(19)
(11)EP 3 273 748 B1

(12)EUROPEAN PATENT SPECIFICATION

(45)Mention of the grant of the patent:
17.06.2020 Bulletin 2020/25

(21)Application number: 15886210.2

(22)Date of filing:  22.12.2015
(51)Int. Cl.: 
H04W 36/00  (2009.01)
H04W 88/16  (2009.01)
H04W 92/20  (2009.01)
H04W 36/04  (2009.01)
H04W 76/00  (2018.01)
(86)International application number:
PCT/JP2015/006366
(87)International publication number:
WO 2016/151653 (29.09.2016 Gazette  2016/39)

(54)

BASE STATION APPARATUS, AND INTER-BASE-STATION GATEWAY APPARATUS

BASISSTATIONSVORRICHTUNG UND ZWISCHENBASISSTATION-GATEWAY-VORRICHTUNG

APPAREIL DE STATION DE BASE ET APPAREIL DE PASSERELLE ENTRE LES STATIONS DE BASE


(84)Designated Contracting States:
AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

(30)Priority: 20.03.2015 JP 2015058155

(43)Date of publication of application:
24.01.2018 Bulletin 2018/04

(73)Proprietor: NEC Corporation
Tokyo 108-8001 (JP)

(72)Inventor:
  • UEDA, Yoshio
    Tokyo 108-8001 (JP)

(74)Representative: MacDougall, Alan John Shaw et al
Mathys & Squire LLP The Shard 32 London Bridge Street
London SE1 9SG
London SE1 9SG (GB)


(56)References cited: : 
WO-A1-2014/169687
WO-A1-2015/015773
JP-A- 2013 150 204
WO-A1-2014/177004
JP-A- 2012 227 974
  
  • ERICSSON: 'TAI-Assisted Intra-HeNB-GW X2 Handover' 3GPP TSG-RAN WG3#74 R3-113003 14 November 2011, XP050566192
  • NTT DOCOMO,INC.: 'Handover message routing for relays' 3GPP TSG-RAN WG3 AD-HOC R3-101934 29 June 2010, XP050453845
  • ZTE: 'The enhancement for peer discovery' 3GPP TSG-RAN WG3 MEETING #83 R3-140040 10 February 2014, XP050738485
  
Note: Within nine months from the publication of the mention of the grant of the European patent, any person may give notice to the European Patent Office of opposition to the European patent granted. Notice of opposition shall be filed in a written reasoned statement. It shall not be deemed to have been filed until the opposition fee has been paid. (Art. 99(1) European Patent Convention).


Description

Technical Field



[0001] The present disclosure relates to radio communication and in particular to forwarding of user data packets between base stations.

Background Art



[0002] The 3rd Generation Partnership Project (3GPP) Release 12 specifies an X2 Gateway (X2 GW) (see, for example, Non-patent Literature 1). As described in Non-patent Literature 1, the X2 GW establishes a signaling (i.e., Stream Control Transmission Protocol (SCTP)) connection with each of a plurality of (H)eNBs and these (H)eNBs exchange signaling messages (i.e., X2AP messages) through the X2 GW. The (H)eNB means an eNodeB or a Home eNodeB. The X2 GW does not terminate X2AP procedures except for the X2AP Message Transfer procedure. That is, X2AP contexts only exist in the two peer (H)eNBs, which is similar to the case where no X2 GW is present. The X2AP contexts define an "X2AP association" between peer (H)eNBs that spans over two SCTP connections.

[0003] The X2AP Message Transfer procedure is performed by the X2 GW as follows. That is, when a source (H)eNB sends an X2AP message (except the X2AP MESSAGE TRANSFER message) to a target (H)eNB through the X2 GW, the source (H)eNB encapsulates the X2AP message in an X2AP MESSAGE TRANSFER message, adds routing information (i.e., RNL Header), then sends the X2AP MESSAGE TRANSFER message to the X2 GW. The routing information (i.e., RNL Header) includes both a target (H)eNB ID and a source (H)eNB ID. The X2 GW routes the X2AP MESSAGE TRANSFER message based on the target (H)eNB ID.

[0004] The X2 interface is an inter-base-station interface in the 3GPP Release 8 and subsequent releases. 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). The X2-C interface is used, for example, for preparation of a handover between base stations (i.e., X2 handover), control of Dual connectivity (e.g., establishment, modification, and release of a UE context; and management of an X2 user plane tunnel), and various settings and maintenance related to adjacent eNBs. The X2-C interface uses the X2AP protocol and uses the SCTP and the Internet Protocol (IP) to transfer X2AP signaling messages. The X2AP protocol is referred to as a Radio Network Layer (RNL) protocol and the SCTP/IP, which is used to transfer the X2AP protocol, is referred to as a Transport Network Layer (TNL) protocol.

[0005] Meanwhile, the X2-U interface is used, for example, to forward user data packets from a source (H)eNB to a target (H)eNB during a handover, and transfer user data packets (i.e., Packet Data Convergence Protocol (PDCP) PDUs) between a Master eNB (MeNB) and a Secondary eNB (SeNB) in Dual connectivity. The X2-U interface uses the GPRS Tunnelling Protocol User Plane (GTP-U) protocol and uses the User Datagram Protocol (UDP) and the IP to transfer GTP Protocol Data Units (GTP-PDUs). The GTP-U protocol is an RNL protocol for the user plane (U-plane) and the UDP/IP, which is used to transfer the GTP-U PDU, is a TNL protocol for the U-plane. The GTP-U and the TNL UDP/IP provide a tunnel mechanism. That is, the GTP-U encapsulates a user data packet (e.g., IP packet) with a GTP-U header, and the encapsulated user data packet (i.e., GTP-PDU) is transferred on the TNL UDP/IP layer. The user data packet is also referred to as a T-PDU. Further, although the user data packet (i.e., T-PDU) encapsulated with the GTP-U header is one of the GTP-PDUs, it is also referred to as a G-PDU to distinguish it from other GTP-PDUs containing a signaling message between GTP nodes. Further, each of the G-PDU and the GTP-U PDU (i.e., signaling message) is also referred to as a GTP-U message.

[0006] Although the 3GPP Release 12 specifies a transfer of X2AP signaling messages (X2-C) between two peer (H)eNBs through an X2 GW as described in Non-patent Literature 1, it does not specify a transfer of user data packets (X2-U). For this matter, Patent Literatures 1 and 2 disclose a transfer of user data packets between two peer (H)eNBs through an X2 GW.

[0007] Patent Literature 1 discloses that an HeNB-GW, which relays S1-MME signaling messages and user data packets between a core network (i.e., Evolved Packet Core (EPC)) and an (H)eNB, also supports the X2-C interface and X2-U interface. The HeNB-GW disclosed in Patent Literature 1 operates to relay a GTP-PDU encapsulating a user data packet (i.e., G-PDU) between two peer (H)eNBs. However, Patent Literature 1 does not describe details of the G-PDU relay operation performed by the HeNB-GW.

[0008] Patent Literature 2 discloses that a G-PDU is transferred between two (H)eNBs through an X2-GW. The X2-GW disclosed in Patent Literature 2 assigns a Tunnel Endpoint Identifier (TEID) to each of the two (H)eNBs during the preparation of a handover, and operates to change the TEID indicated in the GTP-U header of a received GTP-U PDU from one (H)eNB and send the GTP-U PDU, in which the TEID has been changed, to the other (H)eNB.
WO2015/015773 describes a method and system for notifying a transport layer address associated with an X2 gateway, by a home eNB to another base station wishing to establish an X2 connection with the X2 gateway.

[0009] WO2014/169687 describes a communication apparatus concerned with the handover of a wireless terminal from a first apparatus to a second apparatus in a communication system including a core network node. The communication apparatus receives control information from the core network node when performing the handover, wherein the control information relates to the transmission path of data to be transferred from the first apparatus to the second apparatus.

[0010] WO2014/177004 describes a communications network in which a method of connection is utilized by a source base station, whereby the source base station transmits a request for an address to be transmitted through an s1 interface and initiates an X2 interface establishment flow for a target base station according to the response message received.

Citation List


Patent Literature



[0011] 

Patent Literature 1: Japanese Unexamined Patent Application Publication No. 2012-227974

Patent Literature 2: Japanese Unexamined Patent Application Publication No. 2013-150204
WO2015/015773
WO2014/169687
WO2014/177004


Non Patent Literature



[0012] Non-patent Literature 1: 3GPP TS 36.300 V12.4.0 (2014-12), "3rd Generation Partnership Project; Technical Specification Group Radio Access Network; Evolved Universal Terrestrial Radio Access (E-UTRA) and Evolved Universal Terrestrial Radio Access Network (E-UTRAN); Overall description; Stage 2 (Release 12)", December 2014

Summary of Invention


Technical Problem



[0013] The invention is set out in the appended set of claims.

[0014] In the case where an inter-base-station gateway (e.g., X2-GW) is used, it may be inappropriate if a transfer of user data packets (e.g., PDCP PDUs) between base stations (e.g., DL data forwarding at the time of an inter-base-station handover (e.g., X2 handover) and transferring between an MeNB and an SeNB in Dual connectivity) is always performed through the X2-GW. For example, when the maximum or effective throughput (i.e., transmission rate) of the inter-base-station direct path (e.g., X2 interface) is sufficiently large, it may be inappropriate to always use the relay operation by the inter-base-station gateway in view of increase in delay. On the other hand, when the load of the inter-base-station direct path is high or when the inter-base-station direct path cannot be used for some reason, it may be preferable if the relay operation by the inter-base-station gateway can be selected. Further, it may be preferable if a TNL address (e.g., IP address) of one of two base stations (e.g., (H)eNBs) can be concealed from the other when a handover is performed between these two base stations. This concealment of the TNL address may be required only for a specific base station or a specific type of base stations.

[0015] In view of above, it may be preferable if a base station (e.g., (H)eNB) or an inter-base-station gateway (e.g., X2-GW) can select whether a relay operation by the inter-base-station gateway (e.g., the X2-GW) should be performed when user data packets are transferred between base stations. However, Patent Literatures 1 and 2 do not disclose any control as to whether the relay operation by the X2 GW should be performed. Note that the relay operation of user data packets by the inter-base-station gateway (e.g., X2-GW) means a transfer of user data packets between base stations (e.g., (H)eNBs) through the X2-GW.

