Method and apparatus for data forwarding in wireless network system

By communicating with each other between the CU-CP and CU-UP of the RAN node, the problems of data forwarding duplication and path determination in the NR-DC scenario are solved, and efficient indirect and direct data forwarding is achieved, improving the data forwarding efficiency and reliability of the network.

CN121729933APending Publication Date: 2026-03-24LG ELECTRONICS INC
View PDF 0 Cites 0 Cited by

Patent Information

Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Filing Date
2024-07-31
Publication Date
2026-03-24

AI Technical Summary

Technical Problem

In NR-DC scenarios, the source side may repeatedly forward data to the target node, especially when multiple T-MN nodes of the UE request CHO, resulting in repeated data forwarding of PDU sessions or DRBs. Furthermore, the availability of indirect data forwarding paths cannot be effectively determined at intermediate nodes (such as S-MN or T-MN), leading to low data forwarding efficiency.

Method used

The CU-CP of the RAN node in the wireless communication system sends a request message to the CU-UP, which contains information on indirect data forwarding and relevant information on receiving the transport layer. It then receives a response message from the CU-UP to perform indirect data forwarding, ensuring effective support for data forwarding when there is no direct path.

Benefits of technology

It enables efficient indirect and direct data forwarding during HO or DC processes, especially when there is no direct path between the source and destination nodes, ensuring that CU-UP can effectively perform data forwarding and improving the network's data forwarding efficiency and reliability.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN121729933A_ABST
    Figure CN121729933A_ABST
Patent Text Reader

Abstract

A method and apparatus for data forwarding in a wireless network system are provided. The CU-CP of the RAN node sends a first message to the CU-UP of the RAN node, the first message including (i) information requesting to perform indirect data forwarding, (ii) information related to a forwarding transport layer, and (iii) information requesting to allocate a receiving transport layer corresponding to the forwarding transport layer. The CU-CP receives a second message from the CU-UP in response to the first message, the second message including information related to the allocated receiving transport layer.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This disclosure relates to methods and apparatus for data forwarding in wireless network systems. Background Technology

[0002] The 3rd Generation Partnership Project (3GPP) Long Term Evolution (LTE) is a technology that enables high-speed packet communication. Many proposals have been put forward for LTE objectives, including those aimed at reducing costs for users and vendors, improving quality of service, and expanding and improving coverage and system capacity. As upper-layer requirements, 3GPP LTE needs to reduce cost per bit, increase service availability, allow flexible use of frequency bands, have a simple architecture, open interfaces, and appropriate power consumption for terminals.

[0003] The International Telecommunication Union (ITU) and 3GPP have begun developing requirements and specifications for New Radio (NR) systems. 3GPP must identify and develop the technical components needed for the successful standardization of the new RAT (Radio Access Technology) to meet both urgent market demands and the longer-term requirements outlined in the ITU Radiocommunication Sector (ITU-R) International Mobile Telecommunications (IMT)-2020 process. Furthermore, NR should be able to utilize any spectrum band, at least up to 100 GHz, that can be used for wireless communication even in the more distant future.

[0004] The goal of NR is a single technology framework that addresses all use cases, requirements, and deployment scenarios, including enhanced mobile broadband (eMBB), massive machine-type communications (mMTC), ultra-reliable and low-latency communications (URLLC), and more. NR should be inherently backward compatible. Summary of the Invention

[0005] Technical issues

[0006] The following is being discussed: How to optimize early data forwarding in a Chokepoint Request (CHO) in an NR-DC scenario, so that the NW (especially the source side) can avoid repeatedly forwarding data to the target node before the UE executes the CHO under NR-DC. Specifically, multiple T-MN nodes can request a CHO for the same UE, which may reach the same T-SN to prepare conditional configuration for the UE's SCG. In this case, data forwarding from the source side can occur on multiple paths toward the same T-SN. When the admission results of CHO NR-DC requests from different T-MNs are the same, this may lead to the forwarding of duplicate data from PDU sessions or DRBs established in the T-SN.

[0007] Additionally, support for indirect data forwarding is discussed where no direct path is available, i.e., when there is no direct path between the S-SN and T-SN, between the S-MN and T-SN, or between the S-SN and T-MN. In this case, the intermediate node (e.g., the S-MN or T-MN) should be able to determine whether indirect data forwarding is supported. If so, it needs to assign its own TNL (Transport Network Layer) address to receive the forwarded packets and relay them to their final destination accordingly.

[0008] However, it is assumed that this indirect data forwarding is implicitly supported in 3GPP, depending on the implementation. In the case of a unified gNB, the implementation is sufficient because the gNB can handle all control plane and user plane functions. On the other hand, when the gNB is divided into a control plane entity (gNB-CU-CP, also known as CU-CP) and a user plane entity (gNB-CU-UP, also known as CU-UP), this has not been specified. In this case, it is unclear how indirect data forwarding is supported in the CU-UP entity, which is dedicated to handling user plane functions.

[0009] Furthermore, intermediate nodes (e.g., S-MN or T-MN) need to know whether a PDU session or DRB undergoing data forwarding during HO or DC terminates in the MN or SN, in order to appropriately determine indirect forwarding support based on path availability. For example, the T-MN needs to know before triggering HO whether a PDU session that decides to terminate in the T-SN initially terminated in the S-MN or the S-SN. If it terminates in the S-SN but there is no direct path between the S-SN and T-SN (but there is a direct path between the S-SN and T-MN), the T-MN can decide to perform indirect forwarding for that PDU session. If it terminates in the S-MN but there is no direct path between the S-MN and T-SN, the T-MN can decide to perform indirect forwarding for that PDU session. On the other hand, if there is a direct path from the location where the PDU session (decided to terminate in the T-SN) was initially located on the source side to the T-SN, direct forwarding is possible, and the T-MN does not need to perform indirect data forwarding for that PDU session: it can simply forward the destination TNL address to the S-MN during HO preparation.

[0010] Similar logic applies to the S-MN. During HO preparation, the S-MN also needs to know whether the PDU session undergoing data forwarding was established in the MN or SN on the target side. If it was established in the T-SN but initially hosted in the S-SN and there is no direct path between the S-SN and T-SN, the S-MN can decide to perform indirect forwarding for that PDU session. The same applies if it was established in the T-MN but initially hosted in the S-SN and there is no direct path between the S-SN and T-MN. On the other hand, if there is a direct path between the S-SN and T-MN, direct forwarding is possible, and the S-MN has no reason to perform indirect data forwarding for that PDU session.

[0011] Given these considerations, information regarding whether a PDU session or DRB undergoing data forwarding terminates in the MN or SN on the destination (or source) side is crucial for the S-MN (or T-MN) to make informed decisions about indirect forwarding. Path availability is insufficient. Although it is assumed that the T-MN can be accessed via... Handover Preparation The inter-node RRC container determines whether a PDU session or DRB requested to be established during the HO is initially hosted in the S-MN or S-SN, but it is unclear how the S-MN knows whether a PDU session or DRB undergoing data forwarding is hosted in the T-MN or T-SN during HO preparation.

[0012] Therefore, it is necessary to study data forwarding in wireless network systems.

[0013] Technical solution

[0014] In one aspect, a method is provided performed by a central unit (CU)-control plane (CP) of a radio access network (RAN) node in a wireless communication system. The method includes the steps of: sending a first message to the CU-user plane UP of the RAN node, the first message including: (i) information requesting the execution of indirect data forwarding, (ii) information related to a forwarding transport layer, and (iii) information requesting the allocation of a receive transport layer corresponding to the forwarding transport layer; and in response to the first message, receiving a second message from the CU-UP, the second message including information related to the allocated receive transport layer.

[0015] On the other hand, an apparatus for implementing the above method is provided.

[0016] Beneficial effects of the present invention

[0017] This disclosure can have various beneficial effects.

[0018] According to some embodiments of this disclosure, the network can efficiently support indirect data forwarding and / or direct data forwarding during handover (HO) or dual connectivity (DC).

[0019] For example, the implementations described in this disclosure enable network nodes to support indirect data forwarding during HO or DC processes when no direct path is available between the source entity and the target entity, and also enable indirect data forwarding in a central unit (CU)-user plane (UP) entity (hereinafter referred to as CU-UP) dedicated to handling all user plane functions.

[0020] For example, when there is no direct path between the source node and the destination node, network nodes can efficiently support indirect data forwarding and / or direct data forwarding during HO or DC processes.

[0021] For example, CU-UP entities can efficiently perform indirect data forwarding and / or direct data forwarding.

[0022] The beneficial effects obtainable through specific embodiments of this disclosure are not limited to those listed above. For example, various technical effects may exist that can be understood and / or derived by those skilled in the art based on this disclosure. Therefore, the specific effects of this disclosure 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 disclosure. Attached Figure Description

[0023] Figure 1 An example of a communication system that applies the implementation of this disclosure is shown.

[0024] Figure 2 An example of a wireless device that applies an implementation of the present disclosure is shown.

[0025] Figure 3 An example of a wireless device that applies an implementation of the present disclosure is shown.

[0026] Figure 4 An example of a UE that applies the implementation of this disclosure is shown.

[0027] Figure 5 and Figure 6 An example of a protocol stack in a 3GPP-based wireless communication system applying the implementation of this disclosure is shown.

[0028] Figure 7 An example of the overall architecture of NG-RAN to which the technical features of this disclosure can be applied is shown.

[0029] Figure 8 An interface protocol structure for an E1 interface to which the technical features of this disclosure can be applied is shown.

[0030] Figure 9a and Figure 9bAn example signaling flow for inter-MN handover with / without an MN-initiated SN change process is shown.

[0031] Figure 10 An example of a successful operation of the S-NG-RAN node addition preparation process is shown.

[0032] Figure 11 An example of an unsuccessful operation during the S-NG-RAN node addition preparation process is shown.

[0033] Figure 12 Examples of methods for data forwarding in a wireless network system according to some embodiments of the present disclosure are shown.

[0034] Figure 13 A flowchart illustrating indirect data forwarding support in T-MN is shown.

[0035] Figure 14 A flowchart illustrating indirect data forwarding support in S-MN is shown.

[0036] Figure 15 A flowchart is shown to illustrate the termination of indirect data forwarding from the CU-UP.

[0037] Figure 16 A flowchart is shown for resource pooling support for indirect data forwarding in CU-UP.

[0038] Figure 17 Examples of methods for indirect data forwarding in a wireless network system according to some embodiments of the present disclosure are shown. Detailed Implementation

[0039] The following technologies, devices, and systems can be applied to a variety of 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 radio technologies such as Universal Terrestrial Radio Access (UTRA) or CDMA2000. TDMA can be implemented using radio technologies such as Global System for Mobile Communications (GSM), Universal Packet Radio Service (GPRS), or Enhanced Data Rate GSM Evolution (EDGE). OFDMA can be implemented using radio technologies such as IEEE 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). The 3GPP Long Term Evolution (LTE) is part of the Evolved UMTS (E-UMTS) using E-UTRA. 3GPP LTE uses OFDMA in DL and SC-FDMA in UL. The evolution of 3GPP LTE includes LTE-A (Advanced), LTE-A Pro, and / or 5G NR (New Radio).

[0040] For ease of description, the implementation of this disclosure is primarily described with respect to 3GPP-based wireless communication systems. However, the technical features of this disclosure are not limited thereto. For example, although the following detailed description is based on a mobile communication system corresponding to a 3GPP-based wireless communication system, the aspects of this disclosure that are not limited to 3GPP-based wireless communication systems are applicable to other mobile communication systems.

[0041] For terms and techniques used in this disclosure that are not specifically described in this disclosure, please refer to wireless communication standards documents published prior to this disclosure.

[0042] In this disclosure, "A or B" may mean "A only", "B only", or "both A and B". In other words, in this disclosure, "A or B" can be interpreted as "A and / or B". For example, in this disclosure, "A, B or C" may mean "A only", "B only", "C only", or "any combination of A, B and C".

[0043] In this disclosure, a forward slash ( / ) or a comma (,) can mean "and / or". For example, "A / B" can mean "A and / or B". Therefore, "A / B" can mean "A only", "B only", or "both A and B". For example, "A, B, C" can mean "A, B, or C".

[0044] In this disclosure, "at least one of A and B" can mean "only A", "only B" or "both A and B". Furthermore, the expressions "at least one of A or B" or "at least one of A and / or B" in this disclosure can be interpreted as the same as "at least one of A and B".

[0045] Additionally, in this disclosure, "at least one of A, B, and C" may mean "A only", "B only", "C only" or "any combination of A, B, and C". Furthermore, "at least one of A, B, or C" or "at least one of A, B, and / or C" may mean "at least one of A, B, and C".

[0046] Furthermore, the brackets used in this disclosure may mean "for example". Specifically, when shown as "Control Information (PDCCH)", "PDCCH" can be cited as an example of "Control Information". In other words, "Control Information" in this disclosure is not limited to "PDCCH", and "PDCCH" can be cited as an example of "Control Information". Additionally, even when shown as "Control Information (i.e., PDCCH)", "PDCCH" can be cited as an example of "Control Information".

[0047] The technical features described individually in a single figure in this disclosure can be implemented individually or simultaneously.

[0048] Although not limited thereto, the various descriptions, functions, processes, suggestions, methods and / or operation flowcharts disclosed herein can be applied to various fields requiring wireless communication and / or connectivity between devices (e.g., 5G).

[0049] In the following description, this disclosure will be described in more detail with reference to the accompanying drawings. Unless otherwise stated, the same reference numerals in the following drawings and / or description may refer to the same and / or corresponding hardware blocks, software blocks and / or functional blocks.

[0050] Figure 1 An example of a communication system that applies the implementation of this disclosure is shown.

[0051] exist Figure 1 The 5G use cases shown are merely exemplary, and the technical features of this disclosure can be applied to scenarios not described herein. Figure 1 Other 5G use cases are shown in the diagram.

[0052] The three main demand categories for 5G include: (1) enhanced mobile broadband (eMBB), (2) massive machine-type communications (mMTC), and (3) ultra-reliable and low-latency communications (URLLC).

[0053] Some use cases may require multiple categories for optimization, while others can focus on just one key performance indicator (KPI). 5G supports a wide variety of such use cases using flexible and reliable methods.

[0054] eMBB goes far beyond basic mobile internet access and covers a wealth of two-way work, media, and entertainment applications in the cloud and augmented reality. Data is one of the core driving forces of 5G, and for the first time in the 5G era, dedicated voice services may not be provided. In 5G, voice is expected to be simply processed as an application using the data connection provided by the communication system. The main reason for the increased service capacity is the increase in content size and the increase in the number of applications requiring high data transmission rates. As more and more devices connect to the internet, streaming services (audio and video), conversational video, and mobile internet access will be used more widely. These many applications require always-on connectivity to push real-time information and alerts to users. Cloud storage and applications are rapidly increasing in mobile communication platforms and can be applied to both work and entertainment. Cloud storage is a special use case for accelerating the growth of uplink data transmission rates. 5G is also used for remote work in the cloud. When using haptic interfaces, 5G requires much lower end-to-end latency to maintain a good user experience. Entertainment, such as cloud gaming and video streaming, is another core element increasing the demand for mobile broadband capabilities. Entertainment is essential for smartphones and tablets anywhere, including in highly mobile environments such as trains, vehicles, and airplanes. Other use cases include augmented reality for entertainment and information retrieval. In this case, augmented reality requires very low latency and instantaneous data capacity.

[0055] Additionally, one of the most anticipated 5G use cases involves the ability to seamlessly connect embedded sensors across all sectors, namely mMTC. The number of potential Internet of Things (IoT) devices is expected to reach 204 billion by 2020. Industrial IoT is one of the key categories performing key roles in enabling smart cities, asset tracking, smart utilities, agriculture, and security infrastructure through 5G.

[0056] URLLC encompasses new services that will transform industry, such as autonomous vehicles, through remote control of the main infrastructure and ultra-reliable / available low-latency links. Levels of reliability and latency are essential for controlling smart grids, automating industry, enabling robotics, and controlling and adapting drones.

