JP2016046669A - パケット処理装置、プログラム及び方法 - Google Patents

Abstract

【課題】 大量のトラヒックが発生した場合でもより安定的に端末群をネットワークに接続させる。【解決手段】 本発明は、複数の端末と上位側ネットワークとの間で流れるパケットを中継処理するパケット処理装置に関する。そして、本発明のパケット処理装置は、複数のバッファ手段と、分析結果したパケットの分析結果に基づいて、いずれかのバッファ手段を選択し選択したバッファ手段に受信したパケットを振り分けるものであって、遅延を許容可能なアプリケーションに係るパケットと、その他のパケットとで振り分けるバッファ手段を分ける手段と、それぞれのバッファ手段が蓄積しているパケットを送出する送信手段と、それぞれのバッファ手段に対して送信手段で送信する際に用いる通信帯域を決定し、送信手段に決定した通信帯域で、それぞれのバッファ手段が保持しているパケットを送信するように制御する手段とを有することを特徴とする。【選択図】 図１

Description

この発明は、パケット処理装置、プログラム及び方法に関し、例えば、種々のモバイル端末のアクセスを受付けるアクセスネットワーク（モバイルネットワーク）に適用し得る。

従来のモバイル通信のアクセスネットワーク、例えば３Ｇ／ＬＴＥ（Ｌｏｎｇ Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ）では、Ｈ２Ｈ（Ｈｕｍａｎ ｔｏ Ｈｕｍａｎ）通信など、人が介在する通信に対して最適化されている。具体的には、従来のモバイル通信のアクセスネットワークでは、接続される携帯電話端末などのモバイル機器の台数や、人の行動特性に応じてネットワークが設計・構成されてきた。

昨今、IoT（Ｉｎｔｅｒｎｅｔ ｏｆ Ｔｈｉｎｇｓ）等のいわゆる「モノ・センサー」がネットワークに直接接続されるようになり、人間を介在しないＭ２Ｍ（Ｍａｃｈｉｎｅ ｔｏ Ｍａｃｈｉｎｅ）の通信を行うネットワークが注目されている。車・家電・ウェアラブル端末をはじめとする社会基盤が通信することで、災害に繋がる情報等を早期に収集し予測することが考えられている。これらのＭ２Ｍ通信端末は、数が非常に多いため常時モバイルネットワークに収容することは難しい。また、センシングしたデータのうち、早急に伝達しなければならない災害情報などは、バースト的に発生することが考えられる。従来のモバイル通信のアクセスネットワークでは、これらの制御トラヒック・データトラヒックを安定して処理する仕組みが求められている。

上述のような課題に対する試みとして、従来、アクセスネットワーク内の処理装置を仮想化し、ハードウェアで処理していた機能をソフトウェアとして実現することで、動的に必要な機能を追加・削除することが検討されている。この仮想化機能はＶＮＦ（Ｖｉｒｔｕａｌ Ｎｅｔｗｏｒｋ Ｆｕｎｃｔｉｏｎ：仮想化ネットワーク機能）と呼ばれ、ネットワークを動的に変化させることで、安定したトラヒック収容を目指している。尚、モバイルアクセスネットワークでは、ＥＰＣ（Ｅｖｏｌｖｅｄ Ｐａｃｋｅｔ Ｃｏｒｅ）という装置においてトラヒックが制御されており、この装置を仮想化したものがｖＥＰＣ（仮想化ＥＰＣ）と呼ばれる。

そして、従来、特許文献１、２では、モバイルネットワークに接続された端末から予測を超える大量トラヒックが発生する状況に対応するために、ネットワーク機器での通信処理の処理量を検出する手段を元に仮想的に処理ノードを生成し、処理ノードが不足しているときは違う地域に処理ノードを生成して通信処理をすることを提案している。そして、これにより、大量トラヒックが発生した際には処理ノードを仮想的に多数作成して大量の処理に対応することができると述べられている。

特許文献１のような動的な仮想化した機能の配置は当然できる状態であるが、たとえば仮想環境としてｖＥＰＣのような装置において、ＭＭＥ（Ｍｏｂｉｌｉｔｙ Ｍａｎａｇｅｍｅｎｔ Ｅｎｔｉｔｙ）の仮想マシンとＳ−ＧＷ（Ｓｅｒｖｉｎｇ ＧａｔｅＷａｙ）の仮想マシンの間の量が多いことを計測部によって計測し、輻輳が懸念されるような閾値を超えた通信が計測された場合に通信量が多い仮想ネットワーク機能同士（この場合、ＭＭＥとＳ−ＧＷ）を同一物理装置に移動させることで、ボトルネックとなる通信量を低減、輻輳を軽減する制御手段を提案している。

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

白井嵩士・可児島 建著、「Ｍ２ＭのＣ−ｐｌａｎｅ輻輳の課題に関する検討」、信学技報、ｖｏｌ．１１３、ｎｏ．４９２、ＩＣＭ２０１３−７４、ｐｐ１３１−１３６、２０１４年３月．

特許文献１、２の記載技術は、いずれもアクセス回線から流入したトラヒックによる輻輳を回避する技術であり、従来のようなＨ２Ｈの通信だけを考えれば、有効な手段といえる。

しかし、たとえば、Ｍ２Ｍの通信は、非特許文献１（輻輳パターンの検討表の技報）に見られるようなバースト的（急激）な制御信号による輻輳を発生させる。例えば、「ＮＷ装置の故障からの復旧に伴う通信の一斉開始」「停電からの復旧に伴う、通信の一斉開始」、「大規模災害発生時の信号送信の急増」、「公共交通の乱れに伴う、公共交通情報需要の急増」などが挙げられている。

これらの例で見られるように、従来人間主導で発生していた通信とは桁違いの機器が一斉に通信を開始することが従来の大きな課題である。具体的には、特許文献１の記載技術で処理できる限界量を遥かに超えたトラヒックであると想定されるため、物理資源で処理できるトラヒックより多くは処理できないという課題がある。また、仮想ネットワーク機能で遠くの物理資源を利用する場合でも、対応できるトラヒック量に限りがあるため、輻輳ならびに通信障害は回避できないという課題がある。加えて、M2Mの通信により生成されるトラヒックは人間主導による通信のトラヒックとはその特性および重要性が大きく異なることから、両者を区別したトラヒック制御が必要となる。

上述のような問題に鑑みて、大量のトラヒックが発生した場合でもより安定的に端末群をネットワークに接続させることができるパケット処理装置、プログラム及び方法が望まれている。

第１の本発明は、複数の端末と上位側ネットワークとの間で流れるパケットを中継処理するパケット処理装置において、（１）上記端末に係るパケットを受信する受信手段と、（２）上記受信手段が受信したパケットを分析する分析手段と、（３）上記受信手段が受信したパケットを一時的に蓄積する複数のバッファ手段と、（４）上記分析手段の分析結果に基づいて、いずれかの上記バッファ手段を選択し、選択したバッファ手段に受信したパケットの一部又は全部を振り分けるものであって、遅延を許容可能なアプリケーションに係るパケットと、その他のパケットとで振り分ける上記バッファ手段を分ける振分手段と、（５）それぞれの上記バッファ手段が蓄積しているパケットを送出する送信手段と、（６）それぞれの上記バッファ手段に対して上記送信手段で送信する際に用いる通信帯域を決定し、決定した通信帯域で、それぞれの上記バッファ手段が保持しているパケットを送信するように、上記送信手段を制御する送信制御手段とを有することを特徴とする。