[0016] One of the objects to be attained by embodiments disclosed herein is to provide an apparatus, a method, and a program that contribute to enabling a base station (e.g., (H)eNB) or an inter-base-station gateway (e.g., X2-GW) to select whether a relay operation by the inter-base-station gateway (e.g., X2-GW) should be performed. It should be noted that the above-described object is merely one of the objects intended to be attained by the embodiments disclosed herein. Other objects or problems and novel features will be made apparent from the following description and the accompanying drawings.

Solution to Problem



[0017] In a first aspect, a 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 an inter-base-station gateway. The first information element indicates whether a relay operation is necessary. The relay operation is an operation in which the inter-base-station gateway relays a data packet destined for or sent from a radio terminal between the base station apparatus and another base station. The at least one processor is configured to, when generating the first information element, consider whether it is necessary to conceal a transport-layer address of the base station apparatus from the other base station.

[0018] In a second aspect, a method performed by a base station apparatus includes sending a first information element to an inter-base-station gateway. The first information element indicates whether a relay operation is necessary. The relay operation is an operation in which the inter-base-station gateway relays a data packet destined for or sent from a radio terminal between the base station apparatus and another base station. The method comprises, when generating the first information element, considering whether it is necessary to conceal a transport-layer address of the base station apparatus from the other base station.

[0019] In a third aspect, a program includes a set of instructions (software codes) that, when loaded into a computer, causes the computer to perform a method according to the above-described second aspect.

Advantageous Effects of Invention



[0020] According to the above-described aspect, it is possible to provide an apparatus, a method, and a program that contribute to enabling a base station or an inter-base-station gateway to select whether a relay operation by the inter-base-station gateway should be performed.

Brief Description of Drawings



[0021] 

Fig. 1 shows a configuration example of a radio communication system according to some embodiments;

Fig. 2 is a sequence diagram showing an example of a procedure for giving a notice of necessity for a relay operation according to a first embodiment;

Fig. 3 is a flowchart showing an example of an operation of a source base station according to the first embodiment;

Fig. 4 is a flowchart showing an example of an operation of an inter-base-station gateway according to the first embodiment;

Fig. 5 is a flowchart showing an example of an operation of a target base station according to the first embodiment;

Fig. 6 is a flowchart showing an example of an operation of a target base station according to the first embodiment;

Fig. 7 is a table showing an example of combinations of operations of a source base station and an inter-base-station gateway with their activation conditions according to the first embodiment;

Fig. 8 is a table showing an example of combinations of operations of a source base station and an inter-base-station gateway with their activation conditions according to the first embodiment;

Fig. 9 is a table showing an example of combinations of operations of a target base station and an inter-base-station gateway with their activation conditions according to the first embodiment;

Fig. 10 is a table showing an example of combinations of operations of a target base station and an inter-base-station gateway with their activation conditions according to the first embodiment;

Fig. 11 is a sequence diagram showing an example of a notifying procedure of a relay capability according to the first embodiment;

Fig. 12 is a sequence diagram showing an example of a notifying procedure of a relay capability according to the first embodiment;

Fig. 13A is a sequence diagram showing an example of a procedure for an inter-base-station handover according to the first embodiment;

Fig. 13B is a sequence diagram showing an example of a procedure for an inter-base-station handover according to the first embodiment;

Fig. 14 shows an example of a modification to an X2AP Message Transfer message;

Fig. 15A shows another example of a modification to an X2AP Message Transfer message;

Fig. 15B shows another example of a modification to an X2AP Message Transfer message;

Fig. 16 is a sequence diagram showing an example of a procedure for notifying a target base station of an address of an inter-base-station gateway according to a third embodiment;

Fig. 17A shows an example of a modification to an X2 TNL Configuration Info message;

Fig. 17B shows an example of a modification to an X2 TNL Configuration Info message;

Fig. 18 is a block diagram showing a configuration example of a base station according to some embodiments; and

Fig. 19 is a block diagram showing a configuration example of an inter-base-station gateway according to some embodiments.


Description of Embodiments



[0022] Specific embodiments are described hereinafter in detail with reference to the drawings. The same symbols are assigned to the same or corresponding elements throughout the drawings, and duplicated explanations are omitted as necessary.

[0023] Embodiments described below are explained mainly using specific examples with regard to a Long Term Evolution (LTE)/LTE-Advanced system. However, these embodiments are not limited to being applied to the LTE/LTE-Advanced system and may also be applied to other mobile communication networks or systems such as a 3GPP Universal Mobile Telecommunications System (UMTS), a 3GPP2 CDMA2000 system, a Global System for Mobile communications (GSM (Registered Trademark))/General packet radio service (GPRS) system, and a WiMAX system.

First Embodiment



[0024] Fig. 1 shows a configuration example of a radio communication system according to some embodiments including this embodiment. In the example shown in Fig. 1, the radio communication system includes an (H)eNB 1, an (H)eNB 2, an X2 GW 3, and an EPC 4. The X2 GW 3 is configured to establish an SCTP connection with each of the (H)eNBs 1 and 2 to relay signaling messages (i.e., X2AP messages) 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 to relay user data packets between the (H)eNBs 1 and 2. Each of the (H)eNBs 1 and 2 includes an X2-C interface with the X2 GW 3 and an S1 interface with the EPC 4. Note that an HeNB-GW may be used between the EPC 4 and at least one of the (H)eNBs 1 and 2. This HeNB-GW relays S1-MME signaling and user data packets (S1-U) between the EPC 4 and at least one of the (H)eNBs 1 and 2. This embodiment focuses mainly on a handover of an UE from the (H)eNB 1 to the (H)eNB 2. Accordingly, the (H)eNB 1 and the (H)eNB 2 may be referred to as the source (H)eNB and the target (H)eNB, respectively.

[0025] In this embodiment, at least one of the (H)eNBs 1 and 2 is configured to send a first Information Element (IE) to the X2 GW 3. This first information element explicitly or implicitly indicates whether a relay operation by the X2 GW 3 is necessary for forwarding user data packets of a radio terminal (User Equipment (UE)). In some implementations, when the UE is handed over from the (H)eNB 1 to the (H)eNB 2, at least one of the source (H)eNB 1 and the target (H)eNB 2 sends this first information element. In some implementations, the (H)eNB 1, the (H)eNB 2 and the UE support Dual Connectivity, and at least one of the (H)eNBs 1 and 2 sends the first information element when a bearer for the UE is established.

[0026] The relay operation by the X2 GW 3 includes transferring user data packets (i.e., T-PDUs) through the X2-U interface (i.e., GTP-U tunnel) 101 between the (H)eNB 1 and the X2 GW 3 and the X2-U interface (i.e., GTP-U tunnel) 102 between the (H)eNB 2 and the X2 GW 3. This relay operation, in which the X2 GW 3 relays user data packets, may include transferring user data packets each encapsulated with a GTP-U header (i.e., G-PDUs). The relay operation by the X2 GW 3 can also be referred to as an X2-U relay, a U-plane relay, a GTP-U relay, or a user plane concentration.

[0027] That is, the first information element is an explicit or implicit indication indicating necessity for a U-plane relay by the X2 GW 3. In some implementations, this indication is flag information that is set to different values according to whether the relay operation by the X2 GW 3 is necessary. Alternatively, in some implementations, this indication is an explicit or implicit relay request that is transmitted when the relay operation by the X2 GW 3 is necessary and is not transmitted when the relay operation is unnecessary. Alternatively, in some implementations, this indication is a combination of a plurality of information elements.

[0028] For example, as shown in the below specific examples, this indication may include an information element (e.g., Direct Path Availability IE or Direct Path Unavailability IE) that indicates availability of a direct path 100 between the (H)eNBs 1 and 2. For example, the availability of the direct path 100 may be set in advance in the (H)eNBs 1 and 2 by an operator or an Operations, Administration and Maintenance (OAM). Alternatively, the availability of the direct path 100 may be dynamically determined by the (H)eNBs 1 and 2. For example, when the direct path 100 is available but its throughput is low or when the load of the direct path 100 is high, the (H)eNBs 1 and 2 may determine that the direct path 100 cannot be used. This indication may be, for example, a combination of an information element indicating the availability of the direct path 100 and an information element (e.g., DL Forwarding IE or Uplink (UL) GTP Tunnel Endpoint IE) indicating necessity of data forwarding.

[0029] Fig. 2 is a sequence diagram showing an example (Process 200) of a procedure for notifying the X2 GW 3 of necessity for the relay operation. In Block 201, the (H)eNB 1 or 2 sends an X2AP Message Transfer message to the X2 GW 3. This X2AP Message Transfer message carries an X2AP Handover Request message from the source (H)eNB 1 to the target (H)eNB 2, or an X2AP Handover Request Acknowledge message from the target (H)eNB 2 to the source (H)eNB 1. Furthermore, this X2AP Message Transfer message includes an indication explicitly or implicitly indicating necessity for the X2-U relay operation by the X2 GW 3. The X2 GW 3 can recognize whether it should prepare for the X2-U relay based on this indication.

[0030] Further, in the example shown in Fig. 2, the X2 GW 3 receives the indication indicating necessity of the X2-U relay operation together with the X2AP Message Transfer message carrying the Handover Request message or the Handover Request Acknowledge message. Therefore, the X2 GW 3 can easily prepare for a GTP-U tunnel necessary for the X2-U relay by referring to this X2AP Message Transfer message.

[0031] As can be understood from the above description, in this embodiment, at least one of the (H)eNBs 1 and 2 is configured to send to the X2 GW 3 the indication explicitly or implicitly indicating whether the U-plane (X2-U) relay by the X2 GW 3 is necessary. Therefore, the X2 GW 3 can recognize whether it should perform the U-plane (X2-U) relay based on this indication.

[0032] Further, in this embodiment, at least one of the (H)eNBs 1 and 2 may be configured to, when transferring of user data packets of a radio terminal (UE) from the (H)eNB 1 to the (H)eNB 2 is needed, determine whether to use the relay operation by the X2 GW 3 for forwarding these user data packets of the UE. In other words, the (H)eNBs 1 and 2 may be configured to select which of the relay path (101 and 102) through the X2 GW 3 and the direct path (100) will be used for forwarding user data packets from the (H)eNB 1 to the (H)eNB 2. When they do not use the relay operation by the X2 GW 3, the source (H)eNB 1 may forward user data packets to the target (H)eNB 2 via the direct path between the (H)eNBs 1 and 2 (i.e., X2-U interface (GTP-U tunnel) 100).

