Method and apparatus for support of multi hop relay ue

Abstract

A method and apparatus for support of multi-hop relay UE are provided. The method comprises: transmitting, by the CU of the RAN node to the last relay UE, a RRC reconfiguration message including information related to a local ID of the remote UE; receiving, by the CU of the RAN node from a DU of the RAN node, an uplink RRC message transfer message including an RRC setup request for the remote UE; and transmitting, by the CU of the RAN node to the DU of the RAN node, a downlink RRC message transfer message including (i) information related to the L2 ID of the remote UE and (ii) an RRC setup message.

Description

METHOD AND APPARATUS FOR SUPPORT OF MULTI HOP RELAY UE

[0001] The present disclosure relates to a method and apparatus for support of multi-hop relay UE.

[0002] 3rd generation partnership project (3GPP) long-term evolution (LTE) is a technology for enabling high-speed packet communications. Many schemes have been proposed for the LTE objective including those that aim to reduce user and provider costs, improve service quality, and expand and improve coverage and system capacity. The 3GPP LTE requires reduced cost per bit, increased service availability, flexible use of a frequency band, a simple structure, an open interface, and adequate power consumption of a terminal as an upper-level requirement.

[0003] Work has started in international telecommunication union (ITU) and 3GPP to develop requirements and specifications for new radio (NR) systems. 3GPP has to identify and develop the technology components needed for successfully standardizing the new RAT timely satisfying both the urgent market needs, and the more long-term requirements set forth by the ITU radio communication sector (ITU-R) international mobile telecommunications (IMT)-2020 process. Further, the NR should be able to use any spectrum band ranging at least up to 100 GHz that may be made available for wireless communications even in a more distant future.

[0004] The NR targets a single technical framework addressing all usage scenarios, requirements and deployment scenarios including enhanced mobile broadband (eMBB), massive machine-type-communications (mMTC), ultra-reliable and low latency communications (URLLC), etc. The NR shall be inherently forward compatible.

[0005] In NR, it was approved to proceed with a work item on additional measures to support ProSe (Proximity based Services) through Multi-hop in 5GS as follows.

[0006] Currently, in 3GPP RAN2, in a situation where all U2N Relay UEs participating in Multi-hop relay operation are in RRC_CONNECTED state (for example, Approach 1), the basic procedure to support initial access of U2N Remote UE is being discussed. Additionally, in a situation where some or all among the remaining U2N Relay UEs, excluding the U2N Relay UE located at the last hop (for example, the U2N Relay UE directly connected to the base station), are in RRC_IDLE or RRC_INACTIVE state (for example, Approach 2), the procedure to support initial access of U2N Remote UE is also being discussed.

[0007] In particular, it is in a state of conducting a discussion regarding the specification impact necessary to support Approach 2. Accordingly, in a situation where the base station is separated into gNB-CU and gNB-DU, a measure to support Approach 2 is necessary.

[0008] According to the RAN2 discussion, the base station can decide to transmit by multiplexing together the SRBs and / or DRBs of a new U2N Remote UE into the PC5 Relay RLC channel configuration allocated / configured for existing UEs (for example, Relay UE and / or Remote UE). In a situation where the base station is separated into gNB-CU and gNB-DU, if the gNB-CU decides to multiplex the SRBs and / or DRBs of the new U2N Remote UE into the existing PC5 Relay RLC channel configuration, a method is necessary for the gNB-CU to inform information about the UE (for example, Remote UE and / or Relay UE) that will together use / utilize the existing PC5 Relay RLC channel configuration instead of requesting the allocation / configuration of a new PC5 Relay RLC channel configuration within the UE CONTEXT MODIFICATION REQUEST message.

[0009] In addition, a discussion has been conducted regarding the specification impact necessary to support Fast / Parallel RRC Setup. Therefore, in a situation where Fast / Parallel RRC Setup is applied, a method is necessary to inform the gNB-DU of the situation where the gNB-CU decided to multiplex the SRBs and / or DRBs of the new U2N Remote UE into the existing PC5 Relay RLC channel configuration.

[0010] Therefore, studies for support of multi-hop relay UE are required.

[0011] In an aspect, a method is provided. The method comprises: receiving, by a central unit (CU) of a radio access network (RAN) node from a last relay User Equipment (UE), UE information related to a inter-UE link including (i) information related to a Layer-2 identity (L2 ID) of a remote UE and (ii) information related to the last relay UE; transmitting, by the CU of the RAN node to the last relay UE, a radio resource control (RRC) reconfiguration message including information related to a local ID of the remote UE; receiving, by the CU of the RAN node from a distributed unit (DU) of the RAN node, an uplink RRC message transfer message including an RRC setup request for the remote UE; and transmitting, by the CU of the RAN node to the DU of the RAN node, a downlink RRC message transfer message including (i) information related to the L2 ID of the remote UE and (ii) an RRC setup message.

[0012] In another aspect, an apparatus for implementing the above method is provided.

[0013] The present disclosure can have various advantageous effects.

[0014] According to some embodiments of the present disclosure, the radio access network (RAN) node could efficiently support the multi-hop relay UE and the remote UE.

[0015] For example, the SRAP header can be configured by considering idle / inactive relay UEs. Even if there are idle / inactive relay UEs, a CU / DU split RAN node can efficiently establish an RRC connection with the remote UE.

[0016] For example, in a Multi-hop U2N relaying scenario, by providing mapping information for the L2 ID and Local ID of the U2N Remote UE to U2N Relay UEs in RRC_IDLE or RRC_INACTIVE state, it allows the U2N Relay UE to deliver DL signaling and / or data coming from the base station to the U2N Remote UE.

[0017] Alternatively, in the case where a U2N Relay UE in RRC_IDLE or RRC_INACTIVE state transitions to RRC_CONNECTED state, because the base station can configure / allocate the PC5 Relay RLC channel for the PC5 connection related to the U2N Relay UE for UL / DL data transmission of the U2N Remote UEs connected through the U2N Relay UE, it can provide better performance to the U2N Remote UE.

[0018] Alternatively, in the case where the U2N Remote UE transitions to RRC_IDLE or RRC_INACTIVE state, because the base station can delete the Local ID-related information allocated for the U2N Remote UE from the U2N Relay UEs in RRC_IDLE or RRC_INACTIVE state, it can avoid a situation where different U2N Remote UEs use the same Local ID.

[0019] For example, in a multi-hop U2N relaying scenario, the gNB-DU becomes able to know the fact that the gNB-CU has allocated / configured the SRBs and / or DRBs of the U2N Remote UE to an existing PC5 Relay RLC channel, so PC5 Relay RLC channel resources can be efficiently managed.

[0020] In addition, it becomes able to receive local ID information regarding the Remote UE even in the situation, so the gNB-DU can identify the UE that sent the RRCSetupRequest message during the RRC Setup process.

[0021] Therefore, when the gNB-DU allocates / configures the PC5 Relay RLC channel configuration for SRB1 message transmission and includes it in the INITIAL UL RRC MESSAGE TRANSFER message, it can identify the counterpart of the corresponding PC5 Relay RLC channel in advance, so it is possible to avoid the gNB-DU allocating / configuring an incorrect PC5 Relay RLC channel.

[0022] Advantageous effects which can be obtained through specific embodiments of the present disclosure are not limited to the advantageous effects listed above. For example, there may be a variety of technical effects that a person having ordinary skill in the related art can understand and / or derive from the present disclosure. Accordingly, the specific effects of the present disclosure are not limited to those explicitly described herein, but may include various effects that may be understood or derived from the technical features of the present disclosure.

[0023] FIG. 1 shows an example of a communication system to which implementations of the present disclosure is applied.

[0024] FIG. 2 shows an example of wireless devices to which implementations of the present disclosure is applied.

[0025] FIG. 3 shows an example of a wireless device to which implementations of the present disclosure is applied.

[0026] FIG. 4 shows an example of UE to which implementations of the present disclosure is applied.

[0027] FIGS. 5 and 6 show an example of protocol stacks in a 3GPP based wireless communication system to which implementations of the present disclosure is applied.

[0028] FIG. 7 shows an example of the overall architecture of an NG-RAN to which technical features of the present disclosure can be applied.

[0029] FIG. 8 shows an interface protocol structure for F1-C to which technical features of the present disclosure can be applied.

[0030] FIG. 9a, FIG. 9b, and FIG. 9c show an example of Remote UE Initial Access procedure, to which technical features of the present disclosure can be applied.

[0031] FIG. 10a and FIG. 10b show an example of Remote UE RRC Resume procedure, to which technical features of the present disclosure can be applied.

[0032] FIG. 11 shows an example of a method for support of multi-hop relay UE, according to some embodiments of the present disclosure.

[0033] FIG. 12a and FIG. 12b show an example of a method for support of multi-hop relay UE, according to some embodiments of the present disclosure.

[0034] FIG. 13 shows an example of an SRAP PDU Format, according to some embodiments of the present disclosure.

[0035] FIG. 14 shows an example of an SRAP PDU Format, according to some embodiments of the present disclosure.

[0036] FIG. 15 shows an example of an SRAP PDU Format, according to some embodiments of the present disclosure.

[0037] FIG. 16a and FIG. 16b show an example of a method for support of multi-hop relay UE, according to some embodiments of the present disclosure.

[0038] FIG. 17a, FIG. 17b, and FIG. 17c show an example of a method for F1 support of multi-hop relay UE, according to some embodiments of the present disclosure.

[0039] FIG. 18 shows an example of user plane protocol stack for single-hop L2 UE-to-Network Relay.

[0040] FIG. 19 shows an example of control plane protocol stack for single-hop L2 UE-to-Network Relay.

[0041] FIG. 20 shows an example of user plane protocol stack for multi-hop L2 UE-to-Network Relay.

[0042] FIG. 21 shows an example of control plane protocol stack for multi-hop L2 UE-to-Network Relay.

[0043] FIG. 22 shows an example of coexistence of single hop relay operation and multi-hop relay operation.

[0044] FIG. 23a and FIG. 23b show an example of overall procedure for Fast / Parallel RRC Setup.

[0045] The following techniques, apparatuses, and systems may be applied to a variety of wireless multiple access systems. Examples of the multiple access systems include a code division multiple access (CDMA) system, a frequency division multiple access (FDMA) system, a time division multiple access (TDMA) system, an orthogonal frequency division multiple access (OFDMA) system, a single carrier frequency division multiple access (SC-FDMA) system, and a multicarrier frequency division multiple access (MC-FDMA) system. CDMA may be embodied through radio technology such as universal terrestrial radio access (UTRA) or CDMA2000. TDMA may be embodied through radio technology such as global system for mobile communications (GSM), general packet radio service (GPRS), or enhanced data rates for GSM evolution (EDGE). OFDMA may be embodied through radio technology such as institute of electrical and electronics engineers (IEEE) 802.11 (Wi-Fi), IEEE 802.16 (WiMAX), IEEE 802.20, or evolved UTRA (E-UTRA). UTRA is a part of a universal mobile telecommunications system (UMTS). 3rd generation partnership project (3GPP) long term evolution (LTE) is a part of evolved UMTS (E-UMTS) using E-UTRA. 3GPP LTE employs OFDMA in DL and SC-FDMA in UL. Evolution of 3GPP LTE includes LTE-A (advanced), LTE-A Pro, and / or 5G NR (new radio).

[0046] For convenience of description, implementations of the present disclosure are mainly described in regards to a 3GPP based wireless communication system. However, the technical features of the present disclosure are not limited thereto. For example, although the following detailed description is given based on a mobile communication system corresponding to a 3GPP based wireless communication system, aspects of the present disclosure that are not limited to 3GPP based wireless communication system are applicable to other mobile communication systems.

[0047] For terms and technologies which are not specifically described among the terms of and technologies employed in the present disclosure, the wireless communication standard documents published before the present disclosure may be referenced.

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

[0049] In the present disclosure, slash ( / ) or comma (,) may mean "and / or". For example, "A / B" may mean "A and / or B". Accordingly, "A / B" may mean "only A", "only B", or "both A and B". For example, "A, B, C" may mean "A, B or C".

[0050] In the present disclosure, "at least one of A and B" may mean "only A", "only B" or "both A and B". In addition, the expression "at least one of A or B" or "at least one of A and / or B" in the present disclosure may be interpreted as same as "at least one of A and B".

[0051] In addition, in the present disclosure, "at least one of A, B and C" may mean "only A", "only B", "only C", or "any combination of A, B and C". In addition, "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".

[0052] Also, parentheses used in the present disclosure may mean "for example". In detail, when it is shown as "control information (PDCCH)", "PDCCH" may be proposed as an example of "control information". In other words, "control information" in the present disclosure is not limited to "PDCCH" and "PDCCH" may be proposed as an example of "control information". In addition, even when shown as "control information (for example, PDCCH)", "PDCCH" may be proposed as an example of "control information".

[0053] Technical features that are separately described in one drawing in the present disclosure may be implemented separately or simultaneously.

[0054] Although not limited thereto, various descriptions, functions, procedures, suggestions, methods and / or operational flowcharts of the present disclosure disclosed herein can be applied to various fields requiring wireless communication and / or connection (e.g., 5G) between devices.

[0055] Hereinafter, the present disclosure will be described in more detail with reference to drawings. The same reference numerals in the following drawings and / or descriptions may refer to the same and / or corresponding hardware blocks, software blocks, and / or functional blocks unless otherwise indicated.

[0056] FIG. 1 shows an example of a communication system to which implementations of the present disclosure is applied.

[0057] The 5G usage scenarios shown in FIG. 1 are only exemplary, and the technical features of the present disclosure can be applied to other 5G usage scenarios which are not shown in FIG. 1.

[0058] Three main requirement categories for 5G include (1) a category of enhanced mobile broadband (eMBB), (2) a category of massive machine type communication (mMTC), and (3) a category of ultra-reliable and low latency communications (URLLC).

[0059] Partial use cases may require a plurality of categories for optimization and other use cases may focus only upon one key performance indicator (KPI). 5G supports such various use cases using a flexible and reliable method.

[0060] eMBB far surpasses basic mobile Internet access and covers abundant bidirectional work and media and entertainment applications in cloud and augmented reality. Data is one of 5G core motive forces and, in a 5G era, a dedicated voice service may not be provided for the first time. In 5G, it is expected that voice will be simply processed as an application program using data connection provided by a communication system. Main causes for increased traffic volume are due to an increase in the size of content and an increase in the number of applications requiring high data transmission rate. A streaming service (of audio and video), conversational video, and mobile Internet access will be more widely used as more devices are connected to the Internet. These many application programs require connectivity of an always turned-on state in order to push real-time information and alarm for users. Cloud storage and applications are rapidly increasing in a mobile communication platform and may be applied to both work and entertainment. The cloud storage is a special use case which accelerates growth of uplink data transmission rate. 5G is also used for remote work of cloud. When a tactile interface is used, 5G demands much lower end-to-end latency to maintain user good experience. Entertainment, for example, cloud gaming and video streaming, is another core element which increases demand for mobile broadband capability. Entertainment is essential for a smartphone and a tablet in any place including high mobility environments such as a train, a vehicle, and an airplane. Other use cases are augmented reality for entertainment and information search. In this case, the augmented reality requires very low latency and instantaneous data volume.

[0061] In addition, one of the most expected 5G use cases relates a function capable of smoothly connecting embedded sensors in all fields, for example, mMTC. It is expected that the number of potential Internet-of-things (IoT) devices will reach 204 hundred million up to the year of 2020. An industrial IoT is one of categories of performing a main role enabling a smart city, asset tracking, smart utility, agriculture, and security infrastructure through 5G.

[0062] URLLC includes a new service that will change industry through remote control of main infrastructure and an ultra-reliable / available low-latency link such as a self-driving vehicle. A level of reliability and latency is essential to control a smart grid, automatize industry, achieve robotics, and control and adjust a drone.

[0063] 5G is a means of providing streaming evaluated as a few hundred megabits per second to gigabits per second and may complement fiber-to-the-home (FTTH) and cable-based broadband (or DOCSIS). Such fast speed is needed to deliver TV in resolution of 4K or more (6K, 8K, and more), as well as virtual reality and augmented reality. Virtual reality (VR) and augmented reality (AR) applications include almost immersive sports games. A specific application program may require a special network configuration. For example, for VR games, gaming companies need to incorporate a core server into an edge network server of a network operator in order to minimize latency.

[0064] Automotive is expected to be a new important motivated force in 5G together with many use cases for mobile communication for vehicles. For example, entertainment for passengers requires high simultaneous capacity and mobile broadband with high mobility. This is because future users continue to expect connection of high quality regardless of their locations and speeds. Another use case of an automotive field is an AR dashboard. The AR dashboard causes a driver to identify an object in the dark in addition to an object seen from a front window and displays a distance from the object and a movement of the object by overlapping information talking to the driver. In the future, a wireless module enables communication between vehicles, information exchange between a vehicle and supporting infrastructure, and information exchange between a vehicle and other connected devices (e.g., devices accompanied by a pedestrian). A safety system guides alternative courses of a behavior so that a driver may drive more safely drive, thereby lowering the danger of an accident. The next stage will be a remotely controlled or self-driven vehicle. This requires very high reliability and very fast communication between different self-driven vehicles and between a vehicle and infrastructure. In the future, a self-driven vehicle will perform all driving activities and a driver will focus only upon abnormal traffic that the vehicle cannot identify. Technical requirements of a self-driven vehicle demand ultra-low latency and ultra-high reliability so that traffic safety is increased to a level that cannot be achieved by human being.

[0065] A smart city and a smart home / building mentioned as a smart society will be embedded in a high-density wireless sensor network. A distributed network of an intelligent sensor will identify conditions for costs and energy-efficient maintenance of a city or a home. Similar configurations may be performed for respective households. All of temperature sensors, window and heating controllers, burglar alarms, and home appliances are wirelessly connected. Many of these sensors are typically low in data transmission rate, power, and cost. However, real-time HD video may be demanded by a specific type of device to perform monitoring.

[0066] Consumption and distribution of energy including heat or gas is distributed at a higher level so that automated control of the distribution sensor network is demanded. The smart grid collects information and connects the sensors to each other using digital information and communication technology so as to act according to the collected information. Since this information may include behaviors of a supply company and a consumer, the smart grid may improve distribution of fuels such as electricity by a method having efficiency, reliability, economic feasibility, production sustainability, and automation. The smart grid may also be regarded as another sensor network having low latency.

[0067] Mission critical application (e.g., e-health) is one of 5G use scenarios. A health part contains many application programs capable of enjoying benefit of mobile communication. A communication system may support remote treatment that provides clinical treatment in a faraway place. Remote treatment may aid in reducing a barrier against distance and improve access to medical services that cannot be continuously available in a faraway rural area. Remote treatment is also used to perform important treatment and save lives in an emergency situation. The wireless sensor network based on mobile communication may provide remote monitoring and sensors for parameters such as heart rate and blood pressure.

[0068] Wireless and mobile communication gradually becomes important in the field of an industrial application. Wiring is high in installation and maintenance cost. Therefore, a possibility of replacing a cable with reconstructible wireless links is an attractive opportunity in many industrial fields. However, in order to achieve this replacement, it is necessary for wireless connection to be established with latency, reliability, and capacity similar to those of the cable and management of wireless connection needs to be simplified. Low latency and a very low error probability are new requirements when connection to 5G is needed.

[0069] Logistics and freight tracking are important use cases for mobile communication that enables inventory and package tracking anywhere using a location-based information system. The use cases of logistics and freight typically demand low data rate but require location information with a wide range and reliability.

[0070] Referring to FIG. 1, the communication system 1 includes wireless devices 100a to 100f, base stations (BSs) 200, and a network 300. Although FIG. 1 illustrates a 5G network as an example of the network of the communication system 1, the implementations of the present disclosure are not limited to the 5G system, and can be applied to the future communication system beyond the 5G system.

[0071] The BSs 200 and the network 300 may be implemented as wireless devices and a specific wireless device may operate as a BS / network node with respect to other wireless devices.

[0072] The wireless devices 100a to 100f represent devices performing communication using radio access technology (RAT) (e.g., 5G new RAT (NR)) or LTE) and may be referred to as communication / radio / 5G devices. The wireless devices 100a to 100f may include, without being limited to, a robot 100a, vehicles 100b-1 and 100b-2, an extended reality (XR) device 100c, a hand-held device 100d, a home appliance 100e, an IoT device 100f, and an artificial intelligence (AI) device / server 400. For example, the vehicles may include a vehicle having a wireless communication function, an autonomous driving vehicle, and a vehicle capable of performing communication between vehicles. The vehicles may include an unmanned aerial vehicle (UAV) (e.g., a drone). The XR device may include an AR / VR / Mixed Reality (MR) device and may be implemented in the form of a head-mounted device (HMD), a head-up display (HUD) mounted in a vehicle, a television, a smartphone, a computer, a wearable device, a home appliance device, a digital signage, a vehicle, a robot, etc. The hand-held device may include a smartphone, a smartpad, a wearable device (e.g., a smartwatch or a smartglasses), and a computer (e.g., a notebook). The home appliance may include a TV, a refrigerator, and a washing machine. The IoT device may include a sensor and a smartmeter.

[0073] In the present disclosure, the wireless devices 100a to 100f may be called user equipments (UEs). A UE may include, for example, a cellular phone, a smartphone, a laptop computer, a digital broadcast terminal, a personal digital assistant (PDA), a portable multimedia player (PMP), a navigation system, a slate personal computer (PC), a tablet PC, an ultrabook, a vehicle, a vehicle having an autonomous traveling function, a connected car, an UAV, an AI module, a robot, an AR device, a VR device, an MR device, a hologram device, a public safety device, an MTC device, an IoT device, a medical device, a FinTech device (or a financial device), a security device, a weather / environment device, a device related to a 5G service, or a device related to a fourth industrial revolution field.

[0074] The UAV may be, for example, an aircraft aviated by a wireless control signal without a human being onboard.

[0075] The VR device may include, for example, a device for implementing an object or a background of the virtual world. The AR device may include, for example, a device implemented by connecting an object or a background of the virtual world to an object or a background of the real world. The MR device may include, for example, a device implemented by merging an object or a background of the virtual world into an object or a background of the real world. The hologram device may include, for example, a device for implementing a stereoscopic image of 360 degrees by recording and reproducing stereoscopic information, using an interference phenomenon of light generated when two laser lights called holography meet.

[0076] The public safety device may include, for example, an image relay device or an image device that is wearable on the body of a user.

[0077] The MTC device and the IoT device may be, for example, devices that do not require direct human intervention or manipulation. For example, the MTC device and the IoT device may include smartmeters, vending machines, thermometers, smartbulbs, door locks, or various sensors.

[0078] The medical device may be, for example, a device used for the purpose of diagnosing, treating, relieving, curing, or preventing disease. For example, the medical device may be a device used for the purpose of diagnosing, treating, relieving, or correcting injury or impairment. For example, the medical device may be a device used for the purpose of inspecting, replacing, or modifying a structure or a function. For example, the medical device may be a device used for the purpose of adjusting pregnancy. For example, the medical device may include a device for treatment, a device for operation, a device for (in vitro) diagnosis, a hearing aid, or a device for procedure.

[0079] The security device may be, for example, a device installed to prevent a danger that may arise and to maintain safety. For example, the security device may be a camera, a closed-circuit TV (CCTV), a recorder, or a black box.

[0080] The FinTech device may be, for example, a device capable of providing a financial service such as mobile payment. For example, the FinTech device may include a payment device or a point of sales (POS) system.

[0081] The weather / environment device may include, for example, a device for monitoring or predicting a weather / environment.

[0082] The wireless devices 100a to 100f may be connected to the network 300 via the BSs 200. An AI technology may be applied to the wireless devices 100a to 100f and the wireless devices 100a to 100f may be connected to the AI server 400 via the network 300. The network 300 may be configured using a 3G network, a 4G (e.g., LTE) network, a 5G (e.g., NR) network, and a beyond-5G network. Although the wireless devices 100a to 100f may communicate with each other through the BSs 200 / network 300, the wireless devices 100a to 100f may perform direct communication (e.g., sidelink communication) with each other without passing through the BSs 200 / network 300. For example, the vehicles 100b-1 and 100b-2 may perform direct communication (e.g., vehicle-to-vehicle (V2V) / vehicle-to-everything (V2X) communication). The IoT device (e.g., a sensor) may perform direct communication with other IoT devices (e.g., sensors) or other wireless devices 100a to 100f.

[0083] Wireless communication / connections 150a, 150b and 150c may be established between the wireless devices 100a to 100f and / or between wireless device 100a to 100f and BS 200 and / or between BSs 200. Herein, the wireless communication / connections may be established through various RATs (e.g., 5G NR) such as uplink / downlink communication 150a, sidelink communication (or device-to-device (D2D) communication) 150b, inter-base station communication 150c (e.g., relay, integrated access and backhaul (IAB)), etc. The wireless devices 100a to 100f and the BSs 200 / the wireless devices 100a to 100f may transmit / receive radio signals to / from each other through the wireless communication / connections 150a, 150b and 150c. For example, the wireless communication / connections 150a, 150b and 150c may transmit / receive signals through various physical channels. To this end, at least a part of various configuration information configuring processes, various signal processing processes (e.g., channel encoding / decoding, modulation / demodulation, and resource mapping / de-mapping), and resource allocating processes, for transmitting / receiving radio signals, may be performed based on the various proposals of the present disclosure.

[0084] AI refers to the field of studying artificial intelligence or the methodology that can create it, and machine learning refers to the field of defining various problems addressed in the field of AI and the field of methodology to solve them. Machine learning is also defined as an algorithm that increases the performance of a task through steady experience on a task.

[0085] Robot means a machine that automatically processes or operates a given task by its own ability. In particular, robots with the ability to recognize the environment and make self-determination to perform actions can be called intelligent robots. Robots can be classified as industrial, medical, home, military, etc., depending on the purpose or area of use. The robot can perform a variety of physical operations, such as moving the robot joints with actuators or motors. The movable robot also includes wheels, brakes, propellers, etc., on the drive, allowing it to drive on the ground or fly in the air.

[0086] Autonomous driving means a technology that drives on its own, and autonomous vehicles mean vehicles that drive without user's control or with minimal user's control. For example, autonomous driving may include maintaining lanes in motion, automatically adjusting speed such as adaptive cruise control, automatic driving along a set route, and automatically setting a route when a destination is set. The vehicle covers vehicles equipped with internal combustion engines, hybrid vehicles equipped with internal combustion engines and electric motors, and electric vehicles equipped with electric motors, and may include trains, motorcycles, etc., as well as cars. Autonomous vehicles can be seen as robots with autonomous driving functions.

[0087] Extended reality is collectively referred to as VR, AR, and MR. VR technology provides objects and backgrounds of real world only through computer graphic (CG) images. AR technology provides a virtual CG image on top of a real object image. MR technology is a CG technology that combines and combines virtual objects into the real world. MR technology is similar to AR technology in that they show real and virtual objects together. However, there is a difference in that in AR technology, virtual objects are used as complementary forms to real objects, while in MR technology, virtual objects and real objects are used as equal personalities.

[0088] NR supports multiples numerologies (and / or multiple subcarrier spacings (SCS)) to support various 5G services. For example, if SCS is 15 kHz, wide area can be supported in traditional cellular bands, and if SCS is 30 kHz / 60 kHz, dense-urban, lower latency, and wider carrier bandwidth can be supported. If SCS is 60 kHz or higher, bandwidths greater than 24.25 GHz can be supported to overcome phase noise.