第２の本発明のパケット処理プログラムは、複数の端末と上位側ネットワークとの間で流れるパケットを中継処理するパケット処理装置に搭載されたコンピュータを、（１）上記端末に係るパケットを受信する受信手段と、（２）上記受信手段が受信したパケットを分析する分析手段と、（３）上記受信手段が受信したパケットを一時的に蓄積する複数のバッファ手段と、（４）上記分析手段の分析結果に基づいて、いずれかの上記バッファ手段を選択し、選択したバッファ手段に受信したパケットの一部又は全部を振り分けるものであって、遅延を許容可能なアプリケーションに係るパケットと、その他のパケットとで振り分ける上記バッファ手段を分ける振分手段と、（５）それぞれの上記バッファ手段が蓄積しているパケットを送出する送信手段と、（６）それぞれの上記バッファ手段に対して上記送信手段で送信する際に用いる通信帯域を決定し、決定した通信帯域で、それぞれの上記バッファ手段が保持しているパケットを送信するように、上記送信手段を制御する送信制御手段として機能させることを特徴とする。

第３の本発明は、複数の端末と上位側ネットワークとの間で流れるパケットを中継処理するパケット処理装置が行うパケット処理方法において、（１）受信手段、分析手段、複数のバッファ手段、振分手段、及び送信制御手段を有し、（２）上記受信手段は、上記端末に係るパケットを受信し、（３）上記分析手段は、上記受信手段が受信したパケットを分析し、（４）それぞれの上記バッファ手段は、上記受信手段が受信したパケットを一時的に蓄積し、（５）上記振分手段は、上記分析手段の分析結果に基づいて、いずれかの上記バッファ手段を選択し、選択した上記バッファ手段に受信したパケットの一部又は全部を振り分けるものであって、遅延を許容可能なアプリケーションに係るパケットと、その他のパケットとで振り分ける上記バッファ手段を分け、（６）上記送信手段は、それぞれの上記バッファ手段が蓄積しているパケットを送出し、（７）上記送信制御手段は、それぞれの上記バッファ手段に対してパケット送信の際に用いる通信帯域を決定し、決定した通信帯域で、それぞれの上記バッファ手段が保持しているパケットを送信するように、上記送信手段を制御することを特徴とする。

本発明によれば、大量のトラヒックが発生した場合でもより品質要求条件に合わせて安定的に端末群をネットワークに接続させるパケット処理装置を提供する。

第１の実施形態に係るパケット処理装置を有する通信システムの全体構成について示したブロック図である。 第１の実施形態に係るパケット処理装置の動作について示したフローチャートである。 第２の実施形態に係るパケット処理装置を有する通信システムの全体構成について示したブロック図である。 第２の実施形態に係るパケット処理装置で保持するフロー統計値テーブルの構成例について示した説明図である。 第２の実施形態に係るパケット処理装置で保持するアプリケーション推定テーブルの構成例について示した説明図である。 第２の実施形態に係るパケット処理装置で保持するアプリケーション制御ポリシーテーブルの構成例について示した説明図である。 第２の実施形態に係るパケット処理装置の動作について示したフローチャートである。 第１の実施形態の変形実施形例に係る学習テーブルについて示した説明図である。 第２の実施形態の変形実施形例に係る学習テーブルについて示した説明図である。

（Ａ）第１の実施形態
以下、本発明によるパケット処理装置、プログラム及び方法の第１の実施形態を、図面を参照しながら詳述する。

（Ａ−１）第１の実施形態の構成
図１は、この実施形態のパケット処理装置１０を備える通信システム１の全体構成を示すブロック図である。

通信システム１は、複数のＵＥ（Ｕｓｅｒ Ｅｑｕｉｐｍｅｎｔ以下、「ＵＥ」と呼ぶ）４０や複数のＭ２Ｍ機器５０等の端末（以下、「モバイル端末」と呼ぶ）をコアネットワークＮ（上位ネットワーク側）に接続させるアクセスネットワーク（モバイルネットワーク）を構成している。この実施形態において、通信システム１は、ＬＴＥの規格に基づいて構成されているものとする。ＵＥ４０としては、例えば、スマートフォンや携帯端末等の種々の端末が該当する。また、Ｍ２Ｍ機器５０としては、例えば、ＩＯＴ等の人間が通信に介在しない種々の端末が該当する。言い換えると、ＵＥ４０は、Ｍ２Ｍに該当しない端末であるものとする。

また、この実施形態の通信システム１には、少なくともパケット処理装置１０、基地局装置２０及びモバイルアクセス装置３０が配置されているものとする。

基地局装置２０は、ＵＥ４０及びＭ２Ｍ機器５０を含む端末を収容（接続）する通信装置である。図１では図示を省略しているが、基地局装置２０が端末と接続する具体的な通信メディア（例えば、光ファイバー等）については限定されないものである。基地局装置２０としては、例えば、ＬＴＥのネットワークを構成するｅＮｏｄｅＢが該当する。図１では、基地局装置２０は１台の構成となっているが、１つのパケット処理装置１０の配下に接続される基地局装置２０の数は限定されないものであり、複数としてもよい。

パケット処理装置１０は、基地局装置２０で接続（収容）した端末とコアネットワークＮとの間で送受信するパケットを中継処理し、コアネットワークＮに接続させるものである。言い換えると、この実施形態のパケット処理装置１０は、ＬＴＥのネットワークにおける無線ネットワーク（ｅＵＴＲＡＮ：Ｅｖｏｌｖｅｄ Ｕｎｉｖｅｒｓａｌ Ｔｅｒｒｅｓｔｒｉａｌ Ｒａｄｉｏ Ｎｅｔｗｏｒｋ）とコアネットワークＮ（ＥＰＣ（Ｅｖｏｌｖｅｄ Ｐａｃｋｅｔ Ｃｏｒｅ）を含むネットワーク）の２つのネットワークの間、又はこの２つのネットワークの一方に配置されたノードとなっている。

図１に示すように、コアネットワークＮ上には、少なくとも、モバイルアクセス装置３０が配置されている。この実施形態では、モバイルアクセス装置３０は、パケット処理装置１０をコアネットワークＮ側に接続・収容させる装置となっている。モバイルアクセス装置３０としては、例えば、ＬＴＥのＥＰＣを構成するＭＭＥ、Ｓ−ＧＷ等の機能を担うノードであるものとして説明する。なお、コアネットワークＮ上に配置されるモバイルアクセス装置３０（ＥＰＣ）を配置する数は限定されないものであり、通常は複数台配置される。

図１では、コアネットワークＮ内部には、モバイルアクセス装置３０のみを図示しているが、コアネットワークＮ内部の構成については限定されないものである。また、図１では、モバイルアクセス装置３０に直接コアネットワークＮが接続されているが、モバイルアクセス装置３０とコアネットワークＮとの間のネットワーク構成については限定されないものである。なお、以下では、通信システム１において、モバイル端末側の方向を「下位側の方向」又は「下り方向」と呼び、コアネットワークＮ側の方向を「上位側の方向」又は「上り方向」と呼ぶものとする。

次に、パケット処理装置１０の内部構成について説明する。

パケット処理装置１０は、ネットワークインタフェース（以下、「ＮＷＩＦ」と呼ぶ）部１１、サービスリクエスト（以下、「ＳＲ」と呼ぶ）検出部１２、Ｍ２Ｍ識別部１０３、Ｍ２Ｍメモリバッファ１０４、通常メモリバッファ１０５、ＳＲ制御部１０６、及びＮＷＩＦ部１０７を有している。

パケット処理装置１０は、例えば、コンピュータに実施形態のパケット処理プログラムを実行させることにより実現するようにしてもよい。また、パケット処理装置１０として機能させる装置は単独機能の装置に限定されないものであり、モバイルアクセス装置３０等のコアネットワークＮ内部の装置において、（当該のコンピュータ上において）ソフトウェア的にパケット処理装置のノードを構成（仮想的に構成）するようにしてもよい。

ＮＷＩＦ部１０１は、下位側（基地局装置２０）と接続するためのネットワークインタフェースである。また、ＮＷＩＦ部１０７は、上位側（コアネットワークＮ側）と接続するためのネットワークインタフェースである。

ＳＲ検出部１０２は、下位側から受信した上り方向のパケットのそれぞれについて、ＳＲパケット（モバイルネットワークに接続するための制御信号）であるかどうかを判定する処理を行う。