[0033] In some implementations, when the source (H)eNB 1 determines initiation of a handover of a UE to the (H)eNB 2, it may also determine whether to use the U-plane (X2-U) relay operation by the X2 GW 3. In some implementations, when the target (H)eNB 2 receives a handover request from the source (H)eNB 1, it may determine whether to use the U-plane (X2-U) relay operation by the X2 GW 3. In some implementations, when the (H)eNB 1 receives a request for establishing a bearer for an UE that supports Dual Connectivity (e.g., S1AP: Initial Context Setup Request) from the EPC 4, it may determine whether to use the U-plane (X2-U) relay operation by the X2 GW 3. Alternatively, determination of whether the U-plane (X2-U) relay operation by the X2 GW 3 is to be used or not is performed in advance per pair of (H)eNBs.

[0034] In some implementations, one or both of the (H)eNBs 1 and 2 may select whether to use the U-plane (X2-U) relay operation by the X2 GW 3 according to the state of the direct path 100 (e.g., availability of the direct path 100, throughput of the direct path 100, or load of the direct path 100). In other words, one or both of the (H)eNBs 1 and 2 may consider the state of the direct path 100 when determining whether to use (or request) the U-plane (X2-U) relay operation by the X2 GW 3.

[0035] For example, when the maximum or effective throughput (or transmission rate) of the inter-base-station direct path 100 is larger than throughput of the path 101 (or 102) between the (H)eNB 1 (or 2) and the X2 GW 3, it may not be appropriate to use the relay operation by the inter-base-station gateway in view of increase in delay. Therefore, when the throughput of the inter-base-station direct path 100 is sufficiently larger than that of the path 101 between the (H)eNB 1 and the X2 GW 3 or larger than that of the path 102, the (H)eNB 1 or 2 may determine not to use the U-plane (X2-U) relay operation by the X2 GW 3. In this way, it is possible to prevent increase in delay that would otherwise be caused by the unnecessary U-plane relay.

[0036] In some implementations, the (H)eNB 1 may use the U-plane (X2-U) relay operation by the X2 GW 3 when it is necessary to conceal the TNL address (e.g., IP address) of the (H)eNB 1 from the (H)eNB 2, and may perform forwarding through the direct path 100 when it is unnecessary to conceal its TNL address. Similarly, the (H)eNB 2 may select whether to use the U-plane (X2-U) relay operation by the X2 GW 3 based on necessity for concealing the TNL address (e.g., IP address) of the (H)eNB 2 from the (H)eNB 1. In other words, one or both of the (H)eNBs 1 and 2 may consider the necessity for concealing the TNL address when determining whether to use (or request) the U-plane (X2-U) relay operation by the X2 GW 3.

[0037] For example, the source (H)eNB 1 may need to conceal its TNL address (e.g., IP address) from the target (H)eNB 2 when performing a handover. Conversely, the target (H)eNB 2 may need to conceal its TNL address (e.g., IP address) from the source (H)eNB 1. The TNL address may be required to be concealed only from a specific base station or a specific type of base stations.

[0038] HeNBs are installed in premises or buildings of end-users, rather than in buildings (sites) administered by telecommunications carriers. Accordingly, there is a risk that HeNBs may be altered by malicious users and, thus it may be hard to ensure sufficient security for HeNBs. Therefore, providing the X2-U TNL address of a macro eNB to an HeNB at the time of a handover could lead to a security risk such as a Denial of Service (DoS) attack to the macro eNB. For example, when the source (H)eNB 1 is a macro eNB and the target (H)eNB 2 is an HeNB, the source (H)eNB 1 may determine to use the U-plane (X2-U) relay operation by the X2 GW 3. In contrast to this, when the source (H)eNB 1 is a macro eNB and the target (H)eNB 2 is also a macro eNB, the source (H)eNB 1 may determine not to use the U-plane (X2-U) relay operation by the X2 GW 3. In this way, it is possible to prevent a security risk that would otherwise arise if an HeNB is informed of an X2-U TNL address of a macro eNB.

[0039] In some implementations, one or both of the (H)eNBs 1 and 2 may select whether to use the U-plane (X2-U) relay operation by the X2 GW 3 based on the U-plane Relay Capability of the X2 GW 3. In other words, one or both of the (H)eNBs 1 and 2 may consider the presence or absence of the U-plane capability of the X2 GW 3 when determining whether to use (or request) the U-plane (X2-U) relay operation by the X2 GW 3.

[0040] As can be understood from the above description, in this embodiment, at least one of the (H)eNBs 1 and 2 may be configured to determine whether to use the U-plane (X2-U) relay operation by the X2 GW 3 when a UE is handed over from the (H)eNB 1 to the (H)eNB 2. In this way, at least one of the (H)eNBs 1 and 2 can select whether to use the U-plane (X2-U) relay operation by the X2 GW 3.

[0041] Next, a specific example of operations of the source (H)eNB 1, the X2 GW 3, and the target (H)eNB 2 are described. Fig. 3 is a flowchart showing an example (Process 300) of an operation of the source (H)eNB 1. In Block 301, the (H)eNB 1 determines initiation of a handover of a UE to the target (H)eNB 2. In Block 302, the (H)eNB 1 determines whether the U-plane (X2-U) relay operation by the X2 GW 3 is necessary at the time of the handover. When the U-plane (X2-U) relay operation is necessary (YES at Block 302), the source (H)eNB 1 incorporates an explicit or implicit relay request into a transfer message (i.e., X2AP Message Transfer message) that carries a handover request (i.e., Handover Request message) (Block 303). In Block 304, the source (H)eNB 1 sends to the X2 GW 3 the transfer message, which carries the handover request and contains the relay request. On the other hand, when the U-plane (X2-U) relay operation is unnecessary (NO at Block 302), the source (H)eNB 1 sends to the X2 GW 3 the transfer message, which carries the handover request, but does not contain the relay request (Block 305).

[0042] Fig. 4 is a flowchart showing an example (Process 400) of an operation of the X2 GW 3. In Block 401, the X2 GW 3 receives a transfer message (i.e., X2AP Message Transfer message) carrying a handover request (i.e., Handover Request message) from the source (H)eNB 1. In Block 402, the X2 GW 3 checks whether the received transfer message includes a relay request or not. When the transfer message includes the relay request (YES at Block 402), the X2 GW 3 adds in the transfer message, which carries the handover request, an indication indicating that the U-plane (X2-U) relay by the X2 GW 3 is to be performed and then sends this transfer message to the target (H)eNB 2.

[0043] In some implementations, this indication indicating that the U-plane (X2-U) relay by the X2 GW 3 is to be performed may be simple flag information indicating whether the U-plane (X2-U) relay is to be performed or not. Additionally or alternatively, as shown in Block 403 in Fig. 4, this indication indicating that the U-plane (X2-U) relay by the X2 GW 3 is to be performed may include an endpoint configuration of the X2 GW 3 side regarding an X2 transport bearer (i.e., GTP-U bearer). The endpoint configuration includes a TNL address (e.g., IP address) and a TEID. This endpoint configuration may include only a DL GTP tunnel endpoint configuration regarding an X2 transport bearer used for forwarding downlink (DL) user data packets, or may further include a UL GTP tunnel endpoint configuration regarding an X2 transport bearer used for forwarding uplink (UL) user data packets.

[0044] The above-described operation in which the X2 GW 3 sends the endpoint configuration of the X2 GW 3 side regarding the X2 transport bearer(s) (i.e., GTP-U bearer(s)) to the target (H)eNB 2 together with the transfer message carrying the handover request provides, for example, the following advantages. In some implementations, the target (H)eNB 2 may have Access Control List (ACL) functionality. When the ACL functionality is applied to the target (H)eNB 2, the target (H)eNB 2 accepts a connection from a sending node only when the source address of the sending node is already known in the target (H)eNB 2. Accordingly, if the target (H)eNB 2 does not know the X2-U TNL address of the X2 GW 3, the target (H)eNB 2 may discard TNL UDP/IP packets that carries G-PDUs and are transmitted from the X2 GW 3 because of its ACL functionality. To prevent this, the X2 GW 3 preferably notifies the target (H)eNB 2 of the endpoint configuration of the X2 GW 3 side regarding the X2 transport bearer (i.e., GTP-U bearer) in advance, though the X2 GW 3 is on the upstream side of the data forwarding. In this way, the target (H)eNB 2 can update its ACL so as to accept a connection from the X2-U TNL address of the X2 GW 3. The ACL can also be referred to as a packet filter or a firewall configuration.

[0045] Referring back to Fig. 4, when the transfer message does not include the relay request (No at Block 402), the X2 GW 3 sends the transfer message received from the source (H)eNB 1 to the target (H)eNB 2 without adding any information thereto (Block 404). That is, the transfer message sent in Block 404 does not include the indication indicating that the U-plane (X2-U) relay by the X2 GW 3 is to be performed.

[0046] Fig. 5 is a flowchart showing an example (Process 500) of an operation of the target (H)eNB 2. In Block 501, the target (H)eNB 2 receives a transfer message (i.e., X2AP Message Transfer message) carrying a handover request (i.e., Handover Request message) from the X2 GW 3. In Block 502, the target (H)eNB 2 checks whether the received transfer message includes an endpoint configuration of the X2 GW 3 side regarding an X2 transport bearer (i.e., GTP-U bearer). When the transfer message includes the endpoint configuration of the X2 GW 3 side (YES at Block 503), the target (H)eNB 2 updates its ACL so as to accept a connection from the X2-U TNL address of the X2 GW 3.

