Communication method and device of IAB nodes with multiple timings set

Abstract

This specification proposes a communication method for IAB nodes with multiple timings set.

Description

Technology Field

[0001] The present disclosure relates to wireless communication. Background Technology

[0002] One of the potential technologies aimed at enabling future cellular network deployment scenarios and applications is to enable flexible and very dense deployment of NR cells without the need to proportionally densify the transport network as support for wireless backhaul and relay links.

[0003] With the expected availability of larger bandwidths in NR compared to LTE (e.g., millimeter wave spectrum) alongside the native deployment of massive MIMO or multi-beam systems, opportunities for the development and deployment of integrated access and backhaul links are created. This allows for easier deployment of dense networks of self-backhauled NR cells in a more integrated manner by establishing multiple control and data channels / procedures defined to provide access to terminals. Such systems are referred to as integrated access and backhaul links (IABs). means of solving the problem

[0004] This specification proposes a communication method for IAB nodes with multiple timings set. Effects of the invention

[0005] According to the present specification, by proposing a communication method of IAB nodes based on multiple timings, more flexible and high-efficiency communication can be supported.

[0006] The effects obtainable through the specific examples of this specification are not limited to those listed above. For example, there may be various technical effects that a person having ordinary skill in the related art can understand or derive from this specification. Accordingly, the specific effects of this specification are not limited to those explicitly described herein, but may include various effects that can be understood or derived from the technical features of this specification. Brief explanation of the drawing

[0007] The drawings attached below are intended to aid in understanding the present disclosure and may provide embodiments of the present disclosure together with the detailed description. However, the technical features of the present disclosure are not limited to specific drawings, and the features disclosed in each drawing may be combined with one another to form new embodiments. Reference numerals in each drawing may denote structural elements. FIG. 1 illustrates a wireless communication system to which the present disclosure may be applied. Figure 2 is a block diagram showing the radio protocol architecture for the user plane. Figure 3 is a block diagram showing the wireless protocol structure for the control plane. FIG. 4 shows another example of a wireless communication system to which the technical features of the present disclosure can be applied. Figure 5 illustrates the functional partitioning between NG-RAN and 5GC. Figure 6 illustrates a frame structure that can be applied in NR. Figure 7 shows a slot structure. Figure 8 illustrates a CORESET. Figure 9 is a diagram showing the difference between the conventional control area and the CORESET in NR. Figure 10 illustrates an example of a frame structure for a new wireless access technology. Figure 11 is an example of a self-contained slot structure. Figure 12 is an abstract schematic of a hybrid beamforming structure in terms of the TXRU and physical antenna. Figure 13 illustrates the synchronization signal and the PBCH (SS / PBCH) block. Figure 14 is intended to explain how a terminal obtains timing information. Figure 15 illustrates an example of the process of acquiring system information of a terminal. Figure 16 is intended to illustrate a random access procedure. Figure 17 is intended to illustrate a power ramping counter. Figure 18 is intended to explain the concept of threshold values ​​for SS blocks regarding RACH resource relationships. FIG. 19 is a flowchart illustrating an example of performing idle mode DRX operations. Figure 20 illustrates a DRX cycle. FIG. 21 schematically illustrates an example of a network having integrated access and backhaul links (IAB). FIG. 22 illustrates an example of the operation of an IAB system in SA (standalone) mode and NSA (non-standalone) mode. FIG. 23 schematically illustrates an example of the configuration of access and backhaul links. Figure 24 is intended to illustrate the links and relationships between IAB nodes. Figure 25 illustrates timing alignment case 1. Figure 26 illustrates timing alignment case 6. Figure 27 illustrates timing alignment case 7. Figure 28 illustrates an example of the operation of an IAB node in a case where the uplink reception timing may differ for each child link of the DU of the IAB node. Figure 29 illustrates an example of the timing difference between an IAB node and multiple child links. Figure 30 illustrates another example of the timing difference between an IAB node and multiple child links. FIG. 31 is intended to illustrate an example of uplink transmission of an IAB node MT with multiple uplink transmission timings set according to a partial implementation of the present specification. FIG. 32 is a flowchart for an example of a signal transmission method of an IAB node according to a partial implementation of the present specification. FIG. 33 is a flowchart for an example of a method for receiving a signal of an IAB node according to a partial implementation of the present specification. FIG. 34 illustrates a communication system (1) to which the present disclosure applies. FIG. 35 illustrates a wireless device that can be applied to the present disclosure. FIG. 36 illustrates a signal processing circuit for a transmission signal. FIG. 37 shows another example of a wireless device to which the present disclosure applies. FIG. 38 illustrates a portable device to which the present disclosure applies. FIG. 39 illustrates a vehicle or autonomous vehicle to which the present disclosure applies. FIG. 40 illustrates a vehicle to which the present disclosure applies. FIG. 41 illustrates an XR device to which the present disclosure applies. FIG. 42 illustrates a robot to which the present disclosure applies. FIG. 43 illustrates an AI device to which the present disclosure applies. Specific details for implementing the invention

[0008] In this specification, “A or B” may mean “only A,” “only B,” or “both A and B.” Alternatively, in this specification, “A or B” may be interpreted as “A and / or B.” For example, in this specification, “A, B or C” may mean “only A,” “only B,” “only C,” or “any combination of A, B and C.”

[0009] As used herein, a slash ( / ) or a comma may mean “and / or.” For example, “A / B” may mean “A and / or B.” Accordingly, “A / B” may mean “only A,” “only B,” or “both A and B.” For example, “A, B, C” may mean “A, B or C.”

[0010] In this specification, “at least one of A and B” may mean “only A,” “only B,” or “both A and B.” Additionally, in this specification, the expressions “at least one of A or B” or “at least one of A and / or B” may be interpreted as synonymous with “at least one of A and B.”

[0011] Additionally, in this specification, “at least one of A, B and C” may mean “only A,” “only B,” “only C,” or “any combination of A, B and C.” Additionally, “at least one of A, B or C” or “at least one of A, B and / or C” may mean “at least one of A, B and C.”

[0012] Additionally, parentheses used in this specification may mean “for example.” Specifically, when indicated as “Control Information (PDCCH),” “PDCCH” may be proposed as an example of “Control Information.” In other words, “Control Information” in this specification is not limited to “PDCCH,” and “PDDCH” may be proposed as an example of “Control Information.” Furthermore, even when indicated as “Control Information (i.e., PDCCH),” “PDCCH” may be proposed as an example of “Control Information.”

[0013] Technical features described individually within a single drawing in this specification may be implemented individually or simultaneously.

[0014] FIG. 1 illustrates a wireless communication system to which the present disclosure may be applied. This may also be referred to as an E-UTRAN (Evolved-UMTS Terrestrial Radio Access Network) or an LTE (Long Term Evolution) / LTE-A system.

[0015] E-UTRAN includes a base station (20: Base Station, BS) that provides a control plane and a user plane to a terminal (10: User Equipment, UE). The terminal (10) may be fixed or mobile and may be referred to by other terms such as MS (Mobile station), UT (User Terminal), SS (Subscriber Station), MT (mobile terminal), or Wireless Device. The base station (20) refers to a fixed station that communicates with the terminal (10) and may be referred to by other terms such as eNB (evolved-NodeB), BTS (Base Transceiver System), or Access Point.

[0016] Base stations (20) can be connected to each other through an X2 interface. The base station (20) is connected to the EPC (Evolved Packet Core, 30) through the S1 interface, more specifically to the MME (Mobility Management Entity) through the S1-MME and to the S-GW (Serving Gateway) through the S1-U.

[0017] The EPC (30) consists of an MME, an S-GW, and a P-GW (Packet Data Network-Gateway). The MME holds information regarding the terminal's connection information or capabilities, and this information is primarily used for managing the terminal's mobility. The S-GW is a gateway with an E-UTRAN as its endpoint, and the P-GW is a gateway with a PDN as its endpoint.

[0018] The layers of the Radio Interface Protocol between a terminal and a network can be classified into L1 (Layer 1), L2 (Layer 2), and L3 (Layer 3) based on the lower three layers of the Open System Interconnection (OSI) model, which is widely known in communication systems. Among these, the physical layer, which belongs to Layer 1, provides information transfer services using a physical channel, while the Radio Resource Control (RRC) layer, located at Layer 3, performs the role of controlling radio resources between the terminal and the network. To this end, the RRC layer exchanges RRC messages between the terminal and the base station.

[0019] FIG. 2 is a block diagram showing the radio protocol architecture for the user plane. FIG. 3 is a block diagram showing the radio protocol architecture for the control plane. The user plane is a protocol stack for transmitting user data, and the control plane is a protocol stack for transmitting control signals.

[0020] Referring to Figures 2 and 3, the physical layer (PHY layer) provides information transfer services to upper layers using a physical channel. The physical layer is connected to the upper layer, the MAC (Medium Access Control) layer, through a transport channel. Data travels between the MAC layer and the physical layer through the transport channel. Transport channels are classified according to how and with what characteristics data is transmitted through a wireless interface.

[0021] Data travels between different physical layers, specifically between the physical layers of the transmitter and the receiver, through a physical channel. This physical channel can be modulated using the Orthogonal Frequency Division Multiplexing (OFDM) method and utilizes time and frequency as wireless resources.

[0022] The functions of the MAC layer include mapping between logical channels and transport channels, and multiplexing / demultiplexing MAC SDUs (service data units) belonging to logical channels into transport blocks provided to physical channels over the transport channel. The MAC layer provides services to the RLC (Radio Link Control) layer through logical channels.

[0023] The functions of the RLC layer include the concatenation, segmentation, and reassembly of RLC SDUs. To ensure the various Quality of Service (QoS) required by Radio Bearers (RBs), the RLC layer provides three operating modes: Transparent Mode (TM), Unacknowledged Mode (UM), and Acknowledged Mode (AM). AM RLC provides error correction through Automatic Repeat Requests (ARQ).

[0024] The RRC (Radio Resource Control) layer is defined only in the control plane. The RRC layer is responsible for controlling logical channels, transmission channels, and physical channels in relation to the configuration, reconfiguration, and release of wireless bearers. RB refers to a logical path provided by the first layer (PHY layer) and the second layer (MAC layer, RLC layer, PDCP layer) for data transmission between a terminal and a network.

[0025] The functions of the PDCP (Packet Data Convergence Protocol) layer in the user plane include the delivery of user data, header compression, and ciphering. The functions of the PDCP (Packet Data Convergence Protocol) layer in the control plane include the delivery of control plane data and encryption / integrity protection.

[0026] The establishment of an RB refers to the process of defining the characteristics of the wireless protocol layer and channel to provide specific services, and setting their respective specific parameters and operating methods. RBs can be further divided into two types: SRBs (Signaling RBs) and DRBs (Data RBs). SRBs are used as a channel for transmitting RRC messages in the control plane, while DRBs are used as a channel for transmitting user data in the user plane.

[0027] When an RRC connection is established between the terminal's RRC layer and the E-UTRAN's RRC layer, the terminal is in an RRC connected state; otherwise, it is in an RRC idle state.

[0028] Downlink transmission channels for transmitting data from a network to a terminal include a Broadcast Channel (BCH) for transmitting system information and a Shared Channel (SCH) for transmitting user traffic or control messages. Traffic or control messages for downlink multicast or broadcast services may be transmitted via the Shared Channel (SCH) or via a separate Multicast Channel (MCH). Meanwhile, uplink transmission channels for transmitting data from a terminal to a network include a Random Access Channel (RACH) for transmitting initial control messages and a Shared Channel (SCH) for transmitting user traffic or control messages.

[0029] Logical channels that are above the transmission channel and map to the transmission channel include BCCH (Broadcast Control Channel), PCCH (Paging Control Channel), CCCH (Common Control Channel), MCCH (Multicast Control Channel), and MTCH (Multicast Traffic Channel).

[0030] A physical channel consists of multiple OFDM symbols in the time domain and multiple subcarriers in the frequency domain. A single subframe consists of multiple OFDM symbols in the time domain. A resource block is a resource allocation unit composed of multiple OFDM symbols and multiple subcarriers. Additionally, each subframe may utilize specific subcarriers of specific OFDM symbols (e.g., the first OFDM symbol) within that subframe for the Physical Downlink Control Channel (PDCCH), i.e., the L1 / L2 control channel. A Transmission Time Interval (TTI) is a unit of time for transmission, which can be, for example, a subframe or a slot.

[0031] The following describes new radio access technology (new RAT, NR).

[0032] As more communication devices require larger communication capacities, the need for enhanced mobile broadband communication compared to existing radio access technology (RAT) is emerging. Furthermore, Massive Machine Type Communications (MTC), which connects multiple devices and objects to provide various services anytime and anywhere, is also one of the major issues to be considered in next-generation communication. In addition, communication system designs that take into account services and terminals sensitive to reliability and latency are being discussed. Thus, the introduction of next-generation radio access technologies that consider enhanced mobile broadband communication, massive MTC, and Ultra-Reliable and Low Latency Communication (URLC) is being discussed, and for convenience, this technology is referred to as new RAT or NR in this disclosure.

[0033] FIG. 4 shows another example of a wireless communication system to which the technical features of the present disclosure can be applied.

[0034] Specifically, FIG. 4 illustrates a system architecture based on a 5G NR (new radio access technology) system. An entity used in the 5G NR system (hereinafter simply referred to as "NR") can absorb some or all of the functions of the entities introduced in FIG. 1 (e.g., eNB, MME, S-GW). An entity used in the NR system may be identified by the name "NG" to distinguish it from LTE.

[0035] Referring to FIG. 4, the wireless communication system includes one or more UEs (11), a next-generation RAN (NG-RAN), and a fifth-generation core network (5GC). The NG-RAN consists of at least one NG-RAN node. The NG-RAN node is an entity corresponding to the BS (20) shown in FIG. 1. The NG-RAN node consists of at least one gNB (21) and / or at least one ng-eNB (22). The gNB (21) provides terminations for NR user plane and control plane protocols toward the UE (11). The ng-eNB (22) provides terminations for E-UTRA user plane and control plane protocols toward the UE (11).

[0036] 5GC includes the Access and Mobility Management Function (AMF), User Plane Function (UPF), and Session Management Function (SMF). The AMF hosts functions such as NAS security and idle state mobility processing. The AMF is an entity that includes the functions of a conventional MME. The UPF hosts functions such as mobility anchoring and Protocol Data Unit (PDU) processing. The UPF is an entity that includes the functions of a conventional S-GW. The SMF hosts functions such as UE IP address allocation and PDU session control.

[0037] The gNB and ng-eNB are interconnected via the Xn interface. The gNB and ng-eNB are also connected to the 5GC via the NG interface. More specifically, they are connected to the AMF via the NG-C interface and to the UPF via the NG-U interface.

[0038] Figure 5 illustrates the functional partitioning between NG-RAN and 5GC.

[0039] Referring to FIG. 5, the gNB can provide functions such as Inter Cell RRM, RB control, Connection Mobility Control, Radio Admission Control, Measurement Configuration & Provision, and Dynamic Resource Allocation. The AMF can provide functions such as NAS security and idle state mobility processing. The UPF can provide functions such as Mobility Anchoring and PDU processing. The SMF (Session Management Function) can provide functions such as terminal IP address allocation and PDU session control.

[0040] Figure 6 illustrates a frame structure that can be applied in NR.

[0041] Referring to FIG. 6, the frame may consist of 10 ms (milliseconds) and may include 10 subframes consisting of 1 ms.

[0042] In NR, uplink and downlink transmissions can be composed of frames. A radio frame has a length of 10 ms and can be defined as two 5 ms half-frames (HF). A half-frame can be defined as five 1 ms subframes (SF). A subframe is divided into one or more slots, and the number of slots within a subframe depends on the subcarrier spacing (SCS). Each slot contains 12 or 14 OFDM(A) symbols depending on the cyclic prefix (CP). When a normal CP is used, each slot contains 14 symbols. When an extended CP is used, each slot contains 12 symbols. Here, the symbols may include OFDM symbols (or CP-OFDM symbols) or SC-FDMA symbols (or DFT-s-OFDM symbols).

[0043] One or more slots may be included within the subframe depending on the subcarrier spacing.

[0044] The following Table 1 shows examples of subcarrier spacing configurations μ.

[0045]

[0046] Table 2 below shows the number of slots (N) within a frame according to the subcarrier spacing configuration μ. frameμ slot ), number of slots in the subframe (N subframeμ slot ), number of symbols in the slot (N slot symb Examples include ) etc.

[0047]

[0048] Table 3 shows the number of symbols per slot, the number of slots per frame, and the number of slots per subframe (SF) according to the SCS when an extended CP is used.

[0049]

[0050] NR supports multiple numerologies (or subcarrier spacing (SCS)) to support various 5G services. For example, when the SCS is 15 kHz, it supports a wide area in traditional cellular bands; when the SCS is 30 kHz / 60 kHz, it supports dense-urban, lower latency, and wider carrier bandwidth; and when the SCS is 60 kHz or higher, it supports a bandwidth greater than 24.25 GHz to overcome phase noise.