[0089] The NR frequency band may be defined as two types of frequency range, for example, FR1 and FR2. The numerical value of the frequency range may be changed. For example, the frequency ranges of the two types (FR1 and FR2) may be as shown in Table 1 below. For ease of explanation, in the frequency ranges used in the NR system, FR1 may mean "sub 6 GHz range", FR2 may mean "above 6 GHz range," and may be referred to as millimeter wave (mmW).

[0090] Frequency Range designationCorresponding frequency rangeSubcarrier SpacingFR1450MHz - 6000MHz15, 30, 60kHzFR224250MHz - 52600MHz60, 120, 240kHz

[0091] As mentioned above, the numerical value of the frequency range of the NR system may be changed. For example, FR1 may include a frequency band of 410MHz to 7125MHz as shown in Table 2 below. For example, FR1 may include a frequency band of 6GHz (or 5850, 5900, 5925 MHz, etc.) or more. For example, a frequency band of 6 GHz (or 5850, 5900, 5925 MHz, etc.) or more included in FR1 may include an unlicensed band. Unlicensed bands may be used for a variety of purposes, for example for communication for vehicles (e.g., autonomous driving).

[0092] Frequency Range designationCorresponding frequency rangeSubcarrier SpacingFR1410MHz - 7125MHz15, 30, 60kHzFR224250MHz - 52600MHz60, 120, 240kHz

[0093] Here, the radio communication technologies implemented in the wireless devices in the present disclosure may include narrowband internet-of-things (NB-IoT) technology 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, may be implemented in specifications such as LTE Cat NB1 and / or LTE Cat NB2, and may not be limited to the above-mentioned names. Additionally and / or alternatively, the radio communication technologies implemented in the wireless devices in the present disclosure may communicate based on LTE-M technology. For example, LTE-M technology may be an example of LPWAN technology and be called by various names such as enhanced machine type communication (eMTC). For example, LTE-M technology may be implemented in at least one of the 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 above-mentioned names. Additionally and / or alternatively, the radio communication technologies implemented in the wireless devices in the present 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 above-mentioned names. 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 called various names.

[0094] FIG. 2 shows an example of wireless devices to which implementations of the present disclosure is applied.

[0095] Referring to FIG. 2, a first wireless device 100 and a second wireless device 200 may transmit / receive radio signals to / from an external device through a variety of RATs (e.g., LTE and NR).

[0096] In FIG. 2, {the first wireless device 100 and the second wireless device 200} may correspond to at least one of {the wireless device 100a to 100f and the BS 200}, {the wireless device 100a to 100f and the wireless device 100a to 100f} and / or {the BS 200 and the BS 200} of FIG. 1.

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

[0098] The processing chip 101 may include at least one processor, such a processor 102, and at least one memory, such as a memory 104. It is exemplarily shown in FIG. 2 that the memory 104 is included in the processing chip 101. Additional and / or alternatively, the memory 104 may be placed outside of the processing chip 101.

[0099] The processor 102 may control the memory 104 and / or the transceiver 106 and may be configured to implement the descriptions, functions, procedures, suggestions, methods and / or operational flowcharts described in the present disclosure. For example, the processor 102 may process information within the memory 104 to generate first information / signals and then transmit radio signals including the first information / signals through the transceiver 106. The processor 102 may receive radio signals including second information / signals through the transceiver 106 and then store information obtained by processing the second information / signals in the memory 104.

[0100] The memory 104 may be operably connectable to the processor 102. The memory 104 may store various types of information and / or instructions. The memory 104 may store a software code 105 which implements instructions that, when executed by the processor 102, perform the descriptions, functions, procedures, suggestions, methods and / or operational flowcharts disclosed in the present disclosure. For example, the software code 105 may implement instructions that, when executed by the processor 102, perform the descriptions, functions, procedures, suggestions, methods and / or operational flowcharts disclosed in the present disclosure. For example, the software code 105 may control the processor 102 to perform one or more protocols. For example, the software code 105 may control the processor 102 to perform one or more layers of the radio interface protocol.

[0101] Herein, the processor 102 and the memory 104 may be a part of a communication modem / circuit / chip designed to implement RAT (e.g., LTE or NR). The transceiver 106 may be connected to the processor 102 and transmit and / or receive radio signals through one or more antennas 108. Each of the transceiver 106 may include a transmitter and / or a receiver. The transceiver 106 may be interchangeably used with radio frequency (RF) unit(s). In the present disclosure, the first wireless device 100 may represent a communication modem / circuit / chip.

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

[0103] The processing chip 201 may include at least one processor, such a processor 202, and at least one memory, such as a memory 204. It is exemplarily shown in FIG. 2 that the memory 204 is included in the processing chip 201. Additional and / or alternatively, the memory 204 may be placed outside of the processing chip 201.

[0104] The processor 202 may control the memory 204 and / or the transceiver 206 and may be configured to implement the descriptions, functions, procedures, suggestions, methods and / or operational flowcharts described in the present disclosure. For example, the processor 202 may process information within the memory 204 to generate third information / signals and then transmit radio signals including the third information / signals through the transceiver 206. The processor 202 may receive radio signals including fourth information / signals through the transceiver 106 and then store information obtained by processing the fourth information / signals in the memory 204.

[0105] The memory 204 may be operably connectable to the processor 202. The memory 204 may store various types of information and / or instructions. The memory 204 may store a software code 205 which implements instructions that, when executed by the processor 202, perform the descriptions, functions, procedures, suggestions, methods and / or operational flowcharts disclosed in the present disclosure. For example, the software code 205 may implement instructions that, when executed by the processor 202, perform the descriptions, functions, procedures, suggestions, methods and / or operational flowcharts disclosed in the present disclosure. For example, the software code 205 may control the processor 202 to perform one or more protocols. For example, the software code 205 may control the processor 202 to perform one or more layers of the radio interface protocol.

[0106] Herein, the processor 202 and the memory 204 may be a part of a communication modem / circuit / chip designed to implement RAT (e.g., LTE or NR). The transceiver 206 may be connected to the processor 202 and transmit and / or receive radio signals through one or more antennas 208. Each of the transceiver 206 may include a transmitter and / or a receiver. The transceiver 206 may be interchangeably used with RF unit. In the present disclosure, the second wireless device 200 may represent a communication modem / circuit / chip.

[0107] Hereinafter, hardware elements of the wireless devices 100 and 200 will be described more specifically. One or more protocol layers may be implemented by, without being limited to, one or more processors 102 and 202. For example, the one or more processors 102 and 202 may implement one or more layers (e.g., functional layers such as physical (PHY) layer, media access control (MAC) layer, radio link control (RLC) layer, packet data convergence protocol (PDCP) layer, radio resource control (RRC) layer, and service data adaptation protocol (SDAP) layer). The one or more processors 102 and 202 may generate one or more protocol data units (PDUs) and / or one or more service data unit (SDUs) according to the descriptions, functions, procedures, suggestions, methods and / or operational flowcharts disclosed in the present disclosure. The one or more processors 102 and 202 may generate messages, control information, data, or information according to the descriptions, functions, procedures, suggestions, methods and / or operational flowcharts disclosed in the present disclosure. The one or more processors 102 and 202 may generate signals (e.g., baseband signals) including PDUs, SDUs, messages, control information, data, or information according to the descriptions, functions, procedures, suggestions, methods and / or operational flowcharts disclosed in the present disclosure and provide the generated signals to the one or more transceivers 106 and 206. The one or more processors 102 and 202 may receive the signals (e.g., baseband signals) from the one or more transceivers 106 and 206 and acquire the PDUs, SDUs, messages, control information, data, or information according to the descriptions, functions, procedures, suggestions, methods and / or operational flowcharts disclosed in the present disclosure.

[0108] The one or more processors 102 and 202 may be referred to as controllers, microcontrollers, microprocessors, or microcomputers. The 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 the one or more processors 102 and 202. The descriptions, functions, procedures, suggestions, methods and / or operational flowcharts disclosed in the present disclosure may be implemented using firmware or software and the firmware or software may be configured to include the modules, procedures, or functions. Firmware or software configured to perform the descriptions, functions, procedures, suggestions, methods and / or operational flowcharts disclosed in the present disclosure may be included in the one or more processors 102 and 202 or stored in the one or more memories 104 and 204 so as to be driven by the one or more processors 102 and 202. The descriptions, functions, procedures, suggestions, methods and / or operational flowcharts disclosed in the present disclosure may be implemented using firmware or software in the form of code, commands, and / or a set of commands.

[0109] The one or more memories 104 and 204 may be connected to the one or more processors 102 and 202 and store various types of data, signals, messages, information, programs, code, instructions, and / or commands. The one or more memories 104 and 204 may be configured by read-only memories (ROMs), random access memories (RAMs), electrically erasable programmable read-only memories (EPROMs), flash memories, hard drives, registers, cash memories, computer-readable storage media, and / or combinations thereof. The one or more memories 104 and 204 may be located at the interior and / or exterior of the one or more processors 102 and 202. The one or more memories 104 and 204 may be connected to the one or more processors 102 and 202 through various technologies such as wired or wireless connection.

[0110] The one or more transceivers 106 and 206 may transmit user data, control information, and / or radio signals / channels, mentioned in the descriptions, functions, procedures, suggestions, methods and / or operational flowcharts disclosed in the present disclosure, to one or more other devices. The one or more transceivers 106 and 206 may receive user data, control information, and / or radio signals / channels, mentioned in the descriptions, functions, procedures, suggestions, methods and / or operational flowcharts disclosed in the present disclosure, from one or more other devices. For example, the one or more transceivers 106 and 206 may be connected to the one or more processors 102 and 202 and transmit and receive radio signals. For example, the one or more processors 102 and 202 may perform control so that the one or more transceivers 106 and 206 may transmit user data, control information, or radio signals to one or more other devices. The one or more processors 102 and 202 may perform control so that the one or more transceivers 106 and 206 may receive user data, control information, or radio signals from one or more other devices.

[0111] The one or more transceivers 106 and 206 may be connected to the one or more antennas 108 and 208 and the 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, procedures, suggestions, methods and / or operational flowcharts disclosed in the present disclosure, through the one or more antennas 108 and 208. In the present disclosure, the one or more antennas 108 and 208 may be a plurality of physical antennas or a plurality of logical antennas (e.g., antenna ports).

[0112] The one or more transceivers 106 and 206 may convert received user data, control information, radio signals / channels, etc., from RF band signals into baseband signals in order to process received user data, control information, radio signals / channels, etc., using the one or more processors 102 and 202. The one or more transceivers 106 and 206 may convert the user data, control information, radio signals / channels, etc., processed using the one or more processors 102 and 202 from the base band signals into the RF band signals. To this end, the one or more transceivers 106 and 206 may include (analog) oscillators and / or filters. For example, the one or more transceivers 106 and 206 can up-convert OFDM baseband signals to OFDM signals by their (analog) oscillators and / or filters under the control of the one or more processors 102 and 202 and transmit the up-converted OFDM signals at the carrier frequency. The one or more transceivers 106 and 206 may receive OFDM signals at a carrier frequency and down-convert the OFDM signals into OFDM baseband signals by their (analog) oscillators and / or filters under the control of the one or more processors 102 and 202.

[0113] In the implementations of the present disclosure, a UE may operate as a transmitting device in uplink (UL) and as a receiving device in downlink (DL). In the implementations of the present disclosure, a BS may operate as a receiving device in UL and as a transmitting device in DL. Hereinafter, for convenience of description, it is mainly assumed that the first wireless device 100 acts as the UE, and the second wireless device 200 acts as the BS. For example, the processor(s) 102 connected to, mounted on or launched in the first wireless device 100 may be configured to perform the UE behavior according to an implementation of the present disclosure or control the transceiver(s) 106 to perform the UE behavior according to an implementation of the present disclosure. The processor(s) 202 connected to, mounted on or launched in the second wireless device 200 may be configured to perform the BS behavior according to an implementation of the present disclosure or control the transceiver(s) 206 to perform the BS behavior according to an implementation of the present disclosure.

[0114] In the present disclosure, a BS is also referred to as a node B (NB), an eNode B (eNB), or a gNB.

[0115] FIG. 3 shows an example of a wireless device to which implementations of the present disclosure is applied.

[0116] The wireless device may be implemented in various forms according to a use-case / service (refer to FIG. 1).

[0117] Referring to FIG. 3, wireless devices 100 and 200 may correspond to the wireless devices 100 and 200 of FIG. 2 and may be configured by various elements, components, units / portions, 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 additional components 140. The communication unit 110 may include a communication circuit 112 and transceiver(s) 114. For example, the communication circuit 112 may include the one or more processors 102 and 202 of FIG. 2 and / or the one or more memories 104 and 204 of FIG. 2. For example, the transceiver(s) 114 may include the one or more transceivers 106 and 206 of FIG. 2 and / or the one or more antennas 108 and 208 of FIG. 2. The control unit 120 is electrically connected to the communication unit 110, the memory unit 130, and the additional components 140 and controls overall operation of each of the wireless devices 100 and 200. For example, the control unit 120 may control an electric / mechanical operation of each of the wireless devices 100 and 200 based on programs / code / commands / information stored in the memory unit 130. The control unit 120 may transmit the information stored in the memory unit 130 to the exterior (e.g., other communication devices) via the communication unit 110 through a wireless / wired interface or store, in the memory unit 130, information received through the wireless / wired interface from the exterior (e.g., other communication devices) via the communication unit 110.

[0118] The additional components 140 may be variously configured according to types of the wireless devices 100 and 200. For example, the additional components 140 may include at least one of a power unit / battery, input / output (I / O) unit (e.g., audio I / O port, video I / O port), a driving unit, and a computing unit. The wireless devices 100 and 200 may be implemented in the form of, without being limited to, the robot (100a of FIG. 1), the vehicles (100b-1 and 100b-2 of FIG. 1), the XR device (100c of FIG. 1), the hand-held device (100d of FIG. 1), the home appliance (100e of FIG. 1), the IoT device (100f of FIG. 1), a digital broadcast terminal, a hologram device, a public safety device, an MTC device, a medicine device, a FinTech device (or a finance device), a security device, a climate / environment device, the AI server / device (400 of FIG. 1), the BSs (200 of FIG. 1), a network node, etc. The wireless devices 100 and 200 may be used in a mobile or fixed place according to a use-example / service.

[0119] In FIG. 3, the entirety of the various elements, components, units / portions, and / or modules in the wireless devices 100 and 200 may be connected to each other through a wired interface or at least a part thereof may be wirelessly connected through the communication unit 110. For example, in each of the wireless devices 100 and 200, the control unit 120 and the communication unit 110 may be connected by wire and the control unit 120 and first units (e.g., 130 and 140) may be wirelessly connected through the communication unit 110. Each element, component, unit / portion, and / or module within the wireless devices 100 and 200 may further include one or more elements. For example, the control unit 120 may be configured by a set of one or more processors. As an example, the control unit 120 may be configured by a set of a communication control processor, an application processor (AP), an electronic control unit (ECU), a graphical processing unit, and a memory control processor. As another example, the memory unit 130 may be configured by a RAM, a DRAM, a ROM, a flash memory, a volatile memory, a non-volatile memory, and / or a combination thereof.

[0120] FIG. 4 shows an example of UE to which implementations of the present disclosure is applied.

[0121] Referring to FIG. 4, a UE 100 may correspond to the first wireless device 100 of FIG. 2 and / or the wireless device 100 or 200 of FIG. 3.

[0122] A 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.

[0123] The processor 102 may be configured to implement the descriptions, functions, procedures, suggestions, methods and / or operational flowcharts disclosed in the present disclosure. The processor 102 may be configured to control one or more other components of the UE 100 to implement the descriptions, functions, procedures, suggestions, methods and / or operational flowcharts disclosed in the present disclosure. Layers of the radio interface protocol may be implemented in the processor 102. The processor 102 may include ASIC, other chipset, logic circuit and / or data processing device. The processor 102 may be an application processor. The processor 102 may include at least one of a digital signal processor (DSP), a central processing unit (CPU), a graphics processing unit (GPU), a modem (modulator and demodulator). An example of the processor 102 may be found in SNAPDRAGONTMseries of processors made by Qualcomm®, EXYNOSTMseries of processors made by Samsung®, A series of processors made by Apple®, HELIOTMseries of processors made by MediaTek®, ATOMTMseries of processors made by Intel®or a corresponding next generation processor.

[0124] The memory 104 is operatively coupled with the processor 102 and stores a variety of information to operate the processor 102. The memory 104 may include ROM, RAM, flash memory, memory card, storage medium and / or other storage device. When the embodiments are implemented in software, the techniques described herein can be implemented with modules (e.g., procedures, functions, etc.) that perform the descriptions, functions, procedures, suggestions, methods and / or operational flowcharts disclosed in the present disclosure. The modules can be stored in the memory 104 and executed by the processor 102. The memory 104 can be implemented within the processor 102 or external to the processor 102 in which case those can be communicatively coupled to the processor 102 via various means as is known in the art.

[0125] The transceiver 106 is operatively coupled with the processor 102, and transmits and / or receives a radio signal. The transceiver 106 includes a transmitter and a receiver. The transceiver 106 may include baseband circuitry to process radio frequency signals. The transceiver 106 controls the one or more antennas 108 to transmit and / or receive a radio signal.

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

[0127] The display 114 outputs results processed by the processor 102. The keypad 116 receives inputs to be used by the processor 102. The keypad 116 may be shown on the display 114.

[0128] The SIM card 118 is an　integrated circuit　that is intended to　securely store the　international mobile subscriber identity　(IMSI) number and its related　key, which are used to identify and authenticate subscribers on　mobile telephony　devices (such as　mobile phones　and　computers). It is also possible to store contact information on many SIM cards.

[0129] The speaker 120 outputs sound-related results processed by the processor 102. The microphone 122 receives sound-related inputs to be used by the processor 102.

[0130] FIGS. 5 and 6 show an example of protocol stacks in a 3GPP based wireless communication system to which implementations of the present disclosure is applied.

[0131] In particular, FIG. 5 illustrates an example of a radio interface user plane protocol stack between a UE and a BS and FIG. 6 illustrates an example of a radio interface control plane protocol stack between a UE and a BS. The control plane refers to a path through which control messages used to manage call by a UE and a network are transported. The user plane refers to a path through which data generated in an application layer, for example, voice data or Internet packet data are transported. Referring to FIG. 5, the user plane protocol stack may be divided into Layer 1 (for example, a PHY layer) and Layer 2. Referring to FIG. 6, the control plane protocol stack may be divided into Layer 1 (for example, a PHY layer), Layer 2, Layer 3 (e.g., an RRC layer), and a non-access stratum (NAS) layer. Layer 1, Layer 2 and Layer 3 are referred to as an access stratum (AS).

[0132] In the 3GPP LTE system, the Layer 2 is split into the following sublayers: MAC, RLC, and PDCP. In the 3GPP NR system, the Layer 2 is split into the following sublayers: MAC, RLC, PDCP and SDAP. The PHY layer offers to the MAC sublayer transport channels, the MAC sublayer offers to the RLC sublayer logical channels, the RLC sublayer offers to the PDCP sublayer RLC channels, the PDCP sublayer offers to the SDAP sublayer radio bearers. The SDAP sublayer offers to 5G core network quality of service (QoS) flows.

[0133] In the 3GPP NR system, the main services and functions of the MAC sublayer include: mapping between logical channels and transport channels; multiplexing / de-multiplexing of MAC SDUs belonging to one or different logical channels into / from transport blocks (TB) delivered to / from the physical layer on transport channels; scheduling information reporting; error correction through hybrid automatic repeat request (HARQ) (one HARQ entity per cell in case of carrier aggregation (CA)); priority handling between UEs by means of dynamic scheduling; priority handling between logical channels of one UE by means of logical channel prioritization; padding. A single MAC entity may support multiple numerologies, transmission timings and cells. Mapping restrictions in logical channel prioritization control which numerology(ies), cell(s), and transmission timing(s) a logical channel can use.

[0134] Different kinds of data transfer services are offered by MAC. To accommodate different kinds of data transfer services, multiple types of logical channels are defined, for example, each supporting transfer of a particular type of information. Each logical channel type is defined by what type of information is transferred. Logical channels are classified into two groups: control channels and traffic channels. Control channels are used for the transfer of control plane information only, and traffic channels are used for the transfer of user plane information only. Broadcast control channel (BCCH) is a downlink logical channel for broadcasting system control information, paging control channel (PCCH) is a downlink logical channel that transfers paging information, system information change notifications and indications of ongoing public warning service (PWS) broadcasts, common control channel (CCCH) is a logical channel for transmitting control information between UEs and network and used for UEs having no RRC connection with the network, and dedicated control channel (DCCH) is a point-to-point bi-directional logical channel that transmits dedicated control information between a UE and the network and used by UEs having an RRC connection. Dedicated traffic channel (DTCH) is a point-to-point logical channel, dedicated to one UE, for the transfer of user information. A DTCH can exist in both uplink and downlink. In downlink, the following connections between logical channels and transport channels exist: BCCH can be mapped to broadcast channel (BCH); BCCH can be mapped to downlink shared channel (DL-SCH); PCCH can be mapped to 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 uplink, the following connections between logical channels and transport channels exist: CCCH can be mapped to uplink shared channel (UL-SCH); DCCH can be mapped to UL-SCH; and DTCH can be mapped to UL-SCH.

[0135] The RLC sublayer supports three transmission modes: transparent mode (TM), unacknowledged mode (UM), and acknowledged node (AM). The RLC configuration is per logical channel with no dependency on numerologies and / or transmission durations. In the 3GPP NR system, the main services and functions of the RLC sublayer depend on the transmission mode and include: transfer of upper layer PDUs; sequence numbering independent of the one in PDCP (UM and AM); error correction through ARQ (AM only); segmentation (AM and UM) and re-segmentation (AM only) of RLC SDUs; reassembly of SDU (AM and UM); duplicate detection (AM only); RLC SDU discard (AM and UM); RLC re-establishment; protocol error detection (AM only).

[0136] 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); transfer of user data; reordering and duplicate detection; in-order delivery; PDCP PDU routing (in case of split bearers); retransmission of PDCP SDUs; ciphering, deciphering and integrity protection; PDCP SDU discard; PDCP re-establishment and data recovery for RLC AM; PDCP status reporting for RLC AM; duplication of PDCP PDUs and duplicate discard indication to lower layers. The main services and functions of the PDCP sublayer for the control plane include: sequence numbering; ciphering, deciphering and integrity protection; transfer of control plane data; reordering and duplicate detection; in-order delivery; duplication of PDCP PDUs and duplicate discard indication to lower layers.

[0137] In the 3GPP NR system, the main services and functions of SDAP include: mapping between a QoS flow and a data radio bearer; marking QoS flow ID (QFI) in both DL and UL packets. A single protocol entity of SDAP is configured for each individual PDU session.

[0138] In the 3GPP NR system, the main services and functions of the RRC sublayer include: broadcast of system information related to AS and NAS; paging initiated by 5GC or NG-RAN; establishment, maintenance and release of an RRC connection between the UE and NG-RAN; security functions including key management; establishment, configuration, maintenance and release of signaling radio bearers (SRBs) and data radio bearers (DRBs); mobility functions (including: handover and context transfer, UE cell selection and reselection and control of cell selection and reselection, inter-RAT mobility); QoS management functions; UE measurement reporting and control of the reporting; detection of and recovery from radio link failure; NAS message transfer to / from NAS from / to UE.

[0139] FIG. 7 shows an example of the overall architecture of an NG-RAN to which technical features of the present disclosure can be applied.

[0140] Referring to FIG. 7, a gNB may include a gNB-CU (hereinafter, gNB-CU may be simply referred to as CU) and at least one gNB-DU (hereinafter, gNB-DU may be simply referred to as DU).

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

[0142] The gNB-DU is a logical node hosting RLC, MAC, and physical layers of the gNB or the en-gNB. The operation of the gNB-DU is partly controlled by the gNB-CU. One gNB-DU supports one or multiple cells. One cell is supported by only one gNB-DU.

[0143] The gNB-CU and gNB-DU are connected via an F1 interface. The gNB-CU terminates the F1 interface connected to the gNB-DU. The gNB-DU terminates the F1 interface connected to the gNB-CU. One gNB-DU is connected to only one gNB-CU. However, the gNB-DU may be connected to multiple gNB-CUs by appropriate implementation. The F1 interface is a logical interface. For NG-RAN, the NG and Xn-C interfaces for a gNB consisting of a gNB-CU and gNB-DUs, terminate in the gNB-CU. For E-UTRAN-NR dual connectivity (EN-DC), the S1-U and X2-C interfaces for a gNB consisting of a gNB-CU and gNB-DUs, terminate in the gNB-CU. The gNB-CU and connected gNB-DUs are only visible to other gNBs and the 5GC as a gNB.

[0144] Functions of the F1 interface includes F1 control (F1-C) functions as follows.

[0145] (1) F1 interface management function

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

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

[0148] The F1 setup function allows to exchange application level data needed for the gNB-DU and gNB-CU to interoperate correctly on the F1 interface. The F1 setup is initiated by the gNB-DU.

[0149] The gNB-CU configuration update and gNB-DU configuration update functions allow to update application level configuration data needed between gNB-CU and gNB-DU to interoperate correctly over the F1 interface, and may activate or deactivate cells.

[0150] The F1 setup and gNB-DU configuration update functions allow to inform the single network slice selection assistance information (S-NSSAI) supported by the gNB-DU.

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

[0152] (2) System Information management function

[0153] Scheduling of system broadcast information is carried out in the gNB-DU. The gNB-DU is responsible for transmitting the system information according to the scheduling parameters available.

[0154] The gNB-DU is responsible for the encoding of NR master information block (MIB). In case broadcast of system information block type-1 (SIB1) and other SI messages is needed, the gNB-DU is responsible for the encoding of SIB1 and the gNB-CU is responsible for the encoding of other SI messages.

[0155] (3) F1 UE context management function

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

[0157] 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 not available).

[0158] The modification of the F1 UE context can be initiated by either gNB-CU or gNB-DU. The receiving node can accept or reject the modification. The F1 UE context management function also supports the release of the context previously established in the gNB-DU. The release of the context is triggered by the gNB-CU either directly or following a request received from the gNB-DU. The gNB-CU request the gNB-DU to release the UE Context when the UE enters RRC_IDLE or RRC_INACTIVE.

[0159] This function can be also used to manage DRBs and SRBs, for example, establishing, modifying and releasing DRB and SRB resources. The establishment and modification of DRB resources are triggered by the gNB-CU and accepted / rejected by the gNB-DU based on resource reservation information and QoS information to be provided to the gNB-DU. For each DRB to be setup or modified, the S-NSSAI may be provided by gNB-CU to the gNB-DU in the UE context setup procedure and the UE context modification procedure.

[0160] The mapping between QoS flows and radio bearers is performed by gNB-CU and the granularity of bearer related management over F1 is radio bearer level. For NG-RAN, the gNB-CU provides an aggregated DRB QoS profile and QoS flow profile to the gNB-DU, and the gNB-DU either accepts the request or rejects it with appropriate cause value. To support packet duplication for intra-gNB-DU carrier aggregation (CA), one data radio bearer should be configured with two GPRS tunneling protocol (GTP)-U tunnels between gNB-CU and a gNB-DU.