[0047] In Block 504, the target (H)eNB 2 sends a transfer message (i.e., X2AP Message Transfer message) carrying a handover request acknowledgement (i.e., Handover Request Acknowledge message) to the X2 GW 3. The handover request acknowledgement (i.e., Handover Request Acknowledge message) includes a DL GTP tunnel endpoint configuration of the target (H)eNB 2. Further, when UL data forwarding is performed in addition to the DL data forwarding, the handover request acknowledgement (i.e., Handover Request Acknowledge message) includes a UL GTP tunnel endpoint configuration of the target (H)eNB 2. The DL GTP tunnel endpoint configuration of the target (H)eNB 2 includes a TNL address and a TEID regarding a GTP-U tunnel for receiving DL user data packets forwarded from the source (H)eNB 1. The UL GTP tunnel endpoint configuration of the target (H)eNB 2 includes a TNL address and a TEID regarding a GTP-U tunnel for receiving a UL user data packet forwarded from the source (H)eNB 1.

[0048] Note that the transfer message carrying the handover request acknowledge message sent in Block 504 may include an additional information element indicating a GTP tunnel endpoint configuration of the target (H)eNB 2 which is the same as that described in the handover request acknowledge message. Although this message structure is redundant, it has an advantage that the X2 GW 3 does not have to decode or refer to the handover request acknowledge message.

[0049] The operations of the source (H)eNB 1, the X2 GW 3, and the target (H)eNB 2 shown in Figs. 3 to 5 are merely examples and may be modified as appropriate. For example, the message used to send the relay request in Fig. 3 may be an X2AP message other than the X2AP Message Transfer message. For example, the relay request may be embedded in the Handover Request message that is carried by the X2AP Message Transfer message. With regard to Fig. 4, the message used to send the endpoint configuration of the X2 GW 3 may be an X2AP message other than the X2AP Message Transfer message. For example, the endpoint configuration of the X2 GW 3 may be embedded in the Handover Request message that is carried by the X2AP Message Transfer message.

[0050] Figs. 3 to 5 show examples in which the source (H)eNB 1 determines whether to use (or request) the U-plane (X2-U) relay by the X2 GW 3 at the time of a handover. Similarly, when receiving the handover request from the source (H)eNB 1 through the X2 GW 3, the target (H)eNB 2 may determine whether to use (or request) the U-plane (X2-U) relay by the X2 GW 3. That is, the target (H)eNB 2 may determine necessity of the U-plane (X2-U) relay by the X2 GW 3 independently from the determination of necessity of the U-plane (X2-U) relay made by the source (H)eNB 1.

[0051] Fig. 6 is a flowchart showing an example (Process 600) of an operation including a determination by the target (H)eNB 2 of the necessity of the U-plane (X2-U) relay. In Block 601, the target (H)eNB 2 receives a transfer message (i.e., X2AP Message Transfer message) carrying a handover request (i.e., Handover Request message) from the X2 GW 3. In Block 602, the target (H)eNB 2 determines whether the U-plane (X2-U) relay operation by the X2 GW 3 is necessary. When the U-plane (X2-U) relay operation is necessary (YES at Block 602), the target (H)eNB 2 incorporates an explicit or implicit relay request into a transfer message (i.e., X2AP Message Transfer message) carrying a handover request acknowledgement (i.e., Handover Request Acknowledge message) (Block 603). In Block 604, the target (H)eNB 2 sends to the X2 GW 3 the transfer message, which carries the handover request acknowledgement and includes the relay request. On the other hand, when the U-plane (X2-U) relay operation is unnecessary (NO at Block 602), the target (H)eNB 2 sends to the X2 GW 3 the transfer message, which carries the handover request acknowledgement, but does not include the relay request (Block 605).

[0052] The operation in the X2 GW 3 when it receives from the target (H)eNB 2 the transfer message which carries the handover request acknowledgement and includes the relay request may be similar to that shown in Fig. 4. However, as described above with reference to Fig. 5, the handover request acknowledgement (i.e., Handover Request Acknowledge message) includes the GTP tunnel endpoint configuration of the target (H)eNB 2. In some implementations, in the process corresponding to Block 403, the X2 GW 3 may rewrite the GTP tunnel endpoint configuration of the target (H)eNB 2 embedded in the Handover Request Acknowledge message with a GTP tunnel endpoint configuration of the X2 GW 3.

[0053] Alternatively, in the process corresponding to Block 403, the X2 GW 3 may not make any modification to the GTP tunnel endpoint configuration of the target (H)eNB 2 embedded in the Handover Request Acknowledge message and may incorporate, into the X2AP Message Transfer message, an additional information element indicating the endpoint configuration of the X2 GW 3. In this case, the source (H)eNB 1 may update its X2 transport bearer context in accordance with the additional information element and ignore the GTP tunnel endpoint configuration of the target (H)eNB 2 described in the Handover Request Acknowledge message.

[0054] Note that when the U-plane (X2-U) relay by the X2 GW 3 is performed to conceal the TNL address of the target (H)eNB 2 from the source (H)eNB 1, the X2 GW 3 preferably modifies the GTP tunnel endpoint configuration of the target (H)eNB 2 described in the Handover Request Acknowledge message. In this way, it is possible to certainly conceal the TNL address of the target (H)eNB 2 from the source (H)eNB 1.

[0055] Figs. 3 to 6 show specific examples of the operations of the (H)eNBs 1 and 2 and the X2 GW 3 in a handover. However, as can be understood from the above description, the specific examples of the operations of the (H)eNBs 1 and 2 and the X2 GW 3 described with reference to Figs. 3 to 6 may be applied to the case when a bearer related to a UE supporting Dual Connectivity is established. For example, the (H)eNB 1 may determine whether to use the U-plane (X2-U) relay operation by the X2 GW 3 in response to receiving from the EPC 4 a request for establishing a bearer related to a UE supporting Dual Connectivity. Then, the (H)eNB 1 may incorporate the explicit or implicit relay request into a transfer message (i.e., X2AP Message Transfer message) carrying an X2AP message for establishing a UE context for Dual Connectivity.

[0056] Next, specific examples of operations of the source (H)eNB 1 and the X2 GW 3, and their activation conditions are described with reference to Figs. 7 and 8. Fig. 7 is a table showing an example of combinations of operations of the source (H)eNB 1 and the X2 GW 3 with their activation conditions. In the example shown in Fig. 7, the source (H)eNB 1 considers the availability of the direct path 100 (Direct Path Availability) and the relay capability of the X2 GW 3 (U-plane Relay Capability) to determine whether to use (or request) the U-plane (X2-U) relay.

[0057] In the Case 1 shown in Fig. 7, the direct path 100 is available and the X2 GW 3 has the relay capability. In the Case 2 shown in Fig. 7, the direct path 100 is available and the X2 GW 3 does not have the relay capability. In the Cases 1 and 2, since the direct path 100 is available, the source (H)eNB 1 does not incorporate the explicit or implicit relay request to the X2 GW 3 into the X2AP Message Transfer message (carrying the Handover Request message). Therefore, the X2 GW 3 does not perform the U-plane (X2-U) relay for DL data forwarding.

[0058] In the Case 3 shown in Fig. 7, the direct path 100 is unavailable and the X2 GW 3 has the relay capability. In the Case 3, since the X2 GW 3 has the relay capability, though the direct path 100 is unavailable, the source (H)eNB 1 incorporates the explicit or implicit relay request to the X2 GW 3 into the X2AP Message Transfer message (carrying the Handover Request message). Therefore, the X2 GW 3 performs the U-plane (X2-U) relay for DL data forwarding.

[0059] In the Case 4 shown in Fig. 7, the direct path 100 is unavailable and the X2 GW 3 does not have the relay capability. In the Case 4, since X2-U data forwarding cannot be performed, the source (H)eNB 1 does not incorporate the explicit or implicit relay request to the X2 GW 3 into the X2AP Message Transfer message (carrying the Handover Request message). Therefore, the X2 GW 3 does not perform the U-plane (X2-U) relay for DL data forwarding.

[0060] Note that as already described, in some implementations, the implicit relay request (or the relay indication) to the X2 GW 3 may include a combination of a plurality of information elements. For example, as shown in Fig. 8, the implicit relay request (or the relay indication) to the X2 GW 3 may be a combination of the Direct Path Unavailability IE and the DL Forwarding IE. The Direct Path Unavailability IE shown in Fig. 8 is set when the direct path 100 is unavailable. The Direct Path Unavailability IE may be one-bit flag information. The DL Forwarding IE shown in Fig. 8 may be the DL Forwarding IE contained in the X2AP: Handover Request message specified in the current 3GPP specifications, or may be an information element newly added in the X2AP Message Transfer message.

[0061] The Cases 1 to 4 shown in Fig. 8 correspond to the Cases 1 to 4 shown in Fig. 7, respectively. That is, in the Case 1 shown in Fig. 8, the direct path 100 is available and the X2 GW 3 has the relay capability. In the Case 2 shown in Fig. 8, the direct path 100 is available and the X2 GW 3 does not have the relay capability. In the Cases 1 and 2, since the direct path 100 is available, the source (H)eNB 1 does not set the Direct Path Unavailability IE. However, the source (H)eNB 1 sets the DL Forwarding IE to inform the target (H)eNB 2 that DL forwarding (through the direct path 100) is to be performed.

[0062] In the Case 3 shown in Fig. 8, the direct path 100 is unavailable and the X2 GW 3 has the relay capability. In the Case 3, since the direct path 100 is unavailable, the source (H)eNB 1 sets the Direct Path Unavailability IE. Further, in the Case 3, since the X2 GW 3 has the relay capability, though the direct path 100 is unavailable, the source (H)eNB 1 determines that it can perform DL forwarding through the X2 GW 3 and, accordingly, sets the DL Forwarding IE to inform the target (H)eNB 2 that DL forwarding (through the X2 GW 3) is to be performed.

[0063] In the Case 4 shown in Fig. 8, the direct path 100 is unavailable and the X2 GW 3 does not have the relay capability. Therefore, in the Case 4, the source (H)eNB 1 sets the Direct Path Unavailability IE but does not set the DL Forwarding IE.

[0064] In the example shown in Fig. 8, the X2 GW 3 refers to the Direct Path Unavailability IE and the DL Forwarding IE, and performs the U-Plane (X2-U) relay for DL data forwarding when both of the two information elements are set. Therefore, similarly to the example shown in Fig. 7, the U-Plane (X2-U) relay for DL data forwarding is performed only in the Case 3 in Fig. 8 and is not performed in the Cases 1, 2 and 4 in Fig. 8.

