Communication system and base station

Abstract

This communication system comprises a first base station composed of a central unit (IAB-Donor CU) and a distributed unit (IAB-Donor DU) and operating as an integrated access backhaul donor, and at least one second base station operating as an integrated access backhaul node (IAB-node). The central unit performs, with respect to the distributed unit and the second base station, address configuration for multicasting data from the central unit to a communication terminal in a backhaul adaptation layer in which data transmitted and received to and from the communication terminal is routed.

Description

Communication system and base station

[0001] The present disclosure relates to wireless communication technology.

[0002] The 3GPP (3rd Generation Partnership Project), a standardization organization for mobile communication systems, is considering a communication method called Long Term Evolution (LTE) for wireless sections and System Architecture Evolution (SAE) for the overall system configuration including the core network and radio access network (hereinafter collectively referred to as the network) (see, for example, Non-Patent Documents 1 to 5). This communication method is also called a 3.9G (3.9 Generation) system.

[0003] LTE uses Orthogonal Frequency Division Multiplexing (OFDM) for downlink and Single Carrier Frequency Division Multiple Access (SC-FDMA) for uplink as its access method. Unlike Wideband Code Division Multiple Access (W-CDMA), LTE does not include circuit switching and is only a packet communication method.

[0004] The decisions made by 3GPP regarding the frame configuration in an LTE system, as described in Non-Patent Document 1 (Chapter 5), will be explained using FIG. 1. FIG. 1 is an explanatory diagram showing the configuration of a radio frame used in an LTE communication system. In FIG. 1, one radio frame is 10 ms. The radio frame is divided into 10 equally sized subframes. The subframe is divided into two equally sized slots. The first and sixth subframes of each radio frame include a downlink synchronization signal. The synchronization signals include a primary synchronization signal (P-SS) and a secondary synchronization signal (S-SS).

[0005] The decisions made by 3GPP regarding the channel configuration in the LTE system are described in Non-Patent Document 1 (Chapter 5). It is assumed that the same channel configuration as that of a non-CSG cell is used in a CSG (Closed Subscriber Group) cell.

[0006] The Physical Broadcast Channel (PBCH) is a channel for downlink transmission from a base station apparatus (hereinafter sometimes simply referred to as a "base station") to a communication terminal apparatus (hereinafter sometimes simply referred to as a "communication terminal") such as a mobile terminal apparatus (hereinafter sometimes simply referred to as a "mobile terminal"). A BCH transport block is mapped to four subframes in a 40 ms interval. There is no explicit signaling of the 40 ms timing.

[0007] The Physical Control Format Indicator Channel (PCFICH) is a channel for downlink transmission from a base station to a communication terminal. The PCFICH notifies the communication terminal of the number of Orthogonal Frequency Division Multiplexing (OFDM) symbols used for PDCCHs. The PCFICH is transmitted every subframe.

[0008] The Physical Downlink Control Channel (PDCCH) is a channel for downlink transmission from a base station to a communication terminal. The PDCCH reports resource allocation information for a Downlink Shared Channel (DL-SCH), which is one of the transport channels described below, resource allocation information for a Paging Channel (PCH), which is one of the transport channels described below, and Hybrid Automatic Repeat reQuest (HARQ) information related to the DL-SCH. The PDCCH carries an Uplink Scheduling Grant. The PDCCH carries Acknowledgement (Ack) / Negative Acknowledgement (Nack), which are response signals to uplink transmission. The PDCCH is also called an L1 / L2 control signal.

[0009] The Physical Downlink Shared Channel (PDSCH) is a channel for downlink transmission from a base station to a communication terminal. The Downlink Shared Channel (DL-SCH), which is a transport channel, and the PCH, which is a transport channel, are mapped to the PDSCH.

[0010] A physical multicast channel (PMCH) is a channel for downlink transmission from a base station to communication terminals, and a multicast channel (MCH), which is a transport channel, is mapped to the PMCH.

[0011] The Physical Uplink Control Channel (PUCCH) is a channel for uplink transmission from a communication terminal to a base station. The PUCCH carries Ack / Nack, which is a response signal to a downlink transmission. The PUCCH carries Channel State Information (CSI). The CSI is composed of a Rank Indicator (RI), a Precoding Matrix Indicator (PMI), and a Channel Quality Indicator (CQI) report. The RI is rank information of a channel matrix in MIMO. The PMI is information on a precoding weight matrix used in MIMO. The CQI is quality information indicating the quality of received data or the quality of a communication channel. The PUCCH also carries a Scheduling Request (SR).

[0012] The Physical Uplink Shared Channel (PUSCH) is a channel for uplink transmission from a communication terminal to a base station. The Uplink Shared Channel (UL-SCH), which is one of the transport channels, is mapped to the PUSCH.

[0013] The Physical Hybrid ARQ Indicator Channel (PHICH) is a channel for downlink transmission from a base station to a communication terminal. The PHICH carries Ack / Nack, which is a response signal to an uplink transmission. The Physical Random Access Channel (PRACH) is a channel for uplink transmission from a communication terminal to a base station. The PRACH carries a random access preamble.

[0014] A downlink reference signal (RS) is a known symbol in an LTE communication system. The following five types of downlink reference signals are defined: a cell-specific reference signal (CRS), an MBSFN reference signal, a demodulation reference signal (DM-RS) which is a UE-specific reference signal, a positioning reference signal (PRS), and a channel state information reference signal (CSI-RS). Measurement of the physical layer of a communication terminal includes measurement of the reference signal received power (RSRP).

[0015] Similarly, the uplink reference signal is a symbol known in the LTE communication system. The following two types of uplink reference signals are defined: a data demodulation reference signal (DM-RS) and a sounding reference signal (SRS).

[0016] The transport channels described in Non-Patent Document 1 (Chapter 5) will be described below. Among the downlink transport channels, a broadcast channel (BCH) is broadcast to the entire coverage of the base station (cell). The BCH is mapped to a physical broadcast channel (PBCH).

[0017] Retransmission control using Hybrid ARQ (HARQ) is applied to the Downlink Shared Channel (DL-SCH). The DL-SCH can be broadcast to the entire coverage of a base station (cell). The DL-SCH supports dynamic or semi-static resource allocation. Semi-static resource allocation is also called persistent scheduling. The DL-SCH supports discontinuous reception (DRX) in communication terminals to reduce power consumption of the communication terminals. The DL-SCH is mapped to the Physical Downlink Shared Channel (PDSCH).

[0018] The Paging Channel (PCH) supports DRX of communication terminals to enable low power consumption of the communication terminals. The PCH is required to broadcast to the entire coverage of the base station (cell). The PCH is mapped to physical resources such as the Physical Downlink Shared Channel (PDSCH) that can be dynamically used for traffic.

[0019] The Multicast Channel (MCH) is used for broadcasting to the entire coverage of a base station (cell). The MCH supports SFN combining of MBMS (Multimedia Broadcast Multicast Service) services (MTCH and MCCH) in multi-cell transmission. The MCH supports semi-static resource allocation. The MCH is mapped to the PMCH.

[0020] Among the uplink transport channels, the uplink shared channel (UL-SCH) is subject to retransmission control using Hybrid ARQ (HARQ). The UL-SCH supports dynamic or semi-static resource allocation. The UL-SCH is mapped to the physical uplink shared channel (PUSCH).

[0021] The Random Access Channel (RACH) is limited to control information, has a risk of collision, and is mapped to the Physical Random Access Channel (PRACH).

[0022] The following describes HARQ. HARQ is a technology that improves the communication quality of a transmission path by combining Automatic Repeat reQuest (ARQ) and Forward Error Correction. HARQ has the advantage that error correction functions effectively through retransmission even for transmission paths whose communication quality varies. In particular, by combining the reception result of the initial transmission and the reception result of the retransmission when retransmitting, it is possible to obtain further quality improvement.

[0023] An example of a retransmission method will be described below. If the receiving side is unable to decode the received data correctly, in other words, if a CRC (Cyclic Redundancy Check) error occurs (CRC=NG), the receiving side will send a "Nack" to the transmitting side. The transmitting side, having received the "Nack", will retransmit the data. If the receiving side is able to decode the received data correctly, in other words, if no CRC error occurs (CRC=OK), the receiving side will send an "Ack" to the transmitting side. The transmitting side, having received the "Ack", will send the next data.

[0024] The logical channels described in Non-Patent Document 1 (Chapter 6) are explained below. The Broadcast Control Channel (BCCH) is a downlink channel for broadcast system control information. The BCCH, which is a logical channel, is mapped to the broadcast channel (BCH) or the downlink shared channel (DL-SCH), which are transport channels.

[0025] The Paging Control Channel (PCCH) is a downlink channel for transmitting paging information and changes to system information. The PCCH is used when the cell location of a communication terminal is unknown to the network. The PCCH, which is a logical channel, is mapped to the Paging Channel (PCH), which is a transport channel.

[0026] The Common Control Channel (CCCH) is a channel for transmission control information between a communication terminal and a base station. The CCCH is used when the communication terminal does not have an RRC connection with the network. In the downlink direction, the CCCH is mapped to the Downlink Shared Channel (DL-SCH), which is a transport channel. In the uplink direction, the CCCH is mapped to the Uplink Shared Channel (UL-SCH), which is a transport channel.

[0027] The Multicast Control Channel (MCCH) is a downlink channel for point-to-multipoint transmission. The MCCH is used to transmit MBMS control information for one or several MTCHs from the network to communication terminals. The MCCH is used only by communication terminals receiving MBMS. The MCCH is mapped to the Multicast Channel (MCH), which is a transport channel.

[0028] A Dedicated Control Channel (DCCH) is a channel that transmits dedicated control information between a communication terminal and a network in a one-to-one relationship. The DCCH is used when the communication terminal is in an RRC connection. The DCCH is mapped to an uplink shared channel (UL-SCH) in the uplink and to a downlink shared channel (DL-SCH) in the downlink.

[0029] A Dedicated Traffic Channel (DTCH) is a point-to-point communication channel for transmitting user information to an individual communication terminal. DTCH exists in both uplink and downlink. In uplink, DTCH is mapped to an uplink shared channel (UL-SCH) and in downlink, it is mapped to a downlink shared channel (DL-SCH).

[0030] A Multicast Traffic Channel (MTCH) is a downlink channel for transmitting traffic data from a network to communication terminals. The MTCH is a channel used only by communication terminals receiving MBMS. The MTCH is mapped to a Multicast Channel (MCH).

[0031] CGI stands for Cell Global Identifier. ECGI stands for E-UTRAN Cell Global Identifier. LTE, LTE-A (Long Term Evolution Advanced) (described later), and UMTS (Universal Mobile Telecommunication System) introduce CSG (Closed Subscriber Group) cells.

[0032] The location of a communication terminal is tracked in units of an area consisting of one or more cells. Location tracking is performed to track the location of the communication terminal even when it is in standby mode and to enable the communication terminal to be called, in other words, to enable the communication terminal to receive calls. The area for tracking the location of this communication terminal is called a tracking area.

[0033] 3GPP is also currently working on the development of the Long Term Evolution Advanced (LTE-A) standard as Release 10 (see Non-Patent Documents 3 and 4). LTE-A is based on the LTE wireless communication system, and is configured by adding several new technologies to it.

[0034] In the LTE-A system, in order to support wider frequency bandwidths (transmission bandwidths) up to 100 MHz, carrier aggregation (CA) is being considered, which aggregates (also referred to as "aggregation") two or more component carriers (CCs). CA is described in Non-Patent Document 1.

[0035] When CA is configured, a communication terminal (UE) has only one RRC connection with the network (NW). In the RRC connection, one serving cell provides NAS mobility information and security input. This cell is called a primary cell (PCell). In the downlink, the carrier corresponding to the PCell is the downlink primary component carrier (DL PCC). In the uplink, the carrier corresponding to the PCell is the uplink primary component carrier (UL PCC).

[0036] Depending on the UE's capabilities, a secondary cell (SCell) is configured to form a serving cell set together with the PCell. In the downlink, the carrier corresponding to the SCell is the Downlink Secondary Component Carrier (DL SCC). In the uplink, the carrier corresponding to the SCell is the Uplink Secondary Component Carrier (UL SCC).

[0037] A set of serving cells consisting of one PCell and one or more SCells is configured for one UE.

[0038] Furthermore, new technologies for LTE-A include a technology that supports wider bandwidth (Wider Bandwidth Extension) and a Coordinated Multiple Point transmission and reception (CoMP) technology. CoMP, which is being studied for LTE-A by 3GPP, is described in Non-Patent Document 1.

[0039] Furthermore, in order to handle future massive traffic volumes, 3GPP is considering the use of small eNBs (hereinafter sometimes referred to as "small-scale base station devices") that configure small cells. For example, technologies are being considered that improve frequency utilization efficiency and increase communication capacity by installing a large number of small eNBs and configuring a large number of small cells. Specifically, there is dual connectivity (abbreviated as DC), in which a UE connects to two eNBs to communicate. DC is described in Non-Patent Document 1.

[0040] Of the eNBs that perform dual connectivity (DC), one may be referred to as a "master eNB (abbreviated as MeNB)" and the other as a "secondary eNB (abbreviated as SeNB)."

[0041] Mobile network traffic volume is on the rise, and communication speeds are also increasing. Once LTE and LTE-A begin full-scale operation, communication speeds are expected to increase even further.

[0042] Furthermore, in response to the increasing sophistication of mobile communications, fifth-generation (hereinafter sometimes referred to as "5G") wireless access systems are being considered, with the goal of launching services after 2020. For example, in Europe, an organization called METIS has compiled requirements for 5G (see Non-Patent Document 5).

[0043] The requirements for a 5G wireless access system are that it will have 1,000 times the system capacity, 100 times the data transmission speed, one-tenth (1 / 10) the data processing delay, and 100 times the number of simultaneous connections of communication terminals compared to an LTE system, while also achieving further reductions in power consumption and lower costs for the equipment.

[0044] To meet these demands, 3GPP is currently working on 5G standards as Release 15 (see Non-Patent Documents 6 to 19). 5G wireless access technology is called "New Radio Access Technology" ("New Radio" is abbreviated as "NR").

[0045] The NR system is being studied based on the LTE system and LTE-A system, but the following changes and additions have been made to the LTE system and LTE-A system.

[0046] The access method for NR is OFDM in the downlink direction and OFDM and DFT-s-OFDM (DFT-spread-OFDM) in the uplink direction.

[0047] NR allows the use of higher frequencies than LTE in order to improve transmission speeds and reduce processing delays.

[0048] In NR, cell coverage is ensured by forming a narrow beam-shaped transmission and reception range (beam forming) and changing the direction of the beam (beam sweeping).

[0049] In the NR frame structure, various subcarrier spacings, i.e., various numerologies, are supported. In NR, regardless of the numerology, one subframe is 1 millisecond, and one slot consists of 14 symbols. In addition, the number of slots included in one subframe is one in a numerology with a subcarrier spacing of 15 kHz, but in other numerologies, the number of slots increases in proportion to the subcarrier spacing (see Non-Patent Document 13 (3GPP TS38.211)).

[0050] The downlink synchronization signal in NR is transmitted from the base station as a synchronization signal burst (hereinafter sometimes referred to as an SS burst) at a predetermined cycle for a predetermined duration. The SS burst is composed of a synchronization signal block (hereinafter sometimes referred to as an SS block) for each beam of the base station.

[0051] The base station transmits the SS block of each beam by changing the beam during the duration of the SS burst. The SS block consists of the P-SS, S-SS, and PBCH.

[0052] In NR, the influence of phase noise is reduced by adding a phase tracking reference signal (PTRS) as a downlink reference signal of NR. PTRS is also added to the uplink reference signal in the same way as in the downlink.

[0053] In NR, in order to flexibly switch between DL and UL within a slot, slot format indication (SFI) has been added to the information contained in the PDCCH.

[0054] In addition, in NR, the base station pre-sets a portion of the carrier frequency band (hereinafter sometimes referred to as the Bandwidth Part (BWP)) for the UE, and the UE transmits and receives data to and from the base station using this BWP, thereby reducing power consumption in the UE.

[0055] In 3GPP, the following DC forms are being considered: DC using LTE base stations and NR base stations connected to EPC, DC using NR base stations connected to a 5G core system, and DC using LTE base stations and NR base stations connected to a 5G core system (see Non-Patent Documents 12, 16, and 19).

[0056] Additionally, 3GPP is considering supporting services (or applications) using side link (SL) communication (also referred to as PC5 communication) in both the Evolved Packet System (EPS) (described later) and the 5G core system (see Non-Patent Documents 1, 16, 20, 21, 22, and 23). SL communication involves communication between terminals. Services using SL communication include, for example, vehicle-to-everything (V2X) services and proximity services. In SL communication, not only direct communication between terminals but also communication between a UE and a network via a relay has been proposed (see Non-Patent Documents 20, 23, 26, and 27).

[0057] 3GPP is also studying several new technologies. For example, multicast using NR is being studied. Regarding multicast using NR, for example, a multicast method that ensures reliability and dynamic switching between Point To Multipoint (PTM) transmission and Point To Point (PTP) transmission are being studied (see Non-Patent Documents 28, 29, and 30). Also, multicast in a base station with a CU (Central Unit) / DU (Distributed Unit) separated configuration is being studied (see Non-Patent Document 31).

[0058] As another example, Integrated Access and Backhaul (IAB) is being considered, in which both the access link between the UE and the base station and the backhaul link between the base stations are wireless (see Non-Patent Documents 16, 32, and 33).

[0059] 3GPP TS 36.300 V16.5.03GPP S1-0834613GPP TR 36.814 V9.2.03GPP TR 36.912 V16.0.0“Scenarios, requirements and KPIs for 5G mobile and wireless system”、ICT-317669-METIS / D1.13GPP TR 23.799 V14.0.03GPP TR 38.801 V14.0.03GPP TR 38.802 V14.2.03GPP TR 38.804 V14.0.03GPP TR 38.912 V16.0.03GPP RP-1721153GPP TS 37.340 V16.5.03GPP TS 38.211 V16.5.03GPP TS 38.213 V16.5.03GPP TS 38.214 V16.5.03GPP TS 38.300 V16.5.03GPP TS 38.321 V16.4.03GPP TS 38.212 V16.5.03GPP TS 38.331 V16.4.13GPP TR 23.703 V12.0.03GPP TS 23.501 V17.0.03GPP TS 23.287 V16.5.03GPP TS 23.303 V16.0.03GPP TS 38.305 V16.4.03GPP TS 23.273 V17.0.03GPP R2-20091453GPP TR 38.836 V17.0.03GPP TR 23.757 V17.0.03GPP RP-2010383GPP R2-20093373GPP R3-2110293GPP RP-2012933GPP TS 38.401 V16.5.03GPP TS 36.321 V16.4.03GPP TS 38.473 V16.5.03GPP TS 38.340 V16.4.03GPP TS 23.502 V17.0.03GPP TS 38.413 V16.5.03GPP TS 38.323 V16.3.03GPP TS 38.322 V16.2.03GPP R3-210017

[0060] 5G base stations can support integrated access and backhaul (IAB) (see Non-Patent Document 16 (TS38.300)). It has also been proposed to perform multicast using a base station that supports IAB (hereinafter, sometimes referred to as an IAB base station) (see Non-Patent Document 41 (R3-210017)). However, detailed methods for configuring multicast in an IAB base station, particularly settings in the BAP (Backhaul Adaptation Protocol) layer that performs routing between IAB nodes, are not disclosed. Therefore, a problem arises in that multicast using an IAB base station cannot be realized.

[0061] In view of the above-mentioned problems, one of the objects of the present disclosure is to enable multicast transmission in a communication system to which access and backhaul integration is applied.

[0062] The communication system according to the present disclosure is composed of a central unit and distributed units, and includes a first base station operating as an access / backhaul integration donor, and one or more second base stations operating as access / backhaul integration nodes, and the central unit configures addresses for multicasting data from the central unit to the communication terminals in a backhaul adaptation layer that routes data transmitted and received by the communication terminals to the distributed units and the second base stations.

[0063] The present disclosure provides an advantage in that multicast transmission becomes possible in a communication system to which access and backhaul integration is applied.

[0064] The objects, features, aspects, and advantages of the present disclosure will become more apparent from the following detailed description and the accompanying drawings.

[0065] 1 is an explanatory diagram showing the configuration of a radio frame used in an LTE communication system. FIG. 1 is a block diagram showing the overall configuration of an LTE communication system 200 being discussed in 3GPP. FIG. 2 is a block diagram showing the overall configuration of an NR communication system 210 being discussed in 3GPP. FIG. 3 is a block diagram showing the configuration of a DC by an eNB and a gNB connected to an EPC. FIG. 4 is a block diagram showing the configuration of a DC by a gNB connected to an NG core. FIG. 5 is a block diagram showing the configuration of a DC by an eNB and a gNB connected to an NG core. FIG. 6 is a block diagram showing the configuration of a mobile terminal 202 shown in FIG. 2. FIG. 7 is a block diagram showing the configuration of a base station 203 shown in FIG. 2. FIG. 8 is a block diagram showing the configuration of an MME. FIG. 9 is a block diagram showing the configuration of a 5GC unit. FIG. 10 is a flowchart showing an overview of the process from cell search to standby operation performed by a communication terminal (UE) in an LTE communication system. FIG. 11 is a diagram showing an example of the configuration of a cell in an NR system. FIG. 12 is a diagram showing an example of a list of BAP addresses for a first embodiment. FIG. 13 is a diagram showing an example of a BAP header for a first embodiment. FIG. 14 is a diagram showing another example of a BAP header for a first embodiment. FIG. 1 is a diagram showing another example of a BAP header for the first embodiment. FIG. 2 is a diagram showing another example of a BAP header for the first embodiment. FIG. 3 is a diagram showing another example of a BAP header for the first embodiment. FIG. 4 is a diagram showing the first half of a sequence showing an example of multicast configuration in an IAB base station for the first embodiment. FIG. 5 is a diagram showing the second half of a sequence showing an example of multicast configuration in an IAB base station for the first embodiment. FIG. 6 is a diagram showing an example of allocation of a multicast BAP address for the first embodiment. FIG. 7 is a diagram showing another example of allocation of a multicast BAP address for the first embodiment. FIG. 8 is a diagram showing a bitmap of a multicast BAP address for the first embodiment. FIG. 9 is a diagram showing another example of allocation of a multicast BAP address for the first embodiment.1 is a diagram showing another example of allocation of a BAP address for multicast according to the first embodiment. FIG. 2 is a diagram showing another example of allocation of a BAP address for multicast according to the first embodiment. FIG. 3 is a diagram showing an example of a replication operation in the BAP layer according to the second embodiment. FIG. 4 is a diagram showing another example of a replication operation in the BAP layer according to the second embodiment. FIG. 5 is a diagram showing another example of a replication operation in the BAP layer according to the second embodiment. FIG. 6 is a diagram showing an example of a replication operation in an end IAB node on a protocol stack from an IAB donor CU to a UE according to the second embodiment. FIG. 7 is a diagram showing an example of a merger of multiple data paths along the way according to the third embodiment. FIG. 8 is a conceptual diagram of a case where a relay UE connects to two gNBs in communication between a remote UE and a NW via a relay UE according to the fourth embodiment. FIG. 9 is a diagram showing a protocol stack of a case where a relay UE connects to two gNBs in communication between a remote UE and a NW via a relay UE according to the fourth embodiment. 10 is a diagram showing another configuration method of a protocol stack when a relay UE connects to two gNBs in communication between a remote UE and a NW via a relay UE, for a fourth embodiment. FIG. 11 is a diagram showing another configuration method of a protocol stack when a relay UE connects to two gNBs in communication between a remote UE and a NW via a relay UE, for a fourth embodiment. FIG. 12 is a sequence diagram showing an example of a method for setting a DC in which a relay UE connects to two gNBs, for a fourth embodiment. FIG. 13 is a sequence diagram showing another example of a method for setting a DC in which a relay UE connects to two gNBs, for a fourth embodiment. FIG. 14 is a conceptual diagram showing an example of a case in which a remote UE connects to two gNBs in communication between a remote UE and a NW via a relay UE, for a fifth embodiment. FIG. 15 is a conceptual diagram showing another example of a case in which a remote UE connects to two gNBs in communication between a remote UE and a NW via a relay UE, for a fifth embodiment. FIG. 16 is a conceptual diagram showing another example of a case in which a remote UE connects to two gNBs in communication between a remote UE and a NW via a relay UE, for a fifth embodiment.10 is a diagram showing a protocol stack for a case where a remote UE connects to two gNBs in communication between a remote UE and a NW via a relay UE, for a fifth embodiment. FIG. 11 is a sequence diagram showing an example of a method for setting a DC in which a remote UE connects to two gNBs, for a fifth embodiment. FIG. 12 is a diagram showing another method for configuring a protocol stack for a case where a remote UE connects to two gNBs in communication between a remote UE and a NW via a relay UE, for a fifth embodiment. FIG. 13 is a sequence diagram showing an example of a method for setting a DC in which a remote UE connects to two gNBs, for a fifth embodiment. FIG. 14 is a diagram showing another method for configuring a protocol stack for a case where a remote UE connects to two gNBs in communication between a remote UE and a NW via a relay UE, for a sixth embodiment. FIG. 15 is a sequence diagram showing an example of a method for setting a DC in which a remote UE connects to two gNBs, for a sixth embodiment. FIG. 16 is a conceptual diagram showing an example of a case where a remote UE connects to one gNB via two paths in communication between a remote UE and a NW via a relay UE, for a sixth embodiment. 10 is a conceptual diagram showing another example of a case where a remote UE connects to one gNB via two paths in communication between a remote UE and a NW via a relay UE, for a sixth embodiment. FIG. 10 is a diagram showing a protocol stack when a DC is set in a remote UE using a MN and a relay UE #S that substitutes for an SN in communication between a remote UE and a NW, for a sixth embodiment. FIG. 10 is a diagram showing a protocol stack between a MN and a relay UE #S, for a sixth embodiment. FIG. 10 is a sequence diagram showing an example of a method for setting a DC in which a remote UE connects to one gNB via two paths, for a sixth embodiment. FIG. 10 is a diagram showing another method for configuring a protocol stack when a DC is set in a remote UE using a MN and a relay UE #S that substitutes for an SN in communication between a remote UE and a NW, for a sixth embodiment.

[0066] A communication system and a base station according to an embodiment of the present disclosure will be described in detail below with reference to the accompanying drawings.

[0067] First Embodiment Fig. 2 is a block diagram showing the overall configuration of an LTE communication system 200 being discussed in 3GPP. Fig. 2 will be described. The radio access network is called E-UTRAN (Evolved Universal Terrestrial Radio Access Network) 201. A mobile terminal device (hereinafter referred to as "mobile terminal (User Equipment: UE)") 202, which is a communication terminal device, is capable of wireless communication with a base station device (hereinafter referred to as "base station (E-UTRAN NodeB: eNB)") 203, and transmits and receives signals via wireless communication.

[0068] Here, the term "communication terminal device" includes not only mobile terminal devices such as mobile cell phone terminal devices, but also stationary devices such as sensors. In the following description, the term "communication terminal device" may be simply referred to as a "communication terminal."

[0069] If control protocols for mobile terminals 202, such as RRC (Radio Resource Control), and user planes (hereinafter sometimes referred to as U-Plane), such as PDCP (Packet Data Convergence Protocol), RLC (Radio Link Control), MAC (Medium Access Control), and PHY (Physical layer), terminate at base stations 203, then E-UTRAN is composed of one or more base stations 203.

[0070] The control protocol RRC (Radio Resource Control) between the mobile terminal 202 and the base station 203 performs broadcasting, paging, RRC connection management, etc. The states of the base station 203 and the mobile terminal 202 in RRC include RRC_IDLE and RRC_CONNECTED.

[0071] In RRC_IDLE, PLMN (Public Land Mobile Network) selection, system information (SI) broadcast, paging, cell re-selection, mobility, etc. are performed. In RRC_CONNECTED, the mobile terminal has an RRC connection and can transmit and receive data to and from the network. In addition, in RRC_CONNECTED, handover (HO), measurement of neighbor cells, etc. are performed.

[0072] The base station 203 is configured by one or more eNBs 207. A system configured by an EPC (Evolved Packet Core) which is a core network and an E-UTRAN 201 which is a radio access network is called an EPS (Evolved Packet System). The EPC which is a core network and the E-UTRAN 201 which is a radio access network may be collectively referred to as a "network."

[0073] The eNB 207 is connected to a Mobility Management Entity (MME), or a Serving Gateway (S-GW), or an MME / S-GW unit (hereinafter sometimes referred to as an "MME unit") 204 including an MME and an S-GW via an S1 interface, and control information is communicated between the eNB 207 and the MME unit 204. Multiple MME units 204 may be connected to one eNB 207. The eNBs 207 are connected to each other via an X2 interface, and control information is communicated between the eNBs 207.

[0074] The MME unit 204 is an upper device, specifically an upper node, and controls the connection between the eNB 207, which is a base station, and the mobile terminal (UE) 202. The MME unit 204 constitutes the EPC, which is a core network. The base station 203 constitutes the E-UTRAN 201.

[0075] The base station 203 may configure one cell or multiple cells. Each cell has a predetermined range as its coverage, which is the range within which communication with the mobile terminal 202 is possible, and wireless communication with the mobile terminal 202 is performed within the coverage. When one base station 203 configures multiple cells, each cell is configured to be able to communicate with the mobile terminal 202.

[0076] FIG. 3 is a block diagram showing the overall configuration of a 5G communication system 210 being discussed in 3GPP. Referring to FIG. 3, the radio access network is referred to as an NG-RAN (Next Generation Radio Access Network) 211. The UE 202 is capable of wireless communication with an NR base station device (hereinafter referred to as an "NR base station (NG-RAN NodeB: gNB)") 213, and transmits and receives signals via wireless communication. The core network is referred to as a 5G Core (5GC).

[0077] If control protocols for UE202, such as RRC (Radio Resource Control), and user planes (hereinafter sometimes referred to as U-Plane), such as SDAP (Service Data Adaptation Protocol), PDCP (Packet Data Convergence Protocol), RLC (Radio Link Control), MAC (Medium Access Control), and PHY (Physical layer), terminate at the NR base station 213, the NG-RAN is composed of one or more NR base stations 213.

[0078] The function of the control protocol RRC (Radio Resource Control) between the UE 202 and the NR base station 213 is the same as that of LTE. The states of the NR base station 213 and the UE 202 in RRC include RRC_IDLE, RRC_CONNECTED, and RRC_INACTIVE.

[0079] RRC_IDLE and RRC_CONNECTED are the same as those in the LTE system. RRC_INACTIVE maintains the connection between the 5G core and the NR base station 213, and performs system information (SI), paging, cell reselection, mobility, etc.

[0080] The gNB217 is connected to an AMF / SMF / UPF unit (hereinafter sometimes referred to as the "5GC unit") 214 including an Access and Mobility Management Function (AMF), a Session Management Function (SMF), or a User Plane Function (UPF), or an AMF, SMF, and UPF, via an NG interface. Control information and / or user data is communicated between the gNB217 and the 5GC unit 214. The NG interface is a collective term for the N2 interface between the gNB217 and the AMF, the N3 interface between the gNB217 and the UPF, the N11 interface between the AMF and the SMF, and the N4 interface between the UPF and the SMF. Multiple 5GC units 214 may be connected to one gNB217. The gNBs 217 are connected via an Xn interface, and control information and / or user data is communicated between the gNBs 217.