[0057] 5G is the means to deliver streams assessed at hundreds of megabits per second to gigabits per second and can complement fiber-to-the-home (FTTH) and wired broadband (or DOCSIS). Such speeds are needed to deliver TVs at 4K or higher resolutions (6K, 8K, and more), as well as virtual reality and augmented reality. Virtual reality (VR) and augmented reality (AR) applications include almost immersive motion games. Specific applications may require special network configurations. For example, for VR games, game companies need to integrate their core servers into the network operator's edge network servers to minimize latency.

[0058] The automotive industry, along with numerous use cases for mobile communications in vehicles, is expected to be a significant new driving force in 5G. For example, passenger entertainment requires high concurrent capacity and highly mobile broadband. This is because future users continue to expect high-quality connectivity regardless of their location and speed. Another use case in the automotive sector is AR dashboards. AR dashboards allow drivers to identify objects in the dark in addition to those seen through the windshield and display distances and movement of objects by overlaying information spoken to the driver. In the future, wireless modules will enable communication between vehicles, information exchange between vehicles and supporting infrastructure, and information exchange between vehicles and other connected devices, such as pedestrian-accompanied devices. Safety systems will guide alternative routes, allowing drivers to drive more safely and thus reducing the risk of accidents. The next stage will be remotely controlled or self-driving vehicles. This requires very high reliability and very fast communication between different self-driving vehicles and between vehicles and infrastructure. In the future, self-driving vehicles will perform all driving activities, and drivers will only focus on abnormal traffic that the vehicle cannot recognize. The technological requirements for self-driving vehicles necessitate ultra-low latency and ultra-high reliability, increasing traffic safety to levels that cannot be achieved by humans.

[0059] Smart cities and smart homes / buildings, touted as part of a smart society, will be embedded in high-density wireless sensor networks. These distributed networks of smart sensors will identify conditions for cost- and energy-efficient maintenance in cities or homes. Similar configurations can be implemented for specific homes. All temperature sensors, window and heating controllers, burglar alarms, and home appliances will be wirelessly connected. Many of these sensors are typically low in terms of data transmission rates, power consumption, and cost. However, certain types of devices may require real-time HD video for monitoring.

[0060] The consumption and distribution of energy, including heat and gases, at a higher level necessitates automated control of distribution sensor networks. Smart grids collect information and use digital information and communication technologies to connect sensors to each other, thereby enabling actions based on the collected information. Because this information can include the behavior of supply companies and consumers, smart grids can improve the distribution of fuels such as electricity through methods that are efficient, reliable, economically feasible, production sustainable, and automated. Smart grids can also be considered as another type of sensor network with low latency.

[0061] Mission-critical applications, such as e-health, are one of the use cases for 5G. The health component includes many applications that can benefit from mobile communications. Communication systems can support telemedicine, enabling the delivery of clinical care in remote locations. Telemedicine can help reduce barriers of distance and improve access to healthcare services that are not readily available in remote rural areas. Telemedicine is also used to administer vital treatments and save lives in emergency situations. Mobile communication-based wireless sensor networks can provide remote monitoring and sensing of parameters such as heart rate and blood pressure.

[0062] Wireless and mobile communications are becoming increasingly important in industrial applications. Cabling is costly in terms of installation and maintenance. Therefore, the possibility of replacing cables with reconfigurable wireless links presents an attractive opportunity in many industrial sectors. However, to achieve this replacement, wireless connections need to have similar latency, reliability, and capacity to cables, and simplified wireless connection management is required. When connecting to 5G, low latency and a very low error probability become new requirements.

[0063] Logistics and freight tracking are important use cases for mobile communications, allowing inventory and packages to be tracked anywhere using location-based information systems. Logistics and freight tracking use cases typically require low data rates but demand location information with wide coverage and reliability.

[0064] Reference Figure 1 The communication system 1 includes wireless devices 100a to 100f, a base station (BS) 200, and a network 300. Although Figure 1 An example of a 5G network as a network of communication system 1 is illustrated, but the implementation of this disclosure is not limited to 5G systems and can be applied to future communication systems other than 5G systems.

[0065] BS 200 and network 300 can be implemented as wireless devices, and a particular wireless device can operate as a BS / network node relative to other wireless devices.

[0066] Wireless devices 100a to 100f represent devices that use radio access technology (RAT) (e.g., 5G New RAT (NR) or LTE) to perform communication, and may be referred to as communication / wireless / 5G devices. Wireless devices 100a to 100f may include, but are not limited to, robots 100a, vehicles 100b-1 and 100b-2, extended reality (XR) devices 100c, handheld devices 100d, home appliances 100e, IoT devices 100f, and artificial intelligence (AI) devices / servers 400. For example, vehicles may include vehicles with wireless communication capabilities, autonomous vehicles, and vehicles capable of performing communication between vehicles. Vehicles may include unmanned aerial vehicles (UAVs) (e.g., drones). XR devices may include AR / VR / mixed reality (MR) devices and may be implemented in the form of head-mounted displays (HMDs), head-up displays (HUDs) installed in vehicles, televisions, smartphones, computers, wearable devices, home appliance devices, digital signage, vehicles, robots, etc. Handheld devices may include smartphones, smart tablets, wearable devices (e.g., smartwatches 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.

[0067] In this disclosure, wireless devices 100a to 100f may be referred to as user equipment (UE). For example, a UE may include a cellular phone, smartphone, laptop computer, digital broadcasting terminal, personal digital assistant (PDA), portable multimedia player (PMP), navigation system, tablet PC, ultrabook, vehicle, vehicle with autonomous driving capability, connected car, UAV, AI module, robot, AR device, VR device, MR device, hologram device, public safety device, MTC device, IoT device, medical device, Fintech device (or financial device), security device, weather / environment device, device related to 5G services, or device related to the fourth industrial evolution.

[0068] UAVs can be, for example, aircraft that are driven by wireless control signals without any human passengers.

[0069] VR devices may include, for example, means for realizing objects or backgrounds in a virtual world. AR devices may include, for example, means for connecting objects or backgrounds in a virtual world to objects or backgrounds in the real world. MR devices may include, for example, means for incorporating objects or backgrounds in a virtual world into objects or backgrounds in the real world. Holographic devices may include, for example, means for realizing 360-degree stereoscopic images by recording and reproducing stereoscopic information, which utilizes the interference phenomenon of light generated when two lasers, known as holographic imaging, meet.

[0070] Public safety devices may include, for example, image relay devices or image devices that can be worn on a user's body.

[0071] MTC devices and IoT devices can be, for example, devices that do not require direct human intervention or manipulation. For example, MTC devices and IoT devices can include smart meters, vending machines, thermometers, smart light bulbs, door locks, or various sensors.

[0072] Medical devices can be, for example, devices used for the purpose of diagnosing, treating, alleviating, curing, or preventing disease. For example, a medical device can be a device used for the purpose of diagnosing, treating, alleviating, or correcting an injury or lesion. For example, a medical device can be a device used for the purpose of examining, replacing, or modifying a structure or function. For example, a medical device can be a device used for regulating pregnancy. For example, medical devices can include devices for treatment, devices for operation, devices for (in vitro) diagnosis, hearing aids, or devices for surgery.

[0073] Safety devices can be, for example, devices installed to prevent potential hazards and maintain safety. For instance, safety devices can be cameras, closed-circuit television (CCTV), recorders, or black boxes.

[0074] Fintech devices can be, for example, devices capable of providing financial services such as mobile payments. For instance, a fintech device can include a payment device or a point-of-sale (POS) system.

[0075] Weather / environment devices may include, for example, devices for monitoring or predicting weather / environment.

[0076] Wireless devices 100a to 100f can connect to network 300 via BS 200. AI technology can be applied to wireless devices 100a to 100f, and wireless devices 100a to 100f can connect to AI server 400 via network 300. Network 300 can be configured using 3G networks, 4G (e.g., LTE) networks, 5G (e.g., NR) networks, and super 5G networks. Although wireless devices 100a to 100f can communicate with each other via BS 200 / network 300, wireless devices 100a to 100f can also perform direct communication with each other without going through BS 200 / network 300 (e.g., sidelink communication). For example, vehicles 100b-1 and 100b-2 can perform direct communication (e.g., vehicle-to-vehicle (V2V) / vehicle-to-everything (V2X) communication). IoT devices (e.g., sensors) can perform direct communication with other IoT devices (e.g., sensors) or other wireless devices 100a to 100f.

[0077] Wireless communication / connections 150a, 150b, and 150c can be established between wireless devices 100a to 100f and / or between wireless devices 100a to 100f and BS 200 and / or between BS 200. In this document, wireless communication / connections can be established via various RATs (e.g., 5G NR) such as uplink / downlink communication 150a, sidelink communication (or device-to-device (D2D) communication) 150b, and inter-base station communication 150c (e.g., relay, integrated access and backhaul (IAB)). Wireless devices 100a to 100f and BS 200 / wireless devices 100a to 100f can transmit / receive radio signals to each other via wireless communication / connections 150a, 150b, and 150c. For example, wireless communication / connections 150a, 150b, and 150c can transmit / receive signals via various physical channels. Therefore, at least a portion of various configuration information configuration processes, various signal processing processes (e.g., channel coding / decoding, modulation / demodulation, and resource mapping / demapping), and resource allocation processes for transmitting / receiving radio signals can be performed based on various proposals of this disclosure.

[0078] AI refers to the field of studying artificial intelligence or the methodologies that can create it, while machine learning refers to the field that defines the various problems solved within AI and the methodologies for solving these problems. Machine learning is also defined as an algorithm that improves the performance of a task through stable experience with that task.

[0079] A robot is a machine that automatically processes or operates a given task using its own capabilities. Specifically, a robot capable of recognizing its environment and autonomously deciding to perform actions can be called an intelligent robot. Based on their purpose or field of application, robots can be categorized into industrial, medical, domestic, and military types. Robots can perform various physical operations, such as moving robot joints using actuators or motors. Mobile robots also include wheels, brakes, propellers, etc., on their drive systems, enabling them to travel on the ground or fly in the air.

[0080] Autonomous driving refers to a technology that allows a vehicle to drive itself, while an autonomous vehicle is a vehicle that operates with minimal or no user control. For example, autonomous driving can include lane keeping while moving, automatic speed adjustment such as adaptive cruise control, automatic driving along a set route, and automatic route planning when a destination is set. Vehicles encompass vehicles equipped with internal combustion engines, hybrid vehicles equipped with both internal combustion engines and electric motors, and electric vehicles equipped with electric motors, and can include trains, motorcycles, and automobiles. An autonomous vehicle can be viewed as a robot with autonomous driving capabilities.

[0081] Extended reality is collectively referred to as VR, AR, and MR. VR technology provides real-world objects and backgrounds solely through computer graphics (CG) images. AR technology provides virtual CG images on top of real-world object images. MR technology is a CG technology that combines virtual objects with and integrates them into the real world. MR technology is similar to AR technology in that it displays real and virtual objects together. However, the difference lies in that in AR technology, virtual objects serve as a complementary form to real objects, while in MR technology, virtual and real objects serve as equal entities.

[0082] NR supports multiple parameter sets (and / or multiple subcarrier spacings (SCS)) to support a variety of 5G services. For example, if the SCS is 15kHz, it can support wide-area coverage of traditional cellular bands; and if the SCS is 30kHz / 60kHz, it can support dense urban areas, lower latency, and wider carrier bandwidth. If the SCS is 60kHz or higher, it can support bandwidths greater than 24.25GHz to overcome phase noise.

[0083] NR bands can be defined as two types of frequency ranges, namely FR1 and FR2. The numerical values ​​of the frequency ranges can be varied. For example, the frequency ranges of the two types (FR1 and FR2) can be shown in Table 1 below. For ease of explanation, in the frequency ranges used in NR systems, FR1 can represent the "sub-6 GHz range", FR2 can represent the "range above 6 GHz", and can be referred to as millimeter wave (mmW).

[0084] [Table 1]

[0085] As mentioned above, the frequency range of the NR system can be varied. For example, FR1 can include a frequency band from 410MHz to 7125MHz, as shown in Table 2 below. That is, FR1 can include a frequency band of 6GHz (or 5850, 5900, 5925MHz, etc.) or larger. For example, the 6GHz (or 5850, 5900, 5925MHz, etc.) or larger frequency band included in FR1 can include unlicensed frequency bands. Unlicensed frequency bands can be used for various purposes, such as for vehicle communications (e.g., autonomous driving).

[0086] [Table 2]

[0087] Here, the radio communication technologies implemented in the wireless devices of this disclosure may include narrowband Internet of Things (NB-IoT) technologies for low-power communication, as well as LTE, NR, and 6G. For example, NB-IoT technology may be an example of low-power wide-area network (LPWAN) technology, implemented in specifications such as LTE Cat NB1 and / or LTE Cat NB2, and may not be limited to the aforementioned names. Additionally and / or alternatively, the radio technologies implemented in the wireless devices of this disclosure may communicate based on LTE-M technology. For example, LTE-M technology may be an example of LPWAN technology and may be referred to by various names such as enhanced machine-type communication (eMTC). For example, LTE-M technology may be implemented in at least one of various specifications such as 1) LTE Cat 0, 2) LTE Cat M1, 3) LTE Cat M2, 4) LTE non-bandwidth limited (non-BL), 5) LTE-MTC, 6) LTE machine-type communication, and / or 7) LTE M, and may not be limited to the aforementioned names. Additionally and / or alternatively, the radio communication technology implemented in the wireless devices of this disclosure may include at least one of ZigBee, Bluetooth, and / or LPWAN, which take into account low-power communication, and may not be limited to the names mentioned above. For example, ZigBee technology may generate personal area networks (PANs) associated with small / low-power digital communication based on various specifications such as IEEE 802.15.4, and may be referred to by various names.

[0088] Figure 2 An example of a wireless device that applies an implementation of the present disclosure is shown.

[0089] Reference Figure 2 The first wireless device 100 and the second wireless device 200 can send / receive radio signals to / from external devices via various RATs (e.g., LTE and NR).

[0090] exist Figure 2 In this context, {the first wireless device 100 and the second wireless device 200} can correspond to the attached... Figure 1 At least one of {wireless devices 100a to 100f and BS 200}, {wireless devices 100a to 100f and wireless devices 100a to 100f} and / or {BS 200 and BS200}.

[0091] The first wireless device 100 may include at least one transceiver (such as transceiver 106), at least one processing chip (such as processing chip 101), and / or one or more antennas 108.

[0092] The processing chip 101 may include at least one processor (such as processor 102) and at least one memory (such as memory 104). Figure 2 The image exemplarily illustrates that memory 104 is included in processing chip 101. Additionally and / or alternatively, memory 104 may be located external to processing chip 101.

[0093] Processor 102 can control memory 104 and / or transceiver 106, and can be configured to implement the descriptions, functions, processes, suggestions, methods, and / or operation flowcharts described in this disclosure. For example, processor 102 can process information in memory 104 to generate first information / signal, and then transmit a radio signal including the first information / signal via transceiver 106. Processor 102 can receive a radio signal including a second information / signal via transceiver 106, and then store the information obtained by processing the second information / signal in memory 104.

[0094] Memory 104 may be operatively connected to processor 102. Memory 104 may store various types of information and / or instructions. Memory 104 may store software code 105 that implements instructions, when executed by processor 102, to execute the descriptions, functions, procedures, suggestions, methods, and / or operation flowcharts disclosed in this disclosure. For example, software code 105 may implement instructions, when executed by processor 102, to execute the descriptions, functions, procedures, suggestions, methods, and / or operation flowcharts disclosed in this disclosure. For example, software code 105 may control processor 102 to execute one or more protocols. For example, software code 105 may control processor 102 to execute one or more layers of a radio interface protocol.