[0065] Next, specific examples of operations of the target (H)eNB 2 and the X2 GW 3, and their activation conditions are described with reference to Figs. 9 and 10. Fig. 9 is a table showing an example of combinations of operations of the target (H)eNB 2 and the X2 GW 3 with their activation conditions. The example related to the target (H)eNB 2 shown in Fig. 9 corresponds to the example related to the source (H)eNB 1 shown in Fig. 7. Therefore, the U-Plane (X2-U) relay for UL data forwarding is performed only in the Case 3 in Fig. 9 and is not performed in the Cases 1, 2 and 4 in Fig. 9.

[0066] In the example shown in Fig. 10, the implicit relay request (or the relay indication) to the X2 GW 3 from the target (H)eNB 2 is a combination of the Direct Path Unavailability IE and the UL GTP Tunnel Endpoint IE. The UL GTP Tunnel Endpoint IE shown in Fig. 10 may be the UL GTP Tunnel Endpoint IE contained in an X2AP: Handover Request Acknowledge message specified in the current 3GPP specifications, or may be an information element newly added in the X2AP Message Transfer message.

[0067] The example related to the target (H)eNB 2 shown in Fig. 10 corresponds to the example related to the source (H)eNB 1 shown in Fig. 8, except for the difference between the DL Forwarding IE and the UL GTP Tunnel Endpoint IE. That is, in the example shown in Fig. 10, the X2 GW 3 refers to the Direct Path Unavailability IE and the UL GTP Tunnel Endpoint IE, and performs the U-Plane (X2-U) relay for UL data forwarding when both of the two information elements are set. Therefore, the U-Plane (X2-U) relay for UL data forwarding is performed only in the Case 3 in Fig. 10 and is not performed in the Cases 1, 2 and 4 in Fig. 10.

[0068] Figs. 7 to 10 show specific examples of the operations of the (H)eNBs 1 and 2 and the X2 GW 3 in a handover. However, as can be understood from the above description, the specific examples of the operations of the (H)eNBs 1 and 2 and the X2 GW 3 described with reference to Figs. 7 to 10 may be applied when a bearer related to a UE supporting Dual Connectivity is established.

[0069] In the examples described with reference to Figs. 7 to 10, the (H)eNBs 1 and 2 consider the presence or absence of the relay capability of the X2 GW 3 when determining whether to use (or request) the U-plane (X2-U) relay. The presence or absence of the relay capability of the X2 GW 3 may be set in advance in the (H)eNBs 1 and 2 by an operator or an operations, administration and maintenance (OAM). Alternatively, the X2 GW 3 may notify the (H)eNBs 1 and 2 of the presence or absence of its relay capability. Specifically, the X2 GW 3 may send to the (H)eNBs 1 and 2 a signaling message including an information element (IE) indicating the presence or absence of its relay capability. In some implementations, as shown in Figs. 11 and 12, the X2 GW 3 may inform the (H)eNBs 1 and 2 of its relay capability during a procedure for registering the (H)eNBs 1 and 2 in the X2 GW 3.

[0070] Fig. 11 is a sequence diagram showing an example (Process 1100) of a procedure in which the X2 GW 3 notifies the (H)eNBs 1 and 2 of the presence or absence of its relay capability. In Block 1101, the (H)eNBs 1 (2) sends a registration request to the X2 GW 3 ((H)eNB registration). The X2 GW 3 stores mapping of the identifier of the sender (H)eNB (i.e., Global eNB ID) included in the registration request and the TNL address (e.g., IP address) of the sender (H)eNB used for the transmission of the registration request. Then, in Block 1102, the X2 GW 3 sends a response to the registration request ((H)eNB registration response). This response includes an information element indicating the presence or absence of the relay capability of the X2 GW 3 (U-plane Relay Capability). The (H)eNB 1 (2) receives the response sent in Block 1102 and thereby recognizes the presence or absence of the U-plane (X2-U) relay capability of the X2 GW 3.

[0071] Fig. 12 is a sequence diagram showing another example (Process 1200) of a procedure in which the X2 GW 3 notifies the (H)eNBs 1 and 2 of the presence or absence of the relay capability. In the 3GPP Release 12, an X2AP Message Transfer message is used to register an (H)eNB in an X2 GW. Similarly to the 3GPP Release 12, Fig. 12 shows an example in which an X2AP Message Transfer message is used. That is, in Block 1201, the (H)eNB 1 (2), which requests its registration, sends an X2AP Message Transfer message. This X2AP Message Transfer message contains a Source (H)eNB ID within its RNL Header IE, but it does not contain a Target (H)eNB ID within the RNL Header IE and also does not contain any X2AP Message. In Block 1202, the X2 GW 3 sends a modified X2AP Message Transfer message. This modified X2AP Message Transfer message contains a Target (H)eNB ID within its RNL Header IE and also contains a newly-defined U-plane Relay Capability IE, but it does not contain a Source (H)eNB ID within the RNL Header IE and also does not contain any X2AP Message. The (H)eNBs 1 (2) receives the X2AP Message Transfer message sent in Block 1202 and thereby recognizes the presence or absence of the U-plane (X2-U) relay capability of the X2 GW 3.

[0072] Figs. 13A and 13B are sequence diagrams showing an example (Process 1300) of an X2 handover procedure according to this embodiment. The procedure shown in Figs. 13A and 13B is similar to an ordinary X2 handover procedure through an X2 GW, except that user data packets is forwarded from the source (H)eNB 1 to the target (H)eNB 2 through the X2 GW 3 (Blocks 1307 and 1308). That is, in Block 1301, the source (H)eNB 1 sends to the X2 GW 3 an X2AP Message Transfer message carrying a Handover Request message. As already described, this X2AP Message Transfer message may contain an information element explicitly or implicitly indicating the necessity of the U-plane (X2-U) relay. In Block 1302, the X2 GW 3 transfers the X2AP Message Transfer message carrying the Handover Request message to the target (H)eNB 2. As already described, the X2 GW 3 may update an information element in the X2AP Message Transfer message transferred in Block 1302 (or add an information element in the X2AP Message Transfer message) according to whether to perform the U-plane (X2-U) relay.

[0073] In Block 1303, the target (H)eNB 2 sends to the X2 GW 3 an X2AP Message Transfer message carrying a Handover Request Acknowledge message. As already described, this X2AP Message Transfer message may include an information element explicitly or implicitly indicating the necessity of the U-plane (X2-U) relay. In Block 1304, the X2 GW 3 transfers the X2AP Message Transfer message carrying the Handover Request Acknowledge message to the source (H)eNB 1. As already described, the X2 GW 3 may update an information element in the X2AP Message Transfer message transferred in Block 1304 (or add an information element in the X2AP Message Transfer message) according to whether to perform the U-plane (X2-U) relay.

[0074] In response to reception of the Handover Request Acknowledge message, the source (H)eNB 1 sends a Handover Command to an UE (not shown). In Block 1305, the source (H)eNB 1 sends to the X2 GW 3 an X2AP Message Transfer message carrying an SN Status Transfer message. The SN Status Transfer message indicates a Sequence Number (SN) of an uplink/downlink Packet Data Convergence Protocol (PDCP) PDU of which the delivery to the UE has not been completed. In Block 1306, the X2 GW 3 transfers the X2AP Message Transfer message carrying the SN Status Transfer message to the target (H)eNB 2.

[0075] In Blocks 1307 and 1308, the source (H)eNB 1 forwards the uplink/downlink user data packet(s), of which the delivery to the UE has not been completed, to the target (H)eNB 2 through the X2 GW 3. That is, in Block 1307, the source (H)eNB 1 sends to the X2 GW 3, through a GTP-U tunnel between the source (H)eNB 1 and the X2 GW 3, a G-PDU(s) which encapsulates the uplink/downlink user data packet(s). In Block 1308, the X2 GW 3 transfers the G-PDU(s) received from the source (H)eNB 1 to the target (H)eNB 2 through a GTP-U tunnel between the target (H)eNB 2 and the X2 GW 3.

[0076] In the data forwarding in Blocks 1307 and 1308, the X2 GW 3 updates the source TNL address (i.e., TNL address of the source (H)eNB 1) assigned to the G-PDU(s) received from the source (H)eNB 1 by the TNL address of the X2 GW 3 and also updates the source TEID (i.e., TEID of the source (H)eNB 1) by the TEID of the X2 GW 3. Further, the X2 GW 3 updates the target TNL address (i.e., TNL address of the X2 GW 3) assigned to the G-PDU(s) received from the source (H)eNB 1 by the TNL address of the (H)eNB 2 and also updates the target TEID (i.e., TEID of the X2 GW 3) by the TEID of the target (H)eNB 2.

[0077] In Block 1309, the target (H)eNB 2 receives a Handover Confirm message from the UE. As a result of this, the UE can transmit UL user data packets to the target (H)eNB 2 and receive DL user data packets from the target (H)eNB 2.

[0078] In Block 1310, the target (H)eNB 2 informs the EPC 4 of a change of the serving cell of the UE and sends an S1AP: Path Switch Request message to the EPC 4 (i.e., Mobility Management Entity (MME) 5) to request a change of the route of the Evolved Packet System (EPS) bearer. The MME 5 performs signaling with a Serving Gateway (S-GW) (not shown) and thereby modifies the route of the EPS bearer (i.e., route of the S1 bearer). In Block 1311, the MME 5 sends an S1AP: Path Switch Request Acknowledge message to the target (H)eNB 2. In Block 1312, in response to reception of the Path Switch Request Acknowledge message, the target (H)eNB 2 sends to the X2 GW 3 an X2AP Message Transfer message carrying a UE Context Release message. In Block 1313, the X2 GW 3 transfers the X2AP Message Transfer message carrying the UE Context Release message to the source (H)eNB 1. In response to reception of the UE Context Release message, the source (H)eNB 1 releases the radio resources allocated to the UE.

[0079] Note that in response to transmission of the UE Context Release message (Block 1312), the target (H)eNB 2 may release its GTP-U tunnel configuration for the data forwarding. In response to reception of the X2AP Message Transfer message carrying the UE Context Release message (Block 1312), the X2 GW 3 may release its GTP-U tunnel configuration for the data forwarding. In response to reception of the UE Context Release message (Block 1313), the source (H)eNB 1 may release its GTP-U tunnel configuration for the data forwarding.