[0081] The 5GC unit 214 is an upper device, specifically an upper node, and distributes paging signals to one or more base stations 203 and / or base stations 213. The 5GC unit 214 also performs mobility control in an idle state. The 5GC unit 214 manages a tracking area list when the mobile terminal 202 is in an idle state, an inactive state, or an active state. The 5GC unit 214 initiates a paging protocol by transmitting a paging message to a cell belonging to a tracking area in which the mobile terminal 202 is registered.

[0082] The NR base station 213 may also configure one or more cells, like the base station 203. When one NR base station 213 configures multiple cells, each cell is configured to be able to communicate with the UE 202.

[0083] The gNB 217 may be divided into a central unit (hereinafter sometimes referred to as CU) 218 ​​and a distributed unit (hereinafter sometimes referred to as DU) 219. One CU 218 is configured in the gNB 217. One or more DUs 219 are configured in the gNB 217. The CU 218 is connected to the DU 219 via an F1 interface, and control information and / or user data is communicated between the CU 218 and the DU 219.

[0084] In a 5G communication system, a Unified Data Management (UDM) function and a Policy Control Function (PCF) described in Non-Patent Document 21 (3GPP TS23.501) may be included. The UDM and / or PCF may be included in the 5GC unit 214 in FIG. 3 .

[0085] In a 5G communication system, a Location Management Function (LMF) described in Non-Patent Document 24 (3GPP TS 38.305) may be provided. The LMF may be connected to a base station via an AMF as disclosed in Non-Patent Document 25 (3GPP TS 23.273).

[0086] A 5G communication system may include a Non-3GPP Interworking Function (N3IWF) described in Non-Patent Document 21 (3GPP TS23.501). The N3IWF may terminate an Access Network (AN) between the UE and the N3IWF in non-3GPP access between the UE and the N3IWF.

[0087] Figure 4 is a diagram showing the configuration of DC by eNB and gNB connected to EPC. In Figure 4, solid lines indicate U-Plane connections, and dashed lines indicate C-Plane connections. In Figure 4, eNB223-1 is the master base station, and gNB224-2 is the secondary base station (this DC configuration may be referred to as EN-DC). In Figure 4, an example is shown in which U-Plane connection between the MME unit 204 and gNB224-2 is performed via eNB223-1, but it may also be performed directly between the MME unit 204 and gNB224-2.

[0088] Figure 5 is a diagram showing the configuration of DC by gNB connected to the NG core. In Figure 5, solid lines indicate U-Plane connections, and dashed lines indicate C-Plane connections. In Figure 5, gNB224-1 is the master base station, and gNB224-2 is the secondary base station (this DC configuration may be referred to as NR-DC). In Figure 5, an example is shown in which the U-Plane connection between the 5GC unit 214 and gNB224-2 is made via gNB224-1, but it may also be made directly between the 5GC unit 214 and gNB224-2.

[0089] Figure 6 is a diagram showing the configuration of DC by eNB and gNB connected to the NG core. In Figure 6, the solid line indicates the U-Plane connection, and the dashed line indicates the C-Plane connection. In Figure 6, eNB226-1 is the master base station, and gNB224-2 is the secondary base station (this DC configuration may be referred to as NG-EN-DC). In Figure 6, an example is shown in which the U-Plane connection between the 5GC unit 214 and the gNB224-2 is performed via eNB226-1, but it may also be performed directly between the 5GC unit 214 and the gNB224-2.

[0090] Figure 7 is a diagram showing another configuration of DC by eNB and gNB connected to the NG core. In Figure 7, the solid line indicates the U-Plane connection, and the dashed line indicates the C-Plane connection. In Figure 7, the gNB224-1 becomes the master base station, and the eNB226-2 becomes the secondary base station (this DC configuration may be referred to as NE-DC). In Figure 7, an example is shown in which the U-Plane connection between the 5GC unit 214 and the eNB226-2 is made via the gNB224-1, but it may also be made directly between the 5GC unit 214 and the eNB226-2.

[0091] FIG. 8 is a block diagram showing the configuration of mobile terminal 202 shown in FIG. 2. The transmission process of mobile terminal 202 shown in FIG. 8 will be described. First, control data from protocol processing unit 301 and user data from application unit 302 are stored in transmission data buffer unit 303. The data stored in transmission data buffer unit 303 is passed to encoder unit 304, where it undergoes encoding processes such as error correction. Some data may be output directly from transmission data buffer unit 303 to modulation unit 305 without undergoing encoding processes. The data encoded by encoder unit 304 is modulated by modulation unit 305. Precoding in MIMO may be performed by modulation unit 305. The modulated data is converted into a baseband signal, then output to frequency conversion unit 306, where it is converted to a radio transmission frequency. Then, a transmission signal is transmitted to base station 203 from antennas 307-1 to 307-4. While FIG. 8 illustrates an example in which the number of antennas is four, the number of antennas is not limited to four.

[0092] The reception process of the mobile terminal 202 is performed as follows: Radio signals from the base station 203 are received by the antennas 307-1 to 307-4. The received signals are converted from a radio reception frequency to a baseband signal by the frequency converter 306, and demodulated by the demodulator 308. The demodulator 308 may also perform weight calculation and multiplication. The demodulated data is passed to the decoder 309, where it undergoes decoding processes such as error correction. Of the decoded data, control data is passed to the protocol processor 301, and user data is passed to the application unit 302. The series of processes of the mobile terminal 202 are controlled by the controller 310. Therefore, although not shown in FIG. 8 , the controller 310 is connected to each of the units 301 to 309. The controller 310 is implemented, for example, by a processing circuit including a processor and a memory. In other words, the controller 310 is implemented by the processor executing a program in which the series of processes of the mobile terminal 202 are described. A program describing a series of processes of mobile terminal 202 is stored in memory. Examples of memory include non-volatile or volatile semiconductor memory such as RAM (Random Access Memory), ROM (Read Only Memory), and flash memory. Control unit 310 may be realized by a dedicated processing circuit such as an FPGA (Field Programmable Gate Array), an ASIC (Application Specific Integrated Circuit), or a DSP (Digital Signal Processor). In FIG. 8 , the number of antennas used by mobile terminal 202 for transmission and the number of antennas used for reception may be the same or different.

[0093] 9 is a block diagram showing the configuration of the base station 203 shown in FIG. 2. The transmission process of the base station 203 shown in FIG. 9 will be described. The EPC communication unit 401 transmits and receives data between the base station 203 and the EPC (such as the MME unit 204). The 5GC communication unit 412 transmits and receives data between the base station 203 and the 5GC (such as the 5GC unit 214). The other base station communication unit 402 transmits and receives data with other base stations. The EPC communication unit 401, the 5GC communication unit 412, and the other base station communication unit 402 each exchange information with the protocol processing unit 403. Control data from the protocol processing unit 403, and user data and control data from the EPC communication unit 401, the 5GC communication unit 412, and the other base station communication unit 402 are stored in the transmission data buffer unit 404.

[0094] The data stored in the transmission data buffer unit 404 is passed to the encoder unit 405, where it undergoes encoding processes such as error correction. Some data may be output directly from the transmission data buffer unit 404 to the modulator unit 406 without undergoing encoding processes. The encoded data is modulated by the modulator unit 406. The modulator unit 406 may also perform precoding in MIMO. The modulated data is converted into a baseband signal, and then output to the frequency converter unit 407, where it is converted into a radio transmission frequency. Then, a transmission signal is transmitted to one or more mobile terminals 202 from antennas 408-1 to 408-4. While FIG. 9 illustrates an example in which the number of antennas is four, the number of antennas is not limited to four.

[0095] The reception process of the base station 203 is performed as follows: A radio signal from one or more mobile terminals 202 is received by the antenna 408. The received signal is converted from a radio reception frequency to a baseband signal by the frequency conversion unit 407, and demodulated by the demodulation unit 409. The demodulated data is passed to the decoder unit 410, where decoding processes such as error correction are performed. Of the decoded data, control data is passed to the protocol processing unit 403, the 5GC communication unit 412, the EPC communication unit 401, or the other base station communication unit 402, and user data is passed to the 5GC communication unit 412, the EPC communication unit 401, or the other base station communication unit 402. A series of processes of the base station 203 is controlled by the control unit 411. Therefore, although the control unit 411 is omitted in FIG. 9 , it is connected to each of the units 401 to 410 and 412. Similar to the control unit 310 of the mobile terminal 202 described above, the control unit 411 is realized by a processing circuit including a processor and a memory, or a dedicated processing circuit such as an FPGA, an ASIC, or a DSP. In Fig. 9, the number of antennas used by the base station 203 for transmission and the number of antennas used for reception may be the same or different.

[0096] 9 is a block diagram showing the configuration of base station 203, but a similar configuration may also be used for base station 213. In addition, in FIGS. 8 and 9, the number of antennas of mobile terminal 202 and the number of antennas of base station 203 may be the same or different.

[0097] FIG. 10 is a block diagram showing the configuration of an MME. FIG. 10 shows the configuration of an MME 204a included in the MME unit 204 shown in FIG. 2 described above. A PDN GW communication unit 501 transmits and receives data between the MME 204a and a PDN GW (Packet Data Network Gateway). A base station communication unit 502 transmits and receives data via the S1 interface between the MME 204a and a base station 203. If the data received from the PDN GW is user data, the user data is passed from the PDN GW communication unit 501 to the base station communication unit 502 via a user plane communication unit 503, and transmitted to one or more base stations 203. If the data received from the base station 203 is user data, the user data is passed from the base station communication unit 502 to the PDN GW communication unit 501 via the user plane communication unit 503, and transmitted to the PDN GW.

[0098] If the data received from the PDN GW is control data, the control data is passed from the PDN GW communication unit 501 to the control plane control unit 505. If the data received from the base station 203 is control data, the control data is passed from the base station communication unit 502 to the control plane control unit 505.

[0099] The HeNBGW communication unit 504 transmits and receives data between the MME 204a and a Home-eNB Gateway (HeNB GW). The control data received by the HeNBGW communication unit 504 from the HeNB GW is passed to the control plane control unit 505. The HeNBGW communication unit 504 transmits the control data input from the control plane control unit 505 to the HeNB GW.

[0100] The control plane control unit 505 includes a NAS security unit 505-1, an SAE bearer control unit 505-2, an idle state mobility management unit 505-3, and the like, and performs overall processing for the control plane (hereinafter sometimes referred to as the C-Plane). The NAS security unit 505-1 performs security for NAS (Non-Access Stratum) messages, etc. The SAE bearer control unit 505-2 performs management of SAE (System Architecture Evolution) bearers, etc. The idle state mobility management unit 505-3 performs mobility management in the idle state (idle state: also referred to as LTE-IDLE state or simply idle), generation and control of paging signals in the idle state, addition, deletion, update, search, and tracking area list management for one or more mobile terminals 202 under its control.

[0101] The MME 204a distributes paging signals to one or more base stations 203. The MME 204a also performs mobility control in an idle state. The MME 204a manages a tracking area list when the mobile terminal 202 is in an idle state and an active state. The MME 204a initiates a paging protocol by transmitting a paging message to cells belonging to a tracking area in which the mobile terminal 202 is registered. The idle state mobility management unit 505-3 may manage the CSG, CSG ID, and whitelist of the eNB 207 connected to the MME 204a.

[0102] A series of processes of the MME 204a is controlled by a control unit 506. Therefore, although not shown in Fig. 10, the control unit 506 is connected to each of the units 501 to 505. Similar to the control unit 310 of the mobile terminal 202 described above, the control unit 506 is realized by a processing circuit including a processor and a memory, or a dedicated processing circuit such as an FPGA, an ASIC, or a DSP.

[0103] FIG. 11 is a block diagram showing the configuration of the 5GC unit. FIG. 11 shows the configuration of the 5GC unit 214 shown in FIG. 3 described above. FIG. 11 shows a case where the 5GC unit 214 shown in FIG. 5 includes an AMF configuration, an SMF configuration, and a UPF configuration. The Data Network communication unit 521 transmits and receives data between the 5GC unit 214 and the Data Network. The base station communication unit 522 transmits and receives data via the S1 interface between the 5GC unit 214 and the base station 203, and / or the NG interface between the 5GC unit 214 and the base station 213. If the data received from the Data Network is user data, the user data is passed from the Data Network communication unit 521 to the base station communication unit 522 via the user plane communication unit 523 and transmitted to one or more base stations 203 and / or 213. If the data received from base station 203 and / or base station 213 is user data, the user data is passed from base station communication unit 522 to data network communication unit 521 via user plane communication unit 523 and transmitted to the data network.

[0104] If the data received from the Data Network is control data, the control data is passed from the Data Network communication unit 521 to the session management unit 527 via the user plane communication unit 523. The session management unit 527 passes the control data to the control plane control unit 525. If the data received from the base station 203 and / or base station 213 is control data, the control data is passed from the base station communication unit 522 to the control plane control unit 525. The control plane control unit 525 passes the control data to the session management unit 527.

[0105] The control plane control unit 525 includes a NAS security unit 525-1, a PDU session control unit 525-2, an idle state mobility management unit 525-3, and the like, and performs overall processing for the control plane (hereinafter sometimes referred to as the C-Plane). The NAS security unit 525-1 performs security for NAS (Non-Access Stratum) messages, etc. The PDU session control unit 525-2 performs management of PDU sessions between the mobile terminal 202 and the 5GC unit 214, etc. The idle state mobility management unit 525-3 performs mobility management in the standby state (idle state: RRC_IDLE state, or simply referred to as idle), generation and control of paging signals in the standby state, addition, deletion, update, search, tracking area list management, etc. of one or more mobile terminals 202 under its control.

[0106] A series of processes of the 5GC unit 214 is controlled by a control unit 526. Therefore, although the control unit 526 is omitted in Fig. 11, it is connected to each of the units 521 to 523, 525, and 527. Similar to the control unit 310 of the mobile terminal 202 described above, the control unit 526 is realized by a processing circuit including a processor and a memory, or a dedicated processing circuit such as an FPGA, an ASIC, or a DSP.

[0107] Next, an example of a cell search method in a communication system is shown. Fig. 12 is a flowchart showing an outline of the process from cell search to standby operation performed by a communication terminal (UE) in an LTE communication system. When the communication terminal starts a cell search, in step ST601, it synchronizes slot timing and frame timing using a primary synchronization signal (P-SS) and a secondary synchronization signal (S-SS) transmitted from a surrounding base station.

[0108] P-SS and S-SS are collectively called a synchronization signal (SS). A synchronization code is assigned to the synchronization signal (SS) in one-to-one correspondence with the PCI assigned to each cell. 504 different PCIs are being considered. A communication terminal synchronizes using these 504 different PCIs and detects (identifies) the PCI of the synchronized cell.

[0109] In step ST602, for the next synchronized cell, the communication terminal detects a cell-specific reference signal (CRS), which is a reference signal (RS) transmitted from the base station for each cell, and measures the received power of the RS (Reference Signal Received Power: RSRP). A code that has a one-to-one correspondence with the PCI is used for the reference signal (RS). By correlating with this code, the cell can be separated from other cells. By deriving the code for the RS of the cell from the PCI identified in step ST601, it becomes possible to detect the RS and measure the received power of the RS.

[0110] Next, in step ST603, the communication terminal selects the cell with the best RS reception quality, for example, the cell with the highest RS reception power, that is, the best cell, from among one or more cells detected up to step ST602.

[0111] Next, in step ST604, the communication terminal receives the PBCH of the best cell and obtains the BCCH, which is broadcast information. A Master Information Block (MIB), which includes cell configuration information, is mapped to the BCCH on the PBCH. Therefore, the MIB can be obtained by receiving the PBCH and obtaining the BCCH. Examples of MIB information include the DL (downlink) system bandwidth (also called transmission bandwidth configuration: dl-bandwidth), the number of transmitting antennas, and the SFN (System Frame Number).

[0112] Next, in step ST605, the communication terminal receives the DL-SCH of the cell based on the cell configuration information in the MIB, and obtains SIB (System Information Block) 1 in the broadcast information BCCH. SIB 1 includes information on access to the cell, information on cell selection, and scheduling information for other SIBs (SIBk; k is an integer greater than or equal to 2). SIB 1 also includes a tracking area code (TAC).

[0113] Next, in step ST606, the communication terminal compares the TAC of SIB1 received in step ST605 with the TAC portion of the tracking area identity (TAI) in the tracking area list already held by the communication terminal. The tracking area list is also called a TAI list. The TAI is identification information for identifying a tracking area, and is composed of an MCC (Mobile Country Code), an MNC (Mobile Network Code), and a TAC (Tracking Area Code). The MCC is a country code. The MNC is a network code. The TAC is a tracking area code number.

[0114] If the comparison in step ST606 shows that the TAC received in step ST605 is the same as the TAC included in the tracking area list, the communication terminal enters standby mode in the cell. If the comparison shows that the TAC received in step ST605 is not included in the tracking area list, the communication terminal requests a core network (EPC) including an MME and the like to change the tracking area through the cell in order to perform a Tracking Area Update (TAU).

[0115] In the example shown in Fig. 12, an example of operations from cell search to standby in the LTE system is shown, but in the NR system, in step ST603, the best beam may be selected in addition to the best cell. Also, in the NR system, beam information, for example, a beam identifier, may be acquired in step ST604. Also, in the NR system, scheduling information of remaining minimum SI (RMSI) may be acquired in step ST604. In the NR system, the RMSI may be received in step ST605.

[0116] An apparatus constituting a core network (hereinafter sometimes referred to as a "core network side apparatus") updates the tracking area list based on the identification number (UE-ID, etc.) of the communication terminal sent from the communication terminal together with a TAU request signal. The core network side apparatus transmits the updated tracking area list to the communication terminal. The communication terminal rewrites (updates) the TAC list held by the communication terminal based on the received tracking area list. Thereafter, the communication terminal enters standby mode in the cell.

[0117] The widespread use of smartphones and tablet devices has led to an explosive increase in cellular wireless communication traffic, raising concerns about a shortage of wireless resources worldwide. In response to this, efforts are being made to develop small cells and promote spatial separation in order to improve frequency utilization efficiency.

[0118] In a conventional cell configuration, a cell configured by an eNB has a relatively wide coverage area. Conventionally, a cell is configured so that a certain area is covered by the relatively wide coverage areas of multiple cells configured by multiple eNBs.

[0119] In the case of small cell configuration, a cell configured by an eNB has a narrower coverage area than a cell configured by a conventional eNB. Therefore, as in the past, a larger number of small cell configuration eNBs are required to cover a certain area than conventional eNBs.

[0120] In the following description, a cell with a relatively large coverage, such as a cell configured by a conventional eNB, is referred to as a "macro cell," and an eNB configuring a macro cell is referred to as a "macro eNB." Also, a cell with a relatively small coverage, such as a cell configured as a small cell, is referred to as a "small cell," and an eNB configuring a small cell is referred to as a "small eNB."

[0121] The macro eNB may be, for example, a "Wide Area Base Station" as described in Non-Patent Document 7.

[0122] The small eNB may be, for example, a low-power node, a local area node, a hotspot, etc. The small eNB may also be a pico eNB constituting a pico cell, a femto eNB constituting a femto cell, a HeNB, a remote radio head (RRH), a remote radio unit (RRU), a remote radio equipment (RRE), or a relay node (RN). The small eNB may also be a "local area base station" or a "home base station" as described in Non-Patent Document 7.

[0123] FIG. 13 shows an example of a cell configuration in NR. In an NR cell, narrow beams are formed and transmitted in different directions. In the example shown in FIG. 13, at a certain time, base station 750 transmits and receives signals to and from a mobile terminal using beam 751-1. At other times, base station 750 transmits and receives signals to and from a mobile terminal using beam 751-2. In a similar manner, base station 750 transmits and receives signals to and from a mobile terminal using one or more of beams 751-3 to 751-8. In this way, base station 750 forms a wide-area cell.

[0124] 13 shows an example in which the number of beams used by the base station 750 is 8, but the number of beams may be different from 8. Also, in the example shown in FIG. 13, the number of beams used simultaneously by the base station 750 is 1, but it may be multiple.

[0125] In 3GPP, a side link (SL) is supported for D2D (Device to Device) communication and V2V (Vehicle to Vehicle) communication (see Non-Patent Document 1 and Non-Patent Document 16). The SL is defined by the PC5 interface.

[0126] The physical channels used for SL (see Non-Patent Document 1) are as follows: The physical sidelink broadcast channel (PSBCH) carries information related to the system and synchronization and is transmitted from the UE.

[0127] The physical sidelink discovery channel (PSDCH) carries sidelink discovery messages from the UE.

[0128] The physical sidelink control channel (PSCCH) carries control information from the UE for sidelink and V2X sidelink communications.

[0129] The physical sidelink shared channel (PSSCH) carries data from the UE for sidelink and V2X sidelink communications.

[0130] The physical sidelink feedback channel (PSFCH) carries HARQ feedback on the sidelink from a UE that received a PSSCH transmission to the UE that transmitted the PSSCH.

[0131] The transport channel used for SL (see Non-Patent Document 1) will be described. The sidelink broadcast channel (SL-BCH) has a predetermined transport format and is mapped to the PSBCH, which is a physical channel.

[0132] The Sidelink Discovery Channel (SL-DCH) has periodic broadcast transmissions of a fixed size and a predetermined format. The SL-DCH supports both UE autonomous resource selection and eNB-scheduled resource allocation. UE autonomous resource selection involves a collision risk, whereas when the UE is allocated dedicated resources by the eNB, there is no collision. The SL-DCH supports HARQ combining but not HARQ feedback. The SL-DCH is mapped to the PSDCH, which is a physical channel.

[0133] The Sidelink Shared Channel (SL-SCH) supports broadcast transmission. The SL-SCH supports both UE autonomous resource selection and eNB-scheduled resource allocation. While UE autonomous resource selection involves a collision risk, there is no collision when the UE is allocated dedicated resources by the eNB. The SL-SCH also supports HARQ combining but not HARQ feedback. The SL-SCH also supports dynamic link adaptation by changing transmit power, modulation, and coding. The SL-SCH is mapped to the PSSCH, a physical channel.

[0134] The logical channels used for SL (see Non-Patent Document 1) will be described. The Sidelink Broadcast Control Channel (SBCCH) is a sidelink channel used by one UE to broadcast sidelink system information to other UEs. The SBCCH is mapped to the SL-BCH, which is a transport channel.

[0135] The Sidelink Traffic Channel (STCH) is a point-to-multipoint traffic channel for transmitting user information from one UE to other UEs. The STCH is used only by UEs with sidelink communication capability and UEs with V2X sidelink communication capability. Point-to-point communication between two sidelink-capable UEs is also realized by the STCH. The STCH is mapped to the SL-SCH, a transport channel.

[0136] The Sidelink Control Channel (SCCH) is a control channel for transmitting control information from one UE to another UE. The SCCH is mapped to the SL-SCH, which is a transport channel.

[0137] 3GPP is considering supporting V2X communication in NR as well. The study of V2X communication in NR is being conducted based on the LTE system and LTE-A system, but the following changes and additions have been made from the LTE system and LTE-A system.

[0138] In LTE, only broadcast was supported for SL communication. In NR, support for unicast and groupcast as SL communication in addition to broadcast is being considered (see Non-Patent Document 22 (3GPP TS23.287)).

[0139] In unicast communication and groupcast communication, support for HARQ feedback (Ack / Nack), CSI reporting, etc. is being considered.

[0140] In order to support unicast and groupcast in addition to broadcast in SL communication, support for PC5-S signaling is being considered (see Non-Patent Document 22 (3GPP TS23.287)). For example, PC5-S signaling is implemented to establish a link for implementing SL, i.e., PC5 communication. The link is implemented in the V2X layer and is also called a Layer 2 link.

[0141] Furthermore, support for RRC signaling in SL communication is being considered (see Non-Patent Document 22 (3GPP TS23.287)). RRC signaling in SL communication is also referred to as PC5 RRC signaling. For example, it has been proposed to notify UE capabilities between UEs performing PC5 communication, or to notify AS layer settings for performing V2X communication using PC5 communication.

[0142] In multicast communication using NR, both PTM (Point to Multipoint) and PTP (Point to Point) may be used. A common PDCP entity may be used for PTM and PTP. PTM and PTP may have different legs (combinations of RLC and logical channels). In multicast communication, PTM legs and PTP legs may be used while being dynamically switched. For example, MAC signaling may be used for the dynamic switching.

[0143] 5G base stations can support integrated access and backhaul (IAB) (see Non-Patent Document 16 (TS38.300)). An IAB base station may consist of an IAB donor CU, which is a CU of a base station operating as an IAB donor that provides IAB functions; an IAB donor DU, which is a DU of a base station operating as an IAB donor; and an IAB node connected to the IAB donor DU and to a UE via a radio interface. Multiple IAB nodes may exist under the IAB donor CU. IAB nodes may be connected to each other via a radio interface. In other words, IAB nodes may be connected in multiple stages. The connection between the IAB node and the IAB donor CU is established using an F1 interface (see Non-Patent Document 16 (TS38.300)).

[0144] A Backhaul Adaptation Protocol (BAP) layer is provided in the connection between the IAB donor DU and the IAB node and in the connection between the IAB nodes. The BAP layer performs operations such as routing received data to the IAB donor DU and / or the IAB node and mapping the data to an RLC channel (see Non-Patent Document 36 (TS38.340)). In this routing, an address called a BAP address may be used. A BAP address may be assigned to each IAB donor DU and / or IAB node. The BAP address may be assigned by the IAB donor CU. Data transmitted and received in IAB communications includes information about the destination IAB node, such as the BAP address. The data includes information identifying the data path, such as a path ID. The information may be included, for example, as a BAP header. The IAB donor DU and / or the IAB node may perform the routing using the BAP address and / or the path ID.

[0145] In multicast communication using NR, an IAB base station may be used. In multicast using an IAB base station, an IAB node located along a path from an IAB donor CU to a UE may perform multicast transmission to another IAB node (hereinafter, sometimes referred to as a child IAB node) that is a subordinate connection destination of the node in communication with the UE, or may perform multicast transmission to the UE.

[0146] Among one or more child IAB nodes connected to an IAB donor DU and / or IAB node performing multicast transmission, there may be a mixture of child IAB nodes that are the target of multicast transmission and child IAB nodes that are not the target.

[0147] However, in the case of multicasting at an IAB base station, the above-mentioned non-patent documents do not disclose a method for setting a BAP address used for multicasting to an IAB node. Therefore, a problem occurs in that multicasting using an IAB base station cannot be realized.

[0148] In the first embodiment, a method for solving such a problem will be disclosed.

[0149] To solve the above-mentioned problem, the communication system according to this embodiment allows multiple destination BAP addresses to be set for one piece of data. Multiple destination BAP addresses may be set, and multiple next-hop BAP addresses (see Non-Patent Document 35 (TS38.473)) may be set. The multiple BAP addresses may be set such that different BAP addresses are set for different path IDs, or multiple different BAP addresses may be set for the same path ID.

[0150] The IAB donor CU may configure multiple destination BAP addresses for the IAB donor DU and / or IAB node. This configuration may be performed using F1 signaling, such as the BAP MAPPING CONFIGURATION disclosed in TS38.473 (Non-Patent Document 35), or other signaling. The multiple destination BAP addresses may be configured as a list. For example, a BAP Routing ID (see TS38.473), which is one of the information elements in the F1 signaling, may include a list of BAP addresses, including one or more BAP addresses. As another example, the next-hop BAP address included in the F1 signaling may be configured as a list including one or more BAP addresses. Both of the above lists may be provided.

[0151] Identifiers representing BAP addresses may be provided. For example, identifiers may be provided corresponding to each destination BAP address and / or next-hop BAP address set by the IAB donor CU, or one identifier may be provided corresponding to multiple destination BAP addresses and / or next-hop BAP addresses. Similarly, identifiers representing one and / or multiple path IDs may be provided.

[0152] The IAB donor CU may notify the IAB donor DU and / or IAB node of the identifier. The notification of the identifier may be included in the notification of the destination BAP address and / or next-hop BAP address setting from the IAB donor CU to the IAB donor DU and / or IAB node, for example, in the BAP MAPPING CONFIGURATION described above.

[0153] The BAP header may include the aforementioned identifier. The IAB node may use the identifier to derive the destination BAP address or the path ID. This, for example, may reduce the size of the BAP header, thereby improving the efficiency of the communication system. If the BAP header includes one identifier each corresponding to multiple destination BAP addresses and / or multiple path IDs, for example, the size of the BAP header may be further reduced, thereby further improving the efficiency of the communication system.

[0154] The identifier may be uniquely assigned under the IAB donor CU, which may avoid complexity in the communication system, for example.

[0155] As another example, the identifier may be uniquely assigned between an IAB node and / or an IAB donor DU and a child IAB node. The IAB node may change the value of the identifier indicating the destination BAP address and / or path ID included in the BAP header. For example, the IAB node may use the identifier included in the received BAP header to derive the destination BAP address and / or path ID. The IAB node may derive an identifier to be used for communication with the child IAB node corresponding to the derived destination BAP address and / or path ID. The IAB node may replace the identifier included in the received BAP header with the derived identifier. The IAB node may transmit to the child IAB node using a BAP header including the derived identifier. This, for example, may reduce the bit width of the identifier, thereby improving communication efficiency.

[0156] An example of a list of BAP addresses is illustrated in Figure 14. The BAP Routing ID information element (IE) includes multiple BAP addresses and one path ID. The multiple BAP addresses may be destination BAP addresses.

[0157] The BAP Routing ID information element with the list of BAP addresses may for example be included in a Backhaul Routing Information Added List, or in a Backhaul Routing Information Removed List, or in both.

[0158] Information regarding modified backhaul routing information may be provided. This information may be included, for example, in the BAP MAPPING CONFIGURATION described above. One or more pieces of information may be provided. This information may be provided, for example, as a list, such as a backhaul routing information modified list (BH Routing Information Modified List). This list may include, for example, a BAP address, a path ID, and a next-hop BAP address. The information included in the list may be, for example, the modified information. This may reduce the amount of routing configuration processing in the IAB node. The modified BAP address may be included as a list consisting of one or more BAP addresses. Similarly, the modified next-hop BAP address may be included as a list.

[0159] As another example, the list may include information about BAP addresses to be added, next-hop BAP addresses to be added, next-hop BAP addresses to be removed, next-hop BAP addresses to be removed, path IDs to be added, path IDs to be removed, or a combination of the above. Each of the above information may be included as a list of one or more elements. This may, for example, reduce the size of information about changes to backhaul routing information.

[0160] The configuration from the IAB donor CU to the IAB donor DU may include multiple BAP addresses. The configuration may include multiple TNL (Transport Network Layer) addresses (see Non-Patent Document 35 (TS38.473)). The TNL address may be, for example, an IP address. The IP address may be, for example, an IPv4 address, an IPv6 address, or an IPv6 prefix. The TNL address may include a multicast IP address. Including multiple TNL addresses can, for example, avoid the complexity of multicasting from the IAB donor CU to an IAB node that directly communicates with a UE (hereinafter, sometimes referred to as an end IAB node). An end IAB node is an IAB node to which a UE is connected and capable of direct communication with the UE. Multiple UEs may be simultaneously connected to an end IAB node. In addition to the UE, other IAB nodes (corresponding to child IAB nodes of the end IAB node) may also be connected to the end IAB node.