[0051] The NR frequency band can be defined by two types of frequency ranges (FR1, FR2). The numerical values ​​of the frequency ranges may change; for example, the two types of frequency ranges (FR1, FR2) may be as shown in Table 4 below. For convenience of explanation, among the frequency ranges used in the NR system, FR1 may mean the “sub 6GHz range” and FR2 may mean the “above 6GHz range” and may be referred to as millimeter wave (mmW).

[0052] Frequency Range Designation Corresponding frequency range Subcarrier Spacing FR1 450MHz - 6000MHz 15, 30, 60kHz FR2 24250MHz - 52600MHz 60, 120, 240kHz

[0053] As described above, the numerical value of the frequency range of the NR system may change. For example, FR1 may include a band of 410 MHz to 7125 MHz as shown in Table 5 below. That is, FR1 may include a frequency band of 6 GHz (or 5850, 5900, 5925 MHz, etc.) or higher. For example, the frequency band of 6 GHz (or 5850, 5900, 5925 MHz, etc.) or higher included within FR1 may include an unlicensed band. The unlicensed band may be used for various purposes, for example, for communication for vehicles (e.g., autonomous driving).

[0054] Frequency Range Designation Corresponding frequency range Subcarrier Spacing FR1 410MHz - 7125MHz 15, 30, 60kHz FR2 24250MHz - 52600MHz 60, 120, 240kHz

[0055] In an NR system, the OFDM(A) numerology (e.g., SCS, CP length, etc.) can be configured differently among multiple cells that are merged into a single terminal. Accordingly, the (absolute time) interval of a time resource (e.g., SF, slot, or TTI) (collectively referred to as TU (Time Unit) for convenience) composed of the same number of symbols can be configured differently among the merged cells.

[0056] Figure 7 shows a slot structure.

[0057] Referring to FIG. 7, a slot contains multiple symbols in the time domain. For example, in the case of a normal CP, one slot may contain 14 symbols, but in the case of an extended CP, one slot may contain 12 symbols. Alternatively, in the case of a normal CP, one slot may contain 7 symbols, but in the case of an extended CP, one slot may contain 6 symbols.

[0058] A carrier includes multiple subcarriers in the frequency domain. A Resource Block (RB) can be defined as multiple (e.g., 12) consecutive subcarriers in the frequency domain. A Bandwidth Part (BWP) can be defined as multiple consecutive (P)RBs in the frequency domain and can correspond to a single numerology (e.g., SCS, CP length, etc.). A carrier can include up to N (e.g., 5) BWPs. Data communication can be performed through the active BWPs. Each element can be referred to as a Resource Element (RE) in a resource grid and can be mapped to a single complex symbol.

[0059] A PDCCH (physical downlink control channel) can be composed of one or more CCEs (control channel elements) as shown in the following table.

[0060] Aggregation level Number of CCEs 1 1 2 2 4 4 8 8 16 16

[0061] That is, the PDCCH can be transmitted through a resource consisting of 1, 2, 4, 8, or 16 CCEs. Here, the CCE consists of 6 REGs (resource element groups), and one REG consists of one resource block in the frequency domain and one OFDM (orthogonal frequency division multiplexing) symbol in the time domain.

[0062] Meanwhile, in NR, a new unit called a control resource set (CORESET) can be introduced. A terminal can receive PDCCH from the CORESET.

[0063] Figure 8 illustrates a CORESET.

[0064] Referring to Fig. 8, CORESET is N in the frequency domain CORESET RBIt consists of N resource blocks, and in the time domain N CORESET symb ∈ Can be composed of {1, 2, 3} symbols. N CORESET RB , N CORESET symb It can be provided by the base station through an upper layer signal. As illustrated in FIG. 8, a plurality of CCEs (or REGs) may be included within the CORESET.

[0065] The terminal may attempt to detect PDCCH in units of 1, 2, 4, 8, or 16 CCEs within the CORESET. One or more CCEs that may attempt to detect PDCCH may be called PDCCH candidates.

[0066] The terminal can receive multiple CORESETs.

[0067] Figure 9 is a diagram showing the difference between the conventional control area and the CORESET in NR.

[0068] Referring to FIG. 9, the control area (300) in a conventional wireless communication system (e.g., LTE / LTE-A) is configured across the entire system band used by the base station. All terminals, except for some terminals that support only a narrow band (e.g., eMTC / NB-IoT terminals), had to be able to receive wireless signals across the entire system band of the base station in order to properly receive / decode control information transmitted by the base station.

[0069] On the other hand, in NR, the aforementioned CORESET is introduced. CORESET (301, 302, 303) can be described as a wireless resource for control information that a terminal must receive, and only a portion of the system band can be used instead of the entire system band. A base station can allocate a CORESET to each terminal and transmit control information through the allocated CORESET. For example, in FIG. 9, the first CORESET (301) can be allocated to terminal 1, the second CORESET (302) can be allocated to terminal 2, and the third CORESET (303) can be allocated to terminal 3. In NR, a terminal can receive control information from a base station even without necessarily receiving the entire system band.

[0070] A CORESET may include a terminal-specific CORESET for transmitting terminal-specific control information and a common CORESET for transmitting control information common to all terminals.

[0071] Meanwhile, in NR, high reliability may be required depending on the application field, and in such situations, the target block error rate (BLER) for downlink control information (DCI) transmitted through a downlink control channel (e.g., physical downlink control channel: PDCCH) can be significantly lower than that of conventional technology. As an example of a method to satisfy such requirements for high reliability, the amount of content included in the DCI can be reduced, and / or the amount of resources used during DCI transmission can be increased. In this case, the resources may include at least one of resources in the time domain, resources in the frequency domain, resources in the code domain, and resources in the space domain.

[0072] Meanwhile, the following technologies / features can be applied in NR.

[0073] Self-contained subframe structure

[0074] Figure 10 illustrates an example of a frame structure for a new wireless access technology.

[0075] In NR, for the purpose of minimizing latency, a structure in which the control channel and the data channel are time-division multiplexed (TDM) within a single TTI, as shown in Fig. 10, can be considered as one of the frame structures.

[0076] In Fig. 10, the shaded area represents the downlink control area, and the black area represents the uplink control area. The unmarked area may be used for downlink data (DL data) transmission or uplink data (UL data) transmission. A feature of this structure is that downlink (DL) transmission and uplink (UL) transmission proceed sequentially within a single subframe, allowing DL data to be sent and UL ACK / NACK (Acknowledgement / Not-acknowledgement) to be received within the subframe. Consequently, the time required for data retransmission in the event of a data transmission error is reduced, thereby minimizing the latency of the final data delivery.

[0077] In such a data and control TDMed subframe structure, a time gap is required for the transition process between the base station and the terminal from transmit mode to receive mode or from receive mode to transmit mode. To this end, in a self-contained subframe structure, some OFDM symbols at the time of transition from DL to UL can be set as a guard period (GP).

[0078] Figure 11 is an example of a self-contained slot structure.

[0079] Referring to FIG. 11, a single slot may have a self-complete structure that can include a DL control channel, DL or UL data, a UL control channel, etc. For example, the first N symbols within the slot may be used to transmit a DL control channel (hereinafter referred to as the DL control area), and the last M symbols within the slot may be used to transmit a UL control channel (hereinafter referred to as the UL control area). N and M are each integers greater than or equal to 0. A resource area (hereinafter referred to as the data area) located between the DL control area and the UL control area may be used for transmitting DL data or for transmitting UL data. As an example, the following configuration may be considered. Each section is listed in chronological order.

[0080] 1. DL only configuration

[0081] 2. UL only configuration

[0082] 3. Mixed UL-DL Configuration

[0083] - DL Area + GP (Guard Period) + UL Control Area

[0084] - DL Control Area + GP + UL Area

[0085] Here, the DL area may be (i) a DL data area, (ii) a DL control area + a DL data area. The UL area may be (i) a UL data area, (ii) a UL data area + a UL control area.

[0086] PDCCH can be transmitted in the DL control area, and PDSCH can be transmitted in the DL data area. PUCCH can be transmitted in the UL control area, and PUSCH can be transmitted in the UL data area. Downlink Control Information (DCI), such as DL data scheduling information and UL data scheduling information, can be transmitted in PDCCH. Uplink Control Information (UCI), such as ACK / NACK (Positive Acknowledgement / Negative Acknowledgement) information for DL ​​data, Channel State Information (CSI), and Scheduling Request (SR), can be transmitted in PUCCH. GP provides a time gap during the process of the base station and the terminal switching from transmit mode to receive mode or from receive mode to transmit mode. Within a subframe, some symbols at the point of transition from DL to UL can be set as GP.

[0087] Analog Beamforming #1

[0088] In millimeter wave (mmW), the shorter wavelength allows for the installation of multiple antenna elements within the same area. Specifically, in the 30 GHz band, the wavelength is 1 cm, making it possible to install a total of 100 antenna elements in a 2-dimensional array form at intervals of 0.5 wavelengths (lambda) on a 5 by 5 cm panel. Therefore, in mmW, multiple antenna elements are used to increase beamforming (BF) gain, thereby increasing coverage or throughput.

[0089] In this case, if a transceiver unit (TXRU) is equipped to allow for transmission power and phase control for each antenna element, independent beamforming for each frequency resource becomes possible. However, installing TXRUs for all 100 or so antenna elements presents a problem of low cost-effectiveness. Therefore, a method is being considered in which multiple antenna elements are mapped to a single TXRU and the beam direction is adjusted using an analog phase shifter. This analog beamforming method has the disadvantage of being unable to perform frequency-selective beamforming because it can only create a single beam direction across the entire band.

[0090] A hybrid beamforming (hybrid BF) can be considered as an intermediate form between digital beamforming (Digital BF) and analog beamforming (analog BF), having B TXRUs, which is fewer than Q antenna elements. In this case, although there are differences depending on the connection method between B TXRUs and Q antenna elements, the number of beam directions that can be transmitted simultaneously is limited to B or fewer.

[0091] Analog Beamforming #2

[0092] In NR systems, when multiple antennas are used, hybrid beamforming techniques combining digital and analog beamforming are emerging. In this case, analog beamforming (or RF beamforming) performs precoding (or combining) at the RF stage, which has the advantage of achieving performance close to that of digital beamforming while reducing the number of RF chains and D / A (or A / D) converters. For convenience, the above hybrid beamforming structure can be represented by N TXRUs and M physical antennas. Then, digital beamforming for L data layers to be transmitted at the transmitter can be represented by an N by L matrix, and subsequently, the converted N digital signals pass through the TXRUs to be converted into analog signals, after which analog beamforming represented by an M by N matrix is ​​applied.

[0093] Figure 12 is an abstract schematic representation of a hybrid beamforming structure in terms of the TXRU and physical antenna.

[0094] In Fig. 12, the number of digital beams is L, and the number of analog beams is N. Furthermore, in the NR system, the base station is designed to change analog beamforming on a symbol-by-symbol basis, thereby considering a direction to support more efficient beamforming for terminals located in specific areas. Furthermore, when a specific N TXRUs and M RF antennas are defined as a single antenna panel in Fig. 12, the NR system is even considering a method to introduce multiple antenna panels capable of applying mutually independent hybrid beamforming.

[0095] As described above, when a base station utilizes multiple analog beams, the analog beam advantageous for signal reception may differ for each terminal; therefore, beam sweeping operations are considered to ensure that all terminals have a reception opportunity by changing the multiple analog beams to be applied by the base station in a specific subframe by symbol, at least for synchronization signals, system information, paging, etc.

[0096] Figure 13 illustrates the synchronization signal and the PBCH (SS / PBCH) block.

[0097] According to FIG. 13, the SS / PBCH block consists of a PSS and an SSS each occupying 1 symbol and 127 subcarriers, and a PBCH spanning 3 OFDM symbols and 240 subcarriers, with an unused portion for the SSS left in the middle on one symbol. The periodicity of the SS / PBCH block can be set by the network, and the time position at which the SS / PBCH block can be transmitted can be determined by the subcarrier spacing.

[0098] Polar coding can be used for PBCH. The terminal can assume a band-specific subcarrier spacing for SS / PBCH blocks unless the network configures the terminal to assume a different subcarrier spacing.

[0099] PBCH symbols carry their own frequency-multiplexed DMRS. QPSK modulation can be used for PBCH. 1008 unique physical layer cell IDs can be provided.

[0100] For a half frame having SS / PBCH blocks, the first symbol indices for the candidate SS / PBCH blocks are determined according to the subcarrier spacing of the SS / PBCH blocks described below.

[0101] - Case A - Subcarrier spacing 15 kHz: The first symbols of the candidate SS / PBCH blocks have indices of {2, 8}+14*n. For carrier frequencies 3 GHz or lower, n=0, 1. For carrier frequencies greater than 3 GHz and less than or equal to 6 GHz, n=0, 1, 2, 3.

[0102] - Case B - Subcarrier spacing 30 kHz: The first symbols of the candidate SS / PBCH blocks have indices of {4, 8, 16, 20}+28*n. For carrier frequencies 3 GHz or lower, n=0. For carrier frequencies greater than 3 GHz and less than or equal to 6 GHz, n=0, 1.

[0103] - Case C - Subcarrier spacing 30 kHz: The first symbols of the candidate SS / PBCH blocks have indices of {2, 8}+14*n. For carrier frequencies 3 GHz or less, n=0, 1. For carrier frequencies greater than 3 GHz and less than or equal to 6 GHz, n=0, 1, 2, 3.

[0104] - Case D - Subcarrier spacing 120 kHz: The first symbols of the candidate SS / PBCH blocks have indices of {4, 8, 16, 20}+28*n. For carrier frequencies greater than 6 GHz, n=0, 1, 2, 3, 5, 6, 7, 8, 10, 11, 12, 13, 15, 16, 17, 18.

[0105] - Case E - Subcarrier spacing 240 kHz: The first symbols of the candidate SS / PBCH blocks have indices of {8, 12, 16, 20, 32, 36, 40, 44}+56*n. For carrier frequencies greater than 6 GHz, n=0, 1, 2, 3, 5, 6, 7, 8.

[0106] Candidate SS / PBCH blocks within a half frame are indexed in ascending order from 0 to L-1 on the time axis. The terminal must determine the 2 LSB bits for L=4 and the 3 LSB bits for L>4 of the SS / PBCH block index per half frame from a one-to-one mapping with the index of the DM-RS sequence transmitted within the PBCH. For L=64, the terminal must determine the 3 MSB bits of the SS / PBCH block index per half frame based on the PBCH payload bits.

[0107] By the upper layer parameter 'SSB-transmitted-SIB1', an index of SS / PBCH blocks can be set where the terminal cannot receive other signals or channels within REs that overlap with REs corresponding to the SS / PBCH blocks. Additionally, by the upper layer parameter 'SSB-transmitted', an index of SS / PBCH blocks per serving cell can be set where the terminal cannot receive other signals or channels within REs that overlap with REs corresponding to the SS / PBCH blocks. The setting by 'SSB-transmitted' may take precedence over the setting by 'SSB-transmitted-SIB1'. By the upper layer parameter 'SSB-periodicityServingCell', the periodicity of the half-frame for the reception of SS / PBCH blocks per serving cell can be set. If the terminal is not set the periodicity of the half-frame for the reception of SS / PBCH blocks, the terminal must assume the periodicity of the half-frame. The terminal can assume that the periodicity is the same for all SS / PBCH blocks within the serving cell.

[0108] Figure 14 is intended to explain how a terminal obtains timing information.

[0109] First, the terminal can obtain 6 bits of SFN information through the Master Information Block (MIB) received within the PBCH. In addition, it can obtain 4 bits of SFN within the PBCH transmission block.

[0110] Secondly, the terminal can obtain a 1-bit half-frame indicator as part of the PBCH payload. Below 3 GHz, the half-frame indicator can be implicitly signaled as part of the PBCH DMRS for Lmax=4.

[0111] Finally, the terminal can obtain the SS / PBCH block index via the DMRS sequence and the PBCH payload. That is, the LSB 3 bits of the SS block index can be obtained via the DMRS sequence during a 5ms period. Additionally, the MSB 3 bits of the timing information are explicitly carried within the PBCH payload (for frequencies above 6GHz).

[0112] In initial cell selection, the terminal can assume that half frames containing SS / PBCH blocks occur with a periodicity of 2 frames. Upon detecting an SS / PBCH block, the terminal, if k for FR1 SSB For k ≤23 and FR2 SSB If ≤11, it is determined that a set of control resources exists for the Type0-PDCCH common search space. The terminal, if k for FR1 SSB for >23 and FR2 k SSB If >11, it is determined that there is no set of control resources for the Type0-PDCCH common search space.

[0113] For a serving cell in which there is no transmission of SS / PBCH blocks, the terminal obtains time and frequency synchronization of the serving cell based on the reception of SS / PBCH blocks on the primary cell or PSCell of the cell group for the serving cell.

[0114] The following describes how to obtain system information.

[0115] System information (SI) is divided into a Master Information Block (MIB) and multiple System Information Blocks (SIBs). Here,

[0116] - The MIB is always transmitted over the BCH with an 80ms period and repeats within 80ms, and includes parameters necessary to obtain SystemInformationBlockType1 (SIB1) from the cell;