[0161] With this function, gNB-CU requests the gNB-DU to setup or change of the special cell (SpCell) for the UE, and the gNB-DU either accepts or rejects the request with appropriate cause value.

[0162] With this function, the gNB-CU requests the setup of the secondary cell(s) (SCell(s)) at the gNB-DU side, and the gNB-DU accepts all, some or none of the SCell(s) and replies to the gNB-CU. The gNB-CU requests the removal of the SCell(s) for the UE.

[0163] (4) RRC message transfer function

[0164] This function allows to transfer RRC messages between gNB-CU and gNB-DU. RRC messages are transferred over F1-C. The gNB-CU is responsible for the encoding of the dedicated RRC message with assistance information provided by gNB-DU.

[0165] (5) Paging function

[0166] The gNB-DU is responsible for transmitting the paging information according to the scheduling parameters provided.

[0167] The gNB-CU provides paging information to enable the gNB-DU to calculate the exact paging occasion (PO) and paging frame (PF). The gNB-CU determines the paging assignment (PA). The gNB-DU consolidates all the paging records for a particular PO, PF and PA, and encodes the final RRC message and broadcasts the paging message on the respective PO, PF in the PA.

[0168] (6) Warning messages information transfer function

[0169] This function allows to cooperate with the warning message transmission procedures over NG interface. The gNB-CU is responsible for encoding the warning related SI message and sending it together with other warning related information for the gNB-DU to broadcast over the radio interface.

[0170] FIG. 8 shows an interface protocol structure for F1-C to which technical features of the present disclosure can be applied.

[0171] A transport network layer (TNL) is based on Internet protocol (IP) transport, comprising a stream control transmission protocol (SCTP) layer on top of the IP layer. An application layer signaling protocol is referred to as an F1 application protocol (E1AP).

[0172] FIG. 9a, FIG. 9b, and FIG. 9c show an example of Remote UE Initial Access procedure, to which technical features of the present disclosure can be applied.

[0173] 1. The U2N Remote UE and the U2N Relay UE perform discovery procedure, and establish PC5 connection using NR ProSe procedure.

[0174] 2. The U2N Remote UE sends an RRCSetupRequest message to the U2N Relay UE via PC5 Relay RLC Channel.

[0175] 3. The U2N Relay UE withholds the received RRC message and sends the SidelinkUEInformationNR message to the gNB-DU. Before that, if the U2N Relay UE is in RRC_IDLE / RRC_INACTIVE state, it should trigger the RRC establishment / resume procedure to enter RRC_CONNECTED state upon reception of the RRC message.

[0176] 4. The gNB-DU sends the UL RRC MESSAGE TRANSFER message of the U2N Relay UE by encapsulating the SidelinkUEInformationNR message to gNB-CU, and gNB-CU allocates the local ID of U2N Remote UE.

[0177] 5. The gNB-CU sends the UE CONTEXT MODIFICATION REQUEST message of the U2N Relay UE to gNBDU. Such message may request the establishment of Uu Relay RLC channel(s) for the transmission of U2N Remote UE's SRB0

[0178] 6. The gNB-DU sends the UE CONTEXT MODIFICATION RESPONSE message of the U2N Relay UE to gNBCU.

[0179] 7. The gNB-CU sends the DL RRC MESSAGE TRANSFER message of the U2N Relay UE to gNB-DU by encapsulating the RRCReconfiguration message, which contains the local ID allocated to the U2N Remote UE. The RRCReconfiguration message shall also contain the Uu Relay RLC channel(s) configuration if not configured and bearer mapping for relaying of U2N Remote UE's SRB0.

[0180] 8. The gNB-DU sends the RRCReconfiguration message to the U2N Relay UE to configure the local ID of the U2N Remote UE, the Uu Relay RLC channel(s) configuration and bearer mapping for relaying of U2N Remote UE's SRB0.

[0181] 9. The U2N Relay UE sends the RRCReconfigurationComplete message to gNB-DU.

[0182] 10. The gNB-DU sends the UL RRC MESSAGE TRANSFER message of the U2N Relay UE by encapsulating the RRCReconfigurationComplete message to gNB-CU.

[0183] 11. After receiving the local ID of the U2N Remote UE and the Uu Relay RLC channel(s) configuration and bearer mapping for relaying of U2N Remote UE's SRB0, the U2N Relay UE sends the RRCSetupRequest message of the U2N Remote UE to gNB-DU. The local ID of the U2N Remote UE and RB ID for SRB0 are conveyed in the SRAP header.

[0184] 12. The gNB-DU allocates a C-RNTI and a gNB-DU UE F1AP ID for the U2N Remote UE and sends the INITIAL UL RRC MESSAGE TRANSFER message to gNB-CU by encapsulating the RRCSetupRequest message of the U2N Remote UE. In addition, the local ID of the U2N Remote UE , the gNB-DU UE F1AP ID of the U2N Relay UE and the sidelink configuration container for at least the PC5 Relay RLC channel configuration for relaying of U2N Remote UE's SRB1 are included in the INITIAL UL RRC MESSAGE TRANSFER message.

[0185] 13. The gNB-CU allocates a gNB-CU UE F1AP ID for the U2N Remote UE and generates a RRCSetup message towards the U2N Remote UE. The RRC message is encapsulated in the DL RRC MESSAGE TRANSFER message, and includes the configurations of PC5 Relay RLC channel and bearer mapping at least for the transmission of U2N Remote UE's SRB1.

[0186] 14. The gNB-DU sends the RRCSetup message to the U2N Remote UE via the U2N Relay UE.

[0187] 15. The gNB-CU configures the U2N Relay UE with PC5 Relay RLC channel, Uu Relay RLC channel and bearer mapping for relaying of U2N Remote UE's SRB1. According to the configuration from gNB-CU, the U2N Relay UE establishes a PC5 Relay RLC channel for relaying of U2N Remote UE's SRB1 over PC5 and establishes a Uu Relay RLC channel for relaying of U2N Remote UE's SRB1 towards gNB-DU if not configured yet.

[0188] - This step may be performed earlier, e.g., via steps 5~8.

[0189] 16. The U2N Remote UE sends the RRCSetupComplete message to the gNB-DU via the U2N Relay UE.

[0190] 17. The gNB-DU encapsulates the RRC message in the UL RRC MESSAGE TRANSFER message and sends it to the gNB-CU.

[0191] 18. Upon receiving the RRCSetupComplete message of U2N Remote UE, the gNB-CU sends the INITIAL UE MESSAGE message to the AMF.

[0192] 19. The AMF sends the INITIAL CONTEXT SETUP REQUEST message to the gNB-CU.

[0193] 20. The gNB-CU sends the UE CONTEXT SETUP REQUEST message to establish the U2N Remote UE context in the gNB-DU. Such message may request the configuration of PC5 Relay RLC channels for the transmission of U2N Remote UE's SRB2 and DRBs, and may also encapsulate the SecurityModeCommand message.

[0194] 21. The gNB-DU sends the SecurityModeCommand message to the U2N Remote UE via U2N Relay UE.

[0195] 22. The gNB-DU sends the UE CONTEXT SETUP RESPONSE message of the U2N Remote UE to the gNB-CU, which contains the configuration of PC5 Relay RLC channels for the transmission of U2N Remote UE's SRB2 and DRBs.

[0196] 23. The U2N Remote UE responds with the SecurityModeComplete message.

[0197] 24. The gNB-DU encapsulates the RRC message in the UL RRC MESSAGE TRANSFER message and sends it to the gNB-CU.

[0198] 25. The gNB-CU generates the RRCReconfiguration message for U2N Remote UE and encapsulates it in the DL RRC MESSAGE TRANSFER message. The RRCReconfiguration message contains the configuration of PC5 Relay RLC channels and bearer mapping for the transmission of U2N Remote UE's SRB2 and DRBs.

[0199] 26. The gNB-DU sends RRCReconfiguration message to the U2N Remote UE via the U2N Relay UE.

[0200] 27. The U2N Remote UE sends RRCReconfigurationComplete message to the gNB-DU via the U2N Relay UE.

[0201] 28. The gNB-DU encapsulates the RRC message in the UL RRC MESSAGE TRANSFER message and send it to the gNB-CU.

[0202] 29. The gNB-CU sends the INITIAL CONTEXT SETUP RESPONSE message to the AMF.

[0203] 30. The gNB-CU configures additional Uu Relay RLC channels between the gNB-DU and the U2N Relay UE, and additional PC5 Relay RLC channels for the U2N Relay UE for relaying of U2N Remote UE's DRBs and SRBs. Also, such step may configure the bearer mapping between U2N Remote UE's DRB / SRB and PC5 / Uu Relay RLC channel at the U2N Relay UE. - This step may be performed earlier.

[0204] FIG. 10a and FIG. 10b show an example of Remote UE RRC Resume procedure, to which technical features of the present disclosure can be applied.

[0205] 1. The U2N Remote UE and the U2N Relay UE perform discovery procedure, and establish PC5 connection using NR ProSe procedure. This step may be omitted if PC5 connection was established.

[0206] 2. The U2N Remote UE sends an RRCResumeRequest message to the U2N Relay UE via PC5 RLC Relay Channel.

[0207] 3~10. The gNB-CU allocates the local ID of the U2N Remote UE if the U2N Relay UE does not have it. The details of those steps can be referred to FIG. 12a and FIG. 12b.

[0208] 11. After receiving the local ID of the U2N Remote UE, the U2N Relay UE sends the RRCResumeRequest message of the U2N Remote UE to gNB-DU.

[0209] 12. The gNB-DU allocates a C-RNTI and a gNB-DU UE F1AP ID for the U2N Remote UE and sends the INITIAL UL RRC MESSAGE TRANSFER message to gNB-CU by encapsulating the RRCResumeRequest message of the U2N Remote UE. In addition, the local ID of the U2N Remote UE, the gNB-DU UE F1AP ID of the U2N Relay UE and the sidelink configuration container for at least the PC5 Relay RLC channel configuration for relaying of U2N Remote UE's SRB1 are included in the INITIAL UL RRC MESSAGE TRANSFER message.

[0210] 13. The gNB-CU configures the U2N Relay UE with PC5 Relay RLC channel, Uu Relay RLC channel and bearer mapping for relaying of U2N Remote UE's SRB1. According to the configuration from gNB-CU, the U2N Relay UE establishes a PC5 Relay RLC channel for relaying of U2N Remote UE's SRB1 over PC5 and establishes a Uu Relay RLC channel for relaying of U2N Remote UE's SRB1 over Uu.

[0211] - This step may be performed earlier, e.g., via steps 5~8.

[0212] 14~19. The details of those steps can be referred to Steps 5~10 in clause 8.6.2. For L2 U2N relay, the RRC message(s) between the U2N Remote UE and the gNB-DU are relayed via the U2N Relay UE; Steps 14~15 may additionally perform the configurations of PC5 Relay RLC channel(s) for relaying of U2N Remote UE's SRB2 and DRBs.

[0213] 20. The gNB-CU establishes additional Uu Relay RLC channels between the gNB-DU and the U2N Relay UE, and additional PC5 Relay RLC channels for the U2N Relay UE for relaying of U2N Remote UE's DRBs and SRBs. Also, such step may configure the bearer mapping between U2N Remote UE's DRB / SRB and PC5 / Uu Relay RLC channel at the U2N Relay UE. - This step may be performed earlier.

[0214] Meanwhile, following Release 18, 3GPP has conducted an additional study (Study on System Enhancement for Proximity-based Services in 5GS - Phase 3 (FS_5G_ProSe_Ph3)) to support ProSe (Proximity based Services) in 5GS in Release 19, and it is scheduled to start standard specification work based on the study results captured in 23.700-03. The objective of the standard specification work, namely New WID on Proximity-based Services in 5GS - Phase 3 (5G_ProSe_Ph3), is as follows.

[0215] - The objective of this work item is to specify 5G System enhancements to support multi-hop UE-to-Network Relay and UE-to-UE Relay Services as per conclusions reached within TR 23.700-03.

[0216] - The detailed objectives are as follows:

[0217] > WT#1: Enhance ProSe to support multi-hop UE-to-Network Relay.

[0218] > WT#2: Enhance ProSe to support Layer 3 multi-hop UE-to-UE Relays for IP PDU type based on IETF MANET Protocol.

[0219] > WT#3: Enhance ProSe to support Layer 3 multi-hop UE-to-UE Relays for Ethernet and Unstructured PDU type based on Release 18 PC5 protocol.

[0220] - The UE-to-Network Relay include both Layer-3 and Layer-2 Relays.

[0221] - This work item requires coordination with RAN WGs in particular for Layer 2 multi-hop UE-to-Network Relay.

[0222] Also, in the 3GPP RAN plenary #104 meeting, it was approved to proceed with a work item on additional measures to support ProSe (Proximity based Services) through Multi-hop in 5GS as follows. The objective of New WID on NR sidelink multi-hop relay (NR_SL_relay_enh2) - RP-241609 is as below.

[0223] - Objective of SI or Core part WI or Testing part WI

[0224] - The objective of this work item is to specify solutions that are needed to support multi-hop Layer-2 UE-to-Network relay for a single indirect path via SL relay UEs based on Rel-17 / 18 SL relay functionalities [RAN2, RAN3]

[0225] > 1. Specify mechanisms to support up to two additional hops relays on top of Rel-17 U2N relay. The work starts with one additional hop relay (for example, remote UE -> first relay UE -> last relay UE -> gNB) until RAN#107 and further check will be made in RAN#107 if it can be easily extended to two additional hops relays (for example, remote UE -> first relay UE -> second relay UE -> last relay UE -> gNB). A necessary criterion for the specified mechanisms is easy extensibility to support two additional hop relays for the work done until RAN#107 and to be forward compatible for future extensions for additional relays.

[0226] > A. Relay discovery and (re)selection [RAN2]

[0227] > B. Signalling support for relay UEs and remote UE authorization if SA2 concludes it is needed [RAN3]

[0228] > C. Impact on SRAP and QoS handling for multi-hop [RAN2]

[0229] > D. Control plane procedures [RAN2, RAN3]

[0230] > 2. Specify the following intra-gNB service continuity scenarios for multi-hop U2N relay based on Rel-17 / 18 procedures (for remote UE):

[0231] - First Priority:

[0232] > A. Intra-gNB multi-hop indirect to direct path switching using existing framework

[0233] > B.Intra-gNB multi-hop indirect to single-hop indirect path switching using existing framework

[0234] - Second Priority in order of importance:

[0235] > C. Intra-gNB direct to multi-hop indirect path switching

[0236] > D. Intra-gNB single-hop indirect to multi-hop indirect path switching

[0237] - The scenarios C and D are limited to path switching to a target indirect path consisting of the last relay UE in "direct" RRC Connected mode and all the other intermediate relay(s) in "indirect" RRC Connected mode to the same cell.

[0238] - The current existing measurement framework and existing data forwarding mechanism should be reused.

[0239] Currently, in 3GPP RAN2, in a situation where all U2N Relay UEs participating in Multi-hop relay operation are in RRC_CONNECTED state (for example, Approach 1), the basic procedure to support initial access of U2N Remote UE is being discussed. Additionally, in a situation where some or all among the remaining U2N Relay UEs, excluding the U2N Relay UE located at the last hop (for example, the U2N Relay UE directly connected to the base station), are in RRC_IDLE or RRC_INACTIVE state (for example, Approach 2), the procedure to support initial access of U2N Remote UE is also being discussed.

[0240] - Agreement in RAN2#128:

[0241] - Support a baseline procedure for the case in which the intermediate relay UEs for a remote UE all transition to RRC_CONNECTED (if not already there) when the remote UE goes to RRC_CONNECTED.

[0242] > 1. Support this case based on existing U2N framework, with all the UEs RRC_CONNECTED to the last relay UE's serving cell.

[0243] > 2. Continue to discuss whether / how to support the case that intermediate relay UEs do not all move to RRC_CONNECTED when the remote UE triggers connection establishment.

[0244] - All agreements in this WI apply to both these cases unless otherwise specified.