ＬＴＥに対応する各モバイル端末（ＵＥ４０及びＭ２Ｍ機器５０）は、ＳＲパケットがＭＭＥ（この実施形態では、モバイルアクセス装置３０）で処理されコアネットワークＮへの接続が認められないとデータ通信を開始することができない。そして、ＳＲ検出部１０２は、ＳＲパケットと判定されたパケットを、Ｍ２Ｍ識別部１０３へ供給（ＳＲパケットのコピーをＭ２Ｍ識別部１０３へ供給）する。また、ＳＲ検出部１０２は、ＳＲパケット以外のパケットについて、コアネットワークＮ側（モバイルアクセス装置３０）に中継送信（ＮＷＩＦ部１０７を介してモバイルアクセス装置３０に送信）する。

Ｍ２Ｍ識別部１０３は、ＳＲ検出部１０２から、ＳＲパケットが供給された場合、当該ＳＲパケットの送信元が、Ｍ２Ｍ機器５０であるか否か（Ｍ２Ｍのアプリケーションに係るパケットであるか否か）を識別する。そして、Ｍ２Ｍ識別部１０３は、識別結果に応じて、当該ＳＲパケットを、Ｍ２Ｍメモリバッファ１０４又は通常メモリバッファ１０５のいずれかに振り分けて保持（メモリバッファに記憶）させる。Ｍ２Ｍ識別部１０３は、供給されたＳＲパケットの送信元についてＭ２Ｍ機器５０と判定した場合、当該ＳＲパケットをＭ２Ｍメモリバッファ１０４に供給し、当該ＳＲパケットの送信元についてＭ２Ｍ機器５０以外（ＵＥ４０）と判定した場合、当該ＳＲパケットを通常メモリバッファ１０５に供給する。

Ｍ２Ｍ識別部１０３が、ＳＲパケットの送信元について、Ｍ２Ｍ機器５０であるか否かを判定する方法としては、例えば、以下の２つの方法が挙げられる。

[第１の判定方法]
Ｍ２Ｍ識別部１０３は、例えば、ＳＲパケットのヘッダ情報に含まれるＡＰＮ（Ａｃｃｅｓｓ Ｐｏｉｎｔ Ｎａｍｅ）の情報に基づいて、当該ＳＲパケットの送信元がＭ２Ｍ機器５０であるか否かを判定するようにしてもよい。通常、ＬＴＥのネットワークに接続する端末は、ＡＰＮを指定して接続を行う。例えば、通信システム１において、Ｍ２Ｍサービスのアプリケーションに対して、所定のＡＰＮが割り当てられているとすれば、Ｍ２Ｍ機器５０が送出するＳＲパケットには、その所定のＡＰＮが指定されていることになる。したがって、Ｍ２Ｍ識別部１０３は、上述のようにＡＰＮを利用して、ＳＲパケットの送信元がＭ２Ｍ機器５０であるか否か（Ｍ２Ｍサービスを利用する端末であるか否か）を判定することができる。

[第２の判定方法]
Ｍ２Ｍ識別部１０３は、例えば、ＳＲパケットのヘッダ情報に含まれる送信元のハードウェア識別子に基づいて、当該ＳＲパケットの送信元がＭ２Ｍ機器５０であるか否かを判定するようにしてもよい。具体的には、例えば、モバイル端末に付与されるＩＭＥＩ（Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｍｏｂｉｌｅ Ｅｑｕｉｐｍｅｎｔ Ｉｄｅｎｔｉｔｙ）の先頭８桁で構成されるＴＡＣ（Ｔｙｐｅ Ａｌｌｏｃａｔｉｏｎ Ｎｕｍｂｅｒ）に基づいて、当該ＳＲパケットの属性を識別することができる。ＴＡＣは通常モバイル端末の機種や製造元等を識別することに用いられる。例えば、Ｍ２Ｍ機器５０に予め所定のＴＡＣを含むＩＭＥＩを付与しておけば、Ｍ２Ｍ識別部１０３でＳＲパケットを参照することにより、当該ＳＲパケットの送信元の属性（Ｍ２Ｍ機器５０であるか否か）を判定することができる。

Ｍ２Ｍメモリバッファ１０４は、Ｍ２Ｍ機器５０が送信元となるＳＲパケットを保持（蓄積）し、所定の待行列方式（例えば、ＦＩＦＯ（Ｆｉｒｓｔ Ｉｎ Ｆｉｒｓｔ Ｏｕｔ）等）に基づいて、保持したＳＲパケットを出力（ＳＲ制御部１０６に供給）する。また、Ｍ２Ｍメモリバッファ１０４は、保持（バッファリング）の状況に応じて、保持しているＳＲパケットを破棄する。Ｍ２Ｍメモリバッファ１０４は、例えば、所定時間以上保持しているＳＲパケットを破棄したり、保持しているＳＲパケットの総量（例えば、パケット数やデータ量）が所定数以上となった場合等に一部のＳＲパケットを破棄（例えば、最も古いＳＲパケットから順に破棄）して、保持するＳＲパケットの総量が所定量を下回るように（処理能力を超えないように）してもよい。さらに、Ｍ２Ｍメモリバッファ１０４は、ＳＲ制御部１０６からの制御に応じたタイミングで、保持しているＳＲパケットを出力する。

通常メモリバッファ１０５は、送信元がＭ２Ｍ機器５０以外のＳＲパケットを保持（蓄積）し、所定の待ち行列方式（例えば、ＦＩＦＯ）に基づいて、保持したＳＲパケットを出力（ＳＲ制御部１０６に供給）する。また、通常メモリバッファ１０５は、保持（蓄積）の状況に応じて、保持しているＳＲパケットを破棄する。通常メモリバッファ１０５は、例えば、所定時間以上保持しているＳＲパケットを破棄したり、保持しているＳＲパケットの総量（例えば、パケット数やデータ量）が所定数以上となった場合等に一部のＳＲパケットを破棄（例えば、最も古いＳＲパケットから順に破棄）して、保持するＳＲパケットの総量を所定量を下回るように（処理能力を超えないように）してもよい。さらに、通常メモリバッファ１０５は、ＳＲ制御部１０６からの制御に応じたタイミングで、保持しているＳＲパケットを出力する。

ＳＲ制御部１０６は、Ｍ２Ｍメモリバッファ１０４及び通常メモリバッファ１０５を制御して、保持（蓄積）しているＳＲパケットの供給を受け、ＮＷＩＦ部１０７を介してコアネットワークＮ側に送信する処理を行う。モバイルアクセス装置３０が複数配置されている場合、ＳＲ制御部１０６は、ＳＲパケットを送信（転送）する際、適切なモバイルアクセス装置３０（ＥＰＣ）を選択する処理を行う。

ＳＲ制御部１０６は、Ｍ２Ｍメモリバッファ１０４及び通常メモリバッファ１０５のそれぞれから、単位時間あたりに受信（上位側へ送信）するＳＲパケットの数が所定数以下となるように、Ｍ２Ｍメモリバッファ１０４及び通常メモリバッファ１０５を制御するようにしてもよい。例えば、ＳＲ制御部１０６がＭ２Ｍメモリバッファ１０４から１秒当たりに受信するＳＲパケットの数をＸとし、通常メモリバッファ１０５から１秒当たりに受信するＳＲパケットの数をＹとする。この場合、例えば、ＳＲ制御部１０６は、ＸとＹの比率が２対８（Ｘ／Ｙ＝２／８）となるように制御するようにしてもよい。このとき、ＳＲ制御部１０６側で、各バッファメモリ（Ｍ２Ｍメモリバッファ１０４及び通常メモリバッファ１０５）にＳＲパケットの出力タイミングを指示する信号を通知するようにしてもよいし、各バッファメモリに、ＳＲパケットの送信タイミングを決定するためのパラメータ（例えば、上述のＳＲパケット送信の比率）だけを通知して、各バッファメモリ側でＳＲパケットの送信タイミングを決定するようにしてもよい。

