JP6645660B2 - 中継ノード装置、通信制御方法、及び、プログラム - Google Patents

Description

本発明は中継ノード装置、通信制御方法、及び、プログラムに関し、特にメッセージを伝送する中継ノード装置、通信制御方法、及び、プログラムに関する。

近年、スマートフォン等が普及するとともに、ＩｏＴ（Internet Of Things）サービスも広まってきている。ＩｏＴサービスは、例えば、ユーザの操作を伴わずに自律的に通信を行う端末等を用いて実施される。一般的に、スマートフォン等の端末と、ＩｏＴサービスに用いられる端末とでは、トラヒック特性が異なることが知られている。例えば、ＩｏＴサービスは、スマートフォン等と比較して少量のデータが伝送される場合が多い。さらに、ＩｏＴサービスは、１日のうち、予め定められたタイミングにデータが伝送されるというトラヒック特性を有することもある。

このように、スマートフォン等の端末を用いた一般サービスと、ＩｏＴサービスとは、トラヒック特性が異なるため、一般サービスを提供するコアネットワークと、ＩｏＴサービスを提供するコアネットワークとを分離し、それぞれ独立に運用することが検討されている。コアネットワークを分離することによって、それぞれのサービスのトラヒック特性に応じた設備設計等を行うことが可能となる。

特許文献１には、トラヒック特性の異なるユーザ端末を区別し、ユーザ端末を接続することに適したトラヒック特性を持つゲートウェイ装置の構成が開示されている。具体的に、ゲートウェイ装置が有するパケット振り分け制御部が、パケット内に含まれるユーザ端末のＭＡＣアドレスもしくはドメイン情報等に基づいて、パケットの転送先を決定する。さらにパケット振り分け制御部は、パケットの送信先のＩＰアドレスを、転送先のゲートウェイ装置のＩＰアドレスに変更する。

特開２０１５−４３５２２号公報

今後、ＩｏＴサービスは急速に普及し、ＩｏＴサービスに用いられる端末も急速に増加することが予測されている。この場合、ＩｏＴサービスを提供するコアネットワークの設備を増強した場合であっても、ＩｏＴサービスに用いられる端末が急速に増加することによって、ＩｏＴサービスを提供するコアネットワークに、ＩｏＴサービスに用いられる全ての端末を登録することができなくなるという問題がある。

本発明の目的は、コアネットワークにおいて保持するデータ量を削減し、多くの端末を登録することができる中継ノード装置、通信制御方法、及び、プログラムを提供することにある。

本発明の第１の態様にかかる中継ノード装置は、コアネットワークに配置され、移動局に関するユーザデータを伝送する中継ノード装置であって、加入者情報管理装置から送信された移動局の加入者データを保持する加入者データ保持部と、前記移動局に関するユーザデータの伝送が行われていない場合に、ＩｏＴサービスポリシーに従い前記加入者データ保持部において前記移動局の加入者データを保持するか否かを判定する制御部と、を備えるものである。

本発明の第２の態様にかかる通信制御方法は、コアネットワークに配置され、移動局に関するユーザデータを伝送する中継ノード装置における通信制御方法であって、加入者情報管理装置から送信された移動局の加入者データを保持する加入者データ保持し、前記移動局に関するユーザデータの伝送が行われていない場合に、ＩｏＴサービスポリシーに従い前記移動局の加入者データを保持するか否かを判定するものである。

本発明の第３の態様にかかるプログラムは、コアネットワークに配置され、移動局に関するユーザデータを伝送する中継ノード装置であるコンピュータに実行させるプログラムであって、加入者情報管理装置から送信された移動局の加入者データを保持する加入者データ保持し、前記移動局に関するユーザデータの伝送が行われていない場合に、ＩｏＴサービスポリシーに従い前記移動局の加入者データを保持するか否かを判定することをコンピュータに実行させるものである。

本発明により、コアネットワークにおいて保持するデータ量を削減し、多くの端末を登録することができる中継ノード装置、通信制御方法、及び、プログラムを提供することができる。

実施の形態１にかかる通信システムの構成図である。 実施の形態２にかかる通信システムの構成図である。 実施の形態２にかかるＡｔｔａｃｈ処理の流れを示す図である。 実施の形態２にかかる無通信検出時の処理の流れを示す図である。 実施の形態３にかかる通信システムの構成図である。 実施の形態３にかかるＡｔｔａｃｈ処理の流れを示す図である。 実施の形態３にかかる無通信検出時の処理の流れを示す図である。 実施の形態４にかかる通信システムの構成図である。 実施の形態４にかかるＤＢが管理する情報を示す図である。 実施の形態４にかかるパケット振り分け処理の流れを示す図である。 実施の形態５にかかるパケット振り分け処理の流れを示す図である。 実施の形態６にかかるＳＧＳＮの構成図である。 実施の形態６にかかるＡｔｔａｃｈ処理の流れを示す図である。 実施の形態６にかかるＵＥがパケット通信を開始する際の流れを示す図である。 実施の形態６にかかるＵＥがパケット通信を完了した際の処理流れを示す図である。 実施の形態６にかかる無通信検出時の処理の流れを示す図である。

（実施の形態１）
以下、図面を参照して本発明の実施の形態について説明する。図１を用いて本発明の実施の形態１にかかる通信システムについて説明する。図１の通信システムは、ｅＮＢ（evolved Node B）１０、ゲートウェイ装置２０、ＭＭＥ（Mobility Management Entity）３０、ＭＭＥ３２、及び、ＵＥ（User Equipment）４０を有している。ＵＥ４０、ｅＮＢ１０、ゲートウェイ装置２０、及び、ＭＭＥ３０は、プロセッサがメモリに格納されたプログラムを実行することによって動作するコンピュータ装置であってもよい。

ｅＮＢ１０は、３ＧＰＰにおいてＬＴＥ（Long Term Evolution）をサポートする基地局である。ｅＮＢ１０は、無線通信方式としてＬＴＥを用いて、ＵＥ４０と無線通信を行う。ＵＥ４０は、３ＧＰＰにおいて用いられている移動局の総称である。

ＭＭＥ３０及びＭＭＥ３２は、３ＧＰＰにおいてＵＥ４０の位置情報を管理し、さらに、ＵＥ４０に関する呼処理制御を実施するノード装置である。ＭＭＥ３０及びＭＭＥ３２は、コアネットワークを構成するノード装置である。また、図１においては、ＭＭＥ３０及びＭＭＥ３２の２台が示されているが、３台以上のＭＭＥが配置されてもよい。

ゲートウェイ装置２０は、ｅＮＢ１０とＭＭＥ３０との間に配置され、ｅＮＢ１０とＭＭＥ３０との間において伝送される制御データを中継する。制御データは、ＵＥ４０の位置情報を収集するためのデータ、さらに、呼処理制御を実行するためのデータ等であってもよい。制御データは、制御信号、制御情報、もしくは、Ｃ−Ｐｌａｎｅデータ等と称されてもよい。また、ＵＥ４０が送受信するテキストデータ、画像データ、もしくは動画データ等をユーザデータと称する。ユーザデータは、ユーザ情報、もしくは、Ｕ−Ｐｌａｎｅデータ等と称されてもよい。

ｅＮＢ１０とＭＭＥ３０とは、Ｓ１ＡＰ（S1 Application Protocol）に従って通信を実行する。つまり、ｅＮＢ１０及びＭＭＥ３０は、Ｓ１ＡＰにおいて規定された制御メッセージであるＳ１ＡＰメッセージに各種情報を設定し、Ｓ１ＡＰメッセージを伝送する。ｅＮＢ１０とＭＭＥ３０との間は、３ＧＰＰにおいてＳ１リファレンスポイントとして定義されている。ｅＮＢ１０及びＭＭＥ３２も、Ｓ１ＡＰに従って通信を実行する。

続いて、ゲートウェイ装置２０の構成例について説明する。ゲートウェイ装置２０は、通信部２１、判定部２２、及び、変換部２３を有している。通信部２１、判定部２２、及び、変換部２３は、プロセッサがメモリに格納されたプログラムを実行することによって処理が実行されるソフトウェアもしくはモジュールであってもよい。または、通信部２１、判定部２２、及び、変換部２３は、回路もしくはチップ等のハードウェアであってもよい。

通信部２１は、ｅＮＢ１０、ＭＭＥ３０、もしくはＭＭＥ３２から送信されたＳ１ＡＰメッセージを終端する。通信部２１がＳ１ＡＰメッセージを終端するとは、通信部２１がＳ１ＡＰメッセージに設定された情報を解析し、もしくは、Ｓ１ＡＰメッセージに設定された情報を変更等することであってもよい。通信部２１は、受信したＳ１ＡＰメッセージを判定部２２及び変換部２３へ出力する。