[0161] The configuration from the IAB donor CU to the IAB donor DU may be performed, for example, using the information element IP to layer 2 Traffic Mapping Info (see TS 38.473).

[0162] Examples of information included in the settings are (1) to (5) below.

[0163] (1) A single IP address, multiple BAP addresses, or multiple combinations of next-hop BAP addresses and RLC channel identifiers. (2) A single IP address, multiple BAP addresses, multiple next-hop BAP addresses, and a single RLC channel identifier. (3) Multiple combinations of IP addresses and BAP addresses, or multiple combinations of next-hop BAP addresses and RLC channel identifiers. (4) Multiple combinations of IP addresses and BAP addresses, multiple next-hop BAP addresses, and a single RLC channel identifier. (5) A combination of the above (1) to (4).

[0164] The IP address included in the above (1) may be a multicast IP address. The above (1) enables multicast using PTP to IAB nodes, for example.

[0165] The IP address included in the above (2) may be a multicast IP address. The above (2) enables multicast using PTM to IAB nodes, for example.

[0166] The IP address included in the above (3) may be a unicast IP address. The above (3) enables multicast using PTP to IAB nodes, for example.

[0167] The IP address included in the above (4) may be a unicast IP address. The above (4) enables multicast using PTM to IAB nodes, for example.

[0168] The configuration from the IAB donor CU to the IAB node may include multiple next-hop BAP addresses. Multiple pieces of information regarding RLC channel identifiers may also be included. For example, multiple combinations of next-hop BAP addresses and RLC channel identifiers may be used to enable multicasting using PTP to the IAB node. As another example, multiple combinations of next-hop BAP addresses and a single RLC channel identifier may be used to enable multicasting using PTM to the IAB node.

[0169] A plurality of BAP addresses may be included in the BAP header. A plurality of path IDs may be included in the BAP header. A BAP header may include both a plurality of BAP addresses and a plurality of path IDs. This eliminates the need to transmit the same multicast data as many times as the number of destination IAB nodes, thereby enabling efficient use of the Uu interface.

[0170] The BAP header may be composed of a single header or multiple headers. As an example of a BAP header composed of multiple headers, the BAP header may be composed of two headers. One of the two headers (hereinafter, sometimes referred to as a basic header) may have a fixed size. The other header (hereinafter, sometimes referred to as an extension header) may have a variable size. The IAB node may obtain the basic header first. This allows, for example, the IAB node to obtain the headers quickly.

[0171] As another example of a BAP header consisting of multiple headers, the BAP header may consist of multiple base headers. An IAB node may acquire multiple base headers. This can avoid, for example, complexity in the BAP header acquisition process.

[0172] The following (A) to (M) are disclosed as examples of information contained in the BAP header.

[0173] (A) One or more BAP addresses.

[0174] (B) Information regarding the number of BAP addresses.

[0175] (C) Information about the size of the BAP header.

[0176] (D) One or more path IDs.

[0177] (E) Information regarding the number of pass IDs.

[0178] (F) Information as to whether multiple BAP addresses are included.

[0179] (G) Information regarding whether multiple pass IDs are included.

[0180] (H) Information regarding the presence or absence of a subsequent header.

[0181] (I) Information about the size of the subsequent header.

[0182] (J) Information regarding the number of headers that make up the BAP header.

[0183] (K) Padding.

[0184] (L) Information about the type of BAP header.

[0185] (M) A combination of the above (A) to (L).

[0186] The BAP address included in (A) above may be, for example, a destination BAP address. The IAB node may use the information in (A) above to route to one or more child IAB nodes. By providing one or more BAP addresses in the BAP header, for example, the IAB node can quickly perform routing to multiple child IAB nodes.

[0187] The information regarding the number of (B) may be the number of BAP addresses included in the BAP header, or may be a value obtained by subtracting a predetermined value, for example, 1, from the number. The IAB node may use the value of (B) above to obtain information regarding the destination BAP address. This enables the IAB node to quickly obtain the BAP address included in the BAP header, for example. As another example, when a basic header and an extension header are used in the BAP header, the same effect as described above can be obtained by using a value obtained by subtracting 1 from the number of BAP addresses included in the BAP header as (B) above.

[0188] The size information (C) may be provided in units of bits, octets, or multiple octets (e.g., two octets, three octets, or more). The IAB node may use the information (C) to acquire the BAP header. This can prevent, for example, the IAB node from erroneously acquiring the BAP header.

[0189] The path ID included in (D) above may be, for example, all or part of the path ID used for transmission from the IAB donor CU. The IAB node may use the information in (D) above to route to one or more child IAB nodes. Providing multiple path IDs in the BAP header, for example, allows the IAB node to quickly route to multiple child IAB nodes. This also reduces the number of BAP-PDUs transmitted from the IAB donor DU and / or IAB node, thereby reducing the amount of processing required at the IAB donor DU and / or IAB node.

[0190] The aforementioned (E) may be, for example, the number of path IDs included in the BAP header, or may be a value obtained by subtracting a predetermined value, for example, 1, from that number. The IAB node may use the aforementioned value of (E) to obtain information about the path IDs. This enables, for example, the IAB node to quickly obtain the path IDs included in the BAP header. As another example, when a basic header and an extension header are used in the BAP header, the same effect as described above can be obtained by using a value obtained by subtracting 1 from the number of path IDs included in the BAP header as the aforementioned (E).

[0191] The above (F) may be expressed as information including, for example, whether the BAP header has multiple BAP addresses. The IAB node may use this information to decide whether to continue acquiring a BAP address. This may, for example, reduce the complexity of the BAP address acquisition process.

[0192] The above (G) may be expressed as information including, for example, whether the BAP header contains multiple path IDs. The IAB node may use this information to decide whether to continue acquiring a path ID. This, for example, can avoid complexity in the path ID acquisition process.

[0193] The above (H) may be, for example, information indicating whether the BAP header has a subsequent header. The information may be expressed as information including, for example, yes or no. The BAP header including the above information (H) may be, for example, a basic header or an extension header. The header following the basic header may be an extension header. The header following the extension header may be another extension header. When the basic header is followed by an extension header, the sizes of the basic header and the extension header may be the same or different from each other. When the basic header is followed by an extension header and then another extension header, the sizes of the headers may be the same or different from each other. The IAB node may, for example, continue the BAP header acquisition process using the information (H) being yes, or may terminate the BAP header acquisition process using the information (H) being no. This, for example, makes it possible to avoid complexity in BAP header processing in the IAB node.

[0194] The size information in (I) may be provided in units of bits, octets, or multiple octets (e.g., two, three, or four octets). The IAB node may use the information in (I) to obtain the subsequent header. This may prevent, for example, the IAB node from erroneously obtaining the subsequent header.

[0195] The information regarding the number of (J) may be, for example, the number including the header in question, or the number of subsequent headers excluding the header in question. The IAB node may acquire subsequent headers using the information regarding (J). This may prevent, for example, the IAB node from erroneously acquiring subsequent headers.

[0196] The (K) may be provided, for example, after each of one or more BAP addresses included in the BAP header, after each of one or more path IDs, or at the beginning and / or end of the header. The (K) may be provided, for example, so that the size of the BAP header is one octet, two octets, or three or more octets. This makes it possible to avoid complexity in obtaining the BAP header.

[0197] The above (L) may be, for example, information indicating that the header contains one BAP address and one path ID, information indicating that the header contains multiple combinations of BAP addresses and path IDs, information indicating that the header contains multiple BAP addresses and one path ID, information indicating that one BAP address and multiple path IDs are included, information indicating that only one or multiple BAP addresses are included, or information indicating that only one or multiple path IDs are included. The IAB donor DU may use multiple types of BAP headers. The IAB node may determine the type of header using the above information (L). This, for example, can improve the flexibility of the communication system.

[0198] As an example of the above (M), a combination of multiple types of headers may be used. For example, a combination of a header including multiple combinations of BAP addresses and path IDs and a header including multiple BAP addresses and one path ID may be used. This, for example, can improve the flexibility of the communication system.

[0199] FIG. 15 is a diagram showing an example of a BAP header. FIG. 15 shows an example of a variable-length header including multiple BAP addresses and path IDs. In FIG. 15, the number (N) of BAP addresses and path IDs is included. The BAP header includes N pairs of destination BAP addresses and path IDs. Padding is included at the end of the BAP header to make the BAP header an octet unit. The IAB node uses the value of N included in the BAP header to obtain the combination of destination BAP addresses and path IDs.

[0200] 15 shows an example in which the BAP header includes the BAP address and the number of path IDs, but the size of the BAP header may also be included, which allows, for example, an IAB node to quickly obtain the BAP header.

[0201] 15 shows an example in which the combinations of BAP addresses and path IDs are included in sequence, but all path IDs may be included after all BAP addresses, which allows, for example, an IAB node to quickly obtain BAP addresses.

[0202] As another example in Figure 15, all BAP addresses may be included after all Path IDs, allowing, for example, an IAB node to quickly obtain the Path IDs.

[0203] Fig. 16 shows another example of a BAP header. Fig. 16 shows an example of a fixed-length basic header and a variable-length extension header that include multiple BAP addresses and path IDs. In Fig. 16, the white area of ​​the BAP header is the basic header, and the gray area is the extension header, which is the subsequent header.

[0204] The basic header shown in Figure 16 includes information about the presence or absence of subsequent headers, the first destination BAP address, and a path ID. The IAB node obtains the first destination BAP address and path ID from the basic header, as well as information about the presence or absence of subsequent headers (Ext.). If the information is positive, the IAB node obtains the subsequent headers.

[0205] The subsequent header shown in FIG. 16 includes the number (N) of combinations of destination BAP addresses and path IDs, as well as the second and subsequent combinations of destination BAP addresses and path IDs. The subsequent header also includes padding at the end to organize the subsequent header into octets. The value of N included in the subsequent header may exclude or include the destination BAP addresses and path IDs included in the basic BAP header. The IAB node may use the aforementioned value of N to determine the number of destination BAP addresses and path IDs included in the subsequent header, or the size of the subsequent header. By providing a subsequent header, for example, the size of the basic header can be fixed, thereby enabling the basic header to be quickly acquired.

[0206] 16 shows an example in which the BAP header includes the BAP address and the number of path IDs, but the size of the BAP header may also be included, which allows, for example, an IAB node to quickly obtain the BAP header.

[0207] 16 shows an example in which the combination of BAP addresses and path IDs is included in the extension header in sequence, but all path IDs may be included after all BAP addresses, which allows, for example, an IAB node to quickly obtain BAP addresses.

[0208] As another example, in the extension header of Figure 16, all BAP addresses may be included after all Path IDs, which allows, for example, an IAB node to quickly obtain the Path IDs.

[0209] Fig. 17 shows another example of a BAP header. Fig. 17 shows an example of a fixed-length basic header and one or more fixed-length extension headers. In Fig. 17, the white area of ​​the BAP header is the basic header, and the gray area is the extension header.

[0210] The basic header shown in FIG. 17 is the same as that shown in FIG. 16, and therefore a description thereof will be omitted.

[0211] Each of the multiple extension headers shown in Figure 17 includes information on the presence or absence of a subsequent header, and a combination of a destination BAP address and a path ID. The IAB node obtains the destination BAP address and path ID from the extension header, as well as information on the presence or absence of a subsequent header. If the information is positive, the IAB node obtains the subsequent header. As shown in Figure 17, the configuration of the extension header may be the same as that of the basic header. This, for example, can reduce the amount of processing required to obtain and / or process the extension header.

[0212] The last extension header shown in Figure 17 includes information about the presence or absence of subsequent headers, and a combination of the destination BAP address and path ID. The IAB node obtains the destination BAP address and path ID from the extension header, as well as information about the presence or absence of subsequent headers. The IAB node uses the fact that the information contained in the last extension header is not true to stop obtaining subsequent headers.

[0213] Although the extension header in Fig. 17 includes information (D / C) indicating whether the PDU is a data PDU or a control PDU, this information may not be included. Instead of this information, a reserved bit may be included. This allows, for example, improved future extensibility.

[0214] As shown in Figure 17, the extension header may include a D / C. This, for example, can avoid the complexity of the header generation process in the IAB donor DU. The IAB node may ignore the D / C included in the extension header. This, for example, can speed up the header acquisition process in the IAB node.

[0215] The same path ID may be set for multiple BAP addresses, which may reduce the size of the BAP header and the number of path IDs used in an IAB base station.

[0216] Fig. 18 shows another example of a BAP header. Fig. 18 shows an example of a variable-length header including multiple BAP addresses and one path ID. The BAP header shown in Fig. 18 includes the number (N) of destination BAP addresses. At the end of the BAP header, padding is included to make the BAP header an octet unit. The IAB node uses the value of N included in the BAP header to obtain one or more destination BAP addresses and one path ID.

[0217] 18 shows an example in which the number of destination BAP addresses is included in the BAP header, but the size of the BAP header may also be included, which allows, for example, an IAB node to quickly obtain the BAP header.

[0218] 18 shows the case where the second and subsequent BAP addresses are included after the path ID, but the path ID may be included after the last BAP address, which can avoid complexity in the implementation of BAP header processing, for example.

[0219] Fig. 19 shows another example of a BAP header. Fig. 19 shows an example of a fixed-length basic header and a variable-length extension header, each containing multiple BAP addresses and one path ID. In Fig. 19, the white area of ​​the BAP header is the basic header, and the gray area is the extension header.

[0220] The basic header shown in Figure 19 includes information about the presence or absence of subsequent headers, as well as the first destination BAP address and path ID. The IAB node obtains the first destination BAP address and path ID from the basic header, and also obtains information about the presence or absence of subsequent headers. If the information is positive, the IAB node obtains the subsequent headers.

[0221] The subsequent header shown in FIG. 19 includes the number (N) of destination BAP addresses and the second and subsequent destination BAP addresses. The subsequent header also includes padding at the end to organize the subsequent header into octet units. The value of N included in the subsequent header may exclude or include the destination BAP addresses included in the basic BAP header. The IAB node may use the aforementioned value of N to determine the number of destination BAP addresses included in the subsequent header or the size of the subsequent header. By providing a subsequent header, for example, the size of the basic header can be fixed, thereby enabling the basic header to be quickly acquired.

[0222] Fig. 20 shows another example of a BAP header. Fig. 20 shows an example of a fixed-length basic header and one or more fixed-length extension headers. In Fig. 20, the white area of ​​the BAP header is the basic header, and the gray area is the extension header.

[0223] The basic header shown in FIG. 20 is the same as that shown in FIG. 19, and therefore a description thereof will be omitted.

[0224] The extension header shown in Figure 20 includes information about the presence or absence of a subsequent header and a destination BAP address. The IAB node obtains the destination BAP address from the extension header and also obtains information about the presence or absence of a subsequent header. If the information is positive, the IAB node obtains the subsequent header.

[0225] The last extension header shown in Figure 20 contains information about the presence or absence of subsequent headers and the destination BAP address. The IAB node obtains the destination BAP address and information about the presence or absence of subsequent headers from the extension header. The IAB node uses the fact that the information contained in the last extension header is not present to stop obtaining subsequent headers.

[0226] In the example shown in Fig. 20, the size of the extension header is two octets, but it may be three octets, the same as the basic header. For example, the 10 bits after the destination BAP address in the extension header may be padding. This can avoid the complexity of the BAP header acquisition process at the IAB node, for example.

[0227] The IAB node may modify the BAP header. The IAB node may, for example, delete some information included in the BAP header. The part of the information may, for example, be a BAP address that is not set in the node itself, a path ID that is not set in the node itself, or a combination of the above. This may, for example, reduce the size of the BAP header. The deletion of the BAP header may be performed in the BAP layer that performs the transmission process, or in the BAP layer that performs the reception process.

[0228] As another solution, IAB nodes may be grouped. BAP addresses may be used for the grouping. For example, a multicast BAP address may be provided. The IAB donor CU may assign the BAP address to the IAB node. The IAB donor DU and / or the IAB node may use the multicast BAP address to perform multicast transmission to child IAB nodes. This may enable, for example, multicast transmission to be performed quickly.

[0229] A multicast BAP address may be provided for each multicast service or content, which allows, for example, each device in a communication system to quickly recognize a multicast service or content.

[0230] The multicast BAP address may be set within a predetermined range of possible values ​​for a BAP address. For example, a range of BAP addresses whose first four bits are all '1' may be set as the multicast BAP address. This allows each device in the communication system to quickly determine whether a BAP address is for multicast or not.

[0231] The IAB donor CU may configure the IAB donor DU and / or IAB node, e.g., routing-related configuration, using F1 signaling, such as BAP MAPPING CONFIGURATION signaling (see TS 38.473) or other signaling.

[0232] The configuration may include information about BAP layer routing. The IAB donor CU may include this information in the configuration. This configuration may be performed for each of the PTM leg and the PTP leg. The BAP layer routing information may include information identifying the routing, such as a routing identifier, information about the BAP address of the IAB donor DU and / or IAB node (see Non-Patent Document 35 (TS38.473)), information about the next hop destination, such as the BAP address of a child IAB node, information about the BAP address of the IAB node directly connected to the UE receiving the multicast data, or information about the path from the IAB donor CU to the UE, such as information about the path identifier. This allows, for example, the IAB donor DU and / or IAB node to smoothly route multicast data to the UE.

[0233] The configuration may include multiple pieces of information about routing at the BAP layer. For example, the configuration may include information about routing for transmission using a PTM leg and information about routing for transmission using a PTP leg. The configuration may include multiple pieces of information about routing for transmission using a PTP leg, or multiple pieces of information about routing for transmission using a PTM leg. The IAB node may switch the routing destination using information included in the BAP header, such as DESTINATION and / or path ID information. This allows, for example, dynamic change of the routing destination at the IAB node.

[0234] The configuration may include information about an area where multicast data can be transmitted. The IAB node may use this information to control the beam and / or transmission power so that the transmission range of the multicast data is within the area. This may, for example, prevent the multicast data from being transmitted outside the area where it can be transmitted.

[0235] The configuration may include information about the transmission method. This information may include information indicating the use of a PTM leg or information indicating the use of a PTP leg. This information may be provided for each child IAB node and / or UE to which the transmission is to be made. The IAB donor DU and / or IAB node may use this information to determine the leg to use for transmission to the child IAB node and / or UE. This allows, for example, the IAB donor DU and / or IAB node to quickly determine the leg to use for the transmission.

[0236] Predetermined modes may be provided for the method of transmission from the IAB donor DU and / or IAB node to the child IAB node and / or UE. For example, there may be a mode in which transmission is performed using a PTM leg for both the child IAB node and the UE, a mode in which transmission is performed using a PTM leg for both the UE and a PTP leg for both the child IAB node, a mode in which transmission is performed using a PTP leg for both the UE and the PTM leg for both the child IAB node, or a mode in which transmission is performed using a PTP leg for both the UE and the child IAB node. As another example, there may be a mode in which both the PTP leg and the PTM leg are available to the UE, a mode in which only the PTP leg is used for transmission to the UE, a mode in which only the PTM leg is used for transmission to the UE, a mode in which both the PTP leg and the PTM leg are available to the child IAB node, a mode in which only the PTP leg is used for transmission to the child IAB node, a mode in which only the PTM leg is used for transmission to the child IAB node, or a combination of the above, for example, a combination of a mode for transmission to the UE and a mode for transmission to the child IAB node. The mode may be configurable for each child IAB node and / or UE. The IAB donor CU may determine the mode and notify the IAB donor DU and / or IAB node. The mode may be included in the above-mentioned configuration. The IAB donor DU and / or IAB node may use information about the mode to determine the leg to use for transmission to the child IAB node and / or UE, which, for example, allows the IAB donor DU and / or IAB node to quickly determine the leg to use for the transmission, thereby reducing the amount of processing required for transmission from the IAB donor DU and / or IAB node.

[0237] In routing using an IAB node, multicast data received using a PTM leg may be transmitted using a PTP leg, multicast data received using a PTP leg may be transmitted using a PTM leg, multicast data received using a PTM leg may be transmitted using a PTM leg, or multicast data received using a PTP leg may be transmitted using a PTP leg, which can, for example, improve flexibility in a communication system.

[0238] Routing at the BAP layer may be determined using information about an area in which multicast can be transmitted. For example, the IAB node that performs the multicast routing may be determined from among the IAB nodes whose transmission range is included in the area. This makes it possible to prevent the multicast data from being transmitted outside the area in which it can be transmitted.

[0239] The core network device may determine information about an area where multicast can be transmitted. The core network device may notify the IAB donor CU of the information. As another example, the core network device may notify the IAB donor CU of information about IAB nodes belonging to the area. The IAB donor CU may use the above information to determine the IAB node that will perform routing. This allows, for example, the IAB donor CU to appropriately select an IAB node within the area where multicast can be transmitted.

[0240] The IAB donor DU and / or IAB node may determine an identifier to assign to the child IAB node and / or UE. The identifier may be, for example, a G-RNTI and / or a SC-RNTI (see TS 36.321) or a C-RNTI. The IAB donor DU and / or IAB node may notify the IAB donor CU of the identifier. This notification may be performed using F1 signaling, for example, UL RRC MESSAGE TRANSFER (see TS 38.473).

[0241] A correspondence may be established between the multicast BAP address and the above-mentioned G-RNTI and / or SC-RNTI. For example, the IAB donor CU may determine the multicast BAP address using the above-mentioned G-RNTI and / or SC-RNTI. For example, the IAB donor DU and / or IAB node may set the destination of data whose next-hop BAP address is the multicast BAP address to a child IAB node and / or UE assigned to the above-mentioned G-RNTI. This may improve the efficiency of the communication system, for example.

[0242] The same IAB node may be assigned one or more BAP addresses, and the BAP addresses assigned to an IAB node may include a multicast BAP address.

[0243] The IAB donor CU may configure multiple BAP addresses for the IAB node. For example, RRC signaling, such as RRC reconfiguration signaling, may be used for the configuration. For example, multiple BAP addresses may be configurable in a BAP configuration (bap-config) information element included in the RRC reconfiguration signaling. The configuration from the IAB donor CU to the IAB node may be performed via the parent IAB node of the IAB node. The parent IAB node is the IAB node to which the IAB node is connected. The IAB donor CU may transmit RRC signaling to the parent IAB node to notify the IAB node. For example, DL RRC MESSAGE TRANSFER signaling may be used for the transmission. The parent IAB node may use the signaling to obtain signaling to be sent to the IAB node. The parent IAB node may use the signaling to obtain information to be configured in the IAB node, such as the BAP address assigned to the IAB node. This allows the parent IAB node to know, for example, the multicast BAP address assigned to the IAB node.

[0244] An IAB donor CU may notify an IAB node of information about IAB nodes subordinate to the IAB node. This notification may be performed using F1 signaling, e.g., BAP MAPPING CONFIGURATION signaling, or RRC signaling, e.g., RRC reconfiguration signaling. The information may include, for example, information about one or more BAP addresses assigned to the subordinate IAB nodes. This allows, for example, an IAB node to obtain information about the BAP addresses assigned to the subordinate IAB nodes, thereby enabling smooth routing operations.

[0245] The information may include information about the hierarchy of the subordinate IAB nodes, which may be, for example, a hierarchy based on the IAB node itself, a hierarchy based on the IAB donor CU, or a hierarchy based on the IAB donor DU.

[0246] Another example of the hierarchy information may be a UE-based hierarchy. Information identifying the UE, such as a UE identifier, may be included. The IAB node may use this information to schedule child IAB nodes and / or UEs. This may reduce delays in multicast, for example.

[0247] The information about the hierarchy may include information about the device that is the basis of the hierarchy (e.g., IAB donor CU, IAB donor DU, UE). The IAB node may use this information to obtain information about the device that is the basis of the hierarchy. This can reduce the probability of malfunctions related to multicast transmission processing, for example.

[0248] One or more TNL addresses (see Non-Patent Document 35 (TS38.473)) may be assigned to the same IAB node. The assignment of a TNL address may be performed, for example, for an end IAB node. The TNL address may be, for example, an IPv4 address, an IPv6 address, or an IPv6 prefix. A multicast IP address may be included in the TNL address.

[0249] The multicast BAP address may be used as the destination BAP address, which may reduce the size of the BAP header, for example.

[0250] The multicast BAP address may be used as the next-hop BAP address, which may reduce the size of signaling for routing configuration from the CU to the IAB node, for example.

[0251] In multicast using an IAB base station, a unicast BAP address, i.e., a normal BAP address, may be used. For example, a unicast BAP address may be used to transmit multicast data to an IAB node that is not assigned a multicast BAP address, or a unicast BAP address may be used to transmit multicast data to an IAB node that is assigned a multicast BAP address. This, for example, can improve the flexibility of the communication system.

[0252] Figures 21 and 22 show a multicast setting sequence in an IAB base station. Figure 21 shows the first half of the sequence, and Figure 22 shows the second half of the sequence. That is, in multicast setting in an IAB base station, first, steps ST1510 to ST1528 shown in Figure 21 are executed, and then steps ST1532 to ST1594 shown in Figure 22 are executed. In the example shown in Figures 21 and 22, a UE is connected to an IAB donor CU via IAB node #2, IAB node #1, and an IAB donor DU. In the example shown in Figures 21 and 22, it is assumed that the UE has already obtained information about multicast.

[0253] In Step ST1510 shown in FIG. 21 , the UE makes a PDU session modification request to the AMF. The request may be made using NAS signaling. The request may include information about the multicast that the UE wishes to receive. In Step ST1512, the AMF notifies the SMF that there has been a PDU session modification request. The notification may be made using, for example, the service operation Nsmf_PDUSession_UpdateSMContext (see Non-Patent Document 37 (TS23.502)). The notification may include information about the multicast that the UE wishes to receive. In Step ST1514, the SMF checks whether the UE is able to receive the multicast. In Step ST1516, the SMF queries a Unified Data Repository (UDR) (see Non-Patent Document 21 (TS23.501)) for information about the multicast and acquires the information from the UDR. In step ST1518, the SMF requests information about multicast QoS from the multicast / broadcast SMF (MB-SMF) (see non-patent document 28 (TR23.757)). In step ST1520, the MB-SMF notifies the SMF of a response to the request. The response may include information about multicast QoS.

[0254] In Step ST1522 shown in FIG. 21 , the SMF requests the AMF to transmit a message to the base station. The request may be made using the Namf_Communication_N1N2MessageTransfer service operation (see Non-Patent Document 37 (TS 23.502)). The request may include a request for creating a multicast context in the base station. In Step ST1524, the AMF requests the IAB donor CU to modify the PDU session. For the request, for example, signaling of a PDU Session Resource Modify Request (see Non-Patent Document 38 (TS 38.413)) may be used. The request may include information about the multicast session. The IAB donor CU may use the information to obtain the information about the multicast session.

[0255] In step ST1526 shown in FIG. 21 , the IAB donor CU notifies IAB node #2 of a PDU session modification request. The request may include information about the multicast session. The notification may be made via the IAB donor DU and IAB node #1. The notification may be made using F1 signaling, for example, DL RRC MESSAGE TRANSFER. In step ST1528, IAB node #2 notifies the UE of the PDU session modification request. The UE may obtain information about the multicast session using the information in step ST1528. The UE may change the PDU session information.

[0256] In steps ST1532 to ST1562 shown in FIG. 22, settings related to multicast transmission are made between the IAB base station and the UE.

[0257] In step ST1532 shown in FIG. 22 , the IAB donor CU sets information about routing in the IAB donor DU. The IAB donor CU may determine the information necessary for this setting upon receiving the request in step ST1524. For example, the IAB donor CU may use the information included in the request received in step ST1524 to determine the multicast PDU session and the IAB node to be used for routing. The routing information may include information about the BAP address of the IAB donor DU, or information about the route, such as information about the IAB node directly connected to the UE, information about the BAP address of the next hop destination, or information about the identifier of the RLC channel to be used. The information may include the TNL address of the IAB node. The BAP address may be a multicast BAP address. The TNL address may be provided as a multicast IP address. The setting in step ST1532 may use F1 signaling, for example, signaling of BAP MAPPING CONFIGURATION. Multiple BAP addresses may be provided in the signaling. For example, multiple BAP addresses may be included in the BAP Routing ID information element (IE) included in the signaling. The BAP address of the IAB node may be included in the multiple BAP addresses. Multiple TNL addresses may be provided in the signaling. For example, multiple destination IAB TNL addresses may be included in the information element of IP to layer 2 Traffic Mapping Info (see Non-Patent Document 35 (TS38.473)) included in the signaling. In Step ST1534, the IAB donor DU notifies the IAB donor CU of a response to Step ST1532. In the example shown in FIG. 22, a positive response is notified. The notification in Step ST1534 may use F1 signaling, for example, signaling of BAP MAPPING CONFIGURATION ACKNOWLEDGEMENT.In step ST1536, the IAB donor DU notifies the IAB donor CU of an identifier to be assigned to the child IAB node, IAB node #1 in the example shown in FIG. 22. The identifier may be a C-RNTI, a G-RNTI, an SC-RNTI, or may include a combination of the above. The notification may include information on the RRC configuration used by the IAB donor DU for communication with IAB node #1. The IAB donor DU may perform the notification of step ST1536 upon receiving step ST1532. The notification may be performed using F1 signaling, for example, UL RRC MESSAGE TRANSFER.

[0258] In step ST1538 shown in FIG. 22 , the IAB donor CU notifies the IAB donor DU of the RRC settings to be used for multicast communication with IAB node #1. This notification may be performed using F1 signaling, for example, DL RRC MESSAGE TRANSFER signaling. In step ST1540, the IAB donor DU performs multicast-related settings on the IAB node #1. This setting may include settings for the PTM leg or the PTP leg. This setting may be performed using, for example, RRC reconfiguration signaling. Step ST1540 may include information on an identifier of IAB node #1, for example, a C-RNTI, a G-RNTI, and / or an SC-RNTI, information on a BAP address, information on an RLC configuration, information on a MAC configuration, information on a PHY configuration, or information on a logical channel, for example, information used to identify a logical channel. The BAP address may include information on the BAP address of IAB node #1, information on a next hop destination, for example, a BAP address of IAB node #2, or information on a BAP address of an IAB node directly connected to a UE receiving the multicast data, for example, information on the BAP address of IAB node #2. Multiple BAP addresses may be included as the BAP address of IAB node #1, multiple BAP addresses may be included as the BAP address of a next hop destination, or multiple BAP addresses may be included as the BAP address of an IAB node directly connected to a UE receiving the multicast data. The above-mentioned BAP address may include a multicast BAP address. The above-mentioned information may be included as information relating to each of the PTM leg and the PTP leg. In step ST1542, the IAB node #1 notifies the IAB donor DU of the completion of the multicast configuration. For this notification, for example, signaling of RRC reconfiguration complete (RRCReconfigurationComplete) may be used.In step ST1443, the IAB donor DU notifies the IAB donor CU of information regarding the completion of RRC reconfiguration of IAB node #1. This notification may be performed using F1 signaling, for example, UL RRC MESSAGE TRANSFER signaling. The IAB donor CU may recognize that multicast configuration for IAB node #1 has been completed, triggered by ST1543.