[0117] - SIB1 is transmitted over the DL-SCH with periodicity and repetition. SIB1 contains information regarding the availability and scheduling (e.g., periodicity, SI-window size) of other SIBs. It also indicates whether they (i.e., other SIBs) are provided on a periodic broadcast basis or on demand. If other SIBs are provided on demand, SIB1 contains information for the terminal to perform an SI request;

[0118] - SIBs other than SIB1 are carried as System Information (SI) messages transmitted over the DL-SCH. Each SI message is transmitted within a periodically occurring time-domain window (called the SI window);

[0119] - For PSCells and secondary cells, the RAN provides the necessary SIs via dedicated signaling. Nevertheless, the terminal must acquire the PSCell's MIB to obtain the SCH's SFN timing (which may differ from the MCG). If the associated SI for a secondary cell changes, the RAN releases and adds the associated secondary cell. For PSCells, the SI can only be changed via Reconfiguration with Sync.

[0120] Figure 15 illustrates an example of the process of acquiring system information of a terminal.

[0121] According to FIG. 15, the terminal receives an MIB from the network and can subsequently receive SIB1. After that, the terminal can send a system information request to the network and receive a 'SystemInformation message' from the network in response.

[0122] The terminal can apply a system information acquisition procedure for acquiring AS (access stratum) and NAS (non-access stratum) information.

[0123] Terminals in the RRC_IDLE and RRC_INACTIVE states must ensure valid versions of (at least) MIB, SIB1, and SystemInformationBlockTypeX (depending on the relevant RAT support for the mobility controlled by the terminal).

[0124] Terminals in the RRC_CONNECTED state must ensure valid versions of MIB, SIB1, and SystemInformationBlockTypeX (depending on mobility support for the relevant RAT).

[0125] The terminal must store the relevant SI acquired from the currently camped / serving cell. The version of the SI acquired and stored by the terminal is valid only for a certain period of time. The terminal may use this stored version of the SI, for example, after cell reselection, return from outside coverage, or after a system information change instruction.

[0126] In the following, random access is explained.

[0127] The random connection procedure of the terminal can be summarized as shown in the following table.

[0128]

[0129] Figure 16 is intended to illustrate a random access procedure.

[0130] According to FIG. 16, first, the terminal can transmit a PRACH (physical random access channel) preamble to the uplink as message (Msg) 1 of the random access procedure.

[0131] Two randomly connected preamble sequences of different lengths are supported. A long sequence of length 839 is applied to subcarrier intervals of 1.25 kHz and 5 kHz, and a short sequence of length 139 is applied to subcarrier intervals of 15, 30, 60, and 120 kHz. The long sequence supports an inrestricted set and restricted sets of types A and B, whereas the short sequence supports only an inrestricted set.

[0132] Multiple RACH preamble formats are defined by one or more RACH OFDM symbols, different CPs (cyclic prefixes), and guard times. The RACH preamble setting to be used is provided to the terminal as system information.

[0133] If there is no response to Msg1, the terminal may retransmit a power-ramped PRACH preamble within a specified number of times. The terminal calculates the PRACH transmission power for the retransmission of the preamble based on the most recent estimated path loss and the power ramping counter. If the terminal performs beam switching, the power ramping counter does not change.

[0134] Figure 17 is intended to illustrate a power ramping counter.

[0135] The terminal can perform power ramping for the retransmission of a random access preamble based on a power ramping counter. Here, as previously mentioned, the power ramping counter does not change when the terminal performs beam switching during PRACH retransmission.

[0136] According to FIG. 17, when a terminal retransmits a random access preamble for the same beam, such as when the power ramping counter increases from 1 to 2 or from 3 to 4, the terminal increases the power ramping counter by 1. However, when the beam is changed, the power ramping counter does not change during PRACH retransmission.

[0137] Figure 18 is intended to explain the concept of threshold values ​​for SS blocks regarding RACH resource relationships.

[0138] System information informs the terminal of the relationship between SS blocks and RACH resources. The threshold of the SS block for the RACH resource relationship is based on RSRP and network configuration. Transmission or retransmission of the RACH preamble is based on the SS block satisfying the threshold. Thus, in the example of FIG. 18, since SS block m exceeds the threshold of the received power, the RACH preamble is transmitted or retransmitted based on SS block m.

[0139] Subsequently, when the terminal receives a random access response on the DL-SCH, the DL-SCH may provide timing array information, an RA-preamble ID, an initial uplink grant, and a temporary C-RNTI.

[0140] Based on the above information, the terminal can perform an uplink transmission on the UL-SCH as Msg3 of the random access procedure. Msg3 may include an RRC connection request and a UE identifier.

[0141] In response to this, the network may transmit Msg4, which can be treated as a contention resolution message, over the downlink. Upon receiving this, the terminal can enter an RRC connection state.

[0142] <bandwidth part (BWP)>

[0143] In an NR system, up to 400 megahertz (MHz) can be supported per component carrier (CC). If a terminal operating in such a wideband CC always keeps the RF for the entire CC turned on, the terminal's battery consumption may increase. Alternatively, considering various use cases (e.g., eMBB, URLLC, mMTC, etc.) operating within a single wideband CC, different numerologies (e.g., sub-carrier spacing (SCS)) may be supported for each frequency band within that CC. Or, the capability regarding the maximum bandwidth may vary by terminal. Taking this into account, the base station may instruct the terminal to operate only in a portion of the bandwidth rather than the entire bandwidth of the wideband CC, and for convenience, this portion of the bandwidth is to be defined as the bandwidth part (BWP). A BWP can be composed of consecutive resource blocks (RBs) on the frequency axis and can correspond to a single numerology (e.g., subcarrier spacing, CP (cyclic prefix) length, slot / mini-slot duration, etc.).

[0144] Meanwhile, the base station can configure multiple BWPs within a single CC configured for the terminal. For example, a BWP occupying a relatively small frequency range can be configured in the PDCCH monitoring slot, and the PDSCH indicated by the PDCCH can be scheduled on a larger BWP. Alternatively, if terminals are concentrated on a specific BWP, some terminals can be configured to a different BWP for load balancing. Or, considering frequency domain inter-cell interference cancellation between neighboring cells, a portion of the spectrum in the middle of the total bandwidth can be excluded, and both BWPs can be configured within the same slot. That is, the base station may set at least one DL / UL BWP to a terminal associated with a wideband CC, and may activate at least one of the DL / UL BWP(s) set at a specific time (by L1 signaling, MAC CE, RRC signaling, etc.), and may be instructed to switch to another set DL / UL BWP (by L1 signaling, MAC CE, RRC signaling, etc.), or may be switched to a predetermined DL / UL BWP when the timer value expires based on a timer. In this case, the activated DL / UL BWP is defined as the active DL / UL BWP. However, in situations such as when the terminal is in the initial access process or before the RRC connection is set up, the terminal may not receive the setting for the DL / UL BWP; in such situations, the DL / UL BWP assumed by the terminal is defined as the initial active DL / UL BWP.

[0145] <DRX(Discontinuous Reception)>

[0146] DRX (Discontinuous Reception) refers to an operating mode that allows the User Equipment (UE) to receive downlink channels discontinuously by reducing battery consumption. In other words, a terminal configured for DRX can reduce power consumption by receiving DL signals discontinuously.

[0147] The DRX operation is performed within a DRX cycle, which represents a time interval in which an On Duration is repeated periodically. A DRX cycle includes an On Duration and a Sleep Duration (or opportunity for DRX). The On Duration represents a time interval during which the terminal monitors the PDCCH to receive it.

[0148] DRX can be performed in the RRC(Radio Resource Control)_IDLE state (or mode), RRC_INACTIVE state (or mode), or RRC_CONNECTED state (or mode). In the RRC_IDLE state and RRC_INACTIVE state, DRX can be used to receive paging signals discontinuously.

[0149] - RRC_IDLE state: A state in which a wireless connection (RRC connection) has not been established between the base station and the terminal.

[0150] - RRC_INACTIVE state: A wireless connection (RRC connection) has been established between the base station and the terminal, but the wireless connection is disabled.

[0151] - RRC_CONNECTED state: A state in which a wireless connection (RRC connection) has been established between the base station and the terminal.

[0152] DRX can basically be classified into idle mode DRX, connected DRX (C-DRX), and extended DRX.

[0153] A DRX applied in the IDLE state may be named an idle mode DRX, and a DRX applied in the CONNECTED state may be named a connected mode DRX (C-DRX).

[0154] eDRX (Extended / Enhanced DRX) is a mechanism that can extend the cycles of idle mode DRX and C-DRX, and eDRX (Extended / Enhanced DRX) can be primarily used for (massive) IoT applications. In idle mode DRX, whether to allow eDRX can be configured based on system information (e.g., SIB1). SIB1 may include an eDRX-allowed parameter. The eDRX-allowed parameter is a parameter indicating whether the idle mode extended DRX is allowed.

[0155] <Idle Mode DRX>

[0156] In idle mode, the terminal can use DRX to reduce power consumption. A paging occasion (PO) is a subframe in which a P-RNTI (Paging-Radio Network Temporary Identifier) ​​can be transmitted via a PDCCH (Physical Downlink Control Channel) or MPDCCH (MTC PDCCH) or NPDCCH (Narrowband PDCCH) (which addresses paging messages for NB-IoT).

[0157] In the case of a P-RNTI transmitted via MPDCCH, the PO may represent the starting subframe of the MPDCCH iteration. In the case of a P-RNTI transmitted via NPDCCH, if the subframe determined by the PO is not a valid NB-IoT downlink subframe, the PO may represent the starting subframe of the NPDCCH iteration. Therefore, the first valid NB-IoT downlink subframe after the PO is the starting subframe of the NPDCCH iteration.

[0158] A paging frame (PF) is a single radio frame that may contain one or more paging opportunities. When DRX is used, the terminal only needs to monitor one PO per DRX cycle. A paging narrow band (PNB) is a single narrow band where the terminal performs paging message reception. The PF, PO, and PNB can be determined based on DRX parameters provided in the system information.

[0159] FIG. 19 is a flowchart illustrating an example of performing idle mode DRX operations.

[0160] According to FIG. 19, the terminal can receive idle mode DRX setting information from the base station through upper layer signaling (e.g., system information) (S21).

[0161] The terminal can determine a Paging Frame (PF) and a Paging Occasion (PO) to monitor the PDCCH in the paging DRX cycle based on idle mode DRX setting information (S22). In this case, the DRX cycle may include an on-period and a sleep period (or an opportunity for DRX).

[0162] The terminal can monitor the PDCCH at the PO of the determined PF (S23). Here, for example, the terminal monitors only one subframe (PO) per paging DRX cycle. Additionally, when the terminal receives a scrambled PDCCH by the P-RNTI during the on-period (i.e., when paging is detected), the terminal transitions to a connection mode and can transmit and receive data with the base station.

[0163] <Connected mode DRX(C-DRX)>

[0164] C-DRX refers to a DRX applied in an RRC connection state. The DRX cycle of a C-DRX can consist of a short DRX cycle and / or a long DRX cycle. Here, the short DRX cycle may be optional.

[0165] If C-DRX is configured, the terminal can perform PDCCH monitoring during the on-period. If a PDCCH is successfully detected during PDCCH monitoring, the terminal can activate (or run) an inactive timer and maintain an awake state. Conversely, if a PDCCH is not successfully detected during PDCCH monitoring, the terminal can enter a sleep state after the on-period ends.

[0166] If C-DRX is configured, PDCCH receiving opportunities (e.g., slots having a PDCCH search space) may be configured discontinuously based on the C-DRX configuration. In contrast, if C-DRX is not configured, PDCCH receiving opportunities (e.g., slots having a PDCCH search space) may be configured continuously in the present disclosure.

[0167] Meanwhile, PDCCH monitoring can be limited to a time interval set as a measurement gap, regardless of the C-DRX setting.

[0168] Figure 20 illustrates a DRX cycle.

[0169] Referring to FIG. 20, the DRX cycle consists of 'On Duration' and 'Opportunity for DRX'. The DRX cycle defines a time interval in which the 'On Duration' is repeated periodically. The 'On Duration' represents a time interval during which the terminal monitors to receive PDCCH. When the DRX is set, the terminal performs PDCCH monitoring during the 'On Duration'. If a PDCCH is successfully detected during the PDCCH monitoring, the terminal activates an inactivity timer and remains in an awake state. Conversely, if no PDCCH is successfully detected during the PDCCH monitoring, the terminal enters a sleep state after the 'On Duration' ends. Therefore, when the DRX is set, PDCCH monitoring / reception can be performed discontinuously in the time domain when executing the procedure and / or method described / proposed above. For example, if DRX is set, the PDCCH reception occasions (e.g., slots having a PDCCH search space) in this disclosure may be set discontinuously according to the DRX setting. On the other hand, if DRX is not set, PDCCH monitoring / reception may be performed continuously in the time domain when performing the procedure and / or method described / proposed above. For example, if DRX is not set, the PDCCH reception occasions (e.g., slots having a PDCCH search space) in this disclosure may be set continuously. Meanwhile, regardless of whether DRX is set, PDCCH monitoring may be restricted in time intervals set as measurement gaps.

[0170] Table 8 shows the process of the terminal associated with the DRX (RRC_CONNECTED state). Referring to Table 8, DRX configuration information is received via upper layer (e.g., RRC) signaling, and the DRX ON / OFF status is controlled by DRX commands at the MAC layer. Once the DRX is configured, PDCCH monitoring can be performed discontinuously while carrying out the procedures and / or methods described / proposed in this disclosure.

[0171] Type of signals Terminal procedure (UE procedure) Step 1 RRC Signaling (MAC-CellGroupConfig) - Receive DRX configuration information Step 2 MAC CE((Long) DRX command MAC CE) - Receive DRX command Step 3 - - PDCCH monitoring during the on-duration of the DRX cycle

[0172] The above MAC-CellGroupConfig may include configuration information necessary to set MAC (Medium Access Control) parameters for a cell group. MAC-CellGroupConfig may also include configuration information regarding DRX. For example, MAC-CellGroupConfig may include information for defining DRX as follows.

[0173] - Value of drx-OnDurationTimer: Defines the length of the start interval of the DRX cycle.

[0174] - Value of drx-InactivityTimer: Defines the length of the time interval during which the terminal remains awake after a PDCCH opportunity is detected that indicates initial UL or DL ​​data.

[0175] - Value of drx-HARQ-RTT-TimerDL: Defines the maximum time interval from when the initial DL transmission is received until when the DL retransmission is received.

[0176] - Value of drx-HARQ-RTT-TimerDL: Defines the length of the maximum time interval from when a grant for an initial UL transmission is received until when a grant for a UL retransmission is received.

[0177] - drx-LongCycleStartOffset: Defines the time length and start time of the DRX cycle.

[0178] - drx-ShortCycle (optional): Defines the time length of a short DRX cycle

[0179] Here, if any of drx-OnDurationTimer, drx-InactivityTimer, drx-HARQ-RTT-TimerDL, or drx-HARQ-RTT-TimerDL is running, the terminal remains awake and performs PDCCH monitoring at every PDCCH opportunity.

[0180] In the following, the integrated access and backhaul link (IAB) is described. Meanwhile, for the convenience of explanation, the proposed method is described based on the new RAT (NR) system. However, the scope of systems to which the proposed method applies can be extended to other systems, such as 3GPP LTE / LTE-A systems, in addition to NR systems.

[0181] One of the potential technologies aimed at enabling future cellular network deployment scenarios and applications is to enable flexible and very dense deployment of NR cells without the need to proportionally densify the transport network as support for wireless backhaul and relay links.

[0182] With the expected availability of larger bandwidths in NR compared to LTE (e.g., millimeter wave spectrum) alongside the native deployment of massive MIMO or multi-beam systems, opportunities for the development and deployment of integrated access and backhaul links are created. This allows for easier deployment of dense networks of self-backhauled NR cells in a more integrated manner by establishing multiple control and data channels / procedures defined to provide access to terminals. Such systems are referred to as integrated access and backhaul links (IABs).

[0183] The present disclosure defines the following.

[0184] - AC(x): Access link between node(x) and terminal(s).

[0185] - BH(xy): Backhaul link between node (x) and node (y).

[0186] In this case, the node may refer to a DgNB (donor gNB) or a relay node (relay node: RN). Here, the DgNB or donor node may be a gNB that provides the function of supporting backhaul for IAB nodes.

[0187] Additionally, for convenience of explanation in the present disclosure, when relay node 1 and relay node 2 exist, and relay node 1 is connected to relay node 2 via a backhaul link to relay node 2 and relays data transmitted to and received by relay node 2, relay node 1 is referred to as the parent node of relay node 2, and relay node 2 is referred to as the child node of relay node 1.

[0188] The following drawings are prepared to illustrate a specific example of the present specification. The names of specific devices or specific signals / messages / fields described in the drawings are presented as examples, and therefore the technical features of the present specification are not limited to the specific names used in the following drawings.

[0189] FIG. 21 schematically illustrates an example of a network having integrated access and backhaul links (IAB).

[0190] According to FIG. 21, relay nodes (rTRPs) can multiplex access and backhaul links in the time, frequency, or space domain (i.e., beam-based operation).