判定部２２は、Ｓ１ＡＰメッセージに関連付けられたＵＥ４０の端末種別を判定する。Ｓ１ＡＰメッセージは、ＵＥ４０の位置情報を管理するため、さらに、ＵＥ４０の呼処理制御を行うために用いられるメッセージである。つまり、Ｓ１ＡＰメッセージは、ＵＥ毎に伝送される。

端末種別は、例えば、ＵＥ４０が実行するサービスの識別情報、ＵＥ４０のトラヒック特性を定義した情報、もしくは、その他のＵＥ４０を識別するための識別情報等であってもよい。例えば、端末種別は、ＩｏＴサービスを実行する端末と、それ以外の端末とを識別する情報であってもよい。

変換部２３は、ｅＮＢ１０から送信されたＳ１ＡＰメッセージに設定されている送信元アドレスをｅＮＢ１０の識別子からゲートウェイ装置２０の識別子Ａへ変更する。識別子Ａは、ゲートウェイ装置２０とＭＭＥ３０との間、もしくは、ゲートウェイ装置２０とＭＭＥ３２との間の通信に用いられる識別子である。

ここで、通信部２１は、送信元アドレスが変換されたＳ１ＡＰメッセージを、端末種別に応じて決定されるＭＭＥ３０もしくはＭＭＥ３２へ送信する。例えば、ＭＭＥ３０及びＭＭＥ３２は、特定の端末種別のＵＥ４０の位置情報を管理し、さらに、呼処理制御を実行する。この場合、通信部２１は、判定した端末種別に関連付けられているＭＭＥへ、Ｓ１ＡＰメッセージを送信する。言い換えると、通信部２１は、端末種別に応じて、Ｓ１ＡＰメッセージを複数のＭＭＥへ振り分ける。

以上説明したように、図１のゲートウェイ装置２０は、３ＧＰＰにおいてｅＮＢ１０とＭＭＥ３０との間の通信に用いられるＳ１ＡＰメッセージを終端することができる。さらに、ゲートウェイ装置２０は、ＵＥ４０の端末種別に応じて、Ｓ１ＡＰメッセージを複数のＭＭＥへ振り分けることができる。

さらに、ゲートウェイ装置２０は、ｅＮＢ１０から送信されたＳ１ＡＰメッセージの送信元アドレスを、ｅＮＢ１０からゲートウェイ装置２０に変更することができる。これより、ゲートウェイ装置２０が、Ｓ１ＡＰメッセージにおいて定められている送信元の識別情報を変更し、送信元の識別情報を変更したＳ１ＡＰメッセージをＭＭＥへ送信することによって、ゲートウェイ装置２０がｅＮＢ１０とＭＭＥ３０またＭＭＥ３２との間に配置され、Ｓ１ＡＰメッセージを終端した場合であっても、正常にＳ１ＡＰメッセージを伝送することができる。つまり、ＭＭＥは、Ｓ１ＡＰメッセージの送信先として、ゲートウェイ装置２０の識別情報を設定することによって、ｅＮＢ１０とＭＭＥとの間において伝送されるＳ１ＡＰメッセージが、ゲートウェイ装置２０を介して伝送されることを可能とする。

（実施の形態２）
続いて、図２を用いて本発明の実施の形態２にかかる通信システムの構成例について説明する。図２は、ＭＭＥ３０が、一般ネットワーク５０内に配置され、ＭＭＥ３２が、ＩｏＴネットワーク５２内に配置されていることを示している。図２のその他の構成は、図１と同様であるため詳細な説明を省略する。

ＩｏＴネットワーク５２は、ＩｏＴサービスに用いられるＵＥに関するデータを伝送するネットワークである。例えば、ＩｏＴネットワーク５２は、ＩｏＴサービスに用いられるＵＥに関する制御データ及びユーザデータを伝送するネットワークであってもよい。ＩｏＴネットワーク５２は、制御データを伝送するＭＭＥ３２の他に、ユーザデータを伝送するＳＧＷ（Serving Gateway）及びＰＧＷ（Packet data network Gateway）を有してもよい。

一般ネットワーク５０は、ＩｏＴサービスに用いられるＵＥ以外のＵＥに関するデータを伝送するネットワークである。例えば、ＩｏＴサービスに用いられるＵＥ以外のＵＥは、サービスを利用する際にユーザ操作を伴う携帯電話もしくはスマートフォン等であってもよい。

ＩｏＴサービスは、スマートフォン等と比較して少量のデータを伝送する場合が多い。さらに、ＩｏＴサービスは、１日のうち、予め定められたタイミングにデータが伝送されるというトラヒック特性を有することもある。

一方、スマートフォン等の端末は、大容量の動画データを受信することもある。さらに、スマートフォン端末を用いて様々なサービスを利用することが可能であり、近年、スマートフォン端末が送受信するデータ量は増加していると考えられている。このように、ＩｏＴサービスに用いられる端末と、その他のサービスに用いられる端末とは、トラヒック特性が異なる。ここで、同じトラヒック特性の端末に関するトラヒックを同じネットワークにて扱うことによって、ネットワークを効率的に設計することができる。

例えば、伝送されるユーザデータの少ない端末に関するトラヒックを扱うネットワークであるＩｏＴネットワーク５２においては、ユーザデータを中継するＳＧＷ等のノード装置の数を少なくしてもよい。また、ＩｏＴネットワーク５２は、今後、スマートフォン等と比較して、多くの端末を収容する可能性もある。そのため、ＩｏＴネットワーク５２においては、制御データを処理するＭＭＥ等のノード装置の数を多くしてもよい。

一方、一般ネットワーク５０においては、伝送されるユーザデータの多い端末に関するトラヒックを扱う。そのため、一般ネットワーク５０においては、ユーザデータを中継するＳＧＷ等のノード装置の数を多くしてもよい。また、スマートフォン等の普及速度は、今後鈍化する可能性もある。そのため、ＩｏＴネットワーク５２においては、制御データを処理するＭＭＥ等のノード装置の数を少なくする、もしくは、現在のＭＭＥ等のノード装置の数を維持するようにしてもよい。

ゲートウェイ装置２０は、ＵＥ４０がＩｏＴサービスに用いられる端末か否かを判定し、ＵＥ４０に関するメッセージをＭＭＥ３０もしくはＭＭＥ３２に振り分ける。

続いて、図３を用いてＵＥ４０に関するＡｔｔａｃｈ処理の流れについて説明する。はじめに、ＵＥ４０は、ＮＡＳ（Non Access Stratum）メッセージであるAttach RequestメッセージをｅＮＢ１０へ送信する（Ｓ１１）。ＵＥ４０は、Attach Requestメッセージに、端末種別に関する情報を設定してもよい。端末種別に関する情報は、例えば、ＩｏＴサービスに用いられる端末か否かを示す情報であってもよい。具体的には、ＵＥ４０は、ＮＡＳメッセージに設定するパラメータであるDevice-Propertiesに端末種別に関する情報を設定してもよい。

次に、ｅＮＢ１０は、Ｓ１ＡＰメッセージであるInitial UE Messageをゲートウェイ装置２０へ送信する（Ｓ１２）。ｅＮＢ１０は、ＵＥ４０から受信したAttach RequestメッセージをInitial UE Messageに多重する。つまり、ｅＮＢ１０は、Attach Requestメッセージを含むInitial UE Messageをゲートウェイ装置２０へ送信する。Initial UE Messageの宛先は、ゲートウェイ装置２０が設定されてもよく、任意のＭＭＥが設定されてもよい。

ＵＥ４０に関する制御データを伝送するＭＭＥは、ゲートウェイ装置２０において決定される。そのため、Initial UE Messageの宛先に任意のＭＭＥが設定された場合、ゲートウェイ装置２０において、Initial UE Messageの宛先は変更される。また、Initial UE Messageの宛先に任意のＭＭＥが設定された場合であっても、Initial UE Messageは、ゲートウェイ装置２０へ送信されるように通信経路が設定される。

次に、ゲートウェイ装置２０は、Ｓ１ＡＰメッセージであるInitial UE Messageの振り分け先を判定する（Ｓ１３）。言い換えると、ゲートウェイ装置２０は、Initial UE Messageの送信先を決定する。ゲートウェイ装置２０は、Initial UE Messageに含まれるAttach Requestメッセージに設定された端末種別に関する情報を用いて、Initial UE Messageの振り分け先を判定する。ゲートウェイ装置２０は、端末種別に、ＩｏＴサービスに用いられる端末であることが示される情報が設定されている場合、Initial UE Messageの振り分け先がＭＭＥ３２であると判定する。図３においては、ゲートウェイ装置２０が、Initial UE Messageの振り分け先がＭＭＥ３２であると判定した場合について説明する。