[0259] In step ST1544 shown in FIG. 22 , the IAB donor CU sets routing-related information for the IAB node #1. The routing-related information may include information about the BAP address of the IAB node #1, or information about the route, for example, information about the IAB node directly connected to the UE, information about the BAP address of the next hop destination, or information about the identifier of the RLC channel to be used. The BAP address may be a multicast BAP address. The setting in step ST1544 may be performed using F1 signaling, such as BAP MAPPING CONFIGURATION signaling. Multiple BAP addresses may be provided in this signaling. For example, multiple BAP addresses may be included in the BAP Routing ID information element (IE) included in the signaling. The BAP address of the IAB node may be included among the multiple BAP addresses. In step ST1546, IAB node #1 notifies the IAB donor CU of a response to step ST1544. In the example shown in FIG. 22, an affirmative response is notified. For the notification in step ST1546, F1 signaling, for example, BAP MAPPING CONFIGURATION ACKNOWLEDGEMENT signaling, may be used. In step ST1548, IAB node #1 notifies the IAB donor CU of an identifier to be assigned to the child IAB node, IAB donor #2 in the example shown in FIG. 22. The identifier may be a C-RNTI, a G-RNTI, or an SC-RNTI, or may include a combination of the above. The notification may include information regarding the RRC configuration used by IAB node #1 for communication with IAB node #2. IAB node #1 may send the notification of step ST1548 upon receiving step ST1540, or may send the notification of step ST1548 upon receiving step ST1544, or may send the notification of step ST1548 upon receiving both step ST1540 and step ST1544.For this notification, F1 signaling, for example, UL RRC MESSAGE TRANSFER may be used.

[0260] In step ST1550 shown in FIG. 22 , the IAB donor CU notifies the IAB node #1 of the RRC configuration to be used for multicast communication with the IAB node #2. This notification may be performed using F1 signaling, for example, DL RRC MESSAGE TRANSFER signaling. In step ST1552, the IAB node #1 performs multicast-related configuration for the IAB node #2. This configuration may include configuration for the PTM leg or for the PTP leg. This configuration may be performed using, for example, RRC reconfiguration signaling. Step ST1552 may include information on an identifier of IAB node #2, for example, a C-RNTI, a G-RNTI, and / or an SC-RNTI, information on a BAP address, information on an RLC configuration, information on a MAC configuration, information on a PHY configuration, or information on a logical channel, for example, information used to identify a logical channel. The BAP address may include information on a BAP address of IAB node #2, information on a BAP address of a next hop destination, or information on a BAP address of an IAB node directly connected to a UE receiving the multicast data. Multiple BAP addresses may be included as the BAP address of IAB node #2, multiple BAP addresses may be included as the BAP address of a next hop destination, or multiple BAP addresses may be included as the BAP address of an IAB node directly connected to a UE receiving the multicast data. The BAP address may include a multicast BAP address. The above-mentioned information may be included as information relating to each of the PTM leg and the PTP leg. In step ST1554, IAB node #2 notifies IAB node #1 of the completion of multicast configuration. For example, signaling of RRC reconfiguration completion may be used for this notification. In step ST1555, IAB node #1 notifies the IAB donor CU of information relating to the completion of RRC reconfiguration of IAB node #2.For this notification, F1 signaling, for example, UL RRC MESSAGE TRANSFER signaling, may be used. The IAB donor CU may recognize that multicast configuration for the IAB node #2 has been completed, triggered by Step ST1555.

[0261] In step ST1555A shown in FIG. 22 , the IAB donor CU sets routing-related information for IAB node #2. The routing-related information may include information about the BAP address of IAB node #2, route-related information (e.g., information indicating that IAB node #2 is a terminal IAB node), or information about the identifier of the RLC channel to be used. The BAP address may be a multicast BAP address. The setting in step ST1555A may be performed using F1 signaling, such as BAP MAPPING CONFIGURATION signaling. Multiple BAP addresses may be provided in this signaling. For example, multiple BAP addresses may be included in the BAP Routing ID information element (IE) included in the signaling. The BAP address of the IAB node may be included among the multiple BAP addresses. In step ST1555B, the IAB node #2 notifies the IAB donor CU of a response to step ST1555A. In the example shown in FIG. 22, a positive response is notified. The notification in step ST1555B may be made using F1 signaling, for example, signaling of BAP MAPPING CONFIGURATION ACKNOWLEDGEMENT.

[0262] In step ST1556 shown in FIG. 22 , the IAB node #2 notifies the IAB donor CU of the identifier to be assigned to the UE. The identifier may be a C-RNTI, a G-RNTI, an SC-RNTI, or may include a plurality of the above. The notification may include information on the RRC configuration that the IAB node #2 uses for communication with the UE. The IAB node #2 may perform the notification of step ST1556 upon receiving step ST1554. The notification may use F1 signaling, for example, UL RRC MESSAGE TRANSFER.

[0263] In step ST1558 shown in FIG. 22 , the IAB donor CU notifies the IAB node #2 of the RRC configuration to be used for multicast communication with the UE. This notification may be performed using F1 signaling, for example, DL RRC MESSAGE TRANSFER signaling. In step ST1560, the IAB node #2 performs multicast-related configuration for the UE. This configuration may include configuration for the PTM leg or for the PTP leg. This configuration may be performed using, for example, RRC reconfiguration signaling. Step ST1560 may include information on a UE identifier, for example, the C-RNTI, G-RNTI, and / or SC-RNTI, information on the RLC configuration, information on the MAC configuration, information on the PHY configuration, or information on the logical channel, for example, information used to identify the logical channel. The above-mentioned information may be included as information relating to each of the PTM leg and the PTP leg. In Step ST1562, the UE notifies the IAB node #2 of the completion of multicast configuration. For example, signaling of RRC reconfiguration completion may be used for this notification. In Step ST1563, the IAB node #2 notifies the IAB donor CU of information relating to the completion of RRC reconfiguration of the UE. For this notification, F1 signaling, for example, signaling of UL RRC MESSAGE TRANSFER may be used. The IAB donor CU may recognize that multicast configuration for the UE has been completed, triggered by Step ST1563.

[0264] In step ST1572 shown in FIG. 22 , the IAB donor CU requests multicast delivery from the AMF. The request may include information for identifying the UE or information for identifying the multicast. In step ST1574, the AMF requests multicast delivery from the MB-SMF. In step ST1576, a modification of session information related to multicast delivery is performed between the MB-SMF and the UPF for multicast / broadcast (MB-UPF) (see Non-Patent Document 28 (TR23.757)). In step ST1578, the MB-SMF notifies the AMF of a response to the multicast delivery request. In step ST1580, the AMF notifies the IAB donor CU of a response to the multicast delivery request.

[0265] In Step ST1582 shown in FIG. 22 , the IAB donor CU notifies the AMF of a response to the change of session information related to multicast distribution. In Step ST1584, the AMF notifies the SMF of the response to the change of session information. For example, the process of Nsmf_PDUSession_UpdateSMContext (see Non-Patent Document 37 (TS23.502)) may be used for the notification.

[0266] In step ST1586 shown in FIG. 22 , the MB-UPF transmits multicast data to the IAB donor CU. In step ST1588, the IAB donor CU forwards the data to the IAB donor DU. In step ST1590, the IAB donor DU forwards the data to IAB node #1. In step ST1592, IAB node #1 forwards the data to IAB node #2. In step ST1594, IAB node #2 forwards the data to the UE. In steps ST1590 to ST1594, a PTP leg may be used, a PTM leg may be used, or both may be used.

[0267] 21 and 22 show the case where there is one IAB donor CU, but multiple IAB donor CUs may be provided. For example, an IAB donor CU (IAB donor CU-CP) for the C-plane and an IAB donor CU (IAB donor CU-UP) for the U-plane may be provided. Multiple IAB donor CU-UPs may be provided. This makes it possible to reduce the load on the IAB donor CU by distributing the processing load, for example.

[0268] An IAB donor DU and / or IAB node may be provided for the C-plane, and an IAB donor DU and / or IAB node may be provided for the U-plane. The IAB donor DU and / or IAB node may be connected to both an IAB donor CU-CP and an IAB donor CU-UP. This allows, for example, increased flexibility in the communication system.

[0269] The IAB donor CU-CP may notify the IAB donor CU-UP of information about the IAB donor DU to which data is to be sent. The notification may include information about the end IAB node. The notification may be performed using signaling (e.g., E1 signaling) between the CU-CP and the CU-UP. The IAB donor CU-UP may use the notification to route the data to the IAB donor DU to which the data is to be sent, or may transmit the data to the IAB donor DU. This may prevent malfunctions related to data transmission from the IAB donor CU-UP to the IAB donor DU, for example.

[0270] An IAB donor DU and / or IAB node may be provided for the C-plane, and an IAB donor DU and / or IAB node may be provided for the U-plane. The IAB donor DU and / or IAB node may be connected to both an IAB donor CU-CP and an IAB donor CU-UP. This allows, for example, increased flexibility in the communication system.

[0271] In the signaling transmitted and received between the IAB donor CU and the IAB donor DU and / or IAB node in Figures 21 and 22, the IAB donor CU may be replaced with an IAB donor CU-CP. Similarly, in the signaling transmitted and received between the IAB donor CU and the UE, the IAB donor CU may be replaced with an IAB donor CU-CP. This, for example, can avoid complexity in the communication system.

[0272] The setting sequences shown in Figures 21 and 22 may be used to change a multicast route. The route may be changed, for example, when a UE receiving multicast is added and / or deleted, when a communication route between IAB nodes is blocked by an obstacle or the like, or when the communication route is restored from the blockage. This enables, for example, a route change in multicast using IAB nodes, thereby improving the flexibility of the communication system.

[0273] When a multicast route is changed, the BAP address of the IAB node involved in the change may be included in a backhaul routing information added list (BH Routing Information Added List), a backhaul routing information removed list (BH Routing Information Removed List), a backhaul routing information modified list (BH Routing Information Modified List), or more than one of the above. For example, by being included in the backhaul routing information modified list, it is possible to reduce the amount of F1 signaling involved in the multicast route change.

[0274] The multicast BAP address may be used for setting from the IAB donor CU to the IAB donor DU. For example, the multicast BAP address may be included in the BAP address included in the information element of IP to layer 2 traffic mapping information (see Non-Patent Document 35 (TS38.473)).

[0275] The following (a) to (e) are disclosed as examples of information included in the setting using a multicast BAP address.

[0276] (a) A single IP address, a single or multiple BAP addresses, a single or multiple next-hop BAP addresses, and multiple RLC channel identifiers; (b) A single IP address, a single or multiple BAP addresses, a single or multiple next-hop BAP addresses, and a single RLC channel identifier; (c) Multiple IP addresses, a single or multiple BAP addresses, a single or multiple next-hop BAP addresses, and multiple RLC channel identifiers; (d) Multiple IP addresses, a single or multiple BAP addresses, a single or multiple next-hop BAP addresses, and a single RLC channel identifier; or (e) A combination of the above (a) to (d).

[0277] The IP address included in (a) above may be a multicast IP address. The BAP address and / or next hop BAP address included in (a) above may include a multicast BAP address. (a) above enables multicast using PTP to IAB nodes, for example.

[0278] The IP address included in (b) above may be a multicast IP address. The BAP address and / or next hop BAP address included in (b) above may include a multicast BAP address. (b) above enables multicast using PTM to IAB nodes, for example.

[0279] The IP address included in (c) above may be a unicast IP address. The BAP address and / or next hop BAP address included in (c) above may include a multicast BAP address. (c) above enables multicast using PTP to IAB nodes, for example.

[0280] The IP address included in the above (d) may be a unicast IP address. The BAP address and / or next hop BAP address included in the above (d) may include a multicast BAP address. The above (d) enables multicast using PTM to IAB nodes, for example.

[0281] The configuration from the IAB donor CU to the IAB node may include a multicast BAP address. The multicast BAP address may be included, for example, as a next-hop BAP address. For example, using one or more next-hop BAP addresses and multiple RLC channel identifiers enables multicast using PTP to the IAB node. As another example, using a combination of one or more next-hop BAP addresses and a single RLC channel identifier enables multicast using PTM to the IAB node.

[0282] The following (A) to (G) are examples of how to assign multicast BAP addresses to IAB nodes.

[0283] (a) Assign to end IAB nodes.

[0284] (a) Assign each parent IAB node to a child IAB node.

[0285] (c) Each IAB node is assigned to each bit of the BAP address.

[0286] (d) The same BAP address is assigned to IAB nodes at the same hierarchical level.

[0287] (e) The same BAP address is assigned to IAB nodes below a certain hierarchy level.

[0288] (c) The same BAP address is assigned to the IAB nodes along the path from the IAB donor CU to the UE.

[0289] (Ki) A combination of the above (A) to (F).

[0290] As the above-mentioned method (A), a multicast BAP address may be assigned to an end IAB node. The end IAB nodes to which a multicast BAP address is assigned may include end IAB nodes to which child IAB nodes connect. This enables, for example, multicast transmission to many IAB nodes. As another example, the end IAB node may be only an end IAB node that is not connected to a child IAB node. This makes it possible, for example, to avoid complex processing in the BAP layer of the end IAB node.

[0291] Fig. 23 is a diagram showing an example of the assignment of a multicast BAP address in an IAB base station. Fig. 23 shows an example in which a multicast BAP address is also assigned to an end IAB node serving as a parent IAB node to which a child IAB node connects. In Fig. 23, UEs #1 to #6 are UEs that receive multicast, unhatched IAB nodes #2 to #5 are IAB nodes to which a multicast BAP address is assigned, and hatched IAB node #1 is an IAB node to which a multicast BAP address is not assigned.

[0292] In the example shown in Figure 23, IAB nodes #2 to #5 are all end IAB nodes connected to UEs receiving multicast. Therefore, multicast BAP addresses are assigned to IAB nodes #2 to #5. That is, a multicast BAP address is also assigned to IAB node #3, which is the parent IAB node of IAB node #5. Note that in the example shown in Figure 23, UE #2 and IAB node #5 are connected to IAB node #3 as a child IAB node. In this connection topology, IAB node #3 is an end IAB node from the perspective of UE #2 and a parent IAB node from the perspective of IAB node #5.

[0293] Fig. 24 is a diagram showing another example of the assignment of multicast BAP addresses in an IAB base station. Fig. 24 shows an example in which multicast BAP addresses are assigned only to end IAB nodes to which no child IAB nodes are connected. In Fig. 24, UEs #1 to #6 are UEs that receive multicast, unhatched IAB nodes #2, #4, and #5 are IAB nodes to which multicast BAP addresses are assigned, and hatched IAB nodes #1 and #3 are IAB nodes to which no multicast BAP addresses are assigned.

[0294] In the example shown in Figure 24, IAB nodes #2 to #5 are all connected to UEs that receive multicast, but IAB node #3 is also connected to IAB node #5, which is a child IAB node. Therefore, a multicast BAP address is not assigned to IAB node #3, and multicast BAP addresses are assigned to IAB nodes #2, #4, and #5. In other words, in the example shown in Figure 24, a multicast BAP address is assigned to an IAB node that is connected to a UE and has no other IAB nodes (child IAB nodes) connected to it.

[0295] As an alternative to the method (a) above, a child IAB node may be assigned for each parent IAB node. This allows, for example, the next-hop BAP address from the IAB donor CU to the parent IAB node to be set using fewer BAP addresses, thereby reducing the size of F1 signaling between the IAB donor CU and the parent IAB node.

[0296] Figure 25 is a diagram showing an example of the allocation of multicast BAP addresses in an IAB base station. Figure 25 shows an example in which the same multicast BAP address is assigned to child IAB nodes connected to the same parent IAB node. In Figure 25, UEs #1 to #7 are UEs that receive multicast, and IAB node #7, which is hatched with a dotted pattern, indicates an IAB node to which a multicast BAP address is not assigned. In Figure 25, IAB nodes with hatching that slopes upward to the right, hatching that slopes downward to the right, and hatching that has narrow gaps between them indicate IAB nodes to which different multicast BAP addresses are assigned. In other words, among IAB nodes #1 to #6, IAB nodes with hatching that has the same pattern are assigned the same multicast BAP address.

[0297] The same BAP address may be assigned to multicast content, which, for example, makes it possible to reduce the number of BAP addresses used for multicast, thereby increasing the number of IAB nodes that can be accommodated in the communication system.

[0298] A different RLC channel may be used for each multicast content. For example, different RLC channels may be used when the same BAP address is assigned to the multicast content. This allows, for example, the number of BAP addresses used for multicasting to be reduced while still allowing the multicast content to be identified.

[0299] The same path ID may be used between multicast contents, which makes it possible to reduce the number of path IDs used for multicast, and as a result, to increase the number of IAB nodes that can be accommodated in a communication system.

[0300] A different RLC channel may be used for each multicast content. The use of different RLC channels may be performed, for example, when the same path ID is assigned between multicast contents. This makes it possible to identify multicast contents while reducing the number of path IDs used for multicasting.

[0301] Different multicast BAP addresses may be assigned to child IAB nodes connected to different parent IAB nodes, which allows, for example, a communication system to quickly identify IAB nodes that are multicast transmission targets.

[0302] As another example, the same multicast BAP address may be assigned to child IAB nodes connected to different parent IAB nodes. The multicast BAP address may be used, for example, as a next-hop BAP address. When the multicast BAP address is used as a next-hop BAP address, the value of the next-hop BAP address may be determined by a standard. This eliminates the need for an IAB donor CU to set the multicast BAP address as a next-hop BAP address to an IAB donor DU and / or IAB node, thereby reducing the size of F1 signaling.

[0303] As in the method (c) above, each IAB node may be assigned to each bit of the BAP address. The IAB donor CU may notify the IAB node of information regarding the bit position of the BAP address to be assigned to the IAB node. The IAB node may use this information to recognize the bit position assigned to its own IAB node. The IAB node may use the value of the corresponding bit of the BAP address included in the BAP header to determine whether its own IAB node is included in the destinations. This allows, for example, the IAB node to quickly determine whether its own IAB node is included in the destinations.

[0304] Figure 26 is a diagram showing another example of the allocation of multicast BAP addresses in an IAB base station. In Figure 26, UEs #1, #4 to #7 (not hatched) are UEs that receive multicast, and UEs #2 and #3 (hatched) are UEs that do not receive multicast. In the example shown in Figure 26, a multicast BAP address is assigned to an end IAB node connected to a UE that receives multicast. In Figure 26, IAB nodes #1 to #3 and #5 (hatched) are IAB nodes that are not assigned a multicast BAP address, and IAB nodes #4, #6, and #7 (not hatched) are IAB nodes that are assigned a multicast BAP address.

[0305] Fig. 27 is a diagram showing a bitmap of the multicast BAP address assigned in Fig. 26. The multicast BAP address in the example shown in Fig. 27 is composed of 10 bits, from bit 0 to bit 9. In the example shown in Fig. 27, bit 0 (LSB) is assigned to the IAB donor DU, and bits 1 to 7 are assigned to IAB nodes #1 to #7, respectively. Bits 8 and 9 are free bits. These bits may be reserved bits. This allows, for example, to improve future extensibility.

[0306] In Fig. 26, multicast BAP addresses are assigned to IAB nodes #4, #6, and #7. In this case, '1' is assigned to bits 4, 6, and 7 in Fig. 27, and '0' is assigned to the remaining bits. Note that in Fig. 27, bits assigned '1' are hatched. Therefore, the multicast BAP addresses assigned in the examples of Fig. 26 and Fig. 27 are "0011010000" in binary notation.

[0307] Although Fig. 27 shows an example in which the multicast BAP address is 10 bits, it may be a predetermined number of bits. The predetermined number of bits may be a number of bits other than 10. This can improve the flexibility of the communication system, for example.

[0308] While FIG. 27 shows an example in which the upper two bits of the multicast BAP address are empty, a predetermined bit pattern may be assigned. The bit pattern may be a predetermined bit pattern indicating that the BAP address is a multicast BAP address. The bit pattern may have a number of bits other than two. The IAB donor DU and / or IAB node may determine that the BAP address is a multicast BAP address when the value of a predetermined bit position in the BAP address matches the bit pattern. This may, for example, reduce the amount of processing in the communication system.

[0309] Different path IDs may be assigned to the same destination BAP address. For example, a different path ID may be assigned to each path to an end IAB node. As another example, a different path ID may be assigned to each different multicast content. By assigning a path ID to each multicast content, for example, an IAB node can quickly identify the multicast content.

[0310] The same path ID may be assigned to different destination BAP addresses. This makes it possible, for example, to reduce the number of path IDs used for multicast. A different RLC channel may be used for each multicast content. This makes it possible, for example, to reduce the number of path IDs used for multicast while still being able to identify the multicast content.

[0311] The above-mentioned method (c) may be used for unicast. This allows an IAB node to quickly determine that the IAB node is the destination even in unicast.

[0312] As the method (d) above, the same BAP address may be assigned to IAB nodes in the same hierarchy. The hierarchy may be based on the IAB donor CU.

[0313] A multicast BAP address assigned to an IAB node at the same hierarchical level may be set as the next-hop BAP address, which allows, for example, quick routing processing in the IAB node.

[0314] A multicast BAP address assigned to an IAB node at the same hierarchical level may be set as the destination BAP address. Multiple BAP addresses may be set as the destination BAP address. For example, when the hierarchical levels of end IAB nodes are different, multiple BAP addresses may be set as the destination BAP address. Multiple BAP addresses may be included in the BAP header. The IAB node and / or IAB donor DU may perform scheduling using the multiple BAP addresses included in the BAP header. For example, when an IAB node is an end IAB node and a child IAB node is connected, the IAB node may transmit multicast data to a UE after a predetermined time has elapsed since transmission to the child IAB node. The predetermined time may be determined using the hierarchical level of the IAB node that is the target of the BAP address included in the destination BAP header. This, for example, can reduce the difference in reception time between UEs connected to end IAB nodes at different hierarchical levels for the same multicast data.

[0315] The same BAP address may be assigned to child IAB nodes connected to different parent IAB nodes, which may reduce the number of BAP addresses used.

[0316] A predetermined BAP address indicating the hierarchical level may be provided. The BAP address may be predetermined by a standard or may be determined by the IAB donor CU. One or more IAB nodes may be associated with the predetermined BAP address. The one or more IAB nodes may be IAB nodes in the same hierarchical level.

[0317] The IAB donor CU may determine the mapping and notify the IAB donor DU and / or IAB node. The notification may include information about the BAP address and the BAP address of the target IAB node. The notification may be included in the F1 interface, for example, in the BAP MAPPING CONFIGURATION signaling disclosed in Non-Patent Document 35 (TS38.473). The notification may include information about the hierarchy instead of the BAP address, or may include both the BAP address and information about the hierarchy. The notification may also include information about the hierarchy of the IAB donor DU and / or IAB node. The IAB donor DU and / or IAB node may use this information for routing. This, for example, may avoid complexity in the routing process of the IAB node.

[0318] The IAB donor DU and / or IAB node may perform the above-described association autonomously. The IAB donor DU and / or IAB node may use information about its own hierarchy to derive the hierarchy of the IAB node under it. The IAB donor CU may notify the IAB donor DU and / or IAB node of information about its own hierarchy. This, for example, may enable the routing process in the IAB node to be performed quickly.

[0319] Figure 28 is a diagram showing an example of the allocation of multicast BAP addresses in an IAB base station. Figure 28 shows an example in which the same BAP address is assigned to IAB nodes in the same layer. The layers in Figure 28 are based on the IAB donor DU. In Figure 28, UEs #1 to #7 are UEs that receive multicast, and IAB node #7, hatched with dots, is an IAB node to which a multicast BAP address is not assigned. In Figure 28, IAB nodes with lines sloping downward and IAB nodes with lines sloping upward indicate IAB nodes in the first and second layers, respectively.

[0320] Different BAP addresses may be assigned to child IAB nodes connected to different parent IAB nodes, which may, for example, reduce the complexity of the communication system.

[0321] As an alternative to the above (d), the aforementioned layer may be a layer based on the UE. The same IAB node may have BAP addresses corresponding to multiple layers. For example, when multiple UEs belong to different layers based on the IAB donor CU, the same IAB node may have BAP addresses corresponding to multiple layers. The same BAP address may be assigned to IAB nodes in the same layer. As another example, an IAB node may have a BAP address corresponding to the deepest layer among layers based on one or more subordinate UEs. The IAB node may use information about the layer in scheduling. This may, for example, reduce delays in data transmission from the IAB node to the UE. As another example, an IAB node may have a BAP address corresponding to the shallowest layer among layers based on one or more subordinate UEs.

[0322] As the method (e) described above, the same BAP address may be assigned to IAB nodes below a predetermined layer. The same BAP address may be assigned to IAB nodes above a predetermined layer. This makes it possible to reduce radio resources in multicast communication using an IAB base station, for example. The layer may be based on an IAB donor CU. As another example, the layer may be based on a UE.

[0323] As the method (a) described above, the same BAP address may be assigned to IAB nodes along the path from the IAB donor CU to the UE.

[0324] Figure 29 shows an example of assigning the same BAP address to IAB nodes along the path from an IAB donor CU to a UE. Figure 29 shows an example of assigning a multicast BAP address to IAB nodes #1, #3, and #5 along the path to UE #5. In Figure 29, UEs #1 to #6 are UEs receiving multicast, hatched IAB nodes #2 and #4 are IAB nodes to which a multicast BAP address is not assigned, and unhatched IAB nodes #1, #3, and #5 are IAB nodes to which a multicast BAP address is assigned. The same BAP address is assigned as a multicast BAP address to IAB nodes #1, #3, and #5.

[0325] As an example of (G), a combination of (A) and (B) may be used. For example, the destination BAP address may be the multicast BAP address assigned to the end IAB node in (A) above, and the next hop BAP address may be the multicast BAP address assigned to the child IAB node in (B) above. This may avoid the complexity of multicast transmission at the IAB node, for example.

[0326] Figure 30 is a diagram showing an example in which multicast BAP addresses are assigned to end IAB nodes and child IAB nodes connected to the same parent IAB node. In Figure 30, UEs #1 to #7 represent UEs receiving multicast. In Figure 30, IAB nodes #4 to #7 marked with horizontal lines are assigned BAP addresses for end IAB nodes. IAB nodes #1 and #2 marked with upward sloping lines, IAB nodes #3 and #4 marked with downward sloping lines, and IAB nodes #5 and #6 marked with vertical lines are assigned BAP addresses assigned to child IAB nodes connected to the same parent IAB node. In Figure 30, IAB nodes #4 to #6 are assigned both of the above-mentioned BAP addresses. In particular, IAB node #4 is assigned a BAP address for end IAB nodes and a BAP address assigned to a child IAB node with IAB node #1 as the parent IAB node. IAB nodes #5 and #6 are assigned a BAP address for terminal IAB nodes and a BAP address assigned to a child IAB node with IAB node #2 as the parent IAB node.

[0327] An IAB node may transmit a BAP-PDU received from a parent IAB node to a child IAB node. This operation may be performed, for example, when a child IAB node is connected to the IAB node. This allows multicast transmission to a child IAB node even when the destination BAP address includes the IAB node itself.

[0328] An IAB node may forward a BAP-PDU received from a parent IAB node to upper layers. The IAB node may also remove the BAP header from the BAP-PDU. This may occur, for example, when the IAB node is an end IAB node. This allows, for example, multicasting to UEs.

[0329] An IAB node may perform both of the above operations. For example, both of the above operations may be performed when the IAB node is a terminal IAB node, i.e., when the IAB node is connected to a UE and also to a child IAB node. The IAB node may also perform replication of the BAP-PDU disclosed in the second embodiment. This enables, for example, multicast transmission from the IAB node to the child IAB node and the UE.

[0330] In multicast transmission from an IAB base station, switching between a PTM leg and a PTP leg may be performed. The switching may be determined by the IAB donor CU or by an IAB node directly connected to the UE. The IAB donor CU and / or the IAB node may make the determination using information about PDCP Sequence Numbers (SNs), for example, information about PDCP SNs whose delivery has been acknowledged to the UE. The IAB node may notify the IAB donor CU of the result of the determination. The IAB donor CU may determine the leg to use in multicast using the result of the determination made by its own CU and / or the IAB node.

[0331] As another example of the switching, the IAB donor DU may make the decision, or an IAB node along the path to the UE may make the decision. The IAB donor DU and / or the IAB node may make the decision using information about the RLC SN, for example, information about the RLC SN for which delivery to the UE has been acknowledged. The IAB donor DU and / or the IAB node may notify the IAB donor CU of the result of the decision. The IAB donor CU may use the result of the decision made by its own CU and / or the IAB node to determine the legs to use in multicast.

[0332] As another example of the switching, the UE may determine the switching. For example, the UE may make the determination using the multicast reception status (e.g., PDCP SN, RLC SN). The UE may notify the base station of the switching request or may notify information about the multicast reception status. The UE may autonomously transmit the notification to the base station. The notification may be made using a PDCP status report (see Non-Patent Document 39 (TS38.323)). The IAB donor CU may perform PTM / PTP switching using the information received from the UE.

[0333] As another example, the UE may use the PRACH or RRC signaling for the notification. The IAB donor DU and / or IAB node that communicates directly with the UE may forward the notification from the UE to the IAB donor CU. The IAB donor DU and / or IAB node may perform the forwarding using F1 signaling. This allows, for example, the IAB donor DU and / or IAB node to notify the IAB donor CU of a PTM / PTP switch request from the UE. The IAB donor CU may perform the PTM / PTP switch using the notification forwarded from the IAB donor DU and / or IAB node.

[0334] The F1 signaling may use, for example, the signaling of UL RRC MESSAGE TRANSFER (see Non-Patent Document 35 (TS38.473)), or new signaling. The new signaling may include, for example, information indicating that a PTM / PTP switching request has been made from the UE, information about the leg before switching, information about the leg after switching, information about the multicast reception status at the UE for the leg, or a combination of the above information. Examples of the information regarding the multicast reception status may include information regarding the expiration of a timer used in the PDCP layer (e.g., t-reordering described in Non-Patent Document 39), information indicating that the number of missing PDCP SDUs (Service Data Units) and / or PDCP PDUs related to multicast has exceeded a predetermined value, information regarding the expiration of a timer used in the RLC layer (e.g., t-reassembly described in Non-Patent Document 40), or information indicating that the number of missing RLC SDUs (Service Data Units) and / or RLC PDUs related to multicast has exceeded a predetermined value. The above-mentioned predetermined information may be determined in advance by a standard, or may be determined by the IAB donor CU and notified or broadcast to the UE. A new timer may be provided as the timer used in the PDCP layer described above. A new timer may be provided as the timer used in the RLC layer described above. The above-mentioned information may be included, for example, as a reason in the F1 signaling. For example, information about the multicast reception status may be included as a reason for a PTM / PTP leg switching request from a UE, thereby enabling, for example, an IAB donor CU to obtain detailed information about the UE's status.

[0335] The RRC signaling may also include information similar to that of the F1 signaling, thereby achieving, for example, the same effects as those described above.

[0336] The IAB donor CU may notify the IAB donor DU and / or IAB node of leg activation / deactivation information. For this notification, F1 signaling, such as a UE CONTEXT SETUP REQUEST or a UE CONTEXT MODIFICATION REQUEST as disclosed in Non-Patent Document 35 (TS38.473), may be used. The IAB donor DU and / or IAB node may notify child IAB nodes and / or UEs of leg activation / deactivation information. This notification may be performed, for example, using MAC signaling. This allows, for example, child IAB nodes and / or UEs to be notified of the information quickly.