[0191] The operation of different links can operate on the same frequency or on different frequencies (which may be referred to as 'in-band' or 'out-band' relays, respectively). While efficient support for out-of-band relays is important for some NR deployment scenarios, it is very important to understand the requirements of in-band operation, which involves close interworking with access links operating on the same frequency to accommodate duplex limitations and avoid / mitigate interference.

[0192] Furthermore, operating NR systems in the millimeter-wave spectrum presents some unique challenges, including experiencing severe short-term blocking that may not be easily mitigated by current RRC-based handover mechanisms due to the larger time scale required for procedure completion compared to short blocking. Overcoming short-term blocking in millimeter-wave systems may require fast RAN-based mechanisms for switching between rTRPs that do not necessarily require the inclusion of a core network. The aforementioned need to mitigate short-term blocking in NR operations in the millimeter-wave spectrum, along with the need for easier deployment of self-backhauled NR cells, necessitates the development of an integrated framework that allows for fast switching of access and backhaul links. Over-the-air (OTA) coordination between rTRPs can also be considered as mitigating interference and supporting end-to-end path selection and optimization.

[0193] The following requirements and aspects regarding NR must be addressed by the IAB.

[0194] - Efficient and flexible operation for in-band and out-of-band relay in indoor and outdoor scenarios

[0195] - Multi-hop and redundant connections

[0196] - End-to-end path selection and optimization

[0197] - Support for backhaul links with high spectral efficiency

[0198] - Support for legacy NR terminals

[0199] Legacy NR is designed to support half-duplex devices. Therefore, in IAB scenarios, half-duplex is supported and may be worth targeting. Furthermore, IAB devices with full duplex capabilities can also be considered.

[0200] FIG. 22 illustrates an example of the operation of an IAB system in SA (standalone) mode and NSA (non-standalone) mode. Specifically, FIG. 22 (a) illustrates an example of the operation of a terminal and an IAB node considering NGC in SA mode, FIG. 22 (b) illustrates an example of the operation of an IAB node considering NGC in SA mode and a terminal considering EPC in NSA mode, and FIG. 22 (c) illustrates an example of the operation of a terminal and an IAB node considering EPC in NSA mode.

[0201] An IAB node can operate in SA mode or NSA mode. When operating in NSA mode, the IAB node uses only NR links for backhauling. Terminals connected to an IAB node may select a different operating mode from the IAB node. Terminals may be connected to a different type of core network than the connected IAB node. In this case, (e)DECOR ((enhanced) dedicated core network) or slicing may be used for CN selection. An IAB node operating in NSA mode may be connected to the same or different eNB(s). Terminals operating in NSA mode may be connected to the same or different eNB as the connected IAB node. FIG. 22 illustrates an example considering NGC in SA mode and an example considering EPC in NSA mode.

[0202] In an IAB scenario, if each relay node (RN) does not have scheduling capabilities, the donor gNB (DgNB) must schedule all links between the DgNB, the associated relay nodes, and the terminals. In other words, the DgNB must make scheduling decisions for all links by collecting traffic information from all associated relay nodes, and then notify each relay node of the scheduling information.

[0203] On the other hand, distributed scheduling can be performed when each relay node possesses scheduling capabilities. This enables immediate scheduling of uplink scheduling requests from terminals and allows for more flexible utilization of backhaul / access links by reflecting surrounding traffic conditions.

[0204] FIG. 23 schematically illustrates an example of the configuration of access and backhaul links.

[0205] FIG. 23 shows an example of backhaul links and access links being configured when DgNB and IAB relay nodes (RNs) exist. RN(b) and RN(e) are connected by a backhaul link, RN(c) is connected by a backhaul link to RN(b), and RN(d) is connected by a backhaul link to RN(c).

[0206] According to FIG. 23, the DgNB receives a scheduling request from Terminal 1 (UE1), as well as from Terminal 2 (UE2) and Terminal 3 (UE3). Subsequently, the DgNB makes scheduling decisions for two backhaul links and three access links and provides the scheduling results. Therefore, this centralized scheduling involves scheduling delays and causes latency issues.

[0207] On the other hand, distributed scheduling can be performed if each relay node has scheduling capability. This allows for immediate scheduling of uplink scheduling requests from terminals, and enables backhaul / access links to be utilized more flexibly by reflecting surrounding traffic conditions.

[0208] Figure 24 is intended to illustrate the links and relationships between IAB nodes.

[0209] Referring to FIG. 24, IAB Node 1 is connected to IAB Node 2 via backhaul link A, and with respect to backhaul link A, IAB Node 1 is the parent node of IAB Node 2 and IAB Node 2 is the child node of IAB Node 1. Additionally, IAB Node 2 is connected to IAB Node 3 via backhaul link B, and with respect to backhaul link B, IAB Node 2 is the parent node of IAB Node 3 and IAB Node 3 is the child node of IAB Node 2.

[0210] Here, each of the IAB nodes can perform two functions. One is as a mobile termination (MT) to maintain a wireless backhaul connection to an upper IAB node or donor node, and the other is as a distributed unit (DU) to provide access connections with terminals or to provide connections with the MT of a lower IAB node.

[0211] For example, from the perspective of IAB Node 2, the DU of IAB Node 2 functionally forms a backhaul link B with the MT of IAB Node 3, and at the same time, the MT of IAB Node 2 functionally forms a backhaul link A with the DU of IAB Node 1. Here, the child link of the DU of IAB Node 2 may refer to the backhaul link B between IAB Node 2 and IAB Node 3. Also, here, the parent link of the MT of IAB Node 2 may refer to the backhaul link A between IAB Node 2 and IAB Node 1.

[0212] The initial access of the IAB node is described below.

[0213] To initially establish a connection with a parent node or donor node, an IAB node may follow the same procedure as the terminal's initial connection procedure, which includes cell discovery, system information acquisition, and random connection. SSB / CSI-RS-based RRM measurement is the starting point for IAB node discovery and measurement.

[0214] Discovery procedures between IAB nodes applying half-duplex restrictions and multi-hop topology should be considered, including methods to avoid SSB configuration conflicts between IAB nodes and the feasibility of CSI-RS-based IAB node discovery. Given the cell ID used by a given IAB node, the following two cases can be considered.

[0215] - Case 1: The donor node and the IAB node share the same cell ID

[0216] - Case 2: Donor node and IAB node maintain separate cell IDs

[0217] Furthermore, a mechanism for multiplexing RACH transmission from terminals and RACH transmission from IAB nodes should be additionally considered.

[0218] In the case of SA (standalone) deployment, the initial IAB node discovery by MT (Stage 1) follows the same initial connection procedure as the terminal, which includes cell search based on the same SSB available to the terminals, system information acquisition, and random connection, in order to initially establish a connection with the parent IAB node or IAB donor.

[0219] In the case of an NSA (non-standalone) deployment (from the perspective of the access / access terminal), when the IAB node MT performs an initial connection on the NR carrier, it follows the aforementioned Stage 1 initial connection in the SA deployment (from the perspective of the access terminal). The SSB / RMSI period assumed by the MTs for the initial connection may be longer than 20ms, which is assumed for the rel-15 terminals of the NR, and one of the candidate values ​​20ms, 40ms, 80ms, or 160ms is selected.

[0220] Here, this means that candidate parent IAB nodes / donors must support both NSA functionality for terminals and SA functionality for MTs on the NR carrier.

[0221] When the IAB node MT performs initial access on the LTE carrier, the Stage 2 solutions can be used as parent selection of the IAB node by the MT on the NR carrier.

[0222] Below, backhaul link measurements are explained.

[0223] Measurement of multiple backhaul links for link management and path selection should be considered. To support half-duplex constraints from the perspective of a given IAB node, the IAB supports the detection and measurement of candidate backhaul links (after initial connection) utilizing resources orthogonal to those used by access terminals for cell detection and measurement. In this regard, the following may be further considered.

[0224] - TDM of multiple SSBs (e.g., may follow hop order, cell ID, etc.)

[0225] - SSB muting across IAB nodes

[0226] - Multiplexing of SSBs for access terminals and IAB nodes within or across half-frames

[0227] - Additional IAB node discovery signals (e.g., CSI-RS) transmitted via SSB and TDM

[0228] - Use of off-raster SSB

[0229] - Different transmission cycles for backhaul link detection and measurement compared to the cycles used by access terminals

[0230] A coordination mechanism for different solutions must be further considered, including a coordination mechanism for measurement timing and reference signal (RS) transmission for IAB nodes.

[0231] Enhancement of the SMTC and CSI-RS configurations to support RRM measurements for IAB nodes may be considered.

[0232] For the purpose of backhaul link RSRP / RSRQ RRM measurement, IAB supports SSB-based and CSI-RS-based solutions.

[0233] After the IAB node DU is activated, for the purpose of inter-IAB node and donor detection (Stage 2), the inter-IAB node discovery procedure needs to consider half-duplex limitations for IAB nodes and multi-hop topologies. The following solutions are supported: SSB-based solutions—the use of SSBs orthogonal (TDM and / or FDM) to the SSBs used for access terminals.

[0234] Below, backhaul link management is explained.

[0235] The IAB node supports mechanisms for detecting and recovering backhaul link failures. Enhancements to beam failure recovery (BFR) and radio link failure (RLF) procedures are advantageous and should be supported for the NR IAB as follows.

[0236] - Improvement of support for interaction between beam failure recovery success indications and RLFs.

[0237] Improvements to current beam management procedures for faster beam switching, coordination, and recovery to avoid backhaul link outages should be considered for IAB nodes.

[0238] Furthermore, the need for an additional backhaul link condition notification mechanism from the parent IAB node to the child IAB node, and the necessity for the corresponding IAB node operation, are discussed, for example, in cases where the backhaul link of the parent IAB node fails. Solutions must be supported to avoid RLF in the child IAB node caused by the failure of the parent backhaul link.

[0239] In the following, mechanisms for routing or transmission / reception in multiple backhaul links are described.

[0240] Mechanisms for efficient simultaneous path switching or transmission / reception across multiple backhaul links (e.g., multi-TRP (Tx / Rx point) operation and intra-frequency dual connectivity) must be considered.

[0241] The scheduling of backhaul and access links is described below.

[0242] Downlink IAB node transmissions (i.e., transmissions from an IAB node on a backhaul link to a child IAB node served by said IAB node, and transmissions from an IAB node to terminals served by said IAB node on an access link) must be scheduled by the IAB node itself. Uplink IAB transmissions (transmissions from an IAB node on a backhaul link to its parent node or donor node) must be scheduled by the parent node or donor node.

[0243] The following describes the multiplexing of access and backhaul links.

[0244] The IAB supports TDM, FDM, and SDM between access and backhaul links at the IAB node, subject to half-duplex limits. Mechanisms for efficient TDM / FDM (frequency division multiplexing) / SDM (spatial division multiplexing) multiplexing of access / backhaul traffic across multiple hops, taking into account the IAB node half-duplex limits, must be considered. The following solutions for different multiplexing options may be further considered.

[0245] - Mechanism for the orthogonal partitioning of time slots or frequency resources between access and backhaul links spanning one or more hops

[0246] - Utilization of different DL / UL slot settings for access and backhaul links

[0247] - DL and UL power control enhancement and timing requirements to allow intra-panel FDM and SDM for backhaul and access links

[0248] - Interference management including cross-link interference

[0249] The following describes resource coordination.

[0250] Mechanisms for scheduling coordination, resource allocation, and path selection across IAB nodes / donor nodes and multiple backhaul hops must be considered. Resource coordination (frequency, time in terms of slot / slot format, etc.) between semi-static IAB nodes (on the timescale of RRC signaling) must be supported. The following aspects may be additionally considered.

[0251] - Distributed or centralized coordination mechanism

[0252] - Resource granularity of required signals (e.g., TDD configuration patterns)

[0253] - Exchange of L1 (layer-1) and / or L3 (layer-3) measurements between IAB nodes

[0254] - Exchange of topology-related information (e.g., hop order) affecting backhaul link physical layer design

[0255] - Resource adjustment faster than semi-static adjustment (frequency, time in terms of slot / slot format, etc.)

[0256] The following describes IAB node synchronization and timing alignment.

[0257] The feasibility of over-the-air (OTA) synchronization and the impact of timing misalignment on IAB performance (e.g., the number of hops that can be supported) must be considered. Assuming timing requirements of 3us or less at IAB nodes within overlapping coverage, TA-based OTA synchronization can support a multi-hop IAB network (up to 5 hops) for FR 2. TA-based OTA synchronization may not be sufficient to support multiple hops in FR 1.

[0258] Alignment of the next level between IAB nodes / IAB donors or within an IAB node is discussed.

[0259] - Slot-level alignment

[0260] - Symbol-level alignment

[0261] - Not aligned

[0262] A mechanism for timing alignment in a multi-hop IAB network is discussed. The IAB supports TA-based synchronization between IAB nodes that include multiple backhaul hops. Improvements to existing timing alignment mechanisms are discussed, including the TA required for IAB nodes to support different transmission timing alignment cases.

[0263] The following transmission timing alignment cases across the IAB node and IAB donor are discussed.

[0264] - Case 1: DL transmission timing alignment across IAB node and IAB donor: If downlink transmission and uplink reception are not well aligned at the parent node, the child node requires additional information regarding the alignment to properly set its downlink transmission timing for OTA-based timing and synchronization.

[0265] - Case 2: Downlink and uplink transmission timings are aligned for a single IAB node.

[0266] - Case 3: Downlink and uplink receive timings are aligned for a single IAB node.

[0267] - Case 4: For a single IAB node, in the case of receiving using Case 3 and transmitting using Case 2.

[0268] - Case 5: Case 4 for backhaul link timing and Case 1 for access link timing for a single IAB node within different time slots.

[0269] - Case 6: Sum of the downlink transmission timing of Case 1 and the uplink transmission timing of Case 2: The downlink transmission timing of all IAB nodes is aligned with the downlink timing of the parent IAB node or donor; the uplink transmission timing of an IAB node can be aligned with the downlink transmission timing of the said IAB node.

[0270] - Case 7: Sum of the downlink transmission timing of Case 1 and the uplink reception timing of Case 3: The downlink transmission timing of all IAB nodes is aligned with the downlink timing of the parent IAB node or donor; the uplink reception timing of an IAB node can be aligned with the downlink reception timing of the said IAB node; if the downlink transmission and uplink reception at the parent node are not well aligned, the child node requires additional information regarding the alignment to properly set its downlink transmission timing for OTA-based timing and synchronization.

[0271] The impact of different cases on TDM / FDM / SDM multiplexing of parent and child links, the potential impact of incomplete timing coordination, the overhead of the required downlink / uplink switching gap, cross-link interference, the feasibility of cases where an iab node is connected to one or more parent nodes, and the impact of access terminals (particularly compatibility with rel-15 terminals) are discussed.

[0272] Case 1 is supported for both access and backhaul link transmission timing alignment.

[0273] Cases 2 through 5 are not supported for IAB.

[0274] The use of Case 6 for IAB nodes must be under the control of the parent or network, if supported. To enable the alignment of downlink transmissions between IAB nodes, examples of the following solutions have been identified.

[0275] - Alternative 1: The IAB node may need to perform parallel (always time-multiplexed) Case 1 and Case 6 uplink transmissions.

[0276] - Alternative 2: Signaling between parent and IAB nodes regarding the time difference between downlink transmission and uplink reception timings at the parent node to correct potential misalignment of downlink transmission timing at the child node: The child IAB node compares the corresponding difference between its downlink transmission timing and backhaul reception timing; if the signaled difference at the parent node is greater than that measured at the child node, and if the transmission timing is smaller, the child node advances its transmission timing.

[0277] Here, alternatives 1 and 2 may need to maintain separate receive timings at the parent node for case 6 uplink transmission from other child nodes.

[0278] Case 7 is compatible with rel-15 terminals by introducing TDM between child IAB nodes / rel-16 terminals that support effective negative TA and new TA values ​​and child IAB nodes / terminals that do not support new TA values. To enable alignment between downlink and uplink receptions within an IAB node, examples of the following solutions were identified.

[0279] - Alternative 1: Introduce a negative initial time alignment (TA) to be applied to the child nodes of the IAB node to which Case 7 timing is applied.

[0280] - Alternative 2: Apply a positive TA at the IAB node that allows symbol alignment rather than slot alignment between downlink reception and uplink reception.

[0281] - Alternative 3: Signaling of the relative offset of the most recent TA value to be applied to the child node of the IAB node to which Case 7 timing is applied in order to achieve an efficient negative TA.

[0282] In addition to OTA synchronization, other technologies such as GNSS and PTP can be used to obtain synchronization between IAB nodes.

[0283] The following describes the measurement and management of cross-link interference.

[0284] The impact of cross-link interference (CLI) on access and backhaul links (including those spanning multiple hops) must be considered. Furthermore, interference measurement and management solutions must be considered.

[0285] Below, CLI mitigation techniques are described.

[0286] CLI mitigation techniques, including advanced receiver and transmitter coordination, must be considered and prioritized in terms of complexity and performance. CLI mitigation techniques must be able to manage the following IAB-node interference scenarios.

[0287] - Case 1: The victim IAB node receives via the downlink through its MT, and the interfering IAB node transmits via the uplink through its MT.

[0288] - Case 2: The victim IAB node receives via its MT on the downlink, and the interfering IAB node transmits via its DU on the downlink.