次に、ゲートウェイ装置２０は、Initial UE Messageの送信元のアドレスをｅＮＢ１０の識別子からゲートウェイ装置２０の識別子へ変更する、もしくは、付け替える（Ｓ１４）。Initial UE Messageの送信元のアドレスは、Ｓ１ＡＰにおいて規定されるＳ１ＡＰレイヤにおけるアドレスである。Initial UE Messageの送信元のアドレスに設定する識別子を、eNB-S1AP-idとする。例えば、ゲートウェイ装置２０は、送信元のアドレスに、eNB-S1AP-id=Aと設定されたInitial UE Messageを受信すると、送信元アドレスを、eNB-S1AP-id=Cへ変更する。ゲートウェイ装置２０は、eNB-S1AP-id=AとeNB-S1AP-id=Cとを対応付けて管理する。言い換えると、ゲートウェイ装置２０は、eNB-S1AP-id=Aに対して、eNB-S1AP-id=Cを割り当てる。

次に、ゲートウェイ装置２０は、送信元のアドレスを変更したInitial UE MessageをＭＭＥ３２へ送信する（Ｓ１５）。次に、ＭＭＥ３２は、Ｓ１ＡＰメッセージであるDownlink NAS Transportメッセージをゲートウェイ装置２０へ送信する（Ｓ１６）。ＭＭＥ３２は、Downlink NAS Transportメッセージの宛先として、eNB-S1AP-id=Cを設定する。例えば、ＭＭＥ３２は、ＵＥ４０に関する認証を行うために用いるAuthentication RequestメッセージをDownlink NAS Transportメッセージに多重する。Authentication Requestメッセージは、ＮＡＳメッセージである。

次に、ゲートウェイ装置２０は、Downlink NAS Transportメッセージの送信元のアドレスをＭＭＥ３２の識別子からゲートウェイ装置２０の識別子へ変更する、もしくは、付け替える（Ｓ１７）。Downlink NAS Transportメッセージの送信元のアドレスは、Ｓ１ＡＰにおいて規定されるＳ１ＡＰレイヤにおけるアドレスである。Downlink NAS Transportメッセージの送信元のアドレスに設定する識別子を、MME-S1AP-idとする。例えば、ゲートウェイ装置２０は、送信元のアドレスに、MME-S1AP-id=Dと設定されたDownlink NAS Transportメッセージを受信すると、送信元アドレスを、MME-S1AP-id=Bへ変更する。ゲートウェイ装置２０は、MME-S1AP-id=DとMME-S1AP-id=Bとを対応付けて管理する。言い換えると、ゲートウェイ装置２０は、MME-S1AP-id=Dに対して、MME-S1AP-id=Bを割り当てる。

次に、ゲートウェイ装置２０は、送信元のアドレスを変更したDownlink NAS TransportメッセージをｅＮＢ１０へ送信する（Ｓ１８）。また、ゲートウェイ装置２０は、Downlink NAS Transportメッセージにおいて宛先として設定されたeNB-S1AP-id=Cを、eNB-S1AP-id=Cと関連付けられているeNB-S1AP-id=Aに変更する。ここで、ｅＮＢ１０は、Downlink NAS Transportメッセージを受信すると、Downlink NAS Transportメッセージに含まれるAuthentication RequestメッセージをＵＥ４０へ送信する。

次に、ＵＥ４０は、ＮＡＳメッセージであるAuthentication Responseを送信し、ｅＮＢ１０は、Authentication ResponseメッセージをＳ１ＡＰメッセージであるUplink NAS Transportメッセージに多重する。ｅＮＢ１０は、Authentication Responseメッセージを多重したUplink NAS Transportメッセージをゲートウェイ装置２０へ送信する（Ｓ１９）。ここで、ｅＮＢ１０は、Uplink NAS Transportメッセージの宛先として、MME-S1AP-id=Bを設定する。

次に、ゲートウェイ装置２０は、Uplink NAS Transportメッセージの送信元のアドレスを、eNB-S1AP-id=AからeNB-S1AP-id=Cへ変更し、さらに、宛先のアドレスをMME-S1AP-id=BからMME-S1AP-id=Dへ変更する（Ｓ２０）。以降、ＵＥ４０のＡｔｔａｃｈ処理を実行するために、ステップＳ１６〜Ｓ２１と同様に、Downlink NAS Transportメッセージ及びUplink NAS Transportメッセージが伝送される。

次に、ＭＭＥ３２は、ＵＥ４０に関するＡｔｔａｃｈ処理を完了した場合、ＮＡＳメッセージであるAttach Acceptメッセージを、Ｓ１ＡＰメッセージであるInitial Context Setup Requestメッセージに多重して、ゲートウェイ装置２０へ送信する（Ｓ２２）。ここで、ゲートウェイ装置２０は、ステップＳ１７と同様に、アドレス変換を行い、Initial Context Setup RequestメッセージをｅＮＢ１０へ送信する。

次に、ｅＮＢ１０は、ＵＥ４０との間において、無線ベアラを設定するために、E-RAB Setup処理を実行する（Ｓ２３）。次に、ｅＮＢ１０は、ＵＥ４０の能力情報、もしくは、性能情報をＭＭＥ３２へ通知するために、Ｓ１ＡＰメッセージである、UE Radio Access Capability Informationメッセージをゲートウェイ装置２０へ送信する（Ｓ２４）。ここで、ゲートウェイ装置２０は、ステップＳ２０と同様に、アドレス変換を行い、UE Radio Access Capability InformationメッセージをＭＭＥ３２へ送信する。

次に、ＵＥ４０は、ＮＡＳメッセージであるAttach Completeメッセージを送信し、ｅＮＢ１０は、Attach CompleteメッセージをＳ１ＡＰメッセージであるUplink NAS Transportメッセージに多重する。ｅＮＢ１０は、Attach Completeメッセージを多重したUplink NAS Transportメッセージをゲートウェイ装置２０へ送信する（Ｓ２５）。ここで、ゲートウェイ装置２０は、ステップＳ２０と同様に、アドレス変換を行い、Uplink NAS TransportメッセージをＭＭＥ３２へ送信する。

これ以降、ＵＥ４０に関するユーザデータであるUplink/Downlink Packetが、ｅＮＢ１０及びＳＧＷとの間において伝送される。ＳＧＷは、ＩｏＴネットワーク５２に配置されたノード装置である。また、ｅＮＢ１０とＳＧＷとの間において伝送されるUplink/Downlink Packetは、制御データと同様に、ゲートウェイ装置２０を介して伝送される。この場合、ゲートウェイ装置２０は、ステップＳ１７及びＳ２０と同様に、Uplink/Downlink Packetに設定されているアドレスの変換を行う。

続いて、図４を用いて本発明の実施の形態２にかかる無通信検出時の処理の流れについて説明する。はじめに、ｅＮＢ１０は、ＵＥ４０が所定の期間通信を行っていない、無通信状態であることを検出する（Ｓ３１）。

次に、ｅＮＢ１０は、ＵＥ４０との間の無線ベアラを解放するために、Ｓ１ＡＰメッセージであるUE Context Release Requestメッセージを、ゲートウェイ装置２０を介してＭＭＥ３２へ送信する（Ｓ３２）。ゲートウェイ装置２０は、図３のステップＳ２０と同様に、アドレス変換を行う。

次に、ＭＭＥ３２は、ＵＥ４０とｅＮＢ１０との間の無線ベアラを解放することを指示するために、Ｓ１ＡＰメッセージであるUE Context Release Commandメッセージを、ゲートウェイ装置２０を介してｅＮＢ１０へ送信する（Ｓ３３）。ゲートウェイ装置２０は、図３のステップＳ１７と同様に、アドレス変換を行う。

次に、ｅＮＢ１０は、ＵＥ４０との間の無線ベアラを解放する処理を実行する（Ｓ３４）。次に、ｅＮＢ１０は、Ｓ１ＡＰメッセージであるUE Context Release Completeメッセージを、ゲートウェイ装置２０を介してＭＭＥ３２へ送信する（Ｓ３５）。ゲートウェイ装置２０は、図３のステップＳ２０と同様に、アドレス変換を行う。

次に、ゲートウェイ装置２０は、eNB-S1AP-id=AとeNB-S1AP-id=Cとを関連付けた管理情報、さらに、MME-S1AP-id=BとMME-S1AP-id=Dとを関連付けた管理情報を解放、もしくは削除する（Ｓ３６）。言い換えると、ゲートウェイ装置２０は、eNB-S1AP-id=Aに対して割り当てたeNB-S1AP-id=C、及び、MME-S1AP-id=Dに対して割り当てたMME-S1AP-id=Bを解放する。

