知財求人 - 知財ポータルサイト「IP Force」
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2024-04-30
(45)【発行日】2024-05-10
(54)【発明の名称】ノード装置及び通信端末のユーザデータを中継するノード装置の方法
(51)【国際特許分類】
H04W 28/08 20230101AFI20240501BHJP
H04M 11/00 20060101ALI20240501BHJP
H04W 92/14 20090101ALI20240501BHJP
【ＦＩ】
H04W28/08
H04M11/00 302
H04W92/14
【請求項の数】
4
(21)【出願番号】P 2020215053
(22)【出願日】2020-12-24
(62)【分割の表示】P 2017504863の分割
【原出願日】2016-03-07
(65)【公開番号】P2021064955
(43)【公開日】2021-04-22
【審査請求日】2020-12-24
【審判番号】
【審判請求日】2023-09-25
(31)【優先権主張番号】P 2015049573
(32)【優先日】2015-03-12
(33)【優先権主張国・地域又は機関】JP
(73)【特許権者】
【識別番号】000004237
【氏名又は名称】日本電気株式会社
(74)【代理人】
【識別番号】100103894
【弁理士】
【氏名又は名称】家入 健
(72)【発明者】
【氏名】水上 太介
(72)【発明者】
【氏名】大西 信慈
(72)【発明者】
【氏名】江頭 一廣
(72)【発明者】
【氏名】志賀 信吾
(72)【発明者】
【氏名】田村 利之
【合議体】
【審判長】廣川 浩
【審判官】圓道 浩史
【審判官】新田 亮
(56)【参考文献】
【文献】米国特許出願公開第２０１４／０３４７９９０（ＵＳ，Ａ１）
【文献】特開２０１３－２１９８３５（ＪＰ，Ａ）
【文献】米国特許出願公開第２０１３／０１３６０４７（ＵＳ，Ａ１）
(58)【調査した分野】(Int.Cl.，ＤＢ名)
H04B 7/24- 7/26
H04W 4/00-99/00
3GPP TSG RAN WG1-4
3GPP TSG SA WG1-4
3GPP TSG CT WG1,4
(57)【特許請求の範囲】
【請求項1】
通信端末と無線通信を行うノード装置であって、前記通信端末の移動管理を行っている移動管理装置が停止処理を開始するために、当該移動管理装置から、当該移動管理装置の識別情報と当該移動管理装置を停止する時間に関する情報と前記通信端末が利用可能な他の移動管理装置の情報とを含むIndicationメッセージを、受信する手段と、
前記時間が来ると、前記通信端末に関連して確立されているコネクションを削除する手段と、を備えるノード装置。
【請求項2】
通信端末と無線通信を行うノード装置の方法であって、前記通信端末の移動管理を行っている移動管理装置が停止処理を開始するために、当該移動管理装置から、当該移動管理装置の識別情報と当該移動管理装置を停止する時間に関する情報と前記通信端末が利用可能な他の移動管理装置の情報とを含むIndicationメッセージを、受信し、
前記時間が来ると、前記通信端末に関連して確立されているコネクションを削除する、方法。
【請求項3】
前記Indicationメッセージは、前記通信端末に関するコンテキスト情報を利用することができる移動管理装置のグループに関する情報を含んでいる、請求項１に記載のノード装置。
【請求項4】
前記Indicationメッセージは、前記通信端末に関するコンテキスト情報を利用することができる移動管理装置のグループに関する情報を含んでいる、請求項２に記載の方法。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は通信システムに関し、特に複数の通信制御装置の中から通信制御装置を選択する通信システムに関する。
【背景技術】
【0002】
スマートフォン及びタブレット端末の普及により、コアネットワークに配置されるＭＭＥ（Mobile Management Entity）は、これらのデバイスのアプリケーションが発生させる多種多様なシグナリングを処理しなければならない。また、ＭＴＣ（Machine Type Communication）サービスの提供、人が密集するイベントの実施、もしくは、災害の発生等、通信が発生する時間もしくは場所に応じて特性が大きく変化し、予見困難なシグナリングが増加している。こうした環境の中、モバイル通信事業者は、過剰投資を抑え、ＴＣＯ（Total Cost Ownership）を削減しながら、サービス品質を維持しなければならない。
【0003】
そこで、ＭＭＥには、装置の性能、保有リソースもしくは負荷状況等に応じて、動的にシグナリングの負荷分散を行う仕組みが求められている。例えば、非特許文献１には、ＭＭＥにおけるシグナリング制御の仕組みが開示されている。また、特許文献１には、ＭＭＥの輻輳回避のためｅＮＢ（evolved NodeB）単位に他のＭＭＥへ収容替えを行い負荷分散することが記載されている。
【先行技術文献】
【特許文献】
【0004】
【文献】特表２０１４－５３３０１１号公報
【非特許文献】
【0005】
【文献】3GPP TS 23.401 V13.1.0 (2014-12) 5.3.2 Attach procedure
【発明の概要】
【発明が解決しようとする課題】
【0006】
しかし、非特許文献１には、通信端末に関するＭＭ Ｃｏｎｔｅｘｔ（加入者データ）をはじめとする呼処理に必要な情報が一度特定のＭＭＥに生成されると、その通信端末に関する呼処理を行う際には、呼処理に必要な情報が生成されたＭＭＥを利用し続けることが記載されている。そのため、呼処理において、ＭＭＥの負荷状況等に応じて、利用するＭＭＥを動的に変更することができないという問題がある。また、特許文献１には、ｅＮＢ単位に収容替えを行うため、ＭＭＥの負荷分散が十分に行えなかったり、適切に行えなかったりすることがあるという問題がある。
【0007】
本発明の目的は、上記の問題を解決し、ＭＭＥの負荷をより効果的に分散することができる通信システム、通信制御装置、ノード装置及び通信方法を提供することにある。
【課題を解決するための手段】
【0008】
本発明の第１の態様にかかる通信システムは、複数の通信制御装置と、前記複数の通信制御装置と通信端末に関する呼処理を含む制御処理を実行するノード装置とを備える通信システムであって、前記複数の通信制御装置は、前記通信端末の加入者データを共有するコンテキスト共有グループを形成し、前記ノード装置は、前記コンテキスト共有グループ内の第１の通信制御装置を選択し、前記第１の通信制御装置へ呼処理メッセージを送信し、前記第１の通信制御装置は、前記コンテキスト共有グループにおいて共有される前記加入者データを用いて呼処理を実行するものである。
【0009】
本発明の第２の態様にかかる通信制御装置は、コンテキスト共有グループに属する他の通信制御装置と通信端末の加入者データを共有するコンテキスト共有部と、ノード装置から呼処理メッセージを受信すると、前記コンテキスト共有グループにおいて共有されている前記加入者データを用いて呼処理を実行するものである。
【0010】
本発明の第３の態様にかかるノード装置は、通信制御装置と通信端末に関する呼処理を含む制御処理を実行するノード装置であって、呼処理メッセージを送信するたびに、通信端末の加入者データを共有するコンテキスト共有グループに属する複数の通信制御装置の中から一の通信制御装置を選択し、選択した通信制御装置へ呼処理メッセージを含む制御処理メッセージを送信するものである。
【0011】
本発明の第４の態様にかかる通信方法は、複数の通信制御装置と、前記複数の通信制御装置と通信端末に関する呼処理を含む制御処理を実行するノード装置とを備える通信システムにおいて実行される通信方法であって、前記複数の通信制御装置は、前記通信端末の加入者データを共有するコンテキスト共有グループを形成し、前記ノード装置は、前記コンテキスト共有グループ内の第１の通信制御装置を選択し、選択した前記第１の通信制御装置へ呼処理メッセージを送信し、前記第１の通信制御装置は、前記コンテキスト共有グループにおいて共有される前記加入者データを用いて呼処理を実行するものである。
【発明の効果】
【0012】
本発明により、ＭＭＥの負荷状況等に応じて、ＭＭＥの負荷をより効果的に分散することができる通信システム、通信制御装置、ノード装置及び通信方法を提供することができる。
【図面の簡単な説明】
【0013】
【図1】実施の形態１にかかる通信システムの構成図である。
【図2】実施の形態２にかかる通信システムの構成図である。
【図3】実施の形態２にかかるＭＭＥの構成図である。
【図4】実施の形態２にかかるｅＮＢの構成図である。
【図5】実施の形態２にかかるＳ－ＧＷの構成図である。
【図6】実施の形態２にかかるＨＳＳの構成図である。
【図7】実施の形態２にかかるＭＭＥからｅＮＢに対するコンテキスト共有グループに関する情報の通知処理の流れを示す図である。
【図8】実施の形態２にかかるＭＭＥからｅＮＢに対するコンテキスト共有グループに関する情報の通知処理の流れを示す図である。
【図9】実施の形態２にかかるＭＭＥからｅＮＢに対するコンテキスト共有グループに関する情報の通知処理の流れを示す図である。
【図10】実施の形態２にかかるＭＭＥからＳ－ＧＷに対するコンテキスト共有グループに関する情報の通知処理の流れを示す図である。
【図11】実施の形態２にかかるＭＭＥからＳ－ＧＷに対するコンテキスト共有グループに関する情報の通知処理の流れを示す図である。
【図12】実施の形態２にかかるＭＭＥからＳ－ＧＷに対するコンテキスト共有グループに関する情報の通知処理の流れを示す図である。
【図13】実施の形態２にかかるＭＭＥからＳ－ＧＷに対するコンテキスト共有グループに関する情報の通知処理の流れを示す図である。
【図14】実施の形態２にかかるＭＭＥからＳ－ＧＷに対するコンテキスト共有グループに関する情報の通知処理の流れを示す図である。
【図15】実施の形態２にかかるＭＭＥからＨＳＳに対するコンテキスト共有グループに関する情報の通知処理の流れを示す図である。
【図16】実施の形態２にかかるＭＭＥからＨＳＳに対するコンテキスト共有グループに関する情報の通知処理の流れを示す図である。
【図17】実施の形態２にかかるＭＭＥからＨＳＳに対するコンテキスト共有グループに関する情報の通知処理の流れを示す図である。
【図18】実施の形態２にかかるｅＮＢ、Ｓ－ＧＷ及びＨＳＳが管理する管理情報を示す図である。
【図19】実施の形態２にかかる呼処理を示す図である。
【図20】実施の形態２にかかる呼処理を示す図である。
【図21】実施の形態３にかかるＭＭＥを増設した際に、ｅＮＢに対するコンテキスト共有グループに関する情報の通知処理の流れを示す図である。
【図22】実施の形態３にかかるＭＭＥを増設した際に、Ｓ－ＧＷに対するコンテキスト共有グループに関する情報の通知処理の流れを示す図である。
【図23】実施の形態３にかかるＭＭＥを増設した際に、Ｓ－ＧＷに対するコンテキスト共有グループに関する情報の通知処理の流れを示す図である。
【図24】実施の形態３にかかるＭＭＥを増設した際に、Ｓ－ＧＷに対するコンテキスト共有グループに関する情報の通知処理の流れを示す図である。
【図25】実施の形態３にかかるＭＭＥを減設した際に、ｅＮＢに対するコンテキスト共有グループに関する情報の通知処理の流れを示す図である。
【図26】実施の形態４にかかるＭＭＥを減設した際に、ｅＮＢに対するコンテキスト共有グループに関する情報の通知処理の流れを示す図である。
【図27】実施の形態４にかかるＭＭＥを減設した際に、Ｓ－ＧＷに対するコンテキスト共有グループに関する情報の通知処理の流れを示す図である。
【図28】実施の形態４にかかるＭＭＥを減設した際に、Ｓ－ＧＷに対するコンテキスト共有グループに関する情報の通知処理の流れを示す図である。
【図29】実施の形態４にかかるＭＭＥを減設した際に、Ｓ－ＧＷに対するコンテキスト共有グループに関する情報の通知処理の流れを示す図である。
【図30】実施の形態４にかかるＭＭＥを減設した際に、ＨＳＳに対するコンテキスト共有グループに関する情報の通知処理の流れを示す図である。
【図31】実施の形態４にかかるＭＭＥを減設した際に、ＨＳＳに対するコンテキスト共有グループに関する情報の通知処理の流れを示す図である。
【図32】実施の形態５にかかるＭＭＥのＷＦを変更した際に、ｅＮＢに対するコンテキスト共有グループに関する情報の通知処理の流れを示す図である。
【図33】実施の形態６にかかるＨＳＳに関するインタフェースを説明する図である。
【図34】実施の形態６にかかるＨＳＳに関するインタフェースを説明する図である。
【図35】実施の形態６にかかるＣｏｎｔｅｘｔ情報の格納処理の流れ示す図である。
【図36】実施の形態６にかかるＣｏｎｔｅｘｔ情報の格納処理の流れ示す図である。
【図37】実施の形態７にかかる通信システムの構成図である。
【発明を実施するための形態】
【0014】
（実施の形態１）
以下、図面を参照して本発明の実施の形態について説明する。はじめに、図１を用いて本発明の実施の形態１にかかる通信システムの構成例について説明する。図１の通信システムは、通信制御装置１０～１２及びノード装置２０を有する。本図においては、ノード装置２０が通信制御装置１０～１２と接続していることを示しているが、ノード装置２０は、２台、あるいは３台以上の通信制御装置と接続してもよい。
以下、図面を参照して本発明の実施の形態について説明する。はじめに、図１を用いて本発明の実施の形態１にかかる通信システムの構成例について説明する。図１の通信システムは、通信制御装置１０～１２及びノード装置２０を有する。本図においては、ノード装置２０が通信制御装置１０～１２と接続していることを示しているが、ノード装置２０は、２台、あるいは３台以上の通信制御装置と接続してもよい。
【0015】
通信制御装置１０～１２は、ＣＰＵ(Central Processing Unit)がメモリに格納されたプログラムを実行することによって動作するコンピュータ装置であってもよい。また、通信制御装置１０～１２は、３ＧＰＰ（3rd Generation Partnership Project）において規定されているＭＭＥもしくはＳＧＳＮ（Serving GPRS Support Node）であってもよい。
【0016】
ノード装置２０は、通信制御装置１０～１２との間において通信端末に関する呼処理を含む制御処理を実行する。呼処理とは、例えば、通信端末が音声通話もしくはデータ通信等を行う際に実行される、コアネットワーク内の経路設定等の制御処理に相当する。ノード装置２０は、ＣＰＵ(Central Processing Unit)がメモリに格納されたプログラムを実行することによって動作するコンピュータ装置であってもよい。また、ノード装置２０は、３ＧＰＰにおいて規定されているｅＮＢ（evolved Node B）、ＲＮＣ（Radio Network Controller）、Ｓ－ＧＷ（Serving Gateway）もしくはＨＳＳ（Home Subscriber Server）等であってもよい。
【0017】
通信端末は、例えば、携帯電話、スマートフォンもしくは通信機能を有するタブレット端末等であってもよい。また、通信端末は、パーソナルコンピュータ等のコンピュータ装置であってもよい。
【0018】
通信制御装置１０～１２は、通信端末の加入者データを共有するコンテキスト共有グループを形成する。加入者データを共有するとは、通信制御装置１０が利用することができる加入者データを、通信制御装置１１及び１２も利用することができることである。例えば、加入者データを管理するサーバ装置がある場合、通信制御装置１０～１２は、サーバ装置から適宜加入者データを取得してもよい。もしくは、それぞれの通信制御装置間において、加入者データを送受信することによって、他の通信制御装置において保持されている加入者データを取得してもよい。
【0019】
ノード装置２０は、通信端末に関する呼処理、あるいは制御処理を実行する場合、コンテキスト共有グループ内のいずれかの通信制御装置を選択する。さらに、ノード装置２０は、選択した通信制御装置へ、呼処理メッセージ、あるいは制御メッセージを送信する。呼処理メッセージは、例えば、３ＧＰＰにおいて規定されている制御メッセージであってもよい。３ＧＰＰにおいては、例えば、通信端末の電源がＯＮ状態に遷移した場合に送信されるＡｔｔａｃｈ Ｒｅｑｕｅｓｔメッセージ等、様々な制御メッセージが規定されている。ノード装置は、通信制御装置から通知される情報（例えば、各通信制御装置の輻輳状況や、各通信制御装置のキャパシティ、通信制御装置間で共有している加入者データ（コンテキスト共有グループ）の情報など）に基づいて、通信制御装置を選択する。
【0020】
ノード装置２０において選択された通信制御装置、つまり、ノード装置２０から送信された呼処理メッセージ、あるいは制御メッセージを受信した通信制御装置は、コンテキスト共有グループにおいて共有される加入者データを用いて呼処理、あるいは制御処理を実行する。例えば、ノード装置２０において選択された通信制御装置は、自装置内に呼処理の対象となる通信端末の加入者データを保持している場合、保持している加入者データを用いて呼処理、あるいは制御処理を実行する。ノード装置２０において選択された通信制御装置は、自装置内に呼処理の対象となる通信端末の加入者データを保持していない場合、サーバ装置において管理されている加入者データを取得してもよく、他の通信制御装置から加入者データを取得してもよい。
【0021】
以上説明したように、図１の通信システムを用いることにより、コンテキスト共有グループに属する通信制御装置は、通信端末の加入者データを共有することができる。そのため、ノード装置は、コンテキスト共有グループに属するいずれの通信制御装置を選択しても、通信端末の呼処理、あるいは制御処理を実行することができる。
【0022】
これより、ノード装置２０は、呼処理、あるいは制御処理を実行する際に通信を行う通信制御装置を動的に変更することができる。そのため、ノード装置２０は、例えば、通信制御装置の負荷状況に応じて、通信制御装置を変更することもできる。その結果、ノード装置２０は、複数の通信制御装置における負荷分散制御を行うことができる。また、ノード装置は、加入者データを共有する通信制御装置に対して、加入者単位に呼処理メッセージ、あるいは制御メッセージを分散することができる。そのため、ノード装置単位にメッセージを分散する場合と比較して、ノード装置は、通信制御装置に対して、細かな単位でより適切にメッセージの分散を行うことができる。
【0023】
（実施の形態２）
続いて、図２を用いて本発明の実施の形態２にかかる通信システムの構成例について説明する。図２の通信システムは、３ＧＰＰにおいて規定されている装置によって構成されている。図２の通信システムは、ＭＭＥ３０～６０、ｅＮＢ７０、ＨＳＳ８０、Ｓ－ＧＷ９０、Ｐ－ＧＷ（Packet Data Network-Gateway）１００及びＵＥ（User Equipment）１１０を有している。ＭＭＥ３０～６０は、図１の通信制御装置に相当する。ｅＮＢ７０、ＨＳＳ８０及びＳ－ＧＷ９０は、図１のノード装置に相当する。ＵＥ１１０は、通信端末に相当する。
続いて、図２を用いて本発明の実施の形態２にかかる通信システムの構成例について説明する。図２の通信システムは、３ＧＰＰにおいて規定されている装置によって構成されている。図２の通信システムは、ＭＭＥ３０～６０、ｅＮＢ７０、ＨＳＳ８０、Ｓ－ＧＷ９０、Ｐ－ＧＷ（Packet Data Network-Gateway）１００及びＵＥ（User Equipment）１１０を有している。ＭＭＥ３０～６０は、図１の通信制御装置に相当する。ｅＮＢ７０、ＨＳＳ８０及びＳ－ＧＷ９０は、図１のノード装置に相当する。ＵＥ１１０は、通信端末に相当する。
【0024】
また、ＭＭＥは、３ＧＰＰにおいて規定されているＳＧＳＮに置き換えられてもよく、ｅＮＢは、３ＧＰＰにおいて規定されているＲＮＣに置き換えられてもよい。
【0025】
本図においては、ＭＭＥ３０及びＭＭＥ４０が、コンテキスト共有グループＡに属し、ＭＭＥ５０及びＭＭＥ６０が、コンテキスト共有グループＢに属することを示している。また、ＭＭＥ３０～６０は、コンテキスト共有グループとは異なるグループであるＭＭＥグループに属してもよい。ＭＭＥグループは、ｅＮＢ７０がはじめにＣｏｎｔｅｘｔ情報を生成する候補のＭＭＥが属するグループである。Ｃｏｎｔｅｘｔ情報は、図１において説明した加入者データに相当する。つまり、ＭＭＥグループは、複数のコンテキスト共有グループを含んでもよい。もしくは、ＭＭＥグループに属するＭＭＥと、コンテキスト共有グループに属するＭＭＥとは、同じであってもよい。
【0026】
一般的に、ｅＮＢ７０は、はじめにＭＭＥ３０においてＵＥ１１０に関するＣｏｎｔｅｘｔ情報を生成することを決定した場合、以降の呼処理においてはすべてＭＭＥ３０を選択する。これに対して、本願の各実施の形態においては、ｅＮＢ７０は、はじめにＭＭＥ３０においてＣｏｎｔｅｘｔ情報を生成した場合であっても、以降の呼処理において、ＭＭＥ３０もしくはＭＭＥ４０を選択することができる。また、ＨＳＳ８０及びＳ－ＧＷ９０も、最初にＣｏｎｔｅｘｔ情報が生成されたＭＭＥとは異なるＭＭＥを選択して呼処理を実行することができる。
【0027】
続いて、図３を用いて本発明の実施の形態２にかかるＭＭＥ３０の構成例について説明する。ＭＭＥ４０～６０は、ＭＭＥ３０と実質的に同一の構成であるため、詳細な説明を省略する。
【0028】
ＭＭＥ３０は、Ｄｉａｍｅｔｅｒ通信部３１、Ｓ１ＡＰ（S1 Application）通信部３２、ＧＴＰ（General packet radio service Tunneling Protocol）－Ｃ通信部３３、Ｃｏｎｔｅｘｔ共有部３４、Ｃｏｎｔｅｘｔ記憶部３５及びＭＭＥ呼処理部３６を有している。Ｄｉａｍｅｔｅｒ通信部３１は、ＨＳＳ８０との間のインタフェースとして用いられる。Ｓ１ＡＰ通信部３２は、ｅＮＢ７０との間のインタフェースとして用いられる。ＧＴＰ－Ｃ通信部３３は、Ｓ－ＧＷ９０との間のインタフェースとして用いられる。
【0029】
Ｃｏｎｔｅｘｔ共有部３４は、呼処理の対象となるＵＥ１１０のＣｏｎｔｅｘｔ情報を取得する。例えば、サーバ装置等において、コンテキスト共有グループＡのＭＭＥにおいて生成されたＣｏｎｔｅｘｔ情報が管理されている場合、Ｃｏｎｔｅｘｔ共有部３４は、サーバ装置から呼処理の対象となるＵＥ１１０のＣｏｎｔｅｘｔ情報を取得してもよい。もしくは、Ｃｏｎｔｅｘｔ共有部３４は、呼処理の対象となるＵＥ１１０のＣｏｎｔｅｘｔ情報をコンテキスト拒有グループＡに属するＭＭＥ４０から取得してもよい。
【0030】
Ｃｏｎｔｅｘｔ記憶部３５は、Ｃｏｎｔｅｘｔ共有部３４が取得したＣｏｎｔｅｘｔ情報及びＭＭＥ３０において生成されたＣｏｎｔｅｘｔ情報を記憶する。Ｃｏｎｔｅｘｔ記憶部３５は、例えば、ＭＭＥ３０内のメモリであってもよく、ＭＭＥ３０に装着された外部メモリ装置等であってもよい。または、ＨＳＳ８０がＣｏｎｔｅｘｔ情報を保持し複数のＭＭＥが必要に応じてアクセスする事によりＣｏｎｔｅｘｔ情報が複数のＭＭＥ間で共有されても良い。
【0031】
さらに、Ｃｏｎｔｅｘｔ記憶部３５は、ＭＭＥ３０が属するコンテキスト共有グループに関する情報を保持する。ここでは、Ｃｏｎｔｅｘｔ記憶部３５は、コンテキスト共有グループＡを示す情報を保持する。Ｃｏｎｔｅｘｔ記憶部３５は、例えば、ＭＭＥ３０内のメモリであってもよく、ＭＭＥ３０に装着された外部メモリ装置等であってもよい。または、ＨＳＳ８０がＣｏｎｔｅｘｔ記憶部３５を保持し複数のＭＭＥが必要に応じてアクセスする事によりＣｏｎｔｅｘｔ記憶部３５が保持する情報が複数のＭＭＥ間で共有されても良い。
【0032】
ＭＭＥ呼処理部３６は、Ｃｏｎｔｅｘｔ記憶部３５に記憶されているＣｏｎｔｅｘｔ情報及びコンテキスト共有グループＡを示す情報を用いて、呼処理を実行する。ＭＭＥ呼処理部３６は、Ｄｉａｍｅｔｅｒ通信部３１、Ｓ１ＡＰ通信部３２もしくはＧＴＰ－Ｃ通信部３３を介して、呼処理に関するメッセージをｅＮＢ７０、ＨＳＳ８０もしくはＳ－ＧＷ９０との間において送受信する。
【0033】
続いて、図４を用いて本発明の実施の形態２にかかるｅＮＢ７０の構成例について説明する。ｅＮＢ７０は、Ｓ１ＡＰ通信部７１、Ｓ１ＡＰ呼処理部７２、ＲＲＣ（Radio Resource Control）処理部７３、無線処理部７４、ＧＴＰ－Ｕ通信部７５、ＧＴＰ－Ｕ処理部７６及びＣｏｎｔｅｘｔ記憶部７７を有している。
【0034】
Ｓ１ＡＰ通信部７１は、ＭＭＥ３０～６０と通信する際のインタフェースとして用いられる。Ｓ１ＡＰ呼処理部７２は、Ｃｏｎｔｅｘｔ記憶部７７に記憶されている情報を用いて、ＭＭＥ３０～６０との間において呼処理を実行する。
【0035】
Ｓ１ＡＰ呼処理部７２は、Ｓ１ＡＰ通信部７１を介してＭＭＥ３０～６０との間において呼処理に関するメッセージを送受信する。また、Ｓ１ＡＰ呼処理部７２は、Ｃｏｎｔｅｘｔ記憶部７７に記憶されている情報を用いて、呼処理を行うＭＭＥを選択する。
【0036】
ＲＲＣ（Radio Resource Control）処理部７３は、ＵＥ１１０との間において用いられるＲＲＣプロトコルに関する処理を実行する。例えば、ＲＲＣ処理部７３は、ＵＥ１１０との間の接続状態を管理する処理を実行してもよい。無線処理部７４は、ＵＥ１１０と無線通信する際のインタフェースとして用いられる。
【0037】
ＧＴＰ－Ｕ通信部７５は、Ｓ－ＧＷ９０と通信する際のインタフェースとして用いられる。ＧＴＰ－Ｕ処理部７６は、ＧＴＰ－Ｕ通信部７５を介して、Ｓ－ＧＷ９０との間においてユーザデータの送受信を行う。
【0038】
Ｃｏｎｔｅｘｔ記憶部７７は、ＭＭＥ３０～６０から送信されるコンテキスト共有グループに関する情報を記憶する。例えば、Ｃｏｎｔｅｘｔ記憶部７７は、コンテキスト共有グループと、そのグループに属するＭＭＥとを関連付けて記憶する。さらに、Ｃｏｎｔｅｘｔ記憶部７７は、それぞれのＭＭＥを選択する際に参照するＷＦ（Weight Factor）をＭＭＥと関連付けて記憶してもよい。
【0039】
続いて、図５を用いて本発明の実施の形態２にかかるＳ－ＧＷ９０の構成例について説明する。Ｓ－ＧＷ９０は、ＧＴＰ－Ｃ通信部９１、ＧＴＰ－Ｕ通信部９２、ＧＴＰ－Ｃ処理部９３、Ｃｏｎｔｅｘｔ記憶部９４及びＧＴＰ－Ｕ処理部９５を有している。
【0040】
ＧＴＰ－Ｃ通信部９１は、ＭＭＥ３０～６０と通信する際のインタフェースとして用いられる。ＧＴＰ－Ｕ通信部９２は、ｅＮＢ７０と通信する際のインタフェースとして用いられる。
【0041】
ＧＴＰ－Ｃ処理部９３は、ＧＴＰ－Ｃ通信部９１を介してＭＭＥ３０～６０との間において呼処理に関するメッセージを送受信する。また、ＧＴＰ－Ｃ処理部９３は、Ｃｏｎｔｅｘｔ記憶部９４に記憶されている情報を用いて、呼処理を行うＭＭＥを選択する。ＧＴＰ－Ｕ処理部９５は、ＧＴＰ－Ｕ通信部９２を介してｅＮＢ７０との間においてユーザデータを送受信する。
【0042】
Ｃｏｎｔｅｘｔ記憶部９４は、ＭＭＥ３０～６０から送信されるコンテキスト共有グループに関する情報を記憶する。例えば、Ｃｏｎｔｅｘｔ記憶部７７は、コンテキスト共有グループと、そのグループに属するＭＭＥとを関連付けて記憶する。さらに、それぞれのＭＭＥを選択する際に参照するＷＦをＭＭＥと関連付けて記憶してもよい。
【0043】
続いて、図６を用いて本発明の実施の形態２にかかるＨＳＳ８０の構成例について説明する。ＨＳＳ８０は、Ｄｉａｍｅｔｅｒ通信部８１、加入者情報処理部８２及び加入者情報記憶部８３を有している。Ｄｉａｍｅｔｅｒ通信部８１は、ＭＭＥ３０～６０と通信する際にインタフェースとして用いられる。
【0044】
加入者情報記憶部８３は、ＭＭＥ３０～６０から送信されるコンテキスト共有グループに関する情報を記憶する。例えば、加入者情報記憶部８３は、コンテキスト共有グループと、そのグループに属するＭＭＥとを関連付けて記憶する。さらに加入者情報記憶部８３は、それぞれのＭＭＥを選択する際に参照するＷＦをＭＭＥと関連付けて記憶してもよい。
【0045】
加入者情報処理部８２は、Ｄｉａｍｅｔｅｒ通信部８１を介してＭＭＥ３０～６０との間において呼処理に関するメッセージを送受信する。また、加入者情報処理部８２は、加入者情報記憶部８３に記憶されている情報を用いて、呼処理を行うＭＭＥを選択する。
【0046】
続いて、図７を用いて本発明の実施の形態２にかかるＭＭＥからｅＮＢに対するコンテキスト共有グループに関する情報の通知処理の流れについて説明する。はじめに、ｅＮＢ７０は、Ｓ１コネクションを確立するために、ＭＭＥグループ内の全てのＭＭＥに対して、S1 SETUP REQUESTメッセージを送信する（Ｓ１１）。
【0047】
次に、それぞれのＭＭＥは、S1 SETUP REQUESTメッセージへの応答として、S1 SETUP RESPONSEメッセージをｅＮＢ７０へ送信する（Ｓ１２）。それぞれのＭＭＥは、S1 SETUP RESPONSEメッセージに、自装置が属するコンテキスト共有グループ、ＧＵＭＭＥＩ（Globally Unique MME Identifier）及びＷＦ（Weight Factor）を設定する。ＧＵＭＭＥＩは、ＭＭＥを一意に識別するための識別情報である。ＷＦは、ｅＮＢ７０が呼処理を実行するＭＭＥを選択する際に用いる優先度情報である。例えば、ｅＮＢ７０は、ＷＦの値が高いＭＭＥを選択する回数を多くし、ＷＦの値が低いＭＭＥを選択する回数を少なくしてもよい。ｅＮＢ７０は、S1 SETUP RESPONSEメッセージに設定される情報を保持する。
【0048】
続いて、図８を用いて本発明の実施の形態２にかかるコンテキスト共有グループに関する情報の通知処理について、図７と異なる通知処理の流れについて説明する。はじめに、ＭＭＥ３０及びＭＭＥ４０は、どちらが代表ＭＭＥであるかを決定する代表選択処理を実施する（Ｓ２０）。代表選択処理は、同一のコンテキスト共有グループに属する複数のＭＭＥ間において実行される。例えば、代表ＭＭＥには、若番の識別情報が設定されているＭＭＥが選択されてもよく、その他の基準により代表ＭＭＥが選択されてもよい。ここでは、ＭＭＥ３０が代表ＭＭＥとして選択されたとする。また、代表選択処理において、代表ＭＭＥではないＭＭＥ４０等は、代表ＭＭＥへ、自装置のＧＵＭＭＥＩ及びＷＦ等の情報を送信してもよい。
【0049】
次に、ｅＮＢ７０は、Ｓ１コネクションを確立するために、ＭＭＥグループ内の全てのＭＭＥに対して、S1 SETUP REQUESTメッセージを送信する（Ｓ２１）。なお、図８においては、ｅＮＢ７０が、ＭＭＥ３０及びＭＭＥ４０にS1 SETUP REQUESTメッセージを送信していることを示しているが、ＭＭＥグループ内の全てのＭＭＥに対してS1 SETUP REQUESTメッセージが送信されているとする。
【0050】
次に、代表ＭＭＥであるＭＭＥ３０は、ｅＮＢ７０に対して、コンテキスト共有グループ、コンテキスト共有グループに属する全てのＭＭＥのＧＵＭＭＥＩ、及び、全てのＭＭＥのＷＦを設定したS1 SETUP RESPONSEメッセージを送信する（Ｓ２２）。代表ＭＭＥではないＭＭＥ４０は、Ｓ１コネクションの確立のために、S1 SETUP RESPONSEメッセージをｅＮＢ７０へ送信する。ＭＭＥ４０が送信するS1 SETUP RESPONSEメッセージには、コンテキスト共有グループに関する情報が設定されていなくてもよい。
【0051】
続いて、図９を用いて、本発明の実施の形態２にかかるコンテキスト共有グループに関する情報の通知処理について、図７及び図８と異なる通知処理の流れについて説明する。本図においては、ＥＭＳ（Element Management System）装置が、ｅＮＢ７０に対して、コンテキスト共有グループ、コンテキスト共有グループに属する全てのＭＭＥのＧＵＭＭＥＩ、及び、全てのＭＭＥのＷＦに関する情報を登録する（Ｓ３１）。
【0052】
続いて、図１０を用いて、本発明の実施の形態２にかかるＭＭＥからＳ－ＧＷに対するコンテキスト共有グループに関する情報の通知処理の流れについて説明する。はじめに、それぞれのＭＭＥは、自装置が属するコンテキスト共有グループ及びＷＦを設定したGTP Echo REQUESTメッセージをＳ－ＧＷ９０へ送信する（Ｓ４１）。Ｓ－ＧＷ９０は、GTP Echo REQUESTメッセージの送信元のＩＰアドレスを用いて、ＭＭＥを識別する。Ｓ－ＧＷ９０は、GTP Echo REQUESTメッセージに設定されている情報を保持する。
【0053】
次に、Ｓ－ＧＷ９０は、GTP Echo RESPONSEメッセージをそれぞれのＭＭＥへ送信する（Ｓ４２）。一般的に、GTP Echo REQUESTメッセージ及びGTP Echo RESPONSEメッセージは、ＭＭＥとＳ－ＧＷとの間において障害が発生しているか否かを確認するために用いられる。
【0054】
続いて、図１１を用いて、本発明の実施の形態２にかかるコンテキスト共有グループに関する情報の通知処理について、図１０と異なる通知処理の流れについて説明する。本図においては、Ｓ－ＧＷ９０が、GTP Echo REQUESTメッセージをそれぞれのＭＭＥへ送信する（Ｓ５１）。次に、それぞれのＭＭＥは、自装置が属するコンテキスト共有グループ及びＷＦを設定したGTP Echo RESPONSEメッセージをＳ－ＧＷ９０へ送信する（Ｓ５２）。
【0055】
【0056】
はじめに、ＭＭＥ３０及びＭＭＥ４０は、どちらが代表ＭＭＥであるかを決定する代表選択処理を実施する（Ｓ６０）。代表選択処理は、同一のコンテキスト共有グループに属する複数のＭＭＥ間において実行される。ここでは、ＭＭＥ３０が代表ＭＭＥとして選択されたとする。
【0057】
次に、代表ＭＭＥであるＭＭＥ３０は、Ｓ－ＧＷ９０に対して、コンテキスト共有グループ及びコンテキスト共有グループに属する全てのＭＭＥのＷＦを設定したGTP Echo REQUESTメッセージを送信する（Ｓ６１）。ＭＭＥ３０は、コンテキスト共有グループに属するＭＭＥの識別情報であるＩＰアドレスとＷＦとを関連付けて設定してもよい。代表ＭＭＥではないＭＭＥ４０は、通常のGTP Echo REQUESTメッセージをＳ－ＧＷ９０へ送信する（Ｓ６２）。
【0058】
次に、Ｓ－ＧＷ９０は、GTP Echo REQUESTメッセージに対する応答メッセージとして、GTP Echo RESPONSEメッセージをそれぞれのＭＭＥへ送信する（Ｓ６３）。
【0059】
続いて、図１３を用いて、本発明の実施の形態２にかかるコンテキスト共有グループ情報の通知処理について、図１０～図１２と異なる通知処理の流れについて説明する。はじめに、ＭＭＥ３０及びＭＭＥ４０は、図１２のステップＳ６０と同様に、代表選択処理を実施する（Ｓ７０）。次に、Ｓ－ＧＷ９０は、ＭＭＥグループ内の全てのＭＭＥに対してGTP Echo REQUESTメッセージを送信する（Ｓ７１）。
【0060】
次に、代表ＭＭＥであるＭＭＥ３０は、GTP Echo REQUESTメッセージに対する応答メッセージとして、コンテキスト共有グループ及びコンテキスト共有グループに属する全てのＭＭＥのＷＦを設定したGTP Echo REQUESTメッセージをＳ－ＧＷ９０へ送信する（Ｓ７２）。
【0061】
代表ＭＭＥではないＭＭＥ４０は、GTP Echo REQUESTメッセージに対する応答メッセージとして、通常のGTP Echo RESPONSEメッセージをＳ－ＧＷ９０へ送信する（Ｓ７３）。
【0062】
続いて、図１４を用いて、本発明の実施の形態２にかかるコンテキスト共有グループ情報の通知処理について、図１０～図１３と異なる通知処理の流れについて説明する。本図においては、ＥＭＳ（Element Management System）装置が、Ｓ－ＧＷ９０に対して、コンテキスト共有グループ、コンテキスト共有グループに属する全てのＭＭＥのＷＦに関する情報を登録する（Ｓ８１）。
【0063】
続いて、図１５を用いて本発明の実施の形態２にかかるＭＭＥからＨＳＳ８０に対するコンテキスト共有グループ情報の通知処理の流れについて説明する。はじめに、それぞれのＭＭＥは、ＨＳＳ８０との間においてSCTP（Stream Control Transmission Protocol） Connectionを確立する（Ｓ９０）。
【0064】
次に、それぞれのＭＭＥは、自装置が属するコンテキスト共有グループ、Ｏｒｉｇｉｎ－Ｈｏｓｔ及びＷＦを設定したUpdate Context Shared Group REQUESTメッセージをＨＳＳ８０へ送信する（Ｓ９１）。Ｏｒｉｇｉｎ－Ｈｏｓｔは、ＭＭＥを識別する情報である。ＨＳＳ８０は、Update Context Shared Group REQUESTメッセージに設定される情報を保持する。
【0065】
次に、ＨＳＳ８０は、Update Context Shared Group REQUESTメッセージに対する応答として、Update Context Shared Group ANSWERメッセージをそれぞれのＭＭＥへ送信する（Ｓ９２）。
【0066】
続いて、図１６を用いて、本発明の実施の形態２にかかるコンテキスト共有グループ情報の通知処理について、図１５と異なる通知処理の流れについて説明する。はじめに、ＭＭＥ３０及びＭＭＥ４０は、図１５のステップＳ９０と同様に、SCTP Connectionを確立する（Ｓ１００）。次に、ＭＭＥ３０及びＭＭＥ４０は、どちらが代表ＭＭＥであるかを決定する代表選択処理を実施する（Ｓ１０１）。代表選択処理は、同一のコンテキスト共有グループに属する複数のＭＭＥ間において実行される。ここでは、ＭＭＥ３０が代表ＭＭＥとして選択されたとする。
【0067】
次に、代表ＭＭＥであるＭＭＥ３０は、コンテキスト共有グループ、コンテキスト共有グループに属する全てのＭＭＥのＯｒｉｇｉｎ－Ｈｏｓｔ及びコンテキスト共有グループに属する全てのＭＭＥのＷＦを設定したUpdate Context Shared Group REQUESTメッセージをＨＳＳ８０へ送信する（Ｓ１０２）。次に、ＨＳＳ８０は、Update Context Shared Group REQUESTメッセージに対する応答として、Update Context Shared Group ANSWERメッセージをＭＭＥ３０へ送信する（Ｓ１０３）。
【0068】
続いて、図１７を用いて、本発明の実施の形態２にかかるコンテキスト共有グループ情報の通知処理について、図１５及び図１６と異なる通知処理の流れについて説明する。本図においては、ＥＭＳ（Element Management System）装置が、ＨＳＳ８０に対して、コンテキスト共有グループ、コンテキスト共有グループに属する全てのＭＭＥのＷＦに関する情報を登録する（Ｓ１１１）。
【0069】
図７～図１７において、コンテキスト共有グループに関する情報を受信したｅＮＢ７０、Ｓ－ＧＷ９０及びＨＳＳ８０は、図１８に示すようにコンテキスト共有グループに関する情報を管理する。図１８に示す管理情報は、コンテキスト共有グループと、コンテキスト共有グループに属するＭＭＥとを関連付けて管理している。さらに、ＭＭＥに設定されたＷＦの値についてもＭＭＥ毎に関連付けて管理している。コンテキスト共有グループＡには、ＭＭＥ３０～ＭＭＥ＃Ｎが属し、コンテキスト共有グループＢには、ＭＭＥ５０及びＭＭＥ６０が属する。また、例えば、ＭＭＥ３０は、コンテキスト共有グループＡに属し、ＷＦの値が５０であることが示されている。
【0070】
また、ＭＭＥを識別する情報は、ノードの種類によって異なってもよい。例えば、ｅＮＢは、ＭＭＥの識別情報としてＧＵＭＭＥＩを用い、ＳＧＷは、ＭＭＥの識別情報としてＩＰアドレスを用い、ＨＳＳは、Ｏｒｉｇｉｎ－Ｈｏｓｔを用いてもよい。
【0071】
続いて、図１９及び図２０を用いて、本発明の実施の形態２にかかる呼処理の流れについて説明する。はじめに、ＵＥ１１０は、ユーザによって電源ボタンが押下され、装置が起動された場合に、NAS（Non-Access Stratum）:Attach REQUESTメッセージをｅＮＢ７０へ送信する（Ｓ１２１）。ＵＥ１１０は、NAS:Attach REQUESTメッセージに、ＧＵＴＩ（Globally Unique Temporary Identifier）を設定する。ＧＵＴＩは、ＧＵＭＭＥＩ及びＭ-ＴＭＳＩ（Temporary Mobile Subscriber Identity）から構成される情報である。ＧＵＴＩは、ＵＥを一意に識別するために用いられる一時的な識別情報である。
【0072】
次に、ｅＮＢ７０は、NAS:Attach REQUESTメッセージを送信するＭＭＥを選択する処理を行う（Ｓ１２２）。ｅＮＢ７０は、ＭＭＥを選択する処理において、NAS:Attach REQUESTメッセージに設定されているＧＵＴＩから、ＧＵＭＭＥＩを特定する。ＧＵＴＩから特定されるＧＵＭＭＥＩは、以前のAttach処理において、ＵＥ１１０に関するＣｏｎｔｅｘｔ情報を生成したＭＭＥ、もしくは、ｅＮＢが選択したＭＭＥを示している。ｅＮＢ７０は、図１８に示す管理情報から、ＧＵＭＭＥＩによって識別されるＭＭＥが属するコンテキスト共有グループを特定することができる。ｅＮＢ７０は、特定したコンテキスト共有グループに属するＭＭＥの中から、ＷＦに従ってＭＭＥを選択する。本図においては、ｅＮＢ７０は、ＭＭＥ３０を選択したとする。
【0073】
次に、ｅＮＢ７０は、選択したＭＭＥへ、NAS:Attach REQUEST／S1AP: Initial UEメッセージを送信する（Ｓ１２３）。次に、ＭＭＥ３０は、ＵＥ１１０に関する認証ベクトル（Authentication Vector：AV）を取得するために、ＨＳＳ８０へAuthentication Information REQUESTメッセージを選択する（Ｓ１２４）。次に、ＨＳＳ８０は、ＡＶを設定したAuthentication Information ANSWERメッセージの送信先となるＭＭＥを選択する処理を行う（Ｓ１２５）。ＨＳＳ８０は、図１８に示す管理情報を用いて、Authentication Information REQUESTメッセージを送信してきたＭＭＥ３０の属するコンテキスト共有グループを特定する。ＨＳＳ８０は、特定したコンテキスト共有グループに属するＭＭＥの中から、ＷＦに従ってＭＭＥを選択する。本図においては、ＨＳＳ８０は、ＭＭＥ＃Ｎを選択したとする。ＭＭＥ＃Ｎは、ＭＭＥ３０と同じコンテキスト共有グループＡに含まれるとする。
【0074】
次に、ＨＳＳ８０は、Authentication Information ANSWERメッセージを、選択したＭＭＥ＃Ｎへ送信する（Ｓ１２６）。このように、ＨＳＳ８０は、Authentication Information REQUESTメッセージを送信してきたＭＭＥ３０と異なるＭＭＥ＃Ｎへ、Authentication Information ANSWERメッセージを送信することができる。次に、ＭＭＥ＃Ｎは、ｅＮＢ７０へ、Authentication REQUESTメッセージを送信する（Ｓ１２７）。
【0075】
図２０に移り、ＭＭＥ３０は、Ｓ－ＧＷ９０との間のセッションを生成するために、Create Session REQUESTメッセージをＳ－ＧＷ９０へ送信する（Ｓ１２８）。次に、Ｓ－ＧＷ９０は、Create Session RESPONSEメッセージの送信先となるＭＭＥを選択する処理を行う（Ｓ１２９）。Ｓ－ＧＷ９０は、図１８の管理情報を用いて、Create Session REQUESTメッセージを送信してきたＭＭＥ３０の属するコンテキスト共有グループを特定する。Ｓ－ＧＷ９０は、特定したコンテキスト共有グループに属するＭＭＥの中から、ＷＦに従ってＭＭＥを選択する。本図においては、Ｓ－ＧＷ９０は、ＭＭＥ＃Ｎを選択したとする。
【0076】
次に、Ｓ－ＧＷ９０は、Create Session RESPONSEメッセージを、選択したＭＭＥ＃Ｎへ送信する（Ｓ１３０）。このように、Ｓ－ＧＷ９０は、Create Session REQUESTメッセージを送信してきたＭＭＥ３０と異なるＭＭＥ＃Ｎへ、Create Session RESPONSEメッセージを送信することができる。
【0077】
次に、ＭＭＥ＃Ｎは、NAS:Attach Accept／S1AP:Initial Context Setup RequestメッセージをｅＮＢ７０へ送信する（Ｓ１３１）。ステップＳ１３１において、ｅＮＢ７０は、NAS:Attach Requestメッセージを送信したＭＭＥ３０と異なるＭＭＥ＃ＮからNAS:Attach Acceptメッセージを受信することができる。
【0078】
次に、ｅＮＢ７０は、NAS:Attach AcceptメッセージをＵＥ１１０へ送信する（Ｓ１３２）。次に、ｅＮＢ７０は、ステップＳ１３１において、S1AP:Initial Context Setup REQUESTメッセージを受信すると、S1AP:Initial Context Setup RESPONSEメッセージの送信先となるＭＭＥを選択する処理を行う（Ｓ１３３）。ここでは、ｅＮＢ７０は、コンテキスト共有グループＡのなかからＭＭＥ＃Ｎを選択したとする。次に、ｅＮＢ７０は、S1AP:Initial Context Setup RESPONSEメッセージを、選択したＭＭＥ＃Ｎへ送信する。このように、ｅＮＢ７０は、ステップＳ１２３において送信したNAS:Attach REQUESTメッセージの送信先であるＭＭＥ３０と異なるＭＭＥ＃ＮへS1AP:Initial Context Setup RESPONSEメッセージを送信することができる。
【0079】
次に、ＭＭＥ＃Ｎは、Modify Bearer REQUESTメッセージをＳ－ＧＷ９０へ送信する（Ｓ１３５）。次に、Ｓ－ＧＷ９０は、Modify Bearer RESPONSEメッセージを送信するためのＭＭＥを選択するために、ステップＳ１２９と同様の処理を行う（Ｓ１３６）。ここでは、Ｓ－ＧＷ９０は、ＭＭＥ３０を選択したとする。次に、Ｓ－ＧＷ９０は、Modify Bearer RESPONSEメッセージを、選択したＭＭＥ３０へ送信する。
【0080】
以上説明したように、ＭＭＥは、同一のコンテキスト共有グループ内の他のＭＭＥと、ＵＥに関するＣｏｎｔｅｘｔ情報を共有することができる。そのため、ｅＮＢ、Ｓ－ＧＷ及びＨＳＳから、コンテキスト共有グループ内の任意のＭＭＥに対して呼処理メッセージが送信されてきたとしても、ＵＥに対する呼処理を継続することができる。
【0081】
また、ＭＭＥの周辺のノード装置であるｅＮＢ、Ｓ－ＧＷ及びＨＳＳは、ＵＥの呼処理を行う際に、コンテキスト共有グループ内の任意のＭＭＥに対して呼処理メッセージを送信することができる。そのため、ｅＮＢ、Ｓ－ＧＷ及びＨＳＳは、ＭＭＥにおいて実行される呼処理の負荷を分散することができる。
【0082】
（実施の形態３）
続いて、図２１を用いて、本発明の実施の形態３にかかるＭＭＥを増設した場合におけるＭＭＥからｅＮＢに対するコンテキスト共有グループ情報の通知処理の流れについて説明する。
続いて、図２１を用いて、本発明の実施の形態３にかかるＭＭＥを増設した場合におけるＭＭＥからｅＮＢに対するコンテキスト共有グループ情報の通知処理の流れについて説明する。
【0083】
はじめに、ＭＭＥを増設した後に、増設ＭＭＥが属するコンテキスト共有グループの他のＭＭＥは、S1 SETUPメッセージの起動を要求するS1 SETUP要求メッセージをｅＮＢ７０へ送信する（Ｓ１５１）。本図においては、増設ＭＭＥが、コンテキスト共有グループＡに属し、コンテキスト共有グループＡ内のＭＭＥ３０が、S1 SETUP要求メッセージをｅＮＢ７０へ送信している。
【0084】
【0085】
S1 SETUP要求メッセージを送信するＭＭＥは、例えば、増設ＭＭＥがコンテキスト共有グループに属する前に代表として選択されたＭＭＥであってもよく、管理者等から増設ＭＭＥに関する情報が入力されたＭＭＥであってもよい。また、増設ＭＭＥと、既存のＭＭＥとの間において代表選択処理が実行され、増設ＭＭＥが代表ＭＭＥとして選択された場合、増設ＭＭＥがS1 SETUP要求メッセージを送信してもよい。
【0086】
また、ＭＭＥがS1 SETUP要求メッセージを送信するかわりに、図９に示すように、ＥＭＳ装置が、ｅＮＢ７０へ増設ＭＭＥに関する情報を登録してもよい。ｅＮＢ７０は、増設ＭＭＥに関する情報が登録されると、図７及び図８に示すように、S1 SETUP REQUESTメッセージを全てのＭＭＥもしくは増設ＭＭＥのみへ送信してもよい。
【0087】
続いて、図２２を用いて、本発明の実施の形態３にかかるＭＭＥを増設した場合におけるＭＭＥからＳ－ＧＷに対するコンテキスト共有グループ情報の通知処理の流れについて説明する。はじめに、増設ＭＭＥは、自装置が属するコンテキスト共有グループ及びＷＦを設定したGTP Echo REQUESTメッセージをＳ－ＧＷ９０へ送信する（Ｓ１６１）。
【0088】
Ｓ－ＧＷ９０は、図１８に示す情報を管理しており、GTP Echo REQUESTメッセージを受信することによって、図１８に示す情報に増設ＭＭＥに関する情報を追加して管理情報を更新する（Ｓ１６２）。次に、Ｓ－ＧＷ９０は、増設ＭＭＥへ、GTP Echo RESPONSEメッセージを送信する（Ｓ１６３）。
【0089】
続いて、図２３を用いて、本発明の実施の形態３にかかるＭＭＥを増設した場合におけるＭＭＥからＳ－ＧＷに対するコンテキスト共有グループ情報の通知処理の流れについて、図２２とは異なる処理の流れについて説明する。
【0090】
はじめに、ＭＭＥが増設されると、増設ＭＭＥが属するコンテキスト共有グループ内において、代表ＭＭＥの選択処理が実行される（Ｓ１７１）。ここでは、ＭＭＥ＃Ｎが代表ＭＭＥとして選択されたとする。次に、代表ＭＭＥは、Ｓ－ＧＷ９０に対して、コンテキスト共有グループ及びコンテキスト共有グループに属する全てのＭＭＥのＷＦを設定したGTP Echo REQUESTメッセージを送信する（Ｓ１７２）。
【0091】
ステップＳ１７３及びＳ１７４は、図２２のステップＳ１６２及びＳ１６３と同様であるため詳細な説明を省略する。ただし、ステップＳ１７４においては、Ｓ－ＧＷ９０は、代表ＭＭＥへ、GTP Echo REQUESTメッセージを送信する。
【0092】
続いて、図２４を用いて、本発明の実施の形態３にかかるＭＭＥを増設した場合におけるＭＭＥからＳ－ＧＷに対するコンテキスト共有グループ情報の通知処理の流れについて、図２２及び図２３とは異なる処理の流れについて説明する。
【0093】
ステップＳ１８１は、図２３のステップＳ１７１と同様であるため詳細な説明を省略する。次に、Ｓ－ＧＷ９０は、ＭＭＥグループ内の全てのＭＭＥに対してGTP Echo REQUESTメッセージを送信する（Ｓ１８２）。次に、代表ＭＭＥは、Ｓ－ＧＷ９０に対して、コンテキスト共有グループ及びコンテキスト共有グループに属する全てのＭＭＥのＷＦを設定したGTP Echo RESPONSEメッセージを送信する（Ｓ１８３）。ここで、代表ＭＭＥ以外のＭＭＥについても、コンテキスト共有グループ等の情報を設定しないGTP Echo RESPONSEメッセージをＳ－ＧＷ９０へ送信してもよい。ステップＳ１８４は、図２３のステップＳ１７３と同様であるため詳細な説明を省略する。
【0094】
また、図２２～図２４のようにGTP Echo REQUESTメッセージ及びGTP Echo RESPONSEメッセージを用いる代わりに、図１４のようにＥＭＳ装置が、Ｓ－ＧＷ９０へ増設ＭＭＥに関する情報を登録してもよい。また、図２２～図２４のようにGTP Echo REQUESTメッセージ及びGTP Echo RESPONSEメッセージを用いる代わりに、現在３ＧＰＰにおいて定義されていない新たなメッセージを用いて、増設ＭＭＥに関する情報がＳ－ＧＷ９０へ送信されてもよい。
【0095】
続いて、本発明の実施の形態３にかかる増設ＭＭＥからＨＳＳに対するコンテキスト共有グループ情報の通知処理の流れについて説明する。ＭＭＥが増設された場合、図１５及び図１６と同様に、増設ＭＭＥとＨＳＳ８０との間においてSCTP Connectionが確立される。SCTP Connectionが確立された後は、図１５及び図１６と同様に、Update Context Shared Group REQUESTメッセージを用いて、ＨＳＳへ、増設されたＭＭＥに関するコンテキスト共有グループ等の情報を通知する。
【0096】
以上説明したように、ＭＭＥを増設した場合に、ｅＮＢ７０、Ｓ－ＧＷ９０及びＨＳＳ８０は、ＭＭＥが増設されたことを把握し、管理情報を更新することができる。ｅＮＢ７０、Ｓ－ＧＷ９０及びＨＳＳ８０は、ＷＦの値に応じて増設したＭＭＥを選択することによって、増設されたＭＭＥを利用して呼処理を行うことができる。つまり、ｅＮＢ７０、Ｓ－ＧＷ９０及びＨＳＳ８０は、増設されたＭＭＥに対して動的に呼処理メッセージを送信することができる。
【0097】
（実施の形態４）
続いて、図２５を用いて本発明の実施の形態４にかかるＭＭＥを減設した場合における、ｅＮＢ７０の情報更新処理の流れについて説明する。はじめに、減設対象となるＭＭＥは、減設処理を開始する（Ｓ１９１）。ＭＭＥの減設処理は、例えば、ＭＭＥの電源をＯＦＦ状態にすることもしくはＭＭＥをシャットダウン状態にすること等であってもよい。
続いて、図２５を用いて本発明の実施の形態４にかかるＭＭＥを減設した場合における、ｅＮＢ７０の情報更新処理の流れについて説明する。はじめに、減設対象となるＭＭＥは、減設処理を開始する（Ｓ１９１）。ＭＭＥの減設処理は、例えば、ＭＭＥの電源をＯＦＦ状態にすることもしくはＭＭＥをシャットダウン状態にすること等であってもよい。
【0098】
ＭＭＥが減設処理を行うと、減設ＭＭＥとｅＮＢ７０との間のＳ１ＡＰコネクションが切断状態となる。この時、ｅＮＢ７０は、Ｓ１ＡＰのコネクションが切断されていることを検出する（Ｓ１９２）。次に、ｅＮＢ７０は、図１８において説明した管理情報から、減設ＭＭＥに関する情報を削除するようにして、管理情報を更新する（Ｓ１９３）。この時、コンテキスト共有グループに属するＭＭＥが、減設されたＭＭＥのみであった場合、ｅＮＢ７０は、ＲＲＣコネクションについても切断してもよい。
【0099】
本図においては、ＭＭＥを減設する場合について説明したが、本図の処理は、ＭＭＥに障害が発生した場合にも適用されてもよい。
【0100】
続いて、図２６を用いて、本発明の実施の形態４にかかるＭＭＥを減設した場合における、ｅＮＢ７０の情報更新処理の流れについて、図２５と異なる情報更新処理の流れについて説明する。減設対象となるＭＭＥは、減設処理を開始する前に、MME Shutdown IndicationメッセージをｅＮＢ７０へ送信する（Ｓ２０１）。減設対象となるＭＭＥは、減設処理を開始することを知らせるために、ｅＮＢ７０へMME Shutdown Indicationメッセージを送信する。また、MME Shutdown Indicationメッセージは、異なる名称のメッセージであってもよい。
【0101】
減設対象となるＭＭＥは、MME Shutdown Indicationメッセージに、コンテキスト共有グループ、ＧＵＭＭＥＩ及びshutdown timeを設定してもよい。shutdown timeは、例えば、減設対象となるＭＭＥが減設処理を開始する時刻、もしくは、何秒後にＭＭＥが減設処理を開始するか等を示す情報である。このように、減設対象となるＭＭＥが、shutdown timeをｅＮＢ７０へ送信することによって、例えば、ＭＭＥが急に減設することによる呼損を防ぐことができる。例えば、MME Shutdown Indicationメッセージを受信したｅＮＢ７０は、減設対象となるＭＭＥとの間の呼処理を優先してもよい。
【0102】
続いて、図２７を用いて、本発明の実施の形態４にかかるＭＭＥを減設した場合における、Ｓ－ＧＷ９０の情報更新処理の流れについて説明する。Ｓ－ＧＷ９０は、ＭＭＥと正常に接続しているかを確認するために、定期的にGTP Echo REQUESTメッセージをＭＭＥへ送信する（Ｓ２１１）。しかし、ＭＭＥが減設されている場合、Ｓ－ＧＷ９０は、送信したGTP Echo REQUESTメッセージに対する応答信号を受信することはない。そのため、Ｓ－ＧＷ９０は、GTP Echo REQUESTメッセージの送信を繰り返す（Ｓ２１２）。
【0103】
次に、Ｓ－ＧＷ９０は、GTP Echo REQUESTメッセージの送信を予め定められた回数繰り返しても応答メッセージを受信しない場合、ＭＭＥが減設された、もしくは、ＭＭＥに障害が発生したと判定する。この場合、Ｓ－ＧＷ９０は、図１８の管理情報を更新し、減設されたもしくは障害が発生したと判定されたＭＭＥのエントリを削除する（Ｓ２１３）。
【0104】
続いて、図２８を用いて、本発明の実施の形態４にかかるＭＭＥを減設した場合における、Ｓ－ＧＷ９０の情報更新処理の流れについて、図２７と異なる処理の流れについて説明する。減設対象のＭＭＥは、減設を開始する前に、減設することを設定したGTP Echo REQUESTメッセージをＳ－ＧＷ９０へ送信する（Ｓ２２１）。減設対象のＭＭＥは、GTP Echo REQUESTメッセージに、例えば、減設対象のＭＭＥが属するコンテキスト共有グループ及び減設することを示す減設フラグ等を新規のＩＥ（Information Element）として設定してもよい。
【0105】
次に、Ｓ－ＧＷ９０は、ステップＳ２２１においてGTP Echo REQUESTメッセージを受信すると、図１８の管理情報を更新し、減設されるＭＭＥのエントリを削除する（Ｓ２２２）。次に、Ｓ－ＧＷ９０は、減設対象のＭＭＥへ、GTP Echo RESPONSEメッセージを送信する（Ｓ２２３）。
【0106】
続いて、図２９を用いて、本発明の実施の形態４にかかるＭＭＥを減設した場合における、Ｓ－ＧＷ９０の情報更新処理の流れについて、図２７及び図２８と異なる処理の流れについて説明する。図２８においては、減設対象のＭＭＥは、Ｓ－ＧＷ９０へ、GTP Echo REQUESTメッセージを送信することによって減設することを伝えていたが、図２９においては、MME Shutdown IndicationメッセージをＳ－ＧＷ９０へ送信することによって減設することを伝える。減設対象のＭＭＥは、MME Shutdown Indicationメッセージに、コンテキスト共有グループ及びshutdown timeを設定してもよい。shutdown timeは、例えば、減設対象となるＭＭＥが減設処理を開始する時刻、もしくは、何秒後にＭＭＥが減設処理を開始するか等を示す情報である。
【0107】
次に、Ｓ－ＧＷ９０は、ステップＳ２２１においてMME Shutdown Indicationメッセージを受信すると、図１８の管理情報を更新し、減設されるＭＭＥのエントリを削除する（Ｓ２３２）。ここで、Ｓ－ＧＷ９０は、MME Shutdown Indicationメッセージに対する応答メッセージを送信することなく処理を終了する。
【0108】
また、図２７～図２９のようにGTP Echo REQUESTメッセージ及びMME Shutdown Indicationメッセージを用いる代わりに、図１４のようにＥＭＳ装置が、Ｓ－ＧＷ９０へ減設ＭＭＥに関する情報を登録してもよい。また、図２７～図２９のようにGTP Echo REQUESTメッセージ及びMME Shutdown Indicationメッセージを用いる代わりに、現在３ＧＰＰにおいて定義されていない新たなメッセージを用いて、減設ＭＭＥに関する情報がＳ－ＧＷ９０へ送信されてもよい。
【0109】
続いて、図３０を用いて、本発明の実施の形態４にかかるＭＭＥを減設した場合における、ＨＳＳ８０の情報更新処理の流れについて説明する。はじめに、減設対象となるＭＭＥは、減設処理を開始する（Ｓ２４１）。ＭＭＥの減設処理は、例えば、ＭＭＥの電源をＯＦＦ状態にすることもしくはＭＭＥをシャットダウン状態にすること等であってもよい。
【0110】
ＭＭＥが減設処理を行うと、減設ＭＭＥとＨＳＳ８０との間のＳＣＴＰコネクションが切断状態となる。この時、ＨＳＳ８０は、ＳＣＴＰのコネクションが切断されていることを検出する（Ｓ２４２）。次に、ＨＳＳ８０は、図１８において説明した管理情報から、減設ＭＭＥに関する情報を削除して、管理情報を更新する（Ｓ２４３）。
【0111】
続いて、図３１を用いて、本発明の実施の形態４にかかるＭＭＥを減設した場合における、ＨＳＳ８０の情報更新処理の流れについて、図３０と異なる情報更新処理の流れについて説明する。減設対象となるＭＭＥは、減設処理を開始する前に、MME Shutdown IndicationメッセージをＨＳＳ８０へ送信する（Ｓ２５２）。減設対象となるＭＭＥは、減設処理を開始することを知らせるために、ＨＳＳ８０へMME Shutdown Indicationメッセージを送信する。また、MME Shutdown Indicationメッセージは、異なる名称のメッセージであってもよい。
【0112】
減設対象となるＭＭＥは、MME Shutdown Indicationメッセージに、コンテキスト共有グループ、Ｏｒｉｇｉｎ－Ｈｏｓｔ及びshutdown timeを設定してもよい。shutdown timeは、例えば、減設対象となるＭＭＥが減設処理を開始する時刻、もしくは、何秒後にＭＭＥが減設処理を開始するか等を示す情報である。このように、減設対象となるＭＭＥが、shutdown timeをｅＮＢ７０へ送信することによって、例えば、ＭＭＥが急に減設することによる呼損を防ぐことができる。例えば、MME Shutdown Indicationメッセージを受信したＨＳＳ８０は、減設対象となるＭＭＥとの間の呼処理を優先してもよい。
【0113】
次に、減設対象のＭＭＥは、shutdown timeに示されたタイミングに減設処理を開始する（Ｓ２５２）。また、ＨＳＳ８０は、減設対象のＭＭＥを図１８に示す管理情報のエントリから削除するようにして管理情報を更新する。
【0114】
以上説明したように、ＭＭＥを減設した場合に、ｅＮＢ７０、Ｓ－ＧＷ９０及びＨＳＳ８０は、ＭＭＥが減設されたことを把握し、管理情報を更新することができる。ｅＮＢ７０、Ｓ－ＧＷ９０及びＨＳＳ８０は、管理情報を更新した後は、減設されたＭＭＥに対して呼処理メッセージを送信することはなくなる。
【0115】
通常、ＭＭＥを減設する際、減設対象のＭＭＥは、ＭＭＥが保持しているそれぞれのＵＥのＣｏｎｔｅｘｔ情報を他のＭＭＥへ移管する必要がある。このような場合、一般的には、ＭＭＥは、ＵＥをＤｅｔａｃｈさせ、ＵＥに再度Ａｔｔａｃｈ処理を実行させ、新たなＭＭＥにおいてＵＥのＣｏｎｔｅｘｔ情報を生成させる。ここで、通信中のＵＥをＤｅｔａｃｈさせた場合、通信中のＵＥの通信が一時的に中断されてしまうという問題があった。
【0116】
これに対して、実施の形態４における通信システムは、それぞれのＭＭＥは、外部のサーバ装置等に保存されているＣｏｎｔｅｘｔ情報を共有することができる。そのため、ＭＭＥを減設する場合においても、ＵＥをＤｅｔａｃｈさせる必要がない。これより、実施の形態４における通信システムを用いることによって、ＵＥの通信を中断させることなく、ＭＭＥを減設することができる。
【0117】
また、Ｃｏｎｔｅｘｔ情報がサーバ装置等において格納されている場合、ＭＭＥが減設された場合においても、Ｃｏｎｔｅｘｔ情報が消滅することはない。そのため、残存するＭＭＥは、減設されたＭＭＥの代わりにサーバ装置等において格納されているＣｏｎｔｅｘｔ情報を用いて呼処理を継続することができる。
【0118】
（実施の形態５）
続いて、図３２を用いて本発明の実施の形態５にかかるＭＭＥがスケールアップもしくはスケールダウンした場合におけるＨＳＳ８０の情報更新処理の流れについて説明する。ＭＭＥのスケールアップとは、ＭＭＥの性能を向上させることであり、ＭＭＥのスケールダウンとは、ＭＭＥの性能を低下させることである。ＭＭＥをスケールアップさせた場合、スケールアップさせたＭＭＥにおける呼処理量を増加させることができる。このような場合、スケールアップしたＭＭＥは、ＷＦの値を高くして、周辺のノード装置において自装置が選択される機会を増加させる。ＭＭＥをスケールダウンさせた場合、スケールダウンしたＭＭＥは、ＷＦの値を低くして、周辺のノード装置において自装置が選択される機会を減少させる。図３２においては、スケールアップもしくはスケールダウンによって変更したＷＦをｅＮＢ７０へ通知する際の処理の流れについて説明する。
続いて、図３２を用いて本発明の実施の形態５にかかるＭＭＥがスケールアップもしくはスケールダウンした場合におけるＨＳＳ８０の情報更新処理の流れについて説明する。ＭＭＥのスケールアップとは、ＭＭＥの性能を向上させることであり、ＭＭＥのスケールダウンとは、ＭＭＥの性能を低下させることである。ＭＭＥをスケールアップさせた場合、スケールアップさせたＭＭＥにおける呼処理量を増加させることができる。このような場合、スケールアップしたＭＭＥは、ＷＦの値を高くして、周辺のノード装置において自装置が選択される機会を増加させる。ＭＭＥをスケールダウンさせた場合、スケールダウンしたＭＭＥは、ＷＦの値を低くして、周辺のノード装置において自装置が選択される機会を減少させる。図３２においては、スケールアップもしくはスケールダウンによって変更したＷＦをｅＮＢ７０へ通知する際の処理の流れについて説明する。
【0119】
はじめに、コンテキスト共有グループＡに属するＭＭＥ＃Ｎがスケールアップもしくはスケールダウンしたとする（Ｓ２６１）。次に、ＭＭＥ＃Ｎは、ｅＮＢ７０へ、MME Configuration Updateメッセージを送信する（Ｓ２６２）。ＭＭＥ＃Ｎは、MME Configuration Updateメッセージに、コンテキスト共有グループ、ＧＵＭＭＥＩ及び更新したＷＦの値を設定する。
【0120】
次に、ｅＮＢ７０は、図１８に示す管理情報のうち、ＭＭＥ＃ＮのＷＦの値を更新する（Ｓ２６３）。次に、ｅＮＢ７０は、MME Configuration Update AcknowledgeメッセージをＭＭＥ＃Ｎへ送信する。
【0121】
また、本図においては、ＷＦを変更したＭＭＥ＃ＮがMME Configuration UpdateメッセージをｅＮＢ７０へ送信する例について説明したが、コンテキスト共有グループＡ内の代表ＭＭＥが、MME Configuration UpdateメッセージをｅＮＢ７０へ送信してもよい。この場合、代表ＭＭＥは、コンテキスト共有グループと、コンテキスト共有グループ内全てのＭＭＥのＧＵＭＭＥＩ及びＷＦをMME Configuration Updateメッセージに設定してもよい。もしくは、代表ＭＭＥは、コンテキスト共有グループと、ＷＦを更新したＭＭＥのＧＵＭＭＥＩ及び更新後のＷＦをMME Configuration Updateメッセージに設定してもよい。
【0122】
また、図９に示すように、ＥＭＳ装置が、ｅＮＢ７０へＭＭＥ＃Ｎの更新後のＷＦに関する情報を登録してもよい。
【0123】
続いて、ＭＭＥがスケールアップもしくはスケールダウンした場合におけるＳ－ＧＷ９０の情報更新処理の流れについて説明する。ＭＭＥがスケールアップもしくはスケールダウンした場合、図１０～図１３における処理と同様に、GTP Echo REQUESTメッセージもしくはGTP Echo RESPONSEメッセージに更新後のＷＦを設定する。もしくは、図１４における処理と同様に、ＥＭＳ装置が、Ｓ－ＧＷ９０へスケールアップもしくはスケールダウンしたＭＭＥの更新後のＷＦに関する情報を登録してもよい。
【0124】
続いて、ＭＭＥがスケールアップもしくはスケールダウンした場合におけるＨＳＳ８０の情報更新処理の流れについて説明する。ＭＭＥがスケールアップもしくはスケールダウンした場合、図１５及び図１６における処理と同様に、ＭＭＥは、Update Context Shared Group REQUESTメッセージに更新後のＷＦを設定する。もしくは、図１７における処理と同様に、ＥＭＳ装置が、ＨＳＳ８０へスケールアップもしくはスケールダウンしたＭＭＥの更新後のＷＦに関する情報を登録してもよい。
【0125】
以上説明したように、本発明の実施の形態５にかかる通信システムを用いることによって、ＭＭＥの性能の変化に応じて、動的にＭＭＥの負荷分散制御を行うことができる。
【0126】
また、ＷＦの変更は、ＭＭＥに輻輳が発生した場合に行われてもよい。例えば、ＭＭＥに輻輳が発生した場合、輻輳が発生したＭＭＥのＷＦを低い値に変更してもよい。このようにすることによって、周辺のノード装置は、ＭＭＥを選択する機会が減少することになり、輻輳を回避することができる。
【0127】
（実施の形態６）
続いて、図３３及び図３４を用いて、コンテキスト共有グループ内のＭＭＥが、Ｃｏｎｔｅｘｔ情報を共有するために、Ｃｏｎｔｅｘｔ情報を格納する装置としてＨＳＳ８０を用いる場合の構成について説明する。
続いて、図３３及び図３４を用いて、コンテキスト共有グループ内のＭＭＥが、Ｃｏｎｔｅｘｔ情報を共有するために、Ｃｏｎｔｅｘｔ情報を格納する装置としてＨＳＳ８０を用いる場合の構成について説明する。
【0128】
図３３は、ＭＭＥ３０が、ＨＳＳ８０とＳ６ａインタフェースを介して接続していることを示している。本図においては、ＨＳＳ８０には、ＭＭＥ３０が接続していることを示しているが、ＨＳＳ８０には、複数のＭＭＥがＳ６ａインタフェースを介して接続している。
【0129】
図３４は、ＭＭＥ３０が、ＨＳＳ－ＦＥ（Front End）８５とＳ６ａインタフェースを介して接続し、ＵＤＲ（User Data Repository）８６とＵｄインタフェースを介して接続していることを示している。また、ＨＳＳ－ＦＥ８５は、ＵＤＲ８６とＵｄインタフェースを介して接続している。
【0130】
ＵＤＲ８６は、ＵＥの加入者データを保持する。また、ＨＳＳ－ＦＥ８５は、ＭＭＥ３０とＵＤＲ８６との間に配置され、ＭＭＥ３０とＵＤＲ８６との間の通信を中継する。このように、ＨＳＳ８０の構成は、データの格納部であるＵＤＲ８６と、ＭＭＥ３０と通信する際のインタフェースとして動作するＨＳＳ－ＦＥ８５とに分離されてもよい。
【0131】
【0132】
はじめに、ｅＮＢ７０は、図１９のステップＳ１２２等と同様に、NAS:Attach REQUESTメッセージの送信先となるＭＭＥを選択する（Ｓ２７１）。ここでは、ｅＮＢ７０は、ＭＭＥ３０を選択したとする。次に、ｅＮＢ７０は、選択したＭＭＥ３０へ、NAS:Attach REQUESTメッセージを送信する（Ｓ２７２）。
【0133】
次に、ＭＭＥ３０は、NAS:Attach REQUESTメッセージを送信したＵＥに関するＣｏｎｔｅｘｔ情報を生成する（Ｓ２７３）。例えば、ＭＭＥ３０は、ＨＳＳ８０にNAS:Attach REQUESTメッセージを送信したＵＥに関するＣｏｎｔｅｘｔ情報が格納されていない場合等にＣｏｎｔｅｘｔ情報を生成する。
【0134】
次に、ＭＭＥ３０は、生成したＣｏｎｔｅｘｔ情報をＨＳＳ８０もしくはＵＤＲ８６（以下、ＨＳＳ８０等とする）へ格納するために、Context Put REQUESTメッセージを送信する（Ｓ２７５）。次に、ＨＳＳ８０等は、Context Put REQUESTメッセージに設定されているＣｏｎｔｅｘｔ情報を自装置のメモリ等へ格納する（Ｓ２７５）。次に、ＨＳＳ８０等は、Context Put ANSWERメッセージをＭＭＥ３０へ送信する。ここで、ＨＳＳ８０等は、コンテキスト共有グループ内の任意のＭＭＥを選択する処理を実行せず、Context Put REQUESTメッセージを送信してきたＭＭＥへ、Context Put ANSWERメッセージを送信する。
【0135】
次に、ＭＭＥ３０は、ＵＥを認証するために必要な認証ベクトル（ＡＶ）を取得するために、ＨＳＳ８０等へ、Authentication Information REQUESTメッセージを送信する（Ｓ２７７）。次に、ＨＳＳ８０等は、指定されたＵＥの認証ベクトルを設定したAuthentication Information AnswerメッセージをＭＭＥ３０へ送信する（Ｓ２７８）。
【0136】
次に、ＭＭＥ３０は、ＨＳＳ８０等から送信された認証ベクトルをＨＳＳ８０等へ送信するためにContext Put REQUESTメッセージをＨＳＳ８０等へ送信する。ＨＳＳ８０等は、ステップＳ２７５において格納したＣｏｎｔｅｘｔ情報にＵＥの認証ベクトルを反映してＣｏｎｔｅｘｔ情報を更新する（Ｓ２８０）。次に、ＨＳＳ８０は、Context Put ANSWERメッセージをＭＭＥ３０へ送信する（Ｓ２８１）。
【0137】
次に、ＭＭＥ３０は、ＵＥの認証を実施するためにｅＮＢ７０を介してＵＥへAuthentication REQUESTメッセージを送信する（Ｓ２８２）。次に、ｅＮＢ７０は、Authentication RESPONSEメッセージを送信するために、ステップＳ２７１と同様に送信先のＭＭＥを選択する（Ｓ２８３）。ここでは、ｅＮＢ７０は、コンテキスト共有グループＡに属するＭＭＥ＃Ｎを選択したとする。
【0138】
次に、ｅＮＢ７０は、選択したＭＭＥ＃ＮへAuthentication RESPONSEメッセージを送信する（Ｓ２８４）。
【0139】
図３６へすすみ、次に、ＭＭＥ＃Ｎは、ＵＥに関するＣｏｎｔｅｘｔ情報を取得するために、ＨＳＳ８０等へContext Get REQUESTメッセージを送信する（Ｓ２８５）。次に、ＨＳＳ８０等は、指定されたＵＥのＣｏｎｔｅｘｔ情報を設定したContext Get ANSWERメッセージをＭＭＥ＃Ｎへ送信する（Ｓ２８６）。
【0140】
次に、ＭＭＥ＃Ｎは、ＵＥに関する認証処理を実行する（Ｓ２８７）。次に、ＭＭＥ＃Ｎは、認証処理を反映したＣｏｎｔｅｘｔ情報をＨＳＳ８０等へ格納するために、ＨＳＳ８０へＣｏｎｔｅｘｔ情報を設定したContext Put REQUESTメッセージを送信する（Ｓ２８８）。次に、ＨＳＳ８０等は、Context Put REQUESTメッセージに設定されたＣｏｎｔｅｘｔ情報を用いて、現在のＣｏｎｔｅｘｔ情報を更新する（Ｓ２８９）。次に、ＨＳＳ８０等は、ＭＭＥ＃Ｎへ、Context Put ANSWERメッセージを送信する（Ｓ２９０）。
【0141】
ここで、図３５のステップＳ２７７～Ｓ２８１は、ＵＥを認証する際に必要となる認証ベクトルをＨＳＳから取得し、さらに、認証ベクトルをＨＳＳ８０に格納されているＣｏｎｔｅｘｔに保存する動作となる。そのため、ＨＳＳ８０等が、格納されているＣｏｎｔｅｘ情報に認証ベクトルを保存する動作を実行する場合、ステップＳ２７７～Ｓ２８１を省略することができる。
【0142】
以上説明したように、本発明の実施の形態６にかかる通信システムを用いることによって、ＨＳＳは、ＭＭＥにおいて生成されたＣｏｎｔｅｘｔ情報を保存することができる。これによって、コンテキスト共有グループに属する複数のＭＭＥは、Ｃｏｎｔｅｘｔ情報をＨＳＳから取得することによって、他のＭＭＥにおいて生成されたＣｏｎｔｅｘｔ情報を利用することができる。
【0143】
（実施の形態７）
続いて、図３７を用いて本発明の実施の形態７にかかる通信システムの構成例について説明する。図３７の通信システムは、図２の通信システムと、コンテキスト共有グループに属するＭＭＥが異なる。本図においては、主に図２の通信システムと異なる点について説明する。
続いて、図３７を用いて本発明の実施の形態７にかかる通信システムの構成例について説明する。図３７の通信システムは、図２の通信システムと、コンテキスト共有グループに属するＭＭＥが異なる。本図においては、主に図２の通信システムと異なる点について説明する。
【0144】
本図の通信システムは、ＭＭＥ３０及びＭＭＥ４０がコンテキスト共有グループＣに属している。また、ＭＭＥ４０、ＭＭＥ５０及びＭＭＥ６０がコンテキスト共有グループＤに属している。つまり、ＭＭＥ４０は、コンテキスト共有グループＣ及びコンテキスト共有グループＤに属している。このように、ＭＭＥは、複数のコンテキスト共有グループに属してもよい。
【0145】
図３７のようなコンテキスト共有グループの構成において、図１９の呼処理を実行すると、ｅＮＢ７０は、NAS:Attach REQUESTメッセージに設定されているＧＵＴＩから特定したＧＵＭＭＥＩがＭＭＥ４０を示す場合、ＭＭＥ４０が、どのコンテキスト共有グループに属するか特定することができない。
【0146】
そのため、このような場合、ＧＵＭＭＥＩに、コンテキスト共有グループを特定することができる情報を設定しておいてもよい。例えば、ＧＵＭＭＥＩのＭＭＥＣ領域を、ＭＭＥＣ＋コンテキスト共有グループＩＤに細分化してもよい。もしくは、ｅＮＢ７０が、ＭＭＥ４０へNAS:Attach REQUESTメッセージを送信した後に、ＭＭＥから送信されるメッセージにおいてコンテキスト共有グループが指定されてもよい。
【0147】
以上説明したように、本発明の実施の形態７に係る通信システムのように、ＭＭＥが複数のコンテキスト共有グループに属することができるようにすることによって、複数のコンテキスト共有グループに属するＭＭＥを、それぞれのコンテキスト共有グループにおける代替装置として使用することもできる。
【0148】
なお、本発明は上記実施の形態に限られたものではなく、趣旨を逸脱しない範囲で適宜変更することが可能である。
【0149】
以上、実施の形態を参照して本願発明を説明したが、本願発明は上記によって限定されるものではない。本願発明の構成や詳細には、発明のスコープ内で当業者が理解し得る様々な変更をすることができる。
【0150】
この出願は、２０１５年３月１２日に出願された日本出願特願２０１５－０４９５７３を基礎とする優先権を主張し、その開示の全てをここに取り込む。
【符号の説明】
【0151】
１０ 通信制御装置
１１ 通信制御装置
１２ 通信制御装置
２０ ノード装置
３０ ＭＭＥ
３１ Ｄｉａｍｅｔｅｒ通信部
３２ Ｓ１ＡＰ通信部
３３ ＧＴＰ－Ｃ通信部
３４ Ｃｏｎｔｅｘｔ共有部
３５ Ｃｏｎｔｅｘｔ記憶部
３６ ＭＭＥ呼処理部
４０ ＭＭＥ
５０ ＭＭＥ
６０ ＭＭＥ
７０ ｅＮＢ
７１ Ｓ１ＡＰ通信部
７２ Ｓ１ＡＰ呼処理部
７３ ＲＲＣ処理部
７４ 無線処理部
７５ ＧＴＰ－Ｕ通信部
７６ ＧＴＰ－Ｕ処理部
７７ Ｃｏｎｔｅｘｔ記憶部
８０ ＨＳＳ
８１ Ｄｉａｍｅｔｅｒ通信部
８２ 加入者情報処理部
８３ 加入者情報記憶部
８５ ＨＳＳ－ＦＥ
８６ ＵＤＲ
９０ Ｓ－ＧＷ
９１ ＧＴＰ－Ｃ通信部
９２ ＧＴＰ－Ｕ通信部
９３ ＧＴＰ－Ｃ処理部
９４ Ｃｏｎｔｅｘｔ記憶部
９５ ＧＴＰ－Ｕ処理部
１００ Ｐ－ＧＷ
１１０ ＵＥ
１１ 通信制御装置
１２ 通信制御装置
２０ ノード装置
３０ ＭＭＥ
３１ Ｄｉａｍｅｔｅｒ通信部
３２ Ｓ１ＡＰ通信部
３３ ＧＴＰ－Ｃ通信部
３４ Ｃｏｎｔｅｘｔ共有部
３５ Ｃｏｎｔｅｘｔ記憶部
３６ ＭＭＥ呼処理部
４０ ＭＭＥ
５０ ＭＭＥ
６０ ＭＭＥ
７０ ｅＮＢ
７１ Ｓ１ＡＰ通信部
７２ Ｓ１ＡＰ呼処理部
７３ ＲＲＣ処理部
７４ 無線処理部
７５ ＧＴＰ－Ｕ通信部
７６ ＧＴＰ－Ｕ処理部
７７ Ｃｏｎｔｅｘｔ記憶部
８０ ＨＳＳ
８１ Ｄｉａｍｅｔｅｒ通信部
８２ 加入者情報処理部
８３ 加入者情報記憶部
８５ ＨＳＳ－ＦＥ
８６ ＵＤＲ
９０ Ｓ－ＧＷ
９１ ＧＴＰ－Ｃ通信部
９２ ＧＴＰ－Ｕ通信部
９３ ＧＴＰ－Ｃ処理部
９４ Ｃｏｎｔｅｘｔ記憶部
９５ ＧＴＰ－Ｕ処理部
１００ Ｐ－ＧＷ
１１０ ＵＥ
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【図14】
【図15】
【図16】
【図17】
【図18】
【図19】
【図20】
【図21】
【図22】
【図23】
【図24】
【図25】
【図26】
【図27】
【図28】
【図29】
【図30】
【図31】
【図32】
【図33】
【図34】
【図35】
【図36】
【図37】