以上のように、この実施形態では、ＳＲ制御部１０６、Ｍ２Ｍメモリバッファ１０４及び通常メモリバッファ１０５により、Ｍ２ＭのＳＲパケットと、Ｍ２Ｍ以外のＳＲパケットとの帯域を分ける送信制御手段（帯域制御手段）が構成されている。

（Ａ−２）第１の実施形態の動作
次に、以上のような構成を有する第１の実施形態の通信システム１におけるパケット処理装置１０の動作について、図２のフローチャートを用いて説明する。

モバイル端末（ＵＥ４０、及びＭ２Ｍ機器５０）の電源が投入されると、当該モバイル端末は、保持している設定内容（例えば、フラッシュメモリやＨＤＤ等の不揮発メモリに保持された設定）等に従った起動処理を行い、モバイルアクセス装置３０を介したコアネットワークＮへの接続処理を行う。ＬＴＥのネットワークにおいては、各モバイル端末が、コアネットワークＮに対してＳＲパケットを送信し、認証処理をした後、データ通信が可能となる。そして、図２では、上述のＳＲパケットを含む上り方向のパケットを受信した場合の動作について示している。

パケット処理装置１０（ＮＷＩＦ部１０１）では、下位側（基地局装置２０）からパケットを受信すると（Ｓ１０１）、当該パケットがＳＲ検出部１０２に供給され、ＳＲパケットであるか否かが確認される（Ｓ１０２）。パケット処理装置１０は、受信パケットがＳＲパケットだった場合には、後述するステップＳ１０３から動作する。一方、受信パケットがＳＲパケット以外のパケットだった場合には、ＳＲ検出部１０２は、当該受信パケットをＮＷＩＦ部１０７に供給する。パケット処理装置１０では、ＳＲパケット以外の受信パケットについては、単に上位側への中継転送の処理のみを行うものとする。

ＳＲ検出部１０２でＳＲパケットが検出されると、ＳＲ検出部１０２は、当該ＳＲパケットをＭ２Ｍ識別部１０３に供給する。そして、Ｍ２Ｍ識別部１０３は、当該ＳＲパケットのヘッダ情報等に基づいて、送信元がＭ２Ｍ機器５０であるか否か（Ｍ２Ｍのサービスのアプリケーションに係るＳＲパケットであるか否か）を判定する（Ｓ１０３）。

そして、Ｍ２Ｍ識別部１０３は、受信したＳＲパケットの送信元がＭ２Ｍ機器５０でないと判定した場合、当該ＳＲパケットを通常メモリバッファ１０５に供給して保持させる（Ｓ１０４）。そして、通常メモリバッファ１０５は、保持したＳＲパケットを、ＳＲ制御部１０６の制御に従った間隔（図２では、ＳＲ制御部１０６からの送信許可に応じた間隔）でＳＲパケットをＳＲ制御部１０６に供給することになる（Ｓ１０５）。

一方、Ｍ２Ｍ識別部１０３は、受信したＳＲパケットの送信元がＭ２Ｍ機器５０であると判定した場合、当該ＳＲパケットをＭ２Ｍメモリバッファ１０４に供給して保持させる（Ｓ１０６）。そして、Ｍ２Ｍメモリバッファ１０４は、保持したＳＲパケットを、ＳＲ制御部１０６の制御に従った間隔（図２では、ＳＲ制御部１０６からの送信許可に応じた間隔）でＳＲパケットをＳＲ制御部１０６に供給することになる（Ｓ１０７）。

ＳＲ制御部１０６は、あらかじめネットワーク管理者などから設定されたＳＲパケット処理量（単位時間当たりに処理可能なＳＲパケットの量）を元に通常メモリバッファ１０５とＭ２Ｍメモリバッファ１０４に割り当てる計算を行い、それぞれのメモリバッファに許容処理量を伝える。ＳＲ制御部１０６は、動作中に、ネットワーク管理者の操作等により、設定変更が行われるとその内容に従って各メモリバッファに対する制御内容を変更する。

そして、ＳＲ制御部１０６は、Ｍ２Ｍメモリバッファ１０４又は通常メモリバッファ１０５からＳＲパケットが供給されると、当該ＳＲパケットについて、少なくとも１つ以上登録されているモバイルアクセス装置３０（ＥＰＣ）のいずれかを宛先に指定して、ＮＷＩＦ部１０７に供給する。

そして、ＮＷＩＦ部１０７は、ＳＲ検出部１０２又はＳＲ制御部１０６から供給されたパケットを、コアネットワークＮ側に転送する処理を行うことになる（Ｓ１０９）。

（Ａ−３）第１の実施形態の効果
第１の実施形態実施形態によれば、以下のような効果を奏することができる。

通信システム１では、パケット処理装置１０を配置することにより、コアネットワークＮ（モバイルアクセス装置３０）へのＳＲパケット等の制御メッセージの流れを制御して、コアネットワークＮ（モバイルアクセス装置３０）における輻輳状態を抑制することができる。例えば、従来ＥＰＣ（この実施形態のモバイルアクセス装置３０）に対して大量の制御メッセージが発生した場合などにＥＰＣの処理許容量を超えてしまい、スマートフォン等の端末がネットワークに繋がらないという事態が発生するおそれがある。特に、Ｍ２Ｍ機器等の大量のメッセージを送信する場合のあるモバイル端末を原因として、コアネットワークＮ（モバイルアクセス装置３０）が輻輳状態となりやすい傾向にある。また、ＵＥ４０にはスマートフォン等の音声通話等のリアルタイム性の高いアプリケーションを実行する端末が含まれるため、これらのモバイル端末を収容する通信システム１では、通信事業者として品質を担保する必要があるアプリケーシヨンが輻輳することを未然に予防することにより、音声通話等の品質劣化を軽減することができる。これにより、第１の実施形態では、ユーザ（特に、モバイル端末で音声アプリケーションを仕様するユーザ）の体感品質の向上という効果を奏することができる。

（Ｂ）第２の実施形態
以下、本発明によるパケット処理装置、プログラム及び方法の第２の実施形態を、図面を参照しながら詳述する。

（Ｂ−１）第２の実施形態の構成
図３は、この実施形態のパケット処理装置１０Ａを備える通信システム１Ａの全体構成を示すブロック図であり、上述の図１と同一又は対応する部分には同一又は対応する符号を付している。

第１の実施形態のパケット処理装置１０では、ＳＲ検出部１０２、Ｍ２Ｍ識別部１０３、Ｍ２Ｍメモリバッファ１０４、通常メモリバッファ１０５、及びＳＲ制御部１０６を用いて、ＳＲパケットを含む下位側から送信されるパケットの処理を行っていた。これに対して、第２の実施形態では、フロー統計算出部１０８、アプリケーション推定部１０９、遅延メモリバッファ１１０、通常メモリバッファ１１１、及びパケット転送制御部１１２を用いて、下位側から送信されるパケットの処理を行う。

フロー統計算出部１０８は、下位側から送信されたパケットをフロー毎に分類し、さらに、フロー毎に統計情報（統計値）を算出する処理を行うものである。

ここで、各モバイル端末（モバイルアクセス装置３０及びＵＥ４０）から送出されるパケットのフローは、５−ｔｕｐｌｅｓ（送信元ＩＰアドレス、送信先ＩＰアドレス、プロトコル、送信元ポート番号、及び送信先ポート番号の組み合わせ）で分類可能なものであるものとする。なお、各モバイル端末（モバイルアクセス装置３０及びＵＥ４０）から送出されるパケットのフローの特性については５−ｔｕｐｌｅｓで分類可能なものに限定されないものである。例えば、各モバイル端末（モバイルアクセス装置３０及びＵＥ４０）から送出されるパケットの各フローが、ＧＴＰ（ＧＰＲＳ Ｔｕｎｎｅｌｉｎｇ Ｐｒｏｔｏｃｏｌ）に基づくトンネルを構成している場合には、「送信元ＩＰアドレス、送信先ＩＰアドレス、送信元ＵＤＰポート番号、送信先ＵＤＰポート番号」と、「ＴＥＩＤ（Ｔｕｎｎｅｌ Ｅｎｄｐｏｉｎｔ Ｉｄｅｎｔｉｆｉｅｒ）」との対で分類するようにしてもよい。

