WO2022255133A1 - 通信システムおよび基地局 - Google Patents

通信システムおよび基地局 Download PDF

Info

Publication number
WO2022255133A1
WO2022255133A1 PCT/JP2022/021015 JP2022021015W WO2022255133A1 WO 2022255133 A1 WO2022255133 A1 WO 2022255133A1 JP 2022021015 W JP2022021015 W JP 2022021015W WO 2022255133 A1 WO2022255133 A1 WO 2022255133A1
Authority
WO
WIPO (PCT)
Prior art keywords
bap
information
base station
communication
iab
Prior art date
Application number
PCT/JP2022/021015
Other languages
English (en)
French (fr)
Inventor
忠宏 下田
満 望月
Original Assignee
三菱電機株式会社
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 三菱電機株式会社 filed Critical 三菱電機株式会社
Priority to EP22815884.6A priority Critical patent/EP4351191A1/en
Priority to CN202280037897.8A priority patent/CN117356118A/zh
Priority to JP2023525730A priority patent/JPWO2022255133A1/ja
Priority to KR1020237039728A priority patent/KR20240014466A/ko
Publication of WO2022255133A1 publication Critical patent/WO2022255133A1/ja

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04B—TRANSMISSION
    • H04B7/00—Radio transmission systems, i.e. using radiation field
    • H04B7/14—Relay systems
    • H04B7/15—Active relay systems
    • H04B7/155—Ground-based stations
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W16/00—Network planning, e.g. coverage or traffic planning tools; Network deployment, e.g. resource partitioning or cells structures
    • H04W16/24—Cell structures
    • H04W16/26—Cell enhancers or enhancement, e.g. for tunnels, building shadow
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/06—Selective distribution of broadcast services, e.g. multimedia broadcast multicast service [MBMS]; Services to user groups; One-way selective calling services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W40/00—Communication routing or communication path finding
    • H04W40/02—Communication route or path selection, e.g. power-based or shortest path routing
    • H04W40/22—Communication route or path selection, e.g. power-based or shortest path routing using selective relaying for reaching a BTS [Base Transceiver Station] or an access point
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W76/00—Connection management
    • H04W76/10—Connection setup
    • H04W76/14—Direct-mode setup
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W8/00—Network data management
    • H04W8/26—Network addressing or numbering for mobility support
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W84/00—Network topologies
    • H04W84/02—Hierarchically pre-organised networks, e.g. paging networks, cellular networks, WLAN [Wireless Local Area Network] or WLL [Wireless Local Loop]
    • H04W84/04—Large scale networks; Deep hierarchical networks
    • H04W84/042—Public Land Mobile systems, e.g. cellular systems
    • H04W84/047—Public Land Mobile systems, e.g. cellular systems using dedicated repeater stations
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W88/00—Devices specially adapted for wireless communication networks, e.g. terminals, base stations or access point devices
    • H04W88/02—Terminal devices
    • H04W88/04—Terminal devices adapted for relaying to or from another terminal or user
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W92/00—Interfaces specially adapted for wireless communication networks
    • H04W92/16—Interfaces between hierarchically similar devices
    • H04W92/20—Interfaces between hierarchically similar devices between access points
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/50—Address allocation
    • H04L61/5007—Internet protocol [IP] addresses
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/50—Address allocation
    • H04L61/5069—Address allocation for group communication, multicast communication or broadcast communication

Definitions

  • This disclosure relates to wireless communication technology.
  • LTE Long Term Evolution
  • SAE System Architecture Evolution
  • OFDM Orthogonal Frequency Division Multiplexing
  • SC-FDMA Single Carrier Frequency Division Multiple Access
  • LTE does not include circuit switching and is only a packet communication method.
  • FIG. 1 is an explanatory diagram showing the structure of a radio frame used in an LTE communication system.
  • one radio frame is 10 ms.
  • a radio frame is divided into 10 equally sized subframes.
  • a subframe is divided into two equal-sized slots.
  • a downlink synchronization signal is included in the first and sixth subframes of each radio frame.
  • Synchronization signals include a primary synchronization signal (P-SS) and a secondary synchronization signal (S-SS).
  • Non-Patent Document 1 (Chapter 5) describes the decisions made by 3GPP regarding the channel configuration in the LTE system. It is assumed that CSG (Closed Subscriber Group) cells also use the same channel configuration as non-CSG cells.
  • a physical broadcast channel is a communication terminal device such as a base station device (hereinafter sometimes simply referred to as a "base station”) to a mobile terminal device (hereinafter sometimes simply referred to as a “mobile terminal”). (hereinafter sometimes simply referred to as "communication terminal”).
  • a BCH transport block is mapped to 4 subframes in a 40ms interval. There is no explicit signaling of 40ms timing.
  • PCFICH Physical Control Format Indicator Channel
  • the PCFICH notifies the communication terminal from the base station of the number of OFDM (Orthogonal Frequency Division Multiplexing) symbols used for PDCCHs.
  • PCFICH is transmitted every subframe.
  • a Physical Downlink Control Channel is a channel for downlink transmission from a base station to a communication terminal.
  • PDCCH includes resource allocation information for a downlink shared channel (DL-SCH), which is one of the transport channels described later, and paging channel (PCH), which is one of the transport channels described later. ) and HARQ (Hybrid Automatic Repeat ReQuest) information on DL-SCH.
  • DL-SCH downlink shared channel
  • PCH paging channel
  • HARQ Hybrid Automatic Repeat ReQuest
  • PDCCH carries an uplink scheduling grant.
  • the PDCCH carries Ack (Acknowledgment)/Nack (Negative Acknowledgment), which are response signals to uplink transmission.
  • PDCCH is also called L1/L2 control signal.
  • a physical downlink shared channel is a channel for downlink transmission from a base station to a communication terminal.
  • a downlink shared channel (DL-SCH), which is a transport channel, and a PCH, which is a transport channel, are mapped to the PDSCH.
  • a Physical Multicast Channel is a channel for downlink transmission from a base station to a communication terminal.
  • a multicast channel (Multicast Channel: MCH), which is a transport channel, is mapped to PMCH.
  • a physical uplink control channel is a channel for uplink transmission from a communication terminal to a base station.
  • PUCCH carries Ack/Nack, which is a response signal for downlink transmission.
  • PUCCH carries CSI (Channel State Information).
  • CSI is composed of RI (Rank Indicator), PMI (Precoding Matrix Indicator), and CQI (Channel Quality Indicator) reports.
  • RI is rank information of a channel matrix in MIMO.
  • PMI is precoding weight matrix information used in MIMO.
  • CQI is quality information indicating the quality of received data or communication channel quality.
  • PUCCH also carries a scheduling request (SR).
  • SR scheduling request
  • a physical uplink shared channel is a channel for uplink transmission from a communication terminal to a base station.
  • An uplink shared channel (UL-SCH), which is one of transport channels, is mapped to the PUSCH.
  • a Physical Hybrid ARQ Indicator Channel is a channel for downlink transmission from a base station to a communication terminal.
  • PHICH carries Ack/Nack, which is a response signal to uplink transmission.
  • a physical random access channel is a channel for uplink transmission from a communication terminal to a base station. PRACH carries a random access preamble.
  • a downlink reference signal (reference signal: RS) is a symbol known as an LTE communication system.
  • the following five types of downlink reference signals are defined.
  • Cell-specific reference signal (CRS), MBSFN reference signal (MBSFN reference signal), data demodulation reference signal (DM-RS) which is UE-specific reference signal (UE-specific reference signal) , Positioning Reference Signal (PRS), Channel State Information Reference Signal (CSI-RS).
  • RSRP reference signal received power
  • the uplink reference signal is also a symbol known as an LTE communication system.
  • the following two types of uplink reference signals are defined. They are a data demodulation reference signal (DM-RS) and a sounding reference signal (SRS).
  • DM-RS data demodulation reference signal
  • SRS sounding reference signal
  • Non-Patent Document 1 (Chapter 5) will be explained.
  • the broadcast channel (BCH) is broadcast over the entire coverage of the base station (cell).
  • BCH is mapped to a Physical Broadcast Channel (PBCH).
  • PBCH Physical Broadcast Channel
  • HARQ Hybrid ARQ
  • DL-SCH downlink shared channel
  • the DL-SCH can be broadcast to the entire coverage of the base station (cell).
  • DL-SCH supports dynamic or semi-static resource allocation.
  • Semi-static resource allocation is also called persistent scheduling.
  • DL-SCH supports discontinuous reception (DRX) of communication terminals in order to reduce the power consumption of communication terminals.
  • the DL-SCH is mapped onto a physical downlink shared channel (PDSCH).
  • PDSCH physical downlink shared channel
  • a paging channel supports DRX of a communication terminal in order to enable low power consumption of the communication terminal.
  • the PCH is required to be broadcast to the entire coverage of the base station (cell).
  • the PCH is dynamically mapped to a physical resource such as a Physical Downlink Shared Channel (PDSCH) that can be used for traffic.
  • PDSCH Physical Downlink Shared Channel
  • a multicast channel 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.
  • MCH supports semi-static resource allocation.
  • MCH is mapped to PMCH.
  • HARQ Hybrid ARQ
  • PUSCH physical uplink shared channel
  • RACH random access channel
  • PRACH Physical Random Access Channel
  • HARQ is a technique for improving the communication quality of a transmission line by combining automatic repeat request (ARQ) and error correction (Forward Error Correction).
  • ARQ automatic repeat request
  • FEC Correction Forward Error Correction
  • HARQ has the advantage that error correction functions effectively by retransmission even for a transmission path whose communication quality changes. In particular, it is possible to further improve the quality by combining the reception result of the initial transmission and the reception result of the retransmission at the time of retransmission.
  • BCCH broadcast control channel
  • BCH broadcast channel
  • DL-SCH downlink shared channel
  • a paging control channel is a downlink channel for transmitting changes in paging information and system information.
  • PCCH is used when the network does not know the cell location of the communication terminal.
  • a logical channel, PCCH is mapped to a transport channel, a paging channel (PCH).
  • a common control channel is a channel for transmission control information between a communication terminal and a base station. CCCH is used when the communication terminal does not have an RRC connection with the network.
  • CCCH is mapped to a downlink shared channel (DL-SCH), which is a transport channel.
  • DL-SCH downlink shared channel
  • UL-SCH uplink shared channel
  • a multicast control channel is a downlink channel for one-to-many transmission.
  • MCCH is used for transmission of MBMS control information for one or several MTCHs from the network to communication terminals.
  • MCCH is used only for communication terminals that are receiving MBMS.
  • MCCH is mapped to a multicast channel (MCH), which is a transport channel.
  • a dedicated control channel is a channel that transmits dedicated control information between a communication terminal and a network on a one-to-one basis.
  • DCCH is used when the communication terminal is in an RRC connection.
  • DCCH is mapped to an uplink shared channel (UL-SCH) in uplink, and mapped to a downlink shared channel (DL-SCH) in downlink.
  • UL-SCH uplink shared channel
  • DL-SCH downlink shared channel
  • a dedicated traffic channel is a one-to-one communication channel to a dedicated communication terminal for transmitting user information.
  • DTCH exists in both uplink and downlink.
  • the DTCH is mapped to an uplink shared channel (UL-SCH) in uplink, and mapped to a downlink shared channel (DL-SCH) in downlink.
  • UL-SCH uplink shared channel
  • DL-SCH downlink shared channel
  • a multicast traffic channel is a downlink channel for transmitting traffic data from a network to communication terminals.
  • MTCH is a channel used only by communication terminals that are receiving MBMS.
  • MTCH is mapped to a multicast channel (MCH).
  • CGI is a Cell Global Identifier.
  • ECGI is an E-UTRAN Cell Global Identifier.
  • LTE Long Term Evolution Advanced
  • UMTS Universal Mobile Telecommunication System
  • CSG Cell Subscriber Group
  • Communication terminal location tracking is performed in units of areas consisting of one or more cells. Position tracking is performed to track the position of the communication terminal even in a standby state and to call the communication terminal, in other words, to enable the communication terminal to receive a call.
  • the area for position tracking of this communication terminal is called a tracking area.
  • LTE-A Long Term Evolution Advanced
  • CA Carrier Aggregation
  • the UE When CA is configured, the UE, which is a communication terminal, has a network (Network: NW) and only one RRC connection. In an RRC connection, one serving cell provides NAS mobility information and security input. This cell is called a primary cell (PCell).
  • PCell In the downlink, the carrier corresponding to the PCell is the downlink primary component carrier (DL PCC).
  • DL PCC downlink primary component carrier
  • UPC uplink primary component carrier
  • a secondary cell is configured together with the PCell to form a set of serving cells.
  • the carrier corresponding to the SCell is the Downlink Secondary Component Carrier (DL SCC).
  • the carrier corresponding to the SCell is the uplink secondary component carrier (UL SCC).
  • a serving cell set consisting of one PCell and one or more SCells is configured for one UE.
  • LTE-A new technologies in LTE-A include technology that supports wider bands (wider bandwidth extension) and coordinated multiple point transmission and reception (CoMP) technology.
  • CoMP under consideration for LTE-A in 3GPP is described in Non-Patent Document 1.
  • small-scale base station devices small-scale base station devices
  • technologies such as installing a large number of small eNBs and configuring a large number of small cells to improve frequency utilization efficiency and increase communication capacity are being studied.
  • DC dual connectivity
  • eNBs that perform dual connectivity (DC)
  • MeNB master eNB
  • SeNB secondary eNB
  • the volume of mobile network traffic is on the rise, and communication speeds are also increasing. Once full-scale operation of LTE and LTE-A is started, it is expected that the communication speed will be further increased.
  • 5G 5th generation radio access system
  • METIS a 5th generation radio access system
  • the 5G radio access system Compared to the LTE system, the 5G radio access system has 1000 times the system capacity, 100 times the data transmission speed, 1/10th the data processing delay, and 100 times the number of simultaneous connections of communication terminals. As a requirement, it is necessary to further reduce power consumption and reduce the cost of the device.
  • the NR system is being studied based on the LTE and LTE-A systems, but the following changes and additions have been made to the LTE and LTE-A systems.
  • OFDM is used in the downlink direction
  • OFDM is used in the uplink direction
  • DFT-s-OFDM DFT-spread-OFDM
  • NR In NR, cell coverage is ensured by forming a narrow beam-shaped transmission/reception range (beamforming) and changing the direction of the beam (beam sweeping).
  • Various subcarrier intervals that is, various numerologies are supported in the NR frame configuration.
  • one subframe is 1 millisecond and one slot is composed of 14 symbols regardless of numerology.
  • the number of slots included in one subframe is one in numerology with a subcarrier interval of 15 kHz, and increases in proportion to the subcarrier interval in other numerologies (Non-Patent Document 13 (3GPP TS38.211 )reference).
  • 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) with a predetermined period and a predetermined duration.
  • the SS burst is composed of synchronization signal blocks (Synchronization Signal Blocks: hereinafter sometimes referred to as SS blocks) for each beam of the base station.
  • the base station transmits the SS block of each beam by changing the beam within the duration of the SS burst.
  • the SS block consists of P-SS, S-SS and PBCH.
  • phase tracking reference signal a phase tracking reference signal (PTRS) as a downlink reference signal for NR.
  • the PTRS is added to the uplink reference signal as well as the downlink.
  • SFI Slot Format Indication
  • BWP Bandwidth Part
  • SL Side Link
  • EPS Evolved Packet System
  • multicast using NR is under study.
  • a reliable multicast method dynamic switching between point-to-multipoint (PTM) transmission and point-to-point (PTP) transmission is being studied.
  • PTM point-to-multipoint
  • PTP point-to-point
  • base station with a CU (Central Unit)/DU (Distributed Unit) separated configuration is being studied (see Non-Patent Document 31).
  • CU Central Unit
  • D Distributed Unit
  • IAB Integrated Access and Backhaul
  • a 5G base station can support Integrated Access and Backhaul (IAB) (see Non-Patent Document 16 (TS38.300)). Also, it has been proposed to perform multicasting using base stations that support IAB (hereinafter sometimes referred to as IAB base stations) (see Non-Patent Document 41 (R3-210017)). However, there is no disclosure of detailed multicast setting methods in IAB base stations, particularly settings in the BAP (Backhaul Adaptation Protocol) layer that performs routing between IAB nodes. Therefore, there arises a problem that multicast using IAB base stations cannot be realized.
  • IAB base stations hereinafter sometimes referred to as IAB base stations
  • BAP Backhaul Adaptation Protocol
  • one object of the present disclosure is to enable multicast transmission in a communication system to which access/backhaul integration is applied.
  • a communication system comprises a central unit and a distributed unit, a first base station acting as a donor for access backhaul integration, and one or more second base stations acting as nodes for access backhaul integration. and multicasting data from the central unit to the communication terminals in a backhaul adaptation layer where the central unit routes data sent and received by the communication terminals to the distribution unit and the second base station. address settings for
  • FIG. 2 is an explanatory diagram showing the configuration of a radio frame used in an LTE communication system
  • 1 is a block diagram showing the overall configuration of an LTE-based communication system 200 under discussion in 3GPP
  • FIG. 1 is a block diagram showing the overall configuration of an NR-based communication system 210 under discussion in 3GPP
  • FIG. 3 is a block diagram of DC with eNB and gNB connecting to EPC
  • FIG. 4 is a block diagram of DC by gNB connected to NG core
  • FIG. 4 is a block diagram of DC by eNB and gNB connecting to NG core
  • FIG. 4 is a block diagram of DC by eNB and gNB connecting to NG core
  • 3 is a block diagram showing the configuration of mobile terminal 202 shown in FIG. 2.
  • FIG. 3 is a block diagram showing the configuration of base station 203 shown in FIG. 2.
  • FIG. It is a block diagram which shows the structure of MME. It is a block diagram which shows the structure of a 5GC part.
  • FIG. 2 is a flowchart showing an overview from cell search to standby operation performed by a communication terminal (UE) in an LTE-based communication system;
  • FIG. 1 is a diagram showing an example of a cell configuration in an NR system;
  • FIG. FIG. 4 is a diagram showing an example of a list of BAP addresses in Embodiment 1;
  • FIG. 4 is a diagram showing an example of a BAP header for Embodiment 1;
  • FIG. 10 is a diagram showing another example of a BAP header in Embodiment 1;
  • FIG. 10 is a diagram showing another example of a BAP header in Embodiment 1;
  • FIG. FIG. 10 is a diagram showing another example of a BAP header in Embodiment 1;
  • FIG. 10 is a diagram showing another example of a BAP header in Embodiment 1;
  • FIG. 10 is a diagram showing another example of a BAP header in Embodiment 1;
  • FIG. FIG. 4 is a diagram showing the first half of a sequence showing an example of multicast setting in an IAB base station in Embodiment 1;
  • FIG. 10 is a diagram showing the second half of a sequence showing an example of multicast setting in an IAB base station in Embodiment 1;
  • FIG. 4 is a diagram showing an example of allocation of BAP addresses for multicast according to Embodiment 1;
  • FIG. 4 is a diagram showing another example of allocation of multicast BAP addresses according to the first embodiment;
  • FIG. 4 is a diagram showing another example of allocation of multicast BAP addresses according to the first embodiment;
  • FIG. 4 is a diagram showing another example of allocation of multicast BAP addresses according to the first embodiment;
  • FIG. 4 is a diagram showing a bitmap of multicast BAP addresses in the first embodiment;
  • FIG. 4 is a diagram showing another example of allocation of multicast BAP addresses according to the first embodiment;
  • FIG. 4 is a diagram showing another example of allocation of multicast BAP addresses according to the first embodiment;
  • FIG. 4 is a diagram showing another example of allocation of multicast BAP addresses according to the first embodiment;
  • FIG. 4 is a diagram showing another example of allocation of multicast BAP addresses according to the first embodiment;
  • FIG. 4 is a diagram showing another example of allocation of multicast BAP addresses
  • FIG. 4 is a diagram showing another example of allocation of multicast BAP addresses according to the first embodiment;
  • FIG. 10 is a diagram showing an example of duplication operation in the BAP layer according to the second embodiment;
  • FIG. 10 is a diagram showing another example of copying operation in the BAP layer in the second embodiment;
  • FIG. 10 is a diagram showing another example of copying operation in the BAP layer in the second embodiment;
  • FIG. 10 is a diagram showing another example of copying operation in the BAP layer in the second embodiment;
  • FIG. 10 is a diagram showing an example of replication operation in a terminal IAB node on a protocol stack from an IAB donor CU to a UE for Embodiment 2;
  • FIG. 13 is a diagram showing an example in which multiple paths of data merge in the middle, according to the third embodiment;
  • FIG. 14 is a conceptual diagram when a relay UE is connected to two gNBs in communication between a remote UE and a NW via a relay UE, according to Embodiment 4;
  • FIG. 14 is a diagram showing a protocol stack when a relay UE connects with two gNBs in communication between a remote UE and a NW via a relay UE, according to Embodiment 4;
  • FIG. 13 is a diagram showing another configuration method of a protocol stack when a relay UE connects with two gNBs in communication between a remote UE and a NW via a relay UE, according to Embodiment 4;
  • FIG. 20 is a conceptual diagram showing an example of a case where a remote UE connects with two gNBs in communication between a remote UE and a NW via a relay UE, according to Embodiment 5;
  • FIG. 21 is a conceptual diagram showing another example of a case where a remote UE connects with two gNBs in communication between a remote UE and a NW via a relay UE, according to Embodiment 5;
  • FIG. 21 is a conceptual diagram showing another example of a case where a remote UE connects with two gNBs in communication between a remote UE and a NW via a relay UE, according to Embodiment 5;
  • FIG. 14 is a diagram showing a protocol stack when a remote UE connects with two gNBs in communication between a remote UE and a NW via a relay UE, according to Embodiment 5;
  • FIG. 20 is a sequence diagram showing an example of a setting method of a DC in which a remote UE connects with two gNBs, according to Embodiment 5;
  • FIG. 20 is a diagram showing another configuration method of a protocol stack when a remote UE connects with two gNBs in communication between a remote UE and a NW via a relay UE, according to Embodiment 5;
  • FIG. 20 is a sequence diagram showing an example of a setting method of a DC in which a remote UE connects with two gNBs, according to Embodiment 5;
  • FIG. 20 is a diagram showing another configuration method of a protocol stack when a remote UE connects with two gNBs in communication between a remote UE and a NW via a relay UE, according to Embodiment 5;
  • FIG. 20 is a sequence diagram showing an example of a setting method of a DC in which a remote UE connects with two gNBs, according to Embodiment 5;
  • FIG. 14 is a conceptual diagram showing an example of a case where a remote UE connects with one gNB via two paths in communication between a remote UE and a NW via a relay UE, according to Embodiment 6;
  • FIG. 21 is a conceptual diagram showing another example of a case where the remote UE connects with one gNB via two paths in communication between the remote UE and the NW via the relay UE, according to Embodiment 6;
  • FIG. 20 is a diagram showing a protocol stack when the DC is set by the remote UE using the MN and the relay UE#S as a substitute for the SN in the communication between the remote UE and the NW, according to the sixth embodiment;
  • FIG. 20 is a diagram showing a protocol stack between MN and relay UE#S for Embodiment 6;
  • FIG. 20 is a sequence diagram showing an example of a setting method of a DC in which a remote UE is connected to one gNB via two paths, according to Embodiment 6;
  • Embodiment 6 in the communication between the remote UE and the NW, another configuration method of the protocol stack when the DC is set by the remote UE using the MN and the relay UE #S that substitutes for the SN is
  • FIG. 4 is a diagram showing;
  • FIG. 20 is a sequence diagram showing an example of a setting method of a DC in which a remote UE is connected to one gNB via two paths, according to Embodiment 6;
  • FIG. 2 is a block diagram showing the overall configuration of an LTE-based communication system 200 under discussion in 3GPP.
  • the radio access network is called E-UTRAN (Evolved Universal Terrestrial Radio Access Network) 201 .
  • a mobile terminal device hereinafter referred to as “user equipment (UE)”
  • UE user equipment
  • base station E-UTRAN NodeB: eNB
  • communication terminal equipment includes not only mobile terminal equipment such as mobile phone terminal equipment, but also non-moving devices such as sensors.
  • communication terminal device may be simply referred to as “communication terminal”.
  • a control protocol for the mobile terminal 202 such as RRC (Radio Resource Control), and a user plane (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 the base station 203, the E-UTRAN is composed of one or more base stations 203.
  • RRC Radio Resource Control
  • U-Plane user plane
  • PDCP Packet Data Convergence Protocol
  • RLC Radio Link Control
  • MAC Medium Access Control
  • PHY Physical layer
  • a control protocol RRC Radio Resource Control
  • RRC Radio Resource Control
  • the states of the base station 203 and mobile terminal 202 in RRC include RRC_IDLE and RRC_CONNECTED.
  • RRC_IDLE PLMN (Public Land Mobile Network) selection, system information (SI) notification, paging, cell re-selection, mobility, etc. are performed.
  • RRC_CONNECTED the mobile terminal has an RRC connection and can send and receive data to and from the network. Also, in RRC_CONNECTED, handover (HO), measurement of neighboring cells (measurement), etc. are performed.
  • the base station 203 is composed of one or more eNBs 207.
  • EPC Evolved Packet Core
  • EPS Evolved Packet System
  • the EPC, which is the core network, and the E-UTRAN 201, which is the radio access network, may be collectively referred to as a “network”.
  • the eNB 207 is a Mobility Management Entity (MME), or an S-GW (Serving Gateway), or an MME/S-GW section including the MME and S-GW (hereinafter sometimes referred to as "MME section") 204 and Control information is communicated between the eNB 207 and the MME unit 204 via the S1 interface.
  • MME Mobility Management Entity
  • S-GW Serving Gateway
  • MME/S-GW section including the MME and S-GW
  • Control information is communicated between the eNB 207 and the MME unit 204 via the S1 interface.
  • a plurality of MME units 204 may be connected to one eNB 207 .
  • the eNBs 207 are connected by an X2 interface, and control information is communicated between the eNBs 207 .
  • the MME unit 204 is a higher-level device, specifically a higher-level node, and controls connection between the eNB 207, which is a base station, and the mobile terminal (UE) 202.
  • the MME unit 204 constitutes an EPC, which is a core network.
  • Base station 203 constitutes E-UTRAN 201 .
  • the base station 203 may configure one cell or multiple cells. Each cell has a predetermined range as coverage, which is a range in which mobile terminal 202 can be communicated with, and wirelessly communicates with mobile terminal 202 within the coverage. When one base station 203 constitutes a plurality of cells, each cell is configured to be able to communicate with the mobile terminal 202 .
  • FIG. 3 is a block diagram showing the overall configuration of a 5G communication system 210 under discussion in 3GPP.
  • the radio access network is called 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 "NR base station (NG-RAN NodeB: gNB)") 213, and transmits and receives signals by wireless communication.
  • NR base station (NG-RAN NodeB: gNB) Next Generation Radio Access Network
  • the core network is called 5G Core (5GC).
  • 5GC 5G Core
  • Control protocols for UE 202 such as RRC (Radio Resource Control), user plane (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 configured by one or more NR base stations 213.
  • RRC Radio Resource Control
  • U-Plane user plane
  • SDAP Service Data Adaptation Protocol
  • PDCP Packet Data Convergence Protocol
  • RLC Radio Link Control
  • MAC Medium Access Control
  • PHY Physical layer
  • the function of the control protocol RRC (Radio Resource Control) between the UE 202 and the NR base station 213 is the same as in LTE.
  • the states of the NR base station 213 and the UE 202 in RRC include RRC_IDLE, RRC_CONNECTED, and RRC_INACTIVE.
  • RRC_IDLE and RRC_CONNECTED are the same as in the LTE system.
  • RRC_INACTIVE maintains the connection between the 5G core and the NR base station 213, while system information (System Information: SI) is broadcast, paging, cell re-selection, mobility, etc. are performed. .
  • SI System Information
  • gNB 217 has access and mobility management function (AMF), session management function (SMF), or user plane function (UPF), or AMF/SMF/UPF including AMF, SMF and UPF section (hereinafter sometimes referred to as “5GC section”) 214 via an NG interface.
  • AMF access and mobility management function
  • SMF session management function
  • UPF user plane function
  • AMF/SMF/UPF including AMF, SMF and UPF section hereinafter sometimes referred to as “5GC section” 214 via an NG interface.
  • AMF access and mobility management function
  • SMF session management function
  • UPF user plane function
  • AMF/SMF/UPF including AMF, SMF and UPF section hereinafter sometimes referred to as “5GC section” 214 via an NG interface.
  • Control information and/or user data are communicated between the gNB 217 and the 5GC unit 214 .
  • the NG interface is a generic term for the N2 interface between gNB 217 and AMF, the
  • the 5GC unit 214 is a host device, specifically a host node, and distributes paging signals to one or more base stations 203 and/or base stations 213 .
  • the 5GC unit 214 performs mobility control in the idle state (Idle State).
  • the 5GC unit 214 manages the tracking area list when the mobile terminal 202 is in the standby state, inactive state, and in the active state.
  • the 5GC unit 214 initiates the paging protocol by sending a paging message to the cell belonging to the Tracking Area in which the mobile terminal 202 is registered.
  • each cell is configured to be able to communicate with UE 202 .
  • the gNB 217 may be divided into a central unit (hereinafter referred to as CU) 218 and a distributed unit (hereinafter referred to as DU) 219.
  • CU central unit
  • DU distributed unit
  • One CU 218 is configured in gNB 217 .
  • One or more DUs 219 are configured in gNBs 217 .
  • CU 218 is connected to DU 219 by an F1 interface, and control information and/or user data are communicated between CU 218 and DU 219 .
  • the 5G communication system may include the Unified Data Management (UDM) function and Policy Control Function (PCF) described in Non-Patent Document 21 (3GPP TS23.501).
  • UDM and/or PCF may be included in 5GC section 214 in FIG.
  • a location management function (LMF) described in Non-Patent Document 24 (3GPP TS38.305) may be provided.
  • the LMF may be connected to the base station via AMF as disclosed in Non-Patent Document 25 (3GPP TS23.273).
  • the non-3GPP interworking function (N3IWF) described in Non-Patent Document 21 (3GPP TS23.501) may be included.
  • the N3IWF may terminate an access network (AN) with the UE in non-3GPP access with the UE.
  • AN access network
  • FIG. 4 is a diagram showing the configuration of DC by eNB and gNB connected to EPC.
  • solid lines indicate U-Plane connections
  • dashed lines indicate C-Plane connections.
  • the eNB 223-1 is the master base station and the gNB 224-2 is the secondary base station (this DC configuration is sometimes referred to as EN-DC).
  • FIG. 4 shows an example in which the U-Plane connection between the MME unit 204 and the gNB 224-2 is performed via the eNB 223-1, but even if it is performed directly between the MME unit 204 and the gNB 224-2 good.
  • FIG. 5 is a diagram showing the configuration of DC by gNBs connected to the NG core.
  • solid lines indicate U-Plane connections
  • dashed lines indicate C-Plane connections.
  • gNB 224-1 is the master base station
  • gNB 224-2 is the secondary base station (this DC configuration may be referred to as NR-DC).
  • FIG. 5 shows an example in which the U-Plane connection between the 5GC unit 214 and the gNB224-2 is performed via the gNB224-1. good.
  • FIG. 6 is a diagram showing the configuration of DC by eNB and gNB connected to the NG core.
  • solid lines indicate U-Plane connections
  • dashed lines indicate C-Plane connections.
  • the eNB 226-1 is the master base station and the gNB 224-2 is the secondary base station (this DC configuration may be referred to as NG-EN-DC).
  • FIG. 6 shows an example in which the U-Plane connection between the 5GC unit 214 and the gNB224-2 is performed via the eNB226-1. good.
  • FIG. 7 is a diagram showing another configuration of DC by eNB and gNB connected to the NG core.
  • solid lines indicate U-Plane connections
  • dashed lines indicate C-Plane connections.
  • gNB 224-1 is the master base station
  • eNB 226-2 is the secondary base station (this DC configuration may be referred to as NE-DC).
  • FIG. 7 shows an example in which the U-Plane connection between the 5GC unit 214 and the eNB 226-2 is performed via the gNB 224-1. good.
  • FIG. 8 is a block diagram showing the configuration of mobile terminal 202 shown in FIG. Transmission processing of the mobile terminal 202 shown in FIG. 8 will be described.
  • control data from the protocol processing unit 301 and user data from the application unit 302 are saved in the transmission data buffer unit 303 .
  • the data stored in the transmission data buffer unit 303 is transferred to the encoder unit 304 and subjected to encoding processing such as error correction.
  • the data encoded by the encoder section 304 is modulated by the modulation section 305 . Precoding in MIMO may be performed in modulation section 305 .
  • the modulated data After being converted into a baseband signal, the modulated data is output to frequency conversion section 306 and converted into a radio transmission frequency. Thereafter, transmission signals are transmitted to base station 203 from antennas 307-1 to 307-4.
  • FIG. 8 illustrates the case where the number of antennas is four, but the number of antennas is not limited to four.
  • the reception processing of the mobile terminal 202 is executed as follows. Radio signals from base station 203 are received by antennas 307-1 to 307-4. The received signal is converted from a radio reception frequency to a baseband signal by frequency conversion section 306 , and demodulated by demodulation section 308 . Weight calculation and multiplication processing may be performed in the demodulator 308 . The demodulated data is passed to the decoder section 309 and subjected to decoding processing such as error correction. Of the decoded data, control data is passed to protocol processing section 301 and user data is passed to application section 302 . A series of processing of mobile terminal 202 is controlled by control unit 310 .
  • the control unit 310 is connected to each of the units 301 to 309, though omitted in FIG.
  • the control unit 310 is implemented by, for example, a processing circuit including a processor and memory. That is, the control unit 310 is realized by the processor executing a program describing a series of processes of the mobile terminal 202 . A program describing a series of processes of the mobile terminal 202 is stored in the memory. Examples of memory are nonvolatile or volatile semiconductor memories such as RAM (Random Access Memory), ROM (Read Only Memory), flash memory, and the like.
  • the control unit 310 may be realized by a dedicated processing circuit such as FPGA (Field Programmable Gate Array), ASIC (Application Specific Integrated Circuit), DSP (Digital Signal Processor). In FIG. 8, the number of antennas used for transmission and the number of antennas used for reception by mobile terminal 202 may be the same or different.
  • FIG. 9 is a block diagram showing the configuration of base station 203 shown in FIG. Transmission processing of the base station 203 shown in FIG. 9 will be described.
  • EPC communication section 401 transmits and receives data between base station 203 and EPC (MME section 204, etc.).
  • the 5GC communication unit 412 transmits and receives data between the base station 203 and 5GC (5GC unit 214, etc.).
  • the other base station communication unit 402 transmits and receives data to and from another base station.
  • EPC communication unit 401, 5GC communication unit 412, and other base station communication unit 402 exchange information with protocol processing unit 403, respectively. Control data from protocol processing section 403 , and user data and control data from EPC communication section 401 , 5GC communication section 412 , and other base station communication section 402 are saved in transmission data buffer section 404 .
  • the data stored in the transmission data buffer unit 404 is passed to the encoder unit 405 and subjected to encoding processing such as error correction. There may be data that is directly output from transmission data buffer section 404 to modulation section 406 without being subjected to encoding processing.
  • the encoded data is subjected to modulation processing in modulation section 406 . Precoding in MIMO may be performed in modulation section 406 .
  • the modulated data is output to frequency conversion section 407 and converted into a radio transmission frequency.
  • a transmission signal is then transmitted to one or more mobile terminals 202 from antennas 408-1 to 408-4.
  • FIG. 9 illustrates the case where the number of antennas is four, but the number of antennas is not limited to four.
  • the reception processing of the base station 203 is executed as follows. Radio signals from one or more mobile terminals 202 are received by antenna 408 . The received signal is converted from a radio reception frequency to a baseband signal by frequency conversion section 407 and demodulated by demodulation section 409 . The demodulated data is passed to the decoder section 410 and subjected to decoding processing such as error correction. Of the decoded data, control data is passed to protocol processing unit 403, 5GC communication unit 412, EPC communication unit 401, or other base station communication unit 402, and user data is passed to 5GC communication unit 412, EPC communication unit 401, or other base station communication unit. It is passed to the station communication unit 402 .
  • control unit 411 A series of processes of the base station 203 are controlled by the control unit 411 . Therefore, the control unit 411 is connected to each of the units 401 to 410 and 412, though omitted in FIG. Like 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 memory, or by a dedicated processing circuit such as FPGA, ASIC, or DSP. In FIG. 9, the number of antennas used for transmission and the number of antennas used for reception by the base station 203 may be the same or different.
  • FIG. 9 is a block diagram showing the configuration of the base station 203
  • the base station 213 may also have the same configuration. 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.
  • FIG. 10 is a block diagram showing the configuration of the MME.
  • FIG. 10 shows the configuration of MME 204a included in MME section 204 shown in FIG.
  • the PDN GW communication unit 501 transmits and receives data between the MME 204a and the PDN GW (Packet Data Network Gate Way).
  • a base station communication unit 502 transmits and receives data via the S1 interface between the MME 204 a and the 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 the user plane communication unit 503 and then to one or more base stations 203 sent. When 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.
  • PDN GW Packet Data Network Gate Way
  • control data is passed from the PDN GW communication unit 501 to the control plane control unit 505.
  • control data is passed from the base station communication section 502 to the control plane control section 505 .
  • the HeNBGW communication unit 504 transmits and receives data between the MME 204a and the HeNB GW (Home-eNB Gate Way). 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 control data input from the control plane control unit 505 to the HeNB GW.
  • the control plane control unit 505 includes a NAS security unit 505-1, an SAE bearer control unit 505-2, an idle state (Idle State) mobility management unit 505-3, and the like, and a control plane (hereinafter referred to as C-Plane). in some cases).
  • the NAS security unit 505-1 performs NAS (Non-Access Stratum) message security and the like.
  • the SAE bearer control unit 505-2 manages SAE (System Architecture Evolution) bearers.
  • the idle state mobility management unit 505-3 manages mobility in the standby state (idle state: LTE-IDLE state, or simply called idle), generates and controls paging signals in the standby state, Adds, deletes, updates, searches, manages the tracking area list, etc. of the tracking areas of one or more mobile terminals 202 .
  • the MME 204a distributes paging signals to one or more base stations 203.
  • the MME 204a also performs mobility control in the idle state.
  • the MME 204a manages the tracking area list when the mobile terminal 202 is in a standby state and in an active state.
  • the MME 204a initiates the paging protocol by sending a paging message to a cell belonging to the Tracking Area in which the mobile terminal 202 is registered.
  • Management of the CSG, CSG ID, and whitelist of the eNB 207 connected to the MME 204a may be performed by the idle state mobility manager 505-3.
  • control unit 506 is connected to each of the units 501 to 505, although omitted in FIG.
  • control unit 506 is implemented by a processing circuit including a processor and memory, or by a dedicated processing circuit such as FPGA, ASIC, or DSP.
  • FIG. 11 is a block diagram showing the configuration of the 5GC section.
  • FIG. 11 shows the configuration of the 5GC section 214 shown in FIG. 3 described above.
  • FIG. 11 shows a case where the 5GC section 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 .
  • 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 is sent to one or more base stations 203 and/or transmitted to base station 213 .
  • the user data is passed from the base station communication unit 522 to the data network communication unit 521 via the user plane communication unit 523, and transferred to the data network. sent to.
  • control data When the data received from the Data Network is control data, the control data is passed from the Data Network communication section 521 to the session management section 527 via the user plane communication section 523 .
  • the session manager 527 passes control data to the control plane controller 525 . If the data received from base station 203 and/or base station 213 is control data, the control data is passed from base station communication section 522 to control plane control section 525 .
  • the control plane controller 525 passes control data to the session manager 527 .
  • the control plane control unit 525 includes a NAS security unit 525-1, a PDU session control unit 525-2, an idle state (Idle State) mobility management unit 525-3, etc., and is a control plane (hereinafter also referred to as C-Plane). existing).
  • the NAS security unit 525-1 performs NAS (Non-Access Stratum) message security and the like.
  • the PDU session control unit 525-2 manages the PDU session between the mobile terminal 202 and the 5GC unit 214, and the like.
  • the idle state mobility management unit 525-3 manages mobility in the standby state (idle state: RRC_IDLE state, or simply called idle), generates and controls paging signals in the standby state, Adds, deletes, updates, searches, manages the tracking area list, etc. of the tracking areas of one or more mobile terminals 202 .
  • control unit 526 A series of processes of the 5GC unit 214 are controlled by the control unit 526 . Therefore, the control unit 526 is connected to each of the units 521 to 523, 525 and 527, although omitted in FIG. Like the control unit 310 of the mobile terminal 202 described above, the control unit 526 is implemented by a processing circuit including a processor and memory, or by a dedicated processing circuit such as FPGA, ASIC, or DSP.
  • FIG. 12 is a flowchart showing an overview from cell search to standby operation performed by a communication terminal (UE) in an LTE communication system.
  • UE communication terminal
  • FIG. 12 is a flowchart showing an overview from cell search to standby operation performed by a communication terminal (UE) in an LTE communication system.
  • step ST601 slot timing, frame Synchronize timing.
  • a combination of P-SS and S-SS is called a Synchronization Signal (SS).
  • the synchronization signal (SS) is assigned a synchronization code corresponding to the PCI assigned to each cell on a one-to-one basis.
  • the communication terminal synchronizes using these 504 PCIs and detects (specifies) the PCI of the synchronized cell.
  • the communication terminal transmits a cell-specific reference signal (RS), which is a reference signal (RS) transmitted from the base station to each cell, for the next synchronized cell. ) and measure the RS received power (Reference Signal Received Power: RSRP).
  • RS Cell-specific reference signal
  • RSRP Reference Signal Received Power
  • a code corresponding to PCI on a one-to-one basis is used for the reference signal (RS). It can be separated from other cells by correlating with that code.
  • 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 the one or more cells detected up to step ST602. select.
  • the communication terminal receives the PBCH of the best cell and obtains BCCH, which is broadcast information.
  • MIB Master Information Block
  • DL downlink
  • dl-bandwidth transmission bandwidth configuration
  • SFN System Frame Number
  • SIB1 includes information on access to the cell, information on cell selection, and scheduling information on other SIBs (SIBk; an integer of k ⁇ 2). SIB1 also includes a tracking area code (TAC).
  • TAC tracking area code
  • step ST606 the communication terminal compares the TAC of SIB1 received in step ST605 with the TAC portion of the tracking area identifier (TAI) in the tracking area list already held by the communication terminal.
  • a tracking area list is also called a TAI list.
  • TAI is identification information for identifying a tracking area, and is composed of MCC (Mobile Country Code), MNC (Mobile Network Code), and TAC (Tracking Area Code).
  • MCC Mobile Country Code
  • MNC Mobile Network Code
  • TAC Track Area Code
  • MCC Mobile Country Code
  • MNC Mobile Network Code
  • TAC Track Area Code
  • step ST606 if the TAC received in step ST605 is the same as the TAC included in the tracking area list, the communication terminal enters standby operation in that cell.
  • the communication terminal sends a TAU (Tracking Area Update) to the core network (Core Network, EPC) including the MME etc. through the cell. Request a change of tracking area to do so.
  • TAU Track Area Update
  • the example shown in FIG. 12 shows an example of the operation from cell search to standby in the LTE system, but in the NR system, the best beam may be selected in addition to the best cell in step ST603.
  • beam information for example, a beam identifier may be obtained in step ST604.
  • scheduling information of Remaining Minimum SI (RMSI) may be acquired in step ST604.
  • the RMSI may be received in step ST605.
  • a device constituting the core network (hereinafter sometimes referred to as “core network side device") is based on the identification number (UE-ID etc.) of the communication terminal sent from the communication terminal together with the TAU request signal. Update area list.
  • the core network device 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. After that, the communication terminal enters standby operation in the cell.
  • cells configured by eNBs have relatively wide coverage.
  • cells are configured to cover an area with relatively wide coverage of multiple cells configured by multiple eNBs.
  • a cell configured by an eNB When converted to small cells, a cell configured by an eNB has a narrower coverage than the coverage of a cell configured by a conventional eNB. Therefore, as in the past, in order to cover a certain area, a large number of eNBs made into smaller cells are required compared to conventional eNBs.
  • a cell with relatively large coverage such as a cell composed of conventional eNBs
  • a macro cell such as a cell composed of conventional eNBs
  • an eNB that constitutes a macro cell will be referred to as a “macro eNB”.
  • a cell with relatively small coverage such as a cell made into a small cell
  • an eNB that constitutes the small cell is referred to as a "small eNB”.
  • a macro eNB may be, for example, a "Wide Area Base Station" described in Non-Patent Document 7.
  • a small eNB may be, for example, a low power node, a local area node, a hotspot, or the like.
  • the small eNB is a pico eNB that constitutes a pico cell, a femto eNB that constitutes a femto cell, HeNB, RRH (Remote Radio Head), RRU (Remote Radio Unit), RRE (Remote Radio Equipment) or RN (Relay Node).
  • the small eNB may be a "Local Area Base Station" or a "Home Base Station" described in Non-Patent Document 7.
  • FIG. 13 shows an example of a cell configuration in NR.
  • narrow beams are formed and transmitted in different directions.
  • base station 750 transmits and receives to and from mobile terminals using beam 751-1 at a given time. At other times, base station 750 transmits to and receives from mobile terminals using beam 751-2. Similarly, the base station 750 uses one or more of the beams 751-3 to 751-8 to transmit and receive with the mobile terminal. In this manner, base station 750 constitutes a wide-area cell.
  • FIG. 13 shows an example in which the number of beams used by the base station 750 is eight, the number of beams may be different from eight. Also, in the example shown in FIG. 13, the number of beams used simultaneously by the base station 750 is one, but a plurality of beams may be used.
  • SL Side Link
  • D2D Device to Device
  • V2V Vehicle to Vehicle
  • the Physical sidelink broadcast channel (PSBCH) carries system and synchronization related information and is transmitted from the UE.
  • the physical sidelink discovery channel (PSDCH) carries sidelink discovery messages from the UE.
  • a physical sidelink control channel (PSCCH) carries control information from the UE for sidelink communication and V2X sidelink communication.
  • the physical sidelink shared channel (PSSCH) carries data from the UE for sidelink communication and V2X sidelink communication.
  • a physical sidelink feedback channel (PSFCH) carries HARQ feedback on the sidelink from the UE that received the PSSCH transmission to the UE that transmitted the PSSCH.
  • a sidelink broadcast channel (SL-BCH: Sidelink broadcast channel) has a predetermined transport format and is mapped to a physical channel PSBCH.
  • the Sidelink Discovery Channel has periodic broadcast transmissions of fixed size and predetermined format.
  • SL-DCH also supports both UE autonomous resource selection and eNB scheduled resource allocation. There is a collision risk with UE automatic resource selection, and there is no collision when the UE is allocated dedicated resources by the eNB.
  • SL-DCH also supports HARQ combining, but not HARQ feedback.
  • SL-DCH is mapped to PSDCH, which is a physical channel.
  • a sidelink shared channel supports broadcast transmission.
  • SL-SCH supports both UE autonomous resource selection and eNB scheduled resource allocation. There is a collision risk with UE automatic resource selection, and there is no collision when the UE is allocated dedicated resources by the eNB.
  • SL-SCH also supports HARQ combining, but not HARQ feedback.
  • SL-SCH also supports dynamic link adaptation by varying transmit power, modulation and coding.
  • SL-SCH is mapped to PSSCH which is a physical channel.
  • a sidelink broadcast control channel (SBCCH: Sidelink Broadcast Control Channel) is a sidelink channel for reporting sidelink system information from one UE to another UE.
  • SBCCH is mapped to SL-BCH, which is a transport channel.
  • a sidelink traffic channel is a one-to-many sidelink traffic channel for transmitting user information from one UE to another UE.
  • STCH is only used by UEs with sidelink communication capability and UEs with V2X sidelink communication capability.
  • Point-to-point communication between UEs with two sidelink communication capabilities is also realized with STCH.
  • STCH is mapped to SL-SCH which is a transport channel.
  • a sidelink control channel is a sidelink control channel for transmitting control information from one UE to another UE.
  • SCCH is mapped to SL-SCH which is a transport channel.
  • V2X communication in NR is being studied based on the LTE system and the LTE-A system, the following changes and additions have been made from the LTE system and the LTE-A system.
  • PC5-S signaling is implemented to establish a link for implementing SL, or PC5 communication.
  • the link is implemented at the V2X layer and is also referred to as a layer 2 link.
  • RRC signaling in SL communication is also called PC5 RRC signaling.
  • PC5 RRC signaling it has been proposed to notify UE capabilities between UEs that perform PC5 communication, and to notify AS layer settings for performing V2X communication using PC5 communication.
  • PTM Point to Multipoint
  • PTP Point to Point
  • a common PDCP entity may be used in PTM and PTP.
  • PTM and PTP may have different legs (RLC, Logical Channel Combination).
  • RLC Logical Channel Combination
  • the PTM leg and the PTP leg may be used while being dynamically switched. For example, MAC signaling may be used for dynamic switching.
  • a 5G base station can support Integrated Access and Backhaul (IAB) (see Non-Patent Document 16 (TS38.300)).
  • An IAB base station has an IAB donor CU that is a CU of a base station that operates as an IAB donor that provides IAB functions, an IAB donor DU that is a DU of a base station that operates as an IAB donor, and an IAB donor DU.
  • IAB node connected using a radio interface between A plurality of IAB nodes may exist under the IAB donor CU.
  • a radio interface may be used to connect between the IAB nodes. That is, multi-stage connection of IAB nodes may be performed. Connections between IAB nodes and IAB donor CUs are made using the F1 interface (see Non-Patent Document 16 (TS38.300)).
  • a BAP (Backhaul Adaptation Protocol) layer is provided in the connection between the IAB donor DU and the IAB node and the connection between the IAB nodes.
  • the BAP layer performs operations such as routing of received data to IAB donor DUs and/or IAB nodes and mapping to RLC channels (see Non-Patent Document 36 (TS38.340)).
  • An address called a BAP address may be used in the routing.
  • a BAP address may be assigned per IAB donor DU and/or IAB node. Allocation of BAP addresses may be done by the IAB donor CU.
  • Data transmitted and received in communication using the IAB includes information on the destination IAB node, such as a BAP address.
  • the data includes information for identifying the data path, such as a path ID. Such information may be included, for example, as a BAP header.
  • the IAB donor DU and/or IAB node may use the BAP address and/or path ID to perform the aforementioned routing.
  • An IAB base station may be used in multicast communication using NR.
  • an IAB node that exists in the middle of the path from the IAB donor CU to the UE is another IAB node (hereinafter referred to as a child IAB node may be referred to as), or multicast transmission may be performed to the UE.
  • Child IAB nodes subject to multicast transmission and child IAB nodes not subject to multicast transmission may coexist.
  • Embodiment 1 discloses a method for solving such problems.
  • a plurality of destination BAP addresses may be set, and a plurality of next-hop BAP addresses (see Non-Patent Document 35 (TS38.473)) may be set.
  • Different BAP addresses may be set for different path IDs, or a plurality of different BAP addresses may be set for the same path ID.
  • the IAB donor CU may set multiple destination BAP addresses for the IAB donor DU and/or IAB node.
  • F1 signaling for example, BAP MAPPING CONFIGURATION disclosed in Non-Patent Document 35 (TS38.473) may be used, or other signaling may be used.
  • Multiple destination BAP address settings may be included as a list.
  • the BAP Routing ID which is one of the information elements in F1 signaling
  • a list of BAP addresses containing one or more BAP addresses may be provided.
  • the next-hop BAP addresses included in the F1 signaling may be configured as a list containing one or more BAP addresses. Both of the aforementioned lists may be provided.
  • An identifier representing the BAP address may be provided. For example, an identifier associated with each destination BAP address and/or next hop BAP address set from the IAB donor CU may be provided, or a plurality of destination BAP addresses and/or next hop BAP addresses may be associated. There may be provided one identifier that Similarly, identifiers representing one and/or more path IDs may be provided.
  • the identifier may be notified by the IAB donor CU to the IAB donor DU and/or the IAB node.
  • the notification of the identifier may be included in the notification of the setting of the destination BAP address and/or the next hop BAP address by the IAB donor CU to the IAB donor DU and/or the IAB node, for example, the BAP MAPPING CONFIGURATION described above.
  • the BAP header may contain the aforementioned identifier.
  • the IAB node may use the identifier to derive the destination BAP address or derive the path ID. This makes it possible, for example, to reduce the size of the BAP header and, as a result, to improve the efficiency of the communication system.
  • Including in the BAP header one identifier each corresponding to multiple destination BAP addresses and/or multiple path IDs can, for example, further reduce the size of the BAP header, thereby increasing the efficiency of the communication system. Further improvement is possible.
  • the aforementioned identifier may be uniquely given under the control of the IAB donor CU. This makes it possible, for example, to avoid complexity in the communication system.
  • the aforementioned identifier may be uniquely provided between the IAB node and/or the IAB donor DU and the child IAB node.
  • the IAB node may change the value of the identifier indicating the destination BAP address and/or the path ID included in the BAP header.
  • the IAB node may use the identifier contained in the received BAP header to derive the destination BAP address and/or path ID.
  • the IAB node may derive an identifier for communication with child IAB nodes corresponding to the derived destination BAP address and/or path ID.
  • the IAB node may replace the identifier contained in the received BAP header with the derived identifier.
  • the IAB node may send to the child IAB node using a BAP header containing the derived identifier.
  • the bit width of the identifier can be reduced, and as a result, communication efficiency can be improved.
  • FIG. 14 illustrates an example of a list of BAP addresses.
  • the BAP Routing ID information element (IE: Information Element) contains multiple BAP addresses and one path ID.
  • the plurality of BAP addresses may be destination BAP addresses.
  • the BAP Routing ID information element with the list of BAP addresses may be included in, for example, the backhaul routing information added list (BH Routing Information Added List) or the backhaul routing information removed list (BH Routing Information Removed List) or both of the above.
  • Information about changed backhaul routing information may be provided.
  • the information may be included in the aforementioned BAP MAPPING CONFIGURATION, for example.
  • One piece of information may be provided, or a plurality of pieces of information may be provided.
  • the information may be provided, for example, as a list, for example, a Backhaul Routing Information Modified List (BH Routing Information Modified List).
  • the list may include, for example, BAP addresses, path IDs, and next-hop BAP addresses.
  • the information included in the list may be changed information, for example. This makes it possible, for example, to reduce the amount of routing setting processing in the IAB node.
  • the modified BAP addresses may be included as a list of one or more BAP addresses.
  • a modified next-hop BAP address may also be included as a list.
  • the list may include information about BAP addresses to be added, information about next-hop BAP addresses to be added, and information about BAP addresses to be deleted.
  • Information about the next hop BAP address to be deleted May be included
  • Information about the path ID to be added May be included
  • Information about the path ID to be deleted may also include a plurality of the foregoing. Each of the foregoing information may be included as a list of one or more elements. This allows, for example, a reduction in the size of information relating to changes in backhaul routing information.
  • the setting may include a plurality of TNL (Transport Network Layer) addresses (see Non-Patent Document 35 (TS38.473)).
  • a 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.
  • a multicast IP address may be included in the TNL address. The inclusion of multiple TNL addresses avoids complexity in multicasting, for example, from an IAB donor CU to an IAB node that communicates directly with the UE (hereinafter sometimes referred to as an end IAB node).
  • a terminal IAB node is an IAB node connected to a UE and capable of direct communication with the UE. Multiple UEs may be connected to the terminal IAB node at the same time. In addition to the UE, other IAB nodes (equivalent to child IAB nodes of the terminal IAB node) may be connected to the terminal IAB node.
  • the setting from the IAB donor CU to the IAB donor DU is performed using, for example, information elements of traffic mapping information from IP to layer 2 (IP to layer2 Traffic Mapping Info) (see Non-Patent Document 35 (TS38.473)). may be broken.
  • the IP address included in (1) above may be a multicast IP address.
  • multicast using PTP is enabled for IAB nodes.
  • the IP address included in (2) above may be a multicast IP address.
  • multicast using PTM is enabled for IAB nodes.
  • the IP address included in (3) above may be a unicast IP address.
  • multicast using PTP is enabled for IAB nodes.
  • the IP address included in (4) above may be a unicast IP address.
  • multicast using PTM is enabled for IAB nodes.
  • a configuration from an IAB donor CU to an IAB node may contain multiple next-hop BAP addresses. Multiple pieces of information about the RLC channel identifier may be included. For example, multiple next-hop BAP address and RLC channel identifier combinations can be used to enable multicast using PTP to IAB nodes. As another example, using a combination of multiple next-hop BAP addresses and a single RLC channel identifier enables multicast using PTM to IAB nodes.
  • a BAP header may contain multiple path IDs.
  • a BAP header may contain both multiple BAP addresses and multiple path IDs. This eliminates the need to transmit the same multicast data as many times as the number of destination IAB nodes, and as a result, the Uu interface can be used efficiently.
  • a BAP header may consist of a single header, or may consist of multiple headers.
  • a 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 be of variable size.
  • the IAB node may get the basic header first. This allows, for example, an IAB node to get the header quickly.
  • the BAP header is composed of multiple headers
  • it may be composed of multiple basic headers.
  • An IAB node may obtain multiple basic headers. This makes it possible, for example, to avoid complexity in the BAP header acquisition process.
  • the BAP address included in (A) above may be, for example, the destination BAP address.
  • An IAB node may use the information in (A) above to route to one or more child IAB nodes.
  • Providing one or more BAP addresses in the BAP header, for example, allows an IAB node to quickly perform routing to multiple child IAB nodes.
  • the information regarding the number (B) above may be the number of BAP addresses contained in the BAP header, or may be a predetermined value, for example, a value obtained by subtracting 1 from the number.
  • the IAB node may use the value of (B) above to obtain information about the destination BAP address. This allows, for example, the IAB node to quickly acquire the BAP address included 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 the above (B). can get.
  • the information about the size of (C) above may be given in units of bits, may be given in units of octets, or may be given in units of multiple octets (for example, 2 octets or 3 or more octets). good too.
  • the IAB node may use the information in (C) above to obtain the BAP header. This makes it possible, for example, to prevent the IAB node from erroneously acquiring the BAP header.
  • 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.
  • An IAB node may use the information in (D) above to route to one or more child IAB nodes.
  • By providing multiple path IDs in the BAP header for example, an IAB node can quickly perform routing to multiple child IAB nodes. Also, it is possible to reduce the number of BAP-PDUs transmitted from the IAB donor DU and/or the IAB node, and as a result, it is possible to reduce the amount of processing in the IAB donor DU and/or the IAB node.
  • the aforementioned (E) may be, for example, the number of path IDs included in the BAP header, or may be a predetermined value, for example, a value obtained by subtracting 1 from the number.
  • the IAB node may use the value of (E) above to obtain information about the Path ID. This allows, for example, the IAB node to quickly acquire the path ID included 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 described in (E). be done.
  • the above (F) may be expressed as information including whether or not the BAP header has multiple BAP addresses, for example.
  • the IAB node may use the information to decide whether to continue obtaining the BAP address. This makes it possible to avoid complexity in the BAP address acquisition process, for example.
  • the above (G) may be expressed as information including whether or not the BAP header has multiple path IDs, for example.
  • the IAB node may use the information to determine whether to continue obtaining the path ID. This makes it possible to avoid complexity in the path ID acquisition process, for example.
  • the above (H) may be, for example, information indicating whether the BAP header has a subsequent header.
  • the information may be represented as yes or no information, for example.
  • the BAP header containing the information (H) may be, for example, a basic header or an extension header.
  • the headers following the basic header may be extension headers.
  • Subsequent headers of an extension header may be other extension headers.
  • the sizes of the basic header and the extension header may be the same or different.
  • the size of each header may be the same or different.
  • the IAB node may, for example, continue the BAP header acquisition process using the above information (H) as yes, or use the above information (H) as no to obtain the BAP header
  • the acquisition process may end. This avoids complexity in BAP header processing in IAB nodes, for example.
  • the information about the size of (I) above may be given in units of bits, may be given in units of octets, or may be given in units of multiple octets (for example, 2 octets, 3 octets, or 4 octets).
  • the IAB node may use the information in (I) above to obtain subsequent headers. This makes it possible, for example, to prevent erroneous acquisition of subsequent headers by an IAB node.
  • the information regarding the number of (J) above may be, for example, the number including the header, or the number of subsequent headers excluding the header.
  • the IAB node may use the information in (J) above to obtain subsequent headers. This makes it possible, for example, to prevent erroneous acquisition of subsequent headers by an IAB node.
  • the above (K) may be provided after each of one or more BAP addresses contained in the BAP header, or may be provided after each of one or more path IDs. , may be provided at the beginning and/or end of the header.
  • the aforementioned (K) may be provided, for example, so that the size of the BAP header is in units of 1 octet, may be provided in units of 2 octets, or may be in units of 3 or more octets. may be provided in This makes it possible, for example, to avoid the complexity in obtaining the BAP header.
  • the aforementioned (L) may be, for example, information indicating that the header includes one BAP address and one path ID, or may be information indicating that the header includes a plurality of combinations of BAP addresses and path IDs. information indicating that a header includes a plurality of BAP addresses and one path ID, or information indicating that a header includes a plurality of BAP addresses and a plurality of path IDs. , information indicating that only one or more BAP addresses are included, or information indicating that only one or more path IDs are included It may be information.
  • An IAB donor DU may use multiple types of BAP headers.
  • the IAB node may use the information in (L) above to determine the type of header. This allows, for example, greater flexibility in communication systems.
  • a combination of multiple types of headers may be used.
  • a combination of a header containing multiple combinations of BAP addresses and path IDs and a header containing multiple BAP addresses and one path ID may be used. This allows, for example, greater flexibility in communication systems.
  • FIG. 15 is a diagram showing an example of a BAP header.
  • FIG. 15 shows an example variable length header containing multiple BAP addresses and path IDs.
  • the number (N) of BAP addresses and path IDs is included.
  • the BAP header includes N sets of destination (DESTINATION) BAP addresses and path (PATH) IDs.
  • DESTINATION destination BAP addresses
  • PATH path IDs.
  • padding is included at the end of the BAP header.
  • the IAB node uses the value of N contained in the BAP header to obtain the combination of destination BAP address and path ID.
  • FIG. 15 shows an example in which the BAP header includes the BAP address and the number of path IDs
  • the size of the BAP header may also be included. This allows, for example, an IAB node to quickly obtain the BAP header.
  • FIG. 15 shows an example in which combinations of BAP addresses and path IDs are sequentially included, all path IDs may be included after all BAP addresses. This allows, for example, an IAB node to quickly obtain a BAP address.
  • all BAP addresses may be included after all path IDs. This allows, for example, an IAB node to quickly obtain a path ID.
  • FIG. 16 is a diagram showing another example of the BAP header.
  • FIG. 16 shows an example of a fixed length basic header and a variable length extension header containing multiple BAP addresses and path IDs.
  • the white area of the BAP header is the basic header, and the gray area is the extension header, which is the subsequent header.
  • the basic header shown in FIG. 16 contains information about the presence or absence of a subsequent header, the first destination BAP address, and the path ID.
  • the IAB node acquires the first destination BAP address and path ID from the basic header, and also acquires information (Ext.) regarding the presence or absence of the subsequent header. The IAB node uses that information to get the subsequent headers.
  • the subsequent header shown in FIG. 16 contains the number (N) of combinations of the destination BAP address and the path ID, and the combinations of the second and subsequent destination BAP addresses and the path ID. Also, at the end of the subsequent header, padding is included to make the subsequent header into units of octets.
  • the value of N included in the subsequent header may exclude or include the destination BAP address and path ID included in the basic BAP header.
  • the IAB node may use the aforementioned value of N to keep track of the number of destination BAP addresses and path IDs contained in subsequent headers, and may keep track of the size of subsequent headers.
  • the size of the basic header can be fixed, so that the basic header can be obtained quickly.
  • FIG. 16 shows an example in which the BAP header includes the number of BAP addresses and path IDs
  • the size of the BAP header may also be included. This allows, for example, an IAB node to quickly obtain the BAP header.
  • extension header in FIG. 16 shows an example in which combinations of BAP addresses and path IDs are sequentially included, all path IDs may be included after all BAP addresses. This allows, for example, an IAB node to quickly obtain a BAP address.
  • all BAP addresses may be included after all path IDs. This allows, for example, an IAB node to quickly obtain a path ID.
  • FIG. 17 is a diagram showing another example of the BAP header.
  • FIG. 17 illustrates an example fixed length base header and one or more fixed length extension headers.
  • the white area of the BAP header is the basic header, and the gray area is the extension header.
  • the basic header shown in FIG. 17 is the same as that in FIG. 16, so the explanation is omitted.
  • Each of the multiple extension headers shown in FIG. 17 contains information on the presence or absence of a subsequent header and a combination of the destination BAP address and the path ID.
  • the IAB node acquires the destination BAP address and path ID from the extension header, and also acquires information regarding the presence or absence of a subsequent header.
  • the IAB node uses that information to get the subsequent headers.
  • the configuration of the extension header may be the same as that of the basic header. This makes it possible to reduce the amount of processing involved in acquiring and/or processing extension headers, for example.
  • the last extension header shown in FIG. 17 contains information on the presence or absence of a subsequent header and a combination of the destination BAP address and the path ID.
  • the IAB node acquires the destination BAP address and path ID from the extension header, and also acquires information regarding the presence or absence of a subsequent header.
  • the IAB node uses the fact that the information contained in the last extension header is non-existent to stop getting subsequent headers.
  • extension header in FIG. 17 includes information (D/C) indicating whether it is a data PDU or a control PDU, the information may not be included. Instead of this information, reserved bits may be included. As a result, future expandability can be improved, for example.
  • D/C information indicating whether it is a data PDU or a control PDU
  • the D/C may be included in the extension header. This avoids the complexity associated with the header generation process in, for example, the IAB donor DU. An IAB node may ignore the D/C included in the extension header. As a result, for example, the header acquisition process in the IAB node can be executed quickly.
  • the same path ID may be set for multiple BAP addresses. As a result, for example, the size of the BAP header can be reduced, and the number of path IDs used in the IAB base station can be reduced.
  • FIG. 18 is a diagram showing another example of the BAP header.
  • FIG. 18 shows an example variable length header containing multiple BAP addresses and one path ID.
  • the BAP header shown in FIG. 18 includes the number (N) of destination BAP addresses.
  • N the number of destination BAP addresses.
  • padding is included to make the BAP header octet unit.
  • the IAB node uses the value of N contained in the BAP header to obtain one or more destination BAP addresses and a path ID.
  • FIG. 18 shows an example in which the number of destination BAP addresses is included in the BAP header
  • the size of the BAP header may also be included. This allows, for example, an IAB node to quickly obtain the BAP header.
  • FIG. 18 shows the case where the second and subsequent BAP addresses are included after the path ID
  • the path ID may be included after the last BAP address. This can avoid complexity in implementing BAP header processing, for example.
  • FIG. 19 is a diagram showing another example of the BAP header.
  • FIG. 19 shows an example of a fixed-length basic header and a variable-length extension header containing multiple BAP addresses and one path ID.
  • the white area of the BAP header is the basic header, and the gray area is the extension header.
  • the basic header shown in FIG. 19 contains information regarding the presence or absence of a subsequent header, and 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 obtains information regarding the presence or absence of subsequent headers.
  • the IAB node uses that information to get the subsequent headers.
  • the subsequent header shown in FIG. 19 contains the number (N) of destination BAP addresses and the second and subsequent destination BAP addresses. Also, at the end of the subsequent header, padding is included to make the subsequent header into units of octets.
  • 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 value of N above to keep track of the number of destination BAP addresses contained in the subsequent header, and may keep track of the size of the subsequent header.
  • FIG. 20 is a diagram showing another example of the BAP header.
  • FIG. 20 illustrates an example fixed length base header and one or more fixed length extension headers.
  • the white area of the BAP header is the basic header, and the gray area is the extension header.
  • the basic header shown in FIG. 20 is the same as that shown in FIG. 19, so the explanation is omitted.
  • the extension header shown in FIG. 20 contains information on the presence or absence of a subsequent header and the destination BAP address.
  • the IAB node acquires the destination BAP address from the extension header and also acquires information regarding the presence or absence of the subsequent header.
  • the IAB node uses that information to get the subsequent headers.
  • the last extension header shown in FIG. 20 contains information on the presence or absence of a subsequent header and the destination BAP address.
  • the IAB node acquires the destination BAP address from the extension header and also acquires information regarding the presence or absence of the subsequent header.
  • the IAB node uses the fact that the information contained in the last extension header is non-existent to stop getting subsequent headers.
  • the example shown in FIG. 20 shows the case where the size of the extension header is 2 octets, it may be 3 octets, which is the same as the basic header. For example, 10 bits after the destination BAP address in the extension header may be padding. This allows, for example, avoiding the complexity associated with the BAP header retrieval process in the IAB node.
  • An IAB node may modify the BAP header.
  • the IAB node may, for example, remove some information contained in the BAP header.
  • the part of the information may be, for example, a BAP address not set in the self node, a path ID not set in the self node, or a combination of the above. This makes it possible, for example, to reduce the size of the BAP header.
  • Deletion of the BAP header may be performed in the BAP layer that performs transmission processing, or may be performed in the BAP layer that performs reception processing.
  • grouping of IAB nodes may be performed.
  • a BAP address may be used for the grouping.
  • a multicast BAP address may be provided.
  • An IAB donor CU may assign the BAP address to an IAB node.
  • IAB donor DUs and/or IAB nodes may use multicast BAP addresses to multicast transmissions to child IAB nodes. This allows, for example, multicast transmissions to be performed quickly.
  • a multicast BAP address may be provided for each multicast service or content.
  • each device in the communication system can quickly recognize services or contents related to multicast.
  • the multicast BAP address may be provided within a predetermined range of possible values for the BAP address. For example, a range of BAP addresses whose leading 4 bits are all '1' may be provided as BAP addresses for multicast. As a result, for example, each device in the communication system can quickly recognize whether the BAP address is for multicast.
  • the IAB donor CU may use F1 signaling to configure the IAB donor DU and/or the IAB node, for example, configure routing.
  • the F1 signaling may be, for example, BAP MAPPING CONFIGURATION signaling (see Non-Patent Document 35 (TS38.473)) or other signaling.
  • the settings may include information about BAP layer routing.
  • An IAB donor CU may include this information in the configuration.
  • the configuration may be performed for each of the PTM leg and the PTP leg.
  • Information about routing in the BAP layer may include information that identifies routing, e.g., routing identifiers, and BAP addresses of IAB donor DUs and/or IAB nodes (see Non-Patent Document 35 (TS38.473) ), information about the BAP address of the next hop destination, e.g. Information may be included, information about the path from the IAB donor CU to the UE, eg information about the identifier of the path. This allows, for example, IAB donor DUs and/or IAB nodes to facilitate routing of multicast data to UEs.
  • This setting may include multiple pieces of information related to BAP layer routing. For example, information regarding routing for transmissions using PTM legs and information regarding routing for transmissions using PTP legs may be included. Multiple pieces of information relating to routing in transmissions using PTP legs may be included, and multiple pieces of information relating to routing in transmissions using PTM legs may be included.
  • the IAB node may switch routing destinations using information contained in the BAP header, eg, DESTINATION and/or path ID information. This allows, for example, dynamic change of routing destinations in IAB nodes.
  • the settings may include information about areas where multicast can be transmitted.
  • the IAB node may use the information to control beams and/or transmit power such that the transmission range of multicast data is within the area. This makes it possible, for example, to prevent the multicast data from being transmitted outside the transmittable area.
  • Information about the transmission method may be included in the settings.
  • the information may include information indicating use of the PTM leg, or may include information indicating use of the PTP leg.
  • the information may be provided per destination child IAB node and/or UE.
  • the IAB donor DU and/or IAB node may use the information to determine which leg to use for transmission to the child IAB node and/or UE. This allows, for example, an IAB donor DU and/or an IAB node to quickly determine which leg to use for the transmission.
  • a predetermined mode may be provided for the transmission method from the IAB donor DU and/or IAB node to the child IAB node and/or UE.
  • both the child IAB node and the UE may have a mode of transmission using the PTM leg, or there may be a mode of transmission using the PTM leg for the UE and the PTP leg for the child IAB node.
  • the mode may be configurable per child IAB node and/or UE.
  • the mode may be determined by the IAB donor CU and communicated to the IAB donor DU and/or IAB node.
  • the mode may be included in the settings described above.
  • the IAB donor DU and/or IAB node may use the information about the mode to decide which leg to use for transmission to the child IAB node and/or UE. This enables, for example, the IAB donor DU and/or the IAB node to quickly determine the leg to use for the transmission, thereby reducing the amount of processing in the transmission process from the IAB donor DU and/or the IAB node. Become.
  • multicast data received using the PTM leg may be sent using the PTP leg, and multicast data received using the PTP leg may be sent using the PTM leg.
  • multicast data received using the PTM leg may be sent using the PTM leg, and multicast data received using the PTP leg may be sent using the PTP leg. This allows, for example, greater flexibility in communication systems.
  • BAP layer routing may be determined using information about areas where multicast can be sent. For example, the IAB node that routes the multicast may be determined from among the IAB nodes whose transmission range is included in the area. This makes it possible, for example, to prevent the multicast data from being transmitted outside the transmittable area.
  • the core NW device may determine information on areas where multicast can be transmitted.
  • the core NW device may notify the information to the IAB donor CU.
  • the core NW device may notify the IAB donor CU of information on the IAB nodes belonging to the area.
  • the IAB donor CU may use the above information to determine the IAB node to route to. This allows, for example, an IAB donor CU to appropriately select an IAB node within an area where multicast can be transmitted.
  • An IAB donor DU and/or an IAB node may decide which identifiers to assign to child IAB nodes and/or UEs.
  • the identifier may be, for example, G-RNTI and/or SC-RNTI (see Non-Patent Document 34 (TS36.321)) or C-RNTI.
  • the IAB donor DU and/or IAB node may notify the IAB donor CU of the identifier.
  • the notification may be performed using F1 signaling, for example, UL RRC MESSAGE TRANSFER (see Non-Patent Document 35 (TS38.473)) signaling.
  • a correspondence may be made between the multicast BAP address and the G-RNTI and/or SC-RNTI described above.
  • the IAB donor CU may use the aforementioned G-RNTI and/or SC-RNTI to determine the BAP address for multicast.
  • the IAB donor DU and/or the IAB node assigns the transmission destination of the data whose next hop destination BAP address is the multicast BAP address to the above-mentioned G-RNTI child IAB node and/or UE may be This can, for example, improve the efficiency of the communication system.
  • One or more BAP addresses may be assigned to the same IAB node.
  • a BAP address for multicast may be included in the BAP address assigned to the IAB node.
  • the IAB donor CU may set multiple BAP addresses for the IAB node.
  • RRC signaling for example, signaling of RRC reconfiguration (RRCReconfiguration) may be used.
  • multiple BAP addresses may be settable in an information element of BAP configuration (bap-config) included in RRC reconfiguration signaling.
  • the configuration from an IAB donor CU to an IAB node may be done via the IAB node's parent IAB node.
  • a parent IAB node is an IAB node to which the IAB node is connected.
  • the IAB donor CU may send RRC signaling to the parent IAB node informing the IAB node. For this transmission, for example, DL RRC MESSAGE TRANSFER signaling may be used.
  • a parent IAB node may use the signaling to obtain signaling to send to the IAB node.
  • a parent IAB node may use the signaling to obtain information to be configured in the IAB node, eg, a BAP address assigned to the IAB node. This enables, for example, the parent IAB node to grasp the multicast BAP address assigned to the IAB node.
  • the IAB donor CU may notify the IAB node of information on the IAB nodes existing under the IAB node.
  • the notification may be performed using F1 signaling, eg, BAP MAPPING CONFIGURATION signaling, or may be performed using RRC signaling, eg, RRC reconfiguration signaling.
  • the information may include, for example, information about one or more BAP addresses assigned to subordinate IAB nodes. As a result, for example, an IAB node can obtain information on the BAP address assigned to the IAB node under its control, and as a result, the routing process can be executed smoothly.
  • This information may include information about the hierarchy of IAB nodes under it.
  • the hierarchy may be, for example, a hierarchy based on the self IAB node, a hierarchy based on the IAB donor CU, or a hierarchy based on the IAB donor DU.
  • Another example of the information about the hierarchy may be a hierarchy based on the UE.
  • Information identifying the reference UE eg, a UE identifier, may be included.
  • the IAB node may use this information to schedule child IAB nodes and/or UEs. This makes it possible, for example, to reduce delays in multicast.
  • the information about the hierarchy may include information about the device (eg, IAB donor CU, IAB donor DU, UE) that is the basis of the hierarchy.
  • the IAB node may use this information to obtain information about the device that the hierarchy references. As a result, for example, it is possible to reduce the probability of malfunction related to multicast transmission processing.
  • TNL addresses may be assigned to the same IAB node. Allocation of TNL addresses may be done for terminal IAB nodes, for example.
  • a 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.
  • a multicast BAP address may be used as the destination BAP address. This makes it possible, for example, to reduce the size of the BAP header.
  • a multicast BAP address may be used as the next-hop BAP address. This can, for example, reduce the size of routing setup signaling from the CU to the IAB node.
  • a unicast BAP address that is, a normal BAP address may be used.
  • a unicast BAP address may be used in transmitting multicast data to an IAB node to which a multicast BAP address is not assigned, or a unicast BAP address may be used in transmitting multicast data to an IAB node to which a multicast BAP address is assigned.
  • a cast BAP address may be used. This can, for example, increase the flexibility of the communication system.
  • Figures 21 and 22 are multicast setting sequences in the IAB base station.
  • FIG. 21 shows the first half of the sequence
  • FIG. 22 shows the second half of the sequence. That is, in multicast setting in the IAB base station, steps ST1510 to ST1528 shown in FIG. 21 are executed first, and then steps ST1532 to ST1594 shown in FIG. 22 are executed.
  • the UE is connected to the IAB donor CU via IAB node #2, IAB node #1 and IAB donor DU.
  • FIGS. 21 and 22 it is assumed that the UE has obtained information on multicast in advance.
  • the UE makes a PDU session modification request to the AMF.
  • the request may be made using NAS signaling.
  • the request may contain information about the multicasts that the UE wishes to receive.
  • the AMF notifies the SMF of the PDU session change request.
  • the notification may be performed using, for example, the Nsmf_PDUSession_UpdateSMContext service operation (see Non-Patent Document 37 (TS23.502)).
  • the notification may contain information about the multicasts that the UE wishes to receive.
  • the SMF checks whether the UE can receive the multicast.
  • step ST1516 the SMF queries the Unified Data Repository (UDR) (see Non-Patent Document 21 (TS23.501)) for information on the multicast and acquires the information from the UDR.
  • UDR Unified Data Repository
  • step ST1518 the SMF requests multicast/broadcast SMF (MB-SMF) (see Non-Patent Document 28 (TR23.757)) for information on multicast QoS.
  • step ST1520 MB-SMF notifies SMF of the response to the request.
  • the response may include information about multicast QoS.
  • 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 (TS23.502)).
  • the request may include a request for multicast context creation in the base station.
  • AMF requests the IAB donor CU to change the PDU session.
  • PDU Session Resource Modify Request signaling see Non-Patent Document 38 (TS38.413)
  • Information about the multicast session may be included in the request.
  • the IAB donor CU may use the information to obtain information about the multicast session.
  • the IAB donor CU notifies the IAB node #2 of the PDU session change request.
  • Information about the multicast session may be included in the request.
  • the notification may be made via the IAB donor DU, IAB node #1.
  • the notification may be made using F1 signaling, eg, DL RRC MESSAGE TRANSFER.
  • the IAB node #2 notifies the UE of the PDU session change request.
  • the UE may acquire information on the multicast session using the information in step ST1528.
  • the UE may change the PDU session information.
  • steps ST1532 to ST1562 shown in FIG. 22 settings regarding multicast transmission are performed between the IAB base station and the UE.
  • the IAB donor CU sets information regarding routing to the IAB donor DU.
  • the IAB donor CU may determine the information necessary for the 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 IAB node used for multicast PDU session and routing.
  • Information about routing may include information about the BAP address of the IAB donor DU, information about the route, e.g. Information about the address may be included, and information about the identifier of the RLC channel to use may be included.
  • 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 given as a multicast IP address.
  • F1 signaling for example, BAP MAPPING CONFIGURATION signaling may be used.
  • Multiple BAP addresses may be given in the signaling.
  • multiple BAP addresses may be included in the information element (IE) of the BAP Routing ID included in the signaling.
  • the IAB node's BAP address may be included in the plurality of BAP addresses.
  • Multiple TNL addresses may be provided in the signaling.
  • step ST1534 the IAB donor DU notifies the IAB donor CU of a response to step ST1532.
  • an acknowledgment is signaled.
  • F1 signaling for example, BAP MAPPING CONFIGURATION ACKNOWLEDGEMENT signaling may be used.
  • step ST1536 the IAB donor DU notifies the IAB donor CU of the identifier to be assigned to the child IAB node, IAB node #1 in the example shown in FIG.
  • the identifier may be a C-RNTI, a G-RNTI, an SC-RNTI, or any combination of the foregoing.
  • the notification may include information about the RRC settings that the IAB donor DU uses for communication with IAB node #1.
  • the IAB donor DU may notify step ST1536 with the reception of step ST1532 as a trigger.
  • the notification may use F1 signaling, eg, UL RRC MESSAGE TRANSFER.
  • the IAB donor CU notifies the IAB donor DU of the RRC settings used for multicast communication with IAB node #1.
  • the notification may use F1 signaling, for example, DL RRC MESSAGE TRANSFER signaling.
  • the IAB donor DU configures the multicast for the IAB node #1.
  • the settings may include settings related to the PTM leg, and may include settings related to the PTP leg. For example, RRC reconfiguration signaling may be used for the configuration.
  • Step ST1540 may include information about the identifier of the IAB node #1, such as C-RNTI, G-RNTI, and/or SC-RNTI, or information about the BAP address, Information about RLC settings may be included, information about MAC settings may be included, information about PHY settings may be included, information about logical channels, for example, used to identify logical channels Information may be included.
  • the BAP address may include information about the BAP address of IAB node #1, or may include information about the BAP address of the next hop destination, for example, IAB node #2, or multicast data.
  • Information about the BAP address of the IAB node that is directly connected to the receiving UE eg, information about the BAP address of IAB node #2, may be included.
  • Multiple BAP addresses may be included as the BAP address of the IAB node #1, multiple BAP addresses may be included as the BAP address of the next hop destination, and direct communication with the UE that receives the multicast data
  • Multiple BAP addresses may be included as the BAP addresses of the IAB nodes to be connected.
  • the BAP address described above may include a multicast BAP address.
  • the above information may be included as information for each of the PTM and PTP legs.
  • the IAB node #1 notifies the IAB donor DU of the completion of setting regarding multicast. For the notification, for example, RRC reconfiguration complete (RRCReconfigurationComplete) signaling may be used.
  • the IAB donor DU notifies the IAB donor CU of information regarding the completion of RRC reconfiguration of IAB node #1.
  • the notification may use F1 signaling, for example, UL RRC MESSAGE TRANSFER signaling.
  • the IAB donor CU may recognize that the multicast setting for IAB node #1 has been completed.
  • the IAB donor CU sets information on routing for IAB node #1.
  • the routing information may include information about the BAP address of the IAB node #1, information about the route, for example, information about the IAB node directly connected to the UE, or information about the next hop destination.
  • Information about the BAP address may be included, and information about the identifier of the RLC channel to use may be included.
  • the BAP address may be a multicast BAP address.
  • F1 signaling for example, BAP MAPPING CONFIGURATION signaling may be used. Multiple BAP addresses may be given in the signaling.
  • multiple BAP addresses may be included in the information element (IE) of the BAP Routing ID included in the signaling.
  • the IAB node's BAP address may be included in the plurality of BAP addresses.
  • IAB node #1 notifies the response to step ST1544 to the IAB donor CU. In the example shown in Figure 22, an acknowledgment is signaled.
  • F1 signaling for example, BAP MAPPING CONFIGURATION ACKNOWLEDGEMENT signaling may be used.
  • the IAB node #1 notifies the IAB donor CU of the identifier to be assigned to the child IAB node, which is the IAB donor #2 in the example shown in FIG.
  • the identifier may be a C-RNTI, a G-RNTI, an SC-RNTI, or any combination of the foregoing.
  • the notification may include information about the RRC settings that the IAB node #1 uses for communication with the IAB node #2.
  • IAB node # 1 triggered by the reception of step ST1540, may perform the notification of step ST1548, triggered by the reception of step ST1544, may perform the notification of step ST1548, step ST1540 and step ST1544.
  • the notification of step ST1548 may be performed with the reception of both as a trigger.
  • the notification may use F1 signaling, eg, UL RRC MESSAGE TRANSFER.
  • the IAB donor CU notifies the IAB node #1 of the RRC settings used for multicast communication with the IAB node #2.
  • the notification may use F1 signaling, for example, DL RRC MESSAGE TRANSFER signaling.
  • the IAB node #1 configures the multicast for the IAB node #2.
  • the settings may include settings related to the PTM leg, and may include settings related to the PTP leg. For example, RRC reconfiguration signaling may be used for the configuration.
  • Step ST1552 may include information about the identifier of the IAB node #2, such as C-RNTI, G-RNTI, and/or SC-RNTI, or information about the BAP address, Information about RLC settings may be included, information about MAC settings may be included, information about PHY settings may be included, information about logical channels, for example, used to identify logical channels Information may be included.
  • the BAP address may include information about the BAP address of IAB node #2, may include information about the BAP address of the next hop destination, or may be directly connected to the UE that receives the multicast data. Information about the BAP address of the IAB node may be included.
  • Multiple BAP addresses may be included as the BAP address of the IAB node #2, multiple BAP addresses may be included as the BAP address of the next hop destination, and direct communication with the UE that receives the multicast data
  • Multiple BAP addresses may be included as the BAP addresses of the IAB nodes to be connected.
  • the BAP address described above may include a multicast BAP address.
  • the above information may be included as information for each of the PTM and PTP legs.
  • the IAB node #2 notifies the IAB node #1 of the completion of setting regarding multicast.
  • RRC reconfiguration completion signaling may be used.
  • the IAB node #1 notifies the IAB donor CU of information regarding the completion of RRC reconfiguration of the IAB node #2.
  • the notification may use F1 signaling, for example, UL RRC MESSAGE TRANSFER signaling.
  • the IAB donor CU may recognize that the multicast setting for IAB node #2 has been completed.
  • the IAB donor CU sets information regarding routing to IAB node #2.
  • the information about routing may include information about the BAP address of IAB node #2, or information about routes, for example, information indicating that IAB node #2 is a terminal IAB node. , may include information about the identifier of the RLC channel to use.
  • the BAP address may be a multicast BAP address.
  • F1 signaling for example, BAP MAPPING CONFIGURATION signaling may be used.
  • Multiple BAP addresses may be given in the signaling.
  • multiple BAP addresses may be included in the information element (IE) of the BAP Routing ID included in the signaling.
  • IE information element
  • the IAB node's BAP address may be included in the plurality of BAP addresses.
  • IAB node #2 notifies the response to step ST1555A to the IAB donor CU.
  • an acknowledgment is signaled.
  • F1 signaling for example, BAP MAPPING CONFIGURATION ACKNOWLEDGEMENT signaling may be used.
  • 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 any combination of the foregoing.
  • the notification may include information about the RRC configuration that IAB node #2 uses for communication with the UE.
  • IAB node #2 may notify step ST1556 with the reception of step ST1554 as a trigger.
  • the notification may use F1 signaling, eg, UL RRC MESSAGE TRANSFER.
  • the IAB donor CU notifies the IAB node #2 of the RRC settings used for multicast communication with the UE.
  • the notification may use F1 signaling, for example, DL RRC MESSAGE TRANSFER signaling.
  • IAB node #2 configures multicast for the UE.
  • the settings may include settings related to the PTM leg, and may include settings related to the PTP leg.
  • RRC reconfiguration signaling may be used for the configuration.
  • Step ST1560 may include information about the identifier of the UE, for example, C-RNTI, G-RNTI, and/or SC-RNTI, may include information about RLC settings, or may include information about MAC settings.
  • the UE notifies the IAB node #2 of the completion of setting regarding multicast.
  • the notification for example, RRC reconfiguration completion signaling may be used.
  • the IAB node #2 notifies the IAB donor CU of the information on the RRC reconfiguration completion of the UE.
  • the notification may use F1 signaling, for example, UL RRC MESSAGE TRANSFER signaling.
  • the IAB donor CU may recognize that the multicast setting for the UE has been completed, triggered by step ST1563.
  • the IAB donor CU requests the AMF for multicast distribution.
  • the request may include information identifying the UE, and may include information identifying the multicast.
  • AMF requests multicast distribution from MB-SMF.
  • session information related to multicast distribution is modified between MB-SMF and multicast/broadcast UPF (MB-UPF) (see Non-Patent Document 28 (TR23.757)).
  • MB-UPF multicast/broadcast UPF
  • MB-UPF multicast/broadcast UPF
  • step ST1578 MB-SMF notifies AMF of a response to the multicast distribution request.
  • the AMF notifies the IAB donor CU of the response to the multicast distribution request.
  • 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.
  • step ST1584 AMF notifies SMF of a response to the change of session information.
  • the processing of Nsmf_PDUSession_UpdateSMContext may be used.
  • the MB-UPF transmits multicast data to the IAB donor CUs.
  • the IAB donor CU transfers the data to the IAB donor DU.
  • the IAB donor DU transfers the data to IAB node #1.
  • IAB node #1 transfers the data to IAB node #2.
  • IAB node #2 forwards the data to the UE.
  • the PTP leg may be used, the PTM leg may be used, or both of the above may be used.
  • IAB donor CU-CP IAB donor CU
  • IAB donor CU-UP IAB donor CU-UP
  • An IAB donor DU and/IAB node for the C-plane may be provided, and an IAB donor DU and/or IAB node for the U-plane may be provided.
  • An IAB donor DU and/or an IAB node may be connected to either an IAB donor CU-CP or an IAB donor CU-UP. This allows, for example, greater flexibility in communication systems.
  • the IAB donor CU-CP may inform the IAB donor CU-UP of information about the IAB donor DU that sends data. Information about the end IAB node may be included in the notification.
  • the notification may be done using signaling (eg, E1 signaling) between the CU-CP and CU-UP.
  • the IAB donor CU-UP may use the notification to perform routing to the destination IAB donor DU of the data, and may transmit the data to the IAB donor DU. This makes it possible, for example, to prevent malfunctions related to data transmission from the IAB donor CU-UP to the IAB donor DU.
  • An IAB donor DU and/IAB node for the C-plane may be provided, and an IAB donor DU and/or IAB node for the U-plane may be provided.
  • An IAB donor DU and/or an IAB node may be connected to either an IAB donor CU-CP or an IAB donor CU-UP. This allows, for example, greater flexibility in communication systems.
  • the IAB donor CU may replace the IAB donor CU-CP for signaling transmitted and received between the IAB donor CU and the IAB donor DU and/or IAB node.
  • the IAB donor CU may replace the IAB donor CU-CP for signaling sent and received between the IAB donor CU and the UE. This makes it possible, for example, to avoid complexity in the communication system.
  • the setting sequences shown in FIGS. 21 and 22 may be used to change multicast routes.
  • the change of the route for example, may be performed in the addition and / or deletion of the UE that receives the multicast, may be performed when the communication path between the IAB nodes is blocked by an obstacle or the like, It may occur when the communication path is restored from the occlusion. This allows, for example, rerouting in multicast using IAB nodes, thus allowing greater flexibility in the communication system.
  • the BAP address of the IAB node related to the change may be included in the backhaul routing information added list (BH Routing Information Added List), or the backhaul routing information removed list (BH Routing Information Removed List) ), may be included as a backhaul routing information modified list (BH Routing Information Modified List), or may be included in a plurality of the above. For example, by being included in the backhaul routing information change list, it is possible to reduce the amount of F1 signaling related to multicast route change.
  • a multicast BAP address may be used for setting from the IAB donor CU to the IAB donor DU. For example, even if a BAP address for multicast is included in the BAP address included in the information element of traffic mapping information from IP to layer 2 (IP to layer2 Traffic Mapping Info) (see Non-Patent Document 35 (TS38.473)) good.
  • the IP address included in (a) above may be a multicast IP address.
  • the BAP address and/or the next hop BAP address included in (a) above may include a multicast BAP address.
  • multicast using PTP is enabled for IAB nodes.
  • the IP address included in (b) above may be a multicast IP address.
  • the BAP address and/or the next hop BAP address included in (b) above may include a multicast BAP address.
  • multicast using PTM is enabled for IAB nodes.
  • the IP address included in (c) above may be a unicast IP address.
  • the BAP address and/or the next hop BAP address included in (c) above may include a multicast BAP address.
  • multicast using PTP is enabled for IAB nodes.
  • the IP address included in (d) above may be a unicast IP address.
  • the BAP address and/or the next hop BAP address included in (d) above may include a multicast BAP address.
  • multicast using PTM is enabled for IAB nodes.
  • the setting from the IAB donor CU to the IAB node may include the multicast BAP address.
  • the multicast BAP address may be included as, for example, the next hop BAP address.
  • using single or multiple next-hop BAP addresses and multiple RLC channel identifiers allows multicast using PTP to IAB nodes.
  • a combination of single or multiple next-hop BAP addresses and a single RLC channel identifier can be used to enable multicast using PTM to IAB nodes.
  • a multicast BAP address may be assigned to the terminal IAB node.
  • Terminal IAB nodes to which multicast BAP addresses are assigned may include terminal IAB nodes to which child IAB nodes connect. This allows multicast transmission to many IAB nodes, for example.
  • the terminal IAB node may be the only terminal IAB node that does not connect to child IAB nodes. This makes it possible, for example, to avoid processing complexity in the BAP layer of terminal IAB nodes.
  • FIG. 23 is a diagram showing an example of multicast BAP address allocation in an IAB base station.
  • FIG. 23 shows an example in which a terminal IAB node serving as a parent IAB node to which a child IAB node connects is also assigned a multicast BAP address.
  • UE #1 to #6 are UEs receiving multicast
  • IAB nodes #2 to #5 without hatching are IAB nodes to which multicast BAP addresses are assigned
  • IAB node #1 with hatching is a multicast BAP address. indicates an IAB node that is not assigned.
  • IAB nodes #2 to #5 are terminal IAB nodes connected to UEs that receive multicast. Therefore, multicast BAP addresses are assigned to IAB nodes #2 to #5. That is, the IAB node #3, which is the parent IAB node of the IAB node #5, is also assigned a multicast BAP address. In the example shown in FIG. 23, the IAB node #3 is connected to the UE #2 and the IAB node #5 as a child IAB node. In this connection configuration, IAB node #3 is a terminal IAB node for UE#2 and a parent IAB node for IAB node #5.
  • FIG. 24 is a diagram showing another example of multicast BAP address allocation in the IAB base station.
  • FIG. 24 shows an example in which multicast BAP addresses are assigned only to terminal IAB nodes to which child IAB nodes are not connected.
  • UE #1 to #6 are UEs that receive multicast
  • IAB nodes #2, #4, and #5 without hatching are IAB nodes to which multicast BAP addresses are assigned
  • hatched IAB nodes #1 and # 3 indicates an IAB node to which no multicast BAP address is assigned.
  • 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, no multicast BAP address is assigned to IAB node #3, and multicast BAP addresses are assigned to IAB nodes #2, #4, and #5. That is, in the example shown in FIG. 24, a multicast BAP address is assigned to an IAB node to which a UE is connected and to which no other IAB node (child IAB node) is connected.
  • each parent IAB node may be assigned to a child IAB node. This allows, for example, setting the next-hop BAP address from the IAB donor CU to the parent IAB node using fewer BAP addresses, thus reducing the size of the F1 signaling between the IAB donor CU and the parent IAB node. can be reduced.
  • FIG. 25 is a diagram showing an example of multicast BAP address allocation in an IAB base station.
  • FIG. 25 shows an example in which the same multicast BAP address is assigned to child IAB nodes connected to the same parent IAB node.
  • UEs #1 to #7 are UEs receiving multicast
  • IAB node #7 hatched with dots indicates an IAB node to which no multicast BAP address is assigned.
  • IAB nodes hatched with ascending lines, hatching with descending lines, and hatching with narrow ascending lines indicate IAB nodes to which different multicast BAP addresses are assigned.
  • the same multicast BAP address is assigned to the IAB nodes with the same pattern of hatching.
  • the same BAP address may be assigned between multicast contents.
  • the number of BAP addresses used for multicasting can be reduced, and as a result, the number of IAB nodes accommodated in the communication system can be increased.
  • a different RLC channel may be used for each multicast content.
  • the use of different RLC channels may be done, for example, when the same BAP address is assigned between multicast contents. This makes it possible to identify multicast content while reducing the number of BAP addresses used for multicast, for example.
  • the same path ID may be used between multicast contents.
  • the number of path IDs used for multicasting can be reduced, and as a result, the number of IAB nodes accommodated in the communication system can be increased.
  • a different RLC channel may be used for each multicast content.
  • the use of different RLC channels may be done, for example, when the same path ID is assigned between multicast contents. This makes it possible to identify multicast content while reducing the number of path IDs used for multicast, for example.
  • Different multicast BAP addresses may be assigned to child IAB nodes connected to different parent IAB nodes. As a result, for example, it is possible to quickly determine an IAB node for multicast transmission in a communication system.
  • 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 the next hop BAP address.
  • the value of the next-hop BAP address may be determined by standards. This eliminates, for example, setting a multicast BAP address as the next hop BAP address from the IAB donor CU to the IAB donor DU and/or the IAB node, thereby reducing the size in F1 signaling.
  • each IAB node may be assigned to each bit of the BAP address.
  • the IAB donor CU may inform the IAB node of information about the bit position of the BAP address to assign to the IAB node.
  • An IAB node may use this information to recognize the bit positions assigned to it.
  • the IAB node may use the value of the bit in the BAP address included in the BAP header to determine whether the IAB node itself is included in the destination. This allows, for example, an IAB node to quickly determine whether the destination includes its own IAB node.
  • FIG. 26 is a diagram showing another example of multicast BAP address allocation in the IAB base station.
  • FIG. 26 shows an example in which UE #1 and #4 to #7 without hatching are UEs that receive multicast, and UE #2 and #3 with hatching are UEs that do not receive multicast.
  • multicast BAP addresses are assigned to terminal IAB nodes that connect to UEs that receive multicast.
  • hatched IAB nodes #1 to #3 and #5 are IAB nodes to which multicast BAP addresses are not assigned, and unhatched IAB nodes #4, #6 and #7 are assigned multicast BAP addresses. indicates an IAB node that is
  • FIG. 27 is a diagram showing a bitmap of multicast BAP addresses assigned in FIG.
  • bit 0 (LSB) is assigned to the IAB donor DU and bits 1-7 are assigned to IAB nodes #1-#7, respectively.
  • Bits 8 and 9 are empty bits. The bit may be a reserved bit. As a result, future expandability can be improved, for example.
  • multicast BAP addresses are assigned to IAB nodes #4, #6, and #7.
  • bits 4, 6 and 7 in FIG. 27 are assigned '1' and the remaining bits are assigned '0'.
  • hatching is added to bits to which '1' is assigned. Therefore, the multicast BAP address assigned in the examples of FIGS. 26 and 27 is "0011010000" in binary notation.
  • 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 different than 10 bits. This allows, for example, greater flexibility in communication systems.
  • FIG. 27 shows an example in which the upper two bits of the multicast BAP address are empty bits
  • a predetermined bit pattern may be assigned.
  • the bit pattern may be a predetermined bit pattern indicating a multicast BAP address.
  • the bit pattern may have a number of bits different from 2 bits.
  • 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 of the BAP address matches the bit pattern. This makes it possible to reduce the amount of processing in the communication system, for example.
  • Different path IDs may be assigned to the same destination BAP address. For example, a different Path ID may be assigned to each of the routes to the terminal IAB node. As another example, different path IDs may be assigned to different multicast contents. By assigning a Path ID to each multicast content, for example, an IAB node can quickly identify the multicast content.
  • the same path ID may be assigned to different destination BAP addresses. This makes it possible to reduce the number of path IDs used for multicasting, for example.
  • a different RLC channel may be used for each multicast content. This makes it possible to identify multicast content while reducing the number of path IDs used for multicast, for example.
  • the above method (c) may be used for unicast. As a result, for example, even in unicast, the IAB node can quickly determine that its own IAB node is the destination.
  • the same BAP address may be assigned to the IAB nodes in the same hierarchy.
  • the aforementioned hierarchy may be a hierarchy based on IAB donor CUs.
  • a multicast BAP address assigned to an IAB node in the same hierarchy may be set as the next hop BAP address. This makes it possible, for example, to quickly execute the routing process in the IAB node.
  • a multicast BAP address assigned to an IAB node in the same hierarchy may be set as the destination BAP address.
  • a plurality of BAP addresses may be set as the destination BAP address.
  • a plurality of BAP addresses may be set as the destination BAP address when the layers of terminal IAB nodes are different. Multiple such BAP addresses may be included in the BAP header.
  • An IAB node and/or an IAB donor DU may schedule using multiple such BAP addresses contained in the BAP header.
  • the IAB node when the IAB node is a terminal IAB node and a child IAB node is connected, the IAB node transmits multicast data to the UE after a predetermined time has passed since transmission to the child IAB node You may
  • the predetermined time may be determined using the hierarchy of the IAB node targeted by the BAP address contained in the destination BAP header. This allows, for example, the reception time difference between UEs connected to terminal IAB nodes of different hierarchies to be reduced for the same multicast data.
  • the same BAP address may be assigned to child IAB nodes that connect to different parent IAB nodes. This makes it possible to reduce the number of BAP addresses used, for example.
  • a predetermined BAP address indicating the hierarchy may be provided.
  • the BAP address may be pre-determined by a standard, or may be determined by the IAB donor CU.
  • One or more IAB nodes may be associated with a given BAP address.
  • One or more IAB nodes may be IAB nodes in the same hierarchy as each other.
  • the aforementioned association may be determined by the IAB donor CU and notified to the IAB donor DU and/or IAB node.
  • the notification may include information about the BAP address and the BAP address of the IAB node in question.
  • the notification may be included in the F1 interface, for example, the BAP MAPPING CONFIGURATION signaling disclosed in Non-Patent Document 35 (TS38.473).
  • the notification may include hierarchy information instead of the BAP address, or may include both the BAP address and hierarchy information.
  • Information about the hierarchy of the IAB donor DU and/or IAB node may be included in the notification. IAB donor DUs and/or IAB nodes may use this information to perform routing. This avoids complexity in the routing process of IAB nodes, for example.
  • IAB donor DUs and/or IAB nodes may use information about their hierarchy to derive the hierarchy of the IAB nodes under them. Information about its hierarchy may be communicated by the IAB donor CU to the IAB donor DU and/or IAB nodes. This makes it possible, for example, to quickly execute the routing process in the IAB node.
  • FIG. 28 is a diagram showing an example of multicast BAP address allocation in an IAB base station.
  • FIG. 28 shows an example in which the same BAP address is assigned to IAB nodes in the same hierarchy.
  • the hierarchy in FIG. 28 is based on IAB donor DUs.
  • UEs #1 to #7 are UEs receiving multicast, and IAB node #7 hatched with dots indicates an IAB node to which no multicast BAP address is assigned.
  • an IAB node with a downward-sloping line and an IAB node with an upward-sloping line indicate IAB nodes in the first and second layers, respectively.
  • Different BAP addresses may be assigned to child IAB nodes that connect to different parent IAB nodes. This makes it possible, for example, to avoid the complexity of the communication system.
  • the above hierarchy may be a hierarchy based on the UE.
  • the same IAB node may have BAP addresses corresponding to multiple hierarchies. 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 hierarchy.
  • an IAB node may have a BAP address corresponding to the deepest hierarchy among one or more UE-based hierarchies under it.
  • the IAB node may use the hierarchy information in scheduling. This can, for example, reduce the delay in data transmission from the IAB node to the UE.
  • an IAB node may have a BAP address corresponding to the lowest hierarchy among one or more UE-based hierarchies under it.
  • the same BAP address may be assigned to IAB nodes below a predetermined hierarchy.
  • the same BAP address may be assigned to IAB nodes above a given hierarchy. This makes it possible to reduce radio resources in multicast communication using IAB base stations, for example.
  • the hierarchy may be a hierarchy based on IAB donor CUs. As another example, the hierarchy may be a UE-based hierarchy.
  • the same BAP address may be assigned to the IAB node that is the route from the IAB donor CU to the UE.
  • FIG. 29 is a diagram showing an example of allocating the same BAP address to the IAB node that is the route from the IAB donor CU to the UE.
  • FIG. 29 shows an example in which multicast BAP addresses are assigned to IAB nodes #1, #3, and #5, which are routes to UE #5.
  • UE #1 to #6 are UEs that receive multicast
  • hatched IAB node #2, #4 are IAB nodes to which multicast BAP addresses are not assigned
  • #5 indicates an IAB node to which a multicast BAP address is assigned.
  • the same BAP address is assigned to the IAB nodes #1, #3, and #5 as the multicast BAP address.
  • a combination of (a) and (b) may be used.
  • a combination of (a) and (b) may be used.
  • using the above-mentioned (a) multicast BAP address assigned to the terminal IAB node as the destination BAP address, and the above-mentioned (b) multicast BAP address assigned to the child IAB node as the next hop BAP address. good too. This allows, for example, avoiding the complexity of multicast transmissions in IAB nodes.
  • FIG. 30 is a diagram showing an example in which multicast BAP addresses are assigned to terminal IAB nodes and child IAB nodes connected to the same parent IAB node.
  • UEs #1 to #7 indicate UEs that receive multicast.
  • IAB nodes #4 to #7 with horizontal lines are assigned BAP addresses for terminal IAB nodes.
  • IAB nodes #1, #2 with upward lines, IAB nodes #3, #4 with downward lines, and IAB nodes #5, #6 with vertical lines are connected to the same parent IAB node.
  • a BAP address is assigned to the child IAB node that In FIG. 30, IAB nodes #4-#6 are assigned both of the above BAP addresses.
  • IAB node #4 is assigned a BAP address for terminal IAB nodes and a BAP address assigned to a child IAB node having IAB node #1 as a parent IAB node.
  • IAB nodes #5 and #6 are assigned BAP addresses for terminal IAB nodes and BAP addresses assigned to child IAB nodes with IAB node #2 as the parent IAB node.
  • the IAB node may send the BAP-PDU received from the parent IAB node to the child IAB node.
  • the operation may be performed, for example, when a child IAB node is connected to the IAB node. As a result, for example, even when the destination BAP address includes the own IAB node, multicast transmission to child IAB nodes is possible.
  • the IAB node may forward the BAP-PDU received from the parent IAB node to upper layers.
  • the IAB node may strip the BAP header from the BAP-PDU. The action may occur, for example, if the IAB node is a terminal IAB node. This allows multicasting to UEs, for example.
  • An IAB node may perform both operations described above. Both operations described above may be performed, for example, if the IAB node is a terminal IAB node, ie it connects to a UE and also connects to child IAB nodes.
  • the IAB node may replicate the BAP-PDU disclosed in the second embodiment. This allows, for example, multicast transmissions from IAB nodes to child IAB nodes and UEs.
  • Switching between the PTM leg and the PTP leg may occur in the multicast transmission from the IAB base station.
  • the switching may be determined by the IAB donor CU, or may be determined by the IAB node directly connected to the UE.
  • the IAB donor CU and/or the IAB node may make this determination using information on the PDCP SN (Sequence Number), for example, information on the PDCP SN acknowledged to the UE.
  • the IAB node may inform the IAB donor CU of the outcome of the determination.
  • An IAB donor CU may use the results of decisions made by its own CU and/or the IAB node to determine which leg to use in the multicast.
  • the switching may be determined by the IAB donor DU, or may be determined by an IAB node on the path to the UE.
  • the IAB donor DU and/or the IAB node may use information about the RLC SN, eg, the RLC SN acknowledged to the UE, to make this determination.
  • the IAB donor DU and/or the IAB node may inform the IAB donor CU of the outcome of the determination.
  • An IAB donor CU may use the results of decisions made by its own CU and/or the IAB node to determine which leg to use in the multicast.
  • the UE may determine the switching. For example, the UE may use the multicast reception status (eg, PDCP SN, RLC SN) to make this determination.
  • the UE may notify the base station of the request for switching, or may notify the information regarding the multicast reception status.
  • the UE may be able to autonomously send the notification to the base station.
  • a PDCP status report (see Non-Patent Document 39 (TS38.323)) may be used for the notification.
  • the IAB donor CU may use the information received from the UE to switch PTM/PTP.
  • the UE may use PRACH for the notification or may use RRC signaling.
  • IAB donor DUs and/or IAB nodes communicating directly with the UE may forward the notification from the UE to the IAB donor CU.
  • the IAB donor DU and/or the IAB node may use F1 signaling to perform the transfer. This allows, for example, the IAB donor DU and/or the IAB node to notify the IAB donor CU of the PTM/PTP switching request from the UE.
  • the IAB donor CU may use the notification forwarded from the IAB donor DU and/or IAB node to switch PTM/PTP.
  • UL RRC MESSAGE TRANSFER (see Non-Patent Document 35 (TS38.473)) signaling may be used, or new signaling may be used.
  • the new signaling may include, for example, information indicating that there is a PTM/PTP switching request from the UE, may include information about the leg before switching, or information about the leg after switching. may be included, information regarding the multicast reception status at the UE for the leg may be included, or a plurality of the above information may be included.
  • information about the expiration of a timer used in the PDCP layer may be used, or PDCP SDU (Service Data Unit) and/or information indicating that the number of missing PDCP PDUs has exceeded a predetermined value, or a timer used in the RLC layer (eg, t-reassembly described in Non-Patent Document 40) may be used, 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.
  • a timer used in the RLC layer eg, t-reassembly described in Non-Patent Document 40
  • the aforementioned predetermined information may be determined in advance by the standard, or may be determined by the IAB donor CU and notified or notified 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.
  • Such information may eg be included as a reason in the F1 signaling.
  • information about multicast reception status may be included as the reason for the PTM/PTP leg switch request from the UE. This allows, for example, the IAB donor CU to obtain detailed status of the UE.
  • the RRC signaling described above may also include the same information as the F1 signaling described above. As a result, for example, the same effect as described above can be obtained.
  • the IAB donor CU may inform the IAB donor DU and/or the IAB node of the information regarding leg activation/deactivation.
  • the notification may use F1 signaling, for example, UE CONTEXT SETUP REQUEST disclosed in Non-Patent Document 35 (TS38.473) or UE CONTEXT MODIFICATION REQUEST.
  • the IAB donor DU and/or the IAB node may inform the child IAB node and/or the UE of the leg activation/deactivation information.
  • the notification may be performed using MAC signaling, for example. This enables, for example, rapid notification of the information to child IAB nodes and/or UEs.
  • multicast transmission between IAB nodes may not be performed.
  • PTM transmissions between IAB nodes may not occur. This makes it possible, for example, to avoid the complexity of the communication system.
  • a BAP header having multiple destination BAP addresses may include a multicast BAP address, or multiple destination BAP addresses set by the IAB donor CU may include a multicast BAP address. This allows, for example, greater flexibility in multicast transmission.
  • the first embodiment it is possible to set BAP addresses in multicast between IAB nodes, and as a result, multicast using IAB base stations becomes possible.
  • Embodiment 2 Data replication may be performed in multicast using IAB base stations. For example, when multicasting using PTP, multicast data to UEs and child IAB nodes may be replicated.
  • Embodiment 2 discloses a method for solving such problems.
  • the IAB donor CU duplicates the multicast data.
  • the replication may be done at the PDCP layer.
  • the IAB donor CU may send replicated data in the PDCP layer to each UE.
  • An IAB donor DU and/or an IAB node may be used for the transmission.
  • IAB donor DUs and/or IAB nodes may replicate multicast data.
  • the IAB donor DU and/or the IAB node may do the replication at the BAP layer.
  • the duplication in the BAP layer may be done in the BAP layer of the sending side.
  • multicast data may be duplicated by the BAP layer on the sending side. This makes it possible, for example, to reduce memory buffer usage in the IAB node.
  • FIG. 31 is a diagram showing an example of duplication operation in the BAP layer.
  • FIG. 31 is an example of BAP layer operation in an IAB node to which multiple child IAB nodes are connected.
  • the BAP layer shown in FIG. 31 is composed of a receiving side BAP layer and a transmitting side BAP layer.
  • FIG. 31 shows an example in which replication in the BAP layer is performed in the sending BAP layer.
  • the received BAP-PDU 3110 is input to the receiving side BAP layer from the input side BH RLC channel.
  • Functional unit 3115 included in the BAP on the receiving side determines whether to transfer to the higher layer or to the BAP layer on the transmitting side.
  • BAP-PDU 3110 is forwarded to the sending BAP layer.
  • BAP-PDU 3110 input to the BAP layer on the sending side is input to routing function section 3125 .
  • the destination child IAB node is determined, and the BAP-PDU 3110 is duplicated to generate a plurality of BAP-PDUs 3130.
  • FIG. The generated BAP-PDU 3130 is mapped to the output side BH RLC channel. Each generated BAP-PDU 3130 may be sent to a different IAB node.
  • the duplication in the BAP layer may be done in the BAP layer of the receiving side. For example, at end IAB nodes to which child IAB nodes are connected, replication of multicast data by the receiving BAP layer may occur. This makes it possible, for example, to avoid the complexity of the multicast data transmission process at the terminal IAB nodes to which the child IAB nodes are connected. As another example, in the PTP transmission from the end IAB node to the UE, replication of the multicast data by the BAP layer at the receiving side may be performed. This makes it possible, for example, to avoid complexity in the design of communication systems.
  • FIG. 32 is a diagram showing another example of replication operation in the BAP layer.
  • FIG. 32 is an example of BAP layer operation in a terminal IAB node to which child IAB nodes are connected.
  • the BAP layer shown in FIG. 32 is composed of a receiving side BAP layer and a transmitting side BAP layer.
  • FIG. 32 shows an example in which replication in the BAP layer is performed in the receiving BAP layer.
  • the received BAP-PDU 3110 is input to the receiving side BAP layer from the input side BH RLC channel.
  • a functional unit 3215 included in the BAP on the receiving side determines whether to transfer to the upper layer or to the BAP layer on the transmitting side.
  • Duplication of the BAP-PDU 3110 is done in the BAP layer if necessary.
  • BAP-PDU 3110 is duplicated into BAP-PDU 3220 forwarded to the sending BAP layer and BAP-PDU 3221 forwarded to higher layers.
  • the BAP-PDU 3220 input to the BAP layer on the transmitting side is mapped to the BH RLC channel on the output side through routing.
  • FIG. 33 is a diagram showing another example of replication operation in the BAP layer.
  • FIG. 33 is an example of BAP layer operation in a terminal IAB node to which multiple child IAB nodes are connected.
  • the BAP layer shown in FIG. 33 is composed of a receiving side BAP layer and a transmitting side BAP layer.
  • FIG. 33 shows an example in which replication in the BAP layer is performed in the receiving BAP layer.
  • the received BAP-PDU 3110 is input to the receiving side BAP layer from the input side BH RLC channel.
  • a functional unit 3215 included in the BAP on the receiving side determines whether to transfer to the upper layer or to the BAP layer on the transmitting side.
  • Duplication of the BAP-PDU 3110 is done in the BAP layer if necessary.
  • a BAP-PDU 3110 is duplicated to generate a plurality of BAP-PDUs 3320 to be forwarded to the sender BAP layer and a BAP-PDU 3221 to be forwarded to the upper layer.
  • the function unit 3215 may perform the duplication using the routing information possessed by the routing function unit of the BAP layer on the transmission side, or has the same routing information as the routing information possessed by the routing function unit of the BAP layer on the transmission side.
  • multiple BAP-PDUs 3320 input to the BAP layer on the transmitting side are mapped to BH RLC channels on the output side through routing.
  • the duplication in the BAP layer may be done in both the sender and receiver BAP layers. For example, in terminal IAB nodes with multiple child IAB nodes connected, it may be done at both the sender and receiver BAP layers. For example, replication at the receiving BAP layer may generate a BAP-PDU for the child IAB node and a BAP-PDU for the UE, and replication at the transmitting BAP layer may result in multiple child IAB nodes. of BAP-PDUs may be duplicated. This makes it possible, for example, to reduce memory buffer usage in the IAB node.
  • FIG. 34 is a diagram showing an example of replication operations in the BAP layer.
  • FIG. 34 is an example of BAP layer operation in a terminal IAB node to which multiple child IAB nodes are connected.
  • the BAP layer shown in FIG. 34 is composed of a receiving side BAP layer and a transmitting side BAP layer.
  • FIG. 34 shows an example in which replication in the BAP layer is performed in the sending BAP layer and the receiving BAP layer.
  • the received BAP-PDU 3110 is input to the receiving side BAP layer from the input side BH RLC channel.
  • a functional unit 3215 included in the BAP on the receiving side determines whether to transfer to the upper layer or to the BAP layer on the transmitting side.
  • Duplication of the BAP-PDU 3110 is done in the BAP layer if necessary.
  • BAP-PDU 3110 is duplicated into BAP-PDU 3220 forwarded to the sending BAP layer and BAP-PDU 3221 forwarded to higher layers.
  • BAP-PDU 3220 input to the BAP layer on the sending side is input to routing function section 3125 .
  • the routing function unit 3125 determines the destination child IAB node, copies the BAP-PDU 3220 , and generates a plurality of BAP-PDUs 3130 .
  • the generated BAP-PDU 3130 is mapped to the output side BH RLC channel.
  • replication in the BAP layer is done in both the sender and receiver BAP layers, in terminal IAB nodes to which multiple child IAB nodes and multiple UEs are connected, It may be done in both BAP layers on the receiving side.
  • replication at the BAP layer at the receiving side may generate a BAP-PDU for the child IAB node and multiple BAP-PDUs for multiple UEs
  • replication at the BAP layer at the transmitting side may generate multiple replication of BAP-PDUs intended for child IAB nodes of . This makes it possible, for example, to avoid complexity in the communication system.
  • Replication of multicast data in IAB donor DUs and/or IAB nodes may be done in higher layers. For example, it may be done at the IP layer. This makes it possible, for example, to reduce memory buffer usage in the IAB node. As another example, it may be done at the UDP layer. This allows, for example, a further reduction in memory buffer usage in the IAB node. As another example, it may be done at the GTP-u layer. This allows, for example, a further reduction in memory buffer usage in the IAB node.
  • duplication of multicast data may occur when forwarding from the GTP-u layer on the receiving side of an IAB node to the RLC layer on the transmitting side of the IAB node. This allows, for example, a further reduction in memory buffer usage in the IAB node.
  • FIG. 35 shows an example of operations in which multicast data is replicated between receivers and senders of terminal IAB nodes, from the IAB donor CU, through the intermediate IAB nodes, to the terminal IAB nodes, to the UE.
  • FIG. 3 is a diagram showing a protocol stack; In the example shown in Figure 35, the multicast data is replicated after GTP-u processing on the receiving side of the terminal IAB node and enters the RLC layer on the transmitting side.
  • a new layer that replicates multicast data may be provided.
  • the layer may be provided above the GTP-u layer of the terminal IAB node, may be provided above the BAP layer of the IAB node in the middle of the terminal IAB node, or may be provided above the IAB donor DU IP It may be provided in a higher layer. Replication of multicast data in IAB donor DUs and/or IAB nodes may be done at this layer. This makes it possible, for example, to avoid complexity in the communication system.
  • the second embodiment it is possible to prevent discrepancies between devices in multicast using IAB base stations, and as a result, it is possible to prevent malfunctions in the communication system.
  • Embodiment 3 In multicast using an IAB base station, multiple data paths may converge on the way.
  • the merging of paths may be performed at the terminal IAB node or may be performed at an IAB node that is not the terminal IAB node.
  • FIG. 36 is a diagram showing an example in which multiple paths of data merge in the middle.
  • the route from IAB node #2 and the route from IAB node #3 join at IAB node #4, which is not a terminal IAB node.
  • IAB node #4 which is not a terminal IAB node, cannot refer to the PDCP header. Therefore, when the node where paths are joined is an IAB node that is not a terminal IAB node, the IAB node cannot determine the identity of the multicast data. Therefore, the method of 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.
  • the discard may be performed when multicast data from the one route arrives.
  • the IAB node may hold multicast data arriving from other paths until multicast data from the one path arrives.
  • the IAB node may, for example, send multicast data arriving from other paths to child IAB nodes if multicast data from the one path does not arrive for a predetermined time. This makes it possible, for example, to improve the reliability of multicast transmissions.
  • the IAB donor CU may notify the IAB node of information on PDCP settings.
  • the information may, for example, include bearer identifiers, or may include information about RLC channels.
  • RRC signaling for example, RRC reconfiguration (RRCReconfiguration) may be used for notification of the information.
  • the notification may be done via the parent IAB node for each path of the IAB node.
  • the IAB node may use the information to obtain information about PDCP settings for multicast data. As a result, for example, the IAB node can recognize that the data received from multiple routes are the data of the same multicast content.
  • a plurality of prior-hop BAP addresses (Prior-Hop BAP Address: see Non-Patent Document 35 (TS38.473)) may be provided.
  • a plurality of input-side backhaul RLC channel identifiers (Ingress Backhaul RLC Channel ID: see Non-Patent Document 35 (TS38.473)) may be provided.
  • Multiple combinations of one previous hop BAP address and one or more ingress backhaul RLC channel identifiers may be provided.
  • Multiple pre-hop BAP addresses and/or multiple ingress backhaul RLC channel identifiers may be provided for one mapping information. As a result, for example, the IAB node can quickly recognize that the multicast data received from multiple paths are data of the same multicast content.
  • the IAB donor CU may decide from which route the multicast data received at the IAB node should be sent to the child IAB node.
  • the IAB donor CU may notify the IAB node of information on which route the multicast data is to be sent to the child IAB node.
  • the notification may be performed using RRC signaling, may be performed using MAC signaling, or may be performed using L1/L2 signaling.
  • the IAB node or the UE may determine from which route the multicast data received at the IAB node should be transmitted to the child IAB node.
  • the IAB node and/or UE may inform the IAB donor CU on which route to send the multicast data to the child IAB node.
  • a valid previous-hop BAP address and/or input-side backhaul RLC channel identifier may be set among the multiple previous-hop BAP addresses and/or multiple input-side backhaul RLC channel identifiers described above.
  • the configuration may be performed by the IAB donor CU, by the IAB node itself, or by the UE.
  • the aforementioned notification may be used when the IAB donor CU performs the setting.
  • An IAB node may send multicast data from a valid previous-hop BAP address and/or ingress backhaul RLC channel identifier to child IAB nodes. This makes it possible, for example, to avoid complexity in multicast routing.
  • Multicast data arriving from more than one path may be sent to child IAB nodes.
  • route the arriving multicast data is sent to the child IAB node the method described above may be used. As a result, for example, redundancy in multicast transmission can be ensured while reducing the usage of radio resources.
  • the multicast data arriving from one or more paths, which is sent to the child IAB node may be data from paths that have previously arrived at the IAB node. This enables, for example, fast communication of multicast.
  • multicast data from multiple routes may be sent as-is to child IAB nodes.
  • redundancy in multicast can be ensured, and as a result, reliability in the communication system can be improved.
  • merging may not occur at IAB nodes other than terminal IAB nodes, merging may not occur at terminal IAB nodes, or merging may not occur at both. This makes it possible, for example, to avoid the complexity of the communication system.
  • the third embodiment it is possible to efficiently use radio resources in multicast data transmission.
  • Embodiment 4 3GPP is considering supporting various services using SL communication in both EPS and 5G core systems (see Non-Patent Documents 1, 16, 20, 21, 22, and 23). Communication is performed between terminals in SL communication. In SL communication, not only direct communication between terminals but also communication between UE and NW via a relay has been proposed (Non-Patent Document 20 (3GPP TR23.703), Non-Patent Reference 23 (3GPP TS23.303), Non-Patent Document 27 (3GPP TR38.836)).
  • a relay between the UE and the NW may be called a UE-to-NW relay or a UE-NW relay.
  • a UE that implements relaying between a UE and a NW may be referred to as a relay UE.
  • a method using a UE-NW relay can be considered.
  • communication between a gNB and a UE takes place via a relay UE.
  • Communication between the gNB and the relay UE is performed by Uu, and communication between the relay UE and the remote UE is performed by PC5.
  • a UE connected to a NW via at least one relay UE is referred to herein as a remote UE.
  • the problem is how to improve the communication quality between the UE and the NW.
  • DC Dual Connectivity
  • a UE communicates by connecting to two base stations.
  • the conventional DC method is disclosed only when the UE is directly connected to the base station.
  • Communication between the remote UE and the NW via the relay UE requires communication on the PC 5 as well as Uu, unlike direct communication between the remote UE and the NW. Therefore, there is a problem that simply using the conventional method for direct communication between the remote UE and the NW cannot be applied to communication between the remote UE and the NW via the relay UE.
  • the method of dual connectivity in the communication between the remote UE and the NW via the relay UE is not disclosed at all in the established standards and the like.
  • the fourth embodiment discloses a method for solving such problems.
  • relay UEs are connected to a plurality of base stations in communication between remote UEs and NWs performed via relay UEs.
  • the plurality may be two, for example.
  • the relay UE connects with two base stations.
  • a method in which a relay UE or a remote UE connects to two base stations in communication between a remote UE and a NW via a relay UE may be simply referred to as DC.
  • the two base stations may be hereinafter referred to as MN (Master Node) and SN (Secondary Node).
  • MN has C-Plane (Control Plane) connection with CN (Core Network).
  • the MN may be an MCG (Master Cell Group).
  • the SN may be an SCG (Secondary Cell Group).
  • it may be a cell group composed of SNs.
  • a relay UE connects with multiple gNBs for a radio bearer (RB) for communication between the remote UE and the NW.
  • the radio bearer may be, for example, an SRB (Signaling Radio Bearer).
  • the SRB may be SRB2 among a plurality of SRB0-SRB2.
  • SRB0 and SRB1 communicate using one gNB, thereby making it possible to simplify the process of establishing communication.
  • the radio bearer may be, for example, a DRB (Data Radio Bearer).
  • the communication quality of bearers for data communication can be improved.
  • FIG. 37 is a conceptual diagram when a relay UE connects with two gNBs in communication between a remote UE and a NW via a relay UE, according to the fourth embodiment.
  • the relay UE and MgNB Master gNB
  • the relay UE and SgNB Secondary gNB
  • the MgNB corresponds to the MN described above
  • the SgNB corresponds to the SN described above.
  • Remote UEs are connected to MgNBs and/or SgNBs via relay UEs. In communication between the remote UE and the NW, communication is performed between the relay UE and the MgNB and/or between the SgNB, and communication is performed between the relay UE and the remote UE.
  • FIG. 38 is a diagram showing a protocol stack when a relay UE connects with two gNBs in communication between a remote UE and a NW via a relay UE, according to the fourth embodiment. It shows the U-Plane (User Plane).
  • MN and SN have the Uu protocol.
  • the Uu protocol is SDAP, PDCP, RLC, MAC, PHY.
  • both the MN termination bearer and the SN termination bearer, the MCG bearer, the SCG bearer and the split bearer are collectively shown as bearers for DC. Protocols corresponding to these bearers are configured.
  • PDCP may be configured one for MN-terminated bearers and one for SN-terminated bearers. It may be possible to set these bearers in the setting of the DC.
  • a relay UE has two Uu protocols for MN and SN.
  • the Uu protocol is SDAP, PDCP, RLC, MAC, PHY.
  • the bearers for the MN are MCG bearers or split bearers.
  • a bearer for SN is an SCG bearer or a split bearer. Protocols corresponding to these bearers are configured.
  • PDCP may be configured one for MN-terminated bearers and one for SN-terminated bearers. DC between MN and/or SN is terminated at relay UE.
  • the relay UE and remote UE have the protocol of PC5 (also called SL).
  • the protocols of the PC5 are PC5 SDAP (SL SDAP), PC5 PDCP (SL PDCP), PC5 RLC (SL RLC), PC5 MAC (SL MAC), and PC5 PHY (SL PHY).
  • the PDU layer consists of UPF, relay UE, and remote UE.
  • a RB is set up between the MN and the remote UE.
  • a DC bearer is set between the MN and/or SN and the relay UE, and one SL bearer is set between the relay UE and the remote UE.
  • the SL bearer may also be called a PC5 bearer.
  • a bearer for DC that is terminated by PDCP is called an MN-terminated bearer in the case of the MN, and is called an SN-terminated bearer in the case of the SN.
  • a bearer having an MN RLC bearer is called an MCG bearer
  • a bearer having an SN RLC bearer is called an SCG bearer
  • a bearer having both MN and SN RLC bearers is called a split bearer.
  • An RB may be set up between the MN and the relay UE
  • an SL bearer may be set up between the relay UE and the remote UE.
  • a DC bearer may be set between the MN and/or SN and the relay UE in the RB between the MN and the relay UE.
  • Data from the NW to the remote UE is mapped to the Uu bearer by the MN and/or SN, and SDAP and PDCP processing is performed.
  • Data output from Uu's SDAP is mapped to an MCG bearer, SCG bearer, or split bearer and input to PDCP.
  • Data output from PDCP is mapped to the RLC bearer corresponding to each bearer, and transmitted to the relay UE through RLC, MAC, and PHY protocols.
  • data received from MN and/or SN is transferred to the PDU layer through the Uu protocol corresponding to each bearer.
  • bearer the relay UE implements as a DC bearer, for example, MN termination bearer, SN termination bearer, MCG bearer, SCG bearer, or split bearer is set.
  • PDU layer the data is mapped to the SL bearer and transmitted to the remote UE through the protocol of PC5.
  • the data received from the relay UE are forwarded to the PDU layer through the PC5 protocol.
  • Data from the remote UE to the NW is sent to the relay UE through the PC5 protocol at the remote UE.
  • data received from the remote UE is transferred to the PDU layer through the PC5 protocol, mapped to the Uu bearer in the PDU layer, and subjected to SDAP and PDCP processing.
  • Data output from Uu's SDAP is mapped to an MCG bearer, SCG bearer, or split bearer and input to PDCP.
  • Data output from Uu's SDAP is input to PDCP and may be mapped to MCG bearers, SCG bearers, or split bearers in PDCP.
  • Data output from PDCP is mapped to an RLC bearer corresponding to each bearer, and transmitted to MN and/or SN through RLC, MAC, and PHY protocols.
  • Data received from the relay UE at the MN and/or SN is transferred to the PDU layer through the Uu protocol corresponding to each bearer.
  • RRC and SL RRC should be provided instead of SDAP and SL SDAP in MN, relay UE and remote UE, respectively.
  • RRC corresponding to SRB and SL RRC corresponding to SL SRB should be provided. If DC is configured in SRB, only MN termination bearer may be configured. DC of SRB is enabled.
  • FIG. 39 is a diagram showing another protocol stack configuration method when a relay UE is connected to two gNBs in communication between a remote UE and a NW via a relay UE, according to the fourth embodiment. It shows the U-Plane. A part different from FIG. 38 will be mainly described.
  • MN and SN have the Uu protocol for DC, similar to the example in FIG.
  • an adaptation protocol (ADP) is configured between RLC and PDCP.
  • ADP may be configured as a sublayer of RLC.
  • a relay UE has two Uu protocols, one for MN and one for SN.
  • the Uu protocol is ADP, RLC, MAC, PHY.
  • the relay UE has the PC5 protocol between remote UEs.
  • 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.
  • PC5 ADP may be configured as a sublayer of PC5 RLC.
  • PC5 ADP may not 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.
  • Protocol configuration can be simplified.
  • the protocols of the PC5 are PC5 ADP (SL ADP), PC5 RLC, PC5 MAC, and PC5 PHY.
  • PC5 SDAP and PC5 PDCP may be omitted.
  • the remote UE has the PC5 protocol between relay UEs. Similar to the relay UE, the protocols of the PC5 are PC5 RLC, PC5 MAC, PC5 PHY. A PC5 ADP may be configured above the PC5 RLC. PC5 SDAP and PC5 PDCP may be omitted. Also, the remote UE has Uu protocol between MN and/or SN. The Uu protocols are SDAP and PDCP. At the remote UE, ADP of PC5 and PDCP of Uu are connected. If PC5's ADP is not configured, PC5's RLC and Uu's PDCP are connected.
  • a RB is set up between the MN and the remote UE.
  • a DC bearer is set between the MN and/or SN and the relay UE.
  • an RLC bearer may be set as the DC bearer.
  • An RLC channel may be set up.
  • One SL bearer is set up between the relay UE and the remote UE.
  • the SL bearer may be an SL RLC bearer. It may be an SL RLC channel.
  • the SL RLC bearer is also called a PC5 RLC bearer.
  • SL RLC channels are also referred to as PC5 RLC channels.
  • MN and SN have a function of mapping RBs between NW and remote UE to RLC bearer of Uu for DC in communication from NW to remote UE.
  • An RLC bearer of Uu for the DC includes 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 may be plural.
  • the number of RBs between the remote UE and the NW is not limited to one, and may be plural.
  • One or more RBs of the remote UE connected to the relay UE and/or one or more RBs between the remote UE and the NW may be mapped to the Uu RLC bearer for the DC.
  • the aforementioned functions may be included in Uu's ADP configured in MN and SN.
  • the ADP may aggregate the functions when the DC is configured and when it is not configured. In this case, the configuration of MN and SN can be facilitated.
  • the MN and 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) in communication from the NW to the remote UE.
  • the RB ID may be the SRB ID if the RB is an SRB.
  • the RB ID may be the DRB ID if the RB is a DRB.
  • MN and SN may add information about bearers used for DC in communication from NW to remote UE.
  • Information about the bearer used for the DC includes, for example, an identifier indicating the termination 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 or the remote UE can recognize the termination, type, etc. of the bearer used for the DC.
  • the aforementioned additional functions may be included in Uu's ADP configured in MN and SN.
  • the ADP may aggregate the functions when the DC is configured and when it is not configured. In this case, the configuration of MN and SN can be facilitated.
  • the relay UE has a function of mapping the RLC bearer of 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 by ADP of MN and SN may be used for the mapping.
  • Information about the bearer used for DC added by ADP of MN and SN may be used for the mapping. By doing so, it becomes possible to map the MCG bearer for DC, the SCG bearer, or the split bearer to the RLC bearer of PC5 in the relay UE.
  • the aforementioned functions may be included in Uu's ADP configured in the relay UE.
  • the ADP may aggregate the functions when the DC is configured and when it is not configured. In this case, the configuration of the relay UE can be facilitated.
  • the relay UE may delete some or all of the remote UE identifier added by MN and SN, the RB identifier, information about the bearer used for DC, and so on. Some or all of this identifier or information may not be added in the mapping of PC5 to the RLC bearer to the remote UE.
  • the remote UE has a function of mapping the RLC bearer of PC5 and the RLC bearer of Uu for DC to RBs 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 MN and SN may be used for the mapping.
  • Information about the bearer used for DC added by MN and SN may be used for the mapping.
  • the remote UE has a function of mapping the RB between the NW and the remote UE to the RLC bearer of PC5 in communication from the remote UE to the NW.
  • the remote UE may add the identifier of the RB between the remote UE and the NW and the identifier of the base station in communication from the NW to the remote UE.
  • There may be multiple base stations. For example, it may be added when a relay UE connects to multiple base stations.
  • Information indicating whether or not there is a plurality of base stations or information indicating whether or not there are a plurality of identifiers of the base stations may be added.
  • the identifier of the base station may be the identifier of MN and/or SN.
  • DC Downlink Control
  • MN or SN for example, transmits to multiple base stations, it is possible to recognize the RB for communication between the destination base station, the remote UE and the NW. becomes.
  • the remote UE may add information about bearers used for the DC in communication from the remote UE to the NW.
  • Information about the bearer used for the DC includes, for example, an identifier indicating the termination 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 termination and type of bearer used for DC.
  • the aforementioned additional functions may be included in the SL ADP configured in the remote UE. Functions for when DC is set and when DC is not set may be aggregated in SL ADP. Configuration of the remote UE can be facilitated.
  • the relay UE has a function of mapping the RLC bearer of PC5 to the RLC bearer of Uu for DC in communication from the remote UE to the NW.
  • the base station identifier added by the remote UE, the RB identifier, information about the bearer used for the DC, and the like may be used.
  • An RLC bearer of Uu for the DC includes 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 may be plural.
  • the aforementioned functions may be included in Uu's ADP configured in the relay UE.
  • the ADP may aggregate the functions when the DC is configured and when it is not configured. In this case, the configuration of the relay UE can be facilitated.
  • the identifier of the base station added by the remote UE, the RB identifier, the information about the bearer used for DC, etc. may be deleted in part or all. .
  • part or all of the identifier or information may not be added.
  • the relay UE may add the identifier of the remote UE and the identifier of the RB between the remote UE and the NW in communication from the remote UE to the NW.
  • the RB ID may be the SRB ID if the RB is an SRB.
  • the RB ID may be the DRB ID if the RB is a DRB.
  • the MN and SN can recognize the remote UE as the transmission source and the RB for communication between the remote UE and the NW.
  • the aforementioned additional functions may be included in Uu's ADP configured in the relay UE.
  • the ADP may aggregate the functions when the DC is configured and when it is not configured. In this case, the configuration of the relay UE can be facilitated.
  • MN and SN have the function of mapping Uu RLC bearer for DC to RB between NW and remote UE in communication from remote UE to NW.
  • the number of remote UEs connected to the relay UE is not limited to one, and may be plural.
  • the number of RBs between the remote UE and the NW is not limited to one, and may be plural.
  • the Uu RLC bearer for DC may be mapped to one or more RBs of the remote UE connected to the relay UE and/or one or more RBs between the remote UE and the NW.
  • the remote UE identifier added by the ADP of the remote UE or relay UE, the RB identifier, the information about the bearer used for the DC, etc. may be used.
  • MN and SN it becomes possible for MN and SN to transfer the MCG bearer, SCG bearer, or split bearer for DC to PDCP of RB for communication between remote UE and NW.
  • the aforementioned functions may be included in Uu's ADP configured in MN and SN.
  • the ADP may aggregate the functions when the DC is configured and when it is not configured. In this case, the configuration of MN and SN can be facilitated.
  • RRC should be provided instead of SDAP in the MN and remote UE. It is preferable to provide RRC corresponding to SRB. If DC is configured in SRB, only MN termination bearer may be configured. DC of SRB is enabled.
  • FIG. 40 is a diagram showing another protocol stack configuration method when a relay UE is connected to two gNBs in communication between a remote UE and a NW via a relay UE, according to the fourth embodiment. It shows the U-Plane. A part different from FIG. 39 will be mainly described.
  • MN and SN have the Uu protocol for DC, similar to the example in FIG.
  • the relay UE has two Uu protocols for MN and SN, as in the example of FIG.
  • the relay UE has two PC5 protocols between the remote UEs.
  • PC5 protocol for MN and SN It may be used for DC.
  • the protocols of the PC5 are PC5 RLC, PC5 MAC, and PC5 PHY.
  • a PC5 ADP may be configured above the PC5 RLC.
  • PC5 SDAP and PC5 PDCP may be omitted.
  • the remote UE has two PC5 protocols between relay UEs. PC5 protocol for MN and SN. It may be used for DC.
  • the protocols of the PC5 are PC5 RLC, PC5 MAC, and PC5 PHY.
  • a PC5 ADP may be configured above the PC5 RLC.
  • PC5 SDAP and PC5 PDCP may be omitted.
  • the remote UE has Uu protocol between MN and/or SN.
  • the Uu protocols are PC5 SDAP and PC5 PDCP.
  • the PDCP or ADP of PC5 and the PDCP of Uu are connected.
  • PDCP may be configured one for MN-terminated bearers and one for SN-terminated bearers. DC is terminated at the remote UE.
  • a RB is set up between the MN and the remote UE.
  • a DC bearer is set between the MN and/or SN and the relay UE.
  • a SL bearer for DC is set between the relay UE and the remote UE.
  • the SL bearer may be an SL RLC bearer. It may be an SL RLC channel.
  • the bearer mapping method disclosed in the example of FIG. 39 may be appropriately applied. Here, mainly different points from the method disclosed in the example of FIG. 39 will be disclosed.
  • the relay UE has a function of mapping the RLC bearer of Uu for DC to the RLC bearer of PC5 for DC in communication from the NW to the remote UE. Map the Uu RLC bearer for the MN to the PC5 RLC bearer for the MN. Map the Uu RLC bearer for SN to the PC5 RLC bearer for SN.
  • the remote UE identifier and RB identifier added by ADP of MN and SN may be used for the mapping.
  • Information about the bearer used for the DC added in the ADP of the MN and SN may be used for the mapping.
  • the relay UE can map the MCG bearer, SCG bearer, or split bearer for DC to the RLC bearer of PC5 for DC.
  • the aforementioned functions may be included in Uu's ADP configured in the relay UE.
  • the ADP may aggregate the functions when the DC is configured and when it is not configured. In this case, the configuration of the relay UE can be facilitated.
  • the relay UE may delete some or all of the remote UE identifier added by MN and SN, the RB identifier, information about the bearer used for DC, and so on. Some or all of this identifier or information may not be added in the mapping of PC5 to the RLC bearer to the remote UE.
  • the remote UE In communication from the NW to the remote UE, the remote UE has a function of mapping the RLC bearer of PC5 for MN and the RLC bearer of PC5 for SN to RBs between the NW and remote UE.
  • the mapping may use remote UE identifiers and RB identifiers added in DPs of MN and SN.
  • Information about the bearer used for DC added by MN and SN may be used for the mapping.
  • the remote UE has a function of mapping the RB between the NW and the remote UE to the RLC bearer of PC5 for DC in communication from the remote UE to the NW.
  • An RLC bearer of PC5 for the DC includes an MCG bearer, an SCG bearer, or a split bearer.
  • the remote UE may add the identifier of the RB between the remote UE and the NW and the identifier of the base station in communication from the NW to the remote UE. There may be multiple base stations.
  • a relay UE may be added when a relay UE connects to multiple base stations.
  • Information indicating whether or not there is a plurality of base stations or information indicating whether or not there are a plurality of identifiers of the base stations may be added.
  • the identifier of the base station may be the identifier of MN and/or SN. For example, it may be applied when DC is set. By doing so, even when the relay UE transmits to a plurality of base stations, the relay UE, MN or SN can recognize the RB for communication between the destination base station, the remote UE and the NW. .
  • the aforementioned additional functions may be included in the SL ADP configured in the remote UE. Functions for when DC is set and when DC is not set may be aggregated in SL ADP. Configuration of the remote UE can be facilitated.
  • the relay UE has a function of mapping the PC5 RLC bearer for DC to the Uu RLC bearer for DC in communication from the remote UE to the NW.
  • Uu RLC bearers for DC include MCG bearers, SCG bearers, and split bearers. Map the PC5 RLC bearer for the MN to the Uu RLC bearer for the MN. Map the PC5 RLC bearer for SN to the Uu RLC bearer for SN. Map PC5's MCG bearer to Uu's MCG bearer. Map PC5's SCG bearer to Uu's SCG bearer. Map PC5's split bearer to Uu's split bearer.
  • the identifier of the base station added by the remote UE may be used.
  • the number of remote UEs connected to the relay UE is not limited to one, and may be plural.
  • the aforementioned functions may be included in Uu's ADP configured in the relay UE.
  • the ADP may aggregate the functions when the DC is configured and when it is not configured. In this case, the configuration of the relay UE can be facilitated.
  • the identifier of the base station added by the remote UE, the RB identifier, the information about the bearer used for DC, etc. may be deleted in part or all. .
  • part or all of the identifier or information may not be added.
  • RRC should be provided instead of SDAP in the MN and remote UE. It is preferable to provide RRC corresponding to SRB. If DC is configured in SRB, only MN termination bearer may be configured. DC of SRB is enabled.
  • This embodiment discloses a DC setting method in which a relay UE connects with two gNBs.
  • MN performs DC settings for the relay UE.
  • MN configures DC for RB with relay UE.
  • the RB may be for communication between remote UE and MN.
  • the RB may be SRB and/or DRB.
  • the SRB may be SRB2.
  • the RB may be for communication between relay UE and MN. For example, it may be applied to a layer 3 UE-NW relay.
  • a MN performs Uu's DC setting for the relay UE.
  • a relay UE terminates the DC.
  • a relay UE in which a DC is set should be in an RRC connection state with the MN.
  • the MN may start DC configuration for the relay UE while the relay UE is in RRC connection with the MN.
  • a relay UE with a DC configured connects to a CN via an MN in the C-plane.
  • the MN sends to the SN a request to add the SN to the RB between the relay UE and the MN for communication between the remote UE and the MN.
  • the add request may be sent using Xn signaling.
  • An S-Node addition request message may be used.
  • Seventeen examples of information to be included in the add SN request are disclosed.
  • (1) is information about the relay UE that sets the DC. For example, it may be the 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. Information about the remote UE may be, for example, the identity of the remote UE. For example, it may be the capabilities of the remote UE.
  • (3) may be, for example, cell group configuration information that the MN configures in the remote UE.
  • (4) may be, for example, cell group configuration information that the MN configures in the relay UE.
  • (5) is RRC configuration information for SL between the remote UE and the relay UE. For example, it may be RRC information set from the remote UE to the relay UE and/or from the relay UE to the remote UE.
  • (6) is information about RBs between the MN that configures the DC and the remote UE.
  • it may be an RB identifier.
  • the identifier of the SRB may be used.
  • the RB that configures the DC is a DRB
  • it may be the identifier of the DRB. It becomes possible to identify the RB that sets the DC.
  • it may be PDCP configuration information.
  • the RB that sets the DC is a DRB, it may be SDAP configuration information.
  • (7) is information about RBs between the MN that configures the DC and the relay UE. Examples of information about RBs are the same as (6).
  • the SL bearer may be SL RB.
  • the SL bearer may be SL RB.
  • it may be an SL RB identifier.
  • an SL SRB is set as the SL RB, it may be the identifier of the SL SRB.
  • an SL DRB is set as the SL RB, it may be the identifier of the SL DRB.
  • it may be SL PDCP configuration information.
  • SL bearers may be SL RLC bearers.
  • it may be the identifier of the SL RLC bearer.
  • it may be SL RLC, SL MAC, and/or SL PHY configuration information.
  • it may be the configuration information of the SL logical channel.
  • (9) is information about PDUs between the relay UE and the CN that are set for communication between the remote UE and the NW via the relay UE.
  • it may be a PDU session identifier.
  • it may be information about the QoS required for the PDU session.
  • (10) is information on PDUs between the remote UE and the CN that are configured for communication between the remote UE and the NW via the relay UE.
  • it may be a PDU session identifier.
  • it may be information about the QoS required for the PDU session.
  • (11) is information indicating the termination of the DC bearer. For example, it may be information indicating whether the bearer is an MN-terminated bearer or an SN-terminated bearer.
  • (12) is information indicating the type of DC bearer. For example, MCG bearer, SCG bearer, split bearer, and so on.
  • (13) is the identifier of the MN to which the relay UE connects. It may be a PCell identifier. It is possible to identify the MN that is the source of the SN addition request.
  • (14) is information on QoS required for communication between the remote UE and the NW.
  • Information on QoS required for communication between the relay UE and the NW or information on QoS required for communication between the remote UE and the relay UE may be used.
  • Information about QoS includes, for example, the resource type required for the communication, packet loss rate, allowable delay, priority, and the like.
  • (15) is, for example, an identifier for network slicing.
  • (16) is information about the execution of the trace function. For example, there is information indicating whether or not to execute the trace function, information about nodes collecting traced information, information about information MDT (Minimization of Drive Tests) to be collected, and the like.
  • the case where the remote UE is indirectly connected to the NW via the relay UE may be included.
  • information indicating which base station the remote UE is connected to, information about the relay UE to which the remote UE is connected, information indicating which base station the relay UE is connected to, information between the remote UE and the relay UE , RLF information between the relay UE and the base station, information on the MDT of the remote UE, information on the MDT of the relay UE, and the like may be collected.
  • This information is shared between base stations such as 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 an MN and an SN, and between a previously connected base station and a newly connected base. It may be communicated between stations, between base stations and nodes that collect information about traces.
  • the MN can send an SN addition request for the DC to the SN. Also, by receiving the SN addition request from the MN, the SN can recognize, for example, which relay UE the DC is for. The SN may use the information received from the MN to configure the DC for the relay UE.
  • SN performs DC setting for the relay UE.
  • SN configures for DC between relay UE and SN.
  • the SN may perform this DC configuration using information contained in the SN Add Request message received from the MN.
  • the DC setting between the SN for the relay UE the setting shown in the information example included in the DC setting described later may be performed.
  • information related to SN may be set.
  • it may be an RRC setting between the SN and the relay UE.
  • the RRC configuration may for example be the configuration for the RLC bearer between the SN and the relay UE.
  • it may be the setting of a cell group between the SN and the relay UE.
  • the SN sends a response message to SN's addition request to MN. If the SN performs DC setup, it sends an Add SN Request Acknowledgment message to the MN. Xn signaling should be used for transmission. An S-Node addition request acknowledge message may be used as the SN addition request acknowledgment message.
  • the message may include DC configuration information for the relay UE.
  • the DC configuration information may be, for example, cell group configuration information 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 relay UE, information on PDU between relay UE and CN, information on PDU between remote UE and CN, information indicating bearer termination, bearer type information, and the like.
  • the SN may set the SL between the relay UE and the remote UE.
  • SN sets SL between relay UE and remote UE for DC.
  • the SN may configure the SL using information contained in the SN Add Request message received from the MN.
  • an SL bearer which will be described later, may be set.
  • information related to the SN may be set.
  • the SL configuration may be the RRC configuration of the SL between the remote UE and the relay UE.
  • SL RRC setting from the remote UE to the relay UE and/or from the relay UE to the remote UE may be possible.
  • the SL RRC settings may be, for example, settings related to the SL RLC bearer between the relay UE and the remote UE.
  • the acknowledgment message for the SN addition request sent from the SN to the MN may include SL setting information between the relay UE and the remote UE. For example, it may include RRC configuration information for SL between remote UE and relay UE.
  • the MN may use the information received from the SN to modify the SL configuration 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. By doing so, it is possible to consider the setting information of the SN. It is possible to consider the radio wave propagation environment and the load status of the SN, and improve the communication quality between the remote UE and the NW via the relay UE.
  • the SN fails to set the DC for the relay UE, it sends an SN addition request rejection response message to the MN.
  • Xn signaling should be used for transmission.
  • An S-Node addition request reject message may be used as the SN addition request reject response message.
  • the message may include, for example, information about the relay UE and reason information.
  • MN sends configuration for DC to relay UE.
  • Information to be included in the settings for DC are disclosed.
  • the information about RB in (1) is information about setting of RB. Five examples of information on setting RBs are disclosed. (1-1) Information about SRB to be set. (1-2) Information about DRB to be set. (1-3) Information about SDAP settings. (1-4) Information on PDCP settings. (1-5) Combinations of (1-1) to (1-4).
  • (1-1) may be, for example, the identifier of the SRB to be set.
  • SRB For example, it may be setting information of the SRB.
  • (1-2) may be, for example, the identifier of the DRB to be set.
  • (1-3) may be set, for example, when the RB to be set is a DRB. It may be associated with a DRB identifier.
  • (1-4) may be set, for example, when the RB to be set is SRB and/or DRB. It may be associated with the SRB identifier and/or the DRB identifier.
  • Information on PDCP settings may include, for example, information on RLC bearers to be connected.
  • Information about the RLC bearer may be, for example, the identifier of the logical channel.
  • information indicating the type of bearer for DC may be used.
  • RB settings that have already been set may be used.
  • the RB setting may be a modification of an already set RB setting.
  • Information indicating the RB settings that have already been set may be included.
  • the information indicating the RB setting may be an RB identifier.
  • the RB may be an SRB identifier, for example, an SRB, or a DRB identifier, for example, a DRB.
  • the MN sends RB settings to the relay UE.
  • the MN may send the RB configuration to the relay UE in RRC signaling. It may be included in the RRCReconfiguration message and transmitted. It may be included in the RadioBearerConfig information and transmitted.
  • the information on the Uu RLC bearer in (2) may be information on the Uu RLC bearer for DC.
  • Uu RLC channel setting may be used instead of Uu RLC bearer setting.
  • the setting of the Uu RLC bearer will be used unless otherwise specified.
  • (2-1) may be the identifier of the RB corresponding to the RLC bearer of Uu to be configured for DC.
  • (2-2) may be RLC configuration information, for example. For example, it may be logical channel setting information. For example, it may be a logical channel identifier.
  • the setting information for the MCG Uu RLC bearer may be included in the MCG setting information.
  • (2-3) may be, for example, RLC configuration information.
  • RLC configuration information For example, it may be logical channel setting information.
  • the SCG Uu RLC bearer setting information may be included in the SCG setting information.
  • (2-4) may be, for example, information indicating whether the bearer is an MN-terminated bearer or an SN-terminated bearer.
  • (2-5) may be, for example, information indicating whether the bearer is an MCG bearer, an SCG bearer, or a split bearer.
  • RRC Reconfiguration may be used for Uu RLC bearer setting.
  • the configuration may be a modification of an already configured Uu RLC bearer configuration.
  • the message to be sent may contain information indicating the already configured Uu RLC bearer configuration.
  • the MN When the MN performs settings for the DC for the relay UE, it may use the setting information for the DC between the relay UE and the SN received from the SN. It becomes possible to take into consideration the load status in the SN.
  • the MN does not set DC for remote UE.
  • the remote UE may be unaware of the relay UE's DC configuration.
  • the PDU session may be modified.
  • the modification includes a PDU session modification procedure between MN and CN.
  • Modification of the PDU session may be when the RB that configures the DC is a DRB.
  • L3 relay modification of PDU session between relay UE and NW is performed.
  • L2 relay modification of PDU session between remote UE and NW is performed.
  • the PDU session ID notified in the DRB setting may be used.
  • a PDU session ID notified in the SDAP setting may be used.
  • the MN, CN nodes can identify the PDU session to modify.
  • 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.
  • DC bearer RLC bearer
  • Data communication between the relay UE and the remote UE is performed using SL bearers.
  • the DC setting method disclosed above may be applied when the DC is terminated by the relay UE. For example, it may be applied to the protocol example disclosed in FIG.
  • FIG. 41 is a sequence diagram showing an example of a DC setting method in which a relay UE connects with two gNBs, according to the fourth embodiment.
  • communication is performed between the remote UE and the NW via the relay UE.
  • step ST4401 data transmission/reception is performed among the remote UE, relay UE, MN, and UPF.
  • the MN decides to set up a DC for the relay UE.
  • the relay UE measures neighboring gNBs and reports the measurement results to the MN.
  • MN determines SN to be used for DC from the measurement result.
  • the MN transmits an SN addition request message to the SN.
  • MN requests SN to be added as SN for DC to relay UE.
  • the Add SN Request message is sent 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 information example of the SN addition request disclosed above.
  • the SN that receives the SN addition request message from the MN, from the information of the SN addition request, relay UE that performs DC setting, information on communication between the remote UE that performs DC setting and the NW, requested bearer termination, requested DC recognizing the bearer type, etc., and setting for DC to the relay UE.
  • the configuration for DC may be, for example, the RRC configuration between SN and relay UE.
  • the SN transmits an SN addition request response message to the MN. This example sends an acknowledgment.
  • 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 Upon receiving the SN addition request response message, the MN recognizes that the SN has configured the DC for the relay UE. Also, the MN is aware of the RRC configuration between the SN and the relay UE.
  • the MN notifies the SN of the Xn-U address indication message. For example, MN sets an address to be used for DC between MN and SN and transmits it to SN in step ST4404. This enables the MN and SN to share the address used for the DC and to transmit and receive data between the MN and SN.
  • the MN transmits settings for DC to the relay UE.
  • the transmission uses RRC signaling. Configuration may be performed using RRC reconfiguration messages.
  • the DC settings may include the information example of the DC settings disclosed above.
  • the RRC setting information received from the SN may be used as the SCG setting of the DC setting information.
  • the relay UE can set the DC between the MN and the SN.
  • the relay UE that has performed the DC setting for the MN and SN transmits a DC setting response to the MN in step ST4406. In this example, it is assumed to be an affirmative response.
  • the transmission uses RRC signaling. An RRC reconfiguration complete message may be used.
  • the MN recognizes that the relay UE has completed DC setup using the MN and SN.
  • the MN transmits an SN setting complete message to the SN.
  • the transmission uses Xn signaling.
  • An S-Node reconfiguration complete message may be sent.
  • the SN recognizes that the MN and relay UE have completed the SN configuration for the DC.
  • step ST4408 the relay UE starts RA processing and communicates with the SN while maintaining communication with the MN.
  • step ST4409 the MN transfers the SN status to the SN, and in step ST4410, transfers the data from the UPF to the SN.
  • the path update process of step ST4420 is performed.
  • PDU session modification indication message transmission in step ST4411, bearer modification message transmission in step ST4412, end marker packet transmission in step ST4413, and PDU session modification completion message transmission in step ST4414 are performed. to change the path of U-Plnae from MN to SN.
  • DC is performed between the relay UE, MN, and SN.
  • data communication takes place between relay UE, SN, UPF.
  • the relay UE is in a state where the remote UE and the PC5 connection are being made. Therefore, for example, in the case of the SN-terminated SCG bearer, data communication is performed between the remote UE, relay UE, SN, and UPF in step ST4415.
  • data communication is performed between remote UE, relay UE, SN, MN and UPF.
  • data communication takes place between remote UE, relay UE, MN, SN, UPF.
  • MN terminated split bearer data communication takes place between remote UE, relay UE, SN, MN and UPF.
  • SN terminated split bearer data communication takes place between remote UE, relay UE, MN, SN and UPF.
  • a relay UE connects with two gNBs.
  • Modification of the SL bearer between remote UE and relay UE may be performed.
  • the MN notifies the relay UE and the remote UE of the modification of the SL bearer. Modifying the SL bearer may be performed during the DC setting process to the relay UE, or may be performed after the DC setting process.
  • the MN sets the SL bearer between the remote UE and the relay UE for the relay UE.
  • the SL bearer configuration may be a configuration for SL bearer modification. Three examples of SL bearer setting information are disclosed. (1) Information about SL RBs. (2) Information about the SL RLC bearer. (3) A combination of (1) and (2).
  • the information on SL RBs in (1) is information on setting of SL RBs. Five examples of information on SL RB configuration are disclosed. (1-1) Information about SL SRB to be set. (1-2) Information about SL DRB to be set. (1-3) Information about SL SDAP settings. (1-4) Information about SL PDCP setting. (1-5) Combinations of (1-1) to (1-4).
  • (1-1) may be, for example, the identifier of the SL SRB to be set.
  • it may be the setting information of the SL SRB.
  • (1-2) may be, for example, the identifier of the SL DRB to be set.
  • it may be the setting information of the SL DRB.
  • (1-3) may be set, for example, when the SL RB to be set is the SL DRB. It may be associated with the SL DRB identifier.
  • (1-4) may be set, for example, when the SL RB to be set is SL SRB and/or SL DRB. It may be associated with the SL SRB identifier and/or SL DRB identifier.
  • Information on SL PDCP settings may include, for example, information on SL RLC bearers to be connected.
  • the information about the SL RLC bearer may be, for example, the identifier of the logical channel.
  • information indicating the type of bearer for DC may be used.
  • it may be information about a cell group.
  • SL RB settings that have already been set may be used.
  • SL RB settings may be modifications of SL RB settings that have already been set. It is preferable to include information indicating SL and RB settings that have already been set.
  • the information indicating the SL RB setting may be the identifier of the SL RB.
  • the SL RB may be the identifier of the SL SRB, for example, the identifier of the SL DRB, or the identifier of the SL DRB, for example.
  • the MN sends SL RB configuration to relay UE.
  • the MN may send the SL RB configuration to the relay UE by RRC signaling. It may be included in the RRCReconfiguration message and transmitted. Alternatively, it may be included in an SL RRCReconfiguration message (RRCReconfigurationSidelink) and transmitted. It may be included in SL RadioBearerConfig information (SL-RadioBearerConfig) and transmitted.
  • (2) may be SL RLC channel settings instead of SL RLC bearer settings.
  • SL RLC bearer settings will be used for explanation.
  • SL RLC bearer setup Four examples of information to be included in the SL RLC bearer setup are disclosed. (2-1) Identifier of the corresponding RB. (2-2) SL RLC bearer setup information. (2-3) SL RLC bearer identifier. (2-4) A combination of (2-1) to (2-3).
  • (2-1) may be the identifier of the RB corresponding to the SL RLC bearer.
  • (2-2) may be RLC configuration information, for example.
  • it may be logical channel setting information.
  • it may be a logical channel identifier.
  • RRC Reconfiguration may be used to transmit SL RLC bearer settings.
  • the configuration may be a modification of an already configured SL RLC bearer configuration.
  • the message to be sent may contain information indicating the already set SL RLC bearer setting.
  • the MN may include the SL bearer configuration information, Uu's RB configuration and/or Uu's RLC bearer configuration in the RRC message to be transmitted, or include it in another RRC message and transmit it to the relay UE. You may
  • the MN sets the SL bearer between the remote UE and the relay UE for the remote UE.
  • the SL bearer configuration may be a configuration for SL bearer modification. Modification of the SL bearer may be performed.
  • the example disclosed above may be appropriately applied.
  • the MN sends SL RB settings to the remote UE.
  • the MN may send the SL RB configuration to the remote UE via RRC signaling.
  • the setting may be included in the RRCReconfiguration message and transmitted. Alternatively, it may be included in the SL RRCReconfiguration message and transmitted. It may be included in the SL RadioBearerConfig information and transmitted.
  • RRC Reconfiguration may be used to transmit SL RLC bearer settings.
  • the configuration may be a modification of an already configured SL RLC bearer configuration. It may also include information indicating SL RLC bearer settings that have already been set.
  • the MN may use the SL bearer setting information between the remote UE and the relay UE received from the SN. It becomes possible to take into consideration the load status in the SN.
  • FIG. 42 is a sequence diagram showing another example of a DC setting method in which a relay UE connects with two gNBs, according to the fourth embodiment. It shows the case where modification of SL bearer setting is performed during DC setting process to relay UE.
  • steps common to those in FIG. 41 are assigned the same step numbers, and common descriptions are omitted. If the SL bearer between the remote UE and the relay UE needs to be modified, the MN will configure the SL bearer for the relay UE and the remote UE.
  • the MN transmits to the relay UE the setting of the SL bearer between the remote UE and the relay UE.
  • the SL bearer configuration may include the SL bearer configuration information disclosed above.
  • the setup of the SL bearer from the MN to the relay UE may be sent together with or included in the DC setup from the MN to the relay UE, disclosed in FIG. Alternatively, it may be performed separately. In this example, it is sent in the same RRC message together with or included in the DC configuration.
  • the relay UE Upon receiving the SL bearer setup, the relay UE enables setup of SL bearers for SL communication between remote UEs.
  • step ST4406 the relay UE transmits to the MN an SL bearer setup completion message between remote UEs.
  • Completion of SL bearer setup from relay UE to MN may be sent together with or included in DC setup completion from relay UE to MN as disclosed in FIG. Alternatively, it may be performed separately. In this example, it is sent in the same RRC message together with or included in the DC configuration complete.
  • the MN transmits to the remote UE the setting of the SL bearer between the remote UE and the relay UE.
  • the SL bearer configuration may include the SL bearer configuration information disclosed above.
  • SL bearer setup from MN to remote UE is sent in RRC signaling.
  • An RRC reconfiguration message may be used.
  • the remote UE that has received the SL bearer setting can set the SL bearer for SL communication between relay UEs.
  • step ST4502 the remote UE transmits an SL bearer setup completion message between relay UEs to the MN.
  • SL bearer setup completion from remote UE to MN is sent in RRC signaling.
  • the transmission may use an RRC configuration complete message.
  • the process of FIG. 42 may be performed.
  • SL bearer setting between remote UE and relay UE suitable for DC setting becomes possible.
  • MN configures DC for relay UE and remote UE.
  • MN configures DC for RB with remote UE.
  • the RB is for communication between remote UE and MN.
  • the RB may be SRB and/or DRB.
  • the SRB may be SRB2.
  • the MN sets up a Uu RLC bearer for DC to the relay UE.
  • the relay UE should be in an RRC connection state with the MN.
  • the remote UE should be in an RRC connected state with the MN.
  • a remote UE configured with a DC connects to the CN via the MN in the C-plane.
  • the MN sends the SN a request to add the SN to the RB for communication between the remote UE and the MN.
  • the add request may be sent using Xn signaling.
  • An S-Node addition request message may be used.
  • the 17 items of information included in the SN addition request disclosed above may be applied as appropriate.
  • the SN performs settings for DC for relay UE.
  • the SN may use the information received from the MN to configure the DC for the relay UE.
  • the SN sends a response message to the SN's add request to the MN. If the SN performs DC setup, it sends an Add SN Request Acknowledgment message to the MN. Xn signaling should be used for transmission.
  • An S-Node addition request acknowledge message may be used as the SN addition request acknowledgment message. If the SN fails to perform DC configuration for the relay UE, it will send an SN Add Request Reject Response message to the MN. Xn signaling should be used for transmission.
  • An S-Node addition request reject message may be used as the SN addition request reject response message.
  • the information included in the SN addition request response message disclosed above may be appropriately applied to the information included in the SN addition request response message.
  • MN sends configuration for DC to relay UE.
  • Five examples of information to be included in the settings for DC are disclosed.
  • the information to be included in these five DC settings is the information disclosed above, specifically, the above-mentioned four information examples to be included in the DC settings when the MN transmits the DC settings to the relay UE. It should be applied as appropriate.
  • (1) is information about RBs for communication between remote UE and MN.
  • MN does not configure RB as DC configuration for relay UE.
  • SRB is not set even when the RB for which DC is set is SRB.
  • DRB is not set even when the RB for which DC is set is DRB.
  • the information about RBs in (1) may be, for example, only RB identifiers.
  • Information on ADP setting includes, for example, information on mapping function in ADP, information on RB to be set, information on RLC bearer to be connected, and the like.
  • Information about ADP configuration may be included in the information about Uu's RLC bearer. The amount of information can be reduced by including information about ADP configuration in information about Uu's RLC bearer. By doing so, the MN can set the ADP for the relay UE.
  • the MN sets the SL bearer between the remote UE and the relay UE for the relay UE.
  • the setting of the SL bearer may be a setting for modification of the SL bearer, or modification of the SL bearer.
  • Three examples of SL bearer setting information are disclosed. (1) Information about the RLC bearer of SL. (2) Information about SL ADP settings. (3) A combination of (1) and (2).
  • the information on the RLC bearer of the SL is the information disclosed above, specifically, when the MN sets the SL bearer between the remote UE and the relay UE for the relay UE, the above "(2) SL RLC bearer information" may be applied as appropriate.
  • the information on the ADP setting of the SL is information on the PC5 ADP setting configured between the PC5 RLC and the PC5 PDCP.
  • PC5 Should be set when ADP is configured.
  • Information on ADP settings includes, for example, information on mapping functions in ADP, information on RBs to be set, and information on SL RLC bearers to be connected.
  • Information on PC5 ADP settings may be included in the information on the SL RLC bearer. The amount of information can be reduced by including the information on the PC5 ADP setting in the information on the SL RLC bearer. By doing so, the MN can set the SL ADP for the relay UE.
  • MN does not need to set SL RB for relay UE. There is no need to send information about SL and RB. SL PDCP and SL SDAP may not be set. MN sets up one SL RLC bearer for DC for relay UE.
  • the MN sets DC for the relay UE and/or sets the SL bearer between the remote UE and the relay UE, and/or sets DC between the relay UE and the SN received from the SN and/or the remote UE and the relay UE You may use the setting information of the SL bearer between. It becomes possible to take into consideration the load status in the SN.
  • MN sends configuration for DC to remote UE.
  • One example of information to be included in the settings for DC is disclosed.
  • the RB information For the RB information, the information disclosed above, specifically, the above-mentioned "(1) RB information" used when the MN transmits DC settings to the relay UE may be applied as appropriate.
  • MN sends RB configuration to the remote UE. It may be transmitted by RRC signaling. It may be included in the RRCReconfiguration message and transmitted. It may be included in the RadioBearerConfig information and transmitted.
  • the MN sets the SL bearer between the remote UE and the relay UE for the remote UE.
  • the setting of the SL bearer may be a setting for modification of the SL bearer, or modification of the SL bearer.
  • Three examples of SL bearer setting information are disclosed. (1) Information about the RLC bearer of SL. (2) Information about SL ADP settings. (3) A combination of (1) and (2).
  • the information disclosed above may be applied as appropriate.
  • MN does not need to configure SL RB for remote UE. There is no need to send information about SL and RB. SL PDCP and SL SDAP may not be set. The MN sets up one SL RLC bearer for the DC for the remote UE.
  • MN sets DC for remote UE and/or sets SL bearer between remote UE and relay UE
  • MN sets relay UE received from SN and DC between SN and/or remote UE and relay UE
  • the PDU session may be modified.
  • the modification includes a PDU session modification procedure between MN and CN. Modification of the PDU session may appropriately apply the method disclosed above.
  • Data communication between the remote UE and the NW is performed 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.
  • RLC bearer DC bearer
  • the DC setting method disclosed above may be applied when the DC RLC bearer and the SL bearer are mapped in the relay UE. For example, it may be applied to the protocol example disclosed in FIG. 39 described above.
  • MN configures DC for relay UE and remote UE.
  • MN configures DC for RB with remote UE.
  • the RB is for communication between remote UE and MN.
  • the RB may be SRB and/or DRB.
  • the SRB may be SRB2.
  • the MN sets up the Uu RLC bearer for DC to the relay UE.
  • the MN sets up an SL bearer for DC between relay UE and remote UE.
  • the SL bearer for DC may be two SL bearers.
  • the two SL bearers may be the SL bearer for MN and the SL bearer for SN.
  • the relay UE should be in an RRC connection state with the MN.
  • the remote UE should be in an RRC connected state with the MN.
  • a remote UE configured with a DC connects to the CN via the MN in the C-plane.
  • the MN sends the SN a request to add the SN to the RB for communication between the remote UE and the MN.
  • the add request may be sent using Xn signaling.
  • An S-Node addition request message may be used.
  • the 17 items of information included in the SN addition request disclosed above may be applied as appropriate.
  • the SN performs settings for DC for relay UE.
  • the SN may use the information received from the MN to configure the DC for the relay UE.
  • the SN sends a response message to the SN's add request to the MN. If the SN performs DC setup, it sends an Add SN Request Acknowledgment message to the MN. Xn signaling should be used for transmission.
  • An S-Node addition request acknowledge message may be used as the SN addition request acknowledgment message. If the SN fails to perform DC configuration for the relay UE, it will send an SN Add Request Reject Response message to the MN. Xn signaling should be used for transmission.
  • An S-Node addition request reject message may be used as the SN addition request reject response message.
  • the information included in the SN addition request response message disclosed above may be appropriately applied to the information included in the SN addition request response message.
  • MN sends DC settings to the relay UE.
  • the information disclosed above may be appropriately applied to the information to be included in the DC settings.
  • the MN sets the SL bearer between the remote UE and the relay UE for the relay UE.
  • the setting of the SL bearer may be a setting for modification of the SL bearer, or modification of the SL bearer.
  • the information disclosed above may be appropriately applied to the setting information of the SL bearer.
  • the two SL RLC bearers for the DC may be the SL RLC bearer for the MN and the SL RLC bearer for the SN.
  • SL ADP can be one. Alternatively, multiple SL ADPs may be used. Two SL ADPs may be set as SL bearer settings for DC. In that case, it is better to use information about two SL ADP settings for DC.
  • the two SL ADPs for DC may be SL ADP for MN and SL ADP for SN.
  • the SL bearer settings may be included in the DC settings. You may include the setting information of SL bearer in the setting information for DC.
  • MN does not need to set SL RB for relay UE. There is no need to send information about SL and RB. SL PDCP and SL SDAP may not be set. The MN sets up two SL RLC bearers for the DC for the relay UE.
  • the MN sets DC for the relay UE and/or sets the SL bearer between the remote UE and the relay UE, and/or sets DC between the relay UE and the SN received from the SN and/or the remote UE and the relay UE You may use the setting information of the SL bearer between. It becomes possible to take into consideration the load status in the SN.
  • MN sends DC settings to the remote UE.
  • the information disclosed above may be appropriately applied to the information to be included in the DC settings.
  • the MN sets the SL bearer between the remote UE and the relay UE for the remote UE.
  • the setting of the SL bearer may be a setting for modification of the SL bearer, or modification of the SL bearer.
  • the information disclosed above may be appropriately applied to the setting information of the SL bearer.
  • the two SL RLC bearers for the DC may be the SL RLC bearer for the MN and the SL RLC bearer for the SN.
  • SL ADP can be one. Alternatively, multiple SL ADPs may be used. Two SL ADPs may be set as SL bearer settings for DC. In that case, it is better to use information about two SL ADP settings for DC.
  • the two SL ADPs for DC may be SL ADP for MN and SL ADP for SN.
  • the SL bearer settings may be included in the DC settings. You may include the setting information of SL bearer in the setting information for DC.
  • MN does not need to configure SL RB for remote UE. There is no need to send information about SL and RB. SL PDCP and SL SDAP may not be set. The MN sets up two SL RLC bearers for the DC for the remote UE.
  • MN sets DC for remote UE and/or sets SL bearer between remote UE and relay UE
  • MN sets relay UE received from SN and DC between SN and/or remote UE and relay UE
  • the PDU session may be modified.
  • the modification includes a PDU session modification procedure between MN and CN. Modification of the PDU session may appropriately apply the method disclosed above.
  • Data communication between the remote UE and the NW is performed 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.
  • RLC bearer DC bearer
  • the DC setting method disclosed above may be applied when the DC is terminated by the remote UE. For example, it may be applied to the protocol example disclosed in FIG. 40 described above.
  • the DC setting method when the relay UE is the DC termination and the DC setting method when the remote UE is the DC termination may be combined.
  • MN performs settings for DC for the relay UE. Thereby, 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. The MN then configures the remote UE for the DC. The MN also sets up two SL bearers for the DC between the relay UE and the remote UE. This maps the MN and SN RLC bearers between the MN and the relay UE to the MN and SN SL RLC bearers between the relay UE and the remote UE. A relay UE may perform this mapping at the PDU layer.
  • RB setting may be performed.
  • RB setting may be performed when modifying RB to a split bearer.
  • PDCP settings may be modified for split bearers.
  • DC bearer between the MN/SN and the relay UE and two SL RLC bearers for DC between the relay UE and the remote UE.
  • a DC setting method when the RLC bearer for DC and the SL bearer are mapped in the relay UE may be combined with a DC setting method when the remote UE is the termination of the DC.
  • the MN performs settings for DC for the relay UE.
  • the MN configures the remote UE for DC.
  • one or more DC RLC bearers between the MN and the relay UE are mapped to one SL RLC bearer between the relay UE and the remote UE.
  • the MN then configures the remote UE for the DC.
  • the MN also sets up two SL bearers for the DC between the relay UE and the remote UE. This maps the MN and SN RLC bearers between the MN and the relay UE to the MN and SN SL RLC bearers between the relay UE and the remote UE.
  • a relay UE may perform this mapping at the ADP layer.
  • RB setting may be performed.
  • RB setting may be performed when modifying RB to a split bearer.
  • PDCP settings may be modified for split bearers.
  • DC bearer between the MN/SN and the relay UE and two SL RLC bearers for DC between the relay UE and the remote UE.
  • a flexible DC setting is possible by combining the DC setting method when the relay UE is the DC termination and the DC setting method when the remote UE is the DC termination. For example, when the load is high in PC5 communication between the relay UE and the remote UE, DC setting may be performed when the relay UE is the terminal of the DC. Flexible DC setting is possible.
  • Embodiment 5 discloses another method for solving the problem described in the fourth embodiment.
  • the remote UE In communication between the remote UE and the NW via the relay UE, the remote UE connects with multiple base stations. The plurality may be two, for example. In communication between the remote UE and the NW via the relay UE, the remote UE connects with two base stations. A DC may be set in communication between the remote UE and the NW performed by the remote UE via the relay UE using the two base stations. A connection between a remote UE and a base station may be a direct connection or an indirect connection via a relay UE. Including indirect connection via at least one relay UE.
  • a remote UE connects with multiple gNBs for radio bearers for communication between the remote UE and the NW.
  • the radio bearer may be, for example, an SRB.
  • SRB0 and SRB1 communicate using one gNB, thereby making it possible to simplify the process of establishing communication.
  • the radio bearer may be, for example, the DRB. The communication quality of bearers for data communication can be improved.
  • FIG. 43 is a conceptual diagram showing an example of a case where the remote UE connects with two gNBs in communication between the remote UE and the NW via the relay UE, according to the fifth embodiment.
  • the remote UE connects with the MgNB via the relay UE#1 and directly connects with the SgNB.
  • Uu connects between the MgNB and the relay UE#1, and PC5 connects between the relay UE#1 and the remote UE.
  • Uu connects the SgNB and the remote UE.
  • MgNB and SgNB are connected by Xn.
  • the remote UE should be in an RRC connected state with the MgNB.
  • the relay UE#1 should be in an RRC connection state with the MgNB.
  • FIG. 44 is a conceptual diagram showing another example in which the remote UE connects to two gNBs in communication between the remote UE and the NW via the relay UE, according to the fifth embodiment.
  • the remote UE connects directly with the MgNB and connects with the SgNB via relay UE#2.
  • Uu connects between the MgNB and the remote UE.
  • the SgNB and the relay UE#2 are connected by Uu, and the relay UE#2 and the remote UE are connected by PC5.
  • MgNB and SgNB are connected by Xn.
  • the remote UE should be in an RRC connected state with the MgNB.
  • the relay UE#2 should be in an RRC connection state with the SgNB.
  • FIG. 45 is a conceptual diagram showing another example in which the remote UE connects to two gNBs in communication between the remote UE and the NW via the relay UE, according to the fifth embodiment.
  • the remote UE connects with the MgNB via the relay UE#1 and connects with the SgNB via the relay UE#2.
  • Uu connects between the MgNB and the relay UE#1
  • PC5 connects between the relay UE#1 and the remote UE.
  • the SgNB and the relay UE#2 are connected by Uu, and the relay UE#2 and the remote UE are connected by PC5.
  • MgNB and SgNB are connected by Xn.
  • the remote UE should be in an RRC connected state with the MgNB.
  • the relay UE#1 should be in an RRC connection state with the MgNB.
  • the relay UE#2 should be in an RRC connection state with the SgNB.
  • FIG. 46 is a diagram showing a protocol stack when the remote UE connects with two gNBs in communication between the remote UE and the NW via the relay UE, according to the fifth embodiment. A case is shown where the remote UE connects with the MgNB via the relay UE#1 and directly connects with the SgNB. It shows the U-Plane.
  • MN and SN have the Uu protocol for DC.
  • the Uu protocol is SDAP, PDCP, RLC, MAC, PHY.
  • ADP may be configured as a sublayer of RLC.
  • FIG. 46 shows both an MN termination bearer and an SN termination bearer, as well as an MCG bearer, an SCG bearer and a split bearer as bearers for DC. Protocols corresponding to these bearers are configured.
  • PDCP may be configured one for MN-terminated bearers and one for SN-terminated bearers. It may be possible to set these bearers in the setting of the DC.
  • the relay UE#1 has the Uu protocol for the MN.
  • the Uu protocol is RLC, MAC, PHY.
  • ADP may be configured as a sublayer of RLC.
  • the bearers for the MN are MCG bearers or split bearers. Protocols corresponding to these bearers are configured.
  • the relay UE#1 has the PC5 protocol between remote UEs.
  • the protocol of the PC5 may be for MN.
  • the protocols of the PC5 are 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, for example, a mapping function between the Uu bearer and the PC5 bearer.
  • PC5 ADP may be configured as a sublayer of PC5 RLC.
  • PC5 SDAP and PC5 PDCP may be omitted.
  • the remote UE has a protocol of PC5 between relay UE#1.
  • the protocol of the PC5 may be for MN. Similar to the relay UE#1, the protocol of the PC5 is PC5 RLC, PC5 MAC, PC5 PHY.
  • a PC5 ADP may be configured above the PC5 RLC.
  • PC5 SDAP and PC5 PDCP may be omitted.
  • the remote UE has a Uu protocol with the SN.
  • the Uu protocol is RLC, MAC, PHY.
  • a bearer for SN is an SCG bearer or a split bearer.
  • the remote UE has Uu protocol between MN and/or SN.
  • the Uu protocol is SDAP and PDCP for DC.
  • PDCP or ADP of PC5 for MN and PDCP of Uu are connected, and RLC of Uu and PDCP of Uu for SN are connected.
  • PDCP may be configured one for MN-terminated bearers and one for SN-terminated bearers. DC is terminated at the remote UE.
  • a RB is set up between the MN and the remote UE.
  • a bearer for MN is set between MN and relay UE#1.
  • the bearer for MN is MCG bearer or split bearer.
  • the MCG bearer or split bearer may be an RLC bearer. It may be an RLC channel.
  • One SL bearer is set between the relay UE#1 and the remote UE.
  • the SL bearer should be the SL RLC bearer for the MN. It may be an SL RLC channel.
  • a bearer for the SN is set up between the SN and the remote UE.
  • a bearer for SN is an SCG bearer or a split bearer.
  • the SCG bearer or split bearer may be an RLC bearer. It may be an RLC channel.
  • MN and SN have a function of mapping RBs between NW and remote UE to RLC bearer of Uu for DC in communication from NW to remote UE.
  • An RLC bearer of Uu for the DC includes an MCG bearer, an SCG bearer, or a split bearer.
  • the number of remote UEs connected to the relay UE#1 is not limited to one, and may be plural.
  • the number of RBs between the remote UE and the NW is not limited to one, and may be plural.
  • one or more RBs of the remote UE connected to the relay UE#1 and/or one or more RBs between the remote UE and the NW may be mapped to the Uu RLC bearer for the DC .
  • the aforementioned functions may be included in Uu's ADP configured in the MN.
  • the ADP may aggregate the functions when the DC is configured and when it is not configured. In this case, the configuration of the MN can be facilitated.
  • the MN may add the identifier of the remote UE and the identifier of the RB between the remote UE and the NW in communication from the NW to the remote UE.
  • the RB ID may be the SRB ID if the RB is an SRB.
  • the RB ID may be the DRB ID if the RB is a DRB.
  • the MN may add information about bearers used for the DC in communication from the NW to the remote UE.
  • Information about the bearer used for the DC includes, for example, an identifier indicating the termination 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 termination and type of the bearer used for the DC.
  • the aforementioned additional functions may be included in Uu's ADP configured in the MN.
  • the ADP may aggregate the functions when the DC is configured and when it is not configured. In this case, the configuration of the MN can be facilitated.
  • the relay UE#1 has a function of mapping the RLC bearer of Uu for MN to the RLC bearer of PC5 for MN in communication from the NW to the remote UE.
  • the mapping may use the remote UE identity, RB identity added in the MN's ADP.
  • the mapping may use information about the bearer used for the DC attached at the MN.
  • relay UE#1 can map the MCG bearer or split bearer for MN to the RLC bearer of PC5 for MN.
  • the aforementioned functions may be included in Uu's ADP configured in relay UE#1.
  • the ADP may aggregate the functions when the DC is configured and when it is not configured. In this case, the configuration of the relay UE#1 can be simplified.
  • the relay UE #1 When the relay UE #1 is mapped to the RLC bearer of PC5, it may delete some or all of the remote UE identifier added by the MN, the RB identifier, information about the bearer used for DC, and the like. Some or all of this identifier or information may not be added in the mapping of PC5 to the RLC bearer to the remote UE.
  • the remote UE In communication from the NW to the remote UE, the remote UE has a function of mapping the RLC bearer of PC5 for MN and the RLC bearer of Uu for SN to RBs between the NW and remote UE.
  • the mapping may use the remote UE identifier, RB identifier added by the MN.
  • the mapping may use information about the bearer used for the DC attached at the MN.
  • the remote UE In communication from the remote UE to the NW, the remote UE has a function of mapping RBs between the NW and the remote UE to the RLC bearer of PC5 for DC and the RLC bearer of Uu.
  • the PC5 RLC bearer for the DC is the PC5 RLC bearer for the MN.
  • the PC5 RLC bearer for the MN is an MCG bearer or a split bearer.
  • the Uu RLC bearer for the DC is the Uu RLC bearer for the SN.
  • An SCG bearer or a split bearer is an RLC bearer of Uu for SN.
  • the remote UE may add the identifier of the RB between the remote UE and the NW and the identifier of the base station in communication from the NW to the remote UE.
  • There may be multiple base stations. For example, it may be added when a relay UE connects to multiple base stations. Information indicating whether or not there is a plurality of base stations or information indicating whether or not there are a plurality of identifiers of the base stations may be added.
  • the identifier of the base station may be the identifier of MN and/or SN. For example, it may be applied when DC is set. By doing so, even when the relay UE transmits to a plurality of base stations, it is possible to recognize the RB for communication between the destination base station, the remote UE and the NW.
  • the remote UE may add information about bearers used for the DC in communication from the remote UE to the NW.
  • Information about the bearer used for the DC includes, for example, an identifier indicating the termination 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 termination and type of bearer used for DC.
  • the aforementioned additional functions may be included in the SL ADP configured in the remote UE. Functions for when DC is set and when DC is not set may be aggregated in SL ADP. Configuration of the remote UE can be facilitated.
  • the relay UE#1 has a function of mapping the PC5 RLC bearer for the MN to the Uu RLC bearer for the MN in communication from the remote UE to the NW.
  • An MCG bearer or a split bearer is an RLC bearer of Uu for the MN.
  • the mapping may use the base station identifier, RB identifier, etc. added by the remote UE.
  • Information about the bearer used for the DC added by the remote UE may be used for the mapping.
  • the number of remote UEs connected to the relay UE#1 is not limited to one, and may be plural.
  • the aforementioned functions may be included in Uu's ADP configured in relay UE#1.
  • the ADP may aggregate the functions when the DC is configured and when it is not configured. In this case, the configuration of the relay UE#1 can be simplified.
  • the relay UE #1 may delete some or all of the remote UE identifier added by the remote UE, the RB identifier, the information about the bearer used for the DC, etc. when mapping to the RLC bearer of Uu. Some or all of this identifier or information may not be added in the mapping of Uu to RLC bearer to MN.
  • the relay UE #1 may add the identifier of the remote UE and the identifier of the RB between the remote UE and the NW in communication from the remote UE to the NW.
  • the RB ID may be the SRB ID if the RB is an SRB.
  • the RB ID may be the DRB ID if the RB is a DRB.
  • the aforementioned additional functions may be included in the Uu ADP for the MN configured in the relay UE#1.
  • the ADP may aggregate the functions when the DC is configured and when it is not configured. In this case, the configuration of the relay UE can be facilitated.
  • MN and SN have the function of mapping Uu RLC bearer for DC to RB between NW and remote UE in communication from remote UE to NW.
  • the number of remote UEs connected to the relay UE#1 is not limited to one, and may be plural.
  • the number of RBs between the remote UE and the NW is not limited to one, and may be plural.
  • the Uu RLC bearer for DC may be mapped to one or more RBs of the remote UE connected to the relay UE#1 and/or one or more RBs between the remote UE and the NW.
  • the remote UE identifier added by ADP of Uu for MN of remote UE or relay UE#1, RB identifier, information about bearer used for DC, and the like may be used.
  • MN and SN it becomes possible for MN and SN to transfer the MCG bearer, SCG bearer, or split bearer for DC to PDCP of RB for communication between remote UE and NW.
  • the aforementioned functions may be included in Uu's ADP configured in MN and SN.
  • the ADP may aggregate the functions when the DC is configured and when it is not configured. In this case, the configuration of MN and SN can be facilitated.
  • RRC should be provided instead of SDAP in the MN and remote UE. It is preferable to provide RRC corresponding to SRB. If DC is configured in SRB, only MN termination bearer may be configured. DC of SRB is enabled.
  • a remote UE connected to two gNBs can communicate between NWs via a relay UE.
  • This embodiment discloses a method for setting a DC in which a remote UE connects with two gNBs.
  • the remote UE connects with the MgNB via the relay UE #1 and directly connects with the SgNB.
  • MN configures the DC for the remote UE.
  • MN configures DC for RB with remote UE.
  • the RB may be for communication between remote UE and MN.
  • the RB may be SRB and/or DRB.
  • the SRB may be SRB2.
  • Uu's RLC bearer for the DC may be the RLC bearer to/from SN.
  • the MN sets up the Uu RLC bearer for DC between the MN and the relay UE#1. Used for setting DC for RB between MN and remote UE.
  • a Uu RLC bearer for DC if there is no modification from the existing Uu RLC bearer, no new setting may be performed.
  • the MN sets up 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 the SL bearer for the MN.
  • the SL bearer may be an SL RLC bearer.
  • the relay UE#1 should be in an RRC connection state with the MN.
  • the remote UE should be in an RRC connected state with the MN.
  • the MN may also initiate DC configuration for the remote UE when the remote UE is in RRC connection with the MN.
  • a remote UE configured with a DC connects to the CN via the MN in the C-plane.
  • the MN sends the SN a request to add the SN to the RB for communication between the remote UE and the MN.
  • the add request may be sent using Xn signaling.
  • An S-Node addition request message may be used.
  • the 17 information examples included in the SN addition request disclosed above may be applied as appropriate.
  • the relay UE in the information example may be replaced with the relay UE #1.
  • the MN can send an SN addition request for the DC to the SN. Also, by receiving the 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 for the DC to the remote UE.
  • the SN performs settings for DC for relay UE.
  • the SN sends a response message to the SN's add request to the MN. If the SN performs DC setup, it sends an Add SN Request Acknowledgment message to the MN. Xn signaling should be used for transmission.
  • An S-Node addition request acknowledge message may be used as the SN addition request acknowledgment message. If the SN fails to perform DC configuration for the relay UE, it will send an SN Add Request Reject Response message to the MN. Xn signaling should be used for transmission.
  • An S-Node addition request reject message may be used as the SN addition request reject response message.
  • Information included in the SN addition request response message disclosed in the fourth embodiment may be applied as appropriate to the information included in the SN addition request response message.
  • the MN transmits DC settings to the relay UE#1.
  • Five examples of information to be included in the settings for DC are disclosed.
  • (1) is information about RBs for communication between remote UE and MN.
  • the MN does not set the RB as the DC setting for the relay UE#1.
  • SRB setting is not performed even when the RB for which DC is set is SRB.
  • DRB is not set even when the RB for which DC is set is DRB.
  • the information about RBs in (1) may be, for example, only RB identifiers.
  • the MN does not need to configure the relay UE#1 for SCG. Since the relay UE #1 is not connected to the SN in the DC of this example, the relay UE #1 does not need to receive information regarding the SCG.
  • the MN does not have to transmit the identifier of the SN to the relay UE#1. Since the relay UE #1 is not connected to the SN in the DC of this example, the relay UE #1 does not need to receive the identifier of the SN.
  • the MN sets up an SL bearer between the remote UE and the relay UE#1 for the relay UE#1.
  • the setting of the SL bearer may be a setting for modification of the SL bearer, or modification of the SL bearer.
  • Three examples of SL bearer setting information are disclosed. (1) Information about the RLC bearer of SL. (2) Information about SL ADP settings. (3) A combination of (1) and (2).
  • the setting information of the SL bearer it is preferable to appropriately apply the setting information example of the SL bearer disclosed above.
  • the MN does not need to set SL RB for relay UE#1. There is no need to send information about SL and RB. SL PDCP and SL SDAP may not be set.
  • the MN may configure one SL bearer for the DC for the relay UE#1.
  • the setting of the SL bearer for the DC may be the setting of the SL bearer for the MN.
  • the MN When the MN performs DC settings for the relay UE#1 and/or SL bearer settings between the remote UE and the relay UE#1, the MN receives the setting information for the DC between the remote UE and the SN from the SN. may be used. It becomes possible to take into consideration the load status in the SN.
  • MN sends configuration for DC to remote UE.
  • Five examples of information to be included in the settings for DC are disclosed.
  • (2) is information about Uu's RLC bearer for DC.
  • the MN may not configure the remote UE for MCG. Since the remote UE connects with the MN via the relay UE#1 in the DC, the remote UE does not need to receive information about the MCG.
  • the MN sets up an SL bearer between the remote UE and the relay UE#1 for the remote UE.
  • the setting of the SL bearer may be a setting for modification of the SL bearer, or modification of the SL bearer.
  • Three examples of SL bearer setting information are disclosed. (1) Information about the RLC bearer of SL. (2) Information about SL ADP settings. (3) A combination of (1) and (2).
  • the setting information of the SL bearer it is preferable to appropriately apply the setting information example of the SL bearer disclosed above.
  • RLC bearer for the SL.
  • an RLC bearer of SL for MN may be set.
  • the ADP setting of the SL for DC the ADP of SL for MN may be set.
  • the SL bearer settings may be included in the DC settings. You may include the setting information of SL bearer in the setting information for DC.
  • MN does not need to configure SL RB for remote UE. There is no need to send information about SL and RB. SL PDCP and SL SDAP may not be set.
  • the MN may configure one SL bearer for the DC to the remote UE.
  • the setting of the SL bearer for the DC may be the setting of the SL bearer for the MN.
  • the MN uses the setting information for the DC between the remote UE and the SN received from the SN when setting the DC for the remote UE and/or setting the SL bearer between the remote UE and the relay UE#1. good too. It becomes possible to take into consideration the load status in the SN.
  • the PDU session may be modified.
  • the modification includes a PDU session modification procedure between MN and CN. Modification of the PDU session may appropriately apply the method disclosed above.
  • Data communication between the remote UE and NW includes the MCG bearer between the remote UE and MN via relay UE#1, the SCG bearer between remote UE and SN, the remote UE and MN via relay UE#1, and the remote It is done using a split bearer between UE and SN.
  • FIG. 47 is a sequence diagram showing an example of a DC setting method in which a remote UE connects with two gNBs, according to the fifth embodiment.
  • a case is disclosed where the remote UE connects with the MgNB via the relay UE#1 and directly connects with the SgNB.
  • steps common to those in FIG. 41 are assigned the same step numbers, and common descriptions are omitted.
  • step ST5001 data communication is performed among the remote UE, relay UE#1, MN, and UPF.
  • the MN decides to set up a DC for the remote UE. For example, the MN configures neighboring gNB measurements for the remote UE. The remote UE performs the set measurements and reports the measurement results to the MN. In addition, the MN may configure measurements of neighboring relay UEs for the remote UE. The remote UE may perform the configured measurements and report the measurement results to the MN. MN determines SN to be used for DC from the measurement result.
  • the MN transmits an SN addition request message to the SN decided to be used for the DC.
  • MN requests SN to be added as SN for DC to remote UE.
  • the Add SN Request message is sent 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 information example of the SN addition request disclosed above.
  • the SN that receives the SN addition request message from the MN, from the information of the SN addition request, the remote UE that performs the DC setting, the information on the communication between the remote UE that performs the DC setting and the NW, the requested bearer termination, the requested DC recognizing the bearer type, etc., and making settings for DC to the remote UE.
  • the configuration for the DC may for example be the RRC configuration between the SN and the remote UE.
  • the SN transmits an SN addition request response message to the MN. This example sends an acknowledgment.
  • An S-Node addition request acknowledge message may be used as the SN addition request response message.
  • the SN Add Request Response message may contain the RRC configuration between the SN and the remote UE.
  • the MN Upon receiving the SN addition request response message, the MN recognizes that the SN has performed DC configuration for the remote UE. Also, the MN is aware of the RRC configuration between the SN and the remote UE.
  • the MN notifies the SN of the Xn-U address indication message. For example, MN sets an address to be used for DC between MN and SN and transmits it to SN in step ST4404. This enables the MN and SN to share the address used for the DC and to transmit and receive data between the MN and SN.
  • the MN transmits DC settings and SL bearer settings to the relay UE#1.
  • the SL bearer configuration may be transmitted together with the DC configuration, or the SL bearer configuration may be included in the DC configuration and transmitted. Alternatively, the setting for DC and the setting for SL bearer may be transmitted separately.
  • the transmission uses RRC signaling. Configuration may be performed using RRC reconfiguration messages.
  • the DC settings may include the information example of the DC settings disclosed above.
  • the SL bearer configuration may include the SL bearer configuration information disclosed above.
  • the relay UE#1 that has made these settings transmits a DC setting response and an SL bearer setting response to the MN in step ST5007.
  • the transmission uses RRC signaling.
  • An RRC reconfiguration complete message may be used.
  • the MN that has received the DC setup response and SL bearer setup response recognizes that the relay UE#1 has completed DC setup and SL bearer setup.
  • step ST5006 the MN transmits DC settings and SL bearer settings to the remote UE.
  • the SL bearer configuration may be transmitted together with the DC configuration, or the SL bearer configuration may be included in the DC configuration and transmitted. Alternatively, the setting for DC and the setting for SL bearer may be transmitted separately.
  • the transmission uses RRC signaling.
  • An RRC reconfiguration message may be used.
  • the DC settings may include the information example of the DC settings disclosed above.
  • the RRC setting information received from the SN may be used as the SCG setting of the DC setting information.
  • the SL bearer configuration may include the SL bearer configuration information disclosed above.
  • the remote UE that has made these settings transmits a DC setting response and an SL bearer setting response to the MN in step ST5008.
  • the transmission uses RRC signaling.
  • An RRC reconfiguration complete message may be used.
  • the MN receiving the DC setup response and SL bearer setup response recognizes that the remote UE has completed the DC setup and SL bearer setup.
  • the MN transmits an SN setting complete message to the SN.
  • the transmission uses Xn signaling.
  • An S-Node reconfiguration complete message may be sent.
  • the SN recognizes that the MN and remote UE have completed the SN configuration for the DC.
  • step ST4408 the remote UE starts RA processing and communicates with the SN while maintaining communication with the MN.
  • step ST4409 the MN transfers the SN status to the SN, and in step ST4410, transfers the data from the UPF to the SN.
  • step ST4410 transfers the data from the UPF to the SN.
  • the path between UPF and gNB needs to be changed from MN to SN.
  • the path update process of step ST4420 is performed.
  • step ST5015 data communication is performed among the remote UE, SN, and UPF.
  • DC is performed between MN and SN via remote UE and relay UE#1.
  • remote UE For example, for SN-terminated SCG bearers, data communication takes place between remote UE, SN and UPF.
  • data communication is performed between the MN and UPF via the remote UE, SN, and relay UE#1.
  • data communication is performed between MN, SN and UPF via remote UE and relay UE#1.
  • MN terminated split bearer data communication takes place between MN, UPF via remote UE, SN, relay UE.
  • data communication is performed between MN, SN and UPF via remote UE and relay UE#1.
  • RRC signaling may be performed between the SN and the remote UE.
  • the RRC signaling may be performed using SRB3.
  • 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.
  • An RRC message using SRB3 may be, for example, a message regarding SN.
  • it may be a message such as SCG bearer setting change, SN measurement report, information transmission regarding SCG bearer filer.
  • the RRC message can be directly communicated between the SN and the remote UE without going through the MN, so that the amount of signaling can be reduced and the delay can be reduced.
  • FIG. 48 is a diagram showing another protocol stack configuration method when the remote UE connects to two gNBs in communication between the remote UE and the NW via the relay UE, according to the fifth embodiment. A case is shown where the remote UE connects directly to the MgNB and connects to the SgNB via the relay UE#2. It shows the U-Plane.
  • MN and SN have the Uu protocol for DC.
  • the Uu protocol is SDAP, PDCP, RLC, MAC, PHY.
  • ADP may be configured as a sublayer of RLC.
  • FIG. 48 shows both the MN termination bearer and the SN termination bearer as bearers for DC. Also, the MCG bearer, SCG bearer and split bearer are shown together. Protocols corresponding to these bearers are configured.
  • PDCP may be configured one for MN-terminated bearers and one for SN-terminated bearers. It may be possible to set these bearers in the setting of the DC.
  • the relay UE#2 has the Uu protocol for SN.
  • the Uu protocol is RLC, MAC, PHY.
  • ADP may be configured as a sublayer of RLC.
  • the bearers for the MN are MCG bearers or split bearers. Protocols corresponding to these bearers are configured.
  • the relay UE#2 has the PC5 protocol between remote UEs.
  • the protocol of the PC5 may be used for SN.
  • the protocols of the PC5 are 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.
  • PC5 ADP may be configured as a sublayer of PC5 RLC.
  • PC5 SDAP and PC5 PDCP may be omitted.
  • the remote UE has a protocol of PC5 between relay UE#2.
  • the protocol of the PC5 may be used for SN. Similar to the relay UE#2, the protocol of the PC5 is PC5 RLC, PC5 MAC, PC5 PHY.
  • a PC5 ADP may be configured above the PC5 RLC.
  • PC5 SDAP and PC5 PDCP may be omitted.
  • the remote UE has a Uu protocol with the MN.
  • the Uu protocol is RLC, MAC, PHY. For MN, it is for SCG bearer or split bearer.
  • the remote UE has Uu protocol between MN and/or SN.
  • the Uu protocol is SDAP and PDCP for DC.
  • PDCP or ADP of PC5 for SN is connected with PDCP of Uu, and RLC of Uu for MN and PDCP of Uu are connected.
  • PDCP may be configured one for MN-terminated bearers and one for SN-terminated bearers.
  • DC is terminated at the remote UE.
  • a RB is set up between the MN and the remote UE.
  • a bearer for SN is set between SN and relay UE#2.
  • a bearer for SN is an SCG bearer or a split bearer.
  • the SCG bearer or split bearer may be an RLC bearer. It may be an RLC channel.
  • One SL bearer is set between the relay UE#2 and the remote UE.
  • the SL bearer should be an SL RLC bearer for SN. It may be an SL RLC channel.
  • a bearer for the MN is set up between the MN and the remote UE.
  • the bearer for MN is MCG bearer or split bearer.
  • the MCG bearer or split bearer may be an RLC bearer. It may be an RLC channel.
  • MN and SN have a function of mapping RBs between NW and remote UE to RLC bearer of Uu for DC in communication from NW to remote UE.
  • An RLC bearer of Uu for the DC includes 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, and may be plural.
  • the number of RBs between the remote UE and the NW is not limited to one, and may be plural.
  • RBs of one or more remote UEs connected to relay UE#2 and/or one or more RBs between the remote UE and the NW may be mapped to the RLC bearer of Uu for DC.
  • the aforementioned functions may be included in Uu's ADP configured in the SN.
  • the ADP may aggregate the functions when the DC is configured and when it is not configured. In this case, the configuration of SN can be facilitated.
  • the SN may add the identifier of the remote UE and the identifier of the RB between the remote UE and the NW in communication from the NW to the remote UE.
  • the RB ID may be the SRB ID if the RB is an SRB.
  • the RB ID may be the DRB ID if the RB is a DRB.
  • the SN may add information about bearers used for the DC in communication from the NW to the remote UE.
  • Information about the bearer used for the DC includes, for example, an identifier indicating the termination 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 termination, type, etc. of the bearer used for the DC.
  • the aforementioned additional functions may be included in Uu's ADP configured in SN.
  • the ADP may aggregate the functions when the DC is configured and when it is not configured. In this case, the configuration of SN can be facilitated.
  • the relay UE#2 has a function of mapping the RLC bearer of Uu for SN to the RLC bearer of PC5 for SN in communication from the NW to the remote UE.
  • the mapping may use the remote UE identifier and RB identifier added in the SN's ADP.
  • Information about the bearer used for the DC attached in the SN may be used for the mapping.
  • relay UE#2 can map the SCG bearer or split bearer for SN to the RLC bearer of PC5 for SN.
  • the aforementioned functions may be included in Uu's ADP configured in relay UE#2.
  • the ADP may aggregate the functions when the DC is configured and when it is not configured. In this case, the configuration of the relay UE#2 can be facilitated.
  • the relay UE #2 When the relay UE #2 is mapped to the RLC bearer of PC5, it may delete some or all of the remote UE identifier added by SN, the RB identifier, information about the bearer used for DC, and the like. Some or all of this identifier or information may not be added in the mapping of PC5 to the RLC bearer to the remote UE.
  • the remote UE In communication from the NW to the remote UE, the remote UE has a function of mapping the RLC bearer of Uu for MN and the RLC bearer of PC5 for SN to RBs between the NW and remote UE.
  • a remote UE identifier and an RB identifier attached by SN may be used for the mapping.
  • Information about the bearer used for the DC attached in the SN may be used for the mapping.
  • the remote UE In communication from the remote UE to the NW, the remote UE has a function of mapping RBs between the NW and the remote UE to the RLC bearer of Uu for DC and the RLC bearer of PC5.
  • the Uu RLC bearer for the DC is the Uu RLC bearer for the MN.
  • the Uu RLC bearer for the MN is an MCG bearer or a split bearer.
  • the PC5 RLC bearer for the DC is the PC5 RLC bearer for the SN.
  • An SCG bearer or a split bearer is available as an RLC bearer of PC5 for SN.
  • the remote UE may add the identifier of the RB between the remote UE and the NW and the identifier of the base station in communication from the NW to the remote UE.
  • There may be multiple base stations. For example, it may be added when a relay UE connects to multiple base stations. Information indicating whether or not there is a plurality of base stations or information indicating whether or not there are a plurality of identifiers of the base stations may be added.
  • the identifier of the base station may be the identifier of MN and/or SN. For example, it may be applied when DC is set. By doing so, even when the relay UE transmits to a plurality of base stations, it is possible to recognize the RB for communication between the destination base station, the remote UE and the NW.
  • the remote UE may add information about bearers used for the DC in communication from the remote UE to the NW.
  • Information about the bearer used for the DC includes, for example, an identifier indicating the termination 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 termination and type of bearer used for DC.
  • the aforementioned additional functions may be included in the SL ADP configured in the remote UE. Functions for when DC is set and when DC is not set may be aggregated in SL ADP. Configuration of the remote UE can be facilitated.
  • the relay UE#2 has a function of mapping the RLC bearer of PC5 for SN to the RLC bearer of Uu for SN in communication from the remote UE to the NW.
  • An SCG bearer or a split bearer is an RLC bearer of Uu for this SN.
  • the identifier of the base station added by the remote UE, the RB identifier, the information about the bearer used for the DC, and the like may be used.
  • the number of remote UEs connected to relay UE#2 is not limited to one, and may be plural.
  • the aforementioned functions may be included in Uu's ADP configured in relay UE#2.
  • the ADP may aggregate the functions when the DC is configured and when it is not configured. In this case, the configuration of the relay UE#2 can be facilitated.
  • the relay UE #2 may delete some or all of the remote UE identifier added by the remote UE, the RB identifier, information about the bearer used for the DC, etc. when mapping to the RLC bearer of Uu. Some or all of this identifier or information may not be added in the mapping of Uu to SN to RLC bearer.
  • the relay UE#2 may add the identifier of the remote UE and the identifier of the RB between the remote UE and the NW in communication from the remote UE to the NW.
  • the RB ID may be the SRB ID if the RB is an SRB.
  • the RB ID may be the DRB ID if the RB is a DRB.
  • the SN can recognize the remote UE of the transmission source and the RB for communication between the remote UE and the NW.
  • the aforementioned additional function may be included in the Uu ADP for SN configured in the relay UE#2.
  • the ADP may aggregate the functions when the DC is configured and when it is not configured. In this case, the configuration of the relay UE#2 can be facilitated.
  • MN and SN have the function of mapping Uu RLC bearer for DC to RB between NW and remote UE in communication from remote UE to NW.
  • the number of remote UEs connected to relay UE#2 is not limited to one, and may be plural.
  • the number of RBs between the remote UE and the NW is not limited to one, and may be plural.
  • the Uu RLC bearer for DC may be mapped to one or more RBs of the remote UE connected to the relay UE#2 and/or one or more RBs between the remote UE and the NW.
  • the remote UE identifier added by ADP of Uu for the SN of the remote UE or relay UE #2, the RB identifier, information about the bearer used for the DC, and the like may be used.
  • MN and SN it becomes possible for MN and SN to transfer the MCG bearer, SCG bearer, or split bearer for DC to PDCP of RB for communication between remote UE and NW.
  • the aforementioned functions may be included in Uu's ADP configured in MN and SN.
  • the ADP may aggregate the functions when the DC is configured and when it is not configured. In this case, the configuration of MN and SN can be facilitated.
  • RRC should be provided instead of SDAP in the MN and remote UE. It is preferable to provide RRC corresponding to SRB. If DC is configured in SRB, only MN termination bearer may be configured. DC of SRB is enabled.
  • a remote UE connected to two gNBs can communicate between NWs via a relay UE.
  • This embodiment discloses a method for setting a DC in which a remote UE connects with two gNBs.
  • the remote UE connects directly to the MgNB and connects to the SgNB via the relay UE#2.
  • MN configures the DC for the remote UE.
  • MN configures DC for RB with remote UE.
  • the RB may be for communication between remote UE and MN.
  • the RB may be SRB and/or DRB.
  • the SRB may be SRB2.
  • Uu's RLC bearer for the DC may be the RLC bearer to/from the MN.
  • the MN sets up the Uu RLC bearer for DC between the SN and the relay UE#2. Used for setting DC for RB between MN and remote UE.
  • a Uu RLC bearer for DC if there is no modification from the existing Uu RLC bearer, no new setting may be performed.
  • the MN sets up 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.
  • the relay UE#2 should be in the SN and RRC connection state.
  • the remote UE should be in an RRC connected state with the MN.
  • the MN may also initiate DC configuration for the remote UE when the remote UE is in RRC connection with the MN.
  • a remote UE configured with a DC connects to the CN via the MN in the C-plane.
  • the MN sends the SN a request to add the SN to the RB for communication between the remote UE and the MN.
  • the add request may be sent using Xn signaling.
  • An S-Node addition request message may be used.
  • the 17 information examples included in the SN addition request disclosed above may be applied as appropriate.
  • the relay UE in the information example may be replaced with relay UE #2.
  • the MN and the remote UE are connected without going through the relay UE#2, there may be no setting information between the MN and the relay UE#2.
  • the MN does not send (4), (7), and (9) to the SN among the 17 examples of information included in the SN addition request disclosed above.
  • the information on the relay UE in (1) is information indicating which relay UE the SN goes through in order to perform DC settings with the remote UE. may include It may also include information about the settings of the relay UE. Also, it may include the measurement result of the relay UE#2 by the remote UE. In addition, the result of SN measurement by relay UE#2 may be included.
  • the MN can send an SN addition request for the DC to the SN. Also, by receiving the SN addition request from the MN, the SN becomes able to recognize, for example, which DC is for which remote UE, which relay UE is used to connect to the remote UE, and the like.
  • the SN may use the information received from the MN to configure for the DC to the remote UE via the relay UE.
  • the setting for DC for the remote UE via the relay UE may be the setting for DC between the SN and the relay UE.
  • the SN performs DC settings for the remote UE via the relay UE.
  • the SN sends a response message to the SN's add request to the MN. If the SN performs DC setup, it sends an Add SN Request Acknowledgment message to the MN. Xn signaling should be used for transmission.
  • An S-Node addition request acknowledge message may be used as the SN addition request acknowledgment message. If the SN fails to perform DC configuration for the relay UE, it will send an SN Add Request Reject Response message to the MN. Xn signaling should be used for transmission.
  • An S-Node addition request reject message may be used as the SN addition request reject response message.
  • the information included in the SN addition request response message disclosed above may be appropriately applied to the information included in the SN addition request response message.
  • the SN transmits DC settings to the relay UE#2.
  • Five examples of information to be included in the settings for DC are disclosed.
  • (1) is information about RBs for communication between remote UE and MN.
  • SN does not set RB as DC setting for relay UE#2.
  • SRB setting is not performed even when the RB for which DC is set is SRB.
  • DRB is not set even when the RB for which DC is set is DRB.
  • the information about RBs in (1) may be, for example, only RB identifiers.
  • the SN does not need to set the relay UE#2 for MCG. Since the relay UE#2 is not connected to the MN in the DC of this example, the relay UE#2 does not need to receive information regarding the MCG.
  • the SN sets up an SL bearer between the remote UE and the relay UE#2 for the 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 SL bearer configuration may be a configuration for SL bearer modification.
  • Three examples of SL bearer setting information are disclosed. (1) Information about the RLC bearer of SL. (2) Information about SL ADP settings. (3) A combination of (1) and (2).
  • the setting information of the SL bearer it is preferable to appropriately apply the setting information example of the SL bearer disclosed above.
  • the SN does not need to set SL RB for relay UE#2. There is no need to send information about SL and RB. SL PDCP and SL SDAP may not be set.
  • the SN may configure one SL bearer for the DC for the relay UE#2.
  • the setting of the SL bearer for the DC may be the setting of the SL bearer for the SN.
  • MN sends configuration for DC to remote UE.
  • Five examples of information to be included in the settings for DC are disclosed.
  • (2) is information about Uu's RLC bearer for DC.
  • the MN may not configure the remote UE for SCG. Since the remote UE connects with the SN via the relay UE#2 in the DC, the remote UE does not need to receive information about the SCG.
  • the MN transmits to the remote UE the setting of the SL bearer between the remote UE and the 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 SL bearer configuration may be a configuration for SL bearer modification. Three examples of SL bearer setting information are disclosed. (1) Information about the RLC bearer of SL. (2) Information about SL ADP settings. (3) A combination of (1) and (2).
  • the setting information of the SL bearer it is preferable to appropriately apply the setting information example of the SL bearer disclosed above.
  • RLC bearer for the SL.
  • an RLC bearer of SL for SN may be set.
  • the ADP setting of the SL for DC the ADP of SL for SN may be set.
  • the SL bearer settings may be included in the DC settings. You may include the setting information of SL bearer in the setting information for DC.
  • MN does not need to configure SL RB for remote UE. There is no need to send information about SL and RB. SL PDCP and SL SDAP may not be set.
  • the MN may configure one SL bearer for the DC to the remote UE.
  • the setting of the SL bearer for the DC may be the setting of the SL bearer for the MN.
  • the MN configures for DC for remote UE and/or configures for DC between relay UE#2 and SN received from SN when configuring SL bearer between remote UE and relay UE#2 and/or or
  • the SL bearer setting information between the remote UE and relay UE#2 may be used. It becomes possible to take into consideration the load status in the SN.
  • the MN may set the SL bearer setting information between the remote UE and the relay UE#2 to be the same as the SL bearer setting information between the remote UE and the relay UE#2 that the SN sent to the relay UE#2. .
  • the setting of the SL bearer becomes the same in the remote UE and the relay UE#2, and malfunctions in SL communication can be reduced.
  • the MN may transmit information regarding the relay UE#2 to the remote UE.
  • Information about the relay UE#2 may be included in the setting of the SL bearer between the remote UE and the relay UE#2.
  • the information about relay UE#2 may be, for example, the identifier of relay UE#2. For example, it may be the identifier of the SN to which relay UE#2 connects. By doing so, the remote UE can recognize the relay UE#2 connected for the DC.
  • the remote UE Upon receiving the SL bearer setting information for DC from the MN, the remote UE establishes a PC5 connection with the relay UE#2. The remote UE that has established the PC5 connection with the relay UE#2 sets up an SL bearer for DC with the relay UE#2. The relay UE#2 that has established the PC5 connection with the remote UE sets up an SL bearer for DC with the remote UE. The remote UE may notify the relay UE#2 of the SL RRC setting. Relay UE#2 may notify the remote UE of the SL RRC setting.
  • the PDU session may be modified.
  • a PDU session modification procedure is performed between MN and CN. Modification of the PDU session may appropriately apply the method disclosed above.
  • Data communication between the remote UE and the NW includes an MCG bearer between the remote UE and the MN, an SCG bearer between the remote UE and the SN via the relay UE#2, and a remote UE between the remote UE and the MN via the relay UE#2. and SN using a split bearer.
  • FIG. 49 is a sequence diagram showing an example of a DC setting method in which a remote UE connects with two gNBs, according to the fifth embodiment.
  • a case is disclosed where the remote UE connects directly to the MgNB and connects to the SgNB via the relay UE#2.
  • steps common to those in FIG. 41 are assigned the same step numbers, and common descriptions are omitted.
  • step ST5201 data communication is performed among the remote UE, MN and UPF.
  • the MN decides to set up a DC for the remote UE. For example, the MN configures neighboring gNB measurements for the remote UE. The remote UE performs the set measurements and reports the measurement results to the MN. In addition, the MN may configure measurements of neighboring relay UEs for the remote UE. The remote UE may perform the configured measurements and report the measurement results to the MN.
  • the remote UE may include information about the gNB to which the relay UE connects in the measurement result report of the relay UE. For example, the gNB identifier may be included. By doing so, the MN that receives the report of the measurement result of the relay UE from the remote UE can recognize the gNB connected to the relay UE.
  • the gNB may transmit the identifier of the relay UE to which it connects to neighboring gNBs.
  • a gNB can recognize relay UEs to which neighboring gNBs connect. By doing so, the MN that has received the report of the measurement result of the relay UE from the remote UE can recognize the gNB connected to the relay UE.
  • MN uses the measurement result from the remote UE to determine the SN to be used for the DC.
  • the MN transmits an SN addition request message to the SN decided to be used for the DC.
  • MN requests SN to be added as SN for DC to remote UE.
  • the Add SN Request message is sent 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 information example of the SN addition request disclosed above.
  • the SN that receives the SN addition request message from the MN, from the information of the SN addition request, the remote UE that performs the DC setting, the information on the communication between the remote UE that performs the DC setting and the NW, the requested bearer termination, the requested DC recognizing the type of bearer for use, etc., and setting for DC to relay UE#2.
  • the SN transmits DC settings and SL bearer settings to the relay UE#2.
  • the SL bearer configuration may be transmitted together with the DC configuration, or the SL bearer configuration may be included in the DC configuration and transmitted. Alternatively, the setting for DC and the setting for SL bearer may be transmitted separately.
  • the transmission uses RRC signaling.
  • a Relay request message may be used to transmit the settings.
  • the DC settings may include the information example of the DC settings disclosed above.
  • the SL bearer configuration may include the SL bearer configuration information disclosed above.
  • the relay UE#2 that has made these settings transmits a DC setting response and an SL bearer setting response to the SN in step ST5203.
  • the transmission uses RRC signaling.
  • the acknowledgment to be sent may be a Relay request Ack message.
  • the SN that has received the DC setting response and SL bearer setting response recognizes that the relay UE#2 has completed the DC setting and SL bearer setting.
  • the SN transmits an SN addition request response message to the MN.
  • This example sends an acknowledgment.
  • the SN addition request response message may include DC settings and/or SL bearer settings between the SN and the remote UE. Some of these information may be included.
  • the MN Upon receiving the SN addition request response message, the MN recognizes that the SN has performed DC setup and SL bearer setup for the remote UE via remote UE#2.
  • the MN notifies the SN of the Xn-U address indication message. For example, MN sets an address to be used for DC between MN and SN, and transmits this message to SN in step ST4404. This enables the MN and SN to share the address used for the DC and to transmit and receive data between the MN and SN.
  • the MN transmits DC settings and SL bearer settings to the remote UE.
  • the SL bearer configuration may be transmitted together with the DC configuration, or the SL bearer configuration may be included in the DC configuration and transmitted. Alternatively, the setting for DC and the setting for SL bearer may be transmitted separately.
  • the transmission uses RRC signaling.
  • the transmission may use an RRC reconfiguration message.
  • the settings for DC may include the previously disclosed examples of information to be included in the settings for DC.
  • the DC settings received from the SN may be used as the SCG settings of the information to be included in the DC settings.
  • the SL bearer configuration may include the SL bearer configuration information disclosed above.
  • the SL bearer setting received from the SN may be used as the setting for the SCG of the SL bearer setting.
  • the remote UE that has made these settings transmits a DC setting response and an SL bearer setting response to the MN in step ST5208.
  • the transmission uses RRC signaling.
  • An RRC reconfiguration complete message may be used to send the acknowledgment.
  • the MN receiving the DC setup response and SL bearer setup response recognizes that the remote UE has completed the DC setup and SL bearer setup.
  • the remote UE establishes a PC5 connection with the relay UE#2 in step ST5210 while maintaining communication with the MN.
  • PC5-S signaling may be used in establishing the PC5 connection.
  • PC5 RRC signaling may be used.
  • the remote UE establishes a PC5 connection using the SL bearer setup with relay UE#2 received from the MN. This enables data communication between the remote UE and the relay UE#2.
  • the remote UE may establish a PC5 connection to relay UE#2 after first transmitting the DC setting response and SL bearer setting response in step ST5208. Processing for DC among MN, SN, and UPF can be implemented early.
  • the MN transmits an SN setting complete message to the SN.
  • the transmission uses Xn signaling.
  • the transmission may use the S-Node reconfiguration complete message.
  • the SN knows that the MN and the remote UE have completed the configuration for the DC.
  • step ST4409 the MN transfers the SN status to the SN
  • step ST4410 transfers the data from the UPF to the SN.
  • the path between UPF and gNB needs to be changed from MN to SN.
  • the path update process of step ST4420 is performed.
  • step ST5215 data communication is performed among the remote UE, relay UE#2, SN, and UPF.
  • DC is performed between the SN via the remote UE, MN, and relay UE#2.
  • data communication is performed between the remote UE, the SN via the relay UE#2, and the UPF.
  • data communication is performed between the SN, MN, and UPF via the remote UE and relay UE#2.
  • data communication is performed between remote UE, MN, SN and UPF via relay UE#2.
  • MN terminated split bearer data communication is performed between SN, MN and UPF via remote UE and relay UE#2.
  • data communication is performed between remote UE, MN, SN and UPF via relay UE#2.
  • RRC signaling may be performed between the SN and the remote UE via the relay UE#2.
  • the RRC signaling may be performed using SRB3.
  • SRB3 After the remote UE and relay UE#2 start communicating in step ST5210, using SRB3, the remote UE sends an RRC message to SN via relay UE#2, and the SN sends an RRC message to the remote UE via relay UE#2.
  • An RRC message using SRB3 may be, for example, a message regarding SN. For example, it may be a message such as SCG bearer setting change, SN measurement report, information transmission regarding SCG bearer filer.
  • the RRC message can be directly communicated between the SN and the remote UE without going through the MN, so that the amount of signaling can be reduced and the delay can be reduced.
  • FIG. 50 is a diagram showing another protocol stack configuration method when the remote UE connects with two gNBs in communication between the remote UE and the NW via the relay UE, according to the fifth embodiment.
  • a remote UE connects with the MgNB via the relay UE#1 and connects with the SgNB via the relay UE#2. It shows the U-Plane.
  • MN and SN have the Uu protocol for DC.
  • the Uu protocol is SDAP, PDCP, RLC, MAC, PHY.
  • ADP may be configured as a sublayer of RLC.
  • FIG. 50 shows both the MN termination bearer and the SN termination bearer, the MCG bearer, the SCG bearer and the split bearer as DC bearers. Protocols corresponding to these bearers are configured.
  • PDCP may be configured one for MN-terminated bearers and one for SN-terminated bearers. It may be possible to set these bearers in the setting of the DC.
  • the relay UE#1 has the Uu protocol for the MN.
  • the relay UE#1 protocol disclosed in the example of FIG. 46 may be applied as appropriate.
  • Relay UE#1 has a protocol of PC5 between remote UEs.
  • the relay UE#1 protocol disclosed in the example of FIG. 46 may be applied as appropriate.
  • the relay UE#2 has the Uu protocol for SN.
  • the protocol of relay UE#2 disclosed in the example of FIG. 48 may be appropriately applied.
  • Relay UE#2 has a protocol of PC5 between remote UEs.
  • the protocol of relay UE#2 disclosed in the example of FIG. 48 may be appropriately applied.
  • the remote UE has a protocol of PC5 between relay UE#1.
  • the protocol of the PC5 may be for MN. Similar to the relay UE#1, the protocol of the PC5 is PC5 RLC, PC5 MAC, PC5 PHY.
  • a PC5 ADP may be configured above the PC5 RLC.
  • PC5 SDAP and PC5 PDCP may be omitted.
  • the remote UE has a protocol of PC5 between relay UE#2.
  • the remote UE may use the PC5 protocol for SN. Similar to the relay UE#2, the protocol of the PC5 is PC5 RLC, PC5 MAC, PC5 PHY.
  • a PC5 ADP may be configured above the PC5 RLC. PC5 SDAP and PC5 PDCP may be omitted.
  • the remote UE has Uu protocol between MN and/or SN.
  • the Uu protocol is SDAP and PDCP for DC.
  • PDCP of PC5 for MN and SN or PDCP of ADP and Uu are connected.
  • PDCP may be configured one for MN-terminated bearers and one for SN-terminated bearers.
  • DC is terminated at the remote UE.
  • a RB is set up between the MN and the remote UE.
  • relay bearers are set between the MN and the relay UE#1 and between the SN and the relay UE#2.
  • the relay bearer may be an RLC bearer. It may be an RLC channel.
  • SL bearers are set between the relay UE#1 and the remote UE, and between the relay UE#2 and the remote UE.
  • the SL bearer may be an SL RLC bearer. It may be an SL RLC channel.
  • a DC bearer is set up between the MN and the remote UE.
  • MN and SN have a function of mapping RBs between NW and remote UE to RLC bearer of Uu for DC in communication from NW to remote UE.
  • An RLC bearer of Uu for the DC includes an MCG bearer, an SCG bearer, or a split bearer.
  • the number of remote UEs connected to relay UEs #1 and #2 is not limited to one, and may be plural.
  • the number of RBs between the remote UE and the NW is not limited to one, and may be plural.
  • RBs of one or more remote UEs connected to relay UEs #1 and #2 and/or one or more RBs between the remote UE and the NW may be mapped to the Uu RLC bearer for DC .
  • the aforementioned functions may be included in Uu's ADP configured in MN and SN.
  • the ADP may aggregate the functions when the DC is configured and when it is not configured. In this case, the configuration of MN and SN can be facilitated.
  • the MN may add the identifier of the remote UE and the identifier of the RB between the remote UE and the NW in communication from the NW to the remote UE.
  • the RB ID may be the SRB ID if the RB is an SRB.
  • the RB ID may be the DRB ID if the RB is a DRB.
  • the MN may add information about bearers used for the DC in communication from the NW to the remote UE.
  • Information about the bearer used for the DC includes, for example, an identifier indicating the termination 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 termination and type of the bearer used for the DC.
  • the aforementioned additional functions may be included in Uu's ADP configured in the MN.
  • the ADP may aggregate the functions when the DC is configured and when it is not configured. In this case, the configuration of the MN can be facilitated.
  • the SN may add the identifier of the remote UE and the identifier of the RB between the remote UE and the NW in communication from the NW to the remote UE.
  • the RB ID may be the SRB ID if the RB is an SRB.
  • the RB ID may be the DRB ID if the RB is a DRB.
  • the SN may add information about bearers used for the DC in communication from the NW to the remote UE.
  • Information about the bearer used for the DC includes, for example, an identifier indicating the termination 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 termination, type, etc. of the bearer used for the DC.
  • the aforementioned additional functions may be included in Uu's ADP configured in SN.
  • the ADP may aggregate the functions when the DC is configured and when it is not configured. In this case, the configuration of SN can be facilitated.
  • the relay UE#1 has a function of mapping the RLC bearer of Uu for MN to the RLC bearer of PC5 for MN in communication from the NW to the remote UE.
  • the mapping method disclosed in the example of FIG. 46 may be applied as appropriate.
  • the relay UE#2 has a function of mapping the RLC bearer of Uu for SN to the RLC bearer of PC5 for SN in communication from the NW to the remote UE.
  • the mapping method disclosed in the example of FIG. 48 may be applied as appropriate.
  • the remote UE In communication from the NW to the remote UE, the remote UE has a function of mapping the RLC bearer of PC5 for MN and the RLC bearer of PC5 for SN to RBs between the NW and remote UE.
  • the mapping may use the remote UE identifier, RB identifier added by the MN.
  • the mapping may use information about the bearer used for the DC attached at the MN.
  • a remote UE identifier and an RB identifier attached by SN may be used for the mapping.
  • Information about the bearer used for the DC attached in the SN may be used for the mapping.
  • the remote UE has a function of mapping RBs between the NW and the remote UE to two RLC bearers of PC5 for DC in communication from the remote UE to the NW.
  • the PC5 RLC bearer for the DC is the PC5 RLC bearer for the MN and SN.
  • the PC5 RLC bearer for the MN is an MCG bearer or a split bearer.
  • An SCG bearer or a split bearer is available as an RLC bearer of PC5 for SN.
  • the remote UE may add the identifier of the RB between the remote UE and the NW and the identifier of the base station in communication from the NW to the remote UE. There may be multiple base stations.
  • a relay UE may be added when a relay UE connects to multiple base stations.
  • Information indicating whether or not there is a plurality of base stations or information indicating whether or not there are a plurality of identifiers of the base stations may be added.
  • the identifier of the base station may be the identifier of MN and/or SN. For example, it may be applied when DC is set. By doing so, even when the relay UE transmits to a plurality of base stations, it is possible to recognize the RB for communication between the destination base station, the remote UE and the NW.
  • the remote UE may add information about bearers used for the DC in communication from the remote UE to the NW.
  • Information about the bearer used for the DC includes, for example, an identifier indicating the termination 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 termination and type of bearer used for DC.
  • the aforementioned additional functions may be included in the SL ADP configured in the remote UE. Functions for when DC is set and when DC is not set may be aggregated in SL ADP. Configuration of the remote UE can be facilitated.
  • the relay UE#1 has a function of mapping the PC5 RLC bearer for the MN to the Uu RLC bearer for the MN in communication from the remote UE to the NW.
  • the mapping method disclosed in the example of FIG. 46 may be applied as appropriate.
  • the relay UE#2 has a function of mapping the RLC bearer of PC5 for SN to the RLC bearer of Uu for SN in communication from the remote UE to the NW.
  • the mapping method disclosed in the example of FIG. 48 may be applied as appropriate.
  • MN and SN have the function of mapping Uu RLC bearer for DC to RB between NW and remote UE in communication from remote UE to NW.
  • the number of remote UEs connected to relay UE#1 and relay UE#2 is not limited to one, and may be plural.
  • the number of RBs between the remote UE and the NW is not limited to one, and may be plural.
  • Mapping the RLC bearer of Uu for DC to one or more RBs of one or more remote UEs connected to the relay UE#1 and the relay UE#2 and/or one or more RBs between the remote UE and the NW good too.
  • the remote UE identifier added by ADP of Uu for the MN of the remote UE or relay UE #1, the RB identifier, information about the bearer used for DC, etc., and the information for the SN of the remote UE or relay UE #2 may be used. By doing so, it becomes possible for MN and SN to transfer the MCG bearer, SCG bearer, or split bearer for DC to PDCP of RB for communication between remote UE and NW.
  • the aforementioned functions may be included in Uu's ADP configured in MN and SN.
  • the ADP may aggregate the functions when the DC is configured and when it is not configured. In this case, the configuration of MN and SN can be facilitated.
  • RRC should be provided instead of SDAP in the MN and remote UE. It is preferable to provide RRC corresponding to SRB. If DC is configured in SRB, only MN termination bearer may be configured. DC of SRB is enabled.
  • a remote UE connected to two gNBs can communicate between NWs via a relay UE.
  • This embodiment discloses a method for setting a DC in which a remote UE connects with two gNBs.
  • the remote UE connects with the MgNB via the relay UE#1 and connects with the SgNB via the relay UE#2.
  • MN configures the DC for the remote UE.
  • MN configures DC for RB with remote UE.
  • the RB may be for communication between remote UE and MN.
  • the RB may be SRB and/or DRB.
  • the SRB may be SRB2.
  • the MN sets up the Uu RLC bearer for DC between the MN and the relay UE#1. Used for setting DC for RB between MN and remote UE.
  • a Uu RLC bearer for DC if there is no modification from the existing Uu RLC bearer, no new setting may be performed.
  • the MN sets up the Uu RLC bearer for DC between the SN and the relay UE#2. Used for setting DC for RB between MN and remote UE.
  • a Uu RLC bearer for DC if there is no modification from the existing Uu RLC bearer, no new setting may be performed.
  • the MN sets up 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 the SL bearer for the MN.
  • the SL bearer may be an SL RLC bearer.
  • the MN sets up 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.
  • the relay UE#1 should be in an RRC connection state with the MN.
  • the relay UE#2 should be in the SN and RRC connected state.
  • the remote UE should be in an RRC connected state with the MN.
  • the MN may also initiate DC configuration for the remote UE when the remote UE is in RRC connection with the MN.
  • a remote UE configured with a DC connects to the CN via the MN in the C-plane.
  • the MN sends the SN a request to add the SN to the RB for communication between the remote UE and the MN.
  • the add request may be sent using Xn signaling.
  • An S-Node addition request message may be used.
  • the 17 information examples included in the SN addition request disclosed above may be applied as appropriate.
  • the relay UE in the information example may be replaced with relay UE#1 and relay UE#2.
  • information on the relay UE is information on the relay UE #1 and information on the relay UE #2.
  • the information on relay UE #2 may include information indicating which relay UE to go through in order for the SN to perform DC configuration with the remote UE. It may also include information about the settings of the relay UE. Also, it may include the measurement result of the relay UE#2 by the remote UE. In addition, the result of SN measurement by relay UE#2 may be included.
  • the MN can send an SN addition request for the DC to the SN. Also, by receiving the SN addition request from the MN, the SN becomes able to recognize, for example, which DC is for which remote UE, which relay UE is used to connect to the remote UE, and the like.
  • the SN may use the information received from the MN to configure for the DC to the remote UE via the relay UE.
  • the setting for DC for the remote UE via the relay UE may be the setting for DC between the SN and the relay UE.
  • the SN performs settings for DC for relay UE.
  • the SN sends a response message to the SN's add request to the MN. If the SN performs DC setup, it sends an Add SN Request Acknowledgment message to the MN. Xn signaling should be used for transmission.
  • An S-Node addition request acknowledge message may be used as the SN addition request acknowledgment message. If the SN fails to perform DC configuration for the relay UE, it will send an SN Add Request Reject Response message to the MN. Xn signaling should be used for transmission.
  • An S-Node addition request reject message may be used as the SN addition request reject response message.
  • the information included in the SN addition request response message disclosed above may be appropriately applied to the information included in the SN addition request response message.
  • the MN transmits DC settings to the relay UE#1.
  • the methods disclosed above may be applied as appropriate.
  • the MN sets up an SL bearer between the remote UE and the relay UE#1 for the relay UE#1.
  • the methods disclosed above may be applied as appropriate.
  • MN sets DC for relay UE#1 and/or sets DC between SN received from SN and relay UE#2 when setting SL bearer between remote UE and relay UE#1 and/or SL bearer setting information between the relay UE#2 and the remote UE may be used. It becomes possible to take into consideration the load status in the SN.
  • the SN sets up an SL bearer between the remote UE and the relay UE#2 for the relay UE#2.
  • the methods disclosed above may be applied as appropriate.
  • MN sends configuration for DC to remote UE.
  • One example of information to be included in the settings for DC is disclosed.
  • MN sends RB configuration to the remote UE. It may be transmitted by RRC signaling. It may be included in the RRC configuration message and transmitted. It may be included in the RadioBearerConfig information and transmitted.
  • the MN may send the SN identifier to the remote UE. It becomes possible for the DC to recognize the SN connected via the relay UE#2.
  • the MN sets SL bearers between the remote UE and the relay UE#1 and between the remote UE and the relay UE#2. For these settings, the method disclosed above may be appropriately applied.
  • MN sets DC for remote UE and/or sets SL bearer between remote UE and relay UE#1 and/or sets SL bearer between remote UE and relay UE#2, relay received from SN Configuration for DC between UE#2 and SN and/or SL bearer configuration information between remote UE and relay UE#2 may be used. It becomes possible to take into consideration the load status in the SN. For example, the MN may set the SL bearer setting information between the remote UE and the relay UE#2 to be the same as the SL bearer setting information between the remote UE and the relay UE#2 that the SN sent to the relay UE#2. . The setting of the SL bearer becomes the same in the remote UE and the relay UE#2, and malfunctions in SL communication can be reduced.
  • the remote UE Upon receiving the SL bearer setting information for DC from the MN, the remote UE establishes a PC5 connection with the relay UE#2. The remote UE that has established the PC5 connection with the relay UE#2 sets up an SL bearer for DC with the relay UE#2. The relay UE#2 that has established the PC5 connection with the remote UE sets up an SL bearer for DC with the remote UE. The remote UE may notify the relay UE#2 of the SL RRC setting. Relay UE#2 may notify the remote UE of the SL RRC setting.
  • the PDU session may be modified.
  • a PDU session modification procedure is performed between MN and CN. Modification of the PDU session may appropriately apply the method disclosed above.
  • Data communication between the remote UE and the NW includes an MCG bearer between the remote UE and the MN via the relay UE#1, an SCG bearer between the remote UE and the SN via the relay UE#2, and a remote bearer via the relay UE#1. This is done by split bearers between the UE and the MN and between the remote UE and the SN via the relay UE#2.
  • FIG. 51 is a sequence diagram showing an example of a DC setting method in which a remote UE connects with two gNBs, according to the fifth embodiment.
  • a case is disclosed where a remote UE connects with the MgNB via the relay UE#1 and connects with the SgNB via the relay UE#2. 51, steps common to those of FIGS. 41, 47, and 49 are assigned the same step numbers, and common descriptions are omitted.
  • step ST5001 data communication is performed among the remote UE, relay UE#1, MN, and UPF.
  • MN uses the measurement result from the remote UE to determine the SN to be used for the DC.
  • a DC is set for the remote UE using the MN via the relay UE#1 and the SN via the relay UE#2.
  • step ST5401 data communication is performed among the remote UE, relay UE#2, SN, and UPF.
  • DC is performed between the remote UE, the MN via the relay UE#1, and the SN via the relay UE#2.
  • data communication is performed between the remote UE, the SN via the relay UE#2, and the UPF.
  • data communication is performed between the remote UE, the SN via the relay UE#2, the MN via the relay UE#1, and the UPF.
  • data communication is performed between the remote UE, the MN via the relay UE#1, the SN via the relay UE#2, and the UPF.
  • MN terminated split bearer data communication is performed between remote UE, SN via relay UE#2, MN via relay UE#1, and UPF.
  • data communication is performed between the remote UE, the MN via the relay UE#1, the SN via the relay UE#2, and the UPF.
  • RRC signaling may be performed between the SN and the remote UE via the relay UE#2.
  • the RRC signaling may be performed using SRB3.
  • SRB3 After the remote UE and relay UE#2 start communicating in step ST5210, using SRB3, the remote UE sends an RRC message to SN via relay UE#2, and the SN sends an RRC message to the remote UE via relay UE#2.
  • An RRC message using SRB3 may be, for example, a message regarding SN. For example, it may be a message such as SCG bearer setting change, SN measurement report, information transmission regarding SCG bearer filer.
  • the RRC message can be directly communicated between the SN and the remote UE without going through the MN, so that the amount of signaling can be reduced and the delay can be reduced.
  • DC becomes possible in indirect communication between the remote UE and the NW via the relay UE.
  • Communication using multiple gNBs is possible in indirect communication between the remote UE and the NW via the relay UE.
  • performance improvements such as high speed, large capacity, low delay, and high reliability can be achieved.
  • the relay UE does not have to connect with multiple gNBs. It is possible to avoid complications due to DC in the configuration of the relay UE.
  • Embodiment 6 discloses another method for solving the problem described in the fourth embodiment.
  • the remote UE In communication between the remote UE and the NW via the relay UE, the remote UE connects to one base station through multiple paths.
  • the plurality may be two, for example.
  • At least one path connects a remote UE and a base station via a relay UE.
  • a DC may be set for communication between the remote UE and the NW.
  • a DC may be configured with a relay UE as an alternative to an SN.
  • a relay UE that replaces SN is referred to as relay UE#S.
  • the relay UE#S has some or all of the SN functions for DC. Since the remote UE is a DC, it connects with the MN and the relay UE#S.
  • the connection between the remote UE and the MN may be a direct connection or an indirect connection via a relay UE.
  • the radio bearer may be, for example, an SRB.
  • SRB0 and SRB1 communicate using one gNB, thereby making it possible to simplify the process of establishing communication.
  • the radio bearer may be, for example, the DRB. In this case, the communication quality of bearers for data communication can be improved.
  • FIG. 52 is a conceptual diagram showing an example of communication between a remote UE and a NW via a relay UE, according to Embodiment 6, in which the remote UE is connected to one gNB via two paths.
  • the remote UE in communication between the remote UE and the NW, the remote UE is configured with a DC using the MN and the relay UE#S that substitutes for the SN.
  • the remote UE connects directly with the MgNB
  • the remote UE connects with the relay UE#S and the relay UE#S connects with the MgNB.
  • a direct connection between the remote UE and the MgNB is made at Uu.
  • PC5 connects between the remote UE and the relay UE#S.
  • Xn connects between the relay UE#S and the MgNB.
  • a wireless connection may be established between the relay UE#S and the MgNB.
  • Xn connections may be made using Uu.
  • the remote UE should be in an RRC connected state with the MgNB.
  • the relay UE#S may be in an RRC connection state with the MgNB. For example, the RRC connection state may be set when the relay UE#S and the MgNB are wirelessly connected and Xn is connected using Uu.
  • FIG. 53 is a conceptual diagram showing another example of communication between the remote UE and the NW via the relay UE, in which the remote UE connects to one gNB with two paths, according to the sixth embodiment.
  • the remote UE in communication between the remote UE and the NW, the remote UE is configured with a DC using the MN and the relay UE#S that substitutes for the SN.
  • the remote UE connects with the MgNB via the relay UE#1, and on the other path, the remote UE connects with the relay UE#S, and the relay UE#S connects with the MgNB.
  • the remote UE and relay UE#1 are connected by PC5, and the relay UE#1 and MgNB are connected by Uu.
  • PC5 connects between the remote UE and the relay UE#S.
  • Xn connects between the relay UE#S and the MgNB.
  • the relay UE#S and the MgNB may be connected by F1.
  • a wireless connection may be established between the relay UE#S and the MgNB.
  • Uu may be used to make Xn or F1 connections.
  • the remote UE should be in an RRC connected state with the MgNB.
  • the relay UE#1 should be in an RRC connection state with the MgNB.
  • the relay UE#S may be in an RRC connection state with the MgNB.
  • the RRC connection state may be set when the relay UE#S and the MgNB are wirelessly connected and Xn or F1 is connected using Uu.
  • FIG. 54 shows a protocol stack in the case where the remote UE uses the MN and the relay UE #S as a substitute for the SN to set the DC in the communication between the remote UE and the NW, according to the sixth embodiment. It is a diagram. A case is shown where the remote UE connects directly to the MgNB on one path, the remote UE connects to the relay UE#S on the other path, and the relay UE#S connects to the MgNB. It shows the U-Plane.
  • the MN has Uu protocol for DC.
  • the Uu protocol is SDAP, PDCP, RLC, MAC, PHY.
  • the Uu protocol may be for the MN.
  • the relay UE#S has a protocol of PC5 for DC.
  • the protocol of the PC5 may be used for SN.
  • the protocols of the PC5 are PC5 RLC, PC5 MAC, and PC5 PHY.
  • a PC5 ADP may be configured above the PC5 RLC.
  • PC5 ADP may be configured as a sublayer of PC5 RLC.
  • the PC5 ADP may have, for example, a mapping function between the Uu bearer and the PC5 bearer.
  • PC5 SDAP and PC5 PDCP may be omitted.
  • FIG. 54 also shows the MCG bearer, SCG bearer, and split bearer. It may be possible to set these bearers in the setting of the DC.
  • the remote UE has the PC5 protocol with the relay UE#S.
  • the protocol of the PC5 may be used for SN. Similar to the relay UE#S, the protocols of this PC5 are PC5 ADP, PC5 RLC, PC5 MAC, PC5 PHY. PC5 SDAP and PC5 PDCP may be omitted.
  • a bearer for SN is an SCG bearer or a split bearer.
  • the remote UE has a Uu protocol for DC with the MN.
  • the Uu protocol is SDAP, PDCP, RLC, MAC, PHY.
  • the bearers for the MN are MCG bearers or split bearers.
  • ADP of PC5 for SN and PDCP of Uu are connected, and RLC of Uu and PDCP of Uu for MN are connected. DC is terminated at the remote UE.
  • a RB is set up between the MN and the remote UE.
  • a bearer for DC is set.
  • an MN termination bearer terminated by the MN's PDCP is set.
  • a bearer for DC a bearer having an MN's RLC bearer or a bearer having both MN's and relay UE#S's RLC bearers is set.
  • the bearer with the MN's RLC bearer is called the MCG bearer
  • the bearer with the relay UE#S's RLC bearer is called the SCG bearer
  • the bearer with both the MN's and the relay UE#S's RLC bearers is split. called a bearer.
  • a SL bearer is set between the relay UE#S and the remote UE.
  • the SL bearer should be an SL RLC bearer. It may be an SL RLC channel.
  • a DC bearer is set up between the MN and the remote UE.
  • the MN has a function of mapping RBs between the NW and the remote UE to RLC bearers for DC in communication from the NW to the remote UE.
  • RLC bearers for the DC include MCG bearers, SCG bearers, and split bearers.
  • the number of remote UEs connected to the relay UE#S is not limited to one, and may be plural.
  • the number of RBs between the remote UE and the NW is not limited to one, and may be plural.
  • the MN may add the identifier of the remote UE and the identifier of the RB (RB identifier: RB ID) between the remote UE and the NW in communication from the NW to the remote UE.
  • the RB ID may be the SRB ID if the RB is an SRB.
  • the RB ID may be the DRB ID if the RB is a DRB.
  • the MN may add information about bearers used for the DC in communication from the NW to the remote UE.
  • Information about the bearer used for the DC includes, for example, an identifier indicating the termination 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#S or the remote UE can recognize the termination and type of the bearer used for the DC.
  • one or more RBs between the remote UE and the NW may be mapped to the RLC bearer of PC5 for DC.
  • the remote UE identifier added by the MN, the RB identifier, information about the bearer used for the DC, etc. may be used.
  • the functions described above may be included in the ADP of PC5 configured in the relay UE#S.
  • the ADP may aggregate the functions when the DC is configured and when it is not configured.
  • the configuration of the relay UE#S can be facilitated.
  • the relay UE#S may delete some or all of the remote UE identifier added by the MN, the RB identifier, information about the bearer used for the DC, and the like. Some or all of this identifier or information may not be added in the mapping of PC5 to the RLC bearer to the remote UE.
  • the identifier of the remote UE and the identifier of the RB between the remote UE and the NW may be added.
  • the RB ID may be the SRB ID if the RB is an SRB.
  • the RB ID may be the DRB ID if the RB is a DRB.
  • information about the bearer used for the DC may be added in communication from the NW to the remote UE.
  • Information about the bearer used for the DC includes, for example, an identifier indicating the termination 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 remote UE becomes capable of recognizing the termination, type, etc. of the bearer used for the DC.
  • the remote UE In communication from the NW to the remote UE, the remote UE has a function of mapping the RLC bearer of Uu for MN and the RLC bearer of PC5 for SN to RBs between the NW and remote UE. For the mapping, the remote UE identifier added by the relay UE#S, the RB identifier, information about the bearer used for the DC, and the like may be used.
  • the remote UE has a function of mapping RBs between the NW and the remote UE to RLC bearers for DC in communication from the remote UE to the NW.
  • RLC bearers for the DC there are a Uu RLC bearer for the MN and a PC5 RLC bearer for the SN.
  • RLC bearers for the DC include MCG bearers, SCG bearers, and split bearers.
  • the number of remote UEs connected to the relay UE#S is not limited to one, and may be plural.
  • the number of RBs between the remote UE and the NW is not limited to one, and may be plural.
  • the remote UE may add the identifier of the base station and the identifier of the RB between the remote UE and the NW in communication from the remote UE to the NW.
  • the RB ID may be the SRB ID if the RB is an SRB.
  • the RB ID may be the DRB ID if the RB is a DRB.
  • Information indicating whether or not there is a plurality of base stations or information indicating whether or not there are a plurality of identifiers of the base stations may be added. By doing so, the relay UE#S or MN can recognize the RB for communication between the destination base station, the remote UE and the NW.
  • the remote UE may add information about the bearer used for the DC in communication from the NW to the remote UE.
  • Information about the bearer used for the DC includes, for example, an identifier indicating the termination 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#S or MN can recognize the termination, type, etc. of the bearer used for the DC.
  • the relay UE#S maps the PC5 RLC bearer for SN to one or more RBs between the remote UE and the NW. For the mapping, the base station identifier added by the remote UE, the RB identifier, information about the bearer used for the DC, and the like may be used.
  • the functions described above may be included in the ADP of PC5 configured in the relay UE#S.
  • the ADP may aggregate the functions when the DC is configured and when it is not configured. The configuration of the relay UE#S can be facilitated.
  • the relay UE#S may delete some or all of the remote UE identifier added by the remote UE, the RB identifier, the information about the bearer used for the DC, etc. when mapping to one or more RBs. . Some or all of the identifier or information may not be added in mapping to one or more RBs.
  • the relay UE#S may add the identifier of the remote UE and the identifier of the RB between the remote UE and the NW in communication from the remote UE to the NW.
  • the RB ID may be the SRB ID if the RB is an SRB.
  • the RB ID may be the DRB ID if the RB is a DRB.
  • the relay UE#S may add information about bearers used for the DC in communication from the remote UE to the NW.
  • Information about the bearer used for the DC includes, for example, an identifier indicating the termination 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, it becomes possible for the MN to recognize the termination, type, etc. of the bearer used for the DC.
  • the MN In communication from the remote UE to the NW, the MN has a function of mapping the RLC bearer of Uu for MN and the RLC bearer of PC5 for SN to RBs between the NW and remote UE.
  • the remote UE identifier added by the ADP of the remote UE or relay UE#S, the RB identifier, information about the bearer used for the DC, and the like may be used.
  • RRC should be provided instead of SDAP in the MN and remote UE. It is preferable to provide RRC corresponding to SRB. If DC is configured in SRB, only MN termination bearer may be configured. DC of SRB is enabled.
  • FIG. 55 is a diagram showing the protocol stack between the MN and the relay UE#S for the sixth embodiment. It shows a case where Xn connection is made using Uu between the relay UE#S and the MgNB. It shows the U-Plane.
  • MN has GTP-U, UDP, IP, RLC, MAC, PHY for Xn or F1 connection with relay UE#S.
  • PDCP which is a Uu protocol for DC, and GTP-U are connected.
  • a PDCP PDU for the relay UE#S is input to the GTP-U.
  • Processing is performed by GTP-U, UDP, and IP, and data output by IP is input to protocol RLC of Uu for wireless connection with relay UE#S.
  • Data input to the RLC is subjected to MAC and PHY processing and transmitted to the relay UE#S.
  • the relay UE#S has GTP-U, UDP, IP, RLC, MAC, and PHY for Xn connection with MN.
  • Data received from the MN are input to Uu's protocol PHY for wireless connection with the MN.
  • Data input to the PHY is processed by MAC and RLC and input to the IP.
  • Data input to IP is processed by UDP and GTP-U, and the data is output. This data is equivalent to PDCP PDU.
  • IP, UDP, and GTP-U are mutually terminated between the MN and the relay UE#S.
  • the output data from the GTP-U is mapped to the SN SL bearer of the relay UE#S.
  • Data mapped to the SL bearer is input to the SL ADP, processed by the SL RLC, SL MAC and SL PHY, and transmitted to the remote UE.
  • SCTP For the C-Plane protocol, only SCTP should be provided instead of UDP and DTP-U in the MN and relay UE#S. DC of SRB is enabled.
  • a remote UE connected to one gNB via two paths can communicate with the NW via the relay UE.
  • a DC setting method is disclosed in which the remote UE connects to one gNB with two paths.
  • a case will be disclosed in which the remote UE uses the MN and the relay UE#S as a substitute for the SN to set the DC. Specifically, a case is disclosed in which the remote UE connects directly to the MgNB on one path, the remote UE connects to the relay UE #S on another path, and the relay UE #S connects to the MgNB.
  • MN configures the DC for the remote UE.
  • MN configures DC for RB with remote UE.
  • the RB may be for communication between remote UE and MN.
  • the RB may be SRB and/or DRB.
  • the SRB may be SRB2.
  • Uu's RLC bearer for the DC may be the RLC bearer to/from the MN.
  • the MN sets up the Uu RLC bearer for DC to the relay UE#S.
  • Uu's RLC bearer for the DC may be the RLC bearer to/from the MN.
  • the MN sets up an SL bearer for DC between the relay UE#S and the remote UE.
  • the SL bearer for the 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.
  • the relay UE#S should be in an RRC connection state with the MN.
  • the remote UE should be in an RRC connected state with the MN.
  • the MN may also initiate DC configuration for the remote UE when the remote UE is in RRC connection with the MN.
  • a remote UE configured with a DC connects to the CN via the MN in the C-plane.
  • the MN transmits to the relay UE#S a DC setting request for the RB for communication between the remote UE and the MN.
  • the setting request for the DC may be a request for addition of functions as an SN.
  • the add request may be sent using Xn signaling. It may be transmitted using F1 signaling. It may be sent using the S-Node addition request message. Alternatively, a new message may be provided and transmitted using this message.
  • the message may be, for example, a Relay (DC) request message.
  • DC Relay
  • the 17 information examples included in the SN addition request disclosed above should be appropriately applied. It is preferable to replace the SN in the information example with the relay UE#S.
  • the MN and the remote UE are connected without going through the relay UE, there may be no setting information between the MN and the relay UE.
  • the MN does not transmit (4), (7), and (9) among the 17 information examples included in the SN addition request disclosed above to the relay UE#S.
  • Relay #S functioning as SN may include information for performing remote UE and DC settings.
  • the information about the relay UE #S in (1) may include the measurement result of the relay UE #S by the remote UE. Also, it may include the measurement result of the MN by the relay UE#S.
  • the MN can transmit a DC setting request to the relay UE#S. Also, by receiving the DC setting request from the MN, the relay UE#S can recognize, for example, which remote UE the DC is for. The relay UE#S uses the information received from the MN to make settings for DC as an SN.
  • MN transmits the setting for DC with respect to relay UE#S.
  • Five examples of information to be included in the settings for DC are disclosed.
  • Information to be included in the setting for DC may be information for setting as SN.
  • (1) is information about RBs for communication between remote UE and MN.
  • MN does not set RB as DC setting for relay UE#S.
  • SRB setting is not performed even when the RB for which DC is set is SRB.
  • DRB is not set even when the RB for which DC is set is DRB.
  • the information about RBs in (1) may be, for example, only RB identifiers.
  • (2) is information about Uu's RLC bearer for DC.
  • the information on the RLC bearer of Uu for DC it is preferable to use the setting information of the Uu RLC bearer for Xn or F1.
  • the MN transmits the setting information of the Uu RLC bearer for Xn or F1 to the relay UE#S.
  • the relay UE#S can establish a connection for Xn signaling or F1 signaling with the MN.
  • the SN identifier in (3) may be omitted.
  • the identifier of the SN may be the identifier of the relay UE#S.
  • the MN configures the SL bearer between the remote UE and the relay UE#S for the relay UE#S. If there is an existing SL bearer between the remote UE and relay UE#S, the SL bearer may be modified.
  • the SL bearer configuration may be a configuration for SL bearer modification. Three examples of SL bearer setting information are disclosed. (1) Information about the RLC bearer of SL. (2) Information about SL ADP settings. (3) A combination of (1) and (2).
  • the setting information of the SL bearer it is preferable to appropriately apply the setting information example of the SL bearer disclosed above.
  • the MN does not need to set SL RB for relay UE#S. There is no need to send information about SL and RB. SL PDCP and SL SDAP may not be set.
  • the MN may configure one SL bearer for the DC for the relay UE#S.
  • the setting of the SL bearer for the DC may be the setting of the SL bearer for the SN.
  • the MN may configure an SN SL bearer for the relay UE#S as the SN.
  • the MN establishes Xn or F1 connection with relay UE#S.
  • the MN may transmit configuration information used for the connection to the relay UE#S.
  • the setting information includes, for example, GTP-u TEID and TNL address (IP address). By doing so, the MN can transmit/receive data to/from the relay UE#S using Xn or F1 instead of Uu.
  • the relay UE#S may perform DC settings for the remote UE.
  • the relay UE #S may configure the DC between the remote UE and the relay UE #S.
  • the relay UE#S may perform DC configuration using information included in the DC configuration request message received from the MN.
  • the SL RRC setting between the remote UE and the relay UE#S may be used as the DC setting for the remote UE.
  • the SL RRC setting may be, for example, the setting of the SL RLC bearer.
  • the relay UE#S sends a response message to the DC setting request to the MN.
  • the relay UE#S implements DC configuration, it sends a DC configuration request acknowledgment message to the MN.
  • Xn signaling should be used for transmission. It may be transmitted using F1 signaling.
  • An S-Node addition request acknowledgment message may be used as the DC configuration request acknowledgment message.
  • a new message may be provided. For example, it may be a Relay (DC) request acknowledge message.
  • Information to be included in the DC setting request response message may appropriately apply the information included in the SN addition request response message disclosed above.
  • the relay UE#S If the relay UE#S cannot implement the DC setting, it sends a DC setting request rejection response message to the MN.
  • Xn signaling should be used for transmission. It may be transmitted using F1 signaling.
  • An S-Node addition request reject message may be used as the DC setting request reject response message.
  • a new message may be provided. For example, it may be a Relay (DC) request reject message.
  • the message may include, for example, information about the remote UE and reason information.
  • MN sends configuration for DC to remote UE.
  • Information to be included in the settings for DC are disclosed.
  • (2) is information about Uu's RLC bearer for DC.
  • the MN may not configure the remote UE for SCG. Since remote UE connects with relay UE#S as SN in DC, remote UE does not need to receive information about SCG.
  • the SN identifier in (3) may be omitted.
  • the identifier of the SN may be the identifier of the relay UE#S.
  • the MN When the MN performs DC settings for the remote UE, it may use the SL bearer setting information received from the relay UE#S between the remote UE and the relay UE#S. It becomes possible to consider the load status and the like in the relay UE#S.
  • the MN sets the SL bearer between the remote UE and the relay UE#S for the remote UE. If there is an existing SL bearer between the remote UE and relay UE#S, the SL bearer may be modified.
  • the SL bearer configuration may be a configuration for SL bearer modification. Three examples of SL bearer setting information are disclosed. (1) Information about the RLC bearer of SL. (2) Information about SL ADP settings. (3) A combination of (1) and (2).
  • the setting information of the SL bearer it is preferable to appropriately apply the setting information example of the SL bearer disclosed above.
  • RLC bearer There may be one RLC bearer for the SL.
  • an RLC bearer of SL for SN may be set.
  • the MN may set up an SL RLC bearer between the relay UE#S as an SN for the remote UE.
  • the ADP setting of the SL for DC the ADP of SL for SN may be set.
  • the MN may configure the SL ADP between the remote UE and the relay UE#S as the SN for the remote UE.
  • the SL bearer settings may be included in the DC settings. You may include the setting information of SL bearer in the setting information for DC.
  • MN does not need to configure SL RB for remote UE. There is no need to send information about SL and RB. SL PDCP and SL SDAP may not be set.
  • the MN may configure one SL bearer for the DC to the remote UE.
  • the setting of the SL bearer for the DC may be the setting of the SL bearer for the MN.
  • the MN may use the SL bearer setting information between the remote UE and relay UE#S received from the relay UE#S. It becomes possible to consider the load status and the like in the relay UE#S. For example, the MN may set the SL bearer setting information between the remote UE and the relay UE#S to be the same as the SL bearer setting information between the remote UE and the relay UE#S received from the relay UE#S. The setting of the SL bearer in the remote UE and the relay UE#S becomes the same, and malfunction in SL communication can be reduced.
  • the remote UE Upon receiving the SL bearer setting information for DC from the MN, the remote UE establishes a PC5 connection with the relay UE#S.
  • the remote UE that has established the PC5 connection with the relay UE#S sets up an SL bearer for DC with the relay UE#S.
  • the relay UE#S that has established the PC5 connection with the remote UE sets up an SL bearer for DC with the remote UE.
  • the remote UE may notify the relay UE#S of the SL RRC setting.
  • the relay UE#S may notify the remote UE of the SL RRC setting.
  • Data communication between the remote UE and the NW includes an MCG bearer between the remote UE and the MN, an SCG bearer between the remote UE and the MN via the relay UE#S, and a remote UE between the remote UE and the MN via the relay UE#S. and MN using a split bearer.
  • FIG. 56 is a sequence diagram showing an example of a DC setting method in which a remote UE connects to one gNB with two paths, according to the sixth embodiment.
  • the remote UE uses the MN and the relay UE#S that substitutes for the SN to configure the DC.
  • a case is disclosed where the remote UE connects directly to the MgNB on one path, the remote UE connects to the relay UE#S on another path, and the relay UE#S connects to the MgNB.
  • steps common to those in FIG. 49 are assigned the same step numbers, and common descriptions are omitted.
  • step ST5201 data communication is performed among the remote UE, MN and UPF.
  • MN decides to set up a DC for the remote UE. For example, MN determines relay UE#S to be used for DC from the measurement result of remote UE.
  • the MN transmits a DC setting request to the relay UE#S determined to be used as DC.
  • the MN requests the relay UE#S to add the function as the DC SN for the remote UE.
  • the DC setup request message is sent using, for example, Xn or F1 signaling.
  • a Relay (DC) request message may be used as the DC setting request message.
  • the DC setup request message may include the information example of the SN addition request disclosed above.
  • the relay UE#S that has received the DC setting request message from the MN, from the information of the DC setting request, the remote UE that performs the DC setting, the information on the communication between the remote UE that performs the DC setting and the NW, the requested bearer termination, the request Recognizes the DC bearer type, etc., and performs DC settings for the remote UE.
  • the configuration for the DC may for example be the RRC configuration between the SN and the remote UE.
  • the relay UE#S transmits a DC setting request response message to the MN. This example sends an acknowledgment.
  • a Relay (DC) request Ack message may be used as the DC setting request response message.
  • the SL RRC setting between the relay UE#S and the remote UE may be included in the DC setting request response message.
  • the MN that has received the DC setting request response message recognizes that the relay UE#S has performed the DC setting for the remote UE. Also, the MN recognizes the RRC configuration between the relay UE#S and the remote UE.
  • step ST5903 the MN notifies the relay UE#S of the Xn-U address indication message.
  • An F1-U address indication message may be signaled.
  • MN sets an address to be used for DC between MN and SN, and transmits this address to relay UE#S in step ST5903. This allows the MN and the relay UE#S to share the address used for the DC, enabling data transmission/reception between the MN and the relay UE#S.
  • the MN transmits DC settings and SL bearer settings to the remote UE.
  • the SL bearer configuration may be transmitted together with the DC configuration, or the SL bearer configuration may be included in the DC configuration and transmitted. Alternatively, the setting for DC and the setting for SL bearer may be transmitted separately.
  • the transmission uses RRC signaling.
  • the transmission may use an RRC reconfiguration message.
  • the settings for DC may include the previously disclosed examples of information to be included in the settings for DC.
  • the DC settings received from the SN may be used as the SCG settings of the information to be included in the DC settings.
  • the SL bearer configuration may include the SL bearer configuration information disclosed above.
  • the SL bearer setting received from the SN may be used as the setting for the SCG of the SL bearer setting.
  • the RRC setting information received from the relay UE#S may be used as the setting related to the SL bearer setting information.
  • the remote UE can configure the DC configuration between the MN and the remote UE and the SL bearer configuration between the remote UE and the relay UE #S.
  • the remote UE that has made these settings transmits a DC setting response and an SL bearer setting response to the MN in step ST5208.
  • the transmission uses RRC signaling.
  • An RRC reconfiguration complete message may be used to send the acknowledgment.
  • the MN receiving the DC setup response and SL bearer setup response recognizes that the remote UE has completed the DC setup and SL bearer setup.
  • step ST5904 the MN transmits a DC setting complete message to the relay UE#S.
  • the transmission uses Xn or F1 signaling.
  • the transmission may use a Relay (DC) reconfiguration complete message.
  • DC Relay
  • the remote UE establishes a PC5 connection with the relay UE#S in step ST5905 while maintaining communication with the MN.
  • PC5-S signaling may be used in establishing the PC5 connection.
  • PC5 RRC signaling may be used.
  • the remote UE establishes a PC5 connection using the SL bearer setup with the relay UE#S received from the MN. This enables data communication between the remote UE and the relay UE#S.
  • the MN may transfer the SN state to the relay UE#S.
  • the SN status transfer may be done using the SN status transfer message.
  • the MN transfers data from the UPF to the relay UE#S.
  • DC is performed between the remote UE, MN, and relay UE#S.
  • Configurable DCs may only be MN terminated bearers. It is possible to facilitate the configuration of the relay UE#S without connecting the relay UE#S directly to the CN. For example, in case of MN terminated SCG bearer, data communication is performed between remote UE, relay UE#S, MN and UPF. For example, in case of MN terminated split bearer, data communication is performed between remote UE, relay UE#S, MN and UPF.
  • the remote UE to set a DC that connects the MgNB and the relay UE#S.
  • FIG. 57 shows, regarding Embodiment 6, in communication between the remote UE and the NW, the remote UE uses the MN and the relay UE #S as a substitute for the SN, and the DC is set. It is a diagram showing a configuration method of. A case is shown in which the remote UE connects to the MgNB via the relay UE#1 on one path, the remote UE connects to the relay UE#S on the other path, and the relay UE#S connects to the MgNB. . It shows the U-Plane.
  • the MN has Uu protocol for DC.
  • the Uu protocol is SDAP, PDCP, RLC, MAC, PHY.
  • ADP is configured between RLC and PDCP.
  • ADP may be configured as a sublayer of RLC.
  • the Uu protocol may be for the MN.
  • the relay UE#S has a protocol of PC5 for DC.
  • the protocol of the PC5 may be used for SN.
  • the protocols of the PC5 are 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.
  • PC5 SDAP and PC5 PDCP may be omitted.
  • FIG. 57 also shows the MCG bearer, SCG bearer, and split bearer. It may be possible to set these bearers in the setting of the DC.
  • the relay UE#1 has the Uu protocol for the MN.
  • the Uu protocol is RLC, MAC, PHY.
  • a PC5 ADP may be configured above the PC5 RLC.
  • PC5 ADP may be configured as a sublayer of PC5 RLC.
  • the bearers for the MN are MCG bearers or split bearers.
  • the relay UE#1 has the PC5 protocol between remote UEs.
  • the protocol of the PC5 may be for MN.
  • the protocols of the PC5 are PC5 RLC, PC5 MAC, and PC5 PHY.
  • a PC5 ADP may be configured above the PC5 RLC.
  • PC5 ADP may be configured as a sublayer of PC5 RLC.
  • the PC5 ADP may have, for example, a mapping function between the Uu bearer and the PC5 bearer.
  • PC5 SDAP and PC5 PDCP may be omitted.
  • the remote UE has the PC5 protocol with the relay UE#S.
  • the protocol of the PC5 may be used for SN. Similar to the relay UE#S, the protocols of this PC5 are PC5 ADP, PC5 RLC, PC5 MAC, PC5 PHY. PC5 SDAP and PC5 PDCP may be omitted.
  • the remote UE has the PC5 protocol with the relay UE#1. The protocol of the PC5 may be for MN. Similar to the relay UE#1, the protocols of the PC5 are PC5 ADP, PC5 RLC, PC5 MAC, PC5 PHY. PC5 SDAP and PC5 PDCP may be omitted.
  • the remote UE has a Uu protocol with the MN. The Uu protocol is SDAP and PDCP for DC. At the remote UE, PC5's ADP for MN and Uu's PDCP are connected. DC is terminated at the remote UE.
  • a RB is set up between the MN and the remote UE.
  • a bearer for MN is set between MN and relay UE#1.
  • the MCG bearer or split bearer may be an RLC bearer. It may be an RLC channel.
  • One SL bearer is set between the relay UE#1 and the remote UE.
  • the SL bearer should be the SL RLC bearer for the MN. It may be an SL RLC channel.
  • An SL bearer for SN is set between the relay UE#S and the remote UE.
  • a bearer for SN is an SCG bearer or a split bearer.
  • the SCG bearer or split bearer may be an RLC bearer. It may be an RLC channel.
  • the MN has a function of mapping RBs between the NW and the remote UE to the RLC bearer of Uu for DC and the RLC bearer of PC5.
  • An MCG bearer or a split bearer is an RLC bearer of Uu for the DC.
  • an RLC bearer of PC5 for the DC there is an SCG bearer or a split bearer.
  • the number of remote UEs connected to the relay UE#1 is not limited to one, and may be plural.
  • the number of RBs between the remote UE and the NW is not limited to one, and may be plural.
  • 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 Uu for DC.
  • the aforementioned functions may be included in Uu's ADP configured in MN and SN.
  • the ADP may aggregate the functions when the DC is configured and when it is not configured. In this case, the configuration of the MN can be facilitated.
  • the MN may add the identifier of the remote UE and the identifier of the RB between the remote UE and the NW in communication from the NW to the remote UE.
  • the RB ID may be the SRB ID if the RB is an SRB.
  • the RB ID may be the DRB ID if the RB is a DRB.
  • the MN may add information about bearers used for the DC in communication from the NW to the remote UE.
  • Information about the bearer used for the DC includes, for example, an identifier indicating the termination of the bearer and/or an identifier indicating the type of bearer and/or an identifier indicating whether it is for MN or SN.
  • the relay UE #1, the relay UE #S, or the remote UE can recognize the termination, type, etc. of the bearer used for the DC.
  • the aforementioned additional functions may be included in Uu's ADP configured in the MN.
  • the ADP of Uu configured in the MN may have only additional functions in communication to the relay UE#1.
  • the ADP may aggregate the functions when the DC is configured and when it is not configured. In this case, the configuration of the MN can be facilitated.
  • the relay UE#1 has a function of mapping the RLC bearer of Uu for MN to the RLC bearer of PC5 for MN in communication from the NW to the remote UE.
  • the remote UE identifier added by the MN, the RB identifier, information about the bearer used for the DC, etc. may be used.
  • relay UE#1 can map the MCG bearer or split bearer for MN to the RLC bearer of PC5 for MN.
  • the aforementioned functions may be included in Uu's ADP configured in relay UE#1.
  • the ADP may aggregate the functions when the DC is configured and when it is not configured. In this case, the configuration of the relay UE#1 can be simplified.
  • the remote UE identifier added by the MN may be partially or entirely deleted. good. Some or all of this identifier or information may not be added in the mapping of PC5 to RLC bearers for the MN.
  • one or more RBs between the remote UE and the NW may be mapped to the RLC bearer of PC5 for DC.
  • the mapping method disclosed in the example of FIG. 54 may be applied as appropriate.
  • the remote UE has a function of mapping the RLC bearer of PC5 for MN and the RLC bearer of PC5 for SN to RBs between the NW and the remote UE in communication from the remote UE to the NW.
  • the remote UE identifier added by the MN or the relay UE#S, the RB identifier, information about the bearer used for the DC, and the like may be used.
  • the remote UE has a function of mapping RBs between the NW and the remote UE to RLC bearers for DC in communication from the remote UE to the NW.
  • RLC bearers for the DC there are a PC5 RLC bearer for the MN and a PC5 RLC bearer for the SN.
  • RLC bearers for the DC include MCG bearers, SCG bearers, and split bearers.
  • the number of remote UEs connected to the relay UE#S is not limited to one, and may be plural.
  • the number of RBs between the remote UE and the NW is not limited to one, and may be plural.
  • the remote UE may add the identifier of the base station and the identifier of the RB between the remote UE and the NW in communication from the remote UE to the NW.
  • the RB ID may be the SRB ID if the RB is an SRB.
  • the RB ID may be the DRB ID if the RB is a DRB.
  • Information indicating whether or not there is a plurality of base stations or information indicating whether or not there are a plurality of identifiers of the base stations may be added. By doing so, the relay UE #1, the relay UE #S, or the MN can recognize the RB for communication between the destination base station, the remote UE, and the NW.
  • the remote UE may add information about the bearer used for the DC in communication from the NW to the remote UE.
  • Information about the bearer used for the DC includes, for example, an identifier indicating the termination of the bearer and/or an identifier indicating the type of bearer and/or an identifier indicating whether it is for MN or SN.
  • the relay UE#1, the relay UE#S, or the MN can recognize the termination, type, etc. of the bearer used for the DC.
  • the relay UE#1 has a function of mapping the PC5 RLC bearer for the MN to the Uu RLC bearer for the MN in communication from the remote UE to the NW.
  • the base station identifier added by the remote UE, the RB identifier, information about the bearer used for the DC, and the like may be used.
  • An MCG bearer or a split bearer is an RLC bearer of Uu for the MN.
  • the number of remote UEs connected to the relay UE#1 is not limited to one, and may be plural.
  • the aforementioned functions may be included in Uu's ADP configured in relay UE#1.
  • the ADP may aggregate the functions when the DC is configured and when it is not configured. In this case, the configuration of the relay UE#1 can be simplified.
  • the relay UE #1 When the relay UE #1 is mapped to the Uu RLC bearer for the MN, the base station identifier added by the remote UE, the RB identifier, the information about the bearer used for the DC, and the like may be deleted in whole or in part. good. Some or all of this identifier or information may not be added in the mapping of Uu to RLC bearers for the MN.
  • the relay UE #1 may add the identifier of the remote UE and the identifier of the RB between the remote UE and the NW in communication from the remote UE to the NW.
  • the RB ID may be the SRB ID if the RB is an SRB.
  • the RB ID may be the DRB ID if the RB is a DRB.
  • the MN can recognize the remote UE of the transmission source and the RB for communication between the remote UE and the NW.
  • the aforementioned additional functions may be included in the Uu ADP for the MN configured in the relay UE#1.
  • the ADP may aggregate the functions when the DC is configured and when it is not configured. In this case, the configuration of the relay UE#1 can be simplified.
  • the relay UE#1 may add information about the bearer used for the DC in communication from the NW to the remote UE.
  • Information about the bearer used for the DC includes, for example, an identifier indicating the termination 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, it becomes possible for the MN to recognize the termination, type, etc. of the bearer used for the DC.
  • the relay UE#S maps the PC5 RLC bearer for SN to one or more RBs between the remote UE and the NW.
  • the mapping method disclosed in the example of FIG. 54 may be applied as appropriate.
  • the MN In communication from the remote UE to the NW, the MN has a function of mapping the RLC bearer of Uu for MN and the RLC bearer of PC5 for SN to RBs between the NW and remote UE.
  • the remote UE identifier added by the remote UE, the relay UE #1 or the relay UE #S, the RB identifier, information about the bearer used for the DC, and the like may be used.
  • the aforementioned functions may be carried by the ADP configured in the MN or relay UE#S.
  • the ADP may aggregate the functions when the DC is configured and when it is not configured.
  • the configuration of the MN or relay UE#S can be facilitated. By doing so, it becomes possible for the MN to map the MCG bearer, SCG bearer, or split bearer for DC to the RB for communication between the remote UE and the NW.
  • RRC should be provided instead of SDAP in the MN and remote UE. It is preferable to provide RRC corresponding to SRB. If DC is configured in SRB, only MN termination bearer may be configured. DC of SRB is enabled.
  • the protocol stack between the MN and the relay UE#S should appropriately apply the configuration disclosed in FIG.
  • remote UEs connected to one gNB via two paths can communicate between NWs via relay UEs.
  • a DC setting method is disclosed in which the remote UE connects to one gNB with two paths.
  • a case will be disclosed in which the remote UE uses the MN and the relay UE#S as a substitute for the SN to set the DC.
  • a case is disclosed where the remote UE connects to the MgNB via the relay UE #1 on one path, the remote UE connects to the relay UE #S on another path, and the relay UE #S connects to the MgNB.
  • MN configures the DC for the remote UE.
  • MN configures DC for RB with remote UE.
  • the RB may be for communication between remote UE and MN.
  • the RB may be SRB and/or DRB.
  • the SRB may be SRB2.
  • the MN sets up the Uu RLC bearer for DC between the MN and the relay UE#1. Used for setting DC for RB between MN and remote UE.
  • a Uu RLC bearer for DC if there is no modification from the existing Uu RLC bearer, no new setting may be performed.
  • the MN sets up an SL bearer for DC between the relay UE#1 and the remote UE.
  • the SL bearer for the DC may be one SL bearer.
  • the SL bearer may be the SL bearer for the MN.
  • the SL bearer may be an SL RLC bearer.
  • the MN sets up the Uu RLC bearer for DC to the relay UE#S.
  • Uu's RLC bearer for the DC may be the RLC bearer to/from the MN.
  • the MN sets up an SL bearer for DC between the relay UE#S and the remote UE.
  • the SL bearer for the 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.
  • the relay UE#1 should be in an RRC connection state with the MN.
  • the relay UE#S should be in an RRC connected state with the MN.
  • the remote UE should be in an RRC connected state with the MN.
  • the MN may also initiate DC configuration for the remote UE when the remote UE is in RRC connection with the MN.
  • a remote UE configured with a DC connects to the CN via the MN in the C-plane.
  • the MN transmits to the relay UE#S a DC setting request for the RB for communication between the remote UE and the MN.
  • the setting request for the DC may be a request for addition of functions as an SN.
  • the add request may be sent using Xn signaling. It may be transmitted using F1 signaling. It may be sent using the S-Node addition request message.
  • the 17 information examples included in the SN addition request disclosed above should be appropriately applied. It is preferable to replace the SN in the information example with the relay UE#S. It is preferable to replace the relay UE in the information example with relay UE#1 and/or relay UE#S. When the relay UE is the relay UE #S, the relay #S functioning as the SN may be information for performing DC setting with the remote UE.
  • the relay UE #1 and/or relay UE #1 and/or relay UE #1 and/or relay UE #1 and/or relay It may include the measurement result of UE#S. It may also include the measurement result of the MN by relay UE#1 and/or relay UE#S.
  • the MN can transmit a DC setting request to the relay UE#S. Also, by receiving the DC setting request from the MN, the relay UE#S can recognize, for example, which remote UE the DC is for. The relay UE#S uses the information received from the MN to make settings for DC as an SN.
  • the MN sends DC settings to the relay UE#S.
  • the DC setting is the above-described case where the remote UE connects directly to the MgNB on one path, the remote UE connects to the relay UE #S on the other path, and the relay UE #S connects to the MgNB. It is preferable to appropriately apply DC settings from the MN to the relay UE#S.
  • the MN sets up an SL bearer between the remote UE and the relay UE#S. If there is an existing SL bearer between the remote UE and relay UE#S, the SL bearer may be modified.
  • the SL bearer configuration may be a configuration for SL bearer modification. The setting of the SL bearer is based on the above-described case where the remote UE connects directly to the MgNB on one path, the remote UE connects to the relay UE #S on another path, and the relay UE #S connects to the MgNB. , MN to the relay UE#S may be applied accordingly.
  • the MN establishes Xn or F1 connection with relay UE#S.
  • the MN may transmit configuration information used for the connection to the relay UE#S.
  • the setting information includes, for example, GTP-u TEID and TNL address (IP address). By doing so, the MN can transmit/receive data to/from the relay UE#S using Xn or F1 instead of Uu.
  • the relay UE#S may perform DC settings for the remote UE.
  • the relay UE #S may configure the DC between the remote UE and the relay UE #S.
  • the relay UE#S may perform DC configuration using information included in the DC configuration request message received from the MN.
  • the SL RRC setting between the remote UE and the relay UE#S may be used as the DC setting for the remote UE.
  • the SL RRC settings may be SL RLC bearer settings, for example.
  • the relay UE#S sends a response message to the DC setting request to the MN.
  • the relay UE#S implements DC configuration, it sends a DC configuration request acknowledgment message to the MN.
  • Xn signaling should be used for transmission. It may be transmitted using F1 signaling.
  • An S-Node addition request acknowledgment message may be used as the DC configuration request acknowledgment message.
  • a new message may be provided. For example, it may be a Relay (DC) request acknowledge message.
  • Information to be included in the DC setting request response message may appropriately apply the information included in the SN addition request response message disclosed above.
  • the relay UE#S If the relay UE#S cannot implement the DC setting, it sends a DC setting request rejection response message to the MN.
  • Xn signaling should be used for transmission. It may be transmitted using F1 signaling.
  • An S-Node addition request reject message may be used as the DC setting request reject response message.
  • a new message may be provided. For example, it may be a Relay (DC) request reject message.
  • the message may include, for example, information about the remote UE and reason information.
  • the MN transmits DC settings to the relay UE#1.
  • the settings for DC the settings for DC from the MN to the relay UE#1 disclosed in Embodiment 5 may be appropriately applied.
  • MN sends configuration for DC to remote UE.
  • Five examples of information to be included in the settings for DC are disclosed.
  • the information about the RLC bearer of Uu in (2) may be absent.
  • the SN identifier in (3) may be omitted.
  • the identifier of the SN may be the identifier of the relay UE#S.
  • the MN sets SL bearers between the remote UE and the relay UE#1 and between the remote UE and the relay UE#S. If there is an existing SL bearer between the remote UE and the relay UE#1 and/or between the remote UE and the relay UE#S, the SL bearer may be modified.
  • the SL bearer configuration may be a configuration for SL bearer modification. Three examples of SL bearer setting information are disclosed. (1) Information about the RLC bearer of SL. (2) Information about SL ADP settings. (3) A combination of (1) and (2).
  • the setting information of the SL bearer it is preferable to appropriately apply the setting information example of the SL bearer disclosed above.
  • the SL bearer between the remote UE and relay UE#1 may be the SL bearer for MN.
  • the SL bearer between the remote UE and relay UE#S may be the SL bearer for SN.
  • the SL bearer settings may be included in the DC settings. You may include the setting information of SL bearer in the setting information for DC.
  • the MN does not need to configure SL RB for remote UE. There is no need to send information about SL and RB. SL PDCP and SL SDAP may not be set.
  • the MN may configure two SL bearers for the DC to the remote UE.
  • the setup of the two SL bearers for the DC may be setup of an SL bearer for the MN and an SL bearer for the SN.
  • the relay UE#S received from the SN and the remote SL bearer configuration information between UEs may be used. It becomes possible to take into consideration the load status in the SN. For example, the MN may set the SL bearer setting information between the remote UE and the relay UE#S to be the same as the SL bearer setting information between the remote UE and the relay UE#S received from the relay UE#S. The setting of the SL bearer in the remote UE and the relay UE#S becomes the same, and malfunction in SL communication can be reduced.
  • the remote UE Upon receiving the SL bearer setting information for DC from the MN, the remote UE establishes a PC5 connection with the relay UE#S.
  • the remote UE that has established the PC5 connection with the relay UE#S sets up an SL bearer for DC with the relay UE#S.
  • the relay UE#S that has established the PC5 connection with the remote UE sets up an SL bearer for DC with the remote UE.
  • the remote UE may notify the relay UE#S of the SL RRC setting.
  • the relay UE#S may notify the remote UE of the SL RRC setting.
  • Data communication between the remote UE and the NW is performed by the MCG bearer between the remote UE and the MN via the relay UE#1, the SCG bearer between the remote UE and the MN via the relay UE#S, or the relay UE#1. between the remote UE and the MN via the relay UE#S and between the remote UE and the MN via the relay UE#S.
  • FIG. 58 is a sequence diagram showing an example of a DC setting method in which a remote UE connects to one gNB via two paths, according to the sixth embodiment.
  • the remote UE uses the MN and the relay UE#S that substitutes for the SN to configure the DC.
  • a case is disclosed where the remote UE connects to the MgNB via the relay UE #1 on one path, the remote UE connects to the relay UE #S on another path, and the relay UE #S connects to the MgNB.
  • steps common to those in FIGS. 47 and 56 are assigned the same step numbers, and common descriptions are omitted.
  • step ST5001 data communication is performed among the remote UE, relay UE#1, MN, and UPF.
  • MN decides to set up a DC for the remote UE. For example, MN determines relay UE#S to be used for DC from the measurement result of remote UE.
  • steps ST5901 and ST5902 transmission and reception of a DC setting request and a DC setting request response are performed between the MN and the relay UE#S. As a result, DC setting to the remote UE is performed in the relay UE#S.
  • steps ST5005 and ST5007 transmission/reception of DC settings and SL bearer settings, and transmission/reception of DC setting responses and SL bearer setting responses are performed between the MN and the relay UE#1.
  • the relay UE #1 can configure the DC configuration between the MN and the relay UE #1 and the SL bearer configuration between the remote UE and the relay UE #1. .
  • steps ST5006 and ST5008 transmission/reception of DC settings and SL bearer settings, and transmission/reception of DC setting responses and SL bearer setting responses are performed between the MN and the remote UE.
  • the RRC setting information received from the relay UE#S may be used as the setting related to the SL bearer setting information.
  • the remote UE By receiving DC settings and SL bearer settings from the MN, the remote UE performs DC settings between the MN and the remote UE, SL bearer settings between the remote UE and the relay UE#1, and remote UE and the relay UE#.
  • SL bearers between S can be set.
  • DC is performed between the remote UE, the MN via the relay UE#1, and the relay UE#S. That is, in step ST6110, data communication is performed among the remote UE, relay UE#1, relay UE#S, MN, and UPF.
  • Configurable DCs may only be MN terminated bearers. It is possible to facilitate the configuration of the relay UE#S without connecting the relay UE#S directly to the CN. For example, in case of MN terminated SCG bearer, data communication is performed between MN and UPF via remote UE, relay UE#S and relay UE#1. For example, in the case of MN terminated split bearer, data communication is performed between MN and UPF via remote UE, relay UE#S and relay UE#1.
  • the remote UE to set a DC that connects the MgNB and the relay UE#S.
  • DC is possible in indirect communication between the remote UE and the NW via the relay UE.
  • performance improvements such as high speed, large capacity, low delay, and high reliability can be achieved.
  • DC is possible without using multiple RAN nodes.
  • DC is possible even in situations where the remote UE cannot directly or indirectly connect with multiple RAN nodes.
  • the relay UE does not need to be connected to multiple RAN nodes.
  • multicast operation using an IAB base station may be applied to communication between a remote UE and a gNB via a relay UE, e.g., multicast from a gNB to a remote UE via a relay UE.
  • BAP layer operations may be performed, for example, in the adaptation protocol. This makes it possible, for example, to reduce radio resources in multicasting from the gNB to the remote UEs.
  • the combination of multicast operation with IAB base stations and communication between remote UE and gNB via relay UE e.g., communication from gNB to remote UE via relay UE is used good too.
  • Communication from the gNB to the remote UE may be broadcast, groupcast, or unicast.
  • a combination of multicast with IAB base stations and groupcast from gNB to remote UEs allows for increased efficiency in the communication system.
  • gNBs or cells are described in the present disclosure, they may be gNBs or cells unless otherwise specified.
  • a subframe is an example of a communication time unit in the fifth generation communication system.
  • a subframe may be a scheduling unit.
  • the processing described in units of subframes may be performed in units of TTIs, slots, subslots, or minislots.
  • V2X Vehicle-to-everything
  • SL communication used in various services such as proximity-based service, public safety, communication between wearable terminals, and communication between devices in factories.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Multimedia (AREA)
  • Databases & Information Systems (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

通信システムは、中央ユニット（ＩＡＢ－Ｄｏｎｏｒ　ＣＵ）および分散ユニット（ＩＡＢ－Ｄｏｎｏｒ　ＤＵ）で構成され、アクセス・バックホール統合のドナーとして動作する第１の基地局と、アクセス・バックホール統合のノード（ＩＡＢ－ｎｏｄｅ）として動作する１つ以上の第２の基地局と、を含み、中央ユニットが分散ユニットおよび第２の基地局に対して、通信端末が送受信するデータのルーティングを行うバックホールアダプテーションレイヤにおいて中央ユニットから通信端末に向けてデータをマルチキャストするためのアドレス設定を行う。

Description

通信システムおよび基地局
　本開示は、無線通信技術に関する。
　移動体通信システムの規格化団体である３ＧＰＰ（3rd　Generation　Partnership　Project）において、無線区間についてはロングタームエボリューション（Long　Term　Evolution：ＬＴＥ）と称し、コアネットワークおよび無線アクセスネットワーク（以下、まとめて、ネットワークとも称する）を含めたシステム全体構成については、システムアーキテクチャエボリューション（System　Architecture　Evolution：ＳＡＥ）と称される通信方式が検討されている（例えば、非特許文献１～５）。この通信方式は３．９Ｇ（3.9　Generation）システムとも呼ばれる。
　ＬＴＥのアクセス方式としては、下り方向はＯＦＤＭ（Orthogonal　Frequency　Division　Multiplexing）、上り方向はＳＣ－ＦＤＭＡ（Single　Carrier　Frequency　Division　Multiple　Access）が用いられる。また、ＬＴＥは、Ｗ－ＣＤＭＡ（Wideband　Code　Division　Multiple　Access）とは異なり、回線交換を含まず、パケット通信方式のみになる。
　非特許文献１（５章）に記載される、３ＧＰＰでの、ＬＴＥシステムにおけるフレーム構成に関する決定事項について、図１を用いて説明する。図１は、ＬＴＥ方式の通信システムで使用される無線フレームの構成を示す説明図である。図１において、１つの無線フレーム（Radio　frame）は１０ｍｓである。無線フレームは１０個の等しい大きさのサブフレーム（Subframe）に分割される。サブフレームは、２個の等しい大きさのスロット（slot）に分割される。無線フレーム毎に１番目および６番目のサブフレームに下り同期信号（Downlink　Synchronization　Signal）が含まれる。同期信号には、第一同期信号（Primary　Synchronization　Signal：Ｐ－ＳＳ）と、第二同期信号（Secondary　Synchronization　Signal：Ｓ－ＳＳ）とがある。
　３ＧＰＰでの、ＬＴＥシステムにおけるチャネル構成に関する決定事項が、非特許文献１（５章）に記載されている。ＣＳＧ（Closed　Subscriber　Group）セルにおいてもｎｏｎ－ＣＳＧセルと同じチャネル構成が用いられると想定されている。
　物理報知チャネル（Physical　Broadcast　Channel：ＰＢＣＨ）は、基地局装置（以下、単に「基地局」という場合がある）から移動端末装置（以下、単に「移動端末」という場合がある）などの通信端末装置（以下、単に「通信端末」という場合がある）への下り送信用のチャネルである。ＢＣＨトランスポートブロック（transport　block）は、４０ｍｓ間隔中の４個のサブフレームにマッピングされる。４０ｍｓタイミングの明白なシグナリングはない。
　物理制御フォーマットインジケータチャネル（Physical　Control　Format　Indicator　Channel：ＰＣＦＩＣＨ）は、基地局から通信端末への下り送信用のチャネルである。ＰＣＦＩＣＨは、ＰＤＣＣＨｓのために用いるＯＦＤＭ（Orthogonal　Frequency　Division　Multiplexing）シンボルの数を、基地局から通信端末へ通知する。ＰＣＦＩＣＨは、サブフレーム毎に送信される。
　物理下り制御チャネル（Physical　Downlink　Control　Channel：ＰＤＣＣＨ）は、基地局から通信端末への下り送信用のチャネルである。ＰＤＣＣＨは、後述のトランスポートチャネルの１つである下り共有チャネル（Downlink　Shared　Channel：ＤＬ－ＳＣＨ）のリソース割り当て（allocation）情報、後述のトランスポートチャネルの１つであるページングチャネル（Paging　Channel：ＰＣＨ）のリソース割り当て（allocation）情報、ＤＬ－ＳＣＨに関するＨＡＲＱ（Hybrid　Automatic　Repeat　reQuest）情報を通知する。ＰＤＣＣＨは、上りスケジューリンググラント（Uplink　Scheduling　Grant）を運ぶ。ＰＤＣＣＨは、上り送信に対する応答信号であるＡｃｋ（Acknowledgement）／Ｎａｃｋ（Negative　Acknowledgement）を運ぶ。ＰＤＣＣＨは、Ｌ１／Ｌ２制御信号とも呼ばれる。
　物理下り共有チャネル（Physical　Downlink　Shared　Channel：ＰＤＳＣＨ）は、基地局から通信端末への下り送信用のチャネルである。ＰＤＳＣＨには、トランスポートチャネルである下り共有チャネル（ＤＬ－ＳＣＨ）、およびトランスポートチャネルであるＰＣＨがマッピングされている。
　物理マルチキャストチャネル（Physical　Multicast　Channel：ＰＭＣＨ）は、基地局から通信端末への下り送信用のチャネルである。ＰＭＣＨには、トランスポートチャネルであるマルチキャストチャネル（Multicast　Channel：ＭＣＨ）がマッピングされている。
　物理上り制御チャネル（Physical　Uplink　Control　Channel：ＰＵＣＣＨ）は、通信端末から基地局への上り送信用のチャネルである。ＰＵＣＣＨは、下り送信に対する応答信号（response　signal）であるＡｃｋ／Ｎａｃｋを運ぶ。ＰＵＣＣＨは、ＣＳＩ（Channel　State　Information）を運ぶ。ＣＳＩは、ＲＩ（Rank　Indicator）、ＰＭＩ（Precoding　Matrix　Indicator）、ＣＱＩ（Channel　Quality　Indicator）レポートで構成される。ＲＩとは、ＭＩＭＯにおけるチャネル行列のランク情報である。ＰＭＩとは、ＭＩＭＯにて用いるプリコーディングウェイト行列の情報である。ＣＱＩとは、受信したデータの品質、もしくは通信路品質を示す品質情報である。またＰＵＣＣＨは、スケジューリングリクエスト（Scheduling　Request：ＳＲ）を運ぶ。
　物理上り共有チャネル（Physical　Uplink　Shared　Channel：ＰＵＳＣＨ）は、通信端末から基地局への上り送信用のチャネルである。ＰＵＳＣＨには、トランスポートチャネルの１つである上り共有チャネル（Uplink　Shared　Channel：ＵＬ－ＳＣＨ）がマッピングされている。
　物理ＨＡＲＱインジケータチャネル（Physical　Hybrid　ARQ　Indicator　Channel：ＰＨＩＣＨ）は、基地局から通信端末への下り送信用のチャネルである。ＰＨＩＣＨは、上り送信に対する応答信号であるＡｃｋ／Ｎａｃｋを運ぶ。物理ランダムアクセスチャネル（Physical　Random　Access　Channel：ＰＲＡＣＨ）は、通信端末から基地局への上り送信用のチャネルである。ＰＲＡＣＨは、ランダムアクセスプリアンブル（random　access　preamble）を運ぶ。
　下り参照信号（リファレンスシグナル（Reference　Signal）：ＲＳ）は、ＬＴＥ方式の通信システムとして既知のシンボルである。以下の５種類の下りリファレンスシグナルが定義されている。セル固有参照信号（Cell-specific　Reference　Signal：ＣＲＳ）、ＭＢＳＦＮ参照信号（MBSFN　Reference　Signal）、ＵＥ固有参照信号（UE-specific　Reference　Signal）であるデータ復調用参照信号（Demodulation　Reference　Signal：ＤＭ－ＲＳ）、位置決定参照信号（Positioning　Reference　Signal：ＰＲＳ）、チャネル状態情報参照信号（Channel　State　Information　Reference　Signal：ＣＳＩ－ＲＳ）。通信端末の物理レイヤの測定として、リファレンスシグナルの受信電力（Reference　Signal　Received　Power：ＲＳＲＰ）測定がある。
　上り参照信号についても同様に、ＬＴＥ方式の通信システムとして既知のシンボルである。以下の２種類の上りリファレンスシグナルが定義されている。データ復調用参照信号（Demodulation　Reference　Signal：ＤＭ－ＲＳ）、サウンディング用参照信号（Sounding　Reference　Signal：ＳＲＳ）である。
　非特許文献１（５章）に記載されるトランスポートチャネル（Transport　Channel）について、説明する。下りトランスポートチャネルのうち、報知チャネル（Broadcast　Channel：ＢＣＨ）は、その基地局（セル）のカバレッジ全体に報知される。ＢＣＨは、物理報知チャネル（ＰＢＣＨ）にマッピングされる。
　下り共有チャネル（Downlink　Shared　Channel：ＤＬ－ＳＣＨ）には、ＨＡＲＱ（Hybrid　ARQ）による再送制御が適用される。ＤＬ－ＳＣＨは、基地局（セル）のカバレッジ全体への報知が可能である。ＤＬ－ＳＣＨは、ダイナミックあるいは準静的（Semi-static）なリソース割り当てをサポートする。準静的なリソース割り当ては、パーシステントスケジューリング（Persistent　Scheduling）ともいわれる。ＤＬ－ＳＣＨは、通信端末の低消費電力化のために通信端末の間欠受信（Discontinuous　reception：ＤＲＸ）をサポートする。ＤＬ－ＳＣＨは、物理下り共有チャネル（ＰＤＳＣＨ）へマッピングされる。
　ページングチャネル（Paging　Channel：ＰＣＨ）は、通信端末の低消費電力を可能とするために通信端末のＤＲＸをサポートする。ＰＣＨは、基地局（セル）のカバレッジ全体への報知が要求される。ＰＣＨは、動的にトラフィックに利用できる物理下り共有チャネル（ＰＤＳＣＨ）のような物理リソースへマッピングされる。
　マルチキャストチャネル（Multicast　Channel：ＭＣＨ）は、基地局（セル）のカバレッジ全体への報知に使用される。ＭＣＨは、マルチセル送信におけるＭＢＭＳ（Multimedia　Broadcast　Multicast　Service）サービス（ＭＴＣＨとＭＣＣＨ）のＳＦＮ合成をサポートする。ＭＣＨは、準静的なリソース割り当てをサポートする。ＭＣＨは、ＰＭＣＨへマッピングされる。
　上りトランスポートチャネルのうち、上り共有チャネル（Uplink　Shared　Channel：ＵＬ－ＳＣＨ）には、ＨＡＲＱ（Hybrid　ARQ）による再送制御が適用される。ＵＬ－ＳＣＨは、ダイナミックあるいは準静的（Semi-static）なリソース割り当てをサポートする。ＵＬ－ＳＣＨは、物理上り共有チャネル（ＰＵＳＣＨ）へマッピングされる。
　ランダムアクセスチャネル（Random　Access　Channel：ＲＡＣＨ）は、制御情報に限られている。ＲＡＣＨは、衝突のリスクがある。ＲＡＣＨは、物理ランダムアクセスチャネル（ＰＲＡＣＨ）へマッピングされる。
　ＨＡＲＱについて説明する。ＨＡＲＱとは、自動再送要求（Automatic　Repeat　reQuest：ＡＲＱ）と誤り訂正（Forward　Error　Correction）との組合せによって、伝送路の通信品質を向上させる技術である。ＨＡＲＱには、通信品質が変化する伝送路に対しても、再送によって誤り訂正が有効に機能するという利点がある。特に、再送にあたって初送の受信結果と再送の受信結果との合成をすることで、更なる品質向上を得ることも可能である。
　再送の方法の一例を説明する。受信側にて、受信データが正しくデコードできなかった場合、換言すればＣＲＣ（Cyclic　Redundancy　Check）エラーが発生した場合（ＣＲＣ＝ＮＧ）、受信側から送信側へ「Ｎａｃｋ」を送信する。「Ｎａｃｋ」を受信した送信側は、データを再送する。受信側にて、受信データが正しくデコードできた場合、換言すればＣＲＣエラーが発生しない場合（ＣＲＣ＝ＯＫ）、受信側から送信側へ「Ａｃｋ」を送信する。「Ａｃｋ」を受信した送信側は次のデータを送信する。
　非特許文献１（６章）に記載される論理チャネル（ロジカルチャネル：Logical　Channel）について、説明する。報知制御チャネル（Broadcast　Control　Channel：ＢＣＣＨ）は、報知システム制御情報のための下りチャネルである。論理チャネルであるＢＣＣＨは、トランスポートチャネルである報知チャネル（ＢＣＨ）、あるいは下り共有チャネル（ＤＬ－ＳＣＨ）へマッピングされる。
　ページング制御チャネル（Paging　Control　Channel：ＰＣＣＨ）は、ページング情報（Paging　Information）およびシステム情報（System　Information）の変更を送信するための下りチャネルである。ＰＣＣＨは、通信端末のセルロケーションをネットワークが知らない場合に用いられる。論理チャネルであるＰＣＣＨは、トランスポートチャネルであるページングチャネル（ＰＣＨ）へマッピングされる。
　共有制御チャネル（Common　Control　Channel：ＣＣＣＨ）は、通信端末と基地局との間の送信制御情報のためのチャネルである。ＣＣＣＨは、通信端末がネットワークとの間でＲＲＣ接続（connection）を有していない場合に用いられる。下り方向では、ＣＣＣＨは、トランスポートチャネルである下り共有チャネル（ＤＬ－ＳＣＨ）へマッピングされる。上り方向では、ＣＣＣＨは、トランスポートチャネルである上り共有チャネル（ＵＬ－ＳＣＨ）へマッピングされる。
　マルチキャスト制御チャネル（Multicast　Control　Channel：ＭＣＣＨ）は、１対多の送信のための下りチャネルである。ＭＣＣＨは、ネットワークから通信端末への１つあるいはいくつかのＭＴＣＨ用のＭＢＭＳ制御情報の送信のために用いられる。ＭＣＣＨは、ＭＢＭＳ受信中の通信端末のみに用いられる。ＭＣＣＨは、トランスポートチャネルであるマルチキャストチャネル（ＭＣＨ）へマッピングされる。
　個別制御チャネル（Dedicated　Control　Channel：ＤＣＣＨ）は、１対１にて、通信端末とネットワークとの間の個別制御情報を送信するチャネルである。ＤＣＣＨは、通信端末がＲＲＣ接続（connection）である場合に用いられる。ＤＣＣＨは、上りでは上り共有チャネル（ＵＬ－ＳＣＨ）へマッピングされ、下りでは下り共有チャネル（ＤＬ－ＳＣＨ）にマッピングされる。
　個別トラフィックチャネル（Dedicated　Traffic　Channel：ＤＴＣＨ）は、ユーザ情報の送信のための個別通信端末への１対１通信のチャネルである。ＤＴＣＨは、上りおよび下りともに存在する。ＤＴＣＨは、上りでは上り共有チャネル（ＵＬ－ＳＣＨ）へマッピングされ、下りでは下り共有チャネル（ＤＬ－ＳＣＨ）へマッピングされる。
　マルチキャストトラフィックチャネル（Multicast　Traffic　Channel：ＭＴＣＨ）は、ネットワークから通信端末へのトラフィックデータ送信のための下りチャネルである。ＭＴＣＨは、ＭＢＭＳ受信中の通信端末のみに用いられるチャネルである。ＭＴＣＨは、マルチキャストチャネル（ＭＣＨ）へマッピングされる。
　ＣＧＩとは、セルグローバル識別子（Cell　Global　Identifier）のことである。ＥＣＧＩとは、Ｅ－ＵＴＲＡＮセルグローバル識別子（E-UTRAN　Cell　Global　Identifier）のことである。ＬＴＥ、後述のＬＴＥ－Ａ（Long　Term　Evolution　Advanced）およびＵＭＴＳ（Universal　Mobile　Telecommunication　System）において、ＣＳＧ（Closed　Subscriber　Group）セルが導入される。
　通信端末の位置追跡は、１つ以上のセルからなる区域を単位に行われる。位置追跡は、待受け状態であっても通信端末の位置を追跡し、通信端末を呼び出す、換言すれば通信端末が着呼することを可能にするために行われる。この通信端末の位置追跡のための区域をトラッキングエリアと呼ぶ。
　また３ＧＰＰでは、リリース１０として、ロングタームエボリューションアドヴァンスド（Long　Term　Evolution　Advanced：ＬＴＥ－Ａ）の規格策定が進められている（非特許文献３、非特許文献４参照）。ＬＴＥ－Ａは、ＬＴＥの無線区間通信方式を基本とし、それにいくつかの新技術を加えて構成される。
　ＬＴＥ－Ａシステムでは、１００ＭＨｚまでのより広い周波数帯域幅（transmission　bandwidths）をサポートするために、二つ以上のコンポーネントキャリア（Component　Carrier：ＣＣ）を集約する（「アグリゲーション（aggregation）する」とも称する）、キャリアアグリゲーション（Carrier　Aggregation：ＣＡ）が検討されている。ＣＡについては、非特許文献１に記載されている。
　ＣＡが構成される場合、通信端末であるＵＥはネットワーク（Network：ＮＷ）と唯一のＲＲＣ接続（RRC　connection）を有する。ＲＲＣ接続において、１つのサービングセルがＮＡＳモビリティ情報とセキュリティ入力を与える。このセルをプライマリセル（Primary　Cell：ＰＣｅｌｌ）と呼ぶ。下りリンクで、ＰＣｅｌｌに対応するキャリアは、下りプライマリコンポーネントキャリア（Downlink　Primary　Component　Carrier：ＤＬ　ＰＣＣ）である。上りリンクで、ＰＣｅｌｌに対応するキャリアは、上りプライマリコンポーネントキャリア（Uplink　Primary　Component　Carrier：ＵＬ　ＰＣＣ）である。
　ＵＥの能力（ケーパビリティ（capability））に応じて、セカンダリセル（Secondary　Cell：ＳＣｅｌｌ）が、ＰＣｅｌｌとともに、サービングセルの組を形成するために構成される。下りリンクで、ＳＣｅｌｌに対応するキャリアは、下りセカンダリコンポーネントキャリア（Downlink　Secondary　Component　Carrier：ＤＬ　ＳＣＣ）である。上りリンクで、ＳＣｅｌｌに対応するキャリアは、上りセカンダリコンポーネントキャリア（Uplink　Secondary　Component　Carrier：ＵＬ　ＳＣＣ）である。
　１つのＰＣｅｌｌと１つ以上のＳＣｅｌｌとからなるサービングセルの組が、１つのＵＥに対して構成される。
　また、ＬＴＥ－Ａでの新技術としては、より広い帯域をサポートする技術（Wider　bandwidth　extension）、および多地点協調送受信（Coordinated　Multiple　Point　transmission　and　reception：ＣｏＭＰ）技術などがある。３ＧＰＰでＬＴＥ－Ａのために検討されているＣｏＭＰについては、非特許文献１に記載されている。
　また、３ＧＰＰにおいて、将来の膨大なトラフィックに対応するために、スモールセルを構成するスモールｅＮＢ（以下「小規模基地局装置」という場合がある）を用いることが検討されている。例えば、多数のスモールｅＮＢを設置して、多数のスモールセルを構成することによって、周波数利用効率を高めて、通信容量の増大を図る技術などが検討されている。具体的には、ＵＥが２つのｅＮＢと接続して通信を行うデュアルコネクティビティ（Dual　Connectivity：ＤＣと略称される）などがある。ＤＣについては、非特許文献１に記載されている。
　デュアルコネクティビティ（ＤＣ）を行うｅＮＢのうち、一方を「マスタｅＮＢ（ＭｅＮＢと略称される）」といい、他方を「セカンダリｅＮＢ（ＳｅＮＢと略称される）」という場合がある。
　モバイルネットワークのトラフィック量は、増加傾向にあり、通信速度も高速化が進んでいる。ＬＴＥおよびＬＴＥ－Ａが本格的に運用を開始されると、更に通信速度が高速化されることが見込まれる。
　さらに、高度化する移動体通信に対して、２０２０年以降にサービスを開始することを目標とした第５世代（以下「５Ｇ」という場合がある）無線アクセスシステムが検討されている。例えば、欧州では、ＭＥＴＩＳという団体で５Ｇの要求事項がまとめられている（非特許文献５参照）。
　５Ｇ無線アクセスシステムでは、ＬＴＥシステムに対して、システム容量は１０００倍、データの伝送速度は１００倍、データの処理遅延は１０分の１（１／１０）、通信端末の同時接続数は１００倍として、更なる低消費電力化、および装置の低コスト化を実現することが要件として挙げられている。
　このような要求を満たすために、３ＧＰＰでは、リリース１５として、５Ｇの規格検討が進められている（非特許文献６～１９参照）。５Ｇの無線区間の技術は「New　Radio　Access　Technology」と称される（「New　Radio」は「ＮＲ」と略称される）。
　ＮＲシステムは、ＬＴＥシステム、ＬＴＥ－Ａシステムを基にして検討が進められているが、以下の点でＬＴＥシステム、ＬＴＥ－Ａシステムからの変更および追加が行われている。
　ＮＲのアクセス方式としては、下り方向はＯＦＤＭ、上り方向はＯＦＤＭ、ＤＦＴ－ｓ－ＯＦＤＭ（DFT-spread-OFDM）が用いられる。
　ＮＲでは、伝送速度向上、処理遅延低減のために、ＬＴＥに比べて高い周波数の使用が可能となっている。
　ＮＲにおいては、狭いビーム状の送受信範囲を形成する（ビームフォーミング）とともにビームの向きを変化させる（ビームスイーピング）ことで、セルカバレッジの確保が図られる。
　ＮＲのフレーム構成においては、様々なサブキャリア間隔、すなわち、様々なヌメロロジ（Numerology）がサポートされている。ＮＲにおいては、ヌメロロジによらず、１サブフレームは１ミリ秒であり、また、１スロットは１４シンボルで構成される。また、１サブフレームに含まれるスロット数は、サブキャリア間隔１５ｋＨｚのヌメロロジにおいては１つであり、他のヌメロロジにおいては、サブキャリア間隔に比例して多くなる（非特許文献１３（３ＧＰＰ　ＴＳ３８．２１１）参照）。
　ＮＲにおける下り同期信号は、同期信号バースト（Synchronization　Signal　Burst：以下、ＳＳバーストと称する場合がある）として、所定の周期で、所定の継続時間をもって基地局から送信される。ＳＳバーストは、基地局のビーム毎の同期信号ブロック（Synchronization　Signal　Block：以下、ＳＳブロックと称する場合がある）により構成される。
　基地局はＳＳバーストの継続時間内において各ビームのＳＳブロックを、ビームを変えて送信する。ＳＳブロックは、Ｐ－ＳＳ、Ｓ－ＳＳ、およびＰＢＣＨによって構成される。
　ＮＲにおいては、ＮＲの下り参照信号として、位相追尾参照信号（Phase　Tracking　Reference　Signal：ＰＴＲＳ）の追加により、位相雑音の影響の低減が図られている。上り参照信号においても、下りと同様にＰＴＲＳが追加されている。
　ＮＲにおいては、スロット内におけるＤＬ／ＵＬの切替えを柔軟に行うために、ＰＤＣＣＨに含まれる情報にスロット構成通知（Slot　Format　Indication：ＳＦＩ）が追加された。
　また、ＮＲにおいては、キャリア周波数帯のうちの一部（以下、Bandwidth　Part（ＢＷＰ）と称する場合がある）を基地局がＵＥに対して予め設定し、ＵＥが該ＢＷＰにおいて基地局との送受信を行うことで、ＵＥにおける消費電力の低減が図られる。
　３ＧＰＰでは、ＤＣの形態として、ＥＰＣに接続するＬＴＥ基地局とＮＲ基地局によるＤＣ、５Ｇコアシステムに接続するＮＲ基地局によるＤＣ、また、５Ｇコアシステムに接続するＬＴＥ基地局とＮＲ基地局によるＤＣが検討されている（非特許文献１２、１６、１９参照）。
　また、３ＧＰＰでは、サイドリンク（ＳＬ：Side　Link）通信（ＰＣ５通信とも称する）を用いたサービス（アプリケーションでもよい）を、後述するＥＰＳ（Evolved　Packet　System）においても、５Ｇコアシステムにおいてもサポートすることが検討されている（非特許文献１、１６、２０、２１、２２、２３参照）。ＳＬ通信では端末間で通信が行われる。ＳＬ通信を用いたサービスとして、たとえば、Ｖ２Ｘ（Vehicle-to-everything）サービス、プロキシミティサービスなどがある。ＳＬ通信においては、端末間の直接通信だけでなく、リレー（relay）を介したＵＥとＮＷとの間の通信が提案されている（非特許文献２０、２３、２６、２７参照）。
　また、３ＧＰＰでは、いくつかの新たな技術が検討されている。例えば、ＮＲを用いたマルチキャストが検討されている。ＮＲを用いたマルチキャストにおいて、例えば、信頼性を確保したマルチキャスト方式、ポイントツーマルチポイント（Point　To　Multipoint：ＰＴＭ）送信とポイントツーポイント（Point　To　Point：ＰＴＰ）送信の動的な切替えが検討されている（非特許文献２８、２９、３０参照）。また、ＣＵ（Central　Unit：中央ユニット）／ＤＵ（Distributed　Unit：分散ユニット）分離構成の基地局におけるマルチキャストについても検討されている（非特許文献３１参照）。
　他の例として、ＵＥと基地局との間のリンクであるアクセスリンク、基地局間のリンクであるバックホールリンクをいずれも無線で行うアクセス・バックホール統合（Integrated　Access　and　Backhaul：ＩＡＢ）が検討されている（非特許文献１６、３２、３３参照）。
３ＧＰＰ　ＴＳ　３６．３００　Ｖ１６．５．０ ３ＧＰＰ　Ｓ１－０８３４６１ ３ＧＰＰ　ＴＲ　３６．８１４　Ｖ９．２．０ ３ＧＰＰ　ＴＲ　３６．９１２　Ｖ１６．０．０ "Scenarios,　requirements　and　KPIs　for　5G　mobile　and　wireless　system"、ＩＣＴ－３１７６６９－ＭＥＴＩＳ／Ｄ１．１ ３ＧＰＰ　ＴＲ　２３．７９９　Ｖ１４．０．０ ３ＧＰＰ　ＴＲ　３８．８０１　Ｖ１４．０．０ ３ＧＰＰ　ＴＲ　３８．８０２　Ｖ１４．２．０ ３ＧＰＰ　ＴＲ　３８．８０４　Ｖ１４．０．０ ３ＧＰＰ　ＴＲ　３８．９１２　Ｖ１６．０．０ ３ＧＰＰ　ＲＰ－１７２１１５ ３ＧＰＰ　ＴＳ　３７．３４０　Ｖ１６．５．０ ３ＧＰＰ　ＴＳ　３８．２１１　Ｖ１６．５．０ ３ＧＰＰ　ＴＳ　３８．２１３　Ｖ１６．５．０ ３ＧＰＰ　ＴＳ　３８．２１４　Ｖ１６．５．０ ３ＧＰＰ　ＴＳ　３８．３００　Ｖ１６．５．０ ３ＧＰＰ　ＴＳ　３８．３２１　Ｖ１６．４．０ ３ＧＰＰ　ＴＳ　３８．２１２　Ｖ１６．５．０ ３ＧＰＰ　ＴＳ　３８．３３１　Ｖ１６．４．１ ３ＧＰＰ　ＴＲ　２３．７０３　Ｖ１２．０．０ ３ＧＰＰ　ＴＳ　２３．５０１　Ｖ１７．０．０ ３ＧＰＰ　ＴＳ　２３．２８７　Ｖ１６．５．０ ３ＧＰＰ　ＴＳ　２３．３０３　Ｖ１６．０．０ ３ＧＰＰ　ＴＳ　３８．３０５　Ｖ１６．４．０ ３ＧＰＰ　ＴＳ　２３．２７３　Ｖ１７．０．０ ３ＧＰＰ　Ｒ２－２００９１４５ ３ＧＰＰ　ＴＲ　３８．８３６　Ｖ１７．０．０ ３ＧＰＰ　ＴＲ　２３．７５７　Ｖ１７．０．０ ３ＧＰＰ　ＲＰ－２０１０３８ ３ＧＰＰ　Ｒ２－２００９３３７ ３ＧＰＰ　Ｒ３－２１１０２９ ３ＧＰＰ　ＲＰ－２０１２９３ ３ＧＰＰ　ＴＳ　３８．４０１　Ｖ１６．５．０ ３ＧＰＰ　ＴＳ　３６．３２１　Ｖ１６．４．０ ３ＧＰＰ　ＴＳ　３８．４７３　Ｖ１６．５．０ ３ＧＰＰ　ＴＳ　３８．３４０　Ｖ１６．４．０ ３ＧＰＰ　ＴＳ　２３．５０２　Ｖ１７．０．０ ３ＧＰＰ　ＴＳ　３８．４１３　Ｖ１６．５．０ ３ＧＰＰ　ＴＳ　３８．３２３　Ｖ１６．３．０ ３ＧＰＰ　ＴＳ　３８．３２２　Ｖ１６．２．０ ３ＧＰＰ　Ｒ３－２１００１７
　５Ｇ方式の基地局は、アクセス・バックホール統合（Integrated　Access　and　Backhaul：ＩＡＢ）（非特許文献１６（ＴＳ３８．３００）参照）をサポート可能である。また、ＩＡＢをサポートする基地局（以下、ＩＡＢ基地局と称する場合がある）を用いて、マルチキャストを行うことが提案されている（非特許文献４１（Ｒ３－２１００１７）参照）。ところが、ＩＡＢ基地局におけるマルチキャストの詳細な設定方法、特に、ＩＡＢノード間のルーティング等を行うＢＡＰ（Backhaul　Adaptation　Protocol）レイヤにおける設定等が開示されていない。従って、ＩＡＢ基地局を用いたマルチキャストが実現できない、という問題が生じる。
　本開示は、上記課題に鑑み、アクセス・バックホール統合を適用した通信システムにおいてマルチキャスト送信を可能にすることを、目的の１つとする。
　本開示にかかる通信システムは、中央ユニットおよび分散ユニットで構成され、アクセス・バックホール統合のドナーとして動作する第１の基地局と、アクセス・バックホール統合のノードとして動作する１つ以上の第２の基地局と、を含み、中央ユニットが分散ユニットおよび第２の基地局に対して、通信端末が送受信するデータのルーティングを行うバックホールアダプテーションレイヤにおいて中央ユニットから通信端末に向けてデータをマルチキャストするためのアドレス設定を行う。
　本開示によれば、アクセス・バックホール統合を適用した通信システムにおいてマルチキャスト送信が可能となる、という効果を奏する。
　本開示の目的、特徴、局面、および利点は、以下の詳細な説明と添付図面とによって、より明白となる。
ＬＴＥ方式の通信システムで使用される無線フレームの構成を示す説明図である。 ３ＧＰＰにおいて議論されているＬＴＥ方式の通信システム２００の全体的な構成を示すブロック図である。 ３ＧＰＰにおいて議論されているＮＲ方式の通信システム２１０の全体的な構成を示すブロック図である。 ＥＰＣに接続するｅＮＢおよびｇＮＢによるＤＣの構成図である。 ＮＧコアに接続するｇＮＢによるＤＣの構成図である。 ＮＧコアに接続するｅＮＢおよびｇＮＢによるＤＣの構成図である。 ＮＧコアに接続するｅＮＢおよびｇＮＢによるＤＣの構成図である。 図２に示す移動端末２０２の構成を示すブロック図である。 図２に示す基地局２０３の構成を示すブロック図である。 ＭＭＥの構成を示すブロック図である。 ５ＧＣ部の構成を示すブロック図である。 ＬＴＥ方式の通信システムにおいて通信端末（ＵＥ）が行うセルサーチから待ち受け動作までの概略を示すフローチャートである。 ＮＲシステムにおけるセルの構成の一例を示す図である。 実施の形態１について、ＢＡＰアドレスのリストの例を示す図である。 実施の形態１について、ＢＡＰヘッダの一例を示す図である。 実施の形態１について、ＢＡＰヘッダの他の例を示す図である。 実施の形態１について、ＢＡＰヘッダの他の例を示す図である。 実施の形態１について、ＢＡＰヘッダの他の例を示す図である。 実施の形態１について、ＢＡＰヘッダの他の例を示す図である。 実施の形態１について、ＢＡＰヘッダの他の例を示す図である。 実施の形態１について、ＩＡＢ基地局におけるマルチキャストの設定の例を示すシーケンスの前半部分を示す図である。 実施の形態１について、ＩＡＢ基地局におけるマルチキャストの設定の例を示すシーケンスの後半部分を示す図である。 実施の形態１について、マルチキャスト用ＢＡＰアドレスの割当ての一例を示す図である。 実施の形態１について、マルチキャスト用ＢＡＰアドレスの割当ての他の例を示す図である。 実施の形態１について、マルチキャスト用ＢＡＰアドレスの割当ての他の例を示す図である。 実施の形態１について、マルチキャスト用ＢＡＰアドレスの割当ての他の例を示す図である。 実施の形態１について、マルチキャスト用ＢＡＰアドレスのビットマップを示した図である。 実施の形態１について、マルチキャスト用ＢＡＰアドレスの割当ての他の例を示す図である。 実施の形態１について、マルチキャスト用ＢＡＰアドレスの割当ての他の例を示す図である。 実施の形態１について、マルチキャスト用ＢＡＰアドレスの割当ての他の例を示す図である。 実施の形態２について、ＢＡＰレイヤにおける複製の動作の一例を示した図である。 実施の形態２について、ＢＡＰレイヤにおける複製の動作の他の例を示した図である。 実施の形態２について、ＢＡＰレイヤにおける複製の動作の他の例を示した図である。 実施の形態２について、ＢＡＰレイヤにおける複製の動作の他の例を示した図である。 実施の形態２について、末端ＩＡＢノードにおける複製の動作の例を、ＩＡＢドナーＣＵからＵＥまでのプロトコルスタック上で示した図である。 実施の形態３について、データの複数の経路が途中で合流する例を示した図である。 実施の形態４について、リレーＵＥを介したリモートＵＥとＮＷ間の通信において、リレーＵＥが２つのｇＮＢと接続する場合の概念図である。 実施の形態４について、リレーＵＥを介したリモートＵＥとＮＷ間の通信において、リレーＵＥが２つのｇＮＢと接続する場合のプロトコルスタックを示す図である。 実施の形態４について、リレーＵＥを介したリモートＵＥとＮＷ間の通信において、リレーＵＥが２つのｇＮＢと接続する場合のプロトコルスタックの他の構成方法を示す図である。 実施の形態４について、リレーＵＥを介したリモートＵＥとＮＷ間の通信において、リレーＵＥが２つのｇＮＢと接続する場合のプロトコルスタックの他の構成方法を示す図である。 実施の形態４について、リレーＵＥが２つのｇＮＢと接続するＤＣの設定方法例を示すシーケンス図である。 実施の形態４について、リレーＵＥが２つのｇＮＢと接続するＤＣの設定方法の他の例を示すシーケンス図である。 実施の形態５について、リレーＵＥを介したリモートＵＥとＮＷ間の通信において、リモートＵＥが２つのｇＮＢと接続する場合の一例を示す概念図である。 実施の形態５について、リレーＵＥを介したリモートＵＥとＮＷ間の通信において、リモートＵＥが２つのｇＮＢと接続する場合の他の例を示す概念図である。 実施の形態５について、リレーＵＥを介したリモートＵＥとＮＷ間の通信において、リモートＵＥが２つのｇＮＢと接続する場合の他の例を示す概念図である。 実施の形態５について、リレーＵＥを介したリモートＵＥとＮＷ間の通信において、リモートＵＥが２つのｇＮＢと接続する場合のプロトコルスタックを示す図である。 実施の形態５について、リモートＵＥが２つのｇＮＢと接続するＤＣの設定方法例を示すシーケンス図である。 実施の形態５について、リレーＵＥを介したリモートＵＥとＮＷ間の通信において、リモートＵＥが２つのｇＮＢと接続する場合のプロトコルスタックの他の構成方法を示す図である。 実施の形態５について、リモートＵＥが２つのｇＮＢと接続するＤＣの設定方法例を示すシーケンス図である。 実施の形態５について、リレーＵＥを介したリモートＵＥとＮＷ間の通信において、リモートＵＥが２つのｇＮＢと接続する場合のプロトコルスタックの他の構成方法を示す図である。 実施の形態５について、リモートＵＥが２つのｇＮＢと接続するＤＣの設定方法例を示すシーケンス図である。 実施の形態６について、リレーＵＥを介したリモートＵＥとＮＷ間の通信において、リモートＵＥが１つのｇＮＢと２つのパスで接続する場合の１例を示す概念図である。 実施の形態６について、リレーＵＥを介したリモートＵＥとＮＷ間の通信において、リモートＵＥが１つのｇＮＢと２つのパスで接続する場合の他の例を示す概念図である。 実施の形態６について、リモートＵＥとＮＷ間の通信において、リモートＵＥが、ＭＮと、ＳＮの代替とするリレーＵＥ＃Ｓとを用いてＤＣが設定される場合のプロトコルスタックを示す図である。 実施の形態６について、ＭＮとリレーＵＥ＃Ｓ間のプロトコルスタックを示す図である。 実施の形態６について、リモートＵＥが１つのｇＮＢと２つのパスで接続するＤＣの設定方法例を示すシーケンス図である。 実施の形態６について、リモートＵＥとＮＷ間の通信において、リモートＵＥが、ＭＮと、ＳＮの代替とするリレーＵＥ＃Ｓとを用いてＤＣが設定される場合のプロトコルスタックの他の構成方法を示す図である。 実施の形態６について、リモートＵＥが１つのｇＮＢと２つのパスで接続するＤＣの設定方法例を示すシーケンス図である。
　以下に、本開示の実施の形態にかかる通信システムおよび基地局を図面に基づいて詳細に説明する。
実施の形態１．
　図２は、３ＧＰＰにおいて議論されているＬＴＥ方式の通信システム２００の全体的な構成を示すブロック図である。図２について説明する。無線アクセスネットワークは、Ｅ－ＵＴＲＡＮ（Evolved　Universal　Terrestrial　Radio　Access　Network）２０１と称される。通信端末装置である移動端末装置（以下「移動端末（User　Equipment：ＵＥ）」という）２０２は、基地局装置（以下「基地局（E-UTRAN　NodeB：ｅＮＢ）」という）２０３と無線通信可能であり、無線通信で信号の送受信を行う。
　ここで、「通信端末装置」とは、移動可能な携帯電話端末装置などの移動端末装置だけでなく、センサなどの移動しないデバイスも含んでいる。以下の説明では、「通信端末装置」を、単に「通信端末」という場合がある。
　移動端末２０２に対する制御プロトコル、例えばＲＲＣ（Radio　Resource　Control）と、ユーザプレイン（以下、Ｕ－Ｐｌａｎｅと称する場合もある）、例えばＰＤＣＰ（Packet　Data　Convergence　Protocol）、ＲＬＣ（Radio　Link　Control）、ＭＡＣ（Medium　Access　Control）、ＰＨＹ（Physical　layer）とが基地局２０３で終端するならば、Ｅ－ＵＴＲＡＮは１つあるいは複数の基地局２０３によって構成される。
　移動端末２０２と基地局２０３との間の制御プロトコルＲＲＣ（Radio　Resource　Control）は、報知（Broadcast）、ページング（paging）、ＲＲＣ接続マネージメント（RRC　connection　management）などを行う。ＲＲＣにおける基地局２０３と移動端末２０２との状態として、ＲＲＣ＿ＩＤＬＥと、ＲＲＣ＿ＣＯＮＮＥＣＴＥＤとがある。
　ＲＲＣ＿ＩＤＬＥでは、ＰＬＭＮ（Public　Land　Mobile　Network）選択、システム情報（System　Information：ＳＩ）の報知、ページング（paging）、セル再選択（cell　re-selection）、モビリティなどが行われる。ＲＲＣ＿ＣＯＮＮＥＣＴＥＤでは、移動端末はＲＲＣ接続（connection）を有し、ネットワークとのデータの送受信を行うことができる。またＲＲＣ＿ＣＯＮＮＥＣＴＥＤでは、ハンドオーバ（Handover：ＨＯ）、隣接セル（Neighbor　cell）の測定（メジャメント（measurement））などが行われる。
　基地局２０３は、１つあるいは複数のｅＮＢ２０７により構成される。またコアネットワークであるＥＰＣ（Evolved　Packet　Core）と、無線アクセスネットワークであるＥ－ＵＴＲＡＮ２０１とで構成されるシステムは、ＥＰＳ（Evolved　Packet　System）と称される。コアネットワークであるＥＰＣと、無線アクセスネットワークであるＥ－ＵＴＲＡＮ２０１とを合わせて、「ネットワーク」という場合がある。
　ｅＮＢ２０７は、移動管理エンティティ（Mobility　Management　Entity：ＭＭＥ）、あるいはＳ－ＧＷ（Serving　Gateway）、あるいはＭＭＥおよびＳ－ＧＷを含むＭＭＥ／Ｓ－ＧＷ部（以下「ＭＭＥ部」という場合がある）２０４とＳ１インタフェースにより接続され、ｅＮＢ２０７とＭＭＥ部２０４との間で制御情報が通信される。１つのｅＮＢ２０７に対して、複数のＭＭＥ部２０４が接続されてもよい。ｅＮＢ２０７間は、Ｘ２インタフェースにより接続され、ｅＮＢ２０７間で制御情報が通信される。
　ＭＭＥ部２０４は、上位装置、具体的には上位ノードであり、基地局であるｅＮＢ２０７と、移動端末（ＵＥ）２０２との接続を制御する。ＭＭＥ部２０４は、コアネットワークであるＥＰＣを構成する。基地局２０３は、Ｅ－ＵＴＲＡＮ２０１を構成する。
　基地局２０３は、１つのセルを構成してもよいし、複数のセルを構成してもよい。各セルは、移動端末２０２と通信可能な範囲であるカバレッジとして予め定める範囲を有し、カバレッジ内で移動端末２０２と無線通信を行う。１つの基地局２０３が複数のセルを構成する場合、１つ１つのセルが、移動端末２０２と通信可能に構成される。
　図３は、３ＧＰＰにおいて議論されている５Ｇ方式の通信システム２１０の全体的な構成を示すブロック図である。図３について説明する。無線アクセスネットワークは、ＮＧ－ＲＡＮ（Next　Generation　Radio　Access　Network）２１１と称される。ＵＥ２０２は、ＮＲ基地局装置（以下「ＮＲ基地局（NG-RAN　NodeB：ｇＮＢ）」という）２１３と無線通信可能であり、無線通信で信号の送受信を行う。また、コアネットワークは、５Ｇコア（5G　Core：５ＧＣ）と称される。
　ＵＥ２０２に対する制御プロトコル、例えばＲＲＣ（Radio　Resource　Control）と、ユーザプレイン（以下、Ｕ－Ｐｌａｎｅと称する場合もある）、例えばＳＤＡＰ（Service　Data　Adaptation　Protocol）、ＰＤＣＰ（Packet　Data　Convergence　Protocol）、ＲＬＣ（Radio　Link　Control）、ＭＡＣ（Medium　Access　Control）、ＰＨＹ（Physical　layer）とがＮＲ基地局２１３で終端するならば、ＮＧ－ＲＡＮは１つあるいは複数のＮＲ基地局２１３によって構成される。
　ＵＥ２０２とＮＲ基地局２１３との間の制御プロトコルＲＲＣ（Radio　Resource　Control）の機能はＬＴＥと同様である。ＲＲＣにおけるＮＲ基地局２１３とＵＥ２０２との状態として、ＲＲＣ＿ＩＤＬＥと、ＲＲＣ＿ＣＯＮＮＥＣＴＥＤと、ＲＲＣ＿ＩＮＡＣＴＩＶＥとがある。
　ＲＲＣ＿ＩＤＬＥ、ＲＲＣ＿ＣＯＮＮＥＣＴＥＤは、ＬＴＥ方式と同様である。ＲＲＣ＿ＩＮＡＣＴＩＶＥは５ＧコアとＮＲ基地局２１３との間の接続が維持されつつ、システム情報（System　Information：ＳＩ）の報知、ページング（paging）、セル再選択（cell　re-selection）、モビリティなどが行われる。
　ｇＮＢ２１７は、アクセス・移動管理機能（Access　and　Mobility　Management　Function：ＡＭＦ）、セッション管理機能（Session　Management　Function：ＳＭＦ）、あるいはＵＰＦ（User　Plane　Function）、あるいはＡＭＦ、ＳＭＦおよびＵＰＦを含むＡＭＦ／ＳＭＦ／ＵＰＦ部（以下「５ＧＣ部」という場合がある）２１４とＮＧインタフェースにより接続される。ｇＮＢ２１７と５ＧＣ部２１４との間で制御情報および／あるいはユーザデータが通信される。ＮＧインタフェースは、ｇＮＢ２１７とＡＭＦとの間のＮ２インタフェース、ｇＮＢ２１７とＵＰＦとの間のＮ３インタフェース、ＡＭＦとＳＭＦとの間のＮ１１インタフェース、および、ＵＰＦとＳＭＦとの間のＮ４インタフェースの総称である。１つのｇＮＢ２１７に対して、複数の５ＧＣ部２１４が接続されてもよい。ｇＮＢ２１７間は、Ｘｎインタフェースにより接続され、ｇＮＢ２１７間で制御情報および／あるいはユーザデータが通信される。
　５ＧＣ部２１４は、上位装置、具体的には上位ノードであり、１つまたは複数の基地局２０３および／あるいは基地局２１３に対して、ページング信号の分配を行う。また、５ＧＣ部２１４は、待受け状態（Idle　State）のモビリティ制御（Mobility　Control）を行う。５ＧＣ部２１４は、移動端末２０２が待ち受け状態のとき、インアクティブ状態（Inactive　State）および、アクティブ状態（Active　State）のときに、トラッキングエリア（Tracking　Area）リストの管理を行う。５ＧＣ部２１４は、移動端末２０２が登録されている（registered）追跡領域（トラッキングエリア：Tracking　Area）に属するセルへ、ページングメッセージを送信することで、ページングプロトコルに着手する。
　ＮＲ基地局２１３も、基地局２０３同様、１つあるいは複数のセルを構成してもよい。１つのＮＲ基地局２１３が複数のセルを構成する場合、１つ１つのセルが、ＵＥ２０２と通信可能に構成される。
　ｇＮＢ２１７は、中央ユニット（Central　Unit：以下、ＣＵと称する場合がある）２１８と分散ユニット（Distributed　Unit：以下、ＤＵと称する場合がある）２１９に分割されていてもよい。ＣＵ２１８は、ｇＮＢ２１７の中に１つ構成される。ＤＵ２１９は、ｇＮＢ２１７の中に１つあるいは複数構成される。ＣＵ２１８は、ＤＵ２１９とＦ１インタフェースにより接続され、ＣＵ２１８とＤＵ２１９との間で制御情報および／あるいはユーザデータが通信される。
　５Ｇ方式の通信システムにおいて、非特許文献２１（３ＧＰＰ　ＴＳ２３．５０１）に記載の統合データ管理（Unified　Data　Management：ＵＤＭ）機能、ポリシー制御機能（Policy　Control　Function：ＰＣＦ）が含まれてもよい。ＵＤＭおよび／あるいはＰＣＦは、図３における５ＧＣ部２１４に含まれるとしてもよい。
　５Ｇ方式の通信システムにおいて、非特許文献２４（３ＧＰＰ　ＴＳ３８．３０５）に記載の位置管理機能（Location　Management　Function：ＬＭＦ）が設けられてもよい。ＬＭＦは、非特許文献２５（３ＧＰＰ　ＴＳ２３．２７３）に開示されているように、ＡＭＦを経由して基地局に接続されていてもよい。
　５Ｇ方式の通信システムにおいて、非特許文献２１（３ＧＰＰ　ＴＳ２３．５０１）に記載の非３ＧＰＰ相互動作機能（Non-3GPP　Interworking　Function：Ｎ３ＩＷＦ）が含まれてもよい。Ｎ３ＩＷＦは、ＵＥとの間における非３ＧＰＰアクセスにおいて、アクセスネットワーク（Access　Network：ＡＮ）をＵＥとの間で終端してもよい。
　図４は、ＥＰＣに接続するｅＮＢおよびｇＮＢによるＤＣの構成を示した図である。図４において、実線はＵ－Ｐｌａｎｅの接続を示し、破線はＣ－Ｐｌａｎｅの接続を示す。図４において、ｅＮＢ２２３－１がマスタ基地局となり、ｇＮＢ２２４－２がセカンダリ基地局となる（このＤＣ構成を、ＥＮ－ＤＣと称する場合がある）。図４において、ＭＭＥ部２０４とｇＮＢ２２４－２との間のＵ－Ｐｌａｎｅ接続がｅＮＢ２２３－１経由で行われる例について示しているが、ＭＭＥ部２０４とｇＮＢ２２４－２との間で直接行われてもよい。
　図５は、ＮＧコアに接続するｇＮＢによるＤＣの構成を示した図である。図５において、実線はＵ－Ｐｌａｎｅの接続を示し、破線はＣ－Ｐｌａｎｅの接続を示す。図５において、ｇＮＢ２２４－１がマスタ基地局となり、ｇＮＢ２２４－２がセカンダリ基地局となる（このＤＣ構成を、ＮＲ－ＤＣと称する場合がある）。図５において、５ＧＣ部２１４とｇＮＢ２２４－２との間のＵ－Ｐｌａｎｅ接続がｇＮＢ２２４－１経由で行われる例について示しているが、５ＧＣ部２１４とｇＮＢ２２４－２との間で直接行われてもよい。
　図６は、ＮＧコアに接続するｅＮＢおよびｇＮＢによるＤＣの構成を示した図である。図６において、実線はＵ－Ｐｌａｎｅの接続を示し、破線はＣ－Ｐｌａｎｅの接続を示す。図６において、ｅＮＢ２２６－１がマスタ基地局となり、ｇＮＢ２２４－２がセカンダリ基地局となる（このＤＣ構成を、ＮＧ－ＥＮ－ＤＣと称する場合がある）。図６において、５ＧＣ部２１４とｇＮＢ２２４－２との間のＵ－Ｐｌａｎｅ接続がｅＮＢ２２６－１経由で行われる例について示しているが、５ＧＣ部２１４とｇＮＢ２２４－２との間で直接行われてもよい。
　図７は、ＮＧコアに接続するｅＮＢおよびｇＮＢによるＤＣの、他の構成を示した図である。図７において、実線はＵ－Ｐｌａｎｅの接続を示し、破線はＣ－Ｐｌａｎｅの接続を示す。図７において、ｇＮＢ２２４－１がマスタ基地局となり、ｅＮＢ２２６－２がセカンダリ基地局となる（このＤＣ構成を、ＮＥ－ＤＣと称する場合がある）。図７において、５ＧＣ部２１４とｅＮＢ２２６－２との間のＵ－Ｐｌａｎｅ接続がｇＮＢ２２４－１経由で行われる例について示しているが、５ＧＣ部２１４とｅＮＢ２２６－２との間で直接行われてもよい。
　図８は、図２に示す移動端末２０２の構成を示すブロック図である。図８に示す移動端末２０２の送信処理を説明する。まず、プロトコル処理部３０１からの制御データ、およびアプリケーション部３０２からのユーザデータが、送信データバッファ部３０３へ保存される。送信データバッファ部３０３に保存されたデータは、エンコーダー部３０４へ渡され、誤り訂正などのエンコード処理が施される。エンコード処理を施さずに、送信データバッファ部３０３から変調部３０５へ直接出力されるデータが存在してもよい。エンコーダー部３０４でエンコード処理されたデータは、変調部３０５にて変調処理が行われる。変調部３０５にて、ＭＩＭＯにおけるプリコーディングが行われてもよい。変調されたデータは、ベースバンド信号に変換された後、周波数変換部３０６へ出力され、無線送信周波数に変換される。その後、アンテナ３０７－１～３０７－４から基地局２０３に送信信号が送信される。図８において、アンテナの数が４つである場合について例示したが、アンテナ数は４つに限定されない。
　また、移動端末２０２の受信処理は、以下のように実行される。基地局２０３からの無線信号がアンテナ３０７－１～３０７－４により受信される。受信信号は、周波数変換部３０６にて無線受信周波数からベースバンド信号に変換され、復調部３０８において復調処理が行われる。復調部３０８にて、ウェイト計算および乗算処理が行われてもよい。復調後のデータは、デコーダー部３０９へ渡され、誤り訂正などのデコード処理が行われる。デコードされたデータのうち、制御データはプロトコル処理部３０１へ渡され、ユーザデータはアプリケーション部３０２へ渡される。移動端末２０２の一連の処理は、制御部３１０によって制御される。よって制御部３１０は、図８では省略しているが、各部３０１～３０９と接続している。制御部３１０は、例えば、プロセッサおよびメモリを含んで構成される処理回路で実現される。すなわち、移動端末２０２の一連の処理が記述されたプログラムをプロセッサが実行することにより制御部３１０が実現される。移動端末２０２の一連の処理が記述されたプログラムはメモリに格納されている。メモリの例は、ＲＡＭ（Random　Access　Memory）、ＲＯＭ（Read　Only　Memory）、フラッシュメモリー、等の、不揮発性または揮発性の半導体メモリである。制御部３１０は、ＦＰＧＡ（Field　Programmable　Gate　Array）、ＡＳＩＣ（Application　Specific　Integrated　Circuit）、ＤＳＰ（Digital　Signal　Processor）などの専用の処理回路で実現されてもよい。図８において、移動端末２０２が送信に用いるアンテナ数と受信に用いるアンテナ数は、同じであってもよいし、異なっていてもよい。
　図９は、図２に示す基地局２０３の構成を示すブロック図である。図９に示す基地局２０３の送信処理を説明する。ＥＰＣ通信部４０１は、基地局２０３とＥＰＣ（ＭＭＥ部２０４など）との間のデータの送受信を行う。５ＧＣ通信部４１２は、基地局２０３と５ＧＣ（５ＧＣ部２１４など）との間のデータの送受信を行う。他基地局通信部４０２は、他の基地局との間のデータの送受信を行う。ＥＰＣ通信部４０１、５ＧＣ通信部４１２、および他基地局通信部４０２は、それぞれプロトコル処理部４０３と情報の受け渡しを行う。プロトコル処理部４０３からの制御データ、ならびにＥＰＣ通信部４０１、５ＧＣ通信部４１２、および他基地局通信部４０２からのユーザデータおよび制御データは、送信データバッファ部４０４へ保存される。
　送信データバッファ部４０４に保存されたデータは、エンコーダー部４０５へ渡され、誤り訂正などのエンコード処理が施される。エンコード処理を施さずに、送信データバッファ部４０４から変調部４０６へ直接出力されるデータが存在してもよい。エンコードされたデータは、変調部４０６にて変調処理が行われる。変調部４０６にて、ＭＩＭＯにおけるプリコーディングが行われてもよい。変調されたデータは、ベースバンド信号に変換された後、周波数変換部４０７へ出力され、無線送信周波数に変換される。その後、アンテナ４０８－１～４０８－４より１つもしくは複数の移動端末２０２に対して送信信号が送信される。図９において、アンテナの数が４つである場合について例示したが、アンテナ数は４つに限定されない。
　また、基地局２０３の受信処理は以下のように実行される。１つもしくは複数の移動端末２０２からの無線信号が、アンテナ４０８により受信される。受信信号は、周波数変換部４０７にて無線受信周波数からベースバンド信号に変換され、復調部４０９で復調処理が行われる。復調されたデータは、デコーダー部４１０へ渡され、誤り訂正などのデコード処理が行われる。デコードされたデータのうち、制御データはプロトコル処理部４０３あるいは５ＧＣ通信部４１２あるいはＥＰＣ通信部４０１あるいは他基地局通信部４０２へ渡され、ユーザデータは５ＧＣ通信部４１２あるいはＥＰＣ通信部４０１あるいは他基地局通信部４０２へ渡される。基地局２０３の一連の処理は、制御部４１１によって制御される。よって制御部４１１は、図９では省略しているが、各部４０１～４１０，４１２と接続している。制御部４１１は、上述した移動端末２０２の制御部３１０と同様に、プロセッサおよびメモリを含んで構成される処理回路、または、ＦＰＧＡ、ＡＳＩＣ、ＤＳＰなどの専用の処理回路で実現される。図９において、基地局２０３が送信に用いるアンテナ数と受信に用いるアンテナ数は、同じであってもよいし、異なっていてもよい。
　図９は、基地局２０３の構成について示したブロック図であるが、基地局２１３についても同様の構成としてもよい。また、図８および図９について、移動端末２０２のアンテナ数と、基地局２０３のアンテナ数は、同じであってもよいし、異なってもよい。
　図１０は、ＭＭＥの構成を示すブロック図である。図１０では、前述の図２に示すＭＭＥ部２０４に含まれるＭＭＥ２０４ａの構成を示す。ＰＤＮ　ＧＷ通信部５０１は、ＭＭＥ２０４ａとＰＤＮ　ＧＷ（Packet　Data　Network　Gate　Way）との間のデータの送受信を行う。基地局通信部５０２は、ＭＭＥ２０４ａと基地局２０３との間のＳ１インタフェースによるデータの送受信を行う。ＰＤＮ　ＧＷから受信したデータがユーザデータであった場合、ユーザデータは、ＰＤＮ　ＧＷ通信部５０１から、ユーザプレイン通信部５０３経由で基地局通信部５０２に渡され、１つあるいは複数の基地局２０３へ送信される。基地局２０３から受信したデータがユーザデータであった場合、ユーザデータは、基地局通信部５０２から、ユーザプレイン通信部５０３経由でＰＤＮ　ＧＷ通信部５０１に渡され、ＰＤＮ　ＧＷへ送信される。
　ＰＤＮ　ＧＷから受信したデータが制御データであった場合、制御データは、ＰＤＮ　ＧＷ通信部５０１から制御プレイン制御部５０５へ渡される。基地局２０３から受信したデータが制御データであった場合、制御データは、基地局通信部５０２から制御プレイン制御部５０５へ渡される。
　ＨｅＮＢＧＷ通信部５０４は、ＭＭＥ２０４ａとＨｅＮＢ　ＧＷ（Home-eNB　Gate　Way）との間のデータの送受信を行う。ＨｅＮＢＧＷ通信部５０４がＨｅＮＢ　ＧＷから受信した制御データは制御プレイン制御部５０５に渡される。ＨｅＮＢＧＷ通信部５０４は、制御プレイン制御部５０５から入力される制御データをＨｅＮＢ　ＧＷへ送信する。
　制御プレイン制御部５０５には、ＮＡＳセキュリティ部５０５－１、ＳＡＥベアラコントロール部５０５－２、アイドルステート（Idle　State）モビリティ管理部５０５－３などが含まれ、制御プレイン（以下、Ｃ－Ｐｌａｎｅと称する場合もある）に対する処理全般を行う。ＮＡＳセキュリティ部５０５－１は、ＮＡＳ（Non-Access　Stratum）メッセージのセキュリティなどを行う。ＳＡＥベアラコントロール部５０５－２は、ＳＡＥ（System　Architecture　Evolution）のベアラの管理などを行う。アイドルステートモビリティ管理部５０５－３は、待受け状態（アイドルステート（Idle　State）：ＬＴＥ－ＩＤＬＥ状態、または、単にアイドルとも称される）のモビリティ管理、待受け状態時のページング信号の生成および制御、傘下の１つあるいは複数の移動端末２０２のトラッキングエリアの追加、削除、更新、検索、トラッキングエリアリスト管理などを行う。
　ＭＭＥ２０４ａは、１つまたは複数の基地局２０３に対して、ページング信号の分配を行う。また、ＭＭＥ２０４ａは、待受け状態（Idle　State）のモビリティ制御（Mobility　control）を行う。ＭＭＥ２０４ａは、移動端末２０２が待受け状態のとき、および、アクティブ状態（Active　State）のときに、トラッキングエリア（Tracking　Area）リストの管理を行う。ＭＭＥ２０４ａは、移動端末２０２が登録されている（registered）追跡領域（トラッキングエリア：Tracking　Area）に属するセルへ、ページングメッセージを送信することで、ページングプロトコルに着手する。ＭＭＥ２０４ａに接続されるｅＮＢ２０７のＣＳＧの管理、ＣＳＧ　ＩＤの管理、およびホワイトリストの管理は、アイドルステートモビリティ管理部５０５－３で行われてもよい。
　ＭＭＥ２０４ａの一連の処理は、制御部５０６によって制御される。よって制御部５０６は、図１０では省略しているが、各部５０１～５０５と接続している。制御部５０６は、上述した移動端末２０２の制御部３１０と同様に、プロセッサおよびメモリを含んで構成される処理回路、または、ＦＰＧＡ、ＡＳＩＣ、ＤＳＰなどの専用の処理回路で実現される。
　図１１は、５ＧＣ部の構成を示すブロック図である。図１１では、前述の図３に示す５ＧＣ部２１４の構成を示す。図１１は、図５にて示す５ＧＣ部２１４に、ＡＭＦの構成、ＳＭＦの構成およびＵＰＦの構成が含まれた場合について示している。Ｄａｔａ　Ｎｅｔｗｏｒｋ通信部５２１は、５ＧＣ部２１４とＤａｔａ　Ｎｅｔｗｏｒｋとの間のデータの送受信を行う。基地局通信部５２２は、５ＧＣ部２１４と基地局２０３との間のＳ１インタフェース、および／あるいは、５ＧＣ部２１４と基地局２１３との間のＮＧインタフェースによるデータの送受信を行う。Ｄａｔａ　Ｎｅｔｗｏｒｋから受信したデータがユーザデータであった場合、ユーザデータは、Ｄａｔａ　Ｎｅｔｗｏｒｋ通信部５２１から、ユーザプレイン通信部５２３経由で基地局通信部５２２に渡され、１つあるいは複数の、基地局２０３および／あるいは基地局２１３へ送信される。基地局２０３および／あるいは基地局２１３から受信したデータがユーザデータであった場合、ユーザデータは、基地局通信部５２２から、ユーザプレイン通信部５２３経由でＤａｔａ　Ｎｅｔｗｏｒｋ通信部５２１に渡され、Ｄａｔａ　Ｎｅｔｗｏｒｋへ送信される。
　Ｄａｔａ　Ｎｅｔｗｏｒｋから受信したデータが制御データであった場合、制御データは、Ｄａｔａ　Ｎｅｔｗｏｒｋ通信部５２１からユーザプレイン通信部５２３経由でセッション管理部５２７へ渡される。セッション管理部５２７は、制御データを制御プレイン制御部５２５へ渡す。基地局２０３および／あるいは基地局２１３から受信したデータが制御データであった場合、制御データは、基地局通信部５２２から制御プレイン制御部５２５に渡される。制御プレイン制御部５２５は、制御データをセッション管理部５２７へ渡す。
　制御プレイン制御部５２５は、ＮＡＳセキュリティ部５２５－１、ＰＤＵセッションコントロール部５２５－２、アイドルステート（Idle　State）モビリティ管理部５２５－３などを含み、制御プレイン（以下、Ｃ－Ｐｌａｎｅと称する場合もある）に対する処理全般を行う。ＮＡＳセキュリティ部５２５－１は、ＮＡＳ（Non-Access　Stratum）メッセージのセキュリティなどを行う。ＰＤＵセッションコントロール部５２５－２は、移動端末２０２と５ＧＣ部２１４との間のＰＤＵセッションの管理などを行う。アイドルステートモビリティ管理部５２５－３は、待受け状態（アイドルステート（Idle　State）：ＲＲＣ＿ＩＤＬＥ状態、または、単にアイドルとも称される）のモビリティ管理、待受け状態時のページング信号の生成および制御、傘下の１つあるいは複数の移動端末２０２のトラッキングエリアの追加、削除、更新、検索、トラッキングエリアリスト管理などを行う。
　５ＧＣ部２１４の一連の処理は、制御部５２６によって制御される。よって制御部５２６は、図１１では省略しているが、各部５２１～５２３，５２５，５２７と接続している。制御部５２６は、上述した移動端末２０２の制御部３１０と同様に、プロセッサおよびメモリを含んで構成される処理回路、または、ＦＰＧＡ、ＡＳＩＣ、ＤＳＰなどの専用の処理回路で実現される。
　次に通信システムにおけるセルサーチ方法の一例を示す。図１２は、ＬＴＥ方式の通信システムにおいて通信端末（ＵＥ）が行うセルサーチから待ち受け動作までの概略を示すフローチャートである。通信端末は、セルサーチを開始すると、ステップＳＴ６０１で、周辺の基地局から送信される第一同期信号（Ｐ－ＳＳ）、および第二同期信号（Ｓ－ＳＳ）を用いて、スロットタイミング、フレームタイミングの同期をとる。
　Ｐ－ＳＳとＳ－ＳＳとを合わせて、同期信号（Synchronization　Signal：ＳＳ）という。同期信号（ＳＳ）には、セル毎に割り当てられたＰＣＩに１対１に対応するシンクロナイゼーションコードが割り当てられている。ＰＣＩの数は５０４通りが検討されている。通信端末は、この５０４通りのＰＣＩを用いて同期をとるとともに、同期がとれたセルのＰＣＩを検出（特定）する。
　通信端末は、次に同期がとれたセルに対して、ステップＳＴ６０２で、基地局からセル毎に送信される参照信号（リファレンスシグナル：ＲＳ）であるセル固有参照信号（Cell-specific　Reference　Signal：ＣＲＳ）を検出し、ＲＳの受信電力（Reference　Signal　Received　Power：ＲＳＲＰ）の測定を行う。参照信号（ＲＳ）には、ＰＣＩと１対１に対応したコードが用いられている。そのコードで相関をとることによって他セルと分離できる。ステップＳＴ６０１で特定したＰＣＩから、該セルのＲＳ用のコードを導出することによって、ＲＳを検出し、ＲＳの受信電力を測定することが可能となる。
　次にステップＳＴ６０３で、通信端末は、ステップＳＴ６０２までで検出された１つ以上のセルの中から、ＲＳの受信品質が最もよいセル、例えば、ＲＳの受信電力が最も高いセル、つまりベストセルを選択する。
　次にステップＳＴ６０４で、通信端末は、ベストセルのＰＢＣＨを受信して、報知情報であるＢＣＣＨを得る。ＰＢＣＨ上のＢＣＣＨには、セル構成情報が含まれるＭＩＢ（Master　Information　Block）がマッピングされる。したがって、ＰＢＣＨを受信してＢＣＣＨを得ることで、ＭＩＢが得られる。ＭＩＢの情報としては、例えば、ＤＬ（ダウンリンク）システム帯域幅（送信帯域幅設定（transmission　bandwidth　configuration：dl-bandwidth）とも呼ばれる）、送信アンテナ数、ＳＦＮ（System　Frame　Number）などがある。
　次にステップＳＴ６０５で、通信端末は、ＭＩＢのセル構成情報をもとに該セルのＤＬ－ＳＣＨを受信して、報知情報ＢＣＣＨの中のＳＩＢ（System　Information　Block）１を得る。ＳＩＢ１には、該セルへのアクセスに関する情報、セルセレクションに関する情報、他のＳＩＢ（ＳＩＢｋ；ｋ≧２の整数）のスケジューリング情報が含まれる。また、ＳＩＢ１には、トラッキングエリアコード（Tracking　Area　Code：ＴＡＣ）が含まれる。
　次にステップＳＴ６０６で、通信端末は、ステップＳＴ６０５で受信したＳＩＢ１のＴＡＣと、通信端末が既に保有しているトラッキングエリアリスト内のトラッキングエリア識別子（Tracking　Area　Identity：ＴＡＩ）のＴＡＣ部分とを比較する。トラッキングエリアリストは、ＴＡＩリスト（TAI　list）とも称される。ＴＡＩはトラッキングエリアを識別するための識別情報であり、ＭＣＣ（Mobile　Country　Code）と、ＭＮＣ（Mobile　Network　Code）と、ＴＡＣ（Tracking　Area　Code）とによって構成される。ＭＣＣは国コードである。ＭＮＣはネットワークコードである。ＴＡＣはトラッキングエリアのコード番号である。
　通信端末は、ステップＳＴ６０６で比較した結果、ステップＳＴ６０５で受信したＴＡＣがトラッキングエリアリスト内に含まれるＴＡＣと同じならば、該セルで待ち受け動作に入る。比較して、ステップＳＴ６０５で受信したＴＡＣがトラッキングエリアリスト内に含まれなければ、通信端末は、該セルを通して、ＭＭＥなどが含まれるコアネットワーク（Core　Network，ＥＰＣ）へ、ＴＡＵ（Tracking　Area　Update）を行うためにトラッキングエリアの変更を要求する。
　図１２に示す例においては、ＬＴＥ方式におけるセルサーチから待ち受けまでの動作の例について示したが、ＮＲ方式においては、ステップＳＴ６０３において、ベストセルに加えてベストビームを選択してもよい。また、ＮＲ方式においては、ステップＳＴ６０４において、ビームの情報、例えば、ビームの識別子を取得してもよい。また、ＮＲ方式においては、ステップＳＴ６０４において、リメイニングミニマムＳＩ（Remaining　Minimum　SI：ＲＭＳＩ）のスケジューリング情報を取得してもよい。ＮＲ方式においては、ステップＳＴ６０５において、ＲＭＳＩを受信するとしてもよい。
　コアネットワークを構成する装置（以下「コアネットワーク側装置」という場合がある）は、ＴＡＵ要求信号とともに通信端末から送られてくる該通信端末の識別番号（ＵＥ－ＩＤなど）をもとに、トラッキングエリアリストの更新を行う。コアネットワーク側装置は、通信端末に更新後のトラッキングエリアリストを送信する。通信端末は、受信したトラッキングエリアリストに基づいて、通信端末が保有するＴＡＣリストを書き換える（更新する）。その後、通信端末は、該セルで待ち受け動作に入る。
　スマートフォンおよびタブレット型端末装置の普及によって、セルラー系無線通信によるトラフィックが爆発的に増大しており、世界中で無線リソースの不足が懸念されている。これに対応して周波数利用効率を高めるために、小セル化し、空間分離を進めることが検討されている。
　従来のセルの構成では、ｅＮＢによって構成されるセルは、比較的広い範囲のカバレッジを有する。従来は、複数のｅＮＢによって構成される複数のセルの比較的広い範囲のカバレッジによって、あるエリアを覆うように、セルが構成されている。
　小セル化された場合、ｅＮＢによって構成されるセルは、従来のｅＮＢによって構成されるセルのカバレッジに比べて範囲が狭いカバレッジを有する。したがって、従来と同様に、あるエリアを覆うためには、従来のｅＮＢに比べて、多数の小セル化されたｅＮＢが必要となる。
　以下の説明では、従来のｅＮＢによって構成されるセルのように、カバレッジが比較的大きいセルを「マクロセル」といい、マクロセルを構成するｅＮＢを「マクロｅＮＢ」という。また、小セル化されたセルのように、カバレッジが比較的小さいセルを「スモールセル」といい、スモールセルを構成するｅＮＢを「スモールｅＮＢ」という。
　マクロｅＮＢは、例えば、非特許文献７に記載される「ワイドエリア基地局（Wide　Area　Base　Station）」であってもよい。
　スモールｅＮＢは、例えば、ローパワーノード、ローカルエリアノード、ホットスポットなどであってもよい。また、スモールｅＮＢは、ピコセルを構成するピコｅＮＢ、フェムトセルを構成するフェムトｅＮＢ、ＨｅＮＢ、ＲＲＨ（Remote　Radio　Head）、ＲＲＵ（Remote　Radio　Unit）、ＲＲＥ（Remote　Radio　Equipment）またはＲＮ（Relay　Node）であってもよい。また、スモールｅＮＢは、非特許文献７に記載される「ローカルエリア基地局（Local　Area　Base　Station）」または「ホーム基地局（Home　Base　Station）」であってもよい。
　図１３は、ＮＲにおけるセルの構成の一例を示す。ＮＲのセルでは、狭いビームを形成し、方向を変えて送信する。図１３に示す例において、基地局７５０は、ある時間において、ビーム７５１－１を用いて移動端末との送受信を行う。他の時間において、基地局７５０は、ビーム７５１－２を用いて移動端末との送受信を行う。以下同様にして、基地局７５０はビーム７５１－３～７５１－８のうち１つあるいは複数を用いて移動端末との送受信を行う。このようにすることで、基地局７５０は広範囲のセルを構成する。
　図１３において、基地局７５０が用いるビームの数を８とする例について示したが、ビームの数は８とは異なっていてもよい。また、図１３に示す例において、基地局７５０が同時に用いるビームの数を１つとしたが、複数であってもよい。
　３ＧＰＰにおいて、Ｄ２Ｄ（Device　to　Device）通信、Ｖ２Ｖ（Vehicle　to　Vehicle）通信のため、サイドリンク（ＳＬ：Side　Link）がサポートされている（非特許文献１、非特許文献１６参照）。ＳＬはＰＣ５インタフェースによって規定される。
　ＳＬに用いられる物理チャネル（非特許文献１参照）について説明する。物理サイドリンク報知チャネル（ＰＳＢＣＨ：Physical　sidelink　broadcast　channel）は、システムと同期に関連する情報を運び、ＵＥから送信される。
　物理サイドリンクディスカバリチャネル（ＰＳＤＣＨ：Physical　sidelink　discovery　channel）は、ＵＥからサイドリンクディスカバリメッセージを運ぶ。
　物理サイドリンク制御チャネル（ＰＳＣＣＨ：Physical　sidelink　control　channel）は、サイドリンク通信とＶ２Ｘサイドリンク通信のためのＵＥからの制御情報を運ぶ。
　物理サイドリンク共有チャネル（ＰＳＳＣＨ：Physical　sidelink　shared　channel）は、サイドリンク通信とＶ２Ｘサイドリンク通信のためのＵＥからのデータを運ぶ。
　物理サイドリンクフィードバックチャネル（ＰＳＦＣＨ：Physical　sidelink　feedback　channel）は、ＰＳＳＣＨ送信を受信したＵＥから、ＰＳＳＣＨを送信したＵＥに、サイドリンク上でのＨＡＲＱフィードバックを運ぶ。
　ＳＬに用いられるトランスポートチャネル（非特許文献１参照）について説明する。サイドリンク報知チャネル（ＳＬ－ＢＣＨ：Sidelink　broadcast　channel）は、予め決められたトランスポートフォーマットを有し、物理チャネルであるＰＳＢＣＨにマッピングされる。
　サイドリンクディスカバリチャネル（ＳＬ－ＤＣＨ：Sidelink　discovery　channel）は、固定サイズの予め決められたフォーマットの周期的報知送信を有する。また、ＳＬ－ＤＣＨは、ＵＥ自動リソース選択（UE　autonomous　resource　selection）と、ｅＮＢによってスケジュールされたリソースアロケーションの両方をサポートする。ＵＥ自動リソース選択では衝突リスクが有り、ＵＥがｅＮＢによって個別リソースをアロケーションされた時は、衝突は無い。また、ＳＬ－ＤＣＨは、ＨＡＲＱコンバイニングをサポートするが、ＨＡＲＱフィードバックはサポートしない。ＳＬ－ＤＣＨは物理チャネルであるＰＳＤＣＨにマッピングされる。
　サイドリンク共有チャネル（ＳＬ－ＳＣＨ：Sidelink　shared　channel）は、報知送信をサポートする。ＳＬ－ＳＣＨは、ＵＥ自動リソース選択（UE　autonomous　resource　selection）と、ｅＮＢによってスケジュールされたリソースアロケーションの両方をサポートする。ＵＥ自動リソース選択では衝突リスクが有り、ＵＥがｅＮＢによって個別リソースをアロケーションされた時は、衝突は無い。また、ＳＬ－ＳＣＨは、ＨＡＲＱコンバイニングをサポートするが、ＨＡＲＱフィードバックはサポートしない。また、ＳＬ－ＳＣＨは、送信電力、変調、コーディングを変えることによって、動的リンクアダプテーションをサポートする。ＳＬ－ＳＣＨは物理チャネルであるＰＳＳＣＨにマッピングされる。
　ＳＬに用いられる論理チャネル（非特許文献１参照）について説明する。サイドリンク報知制御チャネル（ＳＢＣＣＨ：Sidelink　Broadcast　Control　Channel）は、１つのＵＥから他のＵＥにサイドリンクシステム情報を報知するためのサイドリンク用チャネルである。ＳＢＣＣＨはトランスポートチャネルであるＳＬ－ＢＣＨにマッピングされる。
　サイドリンクトラフィックチャネル（ＳＴＣＨ：Sidelink　Traffic　Channel）は、１つのＵＥから他のＵＥにユーザ情報を送信するための１対多のサイドリンク用トラフィックチャネルである。ＳＴＣＨは、サイドリンク通信能力を有するＵＥと、Ｖ２Ｘサイドリンク通信能力を有するＵＥによってのみ用いられる。２つのサイドリンク通信能力を有するＵＥ間の１対１通信もまたＳＴＣＨで実現される。ＳＴＣＨはトランスポートチャネルであるＳＬ－ＳＣＨにマッピングされる。
　サイドリンク制御チャネル（ＳＣＣＨ：Sidelink　Control　Channel）は、１つのＵＥから他のＵＥに制御情報を送信するためのサイドリンク用制御チャネルである。ＳＣＣＨはトランスポートチャネルであるＳＬ－ＳＣＨにマッピングされる。
　３ＧＰＰでは、ＮＲにおいてもＶ２Ｘ通信をサポートすることが検討されている。ＮＲにおけるＶ２Ｘ通信の検討が、ＬＴＥシステム、ＬＴＥ－Ａシステムを基にして進められているが、以下の点でＬＴＥシステム、ＬＴＥ－Ａシステムからの変更および追加が行われている。
　ＬＴＥではＳＬ通信はブロードキャスト（broadcast）のみであった。ＮＲでは、ＳＬ通信として、ブロードキャストに加え、ユニキャスト（unicast）とグループキャスト（groupcast）のサポートが検討されている（非特許文献２２（３ＧＰＰ　ＴＳ２３．２８７）参照）。
　ユニキャスト通信やグループキャスト通信では、ＨＡＲＱのフィードバック（Ａｃｋ／Ｎａｃｋ）、ＣＳＩ報告等のサポートが検討されている。
　ＳＬ通信で、ブロードキャストに加え、ユニキャストとグループキャストをサポートするため、ＰＣ５－Ｓシグナリングのサポートが検討されている（非特許文献２２（３ＧＰＰ　ＴＳ２３．２８７）参照）。たとえば、ＳＬ、すなわちＰＣ５通信を実施するためのリンクを確立するため、ＰＣ５－Ｓシグナリングが実施される。該リンクはＶ２Ｘレイヤで実施され、レイヤ２リンクとも称される。
　また、ＳＬ通信において、ＲＲＣシグナリングのサポートが検討されている（非特許文献２２（３ＧＰＰ　ＴＳ２３．２８７）参照）。ＳＬ通信におけるＲＲＣシグナリングを、ＰＣ５　ＲＲＣシグナリングとも称する。たとえば、ＰＣ５通信を行うＵＥ間で、ＵＥのケーパビリティを通知することや、ＰＣ５通信を用いてＶ２Ｘ通信を行うためのＡＳレイヤの設定などを通知することが提案されている。
　ＮＲを用いたマルチキャスト通信において、ＰＴＭ（Point　to　Multipoint）とＰＴＰ（Point　to　Point）がともに用いられてもよい。ＰＴＭとＰＴＰにおいて、共通のＰＤＣＰエンティティが用いられてもよい。ＰＴＭとＰＴＰが、互いに異なるレッグ（ＲＬＣ、論理チャネルの組合せ）を有してもよい。マルチキャスト通信において、ＰＴＭレッグとＰＴＰレッグとが動的に切り替えられつつ用いられてもよい。動的な切替えには、例えば、ＭＡＣシグナリングが用いられてもよい。
　５Ｇ方式の基地局は、アクセス・バックホール統合（Integrated　Access　and　Backhaul：ＩＡＢ）（非特許文献１６（ＴＳ３８．３００）参照）をサポート可能である。ＩＡＢ基地局は、ＩＡＢ機能を提供するＩＡＢドナーとして動作する基地局のＣＵであるＩＡＢドナーＣＵ、ＩＡＢドナーとして動作する基地局のＤＵであるＩＡＢドナーＤＵ、および、ＩＡＢドナーＤＵとの間、ＵＥとの間で無線インタフェースを用いて接続されるＩＡＢノードにより成り立っていてもよい。ＩＡＢノードは、ＩＡＢドナーＣＵの配下に複数存在してもよい。ＩＡＢノードとＩＡＢノードとの間が無線インタフェースを用いて接続されてもよい。すなわち、ＩＡＢノードの多段接続が行われてもよい。ＩＡＢノードとＩＡＢドナーＣＵとの間の接続は、Ｆ１インタフェースを用いて行われる（非特許文献１６（ＴＳ３８．３００）参照）。
　ＩＡＢドナーＤＵとＩＡＢノードとの間の接続およびＩＡＢノード間の接続において、ＢＡＰ（Backhaul　Adaptation　Protocol）レイヤが設けられる。ＢＡＰレイヤは、受信したデータの、ＩＡＢドナーＤＵおよび／あるいはＩＡＢノードへのルーティング、ＲＬＣチャネルへのマッピング等の動作を行う（非特許文献３６（ＴＳ３８．３４０）参照）。該ルーティングにおいて、ＢＡＰアドレスなるアドレスが用いられてもよい。ＢＡＰアドレスは、ＩＡＢドナーＤＵおよび／あるいはＩＡＢノード毎に割り当てられてもよい。ＢＡＰアドレスの割り当てを、ＩＡＢドナーＣＵが行ってもよい。ＩＡＢを用いた通信において送受信されるデータに、送信先のＩＡＢノードに関する情報、例えば、ＢＡＰアドレスが含まれる。該データに、データの経路を識別する情報、例えば、パスＩＤが含まれる。前述の情報は、例えば、ＢＡＰヘッダとして含まれてもよい。ＩＡＢドナーＤＵおよび／あるいはＩＡＢノードは、該ＢＡＰアドレスおよび／あるいはパスＩＤを用いて、前述のルーティングを行ってもよい。
　ＮＲを用いたマルチキャスト通信において、ＩＡＢ基地局が用いられてもよい。ＩＡＢ基地局を用いたマルチキャストにおいて、ＩＡＢドナーＣＵからＵＥまでの経路の途中に存在するＩＡＢノードが、ＵＥとの通信において自ノードの下位の接続先となる他のＩＡＢノード（以下、子ＩＡＢノードと称する場合がある）に対してマルチキャスト送信を行ってもよいし、ＵＥに対してマルチキャスト送信を行ってもよい。
　マルチキャスト送信を行うＩＡＢドナーＤＵおよび／ＩＡＢノードに接続する１つまたは複数の子ＩＡＢノードの中に、マルチキャスト送信の対象となる子ＩＡＢノードと対象外となる子ＩＡＢノードが混在してもよい。
　ところが、ＩＡＢ基地局におけるマルチキャストにおいて、ＩＡＢノードへのマルチキャストに用いられるＢＡＰアドレスに関する設定方法が上述の各非特許文献等において開示されていない。従って、ＩＡＢ基地局を用いたマルチキャストが実現できない、という問題が生じる。
　本実施の形態１では、このような課題を解決する方法を開示する。
　前述の問題を解決するため、本実施の形態にかかる通信システムにおいては、１つのデータについて送信先ＢＡＰアドレスを複数設定可能とする。宛先（Destination）ＢＡＰアドレスが複数設定されてもよいし、次ホップ（Next-hop）ＢＡＰアドレス（非特許文献３５（ＴＳ３８．４７３）参照）が複数設定されてもよい。複数のＢＡＰアドレスは、異なるパスＩＤに対してそれぞれ異なるＢＡＰアドレスが設定されるものであってもよいし、同じパスＩＤに対して複数の異なるＢＡＰアドレスが設定されるものであってもよい。
　ＩＡＢドナーＣＵはＩＡＢドナーＤＵおよび／あるいはＩＡＢノードに対して、送信先ＢＡＰアドレスを複数設定してもよい。該設定には、Ｆ１シグナリング、例えば、非特許文献３５（ＴＳ３８．４７３）に開示されたＢＡＰ　ＭＡＰＰＩＮＧ　ＣＯＮＦＩＧＵＲＡＴＩＯＮが用いられてもよいし、他のシグナリングが用いられてもよい。複数の送信先ＢＡＰアドレスの設定は、リストとして含まれてもよい。例えば、Ｆ１シグナリングにおける情報要素の１つであるＢＡＰ　Ｒｏｕｔｉｎｇ　ＩＤ（非特許文献３５（ＴＳ３８．４７３）参照）において、１つまたは複数のＢＡＰアドレスが含まれるＢＡＰアドレスのリストが設けられてもよい。他の例として、Ｆ１シグナリングに含まれる次ホップＢＡＰアドレスが、１つまたは複数のＢＡＰアドレスを含むリストとして構成されてもよい。前述の両方のリストが設けられてもよい。
　ＢＡＰアドレスを表す識別子が設けられてもよい。例えば、ＩＡＢドナーＣＵから設定される送信先ＢＡＰアドレスおよび／あるいは次ホップＢＡＰアドレスのそれぞれに対応付けられる識別子が設けられてもよいし、複数の送信先ＢＡＰアドレスおよび／あるいは次ホップＢＡＰアドレスに対応する１つの識別子が設けられてもよい。同様に、１つおよび／あるいは複数のパスＩＤを表す識別子が設けられてもよい。
　該識別子を、ＩＡＢドナーＣＵがＩＡＢドナーＤＵおよび／あるいはＩＡＢノードに対して通知してもよい。該識別子の通知は、ＩＡＢドナーＣＵがＩＡＢドナーＤＵおよび／あるいはＩＡＢノードに対する送信先ＢＡＰアドレスおよび／あるいは次ホップＢＡＰアドレスの設定の通知、例えば、前述のＢＡＰ　ＭＡＰＰＩＮＧ　ＣＯＮＦＩＧＵＲＡＴＩＯＮに含まれてもよい。
　ＢＡＰヘッダに、前述の識別子が含まれてもよい。ＩＡＢノードは、該識別子を用いて、送信先ＢＡＰアドレスを導出してもよいし、パスＩＤを導出してもよい。このことにより、例えば、ＢＡＰヘッダのサイズを削減可能となり、その結果、通信システムの効率を向上可能となる。ＢＡＰヘッダに、複数の送信先ＢＡＰアドレスおよび／あるいは複数のパスＩＤに対応するそれぞれ１つの識別子が含まれることにより、例えば、ＢＡＰヘッダのサイズをさらに削減可能となり、その結果、通信システムの効率をさらに向上可能となる。
　前述の識別子が、ＩＡＢドナーＣＵの配下において一意に与えられてもよい。このことにより、例えば、通信システムにおける複雑性を回避可能となる。
　他の例として、前述の識別子が、ＩＡＢノードおよび／あるいはＩＡＢドナーＤＵと子ＩＡＢノードの間で一意に与えられるとしてもよい。ＩＡＢノードは、ＢＡＰヘッダに含まれる送信先ＢＡＰアドレスおよび／あるいはパスＩＤを示す識別子の値を変更してもよい。例えば、ＩＡＢノードは、受信したＢＡＰヘッダに含まれる該識別子を用いて、送信先ＢＡＰアドレスおよび／あるいはパスＩＤを導出してもよい。該ＩＡＢノードは、導出した送信先ＢＡＰアドレスおよび／あるいはパスＩＤに対応する、子ＩＡＢノードとの間の通信に用いる識別子を導出してもよい。該ＩＡＢノードは、受信したＢＡＰヘッダに含まれる識別子を、導出した識別子に置き換えてもよい。該ＩＡＢノードは、導出した識別子を含むＢＡＰヘッダを用いて子ＩＡＢノードへの送信を行ってもよい。このことにより、例えば、該識別子のビット幅を小さくでき、その結果、通信効率を向上可能となる。
　図１４は、ＢＡＰアドレスのリストの例を図示したものである。ＢＡＰ　Ｒｏｕｔｉｎｇ　ＩＤの情報要素（ＩＥ：Ｉｎｆｏｒｍａｔｉｏｎ　Ｅｌｅｍｅｎｔ）に、複数のＢＡＰアドレスおよび１つのパスＩＤが含まれる。複数のＢＡＰアドレスは、宛先（Ｄｅｓｔｉｎａｔｉｏｎ）ＢＡＰアドレスであってもよい。
　ＢＡＰアドレスのリストを有するＢＡＰ　Ｒｏｕｔｉｎｇ　ＩＤの情報要素は、例えば、バックホールルーティング情報追加一覧（ＢＨ　Ｒｏｕｔｉｎｇ　Ｉｎｆｏｒｍａｔｉｏｎ　Ａｄｄｅｄ　Ｌｉｓｔ）に含まれてもよいし、バックホールルーティング情報削除一覧（ＢＨ　Ｒｏｕｔｉｎｇ　Ｉｎｆｏｒｍａｔｉｏｎ　Ｒｅｍｏｖｅｄ　Ｌｉｓｔ）に含まれてもよいし、前述の両方に含まれてもよい。
　変更されたバックホールルーティング情報に関する情報が設けられてもよい。該情報は、例えば、前述のＢＡＰ　ＭＡＰＰＩＮＧ　ＣＯＮＦＩＧＵＲＡＴＩＯＮに含まれてもよい。該情報は１つ設けられてもよいし、複数設けられてもよい。該情報が、例えば、一覧、例えば、バックホールルーティング情報変更一覧（ＢＨ　Ｒｏｕｔｉｎｇ　Ｉｎｆｏｒｍａｔｉｏｎ　Ｍｏｄｉｆｉｅｄ　Ｌｉｓｔ）として設けられてもよい。該一覧には、例えば、ＢＡＰアドレス、パスＩＤ、次ホップＢＡＰアドレスが含まれてもよい。該一覧に含まれる該情報は、例えば、変更後の情報であってもよい。このことにより、例えば、ＩＡＢノードにおけるルーティング設定処理量を削減可能となる。変更後のＢＡＰアドレスは、１つまたは複数のＢＡＰアドレスからなるリストとして含まれてもよい。変更後の次ホップＢＡＰアドレスも同様に、リストとして含まれてもよい。
　他の例として、該一覧には、追加されるＢＡＰアドレスに関する情報が含まれてもよいし、追加される次ホップＢＡＰアドレスに関する情報が含まれてもよいし、削除されるＢＡＰアドレスに関する情報が含まれてもよいし、削除される次ホップＢＡＰアドレスに関する情報が含まれてもよいし、追加されるパスＩＤに関する情報が含まれてもよいし、削除されるパスＩＤに関する情報が含まれてもよいし、前述の複数が含まれてもよい。前述の各情報は、１つまたは複数の要素からなる一覧として含まれてもよい。このことにより、例えば、バックホールルーティング情報の変更に関する情報のサイズを削減可能となる。
　ＩＡＢドナーＣＵからＩＡＢドナーＤＵへの設定に、複数のＢＡＰアドレスが含まれてもよい。該設定に、複数のＴＮＬ（Ｔｒａｎｓｐｏｒｔ　Ｎｅｔｗｏｒｋ　Ｌａｙｅｒ）アドレス（非特許文献３５（ＴＳ３８．４７３）参照）が含まれてもよい。ＴＮＬアドレスは、例えば、ＩＰアドレスであってもよい。該ＩＰアドレスは、例えば、ＩＰｖ４アドレスであってもよいし、ＩＰｖ６であってもよいし、ＩＰｖ６プレフィックスであってもよい。ＴＮＬアドレスの中に、マルチキャストＩＰアドレスが含まれてもよい。複数のＴＮＬアドレスが含まれることにより、例えば、ＩＡＢドナーＣＵから、ＵＥと直接通信するＩＡＢノード（以下、末端ＩＡＢノードと称する場合がある）へのマルチキャストにおける複雑性を回避可能となる。なお、末端ＩＡＢノードとは、ＵＥが接続され、該ＵＥとの直接通信が可能な状態のＩＡＢノードをいう。末端ＩＡＢノードには、複数のＵＥが同時に接続されてもよい。また、末端ＩＡＢノードには、ＵＥに加えて、他のＩＡＢノード（該末端ＩＡＢノードの子ＩＡＢノードに相当）が接続されることもある。
　ＩＡＢドナーＣＵからＩＡＢドナーＤＵへの設定は、例えば、ＩＰからレイヤ２へのトラフィックマッピング情報（ＩＰ　ｔｏ　ｌａｙｅｒ２　Ｔｒａｆｆｉｃ　Ｍａｐｐｉｎｇ　Ｉｎｆｏ）（非特許文献３５（ＴＳ３８．４７３）参照）の情報要素を用いて行われてもよい。
　該設定に含まれる情報の例として、以下（１）～（５）を開示する。
　（１）単一のＩＰアドレス、複数のＢＡＰアドレス、複数の、次ホップＢＡＰアドレスとＲＬＣチャネル識別子との組合せ。
　（２）単一のＩＰアドレス、複数のＢＡＰアドレス、複数の次ホップＢＡＰアドレス、単一のＲＬＣチャネル識別子。
　（３）複数の、ＩＰアドレスとＢＡＰアドレスとの組合せ、複数の、次ホップＢＡＰアドレスとＲＬＣチャネル識別子との組合せ。
　（４）複数の、ＩＰアドレスとＢＡＰアドレスとの組合せ、複数の次ホップＢＡＰアドレス、単一のＲＬＣチャネル識別子。
　（５）前述の（１）～（４）の組合せ。
　前述の（１）に含まれるＩＰアドレスは、マルチキャストＩＰアドレスであってもよい。前述の（１）により、例えば、ＩＡＢノードに対してＰＴＰを用いたマルチキャストが可能となる。
　前述の（２）に含まれるＩＰアドレスは、マルチキャストＩＰアドレスであってもよい。前述の（２）により、例えば、ＩＡＢノードに対してＰＴＭを用いたマルチキャストが可能となる。
　前述の（３）に含まれるＩＰアドレスは、ユニキャストＩＰアドレスであってもよい。前述の（３）により、例えば、ＩＡＢノードに対してＰＴＰを用いたマルチキャストが可能となる。
　前述の（４）に含まれるＩＰアドレスは、ユニキャストＩＰアドレスであってもよい。前述の（４）により、例えば、ＩＡＢノードに対してＰＴＭを用いたマルチキャストが可能となる。
　ＩＡＢドナーＣＵからＩＡＢノードへの設定に、複数の次ホップＢＡＰアドレスが含まれてもよい。ＲＬＣチャネル識別子に関する情報が複数含まれてもよい。例えば、複数の、次ホップＢＡＰアドレスとＲＬＣチャネル識別子との組合せを用いることにより、ＩＡＢノードに対しＰＴＰを用いたマルチキャストが可能となる。他の例として、複数の次ホップＢＡＰアドレスと単一のＲＬＣチャネル識別子との組合せを用いることにより、ＩＡＢノードに対してＰＴＭを用いたマルチキャストが可能となる。
　複数のＢＡＰアドレスが、ＢＡＰヘッダに含まれてもよい。ＢＡＰヘッダに、複数のパスＩＤが含まれてもよい。ＢＡＰヘッダに、複数のＢＡＰアドレスと複数のパスＩＤの両方が含まれてもよい。このことにより、例えば、同じマルチキャストデータを、送信先のＩＡＢノードの個数分だけ送信することが不要となり、その結果、Ｕｕインタフェースの効率的な利用が可能となる。
　ＢＡＰヘッダが単一のヘッダにより構成されてもよいし、複数のヘッダにより構成されてもよい。複数のヘッダにより構成される例として、２つのヘッダからＢＡＰヘッダが構成されてもよい。２つの該ヘッダのうち、片方のヘッダ（以下、基本ヘッダと称する場合がある）は固定サイズであってもよい。他方のヘッダ（以下、拡張ヘッダと称する場合がある）は可変サイズであってもよい。ＩＡＢノードは、基本ヘッダを先に取得してもよい。このことにより、例えば、ＩＡＢノードはヘッダを迅速に取得可能となる。
　ＢＡＰヘッダが複数のヘッダにより構成される他の例として、複数の基本ヘッダにより構成されてもよい。ＩＡＢノードは、複数の基本ヘッダを取得してもよい。このことにより、例えば、ＢＡＰヘッダ取得処理における複雑性を回避可能となる。
　ＢＡＰヘッダに含まれる情報の例として、以下の（Ａ）～（Ｍ）を開示する。
　（Ａ）１つまたは複数のＢＡＰアドレス。
　（Ｂ）ＢＡＰアドレスの個数に関する情報。
　（Ｃ）ＢＡＰヘッダのサイズに関する情報。
　（Ｄ）１つまたは複数のパスＩＤ。
　（Ｅ）パスＩＤの個数に関する情報。
　（Ｆ）含まれるＢＡＰアドレスが複数か否かに関する情報。
　（Ｇ）含まれるパスＩＤが複数か否かに関する情報。
　（Ｈ）後続ヘッダの有無に関する情報。
　（Ｉ）後続ヘッダのサイズに関する情報。
　（Ｊ）ＢＡＰヘッダを構成するヘッダの個数に関する情報。
　（Ｋ）パディング。
　（Ｌ）ＢＡＰヘッダの種類に関する情報。
　（Ｍ）前述の（Ａ）～（Ｌ）の組合せ。
　前述の（Ａ）に含まれるＢＡＰアドレスは、例えば、宛先ＢＡＰアドレスであってもよい。ＩＡＢノードは、前述の（Ａ）の情報を用いて、１つまたは複数の子ＩＡＢノードへのルーティングを行ってもよい。ＢＡＰヘッダの中にＢＡＰアドレスが１つまたは複数設けられることにより、例えば、ＩＡＢノードは複数の子ＩＡＢノードへのルーティングを迅速に実行可能となる。
　前述（Ｂ）の個数に関する情報は、ＢＡＰヘッダに含まれるＢＡＰアドレスの個数であってもよいし、該個数から所定の値、例えば、１を減じた値であってもよい。ＩＡＢノードは、前述の（Ｂ）の値を用いて、送信先ＢＡＰアドレスに関する情報を取得してもよい。このことにより、例えば、ＩＡＢノードは、ＢＡＰヘッダに含まれるＢＡＰアドレスを迅速に取得可能となる。他の例として、ＢＡＰヘッダに基本ヘッダと拡張ヘッダを用いる場合において、前述の（Ｂ）としてＢＡＰヘッダに含まれるＢＡＰアドレスの個数から１を減じた値を用いることにより、前述と同様の効果が得られる。
　前述（Ｃ）のサイズに関する情報は、ビット単位で与えられてもよいし、オクテット単位で与えられてもよいし、複数オクテット（例えば、２オクテットでも３オクテット以上でもよい）の単位で与えられてもよい。ＩＡＢノードは、前述（Ｃ）の情報を用い、ＢＡＰヘッダを取得してもよい。このことにより、例えば、ＩＡＢノードによるＢＡＰヘッダの誤取得を防止可能となる。
　前述の（Ｄ）に含まれるパスＩＤは、例えば、ＩＡＢドナーＣＵからの送信に用いられるパスＩＤの全部あるいは一部であってもよい。ＩＡＢノードは、前述の（Ｄ）の情報を用いて、１つまたは複数の子ＩＡＢノードへのルーティングを行ってもよい。ＢＡＰヘッダの中にパスＩＤが複数設けられることにより、例えば、ＩＡＢノードは複数の子ＩＡＢノードへのルーティングを迅速に実行可能となる。また、ＩＡＢドナーＤＵおよび／あるいはＩＡＢノードから送信するＢＡＰ－ＰＤＵの数を削減可能とし、その結果、ＩＡＢドナーＤＵおよび／あるいはＩＡＢノードにおける処理量を削減可能となる。
　前述（Ｅ）は、例えば、ＢＡＰヘッダに含まれるパスＩＤの個数であってもよいし、該個数から所定の値、例えば、１を減じた値であってもよい。ＩＡＢノードは、前述の（Ｅ）の値を用いて、パスＩＤに関する情報を取得してもよい。このことにより、例えば、ＩＡＢノードは、ＢＡＰヘッダに含まれるパスＩＤを迅速に取得可能となる。他の例として、ＢＡＰヘッダに基本ヘッダと拡張ヘッダを用いる場合において、前述（Ｅ）としてＢＡＰヘッダに含まれるパスＩＤの個数から１を減じた値を用いることにより、前述と同様の効果が得られる。
　前述（Ｆ）は、例えば、ＢＡＰヘッダが複数のＢＡＰアドレスを有するかどうかについて、是あるいは非を含む情報としてあらわされてもよい。ＩＡＢノードは、該情報を用いて、ＢＡＰアドレス取得の継続有無を決定してもよい。このことにより、例えば、ＢＡＰアドレス取得処理における複雑性を回避可能となる。
　前述（Ｇ）は、例えば、ＢＡＰヘッダが複数のパスＩＤを有するかどうかについて、是あるいは非を含む情報としてあらわされてもよい。ＩＡＢノードは、該情報を用いて、パスＩＤ取得の継続有無を決定してもよい。このことにより、例えば、パスＩＤ取得処理における複雑性を回避可能となる。
　前述（Ｈ）は、例えば、ＢＡＰヘッダが後続ヘッダを有するかどうかを表す情報であってもよい。該情報は、例えば、是あるいは非を含む情報として表されてもよい。前述（Ｈ）の情報を含むＢＡＰヘッダは、例えば、基本ヘッダであってもよいし、拡張ヘッダであってもよい。基本ヘッダの後続ヘッダは、拡張ヘッダであってもよい。拡張ヘッダの後続ヘッダは、他の拡張ヘッダであってもよい。基本ヘッダの後に拡張ヘッダが続く場合において、基本ヘッダと拡張ヘッダのサイズは同じであってもよいし、互いに異なっていてもよい。基本ヘッダの後に拡張ヘッダ、さらに他の拡張ヘッダが続く場合において、各ヘッダのサイズは同じであってもよいし、互いに異なっていてもよい。ＩＡＢノードは、例えば、前述（Ｈ）の情報が是であることを用いて、ＢＡＰヘッダ取得処理を継続してもよいし、前述（Ｈ）の情報が非であることを用いて、ＢＡＰヘッダ取得処理を終了してもよい。このことにより、例えば、ＩＡＢノードにおけるＢＡＰヘッダ処理における複雑性を回避可能となる。
　前述（Ｉ）のサイズに関する情報は、ビット単位で与えられてもよいし、オクテット単位で与えられてもよいし、複数オクテット（例えば、２オクテットでも３オクテットでも４オクテットでもよい）の単位で与えられてもよい。ＩＡＢノードは、前述（Ｉ）の情報を用い、後続ヘッダを取得してもよい。このことにより、例えば、ＩＡＢノードによる後続ヘッダの誤取得を防止可能となる。
　前述（Ｊ）の個数に関する情報は、例えば、当該ヘッダを含む個数であってもよいし、当該ヘッダを除く後続ヘッダの個数であってもよい。ＩＡＢノードは、前述（Ｊ）の情報を用い、後続ヘッダを取得してもよい。このことにより、例えば、ＩＡＢノードによる後続ヘッダの誤取得を防止可能となる。
　前述（Ｋ）は、例えば、ＢＡＰヘッダに含まれる１つまたは複数のＢＡＰアドレスのそれぞれの後ろに設けられてもよいし、１つまたは複数のパスＩＤのそれぞれの後ろに設けられてもよいし、ヘッダの先頭および／あるいは末尾に設けられてもよい。前述（Ｋ）は、例えば、ＢＡＰヘッダのサイズが１オクテット単位になるように設けられてもよいし、２オクテットの単位になるように設けられてもよいし、３オクテット以上の単位となるように設けられてもよい。このことにより、例えば、ＢＡＰヘッダ取得における複雑性を回避可能となる。
　前述（Ｌ）は、例えば、１つのＢＡＰアドレスと１つのパスＩＤとが含まれるヘッダであることを示す情報であってもよいし、複数の、ＢＡＰアドレスとパスＩＤとの組合せが含まれるヘッダであることを示す情報であってもよいし、複数のＢＡＰアドレスと１つのパスＩＤとが含まれるヘッダであることを示す情報であってもよいし、１つのＢＡＰアドレスと複数のパスＩＤとが含まれることを示す情報であってもよいし、１つまたは複数のＢＡＰアドレスのみが含まれることを示す情報であってもよいし、１つまたは複数のパスＩＤのみが含まれることを示す情報であってもよい。ＩＡＢドナーＤＵは、複数の種類のＢＡＰヘッダを用いてもよい。ＩＡＢノードは、前述（Ｌ）の情報を用いて、ヘッダの種類を判断してもよい。このことにより、例えば、通信システムにおける柔軟性を向上可能となる。
　前述（Ｍ）の例として、複数の種類のヘッダの組合せが用いられてもよい。例えば、複数の、ＢＡＰアドレスとパスＩＤとの組合せが含まれるヘッダと、複数のＢＡＰアドレスと１つのパスＩＤとが含まれるヘッダとの組合せが用いられてもよい。このことにより、例えば、通信システムにおける柔軟性を向上可能となる。
　図１５は、ＢＡＰヘッダの一例を示した図である。図１５は、複数のＢＡＰアドレスとパスＩＤを含む、可変長ヘッダの例について示す。図１５において、ＢＡＰアドレスとパスＩＤの数（Ｎ）が含まれる。宛先（ＤＥＳＴＩＮＡＴＩＯＮ）ＢＡＰアドレスとパス（ＰＡＴＨ）ＩＤの組がＮ個分、ＢＡＰヘッダに含まれる。ＢＡＰヘッダの末尾において、ＢＡＰヘッダをオクテット単位とするためのパディング（Ｐａｄｄｉｎｇ）が含まれる。ＩＡＢノードは、ＢＡＰヘッダに含まれるＮの値を用いて、宛先ＢＡＰアドレスとパスＩＤとの組合せを取得する。
　図１５において、ＢＡＰヘッダにＢＡＰアドレスとパスＩＤの数とが含まれる例について示したが、ＢＡＰヘッダのサイズが含まれてもよい。このことにより、例えば、ＩＡＢノードはＢＡＰヘッダを迅速に取得可能となる。
　図１５において、ＢＡＰアドレスとパスＩＤとの組合せが順次含まれる例について示したが、全てのＢＡＰアドレスの後ろに全てのパスＩＤが含まれてもよい。このことにより、例えば、ＩＡＢノードはＢＡＰアドレスを迅速に取得可能となる。
　図１５における他の例として、全てのパスＩＤの後ろに全てのＢＡＰアドレスが含まれてもよい。このことにより、例えば、ＩＡＢノードはパスＩＤを迅速に取得可能となる。
　図１６は、ＢＡＰヘッダの他の例を示した図である。図１６は、複数のＢＡＰアドレスとパスＩＤを含む、固定長の基本ヘッダおよび可変長の拡張ヘッダの例について示す。図１６において、ＢＡＰヘッダのうち白色の領域は基本ヘッダ、灰色の領域は後続ヘッダである拡張ヘッダとなる。
　図１６に示す基本ヘッダにおいて、後続ヘッダの有無に関する情報、および１つ目の宛先ＢＡＰアドレスとパスＩＤとが含まれる。ＩＡＢノードは、基本ヘッダより、１つ目の宛先ＢＡＰアドレスおよびパスＩＤを取得するとともに、後続ヘッダの有無に関する情報（Ｅｘｔ．）を取得する。ＩＡＢノードは、該情報が是であることを用いて、後続ヘッダを取得する。
　図１６に示す後続ヘッダにおいて、宛先ＢＡＰアドレスとパスＩＤとの組合せの個数（Ｎ）、および、２個目以降の宛先ＢＡＰアドレスとパスＩＤとの組合せが含まれる。また、後続ヘッダの末尾において、後続ヘッダをオクテット単位とするためのパディングが含まれる。後続ヘッダに含まれるＮの値は、基本ＢＡＰヘッダに含まれる宛先ＢＡＰアドレスおよびパスＩＤを除外した数であってもよいし、含めた数であってもよい。ＩＡＢノードは、前述のＮの値を用いて、後続ヘッダに含まれる宛先ＢＡＰアドレスおよびパスＩＤの数を把握してもよいし、後続ヘッダのサイズを把握してもよい。後続ヘッダを設けることにより、例えば、基本ヘッダのサイズを固定長とできるため、基本ヘッダの取得が迅速に可能となる。
　図１６において、ＢＡＰヘッダにＢＡＰアドレスとパスＩＤの数が含まれる例について示したが、ＢＡＰヘッダのサイズが含まれてもよい。このことにより、例えば、ＩＡＢノードはＢＡＰヘッダを迅速に取得可能となる。
　図１６の拡張ヘッダにおいて、ＢＡＰアドレスとパスＩＤとの組合せが順次含まれる例について示したが、全てのＢＡＰアドレスの後ろに全てのパスＩＤが含まれてもよい。このことにより、例えば、ＩＡＢノードはＢＡＰアドレスを迅速に取得可能となる。
　図１６の拡張ヘッダにおける他の例として、全てのパスＩＤの後ろに全てのＢＡＰアドレスが含まれてもよい。このことにより、例えば、ＩＡＢノードはパスＩＤを迅速に取得可能となる。
　図１７は、ＢＡＰヘッダの他の例を示した図である。図１７は、固定長の基本ヘッダおよび１つまたは複数の固定長の拡張ヘッダの例について示す。図１７において、ＢＡＰヘッダのうち白色の領域は基本ヘッダ、灰色の領域は拡張ヘッダとなる。
　図１７に示す基本ヘッダは、図１６と同様であるため、説明を省略する。
　図１７に示す複数の拡張ヘッダのそれぞれに、後続ヘッダの有無に関する情報、および宛先ＢＡＰアドレスとパスＩＤとの組合せが含まれる。ＩＡＢノードは、拡張ヘッダより、宛先ＢＡＰアドレスおよびパスＩＤを取得するとともに、後続ヘッダの有無に関する情報を取得する。ＩＡＢノードは、該情報が是であることを用いて、後続ヘッダを取得する。図１７に示すように、拡張ヘッダの構成は、基本ヘッダと同じとしてもよい。このことにより、例えば、拡張ヘッダの取得および／あるいは処理に関する処理量を削減可能となる。
　図１７に示す最後の拡張ヘッダにおいて、後続ヘッダの有無に関する情報、および宛先ＢＡＰアドレスとパスＩＤとの組合せが含まれる。ＩＡＢノードは、拡張ヘッダより、宛先ＢＡＰアドレスおよびパスＩＤを取得するとともに、後続ヘッダの有無に関する情報を取得する。ＩＡＢノードは、最後の拡張ヘッダに含まれる該情報が非であることを用いて、後続ヘッダの取得を停止する。
　図１７の拡張ヘッダにおいて、データＰＤＵ／制御ＰＤＵのいずれであるかを示す情報（Ｄ／Ｃ）が含まれる例について示したが、該情報が含まれないとしてもよい。該情報の代わりに、予約ビットが含まれてもよい。このことにより、例えば、今後の拡張性を向上可能となる。
　図１７に示すように、拡張ヘッダにＤ／Ｃが含まれてもよい。このことにより、例えば、ＩＡＢドナーＤＵにおけるヘッダ生成処理に関する複雑性を回避可能となる。ＩＡＢノードは、拡張ヘッダに含まれるＤ／Ｃを無視してもよい。このことにより、例えば、ＩＡＢノードにおけるヘッダ取得処理を迅速に実行可能となる。
　複数のＢＡＰアドレスに対して、同じパスＩＤが設定されてもよい。このことにより、例えば、ＢＡＰヘッダのサイズを削減可能となるとともに、ＩＡＢ基地局におけるパスＩＤの使用個数を削減可能となる。
　図１８は、ＢＡＰヘッダの他の例を示した図である。図１８は、複数のＢＡＰアドレスと１つのパスＩＤを含む、可変長ヘッダの例について示す。図１８に示すＢＡＰヘッダには、宛先ＢＡＰアドレスの数（Ｎ）が含まれる。ＢＡＰヘッダの末尾において、ＢＡＰヘッダをオクテット単位とするためのパディングが含まれる。ＩＡＢノードは、ＢＡＰヘッダに含まれるＮの値を用いて、１つまたは複数の宛先ＢＡＰアドレスと、１つのパスＩＤとを取得する。
　図１８において、ＢＡＰヘッダに宛先ＢＡＰアドレスの数が含まれる例について示したが、ＢＡＰヘッダのサイズが含まれてもよい。このことにより、例えば、ＩＡＢノードはＢＡＰヘッダを迅速に取得可能となる。
　図１８において、２つ目以降のＢＡＰアドレスがパスＩＤの後に含まれる場合について示したが、パスＩＤが最後のＢＡＰアドレスの後ろに含まれるとしてもよい。このことにより、例えば、ＢＡＰヘッダ処理の実装における複雑性を回避可能となる。
　図１９は、ＢＡＰヘッダの他の例を示した図である。図１９は、複数のＢＡＰアドレスと１つのパスＩＤとを含む、固定長の基本ヘッダおよび可変長の拡張ヘッダの例について示す。図１９において、ＢＡＰヘッダのうち白色の領域は基本ヘッダ、灰色の領域は拡張ヘッダとなる。
　図１９に示す基本ヘッダにおいて、後続ヘッダの有無に関する情報、および１つ目の宛先ＢＡＰアドレスとパスＩＤが含まれる。ＩＡＢノードは、基本ヘッダより、１つ目の宛先ＢＡＰアドレスおよびパスＩＤを取得するとともに、後続ヘッダの有無に関する情報を取得する。ＩＡＢノードは、該情報が是であることを用いて、後続ヘッダを取得する。
　図１９に示す後続ヘッダにおいて、宛先ＢＡＰアドレスの個数（Ｎ）、および、２個目以降の宛先ＢＡＰアドレスが含まれる。また、後続ヘッダの末尾において、後続ヘッダをオクテット単位とするためのパディングが含まれる。後続ヘッダに含まれるＮの値は、基本ＢＡＰヘッダに含まれる宛先ＢＡＰアドレスを除外した数であってもよいし、含めた数であってもよい。ＩＡＢノードは、前述のＮの値を用いて、後続ヘッダに含まれる宛先ＢＡＰアドレスの数を把握してもよいし、後続ヘッダのサイズを把握してもよい。後続ヘッダを設けることにより、例えば、基本ヘッダのサイズを固定長とできるため、基本ヘッダの取得を迅速に可能となる。
　図２０は、ＢＡＰヘッダの他の例を示した図である。図２０は、固定長の基本ヘッダおよび１つまたは複数の固定長の拡張ヘッダの例について示す。図２０において、ＢＡＰヘッダのうち白色の領域は基本ヘッダ、灰色の領域は拡張ヘッダとなる。
　図２０に示す基本ヘッダは、図１９と同様であるため、説明を省略する。
　図２０に示す拡張ヘッダにおいて、後続ヘッダの有無に関する情報、および宛先ＢＡＰアドレスが含まれる。ＩＡＢノードは、拡張ヘッダより、宛先ＢＡＰアドレスを取得するとともに、後続ヘッダの有無に関する情報を取得する。ＩＡＢノードは、該情報が是であることを用いて、後続ヘッダを取得する。
　図２０に示す最後の拡張ヘッダにおいて、後続ヘッダの有無に関する情報、および宛先ＢＡＰアドレスが含まれる。ＩＡＢノードは、拡張ヘッダより、宛先ＢＡＰアドレスを取得するとともに、後続ヘッダの有無に関する情報を取得する。ＩＡＢノードは、最後の拡張ヘッダに含まれる該情報が非であることを用いて、後続ヘッダの取得を停止する。
　図２０に示す例において、拡張ヘッダのサイズを２オクテットとする場合について示したが、基本ヘッダと同じ３オクテットであってもよい。例えば、拡張ヘッダにおける宛先ＢＡＰアドレスの後ろの１０ビットがパディングであってもよい。このことにより、例えば、ＩＡＢノードにおけるＢＡＰヘッダ取得処理に関する複雑性を回避可能となる。
　ＩＡＢノードは、ＢＡＰヘッダに変更を加えてもよい。ＩＡＢノードは、例えば、ＢＡＰヘッダに含まれる一部の情報を削除してもよい。一部の情報は、例えば、自ノードに設定されていないＢＡＰアドレスであってもよいし、自ノードに設定されていないパスＩＤであってもよいし、前述の組合せであってもよい。このことにより、例えば、ＢＡＰヘッダのサイズを削減可能となる。ＢＡＰヘッダの削除は、送信処理を行うＢＡＰレイヤにおいて行われてもよいし、受信処理を行うＢＡＰレイヤにおいて行われてもよい。
　他の解決策として、ＩＡＢノードのグルーピングが行われてもよい。該グルーピングに、ＢＡＰアドレスが用いられてもよい。例えば、マルチキャスト用ＢＡＰアドレスが設けられてもよい。ＩＡＢドナーＣＵはＩＡＢノードに、該ＢＡＰアドレスを割当ててもよい。ＩＡＢドナーＤＵおよび／あるいはＩＡＢノードは、マルチキャスト用ＢＡＰアドレスを用いて子ＩＡＢノードへのマルチキャスト送信を行ってもよい。このことにより、例えば、マルチキャスト送信を迅速に実行可能となる。
　マルチキャスト用ＢＡＰアドレスは、マルチキャストのサービスあるいはコンテンツ毎に設けられてもよい。このことにより、例えば、通信システムの各装置はマルチキャストに係るサービスあるいはコンテンツを迅速に認識可能となる。
　マルチキャスト用ＢＡＰアドレスは、ＢＡＰアドレスとして取りうる値の範囲のうち所定の範囲において設けられてもよい。例えば、先頭４ビットが全て‘１’であるＢＡＰアドレスの範囲が、マルチキャスト用のＢＡＰアドレスとして設けられてもよい。このことにより、例えば、通信システムの各装置は、ＢＡＰアドレスがマルチキャスト用か否かを迅速に認識可能となる。
　ＩＡＢドナーＣＵはＩＡＢドナーＤＵおよび／あるいはＩＡＢノードに対する設定、例えば、ルーティングに関する設定を、Ｆ１シグナリングを用いて行ってもよい。該Ｆ１シグナリングは、例えば、ＢＡＰマッピング設定（BAP　MAPPING　CONFIGURATION）のシグナリング（非特許文献３５（ＴＳ３８．４７３）参照）であってもよいし、他のシグナリングであってもよい。
　該設定に、ＢＡＰレイヤのルーティングに関する情報が含まれてもよい。ＩＡＢドナーＣＵが該情報を該設定に含めてもよい。該設定は、ＰＴＭレッグとＰＴＰレッグのそれぞれについて行われてもよい。ＢＡＰレイヤのルーティングに関する情報には、ルーティングを識別する情報、例えば、ルーティングの識別子が含まれてもよいし、ＩＡＢドナーＤＵおよび／あるいはＩＡＢノードのＢＡＰアドレス（非特許文献３５（ＴＳ３８．４７３）参照）に関する情報が含まれてもよいし、次のホップ先、例えば、子ＩＡＢノードのＢＡＰアドレスに関する情報が含まれてもよいし、マルチキャストデータを受信するＵＥと直接接続するＩＡＢノードのＢＡＰアドレスに関する情報が含まれてもよいし、ＩＡＢドナーＣＵからＵＥまでの経路に関する情報、例えば、経路の識別子に関する情報が含まれてもよい。このことにより、例えば、ＩＡＢドナーＤＵおよび／あるいはＩＡＢノードは、マルチキャストデータのＵＥまでのルーティングを円滑に実行可能となる。
　該設定に、ＢＡＰレイヤのルーティングに関する情報が複数含まれてもよい。例えば、ＰＴＭレッグを用いる送信におけるルーティングに関する情報と、ＰＴＰレッグを用いる送信におけるルーティングに関する情報が含まれてもよい。ＰＴＰレッグを用いる送信におけるルーティングに関する情報が複数含まれてもよいし、ＰＴＭレッグを用いる送信におけるルーティングに関する情報が複数含まれてもよい。ＩＡＢノードは、ＢＡＰヘッダに含まれる情報、例えば、ＤＥＳＴＩＮＡＴＩＯＮおよび／あるいはパスＩＤの情報を用いて、ルーティング先を切替えてもよい。このことにより、例えば、ＩＡＢノードにおけるルーティング先の動的な変更が可能となる。
　該設定に、マルチキャストを送信可能なエリアに関する情報が含まれてもよい。ＩＡＢノードは、該情報を用いて、マルチキャストのデータの送信範囲が該エリアに収まるようにビームおよび／あるいは送信電力を制御してもよい。このことにより、例えば、送信可能なエリア外への該マルチキャストのデータの送信を防止可能となる。
　該設定に、送信方法に関する情報が含まれてもよい。該情報には、ＰＴＭレッグを用いることを示す情報が含まれてもよいし、ＰＴＰレッグを用いることを示す情報が含まれてもよい。該情報が、送信先の子ＩＡＢノードおよび／あるいはＵＥ毎に設けられてもよい。ＩＡＢドナーＤＵおよび／あるいはＩＡＢノードは、該情報を用いて、子ＩＡＢノードおよび／あるいはＵＥへの送信に用いるレッグを決めてもよい。このことにより、例えば、ＩＡＢドナーＤＵおよび／あるいはＩＡＢノードは該送信に用いるレッグを迅速に決定可能となる。
　ＩＡＢドナーＤＵおよび／あるいはＩＡＢノードから子ＩＡＢノードおよび／あるいはＵＥへの送信方法に、所定のモードが設けられてもよい。例えば、子ＩＡＢノードにもＵＥにもＰＴＭレッグを用いて送信するモードが存在してもよいし、ＵＥに対してＰＴＭレッグ、子ＩＡＢノードに対してＰＴＰレッグをそれぞれ用いて送信するモードが存在してもよいし、ＵＥに対してＰＴＰレッグ、子ＩＡＢノードに対してＰＴＭレッグをそれぞれ用いて送信するモードが存在してもよいし、子ＩＡＢノードにもＵＥにもＰＴＰレッグを用いて送信するモードが存在してもよい。他の例として、ＵＥに対してＰＴＰレッグ、ＰＴＭレッグの両方を使用可能とするモードが存在してもよいし、ＵＥに対してＰＴＰレッグのみを用いて送信するモードが存在してもよいし、ＵＥに対してＰＴＭレッグのみを用いて送信するモードが存在してもよいし、子ＩＡＢノードに対してＰＴＰレッグ、ＰＴＭレッグの両方を使用可能とするモードが存在してもよいし、子ＩＡＢノードに対してＰＴＰレッグのみを用いて送信するモードが存在してもよいし、子ＩＡＢノードに対してＰＴＭレッグのみを用いて送信するモードが存在してもよいし、前述の組合せ、例えば、ＵＥへの送信についての各モードと子ＩＡＢノードへの送信についての各モードが組合せて用いられてもよい。該モードが、子ＩＡＢノードおよび／あるいはＵＥ毎に設定可能であってもよい。該モードを、ＩＡＢドナーＣＵが決定してＩＡＢドナーＤＵおよび／あるいはＩＡＢノードに通知してもよい。該モードが、前述の該設定に含まれてもよい。ＩＡＢドナーＤＵおよび／あるいはＩＡＢノードは、該モードに関する情報を用いて、子ＩＡＢノードおよび／あるいはＵＥへの送信に用いるレッグを決めてもよい。このことにより、例えば、ＩＡＢドナーＤＵおよび／あるいはＩＡＢノードは、該送信に用いるレッグを迅速に決定可能となり、その結果、ＩＡＢドナーＤＵおよび／あるいはＩＡＢノードからの送信処理における処理量を削減可能となる。
　ＩＡＢノードを用いたルーティングにおいて、ＰＴＭレッグを用いて受信したマルチキャストデータがＰＴＰレッグを用いて送信されるとしてもよいし、ＰＴＰレッグを用いて受信したマルチキャストデータがＰＴＭレッグを用いて送信されるとしてもよいし、ＰＴＭレッグを用いて受信したマルチキャストデータがＰＴＭレッグを用いて送信されるとしてもよいし、ＰＴＰレッグを用いて受信したマルチキャストデータがＰＴＰレッグを用いて送信されるとしてもよい。このことにより、例えば、通信システムにおける柔軟性を向上可能となる。
　ＢＡＰレイヤのルーティングが、マルチキャストを送信可能なエリアに関する情報を用いて決められてもよい。例えば、該マルチキャストのルーティングを行うＩＡＢノードは、送信範囲が該エリアに含まれるＩＡＢノードの中から決められてもよい。このことにより、例えば、送信可能なエリア外への該マルチキャストのデータの送信を防止可能となる。
　マルチキャストを送信可能なエリアに関する情報を、コアＮＷ装置が決定してもよい。コアＮＷ装置はＩＡＢドナーＣＵに対して、該情報を通知してもよい。他の例として、コアＮＷ装置がＩＡＢドナーＣＵに対して、該エリアに属するＩＡＢノードに関する情報を通知してもよい。ＩＡＢドナーＣＵは前述の情報を用いて、ルーティングを行うＩＡＢノードを決定してもよい。このことにより、例えば、ＩＡＢドナーＣＵはマルチキャストを送信可能なエリア内のＩＡＢノードを適切に選択可能となる。
　ＩＡＢドナーＤＵおよび／あるいはＩＡＢノードは、子ＩＡＢノードおよび／あるいはＵＥに割り当てる識別子を決定してもよい。該識別子は、例えば、Ｇ－ＲＮＴＩおよび／あるいはＳＣ－ＲＮＴＩ（非特許文献３４（ＴＳ３６．３２１）参照）であってもよいし、Ｃ－ＲＮＴＩであってもよい。ＩＡＢドナーＤＵおよび／あるいはＩＡＢノードは、ＩＡＢドナーＣＵに対し、該識別子を通知してもよい。該通知は、Ｆ１シグナリング、例えば、ＵＬ　ＲＲＣ　ＭＥＳＳＡＧＥ　ＴＲＡＮＳＦＥＲ（非特許文献３５（ＴＳ３８．４７３）参照）のシグナリングを用いて行われてもよい。
　マルチキャスト用ＢＡＰアドレスと、前述のＧ－ＲＮＴＩおよび／あるいはＳＣ－ＲＮＴＩとの間の対応付けが行われてもよい。例えば、ＩＡＢドナーＣＵは、前述のＧ－ＲＮＴＩおよび／あるいはＳＣ－ＲＮＴＩを用いて、マルチキャスト用ＢＡＰアドレスを決定してもよい。例えば、ＩＡＢドナーＤＵおよび／あるいはＩＡＢノードは、次のホップ先のＢＡＰアドレスがマルチキャスト用ＢＡＰアドレスとなっているデータの送信先を、前述のＧ－ＲＮＴＩに割り当てている子ＩＡＢノードおよび／あるいはＵＥとしてもよい。このことにより、例えば、通信システムの効率を向上可能となる。
　同じＩＡＢノードに対して、１つまたは複数のＢＡＰアドレスが割り当てられてもよい。ＩＡＢノードに割り当てられるＢＡＰアドレスに、マルチキャスト用ＢＡＰアドレスが含まれてもよい。
　ＩＡＢドナーＣＵはＩＡＢノードに対し、複数のＢＡＰアドレスを設定してもよい。該設定に、例えば、ＲＲＣシグナリング、例えば、ＲＲＣ再設定（ＲＲＣＲｅｃｏｎｆｉｇｕｒａｔｉｏｎ）のシグナリングが用いられてもよい。例えば、ＲＲＣ再設定のシグナリングに含まれるＢＡＰ設定（ｂａｐ－ｃｏｎｆｉｇ）の情報要素において、複数のＢＡＰアドレスを設定可能としてもよい。ＩＡＢドナーＣＵからＩＡＢノードへの該設定は、該ＩＡＢノードの親ＩＡＢノードを経由して行われてもよい。なお、親ＩＡＢノードは、該ＩＡＢノードが接続しているＩＡＢノードである。ＩＡＢドナーＣＵは親ＩＡＢノードに対し、該ＩＡＢノードに通知するＲＲＣシグナリングを送信してもよい。該送信には、例えば、ＤＬ　ＲＲＣ　ＭＥＳＳＡＧＥ　ＴＲＡＮＳＦＥＲのシグナリングが用いられてもよい。親ＩＡＢノードは該シグナリングを用いて、該ＩＡＢノードに送信するシグナリングを取得してもよい。親ＩＡＢノードは該シグナリングを用いて、該ＩＡＢノードに設定される情報、例えば、該ＩＡＢノードに割当てられるＢＡＰアドレスを取得してもよい。このことにより、例えば、親ＩＡＢノードは該ＩＡＢノードに割当てられるマルチキャスト用ＢＡＰアドレスを把握可能となる。
　ＩＡＢドナーＣＵはＩＡＢノードに対し、該ＩＡＢノードの配下に存在するＩＡＢノードに関する情報を通知してもよい。該通知は、Ｆ１シグナリング、例えば、ＢＡＰ　ＭＡＰＰＩＮＧ　ＣＯＮＦＩＧＵＲＡＴＩＯＮのシグナリングを用いて行われてもよいし、ＲＲＣシグナリング、例えば、ＲＲＣ再設定のシグナリングを用いて行われてもよい。該情報には、例えば、配下のＩＡＢノードに割当てられる１つまたは複数のＢＡＰアドレスに関する情報が含まれてもよい。このことにより、例えば、ＩＡＢノードは配下のＩＡＢノードに割当てられたＢＡＰアドレスに関する情報を取得可能となり、その結果、ルーティング処理を円滑に実行可能となる。
　該情報に、配下のＩＡＢノードの階層に関する情報が含まれてもよい。該階層は、例えば、自ＩＡＢノードを基準とした階層であってもよいし、ＩＡＢドナーＣＵを基準とした階層であってもよいし、ＩＡＢドナーＤＵを基準とした階層であってもよい。
　階層に関する該情報の他の例として、ＵＥを基準とした階層であってもよい。基準としたＵＥを識別する情報、例えば、ＵＥ識別子が含まれてもよい。ＩＡＢノードは、該情報を用いて、子ＩＡＢノードおよび／あるいはＵＥに対するスケジューリングを行ってもよい。このことにより、例えば、マルチキャストにおける遅延を削減可能となる。
　階層に関する該情報に、階層の基準とした装置（例、ＩＡＢドナーＣＵ、ＩＡＢドナーＤＵ、ＵＥ）に関する情報が含まれてもよい。ＩＡＢノードは、該情報を用いて、階層の基準となる装置に関する情報を取得してもよい。このことにより、例えば、マルチキャスト送信処理に関する誤動作の確率を低減可能となる。
　同じＩＡＢノードに対して、１つまたは複数のＴＮＬアドレス（非特許文献３５（ＴＳ３８．４７３）参照）が割り当てられてもよい。ＴＮＬアドレスの割り当ては、例えば、末端ＩＡＢノードに対して行われてもよい。ＴＮＬアドレスは、例えば、ＩＰｖ４アドレスであってもよいし、ＩＰｖ６であってもよいし、ＩＰｖ６プレフィックスであってもよい。ＴＮＬアドレスの中に、マルチキャストＩＰアドレスが含まれてもよい。
　マルチキャスト用ＢＡＰアドレスが、宛先ＢＡＰアドレスとして用いられてもよい。このことにより、例えば、ＢＡＰヘッダのサイズを削減可能となる。
　マルチキャスト用ＢＡＰアドレスが、次ホップＢＡＰアドレスとして用いられてもよい。このことにより、例えば、ＣＵからＩＡＢノードに対するルーティング設定のシグナリングのサイズを削減可能となる。
　ＩＡＢ基地局を用いたマルチキャストにおいて、ユニキャスト用ＢＡＰアドレス、すなわち、通常のＢＡＰアドレスが用いられてもよい。例えば、マルチキャスト用ＢＡＰアドレスを割当てられないＩＡＢノードに対するマルチキャストデータの送信においてユニキャスト用ＢＡＰアドレスが用いられてもよいし、マルチキャスト用ＢＡＰアドレスが割り当てられているＩＡＢノードへのマルチキャストデータの送信においてユニキャスト用ＢＡＰアドレスが用いられてもよい。このことにより、例えば、通信システムの柔軟性を向上可能となる。
　図２１および図２２は、ＩＡＢ基地局におけるマルチキャストの設定シーケンスである。図２１はシーケンスの前半部分を示し、図２２はシーケンスの後半部分を示す。すなわち、ＩＡＢ基地局におけるマルチキャストの設定では、まず、図２１に示すステップＳＴ１５１０～ステップＳＴ１５２８が実行され、次に、図２２に示すステップＳＴ１５３２～ステップＳＴ１５９４が実行される。図２１および図２２に示す例において、ＵＥはＩＡＢノード＃２、ＩＡＢノード＃１、ＩＡＢドナーＤＵを経由してＩＡＢドナーＣＵと接続している。図２１および図２２に示す例において、ＵＥは予めマルチキャストに関する情報を入手済みであるとする。
　図２１に示すステップＳＴ１５１０において、ＵＥはＡＭＦに対して、ＰＤＵセッション変更（modification）要求を行う。該要求は、ＮＡＳシグナリングを用いて行われてもよい。該要求に、ＵＥが受信したいマルチキャストに関する情報が含まれてもよい。ステップＳＴ１５１２において、ＡＭＦはＳＭＦに対し、ＰＤＵセッション変更要求があったことを通知する。該通知は、例えば、Nsmf_PDUSession_UpdateSMContextのサービス動作（非特許文献３７（ＴＳ２３．５０２）参照）を用いて行われてもよい。該通知に、ＵＥが受信したいマルチキャストに関する情報が含まれてもよい。ステップＳＴ１５１４において、ＳＭＦは、ＵＥの該マルチキャストの受信可否をチェックする。ステップＳＴ１５１６において、ＳＭＦは統合データレポジトリ（Unified　Data　Repository：ＵＤＲ）（非特許文献２１（ＴＳ２３．５０１）参照）に対し、該マルチキャストに関する情報の問合せおよびＵＤＲからの該情報の取得を行う。ステップＳＴ１５１８において、ＳＭＦはマルチキャスト／ブロードキャスト用ＳＭＦ（ＭＢ－ＳＭＦ）（非特許文献２８（ＴＲ２３．７５７）参照）に対し、マルチキャストのＱｏＳに関する情報を要求する。ステップＳＴ１５２０において、ＭＢ－ＳＭＦはＳＭＦに対し、該要求に対する応答を通知する。該応答に、マルチキャストのＱｏＳに関する情報が含まれてもよい。
　図２１に示すステップＳＴ１５２２において、ＳＭＦはＡＭＦに対し、基地局へのメッセージの送信を要求する。該要求は、Namf_Communication_N1N2MessageTransferのサービス動作（非特許文献３７（ＴＳ２３．５０２）参照）を用いて行われてもよい。該要求には、基地局におけるマルチキャスト用コンテキストの生成の要求が含まれてもよい。ステップＳＴ１５２４において、ＡＭＦはＩＡＢドナーＣＵに対し、ＰＤＵセッションの変更を要求する。該要求には、例えば、PDU　Session　Resource　Modify　Requestのシグナリング（非特許文献３８（ＴＳ３８．４１３）参照）が用いられてもよい。該要求に、マルチキャストのセッションに関する情報が含まれてもよい。ＩＡＢドナーＣＵは、該情報を用いて、マルチキャストのセッションに関する情報を取得してもよい。
　図２１に示すステップＳＴ１５２６において、ＩＡＢドナーＣＵはＩＡＢノード＃２に対し、ＰＤＵセッション変更要求を通知する。該要求に、マルチキャストのセッションに関する情報が含まれてもよい。該通知は、ＩＡＢドナーＤＵ、ＩＡＢノード＃１を経由して行われてもよい。該通知は、Ｆ１シグナリング、例えば、ＤＬ　ＲＲＣ　ＭＥＳＳＡＧＥ　ＴＲＡＮＳＦＥＲを用いて行われてもよい。ステップＳＴ１５２８において、ＩＡＢノード＃２はＵＥに対し、ＰＤＵセッション変更要求を通知する。ＵＥは、ステップＳＴ１５２８の情報を用いて、マルチキャストのセッションに関する情報を取得してもよい。ＵＥは、ＰＤＵセッションの情報を変更してもよい。
　図２２に示すステップＳＴ１５３２～ステップＳＴ１５６２において、ＩＡＢ基地局とＵＥとの間でマルチキャストの送信に関する設定が行われる。
　図２２に示すステップＳＴ１５３２において、ＩＡＢドナーＣＵはＩＡＢドナーＤＵに対し、ルーティングに関する情報を設定する。ＩＡＢドナーＣＵは、ステップＳＴ１５２４の要求の受信を契機として、該設定に必要な情報を決定してもよい。例えば、ＩＡＢドナーＣＵは、ステップＳＴ１５２４で受信した要求に含まれる情報を用いて、マルチキャストに係るＰＤＵセッション、ルーティングに用いられるＩＡＢノードを決定してもよい。ルーティングに関する情報には、ＩＡＢドナーＤＵのＢＡＰアドレスに関する情報が含まれてもよいし、経路に関する情報、例えば、ＵＥに直接接続するＩＡＢノードに関する情報が含まれてもよいし、次ホップ先のＢＡＰアドレスに関する情報が含まれてもよいし、用いるＲＬＣチャネルの識別子に関する情報が含まれてもよい。該情報には、該ＩＡＢノードのＴＮＬアドレスが含まれてもよい。該ＢＡＰアドレスはマルチキャスト用ＢＡＰアドレスであってもよい。該ＴＮＬアドレスは、マルチキャストＩＰアドレスとして与えられてもよい。ステップＳＴ１５３２における設定には、Ｆ１シグナリング、例えば、ＢＡＰ　ＭＡＰＰＩＮＧ　ＣＯＮＦＩＧＵＲＡＴＩＯＮのシグナリングが用いられてもよい。該シグナリングにおいて、ＢＡＰアドレスが複数与えられてもよい。例えば、該シグナリングに含まれるＢＡＰ　Ｒｏｕｔｉｎｇ　ＩＤの情報要素（ＩＥ）に、複数のＢＡＰアドレスが含まれてもよい。複数のＢＡＰアドレスの中に、該ＩＡＢノードのＢＡＰアドレスが含まれてもよい。該シグナリングにおいて、ＴＮＬアドレスが複数与えられてもよい。例えば、該シグナリングに含まれる、ＩＰからレイヤ２へのトラフィックマッピング情報（ＩＰ　ｔｏ　ｌａｙｅｒ２　Ｔｒａｆｆｉｃ　Ｍａｐｐｉｎｇ　Ｉｎｆｏ）（非特許文献３５（ＴＳ３８．４７３）参照）の情報要素において、宛先ＩＡＢ　ＴＮＬアドレスが複数含まれてもよい。ステップＳＴ１５３４において、ＩＡＢドナーＤＵはＩＡＢドナーＣＵに対して、ステップＳＴ１５３２に対する応答を通知する。図２２に示す例においては、肯定応答が通知される。ステップＳＴ１５３４の通知には、Ｆ１シグナリング、例えば、ＢＡＰ　ＭＡＰＰＩＮＧ　ＣＯＮＦＩＧＵＲＡＴＩＯＮ　ＡＣＫＮＯＷＬＥＤＧＥＭＥＮＴのシグナリングが用いられてもよい。ステップＳＴ１５３６において、ＩＡＢドナーＤＵは、子ＩＡＢノード、図２２に示す例ではＩＡＢノード＃１に割り当てる識別子をＩＡＢドナーＣＵに通知する。該識別子は、Ｃ－ＲＮＴＩであってもよいし、Ｇ－ＲＮＴＩであってもよいし、ＳＣ－ＲＮＴＩであってもよいし、前述のうち複数を含んでもよい。該通知には、ＩＡＢドナーＤＵがＩＡＢノード＃１との間の通信に用いるＲＲＣ設定に関する情報が含まれてもよい。ＩＡＢドナーＤＵは、ステップＳＴ１５３２の受信を契機として、ステップＳＴ１５３６の通知を行ってもよい。該通知には、Ｆ１シグナリング、例えば、ＵＬ　ＲＲＣ　ＭＥＳＳＡＧＥ　ＴＲＡＮＳＦＥＲが用いられてもよい。
　図２２に示すステップＳＴ１５３８において、ＩＡＢドナーＣＵはＩＡＢドナーＤＵに対して、ＩＡＢノード＃１との間のマルチキャスト通信に用いるＲＲＣ設定を通知する。該通知は、Ｆ１シグナリング、例えば、ＤＬ　ＲＲＣ　ＭＥＳＳＡＧＥ　ＴＲＡＮＳＦＥＲのシグナリングが用いられてもよい。ステップＳＴ１５４０において、ＩＡＢドナーＤＵはＩＡＢノード＃１に対し、マルチキャストに関する設定を行う。該設定には、ＰＴＭレッグに関する設定が含まれてもよいし、ＰＴＰレッグに関する設定が含まれてもよい。該設定には、例えば、ＲＲＣ再設定のシグナリングが用いられてもよい。ステップＳＴ１５４０には、ＩＡＢノード＃１の識別子、例えば、Ｃ－ＲＮＴＩ、Ｇ－ＲＮＴＩ、および／あるいはＳＣ－ＲＮＴＩに関する情報が含まれてもよいし、ＢＡＰアドレスに関する情報が含まれてもよいし、ＲＬＣ設定に関する情報が含まれてもよいし、ＭＡＣ設定に関する情報が含まれてもよいし、ＰＨＹ設定に関する情報が含まれてもよいし、論理チャネルに関する情報、例えば、論理チャネルの識別に用いられる情報が含まれてもよい。該ＢＡＰアドレスには、ＩＡＢノード＃１のＢＡＰアドレスに関する情報が含まれてもよいし、次のホップ先、例えば、ＩＡＢノード＃２のＢＡＰアドレスに関する情報が含まれてもよいし、マルチキャストデータを受信するＵＥと直接接続するＩＡＢノードのＢＡＰアドレスに関する情報、例えば、ＩＡＢノード＃２のＢＡＰアドレスに関する情報が含まれてもよい。ＩＡＢノード＃１のＢＡＰアドレスとして、複数のＢＡＰアドレスが含まれてもよいし、次のホップ先のＢＡＰアドレスとして、複数のＢＡＰアドレスが含まれてもよいし、マルチキャストデータを受信するＵＥと直接接続するＩＡＢノードのＢＡＰアドレスとして、複数のＢＡＰアドレスが含まれてもよい。前述のＢＡＰアドレスに、マルチキャスト用ＢＡＰアドレスが含まれてもよい。前述の情報が、ＰＴＭレッグとＰＴＰレッグのそれぞれに関する情報として含まれてもよい。ステップＳＴ１５４２において、ＩＡＢノード＃１はＩＡＢドナーＤＵに対して、マルチキャストに関する設定の完了を通知する。該通知には、例えば、ＲＲＣ再設定完了（RRCReconfigurationComplete）のシグナリングが用いられてもよい。ステップＳＴ１４４３において、ＩＡＢドナーＤＵはＩＡＢドナーＣＵに対して、ＩＡＢノード＃１のＲＲＣ再設定完了に関する情報を通知する。該通知には、Ｆ１シグナリング、例えば、ＵＬ　ＲＲＣ　ＭＥＳＳＡＧＥ　ＴＲＡＮＳＦＥＲのシグナリングが用いられてもよい。ＩＡＢドナーＣＵは、ＳＴ１５４３を契機として、ＩＡＢノード＃１に対するマルチキャスト設定が完了したことを認識してもよい。
　図２２に示すステップＳＴ１５４４において、ＩＡＢドナーＣＵはＩＡＢノード＃１に対し、ルーティングに関する情報を設定する。ルーティングに関する情報には、ＩＡＢノード＃１のＢＡＰアドレスに関する情報が含まれてもよいし、経路に関する情報、例えば、ＵＥに直接接続するＩＡＢノードに関する情報が含まれてもよいし、次ホップ先のＢＡＰアドレスに関する情報が含まれてもよいし、用いるＲＬＣチャネルの識別子に関する情報が含まれてもよい。該ＢＡＰアドレスはマルチキャスト用ＢＡＰアドレスであってもよい。ステップＳＴ１５４４における設定には、Ｆ１シグナリング、例えば、ＢＡＰ　ＭＡＰＰＩＮＧ　ＣＯＮＦＩＧＵＲＡＴＩＯＮのシグナリングが用いられてもよい。該シグナリングにおいて、ＢＡＰアドレスが複数与えられてもよい。例えば、該シグナリングに含まれるＢＡＰ　Ｒｏｕｔｉｎｇ　ＩＤの情報要素（ＩＥ）に、複数のＢＡＰアドレスが含まれてもよい。複数のＢＡＰアドレスの中に、該ＩＡＢノードのＢＡＰアドレスが含まれてもよい。ステップＳＴ１５４６において、ＩＡＢノード＃１はＩＡＢドナーＣＵに対して、ステップＳＴ１５４４に対する応答を通知する。図２２に示す例においては、肯定応答が通知される。ステップＳＴ１５４６の通知には、Ｆ１シグナリング、例えば、ＢＡＰ　ＭＡＰＰＩＮＧ　ＣＯＮＦＩＧＵＲＡＴＩＯＮ　ＡＣＫＮＯＷＬＥＤＧＥＭＥＮＴのシグナリングが用いられてもよい。ステップＳＴ１５４８において、ＩＡＢノード＃１は、子ＩＡＢノード、図２２に示す例ではＩＡＢドナー＃２に割り当てる識別子をＩＡＢドナーＣＵに通知する。該識別子は、Ｃ－ＲＮＴＩであってもよいし、Ｇ－ＲＮＴＩであってもよいし、ＳＣ－ＲＮＴＩであってもよいし、前述のうち複数を含んでもよい。該通知には、ＩＡＢノード＃１がＩＡＢノード＃２との間の通信に用いるＲＲＣ設定に関する情報が含まれてもよい。ＩＡＢノード＃１は、ステップＳＴ１５４０の受信を契機として、ステップＳＴ１５４８の通知を行ってもよいし、ステップＳＴ１５４４の受信を契機として、ステップＳＴ１５４８の通知を行ってもよいし、ステップＳＴ１５４０およびステップＳＴ１５４４の両方の受信を契機として、ステップＳＴ１５４８の通知を行ってもよい。該通知には、Ｆ１シグナリング、例えば、ＵＬ　ＲＲＣ　ＭＥＳＳＡＧＥ　ＴＲＡＮＳＦＥＲが用いられてもよい。
　図２２に示すステップＳＴ１５５０において、ＩＡＢドナーＣＵはＩＡＢノード＃１に対して、ＩＡＢノード＃２との間のマルチキャスト通信に用いるＲＲＣ設定を通知する。該通知は、Ｆ１シグナリング、例えば、ＤＬ　ＲＲＣ　ＭＥＳＳＡＧＥ　ＴＲＡＮＳＦＥＲのシグナリングが用いられてもよい。ステップＳＴ１５５２において、ＩＡＢノード＃１はＩＡＢノード＃２に対し、マルチキャストに関する設定を行う。該設定には、ＰＴＭレッグに関する設定が含まれてもよいし、ＰＴＰレッグに関する設定が含まれてもよい。該設定には、例えば、ＲＲＣ再設定のシグナリングが用いられてもよい。ステップＳＴ１５５２には、ＩＡＢノード＃２の識別子、例えば、Ｃ－ＲＮＴＩ、Ｇ－ＲＮＴＩ、および／あるいはＳＣ－ＲＮＴＩに関する情報が含まれてもよいし、ＢＡＰアドレスに関する情報が含まれてもよいし、ＲＬＣ設定に関する情報が含まれてもよいし、ＭＡＣ設定に関する情報が含まれてもよいし、ＰＨＹ設定に関する情報が含まれてもよいし、論理チャネルに関する情報、例えば、論理チャネルの識別に用いられる情報が含まれてもよい。該ＢＡＰアドレスには、ＩＡＢノード＃２のＢＡＰアドレスに関する情報が含まれてもよいし、次のホップ先のＢＡＰアドレスに関する情報が含まれてもよいし、マルチキャストデータを受信するＵＥと直接接続するＩＡＢノードのＢＡＰアドレスに関する情報が含まれてもよい。ＩＡＢノード＃２のＢＡＰアドレスとして、複数のＢＡＰアドレスが含まれてもよいし、次のホップ先のＢＡＰアドレスとして、複数のＢＡＰアドレスが含まれてもよいし、マルチキャストデータを受信するＵＥと直接接続するＩＡＢノードのＢＡＰアドレスとして、複数のＢＡＰアドレスが含まれてもよい。前述のＢＡＰアドレスに、マルチキャスト用ＢＡＰアドレスが含まれてもよい。前述の情報が、ＰＴＭレッグとＰＴＰレッグのそれぞれに関する情報として含まれてもよい。ステップＳＴ１５５４において、ＩＡＢノード＃２はＩＡＢノード＃１に対して、マルチキャストに関する設定の完了を通知する。該通知には、例えば、ＲＲＣ再設定完了のシグナリングが用いられてもよい。ステップＳＴ１５５５において、ＩＡＢノード＃１はＩＡＢドナーＣＵに対して、ＩＡＢノード＃２のＲＲＣ再設定完了に関する情報を通知する。該通知には、Ｆ１シグナリング、例えば、ＵＬ　ＲＲＣ　ＭＥＳＳＡＧＥ　ＴＲＡＮＳＦＥＲのシグナリングが用いられてもよい。ＩＡＢドナーＣＵは、ステップＳＴ１５５５を契機として、ＩＡＢノード＃２に対するマルチキャスト設定が完了したことを認識してもよい。
　図２２に示すステップＳＴ１５５５Ａにおいて、ＩＡＢドナーＣＵはＩＡＢノード＃２に対し、ルーティングに関する情報を設定する。ルーティングに関する情報には、ＩＡＢノード＃２のＢＡＰアドレスに関する情報が含まれてもよいし、経路に関する情報、例えば、ＩＡＢノード＃２が末端ＩＡＢノードであることを示す情報が含まれてもよいし、用いるＲＬＣチャネルの識別子に関する情報が含まれてもよい。該ＢＡＰアドレスはマルチキャスト用ＢＡＰアドレスであってもよい。ステップＳＴ１５５５Ａにおける設定には、Ｆ１シグナリング、例えば、ＢＡＰ　ＭＡＰＰＩＮＧ　ＣＯＮＦＩＧＵＲＡＴＩＯＮのシグナリングが用いられてもよい。該シグナリングにおいて、ＢＡＰアドレスが複数与えられてもよい。例えば、該シグナリングに含まれるＢＡＰ　Ｒｏｕｔｉｎｇ　ＩＤの情報要素（ＩＥ）に、複数のＢＡＰアドレスが含まれてもよい。複数のＢＡＰアドレスの中に、該ＩＡＢノードのＢＡＰアドレスが含まれてもよい。ステップＳＴ１５５５Ｂにおいて、ＩＡＢノード＃２はＩＡＢドナーＣＵに対して、ステップＳＴ１５５５Ａに対する応答を通知する。図２２に示す例においては、肯定応答が通知される。ステップＳＴ１５５５Ｂの通知には、Ｆ１シグナリング、例えば、ＢＡＰ　ＭＡＰＰＩＮＧ　ＣＯＮＦＩＧＵＲＡＴＩＯＮ　ＡＣＫＮＯＷＬＥＤＧＥＭＥＮＴのシグナリングが用いられてもよい。
　図２２に示すステップＳＴ１５５６において、ＩＡＢノード＃２は、ＵＥに割り当てる識別子をＩＡＢドナーＣＵに通知する。該識別子は、Ｃ－ＲＮＴＩであってもよいし、Ｇ－ＲＮＴＩであってもよいし、ＳＣ－ＲＮＴＩであってもよいし、前述のうち複数を含んでもよい。該通知には、ＩＡＢノード＃２がＵＥとの間の通信に用いるＲＲＣ設定に関する情報が含まれてもよい。ＩＡＢノード＃２は、ステップＳＴ１５５４の受信を契機として、ステップＳＴ１５５６の通知を行ってもよい。該通知には、Ｆ１シグナリング、例えば、ＵＬ　ＲＲＣ　ＭＥＳＳＡＧＥ　ＴＲＡＮＳＦＥＲが用いられてもよい。
　図２２に示すステップＳＴ１５５８において、ＩＡＢドナーＣＵはＩＡＢノード＃２に対して、ＵＥとの間のマルチキャスト通信に用いるＲＲＣ設定を通知する。該通知には、Ｆ１シグナリング、例えば、ＤＬ　ＲＲＣ　ＭＥＳＳＡＧＥ　ＴＲＡＮＳＦＥＲのシグナリングが用いられてもよい。ステップＳＴ１５６０において、ＩＡＢノード＃２はＵＥに対し、マルチキャストに関する設定を行う。該設定には、ＰＴＭレッグに関する設定が含まれてもよいし、ＰＴＰレッグに関する設定が含まれてもよい。該設定には、例えば、ＲＲＣ再設定のシグナリングが用いられてもよい。ステップＳＴ１５６０には、ＵＥの識別子、例えば、Ｃ－ＲＮＴＩ、Ｇ－ＲＮＴＩ、および／あるいはＳＣ－ＲＮＴＩに関する情報が含まれてもよいし、ＲＬＣ設定に関する情報が含まれてもよいし、ＭＡＣ設定に関する情報が含まれてもよいし、ＰＨＹ設定に関する情報が含まれてもよいし、論理チャネルに関する情報、例えば、論理チャネルの識別に用いられる情報が含まれてもよい。前述の情報が、ＰＴＭレッグとＰＴＰレッグのそれぞれに関する情報として含まれてもよい。ステップＳＴ１５６２において、ＵＥはＩＡＢノード＃２に対して、マルチキャストに関する設定の完了を通知する。該通知には、例えば、ＲＲＣ再設定完了のシグナリングが用いられてもよい。ステップＳＴ１５６３において、ＩＡＢノード＃２はＩＡＢドナーＣＵに対して、ＵＥのＲＲＣ再設定完了に関する情報を通知する。該通知には、Ｆ１シグナリング、例えば、ＵＬ　ＲＲＣ　ＭＥＳＳＡＧＥ　ＴＲＡＮＳＦＥＲのシグナリングが用いられてもよい。ＩＡＢドナーＣＵは、ステップＳＴ１５６３を契機として、ＵＥに対するマルチキャスト設定が完了したことを認識してもよい。
　図２２に示すステップＳＴ１５７２において、ＩＡＢドナーＣＵはＡＭＦに対して、マルチキャスト配信を要求する。該要求には、ＵＥを識別する情報が含まれてもよいし、マルチキャストを識別する情報が含まれてもよい。ステップＳＴ１５７４において、ＡＭＦはＭＢ－ＳＭＦに対し、マルチキャスト配信を要求する。ステップＳＴ１５７６において、ＭＢ－ＳＭＦとマルチキャスト／ブロードキャスト用ＵＰＦ（ＭＢ－ＵＰＦ）（非特許文献２８（ＴＲ２３．７５７）参照）との間で、マルチキャスト配信に係るセッション情報の変更（Modification）が行われる。ステップＳＴ１５７８において、ＭＢ－ＳＭＦはＡＭＦに対して、マルチキャスト配信要求に対する応答を通知する。ステップＳＴ１５８０において、ＡＭＦはＩＡＢドナーＣＵに対し、マルチキャスト配信要求に対する応答を通知する。
　図２２に示すステップＳＴ１５８２において、ＩＡＢドナーＣＵはＡＭＦに対して、マルチキャスト配信に係るセッション情報の変更に対する応答を通知する。ステップＳＴ１５８４において、ＡＭＦはＳＭＦに対し、セッション情報の変更に対する応答を通知する。該通知には、例えば、Nsmf_PDUSession_UpdateSMContext（非特許文献３７（ＴＳ２３．５０２）参照）の処理が用いられてもよい。
　図２２に示すステップＳＴ１５８６において、ＭＢ－ＵＰＦはＩＡＢドナーＣＵに対してマルチキャストデータを送信する。ステップＳＴ１５８８において、ＩＡＢドナーＣＵはＩＡＢドナーＤＵに対して該データを転送する。ステップＳＴ１５９０において、ＩＡＢドナーＤＵはＩＡＢノード＃１に対して該データを転送する。ステップＳＴ１５９２において、ＩＡＢノード＃１はＩＡＢノード＃２に対して該データを転送する。ステップＳＴ１５９４において、ＩＡＢノード＃２はＵＥに対して該データを転送する。ステップＳＴ１５９０～ステップＳＴ１５９４において、ＰＴＰレッグが用いられてもよいし、ＰＴＭレッグが用いられてもよいし、前述の両方が用いられてもよい。
　図２１、図２２において、ＩＡＢドナーＣＵが１つである場合について示したが、ＩＡＢドナーＣＵが複数設けられてもよい。例えば、Ｃプレイン（Ｃ－Ｐｌａｎｅ）用のＩＡＢドナーＣＵ（ＩＡＢドナーＣＵ－ＣＰ）とＵプレイン（Ｕ－Ｐｌａｎｅ）用のＩＡＢドナーＣＵ（ＩＡＢドナーＣＵ－ＵＰ）が設けられてもよい。ＩＡＢドナーＣＵ－ＵＰは複数設けられてもよい。このことにより、例えば、ＩＡＢドナーＣＵにおける処理量分散による負荷低減が可能となる。
　Ｃプレイン用のＩＡＢドナーＤＵおよび／ＩＡＢノードが設けられてもよいし、Ｕプレイン用のＩＡＢドナーＤＵおよび／あるいはＩＡＢノードが設けられてもよい。ＩＡＢドナーＤＵおよび／あるいはＩＡＢノードがＩＡＢドナーＣＵ－ＣＰにもＩＡＢドナーＣＵ－ＵＰにも接続されてもよい。このことにより、例えば、通信システムにおける柔軟性を向上可能となる。
　ＩＡＢドナーＣＵ－ＣＰはＩＡＢドナーＣＵ－ＵＰに対し、データを送信するＩＡＢドナーＤＵに関する情報を通知してもよい。該通知に、末端ＩＡＢノードに関する情報が含まれてもよい。該通知は、ＣＵ－ＣＰとＣＵ－ＵＰとの間のシグナリング（例、Ｅ１シグナリング）を用いて行われてもよい。ＩＡＢドナーＣＵ－ＵＰは、該通知を用いて、データの送信先のＩＡＢドナーＤＵに対するルーティングを行ってもよいし、該ＩＡＢドナーＤＵに対して該データを送信してもよい。このことにより、例えば、ＩＡＢドナーＣＵ－ＵＰからＩＡＢドナーＤＵへのデータ送信に関する誤動作を防止可能となる。
　Ｃプレイン用のＩＡＢドナーＤＵおよび／ＩＡＢノードが設けられてもよいし、Ｕプレイン用のＩＡＢドナーＤＵおよび／あるいはＩＡＢノードが設けられてもよい。ＩＡＢドナーＤＵおよび／あるいはＩＡＢノードがＩＡＢドナーＣＵ－ＣＰにもＩＡＢドナーＣＵ－ＵＰにも接続されてもよい。このことにより、例えば、通信システムにおける柔軟性を向上可能となる。
　図２１、図２２における、ＩＡＢドナーＣＵと、ＩＡＢドナーＤＵおよび／あるいはＩＡＢノードとの間で送受信されるシグナリングについて、ＩＡＢドナーＣＵがＩＡＢドナーＣＵ－ＣＰに置き換わってもよい。同様に、ＩＡＢドナーＣＵとＵＥとの間で送受信されるシグナリングについて、ＩＡＢドナーＣＵがＩＡＢドナーＣＵ－ＣＰに置き換わってもよい。このことにより、例えば、通信システムにおける複雑性を回避可能となる。
　図２１、図２２に示す設定シーケンスが、マルチキャストの経路の変更に用いられてもよい。経路の変更は、例えば、マルチキャストを受信するＵＥの追加および／あるいは削除において行われてもよいし、ＩＡＢノード間の通信経路が障害物等で遮蔽された場合に行われてもよいし、該通信経路が該遮蔽から復旧した場合に行われてもよい。このことにより、例えば、ＩＡＢノードを用いたマルチキャストにおける経路変更が可能となり、その結果、通信システムにおける柔軟性を向上可能となる。
　マルチキャストの経路の変更において、変更に係るＩＡＢノードのＢＡＰアドレスが、バックホールルーティング情報追加一覧（ＢＨ　Ｒｏｕｔｉｎｇ　Ｉｎｆｏｒｍａｔｉｏｎ　Ａｄｄｅｄ　Ｌｉｓｔ）に含まれてもよいし、バックホールルーティング情報削除一覧（ＢＨ　Ｒｏｕｔｉｎｇ　Ｉｎｆｏｒｍａｔｉｏｎ　Ｒｅｍｏｖｅｄ　Ｌｉｓｔ）に含まれてもよいし、バックホールルーティング情報変更一覧（ＢＨ　Ｒｏｕｔｉｎｇ　Ｉｎｆｏｒｍａｔｉｏｎ　Ｍｏｄｉｆｉｅｄ　Ｌｉｓｔ）として含まれてもよいし、前述のうち複数に含まれてもよい。例えば、バックホールルーティング情報変更一覧に含まれることにより、マルチキャストの経路の変更に係るＦ１シグナリング量の削減が可能となる。
　ＩＡＢドナーＣＵからＩＡＢドナーＤＵへの設定に、マルチキャスト用ＢＡＰアドレスが用いられてもよい。例えば、ＩＰからレイヤ２へのトラフィックマッピング情報（ＩＰ　ｔｏ　ｌａｙｅｒ２　Ｔｒａｆｆｉｃ　Ｍａｐｐｉｎｇ　Ｉｎｆｏ）（非特許文献３５（ＴＳ３８．４７３）参照）の情報要素に含まれるＢＡＰアドレスに、マルチキャスト用ＢＡＰアドレスが含まれてもよい。
　マルチキャスト用ＢＡＰアドレスを用いた該設定に含まれる情報の例として、以下（ａ）～（ｅ）を開示する。
　（ａ）単一のＩＰアドレス、単一又は複数のＢＡＰアドレス、単一又は複数の次ホップＢＡＰアドレス、複数のＲＬＣチャネル識別子。
　（ｂ）単一のＩＰアドレス、単一又は複数のＢＡＰアドレス、単一又は複数の次ホップＢＡＰアドレス、単一のＲＬＣチャネル識別子。
　（ｃ）複数のＩＰアドレス、単一又は複数のＢＡＰアドレス、単一又は複数の次ホップＢＡＰアドレス、複数のＲＬＣチャネル識別子。
　（ｄ）複数のＩＰアドレス、単一又は複数のＢＡＰアドレス、単一又は複数の次ホップＢＡＰアドレス、単一のＲＬＣチャネル識別子。
　（ｅ）前述の（ａ）～（ｄ）の組合せ。
　前述の（ａ）に含まれるＩＰアドレスは、マルチキャストＩＰアドレスであってもよい。前述の（ａ）に含まれるＢＡＰアドレスおよび／あるいは次ホップＢＡＰアドレスに、マルチキャスト用ＢＡＰアドレスが含まれてもよい。前述の（ａ）により、例えば、ＩＡＢノードに対してＰＴＰを用いたマルチキャストが可能となる。
　前述の（ｂ）に含まれるＩＰアドレスは、マルチキャストＩＰアドレスであってもよい。前述の（ｂ）に含まれるＢＡＰアドレスおよび／あるいは次ホップＢＡＰアドレスに、マルチキャスト用ＢＡＰアドレスが含まれてもよい。前述の（ｂ）により、例えば、ＩＡＢノードに対してＰＴＭを用いたマルチキャストが可能となる。
　前述の（ｃ）に含まれるＩＰアドレスは、ユニキャストＩＰアドレスであってもよい。前述の（ｃ）に含まれるＢＡＰアドレスおよび／あるいは次ホップＢＡＰアドレスに、マルチキャスト用ＢＡＰアドレスが含まれてもよい。前述の（ｃ）により、例えば、ＩＡＢノードに対してＰＴＰを用いたマルチキャストが可能となる。
　前述の（ｄ）に含まれるＩＰアドレスは、ユニキャストＩＰアドレスであってもよい。前述の（ｄ）に含まれるＢＡＰアドレスおよび／あるいは次ホップＢＡＰアドレスに、マルチキャスト用ＢＡＰアドレスが含まれてもよい。前述の（ｄ）により、例えば、ＩＡＢノードに対してＰＴＭを用いたマルチキャストが可能となる。
　ＩＡＢドナーＣＵからＩＡＢノードへの設定に、マルチキャスト用ＢＡＰアドレスが含まれてもよい。マルチキャスト用ＢＡＰアドレスは、例えば、次ホップＢＡＰアドレスとして含まれてもよい。例えば、単一又は複数の次ホップＢＡＰアドレスと複数のＲＬＣチャネル識別子を用いることにより、ＩＡＢノードに対しＰＴＰを用いたマルチキャストが可能となる。他の例として、単一又は複数の次ホップＢＡＰアドレスと単一のＲＬＣチャネル識別子との組合せを用いることにより、ＩＡＢノードに対してＰＴＭを用いたマルチキャストが可能となる。
　マルチキャスト用ＢＡＰアドレスのＩＡＢノードへの割り当て方の例として、以下（ア）～（キ）を開示する。
　（ア）末端ＩＡＢノードに割当てる。
　（イ）親ＩＡＢノード毎に子ＩＡＢノードに対して割当てる。
　（ウ）ＢＡＰアドレスの各ビットに各ＩＡＢノードを割当てる。
　（エ）同じＢＡＰアドレスを同じ階層のＩＡＢノードに割当てる。
　（オ）所定の階層以下のＩＡＢノードに同じＢＡＰアドレスを割当てる。
　（カ）ＩＡＢドナーＣＵからＵＥまでの経路となるＩＡＢノードに同じＢＡＰアドレスを割当てる。
　（キ）前述の（ア）～（カ）の組合せ。
　前述の（ア）の方法として、マルチキャスト用ＢＡＰアドレスが、末端ＩＡＢノードに対して割り当てられるとしてもよい。マルチキャスト用ＢＡＰアドレスが割り当てられる末端ＩＡＢノードに、子ＩＡＢノードが接続する末端ＩＡＢノードが含まれてもよい。このことにより、例えば、多くのＩＡＢノードへのマルチキャスト送信が可能となる。他の例として、該末端ＩＡＢノードは、子ＩＡＢノードと接続しない末端ＩＡＢノードのみとしてもよい。このことにより、例えば、末端ＩＡＢノードのＢＡＰレイヤにおける処理の複雑性を回避可能となる。
　図２３は、ＩＡＢ基地局におけるマルチキャスト用ＢＡＰアドレスの割当ての例を示す図である。図２３は、子ＩＡＢノードが接続する親ＩＡＢノードとしての末端ＩＡＢノードにもマルチキャスト用ＢＡＰアドレスが割り当てられる例を示す。図２３において、ＵＥ＃１～＃６はマルチキャストを受信するＵＥ、ハッチング無しのＩＡＢノード＃２～＃５はマルチキャスト用ＢＡＰアドレスが割り当てられるＩＡＢノード、ハッチングありのＩＡＢノード＃１はマルチキャスト用ＢＡＰアドレスが割り当てられないＩＡＢノードを示す。
　図２３に示す例において、ＩＡＢノード＃２～＃５はいずれもマルチキャストを受信するＵＥに接続されている末端ＩＡＢノードである。従って、ＩＡＢノード＃２～＃５に対し、マルチキャスト用ＢＡＰアドレスが割り当てられる。すなわち、ＩＡＢノード＃５の親ＩＡＢノードであるＩＡＢノード＃３にもマルチキャスト用ＢＡＰアドレスが割り当てられる。なお、図２３に示す例において、ＩＡＢノード＃３には、ＵＥ＃２と、子ＩＡＢノードとしてＩＡＢノード＃５とが接続されている。この接続形態の場合、ＩＡＢノード＃３は、ＵＥ＃２からみた末端ＩＡＢノード、ＩＡＢノード＃５からみた親ＩＡＢノードとなる。
　図２４は、ＩＡＢ基地局におけるマルチキャスト用ＢＡＰアドレスの割当ての他の例を示す図である。図２４は、子ＩＡＢノードが接続されない末端ＩＡＢノードにのみマルチキャスト用ＢＡＰアドレスが割り当てられる例を示す。図２４において、ＵＥ＃１～＃６はマルチキャストを受信するＵＥ、ハッチング無しのＩＡＢノード＃２、＃４、＃５はマルチキャスト用ＢＡＰアドレスが割り当てられるＩＡＢノード、ハッチングありのＩＡＢノード＃１、＃３はマルチキャスト用ＢＡＰアドレスが割り当てられないＩＡＢノードを示す。
　図２４に示す例において、ＩＡＢノード＃２～＃５はいずれもマルチキャストを受信するＵＥに接続されているが、ＩＡＢノード＃３は子ＩＡＢノードとなるＩＡＢノード＃５にも接続されている。従って、ＩＡＢノード＃３にはマルチキャスト用ＢＡＰアドレスが割り当てられず、ＩＡＢノード＃２、＃４、＃５に対し、マルチキャスト用ＢＡＰアドレスが割り当てられる。すなわち、図２４に示す例においては、ＵＥが接続され、かつ他のＩＡＢノード（子ＩＡＢノード）が接続されていないＩＡＢノードに対して、マルチキャスト用ＢＡＰアドレスを割り当てる。
　前述の（イ）の方法として、親ＩＡＢノード毎に子ＩＡＢノードに対して割当てるとしてもよい。このことにより、例えば、ＩＡＢドナーＣＵから親ＩＡＢノードに対する次ホップＢＡＰアドレスの設定を、少ないＢＡＰアドレスを用いて設定可能となり、その結果、ＩＡＢドナーＣＵと親ＩＡＢノードの間のＦ１シグナリングのサイズを削減可能となる。
　図２５は、ＩＡＢ基地局におけるマルチキャスト用ＢＡＰアドレスの割当ての例を示す図である。図２５は、同じ親ＩＡＢノードに接続する子ＩＡＢノードに対して同じマルチキャスト用ＢＡＰアドレスが割り当てられる例を示す。図２５において、ＵＥ＃１～＃７はマルチキャストを受信するＵＥ、ドット模様のハッチングがあるＩＡＢノード＃７はマルチキャスト用ＢＡＰアドレスが割り当てられないＩＡＢノードを示す。図２５において、右上がり線のハッチング、右下がり線のハッチング、間隔の狭い右上がり線のハッチングがあるＩＡＢノードは、それぞれ異なるマルチキャスト用ＢＡＰアドレスが割り当てられたＩＡＢノードを示す。言い換えると、ＩＡＢノード＃１～＃６のうち、同じ模様のハッチングがあるＩＡＢノードには同一のマルチキャスト用ＢＡＰアドレスが割り当てられる。
　マルチキャストのコンテンツ間で、同じＢＡＰアドレスが割当てられてもよい。このことにより、例えば、マルチキャストに用いるＢＡＰアドレスの数を削減可能となり、その結果、通信システムにおけるＩＡＢノードの収容数を増加可能となる。
　マルチキャストのコンテンツ毎に、異なるＲＬＣチャネルが用いられてもよい。異なるＲＬＣチャネルの使用は、例えば、マルチキャストのコンテンツ間で同じＢＡＰアドレスが割当てられる場合に行われてもよい。このことにより、例えば、マルチキャストに用いるＢＡＰアドレスの数を削減可能としつつ、マルチキャストのコンテンツを識別可能となる。
　マルチキャストのコンテンツ間で、同じパスＩＤが用いられてもよい。このことにより、例えば、マルチキャストに用いるパスＩＤの数を削減可能となり、その結果、通信システムにおけるＩＡＢノードの収容数を増加可能となる。
　マルチキャストのコンテンツ毎に、異なるＲＬＣチャネルが用いられてもよい。異なるＲＬＣチャネルの使用は、例えば、マルチキャストのコンテンツ間で同じパスＩＤが割当てられる場合に行われてもよい。このことにより、例えば、マルチキャストに用いるパスＩＤの数を削減可能としつつ、マルチキャストのコンテンツを識別可能となる。
　異なる親ＩＡＢノードに接続する子ＩＡＢノードに対して、異なるマルチキャスト用ＢＡＰアドレスが割り当てられるとしてもよい。このことにより、例えば、通信システムにおいてマルチキャスト送信対象のＩＡＢノードを迅速に判別可能となる。
　他の例として、異なる親ＩＡＢノードに接続する子ＩＡＢノードに対して、同じマルチキャスト用ＢＡＰアドレスが割当てられるとしてもよい。該マルチキャスト用ＢＡＰアドレスが、例えば、次ホップＢＡＰアドレスとして用いられてもよい。該マルチキャスト用ＢＡＰアドレスが次ホップＢＡＰアドレスとして用いられる場合において、該次ホップＢＡＰアドレスの値が規格で決められてもよい。このことにより、例えば、ＩＡＢドナーＣＵからＩＡＢドナーＤＵおよび／あるいはＩＡＢノードへの、マルチキャスト用ＢＡＰアドレスの次ホップＢＡＰアドレスとしての設定が不要となり、その結果、Ｆ１シグナリングにおけるサイズを削減可能となる。
　前述の（ウ）の方法として、ＢＡＰアドレスの各ビットに各ＩＡＢノードを割当ててもよい。ＩＡＢドナーＣＵはＩＡＢノードに対し、該ＩＡＢノードに割当てるＢＡＰアドレスのビット位置に関する情報を通知してもよい。ＩＡＢノードは該情報を用いて、自ＩＡＢノードに割当てられるビット位置を認識してもよい。ＩＡＢノードは、ＢＡＰヘッダに含まれるＢＡＰアドレスの当該ビットの値を用いて、自ＩＡＢノードが宛先に含まれるかどうかを判断してもよい。このことにより、例えば、ＩＡＢノードは自ＩＡＢノードが宛先に含まれるかどうかを迅速に判断可能となる。
　図２６は、ＩＡＢ基地局におけるマルチキャスト用ＢＡＰアドレスの割当ての他の例を示す図である。図２６は、ハッチング無しのＵＥ＃１、＃４～＃７はマルチキャストを受信するＵＥ、ハッチングありのＵＥ＃２、＃３はマルチキャストを受信しないＵＥである例について示す。図２６に示す例においては、マルチキャストを受信するＵＥと接続する末端ＩＡＢノードに対してマルチキャストＢＡＰアドレスが割り当てられている。図２６において、ハッチングありのＩＡＢノード＃１～＃３、＃５はマルチキャスト用ＢＡＰアドレスが割り当てられないＩＡＢノード、ハッチングなしのＩＡＢノード＃４、＃６、＃７は、マルチキャスト用ＢＡＰアドレスが割り当てられるＩＡＢノードを示す。
　図２７は、図２６において割り当てられるマルチキャスト用ＢＡＰアドレスのビットマップを示した図である。図２７に示す例のマルチキャスト用ＢＡＰアドレスは、ビット０～ビット９の１０ビットで構成される。図２７に示す例において、ビット０（ＬＳＢ）はＩＡＢドナーＤＵに、ビット１～７はそれぞれＩＡＢノード＃１～＃７に割当てられている。ビット８、９は空きビットである。当該ビットは予約ビットであってもよい。このことにより、例えば、今後の拡張性を向上可能となる。
　図２６においてＩＡＢノード＃４、＃６、＃７にマルチキャスト用ＢＡＰアドレスが割り当てられる。この場合において、図２７におけるビット４、６、７に‘１’が割り当てられ、残りのビットには‘０’が割り当てられる。なお、図２７では、‘１’が割り当てられるビットにハッチングを付加している。従って、図２６、図２７の例において割り当てられるマルチキャスト用ＢＡＰアドレスは、２進数表記で“００１１０１００００”となる。
　図２７において、マルチキャスト用ＢＡＰアドレスが１０ビットである場合の例を示したが、所定のビット数であってもよい。所定の該ビット数は、１０ビットと異なるビット数であってもよい。このことにより、例えば、通信システムにおける柔軟性を向上可能となる。
　図２７において、マルチキャスト用ＢＡＰアドレスの上位２ビットが空きビットである例について示したが、所定のビットパターンが割り当てられてもよい。該ビットパターンは、マルチキャスト用ＢＡＰアドレスであることを示す所定のビットパターンであってもよい。該ビットパターンは、２ビットと異なるビット数であってもよい。ＩＡＢドナーＤＵおよび／あるいはＩＡＢノードは、ＢＡＰアドレスの所定のビット位置の値が該ビットパターンに一致することを契機として、該ＢＡＰアドレスがマルチキャスト用ＢＡＰアドレスであると判断してもよい。このことにより、例えば、通信システムにおける処理量を削減可能となる。
　同じ宛先ＢＡＰアドレスに対し、異なるパスＩＤが割り当てられてもよい。例えば、末端ＩＡＢノードまでの経路のそれぞれに対して異なるパスＩＤが割り当てられてもよい。他の例として、異なるマルチキャストのコンテンツのそれぞれに対し、異なるパスＩＤが割当てられてもよい。パスＩＤをマルチキャストのコンテンツ毎に割当てることにより、例えば、ＩＡＢノードはマルチキャストのコンテンツを迅速に識別可能となる。
　異なる宛先ＢＡＰアドレスに対して、同じパスＩＤが割り当てられてもよい。このことにより、例えば、マルチキャストに用いるパスＩＤの数を削減可能となる。マルチキャストのコンテンツ毎に、異なるＲＬＣチャネルが用いられてもよい。このことにより、例えば、マルチキャストに用いるパスＩＤの数を削減可能としつつ、マルチキャストのコンテンツを識別可能となる。
　前述（ウ）の方法が、ユニキャストに用いられてもよい。このことにより、例えば、ユニキャストにおいてもＩＡＢノードは自ＩＡＢノードが宛先であることを迅速に判断可能となる。
　前述（エ）の方法として、同じＢＡＰアドレスが同じ階層のＩＡＢノードに割当てられてもよい。前述の階層は、ＩＡＢドナーＣＵを基準とした階層であってもよい。
　同じ階層のＩＡＢノードに割当てられるマルチキャスト用ＢＡＰアドレスが、次ホップＢＡＰアドレスとして設定されてもよい。このことにより、例えば、ＩＡＢノードにおけるルーティング処理を迅速に実行可能となる。
　同じ階層のＩＡＢノードに割当てられるマルチキャスト用ＢＡＰアドレスが、送信先ＢＡＰアドレスとして設定されてもよい。送信先ＢＡＰアドレスとして、複数の該ＢＡＰアドレスが設定されてもよい。例えば、末端ＩＡＢノードの階層がそれぞれ異なる場合において、送信先ＢＡＰアドレスとして複数の該ＢＡＰアドレスが設定されてもよい。複数の該ＢＡＰアドレスが、ＢＡＰヘッダに含まれてもよい。ＩＡＢノードおよび／あるいはＩＡＢドナーＤＵは、ＢＡＰヘッダに含まれる複数の該ＢＡＰアドレスを用いてスケジューリングを行ってもよい。例えば、ＩＡＢノードが末端ＩＡＢノードであり、かつ、子ＩＡＢノードが接続されている場合において、該ＩＡＢノードは子ＩＡＢノードへの送信から所定の時間が経過した後にＵＥに対してマルチキャストデータを送信してもよい。所定の該時間は、宛先ＢＡＰヘッダに含まれる該ＢＡＰアドレスの対象となるＩＡＢノードの階層を用いて決められてもよい。このことにより、例えば、同じマルチキャストデータについて、異なる階層の末端ＩＡＢノードに接続するＵＥの間における受信時間差を低減可能となる。
　異なる親ＩＡＢノードに接続する子ＩＡＢノードに対して、同じＢＡＰアドレスが割り当てられてもよい。このことにより、例えば、ＢＡＰアドレスの使用数を削減可能となる。
　該階層を示す所定のＢＡＰアドレスが設けられてもよい。該ＢＡＰアドレスは、あらかじめ規格で決められてもよいし、ＩＡＢドナーＣＵが決定してもよい。所定の該ＢＡＰアドレスに、１つまたは複数のＩＡＢノードが対応付けられてもよい。１つまたは複数のＩＡＢノードは、互いに同じ階層のＩＡＢノードであってもよい。
　前述の対応付けを、ＩＡＢドナーＣＵが決定してＩＡＢドナーＤＵおよび／あるいはＩＡＢノードに通知してもよい。該通知に、該ＢＡＰアドレスと、対象となるＩＡＢノードのＢＡＰアドレスに関する情報が含まれてもよい。該通知が、Ｆ１インタフェース、例えば、非特許文献３５（ＴＳ３８．４７３）に開示されたＢＡＰ　ＭＡＰＰＩＮＧ　ＣＯＮＦＩＧＵＲＡＴＩＯＮのシグナリングに含まれてもよい。該通知に、該ＢＡＰアドレスに代わって階層に関する情報が含まれてもよいし、該ＢＡＰアドレスと階層に関する情報の両方が含まれてもよい。該通知に、該ＩＡＢドナーＤＵおよび／あるいはＩＡＢノードの階層に関する情報が含まれてもよい。ＩＡＢドナーＤＵおよび／あるいはＩＡＢノードは、該情報を用いてルーティングを行ってもよい。このことにより、例えば、ＩＡＢノードのルーティング処理における複雑性を回避可能となる。
　前述の対応付けを、ＩＡＢドナーＤＵおよび／あるいはＩＡＢノードが自律的に行ってもよい。ＩＡＢドナーＤＵおよび／あるいはＩＡＢノードは、自身の階層に関する情報を用いて、配下のＩＡＢノードの階層を導出してもよい。自身の階層に関する情報を、ＩＡＢドナーＣＵがＩＡＢドナーＤＵおよび／あるいはＩＡＢノードに通知してもよい。このことにより、例えば、ＩＡＢノードにおけるルーティング処理を迅速に実行可能となる。
　図２８は、ＩＡＢ基地局におけるマルチキャスト用ＢＡＰアドレスの割当ての例を示す図である。図２８は、同じ階層のＩＡＢノードに対して同じＢＡＰアドレスが割り当てられる例を示す。図２８における階層は、ＩＡＢドナーＤＵを基準とした階層である。図２８において、ＵＥ＃１～＃７はマルチキャストを受信するＵＥ、ドット模様のハッチングがあるＩＡＢノード＃７はマルチキャスト用ＢＡＰアドレスが割り当てられないＩＡＢノードを示す。図２８において、右下がり線が入ったＩＡＢノード、右上がり線が入ったＩＡＢノードは、それぞれ第１階層、第２階層のＩＡＢノードを示す。
　異なる親ＩＡＢノードに接続する子ＩＡＢノードに対して、異なるＢＡＰアドレスが割り当てられてもよい。このことにより、例えば、通信システムの複雑性を回避可能となる。
　前述（エ）の他の方法として、前述の階層は、ＵＥを基準とした階層であってもよい。同じＩＡＢノードが複数の階層に対応するＢＡＰアドレスを有してもよい。例えば、複数のＵＥがそれぞれＩＡＢドナーＣＵを基準として異なる階層に属する場合において、同じＩＡＢノードが複数の階層に対応するＢＡＰアドレスを有してもよい。同じＢＡＰアドレスが同じ階層のＩＡＢノードに割当てられてもよい。他の例として、ＩＡＢノードは、配下の１つまたは複数のＵＥを基準とした階層のうち、一番深い階層に対応するＢＡＰアドレスを有してもよい。ＩＡＢノードは、スケジューリングにおいて該階層の情報を用いてもよい。このことにより、例えば、ＩＡＢノードからＵＥまでのデータ送信における遅延を低減可能となる。他の例として、ＩＡＢノードは、配下の１つまたは複数のＵＥを基準とした階層のうち、一番浅い階層に対応するＢＡＰアドレスを有してもよい。
　前述（オ）の方法として、所定の階層以下のＩＡＢノードに同じＢＡＰアドレスを割当てるとしてもよい。所定の階層より先のＩＡＢノードに同じＢＡＰアドレスを割当てるとしてもよい。このことにより、例えば、ＩＡＢ基地局を用いたマルチキャスト通信における無線リソースを削減可能となる。該階層は、ＩＡＢドナーＣＵを基準とした階層であってもよい。他の例として、該階層は、ＵＥを基準とした階層であってもよい。
　前述（カ）の方法として、ＩＡＢドナーＣＵからＵＥまでの経路となるＩＡＢノードに同じＢＡＰアドレスを割当てるとしてもよい。
　図２９は、ＩＡＢドナーＣＵからＵＥまでの経路となるＩＡＢノードに同じＢＡＰアドレスを割当てる例について示した図である。図２９は、ＵＥ＃５までの経路となるＩＡＢノード＃１、＃３、＃５に対してマルチキャスト用ＢＡＰアドレスが割り当てられる例を示す。図２９において、ＵＥ＃１～＃６はマルチキャストを受信するＵＥ、ハッチングありのＩＡＢノード＃２、＃４はマルチキャスト用ＢＡＰアドレスが割り当てられないＩＡＢノード、ハッチング無しのＩＡＢノード＃１、＃３、＃５はマルチキャスト用ＢＡＰアドレスが割り当てられるＩＡＢノードを示す。ＩＡＢノード＃１、＃３、＃５にはマルチキャスト用ＢＡＰアドレスとして同じＢＡＰアドレスが割り当てられる。
　前述（キ）の例として、（ア）と（イ）の組合せが用いられてもよい。例えば、宛先ＢＡＰアドレスに、前述（ア）の、末端ＩＡＢノードに割当てるマルチキャスト用ＢＡＰアドレスを、次ホップＢＡＰアドレスに、前述（イ）の、子ＩＡＢノードに割当てるマルチキャスト用ＢＡＰアドレスを、それぞれ用いてもよい。このことにより、例えば、ＩＡＢノードにおけるマルチキャスト送信の複雑性を回避可能となる。
　図３０は、末端ＩＡＢノード、および、同じ親ＩＡＢノードに接続する子ＩＡＢノードに対してマルチキャスト用ＢＡＰアドレスが割り当てられる例を示す図である。図３０において、ＵＥ＃１～＃７はマルチキャストを受信するＵＥを示す。図３０において、横線が入ったＩＡＢノード＃４～＃７は、末端ＩＡＢノード用のＢＡＰアドレスが割り当てられる。右上がり線が入ったＩＡＢノード＃１、＃２、右下がり線が入ったＩＡＢノード＃３、＃４、および、縦線が入ったＩＡＢノード＃５、＃６は、同じ親ＩＡＢノードに接続する子ＩＡＢノードに対して割り当てられるＢＡＰアドレスが割り当てられる。図３０において、ＩＡＢノード＃４～＃６には、前述の両方のＢＡＰアドレスが割り当てられる。詳細には、ＩＡＢノード＃４には、末端ＩＡＢノード用のＢＡＰアドレスと、ＩＡＢノード＃１を親ＩＡＢノードとする子ＩＡＢノードに対して割り当てられるＢＡＰアドレスとが割り当てられる。ＩＡＢノード＃５および＃６には、末端ＩＡＢノード用のＢＡＰアドレスと、ＩＡＢノード＃２を親ＩＡＢノードとする子ＩＡＢノードに対して割り当てられるＢＡＰアドレスが割り当てられる。
　ＩＡＢノードは、親ＩＡＢノードから受信したＢＡＰ－ＰＤＵを子ＩＡＢノードに送信してもよい。該動作は、例えば、該ＩＡＢノードに子ＩＡＢノードが接続される場合において行うとしてもよい。このことにより、例えば、宛先ＢＡＰアドレスに自ＩＡＢノードが含まれる場合においても、子ＩＡＢノードへのマルチキャスト送信が可能となる。
　ＩＡＢノードは、親ＩＡＢノードから受信したＢＡＰ－ＰＤＵを上位レイヤに転送してもよい。ＩＡＢノードは、ＢＡＰ－ＰＤＵからＢＡＰヘッダを取り除いてもよい。該動作は、例えば、該ＩＡＢノードが末端ＩＡＢノードである場合に行われるとしてもよい。このことにより、例えば、ＵＥへのマルチキャストが可能となる。
　ＩＡＢノードは、前述の両方の動作を行ってもよい。前述の両方の動作は、例えば、該ＩＡＢノードが末端ＩＡＢノードであり、すなわち、ＵＥに接続し、かつ、子ＩＡＢノードにも接続する場合に行われてもよい。ＩＡＢノードは、実施の形態２に開示するＢＡＰ－ＰＤＵの複製を行ってもよい。このことにより、例えば、ＩＡＢノードから子ＩＡＢノードおよびＵＥへのマルチキャスト送信が可能となる。
　ＩＡＢ基地局からのマルチキャスト送信において、ＰＴＭレッグとＰＴＰレッグの間の切替えが行われてもよい。該切替えを、ＩＡＢドナーＣＵが判断してもよいし、ＵＥと直接接続するＩＡＢノードが判断してもよい。ＩＡＢドナーＣＵおよび／あるいは該ＩＡＢノードは、ＰＤＣＰ　ＳＮ（Sequence　Number）に関する情報、例えば、ＵＥに対して送達確認の取れたＰＤＣＰ　ＳＮに関する情報を用いて、該判断を行ってもよい。該ＩＡＢノードは、該判断の結果をＩＡＢドナーＣＵに通知してもよい。ＩＡＢドナーＣＵは、自ＣＵおよび／あるいは該ＩＡＢノードによる判断の結果を用いて、マルチキャストにおいて用いるレッグを決定してもよい。
　該切替に関する他の例として、該切替えを、ＩＡＢドナーＤＵが判断してもよいし、ＵＥまでの経路の途中にあるＩＡＢノードが判断してもよい。ＩＡＢドナーＤＵおよび／あるいは該ＩＡＢノードは、ＲＬＣ　ＳＮに関する情報、例えば、ＵＥに対して送達確認の取れたＲＬＣ　ＳＮに関する情報を用いて、該判断を行ってもよい。ＩＡＢドナーＤＵおよび／あるいは該ＩＡＢノードは、該判断の結果をＩＡＢドナーＣＵに通知してもよい。ＩＡＢドナーＣＵは、自ＣＵおよび／あるいは該ＩＡＢノードによる判断の結果を用いて、マルチキャストにおいて用いるレッグを決定してもよい。
　該切替に関する他の例として、該切替えをＵＥが判断してもよい。例えば、ＵＥは、マルチキャストの受信状況（例、ＰＤＣＰ　ＳＮ、ＲＬＣ　ＳＮ）を用いて、該判断を行ってもよい。ＵＥは基地局に対し、該切替えの要求を通知してもよいし、マルチキャストの受信状況に関する情報を通知してもよい。ＵＥは基地局に対して自律的に該通知を送信可能としてもよい。該通知には、ＰＤＣＰステータスレポート（非特許文献３９（ＴＳ３８．３２３）参照）が用いられてもよい。ＩＡＢドナーＣＵは、ＵＥから受信した該情報を用いて、ＰＴＭ／ＰＴＰの切替えを行ってもよい。
　他の例として、ＵＥは該通知にＰＲＡＣＨを用いてもよいし、ＲＲＣシグナリングを用いてもよい。ＵＥと直接通信するＩＡＢドナーＤＵおよび／あるいはＩＡＢノードは、ＩＡＢドナーＣＵに対し、ＵＥからの該通知を転送してもよい。ＩＡＢドナーＤＵおよび／あるいはＩＡＢノードは、Ｆ１シグナリングを用いて、該転送を行ってもよい。このことにより、例えば、ＩＡＢドナーＤＵおよび／あるいはＩＡＢノードは、ＵＥからのＰＴＭ／ＰＴＰ切替え要求をＩＡＢドナーＣＵに通知可能となる。ＩＡＢドナーＣＵは、ＩＡＢドナーＤＵおよび／あるいはＩＡＢノードから転送された該通知を用いて、ＰＴＭ／ＰＴＰの切替えを行ってもよい。
　前述のＦ１シグナリングには、例えば、ＵＬ　ＲＲＣ　ＭＥＳＳＡＧＥ　ＴＲＡＮＳＦＥＲ（非特許文献３５（ＴＳ３８．４７３）参照）のシグナリングが用いられてもよいし、新たなシグナリングが用いられてもよい。新たなシグナリングには、例えば、ＵＥからＰＴＭ／ＰＴＰ切替え要求があったことを示す情報が含まれてもよいし、切替え前のレッグに関する情報が含まれてもよいし、切替え後のレッグに関する情報が含まれてもよいし、レッグに関するＵＥにおけるマルチキャストの受信状況に関する情報が含まれてもよいし、前述のうち複数の情報が含まれてもよい。マルチキャストの受信状況に関する情報の例として、ＰＤＣＰレイヤにおいて用いられるタイマー（例、非特許文献３９に記載のt-reordering）の満了に関する情報が用いられてもよいし、マルチキャストに係るＰＤＣＰ　ＳＤＵ（Service　Data　Unit）および／あるいはＰＤＣＰ　ＰＤＵの欠落数が所定の値以上となったことを示す情報が用いられてもよいし、ＲＬＣレイヤにおいて用いられるタイマー（例、非特許文献４０に記載のt-reassembly）の満了に関する情報が用いられてもよいし、マルチキャストに係るＲＬＣ　ＳＤＵ（Service　Data　Unit）および／あるいはＲＬＣ　ＰＤＵの欠落数が所定の値以上となったことを示す情報が用いられてもよい。前述の所定の情報は、あらかじめ規格で決められてもよいし、ＩＡＢドナーＣＵが決定してＵＥに通知あるいは報知してもよい。前述における、ＰＤＣＰレイヤにおいて用いられるタイマーとして、新たなタイマーが設けられてもよい。前述における、ＲＬＣレイヤにおいて用いられるタイマーとして、新たなタイマーが設けられてもよい。前述の情報は、例えば、該Ｆ１シグナリングにおいて、理由、として含まれてもよい。例えば、マルチキャストの受信状況に関する情報が、ＵＥからのＰＴＭ／ＰＴＰレッグ切替え要求の理由として含まれてもよい。このことにより、例えば、ＩＡＢドナーＣＵは、ＵＥの詳細な状況を取得可能となる。
　前述のＲＲＣシグナリングにおいても、前述のＦ１シグナリングと同様の情報が含まれてもよい。このことにより、例えば、前述と同様の効果が得られる。
　ＩＡＢドナーＣＵは、レッグのアクティベーション／デアクティベーションに関する情報をＩＡＢドナーＤＵおよび／あるいはＩＡＢノードに通知してもよい。該通知には、Ｆ１シグナリング、例えば、非特許文献３５（ＴＳ３８．４７３）に開示されたＵＥ　ＣＯＮＴＥＸＴ　ＳＥＴＵＰ　ＲＥＱＵＥＳＴが用いられてもよいし、ＵＥ　ＣＯＮＴＥＸＴ　ＭＯＤＩＦＩＣＡＴＩＯＮ　ＲＥＱＵＥＳＴが用いられてもよい。ＩＡＢドナーＤＵおよび／あるいはＩＡＢノードは、子ＩＡＢノードおよび／あるいはＵＥに対して、レッグのアクティベーション／デアクティベーションに関する情報を通知してもよい。該通知は、例えば、ＭＡＣシグナリングを用いて行われてもよい。このことにより、例えば、子ＩＡＢノードおよび／あるいはＵＥに対する該情報を迅速に通知可能となる。
　他の解決策として、ＩＡＢノード間におけるマルチキャスト送信が行われないとしてもよい。例えば、ＩＡＢノード間におけるＰＴＭ送信が行われないとしてもよい。このことにより、例えば、通信システムの複雑性を回避可能となる。
　本実施の形態１において開示した解決策の組合せが用いられてもよい。例えば、複数の宛先ＢＡＰアドレスを有するＢＡＰヘッダにおいて、マルチキャスト用ＢＡＰアドレスが含まれてもよいし、ＩＡＢドナーＣＵから設定される複数の宛先ＢＡＰアドレスに、マルチキャスト用ＢＡＰアドレスが含まれてもよい。このことにより、例えば、マルチキャスト送信における柔軟性を向上可能となる。
　本実施の形態１により、ＩＡＢノード間のマルチキャストにおけるＢＡＰアドレスの設定が可能となり、その結果、ＩＡＢ基地局を用いたマルチキャストが可能となる。
実施の形態２．
　ＩＡＢ基地局を用いたマルチキャストにおいて、データの複製が行われてもよい。例えば、ＰＴＰを用いたマルチキャスト、ＵＥおよび子ＩＡＢノードに対してマルチキャストデータを送信する場合において、データの複製が行われてもよい。
　ところが、データの複製を行う主体について上述の各非特許文献等では開示されていない。その結果、ＩＡＢ基地局を用いたマルチキャストにおいて、装置間の齟齬が発生し、通信システムにおける誤動作が発生する恐れがある。
　本実施の形態２では、このような課題を解決する方法を開示する。
　前述の問題を解決するため、本実施の形態にかかる通信システムにおいては、ＩＡＢドナーＣＵがマルチキャストデータを複製する。該複製がＰＤＣＰレイヤにおいて行われてもよい。ＩＡＢドナーＣＵは、ＰＤＣＰレイヤにおいて複製したデータを各ＵＥに対して送信してもよい。該送信には、ＩＡＢドナーＤＵおよび／あるいはＩＡＢノードが用いられてもよい。
　他の解決策を開示する。ＩＡＢドナーＤＵおよび／あるいはＩＡＢノードがマルチキャストデータを複製してもよい。ＩＡＢドナーＤＵおよび／あるいはＩＡＢノードは、ＢＡＰレイヤにおいて該複製を行ってもよい。
　ＢＡＰレイヤにおける該複製が、送信側のＢＡＰレイヤにおいて行われてもよい。例えば、ＰＴＰを用いたマルチキャストにおいて、送信側のＢＡＰレイヤによるマルチキャストデータの複製が行われてもよい。このことにより、例えば、ＩＡＢノードにおけるメモリバッファ使用量を削減可能となる。
　図３１は、ＢＡＰレイヤにおける複製の動作の例を示した図である。図３１は、複数の子ＩＡＢノードが接続しているＩＡＢノードにおけるＢＡＰレイヤ動作の一例である。図３１に示すＢＡＰレイヤは、受信側ＢＡＰレイヤおよび送信側ＢＡＰレイヤによって構成される。図３１において、ＢＡＰレイヤにおける複製が送信側ＢＡＰレイヤにおいて行われる例を示す。
　図３１において、受信したＢＡＰ－ＰＤＵ３１１０は、入力側ＢＨ　ＲＬＣチャネルより受信側ＢＡＰレイヤに入力される。受信側ＢＡＰに含まれる機能部３１１５において、上位レイヤに転送されるか送信側ＢＡＰレイヤに転送されるかが判断される。図３１に示す例において、ＢＡＰ－ＰＤＵ３１１０は送信側ＢＡＰレイヤに転送される。
　図３１において、送信側ＢＡＰレイヤに入力されたＢＡＰ－ＰＤＵ３１１０は、ルーティング機能部３１２５に入力される。ルーティング機能部３１２５において、送信先の子ＩＡＢノードが決定されるとともに、ＢＡＰ－ＰＤＵ３１１０の複製が行われ、複数のＢＡＰ－ＰＤＵ３１３０が生成される。生成されたＢＡＰ－ＰＤＵ３１３０は、出力側ＢＨ　ＲＬＣチャネルにマッピングされる。生成されたＢＡＰ－ＰＤＵ３１３０のそれぞれは、それぞれ異なるＩＡＢノードに送信されてもよい。
　ＢＡＰレイヤにおける該複製が、受信側のＢＡＰレイヤにおいて行われてもよい。例えば、子ＩＡＢノードが接続している末端ＩＡＢノードにおいて、受信側のＢＡＰレイヤによるマルチキャストデータの複製が行われてもよい。このことにより、例えば、子ＩＡＢノードが接続している末端ＩＡＢノードにおけるマルチキャストデータ送信処理の複雑性を回避可能となる。他の例として、末端ＩＡＢノードからＵＥへのＰＴＰ送信において、受信側のＢＡＰレイヤによるマルチキャストデータの複製が行われてもよい。このことにより、例えば、通信システムの設計の複雑性を回避可能となる。
　図３２は、ＢＡＰレイヤにおける複製の動作の他の例を示した図である。図３２は、子ＩＡＢノードが接続している末端ＩＡＢノードにおけるＢＡＰレイヤ動作の一例である。図３２に示すＢＡＰレイヤは、受信側ＢＡＰレイヤおよび送信側ＢＡＰレイヤによって構成される。図３２において、ＢＡＰレイヤにおける複製が受信側ＢＡＰレイヤにおいて行われる例を示す。
　図３２において、受信したＢＡＰ－ＰＤＵ３１１０は、入力側ＢＨ　ＲＬＣチャネルより受信側ＢＡＰレイヤに入力される。受信側ＢＡＰに含まれる機能部３２１５において、上位レイヤに転送されるか送信側ＢＡＰレイヤに転送されるかが判断される。必要であれば、ＢＡＰレイヤにおいてＢＡＰ－ＰＤＵ３１１０の複製が行われる。図３２に示す例において、ＢＡＰ－ＰＤＵ３１１０は、送信側ＢＡＰレイヤに転送されるＢＡＰ－ＰＤＵ３２２０と上位レイヤに転送されるＢＡＰ－ＰＤＵ３２２１に複製される。
　図３２において、送信側ＢＡＰレイヤに入力されたＢＡＰ－ＰＤＵ３２２０は、ルーティングを経て、出力側ＢＨ　ＲＬＣチャネルにマッピングされる。
　図３３は、ＢＡＰレイヤにおける複製の動作の他の例を示した図である。図３３は、複数の子ＩＡＢノードが接続している末端ＩＡＢノードにおけるＢＡＰレイヤ動作の一例である。図３３に示すＢＡＰレイヤは、受信側ＢＡＰレイヤおよび送信側ＢＡＰレイヤによって構成される。図３３において、ＢＡＰレイヤにおける複製が受信側ＢＡＰレイヤにおいて行われる例を示す。
　図３３において、受信したＢＡＰ－ＰＤＵ３１１０は、入力側ＢＨ　ＲＬＣチャネルより受信側ＢＡＰレイヤに入力される。受信側ＢＡＰに含まれる機能部３２１５において、上位レイヤに転送されるか送信側ＢＡＰレイヤに転送されるかが判断される。必要であれば、ＢＡＰレイヤにおいてＢＡＰ－ＰＤＵ３１１０の複製が行われる。図３３に示す例において、ＢＡＰ－ＰＤＵ３１１０の複製が行われ、送信側ＢＡＰレイヤに転送される複数のＢＡＰ－ＰＤＵ３３２０と上位レイヤに転送されるＢＡＰ－ＰＤＵ３２２１が生成される。機能部３２１５は、送信側ＢＡＰレイヤのルーティング機能部が有するルーティング情報を用いて、該複製を行ってもよいし、送信側ＢＡＰレイヤのルーティング機能部が有するルーティング情報と同様のルーティング情報を有してもよい。
　図３３において、送信側ＢＡＰレイヤに入力された複数のＢＡＰ－ＰＤＵ３３２０は、ルーティングを経て、出力側ＢＨ　ＲＬＣチャネルにマッピングされる。
　ＢＡＰレイヤにおける該複製が、送信側と受信側の両方のＢＡＰレイヤにおいて行われてもよい。例えば、複数の子ＩＡＢノードが接続している末端ＩＡＢノードにおいて、送信側と受信側の両方のＢＡＰレイヤにおいて行われてもよい。例えば、受信側のＢＡＰレイヤにおける複製により、子ＩＡＢノード向けのＢＡＰ－ＰＤＵとＵＥ向けのＢＡＰ－ＰＤＵが生成されるとしてもよいし、送信側のＢＡＰレイヤにおける複製により、複数の子ＩＡＢノード向けのＢＡＰ－ＰＤＵの複製が行われるとしてもよい。このことにより、例えば、ＩＡＢノードにおけるメモリバッファ使用量を削減可能となる。
　図３４は、ＢＡＰレイヤにおける複製の動作の例を示した図である。図３４は、複数の子ＩＡＢノードが接続している末端ＩＡＢノードにおけるＢＡＰレイヤ動作の一例である。図３４に示すＢＡＰレイヤは、受信側ＢＡＰレイヤおよび送信側ＢＡＰレイヤによって構成される。図３４において、ＢＡＰレイヤにおける複製が送信側ＢＡＰレイヤおよび受信側ＢＡＰレイヤにおいて行われる例を示す。
　図３４において、受信したＢＡＰ－ＰＤＵ３１１０は、入力側ＢＨ　ＲＬＣチャネルより受信側ＢＡＰレイヤに入力される。受信側ＢＡＰに含まれる機能部３２１５において、上位レイヤに転送されるか送信側ＢＡＰレイヤに転送されるかが判断される。必要であれば、ＢＡＰレイヤにおいてＢＡＰ－ＰＤＵ３１１０の複製が行われる。図３４に示す例において、ＢＡＰ－ＰＤＵ３１１０は、送信側ＢＡＰレイヤに転送されるＢＡＰ－ＰＤＵ３２２０と上位レイヤに転送されるＢＡＰ－ＰＤＵ３２２１に複製される。
　図３４において、送信側ＢＡＰレイヤに入力されたＢＡＰ－ＰＤＵ３２２０は、ルーティング機能部３１２５に入力される。ルーティング機能部３１２５において、送信先の子ＩＡＢノードが決定されるとともに、ＢＡＰ－ＰＤＵ３２２０の複製が行われ、複数のＢＡＰ－ＰＤＵ３１３０が生成される。生成されたＢＡＰ－ＰＤＵ３１３０は、出力側ＢＨ　ＲＬＣチャネルにマッピングされる。
　ＢＡＰレイヤにおける該複製が、送信側と受信側の両方のＢＡＰレイヤにおいて行われる方法の他の例として、複数の子ＩＡＢノードと複数のＵＥが接続している末端ＩＡＢノードとにおいて、送信側と受信側の両方のＢＡＰレイヤにおいて行われてもよい。例えば、受信側のＢＡＰレイヤにおける複製により、子ＩＡＢノード向けのＢＡＰ－ＰＤＵと複数のＵＥ向けの複数のＢＡＰ－ＰＤＵとが生成されるとしてもよいし、送信側のＢＡＰレイヤにおける複製により、複数の子ＩＡＢノード向けのＢＡＰ－ＰＤＵの複製が行われるとしてもよい。このことにより、例えば、通信システムにおける複雑性を回避可能となる。
　ＩＡＢドナーＤＵおよび／あるいはＩＡＢノードにおけるマルチキャストデータの複製が、上位レイヤにおいて行われてもよい。例えば、ＩＰレイヤにおいて行われてもよい。このことにより、例えば、ＩＡＢノードにおけるメモリバッファ使用量を削減可能となる。他の例として、ＵＤＰレイヤにおいて行われてもよい。このことにより、例えば、ＩＡＢノードにおけるメモリバッファ使用量をさらに削減可能となる。他の例として、ＧＴＰ－ｕレイヤにおいて行われてもよい。このことにより、例えば、ＩＡＢノードにおけるメモリバッファ使用量をさらに削減可能となる。
　他の例として、マルチキャストデータの複製が、ＩＡＢノードの受信側のＧＴＰ－ｕレイヤから、該ＩＡＢノードの送信側のＲＬＣレイヤに転送されるときに行われてもよい。このことにより、例えば、ＩＡＢノードにおけるメモリバッファ使用量をさらに削減可能となる。
　図３５は、末端ＩＡＢノードの受信側と送信側の間でマルチキャストデータの複製が行われる動作の例を、ＩＡＢドナーＣＵからＩＡＢドナーＤＵ、中間ＩＡＢノード、末端ＩＡＢノードを経てＵＥに至るまでのプロトコルスタックにおいて示す図である。図３５に示す例において、マルチキャストデータが、末端ＩＡＢノードの受信側のＧＴＰ－ｕ処理後に複製され、送信側のＲＬＣレイヤに入力される。
　マルチキャストデータの複製を行う新たなレイヤが設けられてもよい。該レイヤが、例えば、末端ＩＡＢノードのＧＴＰ－ｕレイヤの上位に設けられてもよいし、末端ＩＡＢノードの途中のＩＡＢノードのＢＡＰレイヤの上位に設けられてもよいし、ＩＡＢドナーＤＵのＩＰレイヤの上位に設けられてもよい。ＩＡＢドナーＤＵおよび／あるいはＩＡＢノードにおけるマルチキャストデータの複製が該レイヤにおいて行われてもよい。このことにより、例えば、通信システムにおける複雑性を回避可能となる。
　本実施の形態２により、ＩＡＢ基地局を用いたマルチキャストにおける装置間の齟齬を防止可能となり、その結果、通信システムにおける誤動作を防止可能となる。
実施の形態３．
　ＩＡＢ基地局を用いたマルチキャストにおいて、複数のデータの経路が途中で合流してもよい。経路の合流は、末端ＩＡＢノードにおいて行われてもよいし、末端ＩＡＢノードでないＩＡＢノードにおいて行われてもよい。
　図３６は、データの複数の経路が途中で合流する例について示した図である。図３６において、末端ＩＡＢノードでないＩＡＢノード＃４において、ＩＡＢノード＃２からの経路とＩＡＢノード＃３からの経路が合流する。
　ところが、末端ＩＡＢノードでないＩＡＢノード＃４は、ＰＤＣＰヘッダを参照することができない。そのため、経路の合流が行われるノードが末端ＩＡＢノードでないＩＡＢノードである場合において、該ＩＡＢノードはマルチキャストデータの同一性を判断できない。そのため、マルチキャストにおける効率性向上として、パケット複製（非特許文献３９（ＴＳ３８．３２３）参照）の方法を適用することができない。このことにより、無線リソースを圧迫するという問題が生じる。
　本実施の形態３では、このような課題を解決する方法を開示する。
　前述の問題を解決するため、本実施の形態にかかる通信システムにおいては、１つの経路から到着したマルチキャストデータのみが子ＩＡＢノードに送信される。ＩＡＢノードは、他の経路から到着したマルチキャストデータを破棄してもよい。
　該破棄は、該１つの経路からのマルチキャストデータが到着した場合に行われるとしてもよい。該ＩＡＢノードは、該１つの経路からのマルチキャストデータが到着するまで、他の経路から到着したマルチキャストデータを保持してもよい。該ＩＡＢノードは、例えば、該１つの経路からのマルチキャストデータが所定の時間到着しない場合において、他の経路から到着したマルチキャストデータを子ＩＡＢノードに送信してもよい。このことにより、例えば、マルチキャスト送信における信頼性を向上可能となる。
　ＩＡＢドナーＣＵは該ＩＡＢノードに対し、ＰＤＣＰ設定に関する情報を通知してもよい。該情報は、例えば、ベアラ識別子を含んでもよいし、ＲＬＣチャネルに関する情報を含んでもよい。該情報の通知には、ＲＲＣシグナリング、例えば、ＲＲＣ再設定（ＲＲＣＲｅｃｏｎｆｉｇｕｒａｔｉｏｎ）が用いられてもよい。該通知は、該ＩＡＢノードの各経路に関する親ＩＡＢノードを経由して行われてもよい。該ＩＡＢノードは、該情報を用いて、マルチキャストデータのＰＤＣＰ設定に関する情報を取得してもよい。このことにより、例えば、ＩＡＢノードは複数の経路から受信したデータが同じマルチキャストコンテンツのデータであることを認識可能となる。
　前ホップＢＡＰアドレス（Ｐｒｉｏｒ－Ｈｏｐ　ＢＡＰ　Ａｄｄｒｅｓｓ：非特許文献３５（ＴＳ３８．４７３）参照）が複数設けられてもよい。入力側バックホールＲＬＣチャネル識別子（Ｉｎｇｒｅｓｓ　Ｂａｃｋｈａｕｌ　ＲＬＣ　Ｃｈａｎｎｅｌ　ＩＤ：非特許文献３５（ＴＳ３８．４７３）参照）が複数設けられてもよい。１つの前ホップＢＡＰアドレスと、１つまたは複数の入力側バックホールＲＬＣチャネル識別子の組合せが複数設けられてもよい。複数の前ホップＢＡＰアドレスおよび／あるいは複数の入力側バックホールＲＬＣチャネル識別子は、１つのマッピング情報に対して設けられてもよい。このことにより、例えば、ＩＡＢノードは複数の経路から受信したマルチキャストデータが同じマルチキャストコンテンツのデータであることを迅速に認識可能となる。
　ＩＡＢノードにおいてどの経路から受信されるマルチキャストデータを子ＩＡＢノードに送信するかを、ＩＡＢドナーＣＵが決定してもよい。ＩＡＢドナーＣＵは該ＩＡＢノードに対し、どの経路から送信されるマルチキャストデータを子ＩＡＢノードに送信するかの情報を通知してもよい。該通知は、ＲＲＣシグナリングを用いて行われてもよいし、ＭＡＣシグナリングを用いて行われてもよいし、Ｌ１／Ｌ２シグナリングを用いて行われてもよい。
　他の例として、ＩＡＢノードにおいてどの経路から受信されるマルチキャストデータを子ＩＡＢノードに送信するかを、該ＩＡＢノードが決定してもよいし、ＵＥが決定してもよい。該ＩＡＢノードおよび／あるいはＵＥはＩＡＢドナーＣＵに対し、どの経路のマルチキャストデータを子ＩＡＢノードに送信するかを通知してもよい。このことにより、例えば、ＩＡＢノードおよび／あるいはＵＥまでの受信環境を基にマルチキャストデータの経路を決定可能となり、その結果、通信品質を向上可能となる。
　前述の、複数の前ホップＢＡＰアドレスおよび／あるいは複数の入力側バックホールＲＬＣチャネル識別子のうち、有効となる前ホップＢＡＰアドレスおよび／あるいは入力側バックホールＲＬＣチャネル識別子が設定されてもよい。該設定は、ＩＡＢドナーＣＵが行ってもよいし、該ＩＡＢノード自身が行ってもよいし、ＵＥが行ってもよい。該設定をＩＡＢドナーＣＵが行う場合において、前述の通知が用いられてもよい。ＩＡＢノードは、有効となる前ホップＢＡＰアドレスおよび／あるいは入力側バックホールＲＬＣチャネル識別子からのマルチキャストデータを子ＩＡＢノードに送信するとしてもよい。このことにより、例えば、マルチキャストの経路選択における複雑性を回避可能となる。
　２つ以上の経路から到着したマルチキャストデータが子ＩＡＢノードに送信されるとしてもよい。どの経路から到着したマルチキャストデータが子ＩＡＢノードに送信されるかについては、前述の方法が用いられてもよい。このことにより、例えば、無線リソースの使用量を削減しつつ、マルチキャスト送信の冗長性を確保可能となる。
　子ＩＡＢノードに送信される、１つあるいは複数の経路から到着したマルチキャストデータは、ＩＡＢノードに先に到着した経路のデータであってもよい。このことにより、例えば、マルチキャストの迅速な通信が可能となる。
　他の解決策として、複数の経路からのマルチキャストデータがそのまま子ＩＡＢノードに送信されるとしてもよい。このことにより、例えば、マルチキャストにおける冗長性を確保可能となり、その結果、通信システムにおける信頼性を向上可能となる。
　他の解決策として、マルチキャストの送信経路の合流が行われないとしてもよい。例えば、末端ＩＡＢノード以外のＩＡＢノードにおいて合流が行われないとしてもよいし、末端ＩＡＢノードにおいて合流が行われないとしてもよいし、前述の両方において合流が行われないとしてもよい。このことにより、例えば、通信システムの複雑性を回避可能となる。
　本実施の形態３により、マルチキャストデータ送信における無線リソースを効率的に利用可能となる。
実施の形態４．
　３ＧＰＰでは、ＳＬ通信を用いた多種のサービスを、ＥＰＳにおいても、５Ｇコアシステムにおいてもサポートすることが検討されている（非特許文献１、１６、２０、２１、２２、２３参照）。ＳＬ通信では端末間で通信が行われる。また、ＳＬ通信においては、端末間の直接通信だけでなく、リレー（relay）を介したＵＥとＮＷとの間の通信が提案されている（非特許文献２０(３ＧＰＰ　ＴＲ２３．７０３)、非特許文献２３(３ＧＰＰ　ＴＳ２３．３０３)、非特許文献２７（３ＧＰＰ　ＴＲ３８．８３６）参照）。ＵＥとＮＷとの間のリレーを、ＵＥ－ｔｏ－ＮＷリレー、あるいは、ＵＥ－ＮＷ間リレーと称する場合がある。本開示では、ＵＥとＮＷとの間のリレーを実施するＵＥを、リレーＵＥと称する場合がある。
　たとえば、ＲＡＮ（Radio　Access　Network）ノード（たとえばｇＮＢ）のカバレッジ内のＵＥだけでなく、より遠方のＵＥとＲＡＮノードとの間で通信を行う必要性が生じる場合がある。このような場合、ＵＥ－ＮＷ間リレーを用いる方法が考えられる。たとえば、ｇＮＢとＵＥ（リモートＵＥと称する場合がある）との間の通信を、リレーＵＥを介して行う。ｇＮＢとリレーＵＥとの間の通信をＵｕで行い、リレーＵＥとリモートＵＥとの間の通信をＰＣ５で行う。本明細書では、少なくとも一つのリレーＵＥを介してＮＷと接続するＵＥをリモートＵＥと称する。
　このようなリレーを介した通信をサポートする通信システムにおいて、ＵＥとＮＷ間の通信品質を如何に向上させるかが問題となる。従来、通信品質を向上させるため、ＵＥが２つの基地局と接続して通信を行うデュアルコネクティビティ（DC：Dual　Connectivity）という方法がある（非特許文献１２（ＴＳ３７．３４０）参照）。しかし、従来のＤＣの方法は、ＵＥが基地局と直接接続する場合のみしか開示されていない。リレーＵＥを介したリモートＵＥとＮＷ間の通信では、リモートＵＥとＮＷ間の直接通信とは異なり、ＵｕだけでなくＰＣ５上での通信が必要となる。このため、従来のリモートＵＥとＮＷ間の直接通信での方法を単に用いただけでは、リレーＵＥを介したリモートＵＥとＮＷ間の通信には適用できない、という問題がある。また、リレーＵＥを介したリモートＵＥとＮＷ間の通信におけるデュアルコネクティビティの方法は、これまで策定済みの規格等において、なんら開示されていない。
　本実施の形態４では、このような課題を解決する方法を開示する。
　前述の課題を解決するため、本実施の形態では、リレーＵＥを介して行うリモートＵＥとＮＷ間の通信において、リレーＵＥが複数の基地局と接続する。該複数はたとえば２つであってもよい。リレーＵＥを介して行うリモートＵＥとＮＷ間の通信において、リレーＵＥが２つの基地局と接続する。本明細書では、リレーＵＥを介して行うリモートＵＥとＮＷ間の通信において、リレーＵＥあるいはリモートＵＥが、２つの基地局と接続する方法を、単にＤＣと称する場合がある。該２つの基地局を、以降、ＭＮ（Master　Node）、ＳＮ（Secondary　Node）と称する場合がある。ＭＮは、ＣＮ（Core　Network）とのＣ－Ｐｌａｎｅ（Control　Plane）接続を有す。ＭＮはＭＣＧ（Master　Cell　Group）であってもよい。たとえば、ＭＮが構成するセルグループであってもよい。ＳＮはＳＣＧ（Secondary　Cell　Group）であってもよい。たとえば、ＳＮが構成するセルグループであってもよい。
　リモートＵＥとＮＷ間の通信のための無線ベアラ（RB：Radio　Bearer）に対して、リレーＵＥは複数のｇＮＢと接続する。該無線ベアラは、たとえば、ＳＲＢ（Signaling　Radio　Bearer）であってもよい。たとえば、該ＳＲＢは複数のＳＲＢ０～ＳＲＢ２の中のＳＲＢ２であってもよい。ＳＲＢ０、ＳＲＢ１は一つのｇＮＢを用いて通信することで、通信の確立処理を簡易にすることが可能となる。該無線ベアラは、たとえば、ＤＲＢ（Data　Radio　Bearer）であってもよい。データ通信用のベアラの通信品質の向上が図れる。
　図３７は、実施の形態４について、リレーＵＥを介したリモートＵＥとＮＷ間の通信において、リレーＵＥが２つのｇＮＢと接続する場合の概念図である。図３７に示す例では、リレーＵＥとＭｇＮＢ（Master　gNB）間と、リレーＵＥとＳｇＮＢ（Secondary　gNB）間とはＵｕインタフェースで接続され、リレーＵＥとリモートＵＥ間はＰＣ５で接続される。なお、ＭｇＮＢは上述のＭＮに対応し、ＳｇＮＢは上述のＳＮに対応する。リモートＵＥは、リレーＵＥを介して、ＭｇＮＢ　ａｎｄ／ｏｒ　ＳｇＮＢと接続される。リモートＵＥとＮＷ間の通信において、リレーＵＥとＭｇＮＢ間　ａｎｄ／ｏｒ　ＳｇＮＢ間で通信が行われ、リレーＵＥとリモートＵＥ間で通信が行われる。
　リレーＵＥを介したリモートＵＥとＮＷ間の通信において、リレーＵＥが２つのｇＮＢと接続する場合のプロトコル構成を開示する。図３８は、実施の形態４について、リレーＵＥを介したリモートＵＥとＮＷ間の通信において、リレーＵＥが２つのｇＮＢと接続する場合のプロトコルスタックを示す図である。Ｕ－Ｐｌａｎｅ（User　Plane）について示している。
　ＭＮとＳＮはＵｕのプロトコルを有する。該Ｕｕのプロトコルは、ＳＤＡＰ、ＰＤＣＰ、ＲＬＣ、ＭＡＣ、ＰＨＹである。図３８では、ＤＣ用のベアラとして、ＭＮ終端ベアラおよびＳＮ終端ベアラの両方と、ＭＣＧベアラ、ＳＣＧベアラおよびスプリットベアラについて併せて示している。これらのベアラに対応したプロトコルが構成される。ＰＤＣＰは、ＭＮ終端ベアラ用に１つ、ＳＮ終端ベアラ用に１つ構成されてもよい。ＤＣの設定においてこれらのベアラの設定を可能としてもよい。
　リレーＵＥは、ＭＮ用とＳＮ用の２つのＵｕのプロトコルを有す。該Ｕｕのプロトコルは、ＳＤＡＰ、ＰＤＣＰ、ＲＬＣ、ＭＡＣ、ＰＨＹである。ＭＮ用のベアラは、ＭＣＧベアラあるいはスプリットベアラである。ＳＮ用のベアラは、ＳＣＧベアラあるいはスプリットベアラである。これらのベアラに対応したプロトコルが構成される。ＰＤＣＰは、ＭＮ終端ベアラ用に１つ、ＳＮ終端ベアラ用に１つ構成されてもよい。リレーＵＥでＭＮ　ａｎｄ／ｏｒ　ＳＮ間のＤＣが終端される。
　リレーＵＥとリモートＵＥは、ＰＣ５（ＳＬとも称する）のプロトコルを有する。該ＰＣ５のプロトコルは、ＰＣ５　ＳＤＡＰ（ＳＬ　ＳＤＡＰ）、ＰＣ５　ＰＤＣＰ（ＳＬ　ＰＤＣＰ）、ＰＣ５　ＲＬＣ（ＳＬ　ＲＬＣ）、ＰＣ５　ＭＡＣ（ＳＬ　ＭＡＣ）、ＰＣ５　ＰＨＹ（ＳＬ　ＰＨＹ）である。
　ＰＤＵレイヤは、ＵＰＦ、リレーＵＥ、リモートＵＥ間で構成される。
　ベアラについて開示する。ＭＮとリモートＵＥ間で、ＲＢが設定される。該ＲＢにおいて、ＭＮ　ａｎｄ／ｏｒ　ＳＮとリレーＵＥ間でＤＣ用ベアラが設定され、リレーＵＥとリモートＵＥ間で１つのＳＬベアラが設定される。なお、ＳＬベアラはＰＣ５ベアラと称される場合もある。ＤＣ用ベアラとして、ＰＤＣＰで終端されるものを、ＭＮの場合はＭＮ終端ベアラと称し、ＳＮの場合はＳＮ終端ベアラと称す。ＤＣ用ベアラとして、ＭＮのＲＬＣベアラを有するベアラをＭＣＧベアラと称し、ＳＮのＲＬＣベアラを有するベアラをＳＣＧベアラと称し、ＭＮとＳＮの両方のＲＬＣベアラを有するベアラをスプリットベアラと称する。ＭＮとリレーＵＥ間でＲＢが設定され、リレーＵＥとリモートＵＥ間でＳＬベアラが設定されてもよい。該ＭＮとリレーＵＥ間のＲＢにおいて、ＭＮ　ａｎｄ／ｏｒ　ＳＮとリレーＵＥ間でＤＣ用ベアラが設定されてもよい。
　ＮＷからリモートＵＥへのデータは、ＭＮ　ａｎｄ／ｏｒ　ＳＮでＵｕのベアラにマッピングされ、ＳＤＡＰ、ＰＤＣＰの処理が行われる。ＵｕのＳＤＡＰから出力されたデータは、ＭＣＧベアラあるいはＳＣＧベアラあるいはスプリットベアラにマッピングされ、ＰＤＣＰに入力される。ＰＤＣＰから出力されたデータは各ベアラに対応するＲＬＣベアラにマッピングされ、ＲＬＣ、ＭＡＣ、ＰＨＹのプロトコルを通してリレーＵＥに送信される。リレーＵＥで、ＭＮ　ａｎｄ/ｏｒ　ＳＮから受信したデータは、各ベアラに対応したＵｕのプロトコルを通してＰＤＵレイヤに転送される。リレーＵＥが、ＤＣ用ベアラとしてどのベアラで実施するか、たとえば、ＭＮ終端ベアラかＳＮ終端ベアラか、ＭＣＧベアラかＳＣＧベアラかスプリットベアラかが設定される。、ＰＤＵレイヤでデータはＳＬベアラにマッピングされ、ＰＣ５のプロトコルを通してリモートＵＥに送信される。リモートＵＥで、リレーＵＥから受信したデータは、ＰＣ５のプロトコルを通してＰＤＵレイヤに転送される。
　リモートＵＥからＮＷへのデータは、リモートＵＥでＰＣ５のプロトコルを通してリレーＵＥに送信される。リレーＵＥで、リモートＵＥから受信したデータは、ＰＣ５のプロトコルを通してＰＤＵレイヤに転送され、ＰＤＵレイヤでＵｕのベアラにマッピングされ、ＳＤＡＰ、ＰＤＣＰの処理が行われる。ＵｕのＳＤＡＰから出力されたデータは、ＭＣＧベアラあるいはＳＣＧベアラあるいはスプリットベアラにマッピングされ、ＰＤＣＰに入力される。ＵｕのＳＤＡＰから出力されたデータがＰＤＣＰに入力され、ＰＤＣＰで、ＭＣＧベアラあるいはＳＣＧベアラあるいはスプリットベアラにマッピングされてもよい。ＰＤＣＰから出力されたデータは各ベアラに対応するＲＬＣベアラにマッピングされ、ＲＬＣ、ＭＡＣ、ＰＨＹのプロトコルを通してＭＮ　ａｎｄ／ｏｒ　ＳＮに送信される。ＭＮ　ａｎｄ／ｏｒ　ＳＮで、リレーＵＥから受信したデータは、各ベアラに対応したＵｕのプロトコルを通してＰＤＵレイヤに転送される。
　Ｃ－Ｐｌａｎｅのプロトコルについては、ＭＮ、リレーＵＥ、リモートＵＥにおけるＳＤＡＰ、ＳＬ　ＳＤＡＰの代わりに、各々ＲＲＣ、ＳＬ　ＲＲＣを設ければよい。ＳＲＢに対応したＲＲＣ、ＳＬ　ＳＲＢに対応したＳＬ　ＲＲＣを設けるとよい。ＳＲＢにＤＣが設定される場合はＭＮ終端ベアラのみが設定されてもよい。ＳＲＢのＤＣが可能となる。
　このようにすることで、２つのｇＮＢと接続したリレーＵＥを介したリモートＵＥとＮＷ間の通信を可能とする。
　リレーＵＥを介したリモートＵＥとＮＷ間の通信において、リレーＵＥが２つのｇＮＢと接続する場合のプロトコル構成の他の方法を開示する。図３９は、実施の形態４について、リレーＵＥを介したリモートＵＥとＮＷ間の通信において、リレーＵＥが２つのｇＮＢと接続する場合のプロトコルスタックの他の構成方法を示す図である。Ｕ－Ｐｌａｎｅについて示している。図３８と異なる部分を主に説明する。
　ＭＮとＳＮは、図３８の例と同様、ＤＣ用のＵｕのプロトコルを有する。図３８の例で示した構成に加え、ＲＬＣとＰＤＣＰの間にアダプテーションプロトコル（ＡＤＰ）を構成する。ＡＤＰはＲＬＣのサブレイヤとして構成されてもよい。リレーＵＥは、ＭＮ用とＳＮ用の２つのＵｕのプロトコルを有す。該Ｕｕのプロトコルは、ＡＤＰ、ＲＬＣ、ＭＡＣ、ＰＨＹである。
　リレーＵＥは、リモートＵＥ間にＰＣ５のプロトコルを有す。ＰＣ５　ＲＬＣの上位にＰＣ５　ＡＤＰが構成されてもよい。ＰＣ５　ＡＤＰは、たとえばＵｕのベアラとＰＣ５のベアラ間のマッピング機能を有するとよい。ＰＣ５　ＡＤＰはＰＣ５　ＲＬＣのサブレイヤとして構成されてもよい。ＰＣ５　ＡＤＰは構成されなくてもよい。たとえばＵｕのベアラとＰＣ５のベアラ間のマッピングが１対１に限定されるような場合、ＰＣ５　ＡＤＰを有さなくてもよい。プロトコル構成を簡略化できる。該ＰＣ５のプロトコルは、ＰＣ５　ＡＤＰ（ＳＬ　ＡＤＰ）、ＰＣ５　ＲＬＣ、ＰＣ５　ＭＡＣ、ＰＣ５　ＰＨＹである。ＰＣ５　ＳＤＡＰ、ＰＣ５　ＰＤＣＰは無くてもよい。
　リモートＵＥはリレーＵＥ間にＰＣ５のプロトコルを有す。リレーＵＥと同様に、該ＰＣ５のプロトコルはＰＣ５　ＲＬＣ、ＰＣ５　ＭＡＣ、ＰＣ５　ＰＨＹである。ＰＣ５　ＲＬＣの上位にＰＣ５　ＡＤＰが構成されてもよい。ＰＣ５　ＳＤＡＰ、ＰＣ５　ＰＤＣＰは無くてもよい。また、リモートＵＥは、ＭＮ　ａｎｄ／ｏｒ　ＳＮ間にＵｕのプロトコルを有す。該Ｕｕのプロトコルは、ＳＤＡＰ、ＰＤＣＰである。リモートＵＥで、ＰＣ５のＡＤＰとＵｕのＰＤＣＰが接続される。ＰＣ５のＡＤＰが構成されない場合は、ＰＣ５のＲＬＣとＵｕのＰＤＣＰが接続される。
　ベアラについて開示する。ＭＮとリモートＵＥ間で、ＲＢが設定される。該ＲＢにおいて、ＭＮ　ａｎｄ／ｏｒ　ＳＮとリレーＵＥ間でＤＣ用ベアラが設定される。リレーＵＥでは、該ＤＣ用ベアラとしてＲＬＣベアラが設定されるとよい。ＲＬＣチャネルが設定されてもよい。リレーＵＥとリモートＵＥ間で１つのＳＬベアラが設定される。該ＳＬベアラは、ＳＬ　ＲＬＣベアラとするとよい。ＳＬ　ＲＬＣチャネルであってもよい。ＳＬ　ＲＬＣベアラはＰＣ５　ＲＬＣベアラとも称する。ＳＬ　ＲＬＣチャネルはＰＣ５　ＲＬＣチャネルとも称する。
　ＮＷからリモートＵＥへの通信におけるベアラマッピングに関して開示する。ＭＮとＳＮは、ＮＷからリモートＵＥへの通信において、ＮＷとリモートＵＥ間のＲＢを、ＤＣ用のＵｕのＲＬＣベアラにマッピングする機能を有する。該ＤＣ用のＵｕのＲＬＣベアラとして、ＭＣＧベアラあるいはＳＣＧベアラあるいはスプリットベアラがある。リレーＵＥに接続されるリモートＵＥは１つに限らず複数であってもよい。リモートＵＥとＮＷ間のＲＢは１つに限らず複数であってもよい。リレーＵＥに接続される１つまたは複数のリモートＵＥのＲＢ　ａｎｄ／ｏｒ　リモートＵＥとＮＷ間の１つまたは複数のＲＢを、ＤＣ用のＵｕのＲＬＣベアラにマッピングしてもよい。前述の機能は、ＭＮとＳＮに構成されるＵｕのＡＤＰが有してもよい。ＡＤＰに、ＤＣが設定される場合と設定されない場合の機能を集約してもよい。この場合、ＭＮとＳＮの構成を容易にできる。
　ＭＮとＳＮは、ＮＷからリモートＵＥへの通信において、リモートＵＥの識別子とリモートＵＥとＮＷ間のＲＢの識別子（ＲＢ識別子：ＲＢ　ＩＤ）を付加してもよい。ＲＢ　ＩＤは、ＲＢがＳＲＢの場合、ＳＲＢ　ＩＤであってもよい。ＲＢ　ＩＤは、ＲＢがＤＲＢの場合、ＤＲＢ　ＩＤであってもよい。このようにすることで、リレーＵＥが、送信先のリモートＵＥ、リモートＵＥとＮＷ間通信用のＲＢを認識可能となる。
　ＭＮとＳＮは、ＮＷからリモートＵＥへの通信において、ＤＣに用いるベアラについての情報を付加してもよい。ＤＣに用いるベアラについての情報として、たとえば、ベアラの終端を示す識別子　ａｎｄ／ｏｒ　ベアラの種類を示す識別子　ａｎｄ／ｏｒ　ＭＮ用かＳＮ用かを示す識別子などがある。このようにすることで、リレーＵＥまたはリモートＵＥが、ＤＣに用いるベアラの終端や種類などを認識可能となる。
　前述の付加機能は、ＭＮとＳＮに構成されるＵｕのＡＤＰが有してもよい。ＡＤＰに、ＤＣが設定される場合と設定されない場合の機能を集約してもよい。この場合、ＭＮとＳＮの構成を容易にできる。
　リレーＵＥは、ＮＷからリモートＵＥへの通信において、ＤＣ用のＵｕのＲＬＣベアラをＰＣ５のＲＬＣベアラにマッピングする機能を有する。該マッピングに、ＭＮ，ＳＮのＡＤＰで付加されたリモートＵＥ識別子、ＲＢ識別子を用いてもよい。該マッピングに、ＭＮ，ＳＮのＡＤＰで付加されたＤＣに用いるベアラについての情報を用いてもよい。このようにすることで、リレーＵＥで、ＤＣ用のＭＣＧベアラあるいはＳＣＧベアラあるいはスプリットベアラを、ＰＣ５のＲＬＣベアラにマッピングすることが可能となる。前述の機能は、リレーＵＥに構成されるＵｕのＡＤＰが有してもよい。ＡＤＰに、ＤＣが設定される場合と設定されない場合の機能を集約してもよい。この場合、リレーＵＥの構成を容易にできる。
　リレーＵＥは、ＰＣ５のＲＬＣベアラにマッピングする際に、ＭＮ，ＳＮで付加されたリモートＵＥ識別子、ＲＢ識別子、ＤＣに用いるベアラについての情報などの一部または全部を削除してもよい。リモートＵＥへのＰＣ５のＲＬＣベアラへのマッピングにおいて、該識別子や情報の一部または全部を付加しなくてもよい。
　リモートＵＥは、ＮＷからリモートＵＥへの通信において、ＰＣ５のＲＬＣベアラとＤＣ用のＵｕのＲＬＣベアラをＮＷとリモートＵＥ間のＲＢにマッピングする機能を有する。該マッピングに、ＭＮ，ＳＮで付加されたリモートＵＥ識別子、ＲＢ識別子を用いてもよい。該マッピングに、ＭＮ，ＳＮで付加されたＤＣに用いるベアラについての情報を用いてもよい。
　リモートＵＥからＮＷへの通信におけるベアラマッピングに関して開示する。リモートＵＥは、リモートＵＥからＮＷへの通信において、ＮＷとリモートＵＥ間のＲＢを、ＰＣ５のＲＬＣベアラにマッピングする機能を有する。リモートＵＥは、ＮＷからリモートＵＥへの通信において、リモートＵＥとＮＷ間のＲＢの識別子と基地局の識別子とを付加してもよい。該基地局は複数であってもよい。たとえば、リレーＵＥが複数の基地局に接続するような場合に付加してもよい。該基地局が複数か否かを示す情報あるいは該基地局の識別子が複数か否かを示す情報を付加してもよい。基地局の識別子として、ＭＮ　ａｎｄ／ｏｒ　ＳＮの識別子としてもよい。たとえば、ＤＣが設定される場合に適用してもよい。このようにすることで、リレーＵＥ、ＭＮまたはＳＮが、たとえば、リレーＵＥが複数の基地局に送信するような場合も、送信先の基地局、リモートＵＥとＮＷ間通信用のＲＢを認識可能となる。
　リモートＵＥは、リモートＵＥからＮＷへの通信において、ＤＣに用いるベアラについての情報を付加してもよい。ＤＣに用いるベアラについての情報として、たとえば、ベアラの終端を示す識別子　ａｎｄ／ｏｒ　ベアラの種類を示す識別子　ａｎｄ／ｏｒ　ＭＮ用かＳＮ用かを示す識別子などがある。このようにすることで、リレーＵＥ、ＭＮまたはＳＮが、ＤＣに用いるベアラの終端や種類などを認識可能となる。
　前述の付加機能は、リモートＵＥに構成されるＳＬのＡＤＰが有してもよい。ＳＬ　ＡＤＰに、ＤＣが設定される場合と設定されない場合の機能を集約してもよい。リモートＵＥの構成を容易にできる。
　リレーＵＥは、リモートＵＥからＮＷへの通信において、ＰＣ５のＲＬＣベアラをＤＣ用のＵｕのＲＬＣベアラにマッピングする機能を有する。該マッピングに、リモートＵＥで付加された基地局識別子、ＲＢ識別子、ＤＣに用いるベアラについての情報などを用いてもよい。該ＤＣ用のＵｕのＲＬＣベアラとして、ＭＣＧベアラあるいはＳＣＧベアラあるいはスプリットベアラがある。リレーＵＥに接続されるリモートＵＥは１つに限らず複数であってもよい。前述の機能は、リレーＵＥに構成されるＵｕのＡＤＰが有してもよい。ＡＤＰに、ＤＣが設定される場合と設定されない場合の機能を集約してもよい。この場合、リレーＵＥの構成を容易にできる。
　リレーＵＥは、ＤＣ用のＵｕのＲＬＣベアラにマッピングする際に、リモートＵＥで付加された基地局の識別子、ＲＢ識別子、ＤＣに用いるベアラについての情報などの一部または全部を削除してもよい。基地局へのＤＣ用のＵｕのＲＬＣベアラへのマッピングにおいて、該識別子や情報の一部または全部を付加しなくてもよい。
　リレーＵＥは、リモートＵＥからＮＷへの通信において、リモートＵＥの識別子とリモートＵＥとＮＷ間のＲＢの識別子とを付加してもよい。ＲＢ　ＩＤは、ＲＢがＳＲＢの場合、ＳＲＢ　ＩＤであってもよい。ＲＢ　ＩＤは、ＲＢがＤＲＢの場合、ＤＲＢ　ＩＤであってもよい。このようにすることで、ＭＮとＳＮが、送信元のリモートＵＥ、リモートＵＥとＮＷ間通信用のＲＢを認識可能となる。前述の付加機能は、リレーＵＥに構成されるＵｕのＡＤＰが有してもよい。ＡＤＰに、ＤＣが設定される場合と設定されない場合の機能を集約してもよい。この場合、リレーＵＥの構成を容易にできる。
　ＭＮとＳＮは、リモートＵＥからＮＷへの通信において、ＤＣ用のＵｕのＲＬＣベアラをＮＷとリモートＵＥ間のＲＢにマッピングする機能を有する。リレーＵＥに接続されるリモートＵＥは１つに限らず複数であってもよい。リモートＵＥとＮＷ間のＲＢは１つに限らず複数であってもよい。ＤＣ用のＵｕのＲＬＣベアラを、リレーＵＥに接続される１つまたは複数のリモートＵＥのＲＢ　ａｎｄ／ｏｒ　リモートＵＥとＮＷ間の１つまたは複数のＲＢにマッピングしてもよい。該マッピングに、リモートＵＥまたはリレーＵＥのＡＤＰで付加されたリモートＵＥ識別子、ＲＢ識別子、ＤＣに用いるベアラについての情報などを用いてもよい。このようにすることで、ＭＮとＳＮで、ＤＣ用のＭＣＧベアラあるいはＳＣＧベアラあるいはスプリットベアラを、リモートＵＥとＮＷ間通信用のＲＢのＰＤＣＰに転送することが可能となる。前述の機能は、ＭＮとＳＮに構成されるＵｕのＡＤＰが有してもよい。ＡＤＰに、ＤＣが設定される場合と設定されない場合の機能を集約してもよい。この場合、ＭＮとＳＮの構成を容易にできる。
　Ｃ－Ｐｌａｎｅのプロトコルについては、ＭＮ、リモートＵＥにおけるＳＤＡＰの代わりにＲＲＣを設ければよい。ＳＲＢに対応したＲＲＣを設けるとよい。ＳＲＢにＤＣが設定される場合はＭＮ終端ベアラのみが設定されてもよい。ＳＲＢのＤＣが可能となる。
　このようにすることで、２つのｇＮＢと接続したリレーＵＥを介したリモートＵＥとＮＷ間の通信を可能とする。
　リレーＵＥを介したリモートＵＥとＮＷ間の通信において、リレーＵＥが２つのｇＮＢと接続する場合のプロトコル構成の他の方法を開示する。図４０は、実施の形態４について、リレーＵＥを介したリモートＵＥとＮＷ間の通信において、リレーＵＥが２つのｇＮＢと接続する場合のプロトコルスタックの他の構成方法を示す図である。Ｕ－Ｐｌａｎｅについて示している。図３９と異なる部分を主に説明する。
　ＭＮとＳＮは、図３９の例と同様、ＤＣ用のＵｕのプロトコルを有する。リレーＵＥは、図３９の例と同様、ＭＮ用とＳＮ用の２つのＵｕのプロトコルを有す。また、リレーＵＥはリモートＵＥ間に２つのＰＣ５のプロトコルを有す。ＭＮ用とＳＮ用のＰＣ５のプロトコルである。ＤＣ用としてもよい。該ＰＣ５のプロトコルはＰＣ５　ＲＬＣ、ＰＣ５　ＭＡＣ、ＰＣ５　ＰＨＹである。ＰＣ５　ＲＬＣの上位にＰＣ５　ＡＤＰが構成されてもよい。ＰＣ５　ＳＤＡＰ、ＰＣ５　ＰＤＣＰは無くてもよい。リモートＵＥはリレーＵＥ間に２つのＰＣ５のプロトコルを有す。ＭＮ用とＳＮ用のＰＣ５のプロトコルである。ＤＣ用としてもよい。該ＰＣ５のプロトコルはＰＣ５　ＲＬＣ、ＰＣ５　ＭＡＣ、ＰＣ５　ＰＨＹである。ＰＣ５　ＲＬＣの上位にＰＣ５　ＡＤＰが構成されてもよい。ＰＣ５　ＳＤＡＰ、ＰＣ５　ＰＤＣＰは無くてもよい。また、リモートＵＥは、ＭＮ　ａｎｄ／ｏｒ　ＳＮ間にＵｕのプロトコルを有す。該Ｕｕのプロトコルは、ＰＣ５　ＳＤＡＰ、ＰＣ５　ＰＤＣＰである。リモートＵＥで、ＰＣ５のＰＤＣＰあるいはＡＤＰとＵｕのＰＤＣＰが接続される。ＰＤＣＰは、ＭＮ終端ベアラ用に１つ、ＳＮ終端ベアラ用に１つ構成されてもよい。リモートＵＥでＤＣが終端される。
　ベアラについて開示する。ＭＮとリモートＵＥ間で、ＲＢが設定される。該ＲＢにおいて、ＭＮ　ａｎｄ／ｏｒ　ＳＮとリレーＵＥ間でＤＣ用ベアラが設定される。リレーＵＥとリモートＵＥ間でＤＣ用ＳＬベアラが設定される。該ＳＬベアラは、ＳＬ　ＲＬＣベアラとするとよい。ＳＬ　ＲＬＣチャネルであってもよい。
　ＮＷからリモートＵＥへの通信におけるベアラマッピングに関して開示する。図３９の例で開示したベアラマッピングの方法を適宜適用するとよい。ここでは主に図３９の例で開示した方法と異なる点について開示する。
　リレーＵＥは、ＮＷからリモートＵＥへの通信において、ＤＣ用のＵｕのＲＬＣベアラをＤＣ用のＰＣ５のＲＬＣベアラにマッピングする機能を有する。ＭＮ用のＵｕのＲＬＣベアラをＭＮ用のＰＣ５のＲＬＣベアラにマッピングする。ＳＮ用のＵｕのＲＬＣベアラをＳＮ用のＰＣ５のＲＬＣベアラにマッピングする。該マッピングに、ＭＮ，ＳＮのＡＤＰで付加されたリモートＵＥ識別子、ＲＢ識別子を用いてもよい。該マッピングに、ＭＮ、ＳＮのＡＤＰで付加されたＤＣに用いるベアラについての情報を用いてもよい。このようにすることで、リレーＵＥで、ＤＣ用のＭＣＧベアラあるいはＳＣＧベアラあるいはスプリットベアラを、ＤＣ用のＰＣ５のＲＬＣベアラにマッピングすることが可能となる。前述の機能は、リレーＵＥに構成されるＵｕのＡＤＰが有してもよい。ＡＤＰに、ＤＣが設定される場合と設定されない場合の機能を集約してもよい。この場合、リレーＵＥの構成を容易にできる。
　リレーＵＥは、ＰＣ５のＲＬＣベアラにマッピングする際に、ＭＮ，ＳＮで付加されたリモートＵＥ識別子、ＲＢ識別子、ＤＣに用いるベアラについての情報などの一部または全部を削除してもよい。リモートＵＥへのＰＣ５のＲＬＣベアラへのマッピングにおいて、該識別子や情報の一部または全部を付加しなくてもよい。
　リモートＵＥは、ＮＷからリモートＵＥへの通信において、ＭＮ用のＰＣ５のＲＬＣベアラとＳＮ用のＰＣ５のＲＬＣベアラとをＮＷとリモートＵＥ間のＲＢにマッピングする機能を有する。該マッピングに、ＭＮ，ＳＮのＤＰで付加されたリモートＵＥ識別子、ＲＢ識別子を用いてもよい。該マッピングに、ＭＮ，ＳＮで付加されたＤＣに用いるベアラについての情報を用いてもよい。
　リモートＵＥからＮＷへの通信におけるベアラマッピングに関して開示する。図３９の例で開示したベアラマッピングの方法を適宜適用するとよい。ここでは主に図３９の例で開示した方法と異なる点について開示する。リモートＵＥは、リモートＵＥからＮＷへの通信において、ＮＷとリモートＵＥ間のＲＢを、ＤＣ用のＰＣ５のＲＬＣベアラにマッピングする機能を有する。該ＤＣ用のＰＣ５のＲＬＣベアラとして、ＭＣＧベアラあるいはＳＣＧベアラあるいはスプリットベアラがある。リモートＵＥは、ＮＷからリモートＵＥへの通信において、リモートＵＥとＮＷ間のＲＢの識別子と基地局の識別子とを付加してもよい。該基地局は複数であってもよい。たとえば、リレーＵＥが複数の基地局に接続するような場合に付加してもよい。該基地局が複数か否かを示す情報あるいは該基地局の識別子が複数か否かを示す情報を付加してもよい。基地局の識別子として、ＭＮ　ａｎｄ／ｏｒ　ＳＮの識別子としてもよい。たとえば、ＤＣが設定される場合に適用してもよい。このようにすることで、リレーＵＥ、ＭＮまたはＳＮは、リレーＵＥが複数の基地局に送信するような場合も、送信先の基地局、リモートＵＥとＮＷ間通信用のＲＢを認識可能となる。
　前述の付加機能は、リモートＵＥに構成されるＳＬのＡＤＰが有してもよい。ＳＬ　ＡＤＰに、ＤＣが設定される場合と設定されない場合の機能を集約してもよい。リモートＵＥの構成を容易にできる。
　リレーＵＥは、リモートＵＥからＮＷへの通信において、ＤＣ用のＰＣ５のＲＬＣベアラをＤＣ用のＵｕのＲＬＣベアラにマッピングする機能を有する。ＤＣ用のＵｕのＲＬＣベアラとして、ＭＣＧベアラあるいはＳＣＧベアラあるいはスプリットベアラがある。ＭＮ用のＰＣ５のＲＬＣベアラをＭＮ用のＵｕのＲＬＣベアラにマッピングする。ＳＮ用のＰＣ５のＲＬＣベアラをＳＮ用のＵｕのＲＬＣベアラにマッピングする。ＰＣ５のＭＣＧベアラをＵｕのＭＣＧベアラにマッピングする。ＰＣ５のＳＣＧベアラをＵｕのＳＣＧベアラにマッピングする。ＰＣ５のスプリットベアラをＵｕのスプリットベアラにマッピングする。該マッピングに、リモートＵＥで付加された基地局の識別子、ＲＢ識別子、ＤＣに用いるベアラについての情報などを用いてもよい。リレーＵＥに接続されるリモートＵＥは１つに限らず複数であってもよい。前述の機能は、リレーＵＥに構成されるＵｕのＡＤＰが有してもよい。ＡＤＰに、ＤＣが設定される場合と設定されない場合の機能を集約してもよい。この場合、リレーＵＥの構成を容易にできる。
　リレーＵＥは、ＤＣ用のＵｕのＲＬＣベアラにマッピングする際に、リモートＵＥで付加された基地局の識別子、ＲＢ識別子、ＤＣに用いるベアラについての情報などの一部または全部を削除してもよい。基地局へのＤＣ用のＵｕのＲＬＣベアラへのマッピングにおいて、該識別子や情報の一部または全部を付加しなくてもよい。
　Ｃ－Ｐｌａｎｅのプロトコルについては、ＭＮ、リモートＵＥにおけるＳＤＡＰの代わりにＲＲＣを設ければよい。ＳＲＢに対応したＲＲＣを設けるとよい。ＳＲＢにＤＣが設定される場合はＭＮ終端ベアラのみが設定されてもよい。ＳＲＢのＤＣが可能となる。
　このようにすることで、２つのｇＮＢと接続したリレーＵＥを介したリモートＵＥとＮＷ間の通信を可能とする。
　リレーＵＥを介して行うリモートＵＥとＮＷ間の通信において、リレーＵＥが複数のｇＮＢと接続するための設定方法を開示する。本実施の形態では、リレーＵＥが２つのｇＮＢと接続するＤＣの設定方法を開示する。
　ＭＮはリレーＵＥに対してＤＣの設定を行う。ＭＮは、リレーＵＥとの間のＲＢに対してＤＣの設定を行う。該ＲＢは、リモートＵＥとＭＮ間の通信用であってもよい。該ＲＢは、ＳＲＢ　ａｎｄ／ｏｒ　ＤＲＢであってもよい。ＳＲＢとしてＳＲＢ２であってもよい。該ＲＢは、リレーＵＥとＭＮ間の通信用であってもよい。たとえばレイヤ３のＵＥ－ＮＷ間リレーに適用してもよい。
　ＭＮはリレーＵＥに対してＵｕのＤＣ設定を行う。リレーＵＥがＤＣの終端となる。ＤＣが設定されたリレーＵＥはＭＮとＲＲＣ接続状態とするとよい。また、ＭＮは、リレーＵＥがＭＮとＲＲＣ接続している状態において、リレーＵＥに対してＤＣ設定を開始する、としてもよい。ＤＣが設定されたリレーＵＥはＣ－ｐｌａｎｅにおいてＭＮを介してＣＮに接続する。
　ＭＮは、ＳＮに対して、リモートＵＥとＭＮ間通信用のリレーＵＥとＭＮ間のＲＢに対するＳＮの追加要求を送信する。該追加要求はＸｎシグナリングを用いて送信するとよい。Ｓ－Ｎｏｄｅ　ａｄｄｉｔｉｏｎ　ｒｅｑｕｅｓｔメッセージを用いてもよい。
　ＳＮの追加要求に含める情報例を１７個開示する。
（１）リレーＵＥに関する情報。
（２）リモートＵＥに関する情報。
（３）ＭＮとリモートＵＥ間のＲＲＣ設定情報。
（４）ＭＮとリレーＵＥ間のＲＲＣ設定情報。
（５）リモートＵＥとリレーＵＥ間のＳＬ　ＲＲＣ設定情報。
（６）ＭＮとリモートＵＥ間のＲＢ情報。
（７）ＭＮとリレーＵＥ間のＲＢ情報。
（８）リモートＵＥとリレーＵＥ間のＳＬベアラ情報。
（９）リレーＵＥとＣＮ間のＰＤＵに関する情報。
（１０）リモートＵＥとＣＮ間のＰＤＵに関する情報。
（１１）ＳＮに要求するベアラ終端を示す情報。
（１２）ＳＮに要求するベアラ種類情報。
（１３）ＭＮの識別子。
（１４）通信に要求されるＱｏＳに関する情報。
（１５）ネットワークスライシングに関する情報。
（１６）トレースに関する情報。
（１７）（１）～（１６）の組合せ。
　（１）は、ＤＣを設定するリレーＵＥに関する情報である。たとえば、リレーＵＥの識別子でもよい。たとえば、リレーＵＥのケーパビリティでもよい。（２）は、ＮＷと通信を行うリモートＵＥに関する情報である。リモートＵＥに関する情報は、たとえば、リモートＵＥの識別子でもよい。たとえば、リモートＵＥのケーパビリティでもよい。
　（３）は、たとえば、ＭＮがリモートＵＥに設定するセルグループの設定情報でもよい。（４）は、たとえば、ＭＮがリレーＵＥに設定するセルグループの設定情報でもよい。（５）は、リモートＵＥとリレーＵＥ間のＳＬのＲＲＣ設定情報である。たとえば、リモートＵＥからリレーＵＥに　ａｎｄ／ｏｒ　リレーＵＥからリモートＵＥに設定するＲＲＣ情報でもよい。
　（６）は、ＤＣを設定するＭＮとリモートＵＥ間のＲＢに関する情報である。たとえば、ＲＢの識別子であってもよい。たとえば、ＤＣを設定するＲＢがＳＲＢであれば、該ＳＲＢの識別子であってもよい。たとえば、ＤＣを設定するＲＢがＤＲＢであれば、該ＤＲＢの識別子であってもよい。ＤＣを設定するＲＢを特定可能となる。たとえば、ＰＤＣＰの構成情報であってもよい。たとえば、ＤＣを設定するＲＢがＤＲＢであれば、ＳＤＡＰの構成情報であってもよい。（７）は、ＤＣを設定するＭＮとリレーＵＥ間のＲＢに関する情報である。ＲＢに関する情報の例としては（６）と同様である。
　（８）は、リレーＵＥを介したリモートＵＥとＮＷ間の通信におけるリレーＵＥとリモートＵＥ間のＳＬベアラに関する情報である。ＳＬベアラはＳＬ　ＲＢであってもよい。たとえば、ＳＬ　ＲＢの識別子であってもよい。たとえば、ＳＬ　ＲＢとしてＳＬ　ＳＲＢが設定されていれば、該ＳＬ　ＳＲＢの識別子であってもよい。たとえば、ＳＬ　ＲＢとしてＳＬ　ＤＲＢが設定されていれば、該ＳＬ　ＤＲＢの識別子であってもよい。たとえば、ＳＬ　ＰＤＣＰの構成情報であってもよい。たとえば、ＳＬ　ＲＢとしてＳＬ　ＤＲＢが設定されていれば、ＳＬ　ＳＤＡＰの構成情報であってもよい。ＳＬベアラは、ＳＬ　ＲＬＣベアラであってもよい。たとえば、ＳＬ　ＲＬＣベアラの識別子であってもよい。たとえば、ＳＬ　ＲＬＣ、ＳＬ　ＭＡＣ、ａｎｄ／ｏｒ　ＳＬ　ＰＨＹの構成情報であってもよい。たとえば、ＳＬのロジカルチャネルの構成情報であってもよい。
　（９）は、リレーＵＥを介したリモートＵＥとＮＷ間の通信用に設定されている、リレーＵＥとＣＮ間のＰＤＵに関する情報である。たとえば、ＰＤＵセッションの識別子でもよい。たとえば、ＰＤＵセッションに要求されるＱｏＳに関する情報であってもよい。（１０）は、リレーＵＥを介したリモートＵＥとＮＷ間の通信用に設定されている、リモートＵＥとＣＮ間のＰＤＵに関する情報である。たとえば、ＰＤＵセッションの識別子でもよい。たとえば、ＰＤＵセッションに要求されるＱｏＳに関する情報であってもよい。
　（１１）は、ＤＣ用のベアラの終端を示す情報である。たとえば、ＭＮ終端ベアラかＳＮ終端ベアラかを示す情報としてもよい。（１２）は、ＤＣ用ベアラの種類を示す情報である。たとえば、ＭＣＧベアラ、ＳＣＧベアラ、スプリットベアラなどである。（１３）は、リレーＵＥが接続するＭＮの識別子である。ＰＣｅｌｌの識別子であってもよい。ＳＮの追加要求の送信元であるＭＮを特定することが可能となる。
　（１４）は、リモートＵＥとＮＷ間の通信に要求されるＱｏＳに関する情報である。または、リレーＵＥとＮＷ間の通信に要求されるＱｏＳに関する情報、リモートＵＥとリレーＵＥ間の通信に要求されるＱｏＳに関する情報としてもよい。ＱｏＳに関する情報は、たとえば、該通信に要求されるリソースタイプ、パケットロス率、許容遅延、優先順位などがある。（１５）は、たとえば、ネットワークスライシングの識別子などである。（１６）は、トレース機能の実行に関する情報である。たとえば、トレース機能を実行するか否かを示す情報、トレースした情報を収集するノードに関する情報、収集する情報ＭＤＴ（Minimization　of　Drive　Tests）に関する情報などがある。
　トレース機能として、リレーＵＥを介してリモートＵＥがＮＷと間接接続する場合を含めてもよい。たとえば、トレース機能として、リモートＵＥがどの基地局と接続したかを示す情報、リモートＵＥが接続するリレーＵＥの情報、リレーＵＥがどの基地局と接続したかを示す情報、リモートＵＥとリレーＵＥ間のＲＬＦ情報、リレーＵＥと基地局間のＲＬＦ情報、リモートＵＥのＭＤＴに関する情報、リレーＵＥのＭＤＴに関する情報などの収集を行ってもよい。これらの情報が、リモートＵＥとリレーＵＥ間、リモートＵＥと基地局間、リレーＵＥと基地局間、ＭＮとＳＮ間などの基地局間、前に接続していた基地局と新たに接続する基地局間、基地局とトレースに関する情報を収集するノード間で通信されてもよい。
　このようにすることで、ＭＮはＳＮに対して、ＤＣ用にＳＮ追加要求を送信することが可能となる。また、ＳＮは、ＭＮからＳＮ追加要求を受信することで、たとえば、どのリレーＵＥに対するＤＣかなどを認識可能となる。ＳＮはＭＮから受信した情報を用いて、リレーＵＥに対するＤＣ用の設定を行ってもよい。
　ＳＮはリレーＵＥに対するＤＣ設定を行う。ＳＮは、リレーＵＥとＳＮ間のＤＣのための設定を行う。ＳＮは、ＭＮから受信したＳＮ追加要求メッセージに含まれる情報を用いて該ＤＣ設定を行ってもよい。リレーＵＥに対するＳＮとの間のＤＣ設定として、後述するＤＣ用設定に含める情報例に示す設定を行ってもよい。後述するＤＣ用設定に含める情報例のうち、ＳＮに関する情報を設定してもよい。たとえば、ＳＮとリレーＵＥ間のＲＲＣ設定であってもよい。ＲＲＣ設定は、たとえば、ＳＮとリレーＵＥ間のＲＬＣベアラに関する設定であってもよい。たとえば、ＳＮとリレーＵＥ間のセルグループの設定であってもよい。
　ＳＮはＭＮに対してＳＮの追加要求に対する応答メッセージを送信する。ＳＮがＤＣ設定を実施する場合、ＭＮに対してＳＮ追加要求肯定応答メッセージを送信する。Ｘｎシグナリングを用いて送信するとよい。ＳＮ追加要求肯定応答メッセージとしてＳ－Ｎｏｄｅ　ａｄｄｉｔｉｏｎ　ｒｅｑｕｅｓｔ　ａｃｋｎｏｗｌｅｄｇｅメッセージを用いてもよい。該メッセージに、リレーＵＥに対するＤＣ設定情報を含めるとよい。該ＤＣ設定情報は、たとえば、ＳＮとリレーＵＥ間のセルグループの設定情報であってもよい。また、該メッセージに、前述に開示したＳＮの追加要求に含める情報例の一部を含めてもよい。たとえば、リレーＵＥに関する情報、リレーＵＥとＣＮ間のＰＤＵに関する情報、リモートＵＥとＣＮ間のＰＤＵに関する情報、ベアラ終端を示す情報、ベアラ種類情報などである。
　ＳＮはリレーＵＥとリモートＵＥ間のＳＬの設定を行ってもよい。ＳＮは、ＤＣのため、リレーＵＥとリモートＵＥ間のＳＬの設定を行う。ＳＮは、ＭＮから受信したＳＮ追加要求メッセージに含まれる情報を用いて該ＳＬの設定を行ってもよい。リレーＵＥとリモートＵＥ間のＤＣ設定として、後述するＳＬベアラの設定を行ってもよい。後述するＳＬベアラの設定に含める情報例のうち、ＳＮに関する情報を設定してもよい。該ＳＬの設定は、リモートＵＥとリレーＵＥ間のＳＬのＲＲＣ設定であってもよい。たとえば、リモートＵＥからリレーＵＥへの　ａｎｄ／ｏｒ　リレーＵＥからリモートＵＥへのＳＬ　ＲＲＣ設定でもよい。ＳＬ　ＲＲＣ設定は、たとえば、リレーＵＥとリモートＵＥ間のＳＬのＲＬＣベアラに関する設定であってもよい。
　ＳＮからＭＮに対して送信するＳＮの追加要求に対する肯定応答メッセージに、リレーＵＥとリモートＵＥ間のＳＬの設定情報を含めてもよい。たとえば、リモートＵＥとリレーＵＥ間のＳＬのＲＲＣ設定情報を含めてもよい。ＭＮは、ＳＮから受信した該情報を用いて、リモートＵＥとリレーＵＥ間のＳＬの設定を修正してもよい。ＭＮは、ＳＮから受信した該情報を用いて、リモートＵＥとリレーＵＥ間のＳＬベアラの修正を行ってもよい。このようにすることで、ＳＮの設定情報を考慮することが可能となる。ＳＮの電波伝搬環境や、負荷状況を考慮することができ、リレーＵＥを介したリモートＵＥとＮＷ間の通信品質を向上させることが可能となる。
　ＳＮがリレーＵＥに対してＤＣ設定を実施できなかった場合、ＭＮに対してＳＮ追加要求拒否応答メッセージを送信する。Ｘｎシグナリングを用いて送信するとよい。ＳＮ追加要求拒否応答メッセージとしてＳ－Ｎｏｄｅ　ａｄｄｉｔｉｏｎ　ｒｅｑｕｅｓｔ　ｒｅｊｅｃｔメッセージを用いてもよい。該メッセージに、たとえば、リレーＵＥに関する情報、理由情報を含めて通知してもよい。
　ＭＮはリレーＵＥに対してＤＣ用の設定を送信する。ＤＣ用設定に含める情報例を４つ開示する。
（１）ＲＢに関する情報。
（２）ＵｕのＲＬＣベアラに関する情報。
（３）ＳＮの識別子。
（４）（１）～（３）の組合せ。
　（１）のＲＢに関する情報は、ＲＢの設定に関する情報である。ＲＢの設定に関する情報例を５つ開示する。
（１－１）設定するＳＲＢに関する情報。
（１－２）設定するＤＲＢに関する情報。
（１－３）ＳＤＡＰ設定に関する情報。
（１－４）ＰＤＣＰ設定に関する情報。
（１－５）（１－１）～（１－４）の組合せ。
　（１－１）は、たとえば、設定するＳＲＢの識別子であってもよい。たとえば、該ＳＲＢの設定情報でもよい。（１－２）は、たとえば、設定するＤＲＢの識別子であってもよい。たとえば、該ＤＲＢの設定情報でもよい。（１－３）は、たとえば、設定するＲＢがＤＲＢの場合に設定されてもよい。ＤＲＢ識別子と関連付けられてもよい。（１－４）は、たとえば、設定するＲＢがＳＲＢ　ａｎｄ／ｏｒ　ＤＲＢの場合に設定されてもよい。ＳＲＢ識別子　ａｎｄ／ｏｒ　ＤＲＢ識別子と関連付けられてもよい。ＰＤＣＰ設定に関する情報として、たとえば、接続するＲＬＣベアラに関する情報を含めてもよい。ＲＬＣベアラに関する情報は、たとえば、論理チャネルの識別子でもよい。たとえば、ＤＣ用ベアラの種類を示す情報でもよい。たとえば、セルグループに関する情報でもよい。
　（１）のＲＢに関する情報は、既に設定されているＲＢ設定を用いてもよい。ＲＢ設定は、既に設定されているＲＢ設定の修正であってもよい。既に設定されているＲＢ設定を示す情報を含めるとよい。ＲＢ設定を示す情報として、ＲＢの識別子であってもよい。ＲＢとして、たとえばＳＲＢであればＳＲＢの識別子、たとえばＤＲＢであればＤＲＢの識別子でもよい。
　ＭＮはリレーＵＥに対してＲＢ設定を送信する。ＭＮはリレーＵＥに対してＲＢ設定を、ＲＲＣシグナリングで送信してもよい。ＲＲＣＲｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージに含めて送信してもよい。ＲａｄｉｏＢｅａｒｅｒＣｏｎｆｉｇ情報に含めて送信してもよい。
　（２）のＵｕのＲＬＣベアラに関する情報は、ＤＣ用のＵｕ　ＲＬＣベアラに関する情報としてもよい。Ｕｕ　ＲＬＣベアラ設定ではなく、Ｕｕ　ＲＬＣ　ｃｈａｎｎｅｌの設定としてもよい。本明細書においては特に説明の無い限りＵｕ　ＲＬＣベアラの設定を用いて説明する。
　ＤＣ用のＵｕ　ＲＬＣベアラ設定に含める情報例を７つ開示する。
（２－１）対応するＲＢの識別子。
（２－２）ＭＣＧ用Ｕｕ　ＲＬＣベアラの設定情報。
（２－３）ＳＣＧ用Ｕｕ　ＲＬＣベアラの設定情報。
（２－４）ベアラ終端を示す情報。
（２－５）ベアラの種類を示す情報。
（２－６）Ｕｕ　ＲＬＣベアラの識別子。
（２－７）（２－１）～（２－６）の組合せ。
　（２－１）は、ＤＣ用に設定を行うＵｕのＲＬＣベアラに対応するＲＢの識別子とするとよい。（２－２）は、たとえば、ＲＬＣの設定情報でもよい。たとえば、論理チャネルの設定情報でもよい。たとえば、論理チャネルの識別子でもよい。ＭＣＧ用Ｕｕ　ＲＬＣベアラの設定情報は、ＭＣＧの設定情報に含めてもよい。（２－３）は、たとえば、ＲＬＣの設定情報でもよい。たとえば、論理チャネルの設定情報でもよい。たとえば、論理チャネルの識別子でもよい。ＳＣＧ用Ｕｕ　ＲＬＣベアラの設定情報は、ＳＣＧの設定情報に含めてもよい。（２－４）は、たとえば、ＭＮ終端ベアラかＳＮ終端ベアラかを示す情報としてもよい。（２－５）は、たとえば、ＭＣＧベアラかＳＣＧベアラかスプリットベアラかを示す情報としてもよい。
　ＭＮはリレーＵＥに対してＵｕ　ＲＬＣベアラ設定を送信する。Ｕｕ　ＲＬＣベアラ設定に、ＲＲＣＲｅｃｏｎｆｉｇｕｒａｔｉｏｎを用いてもよい。該設定は既に設定されているＵｕ　ＲＬＣベアラ設定の修正であってもよい。送信する該メッセージに、既に設定されているＵｕ　ＲＬＣベアラ設定を示す情報を含めてもよい。
　ＭＮはリレーＵＥに対するＤＣ用の設定を行う場合、ＳＮから受信したリレーＵＥとＳＮ間のＤＣのための設定情報を用いてもよい。ＳＮにおける負荷状況などを考慮することが可能となる。
　ＭＮはリモートＵＥに対してはＤＣを設定しない。リモートＵＥは、リレーＵＥのＤＣ設定に関して認識しなくてもよい。
　ＤＣ設定の種類がＳＮ終端の場合、ＰＤＵセッションの修正を行ってもよい。該修正では、ＭＮとＣＮ間でＰＤＵセッション修正処理が行われる。ＰＤＵセッションの修正は、ＤＣを設定するＲＢがＤＲＢの場合としてもよい。Ｌ３リレーの場合、リレーＵＥとＮＷ間のＰＤＵセッションの修正が行われる。Ｌ２リレーの場合、リモートＵＥとＮＷ間のＰＤＵセッションの修正が行われる。ＰＤＵセッションの修正処理において、ＤＲＢ設定において通知するＰＤＵセッションＩＤを用いてもよい。ＳＤＡＰ設定において通知するＰＤＵセッションＩＤを用いてもよい。この場合、ＭＮ、ＣＮのノードは、修正を行うＰＤＵセッションを特定することができる。
　リモートＵＥとＮＷ間のデータ通信は、ＭＮ/ＳＮとリレーＵＥ間のＤＣ用ベアラ（ＲＬＣベアラ）を介して行われる。リレーＵＥとリモートＵＥ間のデータ通信は、ＳＬベアラを用いて行われる。
　前述に開示したＤＣの設定方法は、リレーＵＥでＤＣが終端される場合に適用してもよい。たとえば、図３８で開示したプロトコル例に適用してもよい。
　図４１は、実施の形態４について、リレーＵＥが２つのｇＮＢと接続するＤＣの設定方法例を示すシーケンス図である。該ＤＣでは、リレーＵＥを介してリモートＵＥとＮＷ間で通信が行われる。ステップＳＴ４４０１で、リモートＵＥ、リレーＵＥ、ＭＮ、ＵＰＦ間でデータ送受信が行われる。ＭＮはリレーＵＥに対してＤＣを設定することを決定する。たとえば、リレーＵＥは周辺ｇＮＢのメジャメントを行いＭＮに対してメジャメント結果を報告する。ＭＮは該メジャメント結果からＤＣに用いるＳＮを決定する。ステップＳＴ４４０２で、ＭＮはＳＮに対してＳＮ追加要求メッセージを送信する。ＭＮはＳＮに対してリレーＵＥに対するＤＣのためのＳＮとしての追加を要求する。ＳＮ追加要求メッセージは、Ｘｎシグナリングを用いて送信される。ＳＮ追加要求メッセージとしてＳ－Ｎｏｄｅ　ａｄｄｉｔｉｏｎ　ｒｅｑｕｅｓｔメッセージを用いてもよい。ＳＮ追加要求メッセージには、前述に開示したＳＮの追加要求の情報例を含めるとよい。
　ＭＮからＳＮ追加要求メッセージを受信したＳＮは、ＳＮ追加要求の情報から、ＤＣ設定を行うリレーＵＥ、ＤＣ設定を行うリモートＵＥとＮＷ間の通信に関する情報、要求されるベアラ終端、要求されるＤＣ用ベアラ種類等を認識し、リレーＵＥに対してＤＣ用の設定を行う。ＤＣ用の設定は、たとえば、ＳＮとリレーＵＥ間のＲＲＣ設定であってもよい。ステップＳＴ４４０３で、ＳＮはＭＮに対して、ＳＮ追加要求応答メッセージを送信する。本例では肯定応答を送信する。ＳＮ追加要求応答メッセージとしてＳ－Ｎｏｄｅ　ａｄｄｉｔｉｏｎ　ｒｅｑｕｅｓｔ　ａｃｋｎｏｗｌｅｄｇｅメッセージを用いてもよい。ＳＮ追加要求応答メッセージに、ＳＮとリレーＵＥ間のＲＲＣ設定を含めてもよい。ＳＮ追加要求応答メッセージを受信したＭＮは、ＳＮがリレーＵＥに対してＤＣ設定を実施したことを認識する。また、ＭＮは、ＳＮとリレーＵＥ間のＲＲＣ設定を認識する。
　ステップＳＴ４４０４で、ＭＮはＳＮに対してＸｎ－Ｕアドレスインジケーションメッセージを通知する。たとえば、ＭＮは、ＭＮとＳＮ間のＤＣに用いるアドレスを設定し、ステップＳＴ４４０４でＳＮに対して送信する。これにより、ＭＮとＳＮ間でＤＣに用いるアドレスを共有し、ＭＮとＳＮ間のデータ送受信を可能とする。
　ステップＳＴ４４０５で、ＭＮはリレーＵＥに対して、ＤＣ用の設定を送信する。該送信にはＲＲＣシグナリングを用いる。ＲＲＣ　ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージを用いて設定を行ってもよい。ＤＣ用設定には、前述に開示したＤＣ用設定の情報例を含めるとよい。ＤＣ用設定の情報のＳＣＧに関する設定として、ＳＮから受信したＲＲＣ設定情報を用いてもよい。リレーＵＥはＭＮからＤＣ用設定を受信することで、ＭＮとＳＮとのＤＣの設定が可能となる。ＭＮとＳＮとのＤＣ設定を行ったリレーＵＥは、ステップＳＴ４４０６で、ＭＮに対して、ＤＣ設定応答を送信する。本例では肯定応答とする。該送信にはＲＲＣシグナリングを用いる。ＲＲＣ　ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎ　ｃｏｍｐｌｅｔｅメッセージを用いてもよい。ＤＣ設定応答を受信したＭＮは、リレーＵＥがＭＮとＳＮを用いたＤＣの設定を完了したことを認識する。
　ステップＳＴ４４０７で、ＭＮはＳＮに対してＳＮ設定完了メッセージを送信する。該送信にはＸｎシグナリングを用いる。Ｓ－Ｎｏｄｅ　ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎ　ｃｏｍｐｌｅｔｅメッセージを送信してもよい。ＳＮは該メッセージを受信することにより、ＭＮおよびリレーＵＥがＤＣ用のＳＮ設定を完了したことを認識する。
　ステップＳＴ４４０８で、リレーＵＥはＭＮとの通信を維持したままＳＮに対してＲＡ処理を開始し通信を行う。
　ステップＳＴ４４０９でＭＮはＳＮに対してＳＮ状態転送を行い、ステップＳＴ４４１０でＵＰＦからのデータをＳＮに転送する。ＳＮ終端ベアラの場合、ＵＰＦとｇＮＢ間のパスをＭＮからＳＮに変更する必要がある。この場合、ステップＳＴ４４２０のパスアップデート処理を実施する。パスアップデート処理では、ＭＮ、ＵＰＦ、ＡＭＦ、ＳＮ間でステップＳＴ４４１１のＰＤＵセッション修正インジケーションメッセージ送信、ステップＳＴ４４１２のベアラ修正メッセージ送信、ステップＳＴ４４１３のエンドマーカーパケット送信、ステップＳＴ４４１４のＰＤＵセッション修正完了メッセージ送信を実施し、Ｕ－ＰｌｎａｅのパスをＭＮからＳＮに変更する。
　このようにすることで、リレーＵＥ、ＭＮ、ＳＮ間でＤＣが行われる。たとえば、ＳＮ終端ＳＣＧベアラの場合、リレーＵＥ、ＳＮ、ＵＰＦ間でデータ通信が行われる。リレーＵＥはリモートＵＥとＰＣ５接続が行われている状態である。このため、たとえば、ＳＮ終端ＳＣＧベアラの場合、ステップＳＴ４４１５で、リモートＵＥ、リレーＵＥ、ＳＮ、ＵＰＦ間でデータ通信が行われる。
　たとえば、ＭＮ終端ＳＣＧベアラの場合、リモートＵＥ、リレーＵＥ、ＳＮ、ＭＮ、ＵＰＦ間でデータ通信が行われる。たとえば、ＳＮ終端ＭＣＧベアラの場合、リモートＵＥ、リレーＵＥ、ＭＮ、ＳＮ、ＵＰＦ間でデータ通信が行われる。たとえば、ＭＮ終端スプリットベアラの場合、リモートＵＥ、リレーＵＥ、ＳＮ、ＭＮ、ＵＰＦ間でデータ通信が行われる。たとえば、ＳＮ終端スプリットベアラの場合、リモートＵＥ、リレーＵＥ、ＭＮ、ＳＮ、ＵＰＦ間でデータ通信が行われる。
　このようにすることで、リレーＵＥが２つのｇＮＢと接続するＤＣの設定が可能となる。
　リレーＵＥが２つのｇＮＢと接続するＤＣの設定方法の他の例を開示する。リモートＵＥとリレーＵＥ間のＳＬベアラの修正を行ってもよい。リモートＵＥとリレーＵＥ間のＳＬベアラの修正を行う場合、ＭＮは、リレーＵＥとリモートＵＥに対して、ＳＬベアラの修正を通知する。ＳＬベアラの修正は、リレーＵＥへのＤＣ設定処理中に行われてもよいし、ＤＣ設定処理後に行われてもよい。
　ＭＮはリレーＵＥに対して、リモートＵＥとリレーＵＥ間のＳＬベアラの設定を行う。ＳＬベアラの設定は、ＳＬベアラの修正のための設定であってもよい。ＳＬベアラの設定情報例として３つ開示する。
（１）ＳＬ　ＲＢに関する情報。
（２）ＳＬのＲＬＣベアラに関する情報。
（３）（１）と（２）の組合せ。
　（１）のＳＬ　ＲＢに関する情報は、ＳＬ　ＲＢの設定に関する情報である。ＳＬ　ＲＢの設定に関する情報例を５つ開示する。
（１－１）設定するＳＬ　ＳＲＢに関する情報。
（１－２）設定するＳＬ　ＤＲＢに関する情報。
（１－３）ＳＬ　ＳＤＡＰ設定に関する情報。
（１－４）ＳＬ　ＰＤＣＰ設定に関する情報。
（１－５）（１－１）～（１－４）の組合せ。
　（１－１）は、たとえば、設定するＳＬ　ＳＲＢの識別子であってもよい。たとえば、該ＳＬ　ＳＲＢの設定情報でもよい。（１－２）は、たとえば、設定するＳＬ　ＤＲＢの識別子であってもよい。たとえば、該ＳＬ　ＤＲＢの設定情報でもよい。（１－３）は、たとえば、設定するＳＬ　ＲＢがＳＬ　ＤＲＢの場合に設定されてもよい。ＳＬ　ＤＲＢ識別子と関連付けられてもよい。（１－４）は、たとえば、設定するＳＬ　ＲＢがＳＬ　ＳＲＢ　ａｎｄ／ｏｒ　ＳＬ　ＤＲＢの場合に設定されてもよい。ＳＬ　ＳＲＢ識別子　ａｎｄ／ｏｒ　ＳＬ　ＤＲＢ識別子と関連付けられてもよい。ＳＬ　ＰＤＣＰ設定に関する情報として、たとえば、接続するＳＬ　ＲＬＣベアラに関する情報を含めてもよい。ＳＬ　ＲＬＣベアラに関する情報は、たとえば、論理チャネルの識別子でもよい。たとえば、ＤＣ用ベアラの種類を示す情報でもよい。たとえば、セルグループに関する情報でもよい。
　（１）のＳＬ　ＲＢに関する情報は、既に設定されているＳＬ　ＲＢ設定を用いてもよい。ＳＬ　ＲＢ設定は、既に設定されているＳＬ　ＲＢ設定の修正であってもよい。既に設定されているＳＬ　ＲＢ設定を示す情報を含めるとよい。ＳＬ　ＲＢ設定を示す情報として、ＳＬ　ＲＢの識別子であってもよい。ＳＬ　ＲＢとして、たとえばＳＬ　ＳＲＢであればＳＬ　ＳＲＢの識別子、たとえばＳＬ　ＤＲＢであればＳＬ　ＤＲＢの識別子でもよい。
　ＭＮはリレーＵＥに対してＳＬ　ＲＢ設定を送信する。ＭＮはリレーＵＥに対してＳＬ　ＲＢ設定を、ＲＲＣシグナリングで送信してもよい。ＲＲＣＲｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージに含めて送信してもよい。あるいは、ＳＬのＲＲＣＲｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージ（RRCReconfigurationSidelink）に含めて送信してもよい。ＳＬのＲａｄｉｏＢｅａｒｅｒＣｏｎｆｉｇ情報（SL-RadioBearerConfig）に含めて送信してもよい。
　（２）は、ＳＬ　ＲＬＣベアラ設定ではなく、ＳＬ　ＲＬＣ　ｃｈａｎｎｅｌの設定としてもよい。本明細書においては特に説明の無い限りＳＬ　ＲＬＣベアラの設定を用いて説明する。
　ＳＬのＲＬＣベアラ設定に含める情報例を４つ開示する。
（２－１）対応するＲＢの識別子。
（２－２）ＳＬ　ＲＬＣベアラの設定情報。
（２－３）ＳＬ　ＲＬＣベアラの識別子。
（２－４）（２－１）～（２－３）の組合せ。
　（２－１）は、ＳＬのＲＬＣベアラに対応するＲＢの識別子とするとよい。（２－２）は、たとえば、ＲＬＣの設定情報でもよい。たとえば、論理チャネルの設定情報でもよい。たとえば、論理チャネルの識別子でもよい。
　ＭＮはリレーＵＥに対してＳＬ　ＲＬＣベアラ設定を送信する。ＳＬ　ＲＬＣベアラ設定の送信に、ＲＲＣＲｅｃｏｎｆｉｇｕｒａｔｉｏｎを用いてもよい。該設定は既に設定されているＳＬ　ＲＬＣベアラ設定の修正であってもよい。送信する該メッセージに、既に設定されているＳＬ　ＲＬＣベアラ設定を示す情報を含めてもよい。
　ＭＮはリレーＵＥに対して、ＳＬベアラの設定情報を、ＵｕのＲＢ設定　ａｎｄ／ｏｒＵｕのＲＬＣベアラ設定を、送信するＲＲＣメッセージに含めて送信してもよいし、別のＲＲＣメッセージに含めて送信してもよい。
　ＭＮはリモートＵＥに対して、リモートＵＥとリレーＵＥ間のＳＬベアラの設定を行う。該ＳＬベアラの設定は、ＳＬベアラの修正のための設定であってもよい。ＳＬベアラの修正を行ってもよい。ＳＬベアラの設定情報は前述に開示した例を適宜適用するとよい。
　ＭＮはリモートＵＥに対してＳＬ　ＲＢ設定を送信する。ＭＮはリモートＵＥに対してＳＬ　ＲＢ設定を、ＲＲＣシグナリングで送信してもよい。該設定をＲＲＣＲｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージに含めて送信してもよい。あるいは、ＳＬのＲＲＣＲｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージに含めて送信してもよい。ＳＬのＲａｄｉｏＢｅａｒｅｒＣｏｎｆｉｇ情報に含めて送信してもよい。
　ＭＮはリモートＵＥに対してＳＬ　ＲＬＣベアラ設定を送信する。ＳＬ　ＲＬＣベアラ設定の送信に、ＲＲＣＲｅｃｏｎｆｉｇｕｒａｔｉｏｎを用いてもよい。該設定は既に設定されているＳＬ　ＲＬＣベアラ設定の修正であってもよい。既に設定されているＳＬ　ＲＬＣベアラ設定を示す情報を含めてもよい。
　ＭＮはリモートＵＥとリレーＵＥ間のＳＬベアラの設定を行う場合、ＳＮから受信したリモートＵＥとリレーＵＥの間のＳＬベアラの設定情報を用いてもよい。ＳＮにおける負荷状況などを考慮することが可能となる。
　このようにすることで、リモートＵＥとＮＷ間の通信に用いるリモートＵＥとリレーＵＥ間のＳＬベアラの設定を行うことが可能となる。リレーＵＥが２つのｇＮＢと接続するＤＣの設定にともなって、リモートＵＥとリレーＵＥ間のＳＬベアラ設定の修正を行ってもよい。リレーＵＥが２つのｇＮＢと接続するＤＣの設定に適したＳＬベアラの設定が可能となる。たとえば、ＤＣによるリレーＵＥとＮＷ間の通信容量の増大に適したリモートＵＥとリレーＵＥのＳＬベアラの設定としてもよい。リレーＵＥを介したリモートＵＥとＮＷ間の通信容量を増大可能となる。
　図４２は、実施の形態４について、リレーＵＥが２つのｇＮＢと接続するＤＣの設定方法の他の例を示すシーケンス図である。ＳＬベアラ設定の修正が、リレーＵＥへのＤＣ設定処理中に行われる場合について示している。図４２において、図４１と共通するステップについては同じステップ番号を付し、共通する説明を省略する。リモートＵＥとリレーＵＥ間のＳＬベアラの修正が必要な場合、ＭＮはリレーＵＥとリモートＵＥに対してＳＬベアラの設定を行う。
　ステップＳＴ４４０５で、ＭＮはリレーＵＥに対して、リモートＵＥとリレーＵＥ間のＳＬベアラの設定を送信する。ＳＬベアラの設定には、前述に開示したＳＬベアラの設定情報を含めるとよい。ＭＮからリレーＵＥへのＳＬベアラの設定は、図４１で開示した、ＭＮからリレーＵＥへのＤＣ設定と一緒に、あるいはＤＣ設定に含まれて、送信されてもよい。あるいは、別途行われてもよい。本例では、ＤＣ設定と一緒に、あるいはＤＣ設定に含まれて、同一のＲＲＣメッセージで送信される。ＳＬベアラ設定を受信したリレーＵＥは、リモートＵＥ間のＳＬ通信用のＳＬベアラの設定を可能とする。
　ステップＳＴ４４０６で、リレーＵＥはＭＮに対して、リモートＵＥ間のＳＬベアラ設定の完了メッセージを送信する。リレーＵＥからＭＮへのＳＬベアラ設定の完了は、図４１で開示した、リレーＵＥからＭＮへのＤＣ設定完了と一緒に、あるいはＤＣ設定完了に含まれて、送信されてもよい。あるいは、別途行われてもよい。本例では、ＤＣ設定完了と一緒に、あるいはＤＣ設定完了に含まれて、同一のＲＲＣメッセージで送信される。
　上記のステップＳＴ４４０５に続くステップＳＴ４５０１で、ＭＮはリモートＵＥに対して、リモートＵＥとリレーＵＥ間のＳＬベアラの設定を送信する。ＳＬベアラの設定には、前述に開示したＳＬベアラの設定情報を含めるとよい。ＭＮからリモートＵＥへのＳＬベアラの設定はＲＲＣシグナリングで送信される。ＲＲＣ　ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージを用いてもよい。ＳＬベアラ設定を受信したリモートＵＥは、リレーＵＥ間のＳＬ通信用のＳＬベアラの設定が可能となる。
　ステップＳＴ４５０２で、リモートＵＥはＭＮに対して、リレーＵＥ間のＳＬベアラ設定の完了メッセージを送信する。リモートＵＥからＭＮへのＳＬベアラ設定の完了はＲＲＣシグナリングで送信される。該送信ではＲＲＣ　ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎ　ｃｏｍｐｌｅｔｅメッセージを用いてもよい。
　このようにすることで、リモートＵＥとリレーＵＥ間のＳＬベアラの修正を行うことが可能となる。たとえば、リレーＵＥとＭＮ、ＳＮ間のＤＣ設定により、リモートＵＥとリレーＵＥ間のＳＬベアラ設定の修正が必要な場合に図４２の処理を行うとよい。ＤＣ設定に適したリモートＵＥとリレーＵＥ間のＳＬベアラの設定が可能となる。
　リレーＵＥが２つのｇＮＢと接続するＤＣの設定方法の他の例を開示する。ＭＮはリレーＵＥおよびリモートＵＥに対してＤＣの設定を行う。ＭＮは、リモートＵＥとの間のＲＢに対してＤＣの設定を行う。該ＲＢは、リモートＵＥとＭＮ間の通信用である。該ＲＢは、ＳＲＢ　ａｎｄ／ｏｒ　ＤＲＢであってもよい。ＳＲＢとしてＳＲＢ２であってもよい。ＭＮはリレーＵＥに対してＤＣ用のＵｕのＲＬＣベアラの設定を行う。
　リレーＵＥはＭＮとＲＲＣ接続状態とするとよい。リモートＵＥはＭＮとＲＲＣ接続状態とするとよい。ＤＣが設定されたリモートＵＥはＣ－ｐｌａｎｅにおいてＭＮを介してＣＮに接続する。
　ＭＮは、ＳＮに対して、リモートＵＥとＭＮ間通信用のＲＢに対するＳＮの追加要求を送信する。該追加要求はＸｎシグナリングを用いて送信するとよい。Ｓ－Ｎｏｄｅ　ａｄｄｉｔｉｏｎ　ｒｅｑｕｅｓｔメッセージを用いてもよい。
　本ＤＣの設定方法例におけるＳＮの追加要求に含める情報は、前述に開示したＳＮの追加要求に含める１７個の情報を適宜適用してもよい。
　ＳＮはリレーＵＥに対するＤＣ用の設定を行う。ＳＮはＭＮから受信した情報を用いて、リレーＵＥに対するＤＣ用の設定を行ってもよい。ＳＮはＭＮに対してＳＮの追加要求に対する応答メッセージを送信する。ＳＮがＤＣ設定を実施する場合、ＭＮに対してＳＮ追加要求肯定応答メッセージを送信する。Ｘｎシグナリングを用いて送信するとよい。ＳＮ追加要求肯定応答メッセージとしてＳ－Ｎｏｄｅ　ａｄｄｉｔｉｏｎ　ｒｅｑｕｅｓｔ　ａｃｋｎｏｗｌｅｄｇｅメッセージを用いてもよい。ＳＮがリレーＵＥに対してＤＣ設定を実施できなかった場合、ＭＮに対してＳＮ追加要求拒否応答メッセージを送信する。Ｘｎシグナリングを用いて送信するとよい。ＳＮ追加要求拒否応答メッセージとしてＳ－Ｎｏｄｅ　ａｄｄｉｔｉｏｎ　ｒｅｑｕｅｓｔ　ｒｅｊｅｃｔメッセージを用いてもよい。ＳＮ追加要求応答メッセージに含める情報は、前述に開示したＳＮ追加要求応答メッセージに含める情報を適宜適用してもよい。
　ＭＮはリレーＵＥに対してＤＣ用の設定を送信する。ＤＣ用設定に含める情報例を５つ開示する。
（１）ＲＢに関する情報。
（２）ＵｕのＲＬＣベアラに関する情報。
（３）ＳＮの識別子。
（４）ＡＤＰ設定に関する情報。
（５）（１）～（４）の組合せ。
　これら５つのＤＣ用設定に含める情報は、前述に開示した情報、具体的には、ＭＮがリレーＵＥに対してＤＣ用の設定を送信する際のＤＣ用設定に含める前述の４つの情報例を適宜適用するとよい。
　ただし、（１）は、リモートＵＥとＭＮ間通信用のＲＢに関する情報である。ＭＮはリレーＵＥに対してＤＣの設定としてＲＢの設定を行わない。ＤＣを設定するＲＢがＳＲＢの場合もＳＲＢの設定を行わない。ＤＣを設定するＲＢがＤＲＢの場合もＤＲＢの設定を行わない。（１）のＲＢに関する情報として、たとえば、ＲＢの識別子のみとしてもよい。
　（４）は、ＲＬＣとＰＤＣＰの間に構成されるＡＤＰの設定に関する情報である。ＡＤＰ設定に関する情報として、たとえば、ＡＤＰでのマッピング機能に関する情報、設定するＲＢに関する情報、接続するＲＬＣベアラに関する情報などがある。ＡＤＰの設定に関する情報は、ＵｕのＲＬＣベアラに関する情報に含めてもよい。ＡＤＰの設定に関する情報をＵｕのＲＬＣベアラに関する情報に含めることで、情報量を削減できる。このようにすることで、ＭＮはリレーＵＥに対してＡＤＰの設定が可能となる。
　ＭＮはリレーＵＥに対して、リモートＵＥとリレーＵＥ間のＳＬベアラの設定を行う。ＳＬベアラの設定は、ＳＬベアラの修正のための設定であってもよく、ＳＬベアラの修正を行ってもよい。ＳＬベアラの設定情報例として３つ開示する。
（１）ＳＬのＲＬＣベアラに関する情報。
（２）ＳＬのＡＤＰ設定に関する情報。
（３）（１）と（２）の組合せ。
　該ＳＬのＲＬＣベアラに関する情報は、前述に開示した情報、具体的には、ＭＮがリレーＵＥに対してリモートＵＥとリレーＵＥ間のＳＬベアラの設定を行う際に用いる、前述の「（２）ＳＬのＲＬＣベアラに関する情報」を適宜適用するとよい。
　該ＳＬのＡＤＰ設定に関する情報は、ＰＣ５　ＲＬＣとＰＣ５　ＰＤＣＰの間に構成されるＰＣ５　ＡＤＰの設定に関する情報である。ＰＣ５　ＡＤＰが構成される場合に設定されるとよい。ＡＤＰ設定に関する情報として、たとえば、ＡＤＰでのマッピング機能に関する情報、設定するＲＢに関する情報、接続するＳＬ　ＲＬＣベアラに関する情報などがある。ＰＣ５　ＡＤＰの設定に関する情報は、ＳＬのＲＬＣベアラに関する情報に含めてもよい。ＰＣ５　ＡＤＰの設定に関する情報をＳＬのＲＬＣベアラに関する情報に含めることで、情報量を削減できる。このようにすることで、ＭＮはリレーＵＥに対してＳＬのＡＤＰの設定が可能となる。
　ＭＮはリレーＵＥに対してＳＬ　ＲＢの設定は行わなくてよい。ＳＬ　ＲＢに関する情報を送信しなくてよい。ＳＬ　ＰＤＣＰ、ＳＬ　ＳＤＡＰの設定を行わないとしてもよい。ＭＮはリレーＵＥに対して、ＤＣ用として１つのＳＬ　ＲＬＣベアラの設定を行う。
　ＭＮはリレーＵＥに対するＤＣ用の設定　ａｎｄ／ｏｒ　リモートＵＥとリレーＵＥ間のＳＬベアラの設定を行う場合、ＳＮから受信したリレーＵＥとＳＮ間のＤＣのための設定　ａｎｄ／ｏｒ　リモートＵＥとリレーＵＥ間のＳＬベアラの設定情報を用いてもよい。ＳＮにおける負荷状況などを考慮することが可能となる。
　ＭＮはリモートＵＥに対してＤＣ用の設定を送信する。ＤＣ用設定に含める情報例を１つ開示する。
（１）ＲＢに関する情報。
　ＲＢに関する情報は、前述に開示した情報、具体的には、ＭＮがリレーＵＥに対してＤＣ用の設定を送信する際に用いる、前述の「（１）ＲＢに関する情報」を適宜適用するとよい。
　ＭＮはリモートＵＥに対してＲＢ設定を送信する。ＲＲＣシグナリングで送信してもよい。ＲＲＣＲｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージに含めて送信してもよい。ＲａｄｉｏＢｅａｒｅｒＣｏｎｆｉｇ情報に含めて送信してもよい。
　ＭＮはリモートＵＥに対して、リモートＵＥとリレーＵＥ間のＳＬベアラの設定を行う。ＳＬベアラの設定は、ＳＬベアラの修正のための設定であってもよく、ＳＬベアラの修正を行ってもよい。ＳＬベアラの設定情報例として３つ開示する。
（１）ＳＬのＲＬＣベアラに関する情報。
（２）ＳＬのＡＤＰ設定に関する情報。
（３）（１）と（２）の組合せ。
　ＳＬのＲＬＣベアラに関する情報、ＳＬのＡＤＰ設定に関する情報は、前述に開示した情報を適宜適用するとよい。
　ＭＮはリモートＵＥに対してＳＬ　ＲＢの設定は行わなくてよい。ＳＬ　ＲＢに関する情報を送信しなくてよい。ＳＬ　ＰＤＣＰ、ＳＬ　ＳＤＡＰの設定を行わないとしてもよい。ＭＮはリモートＵＥに対して、ＤＣ用として１つのＳＬ　ＲＬＣベアラの設定を行う。
　ＭＮはリモートＵＥに対するＤＣ用の設定　ａｎｄ／ｏｒ　リモートＵＥとリレーＵＥ間のＳＬベアラの設定を行う場合、ＳＮから受信したリレーＵＥとＳＮ間のＤＣのための設定　ａｎｄ／ｏｒ　リモートＵＥとリレーＵＥ間のＳＬベアラの設定情報を用いてもよい。ＳＮにおける負荷状況などを考慮することが可能となる。
　ＤＣ設定の種類がＳＮ終端の場合、ＰＤＵセッションの修正を行ってもよい。該修正では、ＭＮとＣＮ間でＰＤＵセッション修正処理が行われる。ＰＤＵセッションの修正は、前述に開示した方法を適宜適用するとよい。
　リモートＵＥとＮＷ間のデータ通信は、ＭＮ/ＳＮとリレーＵＥ間のＤＣ用ベアラ（ＲＬＣベアラ）およびリレーＵＥとリモートＵＥ間のＳＬベアラを用いて行われる。
　前述に開示したＤＣの設定方法は、リレーＵＥでＤＣ用ＲＬＣベアラとＳＬベアラとがマッピングされる場合に適用してもよい。たとえば、前述の図３９で開示したプロトコル例に適用してもよい。
　リレーＵＥが２つのｇＮＢと接続するＤＣの設定方法の他の例におけるシーケンス例として、前述の図４２で開示したシーケンス例を適宜適用してもよい。
　リレーＵＥが２つのｇＮＢと接続するＤＣの設定方法の他の例を開示する。ＭＮはリレーＵＥおよびリモートＵＥに対してＤＣの設定を行う。ＭＮは、リモートＵＥとの間のＲＢに対してＤＣの設定を行う。該ＲＢは、リモートＵＥとＭＮ間の通信用である。該ＲＢは、ＳＲＢ　ａｎｄ／ｏｒ　ＤＲＢであってもよい。ＳＲＢとしてＳＲＢ２であってもよい。
　ＭＮはリレーＵＥに対してＤＣ用のＵｕのＲＬＣベアラの設定を行う。
　ＭＮは、リレーＵＥとリモートＵＥ間のＤＣ用のＳＬベアラを設定する。ＤＣ用のＳＬベアラは２つのＳＬベアラとしてもよい。該２つのＳＬベアラは、ＭＮ用のＳＬベアラとＳＮ用のＳＬベアラとしてもよい。
　リレーＵＥはＭＮとＲＲＣ接続状態とするとよい。リモートＵＥはＭＮとＲＲＣ接続状態とするとよい。ＤＣが設定されたリモートＵＥはＣ－ｐｌａｎｅにおいてＭＮを介してＣＮに接続する。
　ＭＮは、ＳＮに対して、リモートＵＥとＭＮ間通信用のＲＢに対するＳＮの追加要求を送信する。該追加要求はＸｎシグナリングを用いて送信するとよい。Ｓ－Ｎｏｄｅ　ａｄｄｉｔｉｏｎ　ｒｅｑｕｅｓｔメッセージを用いてもよい。
　本ＤＣの設定方法例におけるＳＮの追加要求に含める情報は、前述に開示したＳＮの追加要求に含める１７個の情報を適宜適用してもよい。
　ＳＮはリレーＵＥに対するＤＣ用の設定を行う。ＳＮはＭＮから受信した情報を用いて、リレーＵＥに対するＤＣ用の設定を行ってもよい。ＳＮはＭＮに対してＳＮの追加要求に対する応答メッセージを送信する。ＳＮがＤＣ設定を実施する場合、ＭＮに対してＳＮ追加要求肯定応答メッセージを送信する。Ｘｎシグナリングを用いて送信するとよい。ＳＮ追加要求肯定応答メッセージとしてＳ－Ｎｏｄｅ　ａｄｄｉｔｉｏｎ　ｒｅｑｕｅｓｔ　ａｃｋｎｏｗｌｅｄｇｅメッセージを用いてもよい。ＳＮがリレーＵＥに対してＤＣ設定を実施できなかった場合、ＭＮに対してＳＮ追加要求拒否応答メッセージを送信する。Ｘｎシグナリングを用いて送信するとよい。ＳＮ追加要求拒否応答メッセージとしてＳ－Ｎｏｄｅ　ａｄｄｉｔｉｏｎ　ｒｅｑｕｅｓｔ　ｒｅｊｅｃｔメッセージを用いてもよい。ＳＮ追加要求応答メッセージに含める情報は、前述に開示したＳＮ追加要求応答メッセージに含める情報を適宜適用してもよい。
　ＭＮはリレーＵＥに対してＤＣ用の設定を送信する。ＤＣ用設定に含める情報は、前述に開示した情報を適宜適用するとよい。
　ＭＮはリレーＵＥに対して、リモートＵＥとリレーＵＥ間のＳＬベアラの設定を行う。ＳＬベアラの設定は、ＳＬベアラの修正のための設定であってもよく、ＳＬベアラの修正を行ってもよい。ＳＬベアラの設定情報は、前述に開示した情報を適宜適用するとよい。
　ＳＬのＲＬＣベアラは一つとしてもよい。あるいは、複数のＳＬのＲＬＣベアラとしてもよい。ＤＣ用のＳＬベアラの設定として、２つのＳＬのＲＬＣベアラの設定を行ってもよい。その場合、ＤＣ用として２つのＳＬのＲＬＣベアラに関する情報とするとよい。ＤＣ用の２つのＳＬのＲＬＣベアラはＭＮ用のＳＬのＲＬＣベアラとＳＮ用のＳＬのＲＬＣベアラとしてもよい。
　ＳＬ　ＡＤＰは一つとしてもよい。あるいは、複数のＳＬ　ＡＤＰとしてもよい。ＤＣ用のＳＬベアラの設定として、２つのＳＬ　ＡＤＰの設定を行ってもよい。その場合、ＤＣ用として２つのＳＬ　ＡＤＰ設定に関する情報とするとよい。ＤＣ用の２つのＳＬ　ＡＤＰはＭＮ用のＳＬ　ＡＤＰとＳＮ用のＳＬ　ＡＤＰとしてもよい。
　ＳＬベアラの設定をＤＣ用設定に含めてもよい。ＳＬベアラの設定情報をＤＣ用設定情報に含めてもよい。
　ＭＮはリレーＵＥに対してＳＬ　ＲＢの設定は行わなくてよい。ＳＬ　ＲＢに関する情報を送信しなくてよい。ＳＬ　ＰＤＣＰ、ＳＬ　ＳＤＡＰの設定を行わないとしてもよい。ＭＮはリレーＵＥに対して、ＤＣ用として２つのＳＬ　ＲＬＣベアラの設定を行う。
　ＭＮはリレーＵＥに対するＤＣ用の設定　ａｎｄ／ｏｒ　リモートＵＥとリレーＵＥ間のＳＬベアラの設定を行う場合、ＳＮから受信したリレーＵＥとＳＮ間のＤＣのための設定　ａｎｄ／ｏｒ　リモートＵＥとリレーＵＥ間のＳＬベアラの設定情報を用いてもよい。ＳＮにおける負荷状況などを考慮することが可能となる。
　ＭＮはリモートＵＥに対してＤＣ用の設定を送信する。ＤＣ用設定に含める情報は、前述に開示した情報を適宜適用するとよい。
　ＭＮはリモートＵＥに対して、リモートＵＥとリレーＵＥ間のＳＬベアラの設定を行う。ＳＬベアラの設定は、ＳＬベアラの修正のための設定であってもよく、ＳＬベアラの修正を行ってもよい。ＳＬベアラの設定情報は、前述に開示した情報を適宜適用するとよい。
　ＳＬのＲＬＣベアラは一つとしてもよい。あるいは、複数のＳＬのＲＬＣベアラとしてもよい。ＤＣ用のＳＬベアラの設定として、２つのＳＬのＲＬＣベアラの設定を行ってもよい。その場合、ＤＣ用として２つのＳＬのＲＬＣベアラに関する情報とするとよい。ＤＣ用の２つのＳＬのＲＬＣベアラはＭＮ用のＳＬのＲＬＣベアラとＳＮ用のＳＬのＲＬＣベアラとしてもよい。
　ＳＬ　ＡＤＰは一つとしてもよい。あるいは、複数のＳＬ　ＡＤＰとしてもよい。ＤＣ用のＳＬベアラの設定として、２つのＳＬ　ＡＤＰの設定を行ってもよい。その場合、ＤＣ用として２つのＳＬ　ＡＤＰ設定に関する情報とするとよい。ＤＣ用の２つのＳＬ　ＡＤＰはＭＮ用のＳＬ　ＡＤＰとＳＮ用のＳＬ　ＡＤＰとしてもよい。
　ＳＬベアラの設定をＤＣ用設定に含めてもよい。ＳＬベアラの設定情報をＤＣ用設定情報に含めてもよい。
　ＭＮはリモートＵＥに対してＳＬ　ＲＢの設定は行わなくてよい。ＳＬ　ＲＢに関する情報を送信しなくてよい。ＳＬ　ＰＤＣＰ、ＳＬ　ＳＤＡＰの設定を行わないとしてもよい。ＭＮはリモートＵＥに対して、ＤＣ用として２つのＳＬ　ＲＬＣベアラの設定を行う。
　ＭＮはリモートＵＥに対するＤＣ用の設定　ａｎｄ／ｏｒ　リモートＵＥとリレーＵＥ間のＳＬベアラの設定を行う場合、ＳＮから受信したリレーＵＥとＳＮ間のＤＣのための設定　ａｎｄ／ｏｒ　リモートＵＥとリレーＵＥ間のＳＬベアラの設定情報を用いてもよい。ＳＮにおける負荷状況などを考慮することが可能となる。
　ＤＣ設定の種類がＳＮ終端の場合、ＰＤＵセッションの修正を行ってもよい。該修正では、ＭＮとＣＮ間でＰＤＵセッション修正処理が行われる。ＰＤＵセッションの修正は、前述に開示した方法を適宜適用するとよい。
　リモートＵＥとＮＷ間のデータ通信は、ＭＮ/ＳＮとリレーＵＥ間のＤＣ用ベアラ（ＲＬＣベアラ）およびリレーＵＥとリモートＵＥ間のＤＣ用の２つのＳＬ　ＲＬＣベアラを用いて行われる。
　前述に開示したＤＣの設定方法は、リモートＵＥでＤＣが終端される場合に適用してもよい。たとえば、前述の図４０で開示したプロトコル例に適用してもよい。
　リレーＵＥが２つのｇＮＢと接続するＤＣの設定方法の他の例におけるシーケンス例として、前述の図４２で開示したシーケンス例を適宜適用してもよい。
　リレーＵＥが２つのｇＮＢと接続するＤＣの設定方法の他の例を開示する。リレーＵＥがＤＣの終端となる場合のＤＣ設定方法と、リモートＵＥがＤＣの終端となる場合のＤＣ設定方法とを組合せてもよい。
　ＭＮはリレーＵＥに対してＤＣ用の設定を行う。これにより、ＭＮとリレーＵＥ間の一つ以上のＤＣ用ベアラが、リレーＵＥとリモートＵＥ間の一つのＳＬベアラにマッピングされる。次に、ＭＮはリモートＵＥに対してＤＣ用の設定を行う。また、ＭＮはリレーＵＥとリモートＵＥ間のＤＣ用の２つのＳＬベアラを設定する。これにより、ＭＮとリレーＵＥ間のＭＮおよびＳＮのＲＬＣベアラがリレーＵＥとリモートＵＥ間のＭＮおよびＳＮのＳＬ　ＲＬＣベアラにマッピングされる。リレーＵＥはＰＤＵレイヤで該マッピングを行ってもよい。
　ＭＮからリモートＵＥに対して、ＲＢの修正が必要な場合、ＲＢの設定を実施してもよい。たとえば、ＲＢを、スプリットベアラに修正するような場合にＲＢの設定を実施してもよい。ＰＤＣＰ設定をスプリットベアラ用に修正してもよい。
　このようにすることで、リモートＵＥとＮＷ間のデータ通信が、ＭＮ/ＳＮとリレーＵＥ間のＤＣ用ベアラ（ＲＬＣベアラ）およびリレーＵＥとリモートＵＥ間のＤＣ用の２つのＳＬ　ＲＬＣベアラを用いて行われる。
　リレーＵＥが２つのｇＮＢと接続するＤＣの設定方法の他の例を開示する。リレーＵＥでＤＣ用ＲＬＣベアラとＳＬベアラとがマッピングされる場合のＤＣ設定方法と、リモートＵＥがＤＣの終端となる場合のＤＣ設定方法とを組合せてもよい。
　ＭＮはリレーＵＥに対してＤＣ用の設定を行う。ＭＮはリモートＵＥに対してＤＣ用の設定を行う。これにより、ＭＮとリレーＵＥ間の一つ以上のＤＣ用のＲＬＣベアラが、リレーＵＥとリモートＵＥ間の一つのＳＬ　ＲＬＣベアラにマッピングされる。次に、ＭＮはリモートＵＥに対してＤＣ用の設定を行う。また、ＭＮはリレーＵＥとリモートＵＥ間のＤＣ用の２つのＳＬベアラを設定する。これにより、ＭＮとリレーＵＥ間のＭＮおよびＳＮのＲＬＣベアラがリレーＵＥとリモートＵＥ間のＭＮおよびＳＮのＳＬ　ＲＬＣベアラにマッピングされる。リレーＵＥはＡＤＰレイヤで該マッピングを行ってもよい。
　ＭＮからリモートＵＥに対して、ＲＢの修正が必要な場合、ＲＢの設定を実施してもよい。たとえば、ＲＢを、スプリットベアラに修正するような場合にＲＢの設定を実施してもよい。ＰＤＣＰ設定をスプリットベアラ用に修正してもよい。
　このようにすることで、リモートＵＥとＮＷ間のデータ通信が、ＭＮ/ＳＮとリレーＵＥ間のＤＣ用ベアラ（ＲＬＣベアラ）およびリレーＵＥとリモートＵＥ間のＤＣ用の２つのＳＬ　ＲＬＣベアラを用いて行われる。
　リレーＵＥがＤＣの終端となる場合のＤＣ設定方法と、リモートＵＥがＤＣの終端となる場合のＤＣ設定方法とを組合せた場合、あるいは、リレーＵＥでＤＣ用ＲＬＣベアラとＳＬベアラとがマッピングされる場合のＤＣ設定方法と、リモートＵＥがＤＣの終端となる場合のＤＣ設定方法とを組合せた場合の例におけるシーケンス例として、前述の図４１で開示したシーケンス例と図４２で開示したシーケンス例とを適宜適用してもよい。
　リレーＵＥがＤＣの終端となる場合のＤＣ設定方法と、リモートＵＥがＤＣの終端となる場合のＤＣ設定方法とを組合せることで、柔軟なＤＣ設定が可能となる。たとえば、リレーＵＥとリモートＵＥ間のＰＣ５通信において負荷が高い場合はリレーＵＥがＤＣの終端となる場合のＤＣ設定を行うなどとするとよい。柔軟なＤＣ設定が可能となる。
　このようにすることで、リレーＵＥを介したリモートＵＥとＮＷ間の間接通信においてＤＣの設定が可能となる。リレーＵＥを介したリモートＵＥとＮＷ間の間接通信において、複数のｇＮＢを用いた通信が可能となる。これにより、高速大容量化、低遅延化、高信頼性化などの、性能改善が図れる。
実施の形態５．
　本実施の形態５では、実施の形態４で述べた課題を解決する他の方法を開示する。
　リレーＵＥを介して行うリモートＵＥとＮＷ間の通信において、リモートＵＥが複数の基地局と接続する。該複数はたとえば２つであってもよい。リレーＵＥを介して行うリモートＵＥとＮＷ間の通信において、リモートＵＥが２つの基地局と接続する。リモートＵＥが、該２つの基地局を用いて、リレーＵＥを介して行うリモートＵＥとＮＷ間の通信におけるＤＣが設定されてもよい。リモートＵＥと基地局との接続は、直接接続であってもよいし、リレーＵＥを介した間接接続であってもよい。少なくとも一つのリレーＵＥを介した間接接続を含む。
　リモートＵＥとＮＷ間の通信のための無線ベアラに対して、リモートＵＥは複数のｇＮＢと接続する。該無線ベアラは、たとえば、ＳＲＢであってもよい。たとえば、ＳＲＢ２であってもよい。ＳＲＢ０、ＳＲＢ１は一つのｇＮＢを用いて通信することで、通信の確立処理を簡易にすることが可能となる。該無線ベアラは、たとえば、ＤＲＢであってもよい。データ通信用のベアラの通信品質の向上が図れる。
　図４３は、実施の形態５について、リレーＵＥを介したリモートＵＥとＮＷ間の通信において、リモートＵＥが２つのｇＮＢと接続する場合の一例を示す概念図である。図４３に示す例では、リモートＵＥは、リレーＵＥ＃１を介してＭｇＮＢと接続し、ＳｇＮＢと直接接続する。ＭｇＮＢとリレーＵＥ＃１間はＵｕで接続され、リレーＵＥ＃１とリモートＵＥ間はＰＣ５で接続される。ＳｇＮＢとリモートＵＥ間はＵｕで接続される。ＭｇＮＢとＳｇＮＢはＸｎで接続される。リモートＵＥはＭｇＮＢとＲＲＣ接続状態とするとよい。リレーＵＥ＃１はＭｇＮＢとＲＲＣ接続状態とするとよい。
　図４４は、実施の形態５について、リレーＵＥを介したリモートＵＥとＮＷ間の通信において、リモートＵＥが２つのｇＮＢと接続する場合の他の例を示す概念図である。図４４に示す例では、リモートＵＥはＭｇＮＢと直接接続し、リレーＵＥ＃２を介してＳｇＮＢと接続する。ＭｇＮＢとリモートＵＥ間はＵｕで接続される。ＳｇＮＢとリレーＵＥ＃２間はＵｕで接続され、リレーＵＥ＃２とリモートＵＥ間はＰＣ５で接続される。ＭｇＮＢとＳｇＮＢはＸｎで接続される。リモートＵＥはＭｇＮＢとＲＲＣ接続状態とするとよい。リレーＵＥ＃２はＳｇＮＢとＲＲＣ接続状態とするとよい。
　図４５は、実施の形態５について、リレーＵＥを介したリモートＵＥとＮＷ間の通信において、リモートＵＥが２つのｇＮＢと接続する場合の他の例を示す概念図である。図４５に示す例では、リモートＵＥは、リレーＵＥ＃１を介してＭｇＮＢと接続し、リレーＵＥ＃２を介してＳｇＮＢと接続する。ＭｇＮＢとリレーＵＥ＃１間はＵｕで接続され、リレーＵＥ＃１とリモートＵＥ間はＰＣ５で接続される。ＳｇＮＢとリレーＵＥ＃２間はＵｕで接続され、リレーＵＥ＃２とリモートＵＥ間はＰＣ５で接続される。ＭｇＮＢとＳｇＮＢはＸｎで接続される。リモートＵＥはＭｇＮＢとＲＲＣ接続状態とするとよい。リレーＵＥ＃１はＭｇＮＢとＲＲＣ接続状態とするとよい。リレーＵＥ＃２はＳｇＮＢとＲＲＣ接続状態とするとよい。
　リレーＵＥを介したリモートＵＥとＮＷ間の通信において、リモートＵＥが２つのｇＮＢと接続する場合のプロトコル構成を開示する。図４６は、実施の形態５について、リレーＵＥを介したリモートＵＥとＮＷ間の通信において、リモートＵＥが２つのｇＮＢと接続する場合のプロトコルスタックを示す図である。リモートＵＥが、リレーＵＥ＃１を介してＭｇＮＢと接続し、ＳｇＮＢと直接接続する場合について示している。Ｕ－Ｐｌａｎｅについて示している。
　ＭＮとＳＮはＤＣ用のＵｕのプロトコルを有する。該Ｕｕのプロトコルは、ＳＤＡＰ、ＰＤＣＰ、ＲＬＣ、ＭＡＣ、ＰＨＹである。ＭＮ用のＵｕのプロトコルにおいて、ＲＬＣとＰＤＣＰの間にＡＤＰを構成する。ＡＤＰはＲＬＣのサブレイヤとして構成されてもよい。上述の実施の形態４と同様に、図４６では、ＤＣ用のベアラとして、ＭＮ終端ベアラおよびＳＮ終端ベアラの両方と、ＭＣＧベアラ、ＳＣＧベアラおよびスプリットベアラについて併せて示している。これらのベアラに対応したプロトコルが構成される。ＰＤＣＰは、ＭＮ終端ベアラ用に１つ、ＳＮ終端ベアラ用に１つ構成されてもよい。ＤＣの設定においてこれらのベアラの設定を可能としてもよい。
　リレーＵＥ＃１は、ＭＮ用のＵｕのプロトコルを有す。該Ｕｕのプロトコルは、ＲＬＣ、ＭＡＣ、ＰＨＹである。ＭＮ用のＵｕのプロトコルにおいて、ＲＬＣとＰＤＣＰの間にＡＤＰを構成する。ＡＤＰはＲＬＣのサブレイヤとして構成されてもよい。ＭＮ用のベアラは、ＭＣＧベアラあるいはスプリットベアラである。これらのベアラに対応したプロトコルが構成される。
　リレーＵＥ＃１は、リモートＵＥ間にＰＣ５のプロトコルを有す。該ＰＣ５のプロトコルをＭＮ用としてもよい。該ＰＣ５のプロトコルは、ＰＣ５　ＲＬＣ、ＰＣ５　ＭＡＣ、ＰＣ５　ＰＨＹである。ＰＣ５　ＲＬＣ（ＳＬ　ＲＬＣ）の上位にＰＣ５　ＡＤＰ（ＳＬ　ＡＤＰ）が構成されてもよい。ＰＣ５　ＡＤＰは、たとえばＵｕのベアラとＰＣ５のベアラ間のマッピング機能を有するとよい。ＰＣ５　ＡＤＰはＰＣ５　ＲＬＣのサブレイヤとして構成されてもよい。ＰＣ５　ＳＤＡＰ、ＰＣ５　ＰＤＣＰは無くてもよい。
　リモートＵＥはリレーＵＥ＃１間にＰＣ５のプロトコルを有す。該ＰＣ５のプロトコルをＭＮ用としてもよい。リレーＵＥ＃１と同様に、該ＰＣ５のプロトコルはＰＣ５　ＲＬＣ、ＰＣ５　ＭＡＣ、ＰＣ５　ＰＨＹである。ＰＣ５　ＲＬＣの上位にＰＣ５　ＡＤＰが構成されてもよい。ＰＣ５　ＳＤＡＰ、ＰＣ５　ＰＤＣＰは無くてもよい。また、リモートＵＥはＳＮとの間にＵｕのプロトコルを有す。該Ｕｕのプロトコルは、ＲＬＣ、ＭＡＣ、ＰＨＹである。ＳＮ用のベアラは、ＳＣＧベアラあるいはスプリットベアラである。また、リモートＵＥは、ＭＮ　ａｎｄ／ｏｒ　ＳＮ間にＵｕのプロトコルを有す。該Ｕｕのプロトコルは、ＤＣ用のＳＤＡＰ、ＰＤＣＰである。リモートＵＥで、ＭＮ用のＰＣ５のＰＤＣＰあるいはＡＤＰとＵｕのＰＤＣＰが接続され、ＳＮ用のＵｕのＲＬＣとＵｕのＰＤＣＰが接続される。ＰＤＣＰは、ＭＮ終端ベアラ用に１つ、ＳＮ終端ベアラ用に１つ構成されてもよい。リモートＵＥでＤＣが終端される。
　ベアラについて開示する。ＭＮとリモートＵＥ間で、ＲＢが設定される。該ＲＢにおいて、ＭＮとリレーＵＥ＃１間でＭＮ用のベアラが設定される。ＭＮ用ベアラは、ＭＣＧベアラあるいはスプリットベアラである。該ＭＣＧベアラあるいはスプリットベアラはＲＬＣベアラとするとよい。ＲＬＣチャネルであってもよい。リレーＵＥ＃１とリモートＵＥ間で１つのＳＬベアラが設定される。該ＳＬベアラは、ＭＮ用のＳＬ　ＲＬＣベアラとするとよい。ＳＬ　ＲＬＣチャネルであってもよい。ＳＮとリモートＵＥ間でＳＮ用のベアラが設定される。ＳＮ用のベアラは、ＳＣＧベアラあるいはスプリットベアラである。該ＳＣＧベアラあるいはスプリットベアラはＲＬＣベアラとするとよい。ＲＬＣチャネルであってもよい。
　ＮＷからリモートＵＥへの通信におけるベアラマッピングに関して開示する。ＭＮとＳＮは、ＮＷからリモートＵＥへの通信において、ＮＷとリモートＵＥ間のＲＢを、ＤＣ用のＵｕのＲＬＣベアラにマッピングする機能を有する。該ＤＣ用のＵｕのＲＬＣベアラとして、ＭＣＧベアラあるいはＳＣＧベアラあるいはスプリットベアラがある。リレーＵＥ＃１に接続されるリモートＵＥは１つに限らず複数であってもよい。リモートＵＥとＮＷ間のＲＢは１つに限らず複数であってもよい。
　ＭＮにおいて、リレーＵＥ＃１に接続される１つまたは複数のリモートＵＥのＲＢ　ａｎｄ／ｏｒ　リモートＵＥとＮＷ間の１つまたは複数のＲＢを、ＤＣ用のＵｕのＲＬＣベアラにマッピングしてもよい。前述の機能は、ＭＮに構成されるＵｕのＡＤＰが有してもよい。ＡＤＰに、ＤＣが設定される場合と設定されない場合の機能を集約してもよい。この場合、ＭＮの構成を容易にできる。
　ＭＮは、ＮＷからリモートＵＥへの通信において、リモートＵＥの識別子とリモートＵＥとＮＷ間のＲＢの識別子とを付加してもよい。ＲＢ　ＩＤは、ＲＢがＳＲＢの場合、ＳＲＢ　ＩＤであってもよい。ＲＢ　ＩＤは、ＲＢがＤＲＢの場合、ＤＲＢ　ＩＤであってもよい。このようにすることで、リレーＵＥ＃１が、送信先のリモートＵＥ、リモートＵＥとＮＷ間通信用のＲＢを認識可能となる。
　ＭＮは、ＮＷからリモートＵＥへの通信において、ＤＣに用いるベアラについての情報を付加してもよい。ＤＣに用いるベアラについての情報として、たとえば、ベアラの終端を示す識別子　ａｎｄ／ｏｒ　ベアラの種類を示す識別子　ａｎｄ／ｏｒ　ＭＮ用かＳＮ用かを示す識別子などがある。このようにすることで、リレーＵＥ＃１またはリモートＵＥが、ＤＣに用いるベアラの終端や種類などを認識可能となる。
　前述の付加機能は、ＭＮに構成されるＵｕのＡＤＰが有してもよい。ＡＤＰに、ＤＣが設定される場合と設定されない場合の機能を集約してもよい。この場合、ＭＮの構成を容易にできる。
　リレーＵＥ＃１は、ＮＷからリモートＵＥへの通信において、ＭＮ用のＵｕのＲＬＣベアラをＭＮ用のＰＣ５のＲＬＣベアラにマッピングする機能を有する。該マッピングに、ＭＮのＡＤＰで付加されたリモートＵＥ識別子、ＲＢ識別子を用いてもよい。該マッピングに、ＭＮで付加されたＤＣに用いるベアラについての情報を用いてもよい。このようにすることで、リレーＵＥ＃１で、ＭＮ用のＭＣＧベアラあるいはスプリットベアラを、ＭＮ用のＰＣ５のＲＬＣベアラにマッピングすることが可能となる。前述の機能は、リレーＵＥ＃１に構成されるＵｕのＡＤＰが有してもよい。ＡＤＰに、ＤＣが設定される場合と設定されない場合の機能を集約してもよい。この場合、リレーＵＥ＃１の構成を容易にできる。
　リレーＵＥ＃１は、ＰＣ５のＲＬＣベアラにマッピングする際に、ＭＮで付加されたリモートＵＥ識別子、ＲＢ識別子、ＤＣに用いるベアラについての情報などの一部または全部を削除してもよい。リモートＵＥへのＰＣ５のＲＬＣベアラへのマッピングにおいて、該識別子や情報の一部または全部を付加しなくてもよい。
　リモートＵＥは、ＮＷからリモートＵＥへの通信において、ＭＮ用のＰＣ５のＲＬＣベアラとＳＮ用のＵｕのＲＬＣベアラとをＮＷとリモートＵＥ間のＲＢにマッピングする機能を有する。該マッピングに、ＭＮで付加されたリモートＵＥ識別子、ＲＢ識別子を用いてもよい。該マッピングに、ＭＮで付加されたＤＣに用いるベアラについての情報を用いてもよい。
　リモートＵＥからＮＷへの通信におけるベアラマッピングに関して開示する。リモートＵＥは、リモートＵＥからＮＷへの通信において、ＮＷとリモートＵＥ間のＲＢを、ＤＣ用のＰＣ５のＲＬＣベアラとＵｕのＲＬＣベアラにマッピングする機能を有する。該ＤＣ用のＰＣ５のＲＬＣベアラはＭＮ用のＰＣ５のＲＬＣベアラである。ＭＮ用のＰＣ５のＲＬＣベアラとして、ＭＣＧベアラあるいはスプリットベアラがある。該ＤＣ用のＵｕのＲＬＣベアラはＳＮ用のＵｕのＲＬＣベアラである。ＳＮ用のＵｕのＲＬＣベアラとして、ＳＣＧベアラあるいはスプリットベアラがある。リモートＵＥは、ＮＷからリモートＵＥへの通信において、リモートＵＥとＮＷ間のＲＢの識別子と基地局の識別子とを付加してもよい。該基地局は複数であってもよい。たとえば、リレーＵＥが複数の基地局に接続するような場合に付加してもよい。該基地局が複数か否かを示す情報あるいは該基地局の識別子が複数か否かを示す情報を付加してもよい。基地局の識別子として、ＭＮ　ａｎｄ／ｏｒ　ＳＮの識別子としてもよい。たとえば、ＤＣが設定される場合に適用してもよい。このようにすることで、リレーＵＥが複数の基地局に送信するような場合も、送信先の基地局、リモートＵＥとＮＷ間通信用のＲＢを認識可能となる。
　リモートＵＥは、リモートＵＥからＮＷへの通信において、ＤＣに用いるベアラについての情報を付加してもよい。ＤＣに用いるベアラについての情報として、たとえば、ベアラの終端を示す識別子　ａｎｄ／ｏｒ　ベアラの種類を示す識別子　ａｎｄ／ｏｒ　ＭＮ用かＳＮ用かを示す識別子などがある。このようにすることで、リレーＵＥ、ＭＮまたはＳＮが、ＤＣに用いるベアラの終端や種類などを認識可能となる。
　前述の付加機能は、リモートＵＥに構成されるＳＬのＡＤＰが有してもよい。ＳＬ　ＡＤＰに、ＤＣが設定される場合と設定されない場合の機能を集約してもよい。リモートＵＥの構成を容易にできる。
　リレーＵＥ＃１は、リモートＵＥからＮＷへの通信において、ＭＮ用のＰＣ５のＲＬＣベアラをＭＮ用のＵｕのＲＬＣベアラにマッピングする機能を有する。該ＭＮ用のＵｕのＲＬＣベアラとして、ＭＣＧベアラあるいはスプリットベアラがある。ＰＣ５のＭＣＧベアラをＵｕのＭＣＧベアラにマッピングする。ＰＣ５のスプリットベアラをＵｕのスプリットベアラにマッピングする。該マッピングに、リモートＵＥで付加された基地局の識別子、ＲＢ識別子などを用いてもよい。該マッピングに、リモートＵＥで付加されたＤＣに用いるベアラについての情報などを用いてもよい。リレーＵＥ＃１に接続されるリモートＵＥは１つに限らず複数であってもよい。前述の機能は、リレーＵＥ＃１に構成されるＵｕのＡＤＰが有してもよい。ＡＤＰに、ＤＣが設定される場合と設定されない場合の機能を集約してもよい。この場合、リレーＵＥ＃１の構成を容易にできる。
　リレーＵＥ＃１は、ＵｕのＲＬＣベアラにマッピングする際に、リモートＵＥで付加されたリモートＵＥ識別子、ＲＢ識別子、ＤＣに用いるベアラについての情報などの一部または全部を削除してもよい。ＭＮへのＵｕのＲＬＣベアラへのマッピングにおいて、該識別子や情報の一部または全部を付加しなくてもよい。
　リレーＵＥ＃１は、リモートＵＥからＮＷへの通信において、リモートＵＥの識別子とリモートＵＥとＮＷ間のＲＢの識別子とを付加してもよい。ＲＢ　ＩＤは、ＲＢがＳＲＢの場合、ＳＲＢ　ＩＤであってもよい。ＲＢ　ＩＤは、ＲＢがＤＲＢの場合、ＤＲＢ　ＩＤであってもよい。このようにすることで、ＭＮが、送信元のリモートＵＥ、リモートＵＥとＮＷ間通信用のＲＢを認識可能となる。前述の付加機能は、リレーＵＥ＃１に構成されるＭＮ用のＵｕのＡＤＰが有してもよい。ＡＤＰに、ＤＣが設定される場合と設定されない場合の機能を集約してもよい。この場合、リレーＵＥの構成を容易にできる。
　ＭＮとＳＮは、リモートＵＥからＮＷへの通信において、ＤＣ用のＵｕのＲＬＣベアラをＮＷとリモートＵＥ間のＲＢにマッピングする機能を有する。リレーＵＥ＃１に接続されるリモートＵＥは１つに限らず複数であってもよい。リモートＵＥとＮＷ間のＲＢは１つに限らず複数であってもよい。ＤＣ用のＵｕのＲＬＣベアラを、リレーＵＥ＃１に接続される１つまたは複数のリモートＵＥのＲＢ　ａｎｄ／ｏｒ　リモートＵＥとＮＷ間の１つまたは複数のＲＢにマッピングしてもよい。該マッピングに、リモートＵＥまたはリレーＵＥ＃１のＭＮ用のＵｕのＡＤＰで付加されたリモートＵＥ識別子、ＲＢ識別子、ＤＣに用いるベアラについての情報などを用いてもよい。このようにすることで、ＭＮとＳＮで、ＤＣ用のＭＣＧベアラあるいはＳＣＧベアラあるいはスプリットベアラを、リモートＵＥとＮＷ間通信用のＲＢのＰＤＣＰに転送することが可能となる。前述の機能は、ＭＮとＳＮに構成されるＵｕのＡＤＰが有してもよい。ＡＤＰに、ＤＣが設定される場合と設定されない場合の機能を集約してもよい。この場合、ＭＮとＳＮの構成を容易にできる。
　Ｃ－Ｐｌａｎｅのプロトコルについては、ＭＮ、リモートＵＥにおけるＳＤＡＰの代わりにＲＲＣを設ければよい。ＳＲＢに対応したＲＲＣを設けるとよい。ＳＲＢにＤＣが設定される場合はＭＮ終端ベアラのみが設定されてもよい。ＳＲＢのＤＣが可能となる。
　このようにすることで、２つのｇＮＢと接続したリモートＵＥが、リレーＵＥを介してＮＷ間の通信を可能とする。
　リレーＵＥを介して行うリモートＵＥとＮＷ間の通信において、リモートＵＥが複数のｇＮＢと接続するための設定方法を開示する。本実施の形態では、リモートＵＥが２つのｇＮＢと接続するＤＣの設定方法を開示する。
　リモートＵＥが、リレーＵＥ＃１を介してＭｇＮＢと接続し、ＳｇＮＢと直接接続する場合について開示する。
　ＭＮはリモートＵＥに対してＤＣの設定を行う。ＭＮは、リモートＵＥとの間のＲＢに対してＤＣの設定を行う。該ＲＢは、リモートＵＥとＭＮ間の通信用であってもよい。該ＲＢは、ＳＲＢ　ａｎｄ／ｏｒ　ＤＲＢでもよい。ＳＲＢとしてＳＲＢ２であってもよい。
　ＭＮはリモートＵＥに対してＤＣ用のＵｕのＲＬＣベアラの設定を行う。該ＤＣ用のＵｕのＲＬＣベアラは、ＳＮとの間のＲＬＣベアラでもよい。
　ＭＮは、ＭＮとリレーＵＥ＃１との間のＤＣ用のＵｕのＲＬＣベアラの設定を行う。ＭＮとリモートＵＥ間のＲＢに対するＤＣ設定に用いる。ＤＣ用のＵｕのＲＬＣベアラとして、既存のＵｕのＲＬＣベアラから修正がなければ、新たな設定を行わなくてもよい。
　ＭＮは、リレーＵＥ＃１とリモートＵＥ間のＤＣ用のＳＬベアラを設定する。ＤＣ用のＳＬベアラは１つのＳＬベアラとしてもよい。該ＳＬベアラは、ＭＮ用のＳＬベアラとしてもよい。該ＳＬベアラは、ＳＬ　ＲＬＣベアラでもよい。
　リレーＵＥ＃１はＭＮとＲＲＣ接続状態とするとよい。リモートＵＥはＭＮとＲＲＣ接続状態とするとよい。また、ＭＮは、リモートＵＥがＭＮとＲＲＣ接続状態において、リモートＵＥに対してＤＣ設定を開始する、としてもよい。ＤＣが設定されたリモートＵＥはＣ－ｐｌａｎｅにおいてＭＮを介してＣＮに接続する。
　ＭＮは、ＳＮに対して、リモートＵＥとＭＮ間通信用のＲＢに対するＳＮの追加要求を送信する。該追加要求はＸｎシグナリングを用いて送信するとよい。Ｓ－Ｎｏｄｅ　ａｄｄｉｔｉｏｎ　ｒｅｑｕｅｓｔメッセージを用いてもよい。
　ＳＮの追加要求に含める情報は、前述に開示したＳＮの追加要求に含める１７個の情報例を適宜適用するとよい。該情報例におけるリレーＵＥをリレーＵＥ＃１におきかえるとよい。
　このようにすることで、ＭＮはＳＮに対して、ＤＣ用にＳＮ追加要求を送信することが可能となる。また、ＳＮは、ＭＮからＳＮ追加要求を受信することで、たとえば、どのリモートＵＥに対するＤＣかなどを認識可能となる。ＳＮはＭＮから受信した情報を用いて、リモートＵＥに対するＤＣ用の設定を行ってもよい。
　ＳＮはリレーＵＥに対するＤＣ用の設定を行う。ＳＮはＭＮに対してＳＮの追加要求に対する応答メッセージを送信する。ＳＮがＤＣ設定を実施する場合、ＭＮに対してＳＮ追加要求肯定応答メッセージを送信する。Ｘｎシグナリングを用いて送信するとよい。ＳＮ追加要求肯定応答メッセージとしてＳ－Ｎｏｄｅ　ａｄｄｉｔｉｏｎ　ｒｅｑｕｅｓｔ　ａｃｋｎｏｗｌｅｄｇｅメッセージを用いてもよい。ＳＮがリレーＵＥに対してＤＣ設定を実施できなかった場合、ＭＮに対してＳＮ追加要求拒否応答メッセージを送信する。Ｘｎシグナリングを用いて送信するとよい。ＳＮ追加要求拒否応答メッセージとしてＳ－Ｎｏｄｅ　ａｄｄｉｔｉｏｎ　ｒｅｑｕｅｓｔ　ｒｅｊｅｃｔメッセージを用いてもよい。ＳＮ追加要求応答メッセージに含める情報は、実施の形態４に開示したＳＮ追加要求応答メッセージに含める情報を適宜適用してもよい。
　ＭＮはリレーＵＥ＃１に対してＤＣ用の設定を送信する。ＤＣ用設定に含める情報例を５つ開示する。
（１）ＲＢに関する情報。
（２）ＵｕのＲＬＣベアラに関する情報。
（３）ＳＮの識別子。
（４）ＡＤＰ設定に関する情報。
（５）（１）～（４）の組合せ。
　これら５つのＤＣ用設定に含める情報は、前述に開示したＤＣ用設定に含める情報例を適宜適用するとよい。
　ただし、（１）は、リモートＵＥとＭＮ間通信用のＲＢに関する情報である。ＭＮはリレーＵＥ＃１に対してＤＣの設定としてＲＢの設定を行わない。ＤＣを設定するＲＢがＳＲＢの場合もＳＲＢ設定を行わない。ＤＣを設定するＲＢがＤＲＢの場合もＤＲＢの設定を行わない。（１）のＲＢに関する情報として、たとえば、ＲＢの識別子のみとしてもよい。
　（２）は、ＤＣ用のＵｕのＲＬＣベアラに関する情報である。ＭＮはリレーＵＥ＃１に対してＳＣＧ用の設定は行わなくてもよい。本例のＤＣにおいてリレーＵＥ＃１はＳＮと接続しないため、リレーＵＥ＃１はＳＣＧに関する情報を受信しなくてもよい。
　（３）についても同様に、ＭＮはリレーＵＥ＃１に対してＳＮの識別子を送信しなくてもよい。本例のＤＣにおいてリレーＵＥ＃１はＳＮと接続しないため、リレーＵＥ＃１はＳＮの識別子を受信しなくてもよい。
　ＭＮはリレーＵＥ＃１に対して、リモートＵＥとリレーＵＥ＃１間のＳＬベアラの設定を行う。ＳＬベアラの設定は、ＳＬベアラの修正のための設定であってもよく、ＳＬベアラの修正を行ってもよい。ＳＬベアラの設定情報例として３つ開示する。
（１）ＳＬのＲＬＣベアラに関する情報。
（２）ＳＬのＡＤＰ設定に関する情報。
（３）（１）と（２）の組合せ。
　ＳＬベアラの設定情報は、前述に開示したＳＬベアラの設定情報例を適宜適用するとよい。
　ＭＮはリレーＵＥ＃１に対してＳＬ　ＲＢの設定は行わなくてよい。ＳＬ　ＲＢに関する情報を送信しなくてよい。ＳＬ　ＰＤＣＰ、ＳＬ　ＳＤＡＰの設定を行わないとしてもよい。ＭＮはリレーＵＥ＃１に対して、ＤＣ用として１つのＳＬベアラの設定を行ってもよい。該ＤＣ用のＳＬベアラの設定は、ＭＮ用のＳＬベアラの設定でもよい。
　ＭＮはリレーＵＥ＃１に対するＤＣ用の設定　ａｎｄ／ｏｒ　リモートＵＥとリレーＵＥ＃１間のＳＬベアラの設定を行う場合、ＳＮから受信したリモートＵＥとＳＮとの間のＤＣのための設定情報を用いてもよい。ＳＮにおける負荷状況などを考慮することが可能となる。
　ＭＮはリモートＵＥに対してＤＣ用の設定を送信する。ＤＣ用設定に含める情報例を５つ開示する。
（１）ＲＢに関する情報。
（２）ＵｕのＲＬＣベアラに関する情報。
（３）ＳＮの識別子。
（４）ＡＤＰ設定に関する情報。
（５）（１）～（４）の組合せ。
　これら５つのＤＣ用設定に含める情報は、前述に開示したＤＣ用設定に含める情報例を適宜適用するとよい。
　ただし、（２）は、ＤＣ用のＵｕのＲＬＣベアラに関する情報である。ＭＮはリモートＵＥに対してＭＣＧ用の設定は行わなくてもよい。ＤＣにおいてリモートＵＥはＭＮとリレーＵＥ＃１を介して接続するため、リモートＵＥはＭＣＧに関する情報を受信しなくてもよい。
　ＭＮはリモートＵＥに対して、リモートＵＥとリレーＵＥ＃１間のＳＬベアラの設定を行う。ＳＬベアラの設定は、ＳＬベアラの修正のための設定であってもよく、ＳＬベアラの修正を行ってもよい。ＳＬベアラの設定情報例として３つ開示する。
（１）ＳＬのＲＬＣベアラに関する情報。
（２）ＳＬのＡＤＰ設定に関する情報。
（３）（１）と（２）の組合せ。
　ＳＬベアラの設定情報は、前述に開示したＳＬベアラの設定情報例を適宜適用するとよい。
　ＳＬのＲＬＣベアラは１つとしてもよい。ＤＣ用のＳＬベアラの設定として、ＭＮ用のＳＬのＲＬＣベアラを設定してもよい。
　ＳＬのＡＤＰ設定は１つとしてもよい。ＤＣ用のＳＬのＡＤＰ設定として、ＭＮ用のＳＬのＡＤＰを設定してもよい。
　ＳＬベアラの設定をＤＣ用設定に含めてもよい。ＳＬベアラの設定情報をＤＣ用設定情報に含めてもよい。
　ＭＮはリモートＵＥに対してＳＬ　ＲＢの設定は行わなくてよい。ＳＬ　ＲＢに関する情報を送信しなくてよい。ＳＬ　ＰＤＣＰ、ＳＬ　ＳＤＡＰの設定を行わないとしてもよい。ＭＮはリモートＵＥに対して、ＤＣ用として１つのＳＬベアラの設定を行ってもよい。該ＤＣ用のＳＬベアラの設定は、ＭＮ用のＳＬベアラの設定でもよい。
　ＭＮはリモートＵＥに対するＤＣ用の設定　ａｎｄ／ｏｒ　リモートＵＥとリレーＵＥ＃１間のＳＬベアラの設定を行う場合、ＳＮから受信したリモートＵＥとＳＮとの間のＤＣのための設定情報を用いてもよい。ＳＮにおける負荷状況などを考慮することが可能となる。
　ＤＣ設定の種類がＳＮ終端の場合、ＰＤＵセッションの修正を行ってもよい。該修正では、ＭＮとＣＮ間でＰＤＵセッション修正処理が行われる。ＰＤＵセッションの修正は、前述に開示した方法を適宜適用するとよい。
　リモートＵＥとＮＷ間のデータ通信は、リレーＵＥ＃１を介したリモートＵＥとＭＮ間のＭＣＧベアラ、リモートＵＥとＳＮ間のＳＣＧベアラ、リレーＵＥ＃１を介したリモートＵＥとＭＮ間と、リモートＵＥとＳＮ間とのスプリットベアラを用いて行われる。
　図４７は、実施の形態５について、リモートＵＥが２つのｇＮＢと接続するＤＣの設定方法例を示すシーケンス図である。リモートＵＥが、リレーＵＥ＃１を介してＭｇＮＢと接続し、ＳｇＮＢと直接接続する場合について開示する。図４７において、図４１と共通するステップについては同じステップ番号を付し、共通する説明を省略する。ステップＳＴ５００１で、リモートＵＥ、リレーＵＥ＃１、ＭＮ、ＵＰＦ間でデータ通信が行われる。
　ＭＮはリモートＵＥに対してＤＣを設定することを決定する。たとえば、ＭＮはリモートＵＥに対して周辺ｇＮＢのメジャメントを設定する。リモートＵＥは設定されたメジャメントを行いＭＮに対してメジャメント結果を報告する。あわせて、ＭＮはリモートＵＥに対して周辺リレーＵＥのメジャメントを設定してもよい。リモートＵＥは設定されたメジャメントを行いＭＮに対してメジャメント結果を報告してもよい。ＭＮは該メジャメント結果からＤＣに用いるＳＮを決定する。
　ステップＳＴ４４０２で、ＭＮは、ＤＣに用いることに決定したＳＮに対してＳＮ追加要求メッセージを送信する。ＭＮはＳＮに対してリモートＵＥに対するＤＣのためのＳＮとしての追加を要求する。ＳＮ追加要求メッセージは、Ｘｎシグナリングを用いて送信される。ＳＮ追加要求メッセージとしてＳ－Ｎｏｄｅ　ａｄｄｉｔｉｏｎ　ｒｅｑｕｅｓｔメッセージを用いてもよい。ＳＮ追加要求メッセージには、前述に開示したＳＮの追加要求の情報例を含めるとよい。
　ＭＮからＳＮ追加要求メッセージを受信したＳＮは、ＳＮ追加要求の情報から、ＤＣ設定を行うリモートＵＥ、ＤＣ設定を行うリモートＵＥとＮＷ間の通信に関する情報、要求されるベアラ終端、要求されるＤＣ用ベアラ種類等を認識し、リモートＵＥに対してＤＣ用の設定を行う。ＤＣ用の設定は、たとえば、ＳＮとリモートＵＥ間のＲＲＣ設定であってもよい。ステップＳＴ４４０３で、ＳＮはＭＮに対して、ＳＮ追加要求応答メッセージを送信する。本例では肯定応答を送信する。ＳＮ追加要求応答メッセージとしてＳ－Ｎｏｄｅ　ａｄｄｉｔｉｏｎ　ｒｅｑｕｅｓｔ　ａｃｋｎｏｗｌｅｄｇｅメッセージを用いてもよい。ＳＮ追加要求応答メッセージに、ＳＮとリモートＵＥ間のＲＲＣ設定を含めてもよい。ＳＮ追加要求応答メッセージを受信したＭＮは、ＳＮがリモートＵＥに対してＤＣ設定を実施したことを認識する。また、ＭＮは、ＳＮとリモートＵＥ間のＲＲＣ設定を認識する。
　ステップＳＴ４４０４で、ＭＮはＳＮに対してＸｎ－Ｕアドレスインジケーションメッセージを通知する。たとえば、ＭＮは、ＭＮとＳＮ間のＤＣに用いるアドレスを設定し、ステップＳＴ４４０４でＳＮに対して送信する。これにより、ＭＮとＳＮ間でＤＣに用いるアドレスを共有し、ＭＮとＳＮ間のデータ送受信を可能とする。
　ステップＳＴ５００５で、ＭＮはリレーＵＥ＃１に対して、ＤＣ用の設定とＳＬベアラの設定を送信する。ＳＬベアラの設定をＤＣ用の設定と一緒に送信してもよいし、ＳＬベアラの設定をＤＣ用の設定に含めて送信してもよい。あるいは、ＤＣ用の設定とＳＬベアラの設定を個別に送信してもよい。該送信にはＲＲＣシグナリングを用いる。ＲＲＣ　ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージを用いて設定を行ってもよい。ＤＣ用設定には、前述に開示したＤＣ用設定の情報例を含めるとよい。ＳＬベアラの設定には、前述に開示したＳＬベアラの設定情報を含めるとよい。リレーＵＥ＃１はＭＮからＤＣ用設定とＳＬベアラ設定とを受信することで、ＭＮとリレーＵＥ＃１間のＤＣ用設定およびリモートＵＥとリレーＵＥ＃１間のＳＬベアラの設定が可能となる。該設定は修正であってもよい。
　これらの設定を行ったリレーＵＥ＃１は、ステップＳＴ５００７で、ＭＮに対して、ＤＣ設定応答およびＳＬベアラ設定応答を送信する。本例では肯定応答とする。該送信にはＲＲＣシグナリングを用いる。ＲＲＣ　ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎ　ｃｏｍｐｌｅｔｅメッセージを用いてもよい。ＤＣ設定応答およびＳＬベアラ設定応答を受信したＭＮは、リレーＵＥ＃１がＤＣ設定およびＳＬベアラ設定を完了したことを認識する。
　上記のステップＳＴ５００５に続くステップＳＴ５００６で、ＭＮはリモートＵＥに対して、ＤＣ用の設定とＳＬベアラの設定を送信する。ＳＬベアラの設定をＤＣ用の設定と一緒に送信してもよいし、ＳＬベアラの設定をＤＣ用の設定に含めて送信してもよい。あるいは、ＤＣ用の設定とＳＬベアラの設定を個別に送信してもよい。該送信にはＲＲＣシグナリングを用いる。ＲＲＣ　ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージを用いてもよい。ＤＣ用設定には、前述に開示したＤＣ用設定の情報例を含めるとよい。ＤＣ用設定の情報のＳＣＧに関する設定として、ＳＮから受信したＲＲＣ設定情報を用いてもよい。ＳＬベアラの設定には、前述に開示したＳＬベアラの設定情報を含めるとよい。リモートＵＥはＭＮからＤＣ用設定とＳＬベアラ設定を受信することで、ＭＮとリモートＵＥ間のＤＣ用設定およびリモートＵＥとリレーＵＥ＃１間のＳＬベアラの設定が可能となる。該設定は修正であってもよい。
　これらの設定を行ったリモートＵＥは、ステップＳＴ５００８で、ＭＮに対して、ＤＣ設定応答およびＳＬベアラ設定応答を送信する。本例では肯定応答とする。該送信ではＲＲＣシグナリングを用いる。ＲＲＣ　ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎ　ｃｏｍｐｌｅｔｅメッセージを用いてもよい。ＤＣ設定応答およびＳＬベアラ設定応答を受信したＭＮは、リモートＵＥがＤＣ設定およびＳＬベアラ設定を完了したことを認識する。
　ステップＳＴ４４０７で、ＭＮはＳＮに対してＳＮ設定完了メッセージを送信する。該送信にはＸｎシグナリングを用いる。Ｓ－Ｎｏｄｅ　ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎ　ｃｏｍｐｌｅｔｅメッセージを送信してもよい。ＳＮは該メッセージを受信することにより、ＭＮおよびリモートＵＥがＤＣ用のＳＮ設定を完了したことを認識する。
　ステップＳＴ４４０８で、リモートＵＥはＭＮとの通信を維持したままＳＮに対してＲＡ処理を開始し通信を行う。
　ステップＳＴ４４０９でＭＮはＳＮに対してＳＮ状態転送を行い、ステップＳＴ４４１０でＵＰＦからのデータをＳＮに転送する。ＳＮ終端ベアラの場合、ＵＰＦとｇＮＢ間のパスをＭＮからＳＮに変更する必要がある。この場合、ステップＳＴ４４２０のパスアップデート処理を実施する。この結果、ステップＳＴ５０１５で、リモートＵＥ、ＳＮ、ＵＰＦ間でデータ通信が行われる。
　このようにすることで、リモートＵＥ、リレーＵＥ＃１を介したＭＮ、ＳＮ間でＤＣが行われる。たとえば、ＳＮ終端ＳＣＧベアラの場合、リモートＵＥ、ＳＮ、ＵＰＦ間でデータ通信が行われる。
　たとえば、ＭＮ終端ＳＣＧベアラの場合、リモートＵＥ、ＳＮ、リレーＵＥ＃１を介したＭＮ、ＵＰＦ間でデータ通信が行われる。たとえば、ＳＮ終端ＭＣＧベアラの場合、リモートＵＥ、リレーＵＥ＃１を介したＭＮ、ＳＮ、ＵＰＦ間でデータ通信が行われる。たとえば、ＭＮ終端スプリットベアラの場合、リモートＵＥ、ＳＮ、リレーＵＥを介したＭＮ、ＵＰＦ間でデータ通信が行われる。たとえば、ＳＮ終端スプリットベアラの場合、リモートＵＥ、リレーＵＥ＃１を介したＭＮ、ＳＮ、ＵＰＦ間でデータ通信が行われる。
　ＳＮとリモートＵＥ間でＲＲＣシグナリングを行ってもよい。該ＲＲＣシグナリングにＳＲＢ３を用いて行ってもよい。ステップＳＴ４４０８でリモートＵＥとＳＮとで通信開始後、ＳＲＢ３を用いてリモートＵＥはＳＮに、ＳＮはリモートＵＥにＲＲＣメッセージを送信してもよい。ＳＲＢ３を用いるＲＲＣメッセージは、たとえば、ＳＮに関するメッセージであってもよい。たとえば、ＳＣＧベアラの設定変更、ＳＮメジャメント報告、ＳＣＧベアラのファイラに関する情報送信、などのメッセージであってもよい。このようにすることで、ＭＮを介さずＳＮとリモートＵＥ間で直接ＲＲＣメッセージを通信できるので、シグナリング量の削減、低遅延化が図れる。
　このようにすることで、リモートＵＥが、リレーＵＥ＃１を介してＭｇＮＢと接続し、ＳｇＮＢと直接接続するＤＣの設定が可能となる。
　リレーＵＥを介したリモートＵＥとＮＷ間の通信において、リモートＵＥが２つのｇＮＢと接続する場合のプロトコル構成の他の方法を開示する。図４８は、実施の形態５について、リレーＵＥを介したリモートＵＥとＮＷ間の通信において、リモートＵＥが２つのｇＮＢと接続する場合のプロトコルスタックの他の構成方法を示す図である。リモートＵＥが、ＭｇＮＢと直接接続し、リレーＵＥ＃２を介してＳｇＮＢと接続する場合について示している。Ｕ－Ｐｌａｎｅについて示している。
　ＭＮとＳＮはＤＣ用のＵｕのプロトコルを有する。該Ｕｕのプロトコルは、ＳＤＡＰ、ＰＤＣＰ、ＲＬＣ、ＭＡＣ、ＰＨＹである。ＳＮ用のＵｕのプロトコルにおいて、ＲＬＣとＰＤＣＰの間にＡＤＰを構成する。ＡＤＰはＲＬＣのサブレイヤとして構成されてもよい。図４８では、ＤＣ用のベアラとして、ＭＮ終端ベアラ、ＳＮ終端ベアラの両方を示している。また、ＭＣＧベアラ、ＳＣＧベアラおよびスプリットベアラについて併せて示している。これらのベアラに対応したプロトコルが構成される。ＰＤＣＰは、ＭＮ終端ベアラ用に１つ、ＳＮ終端ベアラ用に１つ構成されてもよい。ＤＣの設定においてこれらのベアラの設定を可能としてもよい。
　リレーＵＥ＃２は、ＳＮ用のＵｕのプロトコルを有す。該Ｕｕのプロトコルは、ＲＬＣ、ＭＡＣ、ＰＨＹである。ＳＮ用のＵｕのプロトコルにおいて、ＲＬＣとＰＤＣＰの間にＡＤＰを構成する。ＡＤＰはＲＬＣのサブレイヤとして構成されてもよい。ＭＮ用のベアラは、ＭＣＧベアラあるいはスプリットベアラである。これらのベアラに対応したプロトコルが構成される。
　リレーＵＥ＃２は、リモートＵＥ間にＰＣ５のプロトコルを有す。該ＰＣ５のプロトコルをＳＮ用としてもよい。該ＰＣ５のプロトコルは、ＰＣ５　ＲＬＣ、ＰＣ５　ＭＡＣ、ＰＣ５　ＰＨＹである。ＰＣ５　ＲＬＣの上位にＰＣ５　ＡＤＰが構成されてもよい。ＰＣ５　ＡＤＰは、たとえばＵｕのベアラとＰＣ５のベアラ間のマッピング機能を有するとよい。ＰＣ５　ＡＤＰはＰＣ５　ＲＬＣのサブレイヤとして構成されてもよい。ＰＣ５　ＳＤＡＰ、ＰＣ５　ＰＤＣＰは無くてもよい。
　リモートＵＥはリレーＵＥ＃２間にＰＣ５のプロトコルを有す。該ＰＣ５のプロトコルをＳＮ用としてもよい。リレーＵＥ＃２と同様に、該ＰＣ５のプロトコルはＰＣ５　ＲＬＣ、ＰＣ５　ＭＡＣ、ＰＣ５　ＰＨＹである。ＰＣ５　ＲＬＣの上位にＰＣ５　ＡＤＰが構成されてもよい。ＰＣ５　ＳＤＡＰ、ＰＣ５　ＰＤＣＰは無くてもよい。また、リモートＵＥはＭＮとの間にＵｕのプロトコルを有す。該Ｕｕのプロトコルは、ＲＬＣ、ＭＡＣ、ＰＨＹである。ＭＮ用として、ＳＣＧベアラあるいはスプリットベアラ用である。また、リモートＵＥは、ＭＮ　ａｎｄ／ｏｒ　ＳＮ間にＵｕのプロトコルを有す。該Ｕｕのプロトコルは、ＤＣ用のＳＤＡＰ、ＰＤＣＰである。リモートＵＥで、ＳＮ用のＰＣ５のＰＤＣＰあるいはＡＤＰとＵｕのＰＤＣＰが接続され、ＭＮ用のＵｕのＲＬＣとＵｕのＰＤＣＰが接続される。ＰＤＣＰは、ＭＮ終端ベアラ用に１つ、ＳＮ終端ベアラ用に１つ構成されてもよい。リモートＵＥでＤＣが終端される。
　ベアラについて開示する。ＭＮとリモートＵＥ間で、ＲＢが設定される。該ＲＢにおいて、ＳＮとリレーＵＥ＃２間でＳＮ用のベアラが設定される。ＳＮ用のベアラは、ＳＣＧベアラあるいはスプリットベアラである。該ＳＣＧベアラあるいはスプリットベアラはＲＬＣベアラとするとよい。ＲＬＣチャネルであってもよい。リレーＵＥ＃２とリモートＵＥ間で１つのＳＬベアラが設定される。該ＳＬベアラは、ＳＮ用のＳＬ　ＲＬＣベアラとするとよい。ＳＬ　ＲＬＣチャネルであってもよい。ＭＮとリモートＵＥ間でＭＮ用ベアラが設定される。ＭＮ用ベアラは、ＭＣＧベアラあるいはスプリットベアラである。該ＭＣＧベアラあるいはスプリットベアラはＲＬＣベアラとするとよい。ＲＬＣチャネルであってもよい。
　ＮＷからリモートＵＥへの通信におけるベアラマッピングに関して開示する。ＭＮとＳＮは、ＮＷからリモートＵＥへの通信において、ＮＷとリモートＵＥ間のＲＢを、ＤＣ用のＵｕのＲＬＣベアラにマッピングする機能を有する。該ＤＣ用のＵｕのＲＬＣベアラとして、ＭＣＧベアラあるいはＳＣＧベアラあるいはスプリットベアラがある。リレーＵＥ＃２に接続されるリモートＵＥは１つに限らず複数であってもよい。リモートＵＥとＮＷ間のＲＢは１つに限らず複数であってもよい。
　リレーＵＥ＃２に接続される１つまたは複数のリモートＵＥのＲＢ　ａｎｄ／ｏｒ　リモートＵＥとＮＷ間の１つまたは複数のＲＢを、ＤＣ用のＵｕのＲＬＣベアラにマッピングしてもよい。前述の機能は、ＳＮに構成されるＵｕのＡＤＰが有してもよい。ＡＤＰに、ＤＣが設定される場合と設定されない場合の機能を集約してもよい。この場合、ＳＮの構成を容易にできる。
　ＳＮは、ＮＷからリモートＵＥへの通信において、リモートＵＥの識別子とリモートＵＥとＮＷ間のＲＢの識別子とを付加してもよい。ＲＢ　ＩＤは、ＲＢがＳＲＢの場合、ＳＲＢ　ＩＤであってもよい。ＲＢ　ＩＤは、ＲＢがＤＲＢの場合、ＤＲＢ　ＩＤであってもよい。このようにすることで、リレーＵＥ＃２が、送信先のリモートＵＥ、リモートＵＥとＮＷ間通信用のＲＢを認識可能となる。
　ＳＮは、ＮＷからリモートＵＥへの通信において、ＤＣに用いるベアラについての情報を付加してもよい。ＤＣに用いるベアラについての情報として、たとえば、ベアラの終端を示す識別子　ａｎｄ／ｏｒ　ベアラの種類を示す識別子　ａｎｄ／ｏｒ　ＭＮ用かＳＮ用かを示す識別子などがある。このようにすることで、リレーＵＥ＃２またはリモートＵＥが、ＤＣに用いるベアラの終端や種類などを認識可能となる。
　前述の付加機能は、ＳＮに構成されるＵｕのＡＤＰが有してもよい。ＡＤＰに、ＤＣが設定される場合と設定されない場合の機能を集約してもよい。この場合、ＳＮの構成を容易にできる。
　リレーＵＥ＃２は、ＮＷからリモートＵＥへの通信において、ＳＮ用のＵｕのＲＬＣベアラをＳＮ用のＰＣ５のＲＬＣベアラにマッピングする機能を有する。該マッピングに、ＳＮのＡＤＰで付加されたリモートＵＥ識別子、ＲＢ識別子を用いてもよい。該マッピングに、ＳＮで付加されたＤＣに用いるベアラについての情報を用いてもよい。このようにすることで、リレーＵＥ＃２で、ＳＮ用のＳＣＧベアラあるいはスプリットベアラを、ＳＮ用のＰＣ５のＲＬＣベアラにマッピングすることが可能となる。前述の機能は、リレーＵＥ＃２に構成されるＵｕのＡＤＰが有してもよい。ＡＤＰに、ＤＣが設定される場合と設定されない場合の機能を集約してもよい。この場合、リレーＵＥ＃２の構成を容易にできる。
　リレーＵＥ＃２は、ＰＣ５のＲＬＣベアラにマッピングする際に、ＳＮで付加されたリモートＵＥ識別子、ＲＢ識別子、ＤＣに用いるベアラについての情報などの一部または全部を削除してもよい。リモートＵＥへのＰＣ５のＲＬＣベアラへのマッピングにおいて、該識別子や情報の一部または全部を付加しなくてもよい。
　リモートＵＥは、ＮＷからリモートＵＥへの通信において、ＭＮ用のＵｕのＲＬＣベアラとＳＮ用のＰＣ５のＲＬＣベアラとをＮＷとリモートＵＥ間のＲＢにマッピングする機能を有する。該マッピングに、ＳＮで付加されたリモートＵＥ識別子、ＲＢ識別子を用いてもよい。該マッピングに、ＳＮで付加されたＤＣに用いるベアラについての情報を用いてもよい。
　リモートＵＥからＮＷへの通信におけるベアラマッピングに関して開示する。リモートＵＥは、リモートＵＥからＮＷへの通信において、ＮＷとリモートＵＥ間のＲＢを、ＤＣ用のＵｕのＲＬＣベアラとＰＣ５のＲＬＣベアラにマッピングする機能を有する。該ＤＣ用のＵｕのＲＬＣベアラはＭＮ用のＵｕのＲＬＣベアラである。ＭＮ用のＵｕのＲＬＣベアラとして、ＭＣＧベアラあるいはスプリットベアラがある。該ＤＣ用のＰＣ５のＲＬＣベアラはＳＮ用のＰＣ５のＲＬＣベアラである。ＳＮ用のＰＣ５のＲＬＣベアラとして、ＳＣＧベアラあるいはスプリットベアラがある。リモートＵＥは、ＮＷからリモートＵＥへの通信において、リモートＵＥとＮＷ間のＲＢの識別子と基地局の識別子とを付加してもよい。該基地局は複数であってもよい。たとえば、リレーＵＥが複数の基地局に接続するような場合に付加してもよい。該基地局が複数か否かを示す情報あるいは該基地局の識別子が複数か否かを示す情報を付加してもよい。基地局の識別子として、ＭＮ　ａｎｄ／ｏｒ　ＳＮの識別子としてもよい。たとえば、ＤＣが設定される場合に適用してもよい。このようにすることで、リレーＵＥが複数の基地局に送信するような場合も、送信先の基地局、リモートＵＥとＮＷ間通信用のＲＢを認識可能となる。
　リモートＵＥは、リモートＵＥからＮＷへの通信において、ＤＣに用いるベアラについての情報を付加してもよい。ＤＣに用いるベアラについての情報として、たとえば、ベアラの終端を示す識別子　ａｎｄ／ｏｒ　ベアラの種類を示す識別子　ａｎｄ／ｏｒ　ＭＮ用かＳＮ用かを示す識別子などがある。このようにすることで、リレーＵＥ、ＭＮまたはＳＮが、ＤＣに用いるベアラの終端や種類などを認識可能となる。
　前述の付加機能は、リモートＵＥに構成されるＳＬのＡＤＰが有してもよい。ＳＬ　ＡＤＰに、ＤＣが設定される場合と設定されない場合の機能を集約してもよい。リモートＵＥの構成を容易にできる。
　リレーＵＥ＃２は、リモートＵＥからＮＷへの通信において、ＳＮ用のＰＣ５のＲＬＣベアラをＳＮ用のＵｕのＲＬＣベアラにマッピングする機能を有する。該ＳＮ用のＵｕのＲＬＣベアラとして、ＳＣＧベアラあるいはスプリットベアラがある。ＰＣ５のＳＣＧベアラをＵｕのＳＣＧベアラにマッピングする。ＰＣ５のスプリットベアラをＵｕのスプリットベアラにマッピングする。該マッピングに、リモートＵＥで付加された基地局の識別子、ＲＢ識別子、ＤＣに用いるベアラについての情報などを用いてもよい。リレーＵＥ＃２に接続されるリモートＵＥは１つに限らず複数であってもよい。前述の機能は、リレーＵＥ＃２に構成されるＵｕのＡＤＰが有してもよい。ＡＤＰに、ＤＣが設定される場合と設定されない場合の機能を集約してもよい。この場合、リレーＵＥ＃２の構成を容易にできる。
　リレーＵＥ＃２は、ＵｕのＲＬＣベアラにマッピングする際に、リモートＵＥで付加されたリモートＵＥ識別子、ＲＢ識別子、ＤＣに用いるベアラについての情報などの一部または全部を削除してもよい。ＳＮへのＵｕのＲＬＣベアラへのマッピングにおいて、該識別子や情報の一部または全部を付加しなくてもよい。
　リレーＵＥ＃２は、リモートＵＥからＮＷへの通信において、リモートＵＥの識別子とリモートＵＥとＮＷ間のＲＢの識別子とを付加してもよい。ＲＢ　ＩＤは、ＲＢがＳＲＢの場合、ＳＲＢ　ＩＤであってもよい。ＲＢ　ＩＤは、ＲＢがＤＲＢの場合、ＤＲＢ　ＩＤであってもよい。このようにすることで、ＳＮが、送信元のリモートＵＥ、リモートＵＥとＮＷ間通信用のＲＢを認識可能となる。前述の付加機能は、リレーＵＥ＃２に構成されるＳＮ用のＵｕのＡＤＰが有してもよい。ＡＤＰに、ＤＣが設定される場合と設定されない場合の機能を集約してもよい。この場合、リレーＵＥ＃２の構成を容易にできる。
　ＭＮとＳＮは、リモートＵＥからＮＷへの通信において、ＤＣ用のＵｕのＲＬＣベアラをＮＷとリモートＵＥ間のＲＢにマッピングする機能を有する。リレーＵＥ＃２に接続されるリモートＵＥは１つに限らず複数であってもよい。リモートＵＥとＮＷ間のＲＢは１つに限らず複数であってもよい。ＤＣ用のＵｕのＲＬＣベアラを、リレーＵＥ＃２に接続される１つまたは複数のリモートＵＥのＲＢ　ａｎｄ／ｏｒ　リモートＵＥとＮＷ間の１つまたは複数のＲＢにマッピングしてもよい。該マッピングに、リモートＵＥまたはリレーＵＥ＃２のＳＮ用のＵｕのＡＤＰで付加されたリモートＵＥ識別子、ＲＢ識別子、ＤＣに用いるベアラについての情報などを用いてもよい。このようにすることで、ＭＮとＳＮで、ＤＣ用のＭＣＧベアラあるいはＳＣＧベアラあるいはスプリットベアラを、リモートＵＥとＮＷ間通信用のＲＢのＰＤＣＰに転送することが可能となる。前述の機能は、ＭＮとＳＮに構成されるＵｕのＡＤＰが有してもよい。ＡＤＰに、ＤＣが設定される場合と設定されない場合の機能を集約してもよい。この場合、ＭＮとＳＮの構成を容易にできる。
　Ｃ－Ｐｌａｎｅのプロトコルについては、ＭＮ、リモートＵＥにおけるＳＤＡＰの代わりにＲＲＣを設ければよい。ＳＲＢに対応したＲＲＣを設けるとよい。ＳＲＢにＤＣが設定される場合はＭＮ終端ベアラのみが設定されてもよい。ＳＲＢのＤＣが可能となる。
　このようにすることで、２つのｇＮＢと接続したリモートＵＥが、リレーＵＥを介してＮＷ間の通信を可能とする。
　リレーＵＥを介して行うリモートＵＥとＮＷ間の通信において、リモートＵＥが複数のｇＮＢと接続するための設定方法を開示する。本実施の形態では、リモートＵＥが２つのｇＮＢと接続するＤＣの設定方法を開示する。
　リモートＵＥが、ＭｇＮＢと直接接続し、リレーＵＥ＃２を介してＳｇＮＢと接続する場合について開示する。
　ＭＮはリモートＵＥに対してＤＣの設定を行う。ＭＮは、リモートＵＥとの間のＲＢに対してＤＣの設定を行う。該ＲＢは、リモートＵＥとＭＮ間の通信用であってもよい。該ＲＢは、ＳＲＢ　ａｎｄ／ｏｒ　ＤＲＢでもよい。ＳＲＢとしてＳＲＢ２であってもよい。
　ＭＮはリモートＵＥに対してＤＣ用のＵｕのＲＬＣベアラの設定を行う。該ＤＣ用のＵｕのＲＬＣベアラは、ＭＮとの間のＲＬＣベアラでもよい。
　ＭＮは、ＳＮとリレーＵＥ＃２との間のＤＣ用のＵｕのＲＬＣベアラの設定を行う。ＭＮとリモートＵＥ間のＲＢに対するＤＣ設定に用いる。ＤＣ用のＵｕのＲＬＣベアラとして、既存のＵｕのＲＬＣベアラから修正がなければ、新たな設定を行わなくてもよい。
　ＭＮは、リレーＵＥ＃２とリモートＵＥ間のＤＣ用のＳＬベアラを設定する。ＤＣ用のＳＬベアラは１つのＳＬベアラとしてもよい。該ＳＬベアラは、ＳＮ用のＳＬベアラとしてもよい。該ＳＬベアラは、ＳＬ　ＲＬＣベアラでもよい。
　リレーＵＥ＃２はＳＮとＲＲＣ接続状態とするとよい。リモートＵＥはＭＮとＲＲＣ接続状態とするとよい。また、ＭＮは、リモートＵＥがＭＮとＲＲＣ接続状態において、リモートＵＥに対してＤＣ設定を開始する、としてもよい。ＤＣが設定されたリモートＵＥはＣ－ｐｌａｎｅにおいてＭＮを介してＣＮに接続する。
　ＭＮは、ＳＮに対して、リモートＵＥとＭＮ間通信用のＲＢに対するＳＮの追加要求を送信する。該追加要求はＸｎシグナリングを用いて送信するとよい。Ｓ－Ｎｏｄｅ　ａｄｄｉｔｉｏｎ　ｒｅｑｕｅｓｔメッセージを用いてもよい。
　ＳＮの追加要求に含める情報は、前述に開示したＳＮの追加要求に含める１７個の情報例を適宜適用するとよい。該情報例におけるリレーＵＥをリレーＵＥ＃２におきかえるとよい。
　ただし、ＭＮとリモートＵＥはリレーＵＥ＃２を介さずに接続されるため、ＭＮとリレーＵＥ＃２間の設定情報は無くてもよい。たとえば、ＭＮはＳＮに対して、前述に開示したＳＮの追加要求に含める１７個の情報例のうち、（４）、（７）、（９）を送信しない。
　前述に開示したＳＮの追加要求に含める１７個の情報例のうち、（１）のリレーＵＥに関する情報は、ＳＮが、リモートＵＥとＤＣ設定を行うために、どのリレーＵＥを介するかを示す情報を含んでもよい。また、該リレーＵＥの設定に関する情報を含んでもよい。また、リモートＵＥによるリレーＵＥ＃２のメジャメント結果を含んでもよい。また、リレーＵＥ＃２によるＳＮのメジャメント結果を含んでもよい。
　このようにすることで、ＭＮはＳＮに対して、ＤＣ用にＳＮ追加要求を送信することが可能となる。また、ＳＮは、ＭＮからＳＮ追加要求を受信することで、たとえば、どのリモートＵＥに対するＤＣか、どのリレーＵＥを介してリモートＵＥと接続するか、などを認識可能となる。ＳＮはＭＮから受信した情報を用いて、リレーＵＥを介したリモートＵＥに対するＤＣ用の設定を行ってもよい。リレーＵＥを介したリモートＵＥに対するＤＣ用の設定は、ＳＮとリレーＵＥ間のＤＣ用の設定としてもよい。
　ＳＮはリレーＵＥを介したリモートＵＥに対するＤＣ用の設定を行う。ＳＮはＭＮに対してＳＮの追加要求に対する応答メッセージを送信する。ＳＮがＤＣ設定を実施する場合、ＭＮに対してＳＮ追加要求肯定応答メッセージを送信する。Ｘｎシグナリングを用いて送信するとよい。ＳＮ追加要求肯定応答メッセージとしてＳ－Ｎｏｄｅ　ａｄｄｉｔｉｏｎ　ｒｅｑｕｅｓｔ　ａｃｋｎｏｗｌｅｄｇｅメッセージを用いてもよい。ＳＮがリレーＵＥに対してＤＣ設定を実施できなかった場合、ＭＮに対してＳＮ追加要求拒否応答メッセージを送信する。Ｘｎシグナリングを用いて送信するとよい。ＳＮ追加要求拒否応答メッセージとしてＳ－Ｎｏｄｅ　ａｄｄｉｔｉｏｎ　ｒｅｑｕｅｓｔ　ｒｅｊｅｃｔメッセージを用いてもよい。ＳＮ追加要求応答メッセージに含める情報は、前述に開示したＳＮ追加要求応答メッセージに含める情報を適宜適用してもよい。
　ＳＮはリレーＵＥ＃２に対してＤＣ用の設定を送信する。ＤＣ用設定に含める情報例を５つ開示する。
（１）ＲＢに関する情報。
（２）ＵｕのＲＬＣベアラに関する情報。
（３）ＳＮの識別子。
（４）ＡＤＰ設定に関する情報。
（５）（１）～（４）の組合せ。
　これら５つのＤＣ用設定に含める情報は、前述に開示したＤＣ用設定に含める情報例を適宜適用するとよい。
　ただし、（１）は、リモートＵＥとＭＮ間通信用のＲＢに関する情報である。ＳＮはリレーＵＥ＃２に対してＤＣの設定としてＲＢの設定を行わない。ＤＣを設定するＲＢがＳＲＢの場合もＳＲＢ設定を行わない。ＤＣを設定するＲＢがＤＲＢの場合もＤＲＢの設定を行わない。（１）のＲＢに関する情報として、たとえば、ＲＢの識別子のみとしてもよい。
　（２）は、ＤＣ用のＵｕのＲＬＣベアラに関する情報である。ＳＮはリレーＵＥ＃２に対してＭＣＧ用の設定は行わなくてもよい。本例のＤＣにおいてリレーＵＥ＃２はＭＮと接続しないため、リレーＵＥ＃２はＭＣＧに関する情報を受信しなくてもよい。
　ＳＮはリレーＵＥ＃２に対して、リモートＵＥとリレーＵＥ＃２間のＳＬベアラの設定を行う。リモートＵＥとリレーＵＥ＃２間で既存のＳＬベアラがある場合は、該ＳＬベアラの修正を行ってもよい。ＳＬベアラの設定は、ＳＬベアラの修正のための設定であってもよい。ＳＬベアラの設定情報例として３つ開示する。
（１）ＳＬのＲＬＣベアラに関する情報。
（２）ＳＬのＡＤＰ設定に関する情報。
（３）（１）と（２）の組合せ。
　ＳＬベアラの設定情報は、前述に開示したＳＬベアラの設定情報例を適宜適用するとよい。
　ＳＮはリレーＵＥ＃２に対してＳＬ　ＲＢの設定は行わなくてよい。ＳＬ　ＲＢに関する情報を送信しなくてよい。ＳＬ　ＰＤＣＰ、ＳＬ　ＳＤＡＰの設定を行わないとしてもよい。ＳＮはリレーＵＥ＃２に対して、ＤＣ用として１つのＳＬベアラの設定を行ってもよい。該ＤＣ用のＳＬベアラの設定は、ＳＮ用のＳＬベアラの設定でもよい。
　ＭＮはリモートＵＥに対してＤＣ用の設定を送信する。ＤＣ用設定に含める情報例を５つ開示する。
（１）ＲＢに関する情報。
（２）ＵｕのＲＬＣベアラに関する情報。
（３）ＳＮの識別子。
（４）ＡＤＰ設定に関する情報。
（５）（１）～（４）の組合せ。
　これら５つのＤＣ用設定に含める情報は、前述に開示したＤＣ用設定に含める情報例を適宜適用するとよい。
　ただし、（２）は、ＤＣ用のＵｕのＲＬＣベアラに関する情報である。ＭＮはリモートＵＥに対してＳＣＧ用の設定は行わなくてもよい。ＤＣにおいてリモートＵＥはＳＮとリレーＵＥ＃２を介して接続するため、リモートＵＥはＳＣＧに関する情報を受信しなくてもよい。
　ＭＮはリモートＵＥに対して、リモートＵＥとリレーＵＥ＃２間のＳＬベアラの設定を送信する。リモートＵＥとリレーＵＥ＃２間で既存のＳＬベアラがある場合は、該ＳＬベアラの修正を行ってもよい。ＳＬベアラの設定は、ＳＬベアラの修正のための設定であってもよい。ＳＬベアラの設定情報例として３つ開示する。
（１）ＳＬのＲＬＣベアラに関する情報。
（２）ＳＬのＡＤＰ設定に関する情報。
（３）（１）と（２）の組合せ。
　ＳＬベアラの設定情報は、前述に開示したＳＬベアラの設定情報例を適宜適用するとよい。
　ＳＬのＲＬＣベアラは１つとしてもよい。ＤＣ用のＳＬベアラの設定として、ＳＮ用のＳＬのＲＬＣベアラを設定してもよい。
　ＳＬのＡＤＰ設定は１つとしてもよい。ＤＣ用のＳＬのＡＤＰ設定として、ＳＮ用のＳＬのＡＤＰを設定してもよい。
　ＳＬベアラの設定をＤＣ用設定に含めてもよい。ＳＬベアラの設定情報をＤＣ用設定情報に含めてもよい。
　ＭＮはリモートＵＥに対してＳＬ　ＲＢの設定は行わなくてよい。ＳＬ　ＲＢに関する情報を送信しなくてよい。ＳＬ　ＰＤＣＰ、ＳＬ　ＳＤＡＰの設定を行わないとしてもよい。ＭＮはリモートＵＥに対して、ＤＣ用として１つのＳＬベアラの設定を行ってもよい。該ＤＣ用のＳＬベアラの設定は、ＭＮ用のＳＬベアラの設定でもよい。
　ＭＮはリモートＵＥに対するＤＣ用の設定　ａｎｄ／ｏｒ　リモートＵＥとリレーＵＥ＃２間のＳＬベアラの設定を行う場合、ＳＮから受信したリレーＵＥ＃２とＳＮとの間のＤＣのための設定　ａｎｄ／ｏｒ　リモートＵＥとリレーＵＥ＃２間のＳＬベアラの設定情報を用いてもよい。ＳＮにおける負荷状況などを考慮することが可能となる。たとえば、ＭＮは、リモートＵＥとリレーＵＥ＃２間のＳＬベアラの設定情報については、ＳＮがリレーＵＥ＃２に送信したリモートＵＥとリレーＵＥ＃２間のＳＬベアラの設定情報と同じとしてもよい。リモートＵＥとリレーＵＥ＃２におけるＳＬベアラの設定が同じとなり、ＳＬ通信における誤動作を低減できる。
　ＭＮはリモートＵＥに対して、リレーＵＥ＃２に関する情報を送信してもよい。リレーＵＥ＃２に関する情報をリモートＵＥとリレーＵＥ＃２間のＳＬベアラの設定に含めてもよい。リレーＵＥ＃２に関する情報は、たとえば、リレーＵＥ＃２の識別子であってもよい。たとえば、リレーＵＥ＃２が接続するＳＮの識別子であってもよい。このようにすることで、リモートＵＥはＤＣのために接続するリレーＵＥ＃２を認識可能となる。
　ＭＮからＤＣ用のＳＬベアラの設定情報を受信したリモートＵＥは、リレーＵＥ＃２とのＰＣ５接続を確立する。リレーＵＥ＃２とＰＣ５接続を確立したリモートＵＥは、リレーＵＥ＃２との間でＤＣ用のＳＬベアラを設定する。リモートＵＥとＰＣ５接続を確立したリレーＵＥ＃２は、リモートＵＥとの間でＤＣ用のＳＬベアラを設定する。リモートＵＥはリレーＵＥ＃２に対してＳＬ　ＲＲＣ設定を通知してもよい。リレーＵＥ＃２はリモートＵＥに対してＳＬ　ＲＲＣ設定を通知してもよい。
　ＤＣ設定の種類がＳＮ終端の場合、ＰＤＵセッションの修正を行ってもよい。この場合、ＭＮとＣＮ間でＰＤＵセッション修正処理が行われる。ＰＤＵセッションの修正は、前述に開示した方法を適宜適用するとよい。
　リモートＵＥとＮＷ間のデータ通信は、リモートＵＥとＭＮ間のＭＣＧベアラ、リレーＵＥ＃２を介したリモートＵＥとＳＮ間のＳＣＧベアラ、リモートＵＥとＭＮ間とリレーＵＥ＃２を介したリモートＵＥとＳＮ間のスプリットベアラを用いて行われる。
　図４９は、実施の形態５について、リモートＵＥが２つのｇＮＢと接続するＤＣの設定方法例を示すシーケンス図である。リモートＵＥが、ＭｇＮＢと直接接続し、リレーＵＥ＃２を介してＳｇＮＢと接続する場合について開示する。図４９において、図４１と共通するステップについては同じステップ番号を付し、共通する説明を省略する。ステップＳＴ５２０１で、リモートＵＥ、ＭＮ、ＵＰＦ間でデータ通信が行われる。
　ＭＮはリモートＵＥに対してＤＣを設定することを決定する。たとえば、ＭＮはリモートＵＥに対して周辺ｇＮＢのメジャメントを設定する。リモートＵＥは設定されたメジャメントを行いＭＮに対してメジャメント結果を報告する。あわせて、ＭＮはリモートＵＥに対して周辺リレーＵＥのメジャメントを設定してもよい。リモートＵＥは設定されたメジャメントを行いＭＮに対してメジャメント結果を報告してもよい。
　リモートＵＥは、リレーＵＥのメジャメント結果の報告に、該リレーＵＥが接続するｇＮＢに関する情報を含めてもよい。たとえば、ｇＮＢの識別子を含めてもよい。このようにすることで、リモートＵＥからリレーＵＥのメジャメント結果の報告を受信したＭＮが、リレーＵＥと接続するｇＮＢを認識可能となる。
　ｇＮＢは、周辺ｇＮＢに対して、自ｇＮＢが接続するリレーＵＥの識別子を送信してもよい。ｇＮＢは、周辺ｇＮＢが接続するリレーＵＥを認識可能となる。このようにすることで、リモートＵＥからリレーＵＥのメジャメント結果の報告を受信したＭＮは、リレーＵＥと接続するｇＮＢを認識可能となる。
　ＭＮはリモートＵＥからのメジャメント結果を用いて、ＤＣに用いるＳＮを決定する。
　ステップＳＴ４４０２で、ＭＮは、ＤＣに用いることに決定したＳＮに対してＳＮ追加要求メッセージを送信する。ＭＮはＳＮに対してリモートＵＥに対するＤＣのためのＳＮとしての追加を要求する。ＳＮ追加要求メッセージは、Ｘｎシグナリングを用いて送信される。ＳＮ追加要求メッセージとしてＳ－Ｎｏｄｅ　ａｄｄｉｔｉｏｎ　ｒｅｑｕｅｓｔメッセージを用いてもよい。ＳＮ追加要求メッセージには、前述に開示したＳＮの追加要求の情報例を含めるとよい。
　ＭＮからＳＮ追加要求メッセージを受信したＳＮは、ＳＮ追加要求の情報から、ＤＣ設定を行うリモートＵＥ、ＤＣ設定を行うリモートＵＥとＮＷ間の通信に関する情報、要求されるベアラ終端、要求されるＤＣ用ベアラ種類等を認識し、リレーＵＥ＃２に対してＤＣ用の設定を行う。
　ステップＳＴ５２０２で、ＳＮはリレーＵＥ＃２に対して、ＤＣ用の設定とＳＬベアラの設定とを送信する。ＳＬベアラの設定をＤＣ用の設定と一緒に送信してもよいし、ＳＬベアラの設定をＤＣ用の設定に含めて送信してもよい。あるいは、ＤＣ用の設定とＳＬベアラの設定とを個別に送信してもよい。該送信にはＲＲＣシグナリングを用いる。該設定の送信ではＲｅｌａｙ　ｒｅｑｕｅｓｔメッセージを用いてもよい。ＤＣ用設定には、前述に開示したＤＣ用設定の情報例を含めるとよい。ＳＬベアラの設定には、前述に開示したＳＬベアラの設定情報を含めるとよい。リレーＵＥ＃２はＳＮからＤＣ用設定とＳＬベアラ設定を受信することで、ＳＮとリレーＵＥ＃２間のＤＣ用設定およびリモートＵＥとリレーＵＥ＃２間のＳＬベアラの設定が可能となる。該設定は修正であってもよい。
　これらの設定を行ったリレーＵＥ＃２は、ステップＳＴ５２０３で、ＳＮに対して、ＤＣ設定応答およびＳＬベアラ設定応答を送信する。本例では肯定応答とする。該送信にはＲＲＣシグナリングを用いる。送信する肯定応答をＲｅｌａｙ　ｒｅｑｕｅｓｔ　Ａｃｋメッセージとしてもよい。ＤＣ設定応答およびＳＬベアラ設定応答を受信したＳＮは、リレーＵＥ＃２がＤＣ設定およびＳＬベアラ設定を完了したことを認識する。
　ステップＳＴ４４０３で、ＳＮはＭＮに対して、ＳＮ追加要求応答メッセージを送信する。本例では肯定応答を送信する。ＳＮ追加要求応答メッセージに、ＳＮとリモートＵＥ間のＤＣ用設定　ａｎｄ／ｏｒ　ＳＬベアラ設定を含めてもよい。これらの一部の情報を含めてもよい。ＳＮ追加要求応答メッセージを受信したＭＮは、ＳＮがリモートＵＥ＃２を介してリモートＵＥに対してＤＣ設定およびＳＬベアラ設定を実施したことを認識する。
　ステップＳＴ４４０４で、ＭＮはＳＮに対してＸｎ－Ｕアドレスインジケーションメッセージを通知する。たとえば、ＭＮは、ＭＮとＳＮ間のＤＣに用いるアドレスを設定し、ステップＳＴ４４０４でＳＮに対して該メッセージを送信する。これにより、ＭＮとＳＮ間でＤＣに用いるアドレスを共有し、ＭＮとＳＮ間のデータ送受信を可能とする。
　ステップＳＴ５２０６で、ＭＮはリモートＵＥに対して、ＤＣ用の設定とＳＬベアラの設定とを送信する。ＳＬベアラの設定をＤＣ用の設定と一緒に送信してもよいし、ＳＬベアラの設定をＤＣ用の設定に含めて送信してもよい。あるいは、ＤＣ用の設定とＳＬベアラの設定とを個別に送信してもよい。該送信にはＲＲＣシグナリングを用いる。該送信ではＲＲＣ　ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージを用いてもよい。ＤＣ用設定には、前述に開示した、ＤＣ用設定に含める情報例を含めるとよい。ＤＣ用設定に含める情報のＳＣＧに関する設定として、ＳＮから受信したＤＣ用設定を用いてもよい。ＳＬベアラの設定には、前述に開示したＳＬベアラの設定情報を含めるとよい。ＳＬベアラ設定のＳＣＧに関する設定として、ＳＮから受信したＳＬベアラ設定を用いてもよい。リモートＵＥはＭＮからＤＣ用設定とＳＬベアラ設定とを受信することで、ＭＮとリモートＵＥ間のＤＣ用設定およびリモートＵＥとリレーＵＥ＃２間のＳＬベアラの設定が可能となる。
　これらの設定を行ったリモートＵＥは、ステップＳＴ５２０８で、ＭＮに対して、ＤＣ設定応答およびＳＬベアラ設定応答を送信する。本例では肯定応答とする。該送信にはＲＲＣシグナリングを用いる。該肯定応答の送信ではＲＲＣ　ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎ　ｃｏｍｐｌｅｔｅメッセージを用いてもよい。ＤＣ設定応答およびＳＬベアラ設定応答を受信したＭＮは、リモートＵＥがＤＣ設定およびＳＬベアラ設定を完了したことを認識する。
　リモートＵＥは、ＭＮとの通信を維持したまま、ステップＳＴ５２１０でリレーＵＥ＃２に対してＰＣ５接続を確立する。該ＰＣ５接続の確立ではＰＣ５－Ｓシグナリングを用いてもよい。ＰＣ５　ＲＲＣシグナリングを用いてもよい。リモートＵＥは、ＭＮから受信したリレーＵＥ＃２とのＳＬベアラ設定を用いてＰＣ５接続を確立する。これにより、リモートＵＥとリレーＵＥ＃２間のデータ通信が可能となる。
　他の方法として、リモートＵＥは、ステップＳＴ５２０８のＤＣ設定応答およびＳＬベアラ設定応答を先に送信した後で、リレーＵＥ＃２に対してＰＣ５接続を確立してもよい。ＭＮ、ＳＮ、ＵＰＦ間でのＤＣ用の処理を早期に実施可能となる。
　ステップＳＴ４４０７で、ＭＮはＳＮに対してＳＮ設定完了メッセージを送信する。該送信にはＸｎシグナリングを用いる。該送信ではＳ－Ｎｏｄｅ　ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎ　ｃｏｍｐｌｅｔｅメッセージを用いてもよい。ＳＮは該メッセージを受信することにより、ＭＮおよびリモートＵＥがＤＣ用の設定を完了したことを認識する。
　ステップＳＴ４４０９でＭＮはＳＮに対してＳＮ状態転送を行い、ステップＳＴ４４１０でＵＰＦからのデータをＳＮに転送する。ＳＮ終端ベアラの場合、ＵＰＦとｇＮＢ間のパスをＭＮからＳＮに変更する必要がある。この場合、ステップＳＴ４４２０のパスアップデート処理を実施する。この結果、ステップＳＴ５２１５で、リモートＵＥ、リレーＵＥ＃２、ＳＮ、ＵＰＦ間でデータ通信が行われる。
　このようにすることで、リモートＵＥ、ＭＮ、リレーＵＥ＃２を介したＳＮ間でＤＣが行われる。たとえば、ＳＮ終端ＳＣＧベアラの場合、リモートＵＥ、リレーＵＥ＃２を介したＳＮ、ＵＰＦ間でデータ通信が行われる。
　たとえば、ＭＮ終端ＳＣＧベアラの場合、リモートＵＥ、リレーＵＥ＃２を介したＳＮ、ＭＮ、ＵＰＦ間でデータ通信が行われる。たとえば、ＳＮ終端ＭＣＧベアラの場合、リモートＵＥ、ＭＮ、リレーＵＥ＃２を介したＳＮ、ＵＰＦ間でデータ通信が行われる。たとえば、ＭＮ終端スプリットベアラの場合、リモートＵＥ、リレーＵＥ＃２を介したＳＮ、ＭＮ、ＵＰＦ間でデータ通信が行われる。たとえば、ＳＮ終端スプリットベアラの場合、リモートＵＥ、ＭＮ、リレーＵＥ＃２を介したＳＮ、ＵＰＦ間でデータ通信が行われる。
　リレーＵＥ＃２を介して、ＳＮとリモートＵＥ間でＲＲＣシグナリングを行ってもよい。該ＲＲＣシグナリングにＳＲＢ３を用いて行ってもよい。ステップＳＴ５２１０でリモートＵＥとリレーＵＥ＃２とで通信開始後、ＳＲＢ３を用いてリモートＵＥはリレーＵＥ＃２を介してＳＮに、ＳＮはリレーＵＥ＃２を介してリモートＵＥにＲＲＣメッセージを送信してもよい。ＳＲＢ３を用いるＲＲＣメッセージは、たとえば、ＳＮに関するメッセージであってもよい。たとえば、ＳＣＧベアラの設定変更、ＳＮメジャメント報告、ＳＣＧベアラのファイラに関する情報送信、などのメッセージであってもよい。たとえば、リモートＵＥとリレーＵＥ＃２間のＳＬベアラの設定変更、リレーＵＥのメジャメント報告、ＳＬベアラのファイラに関する情報送信、などのメッセージであってもよい。このようにすることで、ＭＮを介さずＳＮとリモートＵＥ間で直接ＲＲＣメッセージを通信できるので、シグナリング量の削減、低遅延化が図れる。
　このようにすることで、リモートＵＥが、ＭｇＮＢと直接接続し、リレーＵＥ＃２を介してＳｇＮＢと接続するＤＣの設定が可能となる。
　リレーＵＥを介したリモートＵＥとＮＷ間の通信において、リモートＵＥが２つのｇＮＢと接続する場合のプロトコル構成の他の方法を開示する。図５０は、実施の形態５について、リレーＵＥを介したリモートＵＥとＮＷ間の通信において、リモートＵＥが２つのｇＮＢと接続する場合のプロトコルスタックの他の構成方法を示す図である。リモートＵＥが、リレーＵＥ＃１を介してＭｇＮＢと接続し、リレーＵＥ＃２を介してＳｇＮＢと接続する場合について示している。Ｕ－Ｐｌａｎｅについて示している。
　ＭＮとＳＮはＤＣ用のＵｕのプロトコルを有する。該Ｕｕのプロトコルは、ＳＤＡＰ、ＰＤＣＰ、ＲＬＣ、ＭＡＣ、ＰＨＹである。ＭＮ用のＵｕのプロトコルにおいて、ＲＬＣとＰＤＣＰの間にＡＤＰを構成する。ＡＤＰはＲＬＣのサブレイヤとして構成されてもよい。図５０では、ＤＣ用のベアラとして、ＭＮ終端ベアラおよびＳＮ終端ベアラの両方と、ＭＣＧベアラ、ＳＣＧベアラおよびスプリットベアラについて併せて示している。これらのベアラに対応したプロトコルが構成される。ＰＤＣＰは、ＭＮ終端ベアラ用に１つ、ＳＮ終端ベアラ用に１つ構成されてもよい。ＤＣの設定においてこれらのベアラの設定を可能としてもよい。
　リレーＵＥ＃１は、ＭＮ用のＵｕのプロトコルを有す。図４６の例で開示したリレーＵＥ＃１のプロトコルを適宜適用するとよい。リレーＵＥ＃１は、リモートＵＥ間にＰＣ５のプロトコルを有す。図４６の例で開示したリレーＵＥ＃１のプロトコルを適宜適用するとよい。
　リレーＵＥ＃２は、ＳＮ用のＵｕのプロトコルを有す。図４８の例で開示したリレーＵＥ＃２のプロトコルを適宜適用するとよい。リレーＵＥ＃２は、リモートＵＥ間にＰＣ５のプロトコルを有す。図４８の例で開示したリレーＵＥ＃２のプロトコルを適宜適用するとよい。
　リモートＵＥはリレーＵＥ＃１間にＰＣ５のプロトコルを有す。該ＰＣ５のプロトコルをＭＮ用としてもよい。リレーＵＥ＃１と同様に、該ＰＣ５のプロトコルはＰＣ５　ＲＬＣ、ＰＣ５　ＭＡＣ、ＰＣ５　ＰＨＹである。ＰＣ５　ＲＬＣの上位にＰＣ５　ＡＤＰが構成されてもよい。ＰＣ５　ＳＤＡＰ、ＰＣ５　ＰＤＣＰは無くてもよい。リモートＵＥはリレーＵＥ＃２間にＰＣ５のプロトコルを有す。リモートＵＥは該ＰＣ５のプロトコルをＳＮ用としてもよい。リレーＵＥ＃２と同様に、該ＰＣ５のプロトコルは、ＰＣ５　ＲＬＣ、ＰＣ５　ＭＡＣ、ＰＣ５　ＰＨＹである。ＰＣ５　ＲＬＣの上位にＰＣ５　ＡＤＰが構成されてもよい。ＰＣ５　ＳＤＡＰ、ＰＣ５　ＰＤＣＰは無くてもよい。
　また、リモートＵＥは、ＭＮ　ａｎｄ／ｏｒ　ＳＮ間にＵｕのプロトコルを有す。該Ｕｕのプロトコルは、ＤＣ用のＳＤＡＰ、ＰＤＣＰである。リモートＵＥで、ＭＮ用とＳＮ用のＰＣ５のＰＤＣＰあるいはＡＤＰとＵｕのＰＤＣＰが接続される。ＰＤＣＰは、ＭＮ終端ベアラ用に１つ、ＳＮ終端ベアラ用に１つ構成されてもよい。リモートＵＥでＤＣが終端される。
　ベアラについて開示する。ＭＮとリモートＵＥ間で、ＲＢが設定される。該ＲＢにおいて、ＭＮとリレーＵＥ＃１間、ＳＮとリレーＵＥ＃２間でリレー用ベアラが設定される。該リレー用ベアラはＲＬＣベアラとするとよい。ＲＬＣチャネルであってもよい。リレーＵＥ＃１とリモートＵＥ間、リレーＵＥ＃２とリモートＵＥ間でＳＬベアラが設定される。該ＳＬベアラは、ＳＬ　ＲＬＣベアラとするとよい。ＳＬ　ＲＬＣチャネルであってもよい。ＭＮとリモートＵＥ間でＤＣ用ベアラが設定される。
　ＮＷからリモートＵＥへの通信におけるベアラマッピングに関して開示する。ＭＮとＳＮは、ＮＷからリモートＵＥへの通信において、ＮＷとリモートＵＥ間のＲＢを、ＤＣ用のＵｕのＲＬＣベアラにマッピングする機能を有する。該ＤＣ用のＵｕのＲＬＣベアラとして、ＭＣＧベアラあるいはＳＣＧベアラあるいはスプリットベアラがある。リレーＵＥ＃１および＃２に接続されるリモートＵＥは１つに限らず複数であってもよい。リモートＵＥとＮＷ間のＲＢは１つに限らず複数であってもよい。リレーＵＥ＃１および＃２に接続される１つまたは複数のリモートＵＥのＲＢ　ａｎｄ／ｏｒ　リモートＵＥとＮＷ間の１つまたは複数のＲＢを、ＤＣ用のＵｕのＲＬＣベアラにマッピングしてもよい。前述の機能は、ＭＮとＳＮに構成されるＵｕのＡＤＰが有してもよい。ＡＤＰに、ＤＣが設定される場合と設定されない場合の機能を集約してもよい。この場合、ＭＮとＳＮの構成を容易にできる。
　ＭＮは、ＮＷからリモートＵＥへの通信において、リモートＵＥの識別子とリモートＵＥとＮＷ間のＲＢの識別子とを付加してもよい。ＲＢ　ＩＤは、ＲＢがＳＲＢの場合、ＳＲＢ　ＩＤであってもよい。ＲＢ　ＩＤは、ＲＢがＤＲＢの場合、ＤＲＢ　ＩＤであってもよい。このようにすることで、リレーＵＥ＃１が、送信先のリモートＵＥ、リモートＵＥとＮＷ間通信用のＲＢを認識可能となる。
　ＭＮは、ＮＷからリモートＵＥへの通信において、ＤＣに用いるベアラについての情報を付加してもよい。ＤＣに用いるベアラについての情報として、たとえば、ベアラの終端を示す識別子　ａｎｄ／ｏｒ　ベアラの種類を示す識別子　ａｎｄ／ｏｒ　ＭＮ用かＳＮ用かを示す識別子などがある。このようにすることで、リレーＵＥ＃１またはリモートＵＥが、ＤＣに用いるベアラの終端や種類などを認識可能となる。
　前述の付加機能は、ＭＮに構成されるＵｕのＡＤＰが有してもよい。ＡＤＰに、ＤＣが設定される場合と設定されない場合の機能を集約してもよい。この場合、ＭＮの構成を容易にできる。
　ＳＮは、ＮＷからリモートＵＥへの通信において、リモートＵＥの識別子とリモートＵＥとＮＷ間のＲＢの識別子とを付加してもよい。ＲＢ　ＩＤは、ＲＢがＳＲＢの場合、ＳＲＢ　ＩＤであってもよい。ＲＢ　ＩＤは、ＲＢがＤＲＢの場合、ＤＲＢ　ＩＤであってもよい。このようにすることで、リレーＵＥ＃２が、送信先のリモートＵＥ、リモートＵＥとＮＷ間通信用のＲＢを認識可能となる。
　ＳＮは、ＮＷからリモートＵＥへの通信において、ＤＣに用いるベアラについての情報を付加してもよい。ＤＣに用いるベアラについての情報として、たとえば、ベアラの終端を示す識別子　ａｎｄ／ｏｒ　ベアラの種類を示す識別子　ａｎｄ／ｏｒ　ＭＮ用かＳＮ用かを示す識別子などがある。このようにすることで、リレーＵＥ＃２またはリモートＵＥが、ＤＣに用いるベアラの終端や種類などを認識可能となる。
　前述の付加機能は、ＳＮに構成されるＵｕのＡＤＰが有してもよい。ＡＤＰに、ＤＣが設定される場合と設定されない場合の機能を集約してもよい。この場合、ＳＮの構成を容易にできる。
　リレーＵＥ＃１は、ＮＷからリモートＵＥへの通信において、ＭＮ用のＵｕのＲＬＣベアラをＭＮ用のＰＣ５のＲＬＣベアラにマッピングする機能を有する。図４６の例で開示したマッピング方法を適宜適用するとよい。
　リレーＵＥ＃２は、ＮＷからリモートＵＥへの通信において、ＳＮ用のＵｕのＲＬＣベアラをＳＮ用のＰＣ５のＲＬＣベアラにマッピングする機能を有する。図４８の例で開示したマッピング方法を適宜適用するとよい。
　リモートＵＥは、ＮＷからリモートＵＥへの通信において、ＭＮ用のＰＣ５のＲＬＣベアラとＳＮ用のＰＣ５のＲＬＣベアラとをＮＷとリモートＵＥ間のＲＢにマッピングする機能を有する。該マッピングに、ＭＮで付加されたリモートＵＥ識別子、ＲＢ識別子を用いてもよい。該マッピングに、ＭＮで付加されたＤＣに用いるベアラについての情報を用いてもよい。該マッピングに、ＳＮで付加されたリモートＵＥ識別子、ＲＢ識別子を用いてもよい。該マッピングに、ＳＮで付加されたＤＣに用いるベアラについての情報を用いてもよい。
　リモートＵＥからＮＷへの通信におけるベアラマッピングに関して開示する。リモートＵＥは、リモートＵＥからＮＷへの通信において、ＮＷとリモートＵＥ間のＲＢを、ＤＣ用の２つのＰＣ５のＲＬＣベアラにマッピングする機能を有する。該ＤＣ用のＰＣ５のＲＬＣベアラはＭＮ用とＳＮ用のＰＣ５のＲＬＣベアラである。ＭＮ用のＰＣ５のＲＬＣベアラとして、ＭＣＧベアラあるいはスプリットベアラがある。ＳＮ用のＰＣ５のＲＬＣベアラとして、ＳＣＧベアラあるいはスプリットベアラがある。リモートＵＥは、ＮＷからリモートＵＥへの通信において、リモートＵＥとＮＷ間のＲＢの識別子と基地局の識別子とを付加してもよい。該基地局は複数であってもよい。たとえば、リレーＵＥが複数の基地局に接続するような場合に付加してもよい。該基地局が複数か否かを示す情報あるいは該基地局の識別子が複数か否かを示す情報を付加してもよい。基地局の識別子として、ＭＮ　ａｎｄ／ｏｒ　ＳＮの識別子としてもよい。たとえば、ＤＣが設定される場合に適用してもよい。このようにすることで、リレーＵＥが複数の基地局に送信するような場合も、送信先の基地局、リモートＵＥとＮＷ間通信用のＲＢを認識可能となる。
　リモートＵＥは、リモートＵＥからＮＷへの通信において、ＤＣに用いるベアラについての情報を付加してもよい。ＤＣに用いるベアラについての情報として、たとえば、ベアラの終端を示す識別子　ａｎｄ／ｏｒ　ベアラの種類を示す識別子　ａｎｄ／ｏｒ　ＭＮ用かＳＮ用かを示す識別子などがある。このようにすることで、リレーＵＥ、ＭＮまたはＳＮが、ＤＣに用いるベアラの終端や種類などを認識可能となる。
　前述の付加機能は、リモートＵＥに構成されるＳＬのＡＤＰが有してもよい。ＳＬ　ＡＤＰに、ＤＣが設定される場合と設定されない場合の機能を集約してもよい。リモートＵＥの構成を容易にできる。
　リレーＵＥ＃１は、リモートＵＥからＮＷへの通信において、ＭＮ用のＰＣ５のＲＬＣベアラをＭＮ用のＵｕのＲＬＣベアラにマッピングする機能を有する。図４６の例で開示したマッピング方法を適宜適用するとよい。
　リレーＵＥ＃２は、リモートＵＥからＮＷへの通信において、ＳＮ用のＰＣ５のＲＬＣベアラをＳＮ用のＵｕのＲＬＣベアラにマッピングする機能を有する。図４８の例で開示したマッピング方法を適宜適用するとよい。
　ＭＮとＳＮは、リモートＵＥからＮＷへの通信において、ＤＣ用のＵｕのＲＬＣベアラをＮＷとリモートＵＥ間のＲＢにマッピングする機能を有する。リレーＵＥ＃１とリレーＵＥ＃２に接続されるリモートＵＥは１つに限らず複数であってもよい。リモートＵＥとＮＷ間のＲＢは１つに限らず複数であってもよい。ＤＣ用のＵｕのＲＬＣベアラを、リレーＵＥ＃１とリレーＵＥ＃２に接続される１つまたは複数のリモートＵＥのＲＢ　ａｎｄ／ｏｒ　リモートＵＥとＮＷ間の１つまたは複数のＲＢにマッピングしてもよい。該マッピングに、リモートＵＥまたはリレーＵＥ＃１のＭＮ用のＵｕのＡＤＰで付加されたリモートＵＥ識別子、ＲＢ識別子、ＤＣに用いるベアラについての情報などと、リモートＵＥまたはリレーＵＥ＃２のＳＮ用のＵｕのＡＤＰで付加されたリモートＵＥ識別子、ＲＢ識別子、ＤＣに用いるベアラについての情報などとを用いてもよい。このようにすることで、ＭＮとＳＮで、ＤＣ用のＭＣＧベアラあるいはＳＣＧベアラあるいはスプリットベアラを、リモートＵＥとＮＷ間通信用のＲＢのＰＤＣＰに転送することが可能となる。前述の機能は、ＭＮとＳＮに構成されるＵｕのＡＤＰが有してもよい。ＡＤＰに、ＤＣが設定される場合と設定されない場合の機能を集約してもよい。この場合、ＭＮとＳＮの構成を容易にできる。
　Ｃ－Ｐｌａｎｅのプロトコルについては、ＭＮ、リモートＵＥにおけるＳＤＡＰの代わりにＲＲＣを設ければよい。ＳＲＢに対応したＲＲＣを設けるとよい。ＳＲＢにＤＣが設定される場合はＭＮ終端ベアラのみが設定されてもよい。ＳＲＢのＤＣが可能となる。
　このようにすることで、２つのｇＮＢと接続したリモートＵＥが、リレーＵＥを介してＮＷ間の通信を可能とする。
　リレーＵＥを介して行うリモートＵＥとＮＷ間の通信において、リモートＵＥが複数のｇＮＢと接続するための設定方法を開示する。本実施の形態では、リモートＵＥが２つのｇＮＢと接続するＤＣの設定方法を開示する。
　リモートＵＥが、リレーＵＥ＃１を介してＭｇＮＢと接続し、リレーＵＥ＃２を介してＳｇＮＢと接続する場合について開示する。
　ＭＮはリモートＵＥに対してＤＣの設定を行う。ＭＮは、リモートＵＥとの間のＲＢに対してＤＣの設定を行う。該ＲＢは、リモートＵＥとＭＮ間の通信用であってもよい。該ＲＢは、ＳＲＢ　ａｎｄ／ｏｒ　ＤＲＢでもよい。ＳＲＢとしてＳＲＢ２であってもよい。
　ＭＮは、ＭＮとリレーＵＥ＃１との間のＤＣ用のＵｕのＲＬＣベアラの設定を行う。ＭＮとリモートＵＥ間のＲＢに対するＤＣ設定に用いる。ＤＣ用のＵｕのＲＬＣベアラとして、既存のＵｕのＲＬＣベアラから修正がなければ、新たな設定を行わなくてもよい。
　ＭＮは、ＳＮとリレーＵＥ＃２との間のＤＣ用のＵｕのＲＬＣベアラの設定を行う。ＭＮとリモートＵＥ間のＲＢに対するＤＣ設定に用いる。ＤＣ用のＵｕのＲＬＣベアラとして、既存のＵｕのＲＬＣベアラから修正がなければ、新たな設定を行わなくてもよい。
　ＭＮは、リレーＵＥ＃１とリモートＵＥ間のＤＣ用のＳＬベアラを設定する。ＤＣ用のＳＬベアラは１つのＳＬベアラとしてもよい。該ＳＬベアラは、ＭＮ用のＳＬベアラとしてもよい。該ＳＬベアラは、ＳＬ　ＲＬＣベアラでもよい。
　ＭＮは、リレーＵＥ＃２とリモートＵＥ間のＤＣ用のＳＬベアラを設定する。ＤＣ用のＳＬベアラは１つのＳＬベアラとしてもよい。該ＳＬベアラは、ＳＮ用のＳＬベアラとしてもよい。該ＳＬベアラは、ＳＬ　ＲＬＣベアラでもよい。
　リレーＵＥ＃１はＭＮとＲＲＣ接続状態とするとよい。リレーＵＥ＃２はＳＮとＲＲＣ接続状態とするとよい。リモートＵＥはＭＮとＲＲＣ接続状態とするとよい。また、ＭＮは、リモートＵＥがＭＮとＲＲＣ接続状態において、リモートＵＥに対してＤＣ設定を開始する、としてもよい。ＤＣが設定されたリモートＵＥはＣ－ｐｌａｎｅにおいてＭＮを介してＣＮに接続する。
　ＭＮは、ＳＮに対して、リモートＵＥとＭＮ間通信用のＲＢに対するＳＮの追加要求を送信する。該追加要求はＸｎシグナリングを用いて送信するとよい。Ｓ－Ｎｏｄｅ　ａｄｄｉｔｉｏｎ　ｒｅｑｕｅｓｔメッセージを用いてもよい。
　ＳＮの追加要求に含める情報は、前述に開示したＳＮの追加要求に含める１７個の情報例を適宜適用するとよい。該情報例におけるリレーＵＥをリレーＵＥ＃１とリレーＵＥ＃２におきかえるとよい。
　前述に開示したＳＮの追加要求に含める１７個の情報例のうち、（１）のリレーＵＥに関する情報は、リレーＵＥ＃１に関する情報とリレーＵＥ＃２に関する情報である。リレーＵＥ＃２に関する情報に、ＳＮが、リモートＵＥとＤＣ設定を行うために、どのリレーＵＥを介するかを示す情報を含んでもよい。また、該リレーＵＥの設定に関する情報を含んでもよい。また、リモートＵＥによるリレーＵＥ＃２のメジャメント結果を含んでもよい。また、リレーＵＥ＃２によるＳＮのメジャメント結果を含んでもよい。
　このようにすることで、ＭＮはＳＮに対して、ＤＣ用にＳＮ追加要求を送信することが可能となる。また、ＳＮは、ＭＮからＳＮ追加要求を受信することで、たとえば、どのリモートＵＥに対するＤＣか、どのリレーＵＥを介してリモートＵＥと接続するか、などを認識可能となる。ＳＮはＭＮから受信した情報を用いて、リレーＵＥを介したリモートＵＥに対するＤＣ用の設定を行ってもよい。リレーＵＥを介したリモートＵＥに対するＤＣ用の設定は、ＳＮとリレーＵＥ間のＤＣ用の設定としてもよい。
　ＳＮはリレーＵＥに対するＤＣ用の設定を行う。ＳＮはＭＮに対してＳＮの追加要求に対する応答メッセージを送信する。ＳＮがＤＣ設定を実施する場合、ＭＮに対してＳＮ追加要求肯定応答メッセージを送信する。Ｘｎシグナリングを用いて送信するとよい。ＳＮ追加要求肯定応答メッセージとしてＳ－Ｎｏｄｅ　ａｄｄｉｔｉｏｎ　ｒｅｑｕｅｓｔ　ａｃｋｎｏｗｌｅｄｇｅメッセージを用いてもよい。ＳＮがリレーＵＥに対してＤＣ設定を実施できなかった場合、ＭＮに対してＳＮ追加要求拒否応答メッセージを送信する。Ｘｎシグナリングを用いて送信するとよい。ＳＮ追加要求拒否応答メッセージとしてＳ－Ｎｏｄｅ　ａｄｄｉｔｉｏｎ　ｒｅｑｕｅｓｔ　ｒｅｊｅｃｔメッセージを用いてもよい。ＳＮ追加要求応答メッセージに含める情報は、前述に開示したＳＮ追加要求応答メッセージに含める情報を適宜適用してもよい。
　ＭＮはリレーＵＥ＃１に対してＤＣ用の設定を送信する。前述に開示した方法を適宜適用するとよい。
　ＭＮはリレーＵＥ＃１に対して、リモートＵＥとリレーＵＥ＃１間のＳＬベアラの設定を行う。前述に開示した方法を適宜適用するとよい。
　ＭＮはリレーＵＥ＃１に対するＤＣ用の設定　ａｎｄ／ｏｒ　リモートＵＥとリレーＵＥ＃１間のＳＬベアラの設定を行う場合、ＳＮから受信したＳＮとリレーＵＥ＃２間のＤＣ用の設定　ａｎｄ／ｏｒ　リレーＵＥ＃２とリモートＵＥ間のＳＬベアラの設定情報を用いてもよい。ＳＮにおける負荷状況などを考慮することが可能となる。
　ＳＮはリレーＵＥ＃２に対してＤＣ用の設定を送信する。前述に開示した方法を適宜適用するとよい。
　ＳＮはリレーＵＥ＃２に対して、リモートＵＥとリレーＵＥ＃２間のＳＬベアラの設定を行う。前述に開示した方法を適宜適用するとよい。
　ＭＮはリモートＵＥに対してＤＣ用の設定を送信する。ＤＣ用設定に含める情報例を１つ開示する。
（１）ＲＢに関する情報。
　ＲＢに関する情報は、前述に開示した情報を適宜適用するとよい。
　ＭＮはリモートＵＥに対してＲＢ設定を送信する。ＲＲＣシグナリングで送信してもよい。ＲＲＣ　ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージに含めて送信してもよい。ＲａｄｉｏＢｅａｒｅｒＣｏｎｆｉｇ情報に含めて送信してもよい。
　ＭＮはリモートＵＥに対してＳＮの識別子を送信してもよい。ＤＣによってリレーＵＥ＃２を介して接続するＳＮを認識可能となる。
　ＭＮはリモートＵＥに対して、リモートＵＥとリレーＵＥ＃１間、および、リモートＵＥとリレーＵＥ＃２間のＳＬベアラの設定を行う。これらの設定に関しては前述に開示した方法を適宜適用するとよい。
　ＭＮはリモートＵＥに対するＤＣ用の設定　ａｎｄ／ｏｒ　リモートＵＥとリレーＵＥ＃１間のＳＬベアラの設定　ａｎｄ／ｏｒ　リモートＵＥとリレーＵＥ＃２間のＳＬベアラの設定を行う場合、ＳＮから受信したリレーＵＥ＃２とＳＮとの間のＤＣのための設定　ａｎｄ／ｏｒ　リモートＵＥとリレーＵＥ＃２間のＳＬベアラの設定情報を用いてもよい。ＳＮにおける負荷状況などを考慮することが可能となる。たとえば、ＭＮは、リモートＵＥとリレーＵＥ＃２間のＳＬベアラの設定情報については、ＳＮがリレーＵＥ＃２に送信したリモートＵＥとリレーＵＥ＃２間のＳＬベアラの設定情報と同じとしてもよい。リモートＵＥとリレーＵＥ＃２におけるＳＬベアラの設定が同じとなり、ＳＬ通信における誤動作を低減できる。
　ＭＮからＤＣ用のＳＬベアラの設定情報を受信したリモートＵＥは、リレーＵＥ＃２とのＰＣ５接続を確立する。リレーＵＥ＃２とＰＣ５接続を確立したリモートＵＥは、リレーＵＥ＃２との間でＤＣ用のＳＬベアラを設定する。リモートＵＥとＰＣ５接続を確立したリレーＵＥ＃２は、リモートＵＥとの間でＤＣ用のＳＬベアラを設定する。リモートＵＥはリレーＵＥ＃２に対してＳＬ　ＲＲＣ設定を通知してもよい。リレーＵＥ＃２はリモートＵＥに対してＳＬ　ＲＲＣ設定を通知してもよい。
　ＤＣ設定の種類がＳＮ終端の場合、ＰＤＵセッションの修正を行ってもよい。この場合、ＭＮとＣＮ間でＰＤＵセッション修正処理が行われる。ＰＤＵセッションの修正は、前述に開示した方法を適宜適用するとよい。
　リモートＵＥとＮＷ間のデータ通信は、リレーＵＥ＃１を介したリモートＵＥとＭＮ間のＭＣＧベアラ、リレーＵＥ＃２を介したリモートＵＥとＳＮ間のＳＣＧベアラ、リレーＵＥ＃１を介したリモートＵＥとＭＮ間とリレーＵＥ＃２を介したリモートＵＥとＳＮ間とのスプリットベアラにより行われる。
　図５１は、実施の形態５について、リモートＵＥが２つのｇＮＢと接続するＤＣの設定方法例を示すシーケンス図である。リモートＵＥが、リレーＵＥ＃１を介してＭｇＮＢと接続し、リレーＵＥ＃２を介してＳｇＮＢと接続する場合について開示する。図５１において、図４１、図４７、図４９と共通するステップについては同じステップ番号を付し、共通する説明を省略する。ステップＳＴ５００１で、リモートＵＥ、リレーＵＥ＃１、ＭＮ、ＵＰＦ間でデータ通信が行われる。
　ＭＮはリモートＵＥからのメジャメント結果を用いて、ＤＣに用いるＳＮを決定する。
　ステップＳＴ４４０２～ステップＳＴ４４２０で、リモートＵＥに対して、リレーＵＥ＃１を介したＭＮとリレーＵＥ＃２を介したＳＮとを用いたＤＣの設定が行われる。この結果、ステップＳＴ５４０１で、リモートＵＥ、リレーＵＥ＃２、ＳＮ、ＵＰＦ間でデータ通信が行われる。
　図５１のようにすることで、リモートＵＥ、リレーＵＥ＃１を介したＭＮ、リレーＵＥ＃２を介したＳＮ間でＤＣが行われる。たとえば、ＳＮ終端ＳＣＧベアラの場合、リモートＵＥ、リレーＵＥ＃２を介したＳＮ、ＵＰＦ間でデータ通信が行われる。
　たとえば、ＭＮ終端ＳＣＧベアラの場合、リモートＵＥ、リレーＵＥ＃２を介したＳＮ、リレーＵＥ＃１を介したＭＮ、ＵＰＦ間でデータ通信が行われる。たとえば、ＳＮ終端ＭＣＧベアラの場合、リモートＵＥ、リレーＵＥ＃１を介したＭＮ、リレーＵＥ＃２を介したＳＮ、ＵＰＦ間でデータ通信が行われる。たとえば、ＭＮ終端スプリットベアラの場合、リモートＵＥ、リレーＵＥ＃２を介したＳＮ、リレーＵＥ＃１を介したＭＮ、ＵＰＦ間でデータ通信が行われる。たとえば、ＳＮ終端スプリットベアラの場合、リモートＵＥ、リレーＵＥ＃１を介したＭＮ、リレーＵＥ＃２を介したＳＮ、ＵＰＦ間でデータ通信が行われる。
　リレーＵＥ＃２を介して、ＳＮとリモートＵＥ間でＲＲＣシグナリングを行ってもよい。該ＲＲＣシグナリングにＳＲＢ３を用いて行ってもよい。ステップＳＴ５２１０でリモートＵＥとリレーＵＥ＃２とで通信開始後、ＳＲＢ３を用いてリモートＵＥはリレーＵＥ＃２を介してＳＮに、ＳＮはリレーＵＥ＃２を介してリモートＵＥにＲＲＣメッセージを送信してもよい。ＳＲＢ３を用いるＲＲＣメッセージは、たとえば、ＳＮに関するメッセージであってもよい。たとえば、ＳＣＧベアラの設定変更、ＳＮメジャメント報告、ＳＣＧベアラのファイラに関する情報送信、などのメッセージであってもよい。たとえば、リモートＵＥとリレーＵＥ＃２間のＳＬベアラの設定変更、リレーＵＥのメジャメント報告、ＳＬベアラのファイラに関する情報送信、などのメッセージであってもよい。このようにすることで、ＭＮを介さずＳＮとリモートＵＥ間で直接ＲＲＣメッセージを通信できるので、シグナリング量の削減、低遅延化が図れる。
　このようにすることで、リモートＵＥが、リレーＵＥ＃１を介してＭｇＮＢと接続し、リレーＵＥ＃２を介してＳｇＮＢと接続するＤＣの設定が可能となる。
　すなわち、リレーＵＥを介したリモートＵＥとＮＷ間の間接通信においてＤＣが可能となる。リレーＵＥを介したリモートＵＥとＮＷ間の間接通信において、複数のｇＮＢを用いた通信が可能となる。これにより、高速大容量化、低遅延化、高信頼性化などの、性能改善が図れる。また、リモートＵＥに対するＤＣのため、リレーＵＥが複数のｇＮＢと接続しなくてもよい。リレーＵＥの構成においてＤＣによる複雑化を回避することが可能となる。
実施の形態６．
　本実施の形態６では、実施の形態４で述べた課題を解決する他の方法を開示する。
　リレーＵＥを介して行うリモートＵＥとＮＷ間の通信において、リモートＵＥが複数のパスで一つの基地局と接続する。該複数はたとえば２つであってもよい。少なくとも一つのパスで、リモートＵＥと基地局とがリレーＵＥを介して接続される。
　リモートＵＥが複数のパスで一つの基地局と接続する構成において、リモートＵＥとＮＷ間の通信におけるＤＣが設定されてもよい。リレーＵＥをＳＮの代替としてＤＣが設定されてもよい。本実施の形態では、ＳＮの代替となるリレーＵＥをリレーＵＥ＃Ｓと称する。リレーＵＥ＃Ｓは、ＤＣ用のＳＮの機能の一部または全部を有する。リモートＵＥはＤＣのため、ＭＮおよびリレーＵＥ＃Ｓと接続する。リモートＵＥとＭＮとの接続は直接接続であってもよいし、リレーＵＥを介した間接接続であってもよい。
　リモートＵＥとＮＷ間の通信のための無線ベアラに対して、リモートＵＥは１つのｇＮＢと複数のパスで接続する。該無線ベアラは、たとえば、ＳＲＢであってもよい。たとえば、ＳＲＢ２であってもよい。ＳＲＢ０、ＳＲＢ１は一つのｇＮＢを用いて通信することで、通信の確立処理を簡易にすることが可能となる。該無線ベアラは、たとえば、ＤＲＢであってもよい。この場合、データ通信用のベアラの通信品質の向上が図れる。
　図５２は、実施の形態６について、リレーＵＥを介したリモートＵＥとＮＷ間の通信において、リモートＵＥが１つのｇＮＢと２つのパスで接続する場合の一例を示す概念図である。この構成において、リモートＵＥとＮＷ間の通信において、リモートＵＥは、ＭＮと、ＳＮの代替とするリレーＵＥ＃Ｓとを用いてＤＣが設定される。
　１つのパスでリモートＵＥはＭｇＮＢと直接接続し、他の１つのパスでリモートＵＥはリレーＵＥ＃Ｓと接続し、リレーＵＥ＃ＳはＭｇＮＢと接続する。リモートＵＥとＭｇＮＢとの直接接続はＵｕで行われる。リモートＵＥとリレーＵＥ＃Ｓ間はＰＣ５で接続される。リレーＵＥ＃ＳとＭｇＮＢ間はＸｎで接続される。リレーＵＥ＃ＳとＭｇＮＢ間は無線接続であってもよい。Ｕｕを用いてＸｎの接続がなされてもよい。リモートＵＥはＭｇＮＢとＲＲＣ接続状態とするとよい。リレーＵＥ＃ＳはＭｇＮＢとＲＲＣ接続状態としてもよい。たとえば、リレーＵＥ＃ＳとＭｇＮＢとが無線接続でＵｕを用いてＸｎの接続が行われる場合にＲＲＣ接続状態としてもよい。
　図５３は、実施の形態６について、リレーＵＥを介したリモートＵＥとＮＷ間の通信において、リモートＵＥが１つのｇＮＢと２つのパスで接続する場合の他の例を示す概念図である。この構成において、リモートＵＥとＮＷ間の通信において、リモートＵＥは、ＭＮと、ＳＮの代替とするリレーＵＥ＃Ｓとを用いてＤＣが設定される。
　１つのパスでリモートＵＥはリレーＵＥ＃１を介してＭｇＮＢと接続し、他の１つのパスでリモートＵＥはリレーＵＥ＃Ｓと接続し、リレーＵＥ＃ＳはＭｇＮＢと接続する。リモートＵＥとリレーＵＥ＃１間はＰＣ５で接続され、リレーＵＥ＃１とＭｇＮＢ間はＵｕで接続される。リモートＵＥとリレーＵＥ＃Ｓ間はＰＣ５で接続される。リレーＵＥ＃ＳとＭｇＮＢ間はＸｎで接続される。リレーＵＥ＃ＳとＭｇＮＢ間はＦ１で接続されてもよい。リレーＵＥ＃ＳとＭｇＮＢ間は無線接続であってもよい。Ｕｕを用いてＸｎあるいはＦ１の接続がなされてもよい。リモートＵＥはＭｇＮＢとＲＲＣ接続状態とするとよい。リレーＵＥ＃１はＭｇＮＢとＲＲＣ接続状態とするとよい。リレーＵＥ＃ＳはＭｇＮＢとＲＲＣ接続状態としてもよい。たとえば、リレーＵＥ＃ＳとＭｇＮＢとが無線接続でＵｕを用いてＸｎあるいはＦ１の接続が行われる場合にＲＲＣ接続状態としてもよい。
　リレーＵＥを介したリモートＵＥとＮＷ間の通信において、リモートＵＥが１つのｇＮＢと２つのパスで接続する場合のプロトコル構成を開示する。図５４は、実施の形態６について、リモートＵＥとＮＷ間の通信において、リモートＵＥが、ＭＮと、ＳＮの代替とするリレーＵＥ＃Ｓとを用いてＤＣが設定される場合のプロトコルスタックを示す図である。１つのパスでリモートＵＥはＭｇＮＢと直接接続し、他の１つのパスでリモートＵＥはリレーＵＥ＃Ｓと接続し、リレーＵＥ＃ＳはＭｇＮＢと接続する場合について示している。Ｕ－Ｐｌａｎｅについて示している。
　ＭＮはＤＣ用のＵｕのプロトコルを有する。該Ｕｕのプロトコルは、ＳＤＡＰ、ＰＤＣＰ、ＲＬＣ、ＭＡＣ、ＰＨＹである。該ＵｕのプロトコルはＭＮ用としてもよい。リレーＵＥ＃ＳはＤＣ用のＰＣ５のプロトコルを有す。該ＰＣ５のプロトコルをＳＮ用としてもよい。該ＰＣ５のプロトコルは、ＰＣ５　ＲＬＣ、ＰＣ５　ＭＡＣ、ＰＣ５　ＰＨＹである。ＰＣ５　ＲＬＣの上位にＰＣ５　ＡＤＰが構成されてもよい。ＰＣ５　ＡＤＰはＰＣ５　ＲＬＣのサブレイヤとして構成されてもよい。ＰＣ５　ＡＤＰは、たとえばＵｕのベアラとＰＣ５のベアラ間のマッピング機能を有するとよい。ＰＣ５　ＳＤＡＰ、ＰＣ５　ＰＤＣＰは無くてもよい。図５４では、ＭＣＧベアラ、ＳＣＧベアラ、スプリットベアラについて併せて示している。ＤＣの設定においてこれらのベアラの設定を可能としてもよい。
　リモートＵＥはリレーＵＥ＃Ｓとの間にＰＣ５のプロトコルを有す。該ＰＣ５のプロトコルをＳＮ用としてもよい。リレーＵＥ＃Ｓと同様に、該ＰＣ５のプロトコルはＰＣ５　ＡＤＰ、ＰＣ５　ＲＬＣ、ＰＣ５　ＭＡＣ、ＰＣ５　ＰＨＹである。ＰＣ５　ＳＤＡＰ、ＰＣ５　ＰＤＣＰは無くてもよい。ＳＮ用のベアラは、ＳＣＧベアラあるいはスプリットベアラである。また、リモートＵＥはＭＮとの間にＤＣ用のＵｕのプロトコルを有す。該Ｕｕのプロトコルは、ＳＤＡＰ、ＰＤＣＰ、ＲＬＣ、ＭＡＣ、ＰＨＹである。ＭＮ用のベアラは、ＭＣＧベアラあるいはスプリットベアラである。リモートＵＥで、ＳＮ用のＰＣ５のＡＤＰとＵｕのＰＤＣＰが接続され、ＭＮ用のＵｕのＲＬＣとＵｕのＰＤＣＰが接続される。リモートＵＥでＤＣが終端される。
　ベアラについて開示する。ＭＮとリモートＵＥ間で、ＲＢが設定される。該ＲＢにおいて、ＤＣ用のベアラが設定される。ＤＣ用のベアラとして、ＭＮのＰＤＣＰで終端されるＭＮ終端ベアラが設定される。ＤＣ用のベアラとして、ＭＮのＲＬＣベアラを有するベアラ、あるいは、ＭＮとリレーＵＥ＃Ｓの両方のＲＬＣベアラを有するベアラが設定される。本明細書では、ＭＮのＲＬＣベアラを有するベアラをＭＣＧベアラと称し、リレーＵＥ＃ＳのＲＬＣベアラを有するベアラをＳＣＧベアラと称し、ＭＮとリレーＵＥ＃Ｓの両方のＲＬＣベアラを有するベアラをスプリットベアラと称する。
　リレーＵＥ＃ＳとリモートＵＥ間でＳＬベアラが設定される。該ＳＬベアラはＳＬ　ＲＬＣベアラとするとよい。ＳＬ　ＲＬＣチャネルであってもよい。ＭＮとリモートＵＥ間でＤＣ用ベアラが設定される。
　ＮＷからリモートＵＥへの通信におけるベアラマッピングに関して開示する。ＭＮは、ＮＷからリモートＵＥへの通信において、ＮＷとリモートＵＥ間のＲＢを、ＤＣ用のＲＬＣベアラにマッピングする機能を有する。該ＤＣ用のＲＬＣベアラとして、ＭＣＧベアラあるいはＳＣＧベアラあるいはスプリットベアラがある。リレーＵＥ＃Ｓに接続されるリモートＵＥは１つに限らず複数であってもよい。リモートＵＥとＮＷ間のＲＢは１つに限らず複数であってもよい。
　ＭＮは、ＮＷからリモートＵＥへの通信において、リモートＵＥの識別子とリモートＵＥとＮＷ間のＲＢの識別子（ＲＢ識別子：ＲＢ　ＩＤ）を付加してもよい。ＲＢ　ＩＤは、ＲＢがＳＲＢの場合、ＳＲＢ　ＩＤであってもよい。ＲＢ　ＩＤは、ＲＢがＤＲＢの場合、ＤＲＢ　ＩＤであってもよい。このようにすることで、リレーＵＥ＃ＳまたはリモートＵＥが、送信先のリモートＵＥ、リモートＵＥとＮＷ間通信用のＲＢを認識可能となる。
　ＭＮは、ＮＷからリモートＵＥへの通信において、ＤＣに用いるベアラについての情報を付加してもよい。ＤＣに用いるベアラについての情報として、たとえば、ベアラの終端を示す識別子　ａｎｄ／ｏｒ　ベアラの種類を示す識別子　ａｎｄ／ｏｒ　ＭＮ用かＳＮ用かを示す識別子などがある。このようにすることで、リレーＵＥ＃ＳまたはリモートＵＥが、ＤＣに用いるベアラの終端や種類などを認識可能となる。
　リレーＵＥ＃Ｓにおいて、リモートＵＥとＮＷ間の１つまたは複数のＲＢを、ＤＣ用のＰＣ５のＲＬＣベアラにマッピングしてもよい。該マッピングに、ＭＮで付加されたリモートＵＥ識別子、ＲＢ識別子、ＤＣに用いるベアラについての情報などを用いてもよい。前述の機能は、リレーＵＥ＃Ｓに構成されるＰＣ５のＡＤＰが有してもよい。ＡＤＰに、ＤＣが設定される場合と設定されない場合の機能を集約してもよい。リレーＵＥ＃Ｓの構成を容易にできる。
　リレーＵＥ＃Ｓは、ＰＣ５のＲＬＣベアラにマッピングする際に、ＭＮで付加されたリモートＵＥ識別子、ＲＢ識別子、ＤＣに用いるベアラについての情報などの一部または全部を削除してもよい。リモートＵＥへのＰＣ５のＲＬＣベアラへのマッピングにおいて、該識別子や情報の一部または全部を付加しなくてもよい。
　リレーＵＥ＃Ｓにおいて、ＮＷからリモートＵＥへの通信において、リモートＵＥの識別子とリモートＵＥとＮＷ間のＲＢの識別子とを付加してもよい。ＲＢ　ＩＤは、ＲＢがＳＲＢの場合、ＳＲＢ　ＩＤであってもよい。ＲＢ　ＩＤは、ＲＢがＤＲＢの場合、ＤＲＢ　ＩＤであってもよい。このようにすることで、リモートＵＥが、送信先のリモートＵＥ、リモートＵＥとＮＷ間通信用のＲＢを認識可能となる。
　リレーＵＥ＃Ｓにおいて、ＮＷからリモートＵＥへの通信において、ＤＣに用いるベアラについての情報を付加してもよい。ＤＣに用いるベアラについての情報として、たとえば、ベアラの終端を示す識別子　ａｎｄ／ｏｒ　ベアラの種類を示す識別子　ａｎｄ／ｏｒ　ＭＮ用かＳＮ用かを示す識別子などがある。このようにすることで、リモートＵＥが、ＤＣに用いるベアラの終端や種類などを認識可能となる。
　リモートＵＥは、ＮＷからリモートＵＥへの通信において、ＭＮ用のＵｕのＲＬＣベアラとＳＮ用のＰＣ５のＲＬＣベアラとをＮＷとリモートＵＥ間のＲＢにマッピングする機能を有する。該マッピングに、リレーＵＥ＃Ｓで付加されたリモートＵＥ識別子、ＲＢ識別子、ＤＣに用いるベアラについての情報などを用いてもよい。
　リモートＵＥからＮＷへの通信におけるベアラマッピングに関して開示する。リモートＵＥは、リモートＵＥからＮＷへの通信において、ＮＷとリモートＵＥ間のＲＢを、ＤＣ用のＲＬＣベアラにマッピングする機能を有する。該ＤＣ用のＲＬＣベアラとして、ＭＮ用のＵｕのＲＬＣベアラとＳＮ用のＰＣ５のＲＬＣベアラがある。該ＤＣ用のＲＬＣベアラとして、ＭＣＧベアラあるいはＳＣＧベアラあるいはスプリットベアラがある。リレーＵＥ＃Ｓに接続されるリモートＵＥは１つに限らず複数であってもよい。リモートＵＥとＮＷ間のＲＢは１つに限らず複数であってもよい。
　リモートＵＥは、リモートＵＥからＮＷへの通信において、基地局の識別子とリモートＵＥとＮＷ間のＲＢの識別子とを付加してもよい。ＲＢ　ＩＤは、ＲＢがＳＲＢの場合、ＳＲＢ　ＩＤであってもよい。ＲＢ　ＩＤは、ＲＢがＤＲＢの場合、ＤＲＢ　ＩＤであってもよい。該基地局が複数か否かを示す情報あるいは該基地局の識別子が複数か否かを示す情報を付加してもよい。このようにすることで、リレーＵＥ＃ＳまたはＭＮが、送信先の基地局、リモートＵＥとＮＷ間通信用のＲＢを認識可能となる。
　リモートＵＥは、ＮＷからリモートＵＥへの通信において、ＤＣに用いるベアラについての情報を付加してもよい。ＤＣに用いるベアラについての情報として、たとえば、ベアラの終端を示す識別子　ａｎｄ／ｏｒ　ベアラの種類を示す識別子　ａｎｄ／ｏｒ　ＭＮ用かＳＮ用かを示す識別子などがある。このようにすることで、リレーＵＥ＃ＳまたはＭＮが、ＤＣに用いるベアラの終端や種類などを認識可能となる。
　リレーＵＥ＃Ｓにおいて、ＳＮ用のＰＣ５のＲＬＣベアラをリモートＵＥとＮＷ間の１つまたは複数のＲＢにマッピングする。該マッピングに、リモートＵＥで付加された基地局識別子、ＲＢ識別子、ＤＣに用いるベアラについての情報などを用いてもよい。前述の機能は、リレーＵＥ＃Ｓに構成されるＰＣ５のＡＤＰが有してもよい。ＡＤＰに、ＤＣが設定される場合と設定されない場合の機能を集約してもよい。リレーＵＥ＃Ｓの構成を容易にできる。
　リレーＵＥ＃Ｓは、１つまたは複数のＲＢにマッピングする際に、リモートＵＥで付加されたリモートＵＥ識別子、ＲＢ識別子、ＤＣに用いるベアラについての情報などの一部または全部を削除してもよい。１つまたは複数のＲＢへのマッピングにおいて、該識別子や情報の一部または全部を付加しなくてもよい。
　リレーＵＥ＃Ｓは、リモートＵＥからＮＷへの通信において、リモートＵＥの識別子とリモートＵＥとＮＷ間のＲＢの識別子とを付加してもよい。ＲＢ　ＩＤは、ＲＢがＳＲＢの場合、ＳＲＢ　ＩＤであってもよい。ＲＢ　ＩＤは、ＲＢがＤＲＢの場合、ＤＲＢ　ＩＤであってもよい。このようにすることで、ＭＮが、リモートＵＥとＮＷ間通信用のＲＢを認識可能となる。
　リレーＵＥ＃Ｓは、リモートＵＥからＮＷへの通信において、ＤＣに用いるベアラについての情報を付加してもよい。ＤＣに用いるベアラについての情報として、たとえば、ベアラの終端を示す識別子　ａｎｄ／ｏｒ　ベアラの種類を示す識別子　ａｎｄ／ｏｒ　ＭＮ用かＳＮ用かを示す識別子などがある。このようにすることで、ＭＮが、ＤＣに用いるベアラの終端や種類などを認識可能となる。
　ＭＮは、リモートＵＥからＮＷへの通信において、ＭＮ用のＵｕのＲＬＣベアラとＳＮ用のＰＣ５のＲＬＣベアラとをＮＷとリモートＵＥ間のＲＢにマッピングする機能を有する。該マッピングに、リモートＵＥまたはリレーＵＥ＃ＳのＡＤＰで付加されたリモートＵＥ識別子、ＲＢ識別子、ＤＣに用いるベアラについての情報などを用いてもよい。
　Ｃ－Ｐｌａｎｅのプロトコルについては、ＭＮ、リモートＵＥにおけるＳＤＡＰの代わりにＲＲＣを設ければよい。ＳＲＢに対応したＲＲＣを設けるとよい。ＳＲＢにＤＣが設定される場合はＭＮ終端ベアラのみが設定されてもよい。ＳＲＢのＤＣが可能となる。
　図５５は、実施の形態６について、ＭＮとリレーＵＥ＃Ｓ間のプロトコルスタックを示す図である。リレーＵＥ＃ＳとＭｇＮＢ間がＵｕを用いてＸｎの接続がなされる場合について示している。Ｕ－Ｐｌａｎｅについて示している。
　ＭＮはリレーＵＥ＃Ｓとの間のＸｎあるいはＦ１接続のため、ＧＴＰ－Ｕ、ＵＤＰ、ＩＰ、ＲＬＣ、ＭＡＣ、ＰＨＹを有す。ＤＣ用のＵｕのプロトコルであるＰＤＣＰと、ＧＴＰ－Ｕが接続される。リレーＵＥ＃Ｓ用のＰＤＣＰ　ＰＤＵがＧＴＰ－Ｕに入力される。ＧＴＰ－Ｕ、ＵＤＰ、ＩＰで処理を行い、ＩＰで出力されたデータが、リレーＵＥ＃Ｓとの無線接続用のＵｕのプロトコルＲＬＣに入力される。ＲＬＣに入力されたデータは、ＭＡＣ、ＰＨＹの処理が行われ、リレーＵＥ＃Ｓに送信される。
　リレーＵＥ＃ＳはＭＮとの間のＸｎ接続のため、ＧＴＰ－Ｕ、ＵＤＰ、ＩＰ、ＲＬＣ、ＭＡＣ、ＰＨＹを有す。ＭＮから受信したデータは、ＭＮとの無線接続用のＵｕのプロトコルＰＨＹに入力される。ＰＨＹに入力されたデータは、ＭＡＣ、ＲＬＣの処理が行われ、ＩＰに入力される。ＩＰに入力されたデータは、ＵＤＰ、ＧＴＰ－Ｕで処理が行われ、データが出力される。該データは、ＰＤＣＰ　ＰＤＵと同等である。
　このように、ＭＮとリレーＵＥ＃Ｓ間は、ＩＰ、ＵＤＰ、ＧＴＰ－Ｕが互いに終端される。
　ＧＴＰ－Ｕからの出力データは、リレーＵＥ＃ＳのＳＮ用ＳＬベアラにマッピングされる。ＳＬベアラにマッピングされたデータは、ＳＬ　ＡＤＰに入力され、ＳＬ　ＲＬＣ、ＳＬ　ＭＡＣ、ＳＬ　ＰＨＹで処理が行われ、リモートＵＥに送信される。
　ＭＮからリレーＵＥ＃Ｓを介したリモートＵＥへの通信方向について開示した。リモートＵＥからリレーＵＥ＃Ｓを介したＭＮへの通信方向については、前述に開示した逆の処理が行われる。
　Ｃ－Ｐｌａｎｅのプロトコルについては、ＭＮ、リレーＵＥ＃ＳにおけるＵＤＰとＤＴＰ－Ｕの代わりに、ＳＣＴＰのみを設ければよい。ＳＲＢのＤＣが可能となる。
　このようにすることで、１つのｇＮＢと２つのパスで接続したリモートＵＥが、リレーＵＥを介してＮＷ間との通信を可能とする。
　リレーＵＥを介して行うリモートＵＥとＮＷ間の通信において、リモートＵＥが１つのｇＮＢと２つのパスで接続するＤＣの設定方法を開示する。
　リモートＵＥが、ＭＮと、ＳＮの代替とするリレーＵＥ＃Ｓとを用いてＤＣが設定される場合について開示する。具体的には、１つのパスでリモートＵＥがＭｇＮＢと直接接続し、他の１つのパスでリモートＵＥがリレーＵＥ＃Ｓと接続し、リレーＵＥ＃ＳがＭｇＮＢと接続する場合について開示する。
　ＭＮはリモートＵＥに対してＤＣの設定を行う。ＭＮは、リモートＵＥとの間のＲＢに対してＤＣの設定を行う。該ＲＢは、リモートＵＥとＭＮ間の通信用であってもよい。該ＲＢは、ＳＲＢ　ａｎｄ／ｏｒ　ＤＲＢでもよい。たとえば、ＳＲＢとしてＳＲＢ２であってもよい。
　ＭＮはリモートＵＥに対してＤＣ用のＵｕのＲＬＣベアラの設定を行う。該ＤＣ用のＵｕのＲＬＣベアラは、ＭＮとの間のＲＬＣベアラでもよい。
　ＭＮはリレーＵＥ＃Ｓに対してＤＣ用のＵｕのＲＬＣベアラの設定を行う。該ＤＣ用のＵｕのＲＬＣベアラは、ＭＮとの間のＲＬＣベアラでもよい。
　ＭＮは、リレーＵＥ＃ＳとリモートＵＥ間のＤＣ用のＳＬベアラを設定する。該ＤＣ用のＳＬベアラは１つのＳＬベアラとしてもよい。該ＳＬベアラは、ＳＮ用のＳＬベアラとしてもよい。該ＳＬベアラは、ＳＬ　ＲＬＣベアラでもよい。
　リレーＵＥ＃ＳはＭＮとＲＲＣ接続状態とするとよい。リモートＵＥはＭＮとＲＲＣ接続状態とするとよい。また、ＭＮは、リモートＵＥがＭＮとＲＲＣ接続状態において、リモートＵＥに対してＤＣ設定を開始する、としてもよい。ＤＣが設定されたリモートＵＥはＣ－ｐｌａｎｅにおいてＭＮを介してＣＮに接続する。
　ＭＮは、リレーＵＥ＃Ｓに対して、リモートＵＥとＭＮ間通信用のＲＢに対するＤＣの設定要求を送信する。該ＤＣの設定要求はＳＮとしての機能の追加要求でもよい。該追加要求はＸｎシグナリングを用いて送信するとよい。Ｆ１シグナリングを用いて送信してもよい。Ｓ－Ｎｏｄｅ　ａｄｄｉｔｉｏｎ　ｒｅｑｕｅｓｔメッセージを用いて送信してもよい。あるいは、新たなメッセージを設け、該メッセージを用いて送信してもよい。該メッセージは、たとえば、Ｒｅｌａｙ（ＤＣ）ｒｅｑｕｅｓｔメッセージとしてもよい。
　ＤＣの設定要求に含める情報は、前述に開示したＳＮの追加要求に含める１７個の情報例を適宜適用するとよい。該情報例におけるＳＮをリレーＵＥ＃Ｓにおきかえるとよい。
　ただし、ＭＮとリモートＵＥはリレーＵＥを介さずに接続されるため、ＭＮとリレーＵＥ間の設定情報は無くてもよい。たとえば、ＭＮはリレーＵＥ＃Ｓに対して、前述に開示したＳＮの追加要求に含める１７個の情報例のうち、（４）、（７）、（９）を送信しない。
　前述に開示したＳＮの追加要求に含める１７個の情報例のうち、（１）、（５）、（８）におけるリレーＵＥは、リレーＵＥ＃Ｓにおきかえるとよい。ＳＮとして機能するリレー＃Ｓが、リモートＵＥとＤＣ設定を行うための情報を含んでもよい。また、（１）のリレーＵＥ＃Ｓに関する情報に、リモートＵＥによるリレーＵＥ＃Ｓのメジャメント結果を含んでもよい。また、リレーＵＥ＃ＳによるＭＮのメジャメント結果を含んでもよい。
　このようにすることで、ＭＮはリレーＵＥ＃Ｓに対して、ＤＣ設定要求を送信することが可能となる。また、リレーＵＥ＃Ｓは、ＭＮからＤＣ設定要求を受信することで、たとえば、どのリモートＵＥに対するＤＣかなどを認識可能となる。リレーＵＥ＃ＳはＭＮから受信した情報を用いてＳＮとしてのＤＣ用の設定を行う。
　ＭＮはリレーＵＥ＃Ｓに対してＤＣ用の設定を送信する。ＤＣ用設定に含める情報例を５つ開示する。
（１）ＲＢに関する情報。
（２）ＵｕのＲＬＣベアラに関する情報。
（３）ＳＮの識別子。
（４）ＡＤＰ設定に関する情報。
（５）（１）～（４）の組合せ。
　これら５つのＤＣ用設定に含める情報は、前述に開示したＤＣ用設定に含める情報例を適宜適用するとよい。ＤＣ用設定に含める情報として、ＳＮとして設定するための情報とするとよい。
　ただし、（１）は、リモートＵＥとＭＮ間通信用のＲＢに関する情報である。ＭＮはリレーＵＥ＃Ｓに対してＤＣの設定としてＲＢの設定を行わない。ＤＣを設定するＲＢがＳＲＢの場合もＳＲＢ設定を行わない。ＤＣを設定するＲＢがＤＲＢの場合もＤＲＢの設定を行わない。（１）のＲＢに関する情報として、たとえば、ＲＢの識別子のみとしてもよい。
　ただし、（２）は、ＤＣ用のＵｕのＲＬＣベアラに関する情報である。ＤＣ用のＵｕのＲＬＣベアラに関する情報として、ＸｎあるいはＦ１用のＵｕ　ＲＬＣベアラの設定情報とするとよい。ＭＮはリレーＵＥ＃Ｓに対してＸｎあるいはＦ１用のＵｕ　ＲＬＣベアラの設定情報を送信する。リレーＵＥ＃ＳはＭＮからＸｎあるいはＦ１用のＵｕ　ＲＬＣベアラ設定情報を受信することで、ＭＮとの間でＸｎシグナリングあるいはＦ１シグナリング用の接続が可能となる。
　ただし、（３）のＳＮの識別子は無くてもよい。ＳＮの識別子として、リレーＵＥ＃Ｓの識別子としてもよい。
　ＭＮはリレーＵＥ＃Ｓに対して、リモートＵＥとリレーＵＥ＃Ｓ間のＳＬベアラの設定を行う。リモートＵＥとリレーＵＥ＃Ｓ間で既存のＳＬベアラがある場合は、該ＳＬベアラの修正を行ってもよい。ＳＬベアラの設定は、ＳＬベアラの修正のための設定であってもよい。ＳＬベアラの設定情報例として３つ開示する。
（１）ＳＬのＲＬＣベアラに関する情報。
（２）ＳＬのＡＤＰ設定に関する情報。
（３）（１）と（２）の組合せ。
　ＳＬベアラの設定情報は、前述に開示したＳＬベアラの設定情報例を適宜適用するとよい。
　ＭＮはリレーＵＥ＃Ｓに対してＳＬ　ＲＢの設定は行わなくてよい。ＳＬ　ＲＢに関する情報を送信しなくてよい。ＳＬ　ＰＤＣＰ、ＳＬ　ＳＤＡＰの設定を行わないとしてもよい。ＭＮはリレーＵＥ＃Ｓに対して、ＤＣ用として１つのＳＬベアラの設定を行ってもよい。該ＤＣ用のＳＬベアラの設定は、ＳＮ用のＳＬベアラの設定でもよい。ＭＮは、ＳＮとしてのリレーＵＥ＃Ｓに対してＳＮ用のＳＬベアラを設定してもよい。
　ＭＮはリレーＵＥ＃Ｓとの間でＸｎあるいはＦ１接続が行われる。ＭＮはリレーＵＥ＃Ｓに対して、該接続に用いる設定情報を送信してもよい。該設定情報として、たとえば、ＧＴＰ-ｕ　ＴＥＩＤやＴＮＬアドレス（ＩＰアドレス）などがある。このようにすることで、ＭＮはリレーＵＥ＃Ｓとの間で、Ｕｕではなく、ＸｎあるいはＦ１によるデータの送受信が可能となる。
　リレーＵＥ＃ＳはリモートＵＥに対するＤＣ設定を行ってもよい。リレーＵＥ＃Ｓは、リモートＵＥに対してリレーＵＥ＃Ｓとの間のＤＣのための設定を行ってもよい。リレーＵＥ＃Ｓは、ＭＮから受信したＤＣ設定要求メッセージに含まれる情報を用いてＤＣ設定を行ってもよい。リモートＵＥに対するＤＣ設定として、リモートＵＥとリレーＵＥ＃Ｓ間のＳＬ　ＲＲＣ設定であってもよい。ＳＬ　ＲＲＣ設定は、たとえば、ＳＬ　ＲＬＣベアラの設定であってもよい。
　リレーＵＥ＃ＳはＭＮに対してＤＣ設定要求に対する応答メッセージを送信する。リレーＵＥ＃ＳがＤＣ設定を実施する場合、ＭＮに対してＤＣ設定要求肯定応答メッセージを送信する。Ｘｎシグナリングを用いて送信するとよい。Ｆ１シグナリングを用いて送信してもよい。ＤＣ設定要求肯定応答メッセージとしてＳ－Ｎｏｄｅ　ａｄｄｉｔｉｏｎ　ｒｅｑｕｅｓｔ　ａｃｋｎｏｗｌｅｄｇｅメッセージを用いてもよい。あるいは、新たなメッセージを設けてもよい。たとえば、Ｒｅｌａｙ（ＤＣ）ｒｅｑｕｅｓｔ　ａｃｋｎｏｗｌｅｄｇｅメッセージとしてもよい。ＤＣ設定要求応答メッセージに含める情報は、前述に開示したＳＮ追加要求応答メッセージに含める情報を適宜適用してもよい。
　リレーＵＥ＃ＳがＤＣ設定を実施できなかった場合、ＭＮに対してＤＣ設定要求拒否応答メッセージを送信する。Ｘｎシグナリングを用いて送信するとよい。Ｆ１シグナリングを用いて送信してもよい。ＤＣ設定要求拒否応答メッセージとしてＳ－Ｎｏｄｅ　ａｄｄｉｔｉｏｎ　ｒｅｑｕｅｓｔ　ｒｅｊｅｃｔメッセージを用いてもよい。あるいは、新たなメッセージを設けてもよい。たとえば、Ｒｅｌａｙ（ＤＣ）ｒｅｑｕｅｓｔ　ｒｅｊｅｃｔメッセージとしてもよい。該メッセージに、たとえば、リモートＵＥに関する情報、理由情報を含めて通知してもよい。
　ＭＮはリモートＵＥに対してＤＣ用の設定を送信する。ＤＣ用設定に含める情報例を４つ開示する。
（１）ＲＢに関する情報。
（２）ＵｕのＲＬＣベアラに関する情報。
（３）ＳＮの識別子。
（４）（１）～（３）の組合せ。
　これら４つのＤＣ用設定に含める情報は、前述に開示したＤＣ用設定に含める情報例を適宜適用するとよい。
　ただし、（２）は、ＤＣ用のＵｕのＲＬＣベアラに関する情報である。ＭＮはリモートＵＥに対してＳＣＧ用の設定は行わなくてもよい。ＤＣにおいてリモートＵＥはＳＮとしてのリレーＵＥ＃Ｓと接続するため、リモートＵＥはＳＣＧに関する情報を受信しなくてもよい。
　ただし、（３）のＳＮの識別子は無くてもよい。ＳＮの識別子として、リレーＵＥ＃Ｓの識別子としてもよい。
　ＭＮはリモートＵＥに対するＤＣ用の設定を行う場合、リレーＵＥ＃Ｓから受信したリモートＵＥとリレーＵＥ＃Ｓ間のＳＬベアラの設定情報を用いてもよい。リレーＵＥ＃Ｓにおける負荷状況などを考慮することが可能となる。
　ＭＮはリモートＵＥに対して、リモートＵＥとリレーＵＥ＃Ｓ間のＳＬベアラの設定を行う。リモートＵＥとリレーＵＥ＃Ｓ間で既存のＳＬベアラがある場合は、該ＳＬベアラの修正を行ってもよい。ＳＬベアラの設定は、ＳＬベアラの修正のための設定であってもよい。ＳＬベアラの設定情報例として３つ開示する。
（１）ＳＬのＲＬＣベアラに関する情報。
（２）ＳＬのＡＤＰ設定に関する情報。
（３）（１）と（２）の組合せ。
　ＳＬベアラの設定情報は、前述に開示したＳＬベアラの設定情報例を適宜適用するとよい。
　ＳＬのＲＬＣベアラは１つとしてもよい。ＤＣ用のＳＬベアラの設定として、ＳＮ用のＳＬのＲＬＣベアラを設定してもよい。ＭＮは、リモートＵＥに対して、ＳＮとしてのリレーＵＥ＃Ｓ間のＳＬ　ＲＬＣベアラを設定してもよい。
　ＳＬのＡＤＰ設定は１つとしてもよい。ＤＣ用のＳＬのＡＤＰ設定として、ＳＮ用のＳＬのＡＤＰを設定してもよい。ＭＮは、リモートＵＥに対して、リモートＵＥとＳＮとしてのリレーＵＥ＃Ｓ間のＳＬのＡＤＰを設定してもよい。
　ＳＬベアラの設定をＤＣ用設定に含めてもよい。ＳＬベアラの設定情報をＤＣ用設定情報に含めてもよい。
　ＭＮはリモートＵＥに対してＳＬ　ＲＢの設定は行わなくてよい。ＳＬ　ＲＢに関する情報を送信しなくてよい。ＳＬ　ＰＤＣＰ、ＳＬ　ＳＤＡＰの設定を行わないとしてもよい。ＭＮはリモートＵＥに対して、ＤＣ用として１つのＳＬベアラの設定を行ってもよい。該ＤＣ用のＳＬベアラの設定は、ＭＮ用のＳＬベアラの設定でもよい。
　ＭＮはリモートＵＥとリレーＵＥ＃Ｓ間のＳＬベアラの設定を行う場合、リレーＵＥ＃Ｓから受信したリモートＵＥとリレーＵＥ＃Ｓの間のＳＬベアラの設定情報を用いてもよい。リレーＵＥ＃Ｓにおける負荷状況などを考慮することが可能となる。たとえば、ＭＮは、リモートＵＥとリレーＵＥ＃Ｓ間のＳＬベアラの設定情報については、リレーＵＥ＃Ｓから受信したリモートＵＥとリレーＵＥ＃Ｓ間のＳＬベアラの設定情報と同じとしてもよい。リモートＵＥとリレーＵＥ＃ＳにおけるＳＬベアラの設定が同じとなり、ＳＬ通信における誤動作を低減できる。
　ＭＮからＤＣ用のＳＬベアラの設定情報を受信したリモートＵＥは、リレーＵＥ＃ＳとのＰＣ５接続を確立する。リレーＵＥ＃ＳとＰＣ５接続を確立したリモートＵＥは、リレーＵＥ＃Ｓとの間でＤＣ用のＳＬベアラを設定する。リモートＵＥとＰＣ５接続を確立したリレーＵＥ＃Ｓは、リモートＵＥとの間でＤＣ用のＳＬベアラを設定する。リモートＵＥはリレーＵＥ＃Ｓに対してＳＬ　ＲＲＣ設定を通知してもよい。リレーＵＥ＃ＳはリモートＵＥに対してＳＬ　ＲＲＣ設定を通知してもよい。
　リモートＵＥとＮＷ間のデータ通信は、リモートＵＥとＭＮ間のＭＣＧベアラ、リレーＵＥ＃Ｓを介したリモートＵＥとＭＮ間のＳＣＧベアラ、リモートＵＥとＭＮ間とリレーＵＥ＃Ｓを介したリモートＵＥとＭＮ間のスプリットベアラを用いて行われる。
　図５６は、実施の形態６について、リモートＵＥが１つのｇＮＢと２つのパスで接続するＤＣの設定方法例を示すシーケンス図である。リモートＵＥが、ＭＮと、ＳＮの代替とするリレーＵＥ＃Ｓとを用いてＤＣが設定される場合について開示する。１つのパスでリモートＵＥはＭｇＮＢと直接接続し、他の１つのパスでリモートＵＥはリレーＵＥ＃Ｓと接続し、リレーＵＥ＃ＳはＭｇＮＢと接続する場合について開示する。図５６において、図４９と共通するステップについては同じステップ番号を付し、共通する説明を省略する。ステップＳＴ５２０１で、リモートＵＥ、ＭＮ、ＵＰＦ間でデータ通信が行われる。
　ＭＮはリモートＵＥに対してＤＣを設定することを決定する。たとえば、ＭＮはリモートＵＥのメジャメント結果からＤＣに用いるリレーＵＥ＃Ｓを決定する。
　ステップＳＴ５９０１で、ＭＮは、ＤＣに用いることに決定したリレーＵＥ＃Ｓに対してＤＣ設定要求を送信する。ＭＮはリレーＵＥ＃Ｓに対してリモートＵＥに対するＤＣのＳＮとしての機能の追加を要求する。ＤＣ設定要求メッセージは、たとえばＸｎあるいはＦ１シグナリングを用いて送信される。ＤＣ設定要求メッセージとしてＲｅｌａｙ（ＤＣ）　ｒｅｑｕｅｓｔメッセージを用いてもよい。ＤＣ設定要求メッセージには、前述に開示したＳＮの追加要求の情報例を含めるとよい。
　ＭＮからＤＣ設定要求メッセージを受信したリレーＵＥ＃Ｓは、ＤＣ設定要求の情報から、ＤＣ設定を行うリモートＵＥ、ＤＣ設定を行うリモートＵＥとＮＷ間の通信に関する情報、要求されるベアラ終端、要求されるＤＣ用ベアラ種類等を認識し、リモートＵＥに対してＤＣ用の設定を行う。ＤＣ用の設定は、たとえば、ＳＮとリモートＵＥ間のＲＲＣ設定であってもよい。ステップＳＴ５９０２で、リレーＵＥ＃ＳはＭＮに対して、ＤＣ設定要求応答メッセージを送信する。本例では肯定応答を送信する。ＤＣ設定要求応答メッセージとしてＲｅｌａｙ（ＤＣ）　ｒｅｑｕｅｓｔ　Ａｃｋメッセージを用いてもよい。ＤＣ設定要求応答メッセージに、リレーＵＥ＃ＳとリモートＵＥ間のＳＬ　ＲＲＣ設定を含めてもよい。ＤＣ設定要求応答メッセージを受信したＭＮは、リレーＵＥ＃ＳがリモートＵＥに対してＤＣ設定を実施したことを認識する。また、ＭＮは、リレーＵＥ＃ＳとリモートＵＥ間のＲＲＣ設定を認識する。
　ステップＳＴ５９０３で、ＭＮはリレーＵＥ＃Ｓに対してＸｎ－Ｕアドレスインジケーションメッセージを通知する。Ｆ１－Ｕアドレスインジケーションメッセージを通知してもよい。たとえば、ＭＮは、ＭＮとＳＮ間のＤＣに用いるアドレスを設定し、該アドレスをステップＳＴ５９０３でリレーＵＥ＃Ｓに対して送信する。これにより、ＭＮとリレーＵＥ＃Ｓ間でＤＣに用いるアドレスを共有し、ＭＮとリレーＵＥ＃Ｓ間のデータ送受信を可能とする。
　ステップＳＴ５２０６で、ＭＮはリモートＵＥに対して、ＤＣ用の設定とＳＬベアラの設定とを送信する。ＳＬベアラの設定をＤＣ用の設定と一緒に送信してもよいし、ＳＬベアラの設定をＤＣ用の設定に含めて送信してもよい。あるいは、ＤＣ用の設定とＳＬベアラの設定を個別に送信してもよい。該送信にはＲＲＣシグナリングを用いる。該送信ではＲＲＣ　ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージを用いてもよい。ＤＣ用設定には、前述に開示した、ＤＣ用設定に含める情報例を含めるとよい。ＤＣ用設定に含める情報のＳＣＧに関する設定として、ＳＮから受信したＤＣ用設定を用いてもよい。ＳＬベアラの設定には、前述に開示したＳＬベアラの設定情報を含めるとよい。ＳＬベアラ設定のＳＣＧに関する設定として、ＳＮから受信したＳＬベアラ設定を用いてもよい。ＳＬベアラ設定の情報に関する設定として、リレーＵＥ＃Ｓから受信したＲＲＣ設定情報を用いてもよい。リモートＵＥはＭＮからＤＣ用設定とＳＬベアラ設定とを受信することで、ＭＮとリモートＵＥ間のＤＣ用設定およびリモートＵＥとリレーＵＥ＃Ｓ間のＳＬベアラの設定が可能となる。
　これらの設定を行ったリモートＵＥは、ステップＳＴ５２０８で、ＭＮに対して、ＤＣ設定応答およびＳＬベアラ設定応答を送信する。本例では肯定応答とする。該送信にはＲＲＣシグナリングを用いる。該肯定応答の送信ではＲＲＣ　ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎ　ｃｏｍｐｌｅｔｅメッセージを用いてもよい。ＤＣ設定応答およびＳＬベアラ設定応答を受信したＭＮは、リモートＵＥがＤＣ設定およびＳＬベアラ設定を完了したことを認識する。
　ステップＳＴ５９０４で、ＭＮはリレーＵＥ＃Ｓに対してＤＣ設定完了メッセージを送信する。該送信にはＸｎあるいはＦ１シグナリングを用いる。該送信ではＲｅｌａｙ（ＤＣ）　ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎ　ｃｏｍｐｌｅｔｅメッセージを用いてもよい。リレーＵＥ＃Ｓは該メッセージを受信することにより、ＭＮおよびリモートＵＥがＤＣ用の設定を完了したことを認識する。
　リモートＵＥは、ＭＮとの通信を維持したまま、ステップＳＴ５９０５でリレーＵＥ＃Ｓに対してＰＣ５接続を確立する。該ＰＣ５接続の確立ではＰＣ５－Ｓシグナリングを用いてもよい。ＰＣ５　ＲＲＣシグナリングを用いてもよい。リモートＵＥは、ＭＮから受信したリレーＵＥ＃ＳとのＳＬベアラ設定を用いてＰＣ５接続を確立する。これにより、リモートＵＥとリレーＵＥ＃Ｓ間のデータ通信が可能となる。
　ステップＳＴ５９０６で、ＭＮはリレーＵＥ＃Ｓに対してＳＮ状態転送を行ってもよい。該ＳＮ状態転送はＳＮ　ｓｔａｔｕｓ　ｔｒａｎｓｆｅｒメッセージを用いて行ってもよい。ステップＳＴ５９０７で、ＭＮはＵＰＦからのデータをリレーＵＥ＃Ｓに転送する。
　このようにすることで、リモートＵＥ、ＭＮ、リレーＵＥ＃Ｓ間でＤＣが行われる。設定可能なＤＣはＭＮ終端ベアラのみとしてもよい。リレーＵＥ＃Ｓが直接ＣＮと接続することなく、リレーＵＥ＃Ｓの構成を容易にすることが可能となる。たとえば、ＭＮ終端ＳＣＧベアラの場合、リモートＵＥ、リレーＵＥ＃Ｓ、ＭＮ、ＵＰＦ間でデータ通信が行われる。たとえば、ＭＮ終端スプリットベアラの場合、リモートＵＥ、リレーＵＥ＃Ｓ、ＭＮ、ＵＰＦ間でデータ通信が行われる。
　このようにすることで、リモートＵＥが、ＭｇＮＢとリレーＵＥ＃Ｓと接続するＤＣの設定が可能となる。
　リレーＵＥを介したリモートＵＥとＮＷ間の通信において、リモートＵＥが１つのｇＮＢと２つのパスで接続する場合のプロトコル構成の他の例を開示する。図５７は、実施の形態６について、リモートＵＥとＮＷ間の通信において、リモートＵＥが、ＭＮと、ＳＮの代替とするリレーＵＥ＃Ｓとを用いてＤＣが設定される場合のプロトコルスタックの他の構成方法を示す図である。１つのパスでリモートＵＥはリレーＵＥ＃１を介してＭｇＮＢと接続し、他の１つのパスでリモートＵＥはリレーＵＥ＃Ｓと接続し、リレーＵＥ＃ＳはＭｇＮＢと接続する場合について示している。Ｕ－Ｐｌａｎｅについて示している。
　ＭＮはＤＣ用のＵｕのプロトコルを有する。該Ｕｕのプロトコルは、ＳＤＡＰ、ＰＤＣＰ、ＲＬＣ、ＭＡＣ、ＰＨＹである。該Ｕｕのプロトコルにおいて、ＲＬＣとＰＤＣＰの間にＡＤＰを構成する。ＡＤＰはＲＬＣのサブレイヤとして構成されてもよい。該ＵｕのプロトコルはＭＮ用としてもよい。リレーＵＥ＃ＳはＤＣ用のＰＣ５のプロトコルを有す。該ＰＣ５のプロトコルをＳＮ用としてもよい。該ＰＣ５のプロトコルは、ＰＣ５　ＲＬＣ、ＰＣ５　ＭＡＣ、ＰＣ５　ＰＨＹである。ＰＣ５　ＲＬＣの上位にＰＣ５　ＡＤＰが構成されてもよい。ＰＣ５　ＡＤＰは、たとえばＵｕのベアラとＰＣ５のベアラ間のマッピング機能を有するとよい。ＰＣ５　ＳＤＡＰ、ＰＣ５　ＰＤＣＰは無くてもよい。図５７では、ＭＣＧベアラ、ＳＣＧベアラ、スプリットベアラについて併せて示している。ＤＣの設定においてこれらのベアラの設定を可能としてもよい。
　リレーＵＥ＃１は、ＭＮ用のＵｕのプロトコルを有す。該Ｕｕのプロトコルは、ＲＬＣ、ＭＡＣ、ＰＨＹである。ＰＣ５　ＲＬＣの上位にＰＣ５　ＡＤＰが構成されてもよい。ＰＣ５　ＡＤＰはＰＣ５　ＲＬＣのサブレイヤとして構成されてもよい。ＭＮ用のベアラは、ＭＣＧベアラあるいはスプリットベアラである。
　リレーＵＥ＃１は、リモートＵＥ間にＰＣ５のプロトコルを有す。該ＰＣ５のプロトコルをＭＮ用としてもよい。該ＰＣ５のプロトコルは、ＰＣ５　ＲＬＣ、ＰＣ５　ＭＡＣ、ＰＣ５　ＰＨＹである。ＰＣ５　ＲＬＣの上位にＰＣ５　ＡＤＰが構成されてもよい。ＰＣ５　ＡＤＰはＰＣ５　ＲＬＣのサブレイヤとして構成されてもよい。ＰＣ５　ＡＤＰは、たとえばＵｕのベアラとＰＣ５のベアラ間のマッピング機能を有するとよい。ＰＣ５　ＳＤＡＰ、ＰＣ５　ＰＤＣＰは無くてもよい。
　リモートＵＥはリレーＵＥ＃Ｓとの間にＰＣ５のプロトコルを有す。該ＰＣ５のプロトコルをＳＮ用としてもよい。リレーＵＥ＃Ｓと同様に、該ＰＣ５のプロトコルはＰＣ５　ＡＤＰ、ＰＣ５　ＲＬＣ、ＰＣ５　ＭＡＣ、ＰＣ５　ＰＨＹである。ＰＣ５　ＳＤＡＰ、ＰＣ５　ＰＤＣＰは無くてもよい。また、リモートＵＥはリレーＵＥ＃１との間にＰＣ５のプロトコルを有す。該ＰＣ５のプロトコルをＭＮ用としてもよい。リレーＵＥ＃１と同様に、該ＰＣ５のプロトコルはＰＣ５　ＡＤＰ、ＰＣ５　ＲＬＣ、ＰＣ５　ＭＡＣ、ＰＣ５　ＰＨＹである。ＰＣ５　ＳＤＡＰ、ＰＣ５　ＰＤＣＰは無くてもよい。また、リモートＵＥは、ＭＮとの間にＵｕのプロトコルを有す。該Ｕｕのプロトコルは、ＤＣ用のＳＤＡＰ、ＰＤＣＰである。リモートＵＥで、ＭＮ用のＰＣ５のＡＤＰとＵｕのＰＤＣＰが接続される。リモートＵＥでＤＣが終端される。
　ベアラについて開示する。ＭＮとリモートＵＥ間で、ＲＢが設定される。該ＲＢにおいて、ＭＮとリレーＵＥ＃１間でＭＮ用のベアラが設定される。ＭＮ用のベアラとして、ＭＣＧベアラあるいはスプリットベアラ用である。該ＭＣＧベアラあるいはスプリットベアラはＲＬＣベアラとするとよい。ＲＬＣチャネルであってもよい。リレーＵＥ＃１とリモートＵＥ間で１つのＳＬベアラが設定される。該ＳＬベアラは、ＭＮ用のＳＬ　ＲＬＣベアラとするとよい。ＳＬ　ＲＬＣチャネルであってもよい。リレーＵＥ＃ＳとリモートＵＥ間でＳＮ用のＳＬベアラが設定される。ＳＮ用のベアラは、ＳＣＧベアラあるいはスプリットベアラである。該ＳＣＧベアラあるいはスプリットベアラはＲＬＣベアラとするとよい。ＲＬＣチャネルであってもよい。
　ＮＷからリモートＵＥへの通信におけるベアラマッピングに関して開示する。ＭＮは、ＮＷからリモートＵＥへの通信において、ＮＷとリモートＵＥ間のＲＢを、ＤＣ用のＵｕのＲＬＣベアラとＰＣ５のＲＬＣベアラにマッピングする機能を有する。該ＤＣ用のＵｕのＲＬＣベアラとして、ＭＣＧベアラあるいはスプリットベアラがある。該ＤＣ用のＰＣ５のＲＬＣベアラとして、ＳＣＧベアラあるいはスプリットベアラがある。
　リレーＵＥ＃１に接続されるリモートＵＥは１つに限らず複数であってもよい。リモートＵＥとＮＷ間のＲＢは１つに限らず複数であってもよい。リレーＵＥ＃１に接続される１つまたは複数のリモートＵＥのＲＢ　ａｎｄ／ｏｒ　リモートＵＥとＮＷ間の１つまたは複数のＲＢを、ＤＣ用のＵｕのＲＬＣベアラにマッピングしてもよい。前述の機能は、ＭＮとＳＮに構成されるＵｕのＡＤＰが有してもよい。ＡＤＰに、ＤＣが設定される場合と設定されない場合の機能を集約してもよい。この場合、ＭＮの構成を容易にできる。
　ＭＮは、ＮＷからリモートＵＥへの通信において、リモートＵＥの識別子とリモートＵＥとＮＷ間のＲＢの識別子とを付加してもよい。ＲＢ　ＩＤは、ＲＢがＳＲＢの場合、ＳＲＢ　ＩＤであってもよい。ＲＢ　ＩＤは、ＲＢがＤＲＢの場合、ＤＲＢ　ＩＤであってもよい。このようにすることで、リレーＵＥ＃１、リレーＵＥ＃Ｓ、またはリモートＵＥが、送信先のリモートＵＥ、リモートＵＥとＮＷ間通信用のＲＢを認識可能となる。
　ＭＮは、ＮＷからリモートＵＥへの通信において、ＤＣに用いるベアラについての情報を付加してもよい。ＤＣに用いるベアラについての情報として、たとえば、ベアラの終端を示す識別子　ａｎｄ／ｏｒ　ベアラの種類を示す識別子　ａｎｄ／ｏｒ　ＭＮ用かＳＮ用かを示す識別子などがある。このようにすることで、リレーＵＥ＃１、リレーＵＥ＃ＳまたはリモートＵＥが、ＤＣに用いるベアラの終端や種類などを認識可能となる。
　前述の付加機能は、ＭＮに構成されるＵｕのＡＤＰが有してもよい。たとえば、リレーＵＥ＃１への通信における付加機能のみをＭＮに構成されるＵｕのＡＤＰが有してもよい。ＡＤＰに、ＤＣが設定される場合と設定されない場合の機能を集約してもよい。この場合、ＭＮの構成を容易にできる。
　リレーＵＥ＃１は、ＮＷからリモートＵＥへの通信において、ＭＮ用のＵｕのＲＬＣベアラをＭＮ用のＰＣ５のＲＬＣベアラにマッピングする機能を有する。該マッピングに、ＭＮで付加されたリモートＵＥ識別子、ＲＢ識別子、ＤＣに用いるベアラについての情報などを用いてもよい。このようにすることで、リレーＵＥ＃１で、ＭＮ用のＭＣＧベアラあるいはスプリットベアラを、ＭＮ用のＰＣ５のＲＬＣベアラにマッピングすることが可能となる。前述の機能は、リレーＵＥ＃１に構成されるＵｕのＡＤＰが有してもよい。ＡＤＰに、ＤＣが設定される場合と設定されない場合の機能を集約してもよい。この場合、リレーＵＥ＃１の構成を容易にできる。
　リレーＵＥ＃１は、ＭＮ用のＰＣ５のＲＬＣベアラににマッピングする際に、ＭＮで付加されたリモートＵＥ識別子、ＲＢ識別子、ＤＣに用いるベアラについての情報などの一部または全部を削除してもよい。ＭＮ用のＰＣ５のＲＬＣベアラへのマッピングにおいて、該識別子や情報の一部または全部を付加しなくてもよい。
　リレーＵＥ＃Ｓにおいて、リモートＵＥとＮＷ間の１つまたは複数のＲＢを、ＤＣ用のＰＣ５のＲＬＣベアラにマッピングしてもよい。図５４の例で開示したマッピング方法を適宜適用するとよい。
　リモートＵＥは、リモートＵＥからＮＷへの通信において、ＭＮ用のＰＣ５のＲＬＣベアラとＳＮ用のＰＣ５のＲＬＣベアラとをＮＷとリモートＵＥ間のＲＢにマッピングする機能を有する。該マッピングに、ＭＮまたはリレーＵＥ＃Ｓで付加されたリモートＵＥ識別子、ＲＢ識別子、ＤＣに用いるベアラについての情報などを用いてもよい。
　リモートＵＥからＮＷへの通信におけるベアラマッピングに関して開示する。リモートＵＥは、リモートＵＥからＮＷへの通信において、ＮＷとリモートＵＥ間のＲＢを、ＤＣ用のＲＬＣベアラにマッピングする機能を有する。該ＤＣ用のＲＬＣベアラとして、ＭＮ用のＰＣ５のＲＬＣベアラとＳＮ用のＰＣ５のＲＬＣベアラがある。該ＤＣ用のＲＬＣベアラとして、ＭＣＧベアラあるいはＳＣＧベアラあるいはスプリットベアラがある。リレーＵＥ＃Ｓに接続されるリモートＵＥは１つに限らず複数であってもよい。リモートＵＥとＮＷ間のＲＢは１つに限らず複数であってもよい。
　リモートＵＥは、リモートＵＥからＮＷへの通信において、基地局の識別子とリモートＵＥとＮＷ間のＲＢの識別子とを付加してもよい。ＲＢ　ＩＤは、ＲＢがＳＲＢの場合、ＳＲＢ　ＩＤであってもよい。ＲＢ　ＩＤは、ＲＢがＤＲＢの場合、ＤＲＢ　ＩＤであってもよい。該基地局が複数か否かを示す情報あるいは該基地局の識別子が複数か否かを示す情報を付加してもよい。このようにすることで、リレーＵＥ＃１、リレーＵＥ＃ＳまたはＭＮが、送信先の基地局、リモートＵＥとＮＷ間通信用のＲＢを認識可能となる。
　リモートＵＥは、ＮＷからリモートＵＥへの通信において、ＤＣに用いるベアラについての情報を付加してもよい。ＤＣに用いるベアラについての情報として、たとえば、ベアラの終端を示す識別子　ａｎｄ／ｏｒ　ベアラの種類を示す識別子　ａｎｄ／ｏｒ　ＭＮ用かＳＮ用かを示す識別子などがある。このようにすることで、リレーＵＥ＃１、リレーＵＥ＃ＳまたはＭＮが、ＤＣに用いるベアラの終端や種類などを認識可能となる。
　リレーＵＥ＃１は、リモートＵＥからＮＷへの通信において、ＭＮ用のＰＣ５のＲＬＣベアラをＭＮ用のＵｕのＲＬＣベアラにマッピングする機能を有する。該マッピングに、リモートＵＥで付加された基地局識別子、ＲＢ識別子、ＤＣに用いるベアラについての情報などを用いてもよい。該ＭＮ用のＵｕのＲＬＣベアラとして、ＭＣＧベアラあるいはスプリットベアラがある。リレーＵＥ＃１に接続されるリモートＵＥは１つに限らず複数であってもよい。前述の機能は、リレーＵＥ＃１に構成されるＵｕのＡＤＰが有してもよい。ＡＤＰに、ＤＣが設定される場合と設定されない場合の機能を集約してもよい。この場合、リレーＵＥ＃１の構成を容易にできる。
　リレーＵＥ＃１は、ＭＮ用のＵｕのＲＬＣベアラにマッピングする際に、リモートＵＥで付加された基地局識別子、ＲＢ識別子、ＤＣに用いるベアラについての情報などの一部または全部を削除してもよい。ＭＮ用のＵｕのＲＬＣベアラへのマッピングにおいて、該識別子や情報の一部または全部を付加しなくてもよい。
　リレーＵＥ＃１は、リモートＵＥからＮＷへの通信において、リモートＵＥの識別子とリモートＵＥとＮＷ間のＲＢの識別子とを付加してもよい。ＲＢ　ＩＤは、ＲＢがＳＲＢの場合、ＳＲＢ　ＩＤであってもよい。ＲＢ　ＩＤは、ＲＢがＤＲＢの場合、ＤＲＢ　ＩＤであってもよい。このようにすることで、ＭＮが、送信元のリモートＵＥ、リモートＵＥとＮＷ間通信用のＲＢを認識可能となる。前述の付加機能は、リレーＵＥ＃１に構成されるＭＮ用のＵｕのＡＤＰが有してもよい。ＡＤＰに、ＤＣが設定される場合と設定されない場合の機能を集約してもよい。この場合、リレーＵＥ＃１の構成を容易にできる。
　リレーＵＥ＃１は、ＮＷからリモートＵＥへの通信において、ＤＣに用いるベアラについての情報を付加してもよい。ＤＣに用いるベアラについての情報として、たとえば、ベアラの終端を示す識別子　ａｎｄ／ｏｒ　ベアラの種類を示す識別子　ａｎｄ／ｏｒ　ＭＮ用かＳＮ用かを示す識別子などがある。このようにすることで、ＭＮが、ＤＣに用いるベアラの終端や種類などを認識可能となる。
　リレーＵＥ＃Ｓにおいて、ＳＮ用のＰＣ５のＲＬＣベアラをリモートＵＥとＮＷ間の１つまたは複数のＲＢにマッピングする。図５４の例で開示したマッピング方法を適宜適用するとよい。
　ＭＮは、リモートＵＥからＮＷへの通信において、ＭＮ用のＵｕのＲＬＣベアラとＳＮ用のＰＣ５のＲＬＣベアラとをＮＷとリモートＵＥ間のＲＢにマッピングする機能を有する。該マッピングに、リモートＵＥ、リレーＵＥ＃１またはリレーＵＥ＃Ｓで付加されたリモートＵＥ識別子、ＲＢ識別子、ＤＣに用いるベアラについての情報などを用いてもよい。前述の機能は、ＭＮまたはリレーＵＥ＃Ｓに構成されるＡＤＰが有してもよい。ＡＤＰに、ＤＣが設定される場合と設定されない場合の機能を集約してもよい。ＭＮまたはリレーＵＥ＃Ｓの構成を容易にできる。このようにすることで、ＭＮで、ＤＣ用のＭＣＧベアラあるいはＳＣＧベアラあるいはスプリットベアラを、リモートＵＥとＮＷ間通信用のＲＢにマッピングすることが可能となる。
　Ｃ－Ｐｌａｎｅのプロトコルについては、ＭＮ、リモートＵＥにおけるＳＤＡＰの代わりにＲＲＣを設ければよい。ＳＲＢに対応したＲＲＣを設けるとよい。ＳＲＢにＤＣが設定される場合はＭＮ終端ベアラのみが設定されてもよい。ＳＲＢのＤＣが可能となる。
　ＭＮとリレーＵＥ＃Ｓ間のプロトコルスタックは、図５５に開示した構成を適宜適用するとよい。
　このようにすることで、１つのｇＮＢと２つのパスで接続したリモートＵＥが、リレーＵＥを介してＮＷ間の通信を可能とする。
　リレーＵＥを介して行うリモートＵＥとＮＷ間の通信において、リモートＵＥが１つのｇＮＢと２つのパスで接続するＤＣの設定方法を開示する。
　リモートＵＥが、ＭＮと、ＳＮの代替とするリレーＵＥ＃Ｓとを用いてＤＣが設定される場合について開示する。１つのパスでリモートＵＥはリレーＵＥ＃１を介してＭｇＮＢと接続し、他の１つのパスでリモートＵＥはリレーＵＥ＃Ｓと接続し、リレーＵＥ＃ＳはＭｇＮＢと接続する場合について開示する。
　ＭＮはリモートＵＥに対してＤＣの設定を行う。ＭＮは、リモートＵＥとの間のＲＢに対してＤＣの設定を行う。該ＲＢは、リモートＵＥとＭＮ間の通信用であってもよい。該ＲＢは、ＳＲＢ　ａｎｄ／ｏｒ　ＤＲＢでもよい。たとえば、ＳＲＢとしてＳＲＢ２であってもよい。
　ＭＮは、ＭＮとリレーＵＥ＃１との間のＤＣ用のＵｕのＲＬＣベアラの設定を行う。ＭＮとリモートＵＥ間のＲＢに対するＤＣ設定に用いる。ＤＣ用のＵｕのＲＬＣベアラとして、既存のＵｕのＲＬＣベアラから修正がなければ、新たな設定を行わなくてもよい。
　ＭＮは、リレーＵＥ＃１とリモートＵＥ間のＤＣ用のＳＬベアラを設定する。該ＤＣ用のＳＬベアラは１つのＳＬベアラとしてもよい。該ＳＬベアラは、ＭＮ用のＳＬベアラとしてもよい。該ＳＬベアラは、ＳＬ　ＲＬＣベアラでもよい。
　ＭＮはリレーＵＥ＃Ｓに対してＤＣ用のＵｕのＲＬＣベアラの設定を行う。該ＤＣ用のＵｕのＲＬＣベアラは、ＭＮとの間のＲＬＣベアラでもよい。
　ＭＮは、リレーＵＥ＃ＳとリモートＵＥ間のＤＣ用のＳＬベアラを設定する。該ＤＣ用のＳＬベアラは１つのＳＬベアラとしてもよい。該ＳＬベアラは、ＳＮ用のＳＬベアラとしてもよい。該ＳＬベアラは、ＳＬ　ＲＬＣベアラでもよい。
　リレーＵＥ＃１はＭＮとＲＲＣ接続状態とするとよい。リレーＵＥ＃ＳはＭＮとＲＲＣ接続状態とするとよい。リモートＵＥはＭＮとＲＲＣ接続状態とするとよい。また、ＭＮは、リモートＵＥがＭＮとＲＲＣ接続状態において、リモートＵＥに対してＤＣ設定を開始する、としてもよい。ＤＣが設定されたリモートＵＥはＣ－ｐｌａｎｅにおいてＭＮを介してＣＮに接続する。
　ＭＮは、リレーＵＥ＃Ｓに対して、リモートＵＥとＭＮ間通信用のＲＢに対するＤＣの設定要求を送信する。該ＤＣの設定要求はＳＮとしての機能の追加要求でもよい。該追加要求はＸｎシグナリングを用いて送信するとよい。Ｆ１シグナリングを用いて送信してもよい。Ｓ－Ｎｏｄｅ　ａｄｄｉｔｉｏｎ　ｒｅｑｕｅｓｔメッセージを用いて送信してもよい。
　ＤＣの設定要求に含める情報は、前述に開示したＳＮの追加要求に含める１７個の情報例を適宜適用するとよい。該情報例におけるＳＮをリレーＵＥ＃Ｓにおきかえるとよい。該情報例におけるリレーＵＥをリレーＵＥ＃１　ａｎｄ／ｏｒ　リレーＵＥ＃Ｓにおきかえるとよい。リレーＵＥをリレーＵＥ＃Ｓとする場合、ＳＮとして機能するリレー＃Ｓが、リモートＵＥとＤＣ設定を行うための情報としてもよい。
　また、前述に開示したＳＮの追加要求に含める１７個の情報例のうち、（１）のリレーＵＥ＃１　ａｎｄ／ｏｒ　リレーＵＥ＃Ｓに関する情報に、リモートＵＥによるリレーＵＥ＃１　ａｎｄ／ｏｒ　リレーＵＥ＃Ｓのメジャメント結果を含んでもよい。また、リレーＵＥ＃１　ａｎｄ／ｏｒ　リレーＵＥ＃ＳによるＭＮのメジャメント結果を含んでもよい。
　このようにすることで、ＭＮはリレーＵＥ＃Ｓに対して、ＤＣ設定要求を送信することが可能となる。また、リレーＵＥ＃Ｓは、ＭＮからＤＣ設定要求を受信することで、たとえば、どのリモートＵＥに対するＤＣかなどを認識可能となる。リレーＵＥ＃ＳはＭＮから受信した情報を用いてＳＮとしてのＤＣ用の設定を行う。
　ＭＮはリレーＵＥ＃Ｓに対してＤＣ用の設定を送信する。ＤＣ用設定は、前述した、１つのパスでリモートＵＥはＭｇＮＢと直接接続し、他の１つのパスでリモートＵＥはリレーＵＥ＃Ｓと接続し、リレーＵＥ＃ＳはＭｇＮＢと接続する場合の、ＭＮからリレーＵＥ＃ＳへのＤＣ用設定を適宜適用するとよい。
　ＭＮはリレーＵＥ＃Ｓに対して、リモートＵＥとリレーＵＥ＃Ｓ間のＳＬベアラの設定を行う。リモートＵＥとリレーＵＥ＃Ｓ間で既存のＳＬベアラがある場合は、該ＳＬベアラの修正を行ってもよい。ＳＬベアラの設定は、ＳＬベアラの修正のための設定であってもよい。ＳＬベアラの設定は、前述した、１つのパスでリモートＵＥはＭｇＮＢと直接接続し、他の１つのパスでリモートＵＥはリレーＵＥ＃Ｓと接続し、リレーＵＥ＃ＳはＭｇＮＢと接続する場合の、ＭＮからリレーＵＥ＃ＳへのＳＬベアラの設定を適宜適用するとよい。
　ＭＮはリレーＵＥ＃Ｓとの間でＸｎあるいはＦ１接続が行われる。ＭＮはリレーＵＥ＃Ｓに対して、該接続に用いる設定情報を送信してもよい。該設定情報として、たとえば、ＧＴＰ-ｕ　ＴＥＩＤやＴＮＬアドレス（ＩＰアドレス）などがある。このようにすることで、ＭＮはリレーＵＥ＃Ｓとの間で、Ｕｕではなく、ＸｎあるいはＦ１によるデータの送受信が可能となる。
　リレーＵＥ＃ＳはリモートＵＥに対するＤＣ設定を行ってもよい。リレーＵＥ＃Ｓは、リモートＵＥに対してリレーＵＥ＃Ｓとの間のＤＣのための設定を行ってもよい。リレーＵＥ＃Ｓは、ＭＮから受信したＤＣ設定要求メッセージに含まれる情報を用いてＤＣ設定を行ってもよい。リモートＵＥに対するＤＣ設定として、リモートＵＥとリレーＵＥ＃Ｓ間のＳＬ　ＲＲＣ設定であってもよい。ＳＬ　ＲＲＣ設定は、たとえば、ＳＬ　ＲＬＣベアラ設定であってもよい。
　リレーＵＥ＃ＳはＭＮに対してＤＣ設定要求に対する応答メッセージを送信する。リレーＵＥ＃ＳがＤＣ設定を実施する場合、ＭＮに対してＤＣ設定要求肯定応答メッセージを送信する。Ｘｎシグナリングを用いて送信するとよい。Ｆ１シグナリングを用いて送信してもよい。ＤＣ設定要求肯定応答メッセージとしてＳ－Ｎｏｄｅ　ａｄｄｉｔｉｏｎ　ｒｅｑｕｅｓｔ　ａｃｋｎｏｗｌｅｄｇｅメッセージを用いてもよい。あるいは、新たなメッセージを設けてもよい。たとえば、Ｒｅｌａｙ（ＤＣ）ｒｅｑｕｅｓｔ　ａｃｋｎｏｗｌｅｄｇｅメッセージとしてもよい。ＤＣ設定要求応答メッセージに含める情報は、前述に開示したＳＮ追加要求応答メッセージに含める情報を適宜適用してもよい。
　リレーＵＥ＃ＳがＤＣ設定を実施できなかった場合、ＭＮに対してＤＣ設定要求拒否応答メッセージを送信する。Ｘｎシグナリングを用いて送信するとよい。Ｆ１シグナリングを用いて送信してもよい。ＤＣ設定要求拒否応答メッセージとしてＳ－Ｎｏｄｅ　ａｄｄｉｔｉｏｎ　ｒｅｑｕｅｓｔ　ｒｅｊｅｃｔメッセージを用いてもよい。あるいは、新たなメッセージを設けてもよい。たとえば、Ｒｅｌａｙ（ＤＣ）ｒｅｑｕｅｓｔ　ｒｅｊｅｃｔメッセージとしてもよい。該メッセージに、たとえば、リモートＵＥに関する情報、理由情報を含めて通知してもよい。
　ＭＮはリレーＵＥ＃１に対してＤＣ用の設定を送信する。ＤＣ用の設定は、実施の形態５で開示した、ＭＮからリレーＵＥ＃１へのＤＣ用の設定を適宜適用するとよい。
　ＭＮはリモートＵＥに対してＤＣ用の設定を送信する。ＤＣ用設定に含める情報例を５つ開示する。
（１）ＲＢに関する情報。
（２）ＵｕのＲＬＣベアラに関する情報。
（３）ＳＮの識別子。
（４）ＡＤＰ設定に関する情報。
（５）（１）～（４）の組合せ。
　これら５つのＤＣ用設定に含める情報は、前述に開示したＤＣ用設定に含める情報例を適宜適用するとよい。
　ただし、（２）のＵｕのＲＬＣベアラに関する情報は無くてもよい。
　ただし、（３）のＳＮの識別子は無くてもよい。ＳＮの識別子として、リレーＵＥ＃Ｓの識別子としてもよい。
　ＭＮはリモートＵＥに対して、リモートＵＥとリレーＵＥ＃１間、および、リモートＵＥとリレーＵＥ＃Ｓ間のＳＬベアラの設定を行う。リモートＵＥとリレーＵＥ＃１間、　ａｎｄ／ｏｒ　リモートＵＥとリレーＵＥ＃Ｓ間で既存のＳＬベアラがある場合は、該ＳＬベアラの修正を行ってもよい。ＳＬベアラの設定は、ＳＬベアラの修正のための設定であってもよい。ＳＬベアラの設定情報例として３つ開示する。
（１）ＳＬのＲＬＣベアラに関する情報。
（２）ＳＬのＡＤＰ設定に関する情報。
（３）（１）と（２）の組合せ。
　ＳＬベアラの設定情報は、前述に開示したＳＬベアラの設定情報例を適宜適用するとよい。
　ＤＣ用のＳＬベアラの設定として、リモートＵＥとリレーＵＥ＃１間のＳＬベアラはＭＮ用のＳＬベアラとしてもよい。リモートＵＥとリレーＵＥ＃Ｓ間のＳＬベアラは、ＳＮ用のＳＬベアラとしてもよい。
　ＳＬベアラの設定をＤＣ用設定に含めてもよい。ＳＬベアラの設定情報をＤＣ用設定情報に含めてもよい。
　ＭＮはリモートＵＥに対してＳＬ　ＲＢの設定は行わなくてよい。ＳＬ　ＲＢに関する情報を送信しなくてよい。ＳＬ　ＰＤＣＰ、ＳＬ　ＳＤＡＰの設定を行わないとしてもよい。ＭＮはリモートＵＥに対して、ＤＣ用として２つのＳＬベアラの設定を行ってもよい。該ＤＣ用の２つのＳＬベアラの設定は、ＭＮ用のＳＬベアラとＳＮ用のＳＬベアラの設定でもよい。
　ＭＮはリモートＵＥに対するＤＣ用の設定　ａｎｄ／ｏｒ　リモートＵＥとリレーＵＥ＃１間、および、リモートＵＥとリレーＵＥ＃Ｓ間のＳＬベアラの設定を行う場合、ＳＮから受信したリレーＵＥ＃ＳとリモートＵＥ間のＳＬベアラの設定情報を用いてもよい。ＳＮにおける負荷状況などを考慮することが可能となる。たとえば、ＭＮは、リモートＵＥとリレーＵＥ＃Ｓ間のＳＬベアラの設定情報については、リレーＵＥ＃Ｓから受信したリモートＵＥとリレーＵＥ＃Ｓ間のＳＬベアラの設定情報と同じとしてもよい。リモートＵＥとリレーＵＥ＃ＳにおけるＳＬベアラの設定が同じとなり、ＳＬ通信における誤動作を低減できる。
　ＭＮからＤＣ用のＳＬベアラの設定情報を受信したリモートＵＥは、リレーＵＥ＃ＳとのＰＣ５接続を確立する。リレーＵＥ＃ＳとＰＣ５接続を確立したリモートＵＥは、リレーＵＥ＃Ｓとの間でＤＣ用のＳＬベアラを設定する。リモートＵＥとＰＣ５接続を確立したリレーＵＥ＃Ｓは、リモートＵＥとの間でＤＣ用のＳＬベアラを設定する。リモートＵＥはリレーＵＥ＃Ｓに対してＳＬ　ＲＲＣ設定を通知してもよい。リレーＵＥ＃ＳはリモートＵＥに対してＳＬ　ＲＲＣ設定を通知してもよい。
　リモートＵＥとＮＷ間のデータ通信は、リレーＵＥ＃１を介したリモートＵＥとＭＮ間のＭＣＧベアラ、あるいは、リレーＵＥ＃Ｓを介したリモートＵＥとＭＮ間のＳＣＧベアラ、あるいは、リレーＵＥ＃１を介したリモートＵＥとＭＮ間とリレーＵＥ＃Ｓを介したリモートＵＥとＭＮ間のスプリットベアラを用いて行われる。
　図５８は、実施の形態６について、リモートＵＥが１つのｇＮＢと２つのパスで接続するＤＣの設定方法例を示すシーケンス図である。リモートＵＥが、ＭＮと、ＳＮの代替とするリレーＵＥ＃Ｓとを用いてＤＣが設定される場合について開示する。１つのパスでリモートＵＥはリレーＵＥ＃１を介してＭｇＮＢと接続し、他の１つのパスでリモートＵＥはリレーＵＥ＃Ｓと接続し、リレーＵＥ＃ＳはＭｇＮＢと接続する場合について開示する。図５８において、図４７、図５６と共通するステップについては同じステップ番号を付し、共通する説明を省略する。ステップＳＴ５００１で、リモートＵＥ、リレーＵＥ＃１、ＭＮ、ＵＰＦ間でデータ通信が行われる。
　ＭＮはリモートＵＥに対してＤＣを設定することを決定する。たとえば、ＭＮはリモートＵＥのメジャメント結果からＤＣに用いるリレーＵＥ＃Ｓを決定する。
　ステップＳＴ５９０１、ステップＳＴ５９０２で、ＭＮとリレーＵＥ＃Ｓ間でＤＣ設定要求およびＤＣ設定要求応答の送受信が行われる。これにより、リレーＵＥ＃ＳでリモートＵＥへのＤＣ設定が行われる。
　ステップＳＴ５００５、ステップＳＴ５００７で、ＭＮとリレーＵＥ＃１間で、ＤＣ用の設定およびＳＬベアラの設定の送受信、ＤＣ設定応答およびＳＬベアラ設定応答の送受信が行われる。リレーＵＥ＃１はＭＮからＤＣ用設定およびＳＬベアラ設定を受信することで、ＭＮとリレーＵＥ＃１間のＤＣ用設定およびリモートＵＥとリレーＵＥ＃１間のＳＬベアラの設定とが可能となる。
　ステップＳＴ５００６、ステップＳＴ５００８で、ＭＮとリモートＵＥ間で、ＤＣ用の設定およびＳＬベアラの設定の送受信、ＤＣ設定応答およびＳＬベアラ設定応答の送受信が行われる。ＳＬベアラ設定の情報に関する設定として、リレーＵＥ＃Ｓから受信したＲＲＣ設定情報を用いてもよい。リモートＵＥはＭＮからＤＣ用設定およびＳＬベアラ設定を受信することで、ＭＮとリモートＵＥ間のＤＣ用設定、リモートＵＥとリレーＵＥ＃１間のＳＬベアラの設定、および、リモートＵＥとリレーＵＥ＃Ｓ間のＳＬベアラの設定が可能となる。
　このようにすることで、リモートＵＥ、リレーＵＥ＃１を介したＭＮ、リレーＵＥ＃Ｓ間でＤＣが行われる。すなわち、ステップＳＴ６１１０で、リモートＵＥ、リレーＵＥ＃１、リレーＵＥ＃Ｓ、ＭＮ、ＵＰＦ間でデータ通信が行われる。設定可能なＤＣはＭＮ終端ベアラのみとしてもよい。リレーＵＥ＃Ｓが直接ＣＮと接続することなく、リレーＵＥ＃Ｓの構成を容易にすることが可能となる。たとえば、ＭＮ終端ＳＣＧベアラの場合、リモートＵＥ、リレーＵＥ＃Ｓ、リレーＵＥ＃１を介したＭＮ、ＵＰＦ間でデータ通信が行われる。たとえば、ＭＮ終端スプリットベアラの場合、リモートＵＥ、リレーＵＥ＃Ｓ、リレーＵＥ＃１を介したＭＮ、ＵＰＦ間でデータ通信が行われる。
　このようにすることで、リモートＵＥが、ＭｇＮＢとリレーＵＥ＃Ｓと接続するＤＣの設定が可能となる。
　本実施の形態のようにすることで、リレーＵＥを介したリモートＵＥとＮＷ間の間接通信においてＤＣが可能となる。これにより、高速大容量化、低遅延化、高信頼性化などの、性能改善が図れる。また、リレーＵＥを介したリモートＵＥとＮＷ間の間接通信において、複数のＲＡＮノードを用いなくてもＤＣが可能となる。リモートＵＥが直接あるいは間接的に複数のＲＡＮノードと接続できないような状況の場合でもＤＣが可能となる。また、リモートＵＥに対するＤＣのため、リレーＵＥが複数のＲＡＮノードと接続しなくてもよい。
　本開示において、ＩＡＢ基地局を用いたマルチキャストの動作が、リレーＵＥを介したリモートＵＥとｇＮＢ間の通信、例えば、リレーＵＥを介した、ｇＮＢからリモートＵＥへのマルチキャストに適用されてもよい。ＢＡＰレイヤの動作が、例えば、アダプテーションプロトコルにおいて行われてもよい。このことにより、例えば、ｇＮＢからリモートＵＥへのマルチキャストにおける無線リソースを削減可能となる。
　本開示における、ＩＡＢ基地局を用いたマルチキャストの動作、および、リレーＵＥを介したリモートＵＥとｇＮＢ間の通信、例えば、リレーＵＥを介した、ｇＮＢからリモートＵＥへの通信の組合せが用いられてもよい。このことにより、例えば、通信システムにおける柔軟性を向上可能となる。ｇＮＢからリモートＵＥへの通信は、ブロードキャストであってもよいし、グループキャストであってもよいし、ユニキャストであってもよい。例えば、ＩＡＢ基地局を用いたマルチキャストとｇＮＢからリモートＵＥへのグループキャストの組合せにより、通信システムにおける効率向上が可能となる。
　本開示において、ｇＮＢあるいはセルとして記載しているが、特に説明の無い限り、ｇＮＢであってもよいしセルであってもよい。
　前述の各実施の形態およびその変形例は、例示に過ぎず、各実施の形態およびその変形例を自由に組合せることができる。また各実施の形態およびその変形例の任意の構成要素を適宜変更または省略することができる。
　例えば、前述の各実施の形態およびその変形例において、サブフレームは、第５世代通信システムにおける通信の時間単位の一例である。サブフレームはスケジューリング単位であってもよい。前述の各実施の形態およびその変形例において、サブフレーム単位として記載している処理を、ＴＴＩ単位、スロット単位、サブスロット単位、ミニスロット単位として行ってもよい。
　例えば、前述の各実施の形態およびその変形例において開示した方法は、Ｖ２Ｘ（Vehicle-to-everything）サービスに限らずＳＬ通信が用いられるサービスに適用してもよい。たとえば、プロキシミティサービス（Proximity-based　service）、パブリックセイフティ（Public　Safety）、ウェアラブル端末間通信、工場における機器間通信など、多種のサービスで用いられるＳＬ通信に適用してもよい。
　本開示は詳細に説明されたが、上記した説明は、すべての局面において、例示であって、限定的なものではない。例示されていない無数の変形例が、想定され得るものと解される。
　２００，２１０　通信システム、２０２　通信端末装置（移動端末）、２０３，２０７，２１３，２１７，２２３－１，２２４－１，２２４－２，２２６－１，２２６－２，７５０　基地局装置（基地局）、２０４　ＭＭＥ／Ｓ－ＧＷ部（ＭＭＥ部）、２０４ａ　ＭＭＥ、２１４　ＡＭＦ／ＳＭＦ／ＵＰＦ部（５ＧＣ部）、２１８　中央ユニット、２１９　分散ユニット、３０１，４０３　プロトコル処理部、３０２　アプリケーション部、３０３，４０４　送信データバッファ部、３０４，４０５　エンコーダー部、３０５，４０６　変調部、３０６，４０７　周波数変換部、３０７－１～３０７－４，４０８－１～４０８－４　アンテナ、３０８，４０９　復調部、３０９，４１０　デコーダー部、３１０，４１１，５０６，５２６　制御部、４０１　ＥＰＣ通信部、４０２　他基地局通信部、４１２　５ＧＣ通信部、５０１　ＰＤＮ　ＧＷ通信部、５０２，５２２　基地局通信部、５０３，５２３　ユーザプレイン通信部、５０４　ＨｅＮＢＧＷ通信部、５０５，５２５　制御プレイン制御部、５０５－１，５２５－１　ＮＡＳセキュリティ部、５０５－２　ＳＡＥベアラコントロール部、５０５－３，５２５－３　アイドルステートモビリティ管理部、５２１　Ｄａｔａ　Ｎｅｔｗｏｒｋ通信部、５２５－２　ＰＤＵセッションコントロール部、５２７　セッション管理部、７５１－１～７５１－８　ビーム、３１１０，３１３０，３２２０，３２２１，３３２０　ＢＡＰ－ＰＤＵ、３１１５，３２１５　機能部、３１２５　ルーティング機能部。

Claims (18)

  1. 　中央ユニットおよび分散ユニットで構成され、アクセス・バックホール統合のドナーとして動作する第１の基地局と、
    　前記アクセス・バックホール統合のノードとして動作する１つ以上の第２の基地局と、
    　を含み、
    　前記中央ユニットが前記分散ユニットおよび前記第２の基地局に対して、通信端末が送受信するデータのルーティングを行うバックホールアダプテーションレイヤにおいて前記中央ユニットから前記通信端末に向けてデータをマルチキャストするためのアドレス設定を行う、
    　ことを特徴とする通信システム。
  2. 　前記中央ユニットは、通信端末が接続された状態の前記第２の基地局に対し、前記バックホールアダプテーションレイヤにおけるマルチキャスト用アドレスを割当てる、
    　ことを特徴とする請求項１に記載の通信システム。
  3. 　前記中央ユニットは、通信端末が接続された状態の前記第２の基地局のうち、他の第２の基地局が接続されていない状態の前記第２の基地局に対し、前記バックホールアダプテーションレイヤにおけるマルチキャスト用アドレスを割当てる、
    　ことを特徴とする請求項１に記載の通信システム。
  4. 　前記中央ユニットは、接続先が同じ複数の前記第２の基地局のそれぞれに対し、前記バックホールアダプテーションレイヤにおけるマルチキャスト用アドレスとして同じアドレスを割当てる、
    　ことを特徴とする請求項１に記載の通信システム。
  5. 　前記中央ユニットは、マルチキャストデータを受信する通信端末が接続された状態の前記第２の基地局に対し、前記バックホールアダプテーションレイヤにおけるマルチキャスト用アドレスを割当てる、
    　ことを特徴とする請求項１に記載の通信システム。
  6. 　前記中央ユニットは、前記分散ユニットまたは通信端末を基準としたときの階層が同じ前記第２の基地局に対し、前記バックホールアダプテーションレイヤにおけるマルチキャスト用アドレスとして同じアドレスを割当てる、
    　ことを特徴とする請求項１に記載の通信システム。
  7. 　前記中央ユニットは、マルチキャストデータの送信先の通信端末までの経路を形成している複数の前記第２の基地局に対し、前記バックホールアダプテーションレイヤにおけるマルチキャスト用アドレスとして同じアドレスを割当てる、
    　ことを特徴とする請求項１に記載の通信システム。
  8. 　前記バックホールアダプテーションレイヤにおけるマルチキャスト用アドレスとして同じアドレスを割当てる条件が複数存在する場合、
    　前記中央ユニットは、２つ以上の前記条件を満たしている前記第２の基地局に対し、満たしている前記条件のそれぞれに対応する２つ以上のマルチキャスト用アドレスを割当てる、
    　ことを特徴とする請求項１に記載の通信システム。
  9. 　マルチキャスト送信の対象データの複製を前記中央ユニットが行う、
    　ことを特徴とする請求項１から８のいずれか一つに記載の通信システム。
  10. 　前記第２の基地局は、送信先の通信端末が同じマルチキャストデータを異なる経路から受信する場合、いずれか一つの経路から受信するマルチキャストデータを対象として転送を行う、
    　ことを特徴とする請求項１から９のいずれか一つに記載の通信システム。
  11. 　第５世代無線アクセスシステムを構成する第１の基地局および第２の基地局と、
    　前記第１の基地局および前記第２の基地局に接続する第１の通信端末と、
    　通信端末同士が直接通信する端末間通信を前記第１の通信端末との間で実施し、前記第１の通信端末を介して前記第１の基地局および前記第２の基地局に同時に接続する第２の通信端末と、
    　を備えることを特徴とする通信システム。
  12. 　第５世代無線アクセスシステムを構成する第１の基地局および第２の基地局と、
    　前記第１の基地局または前記第２の基地局に接続する第１の通信端末と、
    　通信端末同士が直接通信する端末間通信を前記第１の通信端末との間で実施し、前記第１の通信端末を介して前記第１の基地局または前記第２の基地局に接続するとともに、前記第１の通信端末を介さずに前記第１の基地局または前記第２の基地局に接続する第２の通信端末と、
    　を備えることを特徴とする通信システム。
  13. 　前記第２の通信端末は、前記第１の通信端末が接続していない前記第１の基地局または前記第２の基地局に直接接続する、
    　ことを特徴とする請求項１２に記載の通信システム。
  14. 　前記第１の通信端末が接続していない前記第１の基地局または前記第２の基地局に接続する第３の通信端末、
    　を備え、
    　前記第２の通信端末は、前記端末間通信を前記第３の通信端末との間で実施し、前記第３の通信端末を介して前記第１の基地局または前記第２の基地局に接続する、
    　ことを特徴とする請求項１２に記載の通信システム。
  15. 　第５世代無線アクセスシステムを構成する基地局と、
    　前記基地局に接続する第１の通信端末と、
    　通信端末同士が直接通信する端末間通信を前記第１の通信端末との間で実施し、前記第１の通信端末を介して前記基地局に接続するとともに、前記第１の通信端末を介さずに前記基地局に接続する第２の通信端末と、
    　を備えることを特徴とする通信システム。
  16. 　前記第２の通信端末は、前記第１の通信端末を介して前記基地局に接続するとともに、前記基地局に直接接続する、
    　ことを特徴とする請求項１５に記載の通信システム。
  17. 　前記基地局に接続する第３の通信端末、
    　を備え、
    　前記第２の通信端末は、前記第１の通信端末を介して前記基地局に接続するとともに、前記第３の通信端末を介して前記基地局に接続する、
    　ことを特徴とする請求項１５に記載の通信システム。
  18. 　中央ユニットおよび分散ユニットで構成され、アクセス・バックホール統合のドナーとして動作する基地局であって、
    　前記アクセス・バックホール統合のノードとして動作する１つ以上の他の基地局に対して、通信端末が送受信するデータのルーティングを行うバックホールアダプテーションレイヤにおいて前記通信端末に向けてデータをマルチキャストするためのアドレス設定を行う、
    　ことを特徴とする基地局。
PCT/JP2022/021015 2021-06-02 2022-05-20 通信システムおよび基地局 WO2022255133A1 (ja)

Priority Applications (4)

Application Number Priority Date Filing Date Title
EP22815884.6A EP4351191A1 (en) 2021-06-02 2022-05-20 Communication system and base station
CN202280037897.8A CN117356118A (zh) 2021-06-02 2022-05-20 通信系统及基站
JP2023525730A JPWO2022255133A1 (ja) 2021-06-02 2022-05-20
KR1020237039728A KR20240014466A (ko) 2021-06-02 2022-05-20 통신 시스템 및 기지국

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2021092762 2021-06-02
JP2021-092762 2021-06-02

Publications (1)

Publication Number Publication Date
WO2022255133A1 true WO2022255133A1 (ja) 2022-12-08

Family

ID=84323253

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2022/021015 WO2022255133A1 (ja) 2021-06-02 2022-05-20 通信システムおよび基地局

Country Status (5)

Country Link
EP (1) EP4351191A1 (ja)
JP (1) JPWO2022255133A1 (ja)
KR (1) KR20240014466A (ja)
CN (1) CN117356118A (ja)
WO (1) WO2022255133A1 (ja)

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2020027713A1 (en) * 2018-07-30 2020-02-06 Telefonaktiebolaget Lm Ericsson (Publ) Iab nodes with multiple mts – multi-path connectivity
JP2020523887A (ja) * 2017-06-15 2020-08-06 ブラックベリー リミテッドＢｌａｃｋＢｅｒｒｙ Ｌｉｍｉｔｅｄ サイドリンク通信の構成
US20200267795A1 (en) * 2019-02-14 2020-08-20 Lg Electronics Inc. Method and apparatus for handling backhaul link failure in wireless communication system

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2020523887A (ja) * 2017-06-15 2020-08-06 ブラックベリー リミテッドＢｌａｃｋＢｅｒｒｙ Ｌｉｍｉｔｅｄ サイドリンク通信の構成
WO2020027713A1 (en) * 2018-07-30 2020-02-06 Telefonaktiebolaget Lm Ericsson (Publ) Iab nodes with multiple mts – multi-path connectivity
US20200267795A1 (en) * 2019-02-14 2020-08-20 Lg Electronics Inc. Method and apparatus for handling backhaul link failure in wireless communication system

Non-Patent Citations (44)

* Cited by examiner, † Cited by third party
Title
"Scenarios, requirements and KPIs for 5G mobile and wireless system", ICT-317669-METIS/D1.1
3GPP R2-2009145
3GPP R2-2009337
3GPP R3-210017
3GPP R3-211029
3GPP RP-172115
3GPP RP-201038
3GPP RP-201293
3GPP S1-083461
3GPP T S23.287
3GPP TR 23.703
3GPP TR 23.757
3GPP TR 23.799
3GPP TR 36.814
3GPP TR 36.912
3GPP TR 38.801
3GPP TR 38.802
3GPP TR 38.804
3GPP TR 38.836
3GPP TR 38.912
3GPP TS 23.273
3GPP TS 23.303
3GPP TS 23.501
3GPP TS 23.502
3GPP TS 36.300
3GPP TS 36.321
3GPP TS 37.340
3GPP TS 38.211
3GPP TS 38.212
3GPP TS 38.213
3GPP TS 38.214
3GPP TS 38.300
3GPP TS 38.305
3GPP TS 38.321
3GPP TS 38.322
3GPP TS 38.323
3GPP TS 38.331
3GPP TS 38.340
3GPP TS 38.401
3GPP TS 38.413
3GPP TS 38.473
CATT: "Clarification on the Scenarios for NR Sidelink Relay", 3GPP DRAFT; R2-2006609, 3RD GENERATION PARTNERSHIP PROJECT (3GPP), MOBILE COMPETENCE CENTRE ; 650, ROUTE DES LUCIOLES ; F-06921 SOPHIA-ANTIPOLIS CEDEX ; FRANCE, vol. RAN WG2, no. Electronic; 20200817 - 20200828, 7 August 2020 (2020-08-07), Mobile Competence Centre ; 650, route des Lucioles ; F-06921 Sophia-Antipolis Cedex ; France , XP051911539 *
HUAWEI, HISILICON: "Key points on sidelink relay SID", 3GPP DRAFT; RP-192791, 3RD GENERATION PARTNERSHIP PROJECT (3GPP), MOBILE COMPETENCE CENTRE ; 650, ROUTE DES LUCIOLES ; F-06921 SOPHIA-ANTIPOLIS CEDEX ; FRANCE, vol. TSG RAN, no. Sitges, Spain; 20191209 - 20191212, 2 December 2019 (2019-12-02), Mobile Competence Centre ; 650, route des Lucioles ; F-06921 Sophia-Antipolis Cedex ; France , XP051834383 *
VIVO: "Scope and Scenarios of SL relay", 3GPP DRAFT; R2-2007039, 3RD GENERATION PARTNERSHIP PROJECT (3GPP), MOBILE COMPETENCE CENTRE ; 650, ROUTE DES LUCIOLES ; F-06921 SOPHIA-ANTIPOLIS CEDEX ; FRANCE, vol. RAN WG2, no. E-Meeting; 20200817 - 20200828, 7 August 2020 (2020-08-07), Mobile Competence Centre ; 650, route des Lucioles ; F-06921 Sophia-Antipolis Cedex ; France , XP051911887 *

Also Published As

Publication number Publication date
CN117356118A (zh) 2024-01-05
JPWO2022255133A1 (ja) 2022-12-08
EP4351191A1 (en) 2024-04-10
KR20240014466A (ko) 2024-02-01

Similar Documents

Publication Publication Date Title
JP7313281B2 (ja) 通信システム
WO2020031884A1 (ja) 通信システム、通信端末および基地局
WO2018124259A1 (ja) 通信システム
WO2021106761A1 (ja) 通信システム、通信端末および基地局
WO2022113875A1 (ja) 通信システムおよび通信端末
EP4135468A1 (en) Communication system, communication terminal, and base station
WO2022030520A1 (ja) 通信システムおよび通信端末
WO2021106769A1 (ja) 通信システム、基地局および通信端末
WO2023153336A1 (ja) 通信システムおよび基地局
WO2022255133A1 (ja) 通信システムおよび基地局
WO2022210184A1 (ja) 通信システムおよび基地局
WO2022181525A1 (ja) 通信システムおよび通信端末
WO2023095804A1 (ja) 通信システム
WO2022181526A1 (ja) 通信システムおよび基地局
WO2023054394A1 (ja) 通信システム
US20240187960A1 (en) Communication system and base station
WO2021251210A1 (ja) 通信システム、通信端末および管理装置
WO2023013513A1 (ja) 通信システム
KR20240068652A (ko) 통신 시스템

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 22815884

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2023525730

Country of ref document: JP

Kind code of ref document: A

WWE Wipo information: entry into national phase

Ref document number: 18563644

Country of ref document: US

WWE Wipo information: entry into national phase

Ref document number: 202280037897.8

Country of ref document: CN

WWE Wipo information: entry into national phase

Ref document number: 2022815884

Country of ref document: EP

NENP Non-entry into the national phase

Ref country code: DE

ENP Entry into the national phase

Ref document number: 2022815884

Country of ref document: EP

Effective date: 20240102