Multi-path-based communication
The method addresses the challenge of supporting multi-path operations in 3GPP LTE systems by managing bearer contexts and determining data discard in 5G networks, thereby enhancing stability and efficiency.
Patent Information
- Application Number
- PCT/KR2024/014488
- Authority / Receiving Office
- WO · WO
- Patent Type
- Applications
- Current Assignee / Owner
- Priority Date
- 2023-09-27
- Filing Date
- 2024-09-25
- Publication Date
- 2025-04-03
AI Technical Summary
The multi-path operation in 3GPP LTE systems is not effectively supported by the direct path connected to the base station and the indirect path connected through a relay UE.
A method is provided to manage bearer contexts in a communication system, involving receiving a bearer context modification request, sending a response, receiving a downlink data delivery status frame, and determining whether to discard associated downlink data. This method is implemented in a device that supports multi-path communication.
The solution enhances the stability and efficiency of multi-path operations in 5G networks by ensuring reliable data transmission through both direct and indirect paths, even if one path fails.
Smart Images

Figure KR2024014488_03042025_PF_FP_ABST
Abstract
Description
Multipath-based communication
[0001] This specification relates to mobile communications.
[0002] 3GPP (3rd Generation Partnership Project) LTE (Long-Term Evolution) is a technology designed to enable high-speed packet communications. Numerous approaches have been proposed to achieve LTE's goals of reducing costs for users and operators, improving service quality, expanding coverage, and increasing system capacity. 3GPP LTE's high-level requirements include reduced cost per bit, improved service availability, flexible use of frequency bands, a simple architecture, open interfaces, and adequate power consumption for terminals.
[0003] The International Telecommunication Union (ITU) and 3GPP have begun work on developing requirements and specifications for New Radio (NR) systems. 3GPP must identify and develop the technical components necessary to successfully standardize NR, meeting both urgent market needs and the longer-term requirements outlined by the ITU Radio communication sector (ITU-R) International Mobile Telecommunications (IMT)-2020 process. Furthermore, NR must be able to utilize any spectrum band up to at least 130 GHz, ensuring that it remains available for wireless communications well into the future.
[0004] NR aims to be a single technology framework that addresses all deployment scenarios, usage scenarios, and requirements, including enhanced Mobile Broadband (eMBB), massive Machine Type Communications (mMTC), and Ultra-Reliable and Low Latency Communications (URLLC). NR must be inherently forward-compatible.
[0005] There is a problem that multipath operation, which includes a direct path where the UE is directly connected to the base station and an indirect path where the UE is connected to the base station via a relay UE, is not effectively supported.
[0006] According to one embodiment of the present disclosure, a method is provided. The method may include: receiving a bearer context modification request message from a CU-CP; transmitting a bearer context modification response message to the CU-CP; receiving a downlink data transfer status frame from a DU; and determining whether to transmit information to the DU for discarding downlink data associated with the DDDS frame.
[0007] According to one embodiment, a device implementing the method is provided.
[0008] According to one embodiment of the present disclosure, a method is provided. The method may include the steps of transmitting a bearer context modification request message to a CU-UP; and receiving a bearer context modification response message from the CU-UP.
[0009] Figure 1 illustrates an example of a communication system to which the implementation of this specification is applied.
[0010] Figure 2 illustrates an example of a wireless device to which the implementation of the present specification is applied.
[0011] Figure 3 shows an example of a UE to which the implementation of this specification is applied.
[0012] Figure 4 shows an example of a 5G system structure to which the implementation of this specification is applied.
[0013] Figure 6a illustrates a first example in which a service is provided to a UE via two paths. Figure 6b illustrates a second example in which a service is provided to a UE via two paths. Figure 6c illustrates a third example in which a service is provided to a UE via two paths. Figure 6d illustrates a fourth example in which a service is provided to a UE via two paths.
[0014] FIG. 7a and FIG. 7b illustrate an example of an indirect path addition procedure according to the first example of the disclosure of the present specification.
[0015] FIG. 8a and FIG. 8b illustrate examples of a direct path addition procedure according to the second example of the disclosure of the present specification.
[0016] FIG. 9A and FIG. 9B are examples of adding a direct path between DUs according to one embodiment of the disclosure of the present specification.
[0017] FIG. 10A and FIG. 10B are examples of adding an indirect path between DUs according to one embodiment of the disclosure of the present specification.
[0018] FIG. 11 is an example of adding a direct path within a DU according to one embodiment of the disclosure of the present specification.
[0019] FIG. 12 is an example of adding an indirect path within a DU according to one embodiment of the disclosure of the present specification.
[0020] FIG. 13 illustrates an example of a procedure according to one embodiment of the disclosure of the present specification.
[0021] The following techniques, devices, and systems can be applied to various wireless multiple access systems. Examples of multiple access systems include Code Division Multiple Access (CDMA) systems, Frequency Division Multiple Access (FDMA) systems, Time Division Multiple Access (TDMA) systems, Orthogonal Frequency Division Multiple Access (OFDMA) systems, Single Carrier Frequency Division Multiple Access (SC-FDMA) systems, and Multi-Carrier Frequency Division Multiple Access (MC-FDMA) systems. CDMA can be implemented using wireless technologies such as Universal Terrestrial Radio Access (UTRA) or CDMA2000. TDMA can be implemented using wireless technologies such as Global System for Mobile communications (GSM), General Packet Radio Service (GPRS), or Enhanced Data rates for GSM Evolution (EDGE). OFDMA can be implemented using wireless technologies such as IEEE (Institute of Electrical and Electronics Engineers) 802.11 (Wi-Fi), IEEE 802.16 (WiMAX), IEEE 802.20, or Evolved UTRA (E-UTRA). UTRA is part of the Universal Mobile Telecommunications System (UMTS). 3GPP (3rd Generation Partnership Project) Long-Term Evolution (LTE) is part of E-UMTS (Evolved UMTS) that utilizes E-UTRA.3GPP LTE uses OFDMA in the downlink (DL) and SC-FDMA in the uplink (UL). Evolution of 3GPP LTE includes LTE-A (Advanced), LTE-A Pro, and / or 5G NR (New Radio).
[0022] For convenience of explanation, the implementation of this specification is primarily described in relation to a 3GPP-based wireless communication system. However, the technical features of this specification are not limited thereto. For example, the following detailed description is provided based on a mobile communication system corresponding to a 3GPP-based wireless communication system, but aspects of this specification that are not limited to a 3GPP-based wireless communication system can be applied to other mobile communication systems.
[0023] For terms and technologies used in this specification that are not specifically described, reference may be made to wireless communication standard documents published prior to this specification.
[0024] As used herein, "A or B" can mean "only A," "only B," or "both A and B." Alternatively, as used herein, "A or B" can be interpreted as "A and / or B." For example, as used herein, "A, B or C" can mean "only A," "only B," "only C," or "any combination of A, B and C."
[0025] As used herein, a slash ( / ) or a comma can mean "and / or." For example, "A / B" can mean "A and / or B." Accordingly, "A / B" can mean "only A," "only B," or "both A and B." For example, "A, B, C" can mean "A, B, or C."
[0026] 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 identically to “at least one of A and B.”
[0027] Additionally, in this specification, “at least one of A, B and C” can 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” can mean “at least one of A, B and C”.
[0028] Additionally, parentheses used herein 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 "PDCCH" 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."
[0029] Technical features individually described in a single drawing in this specification may be implemented individually or simultaneously.
[0030] Although not limited thereto, the various descriptions, functions, procedures, proposals, methods and / or operational flowcharts disclosed herein may be applied to various fields requiring wireless communication and / or connectivity between devices (e.g., 5G).
[0031] Hereinafter, the present specification will be described in more detail with reference to the drawings. In the following drawings and / or description, the same reference numbers may refer to the same or corresponding hardware blocks, software blocks, and / or functional blocks, unless otherwise indicated.
[0032] Figure 1 illustrates an example of a communication system to which the implementation of this specification is applied.
[0033] The 5G usage scenario shown in FIG. 1 is only an example, and the technical features of this specification can be applied to other 5G usage scenarios not shown in FIG. 1.
[0034] The three main requirement categories for 5G are (1) enhanced mobile broadband (eMBB), (2) massive machine type communication (mMTC), and (3) ultra-reliable and low latency communications (URLLC).
[0035] Referring to FIG. 1, a communication system (1) includes wireless devices (100a to 100f), a base station (BS; 200), and a network (300). FIG. 1 illustrates a 5G network as an example of a network of the communication system (1), but the implementation of the present disclosure is not limited to a 5G system and can be applied to future communication systems beyond the 5G system.
[0036] The base station (200) and the network (300) may be implemented as wireless devices, and a particular wireless device may operate as a base station / network node in relation to other wireless devices.
[0037] The wireless devices (100a to 100f) represent devices that perform communication using Radio Access Technology (RAT) (e.g., 5G NR or LTE) and may also be referred to as communication / wireless / 5G devices. The wireless devices (100a to 100f) may include, but are not limited to, a robot (100a), a vehicle (100b-1 and 100b-2), an extended reality (XR) device (100c), a portable device (100d), a home appliance (100e), an Internet-of-Things (IoT) device (100f), and an artificial intelligence (AI) device / server (400). For example, the vehicles may include vehicles having wireless communication capabilities, autonomous vehicles, and vehicles capable of performing vehicle-to-vehicle communication. The vehicles may include unmanned aerial vehicles (UAVs) (e.g., drones). XR devices may include AR (Augmented Reality) / VR (Virtual Reality) / MR (Mixed Reality) devices, and may be implemented in the form of HMD (Head-Mounted Device) and HUD (Head-Up Display) mounted on vehicles, televisions, smartphones, computers, wearable devices, home appliances, digital signs, vehicles, robots, etc. Portable devices may include smartphones, smart pads, wearable devices (e.g., smart watches or smart glasses), and computers (e.g., laptops). Home appliances may include TVs, refrigerators, and washing machines. IoT devices may include sensors and smart meters.
[0038] In this specification, wireless devices (100a to 100f) may be referred to as user equipment (UE). The UE may include, for example, a mobile phone, a smartphone, a laptop computer, a digital broadcasting terminal, a personal digital assistant (PDA), a portable multimedia player (PMP), a navigation system, a slate PC, a tablet PC, an ultrabook, a vehicle, a vehicle with autonomous driving function, a connected car, a UAV, an AI module, a robot, an AR device, a VR device, an MR device, a hologram device, a public safety device, an MTC device, an IoT device, a medical device, a fintech device (or a financial device), a security device, a weather / environmental device, a 5G service-related device, or a 4th industrial revolution-related device.
[0039] Wireless devices (100a to 100f) can be connected to a network (300) via a base station (200). AI technology can be applied to the wireless devices (100a to 100f), and the wireless devices (100a to 100f) can be connected to an AI server (400) via the network (300). The network (300) can be configured using a 3G network, a 4G (e.g., LTE) network, a 5G (e.g., NR) network, and a network after 5G. The wireless devices (100a to 100f) can communicate with each other via the base station (200) / network (300), but can also communicate directly (e.g., sidelink communication) without going through the base station (200) / network (300). For example, vehicles (100b-1, 100b-2) can communicate directly (e.g., vehicle-to-vehicle (V2V) / vehicle-to-everything (V2X) communication). Additionally, IoT devices (e.g., sensors) can communicate directly with other IoT devices (e.g., sensors) or other wireless devices (100a to 100f).
[0040] Wireless communication / connection (150a, 150b, 150c) can be established between wireless devices (100a to 100f) and / or between wireless devices (100a to 100f) and a base station (200) and / or between base stations (200). Here, the wireless communication / connection can be established through various RATs (e.g., 5G NR), such as uplink / downlink communication (150a), sidelink communication (150b) (or, D2D (Device-To-Device) communication), and base station-to-base station communication (150c) (e.g., relay, IAB (Integrated Access and Backhaul)). Through the wireless communication / connection (150a, 150b, 150c), the wireless devices (100a to 100f) and the base station (200) 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, at least some of the 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.), and resource allocation processes can be performed based on various proposals of the present specification.
[0041] NR supports multiple numerologies, or subcarrier spacings (SCS), to support diverse 5G services. For example, an SCS of 15 kHz supports wide areas in traditional cellular bands; an SCS of 30 kHz / 60 kHz supports dense urban areas, lower latency, and wider carrier bandwidth; and an SCS of 60 kHz or higher supports bandwidths greater than 24.25 GHz to overcome phase noise.
[0042] The NR frequency band can be defined by two types of frequency ranges (FR1 and FR2). The numerical values of the frequency ranges can be changed. For example, the two types of frequency ranges (FR1 and FR2) can be as shown in Table 1 below. For convenience of explanation, among the frequency ranges used in the NR system, FR1 can mean the "sub 6 GHz range," and FR2 can mean the "above 6 GHz range," which can be called millimeter wave (mmW).
[0043] Frequency Range DefinitionFrequency RangeSubcarrier SpacingFR1450MHz - 6000MHz15, 30, 60kHzFR224250MHz - 52600MHz60, 120, 240kHz
[0044] As described above, the numerical value of the frequency range of the NR system can be changed. For example, FR1 may include a band from 410 MHz to 7125 MHz, as shown in Table 2 below. That is, FR1 may include frequency bands above 6 GHz (or 5850, 5900, 5925 MHz, etc.). For example, the frequency bands above 6 GHz (or 5850, 5900, 5925 MHz, etc.) included within FR1 may include unlicensed bands. Unlicensed bands may be used for various purposes, such as for communications for vehicles (e.g., autonomous driving).
[0045] Frequency Range DefinitionFrequency RangeSubcarrier SpacingFR1410MHz - 7125MHz15, 30, 60kHzFR224250MHz - 52600MHz60, 120, 240kHz
[0046] Here, the wireless communication technology implemented in the wireless device of the present specification may include not only LTE, NR, and 6G, but also Narrowband IoT (NB-IoT) 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 with standards such as LTE Cat NB1 and / or LTE Cat NB2, and is not limited to the above-described names. Additionally or alternatively, the wireless communication technology implemented in the wireless device of the present specification may perform communication based on LTE-M technology. For example, LTE-M technology may be an example of LPWAN technology and may be called by various names such as eMTC (enhanced MTC). For example, LTE-M technology can be implemented by 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 MTC, and / or 7) LTE M, and is not limited to the above-described names. Additionally or alternatively, the wireless communication technology implemented in the wireless device of the present specification can include at least one of ZigBee, Bluetooth, and / or LPWAN considering low-power communication, and is not limited to the above-described names. For example, ZigBee technology can create PANs (Personal Area Networks) related to small / low-power digital communication based on various standards such as IEEE 802.15.4, and can be called by various names.
[0047] Figure 2 illustrates an example of a wireless device to which the implementation of the present specification is applied.
[0048] In FIG. 2, the first wireless device (100) and / or the second wireless device (200) may be implemented in various forms depending on the use case / service. For example, {the first wireless device (100) and the second wireless device (200)} may correspond to at least one of {the wireless devices (100a to 100f) and the base station (200)}, {the wireless devices (100a to 100f) and the wireless devices (100a to 100f)}, and / or {the base station (200) and the base station (200)} of FIG. 1. The first wireless device (100) and / or the second wireless device (200) may be configured by various components, devices / parts, and / or modules.
[0049] The first wireless device (100) may include at least one transceiver, such as a transceiver (106), at least one processing chip, such as a processing chip (101), and / or one or more antennas (108).
[0050] The processing chip (101) may include at least one processor, such as a processor (102), and at least one memory, such as a memory (104). Additionally and / or alternatively, the memory (104) may be located external to the processing chip (101).
[0051] The processor (102) may control the memory (104) and / or the transceiver (106) and may be configured to implement the descriptions, functions, procedures, proposals, methods, and / or operational flowcharts disclosed herein. For example, the processor (102) may process information in the memory (104) to generate first information / signal and transmit a wireless signal including the first information / signal via the transceiver (106). The processor (102) may receive a wireless signal including second information / signal via the transceiver (106) and store information obtained by processing the second information / signal in the memory (104).
[0052] A memory (104) may be operatively connected to the processor (102). The memory (104) may store various types of information and / or instructions. The memory (104) may store firmware and / or software code (105) that implements code, instructions and / or sets of instructions that, when executed by the processor (102), perform the descriptions, functions, procedures, suggestions, methods and / or operational flowcharts disclosed herein. For example, the firmware and / or software code (105) may implement instructions that, when executed by the processor (102), perform the descriptions, functions, procedures, suggestions, methods and / or operational flowcharts disclosed herein. For example, the firmware and / or software code (105) may control the processor (102) to perform one or more protocols. For example, the firmware and / or software code (105) may control the processor (102) to perform one or more air interface protocol layers.
[0053] Here, the processor (102) and memory (104) may be part of a communication modem / circuit / chip designed to implement a RAT (e.g., LTE or NR). A transceiver (106) may be connected to the processor (102) and may transmit and / or receive wireless signals via one or more antennas (108). Each transceiver (106) may include a transmitter and / or a receiver. The transceiver (106) may be used interchangeably with an RF (Radio Frequency) unit. In the present specification, the first wireless device (100) may represent a communication modem / circuit / chip.
[0054] The second wireless device (200) may include at least one transceiver, such as a transceiver (206), at least one processing chip, such as a processing chip (201), and / or one or more antennas (208).
[0055] The processing chip (201) may include at least one processor, such as a processor (202), and at least one memory, such as a memory (204). Additionally and / or alternatively, the memory (204) may be located external to the processing chip (201).
[0056] The processor (202) may control the memory (204) and / or the transceiver (206) and may be configured to implement the descriptions, functions, procedures, proposals, methods and / or operational flowcharts disclosed herein. For example, the processor (202) may process information in the memory (204) to generate third information / signal and transmit a wireless signal including the third information / signal via the transceiver (206). The processor (202) may receive a wireless signal including fourth information / signal via the transceiver (206) and store information obtained by processing the fourth information / signal in the memory (204).
[0057] A memory (204) may be operatively connected to the processor (202). The memory (204) may store various types of information and / or instructions. The memory (204) may store firmware and / or software code (205) that implements code, instructions and / or sets of instructions that, when executed by the processor (202), perform the descriptions, functions, procedures, suggestions, methods and / or operational flowcharts disclosed herein. For example, the firmware and / or software code (205) may implement instructions that, when executed by the processor (202), perform the descriptions, functions, procedures, suggestions, methods and / or operational flowcharts disclosed herein. For example, the firmware and / or software code (205) may control the processor (202) to perform one or more protocols. For example, the firmware and / or software code (205) may control the processor (202) to perform one or more air interface protocol layers.
[0058] Here, the processor (202) and memory (204) may be part of a communication modem / circuit / chip designed to implement a RAT (e.g., LTE or NR). A transceiver (206) may be connected to the processor (202) and may transmit and / or receive wireless signals via one or more antennas (208). Each transceiver (206) may include a transmitter and / or a receiver. The transceiver (206) may be used interchangeably with the RF unit. In the present specification, the second wireless device (200) may represent a communication modem / circuit / chip.
[0059] 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 a physical (PHY) layer, a Media Access Control (MAC) layer, a Radio Link Control (RLC) layer, a Packet Data Convergence Protocol (PDCP) layer, a Radio Resource Control (RRC) layer, and a Service Data Adaptation Protocol (SDAP) layer). One or more processors (102, 202) may generate one or more Protocol Data Units (PDUs), one or more Service Data Units (SDUs), messages, control information, data, or information according to the descriptions, functions, procedures, proposals, methods, and / or operational flowcharts disclosed herein. One or more processors (102, 202) can generate signals (e.g., baseband signals) including PDUs, SDUs, messages, control information, data or information according to the descriptions, functions, procedures, proposals, methods and / or operational flowcharts disclosed herein and provide the signals to one or more transceivers (106, 206). One or more processors (102, 202) can receive signals (e.g., baseband signals) from one or more transceivers (106, 206) and obtain PDUs, SDUs, messages, control information, data or information according to the descriptions, functions, procedures, proposals, methods and / or operational flowcharts disclosed herein.
[0060] The one or more processors (102, 202) may be referred to as a controller, a microcontroller, a microprocessor, and / or a microcomputer. The one or more processors (102, 202) may be implemented by hardware, firmware, software, and / 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), and / or one or more Field Programmable Gate Arrays (FPGAs) may be included in the one or more processors (102, 202). For example, the one or more processors (102, 202) may be configured by a set of a communication control processor, an Application Processor (AP), an Electronic Control Unit (ECU), a Central Processing Unit (CPU), a Graphic Processing Unit (GPU), and a Memory Control Processor. One or more memories (104, 204) may be coupled to one or more processors (102, 202) and may store various forms of data, signals, messages, information, programs, codes, instructions and / or commands. The one or more memories (104, 204) may be configured as random access memory (RAM), dynamic RAM (DRAM), read-only memory (ROM), erasable programmable ROM (EPROM), flash memory, volatile memory, nonvolatile memory, hard drive, register, cache memory, computer readable storage media and / or combinations thereof.One or more memories (104, 204) may be located internally and / or externally to one or more processors (102, 202). Additionally, one or more memories (104, 204) may be connected to one or more processors (102, 202) via various technologies, such as wired or wireless connections.
[0061] One or more transceivers (106, 206) can transmit user data, control information, wireless signals / channels, etc., referred to in the descriptions, functions, procedures, proposals, methods, and / or flowcharts disclosed herein to one or more other devices. One or more transceivers (106, 206) can receive user data, control information, wireless signals / channels, etc., referred to in the descriptions, functions, procedures, proposals, methods, and / or flowcharts disclosed herein from one or more other devices. For example, one or more transceivers (106, 206) can be coupled to one or more processors (102, 202) and can transmit and receive wireless signals. For example, one or more processors (102, 202) can control one or more transceivers (106, 206) to transmit user data, control information, wireless signals, etc., 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, wireless signals, etc. from one or more other devices.
[0062] One or more transceivers (106, 206) may be coupled to one or more antennas (108, 208). Additionally and / or alternatively, one or more transceivers (106, 206) may include one or more antennas (108, 208). 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 operational flowcharts disclosed herein via one or more antennas (108, 208). In the present disclosure, one or more antennas (108, 208) may be multiple physical antennas or multiple logical antennas (e.g., antenna ports).
[0063] One or more transceivers (106, 206) may convert received user data, control information, wireless signals / channels, etc. from RF band signals to baseband signals in order to process the received user data, control information, wireless signals / channels, etc. using one or more processors (102, 202). One or more transceivers (106, 206) may convert processed user data, control information, wireless signals / channels, etc. from baseband signals to RF band signals using one or more processors (102, 202). For this purpose, one or more transceivers (106, 206) may include an (analog) oscillator and / or a filter. For example, one or more transceivers (106, 206) may up-convert an OFDM baseband signal to an OFDM signal via an (analog) oscillator and / or filter under the control of one or more processors (102, 202) and transmit the up-converted OFDM signal at a carrier frequency. One or more transceivers (106, 206) may receive an OFDM signal at a carrier frequency and down-convert the OFDM signal to an OFDM baseband signal via an (analog) oscillator and / or filter under the control of one or more processors (102, 202).
[0064] Although not illustrated in FIG. 2, the wireless device (100, 200) may further include additional components. The additional components (140) may be configured in various ways depending on the type of the wireless device (100, 200). For example, the additional components (140) may include at least one of a power unit / battery, an input / output (I / O) device (e.g., an audio I / O port, a video I / O port), a driving device, and a computing device. The additional components (140) may be connected to one or more processors (102, 202) via various technologies, such as a wired or wireless connection.
[0065] In the implementation of this specification, a UE can operate as a transmitter in the uplink and as a receiver in the downlink. In the implementation of this specification, a base station can operate as a receiver in the UL and as a transmitter in the DL. For the sake of convenience of description, it is mainly assumed below that the first wireless device (100) operates as a UE and the second wireless device (200) operates as a base station. For example, a processor (102) connected to, mounted on, or released in the first wireless device (100) can be configured to perform UE operations according to the implementation of this specification or to control a transceiver (106) to perform UE operations according to the implementation of this specification. A processor (202) connected to, mounted on, or released in the second wireless device (200) can be configured to perform base station operations according to the implementation of this specification or to control a transceiver (206) to perform base station operations according to the implementation of this specification.
[0066] In this specification, a base station may be referred to as a Node B, an eNode B (eNB), or a gNB.
[0067] Figure 3 shows an example of a UE to which the implementation of this specification is applied.
[0068] Referring to FIG. 3, the UE (100) can correspond to the first wireless device (100) of FIG. 2.
[0069] The UE (100) includes a processor (102), memory (104), a transceiver (106), one or more antennas (108), a power management module (141), a battery (142), a display (143), a keypad (144), a SIM (Subscriber Identification Module) card (145), a speaker (146), and a microphone (147).
[0070] The processor (102) may be configured to implement the descriptions, functions, procedures, proposals, methods and / or flowcharts disclosed herein. The processor (102) may be configured to control one or more other components of the UE (100) to implement the descriptions, functions, procedures, proposals, methods and / or flowcharts disclosed herein. A layer of a radio interface protocol may be implemented in the processor (102). The processor (102) may include an ASIC, other chipsets, logic circuits and / or data processing devices. The processor (102) may be an application processor. The processor (102) may include at least one of a DSP, a CPU (Central Processing Unit), a GPU (Graphics Processing Unit), and a modem (modulator and demodulator). An example of the processor (102) is the SNAPDRAGON manufactured by Qualcomm®. TM Series processors, EXYNOS made by Samsung® TM Series processors, A-series processors made by Apple®, HELIO made by MediaTek® TM ATOM series processors made by Intel® TM It can be found in the series processors or the corresponding next-generation processors.
[0071] Memory (104) is operatively coupled to the processor (102) and stores various information for operating the processor (102). Memory (104) may include ROM, RAM, flash memory, memory cards, storage media, and / or other storage devices. When the implementation is implemented in software, the techniques described herein may be implemented using modules (e.g., procedures, functions, etc.) that perform the descriptions, functions, procedures, suggestions, methods, and / or operational flowcharts disclosed herein. The modules may be stored in memory (104) and executed by the processor (102). Memory (104) may be implemented within the processor (102) or external to the processor (102), in which case it may be communicatively coupled to the processor (102) via various methods known in the art.
[0072] A transceiver (106) is operably coupled to the processor (102) and transmits and / or receives a radio signal. The transceiver (106) includes a transmitter and a receiver. The transceiver (106) may include a baseband circuit for processing a radio frequency signal. The transceiver (106) controls one or more antennas (108) to transmit and / or receive a radio signal.
[0073] The power management module (141) manages the power of the processor (102) and / or the transceiver (106). The battery (142) supplies power to the power management module (141).
[0074] The display (143) outputs the results processed by the processor (102). The keypad (144) receives input to be used by the processor (102). The keypad (144) can be displayed on the display (143).
[0075] A SIM card (145) is an integrated circuit that securely stores an International Mobile Subscriber Identity (IMSI) and associated keys, and is used to identify and authenticate subscribers in mobile devices such as mobile phones and computers. Additionally, many SIM cards can store contact information.
[0076] The speaker (146) outputs sound-related results processed by the processor (102). The microphone (147) receives sound-related input to be used by the processor (102).
[0077] Figure 4 shows an example of a 5G system structure to which the implementation of this specification is applied.
[0078] The 5G system (5GS; 5G system) structure consists of the following network functions (NF; Network Function).
[0079] - AUSF (Authentication Server Function)
[0080] -AMF (Access and Mobility Management Function)
[0081] - DN (Data Network), for example, operator services, Internet access, or third-party services.
[0082] - USDF (Unstructured Data Storage Function)
[0083] - NEF (Network Exposure Function)
[0084] - I-NEF (Intermediate NEF)
[0085] - NRF (Network Repository Function)
[0086] - NSSF (Network Slice Selection Function)
[0087] - PCF (Policy Control Function)
[0088] - SMF (Session Management Function)
[0089] - UDM (Unified Data Management)
[0090] - UDR (Unified Data Repository)
[0091] - UPF (User Plane Function)
[0092] - UCMF (UE radio Capability Management Function)
[0093] - AF (Application Function)
[0094] - UE (User Equipment)
[0095] - (R)AN ((Radio) Access Network)
[0096] - 5G-EIR (5G-Equipment Identity Register)
[0097] - NWDAF (Network Data Analytics Function)
[0098] - CHF (CHarging Function)
[0099] 또한, 다음과 같은 네트워크 기능이 고려될 수 있다.
[0100] - N3IWF (Non-3GPP InterWorking Function)
[0101] - TNGF (Trusted Non-3GPP Gateway Function)
[0102] - W-AGF (Wireline Access Gateway Function)
[0103] Figure 4 illustrates the 5G system architecture for a non-roaming case using a reference point representation showing how various network functions interact with each other.
[0104] For clarity of the point-to-point diagram in Figure 4, UDSF, NEF, and NRF are not illustrated. However, all network functions shown can interact with UDSF, UDR, NEF, and NRF as needed.
[0105] For clarity, the connection between UDR and other NFs (e.g., PCF) is not shown in Fig. 4. For clarity, the connection between NWDAF and other NFs (e.g., PCF) is not shown in Fig. 4.
[0106] The 5G system architecture includes the following benchmarks:
[0107] - N1: Reference point between UE and AMF.
[0108] - N2: Reference point between (R)AN and AMF.
[0109] - N3: Reference point between (R)AN and UPF.
[0110] - N4: Reference point between SMF and UPF.
[0111] - N6: Reference point between UPF and data network.
[0112] - N9: Reference point between two UPFs.
[0113] The following benchmarks illustrate the interactions that exist between NF services in NF.
[0114] - N5: Reference point between PCF and AF.
[0115] - N7: Reference point between SMF and PCF.
[0116] - N8: Reference point between UDM and AMF.
[0117] - N10: Reference point between UDM and SMF.
[0118] - N11: Reference point between AMF and SMF.
[0119] - N12: Reference point between AMF and AUSF.
[0120] - N13: Reference point between UDM and AUSF.
[0121] - N14: Reference point between two AMFs.
[0122] - N15: Reference point between PCF and AMF for non-roaming scenarios, and reference point between PCF and AMF of visited network for roaming scenarios.
[0123] - N16: Reference point between two SMFs (in case of roaming, between the SMF of the visited network and the SMF of the home network)
[0124] - N22: Reference point between AMF and NSSF.
[0125] In some cases, two NFs may need to be interconnected to serve a UE.
[0126] < UE-to-Network Relay >
[0127] Figure 5 illustrates an example of the architecture of a UE-to-Network Relay.
[0128] Referring to FIG. 5, UE-to-Network Relay supports network connection of a remote UE.
[0129] The PC5 link is the interface between the UE and the UE-to-network relay. The Uu link is the interface between the UE-to-network relay and the base station.
[0130] If the UE has established a PC5 link with a UE-to-network relay, the UE is considered a remote UE.
[0131] A UE-to-Network Relay entity can provide network connectivity for remote UEs. UE-to-Network Relay can be used for both public safety services and commercial services (e.g., interactive services).
[0132] When a UE (e.g., a remote UE) successfully establishes a PC5 link to a UE-to-Network Relay, the UE (e.g., a remote UE) may be considered a Remote UE for that particular UE-to-Network Relay. The Remote UE may be located within NG-RAN coverage or outside NG-RAN coverage.
[0133] A UE-to-Network Relay can relay unicast traffic (UL and DL traffic) between a remote UE and the network. A UE-to-Network Relay must provide a general function capable of relaying all IP traffic.
[0134] For unicast traffic between Remote UEs and UE-to-Network Relays, one-to-one direct communication can be used.
[0135] A method to support ProSe (Proximity-based Services) in 5GS is being discussed. This includes a method of receiving network connection services through a UE-to-Network Relay, which may be a Layer-2 UE-to-Network Relay or a Layer-3 UE-to-Network Relay.
[0136] In the prior art, a UE can receive a connection service from a network in a manner such as the example below.
[0137] 1) The UE can receive services directly from the network for Protocol Data Unit (PDU) Sessions without going through a UE-to-Network Relay (this is called Direct Network Communication or Direct Path).
[0138] 2) The UE can indirectly receive services from the network for PDU Sessions through UE-to-Network Relay (this is called Indirect Network Communication or Indirect Path).
[0139] In particular, the following scenarios are considered not possible in prior art:
[0140] i) The UE receives network connection services through one or more Layer-2 UE-to-Network Relays, while simultaneously receiving network connection services through a direct path.
[0141] ii) The UE receives network connection services through two or more Layer-2 UE-to-Network Relays.
[0142] Because, even if the UE receives network connection service through Layer-2 UE-to-Network Relay, the UE performs RRC operation and NAS operation with NG-RAN and Core network (via Layer-2 UE-to-Network Relay). In the above scenarios i) and ii), the UE forms multiple RRC connections and NAS connections through 3GPP access (i.e., Uu interface between UE and NG-RAN in case of direct path, and Uu interface between Layer-2 UE-to-Network Relay and NG-RAN in case of indirect path), but multiple RRC connections and NAS connections were not allowed in the prior art.
[0143] Unlike prior art, scenarios in which a UE receives services from a network via multiple paths are being considered. The examples in Figures 6a through 6d below illustrate a scenario in which a UE receives services from a network via two paths.
[0144] The following drawings are intended to illustrate specific examples of the present specification. The names of specific devices and the names of specific signals / messages / fields depicted in the drawings are provided for illustrative purposes only, and the technical features of this specification are not limited to the specific names used in the drawings.
[0145] Figure 6a illustrates a first example in which a service is provided to a UE via two paths. Figure 6b illustrates a second example in which a service is provided to a UE via two paths. Figure 6c illustrates a third example in which a service is provided to a UE via two paths. Figure 6d illustrates a fourth example in which a service is provided to a UE via two paths.
[0146] In the example of Figure 6a, the UE can receive services from the network via direct and indirect paths. In this case, these paths can be serviced via the same NG-RAN.
[0147] In the example of Figure 6b, a UE can receive services from the network through two different indirect paths, where these paths can be served through the same NG-RAN.
[0148] In the example of Figure 6c, the UE can receive services from the network via direct and indirect paths. These paths may be served via different NG-RANs.
[0149] Figure 6d shows that a UE can receive services from the network through two different indirect paths. In this case, the paths can be served through different NG-RANs.
[0150] As can be seen in the examples of Figures 6a to 6d, for all paths, it is assumed that the connection / communication between the UE and the network on the path is 3GPP access (i.e., Uu interface). That is, in the case of a direct path, the connection / communication between the UE and the network can be formed through 3GPP access. In the case of an indirect path, the connection / communication between the UE-to-Network Relay and the network can be formed through 3GPP access.
[0151] Although the examples of FIGS. 6A to 6D illustrate two paths, this is merely an example, and the scope of multi-path described in the disclosure of this specification may be extended to three or more paths.
[0152] The examples in Figures 6a through 6d illustrate that a UE receives service through the same PLMN. Additionally, a UE may receive service through paths that pass through different PLMNs.
[0153] A UE using these multiple paths can be assumed to be supported for both non-roaming and roaming cases.
[0154] Discussions are needed to achieve the following objectives:
[0155] Supports UE-to-network relay by supporting multipath transmission using only one direct network communication path and one indirect network communication path to improve stability or data rate.
[0156] Additionally, discussions are needed to achieve the following objectives:
[0157] The following scenarios warrant investigation into the benefits and potential solutions (e.g., switching between or simultaneously utilizing multiple paths) of multipath support for improved reliability and throughput:
[0158] The UE is connected to the same gNB using 1) one direct path and 1 indirect path via a Layer 2 UE-to-network relay. Alternatively, the UE is connected to the same gNB via 2) another UE (assuming ideal UE-to-UE connectivity). The solution in 1) can be reused in 2), without excluding parts of the solution that are unnecessary for the task in 2).
[0159] PDCP (Packet Data Convergence Protocol) duplication can be supported. PDCP duplication is a feature introduced to enhance data reliability in 5G networks. PDCP duplication is used to improve transmission efficiency and reduce packet loss by transmitting the same PDCP Protocol Data Unit (PDU) over two different paths. This ensures that even if a packet is lost on one path, it can still be received on the other path, ensuring reliable data transmission.
[0160] If there is no specific mention of an indirect path in the disclosure of this specification, the indirect path is basically assumed to be an indirect path via Layer-2 UE-to-Network Relay.
[0161] There is a problem that multipath operation, which includes a direct path where the UE is directly connected to the base station and an indirect path where the UE is connected to the base station via a relay UE, is not effectively supported.
[0162] For example, multipaths including an indirect path based on Sidelink (SL) relay have been introduced. PDCP duplication can be used to transmit the same data on both the indirect path and the direct path. Conventional techniques can cause problems with data transmission between the remote UE and the relay UE on the indirect path, even if the DU transmits a Downlink Data Delivery Status (DDDS) message to the CU-UP.
[0163] In a situation where PDCP duplication is applied, the PDCP located in the CU can recognize that data transmission has been successful through one RLC entity located in the DU. According to the prior art, in this case, one side can instruct the other side's Radio Link Control (RLC) entity to not transmit the corresponding PDCP PDU and to discard the corresponding packet. Note that the two RLC entities can be located in the same DU or in different DUs. However, the following agreement has been discussed for situations where multipath is applied to the SL relay.
[0164] Agreement: In packet duplication for Scenario 1, the PDCP entity does not need to instruct the Uu RLC entity to discard the PDCP PDU when the PC5 RLC entity indicates successful transmission of the PDCP PDU. In packet duplication for Scenario 1, if the Uu RLC entity of the remote UE indicates successful transmission of the PDCP PDU, the PDCP entity must instruct the PC5 RLC entity to discard the PDCP PDU.
[0165] For reference, Scenario 1 utilizes a PC5 link between the Remote UE and the Relay UE. Scenario 2 utilizes a non-3GPP connection (N3C) between the Remote UE and the Relay UE.
[0166] In SL relay-based communication, multi-path transmission may be considered. In this case, the PC5 RLC entity can notify PDCP that it has successfully transmitted data to the Relay UE. Even in this case, PDCP must not request the Uu RLC entity to block the transmission of the corresponding PDCP PDU or to delete the corresponding PDCP PDU. This is because the Relay UE may fail to transmit the corresponding data to the Remote UE (for DL) or to the gNB (for UL). In case of failure, the DU must be able to transmit the corresponding data packet to the UE via the Uu link. For example, a DU located on the direct path can transmit a duplicated PDCP PDU to the UE. However, the DU does not send the data to the direct path because the indirect path failed. Even though the CU's PDCP receives an ack from the PC5 RLC entity, it does not request the DU's Uu RLC entity to delete the duplicated PDCP PDU, so the Uu RLC entity naturally transmits the duplicated PDCP PDU it was storing to the terminal.
[0167] For reference, a PC5 RLC entity refers to an RLC entity related to an indirect path and can be located in a DU. A PC5 RLC entity may be located in the same DU as a Uu RLC entity, but they may be located in different DUs. PDCP is located in the CU. The DU manages the PHY layer, MAC layer, and RLC layer, and the CU can manage the PDCP layer, RRC layer, and SDAP layer.
[0168] Therefore, when the gNB-CU is divided into CP and UP, the CU-UP must know information such as the bearer and / or RLC entity, TNL address, etc. related to the indirect path. The CU-UP can receive successfully delivered PDCP SN information through DDDS from the RLC entity related to the indirect path. Even in this case, the CU-UP may not perform deletion or transmission prohibition actions on the corresponding data packet to the Uu entity related to the direct path.
[0169] In various examples of the disclosure of this specification, it is described how a CU-CP informs a CU-UP of bearer and / or TNL address information associated with an indirect path among the direct path and indirect path created for multi-path transmission.
[0170] Some of the service operations between Core NFs described in the disclosure of this specification may be newly defined service operations. In addition, some of the NG messages between AMF and NG-RAN described in the disclosure of this specification may be newly defined NG messages. In addition, some of the RRC messages between NG-RAN and UE described in the disclosure of this specification may be newly defined RRC messages.
[0171] In the procedures below, some steps may be performed concurrently / in parallel, or may be performed in a different order than described.
[0172] The names of the indication or parameter information suggested below are examples and may be changed and interpreted to other names for the proposed procedure / purpose / method.
[0173] 1. First example of disclosure of this specification
[0174] Hereinafter, a first example of the disclosure of the present specification related to adding an indirect path is described with reference to FIGS. 7a and 7b.
[0175] The following drawings are intended to illustrate specific examples of the present specification. The names of specific devices and the names of specific signals / messages / fields depicted in the drawings are provided for illustrative purposes only, and the technical features of this specification are not limited to the specific names used in the drawings.
[0176] FIG. 7a and FIG. 7b illustrate an example of an indirect path addition procedure according to the first example of the disclosure of the present specification.
[0177] Figures 7a and 7b illustrate examples of providing an indirect path indication when adding an inter-DU indirect path in addition to a direct path.
[0178] In the examples of FIGS. 7a and 7b, multi-path transmission can be performed by creating a direct path and an indirect path for each DU in an inter-DU situation. In this case, the CU-CP can inform the CU-UP of the bearer and / or TNL address information related to the indirect path.
[0179] The examples in FIGS. 7a and 7b assume an inter-DU situation where the direct path and indirect path are connected to DU1 and DU2, respectively, but this is merely an example. The first example disclosed in this specification is also applicable to cases where DU1 and DU2 are identical.
[0180] Step 0: The Remote UE is directly connected to the NG-RAN via DU1. Therefore, the Remote UE can transmit and receive DL / UL data to and from the NG-RAN via DU1 (i.e., via a direct path).
[0181] Step 1: The Remote UE can receive a measurement configuration from the NG-RAN. Based on the measurement configuration, the Remote UE can perform measurement / discovery operations on surrounding Uu cells and / or Relay UEs, and then report the results to the NG-RAN. The results of the operations can include the L2 U2N Relay UE ID, serving cell ID, sidelink measurement results, and Uu link measurements of candidate relay UEs located nearby.
[0182] Step 2: Based on the measurement results received in Step 1, the CU-CP can select a relay UE that can reach the same NG-RAN. Relay UEs may have different serving gNBs. Remote UEs may need to receive services from the same base station via both direct and indirect paths. Therefore, from the base station's perspective, only relay UEs connected to it can be considered as targets for indirect paths.
[0183] CU-CP may decide to create an additional indirect path through the Relay UE and transmit DL / UL data to the Remote UE through multi-path.
[0184] Step 3: To enable the Relay UE to serve the Remote UE, the CU-CP, CU-UP, and DU can perform reconfiguration for the Relay UE in advance.
[0185] Step 4: CU-CP can request DU2 to set up UE context for Remote UE and allocate resources for Bearer using UE CONTEXT SETUP REQUEST message. After completing UE context setup and resource allocation, DU2 can respond to CU-CP with UE CONTEXT SETUP RESPONSE message including F1-U DL TNL address.
[0186] NOTE: If DU1 and DU2 are the same, CU-CP may perform UE Context Modification procedure in step 4.
[0187] Step 5: The CU-CP may send a BEARER CONTEXT MODIFICATION REQUEST message to the CU-UP. For example, the BEARER CONTEXT MODIFICATION REQUEST message may include UP Transport Layer information and an indirect path indication. For example, the indirect path indication may inform the CU-UP that an indirect path is used in a multi-path situation. For example, the indirect path indication may inform the CU-UP that multi-path transmission is required for the Remote UE, that an additional indirect path through a Relay UE must be created for the CU-UP for multi-path transmission, and / or information related to an F1-U DL TNL address associated with the indirect path.
[0188] NOTE: For reference, CU-CP may also inform CU-UP of information related to the F1-U DL TNL address associated with the direct path.
[0189] Step 6: The CU-UP may send a Bearer Context Modification Response message to the CU-CP. For example, based on the information received in Step 5, the CU-UP may additionally allocate an F1-U UL TNL address for the newly created indirect path for multi-path transmission of the Remote UE. The CU-UP may send a BEARER CONTEXT MODIFICATION RESPONSE message to the CU-CP, including the F1-U UL TNL address for the indirect path.
[0190] NOTE: The CU-CP may also inform the CU-UP in Step 5 that a specific bearer of the Remote UE is associated with a specific Relay UE or indirect path. In this case, the CU-UP may perform the above actions in Step 6 based on the fact that a specific bearer is associated with a specific Relay UE or indirect path.
[0191] Step 7: The remaining steps of the Signaling procedure of inter-DU indirect path addition on top of direct path procedure according to the examples of FIGS. 10a and 10b are performed.
[0192] Remote UE and NG-RAN can transmit and receive DL / UL data using both the direct path via Uu link and the indirect path via Relay UE.
[0193] NOTE: If DU1 and DU2 are the same, the remaining steps of the Signaling procedure of intra-DU indirect path addition on top of direct path procedure of Fig. 12 may be performed.
[0194] Step 8: DU1 and DU2 can successfully transmit the DL data received from the CU-UP to the Remote UE or Relay UE. In this case, DU1 and DU2 can each transmit DDDS to the CU-UP. DU1 and DU2 can each notify the CU-UP that they have successfully transmitted the DL data to the Remote UE or Relay UE through DDDS. The DDDS may include the Highest successfully delivered NR PDCP Sequence Number and / or the Number of successfully delivered out-of-sequence PDCP Sequence Number ranges.
[0195] For reference, Table 3 is an example of the DDS transmitted by the DU. For example, Table 3 shows the DL DATA DELIVERY STATUS (PDU Type 1) Format.
[0196]
[0197] Table 3 is an example of the DL DATA DELIVERY STATUS (PDU Type 1) Format. The DDDS transmitted by the DU may have the same format as the example in Table 3.
[0198] NOTE: Instead of the CU-CP indicating to the CU-UP in Step 5 that a particular F1-U DL TNL address is associated with an indirect path or a Relay UE (e.g., an indirect path indication), the following may be performed. For example, in Step 8, the DU may send the CU-UP a DDDS containing information that data is to be transmitted to the Remote UE via a Relay UE. Therefore, the CU-UP can know, based on the information received in Steps 5 and 8, that the same Bearer is associated with two RLCs, one of which is the indirect path. Accordingly, the CU-UP may perform the actions of Step 9.
[0199] Step 9: Based on the information received in Step 8, CU-UP can handle PDCP PDU.
[0200] (CASE 1) For example, unlike the prior art, for a DU that transmitted a DDDS associated with an F1-U UL Transport Network Layer (TNL) address allocated for an indirect path, the CU-UP may not transmit information to the DU to delete a successfully transmitted DL data packet. For example, the CU-UP may not perform an action to notify DU1 to delete a DL data packet having a PDCP Sequence Number (SN) equal to the Highest successfully delivered NR PDCP Sequence Number and / or the Number of successfully delivered out of sequence PDCP Sequence Number range included in the DDDS transmitted by DU2 through the F1-U UL TNL address allocated for the indirect path in Step 6.
[0201] When the operation related to Case 1 is performed, even if the Relay UE fails to transmit the DL data on the PC5 link of the Indirect path, the Remote UE can receive it through the Direct path.
[0202] (CASE 2) Conversely, for a DU that transmitted a DDDS associated with the F1-U UL TNL address assigned for the direct path, the CU-UP can send information to the DU to discard the DL data packets that were successfully transmitted. For example, the CU-UP can instruct DU2 to discard the DL data packets with PDCP SNs equal to the Highest successfully delivered NR PDCP Sequence Number and / or the Number of successfully delivered out of sequence PDCP Sequence Number range contained in the DDDS that DU1 forwarded via the F1-U UL TNL address assigned for the direct path.
[0203] For example, if DDDS is received first from the direct link, Case 2 may be executed. Conversely, if DDDS is received first from the indirect path, Case 1 may be executed.
[0204] Alternatively, if the Primary path is set to a Direct link, Case 2 may be executed, and if the Primary path is set to an Indirect path, Case 1 may be executed. However, even in this case, if DDDS is received first from a link other than the Primary path, either Case 1 or Case 2 may be executed depending on whether the Primary path is a Direct link or an Indirect link.
[0205] NOTE: For reference, if DU1 and DU2 are the same, CU-UP can operate as in CASE 1 above for the DDDS transmitted by DU through F1-U UL TNL address assigned for indirect path in Step 6. Conversely, CU-UP can operate as in CASE 2 above for the DDDS transmitted by DU through F1-U UL TNL address assigned for direct path.
[0206] 2. Second example of disclosure of this specification
[0207] Hereinafter, a first example of the disclosure of the present specification related to adding an indirect path is described with reference to FIGS. 8a and 8b.
[0208] The following drawings are intended to illustrate specific examples of the present specification. The names of specific devices and the names of specific signals / messages / fields depicted in the drawings are provided for illustrative purposes only, and the technical features of this specification are not limited to the specific names used in the drawings.
[0209] FIG. 8a and FIG. 8b illustrate examples of a direct path addition procedure according to the second example of the disclosure of the present specification.
[0210] Figures 8a and 8b illustrate examples of providing an indirect path indication when adding an inter-DU direct path in addition to an indirect path.
[0211] In the examples of FIGS. 8A and 8B, multi-path transmission can be performed by creating a direct path and an indirect path for each DU in an inter-DU situation. In this case, the CU-CP can inform the CU-UP of the bearer and / or TNL address information related to the indirect path.
[0212] The examples in FIGS. 8A and 8B assume an inter-DU situation where the direct path and indirect path are connected to DU1 and DU2, respectively, but this is merely an example. The second example disclosed in this specification is also applicable to cases where DU1 and DU2 are identical.
[0213] Step 0: The Remote UE is directly connected to the NG-RAN via the Relay UE and DU2. Therefore, the Remote UE can transmit and receive DL / UL data to and from the NG-RAN via the Relay UE and DU2 (i.e., via a direct path).
[0214] NOTE: Instead of performing the operation of Step 5, during the process of creating an indirect path in Step 0, the CU-CP may also transmit the information transmitted in Step 5 to the CU-UP. For example, the CU-CP may transmit to the CU-UP that Multi-path transmission is required for the Remote UE, that an Indirect path through the Relay UE must be created in advance for the Multi-path transmission, and information related to the F1-U DL TNL address associated with the indirect path.
[0215] Step 1: It can be performed in the same manner as step 1 of Fig. 7a and Fig. 7b.
[0216] Step 2: Based on the measurement results received in Step 1, the CU-CP can select a Uu cell that can reach the same NG-RAN. The CU-CP can additionally create a direct path through the cell and decide to transmit DL / UL data to the remote UE via multipath.
[0217] Step 3: CU-CP can request DU1 to set up UE context for Remote UE and allocate resources for Bearer using UE CONTEXT SETUP REQUEST message. After completing UE context setup and resource allocation, DU1 can respond to CU-CP using UE CONTEXT SETUP RESPONSE message including F1-U DL TNL address.
[0218] NOTE: If DU1 and DU2 are the same, CU-CP may perform the UE Context Modification procedure in Step 3.
[0219] Step 4: If some bearers being serviced through the Relay UE are changed to the direct path, or if some QoS is updated, the CU-CP, CU-UP, and DU can perform reconfiguration for the Relay UE in advance.
[0220] Step 5: The CU-CP may send a BEARER CONTEXT MODIFICATION REQUEST message to the CU-UP. For example, the BEARER CONTEXT MODIFICATION REQUEST message may include UP Transport Layer information and an indirect path indication. For example, the indirect path indication may inform the CU-UP that multipath transmission is required for the Remote UE and information related to the F1-U DL TNL address associated with the indirect path.
[0221] NOTE: For reference, CU-CP can also inform CU-UP about the information related to the F1-U DL TNL address associated with the direct path.
[0222] Step 6: Based on the information received in Step 5, the CU-UP may additionally allocate an F1-U UL TNL address for the newly created direct path for multi-path transmission of the Remote UE. The CU-UP may send a BEARER CONTEXT MODIFICATION RESPONSE message to the CU-CP, including the F1-U UL TNL address for the direct path. The CU-UP may also update the previously allocated F1-U UL TNL address for the indirect path.
[0223] NOTE: The CU-CP may inform the CU-UP in Step 0 or Step 5 that a specific bearer of the Remote UE is associated with a specific Relay UE or indirect path. In this case, the CU-UP may perform the above actions in Step 6 based on the fact that a specific bearer of the Remote UE is associated with a specific Relay UE or indirect path.
[0224] Step 7: The remaining steps of the signaling procedure of inter-DU direct path addition on top of indirect path according to the examples of FIGS. 9a and 9b are performed.
[0225] Remote UE and NG-RAN can transmit and receive DL / UL data using both the direct path via Uu link and the indirect path via Relay UE.
[0226] NOTE: If DU1 and DU2 are the same, the remaining steps of the Signaling procedure of intra-DU direct path addition on top of indirect path procedure of Fig. 11 may be performed.
[0227] Step 8: It can be performed in the same manner as step 8 of FIG. 7a and FIG. 7b.
[0228] In Step 8, Table 3, which is an example of the DL DATA DELIVERY STATUS (PDU Type 1) Format, can be used.
[0229] NOTE: Instead of the CU-CP indicating to the CU-UP in Step 0 or Step 5 that a particular F1-U DL TNL address is associated with an indirect path or a Relay UE (e.g., an indirect path indication), the following may be performed. For example, in Step 8, the DU may send the CU-UP a DDDS containing information that data is to be transmitted to the Remote UE via a Relay UE. Thus, the CU-UP can know, based on the information obtained in Steps 5 and 8, that the same Bearer is associated with two RLCs, one of which is the indirect path. Accordingly, the CU-UP may perform the actions of Step 9.
[0230] Step 9: Based on the information received in Step 8, CU-UP can handle PDCP PDU.
[0231] (CASE 1) For example, unlike the prior art, for a DU that transmitted a DDDS related to the F1-U UL TNL address allocated for the indirect path, the CU-UP may not transmit information to the DU to delete a successfully transmitted DL data packet. For example, the CU-UP may not perform an action to notify DU1 to delete a DL data packet having a PDCP SN equal to the Highest successfully delivered NR PDCP Sequence Number and / or Number of successfully delivered out of sequence PDCP Sequence Number range included in the DDDS transmitted by DU2 through the F1-U UL TNL address allocated for the indirect path in Step 6.
[0232] When the operation related to Case 1 is performed, even if the Relay UE fails to transmit the DL data on the PC5 link of the Indirect path, the Remote UE can receive it through the Direct path.
[0233] (CASE 2) Conversely, for a DU that transmitted a DDDS associated with the F1-U UL TNL address assigned for the direct path, the CU-UP can send information to the DU to discard the DL data packets that were successfully transmitted. For example, the CU-UP can instruct DU2 to discard the DL data packets with PDCP SNs equal to the Highest successfully delivered NR PDCP Sequence Number and / or the Number of successfully delivered out of sequence PDCP Sequence Number range contained in the DDDS that DU1 forwarded via the F1-U UL TNL address assigned for the direct path.
[0234] For example, if DDDS is received first from the direct link, Case 2 may be executed. Conversely, if DDDS is received first from the indirect path, Case 1 may be executed.
[0235] Alternatively, if the Primary path is set to a Direct link, Case 2 may be executed, and if the Primary path is set to an Indirect path, Case 1 may be executed. However, even in this case, if DDDS is received first from a link other than the Primary path, either Case 1 or Case 2 may be executed depending on whether the Primary path is a Direct link or an Indirect link.
[0236] NOTE: For reference, if DU1 and DU2 are the same, CU-UP can operate as in CASE 1 above for the DDDS transmitted by DU through F1-U UL TNL address assigned for indirect path in Step 6. Conversely, CU-UP can operate as in CASE 2 above for the DDDS transmitted by DU through F1-U UL TNL address assigned for direct path.
[0237] 3. Third example of disclosure of this specification
[0238] The third example of the disclosure of this specification illustrates a case where a multi-path transition occurs to a single path. Both direct and indirect paths may be used, or only the indirect path or the direct path may be used.
[0239] While a Remote UE is transmitting data via multipath, it may switch to single-path transmission by releasing the direct path or indirect path. In this case, the CU-CP can explicitly notify the CU-UP that it is switching to single-path transmission by sending a BEARER CONTEXT MODIFICATION REQUEST message to the CU-UP. In this case, the CU-UP can be aware that it no longer needs to perform the operation described with reference to Step 9 of FIGS. 7a and 7b or Step 9 of FIGS. 8a and 8b.
[0240] NOTE: The CU-CP can notify the CU-UP that the Remote UE is about to switch to single-path transmission by releasing the direct path or indirect path while transmitting data via multi-path in the following ways. For example, the CU-CP can implicitly notify the CU-UP that single-path is being used by including only the DL TNL address related to single-path in the BEARER CONTEXT MODIFICATION REQUEST message. For example, the BEARER CONTEXT MODIFICATION REQUEST message may not include two DL TNL addresses (i.e., DL TNL address for direct path and DL TNL address for indirect path) for the bearer with multi-path applied, but may only include one DL TNL address. In this case, the CU-UP can determine that the Remote UE has switched to single-path transmission.
[0241] Below, various examples to which the disclosure of this specification is applied or implemented are described.
[0242] The fourth example of the disclosure of this specification describes a specific example to which at least one of the first to third examples of the disclosure of this specification is applied.
[0243] 4. Fourth example of disclosure of this specification
[0244] Describes a rescue plan to support multipath.
[0245] Describes the impact on PDCP duplication.
[0246] In legacy PDCP duplication, a node (e.g., DU) transmits a DDDS frame containing the successfully delivered PDCP SN to the node hosting the PDCP entity (e.g., CU-UP). The node hosting the NR PDCP entity (e.g., CU-UP) then decides whether to discard the PDCP PDU and forwards DL USER DATA to that node, requesting discard of the duplicated PDCP PDU. In general, this mechanism can be reused in multipath operation as well.
[0247] In packet duplication in Scenario 1, the PDCP entity does not need to indicate to the Uu RLC entity to discard the PDCP PDU when the PC5 RLC entity notifies the successful PDCP PDU transmission. For example, even if a DDDS containing a successfully delivered PDCP SN is provided from a node in the indirect path (i.e., a DU involved in the indirect path), the node hosting the PDCP entity must not request the corresponding node in the direct path to discard the duplicate PDCP PDU. In the prior art, the gNB-CU-UP does not know the DRBs associated with the indirect path. Therefore, during the direct path addition or indirect path addition procedure, the gNB-CU-CP must inform the gNB-CU-UP which DRBs are associated with the indirect path.
[0248] Proposal: During the direct path addition or indirect path addition procedure, the gNB-CU-CP should inform the gNB-CU-UP of the DRBs associated with the indirect path.
[0249] Below, an indirect path indicator, which is an example of an indirect path indication described in the disclosure of this specification, is described. The indirect path indicator may be provided as shown in the example below.
[0250] The CU-CP can transmit UP parameters to the CU-UP. For example, an Information Element (IE) such as the example in Table 4 below can provide information related to the DRB configured in the gNB-CU-UP.
[0251]
[0252] According to the example in Table 4, the CU-CP can transmit an UP parameter list. The UP parameter list can include UP parameter items. The UP parameter items can include UP Transport layer information and an indirect path indicator. The indirect path indicator indicates an indirect path in multi-path operation.
[0253] For example, if the CU-CP transmits an indirect path indicator to the CU-UP, the CU-UP can know the indirect path of the multi-path operation.
[0254] Referring to FIGS. 9A and 9B to 12, examples of procedures for supporting multi-path are described.
[0255] Referring to FIGS. 9a and 9b, an example of adding an inter-DU direct path on top of an indirect path is described.
[0256] The following drawings are intended to illustrate specific examples of the present specification. The names of specific devices and the names of specific signals / messages / fields depicted in the drawings are provided for illustrative purposes only, and the technical features of this specification are not limited to the specific names used in the drawings.
[0257] FIG. 9A and FIG. 9B are examples of adding a direct path between DUs according to one embodiment of the disclosure of the present specification.
[0258] Figures 9a and 9b are examples of signaling flows for adding a direct path between DUs. Figures 9a and 9b are examples of signaling procedures for adding a direct path between DUs over an indirect path.
[0259] 1. Signaling for Uu measurement setup and measurement reporting is performed between the remote UE and the gNB-CU. Step 1 is performed to evaluate both relay link measurements and Uu link measurements. The remote UE can report Uu measurement results of one or more candidate relay UEs to neighboring cells.
[0260] 2. The gNB-CU may decide to add a direct path to the remote UE from another gNB-DU (i.e., gNB-DU1).
[0261] 3. The gNB-CU may send a UE context setup request message (including direct path setup) for the remote UE to the gNB-DU1.
[0262] 4. gNB-DU1 responds to gNB-CU with a UE context setup response message.
[0263] 5. The gNB-CU sends an RRCReconfiguration message to the relay UE to update the indirect path configuration if necessary.
[0264] 6. The gNB-CU sends a UE CONTEXT MODIFICATION REQUEST message containing an RRCReconfiguration message to the gNB-DU2 for the remote UE. The content of the RRCRecfiguration message may include at least the direct path additional configuration, RLC channel configuration, bearer mapping, and the associated radio bearer.
[0265] 7. gNB-DU2 sends an RRCRecfiguration message to the remote UE.
[0266] 8. gNB-DU2 sends a UE context modification response message to gNB-CU.
[0267] 9. The remote UE performs a random access procedure on gNB-DU1.
[0268] 10. The remote UE sends an RRCReconfigurationComplete message to gNB-DU2 to complete the direct path addition procedure. In multipath communication via L2 U2N relay, the RRCReconfigurationComplete message can always be sent via the direct path (i.e., gNB-DU1) when adding / changing a path. In case of split SRB1 with PDCP overlap, the remote UE can send the RRCReconfigurationComplete message to gNB-CU via both paths.
[0269] 11. gNB-DU2 transmits a UL RRC Message Transmission message containing an RRCReconfigurationComplete message to gNB-CU.
[0270] Referring to FIGS. 10a and 10b, an example of adding an inter-DU indirect path on top of a direct path is described.
[0271] The following drawings are intended to illustrate specific examples of the present specification. The names of specific devices and the names of specific signals / messages / fields depicted in the drawings are provided for illustrative purposes only, and the technical features of this specification are not limited to the specific names used in the drawings.
[0272] FIG. 10A and FIG. 10B are examples of adding an indirect path between DUs according to one embodiment of the disclosure of the present specification.
[0273] Figures 10a and 10b are examples of signaling flows for adding an indirect path between DUs. Figures 10a and 10b are examples of signaling procedures for adding an indirect path between DUs on top of a direct path.
[0274] 1. It can be performed in the same manner as step 1 of FIG. 9a and FIG. 9b.
[0275] Otherwise, the remote UE connects to the relay UE using a non-3GPP link, and the remote UE reports at least the C-RNTI of the relay UE and the cell ID of the serving relay UE.
[0276] 2. The gNB-CU decides to add an indirect path to the remote UE through the relay UE to another gNB-DU (i.e., gNB-DU2).
[0277] 3. If the relay UE is in RRC_CONNECTED state, a reconfiguration for the relay UE is performed between the relay UE, gNB-DU2, and gNB-CU. The gNB-CU sends an RRCReconfiguration message to the relay UE. This step is skipped if the relay UE is in RRC_IDLE / INACTIVE state.
[0278] 4. The gNB-CU sends a UE context setup request message to the gNB-DU2 for the remote UE, which includes at least an indirect path setup.
[0279] 5. gNB-DU2 responds to gNB-CU with a UE context setup response message.
[0280] 6. The gNB-CU sends an RRCReconfiguration message containing a DL RRC message transfer message for the remote UE to the gNB-DU1. The content of the RRCReconfiguration message may include at least direct path addition configuration, RLC channel configuration, bearer mapping, and associated radio bearers.
[0281] 7. gNB-DU1 sends an RRCReconfiguration message to the remote UE.
[0282] 8. If the remote UE using the side link does not have a PC5 connection with the target relay UE, the remote UE establishes a PC5 connection with the relay UE. If the remote UE uses a non-3GPP link, this step is omitted.
[0283] 9. The remote UE can complete the indirect path addition procedure by sending an RRCReconfigurationComplete message to gNB-DU1. If the U2N relay UE is in RRC_IDLE / RRC_INACTIVE state, when the PC5-RRC message is received from the U2N remote UE, the RRC setup / resume procedure for the U2N relay UE to enter RRC_CONNECTED state is triggered first. In case of split SRB1 with PDCP overlap, the RRCReconfurationComplete message may trigger the RRC setup / resume procedure of the U2N relay UE to enter RRC_CONNECTED state.
[0284] 10. gNB-DU1 transmits a UL RRC Message Transmission message containing an RRCReconfigurationComplete message to gNB-CU.
[0285] Referring to FIG. 11, an example of adding an intra-DU direct path on top of an indirect path is described.
[0286] The following drawings are intended to illustrate specific examples of the present specification. The names of specific devices and the names of specific signals / messages / fields depicted in the drawings are provided for illustrative purposes only, and the technical features of this specification are not limited to the specific names used in the drawings.
[0287] FIG. 11 is an example of adding a direct path within a DU according to one embodiment of the disclosure of the present specification.
[0288] Figure 11 is an example of a signal flow for adding a direct path within a DU. Figure 11 is an example of a signaling procedure for adding a direct path within a DU over an indirect path.
[0289] 1. It can be performed in the same manner as step 1 of FIG. 9a and FIG. 9b.
[0290] 2. The gNB-CU decides to add a direct path to the remote UE in the same gNB-DU.
[0291] 3. The gNB-CU sends a UE context modification request message to the gNB-DU, which includes a minimum direct path setup for the remote UE.
[0292] 4. The gNB-DU responds to the gNB-CU with a UE context modification response message.
[0293] 5. The gNB-CU sends an RRCReconfiguration message to the relay UE to update the indirect path configuration if necessary.
[0294] 6. The gNB-CU sends a DL RRC Message Transmission message for the remote UE containing an RRCReconfiguration message to the gNB-DU. The content of the RRCReconfiguration message may include at least direct path addition configuration, RLC channel configuration, bearer mapping, and associated radio bearers.
[0295] 7. The gNB-DU sends an RRCReconfiguration message to the remote UE.
[0296] 8. The remote UE performs a random access procedure on the gNB-DU.
[0297] 9. The remote UE can send an RRCReconfigurationComplete message to the gNB-DU to complete the direct path addition procedure. In multipath communication via L2 U2N relay, the RRCReconfigurationComplete message is always sent via the direct path when adding / changing a path. In case of split SRB1 with PDCP overlap, the remote UE can send the RRCReconfigurationComplete message to the gNB-CU via both paths.
[0298] 10. The gNB-DU transmits a UL RRC Message Transmission message containing an RRCReconfigurationComplete message to the gNB-CU.
[0299] Referring to Fig. 12, an example of adding an intra-DU indirect path on top of a direct path is described.
[0300] The following drawings are intended to illustrate specific examples of the present specification. The names of specific devices and the names of specific signals / messages / fields depicted in the drawings are provided for illustrative purposes only, and the technical features of this specification are not limited to the specific names used in the drawings.
[0301] FIG. 12 is an example of adding an indirect path within a DU according to one embodiment of the disclosure of the present specification.
[0302] Figure 12 is an example of a signal flow for adding an indirect path within a DU. Figure 12 is an example of a signaling procedure for adding an indirect path within a DU on top of a direct path.
[0303] 1. It can be performed in the same manner as step 1 of FIG. 10a and FIG. 10b.
[0304] 2. The gNB-CU decides to add an indirect path to a remote UE under the same gNB-DU via a relay UE.
[0305] 3. If the relay UE is in RRC_CONNECTED state, a reconfiguration for the relay UE is performed between the relay UE, gNB-DU, and gNB-CU. The gNB-CU sends an RRCReconfiguration message to the relay UE. This step is skipped if the relay UE is in RRC_IDLE / INACTIVE state.
[0306] 4. The gNB-CU sends a UE context modification request message to the gNB-DU containing the minimum indirect path setup for the remote UE.
[0307] 5. The gNB-DU responds to the gNB-CU with a UE context modification response message.
[0308] 6. The gNB-CU sends a DL RRC MESSAGE TRANSFER message to the gNB-DU for the remote UE, containing an RRCReconfiguration message. The content of the RRCReconfiguration message may include at least the indirect path addition setup, PC5 RLC channel configuration for relay traffic, bearer mapping, and the associated radio bearer.
[0309] 7. The gNB-DU sends an RRCReconfiguration message to the remote UE.
[0310] 8. If the remote UE using the side link does not have a PC5 connection with the target relay UE, the remote UE establishes a PC5 connection with the relay UE. If the remote UE uses a non-3GPP link, this step is omitted.
[0311] 9. The remote UE can complete the indirect path addition procedure by sending an RRCReconfigurationComplete message to the gNB-DU. If the U2N relay UE is in RRC_IDLE / RRC_INACTIVE state, when the PC5-RRC message is received from the U2N remote UE, the RRC setup / resume procedure for the U2N relay UE to enter the RRC_CONNECTED state is triggered first. In case of split SRB1 with PDCP overlap, the RRCReconfurationComplete message may also trigger the RRC setup / resume procedure of the U2N relay UE to enter the RRC_CONNECTED state.
[0312] 10. The gNB-DU transmits a UL RRC Message Transmission message containing an RRCReconfigurationComplete message to the gNB-CU.
[0313] 5. Fifth example of disclosure of this specification
[0314] Describes an example of a rescue measure to support multipathing.
[0315] The fifth example of the disclosure of this specification may be applied to the following cases.
[0316] For example, a CU-CP may send a bearer context modification request message to a CU-UP. The CU-UP may send a bearer context modification response message to the CU-CP. When these actions are performed, the fifth example of the disclosure of the present specification may be applied.
[0317] The operation according to the fifth example of the disclosure of the present specification may be combined with at least one of the first to fourth examples of the disclosure of the present specification described above. The bearer context modification request message may include a DRB To Modify List IE. The DRB To Modify List IE may include a PDCP configuration IE. The PDCP configuration IE may include a PDCP Duplication IE or an additional PDCP duplication information IE.
[0318] The DRB To Modify List IE may include a DL UP Parameter IE. The DU UP Parameter IE may include an Indirect Path Indication IE. The indirect path indication may be used for L2 U2N remote UEs and L2 Multi-Path (MP) remote UEs using the PC5 link.
[0319] The CU-CP can send a Bearer Context Modification Request message to the CU-UP. The Bearer Context Modification Request message may include both the PDCP Duplication IE and the Indirect Path Indication IE. In this case, the CU-UP can recognize the UP TNL information associated with the Indirect Path Indication IE as the indirect path in a multi-path situation. Based on the DDDS received from the path based on the UP TNL information (i.e., the indirect path), the CU-UP may not send a command to the DU on the direct path side to delete duplicated PDCP PDUs.
[0320] For example, the PDCP Duplication IE or the additional PDCP Duplication Information IE may be included in the PDCP Configuration IE, and the Indirect Path Indication IE may be included in the DL UP parameter IE of the Modify Bearer Context Request message. In this case, the gNB-CU-UP may not request discarding of duplicated DL data for the UP Transport Layer Information IE without the Indirect Path Indication IE. That is, in this case, even if a DDDS is received from a DU, the gNB-CU-UP may not request discarding of duplicated DL data for the DU related to the direct path (e.g., the DU related to the UP Transport Layer Information IE without the Indirect Path Indication IE).
[0321] Note that the Indirect Path Indication IE may be an IE that the CU-CP notifies the CU-UP that there is a single indirect path. Upon receiving the Indirect Path Indication IE from the CU-CP, the CU-UP may perform operations for DL lossless handover (HO).
[0322] For reference, the Indirect Path Indication IE of the fifth example of the disclosure of the present specification described in the paragraph immediately above may be an Indirect Path Indication IE according to the prior art. Meanwhile, the Indirect Path Indication IE of the fifth example of the disclosure of the present specification may be replaced with an indirect path indication newly defined in the first to fourth examples of the disclosure of the present specification. That is, the operations described in the fifth example of the disclosure of the present specification may be performed based on the indirect path indication newly defined in the first to fourth examples of the disclosure of the present specification.
[0323] For example, the CU-CP may receive a bearer context modification request message containing only an Indirect Path Indication IE without a PDCP Duplication IE. In this case, the CU-UP can perform a DL lossless handover in a single indirect path situation.
[0324] For another example, the CU-CP may receive a bearer context modification request message that includes both a PDCP Duplication IE and an Indirect Path Indication IE. In this case, the CU-CP may inform the CU-UP which UP TNL information is associated with the indirect path in a multi-path situation. Then, the gNB-CU-UP may not request to discard duplicated DL data for UP Transport Layer Information IEs that do not have an Indirect Path Indication IE. That is, in this case, even if a DDDS is received from a DU, the gNB-CU-UP may not request to discard duplicated DL data for DUs associated with the direct path (e.g., DUs associated with UP Transport Layer Information IEs that do not have an Indirect Path Indication IE).
[0325] Additionally, the fifth example of the disclosure of this specification can also be applied to the bearer context setup procedure based on Figure 8.9.2-1 of TS38.401 V18.3.0.
[0326] For example, the bearer context setup procedure may perform the following actions:
[0327] 0. Bearer context setup can be triggered in gNB-CU-UP.
[0328] 1. gNB-CU-UP can send a bearer context setup request message to gNB-CU-CP.
[0329] 2. gNB-CU-CP can send a bearer context setup response message to gNB-CU-UP.
[0330] 3. gNB-DU and gNB-CU-CP can perform the F1 UE context setup procedure.
[0331] 4. The gNB-CU-CP may send a bearer context modification request message to the gNB-CU-UP. The DU may also send uplink user data to the gNB-CU-UP.
[0332] In step 4, the fifth example of the disclosure of this specification can be applied as follows.
[0333] If information related to PDCP duplication is not included in the bearer context modification request message and an indirect path indication is included in the bearer context modification request message, the gNB-CU-UP may not discard DL data based on the Downlink Data Delivery Status frame received from the gNB-DU. If both PDCP duplication and indirect path indication are received in step 4, the gNB-CU-UP may not request the RLC entity for the direct path to discard duplicated DL data based on the Downlink Data Delivery Status frame received from the RLC entity for the indirect path.
[0334] 5. The gNB-CU-UP may send a bearer context modification response message to the gNB-CU-CP. The gNB-CU-UP may also send downlink user data to the DU.
[0335] The following drawings are intended to illustrate specific examples of the present specification. The names of specific devices and the names of specific signals / messages / fields depicted in the drawings are provided for illustrative purposes only, and the technical features of this specification are not limited to the specific names used in the drawings.
[0336] FIG. 13 illustrates an example of a procedure according to one embodiment of the disclosure of the present specification.
[0337] For reference, the procedure illustrated in FIG. 13 is merely an example, and the scope of the disclosure of this specification is not limited by the example in FIG. 13.
[0338] For example, with respect to the example of FIG. 13, the operations described in the examples of FIGS. 1 to 12 may also be applied. For example, even if operations, contents, etc. are not directly described in the example of FIG. 13, operations, contents, etc. described in various examples of the disclosure of this specification may be applied.
[0339] DU, CU-UP, and CU-CP may be included in a single NG-RAN. DU may be referred to as gNB-DU, CU-UP as gNB-CU-UP, and CU-CP as gNB-CU-CP.
[0340] In step (S1301), the CU-CP may send a bearer context modification request message to the CU-UP.
[0341] For example, a bearer context modification request message may include information related to multipath operation and indirect path indications.
[0342] For example, an indirect path indication may include F1-U Uplink Transport Network Layer (F1-U DL TNL) address information associated with the indirect path.
[0343] For example, based on the bearer context modification request message, the CU-UP can allocate an F1-U UL TNL address for the indirect path.
[0344] In step (S1302), the CU-UP may send a bearer context modification response message to the CU-CP.
[0345] In step (S1303), the DU may transmit a message related to the data transfer status to the CU-UP. For example, the message related to the data transfer status may mean a DDDS frame.
[0346] At step (S1304), the CU-UP may decide whether to transmit information to the DU.
[0347] For example, the CU-UP may determine whether to transmit information to the DU to discard downlink data associated with the DDDS frame.
[0348] For example, based on a decision not to transmit information for discarding downlink data, information for discarding downlink data may not be transmitted to the DU.
[0349] For example, based on the DDDS frame being associated with the F1-U UL TNL address for the indirect path, the CU-UP may decide not to transmit information to discard downlink data.
[0350] For example, information for discarding downlink data may be information for discarding a downlink data packet related to a PDCP sequence number that is identical to the PDCP sequence number related to the “successfully delivered PDCP sequence” included in the DDDS frame.
[0351] For example, based on the DDDS frame being associated with the F1-U UL TNL address for the indirect path, the CU-UP may decide to transmit information to discard downlink data.
[0352] According to one embodiment of the disclosure of the present specification, in a multi-path transmission situation, the CU-CP may inform the CU-UP of the Bearer and / or TNL address associated with the indirect path.
[0353] For example, the CU-CP may notify the CU-UP that a multi-path has been created / allocated for the Remote UE during the Bearer Context Setup or Bearer Context Modification process for the Remote UE. Additionally, the CU-CP may notify the CU-UP of the Bearer and / or TNL address associated with the indirect path.
[0354] For example, based on information received from CU-CP and DU, CU-UP may not transmit a command to DU related to direct path to delete DL data successfully transmitted to Relay UE through indirect path.
[0355] The operations of the drawings based on the various examples described above may be performed individually or together with the operations of other drawings.
[0356] The above drawings can be executed individually or in conjunction with other drawings. Furthermore, the above drawings can be applied to both indirect and direct path change situations.
[0357] This specification may have various effects.
[0358] For example, according to the disclosure of this specification, a CU-UP can distinguish between data transmitted via a direct path and data transmitted via an indirect path in a multi-path situation. For example, even if a CU-UP receives an ack from a DU for DL data transmitted via an indirect path, it may not instruct the DU involved in the direct path to delete a copy of the same DL data packet. Effective communication can be supported for a remote UE. For example, from the remote UE's perspective, even if a relay UE fails to transmit the DL data on the PC5 link of the indirect path, the remote UE can receive it via the direct path.
[0359] The effects that can be achieved through the specific examples of this specification are not limited to the effects listed above. For example, a person with ordinary skill in the relevant technical field may understand or derive various technical effects 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.
[0360] For reference, the operation of the terminal (e.g., UE, remote UE, relay UE, etc.) described in this specification can be implemented by the devices of FIGS. 1 to 3 described above. For example, the terminal (e.g., UE, remote UE, relay UE, etc.) can be the first device (100) or the second device (200) of FIG. 2. For example, the operation of the terminal (e.g., UE, remote UE, relay UE, etc.) described in this specification can be processed by one or more processors (102 or 202). The operation of the terminal described in this specification can be stored in one or more memories (104 or 204) in the form of instructions / programs (e.g., instructions, executable codes) executable by one or more processors (102 or 202). One or more processors (102 or 202) may control one or more memories (104 or 204) and one or more transceivers (105 or 206), and execute instructions / programs stored in one or more memories (104 or 204) to perform operations of a terminal (e.g., UE) described in the disclosure of this specification.
[0361] In addition, commands for performing operations of a terminal (e.g., UE, remote UE, relay UE, etc.) described in the disclosure of this specification may be stored in a non-volatile computer-readable storage medium. The storage medium may be included in one or more memories (104 or 204). In addition, the commands recorded in the storage medium may be executed by one or more processors (102 or 202) to perform operations of a terminal (e.g., UE, remote UE, relay UE, etc.) described in the disclosure of this specification.
[0362] For reference, the operations of a network node (e.g., AMF, SMF, UPF, PCF, NEF, UDM, DN, etc.) or a base station (e.g., NG-RAN, gNB, gNB-DU, gNB-CU, DU, CU-UP, CU-CP, etc.) described in this specification may be implemented by the devices of FIGS. 1 to 3 described below. For example, the network node or the base station may be the first device (100) or the second device (200) of FIG. 2. For example, the operations of the network node or the base station described in this specification may be processed by one or more processors (102 or 202). The operations of the terminal described in this specification may be stored in one or more memories (104 or 204) in the form of instructions / programs (e.g., instructions, executable codes) executable by one or more processors (102 or 202). One or more processors (102 or 202) may control one or more memories (104 or 204) and one or more transceivers (106 or 206), and execute instructions / programs stored in one or more memories (104 or 204) to perform operations of a network node or base station as described in the disclosure of this specification.
[0363] Additionally, the instructions for performing the operations of the network node or base station described in the disclosure of this specification may be stored in a non-volatile (or non-transitory) computer-readable storage medium having the instructions recorded thereon. The storage medium may be included in one or more memories (104 or 204). In addition, the instructions recorded in the storage medium may be executed by one or more processors (102 or 202) to perform the operations of the network node or base station described in the disclosure of this specification.
[0364] Although the preferred embodiments have been described above by way of example, the disclosure of this specification is not limited to these specific embodiments, and may be modified, changed, or improved in various forms within the scope described in the spirit and claims of this specification.
[0365] In the exemplary system described above, the methods are described based on a flowchart as a series of steps or blocks. However, the order of the steps described is not limited, and some steps may occur in a different order or simultaneously with other steps described above. Furthermore, those skilled in the art will understand that the steps depicted in the flowchart are not exclusive, and other steps may be included, or one or more steps in the flowchart may be deleted without affecting the scope of the invention.
[0366] The claims set forth in this specification may be combined in various ways. For example, the technical features of the method claims of this specification may be combined to implement a device, and the technical features of the device claims of this specification may be combined to implement a method. Furthermore, the technical features of the method claims and the technical features of the device claims of this specification may be combined to implement a device, and the technical features of the method claims and the technical features of the device claims of this specification may be combined to implement a method. Other implementations are within the scope of the claims.
Claims
1. Step of receiving a bearer context modification request message from the Central Unit - Control Plane (CU-CP). The above bearer context modification request message includes information related to multipath operation and indirect path indication; A step of transmitting a bearer context modification response message to the CU-CP; A step of receiving a Downlink Data Delivery Status (DDDS) frame from a Distributed Unit (DU); and A method comprising a step of determining whether to transmit information for discarding downlink data related to the DDDS frame to the DU.
2. In paragraph 1, A method characterized in that information for discarding the downlink data is not transmitted to the DU based on a decision not to transmit information for discarding the downlink data.
3. In paragraph 1 or 2, A method characterized in that the above indirect path indication includes F1-U Uplink Transport Network Layer (F1-U DL TNL) address information related to the indirect path.
4. In any one of paragraphs 1 to 3, A method further comprising the step of allocating an F1-U UL TNL address for the indirect path based on the bearer context modification request message.
5. In any one of paragraphs 1 to 4, A method characterized in that it is determined not to transmit information for discarding the downlink data based on the DDDS frame being related to the F1-U UL TNL address for the indirect path.
6. In any one of paragraphs 1 to 5, A method characterized in that the information for discarding the above downlink data is information for discarding a downlink data packet related to a PDCP sequence number that is identical to a PDCP sequence number related to a successfully transmitted Packet Data Convergence Protocol (PDCP) sequence included in the DDDS frame.
7. In any one of paragraphs 1 to 6, A method characterized in that the DDDS frame is determined to transmit information for discarding the downlink data based on the F1-U UL TNL address for the indirect path.
8. In any one of paragraphs 1 to 7, A method characterized in that it is determined not to transmit information for discarding the downlink data based on the bearer context modification request message including both information related to an indirect path indication and PDCP duplication.
9. One or more transmitters and receivers; one or more processors; and comprising one or more memories capable of storing instructions and being operable to the one or more processors; A device wherein the operation performed based on the command being executed by the one or more processors is a method according to any one of claims 1 to 8.
10. Step of sending a bearer context modification request message to the Central Unit - User Plane (CU-UP). The above bearer context modification request message includes information related to multipath operation and indirect path indication; and comprising the step of receiving a bearer context modification response message from the CU-UP, A method characterized in that the indirect path indication is used to determine whether to transmit information for discarding downlink data related to a Downlink Data Delivery Status (DDDS) frame received by the CU-UP from a Distributed Unit (DU) to the DU.
11. In paragraph 10, A method characterized in that the above indirect path indication includes F1-U Uplink Transport Network Layer (F1-U DL TNL) address information related to the indirect path.
12. One or more transmitters and receivers; one or more processors; and comprising one or more memories capable of storing instructions and being operable to the one or more processors; A device wherein the operation performed based on the above command being executed by the one or more processors is a method according to any one of claims 10 or 11.
Citation Information
Patent Citations
Enhancing User Plane Contexts Management in New Radio (NR)
US20210176802A1
Method and apparatus for discarding buffered data while keeping connection in CP-up separation
US20210185755A1
Enhanced Handover of Nodes in Integrated Access Backhaul (IAB) Networks - Control Plane (CP) Handling
US20220201777A1