[0289] - Case 3: The victim IAB node receives on the uplink via its DU, and the interfering IAB node transmits on the uplink via its MT.

[0290] - Case 4: The victim IAB node receives on the uplink via its DU, and the interfering IAB node transmits on the downlink via its DU.

[0291] In the case of FDM / SDM reception between access and backhaul links at a given IAB node, interference experienced at the said IAB node must be additionally considered.

[0292] Below, spectral efficiency enhancement is explained.

[0293] Support for 1024 QAM (quadrature amplitude modulation) for the backhaul link should be considered.

[0294] The proposal of the present disclosure will be explained in more detail below.

[0295] The following drawings are prepared to illustrate a specific example of the present specification. The names of specific devices or specific signals / messages / fields described in the drawings are presented as examples, and therefore the technical features of the present specification are not limited to the specific names used in the following drawings. Furthermore, the methods / configurations proposed in the present specification may be combined in various ways.

[0296] Referring to FIGS. 25 through 27, the following three cases of transmission and reception timing alignment of IAB nodes that can be considered in an IAB environment are examined. FIG. 25 illustrates timing alignment case 1. FIG. 26 illustrates timing alignment case 6. FIG. 27 illustrates timing alignment case 7.

[0297] - Timing Alignment Example 1: DL transmission timing alignment across IAB nodes and IAB donors. This is a method in which the downlink transmission timing of DUs between IAB nodes is aligned.

[0298] Referring to Timing Alignment Case 1, if downlink transmission and uplink reception are not well aligned at the parent node, the child node requires additional information regarding the alignment to properly set its downlink transmission timing for OTA-based timing and synchronization. MT transmission timing can be expressed as (MT reception timing - TA (timing advance)), and DU transmission timing as (MT reception timing - TA / 2 - T Δ It can be expressed as ). Here, T Δ The value can be obtained from the parent node.

[0299] - Timing Alignment Example 6: The DL transmission timing for all IAB nodes is aligned with the DL timing of the parent IAB node or donor. The UL transmission timing of an IAB node can be aligned with the DL transmission timing of the said IAB node.

[0300] Referring to Timing Alignment Example 6, this is a method in which the uplink transmission timing for the MT of the IAB node and the downlink transmission timing for the DU of the IAB node are aligned. Since the uplink transmission timing of the MT of the IAB node is fixed, the uplink reception timing of the DU of the parent node receiving it is delayed by the propagation delay between the DU of the parent node and the MT of the IAB node compared to the uplink transmission timing of the MT of the IAB node. If the IAB node uses Timing Alignment Example 6, the uplink reception timing of the parent node changes compared to the existing one; therefore, if the IAB node intends to use Timing Alignment Example 6, the parent node also needs to be aware of this information.

[0301] - Timing Alignment Example 7: The downlink transmission timing of all IAB nodes is aligned with the downlink timing of the parent IAB node or donor. The uplink reception timing of an IAB node can be aligned with the downlink reception timing of the said IAB node.

[0302] Referring to Timing Alignment Example 7, if downlink transmission and uplink reception are not well aligned at the parent node, additional information regarding the alignment is required to properly set its own downlink transmission timing for OTA-based timing and synchronization with respect to the child node. This is a method in which the downlink reception timing of the MT of the IAB node and the uplink reception timing of the DU of the IAB node are aligned. The transmission and reception timing from the perspective of the MT is the same as that of an existing IAB node or a Rel-16 IAB node, and the uplink reception timing of the DU of the IAB node can be matched to the downlink reception timing of the MT of the IAB node. The IAB node can adjust the TA of the MTs of the child nodes so that the child node MTs transmit uplink signals in accordance with its own uplink reception timing. Therefore, this timing alignment method may not reveal differences in the standard (specification) operation of the IAB node when compared to Timing Alignment Example 1. Accordingly, Timing Alignment Example 7 described in this specification may be substituted for / interpreted as Timing Alignment Example 1.

[0303] Meanwhile, in this specification, timing alignment may mean slot-unit alignment or symbol-unit alignment.

[0304] Additionally, multiple timing alignment cases may be set / applied for a single IAB node. Here, the multiple timing alignment cases set / applied may be modified / switched by the time resources of the IAB node. That is, a first timing alignment case may be set / applied for the IAB node in a first time resource, and a second timing alignment case may be set / applied for the IAB node in a second time resource. Here, the first time resource and the second time resource may be distinguished by their positions in the time domain, or by the multiplexing type set for the IAB node. Meanwhile, the modification / switching of the aforementioned timing alignment cases according to the time resources may be performed based on dynamic instructions or based on semi-static instructions.

[0305] The contents proposed in this specification are described under the assumption of an in-band environment, but can also be applied in an out-band environment. Additionally, the contents proposed in this specification are described with consideration of an environment in which a donor gNB (DgNB), a relay node (RN), and a terminal operate in half-duplex mode, but can also be applied in an environment in which the DgNB, RN, and / or terminal operate in full-duplex mode.

[0306] An IAB node operates with a specific transmit / receive timing at a specific point in time, but may use different transmit / receive timings depending on the time or situation. This specification proposes an operation in which an IAB node applies different transmit / receive timings depending on the time or situation.

[0307] First, the DU operation of an IAB node with multiple reception timings is described below.

[0308] For a DU (a DU of a donor node or an IAB node), multiple child node MTs / terminals may be connected. In this case, links to different child node MTs / terminals may be distinguished as different child links. In the case of an existing DU, the uplink reception timing is fixed to a specific timing, and it can be configured so that the uplink reception timings for all child links are aligned. To this end, the DU can set a TA (timing advance) for its child node MTs / terminals so that the uplink reception timings for multiple child links can be aligned.

[0309] On the other hand, in the case of an enhanced IAB node, not all child links may have the same uplink receive timing. Specific examples of situations where uplink receive timing may differ by child link are as follows.

[0310] (Example 1) When a child node applies timing alignment case 6 (transmission timing alignment), the uplink transmission timing of the child node's MT can be aligned with the downlink transmission timing of the child node's DU. In this case, the uplink reception timing of the IAB node's DU can be determined by the propagation delay between the IAB node's DU and the child node. Therefore, the uplink reception timing of the IAB node's DU may differ between uplink signals transmitted by the child node's MT, which have different propagation delays.

[0311] (Example 2) When the timing alignment cases applied between child nodes are different, the uplink reception timing of the DU of the IAB node may differ depending on the MT of the child node. For example, if child node 1 uses timing alignment case 1 and child node 2 uses timing alignment case 6, child node 1 determines the uplink transmission timing based on the configured TA, and child node 2 determines the uplink transmission timing according to its downlink transmission timing. Therefore, the uplink reception timing of the DU of the IAB node may differ between the uplink signals transmitted by the MT of child node 1 and the MT of child node 2.

[0312] (Example 3) The uplink reception timing of the DUs of an IAB node may differ depending on the capability of the child nodes. For example, when the DU of an IAB node wishes to align its uplink reception timing to apply Timing Alignment Case 7, the MT of Child Node 1, which is an improved IAB node, can determine the uplink transmission timing by adjusting the TA value to match the uplink reception timing. In this case, the TA value may become negative, causing the uplink transmission timing of the MT of Child Node 1 to be behind the downlink reception timing. Another child link of the IAB node's DU may be connected to an access UE or the MT of Child Node 2, which is a legacy IAB node. In this case, the access UE or the MT of Child Node 2 lacks the capability to set a negative TA value, so the uplink transmission timing may always have to be ahead of the downlink reception timing. In this case, the uplink reception timing of the DU of the IAB node may differ between the uplink signals transmitted by the MT of child node 1 and the connected terminal or the MT of child node 2.

[0313] As described above, this specification proposes the operation of an IAB node when the uplink reception timing may differ for each child link of the DU of the IAB node. In this specification, the MT of the child node may refer to a connected terminal.

[0314] FIG. 28 illustrates an example of the operation of an IAB node in a case where the uplink reception timing may differ for each child link of the DU of the IAB node. The example in FIG. 28 assumes a situation in which the MTs of multiple child nodes are connected to the IAB node, for example, the MT of the first child node and the MT of the second child node.

[0315] Referring to FIG. 28, the IAB node determines whether the difference between the first uplink reception timing for the MT of the first child node and the second uplink reception timing for the MT of the second child node is less than or equal to a specific value (S2810).

[0316] As a result of the above determination, if the difference between the first uplink reception timing and the second uplink reception timing is less than or equal to a specific value, the IAB node receives both the signal of the MT of the first child node and the signal of the MT of the second child node within the same time resource (S2820). Here, the IAB node can manage the MT of the first child node and the MT of the second child node as the same child node MT group.

[0317] On the other hand, if, as a result of the above judgment, the difference between the first uplink reception timing and the second uplink reception timing is greater than the specific value, the IAB node receives the signal of the MT of the first child node and the signal of the MT of the second child node through each of the different time resources (S2830). For example, when there is a resource that is time domain multiplexed (TDM) and a second time resource, the IAB node can receive the signal of the MT of the first child node from the first time resource and receive the signal of the MT of the second child node from the second time resource. Here, the IAB node can manage the MT of the first child node and the MT of the second child node as different child node MT groups. For example, the MT of the first child node can be managed as belonging to the first group, and the MT of the second child node can be managed as belonging to the second group. In addition, the IAB node can set an independent TA (timing advance) value for each group (i.e., the MT group of the child node).

[0318] In addition, the specific value here may be set by the network (e.g., set by the donor node of the IAB node via an RRC message or DCI) or may be a predetermined value.

[0319] The proposals of this specification will be explained in more detail below.

[0320] The DU of an IAB node can receive uplink signals transmitted by child links having the same or similar uplink reception timing using the same time resources. However, if there is a significant difference in the uplink reception timing between uplink signals transmitted by different child links, the IAB node may not be able to successfully receive all uplink signals.

[0321] FIG. 29 illustrates an example of a timing difference between an IAB node and multiple child links. FIG. 30 illustrates another example of a timing difference between an IAB node and multiple child links.

[0322] FIGS. 29 and 30 assume a case where the DU of an IAB node is connected to the MT of a first child node and the MT of a second child node via a child link. In FIGS. 29 and 30, the MT of the first child node is denoted as child MT1, the MT of the second child node is denoted as child MT2, and the DU of the IAB node is denoted as DU.

[0323] Referring to FIG. 29, if the uplink reception timing of the MT of the first child node and the MT of the second child node match each other, or if the difference between the uplink reception timings is less than a certain value, the IAB node DU can receive both uplink signals. On the other hand, referring to FIG. 30, if the difference between the uplink reception timing of the MT of the first child node and the MT of the second child node is greater than a certain value, the IAB node DU may not be able to receive both uplink signals.

[0324] Therefore, it may be desirable for the IAB node DU to simultaneously receive uplink signals from child links whose uplink reception timings match each other or whose difference in uplink reception timing is less than or equal to a specific value, and to receive uplink signals from child links whose difference in uplink reception timing is greater than a specific value through different time resources.

[0325] Hereinafter, the MT operation of an IAB node having multiple transmission timings is described. Here, the MT operation of the IAB node having multiple transmission timings includes an MT operation in which multiple transmission timings are applied to a single serving cell.

[0326] IAB nodes can use a different DU / MT transmit / receive timing alignment method than legacy IAB nodes. For example, while legacy IAB nodes perform timing alignment using timing alignment case 1, enhanced IAB nodes can perform timing alignment using timing alignment case 6 or 7.

[0327] In order for an IAB node to apply timing alignment case 6 or 7, it must receive a configuration from the parent node's DU / CU (centralized unit) to apply the corresponding timing alignment case, and, if necessary, receive additional information to apply the timing alignment case. In such cases, the IAB node may operate by assuming a default timing alignment case when initially connecting to the parent node's DU or when it is determined that RRC settings, etc., are invalid. Here, for example, this default timing alignment case may be timing alignment case 1. In such cases, depending on the situation, the uplink transmission timing at which the IAB node's MT performs uplink transmission to the parent node's DU may be applied differently.

[0328] As previously described regarding the operation of the DU of an IAB node with multiple receive timings, from the perspective of the parent node's DU, not all child links may have the same uplink receive timing. The DU of the IAB node can receive uplink signals transmitted by child links having the same or similar uplink receive timings using the same time resources. On the other hand, if there is a significant difference in uplink receive timing between uplink signals transmitted by different child links, not all uplink signals may be successfully received.

[0329] Therefore, it is desirable for the DU of an IAB node to simultaneously receive uplink signals from child links whose uplink reception timings match or whose difference is less than or equal to a specific value, and to receive uplink signals from child links whose uplink reception timing difference is greater than that specific value through different time resources. In this case, the DU of the IAB node can group the MTs of the child nodes to receive uplink channels / signals from child links whose uplink reception timings match or whose difference is less than or equal to a specific value through the same time resource, and to have the MTs of other child nodes—that is, those with uplink reception timings that differ from the specific value—transmit uplink channels / signals through different time resources. In other words, from the perspective of a specific parent node's DU, multiple uplink reception timings exist, and a specific uplink reception timing may be applied at a specific time resource. For example, the DU of an IAB node may perform an uplink reception operation by applying uplink reception timing 1 in time resource group 1, and an uplink reception operation by applying uplink reception timing 2 in time resource group 2. In this case, when the MT of a child node transmits an uplink signal to the DU of the IAB node by applying a specific uplink transmission timing, it may need to perform uplink transmission only within a specific time resource group. If the MT of the child node intends to perform uplink transmission through other time resource groups as well, it may need to perform uplink transmission in accordance with the uplink reception timing applied by the DU of the IAB node in those time resource groups. In such cases, the MT of the child node may perform uplink transmission by applying different uplink transmission timings depending on the time resource.

[0330] As mentioned above, uplink transmission can be performed by applying different uplink transmission timings depending on the situation / time from the perspective of the MT of a specific IAB node. That is, the MT of the IAB node sets its uplink transmission timing as (downlink reception timing - (TA + TA offset When configured as )) or (downlink reception timing - TA), the MT of the IAB node has multiple TA values ​​and can perform uplink transmission by applying different TA values ​​depending on the situation / time.

[0331] In this specification, a specific method is proposed for performing uplink transmission in which the MT of an IAB node has multiple (e.g., two) TA values ​​and applies different TA values ​​depending on the situation / time.

[0332] Meanwhile, in this specification, TA can be extended to be interpreted as a parameter that determines the transmission or reception timing of an IAB node.

[0333] First, we will explain the types of parameters that determine the TA or transmit / receive timing applied by the MT of the IAB node.

[0334] The parameters for determining the TA or transmit / receive timing applied to determine / determine one's own uplink transmission timing from the perspective of the MT of a specific IAB node may include a default TA (or default parameter) and a dedicated TA or dedicated parameter.

[0335] The default TA may refer to the corresponding TA value when an IAB node sets uplink transmission timing, such as with a legacy IAB node or terminal. Alternatively, it may refer to the TA value set to match the reception timing of uplink signals received from the connected terminal / legacy IAB node's MT from the perspective of the parent node's DU. In this case, if MTs of different child nodes perform uplink transmission using their own default TAs, the uplink transmissions sent by the child nodes' MTs can be received at the same timing from the perspective of the IAB node's DU.

[0336] A dedicated TA may refer to a TA value that corresponds to when an IAB node sets uplink transmission timing differently from that of a legacy IAB node or terminal. Alternatively, it may refer to a TA value that is set to match an uplink reception timing different from the reception timing of the uplink signal received from the connected terminal / legacy IAB node's MT from the perspective of the parent node's DU. In this case, if MTs of different child nodes perform uplink transmission using their own dedicated TAs, the uplink transmissions sent by the child nodes' MTs may be received at the same or different timings from the perspective of the IAB node's DU.

[0337] These default TAs and dedicated TAs can be configured independently, for example, through MAC CE (medium access control control element). In this case, from the perspective of the MT of the IAB node, existing TA configurations are performed based on the default TA, and additional dedicated TAs can be configured.

[0338] Characteristically, multiple dedicated TAs can be configured for the MT of a single IAB node. In this case, one dedicated TA may be applied at a specific uplink transmission time.

[0339] Next, we will explain how to apply TA during the uplink transmission of the MT of the IAB node.

[0340] It is proposed that the MT of the IAB node perform uplink transmission by applying a default TA and a dedicated TA as follows. To determine the TA value used by the MT of the IAB node, one or more of the following may be applied. In the following, the default TA and the dedicated TA may be interpreted as being replaced by TA1 and TA2, which are TA values ​​that may have different values. Alternatively, in the following, the default TA may be interpreted as a default parameter used when the IAB node sets uplink transmission timing like a legacy IAB node or terminal, and the dedicated TA may be interpreted as a dedicated parameter used when the IAB node sets uplink transmission timing in a different way than a legacy IAB node or terminal.

[0341] (Method 1-1) The MT of the IAB node performs uplink transmission using the default TA until it initially connects to the DU / cell and receives a dedicated TA value. After receiving the dedicated TA value, it can perform uplink transmission using that dedicated TA value.

