(57)【要約】ゲートウェイにかかる負荷を把握するために、例示的な実施形態の通信システムにおけるゲートウェイは、コアネットワークと無線基地局との間に接続されるゲートウェイであって、前記無線基地局から、当該無線基地局のトラフィックに関する第１の情報を受信する手段を有する。
2017047074.tif 000002
【特許請求の範囲】
【請求項１】
コアネットワークと無線基地局との間に接続されるゲートウェイであって、
前記無線基地局から、当該無線基地局のトラフィックに関する第１の情報を受信する手段を有する、ゲートウェイ。
【請求項２】
前記第１の情報が、あらかじめ設定された、前記無線基地局において想定されるトラフィック量を含む情報である、請求項１に記載のゲートウェイ。
【請求項３】
前記第１の情報が、Ｈｏｍｅ  Ｎｏｄｅ  Ｂ（ＨＮＢ）  ＲＥＧＩＳＴＥＲ  ＲＥＱＵＥＳＴメッセージによって送信される、請求項１または２に記載のゲートウェイ。
【請求項４】
前記ゲートウェイが、少なくとも１つのサーバを有し、
該サーバが、前記無線基地局から、前記第１の情報を受信する、請求項１乃至３のいずれかに記載のゲートウェイ。
【請求項５】
前記ゲートウェイが、負荷分散モジュールを有し、
前記サーバが、前記無線基地局から受信した前記第１の情報に基づく第２の情報を、該負荷分散モジュールに送信する、請求項４に記載のゲートウェイ。
【請求項６】
前記第１の情報として、前記無線基地局において想定されるトラフィック量が設定されていない場合に、前記サーバが、当該サーバによってあらかじめ設定されたデフォルト値を含む情報を、前記第２の情報として前記負荷分散モジュールに送信する、請求項５に記載のゲートウェイ。
【請求項７】
前記負荷分散モジュールは、前記第２の情報に基づいて、
前記サーバの負荷状態を第３の情報として管理する、
請求項５または６に記載のゲートウェイ。
【請求項８】
前記無線基地局が前記ゲートウェイと接続された場合には、前記第２の情報が、前記無線基地局において想定されるトラフィック量が増加したことを示し、
前記無線基地局が前記ゲートウェイから解除された場合には、前記第２の情報が、前記無線基地局において想定されるトラフィック量が減少したことを示す、請求項５乃至７のいずれかに記載のゲートウェイ。
【請求項９】
前記負荷分散モジュールが、前記第３の情報に基づいて、前記無線基地局を接続させるサーバを選択する、請求項７に記載のゲートウェイ。
【請求項１０】
請求項１乃至９のいずれかに記載されたゲートウェイを介してコアネットワークに接続される無線基地局であって、
当該無線基地局のトラフィックに関する第１の情報を、前記ゲートウェイへ送信する手段を有する、無線基地局。
【発明の詳細な説明】
【技術分野】
【０００１】
本開示は、コアネットワーク、ゲートウェイ、および無線基地局が接続された通信システムに関する。
【背景技術】
【０００２】
ＵＥ（Ｕｓｅｒ  Ｅｑｕｉｐｍｅｎｔ）とＣＮ（Ｃｏｒｅ  Ｎｅｔｗｏｒｋ）とが通信する際、そのＵＥが在圏するセルを通信カバレッジとする無線基地局とＣＮとが、両者の間にあるゲートウェイに接続される。ＵＥとＣＮとの間においては、無線基地局ユーザデータおよび制御信号の中継が行われる。【０００３】
特許文献１には、無線基地局がゲートウェイに、無線基地局の位置情報やアクセスモード情報を含むＨＮＢＡＰ（Ｈｏｍｅ  Ｎｏｄｅ  Ｂ  Ａｐｐｌｉｃａｔｉｏｎ  Ｐａｒｔ）メッセージを送信することについて記載されている。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２０１１‐１２４８６９号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
しかし無線基地局がゲートウェイにＨＮＢＡＰメッセージを送信するだけでは、ゲートウェイは、ゲートウェイにかかる負荷を把握することができない。
【課題を解決するための手段】
【０００６】
上記課題を解決するために、例示的な実施形態のゲートウェイは、
コアネットワークと無線基地局との間に接続されるゲートウェイであって、
前記無線基地局から、当該無線基地局のトラフィックに関する第１の情報を受信する手段を有する、ゲートウェイである。
【発明の効果】
【０００７】
例示的な実施形態のゲートウェイによれば、無線基地局のトラフィック量に関する情報を、無線基地局がゲートウェイへ送信することによって、ゲートウェイが、ゲートウェイにかかる負荷を把握することができる。
【図面の簡単な説明】
【０００８】
【図１】第１〜第３の実施形態にかかる通信システムの構成例を示す図
【図２】第１〜第３の実施形態にかかる動作を示すシーケンス図
【図３】第２〜第３の実施形態にかかる、ＨＮＢ-ＧＷの構成例を示す図
【図４】第２〜第３の実施形態にかかる動作を示すシーケンス図
【図５】ＨＮＢ  ＲＥＧＩＳＴＥＲ  ＲＥＱＵＥＳＴのＩｎｆｏｒｍａｔｉｏｎ  Ｅｌｅｍｅｎｔｓを示すテーブル図
【図６】関連技術における動作を説明するための図
【図７】第２〜第３の実施形態にかかる動作を示すフロー図
【図８】第２〜第３の実施形態にかかる動作を示すブロック図
【図９】第２〜第３の実施形態にかかる動作を示すブロック図
【図１０】第２〜第３の実施形態にかかる動作を表すブロック図
【図１１】第３の実施形態にかかる動作を示すシーケンス図
【図１２】第４〜第６の実施形態にかかる通信システムの構成例を示す図
【図１３】第４〜第６の実施形態にかかる動作を示すシーケンス図
【図１４】第５〜第６の実施形態にかかる、ＨｅＮＢ-ＧＷの構成例を示す図
【図１５】第５〜第６の実施形態にかかる動作を示すシーケンス図
【図１６】Ｓ１ ＳＥＴ  ＵＰ  ＲＥＱＵＥＳＴのＩｎｆｏｒｍａｔｉｏｎ  Ｅｌｅｍｅｎｔｓを示すテーブル図
【図１７】第６の実施形態にかかる動作を示すシーケンス図
【図１８】その他の実施形態に関する動作を示すブロック図
【発明を実施するための形態】
【０００９】
以下、図面を参照しながら例示的な実施形態にかかる通信システムについて詳細に説明する。
（第１の実施形態）
図１は、例示的な実施形態が対象とする通信システムの構成を例示している。ＨＮＢ（Ｈｏｍｅ  Ｎｏｄｅ  Ｂ；無線基地局）３が、ＨＮＢ−ＧＷ（Ｈｏｍｅ  Ｎｏｄｅ  Ｂ−ＧａｔｅＷａｙ；ゲートウェイ）２を介して、ＣＮ（Ｃｏｒｅ  Ｎｅｔｗｏｒｋ；コアネットワーク）１に接続されている。ＨＮＢ−ＧＷ２は、１つまたは複数のＨＮＢ３を収容するゲートウェイであり、ＨＮＢ３とＣＮ１とのユーザデータや制御信号などの中継を行うものである。ＨＮＢ３は、それぞれの通信カバレッジであるセル４を持ち、そこに在圏する１つまたは複数のＵＥ（Ｕｓｅｒ  Ｅｑｕｉｐｍｅｎｔ）５と無線通信を行う。
【００１０】
図２は、本実施形態にかかるシステムの動作を示すシーケンス図である。
ＨＮＢ３は、ＨＮＢ−ＧＷ２に、ＨＮＢ３のトラフィックに関する第１の情報を送信する。ＨＮＢ−ＧＷ２は、その第１の情報を受信する。
【００１１】
本実施形態によれば、ＣＮ１とＨＮＢ３との間に接続されるＨＮＢ−ＧＷ２が、ＨＮＢ３から、当該ＨＮＢ３のトラフィックに関する第１の情報を受信する手段（例えば受信装置、受信機、レシーバ、受信インターフェースとも言う）を有しているため、ＨＮＢ−ＧＷ２が、ＨＮＢ−ＧＷ２にかかる負荷を把握することができる。
（第２の実施形態）
本実施形態は、図１で示される通信システムの構成に基づいて、第１の実施形態をより具体化した例である。
【００１２】
図３は、本実施形態における、ＨＮＢ−ＧＷ２の内部構成を例示している。ＨＮＢ−ＧＷ２は、負荷分散モジュール８、制御信号処理サーバ７、ＳｅＧＷ（セキュリティゲートウェイ）６とを有している。
【００１３】
ＨＮＢ３からＨＮＢ−ＧＷ２への接続要求があった際、負荷分散モジュール８は、そのＨＮＢ３を接続させるのに最適な制御信号処理サーバ７を選択する。選択された制御信号処理サーバ７は、ＨＮＢ３との接続を収容する。そしてＨＮＢ３は、当該選択された制御信号処理サーバ７に対してＳＣＴＰ（Ｓｔｒｅａｍ  Ｃｏｎｔｒｏｌ  Ｔｒａｎｓｍｉｓｓｉｏｎ  Ｐｒｏｔｏｃｏｌ）  Ａｓｓｏｃｉａｔｉｏｎを確立し、それを介してＣＮ１との通信処理を行う。また負荷分散モジュール８は、各制御信号処理サーバ７が確立したＳＣＴＰ  Ａｓｓｏｃｉａｔｉｏｎの数を保持・管理している。ＳｅＧＷ（セキュリティゲートウェイ）６は、ＨＮＢ３との間でＩＰＳｅｃ（ＩＰ  Ｓｅｃｕｒｉｔｙ  Ａｒｃｈｉｔｅｃｔｕｒｅ）等のセキュアコネクションを確立し、情報を暗号化する。
【００１４】
図４は、本実施形態にかかる通信システムの動作を示すシーケンス図である。ＨＮＢ３が起動する（Ｓ１）と、まずＨＮＢ３と、ＳｅＧＷ（セキュリティゲートウェイ）６との間でＳｅｃｕｒｅ  Ｃｏｎｎｅｃｔｉｏｎが確立され（Ｓ２）る。その後、ＨＮＢ３が、負荷分散モジュール８に、ＤＮＳ（Ｄｏｍａｉｎ  Ｎａｍｅ  Ｓｙｓｔｅｍ）Ｑｕｅｒｙを送信（Ｓ３）する。負荷分散モジュール８は、ＨＮＢ３に接続させる制御信号処理サーバ７を選択し（Ｓ４）、選択した制御信号処理サーバ７のＩＰアドレスをＤＮＳ  Ｑｕｅｒｙ  ＲｅｓｐｏｎｓｅでＨＮＢ３に返却する（Ｓ５）。その後、ＨＮＢ３とＨＮＢ−ＧＷ２とを接続するためのＳＣＴＰ  Ａｓｓｏｃｉａｔｉｏｎが、ＨＮＢ３と制御信号処理サーバ７との間で確立される（Ｓ６）。
【００１５】
続いて、ＨＮＢ３は、ＨＮＢ-ＧＷ２における制御信号処理サーバ７にＨＮＢ Ｒｅｇｉｓｔｅｒ  Ｒｅｑｕｅｓｔメッセージを送信することによって、ＨＮＢ−ＧＷ２への登録を要求する（Ｓ７）。この要求に際しては、図５に示されるような、Ｍｅｓｓａｇｅ Ｔｙｐｅ、ＨＮＢ Ｉｄｅｎｔｉｔｙ、ＨＮＢ  Ｌｏｃａｔｉｏｎ  ＩｎｆｏｒｍａｔｉｏｎなどのＩＥ（Ｉｎｆｏｒｍａｔｉｏｎ  Ｅｌｅｍｅｎｔｓ）も用いることができるが、これらに限られない。図４に示されるように、本実施形態でＨＮＢ３がＨＮＢ−ＧＷ２へ送信するＨＮＢ Ｒｅｇｉｓｔｅｒ Ｒｅｑｕｅｓｔメッセージは、ＨＮＢ３のトラフィックに関する第１の情報とＨＮＢ-Ｉｄｅｎｔｉｔｙとを合わせたメッセージである。
【００１６】
ＨＮＢ３とＨＮＢ−ＧＷ２間の情報の送受信を効率化させる観点から、第１の情報は、本実施形態のように、ＨＮＢ  Ｒｅｇｉｓｔｅｒ  Ｒｅｑｕｅｓｔ メッセージによって送信されることが好ましく、他のＩＥと合わせて送信されても良い。しかし第１の情報は、必ずしも他のＩＥと合わせて送信されなくてもよい。第１の情報は、ＨＮＢ３において想定されるトラフィック量を含む情報を、ＨＮＢ  Ｒｅｇｉｓｔｅｒ  Ｒｅｑｕｅｓｔメッセージの新しい文字列のＩＥとして設定してもよい。例えば、図５に示すような文字列Ａｓｓｕｍｅｄ Ｌｏａｄで示されるＩＥとして設定してもよい。なお、第１の情報は、ＨＮＢ３において想定されるトラフィック量そのものであっても良い。
【００１７】
本実施形態のように、制御信号処理サーバ７が、ＨＮＢ３から、第１の情報を受信する場合、上述のとおり、ＨＮＢ３は、ＨＮＢ  Ｒｅｇｉｓｔｅｒ  Ｒｅｑｕｅｓｔメッセージを送信するタイミングで第１の情報を送信することができる。
【００１８】
ここで第１の情報は、均等なトラフィック量でＳＣＴＰ  Ａｓｓｏｃｉａｔｉｏｎが分散されるように、設定されるものである。本実施形態において第１の情報は、ＨＮＢ３にＵＥ５が在圏する前に、あらかじめ設定される。
【００１９】
ところで、ＨＮＢ３は、ＵＥ５がＨＮＢ３に在圏する前に、ＨＮＢ−ＧＷ２と接続してＳＣＴＰ  Ａｓｓｏｃｉａｔｉｏｎを確立する。また、１つのＨＮＢ３については１つのＳＣＴＰ  Ａｓｓｏｃｉａｔｉｏｎしか確立されない。そして、そのＳＣＴＰ  Ａｓｓｏｃｉａｔｉｏｎを確立しているＨＮＢ３またはＨＮＢ−ＧＷ２に在圏するＵＥ５が、そのＳＣＴＰ  Ａｓｓｏｃｉａｔｉｏｎを共有する。
【００２０】
制御信号処理サーバ７−１から制御信号処理サーバ７−Ｎ（Ｎは任意の整数である。）のうち、ＳＣＴＰ  Ａｓｓｏｃｉａｔｉｏｎの数が最も少ない制御信号処理サーバが、最も負荷が少ない制御信号処理サーバであるという前提があった。その前提のもとで、負荷分散モジュール８は、最もＳＣＴＰ  Ａｓｓｏｃｉａｔｉｏｎ数が少ない制御信号処理サーバを、新しくＨＮＢ-ＧＷ２に接続を要求してきたＨＮＢ３を接続させる制御信号処理サーバ７として選択していた（図６）。しかし、ＳＣＴＰ  Ａｓｓｏｃｉａｔｉｏｎの数を選択基準にすると、例えば、制御信号処理サーバ７にかかる負荷が、均等に分散されないという問題が生じ得る。よって、制御信号処理サーバ７の選択基準は、ＳＣＴＰ  Ａｓｓｏｃｉａｔｉｏｎの数ではなく、制御信号処理サーバ７にかかるであろう負荷であることが好ましい。
【００２１】
一方で、制御信号処理サーバ７にかかる負荷を調整するために、一度確立したＳＣＴＰ  Ａｓｓｏｃｉａｔｉｏｎを切断すると、そのＳＣＴＰ  Ａｓｓｏｃｉａｔｉｏｎを確立しているＨＮＢ３またはＨＮＢ−ＧＷ２の配下にあるＵＥ５のすべてが呼損となってしまう恐れがある。
【００２２】
つまり、ＳＣＴＰ  Ａｓｓｏｃｉａｔｉｏｎが確立される前に、ＨＮＢ３において想定されるトラフィック量を設定することによって、ＳＣＴＰ  Ａｓｓｏｃｉａｔｉｏｎを切断することなく、ＳＣＴＰ  Ａｓｓｏｃｉａｔｉｏｎを均等に分散することが可能となる。このことから、本実施形態のように、第１の情報が、ＨＮＢ３にＵＥ５が在圏する前にあらかじめ設定される情報、とりわけＨＮＢ３において想定されるトラフィック量を含む情報であることによって、ＳＣＴＰ  Ａｓｓｏｃｉａｔｉｏｎが確立された（Ｓ６）後で変化する情報、例えばＨＮＢ３における実際のトラフィック量や、後述のようにＨＮＢ３に在圏することとなるＵＥ５に関する実際の識別情報や個数等に起因するトラフィック量である場合と比較して、ＵＥ５の呼損を防止しながら、ＳＣＴＰ  Ａｓｓｏｃｉａｔｉｏｎを均等に分散することが可能となる点で有利である。
【００２３】
制御信号処理サーバ７がＨＮＢ  Ｒｅｇｉｓｔｅｒ  Ｒｅｑｕｅｓｔを許容する場合、ＨＮＢ３へのＨＮＢ  Ｒｅｇｉｓｔｅｒ  Ａｃｃｅｐｔを返却し（Ｓ８）、ＨＮＢ３が制御信号処理サーバ７に接続される。
【００２４】
制御信号処理サーバ７は、Ｓ７でＨＮＢ３から受信した第１の情報に基づく第２の情報を、負荷分散モジュール８へ送信する（Ｓ９）。負荷分散モジュール８は、受信した第２の情報に基づいて、制御信号処理サーバ７の負荷状態を第３の情報として管理する。そして、既に管理している第３の情報が基づく、第２の情報を送信してきた制御信号処理サーバ７から、更に第２の情報が送信されたときには、第３の情報を更新する（Ｓ１０）。
【００２５】
第２の情報は、ＨＮＢ３において想定されるトラフィック量を含む情報であってもよく、また、ＨＮＢ３がＨＮＢ-ＧＷ２と接続された場合には、第２の情報は、ＨＮＢ３において想定されるトラフィック量が増加したことを示す情報であっても良い。そして、第３の情報は、第２の情報の累積値であってもよい。なお、第１の情報と第２の情報と第３の情報は、互いに同じものであってもよいし、異なるものであってもよい。
【００２６】
第３の情報の更新に際しては、例えば図８で示されるような、想定トラフィック量テーブルにおいて、ＨＮＢ３において想定されるトラフィック量やＳＣＴＰ  Ａｓｓｏｃｉａｔｉｏｎの数を加算することによって行ってもよい。新たにＨＮＢ-ＧＷ２に登録を要求してきたＨＮＢがあった際、負荷分散モジュール８は、第３の情報に基づいて、そのＨＮＢを接続させる制御信号処理サーバ７を選択（Ｓ４）してもよい。
【００２７】
ＵＥ５からＨＮＢ３へ、Ｌｏｃａｔｉｏｎ  Ａｒｅａ  Ｕｐｄａｔｅ  Ｒｅｑｕｅｓｔが送信され（Ｓ１１）た後、ＨＮＢ３とＨＮＢ−ＧＷ２内の制御信号処理サーバ７との間でＵＥ５の登録手続きに入る（Ｓ１２）。そして、ＨＮＢ３から制御信号処理サーバ７へ、Ｌｏｃａｔｉｏｎ  Ａｒｅａ  Ｕｐｄａｔｅ  Ｒｅｑｕｅｓｔが送信され（Ｓ１３）。
そして、ＵＥ５がＨＮＢ３の管轄するセルに在圏することとなる。
【００２８】
図７は、制御信号処理サーバ７の処理フローを表したものである。まず、制御信号処理サーバ７は、ＨＮＢ３から、ＨＮＢＡＰ：ＨＮＢ  ＲＥＧＩＳＴＥＲ  ＲＥＱＵＥＳＴメッセージを受信する（Ｔ１）。図７では、ＨＮＢ  ＲＥＧＩＳＴＥＲ  ＲＥＱＵＥＳＴメッセージのＩＥがＨＮＢ-Ｉｄｅｎｔｉｔｙであった場合について示している。次に、制御信号処理サーバ７は、ＨＮＢ-Ｉｄｅｎｔｉｔｙのｒｅａｌｍチェックを行う（Ｔ２）。ＨＮＢ‐Ｉｄｅｎｔｉｔｙのフォーマットは、０＜ＩＭＳＩ＞＠＜ｒｅａｌｍ＞や１＜ＯＵＩ＞‐＜ＳｅｒｉａｌＮｕｍｂｅｒ＞＠＜ｒｅａｌｍ＞と規定されている（非特許文献１）。なお、＜ＩＭＳＩ＞は、非特許文献２で特定される１６桁のコードであり、＜ＯＵＩ＞および＜ＳｅｒｉａｌＮｕｍｂｅｒ＞は、非特許文献３で特定されるコードである。
【非特許文献１】３ＧＰＰ  ＴＳ  ２５．４６９：“ＵＴＲＡＮ  Ｉｕｈ  ｉｎｔｅｒｆａｃｅ  Ｈｏｍｅ  Ｎｏｄｅ  Ｂ（ＨＮＢ）Ａｐｐｌｉｃａｔｉｏｎ  Ｐａｒｔ（ＨＮＢＡＰ） ｓｉｇｎａｌｉｎｇ”.
【非特許文献２】３ＧＰＰ  ＴＳ  ２３．００３：“Ｎｕｍｂｅｒｉｎｇ,  ａｄｄｒｅｓｓｉｎｇ  ａｎｄ  ｉｄｅｎｔｉｆｉｃａｔｉｏｎ”.
【非特許文献３】Ｂｒｏａｄｂａｎｄ  Ｆｏｒｕｍ  ＴＲ‐０６９  Ａｍｅｎｄｍｅｎｔ  ２,   ＣＰＥ  ＷＡＮ  Ｍａｎａｇｅｍｅｎｔ  Ｐｒｏｔｏｃｏｌ,   Ｂｒｏａｄｂａｎｄ  Ｆｏｒｕｍ  Ｔｅｃｈｎｉｃａｌ  Ｒｅｐｏｒｔ,２００７.  ＨＮＢ−Ｉｄｅｎｔｉｔｙのフォーマットのうちｒｅａｌｍ部分（例えば、ｎｅｃ.ｃｏｍ）に、ＨＮＢ３において想定されるトラフィック量が設定されていない、つまりトラフィック量として定めた値がない場合、図７に示すように制御信号処理サーバ７は、トラフィック量を含まない、あらかじめ制御信号処理サーバ７で設定されたデフォルト値を含む情報を、ＨＮＢ−Ｉｄｅｎｔｉｔｙと合わせて保持することができる（Ｔ３）。この場合、制御信号処理サーバ７は、当該制御信号処理サーバ７によってあらかじめ設定されたデフォルト値を含む情報を、第２の情報として負荷分散モジュール８に送信することができる。デフォルト値を含む情報とは、デフォルト値そのもの、あるいは当該デフォルト値とＨＮＢ−Ｉｄｅｎｔｉｔｙとを合わせたＩＥであっても良い。
【００２９】
ｒｅａｌｍ部分に、ＨＮＢ３において想定されるトラフィック量として定めた値がある場合には、制御信号処理サーバ７は、その値、図６においては５００００を、ＨＮＢ３において想定されるトラフィック量として保持し（Ｔ４）、ｒｅａｌｍ部分に、トラフィックに関する第１の情報を示す数値の文字列を付加し、例えば、ｎｅｃ.ｃｏｍ＿５００００ＢＨＣＡ等とすることができる。
【００３０】
そして制御信号処理サーバ７は、デフォルト値、またはｒｅａｌｍ部分にて定められた、ＨＮＢ３において想定されるトラフィック量、もしくはＨＮＢ３において想定されるトラフィック量が増加したことを示す情報を負荷分散モジュール８に送信する（Ｔ６）。
【００３１】
図８は、負荷分散モジュール８における、想定トラフィック量テーブルの更新動作を示している。この場合における第３の情報は、制御信号処理サーバ７から送信された第２の情報が示す、ＨＮＢ３のトラフィック量の累積値である。想定トラフィック量テーブルは、制御信号処理サーバ７の識別子、ＨＮＢ３において想定されるトラフィック量の累積値、そしてＳＣＴＰ  Ａｓｓｏｃｉａｔｉｏｎ数からなる。負荷分散モジュール８は、制御信号処理サーバ７から、ＨＮＢ３において想定されるトラフィック量が増加したことを示す情報を送信された場合、当該情報を送信した制御信号処理サーバ７に関する、ＨＮＢ３において想定されるトラフィック量の累積値に、ＨＮＢ３において想定されるトラフィック量の増加分を追加し、ＳＣＴＰ  Ａｓｓｏｃｉａｔｉｏｎ数を１増やす。
【００３２】
図９は、負荷分散モジュール８における、制御信号処理サーバ７の選択処理動作を示している。この場合も、第３の情報は、制御信号処理サーバ７から送信された第２の情報が示す、ＨＮＢ３のトラフィック量の累積値であり、負荷分散モジュール８は、第３の情報に基づいて、ＨＮＢ３を接続させる制御信号処理サーバ７を選択する。ＨＮＢ３からＤＮＳ  Ｑｕｅｒｙを受信すると、負荷分散モジュール８は、想定トラフィック量テーブルを更新し、ＨＮＢ３において想定されるトラフィック量の累積値が最も小さい制御信号処理サーバ７を選択する。そして選択された制御信号処理サーバ７のＩＰアドレスを、ＤＮＳ Ｑｕｅｒｙ  Ｒｅｓｐｏｎｓｅに含めて返送する。
【００３３】
本実施形態にかかる通信システムによれば、負荷分散モジュール８が、ＨＮＢ３において想定されるトラフィック量の累積値が最小である制御信号処理サーバ７を、新しくＨＮＢ−ＧＷ２に接続を要求してきたＨＮＢ３の接続先として指示することができるようになる。そのため、ＨＮＢ３において想定されるトラフィック量を適切に設定することによって、実際のトラフィック量や、ＵＥ５に関する実際の識別情報および個数等に起因するトラフィック量の偏りを平準化することができるようになる。
【００３４】
図１０は、本実施形態において、新しくＨＮＢ−ＧＷ２に接続を要求してきたＨＮＢ３を制御信号処理サーバ７に接続させる様子を示すものである。図９の表において、第３の情報であるＨＮＢ３のトラフィック量の累積値は、識別子がＮである制御信号処理サーバ７が最も小さい。よって、負荷分散モジュール８は、新しくＨＮＢ−ＧＷ２に接続を要求してきたＨＮＢ３の接続先として、制御信号処理サーバ７−Ｎを選択することを指示する。
（第３の実施形態）
図１１は、制御信号処理サーバ７に接続済みのＨＮＢ３がその接続を解除する場合についてのシーケンス図である。
【００３５】
Ｓ１からＳ１３までは、図４に示す動作と同様の動作が行われる。
【００３６】
その後、ＨＮＢ３が、制御信号処理サーバ７との接続を解除する場合、ＨＮＢ３と制御信号処理サーバ７との間で、ＨＮＢ  Ｄｅ−ＲｅｇｉｓｔｒａｔｉｏｎおよびＳＣＴＰ  Ａｓｓｏｃｉａｔｉｏｎ切断（Ｓ１４）が行われる。この際、接続を解除された制御信号処理サーバ７は、接続解除となったＨＮＢ３において想定されるトラフィック量が減少したことを示す情報を、第２の情報として、負荷分散モジュール８に送信することができる（Ｓ１５）。そして、この情報に基づいて、負荷分散モジュール８は第３の情報をさらに更新する（Ｓ１０１）。
【００３７】
図８を用いて、本実施形態の負荷分散モジュール８における想定トラフィック量テーブルの更新動作について説明する。
【００３８】
負荷分散モジュール８は、制御信号処理サーバ７から、ＨＮＢ３において想定されるトラフィック量が減少したことを示す情報を受信した場合、当該情報送信した制御信号処理サーバ７の、ＨＮＢ３において想定されるトラフィック量の累積値から、ＨＮＢ３において想定されるトラフィック量の減少分を減算し、またＳＣＴＰ  Ａｓｓｏｃｉａｔｉｏｎ数を１減らす。
【００３９】
負荷分散モジュール８における、制御信号処理サーバ７の選択処理動作以降の動作に関しては、第２の実施形態と同様である。
【００４０】
本実施形態にかかる通信システムによれば、制御信号処理サーバ７に接続済みのＨＮＢ３がその接続を解除する場合において、負荷分散モジュール８が、ＨＮＢ３において想定されるトラフィック量の累積値が最小である制御信号処理サーバ７を、新しくＨＮＢ−ＧＷ２に接続を要求してきたＨＮＢ３の接続先として指示することができるようになる。そのため、ＨＮＢ３において想定されるトラフィック量を適切に設定することによって、実際のトラフィック量や、ＵＥ５に関する実際の識別情報および個数等に起因するトラフィック量の偏りを平準化することができるようになる。
（第４の実施形態）
ここまでは、無線基地局としてＨＮＢを想定した実施形態について説明してきたが、本発明はこれに限られるものではなく、ＬＴＥに適用させて、無線基地局がＨｅＮＢであり、ゲートウェイがＨｅＮＢ−ＧＷであることとしてもよい。
【００４１】
図１２は、例示的な実施形態が対象とするＬＴＥシステムの構成を例示している。ＨｅＮＢ（Ｈｏｍｅ  ｅｖｏｌｖｅｄ  Ｎｏｄｅ  Ｂ；無線基地局）３１が、ＨｅＮＢ−ＧＷ（Ｈｏｍｅ ｅｖｏｌｖｅｄ  Ｎｏｄｅ  Ｂ−ＧａｔｅＷａｙ；ゲートウェイ）２１を介して、ＣＮ１１に接続されている。ＨｅＮＢ−ＧＷ２１は、１つまたは複数のＨｅＮＢ３１を収容するゲートウェイであり、ＨｅＮＢ３１とＣＮ１１とのユーザデータや制御信号などの中継を行うものである。ＨｅＮＢ３１は、それぞれの通信カバレッジであるセル４１を持ち、そこに在圏する１つまたは複数のＵＥ（Ｕｓｅｒ  Ｅｑｕｉｐｍｅｎｔ）５１と無線通信を行う。
【００４２】
図１３は、本実施形態にかかる通信システムの動作を示すシーケンス図である。
ＨｅＮＢ３１は、ＨｅＮＢ−ＧＷ２１に、ＨｅＮＢ３１のトラフィックに関する第１の情報を送信する。ＨｅＮＢ−ＧＷ２１は、その第１の情報を受信する。
【００４３】
本実施形態にかかる通信システムによれば、ＨｅＮＢ−ＧＷが、ＨｅＮＢのトラフィックに関する情報を把握することができる。
（第５の実施形態）
本実施形態は、図１２で示される通信システムの構成に基づいて、第４の実施形態をより具体化した例である。
【００４４】
図１４は、ＨｅＮＢ−ＧＷ２１の内部構成およびＳｅＧＷ（セキュリティゲートウェイ）６１を例示している。ＨｅＮＢ−ＧＷ２１は、負荷分散モジュール８１と、制御信号処理サーバ７１を有している。負荷分散モジュール８１は、各制御信号処理サーバ７１が確立しているＳＣＴＰ  Ａｓｓｏｃｉａｔｉｏｎの数を保持および管理している。ＨｅＮＢ３１からＨｅＮＢ−ＧＷ２１への接続要求があった際、負荷分散モジュール８１は、そのＨｅＮＢ３１を接続させるのに最適な制御信号処理サーバ７１を選択する。制御信号処理サーバ７は、ＨｅＮＢ３１との接続を収容し、ＣＮ１１との通信処理を行う。ＳｅＧＷ６１は、ＨｅＮＢ３１との間でＩＰＳｅｃ（ＩＰ  Ｓｅｃｕｒｉｔｙ  Ａｒｃｈｉｔｅｃｔｕｒｅ）等のセキュアコネクションを確立し、情報を暗号化する。
【００４５】
図１５は、本実施形態にかかる通信システムの動作を示すシーケンス図である。ＨｅＮＢ３１が起動する（Ｌ１）と、まずＨｅＮＢ３１と、ＳｅＧＷ６１との間でＳｅｃｕｒｅ  Ｃｏｎｎｅｃｔｉｏｎが確立され（Ｌ２）る。その後、ＨｅＮＢ３１が、負荷分散モジュール８１に、ＤＮＳ（Ｄｏｍａｉｎ  Ｎａｍｅ  Ｓｙｓｔｅｍ）Ｑｕｅｒｙを送信（Ｌ３）する。負荷分散モジュール８は、ＨｅＮＢ３１に接続させる制御信号処理サーバ７を選択し（Ｌ４）、選択した制御信号処理サーバ７のＩＰアドレスをＤＮＳ  Ｑｕｅｒｙ  ＲｅｓｐｏｎｓｅでＨｅＮＢ３１に返却する（Ｌ５）。その後、ＨｅＮＢ３１とＨｅＮＢ−ＧＷ２１とを接続するためのＳＣＴＰ  Ａｓｓｏｃｉａｔｉｏｎが、ＨｅＮＢ３１と制御信号処理サーバ７１との間で確立される（Ｌ６）。
【００４６】
続いて、ＨｅＮＢ３１は、ＨｅＮＢ−ＧＷ２１にＳ１  Ｓｅｔｕｐ  Ｒｅｑｕｅｓｔを送信することによって、ＨｅＮＢ−ＧＷ２１へＳ１インターフェースの確立を要求する（Ｌ７）。この要求に際しては、図１６に示されるような、Ｍｅｓｓａｇｅ  Ｔｙｐｅ、Ｇｌｏｂａｌ  ｅＮＢ  ＩＤ、ｅＮＢ  ＮａｍｅなどのＩＥも用いることができるが、これらに限られない。図１５に示されるように、本実施形態でＨｅＮＢ３１がＨｅＮＢ−ＧＷ２１へ送信するＳ１  Ｓｅｔｕｐ  Ｒｅｑｕｅｓｔは、ＨｅＮＢ３１のトラフィックに関する第１の情報とＧｌｏｂａｌ  ｅＮＢ  ＩＤとを合わせたメッセージである。
【００４７】
Ｌ８からＬ１３までの動作は、図４を用いて説明した、第２の実施形態におけるＳ８からＳ１３までの動作と同様に行われる。
【００４８】
本実施形態にかかる通信システムによれば、ＬＴＥシステムにおいて、負荷分散モジュール８１が、ＨｅＮＢ３１において想定されるトラフィック量の累積値が最小である制御信号処理サーバ７１を、新しくＨｅＮＢ−ＧＷ２１に接続を要求してきたＨｅＮＢ３１の接続先として指示することができるようになる。そのため、ＨｅＮＢ３１において想定されるトラフィック量を適切に設定することによって、実際のトラフィック量や、ＵＥ５１に関する実際の識別情報および個数等に起因するトラフィック量の偏りを平準化することができるようになる。
（第６の実施形態）
図１７は、制御信号処理サーバ７１に接続済みのＨｅＮＢ３１がその接続を解除する場合についてのシーケンス図である。
【００４９】
Ｌ１からＬ１３までは、図１５に示す動作と同様の動作が行われる。
【００５０】
その後、ＨｅＮＢ３１が、制御信号処理サーバ７１との接続を解除する場合、ＨｅＮＢ３１と制御信号処理サーバ７１との間で、ＨｅＮＢ  Ｄｅ−ＲｅｇｉｓｔｒａｔｉｏｎおよびＳＣＴＰ  Ａｓｓｏｃｉａｔｉｏｎ切断（Ｌ１４）が行われる。この際、接続を解除された制御信号処理サーバ７１は、接続解除となったＨｅＮＢ３１において想定されるトラフィック量が減少したこと示す情報を、第２の情報として、負荷分散モジュール８１に送信することができる（Ｌ１５）。そして、この情報に基づいて、負荷分散モジュール８１は第３の情報をさらに更新する（Ｌ１０１）。
【００５１】
本実施形態の負荷分散モジュール８１における想定トラフィック量テーブルの更新動作は、第３の実施形態におけるものと同様である。また、負荷分散モジュール８１における制御信号処理サーバ７１の選択処理動作以降の動作は、第２の実施形態と同様である。
【００５２】
本実施形態にかかる通信システムによれば、ＬＴＥシステムにおいて、制御信号処理サーバ７１に接続済みのＨｅＮＢ３１がその接続を解除する場合において、負荷分散モジュール８１が、ＨｅＮＢ３１において想定されるトラフィック量の累積値が最小である制御信号処理サーバ７１を、新しくＨｅＮＢ−ＧＷ２１に接続を要求してきたＨｅＮＢ３１の接続先として指示することができるようになる。そのため、ＨｅＮＢ３１において想定されるトラフィック量を適切に設定することによって、実際のトラフィック量や、ＵＥ５１に関する実際の識別情報および個数等に起因するトラフィック量の偏りを平準化することができるようになる。
（その他の実施形態）
図１８は、その他の実施形態を表している。ＨＮＢ−ＩｄｅｎｔｉｔｙとＨＮＢ３において想定されるトラフィック量のマッピングテーブルを負荷分散モジュール８内部であらかじめ保持しておき、その情報を用いて負荷分散モジュール８がＨＮＢ３において想定されるトラフィック量の累積値を算出し、ＨＮＢ３において想定されるトラフィック量を含む情報をもとに、制御信号処理サーバ７の選択処理に用いるという例である。
【００５３】
ここでは、ＥＤＮＳ０（Ｅｘｔｅｎｓｉｏｎ  Ｍｅｃｈａｎｉｓｍｓ  ｆｏｒ  ＤＮＳ）によるＤＮＳ拡張を用いて、ＤＮＳ  ＱｕｅｒｙにＨＮＢ−ＩＤおよびＨＮＢ３において想定されるトラフィック量を含む情報を送信するパラメタ（例えばＯｐｔｉｏｎ  Ｃｏｄｅｓ  ６５００１−６５５３４  Ｌｏｃａｌ／Ｅｘｐｅｒｉｍｅｎｔａｌ  ｕｓｅを用いる等）を設定することで、負荷分散モジュール８がＤＮＳ  Ｑｕｅｒｙ受信時にそのＨＮＢにおいて想定されるトラフィック量を取得し、ＨＮＢにおいて想定されるトラフィック量のテーブルの更新および制御信号処理サーバ７の選択を行ってもよい。
【００５４】
以上、例示的な実施形態を説明した。本発明は上述した実施形態に限定されるものではなく、本発明の要旨の範囲内において種々に変形して実施をすることが可能である。上述した実施形態は例示であり、実施形態の組合せやそれらの各構成要素や各処理プロセスの組合せに様々な変形例が可能なこと、またそうした変形例も本発明の範囲にあることは、当業者に理解されるところである。
【００５５】
例えば、本明細書に記載されている処理におけるステップは、必ずしもシーケンス図に記載された順序に沿って時系列に実行されなくてよい。例えば、処理におけるステップは、シーケンス図として記載した順序と異なる順序で実行されても、並列的に実行されてもよい。
【００５６】
また、本明細書において説明した無線基地局は、例えば、通信処理部、要求部、情報取得部、制御部、及び／又は報告部等の構成要素を備えるものであってもよい。さらに、これらの構成要素を備えるモジュール（例えば、無線基地局装置、又は無線基地局装置のためのモジュール）が提供されてもよい。また、当該構成要素の処理を含む方法が提供されてもよく、当該構成要素の処理をプロセッサに実行させるためのプログラムが提供されてもよい。また、当該プログラムを記録した記録媒体が提供されてもよい。
当然ながら、このようなモジュール、方法、プログラム及び記録媒体も本発明に含まれる。
【００５７】
また、本明細書において説明したＵＥは、例えば、ＲＦ（Ｒａｄｉｏ  Ｆｒｅｑｕｅｎｃｙ）トランシーバ、アンテナ、ベースバンドプロセッサ、アプリケーションプロセッサ、およびメモリ等の構成要素を有するものであってもよい。
【００５８】
ＲＦトランシーバ（ＲＦ）トランシーバは、無線基地局と通信するためにアナログＲＦ信号処理を行う。ＲＦトランシーバにより行われるアナログＲＦ信号処理は、周波数アップコンバージョン、周波数ダウンコンバージョン、及び増幅を含むものであってもよい。
ＲＦトランシーバは、アンテナ及びベースバンドプロセッサと結合されるものであってもよい。すなわち、ＲＦトランシーバは、変調シンボルデータ（又はＯＦＤＭシンボルデータ）をベースバンドプロセッサから受信し、送信ＲＦ信号を生成し、送信ＲＦ信号をアンテナに供給してもよい。また、ＲＦトランシーバは、アンテナによって受信された受信ＲＦ信号に基づいてベースバンド受信信号を生成し、これをベースバンドプロセッサに供給してもよい。
【００５９】
ベースバンドプロセッサは、無線通信のためのデジタルベースバンド信号処理（データプレーン処理）とコントロールプレーン処理を行う。デジタルベースバンド信号処理は、（ａ） データ圧縮／復元、（ｂ）データのセグメンテーション／コンカテネーション、（ｃ）伝送フォーマット（伝送フレーム）の生成／分解、（ｄ）伝送路符号化／復号化、（ｅ）変調（シンボルマッピング）／復調、及び（ｆ）Ｉｎｖｅｒｓｅ  Ｆａｓｔ  Ｆｏｕｒｉｅｒ  Ｔｒａｎｓｆｏｒｍ（ＩＦＦＴ）によるＯＦＤＭシンボルデータ（ベースバンドＯＦＤＭ信号）の生成などを含むものであってもよい。一方、コントロールプレーン処理は、レイヤ１（e.g., 送信電力制御）、レイヤ２（ｅ．ｇ．，無線リソース管理、及びｈｙｂｒｉｄ  ａｕｔｏｍａｔｉｃ  ｒｅｐｅａｔ  ｒｅｑｕｅｓｔ（ＨＡＲＱ）処理）、及びレイヤ３（ｅ．ｇ．，アタッチ、モビリティ、及び通話管理に関するシグナリング）の通信管理を含でもよい。
【００６０】
例えば、ＬＴＥ及びＬＴＥ−Ａｄｖａｎｃｅｄの場合、ベースバンドプロセッサによるデジタルベースバンド信号処理は、ＰＤＣＰ（Ｐａｃｋｅｔ  Ｄａｔａ  Ｃｏｎｖｅｒｇｅｎｃｅ Ｐｒｏｔｏｃｏｌ）レイヤ、ＲＬＣ（Ｒａｄｉｏ  Ｌｉｎｋ  Ｃｏｎｔｒｏｌ）レイヤ、ＭＡＣ（Ｍｅｄｉｕｍ  Ａｃｃｅｓｓ  Ｃｏｎｔｒｏｌ）レイヤ、およびＰＨＹ（Ｐｈｙｓｉｃａｌ）レイヤの信号処理を含んでもよい。また、ベースバンドプロセッサによるコントロールプレーン処理は、ＮＡＳ（Ｎｏｎ−Ａｃｃｅｓｓ  Ｓｔｒａｔｕｍ）プロトコル、ＲＲＣ（Ｒａｄｉｏ  Ｒｅｓｏｕｒｃｅ  Ｃｏｎｔｒｏｌ）プロトコル、及びＭＡＣ ＣＥ（ＭＡＣ  Ｃｏｎｔｒｏｌ  Ｅｌｅｍｅｎｔ）の処理を含んでもよい。
【００６１】
ベースバンドプロセッサは、デジタルベースバンド信号処理を行うモデム・プロセッサ（ｅ．ｇ．，ＤＳＰ（Ｄｉｇｉｔａｌ  Ｓｉｇｎａｌ  Ｐｒｏｃｅｓｓｏｒ））とコントロールプレーン処理を行うプロトコルスタック・プロセッサ（ｅ．ｇ．，ＣＰＵ（Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ）、またはＭＰＵ（Ｍｉｃｒｏ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ））を含んでもよい。この場合、コントロールプレーン処理を行うプロトコルスタック・プロセッサは、後述するアプリケーションプロセッサと共通化されてもよい。
【００６２】
アプリケーションプロセッサは、ＣＰＵ、ＭＰＵ、マイクロプロセッサ、又はプロセッサコアとも呼ばれる。アプリケーションプロセッサは、複数のプロセッサ（複数のプロセッサコア）を含んでもよい。アプリケーションプロセッサは、メモリ又は図示されていないメモリから読み出されたシステムソフトウェアプログラム（ＯＳ（Ｏｐｅｒａｔｉｎｇ  Ｓｙｓｔｅｍ））及び様々なアプリケーションプログラム（例えば、通話アプリケーション、ＷＥＢブラウザ、メーラ、カメラ操作アプリケーション、音楽再生アプリケーション）を実行することによって、ＵＥの各種機能を実現する。
【００６３】
いくつかの実装において、ベースバンドプロセッサ及びアプリケーションプロセッサは、１つのチップ上に集積されてもよい。言い換えると、ベースバンドプロセッサ及びアプリケーションプロセッサは、１つのＳｏＣ（Ｓｙｓｔｅｍ  ｏｎ Ｃｈｉｐ）デバイスとして実装されてもよい。ＳｏＣデバイスは、システムＬＳＩ（Ｌａｒｇｅ  Ｓｃａｌｅ  Ｉｎｔｅｇｒａｔｉｏｎ）またはチップセットと呼ばれることもある。
【００６４】
メモリは、揮発性メモリ若しくは不揮発性メモリ又はこれらの組合せである。メモリは、物理的に独立した複数のメモリデバイスを含んでもよい。揮発性メモリは、例えば、ＳＲＡＭ（Ｓｔａｔｉｃ  Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙ）若しくはＤＲＡＭ（Ｄｙｎａｍｉｃ  ＲＡＭ）又はこれらの組み合わせである。不揮発性メモリは、マスクＭ（Mask）ＲＯＭ（Ｒｅａｄ  Ｏｎｌｙ  Ｍｅｍｏｒｙ）、ＥＥＰＲＯＭ（Ｅｌｅｃｔｒｉｃａｌｌｙ  Ｅｒａｓａｂｌｅ  Ｐｒｏｇｒａｍｍａｂｌｅ  ＲＯＭ）、フラッシュメモリ、若しくはハードディスクドライブ、又はこれらの任意の組合せである。例えば、メモリは、ベースバンドプロセッサ、アプリケーションプロセッサ、及びＳｏＣからアクセス可能な外部メモリデバイスを含んでもよい。メモリは、ベースバンドプロセッサ内、アプリケーションプロセッサ内、又はＳｏＣ内に集積された内蔵メモリデバイスを含んでもよい。さらに、メモリは、ＵＩＣＣ（Ｕｎｉｖｅｒｓａｌ  Ｉｎｔｅｇｒａｔｅｄ  Ｃｉｒｃｕｉｔ  Ｃａｒｄ）内のメモリを含んでもよい。
【００６５】
メモリは、上述の複数の実施形態で説明されたＵＥによる処理を行うための命令群およびデータを含むソフトウェアモジュール（コンピュータプログラム）を格納してもよい。
いくつかの実装において、ベースバンドプロセッサ又はアプリケーションプロセッサは、当該ソフトウェアモジュールをメモリから読み出して実行することで、上述の実施形態で説明されたＵＥの処理を行うよう構成されてもよい。
（付記１）
コアネットワークと無線基地局と、その間に接続されるゲートウェイとを有する通信システムであって、
前記ゲートウェイが、前記無線基地局から、当該無線基地局のトラフィックに関する第１の情報を受信する手段を有する、通信システム。
【００６６】
この出願は、２０１５年９月１８日に出願された日本出願特願２０１５−１８５５７２を基礎とする優先権を主張し、その開示の全てをここに取り込む。
【符号の説明】
【００６７】
１    ＣＮ
２    ＨＮＢ−ＧＷ
３    ＨＮＢ
４、４１    セル
５、５１    ＵＥ
６、６１    ＳｅＧＷ
７、７１、７−１〜７−Ｎ、７１−１〜７１−Ｎ    制御信号処理サーバ
８、８１    負荷分散モジュール
２１    ＨｅＮＢ−ＧＷ
３１    ＨｅＮＢ
【図１】
2017047074.tif 000003
【図２】
2017047074.tif 000004
【図３】
2017047074.tif 000005
【図４】
2017047074.tif 000006
【図５】
2017047074.tif 000007
【図６】
2017047074.tif 000008
【図７】
2017047074.tif 000009
【図８】
2017047074.tif 000010
【図９】
2017047074.tif 000011
【図１０】
2017047074.tif 000012
【図１１】
2017047074.tif 000013
【図１２】
2017047074.tif 000014
【図１３】
2017047074.tif 000015
【図１４】
2017047074.tif 000016
【図１５】
2017047074.tif 000017
【図１６】
2017047074.tif 000018
【図１７】
2017047074.tif 000019
【図１８】
2017047074.tif 000020
【国際調査報告】
2017047074.tif 000021
2017047074.tif 000022
2017047074.tif 000023
2017047074.tif 000024