WO2016151653A1 - 基地局装置および基地局間ゲートウェイ装置 - Google Patents

基地局装置および基地局間ゲートウェイ装置 Download PDF

Info

Publication number
WO2016151653A1
WO2016151653A1 PCT/JP2015/006366 JP2015006366W WO2016151653A1 WO 2016151653 A1 WO2016151653 A1 WO 2016151653A1 JP 2015006366 W JP2015006366 W JP 2015006366W WO 2016151653 A1 WO2016151653 A1 WO 2016151653A1
Authority
WO
WIPO (PCT)
Prior art keywords
base station
information element
message
inter
relay
Prior art date
Application number
PCT/JP2015/006366
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 US15/555,671 priority Critical patent/US10772027B2/en
Priority to EP15886210.2A priority patent/EP3273748B1/en
Priority to CN201580077837.9A priority patent/CN107409439B/zh
Priority to JP2017507123A priority patent/JP6384591B2/ja
Publication of WO2016151653A1 publication Critical patent/WO2016151653A1/ja

Links

Images

Classifications

    • 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
    • H04W36/00—Hand-off or reselection arrangements
    • H04W36/0005—Control or signalling for completing the hand-off
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W36/00—Hand-off or reselection arrangements
    • H04W36/0005—Control or signalling for completing the hand-off
    • H04W36/0055—Transmission or use of information for re-establishing the radio link
    • H04W36/0064—Transmission or use of information for re-establishing the radio link of control information between different access points
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W36/00—Hand-off or reselection arrangements
    • H04W36/04—Reselecting a cell layer in multi-layered cells
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W36/00—Hand-off or reselection arrangements
    • H04W36/08—Reselecting an access point
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W76/00—Connection management
    • 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/16—Gateway arrangements
    • 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

