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

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

Info

Publication number
JP6384591B2
JP6384591B2 JP2017507123A JP2017507123A JP6384591B2 JP 6384591 B2 JP6384591 B2 JP 6384591B2 JP 2017507123 A JP2017507123 A JP 2017507123A JP 2017507123 A JP2017507123 A JP 2017507123A JP 6384591 B2 JP6384591 B2 JP 6384591B2
Authority
JP
Japan
Prior art keywords
base station
message
information element
relay
gateway
Prior art date
Legal status (The legal status 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 status listed.)
Active
Application number
JP2017507123A
Other languages
English (en)
Other versions
JPWO2016151653A1 (ja
Inventor
佳央 植田
佳央 植田
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
NEC Corp
Original Assignee
NEC Corp
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 NEC Corp filed Critical NEC Corp
Publication of JPWO2016151653A1 publication Critical patent/JPWO2016151653A1/ja
Application granted granted Critical
Publication of JP6384591B2 publication Critical patent/JP6384591B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W40/00Communication routing or communication path finding
    • H04W40/02Communication route or path selection, e.g. power-based or shortest path routing
    • H04W40/22Communication 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
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W36/00Hand-off or reselection arrangements
    • H04W36/0005Control or signalling for completing the hand-off
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W36/00Hand-off or reselection arrangements
    • H04W36/0005Control or signalling for completing the hand-off
    • H04W36/0055Transmission or use of information for re-establishing the radio link
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W36/00Hand-off or reselection arrangements
    • H04W36/0005Control or signalling for completing the hand-off
    • H04W36/0055Transmission or use of information for re-establishing the radio link
    • H04W36/0064Transmission or use of information for re-establishing the radio link of control information between different access points
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W36/00Hand-off or reselection arrangements
    • H04W36/04Reselecting a cell layer in multi-layered cells
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W36/00Hand-off or reselection arrangements
    • H04W36/08Reselecting an access point
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W76/00Connection management
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W88/00Devices specially adapted for wireless communication networks, e.g. terminals, base stations or access point devices
    • H04W88/16Gateway arrangements
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W92/00Interfaces specially adapted for wireless communication networks
    • H04W92/16Interfaces between hierarchically similar devices
    • H04W92/20Interfaces between hierarchically similar devices between access points

Landscapes

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

Description

本開示は、無線通信に関し、特に、基地局間でのユーザデータパケットのフォワーディングに関する。
3rd Generation Partnership Project(3GPP)Release 12は、X2 Gateway(X2 GW)について規定している(例えば、非特許文献1を参照)。非特許文献1に記載されているように、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)は、2つのピア(H)eNB内にのみ存在する(X2 GWが無い場合と同様)。X2APコンテキストは、2つのSCTPコネクションにまたがる(spans over)2つのピア(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の1つであるが、GTPノード間のシグナリングメッセージを包含するGTP-PDUと区別するためにG-PDUと呼ばれることもある。また、G-PDU又はシグナリングメッセージとしてのGTP-U PDUは、GTP-Uメッセージと呼ばれることもある。
非特許文献1に記載されているように、3GPP Release 12は、2つのピア(H)eNB 間でのX2 GWを介したX2APシグナリングメッセージ(X2-C)の転送を規定しているが、ユーザデータパケット(X2-U)の転送を規定していない。これに対して、特許文献1及び2は、2つのピア(H)eNB 間でのX2 GWを介したユーザデータパケットの転送を開示している。
特許文献1は、コアネットワーク(i.e., Evolved Packet Core(EPC))と(H)eNBの間でS1-MMEシグナリングメッセージ及びユーザデータパケットを中継するHeNB-GWが、X2-Cインタフェース及びX2-Uインタフェースもサポートすることを記載している。特許文献1に記載されたHeNB-GWは、ユーザデータパケットをカプセル化しているGTP-PDU(i.e., G-PDU)を2つのピア(H)eNBの間で中継するよう動作する。しかしながら、特許文献1は、HeNB-GWによるG-PDUの中継動作の詳細について記載していない。
特許文献2は、G-PDUが2つの(H)eNB間でX2-GWを介して転送されることを記載している。特許文献2のX2-GWは、ハンドオーバ準備時に2つの(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インタフェース)の最大または実効的なスループット(伝送速度)が十分に大きければ、常に基地局間ゲートウェイによるリレーを利用することは遅延の増大の観点から適切ではないかもしれない。一方で、基地局間ダイレクトパスの負荷が高い場合、又は基地局間ダイレクトパスが何らかの事情で利用不能である場合には、基地局間ゲートウェイによるリレーを選択できることが好ましいかもしれない。また、2つの基地局(e.g., (H)eNBs)間のハンドオーバの際に、一方の基地局のTNLアドレス(e.g., IPアドレス)を他方の基地局から隠蔽できることが好ましいかもしれない。このTNLアドレスの隠蔽は、特定の基地局または特定の種別の基地局に対してのみ要求されるかもしれない。
したがって、基地局(e.g., (H)eNB)又は基地局間ゲートウェイ(e.g., X2-GW)は、基地局間でのユーザデータパケットの転送の際に基地局間ゲートウェイ(e.g., X2-GW)によるリレー処理を行うか否かを選択できることが好ましいかもしれない。しかしながら、特許文献1及び2は、X2 GWによるリレー処理を行うか否かを制御することについて記載していない。ここで、基地局間ゲートウェイ(e.g., X2-GW)によるユーザデータパケットのリレー処理は、X2 GWを介した基地局(e.g., (H)eNBs)間でのユーザデータパケットの転送を意味する。
本明細書に開示される実施形態が達成しようとする目的の1つは、基地局(e.g., (H)eNB)又は基地局間ゲートウェイ(e.g., X2-GW)が基地局間ゲートウェイ(e.g., X2-GW)によるリレー処理を行うか否かを選択できるようにすることに寄与する装置、方法、及びプログラムを提供することである。この目的は、本明細書に開示される実施形態が達成しようとする複数の目的の1つに過ぎないことに留意されるべきである。その他の目的又は課題と新規な特徴は、本明細書の記述又は添付図面から明らかにされる。
第1の態様では、基地局装置は、メモリ、及び前記メモリに結合された少なくとも1つのプロセッサを含む。前記少なくとも1つのプロセッサは、第1の情報要素を基地局間ゲートウェイに送信するよう構成されている。前記第1の情報要素は、無線端末宛て又は前記無線端末からのデータパケットを前記基地局間ゲートウェイが前記基地局装置と他の基地局の間で中継するリレー処理が必要とされる否かを明示的または暗示的に示す。
第2の態様では、基地局間ゲートウェイ装置は、メモリ、及び前記メモリに結合された少なくとも1つのプロセッサを含む。前記少なくとも1つのプロセッサは、第1の情報要素を第1の基地局及び第2の基地局の少なくとも一方から受信するよう構成されている。前記第1の情報要素は、無線端末宛て又は前記無線端末からのデータパケットを前記基地局間ゲートウェイ装置によって前記第1の基地局と前記第2の基地局の間で中継するリレー処理が必要とされる否かを明示的または暗示的に示す。
第3の態様では、基地局装置により行われる方法は、第1の情報要素を基地局間ゲートウェイに送信することを含む。前記第1の情報要素は、無線端末宛て又は前記無線端末からのデータパケットを前記基地局間ゲートウェイが前記基地局装置と他の基地局の間で中継するリレー処理が必要とされる否かを明示的または暗示的に示す。
第4の態様では、基地局間ゲートウェイ装置により行われる方法は、第1の情報要素を第1の基地局及び第2の基地局の少なくとも一方から受信することを含む。前記第1の情報要素は、無線端末宛て又は前記無線端末からのデータパケットを前記基地局間ゲートウェイ装置によって前記第1の基地局と前記第2の基地局の間で中継するリレー処理が必要とされる否かを明示的または暗示的に示す。
第5の態様では、プログラムは、コンピュータに読み込まれた場合に、上述の第3又は第4の態様に係る方法をコンピュータに行わせるための命令群(ソフトウェアコード)を含む。
上述の態様によれば、基地局又は基地局間ゲートウェイが基地局間ゲートウェイによるリレー処理を行うか否かを選択できるようにすることに寄与する装置、方法、及びプログラムを提供できる。
いくつかの実施形態に係る無線通信システムの構成例を示す図である。 第1の実施形態に係るリレー処理の必要性を通知する手順の一例を示すシーケンス図である。 第1の実施形態に係るソース基地局の動作の一例を示すフローチャートである。 第1の実施形態に係る基地局間ゲートウェイの動作の一例を示すフローチャートである。 第1の実施形態に係るターゲット基地局の動作の一例を示すフローチャートである。 第1の実施形態に係るターゲット基地局の動作の一例を示すフローチャートである。 第1の実施形態に係るソース基地局および基地局間ゲートウェイの動作とその起動条件の組み合せの一例を示すテーブルである。 第1の実施形態に係るソース基地局および基地局間ゲートウェイの動作とその起動条件の組み合せの一例を示すテーブルである。 第1の実施形態に係るターゲット基地局および基地局間ゲートウェイの動作とその起動条件の組み合せの一例を示すテーブルである。 第1の実施形態に係るターゲット基地局および基地局間ゲートウェイの動作とその起動条件の組み合せの一例を示すテーブルである。 第1の実施形態に係るリレー能力の通知手順の一例を示すシーケンス図である。 第1の実施形態に係るリレー能力の通知手順の一例を示すシーケンス図である。 第1の実施形態に係る基地局間ハンドオーバ手順の一例を示すシーケンス図である。 第1の実施形態に係る基地局間ハンドオーバ手順の一例を示すシーケンス図である。 X2AP Message Transferメッセージの変更(modification)の一例を示す図である。 X2AP Message Transferメッセージの変更の他の例を示す図である。 X2AP Message Transferメッセージの変更の他の例を示す図である。 第3の実施形態に係る基地局間ゲートウェイのアドレスをターゲット基地局に通知する手順の一例を示すシーケンス図である。 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システム等に適用されてもよい。
<第1の実施形態>
図1は、本実施形態を含むいくつかの実施形態に係る無線通信システムの構成例を示している。図1の例では、無線通信システムは、(H)eNB1、(H)eNB2、X2 GW3、及びEPC4を含む。X2 GW3は、(H)eNBs1及び2の間でシグナリングメッセージ(X2APメッセージ)を中継するために、(H)eNBs1及び2の各々とSCTPコネクションを確立するよう構成されている。X2 GW3は、さらに、(H)eNBs1及び2の間でユーザデータパケットを中継するために、(H)eNBs1及び2の各々とGTP-Uトンネルを確立できるよう構成されている。(H)eNBs1及び2の各々は、X2 GW3との間にX2-Cインタフェースを有し、EPC4との間にS1インタフェースを有する。なお、 (H)eNB1及び2の少なくとも一方とEPC4の間にHeNB-GWが使用されてもよい。当該HeNB-GWは、(H)eNB1及び2の少なくとも一方とEPC4の間でS1-MMEシグナリング及びユーザデータパケット(S1-U)を中継する。本実施形態では、主に、(H)eNB1から(H)eNB2へのUEのハンドオーバについて説明する。したがって、 (H)eNB1をソース(H)eNBと呼び、(H)eNB2をターゲット(H)eNBと呼ぶこともある。
本実施形態では、(H)eNBs1及び2の少なくとも一方は、第1の情報要素(Information Element(IE))をX2 GW3に送信するよう構成されている。当該第1の情報要素は、無線端末(User Equipment(UE))のユーザデータパケットのフォワーディングのためにX2 GW3によるリレー処理が必要とされるか否かを明示的又は暗示的に示す。いくつかの実装において、(H)eNB1から(H)eNB2への当該UEのハンドオーバの際に、ソース(H)eNBs1及びターゲット(H)eNB2の少なくとも一方が当該第1の情報要素を送信してもよい。いくつかの実装において、(H)eNB1、(H)eNB2、及びUEがDual Connectivityをサポートする場合に、当該UEのベアラ確立の際に、(H)eNBs1及び (H)eNB2の少なくとも一方が当該第1の情報要素を送信してもよい。
X2 GW3によるリレー処理は、(H)eNB1とX2 GW3の間のX2-Uインタフェース(GTP-Uトンネル)101、及び(H)eNB2とX2 GW3の間のX2-Uインタフェース(GTP-Uトンネル)102を介してユーザデータパケット(T-PDU)を転送することを含む。X2 GW3によるユーザデータパケットのリレーは、当該リレー処理は、GTP-Uヘッダによりカプセル化されたユーザデータパケット、つまりG-PDUを転送することにより行われてもよい。X2 GW3によるリレー処理は、X2-Uリレー、U-planeリレー、GTP-Uリレー、又はユーザプレーン集約(user plane concentration)と呼ぶこともできる。
すなわち、当該第1の情報要素は、X2 GW3によるU-planeリレーの必要性を示す明示的(explicit)又は暗示的(implicit)な表示(indication)である。いくつかの実装において、当該表示は、X2 GW3によるリレー処理が必要とされるか否かに応じて異なる値がセットされるフラグ情報であってもよい。これに代えて、いくつかの実装において、当該表示は、X2 GW3によるリレー処理が必要とされる場合に送信され且つリレー処理が不要な場合に送信されない明示的又は暗示的なリレー要求であってもよい。これに代えて、いくつかの実装において、当該表示は、複数の情報要素の組み合せであってもよい。
例えば、以下に示される具体例のように、当該表示は、(H)eNBs1及び2の間のダイレクトパス100の利用可否を示す情報要素(e.g., Direct Path Availability IE又は Direct Path Unavailability IE)を含んでもよい。ダイレクトパス100の利用可否は、例えば、オペレータによって、つまりoperations, administration and maintenance(OAM)によって、(H)eNBs1及び2に予め設定されてもよい。これに代えて、ダイレクトパス100の利用可否は、(H)eNBs1及び2によって動的に判定されてもよい。例えば、(H)eNBs1及び2は、ダイレクトパス100を利用できるがそのスループットが低い場合、又はダイレクトパス100の負荷が高い場合に、ダイレクトパス100を利用できないと判定してもよい。当該表示は、例えば、ダイレクトパス100の利用可否を示す情報要素とデータフォワーディングの要否を示す情報要素(e.g., DL Forwarding IE又はUplink (UL) GTP Tunnel Endpoint IE)の組合せであってもよい。
図2は、リレー処理の必要性をX2 GW3に通知する手順の一例(処理200)を示すシーケンス図である。ブロック201では、(H)eNB1又は2は、X2AP Message TransferメッセージをX2 GW3に送信する。当該X2AP Message Transferメッセージは、ソース(H)eNB1からターゲット(H)eNB2へのX2AP Handover Requestメッセージ又はターゲット(H)eNB2からソース(H)eNB1へのX2AP Handover Request Acknowledgeメッセージを運ぶ。当該X2AP Message Transferメッセージは、さらに、X2 GW3によるX2-Uリレー処理の必要性を明示的又は暗示的に示す表示を含む。X2 GW3は、当該表示に基づいて、X2-Uリレーの準備を行うべきか否かを認識することができる。
また、図2の例では、X2 GW3は、Handover Requestメッセージ又はHandover Request Acknowledgeメッセージを運ぶX2AP Message Transferメッセージと共に、X2-Uリレー処理の必要性を示す表示を受信する。したがって、X2 GW3は、当該X2AP Message Transferメッセージを参照することによって、X2-Uリレーに必要なGTP-Uトンネルの準備を容易に行うことができる。
以上の説明から理解されるように、本実施形態では、(H)eNBs1及び2の少なくとも一方は、X2 GW3によるU-plane(X2-U)リレーが必要とされるか否かを明示的又は暗示的に示す表示をX2 GW3に送信するよう構成されている。したがって、X2 GW3は、当該表示に基づいて、U-plane(X2-U)リレーを行うべきか否かを認識することができる。
さらに、本実施形態では、(H)eNBs1及び2の少なくとも一方は、(H)eNB1から(H)eNB2への無線端末(UE)のユーザデータパケットの転送が必要とされる場合に、当該UEのユーザデータパケットのフォワーディングのためにX2 GW3によるリレー処理を利用するか否かを決定するよう構成されてもよい。言い換えると、(H)eNBs1及び2は、(H)eNB1から(H)eNB2へのユーザデータパケットのフォワーディングのためにX2 GW3を介したリレーパス(101及び102)とダイレクトパス(100)のどちらを利用するかを選択するよう構成されてもよい。X2 GW3によるリレー処理を利用しない場合、ソース(H)eNB1は、(H)eNBs1及び2の間のダイレクトパス、つまりX2-Uインタフェース(GTP-Uトンネル)100を用いてユーザデータパケットをターゲット(H)eNB2にフォワーディングしてもよい。
いくつかの実装において、ソース(H)eNB1は、(H)eNB2へのUEのハンドオーバの開始を決定した場合に、X2 GW3によるU-plane(X2-U)リレー処理を利用するか否かを判定してもよい。いくつかの実装において、ターゲット(H)eNB2は、ソース(H)eNB1からのハンドオーバ要求を受信した場合に、X2 GW3によるU-plane(X2-U)リレー処理を利用するか否かを判定してもよい。いくつかの実装において、(H)eNB1は、Dual connectivityをサポートするUEに関するベアラ確立の要求(e.g., S1AP: Initial Context Setup Request)をEPC4から受信した場合に、X2 GW3によるU-plane(X2-U)リレー処理を利用するか否かを判定してもよい。これらに代えて、X2 GW3によるU-plane(X2-U)リレー処理を利用するか否かは、(H)eNBのペア毎に予め決定されてもよい。
いくつかの実装において、(H)eNB1若しくは2又はこれら両方は、ダイレクトパス100の状態(e.g., ダイレクトパス100の利用可否、ダイレクトパス100のスループット、又はダイレクトパス100の負荷)に応じて、X2 GW3によるU-plane(X2-U)リレー処理を利用するか否かを選択してもよい。言い換えると、(H)eNB1若しくは2又はこれら両方は、X2 GW3によるU-plane(X2-U)リレー処理を利用するか否か(又は要求するか否か)を決定する際に、ダイレクトパス100の状態を考慮してもよい。
例えば、基地局間ダイレクトパス100の最大または実効的なスループット(伝送速度)が (H)eNB1(又は2)とX2 GW3の間のパス101(又は102)のスループットよりも大きければ、基地局間ゲートウェイによるリレーを利用することは遅延の増大の観点から適切ではないかもしれない。したがって、(H)eNB1又は2は、基地局間ダイレクトパス100のスループットが(H)eNB1とX2 GW3の間のパス101又は102のスループットよりも十分に大きい場合に、X2 GW3によるU-plane(X2-U)リレー処理を利用しないことを決定してもよい。これにより、不必要なU-planeリレーに起因する遅延の増大を抑制できる。
いくつかの実装において、(H)eNB1は、(H)eNB1のTNLアドレス(e.g., IPアドレス)を(H)eNB2から隠蔽する必要がある場合にX2 GW3によるU-plane(X2-U)リレー処理を利用し、TNLアドレスの隠蔽が必要でない場合にダイレクトパス100を介したフォワーディングを実施してもよい。同様に、(H)eNB2は、(H)eNB2のTNLアドレス(e.g., IPアドレス)を(H)eNB1からの隠蔽の必要性に基づいて、X2 GW3によるU-plane(X2-U)リレー処理を利用するか否かを選択してもよい。言い換えると、(H)eNB1若しくは2又はこれら両方は、X2 GW3によるU-plane(X2-U)リレー処理を利用するか否か(又は要求するか否か)を決定する際に、TNLアドレスの隠蔽の必要性を考慮してもよい。
例えば、ソース(H)eNB1は、ハンドオーバの際に、自身のTNLアドレス(e.g., IPアドレス)をターゲット(H)eNB2から隠蔽することを必要とするかもしれない。これとは反対に、ターゲット(H)eNB2がそのTNLアドレス(e.g., IPアドレス)をソース(H)eNB1から隠蔽することを必要とするかもしれない。このTNLアドレスの隠蔽は、特定の基地局または特定の種別の基地局に対してのみ要求されるかもしれない。
HeNBは通信事業者によって管理される局舎(サイト)内ではなく、エンドユーザの家やビル内に設置されうる。そのため、HeNBは悪意のユーザによって改造されるおそれがあり、必ずしもセキュリティが十分に保証された装置とはいえない。したがって、ハンドオーバの際に、このようなHeNBに対してマクロeNBのX2-U TNLアドレスを知らせることは、マクロeNBがDenial of Service(DoS)攻撃を受ける等のセキュリティリスクを招くおそれがある。例えば、ソース(H)eNB1がマクロeNBであってターゲット(H)eNB2がHeNBである場合、ソース(H)eNB1は、X2 GW3によるU-plane(X2-U)リレー処理を利用することを決定してもよい。一方、ソース(H)eNB1がマクロeNBであってターゲット(H)eNB2もマクロeNBである場合、ソース(H)eNB1は、X2 GW3によるU-plane(X2-U)リレー処理を利用しないことを決定してもよい。これにより、マクロeNBのX2-U TNLアドレスをHeNBに知らせることに起因するセキュリティリスクを抑制できる。
いくつかの実装において、(H)eNB1若しくは2又はこれら両方は、X2 GW3のU-planeリレー能力(U-plane Relay Capability)に基づいて、X2 GW3によるU-plane(X2-U)リレー処理を利用するか否かを選択してもよい。言い換えると、(H)eNB1若しくは2又はこれら両方は、X2 GW3によるU-plane(X2-U)リレー処理を利用するか否か(又は要求するか否か)を決定する際に、X2 GW3のU-planeリレー能力の有無を考慮してもよい。
以上の説明から理解されるように、本実施形態では、(H)eNBs1及び2の少なくとも一方は、(H)eNB1から(H)eNB2へのUEのハンドオーバの際に、X2 GW3によるU-plane(X2-U)リレー処理を利用するか否かを決定するよう構成されてもよい。これにより、(H)eNBs1及び2の少なくとも一方は、X2 GW3によるU-plane(X2-U)リレー処理を利用するか否かを選択できる。
続いて以下では、ソース(H)eNB1、X2 GW3、及びターゲット(H)eNB2の動作の具体例について説明する。図3は、ソース(H)eNB1の動作の一例(処理300)を示すフローチャートである。ブロック301では、(H)eNB1は、ターゲット(H)eNB2へのUEのハンドオーバの開始を判定する。ブロック302では、当該ハンドオーバの際に、X2 GW3によるU-plane(X2-U)リレー処理が必要とされるか否かを判定する。U-plane(X2-U)リレー処理が必要とされる場合(ブロック302でYES)、ソース(H)eNB1は、ハンドオーバ要求(i.e., Handover Requestメッセージ)を運ぶ転送メッセージ(i.e., X2AP Message Transferメッセージ)に明示的又は暗示的なリレー要求を含める(ブロック303)。ブロック304では、ソース(H)eNB1は、ハンドオーバ要求を運ぶ転送メッセージ(リレー要求を含む)をX2 GW3に送信する。これに対して、U-plane(X2-U)リレー処理が必要とされない場合、(ブロック302でNO)、ソース(H)eNB1は、ハンドオーバ要求を運ぶ転送メッセージ(リレー要求を含まない)をX2 GW3に送信する(ブロック305)。
図4は、X2 GW3の動作の一例(処理400)を示すフローチャートである。ブロック401では、X2 GW3は、ハンドオーバ要求(i.e., Handover Requestメッセージ)を運ぶ転送メッセージ(i.e., X2AP Message Transferメッセージ)をソース(H)eNB1から受信する。ブロック402では、X2 GW3は、受信した転送メッセージ内にリレー要求が含まれているか否かを確認する。転送メッセージがリレー要求を含む場合(ブロック402でYES)、X2 GW3は、X2 GW3によるU-plane(X2-U)リレーが行われることを示す表示を転送メッセージ(ハンドオーバ要求を運ぶ)に追加し、これをターゲット(H)eNB2に送信する。
いくつかの実装において、X2 GW3によるU-plane(X2-U)リレーが行われることを示す当該表示は、U-plane(X2-U)リレーが行われるか否かを示す単純なフラグ情報であってもよい。さらに又はこれに代えて、図4のブロック403に示されているように、X2 GW3によるU-plane(X2-U)リレーが行われることを示す当該表示は、X2トランスポートベアラ(i.e., GTP-Uベアラ)に関するX2 GW3側のエンドポイント設定を含んでもよい。エンドポイント設定は、TNLアドレス(e.g., IPアドレス)及びTEIDを含む。当該エンドポイント設定は、ダウンリンク(DL)ユーザデータパケットのフォワーディングに使用されるX2トランスポートベアラに関するDL GTPトンネル・エンドポイント設定のみでもよいし、アップリンク(UL)ユーザデータパケットのフォワーディングに使用されるX2トランスポートベアラに関するUL GTPトンネル・エンドポイント設定をさらに含んでもよい。
X2 GW3が、ハンドオーバ要求を運ぶ転送メッセージと共に、X2トランスポートベアラ(i.e., GTP-Uベアラ)に関するX2 GW3側のエンドポイント設定をターゲット(H)eNB2に送信することによって、例えば以下に述べる効果が得られる。いくつかの実装において、ターゲット(H)eNB2は、Access Control List (ACL)機能(functionality)を有するかもしれない。ACL機能がターゲット(H)eNB2に適用された場合、ターゲット(H)eNB2は、送信ノードのソースアドレスをターゲット(H)eNB2において既に知っている場合に限り、送信ノードからのコネクションを受け入れる。このため、仮にターゲット(H)eNB2がX2 GW3のX2-U TNLアドレスを知らなければ、ターゲット(H)eNB2は、X2 GW3から送信されるG-PDUを運ぶTNL UDP/IPパケットをACL機能により破棄するおそれがある。これを回避するために、X2 GW3は、データフォワーディングの上流側であるが、X2トランスポートベアラ(i.e., GTP-Uベアラ)に関するX2 GW3側のエンドポイント設定をターゲット(H)eNB2に先に通知するとよい。これにより、ターゲット(H)eNB2は、X2 GW3のX2-U TNLアドレスからのコネクションを受け入れるようにACLを更新することができる。ACLは、パケットフィルタ又はファイヤウォール設定と言うこともできる。
図4に戻り説明を続ける。転送メッセージがリレー要求を含まない場合(ブロック402でNO)、X2 GW3は、ソース(H)eNB1から受信した転送メッセージをそのままターゲット(H)eNB2に送信する(ブロック404)。つまり、ブロック404で送信される転送メッセージは、X2 GW3によるU-plane(X2-U)リレーが行われることを示す表示を含まない。
図5は、ターゲット(H)eNB2の動作の一例(処理500)を示すフローチャートである。ブロック501では、ターゲット(H)eNB2は、ハンドオーバ要求(i.e., Handover Requestメッセージ)を運ぶ転送メッセージ(i.e., X2AP Message Transferメッセージ)をX2 GW3から受信する。ブロック502では、受信した転送メッセージが、X2トランスポートベアラ(i.e., GTP-Uベアラ)に関するX2 GW3側のエンドポイント設定を含むか否かを判定する。X2 GW3側のエンドポイント設定が含まれている場合(ブロック503でYES)、ターゲット(H)eNB2は、X2 GW3のX2-U TNLアドレスからのコネクションを受け入れるように自身のACLを更新する。
ブロック504では、ターゲット(H)eNB2は、ハンドオーバ要求承認(i.e., Handover Request Acknowledgeメッセージ)を運ぶ転送メッセージ(i.e., X2AP Message Transferメッセージ)を X2 GW 3に送信する。ハンドオーバ要求承認(i.e., Handover Request Acknowledgeメッセージ)は、ターゲット(H)eNB2のDL GTPトンネル・エンドポイント設定を含む。さらに、DLデータフォワーディングに加えてULデータフォワーディングが行われる場合、ハンドオーバ要求承認(i.e., Handover Request Acknowledgeメッセージ)は、ターゲット(H)eNB2のUL GTPトンネル・エンドポイント設定を含む。ターゲット(H)eNB2のDL GTPトンネル・エンドポイント設定は、ソース(H)eNB1からフォワーディングされるDLユーザデータパケットを受信するためのGTP-Uトンネルに関するTNLアドレス及びTEIDを含む。ターゲット(H)eNB2のUL GTPトンネル・エンドポイント設定は、ソース(H)eNB1からフォワーディングされるULユーザデータパケットを受信するためのGTP-Uトンネルに関するTNLアドレス及びTEIDを含む。
なお、ブロック504において送信されるハンドオーバ要求承認メッセージを運ぶ転送メッセージは、ハンドオーバ要求承認メッセージ内に記述されているのと同じターゲット(H)eNB2のGTPトンネル・エンドポイント設定を示す追加の情報要素を含んでもよい。このようなメッセージ構成は冗長であるものの、X2 GW3がハンドオーバ要求承認メッセージをデコード又は参照しなくてもよいという利点がある。
図3〜図5に示されたソース(H)eNB1、X2 GW3、及びターゲット(H)eNB2の動作は一例であって適宜変更されてもよい。例えば、図3においてリレー要求の送信に使用されるメッセージは、X2AP Message Transferメッセージとは異なるX2APメッセージであってもよい。例えば、リレー要求は、X2AP Message Transferメッセージによって運ばれるHandover Requestメッセージ内にセットされてもよい。図4において、X2 GW3のエンドポイント設定の送信に使用されるメッセージは、X2AP Message Transferメッセージとは異なるX2APメッセージであってもよい。例えば、X2 GW3のエンドポイント設定は、X2AP Message Transferメッセージによって運ばれるHandover Requestメッセージ内にセットされてもよい。
図3〜図5は、ハンドオーバ要求の際に、ソース(H)eNB1がX2 GW3によるU-plane(X2-U)リレーを利用するか否か(又は要求するか否か)を判定する例について示した。これと同様に、ハンドオーバ要求をソース(H)eNB1からX2 GW3を介して受信した場合に、ターゲット(H)eNB2は、ソース(H)eNB1がX2 GW3によるU-plane(X2-U)リレーを利用するか否か(又は要求するか否か)を判定してもよい。すなわち、ソース(H)eNB1によるX2 GW3によるU-plane(X2-U)リレーの要否判定とは独立に、ターゲット(H)eNB2は、X2 GW3によるU-plane(X2-U)リレーの要否を判定してもよい。
図6は、ターゲット(H)eNB2によって行われるU-plane(X2-U)リレーの要否判定を含む動作の一例(処理600)を示すフローチャートである。ブロック601では、ターゲット(H)eNB2は、ハンドオーバ要求(i.e., Handover Requestメッセージ)を運ぶ転送メッセージ(i.e., X2AP Message Transferメッセージ)をX2 GW3から受信する。ブロック602では、ターゲット(H)eNB2は、X2 GW3によるU-plane(X2-U)リレー処理が必要とされるか否かを判定する。U-plane(X2-U)リレー処理が必要とされる場合(ブロック602でYES)、ターゲット(H)eNB2は、ハンドオーバ要求承認(i.e., Handover Request Acknowledgeメッセージ)を運ぶ転送メッセージ(i.e., X2AP Message Transferメッセージ)に明示的又は暗示的なリレー要求を含める(ブロック603)。ブロック604では、ターゲット(H)eNB2は、ハンドオーバ要求承認を運ぶ転送メッセージ(リレー要求を含む)をX2 GW3に送信する。これに対して、U-plane(X2-U)リレー処理が必要とされない場合、(ブロック602でNO)、ターゲット(H)eNB2は、ハンドオーバ要求承認を運ぶ転送メッセージ(リレー要求を含まない)をX2 GW3に送信する(ブロック605)。
ハンドオーバ要求承認を運ぶ転送メッセージ(リレー要求を含む)をターゲット(H)eNB2から受信したときのX2 GW3の動作は、図4と同様であってもよい。ただし、図5に関して説明したように、ハンドオーバ要求承認(i.e., Handover Request Acknowledgeメッセージ)は、ターゲット(H)eNB2のGTPトンネル・エンドポイント設定を含む。いくつかの実装において、ブロック403に相当する処理において、X2 GW3は、Handover Request Acknowledgeメッセージ内に記述されているターゲット(H)eNB2のGTPトンネル・エンドポイント設定を、X2 GW3のGTPトンネル・エンドポイント設定によって書き換えてもよい。
これに代えて、ブロック403に相当する処理において、X2 GW3は、Handover Request Acknowledgeメッセージ内に記述されているターゲット(H)eNB2のGTPトンネル・エンドポイント設定に修正を加えずに、X2 GW3のエンドポイント設定を示す追加の情報要素をX2AP Message Transferメッセージに含めてもよい。この場合、ソース(H)eNB1は、追加の情報要素に従ってX2トランスポートベアラコンテキストを更新し、Handover Request Acknowledgeメッセージ内に記述されているターゲット(H)eNB2のGTPトンネル・エンドポイント設定を無視すればよい。
ただし、ターゲット(H)eNB2のTNLアドレスをソース(H)eNB1から隠蔽するためにX2 GW3によるU-plane(X2-U)リレーが行われる場合、X2 GW3は、Handover Request Acknowledgeメッセージ内に記述されているターゲット(H)eNB2のGTPトンネル・エンドポイント設定を修正することが好ましい。これにより、ターゲット(H)eNB2のTNLアドレスのソース(H)eNB1からの隠蔽を確実に行うことができる。
図3〜図6は、ハンドオーバにおける (H)eNB1、(H)eNB2、及びX2 GW3の動作の具体例を示した。しかしながら、既に説明したことから理解されるように、図3〜図6を用いて説明された(H)eNB1、(H)eNB2、及びX2 GW3の動作の具体例は、Dual connectivityをサポートするUEに関するベアラ確立を行う際に適用されてもよい。例えば、(H)eNB1は、Dual connectivityをサポートするUEに関するベアラ確立の要求をEPC4から受信したことに応答して、X2 GW3によるU-plane(X2-U)リレー処理を利用するか否かを判定してもよい。そして、(H)eNB1は、Dual connectivityのためのUEコンテキストの確立のためのX2APメッセージを運ぶ転送メッセージ(i.e., X2AP Message Transferメッセージ)に明示的又は暗示的なリレー要求を含めてもよい。
続いて以下では、ソース(H)eNB1およびX2 GW3の動作とその起動条件の具体例について図7及び図8を用いて説明する。図7は、ソース(H)eNB1およびX2 GW3の動作とその起動条件の組み合せの一例を示すテーブルである。図7の例では、ソース(H)eNB1は、U-plane(X2-U)リレーを利用するか否か(又は要求するか否か)を判定するために、ダイレクトパス100の利用可否(Direct Path Availability)及びX2 GW3のリレー能力(U-plane Relay Capability)を参酌する。
図7に示されたケース1は、ダイレクトパス100が利用可能であり、X2 GW3がリレー能力を有する場合である。図7に示されたケース2は、ダイレクトパス100が利用でき、X2 GW3がリレー能力を有していない場合である。ケース1及びケース2では、ダイレクトパス100が利用可能であるため、ソース(H)eNB1は、X2 GW3に対する明示的又は暗示的なリレー要求をX2AP Message Transferメッセージ(Handover Requestメッセージを運ぶ)に設定しない。したがって、X2 GW3は、DLデータフォワーディングに関するU-plane(X2-U)リレーを実施しない。
図7に示されたケース3は、ダイレクトパス100が利用不可であり、X2 GW3がリレー能力を有する場合である。ケース3では、ダイレクトパス100が利用不可であるが、X2 GW3がリレー能力を有するため、ソース(H)eNB1は、X2 GW3に対する明示的又は暗示的なリレー要求をX2AP Message Transferメッセージ(Handover Requestメッセージを運ぶ)に設定する。したがって、X2 GW3は、DLデータフォワーディングに関するU-plane(X2-U)リレーを実施する。
図7に示されたケース4は、ダイレクトパス100が利用不可であり、且つX2 GW3がリレー能力を有していない場合である。ケース4では、X2-Uデータフォワーディングが不可能であるから、ソース(H)eNB1は、X2 GW3に対する明示的又は暗示的なリレー要求をX2AP Message Transferメッセージ(Handover Requestメッセージを運ぶ)に設定しない。したがって、X2 GW3は、DLデータフォワーディングに関するU-plane(X2-U)リレーを実施しない。
なお、既に説明したように、いくつかの実装において、X2 GW3に対する暗示的なリレー要求(又はリレー表示)は、複数の情報要素の組み合せを含んでもよい。例えば、図8に示されているように、X2 GW3に対する暗示的なリレー要求(又はリレー表示)は、Direct Path Unavailability IEおよびDL Forwarding IEの組み合せであってもよい。図8に示されたDirect Path Unavailability IEは、ダイレクトパス100が利用不可能であるときに設定される。Direct Path Unavailability IEは、1ビットのフラグ情報であってもよい。図8に示されたDL Forwarding IEは、現在の3GPP仕様においてX2AP: Handover Requestメッセージに含まれているDL Forwarding IEであってもよいし、X2AP Message Transferメッセージに新たに追加される情報要素であってもよい。
図8に示されたケース1〜4は、図7に示されたケース1〜4にそれぞれ対応する。すなわち、図8に示されたケース1は、ダイレクトパス100が利用可能であり、X2 GW3がリレー能力を有する場合である。図8に示されたケース2は、ダイレクトパス100が利用でき、X2 GW3がリレー能力を有していない場合である。ケース1及びケース2では、ダイレクトパス100が利用可能であるため、ソース(H)eNB1は、Direct Path Unavailability IEを設定しない。一方、(ダイレクトパス100を介して)DLフォワーディングを行うことをターゲット(H)eNB2に知らせるために、DL Forwarding IEを設定する。
図8に示されたケース3は、ダイレクトパス100が利用不可であり、X2 GW3がリレー能力を有する場合である。ケース3では、ダイレクトパス100が利用不可であるため、Direct Path Unavailability IEを設定する。さらに、ダイレクトパス100を利用できないもののX2 GW3がリレー能力を有することから、ソース(H)eNB1は、X2 GW3を介したDLフォワーディングが可能であると判断し、したがって(X2 GW3を介して)DLフォワーディングを行うことをターゲット(H)eNB2に知らせるために、DL Forwarding IEを設定する。
図8に示されたケース4は、ダイレクトパス100が利用不可であり、且つX2 GW3がリレー能力を有していない場合である。したがって、ケース4では、ソース(H)eNB1は、Direct Path Unavailability IEを設定し、DL Forwarding IEを設定しない。
図8の例では、X2 GW3は、Direct Path Unavailability IEおよびDL Forwarding IEを参照し、これらが共に設定されている場合にDLデータフォワーディングに関するU-Plane(X2-U)リレーを実施すればよい。したがって、図7の例と同様に、図8のケース3のみDLデータフォワーディングに関するU-Plane(X2-U)リレーが実施され、図8のケース1、2及び4ではDLデータフォワーディングに関するU-Plane(X2-U)リレーが実施されない。
続いて以下では、ターゲット(H)eNB2およびX2 GW3の動作とその起動条件の具体例について図9及び図10を用いて説明する。図9は、ターゲット(H)eNB2およびX2 GW3の動作とその起動条件の組み合せの一例を示すテーブルである。ターゲット(H)eNB2に関する図9の例は、ソース(H)eNB1に関する図7の例と対応する。したがって、図9のケース3のみULデータフォワーディングに関するU-Plane(X2-U)リレーが実施され、図9のケース1、2及び4ではULデータフォワーディングに関するU-Plane(X2-U)リレーが実施されない。
図10の例では、ターゲット(H)eNB2からX2 GW3に対する暗示的なリレー要求(又はリレー表示)が、Direct Path Unavailability IEおよびUL GTP Tunnel Endpoint IEの組み合せとされている。図10に示されたUL GTP Tunnel Endpoint IEは、現在の3GPP仕様においてX2AP: Handover Request Acknowledgeメッセージに含まれているUL GTP Tunnel Endpoint IEであってもよいし、X2AP Message Transferメッセージに新たに追加される情報要素であってもよい。
ターゲット(H)eNB2に関する図10の例は、DL Forwarding IEとUL GTP Tunnel Endpoint IEの違いを除いて、ソース(H)eNB1に関する図8の例に対応する。すなわち、図10の例では、X2 GW3は、Direct Path Unavailability IEおよびUL GTP Tunnel Endpoint IEを参照し、これらが共に設定されている場合にULデータフォワーディングに関するU-Plane(X2-U)リレーを実施すればよい。したがって、図10のケース3のみULデータフォワーディングに関するU-Plane(X2-U)リレーが実施され、図10のケース1、2及び4ではULデータフォワーディングに関するU-Plane(X2-U)リレーが実施されない。
図7〜図10は、ハンドオーバにおける (H)eNB1、(H)eNB2、及びX2 GW3の動作の具体例を示した。しかしながら、既に説明したことから理解されるように、図7〜図10を用いて説明された(H)eNB1、(H)eNB2、及びX2 GW3の動作の具体例は、Dual connectivityをサポートするUEに関するベアラ確立を行う際に適用されてもよい。
図7〜図10を用いて説明された例では、(H)eNB1及び(H)eNB2は、U-plane(X2-U)リレーを利用するか否か(又は要求するか否か)を判定する際に、X2 GW3のリレー能力の有無を考慮する。X2 GW3のリレー能力の有無は、オペレータによって、つまりoperations, administration and maintenance(OAM)によって、(H)eNBs1及び2に予め設定されてもよい。これに代えて、X2 GW3は、自身のリレー能力の有無を(H)eNBs1及び2に知らせてもよい。すなわち、X2 GW3は、自身のリレー能力の有無を示す情報要素(IE)を含むシグナリングメッセージを(H)eNBs1及び2に送信してもよい。いくつかの実装において、図11及び図12に示されるように、X2 GW3は、(H)eNBs1及び2をX2 GW3に登録する手順において、自身のリレー能力を(H)eNBs1及び2に知らせてもよい。
図11は、リレー能力の有無をX2 GW3から(H)eNBs1及び2に通知する手順の一例(処理1100)を示すシーケンス図である。ブロック1101では、(H)eNBs1(2)は、登録要求をX2 GW3に送信する((H)eNB registration)。当該登録要求は、登録要求に含まれる送信元(H)eNBの識別子(i.e., Global eNB ID)と登録要求の送信に使用された送信元(H)eNBのTNLアドレス(e.g., IPアドレス)のマッピングを保存する。そして、ブロック1102では、X2 GW3は、登録要求に対する応答を送信する((H)eNB registration response)。当該応答は、X2 GW3のリレー能力の有無を示す情報要素(U-plane Relay Capability)を含む。(H)eNBs1(2)は、ブロック1102での応答を受信することにより、X2 GW3のU-plane(X2-U)リレー能力の有無を認識する。
図12は、リレー能力の有無をX2 GW3から(H)eNBs1及び2に通知する手順の他の例(処理1200)を示すシーケンス図である。3GPP Release 12では、(H)eNBのX2 GWへの登録のために、X2AP Message Transferメッセージが使用される。図12は、3GPP Release 12と同様にX2AP Message Transferメッセージを利用する例を示している。すなわち、ブロック1201では、登録を要求する(H)eNB1(2)は、RNL Header IE内にSource (H)eNB IDを含むが、RNL Header IE内にTarget (H)eNB IDを含まず、かつX2AP Messageを含まないX2AP Message Transferメッセージを送信する。ブロック1202では、X2 GW3は、変更された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)eNBs1(2)は、ブロック1202でのX2AP Message Transferメッセージを受信することにより、X2 GW3のU-plane(X2-U)リレー能力の有無を認識する。
図13A及び図13Bは、本実施形態に係るX2ハンドオーバ手順の一例(処理1300)を示すシーケンス図である。図13A及び図13Bに示された手順は、ソース(H)eNB1からターゲット(H)eNB2へのユーザデータパケットのフォワーディングがX2 GW3を介して行われること(ブロック1307及び1308)を除いて、通常のX2 GWを介するX2ハンドオーバ手順と同様である。すなわち、ブロック1301では、ソース(H)eNB1は、Handover Requestメッセージを運ぶX2AP Message TransferメッセージをX2 GW3に送信する。既に説明したように、当該X2AP Message Transferメッセージは、U-plane(X2-U)リレーの要否を明示的又は暗示的に示す情報要素を含んでもよい。ブロック1302では、X2 GW3は、Handover Requestメッセージを運ぶX2AP Message Transferメッセージをターゲット(H)eNB2に転送する。既に説明したように、X2 GW3は、U-plane(X2-U)リレーを行うか否かに応じて、ブロック1302でのX2AP Message Transferメッセージ内の情報要素を更新してもよいし、情報要素を追加してもよい。
ブロック1303では、ターゲット(H)eNB2は、Handover Request Acknowledgeメッセージを運ぶX2AP Message TransferメッセージをX2 GW3に送信する。既に説明したように、当該X2AP Message Transferメッセージは、U-plane(X2-U)リレーの要否を明示的又は暗示的に示す情報要素を含んでもよい。ブロック1304では、X2 GW3は、Handover Request Acknowledgeメッセージを運ぶX2AP Message Transferメッセージをソース(H)eNB1に転送する。既に説明したように、X2 GW3は、U-plane(X2-U)リレーを行うか否かに応じて、ブロック1304でのX2AP Message Transferメッセージ内の情報要素を更新してもよいし、情報要素を追加してもよい。
ソース(H)eNB1は、Handover Request Acknowledgeメッセージの受信に応答して、図示されていないUEにハンドオーバ指示(Handover Command)を送信する。ブロック1305では、ソース(H)eNB1は、SN Status Transferメッセージを運ぶX2AP Message TransferメッセージをX2 GW3に送信する。SN Status Transferメッセージは、UEへの送達が完了してないuplink/downlink Packet Data Convergence Protocol(PDCP) PDUのSequence Number(SN)を示す。ブロック1306では、X2 GW3は、SN Status Transferメッセージを運ぶX2AP Message Transferメッセージをターゲット(H)eNB2に転送する。
ブロック1307及び1308では、ソース(H)eNB1は、UEへの送達が完了していないuplink/downlink ユーザデータパケットを、X2 GW3を介してターゲット(H)eNB2にフォワーディングする。すなわち、ブロック1307では、ソース(H)eNB1は、ソース(H)eNB1とX2 GW3の間のGTP-Uトンネルを介して、uplink/downlink ユーザデータパケットをカプセル化しているG-PDUをX2 GW3に送信する。ブロック1308では、X2 GW3は、ターゲット(H)eNB2とX2 GW3の間のGTP-Uトンネルを介して、ソース(H)eNB1から受信したG-PDUをターゲット(H)eNB2に転送する。
ブロック1307及び1308のデータフォワーディングでは、X2GW3は、ソース(H)eNB1から受信したG-PDUに付与されているソースTNLアドレス(i.e., ソース(H)eNB1のTNLアドレス)をX2GW3のTNLアドレスによって更新し、ソースTEID(i.e., ソース(H)eNB1のTEID)をX2GW3のTEIDによって更新する。さらに、X2GW3は、ソース(H)eNB1から受信したG-PDUに付与されているターゲットTNLアドレス(i.e., X2GW3のTNLアドレス)をターゲット(H)eNB2のTNLアドレスによって更新し、ターゲットTEID(i.e., X2GW3のTEID)をターゲット(H)eNB2のTEIDによって更新する。
ブロック1309では、ターゲット(H)eNB2は、UEからハンドオーバ確認(Handover Confirm)メッセージを受信する。これにより、UEは、ターゲット(H)eNB2にULユーザデータパケットを送信することができ、DLユーザデータパケットをターゲット(H)eNB2から受信できる。
ブロック1310では、ターゲット(H)eNB2は、UEのサービングセルの変更をEPC4に知らせるとともにEvolved Packet System (EPS)ベアラの経路変更を要求するために、S1AP: Path Switch RequestメッセージをEPC4(つまり、Mobility Management Entity(MME)5)に送信する。MME5は、図示していないServing Gateway(S−GW)とシグナルし、EPSベアラの経路(つまり、S1ベアラの経路)を修正する。ブロック1311では、MME5は、S1AP: Path Switch Request Acknowledgeメッセージをターゲット(H)eNB2に送信する。ブロック1312では、Path Switch Request Acknowledgeメッセージの受信に応答して、ターゲット(H)eNB2は、UE Context Releaseメッセージを運ぶX2AP Message TransferメッセージをX2 GW3に送信する。ブロック1313では、X2 GW3は、UE Context Releaseメッセージを運ぶX2AP Message Transferメッセージをソース(H)eNB1に転送する。ソース(H)eNB1は、UE Context Releaseメッセージの受信に応答して、UEに割り当てた無線リソースを解放する。
なお、ターゲット(H)eNB2は、UE Context Releaseメッセージの送信(ブロック1312)に応答して、データフォワーディングのためのGTP-Uトンネル設定を開放してもよい。X2 GW3は、UE Context Releaseメッセージを運ぶX2AP Message Transferメッセージの受信(ブロック1312)に応答して、データフォワーディングのためのGTP-Uトンネル設定を開放してもよい。ソース(H)eNB1は、UE Context Releaseメッセージの受信(ブロック1313)に応答して、データフォワーディングのためのGTP-Uトンネル設定を開放してもよい。
続いて以下では、X2AP Message Transferメッセージの変更(modification)の具体例について、図14並びに図15A及び図15Bを用いて説明する。図14は、X2AP Message Transferメッセージの変更の一例を示している。“U-Plane Relay Capability” IEは、U-plane(X2-U)リレー能力の有無を(H)eNBs1及び2に知らせるためにX2 GW3によって使用される。“Direct Path Unavailability” IEは、ダイレクトパス100の利用可否をX2 GW3に知らせるために(H)eNBs1及び2によって使用される。“E-RABs To Be Setup List” IEは、X2 GW3のEndpoint設定を(H)eNBs1及び2に知らせるためにX2 GW3によって使用される。
“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 GW3のEndpoint設定(つまり、TNLアドレス及びTEID)を示す。“DL GTP Tunnel Endpoint” IEは、DLデータ(DL PDUs)フォワーディングのためのX2トランスポートベアラに関するX2 GW3のEndpoint設定(つまり、TNLアドレス及びTEID)を示す。
図15A及び図15Bは、X2AP Message Transferメッセージの変更の他の例を示している。図15Aに示されているように、X2AP Message Transferメッセージは、“Message Type of X2AP Message” IEを含むように拡張されてもよい。“Message Type of X2AP Message” IEは、X2AP Message Transferメッセージによって運ばれるX2APメッセージの種別を示す。これにより、X2 GW3は、必要なX2APメッセージのみ参照又はデコードするように動作することができる。すなわち、“Message Type of X2AP Message” IE がHandover Requestメッセージ又はHandover Request Acknowledgeメッセージを示す場合にのみ、X2AP Message Transferメッセージ内の“X2AP message” IEを参照又はデコードしてもよい。
さらに又はこれに代えて、図15Bに示されるように、X2AP Message Transferメッセージは、“DL Forwarding” IEを含むように拡張されてもよい。“DL Forwarding” IEは、“X2AP message” IEがHandover Requestメッセージを運ぶ場合に、ソース(H)eNB1によって使用される。“DL Forwarding” IEは、“X2AP message” IE内のHandover Requestメッセージに含まれる“DL Forwarding” IEと同じ内容を示す。これにより、X2 GW3は、“DL Forwarding” IE を確認するために“X2AP message” IE内のHandover Requestメッセージをデコード又は参照する必要がなくなる。
これと同じ思想に従って、X2AP Message Transferメッセージは、図15Bに示された“E-RAB Level QoS Parameters” IEを含むように拡張されてもよい。“E-RAB Level QoS Parameters” IEは、“X2AP message” IEがHandover Requestメッセージを運ぶ場合に、ソース(H)eNB1によって使用される。“E-RAB Level QoS Parameters” IEは、“X2AP message” IE内のHandover Requestメッセージに含まれる“E-RAB Level QoS Parameters” IEと同じ内容を示す。
これと同じ思想に従って、図15Bに示された“E-RAB ID” IEは、“X2AP message” IEがHandover Requestメッセージを運ぶ場合に、ソース(H)eNB1によって使用されてもよい。この場合、“E-RAB ID” IEは、“X2AP message” IE内のHandover Requestメッセージに含まれる“E-RAB ID” IEと同じ内容を示す。さらに、図15Bに示された“E-RAB ID” IEは、“X2AP message” IEがHandover Request Acknowledgeメッセージを運ぶ場合に、ターゲット(H)eNB2によって使用されてもよい。この場合、“E-RAB ID” IEは、“X2AP message” IE内のHandover Request Acknowledgeメッセージに含まれる“E-RAB ID” IEと同じ内容を示す。
これと同じ思想に従って、図15Bに示された“DL GTP Tunnel Endpoint” IE及び“UL GTP Tunnel Endpoint” IEは、“X2AP message” IEがHandover Request Acknowledgeメッセージを運ぶ場合に、ターゲット(H)eNB2によって使用されてもよい。この場合、“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 GW3が参照しなければならない一部の情報要素をX2AP Message Transferメッセージに含めることによって以下の利点がある。すなわち、X2 GW3は、X2AP Message IEを透過的に転送すればよく、X2AP Message IEの参照又はデコードを行う必要がない。もしX2 GW3が常にX2AP Message IE の参照又はデコードすると、X2 GW3の処理能力を大きく消費するかもしれないし、X2 GW3のプロトコルバージョンと(H)eNB間のX2APプロトコルバージョンが異なることでプロトコルエラーが発生するかもしれない。X2 GW3は、X2AP Message IEを透過的に転送することで、これらの問題の発生を回避することができる。
なお、図15A及び図15Bに示すように、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のうち少なくとも1つ)は、暗示的なリレー要求(又はリレー表示)として利用されてもよい。すなわち、X2 GW3は、X2AP Message Transferメッセージが追加された情報要素を含むか否かに応じて、(H)eNB1又は2からのリレー要求の有無を検出してもよい。この場合、X2AP Message Transferメッセージは、“Direct Path Unavailability” IE(又はその他の明示的又は暗示的なリレー要求)を含まなくてもよい。
<第2の実施形態>
本実施形態では、X2 GW3のX2-U TNLアドレス(e.g., IPアドレス)をターゲット(H)eNB2に知らせる手順の具体例を説明する。第1の実施形態では、X2 GW3のX2-U TNLアドレスがOAMによってターゲット(H)eNB2に設定される例、及びX2AP Message Transferメッセージを用いてX2 GW3からターゲット(H)eNB2にX2 GW3のX2-U TNLアドレスが通知される例を示した。これらに代えて、改良されたEnhanced TNL Address Discovery手順が使用されてもよい。
Enhanced TNL Address Discovery手順は、非特許文献1のセクション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アドレスを転送する。これにより、2つの(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手順が変更される。
図16は、本実施形態に係るEnhanced TNL Address Discovery手順の一例(処理1600)を示すシーケンス図である。図16の手順は、X2 GW U-plane アドレス(X2-U TNLアドレス)が送られる点を除いて、既存のEnhanced TNL Address Discovery手順と同様である。すなわち、ブロック1601では、ソース(H)eNB1は、S1AP: eNB CONFIGURATION TRANSFERメッセージをMME5に送信する。当該eNB CONFIGURATION TRANSFERメッセージは、X2 GW3のU-plane アドレス(X2-U TNLアドレス)を含む。ブロック1602では、MME5は、S1AP: MME CONFIGURATION TRANSFERメッセージをターゲット(H)eNB2に送信する。当該MME CONFIGURATION TRANSFERメッセージは、ソース(H)eNB1から受信したX2 GW3のU-plane アドレス(X2-U TNLアドレス)を含む。
ブロック1603では、ターゲット(H)eNB2は、受信したX2 GW3のU-plane アドレス(X2-U TNLアドレス)をACLに追加する。ブロック1604では、ターゲット(H)eNB2は、S1AP: eNB CONFIGURATION TRANSFERメッセージをMME5に送信する。当該eNB CONFIGURATION TRANSFERメッセージは、ソース(H)eNB1に対する応答である。ブロック1605では、MME5は、S1AP: MME CONFIGURATION TRANSFERメッセージをソース(H)eNB1に送信する。MME CONFIGURATION TRANSFERメッセージは、ターゲット(H)eNB2からeNB CONFIGURATION TRANSFERメッセージにより受信した情報要素(e.g., ターゲット(H)eNB2がソース(H)eNB1から受信したX2 GW3のU-plane アドレス)を含む。
図17A及び図17Bは、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メッセージに含まれる。図17Bに示されているように、“X2 TNL Configuration Info” IEは、インダイレクトX2 U-plane エンドポイントに関するTNLアドレス(つまり、X2 GW3のX2-U TNLアドレス)を示す“Transport Layer Address” IEを含むように拡張されてもよい。
最後に、上述の複数の実施形態に係る(H)eNB1、(H)eNB2、及びX2 GW3の構成例について説明する。図18は、(H)eNB1の構成例を示すブロック図である。(H)eNB2も、図18の構成と同様の構成を有してもよい。図18を参照すると、(H)eNB1は、RFトランシーバ1801、ネットワークインターフェース1803、プロセッサ1804、及びメモリ1805を含む。RFトランシーバ1801は、UEsと通信するためにアナログRF信号処理を行う。RFトランシーバ1801は、複数のトランシーバを含んでもよい。RFトランシーバ1801は、アンテナ1802及びプロセッサ1804と結合される。RFトランシーバ1801は、変調シンボルデータ(又はOFDMシンボルデータ)をプロセッサ1804から受信し、送信RF信号を生成し、送信RF信号をアンテナ1802に供給する。また、RFトランシーバ1801は、アンテナ1802によって受信された受信RF信号に基づいてベースバンド受信信号を生成し、これをプロセッサ1804に供給する。
ネットワークインターフェース1803は、ネットワークノード(e.g., MMEおよびS/P-GW)と通信するために使用される。ネットワークインターフェース1803は、例えば、IEEE 802.3 seriesに準拠したネットワークインターフェースカード(NIC)を含んでもよい。
プロセッサ1804は、無線通信のためのデジタルベースバンド信号処理を含むデータプレーン処理とコントロールプレーン処理を行う。例えば、LTEおよびLTE-Advancedの場合、プロセッサ1804によるデジタルベースバンド信号処理は、PDCPレイヤ、RLCレイヤ、MACレイヤ、およびPHYレイヤの信号処理を含んでもよい。さらに、プロセッサ1804による信号処理は、X2-Uインタフェース及びS1-UインタフェースでのGTP-U・UDP/IPレイヤの信号処理を含んでもよい。また、プロセッサ1804によるコントロールプレーン処理は、X2APプロトコル、S1-MMEプロトコルおよびRRCプロトコルの処理を含んでもよい。
プロセッサ1804は、複数のプロセッサを含んでもよい。例えば、プロセッサ1804は、プロセッサ1804は、デジタルベースバンド信号処理を行うモデム・プロセッサ(e.g., DSP)、X2-Uインタフェース及びS1-UインタフェースでのGTP-U・UDP/IPレイヤの信号処理を行うプロセッサ(e.g., DSP)、及びコントロールプレーン処理を行うプロトコルスタック・プロセッサ(e.g., CPU又はMPU)を含んでもよい。
メモリ1805は、揮発性メモリ及び不揮発性メモリの組み合わせによって構成される。メモリ1805は、物理的に独立した複数のメモリデバイスを含んでもよい。揮発性メモリは、例えば、Static Random Access Memory(SRAM)若しくはDynamic RAM(DRAM)又はこれらの組み合わせである。不揮発性メモリは、マスクRead Only Memory(MROM)、Electrically Erasable Programmable ROM(EEPROM)、フラッシュメモリ、若しくはハードディスクドライブ、又はこれらの任意の組合せである。メモリ1805は、プロセッサ1804から離れて配置されたストレージを含んでもよい。この場合、プロセッサ1804は、ネットワークインターフェース1803又は図示されていないI/Oインタフェースを介してメモリ1805にアクセスしてもよい。
メモリ1805は、上述の複数の実施形態で説明された(H)eNB1による処理を行うための命令群およびデータを含むソフトウェアモジュール(コンピュータプログラム)を格納してもよい。いくつかの実装において、プロセッサ1804は、当該ソフトウェアモジュールをメモリ1805から読み出して実行することで、上述の実施形態で説明された(H)eNB1の処理を行うよう構成されてもよい。
図19は、X2 GW3の構成例を示すブロック図である。図16を参照すると、X2 GW3は、ネットワークインターフェース1901、プロセッサ1902、及びメモリ1903を含む。ネットワークインターフェース19601は、ネットワークノード(e.g., (H)eNB1及び(H)eNB2)と通信するために使用される。ネットワークインターフェース1901は、例えば、IEEE 802.3 seriesに準拠したネットワークインターフェースカード(NIC)を含んでもよい。
プロセッサ1902は、メモリ1903からソフトウェア(コンピュータプログラム)を読み出して実行することで、上述の実施形態において説明されたX2 GW3の処理を行う。プロセッサ1902は、例えば、マイクロプロセッサ、MPU、又はCPUであってもよい。プロセッサ1902は、複数のプロセッサを含んでもよい。
メモリ1903は、揮発性メモリ及び不揮発性メモリの組み合わせによって構成される。メモリ1903は、プロセッサ1902から離れて配置されたストレージを含んでもよい。この場合、プロセッサ1902は、図示されていないI/Oインタフェースを介してメモリ1903にアクセスしてもよい。
図18及び図19を用いて説明したように、上述の実施形態に係る(H)eNB1、(H)eNB2、及びX2 GW3が有するプロセッサの各々は、図面を用いて説明されたアルゴリズムをコンピュータに行わせるための命令群を含む1又は複数のプログラムを実行する。このプログラムは、様々なタイプの非一時的なコンピュータ可読媒体(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(非特許文献1)に記載されている。
さらに、上述の実施形態は、既に説明したように、Dual ConnectivityのケースにおいてMaster eNB(MeNB)とSecondary eNB(SeNB)の間のユーザデータパケットの転送のためにX2ゲートウェイを使用する場合に適用されることができる。Dual Connectivityは、3GPP TS36.300(非特許文献1)に記載されている。
さらに、上述した実施形態は本件発明者により得られた技術思想の適用に関する例に過ぎない。すなわち、当該技術思想は、上述した実施形態のみに限定されるものではなく、種々の変更が可能であることは勿論である。
例えば、上記の実施形態の一部又は全部は、以下の付記のようにも記載され得るが、以下には限られない。
(付記1)
基地局装置により行われる方法であって、
無線端末宛て又は前記無線端末からのデータパケットを基地局間ゲートウェイが前記基地局装置と他の基地局の間で中継するリレー処理が必要とされる否かを決定する際に、前記基地局装置と前記他の基地局の間のダイレクトパスの利用可否を考慮することを備える、
方法。
(付記2)
基地局装置により行われる方法であって、
無線端末宛て又は前記無線端末からのデータパケットを基地局間ゲートウェイが前記基地局装置と他の基地局の間で中継するリレー処理が必要とされる否かを決定する際に、前記基地局間ゲートウェイの前記リレー処理の能力を考慮することを備える、
方法。
(付記3)
基地局装置により行われる方法であって、
第1の情報要素を基地局間ゲートウェイに送信することを備え、
前記第1の情報要素は、前記基地局装置と他の基地局の間のダイレクトパスの利用可否を示す、
方法。
(付記4)
基地局間ゲートウェイ装置によって行われる方法であって、
リレー処理の能力を基地局に通知することを備え、
前記リレー処理は、無線端末宛て又は前記無線端末からのデータパケットを前記基地局間ゲートウェイ装置によって第1の基地局と第2の基地局の間で中継することを含む、
方法。
(付記5)
基地局間ゲートウェイ装置であって、
メモリと、
前記メモリに結合された少なくとも1つのプロセッサと、
を備え、
前記少なくとも1つのプロセッサは、第1の情報要素を第1の基地局及び第2の基地局の少なくとも一方から受信するよう構成され、
前記第1の情報要素は、無線端末宛て又は前記無線端末からのデータパケットを前記基地局間ゲートウェイ装置によって前記第1の基地局と前記第2の基地局の間で中継するリレー処理が必要とされる否かを明示的または暗示的に示す、
基地局間ゲートウェイ装置。
(付記6)
前記第1の情報要素は、前記第1の基地局と前記第2の基地局の間のダイレクトパスの利用可否を明示的に示す、
付記5に記載の基地局間ゲートウェイ装置。
(付記7)
前記少なくとも1つのプロセッサは、前記第1の基地局から前記第2の基地局への前記無線端末のハンドオーバの際に、前記第1の情報要素を受信するよう構成されている、
付記5又は6に記載の基地局間ゲートウェイ装置。
(付記8)
前記少なくとも1つのプロセッサは、前記リレー処理の能力を示す第2の情報要素を前記第1の基地局及び前記第2の基地局の少なくとも一方に送信するよう構成されている、
付記5〜7のいずれか1項に記載の基地局間ゲートウェイ装置。
(付記9)
前記少なくとも1つのプロセッサは、前記第1の基地局及び前記第2の基地局の少なくとも一方を前記基地局間ゲートウェイ装置に登録する手順において、前記第2の情報要素を送信するよう構成されている、
付記8に記載の基地局間ゲートウェイ装置。
(付記10)
前記少なくとも1つのプロセッサは、前記第1の情報要素に基づいて、前記リレー処理を行うか否かを決定するよう構成されている、
付記5〜9のいずれか1項に記載の基地局間ゲートウェイ装置。
(付記11)
前記少なくとも1つのプロセッサは、前記基地局間ゲートウェイ装置によって前記リレー処理が行われる場合に、前記第1の基地局から前記第2の基地局へのハンドオーバ要求メッセージを運ぶ第1の転送メッセージに、前記基地局間ゲートウェイ装置と前記第2の基地局の間で前記データパケットを転送するための第1のトランスポートベアラに関する前記基地局間ゲートウェイ装置のエンドポイント設定を含めるよう構成されている、
付記5〜10のいずれか1項に記載の基地局間ゲートウェイ装置。
(付記12)
前記エンドポイント設定は、前記第2の基地局においてパケットフィルタを更新するために使用される、
付記11に記載の基地局間ゲートウェイ装置。
(付記13)
前記エンドポイント設定は、前記基地局間ゲートウェイ装置のトランスポートレイヤ・アドレスを含む、
付記11又は12に記載の基地局間ゲートウェイ装置。
(付記14)
前記エンドポイント設定は、ダンリンクフォワーディングのためのエンドポイント設定及びアップリンクフォワーディングのためのエンドポイント設定を含む、
付記11〜13のいずれか1項に記載の基地局間ゲートウェイ装置。
(付記15)
前記少なくとも1つのプロセッサは、前記基地局間ゲートウェイ装置によって前記リレー処理が行われる場合に、前記第2の基地局から前記第1の基地局へのハンドオーバ要求承認メッセージを運ぶ第2の転送メッセージに、前記基地局間ゲートウェイ装置と前記第1の基地局の間で前記データパケットを転送するための第2のトランスポートベアラに関する前記基地局間ゲートウェイ装置のエンドポイント設定を含めるよう構成されている、
付記5〜14のいずれか1項に記載の基地局間ゲートウェイ装置。
(付記16)
基地局装置により行われる方法であって、
第1の情報要素を基地局間ゲートウェイに送信することを備え、
前記第1の情報要素は、無線端末宛て又は前記無線端末からのデータパケットを前記基地局間ゲートウェイが前記基地局装置と他の基地局の間で中継するリレー処理が必要とされる否かを明示的または暗示的に示す、
方法。
(付記17)
前記第1の情報要素は、前記基地局装置と前記他の基地局の間のダイレクトパスの利用可否を明示的に示す、
付記16に記載の方法。
(付記18)
前記送信することは、前記基地局装置から前記他の基地局または前記他の基地局から前記基地局装置への前記無線端末のハンドオーバの際に、前記第1の情報要素を送信することを含む、
付記16又は17に記載の方法。
(付記19)
前記送信することは、前記他の基地局へのハンドオーバ要求メッセージ又はハンドオーバ要求承認メッセージを運ぶために前記基地局間ゲートウェイに送信される転送メッセージに前記第1の情報要素を含めることを含む、
付記18に記載の方法。
(付記20)
前記第1の情報要素は、前記リレー処理が必要とされることを暗示的に示すために、前記転送メッセージによって運ばれる前記ハンドオーバ要求メッセージ又は前記ハンドオーバ要求承認メッセージに包含されている第2の情報要素と同じ内容を示す、
付記19に記載の方法。
(付記21)
前記転送メッセージによって運ばれる前記ハンドオーバ要求メッセージ又は前記ハンドオーバ要求承認メッセージに包含されている第2の情報要素と同じ内容の第3の情報要素を前記転送メッセージに含めることをさらに備える、
付記19に記載の方法。
(付記22)
前記第2の情報要素は、前記データパケットのフォワーディングの要否を示す情報要素、前記無線端末のために設定されたベアラの識別子を示す情報要素、および前記ベアラのQuality of Service(QoS)パラメータを示す情報要素のうち少なくとも1つを含む、
付記20又は21に記載の方法。
(付記23)
前記転送メッセージによって運ばれる基地局間シグナリングメッセージの種別を示す情報要素を前記転送メッセージに含めることをさらに備える、
付記19〜22のいずれか1項に記載の方法。
(付記24)
前記データパケットの送信又は受信のために、前記基地局間ゲートウェイによる前記リレー処理を利用するか否かを決定すること、及び
前記リレー処理が利用されない場合に、前記基地局装置と前記他の基地局の間のダイレクトパスを用いて前記データパケットをフォワーディングすること、
をさらに備える、
付記16〜23のいずれか1項に記載の方法。
(付記25)
基地局間ゲートウェイ装置によって行われる方法であって、
第1の情報要素を第1の基地局及び第2の基地局の少なくとも一方から受信することを備え、
前記第1の情報要素は、無線端末宛て又は前記無線端末からのデータパケットを前記基地局間ゲートウェイ装置によって前記第1の基地局と前記第2の基地局の間で中継するリレー処理が必要とされる否かを明示的または暗示的に示す、
方法。
(付記26)
前記第1の情報要素は、前記第1の基地局と前記第2の基地局の間のダイレクトパスの利用可否を明示的に示す、
付記25に記載の方法。
(付記27)
前記受信することは、前記第1の基地局から前記第2の基地局への前記無線端末のハンドオーバの際に、前記第1の情報要素を受信することを含む、
付記25又は26に記載の方法。
(付記28)
前記リレー処理の能力を示す第2の情報要素を前記第1の基地局及び前記第2の基地局の少なくとも一方に送信することをさらに備える、
付記25〜27のいずれか1項に記載の方法。
(付記29)
前記送信することは、前記第1の基地局及び前記第2の基地局の少なくとも一方を前記基地局間ゲートウェイ装置に登録する手順において、前記第2の情報要素を送信することを含む、
付記28に記載の方法。
(付記30)
前記第1の情報要素に基づいて、前記リレー処理を行うか否かを決定することをさらに備える、
付記25〜29のいずれか1項に記載の方法。
(付記31)
前記基地局間ゲートウェイ装置によって前記リレー処理が行われる場合に、前記第1の基地局から前記第2の基地局へのハンドオーバ要求メッセージを運ぶ第1の転送メッセージに、前記基地局間ゲートウェイ装置と前記第2の基地局の間で前記データパケットを転送するための第1のトランスポートベアラに関する前記基地局間ゲートウェイ装置のエンドポイント設定を含めることをさらに備える、
付記25〜30のいずれか1項に記載の方法。
(付記32)
前記エンドポイント設定は、前記第2の基地局においてパケットフィルタを更新するために使用される、
付記31に記載の方法。
(付記33)
前記エンドポイント設定は、前記基地局間ゲートウェイ装置のトランスポートレイヤ・アドレスを含む、
付記31又は32に記載の方法。
(付記34)
前記エンドポイント設定は、ダンリンクフォワーディングのためのエンドポイント設定及びアップリンクフォワーディングのためのエンドポイント設定を含む、
付記31〜33のいずれか1項に記載の方法。
(付記35)
前記少なくとも1つのプロセッサは、前記基地局間ゲートウェイ装置によって前記リレー処理が行われる場合に、前記第2の基地局から前記第1の基地局へのハンドオーバ要求承認メッセージを運ぶ第2の転送メッセージに、前記基地局間ゲートウェイ装置と前記第1の基地局の間で前記データパケットを転送するための第2のトランスポートベアラに関する前記基地局間ゲートウェイ装置のエンドポイント設定を含めることをさらに備える、
付記25〜34のいずれか1項に記載の方法。
この出願は、2015年3月20日に出願された日本出願特願2015−058155を基礎とする優先権を主張し、その開示の全てをここに取り込む。
1 (H)eNB
2 (H)eNB
3 X2 Gateway(X2 GW)
4 Evolved Packet Core(EPC)
5 Mobility Management Entity(MME)
1804 プロセッサ
1805 メモリ
1902 プロセッサ
1903 メモリ

Claims (10)

  1. 基地局装置であって、
    メモリと、
    前記メモリに結合された少なくとも1つのプロセッサと、
    を備え、
    前記少なくとも1つのプロセッサは、第1の情報要素を基地局間ゲートウェイに送信するよう構成され、
    前記第1の情報要素は、無線端末宛て又は前記無線端末からのデータパケットを前記基地局間ゲートウェイが前記基地局装置と他の基地局の間で中継するリレー処理が必要とされる否かを明示的または暗示的に示す、
    基地局装置。
  2. 前記第1の情報要素は、前記基地局装置と前記他の基地局の間のダイレクトパスの利用可否を明示的に示す、
    請求項1に記載の基地局装置。
  3. 前記少なくとも1つのプロセッサは、前記基地局装置から前記他の基地局または前記他の基地局から前記基地局装置への前記無線端末のハンドオーバの際に、前記第1の情報要素を送信するよう構成されている、
    請求項1又は2に記載の基地局装置。
  4. 前記少なくとも1つのプロセッサは、前記他の基地局へのハンドオーバ要求メッセージ又はハンドオーバ要求承認メッセージを運ぶために前記基地局間ゲートウェイに送信される転送メッセージに前記第1の情報要素を含めるよう構成されている、
    請求項3に記載の基地局装置。
  5. 前記第1の情報要素は、前記リレー処理が必要とされることを暗示的に示すために、前記転送メッセージによって運ばれる前記ハンドオーバ要求メッセージ又は前記ハンドオーバ要求承認メッセージに包含されている第2の情報要素と同じ内容を示す、
    請求項4に記載の基地局装置。
  6. 前記少なくとも1つのプロセッサは、前記転送メッセージによって運ばれる前記ハンドオーバ要求メッセージ又は前記ハンドオーバ要求承認メッセージに包含されている第2の情報要素と同じ内容の第3の情報要素を前記転送メッセージに含めるよう構成されている、
    請求項4に記載の基地局装置。
  7. 前記第2の情報要素は、前記データパケットのフォワーディングの要否を示す情報要素、前記無線端末のために設定されたベアラの識別子を示す情報要素、および前記ベアラのQuality of Service(QoS)パラメータを示す情報要素のうち少なくとも1つを含む、
    請求項5又は6に記載の基地局装置。
  8. 基地局間ゲートウェイ装置であって、
    メモリと、
    前記メモリに結合された少なくとも1つのプロセッサと、
    を備え、
    前記少なくとも1つのプロセッサは、第1の情報要素を第1の基地局及び第2の基地局の少なくとも一方から受信するよう構成され、
    前記第1の情報要素は、無線端末宛て又は前記無線端末からのデータパケットを前記基地局間ゲートウェイ装置によって前記第1の基地局と前記第2の基地局の間で中継するリレー処理が必要とされる否かを明示的または暗示的に示す、
    基地局間ゲートウェイ装置。
  9. 基地局装置により行われる方法であって、
    第1の情報要素を基地局間ゲートウェイに送信することを備え、
    前記第1の情報要素は、無線端末宛て又は前記無線端末からのデータパケットを前記基地局間ゲートウェイが前記基地局装置と他の基地局の間で中継するリレー処理が必要とされる否かを明示的または暗示的に示す、
    方法。
  10. 基地局装置により行われる方法をコンピュータに行わせるためのプログラムであって、
    前記方法は、第1の情報要素を基地局間ゲートウェイに送信することを備え、
    前記第1の情報要素は、無線端末宛て又は前記無線端末からのデータパケットを前記基地局間ゲートウェイが前記基地局装置と他の基地局の間で中継するリレー処理が必要とされる否かを明示的または暗示的に示す、
    プログラム
JP2017507123A 2015-03-20 2015-12-22 基地局装置および基地局間ゲートウェイ装置 Active JP6384591B2 (ja)

Applications Claiming Priority (3)

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

Publications (2)

Publication Number Publication Date
JPWO2016151653A1 JPWO2016151653A1 (ja) 2017-12-28
JP6384591B2 true JP6384591B2 (ja) 2018-09-05

Family

ID=56978274

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2017507123A Active JP6384591B2 (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)

Families Citing this family (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB2512659A (en) * 2013-04-05 2014-10-08 Nec Corp Communication system
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
CN109792683B (zh) 2016-09-29 2022-08-02 英国电讯有限公司 蜂窝电信网络、基站和在蜂窝电信网络中操作基站的方法
CN109804672B (zh) 2016-09-29 2022-05-10 英国电讯有限公司 蜂窝电信网络
CN110651532B (zh) 2017-03-24 2023-03-10 瑞典爱立信有限公司 第一无线电网络节点(rnn)、第二rnn及其中的方法
WO2018206629A1 (en) * 2017-05-09 2018-11-15 Telefonaktiebolaget Lm Ericsson (Publ) Amf eligibility for relay and reroute
EP3656185A1 (en) 2017-07-18 2020-05-27 British Telecommunications Public Limited Company Cellular telecommunications network
CN111132376B (zh) * 2018-11-01 2021-08-27 大唐移动通信设备有限公司 一种双连接endc链路的管理方法和装置
CN114175736B (zh) 2019-07-29 2024-04-02 英国电讯有限公司 在蜂窝电信网络中发起转移的方法、数据载体和网络节点
EP3772227B1 (en) 2019-07-29 2022-07-13 British Telecommunications public limited company Cellular telecommunications network
GB2596118B (en) 2020-06-18 2022-07-20 British Telecomm Cellular telecommunications network
CN116746215A (zh) * 2021-01-15 2023-09-12 华为技术有限公司 一种配置acl的方法及装置

Family Cites Families (18)

* 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 中兴通讯股份有限公司 一种基站间接口连接建立方法及装置
JP6104507B2 (ja) * 2012-01-20 2017-03-29 ノキア ソリューションズ アンド ネットワークス オサケユキチュア ゲートウェイ装置及び通信方法
CN103326770B (zh) * 2012-03-19 2016-04-06 上海贝尔股份有限公司 支持移动中继站和固定中继站共存的方法和相应的设备
WO2014169687A1 (zh) 2013-04-16 2014-10-23 中兴通讯股份有限公司 一种传输层地址的通知方法及系统
JP5414857B2 (ja) * 2012-08-22 2014-02-12 株式会社Nttドコモ 移動通信方法及び無線基地局
US20150351138A1 (en) * 2012-10-18 2015-12-03 Nokia Solutions And Networks Oy Intelligent bearer setup configuration control
WO2015015773A1 (ja) 2013-07-31 2015-02-05 日本電気株式会社 通信装置、コアネットワークノード、移動通信システム、通信方法及び記憶媒体
CN104469976A (zh) * 2013-09-25 2015-03-25 中兴通讯股份有限公司 一种建立连接的方法、装置及系统
US10104582B2 (en) * 2014-08-11 2018-10-16 Cisco Technology, Inc. Call preservation on handover

Also Published As

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

Similar Documents

Publication Publication Date Title
JP6384591B2 (ja) 基地局装置および基地局間ゲートウェイ装置
JP6597686B2 (ja) X2ゲートウェイ装置および方法
US10588071B2 (en) Wireless communication system, method of routing data in a wireless communication system, and method of handing over a wireless communication device, having an established data connection to a local network
EP2286615B1 (en) Data forwarding during handover in a self-backhauled cell
JP5704370B2 (ja) 基地局間のハンドオーバーを管理するための方法及び装置
US20230239754A1 (en) Enhanced XN Handover Messages for IAB Inter-CU Migration
WO2011020432A1 (zh) 基于移动中继的切换方法和移动无线中继系统
JP2013526087A (ja) ローカルipネットワークに接続するueのハンドオーバ方法、ハンドオーバシステム、装置
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
WO2015085709A1 (zh) 一种处理选定的ip流量卸载连接的方法及基站
EP4335157A1 (en) First node, second node and methods performed thereby for handling migration of a node
JP6732993B2 (ja) データ交換方法および装置
JP6509950B2 (ja) データ交換方法および装置
WO2023113680A1 (en) Radio access nodes and methods for setting up a connection in a wireless communications network
EP4315991A1 (en) Methods for enabling inter-donor routing in iab networks

Legal Events

Date Code Title Description
A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20170915

A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20170915

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20180710

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20180723

R150 Certificate of patent or registration of utility model

Ref document number: 6384591

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150