以上説明したように、本発明の実施の形態２にかかるAttach処理を実行することによって、ゲートウェイ装置２０は、ＵＥ４０の端末種別に応じてＭＭＥを選択し、選択したＭＭＥへＳ１ＡＰメッセージを振り分けることができる。また、ゲートウェイ装置２０は、Ｓ１ＡＰメッセージに設定されるアドレス情報を変換することによって、ゲートウェイ装置２０を介したｅＮＢ１０とＭＭＥとの間において、Ｓ１ＡＰメッセージを終端し、転送することができる。つまり、ゲートウェイ装置２０は、ｅＮＢ１０とＭＭＥとの間において伝送されるＳ１ＡＰメッセージのアドレスを変換することによって、ｅＮＢ１０とＭＭＥとの間において伝送されるＳ１ＡＰメッセージを中継することができる。

（実施の形態３）
続いて、図５を用いて本発明の実施の形態３にかかる通信システムの構成例について説明する。図５の通信システムは、図２の通信システムのｅＮＢ１０をＲＮＣ（Radio Network Controller）１２に置き換え、図２の通信システムのＭＭＥ３０及びＭＭＥ３２をＳＧＳＮ（Serving General packet radio service Support Node）３１及びＳＧＳＮ３３へ置き換えている。また、ＳＧＳＮ３１は、一般ネットワーク５０内に配置され、ＳＧＳＮ３３は、ＩｏＴネットワーク５２内に配置されている。図５のゲートウェイ装置２０は、図１及び図２のゲートウェイ装置２０と同様の構成であるため詳細な説明を省略する。

ＲＮＣ１２は、３Ｇと称される無線アクセスネットワークを制御するノード装置である。また、ＳＧＳＮ３１及びＳＧＳＮ３３は、ＵＥ４０の位置情報を管理し、さらに、ＵＥ４０に関する呼処理制御を実施するノード装置である。ＳＧＳＮ３１及びＳＧＳＮ３３は、ＵＥ４０に関する制御データ及びユーザデータを伝送する。

続いて、図６を用いて本発明の実施の形態３にかかるＵＥ４０のＡｔｔａｃｈ処理の流れについて説明する。はじめに、ＵＥ４０は、ＮＡＳメッセージであるAttach RequestメッセージをＲＮＣ１２へ送信する（Ｓ４１）。ＵＥ４０は、Attach Requestメッセージに、端末種別に関する情報を設定してもよい。端末種別に関する情報は、例えば、ＩｏＴサービスに用いられる端末か否かを示す情報であってもよい。ＵＥ４０は、ＮＡＳメッセージに設定するパラメータであるDevice-Propertiesに端末種別に関する情報を設定してもよい。

次に、ＲＮＣ１２は、ＲＡＮＡＰ（Radio Access Network Application Part）プロトコルメッセージであるInitial UE Messageをゲートウェイ装置２０へ送信する（Ｓ４２）。ＲＮＣ１２は、ＵＥ４０から受信したAttach RequestメッセージをInitial UE Messageに多重する。つまり、ＲＮＣ１２は、Attach Requestメッセージを含むInitial UE Messageをゲートウェイ装置２０へ送信する。Initial UE Messageの宛先は、ゲートウェイ装置２０が設定されてもよく、任意のＳＧＳＮが設定されてもよい。

ＵＥ４０に関する制御データを伝送するＳＧＳＮは、ゲートウェイ装置２０において決定される。そのため、Initial UE Messageに任意のＳＧＳＮが設定された場合、ゲートウェイ装置２０において、Initial UE Messageの宛先は変更される。

次に、ゲートウェイ装置２０は、ＲＡＮＡＰプロトコルメッセージであるInitial UE Messageの振り分け先を判定する（Ｓ４３）。言い換えると、ゲートウェイ装置２０は、Initial UE Messageの送信先を決定する。ゲートウェイ装置２０は、Initial UE Messageに含まれるAttach Requestメッセージに設定された端末種別に関する情報を用いて、Initial UE Messageの振り分け先を判定する。ゲートウェイ装置２０は、端末種別に、ＩｏＴサービスに用いられる端末であることが示される情報が設定されている場合、Initial UE Messageの振り分け先がＳＧＳＮ３３であると判定する。図６においては、ゲートウェイ装置２０が、Initial UE Messageの振り分け先がＳＧＳＮ３３であると判定した場合について説明する。

次に、ゲートウェイ装置２０は、Initial UE Messageの送信元のアドレスをＲＮＣ１２の識別子からゲートウェイ装置２０の識別子へ変更する、もしくは、付け替える（Ｓ４４）。Initial UE Messageの送信元のアドレスは、ＲＡＮＡＰプロトコルにおいて規定されるＳＣＣＰレイヤにおけるアドレスである。Initial UE Messageの送信元のアドレスに設定する識別子を、Source-LRとする。例えば、ゲートウェイ装置２０は、送信元のアドレスに、Source-LR=A1と設定されたInitial UE Messageを受信すると、送信元アドレスを、Source-LR=C1へ変更する。ゲートウェイ装置２０は、Source-LR=A1とSource-LR=C1とを対応付けて管理する。言い換えると、ゲートウェイ装置２０は、Source-LR=A1に対して、Source-LR=C1を割り当てる。

次に、ゲートウェイ装置２０は、送信元のアドレスを変更したInitial UE MessageをＳＧＳＮ３３へ送信する（Ｓ４５）。次に、ＳＧＳＮ３３は、ＲＡＮＡＰプロトコルメッセージであるDirect Transferメッセージをゲートウェイ装置２０へ送信する（Ｓ４６）。ＳＧＳＮ３３は、Direct Transferメッセージの宛先として、Source-LR=C1を設定する。

次に、ゲートウェイ装置２０は、Direct Transferメッセージの送信元のアドレスをＳＧＳＮ３３の識別子からゲートウェイ装置２０の識別子へ変更する、もしくは、付け替える（Ｓ４７）。Direct Transferメッセージの送信元のアドレスは、ＲＡＮＡＰプロトコルにおいて規定されるＳＣＣＰレイヤにおけるアドレスである。Direct Transferメッセージの送信元のアドレスに設定する識別子を、Source-LR=D1とする。例えば、ゲートウェイ装置２０は、送信元のアドレスに、Source-LR=D1と設定されたDirect Transferメッセージを受信すると、送信元アドレスを、Source-LR=B1へ変更する。ゲートウェイ装置２０は、Source-LR=D1とSource-LR=B1とを対応付けて管理する。言い換えると、ゲートウェイ装置２０は、Source-LR=D1に対して、Source-LR=B1を割り当てる。

次に、ゲートウェイ装置２０は、送信元のアドレスを変更したDirect TransferメッセージをＲＮＣ１２へ送信する（Ｓ４８）。また、ゲートウェイ装置２０は、Direct Transferメッセージにおいて宛先として設定されたSource-LR=C1を、Source-LR=C1と関連付けられているSource-LR=A1に変更する。ここで、ＲＮＣ１２は、Direct Transferメッセージを受信すると、Direct Transferメッセージに含まれるＮＡＳメッセージをＵＥ４０へ送信する。

以降のＡｔｔａｃｈ処理は、３ＧＰＰにおいて規定されている既知の処理であるため、詳細な説明を省略する。また、図６においては、Ａｔｔａｃｈ処理の流れについて説明したが、ＰＤＰ接続処理においても同様に、ゲートウェイ装置２０は、ＲＮＣ１２とＳＧＳＮ３１との間において、ＲＡＮＡＰプロトコルメッセージを終端し、転送することができる。

続いて、図７を用いて本発明の実施の形態３にかかる無線ベアラ解放処理の流れについて説明する。はじめに、ＳＧＳＮ３３は、ＵＥ４０とＲＮＣ１２との間の無線ベアラを解放することを指示するために、ＲＡＮＡＰプロトコルメッセージであるIu Release Commandメッセージを、ゲートウェイ装置２０を介してＲＮＣ１２へ送信する（Ｓ５１）。ゲートウェイ装置２０は、図６のステップＳ４７と同様に、アドレス変換を行う。

次に、ＲＮＣ１２は、ＵＥ４０との間の無線ベアラを解放する処理を実行する（Ｓ５２）。次に、ＲＮＣ１２は、ＲＡＮＡＰプロトコルメッセージであるIu Release Completeメッセージを、ゲートウェイ装置２０を介してＳＧＳＮ３３へ送信する（Ｓ５３）。ゲートウェイ装置２０は、図６のステップＳ４４と同様に、アドレス変換を行う。

次に、ゲートウェイ装置２０は、Source-LR=A1とSource-LR=C1とを関連付けた管理情報、さらに、Source-LR=B1とSource-LR=D1とを関連付けた管理情報を解放、もしくは削除する（Ｓ５４）。言い換えると、ゲートウェイ装置２０は、Source-LR=A1に対して割り当てたSource-LR=C1、及び、Source-LR=D1に対して割り当てたSource-LR=B1を解放する。

以上説明したように、本発明の実施の形態３にかかる通信システムにおいても、実施の形態２と同様に、ＲＮＣ１２とＳＧＳＮ３１との間において、ＲＡＮＡＰプロトコルメッセージを終端し、転送することができる。

（実施の形態４）
続いて、図８を用いて本発明の実施の形態４にかかる通信システムの構成例について説明する。図８の通信システムは、図２の通信システムに、ＤＢ（データベース）６０及びＨＳＳ（Home Subscriber Server）６４が追加されている。さらに、ＩｏＴネットワーク５２内に、ＩｏＴコアネットワーク７１、ＩｏＴコアネットワーク７２、及びＩｏＴコアネットワーク７３が存在し、ＩｏＴコアネットワーク７１内には、ＭＭＥ３６が配置され、ＩｏＴコアネットワーク７２内には、ＭＭＥ３７が配置され、ＩｏＴコアネットワーク７３内には、ＭＭＥ３８が配置されている。さらに、ＩｏＴコアネットワーク７１には、サーバ装置８１が接続し、ＩｏＴコアネットワーク７２には、サーバ装置８２が接続し、ＩｏＴコアネットワーク７３には、サーバ装置８３が接続する。

ＩｏＴネットワーク５２は、提供するＩｏＴサービス毎にＩｏＴコアネットワーク７１、ＩｏＴコアネットワーク７２、及びＩｏＴコアネットワーク７３等のように、ＩｏＴコアネットワークが分けられている。もしくは、一つのＩｏＴコアネットワークにおいて、複数のＩｏＴサービスが提供されてもよい。

ＩｏＴサービスには、例えば、スマートメーターを管理するサービス、交通制御を行うサービス、官庁もしくは緊急機関等に関連したサービス、物流を管理するサービス、セキュリティを提供するサービス、もしくは、在庫管理を行うサービス等、様々なサービスがある。

また、サーバ装置８１、サーバ装置８２、及びサーバ装置８３は、ＩｏＴサービスを提供するサービス事業者が管理するサーバ装置であってもよい。つまり、ＩｏＴコアネットワーク７１は、サーバ装置８１を管理するサービス事業者に提供するＩｏＴコアネットワークであると称してもよい。ＩｏＴコアネットワーク７２及びＩｏＴコアネットワーク７３も、ＩｏＴコアネットワーク７１と同様である。

ゲートウェイ装置２０は、ｅＮＢ１０から送信されたＳ１ＡＰメッセージを終端し、複数のＩｏＴコアネットワークの中から、Ｓ１ＡＰメッセージを送信するコアネットワークを特定する。ゲートウェイ装置２０は、Ｓ１ＡＰメッセージを送信するコアネットワークを特定する際に、ＤＢ６０を用いる。

ＤＢ６０は、ＵＥ４０の識別情報と、ＵＥ４０が登録されるＩｏＴコアネットワークの識別情報とを関連付けて管理する。ゲートウェイ装置２０は、Ｓ１ＡＰメッセージに含まれるＵＥ４０の識別情報を用いて、ＤＢ６０から、ＵＥ４０に関連付けられているＩｏＴコアネットワークの識別情報を抽出する。また、ゲートウェイ装置２０は、特定したＩｏＴコアネットワークに配置されているＭＭＥへＳ１ＡＰメッセージを送信する。

ＨＳＳ６４は、複数のＵＥに関する加入者情報を管理する。例えば、ＨＳＳ６４は、それぞれのＵＥの電話番号及び位置情報等を管理する。ＭＭＥ３５〜３８は、ＨＳＳ６４において管理されている加入者情報を用いて、呼処理制御等を実行する。

続いて、図９を用いて、ＤＢ６０が管理する情報について説明する。ＤＢ６０は、情報管理部６１及び情報管理部６２を有している。情報管理部６１及び情報管理部６２は、ＤＢ６０内のメモリ等であってもよく、ＤＢ６０に取り付けられる外部メモリ等であってもよい。

情報管理部６１は、ＩｏＴ種別に関する情報と、ＣＮ（コアネットワーク）種別に関する情報とを関連付けて管理する。ＩｏＴ種別に関する情報は、例えば、ＩｏＴサービスを識別する情報であってもよい。図９においては、ＩｏＴ種別に関する情報として、１〜４の数字が用いられている。また、ＣＮ種別に関する情報は、ＩｏＴコアネットワークを識別する情報である。図９においては、ＣＮ種別に関する情報として、図８におけるＩｏＴコアネットワーク毎に付した７１〜７３の符号が用いられている。

情報管理部６２は、加入者番号に関する情報と、ＩｏＴ種別に関する情報とを関連付けて管理する。加入者番号に関する情報とは、例えば、ＵＥ４０に割り当てられている電話番号もしくは機体番号等であってもよい。図９においては、加入者番号に関する情報として、Ａ〜Ｄの文字が用いられている。

続いて、図１０を用いて本発明の実施の形態４にかかるパケット振り分け処理の流れについて説明する。はじめに、ＤＢ６０は、図９に示す情報を登録する（Ｓ６１）。例えば、ＤＢ６０は、他のサーバ装置等から図９に示す情報を取得してもよく、もしくは、ＤＢ６０を管理するユーザ等から図９に示す情報が入力されてもよい。

次に、ＵＥ４０は、パケット通信を開始するために、ｅＮＢ１０へ、パケット通信開始要求メッセージを送信する（Ｓ６２）。ＵＥ４０は、加入者番号をパケット通信開始要求メッセージに設定する。ここでは、ＵＥ４０は、加入者番号Ａをパケット通信開始要求メッセージに設定したとする。次に、ｅＮＢ１０は、ＵＥ４０から受信したパケット通信開始要求メッセージを、ゲートウェイ装置２０へ送信する（Ｓ６３）。この時、ｅＮＢ１０は、ｅＮＢ１０とＭＭＥとの間の通信に用いられるＳ１ＡＰメッセージとしてパケット通信開始要求メッセージをゲートウェイ装置２０へ送信する。

次に、ゲートウェイ装置２０は、ｅＮＢ１０から送信されたＳ１ＡＰメッセージであるパケット通信開始要求メッセージを終端し、ＵＥ４０の加入者番号を抽出する。さらに、ＵＥ４０は、抽出した加入者番号Ａを設定したＱｕｅｒｙメッセージをＤＢ６０へ送信する（Ｓ６４）。ＤＢ６０は、加入者番号が設定されたＱｕｅｒｙメッセージを受信すると、情報管理部６２を用いて、加入者番号に対応付けられたＩｏＴ種別を特定する。さらに、ＤＢ６０は、情報管理部６１を用いて、ＩｏＴ種別に対応付けられたＣＮ種別を特定する。ここでは、Ｑｕｅｒｙメッセージに加入者番号Ａが設定されているため、ＤＢ６０は、ＩｏＴ種別：２、及び、ＣＮ種別：７２を特定する。

次に、ＤＢ６０は、ＣＮ種別：７２を設定したＡｎｓｗｅｒメッセージをゲートウェイ装置２０へ送信する（Ｓ６５）。次に、ゲートウェイ装置２０は、パケット通信開始要求メッセージの振り分け先を判定する（Ｓ６６）。言い換えると、ゲートウェイ装置２０は、パケット通信開始要求メッセージの送信先を決定する。ゲートウェイ装置２０は、Ａｎｓｗｅｒメッセージに設定されたＣＮ種別：７２に対応する、ＩｏＴコアネットワーク７２に配置されているＭＭＥ３７へ、パケット通信開始要求メッセージを送信することを決定する。

次に、ゲートウェイ装置２０は、ＭＭＥ３７へ送信するＳ１ＡＰメッセージであるパケット通信開始要求メッセージの送信元アドレスを、ｅＮＢ１０の識別情報からゲートウェイ装置２０の識別情報に変更する（Ｓ６７）。ステップＳ６７におけるアドレス変換処理は、図３のステップＳ１４及びＳ２０におけるアドレス変換処理と同様であるため詳細な説明を省略する。

次に、ゲートウェイ装置２０は、ＭＭＥ３７へパケット通信開始要求メッセージを送信する（Ｓ６８）。次に、ＭＭＥ３７は、ＨＳＳ６４へ、ＵＥ４０の位置登録情報の送信を要求するために、位置登録要求メッセージを送信する（Ｓ６９）。次に、ＨＳＳ６４は、ＵＥ４０の位置情報を含む加入者情報をＭＭＥ３７へ送信する（Ｓ７０）。

以上説明したように、本発明の実施の形態４にかかる通信システムを用いることによって、ＩｏＴサービス毎に分離したＩｏＴコアネットワークが存在する場合に、ゲートウェイ装置２０は、ＵＥ４０が利用するＩｏＴサービスに関するデータを伝送するＩｏＴコアネットワークへ、ＵＥ４０に関するデータを中継することができる。

ここで、ステップＳ６１における、加入者番号、ＩｏＴ種別、及び、ＣＮ種別に関する情報を登録する際に、各ＭＭＥにおける加入者の登録状況等に基づいて、ＤＢ６０に情報が登録されてもよい。

例えば、同じＩｏＴサービスに関するデータを伝送する複数のＩｏＴコアネットワークが存在する場合について説明する。この場合、外部監視装置等が、それぞれのＩｏＴコアネットワークに登録されているＵＥの数を監視していてもよい。さらに、外部監視装置等は、それぞれのＩｏＴコアネットワークに登録されるＵＥの数が均等になるように、もしくは、一部のＩｏＴコアネットワークに登録されるＵＥの数が偏らないように、それぞれのＵＥに対応付けられるＩｏＴ種別を決定してもよい。外部監視装置等は、決定した、加入者番号とＩｏＴ種別とを対応付けた情報をＤＢ６０へ送信してもよい。

つまり、加入者番号とＩｏＴ種別とを対応付けた情報は、外部監視装置等から定期的、もしくは、任意のタイミングに、ＵＥの登録状況等に応じてＤＢ６０へ送信されてもよい。

また、実施の形態４においては、ｅＮＢ１０の代わりにＲＮＣが用いられ、ＭＭＥの代わりにＳＧＳＮが用いられてもよい。

また、実施の形態１乃至３においても、実施の形態４において説明したように、ゲートウェイ装置２０が、ＤＢ６０を用いて、メッセージの振り分け先を決定してもよい。

（実施の形態５）
続いて、図１１を用いて本発明の実施の形態５にかかるパケット振り分け処理の流れについて説明する。はじめに、ＤＢ６０は、図９に示す情報管理部６１が管理する情報を登録する（Ｓ８１）。さらに、ＨＳＳ６４は、図９に示す情報管理部６２が管理する情報を登録する（Ｓ８２）。

ステップＳ８３〜Ｓ８５は、図１０のステップＳ６２〜Ｓ６４と同様であるため詳細な説明を省略する。ＤＢ６０は、ＵＥ４０の加入者番号Ａが設定されたＱｕｅｒｙメッセージを受信すると、受信したＱｕｅｒｙメッセージをＨＳＳ６４へ送信する（Ｓ８６）。

次に、ＨＳＳ６４は、加入者番号Ａが設定されたＱｕｅｒｙメッセージを受信すると、加入者番号Ａに関連付けられているＩｏＴ種別：２を特定する。ＨＳＳ６４は、ＩｏＴ種別：２を設定したＡｎｓｗｅｒメッセージをＤＢ６０へ送信する（Ｓ８７）。

次に、ＤＢ６０は、ＩｏＴ種別：２に関連付けられたＣＮ種別：７２を設定したＡｎｓｗｅｒメッセージをゲートウェイ装置２０へ送信する（Ｓ８８）。ステップＳ８９〜ステップＳ９３は、図１０のステップＳ６６〜ステップＳ７０と同様であるため詳細な説明を省略する。

以上説明したように、本発明の実施の形態５にかかるパケット振り分け処理を実行する際に、ＤＢ６０及びＨＳＳ６４において管理されている情報が用いられる。パケット振り分け処理に用いられる情報は、ＤＢ６０及びＨＳＳ６４に分散して管理される。これより、実施の形態４におけるＤＢ６０と比較して、実施の形態５におけるＤＢ６０のメモリ容量を少なくすることができる。

また、ＩｏＴサービスに用いられるＵＥ４０は、スマートメーターもしくは車載端末等のように、ＩｏＴサービス専用の端末であることもある。そのため、ＩｏＴサービスに用いられるＵＥ４０には、予めＩｏＴ種別が登録されていてもよい。例えば、ＵＥ４０の製造時、出荷時、もしくは、通信事業者との契約時等に、ＵＥ４０に、ＩｏＴ種別が登録されもよい。

この場合、ＵＥ４０は、ステップＳ８３におけるパケット通信開始要求メッセージに、加入者番号とともに、ＩｏＴ種別に関する情報を設定してもよい。これにより、ＤＢ６０は、ＩｏＴ種別が設定されたＱｕｅｒｙメッセージを受信すると、ＨＳＳ６４にＱｕｅｒｙメッセージを送信することなく、ＩｏＴ種別に関連付けられたＣＮ種別を設定したＡｎｓｗｅｒメッセージをゲートウェイ装置２０へ送信することができる。

また、実施の形態５においては、ｅＮＢ１０の代わりにＲＮＣが用いられ、ＭＭＥの代わりにＳＧＳＮが用いられてもよい。

（実施の形態６）
続いて、図１２を用いて本発明の実施の形態６にかかるＳＧＳＮ３１の構成例について説明する。ＳＧＳＮ３１以外の他のＳＧＳＮは、ＳＧＳＮ３１と同様の構成であるため詳細な説明を省略する。また、ＳＧＳＮ３１は、コアネットワーク内に配置される中継ノード装置等と称されてもよい。

ＳＧＳＮ３１は、制御部９１、加入者データ保持部９２、及び、セッション情報保持部９３を有している。制御部９１は、プロセッサがメモリに格納されたプログラムを実行することによって動作するソフトウェアもしくはモジュールであってもよい。または、制御部９１は、回路もしくはチップ等のハードウェアであってもよい。加入者データ保持部９２及びセッション情報保持部９３は、ＳＧＳＮ３１内のメモリであってもよく、ＳＧＳＮ３１に取り付けられる外部メモリであってもよい。

加入者データ保持部９２は、加入者情報管理装置であるＨＳＳ６４から送信されたＵＥ４０の加入者データを保持する。加入者データ保持部９２がＵＥ４０の加入者データを保持しておくことによって、ＵＥ４０が通信を実行する際に、ＳＧＳＮ３１がＨＳＳ６４から加入者データを取得する処理を省略することができる。加入者データは、例えば、ＶＬＲ（Visitor Location Register）情報と称されてもよい。

加入者データ保持部９２は、例えば、ＵＥ４０に関するＡｔｔａｃｈ処理時にＨＳＳ６４から送信されたＵＥ４０に関する加入者データを保持する。

セッション情報保持部９３は、ＵＥ４０に関するセッション情報を保持する。セッション情報は、ネットワーク層より上位のプロトコルにて用いられる情報であって、ＵＥ４０とＲＮＣ１２との間の無線ネットワーク、及び、コアネットワーク内においてＵＥ４０を一意に識別する識別情報であってもよい。セッション情報は、例えば、ＰＤＰ（Packet Data Protocol）情報もしくはＰＤＰコンテキスト等と称されてもよい。セッション情報保持部９３は、ＵＥ４０に関するユーザデータが伝送される間、ＵＥ４０に関するセッション情報を保持する。

制御部９１は、加入者データ保持部９２においてＵＥ４０の加入者データを保持するか否かを判定する。さらに、制御部９１は、セッション情報保持部９３においてＵＥ４０のセッションデータを保持するか否かを判定する。

制御部９１は、ＵＥ４０に関するユーザデータの伝送が行われていない場合に、ＩｏＴサービスポリシーに従い加入者データ保持部９２においてＵＥ４０の加入者データを保持するか否かを判定する。

ＵＥ４０に関するユーザデータの伝送が行われていない場合とは、例えば、ＵＥ４０に関するユーザデータの伝送が行われる前に実行されるＡｔｔａｃｈ処理の間、さらに、ＵＥ４０の無通信状態を検出した場合等であってもよい。

ＩｏＴサービスポリシーは、例えば、ＵＥ４０がパケット通信の開始を要求してから、ＵＥ４０がコアネットワークに接続するまでの接続時間が定められてもよい。接続時間は、具体的には、ＵＥ４０がパケット通信の開始を要求してから、実際にパケット通信が実行されるまでの時間であってもよい。

例えば、加入者データ保持部９２がＵＥ４０の加入者データを保持していない場合に、ＵＥ４０がパケット通信を開始する場合について説明する。この場合、ＳＧＳＮ３１は、ＵＥ４０のパケット通信を実行するために、ＨＳＳ６４から加入者データを取得する必要がある。つまり、ＳＧＳＮ３１が、ＨＳＳ６４からＵＥ４０に関する加入者データを取得する処理が実行される時間だけ、加入者データ保持部９２がＵＥ４０に関する加入者データを保持している場合と比較して、ＵＥ４０がパケット通信を実行するまで余計な時間がかかる。

一方、加入者データ保持部９２が、ＵＥ４０に関する加入者データを保持しない場合、メモリ容量を削減することができる。そのため、制御部９１は、加入者データ保持部９２においてＵＥ４０に関する加入者データを保持しない場合であっても、ＩｏＴサービスポリシーに定められた接続時間を超えることが無い場合、加入者データ保持部９２においてＵＥ４０に関する加入者データを保持しないと判定してもよい。

また、ＩｏＴサービスポリシーは、ＵＥ４０に対するＳＭＳ着信を許容するか否かが定められてもよい。例えば、加入者データ保持部９２がＵＥ４０に関する加入者データを保持しない場合、ＵＥ４０に対するＳＭＳ着信が正常に実行されないことがある。そのため、ＩｏＴサービスポリシーにおいて、ＵＥ４０に対するＳＭＳ着信を許容することが定められている場合、制御部９１は、加入者データ保持部９２においてＵＥ４０に関する加入者データを保持すると判定してもよい。一方、ＩｏＴサービスポリシーにおいて、ＵＥ４０に対するＳＭＳ着信を許容しないことが定められている場合、制御部９１は、加入者データ保持部９２において、ＵＥ４０に関する加入者データを保持しないと判定してもよい。

ＩｏＴサービスポリシーは、サービス事業者毎に異なる。つまり、ＩｏＴサービスポリシーは、ＩｏＴコアネットワークごとに異なる。そのため、それぞれのＩｏＴコアネットワークに配置されているＳＧＳＮは、ＩｏＴサービスポリシーに関する情報を予め保持している。

続いて、図１３を用いて、本発明の実施の形態６にかかるＡｔｔａｃｈ処理の流れについて説明する。はじめに、ＵＥ４０は、ＲＮＣ１２を介して、ＳＧＳＮ３１へAttach Requestメッセージを送信する（Ｓ１０１）。ＵＥ４０は、例えば、ＵＥ４０の識別情報であるＩＭＳＩ（International Mobile Subscriber Identity）をAttach Requestメッセージに設定する。

次に、ＳＧＳＮ３１は、ＵＥ４０のＩＭＳＩを設定したMAP-Send Authentication InfoメッセージをＨＳＳ６４へ送信する（Ｓ１０２）。次に、ＨＳＳ６４は、MAP-Send Authentication Infoメッセージに対する応答メッセージとして、MAP-Send Authentication Info AckメッセージをＳＧＳＮ３１へ送信する（Ｓ１０３）。ＨＳＳ６４は、MAP-Send Authentication Info Ackメッセージに、ＵＥ４０に関する認証情報を設定する。

次に、ＳＧＳＮ３１は、ＨＳＳ６４から送信されたＵＥ４０に関する認証情報を用いて、ＵＥ４０に関する認証処理を実行する（Ｓ１０４）。次に、ＳＧＳＮ３１は、ＨＳＳ６４へMAP-Update GPRS Locationメッセージを送信する（Ｓ１０５）。ＳＧＳＮ３１は、ＵＥ４０のＩＭＳＩ及び自装置のＳＧＳＮ番号をMAP-Update GPRS Locationメッセージに設定する（Ｓ１０５）。次に、ＨＳＳ６４は、MAP-Insert Subscriber DataメッセージをＳＧＳＮ３１へ送信する（Ｓ１０６）。ＨＳＳ６４は、ＵＥ４０に関する加入者データをMAP-Insert Subscriber Dataメッセージに設定する。

次に、ＳＧＳＮ３１は、ＲＮＣ１２を介してＵＥ４０へ、Attach Acceptメッセージを送信する（Ｓ１０７）。次に、ＵＥ４０は、ＲＮＣ１２を介してＳＧＳＮ３１へ、Attach Completeメッセージを送信する（Ｓ１０８）。

ＳＧＳＮ３１は、Attach Completeメッセージを受信すると、ＩｏＴサービスポリシーに基づいてＵＥ４０の加入者データを保持するか否かを判定し、ここでは、加入者データ（ＶＬＲ情報）を生成しないと判定する（Ｓ１０９）。

続いて、図１４を用いて、ＳＧＳＮ３１が加入者データを生成していない状態において、ＵＥ４０が、パケット通信を開始する場合について説明する。はじめに、ＵＥ４０は、パケット通信を開始するために、ＲＮＣ１２を介してService RequestメッセージをＳＧＳＮ３１へ送信する（Ｓ１１１）。ＳＧＳＮ３１は、ＵＥ４０からService Requestメッセージを受信した際に、ＵＥ４０の加入者データを保持していないため、ＵＥ４０へService Rejectメッセージを送信する（Ｓ１１２）。ＳＧＳＮ３１は、ＲＮＣ１２を介してＵＥ４０へService Rejectメッセージを送信することによって、ＵＥ４０のパケット通信を拒否する。

ステップＳ１１３以降、ＵＥ４０は、パケット通信を開始するための処理を実行する。ステップＳ１１３〜Ｓ１１６は、図１３のステップＳ１０１〜Ｓ１０４と同様であるため詳細な説明を省略する。

ステップＳ１１６において、ＵＥ４０に関する認証処理が完了すると、ＵＥ４０は、ＲＮＣ１２を介してＳＧＳＮ３１へ、Active PDP Context Requestメッセージを送信する（Ｓ１１７）。ステップＳ１１８及びＳ１１９は、図１３のステップＳ１０５及びＳ１０６と同様であるため詳細な説明を省略する。

次に、ＳＧＳＮ３１は、ステップＳ１１９において、ＨＳＳ６４から送信された加入者データを保持する、言い換えると、ＶＬＲ情報を生成する（Ｓ１２０）。例えば、ＳＧＳＮ３１は、Service Rejectメッセージを送信後のＡｔｔａｃｈ処理においてＨＳＳ６４から送信された加入者データについては保持すると判定してもよい。

次に、ＵＥ４０、ＲＮＣ１２、及び、ＳＧＳＮ３１において、ＵＥ４０とＲＮＣ１２との間において、ＲＡＢ（Radio Access Bearer）を確立するための処理が実行される（Ｓ１２１）。

次に、ＳＧＳＮ３１は、ＲＮＣ１２を介して、ＵＥ４０へActive PDP Context Acceptメッセージを送信する（Ｓ１２２）。Active PDP Context Acceptメッセージは、ステップＳ１１７のActive PDP Context Requestメッセージに対する応答メッセージである。

次に、ＵＥ４０、ＲＮＣ１２、及びＳＧＳＮ３１は、ＵＥ４０に関するＰＤＰ情報を保持する（Ｓ１２３）。ＵＥ４０、ＲＮＣ１２、及びＳＧＳＮ３１がＵＥ４０に関するＰＤＰ情報を保持することによって、ＵＥ４０は、パケット通信を実行することができる。

続いて、図１５を用いて、ＵＥ４０におけるパケット通信が完了した際の処理の流れについて説明する。ＵＥ４０及びＲＮＣ１２は、ＰＤＰ情報を保持している状態であり、ＳＧＳＮ３１は、ＰＤＰ情報及びＶＬＲ情報を保持している状態とする（Ｓ１３１）。

ＵＥ４０は、パケット通信を終了する際に、ＲＮＣ１２を介してDeactivate PDP Context RequestメッセージをＳＧＳＮ３１へ送信する（Ｓ１３２）。次に、ＳＧＳＮ３１は、ＲＮＣ１２を介してDeactivate PDP Context AcceptメッセージをＵＥ４０へ送信する（Ｓ１３３）。

Deactivate PDP Context Acceptメッセージを送信もしくは受信すると、ＵＥ４０、ＲＮＣ１２、及び、ＳＧＳＮ３１は、ＰＤＰ情報を削除する（Ｓ１３４）。次に、ＳＧＳＮ３１は、ＩｏＴサービスポリシーもしくはＳＭＳ受信を許容するか否かに関する情報に基づいて、ＶＬＲ情報を削除するか否かを判定する。（Ｓ１３５）。

続いて、図１６を用いて、ＵＥ４０が無通信状態であることを検出した場合の処理の流れについて説明する。ＵＥ４０及びＲＮＣ１２は、ＰＤＰ情報を保持している状態であり、ＳＧＳＮ３１は、ＰＤＰ情報及びＶＬＲ情報を保持している状態とする（Ｓ１４１）。

ＲＮＣ１２は、ＵＥ４０との間において所定期間ユーザデータを伝送していないと判定した場合、無通信検出メッセージをＳＧＳＮ３１へ送信する（Ｓ１４２）。次に、無通信検出メッセージを送信したＲＮＣ１２、及び、無通信検出メッセージを受信したＳＧＳＮ３１は、ＰＤＰ情報を削除する（Ｓ１４３）。ＵＥ４０は、ＰＤＰ情報を保持している状態とする。

次に、ＳＧＳＮ３１は、ＩｏＴサービスポリシーもしくはＳＭＳ受信を許容するか否かに関する情報に基づいて、ＶＬＲ情報を削除するか否かを判定する（Ｓ１４４）。

以上説明したように、本発明の実施の形態６にかかるＳＧＳＮを用いることによって、ＰＤＰ情報及びＶＬＲ情報を保持するか否かを判定することができる。ＳＧＳＮは、サービスポリシーに基づいて、ＰＤＰ情報もしくはＶＬＲ情報を削除した場合、メモリ容量を節約することができる。

今後、ＩｏＴサービスに用いられる端末が増加することが予測されるため、ＳＧＳＮにおけるＰＤＰ情報及びＶＬＲ情報に割り当てるメモリ容量を節約することによって、ＳＧＳＮにおける端末の収容数を増加させることができる。

また、図１３、図１５及び図１６においては、ＳＭＳ受信を許容しない場合には、ＶＬＲ情報を削除するとして説明している。ただし、ＳＧＳＮ３１は、ＶＬＲ情報を削除した状態において、ＵＥ４０に対するＳＭＳ受信が通知された場合、ＨＳＳ６４からＵＥ４０に関するＶＬＲ情報を取得することによって、ＳＭＳ受信処理を実行してもよい。

また、実施の形態６においては、ＲＮＣ１２の代わりにｅＮＢが用いられ、ＳＧＳＮ３１の代わりにＭＭＥが用いられてもよい。

上述の実施の形態では、本発明をハードウェアの構成として説明したが、本発明は、これに限定されるものではない。本発明は、ゲートウェイ装置もしくはその他ノード装置における処理を、ＣＰＵ（Central Processing Unit）にコンピュータプログラムを実行させることにより実現することも可能である。

上述の例において、プログラムは、様々なタイプの非一時的なコンピュータ可読媒体（non-transitory computer readable medium）を用いて格納され、コンピュータに供給することができる。非一時的なコンピュータ可読媒体は、様々なタイプの実体のある記録媒体（tangible storage medium）を含む。非一時的なコンピュータ可読媒体の例は、磁気記録媒体（例えばフレキシブルディスク、磁気テープ、ハードディスクドライブ）、光磁気記録媒体（例えば光磁気ディスク）、ＣＤ−ＲＯＭ（Read Only Memory）、ＣＤ−Ｒ、ＣＤ−Ｒ／Ｗ、半導体メモリ（例えば、マスクＲＯＭ、ＰＲＯＭ（Programmable ROM）、ＥＰＲＯＭ（Erasable PROM）、フラッシュＲＯＭ、ＲＡＭ（Random Access Memory））を含む。また、プログラムは、様々なタイプの一時的なコンピュータ可読媒体（transitory computer readable medium）によってコンピュータに供給されてもよい。一時的なコンピュータ可読媒体の例は、電気信号、光信号、及び電磁波を含む。一時的なコンピュータ可読媒体は、電線及び光ファイバ等の有線通信路、又は無線通信路を介して、プログラムをコンピュータに供給できる。

なお、本発明は上記実施の形態に限られたものではなく、趣旨を逸脱しない範囲で適宜変更することが可能である。

１０ ｅＮＢ
１２ ＲＮＣ
２０ ゲートウェイ装置
２１ 通信部
２２ 判定部
２３ 変換部
３０ ＭＭＥ
３１ ＳＧＳＮ
３２ ＭＭＥ
３３ ＳＧＳＮ
３５ ＭＭＥ
３６ ＭＭＥ
３７ ＭＭＥ
３８ ＭＭＥ
４０ ＵＥ
５０ 一般ネットワーク
５２ ＩｏＴネットワーク
６０ ＤＢ
６１ 情報管理部
６２ 情報管理部
６４ ＨＳＳ
７１ ＩｏＴコアネットワーク
７２ ＩｏＴコアネットワーク
７３ ＩｏＴコアネットワーク
８１ サーバ装置
８２ サーバ装置
８３ サーバ装置
９１ 制御部
９２ 加入者データ保持部
９３ セッション情報保持部

Claims (10)

1. コアネットワークに配置され、移動局に関するユーザデータを伝送する中継ノード装置であって、
   加入者情報管理装置から送信された移動局の加入者データを保持する加入者データ保持部と、
   前記移動局に関するユーザデータの伝送が行われていない場合に、ＩｏＴサービスポリシーに従い前記加入者データ保持部において前記移動局の加入者データを保持するか否かを判定する制御部と、を備え、
   前記制御部は、
   前記ＩｏＴサービスポリシーとして、前記移動局が通信を実行するために前記コアネットワークに接続する際の接続遅延時間が、所定の時間よりも長くなることが許容されている場合、前記加入者データ保持部において前記移動局の加入者データを削除すると判定する、中継ノード装置。
2. コアネットワークに配置され、移動局に関するユーザデータを伝送する中継ノード装置であって、
   加入者情報管理装置から送信された移動局の加入者データを保持する加入者データ保持部と、
   前記移動局に関するユーザデータの伝送が行われていない場合に、ＩｏＴサービスポリシーに従い前記加入者データ保持部において前記移動局の加入者データを保持するか否かを判定する制御部と、を備え、
   前記制御部は、
   前記ＩｏＴサービスポリシーとして、前記移動局に対するＳＭＳ着信が許容されていない場合、前記加入者データ保持部において前記移動局の加入者データを削除すると判定する、中継ノード装置。
3. 前記制御部は、
   前記移動局のＡｔｔａｃｈ処理時、または、前記移動局が前記ユーザデータの伝送を行うために用いられるセッションを確立後に前記移動局に関するユーザデータの伝送が行われていないことを検出時に、前記加入者データ保持部において前記移動局の加入者データを保持するか否かを判定する、請求項１又は２に記載の中継ノード装置。
4. 前記制御部は、
   前記Ａｔｔａｃｈ処理時に前記加入者データ保持部において前記移動局の加入者データを保持しないと判定した後に、前記移動局からパケット通信の開始を要求するメッセージを受信した場合、前記加入者データ保持部において前記移動局の加入者データを保持すると判定する、請求項３に記載の中継ノード装置。
5. 前記移動局に関するセッション情報を保持するセッション情報保持部をさらに備え、
   前記制御部は、
   前記移動局に関するユーザデータの伝送が行われていない場合に、ＩｏＴサービスポリシーに従い前記セッション情報保持部において保持されている前記移動局のセッション情報を保持するか否かを判定する、請求項１乃至４のいずれか１項に記載の中継ノード装置。
6. 前記制御部は、
   前記加入者データ保持部において前記移動局の加入者データが保持されていない状態において、前記移動局に対してＳＭＳ着信が通知された場合、前記加入者情報管理装置から前記移動局の加入者データを取得する、請求項１乃至５のいずれか１項に記載の中継ノード装置。
7. コアネットワークに配置され、移動局に関するユーザデータを伝送する中継ノード装置における通信制御方法であって、
   加入者情報管理装置から送信された移動局の加入者データを保持し、
   前記移動局に関するユーザデータの伝送が行われていない場合に、ＩｏＴサービスポリシーに従い前記移動局の加入者データを保持するか否かを判定し、
   前記移動局の加入者データを保持するか否かの判定では、前記ＩｏＴサービスポリシーとして、前記移動局が通信を実行するために前記コアネットワークに接続する際の接続遅延時間が、所定の時間よりも長くなることが許容されている場合、前記移動局の加入者データを削除すると判定する、通信制御方法。
8. コアネットワークに配置され、移動局に関するユーザデータを伝送する中継ノード装置における通信制御方法であって、
   加入者情報管理装置から送信された移動局の加入者データを保持し、
   前記移動局に関するユーザデータの伝送が行われていない場合に、ＩｏＴサービスポリシーに従い前記移動局の加入者データを保持するか否かを判定し、
   前記移動局の加入者データを保持するか否かの判定では、前記ＩｏＴサービスポリシーとして、前記移動局に対するＳＭＳ着信が許容されていない場合、前記移動局の加入者データを削除すると判定する、通信制御方法。
9. コアネットワークに配置され、移動局に関するユーザデータを伝送する中継ノード装置であるコンピュータに実行させるプログラムであって、
   加入者情報管理装置から送信された移動局の加入者データを保持し、
   前記移動局に関するユーザデータの伝送が行われていない場合に、ＩｏＴサービスポリシーに従い前記移動局の加入者データを保持するか否かを判定し、
   前記移動局の加入者データを保持するか否かの判定では、前記ＩｏＴサービスポリシーとして、前記移動局が通信を実行するために前記コアネットワークに接続する際の接続遅延時間が、所定の時間よりも長くなることが許容されている場合、前記移動局の加入者データを削除すると判定することをコンピュータに実行させるプログラム。
10. コアネットワークに配置され、移動局に関するユーザデータを伝送する中継ノード装置であるコンピュータに実行させるプログラムであって、
    加入者情報管理装置から送信された移動局の加入者データを保持し、
    前記移動局に関するユーザデータの伝送が行われていない場合に、ＩｏＴサービスポリシーに従い前記移動局の加入者データを保持するか否かを判定し、
    前記移動局の加入者データを保持するか否かの判定では、前記ＩｏＴサービスポリシーとして、前記移動局に対するＳＭＳ着信が許容されていない場合、前記移動局の加入者データを削除すると判定することをコンピュータに実行させるプログラム。

Images