[0342] When the MT of the IAB node is in the RRC_INACTIVE and / or RRC_IDLE state, it is determined that the dedicated TA value is invalid, and uplink transmission can be performed by applying the default TA value. When transitioning from the RRC_INACTIVE and / or RRC_IDLE state to the RRC_CONNECTED state, a) uplink transmission can be performed immediately using the most recent dedicated TA value, or b) uplink transmission can be performed using the default TA value until a new dedicated TA value is set. Alternatively, when transitioning from the RRC_INACTIVE state to the RRC_CONNECTED state, uplink transmission can be performed immediately using the most recent dedicated TA value, and when transitioning from the RRC_IDLE state to the RRC_CONNECTED state, uplink transmission can be performed using the default TA value until a new dedicated TA value is set.

[0343] (Method 1-2) The TA value applied by the MT of the IAB node may differ depending on the type of channel / signal performing uplink transmission.

[0344] The DU of the parent node may manage the default TA value of the MT of the IAB node, so that the transmission of a specific uplink signal may be performed using the default TA. The MT of the IAB node performs uplink transmission by applying a dedicated TA value, but the transmission of a specific uplink signal / channel may be performed using the default TA. For example, the MT of the IAB node performs uplink transmission by applying a dedicated TA value, but exceptionally, the transmission of the SRS (sounding reference signal) may be performed using the default TA.

[0345] Alternatively, in the case of semi-static uplink signals / channels transmitted via RRC (e.g., SRS, SR (scheduling request), SPS-PUSCH (semi-persistent scheduling-physical uplink shared channel), PRACH (physical random access channel)), a default TA may be applied for transmission, and in the case of uplink signals / channels transmitted via dynamic scheduling by DCI, etc., a dedicated TA may be applied for transmission.

[0346] Characteristically, when setting up the transmission of a semi-static uplink signal / channel to an IAB node via RRC, TA information applicable to the IAB node can be set together. For example, when setting up the transmission of a semi-static uplink signal / channel to an IAB node via RRC, whether to perform the transmission using a default TA or to perform the transmission using a dedicated TA value can be set together to the IAB node.

[0347] (Method 1-3) TA information applicable to uplink transmissions can be indicated via the DCI. For example, the DCI may include a field indicating whether to perform the transmission using a default TA or a dedicated TA value. The MT of the IAB node receives the DCI and can apply the TA information indicated by the DCI when performing an uplink transmission scheduled by that DCI. If such TA information is included in the uplink grant, the MT of the IAB node can apply the corresponding TA value when transmitting the scheduled PUSCH. Conversely, if such TA information is included in the downlink grant, the MT of the IAB node can apply the corresponding TA value when transmitting the PUCCH containing ACK / NACK (acknowledgement / negative-acknowledgement) information for the scheduled PDSCH.

[0348] (Method 1-4) Depending on the type of DCI received by the MT of the IAB node, the TA value applied to the uplink transmission may differ.

[0349] The TA value applied may differ depending on whether the DCI received by the MT of the IAB node is a fallback DCI (i.e., DCI format 0_0, DCI format 1_0, etc.) or a non-fallback DCI (i.e., DCI format 0_1, DCI format 1_1). If the MT of the IAB node receives a fallback DCI, a default TA value may be applied to the related uplink transmissions (e.g., PUSCH and PUCCH). On the other hand, if the MT of the IAB node receives a non-fallback DCI, a dedicated TA value may be applied to the related uplink transmissions (e.g., PUSCH and PUCCH).

[0350] (Method 1-5) The TA value applied to uplink transmission may differ depending on the resource to which the DCI received by the MT of the IAB node is transmitted.

[0351] The TA value applied to uplink transmissions may differ depending on the CORESET where the DCI received by the MT of the IAB node is located. For example, for a DCI transmitted through a search space connected to CORESET 1, a default TA value may be applied to the related uplink transmissions (PUSCH and PUCCH), and for a DCI transmitted through a search space connected to CORESET 2, a dedicated TA value may be applied to the related uplink transmissions (PUSCH and PUCCH).

[0352] Alternatively, the TA value applied to the uplink transfer may differ depending on the search space where the DCI received by the MT of the IAB node is located. For example, for a DCI transmitted through search space 1, a default TA value may be applied to the associated uplink transfer (PUSCH and PUCCH), and for a DCI transmitted through search space 2, a dedicated TA value may be applied to the associated uplink transfer. As another example, for a DCI transmitted to the common search space (CSS), a default TA value may be applied to the associated uplink transfer, and for a DCI transmitted to the UE-specific search space (USS), a dedicated TA value may be applied to the associated uplink transfer.

[0353] (Method 1-6) The TA value applied by the MT of the IAB node may differ depending on the time resources for performing uplink transmission.

[0354] The MT of the IAB node can receive information about time resources that operate as dedicated TAs from the DU of the parent node or from the CU / donor node. In this case, the MT of the IAB node can perform uplink transmissions as dedicated TAs on the configured time resources and perform uplink transmissions as default TAs on the remaining resources.

[0355] Alternatively, the MT of the IAB node may receive time resource information that operates as a default TA from the DU of the parent node or from the CU / donor node. In this case, the MT of the IAB node may perform uplink transmission as a default TA on the set time resource and perform uplink transmission as a dedicated TA on the remaining resources.

[0356] Alternatively, the MT of the IAB node may receive time resource information that operates as a default TA and time resource information that operates as a dedicated TA from the DU of the parent node or from the CU / donor node, respectively. In this case, the MT of the IAB node may perform uplink transmission as a default TA in the time resource that operates as a default TA, and perform uplink transmission as a dedicated TA in the time resource that operates as a dedicated TA.

[0357] Meanwhile, the above content may be extended and applied even when there are multiple types of TA values ​​that can be applied to the MT of the IAB node during uplink transmission. In this case, the TA values ​​may be applied differently to the MT of the IAB node during uplink transmission depending on the above method / conditions.

[0358] Meanwhile, in relation to the methods described above, the IAB node can receive DCI from its parent node and receive RRC signaling from the donor node.

[0359] Below, we will explain the priority between uplink transmissions transmitted using different TAs.

[0360] When the MT of an IAB node transmits different uplink transmissions using different TA values, the time resources of the two uplink transmissions may overlap. Alternatively, since a certain amount of time is consumed to change the TA value applied by the IAB node's MT, sufficient time to change the TA value may not be guaranteed even if the time resources of the different uplink transmissions do not overlap. For example, the IAB node's MT requires 2 symbols to change the TA value, but the PUSCH transmission symbol resources and SRS transmission symbol resources of the IAB node's MT may be located consecutively. In such cases, since the IAB node's MT cannot fully execute both uplink transmissions, it may prioritize the execution of one of the transmissions. A specific solution for this is proposed below.

[0361] (Method 2-1) Dynamic uplink transmission (e.g., dynamically scheduled uplink transmission via DCI) may take precedence over semi-static uplink transmission (e.g., uplink transmission configured semi-statically via RRC configuration).

[0362] (Method 2-2) The priority of uplink transmissions may be determined based on the time when information / signals / messages establishing uplink transmissions are received. For example, uplink transmissions that were scheduled / instructed more recently may take priority. Or, the opposite is also possible.

[0363] (Method 2-3) The priority of uplink transmissions may be determined based on when the uplink transmission is performed. For example, an uplink transmission scheduled to be transmitted earlier may have priority. Or, an uplink transmission scheduled to be transmitted later may have priority.

[0364] (Method 2-4) Priority may be determined based on the value of the TA applied to the uplink transmission. For example, an uplink transmission transmitted using the default TA may take precedence over an uplink transmission transmitted using the dedicated TA. Or, an uplink transmission transmitted using the dedicated TA may take precedence over an uplink transmission transmitted using the default TA.

[0365] Meanwhile, the statement in the above content that the first transmission takes precedence over the second transmission may mean the following.

[0366] (Example a) The MT of the IAB node may perform the first transmission and drop the second transmission so that it is not performed.

[0367] (Example b) The MT of the IAB node performs the first transmission, and does not perform the second transmission by puncturing the second transmission resource where the second transmission cannot be performed for the first transmission. The second transmission is performed on the second transmission resource where the second transmission resource can be performed.

[0368] Based on the aforementioned methods, the following behavior of the IAB node can be considered.

[0369] FIG. 31 is intended to illustrate an example of uplink transmission of an IAB node MT with multiple uplink transmission timings set according to a partial implementation of the present specification.

[0370] Referring to FIG. 31, the MT of the IAB node may be set with multiple uplink transmission timings. The multiple uplink transmission timings may be applied differently depending on the time resource or time interval. For example, if the MT of the IAB node is set with two uplink transmission timings (i.e., a first uplink transmission timing and a second uplink transmission timing), the MT of the IAB node may perform uplink transmission based on the first uplink transmission timing in the first time interval and perform uplink transmission based on the second uplink transmission timing in the second time interval. Here, for example, the first uplink transmission timing may be an uplink transmission timing based on timing alignment case 6, and the second uplink transmission timing may be an uplink transmission timing based on timing alignment case 1.

[0371] Meanwhile, in the example described above, the first time interval and the second time interval may be configured as follows.

[0372] For example, the first time interval may be a time resource capable of performing simultaneous transmission between the DU and MT of the IAB node. Additionally, the second time interval may be a resource in which simultaneous transmission between the DU and MT of the IAB node cannot be performed (for example, a resource in which the DU and MT of the IAB node can only perform TDM-based operations, and a time resource configured to perform transmission operations for the MT of the IAB node).

[0373] As another example, the second time interval may be a resource for transmitting SRS, SR and / or PRACH. Additionally, the first time interval may be a time resource configured so that the signal / channel is not transmitted.

[0374] According to the operation described above, the IAB node can perform a transmission operation on a time resource where the parent node of the IAB node can receive a signal transmitted by the IAB node based on a first uplink transmission timing, and on a time resource where the signal transmitted by the IAB node can be received based on a second uplink transmission timing. Additionally, according to the operation described above, since the first uplink transmission timing is a timing at which transmission is performed in accordance with the absolute reception timing of the DU of the parent node, the signal transmitted based on the first uplink transmission timing can be used for the DU of the parent node to determine a change in propagation delay with the IAB node and to adjust the transmission timing for the DU of the IAB node based on said change. Additionally, since the second uplink transmission timing is a timing determined in accordance with the transmission timing of the DU of the parent node, the reception timing of the DU of the parent node can be changed together with the transmission timing of the DU of the parent node and the change in propagation delay with the DU of the parent node. Signals transmitted based on this second uplink transmission timing may be difficult for the DU of the parent node to accurately determine changes in propagation delay with the IAB node, and may not be relatively suitable for use in adjusting the transmission timing of the DU of the IAB node.

[0375] Meanwhile, the operation of the aforementioned IAB node is merely one embodiment according to a partial implementation of this specification, and it is obvious that various methods / configurations proposed in this specification may be implemented.

[0376] FIG. 32 is a flowchart for an example of a signal transmission method of an IAB node according to a partial implementation of the present specification.

[0377] Referring to FIG. 32, the IAB node receives first information indicating a first timing and second information indicating a second timing (S3210).

[0378] Afterwards, the IAB node transmits a first signal and a second signal to the parent node of the IAB node (S3220).

[0379] Here, the first signal may be transmitted over a first resource, and the second signal may be transmitted over a second resource. Also, here, the first resource may be a time resource to which the first timing is applied, and the second resource may be a time resource to which the second timing is applied.

[0380] FIG. 33 is a flowchart for an example of a method for receiving a signal of an IAB node according to a partial implementation of the present specification.

[0381] Referring to FIG. 33, the IAB node transmits timing information to a child node of the IAB node (S3310). Here, the timing information may indicate a plurality of timings for the child node to transmit to the IAB node.

[0382] Afterwards, the IAB node receives a first signal and a second signal from the child node (S3320).

[0383] Here, each of the first signal and the second signal may be transmitted based on different timings among the plurality of timings. Also, here, the timing information may be transmitted via DCI.

[0384] Meanwhile, since it is obvious that the various methods / configurations proposed in this specification can be extended to the example of FIG. 33, redundant descriptions are omitted.

[0385] The claims described in this specification may be combined in various ways. For example, the technical features of the method claims in this specification may be combined to be implemented as a device, and the technical features of the device claims in this specification may be combined to be implemented as a method. Furthermore, the technical features of the method claims and the technical features of the device claims in this specification may be combined to be implemented as a device, and the technical features of the method claims and the technical features of the device claims in this specification may be combined to be implemented as a method.

[0386] The methods proposed herein may also be performed by an apparatus configured to control an IAB node, comprising, in addition to an IAB node, at least one computer-readable medium containing instructions based on execution by at least one processor, one or more processors, and one or more memories executablely connected by said one or more processors and storing the instructions, wherein said one or more processors execute said instructions to perform the methods proposed herein. Furthermore, according to the methods proposed herein, it is obvious that an operation by another IAB node corresponding to an operation performed by an IAB node may be considered.

[0387] Hereinafter, an example of a communication system to which the present disclosure applies is described.

[0388] Although not limited thereto, the various descriptions, functions, procedures, proposals, methods, and / or flowcharts of the disclosure disclosed in this document may be applied to various fields requiring wireless communication / connection (e.g., 5G) between devices.

[0389] Examples are provided in more detail below with reference to the drawings. In the following drawings and descriptions, the same reference numerals may represent the same or corresponding hardware blocks, software blocks, or function blocks unless otherwise described.

[0390] FIG. 34 illustrates a communication system (1) to which the present disclosure applies.

[0391] Referring to FIG. 34, the communication system (1) to which the present disclosure applies includes a wireless device, a base station, and a network. Here, the wireless device refers to a device that performs communication using wireless access technology (e.g., 5G NR (New RAT), LTE (Long Term Evolution)) and may be referred to as a communication / wireless / 5G device. Although not limited thereto, the wireless device may include a robot (100a), a vehicle (100b-1, 100b-2), an XR (eXtended Reality) device (100c), a hand-held device (100d), a home appliance (100e), an IoT (Internet of Thing) device (100f), and an AI device / server (400). For example, the vehicle may include a vehicle equipped with wireless communication capabilities, an autonomous vehicle, a vehicle capable of performing inter-vehicle communication, etc. Here, the vehicle may include an Unmanned Aerial Vehicle (UAV) (e.g., a drone). XR devices include AR (Augmented Reality) / VR (Virtual Reality) / MR (Mixed Reality) devices and can be implemented in the form of HMDs (Head-Mounted Devices), HUDs (Head-Up Displays) equipped in vehicles, televisions, smartphones, computers, wearable devices, home appliances, digital signage, vehicles, robots, etc. Portable devices may include smartphones, smartpads, wearable devices (e.g., smartwatches, smart glasses), computers (e.g., laptops, etc.). Home appliances may include TVs, refrigerators, washing machines, etc. IoT devices may include sensors, smart meters, etc. For example, base stations and networks may be implemented as wireless devices, and a specific wireless device (200a) may operate as a base station / network node to other wireless devices.

[0392] Here, the wireless communication technology implemented in the wireless device of this specification may include LTE, NR, and 6G, as well as Narrowband Internet of Things for low-power communication. For example, NB-IoT technology may be an example of LPWAN (Low Power Wide Area Network) technology and may be implemented according to standards such as LTE Cat NB1 and / or LTE Cat NB2, but is not limited to the names mentioned above. Additionally, or generally, the wireless communication technology implemented in the wireless device of this specification may perform communication based on LTE-M technology. For example, LTE-M technology may be an example of LPWAN technology and may be referred to by various names such as eMTC (enhanced Machine Type Communication). For example, LTE-M technology may be implemented in at least one of various standards such as 1) LTE CAT 0, 2) LTE Cat M1, 3) LTE Cat M2, 4) LTE non-BL (non-Bandwidth Limited), 5) LTE-MTC, 6) LTE Machine Type Communication, and / or 7) LTE M, and is not limited to the names mentioned above. Additionally or generally, wireless communication technology implemented in the wireless device of this specification may include at least one of ZigBee, Bluetooth, and Low Power Wide Area Network (LPWAN) for low-power communication, and is not limited to the names mentioned above. As an example, ZigBee technology can create personal area networks (PANs) related to small / low-power digital communication based on various standards such as IEEE 802.15.4, and may be referred to by various names.

[0393] Wireless devices (100a to 100f) can be connected to a network (300) through a base station (200). Artificial Intelligence (AI) technology may be applied to the wireless devices (100a to 100f), and the wireless devices (100a to 100f) can be connected to an AI server (400) through the network (300). The network (300) can be configured using a 3G network, a 4G (e.g., LTE) network, or a 5G (e.g., NR) network. The wireless devices (100a to 100f) may communicate with each other through the base station (200) / network (300), but they may also communicate directly (e.g., sidelink communication) without going through the base station / network. For example, vehicles (100b-1, 100b-2) can communicate directly (e.g., V2V (Vehicle to Vehicle) / V2X (Vehicle to everything) communication). Also, IoT devices (e.g., sensors) can communicate directly with other IoT devices (e.g., sensors) or other wireless devices (100a to 100f).