[0245] In particular, looking at the email discussion currently being conducted in RAN2 (Control plane approach 2 impact (Apple / Ericsson) [Ref #1]), it is in a state of conducting a discussion regarding the specification impact necessary to support Approach 2. Accordingly, in a situation where the base station is separated into gNB-CU and gNB-DU, a measure to support Approach 2 is necessary.

[0246] In addition, according to the RAN2 discussion, the base station can decide to transmit by multiplexing together the SRBs and / or DRBs of a new U2N Remote UE into the PC5 Relay RLC channel configuration allocated / configured for existing UEs (for example, Relay UE and / or Remote UE). In a situation where the base station is separated into gNB-CU and gNB-DU, if the gNB-CU decides to multiplex the SRBs and / or DRBs of the new U2N Remote UE into the existing PC5 Relay RLC channel configuration, a method is necessary for the gNB-CU to inform information about the UE (for example, Remote UE and / or Relay UE) that will together use / utilize the existing PC5 Relay RLC channel configuration instead of requesting the allocation / configuration of a new PC5 Relay RLC channel configuration within the UE CONTEXT MODIFICATION REQUEST message.

[0247] In addition, looking at the Fast / Parallel RRC Setup for MH relay (R2-2503078 [Ref#1]) conducted in RAN2#129bis, a discussion has been conducted regarding the specification impact necessary to support Fast / Parallel RRC Setup. Therefore, in a situation where Fast / Parallel RRC Setup is applied, a method is necessary to inform the gNB-DU of the situation where the gNB-CU decided to multiplex the SRBs and / or DRBs of the new U2N Remote UE into the existing PC5 Relay RLC channel configuration.

[0248] Therefore, studies for support of multi-hop relay UE are required.

[0249] Hereinafter, a method for support of multi-hop relay UE, according to some embodiments of the present disclosure, will be described with reference to the following drawings.

[0250] The following drawings are created to explain specific embodiments of the present disclosure. The names of the specific devices or the names of the specific signals / messages / fields shown in the drawings are provided by way of example, and thus the technical features of the present disclosure are not limited to the specific names used in the following drawings. Herein, a wireless device may be referred to as a user equipment (UE).

[0251] In the present disclosure, UE (User Equipment) and terminal are explained interchangeably. Also, UE-to-Network Relay, ProSe UE-to-Network Relay, Relay, Relay UE, UE-NW Relay, 5G ProSe UE-to-Network Relay, 5G ProSe UE-to-NW Relay, 5G ProSe UE-to-Network Relay UE, U2N Relay, U2N Relay UE, etc., are used interchangeably. Also, Remote UE, 5G Remote UE, 5G ProSe Remote UE, U2N Remote UE, etc., are used interchangeably. Also, a UE that is not a UE-to-Network Relay may be referred to as a Remote UE or may be referred to just as a UE.

[0252] In the present disclosure, in order to provide network connection services to a Remote UE, a U2N Relay located on the path between the Remote UE and the U2N Relay directly connected with the base station may be referred to as an Intermediate U2N Relay.

[0253] In the present disclosure, it is assumed that a UE can not only perform a relay role (Intermediate U2N Relay role or U2N Relay role directly connected to the base station through Uu) so that a U2N Remote UE receives network connection services, but also can perform communication with the network through another U2N Relay in order to receive connection services to the network for itself (for example, in order to transmit and receive its own traffic through the network) (for example, can perform the U2N Remote UE role). In particular, a UE can simultaneously perform the Intermediate U2N Relay role and the U2N Remote UE role. This can be applied throughout this specification.

[0254] In the present disclosure, U2N (UE-to-Network) Relay is written targeting Layer-2 U2N Relay, but it can mean all kinds of UE-to-Network Relay (e.g., Layer-2 UE-to-Network Relay, Layer-3 UE-to-Network Relay). Also, In the present disclosure, although it is written targeting U2N Relay, the contents written about the section between a U2N Remote UE and a U2N Relay located at the last hop (for example, a U2N Relay directly connected with the base station) are also applicable to Multi-hop UE-to-UE relay operation.

[0255] In the present disclosure, it is described focusing on the proposing contents. Regarding ProSe related operations and procedures, it is decided to basically refer to TS 23.304, TS 24.554, TS 33.536, TS 33.503, TS 38.300, TS 38.401, TS 38.331, TS 38.351, etc.

[0256] The measure to support the proposing Multi-hop UE-to-Network relaying can be configured by a combination of one or more of the following operations / configurations / steps.

[0257] In the NG messages between AMF and NG-RAN described below, some new NG messages may be defined and used. Also, in the RRC messages between NG-RAN and the terminal described below, some new RRC messages may be defined and used.

[0258] In the procedures below, certain steps may be performed simultaneously / in parallel, or may be performed in a swapped order with each other.

[0259] The names of the indication or parameter information proposed below are examples, and for the proposed procedure / purpose / method, they can be interpreted by being replaced with other names.

[0260] FIG. 11 shows an example of a method for support of multi-hop relay UE, according to some embodiments of the present disclosure.

[0261] In particular, FIG. 11 shows an example of a method performed by a central unit (CU) of a radio access network (RAN) node.

[0262] In step S1101, the CU of the RAN node may receive, from a last relay User Equipment (UE), UE information related to a inter-UE link including (i) information related to a Layer-2 identity (L2 ID) of a remote UE and (ii) information related to the last relay UE.

[0263] For example, the last relay UE may be directly connected to a cell provided by a distributed unit (DU) of the RAN node.

[0264] For example, in this scenario, at least one relay UE below may be a intermediate relay UE which are indirectly connected to the cell provided by the DU of the RAN node. For example, the at least one relay UE may be connected to the cell provided by the DU of the RAN node via the last relay UE.

[0265] For example, the remote UE may be indirectly connected to the cell provided by the DU of the RAN node. For example, the remote UE may be connected to the cell provided by the DU of the RAN node via the at least one relay UE (which is the intermediate relay UE) and the last relay UE (which is directly connected to the cell).

[0266] For example, the L2 ID of the remote UE may be used for identifying the remote UE for the inter-UE link.

[0267] In step S1102, the CU of the RAN node may transmit, to the last relay UE, a radio resource control (RRC) reconfiguration message including information related to a local ID of the remote UE.

[0268] For example, the CU of the RAN node may allocate the local ID of the remote UE upon receiving the UE information related to the inter-UE link.

[0269] For example, the local ID of the remote UE may be valid only for a cell served by the DU of the RAN node.

[0270] In step S1103, the CU of the RAN node may receive, from a distributed unit (DU) of the RAN node, an uplink RRC message transfer message including an RRC setup request for the remote UE.

[0271] In step S1104, the CU of the RAN node may transmit, to the DU of the RAN node, a downlink RRC message transfer message including (i) information related to the L2 ID of the remote UE and (ii) an RRC setup message.

[0272] For example, the RRC setup message may be forwarded with a first header to the last relay UE via the DU of the RAN node.

[0273] For example, the first header may include (i) information related to the L2 ID of the remote UE and (ii) information related to the local ID of the remote UE.

[0274] For example, the first header may be a Sidelink Relay Adaptation Protocol (SRAP) header.

[0275] For example, the first header may be configured by the DU of the RAN node.

[0276] For example, the RRC setup message may be forwarded with the first header to at least one relay UE from via the last relay UE. The at least one relay UE may be in RRC idle state or RRC inactive state.

[0277] For example, the RRC setup message may be forwarded to the remote UE via the at least one relay UE.

[0278] For example, before the CU of the RAN node receive UE information related to a inter-UE link in step S1101, the RRC setup request for the remote UE may be transmitted with a second header from the remote UE to the at least one relay UE. The second header may include information related to the L2 ID of the remote UE.

[0279] For example, the RRC setup request for the remote UE may be forwarded with the second header from the at least one relay UE to the last relay UE.

[0280] For example, the RRC setup request for the remote UE may be forwarded with a third header from the last relay UE to the DU of the RAN node.

[0281] For example, the third header may include the local ID of the remote UE. For example, the third header may include the local ID of the remote UE and the L2 ID of the remote UE. For example, the third header may be an SRAP header.

[0282] According to some embodiments of the present disclosure, the CU of the RAN node may transition the remote UE from RRC connected state to RRC idle state or RRC inactive state. The CU of the RAN node may transmit, to the DU of the RAN node, a DL RRC MESSAGE TRANSFER message including an RRC release message. The DU of the RAN node may transmit an RRC release message with a fourth header to the remote UE via the at least one relay UE in RRC idle sate or RRC inactive state.

[0283] For example, the RRC release message for the remote UE may be transmitted with a fourth header to the last relay UE and the at least one relay UE from the DU of the RAN node. For example, the RRC release message may be forwarded to the remote UE.

[0284] For example, the fourth header may include information for releasing the local ID of the remote UE (for example, an indication). For example, when the at least one relay UE receives the information for releasing the local ID of the remote UE, the at least one relay UE may release the local ID of the remote UE. After releasing the local ID for the remote UE, the corresponding local ID could be used for different UE, when the CU of the RAN node allocates the corresponding local ID for the different UE.

[0285] For example, the remote UE is in communication with at least one of a user equipment, a network, or an autonomous vehicle other than remote UE. For example, the remote UE is in communication with at least one relay UE.

[0286] Hereinafter, technical features related to support of Multi-hop Relay UE in RRC_INACTIVE are described.

[0287] In the present disclosure, a method is presented for a U2N Relay UE in RRC_CONNECTED state to configure an SRAP header so that a U2N Relay UE in RRC_IDLE or RRC_INACTIVE state can store the mapping relationship between L2 ID and Local ID for a U2N Remote UE. Also, in a case where the base station is divided into gNB-CU and gNB-DU, a method is presented for the gNB-CU to provide related information so that the gNB-DU can configure an SRAP header to provide the mapping relationship between L2 ID and Local ID for a U2N Remote UE to the U2N Relay UE in RRC_IDLE or RRC_INACTIVE state. Additionally, in a situation where a U2N Remote UE is connected with the base station through a U2N Relay UE, if an RRC state transition of the U2N Relay UE occurs, a method is presented to manage information related to the U2N Remote UE (e.g., local ID(s) for U2N Remote UE(s), PC5 Relay RLC channel configuration(s), information for mapping / routing SRBs and DRBs related to local ID(s) for U2N Remote UE(s) to a specific egress PC5 / Uu Relay RLC channel, etc.) in the U2N Relay UE.

[0288] Embodiment 1:U2NRemoteUE'sinitial access viaU2NRelayUEsin RRC_INACTIVE / RRC_IDLE andU2NRelayUEsin RRC_CONNECTED

[0289] Among the proposing contents below, the explanation or operation for U2N Relay UE#3 (for example, 3-hop U2N Relay UE) can also be applied to a U2N Relay UE of 2-hop or more (for example, intermediate UE-to-Network Relay UE).

[0290] FIG. 12a and FIG. 12b show an example of a method for support of multi-hop relay UE, according to some embodiments of the present disclosure.

[0291] In particular, FIG. 12a and FIG. 12b show a procedure on U2N Remote UE's initial access via U2N Relay UEs in RRC_INACTIVE / RRC_IDLE and U2N Relay UEs in RRC_CONNECTED.

[0292] In FIG. 12a and FIG. 12b, it is assumed that U2N Relay UE#3 and U2N Relay UE#1 are in RRC_CONNECTED state. Also, it is assumed that U2N Relay UE#4 and U2N Relay UE#2 are in RRC_IDLE or RRC_INACTIVE state. The above embodiment is applicable to all remaining situations excluding the case where U2N Relay UE#2, U2N Relay UE#3, and U2N Relay UE#4 are all in RRC_CONNECTED state or all in RRC_IDLE or RRC_INACTIVE state.

[0293] U2N Relay UE#3 in RRC_CONNECTED state can not only perform the Intermediate U2N Relay role so that the U2N Remote UE receives network connection services, but also can perform communication with the network through U2N Relay UE#1 and U2N Relay UE#2 in order to receive connection services to the network for itself.

[0294] Step 1: U2N Remote UE discovers a U2N Relay UE that can provide connection to the network. In FIG. 12a and FIG. 12b, it is assumed that it is connected with the base station through U2N Relay UE#1~U2N Relay UE#4, but it is also applicable to a situation where it is connected to the network through n number of U2N Relay UEs (for example, n-hop).

[0295] In this process, serving cell information of the U2N Relay UE to be used / referenced in (re)selecting the U2N Relay UE and information for accessing the corresponding cell can be delivered together to the U2N Remote UE. In the above, it means the serving cell information of U2N Relay UE#1, and it is also possible to deliver together the serving cell information of other U2N Relay UEs (for example, U2N Relay UE#2, U2N Relay UE#3, U2N Relay UE#4) to the U2N Remote UE. Regarding the existing input parameters used / delivered in the Discovery process, TS 23.304 can be referenced. Additionally, some or all of the following information may also be exchanged / delivered in the Discovery process.

[0296] - Number of hops (n): The number of U2N Relay UEs necessary for the U2N Remote UE to be connected to the network

[0297] - Information about each node involved in the network connection (e.g. User Info ID) and L2 ID of each node (for example, L2 IDs for U2N Remote UE, U2N Relay UE#1, U2N Relay UE#2, U2N Relay UE#3, U2N Relay UE#4)

[0298] Also, the U2N Remote UE first creates a new PC5 connection with U2N Relay UE#4 or changes / updates an existing PC5 connection for connection to the network. In FIG. 12a and FIG. 12b, it is assumed that a Direct Communication Request message is transmitted to U2N Relay UE#4 in order to create a new PC5 connection. Equally, U2N Relay UE#4 towards U2N Relay UE#3, U2N Relay UE#3 towards U2N Relay UE#2, and U2N Relay UE#2 towards U2N Relay UE#1 sequentially transmit the Direct Communication Request message.

[0299] U2N Relay UE#1, having received the Direct Communication Request message, responds with a Direct Communication Accept message in the case of accepting the creation or change / update of the PC5 connection with U2N Relay UE#2. In the same manner, U2N Relay UE#2 towards U2N Relay UE#3, U2N Relay UE#3 towards U2N Relay UE#4, and U2N Relay UE#4 towards U2N Remote UE sequentially transmit the Direct Communication Accept message.

[0300] Different from the above-mentioned, unicast links can be formed between U2N Remote UE and U2N Relays in various ways. For example, by forming unicast links hop-by-hop (for example, U2N Remote UE and U2N Relay UE#4 form a unicast link, U2N Relay UE#4 and U2N Relay UE#3 form a unicast link, U2N Relay UE#3 and U2N Relay UE#2 form a unicast link, U2N Relay UE#2 and U2N Relay UE#1 form a unicast link), U2N Remote UE and U2N Relay UE#1 can form an end-to-end unicast link. This can be applied throughout this specification.

[0301] Regarding the existing input parameters included in the Direct Communication Request / Direct Communication Accept messages, TS 23.304 can be referenced.

[0302] Step 2: U2N Remote UE attempts to create an RRC connection by sending an RRCSetupRequest message towards the base station through U2N Relay UE#4.

[0303] Also, for the transmission / reception of SRB0 messages (for example, RRCSetupRequest, RRCSetup, etc.) of the U2N Remote UE, an existingly defined PC5 Relay RLC channel configuration (for example, SL-RLC0) may be used, or a separate PC5 Relay RLC channel configuration for Multi-hop U2N relay operation may be newly defined.

[0304] A U2N Remote UE supporting Multi-hop relay operation, in the same manner as the operation of Rel-17 U2N Remote UE described in TS 38.351, can deliver only the SRB0 message (for example, RRCSetupRequest message) without any SRAP header to U2N Relay UE#4.

[0305] Step 3: If U2N Relay UE#4 is in RRC_IDLE or RRC_INACTIVE state, after receiving the RRCSetupRequest message of the U2N Remote UE, it can configure and deliver an SRAP header as follows, as can be seen in [Ref #1], in order to together inform nearby U2N Relay UEs of the L2 ID for U2N Remote UE. That is, if the F field is set to 1, it can inform that, not including the Local ID for the U2N Remote UE as in the single-hop relay operation of TS 38.351, the L2 ID for the U2N Remote UE was included instead.

[0306] FIG. 13 shows an example of an SRAP PDU Format, according to some embodiments of the present disclosure.

[0307] In particular, FIG. 13 shows an SRAP PDU Format#1 for U2N Relay UE in RRC_IDLE or RRC_INACTIVE.

[0308] Otherwise, in Step 2, in order for the U2N Remote UE to inform U2N Relay UEs in RRC_INACTIVE or RRC_IDLE state of the L2 ID for U2N Remote UE, after configuring an SRAP header as in FIG. 13, it can deliver this together with the RRCSetupRequest message to U2N Relay UE#4, and U2N Relay UE#4 in RRC_INACTIVE or RRC_IDLE state can deliver this to U2N Relay UE#3.

[0309] Step 4: U2N Relay UE#3 in RRC_CONNECTED state, in order to deliver the RRCSetupRequest message received from U2N Relay UE#4 to the base station, sends a SidelinkUEInformationNR message to the base station and requests Local ID for the U2N Remote UE, allocation / configuration of PC5 / Uu Relay RLC channel configuration necessary for transmitting SRB0 / 1 messages for the U2N Remote UE, etc. In this process, U2N Relay UE#3 can together deliver the L2 ID for U2N Remote UE information received in Step 3 and its own L2 ID.

[0310] gNB-CU, having received the SidelinkUEInformationNR message, allocates / configures the local ID for the U2N Remote UE. As in the UE-to-Network Relay operation within TS 38.351, in all sections between the U2N Remote UE and the base station, it can route data and / or signaling of the U2N Remote UE through the local ID allocated / configured in Step 4. For this, the Local ID value defined in TS 38.331 (for example, INTEGER (0..255)) may be used, but in order to distinguish it from the existing Single-hop U2N Relay operation, a separate Local ID for Multi-hop U2N Relay operation may be newly defined.

[0311] - In the case where there are U2N Relay UEs in RRC_CONNECTED state among U2N Relay UEs excluding U2N Relay UE#1, the U2N Relay UE in RRC_CONNECTED state located at the closest place to the U2N Remote UE can send a SidelinkUEInformationNR message to the base station and request Local ID for the U2N Remote UE, allocation / configuration of PC5 / Uu Relay RLC channel configuration necessary for transmitting SRB0 / 1 messages for the U2N Remote UE, etc. In FIG. 12a and FIG. 12b, since U2N Relay UE#3 is currently in RRC_CONNECTED state and is located closest to the U2N Remote UE, it is assumed that it transmits the SidelinkUEInformationNR message to the base station.

[0312] - In this specification, it is assumed that the gNB-CU has information on the number of U2N Relay UEs involved in the Multi-hop relay operation (for example, Number of hops (n)), and the corresponding information may be included in the SidelinkUEInformationNR messages sent by the U2N Relay UEs currently in RRC_CONNECTED state.

[0313] In addition, the gNB-CU can implicitly know the fact that U2N Relay UEs currently in RRC_IDLE or RRC_INACTIVE state exist between the U2N Remote UE and U2N Relay UE#3, and between U2N Relay UE#3 and U2N Relay UE#1, through the information on the number of U2N Relay UEs involved in the Multi-hop relay operation (for example, Number of hops (n)), the number of U2N Relay UEs currently in RRC_CONNECTED state, and information on the peer UE with which the U2N Relay UE currently in RRC_CONNECTED state has established a PC5 connection, etc.; however, the gNB-CU does not have the UE context related to the corresponding U2N Relay UEs. For example, based on the SidelinkUEInformationNR messages sent by U2N Relay UE#1 and U2N Relay UE#3, the gNB-CU can know that U2N Relay UE#1 has a PC5 connection with U2N Relay UE#2, and U2N Relay UE#3 has respective PC5 connections with U2N Relay UE#2 and U2N Relay UE#4. Also, the gNB-CU can know that the U2N Remote UE has a PC5 connection with U2N Relay UE#4 based on the SidelinkUEInformationNR message sent after the U2N Remote UE transitions to RRC_CONNECTED state.

[0314] Step 5: gNB-CU receives the allocation / configuration of Uu Relay RLC channel configuration necessary for transmitting SRB0 / 1 messages for the U2N Remote UE from the gNB-DU. Additionally, the gNB-CU may receive the allocation / configuration of PC5 Relay RLC channel configuration between U2N Relay UE#2 and U2N Relay UE#1 necessary for transmitting SRB0 / 1 messages for the U2N Remote UE from the gNB-DU.

[0315] Step 6: In order to route the SRB0 / 1 messages of the U2N Remote UE, the gNB-CU can deliver some or all of the following information to U2N Relay UE#1 through the RRCReconfiguration message of U2N Relay UE#1.

[0316] A. Local ID for the U2N Remote UE allocated / configured in Step 4

[0317] B. Uu Relay RLC channel configuration necessary for transmitting SRB0 / 1 messages for the U2N Remote UE, received from the gNB-DU in Step 5

[0318] C. PC5 Relay RLC channel configuration between U2N Relay UE#2 and U2N Relay UE#1 for transmitting SRB0 / 1 messages for the U2N Remote UE, received from the gNB-DU in Step 5

[0319] D. SRAP information for mapping / routing each SRAP Data PDU belonging to SRB0 / 1 to a specific egress PC5 / Uu Relay RLC channel. Or, SRAP information for mapping / routing SRAP Data PDU transmitted through a specific ingress PC5 / Uu Relay RLC channel for SRB0 / 1 to a specific egress Uu / PC5 Relay RLC channel. The information can be allocated / configured per Local ID for U2N Remote UE.

[0320] - In the case where U2N Relay UE#1 received the PC5 Relay RLC channel configuration for SRB0 / 1 in the PC5 connection between U2N Relay UE#2 and U2N Relay UE#1 in Step 6, it can perform the allocation / configuration for the PC5 Relay RLC channel in the corresponding PC5 connection by informing U2N Relay UE#2 of this through the RRC Reconfiguration Sidelink process. Because U2N Relay UE#1 already knows that U2N Relay UE#2 is in RRC_INACTIVE or RRC_IDLE state, it may perform the Reconfiguration Sidelink process for PC5 Relay RLC channel configuration allocation / configuration, or it may know that it must perform the Reconfiguration Sidelink process towards U2N Relay UE#2 by the request of the base station received in Step 6.

[0321] Step 7: After finishing the allocation / configuration of the Bearer to be used in the RRC connection with the base station and / or the egress PC5 / Uu Relay RLC channel configuration for transmitting SRB0 / 1 messages of the U2N Remote UE according to the RRCReconfiguration message received in Step 6, U2N Relay UE#1 informs this by sending an RRCReconfigurationComplete message to the gNB-CU via the gNB-DU.

[0322] Step 8: In order to allocate / configure the PC5 Relay RLC channel for delivering the SRB0 / 1 message of the U2N Remote UE to U2N Relay UE#3, the gNB-CU requests the allocation / configuration of the PC5 Relay RLC channel configuration for the PC5 connection between U2N Relay UE#2 and U2N Relay UE#3 and / or between U2N Relay UE#3 and U2N Relay UE#4 for delivering the SRB0 / 1 message to the gNB-DU through the F1AP UE Context Modification procedure.

[0323] Step 9: The PC5 Relay RLC channel configuration received from the gNB-DU in Step 8 is forwarded to U2N Relay UE#3 via an RRCReconfiguration message. Additionally, the SRAP information for mapping / routing each SRAP Data PDU belonging to SRB0 / 1 to a specific egress PC5 Relay RLC channel, or the SRAP information for mapping / routing SRAP Data PDU transmitted through a specific ingress PC5 Relay RLC channel for SRB0 / 1 to a specific egress PC5 Relay RLC channel, can be allocated / configured to U2N Relay UE#3. The information can be allocated / configured per Local ID for U2N Remote UE.

[0324] - In the same manner, in the case where U2N Relay UE#3 received the PC5 Relay RLC channel configuration for SRB0 / 1 in the PC5 connection between U2N Relay UE#4 and U2N Relay UE#3 and / or between U2N Relay UE#3 and U2N Relay UE#2 in Step 9, it can perform the allocation / configuration for the PC5 Relay RLC channel in the corresponding PC5 connection by informing U2N Relay UE#4 and / or U2N Relay UE#2 of this through the RRC Reconfiguration Sidelink process. Because U2N Relay UE#3 already knows that U2N Relay UE#2 and / or U2N Relay UE#4 are in RRC_INACTIVE or RRC_IDLE state, it may perform the Reconfiguration Sidelink process for PC5 Relay RLC channel configuration allocation / configuration, or it may know that it must perform the Reconfiguration Sidelink process towards U2N Relay UE#2 and / or U2N Relay UE#4 by the request of the base station received in Step 9. Alternatively, in the case where it received the SRAP header configured as in FIG. 13 in Step 3, it may know that it must perform the Reconfiguration Sidelink process.

[0325] Step 10: After finishing the configuration according to the RRCReconfiguration message received in Step 9, U2N Relay UE#3 informs this by sending an RRCReconfigurationComplete message to the gNB-CU via the gNB-DU.

[0326] - Step 5~7 and Step 8~10 may be performed simultaneously / in parallel, alternatively they may be performed in a mutually swapped order.

[0327] Step 11: U2N Relay UE#3 delivers the RRCSetupRequest message received in Step 3 to U2N Relay UE#1. At this time, U2N Relay UE#3 can deliver the SRAP header by converting / updating it as follows as can be seen in [Ref #1], based on the information received in Step 3 and Step 9 (e.g., Local ID for U2N Remote UE, BEARER ID for SRB0, etc.). That is, if the L field is set to 1, it can inform that, in addition to the Local ID for U2N Remote UE, the L2 ID for U2N Remote UE is included additionally.

[0328] FIG. 14 shows an example of an SRAP PDU Format, according to some embodiments of the present disclosure.

[0329] In particular, FIG. 14 shows an SRAP PDU Format#2 for U2N Relay UE in RRC_IDLE or RRC_INACTIVE.

[0330] U2N Relay UEs existing between U2N Relay UE#3 and U2N Relay UE#1 store the mapping information for the Local ID and L2 ID for U2N Remote UE included in the SRAP header. In the case where the corresponding U2N Relay UE has information matching the Local ID for U2N Remote UE or L2 ID for U2N Remote UE information received from U2N Relay UE#3, it updates the existing information according to the newly received information. For example, in a situation where U2N Relay UE#2 already has Local ID for U2N Remote UE information related to a specific L2 ID for U2N Remote UE, if it received a Local ID for U2N Remote UE set with a different value for the same L2 ID for U2N Remote UE from U2N Relay UE#3, it deletes all existing information related to the L2 ID for U2N Remote UE and updates with the newly received information. Conversely, if the L2 ID for U2N Remote UE value previously stored by U2N Relay UE#2 for a specific Local ID for U2N Remote UE and the L2 ID for U2N Remote UE value received from U2N Relay UE#3 are different, it deletes all existing information related to the Local ID for U2N Remote UE and updates with the newly received information.

[0331] Step 12: U2N Relay UE#1 can configure the SRAP header as in the UE-to-Network Relay operation within TS 38.351 based on the information received in Step 6 and Step 11, and deliver it to the gNB-DU. That is, it can deliver to the gNB-DU together with the RRCSetupRequest message sent by the U2N Remote UE by configuring the SRAP header including only the Local ID for U2N Remote UE and the BEARER ID value.

[0332] FIG. 15 shows an example of an SRAP PDU Format, according to some embodiments of the present disclosure.

[0333] In particular, FIG. 15 shows an SRAP PDU Format for U2N Relay UE in Rel-17 single-hop relay operation.

[0334] - U2N Relay UE#1 may deliver the SRAP header configuration received in Step 11 to the gNB-DU as it is. That is, it is also possible to deliver the SRAP header including the Local ID and L2 ID for U2N Remote UE together with the RRCSetupRequest message to the gNB-DU.

[0335] Step 13: The gNB-DU can know that the U2N Remote UE is accessing the gNB-DU for the first time by looking at the BEARER ID (for example, SRB0) within the SRAP header received in Step 12. Alternatively, the gNB-DU can know that the U2N Remote UE is accessing through U2N Relay UE#1 based on the information such as the Uu Relay RLC channel through which the RRCSetupRequest message was delivered.

[0336] In the case where the gNB-DU judges that it can service the U2N Remote UE, it can deliver the lower layer configuration for the PC5 Relay RLC channel between the U2N Remote UE and the U2N Relay UE located at the first hop (for example, U2N Relay UE#4 in FIG. 12a and FIG. 12b) to the gNB-CU through the F1AP INITIAL UL RRC MESSAGE TRANSFER message by allocating / generating it. Alternatively, it stores / keeps the lower layer configuration information for the PC5 Relay RLC channel allocated / generated in this way within the U2N Remote UE's context inside the gNB-DU. Alternatively, the gNB-DU delivers together the gNB-DU UE F1AP ID for the U2N Relay UE located at the last hop (for example, U2N Relay UE#1) and the Local ID for U2N Remote UE included in the SRAP header received in Step 12 to the gNB-CU through the INITIAL UL RRC MESSAGE TRANSFER message.

[0337] The gNB-CU can know that the U2N Remote UE is accessing the base station through at least U2N Relay UE#3 and U2N Relay UE#1 based on the SidelinkUEInformationNR message received in Step 4 and the F1AP INITIAL UL RRC MESSAGE TRANSFER message received in Step 13, and can derive the gNB-DU UE F1AP ID and gNB-CU UE F1AP ID existing within the gNB-CU and gNB-DU, which respectively identify the UE context for U2N Relay UE#3 and U2N Relay UE#1, as follows.

[0338] - gNB-DU UE F1AP ID and gNB-CU UE F1AP ID for U2N Relay UE#1

[0339] - gNB-DU UE F1AP ID and gNB-CU UE F1AP ID for U2N Relay UE#3

[0340] - In the case where U2N Relay UE#1 delivered the SRAP header including the Local ID and L2 ID for U2N Remote UE together with the RRCSetupRequest message to the gNB-DU in Step 12, it is also possible to deliver the L2 ID for U2N Remote UE information together to the gNB-CU.

[0341] Step 14: In the case where the gNB-CU decides to create an RRC connection with the U2N Remote UE, it generates an RRCSetup message and delivers it to the gNB-DU through the F1AP DL RRC MESSAGE TRANSFER message. The gNB-CU can include, within the RRCSetup message, SRAP information for mapping each SRB and DRB to be used by the U2N Remote UE in the PC5 connection (for example, first PC5 connection) between the U2N Remote UE and U2N Relay UE#4 to a specific egress PC5 Relay RLC channel.

[0342] The gNB-DU delivers the RRCSetup message to U2N Relay UE#3 via U2N Relay UE#2 and U2N Relay UE#1 after configuring the SRAP header by referring to the SRB Mapping Info IE included in the F1AP DL RRC MESSAGE TRANSFER message. At this time, the SRAP header can be configured with the Local ID for U2N Remote UE and BEARER ID, as in the UE-to-Network Relay operation within TS 38.351.

[0343] Step 15: U2N Relay UE#3 delivers the RRCSetup message together with the SRAP header changed / updated to an SRAP header including the Local ID and L2 ID for U2N Remote UE as in FIG. 14, from the SRAP header received in Step 14, to U2N Relay UE#4.

[0344] Step 16: U2N Relay UE#4 delivers only the RRCSetup message without the SRAP header to the U2N Remote UE. In this process, it stores the mapping information for the Local ID and L2 ID for U2N Remote UE included in the SRAP header received in Step 15. In the same manner as in Step 11, in the case where U2N Relay UE#4 has information matching the Local ID for U2N Remote UE or L2 ID for U2N Remote UE information received from U2N Relay UE#3, it updates the existing information according to the newly received information. For example, in a situation where U2N Relay UE#4 already has Local ID for U2N Remote UE information related to a specific L2 ID for U2N Remote UE, if it received a Local ID for U2N Remote UE set with a different value for the same L2 ID for U2N Remote UE from U2N Relay UE#3, it deletes all existing information related to the L2 ID for U2N Remote UE and stores the newly received information. Conversely, if the L2 ID for U2N Remote UE value previously stored by U2N Relay UE#4 for a specific Local ID for U2N Remote UE and the L2 ID for U2N Remote UE value received from U2N Relay UE#3 are different, it deletes all existing information related to the Local ID for U2N Remote UE and stores the newly received information.

[0345] Step 17: If the PC5 / Uu Relay RLC channel for delivering the SRB1 message of the U2N Remote UE was not allocated / configured to U2N Relay UE#1 and U2N Relay UE#3 in Step 5~10, the gNB-CU requests the allocation / configuration of the PC5 Relay RLC channel configuration for the PC5 connection between U2N Relay UE#1 and U2N Relay UE#2 and / or the Uu Relay RLC channel configuration between U2N Relay UE#1 and the gNB-DU for delivering the SRB1 message to the gNB-DU through the F1AP UE Context Modification procedure in Step 17a.

[0346] In order to deliver the PC5 / Uu Relay RLC channel configuration received from the gNB-DU in Step 17a to U2N Relay UE#1, it executes the RRC Reconfiguration process as in Step 17b.

[0347] Step 18: If the PC5 Relay RLC channel for delivering the SRB1 message of the U2N Remote UE was not allocated / configured to U2N Relay UE#3, the gNB-CU requests the allocation / configuration of the PC5 Relay RLC channel configuration for the PC5 connection between U2N Relay UE#2 and U2N Relay UE#3 and / or the PC5 Relay RLC channel configuration for the PC5 connection between U2N Relay UE#3 and U2N Relay UE#4 for delivering the SRB1 message to the gNB-DU through the F1AP UE Context Modification procedure in Step 18a.

[0348] In order to deliver the PC5 Relay RLC channel configuration received from the gNB-DU in Step 18a to U2N Relay UE#3, it executes the RRC Reconfiguration process as in Step 18b.

[0349] Step 19: After finishing the Bearer allocation / configuration and / or PC5 Relay RLC channel allocation / configuration, etc., to be used in the RRC connection with the base station according to the RRCSetup message received in Step 16, the U2N Remote UE informs this by sending an RRCSetupComplete message to the base station. The U2N Remote UE includes the Registration Request message together in the RRCSetupComplete message for registration to the network.

[0350] Based on the information received in Step 16, the U2N Remote UE configures the SRAP header with the BEARER ID and Local ID for U2N Remote UE, and delivers it together with the RRCSetupComplete message to the base station via the U2N Relay UEs.

[0351] Step 20: The remaining processes among the Remote UE Initial Access procedure (for example, a procedure of FIG. 9a, FIG. 9b, and FIG. 9c) are executed.

[0352] In the Embodiment 1, it was assumed that U2N Relay UE#3 uses the SRAP header structure as in FIG. 14 while transmitting the RRCSetupRequest message of the U2N Remote UE in Step 11, alternatively it is also possible to use the SRAP header structure as in FIG. 13. That is, it is possible for U2N Relay UE#3 to use the SRAP header sent by U2N Relay UE#4 as it is, rather than converting / rewriting the SRAP header in Step 11. In this case, as described in Embodiment 2, it is also possible for U2N Relay UE#1 or the gNB-DU to use the SRAP header structure as in FIG. 14 while transmitting the RRCSetup message.

[0353] Alternatively, in Step 11 of Embodiment 1, U2N Relay UE#3 in RRC_CONNECTED state may use the SRAP header structure as in FIG. 15. However, in the case where a local ID that was allocated to U2N Remote UE#A (which is currently in RRC_INACTIVE or RRC_IDLE state) is reallocated / reused for U2N Remote UE#B (which is currently in RRC_CONNECTED state), using the existing information (e.g., PC5 Relay RLC channel configuration, information for mapping / routing SRBs and DRBs related to local ID for U2N Remote UE#A to a specific egress PC5 / Uu Relay RLC channel, etc.) allocated / configured by U2N Relay UE#2 in RRC_INACTIVE or RRC_IDLE state to service U2N Remote UE#A for U2N Remote UE#B must be avoided. For this, a process of deleting the UE context for U2N Remote UE#A that was being stored in U2N Relay UEs is necessary in the process where U2N Remote UE#A transitions to RRC_INACTIVE or RRC_IDLE state. Alternatively, in the case where the Local ID for U2N Remote UE information previously stored and the Local ID information received from U2N Relay UE#3 are the same, U2N Relay UE#2 in RRC_INACTIVE alternatively RRC_IDLE state can avoid the error of servicing U2N Remote UE#B based on the information related to U2N Remote UE#A by deleting all the existing information related to the Local ID for U2N Remote UE.

[0354] Embodiment 2:U2NRemoteUE'sinitial access via all otherU2NRelay UEs in RRC_INACTIVE / RRC_IDLE andU2NRelayUE#1 in RRC_CONNECTED

[0355] Among the proposed contents below, the description or operation for U2N Relay UE#4 (for example, 4-hop U2N Relay UE) can also be applied to U2N Relay UEs of 2-hop or more hops (for example, intermediate UE-to-Network Relay UE).

[0356] FIG. 16a and FIG. 16b show an example of a method for support of multi-hop relay UE, according to some embodiments of the present disclosure.

[0357] In FIG. 16a and FIG. 16b, it is assumed that U2N Relay UE#2, U2N Relay UE#3, and U2N Relay UE#4 are all in RRC_IDLE or RRC_INACTIVE state.

[0358] Step 1~2: Step 1~2 of FIG. 12a and FIG. 12b can be referred to.

[0359] Step 3: U2N Relay UE#4, which is in RRC_IDLE or RRC_INACTIVE state, can deliver the SRAP header to U2N Relay UE#3 together with the RRCSetupRequest message by configuring it as in FIG. 13. Alternatively, in Step 2, in order for the U2N Remote UE to inform the U2N Relay UEs in RRC_INACTIVE or RRC_IDLE state of the L2 ID for U2N Remote UE, it delivers the SRAP header to U2N Relay UE#4 together with the RRCSetupRequest message after configuring it as in FIG. 13, and U2N Relay UE#4 in RRC_INACTIVE or RRC_IDLE state can deliver this to U2N Relay UE#3.

[0360] Step 4: It is assumed that, in the case where U2N Relay UE#1 is in RRC_IDLE or RRC_INACTIVE state, it first transitions to RRC_CONNECTED state in order to deliver the RRCSetupRequest message received from the U2N Remote UE to the base station.

[0361] U2N Relay UE#1 in RRC_CONNECTED state, in order to deliver the RRCSetupRequest message received from U2N Relay UE#2 to the base station, sends a SidelinkUEInformationNR message to the base station and requests the allocation / configuration of the Local ID for the U2N Remote UE, the PC5 / Uu Relay RLC channel configuration necessary for transmitting SRB0 / 1 messages for the U2N Remote UE, etc. In this process, U2N Relay UE#1 can deliver together the L2 ID for U2N Remote UE information received in Step 3 and its own L2 ID.

[0362] The gNB-CU having received the SidelinkUEInformationNR message allocates / configures the local ID for the U2N Remote UE. As in the UE-to-Network Relay operation within TS 38.351, it can route the data and / or signaling of the U2N Remote UE through the local ID allocated / configured in Step 4 in all sections between the U2N Remote UE and the base station. For this, it is also possible to use the Local ID value (for example, INTEGER (0..255)) defined in TS 38.331 as follows, alternatively, a separate Local ID for Multi-hop U2N Relay operation may be defined to distinguish it from the existing Single-hop U2N Relay operation.

[0363] Step 5~7: Step 5~7 of FIG. 12a and FIG. 12b can be referred to.

[0364] Step 8: U2N Relay UE#1 can configure the SRAP header as in the UE-to-Network Relay operation within TS 38.351 based on the information received in Step 6, and deliver it to the gNB-DU. That is, as in FIG. 15, it can deliver to the gNB-DU together with the RRCSetupRequest message sent by the U2N Remote UE by configuring the SRAP header including only the Local ID for U2N Remote UE and the BEARER ID value.

[0365] - U2N Relay UE#1 may deliver to the gNB-DU together with the RRCSetupRequest message by configuring the SRAP header as in FIG. 14. That is, it is also possible to deliver the SRAP header including the Local ID and L2 ID for U2N Remote UE together with the RRCSetupRequest message to the gNB-DU.

[0366] Step 9: The gNB-DU can know that the U2N Remote UE is accessing the gNB-DU for the first time by looking at the BEARER ID (for example, SRB0) within the SRAP header received in Step 8. Alternatively, the gNB-DU can know that the U2N Remote UE is accessing through U2N Relay UE#1 based on the information such as the Uu Relay RLC channel through which the RRCSetupRequest message was delivered.

[0367] In the case where the gNB-DU judges that it can service the U2N Remote UE, it can deliver the lower layer configuration for the PC5 Relay RLC channel between the U2N Remote UE and the U2N Relay UE located at the first hop (for example, U2N Relay UE#4 in FIG. 16a and FIG. 16b) to the gNB-CU through the F1AP INITIAL UL RRC MESSAGE TRANSFER message by allocating / generating it. Alternatively, it stores / keeps the lower layer configuration information for the PC5 Relay RLC channel allocated / generated in this way within the U2N Remote UE's context inside the gNB-DU. Alternatively, the gNB-DU delivers together the gNB-DU UE F1AP ID for the U2N Relay UE located at the last hop (for example, U2N Relay UE#1) and the Local ID for U2N Remote UE included in the SRAP header received in Step 8 to the gNB-CU through the INITIAL UL RRC MESSAGE TRANSFER message.

[0368] The gNB-CU can know that the U2N Remote UE is accessing the base station through at least U2N Relay UE#1 based on the SidelinkUEInformationNR message received in Step 4 and the F1AP INITIAL UL RRC MESSAGE TRANSFER message received in Step 9, and can derive the gNB-DU UE F1AP ID and gNB-CU UE F1AP ID existing within the gNB-CU and gNB-DU, which identify the UE context for U2N Relay UE#1, as follows.

[0369] - gNB-DU UE F1AP ID and gNB-CU UE F1AP ID for U2N Relay UE#1

[0370] - In the case where U2N Relay UE#1 delivered the SRAP header including the Local ID and L2 ID for U2N Remote UE together with the RRCSetupRequest message to the gNB-DU in Step 8, it is also possible to deliver the L2 ID for U2N Remote UE information together to the gNB-CU.

[0371] - The gNB-CU can implicitly know the fact that U2N Relay UEs currently in RRC_IDLE or RRC_INACTIVE state exist between the U2N Remote UE and U2N Relay UE#1 through the information on the number of U2N Relay UEs involved in the Multi-hop relay operation (for example, Number of hops (n)), the number of U2N Relay UEs currently in RRC_CONNECTED state, and information on the peer UE with which the U2N Relay UE currently in RRC_CONNECTED state is forming a PC5 connection, etc.; however, the gNB-CU does not have the UE contexts related to the corresponding U2N Relay UEs. For example, based on the SidelinkUEInformationNR message sent by U2N Relay UE#1, the gNB-CU can know that U2N Relay UE#1 has a PC5 connection with U2N Relay UE#2. Alternatively, the gNB-CU can know that the U2N Remote UE has a PC5 connection with U2N Relay UE#4 based on the SidelinkUEInformationNR message sent by the U2N Remote UE after it transitions to RRC_CONNECTED state.

[0372] Step 10: In the case where the gNB-CU decides to create an RRC connection with the U2N Remote UE, it generates an RRCSetup message and delivers it to the gNB-DU through the F1AP DL RRC MESSAGE TRANSFER message. The gNB-CU can include, within the RRCSetup message, SRAP information for mapping each SRB and DRB to be used by the U2N Remote UE in the first PC5 connection (for example, the PC5 connection between the U2N Remote UE and U2N Relay UE#4) to a specific egress PC5 Relay RLC channel.

[0373] In the case where the gNB-CU comes to know the fact in Step 9 that U2N Relay UEs currently in RRC_IDLE or RRC_INACTIVE state exist between the U2N Remote UE and U2N Relay UE#1, it delivers the L2 ID for U2N Remote UE information by including it together in the F1AP DL RRC MESSAGE TRANSFER message.

[0374] Step 11: In the case where the L2 ID for U2N Remote UE information is included in the F1AP DL RRC MESSAGE TRANSFER message, the gNB-DU delivers the RRCSetup message to U2N Relay UE#4 via U2N Relay UE#3, U2N Relay UE#2, and U2N Relay UE#1 after configuring the SRAP header as in FIG. 14.

[0375] In this process, the U2N Relay UEs located between U2N Relay UE#1 and U2N Relay UE#4 store the mapping information for the Local ID and L2 ID for U2N Remote UE included in the SRAP header. In the case where U2N Relay UE#3 has information matching the Local ID for U2N Remote UE or L2 ID for U2N Remote UE information received from U2N Relay UE#2, it updates the existing information according to the newly received information. For example, in a situation where U2N Relay UE#3 already has Local ID for U2N Remote UE information related to a specific L2 ID for U2N Remote UE, if it received a Local ID for U2N Remote UE set with a different value for the same L2 ID for U2N Remote UE from U2N Relay UE#2, it deletes all existing information related to the L2 ID for U2N Remote UE and stores the newly received information. Conversely, if the L2 ID for U2N Remote UE value previously stored by U2N Relay UE#3 for a specific Local ID for U2N Remote UE and the L2 ID for U2N Remote UE value received from U2N Relay UE#3 are different, it deletes all existing information related to the Local ID for U2N Remote UE and stores the newly received information. However, in the case where the Local ID and L2 ID for U2N Remote UE previously stored and the values newly received in the Step 11 process are the same, it is also possible to use the existing information related to the corresponding mapping (e.g., PC5 Relay RLC channel configuration, information for mapping / routing SRBs and DRBs related to local ID for U2N Remote UE to a specific egress PC5 / Uu Relay RLC channel, etc.) as it is, or it is also possible to use it by newly generating / allocating it by the U2N Relay UE itself.

[0376] - Even if the gNB-CU does not include the L2 ID for U2N Remote UE information in the F1AP DL RRC MESSAGE TRANSFER message, in the case where the SRAP header including the L2 ID for U2N Remote UE information was received from U2N Relay UE#1 in Step 8, it is also possible for the gNB-DU to configure the SRAP header including the Local ID and L2 ID for U2N Remote UE information as in FIG. 14.

[0377] Step 12: U2N Relay UE#4 delivers only the RRCSetup message without the SRAP header to the U2N Remote UE.

[0378] Step 13: If the PC5 / Uu Relay RLC channel for delivering the SRB1 message of the U2N Remote UE was not allocated / configured to U2N Relay UE#1 in Step 5~7, the gNB-CU requests the allocation / configuration of the PC5 Relay RLC channel configuration for the PC5 connection between U2N Relay UE#1 and U2N Relay UE#2 and / or the Uu Relay RLC channel configuration between U2N Relay UE#1 and the gNB-DU for delivering the SRB1 message to the gNB-DU through the F1AP UE Context Modification procedure in Step 13a.

[0379] In order to deliver the PC5 / Uu Relay RLC channel configuration received from the gNB-DU in Step 13a to U2N Relay UE#1, it executes the RRC Reconfiguration process as in Step 13b.

[0380] Step 14: After finishing the Bearer allocation / configuration and / or PC5 Relay RLC channel allocation / configuration, etc., to be used in the RRC connection with the base station according to the RRCSetup message received in Step 12, the U2N Remote UE informs this by sending an RRCSetupComplete message to the base station. The U2N Remote UE includes the Registration Request message together in the RRCSetupComplete message for registration to the network.

[0381] Based on the information received in Step 12, the U2N Remote UE configures the SRAP header with the BEARER ID and Local ID for U2N Remote UE, and delivers it together with the RRCSetupComplete message to the base station via the U2N Relay UEs.

[0382] Step 15: The remaining processes among the Remote UE Initial Access procedure (for example, a procedure of FIG. 9a, FIG. 9b, and FIG. 9c) are executed.

[0383] Embodiment 3:U2NRelayUE'sstate transition to RRC_CONNECTED

[0384] In the Embodiment 1, it is assumed that U2N Relay UE#2 and U2N Relay UE#4 are in RRC_IDLE or RRC_INACTIVE state, and in Embodiment 2, it is assumed that U2N Relay UE#2, U2N Relay UE#3, and U2N Relay UE#4 are in RRC_IDLE or RRC_INACTIVE state. It is possible for the U2N Relay UEs to transition to RRC_CONNECTED state in order to transmit / receive their own traffic through the network during the Multi-hop relay operation. In this case, it is possible for the U2N Relay UE to execute Embodiment 1 or Embodiment 2 as another U2N Remote UE. After transitioning to RRC_CONNECTED state, the U2N Relay UE can deliver the L2 ID being used in the Multi-hop relay operation together with the L2 ID to be used as a U2N Remote UE while sending a SidelinkUEInformationNR message to the base station. Through this, the base station can know that it is operating as the U2N Relay UE. Alternatively, it is also possible for the U2N Relay UE to explicitly inform the base station that it is performing the Multi-hop relay operation.

[0385] Alternatively, the U2N Relay UE may also deliver part or all of the following information together to the base station during the Multi-hop relay operation.

[0386] - L2 ID and / or Local ID list of the U2N Remote UEs connected through the U2N Relay UE

[0387] - QoS information allocated / configured by the U2N Relay UE in order to service the U2N Remote UEs connected through the U2N Relay UE

[0388] - PC5 Relay RLC channel configuration allocated / configured by the U2N Relay UE in order to service the U2N Remote UEs connected through the U2N Relay UE

[0389] - Information for mapping / routing the SRB and DRB of the U2N Remote UE to a specific egress PC5 / Uu Relay RLC channel, allocated / configured by the U2N Relay UE in order to service the U2N Remote UEs connected through the U2N Relay UE

[0390] The base station can allocate / configure information necessary to service the U2N Remote UEs connected through the U2N Relay UE based on the corresponding information (e.g., PC5 Relay RLC channel configuration(s), information for mapping / routing the SRB and DRB related to local ID(s) for U2N Remote UE(s) to a specific egress PC5 / Uu Relay RLC channel, etc.). If the base station is divided into gNB-CU and gNB-DU, the gNB-CU can request the allocation / configuration of information necessary to service the U2N Remote UEs (e.g., PC5 Relay RLC channel configuration(s), etc.) by providing part or all of the information received from the U2N Relay UE transitioning to RRC_CONNECTED state to the gNB-DU, and the gNB-DU can perform the requested allocation / configuration operation based on the information provided by the gNB-CU.

[0391] Embodiment 4:U2NRemoteUE'sstate transition to RRC_IDLE or RRC_INACTIVE

[0392] In the case where the base station transitions the U2N Remote UE, which became RRC_CONNECTED state through the Embodiment 1 or Embodiment 2 or Embodiment 3, to RRC_IDLE or RRC_INACTIVE state, the base station can transmit together an SRAP header configured with the Local ID for U2N Remote UE and / or L2 ID for U2N Remote UE while sending an RRCRelease message to the U2N Remote UE. Alternatively, the base station can add a bit within the SRAP header requesting the deletion of the information that the U2N Relay UEs in RRC_IDLE or RRC_INACTIVE state, located between the base station and the U2N Remote UE, are storing inside the U2N Relay UEs in relation to the Local ID for U2N Remote UE and / or L2 ID for U2N Remote UE. If the base station is divided into gNB-CU and gNB-DU, the gNB-CU can deliver a request to add the bit within the SRAP header together with the RRCRelease message to the gNB-DU.

[0393] Alternatively, it is also possible for the base station to transmit an SRAP Control PDU requesting to delete the UE context related to a specific Local ID for U2N Remote UE and / or L2 ID for U2N Remote UE to the U2N Relay UEs in RRC_IDLE or RRC_INACTIVE state. If the base station is divided into gNB-CU and gNB-DU, the gNB-CU can deliver the transmission request of the SRAP Control PDU together with the RRCRelease message to the gNB-DU.

[0394] Alternatively, if an SRAP Data PDU including a specific Local ID for U2N Remote UE and / or L2 ID for U2N Remote UE is not transmitted for a certain period of time, it is also possible for the U2N Relay UEs in RRC_IDLE or RRC_INACTIVE state themselves to delete the UE context related to the specific Local ID for U2N Remote UE and / or L2 ID for U2N Remote UE. The corresponding timer value may be allocated / configured from the base station through SIB, RRC message, SRAP Data PDU, SRAP Control PDU, etc., or it may be pre-configured inside the U2N Relay UE. If the timer information is delivered to the U2N Relay UE through an SRAP Data PDU or SRAP Control PDU, the gNB-CU may also request the gNB-DU to include the timer information within the SRAP Data PDU or SRAP Control PDU.

[0395] In the Embodiment 1, it is assumed that U2N Relay UE#3 is in RRC_CONNECTED state. The base station can decide to transition the U2N Relay UE#3 to RRC_IDLE or RRC_INACTIVE state. Therefore, the base station can apply the Embodiment 4 by considering the U2N Relay UE#3 as a U2N Remote UE. Alternatively, since the base station can already know the L2 ID and Local ID list of the U2N Remote UE connected through the U2N Relay UE#3 through the Embodiment 1 or Embodiment 2 or Embodiment 3, it can request the U2N Relay UE#3 to delete the information (e.g., PC5 Relay RLC channel configuration(s), information for mapping / routing the SRB and DRB related to local ID(s) for U2N Remote UE(s) to a specific egress PC5 / Uu Relay RLC channel, etc.) that the base station had allocated / configured to U2N Relay UE#3 in order to service the U2N Remote UEs connected through the U2N Relay UE#3. Alternatively, the base station can request U2N Relay UE#3 to allocate / configure themselves the information (e.g., PC5 Relay RLC channel configuration(s), information for mapping / routing the SRB and DRB related to local ID(s) for U2N Remote UE(s) to a specific egress PC5 / Uu Relay RLC channel, etc.) for servicing the U2N Remote UEs by performing the role of a U2N Relay UE in RRC_IDLE or RRC_INACTIVE state.

[0396] The base station can deliver to the U2N Relay UE#3 by including an indication related to the request in the RRCRelease message or adding it within the SRAP header. Alternatively, it may deliver it to the U2N Relay UE#3 through an SRAP Control PDU related to the request. If the base station is divided into gNB-CU and gNB-DU and the request is delivered to the U2N Relay UE#3 through an SRAP Data PDU or SRAP Control PDU, the gNB-CU can request the gNB-DU, together with the RRCRelease message, to add the indication related to the request within the SRAP header or transmit the SRAP Control PDU related to the request.

[0397] Unlike what was described in the Embodiment 1 to Embodiment 4, by considering the number of hops from the Remote UE, it is also possible to refer to U2N Relay UE#4 as 1-hop U2N Relay UE (or the first U2N Relay UE or #1 U2N Relay UE or hop#1 U2N Relay UE), refer to U2N Relay UE#3 as 2-hop U2N Relay UE (or the second U2N Relay UE or #2 U2N Relay UE or hop#2 U2N Relay UE), refer to U2N Relay UE#2 as 3-hop U2N Relay UE (or the third U2N Relay UE or #3 U2N Relay UE or hop#3 U2N Relay UE), and refer to U2N Relay UE#1 as 4-hop U2N Relay UE (or the fourth U2N Relay UE or #4 U2N Relay UE or hop#4 U2N Relay UE or last hop U2N Relay UE).

[0398] According to some embodiments of the present disclosure, a U2N Relay UE in RRC_CONNECTED state or the gNB-DU can inform U2N Relay UEs in RRC_IDLE or RRC_INACTIVE state participating in multi-hop U2N relaying of the information on the Local ID and L2 ID combination for the U2N Remote UE. The gNB-CU can inform the gNB-DU of the SRAP header structure that must be used during SRB / DRB transmission of the U2N Remote UE.

[0399] In the case where U2N Relay UEs in RRC_IDLE or RRC_INACTIVE state participating in Multi-hop relay operation transition to RRC_CONNECTED state, they can deliver L2 ID and / or Local ID information for the U2N Remote UE being serviced through the U2N Relay UEs to the base station, and the base station can allocate information necessary in the process of servicing the U2N Remote UE (e.g., PC5 Relay RLC channel configuration(s), information for mapping / routing the SRB and DRB related to local ID(s) for U2N Remote UE(s) to a specific egress PC5 / Uu Relay RLC channel, etc.) to the U2N Relay UE based on the information.

[0400] In the case where a U2N Remote UE in RRC_CONNECTED state transitions to RRC_IDLE or RRC_INACTIVE state, the base station can request U2N Relay UEs in RRC_IDLE or RRC_INACTIVE state participating in Multi-hop relay operation to delete the Local ID-related information allocated to the U2N Remote UE.

[0401] Hereinafter, technical features related to F1 support for multiplexing of PC5 relay RLC channel in Multi-Hop (MH) relay are described.

[0402] In the present disclosure, a method is presented for multiplexing SRBs and / or DRBs of a new Remote UE and / or Relay UE into the existing PC5 Relay RLC channel allocated / configured to existing UEs (for example, Remote UE and / or Relay UE) in a CU-DU split environment. That is, in the case where the gNB-CU decides to multiplex the SRBs and / or DRBs of the new Remote UE and / or Relay UE into the existing PC5 Relay RLC channel allocated / configured to the existing UEs (for example, Remote UE and / or Relay UE), a method is presented for the gNB-CU to deliver information about the UEs (for example, Remote UE and / or Relay UE) to be additionally multiplexed into the existing PC5 Relay RLC channel to the gNB-DU. Alternatively, a method is presented for the gNB-DU to identify the UE that transmitted the RRCSetupRequest message delivered by the Last Relay UE (for example, the U2N Relay UE directly connected to the base station) by using the information received from the gNB-CU.

[0403] Embodiment 5:U2NRemoteUEinitial access by using allU2NRelayUEsin RRC_CONNECTED

[0404] The proposed content below, the description or operation for U2N Relay UE#3 (for example, 3-hop U2N Relay UE), can also be applied to a U2N Relay UE of 2-hop or more hops (for example, intermediate UE-to-Network Relay UE).

[0405] FIG. 17a, FIG. 17b, and FIG. 17c show an example of a method for F1 support of multi-hop relay UE, according to some embodiments of the present disclosure.

[0406] In particular, FIG. 17a, FIG. 17b, and FIG. 17c show a procedure on U2N Remote UE's initial access via Multi-hop U2N Relay operation.

[0407] In the present disclosure, it is assumed that a UE can not only perform a relay role (Intermediate U2N Relay role or U2N Relay role directly connected to the base station via Uu) so that a U2N Remote UE receives network connection service, but also can perform communication with the network through another U2N Relay in order to receive connection service to the network themselves (for example, to transmit / receive their own traffic through the network) (for example, can perform the U2N Remote UE role). In particular, the UE can simultaneously perform the Intermediate U2N Relay role and the U2N Remote UE role. This can be applied throughout this specification.

[0408] In FIG. 17a, FIG. 17b, and FIG. 17c, U2N Relay UE#2 can not only perform the Intermediate U2N Relay role so that the U2N Remote UE receives network connection service, but also can perform communication with the network through U2N Relay UE#1 in order to receive connection service to the network themselves. In addition, the U2N Remote UE can not only perform the Intermediate U2N relay role so that a New U2N Remote UE receives network connection service, but also can perform communication with the network through U2N Relay UE#1 and U2N Relay UE#2 in order to receive connection service to the network themselves.

[0409] Step 1: The U2N Remote UE discovers a U2N Relay UE that can provide connection to the network. In FIG. 17a, FIG. 17b, and FIG. 17c, it is assumed that it is connected with the base station through U2N Relay UE#1 and U2N Relay UE#2, but it is applicable also to a situation where it is connected to the network through n U2N Relay UEs (for example, n-hop).

[0410] In this process, serving cell information of the U2N Relay UE and information for accessing the corresponding cell to be used / referenced in (re)selecting the U2N Relay UE can be delivered together to the U2N Remote UE. The means the serving cell information of U2N Relay UE#1, and it is also possible to deliver together the serving cell information of other U2N Relay UEs (for example, U2N Relay UE#2) to the U2N Remote UE. Regarding the existing input parameters used / delivered in the Discovery process, TS 23.304 can be referenced. In addition, part or all of the following information may additionally be exchanged / delivered in the Discovery process.

[0411] - Number of hops (n): The number of U2N Relay UEs necessary for the U2N Remote UE to be connected to the network

[0412] - Information regarding each node involved in the network connection (e.g., User Info ID) and the L2 ID of each node (for example, L2 IDs for U2N Remote UE, U2N Relay UE#1, and U2N Relay UE#2)

[0413] In addition, the U2N Remote UE first creates a new PC5 connection with U2N Relay UE#2 or changes / updates the existing PC5 connection for connection to the network. In FIG. 17a, FIG. 17b, and FIG. 17c, it is assumed that the U2N Remote UE transmits a Direct Communication Request message to U2N Relay UE#2 in order to create a new PC5 connection. Equally, U2N Relay UE#2 sequentially transmits the Direct Communication Request message toward U2N Relay UE#1.

[0414] U2N Relay UE#1, having received the Direct Communication Request message, responds with a Direct Communication Accept message in the case of accepting the creation or change / update of the PC5 connection with U2N Relay UE#2. Equally, U2N Relay UE#2 sequentially transmits the Direct Communication Accept message toward the U2N Remote UE.

[0415] Unlike the aforementioned, unicast links can be formed between the U2N Remote UE and U2N Relays in various ways. For example, unicast links can be formed hop-by-hop (for example, U2N Remote UE and U2N Relay UE#2 form a unicast link, U2N Relay UE#2 and U2N Relay UE#1 form a unicast link), and the U2N Remote UE and U2N Relay UE#1 can form an end-to-end unicast link. This can be applied throughout this specification.

[0416] Regarding the existing input parameters included in the Direct Communication Request / Direct Communication Accept message, TS 23.304 can be referenced.

[0417] Step 2: The U2N Remote UE attempts to create an RRC connection by sending an RRCSetupRequest message toward the base station through U2N Relay #2. In addition, for the transmission / reception of the SRB0 message (for example, RRCSetupRequest, RRCSetup, etc.) of the U2N Remote UE, an existing defined PC5 Relay RLC channel configuration (for example, SL-RLC0) may be used, or a separate PC5 Relay RLC channel configuration for Multi-hop U2N relay operation (for example, SL-RLCx for SRB0 message transmission) may be newly defined.

[0418] A U2N Remote UE supporting Multi-hop relay operation can deliver only the SRB0 message (for example, RRCSetupRequest message) to U2N Relay UE#2 without any SRAP header, equally to the operation of the Rel-17 U2N Remote UE described in TS 38.351.

[0419] Step 3: If U2N Relay UE#2 is in RRC_IDLE or RRC_INACTIVE state, after receiving the RRCSetupRequest message of the U2N Remote UE, it transitions to RRC_CONNECTED state using the procedure of Remote UE initial access or Remote UE RRC Inactive to other states (for example, procedure of FIGS. 9a ~ 9c, or FIGS. 10a ~ 10b). In this process, the base station allocates a local ID for U2N Relay UE#2 that has accessed the network in the capacity of a U2N Remote UE, and allocates / configures information for mapping / routing the SRB and DRB related to the local ID for U2N Relay UE#2 to a specific egress PC5 / Uu Relay RLC channel to U2N Relay UE#2 and U2N Relay UE#1.

[0420] Prior to Step 3, U2N Relay UE#2 may already be in a state of having transitioned to RRC_CONNECTED state using the procedure of the procedure of Remote UE initial access or Remote UE RRC Inactive to other states (for example, procedure of FIGS. 9a ~ 9c, or FIGS. 10a ~ 10b).

[0421] Step 4: U2N Relay UE#2 sends a SidelinkUEInformationNR message to the base station (for example, to the gNB-CU via the gNB-DU) to request the configuration / creation of a Uu Relay RLC channel for transmitting the RRCSetupRequest message of the U2N Remote UE. Since the gNB already knows that U2N Relay UE#2 is accessing through U2N Relay UE#1, it may implicitly know that the entire path of the U2N Remote UE accessing the gNB through U2N Relay UE#2 has been formed as U2N Remote UE -> U2N Relay UE#2 -> U2N Relay UE#1 -> gNB.

[0422] In addition, the gNB-CU, having received the SidelinkUEInformationNR message, allocates / configures a local ID for the U2N Remote UE. As in the UE-to-Network Relay operation within TS 38.351, the data and / or signaling of the U2N Remote UE can be routed through the local ID allocated / configured in Step 4 in all sections between the U2N Remote UE and the base station. For this, a Local ID value defined in TS 38.331 (for example, INTEGER (0..255)) may be used as follows, but a separate Local ID for Multi-hop U2N Relay operation may be defined in order to distinguish it from the existing Single-hop U2N Relay operation. Alternatively, it is also possible to separately configure / allocate a Local ID for DL to be used in routing DL data and / or signaling that the base station transmits to the U2N Remote UE, and a Local ID for UL to be used in routing UL data and / or signaling that the U2N Remote UE transmits to the base station.

[0423] Step 5: The gNB-CU delivers the SidelinkUEInformationNR message received in Step 4 to the gNB-DU through the F1AP UE CONTEXT MODIFICATION REQUEST message of U2N Relay UE#1. In addition, the gNB-CU can request the gNB-DU for the allocation / configuration of the Uu Relay RLC channel configuration necessary to transmit the SRB0 / 1 message for the U2N Remote UE. The gNB-DU allocates / configures the Uu Relay RLC channel configuration and responds to the gNB-CU through the F1AP UE CONTEXT MODIFICATION RESPONSE message. In the case where the gNB-CU decides to transmit by multiplexing together the SRB0 / 1 message of the U2N Remote UE into the Uu Relay RLC channel configuration allocated / configured for another UE (for example, another Relay UE and / or another Remote UE), the gNB-CU may not include the Uu Relay RLC channel configuration allocation / configuration request within the UE CONTEXT MODIFICATION REQUEST message.

[0424] Additionally, the gNB-CU may request the gNB-DU for the allocation / configuration of the PC5 Relay RLC channel configuration between U2N Relay UE#2 and U2N Relay UE#1 necessary to transmit the SRB0 / 1 message for the U2N Remote UE through the F1AP UE CONTEXT MODIFICATION REQUEST message. In this case, the gNB-CU delivers the Local ID for U2N Remote UE together to inform the gNB-DU that it is a PC5 Relay RLC channel for the U2N Remote UE. In the Step 10 process, the gNB-DU may compare this with the Local ID for U2N Remote UE included in the SRAP header received in Step 9 and know that the U2N Remote UE is accessing the gNB-DU via U2N Relay UE#2 and U2N Relay UE#1. In the case where the gNB-CU decides to transmit by multiplexing together the SRB0 / 1 message of the U2N Remote UE into the PC5 Relay RLC channel configuration allocated / configured for another UE (for example, another Relay UE and / or another Remote UE), the gNB-CU may include information regarding the UE (for example, Remote UE and / or Relay UE) that will together use / utilize the existing PC5 Relay RLC channel configuration instead of requesting the allocation / configuration of a new PC5 Relay RLC channel configuration within the UE CONTEXT MODIFICATION REQUEST message. For example, by including the Additional Remote UE Local ID List IE within the PC5 RLC Channel to Be Modified List IE of the UE CONTEXT MODIFICATION REQUEST message in TS 38.473, the gNB-DU can know that the corresponding PC5 Relay RLC channel must be multiplexed also for the U2N Remote UE(s) included within the Additional Remote UE Local ID List IE.

[0425] Technical features related to UE CONTEXT MODIFICATION REQUEST message is as below:

[0426] This message is sent by the gNB-CU to provide UE Context information changes to the gNB-DU. (Direction: gNB-CU -> gNB-DU)

[0427] Table 3 shows examples of IE included in the UE CONTEXT MODIFICATION REQUEST message.

[0428] IE / Group NamePresenceRangeIE type and referenceSemantics descriptionCriticalityAssigned CriticalityPC5 RLC Channel to Be Setup List0..1YESreject>PC5 RLC Channel to be Setup Item IEs1 .. <maxnoofPC5RLCChannels>->>PC5 RLC Channel IDM9.3.1.265->>Remote UE Local IDO9.3.1.267->>CHOICE PC5 RLC Channel QoS InformationM->>>PC5 RLC Channel QoS>>>>PC5 RLC Channel QoSMQoS Flow Level QoS Parameters9.3.1.45->>>PC5 Control Plane Traffic Type>>>>PC5 Control Plane Traffic TypeMENUMERATED(SRB1, SRB2, ..)This IE indicates the type of SRB conveyed via the PC5 Relay RLC Channel.->>>U2U RLC Channel QoSYESreject>>>>U2U RLC Channel QoSMPC5 QoS Parameters9.3.1.122->>RLC ModeM9.3.1.27->>Peer UE IDOBIT STRING (SIZE(24))Corresponds to information provided in the sl-DestinationIdentityL2-U2U contained in the SL-TxResourceReqL2-U2U IE, defined in TS 38.331.This IE is included if the gNB-CU UE F1AP ID and / or gNB-DU UE F1AP ID are associated with a L2 U2U Remote UE or L2 U2U Relay UE.YESrejectPC5 RLC Channel to Be Modified List0..1YESreject>PC5 RLC Channel to be Modified Item IEs1 .. <maxnoofPC5RLCChannels>->>PC5 RLC Channel IDM9.3.1.265->>Remote UE Local IDO9.3.1.267>>CHOICE PC5 RLC Channel QoS InformationO->>>PC5 RLC Channel QoS>>>>PC5 RLC Channel QoSMQoS Flow Level QoS Parameters9.3.1.45->>>PC5 Control Plane Traffic Type>>>>PC5 Control Plane Traffic TypeMENUMERATED(SRB1, SRB2, ..)This IE indicate the type of SRB conveyed via the PC5 Relay RLC Channel.->>>U2U RLC Channel QoSYESreject>>>>U2U RLC Channel QoSMPC5 QoS Parameters9.3.1.122->>RLC ModeO9.3.1.27->>Additional Remote UE Local ID ListO9.3.1.xxxYESignorePC5 RLC Channel to Be Released List0..1YESreject>PC5 RLC Channel to be Released Item IEs1 .. <maxnoofPC5RLCChannels>->>PC5 RLC Channel IDM9.3.1.265->>Remote UE Local IDO9.3.1.267-

[0429] The UE CONTEXT MODIFICATION REQUEST messagemay includeAdditional RemoteUELocal ID List.

[0430] The Additional Remote UE Local ID List defines the Remote UE list multiplexed over the same egress PC5 Relay RLC channel.

[0431] Table 4 shows examples of IE included in the Additional Remote UE Local ID List.

[0432] IE / Group NamePresenceRangeIE Type and ReferenceSemantics DescriptionCriticalityAssigned CriticalityAdditional Remote UE Local ID List1-> Additional Remote UE Local ID Item1..<maxnoofLocalIds>->>Remote UE Local IDMINTEGER (0..255, ...)Corresponds to the sl-LocalIdentity contained in the SL-SRAP-Config IE defined in TS 38.331.-

[0433] Alternatively, by including only the PC5 RLC Channel ID IE and the Remote UE Local ID IE within the PC5 RLC Channel to Be Modified List IE of the UE CONTEXT MODIFICATION REQUEST message, it may inform the gNB-DU that the SRB or DRB of the Remote UE has been multiplexed into the existing PC5 Relay RLC channel corresponding to the PC5 RLC Channel ID. Alternatively, it is also possible to inform the gNB-DU of the situation by including the PC5 RLC Channel ID IE, the Remote UE Local ID IE, and a Multiplex indication together within the PC5 RLC Channel to Be Modified List IE. Alternatively, it is also possible to deliver to the gNB-DU by including the PC5 RLC Channel ID IE, the Remote UE Local ID IE, and the Existing UE Information IE (for example, related information (e.g., Local ID, L2 ID, etc.) of the Remote UE and / or Relay UE that first received the allocation / configuration of the PC5 Relay RLC channel) within the PC5 RLC Channel to Be Modified List IE.

[0434] Step 6: The gNB-CU can deliver part or all of the following information to U2N Relay UE#1 through the RRCReconfiguration message of U2N Relay UE#1 so that the SRB0 / 1 message of the U2N Remote UE can be routed.

[0435] A. Local ID for the U2N Remote UE allocated / configured in Step 4 in order to distinguish / identify the U2N Remote UE in the Uu link or Uu Relay RLC channel between U2N Relay UE#1 and the base station.

[0436] B. Uu Relay RLC channel configuration necessary to transmit the SRB0 / 1 message for the U2N Remote UE, received from the gNB-DU in Step 5.

[0437] C. PC5 Relay RLC channel configuration between U2N Relay UE#2 and U2N Relay UE#1 for transmitting the SRB0 / 1 message for the U2N Remote UE, received from the gNB-DU in Step 5.

[0438] D. SRAP information for mapping / routing each SRAP Data PDU belonging to SRB0 / 1 to a specific egress PC5 / Uu Relay RLC channel. Or, SRAP information for mapping / routing an SRAP Data PDU transmitted through a specific ingress PC5 / Uu Relay RLC channel for SRB0 / 1 to a specific egress Uu / PC5 Relay RLC channel.

[0439] Step 7: In order to allocate / configure the PC5 Relay RLC channel for delivering the SRB0 / 1 message of the U2N Remote UE to U2N Relay UE#2, the gNB-CU requests the gNB-DU for the allocation / configuration of the PC5 Relay RLC channel configuration for the PC5 connection between U2N Relay UE#1 and U2N Relay UE#2 for delivering the SRB0 / 1 message through the F1AP UE Context Modification procedure of U2N Relay UE#2. In addition, it can request the allocation / configuration of the PC5 Relay RLC channel configuration for the PC5 connection between U2N Relay UE#2 and the U2N Remote UE for delivering the SRB1 message of the U2N Remote UE. If the PC5 Relay RLC channel configuration for the PC5 connection between U2N Relay UE#1 and U2N Relay UE#2 was allocated / created in Step 5, the same configuration may be allocated / configured to U2N Relay UE#2. Alternatively, the PC5 Relay RLC channel configurations for the PC5 connection from U2N Relay UE#1 to U2N Relay UE#2 and the PC5 connection from U2N Relay UE#2 to U2N Relay UE#1 may be allocated / created differently from each other (for example, it is possible to allocate / create the PC5 Relay RLC channel configurations for UL / DL directions differently from each other). In the case where the gNB-CU decides to transmit by multiplexing together the SRB0 / 1 message of the U2N Remote UE into the PC5 Relay RLC channel configuration allocated / configured for another UE (for example, another Relay UE and / or another Remote UE), the gNB-CU may include information regarding the UE (for example, Remote UE and / or Relay UE) that will together use / utilize the existing PC5 Relay RLC channel configuration instead of requesting the allocation / configuration of a new PC5 Relay RLC channel configuration within the UE CONTEXT MODIFICATION REQUEST message, as in Step 5.

[0440] Step 8: The RRC Reconfiguration process is executed to deliver the PC5 Relay RLC channel configuration received from the gNB-DU in Step 7 to U2N Relay UE#2. In addition, SRAP information for mapping / routing each SRAP Data PDU belonging to SRB0 / 1 to a specific egress PC5 Relay RLC channel, or SRAP information for mapping / routing an SRAP Data PDU transmitted through a specific ingress PC5 Relay RLC channel for SRB0 / 1 to a specific egress PC5 Relay RLC channel, can be allocated / configured to U2N Relay UE#2.

[0441] - Step 5 / 6 and Step 7 / 8 may be performed simultaneously / in parallel, or may be performed in a swapped order with each other.

[0442] Step 9: U2N Relay UE#2 delivers the RRCSetupRequest message received in Step 2 to the gNB-DU through the configuration allocated / configured in Step 8. At this time, U2N Relay UE#2 can construct an SRAP header and deliver it to the gNB-DU based on the information (e.g., Local ID for U2N Remote UE, BEARER ID for SRB0, etc.) received in Step 8, equally to the UE-to-Network Relay operation within TS 38.351. At this time, U2N Relay UE#1 can deliver the RRCSetupRequest message of the U2N Remote UE sent by U2N Relay UE#2 to the gNB-DU based on the configuration allocated / configured in Step 6.

[0443] Step 10: The gNB-DU can know that the U2N Remote UE is accessing the gNB-DU for the first time by looking at the BEARER ID (for example, SRB0) within the SRAP header received in Step 9. In addition, it can know that the U2N Remote UE is accessing through U2N Relay UE#1 based on the information such as the Uu Relay RLC channel through which the RRCSetupRequest message was delivered. In addition, it may know that Intermediate U2N Relay UE(s) exist between the current U2N Remote UE and U2N Relay UE#1 based on additional information included in the SRAP header (e.g., an indication informing that it is a Multi-hop U2N Relay operation and / or Number of hops (n), Local ID for U2N Remote UE, etc.). Alternatively, it may also know that the U2N Remote UE is accessing the gNB-DU via U2N Relay UE#2 and U2N Relay UE#1 by comparing information such as the Uu Relay RLC channel through which the RRCSetupRequest message was delivered and the Local ID information included in the SRAP header with the Local ID for U2N Remote UE, Additional Remote UE Local ID List, and / or PC5 / Uu Relay RLC channel allocation / creation request information, etc., received from the gNB-CU in Step 5 and / or Step 7.

[0444] In the case where the gNB-DU decides that it can service the U2N Remote UE, it can allocate / create a lower layer configuration for the PC5 Relay RLC channel between the U2N Remote UE and the U2N Relay UE located at the first hop (for example, U2N Relay UE#2), rather than between the U2N Remote UE and U2N Relay UE#1, and deliver it to the gNB-CU through the F1AP INITIAL UL RRC MESSAGE TRANSFER message. In addition, it stores / keeps the lower layer configuration information for the PC5 Relay RLC channel allocated / created in this way within the U2N Remote UE's context inside the gNB-DU. Since the gNB-DU knows that it must allocate the PC5 Relay RLC channel between the U2N Remote UE and the U2N Relay UE located at the first hop (for example, U2N Relay UE#2), in the case where the gNB-DU decides to transmit by multiplexing together with the PC5 Relay RLC channel configuration allocated / configured for another UE (for example, another Relay UE and / or another Remote UE), the gNB-DU may include the existing PC5 Relay RLC channel configuration allocation / configuration information, as in Step 5, instead of including the allocation / configuration of a new PC5 Relay RLC channel configuration within the INITIAL UL RRC MESSAGE TRANSFER message. In this case, the gNB-DU may also deliver together to the gNB-CU information regarding the Remote UE and / or Relay UE that first received the allocation / configuration of the existing PC5 Relay RLC channel configuration.

[0445] Furthermore, the gNB-DU delivers together to the gNB-CU the gNB-DU UE F1AP ID for the U2N Relay UE located at the last hop (for example, U2N Relay UE#1) and the Local ID for U2N Remote UE that was included in the SRAP header received in Step 9, through the INITIAL UL RRC MESSAGE TRANSFER message. If the gNB-DU can judge that the entire path of the U2N Remote UE has been formed as U2N Remote UE -> Relay UE#2 -> U2N Relay UE#1 -> gNB by combining information from Step 4, Step 5, Step 7, Step 9, etc., the gNB-DU may also include the gNB-DU UE F1AP ID for the U2N Relay UE located at the first hop (for example, U2N Relay UE#2) and deliver it to the gNB-CU.

[0446] The gNB-CU can know that the U2N Remote UE is accessing the base station through U2N Relay UE#2 and U2N Relay UE#1 based on the SidelinkUEInformationNR message received in Step 4 and the F1AP INITIAL UL RRC MESSAGE TRANSFER message received in Step 10, and can derive the gNB-DU UE F1AP ID and gNB-CU UE F1AP ID existing within the gNB-CU and gNB-DU that identify the UE context for U2N Relay UE#2 and U2N Relay UE#1, respectively, as follows:

[0447] - gNB-DU UE F1AP ID and gNB-CU UE F1AP ID for U2N Relay UE#1

[0448] - gNB-DU UE F1AP ID and gNB-CU UE F1AP ID for U2N Relay UE#2

[0449] Step 11: In the case where the gNB-CU decides to create an RRC connection with the U2N Remote UE, it generates an RRCSetup message and delivers it to the gNB-DU through the F1AP DL RRC MESSAGE TRANSFER message.

[0450] The gNB-DU constructs an SRAP header by referring to the SRB Mapping Info IE included in the F1AP DL RRC MESSAGE TRANSFER message, and then delivers the RRCSetup message to the U2N Remote UE via U2N Relay UE#1 and U2N Relay UE#2. At this time, in the case where the gNB-CU decides to transmit by multiplexing together the SRB0 / 1 message of the U2N Remote UE into the Uu Relay RLC channel configuration allocated / configured for another UE (for example, another Relay UE and / or another Remote UE), the gNB-CU may provide it to the gNB-DU by including the Uu Relay RLC channel information used in the other UE within the SRB Mapping Info IE inside the DL RRC MESSAGE TRANSFER message.

[0451] The gNB-CU may include, within the RRCSetup message, SRAP information that maps each SRB and DRB to be used by the U2N Remote UE in the PC5 connection between the U2N Remote UE and U2N Relay UE#2 (for example, for the first PC5 connection) to a specific egress PC5 Relay RLC channel. In addition, it may deliver by including the L2 ID for U2N Relay UE#2 information together within the SRAP configuration in order to inform the U2N Remote UE that it is the PC5 Relay RLC channel toward U2N Relay UE#2.

[0452] Step 12: If the PC5 / Uu Relay RLC channel for delivering the SRB1 message of the U2N Remote UE was not allocated / configured to U2N Relay UE#1 in Steps 5-6, the gNB-CU requests the gNB-DU for the allocation / configuration of the PC5 Relay RLC channel configuration for the PC5 connection between U2N Relay UE#1 and U2N Relay UE#2 and / or the Uu Relay RLC channel configuration between U2N Relay UE#1 and the gNB-DU for delivering the SRB1 message through the F1AP UE Context Modification procedure in Step 12a. In the case where the gNB-CU decides to transmit by multiplexing together the SRB1 message of the U2N Remote UE into the PC5 Relay RLC channel configuration allocated / configured for another UE (for example, another Relay UE and / or another Remote UE), the gNB-CU may include information regarding the UE (for example, Remote UE and / or Relay UE) that will together use / utilize the existing PC5 Relay RLC channel configuration instead of requesting the allocation / configuration of a new PC5 Relay RLC channel configuration within the UE CONTEXT MODIFICATION REQUEST message, as in Step 5 or Step 7.

[0453] The RRC Reconfiguration process is executed as in Step 12b to deliver the PC5 / Uu Relay RLC channel configuration received from the gNB-DU in Step 12a to U2N Relay UE#1. In addition, SRAP information for mapping / routing each SRAP Data PDU belonging to SRB1 to a specific egress PC5 / Uu Relay RLC channel, or SRAP information for mapping / routing an SRAP Data PDU transmitted through a specific ingress PC5 / Uu Relay RLC channel for SRB1 to a specific egress Uu / PC5 Relay RLC channel, can be allocated / configured to U2N Relay UE#1.

[0454] Step 13: If the PC5 Relay RLC channel for delivering the SRB1 message of the U2N Remote UE was not allocated / configured to U2N Relay UE#2, the gNB-CU requests the gNB-DU for the allocation / configuration of the PC5 Relay RLC channel configuration for the PC5 connection between U2N Relay UE#1 and U2N Relay UE#2 and / or the PC5 Relay RLC channel configuration for the PC5 connection between U2N Relay UE#2 and the U2N Remote UE for delivering the SRB1 message through the F1AP UE Context Modification procedure in Step 13a. If the PC5 Relay RLC channel configuration for the PC5 connection between U2N Relay UE#1 and U2N Relay UE#2 was allocated / created in Step 5 or Step 12a, the same configuration can be allocated / configured to U2N Relay UE#2. Equally, if the gNB-DU allocated / configured the PC5 Relay RLC channel configuration for the PC5 connection between U2N Relay UE#2 and the U2N Remote UE in Step 10, the corresponding configuration can be allocated / configured to U2N Relay UE#2. In the case where the gNB-CU decides to transmit by multiplexing together the SRB1 message of the U2N Remote UE into the PC5 Relay RLC channel configuration allocated / configured for another UE (for example, another Relay UE and / or another Remote UE), the gNB-CU may include information regarding the UE (for example, Remote UE and / or Relay UE) that will together use / utilize the existing PC5 Relay RLC channel configuration instead of requesting the allocation / configuration of a new PC5 Relay RLC channel configuration within the UE CONTEXT MODIFICATION REQUEST message, as in Step 5 or Step 7.

[0455] The RRC Reconfiguration process is executed as in Step 13b to deliver the PC5 Relay RLC channel configuration received from the gNB-DU in Step 13a to U2N Relay UE#2. In addition, SRAP information for mapping / routing each SRAP Data PDU belonging to SRB1 to a specific egress PC5 Relay RLC channel, or SRAP information for mapping / routing an SRAP Data PDU transmitted through a specific ingress PC5 Relay RLC channel for SRB1 to a specific egress PC5 Relay RLC channel, can be allocated / configured to U2N Relay UE#2.

[0456] - Step 12 and Step 13 may be performed simultaneously / in parallel, or may be performed in a swapped order with each other.

[0457] Step 14: After finishing the bearer allocation / configuration and / or PC5 Relay RLC channel allocation / configuration to be used in the RRC connection with the base station according to the RRCSetup message received in Step 11, the U2N Remote UE informs this by sending an RRCSetupComplete message to the base station. The U2N Remote UE includes a Registration Request message together within the RRCSetupComplete message for registration to the network.

[0458] Based on the information received in Step 11, the U2N Remote UE constructs the SRAP header of the RRCSetupComplete message in a form suitable for SRB1 message transmission and delivers it to the base station via U2N Relay UE#2 and U2N Relay UE#1.

[0459] Step 15: The base station delivers the Registration Request message received in Step 14 to the AMF, and the AMF decides on registration acceptance for the terminal and informs the base station. The gNB-CU may decide to additionally create / allocate SRBs and / or DRBs in order to exchange data and / or signaling with the U2N Remote UE based on the information received from the AMF. In this case, the gNB-CU can deliver to U2N Relay UE#1 and / or U2N Relay UE#2 after allocating / configuring the PC5 / Uu Relay RLC channel configuration information for the additionally created / allocated SRBs and / or DRBs through the same process as Step 12 and / or Step 13. In the case where the gNB-CU decides to transmit by multiplexing together the SRB message (e.g., SRB2 and / or SRB3) or DRBs of the U2N Remote UE into the PC5 Relay RLC channel configuration allocated / configured for another UE (for example, another Relay UE and / or another Remote UE), the gNB-CU may include information regarding the UE (for example, Remote UE and / or Relay UE) that will together use / utilize the existing PC5 Relay RLC channel configuration instead of requesting the allocation / configuration of a new PC5 Relay RLC channel configuration within the UE CONTEXT MODIFICATION REQUEST message, as in Step 5 or Step 7.

[0460] Step 16: In Step 16a, the gNB-CU requests the gNB-DU for the allocation / configuration of the PC5 Relay RLC channel configuration information for the SRB and / or DRB in the PC5 connection (for example, the first PC5 connection) between the U2N Remote UE and U2N Relay UE#2 through the F1AP UE Context Modification procedure of the U2N Remote UE, and receives it. In this process, Counterpart Information for informing that it is a PC5 Relay RLC channel created / allocated toward U2N Relay UE#2 can be delivered together. In the case where the gNB-CU decides to transmit by multiplexing together the SRB message (e.g., SRB2 and / or SRB3) or DRBs of the U2N Remote UE into the PC5 Relay RLC channel configuration allocated / configured for another UE (for example, another Relay UE and / or another Remote UE), the gNB-CU may include information regarding the UE (for example, Remote UE and / or Relay UE) that will together use / utilize the existing PC5 Relay RLC channel configuration instead of requesting the allocation / configuration of a new PC5 Relay RLC channel configuration within the UE CONTEXT MODIFICATION REQUEST message, as in Step 5 or Step 7.

[0461] The gNB-CU requests the creation of SRBs and / or DRBs for exchanging signaling and / or data with the U2N Remote UE through the RRC Reconfiguration process in Step 16b. The gNB-CU can allocate / configure the PDCP and SDAP configuration for the SRBs and / or DRBs together for this. In addition, the gNB-CU can deliver the PC5 Relay RLC channel configuration information for the SRB and / or DRB in the PC5 connection (for example, the first PC5 connection) between the U2N Remote UE and U2N Relay UE#2, allocated / configured from the gNB-DU in Step 16a, to the U2N Remote UE. By referring to the configuration information received from the gNB-CU, the U2N Remote UE allocates / configures the PC5 Relay RLC channel toward U2N Relay UE#2.

[0462] Step 17: UL / DL data regarding the U2N Remote UE is transmitted via U2N Relay UE#1 and U2N Relay UE#2.

[0463] Step 18: A new U2N Remote UE may attempt connection to the network by repeating Steps 1-17 of FIG. 17a, FIG. 17b, and FIG. 17c. In this case, the existing U2N Remote UE performs the role of U2N Relay UE#3. If U2N Relay UE#3 (for example, the existing U2N Remote UE in FIG. 17a, FIG. 17b, and FIG. 17c) is in RRC_IDLE or RRC_INACTIVE state, it may also perform the role of U2N Relay UE#3 after transitioning to RRC_CONNECTED state by repeating the process of Steps 2-16 of FIG. 17a, FIG. 17b, and FIG. 17c when a RRCSetupRequest message is received from the new U2N Remote UE.

[0464] Embodiment 6:U2NRemoteUEinitial access by using Fast / Parallel RRC Setup

[0465] In the case of applying the Fast / Parallel RRC Setup operation [Ref#1] for U2N Relay UEs in RRC_INACTIVE / RRC_IDLE state, each UE (for example, Relay UE and / or Remote UE) can exchange its own SRB1 message (e.g., RRCSetupComplete message) with the base station using a Specified PC5 Relay RLC channel (e.g., SL-RLC1 or SL-RLCy) during the RRC Setup process (Option 1). Alternatively, each UE may exchange its own SRB1 message (e.g., RRCSetupComplete message) with the base station using a PC5 Relay RLC channel allocated / configured by the base station during the RRC Setup process (Option 2).

[0466] In the case of Option 1, when the RRC connection with each UE is completed, the base station may allocate / configure a PC5 Relay RLC channel for delivering SRBs and / or DRBs to each UE. In this process, in the case where the gNB-CU decides to transmit by multiplexing together the SRBs or DRBs of the U2N Remote UE into the PC5 Relay RLC channel configuration allocated / configured for another UE (for example, another Relay UE and / or another Remote UE), the gNB-CU may include information regarding the UE (for example, Remote UE and / or Relay UE) that will together use / utilize the existing PC5 Relay RLC channel configuration instead of requesting the allocation / configuration of a new PC5 Relay RLC channel configuration within the UE CONTEXT MODIFICATION REQUEST message, as in Step 5 and / or Step 7 of FIG. 17a.

[0467] In the case of Option 2, the base station can allocate / configure the PC5 Relay RLC channel during the RRC Setup process of each UE. In this process, in the case where the gNB-CU decides to transmit by multiplexing together the SRBs or DRBs of the U2N Remote UE into the PC5 Relay RLC channel configuration allocated / configured for another UE (for example, another Relay UE and / or another Remote UE), the gNB-CU may include information regarding the UE (for example, Remote UE and / or Relay UE) that will together use / utilize the existing PC5 Relay RLC channel configuration instead of requesting the allocation / configuration of a new PC5 Relay RLC channel configuration within the UE CONTEXT MODIFICATION REQUEST message, as in Step 5 and / or Step 7 of FIG. 17a.

[0468] Embodiment 7:

[0469] The proposal may also be executed in the following form.

[0470] The term "U2N relay UE" can include first / intermediate / last relay UEs in multihop, if not otherwise qualified. We can distinguish explicitly when a requirement applies only to single-hop or only to certain multihop roles.

[0471] The term "U2N remote UE" can include multihop remote UEs, if not otherwise qualified. We can distinguish explicitly when a requirement applies only to single-hop or only to multihop.

[0472] Expand the definitions of "U2N relay UE" and "U2N remote UE" in the CR definition sections to include multihop. This drafting can be done initially in the 38.300 running CR and migrated later into the other CRs.

[0473] The existing multihop definitions, e.g., first / intermediate / last relay UE, are kept. FFS if they need debugging (business as usual). The intention is that the first relay UE is an intermediate relay UE, as originally agreed.

[0474] Hereinafter technical features related to L2 UE-to-Network Relay are described.

[0475] FIG. 18 shows an example of user plane protocol stack for single-hop L2 UE-to-Network Relay.

[0476] FIG. 19 shows an example of control plane protocol stack for single-hop L2 UE-to-Network Relay.

[0477] FIG. 20 shows an example of user plane protocol stack for multi-hop L2 UE-to-Network Relay.

[0478] FIG. 21 shows an example of control plane protocol stack for multi-hop L2 UE-to-Network Relay.

[0479] The protocol stacks for the user plane and control plane of single-hop L2 U2N Relay architecture are illustrated in FIG. 18 and FIG. 19. The protocol stacks for the user plane and control plane of multi-hop L2 U2N Relay architecture are illustrated in FIG. 20 and FIG. 21. The SRAP sublayer is placed above the RLC sublayer for both CP and UP at both PC5 interface and Uu interface. The Uu SDAP, PDCP and RRC are terminated between L2 U2N Remote UE and gNB, while SRAP, RLC, MAC and PHY are terminated in each hop (for example, the link between L2 U2N Remote UE and the L2 U2N Relay UE, the link between L2 U2N Relay UEs, and the link between L2 U2N Relay UE and the gNB).

[0480] For L2 U2N Relay, the SRAP sublayer over PC5 hop is only for the purpose of bearer mapping. The SRAP sublayer is not present over PC5 hop for relaying the L2 U2N Remote UE's message on BCCH and PCCH. For L2 U2N Remote UE's message on SRB0, the SRAP header is not present over PC5 hop, but the SRAP header is present over Uu hop for both DL and UL.

[0481] For L2 U2N Relay, for uplink:

[0482] - The Uu / PC5 SRAP sublayer at the U2N Relay UE performs UL bearer mapping between end-to-end Uu Radio Bearers of L2 U2N remote UE (identified for the purposes of this mapping by the local Remote UE ID and an associated bearer ID) and egress Uu / PC5 Relay RLC channels over the L2 U2N Relay UE Uu / PC5 interface. For uplink relaying traffic, the different end-to-end Uu Radio Bearers (SRBs or DRBs) of the same L2 U2N Remote UE and / or different L2 U2N Remote UEs can be multiplexed over the same egress Uu / PC5 Relay RLC channel;

[0483] - The Uu / PC5 SRAP sublayer at the U2N Relay UE supports L2 U2N Remote UE identification for the UL traffic. The identity information of L2 U2N Remote UE end-to-end Uu Radio Bearer and a local Remote UE ID are included in the Uu SRAP header at UL in order for gNB to correlate the received packets for the specific PDCP entity associated with the right end-to-end Uu Radio Bearer of the L2 U2N Remote UE;

[0484] - The PC5 SRAP sublayer at the L2 U2N Remote UE supports UL bearer mapping between L2 U2N Remote UE end-to-end Uu Radio Bearers and egress PC5 Relay RLC channels.

[0485] For L2 U2N Relay, for downlink:

[0486] - The Uu / PC5 SRAP sublayer at the U2N Relay UE performs DL bearer mapping at gNB to map end-to-end Uu Radio Bearer (SRB, DRB) of L2 U2N Remote UE (identified for the purposes of this mapping by the local Remote UE ID and an associated bearer ID) into Uu / PC5 Relay RLC channel. The Uu / PC5 SRAP sublayer at the U2N Relay UE performs DL bearer mapping and data multiplexing between multiple end-to-end Radio Bearers (SRBs or DRBs) of a L2 U2N Remote UE and / or different L2 U2N Remote UEs and one Uu Relay RLC channel over the L2 U2N Relay UE Uu / PC5 interface;

[0487] - The Uu / PC5 SRAP sublayer at the U2N Relay UE supports L2 U2N Remote UE identification for DL traffic. The identity information of L2 U2N Remote UE end-to-end Uu Radio Bearer and a local Remote UE ID are included into the Uu SRAP header by the gNB at DL for the L2 U2N Relay UE to identify the corresponding end-to-end Uu Radio Bearer(s) of L2 U2N Remote UE;

[0488] - The PC5 SRAP sublayer at the L2 U2N Relay UE performs DL bearer mapping between end-to-end Uu Radio Bearers of L2 U2N remote UE and egress PC5 Relay RLC channels;

[0489] - The PC5 SRAP sublayer at the L2 U2N Remote UE correlates the received packets with the right PDCP entity associated with the given end-to-end Uu Radio Bearer of the L2 U2N Remote UE based on the identity information included in the PC5 SRAP header.

[0490] A local Remote UE ID is included in both PC5 SRAP header and Uu SRAP header. L2 U2N Relay UE is configured by the gNB with the local Remote UE ID(s) to be used in SRAP header. L2 U2N Remote UE obtains the local Remote ID from the gNB via Uu RRC messages including RRCSetup, RRCReconfiguration, RRCResume and RRCReestablishment.

[0491] The end-to-end DRB(s) or end-to-end SRB(s), except SRB0, of L2 U2N Remote UE can be multiplexed to the PC5 Relay RLC channels and Uu Relay RLC channels in both PC5 hop and Uu hop, but an end-to-end DRB and an end-to-end SRB can neither be mapped into the same PC5 Relay RLC channel nor be mapped into the same Uu Relay RLC channel.

[0492] It is the gNB responsibility to avoid collision on the usage of local Remote UE ID. The gNB can update the local Remote UE ID by sending the updated local Remote UE ID via RRCReconfiguration message. The serving gNB can perform local Remote UE ID update independent of the PC5 unicast link L2 ID update procedure.

[0493] Therefore, RAN3 needs to discuss how to support the mapping of the RBs of different U2N Remote UEs to same PC5 / Uu Relay RLC channel in F1 interface.

[0494] Observation 1: The mapping of the RBs of different U2N Remote UEs to same PC5 / Uu Relay RLC channel needs to be supported in F1 interface.

[0495] Since the different RB(s) of different Remote UE(s) can be already multiplexed over the same Uu Relay RLC channel in Rel-17 single-hop relay operation, this can be reused for Rel-19 multi-hop relay operation. Therefore, there is no RAN3 issue to support the multiplexing for the Uu Relay RLC channel in Rel-19 multi-hop relay operation. However, for PC5 Relay RLC channel, it is unclear how to handle the multiplexing of the RBs of different U2N Remote UEs to the same egress PC5 Relay RLC channel over F1 interface. In Rel-17 single-hop relay operation, since each PC5 Relay RLC channel configuration provided to U2N Relay UE is uniquely associated with one U2N Remote UE, there is no multiplexing between the RBs of different U2N Remote UEs over the same PC5 Relay RLC channel.

[0496] Observation 2: From the RAN3 point of view, the different RB(s) of different Remote UE(s) can be multiplexed over the same Uu Relay RLC channel.

[0497] Observation 3: It is unclear how to handle the multiplexing of the RBs of different U2N Remote UEs to the same egress PC5 Relay RLC channel over F1 interface.

[0498] RAN3 needs to discuss whether the gNB-CU indicates to the gNB-DU that the existing PC5 Relay RLC channel is also used for a new U2N Remote UE. Since the gNB-CU already has the PC5 Relay RLC channel configurations established for other U2N Remote UE, it is possible to generate the RRCReconfiguration message to configure the PC5 Relay RLC channel to a new U2N Relay UE without the help of gNB-DU. In this case, the gNB-DU is difficult to notice that the new U2N Remote UE is additionally mapped to the existing PC5 Relay RLC channel. Therefore, our view is that the list of U2N Remote UEs mapped to the same PC5 Relay RLC channel should be provided to the gNB-DU. To this end, when the existing PC5 Relay RLC channel is used for relaying the SRB message of a new U2N Remote UE, the gNB-CU needs to include the local ID of a new U2N Remote UE to the PC5 RLC Channel to Be Modified List IE in the UE CONTEXT MODIFICATION REQUEST message. One possible option is to reuse the existing Remote UE Local ID IE in the PC5 RLC Channel to Be Modified List IE. However, since the gNB-DU is difficult to differentiate between the wrong local ID value (for example, error case) and the additional local ID value (for example, reuse of existing PC5 Relay RLC channel), it is better to introduce a new IE to indicate to the gNB-DU the local ID of the new Remote UE which is mapped to the existing PC5 Relay RLC channel.

[0499] Proposal 2: The gNB-CU includes the Remote UE Local ID to Add IE (for example, local ID for a new U2N Remote UE) to the PC5 RLC Channel to Be Modified List IE in the UE CONTEXT MODIFICATION REQUEST message to indicate that the existing PC5 Relay RLC channel is used for a new U2N Remote UE.

[0500] Similarly, it is possible that one of the U2N Remote UEs mapped to the same PC5 Relay RLC channel is deleted due to e.g., the UE inactivity or the remapping to other PC5 Relay RLC channel. Therefore, it is also needed to introduce a new IE to indicate to the gNB-DU the Remote UE Local ID to delete.

[0501] Proposal 2a: The gNB-CU includes the Remote UE Local ID to Delete IE to the PC5 RLC Channel to Be Modified List IE in the UE CONTEXT MODIFICATION REQUEST message to indicate that the PC5 Relay RLC channel is no longer used for the U2N Remote UE.

[0502] The following Editor's Notes are related to the gNB-DU's awareness on the multi-hop relay operation.

[0503] - FFS whether the gNB-DU UE F1AP IDs of the U2N First Relay UE and the U2N Intermediate Relay UE are included in the INITIAL UL RRC MESSAGE TRANSFER message

[0504] - FFS whether and how the gNB-DU becomes aware that the U2N Remote UE is connected to the gNB-DU via the U2N First Relay UE, the U2N Intermediate Relay UE and U2N Last Relay UE

[0505] In Rel-17 U2N Relay, the sidelink configuration container in the INITIAL UL RRC MESSAGE TRANSFER message is the configuration for the PC5 Relay RLC channel between U2N Remote UE and U2N Relay UE for relaying of U2N Remote UE's SRB1. In Rel-19 Multi-hop Relay, our understanding is that for relaying of U2N Remote UE's SRB1, this information should include the PC5 Relay RLC channel between First Relay UE and U2N Remote UE. However, in order to correctly include this information in the INITIAL UL RRC MESSAGE TRANSFER message in Rel-19, the gNB-DU needs to know the U2N Remote UE is directly connected to the First Relay UE. For example, as shown in Figure 1, the SRB0 of U2N Remote UE#1 (connected to gNB via multi-hop relay) and U2N Remote UE#4 (connected to gNB via single-hop relay) can be multiplexed over the same egress Uu Relay RLC channel. In this case, the local ID enables the gNB-DU to differentiate between the U2N Remote UE#1 and the U2N Remote UE#4. However, without a priori knowledge, the gNB-DU cannot know that the RRCSetupRequest message from U2N Remote UE#1 is delivered via First Relay UE, the Intermediate Relay UE, and the Last Relay UE. In other words, the gNB-DU may have the wrong knowledge on that the U2N Remote UE#1 is connected to the gNB via the single Relay UE (for example, Last Relay UE). Therefore, the gNB-DU may allocate the PC5 Relay RLC channel for single-hop relay operation, thus causing misconfiguration of the PC5 Relay RLC channel for the U2N Remote UE#1's SRB1. If RAN2 introduces a new Remote UE local ID or a new SRAP header format for multi-hop relay operation, it is natural for the gNB-DU to know that the U2N Remote UE#1 is connected to the gNB via multi-hop relay. However, for now, it seems that RAN2 reuses the existing Remote UE local ID and SRAP header format.

[0506] Proposal 3: Upon the reception of the RRCSetupRequest message, the gNB-DU should know that the U2N Remote UE is directly connected to the First Relay UE.

[0507] FIG. 22 shows an example of coexistence of single hop relay operation and multi-hop relay operation.

[0508] According to previous RAN3 agreement, the gNB-CU can request to the gNB-DU to establish a new PC5 / Uu Relay RLC channel for relaying of U2N Remote UE's SRBs (for example, SRB0, SRB1, and SRB2). If new PC5 Relay RLC channel of the U2N Relay UE for relaying of U2N Remote UE#1's SRB0 is established, the gNB-CU provides the Remote UE Local ID to the gNB-DU in the PC5 RLC Channel to Be Setup List IE of the UE CONTEXT MODIFICATION REQUEST message. Therefore, upon the reception of the RRCSetupRequest message of U2N Remote UE#1, the gNB-DU can check whether the RRC message is delivered via the multi-hop relay, based on the Remote UE Local ID.

[0509] Proposal 4: If a new PC5 Relay RLC channel is established, the gNB-DU becomes aware that the U2N Remote UE is directly connected to the First Relay UE based on the Remote UE Local ID.

[0510] If the existing PC5 Relay RLC channel is used for relaying the U2N Remote UE#1's SRB0 message, the gNB-CU might not include the PC5 RLC Channel to Be Setup List IE in the UE CONTEXT MODIFICATION REQUEST message. Therefore, since the Remote UE Local ID is not provided, the gNB-DU cannot identify the parent node of the U2N Remote UE#1 (for example, First Relay UE) upon the reception of the RRCSetupRequest message of U2N Remote UE#1. If Proposal 2 is agreed, the Remote UE Local ID to Add IE enables the gNB-DU to identify the parent node of the U2N Remote UE#1. If Proposal 2 is not agreed (for example, Remote UE Local ID is not provided in the PC5 RLC Channel to Be Setup List IE or the PC5 RLC Channel to Be Modified List IE), the gNB-CU should at least provide the Remote UE Local ID to the gNB-DU in the UE CONTEXT MODIFICATION REQUEST message of the First Relay UE.

[0511] Proposal 4a: In the case where the existing PC5 Relay RLC channel is reused, if Proposal 2 is agreed, the gNB-DU becomes aware that the U2N Remote UE is directly connected to the First Relay UE based on the additional Remote UE Local ID.

[0512] Proposal 4b: In the case where the existing PC5 Relay RLC channel is reused, if Proposal 2 is not agreed, the gNB-CU should at least provide the Remote UE Local ID to the gNB-DU in the UE CONTEXT MODIFICATION REQUEST message of the First Relay UE.

[0513] From the gNB-CU's point of view, each UE is connected to the gNB in sequence. That is, the gNB-CU already knows that the Intermediate Relay UE in RRC_CONNECTED is connected to the gNB via the Last Relay UE. Upon reception of the SidelinkUEInformationNR message from the Intermediate Relay UE, the gNB-CU becomes aware that the First Relay UE is connected to the gNB via the Intermediate Relay UE and the Last Relay UE. Similarly, when the First Relay UE in RRC_CONNECTED sends its own SidelinkUEInformationNR message to the gNB-CU, the gNB-CU becomes aware that the Remote UE is connected to the gNB via the First Relay UE, the Intermediate Relay UE and the Last Relay UE. Therefore, there is no need to provide the gNB-DU UE F1AP IDs of the First Relay UE and Intermediate Relay UE(s) to the gNB-CU in the INITIAL UL RRC MESSAGE TRANSFER message.

[0514] Proposal 5: There is no need to provide the gNB-DU UE F1AP IDs of the First Relay UE and Intermediate Relay UE(s) to the gNB-CU in the INITIAL UL RRC MESSAGE TRANSFER.

[0515] Proposal 6: The gNB-CU can have the knowledge on the whole path for Remote UE when entering all the Relay UEs into RRC_CONNECTED.

[0516] In RAN3 #127bis meeting, RAN3 made the following working assumption on the counterpart information.

[0517] - WA: Reuse the Peer UE ID IE as counterpart information

[0518] In Approach #1, both gNB-CU and gNB-DU become aware of the whole path information consisting of the L2 IDs for U2N Relay UEs and U2N Remote UE since each UE is connected to the gNB in sequence. Therefore, when receiving the L2 ID of the parent UE or child UE along with the PC5 RLC Channel to Be Setup List IE, the gNB-DU can identify the counterpart of the PC5 Relay RLC channel to be established towards the downstream or the upstream. Since the existing Peer UE ID IE can contain the destination L2 ID of each PC5 hop, there is no critical issue to reuse this IE for the multi-hop relay operation. However, as shown in TS 38.473, the existing Peer UE ID IE is introduced only for the Rel-18 single-hop U2U relay operation. Therefore, the semantics description needs to be updated to cover the Rel-19 multi-hop U2N relay operation. In addition, since the PC5 Relay RLC channel between the First Relay UE and U2N Remote UE is uniquely associated with one U2N Remote UE, the Peer UE ID IE is only included if the gNB-CU UE F1AP ID and / or gNB-DU UE F1AP ID are associated with a L2 U2N Relay UE in the U2N multi-hop relay operation.

[0519] >>Peer UE ID: BIT STRING (SIZE(24)), Corresponds to information provided in the sl-DestinationIdentityL2-U2U contained in the SL-TxResourceReqL2-U2U IE, defined in TS 38.331.

[0520] This IE is included if the gNB-CU UE F1AP ID and / or gNB-DU UE F1AP ID are associated with a L2 U2U Remote UE or L2 U2U Relay UE.

[0521] Proposal 7: It is proposed to turn the following WA into the agreement and update the semantics description of the Peer UE ID IE to cover the multi-hop relay operation.

[0522] WA: Reuse the Peer UE ID IE as counterpart information

[0523] Proposal 7a: The Peer UE ID IE is only included if the gNB-CU UE F1AP ID and / or gNB-DU UE F1AP ID are associated with a L2 U2N Relay UE in the U2N multi-hop relay operation.

[0524] Control plane design considers only approach 1 (along with the fast forwarding enhancement for SRB0 if agreed), and approach 2 is not further pursued in Rel-19.

[0525] Observation 4: Approach 2 is not supported in this release.

[0526] However, it was also considered whether and how to support the fast / parallel RRC setup procedure for Approach 1. That is, RAN2 had the discussion to forward the SRB0 messages of the U2N Remote UE by U2N Relay UEs not in RRC_CONNECTED in Approach 1. RAN2 will conclude whether and how to support the fast / parallel RRC setup procedure for Approach 1 in RAN2#130 meeting as follows:

[0527] Agreement in RAN2#129bis:

[0528] Continue to consider forwarding of SRB0 messages by relay UEs not in RRC_CONNECTED with respect to control plane approach 1.

[0529] TPs showing the two approaches for fast forwarding of SRB0 (SRAP header and local ID assignment by RRC signalling) are invited for next meeting (co-sourcing strongly encouraged).

[0530] Other approaches are not precluded (contribution-driven) but should be shown at a mature stage considering the time left.

[0531] Strive to avoid additional RAN3 impact specific to fast forwarding.

[0532] FFS if applicable to DL.

[0533] FFS what level of gNB awareness of the path information would be needed.

[0534] FFS if fast forwarding is optional / mandatory for UEs to support.

[0535] In RAN2, two options are considered to support the fast forwarding of the SRB0 messages.

[0536] - Option 1: SRAP header adding a L2 ID field to indicate U2N Remote UE in a new header format.

[0537] - Option 2: gNB allocated Local ID(s) to Intermediate Relay UE in the RRCRelease message when the Intermediate Relay UE enters into RRC_INACTIVE. The Intermediate Relay UE then assigns this local ID to represent U2N Remote UE when creating SRAP header.

[0538] The overall procedure for the fast / parallel RRC setup can be illustrated as follows:

[0539] FIG. 23a and FIG. 23b show an example of overall procedure for Fast / Parallel RRC Setup.

[0540] In particular, FIG. 23a and FIG. 23b show an example of overall procedure for Fast / Parallel RRC Setup with Option 1 and 2.

[0541] In Option 1, the First Relay UE in RRC_IDLE / RRC_INACTIVE state does not withhold the RRCSetupRequest message of the U2N Remote UE until it enters into RRC_CONNECTED, but immediately sends it to the parent UE (for example, Intermediate Relay UE). In addition, the First Relay UE in RRC_IDLE / RRC_INACTIVE state generates its own RRCSetupRequest message for the state transition to RRC_CONNECTED and then sends it to the parent UE as well. Similarly, the Intermediate Relay UE in RRC_IDLE / RRC_INACTIVE state forwards the RRCSetupRequest messages of the U2N Remote UE and First Relay UE to the Last Relay UE, and also sends its own RRCSetupRequest message towards the gNB. During Steps 1~3, each Relay UE remembers which PC5 link received the first SRB0 message in UL and uses it for DL egress link determination.

[0542] In Option 2, when entering into RRC_INACTIVE state, the local ID list is provided to the First Relay UE. Upon the reception of the RRCSetupRequest message from the U2N Remote UE, the First Relay UE selects one from the local ID list and assigns it to the U2N Remote UE. The First Relay UE forwards the RRCSetupRequest message of the U2N Remote UE together with the SRAP header containing the assigned local ID for the U2N Remote UE. Then, the First Relay UE generates its own RRCResumeRequest message and sends it to the Last Relay UE. Similarly, the Intermediate Relay UE performs a similar behaviour (for example, forwarding of the SRB0 message of the U2N Remote UE and the First Relay UE, and transmission of its own SRB0 message). During Steps 1~3, each Relay UE remembers the local ID of the child UE in UL and uses it for DL egress link determination.

[0543] The Last Relay UE sends the SidelinkUEInformationNR message to request for the dedicated configurations required to support the relay operation for the U2N Remote UE, First Relay UE, and Intermediate Relay UE. For Option 2, the Last Relay UE also includes the local IDs received from the child UEs in the SidelinkUEInformationNR message. Therefore, for Option 2, the gNB-CU does not need to assign the local IDs to the U2N Remote UE and First Relay UE. For the Intermediate Relay UE, the gNB-CU may allocate the local ID as in Rel-17 single-hop relay operation.

[0544] Observation 5: For Option 2, the gNB-CU does not allocate the local IDs to the U2N Remote UE and First Relay UE.

[0545] In Step 5, the gNB-CU requests to the gNB-DU the Uu Relay RLC channel configuration for relaying the SRB0 message (for example, RRCSetupRequest or RRCResumeRequest) for all UEs. If RAN2 decides to apply the fast forwarding of the SRB0 message only on the uplink (for example, forwarding of the RRCSetupRequest message or the RRCResumeRequest message), the gNB-CU may also request the PC5 Relay RLC channel configuration for relaying the SRB0 message (for example, RRCSetup or RRCResume) to the gNB-DU. However, since all UEs in the multi-hop relay operation try to access to the gNB at the same time, the gNB-CU does not have the path information for each UE. Since the gNB-CU cannot decide the parent UE and child UE of each UE accordingly, it is difficult to provide the Peer UE ID IE together with the PC5 RLC Channel to Be Setup List IE to the gNB-DU. For now, RAN2 considers the inclusion of the path information for each UE into the SidelinkUEInformationNR message. In this case, the gNB-CU can receive the path information from the Last Relay UE. Also, the gNB-DU can know the path information because the gNB-CU also forwards the SidelinkUEInformationNR message to the gNB-DU.

[0546] Observation 6: In case where the fast / parallel RRC setup is applied to the UL, the gNB-CU has to acquire the path information to configure the PC5 Relay RLC channel.

[0547] If RAN2 decides to apply the fast forwarding of the SRB0 message on the downlink (for example, forwarding of the RRCSetup message or the RRCResume message) as well, the gNB-CU might not request to the gNB-DU the SRB0 relaying PC5 Relay RLC channel configuration because the specified PC5 Relay RLC channel (for example, SL-RLC0 or a new SL-RLC) is used for relaying the SRB0 message (for example, RRCSetup or RRCResume). Therefore, there is no chance to provide additional information (e.g., local ID for the UE) by the gNB-CU to the gNB-DU.

[0548] Observation 7: In case where the fast / parallel RRC setup is also applied to the DL, the gNB-CU is difficult to provide additional information (e.g., local ID for the UE) by the gNB-CU to the gNB-DU.

[0549] After the configuration of the Uu Relay RLC channel by gNB, the Last Relay UE forwards all RRC messages to the gNB-DU. In Steps 1b-1 and 2b-1 of Option 1, the U2N Relay UE uses a new SRAP header format containing the L2 ID of the UE in the PC5 hop. However, it is unclear if this new SRAP header format is also used for in Uu hop. Our understanding is that for now, RAN2 tries to avoid the impact on the Uu SRAP operation. That is, since the legacy SRAP header is reused in Uu hop, the gNB-DU includes the BEARER ID and the Local ID for the UE in the SRAP header for DL as in Rel-17 single-hop relay operation. However, if RAN2 decides to change the Uu SRAP operation, the gNB-DU should remember the L2 ID received in the SRAP header of the RRCSetupRequest message and include it together with the Local ID into the SRAP header of the RRCSetup message. This is a new gNB-DU's behaviour compared to Rel-17 single-hop relay operation.

[0550] Observation 8: In case where a new SRAP header format is used for Uu hop in Option 1, the gNB-DU should include the L2 ID and Local ID into the SRAP header of the RRCSetup message.

[0551] As opposed to Option 1, Option 2 reuses the existing SRAP header which contains the BEARER ID and the Local ID for the UE. Therefore, there is no RAN3 impact on the Uu SRAP operation.

[0552] Then, in Step 9, the gNB-DU needs to identify the parent node of the UE sending the SRB0 message (for example, RRCSetupRequest or RRCResumeRequest) to configure the SRB1 relaying PC5 Relay RLC channel between the UE and the parent node. In the basic procedure (for example, all U2N Relay UEs are in RRC_CONNECTED) for Approach 1, each UE is connected to the gNB in sequence. Hence, the gNB-DU can identify the parent node based on the information (e.g., local ID for the UE) provided by the gNB-CU and the whole path knowledge in the gNB-DU. However, in the fast / parallel RRC setup, the gNB-DU does not have the knowledge on the whole path for each UE. As mentioned earlier, if the path information is included in the SidelinkUEInformationNR message, this problem can be resolved.

[0553] However, in case where the fast / parallel RRC setup is also applied to the DL, the way the gNB-CU provides the additional information (e.g., local ID for the UE) to the gNB-DU is still missing. To this end, we think that if the mapping information between the L2 ID of the UE and the local ID of the UE is provided in Step 5 of FIG. 23a, it enables the gNB-DU to identify the parent node of the UE. For example, upon the reception of the RRCSetupRequest message of the First Relay UE in Option 1, the gNB-DU becomes aware that the First Relay UE is directly connected to the Intermediate Relay UE based on the path information and the mapping information between the L2 ID and Local ID.

[0554] For Option 2, if the path information in the SidelinkUEInformationNR message is consisted of the local IDs, then the gNB-DU may deduce the parent node of the UE sending the SRB0 message (for example, RRCSetupRequest or RRCResumeRequest) in Step 9. However, since the gNB-DU does not have the L2 ID of the parent node, we are not sure that it can establish the SRB1 relaying PC5 Relay RLC channel between the UE and the parent node and then include it into the INITIAL UL RRC MESSAGE TRANSFER message. As a result, we think that in Option 2, the mapping information between the L2 ID of the UE and the local ID of the UE should be also provided to the gNB-DU.

[0555] Observation 9: In case where the fast / parallel RRC setup is also applied to the DL, the gNB-CU should provide the mapping information between the L2 ID of the UE and the local ID of the UE to the gNB-DU.

[0556] According to RAN2 agreements, the uniqueness of the local ID within the cell should be guaranteed by the gNB by implementation.

[0557] Reuse the single-hop relay mechanism to support the Local ID allocation for multi-hop relay:

[0558] - First relay UE reports the L2 ID of the remote UE to the gNB to request the local ID allocation, the uniqueness of the local ID within the cell is assumed to be guaranteed by the gNB by implementation.

[0559] - The remote UE local ID is 8 bits.

[0560] In Option 2, when the First Relay UE enters into the RRC_INACTIVE state, the gNB-CU pre-allocates to the First Relay UE the candidate Local ID(s) used in current cell. When the U2N Remote UE initiates the state transition to RRC_CONNECTED in this cell, the First Relay UE selects one of the candidate Local ID(s) on the behalf of the gNB-CU and uses it for the U2N Remote UE. However, the serving cell of the First Relay UE in RRC_INACTIVE may be changed due to cell change by the parent UE (e.g., Intermediate Relay UE or Last Relay UE). In this case, the First Relay UE should not use the candidate Local ID(s) configured by the gNB-CU because the changed cell is different from the cell whose candidate Local ID(s) are configured by the gNB-CU. In this case, the gNB-CU should keep this information because the First Relay UE can move back to the cell in which the UE most recently received RRCRelease message. Another possible scenario is that when the RNA for the First Relay UE is consisted of multiple cells, different candidate Local ID(s) per cell are configured by the gNB-CU. Therefore, when the serving cell is changed within the RNA, the First Relay UE can accordingly use the candidate Local ID(s) configured for the changed cell. This means that the gNB-CU needs to keep all candidate Local ID(s) configured for the First Relay UE in RRC_INACTIVE within the RNA. As a result, considering the Remote UE Local ID is 8 bits, the remaining local ID space in the gNB-CU may not be enough to avoid collision.

[0561] Observation 10: In Option 2, the local ID space in the gNB-CU may not be enough to avoid collision.

[0562] Based on observations, it seems that both options for the support of the fast / parallel RRC setup have RAN3 specification impact. Therefore, if RAN2 decides to support the fast / parallel RRC setup, RAN3 needs to enhance the F1AP signalling.

[0563] Proposal 8: It is proposed to wait for RAN2 progress on the fast / parallel RRC setup in Approach 1.

[0564] The FFS whether Step 18 can be performed earlier (e.g., via Steps 6-13) in current BL CR to TS 38.401 is related to the following RAN2 discussion.

[0565] - FFS if each relay UE can establish RLC channel for relaying of SRB1 at the same time as its connection establishment in step 2

[0566] Regarding this issue, RAN2 concluded that the principle in Rel-17 U2N Relay is also applied to the Rel-19 Multi-hop Relay as highlighted below:

[0567] RAN2 assumes that discovery and PC5 connection establishment can be performed in each intermediate UE prior to processing the received RRCSetupRequest by the remote UE. The related FFS can be removed from the stage 2 description.

[0568] For the baseline solution, the last relay sending SUI on behalf of other relay UEs is not supported. The related FFS can be removed from the stage 2 description.

[0569] For the baseline solution, Rel17 SUI message and format is re-used.

[0570] No further clarification in stage 2 description is needed to clarify that a relay UE can establish its RLC channel for relaying of SRB1 from its immediate child node during its own connection establishment and details will be clarified in stage 3 (for example, follow legacy U2N procedure from Rel-17 to set up the RLC channel for SRB1). The related FFS can be removed from the stage 2 description.

[0571] For the last Editor's Note (for example, FFS whether this step can be performed earlier), we also think that the additional configuration of the PC5 / Uu Relay RLC channel to the U2N Relay UEs for relaying of U2N Remote UE's DRBs and SRBs can follow the legacy U2N procedure from Rel-17. There is no issue to support this functionality in Rel-19 multi-hop relay operation. Therefore, we propose to capture the same Note (for example, This step may be performed earlier) in Rel-17 U2N Relay into the BL CR to TS 38.401.

[0572] Proposal 9: It is proposed to change the following Editor's Notes into the Notes.

[0573] In order to capture the above observations and proposals, the following proposal is also suggested to RAN3:

[0574] Proposal 10: It is proposed to agree the corresponding TP for BL CR to TS 38.401 in Appendix #1.

[0575] Proposal 11: It is proposed to agree the corresponding TP for BL CR to TS 38.473 in Appendix #2.

[0576] In the aforementioned Embodiment 5 to Embodiment 7, multiplexing of SRBs and / or DRBs of a new UE (for example, U2N Relay UE and / or Remote UE) into an existing PC5 Relay RLC channel was considered. However, it is also possible for the gNB-CU to decide to multiplex SRBs and / or DRBs of an existing UE into the PC5 Relay RLC channel of another UE. In this case as well, the gNB-CU can inform the gNB-DU of information regarding the UE (for example, Remote UE and / or Relay UE) that will together use / utilize the existing PC5 Relay RLC channel configuration.

[0577] In addition, in the case of re-allocating / re-configuring SRBs and / or DRBs of some UEs among several UEs multiplexed into a specific PC5 Relay RLC channel to a new PC5 Relay channel, the gNB-CU delivers to the gNB-DU by adding the PC5 RLC Channel to Be Setup List IE within the UE CONTEXT MODIFICATION REQUEST message, and may delete information related to the aforementioned UE from the UE list using / utilizing the existing PC5 Relay RLC channel.

[0578] Alternatively, in the case of releasing SRBs and / or DRBs of some UEs among several UEs multiplexed into a specific PC5 Relay RLC channel, the gNB-CU may request the gNB-DU to delete information regarding the aforementioned UE from the UE list using / utilizing the existing PC5 Relay RLC channel.

[0579] Alternatively, when the gNB-DU requests modification, release, etc. regarding the PC5 Relay RLC channel toward the gNB-CU for some UEs among several UEs multiplexed into a specific PC5 Relay RLC channel (for example, when transmitting the UE CONTEXT MODIFICATION REQUIRED message), it may inform the gNB-CU by including information regarding the aforementioned UE within the PC5 RLC Channel Required to be Modified List IE or the PC5 RLC Channel Required to be Released List IE.

[0580] Unlike what was described in the aforementioned Embodiment 5 to Embodiment 6, considering the number of hops from the Remote UE, U2N Relay UE#3 may be referred to as a 1-hop U2N Relay UE (or the first U2N Relay UE or #1 U2N Relay UE or hop#1 U2N Relay UE), U2N Relay UE#2 may be referred to as a 2-hop U2N Relay UE (or the second U2N Relay UE or #2 U2N Relay UE or hop#2 U2N Relay UE), and U2N Relay UE#1 may be referred to as a 3-hop U2N Relay UE (or the third U2N Relay UE or #3 U2N Relay UE or hop#3 U2N Relay UE or last hop U2N Relay UE).

[0581] According to some embodiments of the present disclosure, the gNB-CU can inform the gNB-DU whether it must newly allocate / configure a PC5 Relay RLC channel for SRBs and / or DRBs of the U2N Remote UE, or whether to utilize an existing PC5 Relay RLC channel. The gNB-DU can identify the UE (for example, Relay UE and / or Remote UE) that sent the RRCSetupRequest message by utilizing the Remote UE local ID information received from the gNB-CU.

[0582] Some of the detailed steps shown in the examples of FIGS. 9 to 21 may not be essential steps and may be omitted. In addition to the steps shown in FIGS. 9 to 21, other steps may be added, and the order of the steps may vary. Some of the above steps may have their own technical meaning.

[0583] Hereinafter, a RAN node for support of multi-hop relay UE, according to some embodiments of the present disclosure, will be described.

[0584] The RAN node may be the gNB in FIG. 7. The RAN node may include a Central Unit (CU) and at least one Distributed Unit (DU).

[0585] A CU of a RAN node may include at least one memory and at least one processor operatively coupled to the at least one transceiver and the at least one memory. The at least one memory operably connectable to the at least one processor and storing instructions that, based on being executed by the at least one processor, perform operations comprising.

[0586] The operations comprise: receiving, from a last relay User Equipment (UE), UE information related to a inter-UE link including (i) information related to a Layer-2 identity (L2 ID) of a remote UE and (ii) information related to the last relay UE; transmitting, to the last relay UE, a radio resource control (RRC) reconfiguration message including information related to a local ID of the remote UE; receiving, from a distributed unit (DU) of the RAN node, an uplink RRC message transfer message including an RRC setup request for the remote UE; and transmitting, to the DU of the RAN node, a downlink RRC message transfer message including (i) information related to the L2 ID of the remote UE and (ii) an RRC setup message.

[0587] A DU of a RAN node may include at least one transceiver, at least one memory, and at least one processor operatively coupled to the at least one transceiver and the at least one memory. The at least one memory operably connectable to the at least one processor and storing instructions that, based on being executed by the at least one processor, perform operations comprising.

[0588] The operations comprise: receiving, from a last relay User Equipment (UE), UE information related to a inter-UE link including (i) information related to a Layer-2 identity (L2 ID) of a remote UE and (ii) information related to the last relay UE; forwarding, to a central unit (CU) of the RAN node, the UE information related to the inter-UE link including (i) information related to the L2 ID of the remote UE and (ii) information related to the last relay UE; receiving, from the CU of the RAN node, a radio resource control (RRC) reconfiguration message including information related to a local ID of the remote UE; forwarding, to the last relay UE, the RRC reconfiguration message including information related to the local ID of the remote UE; receiving, from the last relay UE, an RRC setup request message with a first header, wherein the first header includes information related to the local ID of the remote UE; transmitting, to the CU of the RAN node, an uplink RRC message transfer message including information related to the local ID of the remote UE; receiving, from the CU of the RAN node, a downlink RRC message transfer message including (i) the L2 ID of the remote UE and (ii) an RRC setup message for the remote UE; and transmitting, to the last relay UE, the RRC setup message for the remote UE with a second header, wherein the second SRAP header includes (i) the local ID of the remote UE and (ii) the L2 ID of the remote UE.

[0589] Hereinafter, a processor for a central unit (CU) of a radio access network (RAN) node for support of multi-hop relay UE, according to some embodiments of the present disclosure, will be described.

[0590] The processor may be adapted to the CU of the RAN node to perform operations.

[0591] The operations comprise: receiving, from a last relay User Equipment (UE), UE information related to a inter-UE link including (i) information related to a Layer-2 identity (L2 ID) of a remote UE and (ii) information related to the last relay UE; transmitting, to the last relay UE, a radio resource control (RRC) reconfiguration message including information related to a local ID of the remote UE; receiving, from a distributed unit (DU) of the RAN node, an uplink RRC message transfer message including an RRC setup request for the remote UE; and transmitting, to the DU of the RAN node, a downlink RRC message transfer message including (i) information related to the L2 ID of the remote UE and (ii) an RRC setup message.

[0592] Hereinafter, a non-transitory computer-readable medium has stored thereon a plurality of instructions for support of multi-hop relay UE, according to some embodiments of the present disclosure, will be described.

[0593] According to some embodiment of the present disclosure, the technical features of the present disclosure could be embodied directly in hardware, in a software executed by a processor, or in a combination of the two. For example, a method performed by a wireless device in a wireless communication may be implemented in hardware, software, firmware, or any combination thereof. For example, a software may reside in RAM memory, flash memory, ROM memory, EPROM memory, EEPROM memory, registers, hard disk, a removable disk, a CD-ROM, or any other storage medium.

[0594] Some example of storage medium is coupled to the processor such that the processor can read information from the storage medium. In the alternative, the storage medium may be integral to the processor. The processor and the storage medium may reside in an ASIC. For another example, the processor and the storage medium may reside as discrete components.

[0595] The computer-readable medium may include a tangible and non-transitory computer-readable storage medium.

[0596] 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 medium that can be used to store instructions or data structures. Non-transitory computer-readable media may also include combinations of the above.

[0597] In addition, the method described herein may be realized at least in part by a computer-readable communication medium that carries or communicates code in the form of instructions or data structures and that can be accessed, read, and / or executed by a computer.

[0598] According to some embodiment of the present disclosure, a non-transitory computer-readable medium has stored thereon a plurality of instructions.

[0599] When executed by a processor of a CU of a RAN node, cause the CU of the RAN node to perform operations.

[0600] The operations comprise: receiving, from a last relay User Equipment (UE), UE information related to a inter-UE link including (i) information related to a Layer-2 identity (L2 ID) of a remote UE and (ii) information related to the last relay UE; transmitting, to the last relay UE, a radio resource control (RRC) reconfiguration message including information related to a local ID of the remote UE; receiving, from a distributed unit (DU) of the RAN node, an uplink RRC message transfer message including an RRC setup request for the remote UE; and transmitting, to the DU of the RAN node, a downlink RRC message transfer message including (i) information related to the L2 ID of the remote UE and (ii) an RRC setup message.

[0601] Hereinafter, a UE for support of multi-hop relay UE, according to some embodiments of the present disclosure, will be described.

[0602] The UE may be the device in FIG. 2, FIG. 3, and FIG. 4. The RAN node may include a Central Unit (CU) and at least one Distributed Unit (DU).

[0603] A last relay User Equipment (UE) comprises: at least one transceiver; at least one processor; and at least one memory operably connectable to the at least one processor and the at least one transceiver. The at least one memory may store instructions that, based on being executed by the at least one processor, perform operations.

[0604] The operations comprise: receiving, from a second relay UE, a radio resource control (RRC) setup request message with a first header for a remote UE, wherein the first header includes information related to a Layer-2 identity (L2 ID) of the remote UE, and wherein the second relay UE is in RRC idle state or RRC inactive state; transmitting, to a distributed unit (DU) of a radio access network (RAN) node, UE information related to a inter-UE link including (i) information related to the L2 ID of the remote UE and (ii) information related to the last relay UE; receiving, from the DU of the RAN node, a radio resource control (RRC) reconfiguration message including information related to a local ID of the remote UE; forwarding, to the DU of the RAN node, the RRC setup request message with a second header, wherein the second header includes information related to the local ID of the remote UE; receiving, from the DU of the RAN node, an RRC setup message for the remote UE with a third header, wherein the third header includes (i) the local ID of the remote UE and (ii) the L2 ID of the remote UE; and forwarding, to the second relay UE, the RRC setup message for the remote UE with the third header.

[0605] Hereinafter, a method performed by a last relay UE for support of multi-hop relay UE, according to some embodiments of the present disclosure, will be described.

[0606] The method comprises: receiving, by a last relay User Equipment (UE) from a second relay UE, a radio resource control (RRC) setup request message with a first header for a remote UE, wherein the first header includes information related to a Layer-2 identity (L2 ID) of the remote UE, and wherein the second relay UE is in RRC idle state or RRC inactive state; transmitting, by the last relay UE to a distributed unit (DU) of a radio access network (RAN) node, UE information related to a inter-UE link including (i) information related to the L2 ID of the remote UE and (ii) information related to the last relay UE; receiving, by the the last relay UE from the DU of the RAN node, a radio resource control (RRC) reconfiguration message including information related to a local ID of the remote UE; forwarding, by the last relay UE to the DU of the RAN node, the RRC setup request message with a second header, wherein the second header includes information related to the local ID of the remote UE; receiving, by the last relay UE from the DU of the RAN node, an RRC setup message for the remote UE with a third header, wherein the third header includes (i) the local ID of the remote UE and (ii) the L2 ID of the remote UE; and forwarding, by the last relay UE to the second relay UE, the RRC setup message for the remote UE with the third header.

[0607] The present disclosure can have various advantageous effects.

[0608] According to some embodiments of the present disclosure, the radio access network (RAN) node could efficiently support the multi-hop relay UE and the remote UE.

[0609] For example, the SRAP header can be configured by considering idle / inactive relay UEs. Even if there are idle / inactive relay UEs, a CU / DU split RAN node can efficiently establish an RRC connection with the remote UE.

[0610] For example, in a Multi-hop U2N relaying scenario, by providing mapping information for the L2 ID and Local ID of the U2N Remote UE to U2N Relay UEs in RRC_IDLE or RRC_INACTIVE state, it allows the U2N Relay UE to deliver DL signaling and / or data coming from the base station to the U2N Remote UE.

[0611] Alternatively, in the case where a U2N Relay UE in RRC_IDLE or RRC_INACTIVE state transitions to RRC_CONNECTED state, because the base station can configure / allocate the PC5 Relay RLC channel for the PC5 connection related to the U2N Relay UE for UL / DL data transmission of the U2N Remote UEs connected through the U2N Relay UE, it can provide better performance to the U2N Remote UE.

[0612] Alternatively, in the case where the U2N Remote UE transitions to RRC_IDLE or RRC_INACTIVE state, because the base station can delete the Local ID-related information allocated for the U2N Remote UE from the U2N Relay UEs in RRC_IDLE or RRC_INACTIVE state, it can avoid a situation where different U2N Remote UEs use the same Local ID.

[0613] For example, in a multi-hop U2N relaying scenario, the gNB-DU becomes able to know the fact that the gNB-CU has allocated / configured the SRBs and / or DRBs of the U2N Remote UE to an existing PC5 Relay RLC channel, so PC5 Relay RLC channel resources can be efficiently managed.

[0614] In addition, it becomes able to receive local ID information regarding the Remote UE even in the situation, so the gNB-DU can identify the UE that sent the RRCSetupRequest message during the RRC Setup process.

[0615] Therefore, when the gNB-DU allocates / configures the PC5 Relay RLC channel configuration for SRB1 message transmission and includes it in the INITIAL UL RRC MESSAGE TRANSFER message, it can identify the counterpart of the corresponding PC5 Relay RLC channel in advance, so it is possible to avoid the gNB-DU allocating / configuring an incorrect PC5 Relay RLC channel.

[0616] Advantageous effects which can be obtained through specific embodiments of the present disclosure are not limited to the advantageous effects listed above. For example, there may be a variety of technical effects that a person having ordinary skill in the related art can understand and / or derive from the present disclosure. Accordingly, the specific effects of the present disclosure are not limited to those explicitly described herein, but may include various effects that may be understood or derived from the technical features of the present disclosure.

[0617] Advantageous effects which can be obtained through specific embodiments of the present disclosure are not limited to the advantageous effects listed above. For example, there may be a variety of technical effects that a person having ordinary skill in the related art can understand and / or derive from the present disclosure. Accordingly, the specific effects of the present disclosure are not limited to those explicitly described herein, but may include various effects that may be understood or derived from the technical features of the present disclosure.

[0618] Claims in the present disclosure can be combined in a various way. For instance, technical features in method claims of the present disclosure can be combined to be implemented or performed in an apparatus, and technical features in apparatus claims can be combined to be implemented or performed in a method. Further, technical features in method claim(s) and apparatus claim(s) can be combined to be implemented or performed in an apparatus. Further, technical features in method claim(s) and apparatus claim(s) can be combined to be implemented or performed in a method. Other implementations are within the scope of the following claims.

Claims

1.A method, comprising:receiving, by a central unit (CU) of a radio access network (RAN) node from a last relay User Equipment (UE), UE information related to a inter-UE link including (i) information related to a Layer-2 identity (L2 ID) of a remote UE and (ii) information related to the last relay UE;transmitting, by the CU of the RAN node to the last relay UE, a radio resource control (RRC) reconfiguration message including information related to a local ID of the remote UE;receiving, by the CU of the RAN node from a distributed unit (DU) of the RAN node, an uplink RRC message transfer message including an RRC setup request for the remote UE; andtransmitting, by the CU of the RAN node to the DU of the RAN node, a downlink RRC message transfer message including (i) information related to the L2 ID of the remote UE and (ii) an RRC setup message.2.The method of claim 1,wherein the RRC setup message is forwarded with a first header to the last relay UE via the DU of the RAN node,wherein the first header includes (i) information related to the L2 ID of the remote UE and (ii) information related to the local ID of the remote UE.3.The method of claim 2,wherein the first header includes a Sidelink Relay Adaptation Protocol (SRAP) header.4.The method of claim 2,wherein the first header is configured by the DU of the RAN node.5.The method of claim 2,wherein the RRC setup message is forwarded with the first header to at least one relay UE from via the last relay UE, andwherein the at least one relay UE is in RRC idle state or RRC inactive state.6.The method of claim 5,wherein the RRC setup message is forwarded to the remote UE via the at least one relay UE.7.The method of claim 5,wherein the RRC setup request for the remote UE is transmitted with a second header from the remote UE to the at least one relay UE, andwherein the second header includes information related to the L2 ID of the remote UE.8.The method of claim 7,wherein the RRC setup request for the remote UE is forwarded with the second header from the at least one relay UE to the last relay UE, andwherein the RRC setup request for the remote UE is forwarded with a third header from the last relay UE to the DU of the RAN node,wherein the third header includes the local ID of the remote UE.9.The method of claim 5,wherein an RRC release message is transmitted with a fourth header to the last relay UE and the at least one relay UE from the DU of the RAN node, andwherein the RRC release message is forwarded to the remote UE .10.The method of claim 9,wherein the fourth header includes information for releasing the local ID of the remote UE.11.The method of claim 1,wherein the local ID of the remote UE is valid only for a cell served by the DU of the RAN node.12.The method of claim 1,wherein the L2 ID of the remote UE is used for identifying the remote UE for the inter-UE link.13.The method of claim 1, wherein the method further comprising:allocating, by the CU of the RAN node, the local ID of the remote UE upon receiving the UE information related to the inter-UE link.14.The method of claim 1,wherein the remote UE is in communication with at least one of a user equipment, a network, or an autonomous vehicle other than remote UE.15.A method, comprising:receiving, by a distributed unit (DU) of a radio access network (RAN) node from a last relay User Equipment (UE), UE information related to a inter-UE link including (i) information related to a Layer-2 identity (L2 ID) of a remote UE and (ii) information related to the last relay UE;forwarding, by the DU of the RAN node to a central unit (CU) of the RAN node, the UE information related to the inter-UE link including (i) information related to the L2 ID of the remote UE and (ii) information related to the last relay UE;receiving, by the DU of the RAN node from the CU of the RAN node, a radio resource control (RRC) reconfiguration message including information related to a local ID of the remote UE;forwarding, by the DU of the RAN node to the last relay UE, the RRC reconfiguration message including information related to the local ID of the remote UE;receiving, by the DU of the RAN node from the last relay UE, an RRC setup request message with a first header, wherein the first header includes information related to the local ID of the remote UE;transmitting, by the DU of the RAN node to the CU of the RAN node, an uplink RRC message transfer message including information related to the local ID of the remote UE;receiving, by the DU of the RAN node from the CU of the RAN node, a downlink RRC message transfer message including (i) the L2 ID of the remote UE and (ii) an RRC setup message for the remote UE; andtransmitting, by the DU of the RAN node to the last relay UE, the RRC setup message for the remote UE with a second header,wherein the second SRAP header includes (i) the local ID of the remote UE and (ii) the L2 ID of the remote UE.16.A method, comprising:receiving, by a last relay User Equipment (UE) from a second relay UE, a radio resource control (RRC) setup request message with a first header for a remote UE,wherein the first header includes information related to a Layer-2 identity (L2 ID) of the remote UE, andwherein the second relay UE is in RRC idle state or RRC inactive state;transmitting, by the last relay UE to a distributed unit (DU) of a radio access network (RAN) node, UE information related to a inter-UE link including (i) information related to the L2 ID of the remote UE and (ii) information related to the last relay UE;receiving, by the the last relay UE from the DU of the RAN node, a radio resource control (RRC) reconfiguration message including information related to a local ID of the remote UE;forwarding, by the last relay UE to the DU of the RAN node, the RRC setup request message with a second header, wherein the second header includes information related to the local ID of the remote UE;receiving, by the last relay UE from the DU of the RAN node, an RRC setup message for the remote UE with a third header, wherein the third header includes (i) the local ID of the remote UE and (ii) the L2 ID of the remote UE; andforwarding, by the last relay UE to the second relay UE, the RRC setup message for the remote UE with the third header.17.A central unit (CU) of a radio access network (RAN) node, comprising:at least one processor; andat least one memory operably connectable to the at least one processor, and storing instructions that, based on being executed by the at least one processor, perform operations comprising:receiving, from a last relay User Equipment (UE), UE information related to a inter-UE link including (i) information related to a Layer-2 identity (L2 ID) of a remote UE and (ii) information related to the last relay UE;transmitting, to the last relay UE, a radio resource control (RRC) reconfiguration message including information related to a local ID of the remote UE;receiving, from a distributed unit (DU) of the RAN node, an uplink RRC message transfer message including an RRC setup request for the remote UE; andtransmitting, to the DU of the RAN node, a downlink RRC message transfer message including (i) information related to the L2 ID of the remote UE and (ii) an RRC setup message.18.A distributed unit (DU) of a radio access network (RAN) node, comprising:at least one transceiver;at least one processor; andat least one memory operably connectable to the at least one processor and the at least one transceiver, and storing instructions that, based on being executed by the at least one processor, perform operations comprising:receiving, from a last relay User Equipment (UE), UE information related to a inter-UE link including (i) information related to a Layer-2 identity (L2 ID) of a remote UE and (ii) information related to the last relay UE;forwarding, to a central unit (CU) of the RAN node, the UE information related to the inter-UE link including (i) information related to the L2 ID of the remote UE and (ii) information related to the last relay UE;receiving, from the CU of the RAN node, a radio resource control (RRC) reconfiguration message including information related to a local ID of the remote UE;forwarding, to the last relay UE, the RRC reconfiguration message including information related to the local ID of the remote UE;receiving, from the last relay UE, an RRC setup request message with a first header, wherein the first header includes information related to the local ID of the remote UE;transmitting, to the CU of the RAN node, an uplink RRC message transfer message including information related to the local ID of the remote UE;receiving, from the CU of the RAN node, a downlink RRC message transfer message including (i) the L2 ID of the remote UE and (ii) an RRC setup message for the remote UE; andtransmitting, to the last relay UE, the RRC setup message for the remote UE with a second header,wherein the second SRAP header includes (i) the local ID of the remote UE and (ii) the L2 ID of the remote UE.19.A last relay User Equipment (UE), comprising:at least one transceiver;at least one processor; andat least one memory operably connectable to the at least one processor and the at least one transceiver, and storing instructions that, based on being executed by the at least one processor, perform operations comprising:receiving, from a second relay UE, a radio resource control (RRC) setup request message with a first header for a remote UE,wherein the first header includes information related to a Layer-2 identity (L2 ID) of the remote UE, andwherein the second relay UE is in RRC idle state or RRC inactive state;transmitting, to a distributed unit (DU) of a radio access network (RAN) node, UE information related to a inter-UE link including (i) information related to the L2 ID of the remote UE and (ii) information related to the last relay UE;receiving, from the DU of the RAN node, a radio resource control (RRC) reconfiguration message including information related to a local ID of the remote UE;forwarding, to the DU of the RAN node, the RRC setup request message with a second header, wherein the second header includes information related to the local ID of the remote UE;receiving, from the DU of the RAN node, an RRC setup message for the remote UE with a third header, wherein the third header includes (i) the local ID of the remote UE and (ii) the L2 ID of the remote UE; andforwarding, to the second relay UE, the RRC setup message for the remote UE with the third header.20.A processor for a central unit (CU) of a radio access network (RAN) node in a wireless communication system, wherein the processor is adapted to the CU of the RAN node to perform operations comprising:receiving, from a last relay User Equipment (UE), UE information related to a inter-UE link including (i) information related to a Layer-2 identity (L2 ID) of a remote UE and (ii) information related to the last relay UE;transmitting, to the last relay UE, a radio resource control (RRC) reconfiguration message including information related to a local ID of the remote UE;receiving, from a distributed unit (DU) of the RAN node, an uplink RRC message transfer message including an RRC setup request for the remote UE; andtransmitting, to the DU of the RAN node, a downlink RRC message transfer message including (i) information related to the L2 ID of the remote UE and (ii) an RRC setup message.21.A non-transitory computer-readable medium having stored thereon a plurality of instructions, which, when executed by a central unit (CU) of a radio access network (RAN) node, cause the CU of the RAN node to perform operations, the operations comprising,receiving, from a last relay User Equipment (UE), UE information related to a inter-UE link including (i) information related to a Layer-2 identity (L2 ID) of a remote UE and (ii) information related to the last relay UE;transmitting, to the last relay UE, a radio resource control (RRC) reconfiguration message including information related to a local ID of the remote UE;receiving, from a distributed unit (DU) of the RAN node, an uplink RRC message transfer message including an RRC setup request for the remote UE; andtransmitting, to the DU of the RAN node, a downlink RRC message transfer message including (i) information related to the L2 ID of the remote UE and (ii) an RRC setup message.

Images