[0095] In this document, processor 102 and memory 104 may be part of a communication modem / circuit / chip designed to implement RAT (e.g., LTE or NR). Transceiver 106 may be connected to processor 102 and transmit and / or receive radio signals via one or more antennas 108. Each of transceivers 106 may include a transmitter and / or a receiver. Transceivers 106 may be used interchangeably with radio frequency (RF) units. In this disclosure, first wireless device 100 may represent a communication modem / circuit / chip.

[0096] The second wireless device 200 may include at least one transceiver (such as transceiver 206), at least one processing chip (such as processing chip 201), and / or one or more antennas 208.

[0097] The processing chip 201 may include at least one processor (such as processor 202) and at least one memory (such as memory 204). Figure 2 The image exemplarily illustrates that memory 204 is included in processing chip 201. Additionally and / or alternatively, memory 204 may be located external to processing chip 201.

[0098] Processor 202 can control memory 204 and / or transceiver 206, and can be configured to implement the descriptions, functions, processes, suggestions, methods, and / or operation flowcharts described in this disclosure. For example, processor 202 can process information in memory 204 to generate third information / signal, and then transmit a radio signal including the third information / signal via transceiver 206. Processor 202 can receive a radio signal including a fourth information / signal via transceiver 106, and then store the information obtained by processing the fourth information / signal in memory 204.

[0099] Memory 204 may be operatively connected to processor 202. Memory 204 may store various types of information and / or instructions. Memory 204 may store software code 205 that implements the instructions, which, when executed by processor 202, execute the descriptions, functions, procedures, suggestions, methods, and / or operation flowcharts disclosed in this disclosure. For example, software code 205 may implement instructions that, when executed by processor 202, execute the descriptions, functions, procedures, suggestions, methods, and / or operation flowcharts disclosed in this disclosure. For example, software code 205 may control processor 202 to execute one or more protocols. For example, software code 205 may control processor 202 to execute one or more layers of a radio interface protocol.

[0100] In this document, processor 202 and memory 204 may be part of a communication modem / circuit / chip designed to implement RAT (e.g., LTE or NR). Transceiver 206 may be connected to processor 202 and transmit and / or receive radio signals via one or more antennas 208. Each of transceivers 206 may include a transmitter and / or a receiver. Transceivers 206 may be used interchangeably with RF units. In this disclosure, second wireless device 200 may represent a communication modem / circuit / chip.

[0101] The hardware elements of wireless devices 100 and 200 will be described in more detail below. One or more protocol layers can be implemented by, but are not limited to, one or more processors 102 and 202. For example, one or more processors 102 and 202 can implement one or more layers (e.g., functional layers such as the Physical (PHY) layer, Medium Access Control (MAC) layer, Radio Link Control (RLC) layer, Packet Data Convergence Protocol (PDCP) layer, Radio Resource Control (RRC) layer, and Service Data Adaptive Protocol (SDAP) layer). Based on the descriptions, functions, processes, suggestions, methods, and / or operation flowcharts disclosed in this disclosure, one or more processors 102 and 202 can generate one or more Protocol Data Units (PDUs) and / or one or more Service Data Units (SDUs). One or more processors 102 and 202 can generate messages, control information, data, or information according to the descriptions, functions, processes, suggestions, methods, and / or operation flowcharts disclosed in this disclosure. One or more processors 102 and 202 may generate signals (e.g., baseband signals) including PDUs, SDUs, messages, control information, data, or information, in accordance with the descriptions, functions, processes, suggestions, methods, and / or operation flowcharts disclosed in this disclosure, and provide the generated signals to one or more transceivers 106 and 206. One or more processors 102 and 202 may receive signals (e.g., baseband signals) from one or more transceivers 106 and 206, and acquire PDUs, SDUs, messages, control information, data, or information in accordance with the descriptions, functions, processes, suggestions, methods, and / or operation flowcharts disclosed in this disclosure.

[0102] One or more processors 102 and 202 may be referred to as controllers, microcontrollers, microprocessors, or microcomputers. One or more processors 102 and 202 may be implemented by hardware, firmware, software, or a combination thereof. As an example, one or more application-specific integrated circuits (ASICs), one or more digital signal processors (DSPs), one or more digital signal processing devices (DSPDs), one or more programmable logic devices (PLDs), or one or more field-programmable gate arrays (FPGAs) may be included in one or more processors 102 and 202. The descriptions, functions, processes, suggestions, methods, and / or operation flowcharts disclosed in this disclosure may be implemented using firmware or software, and the firmware or software may be configured to include modules, processes, or functions. Firmware or software configured to perform the descriptions, functions, processes, suggestions, methods, and / or operation flowcharts disclosed in this disclosure may be included in one or more processors 102 and 202, or stored in one or more memories 104 and 204, thereby being driven by one or more processors 102 and 202. The descriptions, functions, processes, suggestions, methods and / or operation flowcharts disclosed in this disclosure may be implemented in the form of firmware or software in the form of code, commands and / or sets of commands.

[0103] One or more memories 104 and 204 may be connected to one or more processors 102 and 202 and store various types of data, signals, messages, information, programs, code, instructions, and / or commands. One or more memories 104 and 204 may be configured using read-only memory (ROM), random access memory (RAM), electrically erasable programmable read-only memory (EPROM), flash memory, hard disk drive, registers, cache memory, computer-readable storage media, and / or combinations thereof. One or more memories 104 and 204 may be located internally and / or externally to one or more processors 102 and 202. One or more memories 104 and 204 may be connected to one or more processors 102 and 202 via various technologies such as wired or wireless connections.

[0104] One or more transceivers 106 and 206 may transmit user data, control information, and / or radio signals / channels mentioned in the descriptions, functions, processes, suggestions, methods, and / or operation flowcharts disclosed herein to one or more other devices. One or more transceivers 106 and 206 may receive user data, control information, and / or radio signals / channels mentioned in the descriptions, functions, processes, suggestions, methods, and / or operation flowcharts disclosed herein from one or more other devices. For example, one or more transceivers 106 and 206 may be connected to one or more processors 102 and 202 and transmit and receive radio signals. For example, one or more processors 102 and 202 may perform control such that one or more transceivers 106 and 206 may transmit user data, control information, or radio signals to one or more other devices. One or more processors 102 and 202 may perform control such that one or more transceivers 106 and 206 may receive user data, control information, or radio signals from one or more other devices.

[0105] One or more transceivers 106 and 206 may be connected to one or more antennas 108 and 208, and one or more transceivers 106 and 206 may be configured to transmit and receive user data, control information, and / or radio signals / channels mentioned in the descriptions, functions, processes, suggestions, methods, and / or operation flowcharts disclosed herein via one or more antennas 108 and 208. In this disclosure, one or more antennas 108 and 208 may be multiple physical antennas or multiple logical antennas (e.g., antenna ports).

[0106] One or more transceivers 106 and 206 can convert received user data, control information, radio signals / channels, etc., from RF band signals to baseband signals for processing. One or more transceivers 106 and 206 can also convert user data, control information, radio signals / channels, etc., processed by one or more processors 102 and 202 from baseband signals to RF band signals. For this purpose, one or more transceivers 106 and 206 may include (analog) oscillators and / or filters. For example, one or more transceivers 106 and 206, under the control of one or more processors 102 and 202, can up-convert OFDM baseband signals to OFDM signals using their (analog) oscillators and / or filters, and transmit the up-converted OFDM signals at the carrier frequency. One or more transceivers 106 and 206 can receive OFDM signals at a carrier frequency and, under the control of one or more processors 102 and 202, downconvert the OFDM signals to OFDM baseband signals via their (analog) oscillators and / or filters.

[0107] In the implementation of this disclosure, the UE can operate as a transmitting device in the uplink (UL) and as a receiving device in the downlink (DL). In the implementation of this disclosure, the BS can operate as a receiving device in the UL and as a transmitting device in the DL. For ease of description, it is primarily assumed below that the first wireless device 100 acts as the UE and the second wireless device 200 acts as the BS. For example, a processor 102 connected to, installed on, or started in the first wireless device 100 can be configured to perform UE actions according to the implementation of this disclosure, or to control the transceiver 106 to perform UE actions according to the implementation of this disclosure. A processor 202 connected to, installed on, or started in the second wireless device 200 can be configured to perform BS actions according to the implementation of this disclosure, or to control the transceiver 206 to perform BS actions according to the implementation of this disclosure.

[0108] In this disclosure, BS is also referred to as Node B (NB), eNodeB (eNB), or gNB.

[0109] Figure 3 An example of a wireless device that applies the implementation of this disclosure is shown.

[0110] Wireless devices can be implemented in various forms depending on the use case / service (see reference). Figure 1 ).

[0111] Reference Figure 3 Wireless devices 100 and 200 can correspond to Figure 2 The wireless devices 100 and 200 can be configured from various elements, components, units / parts, and / or modules. For example, each of the wireless devices 100 and 200 may include a communication unit 110, a control unit 120, a memory unit 130, and an additional component 140. The communication unit 110 may include a communication circuit 112 and a transceiver 114. For example, the communication circuit 112 may include... Figure 2 One or more processors 102 and 202 and / or Figure 2 One or more memories 104 and 204. For example, transceiver 114 may include... Figure 2 One or more transceivers 106 and 206 and / or Figure 2One or more antennas 108 and 208. Control unit 120 is electrically connected to communication unit 110, memory unit 130, and add-on components 140, and controls the overall operation of each of wireless devices 100 and 200. For example, control unit 120 can control the electrical / mechanical operation of each of wireless devices 100 and 200 based on programs / code / commands / information stored in memory unit 130. Control unit 120 can transmit information stored in memory unit 130 to an external source (e.g., other communication devices) via communication unit 110 through a wireless / wired interface, or store information received from an external source (e.g., other communication devices) via communication unit 110 in memory unit 130.