[0394] Wireless communication / connection (150a, 150b, 150c) can be established between wireless devices (100a~100f) / base station (200) and base station (200) / base station (200). Here, wireless communication / connection can be achieved through various wireless access technologies (e.g., 5G NR), such as uplink / downlink communication (150a), sidelink communication (150b) (or D2D communication), and inter-base station communication (150c) (e.g., relay, IAB (Integrated Access Backhaul)). Through wireless communication / connection (150a, 150b, 150c), wireless devices and base stations / wireless devices, and base stations and base stations can transmit / receive wireless signals to / from each other. For example, wireless communication / connection (150a, 150b, 150c) can transmit / receive signals through various physical channels. To this end, based on various proposals of the present disclosure, at least some of the following may be performed: various configuration information setting processes for transmitting / receiving wireless signals, various signal processing processes (e.g., channel encoding / decoding, modulation / demodulation, resource mapping / demapping, etc.), resource allocation processes, etc.

[0395] FIG. 35 illustrates a wireless device that can be applied to the present disclosure.

[0396] Referring to FIG. 35, the first wireless device (100) and the second wireless device (200) can transmit and receive wireless signals through various wireless access technologies (e.g., LTE, NR). Here, {the first wireless device (100), the second wireless device (200)} may correspond to {wireless device (100x), base station (200)} and / or {wireless device (100x), wireless device (100x)} of FIG. 34.

[0397] The first wireless device (100) includes one or more processors (102) and one or more memories (104), and may additionally include one or more transceivers (106) and / or one or more antennas (108). The processor (102) controls the memory (104) and / or transceivers (106) and may be configured to implement the descriptions, functions, procedures, proposals, methods and / or flowcharts of operation disclosed in this document. For example, the processor (102) may process information within the memory (104) to generate a first information / signal and then transmit a wireless signal containing the first information / signal through the transceiver (106). Additionally, the processor (102) may receive a wireless signal containing a second information / signal through the transceiver (106) and then store information obtained from the signal processing of the second information / signal in the memory (104). The memory (104) may be connected to the processor (102) and may store various information related to the operation of the processor (102). For example, the memory (104) may store software code containing instructions for performing some or all of the processes controlled by the processor (102) or for performing the descriptions, functions, procedures, proposals, methods, and / or operation sequence diagrams disclosed in this document. Here, the processor (102) and the memory (104) may be part of a communication modem / circuit / chip designed to implement wireless communication technology (e.g., LTE, NR). The transceiver (106) may be connected to the processor (102) and may transmit and / or receive wireless signals through one or more antennas (108). The transceiver (106) may include a transmitter and / or receiver. The transceiver (106) may be combined with an RF (Radio Frequency) unit. In the present disclosure, a wireless device may refer to a communication modem / circuit / chip.

[0398] The second wireless device (200) includes one or more processors (202) and one or more memories (204), and may additionally include one or more transceivers (206) and / or one or more antennas (208). The processor (202) controls the memory (204) and / or transceivers (206) and may be configured to implement the descriptions, functions, procedures, proposals, methods and / or operation sequences disclosed in this document. For example, the processor (202) may process information within the memory (204) to generate a third information / signal and then transmit a wireless signal containing the third information / signal through the transceiver (206). Additionally, the processor (202) may receive a wireless signal containing a fourth information / signal through the transceiver (206) and then store information obtained from the signal processing of the fourth information / signal in the memory (204). Memory (204) may be connected to the processor (202) and may store various information related to the operation of the processor (202). For example, memory (204) may store software code containing instructions for performing some or all of the processes controlled by the processor (202) or for performing the descriptions, functions, procedures, proposals, methods, and / or flowcharts of operation disclosed in this document. Here, the processor (202) and memory (204) may be part of a communication modem / circuit / chip designed to implement wireless communication technology (e.g., LTE, NR). A transceiver (206) may be connected to the processor (202) and may transmit and / or receive wireless signals through one or more antennas (208). The transceiver (206) may include a transmitter and / or receiver. The transceiver (206) may be interchangeable with an RF unit. In this disclosure, a wireless device may refer to a communication modem / circuit / chip.

[0399] Hereinafter, hardware elements of the wireless device (100, 200) will be described in more detail. Although not limited thereto, one or more protocol layers may be implemented by one or more processors (102, 202). For example, one or more processors (102, 202) may implement one or more layers (e.g., functional layers such as PHY, MAC, RLC, PDCP, RRC, SDAP). One or more processors (102, 202) may generate one or more Protocol Data Units (PDUs) and / or Service Data Units (SDUs) according to the descriptions, functions, procedures, proposals, methods, and / or flowcharts of operation disclosed in this document. One or more processors (102, 202) may generate messages, control information, data, or information according to the descriptions, functions, procedures, proposals, methods, and / or flowcharts of operation disclosed in this document. One or more processors (102, 202) may generate a signal (e.g., baseband signal) containing a PDU, SDU, message, control information, data, or information according to the functions, procedures, proposals, and / or methods disclosed in this document and provide it to one or more transceivers (106, 206). One or more processors (102, 202) may receive a signal (e.g., baseband signal) from one or more transceivers (106, 206) and may obtain a PDU, SDU, message, control information, data, or information according to the descriptions, functions, procedures, proposals, methods, and / or flowcharts disclosed in this document.

[0400] One or more processors (102, 202) may be referred to as a controller, microcontroller, microprocessor, or microcomputer. One or more processors (102, 202) may be implemented by hardware, firmware, software, or a combination thereof. For example, one or more Application Specific Integrated Circuits (ASICs), one or more Digital Signal Processors (DSPs), one or more Digital Signal Processing Devices (DSPDs), one or more Programmable Logic Devices (PLDs), or one or more Field Programmable Gate Arrays (FPGAs) may be included in one or more processors (102, 202). The descriptions, functions, procedures, proposals, methods, and / or flowcharts disclosed in this document may be implemented using firmware or software, and the firmware or software may be implemented to include modules, procedures, functions, etc. Firmware or software configured to perform the descriptions, functions, procedures, proposals, methods, and / or operation sequences disclosed in this document may be contained in one or more processors (102, 202) or stored in one or more memories (104, 204) and driven by one or more processors (102, 202). The descriptions, functions, procedures, proposals, methods, and / or operation sequences disclosed in this document may be implemented using firmware or software in the form of code, instructions, and / or sets of instructions.

[0401] One or more memories (104, 204) may be connected to one or more processors (102, 202) and may store various forms of data, signals, messages, information, programs, code, instructions, and / or commands. One or more memories (104, 204) may be composed of ROM, RAM, EPROM, flash memory, hard drive, registers, cache memory, computer read storage media, and / or combinations thereof. One or more memories (104, 204) may be located inside and / or outside of one or more processors (102, 202). Additionally, one or more memories (104, 204) may be connected to one or more processors (102, 202) through various technologies such as wired or wireless connections.

[0402] One or more transceivers (106, 206) may transmit user data, control information, wireless signals / channels, etc., as mentioned in the methods and / or operation flowcharts, etc., of this document to one or more other devices. One or more transceivers (106, 206) may receive user data, control information, wireless signals / channels, etc., as mentioned in the descriptions, functions, procedures, proposals, methods and / or operation flowcharts, etc., disclosed in this document from one or more other devices. For example, one or more transceivers (106, 206) may be connected to one or more processors (102, 202) and may transmit and receive wireless signals. For example, one or more processors (102, 202) may control one or more transceivers (106, 206) to transmit user data, control information, or wireless signals to one or more other devices. Additionally, one or more processors (102, 202) may control one or more transceivers (106, 206) to receive user data, control information, or wireless signals from one or more other devices. Additionally, one or more transceivers (106, 206) may be connected to one or more antennas (108, 208), and one or more transceivers (106, 206) may be configured to transmit and receive user data, control information, wireless signals / channels, etc., as described in the descriptions, functions, procedures, proposals, methods, and / or flowcharts of operation disclosed in this document through one or more antennas (108, 208). In this document, one or more antennas may be multiple physical antennas or multiple logical antennas (e.g., antenna ports). One or more transceivers (106, 206) can convert the received wireless signal / channel, etc. from an RF band signal to a baseband signal in order to process the received user data, control information, wireless signal / channel, etc. using one or more processors (102, 202).One or more transceivers (106, 206) can convert user data, control information, wireless signals / channels, etc. processed using one or more processors (102, 202) from baseband signals to RF band signals. To this end, one or more transceivers (106, 206) may include (analog) oscillators and / or filters.

[0403] FIG. 36 illustrates a signal processing circuit for a transmission signal.

[0404] Referring to FIG. 36, the signal processing circuit (1000) may include a scrambler (1010), a modulator (1020), a layer mapper (1030), a precoder (1040), a resource mapper (1050), and a signal generator (1060). Although not limited thereto, the operation / function of FIG. 36 may be performed in the processor (102, 202) and / or transceiver (106, 206) of FIG. 35. The hardware elements of FIG. 36 may be implemented in the processor (102, 202) and / or transceiver (106, 206) of FIG. 35. For example, blocks 1010 through 1060 may be implemented in the processor (102, 202) of FIG. 35. Additionally, blocks 1010 to 1050 may be implemented in the processor (102, 202) of FIG. 35, and block 1060 may be implemented in the transceiver (106, 206) of FIG. 35.

[0405] The codeword can be converted into a wireless signal through the signal processing circuit (1000) of FIG. 36. Here, the codeword is an encoded bit sequence of an information block. The information block may include a transmission block (e.g., UL-SCH transmission block, DL-SCH transmission block). The wireless signal can be transmitted through various physical channels (e.g., PUSCH, PDSCH).

[0406] Specifically, a codeword can be converted into a scrambled bit sequence by a scrambler (1010). The scrambled sequence used for scrambling is generated based on an initialization value, which may include ID information of a wireless device, etc. The scrambled bit sequence can be modulated into a modulation symbol sequence by a modulator (1020). The modulation method may include pi / 2-BPSK (pi / 2-Binary Phase Shift Keying), m-PSK (m-Phase Shift Keying), m-QAM (m-Quadrature Amplitude Modulation), etc. The complex modulation symbol sequence can be mapped to one or more transmission layers by a layer mapper (1030). The modulation symbols of each transmission layer can be mapped to the corresponding antenna port(s) by a precoder (1040) (precoding). The output z of the precoder (1040) can be obtained by multiplying the output y of the layer mapper (1030) by an N*M precoding matrix W. Here, N is the number of antenna ports and M is the number of transmission layers. Here, the precoder (1040) can perform precoding after performing transform precoding (e.g., DFT transform) on the complex modulation symbols. Additionally, the precoder (1040) can perform precoding without performing transform precoding.

[0407] A resource mapper (1050) can map the modulation symbols of each antenna port to a time-frequency resource. The time-frequency resource may include multiple symbols (e.g., CP-OFDMA symbols, DFT-s-OFDMA symbols) in the time domain and multiple subcarriers in the frequency domain. A signal generator (1060) generates a radio signal from the mapped modulation symbols, and the generated radio signal can be transmitted to another device through each antenna. To this end, the signal generator (1060) may include an Inverse Fast Fourier Transform (IFFT) module, a Cyclic Prefix (CP) inserter, a Digital-to-Analog Converter (DAC), a frequency uplink converter, etc.

[0408] The signal processing process for a received signal in a wireless device can be configured as the inverse of the signal processing process (1010–1060) of FIG. 36. For example, a wireless device (e.g., 100, 200 in FIG. 35) can receive a wireless signal from the outside through an antenna port / transceiver. The received wireless signal can be converted into a baseband signal through a signal restorer. To this end, the signal restorer may include a frequency downlink converter, an analog-to-digital converter (ADC), a CP remover, and a Fast Fourier Transform (FFT) module. Subsequently, the baseband signal can be restored into a codeword through a resource de-mapper process, a postcoding process, a demodulation process, and a de-scrambling process. The codeword can be restored into the original information block through decoding. Accordingly, a signal processing circuit (not shown) for a received signal may include a signal restorer, a resource de-mapper, a postcoder, a demodulator, a de-scrambler, and a decoder.

[0409] FIG. 37 illustrates another example of a wireless device to which the present disclosure applies. The wireless device may be implemented in various forms depending on the use—example / service (see FIG. 34).

[0410] Referring to FIG. 37, the wireless device (100, 200) corresponds to the wireless device (100, 200) of FIG. 35 and may be composed of various elements, components, units / parts, and / or modules. For example, the wireless device (100, 200) may include a communication unit (110), a control unit (120), a memory unit (130), and additional elements (140). The communication unit may include a communication circuit (112) and transceiver(s) (114). For example, the communication circuit (112) may include one or more processors (102, 202) and / or one or more memories (104, 204) of FIG. 35. For example, the transceiver(s) (114) may include one or more transceivers (106, 206) and / or one or more antennas (108, 208) of FIG. 35. The control unit (120) is electrically connected to the communication unit (110), the memory unit (130), and additional elements (140) and controls the general operation of the wireless device. For example, the control unit (120) may control the electrical / mechanical operation of the wireless device based on a program / code / command / information stored in the memory unit (130). Additionally, the control unit (120) may transmit information stored in the memory unit (130) to an external (e.g., another communication device) via a wireless / wired interface through the communication unit (110), or store information received from an external (e.g., another communication device) via a wireless / wired interface through the communication unit (110) in the memory unit (130).

[0411] The additional element (140) can be configured in various ways depending on the type of wireless device. For example, the additional element (140) may include at least one of a power unit / battery, an input / output unit (I / O unit), a driving unit, and a computing unit. Although not limited thereto, the wireless device may be implemented in the form of a robot (Fig. 34, 100a), a vehicle (Fig. 34, 100b-1, 100b-2), an XR device (Fig. 34, 100c), a portable device (Fig. 34, 100d), a home appliance (Fig. 34, 100e), an IoT device (Fig. 34, 100f), a digital broadcasting terminal, a hologram device, a public safety device, an MTC device, a medical device, a fintech device (or financial device), a security device, a climate / environment device, an AI server / device (Fig. 34, 400), a base station (Fig. 34, 200), a network node, etc. Wireless devices can be used in a movable or fixed location depending on the use—e.g., service.

[0412] In FIG. 37, various elements, components, units / parts, and / or modules within the wireless device (100, 200) may be entirely interconnected via a wired interface, or at least partially connected via a communication unit (110). For example, within the wireless device (100, 200), the control unit (120) and the communication unit (110) may be connected via a wire, and the control unit (120) and the first unit (e.g., 130, 140) may be connected wirelessly via the communication unit (110). Additionally, each element, component, unit / part, and / or module within the wireless device (100, 200) may include one or more additional elements. For example, the control unit (120) may be composed of one or more sets of processors. For example, the control unit (120) may be composed of a set of a communication control processor, an application processor, an Electronic Control Unit (ECU), a graphics processing processor, a memory control processor, etc. As another example, the memory unit (130) may be composed of RAM (Random Access Memory), DRAM (Dynamic RAM), ROM (Read Only Memory), flash memory, volatile memory, non-volatile memory and / or a combination thereof.

[0413] Hereinafter, an implementation example of FIG. 37 will be described in more detail with reference to the drawings.

[0414] FIG. 38 illustrates a portable device to which the present disclosure applies. The portable device may include a smartphone, a smartpad, a wearable device (e.g., a smartwatch, smart glasses), a portable computer (e.g., a laptop, etc.). The portable device may be referred to as an MS (Mobile Station), UT (user terminal), MSS (Mobile Subscriber Station), SS (Subscriber Station), AMS (Advanced Mobile Station), or WT (Wireless terminal).

[0415] Referring to FIG. 38, the portable device (100) may include an antenna unit (108), a communication unit (110), a control unit (120), a memory unit (130), a power supply unit (140a), an interface unit (140b), and an input / output unit (140c). The antenna unit (108) may be configured as part of the communication unit (110). Blocks 110 to 130 / 140a to 140c each correspond to blocks 110 to 130 / 140 of FIG. 37.

[0416] The communication unit (110) can transmit and receive signals (e.g., data, control signals, etc.) with other wireless devices and base stations. The control unit (120) can control the components of the portable device (100) to perform various operations. The control unit (120) may include an AP (Application Processor). The memory unit (130) can store data / parameters / programs / code / commands required for the operation of the portable device (100). Additionally, the memory unit (130) can store input / output data / information, etc. The power supply unit (140a) supplies power to the portable device (100) and may include wired / wireless charging circuits, batteries, etc. The interface unit (140b) can support the connection between the portable device (100) and other external devices. The interface unit (140b) may include various ports (e.g., audio input / output ports, video input / output ports) for connection with external devices. The input / output unit (140c) can receive or output video information / signals, audio information / signals, data, and / or information input from a user. The input / output unit (140c) may include a camera, a microphone, a user input unit, a display unit (140d), a speaker and / or a haptic module, etc.

[0417] For example, in the case of data communication, the input / output unit (140c) acquires information / signals (e.g., touch, text, voice, image, video) input from the user, and the acquired information / signals can be stored in the memory unit (130). The communication unit (110) converts the information / signals stored in the memory into wireless signals and can directly transmit the converted wireless signals to another wireless device or to a base station. Additionally, the communication unit (110) can receive wireless signals from another wireless device or base station and then restore the received wireless signals to their original information / signals. The restored information / signals can be stored in the memory unit (130) and then output in various forms (e.g., text, voice, image, video, haptic) through the input / output unit (140c).

[0418] FIG. 39 illustrates a vehicle or autonomous vehicle to which the present disclosure applies. The vehicle or autonomous vehicle may be implemented as a mobile robot, vehicle, train, manned or unmanned aerial vehicle (AV), ship, etc.