フロー統計算出部１０８は、パケットを受信する都度、例えば、図４のようなテーブル（以下、「フロー統計値テーブル」と呼ぶ）を更新することにより、フロー毎の統計情報を算出保持するようにしてもよい。

図４に示すフロー統計値テーブルでは、フローごとに、管理番号（テーブル上での各フローの管理番号）、フロー情報（当該フローを分類するための識別子の組み合わせ）、及び統計情報（１又は複数の項目の統計値として「パケット数」、「パケット受信間隔」等）の項目の情報が管理されている。

図４では、フロー情報には、５−ｔｕｐｌｅｓ（送信元ＩＰアドレス、送信先ＩＰアドレス、プロトコル、送信元ポート番号、及び送信先ポート番号の組み合わせ）が適用されている。図４に示すように、取得できないプロトコル名の情報や、ポートの情報等は「Ｎ／Ａ」と設定するようにしてもよい。プロトコル情報のうちＮ／Ａが設定されているフローについては、当該項目については捨象（省略）して分類を行うようにしてもよい。

この実施形態において、フロー統計値テーブルには、上り方向のフローについてのみ登録されるものとして説明するが、下りのみの統計情報、双方向のフロー及び統計情報を追加していても良い。フロー統計算出部１０８はフロー統計処理が終了したパケットをアプリケーション推定部１０９に供給する。また、フロー統計算出部１０８のフロー統計値テーブルは、アプリケーション推定部１０９で参照可能であるものとする。

アプリケーション推定部１０９は、フロー統計算出部１０８で算出されたフロー毎の統計情報を用いて、当該フローに係るアプリケーションを推定するアプリケーション推定処理を行う。アプリケーションの推定法は、既存の種々の手法を適用することができる。例えば、アプリケーション推定部１０９は、事前にアプリケーションごとのフローの統計値の特性情報を登録しておき、各フローの統計情報が、いずれかのアプリケーションの特性と一致する場合、当該フローのアプリケーションが当該アプリケーションのフローであると推定するようにしてもよい。フロー統計算出部１０８が取得する統計情報（統計値）、及び統計情報に基づくアプリケーションの推定処理の具体的な手法は限定されないものであるが、例えば、参考文献１（特開２０１３−１２７５０４号公報）の記載技術を適用するようにしてもよい。具体的には、例えば、パケット到着間隔、パケットサイズ、合計パケット数、合計パケットサイズ、転送時間のそれぞれの項目について、最小値、２５％値、５０％値、平均値、７５％値、最大値及び分散値とアプリケーションの組み合わせを学習させた学習器（例えば、参考文献１に記載された手段）を用意し、各フローの統計情報（統計値）を与えることで、当該フローのアプリケーションの推定結果が得られる構成としてもよい。

アプリケーション推定部１０９は、各フローについて任意のタイミングで、このアプリケーション推定処理を行う。アプリケーション推定部１０９は、例えば、フローが開始して以後の初期段階（例えば、フロー開始から１０パケット目や２０パケット目等の段階）、フローの定常段階（例えば、１００パケット目や２００パケット目等の段階）、ロングフローの段階（例えば、１０００パケット目や２０００パケット目等の段階）等に達した各フローについてアプリケーション推定処理を実行するようにしてもよい。

アプリケーション推定部１０９は、フロー毎のアプケーション推定処理結果を図５に示すようなテーブル（以下、「アプリケーション推定テーブル」と呼ぶ）を用いて管理するものとする。

図５では、管理番号１〜５のフローについて、それぞれ、静的なウェブページの閲覧（図５では「Ｗｅｂ（ｓｔａｔ）」）、ＩＰ電話端末等によるリアルタイム通信（図５では「Ｓｔｒｅａｍｉｎｇ」）、単純なデータ転送（図５では「Ｂｕｌｋ」）、サーバへのコマンド入力などを示すサーバ制御（図５では、「Ｉｎｔｅｒａｃｔｉｖｅ」）、及びサーバ非依存型のデータ転送（図５では、「Ｐ２Ｐ」）が推定結果（アプリケーション）として登録されている。なおＭ２Ｍのアプリケーションの具体的なアプリケーション（用途）としては、いわゆる「車々間通信」のアプリケーション（（Ｍ２ＭのＣａｒＣｏｍｍｕｎｉｃａｔｉｏｎ）、スマートメータのアプリケーション（図５では「ＳｍａｒｔＭｅｔｅｒ」）、及び人体の心拍数や血圧等の身体データを測定するセンサに係るアプリケーション（図５では、「Ｈｅａｌｔｈｃａｒｅ」）を適用することができる。アプリケーション推定部１０９は、例えば、上述に例示したいずれかのアプリケーションと推定されたフローについては、Ｍ２Ｍに係るアプリケーションと推定することができる。

また、アプリケーション推定部１０９は、図５に示すように、管理番号１〜５の各フローについて、当該フローのアプリケーション（推定結果）に基づいたトラヒック制御の制御ポリシーを決定して、アプリケーション推定テーブルに登録する。

アプリケーション推定部１０９は、例えば、予めアプリケーションごとの制御ポリシー（パケット転送の優先度）の情報（以下、「アプリケーション制御ポリシーテーブル」と呼ぶ）を保持しておき、当該情報に基づいて各フローの制御ポリシーを決定し、アプリケーション推定テーブルを更新するようにしてもよい。

図６は、アプリケーション制御ポリシーテーブルの構成例について示した説明図である。

この実施形態では、図５、図６に示すように、アプリケーション推定部１０９は、各フローに対して、優先度の高い方から順に「最優先」、「通常」、「遅延」の３段階の制御ポリシーのいずれかを決定する。なお、アプリケーション推定部１０９が決定する制御ポリシーの種類の数及び組み合わせは限定されないものであり、例えば、上述の３種類の制御ポリシーをさらに複数に分類して制御するようにしてもよい。

図６に示すアプリケーション制御ポリシーテーブルでは、「最優先」、「通常」、「遅延」のそれぞれの制御ポリシーに対応するアプリケーション名のリストが登録されている。

図６に示すように、最優先の制御ポリシーには、音声や映像等のリアルタイム性の高いアプリケーション（遅延が許容されない（許容量が少ない）アプリケーション）が登録されている。また、図６に示すように、遅延の制御ポリシーには、Ｍ２Ｍサービスに係るアプリケーション（図６ではＣａｒＣｏｍｍｕｎｉｃａｔｉｏｎ、ＳｍａｒｔＭｅｔｅｒ、Ｈｅａｌｔｈｃａｒｅ等）等の比較的多くの遅延が許容可能なアプリケーションが登録されている。さらに、通常の制御ポリシーには、大きな遅延が許容されるわけではないが、最優先のアプリケーションほどリアルタイム性の高くないアプリケーションが登録されている。アプリケーション制御ポリシーテーブルにおいて、各制御ポリシーに対応するアプリケーションの構成や、制御ポリシーの数については限定されるものではないが、この実施形態では、少なくともＭ２Ｍサービスに係るアプリケーションについては遅延の制御ポリシーを適用するものとして説明する。

そして、アプリケーション推定部１０９は、各フローのパケットについて制御ポリシーに応じた出力処理（それぞれの制御ポリシーに基づいたインタフェースを用いたパケット転送処理）の制御を行う。

アプリケーション推定部１０９は、制御ポリシーが最優先のフローのパケットについては、直ちに（他の制御ポリシーのパケットに優先して）、ＮＷＩＦ部１０７に出力して送信処理を実行させるものとする。また、アプリケーション推定部１０９は、制御ポリシーが「通常」のフローのパケットについては、通常メモリバッファ１１１に出力して保持させるものとする。さらに、アプリケーション推定部１０９は、制御ポリシーが「遅延」のフローのパケットについては、遅延メモリバッファ１１０に出力して保持させるものとする。