[0080] Next, specific examples of a modification to the X2AP Message Transfer message are described with reference to Fig. 14 and Figs. 15A and 15B. Fig. 14 shows an example of a modification to the X2AP Message Transfer message. The "U-Plane Relay Capability" IE is used by the X2 GW 3 to inform the (H)eNBs 1 and 2 of the presence or absence of its U-plane (X2-U) relay capability. The "Direct Path Unavailability" IE is used by the (H)eNBs 1 and 2 to inform the X2 GW 3 of the availability of the direct path 100. The "E-RABs To Be Setup List" IE is used by the X2 GW 3 to inform the (H)eNBs 1 and 2 of the Endpoint configuration of the X2 GW 3.

[0081] The "E-RABs To Be Setup List" IE includes the "E-RABs To Be Setup Item" IE. The "E-RABs To Be Setup Item" IE includes the "E-RAB ID" IE, the "UL GTP Tunnel Endpoint" IE, and the "DL GTP Tunnel Endpoint" IE. The "UL GTP Tunnel Endpoint" IE indicates the Endpoint configuration (i.e., TNL address and TEID) of the X2 GW 3 regarding the X2 transport bearer for UL data (i.e., UL PDUs) forwarding. The "DL GTP Tunnel Endpoint" IE indicates the Endpoint configuration (i.e., TNL address and TEID) of the X2 GW 3 regarding the X2 transport bearer for DL data (i.e., DL PDUs) forwarding.

[0082] Figs. 15A and 15B show another example of a modification to the X2AP Message Transfer message. As shown in Fig. 15A, the X2AP Message Transfer message is extended to include the "Message Type of X2AP Message" IE. The "Message Type of X2AP Message" IE indicates the type of the X2AP message carried by the X2AP Message Transfer message. In this way, the X2 GW 3 can operate so as to refer to or decode only a necessary X2AP message(s). Specifically, the X2 GW 3 may refer to or decode the "X2AP message" IE within the X2AP Message Transfer message, only when the "Message Type of X2AP Message" IE indicates the Handover Request message or the Handover Request Acknowledge message.

[0083] Additionally or alternatively, as shown in Fig. 15B, the X2AP Message Transfer message is extended to include the "DL Forwarding" IE. The "DL Forwarding" IE is used by the source (H)eNB 1 when the "X2AP message" IE carries a Handover Request message. This "DL Forwarding" IE indicates the same content as the "DL Forwarding" IE that is contained in the Handover Request message embedded within the "X2AP message" IE. In this way, the X2 GW 3 does not have to decode or refer to the Handover Request message in the "X2AP message" IE to check the "DL Forwarding" IE.

[0084] According to this, the X2AP Message Transfer message may be extended to include the "E-RAB Level QoS Parameters" IE as shown in Fig. 15B. The "E-RAB Level QoS Parameters" IE is used by the source (H)eNB 1 when the "X2AP message" IE carries a Handover Request message. The "E-RAB Level QoS Parameters" IE indicates the same content as the "E-RAB Level QoS Parameters" IE that is contained in the Handover Request message embedded within the "X2AP message" IE.

[0085] Further, according to this, the "E-RAB ID" IE shown in Fig. 15B may be used by the source (H)eNB 1 when the "X2AP message" IE carries a Handover Request message. In this case, the "E-RAB ID" IE indicates the same content as the "E-RAB ID" IE that is contained in the Handover Request message embedded within the "X2AP message" IE. Further, the "E-RAB ID" IE shown in Fig. 15B may be used by the target (H)eNB 2 when the "X2AP message" IE carries a Handover Request Acknowledge message. In this case, the "E-RAB ID" IE indicates the same content as the "E-RAB ID" IE that is contained in the Handover Request Acknowledge message embedded within the "X2AP message" IE.

[0086] Still further, according to this, the "DL GTP Tunnel Endpoint" IE and the "UL GTP Tunnel Endpoint" IE shown in Fig. 15B may be used by the target (H)eNB 2 when the "X2AP message" IE carries a Handover Request Acknowledge message. In this case, the "DL GTP Tunnel Endpoint" IE and the "UL GTP Tunnel Endpoint" IE indicate the same contents as the "DL GTP Tunnel Endpoint" IE and the "UL GTP Tunnel Endpoint" IE that are contained in the Handover Request Acknowledge message embedded within the "X2AP message" IE.

[0087] As described above, by incorporating, into the X2AP Message Transfer message, one or more information elements that the X2 GW 3 needs to refer to for the U-plane (X2-U) relay out of the information elements contained in the Handover Request message and the Handover Request Acknowledge message, the following advantage is obtained. That is, the X2 GW 3 only needs to transfer the X2AP Message IE in a transparent manner and does not need to refer to or decode the X2AP Message IE. If the X2 GW 3 always has to refer to or decode the X2AP Message IE, it may considerably consume the processing power of the X2 GW 3, or a protocol error may occur due to the difference in the X2AP protocol version between the X2 GW 3 and the (H)eNBs. The X2 GW 3 can prevent the occurrence of such problems by transferring the X2AP Message IE in a transparent manner.

[0088] Note that as shown in Figs. 15A and 15B, when an information element(s) having the same contents as the information elements contained in the Handover Request message or the Handover Request Acknowledge message is added in the X2AP Message Transfer message, this added information element(s) (e.g., at least one of "DL Forwarding" IE, "E-RAB Level QoS Parameters" IE, "E-RAB ID" IE, "DL GTP Tunnel Endpoint" IE, and "UL GTP Tunnel Endpoint" IE) may be used as the implicit relay request (or relay indication). That is, the X2 GW 3 may detect the presence or absence of the relay request from the (H)eNB 1 or 2 according to whether the X2AP Message Transfer message includes the added information element(s). In this case, the X2AP Message Transfer message does not necessarily have to include the "Direct Path Unavailability" IE (or other explicit or implicit relay requests).

Second Embodiment



[0089] This embodiment provides a specific example of a procedure for informing the target (H)eNB 2 of the X2-U TNL address (e.g., IP address) of the X2 GW 3. In the first embodiment, an example in which the X2-U TNL address of the X2 GW 3 is set in the target (H)eNB 2 by the OAM and an example in which the X2-U TNL address of the X2 GW 3 is sent from the X2 GW 3 to the target (H)eNB 2 by using an X2AP Message Transfer message are shown. As an alternative of these examples, an improved Enhanced TNL Address Discovery procedure may be used.

[0090] The Enhanced TNL Address Discovery procedure is specified in Section 4.6.6.1 of Non-patent Literature 1. In the Enhanced TNL Address Discovery procedure, an (H)eNB incorporates the TNL address of the X2 GW, to which this (H)eNB is connected, into the S1AP: eNB CONFIGURATION TRANSFER message and sends the eNB CONFIGURATION TRANSFER message including the TNL address of the X2 GW to an MME. The MME acquires the target eNB ID and the TNL address of the X2 GW contained in the received eNB CONFIGURATION TRANSFER message and transfers the TNL address of the X2 GW to the target eNB ID by using the S1AP: MME CONFIGURATION TRANSFER message. In this way, the two (H)eNBs can share the TNL address of the X2 GW and use indirect X2 through the X2 GW.

[0091] However, it should be noted that the TNL address of the X2 GW that is transferred through the existing Enhanced TNL Address Discovery procedure is the TNL address for transferring X2AP signaling messages via the SCTP connection (i.e., X2-C TNL address). In this embodiment, the existing Enhanced TNL Address Discovery procedure is modified to transfer the TNL address (i.e., X2-U TNL address) of the X2 GW used for transferring TNL UDP/IP packets carrying G-PDUs.

[0092] Fig. 16 is a sequence diagram showing an example (Process 1600) of an Enhanced TNL Address Discovery procedure according to this embodiment. The procedure shown in Fig. 16 is similar to the existing Enhanced TNL Address Discovery procedure, except that the X2 GW U-plane address (i.e., X2-U TNL address) is sent. That is, in Block 1601, the source (H)eNB 1 sends an S1AP: eNB CONFIGURATION TRANSFER message to the MME 5. This eNB CONFIGURATION TRANSFER message includes the U-plane address of the X2 GW 3 (i.e., X2-U TNL address). In Block 1602, the MME 5 sends an S1AP: MME CONFIGURATION TRANSFER message to the target (H)eNB 2. This MME CONFIGURATION TRANSFER message includes the U-plane address (i.e., X2-U TNL address) of the X2 GW 3 received from the source (H)eNB 1.

[0093] In Block 1603, the target (H)eNB 2 adds the received U-plane address (i.e., X2-U TNL address) of the X2 GW 3 in its ACL. In Block 1604, the target (H)eNB 2 sends an S1AP: eNB CONFIGURATION TRANSFER message to the MME 5. This eNB CONFIGURATION TRANSFER message is a response for the source (H)eNB 1. In Block 1605, the MME 5 sends an S1AP: MME CONFIGURATION TRANSFER to the source (H)eNB 1. This MME CONFIGURATION TRANSFER message includes the information element that is received from the target (H)eNB 2 by the eNB CONFIGURATION TRANSFER message (e.g., the U-plane address of the X2 GW 3 that the target (H)eNB 2 has received from the source (H)eNB 1).

[0094] Figs. 17A and 17B show a specific example of a modification to the "X2 TNL Configuration Info" IE specified in Section 9.2.3.29 of 3GPP TS 36.413 V12.4.0. The "X2 TNL Configuration Info" IE is included in the S1AP: eNB CONFIGURATION TRANSFER message and the S1AP: MME CONFIGURATION TRANSFER message. As shown in Fig. 17B, the "X2 TNL Configuration Info" IE may be extended so as to include the "Transport Layer Address" IE indicating the TNL address regarding the indirect X2 U-plane endpoint (i.e., X2-U TNL address of the X2 GW 3).