[0337] Another solution is to eliminate multicast transmission between IAB nodes, for example, to eliminate PTM transmission between IAB nodes, which can, for example, avoid complexity in the communication system.

[0338] A combination of the solutions disclosed in the first embodiment may be used. For example, a BAP header having multiple destination BAP addresses may include a multicast BAP address, or multiple destination BAP addresses set by an IAB donor CU may include a multicast BAP address. This may improve the flexibility of multicast transmission, for example.

[0339] According to the first embodiment, it becomes possible to set a BAP address in multicasting between IAB nodes, and as a result, multicasting using an IAB base station becomes possible.

[0340] Second Embodiment Data may be duplicated in multicast using an IAB base station. For example, data may be duplicated in multicast using PTP, when multicast data is transmitted to a UE and a child IAB node.

[0341] However, the entity that performs the data duplication is not disclosed in the above-mentioned non-patent documents, etc. As a result, in multicast using the IAB base station, discrepancies may occur between devices, which may cause malfunctions in the communication system.

[0342] In the second embodiment, a method for solving such a problem will be disclosed.

[0343] To solve the above problem, in the communication system according to this embodiment, the IAB donor CU replicates multicast data. The replication may be performed in the PDCP layer. The IAB donor CU may transmit the replicated data to each UE in the PDCP layer. The IAB donor DU and / or the IAB node may be used for the transmission.

[0344] Another solution is disclosed: the IAB donor DU and / or the IAB node may replicate the multicast data, and the IAB donor DU and / or the IAB node may perform the replication at the BAP layer.

[0345] The replication at the BAP layer may be performed at the BAP layer of the sending side. For example, in multicast using PTP, the replication of multicast data may be performed at the BAP layer of the sending side. This may reduce the memory buffer usage at the IAB node, for example.

[0346] Figure 31 is a diagram showing an example of a replication operation in the BAP layer. Figure 31 shows an example of a BAP layer operation in an IAB node to which multiple child IAB nodes are connected. The BAP layer shown in Figure 31 is composed of a receiving BAP layer and a transmitting BAP layer. Figure 31 shows an example in which replication in the BAP layer is performed in the transmitting BAP layer.

[0347] In Fig. 31, a received BAP-PDU 3110 is input to the receiving BAP layer via the input BH RLC channel. A function unit 3115 included in the receiving BAP determines whether to transfer the BAP-PDU to a higher layer or to the transmitting BAP layer. In the example shown in Fig. 31, the BAP-PDU 3110 is transferred to the transmitting BAP layer.

[0348] 31, a BAP-PDU 3110 input to the transmitting side BAP layer is input to a routing function unit 3125. The routing function unit 3125 determines the child IAB node to which the BAP-PDU 3110 is to be transmitted, and copies the BAP-PDU 3110 to generate multiple BAP-PDUs 3130. The generated BAP-PDUs 3130 are mapped to the output side BH RLC channel. Each of the generated BAP-PDUs 3130 may be transmitted to a different IAB node.

[0349] The duplication in the BAP layer may be performed in the BAP layer on the receiving side. For example, duplication of multicast data by the BAP layer on the receiving side may be performed in an end IAB node to which a child IAB node is connected. This makes it possible to avoid, for example, complexity in multicast data transmission processing in an end IAB node to which a child IAB node is connected. As another example, duplication of multicast data by the BAP layer on the receiving side may be performed in PTP transmission from an end IAB node to a UE. This makes it possible, for example, to avoid complexity in the design of a communication system.

[0350] Figure 32 shows another example of the operation of the duplication in the BAP layer. Figure 32 shows an example of the operation of the BAP layer in an end IAB node to which a child IAB node is connected. The BAP layer shown in Figure 32 is composed of a receiving BAP layer and a transmitting BAP layer. Figure 32 shows an example in which duplication in the BAP layer is performed in the receiving BAP layer.

[0351] In Figure 32, a received BAP-PDU 3110 is input to the receiving BAP layer via the input BH RLC channel. A function unit 3215 included in the receiving BAP determines whether to transfer the BAP to a higher layer or to a transmitting BAP layer. If necessary, the BAP-PDU 3110 is duplicated in the BAP layer. In the example shown in Figure 32, the BAP-PDU 3110 is duplicated into a BAP-PDU 3220 to be transferred to the transmitting BAP layer and a BAP-PDU 3221 to be transferred to a higher layer.

[0352] In FIG. 32, a BAP-PDU 3220 input to the transmitting BAP layer is routed and mapped to an output BH RLC channel.

[0353] Figure 33 shows another example of the replication operation in the BAP layer. Figure 33 shows an example of the BAP layer operation in an end IAB node to which multiple child IAB nodes are connected. The BAP layer shown in Figure 33 is composed of a receiving BAP layer and a transmitting BAP layer. Figure 33 shows an example in which replication in the BAP layer is performed in the receiving BAP layer.

[0354] In Figure 33, a received BAP-PDU 3110 is input to the receiving BAP layer via the input BH RLC channel. A function unit 3215 included in the receiving BAP determines whether to transfer the BAP to a higher layer or to a transmitting BAP layer. If necessary, the BAP layer copies the BAP-PDU 3110. In the example shown in Figure 33, the BAP-PDU 3110 is copied, and multiple BAP-PDUs 3320 to be transferred to the transmitting BAP layer and a BAP-PDU 3221 to be transferred to a higher layer are generated. The function unit 3215 may perform the copying using routing information held by a routing function unit in the transmitting BAP layer, or may have routing information similar to the routing information held by the routing function unit in the transmitting BAP layer.

[0355] In FIG. 33, a plurality of BAP-PDUs 3320 input to the transmitting BAP layer are routed and mapped to the output BH RLC channel.

[0356] The duplication in the BAP layer may be performed at both the transmitting and receiving BAP layers. For example, in an end IAB node to which multiple child IAB nodes are connected, the duplication may be performed at both the transmitting and receiving BAP layers. For example, the duplication in the receiving BAP layer may generate a BAP-PDU for the child IAB node and a BAP-PDU for the UE, or the duplication in the transmitting BAP layer may duplicate BAP-PDUs for multiple child IAB nodes. This may, for example, reduce memory buffer usage in the IAB node.

[0357] Figure 34 is a diagram showing an example of a replication operation in the BAP layer. Figure 34 shows an example of a BAP layer operation in an end IAB node to which multiple child IAB nodes are connected. The BAP layer shown in Figure 34 is composed of a receiving BAP layer and a transmitting BAP layer. Figure 34 shows an example in which replication in the BAP layer is performed in the transmitting BAP layer and the receiving BAP layer.

[0358] In Figure 34, a received BAP-PDU 3110 is input to the receiving BAP layer via the input BH RLC channel. A function unit 3215 included in the receiving BAP determines whether to transfer the BAP-PDU to a higher layer or to a transmitting BAP layer. If necessary, the BAP-PDU 3110 is duplicated in the BAP layer. In the example shown in Figure 34, the BAP-PDU 3110 is duplicated into a BAP-PDU 3220 to be transferred to the transmitting BAP layer and a BAP-PDU 3221 to be transferred to a higher layer.

[0359] 34, a BAP-PDU 3220 input to the transmitting side BAP layer is input to a routing function unit 3125. The routing function unit 3125 determines the child IAB node to which the BAP-PDU 3220 is to be transmitted, and copies the BAP-PDU 3220 to generate multiple BAP-PDUs 3130. The generated BAP-PDUs 3130 are mapped to the output side BH RLC channel.

[0360] As another example of a method in which the duplication in the BAP layer is performed at both the transmitting and receiving BAP layers, the duplication may be performed at both the transmitting and receiving BAP layers in an end IAB node to which multiple child IAB nodes and multiple UEs are connected. For example, the duplication in the BAP layer on the receiving side may generate a BAP-PDU for the child IAB node and multiple BAP-PDUs for multiple UEs, or the duplication in the BAP layer on the transmitting side may generate a BAP-PDU for multiple child IAB nodes. This may, for example, reduce complexity in the communication system.

[0361] Replication of the IAB donor DU and / or multicast data at the IAB node may be performed at a higher layer, e.g., at the IP layer, which may, e.g., reduce memory buffer usage at the IAB node. Alternatively, replication may be performed at the UDP layer, which may, e.g., further reduce memory buffer usage at the IAB node. Alternatively, replication may be performed at the GTP-u layer, which may, e.g., further reduce memory buffer usage at the IAB node.

[0362] As another example, multicast data may be replicated when forwarded from the GTP-u layer of the receiving side of an IAB node to the RLC layer of the transmitting side of the IAB node, which may further reduce memory buffer usage in the IAB node, for example.

[0363] 35 is a diagram showing an example of the operation of duplicating multicast data between the receiving side and transmitting side of an end IAB node in the protocol stack from the IAB donor CU through the IAB donor DU, intermediate IAB nodes, and the end IAB node to the UE. In the example shown in FIG. 35, the multicast data is duplicated after GTP-u processing on the receiving side of the end IAB node and input to the RLC layer on the transmitting side.

[0364] A new layer that performs duplication of multicast data may be provided. For example, this layer may be provided above the GTP-u layer of the end IAB node, above the BAP layer of an IAB node intermediate the end IAB node, or above the IP layer of the IAB donor DU. Duplication of the IAB donor DU and / or multicast data in the IAB node may be performed in this layer. This may, for example, avoid complexity in the communication system.

[0365] According to the second embodiment, it is possible to prevent discrepancies between devices in multicast using an IAB base station, and as a result, it is possible to prevent malfunctions in the communication system.

[0366] Embodiment 3 In multicast using an IAB base station, multiple data paths may merge along the way. The path merging may be performed at an end IAB node or at an IAB node that is not an end IAB node.

[0367] 36 is a diagram showing an example in which multiple data paths merge along the way. In FIG. 36, the path from IAB node #2 and the path from IAB node #3 merge at IAB node #4, which is not a terminal IAB node.

[0368] However, IAB node #4, which is not an end IAB node, cannot refer to the PDCP header. Therefore, if the node where the route merges is not an end IAB node, the IAB node cannot determine the identity of the multicast data. Therefore, packet duplication (see Non-Patent Document 39 (TS38.323)) cannot be applied to improve efficiency in multicast. This causes a problem of straining radio resources.

[0369] In the third embodiment, a method for solving such a problem will be disclosed.

[0370] To solve the above problem, in the communication system according to the present embodiment, only multicast data arriving from one route is transmitted to the child IAB node, and the IAB node may discard multicast data arriving from other routes.

[0371] The discarding may be performed when multicast data from the one route arrives. The IAB node may hold multicast data arriving from other routes until multicast data from the one route arrives. For example, if multicast data from the one route does not arrive for a predetermined time, the IAB node may transmit multicast data arriving from other routes to a child IAB node. This, for example, can improve the reliability of multicast transmission.

[0372] The IAB donor CU may notify the IAB node of information regarding the PDCP configuration. The information may include, for example, a bearer identifier or information regarding an RLC channel. The information may be notified using RRC signaling, such as RRC reconfiguration. The notification may be performed via a parent IAB node for each path of the IAB node. The IAB node may use the information to obtain information regarding the PDCP configuration of multicast data. This allows, for example, the IAB node to recognize that data received from multiple paths is data for the same multicast content.

[0373] A plurality of prior-hop BAP addresses (see Non-Patent Document 35 (TS38.473)) may be provided. A plurality of ingress backhaul RLC channel IDs (see Non-Patent Document 35 (TS38.473)) may be provided. A plurality of combinations of one prior-hop BAP address and one or more ingress backhaul RLC channel IDs may be provided. A plurality of prior-hop BAP addresses and / or a plurality of ingress backhaul RLC channel IDs may be provided for a single piece of mapping information. This enables, for example, an IAB node to quickly recognize that multicast data received from multiple routes is data of the same multicast content.

[0374] An IAB donor CU may determine which route an IAB node uses to transmit multicast data received from the IAB node to a child IAB node. The IAB donor CU may notify the IAB node of the route from which multicast data is to be transmitted to the child IAB node. The notification may be performed using RRC signaling, MAC signaling, or L1 / L2 signaling.

[0375] As another example, the IAB node or the UE may determine which route the multicast data received at the IAB node will be sent to a child IAB node. The IAB node and / or the UE may notify the IAB donor CU of which route the multicast data will be sent to the child IAB node. This makes it possible to determine the route for multicast data based on the reception environment to the IAB node and / or the UE, thereby improving communication quality.

[0376] Among the above-mentioned multiple previous-hop BAP addresses and / or multiple ingress backhaul RLC channel identifiers, a valid previous-hop BAP address and / or an ingress backhaul RLC channel identifier may be configured. This configuration may be performed by the IAB donor CU, the IAB node itself, or the UE. When the IAB donor CU performs this configuration, the above-mentioned notification may be used. The IAB node may transmit multicast data from the valid previous-hop BAP address and / or ingress backhaul RLC channel identifier to a child IAB node. This may, for example, avoid complexity in multicast route selection.

[0377] Multicast data arriving from two or more routes may be transmitted to a child IAB node. The method described above may be used to determine from which route the multicast data is transmitted to the child IAB node. This makes it possible to ensure redundancy in multicast transmission while reducing the amount of wireless resources used, for example.

[0378] Multicast data arriving from one or more routes and sent to a child IAB node may be data from a route that arrived at the IAB node first, which allows for, for example, quicker multicast communication.

[0379] As another solution, multicast data from multiple routes may be sent directly to the child IAB node, which, for example, makes it possible to ensure redundancy in multicast and, as a result, improve the reliability of the communication system.

[0380] As another solution, merging of multicast transmission paths may not be performed. For example, merging may not be performed at IAB nodes other than the end IAB nodes, or at the end IAB nodes, or at both of the above. This may, for example, make it possible to avoid complexity in the communication system.

[0381] According to the third embodiment, it becomes possible to efficiently use radio resources for multicast data transmission.

[0382] Fourth Embodiment 3GPP is studying the support of various services using SL communication in both EPS and 5G core systems (see Non-Patent Documents 1, 16, 20, 21, 22, and 23). In SL communication, communication is performed between terminals. In addition to direct communication between terminals, communication between a UE and a network via a relay has also been proposed for SL communication (see Non-Patent Document 20 (3GPP TR23.703), Non-Patent Document 23 (3GPP TS23.303), and Non-Patent Document 27 (3GPP TR38.836)). A relay between a UE and a network may be referred to as a UE-to-network relay or a UE-to-network relay. In the present disclosure, a UE that performs relaying between a UE and a network may be referred to as a relay UE.

[0383] For example, there may be a need to communicate not only between UEs within the coverage of a RAN (Radio Access Network) node (e.g., gNB), but also between UEs that are farther away and the RAN node. In such cases, a method using a UE-to-NW relay may be considered. For example, communication between a gNB and a UE (sometimes referred to as a remote UE) is performed via a relay UE. Communication between the gNB and the relay UE is performed via Uu, and communication between the relay UE and the remote UE is performed via PC5. In this specification, a UE that connects to a NW via at least one relay UE is referred to as a remote UE.

[0384] In a communication system that supports communication via such a relay, how to improve the communication quality between a UE and a NW becomes an issue. Conventionally, to improve communication quality, there is a method called dual connectivity (DC) in which a UE connects to two base stations to communicate (see Non-Patent Document 12 (TS37.340)). However, the conventional DC method is disclosed only when a UE is directly connected to a base station. Unlike direct communication between a remote UE and a NW, communication between a remote UE and a NW via a relay UE requires communication not only over Uu but also over PC5. For this reason, there is a problem in that simply using the conventional method for direct communication between a remote UE and a NW cannot be applied to communication between a remote UE and a NW via a relay UE. Furthermore, no dual connectivity method for communication between a remote UE and a NW via a relay UE has been disclosed in standards or the like that have been established so far.

[0385] In the fourth embodiment, a method for solving such a problem will be disclosed.

[0386] In order to solve the above-mentioned problems, in this embodiment, in communication between a remote UE and a network via a relay UE, the relay UE is connected to multiple base stations. The multiple number may be, for example, two. In communication between a remote UE and a network via the relay UE, the relay UE is connected to two base stations. In this specification, a method in which a relay UE or a remote UE connects to two base stations in communication between a remote UE and a network via the relay UE may be simply referred to as DC. The two base stations may hereinafter be referred to as a master node (MN) and a secondary node (SN). The MN has a control plane (C-Plane) connection with a core network (CN). The MN may be a master cell group (MCG). For example, it may be a cell group configured by the MN. The SN may be a secondary cell group (SCG). For example, it may be a cell group configured by the SN.

[0387] The relay UE connects to multiple gNBs for radio bearers (RBs) for communication between the remote UE and the network. The radio bearers may be, for example, signaling radio bearers (SRBs). For example, the SRBs may be SRB2 among multiple SRB0 to SRB2. By communicating using a single gNB for SRB0 and SRB1, the communication establishment process can be simplified. The radio bearers may be, for example, data radio bearers (DRBs). This improves the communication quality of the bearers for data communication.

[0388] Figure 37 is a conceptual diagram of a fourth embodiment in which a relay UE is connected to two gNBs in communication between a remote UE and a network via a relay UE. In the example shown in Figure 37, the relay UE and MgNB (Master gNB) and the relay UE and SgNB (Secondary gNB) are connected via a Uu interface, and the relay UE and remote UE are connected via PC5. Note that the MgNB corresponds to the above-mentioned MN, and the SgNB corresponds to the above-mentioned SN. The remote UE is connected to the MgNB and / or SgNB via the relay UE. In communication between the remote UE and the network, communication is performed between the relay UE and MgNB and / or SgNB, and communication is performed between the relay UE and the remote UE.

[0389] This disclosure discloses a protocol configuration when a relay UE is connected to two gNBs in communication between a remote UE and a network via a relay UE. Figure 38 is a diagram showing a protocol stack when a relay UE is connected to two gNBs in communication between a remote UE and a network via a relay UE, for a fourth embodiment. The figure shows the U-Plane (User Plane).

[0390] The MN and SN have Uu protocols. The Uu protocols include SDAP, PDCP, RLC, MAC, and PHY. Figure 38 shows both MN-terminated and SN-terminated bearers, as well as MCG bearers, SCG bearers, and split bearers, as DC bearers. Protocols corresponding to these bearers are configured. One PDCP may be configured for the MN-terminated bearer and one for the SN-terminated bearer. The configuration of these bearers may be enabled during DC configuration.

[0391] The relay UE has two Uu protocols, one for the MN and one for the SN. The Uu protocols are SDAP, PDCP, RLC, MAC, and PHY. The bearer for the MN is an MCG bearer or a split bearer. The bearer for the SN is an SCG bearer or a split bearer. Protocols corresponding to these bearers are configured. One PDCP may be configured for the MN-terminated bearer and one for the SN-terminated bearer. The relay UE terminates the DC between the MN and / or SN.

[0392] The relay UE and the remote UE have PC5 (also referred to as SL) protocols, which include PC5 SDAP (SL SDAP), PC5 PDCP (SL PDCP), PC5 RLC (SL RLC), PC5 MAC (SL MAC), and PC5 PHY (SL PHY).

[0393] The PDU layer is configured between the UPF, relay UE, and remote UE.

[0394] Bearers will be disclosed. An RB is established between the MN and a remote UE. In the RB, a DC bearer is established between the MN and / or SN and a relay UE, and one SL bearer is established between the relay UE and the remote UE. The SL bearer may also be referred to as a PC5 bearer. A DC bearer terminated by PDCP is referred to as an MN-terminated bearer in the case of the MN, and as an SN-terminated bearer in the case of the SN. As DC bearers, a bearer having an RLC bearer of the MN is referred to as an MCG bearer, a bearer having an RLC bearer of the SN is referred to as an SCG bearer, and a bearer having RLC bearers of both the MN and the SN is referred to as a split bearer. An RB may be established between the MN and the relay UE, and an SL bearer may be established between the relay UE and the remote UE. In the RB between the MN and the relay UE, a DC bearer may be set up between the MN and / or SN and the relay UE.

[0395] Data from the NW to the remote UE is mapped to a Uu bearer by the MN and / or SN, and SDAP and PDCP processing is performed. Data output from the Uu SDAP is mapped to an MCG bearer, SCG bearer, or split bearer, and input to the PDCP. Data output from the PDCP is mapped to an RLC bearer corresponding to each bearer, and transmitted to the relay UE via the RLC, MAC, and PHY protocols. Data received by the relay UE from the MN and / or SN is forwarded to the PDU layer via the Uu protocol corresponding to each bearer. The relay UE is configured to use which bearer as the DC bearer, for example, an MN-terminated bearer, an SN-terminated bearer, an MCG bearer, an SCG bearer, or a split bearer. At the PDU layer, the data is mapped to an SL bearer, and transmitted to the remote UE via the PC5 protocol. At the remote UE, the data received from the relay UE is forwarded to the PDU layer through the PC5 protocol.

[0396] Data from the remote UE to the network is transmitted to the relay UE via the PC5 protocol by the remote UE. Data received from the remote UE by the relay UE is transferred to the PDU layer via the PC5 protocol, where it is mapped to a Uu bearer, and subjected to SDAP and PDCP processing. Data output from the Uu SDAP is mapped to an MCG bearer, SCG bearer, or split bearer, and input to the PDCP. Data output from the Uu SDAP is input to the PDCP, and may be mapped to an MCG bearer, SCG bearer, or split bearer by the PDCP. Data output from the PDCP is mapped to an RLC bearer corresponding to each bearer, and transmitted to the MN and / or SN via the RLC, MAC, and PHY protocols. Data received from the relay UE by the MN and / or SN is transferred to the PDU layer via the Uu protocol corresponding to each bearer.

[0397] Regarding the C-Plane protocol, instead of SDAP and SL SDAP in the MN, relay UE, and remote UE, RRC and SL RRC may be provided, respectively. An RRC corresponding to the SRB and an SL RRC corresponding to the SL SRB may be provided. When DC is set in the SRB, only the MN terminated bearer may be set. DC of the SRB is possible.

[0398] This enables communication between a remote UE and the network via a relay UE connected to two gNBs.

[0399] Another method of protocol configuration when a relay UE is connected to two gNBs in communication between a remote UE and a network via a relay UE is disclosed. Figure 39 is a diagram showing another method of configuring a protocol stack when a relay UE is connected to two gNBs in communication between a remote UE and a network via a relay UE, for the fourth embodiment. The U-Plane is shown. The differences from Figure 38 will be mainly described.

[0400] The MN and SN have Uu protocols for DC, as in the example of Figure 38. In addition to the configuration shown in the example of Figure 38, an adaptation protocol (ADP) is configured between RLC and PDCP. The ADP may be configured as a sublayer of RLC. The relay UE has two Uu protocols, one for the MN and one for the SN. The Uu protocols are ADP, RLC, MAC, and PHY.

[0401] The relay UE has a PC5 protocol between it and the remote UE. A PC5 ADP may be configured above the PC5 RLC. The PC5 ADP may have, for example, a mapping function between the Uu bearer and the PC5 bearer. The PC5 ADP may be configured as a sublayer of the PC5 RLC. The PC5 ADP does not have to be configured. For example, if the mapping between the Uu bearer and the PC5 bearer is limited to one-to-one, the PC5 ADP may not be included. This simplifies the protocol configuration. The PC5 protocol is PC5 ADP (SL ADP), PC5 RLC, PC5 MAC, and PC5 PHY. The PC5 SDAP and PC5 PDCP may not be included.

[0402] The remote UE has the PC5 protocol between it and the relay UE. As with the relay UE, the PC5 protocol is PC5 RLC, PC5 MAC, and PC5 PHY. PC5 ADP may be configured above PC5 RLC. PC5 SDAP and PC5 PDCP are not necessary. The remote UE also has the Uu protocol between it and the MN and / or SN. The Uu protocol is SDAP and PDCP. In the remote UE, the PC5 ADP and the Uu PDCP are connected. If the PC5 ADP is not configured, the PC5 RLC and the Uu PDCP are connected.

[0403] A bearer is disclosed. An RB is established between the MN and the remote UE. A DC bearer is established in the RB between the MN and / or SN and the relay UE. An RLC bearer may be established in the relay UE as the DC bearer. An RLC channel may be established. One SL bearer is established between the relay UE and the remote UE. The SL bearer may be an SL RLC bearer. It may also be an SL RLC channel. The SL RLC bearer is also referred to as a PC5 RLC bearer. The SL RLC channel is also referred to as a PC5 RLC channel.

[0404] This disclosure relates to bearer mapping in communication from a network to a remote UE. In communication from the network to a remote UE, the MN and SN have a function for mapping RBs between the network and the remote UE to the RLC bearer of the Uu for DC in communication from the network to the remote UE. The RLC bearer of the Uu for DC may be an MCG bearer, an SCG bearer, or a split bearer. The number of remote UEs connected to a relay UE is not limited to one, but may be multiple. The number of RBs between the remote UE and the network is not limited to one, but may be multiple. RBs of one or multiple remote UEs connected to a relay UE and / or one or multiple RBs between the remote UE and the network may be mapped to the RLC bearer of the Uu for DC. The above-mentioned function may be included in the ADP of the Uu configured in the MN and SN. The ADP may aggregate functions for when DC is configured and when it is not configured. In this case, the configuration of the MN and SN can be simplified.

[0405] In communication from the NW to the remote UE, the MN and the SN may add the identifier of the remote UE and the identifier of the RB between the remote UE and the NW (RB identifier: RB ID). If the RB is an SRB, the RB ID may be the SRB ID. If the RB is a DRB, the RB ID may be the DRB ID. In this way, the relay UE can recognize the destination remote UE and the RB for communication between the remote UE and the NW.

[0406] The MN and SN may add information about the bearer used for DC in communication from the NW to the remote UE. Information about the bearer used for DC, for example, an identifier indicating the end of the bearer and / or an identifier indicating the type of bearer and / or an identifier indicating whether it is for the MN or the SN. In this way, the relay UE or remote UE can recognize the end and type of the bearer used for DC.

[0407] The above-mentioned additional functions may be included in the ADP of the Uu configured in the MN and SN. The ADP may also integrate functions for when the DC is configured and when it is not configured. In this case, the configuration of the MN and SN can be simplified.

[0408] The relay UE has a function of mapping the RLC bearer of the Uu for DC to the RLC bearer of PC5 in communication from the NW to the remote UE. The remote UE identifier and RB identifier added in the ADP of the MN and SN may be used for this mapping. Information about the bearer used for DC added in the ADP of the MN and SN may be used for this mapping. In this way, the relay UE can map the MCG bearer, SCG bearer, or split bearer for DC to the RLC bearer of PC5. The above-mentioned function may be possessed by the ADP of the Uu configured in the relay UE. Functions for when DC is configured and when it is not configured may be integrated into the ADP. In this case, the configuration of the relay UE can be simplified.

[0409] When mapping to the RLC bearer of PC5, the relay UE may delete some or all of the remote UE identifier, RB identifier, information about the bearer used for DC, etc. added by the MN and SN. When mapping to the RLC bearer of PC5 to the remote UE, some or all of the identifiers and information may not be added.

[0410] The remote UE has a function of mapping the RLC bearer of PC5 and the RLC bearer of Uu for DC to the RB between the NW and the remote UE in communication from the NW to the remote UE. The remote UE identifier and RB identifier added by the MN and SN may be used for this mapping. Information about the bearer used for DC added by the MN and SN may also be used for this mapping.

[0411] This disclosure relates to bearer mapping in communication from a remote UE to a network. The remote UE has a function of mapping an RB between the network and the remote UE to an RLC bearer of PC5 in communication from the remote UE to the network. The remote UE may add an identifier of the RB between the remote UE and the network and an identifier of a base station in communication from the network to the remote UE. The number of base stations may be multiple. For example, this may be added when a relay UE is connected to multiple base stations. Information indicating whether there are multiple base stations or whether the identifier of the base station is multiple may be added. The identifier of the base station may be an identifier of the MN and / or SN. For example, this may be applied when DC is configured. In this way, even when the relay UE transmits to multiple base stations, the relay UE, MN, or SN can recognize the RB for communication between the destination base station, the remote UE, and the network.

[0412] The remote UE may add information about the bearer used for DC in communication from the remote UE to the NW. Information about the bearer used for DC, for example, an identifier indicating the end of the bearer and / or an identifier indicating the type of bearer and / or an identifier indicating whether it is for MN or SN. By doing so, the relay UE, MN, or SN can recognize the end and type of the bearer used for DC.

[0413] The above-mentioned additional functions may be included in the SL ADP configured in the remote UE. The SL ADP may aggregate functions for when DC is configured and when DC is not configured. This makes it easier to configure the remote UE.

[0414] The relay UE has a function of mapping the RLC bearer of PC5 to the RLC bearer of the Uu for DC in communication from the remote UE to the NW. The mapping may use a base station identifier, an RB identifier, information about the bearer used for DC, and the like, added by the remote UE. The RLC bearer of the Uu for DC may be an MCG bearer, an SCG bearer, or a split bearer. The number of remote UEs connected to the relay UE is not limited to one, and multiple remote UEs may be connected. The above-mentioned function may be possessed by the ADP of the Uu configured in the relay UE. The ADP may aggregate functions for when DC is configured and when it is not configured. In this case, the configuration of the relay UE can be simplified.

[0415] When mapping to the RLC bearer of the Uu for DC, the relay UE may delete some or all of the information about the base station identifier, RB identifier, bearer used for DC, etc. added by the remote UE. When mapping to the RLC bearer of the Uu for DC to the base station, some or all of the identifiers and information may not be added.

[0416] In communication from a remote UE to a network, the relay UE may add the identifier of the remote UE and the identifier of the RB between the remote UE and the network. If the RB is an SRB, the RB ID may be the SRB ID. If the RB is a DRB, the RB ID may be the DRB ID. This enables the MN and SN to recognize the source remote UE and the RB for communication between the remote UE and the network. The above-mentioned additional functions may be included in the ADP of the Uu configured in the relay UE. Functions for when DC is configured and when it is not configured may be integrated into the ADP. In this case, the configuration of the relay UE can be simplified.

[0417] The MN and SN have a function of mapping the RLC bearer of the Uu for DC to an RB between the NW and the remote UE in communication from the remote UE to the NW. The number of remote UEs connected to the relay UE is not limited to one, but may be multiple. The number of RBs between the remote UE and the NW is not limited to one, but may be multiple. The RLC bearer of the Uu for DC may be mapped to the RBs of one or multiple remote UEs connected to the relay UE and / or one or multiple RBs between the remote UE and the NW. The mapping may use a remote UE identifier, RB identifier, information about the bearer used for DC, etc., added in the ADP of the remote UE or relay UE. This enables the MN and SN to transfer the MCG bearer, SCG bearer, or split bearer for DC to the PDCP of the RB for communication between the remote UE and the NW. The above function may be possessed by the ADP of the Uu configured in the MN and SN. The ADP may be configured to have functions for both cases where a DC is configured and where it is not configured, which can simplify the configuration of the MN and SN.

[0418] For the C-Plane protocol, an RRC may be provided instead of SDAP in the MN and remote UE. An RRC corresponding to the SRB may be provided. When DC is set in the SRB, only the MN terminated bearer may be set. DC of the SRB is possible.

[0419] This enables communication between a remote UE and the network via a relay UE connected to two gNBs.