Definitions

  • This disclosure relates to wireless communication, and in particular, to user data packet forwarding between base stations.
  • X2 GW 3rd Generation Partnership Project (3GPP) Release 12 specifies X2 Gateway (X2 GW) (for example, see Non-Patent Document 1).
  • X2 GW establishes a signaling (ie, Stream Control Transmission Protocol (SCTP)) connection with each of a plurality of (H) eNBs, and the plurality of (H) eNBs Exchange signaling messages (ie, X2AP messages) via X2 GW.
  • H) eNB means eNodeB or Home eNodeB.
  • X2 GW does not terminate X2AP procedures except for X2AP Message Transfer procedure.
  • the X2AP context (X2AP contexts) exists only in the two peers (H) eNB (similar to the case where there is no X2 GW).
  • the X2AP context defines an “X2AP association” between two peer (H) eNBs that spans two SCTP connections.
  • the X2AP message transfer procedure (X2AP-Message-Transfer procedure) by X2GW is performed as follows. That is, when the source (H) eNB transmits an X2AP message (excluding the X2AP MESSAGE TRANSFER message) to the target (H) eNB via the X2 GW, the source (H) eNB sends the X2AP message to the X2AP MESSAGE TRANSFER message. Encapsulate it, add routing information (ie, RNL Header), and send the X2AP MESSAGE TRANSFER message to the X2 GW.
  • the routing information i.e., RNL Header
  • the routing information includes both the target (H) eNB ID and the source (H) eNB ID.
  • X2 GW routes the X2AP MESSAGE TRANSFER message based on the target (H) eNB ID.
  • the X2 interface is an interface between base stations after 3GPP Release 8 or later.
  • the X2 interface includes a control plane (signaling) interface (i.e., X2-C interface) and a user plane (data plane) interface (i.e., X2-U interface).
  • X2-C interface for example, preparation for inter-base station handover (ie, X2 handover), control of dual connectivity (eg, establishment, modification and release of UE context, and management of X2 user plane tunnel), and adjacent eNB Used for various settings and maintenance.
  • the X2-C interface uses the X2AP protocol and uses SCTP and Internet Protocol (IP) to transfer X2AP signaling messages.
  • the X2AP protocol is called a Radio Network Layer (RNL) protocol
  • SCTP / IP for transferring the X2AP protocol is called a Transport Network Layer (TNL) protocol.
  • RNL Radio Network Layer
  • TNL Transport Network Layer
  • the X2-U interface forwards user data packets from the source (H) eNB to the target (H) eNB during handover, and the Master eNB (MeNB) and Secondary eNB (SeNB) in Dual connectivity. Used to transfer user data packets (ie, Packet-Data Convergence-Protocol (PDCP) -PDUs) between them.
  • the X2-U interface uses the GPRS / Tunnelling / Protocol / User / Plane (GTP-U) protocol and uses the User / Datagram / Protocol (UDP) and IP to transfer the GTP / Protocol / Data / Unit (GTP-PDU).
  • the GTP-U protocol is a user plane (U-plane) RNL protocol
  • UDP / IP for transferring GTP-U-PDU is a TNL protocol for U-plane.
  • GTP-U and TNL UDP / IP provide tunneling mechanisms. That is, GTP-U encapsulates a user data packet (eg, IP packet) with a GTP-U header, and the encapsulated user data packet (ie, GTP-PDU) is transferred at the TNL UDP / IP layer. .
  • the user data packet may be referred to as a T-PDU.
  • a user data packet (T-PDU) encapsulated by a GTP-U header is one of GTP-PDUs, but in order to distinguish it from GTP-PDUs containing signaling messages between GTP nodes, G- Sometimes called PDU.
  • a GTP-UPDUPDU as a G-PDU or a signaling message may also be referred to as a GTP-U message.
  • Patent Document 1 disclose transfer of user data packets between two peers (H) eNBs via X2 GW.
  • Patent Document 1 describes that a HeNB-GW that relays an S1-MME signaling message and a user data packet between a core network (ie, “Evolved” Packet ”Core (EPC)) and (H) eNB has an X2-C interface and an X2-U. It describes that the interface is also supported.
  • the HeNB-GW described in Patent Literature 1 operates to relay a GTP-PDU (i.e., G-PDU) encapsulating user data packets between two peers (H) eNBs.
  • GTP-PDU i.e., G-PDU
  • Patent Document 1 does not describe details of the relay operation of G-PDU by HeNB-GW.
  • Patent Document 2 describes that a G-PDU is transferred between two (H) eNBs via an X2-GW.
  • X2-GW of Patent Document 2 assigns Tunnel Endpoint Identifier (TEID) to two (H) eNBs at the time of handover preparation, and TEID in GTP-U header of GTP-U PDU received from one (H) eNB. And the GTP-U PDU with the changed TEID is transmitted to the other (H) eNB.
  • TEID Tunnel Endpoint Identifier
  • DL when user data packet (eg, PDCP PDUs) is transferred between base stations (eg, inter-base station handover (eg, X2 handover) when inter-base station gateway (eg, X2-GW) is used
  • base stations eg, inter-base station handover (eg, X2 handover) when inter-base station gateway (eg, X2-GW) is used
  • X2-GW inter-base station gateway
  • the TNL address (e.g., IP address) of one base station can be concealed from the other base station at the time of handover between two base stations (e.g., (H) eNBs). This TNL address concealment may only be required for certain base stations or certain types of base stations.
  • the base station eg, (H) eNB
  • the inter-base station gateway eg, X2-GW
  • the relay processing of the user data packet by the inter-base station gateway means the transfer of the user data packet between the base stations (e.g., (H) eNBs) via the X2 GW.
  • a base station eg, (H) eNB
  • an inter-base station gateway eg, X2-GW
  • X2-GW inter-base station gateway
  • the base station apparatus includes a memory and at least one processor coupled to the memory.
  • the at least one processor is configured to send a first information element to the inter-base station gateway.
  • the first information element indicates whether or not a relay process in which the inter-base station gateway relays a data packet addressed to or from the radio terminal between the base station apparatus and another base station is required. Shown explicitly or implicitly.
  • the inter-base station gateway device includes a memory and at least one processor coupled to the memory.
  • the at least one processor is configured to receive a first information element from at least one of a first base station and a second base station.
  • the first information element needs a relay process for relaying a data packet addressed to or from the wireless terminal between the first base station and the second base station by the inter-base station gateway device. Whether it is done or not is indicated explicitly or implicitly.
  • the method performed by the base station apparatus includes transmitting the first information element to the inter-base station gateway.
  • the first information element indicates whether or not a relay process in which the inter-base station gateway relays a data packet addressed to or from the radio terminal between the base station apparatus and another base station is required. Shown explicitly or implicitly.
  • the method performed by the inter-base station gateway apparatus includes receiving the first information element from at least one of the first base station and the second base station.
  • the first information element needs a relay process for relaying a data packet addressed to or from the wireless terminal between the first base station and the second base station by the inter-base station gateway device. Whether it is done or not is indicated explicitly or implicitly.
  • the program includes a group of instructions (software code) for causing the computer to perform the method according to the third or fourth aspect described above when read by the computer.
  • Transfer message It is a sequence diagram which shows an example of the procedure which notifies the address of the gateway between base stations which concerns on 3rd Embodiment to a target base station. It is a figure which shows an example of a change of X2
  • LTE Long Term Evolution
  • LTE-Advanced systems
  • these embodiments are not limited to LTE / LTE-Advanced systems, but other wireless communication networks or systems such as 3GPP Universal Mobile Telecommunications System (UMTS), 3GPP2 CDMA2000 systems, Global System for mobile Communications ( The present invention may be applied to a GSM (registered trademark) / General packet radio service (GPRS) system, a WiMAX system, and the like.
  • GSM registered trademark
  • GPRS General packet radio service
  • FIG. 1 shows a configuration example of a wireless communication system according to some embodiments including this embodiment.
  • the radio communication system includes (H) eNB1, (H) eNB2, X2 GW3, and EPC4.
  • the X2 GW 3 is configured to establish an SCTP connection with each of the (H) eNBs 1 and 2 in order to relay a signaling message (X2AP message) between the (H) eNBs 1 and 2.
  • the X2 GW 3 is further configured to establish a GTP-U tunnel with each of the (H) eNBs 1 and 2 in order to relay user data packets between the (H) eNBs 1 and 2.
  • Each of eNBs 1 and 2 has an X2-C interface with X2 GW3 and an S1 interface with EPC4.
  • HeNB-GW may be used between at least one of eNB 1 and 2 and EPC 4.
  • the HeNB-GW relays S1-MME signaling and a user data packet (S1-U) between (H) at least one of the eNBs 1 and 2 and the EPC 4.
  • S1-U user data packet
  • a UE handover from (H) eNB1 to (H) eNB2 will be mainly described. Therefore, (H) eNB1 may be called a source (H) eNB, and (H) eNB2 may be called a target (H) eNB.
  • At least one of (H) eNBs 1 and 2 is configured to transmit a first information element (Information Element (IE)) to X2 GW 3.
  • the first information element explicitly or implicitly indicates whether or not the relay processing by X2 ⁇ GW3 is required for forwarding the user data packet of the wireless terminal (User Equipment (UE)).
  • UE User Equipment
  • at the time of handover of the UE from (H) eNB1 to (H) eNB2 at least one of the source (H) eNBs1 and target (H) eNB2 transmits the first information element. Also good.
  • when (H) eNB1, (H) eNB2, and UE support DualDConnectivity at least one of (H) eNBs1 and (H) eNB2
  • the first information element may be transmitted.
  • Relay processing by X2 GW3 is (H) X2-U interface (GTP-U tunnel) 101 between eNB1 and X2 GW3, and (H) X2-U interface (GTP-U tunnel) between eNB2 and X2 GW3 And transferring user data packets (T-PDUs) via 102.
  • the relay of the user data packet by the X2 GW3 may be performed by transferring the user data packet encapsulated by the GTP-U header, that is, the G-PDU.
  • the relay processing by X2 GW3 can also be called X2-U relay, U-plane relay, GTP-U relay, or user plane concentration.
  • the first information element is an explicit or implicit indication indicating the necessity of the U-plane relay by X2 GW3.
  • the display may be flag information in which different values are set depending on whether or not relay processing by X23GW3 is required.
  • the indication is an explicit or implicit relay request that is sent when relaying by X2 GW3 is required and not sent when relaying is not required. Also good.
  • the display may be a combination of multiple information elements.
  • the display includes (H) information elements (eg, Direct Path Availability IE or Direct Path Unavailability IE) indicating whether or not the direct path 100 between eNBs 1 and 2 is available. But you can.
  • the availability of the direct path 100 may be preset in (H) eNBs 1 and 2, for example, by an operator, that is, operations, “administration” and “maintenance” (OAM). Instead, the availability of the direct path 100 may be dynamically determined by (H) eNBs 1 and 2. For example, (H) eNBs 1 and 2 may determine that the direct path 100 cannot be used when the direct path 100 can be used but the throughput is low or the load on the direct path 100 is high.
  • H information elements
  • the display may be, for example, a combination of an information element indicating whether or not the direct path 100 can be used and an information element indicating whether or not data forwarding is necessary (e.g., DL ⁇ ⁇ Forwarding IE or Uplink (UL) GTP Tunnel Endpoint IE).
  • an information element indicating whether or not the direct path 100 can be used e.g., DL ⁇ ⁇ Forwarding IE or Uplink (UL) GTP Tunnel Endpoint IE.
  • FIG. 2 is a sequence diagram showing an example of a procedure (processing 200) for notifying the necessity of relay processing to X2 GW3.
  • (H) eNB1 or 2 transmits an X2AP Message Transfer message to X2 GW3.
  • the X2AP Message Transfer message carries an X2AP Handover Request message from the source (H) eNB1 to the target (H) eNB2 or an X2AP Handover Request Acknowledge message from the target (H) eNB2 to the source (H) eNB1.
  • the X2AP Message Transfer message further includes a display that explicitly or implicitly indicates the necessity of X2-U relay processing by X2 GW3.
  • X2 GW3 can recognize whether or not to prepare for the X2-U relay based on the display.
  • the X2 GW3 receives an indication indicating the necessity of X2-U relay processing together with the X2AP Message Transfer message carrying the Handover Request message or the Handover Request Acknowledge message. Therefore, X2 GW3 can easily prepare a GTP-U tunnel necessary for the X2-U relay by referring to the X2AP Message Transfer message.
  • At least one of (H) eNBs 1 and 2 explicitly indicates whether or not a U-plane (X2-U) relay by X2 GW3 is required or An implicit display is transmitted to X2 ⁇ GW3. Therefore, X2 GW3 can recognize whether or not to perform U-plane (X2-U) relay based on the display.
  • the UE when at least one of (H) eNBs1 and 2 needs to transfer a user data packet of a radio terminal (UE) from (H) eNB1 to (H) eNB2, the UE It may be configured to determine whether to use the relay processing by X2 GW3 for forwarding the user data packet. In other words, (H) eNBs 1 and 2 use either the relay path (101 and 102) or the direct path (100) via X2 GW3 for forwarding user data packets from (H) eNB1 to (H) eNB2. It may be configured to select whether to use.
  • the source (H) eNB1 targets the user data packet using the direct path between (H) eNBs1 and 2, that is, the X2-U interface (GTP-U tunnel) 100 ( H) You may forward to eNB2.
  • the source (H) eNB1 decides to start the handover of the UE to (H) eNB2, whether to use the U-plane (X2-U) relay process by X2 GW3 You may judge.
  • the target (H) eNB2 receives a handover request from the source (H) eNB1, the target (H) eNB2 determines whether to use the U-plane (X2-U) relay process by the X2 GW3. May be.
  • (H) eNB1 receives a request for bearer establishment (eg, S1AP: Initial Context Setup Request) for UE supporting Dual connectivity from EPC4, U2-plane (X2- U) It may be determined whether or not to use relay processing. Instead of this, whether to use the U-plane (X2-U) relay processing by X2 GW3 may be determined in advance for each pair of (H) eNBs.
  • a request for bearer establishment eg, S1AP: Initial Context Setup Request
  • X2- U It may be determined whether or not to use relay processing. Instead of this, whether to use the U-plane (X2-U) relay processing by X2 GW3 may be determined in advance for each pair of (H) eNBs.
  • (H) eNB1 or 2 or both are X2 depending on the state of the direct path 100 (eg, availability of the direct path 100, throughput of the direct path 100, or load of the direct path 100). Whether to use U-plane (X2-U) relay processing by GW3 may be selected. In other words, when (H) eNB 1 or 2 or both determine whether to use (or require) the U-plane (X2-U) relay processing by X2XGW3, the direct path 100 May be considered.
  • (H) eNB1 or 2 uses the U-plane (X2 GW3) when the throughput of direct path 100 between base stations is sufficiently larger than the throughput of path 101 or 102 between (H) eNB1 and X2 GW3.
  • X2-U It may be decided not to use relay processing. Thereby, an increase in delay due to unnecessary U-plane relay can be suppressed.
  • (H) eNB1 is a U-plane (X2-U) relay by X2 GW3 when (H) eNB1's TNL address (eg, IP address) needs to be hidden from (H) eNB2 Processing may be used to perform forwarding via the direct path 100 when TNL address concealment is not necessary.
  • (H) eNB2 performs U-plane (X2-U) relay processing by X2 GW3 based on the necessity of concealing the TNL address (eg, IP address) of (H) eNB2 from (H) eNB1. You may choose whether to use or not. In other words, when (H) eNB1 or 2 or both decide whether to use (or require) the U-plane (X2-U) relay processing by X2 GW3, The need for concealment may be considered.
  • the source (H) eNB 1 may need to conceal its TNL address (e.g., IP address) from the target (H) eNB 2 during handover.
  • the target (H) eNB2 may need to hide its TNL address (e.g., IP address) from the source (H) eNB1.
  • This TNL address concealment may only be required for certain base stations or certain types of base stations.
  • the HeNB can be installed in the end user's house or building, not in the station building (site) managed by the carrier. For this reason, the HeNB may be modified by a malicious user, and cannot always be said to be a device whose security is sufficiently guaranteed. Therefore, informing the HeNB of the X2-U TNL address of the macro eNB at the time of handover may cause a security risk such that the macro eNB receives a Denial of Service (DoS) attack.
  • DoS Denial of Service
  • the source (H) eNB1 is a macro eNB and the target (H) eNB2 is a HeNB
  • the source (H) eNB1 decides to use the U-plane (X2-U) relay process by X2 GW3. May be.
  • the source (H) eNB1 is a macro eNB and the target (H) eNB2 is also a macro eNB
  • the source (H) eNB1 does not use the U-plane (X2-U) relay processing by X2 GW3. You may decide. Thereby, the security risk resulting from notifying HeNB of the X2-U TNL address of the macro eNB can be suppressed.
  • (H) eNB1 or 2 or both perform U-plane (X2-U) relay processing by X2 GW3 based on the X2 GW3 U-plane relay capability (U-plane Relay Capability). You may select whether to use. In other words, when (H) eNB1 or 2 or both decide whether to use (or require) the U-plane (X2-U) relay processing by X2 GW3, The presence or absence of U-plane relay capability may be considered.
  • At least one of (H) eNBs 1 and 2 is the U-plane by X2 GW3 at the time of UE handover from (H) eNB1 to (H) eNB2.
  • (X2-U) It may be configured to determine whether to use relay processing. Accordingly, at least one of (H) eNBs 1 and 2 can select whether to use the U-plane (X2-U) relay process by X2XGW3.
  • FIG. 3 is a flowchart showing an example of operation of the source (H) eNB 1 (process 300).
  • (H) eNB1 determines the start of the handover of the UE to the target (H) eNB2.
  • block 302 it is determined whether or not U2-plane (X2-U) relay processing by X2 GW3 is required at the time of the handover.
  • the source (H) eNB1 When U-plane (X2-U) relay processing is required (YES in block 302), the source (H) eNB1 sends a transfer message (ie, X2AP Message Transfer message) carrying a handover request (ie, Handover Request message). ) Include an explicit or implicit relay request (block 303). In block 304, the source (H) eNB1 sends a transfer message (including a relay request) carrying a handover request to X2 GW3. On the other hand, if U-plane (X2-U) relay processing is not required (NO in block 302), the source (H) eNB1 sends a transfer message (not including the relay request) carrying the handover request to X2. Transmit to GW3 (block 305).
  • FIG. 4 is a flowchart showing an example of operation of the X2 GW3 (processing 400).
  • X2 GW3 receives a transfer message (i.e., X2AP Message Transfer message) carrying a handover request (i.e., Handover Request message) from source (H) eNB1.
  • X2 GW3 checks whether or not a relay request is included in the received transfer message. If the forwarding message includes a relay request (YES at block 402), X2 GW3 adds an indication to the forwarding message (carrying the handover request) indicating that U2-plane (X2-U) relaying by X2 GW3 will occur. This is transmitted to the target (H) eNB2.
  • the indication that the U2-plane (X2-U) relay is performed by X2 GW3 is simple flag information that indicates whether the U-plane (X2-U) relay is performed. There may be.
  • the indication that the U-plane (X2-U) relay is performed by X2 GW3 is X2 transport bearer (ie, GTP -The endpoint setting on the X2 GW3 side regarding (U bearer) may be included.
  • the endpoint setting includes a TNL address (e.g., IP address) and TEID.
  • the endpoint configuration may be only DL GTP tunnel endpoint configuration for the X2 transport bearer used for downlink (DL) user data packet forwarding, or it may be used for uplink (UL) user data packet forwarding. It may further include UL ⁇ ⁇ ⁇ ⁇ GTP tunnel endpoint configuration for X2 transport bearers.
  • the X2 GW3 sends the endpoint setting on the X2 GW3 side regarding the X2 transport bearer (ie, GTP-U bearer) to the target (H) eNB2 together with the transfer message carrying the handover request. can get.
  • the target (H) eNB2 may have an Access Control List (ACL) functionality.
  • ACL Access Control List
  • the target (H) eNB 2 accepts a connection from the transmission node only when the source address of the transmission node is already known in the target (H) eNB 2.
  • the target (H) eNB2 uses the ACL function to transmit the TNL UDP / IP packet carrying the G-PDU transmitted from X2 GW3.
  • X2 GW3 is the upstream side of data forwarding, but the X2 GW3 side endpoint setting related to the X2 transport bearer (ie, GTP-U bearer) is notified to the target (H) eNB2 first. Good.
  • the target (H) eNB 2 can update the ACL so as to accept the connection from the X2-ULTNL address of the X2 GW3.
  • An ACL can also be referred to as a packet filter or firewall setting.
  • X2 GW3 transmits the transfer message received from the source (H) eNB1 to the target (H) eNB2 as it is (block 404). That is, the transfer message transmitted at block 404 does not include an indication indicating that the U-plane (X2-U) relay is performed by X23GW3.
  • FIG. 5 is a flowchart showing an example of operation of the target (H) eNB 2 (process 500).
  • the target (H) eNB2 receives a transfer message (i.e., X2AP Message Transfer message) carrying a handover request (i.e., Handover Request message) from X2 GW3.
  • a transfer message i.e., X2AP Message Transfer message
  • handover request i.e., Handover Request message
  • the target (H) eNB2 updates its ACL to accept the connection from the X2-U TNL address of X2 GW3.
  • the target (H) eNB 2 transmits a transfer message (i.e., “X2AP” Message “Transfer message”) carrying a handover request acknowledgment (i.e., “Handover” Request “Acknowledge message) to the“ X2 ”GW 3
  • the handover request acknowledgment i.e., “Handover” Request ”Acknowledge message
  • the handover request acknowledgment includes the DL—GTP tunnel endpoint setting of the target (H) eNB2.
  • the handover request acknowledgment i.e., Handover Request Acknowledge message
  • the handover request acknowledgment includes the UL GTP tunnel endpoint setting of the target (H) eNB2.
  • the DL GTP tunnel endpoint setting of the target (H) eNB 2 includes the TNL address and TEID related to the GTP-U tunnel for receiving the DL user data packet forwarded from the source (H) eNB 1.
  • the UL GTP tunnel endpoint configuration of the target (H) eNB2 includes the TNL address and TEID related to the GTP-U tunnel for receiving the UL user data packet forwarded from the source (H) eNB1.
  • the forward message carrying the handover request acknowledgment message transmitted in block 504 contains an additional information element indicating the same target (H) eNB2 GTP tunnel endpoint configuration as described in the handover request acknowledgment message. May be included. Although such a message structure is redundant, there is an advantage that X2 GW3 does not have to decode or refer to the handover request approval message.
  • the message used for transmitting the relay request in FIG. 3 may be an X2AP message different from the X2APXMessage Transfer message.
  • the relay request may be set in a Handover Request message carried by an X2AP Message Transfer message.
  • the message used for transmission of the endpoint setting of X2 GW3 may be an X2AP message different from the X2AP Message Transfer message.
  • the endpoint setting of X2 GW3 may be set in a Handover Request message carried by an X2AP Message Transfer message.
  • FIGS. 3 to 5 show an example of determining whether or not the source (H) eNB1 uses (or requests) the U-plane (X2-U) relay by X2 GW3 at the time of the handover request. Indicated. Similarly, when a handover request is received from the source (H) eNB1 via the X2 GW3, the target (H) eNB2 uses the U-plane (X2-U) relay by the source (H) eNB1 by the X2 GW3. Whether to use (or to request) may be determined.
  • the target (H) eNB2 requires the U-plane (X2-U) relay by the X2 GW3. You may determine no.
  • FIG. 6 is a flowchart showing an example of the operation (process 600) including the necessity determination of the U-plane (X2-U) relay performed by the target (H) eNB2.
  • the target (H) eNB2 receives a transfer message (i.e., X2AP Message Transfer message) carrying a handover request (i.e., Handover Request message) from X2 GW3.
  • the target (H) eNB2 determines whether or not U2-plane (X2-U) relay processing by X2 GW3 is required.
  • the target (H) eNB2 When U-plane (X2-U) relay processing is required (YES in block 602), the target (H) eNB2 transmits a transfer message (ie, X2AP Message) carrying a handover request acknowledgment (ie, Handover Request Acknowledge message). An explicit or implicit relay request is included in the Transfer message (block 603). In block 604, the target (H) eNB2 sends a transfer message (including a relay request) carrying the handover request acknowledgment to X2 GW3. On the other hand, if U-plane (X2-U) relay processing is not required (NO in block 602), the target (H) eNB2 sends a transfer message (not including the relay request) carrying the handover request acknowledgment. Transmit to X2 GW3 (block 605).
  • X2 GW3 when a transfer message (including a relay request) carrying the handover request approval is received from the target (H) eNB2 may be the same as in FIG. However, as described with reference to FIG. 5, the handover request acknowledgment (i.e., “Handover Request” Acknowledge message) includes the GTP tunnel endpoint setting of the target (H) eNB2. In some implementations, in the process corresponding to block 403, X2 GW3 sets the GTP tunnel endpoint of target (H) eNB2 described in the Handover Request Acknowledge message to the GTP tunnel endpoint of X2 GW3. It may be rewritten depending on the setting.
  • X2 GW3 does not modify the GTP tunnel endpoint setting of target (H) eNB2 described in the Handover Request Acknowledge message, and ends the end of X2 GW3.
  • An additional information element indicating the point setting may be included in the X2AP Message Transfer message. In this case, if the source (H) eNB1 updates the X2 transport bearer context according to the additional information element and ignores the GTP tunnel endpoint setting of the target (H) eNB2 described in the Handover Request Acknowledge message Good.
  • X2-U U-plane
  • X2 GW3 U-plane (X2-U) relay
  • X2 GW3 is described in the Handover Request Acknowledge message. It is preferable to modify the GTP tunnel end point setting of the target (H) eNB2 that is being used. Thereby, the concealment from the source (H) eNB1 of the TNL address of the target (H) eNB2 can be performed reliably.
  • FIGS. 3 to 6 show specific examples of operations of (H) eNB1, (H) eNB2, and X2 GW3 in handover.
  • specific examples of the operations of (H) eNB1, (H) eNB2, and X2 GW3 described using FIGS. 3 to 6 are UEs that support Dual connectivity. It may be applied when performing bearer establishment.
  • (H) eNB1 determines whether or not to use U-plane (X2-U) relay processing by X2 GW3 in response to receiving a bearer establishment request for UE supporting Dual connectivity from EPC4. You may judge.
  • (H) eNB1 may include an explicit or implicit relay request in a transfer message (i.e., X2AP Message Transfer message) carrying an X2AP message for establishing a UE context for Dual connectivity.
  • FIG. 7 is a table showing an example of a combination of the operations of the source (H) eNB 1 and X 2 GW 3 and their activation conditions.
  • the source (H) eNB 1 determines whether the U-plane (X2-U) relay is used (or whether it is requested), and whether or not the direct path 100 can be used (Direct Path (Availability) and X2-GW3 relay capability (U-plane Relay Capability) are taken into consideration.
  • Case 1 shown in FIG. 7 is a case where the direct path 100 is available and the X2 GW3 has a relay capability.
  • Case 2 shown in FIG. 7 is a case where the direct path 100 can be used and the X2 GW3 does not have a relay capability.
  • the source (H) eNB1 since the direct path 100 is available, the source (H) eNB1 does not set an explicit or implicit relay request for X2 GW3 in the X2AP Message Transfer message (carrying a Handover Request message). . Therefore, X2 GW3 does not implement the U-plane (X2-U) relay for DL data forwarding.
  • Case 3 shown in FIG. 7 is a case where the direct path 100 cannot be used and the X2 GW3 has a relay capability.
  • the direct path 100 cannot be used, but since the X2 GW3 has a relay capability, the source (H) eNB1 sends an explicit or implicit relay request to the X2 GW3 as an X2AP Message Transfer message (Handover Request message). To carry). Therefore, X2 GW3 implements a U-plane (X2-U) relay for DL data forwarding.
  • X2-U U-plane
  • Case 4 shown in FIG. 7 is a case where the direct path 100 cannot be used and the X2 GW3 does not have a relay capability.
  • the source (H) eNB1 since X2-U data forwarding is not possible, the source (H) eNB1 does not set an explicit or implicit relay request for X2 GW3 in the X2AP Message Transfer message (carrying a Handover Request message). Therefore, X2 GW3 does not implement the U-plane (X2-U) relay for DL data forwarding.
  • the implicit relay request (or relay indication) for X2 GW3 may include a combination of multiple information elements.
  • the implicit relay request (or relay indication) for X2XGW3 may be a combination of Direct Path Unavailability IE and DL Forwarding IE.
  • Direct Path Unavailability IE shown in FIG. 8 is set when the direct path 100 is unavailable.
  • Direct Path Unavailability IE may be 1-bit flag information.
  • the DL Forwarding IE shown in FIG. 8 may be the DL Forwarding IE included in the X2AP: Handover Request message in the current 3GPP specifications, or is an information element newly added to the X2AP Message Transfer message. May be.
  • Cases 1 to 4 shown in FIG. 8 correspond to cases 1 to 4 shown in FIG. That is, Case 1 shown in FIG. 8 is a case where the direct path 100 is available and X2 GW3 has a relay capability. Case 2 shown in FIG. 8 is a case where the direct path 100 can be used and the X2 GW3 does not have a relay capability.
  • the source (H) eNB 1 since the direct path 100 is available, the source (H) eNB 1 does not set Direct Path Unavailability IE.
  • DL Forwarding IE is set in order to notify the target (H) eNB2 that DL forwarding is performed (via the direct path 100).
  • Case 3 shown in FIG. 8 is a case where the direct path 100 cannot be used and the X2 GW3 has a relay capability.
  • Direct path 100 since Direct path 100 is not usable, Direct Path Unavailability IE is set.
  • the source (H) eNB1 determines that DL forwarding via the X2 GW3 is possible, and therefore (via the X2 GW3) DL DL Forwarding IE is set in order to notify the target (H) eNB2 that forwarding is performed.
  • Case 4 shown in FIG. 8 is a case where the direct path 100 cannot be used and the X2 GW3 does not have a relay capability. Therefore, in case 4, the source (H) eNB1 sets Direct Path Unavailability IE and does not set DL Forwarding IE.
  • X2 GW3 refers to Direct Unavailability IE and DL Forwarding IE, and when these are set together, U-Plane (X2-U) relay related to DL data forwarding may be performed. Therefore, as in the example of FIG. 7, the U-Plane (X2-U) relay related to DL data forwarding is performed only in case 3 of FIG. 8, and in cases 1, 2 and 4 of FIG. (X2-U) Relay is not implemented.
  • FIG. 9 is a table showing an example of a combination of operations of the target (H) eNB 2 and X 2 GW 3 and their activation conditions.
  • the example of FIG. 9 regarding the target (H) eNB 2 corresponds to the example of FIG. 7 regarding the source (H) eNB 1. Therefore, U-Plane (X2-U) relay for UL data forwarding is implemented only in case 3 of FIG. 9, and U-Plane (X2-U) relay for UL data forwarding is implemented in cases 1, 2, and 4 of FIG. Not.
  • the implicit relay request (or relay display) from the target (H) eNB2 to X2 GW3 is a combination of Direct Path Unavailability IE and UL GTP TunnelEndpoint IE.
  • the UL-GTP-Tunnel Endpoint IE shown in FIG. 10 may be the UL-GTP-Tunnel Endpoint IE included in the X2AP: Handover Request Acknowledge message in the current 3GPP specifications, or is newly added to the X2AP Message Send Transfer message. May be an information element.
  • FIG. 10 relating to the target (H) eNB 2 corresponds to the example of FIG. 8 relating to the source (H) eNB 1 except for the difference between DL Forwarding IE and UL GTP Tunnel Endpoint IE.
  • X2 GW3 refers to Direct Path Unavailability IE and UL GTP Tunnel Endpoint IE, and implements U-Plane (X2-U) relay for UL data forwarding when these are set together. do it. Therefore, U-Plane (X2-U) relay for UL data forwarding is implemented only in case 3 of FIG. 10, and U-Plane (X2-U) relay for UL data forwarding is implemented in cases 1, 2, and 4 of FIG. Not.
  • FIGS. 7 to 10 show specific examples of operations of (H) eNB1, (H) eNB2, and X2 GW3 in handover.
  • specific examples of the operations of (H) eNB1, (H) eNB2, and X2 GW3 described with reference to FIGS. 7 to 10 are UEs that support Dual connectivity. It may be applied when performing bearer establishment.
  • (H) eNB1 and (H) eNB2 determine whether to use (or request) the U-plane (X2-U) relay. In doing so, consider the relay capability of X2 GW3.
  • the presence or absence of the relay capability of X2 GW3 may be preset in (H) eNBs 1 and 2 by an operator, that is, operations, administration and maintenance (OAM). Instead, X2 GW3 may notify (H) eNBs 1 and 2 of the presence or absence of its own relay capability. That is, X2 GW3 may transmit a signaling message including an information element (IE) indicating the presence or absence of its own relay capability to (H) eNBs 1 and 2.
  • IE information element
  • X2XGW3 informs (H) eNBs1 and 2 of its relay capability in the procedure of registering (H) eNBs1 and 2 with X2 GW3. Also good.
  • FIG. 11 is a sequence diagram showing an example of a procedure (process 1100) for notifying the presence or absence of relay capability from the X2 GW3 to the (H) eNBs 1 and 2.
  • (H) eNBs1 (2) transmits a registration request to X2 GW3 ((H) eNB registration).
  • the registration request includes the source (H) eNB identifier (ie, Global eNB ID) included in the registration request and the TNL address (eg, IP address) of the source (H) eNB used to transmit the registration request. Save the mapping.
  • X2 GW3 transmits a response to the registration request ((H) eNB registration response).
  • the response includes an information element (U-plane Relay Capability) indicating the presence / absence of the relay capability of X2 GW3.
  • U-plane Relay Capability an information element indicating the presence / absence of the relay capability of X2 GW3.
  • the eNBs 1 (2) recognizes the presence or absence of the U2-plane (X2-U) relay capability of the X2 GW3 by receiving the response in the block 1102.
  • FIG. 12 is a sequence diagram showing another example (process 1200) of notifying the presence or absence of relay capability from X2 GW3 to (H) eNBs 1 and 2.
  • the X2AP Message ⁇ ⁇ ⁇ ⁇ ⁇ Transfer message is used to register (H) eNB with X2 GW.
  • FIG. 12 shows an example in which an X2AP Message Transfer message is used in the same way as 3GPP Release 12. That is, in block 1201, (H) eNB1 (2) requesting registration includes Source (H) eNB ID in RNL Header IE, but does not include Target (H) eNB ID in RNL Header IE, and Send X2AP Message Transfer message that does not include X2AP Message.
  • X2 GW3 sends the modified X2AP Message Transfer message.
  • the modified X2AP Message Transfer message includes the Target (H) eNB ID in the RNL Header IE and the newly defined U-plane Relay Capability IE, but the Source (H) eNB ID in the RNL Header IE Sends an X2AP Message Transfer message that does not contain X2AP Message.
  • H By receiving the X2AP2Message ⁇ ⁇ ⁇ Transfer message in block 1202, eNBs1 (2) recognizes the presence or absence of the U2 plane (X2-U) relay capability of X2 GW3.
  • FIG. 13A and FIG. 13B are sequence diagrams showing an example (process 1300) of the X2 handover procedure according to the present embodiment.
  • the procedure shown in FIGS. 13A and 13B is normal except that the user data packet is forwarded from the source (H) eNB1 to the target (H) eNB2 via X2 GW3 (blocks 1307 and 1308).
  • This is the same as the X2 handover procedure via X2 GW. That is, in block 1301, the source (H) eNB1 sends an X2AP Message Transfer message carrying a Handover Request message to X2 GW3.
  • the X2AP Message Transfer message may include an information element that explicitly or implicitly indicates whether or not a U-plane (X2-U) relay is necessary.
  • X2 GW3 forwards the X2AP Message Transfer message carrying the Handover Request message to the target (H) eNB2.
  • the X2 GW3 may update the information element in the X2AP Message Transfer message in the block 1302 according to whether or not the U-plane (X2-U) relay is performed. May be added.
  • the target (H) eNB2 sends an X2AP Message Transfer message carrying the Handover Request Acknowledge message to the X2 GW3.
  • the X2AP Message Transfer message may include an information element that explicitly or implicitly indicates whether or not a U-plane (X2-U) relay is necessary.
  • X2 GW3 forwards the X2AP Message Transfer message carrying the Handover Request Acknowledge message to the source (H) eNB1.
  • the X2 GW3 may update the information element in the X2AP Message Transfer message in the block 1304 according to whether or not the U-plane (X2-U) relay is performed. May be added.
  • the source (H) eNB 1 responds to the reception of the Handover Request Acknowledge message and transmits a handover instruction (Handover Command) to the UE not shown.
  • the source (H) eNB1 sends an X2AP Message Transfer message carrying the SN Status Transfer message to X2 GW3.
  • the SN Status Transfer message indicates a Sequence Number (SN) of an uplink / downlink Packet Data Convergence Protocol (PDCP) PDU that has not been delivered to the UE.
  • X2 GW3 forwards the X2AP Message Transfer message carrying the SN Status Transfer message to the target (H) eNB2.
  • the source (H) eNB1 forwards the uplink / downlink user data packet that has not been delivered to the UE to the target (H) eNB2 via X2 GW3. That is, in block 1307, the source (H) eNB1 sends the G-PDU encapsulating the uplink / downlink user data packet to the X2 GW3 via the GTP-U tunnel between the source (H) eNB1 and X2 GW3. Send. In block 1308, X2 GW3 transfers the G-PDU received from the source (H) eNB1 to the target (H) eNB2 via the GTP-U tunnel between the target (H) eNB2 and X2 GW3.
  • the X2GW3 updates the source TNL address (ie, the TNL address of the source (H) eNB1) assigned to the G-PDU received from the source (H) eNB1 with the TNL address of the X2GW3. Then, the source TEID (ie, TEID of source (H) eNB1) is updated with the TEID of X2GW3.
  • X2GW3 updates the target TNL address (ie, the TNL address of X2GW3) given to the G-PDU received from the source (H) eNB1 with the TNL address of the target (H) eNB2, and the target TEID (ie, X2GW3 TEID) is updated with the target (H) eNB2 TEID.
  • the target (H) eNB2 receives a handover confirmation (HandoverUEConfirm) message from the UE.
  • UE can transmit a UL user data packet to target (H) eNB2, and can receive DL user data packet from target (H) eNB2.
  • the target (H) eNB2 informs the EPC4 of the UE serving cell change and requests an Evolved Packet System (EPS) bearer path change to send an S1AP: Path Switch Request message to the EPC4 (ie, Mobility Management). Send to Entity (MME) 5).
  • the MME 5 signals Serving Gateway (S-GW) (not shown) and corrects the EPS bearer path (that is, the S1 bearer path).
  • S-GW Serving Gateway
  • the MME 5 sends an S1AP: APPath Switch Request Acknowledge message to the target (H) eNB2.
  • the target (H) eNB2 in response to receiving the Path Switch Request Acknowledge message, sends an X2AP Message Transfer message carrying the UE Context Release message to the X2 GW3.
  • the X2 GW3 forwards the X2AP Message Transfer message carrying the UE ContextaseRelease message to the source (H) eNB1.
  • the source (H) eNB 1 releases radio resources allocated to the UE in response to receiving the UE Context Release message.
  • the target (H) eNB 2 may release the GTP-U tunnel setting for data forwarding in response to transmission of the UE Context Release message (block 1312).
  • X2 ⁇ GW3 may release the GTP-U tunnel setup for data forwarding in response to receiving an X2AP Message Transfer message carrying a UE Context Release message (block 1312).
  • the source (H) eNB 1 may release the GTP-U tunnel setup for data forwarding in response to receiving the UE Context Release message (block 1313).
  • FIG. 14 shows an example of changing the X2AP2Message Transfer message.
  • U-Plane Relay Capability IE is used by X2 GW3 to inform (H) eNBs 1 and 2 of the presence or absence of U-plane (X2-U) relay capability.
  • Direct Path Unavailability IE is used by (H) eNBs 1 and 2 to inform X2 GW 3 of the availability of the direct path 100.
  • E-RABs To Be Setup List” IE is used by X2 GW3 to inform (H) eNBs 1 and 2 of the endpoint settings of X2 GW3.
  • “E-RABs“ To ”Be“ Setup ”Item” IE includes “E-RAB ID” IE, “UL GTP Tunnel Endpoint” IE, and “DL GTP Tunnel Endpoint” IE.
  • “UL GTP TunnelEndpoint” IE indicates the X2 GW3 Endpoint setting (ie, TNL address and TEID) regarding the X2 transport bearer for UL data (UL PDUs) forwarding.
  • “DL GTP Tunnel Endpoint” IE indicates the X2 GW3 Endpoint setting (ie, TNL address and TEID) regarding the X2 transport bearer for DL data (DL PDUs) forwarding.
  • the X2AP Message Transfer message may be extended to include “Message Type of X2AP Message” IE.
  • “Message Type of X2AP Message” IE indicates the type of the X2AP message carried by the X2AP Message Transfer message.
  • X2XGW3 can operate so as to refer to or decode only the necessary X2AP message. That is, only when “Message Type of X2AP Message” IE indicates a Handover Request message or a Handover Request Acknowledge message, “X2AP message” IE in the X2AP Message Transfer message may be referred to or decoded.
  • the X2AP Message Transfer message may be extended to include “DL Forwarding” IE.
  • “DL Forwarding” IE is used by the source (H) eNB1 when the “X2AP message” HandIE carries a Handover Request message.
  • “DL Forwarding” IE indicates the same content as “DL Forwarding” IE included in the Handover Request message in “X2AP message” IE. This eliminates the need for X2 GW3 to decode or refer to the Handover Request message in “X2AP message” IE in order to confirm “DL Forwarding” IE.
  • the X2AP Message Transfer message may be extended to include “E-RAB Level QoS Parameters” IE shown in FIG. 15B.
  • “E-RAB Level QoS Parameters” IE is used by the source (H) eNB 1 when the “X2AP message” IE carries a Handover Request message.
  • “E-RAB Level QoS Parameters” IE indicates the same contents as “E-RAB Level QoS Parameters” IE included in the “Request message” in the “X2AP message” IE.
  • the “E-RAB ID” IE shown in FIG. 15B may be used by the source (H) eNB1 when the “X2AP message” IE carries a Handover Request message.
  • “E-RAB ID” IE indicates the same content as “E-RAB ID” IE included in the Handover Request message in “X2AP message” IE.
  • the “E-RAB ID” IE shown in FIG. 15B may be used by the target (H) eNB2 when the “X2AP message” IE carries a Handover Request Acknowledge message.
  • “E-RAB ID” IE indicates the same contents as “E-RAB ID” IE included in the Handover Request Acknowledge message in the “X2AP message” IE.
  • the “DL GTP TunnelpointEndpoint” IE and “UL GTP Tunnel Endpoint” ⁇ IE shown in FIG. 15B are used by the target (H) eNB2 when the “X2AP message” IE carries a Handover Request Acknowledge message. May be used.
  • “DL GTP Tunnel Endpoint” IE and “UL GTP Tunnel Endpoint” IE are “DL GTP Tunnel Endpoint” IE and “UL GTP Tunnel Endpoint” IE included in the “Handover2Request Acknowledge message” Indicates the same content.
  • X2 GW3 only needs to transparently transfer X2AP Message IE, and does not need to refer to or decode X2AP Message IE. If X2 GW3 always references or decodes X2AP Message IE, it may consume a lot of processing power of X2 GW3, and a protocol error occurs because the protocol version of X2 GW3 and the X2AP protocol version between (H) eNB are different. Might do. X2 GW3 can avoid the occurrence of these problems by transparently transferring X2AP Message IE.
  • X2 GW3 may detect the presence / absence of a relay request from (H) eNB1 or 2 depending on whether or not the information element to which the X2AP Message ⁇ ⁇ ⁇ ⁇ ⁇ Transfer message is added is included.
  • the X2AP Message Transfer message may not include “Direct Path Unavailability” IE (or other explicit or implicit relay request).
  • a specific example of a procedure for notifying the target (H) eNB 2 of the X2-U TNL address (eg, IP address) of the X2 GW 3 will be described.
  • the X2-U TNL address of the X2 GW3 is set to the target (H) eNB2 by OAM, and the X2 GW3 X2 from the X2 GW3 to the target (H) eNB2 using the X2AP Message Transfer message.
  • OAM OAM
  • the X2 GW3 X2 from the X2 GW3 to the target (H) eNB2 using the X2AP Message Transfer message.
  • An example in which a TNL address is notified was shown.
  • an improved Enhanced TNL Address Discovery procedure may be used.
  • the (H) eNB includes the T2 address of the X2 GW connected to the (H) eNB in the S1AP: eNB CONFIGURATION TRANSFER message and the eNB CONFIGURATION TRANSFER message containing the TNL address of the X2 GW.
  • Send to MME The MME obtains the target eNB ID and the T2 address of the X2 GW included in the eNB CONFIGURATION TRANSFER message, and transfers the TNL address of the X2 GW to the target eNB ID using the S1AP: MME CONFIGURATION TRANSFER message.
  • two (H) eNB can recognize the TNL address of X2XGW, and can use indirect X2 via the X2 GW.
  • the X2 GW TNL address forwarded by the existing Enhanced TNL Address Discovery procedure is the TNL address (ie, X2-C TNL address) for forwarding X2AP signaling messages over SCTP connections.
  • the Enhanced TNL Address Discovery procedure is changed so as to transfer the TNL GW TNL address (that is, the X2-U TNL address) for transferring the TNL UDP / IP packet carrying the G-PDU.
  • FIG. 16 is a sequence diagram showing an example (processing 1600) of the Enhanced TNL Address Discovery procedure according to this embodiment.
  • the procedure of FIG. 16 is the same as the existing EnhancedEnhanceTNL Address Discovery procedure except that an X2 GW U-plane address (X2-U TNL address) is sent. That is, in block 1601, the source (H) eNB1 sends an S1AP: APeNB CONFIGURATION TRANSFER message to the MME5.
  • the eNB CONFIGURATION TRANSFER message includes the U-plane address (X2-U TNL address) of X2 GW3.
  • the MME 5 sends an S1AP: APMME CONFIGURATION TRANSFER message to the target (H) eNB2.
  • the MME CONFIGURATION TRANSFER message includes the U2-plane address (X2-U TNL address) of X2 GW3 received from the source (H) eNB1.
  • the target (H) eNB 2 adds the received U-plane address (X2-U TNL address) of X2 GW3 to the ACL.
  • the target (H) eNB2 sends an S1AP: eNB CONFIGURATION TRANSFER message to the MME5.
  • the eNB CONFIGURATION TRANSFER message is a response to the source (H) eNB1.
  • the MME 5 sends an S1AP: MME CONFIGURATION TRANSFER message to the source (H) eNB1.
  • the MME CONFIGURATION TRANSFER message includes the information element (e.g., the X2 GW3 U-plane address received by the target (H) eNB2 from the source (H) eNB1) from the target (H) eNB2 by the eNB CONFIGURATION TRANSFER message.
  • the information element e.g., the X2 GW3 U-plane address received by the target (H) eNB2 from the source (H) eNB1
  • FIG. 17A and 17B show a specific example of the change of “X2 TNL Configuration Info” IE defined in Section 9.3.2.29 of 3GPP TS 36.413 V12.4.0.
  • “X2 TNL Configuration Info” IE is included in the S1AP: eNB CONFIGURATION TRANSFER message and S1AP: MME CONFIGURATION TRANSFER message.
  • “X2 TNL Configuration Info” IE is “Transport Layer ⁇ Address” IE indicating a TNL address (that is, X2-U TNL address of X2 GW3) regarding the indirect X2 U-plane endpoint. May be expanded to include.
  • FIG. 18 is a block diagram illustrating a configuration example of (H) eNB1.
  • (H) eNB 2 may also have a configuration similar to the configuration of FIG.
  • (H) eNB1 includes an RF transceiver 1801, a network interface 1803, a processor 1804, and a memory 1805.
  • the RF transceiver 1801 performs analog RF signal processing to communicate with UEs.
  • the RF transceiver 1801 may include multiple transceivers.
  • RF transceiver 1801 is coupled to antenna 1802 and processor 1804.
  • the RF transceiver 1801 receives modulation symbol data (or OFDM symbol data) from the processor 1804, generates a transmission RF signal, and supplies the transmission RF signal to the antenna 1802. Further, the RF transceiver 1801 generates a baseband received signal based on the received RF signal received by the antenna 1802 and supplies this to the processor 1804.
  • the network interface 1803 is used to communicate with network nodes (e.g., MME and S / P-GW).
  • the network interface 1803 may include, for example, a network interface card (NIC) compliant with IEEE 802.3 series.
  • NIC network interface card
  • the processor 1804 may include a plurality of processors. For example, the processor 1804 performs signal processing of a GTP-U / UDP / IP layer in a modem processor (eg, DSP), an X2-U interface, and an S1-U interface that performs digital baseband signal processing.
  • a modem processor eg, DSP
  • X2-U interface e.g., X2-U
  • S1-U interface that performs digital baseband signal processing.
  • a processor eg, DSP
  • a protocol stack processor eg, CPU or MPU
  • the memory 1805 is constituted by a combination of a volatile memory and a nonvolatile memory.
  • the memory 1805 may include a plurality of physically independent memory devices.
  • the volatile memory is, for example, Static Random Access Memory (SRAM), Dynamic RAM (DRAM), or a combination thereof.
  • the non-volatile memory is a mask Read Only Memory (MROM), Electrically Erasable Programmable ROM (EEPROM), flash memory, hard disk drive, or any combination thereof.
  • Memory 1805 may include storage located remotely from processor 1804. In this case, the processor 1804 may access the memory 1805 via the network interface 1803 or an I / O interface not shown.
  • the memory 1805 may store a software module (computer program) including an instruction group and data for performing processing by (H) eNB1 described in the above-described embodiments.
  • the processor 1804 may be configured to perform the processing of (H) eNB1 described in the above-described embodiment by reading the software module from the memory 1805 and executing the software module.
  • FIG. 19 is a block diagram showing a configuration example of X2 GW3.
  • X2 GW3 includes a network interface 1901, a processor 1902, and a memory 1903.
  • the network interface 19601 is used to communicate with network nodes (e.g., (H) eNB1 and (H) eNB2).
  • the network interface 1901 may include, for example, a network interface card (NIC) that conforms to IEEE 802.3 series.
  • NIC network interface card
  • the processor 1902 reads the software (computer program) from the memory 1903 and executes it to perform the processing of X2 GW3 described in the above-described embodiment.
  • the processor 1902 may be, for example, a microprocessor, MPU, or CPU.
  • the processor 1902 may include a plurality of processors.
  • each of the processors included in (H) eNB1, (H) eNB2, and X2 GW3 uses the algorithm described with reference to the drawings.
  • One or more programs including a group of instructions to be executed are executed.
  • the program can be stored and supplied to a computer using various types of non-transitory computer readable media.
  • Non-transitory computer readable media include various types of tangible storage media (tangible storage medium).
  • non-transitory computer-readable media are magnetic recording media (eg flexible disks, magnetic tapes, hard disk drives), magneto-optical recording media (eg magneto-optical discs), Compact Disc Read Only Memory (CD-ROM), CD-ROM R, CD-R / W, semiconductor memory (for example, mask ROM, Programmable ROM (PROM), Erasable PROM (EPROM), flash ROM, Random Access Memory (RAM)).
  • the program may also be supplied to the computer by various types of temporary computer-readable media. Examples of transitory computer readable media include electrical signals, optical signals, and electromagnetic waves.
  • the temporary computer-readable medium can supply the program to the computer via a wired communication path such as an electric wire and an optical fiber, or a wireless communication path.
  • the above-described embodiment may be applied to other wireless communication systems such as UMTS and GSM systems.
  • the base station ((H) eNB) described in the above embodiment includes a control node (eg, Radio Network Controller (RNC) in UMTS, Base Station Controller (BSC) in the GSM system) having a radio resource management function, and A wireless transmission node (eg, NodeB in UMTS, or Base transceiver station (BTS) in a GSM system) may be included.
  • RNC Radio Network Controller
  • BSC Base Station Controller
  • a wireless transmission node eg, NodeB in UMTS, or Base transceiver station (BTS) in a GSM system
  • HNB Home NodeB
  • HNB-GW Home NodeB Gateway
  • the HNB sends an RNSAP: Enhanced Relocation Request message over the Iurh interface via the HNB-GW.
  • the HNB-GW transfers the RNSAP: “Enhanced” Relocation ”Request message on the Iur interface using the Signaling, Connection, Control, Part (SCCP).
  • SCCP Signaling, Connection, Control, Part
  • the HNB-GW may further perform U-Plane relay between the HNB and the RNC.
  • the above embodiment may be applied when a gateway is used between the UMTS system and the LTE / LTE-Advanced system.
  • the gateway may perform U-Plane relay between HeNB and RNC.
  • the above-described embodiment may be applied when a gateway is used between the CDMA2000 system and the LTE / LTE-Advanced system.
  • the gateway may perform U-Plane relay.
  • the above-described embodiment may be applied when a gateway is used between a Wireless Local Area Network (WLAN) system and an LTE / LTE-Advanced system.
  • WLAN Wireless Local Area Network
  • the gateway may perform U-Plane relay between the HeNB and the access point.
  • the above-described embodiment can be applied to the case where an inter-base station gateway is used for handover between base stations in an arbitrary Radio Access Technology (RAT). Further, the above-described embodiment can be applied when an inter-base station gateway is used for inter-base station handover between arbitrary RATs.
  • RAT Radio Access Technology
  • RN Relay node
  • DeNB Donor node
  • Appendix 2 A method performed by a base station device, When determining whether or not a relay process in which a gateway between base stations relays a data packet addressed to or from a wireless terminal between the base station apparatus and another base station is required, between the base stations Taking into account the relay processing capability of the gateway, Method.
  • the first information element explicitly indicates whether or not a direct path between the first base station and the second base station can be used,
  • the at least one processor is configured to receive the first information element upon handover of the wireless terminal from the first base station to the second base station;
  • the at least one processor is configured to transmit a second information element indicative of the relay processing capability to at least one of the first base station and the second base station;
  • the inter-base station gateway device according to any one of appendices 5 to 7.
  • the at least one processor is configured to transmit the second information element in a procedure of registering at least one of the first base station and the second base station with the gateway device between base stations. , The gateway device between base stations according to attachment 8.
  • the at least one processor is configured to determine whether to perform the relay processing based on the first information element; 10.
  • the inter-base station gateway device according to any one of appendices 5 to 9.
  • the at least one processor when the relay processing is performed by the inter-base station gateway device, in a first transfer message carrying a handover request message from the first base station to the second base station, Configured to include an endpoint setting of the inter-base-station gateway device for a first transport bearer for transferring the data packet between the inter-base-station gateway device and the second base station, 11.
  • the inter-base station gateway device according to any one of appendices 5 to 10.
  • the endpoint setting includes a transport layer address of the inter-base station gateway device, The gateway device between base stations according to appendix 11 or 12.
  • the endpoint configuration includes an endpoint configuration for Dunlink forwarding and an endpoint configuration for uplink forwarding.
  • the inter-base station gateway device according to any one of appendices 11 to 13.
  • the at least one processor transmits a handover request approval message from the second base station to the first base station in a second transfer message when the relay process is performed by the inter-base station gateway apparatus.
  • the inter-base station gateway device according to any one of appendices 5 to 14.
  • (Appendix 16) A method performed by a base station device, Transmitting the first information element to the inter-base station gateway;
  • the first information element indicates whether or not a relay process in which the inter-base station gateway relays a data packet addressed to or from the radio terminal between the base station apparatus and another base station is required.
  • the first information element explicitly indicates whether or not a direct path between the base station apparatus and the other base station can be used. The method according to appendix 16.
  • the transmitting includes including the first information element in a transfer message transmitted to the inter-base station gateway to carry a handover request message or a handover request acknowledge message to the other base station; The method according to appendix 18.
  • the first information element includes second information included in the handover request message or the handover request acknowledgment message carried by the transfer message to implicitly indicate that the relay processing is required.
  • the second information element includes an information element indicating necessity of forwarding of the data packet, an information element indicating an identifier of a bearer set for the wireless terminal, and a quality of service (QoS) parameter of the bearer. Including at least one of the indicated information elements, The method according to appendix 20 or 21.
  • Appendix 23 Further comprising including in the transfer message an information element indicating a type of inter-base station signaling message carried by the transfer message; The method according to any one of appendices 19 to 22.
  • Appendix 24 Determining whether to use the relay processing by the inter-base station gateway for transmission or reception of the data packet; and, when the relay processing is not used, the base station apparatus and the other base Forwarding the data packet using a direct path between stations, Further comprising The method according to any one of appendices 16 to 23.
  • (Appendix 25) A method performed by a gateway device between base stations, Receiving a first information element from at least one of a first base station and a second base station; The first information element needs a relay process for relaying a data packet addressed to or from the wireless terminal between the first base station and the second base station by the inter-base station gateway device. Explicitly or implicitly indicating whether or not Method.
  • the first information element explicitly indicates whether or not a direct path between the first base station and the second base station can be used, The method according to appendix 25.
  • the receiving includes receiving the first information element upon handover of the wireless terminal from the first base station to the second base station; The method according to appendix 25 or 26.
  • Appendix 28 Further comprising transmitting a second information element indicating the capability of the relay processing to at least one of the first base station and the second base station, The method according to any one of appendices 25 to 27.
  • the transmitting includes transmitting the second information element in a procedure of registering at least one of the first base station and the second base station in the inter-base station gateway device, The method according to appendix 28.
  • Appendix 30 Further comprising determining whether to perform the relay processing based on the first information element; The method according to any one of appendices 25 to 29.
  • Appendix 32 The endpoint configuration is used to update a packet filter at the second base station; The method according to appendix 31.
  • the endpoint setting includes a transport layer address of the inter-base station gateway device, The method according to appendix 31 or 32.
  • the endpoint configuration includes an endpoint configuration for Dunlink forwarding and an endpoint configuration for uplink forwarding.
  • the method according to any one of appendices 31 to 33.
  • the at least one processor transmits a handover request approval message from the second base station to the first base station in a second transfer message when the relay process is performed by the inter-base station gateway apparatus. Further comprising an endpoint configuration of the inter-base station gateway device for a second transport bearer for transferring the data packet between the inter-base station gateway device and the first base station, The method according to any one of appendices 25 to 34.

Landscapes

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

Abstract

　基地局装置（１）は、第１の情報要素を基地局間ゲートウェイ（３）に送信するよう構成されている。当該第１の情報要素は、無線端末宛て又は無線端末からのデータパケットを基地局間ゲートウェイ（３）が基地局装置（１）と他の基地局（２）の間で中継するリレー処理が必要とされる否かを明示的または暗示的に示す。これにより、例えば、基地局又は基地局間ゲートウェイが基地局間ハンドオーバの際に基地局間ゲートウェイによるリレー処理を行うか否かを選択できるようにすることに寄与できる。

Description

基地局装置および基地局間ゲートウェイ装置
　本開示は、無線通信に関し、特に、基地局間でのユーザデータパケットのフォワーディングに関する。
　3rd Generation Partnership Project（3GPP）Release 12は、X2 Gateway（X2 GW）について規定している（例えば、非特許文献１を参照）。非特許文献１に記載されているように、X2 GWは複数の(H)eNBの各々とシグナリング（i.e., Stream Control Transmission Protocol（SCTP））コネクションを確立し、これら複数の(H)eNBは当該X2 GWを介してシグナリングメッセージ（i.e., X2APメッセージ）を交換する。(H)eNB は、eNodeB又はHome eNodeBを意味する。X2 GWは、X2AP Message Transfer procedureを除いて、X2AP proceduresを終端しない。つまり、X2APコンテキスト（X2AP contexts）は、２つのピア(H)eNB内にのみ存在する（X2 GWが無い場合と同様）。X2APコンテキストは、２つのSCTPコネクションにまたがる（spans over）２つのピア(H)eNBの間の“X2APアソシエーション”を定義する。
　X2GWによるX2APメッセージの転送手順（X2AP Message Transfer procedure）は以下のように行われる。すなわち、ソース(H)eNBがX2APメッセージ（X2AP MESSAGE TRANSFERメッセージを除く）をX2 GWを介してターゲット(H)eNBに送信する場合、当該ソース(H)eNBは、当該X2APメッセージをX2AP MESSAGE TRANSFERメッセージ内にカプセル化（encapsulate）し、ルーティング情報（i.e., RNL Header）を追加し、そして当該X2AP MESSAGE TRANSFERメッセージを当該X2 GWに送信する。ルーティング情報（i.e., RNL Header）は、ターゲット(H)eNB ID及びソース(H)eNB IDの両方を含む。X2 GWは、ターゲット(H)eNB IDに基づいて当該X2AP MESSAGE TRANSFERメッセージをルーティングする。
　なお、X2インタフェースは、3GPP Release 8以降の基地局間インタフェースである。X2インタフェースは、コントロールプレーン（シグナリング）インタフェース（i.e., X2-Cインタフェース）及びユーザプレーン（データプレーン）インタフェース（i.e., X2-Uインタフェース）を含む。X2-Cインタフェースは、例えば、基地局間ハンドオーバ（i.e., X2ハンドオーバ）の準備、Dual connectivityの制御（e.g., UEコンテキストの確立、修正及び開放、並びにX2ユーザプレーントンネルの管理）、及び隣接するeNBに関する様々な設定及びメンテナンスのために使用される。X2-Cインタフェースは、X2APプロトコルを使用するとともに、X2APシグナリングメッセージを転送するためにSCTP及びInternet Protocol（IP）を使用する。X2APプロトコルは、Radio Network Layer（RNL）プロトコルと呼ばれ、X2APプロトコルを転送するためのSCTP/IPは、Transport Network Layer（TNL）プロトコルと呼ばれる。
　一方、X2-Uインタフェースは、例えば、ハンドオーバ中にソース(H)eNBからターゲット(H)eNBにユーザデータパケットをフォワーディングするため、及びDual connectivityでのMaster eNB（MeNB）とSecondary eNB（SeNB）の間でユーザデータパケット（i.e., Packet Data Convergence Protocol（PDCP） PDUs）を転送するため、に使用される。X2-Uインタフェースは、GPRS Tunnelling Protocol User Plane（GTP-U）プロトコルを使用し、GTP Protocol Data Unit（GTP-PDU）を転送するためにUser Datagram Protocol（UDP）及びIPを使用する。GTP-Uプロトコルは、ユーザプレーン（U-plane）のRNLプロトコルであり、GTP-U PDUを転送するためのUDP/IPは、U-planeのためのTNLプロトコルである。GTP-UおよびTNL UDP/IPは、トンネルメカニズムを提供する。すなわち、GTP-Uは、ユーザデータパケット（e.g., IPパケット）をGTP-Uヘッダによってカプセル化し、カプセル化されたユーザデータパケット（i.e., GTP-PDU）は、TNL UDP/IPレイヤにおいて転送される。なお、ユーザデータパケットは、T-PDUと呼ばれることもある。また、GTP-Uヘッダによりカプセル化されたユーザデータパケット（T-PDU）は、GTP-PDUの１つであるが、GTPノード間のシグナリングメッセージを包含するGTP-PDUと区別するためにG-PDUと呼ばれることもある。また、G-PDU又はシグナリングメッセージとしてのGTP-U PDUは、GTP-Uメッセージと呼ばれることもある。
　非特許文献１に記載されているように、3GPP Release 12は、２つのピア(H)eNB 間でのX2 GWを介したX2APシグナリングメッセージ（X2-C）の転送を規定しているが、ユーザデータパケット（X2-U）の転送を規定していない。これに対して、特許文献１及び２は、２つのピア(H)eNB 間でのX2 GWを介したユーザデータパケットの転送を開示している。
　特許文献１は、コアネットワーク（i.e., Evolved Packet Core（EPC））と(H)eNBの間でS1-MMEシグナリングメッセージ及びユーザデータパケットを中継するHeNB-GWが、X2-Cインタフェース及びX2-Uインタフェースもサポートすることを記載している。特許文献１に記載されたHeNB-GWは、ユーザデータパケットをカプセル化しているGTP-PDU（i.e., G-PDU）を２つのピア(H)eNBの間で中継するよう動作する。しかしながら、特許文献１は、HeNB-GWによるG-PDUの中継動作の詳細について記載していない。
　特許文献２は、G-PDUが２つの(H)eNB間でX2-GWを介して転送されることを記載している。特許文献２のX2-GWは、ハンドオーバ準備時に２つの(H)eNBにTunnel Endpoint Identifier（TEID）を割り当てるとともに、一方の(H)eNBから受信したGTP-U PDUのGTP-Uヘッダ内のTEIDを変更し、TEIDを変更されたGTP-U PDUを他方の(H)eNBに送信するよう動作する。
　基地局間ゲートウェイ（e.g., X2-GW）が利用される場合に、基地局間でのユーザデータパケット（e.g., PDCP PDUs）の転送（e.g., 基地局間ハンドオーバ（e.g., X2ハンドオーバ）時のDLデータフォワーディング、及びDual connectivityでのMeNBとSeNB間での転送）が常にX2-GWを介して行われることは適切ではないかもしれない。例えば、基地局間ダイレクトパス（e.g., X2インタフェース）の最大または実効的なスループット（伝送速度）が十分に大きければ、常に基地局間ゲートウェイによるリレーを利用することは遅延の増大の観点から適切ではないかもしれない。一方で、基地局間ダイレクトパスの負荷が高い場合、又は基地局間ダイレクトパスが何らかの事情で利用不能である場合には、基地局間ゲートウェイによるリレーを選択できることが好ましいかもしれない。また、２つの基地局（e.g., (H)eNBs）間のハンドオーバの際に、一方の基地局のTNLアドレス（e.g., IPアドレス）を他方の基地局から隠蔽できることが好ましいかもしれない。このTNLアドレスの隠蔽は、特定の基地局または特定の種別の基地局に対してのみ要求されるかもしれない。
　したがって、基地局（e.g., (H)eNB）又は基地局間ゲートウェイ（e.g., X2-GW）は、基地局間でのユーザデータパケットの転送の際に基地局間ゲートウェイ（e.g., X2-GW）によるリレー処理を行うか否かを選択できることが好ましいかもしれない。しかしながら、特許文献１及び２は、X2 GWによるリレー処理を行うか否かを制御することについて記載していない。ここで、基地局間ゲートウェイ（e.g., X2-GW）によるユーザデータパケットのリレー処理は、X2 GWを介した基地局（e.g., (H)eNBs）間でのユーザデータパケットの転送を意味する。
　本明細書に開示される実施形態が達成しようとする目的の１つは、基地局（e.g., (H)eNB）又は基地局間ゲートウェイ（e.g., X2-GW）が基地局間ゲートウェイ（e.g., X2-GW）によるリレー処理を行うか否かを選択できるようにすることに寄与する装置、方法、及びプログラムを提供することである。この目的は、本明細書に開示される実施形態が達成しようとする複数の目的の１つに過ぎないことに留意されるべきである。その他の目的又は課題と新規な特徴は、本明細書の記述又は添付図面から明らかにされる。
　第１の態様では、基地局装置は、メモリ、及び前記メモリに結合された少なくとも１つのプロセッサを含む。前記少なくとも１つのプロセッサは、第１の情報要素を基地局間ゲートウェイに送信するよう構成されている。前記第１の情報要素は、無線端末宛て又は前記無線端末からのデータパケットを前記基地局間ゲートウェイが前記基地局装置と他の基地局の間で中継するリレー処理が必要とされる否かを明示的または暗示的に示す。
　第２の態様では、基地局間ゲートウェイ装置は、メモリ、及び前記メモリに結合された少なくとも１つのプロセッサを含む。前記少なくとも１つのプロセッサは、第１の情報要素を第１の基地局及び第２の基地局の少なくとも一方から受信するよう構成されている。前記第１の情報要素は、無線端末宛て又は前記無線端末からのデータパケットを前記基地局間ゲートウェイ装置によって前記第１の基地局と前記第２の基地局の間で中継するリレー処理が必要とされる否かを明示的または暗示的に示す。
　第３の態様では、基地局装置により行われる方法は、第１の情報要素を基地局間ゲートウェイに送信することを含む。前記第１の情報要素は、無線端末宛て又は前記無線端末からのデータパケットを前記基地局間ゲートウェイが前記基地局装置と他の基地局の間で中継するリレー処理が必要とされる否かを明示的または暗示的に示す。
　第４の態様では、基地局間ゲートウェイ装置により行われる方法は、第１の情報要素を第１の基地局及び第２の基地局の少なくとも一方から受信することを含む。前記第１の情報要素は、無線端末宛て又は前記無線端末からのデータパケットを前記基地局間ゲートウェイ装置によって前記第１の基地局と前記第２の基地局の間で中継するリレー処理が必要とされる否かを明示的または暗示的に示す。
　第５の態様では、プログラムは、コンピュータに読み込まれた場合に、上述の第３又は第４の態様に係る方法をコンピュータに行わせるための命令群（ソフトウェアコード）を含む。
　上述の態様によれば、基地局又は基地局間ゲートウェイが基地局間ゲートウェイによるリレー処理を行うか否かを選択できるようにすることに寄与する装置、方法、及びプログラムを提供できる。
いくつかの実施形態に係る無線通信システムの構成例を示す図である。 第１の実施形態に係るリレー処理の必要性を通知する手順の一例を示すシーケンス図である。 第１の実施形態に係るソース基地局の動作の一例を示すフローチャートである。 第１の実施形態に係る基地局間ゲートウェイの動作の一例を示すフローチャートである。 第１の実施形態に係るターゲット基地局の動作の一例を示すフローチャートである。 第１の実施形態に係るターゲット基地局の動作の一例を示すフローチャートである。 第１の実施形態に係るソース基地局および基地局間ゲートウェイの動作とその起動条件の組み合せの一例を示すテーブルである。 第１の実施形態に係るソース基地局および基地局間ゲートウェイの動作とその起動条件の組み合せの一例を示すテーブルである。 第１の実施形態に係るターゲット基地局および基地局間ゲートウェイの動作とその起動条件の組み合せの一例を示すテーブルである。 第１の実施形態に係るターゲット基地局および基地局間ゲートウェイの動作とその起動条件の組み合せの一例を示すテーブルである。 第１の実施形態に係るリレー能力の通知手順の一例を示すシーケンス図である。 第１の実施形態に係るリレー能力の通知手順の一例を示すシーケンス図である。 第１の実施形態に係る基地局間ハンドオーバ手順の一例を示すシーケンス図である。 第１の実施形態に係る基地局間ハンドオーバ手順の一例を示すシーケンス図である。 X2AP Message Transferメッセージの変更（modification）の一例を示す図である。 X2AP Message Transferメッセージの変更の他の例を示す図である。 X2AP Message Transferメッセージの変更の他の例を示す図である。 第３の実施形態に係る基地局間ゲートウェイのアドレスをターゲット基地局に通知する手順の一例を示すシーケンス図である。 X2 TNL Configuration Infoメッセージの変更の一例を示す図である。 X2 TNL Configuration Infoメッセージの変更の一例を示す図である。 いくつかの実施形態に係る基地局の構成例を示すブロック図である。 いくつかの実施形態に係る基地局間ゲートウェイの構成例を示すブロック図である。
　以下では、具体的な実施形態について、図面を参照しながら詳細に説明する。各図面において、同一又は対応する要素には同一の符号が付されており、説明の明確化のため、必要に応じて重複説明は省略される。
　以下に示される複数の実施形態は、Long Term Evolution (LTE)/LTE-Advancedシステムを主な対象として説明される。しかしながら、これらの実施形態は、LTE/ LTE-Advancedシステムに限定されるものではなく、他の無線通信ネットワーク又はシステム、例えば3GPP Universal Mobile Telecommunications System（UMTS）、3GPP2 CDMA2000システム、Global System for Mobile communications（GSM（登録商標））/ General packet radio service（GPRS）システム、及びWiMAXシステム等に適用されてもよい。
＜第１の実施形態＞
　図１は、本実施形態を含むいくつかの実施形態に係る無線通信システムの構成例を示している。図１の例では、無線通信システムは、(H)eNB１、(H)eNB２、X2 GW３、及びEPC４を含む。X2 GW３は、(H)eNBs１及び２の間でシグナリングメッセージ（X2APメッセージ）を中継するために、(H)eNBs１及び２の各々とSCTPコネクションを確立するよう構成されている。X2 GW３は、さらに、(H)eNBs１及び２の間でユーザデータパケットを中継するために、(H)eNBs１及び２の各々とGTP-Uトンネルを確立できるよう構成されている。(H)eNBs１及び２の各々は、X2 GW３との間にX2-Cインタフェースを有し、EPC４との間にS1インタフェースを有する。なお、 (H)eNB１及び２の少なくとも一方とEPC４の間にHeNB-GWが使用されてもよい。当該HeNB-GWは、(H)eNB１及び２の少なくとも一方とEPC４の間でS1-MMEシグナリング及びユーザデータパケット（S1-U）を中継する。本実施形態では、主に、(H)eNB１から(H)eNB２へのUEのハンドオーバについて説明する。したがって、 (H)eNB１をソース(H)eNBと呼び、(H)eNB２をターゲット(H)eNBと呼ぶこともある。
　本実施形態では、(H)eNBs１及び２の少なくとも一方は、第１の情報要素（Information Element（IE））をX2 GW３に送信するよう構成されている。当該第１の情報要素は、無線端末（User Equipment（UE））のユーザデータパケットのフォワーディングのためにX2 GW３によるリレー処理が必要とされるか否かを明示的又は暗示的に示す。いくつかの実装において、(H)eNB１から(H)eNB２への当該UEのハンドオーバの際に、ソース(H)eNBs１及びターゲット(H)eNB２の少なくとも一方が当該第１の情報要素を送信してもよい。いくつかの実装において、(H)eNB１、(H)eNB２、及びUEがDual Connectivityをサポートする場合に、当該UEのベアラ確立の際に、(H)eNBs１及び (H)eNB２の少なくとも一方が当該第１の情報要素を送信してもよい。
　X2 GW３によるリレー処理は、(H)eNB１とX2 GW３の間のX2-Uインタフェース（GTP-Uトンネル）１０１、及び(H)eNB２とX2 GW３の間のX2-Uインタフェース（GTP-Uトンネル）１０２を介してユーザデータパケット（T-PDU）を転送することを含む。X2 GW３によるユーザデータパケットのリレーは、当該リレー処理は、GTP-Uヘッダによりカプセル化されたユーザデータパケット、つまりG-PDUを転送することにより行われてもよい。X2 GW３によるリレー処理は、X2-Uリレー、U-planeリレー、GTP-Uリレー、又はユーザプレーン集約（user plane concentration）と呼ぶこともできる。
　すなわち、当該第１の情報要素は、X2 GW３によるU-planeリレーの必要性を示す明示的（explicit）又は暗示的（implicit）な表示（indication）である。いくつかの実装において、当該表示は、X2 GW３によるリレー処理が必要とされるか否かに応じて異なる値がセットされるフラグ情報であってもよい。これに代えて、いくつかの実装において、当該表示は、X2 GW３によるリレー処理が必要とされる場合に送信され且つリレー処理が不要な場合に送信されない明示的又は暗示的なリレー要求であってもよい。これに代えて、いくつかの実装において、当該表示は、複数の情報要素の組み合せであってもよい。
　例えば、以下に示される具体例のように、当該表示は、(H)eNBs１及び２の間のダイレクトパス１００の利用可否を示す情報要素（e.g., Direct Path Availability IE又は Direct Path Unavailability IE）を含んでもよい。ダイレクトパス１００の利用可否は、例えば、オペレータによって、つまりoperations, administration and maintenance（OAM）によって、(H)eNBs１及び２に予め設定されてもよい。これに代えて、ダイレクトパス１００の利用可否は、(H)eNBs１及び２によって動的に判定されてもよい。例えば、(H)eNBs１及び２は、ダイレクトパス１００を利用できるがそのスループットが低い場合、又はダイレクトパス１００の負荷が高い場合に、ダイレクトパス１００を利用できないと判定してもよい。当該表示は、例えば、ダイレクトパス１００の利用可否を示す情報要素とデータフォワーディングの要否を示す情報要素（e.g., DL Forwarding IE又はUplink (UL) GTP Tunnel Endpoint IE）の組合せであってもよい。
　図２は、リレー処理の必要性をX2 GW３に通知する手順の一例（処理２００）を示すシーケンス図である。ブロック２０１では、(H)eNB１又は２は、X2AP Message TransferメッセージをX2 GW３に送信する。当該X2AP Message Transferメッセージは、ソース(H)eNB１からターゲット(H)eNB２へのX2AP Handover Requestメッセージ又はターゲット(H)eNB２からソース(H)eNB１へのX2AP Handover Request Acknowledgeメッセージを運ぶ。当該X2AP Message Transferメッセージは、さらに、X2 GW３によるX2-Uリレー処理の必要性を明示的又は暗示的に示す表示を含む。X2 GW３は、当該表示に基づいて、X2-Uリレーの準備を行うべきか否かを認識することができる。
　また、図２の例では、X2 GW３は、Handover Requestメッセージ又はHandover Request Acknowledgeメッセージを運ぶX2AP Message Transferメッセージと共に、X2-Uリレー処理の必要性を示す表示を受信する。したがって、X2 GW３は、当該X2AP Message Transferメッセージを参照することによって、X2-Uリレーに必要なGTP-Uトンネルの準備を容易に行うことができる。
　以上の説明から理解されるように、本実施形態では、(H)eNBs１及び２の少なくとも一方は、X2 GW３によるU-plane（X2-U）リレーが必要とされるか否かを明示的又は暗示的に示す表示をX2 GW３に送信するよう構成されている。したがって、X2 GW３は、当該表示に基づいて、U-plane（X2-U）リレーを行うべきか否かを認識することができる。
　さらに、本実施形態では、(H)eNBs１及び２の少なくとも一方は、(H)eNB１から(H)eNB２への無線端末（UE）のユーザデータパケットの転送が必要とされる場合に、当該UEのユーザデータパケットのフォワーディングのためにX2 GW３によるリレー処理を利用するか否かを決定するよう構成されてもよい。言い換えると、(H)eNBs１及び２は、(H)eNB１から(H)eNB２へのユーザデータパケットのフォワーディングのためにX2 GW３を介したリレーパス（１０１及び１０２）とダイレクトパス（１００）のどちらを利用するかを選択するよう構成されてもよい。X2 GW３によるリレー処理を利用しない場合、ソース(H)eNB１は、(H)eNBs１及び２の間のダイレクトパス、つまりX2-Uインタフェース（GTP-Uトンネル）１００を用いてユーザデータパケットをターゲット(H)eNB２にフォワーディングしてもよい。
　いくつかの実装において、ソース(H)eNB１は、(H)eNB２へのUEのハンドオーバの開始を決定した場合に、X2 GW３によるU-plane（X2-U）リレー処理を利用するか否かを判定してもよい。いくつかの実装において、ターゲット(H)eNB２は、ソース(H)eNB１からのハンドオーバ要求を受信した場合に、X2 GW３によるU-plane（X2-U）リレー処理を利用するか否かを判定してもよい。いくつかの実装において、(H)eNB１は、Dual connectivityをサポートするUEに関するベアラ確立の要求（e.g., S1AP: Initial Context Setup Request）をEPC４から受信した場合に、X2 GW３によるU-plane（X2-U）リレー処理を利用するか否かを判定してもよい。これらに代えて、X2 GW３によるU-plane（X2-U）リレー処理を利用するか否かは、(H)eNBのペア毎に予め決定されてもよい。
　いくつかの実装において、(H)eNB１若しくは２又はこれら両方は、ダイレクトパス１００の状態（e.g., ダイレクトパス１００の利用可否、ダイレクトパス１００のスループット、又はダイレクトパス１００の負荷）に応じて、X2 GW３によるU-plane（X2-U）リレー処理を利用するか否かを選択してもよい。言い換えると、(H)eNB１若しくは２又はこれら両方は、X2 GW３によるU-plane（X2-U）リレー処理を利用するか否か（又は要求するか否か）を決定する際に、ダイレクトパス１００の状態を考慮してもよい。
　例えば、基地局間ダイレクトパス１００の最大または実効的なスループット（伝送速度）が (H)eNB１（又は２）とX2 GW３の間のパス１０１（又は１０２）のスループットよりも大きければ、基地局間ゲートウェイによるリレーを利用することは遅延の増大の観点から適切ではないかもしれない。したがって、(H)eNB１又は２は、基地局間ダイレクトパス１００のスループットが(H)eNB１とX2 GW３の間のパス１０１又は１０２のスループットよりも十分に大きい場合に、X2 GW３によるU-plane（X2-U）リレー処理を利用しないことを決定してもよい。これにより、不必要なU-planeリレーに起因する遅延の増大を抑制できる。
　いくつかの実装において、(H)eNB１は、(H)eNB１のTNLアドレス（e.g., IPアドレス）を(H)eNB２から隠蔽する必要がある場合にX2 GW３によるU-plane（X2-U）リレー処理を利用し、TNLアドレスの隠蔽が必要でない場合にダイレクトパス１００を介したフォワーディングを実施してもよい。同様に、(H)eNB２は、(H)eNB２のTNLアドレス（e.g., IPアドレス）を(H)eNB１からの隠蔽の必要性に基づいて、X2 GW３によるU-plane（X2-U）リレー処理を利用するか否かを選択してもよい。言い換えると、(H)eNB１若しくは２又はこれら両方は、X2 GW３によるU-plane（X2-U）リレー処理を利用するか否か（又は要求するか否か）を決定する際に、TNLアドレスの隠蔽の必要性を考慮してもよい。
　例えば、ソース(H)eNB１は、ハンドオーバの際に、自身のTNLアドレス（e.g., IPアドレス）をターゲット(H)eNB２から隠蔽することを必要とするかもしれない。これとは反対に、ターゲット(H)eNB２がそのTNLアドレス（e.g., IPアドレス）をソース(H)eNB１から隠蔽することを必要とするかもしれない。このTNLアドレスの隠蔽は、特定の基地局または特定の種別の基地局に対してのみ要求されるかもしれない。
　HeNBは通信事業者によって管理される局舎（サイト）内ではなく、エンドユーザの家やビル内に設置されうる。そのため、HeNBは悪意のユーザによって改造されるおそれがあり、必ずしもセキュリティが十分に保証された装置とはいえない。したがって、ハンドオーバの際に、このようなHeNBに対してマクロeNBのX2-U TNLアドレスを知らせることは、マクロeNBがDenial of Service（DoS）攻撃を受ける等のセキュリティリスクを招くおそれがある。例えば、ソース(H)eNB１がマクロeNBであってターゲット(H)eNB２がHeNBである場合、ソース(H)eNB１は、X2 GW３によるU-plane（X2-U）リレー処理を利用することを決定してもよい。一方、ソース(H)eNB１がマクロeNBであってターゲット(H)eNB２もマクロeNBである場合、ソース(H)eNB１は、X2 GW３によるU-plane（X2-U）リレー処理を利用しないことを決定してもよい。これにより、マクロeNBのX2-U TNLアドレスをHeNBに知らせることに起因するセキュリティリスクを抑制できる。
　いくつかの実装において、(H)eNB１若しくは２又はこれら両方は、X2 GW３のU-planeリレー能力（U-plane Relay Capability）に基づいて、X2 GW３によるU-plane（X2-U）リレー処理を利用するか否かを選択してもよい。言い換えると、(H)eNB１若しくは２又はこれら両方は、X2 GW３によるU-plane（X2-U）リレー処理を利用するか否か（又は要求するか否か）を決定する際に、X2 GW３のU-planeリレー能力の有無を考慮してもよい。
　以上の説明から理解されるように、本実施形態では、(H)eNBs１及び２の少なくとも一方は、(H)eNB１から(H)eNB２へのUEのハンドオーバの際に、X2 GW３によるU-plane（X2-U）リレー処理を利用するか否かを決定するよう構成されてもよい。これにより、(H)eNBs１及び２の少なくとも一方は、X2 GW３によるU-plane（X2-U）リレー処理を利用するか否かを選択できる。
　続いて以下では、ソース(H)eNB１、X2 GW３、及びターゲット(H)eNB２の動作の具体例について説明する。図３は、ソース(H)eNB１の動作の一例（処理３００）を示すフローチャートである。ブロック３０１では、(H)eNB１は、ターゲット(H)eNB２へのUEのハンドオーバの開始を判定する。ブロック３０２では、当該ハンドオーバの際に、X2 GW３によるU-plane（X2-U）リレー処理が必要とされるか否かを判定する。U-plane（X2-U）リレー処理が必要とされる場合（ブロック３０２でYES）、ソース(H)eNB１は、ハンドオーバ要求（i.e., Handover Requestメッセージ）を運ぶ転送メッセージ（i.e., X2AP Message Transferメッセージ）に明示的又は暗示的なリレー要求を含める（ブロック３０３）。ブロック３０４では、ソース(H)eNB１は、ハンドオーバ要求を運ぶ転送メッセージ（リレー要求を含む）をX2 GW３に送信する。これに対して、U-plane（X2-U）リレー処理が必要とされない場合、（ブロック３０２でNO）、ソース(H)eNB１は、ハンドオーバ要求を運ぶ転送メッセージ（リレー要求を含まない）をX2 GW３に送信する（ブロック３０５）。
　図４は、X2 GW３の動作の一例（処理４００）を示すフローチャートである。ブロック４０１では、X2 GW３は、ハンドオーバ要求（i.e., Handover Requestメッセージ）を運ぶ転送メッセージ（i.e., X2AP Message Transferメッセージ）をソース(H)eNB１から受信する。ブロック４０２では、X2 GW３は、受信した転送メッセージ内にリレー要求が含まれているか否かを確認する。転送メッセージがリレー要求を含む場合（ブロック４０２でYES）、X2 GW３は、X2 GW３によるU-plane（X2-U）リレーが行われることを示す表示を転送メッセージ（ハンドオーバ要求を運ぶ）に追加し、これをターゲット(H)eNB２に送信する。
　いくつかの実装において、X2 GW３によるU-plane（X2-U）リレーが行われることを示す当該表示は、U-plane（X2-U）リレーが行われるか否かを示す単純なフラグ情報であってもよい。さらに又はこれに代えて、図４のブロック４０３に示されているように、X2 GW３によるU-plane（X2-U）リレーが行われることを示す当該表示は、X2トランスポートベアラ（i.e., GTP-Uベアラ）に関するX2 GW３側のエンドポイント設定を含んでもよい。エンドポイント設定は、TNLアドレス（e.g., IPアドレス）及びTEIDを含む。当該エンドポイント設定は、ダウンリンク（DL）ユーザデータパケットのフォワーディングに使用されるX2トランスポートベアラに関するDL GTPトンネル・エンドポイント設定のみでもよいし、アップリンク（UL）ユーザデータパケットのフォワーディングに使用されるX2トランスポートベアラに関するUL GTPトンネル・エンドポイント設定をさらに含んでもよい。
　X2 GW３が、ハンドオーバ要求を運ぶ転送メッセージと共に、X2トランスポートベアラ（i.e., GTP-Uベアラ）に関するX2 GW３側のエンドポイント設定をターゲット(H)eNB２に送信することによって、例えば以下に述べる効果が得られる。いくつかの実装において、ターゲット(H)eNB２は、Access Control List （ACL）機能（functionality）を有するかもしれない。ACL機能がターゲット(H)eNB２に適用された場合、ターゲット(H)eNB２は、送信ノードのソースアドレスをターゲット(H)eNB２において既に知っている場合に限り、送信ノードからのコネクションを受け入れる。このため、仮にターゲット(H)eNB２がX2 GW３のX2-U TNLアドレスを知らなければ、ターゲット(H)eNB２は、X2 GW３から送信されるG-PDUを運ぶTNL UDP/IPパケットをACL機能により破棄するおそれがある。これを回避するために、X2 GW３は、データフォワーディングの上流側であるが、X2トランスポートベアラ（i.e., GTP-Uベアラ）に関するX2 GW３側のエンドポイント設定をターゲット(H)eNB２に先に通知するとよい。これにより、ターゲット(H)eNB２は、X2 GW３のX2-U TNLアドレスからのコネクションを受け入れるようにACLを更新することができる。ACLは、パケットフィルタ又はファイヤウォール設定と言うこともできる。
　図４に戻り説明を続ける。転送メッセージがリレー要求を含まない場合（ブロック４０２でNO）、X2 GW３は、ソース(H)eNB１から受信した転送メッセージをそのままターゲット(H)eNB２に送信する（ブロック４０４）。つまり、ブロック４０４で送信される転送メッセージは、X2 GW３によるU-plane（X2-U）リレーが行われることを示す表示を含まない。
　図５は、ターゲット(H)eNB２の動作の一例（処理５００）を示すフローチャートである。ブロック５０１では、ターゲット(H)eNB２は、ハンドオーバ要求（i.e., Handover Requestメッセージ）を運ぶ転送メッセージ（i.e., X2AP Message Transferメッセージ）をX2 GW３から受信する。ブロック５０２では、受信した転送メッセージが、X2トランスポートベアラ（i.e., GTP-Uベアラ）に関するX2 GW３側のエンドポイント設定を含むか否かを判定する。X2 GW３側のエンドポイント設定が含まれている場合（ブロック５０３でYES）、ターゲット(H)eNB２は、X2 GW３のX2-U TNLアドレスからのコネクションを受け入れるように自身のACLを更新する。
　ブロック５０４では、ターゲット(H)eNB２は、ハンドオーバ要求承認（i.e., Handover Request Acknowledgeメッセージ）を運ぶ転送メッセージ（i.e., X2AP Message Transferメッセージ）を X2 GW ３に送信する。ハンドオーバ要求承認（i.e., Handover Request Acknowledgeメッセージ）は、ターゲット(H)eNB２のDL GTPトンネル・エンドポイント設定を含む。さらに、DLデータフォワーディングに加えてULデータフォワーディングが行われる場合、ハンドオーバ要求承認（i.e., Handover Request Acknowledgeメッセージ）は、ターゲット(H)eNB２のUL GTPトンネル・エンドポイント設定を含む。ターゲット(H)eNB２のDL GTPトンネル・エンドポイント設定は、ソース(H)eNB１からフォワーディングされるDLユーザデータパケットを受信するためのGTP-Uトンネルに関するTNLアドレス及びTEIDを含む。ターゲット(H)eNB２のUL GTPトンネル・エンドポイント設定は、ソース(H)eNB１からフォワーディングされるULユーザデータパケットを受信するためのGTP-Uトンネルに関するTNLアドレス及びTEIDを含む。
　なお、ブロック５０４において送信されるハンドオーバ要求承認メッセージを運ぶ転送メッセージは、ハンドオーバ要求承認メッセージ内に記述されているのと同じターゲット(H)eNB２のGTPトンネル・エンドポイント設定を示す追加の情報要素を含んでもよい。このようなメッセージ構成は冗長であるものの、X2 GW３がハンドオーバ要求承認メッセージをデコード又は参照しなくてもよいという利点がある。
　図３～図５に示されたソース(H)eNB１、X2 GW３、及びターゲット(H)eNB２の動作は一例であって適宜変更されてもよい。例えば、図３においてリレー要求の送信に使用されるメッセージは、X2AP Message Transferメッセージとは異なるX2APメッセージであってもよい。例えば、リレー要求は、X2AP Message Transferメッセージによって運ばれるHandover Requestメッセージ内にセットされてもよい。図４において、X2 GW３のエンドポイント設定の送信に使用されるメッセージは、X2AP Message Transferメッセージとは異なるX2APメッセージであってもよい。例えば、X2 GW３のエンドポイント設定は、X2AP Message Transferメッセージによって運ばれるHandover Requestメッセージ内にセットされてもよい。
　図３～図５は、ハンドオーバ要求の際に、ソース(H)eNB１がX2 GW３によるU-plane（X2-U）リレーを利用するか否か（又は要求するか否か）を判定する例について示した。これと同様に、ハンドオーバ要求をソース(H)eNB１からX2 GW３を介して受信した場合に、ターゲット(H)eNB２は、ソース(H)eNB１がX2 GW３によるU-plane（X2-U）リレーを利用するか否か（又は要求するか否か）を判定してもよい。すなわち、ソース(H)eNB１によるX2 GW３によるU-plane（X2-U）リレーの要否判定とは独立に、ターゲット(H)eNB２は、X2 GW３によるU-plane（X2-U）リレーの要否を判定してもよい。
　図６は、ターゲット(H)eNB２によって行われるU-plane（X2-U）リレーの要否判定を含む動作の一例（処理６００）を示すフローチャートである。ブロック６０１では、ターゲット(H)eNB２は、ハンドオーバ要求（i.e., Handover Requestメッセージ）を運ぶ転送メッセージ（i.e., X2AP Message Transferメッセージ）をX2 GW３から受信する。ブロック６０２では、ターゲット(H)eNB２は、X2 GW３によるU-plane（X2-U）リレー処理が必要とされるか否かを判定する。U-plane（X2-U）リレー処理が必要とされる場合（ブロック６０２でYES）、ターゲット(H)eNB２は、ハンドオーバ要求承認（i.e., Handover Request Acknowledgeメッセージ）を運ぶ転送メッセージ（i.e., X2AP Message Transferメッセージ）に明示的又は暗示的なリレー要求を含める（ブロック６０３）。ブロック６０４では、ターゲット(H)eNB２は、ハンドオーバ要求承認を運ぶ転送メッセージ（リレー要求を含む）をX2 GW３に送信する。これに対して、U-plane（X2-U）リレー処理が必要とされない場合、（ブロック６０２でNO）、ターゲット(H)eNB２は、ハンドオーバ要求承認を運ぶ転送メッセージ（リレー要求を含まない）をX2 GW３に送信する（ブロック６０５）。
　ハンドオーバ要求承認を運ぶ転送メッセージ（リレー要求を含む）をターゲット(H)eNB２から受信したときのX2 GW３の動作は、図４と同様であってもよい。ただし、図５に関して説明したように、ハンドオーバ要求承認（i.e., Handover Request Acknowledgeメッセージ）は、ターゲット(H)eNB２のGTPトンネル・エンドポイント設定を含む。いくつかの実装において、ブロック４０３に相当する処理において、X2 GW３は、Handover Request Acknowledgeメッセージ内に記述されているターゲット(H)eNB２のGTPトンネル・エンドポイント設定を、X2 GW３のGTPトンネル・エンドポイント設定によって書き換えてもよい。
　これに代えて、ブロック４０３に相当する処理において、X2 GW３は、Handover Request Acknowledgeメッセージ内に記述されているターゲット(H)eNB２のGTPトンネル・エンドポイント設定に修正を加えずに、X2 GW３のエンドポイント設定を示す追加の情報要素をX2AP Message Transferメッセージに含めてもよい。この場合、ソース(H)eNB１は、追加の情報要素に従ってX2トランスポートベアラコンテキストを更新し、Handover Request Acknowledgeメッセージ内に記述されているターゲット(H)eNB２のGTPトンネル・エンドポイント設定を無視すればよい。
　ただし、ターゲット(H)eNB２のTNLアドレスをソース(H)eNB１から隠蔽するためにX2 GW３によるU-plane（X2-U）リレーが行われる場合、X2 GW３は、Handover Request Acknowledgeメッセージ内に記述されているターゲット(H)eNB２のGTPトンネル・エンドポイント設定を修正することが好ましい。これにより、ターゲット(H)eNB２のTNLアドレスのソース(H)eNB１からの隠蔽を確実に行うことができる。
　図３～図６は、ハンドオーバにおける (H)eNB１、(H)eNB２、及びX2 GW３の動作の具体例を示した。しかしながら、既に説明したことから理解されるように、図３～図６を用いて説明された(H)eNB１、(H)eNB２、及びX2 GW３の動作の具体例は、Dual connectivityをサポートするUEに関するベアラ確立を行う際に適用されてもよい。例えば、(H)eNB１は、Dual connectivityをサポートするUEに関するベアラ確立の要求をEPC４から受信したことに応答して、X2 GW３によるU-plane（X2-U）リレー処理を利用するか否かを判定してもよい。そして、(H)eNB１は、Dual connectivityのためのUEコンテキストの確立のためのX2APメッセージを運ぶ転送メッセージ（i.e., X2AP Message Transferメッセージ）に明示的又は暗示的なリレー要求を含めてもよい。
　続いて以下では、ソース(H)eNB１およびX2 GW３の動作とその起動条件の具体例について図７及び図８を用いて説明する。図７は、ソース(H)eNB１およびX2 GW３の動作とその起動条件の組み合せの一例を示すテーブルである。図７の例では、ソース(H)eNB１は、U-plane（X2-U）リレーを利用するか否か（又は要求するか否か）を判定するために、ダイレクトパス１００の利用可否（Direct Path Availability）及びX2 GW３のリレー能力（U-plane Relay Capability）を参酌する。
　図７に示されたケース１は、ダイレクトパス１００が利用可能であり、X2 GW３がリレー能力を有する場合である。図７に示されたケース２は、ダイレクトパス１００が利用でき、X2 GW３がリレー能力を有していない場合である。ケース１及びケース２では、ダイレクトパス１００が利用可能であるため、ソース(H)eNB１は、X2 GW３に対する明示的又は暗示的なリレー要求をX2AP Message Transferメッセージ（Handover Requestメッセージを運ぶ）に設定しない。したがって、X2 GW３は、DLデータフォワーディングに関するU-plane（X2-U）リレーを実施しない。
　図７に示されたケース３は、ダイレクトパス１００が利用不可であり、X2 GW３がリレー能力を有する場合である。ケース３では、ダイレクトパス１００が利用不可であるが、X2 GW３がリレー能力を有するため、ソース(H)eNB１は、X2 GW３に対する明示的又は暗示的なリレー要求をX2AP Message Transferメッセージ（Handover Requestメッセージを運ぶ）に設定する。したがって、X2 GW３は、DLデータフォワーディングに関するU-plane（X2-U）リレーを実施する。
　図７に示されたケース４は、ダイレクトパス１００が利用不可であり、且つX2 GW３がリレー能力を有していない場合である。ケース４では、X2-Uデータフォワーディングが不可能であるから、ソース(H)eNB１は、X2 GW３に対する明示的又は暗示的なリレー要求をX2AP Message Transferメッセージ（Handover Requestメッセージを運ぶ）に設定しない。したがって、X2 GW３は、DLデータフォワーディングに関するU-plane（X2-U）リレーを実施しない。
　なお、既に説明したように、いくつかの実装において、X2 GW３に対する暗示的なリレー要求（又はリレー表示）は、複数の情報要素の組み合せを含んでもよい。例えば、図８に示されているように、X2 GW３に対する暗示的なリレー要求（又はリレー表示）は、Direct Path Unavailability IEおよびDL Forwarding IEの組み合せであってもよい。図８に示されたDirect Path Unavailability IEは、ダイレクトパス１００が利用不可能であるときに設定される。Direct Path Unavailability IEは、１ビットのフラグ情報であってもよい。図８に示されたDL Forwarding IEは、現在の3GPP仕様においてX2AP: Handover Requestメッセージに含まれているDL Forwarding IEであってもよいし、X2AP Message Transferメッセージに新たに追加される情報要素であってもよい。
　図８に示されたケース１～４は、図７に示されたケース１～４にそれぞれ対応する。すなわち、図８に示されたケース１は、ダイレクトパス１００が利用可能であり、X2 GW３がリレー能力を有する場合である。図８に示されたケース２は、ダイレクトパス１００が利用でき、X2 GW３がリレー能力を有していない場合である。ケース１及びケース２では、ダイレクトパス１００が利用可能であるため、ソース(H)eNB１は、Direct Path Unavailability IEを設定しない。一方、（ダイレクトパス１００を介して）DLフォワーディングを行うことをターゲット(H)eNB２に知らせるために、DL Forwarding IEを設定する。
　図８に示されたケース３は、ダイレクトパス１００が利用不可であり、X2 GW３がリレー能力を有する場合である。ケース３では、ダイレクトパス１００が利用不可であるため、Direct Path Unavailability IEを設定する。さらに、ダイレクトパス１００を利用できないもののX2 GW３がリレー能力を有することから、ソース(H)eNB１は、X2 GW３を介したDLフォワーディングが可能であると判断し、したがって（X2 GW３を介して）DLフォワーディングを行うことをターゲット(H)eNB２に知らせるために、DL Forwarding IEを設定する。
　図８に示されたケース４は、ダイレクトパス１００が利用不可であり、且つX2 GW３がリレー能力を有していない場合である。したがって、ケース４では、ソース(H)eNB１は、Direct Path Unavailability IEを設定し、DL Forwarding IEを設定しない。
　図８の例では、X2 GW３は、Direct Path Unavailability IEおよびDL Forwarding IEを参照し、これらが共に設定されている場合にDLデータフォワーディングに関するU-Plane（X2-U）リレーを実施すればよい。したがって、図７の例と同様に、図８のケース３のみDLデータフォワーディングに関するU-Plane（X2-U）リレーが実施され、図８のケース１、２及び４ではDLデータフォワーディングに関するU-Plane（X2-U）リレーが実施されない。
　続いて以下では、ターゲット(H)eNB２およびX2 GW３の動作とその起動条件の具体例について図９及び図１０を用いて説明する。図９は、ターゲット(H)eNB２およびX2 GW３の動作とその起動条件の組み合せの一例を示すテーブルである。ターゲット(H)eNB２に関する図９の例は、ソース(H)eNB１に関する図７の例と対応する。したがって、図９のケース３のみULデータフォワーディングに関するU-Plane（X2-U）リレーが実施され、図９のケース１、２及び４ではULデータフォワーディングに関するU-Plane（X2-U）リレーが実施されない。
　図１０の例では、ターゲット(H)eNB２からX2 GW３に対する暗示的なリレー要求（又はリレー表示）が、Direct Path Unavailability IEおよびUL GTP Tunnel Endpoint IEの組み合せとされている。図１０に示されたUL GTP Tunnel Endpoint IEは、現在の3GPP仕様においてX2AP: Handover Request Acknowledgeメッセージに含まれているUL GTP Tunnel Endpoint IEであってもよいし、X2AP Message Transferメッセージに新たに追加される情報要素であってもよい。
　ターゲット(H)eNB２に関する図１０の例は、DL Forwarding IEとUL GTP Tunnel Endpoint IEの違いを除いて、ソース(H)eNB１に関する図８の例に対応する。すなわち、図１０の例では、X2 GW３は、Direct Path Unavailability IEおよびUL GTP Tunnel Endpoint IEを参照し、これらが共に設定されている場合にULデータフォワーディングに関するU-Plane（X2-U）リレーを実施すればよい。したがって、図１０のケース３のみULデータフォワーディングに関するU-Plane（X2-U）リレーが実施され、図１０のケース１、２及び４ではULデータフォワーディングに関するU-Plane（X2-U）リレーが実施されない。
　図７～図１０は、ハンドオーバにおける (H)eNB１、(H)eNB２、及びX2 GW３の動作の具体例を示した。しかしながら、既に説明したことから理解されるように、図７～図１０を用いて説明された(H)eNB１、(H)eNB２、及びX2 GW３の動作の具体例は、Dual connectivityをサポートするUEに関するベアラ確立を行う際に適用されてもよい。
　図７～図１０を用いて説明された例では、(H)eNB１及び(H)eNB２は、U-plane（X2-U）リレーを利用するか否か（又は要求するか否か）を判定する際に、X2 GW３のリレー能力の有無を考慮する。X2 GW３のリレー能力の有無は、オペレータによって、つまりoperations, administration and maintenance（OAM）によって、(H)eNBs１及び２に予め設定されてもよい。これに代えて、X2 GW３は、自身のリレー能力の有無を(H)eNBs１及び２に知らせてもよい。すなわち、X2 GW３は、自身のリレー能力の有無を示す情報要素（IE）を含むシグナリングメッセージを(H)eNBs１及び２に送信してもよい。いくつかの実装において、図１１及び図１２に示されるように、X2 GW３は、(H)eNBs１及び２をX2 GW３に登録する手順において、自身のリレー能力を(H)eNBs１及び２に知らせてもよい。
　図１１は、リレー能力の有無をX2 GW３から(H)eNBs１及び２に通知する手順の一例（処理１１００）を示すシーケンス図である。ブロック１１０１では、(H)eNBs１（２）は、登録要求をX2 GW３に送信する（(H)eNB registration）。当該登録要求は、登録要求に含まれる送信元(H)eNBの識別子（i.e., Global eNB ID）と登録要求の送信に使用された送信元(H)eNBのTNLアドレス（e.g., IPアドレス）のマッピングを保存する。そして、ブロック１１０２では、X2 GW３は、登録要求に対する応答を送信する（(H)eNB registration response）。当該応答は、X2 GW３のリレー能力の有無を示す情報要素（U-plane Relay Capability）を含む。(H)eNBs１（２）は、ブロック１１０２での応答を受信することにより、X2 GW３のU-plane（X2-U）リレー能力の有無を認識する。
　図１２は、リレー能力の有無をX2 GW３から(H)eNBs１及び２に通知する手順の他の例（処理１２００）を示すシーケンス図である。3GPP Release 12では、(H)eNBのX2 GWへの登録のために、X2AP Message Transferメッセージが使用される。図１２は、3GPP Release 12と同様にX2AP Message Transferメッセージを利用する例を示している。すなわち、ブロック１２０１では、登録を要求する(H)eNB１（２）は、RNL Header IE内にSource (H)eNB IDを含むが、RNL Header IE内にTarget (H)eNB IDを含まず、かつX2AP Messageを含まないX2AP Message Transferメッセージを送信する。ブロック１２０２では、X2 GW３は、変更されたX2AP Message Transferメッセージを送信する。当該変更されたX2AP Message Transferメッセージは、RNL Header IE内にTarget (H)eNB IDを含み、新たに定義されたU-plane Relay Capability IEを含むが、RNL Header IE内にSource (H)eNB IDを含まず、かつX2AP Messageを含まないX2AP Message Transferメッセージを送信する。(H)eNBs１（２）は、ブロック１２０２でのX2AP Message Transferメッセージを受信することにより、X2 GW３のU-plane（X2-U）リレー能力の有無を認識する。
　図１３Ａ及び図１３Ｂは、本実施形態に係るX2ハンドオーバ手順の一例（処理１３００）を示すシーケンス図である。図１３Ａ及び図１３Ｂに示された手順は、ソース(H)eNB１からターゲット(H)eNB２へのユーザデータパケットのフォワーディングがX2 GW３を介して行われること（ブロック１３０７及び１３０８）を除いて、通常のX2 GWを介するX2ハンドオーバ手順と同様である。すなわち、ブロック１３０１では、ソース(H)eNB１は、Handover Requestメッセージを運ぶX2AP Message TransferメッセージをX2 GW３に送信する。既に説明したように、当該X2AP Message Transferメッセージは、U-plane（X2-U）リレーの要否を明示的又は暗示的に示す情報要素を含んでもよい。ブロック１３０２では、X2 GW３は、Handover Requestメッセージを運ぶX2AP Message Transferメッセージをターゲット(H)eNB２に転送する。既に説明したように、X2 GW３は、U-plane（X2-U）リレーを行うか否かに応じて、ブロック１３０２でのX2AP Message Transferメッセージ内の情報要素を更新してもよいし、情報要素を追加してもよい。
　ブロック１３０３では、ターゲット(H)eNB２は、Handover Request Acknowledgeメッセージを運ぶX2AP Message TransferメッセージをX2 GW３に送信する。既に説明したように、当該X2AP Message Transferメッセージは、U-plane（X2-U）リレーの要否を明示的又は暗示的に示す情報要素を含んでもよい。ブロック１３０４では、X2 GW３は、Handover Request Acknowledgeメッセージを運ぶX2AP Message Transferメッセージをソース(H)eNB１に転送する。既に説明したように、X2 GW３は、U-plane（X2-U）リレーを行うか否かに応じて、ブロック１３０４でのX2AP Message Transferメッセージ内の情報要素を更新してもよいし、情報要素を追加してもよい。
　ソース(H)eNB１は、Handover Request Acknowledgeメッセージの受信に応答して、図示されていないUEにハンドオーバ指示（Handover Command）を送信する。ブロック１３０５では、ソース(H)eNB１は、SN Status Transferメッセージを運ぶX2AP Message TransferメッセージをX2 GW３に送信する。SN Status Transferメッセージは、UEへの送達が完了してないuplink/downlink Packet Data Convergence Protocol（PDCP） PDUのSequence Number（SN）を示す。ブロック１３０６では、X2 GW３は、SN Status Transferメッセージを運ぶX2AP Message Transferメッセージをターゲット(H)eNB２に転送する。
　ブロック１３０７及び１３０８では、ソース(H)eNB１は、UEへの送達が完了していないuplink/downlink ユーザデータパケットを、X2 GW３を介してターゲット(H)eNB２にフォワーディングする。すなわち、ブロック１３０７では、ソース(H)eNB１は、ソース(H)eNB１とX2 GW３の間のGTP-Uトンネルを介して、uplink/downlink ユーザデータパケットをカプセル化しているG-PDUをX2 GW３に送信する。ブロック１３０８では、X2 GW３は、ターゲット(H)eNB２とX2 GW３の間のGTP-Uトンネルを介して、ソース(H)eNB１から受信したG-PDUをターゲット(H)eNB２に転送する。
　ブロック１３０７及び１３０８のデータフォワーディングでは、X2GW３は、ソース(H)eNB１から受信したG-PDUに付与されているソースTNLアドレス（i.e., ソース(H)eNB１のTNLアドレス）をX2GW３のTNLアドレスによって更新し、ソースTEID（i.e., ソース(H)eNB１のTEID）をX2GW３のTEIDによって更新する。さらに、X2GW３は、ソース(H)eNB１から受信したG-PDUに付与されているターゲットTNLアドレス（i.e., X2GW３のTNLアドレス）をターゲット(H)eNB２のTNLアドレスによって更新し、ターゲットTEID（i.e., X2GW３のTEID）をターゲット(H)eNB２のTEIDによって更新する。
　ブロック１３０９では、ターゲット(H)eNB２は、UEからハンドオーバ確認（Handover Confirm）メッセージを受信する。これにより、UEは、ターゲット(H)eNB２にULユーザデータパケットを送信することができ、DLユーザデータパケットをターゲット(H)eNB２から受信できる。
　ブロック１３１０では、ターゲット(H)eNB２は、UEのサービングセルの変更をEPC４に知らせるとともにEvolved Packet System （EPS）ベアラの経路変更を要求するために、S1AP: Path Switch RequestメッセージをEPC４（つまり、Mobility Management Entity（MME）５）に送信する。MME５は、図示していないServing Gateway（S－GW）とシグナルし、EPSベアラの経路（つまり、S1ベアラの経路）を修正する。ブロック１３１１では、MME５は、S1AP: Path Switch Request Acknowledgeメッセージをターゲット(H)eNB２に送信する。ブロック１３１２では、Path Switch Request Acknowledgeメッセージの受信に応答して、ターゲット(H)eNB２は、UE Context Releaseメッセージを運ぶX2AP Message TransferメッセージをX2 GW３に送信する。ブロック１３１３では、X2 GW３は、UE Context Releaseメッセージを運ぶX2AP Message Transferメッセージをソース(H)eNB１に転送する。ソース(H)eNB１は、UE Context Releaseメッセージの受信に応答して、UEに割り当てた無線リソースを解放する。
　なお、ターゲット(H)eNB２は、UE Context Releaseメッセージの送信（ブロック１３１２）に応答して、データフォワーディングのためのGTP-Uトンネル設定を開放してもよい。X2 GW３は、UE Context Releaseメッセージを運ぶX2AP Message Transferメッセージの受信（ブロック１３１２）に応答して、データフォワーディングのためのGTP-Uトンネル設定を開放してもよい。ソース(H)eNB１は、UE Context Releaseメッセージの受信（ブロック１３１３）に応答して、データフォワーディングのためのGTP-Uトンネル設定を開放してもよい。
　続いて以下では、X2AP Message Transferメッセージの変更（modification）の具体例について、図１４並びに図１５Ａ及び図１５Ｂを用いて説明する。図１４は、X2AP Message Transferメッセージの変更の一例を示している。“U-Plane Relay Capability” IEは、U-plane（X2-U）リレー能力の有無を(H)eNBs１及び２に知らせるためにX2 GW３によって使用される。“Direct Path Unavailability” IEは、ダイレクトパス１００の利用可否をX2 GW３に知らせるために(H)eNBs１及び２によって使用される。“E-RABs To Be Setup List” IEは、X2 GW３のEndpoint設定を(H)eNBs１及び２に知らせるためにX2 GW３によって使用される。
　“E-RABs To Be Setup List” IEは、“E-RABs To Be Setup Item” IEを含む。“E-RABs To Be Setup Item” IEは、“E-RAB ID” IE、“UL GTP Tunnel Endpoint” IE、及び“DL GTP Tunnel Endpoint” IEを含む。“UL GTP Tunnel Endpoint” IEは、ULデータ（UL PDUs）フォワーディングのためのX2トランスポートベアラに関するX2 GW３のEndpoint設定（つまり、TNLアドレス及びTEID）を示す。“DL GTP Tunnel Endpoint” IEは、DLデータ（DL PDUs）フォワーディングのためのX2トランスポートベアラに関するX2 GW３のEndpoint設定（つまり、TNLアドレス及びTEID）を示す。
　図１５Ａ及び図１５Ｂは、X2AP Message Transferメッセージの変更の他の例を示している。図１５Ａに示されているように、X2AP Message Transferメッセージは、“Message Type of X2AP Message” IEを含むように拡張されてもよい。“Message Type of X2AP Message” IEは、X2AP Message Transferメッセージによって運ばれるX2APメッセージの種別を示す。これにより、X2 GW３は、必要なX2APメッセージのみ参照又はデコードするように動作することができる。すなわち、“Message Type of X2AP Message” IE がHandover Requestメッセージ又はHandover Request Acknowledgeメッセージを示す場合にのみ、X2AP Message Transferメッセージ内の“X2AP message” IEを参照又はデコードしてもよい。
　さらに又はこれに代えて、図１５Ｂに示されるように、X2AP Message Transferメッセージは、“DL Forwarding” IEを含むように拡張されてもよい。“DL Forwarding” IEは、“X2AP message” IEがHandover Requestメッセージを運ぶ場合に、ソース(H)eNB１によって使用される。“DL Forwarding” IEは、“X2AP message” IE内のHandover Requestメッセージに含まれる“DL Forwarding” IEと同じ内容を示す。これにより、X2 GW３は、“DL Forwarding” IE を確認するために“X2AP message” IE内のHandover Requestメッセージをデコード又は参照する必要がなくなる。
　これと同じ思想に従って、X2AP Message Transferメッセージは、図１５Ｂに示された“E-RAB Level QoS Parameters” IEを含むように拡張されてもよい。“E-RAB Level QoS Parameters” IEは、“X2AP message” IEがHandover Requestメッセージを運ぶ場合に、ソース(H)eNB１によって使用される。“E-RAB Level QoS Parameters” IEは、“X2AP message” IE内のHandover Requestメッセージに含まれる“E-RAB Level QoS Parameters” IEと同じ内容を示す。
　これと同じ思想に従って、図１５Ｂに示された“E-RAB ID” IEは、“X2AP message” IEがHandover Requestメッセージを運ぶ場合に、ソース(H)eNB１によって使用されてもよい。この場合、“E-RAB ID” IEは、“X2AP message” IE内のHandover Requestメッセージに含まれる“E-RAB ID” IEと同じ内容を示す。さらに、図１５Ｂに示された“E-RAB ID” IEは、“X2AP message” IEがHandover Request Acknowledgeメッセージを運ぶ場合に、ターゲット(H)eNB２によって使用されてもよい。この場合、“E-RAB ID” IEは、“X2AP message” IE内のHandover Request Acknowledgeメッセージに含まれる“E-RAB ID” IEと同じ内容を示す。
　これと同じ思想に従って、図１５Ｂに示された“DL GTP Tunnel Endpoint” IE及び“UL GTP Tunnel Endpoint” IEは、“X2AP message” IEがHandover Request Acknowledgeメッセージを運ぶ場合に、ターゲット(H)eNB２によって使用されてもよい。この場合、“DL GTP Tunnel Endpoint” IE及び“UL GTP Tunnel Endpoint” IEは、“X2AP message” IE内のHandover Request Acknowledgeメッセージに含まれる“DL GTP Tunnel Endpoint” IE及び“UL GTP Tunnel Endpoint” IEと同じ内容を示す。
　このように、Handover Request メッセージ及びHandover Request Acknowledgeメッセージ内の複数の情報要素のうち、U-plane（X2-U）リレーのためにX2 GW３が参照しなければならない一部の情報要素をX2AP Message Transferメッセージに含めることによって以下の利点がある。すなわち、X2 GW３は、X2AP Message IEを透過的に転送すればよく、X2AP Message IEの参照又はデコードを行う必要がない。もしX2 GW３が常にX2AP Message IE の参照又はデコードすると、X2 GW３の処理能力を大きく消費するかもしれないし、X2 GW３のプロトコルバージョンと(H)eNB間のX2APプロトコルバージョンが異なることでプロトコルエラーが発生するかもしれない。X2 GW３は、X2AP Message IEを透過的に転送することで、これらの問題の発生を回避することができる。
　なお、図１５Ａ及び図１５Ｂに示すように、Handover Requestメッセージ又はHandover Request Acknowledgeメッセージ内の情報要素と同一内容を持つ情報要素がX2AP Message Transferメッセージに追加される場合、これらの追加された情報要素（例えば、“DL Forwarding” IE、“E-RAB Level QoS Parameters” IE、“E-RAB ID” IE、“DL GTP Tunnel Endpoint” IE、及び“UL GTP Tunnel Endpoint” IEのうち少なくとも１つ）は、暗示的なリレー要求（又はリレー表示）として利用されてもよい。すなわち、X2 GW３は、X2AP Message Transferメッセージが追加された情報要素を含むか否かに応じて、(H)eNB１又は２からのリレー要求の有無を検出してもよい。この場合、X2AP Message Transferメッセージは、“Direct Path Unavailability” IE（又はその他の明示的又は暗示的なリレー要求）を含まなくてもよい。
＜第２の実施形態＞
　本実施形態では、X2 GW３のX2-U TNLアドレス（e.g., IPアドレス）をターゲット(H)eNB２に知らせる手順の具体例を説明する。第１の実施形態では、X2 GW３のX2-U TNLアドレスがOAMによってターゲット(H)eNB２に設定される例、及びX2AP Message Transferメッセージを用いてX2 GW３からターゲット(H)eNB２にX2 GW３のX2-U TNLアドレスが通知される例を示した。これらに代えて、改良されたEnhanced TNL Address Discovery手順が使用されてもよい。
　Enhanced TNL Address Discovery手順は、非特許文献１のセクション4.6.6.1に規定されている。Enhanced TNL Address Discovery手順では、(H)eNBは、当該(H)eNBが接続されているX2 GWのTNLアドレスをS1AP: eNB CONFIGURATION TRANSFERメッセージに含め、X2 GWのTNLアドレスを含むeNB CONFIGURATION TRANSFERメッセージをMMEに送信する。MMEは、eNB CONFIGURATION TRANSFERメッセージに含まれるtarget eNB ID及びX2 GWのTNLアドレスを取得し、S1AP: MME CONFIGURATION TRANSFERメッセージを用いてtarget eNB IDにX2 GWのTNLアドレスを転送する。これにより、２つの(H)eNBは、X2 GWのTNLアドレスを認識でき、当該X2 GWを介したインダイレクトX2を利用できる。
　しかしながら、既存のEnhanced TNL Address Discovery手順によって転送されるX2 GWのTNLアドレスは、SCTPコネクションにおいてX2APシグナリングメッセージを転送するためのTNLアドレス（つまり、X2-C TNLアドレス）であることに留意するべきである。本実施形態では、G-PDUを運ぶTNL UDP/IPパケットを転送するためのX2 GWのTNLアドレス（つまり、X2-U TNLアドレス）を転送するように、Enhanced TNL Address Discovery手順が変更される。
　図１６は、本実施形態に係るEnhanced TNL Address Discovery手順の一例（処理１６００）を示すシーケンス図である。図１６の手順は、X2 GW U-plane アドレス（X2-U TNLアドレス）が送られる点を除いて、既存のEnhanced TNL Address Discovery手順と同様である。すなわち、ブロック１６０１では、ソース(H)eNB１は、S1AP: eNB CONFIGURATION TRANSFERメッセージをMME５に送信する。当該eNB CONFIGURATION TRANSFERメッセージは、X2 GW３のU-plane アドレス（X2-U TNLアドレス）を含む。ブロック１６０２では、MME５は、S1AP: MME CONFIGURATION TRANSFERメッセージをターゲット(H)eNB２に送信する。当該MME CONFIGURATION TRANSFERメッセージは、ソース(H)eNB１から受信したX2 GW３のU-plane アドレス（X2-U TNLアドレス）を含む。
　ブロック１６０３では、ターゲット(H)eNB２は、受信したX2 GW３のU-plane アドレス（X2-U TNLアドレス）をACLに追加する。ブロック１６０４では、ターゲット(H)eNB２は、S1AP: eNB CONFIGURATION TRANSFERメッセージをMME５に送信する。当該eNB CONFIGURATION TRANSFERメッセージは、ソース(H)eNB１に対する応答である。ブロック１６０５では、MME５は、S1AP: MME CONFIGURATION TRANSFERメッセージをソース(H)eNB１に送信する。MME CONFIGURATION TRANSFERメッセージは、ターゲット(H)eNB２からeNB CONFIGURATION TRANSFERメッセージにより受信した情報要素（e.g., ターゲット(H)eNB２がソース(H)eNB１から受信したX2 GW３のU-plane アドレス）を含む。
　図１７Ａ及び図１７Ｂは、3GPP TS 36.413 V12.4.0のセクション9.2.3.29 に規定されている“X2 TNL Configuration Info” IEの変更の具体例を示している。“X2 TNL Configuration Info” IEは、S1AP: eNB CONFIGURATION TRANSFERメッセージ及びS1AP: MME CONFIGURATION TRANSFERメッセージに含まれる。図１７Ｂに示されているように、“X2 TNL Configuration Info” IEは、インダイレクトX2 U-plane エンドポイントに関するTNLアドレス（つまり、X2 GW３のX2-U TNLアドレス）を示す“Transport Layer Address” IEを含むように拡張されてもよい。
　最後に、上述の複数の実施形態に係る(H)eNB１、(H)eNB２、及びX2 GW３の構成例について説明する。図１８は、(H)eNB１の構成例を示すブロック図である。(H)eNB２も、図１８の構成と同様の構成を有してもよい。図１８を参照すると、(H)eNB１は、RFトランシーバ１８０１、ネットワークインターフェース１８０３、プロセッサ１８０４、及びメモリ１８０５を含む。RFトランシーバ１８０１は、UEsと通信するためにアナログRF信号処理を行う。RFトランシーバ１８０１は、複数のトランシーバを含んでもよい。RFトランシーバ１８０１は、アンテナ１８０２及びプロセッサ１８０４と結合される。RFトランシーバ１８０１は、変調シンボルデータ（又はOFDMシンボルデータ）をプロセッサ１８０４から受信し、送信RF信号を生成し、送信RF信号をアンテナ１８０２に供給する。また、RFトランシーバ１８０１は、アンテナ１８０２によって受信された受信ＲＦ信号に基づいてベースバンド受信信号を生成し、これをプロセッサ１８０４に供給する。
　ネットワークインターフェース１８０３は、ネットワークノード（e.g., MMEおよびS/P-GW）と通信するために使用される。ネットワークインターフェース１８０３は、例えば、IEEE 802.3 seriesに準拠したネットワークインターフェースカード（NIC）を含んでもよい。
　プロセッサ１８０４は、無線通信のためのデジタルベースバンド信号処理を含むデータプレーン処理とコントロールプレーン処理を行う。例えば、LTEおよびLTE-Advancedの場合、プロセッサ１８０４によるデジタルベースバンド信号処理は、PDCPレイヤ、RLCレイヤ、MACレイヤ、およびPHYレイヤの信号処理を含んでもよい。さらに、プロセッサ１８０４による信号処理は、X2-Uインタフェース及びS1-UインタフェースでのGTP-U・UDP/IPレイヤの信号処理を含んでもよい。また、プロセッサ１８０４によるコントロールプレーン処理は、X2APプロトコル、S1-MMEプロトコルおよびRRCプロトコルの処理を含んでもよい。
　プロセッサ１８０４は、複数のプロセッサを含んでもよい。例えば、プロセッサ１８０４は、プロセッサ１８０４は、デジタルベースバンド信号処理を行うモデム・プロセッサ（e.g., DSP）、X2-Uインタフェース及びS1-UインタフェースでのGTP-U・UDP/IPレイヤの信号処理を行うプロセッサ（e.g., DSP）、及びコントロールプレーン処理を行うプロトコルスタック・プロセッサ（e.g., CPU又はMPU）を含んでもよい。
　メモリ１８０５は、揮発性メモリ及び不揮発性メモリの組み合わせによって構成される。メモリ１８０５は、物理的に独立した複数のメモリデバイスを含んでもよい。揮発性メモリは、例えば、Static Random Access Memory（SRAM）若しくはDynamic RAM（DRAM）又はこれらの組み合わせである。不揮発性メモリは、マスクRead Only Memory（MROM）、Electrically Erasable Programmable ROM（EEPROM）、フラッシュメモリ、若しくはハードディスクドライブ、又はこれらの任意の組合せである。メモリ１８０５は、プロセッサ１８０４から離れて配置されたストレージを含んでもよい。この場合、プロセッサ１８０４は、ネットワークインターフェース１８０３又は図示されていないI/Oインタフェースを介してメモリ１８０５にアクセスしてもよい。
　メモリ１８０５は、上述の複数の実施形態で説明された(H)eNB１による処理を行うための命令群およびデータを含むソフトウェアモジュール（コンピュータプログラム）を格納してもよい。いくつかの実装において、プロセッサ１８０４は、当該ソフトウェアモジュールをメモリ１８０５から読み出して実行することで、上述の実施形態で説明された(H)eNB１の処理を行うよう構成されてもよい。
　図１９は、X2 GW３の構成例を示すブロック図である。図１６を参照すると、X2 GW３は、ネットワークインターフェース１９０１、プロセッサ１９０２、及びメモリ１９０３を含む。ネットワークインターフェース１９６０１は、ネットワークノード（e.g., (H)eNB１及び(H)eNB２）と通信するために使用される。ネットワークインターフェース１９０１は、例えば、IEEE 802.3 seriesに準拠したネットワークインターフェースカード（NIC）を含んでもよい。
　プロセッサ１９０２は、メモリ１９０３からソフトウェア（コンピュータプログラム）を読み出して実行することで、上述の実施形態において説明されたX2 GW３の処理を行う。プロセッサ１９０２は、例えば、マイクロプロセッサ、MPU、又はCPUであってもよい。プロセッサ１９０２は、複数のプロセッサを含んでもよい。
　メモリ１９０３は、揮発性メモリ及び不揮発性メモリの組み合わせによって構成される。メモリ１９０３は、プロセッサ１９０２から離れて配置されたストレージを含んでもよい。この場合、プロセッサ１９０２は、図示されていないI/Oインタフェースを介してメモリ１９０３にアクセスしてもよい。
　図１８及び図１９を用いて説明したように、上述の実施形態に係る(H)eNB１、(H)eNB２、及びX2 GW３が有するプロセッサの各々は、図面を用いて説明されたアルゴリズムをコンピュータに行わせるための命令群を含む１又は複数のプログラムを実行する。このプログラムは、様々なタイプの非一時的なコンピュータ可読媒体（non-transitory computer readable medium）を用いて格納され、コンピュータに供給することができる。非一時的なコンピュータ可読媒体は、様々なタイプの実体のある記録媒体（tangible storage medium）を含む。非一時的なコンピュータ可読媒体の例は、磁気記録媒体（例えばフレキシブルディスク、磁気テープ、ハードディスクドライブ）、光磁気記録媒体（例えば光磁気ディスク）、Compact Disc Read Only Memory（CD-ROM）、CD-R、CD-R/W、半導体メモリ（例えば、マスクROM、Programmable ROM（PROM）、Erasable PROM（EPROM）、フラッシュROM、Random Access Memory（RAM））を含む。また、プログラムは、様々なタイプの一時的なコンピュータ可読媒体（transitory computer readable medium）によってコンピュータに供給されてもよい。一時的なコンピュータ可読媒体の例は、電気信号、光信号、及び電磁波を含む。一時的なコンピュータ可読媒体は、電線及び光ファイバ等の有線通信路、又は無線通信路を介して、プログラムをコンピュータに供給できる。
＜その他の実施形態＞
　上述の実施形態は、各々独立に実施されてもよいし、適宜組み合わせて実施されてもよい。
　上述の実施形態では、X2 GWのX2-UインタフェースにおいてGTP-Uプロトコルが使用される例を示した。しかしながら、GTP-Uプロトコルとは異なるプロトコル、例えばProxy Mobile. IPv6（PMIPv6）が使用されてもよい。
　上述の実施形態は、例えば、UMTS及びGSMシステム等の他の無線通信システムに適用されてもよい。上述の実施形態で説明された基地局（(H)eNB）は、無線リソース管理機能を持つ制御ノード（e.g., UMTSにおけるRadio Network Controller（RNC）、又はGSMシステムにおけるBase Station Controller（BSC））及び無線送信ノード（e.g., UMTSにおけるNodeB、又はGSMシステムにおけるBase transceiver station （BTS））を含んでもよい。
　例えば、3GPP TS25.467に示されるように、Home NodeB（HNB）がHome NodeB Gateway（HNB-GW）を経由してRNCにIur接続する場合に、HNBとRNC間においてHNB-GW経由でrelocationを実施することができる。この場合に、HNBは、RNSAP: Enhanced Relocation RequestメッセージをIurhインタフェース上でHNB-GW経由で送る。そして、HNB-GWは、Iurインタフェース上でRNSAP: Enhanced Relocation RequestメッセージをSignalling Connection Control Part（SCCP）を用いて転送する。この場合、HNB-GWは、HNBとRNCの間でU-Planeリレーをさらに行ってもよい。
　上述の実施形態は、UMTSシステムとLTE/LTE-Advancedシステムの間でゲートウェイが用いられる場合に適用されてもよい。例えば、LTEのHeNBとUMTSのRNC間においてハンドオーバを実施する場合に、当該ゲートウェイは、HeNBとRNCの間でU-Planeリレーを行ってもよい。
　上述の実施形態は、CDMA2000システムとLTE/LTE-Advancedシステムの間でゲートウェイが用いられる場合に適用されてもよい。例えば、LTEのHeNBとCDMA2000システムの基地局間においてハンドオーバを実施する場合に、当該ゲートウェイは、U-Planeリレーを行ってもよい。
　上述の実施形態は、Wireless Local Area Network（WLAN）システムとLTE/LTE-Advancedシステムの間でゲートウェイが用いられる場合に適用されてもよい。例えば、LTEのHeNBとWLANのアクセスポイント間においてハンドオーバを実施する場合に、当該ゲートウェイは、HeNBとアクセスポイントの間でU-Planeリレーを行ってもよい。
　さらに、上述の実施形態は、任意のRadio Access Technology（RAT）内の基地局間ハンドオーバのために基地局間ゲートウェイを使用する場合に適用されることができる。さらに、上述の実施形態は、任意のRAT間の基地局間ハンドオーバのために基地局間ゲートウェイを使用する場合に適用されることができる。
　さらに、上述の実施形態は、Relay Node（RN）およびDonor eNB（DeNB）の間のハンドオーバのためにX2ゲートウェイを使用する場合に適用されることができる。RN及びDeNBは、3GPP TS36.300（非特許文献１）に記載されている。
　さらに、上述の実施形態は、既に説明したように、Dual ConnectivityのケースにおいてMaster eNB（MeNB）とSecondary eNB（SeNB）の間のユーザデータパケットの転送のためにX2ゲートウェイを使用する場合に適用されることができる。Dual Connectivityは、3GPP TS36.300（非特許文献１）に記載されている。
　さらに、上述した実施形態は本件発明者により得られた技術思想の適用に関する例に過ぎない。すなわち、当該技術思想は、上述した実施形態のみに限定されるものではなく、種々の変更が可能であることは勿論である。
　例えば、上記の実施形態の一部又は全部は、以下の付記のようにも記載され得るが、以下には限られない。
（付記１）
　基地局装置により行われる方法であって、
　無線端末宛て又は前記無線端末からのデータパケットを基地局間ゲートウェイが前記基地局装置と他の基地局の間で中継するリレー処理が必要とされる否かを決定する際に、前記基地局装置と前記他の基地局の間のダイレクトパスの利用可否を考慮することを備える、
方法。
（付記２）
　基地局装置により行われる方法であって、
　無線端末宛て又は前記無線端末からのデータパケットを基地局間ゲートウェイが前記基地局装置と他の基地局の間で中継するリレー処理が必要とされる否かを決定する際に、前記基地局間ゲートウェイの前記リレー処理の能力を考慮することを備える、
方法。
（付記３）
　基地局装置により行われる方法であって、
　第１の情報要素を基地局間ゲートウェイに送信することを備え、
　前記第１の情報要素は、前記基地局装置と他の基地局の間のダイレクトパスの利用可否を示す、
方法。
（付記４）
　基地局間ゲートウェイ装置によって行われる方法であって、
　リレー処理の能力を基地局に通知することを備え、
　前記リレー処理は、無線端末宛て又は前記無線端末からのデータパケットを前記基地局間ゲートウェイ装置によって第１の基地局と第２の基地局の間で中継することを含む、
方法。
（付記５）
　基地局間ゲートウェイ装置であって、
　メモリと、
　前記メモリに結合された少なくとも１つのプロセッサと、
を備え、
　前記少なくとも１つのプロセッサは、第１の情報要素を第１の基地局及び第２の基地局の少なくとも一方から受信するよう構成され、
　前記第１の情報要素は、無線端末宛て又は前記無線端末からのデータパケットを前記基地局間ゲートウェイ装置によって前記第１の基地局と前記第２の基地局の間で中継するリレー処理が必要とされる否かを明示的または暗示的に示す、
基地局間ゲートウェイ装置。
（付記６）
　前記第１の情報要素は、前記第１の基地局と前記第２の基地局の間のダイレクトパスの利用可否を明示的に示す、
付記５に記載の基地局間ゲートウェイ装置。
（付記７）
　前記少なくとも１つのプロセッサは、前記第１の基地局から前記第２の基地局への前記無線端末のハンドオーバの際に、前記第１の情報要素を受信するよう構成されている、
付記５又は６に記載の基地局間ゲートウェイ装置。
（付記８）
　前記少なくとも１つのプロセッサは、前記リレー処理の能力を示す第２の情報要素を前記第１の基地局及び前記第２の基地局の少なくとも一方に送信するよう構成されている、
付記５～７のいずれか１項に記載の基地局間ゲートウェイ装置。
（付記９）
　前記少なくとも１つのプロセッサは、前記第１の基地局及び前記第２の基地局の少なくとも一方を前記基地局間ゲートウェイ装置に登録する手順において、前記第２の情報要素を送信するよう構成されている、
付記８に記載の基地局間ゲートウェイ装置。
（付記１０）
　前記少なくとも１つのプロセッサは、前記第１の情報要素に基づいて、前記リレー処理を行うか否かを決定するよう構成されている、
付記５～９のいずれか１項に記載の基地局間ゲートウェイ装置。
（付記１１）
　前記少なくとも１つのプロセッサは、前記基地局間ゲートウェイ装置によって前記リレー処理が行われる場合に、前記第１の基地局から前記第２の基地局へのハンドオーバ要求メッセージを運ぶ第１の転送メッセージに、前記基地局間ゲートウェイ装置と前記第２の基地局の間で前記データパケットを転送するための第１のトランスポートベアラに関する前記基地局間ゲートウェイ装置のエンドポイント設定を含めるよう構成されている、
付記５～１０のいずれか１項に記載の基地局間ゲートウェイ装置。
（付記１２）
　前記エンドポイント設定は、前記第２の基地局においてパケットフィルタを更新するために使用される、
付記１１に記載の基地局間ゲートウェイ装置。
（付記１３）
　前記エンドポイント設定は、前記基地局間ゲートウェイ装置のトランスポートレイヤ・アドレスを含む、
付記１１又は１２に記載の基地局間ゲートウェイ装置。
（付記１４）
　前記エンドポイント設定は、ダンリンクフォワーディングのためのエンドポイント設定及びアップリンクフォワーディングのためのエンドポイント設定を含む、
付記１１～１３のいずれか１項に記載の基地局間ゲートウェイ装置。
（付記１５）
　前記少なくとも１つのプロセッサは、前記基地局間ゲートウェイ装置によって前記リレー処理が行われる場合に、前記第２の基地局から前記第１の基地局へのハンドオーバ要求承認メッセージを運ぶ第２の転送メッセージに、前記基地局間ゲートウェイ装置と前記第１の基地局の間で前記データパケットを転送するための第２のトランスポートベアラに関する前記基地局間ゲートウェイ装置のエンドポイント設定を含めるよう構成されている、
付記５～１４のいずれか１項に記載の基地局間ゲートウェイ装置。
（付記１６）
　基地局装置により行われる方法であって、
　第１の情報要素を基地局間ゲートウェイに送信することを備え、
　前記第１の情報要素は、無線端末宛て又は前記無線端末からのデータパケットを前記基地局間ゲートウェイが前記基地局装置と他の基地局の間で中継するリレー処理が必要とされる否かを明示的または暗示的に示す、
方法。
（付記１７）
　前記第１の情報要素は、前記基地局装置と前記他の基地局の間のダイレクトパスの利用可否を明示的に示す、
付記１６に記載の方法。
（付記１８）
　前記送信することは、前記基地局装置から前記他の基地局または前記他の基地局から前記基地局装置への前記無線端末のハンドオーバの際に、前記第１の情報要素を送信することを含む、
付記１６又は１７に記載の方法。
（付記１９）
　前記送信することは、前記他の基地局へのハンドオーバ要求メッセージ又はハンドオーバ要求承認メッセージを運ぶために前記基地局間ゲートウェイに送信される転送メッセージに前記第１の情報要素を含めることを含む、
付記１８に記載の方法。
（付記２０）
　前記第１の情報要素は、前記リレー処理が必要とされることを暗示的に示すために、前記転送メッセージによって運ばれる前記ハンドオーバ要求メッセージ又は前記ハンドオーバ要求承認メッセージに包含されている第２の情報要素と同じ内容を示す、
付記１９に記載の方法。
（付記２１）
　前記転送メッセージによって運ばれる前記ハンドオーバ要求メッセージ又は前記ハンドオーバ要求承認メッセージに包含されている第２の情報要素と同じ内容の第３の情報要素を前記転送メッセージに含めることをさらに備える、
付記１９に記載の方法。
（付記２２）
　前記第２の情報要素は、前記データパケットのフォワーディングの要否を示す情報要素、前記無線端末のために設定されたベアラの識別子を示す情報要素、および前記ベアラのQuality of Service（QoS）パラメータを示す情報要素のうち少なくとも１つを含む、
付記２０又は２１に記載の方法。
（付記２３）
　前記転送メッセージによって運ばれる基地局間シグナリングメッセージの種別を示す情報要素を前記転送メッセージに含めることをさらに備える、
付記１９～２２のいずれか１項に記載の方法。
（付記２４）
　前記データパケットの送信又は受信のために、前記基地局間ゲートウェイによる前記リレー処理を利用するか否かを決定すること、及び
　前記リレー処理が利用されない場合に、前記基地局装置と前記他の基地局の間のダイレクトパスを用いて前記データパケットをフォワーディングすること、
をさらに備える、
付記１６～２３のいずれか１項に記載の方法。
（付記２５）
　基地局間ゲートウェイ装置によって行われる方法であって、
　第１の情報要素を第１の基地局及び第２の基地局の少なくとも一方から受信することを備え、
　前記第１の情報要素は、無線端末宛て又は前記無線端末からのデータパケットを前記基地局間ゲートウェイ装置によって前記第１の基地局と前記第２の基地局の間で中継するリレー処理が必要とされる否かを明示的または暗示的に示す、
方法。
（付記２６）
　前記第１の情報要素は、前記第１の基地局と前記第２の基地局の間のダイレクトパスの利用可否を明示的に示す、
付記２５に記載の方法。
（付記２７）
　前記受信することは、前記第１の基地局から前記第２の基地局への前記無線端末のハンドオーバの際に、前記第１の情報要素を受信することを含む、
付記２５又は２６に記載の方法。
（付記２８）
　前記リレー処理の能力を示す第２の情報要素を前記第１の基地局及び前記第２の基地局の少なくとも一方に送信することをさらに備える、
付記２５～２７のいずれか１項に記載の方法。
（付記２９）
　前記送信することは、前記第１の基地局及び前記第２の基地局の少なくとも一方を前記基地局間ゲートウェイ装置に登録する手順において、前記第２の情報要素を送信することを含む、
付記２８に記載の方法。
（付記３０）
　前記第１の情報要素に基づいて、前記リレー処理を行うか否かを決定することをさらに備える、
付記２５～２９のいずれか１項に記載の方法。
（付記３１）
　前記基地局間ゲートウェイ装置によって前記リレー処理が行われる場合に、前記第１の基地局から前記第２の基地局へのハンドオーバ要求メッセージを運ぶ第１の転送メッセージに、前記基地局間ゲートウェイ装置と前記第２の基地局の間で前記データパケットを転送するための第１のトランスポートベアラに関する前記基地局間ゲートウェイ装置のエンドポイント設定を含めることをさらに備える、
付記２５～３０のいずれか１項に記載の方法。
（付記３２）
　前記エンドポイント設定は、前記第２の基地局においてパケットフィルタを更新するために使用される、
付記３１に記載の方法。
（付記３３）
　前記エンドポイント設定は、前記基地局間ゲートウェイ装置のトランスポートレイヤ・アドレスを含む、
付記３１又は３２に記載の方法。
（付記３４）
　前記エンドポイント設定は、ダンリンクフォワーディングのためのエンドポイント設定及びアップリンクフォワーディングのためのエンドポイント設定を含む、
付記３１～３３のいずれか１項に記載の方法。
（付記３５）
　前記少なくとも１つのプロセッサは、前記基地局間ゲートウェイ装置によって前記リレー処理が行われる場合に、前記第２の基地局から前記第１の基地局へのハンドオーバ要求承認メッセージを運ぶ第２の転送メッセージに、前記基地局間ゲートウェイ装置と前記第１の基地局の間で前記データパケットを転送するための第２のトランスポートベアラに関する前記基地局間ゲートウェイ装置のエンドポイント設定を含めることをさらに備える、
付記２５～３４のいずれか１項に記載の方法。
　この出願は、２０１５年３月２０日に出願された日本出願特願２０１５－０５８１５５を基礎とする優先権を主張し、その開示の全てをここに取り込む。
１　(H)eNB
２　(H)eNB
３　X2 Gateway（X2 GW）
４　Evolved Packet Core（EPC）
５　Mobility Management Entity（MME）
１８０４　プロセッサ
１８０５　メモリ
１９０２　プロセッサ
１９０３　メモリ

Claims (21)

  1. 　基地局装置であって、
    　メモリと、
    　前記メモリに結合された少なくとも１つのプロセッサと、
    を備え、
    　前記少なくとも１つのプロセッサは、第１の情報要素を基地局間ゲートウェイに送信するよう構成され、
    　前記第１の情報要素は、無線端末宛て又は前記無線端末からのデータパケットを前記基地局間ゲートウェイが前記基地局装置と他の基地局の間で中継するリレー処理が必要とされる否かを明示的または暗示的に示す、
    基地局装置。
  2. 　前記第１の情報要素は、前記基地局装置と前記他の基地局の間のダイレクトパスの利用可否を明示的に示す、
    請求項１に記載の基地局装置。
  3. 　前記少なくとも１つのプロセッサは、前記基地局装置から前記他の基地局または前記他の基地局から前記基地局装置への前記無線端末のハンドオーバの際に、前記第１の情報要素を送信するよう構成されている、
    請求項１又は２に記載の基地局装置。
  4. 　前記少なくとも１つのプロセッサは、前記他の基地局へのハンドオーバ要求メッセージ又はハンドオーバ要求承認メッセージを運ぶために前記基地局間ゲートウェイに送信される転送メッセージに前記第１の情報要素を含めるよう構成されている、
    請求項３に記載の基地局装置。
  5. 　前記第１の情報要素は、前記リレー処理が必要とされることを暗示的に示すために、前記転送メッセージによって運ばれる前記ハンドオーバ要求メッセージ又は前記ハンドオーバ要求承認メッセージに包含されている第２の情報要素と同じ内容を示す、
    請求項４に記載の基地局装置。
  6. 　前記少なくとも１つのプロセッサは、前記転送メッセージによって運ばれる前記ハンドオーバ要求メッセージ又は前記ハンドオーバ要求承認メッセージに包含されている第２の情報要素と同じ内容の第３の情報要素を前記転送メッセージに含めるよう構成されている、
    請求項４に記載の基地局装置。
  7. 　前記第２の情報要素は、前記データパケットのフォワーディングの要否を示す情報要素、前記無線端末のために設定されたベアラの識別子を示す情報要素、および前記ベアラのQuality of Service（QoS）パラメータを示す情報要素のうち少なくとも１つを含む、
    請求項５又は６に記載の基地局装置。
  8. 　前記少なくとも１つのプロセッサは、前記転送メッセージによって運ばれる基地局間シグナリングメッセージの種別を示す情報要素を前記転送メッセージに含めるよう構成されている、
    請求項４～７のいずれか１項に記載の基地局装置。
  9. 　前記少なくとも１つのプロセッサは、前記データパケットの送信又は受信のために、前記基地局間ゲートウェイによる前記リレー処理を利用するか否かを決定するよう構成され、
    　前記リレー処理が利用されない場合、前記データパケットは、前記基地局装置と前記他の基地局の間のダイレクトパスを用いてフォワーディングされる、
    請求項１～８のいずれか１項に記載の基地局装置。
  10. 　前記少なくとも１つのプロセッサは、前記第１の情報要素を生成する際に、前記基地局間ゲートウェイが前記リレー処理の能力を有するか否かを考慮するよう構成されている、
    請求項１～９のいずれか１項に記載の基地局装置。
  11. 　前記少なくとも１つのプロセッサは、前記リレー処理の能力を示す第４の情報要素を前記基地局間ゲートウェイから受信するよう構成されている、
    請求項１～１０のいずれか１項に記載の基地局装置。
  12. 　前記少なくとも１つのプロセッサは、前記基地局装置を前記基地局間ゲートウェイに登録する手順において、前記第４の情報要素を受信するよう構成されている、
    請求項１１に記載の基地局装置。
  13. 　前記少なくとも１つのプロセッサは、前記第１の情報要素を生成する際に、前記基地局装置と前記他の基地局の間のダイレクトパスの状態を考慮するよう構成されている、
    請求項１～１２のいずれか１項に記載の基地局装置。
  14. 　前記ダイレクトパスの前記状態は、前記ダイレクトパスの利用可否、前記ダイレクトパスのスループット、及び前記ダイレクトパスの負荷のうち少なくとも１つを含む、
    請求項１３に記載の基地局装置。
  15. 　前記少なくとも１つのプロセッサは、前記第１の情報要素を生成する際に、前記基地局装置のトランスポートレイヤ・アドレスを前記他の基地局から隠す必要があるか否かを考慮するよう構成されている、
    請求項１～１４のいずれか１項に記載の基地局装置。
  16. 　前記少なくとも１つのプロセッサは、前記第１の情報要素を生成する際に、前記他の基地局の種別を考慮するよう構成されている、
    請求項１～１５のいずれか１項に記載の基地局装置。
  17. 　基地局間ゲートウェイ装置であって、
    　メモリと、
    　前記メモリに結合された少なくとも１つのプロセッサと、
    を備え、
    　前記少なくとも１つのプロセッサは、第１の情報要素を第１の基地局及び第２の基地局の少なくとも一方から受信するよう構成され、
    　前記第１の情報要素は、無線端末宛て又は前記無線端末からのデータパケットを前記基地局間ゲートウェイ装置によって前記第１の基地局と前記第２の基地局の間で中継するリレー処理が必要とされる否かを明示的または暗示的に示す、
    基地局間ゲートウェイ装置。
  18. 　基地局装置により行われる方法であって、
    　第１の情報要素を基地局間ゲートウェイに送信することを備え、
    　前記第１の情報要素は、無線端末宛て又は前記無線端末からのデータパケットを前記基地局間ゲートウェイが前記基地局装置と他の基地局の間で中継するリレー処理が必要とされる否かを明示的または暗示的に示す、
    方法。
  19. 　基地局間ゲートウェイ装置によって行われる方法であって、
    　第１の情報要素を第１の基地局及び第２の基地局の少なくとも一方から受信することを備え、
    　前記第１の情報要素は、無線端末宛て又は前記無線端末からのデータパケットを前記基地局間ゲートウェイ装置によって前記第１の基地局と前記第２の基地局の間で中継するリレー処理が必要とされる否かを明示的または暗示的に示す、
    方法。
  20. 　基地局装置により行われる方法をコンピュータに行わせるためのプログラムを格納した非一時的なコンピュータ可読媒体であって、
    　前記方法は、第１の情報要素を基地局間ゲートウェイに送信することを備え、
    　前記第１の情報要素は、無線端末宛て又は前記無線端末からのデータパケットを前記基地局間ゲートウェイが前記基地局装置と他の基地局の間で中継するリレー処理が必要とされる否かを明示的または暗示的に示す、
    非一時的なコンピュータ可読媒体。
  21. 　基地局間ゲートウェイ装置によって行われる方法をコンピュータに行わせるためのプログラムを格納した非一時的なコンピュータ可読媒体であって、
    　前記方法は、第１の情報要素を第１の基地局及び第２の基地局の少なくとも一方から受信することを備え、
    　前記第１の情報要素は、無線端末宛て又は前記無線端末からのデータパケットを前記基地局間ゲートウェイ装置によって前記第１の基地局と前記第２の基地局の間で中継するリレー処理が必要とされる否かを明示的または暗示的に示す、
    非一時的なコンピュータ可読媒体。
PCT/JP2015/006366 2015-03-20 2015-12-22 基地局装置および基地局間ゲートウェイ装置 WO2016151653A1 (ja)

Priority Applications (4)

Application Number Priority Date Filing Date Title
US15/555,671 US10772027B2 (en) 2015-03-20 2015-12-22 Base station apparatus and inter-base-station gateway apparatus
EP15886210.2A EP3273748B1 (en) 2015-03-20 2015-12-22 Base station apparatus, and inter-base-station gateway apparatus
CN201580077837.9A CN107409439B (zh) 2015-03-20 2015-12-22 基站设备和基站间网关设备
JP2017507123A JP6384591B2 (ja) 2015-03-20 2015-12-22 基地局装置および基地局間ゲートウェイ装置

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2015058155 2015-03-20
JP2015-058155 2015-03-20

Publications (1)

Publication Number Publication Date
WO2016151653A1 true WO2016151653A1 (ja) 2016-09-29

Family

ID=56978274

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2015/006366 WO2016151653A1 (ja) 2015-03-20 2015-12-22 基地局装置および基地局間ゲートウェイ装置

Country Status (5)

Country Link
US (1) US10772027B2 (ja)
EP (1) EP3273748B1 (ja)
JP (1) JP6384591B2 (ja)
CN (1) CN107409439B (ja)
WO (1) WO2016151653A1 (ja)

Cited By (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2017108467A (ja) * 2013-04-05 2017-06-15 日本電気株式会社 Ｘ２ゲートウェイ装置および方法
US10728844B2 (en) 2016-09-29 2020-07-28 British Telecommunications Public Limited Company Cellular telecommunications network
US11039388B2 (en) 2019-07-29 2021-06-15 British Telecommunications Public Limited Company Cellular telecommunications network
US11470548B2 (en) 2016-09-29 2022-10-11 British Telecommunications Public Limited Company Cellular telecommunications network
US11558854B2 (en) 2017-07-18 2023-01-17 British Telecommunications Public Limited Company Cellular telecommunications network
US11683752B2 (en) 2020-06-18 2023-06-20 British Telecommunications Public Limited Company Cellular telecommunications network
US11812320B2 (en) 2019-07-29 2023-11-07 British Telecommunications Public Limited Company Initiation of transfer of user equipment to base station according to visual data

Families Citing this family (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11178558B2 (en) * 2015-05-22 2021-11-16 Parallel Wireless, Inc. Wireless backhaul resiliency
EP3363259A1 (en) * 2015-10-15 2018-08-22 Telefonaktiebolaget LM Ericsson (publ) Methods, apparatuses and computer programs for providing an x2 interface between a network unit and a remote network in wireless communication systems
MX2019011295A (es) 2017-03-24 2019-12-05 Ericsson Telefon Ab L M Un primer nodo de red de radio (rnn), un segundo rnn y metodos en los mismos para establecer una interfaz de comunicaciones entre el primer rnn y el segundo rnn.
WO2018206629A1 (en) * 2017-05-09 2018-11-15 Telefonaktiebolaget Lm Ericsson (Publ) Amf eligibility for relay and reroute
CN111132376B (zh) * 2018-11-01 2021-08-27 大唐移动通信设备有限公司 一种双连接endc链路的管理方法和装置
JP2024503577A (ja) * 2021-01-15 2024-01-26 ホアウェイ・テクノロジーズ・カンパニー・リミテッド Ａｃｌ構成方法及び装置
CN116017417A (zh) * 2021-10-21 2023-04-25 大唐移动通信设备有限公司 一种数据前转方法及装置

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2012227974A (ja) * 2012-08-22 2012-11-15 Ntt Docomo Inc 移動通信方法及び無線基地局
JP2013150204A (ja) * 2012-01-20 2013-08-01 Panasonic Corp ゲートウェイ装置及び通信方法

Family Cites Families (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2152035B1 (en) * 2008-08-06 2016-12-21 Alcatel Lucent Method for automatically configuring addresses and/or security data between ENBS of an LTE access network, and associated MME and ENB
WO2010054903A1 (en) * 2008-11-17 2010-05-20 Nokia Siemens Networks Oy Networking capability determination mechanism
CN101754116A (zh) * 2008-12-03 2010-06-23 中兴通讯股份有限公司 在lte系统下基站x2接口传输地址获取的方法和装置
EP2205021A1 (en) 2008-12-31 2010-07-07 Alcatel, Lucent Data forwarding method and apparatus thereof
WO2011142624A2 (en) 2010-05-14 2011-11-17 Lg Electronics Inc. The method and apparatus for performing handover procedure in wireless communication system
CN102076039B (zh) 2011-01-17 2013-01-23 大唐移动通信设备有限公司 一种传输切换信息的方法及装置
US20140328246A1 (en) * 2011-09-30 2014-11-06 Nokia Solutions And Networks Oy Mobile Relay Support in Relay-Enhanced Access Networks
US8982841B2 (en) * 2011-10-27 2015-03-17 Spidercloud Wireless, Inc. Long term evolution architecture and mobility
KR20130064468A (ko) 2011-12-08 2013-06-18 한국전자통신연구원 펨토 기지국 게이트웨이 및 펨토 기지국 게이트웨이의 동작 방법
CN103220815B (zh) 2012-01-18 2019-02-15 中兴通讯股份有限公司 一种基站间接口连接建立方法及装置
CN103326770B (zh) * 2012-03-19 2016-04-06 上海贝尔股份有限公司 支持移动中继站和固定中继站共存的方法和相应的设备
CN104704905B (zh) * 2012-10-18 2018-11-06 诺基亚通信公司 智能承载建立配置控制
JP2016519522A (ja) 2013-04-16 2016-06-30 ゼットティーイー コーポレーションＺｔｅ Ｃｏｒｐｏｒａｔｉｏｎ トランスポート層アドレスの通知方法及びシステム
EP3029993A4 (en) 2013-07-31 2017-01-11 NEC Corporation Communication apparatus, core network node, mobile communication system, communication method, and storage medium
CN104469976A (zh) 2013-09-25 2015-03-25 中兴通讯股份有限公司 一种建立连接的方法、装置及系统
US10104582B2 (en) * 2014-08-11 2018-10-16 Cisco Technology, Inc. Call preservation on handover

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2013150204A (ja) * 2012-01-20 2013-08-01 Panasonic Corp ゲートウェイ装置及び通信方法
JP2012227974A (ja) * 2012-08-22 2012-11-15 Ntt Docomo Inc 移動通信方法及び無線基地局

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
ERICSSON: "TAI-Assisted Intra-HeNB-GW X2 Handover", 3GPP TSG-RAN WG3#74 R3-113003, 14 November 2011 (2011-11-14), XP050566192 *
NTT DOCOMO,INC.: "Handover message routing for relays", 3GPP TSG-RAN WG3 AD-HOC R3-101934, 29 June 2010 (2010-06-29), XP050453845 *
ZTE: "The enhancement for peer discovery", 3GPP TSG-RAN WG3 MEETING #83 R3-140040, 10 February 2014 (2014-02-10), XP050738485 *

Cited By (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2017108467A (ja) * 2013-04-05 2017-06-15 日本電気株式会社 Ｘ２ゲートウェイ装置および方法
US11272410B2 (en) 2013-04-05 2022-03-08 Nec Corporation Communication system
US10728844B2 (en) 2016-09-29 2020-07-28 British Telecommunications Public Limited Company Cellular telecommunications network
US11470548B2 (en) 2016-09-29 2022-10-11 British Telecommunications Public Limited Company Cellular telecommunications network
US11558854B2 (en) 2017-07-18 2023-01-17 British Telecommunications Public Limited Company Cellular telecommunications network
US11039388B2 (en) 2019-07-29 2021-06-15 British Telecommunications Public Limited Company Cellular telecommunications network
US11812320B2 (en) 2019-07-29 2023-11-07 British Telecommunications Public Limited Company Initiation of transfer of user equipment to base station according to visual data
US11683752B2 (en) 2020-06-18 2023-06-20 British Telecommunications Public Limited Company Cellular telecommunications network

Also Published As

Publication number Publication date
CN107409439A (zh) 2017-11-28
US10772027B2 (en) 2020-09-08
EP3273748A1 (en) 2018-01-24
EP3273748B1 (en) 2020-06-17
US20180049098A1 (en) 2018-02-15
JPWO2016151653A1 (ja) 2017-12-28
EP3273748A4 (en) 2018-10-03
JP6384591B2 (ja) 2018-09-05
CN107409439B (zh) 2021-08-03

Similar Documents

Publication Publication Date Title
JP6384591B2 (ja) 基地局装置および基地局間ゲートウェイ装置
JP6597686B2 (ja) Ｘ２ゲートウェイ装置および方法
EP2286615B1 (en) Data forwarding during handover in a self-backhauled cell
JP5704370B2 (ja) 基地局間のハンドオーバーを管理するための方法及び装置
US20230239754A1 (en) Enhanced XN Handover Messages for IAB Inter-CU Migration
JP6239742B2 (ja) 通信システム、ユーザ端末、プロセッサ、及びセルラ基地局
WO2011020432A1 (zh) 基于移动中继的切换方法和移动无线中继系统
JP2013526087A (ja) ローカルｉｐネットワークに接続するｕｅのハンドオーバ方法、ハンドオーバシステム、装置
US8874118B2 (en) Base station, communication method and wireless communication system
EP3202212B1 (en) Local breakout in small cell architecture
US9198108B2 (en) Mobile communication system, relay-station mobility management apparatus, relay-station mobility control method, and computer-readable medium
EP4335157A1 (en) First node, second node and methods performed thereby for handling migration of a node
WO2012155656A1 (zh) 一种宿主基站、中继节点设备及增强路径转换的方法
JP6732993B2 (ja) データ交換方法および装置
US20240205795A1 (en) Methods for enabling inter-donor routing in iab networks
JP6509950B2 (ja) データ交換方法および装置
KR20160142700A (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: 15886210

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 15555671

Country of ref document: US

ENP Entry into the national phase

Ref document number: 2017507123

Country of ref document: JP

Kind code of ref document: A

NENP Non-entry into the national phase

Ref country code: DE