[0095] Lastly, configuration examples of the (H)eNBs 1 and 2 and the X2 GW 3 according to the above embodiments are described. Fig. 18 is Block diagram showing a configuration example of the (H)eNB 1. The (H)eNB 2 may have a configuration similar to that shown in Fig. 18. As shown in Fig. 18, the (H)eNB 1 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 a plurality of transceivers. The RF transceiver 1801 is connected to an antenna 1802 and the processor 1804. The RF transceiver 1801 receives modulated symbol data (or OFDM symbol data) from the processor 1804, generates a transmission RF signal, and supplies the generated transmission RF signal to the antenna 1802. Further, the RF transceiver 1801 generates a baseband reception signal based on a reception RF signal received by the antenna 1802 and supplies this signal to the processor 1804.

[0096] The network interface 1803 is used to communicate with a network node (e.g., MME and S/P-GW). The network interface 1803 may include, for example, a network interface card (NIC) conforming to the IEEE 802.3 series.

[0097] The processor 1804 performs data-plane processing (including digital baseband signal processing and control-plane processing for radio communication. For example, in the case of LTE or LTE-Advanced, the digital baseband signal processing performed by the processor 1804 may include signal processing of the PDCP layer, RLC layer, MAC layer, and PHY layer. Further, the signal processing performed by the processor 1804 may include signal processing of the GTP-U·UDP/IP layer in the X2-U interface and S1-U interface. Further, the control plane processing performed by the processor 1804 may include processing of the X2AP protocol, S1-MME protocol, and RRC protocol.

[0098] The processor 1804 may include a plurality of processors. For example, the processor 1804 may include a modem-processor (e.g., DSP) that performs the digital baseband signal processing, a processor (e.g., DSP) that performs the signal processing of the GTP-U·UDP/IP layer in the X2-U interface and S1-U interface, and a protocol-stack-processor (e.g., CPU or MPU) that performs the control-plane processing.

[0099] The memory 1805 is composed of 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, a Static Random Access Memory (SRAM), a Dynamic RAM (DRAM), or a combination thereof. The nonvolatile memory is, for example, a Read Only Memory (MROM), an Electrically Erasable Programmable ROM (EEPROM), a flash memory, a hard disk drive, or a combination thereof. The memory 1805 may include a storage located apart from the processor 1804. In this case, the processor 1804 may access the memory 1805 through the network interface 1803 or an I/O interface (not shown).

[0100] The memory 1805 may store a software module (i.e., computer program) including a set of instructions and data to perform processing performed by the (H)eNB 1 described in the above embodiments. In some implementations, the processor 1804 may be configured to load the software module from the memory 1805 and executing the loaded software module, thereby performing processing of the (H)eNB 1 described in the above embodiments.

[0101] Fig. 19 is Block diagram showing a configuration example of the X2 GW 3. As shown in Fig. 16, the X2 GW 3 includes a network interface 1901, a processor 1902, and a memory 1903. The network interface 1901 is used for communication with network nodes (e.g., (H)eNBs 1 and 2). The network interface 1901 may include, for example, a network interface card (NIC) conforming to the IEEE 802.3 series.

[0102] The processor 1902 loads software (i.e., computer program) from the memory 1903 and executes the loaded software, thereby performing processing of the X2 GW 3 described in the above embodiments. The processor 1902 may be, for example, a microprocessor, an MPU, or a CPU. The processor 1902 may include a plurality of processors.

[0103] The memory 1903 is composed of a combination of a volatile memory and a nonvolatile memory. The memory 1903 may include a storage located apart from the processor 1902. In this case, the processor 1902 may access the memory 1903 through an I/O interface (not shown).

[0104] As described above with reference to Figs. 18 and 19, each of the processors included in the (H)eNBs 1 and 2 and the X2 GW 3 in the above embodiments executes one or more programs including a set of instructions to cause a computer to perform an algorithm described above with reference to the drawings. These programs may be stored in various types of non-transitory computer readable media and thereby supplied to computers. The non-transitory computer readable media includes various types of tangible storage media. Examples of the non-transitory computer readable media include a magnetic recording medium (such as a flexible disk, a magnetic tape, and a hard disk drive), a magneto-optic recording medium (such as a magneto-optic disk), a Compact Disc Read Only Memory (CD-ROM), CD-R, CD-R/W, and a semiconductor memory (such as a mask ROM, a Programmable ROM (PROM), an Erasable PROM (EPROM), a flash ROM, and a Random Access Memory (RAM)). These programs may be supplied to computers by using various types of transitory computer readable media. Examples of the transitory computer readable media include an electrical signal, an optical signal, and an electromagnetic wave. The transitory computer readable media can be used to supply programs to a computer through a wired communication line (e.g., electric wires and optical fibers) or a wireless communication line.

Other Embodiments



[0105] Each of the above embodiments may be used individually, or two or more of the embodiments may be appropriately combined with one another.

[0106] In the examples shown the above embodiments, the GTP-U protocol is used in the X2-U interface of the X2 GW. However, a protocol different from the GTP-U protocol, such as Proxy Mobile IPv6 (PMIPv6), may be used.

[0107] The above embodiments may be applied to other radio communication systems such as a UMTS system and a GSM system. The base station ((H)eNB) described in the above embodiments may include a control node having a radio resource management function (e.g., Radio Network Controller (RNC) in UMTS or Base Station Controller (BSC) in GSM system) and a radio transmission node (e.g., NodeB in UMTS or Base transceiver station (BTS) in GSM system).

[0108] For example, as shown in 3GPP TS 25.467, when a Home NodeB (HNB) establishes an Iur connection with an RNC through a Home NodeB Gateway (HNB-GW), relocation can be performed between the HNB and the RNC through the HNB-GW. In this case, the HNB sends an RNSAP: Enhanced Relocation Request message via an Iurh interface through the HNB-GW . Then, the HNB-GW transfers the RNSAP: Enhanced Relocation Request message via an Iur interface by using a Signaling Connection Control Part (SCCP). In this case, the HNB-GW may further perform a U-plane relay between the HNB and the RNC.

[0109] The above embodiments may be applied to cases in which a gateway is used between a UMTS system and an LTE/LTE-Advanced system. For example, when a handover is performed between an HeNB of the LTE and an RNC of the UMTS, the gateway may perform a U-plane relay between the HeNB and the RNC.

[0110] The above embodiments may be applied to cases in which a gateway is used between a CDMA2000 system and an LTE/LTE-Advanced system. For example, the gateway may perform a U-plane relay when a handover is performed between an HeNB of the LTE and a base station of the CDMA2000 system.

[0111] The above embodiments may be applied to cases in which a gateway is used between a Wireless Local Area Network (WLAN) system and an LTE/LTE-Advanced system. For example, when a handover is performed between an HeNB of the LTE and an access point of the WLAN, the gateway may perform a U-plane relay between the HeNB and the access point.

[0112] Further, the above embodiments can be applied to cases in which an inter-base-station gateway is used for an inter-base-station handover in any Radio Access Technology (RAT). Further, the above embodiments can be applied to cases in which an inter-base-station gateway is used for an inter-base-station handover between any RATs.

[0113] Further, the above embodiments can be applied to cases in which an X2 gateway is used for a handover between a Relay Node (RN) and a Donor eNB (DeNB). The RN and the DeNB are described in 3GPP TS 36.300 (Non-patent Literature 1).

[0114] Further, as already described above, the above embodiments can be applied to cases in which an X2 gateway is used to transfer user data packets between a Master eNB (MeNB) and a Secondary eNB (SeNB) in the case of Dual Connectivity. The Dual Connectivity is described in 3GPP TS 36.300 (Non-patent Literature 1).

[0115] Further, the above embodiments are merely examples of applications of the technical ideas obtained by the inventor. Needless to say, these technical ideas are not limited to the above embodiments and various modifications can be made thereto. The scope of protection is defined by the appended set of claims.

Reference Signs List



[0116] 
1
(H)eNB
2
(H)eNB
3
X2 GATEWAY (X2 GW)
4
EVOLVED PACKET CORE (EPC)
5
MOBILITY MANAGEMENT ENTITY (MME)
1804
PROCESSOR
1805
MEMORY
1902
PROCESSOR
1903
MEMORY



Claims

1. A base station apparatus (1) comprising:

a memory (1805); and

at least one processor (1804) coupled to the memory, wherein

the at least one processor (1804) is configured to send (201) a first information element to an inter-base-station gateway (3), and

the first information element indicates whether a relay operation is necessary, the relay operation being an operation in which the inter-base-station gateway (3) relays a data packet destined for or sent from a radio terminal between the base station apparatus (1) and another base station (2),

wherein the base station apparatus (1) is characterized in that the at least one processor (1804) is configured to, generate the first information element indicating that a relay operation is necessary, if it is necessary to conceal a transport-layer address of the base station apparatus (1) from the other base station (2).


 
2. The base station apparatus (1) according to Claim 1, wherein the first information element explicitly indicates availability of a direct path between the base station apparatus (1) and the other base station (2).
 
3. The base station apparatus (1) according to Claim 1 or 2, wherein the at least one processor (1804) is configured to send the first information element when the radio terminal is handed over from the base station apparatus (1) to the other base station (2), or from the other base station (2) to the base station apparatus (1).
 
4. The base station apparatus (1) according to Claim 3, wherein the at least one processor (1804) is configured to incorporate the first information element into a transfer message that is to be sent to the inter-base-station gateway (3) to carry a handover request message or handover request acknowledge message for the other base station (2).
 
5. The base station apparatus (1) according to Claim 4, wherein the first information element implicitly indicates that the relay operation is necessary by indicating the same content as a second information element included in the handover request message or the handover request acknowledge message carried by the transfer message.
 
6. The base station apparatus (1) according to Claim 4, wherein the at least one processor (1804) is configured to incorporate, into the transfer message, a third information element indicating the same content as a second information element contained in the handover request message or the handover request acknowledge message carried by the transfer message.
 
7. The base station apparatus (1) according to Claim 5 or 6, wherein the second information element includes at least one of: an information element indicating necessity of forwarding the data packet; an information element indicating an identifier of a bearer configured for the radio terminal; and an information element indicating a Quality of Service, QoS, parameter of the bearer.
 
8. The base station apparatus (1) according to any one of Claims 4 to 7, wherein the at least one processor (1804) is configured to incorporate, into the transfer message, an information element indicating a type of an inter-base-station signaling message carried by the transfer message.
 
9. A method performed by a base station apparatus (1), the method comprising:

sending (201) a first information element to an inter-base-station gateway (3), wherein

the first information element indicates whether a relay operation is necessary, the relay operation being an operation in which the inter-base-station gateway (3) relays a data packet destined for or sent from a radio terminal between the base station apparatus (1) and another base station (2),

wherein the method is characterized by further comprising, generating the first information element indicating that a relay operation is necessary, if it is necessary to conceal a transport-layer address of the base station apparatus (1) from the other base station (2).


 
10. A computer program comprising instructions which, when the program is executed by a processor of a base station, cause the processor of the base station to carry out the method steps of claim 9.
 


Ansprüche

1. Basisstationsvorrichtung (1), die aufweist:

einen Speicher (1805); und

wenigstens einen Prozessor (1804), der mit dem Speicher gekoppelt ist, wobei

der wenigstens eine Prozessor (1804) konfiguriert ist, um ein erstes Informationselement an ein Zwischenbasisstation-Gateway (3) zu senden (201), und

wobei das erste Informationselement anzeigt, ob ein Relaisbetrieb notwendig ist, wobei der Relaisbetrieb ein Betrieb ist, in dem das Zwischenbasisstation-Gateway (3) ein Datenpaket, das für ein Funkendgerät zwischen der Basisstationsvorrichtung (1) und einer anderen Basisstation (2) bestimmt ist oder von diesem gesendet wird, weitergibt,

wobei die Basisstationsvorrichtung (1) dadurch gekennzeichnet ist, dass der wenigstens eine Prozessor (1804) konfiguriert ist, um das erste Informationselement, das anzeigt, dass ein Relaisbetrieb notwendig ist, zu erzeugen, wenn es notwendig ist, eine Transportschichtadresse der Basisstationsvorrichtung (1) vor der anderen Basisstation (2) zu verbergen.


 
2. Basisstationsvorrichtung (1) nach Anspruch 1, wobei das erste Informationselement explizit die Verfügbarkeit eines direkten Pfads zwischen der Basisstationsvorrichtung (1) und der anderen Basisstation (2) anzeigt.
 
3. Basisstationsvorrichtung (1) nach Anspruch 1 oder 2, wobei der wenigstens eine Prozessor (1804) konfiguriert ist, um das erste Informationselement zu senden, wenn das Funkendgerät von der Basisstationsvorrichtung (1) an die andere Basisstation (2) oder von der anderen Basisstation (2) an die Basisstationsvorrichtung (1) weitergegeben wird.
 
4. Basisstationsvorrichtung (1) nach Anspruch 3, wobei der wenigstens eine Prozessor (1804) konfiguriert ist, um das erste Informationselement in eine Übergabenachricht aufzunehmen, die an das Zwischenbasisstation-Gateway (3) gesendet werden soll, um eine Weitergabeanforderungsnachricht oder eine Weitergabeanforderungs-Quittungsnachricht für die andere Basisstation (2) zu befördern.
 
5. Basisstationsvorrichtung (1) nach Anspruch 4, wobei das erste Informationselement implizit anzeigt, dass der Relaisbetrieb notwendig ist, indem es den gleichen Inhalt wie ein zweites Informationselement anzeigt, das in der Weitergabeanforderungsnachricht oder der Weitergabeanforderungs-Quittungsnachricht, die von der Übergabenachricht befördert wird, enthalten ist.
 
6. Basisstationsvorrichtung (1) nach Anspruch 4, wobei der wenigstens eine Prozessor (1804) konfiguriert ist, um in die Übergabenachricht ein drittes Informationselement aufzunehmen, das den gleichen Inhalt wie ein zweites Informationselement anzeigt, das in der Weitergabeanforderungsnachricht oder der Weitergabeanforderungs-Quittungsnachricht, die von der Übergabenachricht befördert wird, enthalten ist.
 
7. Basisstationsvorrichtung (1) nach Anspruch 5 oder 6, wobei das zweite Informationselement wenigstens eines der folgenden umfasst: ein Informationselement, das die Notwendigkeit der Weiterleitung des Datenpakets anzeigt; ein Informationselement, das eine Kennung eines für das Funkendgerät konfigurierten Trägers anzeigt; und ein Informationselement, das einen Dienstqualitäts-, QoS-, Parameter des Trägers anzeigt.
 
8. Basisstationsvorrichtung (1) nach einem der Ansprüche 4 bis 7, wobei der wenigstens eine Prozessor (1804) konfiguriert ist, um in die Übergabenachricht ein Informationselement aufzunehmen, das einen Typ einer Zwischenbasisstationsignalisierungsnachricht, die von der Übergabenachricht befördert wird, anzeigt.
 
9. Verfahren, das von einer Basisstationsvorrichtung (1) durchgeführt wird, wobei das Verfahren aufweist:

Senden (201) eines ersten Informationselements an ein Zwischenbasisstation-Gateway (3), wobei

das erste Informationselement anzeigt, ob ein Relaisbetrieb notwendig ist, wobei der Relaisbetrieb ein Betrieb ist, in dem das Zwischenbasisstation-Gateway (3) ein Datenpaket, das für ein Funkendgerät zwischen der Basisstationsvorrichtung (1) und einer anderen Basisstation (2) bestimmt ist oder von diesem gesendet wird, weitergibt,

wobei das Verfahren dadurch gekennzeichnet ist, dass es ferner das Erzeugen des ersten Informationselements, das anzeigt, dass ein Relaisbetrieb notwendig ist, aufweist, wenn es notwendig ist, eine Transportschichtadresse der Basisstationsvorrichtung (1) vor der anderen Basisstation (2) zu verbergen.


 
10. Computerprogramm, das Anweisungen aufweist, die, wenn das Programm durch einen Prozessor einer Basisstation ausgeführt wird, bewirken, dass der Prozessor der Basisstation die Verfahrensschritte von Anspruch 9 ausführt.
 


Revendications

1. Appareil de station de base (1) comprenant :

une mémoire (1805) ; et

au moins un processeur (1804) couplé à la mémoire, dans lequel

l'au moins un processeur (1804) est configuré pour envoyer (201) un premier élément d'informations à une passerelle entre stations de base (3), et

le premier élément d'informations indique si une opération de relais est nécessaire, l'opération de relais étant une opération dans laquelle la passerelle entre stations de base (3) relaie un paquet de données destiné à un terminal radio, ou envoyé à partir de celui-ci, entre l'appareil de station de base (1) et une autre station de base (2),

dans lequel l'appareil de station de base (1) est caractérisé en ce que l'au moins un processeur (1804) est configuré pour générer le premier élément d'informations indiquant qu'une opération de relais est nécessaire, s'il est nécessaire de dissimuler une adresse de couche de transport de l'appareil de station de base (1) par rapport à l'autre station de base (2).


 
2. Appareil de station de base (1) selon la revendication 1, dans lequel le premier élément d'informations indique explicitement la disponibilité d'un chemin direct entre l'appareil de station de base (1) et l'autre station de base (2).
 
3. Appareil de station de base (1) selon la revendication 1 ou 2, dans lequel l'au moins un processeur (1804) est configuré pour envoyer le premier élément d'informations lorsque le terminal radio subit un transfert intercellulaire de l'appareil de station de base (1) à l'autre station de base (2), ou de l'autre station de base (2) à l'appareil de station de base (1).
 
4. Appareil de station de base (1) selon la revendication 3, dans lequel l'au moins un processeur (1804) est configuré pour incorporer le premier élément d'informations dans un message de transfert qui doit être envoyé à la passerelle entre stations de base (3) pour porter un message de demande de transfert intercellulaire ou un message d'accusé de réception de demande de transfert intercellulaire pour l'autre station de base (2).
 
5. Appareil de station de base (1) selon la revendication 4, dans lequel le premier élément d'informations indique implicitement que l'opération de relais est nécessaire en indiquant le même contenu qu'un deuxième élément d'informations inclus dans le message de demande de transfert intercellulaire ou le message d'accusé de réception de demande de transfert intercellulaire porté par le message de transfert.
 
6. Appareil de station de base (1) selon la revendication 4, dans lequel l'au moins un processeur (1804) est configuré pour incorporer, dans le message de transfert, un troisième élément d'informations indiquant le même contenu qu'un deuxième élément d'informations contenu dans le message de demande de transfert intercellulaire ou le message d'accusé de réception de demande de transfert intercellulaire porté par le message de transfert.
 
7. Appareil de station de base (1) selon la revendication 5 ou 6, dans lequel le deuxième élément d'informations inclut au moins l'un parmi : un élément d'informations indiquant la nécessité de réacheminer le paquet de données ; un élément d'informations indiquant un identifiant d'un support configuré pour le terminal radio ; et un élément d'informations indiquant un paramètre de qualité de service, QoS, du support.
 
8. Appareil de station de base (1) selon l'une quelconque des revendications 4 à 7, dans lequel l'au moins un processeur (1804) est configuré pour incorporer, dans le message de transfert, un élément d'informations indiquant un type d'un message de signalisation entre stations de base porté par le message de transfert.
 
9. Procédé réalisé par un appareil de station de base (1), le procédé comprenant :

l'envoi (201) d'un premier élément d'informations à une passerelle entre stations de base (3), dans lequel

le premier élément d'informations indique si une opération de relais est nécessaire, l'opération de relais étant une opération dans laquelle la passerelle entre stations de base (3) relaie un paquet de données destiné à un terminal radio, ou envoyé à partir de celui-ci, entre l'appareil de station de base (1) et une autre station de base (2),

dans lequel le procédé est caractérisé par le fait qu'il comprend en outre,

la génération du premier élément d'informations indiquant qu'une opération de relais est nécessaire, s'il est nécessaire de dissimuler une adresse de couche de transport de l'appareil de station de base (1) par rapport à l'autre station de base (2).


 
10. Programme informatique comprenant des instructions qui, lorsque le programme est exécuté par un processeur d'une station de base, amènent le processeur de la station de base à mettre en Ĺ“uvre les étapes de procédé selon la revendication 9.
 




Drawing































































REFERENCES CITED IN THE DESCRIPTION



This list of references cited by the applicant is for the reader's convenience only. It does not form part of the European patent document. Even though great care has been taken in compiling the references, errors or omissions cannot be excluded and the EPO disclaims all liability in this regard.

Patent documents cited in the description




Non-patent literature cited in the description