[0420] Another method of protocol configuration when a relay UE is connected to two gNBs in communication between a remote UE and a network via a relay UE is disclosed. Figure 40 is a diagram showing another method of configuring a protocol stack when a relay UE is connected to two gNBs in communication between a remote UE and a network via a relay UE, for the fourth embodiment. The U-Plane is shown. The differences from Figure 39 will be mainly described.

[0421] The MN and SN have a Uu protocol for DC, as in the example of Figure 39. The relay UE has two Uu protocols, one for MN and one for SN, as in the example of Figure 39. Furthermore, the relay UE has two PC5 protocols between it and the remote UE. These are PC5 protocols for MN and SN. They may also be for DC. The PC5 protocols are PC5 RLC, PC5 MAC, and PC5 PHY. PC5 ADP may be configured above PC5 RLC. PC5 SDAP and PC5 PDCP may not be required. The remote UE has two PC5 protocols between it and the relay UE. These are PC5 protocols for MN and SN. They may also be for DC. The PC5 protocols are PC5 RLC, PC5 MAC, and PC5 PHY. PC5 ADP may be configured above PC5 RLC. PC5 SDAP and PC5 PDCP may not be required. Also, the remote UE has a Uu protocol between the MN and / or SN. The Uu protocol is PC5 SDAP and PC5 PDCP. The PC5 PDCP or ADP and the Uu PDCP are connected in the remote UE. One PDCP may be configured for the MN-terminated bearer and one for the SN-terminated bearer. The DC is terminated in the remote UE.

[0422] A bearer is disclosed. An RB is established between the MN and the remote UE. In the RB, a DC bearer is established between the MN and / or SN and the relay UE. An SL bearer for DC is established between the relay UE and the remote UE. The SL bearer may be an SL RLC bearer. It may also be an SL RLC channel.

[0423] This section discloses bearer mapping for communication from a network to a remote user equipment (UE). The bearer mapping method disclosed in the example of Fig. 39 may be applied as appropriate. This section mainly discloses differences from the method disclosed in the example of Fig. 39.

[0424] The relay UE has a function of mapping the RLC bearer of the Uu for DC to the RLC bearer of the PC5 for DC in communication from the NW to the remote UE. The relay UE maps the RLC bearer of the Uu for MN to the RLC bearer of the PC5 for MN. The relay UE maps the RLC bearer of the Uu for SN to the RLC bearer of the PC5 for SN. The remote UE identifier and RB identifier added in the ADP of the MN and SN may be used for this mapping. Information about the bearer used for DC added in the ADP of the MN and SN may be used for this mapping. In this way, the relay UE can map the MCG bearer, SCG bearer, or split bearer for DC to the RLC bearer of the PC5 for DC. The above-mentioned function may be included in the ADP of the Uu configured in the relay UE. Functions for when DC is configured and when it is not configured may be integrated into the ADP. In this case, the configuration of the relay UE can be simplified.

[0425] When mapping to the RLC bearer of PC5, the relay UE may delete some or all of the remote UE identifier, RB identifier, information about the bearer used for DC, etc. added by the MN and SN. When mapping to the RLC bearer of PC5 to the remote UE, some or all of the identifiers and information may not be added.

[0426] The remote UE has a function of mapping the RLC bearer of PC5 for MN and the RLC bearer of PC5 for SN to the RB between the NW and the remote UE in communication from the NW to the remote UE. The remote UE identifier and the RB identifier added by the DP of the MN and the SN may be used for this mapping. The information about the bearer used for the DC added by the MN and the SN may be used for this mapping.

[0427] This disclosure relates to bearer mapping in communication from a remote UE to a network. The bearer mapping method disclosed in the example of Figure 39 may be applied as appropriate. Here, differences from the method disclosed in the example of Figure 39 are mainly disclosed. In communication from the remote UE to the network, the remote UE has a function of mapping the RB between the network and the remote UE to the RLC bearer of the PC5 for DC. The RLC bearer of the PC5 for DC may be an MCG bearer, an SCG bearer, or a split bearer. In communication from the network to the remote UE, the remote UE may add an identifier of the RB between the remote UE and the network and an identifier of the base station. There may be multiple base stations. For example, this may be added when a relay UE is connected to multiple base stations. Information indicating whether there are multiple base stations or information indicating whether the identifier of the base station is multiple may be added. The identifier of the base station may be an identifier of the MN and / or SN. For example, this may be applied when DC is configured. In this way, even when the relay UE transmits to multiple base stations, the relay UE, MN, or SN can recognize the destination base station and the RB for communication between the remote UE and the NW.

[0428] The above-mentioned additional functions may be included in the SL ADP configured in the remote UE. The SL ADP may aggregate functions for when DC is configured and when DC is not configured. This makes it easier to configure the remote UE.

[0429] The relay UE has a function of mapping the RLC bearer of PC5 for DC to the RLC bearer of Uu for DC in communication from the remote UE to the NW. The RLC bearer of Uu for DC can be an MCG bearer, an SCG bearer, or a split bearer. The RLC bearer of PC5 for MN is mapped to the RLC bearer of Uu for MN. The RLC bearer of PC5 for SN is mapped to the RLC bearer of Uu for SN. The MCG bearer of PC5 is mapped to the MCG bearer of Uu. The SCG bearer of PC5 is mapped to the SCG bearer of Uu. The split bearer of PC5 is mapped to the split bearer of Uu. The base station identifier, RB identifier, information on the bearer used for DC, etc. added by the remote UE may be used for this mapping. The number of remote UEs connected to the relay UE is not limited to one, and multiple remote UEs may be connected. The above-mentioned functions may be included in the ADP of the Uu configured in the relay UE. The functions for when the DC is set and when it is not set may be integrated into the ADP. In this case, the configuration of the relay UE can be simplified.

[0430] When mapping to the RLC bearer of the Uu for DC, the relay UE may delete some or all of the information about the base station identifier, RB identifier, bearer used for DC, etc. added by the remote UE. When mapping to the RLC bearer of the Uu for DC to the base station, some or all of the identifiers and information may not be added.

[0431] For the C-Plane protocol, an RRC may be provided instead of SDAP in the MN and remote UE. An RRC corresponding to the SRB may be provided. When DC is set in the SRB, only the MN terminated bearer may be set. DC of the SRB is possible.

[0432] This enables communication between a remote UE and the network via a relay UE connected to two gNBs.

[0433] In communication between a remote UE and a network via a relay UE, a setting method for connecting a relay UE to multiple gNBs is disclosed. In this embodiment, a setting method for connecting a DC in which a relay UE connects to two gNBs is disclosed.

[0434] The MN configures DC for the relay UE. The MN configures DC for the RB between the relay UE. The RB may be for communication between the remote UE and the MN. The RB may be an SRB and / or DRB. The SRB may be SRB2. The RB may be for communication between the relay UE and the MN. For example, this may be applied to a Layer 3 UE-to-NW relay.

[0435] The MN performs DC setting of Uu for the relay UE. The relay UE is the end of the DC. The relay UE in which DC is set may be in an RRC connected state with the MN. In addition, the MN may start DC setting for the relay UE in a state in which the relay UE is RRC connected to the MN. The relay UE in which DC is set connects to the CN via the MN in the C-plane.

[0436] The MN sends a request to the SN to add an RB between the MN and a relay UE for communication between the remote UE and the MN. The request may be sent using Xn signaling, or an S-Node addition request message may be used.

[0437] Seventeen examples of information to be included in the SN addition request are disclosed. (1) Information about the relay UE. (2) Information about the remote UE. (3) RRC setting information between the MN and the remote UE. (4) RRC setting information between the MN and the relay UE. (5) SL RRC setting information between the remote UE and the relay UE. (6) RB information between the MN and the remote UE. (7) RB information between the MN and the relay UE. (8) SL bearer information between the remote UE and the relay UE. (9) Information about the PDU between the relay UE and the CN. (10) Information about the PDU between the remote UE and the CN. (11) Information indicating the bearer termination requested to the SN. (12) Bearer type information requested to the SN. (13) Identifier of the MN. (14) Information about the QoS requested for communication. (15) Information about network slicing. (16) Information about tracing. (17) A combination of (1) to (16).

[0438] (1) is information about the relay UE for which the DC is set. For example, it may be an identifier of the relay UE. For example, it may be the capability of the relay UE. (2) is information about the remote UE that communicates with the NW. The information about the remote UE may be, for example, an identifier of the remote UE. For example, it may be the capability of the remote UE.

[0439] (3) may be, for example, configuration information of a cell group that the MN configures for a remote UE. (4) may be, for example, configuration information of a cell group that the MN configures for a relay UE. (5) is RRC configuration information of an SL between a remote UE and a relay UE. For example, it may be RRC information configured from the remote UE to the relay UE and / or from the relay UE to the remote UE.

[0440] (6) is information about the RB between the MN in which DC is set and the remote UE. For example, it may be an RB identifier. For example, if the RB in which DC is set is an SRB, it may be an identifier of the SRB. For example, if the RB in which DC is set is a DRB, it may be an identifier of the DRB. It becomes possible to identify the RB in which DC is set. For example, it may be configuration information of PDCP. For example, if the RB in which DC is set is a DRB, it may be configuration information of SDAP. (7) is information about the RB between the MN in which DC is set and the relay UE. Examples of information about RB are the same as (6).

[0441] (8) is information about an SL bearer between a relay UE and a remote UE in communication between the remote UE and a NW via the relay UE. The SL bearer may be an SL RB. For example, it may be an identifier of the SL RB. For example, if an SL SRB is configured as the SL RB, it may be an identifier of the SL SRB. For example, if an SL DRB is configured as the SL RB, it may be an identifier of the SL DRB. For example, it may be configuration information of an SL PDCP. For example, if an SL DRB is configured as the SL RB, it may be configuration information of an SL SDAP. The SL bearer may be an SL RLC bearer. For example, it may be an identifier of an SL RLC bearer. For example, it may be configuration information of an SL RLC, an SL MAC, and / or an SL PHY. For example, it may be configuration information of an SL logical channel.

[0442] (9) is information about a PDU between a relay UE and a CN, which is set for communication between a remote UE and a NW via a relay UE. For example, it may be a PDU session identifier. For example, it may be information about a QoS required for the PDU session. (10) is information about a PDU between a remote UE and a CN, which is set for communication between a remote UE and a NW via a relay UE. For example, it may be a PDU session identifier. For example, it may be information about a QoS required for the PDU session.

[0443] (11) is information indicating the termination of the DC bearer. For example, it may be information indicating whether it is an MN terminated bearer or an SN terminated bearer. (12) is information indicating the type of DC bearer. For example, it is an MCG bearer, an SCG bearer, a split bearer, etc. (13) is an identifier of the MN to which the relay UE connects. It may be an identifier of the PCell. It is possible to identify the MN that is the sender of the SN addition request.

[0444] (14) is information regarding the QoS required for communication between a remote UE and a NW. Alternatively, it may be information regarding the QoS required for communication between a relay UE and a NW, or information regarding the QoS required for communication between a remote UE and a relay UE. The information regarding QoS may include, for example, the resource type required for the communication, the packet loss rate, the allowable delay, and the priority. (15) is, for example, a network slicing identifier. (16) is information regarding the execution of a trace function. For example, it may include information indicating whether to execute the trace function, information regarding the node that collects the traced information, and information regarding the collected information MDT (Minimization of Drive Tests).

[0445] The trace function may include a case where a remote UE is indirectly connected to a network via a relay UE. For example, the trace function may collect information indicating which base station a remote UE is connected to, information about a relay UE to which the remote UE is connected, information indicating which base station a relay UE is connected to, RLF information between the remote UE and the relay UE, RLF information between the relay UE and the base station, information about the MDT of the remote UE, information about the MDT of the relay UE, etc. This information may be communicated between a remote UE and a relay UE, between a remote UE and a base station, between a relay UE and a base station, between a MN and an SN, between a previously connected base station and a newly connected base station, and between a base station and a node that collects information about tracing.

[0446] In this way, MN can send an SN addition request for DC to SN. Also, by receiving an SN addition request from MN, SN can recognize, for example, which relay UE the DC is for. SN may use the information received from MN to set up DC for the relay UE.

[0447] The SN performs DC configuration for the relay UE. The SN performs configuration for DC between the relay UE and the SN. The SN may perform the DC configuration using information included in the SN addition request message received from the MN. As the DC configuration between the SN for the relay UE, the configuration shown in the example of information to be included in the DC configuration described later may be performed. Among the example of information to be included in the DC configuration described later, information regarding the SN may be configured. For example, it may be an RRC configuration between the SN and the relay UE. The RRC configuration may be, for example, a configuration regarding the RLC bearer between the SN and the relay UE. For example, it may be a configuration of a cell group between the SN and the relay UE.

[0448] The SN sends a response message to the MN regarding the SN addition request. When the SN performs DC configuration, it sends an SN addition request acknowledgement message to the MN. This may be transmitted using Xn signaling. An S-Node addition request acknowledgement message may be used as the SN addition request acknowledgement message. The message may include DC configuration information for the relay UE. The DC configuration information may be, for example, configuration information for the cell group between the SN and the relay UE. The message may also include some of the example information included in the SN addition request disclosed above. For example, information on the relay UE, information on the PDU between the relay UE and the CN, information on the PDU between the remote UE and the CN, information indicating bearer termination, bearer type information, etc.

[0449] The SN may configure an SL between the relay UE and the remote UE. The SN configures an SL between the relay UE and the remote UE for DC. The SN may configure the SL using information included in the SN addition request message received from the MN. As DC configuration between the relay UE and the remote UE, an SL bearer, which will be described later, may be configured. Among the examples of information included in the SL bearer configuration, which will be described later, information related to the SN may be configured. The SL configuration may be an RRC configuration of an SL between the remote UE and the relay UE. For example, it may be an SL RRC configuration from the remote UE to the relay UE and / or from the relay UE to the remote UE. The SL RRC configuration may be, for example, a configuration related to an RLC bearer of an SL between the relay UE and the remote UE.

[0450] The acknowledgment message for the SN addition request, sent from the SN to the MN, may include configuration information for the SL between the relay UE and the remote UE. For example, the message may include RRC configuration information for the SL between the remote UE and the relay UE. The MN may use the information received from the SN to modify the configuration of the SL between the remote UE and the relay UE. The MN may use the information received from the SN to modify the SL bearer between the remote UE and the relay UE. This makes it possible to take into account the configuration information of the SN. This makes it possible to take into account the radio wave propagation environment and load status of the SN, thereby improving the communication quality between the remote UE and the NW via the relay UE.

[0451] If the SN cannot perform DC configuration for the relay UE, it sends an SN addition request rejection response message to the MN. This may be sent using Xn signaling. An S-Node addition request reject message may be used as the SN addition request rejection response message. The message may include, for example, information about the relay UE and reason information.

[0452] The MN sends a DC configuration to the relay UE. Four examples of information to be included in the DC configuration are disclosed. (1) Information about the RB. (2) Information about the RLC bearer of Uu. (3) SN identifier. (4) A combination of (1) to (3).

[0453] The information about RB in (1) is information about RB configuration. Five examples of information about RB configuration are disclosed. (1-1) Information about SRB to be configured. (1-2) Information about DRB to be configured. (1-3) Information about SDAP configuration. (1-4) Information about PDCP configuration. (1-5) A combination of (1-1) to (1-4).

[0454] (1-1) may be, for example, an identifier of the SRB to be set. For example, it may be configuration information of the SRB. (1-2) may be, for example, an identifier of the DRB to be set. For example, it may be configuration information of the DRB. (1-3) may be, for example, set when the RB to be set is a DRB. It may be associated with a DRB identifier. (1-4) may be, for example, set when the RB to be set is an SRB and / or DRB. It may be associated with an SRB identifier and / or DRB identifier. Information regarding PDCP configuration may include, for example, information regarding the RLC bearer to be connected. Information regarding the RLC bearer may be, for example, an identifier of a logical channel. For example, it may be information indicating the type of DC bearer. For example, it may be information regarding a cell group.

[0455] The information on the RB in (1) may use an RB setting that has already been set. The RB setting may be a modification of an RB setting that has already been set. It is preferable to include information indicating an RB setting that has already been set. The information indicating the RB setting may be an RB identifier. For example, if the RB is an SRB, the identifier of the SRB may be used, and if the RB is a DRB, the identifier of the DRB may be used.

[0456] The MN transmits the RB configuration to the relay UE. The MN may transmit the RB configuration to the relay UE by RRC signaling, or may transmit the RB configuration by including it in an RRCReconfiguration message, or may transmit the RB configuration by including it in RadioBearerConfig information.

[0457] The information about the Uu RLC bearer in (2) may be information about the Uu RLC bearer for DC. Instead of the Uu RLC bearer configuration, the information may be information about the Uu RLC channel configuration. In this specification, unless otherwise specified, the description will be given using the Uu RLC bearer configuration.

[0458] Seven examples of information to be included in the Uu RLC bearer configuration for DC are disclosed. (2-1) Identifier of the corresponding RB. (2-2) Configuration information of the Uu RLC bearer for MCG. (2-3) Configuration information of the Uu RLC bearer for SCG. (2-4) Information indicating bearer termination. (2-5) Information indicating the bearer type. (2-6) Identifier of the Uu RLC bearer. (2-7) Combination of (2-1) to (2-6).

[0459] (2-1) may be an identifier of the RB corresponding to the RLC bearer of the Uu to be configured for DC. (2-2) may be, for example, RLC configuration information. For example, it may be logical channel configuration information. For example, it may be a logical channel identifier. The configuration information of the Uu RLC bearer for MCG may be included in the MCG configuration information. (2-3) may be, for example, RLC configuration information. For example, it may be logical channel configuration information. For example, it may be a logical channel identifier. The configuration information of the Uu RLC bearer for SCG may be included in the SCG configuration information. (2-4) may be, for example, information indicating whether it is an MN-terminated bearer or an SN-terminated bearer. (2-5) may be, for example, information indicating whether it is an MCG bearer, an SCG bearer, or a split bearer.

[0460] The MN sends a Uu RLC bearer setup to the relay UE. The Uu RLC bearer setup may be performed using an RRCReconfiguration message. The setup may be a modification of an already established Uu RLC bearer setup. The message may include information indicating the already established Uu RLC bearer setup.

[0461] When the MN configures the DC for the relay UE, the MN may use the configuration information for the DC between the relay UE and the SN received from the SN. It is possible to take into account the load situation in the SN.

[0462] The MN does not configure DC for the remote UE. The remote UE may not be aware of the DC configuration of the relay UE.

[0463] If the DC configuration type is SN terminated, the PDU session may be modified. In this modification, a PDU session modification process is performed between the MN and CN. The PDU session modification may be performed when the RB for configuring DC is a DRB. In the case of L3 relay, the PDU session between the relay UE and the NW is modified. In the case of L2 relay, the PDU session between the remote UE and the NW is modified. In the PDU session modification process, the PDU session ID notified in the DRB configuration may be used. The PDU session ID notified in the SDAP configuration may be used. In this case, the MN and CN nodes can identify the PDU session to be modified.

[0464] Data communication between the remote UE and the NW is performed via a DC bearer (RLC bearer) between the MN / SN and the relay UE. Data communication between the relay UE and the remote UE is performed using an SL bearer.

[0465] The DC setting method disclosed above may be applied when the DC is terminated at the relay UE. For example, it may be applied to the protocol example disclosed in FIG.

[0466] FIG. 41 is a sequence diagram showing an example of a DC configuration method in which a relay UE connects to two gNBs, according to the fourth embodiment. In the DC, communication is performed between a remote UE and a NW via a relay UE. In step ST4401, data is transmitted and received between a remote UE, a relay UE, a MN, and a UPF. The MN decides to configure a DC for the relay UE. For example, the relay UE measures neighboring gNBs and reports the measurement results to the MN. The MN determines the SN to be used for the DC from the measurement results. In step ST4402, the MN transmits an SN addition request message to the SN. The MN requests the SN to be added as an SN for the DC for the relay UE. The SN addition request message is transmitted using Xn signaling. An S-Node addition request message may be used as the SN addition request message. The SN addition request message may include the example information of the SN addition request disclosed above.

[0467] The SN that has received the SN addition request message from the MN recognizes the relay UE that performs DC configuration, information regarding communication between the remote UE that performs DC configuration and the NW, the requested bearer termination, the requested DC bearer type, etc., from the information in the SN addition request, and performs DC configuration for the relay UE. The DC configuration may be, for example, an RRC configuration between the SN and the relay UE. In step ST4403, the SN transmits an SN addition request response message to the MN. In this example, an acknowledgment is transmitted. An S-Node addition request acknowledge message may be used as the SN addition request response message. The SN addition request response message may include the RRC configuration between the SN and the relay UE. The MN that has received the SN addition request response message recognizes that the SN has performed DC configuration for the relay UE. In addition, the MN recognizes the RRC configuration between the SN and the relay UE.

[0468] In step ST4404, the MN notifies the SN of an Xn-U address indication message. For example, the MN sets an address to be used for the DC between the MN and SN and transmits it to the SN in step ST4404. This allows the MN and SN to share the address to be used for the DC, enabling data transmission and reception between the MN and SN.

[0469] In step ST4405, the MN transmits DC configuration to the relay UE. RRC signaling is used for this transmission. Configuration may be performed using an RRC reconfiguration message. The DC configuration may include the example information for DC configuration disclosed above. The RRC configuration information received from the SN may be used as the configuration related to the SCG of the DC configuration information. By receiving the DC configuration from the MN, the relay UE becomes able to configure the DC between the MN and the SN. In step ST4406, the relay UE that has configured the DC between the MN and the SN transmits a DC configuration response to the MN. In this example, a positive response is used. RRC signaling is used for this transmission. An RRC reconfiguration complete message may be used. The MN that has received the DC configuration response recognizes that the relay UE has completed the DC configuration using the MN and the SN.

[0470] In step ST4407, the MN transmits an SN configuration complete message to the SN. Xn signaling is used for this transmission. An S-Node reconfiguration complete message may also be transmitted. By receiving this message, the SN recognizes that the MN and relay UE have completed the SN configuration for DC.

[0471] In Step ST4408, the relay UE starts an RA procedure with the SN while maintaining communication with the MN.

[0472] In Step ST4409, the MN performs SN state transfer to the SN, and in Step ST4410, transfers the data from the UPF to the SN. In the case of an SN-terminated bearer, it is necessary to change the path between the UPF and the gNB from the MN to the SN. In this case, the path update process of Step ST4420 is performed. In the path update process, the MN, UPF, AMF, and SN transmit a PDU session modification indication message in Step ST4411, a bearer modification message in Step ST4412, an end marker packet in Step ST4413, and a PDU session modification complete message in Step ST4414, thereby changing the U-Plane path from the MN to the SN.

[0473] In this way, DC is performed between the relay UE, MN, and SN. For example, in the case of an SN-terminated SCG bearer, data communication is performed between the relay UE, SN, and UPF. The relay UE is in a state where a PC5 connection is established with the remote UE. Therefore, in the case of an SN-terminated SCG bearer, for example, data communication is performed between the remote UE, relay UE, SN, and UPF in step ST4415.

[0474] For example, in the case of an MN-terminated SCG bearer, data communication is performed between a remote UE, a relay UE, an SN, a MN, and a UPF. For example, in the case of an SN-terminated MCG bearer, data communication is performed between a remote UE, a relay UE, an MN, an SN, and a UPF. For example, in the case of an MN-terminated split bearer, data communication is performed between a remote UE, a relay UE, an SN, a MN, and a UPF. For example, in the case of an SN-terminated split bearer, data communication is performed between a remote UE, a relay UE, an MN, an SN, and a UPF.

[0475] By doing this, it becomes possible to configure a DC in which the relay UE connects to two gNBs.

[0476] Another example of a DC setting method in which a relay UE connects to two gNBs is disclosed. The SL bearer between the remote UE and the relay UE may be modified. When modifying the SL bearer between the remote UE and the relay UE, the MN notifies the relay UE and the remote UE of the SL bearer modification. The SL bearer modification may be performed during the DC setting process for the relay UE or after the DC setting process.

[0477] The MN sets up an SL bearer between the remote UE and the relay UE to the relay UE. The SL bearer setting may be a setting for modifying the SL bearer. Three examples of SL bearer setting information are disclosed: (1) Information about the SL RB; (2) Information about the SL RLC bearer; and (3) A combination of (1) and (2).

[0478] The information on SL RB in (1) is information on the configuration of SL RB. Five examples of information on the configuration of SL RB are disclosed. (1-1) Information on SL SRB to be configured. (1-2) Information on SL DRB to be configured. (1-3) Information on SL SDAP configuration. (1-4) Information on SL PDCP configuration. (1-5) A combination of (1-1) to (1-4).

[0479] (1-1) may be, for example, an identifier of the SL SRB to be set. For example, it may be configuration information of the SL SRB. (1-2) may be, for example, an identifier of the SL DRB to be set. For example, it may be configuration information of the SL DRB. (1-3) may be, for example, set when the SL RB to be set is an SL DRB. It may be associated with the SL DRB identifier. (1-4) may be, for example, set when the SL RB to be set is an SL SRB and / or SL DRB. It may be associated with the SL SRB identifier and / or SL DRB identifier. Information regarding the SL PDCP configuration may include, for example, information regarding the SL RLC bearer to be connected. The information regarding the SL RLC bearer may be, for example, an identifier of a logical channel. For example, it may be information indicating the type of DC bearer. For example, it may be information regarding a cell group.

[0480] The information on the SL RB in (1) may use an already set SL RB setting. The SL RB setting may be a modification of an already set SL RB setting. It is preferable to include information indicating an already set SL RB setting. The information indicating the SL RB setting may be an SL RB identifier. For example, if the SL RB is an SL SRB, the SL SRB identifier may be used, and if the SL RB is an SL DRB, the SL DRB identifier may be used.

[0481] The MN transmits the SL RB configuration to the relay UE. The MN may transmit the SL RB configuration to the relay UE by RRC signaling. The SL RB configuration may be transmitted by being included in an RRCReconfiguration message. Alternatively, the SL RB configuration may be transmitted by being included in an SL RRCReconfiguration message (RRCReconfigurationSidelink). The SL RB configuration may be transmitted by being included in SL RadioBearerConfig information (SL-RadioBearerConfig).

[0482] (2) may be set up as an SL RLC channel instead of an SL RLC bearer. In this specification, unless otherwise specified, the SL RLC bearer will be used for explanation.

[0483] Four examples of information to be included in the SL RLC bearer configuration are disclosed below: (2-1) Identifier of the corresponding RB. (2-2) Configuration information of the SL RLC bearer. (2-3) Identifier of the SL RLC bearer. (2-4) Combination of (2-1) to (2-3).

[0484] (2-1) may be an identifier of an RB corresponding to an RLC bearer of an SL. (2-2) may be, for example, RLC setting information. For example, it may be logical channel setting information. For example, it may be a logical channel identifier.

[0485] The MN sends an SL RLC bearer setup to the relay UE. The SL RLC bearer setup may be sent using an RRCReconfiguration message. The setup may be a modification of an already established SL RLC bearer setup. The message may include information indicating the already established SL RLC bearer setup.

[0486] The MN may transmit the SL bearer configuration information, RB configuration for Uu and / or RLC bearer configuration for Uu to the relay UE by including it in the RRC message to be transmitted, or by including it in a separate RRC message.

[0487] The MN sets up an SL bearer between the remote UE and the relay UE to the remote UE. The SL bearer may be set up for modifying the SL bearer. The SL bearer may also be modified. The SL bearer setting information may be appropriately applied to the examples disclosed above.

[0488] The MN transmits the SL RB configuration to the remote UE. The MN may transmit the SL RB configuration to the remote UE by RRC signaling. The configuration may be included in an RRCReconfiguration message and transmitted. Alternatively, the configuration may be included in an SL RRCReconfiguration message and transmitted. Alternatively, the configuration may be included in SL RadioBearerConfig information and transmitted.

[0489] The MN sends an SL RLC bearer setup to the remote UE. The SL RLC bearer setup may be sent using RRCReconfiguration. The setup may be a modification of an already established SL RLC bearer setup. The setup may include information indicating the already established SL RLC bearer setup.

[0490] When the MN sets up the SL bearer between the remote UE and the relay UE, the MN may use the setting information of the SL bearer between the remote UE and the relay UE received from the SN, which makes it possible to take into account the load situation in the SN.

[0491] By doing this, it is possible to set up an SL bearer between the remote UE and the relay UE used for communication between the remote UE and the NW. The SL bearer setting between the remote UE and the relay UE may be modified along with the setting of a DC in which the relay UE connects to two gNBs. It is possible to set up an SL bearer suitable for setting up a DC in which the relay UE connects to two gNBs. For example, it is also possible to set up an SL bearer between the remote UE and the relay UE suitable for increasing the communication capacity between the relay UE and the NW by DC. It is possible to increase the communication capacity between the remote UE and the NW via the relay UE.

[0492] Figure 42 is a sequence diagram showing another example of a DC setting method in which a relay UE connects to two gNBs for embodiment 4. This shows a case where the SL bearer setting is modified during the DC setting process for the relay UE. In Figure 42, the same step numbers are used for steps common to Figure 41, and common explanations are omitted. When it is necessary to modify the SL bearer between the remote UE and the relay UE, the MN sets up an SL bearer for the relay UE and the remote UE.

[0493] In Step ST4405, the MN transmits to the relay UE the configuration of an SL bearer between the remote UE and the relay UE. The SL bearer configuration may include the SL bearer configuration information disclosed above. The SL bearer configuration from the MN to the relay UE may be transmitted together with the DC configuration from the MN to the relay UE disclosed in FIG. 41, or may be transmitted as part of the DC configuration. Alternatively, it may be transmitted separately. In this example, the SL bearer configuration is transmitted together with the DC configuration, or may be transmitted as part of the DC configuration, in the same RRC message. The relay UE that has received the SL bearer configuration can configure an SL bearer for SL communication with the remote UE.

[0494] In step ST4406, the relay UE transmits a completion message of the SL bearer setup between the remote UE to the MN. The completion of the SL bearer setup from the relay UE to the MN may be transmitted together with the DC setup completion from the relay UE to the MN disclosed in FIG. 41, or may be transmitted by being included in the DC setup completion. Alternatively, it may be transmitted separately. In this example, it is transmitted together with the DC setup completion or by being included in the DC setup completion in the same RRC message.

[0495] In Step ST4501 following Step ST4405 above, the MN transmits to the remote UE the configuration of an SL bearer between the remote UE and the relay UE. The SL bearer configuration may include the SL bearer configuration information disclosed above. The SL bearer configuration from the MN to the remote UE is transmitted by RRC signaling. An RRC reconfiguration message may also be used. The remote UE that has received the SL bearer configuration can configure an SL bearer for SL communication with the relay UE.

[0496] In Step ST4502, the remote UE transmits a message indicating completion of the SL bearer setup between the relay UE and the MN to the MN. The completion of the SL bearer setup from the remote UE to the MN is transmitted by RRC signaling. The transmission may use an RRC reconfiguration complete message.

[0497] In this way, it is possible to modify the SL bearer between the remote UE and the relay UE. For example, when the DC setting between the relay UE and the MN, SN requires modification of the SL bearer setting between the remote UE and the relay UE, the processing of Figure 42 can be performed. It is possible to set up an SL bearer between the remote UE and the relay UE that is suitable for the DC setting.