[0112] The add-on component 140 can be configured differently depending on the type of wireless devices 100 and 200. For example, the add-on component 140 may include at least one of a power supply unit / battery, an input / output (I / O) unit (e.g., an audio I / O port, a video I / O port), a drive unit, and a computing unit. Wireless devices 100 and 200 can be, but are not limited to, robots ( Figure 1 100a), vehicles ( Figure 1 100b-1 and 100b-2), XR device ( Figure 1 100c), handheld device ( Figure 1 100d), home appliances ( Figure 1 100e), IoT devices ( Figure 1 100f), digital broadcasting terminals, holographic devices, public safety devices, MTC devices, medical devices, Fintech devices (or financial devices), security devices, climate / environment devices, AI servers / devices ( Figure 1 400), BSS ( Figure 1 This can be achieved in the form of wireless devices 100 and 200, network nodes, etc. Wireless devices 100 and 200 can be used in mobile or fixed locations depending on the usage example / service.

[0113] exist Figure 3In wireless devices 100 and 200, the various elements, components, units / parts, and / or modules as a whole can be connected to each other via a wired interface, or at least a portion thereof can be wirelessly connected via communication unit 110. For example, in each of wireless devices 100 and 200, control unit 120 and communication unit 110 can be wired connected, and control unit 120 and first units (e.g., 130 and 140) can be wirelessly connected via communication unit 110. Each element, component, unit / part, and / or module within wireless devices 100 and 200 may also include one or more elements. For example, control unit 120 may be configured by a group of one or more processors. As an example, control unit 120 may be configured by a group of communication control processors, application processors (APs), electronic control units (ECUs), graphics processing units, and memory control processors. As another example, memory unit 130 may be configured with RAM, DRAM, ROM, flash memory, volatile memory, non-volatile memory, and / or combinations thereof.

[0114] Figure 4 An example of a UE that applies the implementation of this disclosure is shown.

[0115] Reference Figure 4 UE 100 can correspond to Figure 2 The first wireless device 100 and / or Figure 3 Wireless devices 100 or 200.

[0116] The UE 100 includes a processor 102, a memory 104, a transceiver 106, one or more antennas 108, a power management module 110, a battery 112, a display 114, a keypad 116, a subscriber identification module (SIM) card 118, a speaker 120, and a microphone 122.

[0117] Processor 102 may be configured to implement the descriptions, functions, processes, suggestions, methods, and / or operation flowcharts disclosed in this disclosure. Processor 102 may be configured to control one or more other components of UE 100 to implement the descriptions, functions, processes, suggestions, methods, and / or operation flowcharts disclosed in this disclosure. A layer of the radio interface protocol may be implemented in processor 102. Processor 102 may include an ASIC, other chipsets, logic circuits, and / or data processing means. Processor 102 may be an application processor. Processor 102 may include at least one of a digital signal processor (DSP), a central processing unit (CPU), a graphics processing unit (GPU), and a modem (modulator and demodulator). Examples of processor 102 can be found in Qualcomm... ® Manufacturing SNAPDRAGON TM Series processors, Samsung® EXYNOS manufactured TM Series processors, Apple ® A-series processors manufactured by MediaTek ® HELIO manufactured TM Series processors, Intel ® Manufactured ATOM TM This series of processors or the corresponding next-generation processors.

[0118] Memory 104 is operatively coupled to processor 102 and stores various information to operate processor 102. Memory 104 may include ROM, RAM, flash memory, memory card, storage medium, and / or other storage devices. When the implementation is software-based, the techniques described herein can be implemented using modules (e.g., processes, functions, etc.) that perform the descriptions, functions, processes, suggestions, methods, and / or operation flowcharts disclosed herein. Modules may be stored in memory 104 and executed by processor 102. Memory 104 may be implemented within or outside processor 102, in which case memory 104 may be communicatively coupled to processor 102 via various means known in the art.

[0119] Transceiver 106 is operatively coupled to processor 102 and transmits and / or receives radio signals. Transceiver 106 includes a transmitter and a receiver. Transceiver 106 may include baseband circuitry for processing radio frequency signals. Transceiver 106 controls one or more antennas 108 to transmit and / or receive radio signals.

[0120] The power management module 110 manages the power of the processor 102 and / or transceiver 106. The battery 112 supplies power to the power management module 110.

[0121] Display 114 outputs the results processed by processor 102. Keypad 116 receives input to be used by processor 102. Keypad 116 can be displayed on display 114.

[0122] The SIM 118 is an integrated circuit designed to securely store the International Mobile Subscriber Identity (IMSI) number and its associated keys, used for identifying and authenticating subscribers on mobile devices such as mobile phones and computers. Contact information can also be stored on many SIM cards.

[0123] Speaker 120 outputs sound-related results processed by processor 102. Microphone 122 receives sound-related inputs to be used by processor 102.

[0124] Figure 5 and Figure 6An example of a protocol stack in a 3GPP-based wireless communication system applying the implementation of this disclosure is shown.

[0125] Specifically, Figure 5 An example of the user plane protocol stack for the radio interface between the UE and the BS is shown, and Figure 6 An example of a radio interface control plane protocol stack between the UE and the BS is illustrated. The control plane refers to the path that transmits control messages used to manage calls made by the UE and the network. The user plane refers to the path that transmits data generated in the application layer (e.g., voice data or Internet packet data). See reference... Figure 5 The user plane protocol stack can be divided into Layer 1 (i.e., the PHY layer) and Layer 2. (See reference...) Figure 6 The control plane protocol stack can be divided into Layer 1 (i.e., the PHY layer), Layer 2, Layer 3 (e.g., the RRC layer), and the Non-Access Layer (NAS). Layers 1, 2, and 3 are called the Access Layer (AS).

[0126] In 3GPP LTE systems, Layer 2 is divided into the following sublayers: MAC, RLC, and PDCP. In 3GPP NR systems, Layer 2 is divided into the following sublayers: MAC, RLC, PDCP, and SDAP. The PHY layer provides transport channels to the MAC sublayer, the MAC sublayer provides logical channels to the RLC sublayer, the RLC sublayer provides RLC channels to the PDCP sublayer, and the PDCP sublayer provides radio bearers to the SDAP sublayer. The SDAP sublayer provides Quality of Service (QoS) streams to the 5G core network.

[0127] In 3GPP NR systems, the main services and functions of the MAC sublayer include: mapping between logical channels and transport channels; multiplexing MAC SDUs belonging to one or different logical channels into transport blocks (TBs) / demultiplexing from TBs, which are delivered to or from the physical layer on the transport channel; scheduling information reporting; error correction via Hybrid Automatic Repeat Request (HARQ) (one HARQ entity per cell in the case of carrier aggregation (CA)); priority handling between UEs via dynamic scheduling; priority handling between logical channels of a UE via logical channel priority ordering; and padding. A single MAC entity can support multiple parameter sets, transmission timings, and cells. Mapping constraints in logical channel priority ordering control which parameter sets, cells, and transmission timings a logical channel can use.

[0128] The MAC provides different types of data transmission services. To accommodate these different services, various types of logical channels are defined, each supporting the transmission of a specific type of information. Each logical channel type is defined by the type of information it transmits. Logical channels are divided into two groups: control channels and traffic channels. Control channels are used only for transmitting control plane information, and traffic channels are used only for transmitting user plane information. The Broadcast Control Channel (BCCH) is a downlink logical channel used for broadcasting system control information. The Paging Control Channel (PCCH) is a downlink logical channel that transmits paging information, system information change notifications, and indications of ongoing Public Warning Service (PWS) broadcasts. The Common Control Channel (CCCH) is a logical channel used to transmit control information between the UE and the network and is used by UEs that do not have an RRC connection with the network. The Dedicated Control Channel (DCCH) is a point-to-point bidirectional logical channel used by UEs with an RRC connection to transmit dedicated control information between the UE and the network. The Dedicated Traffic Channel (DTCH) is a point-to-point logical channel dedicated to a single UE for transmitting user information. DTCHs can exist in both the uplink and downlink. In the downlink, the following connections exist between logical channels and transport channels: BCCH can be mapped to the broadcast channel (BCH); BCCH can be mapped to the downlink shared channel (DL-SCH); PCCH can be mapped to the paging channel (PCH); CCCH can be mapped to DL-SCH; DCCH can be mapped to DL-SCH; and DTCH can be mapped to DL-SCH. In the uplink, the following connections exist between logical channels and transport channels: CCCH can be mapped to the uplink shared channel (UL-SCH); DCCH can be mapped to UL-SCH; and DTCH can be mapped to UL-SCH.

[0129] The RLC sublayer supports three transmission modes: Transparent Mode (TM), Unacknowledged Mode (UM), and Acknowledged Node (AM). RLC configuration is per logical channel and does not depend on parameter sets and / or transmission duration. In 3GPP NR systems, the main services and functions of the RLC sublayer depend on the transmission mode and include: transmission of upper-layer PDUs; sequence numbering independent of sequence numbers in PDCP (UM and AM); error correction via ARQ (AM only); RLC SDU segmentation (AM and UM) and resegmentation (AM only); SDU (AM and UM) reassembly; duplicate detection (AM only); RLC SDU dropping (AM and UM); RLC reconstruction; and protocol error detection (AM only).

[0130] In the 3GPP NR system, the main services and functions of the PDCP sublayer for the user plane include: sequence numbering; header compression and decompression using robust header compression (ROHC); transmission of user data; reordering and deduplication detection; ordered delivery; PDCP PDU routing (in the case of separate bearers); retransmission of PDCP SDUs; encryption, decryption, and integrity protection; PDCP SDU discarding; PDCP reconstruction and data recovery for RLC AM; PDCP status reporting for RLC AM; and PDCP PDU deduplication and deduplication indication to lower layers. The main services and functions of the PDCP sublayer for the control plane include: sequence numbering; encryption, decryption, and integrity protection; transmission of control plane data; reordering and deduplication detection; ordered delivery; and PDCP PDU deduplication and deduplication indication to lower layers.

[0131] In the 3GPP NR system, the main services and functions of SDAP include: mapping between QoS flows and data radio bearers; marking QoS flow IDs (QFIs) in DL and UL packets; and configuring a single protocol entity for SDAP for each individual PDU session.

[0132] In the 3GPP NR system, the main services and functions of the RRC sublayer include: broadcasting system information related to AS and NAS; paging initiated by 5GC or NG-RAN; establishment, maintenance, and release of RRC connections between UE and NG-RAN; security functions including key management; establishment, configuration, maintenance, and release of signaling radio bearers (SRB) and data radio bearers (DRB); mobility functions (including: handover and context delivery, UE cell selection and reselection, and control of cell selection and reselection, and inter-RAT mobility); QoS management functions; control of UE measurement reports and notifications; detection and recovery of radio link failures; and NAS message delivery from UE to NAS / from NAS to UE.

[0133] Figure 7 An example of the overall architecture of NG-RAN to which the technical features of this disclosure can be applied is shown.

[0134] Reference Figure 7 A gNB may include a gNB-CU (hereinafter referred to as CU) and at least one gNB-DU (hereinafter referred to as DU).

[0135] The gNB-CU is a logical node that hosts the RRC, SDAP, and PDCP protocols of the gNB or the en-gNB. The gNB-CU controls the operation of at least one gNB-DU.

[0136] A gNB-DU is a logical node that hosts the RLC, MAC, and physical layers of a gNB or en-gNB. The operation of a gNB-DU is partially controlled by a gNB-CU. One gNB-DU supports one or more cells. A cell is supported by only one gNB-DU.

[0137] gNB-CU and gNB-DU are connected via the F1 interface. The gNB-CU is terminated to the F1 interface of the gNB-DU. The gNB-DU is terminated to the F1 interface of the gNB-CU. One gNB-DU is connected to only one gNB-CU. However, a gNB-DU can be connected to multiple gNB-CUs through appropriate implementation. The F1 interface is a logical interface. For NG-RAN, the NG and Xn-C interfaces of the gNB consisting of gNB-CU and gNB-DU are terminated to the gNB-CU. For E-UTRAN-NR Dual Connectivity (EN-DC), the S1-U and X2-C interfaces of the gNB consisting of gNB-CU and gNB-DU are terminated to the gNB-CU. The gNB-CU and the connected gNB-DU are only visible to other gNBs and the 5GC acting as a gNB.

[0138] The F1 interface includes the following F1 control (F1-C) functions.

[0139] (1) F1 interface management function

[0140] The error indication function is used by gNB-DU or gNB-CU to indicate to gNB-CU or gNB-DU that an error has occurred.

[0141] The reset function is used to initialize peer entities after node setup and after a failure event. This procedure can be used by both gNB-DU and gNB-CU.

[0142] The F1 setup function allows the exchange of application-level data required by the gNB-DU and gNB-CU for proper interoperability on the F1 interface. The F1 setup is initiated by the gNB-DU.

[0143] The gNB-CU configuration update and gNB-DU configuration update functions allow updating the application-level configuration data required between the gNB-CU and gNB-DU to properly interoperate via the F1 interface, and can activate or deactivate the cell.

[0144] The F1 setup and gNB-DU configuration update functionality allows notification of individual network slice selection assistance information (S-NSSAI) supported by gNB-DU.

[0145] The F1 resource coordination function is used to transmit information about frequency resource sharing between gNB-CU and gNB-DU.

[0146] (2) System information management function

[0147] The scheduling of system broadcast messages is performed in gNB-DU. gNB-DU is responsible for sending system messages based on available scheduling parameters.

[0148] gNB-DU is responsible for encoding the NR Master Information Block (MIB). If it is necessary to broadcast System Information Block Type 1 (SIB1) and other SI messages, then gNB-DU is responsible for encoding SIB1 and gNB-CU is responsible for encoding the other SI messages.

[0149] (3) F1 UE Context Management Function

[0150] The F1 UE context management function supports the creation and modification of the necessary overall UE context.

[0151] The establishment of the F1 UE context is initiated by the gNB-CU and accepted or rejected by the gNB-DU based on admission control criteria (e.g., resource unavailability).

[0152] Modification of the F1 UE context can be initiated by either the gNB-CU or the gNB-DU. The receiving node can accept or reject the modification. The F1 UE context management function also supports the release of contexts previously established in the gNB-DU. Context release is triggered directly by the gNB-CU or upon receiving a request from the gNB-DU. When the UE enters RRC_IDLE or RRC_INACTIVE, the gNB-CU requests the gNB-DU to release the UE context.

[0153] This function can also be used to manage DRBs and SRBs, that is, to create, modify, and release DRB and SRB resources. The creation and modification of DRB resources are triggered by the gNB-CU and accepted / rejected by the gNB-DU based on the resource reservation information and QoS information to be provided to the gNB-DU. For each DRB to be set or modified, S-NSSAI can be provided by the gNB-CU to the gNB-DU during the UE context setting process and the UE context modification process.

[0154] The mapping between QoS flows and radio bearers is performed by the gNB-CU, and the granularity of bearer-related management on F1 is at the radio bearer level. For NG-RAN, the gNB-CU provides the gNB-DU with aggregated DRB QoS profiles and QoS flow profiles, and the gNB-DU accepts requests or rejects them with appropriate reason values. To support packet replication of carrier aggregation (CA) within the gNB-DU, a data radio bearer should have two GPRS Tunneling Protocol (GTP)-U tunnels configured between the gNB-CU and gNB-DU.

[0155] Using this function, the gNB-CU requests the gNB-DU to set or change a special cell (SpCell) for the UE, and the gNB-DU accepts the request or rejects the request with an appropriate reason value.

[0156] Using this function, the gNB-CU requests the setup of a secondary cell (SCell) on the gNB-DU side, and the gNB-DU accepts all, some, or none of the SCells and replies to the gNB-CU. The gNB-CU then requests the removal of the UE's SCell.

[0157] (4) RRC message passing function

[0158] This feature allows the transmission of RRC messages between the gNB-CU and gNB-DU. RRC messages are transmitted via F1-C. The gNB-CU is responsible for encoding the dedicated RRC messages using auxiliary information provided by the gNB-DU.

[0159] (5) Paging function

[0160] gNB-DU is responsible for sending paging information based on the provided scheduling parameters.

[0161] The gNB-CU provides paging information so that the gNB-DU can calculate the accurate paging opportunity (PO) and paging frame (PF). The gNB-CU determines the paging assignment (PA). The gNB-DU merges all paging records for a specific PO, PF, and PA, encodes the final RRC message, and broadcasts the paging message on the corresponding PO and PF in the PA.

[0162] (6) Warning message transmission function

[0163] This feature allows for coordination with the warning message transmission process via the NG interface. The gNB-CU is responsible for encoding the warning-related SI messages and sending them along with other warning-related information from the gNB-DU for broadcast via the radio interface.

[0164] Figure 8 An interface protocol structure for an E1 interface to which the technical features of this disclosure can be applied is shown.

[0165] TNL is based on IP transport, including SCTP over IP. The application layer signaling protocol is called E1 Application Protocol (E1AP).

[0166] The technical features associated with Multiple Radio Dual Connectivity (MR-DC) with a 5th Generation Core (5GC) are described below. See section 10.7.2 of 3GPP TS 37.340 v17.1.0 for details.

[0167] Inter-MN handover with or without MN-initiated SN change is used to transfer UE context data from the source MN to the target MN, while the UE context at the SN is maintained or moved to another SN. During the inter-master node handover, the target MN decides whether to maintain or change the SN (or release the SN, as described in Clause 10.8). Only intra-RAT inter-master node handovers with or without SN change are supported (e.g., without a transition from NGEN-DC to NR-DC).

[0168] Figure 9a and Figure 9b An example signaling flow for inter-MN handover with / without an MN-initiated SN change process is shown.

[0169] For switching between primary nodes where secondary nodes do not change, Figure 9a and Figure 9b The source SN and target SN shown are the same node.

[0170] In step S901, the source MN initiates the handover process by launching an Xn handover preparation process that includes configuring both the MCG and SCG. The source MN in Switching requests The message includes the source SN, UE XnAP ID, SN ID, and UE context in the source SN.

[0171] For example, the source MN can trigger an SN modification process initiated by the MN (to the source SN) to retrieve the current SCG configuration and allow data forwarding related information to be provided before step S901.

[0172] In step S902, if the target MN decides to preserve the UE context in the source SN, the target MN sends the SN UE XnAP ID, which serves as a reference to the UE context established by the source MN in the SN, to the SN. SN Add Request If the target MN decides to change the incremental configuration of the SN, the target MN sends the UE context established by the source MN to the target SN. SN Add request Otherwise, the target MN can send to the target SN a UE context established by the source MN that does not include the SN UE XnAP ID or the source SN. SN Add Request .

[0173] In step S903, (target) SN with SN Add Request Confirmation Respond. The (target) SN may include an indication of the full or incremental RRC configuration.

[0174] For example, in a CHO with an SCG configuration, the target MN implementation ensures that the CG-Config provided from the (target) SN can be used for all CHO preparations.

[0175] In step S903a, for the bearer using the SN termination of the MCG resource, the target MN is in Xn-U address indication The message provides Xn-U DL TNL address information.

[0176] In step S904, the target MN is Switch request confirmation The message includes an MNRRC reconfiguration message to be sent to the UE to perform a handover, and may also provide a forwarding address to the source MN. If PDU session splitting is performed on the target side during the handover process, then... Switch request confirmation The message includes more than one data forwarding address corresponding to each node. In steps S902 and S903, if the target MN and SN decide to maintain the UE context in the SN, the target MN indicates to the source MN to maintain the UE context in the SN.

[0177] In steps S905a and S905b, the source MN sends to the (source) SN a message including the reason for the MCG's mobility. SN release Release request Message. The (source) SN confirms the release request. If the source MN receives an indication from the target MN, the source MN indicates to the (source) SN to retain the UE context in the SN. If an indication to retain the UE context in the SN is included, the SN retains the UE context.

[0178] In step S905c, the source MN sends an XN-U address indication message to the (source) SN to transmit data forwarding information. If the PDU session is split on the target side, more than one data forwarding address can be provided.

[0179] In step S906, the source MN triggers the UE to perform a handover and apply the new configuration.

[0180] In steps S907 and S908, the UE synchronizes with the target MN and is reconfigured using the MN RRC. Finish Reply to the message.

[0181] In step S909, if a bearer requiring SCG radio resources is configured, the UE synchronizes with the (target) SN.

[0182] For example, the order in which the UE performs random access towards the MN (step S907) and performs random access towards the SN (step S909) is not defined.

[0183] In step S910, if the RRC connection reconfiguration process is successful, the target MN is transmitted via... SN reconfiguration complete The message is sent to the (target) SN.

[0184] In step S911a, the source SN sends to the source MN Auxiliary RAT Data Usage ReportThe message includes the data capacity delivered to and received from the UE via NR / E-UTRA radio.

[0185] For example, sending without defining the source SN. Auxiliary RAT Data Usage Report The order of message and data forwarding with the MN / target SN. The SN may send a report when transmissions of the relevant QoS cease.

[0186] In step S911b, the source MN sends to the AMF. Auxiliary RAT report The message provides information about the NR / E-UTRA resources used.

[0187] In step S912, for a bearer using RLC AM, the source MN sends to the target MN. SN status transfer The message includes (if necessary) the SN status received from the source SN. If necessary, the target forwards the SN status to the target SN.

[0188] In step S913, if applicable, data forwarding is performed from the source side. If the SN is maintained, data forwarding can be omitted for QoS flows maintained in the SN or bearers terminated by the SN.

[0189] In steps S914, S915, S916, and S917, the target MN initiates a path switching process. If the target MN is in Path switching request If the message includes multiple DL TEIDs for a single PDU session, and there is a TEID update in the UPF, it should be reflected in the UPF. Path switch confirmation The message includes multiple UL TEIDs for the UPF of the PDU session.

[0190] For example, if a new UL TEID is included for the UPF of the SN, the target MN performs the MN-initiated SN modification process to provide them to the SN.

[0191] In step S918, the target MN initiates a UE context release process toward the source MN.

[0192] In step S919, after receiving from the source MN UE context release Following the message, the (source) SN releases C-plane-related resources associated with the UE context toward the source MN. Any ongoing data forwarding can continue. If in step S905... SN Release Request If the message includes a UE context retention instruction, the SN will not release the UE context associated with the target MN.

[0193] The technical features related to S-NG-RAN node addition preparation are described below. See section 8.3.1 of 3GPP TS38.423 v17.1.0 for details.

[0194] The purpose of the S-NG-RAN node add preparation process is to request the S-NG-RAN node to allocate resources for dual connectivity operation for a specific UE.

[0195] This process uses UE-associated signaling.

[0196] Figure 10 An example of a successful operation of the S-NG-RAN node addition preparation process is shown.

[0197] The M-NG-RAN node initiates this process by sending an S-NG-RAN node add request message to the S-NG-RAN node.

[0198] When an M-NG-RAN node sends an S-Node Add Request message, it will start timer TXn. DCprep .

[0199] Based on each QoS flow QoS Stream Level QoS Parameters Included in IE Assignment and Retention Priorities The allocation of resources for IE values ​​should follow the principles specified in the PDU session resource creation process.

[0200] S-NG-RAN nodes should be based on UE security capabilities In Internet Explorer, the information and AS encryption algorithm's local configuration priority list selects the encryption algorithm and applies it. S-NG-RAN Node Security Key The key indicated in IE.

[0201] If the request message added to the S node includes information about QoS flows... TSC service characteristics In the case of IE, the S-NG-RAN node should behave the same as the NG-RAN node during the PDU session resource establishment process.

[0202] If the request message added to the S node includes information about QoS flows... Additional QoS flow information In the case of IE, the S-NG-RAN node should behave the same as the NG-RAN node during the PDU session resource establishment process.

[0203] For each GBR QoS flow, if Alternative QoS parameter set IE is included in GBR QoS flow information In IE, S-NG-RAN nodes (if supported) should behave the same as NG-RAN nodes during PDU session resource establishment.

[0204] For each PDU session, if Network Examples IE is included PDU Session Resource Establishment Information - SN Termination IE (which is included in) List of PDU session resources to add In IE, and Public network instancesIf IE is not present, the S-NG-RAN node (if supported) should use it when selecting transport network resources.

[0205] For each GBR QoS flow, if Supply of GBR QoS stream information IE is included QoS flow list to be created IE (which is included in) PDU Session Resource Establishment Information - SN Termination In IE, the S-NG-RAN node can request the M-NG-RAN node to configure the DRB to which the QoS flow is mapped to has MCG resources.

[0206] For each PDU session, if Non-GBR resources available IE is included PDU Session Resource Establishment Information - SN End end IE (which is included in) List of PDU session resources to add If the S-NG-RAN node is set to "true" in IE, then the S-NG-RAN node can request the M-NG-RAN node to map the non-GBR QoS flow of the PDU session to the DRB configured with MCG resources.

[0207] For each PDU session, if Public network instances IE is included PDU Session Resource Establishment Information - SN Termination IE (which is included in) List of PDU session resources to add In IE, the S-NG-RAN node (if supported) should use it when selecting transport network resources.

[0208] Figure 11 An example of an unsuccessful operation during the S-NG-RAN node addition preparation process is shown.

[0209] If an S-NG-RAN node cannot accept any bearers or a failure occurs during S-NG-RAN node add preparation, the S-NG-RAN node sends an S-Node Add Request Rejection message with an appropriate reason value to the M-NG-RAN node.

[0210] In addition, the following has been documented in Rel-18 Further NW Mobility Enhancement WI to support data forwarding optimization in CHO under NR-DC scenarios: The specific objective of this work item is: 1. To specify the mechanisms and processes for L1 / L2-based inter-cell mobility for mobility latency reduction: Configuration and maintenance of multiple candidate cells to allow for rapid application of candidate cell configurations [RAN2, RAN3] - Dynamic handover mechanisms between candidate serving cells (including SpCell and SCell) based on potential application scenarios of L1 / L2 signaling [RAN2, RAN1] - L1 enhancements for inter-cell beam management, including L1 measurement and reporting, and beam indication [RAN1, RAN2] > Early RAN2 involvement is necessary, including further clarification of the project bullet and its relation to previous project bullets. Possibilities of interaction between them > This version only supports L1 measurements based on SSB.

[0211] - Scheduled advance management [RAN1,RAN2]

[0212] - CU-DU interface signaling to support L1 / L2 mobility, if required [RAN3]

[0213] If present, FR2-specific enhancements are not excluded.

[0214] The L1 / L2-based inter-cell mobility process is applicable to the following scenarios: > In standalone, CA, and NR-DC scenarios, when the serving cell changes within a CG, the MCG takes precedence.

[0215] > Intra-DU and intra-CU DU scenarios (applicable to standalone and CA: no new RAN interfaces expected)

[0216] Both within and between frequencies

[0217] Both FR1 and FR2

[0218] The source cell and the target cell can be synchronized or asynchronous.

[0219] 2. To specify the mechanism and process of NR-DC, wherein selective activation of cell groups (at least for SCGs) is performed via L3 enhancement: - To allow subsequent cell group changes after a CG change without reconfiguration and re-initiating CPC / CPA [RAN2,RAN3,RAN4]

[0220] A coordinated RRC modeling approach for objectives 1 and 2 could be considered to minimize the workload in RAN2.

[0221] 3. For CHO[RAN3] in NR-DC, which includes both the target MCG and the target SCG: - To specify data forwarding optimizations; and - If necessary, specify a solution to avoid unnecessary signaling exchange between the source MN and the target SN.

[0222] 4. To specify the CHO[RAN3,RAN2] for candidate SCGs and target MCGs that include CPC / CPA in NR-DC.

[0223] - Use CHO, which includes both the target MCG and the target SCG, as a baseline.

[0224] 5. To specify the core RRM requirements (if necessary) [RAN4] for the following: - Inter-cell mobility based on L1 / L2 - Enhanced CHO configuration solved by this WI 6. To specify RF requirements to cover frequency-based L1 / L2 mobility (if necessary) [RAN4].

[0225] 7. To investigate and specify how to reuse idle / recovery data reported during and / or after RRC connection establishment / recovery. Inactive mode measurement results, in order to improve SCell / SCG setup delay [RAN4, RAN2], include: - The availability and validation of idle / inactive mode measurement results to be reported [RAN4]; and

[0226] - The definition of the corresponding RRM requirements [RAN4]; and

[0227] - If necessary, based on the RAN4 results, refer to the corresponding signaling support definition [RAN2].

[0228] RAN4 will coordinate with RAN2 at the appropriate time to begin operations.

[0229] R4-2220415 is used as a baseline for future work in RAN4.

[0230] In addition to the scenarios mentioned above, measurements of idle / inactive modes and UE behavior in idle / inactive modes are also included. The enhancement is not within the scope.

[0231] Regarding the aforementioned objectives, the following is being discussed: How to optimize early data forwarding in a Chokepoint Request (CHO) under NR-DC scenarios, so that the NW (especially the source side) can avoid repeatedly forwarding data to the target node before the UE executes a CHO under NR-DC. Specifically, multiple T-MN nodes can request a CHO for the same UE, which may reach the same T-SN to prepare conditional configuration for the UE's SCG. In this case, data forwarding from the source side can occur on multiple paths toward the same T-SN. When the admission results of CHO NR-DC requests from different T-MNs are the same, this may lead to the forwarding of duplicate data from PDU sessions or DRBs established in the T-SN.

[0232] Additionally, support for indirect data forwarding is discussed where no direct path is available, i.e., when there is no direct path between the S-SN and T-SN, between the S-MN and T-SN, or between the S-SN and T-MN. In this case, the intermediate node (e.g., the S-MN or T-MN) should be able to determine whether to support indirect data forwarding. If so, it needs to assign its own TNL address to receive forwarded packets and relay them to their final destination accordingly.

[0233] However, it is assumed that this indirect data forwarding is implicitly supported in 3GPP, depending on the implementation. In the case of a unified gNB, the implementation is sufficient because the gNB can handle all control plane and user plane functions. On the other hand, when the gNB is divided into a control plane entity (gNB-CU-CP, also known as CU-CP) and a user plane entity (gNB-CU-UP, also known as CU-UP), this has not been specified. In this case, it is unclear how indirect data forwarding is supported in the CU-UP entity, which is dedicated to handling user plane functions.

[0234] Furthermore, intermediate nodes (e.g., S-MN or T-MN) need to know whether a PDU session or DRB undergoing data forwarding during HO or DC terminates in the MN or SN, in order to appropriately determine indirect forwarding support based on path availability. For example, the T-MN needs to know before triggering HO whether a PDU session that decides to terminate in the T-SN initially terminated in the S-MN or the S-SN. If it terminates in the S-SN but there is no direct path between the S-SN and T-SN (but there is a direct path between the S-SN and T-MN), the T-MN can decide to perform indirect forwarding for that PDU session. If it terminates in the S-MN but there is no direct path between the S-MN and T-SN, the T-MN can decide to perform indirect forwarding for that PDU session. On the other hand, if there is a direct path from the location where the PDU session (decided to terminate in the T-SN) was initially located on the source side to the T-SN, direct forwarding is possible, and the T-MN does not need to perform indirect data forwarding for that PDU session: it can simply forward the destination TNL address to the S-MN during HO preparation.

[0235] Similar logic applies to the S-MN. During HO preparation, the S-MN also needs to know whether the PDU session undergoing data forwarding was established in the MN or SN on the target side. If it was established in the T-SN but initially hosted in the S-SN and there is no direct path between the S-SN and T-SN, the S-MN can decide to perform indirect forwarding for that PDU session. The same applies if it was established in the T-MN but initially hosted in the S-SN and there is no direct path between the S-SN and T-MN. On the other hand, if there is a direct path between the S-SN and T-MN, direct forwarding is possible, and the S-MN has no reason to perform indirect data forwarding for that PDU session.

[0236] Given these considerations, information regarding whether a PDU session or DRB undergoing data forwarding terminates in the MN or SN on the destination (or source) side is crucial for the S-MN (or T-MN) to make informed decisions about indirect forwarding. Path availability is insufficient. Although it is assumed that the T-MN can be accessed via... Handover Preparation The inter-node RRC container determines whether a PDU session or DRB requested to be established during the HO is initially hosted in the S-MN or S-SN, but it is unclear how the S-MN knows whether a PDU session or DRB undergoing data forwarding is hosted in the T-MN or T-SN during HO preparation.

[0237] This disclosure introduces a number of mechanisms to address the above-mentioned problems.

[0238] In the following description, a method for data forwarding in a wireless network system according to some embodiments of the present disclosure will be described with reference to the accompanying drawings.

[0239] The following figures are provided to illustrate specific embodiments of this disclosure. The names of particular devices or signals / messages / fields shown in the figures are provided by way of example, and therefore the technical features of this disclosure are not limited to the specific names used in the following figures. In this document, a wireless device may be referred to as a user equipment (UE).

[0240] Figure 12 Examples of methods for data forwarding in a wireless network system according to some embodiments of the present disclosure are shown.

[0241] Specifically, Figure 12 An example of a method performed by the central unit (CU)-user plane (UP) of a radio access network (RAN) node is shown.

[0242] In step S1201, the CU-UP of the RAN node can perform data forwarding by (i) receiving data from the source RAN node and (ii) forwarding the data to the target RAN node.

[0243] For example, data forwarding can be performed during handover (HO) and / or dual connectivity (DC) processes associated with a wireless device. For example, the wireless device can communicate with at least one of the following: user equipment, network, or autonomous vehicle, other than the wireless device itself.

[0244] In step S1202, the CU-UP of the RAN node can receive information from the source RAN node indicating the end of notification data forwarding.

[0245] For example, information notifying the end of data forwarding may include the last forwarded packet.

[0246] For example, information indicating the end of data forwarding can include an end marker.

[0247] In step S1203, the CU-UP of the RAN node may send a first message to the CU-control plane (CP) of the RAN node, the first message including (i) a forwarding end notification and (ii) information about the resources used for data forwarding related to the forwarding end notification.

[0248] For example, information about resources used for data forwarding may include information about one or more Transport Network Layer (TNL) addresses to be released.

[0249] For example, information about resources used for data forwarding may include at least one Protocol Data Unit (PDU) Session Identifier (ID) and / or at least one Data Radio Bearer (DRB) ID.

[0250] In step S1204, the CU-UP of the RAN node sends a notification to the target RAN node indicating the end of data forwarding.

[0251] In step S1205, the CU-UP of the RAN node can release resources used for data forwarding.

[0252] For example, the CU-UP of a RAN node can receive a second message from the CU-CP that includes a forwarding end notification response, which indicates that the resources used for data forwarding have been released.

[0253] According to some embodiments of this disclosure, the CU-UP may pre-assign one or more TNL addresses to be used for data forwarding before performing data forwarding. In this case, the CU-UP may send information about the pre-assigned one or more TNL addresses to the CU-CP. The CU-UP may receive information about at least one TNL address for data forwarding from the CU-CP. For example, at least one TNL address may be determined from the pre-assigned one or more TNL addresses.

[0254] According to some embodiments of this disclosure, the RAN node can be a target primary node (MN), and the target RAN node can be a target secondary node. In this case, before performing data forwarding, the CU-UP can receive a third message from the CU-CP, which includes (i) a data forwarding request and (ii) information about resources used for data forwarding. Information about resources used for data forwarding can be allocated and delivered from the target RAN node. The CU-UP can assign corresponding resources for data forwarding. The CU-UP can send a fourth message to the CU-CP, which includes (i) a data forwarding response and (ii) information about the assigned resources used for data forwarding.

[0255] The following describes an implementation of support for indirect data forwarding in T-MN (that is, implementation 1).

[0256] After adding a T-SN and knowing that there is no direct path between the source and the T-SN, the T-MN CU-CP can decide to perform indirect data forwarding for some PDU sessions or DRBs established in the T-SN and undergoing data forwarding. The T-MN CU-CP requests the T-MN CU-UP to perform indirect data forwarding and provides the forwarding TNL addresses received from the T-SN for those PDU sessions and DRBs, and retrieves the corresponding forwarding TNL addresses assigned by the T-MN CU-UP. As part of the HO procedure, the forwarding TNL addresses retrieved from the T-MN CU-UP replace those corresponding forwarding TNL addresses received from the T-SN and are delivered to the source for data forwarding. The T-MN CU-UP performs indirect data forwarding by relaying forwarded packets received from the source to the forwarding TNL addresses provided by the T-MN CU-CP.

[0257] Figure 13 A flowchart illustrating indirect data forwarding support in T-MN is shown.

[0258] Specifically, Figure 13 This describes the situation where the T-MN, in its CU-UP entity, decides on indirect data forwarding for some PDU sessions or DRBs established in the T-SN and subject to data forwarding.

[0259] In step S1301, the source initiates a HO towards the UE's T-MN CU-CP.

[0260] In steps S1302 and S1303, based on the measurement results, the T-MN CU-CP decides to add a secondary node for the UE and performs an SN addition procedure with the T-SN. For PDU sessions and DRBs requested to be established in the T-SN, the T-SN performs admission control. For PDU sessions or DRBs established in the T-SN and undergoing data forwarding (the T-SN accepts data forwarding proposals from the source), the T-SN provides the T-MN CU-CP with the corresponding forwarding TNL address and its direct path availability information with the source side (S-MN or S-SN).

[0261] In step S1304, based on the direct path availability information received from the T-SN, and based on whether the PDU session successfully established in the T-SN or the DRB was initially located in the S-MN or the S-SN before the HO was triggered (the T-MN CU-CP can be obtained via step S1301), Handover Preparation (The inter-node RRC container knows) that the T-MN makes a decision on whether to perform indirect data forwarding for each PDU session or DRB established in the T-SN and subjected to data forwarding.

[0262] For example, if the T-SN indicates that the direct path to the S-SN is unavailable, but the T-MN has a direct path to the S-SN, the T-MN can decide to perform indirect data forwarding for PDU sessions and DRBs (which were originally hosted in the S-SN) established in the T-SN and subjected to data forwarding.

[0263] For example, if the T-SN indicates that a direct path to the S-MN is not available, the T-MN may decide to perform indirect data forwarding for PDU sessions and DRBs (which were originally hosted in the S-MN) established in the T-SN and subjected to data forwarding.

[0264] If it is decided to perform indirect data forwarding, the T-MN CU-CP requests the T-MN CU-UP to perform indirect data forwarding and provides the corresponding forwarding TNL address received from the T-SN in step S1303.

[0265] In step S1305, T-MN CU-UP assigns a corresponding forwarding TNL address for each forwarding TNL address received from T-MN CU-CP and provides the assigned forwarding TNL address back to T-MN CU-CP.

[0266] In step S1306, as part of the HO process, the T-MN CU-CP replaces the forwarding TNL address received from the T-SN with the received forwarding TNL address assigned by the T-MN CU-UP and delivers them to the source.

[0267] If the T-SN indicates that it does not have a direct path available to the S-SN, and if there are some PDU sessions or DRBs that were originally hosted in the S-SN and established in the T-SN, then as part of the HO process, if the T-MN CU-CP decides not to perform indirect data forwarding, then those forwarding TNL addresses (received from the T-SN) can be forwarded to the source. If the T-SN indicates that it has a direct path to the S-MN, then it expects the S-MN to support indirect data forwarding instead of those forwarding TNL addresses.

[0268] On the other hand, if the T-SN indicates that it has no available direct path to the source side (i.e., to both the S-MN and S-SN), this essentially means that direct data forwarding is impossible towards the T-SN unless indirect forwarding is performed at the T-MN. If it is decided not to perform indirect forwarding at the T-MN, the T-MN may not forward those forwarding TNL addresses received from the T-SN as part of the HO process (thus not initiating data forwarding from the source side). In this case, the T-MN can send an end marker to the T-SN to terminate the data forwarding process for those forwarding TNL addresses, which the T-SN considers accepted and expects to receive the forwarded data.

[0269] The following describes an implementation of indirect data forwarding support in S-MN (that is, implementation 2).

[0270] After receiving a handover request confirmation message from the target side and knowing that there is no direct path between the S-SN and the target side, and knowing whether the PDU sessions or DRBs recognized by the target are established in the T-MN or T-SN, the S-MN CU-CP can decide to perform indirect data forwarding for some PDU sessions or DRBs recognized by the target side and undergoing data forwarding. The S-MN CU-CP requests the S-MN CU-UP to perform indirect data forwarding, providing the forwarding TNL addresses received from the target side for those PDU sessions and DRBs, and retrieves the corresponding forwarding TNL addresses assigned by the S-MN CU-UP. The forwarding TNL addresses retrieved from the S-MN CU-UP replace those corresponding forwarding TNL addresses received from the target side and are delivered to the S-SN for data forwarding. The S-MN CU-UP performs indirect data forwarding by relaying forwarded packets received from the S-SN to the forwarding TNL addresses provided by the S-MN CU-CP.

[0271] Figure 14 A flowchart illustrating indirect data forwarding support in S-MN is shown.

[0272] Figure 14 This describes the situation where the S-MN, within its CU-UP entity, decides to forward indirect data for some PDU sessions or DRBs that are recognized by the target and undergo data forwarding.

[0273] In step S1401, S-MN CU-CP initiates HO toward the target of UE.

[0274] In step S1402, the target performs admission control and responds back to the S-MN CU-CP. For PDU sessions and DRBs that are recognized by the target and undergo data forwarding, the target provides the corresponding forwarding TNL address along with its direct path availability information with the S-SN to the S-MN CU-CP. The target also provides information on whether the PDU session or DRB is recognized by the T-MN or the T-SN.

[0275] In step S1403, based on the information received from the target in step S1402 and based on whether the PDU session or DRB recognized by the target was initially located in the S-MN or S-SN before the HO was triggered, the S-MN CU-CP decides whether to perform indirect data forwarding for each PDU session or DRB recognized by the target and subjected to data forwarding.

[0276] For example, if the target indicates that a direct path between the S-SN and T-SN is unavailable, the S-MN can decide to perform indirect data forwarding for PDU sessions and DRBs (which are originally hosted in the S-SN) established in the T-SN and subject to data forwarding.

[0277] For example, if the target indicates that a direct path between the S-SN and the T-MN is unavailable, the S-MN can decide to perform indirect data forwarding for PDU sessions and DRBs (which are originally hosted in the S-SN) established in the T-MN and subject to data forwarding.

[0278] If it is decided to perform indirect data forwarding, the S-MN CU-CP requests the S-MN CU-UP to perform indirect data forwarding and provides the corresponding forwarding TNL address received from the target side in step S1402.

[0279] In step S1404, S-MN CU-UP assigns a corresponding forwarding TNL address for each forwarding TNL address received from S-MN CU-UP and provides the assigned forwarding TNL address back to S-MN CU-CP.

[0280] In step S1405, the S-MN CU-CP replaces the forwarding TNL addresses received from the target side with the forwarding TNL addresses assigned by the S-MN CU-UP and delivers them to the S-SN. For some PDU sessions or DRBs recognized by the target side for which the S-MN CU-CP decides not to perform indirect data forwarding, those forwarding TNL addresses (received from the target side) are forwarded to the S-SN.

[0281] This process can also be applied to Figure 14 The target in this scenario is a SN change scenario for another SN, and the SN addition process is used in steps S1401 and S1402. In this case, information about whether the PDU session or DRB is recognized by the T-MN or the T-SN is not applicable.

[0282] The following describes an implementation method for terminating indirect data forwarding from the CU-UP (that is, implementation method 3).

[0283] Indirect data forwarding is complete when the last forwarded packet (i.e., the end-of-transfer packet) is received and forwarded. When the CU-UP receives the end-of-transfer packet in its forwarding TNL address (assigned for the purpose of indirect forwarding), the CU-UP notifies the CU-CP to release indirect data forwarding from that TNL address, while forwarding the end-of-transfer packet to the forwarding TNL address configured from the CU-CP.

[0284] Figure 15 A flowchart is shown to illustrate the termination of indirect data forwarding from the CU-UP.

[0285] Figure 15 This describes the process of releasing indirect data forwarding support from the CU-UP when indirect data forwarding is completed, which can be applied to Implementation 1 and Implementation 2.

[0286] In step S1501, the CU-UP (S-MN CU-UP or T-MN CU-UP) receives the last forwarded packet (i.e., the end marker) indicating the end of data forwarding in its forwarding TNL address.

[0287] In step S1502, the CU-UP notifies the CU-CP (S-MN CU-CP or T-MN CU-CP) that indirect data forwarding is complete. The CU-UP can notify which forwarding TNL addresses received the end-of-time packet and will be released. The CU-UP can also notify their corresponding forwarding TNL addresses, which are configured from the CU-CP to forward the received packets to them.

[0288] In step S1503, CU-CP confirms the release of indirect data forwarding from CU-UP for the indicated forwarding TNL address.

[0289] In step S1504, the CU-UP forwards the last received packet (i.e., the end marker) to the corresponding forwarding TNL address configured from the CU-CP and releases the resources allocated for the completed indirect data forwarding.

[0290] For example, in this embodiment (that is, embodiment 3), step S1503 can be skipped.

[0291] For example, in this embodiment (that is, embodiment 3), step S1504 may occur before step S1502.

[0292] The following describes an implementation of resource pooling for indirect data forwarding support in CU-UP (that is, implementation 4).

[0293] Resource pools can be reserved, and forwarding TNL addresses can be pre-assigned in the CU-UP and communicated to the CU-CP for the purpose of supporting indirect data forwarding. The CU-CP can then use the pre-assigned forwarding TNL addresses at the CU-UP for indirect forwarding and configure which TNL the CU-UP should forward received packets to.

[0294] Figure 16 A flowchart is shown for resource pooling support for indirect data forwarding in CU-UP.

[0295] Figure 16The process of pre-assigning forwarding TNL addresses for indirect data forwarding in CU-UP is described, which can be applied to implementation 1 and implementation 2.

[0296] In step S1601, the CU-UP (S-MN CU-UP or T-MN CU-UP) pre-assigns a forwarding TNL address to support indirect data forwarding.

[0297] In step S1602, the CU-UP delivers the pre-assigned forwarding TNL address to the CU-CP (S-MN CU-CP or T-MN CU-CP).

[0298] In step S1603, once the CU-CP decides on indirect data forwarding during the HO or DC process, the CU-CP configures the CU-UP to have a pre-assigned TNL address for indirect data forwarding and its corresponding forwarding TNL address to which received packets are forwarded.

[0299] In step S1604, CU-UP begins indirect data forwarding.

[0300] Below, examples of methods according to some embodiments of this disclosure are described.

[0301] (1): A method for supporting indirect data forwarding in a network system during HO or DC processes.

[0302] (2): According to the method of (1), the network system includes network nodes interconnected via an X2 or Xn interface.

[0303] (3): According to the method described in (2), the network node may include a control plane (CU-CP) and a user plane (CU-UP) interconnected via an E1 interface.

[0304] (4): According to the method described in (3), the target node can decide on indirect data forwarding for PDU sessions or DRBs established in the target SN (secondary node).

[0305] (4-1): According to the method described in (4), the information that determines indirect data forwarding may include: the availability of the direct path to the source node, and the location from which the PDU session or DRB (established in the target SN and subjected to data forwarding) originates in the source node.

[0306] (5): According to the method described in (3), the target node CU-CP may request its CU-UP entity to perform indirect data forwarding and provide the forwarding TNL address received from the target SN.

[0307] (5-1): According to the method described in (5), CU-UP assigns a corresponding forwarding TNL address for each forwarding TNL address received from the target node CU-CP, and responds to the assigned forwarding TNL address.

[0308] (5-2) According to the method described in (5), the target node CU-CP replaces the forwarding TNL address received from the target SN with the received forwarding TNL address assigned by its CU-UP entity and delivers them to the source node.

[0309] (6) According to the method of (3), the source node may decide on indirect data forwarding for a PDU session or DRB established in the target node.

[0310] (6-1) According to the method of (6), the information for determining indirect data forwarding may include: the availability of the direct path to the target node, and the location in the target node where the PDU session or DRB is initially hosted in the source SN (secondary node).

[0311] (7) According to the method of (6), the source node CU-CP may request its CU-UP entity to perform indirect data forwarding and provide the forwarding TNL address received from the target node.

[0312] (7-1) According to the method of (7), wherein the CU-UP assigns a corresponding forwarding TNL address for each forwarding TNL address received from the source node CU-CP and responds to the assigned forwarding TNL address.

[0313] (7-2) According to the method of (7), the source node CU-CP replaces the forwarding TNL address received from the target node with the received forwarding TNL address assigned by its CU-UP entity and delivers them to the source SN.

[0314] (8) The method according to (5) or (7), wherein the CU-UP notifies the CU-CP of the end of data forwarding.

[0315] (8-1) According to the method of (8), the information from CU-UP may include: which forwarding TNL address received the last forwarded packet and is about to be released, and their corresponding forwarding TNL address, which is configured from CU-CP to forward the received packet.

[0316] (8-2) According to the method of (8), wherein the CU-CP confirms the release from the CU-UP of the indirect data forwarding for the indicated forwarding TNL address.

[0317] (8-3) According to the method of (8), wherein the CU-UP forwards the last received packet to the corresponding forwarding TNL address configured from the CU-CP and releases the resources allocated for the completed indirect data forwarding.

[0318] (9) The method according to (5) or (7), wherein the CU-UP pre-assigns a forwarding TNL address to support indirect data forwarding.

[0319] (9-1) According to the method of (9), wherein the CU-UP notifies the CU-CP of the pre-assigned forwarding TNL address.

[0320] (9-2) According to the method of (9), wherein the CU-CP that determines indirect data forwarding configures the CU-UP to have a pre-assigned TNL address for indirect data forwarding and its corresponding forwarding TNL address (to which the received packets are to be forwarded) so that the CU-UP can start performing indirect data forwarding accordingly.

[0321] Figure 17 Examples of methods for indirect data forwarding in a wireless network system according to some embodiments of the present disclosure are shown.

[0322] For example, a handover from source to target can be performed on a wireless device. The target may include a target master node (MN) and a target slave node (SN). The target MN may include at least one central unit (CU) - control plane (CP), at least one central unit (CU) - user plane (UP), and at least one distributed unit (DU).

[0323] Specifically, Figure 17 An example of a method performed by the central unit (CU)-control plane (CP) of a radio access network (RAN) node (e.g., the CU-CP of a target MN) is shown.

[0324] In step S1701, the CU-CP (e.g., the CU-CP of the target MN) may send a first message to the CU-UP of the RAN node (e.g., the CU-UP of the target MN), the first message including: (i) information requesting the execution of indirect data forwarding, (ii) information related to the forwarding transport layer, and (iii) information requesting the allocation of the receiving transport layer corresponding to the forwarding transport layer.

[0325] For example, before step S1701, the CU-CP of the target master node (MN) can send an S-NG-RAN node add request message to the target slave node (SN). The CU-CP can receive an S-NG-RAN node add request confirmation message from the target SN.

[0326] For example, the CU-CP of the target MN can receive information related to the forwarding transport layer from the target SN. For example, the information related to the forwarding transport layer can be included in the S-NG-RAN node's add request acknowledgment message or a new message.

[0327] For example, prior to step S1701, the CU-CP of the source master node (MN) can send a handover request message to the target RAN node. The CU-CP can then receive a handover request confirmation message from the target RAN node.

[0328] For example, the CU-CP of the source MN can receive information related to the forwarding transport layer from the target RAN node. For example, the information related to the forwarding transport layer can be included in the handover request confirmation message or a new message.

[0329] For example, the source MN's CU-CP can receive information from the target RAN node related to whether the PDU session or DRB is acknowledged by the target MN or the target SN. This information can be included in the handover request confirmation message or a new message.

[0330] For example, the CU-CP can receive information from the target RAN node regarding the availability of a direct path to the target SN. This information can be included in the handover request confirmation message or a new message.

[0331] For example, prior to step S1701, the CU-CP may decide whether to perform indirect data forwarding based on information about whether a direct path between the notification and the target SN is available.

[0332] For example, the forwarding transport layer can be associated with at least one PDU session and / or at least one TNL address associated with a DRB established in the target secondary node (SN).

[0333] For example, information requesting indirect data forwarding can be included in a special trigger destination information element (IE).

[0334] For example, a special triggering purpose IE can be included in the list of PDU session resource modifications to be established IE contained in the bearer context modification request message. gNB-CU-UP may consider the establishment of a DRB or PDU session including the IE to be for the purpose of indirect data forwarding. For example, a special triggering purpose IE can be included in the list of PDU session resource modifications to be established IE contained in the bearer context modification request message. gNB-CU-UP may store bearer context information and consider the establishment of a DRB including the IE to be for the purpose of indirect data forwarding.

[0335] For example, a Special Trigger Item Information Element (IE) can be set as the destination for indirect data forwarding.

[0336] For example, to support indirect data forwarding, the target MN-CU-CP is now allowed to retrieve the receive TNL address and simultaneously configure the forwarding TNL address with respect to the target MN-CU-UP via a single round-trip procedure on the E1AP to establish indirect data forwarding.

[0337] For example, a single round-trip procedure for configuring indirect data forwarding can be as follows. For instance, the target MN can decide to split a PDU session (e.g., in dual connectivity, a PDU session can be divided into an MN and an SN. Some QoS flows within the PDU session for the UE can be served by the MN, and some QoS flows within the PDU session for the UE can be served by the SN). The target MN-CU-CP can first establish the relevant PDU session in the target MN-CU-UP before adding the target SN, and then add the target SN. At this point, the target SN may not know whether direct or indirect data forwarding with the source is possible. Therefore, special triggering purposes may not be used in such bearer context establishment request messages. In other words, before step S1701, the target MN-CU-UP may not receive information from the target SN requesting the execution of indirect data forwarding. Afterwards, when adding the target SN, the remaining QoS flows of the split PDU session can also be successfully established in the target SN, thereby creating an SN DRB. When the target SN accepts DRB data forwarding proposed by the source RAN node, it can reply to the target MN (i.e., the CU-CP) and notify whether a direct path with the source exists. (For example, the forwarding TNL address allocated from the source for data forwarding can also be notified to the target MN.) If the target SN sends a notification that there is no direct path information, the target MN-CU-CP can establish a DRB for indirect data forwarding for the target SN's DRB in the target MN-CU-UP (under this split PDU session). In this case, the establishment of the target SN's DRB can be requested in the second message (e.g., a bearer context modification request message) via a list of DRBs to be established included in the list of PDU session resources to be modified. Since this is a DRB for indirect data forwarding purposes, a "special triggering purpose" can be used. Simultaneously, the target MN-CU-CP can request the target MN-CU-UP to allocate a TNL address for the corresponding PDU session or DRB to receive forwarded data from the source. The forwarding TNL address information for the target SN for the relevant DRB can also be provided simultaneously via the list of DRBs to be modified within the same bearer context modification request message (e.g., via the list of PDU session resources to be modified). And since the request is made to allocate a TNL address for the corresponding PDU session or DRB, the target MN-CU-UP allocates the corresponding TNL address. The target MN-CU-UP can send information, including the assigned TNL address, back to the target MN-CU-CP.

[0338] For example, information related to the forwarding transport layer can be included in the data forwarding information IE. For example, information related to the forwarding transport layer can be included in the PDU session data forwarding information IE or the DRB data forwarding information IE. For example, the data forwarding information IE can include uplink (UL) data forwarding information or downlink (DL) data forwarding information (e.g., UP transport layer information). For example, the data forwarding information IE can provide data forwarding address information during handover or data offloading.

[0339] For example, during a handover, the source can request data forwarding from the target, which is divided into UL or DL ​​data forwarding requests. Therefore, the target can accept UL and / or DL ​​data forwarding individually. The target can also assign a corresponding TNL address individually and send information associated with the assigned TNL address to the source.

[0340] For example, a DRB that requires PDCP SN maintenance (i.e., mapping to RLC AM) can be used to transmit out-of-order PDCP SNs that were not successfully delivered to the CN in the UL PDCP SDU received from the UE during the HO period to the target side. (The target can then send a PDCP status report to the UE and request the UE to retransmit only the lost PDCP SDUs).

[0341] For example, information requesting the allocation of a receive TNL corresponding to a forwarded TNL can be included in the data forwarding information request IE. For example, information requesting the allocation of a receive TNL corresponding to a forwarded TNL can be included in the PDU session data forwarding information request IE or the DRB data forwarding information request IE.

[0342] For example, the Data Forwarding Information Request IE can provide the possibility for the gNB-CU-CP to request a data forwarding address to be allocated by the gNB-CU-UP. It also provides the possibility for the gNB-CU-CP to provide a list of QoS flows subject to PDU session-level or DRB-level data forwarding restrictions to the gNB to which the DRB or QoS flow has been offloaded. For example, the Data Forwarding Information Request IE can be included as enumerated type data (e.g., notifications to UL, DL, both, etc.).

[0343] For example, the first message could be a context modification request message.

[0344] In step S1702, in response to the first message, the CU-CP can receive a second message from the CU-UP, the second message including information related to the allocated receive transport layer.

[0345] For example, the assigned receive transport layer can be associated with the CU-UP-related TNL address used for indirect data forwarding. For example, information associated with the assigned receive transport layer can be included in the PDU session data forwarding information response IE or the DRB data forwarding information response IE.

[0346] For example, the second message may include a bearer context modification response message.

[0347] For example, the CU-CP can send information related to the assigned receive transport layer to the source SN. For example, the information related to the assigned receive transport layer can be included in the Xn-U address indication.

[0348] For example, indirect data forwarding may include (i) the transmission of data packets from the source RAN node to the CU-UP and (ii) the transmission of data packets from the CU-UP to the target SN.

[0349] For example, data packet transmission from the source RAN node to the CU-UP can be performed based on information associated with the assigned receive transport layer. That is, the source RAN node can send data packets to the CU-UP based on information associated with the assigned receive transport layer (e.g., the CU-UP's TNL address).

[0350] For example, data packets can be transmitted from the CU-UP to the target SN based on information related to the forwarding transport layer.

[0351] In other words, CU-UP can forward data packets to the target SN based on information related to the forwarding transport layer (e.g., the TNL address of the target SN).

[0352] In other words, when the first message is received from the CU-CP in step S1701, the CU-UP can assign a receive TNL address that is mapped to the forwarding TNL address of the receiving target SN (according to the request of the target MN-CU-CP) and deliver it back to the target MN-CU-CP.

[0353] In other words, when forwarding data from the source side (e.g., source MN or source SN) to the target SN, since there is no direct path between the source side and the target SN, the target MN-CU-UP can act as a relay in the middle.

[0354] Information related to the receive TNL address of the target MN-CU-UP can be sent to the source side. When forwarding data from the source to the target, packets can first be delivered to the receive TNL address of the target MN-CU-UP. The target MN-CU-UP, which receives the forwarded packets to the corresponding TNL, can then relay the received packets to the forwarding TNL address of the target SN, thus performing indirect data forwarding.

[0355] Figure 12 , Figure 13 , Figure 14 , Figure 15 , Figure 16 and Figure 17 Some of the detailed steps shown in the examples may not be necessary and may be omitted. Besides... Figure 12 , Figure 13 , Figure 14 , Figure 15 , Figure 16 and Figure 17 In addition to the steps shown, other steps can be added, and the order of the steps can be changed. Some of the steps above may have their own technical meaning.

[0356] In the following, an apparatus for data forwarding in a wireless network system according to some embodiments of the present disclosure will be described.

[0357] Here, the RAN node can be Figure 7 In a gNB (gNodeB), a RAN node may include a transceiver, memory, and at least one processor. At least one processor may be operatively coupled to the memory and the transceiver.

[0358] For example, a handover from source to target can be performed on a wireless device. The target may include a target master node (MN) and a target slave node (SN). The target MN may include at least one central unit (CU) - control plane (CP), at least one central unit (CU) - user plane (UP), and at least one distributed unit (DU).

[0359] For example, a RAN node can be a target master node. A RAN node can include at least one Central Unit (CU) - User Plane (UP), at least one Central Unit (CU) - Control Plane (CP), and at least one Distributed Unit (DU). CU-CP can include memory and at least one processor. CU-UP can include memory and at least one processor.

[0360] At least one processor may be adapted to control the CU-CP to send a first message to the CU-User Plane (UP) of the RAN node, the first message including: (i) information requesting the performance of indirect data forwarding, (ii) information related to the forwarding transport layer, and (iii) information requesting the allocation of a receive transport layer corresponding to the forwarding transport layer. At least one processor may be adapted to control the CU-CP to receive a second message from the CU-UP in response to the first message, the second message including information related to the allocated receive transport layer.

[0361] For example, the forwarding transport layer is associated with at least one PDU session and / or at least one TNL address associated with a DRB established in the target secondary node (SN).

[0362] For example, the assigned receive transport layer is associated with a CU-UP-related TNL address used for indirect data forwarding.

[0363] For example, indirect data forwarding includes (i) the transmission of data packets from the source RAN node to the CU-UP and (ii) the transmission of data packets from the CU-UP to the destination SN. For example, the transmission of data packets from the source RAN node to the CU-UP is performed based on information related to the allocated receive transport layer. For example, the transmission of data packets from the CU-UP to the destination SN is performed based on information related to the forwarding transport layer.

[0364] For example, at least one processor may be adapted to control the CU-CP to send information related to the allocated receive transport layer to the source SN.

[0365] For example, information requesting indirect data forwarding is included in a special trigger destination information element (IE).

[0366] For example, information related to the forwarding transport layer is included in the data forwarding information (IE).

[0367] For example, the request to allocate information for the receiving transport layer corresponding to the forwarding transport layer is included in the data forwarding information request IE.

[0368] For example, the first message includes a context modification request message.

[0369] For example, the second message includes a context modification response message.

[0370] For example, at least one processor may be adapted to control the CU-CP to receive information related to the forwarding transport layer from the target SN.

[0371] At least one processor may be adapted to control the CU-UP to perform data forwarding by (i) receiving data from a source RAN node and (ii) forwarding the data to a target RAN node. At least one processor may be adapted to control the CU-UP to receive information from the source RAN node notifying the end of data forwarding. At least one processor may be adapted to control the CU-UP to send a first message to the CU-control plane (CP) of the RAN node, the first message including (i) a forwarding end notification and (ii) information regarding resources used for data forwarding associated with the forwarding end notification. At least one processor may be adapted to control the CU-UP to send information notifying the end of data forwarding to the target RAN node. At least one processor may be adapted to control the CU-UP to release resources used for data forwarding.

[0372] For example, at least one processor may be adapted to control the CU-UP to receive a second message from the CU-CP including a forwarding end notification response that notifies that resources used for data forwarding have been released.

[0373] For example, information notifying the end of data forwarding may include the last forwarded packet.

[0374] For example, information indicating the end of data forwarding can include an end marker.

[0375] For example, information about resources used for data forwarding may include information about one or more Transport Network Layer (TNL) addresses to be released.

[0376] For example, information about resources used for data forwarding may include at least one Protocol Data Unit (PDU) Session Identifier (ID) and / or at least one Data Radio Bearer (DRB) ID.

[0377] For example, at least one processor may be adapted to control the CU-UP to pre-assign one or more TNL addresses for data forwarding before performing data forwarding. At least one processor may be adapted to control the CU-UP to send information to the CU-CP regarding the pre-assigned one or more TNL addresses. At least one processor may be adapted to control the CU-UP to receive information from the CU-CP regarding at least one TNL address for data forwarding. At least one TNL address may be determined from the pre-assigned one or more TNL addresses.

[0378] For example, the RAN node can be the target primary node (MN), and the target RAN node can be the target secondary node. At least one processor can be adapted to control the CU-UP to receive a third message from the CU-CP before performing data forwarding, the third message including (i) a data forwarding request and (ii) information regarding resources used for data forwarding. Information regarding resources used for data forwarding can be sent from the target RAN node. At least one processor can be adapted to control the CU-UP to assign resources for data forwarding. At least one processor can be adapted to control the CU-UP to send a fourth message to the CU-CP, the fourth message including (i) a data forwarding response and (ii) information regarding the assigned resources used for data forwarding.

[0379] For example, data forwarding can be performed during handover (HO) and / or dual connectivity (DC) processes associated with a wireless device. For example, the wireless device can communicate with at least one of the following: user equipment, network, or autonomous vehicle, other than the wireless device itself.

[0380] In the following, a processor for the central unit (CU)-control plane (CP) of a RAN node for data forwarding in a wireless network system according to some embodiments of the present disclosure will be described.

[0381] For example, a handover from source to target can be performed on a wireless device. The target may include a target master node (MN) and a target slave node (SN). The target MN may include at least one central unit (CU) - control plane (CP), at least one central unit (CU) - user plane (UP), and at least one distributed unit (DU).

[0382] For example, a RAN node can be a target master node. A RAN node can include at least one Central Unit (CU) - User Plane (UP), at least one CU - Control Plane (CP), and at least one Distributed Unit (DU). A CU-CP can include memory and at least one processor. A CU-UP can include memory and at least one processor.

[0383] The processor can be configured to control the CU-CP to send a first message to the CU-User Plane (UP) of the RAN node, the first message including: (i) information requesting the performance of indirect data forwarding, (ii) information related to the forwarding transport layer, and (iii) information requesting the allocation of a receive transport layer corresponding to the forwarding transport layer. The processor can also be configured to control the CU-CP to receive a second message from the CU-UP in response to the first message, the second message including information related to the allocated receive transport layer.

[0384] For example, the forwarding transport layer is associated with at least one PDU session and / or at least one TNL address associated with a DRB established in the target secondary node (SN).

[0385] For example, the assigned receive transport layer is associated with a CU-UP-related TNL address used for indirect data forwarding.

[0386] For example, indirect data forwarding includes (i) the transmission of data packets from the source RAN node to the CU-UP and (ii) the transmission of data packets from the CU-UP to the destination SN. For example, the transmission of data packets from the source RAN node to the CU-UP is performed based on information related to the allocated receive transport layer. For example, the transmission of data packets from the CU-UP to the destination SN is performed based on information related to the forwarding transport layer.

[0387] For example, the processor can be configured to control the CU-CP to send information related to the allocated receive transport layer to the source SN.

[0388] For example, information requesting indirect data forwarding is included in a special trigger destination information element (IE).

[0389] For example, information related to the forwarding transport layer is included in the data forwarding information (IE).

[0390] For example, the request to allocate information for the receiving transport layer corresponding to the forwarding transport layer is included in the data forwarding information request IE.

[0391] For example, the first message includes a context modification request message.

[0392] For example, the second message includes a context modification response message.

[0393] For example, the processor can be configured to control the CU-CP to receive information related to the forwarding transport layer from the target SN.

[0394] In the following, a processor for the central unit (CU)-user plane (UP) of a RAN node for data forwarding in a wireless network system according to some embodiments of the present disclosure will be described.

[0395] The processor can be configured to control the CU-UP to perform data forwarding by (i) receiving data from a source RAN node and (ii) forwarding that data to a target RAN node. The processor can be configured to control the CU-UP to receive information from the source RAN node notifying the end of data forwarding. The processor can be configured to control the CU-UP to send a first message to the CU-control plane (CP) of the RAN node, the first message including (i) a forwarding end notification and (ii) information regarding resources used for data forwarding related to the forwarding end notification. The processor can be configured to control the CU-UP to send information to the target RAN node notifying the end of data forwarding. The processor can be configured to control the CU-UP to release resources used for data forwarding.

[0396] For example, the processor can be configured to control the CU-UP to receive a second message from the CU-CP, including a forwarding end notification response that notifies that the resources used for data forwarding have been released.

[0397] For example, information notifying the end of data forwarding may include the last forwarded packet.

[0398] For example, information indicating the end of data forwarding can include an end marker.

[0399] For example, information about resources used for data forwarding may include information about one or more Transport Network Layer (TNL) addresses to be released.

[0400] For example, information about resources used for data forwarding may include at least one Protocol Data Unit (PDU) Session Identifier (ID) and / or at least one Data Radio Bearer (DRB) ID.

[0401] For example, the processor can be configured to control the CU-UP to pre-assign one or more TNL addresses for data forwarding before performing data forwarding. The processor can be configured to control the CU-UP to send information about the pre-assigned one or more TNL addresses to the CU-CP. The processor can be configured to control the CU-UP to receive information from the CU-CP about at least one TNL address for data forwarding. At least one TNL address can be determined from the pre-assigned one or more TNL addresses.

[0402] For example, the RAN node can be the target primary node (MN), and the target RAN node can be the target secondary node. The processor can be configured to control the CU-UP to receive a third message from the CU-CP before performing data forwarding, the third message including (i) a data forwarding request and (ii) information regarding resources used for data forwarding. Information regarding resources used for data forwarding can be sent from the target RAN node. The processor can be configured to control the CU-UP to assign resources for data forwarding. The processor can be configured to control the CU-UP to send a fourth message to the CU-CP, the fourth message including (i) a data forwarding response and (ii) information regarding the assigned resources used for data forwarding.

[0403] For example, data forwarding can be performed during handover (HO) and / or dual connectivity (DC) processes associated with a wireless device. For example, the wireless device can communicate with at least one of the following: user equipment, network, or autonomous vehicle, other than the wireless device itself.

[0404] In the following, a non-transitory computer-readable medium storing multiple instructions for data forwarding in a wireless network system will be described according to some embodiments of the present disclosure.

[0405] According to some embodiments of this disclosure, the technical features of this disclosure can be directly implemented in hardware, in software executed by a processor, or a combination of both. For example, a method executed by a wireless device in wireless communication can be implemented in hardware, software, firmware, or any combination thereof. For example, software can reside in RAM memory, flash memory, ROM memory, EPROM memory, EEPROM memory, registers, hard disk, removable disk, CD-ROM, or any other storage medium.

[0406] Some examples of storage media are coupled to a processor, allowing the processor to read information from the storage media. Alternatively, the storage media can be integrated into the processor. The processor and storage media can reside in an ASIC. Yet another example is that the processor and storage media can exist as discrete components.

[0407] Computer-readable media can include tangible and non-transitory computer-readable storage media.

[0408] For example, non-transitory computer-readable media may include random access memory (RAM), such as synchronous dynamic random access memory (SDRAM), read-only memory (ROM), non-volatile random access memory (NVRAM), electrically erasable programmable read-only memory (EEPROM), flash memory, magnetic or optical data storage media, or any other media that can be used to store instructions or data structures. Non-transitory computer-readable media may also include combinations of the above.

[0409] Furthermore, the methods described herein can be implemented at least in part by a computer-readable communication medium that carries or transmits code in the form of instructions or data structures and can be accessed, read, and / or executed by a computer.

[0410] According to some embodiments of this disclosure, a non-transitory computer-readable medium has a plurality of instructions stored thereon. The plurality of instructions stored can be executed by a processor of the central unit (CU)-control plane (CP) of a radio access network (RAN) node.

[0411] For example, a handover from source to target can be performed on a wireless device. The target may include a target master node (MN) and a target slave node (SN). The target MN may include at least one central unit (CU) - control plane (CP), at least one central unit (CU) - user plane (UP), and at least one distributed unit (DU).

[0412] For example, a RAN node can be a target master node. A RAN node can include at least one Central Unit (CU) - User Plane (UP), at least one Central Unit (CU) - Control Plane (CP), and at least one Distributed Unit (DU). CU-CP can include memory and at least one processor. CU-UP can include memory and at least one processor.

[0413] The stored instructions enable the CU-CP to send a first message to the CU-User Plane (UP) of the RAN node. This first message includes: (i) information requesting indirect data forwarding, (ii) information related to the forwarding transport layer, and (iii) information requesting the allocation of a receive transport layer corresponding to the forwarding transport layer. The stored instructions also enable the CU-CP to receive a second message from the CU-UP in response to the first message. This second message includes information related to the allocated receive transport layer.

[0414] For example, the forwarding transport layer is associated with at least one PDU session and / or at least one TNL address associated with a DRB established in the target secondary node (SN).

[0415] For example, the assigned receive transport layer is associated with a CU-UP-related TNL address used for indirect data forwarding.

[0416] For example, indirect data forwarding includes (i) the transmission of data packets from the source RAN node to the CU-UP and (ii) the transmission of data packets from the CU-UP to the destination SN. For example, the transmission of data packets from the source RAN node to the CU-UP is performed based on information related to the allocated receive transport layer. For example, the transmission of data packets from the CU-UP to the destination SN is performed based on information related to the forwarding transport layer.

[0417] For example, multiple stored instructions can enable the CU-CP to send information related to the assigned receive transport layer to the source SN.

[0418] For example, information requesting indirect data forwarding is included in a special trigger destination information element (IE).

[0419] For example, information related to the forwarding transport layer is included in the data forwarding information (IE).

[0420] For example, the request to allocate information for the receiving transport layer corresponding to the forwarding transport layer is included in the data forwarding information request IE.

[0421] For example, the first message includes a context modification request message.

[0422] For example, the second message includes a context modification response message.

[0423] For example, multiple stored instructions can enable the CU-CP to receive information related to the forwarding transport layer from the target SN.

[0424] According to some embodiments of this disclosure, a non-transitory computer-readable medium has a plurality of instructions stored thereon. The plurality of instructions stored can be executed by a processor of the central unit (CU)-user plane (UP) of a radio access network (RAN) node.

[0425] The stored instructions enable the CU-UP to perform data forwarding by (i) receiving data from the source RAN node and (ii) forwarding that data to the target RAN node. The stored instructions enable the CU-UP to receive information from the source RAN node notifying the end of data forwarding. The stored instructions enable the CU-UP to send a first message to the RAN node's CU-Control Plane (CP), which includes (i) a forwarding end notification and (ii) information regarding resources used for data forwarding related to the forwarding end notification. The stored instructions enable the CU-UP to send information to the target RAN node notifying the end of data forwarding. The stored instructions enable the CU-UP to release resources used for data forwarding.

[0426] For example, multiple stored instructions can enable the CU-UP to receive a second message from the CU-CP, including a forwarding end notification response that indicates the resources used for data forwarding have been released.

[0427] For example, information notifying the end of data forwarding may include the last forwarded packet.

[0428] For example, information indicating the end of data forwarding can include an end marker.

[0429] For example, information about resources used for data forwarding may include information about one or more Transport Network Layer (TNL) addresses to be released.

[0430] For example, information about resources used for data forwarding may include at least one Protocol Data Unit (PDU) Session Identifier (ID) and / or at least one Data Radio Bearer (DRB) ID.

[0431] For example, stored instructions can enable the CU-UP to pre-assign one or more TNL addresses for data forwarding before performing data forwarding. Stored instructions can enable the CU-UP to send information to the CU-CP regarding the pre-assigned one or more TNL addresses. Stored instructions can enable the CU-UP to receive information from the CU-CP regarding at least one TNL address for data forwarding. At least one TNL address can be determined from the pre-assigned one or more TNL addresses.

[0432] For example, the RAN node can be the target primary node (MN), and the target RAN node can be the target secondary node. Multiple stored instructions can cause the CU-UP to receive a third message from the CU-CP before performing data forwarding. This third message includes (i) a data forwarding request and (ii) information regarding the resources used for data forwarding. Information regarding the resources used for data forwarding can be sent from the target RAN node. Multiple stored instructions can cause the CU-UP to assign resources for data forwarding. Multiple stored instructions can cause the CU-UP to send a fourth message to the CU-CP, which includes (i) a data forwarding response and (ii) information regarding the assigned resources used for data forwarding.

[0433] For example, data forwarding can be performed during handover (HO) and / or dual connectivity (DC) processes associated with a wireless device. For example, the wireless device can communicate with at least one of the following: user equipment, network, or autonomous vehicle, other than the wireless device itself.

[0434] In the following, a wireless device for data forwarding in a wireless network system according to some embodiments of the present disclosure will be described.

[0435] A wireless device may include a transceiver, memory, and a processor operatively coupled to the transceiver and memory. For example, a wireless device may be... Figure 2 and Figure 3 The first wireless device 100 or the second wireless device 200, or Figure 4 UE100.

[0436] The processor can be adapted to receive radio resource control (RRC) reconfiguration messages from a source radio access network (RAN) node for handover (HO) and / or dual connectivity (DC) associated with a target RAN node. The processor can also be adapted to send data from the source RAN node to be forwarded to the target RAN node.

[0437] For example, a source RAN node can send a notification of the end of data forwarding to the RAN node's Central Unit (CU)-User Plane (UP). For example, the CU-UP can send a first message to the RAN node's CU-Control Plane (CP), which includes (i) a forwarding end notification and (ii) information regarding resources used for data forwarding related to the forwarding end notification. For example, the CU-UP can send a notification of the end of data forwarding to the target RAN node. For example, the CU-UP can release resources used for data forwarding.

[0438] Hereinafter, a method for data forwarding in a wireless network system performed by a wireless device according to some embodiments of the present disclosure will be described.

[0439] The radio device can receive radio resource control (RRC) reconfiguration messages from the source radio access network (RAN) node for handover (HO) and / or dual connectivity (DC) associated with the target RAN node. The radio device can also send data from the source RAN node to be forwarded to the target RAN node.

[0440] For example, a source RAN node can send a notification of the end of data forwarding to the RAN node's Central Unit (CU) - User Plane (UP). For example, the CU-UP can send a first message to the RAN node's CU - Control Plane (CP), which includes (i) a forwarding end notification and (ii) information regarding resources used for data forwarding related to the forwarding end notification. For example, the CU-UP can send a notification of the end of data forwarding to the target RAN node. For example, the CU-UP can release resources used for data forwarding.

[0441] This disclosure can have various beneficial effects.

[0442] According to some embodiments of this disclosure, the network can efficiently support indirect data forwarding and / or direct data forwarding during handover (HO) or dual connectivity (DC).

[0443] For example, the implementations described in this disclosure enable network nodes to support indirect data forwarding during HO or DC processes when no direct path is available between the source entity and the target entity, and also enable indirect data forwarding in a central unit (CU)-user plane (UP) entity (hereinafter referred to as CU-UP) dedicated to handling all user plane functions.

[0444] For example, when there is no direct path between the source node and the destination node, network nodes can efficiently support indirect data forwarding and / or direct data forwarding during HO or DC processes.

[0445] For example, CU-UP entities can efficiently perform indirect data forwarding and / or direct data forwarding.

[0446] The beneficial effects obtainable through specific embodiments of this disclosure are not limited to those listed above. For example, various technical effects may exist that can be understood and / or derived from this disclosure by those skilled in the art. Therefore, the specific effects of this disclosure 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 disclosure.

[0447] The claims in this disclosure can be combined in various ways. For example, the technical features in the method claims of this disclosure can be combined to implement or perform in a device, and the technical features in the device claims can be combined to implement or perform in a method. Furthermore, the technical features in the method claims and device claims can be combined to implement or perform in a device. Other implementations are within the scope of the appended claims.

Claims

1. A method performed by the central unit (CU) - control plane (CP) of a radio access network (RAN) node in a wireless communication system, the method comprising the following steps: A first message is sent to the CU-User Plane UP of the RAN node, the first message including: (i) information requesting the execution of indirect data forwarding, (ii) information related to the forwarding transport layer, and (iii) information requesting the allocation of a receive transport layer corresponding to the forwarding transport layer; and In response to the first message, a second message is received from the CU-UP, the second message including information related to the allocated receive transport layer.

2. The method according to claim 1, in, The forwarding transport layer is associated with at least one PDU session and / or at least one DRB-related transport network layer (TNL) address established in the target auxiliary node (SN).

3. The method according to claim 1, in, The assigned receive transport layer is associated with the TNL address associated with the CU-UP for the indirect data forwarding.

4. The method according to claim 1, in, The indirect data forwarding includes (i) the transmission of data packets from the source RAN node to the CU-UP and (ii) the transmission of data packets from the CU-UP to the target secondary node SN.

5. The method according to claim 4, in, The transmission of data packets from the source RAN node to the CU-UP is performed based on the information associated with the allocated receive transport layer.

6. The method according to claim 4, in, The transmission of data packets from the CU-UP to the target SN is performed based on the information associated with the forwarding transport layer.

7. The method according to claim 1, wherein, The method further includes the following steps: Send the information related to the allocated receive transport layer to the source SN.

8. The method according to claim 1, in, The information requesting indirect data forwarding is included in a special triggering destination information element (IE).

9. The method according to claim 1, in, The information related to the forwarding transport layer is included in the data forwarding information (IE).

10. The method according to claim 1, in, The information requesting the allocation of the receiving transport layer corresponding to the forwarding transport layer is included in the data forwarding information request IE.

11. The method according to claim 1, in, The first message includes a bearer context modification request message.

12. The method according to claim 1, in, The second message includes a bearer context modification response message.

13. The method according to claim 1, wherein, The method further includes the following steps: Receive the information related to the forwarding transport layer from the target SN.

14. A central unit (CU)-control plane (CP) of a radio access network (RAN) node in a wireless communication system, the CU-CP comprising: transceiver; Memory; as well as At least one processor, operatively coupled to the memory and the transceiver, and the at least one processor is adapted to: Send a first message to the CU-User Plane UP of the RAN node, the first message including: (i) information requesting the execution of indirect data forwarding, (ii) information related to the forwarding transport layer, and (iii) information requesting the allocation of a receiving transport layer corresponding to the forwarding transport layer; and In response to the first message, a second message is received from the CU-UP, the second message including information related to the allocated receive transport layer.

15. The CU-CP according to claim 14, in, The forwarding transport layer is associated with at least one PDU session and / or at least one DRB-related TNL address established in the target auxiliary node SN.

16. The CU-CP according to claim 14, in, The assigned receive transport layer is associated with the TNL address associated with the CU-UP for the indirect data forwarding.

17. The CU-CP according to claim 14, in, The indirect data forwarding includes (i) the transmission of data packets from the source RAN node to the CU-UP and (ii) the transmission of data packets from the CU-UP to the target SN.

18. The CU-CP according to claim 17, in, The transmission of data packets from the source RAN node to the CU-UP is performed based on the information associated with the allocated receive transport layer.

19. The CU-CP according to claim 17, in, The transmission of data packets from the CU-UP to the target SN is performed based on the information associated with the forwarding transport layer.

20. The CU-CP according to claim 14, wherein, The at least one processor is also adapted to: Send the information related to the allocated receive transport layer to the source SN.

21. The CU-CP according to claim 14, in, The information requesting indirect data forwarding is included in a special triggering destination information element (IE).

22. The CU-CP according to claim 14, in, The information related to the forwarding transport layer is included in the data forwarding information (IE).

23. The CU-CP according to claim 14, in, The information requesting the allocation of the receiving transport layer corresponding to the forwarding transport layer is included in the data forwarding information request IE.

24. The CU-CP according to claim 14, in, The first message includes a bearer context modification request message.

25. The CU-CP according to claim 14, in, The second message includes a bearer context modification response message.

26. The CU-CP according to claim 14, wherein, The at least one processor is also adapted to: Receive the information related to the forwarding transport layer from the target SN.

27. A processor for the central unit CU-control plane CP of a radio access network RAN ​​node in a wireless communication system, wherein, The processor is configured to control the CU-CP to perform operations, including: A first message is sent to the CU-User Plane UP of the RAN node, the first message including: (i) information requesting the execution of indirect data forwarding, (ii) information related to the forwarding transport layer, and (iii) information requesting the allocation of a receive transport layer corresponding to the forwarding transport layer; and In response to the first message, a second message is received from the CU-UP, the second message including information related to the allocated receive transport layer.

28. A non-transitory computer-readable medium storing a plurality of instructions, the plurality of instructions performing operations based on execution by a processor of a central unit (CU) – control plane (CP) of a radio access network (RAN) node, the operations including: A first message is sent to the CU-User Plane UP of the RAN node, the first message including: (i) information requesting the execution of indirect data forwarding, (ii) information related to the forwarding transport layer, and (iii) information requesting the allocation of a receive transport layer corresponding to the forwarding transport layer; and In response to the first message, a second message is received from the CU-UP, the second message including information related to the allocated receive transport layer.

29. A method for a wireless device in a wireless communication system, the method comprising the steps of: Receive Radio Resource Control (RRC) reconfiguration messages related to the target primary node (MN) and target secondary node (SN) for switching HO and / or dual-connectivity DC from the source radio access network (RAN) node; as well as The data to be forwarded is sent from the source RAN node to the target SN. Specifically, the central unit (CU)-control plane (CP) of the target MN sends a first message to the CU-user plane (UP) of the target MN. The first message includes: (i) information requesting the execution of indirect data forwarding, (ii) information related to the forwarding transport layer, and (iii) information requesting the allocation of a receiving transport layer corresponding to the forwarding transport layer. The CU-CP receives a second message from the CU-UP in response to the first message, the second message including information related to the allocated receive transport layer.

30. A wireless device in a wireless communication system, the wireless device comprising: transceiver; Memory; as well as A processor, operatively coupled to the transceiver and the memory, and adapted to: Receive Radio Resource Control (RRC) reconfiguration messages related to the target primary node (MN) and target secondary node (SN) for switching HO and / or dual-connectivity DC from the source radio access network (RAN) node; as well as The data to be forwarded is sent from the source RAN node to the target SN. Specifically, the central unit (CU)-control plane (CP) of the target MN sends a first message to the CU-user plane (UP) of the target MN. The first message includes: (i) information requesting the execution of indirect data forwarding, (ii) information related to the forwarding transport layer, and (iii) information requesting the allocation of a receiving transport layer corresponding to the forwarding transport layer. The CU-CP receives a second message from the CU-UP in response to the first message, the second message including information related to the allocated receive transport layer.