通常メモリバッファ１１１、及び遅延メモリバッファは、データパケットを保持するバッファである。各メモリバッファ（通常メモリバッファ１１１、及び遅延メモリバッファ）は、例えば、パケット転送制御部１１２に、バッファ量・処理待ちパケット量を伝え、転送しても良いデータパケットレートを取得する。そして、各メモリバッファ（通常メモリバッファ１１１、及び遅延メモリバッファ）は、取得したレートで、保持しているパケットを、パケット転送制御部１１２に供給する。

パケット転送制御部１１２は、出力用のネットワークインタフェース部（ＮＷＩＦ部１０７）のパケット転送レートを制御している。例えば、パケット転送制御部１１２は、最優先の制御ポリシーで転送されているフローのデータ量を元に、追加で処理可能な転送レート（ＮＷＩＦ部１０７で残っている帯域）を把握している。パケット転送制御部１１２は、追加で処理可能な転送レートより、追加処理する転送レートを計算し、通常メモリバッファ１１１と遅延メモリバッファ１１０に割り振って処理する。パケット転送制御部１１２は、例えば、追加で処理可能な転送レートを８対２の比率で、通常メモリバッファ１１１と遅延メモリバッファ１１０に割り振るようにしてもよい。

なお、第２の実施形態において、制御ポリシーが最優先のフローのパケットについてはメモリバッファが設けられていないが、最優先の制御ポリシー専用のメモリバッファを追加して最優先で中継転送するように構成してもよい。また、さらに制御ポリシーが追加される場合には、それらの制御ポリシーに対応するメモリバッファを追加するようにしてもよい。

以上のように、遅延メモリバッファ１１０、通常メモリバッファ１１１、及びパケット転送制御部１１２は、メモリバッファごとに帯域を分けた送信制御処理（帯域制御処理）を行う。

例えば、ＮＷＩＦ部１０７の最大の転送レートが、１００Ｇｂｐｓであり、制御ポリシーが最優先のデータパケットで、２０Ｇｂｐｓの帯域を利用している場合を想定する。ここで、パケット転送制御部１１２では、ＮＷＩＦ部１０７の最大の転送レートに対して８割までパケット転送に利用してもよいというポリシーが適用されているものとする。この場合、パケット転送制御部１１２は、パケット転送に、１００Ｇｂｐｓの８割として８０Ｇｂｐｓまでデータパケットを転送に利用可能であることになる。そして、既に、制御ポリシーが最優先のフローで２０Ｇｂｐｓの帯域を使用しているので、追加で処理可能な転送レートは、６０Ｇｂｐｓ（８０−２０）となる。さらに、パケット転送制御部１１２は、追加で処理可能な転送レートを８対２の比率で、通常メモリバッファ１１１と遅延メモリバッファ１１０に割り振るものとする。この場合、パケット転送制御部１１２は、通常メモリバッファ１１１に４８Ｇｂｐｓ（６０＊０．８）、遅延メモリバッファに１２Ｇｂｐｓ（６０＊０．２）の転送レートを割り振り、各メモリバッファを制御してパケット転送を受付けることになる。

（Ｂ−２）第２の実施形態の動作
次に、以上のような構成を有する第２の実施形態の通信システム１Ａにおけるパケット処理装置１０Ａの動作について、図７のフローチャートを用いて説明する。以下では、第２の実施形態のパケット処理装置１０Ａの動作について、第１の実施形態との差異を中心に説明する。

パケット処理装置１０Ａでは、ＮＷＩＦ部１０１が上り方向のパケットを受信すると（Ｓ２０１）、そのパケットが、フロー統計算出部１０８に供給される。

そして、フロー統計算出部１０８は、供給されたパケットについていずれかのフローに分類し、統計情報（フロー統計値テーブルの統計値）を更新する（Ｓ２０２）。また、フロー統計算出部１０８は、統計情報の更新が終了したパケットについてアプリケーション推定部１０９に供給する。

アプリケーション推定部１０９は、フロー統計算出部１０８からパケットが供給されると、当該パケットに係るフローについてアプリケーション推定タイミングとなった場合にのみアプリケーション推定処理を実行する（Ｓ２０３）。また、アプリケーション推定部１０９は、当該パケットに係るフローの制御ポリシーを確認する（Ｓ２０４、Ｓ２０５）。

アプリケーション推定部１０９は、例えば、所定のタイミング（例えば、当該パケットのフローについて受信したパケット数が所定数に達したタイミング）で、当該パケットのフローについて、アプリケーション推定処理を実行する。アプリケーション推定部１０９は、例えば、各フローについて、１０パケット目、２０パケット目、１００パケット目、２００パケット目、１０００パケット目、以後２０００パケット毎の各タイミングでアプリケーション推定処理を実行するようにしてもよい。そして、アプリケーション推定部１０９は、アプリケーション推定処理を行った場合、その結果に基づき必要に応じてアプリケーション推定テーブル（図５参照）を更新する。なお、アプリケーション推定部１０９は、例えば、未だアプリケーション推定処理が実行されていないフローに係るパケットを受信した場合には、通常の制御ポリシーを適用するようにしてもよい。

アプリケーション推定部１０９は、当該パケットが最優先の制御ポリシーに係るフローに属する場合には、当該パケットを直ちに、ＮＷＩＦ部１０７に供給する。

また、アプリケーション推定部１０９は、当該パケットが通常の制御ポリシーに係るフローに属する場合には、当該パケットを通常メモリバッファ１１１に供給する。そして、通常メモリバッファ１１１は、保持したパケットを、パケット転送制御部１１２の制御に従ったタイミングで、パケット転送制御部１１２に供給する（Ｓ２０６、Ｓ２０７）。

さらに、アプリケーション推定部１０９は、当該パケットが遅延の制御ポリシーに係るフローに属する場合には、当該パケットを遅延メモリバッファ１１０に供給する。そして、遅延メモリバッファ１１０は、保持したパケットを、パケット転送制御部１１２の制御に従ったタイミングで、パケット転送制御部１１２に供給する（Ｓ２０８、Ｓ２０９）。

例えば、アプリケーション推定テーブルの内容が、上述の図５のような内容だった場合、アプリケーション推定部１０９は、管理番号２のフロー（Ｓｔｒｅａｍｉｎｇ（Ｖｏｉｃｅ）のフロー）について最優先の制御ポリシーを設定しているため、当該フローのパケットについては、直接ＮＷＩＦ部１０７に供給することになる。また、アプリケーション推定部１０９は、管理番号３、５のフローについては、遅延の制御ポリシーを設定しているため、これらのフローのパケットについては、遅延メモリバッファ１１０に供給することになる。さらに、アプリケーション推定部１０９は、管理番号１、４のフローについては、通常の制御ポリシーを設定しているため、これらのフローのパケットについては、通常メモリバッファ１１１に供給することになる。

そして、パケット転送制御部１１２は、パケットが供給されると、当該パケットについて、少なくとも１つ以上登録されているモバイルアクセス装置３０（ＥＰＣ）を宛先に指定して、ＮＷＩＦ部１０７に供給する。そして、ＮＷＩＦ部１０７は、ＳＲ検出部１０２又はＳＲ制御部１０６から供給されたパケットを、コアネットワークＮ側に転送する処理を行うことになる（Ｓ２１０、Ｓ２１１）。

遅延メモリバッファ１１０及び通常メモリバッファ１１１は、アプリケーション推定部１０９からパケットを受け取って保持し、保持できる最大量と現在保持している量を定期的にパケット転送制御部１１２に通知するものとする。また、パケット転送制御部１１２から０より大きいビットレートを通知された場合は、通知されたピットレートを超えない量のパケットをパケット転送制御部１１２に送信するものとする。さらに、パケット転送制御部１１２は、ＮＷＩＦ部１０７を監視しており、最優先で処理するパケットの平均ビットレートを計測しているものとする。その上で、パケット転送制御部１１２は、許容できる通常メモリバッファ１１１からの転送レート、遅延メモリバッファからの転送レートを算出し、それぞれの転送レートを通常メモリバッファ１１１と遅延メモリバッファに通知し、その転送レートを超えない量のパケットをそれぞれより受け取る。パケット転送制御部１１２は、受け取ったパケットについてＮＷＩＦ部１０７を介して上位側に転送することになる。