[0498] Another example of a DC configuration method for a relay UE connecting to two gNBs is disclosed. The MN configures DC for the relay UE and the remote UE. The MN configures DC for the RB between the remote UE. The RB is for communication between the remote UE and the MN. The RB may be an SRB and / or DRB. The SRB may be SRB2. The MN configures an RLC bearer for the Uu for DC for the relay UE.

[0499] The relay UE may be in an RRC connected state with the MN. The remote UE may be in an RRC connected state with the MN. The remote UE with DC configured connects to the CN via the MN in the C-plane.

[0500] The MN sends a request to the SN to add an RB for communication between the remote UE and the MN. The request may be sent using Xn signaling, or may be sent using an S-Node addition request message.

[0501] The information to be included in the SN addition request in this DC setting method example may be any of the 17 pieces of information to be included in the SN addition request disclosed above.

[0502] The SN performs DC configuration for the relay UE. The SN may perform DC configuration for the relay UE using information received from the MN. The SN sends a response message to the MN for the SN addition request. When the SN performs DC configuration, it sends an SN addition request acknowledgement message to the MN. This may be transmitted using Xn signaling. An S-Node addition request acknowledge message may be used as the SN addition request acknowledgement message. If the SN is unable to perform DC configuration for the relay UE, it transmits an SN addition request rejection response message to the MN. This may be transmitted using Xn signaling. An S-Node addition request reject message may be used as the SN addition request rejection response message. The information included in the SN addition request response message may be appropriately applied to the information included in the SN addition request response message disclosed above.

[0503] The MN sends a DC configuration to the relay UE. Five examples of information to be included in the DC configuration are disclosed. (1) Information about RB. (2) Information about the RLC bearer of Uu. (3) SN identifier. (4) Information about ADP configuration. (5) A combination of (1) to (4).

[0504] The information to be included in these five DC settings is the information disclosed above, specifically, the above-mentioned four examples of information to be included in the DC setting when the MN transmits the DC setting to the relay UE.

[0505] However, (1) is information about an RB for communication between a remote UE and an MN. The MN does not configure an RB as a DC setting for the relay UE. Even if the RB for setting DC is an SRB, the MN does not configure an SRB. Even if the RB for setting DC is a DRB, the MN does not configure a DRB. The information about the RB in (1) may be, for example, only the identifier of the RB.

[0506] (4) is information about the configuration of the ADP configured between the RLC and the PDCP. The information about the ADP configuration includes, for example, information about the mapping function in the ADP, information about the RB to be configured, and information about the RLC bearer to be connected. The information about the ADP configuration may be included in the information about the RLC bearer of the Uu. By including the information about the ADP configuration in the information about the RLC bearer of the Uu, the amount of information can be reduced. In this way, the MN can configure the ADP for the relay UE.

[0507] The MN sets up an SL bearer between the remote UE and the relay UE to the relay UE. The SL bearer setting may be a setting for modifying the SL bearer, or may modify the SL bearer. Three examples of SL bearer setting information are disclosed below. (1) Information about the SL RLC bearer. (2) Information about the SL ADP setting. (3) A combination of (1) and (2).

[0508] The information regarding the SL RLC bearer may be appropriately applied from the information disclosed above, specifically, the aforementioned "(2) Information regarding the SL RLC bearer" used when the MN configures the SL bearer between the remote UE and the relay UE to the relay UE.

[0509] The information on the SL ADP configuration is information on the configuration of the PC5 ADP configured between the PC5 RLC and the PC5 PDCP. It is preferable that this information be configured when the PC5 ADP is configured. Examples of information on the ADP configuration include information on the mapping function in the ADP, information on the RB to be configured, and information on the SL RLC bearer to be connected. The information on the PC5 ADP configuration may be included in the information on the SL RLC bearer. Including the information on the PC5 ADP configuration in the information on the SL RLC bearer can reduce the amount of information. In this way, the MN can configure the SL ADP for the relay UE.

[0510] The MN does not need to configure an SL RB for the relay UE. Information about the SL RB does not need to be sent. SL PDCP and SL SDAP may not be configured. The MN configures one SL RLC bearer for DC for the relay UE.

[0511] When the MN configures the DC for the relay UE and / or the SL bearer between the remote UE and the relay UE, the DC between the relay UE and the SN received from the SN and / or the SL bearer configuration information between the remote UE and the relay UE may be used. It is possible to take into account the load situation in the SN.

[0512] The MN transmits a DC configuration to the remote UE. One example of information to be included in the DC configuration is disclosed below. (1) Information about RB.

[0513] The information regarding RB may be appropriately applied to the information disclosed above, specifically, the above-mentioned "(1) Information regarding RB" used when MN transmits DC settings to relay UE.

[0514] The MN sends the RB configuration to the remote UE. It may be sent by RRC signaling, or it may be sent in an RRCReconfiguration message, or it may be sent in RadioBearerConfig information.

[0515] The MN sets up an SL bearer between the remote UE and the relay UE to the remote UE. The SL bearer setting may be a setting for modifying the SL bearer, or may modify the SL bearer. Three examples of SL bearer setting information are disclosed below. (1) Information about the SL RLC bearer. (2) Information about the SL ADP setting. (3) A combination of (1) and (2).

[0516] The information regarding the SL RLC bearer and the information regarding the SL ADP settings may be appropriately applied from the information disclosed above.

[0517] The MN does not need to configure an SL RB for the remote UE. Information about the SL RB does not need to be sent. SL PDCP and SL SDAP may not be configured. The MN configures one SL RLC bearer for DC for the remote UE.

[0518] When the MN configures the DC for the remote UE and / or the SL bearer between the remote UE and the relay UE, the DC between the relay UE and the SN received from the SN and / or the SL bearer between the remote UE and the relay UE may be used. It is possible to take into account the load situation in the SN.

[0519] If the DC setting type is SN terminated, the PDU session may be modified. In this modification, a PDU session modification process is performed between the MN and the CN. The PDU session may be modified by appropriately applying the method disclosed above.

[0520] Data communication between the remote UE and the NW is carried out using a DC bearer (RLC bearer) between the MN / SN and the relay UE and an SL bearer between the relay UE and the remote UE.

[0521] The DC setting method disclosed above may be applied when the relay UE maps the DC RLC bearer and the SL bearer. For example, it may be applied to the protocol example disclosed in the above-mentioned Figure 39.

[0522] As a sequence example for another example of a DC configuration method in which a relay UE connects to two gNBs, the sequence example disclosed in Figure 42 above may be applied as appropriate.

[0523] Another example of a DC configuration method for a relay UE connecting to two gNBs is disclosed. The MN configures DC for the relay UE and the remote UE. The MN configures DC for the RB between the relay UE and the remote UE. The RB is for communication between the remote UE and the MN. The RB may be an SRB and / or DRB. The SRB may be SRB2.

[0524] The MN sets up an RLC bearer for the Uu for DC to the relay UE.

[0525] The MN establishes an SL bearer for DC between the relay UE and the remote UE. The SL bearer for DC may be two SL bearers, one for the MN and one for the SN.

[0526] The relay UE may be in an RRC connected state with the MN. The remote UE may be in an RRC connected state with the MN. The remote UE with DC configured connects to the CN via the MN in the C-plane.

[0527] The MN sends a request to the SN to add an RB for communication between the remote UE and the MN. The request may be sent using Xn signaling, or may be sent using an S-Node addition request message.

[0528] The information to be included in the SN addition request in this DC setting method example may be any of the 17 pieces of information to be included in the SN addition request disclosed above.

[0529] The SN performs DC configuration for the relay UE. The SN may perform DC configuration for the relay UE using information received from the MN. The SN sends a response message to the MN for the SN addition request. When the SN performs DC configuration, it sends an SN addition request acknowledgement message to the MN. This may be transmitted using Xn signaling. An S-Node addition request acknowledge message may be used as the SN addition request acknowledgement message. If the SN is unable to perform DC configuration for the relay UE, it transmits an SN addition request rejection response message to the MN. This may be transmitted using Xn signaling. An S-Node addition request reject message may be used as the SN addition request rejection response message. The information included in the SN addition request response message may be appropriately applied to the information included in the SN addition request response message disclosed above.

[0530] The MN transmits a DC setting to the relay UE. The information to be included in the DC setting may be appropriately applied to the information disclosed above.

[0531] The MN sets up an SL bearer between the remote UE and the relay UE to the relay UE. The SL bearer setting may be a setting for modifying the SL bearer, or may be a modification of the SL bearer. The SL bearer setting information may be appropriately applied to the information disclosed above.

[0532] The SL RLC bearer may be one. Alternatively, it may be multiple SL RLC bearers. Two SL RLC bearers may be set as the SL bearer setting for DC. In that case, it is preferable to use information about the two SL RLC bearers for DC. The two SL RLC bearers for DC may be the SL RLC bearer for MN and the SL RLC bearer for SN.

[0533] There may be one SL ADP. Alternatively, there may be multiple SL ADPs. Two SL ADPs may be configured as the SL bearer configuration for DC. In that case, it is preferable to use information related to the configuration of two SL ADPs for DC. The two SL ADPs for DC may be an SL ADP for MN and an SL ADP for SN.

[0534] The SL bearer setting may be included in the DC setting. The SL bearer setting information may be included in the DC setting information.

[0535] The MN does not need to configure an SL RB for the relay UE. Information about the SL RB does not need to be transmitted. SL PDCP and SL SDAP may not be configured. The MN configures two SL RLC bearers for DC for the relay UE.

[0536] When the MN configures the DC for the relay UE and / or the SL bearer between the remote UE and the relay UE, the DC between the relay UE and the SN received from the SN and / or the SL bearer configuration information between the remote UE and the relay UE may be used. It is possible to take into account the load situation in the SN.

[0537] The MN sends a DC setting to the remote UE. The information to be included in the DC setting may be appropriately applied to the information disclosed above.

[0538] The MN sets up an SL bearer between the remote UE and the relay UE to the remote UE. The SL bearer setting may be a setting for modifying the SL bearer, or may be a setting for modifying the SL bearer. The SL bearer setting information may be appropriately applied to the information disclosed above.

[0539] The SL RLC bearer may be one. Alternatively, it may be multiple SL RLC bearers. Two SL RLC bearers may be set as the SL bearer setting for DC. In that case, it is preferable to use information about the two SL RLC bearers for DC. The two SL RLC bearers for DC may be the SL RLC bearer for MN and the SL RLC bearer for SN.

[0540] There may be one SL ADP. Alternatively, there may be multiple SL ADPs. Two SL ADPs may be configured as the SL bearer configuration for DC. In that case, it is preferable to use information related to the configuration of two SL ADPs for DC. The two SL ADPs for DC may be an SL ADP for MN and an SL ADP for SN.

[0541] The SL bearer setting may be included in the DC setting. The SL bearer setting information may be included in the DC setting information.

[0542] The MN does not need to configure an SL RB for the remote UE. Information about the SL RB does not need to be transmitted. SL PDCP and SL SDAP may not be configured. The MN configures two SL RLC bearers for DC for the remote UE.

[0543] When the MN configures the DC for the remote UE and / or the SL bearer between the remote UE and the relay UE, the DC between the relay UE and the SN received from the SN and / or the SL bearer between the remote UE and the relay UE may be used. It is possible to take into account the load situation in the SN.

[0544] If the DC setting type is SN terminated, the PDU session may be modified. In this modification, a PDU session modification process is performed between the MN and the CN. The PDU session may be modified by appropriately applying the method disclosed above.

[0545] Data communication between the remote UE and the NW is carried out using a DC bearer (RLC bearer) between the MN / SN and the relay UE and two SL RLC bearers for DC between the relay UE and the remote UE.

[0546] The DC setting method disclosed above may be applied when DC is terminated at a remote UE. For example, it may be applied to the protocol example disclosed in the above-mentioned Figure 40.

[0547] As a sequence example for another example of a DC configuration method in which a relay UE connects to two gNBs, the sequence example disclosed in Figure 42 above may be applied as appropriate.

[0548] Another example of a DC setting method in which a relay UE connects to two gNBs is disclosed. The DC setting method in which the relay UE is the DC termination and the DC setting method in which the remote UE is the DC termination may be combined.

[0549] The MN configures the relay UE for DC. As a result, one or more DC bearers between the MN and the relay UE are mapped to one SL bearer between the relay UE and the remote UE. Next, the MN configures the remote UE for DC. The MN also configures two SL bearers for DC between the relay UE and the remote UE. As a result, the RLC bearer of the MN and SN between the MN and the relay UE is mapped to the SL RLC bearer of the MN and SN between the relay UE and the remote UE. The relay UE may perform this mapping at the PDU layer.

[0550] If RB modification is required from the MN to the remote UE, the RB configuration may be performed. For example, if the RB is modified to a split bearer, the RB configuration may be performed. The PDCP configuration may be modified for the split bearer.

[0551] In this way, data communication between the remote UE and the NW is carried out using a DC bearer (RLC bearer) between the MN / SN and the relay UE and two SL RLC bearers for DC between the relay UE and the remote UE.

[0552] Another example of a DC setting method in which a relay UE connects to two gNBs is disclosed. The DC setting method in which the RLC bearer for DC and the SL bearer are mapped in the relay UE and the DC setting method in which the remote UE is the DC termination may be combined.

[0553] The MN configures the relay UE for DC. The MN configures the remote UE for DC. As a result, one or more RLC bearers for DC between the MN and the relay UE are mapped to one SL RLC bearer between the relay UE and the remote UE. Next, the MN configures the remote UE for DC. The MN also configures two SL bearers for DC between the relay UE and the remote UE. As a result, the RLC bearers of the MN and SN between the MN and the relay UE are mapped to the SL RLC bearers of the MN and SN between the relay UE and the remote UE. The relay UE may perform this mapping at the ADP layer.

[0554] If RB modification is required from the MN to the remote UE, the RB configuration may be performed. For example, if the RB is modified to a split bearer, the RB configuration may be performed. The PDCP configuration may be modified for the split bearer.

[0555] In this way, data communication between the remote UE and the NW is carried out using a DC bearer (RLC bearer) between the MN / SN and the relay UE and two SL RLC bearers for DC between the relay UE and the remote UE.

[0556] When a DC setting method in which a relay UE is the DC termination and a DC setting method in which a remote UE is the DC termination are combined, or when a DC setting method in which an RLC bearer and an SL bearer for DC are mapped in a relay UE and a DC setting method in which a remote UE is the DC termination are combined, the sequence example disclosed in the above-mentioned FIG. 41 and the sequence example disclosed in FIG. 42 may be applied as appropriate.

[0557] By combining the DC setting method when the relay UE is the DC terminal and the DC setting method when the remote UE is the DC terminal, flexible DC setting is possible. For example, when the load is high in the PC5 communication between the relay UE and the remote UE, it is preferable to perform DC setting when the relay UE is the DC terminal. Flexible DC setting is possible.

[0558] By doing so, it is possible to set DC in indirect communication between the remote UE and the NW via the relay UE. In indirect communication between the remote UE and the NW via the relay UE, communication using multiple gNBs is possible. This enables performance improvements such as high speed, large capacity, low latency, and high reliability.

[0559] Fifth Embodiment In the fifth embodiment, another method for solving the problem described in the fourth embodiment will be disclosed.

[0560] In communication between a remote UE and a network via a relay UE, the remote UE is connected to multiple base stations. The multiple base stations may be, for example, two. In communication between a remote UE and a network via a relay UE, the remote UE is connected to two base stations. The remote UE may use the two base stations to set DC in communication between the remote UE and the network via the relay UE. The connection between the remote UE and the base station may be a direct connection or an indirect connection via a relay UE. The indirect connection includes at least one relay UE.

[0561] The remote UE connects to multiple gNBs for a radio bearer for communication between the remote UE and the NW. The radio bearer may be, for example, an SRB. For example, it may be SRB2. By communicating using a single gNB for SRB0 and SRB1, it is possible to simplify the communication establishment process. The radio bearer may be, for example, a DRB. This improves the communication quality of the bearer for data communication.

[0562] Figure 43 is a conceptual diagram showing an example of a case where a remote UE is connected to two gNBs in communication between a remote UE and a NW via a relay UE, for the fifth embodiment. In the example shown in Figure 43, the remote UE connects to the MgNB via relay UE #1 and connects directly to the SgNB. The MgNB and relay UE #1 are connected via Uu, and the relay UE #1 and the remote UE are connected via PC5. The SgNB and remote UE are connected via Uu. The MgNB and SgNB are connected via Xn. The remote UE may be in an RRC connected state with the MgNB. The relay UE #1 may be in an RRC connected state with the MgNB.

[0563] Figure 44 is a conceptual diagram showing another example of a case where a remote UE is connected to two gNBs in communication between a remote UE and a NW via a relay UE, for the fifth embodiment. In the example shown in Figure 44, the remote UE is directly connected to the MgNB and is connected to the SgNB via relay UE #2. The MgNB and the remote UE are connected via Uu. The SgNB and relay UE #2 are connected via Uu, and the relay UE #2 and the remote UE are connected via PC5. The MgNB and SgNB are connected via Xn. The remote UE may be in an RRC connected state with the MgNB. The relay UE #2 may be in an RRC connected state with the SgNB.

[0564] Figure 45 is a conceptual diagram showing another example of a case where a remote UE is connected to two gNBs in communication between a remote UE and a NW via a relay UE, for the fifth embodiment. In the example shown in Figure 45, the remote UE is connected to the MgNB via relay UE #1 and to the SgNB via relay UE #2. The MgNB and relay UE #1 are connected via Uu, and the relay UE #1 and the remote UE are connected via PC5. The SgNB and relay UE #2 are connected via Uu, and the relay UE #2 and the remote UE are connected via PC5. The MgNB and SgNB are connected via Xn. The remote UE may be in an RRC connected state with the MgNB. The relay UE #1 may be in an RRC connected state with the MgNB. The relay UE #2 may be in an RRC connected state with the SgNB.

[0565] This discloses a protocol configuration when a remote UE connects to two gNBs in communication between a remote UE and a network via a relay UE. Figure 46 is a diagram showing a protocol stack when a remote UE connects to two gNBs in communication between a remote UE and a network via a relay UE for a fifth embodiment. This shows a case where a remote UE connects to an MgNB via a relay UE #1 and directly connects to an SgNB. This shows the U-Plane.

[0566] The MN and SN have Uu protocols for DC. The Uu protocols include SDAP, PDCP, RLC, MAC, and PHY. In the Uu protocols for MN, ADP is configured between RLC and PDCP. ADP may be configured as a sublayer of RLC. As in the fourth embodiment described above, Figure 46 shows both MN-terminated bearers and SN-terminated bearers, as well as MCG bearers, SCG bearers, and split bearers, as bearers for DC. Protocols corresponding to these bearers are configured. One PDCP may be configured for the MN-terminated bearer and one for the SN-terminated bearer. It may be possible to configure these bearers during DC configuration.

[0567] The relay UE #1 has a Uu protocol for the MN. The Uu protocol includes RLC, MAC, and PHY. In the Uu protocol for the MN, ADP is configured between RLC and PDCP. ADP may be configured as a sublayer of RLC. The bearer for the MN is an MCG bearer or a split bearer. Protocols corresponding to these bearers are configured.

[0568] The relay UE #1 has a PC5 protocol between itself and the remote UE. The PC5 protocol may be used for the MN. The PC5 protocol includes PC5 RLC, PC5 MAC, and PC5 PHY. A PC5 ADP (SL ADP) may be configured above the PC5 RLC (SL RLC). The PC5 ADP may have a mapping function between the Uu bearer and the PC5 bearer, for example. The PC5 ADP may be configured as a sublayer of the PC5 RLC. The PC5 SDAP and PC5 PDCP may be omitted.

[0569] The remote UE has a PC5 protocol between itself and the relay UE #1. This PC5 protocol may be used for the MN. As with the relay UE #1, the PC5 protocol is PC5 RLC, PC5 MAC, and PC5 PHY. PC5 ADP may be configured above PC5 RLC. PC5 SDAP and PC5 PDCP may not be required. The remote UE also has a Uu protocol between itself and the SN. This Uu protocol is RLC, MAC, and PHY. The bearer for the SN is an SCG bearer or a split bearer. The remote UE also has a Uu protocol between itself and the MN and / or SN. This Uu protocol is SDAP and PDCP for the DC. In the remote UE, the PDCP or ADP of the PC5 for the MN and the PDCP of the Uu are connected, and the RLC of the Uu for the SN and the PDCP of the Uu are connected. One PDCP may be configured for the MN-terminated bearer and one for the SN-terminated bearer. The DC is terminated in the remote UE.

[0570] A bearer is disclosed. An RB is established between the MN and a remote UE. In the RB, a bearer for the MN is established between the MN and relay UE #1. The bearer for the MN is an MCG bearer or a split bearer. The MCG bearer or the split bearer may be an RLC bearer, or may be an RLC channel. One SL bearer is established between relay UE #1 and a remote UE. The SL bearer may be an SL RLC bearer for the MN, or may be an SL RLC channel. A bearer for the SN is established between the SN and a remote UE. The bearer for the SN is an SCG bearer or a split bearer. The SCG bearer or the split bearer may be an RLC bearer, or may be an RLC channel.

[0571] This disclosure relates to bearer mapping in communication from a network to a remote UE. In communication from the network to a remote UE, the MN and SN have a function of mapping the RB between the network and the remote UE to the RLC bearer of the Uu for DC. The RLC bearer of the Uu for DC may be an MCG bearer, an SCG bearer, or a split bearer. The number of remote UEs connected to relay UE #1 is not limited to one, but may be multiple. The number of RBs between the remote UE and the network is not limited to one, but may be multiple.

[0572] In the MN, the RBs of one or more remote UEs connected to the relay UE #1 and / or one or more RBs between the remote UE and the NW may be mapped to the RLC bearer of the Uu for DC. The above function may be included in the ADP of the Uu configured in the MN. The ADP may aggregate functions for when DC is configured and when it is not configured. In this case, the configuration of the MN can be simplified.

[0573] In communication from the NW to the remote UE, the MN may add the identifier of the remote UE and the identifier of the RB between the remote UE and the NW. If the RB is an SRB, the RB ID may be the SRB ID. If the RB is a DRB, the RB ID may be the DRB ID. In this way, the relay UE #1 can recognize the destination remote UE and the RB for communication between the remote UE and the NW.

[0574] The MN may add information about the bearer used for DC in communication from the NW to the remote UE. Information about the bearer used for DC, for example, an identifier indicating the end of the bearer and / or an identifier indicating the type of bearer and / or an identifier indicating whether it is for MN or SN. By doing so, the relay UE # 1 or the remote UE can recognize the end and type of the bearer used for DC.

[0575] The above-mentioned additional functions may be included in the ADP of the Uu configured in the MN. The functions for when the DC is configured and when it is not configured may be integrated into the ADP. In this case, the configuration of the MN can be simplified.

[0576] The relay UE #1 has a function of mapping the RLC bearer of the Uu for the MN to the RLC bearer of the PC5 for the MN in communication from the NW to the remote UE. The remote UE identifier and RB identifier added in the ADP of the MN may be used for this mapping. Information about the bearer used for the DC added by the MN may also be used for this mapping. This enables the relay UE #1 to map the MCG bearer or split bearer for the MN to the RLC bearer of the PC5 for the MN. The above-mentioned function may be included in the ADP of the Uu configured in the relay UE #1. The ADP may aggregate functions for when DC is configured and when it is not configured. In this case, the configuration of the relay UE #1 can be simplified.

[0577] When mapping to the RLC bearer of PC5, the relay UE #1 may delete some or all of the remote UE identifier, RB identifier, information about the bearer used for DC, etc. added by the MN. When mapping to the RLC bearer of PC5 to the remote UE, some or all of the identifiers and information may not be added.

[0578] The remote UE has a function of mapping the RLC bearer of PC5 for MN and the RLC bearer of Uu for SN to the RB between the NW and the remote UE in communication from the NW to the remote UE. The remote UE identifier and RB identifier added by the MN may be used for this mapping. Information about the bearer used for the DC added by the MN may also be used for this mapping.

[0579] This disclosure relates to bearer mapping in communication from a remote UE to a network. The remote UE has a function of mapping RBs between the network and the remote UE to an RLC bearer of a PC5 for DC and an RLC bearer of a Uu in communication from the remote UE to the network. The RLC bearer of the PC5 for DC is the RLC bearer of the PC5 for MN. The RLC bearer of the PC5 for MN may be an MCG bearer or a split bearer. The RLC bearer of the Uu for DC is the RLC bearer of a Uu for SN. The RLC bearer of the Uu for SN may be an SCG bearer or a split bearer. In communication from the network to the remote UE, the remote UE may add an identifier of the RB between the remote UE and the network and an identifier of a base station. There may be multiple base stations. For example, these may be added when a relay UE is connected to multiple base stations. Information indicating whether there are multiple base stations or whether there are multiple identifiers of the base stations may be added. The identifier of the base station may be the identifier of the MN and / or SN. For example, this may be applied when DC is set. By doing so, even when a relay UE transmits to multiple base stations, it is possible to identify the destination base station and the RB for communication between the remote UE and the network.

[0580] The remote UE may add information about the bearer used for DC in communication from the remote UE to the NW. Information about the bearer used for DC, for example, an identifier indicating the end of the bearer and / or an identifier indicating the type of bearer and / or an identifier indicating whether it is for MN or SN. By doing so, the relay UE, MN, or SN can recognize the end and type of the bearer used for DC.

[0581] The above-mentioned additional functions may be included in the SL ADP configured in the remote UE. The SL ADP may aggregate functions for when DC is configured and when DC is not configured. This makes it easier to configure the remote UE.

[0582] In communication from a remote UE to a network, the relay UE #1 has a function of mapping the RLC bearer of the PC5 for the MN to the RLC bearer of the Uu for the MN. The RLC bearer of the Uu for the MN may be an MCG bearer or a split bearer. The MCG bearer of the PC5 is mapped to the MCG bearer of the Uu. The split bearer of the PC5 is mapped to the split bearer of the Uu. The base station identifier, RB identifier, etc. added by the remote UE may be used for this mapping. Information about the bearer used for the DC added by the remote UE may also be used for this mapping. The number of remote UEs connected to the relay UE #1 is not limited to one, and multiple remote UEs may be connected. The above-mentioned function may be possessed by the ADP of the Uu configured in the relay UE #1. The ADP may aggregate functions for when DC is configured and when it is not configured. In this case, the configuration of the relay UE #1 can be simplified.

[0583] When mapping to the RLC bearer of Uu, the relay UE #1 may delete some or all of the remote UE identifier, RB identifier, information about the bearer used for DC, etc. added by the remote UE. When mapping to the RLC bearer of Uu to the MN, some or all of the identifiers and information may not be added.

[0584] In communication from a remote UE to a network, the relay UE #1 may add the identifier of the remote UE and the identifier of the RB between the remote UE and the network. If the RB is an SRB, the RB ID may be the SRB ID. If the RB is a DRB, the RB ID may be the DRB ID. This enables the MN to recognize the source remote UE and the RB for communication between the remote UE and the network. The above-mentioned additional function may be included in the ADP of the Uu for the MN configured in the relay UE #1. Functions for when DC is configured and when DC is not configured may be integrated into the ADP. In this case, the configuration of the relay UE can be simplified.

[0585] The MN and SN have a function of mapping the RLC bearer of the Uu for DC to an RB between the NW and the remote UE in communication from the remote UE to the NW. The number of remote UEs connected to the relay UE #1 is not limited to one, but may be multiple. The number of RBs between the remote UE and the NW is not limited to one, but may be multiple. The RLC bearer of the Uu for DC may be mapped to the RBs of one or multiple remote UEs connected to the relay UE #1 and / or one or multiple RBs between the remote UE and the NW. This mapping may use the remote UE identifier, RB identifier, information about the bearer used for DC, etc., added in the ADP of the Uu for MN of the remote UE or relay UE #1. This enables the MN and SN to transfer the MCG bearer, SCG bearer, or split bearer for DC to the PDCP of the RB for communication between the remote UE and the NW. The above function may be possessed by the ADP of the Uu configured in the MN and SN. The ADP may be configured to have functions for both cases where a DC is configured and where it is not configured, which can simplify the configuration of the MN and SN.

[0586] For the C-Plane protocol, an RRC may be provided instead of SDAP in the MN and remote UE. An RRC corresponding to the SRB may be provided. When DC is set in the SRB, only the MN terminated bearer may be set. DC of the SRB is possible.

[0587] By doing this, a remote UE connected to two gNBs can communicate between networks via a relay UE.

[0588] In communication between a remote UE and a NW via a relay UE, a setting method for connecting a remote UE to multiple gNBs is disclosed. In this embodiment, a setting method for DC in which a remote UE connects to two gNBs is disclosed.

[0589] This discloses a case where a remote UE connects to an MgNB via relay UE #1 and connects directly to an SgNB.

[0590] The MN configures DC for the remote UE. The MN configures DC for the RB between the remote UE. The RB may be for communication between the remote UE and the MN. The RB may be an SRB and / or DRB. The SRB may be SRB2.

[0591] The MN sets up an RLC bearer of the Uu for DC to the remote UE. The RLC bearer of the Uu for DC may be an RLC bearer between the MN and the SN.

[0592] The MN sets up an RLC bearer for the Uu for DC between the MN and the relay UE #1. It is used for DC setting for the RB between the MN and the remote UE. If there is no modification from the existing Uu RLC bearer as the RLC bearer for the Uu for DC, it is not necessary to set up a new one.

[0593] The MN establishes an SL bearer for DC between the relay UE #1 and the remote UE. The SL bearer for DC may be one SL bearer. The SL bearer may be an SL bearer for the MN. The SL bearer may be an SL RLC bearer.

[0594] The relay UE #1 may be in an RRC connected state with the MN. The remote UE may be in an RRC connected state with the MN. In addition, the MN may start DC configuration for the remote UE when the remote UE is in an RRC connected state with the MN. The remote UE with DC configured connects to the CN via the MN in the C-plane.

[0595] The MN sends a request to the SN to add an RB for communication between the remote UE and the MN. The request may be sent using Xn signaling, or may be sent using an S-Node addition request message.

[0596] The information to be included in the SN addition request may be any of the 17 examples of information to be included in the SN addition request disclosed above, with the relay UE in the example information being replaced with relay UE #1.

[0597] In this way, the MN can send an SN addition request for DC to the SN. Also, by receiving an SN addition request from the MN, the SN can recognize, for example, which remote UE the DC is for. The SN may use the information received from the MN to configure the DC for the remote UE.

[0598] The SN performs DC configuration for the relay UE. The SN sends a response message to the MN for the SN addition request. When the SN performs DC configuration, it sends an SN addition request acknowledgement message to the MN. This may be transmitted using Xn signaling. An S-Node addition request acknowledge message may be used as the SN addition request acknowledgement message. If the SN is unable to perform DC configuration for the relay UE, it transmits an SN addition request rejection response message to the MN. This may be transmitted using Xn signaling. An S-Node addition request reject message may be used as the SN addition request rejection response message. The information to be included in the SN addition request response message may be the information to be included in the SN addition request response message disclosed in embodiment 4, as appropriate.

