(57)【要約】【課題】転送処理の効率化を図ること。【解決手段】転送装置１０４では、セッションの要求元からセッション生成リクエストＲＥＱを受信すると、ＳＭＣ−Ｕ２０５が、セッション情報Ｓをメモリ２０６に格納する。転送装置１０４は、Ｃ−Ｐｌａｎｅ  ＴＥＩＤおよびＵ−Ｐｌａｎｅ  ＴＥＩＤが埋め込まれたセッション生成レスポンスＲＥＳを要求元に送信する。転送装置１０４は、メモリ２０６に格納されたセッション情報Ｓを、メモリ２１０にキャッシュする。転送装置１０４は、ＮＩＦ２０１により、ユーザプレーンパケット２２０を受信すると、メモリ２１０にキャッシュされたセッション情報Ｓを参照して、ＮＩＦ２０１によりユーザプレーンパケット２２０のヘッダを変換する。そして、ＮＩＦ２０１は、ヘッダを変換したユーザプレーンパケット２３０を宛先に転送する。【選択図】  図２
2014155032.tif 000002
【特許請求の範囲】
【請求項１】
宛先とのセッションを要求する第１の制御パケットが送信元から受信された場合に、前記送信元と前記宛先との前記セッションに関する情報を生成して、第１の記憶部に格納する生成部と、
前記第１の記憶部に記憶された前記セッションに関する情報を参照して、前記送信元と前記宛先との間の前記セッション中の通信を制御する制御部と、
前記送信元から前記第１の制御パケットを受信し、前記セッションが生成されたことを示す第２の制御パケットを前記送信元に送信するとともに、前記制御部による制御にしたがって前記セッション中における前記送信元と前記宛先との間のパケットを送受信する通信処理と、前記第１の記憶部に格納された前記セッションに関する情報をアクセス可能な第２の記憶部に格納するとともに、前記セッション中に前記通信処理によって前記送信元または前記宛先から前記パケットが受信された場合に、前記第２の記憶部に格納された前記セッションに関する情報を参照して、前記制御部の替わりに前記セッション中の通信を制御する制御処理と、を実行する通信部と、
を有することを特徴とする転送装置。
【請求項２】
前記通信部は、前記第２の制御パケットを前記送信元に送信する場合に、前記第１の記憶部に格納された前記セッションに関する情報を前記第２の記憶部に格納することを特徴とする請求項１に記載の転送装置。
【請求項３】
前記通信部は、前記第２の制御パケットを前記送信元に送信する場合に、前記第２の記憶部の空き容量に基づいて、前記第１の記憶部に格納された前記セッションに関する情報を前記第２の記憶部に格納することを特徴とする請求項２に記載の転送装置。
【請求項４】
前記通信部は、前記第２の制御パケットを前記送信元に送信する場合に、前記第１の制御パケットの着順に基づいて、前記第１の記憶部に格納された前記セッションに関する情報を前記第２の記憶部に格納することを特徴とする請求項２に記載の転送装置。
【請求項５】
前記通信部は、前記第２の制御パケットを前記送信元に送信する場合に、前記送信元による前記セッションの生成回数に基づいて、前記第１の記憶部に格納された前記セッションに関する情報を前記第２の記憶部に格納することを特徴とする請求項２に記載の転送装置。
【請求項６】
前記通信部は、前記セッション中に前記送信元から受信された前記パケットを前記宛先に送信する場合に、前記第１の記憶部に格納された前記セッションに関する情報を前記第２の記憶部に格納することを特徴とする請求項１に記載の転送装置。
【請求項７】
前記通信部は、前記セッションの生成後、前記送信元から最初に受信された前記パケットを前記宛先に送信する場合に、前記第１の記憶部に格納された前記セッションに関する情報を前記第２の記憶部に格納すべきか否かを判定し、格納すべきであると判定された場合に、前記第１の記憶部に格納された前記セッションに関する情報を前記第２の記憶部に格納することを特徴とする請求項６に記載の転送装置。
【請求項８】
前記通信部は、前記セッション中に前記送信元から受信された前記パケットを前記宛先に送信する場合に、前記第２の記憶部の空き容量に基づいて、前記第１の記憶部に格納された前記セッションに関する情報を前記第２の記憶部に格納すべきか否かを判定し、格納すべきであると判定された場合に、前記第１の記憶部に格納された前記セッションに関する情報を前記第２の記憶部に格納することを特徴とする請求項６に記載の転送装置。
【請求項９】
前記通信部は、前記パケットを前記宛先に送信する場合に、前記セッション中に前記送信元から受信された前記パケットの着順に基づいて、前記第１の記憶部に格納された前記セッションに関する情報を前記第２の記憶部に格納すべきか否かを判定し、格納すべきであると判定された場合に、前記第１の記憶部に格納された前記セッションに関する情報を前記第２の記憶部に格納することを特徴とする請求項６に記載の転送装置。
【請求項１０】
前記通信部は、前記セッション中に前記送信元から受信された前記パケットを前記宛先に送信する場合に、前記セッション中の前記送信元からの受信回数に基づいて、前記第１の記憶部に格納された前記セッションに関する情報を前記第２の記憶部に格納することを特徴とする請求項６に記載の転送装置。
【請求項１１】
通信部により、宛先とのセッションを要求する第１の制御パケットを送信元から受信する受信工程と、
前記受信工程によって前記第１の制御パケットが前記送信元から受信された場合に、前記送信元と前記宛先との前記セッションに関する情報を生成して、第１の記憶部に格納する生成工程と、
前記通信部により、前記生成工程によって前記セッションが生成されたことを示す第２の制御パケットを前記送信元に送信する送信工程と、
前記第１の記憶部に記憶された前記セッションに関する情報を参照して、前記送信元と前記宛先との間の前記セッション中の通信を制御する第１の制御工程と、
前記通信部により、前記第１の制御工程による制御にしたがって前記セッション中における前記送信元と前記宛先との間のパケットを送受信する通信工程と、
前記通信部により、前記第１の記憶部に格納された前記セッションに関する情報を、前記通信部がアクセス可能な第２の記憶部に格納する格納工程と、
前記セッション中に前記通信工程によって前記送信元または前記宛先から前記パケットが受信された場合に、前記通信部により、前記第２の記憶部に格納された前記セッションに関する情報を参照して、前記第１の制御工程の替わりに前記セッション中の通信を制御する第２の制御工程と、
を含むことを特徴とする転送方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、パケットを転送する転送装置および転送方法に関する。
【背景技術】
【０００２】
従来の転送装置は、通信しあう装置間のセッション情報を保持しておき、送信元からのパケットをインターフェースで受信して、後段の処理部でセッション情報を参照してヘッダを変換し、インターフェースを介して宛先にパケットを送信する。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２００５−２８６４５７号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
しかしながら、上述した従来の転送装置では、通信しあう装置間のセッション情報は、転送装置内のインターフェースの後段に格納されているため、受信したパケットのヘッダを変換する場合、インターフェースの後段の処理部にパケットを転送しなければならない。また、従来の転送装置は、後段の処理部で変換されたパケットを宛先に送信するためにインターフェースに転送しなければならない。このように、インターフェースと後段の処理部との間のパケット転送がパケットごとに必要になるため、転送装置内のデータ転送量が増加し、データ転送性能に影響が生じる。
【０００５】
本発明は、転送効率の向上を図ることを目的とする。
【課題を解決するための手段】
【０００６】
本願において開示される発明の一側面となる転送装置および転送方法は、宛先とのセッションを要求する第１の制御パケットが送信元から受信された場合に、前記送信元と前記宛先との前記セッションに関する情報を生成して、第１の記憶部に格納し、前記第１の記憶部に記憶された前記セッションに関する情報を参照して、前記送信元と前記宛先との間の前記セッション中の通信を制御し、前記送信元から前記第１の制御パケットを受信し、前記セッションが生成されたことを示す第２の制御パケットを前記送信元に送信するとともに、前記制御部による制御にしたがって前記セッション中における前記送信元と前記宛先との間のパケットを送受信する通信処理と、前記第１の記憶部に格納された前記セッションに関する情報を、前記通信部がアクセス可能な第２の記憶部に格納するとともに、前記セッション中に前記通信部によって前記送信元または前記宛先から前記パケットが受信された場合に、前記第２の記憶部に格納された前記セッションに関する情報を参照して、前記制御部の替わりに前記セッション中の通信を制御する制御処理と、を実行する。
【発明の効果】
【０００７】
本発明の代表的な実施の形態によれば、転送効率の向上を図ることができる。前述した以外の課題、構成及び効果は、以下の実施例の説明により明らかにされる。
【図面の簡単な説明】
【０００８】
【図１】実施例１にかかるネットワーク構成例を示す説明図である。
【図２】実施例１にかかる転送装置によるパケット転送例を示す説明図である。
【図３】ＡＰＮ−ＰＤＮ対応テーブルの記憶内容例を示す説明図である。
【図４】ＰＤＮ−ＶＬＡＮ対応テーブルの記憶内容例を示す説明図である。
【図５】パケットのフォーマット例を示す説明図である。
【図６】セッション情報の一例を示す説明図である。
【図７】実施例１にかかるセッション生成シーケンス例を示すシーケンス図である。
【図８】端末からＰＤＮ内のサーバへの転送の際のユーザプレーンパケットの変換例を示す説明図である。
【図９】ＰＤＮ内のサーバから端末への転送の際のユーザプレーンパケットの変換例を示す説明図である。
【図１０】実施例１にかかるユーザプレーンパケットの転送シーケンス例を示すシーケンス図である。
【図１１】セッション削除シーケンス例を示すシーケンス図である。
【図１２】ＮＩＦの転送処理手順例を示すフローチャートである。
【図１３】図１２に示した制御プレーン処理の詳細な処理手順例を示すフローチャートである。
【図１４】図１２に示したユーザプレーン処理の詳細な処理手順例を示すフローチャートである。
【図１５】実施例２にかかる転送装置によるパケット転送例を示す説明図である。
【図１６】実施例２にかかるセッション生成シーケンス例を示すシーケンス図である。
【図１７】実施例２にかかるユーザプレーンパケットの転送シーケンス例を示すシーケンス図である。
【図１８】実施例３にかかる転送装置によるパケット転送例を示す説明図である。
【図１９】実施例３にかかる判定テーブルの記憶内容の一例を示す説明図である。
【図２０】実施例３にかかる判定テーブルの記憶内容の他の例を示す説明図である。
【図２１】実施例３にかかるセッション生成シーケンス例を示すシーケンス図である。
【図２２】図２１のステップＳ２１００に示したＮＩＦによるキャッシュ要否判定処理手順の一例を示すフローチャートである。
【図２３】図２１のステップＳ２１００に示したＮＩＦによるキャッシュ要否判定処理手順の他の例を示すフローチャートである。
【図２４】ＮＩＦによるセッション情報の消去処理手順例を示すフローチャートである。
【図２５】実施例４にかかる転送装置によるパケット転送例を示す説明図である。
【図２６】実施例４にかかる判定テーブルの記憶内容の他の例を示す説明図である。
【図２７】実施例４にかかる判定テーブルの記憶内容の一例を示す説明図である。
【図２８】実施例４にかかるユーザプレーンパケットの転送シーケンス例を示すシーケンス図である。
【図２９】図２８のステップＳ２８００に示したＮＩＦによるキャッシュ要否判定処理手順の一例を示すフローチャートである。
【図３０】図２８のステップＳ２８００に示したＮＩＦによるキャッシュ要否判定処理手順の他の例を示すフローチャートである。
【発明を実施するための形態】
【０００９】
（実施例１）
まず、本発明の実施例１について図１〜図１４を用いて説明する。実施例１では、ＬＴＥ（Ｌｏｎｇ  Ｔｅｒｍ  Ｅｖｏｌｕｔｉｏｎ）を例に挙げて説明する。具体的には、実施例１では、パケット通信において、接続ごとにＣ−Ｐｌａｎｅ（以下、制御プレーン）により、ユーザパケットを転送するためのトンネルであるＧＴＰ（Ｇｅｎｅｒａｌ  ｐａｃｋｅｔ  ｒａｄｉｏ  ｓｅｒｖｉｃｅ  Ｔｕｎｎｅｌｉｎｇ  Ｐｒｏｔｏｃｏｌ）トンネルが構築される。そして、無線ネットワークを経由してＧＴＰトンネルを用いてユーザパケットの送受信がおこなわれる。なお、本発明の適用範囲は、ＬＴＥに限られない。
【００１０】
＜ネットワーク構成例＞
図１は、実施例１にかかるネットワーク構成例を示す説明図である。ネットワーク１００において、端末ｔ１〜ｔ４は、無線通信により基地局と接続される。端末ｔ１〜ｔ４は、たとえば、携帯電話機やスマートフォン、タブレット、ゲーム機、ノード型パソコン、カーナビゲーション装置などである。
【００１１】
基地局１０１は、無線通信により端末ｔ１〜ｔ４と接続される。また、基地局１０１は、Ｓ−ＧＷ（Ｓｅｒｖｉｎｇ  Ｇａｔｅｗａｙ）１０３にも接続され、端末ｔ１〜ｔ４とＳ−ＧＷ１０２間の通信を中継する。Ｓ−ＧＷ１０２は、端末ｔ１〜ｔ４からのユーザデータを中継したり、ＰＤＮ（Ｐｕｂｌｉｃ  Ｄａｔａ  Ｎｅｔｗｏｒｋ。公衆データ網）ｐ１〜ｐ４内のサーバからのデータを中継するノードである。ＭＭＥ（Ｍｏｂｉｌｉｔｙ  Ｍａｎａｇｅｍｅｎｔ  Ｅｎｔｉｔｙ）１０３は、端末ｔ１〜ｔ４の位置登録や呼び出し、基地局１０１間のハンドオーバといったモビリティ管理をおこなうノードである。
【００１２】
Ｐ−ＧＷ（ＰＤＮ  Ｇａｔｅｗａｙ）１０４は、Ｓ−ＧＷ１０２とＰＤＮｐ１〜ｐ４との間を中継するノードである。実施例１の転送装置は、Ｐ−ＧＷ１０４に相当する。以下、転送装置にも符号１０４を付す。ＰＤＮｐ１〜ｐ４は、端末ｔ１〜ｔ４と通信するサーバを有する通信網である。サーバとしては、たとえば、ウェブサーバや、ファイルサーバ、データベースサーバ、アプリケーションサーバなどがある。なお、図１に示した各構成の個数は一例であり、その個数に限られない。
【００１３】
＜転送装置１０４の構成例＞
図２は、実施例１にかかる転送装置１０４によるパケット転送例を示す説明図である。転送装置１０４は、ＮＩＦ（Ｎｅｔｗｏｒｋ  Ｉｎｔｅｒｆｓｃｃｅ）２０１と、ＣＳＷ（Ｃｒｏｓｓ  ｂａｒ  ＳＷｉｔｃｈ）２０３と、第１のセッション関連パケット処理部（以下、ＳＭＣ−Ｃ（Ｓｅｒｖｉｃｅ  Ｍｏｊｕｌｅ  Ｃｏｎｔｒｏｌ−Ｃｏｎｔｒｏｌ）とする。）２０４と、第２のセッション関連パケット処理部（以下、ＳＭＣ−Ｕ（Ｓｅｒｖｉｃｅ  Ｍｏｊｕｌｅ  Ｃｏｎｔｒｏｌ−Ｕｓｅｒ）とする。）２０５と、メモリ２０６と、を有する。
【００１４】
ＮＩＦ２０１は、パケットを受信したり、パケットを送信する通信インターフェースである。ＮＩＦ２０１は、プロセッサ（不図示）とメモリ２１０とインターフェース（不図示）を有し、パケットの解析も行う。ＣＳＷ２０３は、転送装置１０４内部のパケットの転送経路を網羅するスイッチである。
【００１５】
ＳＭＣ−Ｃ２０４は、制御プレーン（Ｃ−Ｐｌａｎｅ）パケットと呼ばれる制御パケットにより、セッション情報を生成するモジュールである。ＳＭＣ−Ｕ２０５は、ユーザプレーン（Ｕ−Ｐｌａｎｅ）パケットと呼ばれるパケットの転送を制御するモジュールである。ＳＭＣ−Ｃ２０４およびＳＭＣ−Ｕ２０５はそれぞれ、プロセッサ（不図示）とメモリ２０６とインターフェース（不図示）を有する。
【００１６】
メモリ２０６は、端末ｔ１〜ｔ４とＰＤＮｐ１〜ｐ４内のサーバとのセッションを規定するセッション情報Ｓを記憶する記憶装置である。図１では、便宜上ＳＭＣ−Ｃ２０４とＳＭＣ−Ｕ２０５とは別装置として描いたが、同一装置でもよい。また、メモリ２０６は、ＳＭＣ−Ｃ２０４およびＳＭＣ−Ｕ２０５が有するメモリに相当する。
【００１７】
つぎに、図２を用いて転送装置１０４の転送処理について説明する。（Ａ）は制御プレーンパケットの転送処理を示す。転送装置１０４は、ＮＩＦ２０１によりセッションの要求元から、制御プレーンパケットであるセッション生成リクエストＲＥＱを受信する。セッション生成リクエストＲＥＱは、ＣＳＷ２０３を経由してＳＭＣ−Ｃ２０４に渡される。ＳＭＣ−Ｃ２０４は、要求元に対しＣ−Ｐｌａｎｅ  ＴＥＩＤ（Ｔｕｎｎｅｌ  Ｅｎｄｐｏｉｎｔ  ＩＤｅｎｔｉｆｉｅｒ）を付与する。Ｃ−Ｐｌａｎｅ  ＴＥＩＤとは、制御プレーンにより、接続ごとに決められるＧＴＰトンネルの識別子である。ＳＭＣ−Ｃ２０４は、セッション生成リクエストＲＥＱの応答であるセッション生成レスポンスＲＥＳにＣ−Ｐｌａｎｅ  ＴＥＩＤを埋め込む。
【００１８】
また、ＳＭＣ−Ｕ２０５は、セッション生成リクエストＲＥＱの応答であるセッション生成レスポンスＲＥＳにＵ−Ｐｌａｎｅ  ＴＥＩＤを埋め込む。Ｕ−Ｐｌａｎｅ  ＴＥＩＤは、ユーザプレーンパケットを通信する際に、ＧＴＰトンネルを用いる送信元を特定するための識別情報である。ＳＭＣ−Ｕ２０５は、セッション生成リクエストＲＥＱにＵ−Ｐｌａｎｅ  ＴＥＩＤを埋め込む。これにより、ＳＭＣ−Ｕ２０５は、セッション情報Ｓをメモリ２０６に格納する。転送装置１０４は、Ｃ−Ｐｌａｎｅ  ＴＥＩＤおよびＵ−Ｐｌａｎｅ  ＴＥＩＤが埋め込まれたセッション生成リクエストＲＥＱを、セッション生成レスポンスＲＥＳとして、要求元端末に送信する。また、転送装置１０４は、メモリ２０６に格納されたセッション情報Ｓを、ＮＩＦ２０１のメモリ２１０にキャッシュする。
【００１９】
（Ｂ）は、（Ａ）の次状態を示す。転送装置１０４は、ユーザプレーンパケット２２０を受信すると、（Ａ）においてＮＩＦ２０１のメモリ２１０にキャッシュされたセッション情報Ｓを参照して、ＮＩＦ２０１によりユーザプレーンパケット２２０のヘッダを変換する。そして、ＮＩＦ２０１は、ヘッダを変換したユーザプレーンパケット２３０を、ＳＭＣ−Ｕを介さずに宛先に転送する。
【００２０】
これにより、ユーザプレーンの場合、本来ＳＭＣ−Ｕ２０５において行われたヘッダの変換処理を、ＮＩＦ２０１が代理で実行することができる。したがって、ＮＩＦ２０１からＳＭＣ−Ｕ２０５へのパケット転送およびＳＭＣ−Ｕ２０５からＮＩＦ２０１へのパケット転送をおこなう必要がなくなり、パケット転送の高速化を図ることができ、転送性能の向上を図ることができる。なお、図２のメモリ２０６を第１の記憶装置とし、メモリ２１０を第２の記憶装置とする。
【００２１】
図３は、ＡＰＮ−ＰＤＮ対応テーブルの記憶内容例を示す説明図である。ＡＰＮ−ＰＤＮ対応テーブル３００は、ＡＰＮ（Ａｃｃｅｓｓ  Ｐｏｉｎｔ  Ｎａｍｅ）とＰＤＮｐ１〜ｐ４との対応関係を規定するテーブルである。ＡＰＮ−ＰＤＮ対応テーブル３００は、メモリ２０６に格納される。ＡＰＮとは、パケット通信を行う際に必要となる接続先を指定する識別情報である。具体的には、たとえば、宛先が提供するウェブサービス、検索、データベース、アプリケーション、ファイル転送などのサービスを指定する識別情報である。ＡＰＮ−ＰＤＮ対応テーブル３００は、ＡＰＮ項目とＰＤＮ項目を有する。ＡＰＮ項目には、ＡＰＮが格納される。ＰＤＮ項目には、ＰＤＮを特定する識別子が格納される。
【００２２】
たとえば、ＡＰＮ−ＰＤＮ対応テーブル３００の１行目のレコードにおいて、ＡＰＮ＝ａ１がウェブサービスである場合、対応するＰＤＮ＝ｐ１，ｐ１１，ｐ２１は、ウェブサービスをおこなうネットワークであり、ＰＤＮ＝ｐ１，ｐ１１，ｐ２１内のサーバは、ウェブサーバを含む。
【００２３】
図４は、ＰＤＮ−ＶＬＡＮ対応テーブルの記憶内容例を示す説明図である。ＰＤＮ−ＶＬＡＮ対応テーブル４００は、ＰＤＮとＶＬＡＮ（Ｖｉｒｔｕａｌ  ＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ））との対応関係を規定するテーブルである。ＰＤＮ−ＶＬＡＮ対応テーブル４００は、メモリ２０６に格納される。ＰＤＮ項目には、ＰＤＮを特定する識別情報が格納される。ＶＬＡＮ項目には、ＶＬＡＮを特定する識別情報が格納される。たとえば、ＰＤＮ−ＶＬＡＮ対応テーブル４００の１行目のレコードにおいて、ＰＤＮ＝ａ１は、ＶＬＡＮ＝ｖ１となる通信網である。
【００２４】
図５は、パケットのフォーマット例を示す説明図である。パケット５００は、ヘッダ５０１とペイロード５０２を有する。ヘッダ５０１において、パケット５００の第１階層（物理層）Ｌ１および第２階層（データリンク層）Ｌ２はイーサネットヘッダ（イーサネットは登録商標、以下同じ）、第３階層（ネットワーク層）Ｌ３はＩＰ（Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ）ヘッダ、第４階層（トランスポート層）Ｌ４はＵＤＰ（Ｕｓｅｒ  Ｄａｔａｇｒａｍ  Ｐｒｏｔｏｃｏｌ）ヘッダである。ＵＤＰヘッダには、そのパケット５００が制御プレーンパケットであるかユーザプレーンパケットであるかを特定する情報（たとえば、ポート番号）が格納される。また、第５階層Ｌ５〜第７階層Ｌ７には、ＧＴＰヘッダが規定される。ＧＴＰヘッダには、Ｃ−Ｐｌａｎｅ  ＴＥＩＤとＵ−Ｐｌａｎｅ  ＴＥＩＤが格納される。
【００２５】
＜セッション情報Ｓ＞
図６は、セッション情報Ｓの一例を示す説明図である。セッション情報Ｓは、転送装置１０４が制御プレーンのセッション生成リクエストＲＥＱを受信してからセッション生成レスポンスＲＥＳを返信するまでの間に、転送装置１０４が生成する。
【００２６】
（Ａ）は、セッション情報Ｓの初期状態を示す。セッション情報Ｓは、端末識別情報項目と、ＩＰアドレス項目と、ＡＰＮ項目と、ＰＤＮ項目と、ＶＬＡＮ項目と、Ｃ−Ｐｌａｎｅ  ＴＥＩＤ項目と、Ｕ−Ｐｌａｎｅ  ＴＥＩＤ項目と、を有する。
【００２７】
端末識別情報項目には、端末識別情報が格納される。端末識別情報とは、端末ｔ１〜ｔ４を一意に特定する情報であり、たとえば、ＩＭＳＩ（Ｉｎｔｅｒｎａｔｉｏｎａｌ  Ｍｏｂｉｌｅ  Ｓｕｂｓｃｒｉｂｅｒ  Ｉｄｅｎｔｉｔｙ）などの端末識別子が採用される。端末識別情報は、端末ｔ１〜ｔ４において制御プレーンであるセッション生成リクエストＲＥＱに埋め込まれ、転送装置１０４に送信される。ＩＰアドレス項目には、セッション生成リクエストＲＥＱの送信元となる端末ｔ１〜ｔ４のＩＰアドレスが格納される。
【００２８】
ＡＰＮ項目には、ＡＰＮが格納される。ＡＰＮは、端末ｔ１〜ｔ４において制御プレーンであるセッション生成リクエストＲＥＱに埋め込まれ、転送装置１０４に送信される。ＰＤＮ項目には、ＰＤＮの識別情報が格納される。ＰＤＮの識別情報は、ＳＭＣ−Ｃ２０４が、図３に示したＡＰＮ−ＰＤＮ対応テーブル３００を参照して、ＡＰＮに対応するＰＤＮの識別情報を抽出することにより、セッション情報Ｓに設定される。
【００２９】
ＶＬＡＮ項目には、ＶＬＡＮの識別情報が格納される。ＶＬＡＮの識別情報は、ＳＭＣ
−Ｃ２０４が、図４に示したＰＤＮ−ＶＬＡＮ対応テーブル４００を参照して、ＰＤＮの識別情報に対応するＶＬＡＮの識別情報を抽出することにより、セッション情報Ｓに設定される。このＶＬＡＮの識別情報とＩＰアドレスとの組により、端末ｔ１〜ｔ４が一意に特定される。Ｃ-Ｐｌａｎｅ  ＴＥＩＤ項目には、Ｃ-Ｐｌａｎｅ  ＴＥＩＤが格納される。
【００３０】
Ｃ-ＰｌａｎｅＴＥＩＤは、ＳＭＣ−Ｃ２０４が固有の識別情報として割り当てることにより、セッション情報Ｓに設定される。また、Ｃ−Ｐｌａｎｅ  ＴＥＩＤは、ＳＭＣ−Ｃ２０４がセッション生成リクエストＲＥＱの応答であるセッション生成レスポンスＲＥＳに埋め込まれる。Ｕ−Ｐｌａｎｅ  ＴＥＩＤ項目には、Ｕ−Ｐｌａｎｅ  ＴＥＩＤが格納される。Ｕ−ＰｌａｎｅＴＥＩＤは、ＣＭＣ−Ｕが固有の識別情報として割り当てることにより、セッション情報Ｓに設定される。また、Ｕ−ＰｌａｎｅＴＥＩＤは、ＣＭＣ−Ｕがセッション生成リクエストＲＥＱに埋め込まれる。
【００３１】
（Ｂ）は、端末ｔ１から転送装置１０４に送信されるセッション生成リクエストＲＥＱにおけるセッション情報Ｓである。端末ｔ１からの送信時では、端末識別情報：ｔ１とＡＰＮ：ａ１がセッション生成リクエストＲＥＱに埋め込まれて、転送装置１０４に送信される。（Ｃ）は、転送装置１０４から端末ｔ１に送信されるセッション生成レスポンスＲＥＳにおけるセッション情報Ｓである。転送装置１０４からの送信時では、端末識別情報：ｔ１、ＡＰＮ：ａ１、ＶＬＡＮの識別情報：ｖ１、Ｃ−Ｐｌａｎｅ  ＴＥＩＤ：ｃ１、およびＵ−Ｐｌａｎｅ  ＴＥＩＤ：ｕ１が、セッション情報Ｓに設定される。ＰＤＮの識別情報：ｐ１が設定されてもよい。Ｃ−Ｐｌａｎｅ  ＴＥＩＤ：ｃ１およびＵ−Ｐｌａｎｅ  ＴＥＩＤ：ｕ１は、セッション生成レスポンスＲＥＳに埋め込まれて、端末ｔ１に送信される。
【００３２】
＜セッション生成シーケンス＞
図７は、実施例１にかかるセッション生成シーケンス例を示すシーケンス図である。Ｓ−ＧＷ１０２は、ある端末からセッション生成リクエストＲＥＱを受信すると、セッション生成リクエストＲＥＱを転送装置１０４に転送する（ステップＳ７０１）。セッション生成リクエストＲＥＱには、ＡＰＮとＩＭＳＩが埋め込まれている。Ｐ−ＧＷ１０４のＮＩＦ２０１は、セッション生成リクエストＲＥＱのＵＤＰヘッダに埋め込まれているポート番号により、受信したパケット５００が制御プレーンパケットかユーザプレーンパケットかを判定する。制御プレーンパケットかユーザプレーンパケットかを判定するためにＧＴＰヘッダ内のメッセージ種別を使用しても良い。ＮＩＦ２０１は、セッション生成リクエストＲＥＱが制御プレーンパケットであると認識し、ＳＭＣ−Ｃ２０４を選択する（ステップＳ７０２）。
【００３３】
ＮＩＦ２０１は、ＣＳＷ２０３を経由して、選択したＳＭＣ−Ｃ２０４にセッション生成リクエストＲＥＱを送信する（ステップＳ７０３）。ＳＭＣ−Ｃ２０４は、セッション生成リクエストＲＥＱを受信すると、ユーザサーチを実行する（ステップＳ７０４）。ユーザサーチでは、ＳＭＣ−Ｃ２０４は、そのユーザの端末についてセッション情報Ｓが存在するか否かを検索する。存在する場合は、転送装置１０４は、存在するリクエストと重複しているセッションの情報を解放し、新規にリクエストに対するセッションを確立する。
【００３４】
存在しない場合、ＳＭＣ−Ｃ２０４は、セッション生成リクエストＲＥＱをＳＭＣ−Ｕ２０５に送信する（ステップＳ７０５）。ＳＭＣ−Ｕ２０５は、セッション生成リクエストＲＥＱを受けると、Ｕ−Ｐｌａｎｅ  ＴＥＩＤを割り当てて、セッション生成リクエストＲＥＱに埋め込む（ステップＳ７０６）。そして、ＳＭＣ−Ｕ２０５は、セッション生成レスポンスＲＥＳとしてＳＭＣ−Ｃ２０４に送信する（ステップＳ７０７）。ＳＭＣ−Ｃ２０４は、セッション生成レスポンスＲＥＳを受けると、Ｃ−Ｐｌａｎｅ  ＴＥＩＤを割り当てて、セッション生成レスポンスＲＥＳに埋め込む（ステップＳ７０８）。また、ＳＭＣ−Ｃ２０４は、ＡＰＮ−ＰＤＮ対応テーブル３００およびＰＤＮ−ＶＬＡＮ対応テーブル４００を参照し、ＰＤＮの識別情報やＶＬＡＮの識別情報も特定してセッション情報Ｓを生成し、セッション情報Ｓをメモリ２０６に格納する（ステップＳ７０９）。
【００３５】
そして、ＳＭＣ−Ｃ２０４は、セッション生成レスポンスＲＥＳをＮＩＦ２０１に送信する（ステップＳ７１０）。このあと、ＮＩＦ２０１は、セッション情報Ｓのキャッシュ処理を実行する（ステップＳ７１１）。キャッシュ処理（ステップＳ７１１）では、ＳＣＭ−Ｃ２０４からＮＩＦ２０１に対してＮＩＦ２０１のメモリ２１０へのセッション情報Ｓの設定を行う（ステップＳ７１２）。ＮＩＦ２０１は、ＳＭＣ−Ｃ２０４からのセッション情報ＳをＮＩＦ２０１のメモリ２１０に格納する（ステップＳ７１３）。
【００３６】
キャッシュ処理（ステップＳ７１１）のあと、ＮＩＦ２０１は、Ｃ−Ｐｌａｎｅ  ＴＥＩＤ，およびＵ−Ｐｌａｎｅ  ＴＥＩＤを含むセッション生成レスポンスＲＥＳを、Ｓ−ＧＷ１０２に送信する（ステップＳ７１４）。このあと、Ｓ−ＧＷ１０２は、セッション生成レスポンスＲＥＳを、ＭＭＥ１０３を介してセッション生成リクエストＲＥＱの送信元となる端末に送信する。
【００３７】
これにより、次回から、セッション生成レスポンスＲＥＳを受けた端末からユーザプレーンパケットが送信されてきた場合、ＮＩＦ２０１は、ＮＩＦ２０１のメモリ２１０からセッション情報Ｓを参照して、宛先へのユーザプレーンパケットに変換することができる。したがって、ＮＩＦ２１０は、ＳＭＣ−Ｕ２０５を介さずにユーザプレーンパケットを転送することができる。したがって、ＳＭＣ−Ｕ２０５とＮＩＦ２０１との間のデータ転送量を抑制することができ、ユーザプレーンパケットの高速転送を実現することができる。
【００３８】
＜ユーザプレーンパケットの変換例＞
図８は、端末ｔ１〜ｔ４からＰＤＮｐ１〜ｐ４内のサーバへの転送の際のユーザプレーンパケットの変換例を示す説明図である。（Ａ）は、端末ｔ１〜ｔ４からの送信時のユーザプレーンパケットを示す。ユーザプレーンパケット８００は、ヘッダ８０１とペイロード８０２とを有する。ヘッダ８０１において、ユーザプレーンパケット８００の第１階層（物理層）Ｌ１および第２階層（データリンク層）Ｌ２は無線プロトコルヘッダ、第３階層（ネットワーク層）Ｌ３はＩＰヘッダである。ＩＰヘッダには、送信元アドレスとして端末のＩＰアドレスが格納され、宛先アドレスとしてサーバのＩＰアドレスが格納される。
【００３９】
（Ｂ）は、Ｓ−ＧＷ１０２からの送信時のユーザプレーンパケット８１０を示す。Ｓ−ＧＷ１０２においてユーザプレーンパケット８００からＬ１、Ｌ２のヘッダを除いたＩＰパケットをヘッダ８０３によりカプセル化したパケットが、ユーザプレーンパケット８１０である。ヘッダ８０３は、例えば、ユーザプレーンパケット８１０の第１階層（物理層）Ｌ１および第２階層（データリンク層）Ｌ２のイーサネットヘッダ、第３階層（ネットワーク層）Ｌ３のＩＰヘッダ、第４階層（トランスポート層）Ｌ４のＵＤＰヘッダ、第５階層〜第７階層のＧＴＰヘッダを有する。
【００４０】
ＯｕｔｅｒのＩＰヘッダには、送信元アドレスとしてＳ−ＧＷ１０２のＩＰアドレスが格納され、宛先アドレスとしてＰ−ＧＷ１０４のＩＰアドレスが格納される。ＵＤＰヘッダには、そのパケットがユーザプレーンパケットであることを特定するポート番号が格納される。また、ＧＴＰヘッダには、端末ｔ１〜ｔ４に割り当てられたＣ−Ｐｌａｎｅ  ＴＥＩＤとＵ−Ｐｌａｎｅ  ＴＥＩＤが格納される。
【００４１】
（Ｃ）は、Ｐ−ＧＷ１０４からの送信時のユーザプレーンパケット８００を示す。Ｐ−ＧＷ１０４から送信されるときは、（Ｂ）のヘッダ８０３がデカプセルされる。また、第２階層Ｌ２のヘッダには、宛先となるサーバが所属するＶＬＡＮの識別情報が格納される。
【００４２】
＜ユーザプレーンパケットの変換例＞
図９は、ＰＤＮｐ１〜ｐ４内のサーバから端末ｔ１〜ｔ４への転送の際のユーザプレーンパケットの変換例を示す説明図である。（Ａ）は、サーバからの送信時のユーザプレーンパケット９００を示す。ユーザプレーンパケット９００は、ヘッダ９０１とペイロード９０２とを有する。ヘッダ９０１において、ユーザプレーンパケット９００の第１階層（物理層）Ｌ１および第２階層（データリンク層）Ｌ２は例えばイーサネットヘッダ、第３階層（ネットワーク層）Ｌ３はＩＰヘッダである。第２階層Ｌ２のイーサネットヘッダには、送信元となるサーバが所属するＶＬＡＮの識別情報が格納される。ＩＰヘッダには、送信元アドレスとしてサーバのＩＰアドレスが格納され、宛先アドレスとして端末のＩＰアドレスが格納される。
【００４３】
（Ｂ）は、Ｐ−ＧＷ１０４からの送信時のユーザプレーンパケット９１０を示す。Ｓ−ＧＷ１０２においてユーザプレーンパケット９００からＬ１、Ｌ２のヘッダを除いたＩＰパケットをヘッダ９０３によりカプセル化したパケットが、ユーザプレーンパケット９１０である。ヘッダ９０３は、例えば、パケットの第１階層（物理層）Ｌ１および第２階層（データリンク層）Ｌ２のイーサネットヘッダ、第３階層（ネットワーク層）Ｌ３のＩＰヘッダ、第４階層（トランスポート層）Ｌ４のＵＤＰヘッダ、第５階層〜第７階層のＧＴＰヘッダを有する。
【００４４】
ＯｕｔｅｒのＩＰヘッダには、送信元アドレスとしてＰ−ＧＷ１０４のＩＰアドレスが格納され、宛先アドレスとしてＳ−ＧＷ１０２のＩＰアドレスが格納される。ＵＤＰヘッダには、そのパケットがユーザプレーンパケットであることを特定するポート番号が格納される。また、ＧＴＰヘッダには、端末ｔ１〜ｔ４のセッションに割り当てられたＣ−Ｐｌａｎｅ  ＴＥＩＤとＵ−Ｐｌａｎｅ  ＴＥＩＤが格納される。
【００４５】
（Ｃ）は、Ｓ−ＧＷ１０２からの送信時のユーザプレーンパケット９００を示す。Ｓ−ＧＷ１０２から端末ｔ１〜ｔ４に送信されるときは、（Ｂ）のヘッダ９０３がデカプセルされ、Ｌ１、Ｌ２には無線プロトコルのヘッダが付与され、送信される。
【００４６】
＜転送シーケンス＞
図１０は、実施例１にかかるユーザプレーンパケットの転送シーケンス例を示すシーケンス図である。まず、ある端末からＰＤＮｐ１〜ｐ４内のサーバへのユーザプレーンパケットの転送シーケンス例について説明する。図７のステップＳ７１５においてセッション生成レスポンスＲＥＳを受けた端末が、図８の（Ａ）に示したようなユーザプレーンパケット８００をサーバ宛に送信する（ステップＳ１００１）。Ｓ−ＧＷ１０２は、端末から基地局１０１を介して受信したユーザプレーンパケット８００の変換処理を実行する（ステップＳ１００２）。具体的には、たとえば、Ｓ−ＧＷ１０２は、図８の（Ａ）のＳ−ＧＷ１０２と基地局１０１間の転送プロトコルをデカプセルし、ユーザプレーンパケット８００をカプセル化して、図８の（Ｂ）のユーザプレーンパケット８１０に変換する。
【００４７】
そして、Ｓ−ＧＷ１０２は、変換したユーザプレーンパケット８１０を、その宛先となるＰ−ＧＷ１０４に送信する（ステップＳ１００３）。Ｐ−ＧＷ１０４のＮＩＦ２０１は、Ｓ−ＧＷ１０２からユーザプレーンパケット８１０を受信すると、ユーザプレーンパケット８１０の変換処理を実行する（ステップＳ１００４）。具体的には、たとえば、ＮＩＦ２０１は、ＮＩＦ２０１のメモリ２１０にキャッシュされたセッション情報Ｓを用いて、図８の（Ｂ）のユーザプレーンパケット８１０をデカプセル化して、図８の（Ｃ）のユーザプレーンパケット８００に変換する。そして、ＮＩＦ２０１は、変換したユーザプレーンパケット８００を、その宛先となるサーバに送信する（ステップＳ１００５）。
【００４８】
つぎに、サーバから端末へのユーザプレーンパケットの転送シーケンス例について説明する。サーバは、図９の（Ａ）に示したようなユーザプレーンパケット９００を端末宛に送信する（ステップＳ１００６）。Ｐ−ＧＷ１０４のＮＩＦ２０１は、サーバからのユーザプレーンパケット９００の変換処理を実行する（ステップＳ１００７）。具体的には、たとえば、ＮＩＦ２０１は、ＮＩＦ２０１のメモリ２１０にキャッシュされたセッション情報Ｓを用いて、図９の（Ａ）のユーザプレーンパケット９００をカプセル化して、図９の（Ｂ）のユーザプレーンパケット９１０に変換する。
【００４９】
そして、ＮＩＦ２０１は、変換したユーザプレーンパケット９１０を、その宛先となるＳ−ＧＷ１０２に送信する（ステップＳ１００８）。Ｓ−ＧＷ１０２は、Ｐ−ＧＷ１０４のＮＩＦ２０１からユーザプレーンパケット９１０を受信すると、ユーザプレーンパケット９１０の変換処理を実行する（ステップＳ１００９）。具体的には、たとえば、Ｓ−ＧＷ１０２は、図９の（Ｂ）のユーザプレーンパケット９１０をデカプセル化して、図９の（Ｃ）のユーザプレーンパケット９００に変換する。そして、Ｓ−ＧＷ１０２は、変換したユーザプレーンパケット９００を、その宛先となる端末に送信する（ステップＳ１０１０）。このように、転送装置１０４での転送処理は、前段のＮＩＦ２０１により実行されるため、内部のＳＭＣ−Ｕ２０５と転送する必要がなくなる。したがって、転送処理の高速化を図ることができる。
【００５０】
＜セッション削除シーケンス＞
図１１は、セッション削除シーケンス例を示すシーケンス図である。まず、Ｓ−ＧＷ１０２が、端末からのセッション削除リクエストをＰ−ＧＷ１０４のＮＩＦ２０１に転送する（ステップＳ１１０１）。つぎに、ＮＩＦ２０１が、Ｓ−ＧＷ１０２からのセッション削除リクエストを受信して、ポート番号から制御プレーンパケットと認識して、ＳＭＣ−Ｃ２０４を選択する（ステップＳ１１０２）。制御プレーンパケットの識別にＧＴＰヘッダ内のメッセージ種別を使用しても良い。そして、ＮＩＦ２０１は、セッション削除リクエストをＳＭＣ−Ｃ２０４に転送する（ステップＳ１１０３）。
【００５１】
ＳＭＣ−Ｃ２０４は、セッション削除リクエストを受信すると、ユーザサーチを実行する（ステップＳ１１０４）。ユーザサーチでは、ＳＭＣ−Ｃ２０４は、そのユーザの端末についてセッション情報Ｓが存在するか否かを検索する。存在しない場合は、転送装置１０４は、その旨のレスポンスを端末に返すことになる。
【００５２】
存在する場合、ＳＭＣ−Ｃ２０４は、セッション削除リクエストをＳＭＣ−Ｕ２０５に送信する（ステップＳ１１０５）。ＳＭＣ−Ｕ２０５は、セッション削除リクエストを受信すると、Ｕ−Ｐｌａｎｅ  ＴＥＩＤを手掛かりとしてメモリ２０６内のセッション情報Ｓを特定し、メモリ２０６から削除する（ステップＳ１１０６）。そして、ＳＭＣ−Ｕ２０５は、セッション削除レスポンスをＳＭＣ−Ｃ２０４に返す（ステップＳ１１０７）。
【００５３】
ＳＭＣ−Ｃ２０４は、ＳＭＣ−Ｕ２０５からセッション削除レスポンスを受けると、ＮＩＦ２０１に転送する（ステップＳ１１０８）。ＮＩＦ２０１は、セッション削除レスポンスを受けると、Ｕ−Ｐｌａｎｅ  ＴＥＩＤを手掛かりとしてＮＩＦ２０１のメモリ内のセッション情報Ｓを特定し、メモリから削除する（ステップＳ１１０９）。そして、ＮＩＦ２０１は、セッション削除レスポンスを、Ｓ−ＧＷ１０２を経由して端末に送信する（ステップＳ１１１０）。これにより、セッションが終了したセッション情報Ｓをメモリ２０６から削除することができる。特に、ＮＩＦ２０１のメモリ２１０からセッション情報Ｓを削除することができるため、ＮＩＦ２０１の省メモリ化を図ることができる。
【００５４】
また、ＮＩＦ２０１は、メモリ２１０の空き容量が所定値以下になった場合に、メモリ２１０に最古にキャッシュされたセッション情報Ｓから順次消去することとしてもよい。また、ＮＩＦ２０１は、セッション情報Ｓごとに、キャッシュされてからのライフタイムを設定しておき、メモリ２１０内のライフタイムを満了したセッション情報Ｓから順次消去することとしてもよい。これにより、メモリ２１０のリソース不足の抑制を図ることができる。
【００５５】
＜ＮＩＦ２０１の転送処理手順例＞
図１２は、ＮＩＦ２０１の転送処理手順例を示すフローチャートである。まず、ＮＩＦ２０１は、パケット５００を受信するのを待ち受け（ステップＳ１２０１：Ｎｏ）、パケットを受信した場合（ステップＳ１２０１：Ｙｅｓ）、ＮＩＦ２０１は、パケット５００の種別を特定する（ステップＳ１２０２）。パケット５００の種別が制御プレーンである場合（ステップＳ１２０２：Ｃ−Ｐｌａｎｅ）、ＮＩＦ２０１は制御プレーン処理を実行する（ステップＳ１２０３）。制御プレーン処理（ステップＳ１２０３）の詳細については図１３で後述するが、制御プレーン処理（ステップＳ１２０３）では、ＮＩＦ２０１はセッション情報Ｓの生成と削除を実行する。
【００５６】
一方、ステップＳ１２０２において、パケット５００の種別がユーザプレーンである場合（ステップＳ１２０２：Ｕ−Ｐｌａｎｅ）、ＮＩＦ２０１はユーザプレーン処理を実行する（ステップＳ１２０４）。ユーザプレーン処理（ステップＳ１２０４）の詳細については図１４で後述するが、ユーザプレーン処理（ステップＳ１２０４）では、ＮＩＦ２０１はユーザプレーンパケットの転送を実行する。
【００５７】
図１３は、図１２に示した制御プレーン処理（ステップＳ１２０３）の詳細な処理手順例を示すフローチャートである。まず、ＮＩＦ２０１は、パケット５００にＣ−Ｐｌａｎｅ  ＴＥＩＤがあるか否かを判断する（ステップＳ１３０１）。Ｃ−Ｐｌａｎｅ  ＴＥＩＤがある場合（ステップＳ１３０１：Ｙｅｓ）、ＮＩＦ２０１は、該当のＣ−Ｐｌａｎｅ  ＴＥＩＤを管理しているＳＭＣ−Ｃ２０４に、受信したパケット５００を転送する。ＳＭＣ−Ｃ２０４は、受信したパケット５００内に設定された生成または削除を示す識別子により、受信したパケット５００が、端末からのセッション生成リクエストＲＥＱであるかセッション削除リクエストであるかを判断する（ステップＳ１３０２）。
【００５８】
セッション生成リクエストＲＥＱであると判断された場合（ステップＳ１３０２：生成）、ＮＩＦ２０１は、セッション情報Ｓのキャッシュ処理を実行する（ステップＳ１３０３）。キャッシュ処理（ステップＳ１３０３）は、図７のステップＳ７１１に示した処理である。そして、ＮＩＦ２０１は、セッション生成レスポンスＲＥＳをＳ−ＧＷ１０２を経由して端末に送信する（ステップＳ１３０４）。
【００５９】
一方、ステップＳ１３０２において、セッション削除リクエストであると判断された場合（ステップＳ１３０２：Ｙｅｓ）、ＮＩＦ２０１は、図１１のステップＳ１１０２、Ｓ１１０３に示したように、ＳＭＣ−Ｃ２０４を選択して、ＳＭＣ−Ｃ２０４にセッション削除リクエストを転送する（ステップＳ１３０５）。このあと、図１１のステップＳ１１０７に示したように、ＳＭＣ−Ｃ２０４からセッション削除レスポンスが送信されてくるため、ＮＩＦ２０１は、ステップＳ１１０８で示したようにセッション情報Ｓを削除する（ステップＳ１３０６）。
【００６０】
そして、ＮＩＦ２０１は、セッション削除レスポンスをＳ−ＧＷ１０２を介してセッション削除リクエストを送信した端末に送信する（ステップＳ１３０７）。
【００６１】
また、ステップＳ１３０１において、Ｃ−Ｐｌａｎｅ  ＴＥＩＤがない場合（ステップＳ１３０１：Ｎｏ）、ＮＩＦ２０１は、ＳＭＣ−Ｃ２０４を選択し（ステップＳ１３０８）、選択したＳＭＣ−Ｃ２０４に対し、セッション生成リクエストＲＥＱを転送する（ステップＳ１３０９）。これにより、ＮＩＦ２０１による制御プレーン処理（ステップＳ１２０３）を終了する。
【００６２】
図１４は、図１２に示したユーザプレーン処理（ステップＳ１２０４）の詳細な処理手順例を示すフローチャートである。まず、ＮＩＦ２０１は、ステップＳ１２０２において、パケットの種別がユーザプレーンである場合（ステップＳ１２０２：Ｕ−Ｐｌａｎｅ）、パケットにＵ−Ｐｌａｎｅ  ＴＥＩＤがあるか否かを判断する（ステップＳ１４０１）。Ｕ−Ｐｌａｎｅ  ＴＥＩＤがある場合（ステップＳ１４０１：Ｙｅｓ）、受信したパケットは、図８の（Ｂ）に示したような端末からのユーザプレーンパケット８１０である。したがって、ＮＩＦ２０１は、ＮＩＦ２０１のメモリ２１０に格納されているセッション情報Ｓを抽出する（ステップＳ１４０２）。
【００６３】
そして、ＮＩＦ２０１は、抽出したセッション情報Ｓを参照して、宛先のサーバが所属するＰＤＮおよびＶＬＡＮを特定し（ステップＳ１４０３）、図８の（Ｃ）に示したようにパケット変換を実行する（ステップＳ１４０４）。そして、ＮＩＦ２０１は、変換したユーザプレーンパケット８００を宛先であるサーバに送信する（ステップＳ１４０５）。
【００６４】
また、ステップＳ１４０１において、パケットがＧＴＰのパケットでなく、パケットにＵ−Ｐｌａｎｅ  ＴＥＩＤがない場合（ステップＳ１４０１：Ｎｏ）、受信したパケット５００は、図９の（Ａ）に示したようなサーバからのユーザプレーンパケット９００である。したがって、ＮＩＦ２０１は、ユーザプレーンパケット９００から宛先ＩＰアドレスとＶＬＡＮの識別情報を取得する（ステップＳ１４０６）。そして、ＮＩＦ２０１は、取得した宛先ＩＰアドレスおよびＶＬＡＮの識別情報と一致するセッション情報Ｓを、ＮＩＦ２０１のメモリ２１０に格納されているセッション情報群を検索する（ステップＳ１４０７）。
【００６５】
このあと、ＮＩＦ２０１は、検索されたセッション情報Ｓを参照して、図９の（Ｂ）に示したようにユーザプレーンパケット９００を変換して（ステップＳ１４０８）、変換したユーザプレーンパケット９１０を宛先であるＳ−ＧＷ１０２に送信する（ステップＳ１４０５）。このように、転送装置１０４での転送処理は、前段のＮＩＦ２０１により実行されるため、転送装置１０４内部のＳＭＣ−Ｕ２０５と転送する必要がなくなる。したがって、転送処理の高速化を図ることができる。
【００６６】
（実施例２）
つぎに、本発明の実施例２について説明する。実施例２では、実施例１と相違する点について説明し、同一内容については省略する。
【００６７】
実施例１では、転送装置１０４は、制御プレーンパケットによりセッション情報Ｓを生成してＮＩＦ２０１のメモリ２１０に格納する。そして、転送装置１０４は、ユーザプレーンパケットを受信した場合に、ＮＩＦ２０１のメモリ２１０に格納されたセッション情報Ｓにより、ＮＩＦ２０１の後段にまでユーザプレーンパケットを引き込まずに転送する。
【００６８】
これに対し、実施例２では、転送装置１０４は、制御プレーンパケットによりセッション情報Ｓを生成するが、ＮＩＦ２０１のメモリ２１０にはこの時点ではキャッシュせず、ユーザプレーンパケットが受信されたときに、生成済みのセッション情報Ｓを、ＮＩＦ２０１のメモリ２１０にキャッシュする。制御プレーンパケットは、たとえば、端末ｔ１〜ｔ４の電源がＯＮになったのを契機に端末ｔ１〜ｔ４から転送装置１０４に送信される。
【００６９】
したがって、ユーザプレーンパケットが送信されたのを契機にセッション情報ＳをＮＩＦ２０１のメモリ２１０にキャッシュすることで、後続のユーザプレーンパケットについては、転送装置１０４での転送処理は、前段のＮＩＦ２０１により実行されるため、転送装置１０４内部のＳＭＣ−Ｕ２０５と転送する必要がなくなる。したがって、転送処理の高速化を図ることができる。また、ユーザプレーンパケットによる通信がおこなわれるまでの間、ＮＩＦ２０１のメモリにセッション情報Ｓをキャッシュしないため、ＮＩＦ２０１のメモリの使用効率の向上を図ることができる。
【００７０】
＜転送装置１０４の構成例＞
図１５は、実施例２にかかる転送装置１０４によるパケット転送例を示す説明図である。（Ａ）は制御プレーンパケットの転送処理を示す。転送装置１０４は、ＮＩＦ２０１によりセッションの要求元から、制御プレーンパケットであるセッション生成リクエストＲＥＱを受信する。セッション生成リクエストＲＥＱは、ＣＳＷ２０３を経由してＳＭＣ−Ｃ２０４に渡される。ＳＭＣ−Ｃ２０４は、要求元に対しＣ−Ｐｌａｎｅ  ＴＥＩＤを付与する。ＳＭＣ−Ｃ２０４は、セッション情報Ｓをメモリ２０６に格納するとともに、セッション生成リクエストＲＥＱの応答であるセッション生成レスポンスＲＥＳにＣ−Ｐｌａｎｅ  ＴＥＩＤを埋め込む。
【００７１】
また、ＳＭＣ−Ｕ２０５は、セッション生成リクエストＲＥＱの応答であるセッション生成レスポンスＲＥＳにＵ−Ｐｌａｎｅ  ＴＥＩＤを埋め込む。転送装置１０４は、Ｃ−Ｐｌａｎｅ  ＴＥＩＤおよびＵ−Ｐｌａｎｅ  ＴＥＩＤが埋め込まれたセッション生成リクエストＲＥＱの応答であるセッション生成レスポンスＲＥＳを、要求元端末に送信する。
【００７２】
なお、メモリ２０６に格納されたセッション情報Ｓは、この段階では、ＮＩＦ２０１のメモリ２１０にキャッシュされない。このように、ユーザプレーンパケットによる通信がおこなわれるまでの間、ＮＩＦ２０１のメモリ２１０にセッション情報Ｓをキャッシュしないため、ＮＩＦ２０１のメモリ２１０の使用効率の向上を図ることができる。
【００７３】
（Ｂ）は、（Ａ）の次状態を示す。転送装置１０４は、ＮＩＦ２０１により、ユーザプレーンパケット１５００を受信すると、ＳＭＣ−Ｕ２０５に転送する。そして、転送装置１０４は、ＳＭＣ−Ｕ２０５によりメモリ２０６に格納されているセッション情報Ｓを参照して、ヘッダを変換したユーザプレーンパケット１５１０を、ＳＭＣ−Ｕ２０５からＮＩＦ２０１を介して、ＣＳＷ２０３を経由して宛先に転送する。また、転送装置１０４は、メモリ２０６に格納されたセッション情報Ｓを、ＮＩＦ２０１のメモリ２１０にキャッシュする。
【００７４】
つぎに、転送装置１０４は、ＮＩＦ２０１により後続のユーザプレーンパケット１５２０を受信すると、ＮＩＦ２０１のメモリ２１０にキャッシュされたセッション情報Ｓを参照して、ＮＩＦ２０１によりヘッダを変換したユーザプレーンパケット１５３０を宛先に転送する。
【００７５】
これにより、ユーザプレーンの場合、本来ＳＭＣ−Ｕ２０５において行われたヘッダの変換処理を、ＮＩＦ２０１が代理で実行することができる。したがって、ＮＩＦ２０１からＳＭＣ−Ｕ２０５へのパケット転送およびＳＭＣ−Ｕ２０５からＮＩＦ２０１へのパケット転送をおこなう必要がなくなり、パケット転送の高速化を図ることができ、転送性能の向上を図ることができる。
【００７６】
＜セッション生成シーケンス＞
図１６は、実施例２にかかるセッション生成シーケンス例を示すシーケンス図である。実施例１（図７）では、ＳＭＣ−Ｃ２０４がセッション生成レスポンスＲＥＳをＮＩＦ２０１に送信（ステップＳ７１０）したあと、キャッシュ処理（ステップＳ７１１）を実行したが、実施例２では、キャッシュ処理は実行されない。
【００７７】
＜転送シーケンス＞
図１７は、実施例２にかかるユーザプレーンパケットの転送シーケンス例を示すシーケンス図である。まず、端末ｔ１〜ｔ４からＰＤＮｐ１〜ｐ４内のサーバへのユーザプレーンパケットの転送シーケンス例について説明する。図１６のステップＳ７１５においてセッション生成レスポンスＲＥＳを受けた端末が、図９の（Ａ）に示したようなユーザプレーンパケット８００をサーバ宛に送信する（ステップＳ１７０１）。Ｓ−ＧＷ１０２は、端末からのユーザプレーンパケット８００の変換処理を実行する（ステップＳ１７０２）。具体的には、たとえば、Ｓ−ＧＷ１０２は、図８の（Ａ）のユーザプレーンパケット８００をカプセル化して、図８の（Ｂ）のユーザプレーンパケット８１０に変換する。
【００７８】
そして、Ｓ−ＧＷ１０２は、変換したユーザプレーンパケット８１０を、その宛先となるＰ−ＧＷ１０４に送信する（ステップＳ１７０３）。Ｐ−ＧＷ１０４のＮＩＦ２０１は、Ｓ−ＧＷ１０２からの受信パケットがユーザプレーンパケットであるため、ＳＭＣ−Ｕ２０５を選択し（ステップＳ１７０４）、受信したユーザプレーンパケット８１０をＳＭＣ−Ｕ２０５に送信する（ステップＳ１７０５）。
【００７９】
ＳＭＣ−Ｕ２０５は、受信したユーザプレーンパケット８１０の変換処理を実行する（ステップＳ１７０６）。具体的には、たとえば、ＮＩＦ２０１は、図８の（Ｂ）のユーザプレーンパケット８１０をデカプセル化して、図８の（Ｃ）のユーザプレーンパケット８００に変換する。そして、ＳＭＣ−Ｕ２０５は、変換したユーザプレーンパケット８００をＮＩＦ２０１に送信し（ステップＳ１７０７）、ＮＩＦ２０１は、変換したユーザプレーンパケット８００を、その宛先となるサーバに送信する（ステップＳ１７０８）。
【００８０】
また、ＳＭＣ−Ｕ２０５は、ＮＩＦ２０１に対してセッション情報Ｓのキャッシュ処理を実行する（ステップＳ１７０９）。キャッシュ処理（ステップＳ１７０９）では、ＳＭＣ−Ｕ２０５主導でＮＩＦ２０１にキャッシュ情報を設定する。具体的には、ＳＭＣ−Ｕ２０５は、メモリからセッション情報Ｓを読み出して、セッション情報ＳをＮＩＦ２０１に送信する（ステップＳ１７１０）。ＮＩＦ２０１は、ＳＭＣ−Ｕ２０５からのセッション情報ＳをＮＩＦ２０１のメモリ２１０に格納する（ステップＳ１７１１）。
【００８１】
これにより、次回から、端末ｔ１〜ｔ４からユーザプレーンパケットが送信されてきた場合、ＮＩＦ２０１は、ＮＩＦ２０１のメモリ２１０からセッション情報Ｓを参照することにより、ユーザプレーンパケットを転送することができる。したがって、ＳＭＣ−Ｕ２０５とＮＩＦ２０１との間のデータ転送量を抑制することができ、ユーザプレーンパケットの高速転送を実現することができる。
【００８２】
つぎに、ＰＤＮｐ１〜ｐ４内のサーバから端末ｔ１〜ｔ４へのユーザプレーンパケットの転送シーケンス例について説明する。サーバは、図９の（Ａ）に示したようなユーザプレーンパケット９００を端末宛に送信する（ステップＳ１７０３）。Ｐ−ＧＷ１０４のＮＩＦ２０１は、サーバからのユーザプレーンパケット９００の変換処理を実行する（ステップＳ１７１４）。具体的には、たとえば、ＮＩＦ２０１は、ＮＩＦ２０１のメモリ２１０にキャッシュされたセッション情報Ｓを用いて、図９の（Ａ）のユーザプレーンパケット９００をカプセル化して、図９の（Ｂ）のユーザプレーンパケット９１０に変換する。
【００８３】
そして、ＮＩＦ２０１は、変換したユーザプレーンパケット９１０を、その宛先となるＳ−ＧＷ１０２に送信する（ステップＳ１７１５）。Ｓ−ＧＷ１０２は、Ｐ−ＧＷ１０４のＮＩＦ２０１からユーザプレーンパケット９１０を受信すると、ユーザプレーンパケット９１０の変換処理を実行する（ステップＳ１７１６）。具体的には、たとえば、Ｓ−ＧＷ１０２は、図９の（Ｂ）のユーザプレーンパケット９１０をデカプセル化して、図９の（Ｃ）のユーザプレーンパケット９００に変換する。そして、Ｓ−ＧＷ１０２は、変換したユーザプレーンパケット９００を、その宛先となる端末に送信する（ステップＳ１７１７）。このように、サーバから端末へのユーザプレーンパケットの転送処理は、前段のＮＩＦ２０１により実行されるため、内部のＳＭＣ−Ｕ２０５と転送する必要がなくなる。したがって、転送処理の高速化を図ることができる。
【００８４】
また、端末からの後続のユーザプレーンパケットとサーバからの後続のユーザプレーンパケットの転送処理は、図１０に示したシーケンスと同一シーケンスとなる。したがって、後続のユーザプレーンパケットについても、転送装置１０４の転送処理は、前段のＮＩＦ２０１により実行されるため、内部のＳＭＣ−Ｕ２０５と転送する必要がなくなる。したがって、転送処理の高速化を図ることができる。また、実施例２の転送装置１０４は、ユーザプレーンパケットによる通信がおこなわれるまでの間、ＮＩＦ２０１のメモリにセッション情報Ｓをキャッシュしないため、ＮＩＦ２０１のメモリの使用効率の向上を図ることができる。
【００８５】
（実施例３）
つぎに、実施例３について説明する。実施例３では、実施例１と相違する点について説明し、同一内容については省略する。
【００８６】
実施例１では、転送装置１０４は、セッション生成レスポンスＲＥＳである制御プレーンパケットを、セッションの生成要求元の端末に送信する場合に、ＮＩＦ２０１のメモリ２１０にセッション情報Ｓをキャッシュする。これに対し、実施例３では、ＮＩＦ２０１のメモリ２１０を効率的に活用するため、統計的な処理により、ＮＩＦ２０１がセッション情報Ｓのキャッシュ要否を判定する。キャッシュすべきである場合は、ＮＩＦ２０１は、にＮＩＦ２０１のメモリ２１０のセッション情報Ｓをキャッシュし、キャッシュすべきでない場合は、ＮＩＦ２０１は、セッション情報Ｓをキャッシュしない。
【００８７】
したがって、セッション情報Ｓがキャッシュされた場合には、実施例１と同じ転送処理が実現できるため、転送装置１０４の転送処理は、前段のＮＩＦ２０１により実行されるため、内部のＳＭＣ−Ｕ２０５と転送する必要がなくなる。したがって、転送処理の高速化を図ることができる。また、キャッシュされない場合は、ＮＩＦ２０１のメモリのリソースを効率的に活用することができる。
【００８８】
＜転送装置１０４の構成例＞
図１８は、実施例３にかかる転送装置１０４によるパケット転送例を示す説明図である。（Ａ）は制御プレーンパケットの転送処理を示す。転送装置１０４は、ＮＩＦ２０１によりセッションの要求元端末から、制御プレーンパケットであるセッション生成リクエストＲＥＱを受信する。セッション生成リクエストＲＥＱは、ＣＳＷ２０３を経由してＳＭＣ−Ｃ２０４に渡される。ＳＭＣ−Ｃ２０４は、要求元端末に対しＣ−Ｐｌａｎｅ  ＴＥＩＤ（Ｔｕｎｎｅｌ  Ｅｎｄｐｏｉｎｔ  ＩＤｅｎｔｉｆｉｅｒ）を付与する。Ｃ−Ｐｌａｎｅ  ＴＥＩＤとは、制御プレーンにより、接続ごとに決められるＧＴＰトンネルの識別子である。ＳＭＣ−Ｃ２０４は、セッション情報Ｓをメモリに格納するとともに、セッション生成リクエストＲＥＱの応答であるセッション生成レスポンスＲＥＳにＣ−Ｐｌａｎｅ  ＴＥＩＤを埋め込む。
【００８９】
また、ＳＭＣ−Ｕ２０５は、セッション生成リクエストＲＥＱの応答であるセッション生成レスポンスＲＥＳにＵ−Ｐｌａｎｅ  ＴＥＩＤを埋め込む。Ｕ−Ｐｌａｎｅ  ＴＥＩＤは、ユーザプレーンパケットを通信する際に、ＧＴＰトンネルを用いる送信元を特定するための識別情報である。転送装置１０４は、Ｃ−Ｐｌａｎｅ  ＴＥＩＤおよびＵ−Ｐｌａｎｅ  ＴＥＩＤが埋め込まれたセッション生成リクエストＲＥＱの応答であるセッション生成レスポンスＲＥＳを、要求元端末に送信する。
【００９０】
また、転送装置１０４は、メモリ２０６に格納されたセッション情報Ｓを、ＮＩＦ２０１のメモリ２１０にキャッシュすべきか否かの要否判定をおこなう。キャッシュすべきであると判定された場合、ＮＩＦ２０１は、ＮＩＦ２０１のメモリ２１０にセッション情報Ｓをキャッシュする。一方、キャッシュすべきでないと判定された場合、ＮＩＦ２０１は、ＮＩＦ２０１のメモリ２１０にセッション情報Ｓをキャッシュしない。
【００９１】
（Ｂ）は、（Ａ）の次状態を示す。転送装置１０４は、ＮＩＦ２０１により、ユーザプレーンパケット１８００を受信すると、宛先を特定する。そして、転送装置１０４は、（Ａ）においてＮＩＦ２０１のメモリ２１０にセッション情報Ｓがキャッシュされた場合には、キャッシュされたセッション情報Ｓを参照して、ＮＩＦ２０１によりユーザプレーンパケット１８００のヘッダを変換する。そして、ＮＩＦ２０１は、変換したユーザプレーンパケット１８１０を、ＣＳＷ２０３を経由して宛先に転送する。
【００９２】
一方、ＮＩＦ２０１のメモリ２１０にセッション情報Ｓがキャッシュされていない場合には、ＳＭＣ−Ｕ２０５がセッション情報Ｓを参照して、ユーザプレーンパケット１８００のヘッダを変換する。そして、転送装置１０４は、ＳＭＣ−Ｕ２０５によりヘッダを変換する。そして、ＳＭＣ−Ｕ２０８は、変換したユーザプレーンパケット１８００を、ＣＳＷ２０３を経由して宛先に転送する。
【００９３】
これにより、ユーザプレーンの場合、セッション情報Ｓがキャッシュされた場合には、本来ＳＭＣ−Ｕ２０５において行われたヘッダの変換処理を、ＮＩＦ２０１が代理で実行することができる。したがって、ＮＩＦ２０１からＳＭＣ−Ｕ２０５へのパケット転送およびＳＭＣ−Ｕ２０５からＮＩＦ２０１へのパケット転送をおこなう必要がなくなり、パケット転送の高速化を図ることができ、転送性能の向上を図ることができる。また、セッション情報Ｓがキャッシュされない場合には、ＮＩＦ２０１のメモリ２１０の省メモリ化を図ることができる。
【００９４】
＜判定テーブル＞
つぎに、上述したセッション情報Ｓのキャッシュの要否判定に用いられる判定テーブルについて説明する。なお、判定テーブルは、ＮＩＦ２０１のメモリ２１０に格納され、ＮＩＦ２０１により更新される。
【００９５】
図１９は、実施例３にかかる判定テーブルの記憶内容の他の例を示す説明図である。判定テーブル１９００は、日付時刻項目と、Ｃ−Ｐｌａｎｅ  ＴＥＩＤ項目と、を有する。日付時刻項目には、制御プレーンパケットを受信したときの日付時刻が格納される。この日付時刻は、ＮＩＦ２０１により実行されるタイムスタンプである。すなわち、制御プレーンパケットの着順を示す。Ｃ−Ｐｌａｎｅ  ＴＥＩＤ項目には、Ｃ−Ｐｌａｎｅ  ＴＥＩＤが格納される。図１９の場合、ＮＩＦ２０１のメモリ２１０に応じて一定量までセッション情報Ｓがキャッシュされ、判定テーブル１９００にＣ−Ｐｌａｎｅ  ＴＥＩＤがエントリされる。そして、ＮＩＦ２０１のメモリ２１０が一定量を超える場合に、ＮＩＦ２０１のメモリ２１０から最古のセッション情報Ｓが消去されるとともに、判定テーブル１９００からも対応するエントリが削除される。
【００９６】
また、セッション情報Ｓにライフタイムが設定されている場合には、そのＴＥＩＤのパケットを最後に受信したときの日付時刻からライフタイムが経過した時点で、ＮＩＦ２０１のメモリ２１０からそのセッション情報Ｓが消去されるとともに、判定テーブル１９００からも対応するエントリが削除される。
【００９７】
判定テーブル１９００を用いてキャッシュ要否判定をおこなうことにより、セッション生成リクエストの着順が早いほどセッション情報Ｓが優先的にメモリ２１０にキャッシュされるため、ＮＩＦ２０１だけによる転送が多くなり、転送効率の向上を図ることができる。また、着順が早くても古いセッション情報は消去されるため、パケット転送中のＵ−Ｐｌａｎｅ  ＴＥＩＤのセッション情報Ｓもキャッシュされ、転送効率の向上を図ることができる。
【００９８】
なお、ＮＩＦ２０１は、セッション情報Ｓのライフタイム満了時にメモリ２１０からそのセッション情報Ｓを消去することとしてもよい。また、ＮＩＦ２０１は、メモリ２１０の空き容量が所定値以下になった場合、日付時刻が最古のエントリおよびそのセッション情報を消去することとしてもよい。これにより、メモリ２１０のリソース不足を抑制することができる。
【００９９】
図２０は、実施例３にかかる判定テーブルの記憶内容の一例を示す説明図である。判定テーブル２０００は、順位項目と、端末識別情報項目と、生成回数項目と、を有する。順位項目には、順位が格納される。順位とは、セッションの生成回数の降順である。端末識別情報項目には、ＩＭＳＩなどの端末識別情報が格納される。生成回数項目には、端末識別情報により特定される端末についてのセッションの生成回数が格納される。生成回数は、ＮＩＦ２０１が、要求元の端末からセッション生成リクエストＲＥＱを受信して、要求元の端末にセッション生成レスポンスＲＥＳを送信する場合に、１ポイント上昇する。
【０１００】
図２０の場合、たとえば、セッション生成回数の上位○位までの端末のセッション情報ＳがＮＩＦ２０１のメモリ２１０にキャッシュされる。また、順位ではなく、単に生成回数が所定回数以上となった場合にＮＩＦ２０１のメモリ２１０にキャッシュされることとしてもよい。判定テーブル２０００を用いてキャッシュ要否判定をおこなうことにより、セッションの生成回数が多いＣ−ｐｌａｎｅ  ＴＥＩＤほどセッション情報Ｓが優先的にメモリ２１０に残存するため、ＮＩＦ２０１だけによる転送が多くなり、転送効率の向上を図ることができる。
【０１０１】
なお、ＮＩＦ２０１は、セッション情報Ｓのライフタイム満了時にメモリ２１０からそのセッション情報Ｓを消去することとしてもよい。また、ＮＩＦ２０１は、メモリ２１０の空き容量が所定値以下になった場合、使用回数が最少のエントリおよびそのセッション情報を消去することとしてもよい。これにより、メモリ２１０のリソース不足を抑制することができる。また、図１９の判定テーブルと図２０の判定テーブルの組合せを使用して最近の一定時間に受信した各ＴＥＩＤのパケットの個数の順位により、キャッシュ追加、削除するＴＥＩＤのセッションを判断しても良い。
【０１０２】
＜セッション生成シーケンス＞
図２１は、実施例３にかかるセッション生成シーケンス例を示すシーケンス図である。実施例１（図７）では、ＳＭＣ−Ｃ２０４がセッション生成レスポンスＲＥＳをＮＩＦ２０１に送信（ステップＳ７１０）したあと、キャッシュ処理（ステップＳ７１１）を実行したが、実施例３では、キャッシュ処理（ステップＳ７１１）に先だって、ＮＩＦ２０１は、判定テーブル１９００，２０００を参照して、キャッシュ要否判定を実行する（ステップＳ２１００）。
【０１０３】
たとえば、図１９の判定テーブル１９００の場合、ＮＩＦ２０１は、判定テーブル１９００の登録エントリ数が上限に達した場合には、キャッシュすべきでないと判定し、上限に達していない場合には、キャッシュすべきであると判定する。また、図２０の判定テーブル２０００の場合、ＮＩＦ２０１は、所定順位以上のＣ−Ｐｌａｎｅ  ＴＥＩＤであるか否かを判定する。所定順位以上（または所定生成回数以上）である場合には、ＮＩＦ２０１は、そのセッション情報ＳをＮＩＦ２０１のメモリ２１０にキャッシュすべきと判定する。
【０１０４】
これにより、転送装置１０４での転送処理は、前段のＮＩＦ２０１により実行されるため、転送装置１０４内部のＳＭＣ−Ｕ２０５と転送する必要がなくなる。したがって、転送処理の高速化を図ることができる。なお、キャッシュ済みである場合には、キャッシュしない。これにより、キャッシュ処理の効率化を図ることができる。
【０１０５】
また、ステップＳ２１００において、キャッシュすべきでないと判定された場合には、ＮＩＦ２０１はキャッシュ処理（ステップＳ７１１）を実行しない。これにより、ＮＩＦ２０１のメモリ２１０のリソース不足を低減することができる。なお、実施例３では、ＮＩＦ２０１が判定テーブル１９００，２０００を用いてセッション情報Ｓをキャッシュすべきか否かを判定したが、判定テーブル１９００，２０００を用いることなく、ランダムにキャッシュすべきか否かを判定することとしてもよい。
【０１０６】
＜キャッシュ要否判定処理手順＞
図２２は、図２１のステップＳ２１００に示したＮＩＦ２０１によるキャッシュ要否判定処理手順の一例を示すフローチャートである。図２２は、図１９に示した判定テーブル１９００を用いるキャッシュ判定要否処理手順例を示す。
【０１０７】
まず、ＮＩＦ２０１は、パケットを受信するまで待ち受ける（ステップＳ２２０１：Ｎｏ）。ＮＩＦ２０１は、パケットを受信した場合（ステップＳ２２０１：Ｙｅｓ）、パケットからＣ−Ｐｌａｎｅ  ＴＥＩＤを抽出する（ステップＳ２２０２）。そして、ＮＩＦ２０１は、判定テーブル１９００の登録エントリ数が上限に達しているか否かを判断する（ステップＳ２２０３）。上限を超えるとメモリ２１０がリソース不足となる。そして、判定テーブル１９００の登録エントリ数が上限に達していない場合（ステップＳ２２０３：Ｎｏ）、ＳＭＣ−Ｃ２０４は、ＮＩＦ２０１の判定テーブル１９００にＣ−Ｐｌａｎｅ  ＴＥＩＤを登録する（ステップＳ２２０４）ためのキャッシュ処理（図２１のＳ７１１）をおこなう（ステップＳ２２０５）。
【０１０８】
一方、判定テーブル１９００の登録エントリ数が上限に達した場合（ステップＳ２２０３：Ｙｅｓ）、キャッシュ要否判定処理を終了する。この場合、メモリ２１０のリソース不足によりキャッシュすべきでないため、図２１のキャッシュ処理（ステップＳ７１１）は実行されない。または、最も所定順位（または所定生成回数）が低いセッション情報Ｓを削除した後、あらたなセッション情報についてキャッシュ処理を行っても良い。
【０１０９】
図２３は、図２１のステップＳ２１００に示したＮＩＦ２０１によるキャッシュ要否判定処理手順の他の例を示すフローチャートである。図２３は、図２０に示した判定テーブル２０００を用いるキャッシュ判定要否処理手順例を示す。まず、ＮＩＦ２０１は、パケットを受信するまで待ち受ける（ステップＳ２３０１：Ｎｏ）。ＮＩＦ２０１は、パケットを受信した場合（ステップＳ２３０１：Ｙｅｓ）、パケットからＴＥＩＤを抽出する（ステップＳ２２０２）。
【０１１０】
そして、ＮＩＦ２０１は、抽出したＴＥＩＤが判定テーブル２０００にエントリ済みであるか否かを判断する（ステップＳ２３０３）。エントリ済みでない場合（ステップＳ２３０３：Ｎｏ）、ＮＩＦ２０１は、判定テーブル２０００の登録エントリ数が上限に達したか否かを判断する（ステップＳ２３０４）。上限を超えるとメモリ２１０がリソース不足となる。そして、判定テーブル２０００の登録エントリ数が上限に達していない場合（ステップＳ２３０４：Ｎｏ）、ＳＭＣ−Ｃ２０４は、ＮＩＦ２０１の判定テーブル２０００にＴＥＩＤ情報を登録する（ステップＳ２３０５）ため、キャッシュ処理を実行する（ステップＳ２３０７）。
【０１１１】
一方、判定テーブル２０００の登録エントリ数が上限に達した場合（ステップＳ２３０４：Ｙｅｓ）、キャッシュ要否判定処理を終了する。この場合、メモリ２１０のリソース不足によりキャッシュすべきでないため、図２１のキャッシュ処理（ステップＳ７１１）は実行されない。または、最も所定順位（または所定生成回数）が低いセッション情報を削除した後、あらたなセッション情報についてキャッシュ処理を行う。
【０１１２】
また、ステップＳ２３０３において、ＴＥＩＤがエントリ済みである場合（ステップＳ２３０３：Ｙｅｓ）、ＮＩＦ２０１は、そのＴＥＩＤについてのセッションの受信回数を１加算して（ステップＳ２３０６）、ステップＳ２３０７に移行する。
【０１１３】
＜セッション情報の消去＞
図２４は、ＮＩＦ２０１によるセッション情報Ｓの消去処理手順例を示すフローチャートである。まず、ＮＩＦ２０１は、メモリ２１０を監視し、ライフタイムを満了したセッション情報Ｓがあるか否かを判断する（ステップＳ２４０１）。満了したセッション情報Ｓがある場合（ステップＳ２４０１：Ｙｅｓ）、ステップＳ２４０３に移行する。一方、満了したセッション情報がない場合（ステップＳ２４０１：Ｎｏ）、ＮＩＦ２０１は、メモリ２１０がリソース不足であるか否かを判断する（ステップＳ２４０２）。リソース不足でない場合（ステップＳ１５０２：Ｎｏ）、ステップＳ１５０１に戻る。
【０１１４】
リソース不足である場合（ステップＳ１５０２：Ｙｅｓ）、ＮＩＦ２０１は、判定テーブル１９００，２０００から消去対象エントリを特定する（ステップＳ２４０３）。例えば、判定テーブル１９００の場合、ＮＩＦ２０１は、日付時刻が最古のエントリを消去対象エントリとして特定する。また、判定テーブル２０００の場合、ＮＩＦ２０１は、生成回数が最少となるエントリを消去対象エントリとして特定する。
【０１１５】
そして、ＮＩＦ２０１は、消去対象エントリを判定テーブル１９００，２０００から消去するとともに、そのセッション情報Ｓをメモリ２１０から消去する（ステップＳ２４０４）。なお、ＮＩＦ２０１は、ＳＭＣ−Ｃ２０４とＮＩＦ２０１におけるキャッシュ状態の同期をとるため、ＳＭＣ−Ｃ２０４に対してＮＩＦ２０１で該当のセッション除法を消去したことを通知しても良い。
【０１１６】
このように、実施例３によれば、キャッシュされたセッション情報Ｓについては、実施例１と同様、転送装置１０４での転送処理は、前段のＮＩＦ２０１により実行されるため、転送装置１０４内部のＳＭＣ−Ｕ２０５と転送する必要がなくなる。したがって、転送処理の高速化を図ることができる。また、一部のセッション情報Ｓがキャッシュされないため、ＮＩＦ２０１のメモリ２１０のリソース不足の低減化を図ることができる。
【０１１７】
なお、実施例３では、ＮＩＦ２０１がＮＩＦ２０１のメモリ２１０のリソースに応じてキャッシュ要否判定を実行したが、ＳＭＣ−Ｕ２０５がメモリ２０６のリソース不足に応じてキャッシュ要否判定をすることとしてもよい。
【０１１８】
（実施例４）
つぎに、実施例４について説明する。実施例４では、実施例２と相違する点について説明し、同一内容については省略する。
【０１１９】
実施例２では、転送装置１０４は、ユーザプレーンパケットを宛先に送信する際に、未キャッシュのセッション情報ＳをＮＩＦ２０１のメモリ２１０にキャッシュする。これに対し、実施例４では、ＮＩＦ２０１のメモリ２１０を効率的に活用するため、統計的な処理により、ＮＩＦ２０１がセッション情報Ｓのキャッシュ要否を判定する。キャッシュすべきである場合は、ＮＩＦ２０１は、ＮＩＦ２０１のメモリ２１０のセッション情報Ｓをキャッシュし、キャッシュすべきでない場合は、ＮＩＦ２０１は、セッション情報Ｓをキャッシュしない。
【０１２０】
したがって、セッション情報Ｓがキャッシュされた場合には、実施例２と同じ転送処理が実現できるため、転送装置１０４の転送処理は、前段のＮＩＦ２０１により実行されるため、内部のＳＭＣ−Ｕ２０５と転送する必要がなくなる。したがって、転送処理の高速化を図ることができる。また、キャッシュされない場合であっても、転送装置１０４は、ＮＩＦ２０１のメモリ２１０のリソースを効率的に活用することができる。
【０１２１】
＜転送装置１０４の構成例＞
図２５は、実施例４にかかる転送装置１０４によるパケット転送例を示す説明図である。（Ａ）は制御プレーンパケットの転送処理を示す。（Ａ）の転送処理については、図１５の（Ａ）と同一処理内容であるため、説明を省略する。
【０１２２】
（Ｂ）は、（Ａ）の次状態を示す。転送装置１０４は、ＮＩＦ２０１により、ユーザプレーンパケット２５００を受信すると、宛先を特定する。そして、転送装置１０４は、ＳＭＣ−Ｕ２０５によりメモリ２０６に格納されているセッション情報Ｓを参照して、ヘッダを変換したユーザプレーンパケット２５１０を、ＳＭＣ−Ｕ２０５からＮＩＦ２０１を介して、ＣＳＷ２０３を経由して宛先に転送する。
【０１２３】
また、転送装置１０４は、メモリ２０６に格納されたセッション情報Ｓを、ＮＩＦ２０１のメモリ２１０にキャッシュするか否かのキャッシュ要否判定を実行する。キャッシュ要否判定の詳細は、実施例３と同一であるため、説明を省略する。キャッシュすべきであると判定された場合は、ＮＩＦ２０１は、セッション情報ＳをＮＩＦ２０１のメモリ２１０にキャッシュする。キャッシュすべきでないと判定された場合は、ＮＩＦ２０１は、セッション情報ＳをＮＩＦ２０１のメモリ２１０にキャッシュしない。
【０１２４】
つぎに、転送装置１０４は、ＮＩＦ２０１により後続のユーザプレーンパケット２５２０を受信すると、宛先を特定する。そして、転送装置１０４は、ＮＩＦ２０１のメモリ２１０にキャッシュされたセッション情報Ｓがある場合には当該セッション情報Ｓを参照して、ＮＩＦ２０１によりヘッダを変換したユーザプレーンパケット２４３０を、ＣＳＷ２０３を経由して宛先に転送する。ＮＩＦ２０１のメモリ２１０にキャッシュされてない場合は、ＳＭＣ−Ｕ２０５によりメモリ２０６内のセッション情報Ｓを参照して、ＮＩＦ２０１によりヘッダを変換したユーザプレーンパケット２５３０を、宛先に転送する。
【０１２５】
これにより、セッション情報Ｓがキャッシュされている場合、本来ＳＭＣ−Ｕ２０５において行われたヘッダの変換処理を、ＮＩＦ２０１が代理で実行することができる。したがって、ＮＩＦ２０１からＳＭＣ−Ｕ２０５へのパケット転送およびＳＭＣ−Ｕ２０５からＮＩＦ２０１へのパケット転送をおこなう必要がなくなり、パケット転送の高速化を図ることができ、転送性能の向上を図ることができる。
【０１２６】
また、実施例２と同様、ユーザプレーンパケットによる通信がおこなわれるまでの間、ＮＩＦ２０１のメモリ２１０にセッション情報Ｓをキャッシュしないため、ＮＩＦ２０１のメモリ２１０の使用効率の向上を図ることができる。また、キャッシュ要否判定により一部のセッション情報Ｓがキャッシュされないため、ＮＩＦ２０１のメモリ２１０のリソース不足の低減化を図ることができる。
【０１２７】
＜判定テーブル＞
つぎに、上述したセッション情報Ｓのキャッシュの要否判定に用いられる判定テーブルについて説明する。なお、判定テーブルは、ＮＩＦ２０１のメモリ２１０に格納され、ＮＩＦ２０１により更新される。
【０１２８】
図２６は、実施例４にかかる判定テーブルの記憶内容の他の例を示す説明図である。判定テーブル２６００は、日付時刻項目と、Ｕ−Ｐｌａｎｅ  ＴＥＩＤ項目と、を有する。日付時刻項目には、ユーザプレーンパケットを受信したときの日付時刻が格納される。この日付時刻は、ＮＩＦ２０１により実行されるタイムスタンプである。すなわち、ユーザプレーンパケットの着順を示す。Ｕ−Ｐｌａｎｅ  ＴＥＩＤ項目には、Ｕ−Ｐｌａｎｅ  ＴＥＩＤが格納される。図２６の場合、ＮＩＦ２０１のメモリ２１０に応じて一定量までセッション情報Ｓがキャッシュされ、判定テーブル２６００にＵ−Ｐｌａｎｅ  ＴＥＩＤがエントリされる。そして、ＮＩＦ２０１のメモリ２１０が一定量を超える場合に、ＮＩＦ２０１のメモリ２１０から最古のセッション情報Ｓが消去されるとともに、判定テーブル１９００からも対応するエントリが削除される。
【０１２９】
また、セッション情報Ｓにライフタイムが設定されている場合には、そのユーザプレーンパケットを受信したときの日付時刻からライフタイムが経過した時点で、ＮＩＦ２０１のメモリ２１０からそのセッション情報Ｓが消去されるとともに、判定テーブル２６００からも対応するエントリが削除される。
【０１３０】
判定テーブル２６００を用いてキャッシュ要否判定をおこなうことにより、ユーザプレーンパケットの着順が早いほどセッション情報Ｓが優先的にメモリ２１０にキャッシュされるため、ＮＩＦ２０１だけによる転送が多くなり、転送効率の向上を図ることができる。
【０１３１】
なお、ＮＩＦ２０１は、セッション情報Ｓのライフタイム満了時にメモリ２１０からそのセッション情報Ｓを消去することとしてもよい。また、ＮＩＦ２０１は、メモリ２１０の空き容量が所定値以下になった場合、日付時刻が最古のエントリおよびそのセッション情報を消去することとしてもよい。これにより、メモリ２１０のリソース不足を抑制することができる。
【０１３２】
図２７は、実施例４にかかる判定テーブルの記憶内容の一例を示す説明図である。判定テーブル２７００は、順位項目と、Ｕ−Ｐｌａｎｅ  ＴＥＩＤ項目と、受信回数項目と、を有する。順位項目には、順位が格納される。順位とは、Ｕ−Ｐｌａｎｅ  ＴＥＩＤでのパケットの受信回数の降順である。Ｕ−Ｐｌａｎｅ  ＴＥＩＤ項目には、Ｕ−Ｐｌａｎｅ  ＴＥＩＤが格納される。受信回数項目には、Ｕ−Ｐｌａｎｅ  ＴＥＩＤのパケットの受信回数が格納される。受信回数は、ＮＩＦ２０１が、端末から該当のＴＥＩＤのパケットを受信する度に１ポイント上昇する。すなわち、受信回数は、端末からの該当ＴＥＩＤのパケットの受信回数を示す。
【０１３３】
図２７の場合、たとえば、受信回数の上位○位までのＴＥＩＤのセッション情報ＳがＮＩＦ２０１のメモリ２１０にキャッシュされる。また、順位ではなく、単に受信回数が所定回数以上となった場合にＮＩＦ２０１のメモリ２１０にキャッシュされることとしてもよい。判定テーブル２７００を用いてキャッシュ要否判定をおこなうことにより、受信回数が多いＵ−Ｐｌａｎｅ  ＴＥＩＤほどセッション情報Ｓが優先的にメモリ２１０に残存するため、ＮＩＦ２０１だけによる転送が多くなり、転送効率の向上を図ることができる。
【０１３４】
なお、ＮＩＦ２０１は、セッション情報Ｓのライフタイム満了時にメモリ２１０からそのセッション情報Ｓを消去することとしてもよい。また、ＮＩＦ２０１は、メモリ２１０の空き容量が所定値以下になった場合、使用回数が最少のエントリおよびそのセッション情報を消去することとしてもよい。これにより、メモリ２１０のリソース不足を抑制することができる。また、図２６の判定テーブルと図２７の判定テーブルの組合せを使用して最近の一定時間に受信した各ＴＥＩＤのパケットの個数の順位により、キャッシュ追加、削除するＴＥＩＤのセッションを判断しても良い。
【０１３５】
＜セッション生成シーケンスと転送シーケンス＞
実施例４のセッション生成シーケンスについては、図１６に示した実施例２のセッション生成シーケンスと同一シーケンスであるため、説明を省略する。
【０１３６】
図２８は、実施例４にかかるユーザプレーンパケットの転送シーケンス例を示すシーケンス図である。ステップＳ１７０８において、ＮＩＦ２０１が、変換したユーザプレーンパケットを、その宛先となるサーバに送信した後（ステップＳ１７０８）、ＮＩＦ２０１は、図２６または図２７に示した判定テーブル２６００，２７００を参照して、キャッシュ要否判定を実行する（ステップＳ２８００）。
【０１３７】
たとえば、図２６の判定テーブル２６００の場合、ＮＩＦ２０１は、判定テーブル２６００の登録エントリ数が上限に達した場合には、キャッシュすべきでないと判定し、上限に達していない場合には、キャッシュすべきであると判定する。また、図２７の判定テーブル２７００の場合、ＮＩＦ２０１は、所定順位以上のＣ−Ｐｌａｎｅ  ＴＥＩＤであるか否かを判定する。所定順位以上（または所定受信回数以上）である場合には、ＮＩＦ２０１は、そのセッション情報ＳをＮＩＦ２０１のメモリ２１０にキャッシュすべきと判定する。
【０１３８】
＜キャッシュ要否判定処理手順＞
図２９は、図２８のステップＳ２８００に示したＮＩＦ２０１によるキャッシュ要否判定処理手順の一例を示すフローチャートである。図２９は、図２６に示した判定テーブル２６００を用いるキャッシュ判定要否処理手順例を示す。
【０１３９】
まず、ＮＩＦ２０１は、ユーザプレーンパケットを受信するまで待ち受ける（ステップＳ２９０１：Ｎｏ）。ＮＩＦ２０１は、ユーザプレーンパケットを受信した場合（ステップＳ２９０１：Ｙｅｓ）、ユーザプレーンパケットからＵ−Ｐｌａｎｅ  ＴＥＩＤを抽出する（ステップＳ２９０２）。そして、ＮＩＦ２０１は、判定テーブル２０００の登録エントリ数が上限に達したか否かを判断する（ステップＳ２９０３）。上限を超えるとメモリ２１０がリソース不足となる。そして、判定テーブル２６００の登録エントリ数が上限に達していない場合（ステップＳ２９０３：Ｎｏ）、ＮＩＦ２０１は、判定テーブル２６００にＵ−Ｐｌａｎｅ  ＴＥＩＤを登録し（ステップＳ２９０４）、図２８に示したように、キャッシュ処理（Ｓ１７０９）をおこなう（ステップＳ２９０５）。
【０１４０】
一方、判定テーブル２６００の登録エントリ数が上限に達した場合（ステップＳ２９０３：Ｙｅｓ）、キャッシュ要否判定処理を終了する。この場合、メモリ２１０のリソース不足によりキャッシュすべきでないため、図２８のキャッシュ処理（ステップＳ１７０９）は実行されない。または、最も所定順位（または所定受信回数）が低いセッション情報を削除した後、あらたなセッション情報についてキャッシュ処理を行っても良い。
【０１４１】
図３０は、図２８のステップＳ２８００に示したＮＩＦ２０１によるキャッシュ要否判定処理手順の他の例を示すフローチャートである。図３０は、図２７に示した判定テーブル２７００を用いるキャッシュ判定要否処理手順例を示す。まず、ＮＩＦ２０１は、ユーザプレーンパケットを受信するまで待ち受ける（ステップＳ３００１：Ｎｏ）。ＮＩＦ２０１は、ユーザプレーンパケットを受信した場合（ステップＳ３００１：Ｙｅｓ）、ユーザプレーンパケットからＵ−Ｐｌａｎｅ  ＴＥＩＤを抽出する（ステップＳ２２０２）。
【０１４２】
そして、ＮＩＦ２０１は、抽出したＵ−Ｐｌａｎｅ  ＴＥＩＤが判定テーブル２７００にエントリ済みであるか否かを判断する（ステップＳ３００３）。エントリ済みでない場合（ステップＳ３００３：Ｎｏ）、ＮＩＦ２０１は、判定テーブル２７００の登録エントリ数が上限に達したか否かを判断する（ステップＳ３００４）。上限を超えるとメモリ２１０がリソース不足となる。そして、判定テーブル２７００の登録エントリ数が上限に達していない場合（ステップＳ３００４：Ｎｏ）、ＮＩＦ２０１は、判定テーブル２７００にＵ−Ｐｌａｎｅ  ＴＥＩＤを登録し（ステップＳ３００５）、図２８に示したように、キャッシュ処理（Ｓ１７０９）をおこなう（ステップＳ３００７）。
【０１４３】
一方、判定テーブル２７００の登録エントリ数が上限に達した場合（ステップＳ３００４：Ｙｅｓ）、キャッシュ要否判定処理を終了する。この場合、メモリ２１０のリソース不足によりキャッシュすべきでないため、図２８のキャッシュ処理（ステップＳ１７０９）は実行されない。
【０１４４】
また、ステップＳ３００３において、Ｕ−Ｐｌａｎｅ  ＴＥＩＤがエントリ済みである場合（ステップＳ３００３：Ｙｅｓ）、ＮＩＦ２０１は、そのＵ−Ｐｌａｎｅ  ＴＥＩＤについてのセッションの受信回数を１加算して（ステップＳ３００６）、ステップＳ３００７に移行する。キャッシュ指示（ステップＳ３００７）により、図２１に示したように、キャッシュリクエストが送信される（ステップＳ７１２）。
【０１４５】
これにより、転送装置１０４での転送処理は、前段のＮＩＦ２０１により実行されるため、転送装置１０４内部のＳＭＣ−Ｕ２０５と転送する必要がなくなる。したがって、転送処理の高速化を図ることができる。なお、キャッシュ済みである場合には、キャッシュしない。これにより、キャッシュ処理の効率化を図ることができる。
【０１４６】
また、ステップＳ２８００において、キャッシュすべきでないと判定された場合には、ＮＩＦ２０１はキャッシュ処理（ステップＳ７１１）を実行しない。これにより、ＮＩＦ２０１のメモリ２１０のリソース不足を低減することができる。また、実施例４では、ＮＩＦ２０１が判定テーブル２６００，２７００を用いてセッション情報Ｓをキャッシュすべきか否かを判定したが、判定テーブル２６００，２７００を用いることなく、ランダムにキャッシュすべきか否かを判定することとしてもよい。
【０１４７】
このように、サーバから端末へのユーザプレーンパケットの転送処理は、前段のＮＩＦ２０１により実行されるため、内部のＳＭＣ−Ｕ２０５と転送する必要がなくなる。したがって、転送処理の高速化を図ることができる。
【０１４８】
また、端末からの後続のユーザプレーンパケットとサーバからの後続のユーザプレーンパケットの転送処理は、図１０に示したシーケンスと同一シーケンスとなる。したがって、後続のユーザプレーンパケットについても、転送装置１０４の転送処理は、セッション情報Ｓがキャッシュされている場合、前段のＮＩＦ２０１により実行されるため、内部のＳＭＣ−Ｕ２０５と転送する必要がなくなる。したがって、転送処理の高速化を図ることができる。
【０１４９】
また、実施例２と同様、ユーザプレーンパケットによる通信がおこなわれるまでの間、ＮＩＦ２０１のメモリ２１０にセッション情報Ｓをキャッシュしないため、ＮＩＦ２０１のメモリの使用効率の向上を図ることができる。また、キャッシュ要否判定により一部のセッション情報Ｓがキャッシュされないため、ＮＩＦ２０１のメモリ２１０のリソース不足の低減化を図ることができる。また、セッション情報の消去については、実施例３と同様、図２４に示したＮＩＦ２０１によるセッション情報Ｓの消去処理手順例と同一処理手順とする。
【０１５０】
なお、実施例４では、ＮＩＦ２０１がＮＩＦ２０１のメモリ２１０のリソースに応じてキャッシュ要否判定を実行したが、ＳＭＣ−Ｕ２０５がメモリ２０６のリソース不足に応じてキャッシュ要否判定をすることとしてもよい。
【０１５１】
以上に説明したように、本発明の実施例によれば、転送処理の効率化を図ることができる。
【０１５２】
以上、本発明を添付の図面を参照して詳細に説明したが、本発明はこのような具体的構成に限定されるものではなく、添付した請求の範囲の趣旨内における様々な変更及び同等の構成を含むものである。
【符号の説明】
【０１５３】
１００  ネットワーク
１０１  基地局
１０２  Ｓ−ＧＷ
１０４  Ｐ−ＧＷ（転送装置）
２０１  ＮＩＦ（通信部）
２０４  第１のセッション関連パケット処理部（ＳＭＣ−Ｃ）
２０５  第２のセッション関連パケット処理部（ＳＭＣ−Ｕ）
２０６  メモリ（第１の記憶部）
２１０  メモリ（第２の記憶部）
１９００，２０００，２６００，２７００  判定テーブル
【図１】
2014155032.tif 000003
【図２】
2014155032.tif 000004
【図３】
2014155032.tif 000005
【図４】
2014155032.tif 000006
【図５】
2014155032.tif 000007
【図６】
2014155032.tif 000008
【図７】
2014155032.tif 000009
【図８】
2014155032.tif 000010
【図９】
2014155032.tif 000011
【図１０】
2014155032.tif 000012
【図１１】
2014155032.tif 000013
【図１２】
2014155032.tif 000014
【図１３】
2014155032.tif 000015
【図１４】
2014155032.tif 000016
【図１５】
2014155032.tif 000017
【図１６】
2014155032.tif 000018
【図１７】
2014155032.tif 000019
【図１８】
2014155032.tif 000020
【図１９】
2014155032.tif 000021
【図２０】
2014155032.tif 000022
【図２１】
2014155032.tif 000023
【図２２】
2014155032.tif 000024
【図２３】
2014155032.tif 000025
【図２４】
2014155032.tif 000026
【図２５】
2014155032.tif 000027
【図２６】
2014155032.tif 000028
【図２７】
2014155032.tif 000029
【図２８】
2014155032.tif 000030
【図２９】
2014155032.tif 000031
【図３０】
2014155032.tif 000032