（Ｂ−３）第２の実施形態の効果
第２の実施形態によれば、以下のような効果を奏することができる。

第２の実施形態の通信システム１Ａでは、第１の実施形態と同様の効果を奏することができる。すなわち、第２の実施形態においても、パケット処理装置１０Ａを配置することにより、コアネットワークＮ（モバイルアクセス装置３０）へのＳＲパケット等の制御メッセージの流れを制御して、コアネットワークＮ（モバイルアクセス装置３０）における輻輳状態を抑制することができる。

また、第２の実施形態では、アプリケーション推定部１０９（アプリケーション制御ポリシーテーブル）において、最優先の制御ポリシーに対して、リアルタイム性が高く遅延が許容されない（許容される遅延が少ない）アプリケーション（例えば、音声や映像に係るアプリケーション）を割当てているため、これらのアプリケーションのパケットが、Ｍ２Ｍに係るアプリケーションにより遅延することを抑制する等の効果を奏することができる。

（Ｃ）他の実施形態
本発明は、上記の各実施形態に限定されるものではなく、以下に例示するような変形実施形態も挙げることができる。

（Ｃ−１）第１の実施形態では、ＳＲパケットの処理に重点を置いた例について説明したが、Ｍ２Ｍ識別部１０３のＭ２Ｍ連携の仕組みとして、第２の実施形態の統計情報に基づくアプリケーション推定処理を適用するようにしてもよい。具体的には、第１の実施形態のＭ２Ｍ識別部１０３において、第２の実施形態で統計情報に基づきアプリケーション推定する処理（Ｍ２Ｍサービスに係るアプリケーションを識別する処理）を適用するようにしてもよい。この場合、第１の実施形態のパケット処理装置１０（Ｍ２Ｍ識別部１０３）は、例えば、モバイル端末毎（ＩＭＥＩ毎）の統計情報に基づいて、Ｍ２Ｍ端末（あるいはＭ２Ｍアプリケーシヨンを発生する端末）を抽出し、Ｍ２Ｍ端末と識別されたモバイル端末の識別子（ＩＭＥＩ）を管理する学習テーブル（例えば、図８に示すような学習テーブル）を用いるようにしてもよい。そして、第１の実施形態のパケット処理装置１０（Ｍ２Ｍ識別部１０３）は、上述の学習テーブルに基づいて、各ＳＲパケットの送信元がＭ２Ｍ端末であるか否か等を識別するようにしてもよい。図８に示す学習テーブルでは、Ｍ２Ｍ端末と認識されたモバイル端末毎のＩＭＥＩと統計情報が管理されている。

また、第２の実施形態においても、フロー統計算出部１０８が、フロー単位ではなくモバイル端末毎（ＩＭＥＩ毎）の統計情報を算出し、さらに、アプリケーション推定部１０９が、モバイル端末毎（ＩＭＥＩ毎）の統計情報に基づいて、モバイル端末毎（ＩＭＥＩ毎）のアプリケーションを識別することで、より詳細なポリシー制御を行うようにしてもよい。例えば、アプリケーション推定部１０９が、図９に示すようなモバイル端末毎（ＩＭＥＩ毎）のアプリケーションを管理する学習テーブルを備えるようにしてもよい。図９に示す学習テーブルでは、Ｍ２Ｍ端末と認識されたモバイル端末毎のＩＭＥＩと統計情報に加えて、当該Ｍ２Ｍ端末に係るトラヒックのアプリケーション（アプリケーションを示す識別番号）が管理されている。そして、アプリケーション推定部１０９は、上述の学習テーブルに従ってモバイル端末毎（ＩＭＥＩ毎）の制御ポリシー（アプリケーション制御ポリシーテーブルに従った制御ポリシー）を決定し、モバイル端末毎（ＩＭＥＩ毎）にパケットを振分ける出力処理を行うようにしてもよい。

（Ｃ−２）第１の実施形態では、ＳＲ制御部１０６はサービス開始要求のみを管理していたが、サービス終了など、モバイル端末の離脱状況もカウントするようにしてもよい。これにより、パケット処理装置１０では、コアネットワークＮ（モバイルアクセスネットワーク）に接続しているモバイル端末の絶対数を管理しながらＳＲパケットの許可数（例えば、単位時間当たりのＳＲパケットの転送数）を変更させることもでき、資源の利用効率の平滑化を実現できる効果がある。

（Ｃ−３）第１の実施形態では、ＳＲ制御部１０６は１つのモバイルアクセス装置３０（ＥＰＣ）に対してデータ転送をしているように図示しているが、実際にはモバイルアクセス装置３０には複数のＥＰＣ機能（ＭＭＥ、Ｓ−ＧＷ、Ｐ−ＧＷ）が存在しており、それらを動的に選択して通信させても良い。例えば、ＳＲ制御部１０６は、複数のモバイルアクセス装置３０（ＥＰＣ）に対して、ラウンドロビンで順番に要求を割り当てていくことで、モバイルアクセス装置３０（ＥＰＣ）の負荷を平滑化する効果を奏する。最も単純には、Ｍ２Ｍの場合とそれ以外の場合で接続するＥＰＣを変更する制御もある。

（Ｃ−４）第１の実施形態で、Ｍ２Ｍメモリバッファ１０４にＳＲパケットを渡す際、Ｍ２Ｍのタイプ（ＣａｒＣｏｍｍｕｎｉｃａｔｉｏｎ、ＳｍａｒｔＭｅｔｅｒ、ＨｅａｌｔｈＣａｒｅ等）や、緊急度（通常のデータ収集、緊急時のアラート）を付与し、ＦＩＦＯでなく、優先度をつけたキューイング処理をするようにしてもよい。これにより、第１の実施形態では、Ｍ２Ｍサービスのアプリケーション同士の融通による即時性の高いＭ２Ｍ通信を実現することができる。

（Ｃ−５）第１の実施形態で、ＳＲ制御部１０６が各メモリバッファからＳＲパケットのバッファ量を通知することも可能であり、あまりにもＳＲパケット量の変動が大きい場合などは、ｖＥＰＣとしてＭＭＥの仮想マシンの数を増やす制御のトリガとして動作しても良い。これにより物理資源の有効活用と、収容端末数の最適化ができる等の効果を奏する。

（Ｃ−６）第２の実施形態では、最優先、通常メモリバッファ、遅延メモリバッファの３種類の分類により輻輳制御を提案しているが、アプリケーション推定の対応によりアプリケーション毎のメモリバッファ（例えば、ＨＴＴＰメモリバッファ、ＶｉｄｅｏＳｔｒｅａｍｉｎｇメモリバッファ、ＶｏｉｃｅＳｔｒｅａｍメモリバッファ、Ｂｕｌｋメモリバッファ等）を用意して、細かい制御をするようにしてもよい。これにより、第２の実施形態において、アプリケーションに応じた最大限の遅延を許容しながら全体を最適化できる。

（Ｃ−７）第２の実施形態では、モバイル端末から送信される上り方向のパケットのみを用いて統計情報の算出をしているが、送受信両方のパケットを用いて統計情報を算出してアプリケーションの推定をしても良い。これにより、第２の実施形態では、アプリケーション推定の精度を向上させることができる。

（Ｃ−８）第２の実施形態では、モバイル端末のデータ通信時にＧＴＰトンネル毎に割り振るＱＣＩ（ＱｏＳ Ｃｌａｓｓ Ｉｄｅｎｔｉｆｉｅｒ）に関して言及していないが、ＱＣＩが適切に割り振られているかどうかの指標として利用するようにしてもよい、これにより、第２の実施形態では、アプリケーション毎のＱＣＩ割り振りの最適設計考えられる。