[0599] The MN sends a DC configuration to the relay UE #1. Five examples of information to be included in the DC configuration are disclosed. (1) Information about RB. (2) Information about the RLC bearer of Uu. (3) SN identifier. (4) Information about ADP configuration. (5) A combination of (1) to (4).

[0600] The information to be included in these five DC settings may be the examples of information to be included in the DC settings disclosed above, as appropriate.

[0601] However, (1) is information about an RB for communication between a remote UE and an MN. The MN does not set an RB as a DC setting for relay UE #1. Even if the RB for setting DC is an SRB, no SRB setting is performed. Even if the RB for setting DC is a DRB, no DRB setting is performed. The information about the RB in (1) may be, for example, only the identifier of the RB.

[0602] (2) is information about the RLC bearer of Uu for DC. MN does not need to configure SCG for relay UE # 1. In this example, relay UE # 1 is not connected to SN in DC, so relay UE # 1 does not need to receive information about SCG.

[0603] Similarly, for (3), the MN does not need to transmit the identifier of the SN to the relay UE #1. In the DC of this example, the relay UE #1 does not connect to the SN, so the relay UE #1 does not need to receive the identifier of the SN.

[0604] The MN sets up an SL bearer between the remote UE and the relay UE #1 to the relay UE #1. The SL bearer setting may be a setting for modifying the SL bearer, or may be a setting for modifying the SL bearer. Three examples of SL bearer setting information are disclosed below. (1) Information about the SL RLC bearer. (2) Information about the SL ADP setting. (3) A combination of (1) and (2).

[0605] The SL bearer setting information may be appropriately applied from the example of SL bearer setting information disclosed above.

[0606] The MN does not need to configure an SL RB for the relay UE #1. Information about the SL RB does not need to be transmitted. SL PDCP and SL SDAP may not be configured. The MN may configure one SL bearer for DC for the relay UE #1. The configuration of the SL bearer for DC may be the configuration of an SL bearer for the MN.

[0607] When the MN configures the DC for the relay UE # 1 and / or configures the SL bearer between the remote UE and the relay UE # 1, it may use the configuration information for the DC between the remote UE and the SN received from the SN. It is possible to take into account the load situation in the SN.

[0608] The MN sends a DC configuration to the remote UE. Five examples of information to be included in the DC configuration are disclosed. (1) Information about RB. (2) Information about the RLC bearer of Uu. (3) SN identifier. (4) Information about ADP configuration. (5) A combination of (1) to (4).

[0609] The information to be included in these five DC settings may be the examples of information to be included in the DC settings disclosed above, as appropriate.

[0610] However, (2) is information about the RLC bearer of Uu for DC. The MN does not need to configure the remote UE for MCG. In DC, the remote UE connects to the MN via relay UE #1, so the remote UE does not need to receive information about the MCG.

[0611] The MN sets up an SL bearer between the remote UE and relay UE #1 to the remote UE. The SL bearer setting may be a setting for modifying the SL bearer, or may modify the SL bearer. Three examples of SL bearer setting information are disclosed. (1) Information about the SL RLC bearer. (2) Information about the SL ADP setting. (3) A combination of (1) and (2).

[0612] The SL bearer setting information may be appropriately applied from the example of SL bearer setting information disclosed above.

[0613] The number of SL RLC bearers may be one. As the setting of the SL bearer for DC, the SL RLC bearer for MN may be set.

[0614] The number of ADP settings for the SL may be one. The ADP of the SL for the MN may be set as the ADP setting of the SL for the DC.

[0615] The SL bearer setting may be included in the DC setting. The SL bearer setting information may be included in the DC setting information.

[0616] The MN does not need to configure an SL RB for the remote UE. Information about the SL RB does not need to be transmitted. SL PDCP and SL SDAP may not be configured. The MN may configure one SL bearer for DC for the remote UE. The configuration of the SL bearer for DC may be the configuration of an SL bearer for the MN.

[0617] When the MN configures the DC for the remote UE and / or configures the SL bearer between the remote UE and the relay UE # 1, it may use the configuration information for the DC between the remote UE and the SN received from the SN. It is possible to take into account the load situation in the SN.

[0618] If the DC setting type is SN terminated, the PDU session may be modified. In this modification, a PDU session modification process is performed between the MN and the CN. The PDU session may be modified by appropriately applying the method disclosed above.

[0619] Data communication between the remote UE and the network is carried out using an MCG bearer between the remote UE and the MN via relay UE #1, an SCG bearer between the remote UE and the SN, and split bearers between the remote UE and the MN and between the remote UE and the SN via relay UE #1.

[0620] Figure 47 is a sequence diagram showing an example of a DC setting method in which a remote UE connects to two gNBs for embodiment 5. This discloses a case in which a remote UE connects to an MgNB via a relay UE #1 and connects directly to an SgNB. In Figure 47, steps common to those in Figure 41 are given the same step numbers, and common explanations are omitted. In step ST5001, data communication is performed between the remote UE, relay UE #1, MN, and UPF.

[0621] The MN decides to configure DC for the remote UE. For example, the MN configures measurements of surrounding gNBs for the remote UE. The remote UE performs the configured measurements and reports the measurement results to the MN. In addition, the MN may configure measurements of surrounding relay UEs for the remote UE. The remote UE may perform the configured measurements and report the measurement results to the MN. The MN determines the SN to be used for DC from the measurement results.

[0622] In step ST4402, the MN transmits an SN addition request message to the SN decided to use for DC. The MN requests the SN to be added as an SN for DC for the remote UE. The SN addition request message is transmitted using Xn signaling. An S-Node addition request message may be used as the SN addition request message. The SN addition request message may include the example information of the SN addition request disclosed above.

[0623] The SN that received the SN addition request message from the MN recognizes the remote UE for which DC is to be configured, information regarding communication between the remote UE for which DC is to be configured and the NW, the requested bearer termination, the requested DC bearer type, etc., from the information of the SN addition request, and performs DC configuration for the remote UE. The DC configuration may be, for example, an RRC configuration between the SN and the remote UE. In step ST4403, the SN transmits an SN addition request response message to the MN. In this example, an acknowledgment is transmitted. An S-Node addition request acknowledge message may be used as the SN addition request response message. The SN addition request response message may include the RRC configuration between the SN and the remote UE. The MN that received the SN addition request response message recognizes that the SN has performed DC configuration for the remote UE. In addition, the MN recognizes the RRC configuration between the SN and the remote UE.

[0624] In step ST4404, the MN notifies the SN of an Xn-U address indication message. For example, the MN sets an address to be used for the DC between the MN and SN and transmits it to the SN in step ST4404. This allows the MN and SN to share the address to be used for the DC, enabling data transmission and reception between the MN and SN.

[0625] In step ST5005, the MN transmits the DC configuration and the SL bearer configuration to the relay UE #1. The SL bearer configuration may be transmitted together with the DC configuration, or the SL bearer configuration may be transmitted by including it in the DC configuration. Alternatively, the DC configuration and the SL bearer configuration may be transmitted separately. RRC signaling is used for this transmission. The configuration may be performed using an RRC reconfiguration message. The DC configuration may include the example information for the DC configuration disclosed above. The SL bearer configuration may include the SL bearer configuration information disclosed above. By receiving the DC configuration and the SL bearer configuration from the MN, the relay UE #1 can configure the DC configuration between the MN and the relay UE #1 and the SL bearer between the remote UE and the relay UE #1. The configuration may be modified.

[0626] In step ST5007, the relay UE #1 that has performed these settings transmits a DC setting response and an SL bearer setting response to the MN. In this example, a positive response is used. RRC signaling is used for the transmission. An RRC reconfiguration complete message may also be used. The MN that has received the DC setting response and the SL bearer setting response recognizes that the relay UE #1 has completed the DC setting and the SL bearer setting.

[0627] In step ST5006 following step ST5005 above, the MN transmits DC configuration and SL bearer configuration to the remote UE. The SL bearer configuration may be transmitted together with the DC configuration, or the SL bearer configuration may be transmitted by including it in the DC configuration. Alternatively, the DC configuration and the SL bearer configuration may be transmitted separately. RRC signaling is used for this transmission. An RRC reconfiguration message may be used. The DC configuration may include the example DC configuration information disclosed above. The RRC configuration information received from the SN may be used as the SCG-related configuration of the DC configuration information. The SL bearer configuration may include the SL bearer configuration information disclosed above. By receiving the DC configuration and SL bearer configuration from the MN, the remote UE can configure the DC configuration between the MN and the remote UE and the SL bearer between the remote UE and relay UE #1. The configuration may be modified.

[0628] In step ST5008, the remote UE that has performed these settings transmits a DC setting response and an SL bearer setting response to the MN. In this example, this is a positive response. RRC signaling is used for this transmission. An RRC reconfiguration complete message may also be used. The MN that has received the DC setting response and the SL bearer setting response recognizes that the remote UE has completed the DC setting and the SL bearer setting.

[0629] In step ST4407, the MN transmits an SN configuration complete message to the SN. Xn signaling is used for this transmission. An S-Node reconfiguration complete message may also be transmitted. By receiving this message, the SN recognizes that the MN and remote UE have completed the SN configuration for DC.

[0630] In Step ST4408, the remote UE starts an RA procedure with the SN while maintaining communication with the MN, and continues communication.

[0631] In Step ST4409, the MN performs SN state transfer to the SN, and in Step ST4410, transfers the data from the UPF to the SN. In the case of an SN-terminated bearer, it is necessary to change the path between the UPF and the gNB from the MN to the SN. In this case, the path update process of Step ST4420 is performed. As a result, in Step ST5015, data communication is performed between the remote UE, SN, and UPF.

[0632] In this way, DC is performed between the MN and SN via the remote UE and relay UE #1. For example, in the case of an SN-terminated SCG bearer, data communication is performed between the remote UE, SN, and UPF.

[0633] For example, in the case of an MN-terminated SCG bearer, data communication is performed between the MN and UPF via the remote UE, SN, and relay UE #1. For example, in the case of an SN-terminated MCG bearer, data communication is performed between the MN, SN, and UPF via the remote UE and relay UE #1. For example, in the case of an MN-terminated split bearer, data communication is performed between the MN and UPF via the remote UE, SN, and relay UE. For example, in the case of an SN-terminated split bearer, data communication is performed between the MN, SN, and UPF via the remote UE and relay UE #1.

[0634] RRC signaling may be performed between the SN and the remote UE. The RRC signaling may be performed using SRB3. After the remote UE and the SN start communication in Step ST4408, the remote UE may transmit an RRC message to the SN, and the SN may transmit an RRC message to the remote UE using SRB3. The RRC message using SRB3 may be, for example, a message related to the SN. For example, it may be a message such as a message for changing the setting of an SCG bearer, an SN measurement report, or transmission of information related to the filer of the SCG bearer. In this way, RRC messages can be communicated directly between the SN and the remote UE without going through the MN, thereby reducing the amount of signaling and delay.

[0635] By doing this, it becomes possible for a remote UE to connect to an MgNB via relay UE #1 and configure a DC that connects directly to an SgNB.

[0636] Another method of protocol configuration when a remote UE connects to two gNBs in communication between a remote UE and a NW via a relay UE is disclosed. Figure 48 is a diagram showing another method of configuring a protocol stack when a remote UE connects to two gNBs in communication between a remote UE and a NW via a relay UE, for a fifth embodiment. This shows a case where a remote UE connects directly to an MgNB and connects to an SgNB via a relay UE #2. This shows the U-Plane.

[0637] The MN and SN have Uu protocols for DC. The Uu protocols include SDAP, PDCP, RLC, MAC, and PHY. In the Uu protocols for SN, ADP is configured between RLC and PDCP. ADP may be configured as a sublayer of RLC. Figure 48 shows both MN-terminated bearers and SN-terminated bearers as bearers for DC. Also shown are MCG bearers, SCG bearers, and split bearers. Protocols corresponding to these bearers are configured. One PDCP may be configured for the MN-terminated bearer and one for the SN-terminated bearer. It may be possible to configure these bearers during DC configuration.

[0638] The relay UE #2 has a Uu protocol for SN. The Uu protocol includes RLC, MAC, and PHY. In the Uu protocol for SN, ADP is configured between RLC and PDCP. ADP may be configured as a sublayer of RLC. The bearer for MN is an MCG bearer or a split bearer. Protocols corresponding to these bearers are configured.

[0639] The relay UE #2 has a PC5 protocol between itself and the remote UE. The PC5 protocol may be used for SN. The PC5 protocol includes PC5 RLC, PC5 MAC, and PC5 PHY. A PC5 ADP may be configured above the PC5 RLC. The PC5 ADP may have, for example, a mapping function between the Uu bearer and the PC5 bearer. The PC5 ADP may be configured as a sublayer of the PC5 RLC. The PC5 SDAP and PC5 PDCP may be omitted.

[0640] The remote UE has a PC5 protocol between itself and the relay UE #2. This PC5 protocol may be used for the SN. As with the relay UE #2, the PC5 protocol is PC5 RLC, PC5 MAC, and PC5 PHY. PC5 ADP may be configured above PC5 RLC. PC5 SDAP and PC5 PDCP may not be required. The remote UE also has a Uu protocol between itself and the MN. This Uu protocol is RLC, MAC, and PHY. For the MN, this is for an SCG bearer or a split bearer. The remote UE also has a Uu protocol between itself and the MN and / or SN. This Uu protocol is SDAP and PDCP for the DC. In the remote UE, the PDCP or ADP of the PC5 for the SN and the PDCP of the Uu are connected, and the RLC of the Uu for the MN and the PDCP of the Uu are connected. One PDCP may be configured for the MN-terminated bearer and one for the SN-terminated bearer. The DC is terminated in the remote UE.

[0641] A bearer is disclosed. An RB is established between the MN and a remote UE. In the RB, a bearer for the SN is established between the SN and relay UE #2. The bearer for the SN is an SCG bearer or a split bearer. The SCG bearer or the split bearer may be an RLC bearer or may be an RLC channel. One SL bearer is established between relay UE #2 and the remote UE. The SL bearer may be an SL RLC bearer for the SN or may be an SL RLC channel. A bearer for the MN is established between the MN and a remote UE. The bearer for the MN is an MCG bearer or a split bearer. The MCG bearer or the split bearer may be an RLC bearer or may be an RLC channel.

[0642] This disclosure relates to bearer mapping in communication from a network to a remote UE. In communication from the network to a remote UE, the MN and SN have a function of mapping the RB between the network and the remote UE to the RLC bearer of the Uu for DC. The RLC bearer of the Uu for DC may be an MCG bearer, an SCG bearer, or a split bearer. The number of remote UEs connected to relay UE #2 is not limited to one, but may be multiple. The number of RBs between the remote UE and the network is not limited to one, but may be multiple.

[0643] The RBs of one or more remote UEs connected to the relay UE #2 and / or one or more RBs between the remote UE and the NW may be mapped to the RLC bearer of the Uu for DC. The above function may be included in the ADP of the Uu configured in the SN. The ADP may aggregate functions for when DC is configured and when it is not configured. In this case, the configuration of the SN can be simplified.

[0644] In communication from the NW to the remote UE, the SN may add the identifier of the remote UE and the identifier of the RB between the remote UE and the NW. If the RB is an SRB, the RB ID may be the SRB ID. If the RB is a DRB, the RB ID may be the DRB ID. In this way, the relay UE #2 can recognize the destination remote UE and the RB for communication between the remote UE and the NW.

[0645] The SN may add information about the bearer used for DC in communication from the NW to the remote UE. Information about the bearer used for DC, for example, an identifier indicating the end of the bearer and / or an identifier indicating the type of bearer and / or an identifier indicating whether it is for MN or SN. By doing so, the relay UE # 2 or the remote UE can recognize the end and type of the bearer used for DC.

[0646] The above-mentioned additional functions may be included in the ADP of the Uu configured in the SN. The ADP may also be configured to aggregate functions for when the DC is configured and when it is not configured. In this case, the configuration of the SN can be simplified.

[0647] The relay UE #2 has a function of mapping the RLC bearer of the Uu for SN to the RLC bearer of the PC5 for SN in communication from the NW to the remote UE. The remote UE identifier and RB identifier added in the ADP of the SN may be used for this mapping. Information about the bearer used for the DC added in the SN may also be used for this mapping. In this way, the relay UE #2 can map the SCG bearer or split bearer for SN to the RLC bearer of the PC5 for SN. The above-mentioned function may be included in the ADP of the Uu configured in the relay UE #2. The ADP may aggregate functions for when DC is configured and when it is not configured. In this case, the configuration of the relay UE #2 can be simplified.

[0648] When mapping to the RLC bearer of PC5, relay UE #2 may delete some or all of the remote UE identifier, RB identifier, information about the bearer used for DC, etc. added in SN. When mapping to the RLC bearer of PC5 to the remote UE, some or all of the identifiers and information may not be added.

[0649] The remote UE has a function of mapping the RLC bearer of the Uu for the MN and the RLC bearer of the PC5 for the SN to the RB between the NW and the remote UE in communication from the NW to the remote UE. The remote UE identifier and the RB identifier added by the SN may be used for this mapping. Information about the bearer used for the DC added by the SN may also be used for this mapping.

[0650] This disclosure relates to bearer mapping in communication from a remote UE to a network. The remote UE has a function of mapping RBs between the network and the remote UE to an RLC bearer of a Uu for DC and an RLC bearer of a PC5 in communication from the remote UE to the network. The RLC bearer of the Uu for DC is an RLC bearer of a Uu for MN. The RLC bearer of the Uu for MN can be an MCG bearer or a split bearer. The RLC bearer of the PC5 for DC is an RLC bearer of a PC5 for SN. The RLC bearer of the PC5 for SN can be an SCG bearer or a split bearer. In communication from the network to the remote UE, the remote UE may add an identifier of the RB between the remote UE and the network and an identifier of a base station. There may be multiple base stations. For example, these identifiers may be added when a relay UE is connected to multiple base stations. Information indicating whether there are multiple base stations or whether there are multiple identifiers of the base stations may be added. The identifier of the base station may be the identifier of the MN and / or SN. For example, this may be applied when DC is set. By doing so, even when a relay UE transmits to multiple base stations, it is possible to identify the destination base station and the RB for communication between the remote UE and the network.

[0651] The remote UE may add information about the bearer used for DC in communication from the remote UE to the NW. Information about the bearer used for DC, for example, an identifier indicating the end of the bearer and / or an identifier indicating the type of bearer and / or an identifier indicating whether it is for MN or SN. By doing so, the relay UE, MN, or SN can recognize the end and type of the bearer used for DC.

[0652] The above-mentioned additional functions may be included in the SL ADP configured in the remote UE. The SL ADP may aggregate functions for when DC is configured and when DC is not configured. This makes it easier to configure the remote UE.

[0653] In communication from a remote UE to a network, relay UE #2 has a function of mapping the RLC bearer of PC5 for SN to the RLC bearer of Uu for SN. The RLC bearer of Uu for SN may be an SCG bearer or a split bearer. The SCG bearer of PC5 is mapped to the SCG bearer of Uu. The split bearer of PC5 is mapped to the split bearer of Uu. The mapping may use information such as a base station identifier, RB identifier, and bearer used for DC added by the remote UE. The number of remote UEs connected to relay UE #2 is not limited to one, and multiple remote UEs may be connected. The above-mentioned function may be possessed by the ADP of Uu configured in relay UE #2. The ADP may aggregate functions for when DC is configured and when it is not configured. In this case, the configuration of relay UE #2 can be simplified.

[0654] When mapping to the RLC bearer of Uu, the relay UE #2 may delete some or all of the remote UE identifier, RB identifier, information about the bearer used for DC, etc. added by the remote UE. When mapping to the RLC bearer of Uu to SN, some or all of the identifiers and information may not be added.

[0655] In communication from a remote UE to a network, the relay UE #2 may add the identifier of the remote UE and the identifier of the RB between the remote UE and the network. If the RB is an SRB, the RB ID may be the SRB ID. If the RB is a DRB, the RB ID may be the DRB ID. This enables the SN to recognize the source remote UE and the RB for communication between the remote UE and the network. The above-mentioned additional function may be included in the ADP of the Uu for the SN configured in the relay UE #2. Functions for when DC is configured and when it is not configured may be integrated into the ADP. In this case, the configuration of the relay UE #2 can be simplified.

[0656] The MN and SN have a function of mapping the RLC bearer of the Uu for DC to an RB between the NW and the remote UE in communication from the remote UE to the NW. The number of remote UEs connected to the relay UE #2 is not limited to one, but may be multiple. The number of RBs between the remote UE and the NW is not limited to one, but may be multiple. The RLC bearer of the Uu for DC may be mapped to the RBs of one or multiple remote UEs connected to the relay UE #2 and / or one or multiple RBs between the remote UE and the NW. This mapping may use the remote UE identifier, RB identifier, information about the bearer used for DC, etc., added in the ADP of the Uu for the SN of the remote UE or relay UE #2. This enables the MN and SN to transfer the MCG bearer, SCG bearer, or split bearer for DC to the PDCP of the RB for communication between the remote UE and the NW. The above function may be possessed by the ADP of the Uu configured in the MN and SN. The ADP may be configured to have functions for both cases where a DC is configured and where it is not configured, which can simplify the configuration of the MN and SN.

[0657] For the C-Plane protocol, an RRC may be provided instead of SDAP in the MN and remote UE. An RRC corresponding to the SRB may be provided. When DC is set in the SRB, only the MN terminated bearer may be set. DC of the SRB is possible.

[0658] By doing this, a remote UE connected to two gNBs can communicate between networks via a relay UE.

[0659] In communication between a remote UE and a NW via a relay UE, a setting method for connecting a remote UE to multiple gNBs is disclosed. In this embodiment, a setting method for DC in which a remote UE connects to two gNBs is disclosed.

[0660] This discloses a case where a remote UE connects directly to an MgNB and connects to an SgNB via a relay UE #2.

[0661] The MN configures DC for the remote UE. The MN configures DC for the RB between the remote UE. The RB may be for communication between the remote UE and the MN. The RB may be an SRB and / or DRB. The SRB may be SRB2.

[0662] The MN sets up an RLC bearer of the Uu for DC to the remote UE. The RLC bearer of the Uu for DC may be an RLC bearer between the MN and the remote UE.

[0663] The MN sets up an RLC bearer for the Uu for DC between the SN and the relay UE #2. It is used for DC setting for the RB between the MN and the remote UE. If there is no modification from the existing Uu RLC bearer as the RLC bearer for the Uu for DC, it is not necessary to set up a new one.

[0664] The MN establishes an SL bearer for DC between the relay UE #2 and the remote UE. The SL bearer for DC may be one SL bearer. The SL bearer may be an SL bearer for SN. The SL bearer may be an SL RLC bearer.

[0665] The relay UE #2 may be in an RRC connected state with the SN. The remote UE may be in an RRC connected state with the MN. In addition, the MN may start DC configuration for the remote UE when the remote UE is in an RRC connected state with the MN. The remote UE with DC configured connects to the CN via the MN in the C-plane.

[0666] The MN sends a request to the SN to add an RB for communication between the remote UE and the MN. The request may be sent using Xn signaling, or may be sent using an S-Node addition request message.

[0667] The information to be included in the SN addition request may be any of the 17 examples of information to be included in the SN addition request disclosed above, with the relay UE in the example information being replaced with relay UE #2.

[0668] However, since the MN and the remote UE are connected without the relay UE #2, there is no need for configuration information between the MN and the relay UE #2. For example, the MN does not transmit (4), (7), or (9) to the SN among the 17 examples of information included in the SN addition request disclosed above.

[0669] Of the 17 information examples included in the SN addition request disclosed above, the information about the relay UE in (1) may include information indicating which relay UE the SN will use to perform DC configuration with the remote UE. It may also include information about the configuration of the relay UE. It may also include a measurement result of the relay UE #2 by the remote UE. It may also include a measurement result of the SN by the relay UE #2.

[0670] By doing this, the MN can send an SN addition request for DC to the SN. Also, by receiving an SN addition request from the MN, the SN can recognize, for example, which remote UE the DC is for, and which relay UE to connect to the remote UE through. The SN may use the information received from the MN to configure DC for the remote UE via the relay UE. The DC configuration for the remote UE via the relay UE may be the DC configuration between the SN and the relay UE.

[0671] The SN performs DC configuration for the remote UE via the relay UE. The SN sends a response message to the MN for the SN addition request. When the SN performs DC configuration, it sends an SN addition request acknowledgement message to the MN. This may be transmitted using Xn signaling. An S-Node addition request acknowledge message may be used as the SN addition request acknowledgement message. If the SN is unable to perform DC configuration for the relay UE, it transmits an SN addition request rejection response message to the MN. This may be transmitted using Xn signaling. An S-Node addition request reject message may be used as the SN addition request rejection response message. The information included in the SN addition request response message may be appropriately applied to the information included in the SN addition request response message disclosed above.

[0672] The SN sends a DC configuration to the relay UE #2. Five examples of information to be included in the DC configuration are disclosed. (1) Information about the RB. (2) Information about the RLC bearer of the Uu. (3) SN identifier. (4) Information about the ADP configuration. (5) A combination of (1) to (4).

[0673] The information to be included in these five DC settings may be the examples of information to be included in the DC settings disclosed above, as appropriate.

[0674] However, (1) is information about an RB for communication between a remote UE and an MN. The SN does not set an RB as a DC setting for relay UE #2. Even if the RB for setting DC is an SRB, no SRB setting is performed. Even if the RB for setting DC is a DRB, no DRB setting is performed. The information about the RB in (1) may be, for example, only the RB identifier.

[0675] (2) is information about the RLC bearer of Uu for DC. SN does not need to configure MCG for relay UE # 2. In this example, relay UE # 2 is not connected to MN in DC, so relay UE # 2 does not need to receive information about MCG.

[0676] The SN sets up an SL bearer between the remote UE and the relay UE #2 to the relay UE #2. If there is an existing SL bearer between the remote UE and the relay UE #2, the SL bearer may be modified. The SL bearer setting may be a setting for modifying the SL bearer. Three examples of SL bearer setting information are disclosed. (1) Information about the SL RLC bearer. (2) Information about the SL ADP setting. (3) A combination of (1) and (2).

[0677] The SL bearer setting information may be appropriately applied from the example of SL bearer setting information disclosed above.

[0678] The SN does not need to configure an SL RB for the relay UE #2. Information about the SL RB does not need to be transmitted. SL PDCP and SL SDAP may not be configured. The SN may configure one SL bearer for DC for the relay UE #2. The configuration of the SL bearer for DC may be the configuration of an SL bearer for the SN.

[0679] The MN sends a DC configuration to the remote UE. Five examples of information to be included in the DC configuration are disclosed. (1) Information about RB. (2) Information about the RLC bearer of Uu. (3) SN identifier. (4) Information about ADP configuration. (5) A combination of (1) to (4).

[0680] The information to be included in these five DC settings may be the examples of information to be included in the DC settings disclosed above, as appropriate.

[0681] However, (2) is information about the RLC bearer of Uu for DC. The MN does not need to configure the remote UE for SCG. In DC, the remote UE connects to the SN via the relay UE # 2, so the remote UE does not need to receive information about the SCG.

[0682] The MN sends to the remote UE the setting of an SL bearer between the remote UE and relay UE #2. If there is an existing SL bearer between the remote UE and relay UE #2, the SL bearer may be modified. The setting of the SL bearer may be a setting for modifying the SL bearer. Three examples of SL bearer setting information are disclosed: (1) Information about the SL RLC bearer; (2) Information about the SL ADP setting; and (3) A combination of (1) and (2).

[0683] The SL bearer setting information may be appropriately applied from the example of SL bearer setting information disclosed above.

[0684] The number of SL RLC bearers may be one. The SL bearer for DC may be set up by...

Claims

1. A first base station, which is composed of a central unit and a distributed unit, and serves as an access-backhaul integration donor; one or more second base stations operating as integrated access and backhaul nodes; Including, The central unit performs address setting for multicasting data from the central unit to the communication terminal in a backhaul adaptation layer that routes data transmitted and received by the communication terminal to the distributed unit and the second base station. A communication system comprising:

2. The central unit assigns a multicast address in the backhaul adaptation layer to the second base station to which the communication terminal is connected; 2. The communication system according to claim 1 .

3. The central unit assigns a multicast address in the backhaul adaptation layer to the second base station to which a communication terminal is connected and to which no other second base station is connected; 2. The communication system according to claim 1 .

4. The central unit assigns the same address as a multicast address in the backhaul adaptation layer to each of the second base stations having the same connection destination.

2. The communication system according to claim 1 .

5. The central unit assigns a multicast address in the backhaul adaptation layer to the second base station to which a communication terminal that receives multicast data is connected; 2. The communication system according to claim 1 .

6. The central unit assigns the same address as a multicast address in the backhaul adaptation layer to the second base station having the same hierarchy as the distributed unit or the communication terminal.

2. The communication system according to claim 1 .

7. The central unit assigns the same address as a multicast address in the backhaul adaptation layer to the second base stations forming a route to a communication terminal that is a destination of the multicast data.

2. The communication system according to claim 1 .

8. There are a plurality of conditions for allocating the same address as a multicast address in the backhaul adaptation layer, the central unit assigns, to the second base station which satisfies two or more of the conditions, two or more multicast addresses corresponding to each of the satisfied conditions; 2. The communication system according to claim 1 .

9. The central unit copies data to be multicast transmitted; 2. The communication system according to claim 1 .

10. the second base station, when a destination communication terminal receives the same multicast data from different routes, forwards the multicast data received from one of the routes; 10. A communication system according to claim 1, wherein the first and second communication devices are connected to each other.

11. A first base station and a second base station constituting a fifth generation wireless access system; a first communication terminal connected to the first base station and the second base station; a second communication terminal that performs inter-terminal communication between communication terminals directly communicating with the first communication terminal and is simultaneously connected to the first base station and the second base station via the first communication terminal; A communication system comprising:

12. A first base station and a second base station constituting a fifth generation wireless access system; a first communication terminal connected to the first base station or the second base station; a second communication terminal that performs inter-terminal communication between communication terminals directly communicating with the first communication terminal, connects to the first base station or the second base station via the first communication terminal, and connects to the first base station or the second base station without going through the first communication terminal; A communication system comprising:

13. The second communication terminal directly connects to the first base station or the second base station to which the first communication terminal is not connected; 13. The communication system according to claim 12.

14. a third communication terminal connected to the first base station or the second base station to which the first communication terminal is not connected; Equipped with the second communication terminal performs the inter-terminal communication with the third communication terminal and connects to the first base station or the second base station via the third communication terminal; 13. The communication system according to claim 12.

15. A base station constituting a fifth generation wireless access system; A first communication terminal connected to the base station; a second communication terminal that performs inter-terminal communication between communication terminals directly communicating with the first communication terminal, connects to the base station via the first communication terminal, and connects to the base station without via the first communication terminal; A communication system comprising:

16. The second communication terminal connects to the base station via the first communication terminal and also directly connects to the base station.

16. The communication system according to claim 15.

17. a third communication terminal connected to the base station; Equipped with the second communication terminal connects to the base station via the first communication terminal and connects to the base station via the third communication terminal; 16. The communication system according to claim 15.

18. A base station, which is composed of a central unit and a distributed unit and serves as an access-backhaul integration donor, For one or more other base stations operating as the access / backhaul integration node, an address setting is performed for multicasting data toward the communication terminal in a backhaul adaptation layer that routes data transmitted and received by the communication terminal; A base station comprising: