JP5776161B2 - 通信装置、通信制御方法及び通信システム - Google Patents

Description

本発明は、通信装置、通信制御方法及び通信システムに関する。

近年、人間が介在することなく通信ネットワークに接続する端末装置が自ら通信を行う、ＭＴＣ（Machine-Type Communication）通信又はＭ２Ｍ（Machine-to-Machine）通信と呼ばれる通信の一形態の利用が広まっている。例えば、家庭用ガスのメータをＭＴＣ端末とし、メータから定期的にガスの残量を事業者のサーバに送信することで、事業者は、検針員による検針作業を要することなく、各家庭でのガスの利用量を把握することができる。また、例えば、自動販売機からの在庫量の送信、コピー機からのトナー残量の送信、運輸業における輸送管理、及びセキュリティのための監視といった様々な用途に、ＭＴＣ通信は利用され得る。ＭＴＣ通信の利用は、今後も拡大していくことが予想されている。

ＭＴＣ通信の利用が広まるにつれて、通信ネットワークが収容すべき端末の数は格段に増加する。その結果、通信ネットワーク内でトラフィックの輻輳が発生し、通信障害又はＱｏＳの低下などといった問題が生じる可能性が高まる。

下記特許文献１は、移動体通信ネットワークにおける通信ノードの状態を監視し、輻輳又は異常が検知された場合に端末からの信号の転送経路を変化させる技術を提案している。

特開２００９−１３０６５７号公報

しかしながら、上記特許文献１に記載された技術は、輻輳が既に発生している場合にその輻輳による影響を低減するためのものであって、輻輳の発生自体を回避し得るものではない。

ここで、ＭＴＣ通信の上述した用途を考えると、ＭＴＣ通信は、特定の時間及び特定の地域においてデータ送信が集中するリスクを内包している。但し、ＭＴＣ通信の多くは計画的に行われることから、人間が利用する端末からの通信と異なり、ＭＴＣ通信におけるデータ送信の集中のリスクを予見することは十分に可能である。また、音声通話及びリアルタイムストリーミングなどのように低遅延が厳しく要求されるケースは、ＭＴＣ通信では比較的少ない。従って、ＭＴＣ通信の通信経路をある程度計画的かつ柔軟に制御することで、ＭＴＣ通信におけるトラフィックの輻輳を回避し又は緩和することが可能であるものと推測される。

そこで、本発明は、ＭＴＣ通信におけるトラフィックの輻輳を回避し又は緩和することのできる、新規かつ改良された通信装置、通信制御方法及び通信システムを提供しようとするものである。

本発明のある実施形態によれば、データパケットの宛て先ノードまでの経路上の上記宛て先ノードとは異なる中間ノードを指定する中間ノード指定情報を、上記データパケットの宛て先フィールドに挿入する通信制御部と、上記中間ノード指定情報が挿入された上記データパケットを送信する送信部と、を備える通信装置が提供される。

かかる通信装置は、ＭＴＣ端末、又はＭＴＣ端末から送信されるデータパケットを受信する通信ネットワーク内の基地局若しくはその他の通信ノードであってよい。かかる構成によれば、ＭＴＣ端末から送信されるデータパケットは、必ずしもデータパケットの宛て先ノードまでの最短経路に沿って伝送されず、上記中間ノードを経由する。

また、上記通信装置は、端末装置から送信され又は端末装置へ送信される上記データパケットを受信する受信部、をさらに備え、上記通信制御部は、上記端末装置がＭＴＣ端末である場合に、上記データパケットの宛て先フィールドに上記中間ノード指定情報を挿入してもよい。

また、上記通信制御部は、指定すべき中間ノードを特定するための中間ノードデータを用いて、複数の中間ノードの候補から上記データパケットのために指定すべき中間ノードを特定してもよい。

また、上記通信制御部は、上記データパケットの受信時に上記宛て先フィールドに記述されている情報を、他のフィールドに転記してもよい。

また、上記通信制御部は、上記宛て先フィールドが変更されたことを示すフラグを上記データパケットに付加してもよい。

また、上記通信制御部は、上記中間ノードにより上記データパケットの上記宛て先ノードを識別するために使用される制御情報を上記データパケットに挿入してもよい。

また、上記通信装置は、複数の中間ノードの候補のうちの１つであってもよい。

また、上記通信装置は、上記データパケットを生成するＭＴＣ端末であってもよい。

また、本発明の別の実施形態によれば、データパケットの宛て先ノードまでの経路上の上記宛て先ノードとは異なる中間ノードを指定する中間ノード指定情報を、上記データパケットの宛て先フィールドに挿入するステップと、上記中間ノード指定情報が挿入された上記データパケットを送信するステップと、を含む通信制御方法が提供される。

また、本発明の別の実施形態によれば、自装置が宛て先フィールドにおいて指定されている、端末装置から送信され又は端末装置へ送信されるデータパケットを受信する受信部と、上記データパケット内の上記宛て先フィールドとは異なるフィールドに含まれる情報から、上記データパケットの宛て先ノードを識別し、識別した当該宛て先ノードを指定する宛て先ノード指定情報を上記宛て先フィールドに挿入する通信制御部と、上記宛て先ノード指定情報が挿入された上記データパケットを送信する送信部と、を備える通信装置が提供される。

また、上記通信装置は、上記データパケット内の制御情報と上記データパケットの宛て先ノードとを対応付ける宛て先ノードデータを記憶する記憶部、をさらに備え、上記通信制御部は、上記宛て先ノードデータを用いて上記データパケットの上記宛て先ノードを識別してもよい。

また、上記制御情報は、上記端末装置の端末ＩＤ、クラス若しくはグループ、上記データパケットに関連するアプリケーションのアプリケーションＩＤ若しくはクラス、又は上記アプリケーションを提供する事業者を特定する情報を含んでもよい。

また、上記通信装置は、上記宛て先ノードデータを更新するための更新データを情報管理サーバから取得し、取得した上記更新データを用いて上記宛て先ノードデータを更新する情報管理部、をさらに備えてもよい。

また、上記通信制御部は、上記宛て先フィールドとは異なるフィールドに上記宛て先フィールドから転記された情報から、上記データパケットの上記宛て先ノードを識別してもよい。

また、本発明の別の実施形態によれば、複数の通信ノードを含む通信ネットワーク内の通信装置における通信制御方法であって、自装置が宛て先フィールドにおいて指定されている、端末装置から送信され又は端末装置へ送信されるデータパケットを受信するステップと、上記データパケット内の上記宛て先フィールドとは異なるフィールドに含まれる情報から、上記データパケットの宛て先ノードを識別するステップと、識別した上記宛て先ノードを指定する宛て先ノード指定情報を上記宛て先フィールドに挿入するステップと、上記宛て先ノード指定情報が挿入された上記データパケットを送信するステップと、を含む通信制御方法が提供される。

また、本発明の別の実施形態によれば、データパケットの宛て先ノードまでの経路上の上記宛て先ノードとは異なる中間ノードを指定する中間ノード指定情報を、上記データパケットの宛て先フィールドに挿入する通信制御部、及び上記中間ノード指定情報が挿入された上記データパケットを送信する送信部、を備える第１の通信装置と、自装置が宛て先フィールドにおいて指定されている、端末装置から送信され又は端末装置へ送信されるデータパケットを受信する受信部、上記データパケット内の上記宛て先フィールドとは異なるフィールドに含まれる情報から、上記データパケットの宛て先ノードを識別し、識別した当該宛て先ノードを指定する宛て先ノード指定情報を上記宛て先フィールドに挿入する通信制御部、及び上記宛て先ノード指定情報が挿入された上記データパケットを送信する送信部、を備える第２の通信装置と、を含み、上記第２の通信装置は、上記中間ノードの候補である、通信システムが提供される。

また、本発明の別の実施形態によれば、ＭＴＣ端末から送信され又はＭＴＣ端末へ送信されるデータパケット内の制御情報と上記データパケットの宛て先ノードとを対応付ける宛て先ノードデータを記憶する記憶部と、上記記憶部により記憶されている上記宛て先ノードデータの更新を管理する管理部と、上記データパケットの上記宛て先ノードまでの経路上の上記宛て先ノードとは異なる中間ノードに、上記宛て先ノードデータに関する更新データを送信する送信部と、を備える通信装置が提供される。

また、上記制御情報は、ＭＴＣ端末の端末ＩＤ、クラス若しくはグループ、上記データパケットに関連するアプリケーションのアプリケーションＩＤ若しくはクラス、又は上記アプリケーションを提供する事業者を特定する情報を含んでもよい。

以上説明したように、本発明に係る通信装置、通信制御方法及び通信システムによれば、ＭＴＣ通信におけるトラフィックの輻輳を回避し又は緩和することができる。

第１の実施形態に係る通信システムの概要を示す模式図である。 第１の実施形態に係る端末装置の構成の一例を示すブロック図である。 パケットフォーマットの一例について説明するための説明図である。 第１の実施形態に係るデータ送信処理の流れの一例を示すフローチャートである。 第１の実施形態に係る基地局の構成の一例を示すブロック図である。 第１の実施形態に係る制御情報挿入処理の流れの一例を示すフローチャートである。 第１の実施形態に係る転送ノードの構成の一例を示すブロック図である。 転送先データの第１の例について説明するための説明図である。 転送先データの第２の例について説明するための説明図である。 第１の実施形態に係るデータ転送処理の流れの一例を示すフローチャートである。 第２の実施形態に係る通信システムの概要を示す模式図である。 第２の実施形態に係る端末装置の構成の一例を示すブロック図である。 第２の実施形態に係るデータ送信処理の流れの一例を示すフローチャートである。 第２の実施形態に係る基地局の構成の一例を示すブロック図である。 中間ノードデータの第１の例について説明するための説明図である。 中間ノードデータの第２の例について説明するための説明図である。 第２の実施形態に係る宛て先フィールド更新処理の第１の例について説明するための説明図である。 第２の実施形態に係る宛て先フィールド更新処理の第２の例について説明するための説明図である。 第２の実施形態に係る宛て先フィールド更新処理の第３の例について説明するための説明図である。 第２の実施形態に係る宛て先フィールド更新処理の第４の例について説明するための説明図である。 第２の実施形態に係る宛て先フィールド更新処理の第５の例について説明するための説明図である。 第２の実施形態に係る基地局によるデータ転送処理の流れの一例を示すフローチャートである。 第２の実施形態に係る基地局によるデータ転送処理の流れの他の例を示すフローチャートである。 第２の実施形態に係る中間ノードの構成の一例を示すブロック図である。 宛て先ノードデータの一例について説明するための説明図である。 第２の実施形態に係る中間ノードによるデータ転送処理の流れの一例を示すフローチャートである。 第２の実施形態に係る中間ノードによるデータ転送処理の流れの他の例を示すフローチャートである。 第２の実施形態により実現され得る通信経路の例について説明するための説明図である。 第２の実施形態に係る情報管理サーバの構成の一例を示すブロック図である。 更新データの一例について説明するための説明図である。 第２の実施形態に係る更新データ配信処理の流れの第１の例を示すフローチャートである。 第２の実施形態に係る更新データ配信処理の流れの第２の例を示すフローチャートである。 第２の実施形態に係る宛て先ノードデータ更新処理の流れの一例を示すフローチャートである。

以下に添付図面を参照しながら、本発明の好適な実施の形態について詳細に説明する。なお、本明細書及び図面において、実質的に同一の機能構成を有する構成要素については、同一の符号を付すことにより重複説明を省略する。

また、以下の順序にしたがって当該「発明を実施するための形態」を説明する。
１．第１の実施形態の説明
１−１．システムの概要
１−２．端末装置
１−３．基地局
１−４．転送ノード
１−５．第１の実施形態のまとめ
１−６．応用例
２．第２の実施形態の説明
２−１．システムの概要
２−２．端末装置
２−３．基地局
２−４．中間ノード
２−５．通信経路の例
２−６．情報管理サーバ
２−７．ＤＲＸの管理
２−８．第２の実施形態のまとめ
２−９．応用例

＜１．第１の実施形態の説明＞
［１−１．システムの概要］
まず、図１〜図９を用いて、本発明の第１の実施形態を説明する。図１は、本発明の第１の実施形態に係る通信システム１の概要を示す模式図である。図１を参照すると、通信システム１は、複数の端末装置１００ａ〜１００ｅ、複数の基地局１２０ａ〜１２０ｄ、複数の通信装置１４０ａ〜１４０ｄ、及び複数のアプリケーションサーバ１９０ａ〜１９０ｃを含む。複数の通信装置１４０ａ〜１４０ｄは、通信システム１におけるコアネットワーク１０を形成する。基地局１２０ｄ、アプリケーションサーバ１９０ａ及び１９０ｂは、ネットワーク２０に接続される。

本明細書では、端末装置１００ａ〜１００ｅを互いに区別する必要がない場合には、これらを端末装置１００と総称する。基地局１２０（１２０ａ〜１２０ｄ）、通信装置１４０（１４０ａ〜１４０ｄ）、及びアプリケーションサーバ１９０（１９０ａ〜１９０ｃ）についても同様とする。

端末装置１００は、ＭＴＣ端末として動作する無線通信装置である。各端末装置１００は、自らが属するセルに無線通信サービスを提供している基地局１２０との間で、無線信号を送受信する。例えば、端末装置１００は、ガスの利用量又は自動販売器の在庫量などのアプリケーションデータを生成し、生成したアプリケーションデータを含むデータパケットを基地局１２０へ送信する。端末装置１００から基地局１２０へ送信されたデータパケットは、最終的には、いくつかの通信ノードを経由して、目的とするアプリケーションサーバ１９０へ届けられる。

基地局１２０は、例えばＬＴＥ（Long Term Evolution）又はＬＴＥ−Ａｄｖａｎｃｅｄなどに代表されるセルラー通信方式に従って、自装置の周囲に広がるセル内に無線通信サービスを提供する通信ノードである。基地局１２０は、例えば、端末装置１００により生成されるアプリケーションデータを含むデータパケットを受信し、受信したデータパケットをコアネットワーク１０の通信装置１４０へ転送する。また、基地局１２０は、コアネットワーク１０を経由して転送されてくる端末装置１００宛てのデータパケットを受信し、受信したデータパケットを宛て先の端末装置１００へ転送する。

図１の例において、基地局１２０ａ〜１２０ｃは、コアネットワーク１０に直接接続されるいわゆるマクロセルの基地局である。一方、基地局１２０ｄは、ネットワーク２０を介してコアネットワーク１０と接続されるフェムトセルの基地局（ＬＴＥではＨｅＮＢ（Home eNB）とも呼ばれる）である。これら基地局１２０は、端末装置１００のようなＭＴＣ端末のみならず、一般的なユーザ端末にも無線通信サービスを提供してよい。

通信装置１４０は、コアネットワーク１０を形成する通信ノードである。各通信装置１４０は、例えば、ＲＮＣ（Radio Network Controller）、ＭＭＥ（Mobility Management Entity）、ＨＳＳ（Home Subscriber Server）、ＳＧＳＮ（Serving GPRS Support Node）又はＧＧＳＮ（Gateway GPRS Support Node）などであってもよい。また、各通信装置１４０は、例えば、これら通信ノード間を接続するスイッチ又はルータなどのネットワーク装置であってもよい。通信装置１４０は、例えば、端末装置１００から送信され又は端末装置１００へ送信されるデータパケットを受信し、受信したデータパケットを宛て先のアプリケーションサーバ１９０へ届くように順次転送する。

図１に示した通信装置１４０のうち、例えば、通信装置１４０ｄは、いわゆるゲートウェイの役割を有するＧＧＳＮであり、コアネットワーク１０とネットワーク２０との境界に位置する。ネットワーク２０は、例えば、インターネットなどのＩＰ（Internet Protocol）ネットワークであってもよく、又はＡＴＭ（Asynchronous Transfer Mode）ネットワークなどの非ＩＰネットワークであってもよい。

アプリケーションサーバ１９０は、例えば、ガス料金の課金、又は自動販売機への商品の配送のプランニングなどのアプリケーション（ＡＰ）機能を有するサーバ装置である。ＭＴＣ端末から送信されるアプリケーションデータを利用するこのようなサーバ装置は、ＭＴＣサーバとも呼ばれる。アプリケーションサーバ１９０は、ネットワーク２０に接続されてもよく、又はコアネットワーク１０内に存在してもよい。図１の例では、アプリケーションサーバ１９０ａ及び１９０ｂはネットワーク２０に接続され、アプリケーションサーバ１９０ｃはコアネットワーク１０内に存在する。アプリケーションサーバ１９０ｃは、コアネットワーク１０を形成する通信ノードと物理的に同一の装置上に実装されてもよい。

アプリケーションサーバ１９０は、例えば、端末装置１００から送信されるデータパケットを最終的に受信する。そして、アプリケーションサーバ１９０は、受信したデータパケットに含まれるアプリケーションデータを取得して、上で例示したようなアプリケーション機能を実行する。また、アプリケーションサーバ１９０は、ＭＴＣ端末に関する設定の入力を受け付けるためのユーザインタフェースをユーザに提供してもよい。ＭＴＣ端末に関する設定とは、例えば、アプリケーションサーバ１９０と端末装置１００との間のＭＴＣ通信のスケジュールに関する設定を含み得る。

図１に例示した通信システム１において、多数のＭＴＣ端末が存在する場合には、ＭＴＣ端末から送信されるデータパケットが、宛て先のアプリケーションサーバ１９０までの通信経路上で輻輳を生じさせる可能性がある。特に、定期的なデータの収集を要するアプリケーションが導入されると、特定の時間又は特定の地域において端末装置１００から一斉にデータパケットが送信され得る。但し、ＭＴＣ通信の多くは計画的に行われるため、ＭＴＣ通信による輻輳が生じる前に、これを回避できる余地がある。また、ＭＴＣ通信の目的がデータ収集であるような場合には、データパケットは必ずしも最大のレートでアプリケーションサーバ１９０に届かなくてもよい。そこで、本実施形態では、次項より説明する各装置の構成を採用することにより、ＭＴＣ通信におけるトラフィックの輻輳の発生を回避し又は緩和する。

なお、本明細書において、「通信ノード」又は「通信装置」という用語は、特に符号が付されない場合において、図１に例示した端末装置１００、基地局１２０、通信装置１４０及びアプリケーションサーバ１９０のいずれをも表し得ることに留意されたい。

［１−２．端末装置］
（１）装置の構成例
図２は、本実施形態に係る端末装置１００の構成の一例を示すブロック図である。図２を参照すると、端末装置１００は、アプリケーション部１０２、記憶部１０４、通信制御部１１０、無線送信部１１２及び無線受信部１１４を備える。

アプリケーション部１０２は、アプリケーションサーバ１９０へ送信されるべきアプリケーションデータを生成し、生成したアプリケーションデータを通信制御部１１０へ出力する。アプリケーション部１０２により生成されるアプリケーションデータは、アプリケーションの目的に応じて、例えばガスの利用量、自動販売機の在庫量、コピー機のトナー残量、又は輸送管理のための位置データなど、任意の種類のデータを含み得る。アプリケーションデータの生成は、例えば、予め設定される時刻又は頻度で定期的に行われてもよい。その代わりに、アプリケーションデータの生成は、所定のイベント（例えば、一定量を超える在庫量の減少など）の発生をきっかけとして行われてもよい。

記憶部１０４は、ハードディスク又は半導体メモリなどの記憶媒体を用いて、アプリケーション部１０２及び通信制御部１１０による処理のためのプログラム及びデータを記憶する。また、記憶部１０４は、アプリケーション部１０２によるアプリケーションデータの生成の基礎となるデータを記憶する。また、記憶部１０４は、後に説明するデータパケットに挿入される制御情報の少なくとも一部を予め記憶する。

通信制御部１１０は、アプリケーションサーバ１９０へ送信されるべきアプリケーションデータがアプリケーション部１０２から入力されると、当該アプリケーションデータを含むデータパケットを生成する。そして、通信制御部１１０は、生成したデータパケットを無線送信部１１２から送信させる。また、通信制御部１１０は、無線受信部１１４によりデータパケットが受信されると、当該データパケットに含まれるアプリケーションデータを取得してアプリケーション部１０２へ出力する。

無線送信部１１２及び無線受信部１１４は、アンテナ及びＲＦ（Radio Frequency）回路を有する。無線送信部１１２は、通信制御部１１０により生成されるデータパケットをエアインタフェース上で無線信号として基地局１２０へ送信する。また、無線受信部１１４は、エアインタフェース上で無線信号として基地局１２０から送信されるデータパケットを受信し、受信したデータパケットを通信制御部１１０へ出力する。

（２）パケットフォーマットの例
図３は、本実施形態において端末装置１００が送信するデータパケットのパケットフォーマットの一例について説明するための説明図である。図３を参照すると、本実施形態に係るデータパケットは、ヘッダ領域ＨＳ及びデータ領域ＤＳを含む。図３に例示したように、ヘッダ領域ＨＳは、制御情報が格納される８つのフィールドＦ１〜Ｆ８を有する。データ領域ＤＳは、上述したアプリケーションデータを格納するための領域である。

ヘッダ領域ＨＳの宛て先フィールドＦ１には、データパケットの宛て先ノードを指定する情報が格納される。宛て先フィールドＦ１に格納される情報は、例えば、宛て先ノードのＩＰ（Internet Protocol）アドレス、ＭＡＣ（Media Access Control）アドレス、ホスト名又はその他の固有の識別子などであってよい。端末装置１００がアプリケーションデータを送信する場合には、対応するアプリケーション機能を提供するアプリケーションサーバ１９０が宛て先ノードとなる。また、端末装置１００がデータパケットを受信する場合には、当該端末装置１００が宛て先ノードとなる。

送信元フィールドＦ２には、データパケットの送信元ノードを指定する送信元ノード情報が格納される。端末装置１００がアプリケーションデータをアプリケーションサーバ１９０へ送信する場合には、当該アプリケーションデータを生成した端末装置１００が送信元ノードとなる。

アプリケーション（ＡＰ）クラスフィールドＦ３及びＡＰ ＩＤ（IDentifier）フィールドＦ４は、ＡＰクラス及びＡＰ ＩＤをそれぞれ格納するためのフィールドである。ＡＰクラス及びＡＰ ＩＤは、データパケットに関連するアプリケーションに関する制御情報である。ＡＰクラスは、アプリケーションをいくつかのクラスに分類した場合の、個々のアプリケーションが属するクラスを表す。例えば、サービス品質（ＱｏＳ）要件に応じて分類されるＱｏＳクラスがＡＰクラスとして利用されてもよい。ＡＰ ＩＤは、個々のアプリケーションを一意に識別するための識別子である。各端末装置１００がサポートするＡＰクラス及びＡＰ ＩＤの値は、記憶部１０４により予め記憶され得る。

端末クラスフィールドＦ５、端末グループ（Ｇｒｐ）フィールドＦ６及び端末ＩＤフィールドＦ７は、端末クラス、端末グループ及び端末ＩＤをそれぞれ格納するためのフィールドである。端末クラス、端末グループ及び端末ＩＤは、ＭＴＣ端末に関する制御情報である。端末クラス及び端末グループは、ＭＴＣ端末をいくつかのクラス及びグループに分類した場合の、個々の端末装置が属するクラス及びグループをそれぞれ表す。例えば、３ＧＰＰ（3rd Generation Partnership Project） ＴＳ（Technical Specification）２２．３６８によれば、ＭＴＣ端末は、そのサービス分野に応じて、セキュリティ機器、交通関連機器、支払機器、健康医療関連機器、遠隔操作機器、計測機器及びコンシューマ機器などに分類され得る。また、例えば、支払機器であれば自動販売機又はＰＯＳ（Point of sales）機器、計測機器であれば電力メータ又はガスメータなどのように、ＭＴＣ端末をその用途に応じてより詳細に分類することもできる。端末クラスとは、例えば、このようなサービス分野又は用途に応じたＭＴＣ端末の分類であってもよい。また、３ＧＰＰ ＴＳ２２．３６８は、例えばＱｏＳポリシー又は最大ビットレートなどの観点で定義される１つ以上のグループに各ＭＴＣ端末を割り当てることを提案している。端末グループとは、例えば、このようなグループベースのＭＴＣ端末の管理のために定義されるグループであってもよい。なお、当然ながら、他の考え方に従ったＭＴＣ端末の分類が利用されてもよい。端末ＩＤは、個々の端末装置を一意に識別するための識別子である。各端末装置１００の端末クラス、端末グループ及び端末ＩＤの値は、記憶部１０４により予め記憶され得る。

事業者ＩＤフィールドＦ８は、各端末装置１００が送信するデータパケットに関連するアプリケーションを提供する事業者を一意に特定する事業者ＩＤを格納するためのフィールドである。事業者ＩＤもまた、記憶部１０４により予め記憶され得る。

（３）データ送信処理の流れ
図４は、本実施形態に係る端末装置１００によるデータ送信処理の流れの一例を示すフローチャートである。

図４を参照すると、まず、端末装置１００のアプリケーション部１０２は、定期的に又は所定のイベントの発生に応じて、アプリケーションデータを生成する（ステップＳ１０２）。次に、通信制御部１１０は、生成されたアプリケーションデータについてのＡＰクラス及びＡＰ ＩＤなどのアプリケーションに関する制御情報を、記憶部１０４から取得する（ステップＳ１０４）。また、通信制御部１１０は、端末装置１００のＭＴＣ端末に関する端末クラス、端末グループ及び端末ＩＤなどの制御情報を、記憶部１０４から取得する（ステップＳ１０６）。次に、通信制御部１１０は、取得した制御情報とアプリケーションデータとを用いて、図３に例示したパケットフォーマットを有するデータパケットを生成する（ステップＳ１０８）。なお、ここで生成されるデータパケットの宛て先は、例えば、アプリケーションデータと関連付けてアプリケーション部１０２により指定され得る。そして、無線送信部１１２は、通信制御部１１０により生成されたデータパケットを基地局１２０へ送信する（ステップＳ１１０）。

なお、ここでは端末装置１００がデータパケットに制御情報を挿入する例について説明したが、その他の通信ノード（例えば、基地局１２０又は通信装置１４０など）が端末装置１００の代わりにデータパケットに制御情報を挿入してもよい。データパケットに制御情報を挿入する装置は、図１に例示していない装置（例えば、端末装置１００と基地局１２０との間に介在し得る中継局など）であってもよい。次項では、一例として、基地局１２０がデータパケットに制御情報の一部を挿入する例を説明する。

［１−３．基地局］
（１）装置の構成例
図５は、本実施形態に係る基地局１２０の構成の一例を示すブロック図である。図５を参照すると、基地局１２０は、無線受信部１２２、無線送信部１２４、送信部１２６、受信部１２８、記憶部１３０及び通信制御部１３２を備える。

無線受信部１２２及び無線送信部１２４は、複数の端末装置１００との間で無線通信を行うためのアンテナ及びＲＦ回路を有する。無線受信部１２２は、端末装置１００から送信されるデータパケットを受信し、受信したデータパケットを通信制御部１３２へ出力する。また、無線送信部１２４は、端末装置１００を宛て先とするデータパケットが通信制御部１３２から入力されると、当該データパケットを端末装置１００へ送信する。

送信部１２６及び受信部１２８は、基地局１２０がコアネットワーク１０の通信装置１４０との間で通信を行うための通信インタフェースである。送信部１２６は、通信制御部１３２からデータパケットが入力されると、当該データパケットをコアネットワーク１０へ送信する。受信部１２８は、コアネットワーク１０からデータパケットを受信すると、当該データパケットを通信制御部１３２へ出力する。

記憶部１３０は、記憶媒体を用いて、通信制御部１３２による処理のためのプログラム及びデータを記憶する。また、記憶部１３０は、図３に例示した制御情報の一部を、各端末装置１００の端末ＩＤ又はアドレス情報と関連付けて予め記憶してもよい。

通信制御部１３２は、例えば、ＬＴＥ又はＬＴＥ−Ａなどの標準仕様に従って、基地局１２０をセルラー通信のための基地局として動作させる。また、本実施形態において、通信制御部１３２は、端末装置１００の代わりに、端末装置１００から送信されるデータパケットに上述した制御情報を挿入し得る。例えば、通信制御部１３２は、端末装置１００からのデータパケットが無線受信部１２２から入力されると、当該データパケット内に記述された端末ＩＤ又は送信元アドレスと関連付けられている制御情報を記憶部１３０から取得する。そして、通信制御部１３２は、取得した制御情報をデータパケットに挿入する。

（２）制御情報挿入処理の流れ
図６は、本実施形態に係る基地局１２０による制御情報挿入処理の流れの一例を示すフローチャートである。

図６を参照すると、まず、基地局１２０の無線受信部１２２は、端末装置１００から送信されたデータパケットを受信する（ステップＳ１２２）。そして、無線受信部１２２は、受信したデータパケットを通信制御部１３２へ出力する。次に、通信制御部１３２は、受信したデータパケットがＭＴＣ通信のためのパケットであるか否かを判定する（ステップＳ１２４）。ＭＴＣ通信のためのパケットとは、送信元がＭＴＣ端末であるパケット、及び最終的な宛て先がＭＴＣ端末であるパケットの双方を含む。通信制御部１３２は、例えば、データパケットに含まれる端末グループ若しくは端末クラスを参照することにより、又はデータパケットに含まれる端末ＩＤを予め登録されるＩＤリストと照合することにより、データパケットがＭＴＣ通信のためのパケットであるか否かを判定することができる。その代わりに、通信制御部１３２は、例えば、データパケットに含まれるＡＰクラスを参照することにより、又はデータパケットに含まれるＡＰ ＩＤを予め登録されるＩＤリストと照合することにより、データパケットがＭＴＣ通信のためのパケットであるか否かを判定してもよい。ここで、データパケットがＭＴＣ通信のためのパケットであれば、続いてステップＳ１２６及びＳ１２８の処理が行われる。

送信元の装置がＭＴＣ端末である場合、通信制御部１３２は、データパケットにアプリケーションに関する制御情報（ＡＰクラス及びＡＰ ＩＤなど）を挿入する（ステップＳ１２６）。また、通信制御部１３２は、データパケットにＭＴＣ端末に関する制御情報（端末クラス又は端末グループなど）を挿入する（ステップＳ１２８）。

次に、通信制御部１３２は、データパケットを再生成する（ステップＳ１３０）。そして、再生成されたデータパケットは、送信部１２６からコアネットワーク１０へ転送される（ステップＳ１３２）。

なお、次に説明する通信装置１４０（転送ノード）によるデータ転送処理のために利用される全ての制御情報が端末装置１００によりデータパケットに挿入される場合には、図６に例示した基地局１２０による制御情報挿入処理は省略される。その場合、基地局１２０は、端末装置１００から送信されるデータパケットを、通常のユーザ端末から送信されるデータパケットと同様に、コアネットワーク１０へ転送する。

［１−４．転送ノード］
（１）装置の構成例
図７は、本実施形態に係る通信装置１４０の構成の一例を示すブロック図である。図７を参照すると、通信装置１４０は、受信部１４２、送信部１４４、記憶部１５０、及び通信制御部１５２を備える。

受信部１４２及び送信部１４４は、通信装置１４０が他の通信装置との間で通信を行うための通信インタフェースである。受信部１４２は、他の通信装置からデータパケットを受信すると、当該データパケットを通信制御部１５２へ出力する。送信部１４４は、通信制御部１５２からデータパケットが入力されると、当該データパケットを他の通信装置へ送信する。

記憶部１５０は、記憶媒体を用いて、通信制御部１５２による処理のためのプログラム及びデータを記憶する。また、記憶部１５０は、データパケット内の制御情報に基づく分類とデータパケットの転送先ノードとを対応付ける転送先データを記憶する。記憶部１５０により記憶される転送先データの例について、後に例を挙げて説明する。

通信制御部１５２は、受信部１４２により受信されたデータパケットの送信元の装置がＭＴＣ端末である場合に、トラフィックが分散されるように、複数の転送先ノードの候補からデータパケットの転送先ノードを選択する。より具体的には、本実施形態において、通信制御部１５２は、データパケット内の制御情報に基づいてデータパケットの転送先ノードを選択する。例えば、通信制御部１５２は、データパケット内の制御情報に応じてデータパケットを分類し、記憶部１５０により記憶されている転送先データにおいて当該データパケットの分類と対応付けられた転送先ノードを、当該データパケットの転送先ノードとして選択してもよい。その代わりに、通信制御部１５２は、例えば、同じ分類に属するデータパケットの転送先が複数の転送先ノードに分散されるように、各データパケットの転送先ノードを選択してもよい。通信制御部１５２による転送先ノードの選択は、典型的には、データパケットの宛て先ノードまでの経路に関するルーティングメトリックとは関係なく行われる。即ち、本実施形態に係る通信装置１４０は、必ずしも宛て先ノードまでのホップ数又は通信経路のコストなどのメトリックが最小となる転送先ノードを選択するわけではない。

図８Ａ及び図８Ｂは、それぞれ、通信装置１４０による転送先ノードの選択のために使用され得る転送先データの一例について説明するための説明図である。

図８Ａを参照すると、第１の例としての転送先データ１５１ａが示されている。転送先データ１５１ａは、「アプリケーションクラス」、「端末ＩＤ」及び「転送先ノード」という３つのデータ項目を有する。第１の例においては、通信制御部１５２は、データパケット内の制御情報に含まれるアプリケーションクラス及び端末ＩＤに応じて、データパケットを６つのカテゴリに分類する。例えば、アプリケーションクラスが「Ｃ１」である場合には、端末ＩＤの下位２ビットに応じて、データパケットは、第１から第４のいずれかのカテゴリに分類される。第１のカテゴリ（端末ＩＤの下位２ビット＝「００」）に分類されるデータパケットの転送先ノードは、ノードＮ１である。第２のカテゴリ（端末ＩＤの下位２ビット＝「０１」）に分類されるデータパケットの転送先ノードは、ノードＮ２である。第３のカテゴリ（端末ＩＤの下位２ビット＝「１０」）に分類されるデータパケットの転送先ノードは、ノードＮ３である。第４のカテゴリ（端末ＩＤの下位２ビット＝「１１」）に分類されるデータパケットの転送先ノードは、ノードＮ４である。また、アプリケーションクラスが「Ｃ２」である場合には、端末ＩＤによらず、データパケットは、第５のカテゴリに分類される。第５のカテゴリに分類されるデータパケットの転送先ノードは、ノードＮ５である。アプリケーションクラスが「Ｃ３」である場合には、端末ＩＤによらず、データパケットは、第６のカテゴリに分類される。第６のカテゴリに分類されるデータパケットの転送先ノードは、ノードＮ６である。

アプリケーションクラス「Ｃ１」は、例えば、ＱｏＳに関して低遅延が推奨される（例えば、許容される遅延の上限値が指定されている）クラスである。この場合には、第１の例のように端末ＩＤに応じてデータパケットの転送先を複数の転送先ノードに分散させて輻輳の発生を回避し、ＱｏＳ違反のリスクを低減することができる。なお、通信制御部１５２は、端末ＩＤを用いることなく、例えばラウンドロビン方式又はランダム方式で、アプリケーションクラス「Ｃ１」のデータパケットの転送先を４つの転送先ノードＮ１〜Ｎ４の間で分散させてもよい。

また、第１の例では、異なるアプリケーションクラスのデータパケットが異なる転送先ノードへ転送される。例えば、ノードＮ５及びノードＮ６は、ノードＮ１〜Ｎ４と比較してスループットが高くないノード又は低速なリンクを有するノードであってもよい。このようにアプリケーションごとに異なる転送先ノードを選択することで、トラフィックの輻輳が生じる可能性はさらに低減され得る。

図８Ｂを参照すると、第２の例としての転送先データ１５１ｂが示されている。転送先データ１５１ｂは、「端末クラス」及び「転送先ノード」という２つのデータ項目を有する。第２の例においては、通信制御部１５２は、データパケット内の制御情報に含まれる端末クラスに応じて、データパケットを４つのカテゴリに分類する。例えば、端末クラスが「Ｔ１」である場合には、データパケットは第１のカテゴリに分類され、転送先ノードとしてノードＮ１が選択される。端末クラスが「Ｔ２」である場合には、データパケットは第２のカテゴリに分類され、転送先ノードとしてノードＮ２が選択される。端末クラスが「Ｔ３」である場合には、データパケットは第３のカテゴリに分類され、転送先ノードとしてノードＮ３が選択される。端末クラスが「Ｔ４」である場合には、データパケットは第４のカテゴリに分類され、転送先ノードとしてノードＮ４が選択される。

第２の例では、異なる端末クラスのデータパケットが異なる転送先ノードへ転送されるため、端末クラス間でデータパケットの転送先が分散される。そのため、データパケットの輻輳の可能性が低減される。なお、通信制御部１５２は、例えば、同じ端末クラスの端末装置１００からのデータパケットの転送先を、４つの転送先ノードＮ１〜Ｎ４の間でラウンドロビン方式又はランダム方式で分散させてもよい。また、端末クラスの代わりに端末グループが使用されてもよい。

なお、コアネットワーク１０内に存在する全ての通信装置１４０がここで説明した転送先ノードとしての機能を有しなくてもよい。また、転送先ノードデータの内容は、転送先ノードとして機能する通信装置１４０ごとに異なってもよい。即ち、第１の転送先ノードが図８Ａに例示した転送先データを有し、一方で第２の転送先ノードが図８Ｂに例示した転送先データを有してもよい。転送先ノードデータは、各転送先ノードにおいて個別に登録及び更新されてもよく、又は第２の実施形態において説明するような情報管理サーバにおいて一括的に管理され、動的に更新されてもよい。

（２）データ転送処理の流れ
図９は、本実施形態に係る通信装置１４０によるデータ転送処理の流れの一例を示すフローチャートである。

図９を参照すると、まず、通信装置１４０の受信部１４２は、端末装置１００から送信されたデータパケットを受信する（ステップＳ１４２）。そして、受信部１４２は、受信したデータパケットを通信制御部１５２へ出力する。次に、通信制御部１５２は、受信したデータパケットがＭＴＣ通信のためのパケットであるか否かを判定する（ステップＳ１４４）。ここで、データパケットがＭＴＣ通信のためのパケットであれば、処理はステップＳ１４６へ進む。一方、データパケットがＭＴＣ通信のためのパケットでなければ、処理はステップＳ１５４へ進む。

ステップＳ１４６では、通信制御部１５２は、データパケットのヘッダ領域に含まれる制御情報を取得する（ステップＳ１４６）。次に、通信制御部１５２は、取得した制御情報に応じてデータパケットを複数のカテゴリのいずれかに分類する（ステップＳ１４８）。次に、通信制御部１５２は、データパケットが属するカテゴリに対応する転送先ノードが記憶部１５０に記憶されている転送先ノードデータに存在するか否かを判定する（ステップＳ１５０）。ここで、対応する転送先ノードが転送先ノードデータに存在する場合には、処理はステップＳ１５２へ進む。一方、対応する転送先ノードが転送先ノードデータに存在しない場合には、処理はステップＳ１５４へ進む。

ステップＳ１５２では、通信制御部１５２は、転送先ノードデータにおいてデータパケットが属するカテゴリに対応付けられている転送先ノードを、データパケットの転送先ノードとして選択する（ステップＳ１５２）。一方、ステップＳ１５４では、通信制御部１５２は、既定の転送先ノードを、データパケットの転送先ノードとして選択する（ステップＳ１５４）。ここで、既定の転送先ノードとは、例えば、予め固定的に定義される転送先ノードであってもよく、又はルーティングメトリックに応じて動的に選択される転送先ノードであってもよい。

そして、送信部１４４は、通信制御部１５２により選択された転送先ノードへデータパケットを転送する（ステップＳ１５６）。

［１−５．第１の実施形態のまとめ］
ここまで、図１〜図９を用いて、本発明の第１の実施形態について説明した。本実施形態によれば、ＭＴＣ端末からデータパケットが送信された場合に、通信ネットワーク内の転送ノードによって、複数の転送先ノードの候補から転送先ノードが選択され、選択された転送先ノードへ当該データパケットが転送される。それにより、ＭＴＣ通信のトラフィックを複数の経路に分散させ、輻輳を回避し又は緩和することができる。また、結果として、通信システムに収容可能なＭＴＣ端末の数を増加させることができる。

また、本実施形態によれば、転送ノードは、データパケット内の制御情報に基づいて転送先ノードを選択する。かかる制御情報は、ＭＴＣ通信に関連するアプリケーション又はＭＴＣ端末の種類の観点でデータパケットを分類するために用いられ得る。かかる構成によれば、アプリケーションの種類又は端末の種類などに応じて計画的にデータパケットを分散させることができる。例えば、一斉にデータを送信する可能性のある同種のアプリケーションの又は同種の端末からのデータパケットの転送先を、複数の転送先ノードの間で分散させることも可能である。従って、ＭＴＣ通信による輻輳の発生を未然に回避し、又は輻輳を効果的に緩和することができる。

また、標準的にデータパケット内に包含される情報を制御情報として利用することで、ＭＴＣ端末又は基地局などの既存の装置に処理ロジックの改変などのインパクトを与えることなく、上述した輻輳回避のためのメカニズムを導入することができる。

また、本実施形態によれば、転送ノードにおける転送先ノードの選択は、宛て先ノードまでの経路に関するルーティングメトリックとは関係なく行われ得る。これは、通常の（人間が利用する）ユーザ端末による通信と比較して必ずしも最大のレートでデータが宛て先に届かなくてもよいケースの多いＭＴＣ通信の特性に着目した考え方である。従って、ＭＴＣ通信のデータパケットは、ルーティングメトリックの観点でいわゆる「最適な」通信経路に集中することがない。その結果、例えば優先度の高い音声通話又はリアルタイムストリーミングなどの非ＭＴＣ通信を、ＭＴＣ通信が阻害するリスクが低減される。

［１−６．応用例］
第１の実施形態では、主にＭＴＣ端末から送信されるデータパケットの転送先を複数の転送先ノードの候補の間で分散させる例について説明した。しかしながら、上述した転送先ノードの選択の仕組みは、ＭＴＣ端末へ送信されるデータパケットにも同様に適用可能である。例えば、図１に示した通信装置１４０は、端末装置１００へ送信されるデータパケットについての複数の転送先ノードの候補を記述する追加的な転送先データを有し、データパケット内の制御情報とその追加的な転送先データとに基づいて、トラフィックが分散されるように、端末装置１００へ送信されるデータパケットの転送先ノードを複数の転送先ノードの候補から選択してもよい。

＜２．第２の実施形態の説明＞
次に、図１０〜図２４を用いて、本発明の第２の実施形態を説明する。第１の実施形態では、転送ノードがＭＴＣ通信のトラフィックを分散させることで、特定の通信経路へのトラフィックの集中が未然に防がれる。本節で説明する第２の実施形態では、ＭＴＣ通信のトラフィックを後述する中間ノードを経由する経路に導くことで、やはり特定の通信経路へのトラフィックの集中を防止する。

［２−１．システムの概要］
図１０は、本発明の第２の実施形態に係る通信システム２の概要を示す模式図である。図１０を参照すると、通信システム２は、複数の端末装置２００ａ〜２００ｄ、複数の基地局２２０ａ〜２２０ｃ、コアネットワーク１０内の通信装置１４０、２４０ａ及び２４０ｂ、情報管理サーバ２７０、並びに複数のアプリケーションサーバ１９０ａ〜１９０ｃを含む。

端末装置２００は、第１の実施形態に係る端末装置１００と同様、ＭＴＣ端末として動作する無線通信装置である。各端末装置２００は、自らが属するセルに無線通信サービスを提供している基地局２２０との間で、無線信号を送受信する。端末装置２００は、例えば、アプリケーションデータを生成し、生成したアプリケーションデータを含むデータパケットを基地局２２０へ送信する。端末装置２００から基地局２２０へ送信されたデータパケットは、最終的には、いくつかの通信ノードを経由して、目的とするアプリケーションサーバ１９０へ届けられる。但し、本実施形態では、端末装置２００は、最終的な宛て先である宛て先ノードとは異なる通信ノードを指定する情報を、データパケットの宛て先フィールドにおいて指定し得る。本明細書では、このように、ＭＴＣ端末から送信されるデータパケットの（最終的な宛て先ではなく）一時的な宛て先として指定される通信ノードを、中間ノードという。

基地局２２０は、第１の実施形態に係る基地局１２０と同様、例えばＬＴＥ又はＬＴＥ−Ａｄｖａｎｃｅｄなどに代表されるセルラー通信方式に従って、自装置の周囲に広がるセル内に無線通信サービスを提供する通信ノードである。基地局２２０は、例えば、端末装置２００により生成されるアプリケーションデータを含むデータパケットを受信し、受信したデータパケットをコアネットワーク１０の通信ノードへ転送する。但し、本実施形態では、基地局２２０は、転送するデータパケットの宛て先フィールドに中間ノードを指定する情報を挿入し得る。また、基地局２２０は、コアネットワーク１０を経由して転送されてくる端末装置２００宛てのデータパケットを受信し、受信したデータパケットを宛て先の端末装置２００へ転送する。

通信装置２４０は、中間ノードとして指定される可能性のある通信ノードである。各通信装置２４０は、例えば、ＲＮＣ、ＭＭＥ、ＨＳＳ、ＳＧＳＮ若しくはＧＧＳＮなどであってもよく、又はこれら通信ノード間を接続するスイッチ若しくはルータなどであってもよい。通信装置２４０は、例えば、自装置が宛て先フィールドにおいて指定されているデータパケットを受信し、データパケット内の制御情報を用いて適切な宛て先ノードを識別し、識別した宛て先ノードに向けてデータパケットを転送する。

情報管理サーバ２７０は、中間ノードが宛て先ノードを識別する際に使用する宛て先ノードデータのマスタを管理する通信装置である。図１０の例では、情報管理サーバ２７０は、ネットワーク２０に接続されている。しかしながら、かかる例に限定されず、情報管理サーバ２７０は、例えば、コアネットワーク１０内に存在してもよい。また、情報管理サーバ２７０は、コアネットワーク１０を形成する通信ノードと物理的に同一の装置上に実装されてもよい。情報管理サーバ２７０は、宛て先ノードデータのマスタに加えて、第１の実施形態で説明した転送先データのマスタを管理してもよい。

［２−２．端末装置］
（１）装置の構成例
図１１は、本実施形態に係る端末装置２００の構成の一例を示すブロック図である。図１１を参照すると、端末装置２００は、アプリケーション部１０２、記憶部２０４、通信制御部２１０、無線送信部１１２及び無線受信部１１４を備える。

記憶部２０４は、記憶媒体を用いて、アプリケーション部１０２及び通信制御部２１０による処理のためのプログラム及びデータを記憶する。また、記憶部２０４は、第１の実施形態に係る端末装置１００の記憶部１０４と同様、アプリケーション部１０２によるアプリケーションデータの生成の基礎となるデータを記憶する。また、記憶部２０４は、データパケットに挿入される制御情報を予め記憶する。さらに本実施形態において、記憶部２０４は、データパケットの最終的な宛て先ノードまでの経路上の宛て先ノードとは異なる中間ノードを指定する中間ノード指定情報を、例えばアプリケーションと関連付けて予め記憶する。中間ノード指定情報とは、例えば、中間ノードのＩＰアドレス、ＭＡＣアドレス、ホスト名又はその他の固有の識別子などであってよい。

通信制御部２１０は、アプリケーションサーバ１９０へ送信されるべきアプリケーションデータがアプリケーション部１０２から入力されると、当該アプリケーションデータを含むデータパケットを生成する。このとき、通信制御部２１０は、データパケットの宛て先フィールドに、記憶部２０４においてアプリケーションと関連付けて記憶されている中間ノード指定情報を挿入し得る。そして、通信制御部２１０は、生成したデータパケットを無線送信部１１２から送信させる。また、通信制御部２１０は、無線受信部１１４によりデータパケットが受信されると、当該データパケットに含まれるアプリケーションデータを取得してアプリケーション部１０２へ出力する。

（２）データ送信処理の流れ
図１２は、本実施形態に係る端末装置２００によるデータ送信処理の流れの一例を示すフローチャートである。

図１２を参照すると、まず、端末装置２００のアプリケーション部１０２は、定期的に又は所定のイベントの発生に応じて、アプリケーションデータを生成する（ステップＳ２０２）。次に、通信制御部２１０は、生成されたアプリケーションデータについてのＡＰクラス及びＡＰ ＩＤなどのアプリケーションに関する制御情報を、記憶部２０４から取得する（ステップＳ２０４）。また、通信制御部２１０は、端末装置２００のＭＴＣ端末に関する端末クラス、端末グループ及び端末ＩＤなどの制御情報を、記憶部２０４から取得する（ステップＳ２０６）。次に、通信制御部２１０は、データパケットの宛て先フィールドに挿入すべき中間ノード指定情報を、記憶部２０４から取得する（ステップＳ２０８）。次に、通信制御部２１０は、取得した中間ノード指定情報及び制御情報をヘッダ領域に、アプリケーションデータをデータ領域にそれぞれ含むデータパケットを生成する（ステップＳ２１０）。そして、無線送信部１１２は、通信制御部２１０により生成されたデータパケットを基地局２２０へ送信する（ステップＳ２１２）。

なお、ここでは端末装置２００がデータパケットに制御情報を挿入する例について説明したが、その他の通信ノード（例えば、基地局２２０又は通信装置２４０など）が端末装置２００の代わりにデータパケットに制御情報を挿入してもよい。また、次に説明するように、端末装置２００の代わりに、その他の通信ノードが中間ノード指定情報を宛て先フィールドに挿入してもよい。中間ノード指定情報を宛て先フィールドに挿入する装置は、図１０に例示していない装置（例えば、端末装置２００と基地局２２０との間に介在し得る中継局など）であってもよい。次項では、一例として、基地局２２０が中間ノード指定情報を宛て先フィールドに挿入する例を説明する。なお、次項の例において、端末装置２００は、一般的なデータ送信処理と同様、最終的な宛て先ノードを指定する宛て先ノード指定情報を宛て先フィールドに挿入し得る。

［２−３．基地局］
（１）装置の構成例
図１３は、本実施形態に係る基地局２２０の構成の一例を示すブロック図である。図１３を参照すると、基地局２２０は、無線受信部１２２、無線送信部１２４、送信部１２６、受信部１２８、記憶部２３０及び通信制御部２３２を備える。

記憶部２３０は、記憶媒体を用いて、通信制御部２３２による処理のためのプログラム及びデータを記憶する。また、記憶部２３０は、図３に例示した制御情報の少なくとも一部を、各端末装置２００の端末ＩＤ又はアドレス情報と関連付けて予め記憶する。また、本実施形態において、記憶部２３０は、データパケットのために指定すべき中間ノードの候補をリスト化した中間ノードデータを予め記憶する。

図１４Ａ及び図１４Ｂは、それぞれ、中間ノードデータの一例について説明するための説明図である。図１４Ａを参照すると、第１の例としての中間ノードデータ２３１ａが示されている。中間ノードデータ２３１ａは、「アプリケーションクラス」及び「中間ノード」という２つのデータ項目を有する。この場合、中間ノードデータ２３１ａは、データパケットのアプリケーションクラスごとに、指定すべき中間ノードを定義するデータである。一方、図１４Ｂを参照すると、第２の例としての中間ノードデータ２３１ｂが示されている。中間ノードデータ２３１ｂは、「端末クラス」及び「中間ノード」という２つのデータ項目を有する。この場合、中間ノードデータ２３１ｂは、データパケットの端末クラスごとに、指定すべき中間ノードを定義するデータである。なお、これらの例に限定されず、中間ノードデータは、図３に例示したような任意の制御情報と関連付けて中間ノードを定義するデータであってよい。

通信制御部２３２は、例えば、ＬＴＥ又はＬＴＥ−Ａなどの標準仕様に従って、基地局２２０をセルラー通信のための基地局として動作させる。また、本実施形態において、通信制御部２３２は、無線受信部１２２により受信されるデータパケットの宛て先フィールドに、当該データパケットの最終的な宛て先ノードとは異なる中間ノードを指定する中間ノード指定情報を挿入し得る。例えば、通信制御部２３２は、端末装置２００からのデータパケットが無線受信部１２２から入力されると、当該データパケット内に記述されたアプリケーションクラス又は端末クラスと関連付けられている中間ノードを、記憶部２３０により記憶されている上述した中間ノードデータを用いて特定する。そして、通信制御部２３２は、特定した中間ノードを指定する中間ノード指定情報を、データパケットの宛て先フィールドに挿入する。ここでの宛て先フィールドの更新処理の複数のパターンについて、後に例を挙げて詳細に説明する。なお、通信制御部２３２は、複数の中間ノードの候補から、例えばラウンドロビン方式又はランダム方式で、データパケットごとに異なる中間ノードを指定してもよい。

また、通信制御部２３２は、中間ノードによりデータパケットの最終的な宛て先ノードを識別するために使用される制御情報を、端末装置２００の代わりに、端末装置２００から送信されるデータパケットに挿入してもよい。最終的な宛て先ノードを識別するために使用される制御情報とは、例えば、図３を用いて説明した制御情報のうちの少なくとも１つを含み得る。

（２）宛て先フィールド更新処理の例
図１５Ａ〜図１５Ｅは、それぞれ、本実施形態に係る通信制御部２３２による宛て先フィールド更新処理の一例について説明するための説明図である。各図には、通信制御部２３２による更新の前後の宛て先フィールドの内容が示されている。

図１５Ａに示した第１の例において、通信制御部２３２は、データパケットの宛て先フィールドＦ１に挿入されている宛て先ノードに関する情報を、単純に中間ノード指定情報（例えば、中間ノードのＩＰアドレス又はホスト名など）で上書きする。この場合、宛て先フィールド更新処理は、最も簡易に実現され得る。

図１５Ｂに示した第２の例において、通信制御部２３２は、データパケットの宛て先フィールドＦ１に挿入されている宛て先ノードに関する情報を中間ノード指定情報で上書きする（Ｆ１ｂ）と共に、宛て先フィールドＦ１が変更されたことを示すフラグをデータパケットに付加する（Ｆ１ａ）。この場合、更新後のデータパケットを受信する中間ノードは、フラグを参照することにより、宛て先フィールドＦ１が変更されているか否かを知ることができる。なお、データパケット内でのフラグの位置は、図１５Ｂに例示した位置とは異なる位置であってもよい。

図１５Ｃに示した第３の例においては、宛て先フィールドＦ１が、フラグ用のサブフィールドＦ１ａ及びノード情報用のサブフィールドＦ１ｂに予め分割されている。この場合、例えば、端末装置２００は、サブフィールドＦ１ａのフラグをゼロに設定すると共に、サブフィールドＦ１ｂに宛て先ノードに関する情報を挿入したデータパケットを送信する。そして、基地局２２０の通信制御部２３２は、サブフィールドＦ１ａのフラグを１に更新すると共に、サブフィールドＦ１ｂを中間ノード指定情報で上書きする。この場合、データパケットを受信する全ての通信ノードは、フラグ用のサブフィールドＦ１ａを参照することにより、宛て先フィールドＦ１が変更されているか否かを知ることができる。

図１５Ｄに示した第４の例において、通信制御部２３２は、フラグを１に更新し、宛て先フィールドＦ１に中間ノード指定情報を挿入すると共に、データパケットの受信時に宛て先フィールドＦ１に記述されている情報を予備フィールドＦ９に転記する。この場合、更新後のデータパケットを受信する中間ノードは、予備フィールドＦ９に転記された宛て先ノードに関する情報を参照することにより、最終的な宛て先ノードを識別することができる。

図１５Ｅに示した第５の例は、１つのデータパケットの転送に際して複数の中間ノードが順に指定される場合に採用され得る、宛て先フィールド更新処理の例を示している。この場合、まず、基地局２２０の通信制御部２３２は、宛て先フィールドＦ１に中間ノード指定情報を挿入すると共に、最終的な宛て先ノード（宛て先ノード１）を指定する情報を予備フィールドＦ９に転記する。次に、データパケットを受信した中間ノードは、宛て先フィールドＦ１に新たな中間ノード指定情報を挿入すると共に、宛て先フィールドＦ１に記載された元の中間ノード指定情報を、さらに予備フィールドＦ９に転記する。このとき、更新の有無を示す２値のフラグの代わりに、更新の回数を示す情報をデータパケットに付加する（更新回数をインクリメントする）ことが望ましい。それにより、更新後のデータパケットを受信する中間ノードは、予備フィールドＦ９に転記されたノード情報の個数を容易に知ることができる。第５の例においては、予備フィールドＦ９が中間ノードの指定の履歴を表すため、１つの中間ノードが複数回指定されることによりループ状の通信経路が形成されることを防止することができる。

（３）データ転送処理の流れ
図１６Ａ及び図１６Ｂは、それぞれ、本実施形態に係る基地局２２０によるデータ転送処理の流れの一例を示すフローチャートである。

図１６Ａは、図１５Ａ〜図１５Ｃに例示した宛て先フィールド更新処理を含む流れの一例を示している。図１６Ａの例において、まず、基地局２２０の無線受信部１２２は、端末装置２００から送信されたデータパケットを受信する（ステップＳ２２２）。そして、無線受信部１２２は、受信したデータパケットを通信制御部２３２へ出力する。次に、通信制御部２３２は、受信したデータパケットがＭＴＣ通信のためのパケットであるか否かを判定する（ステップＳ２２４）。ここで、データパケットがＭＴＣ通信のためのパケットであれば、続いてステップＳ２２６〜Ｓ２３２の処理が行われる。

送信元の装置がＭＴＣ端末である場合、通信制御部２３２は、データパケットの宛て先フィールドにおいて指定すべき中間ノードを、中間ノードデータを用いて特定する（ステップＳ２２６）。次に、通信制御部２３２は、特定した中間ノードを指定する中間ノード指定情報を、データパケットの宛て先フィールドに挿入する（ステップＳ２３０）。次に、通信制御部２３２は、宛て先フィールドが変更されたことを示すフラグ（例えば、フラグ＝１）をデータパケットに設定する（ステップＳ２３２）

そして、データパケットは、送信部１２６からコアネットワーク１０へ転送される（ステップＳ２３４）。

図１６Ｂは、図１５Ｄ及び図１５Ｅに例示した宛て先フィールド更新処理を含む流れの一例を示している。図１６Ｂの例において、まず、基地局２２０の無線受信部１２２は、端末装置２００から送信されたデータパケットを受信する（ステップＳ２２２）。そして、無線受信部１２２は、受信したデータパケットを通信制御部２３２へ出力する。次に、通信制御部２３２は、受信したデータパケットがＭＴＣ通信のためのパケットであるか否かを判定する（ステップＳ２２４）。ここで、データパケットがＭＴＣ通信のためのパケットであれば、続いてステップＳ２２６〜Ｓ２３３の処理が行われる。

送信元の装置がＭＴＣ端末である場合、通信制御部２３２は、データパケットの宛て先フィールドにおいて指定すべき中間ノードを、中間ノードデータを用いて特定する（ステップＳ２２６）。次に、通信制御部２３２は、データパケットの受信時に宛て先フィールドに記述されている宛て先ノードに関する情報を予備フィールドなどの他のフィールドに転記する（ステップＳ２２８）。次に、通信制御部２３２は、特定した中間ノードを指定する中間ノード指定情報を、データパケットの宛て先フィールドに挿入する（ステップＳ２３０）。次に、通信制御部２３２は、フラグを更新する（ステップＳ２３３）

そして、データパケットは、送信部１２６からコアネットワーク１０へ転送される（ステップＳ２３４）。

［２−４．中間ノード］
（１）装置の構成例
図１７は、中間ノードとして動作する通信装置２４０の構成の一例を示すブロック図である。図１７を参照すると、通信装置２４０は、受信部１４２、送信部１４４、記憶部２５０、通信制御部２５２及び情報管理部２５４を備える。

記憶部２５０は、記憶媒体を用いて、通信制御部２５２及び情報管理部２５４による処理のためのプログラム及びデータを記憶する。また、本実施形態において、記憶部２５０は、データパケット内の制御情報とデータパケットの宛て先ノードとを対応付ける、後述する宛て先ノードデータを記憶してもよい。また、記憶部２５０は、第１の実施形態に係る通信装置１４０の記憶部１５０と同様、データパケット内の制御情報とデータパケットの転送先ノードとを対応付ける転送先データを記憶してもよい。

通信制御部２５２は、自装置が宛て先フィールドにおいて指定されているデータパケットを受信部１４２が受信すると、宛て先フィールドとは異なるフィールドに含まれる情報から、当該データパケットの最終的な宛て先ノードを識別する。より具体的には、通信制御部２５２は、例えば、データパケット内の制御情報とデータパケットの宛て先ノードとを対応付ける宛て先ノードデータを用いて、データパケットごとに最終的な宛て先ノードを識別することができる。

図１８は、記憶部２５０により記憶され得る宛て先ノードデータの一例について説明するための説明図である。図１８を参照すると、一例としての宛て先ノードデータ２５１は、「アプリケーションクラス」、「端末クラス」、「事業者」及び「宛て先ノード」という４つのデータ項目を有する。このうち、「アプリケーションクラス」、「端末クラス」及び「事業者」の組合せが、いずれかの宛て先ノードを識別するための識別キーとなる。例えば、アプリケーションクラスが「Ｃ１」、端末クラスが「Ｔ３」、事業者が「Ｊ０１」であるデータパケットは、宛て先ノードＤ１に対応する。アプリケーションクラスが「Ｃ１」、端末クラスが「Ｔ３」、事業者が「Ｊ０２」であるデータパケットは、宛て先ノードＤ２に対応する（残りのレコードについての説明は省略する）。なお、宛て先ノードを識別するための識別キーとして用いられ得る制御情報は、かかる例に限定されない。例えば、図３に例示した制御情報（又は他の制御情報）のうち任意の項目が、宛て先ノードを識別するための識別キーとして用いられてよい。本実施形態において、このような宛て先ノードデータは、図１０に例示した情報管理サーバ２７０において管理され、中間ノード間で共有され得る。

通信制御部２５２は、このような宛て先ノードデータを用いて、データパケット内の制御情報と対応する宛て先ノードを最終的な宛て先ノードとして識別することができる。なお、中間ノードを指定した装置（例えば、上述した基地局２２０）により予備フィールドに宛て先ノードに関する情報が転記されている場合には、通信制御部２５２は、宛て先ノードデータを用いることなく、最終的な宛て先ノードを識別することができる。その場合、記憶部２５０は、図１８に例示した宛て先ノードデータを記憶しなくてもよい。

通信制御部２５２は、上述したように識別した宛て先ノードを指定する宛て先ノード指定情報を、データパケットの宛て先フィールドに挿入する。即ち、通信制御部２５２は、一時的に指定された宛て先フィールドの情報を、最終的にデータパケットが到達すべき宛て先ノードの情報に修正する。そして、通信制御部２５２は、最終的な宛て先ノード指定情報を宛て先フィールドに含むデータパケットを、送信部１４４により送信させる。

なお、通信制御部２５２は、第１の実施形態に係る転送ノードと同様、トラフィックが分散されるように、複数の転送先ノードの候補からデータパケットの転送先ノード（次のホップ）を選択してもよい。また、通信制御部２５２は、最終的な宛て先ノードの代わりに、別の中間ノードを指定する中間ノード指定情報を宛て先フィールドに挿入して、当該別の中間ノードへデータパケットをさらに転送してもよい。

情報管理部２５４は、記憶部２５０により記憶されている宛て先ノードデータを更新するための更新データを情報管理サーバ２７０から取得し、取得した更新データを用いて宛て先ノードデータを更新する。情報管理部２５４は、更新データの配信を一定の頻度で定期的に情報管理サーバ２７０に要求してもよい。その代わりに、情報管理部２５４は、情報管理サーバ２７０から更新データが受信された場合に、受動的に宛て先ノードデータを更新してもよい。

（２）データ転送処理の流れ
図１９Ａ及び図１９Ｂは、それぞれ、本実施形態に係る通信装置２４０によるデータ転送処理の流れの一例を示すフローチャートである。

図１９Ａは、宛て先ノードデータを用いた宛て先ノードの識別処理を含む流れの一例を示している。図１９Ａの例において、まず、通信装置２４０の受信部１４２は、端末装置２００から送信されたデータパケットを受信する（ステップＳ２４２）。そして、受信部１４２は、受信したデータパケットを通信制御部２５２へ出力する。次に、通信制御部２５２は、受信したデータパケットがＭＴＣ通信のためのパケットであるか否かを判定する（ステップＳ２４４）。ここで、データパケットがＭＴＣ通信のためのパケットであれば、処理はステップＳ２４６へ進む。一方、データパケットがＭＴＣ通信のためのパケットでなければ、処理はステップＳ２５４へ進む。

ステップＳ２４６では、通信制御部２５２は、データパケットのヘッダ領域に含まれる制御情報を取得する（ステップＳ２４６）。次に、通信制御部２５２は、例えば、取得した制御情報に含まれるアプリケーションクラス、端末クラス及び事業者の組合せに対応する転送先ノードを、宛て先ノードデータを用いて識別する（ステップＳ２４８）。そして、通信制御部２５２は、識別した宛て先ノードを指定する宛て先ノード指定情報を、データパケットの宛て先フィールドに挿入する（ステップＳ２５０）。このとき、通信制御部２５２は、必要に応じてデータパケット内のフラグの値を更新する。

そして、送信部１４４は、次のホップ（例えば、トラフィックが分散されるように選択される転送先ノード又は既定の通信ノード）へデータパケットを転送する（ステップＳ２５４）。

図１９Ｂは、宛て先ノードデータを用いないデータ転送処理の流れの一例を示している。図１９Ｂの例において、まず、通信装置２４０の受信部１４２は、端末装置２００から送信されたデータパケットを受信する（ステップＳ２４２）。そして、受信部１４２は、受信したデータパケットを通信制御部２５２へ出力する。次に、通信制御部２５２は、受信したデータパケットがＭＴＣ通信のためのパケットであるか否かを判定する（ステップＳ２４４）。ここで、データパケットがＭＴＣ通信のためのパケットであれば、処理はステップＳ２４７へ進む。一方、データパケットがＭＴＣ通信のためのパケットでなければ、処理はステップＳ２５４へ進む。

ステップＳ２４７では、通信制御部２５２は、データパケット内のフラグを参照することにより、宛て先フィールドが変更されているか否かを判定する（ステップＳ２４７）。ここで、宛て先フィールドが変更されている場合には、処理はステップＳ２４９へ進む。一方、宛て先フィールドが変更されていない場合には、処理はステップＳ２５４へ進む。

ステップＳ２４９では、通信制御部２５２は、データパケット内の予備フィールドに転記された情報から宛て先ノードを識別する（ステップＳ２４９）。そして、通信制御部２５２は、識別した宛て先ノードを指定する宛て先ノード指定情報を、データパケットの宛て先フィールドに挿入する（ステップＳ２５２）。このとき、通信制御部２５２は、必要に応じてデータパケット内のフラグの値を更新する。

そして、送信部１４４は、次のホップ（例えば、トラフィックが分散されるように選択される転送先ノード又は既定の通信ノード）へデータパケットを転送する（ステップＳ２５４）。

［２−５．通信経路の例］
図２０は、本実施形態により実現され得る通信経路の例について説明するための説明図である。図２０を参照すると、一例としてのＭＴＣ通信の送信元である端末装置２００と、宛て先であるアプリケーションサーバ１９０との間の簡略化された３つの通信経路Ｒ１、Ｒ２及びＲ３が示されている。なお、ＡＣＫ及びＮＡＣＫなど付随的に行われる制御シグナリングについては、図中に示していない。通信経路Ｒ１は、端末装置２００とアプリケーションサーバ１９０との間の最短の（ルーティングメトリックが最適な）経路である。一方、通信経路Ｒ２及びＲ３は、通信経路Ｒ１に含まれる一部のリンクを迂回する冗長な経路である。

例えば、端末装置２００又は基地局２２０がデータパケットの宛て先フィールドにおいて中間ノードＭ１を指定した場合には、当該データパケットは通信経路Ｒ２を経由してアプリケーションサーバ１９０に到達し得る。また、例えば、端末装置２００又は基地局２２０が中間ノードＭ２を指定し、さらに中間ノードＭ２が中間ノードＭ３を指定した場合には、当該データパケットは通信経路Ｒ３を経由してアプリケーションサーバ１９０に到達し得る。このようにＭＴＣ通信のデータパケットを最短の経路から迂回させることで、トラフィックが分散され、特定の通信経路へのトラフィックの集中が未然に防がれる。

［２−６．情報管理サーバ］
（１）装置の構成例
図２１は、本実施形態に係る情報管理サーバ２７０の構成の一例を示すブロック図である。図２１を参照すると、情報管理サーバ２７０は、受信部２７２、送信部２７４、記憶部２８０及び情報管理部２８２を備える。

受信部２７２及び送信部２７４は、情報管理サーバ２７０が他の通信装置との間で通信を行うための通信インタフェースである。

記憶部２８０は、記憶媒体を用いて、図１８に例示した宛て先ノードデータと同様のデータ項目を有する宛て先ノードデータのマスタを記憶する。また、記憶部２８０は、図１４Ａ及び図１４Ｂに例示した中間ノードデータと同様のデータ項目を有する中間ノードデータのマスタを記憶してもよい。さらに、記憶部２８０は、第１の実施形態で説明した転送先データのマスタを記憶してもよい。

情報管理部２８２は、記憶部２８０により記憶される情報についてのマスタ管理機能を提供する。例えば、情報管理部２８２は、通信システム２に新たにアプリケーションサーバ１９０が導入された場合にアプリケーションに関する新たな情報の登録を受け付けるためのインタフェースを提供する。当該インタフェースは、例えば、装置の画面上でユーザからの情報入力を受け付けるグラフィカルユーザインタフェース（ＧＵＩ）であってよい。その代わりに、当該インタフェースは、例えば、アプリケーションサーバ１９０から登録情報を受信するＡＰＩ（Application Program Interface）であってもよい。また、情報管理部２８２が提供するインタフェースは、登録済みの情報の変更及び削除を受け付けてもよい。そして、情報管理部２８２は、マスタの更新（情報の追加、変更又は削除）が発生すると、マスタの差分に基づく更新データを通信システム２に含まれる通信ノードへ配信する。

（２）更新データの例
図２２は、更新データの一例について説明するための説明図である。例えば、事業者Ｊ０１が、新たにアプリケーションサーバＤ１、Ｄ３及びＤ５を導入した場合を想定する。その場合、事業者Ｊ０１のユーザ（エンジニア）は、情報管理部２８２が提供するユーザインタフェースを介して、アプリケーションサーバＤ１、Ｄ３及びＤ５の各々についての情報を情報管理サーバ２７０に登録する。ここで登録される情報は、例えば、各アプリケーションサーバに対応する、アプリケーションクラス、端末クラス及びＭＴＣ通信のための通信スケジュールなどを含み得る。その結果、情報管理部２８２は、記憶部２８０により記憶されている宛て先ノードデータのマスタを更新すると共に、図２２に例示したような更新データ２８３を生成する。

図２２を参照すると、更新データ２８３は、事業者ＩＤをキーとして、宛て先ノードの候補となり得るアプリケーションサーバごとに、対応するアプリケーションクラス、端末クラス及び通信スケジュールの情報を記述したデータである。更新データ２８３の各レコードには、「追加」、「変更」又は「削除」などの値をとり得る「更新区分」が付与される。情報管理サーバ２７０からこのような更新データ２８３を受信した中間ノードは、更新データ２８３を用いて、個々に記憶している宛て先ノードデータを最新のマスタに同期させる。

（３）更新データ配信処理の流れ
図２３Ａ及び図２３Ｂは、それぞれ、本実施形態に係る情報管理サーバ２７０による更新データ配信処理の流れの一例を示すフローチャートである。

図２３Ａは、マスタの更新の都度、更新データが中間ノードへ配信される例を示している。図２３Ａの例において、まず、情報管理サーバ２７０の情報管理部２８２は、ＧＵＩを介して（又はアプリケーションサーバ１９０から）、アプリケーションサーバ１９０についての登録情報を取得する（ステップＳ２７２）。次に、情報管理部２８２は、取得した登録情報を用いて、記憶部２８０により記憶されている宛て先ノードデータのマスタを更新する（ステップＳ２７４）。次に、情報管理部２８２は、更新により生じたマスタの差分に基づいて、図２２に例示したような更新データを生成する（ステップＳ２７６）。そして、送信部２７４は、情報管理部２８２により生成された更新データを、各中間ノードに配信する（ステップＳ２７８）。なお、更新データは、各中間ノードへブロードキャストされてもよく、個別にユニキャスト又はマルチキャストされてもよい。

図２３Ｂは、中間ノードからの要求に応じて更新データが中間ノードへ配信される例を示している。図２３Ｂの例において、情報管理サーバ２７０の受信部２７２により中間ノードからの更新データ配信要求が受信されると、処理はステップＳ２８４へ進む（ステップＳ２８２）。ステップＳ２８４において、情報管理部２８２は、更新データの前回の配信以降、宛て先ノードデータのマスタに差分が生じているか否かを判定する（ステップＳ２８４）。ここで、宛て先ノードデータのマスタに差分が生じている場合には、情報管理部２８２は、マスタの差分に基づいて更新データを生成する（ステップＳ２８６）。そして、送信部２７４は、情報管理部２８２により生成された更新データを、要求元の中間ノードに配信する（ステップＳ２８８）。一方、宛て先ノードデータのマスタに差分が生じていない場合には、情報管理部２８２は、差分が無いことを要求元の中間ノードに通知する（ステップＳ２８９）。

なお、図２３Ａ及び図２３Ｂの例に限定されず、情報管理サーバ２７０は、例えば、一定の頻度で定期的にマスタの差分の有無を判定し、差分が生じている場合に能動的に各中間ノードへ更新データを配信してもよい。

（４）データ更新処理の流れ
図２４は、本実施形態に係る中間ノードによる宛て先ノードデータ更新処理の流れの一例を示すフローチャートである。

図２４を参照すると、まず、通信装置２４０の受信部１４２は、情報管理サーバ２７０から配信される宛て先ノードデータの更新データを受信する（ステップＳ２９１）。次に、情報管理部２５４は、更新データ内に新たなアプリケーションクラスが存在するか否かを判定する（ステップＳ２９２）。ここで、更新データ内に新たなアプリケーションクラスが存在する場合には、当該新たなアプリケーションクラスを図１８に例示した宛て先ノードデータ２５１に追加する（ステップＳ２９３）。また、情報管理部２５４は、更新データ内に新たな端末クラスが存在するか否かを判定する（ステップＳ２９４）。ここで、更新データ内に新たな端末クラスが存在する場合には、当該新たな端末クラスを宛て先ノードデータ２５１に追加する（ステップＳ２９５）。さらに、情報管理部２５４は、更新データ内の事業者ＩＤが新たな事業者の事業者ＩＤであるか否かを判定する（ステップＳ２９６）。ここで、更新データ内の事業者ＩＤが新たな事業者の事業者ＩＤである場合には、当該新たな事業者の事業者ＩＤを宛て先ノードデータ２５１に追加する（ステップＳ２９７）。そして、情報管理部２５４は、更新データ内のアプリケーションクラス、端末クラス及び事業者ＩＤの組合せに対応する宛て先ノード（のＩＰアドレス又はホスト名などの情報）を宛て先ノードデータ２５１に追加し、又は既存の宛て先ノードを更新する（ステップＳ２９８）。

［２−７．ＤＲＸの管理］
なお、図２２に例示した更新データ２８３に含まれる通信スケジュール情報は、中間ノードからさらに対応する各端末装置２００へ配信され得る。その代わりに、情報管理サーバ２７０は、更新データ２８３とは別に通信スケジュール情報を各端末装置２００へ配信してもよい。通信スケジュール情報を受信した各端末装置２００は、当該通信スケジュール情報に従って自装置のスリープ時間を制御し、間欠動作（ＤＲＸ：Discontinuous Reception）を実現する。

端末装置２００の間欠動作の制御は、図２２に例示した通信スケジュール情報のように、１日１回（“every day”）又は１週間に１回（“every week”）といった単純なパラメータに従って制御されてもよい。例えば、１日１回（“every day”）が指定された場合には、端末装置２００の無線受信部１２２及び無線送信部１２４は、１日１回だけ任意の時間帯にウェイクアップし、その時間帯にアプリケーションデータを生成して上述したデータパケットをアプリケーションサーバ１９０に送信する。通信スケジュール情報は、間欠動作の周期に加えて、ウェイクアップの時間帯に関する情報（例えば、開始時刻及び終了時刻又は時間長など）を含んでもよい。

また、各端末装置２００について、基地局２２０又はその他の通信ノードにより、上述したウェイクアップの時間帯におけるより短い補助的な間欠動作の周期が決定されてもよい。その場合には、端末装置２００の無線受信部１２２及び無線送信部１２４は、指定されたウェイクアップの時間帯においても、例えば自装置のために通信リソースがスケジューリングされたタイミングを除いて、スリープし得る。それにより、端末装置２００の消費電力をより大きく低減することができる。

［２−８．第２の実施形態のまとめ］
ここまで、図１０〜図２４を用いて、本発明の第２の実施形態について説明した。本実施形態によれば、データパケットの宛て先ノードまでの経路上の、宛て先ノードとは異なる中間ノードを指定する中間ノード指定情報が、ＭＴＣ端末から送信されるデータパケットの宛て先フィールドに挿入される。それにより、ＭＴＣ通信のトラフィックが特定の通信経路に集中することなく、指定された中間ノードを経由する経路に迂回する。その結果、トラフィックが分散され、ＭＴＣ通信におけるトラフィックの輻輳が回避され又は緩和される。

また、本実施形態によれば、宛て先フィールドに中間ノード指定情報を挿入する装置は、ＭＴＣ端末からデータパケットを受信する通信ノード（例えば、基地局など）であってよい。このような通信ノードがデータパケットに中間ノード指定情報を挿入する場合には、ＭＴＣ端末に処理ロジックの改変などのインパクトを与えることなく、上述した実施形態による輻輳回避の手法を導入することができる。

また、本実施形態によれば、指定された中間ノードは、データパケット内に挿入されるＭＴＣ端末に関する制御情報、又は予備的なフィールドに転記される情報から、データパケットの最終的な宛て先ノードを識別する。従って、データパケットの宛て先フィールドが変更された場合であっても、中間ノードを経由して適切にデータパケットを最終的な宛て先ノード（例えば、対応するアプリケーションサーバ）に届けることができる。

本実施形態において、ＭＴＣ端末に関する制御情報を用いて宛て先ノードが識別される場合には、予備的なフィールドに宛て先ノードに関する情報を転記する必要がないため、既存のパケットフォーマットを効果的に活用することができる。一方、予備的なフィールドに転記される情報から宛て先ノードが識別される場合には、各中間ノードは宛て先ノードデータを保持しなくてよいため、宛て先ノードデータの参照に要する処理コスト及び記憶媒体のリソースを削減することができる。

［２−９．応用例］
第２の実施形態では、主にＭＴＣ端末から送信されるデータパケットを中間ノードを経由する経路に迂回させる例について説明した。しかしながら、上述した中間ノードの指定の仕組みは、ＭＴＣ端末へ送信されるデータパケットにも適用可能である。例えば、図１０に示した通信装置１４０は、図１５Ｄ又は図１５Ｅに示した宛て先フィールド更新処理に従って、端末装置２００へ送信されるデータパケットの宛て先フィールドに中間ノード指定情報を挿入すると共に、宛て先フィールドに記述されていた端末装置２００のアドレスなどの情報を予備フィールドに転記してもよい。

なお、本明細書において説明した各装置による一連の制御処理は、ソフトウェア、ハードウェア、及びソフトウェアとハードウェアとの組合せのいずれを用いて実現されてもよい。ソフトウェアを構成するプログラムは、例えば、各装置の内部又は外部に設けられる記憶媒体に予め格納される。そして、各プログラムは、例えば、実行時にＲＡＭ（Random Access Memory）に読み込まれ、ＣＰＵ（Central Processing Unit）などのプロセッサにより実行される。

また、本明細書では、ＭＴＣ端末である端末装置１００及び２００が無線通信によりネットワークにアクセスする例について主に説明した。しかしながら、上述した２つの実施形態の効果は、ＭＴＣ端末が有線通信によりネットワークにアクセスする場合にも同等に享受され得る。

以上、添付図面を参照しながら本発明の好適な実施形態について詳細に説明したが、本発明はかかる例に限定されない。本発明の属する技術の分野における通常の知識を有する者であれば、特許請求の範囲に記載された技術的思想の範疇内において、各種の変更例または修正例に想到し得ることは明らかであり、これらについても、当然に本発明の技術的範囲に属するものと了解される。

１，２ 通信システム
１０ コアネットワーク
２０ ネットワーク
１００，２００ 端末装置
１２０，２２０ 基地局
１４０ 通信装置（転送ノード）
２４０ 通信装置（中間ノード）
２７０ 情報管理サーバ
１９０ アプリケーションサーバ

Claims (9)

1. 端末装置から送信され又は端末装置へ送信されるデータパケットを受信する受信部と、
   前記データパケットの宛て先フィールドに記述されている情報を他のフィールドに転記し、前記データパケットの宛て先ノードまでの経路上の前記宛て先ノードとは異なる中間ノードを指定する中間ノード指定情報を、前記データパケットの前記宛て先フィールドに挿入する通信制御部と、
   前記中間ノード指定情報が挿入された前記データパケットを送信する送信部と、
   を備え、
   前記通信制御部は、前記端末装置がＭＴＣ端末である場合に、前記データパケットの前記宛て先フィールドに前記中間ノード指定情報を挿入する、
   通信装置。
2. 前記通信制御部は、指定すべき中間ノードを特定するための中間ノードデータを用いて、複数の中間ノードの候補から前記データパケットのために指定すべき中間ノードを特定する、請求項１に記載の通信装置。
3. 前記通信制御部は、前記宛て先フィールドが変更されたことを示すフラグを前記データパケットに付加する、請求項１に記載の通信装置。
4. 前記通信装置は、複数の中間ノードの候補のうちの１つである、請求項１に記載の通信装置。
5. 端末装置から送信され又は端末装置へ送信されるデータパケットを受信するステップと、
   前記データパケットの宛て先フィールドに記述されている情報を他のフィールドに転記するステップと、
   前記データパケットの宛て先ノードまでの経路上の前記宛て先ノードとは異なる中間ノードを指定する中間ノード指定情報を、前記データパケットの宛て先フィールドに挿入するステップと、
   前記中間ノード指定情報が挿入された前記データパケットを送信するステップと、
   を含み、
   前記中間ノード指定情報は、前記端末装置がＭＴＣ端末である場合に前記データパケットの前記宛て先フィールドにを挿入される、
   通信制御方法。
6. 自装置が宛て先フィールドにおいて指定されている、端末装置から送信され又は端末装置へ送信されるデータパケットを受信する受信部と、
   他の通信ノードにより前記データパケット内の前記宛て先フィールドとは異なるフィールドに前記宛て先フィールドから転記された情報から、前記データパケットの宛て先ノードを識別し、識別した当該宛て先ノードを指定する宛て先ノード指定情報を前記宛て先フィールドに挿入する通信制御部と、
   前記宛て先ノード指定情報が挿入された前記データパケットを送信する送信部と、
   を備える通信装置。
7. 複数の通信ノードを含む通信ネットワーク内の通信装置における通信制御方法であって、
   自装置が宛て先フィールドにおいて指定されている、端末装置から送信され又は端末装置へ送信されるデータパケットを受信するステップと、
   他の通信ノードにより前記データパケット内の前記宛て先フィールドとは異なるフィールドに前記宛て先フィールドから転記された情報から、前記データパケットの宛て先ノードを識別するステップと、
   識別した前記宛て先ノードを指定する宛て先ノード指定情報を前記宛て先フィールドに挿入するステップと、
   前記宛て先ノード指定情報が挿入された前記データパケットを送信するステップと、
   を含む通信制御方法。
8. 端末装置から送信され又は端末装置へ送信されるデータパケットの宛て先フィールドに記述されている情報を他のフィールドに転記し、前記データパケットの宛て先ノードまでの経路上の前記宛て先ノードとは異なる中間ノードを指定する中間ノード指定情報を、前記データパケットの宛て先フィールドに挿入する通信制御部、及び
   前記中間ノード指定情報が挿入された前記データパケットを送信する送信部、
   を備える第１の通信装置と、
   自装置が宛て先フィールドにおいて指定されている前記データパケットを受信する受信部、
   前記第１の通信装置により前記他のフィールドに転記された情報から、前記データパケットの宛て先ノードを識別し、識別した当該宛て先ノードを指定する宛て先ノード指定情報を前記宛て先フィールドに挿入する通信制御部、及び
   前記宛て先ノード指定情報が挿入された前記データパケットを送信する送信部、
   を備える第２の通信装置と、
   を含み、
   前記第２の通信装置は、前記中間ノードの候補である、
   通信システム。
9. ＭＴＣ端末から送信され又はＭＴＣ端末へ送信されるデータパケットが経由すべき、前記データパケットの宛て先ノードまでの経路上の前記宛て先ノードとは異なる中間ノードを複数の中間ノードの候補から指定する際に用いられる中間ノードデータ、を記憶する記憶部と、
   前記記憶部により記憶されている前記中間ノードデータの更新を管理する管理部と、
   前記データパケットの前記宛て先ノードまでの経路上の前記中間ノードを指定する通信ノードに、前記中間ノードデータに関する更新データを送信する送信部と、
   を備え、
   前記データパケットは、前記データパケットがＭＴＣ通信のためのパケットであることを判定するために使用される情報を含み、
   前記中間ノードデータは、指定すべき前記中間ノードを前記情報と関連付けて定義する、
   通信装置。
   

Images