（Ｃ−９）第２の実施形態では、Ｍ２Ｍに係るアプリケーションの例として「ＣａｒＣｏｍｍｕｎｉｃａｔｉｏｎ、ＳｍａｒｔＭｅｔｅｒ、Ｈｅａｌｔｈｃａｒｅ」を示し、全てのＭ２Ｍのアプリケーションについては「遅延」の制御ポリシーを割当てるように設定していた（図６のアプリケーション制御ポリシーテーブル参照）。Ｍ２Ｍに係るアプリケーションであっても、一部の許容される遅延の少ないアプリケーションについては他の区分を割当てる（優先度を上げる）ようにしてもよい。例えば、「ＣａｒＣｏｍｍｕｎｉｃａｔｉｏｎ」に対して「最優先」の制御ポリシーを割当てるようにしてもよい。また、「ＳｍａｒｔＭｅｔｅｒ」に対して「遅延」の制御ポリシーを割当てるようにしてもよい。さらに、「Ｈｅａｌｔｈｃａｒｅ」に対して「通常」の制御ポリシーを割当てるようにしてもよい。

１…通信システム、１０…パケット処理装置、１０１…ＮＷＩＦ部、１０２…ＳＲ検出部、１０３…Ｍ２Ｍ識別部、１０４…Ｍ２Ｍメモリバッファ、１０５…通常メモリバッファ、１０６…ＳＲ制御部、１０７…ＮＷＩＦ部、２０…基地局装置、３０…モバイルアクセス装置、４０…ＵＥ、５０…Ｍ２Ｍ機器。

Claims (11)

1. 複数の端末と上位側ネットワークとの間で流れるパケットを中継処理するパケット処理装置において、
   上記端末に係るパケットを受信する受信手段と、
   上記受信手段が受信したパケットを分析する分析手段と、
   上記受信手段が受信したパケットを一時的に蓄積する複数のバッファ手段と、
   上記分析手段の分析結果に基づいて、いずれかの上記バッファ手段を選択し、選択した上記バッファ手段に受信したパケットの一部又は全部を振り分けるものであって、遅延を許容可能なアプリケーションに係るパケットと、その他のパケットとで振り分ける上記バッファ手段を分ける振分手段と、
   それぞれの上記バッファ手段が蓄積しているパケットを送出する送信手段と、
   それぞれの上記バッファ手段に対してパケット送信の際に用いる通信帯域を決定し、決定した通信帯域で、それぞれの上記バッファ手段が保持しているパケットを送信するように、上記送信手段を制御する送信制御手段と
   を有することを特徴とするパケット処理装置。
2. 上記分析手段は、上記端末から上記上位側ネットワークへ向けて送信されたサービス要求パケットを抽出し、抽出したサービス要求パケットについて、遅延を許容するアプリケーションに係る第１のサービス要求パケットか、それ以外のアプリケーションに係る第２のサービス要求パケットかを識別し、
   上記振分け手段は、第１のサービス要求パケットを第１のバッファ手段に供給し、第２のサービス要求パケットを第２のバッファ手段に供給する
   ことを特徴とする請求項１に記載のパケット処理装置。
3. 上記遅延を許容するアプリケーションには、Ｍ２Ｍに係るアプリケーションが含まれることを特徴とする請求項１又は２に記載のパケット処理装置。
4. 上記送信制御手段は、上記送信手段のパケット転送状況を監視することによって、上位側ネットワークの混雑度合いを把握して、動的にそれぞれの上記バッファ手段に割当てる通信帯域を変更することを特徴とする請求項１〜３のいずれかに記載のパケット処理装置。
5. 上記分析手段は、
   受信したパケットが属するフローを識別して、フローごとの統計情報を算出する統計情報算出処理部と
   それぞれのフローについて算出した統計情報に基づき対応するアプリケーションを推定するアプリケーション推定処理部とを有し、
   上記振分手段は、受信したパケットを、当該パケットが属するフローのアプリケーションに対応する上記バッファ手段に供給する
   ことを特徴とする請求項１に記載のパケット処理装置。
6. 上記アプリケーション推定処理部は、アプリケーションごとに統計情報の特性を学習させた学習器を用いて、上記統計情報算出処理部が算出した統計情報に対応するアプリケーションを推定する処理を行うことを特徴とする請求項５に記載のパケット処理装置。
7. 上記振分手段は、第１の優先度でパケット転送を行うべきアプリケーションのフローに属するパケットについて第１のバッファ手段に供給し、第１の優先度よりも低い第２の優先度でパケット転送を行うアプリケーションのフローに属するパケットについて第２のバッファ手段に供給し、
   上記送信制御手段は、上記第１のバッファ手段に対して、上記第２のバッファ手段よりも優先的に通信帯域を割当てる
   ことを特徴とする請求項５又は６に記載のパケット処理装置。
8. 上記分析手段は、
   受信したパケットの送信元の上記端末ごとの統計情報を算出する統計情報算出処理部と
   それぞれの上記端末について算出した統計情報に基づき、第１のサービス要求パケットか、第２のサービス要求パケットかを識別する識別部とを有し、
   上記振分け手段は、第１のサービス要求パケットを第１のバッファ手段に供給し、第２のサービス要求パケットを第２のバッファ手段に供給する
   ことを特徴とする請求項１に記載のパケット処理装置。
9. 上記分析手段は、
   受信したパケットの送信元の上記端末ごとの統計情報を算出する統計情報算出処理部と、
   それぞれの上記端末について算出した統計情報に基づき、それぞれの上記端末が対応するアプリケーションを推定するアプリケーション推定処理部とを有し、
   上記振分手段は、受信したパケットを、当該パケットの送信元の上記端末に係るアプリケーションに対応する上記バッファ手段に供給する
   ことを特徴とする請求項１に記載のパケット処理装置。
10. 複数の端末と上位側ネットワークとの間で流れるパケットを中継処理するパケット処理装置に搭載されたコンピュータを、
    上記端末に係るパケットを受信する受信手段と、
    上記受信手段が受信したパケットを分析する分析手段と、
    上記受信手段が受信したパケットを一時的に蓄積する複数のバッファ手段と、
    上記分析手段の分析結果に基づいて、いずれかの上記バッファ手段を選択し、選択した上記バッファ手段に受信したパケットの一部又は全部を振り分けるものであって、遅延を許容可能なアプリケーションに係るパケットと、その他のパケットとで振り分ける上記バッファ手段を分ける振分手段と、
    それぞれの上記バッファ手段が蓄積しているパケットを送出する送信手段と、
    それぞれの上記バッファ手段に対してパケット送信の際に用いる通信帯域を決定し、決定した通信帯域で、それぞれの上記バッファ手段が保持しているパケットを送信するように、上記送信手段を制御する送信制御手段と
    して機能させることを特徴とするパケット処理プログラム。
11. 複数の端末と上位側ネットワークとの間で流れるパケットを中継処理するパケット処理装置が行うパケット処理方法において、
    受信手段、分析手段、複数のバッファ手段、振分手段、及び送信制御手段を有し、
    上記受信手段は、上記端末に係るパケットを受信し、
    上記分析手段は、上記受信手段が受信したパケットを分析し、
    それぞれの上記バッファ手段は、上記受信手段が受信したパケットを一時的に蓄積し、
    上記振分手段は、上記分析手段の分析結果に基づいて、いずれかの上記バッファ手段を選択し、選択した上記バッファ手段に受信したパケットの一部又は全部を振り分けるものであって、遅延を許容可能なアプリケーションに係るパケットと、その他のパケットとで振り分ける上記バッファ手段を分け、
    上記送信手段は、それぞれの上記バッファ手段が蓄積しているパケットを送出し、
    上記送信制御手段は、それぞれの上記バッファ手段に対してパケット送信の際に用いる通信帯域を決定し、決定した通信帯域で、それぞれの上記バッファ手段が保持しているパケットを送信するように、上記送信手段を制御する
    ことを特徴とするパケット処理方法。

Images