[0419] Referring to FIG. 39, a vehicle or autonomous vehicle (100) may include an antenna unit (108), a communication unit (110), a control unit (120), a driving unit (140a), a power supply unit (140b), a sensor unit (140c), and an autonomous driving unit (140d). The antenna unit (108) may be configured as part of the communication unit (110). Blocks 110 / 130 / 140a to 140d correspond to blocks 110 / 130 / 140 of FIG. 37, respectively.

[0420] The communication unit (110) can transmit and receive signals (e.g., data, control signals, etc.) with external devices such as other vehicles, base stations (e.g., base stations, roadside base stations (Roadside units), etc.), and servers. The control unit (120) can perform various operations by controlling elements of the vehicle or autonomous vehicle (100). The control unit (120) may include an Electronic Control Unit (ECU). The driving unit (140a) can drive the vehicle or autonomous vehicle (100) on the ground. The driving unit (140a) may include an engine, motor, power train, wheels, brakes, steering device, etc. The power supply unit (140b) supplies power to the vehicle or autonomous vehicle (100) and may include wired / wireless charging circuits, batteries, etc. The sensor unit (140c) can obtain vehicle status, surrounding environment information, user information, etc. The sensor unit (140c) may include an IMU (inertial measurement unit) sensor, a collision sensor, a wheel sensor, a speed sensor, an inclination sensor, a weight detection sensor, a heading sensor, a position module, a vehicle forward / reverse sensor, a battery sensor, a fuel sensor, a tire sensor, a steering sensor, a temperature sensor, a humidity sensor, an ultrasonic sensor, an illuminance sensor, a pedal position sensor, etc. The autonomous driving unit (140d) may implement technologies such as maintaining the driving lane, technologies for automatically adjusting speed such as adaptive cruise control, technologies for automatically driving along a predetermined path, and technologies for automatically setting a path and driving when a destination is set.

[0421] For example, the communication unit (110) can receive map data, traffic information data, etc. from an external server. The autonomous driving unit (140d) can generate an autonomous driving path and a driving plan based on the acquired data. The control unit (120) can control the drive unit (140a) so that the vehicle or the autonomous vehicle (100) moves along the autonomous driving path according to the driving plan (e.g., speed / direction control). During autonomous driving, the communication unit (110) can acquire the latest traffic information data from an external server non-periodically and can acquire surrounding traffic information data from surrounding vehicles. Additionally, during autonomous driving, the sensor unit (140c) can acquire vehicle status and surrounding environment information. The autonomous driving unit (140d) can update the autonomous driving path and the driving plan based on the newly acquired data / information. The communication unit (110) can transmit information regarding the vehicle location, autonomous driving path, driving plan, etc. to an external server. An external server can predict traffic information data in advance using AI technology, etc., based on information collected from vehicles or autonomous vehicles, and can provide the predicted traffic information data to vehicles or autonomous vehicles.

[0422] FIG. 40 illustrates a vehicle to which the present disclosure applies. The vehicle may also be implemented as a means of transport, a train, an aircraft, a ship, etc.

[0423] Referring to FIG. 40, the vehicle (100) may include a communication unit (110), a control unit (120), a memory unit (130), an input / output unit (140a), and a position measurement unit (140b). Here, blocks 110 to 130 / 140a to 140b correspond to blocks 110 to 130 / 140 of FIG. 37, respectively.

[0424] The communication unit (110) can transmit and receive signals (e.g., data, control signals, etc.) with external devices such as other vehicles or base stations. The control unit (120) can control the components of the vehicle (100) to perform various operations. The memory unit (130) can store data / parameters / programs / codes / commands that support various functions of the vehicle (100). The input / output unit (140a) can output AR / VR objects based on information within the memory unit (130). The input / output unit (140a) may include a HUD. The position measurement unit (140b) can acquire position information of the vehicle (100). The position information may include absolute position information of the vehicle (100), position information within the driving line, acceleration information, position information relative to surrounding vehicles, etc. The position measurement unit (140b) may include GPS and various sensors.

[0425] For example, the communication unit (110) of the vehicle (100) can receive map information, traffic information, etc. from an external server and store it in the memory unit (130). The location measurement unit (140b) can acquire vehicle location information through GPS and various sensors and store it in the memory unit (130). The control unit (120) creates a virtual object based on map information, traffic information, and vehicle location information, etc., and the input / output unit (140a) can display the created virtual object on the glass window inside the vehicle (1410, 1420). In addition, the control unit (120) can determine whether the vehicle (100) is operating normally within the driving line based on the vehicle location information. If the vehicle (100) deviates abnormally from the driving line, the control unit (120) can display a warning on the glass window inside the vehicle through the input / output unit (140a). Additionally, the control unit (120) can broadcast a warning message regarding a driving abnormality to surrounding vehicles through the communication unit (110). Depending on the situation, the control unit (120) can transmit the vehicle's location information and information regarding the driving / vehicle abnormality to relevant authorities through the communication unit (110).

[0426] FIG. 41 illustrates an XR device to which the present disclosure applies. The XR device may be implemented as an HMD, a Head-Up Display (HUD) equipped in a vehicle, a television, a smartphone, a computer, a wearable device, a home appliance, digital signage, a vehicle, a robot, etc.

[0427] Referring to FIG. 41, the XR device (100a) may include a communication unit (110), a control unit (120), a memory unit (130), an input / output unit (140a), a sensor unit (140b), and a power supply unit (140c). Here, blocks 110 to 130 / 140a to 140c correspond to blocks 110 to 130 / 140 of FIG. 37, respectively.

[0428] The communication unit (110) can transmit and receive signals (e.g., media data, control signals, etc.) with external devices such as other wireless devices, mobile devices, or media servers. The media data may include video, images, sound, etc. The control unit (120) can perform various operations by controlling the components of the XR device (100a). For example, the control unit (120) may be configured to control and / or perform procedures such as video / image acquisition, (video / image) encoding, metadata generation, and processing. The memory unit (130) may store data / parameters / programs / codes / commands required for driving the XR device (100a) or creating an XR object. The input / output unit (140a) acquires control information, data, etc. from the outside and can output the created XR object. The input / output unit (140a) may include a camera, microphone, user input unit, display unit, speaker and / or haptic module, etc. The sensor unit (140b) can obtain XR device status, surrounding environment information, user information, etc. The sensor unit (140b) may include a proximity sensor, an illuminance sensor, an accelerometer, a magnetic sensor, a gyroscope, an inertial sensor, an RGB sensor, an IR sensor, a fingerprint recognition sensor, an ultrasonic sensor, a light sensor, a microphone and / or radar, etc. The power supply unit (140c) supplies power to the XR device (100a) and may include a wired / wireless charging circuit, a battery, etc.

[0429] For example, the memory unit (130) of the XR device (100a) may contain information (e.g., data, etc.) necessary for creating an XR object (e.g., AR / VR / MR object). The input / output unit (140a) may receive a command to operate the XR device (100a) from the user, and the control unit (120) may operate the XR device (100a) according to the user's operation command. For example, if the user intends to watch movies, news, etc. through the XR device (100a), the control unit (120) may transmit content request information to another device (e.g., mobile device (100b)) or a media server through the communication unit (130). The communication unit (130) may download / stream content such as movies, news, etc. from another device (e.g., mobile device (100b)) or a media server to the memory unit (130). The control unit (120) controls and / or performs procedures such as video / image acquisition, (video / image) encoding, and metadata generation / processing for the content, and can generate / output an XR object based on information about the surrounding space or real object acquired through the input / output unit (140a) / sensor unit (140b).

[0430] Additionally, the XR device (100a) is wirelessly connected to the mobile device (100b) through the communication unit (110), and the operation of the XR device (100a) can be controlled by the mobile device (100b). For example, the mobile device (100b) can act as a controller for the XR device (100a). To this end, the XR device (100a) can acquire three-dimensional position information of the mobile device (100b), and then generate and output an XR object corresponding to the mobile device (100b).

[0431] FIG. 42 illustrates a robot to which the present disclosure applies. Robots may be classified into industrial, medical, household, military, etc., depending on the purpose or field of use.

[0432] Referring to FIG. 42, the robot (100) may include a communication unit (110), a control unit (120), a memory unit (130), an input / output unit (140a), a sensor unit (140b), and a driving unit (140c). Here, blocks 110 to 130 / 140a to 140c correspond to blocks 110 to 130 / 140 of FIG. 37, respectively.

[0433] The communication unit (110) can transmit and receive signals (e.g., driving information, control signals, etc.) with external devices such as other wireless devices, other robots, or control servers. The control unit (120) can control the components of the robot (100) to perform various operations. The memory unit (130) can store data / parameters / programs / codes / commands that support various functions of the robot (100). The input / output unit (140a) can acquire information from outside the robot (100) and output information to outside the robot (100). The input / output unit (140a) may include a camera, microphone, user input unit, display unit, speaker and / or haptic module, etc. The sensor unit (140b) can obtain internal information of the robot (100), surrounding environment information, user information, etc. The sensor unit (140b) may include a proximity sensor, an illuminance sensor, an accelerometer, a magnetic sensor, a gyroscope, an inertial sensor, an IR sensor, a fingerprint recognition sensor, an ultrasonic sensor, a light sensor, a microphone, a radar, etc. The driving unit (140c) may perform various physical movements, such as moving robot joints. Additionally, the driving unit (140c) may enable the robot (100) to travel on the ground or fly in the air. The driving unit (140c) may include an actuator, a motor, a wheel, a brake, a propeller, etc.

[0434] FIG. 43 illustrates an AI device to which the present disclosure applies. The AI ​​device may be implemented as a stationary device or a mobile device, such as a TV, projector, smartphone, PC, laptop, digital broadcasting terminal, tablet PC, wearable device, set-top box (STB), radio, washing machine, refrigerator, digital signage, robot, vehicle, etc.

[0435] Referring to FIG. 43, the AI ​​device (100) may include a communication unit (110), a control unit (120), a memory unit (130), an input / output unit (140a / 140b), a learning processor unit (140c), and a sensor unit (140d). Blocks 110 to 130 / 140a to 140d each correspond to blocks 110 to 130 / 140 of FIG. 37.

[0436] The communication unit (110) can transmit and receive wired and wireless signals (e.g., sensor information, user input, learning model, control signal, etc.) with external devices such as other AI devices (e.g., 100x, 200, 400 in FIG. 34) or AI servers (e.g., 400 in FIG. 34) using wired and wireless communication technology. To do this, the communication unit (110) can transmit information within the memory unit (130) to an external device or transmit signals received from an external device to the memory unit (130).

[0437] The control unit (120) can determine at least one executable operation of the AI ​​device (100) based on information determined or generated using a data analysis algorithm or a machine learning algorithm. The control unit (120) can perform the determined operation by controlling the components of the AI ​​device (100). For example, the control unit (120) can request, search, receive, or utilize data from the learning processor unit (140c) or the memory unit (130), and can control the components of the AI ​​device (100) to execute a predicted operation or an operation determined to be desirable among at least one executable operation. Additionally, the control unit (120) can collect historical information, including the operation details of the AI ​​device (100) or user feedback regarding the operation, and store it in the memory unit (130) or the learning processor unit (140c), or transmit it to an external device such as an AI server (Fig. 35, 400). The collected historical information can be used to update the learning model.

[0438] The memory unit (130) can store data that supports various functions of the AI ​​device (100). For example, the memory unit (130) can store data obtained from the input unit (140a), data obtained from the communication unit (110), output data from the learning processor unit (140c), and data obtained from the sensing unit (140). Additionally, the memory unit (130) can store control information and / or software code required for the operation / execution of the control unit (120).

[0439] The input unit (140a) can acquire various types of data from outside the AI ​​device (100). For example, the input unit (140a) can acquire training data for model training and input data to which the training model is applied. The input unit (140a) may include a camera, a microphone and / or a user input unit, etc. The output unit (140b) can generate output related to visual, auditory, or tactile senses, etc. The output unit (140b) may include a display unit, a speaker and / or a haptic module, etc. The sensing unit (140) can obtain at least one of internal information of the AI ​​device (100), surrounding environment information of the AI ​​device (100), and user information using various sensors. The sensing unit (140) may include a proximity sensor, an illuminance sensor, an accelerometer, a magnetic sensor, a gyroscope, an inertial sensor, an RGB sensor, an IR sensor, a fingerprint recognition sensor, an ultrasonic sensor, a light sensor, a microphone and / or radar, etc.

[0440] The learning processor unit (140c) can train a model composed of an artificial neural network using training data. The learning processor unit (140c) can perform AI processing together with the learning processor unit of the AI ​​server (Fig. 34, 400). The learning processor unit (140c) can process information received from an external device through the communication unit (110) and / or information stored in the memory unit (130). Additionally, the output value of the learning processor unit (140c) can be transmitted to an external device through the communication unit (110) and / or stored in the memory unit (130).

Claims

Claim 1 A method characterized in that an IAB (integrated access and backhaul) node receives timing information for time resources, and the IAB node applies the timing information to the time resources, wherein the timing information is received through a MAC-CE (medium access control-control element), and the timing information indicates each timing alignment case applied to the MT (mobile termination) transmission of the IAB node at each time resource of the time resources, and wherein a first timing alignment case is applied to a first time resource among the time resources, and a second timing alignment case is applied to a second time resource among the time resources. Claim 2 A method according to claim 1, wherein the IAB node receives timing information from the parent node of the IAB node. Claim 3 A method according to claim 1, characterized in that the timing alignment case is one of timing alignment case 1, timing alignment case 6, and timing alignment case 7. Claim 4 A method according to claim 3, wherein the timing alignment case 1 is an alignment of the DU (distribution unit) transmission timing for each of the IAB node and the IAB nodes connected to the IAB node. Claim 5 A method according to paragraph 3, wherein the timing alignment case 6 is the alignment of downlink transmission timing for each of the IAB node and the IAB nodes connected to the IAB node, and the alignment between the uplink transmission timing of the IAB node and the downlink transmission timing. Claim 6 A method according to paragraph 3, wherein the timing alignment case 7 is an alignment of downlink transmission timing for each of the IAB node and the IAB nodes connected to the IAB node, and an alignment between the uplink reception timing of the IAB node and the downlink reception timing of the IAB node. Claim 7 A method according to claim 1, characterized in that the time resources are one or more slots. Claim 8 delete Claim 9 delete Claim 10 An IAB (integrated access and backhaul) node comprises: one or more memories for storing instructions; one or more transceivers; and one or more processors connecting the one or more memories and the one or more transceivers, wherein the one or more processors execute the instructions to receive timing information for time resources and apply the timing information to the time resources, wherein the timing information is received through a MAC-CE (medium access control-control element), and the timing information indicates each timing alignment case applied to the MT (mobile termination) transmission of the IAB node at each time resource of the time resources, and wherein a first timing alignment case is applied to a first time resource among the time resources and a second timing alignment case is applied to a second time resource among the time resources. Claim 11 An apparatus configured to control an IAB (integrated access and backhaul) node, wherein the apparatus comprises: one or more processors; and one or more memories executablely connected to the one or more processors and storing instructions, wherein the one or more processors execute the instructions to receive timing information for time resources and apply the timing information to the time resources, wherein the timing information is received through a MAC-CE (medium access control-control element), and the timing information indicates each timing alignment case applied to the MT (mobile termination) transmission of the IAB node at each time resource of the time resources, and wherein a first timing alignment case is applied to a first time resource among the time resources and a second timing alignment case is applied to a second time resource among the time resources. Claim 12 At least one computer-readable storage medium comprising instructions that are executed by at least one processor to perform operations, wherein the operations include receiving timing information for time resources and applying the timing information to the time resources, wherein the timing information is received through a MAC-CE (medium access control-control element), and the timing information indicates each timing alignment case applied to the MT (mobile termination) transmission of an IAB node at each time resource of the time resources, and wherein a first timing alignment case is applied to a first time resource among the time resources and a second timing alignment case is applied to a second time resource among the time resources. Claim 13 A method characterized in that a parent node transmits timing information regarding time resources to an IAB (integrated access and backhaul) node, wherein the timing information is transmitted via a MAC-CE (medium access control-control element), the timing information indicates each timing alignment case applied to the MT (mobile termination) transmission of the IAB node in each time resource of the time resources, wherein a first timing alignment case is applied to a first time resource among the time resources, and a second timing alignment case is applied to a second time resource among the time resources, and the parent node communicates with the IAB node based on the timing information. Claim 14 A parent node comprises one or more memories for storing instructions; one or more transceivers; and one or more processors connecting the one or more memories and the one or more transceivers, wherein the one or more processors execute the instructions and transmit timing information regarding time resources to an IAB (integrated access and backhaul) node, wherein the timing information is transmitted via a MAC-CE (medium access control-control element), and the timing information indicates each timing alignment case applied to the MT (mobile termination) transmission of the IAB node at each time resource of the time resources, wherein a first timing alignment case is applied to a first time resource among the time resources, and a second timing alignment case is applied to a second time resource among the time resources, and the parent node communicates with the IAB node based on the timing information. Claim 15 delete Claim 16 delete Claim 17 delete Claim 18 delete Claim 19 delete

Images