(57)【要約】【課題】従来の技術ではリジェクトされてしまう可能性があったアプリケーションからのリクエストに基づく適切なパケット転送を実現し、かつ、不必要な処理及び不必要な通信リソースの割り当てを回避する。【解決手段】通信ノード（ＵＥ１００）のＮＡＳレイヤ１２０は、ネットワークとのコネクションを確立するよう要求するリクエストメッセージをアプリレイヤ１１０から受信すると、リクエストメッセージに含まれている情報（例えば、ＱＣＩ値やアプリケーションＩＤなど）と接続先を示す情報（ＡＰＮ）とのテーブルを参照して、関連するＡＰＮを取得する。取得したＡＰＮを使用したＬＩＰＡ  ＰＤＮコネクションが既に確立されている場合には、このＬＩＰＡ  ＰＤＮコネクションを利用し、取得したＡＰＮを使用してＬＩＰＡ  ＰＤＮコネクションが確立されていない場合には、取得したＡＰＮを格納したＰＤＮコネクションの確立処理を行う。【選択図】図５
2013141106.tif 000002
【特許請求の範囲】
【請求項１】
ネットワークとコネクションを確立可能な通信ノードであって、
アプリケーション要求情報と接続先情報との対応関係情報を保持する保持手段と、
前記対応関係情報に基づいて、前記ネットワークとのコネクションを確立するよう要求するアプリケーションリクエストに含まれているアプリケーション要求情報に対応した接続先情報を取得する取得手段と、
前記対応関係情報から取得した前記接続先情報に対応するローカルアクセス・コネクションが確立されているか否かを判断する判断手段と、
前記ローカルアクセス・コネクションが既に確立されている場合には、前記アプリケーションリクエストが要求するコネクションとして、前記ローカルアクセス・コネクションを利用する利用手段と、
前記ローカルアクセス・コネクションが確立されていない場合には、前記アプリケーションリクエストが要求するコネクションを確立するために、前記対応関係情報から取得した前記接続先情報を格納したコネクション確立リクエストメッセージを前記ネットワークへ送信する送信手段とを、
有する通信ノード。
【請求項２】
前記ローカルアクセス・コネクションを経由した通信相手と通信を行うことが可能な接続先情報を格納した確立許可情報を前記ネットワークから受信する受信手段をさらに有し、
前記確立許可情報に格納されている接続先情報が、特定の接続先を示す情報を示しているとき、前記ローカルアクセス・コネクションが確立されていない場合であって、さらに、前記対応関係情報から取得した前記接続先情報が前記確立許可情報に格納されている前記特定の接続先を示す情報に含まれている場合にのみ、前記アプリケーションリクエストが要求するコネクションを確立するために、前記対応関係情報から取得した接続先情報を格納した前記コネクション確立リクエストメッセージを前記ネットワークへ送信する請求項１に記載の通信ノード。
【請求項３】
前記接続先情報は、ローカルアクセス又は非ローカルアクセスのいずれか一方のコネクションの確立でのみ使用されるよう割り当てられている請求項１に記載の通信ノード。
【請求項４】
前記アプリケーション要求情報は、ＱｏＳ情報又はアプリケーションＩＤ情報を含む請求項１に記載の通信ノード。
【請求項５】
前記接続先情報は、ローカルアクセス及び非ローカルアクセスの両方で使用可能な共通の情報として割り当てられている請求項１に記載の通信ノード。
【請求項６】
前記アプリケーションリクエストに含まれているアプリケーション要求情報に基づいて、前記取得手段と前記判断手段と前記利用手段と前記送信手段とを動作させるか否かを判断する制御手段をさらに有する請求項１に記載の通信ノード。
【請求項７】
前記制御手段が、前記取得手段と前記判断手段と前記利用手段と前記送信手段とを動作させるか否かを判断する際に、事前にネットワークから通知された情報をさらに用いる請求項６に記載の通信ノード。
【請求項８】
前記事前にネットワークから通知された情報は、Ｃｏｎｎｅｃｔｉｖｉｔｙ  ｔｙｐｅ  ＩＥを含む請求項７に記載の通信ノード。
【請求項９】
前記制御手段が、前記取得手段と前記判断手段と前記利用手段と前記送信手段とを動作させるか否かを判断する際に、前記ローカルアクセス・コネクション内の通信経路の確立を試みた結果をさらに用いる請求項６に記載の通信ノード。
【請求項１０】
前記通信経路の確立を試みた結果は、通信経路確立拒絶メッセージに格納されている拒絶理由を含む請求項９に記載の通信ノード。
【請求項１１】
ネットワークとコネクションを確立可能な通信ノードであって、
アプリケーション要求情報と接続先情報との対応関係情報を保持する保持手段と、
前記対応関係情報に基づいて、前記ネットワークとのコネクションを確立するよう要求するアプリケーションリクエストに含まれているアプリケーション要求情報に対応した接続先情報を取得する取得手段と、
前記対応関係情報から取得した前記接続先情報に対応するローカルアクセス・コネクションが確立されているか否かを判断する判断手段と、
前記ローカルアクセス・コネクションを経由した通信相手と通信を行うことが可能な接続先情報を格納した確立許可情報を前記ネットワークから受信する受信手段と、
前記ローカルアクセス・コネクションが既に確立されている場合には、前記アプリケーションリクエストが要求するコネクションとして、前記ローカルアクセス・コネクションを利用する利用手段と、
前記ローカルアクセス・コネクションが確立されていない場合には、前記アプリケーションリクエストが要求するコネクションを確立するために、前記確立許可情報に格納されている接続先情報が、任意の接続先を示す情報を示しているとき、前記アプリケーションリクエストに含まれている接続先情報、又は、前記対応関係情報から取得した接続先情報を格納したコネクション確立リクエストメッセージを前記ネットワークへ送信する送信手段とを、
有する通信ノード。
【請求項１２】
前記ネットワークへ送信する前記コネクション確立リクエストに、前記確立許可情報に格納されている情報を挿入する請求項１１に記載の通信ノード。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、宅内アクセス技術（ＬＩＰＡ（Ｌｏｃａｌ  ＩＰ  Ａｃｃｅｓｓ：ローカルＩＰアクセス））を利用する通信ノードに関する。
【背景技術】
【０００２】
現在、携帯電話（Ｕｓｅｒ  Ｅｑｕｉｐｍｅｎｔ：ＵＥ、通信ノードとも呼ぶ）に用いる技術の標準化活動は、３ＧＰＰ（Ｔｈｅ  ｔｈｉｒｄ  Ｇｅｎｅｒａｔｉｏｎ  Ｐａｒｔｎｅｒｓｈｉｐ  Ｐｒｏｊｅｃｔ）で行われていて、ネットワークへの接続手順やハンドオーバ手順などの基本機能を満たす手順から、宅内アクセス技術（ＬＩＰＡ）と呼ばれる、例えば、ＵＥがローカルネットワーク内に位置するサーバ（例えば、外部ネットワークからアクセスできない、又は、外部ネットワークからもアクセス可能な社内サーバやホームサーバ）へのアクセスサービスを提供するための手順などが定義されている（下記の非特許文献１を参照）。このＬＩＰＡは、３ＧＰＰが定義する技術の１つであり、ＵＥが通常時に接続するネットワーク（マクロネットワークとも呼ぶ）とは別にカバーエリアが小さい（例えば、社内やビル内）ネットワーク（ローカルネットワークとも呼ぶ）を経由して、特定のサーバ（例えば、社内サーバ）にアクセスする目的や、通常時に接続するネットワークにおけるトラフィックオフロードなどを目的として定義されている。このＵＥが、ＬＩＰＡを行う際のネットワーク（通信システム）の構成の一例を図１に示す。
【０００３】
図１には、ＵＥ１００と無線接続する基地局２１０（Ｅ−ＵＴＲＡＮ３００ではｅＮＢ（ｅＮｏｄｅ  Ｂ）３１０、ローカルネットワーク（ＬＮ（Ｌｏｃａｌ  Ｎｅｔｗｏｒｋ）やＬＨＮ（Ｌｏｃａｌ  ＨｅＮＢ  Ｎｅｔｗｏｒｋ）とも呼ばれる）２００では、ＨｅＮＢ（Ｈｏｍｅ  ｅＮＢ）２１０と呼ばれる）、Ｅ−ＵＴＲＡＮ３００上のＵＥ１００の通信回線制御や移動制御を担当する交換器（Ｅ−ＵＴＲＡＮ３００と接続する交換器はＭＭＥ（Ｍｏｂｉｌｉｔｙ  Ｍａｎａｇｅｍｅｎｔ  Ｅｎｔｉｔｙ：モビリティ管理エンティティ）４３０、ＵＥ１００のＥ−ＵＴＲＡＮ３００に対するユーザデータ配信制御を行うＳＧＷ（Ｓｅｒｖｉｎｇ  Ｇａｔｅｗａｙ：サービングゲートウェイ、ＭＡＧ（Ｍｏｂｉｌｉｔｙ  Ａｎｃｈｏｒ  Ｇａｔｅｗａｙ：モビリティアンカポイント）などとも呼ばれる）４１０、ＵＥ１００に対するアドレス割り当てやＰＤＮ（Ｐａｃｋｅｔ  Ｄａｔａ  Ｎｅｔｗｏｒｋ：パケットデータネットワーク）５００とＳＧＷ４１０との間のユーザデータ転送並びに経路制御を行うＰＧＷ（Ｐａｃｋｅｔ  Ｄａｔａ  Ｎｅｔｗｏｒｋ  Ｇａｔｅｗａｙ、ＨＡ（Ｈｏｍｅ  Ａｇｅｎｔ：ホームエージェント）やＬＭＡ（Ｌｏｃａｌ  Ｍｏｂｉｌｉｔｙ  Ａｎｃｈｏｒ：ローカルモビリティアンカ）などとも呼ばれる）４２０、ＬＨＮ２００においてＥｎｔｅｒｐｒｉｓｅ／Ｒｅｓｉｄｅｎｔｉａｌネットワーク６００とＳＧＷ４１０、若しくは、ＨｅＮＢ２１０間のユーザデータ転送並びに経路制御を行うＬＧＷ（Ｌｏｃａｌ  Ｇａｔｅｗａｙ：ローカルゲートウェイ）２２０、ＵＥ１００のサブスクリプションデータ（Ｓｕｂｓｃｒｉｐｔｉｏｎ  ｄａｔａ）並びに通信コンテキストなどを管理保持しているサーバ（ＭＭＥ４３０との間にインタフェースを持つ（Ｅ−ＵＴＲＡＮ３００を利用するＵＥ１００を対象とする）ものはＨＳＳ（Ｈｏｍｅ  Ｓｕｂｓｃｒｉｂｅｒ  Ｓｅｒｖｅｒ）４４０と呼ばれる）、課金ルールやユーザとネットワークオペレータ間の契約情報からＱｏＳ（Ｑｕａｌｉｔｙ  ｏｆ  Ｓｅｒｖｉｃｅ：サービス品質）を算出するＰＣＲＦ（Ｐｏｌｉｃｙ  ａｎｄ  Ｃｈａｒｇｉｎｇ  Ｒｕｌｅｓ  Ｆｕｎｃｔｉｏｎ：ポリシ及び課金ルール機能）４５０から構成されるネットワーク構成の一例が図示されている。なお、ＬＨＮ２００とコアネットワーク４００とは、ＥＰＣ（Ｅｖｏｌｖｅｄ  Ｐａｃｋｅｔ  Ｃｏｒｅ）４００やＬＨＮ２００のネットワークオペレータ、又は、第３者ネットワークオペレータ（例えば、ＩＳＰ（Ｉｎｔｅｒｎｅｔ  Ｓｅｒｖｉｃｅ  Ｐｒｏｖｉｄｅｒ））が提供するＩＰ（Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ：インターネットプロトコル）ネットワークであるバックホール（Ｂａｃｋｈａｕｌ）７００を経由して接続されている。
【０００４】
図１において、ＵＥ１００がＬＨＮ２００を通り、Ｅｎｔｅｒｐｒｉｓｅ／Ｒｅｓｉｄｅｎｔｉａｌネットワーク６００とデータ交換（ＬＩＰＡ）を行う際、ＵＥ１００はＬＧＷ２２０との間にＰＤＮコネクション及びＥＰＳベアラ（ＥＰＳ  Ｂｅａｒｅｒ、ベアラなどと呼ばれる）を確立しなければならない。ＵＥ１００は、このＰＤＮコネクションの確立を通じてＩＰアドレスを取得し、Ｅｎｔｅｒｐｒｉｓｅ／Ｒｅｓｉｄｅｎｔｉａｌネットワーク６００と通信するためのＥＰＳベアラを確立する（下記の非特許文献１及び非特許文献２を参照）。ＰＤＮコネクションを確立する際、ＵＥ１００に割り当てたＩＰアドレスやＵＥ１００が使用するＳＧＷ４１０のアドレスなどの情報が、ＵＥ１００のコンテキスト情報として扱われ、ＥＰＣ４００のエンティティで保持される。その結果、コアネットワーク４００のエンティティは、例えばＥｎｔｅｒｐｒｉｓｅ／Ｒｅｓｉｄｅｎｔｉａｌネットワーク６００から送られてきたデータをＵＥ１００に転送することができる。ＵＥ１００は、非特許文献１で開示されている“Ａｔｔａｃｈ  ｒｅｑｕｅｓｔ”や“ＰＤＮ  ｃｏｎｎｅｃｔｉｖｉｔｙ  ｒｅｑｕｅｓｔ”などのリクエストメッセージをネットワークに送信して、ＬＧＷ２２０との間にＰＤＮコネクションを確立する。
【０００５】
ＬＩＰＡ向けＰＤＮコネクション（以降、ＬＩＰＡ  ＰＤＮコネクションやローカルアクセス・コネクションと呼ぶ）の確立手順は、通常のＰＤＮコネクションの確立手順と大部分が同じであり、異なる点は、ＥＰＣ４００のエンティティ（例えば、ＭＭＥ４３０）がＬＩＰＡを目的としたＰＤＮコネクション（ＬＩＰＡ  ＰＤＮコネクション）であると判断した場合（例えば、ＵＥ１００から送信されるＡｔｔａｃｈ／ＰＤＮ  ｃｏｎｎｅｃｔｉｖｉｔｙ  ｒｅｑｕｅｓｔで指定されたＡＰＮ（Ａｃｃｅｓｓ  Ｐｏｉｎｔ  Ｎａｍｅ：アクセスポイントネーム。ＰＤＮ５００を識別するパラメータであり、接続（ＰＤＮコネクション）の接続先を表す情報）が、ＬＩＰＡ向けのＡＰＮと認識された場合や、ＨｅＮＢ２１０からＬＧＷアドレスが通知される場合など）、ＭＭＥ４３０からＨｅＮＢ２１０に対して、Ｃｏｒｒｅｌａｔｉｏｎ  ＩＤが送られる点が挙げられる。このＣｏｒｒｅｌａｔｉｏｎ  ＩＤが、ＭＭＥ４３０からＨｅＮＢ２１０に対して送られることによって、ＬＧＷ２２０とＨｅＮＢ２１０は、ユーザデータを直接交換可能な通信経路（Ｄｉｒｅｃｔ  Ｕｓｅｒ  ｐｌａｎｅ  ｐａｔｈや、Ｄｉｒｅｃｔ  ｐａｔｈ、Ｓｈｏｒｔｃｕｔ  ｐａｔｈとも呼ばれる）を確立し、ＥＰＣ４００のＳＧＷ４１０経由でユーザデータを転送せずに、ＬＧＷ２２０とＨｅＮＢ２１０との間のＤｉｒｅｃｔ  ｐａｔｈを用いて、ユーザデータを交換することができる。
【０００６】
また、非特許文献１で示すように、現在ＬＩＰＡではデフォルトベアラ（Ｄｅｆａｕｌｔ  ｂｅａｒｅｒ）と呼ばれるＰＤＮコネクションを確立した際に確立できるＥＰＳベアラ（通信経路）のみがサポートされている。Ｄｅｆａｕｌｔ  ｂｅａｒｅｒの他にデディケーティッドベアラ（Ｄｅｄｉｃａｔｅｄ  ｂｅａｒｅｒ）と呼ばれるＥＰＳベアラが、非特許文献１で示すように存在する。
【０００７】
Ｄｅｆａｕｌｔ  ｂｅａｒｅｒとＤｅｄｉｃａｔｅｄ  ｂｅａｒｅｒとの主な違いは、割り当てられるＱｏＳ情報が異なる点が挙げられる。例えば、Ｄｅｆａｕｌｔ  ｂｅａｒｅｒの場合、通常はＱＣＩ（ＱｏＳ  Ｃｌａｓｓ  Ｉｄｅｎｔｉｆｉｅｒ）の値が「９」であり、Ｄｅｄｉｃａｔｅｄ  ｂｅａｒｅｒと比較すると、パケット転送のスケジューリングの優先度が低かったり、遅延時間が大きく見積もられたりする（下記の非特許文献３を参照）。すなわち、Ｄｅｆａｕｌｔ  ｂｅａｒｅｒは、高品質の通信を行うためのＰＤＮコネクションを確立するためには適切ではない。
【０００８】
一方、ＵＥ１００とＰＤＮ５００との間のユーザデータ交換では、通常、Ｄｅｄｉｃａｔｅｄ  ｂｅａｒｅｒが用いられる。しかしながら、上述したように、ＬＩＰＡ  ＰＤＮコネクション内では、Ｄｅｆａｕｌｔ  ｂｅａｒｅｒのみがサポートされている。そのため、ＵＥ１００がＤｅｄｉｃａｔｅｄ  ｂｅａｒｅｒの確立をＬＨＮ２００へリクエストした場合には、ネットワークの装置（例えば、ＭＭＥ４３０）によって、対応するリジェクト理由を格納したメッセージが返信される（下記の非特許文献４を参照）。なお、今後の３ＧＰＰにおける標準化活動で、ＬＩＰＡ環境においてもＤｅｄｉｃａｔｅｄ  ｂｅａｒｅｒがサポートされる可能性はある。しかしながら、現在の仕様（リリース１０）では、Ｄｅｆａｕｌｔ  ｂｅａｒｅｒのみがサポートされている。
【０００９】
ＵＥ１００からネットワークに対して、ＰＤＮコネクションの確立やＥＰＳベアラの確立をリクエストする際、非特許文献１で示されるように、Ａｔｔａｃｈ  ｐｒｏｃｅｄｕｒｅやＵＥ  ｒｅｑｕｅｓｔｅｄ  ＰＤＮ  ｃｏｎｎｅｃｔｉｖｉｔｙ  ｐｒｏｃｅｄｕｒｅ、ＵＥ  ｒｅｑｕｅｓｔｅｄ  ｂｅａｒｅｒ  ｒｅｓｏｕｒｃｅ  ｍｏｄｉｆｉｃａｔｉｏｎ  ｐｒｏｃｅｄｕｒｅなどの処理を開始する。これらの処理を開始する一例を図２に示す。
【００１０】
図２には、ＵＥ１００とネットワークが図示されている。ＵＥ１００は、下記の非特許文献５で開示されるように、ユーザとのインタフェースであり、アプリケーションが実際に動作するアプリケーションレイヤ１０１、アプリケーションなどを管理するＴＥ（Ｔｅｒｍｉｎａｌ  Ｅｑｕｉｐｍｅｎｔ、例えばコンピュータ）１０２、ＭＴ（Ｍｏｂｉｌｅ  Ｔｅｒｍｉｎａｔｉｏｎ）１０４との中継役となるＴＡ（Ｔｅｒｍｉｎａｌ  Ａｄａｐｔｏｒ、例えば通信カード）１０３、ネットワークとの通信関係の情報を終端するＭＴ（Ｍｏｂｉｌｅ  Ｔｅｒｍｉｎａｔｉｏｎ）１０４から構成される。ＭＴ１０４には、ＮＡＳ（Ｎｏｎ  Ａｃｃｅｓｓ  Ｓｔｒａｔｕｍ：ノンアクセスストラタム）が位置しており、ネットワークとの間で、ユーザデータや制御シグナリングを交換する。
【００１１】
続いて、ＵＥ１００がＬＩＰＡを行うために、ネットワークとＬＩＰＡ  ＰＤＮコネクションを確立し、ＵＥ１００の上位レイヤ（図２のアプリケーションレイヤ１０１やＴＥ１０２に相当）からＮＡＳレイヤ（図２のＭＴ１０４に相当）に対して、Ｄｅｄｉｃａｔｅｄ  ｂｅａｒｅｒの確立リクエストが送信され、ネットワークによってリジェクトされる流れの一例を図３に示す。
【００１２】
図３では、本発明に関わるＵＥ１００内の上位レイヤ（以降、アプリレイヤ１１０と呼ぶ）とＮＡＳレイヤ１２０（以降、ＮＡＳとも呼ぶ）をＵＥ１００として、本発明の想定するシナリオの一例として、図３を用いて説明する。ＵＥ１００が最初にネットワークに接続する際、ＮＡＳレイヤ１２０の上位レイヤ、又は、ＮＡＳレイヤ１２０を起点として、ネットワークとの間にＰＤＮコネクションとＤｅｆａｕｌｔ  ｂｅａｒｅｒを確立する（図３のステップＳ３００１）。なお、ＰＤＮコネクションを確立完了する際、ネットワーク（例えば、ＭＭＥ４３０）からＵＥ１００のＮＡＳ１２０に対して、確立されたＰＤＮコネクションがＬＩＰＡを行うためにＬＨＮ２００のＬＧＷ２２０との間に確立したＬＩＰＡ  ＰＤＮコネクションなのか、ＬＩＰＡではなく通常の通信を行うためにマクロネットワークのＰＧＷ４２０との間に確立したＰＤＮコネクションなのかをＵＥ１００に通知するための情報（Ｃｏｎｎｅｃｔｉｖｉｔｙ  ｔｙｐｅやＰＤＮコネクションタイプなどとも呼ばれる）が規定されている（非特許文献４及び非特許文献６を参照）。このＣｏｎｎｅｃｔｉｖｉｔｙ  ｔｙｐｅは、非特許文献４で示されるようにオプションであり、ネットワークオペレータのポリシやネットワーク装置の仕様によって、ネットワーク（ＭＭＥ４３０）からＵＥ１００に通知される場合と通知されない場合がある。
【００１３】
その後、例えば、ＵＥ１００を操作するユーザや自動更新が設定されているアプリケーションによって、上位レイヤのアプリレイヤ１１０においてアプリが起動される（図３のＳ３００３）。アプリ起動後、アプリレイヤ１１０から下位レイヤのＮＡＳ１２０に対して、アプリケーションのパケットを通信するために必要な情報（アプリケーション要求、Application demand、Required parametersなどとも呼ばれる）が格納されたリクエスト（アプリケーションリクエストとも呼ばれる）が送信される（図３のステップＳ３００５）。上記リクエストに格納されるアプリケーションのパケットを通信するために必要な情報としては、例えば、ＥＰＳベアラにおけるＱｏＳ情報（例えば、ＱＣＩ）、ＡＰＮ、アプリケーションＩＤ、ＧＢＲ（Ｇｕａｒａｎｔｅｅｄ  Ｂｉｔ  Ｒａｔｅ）、ＭＢＲ（Ｍａｘｉｍｕｍ  Ｂｉｔ  Ｒａｔｅ）などの中の少なくとも１種類又は複数種類が使用される。
【００１４】
リクエストを受信したＮＡＳ１２０は、既に確立済みのＥＰＳベアラで、受信したパケットを通信するために必要な情報を満たせるかどうか確認する。例えば、リクエストにＱｏＳ情報とＡＰＮのみが格納されている場合、既に確立済みのＥＰＳベアラに割り当てられているＱｏＳ情報で十分であり、かつ、接続先を示すＡＰＮも既存のＥＰＳベアラと同じであれば、新たにＥＰＳベアラを確立する必要はなく、既存のＥＰＳベアラを利用することが可能である。ＥＰＳベアラが既存か否か、又は、他のアプリケーションと共用せずに個別のＥＰＳベアラが必要か否かの判断は、ＮＡＳ１２０で実施することができる。
【００１５】
また、上記したように、既に確立済みのＰＤＮコネクションがＬＩＰＡ  ＰＤＮコネクションであるか否かについて通知されない場合も起こり得る。既存のＰＤＮコネクションがＬＩＰＡ  ＰＤＮコネクションであるか否かについて通知されていない場合、ＵＥ１００のＮＡＳ１２０は、既存のＰＤＮコネクションがＬＩＰＡ  ＰＤＮコネクションであるか否かを判断できず、リクエストされたＡＰＮに関する既存のＤｅｆａｕｌｔ  Ｂｅａｒｅｒに加えて、Ｄｅｄｉｃａｔｅｄ  ｂｅａｒｅｒ確立の処理を開始する決定を行う可能性がある（図３のステップＳ３００７）。すなわち、この場合には、ＵＥ１００のＮＡＳ１２０は、上位レイヤ（アプリレイヤ１１０）からＤｅｄｉｃａｔｅｄ  ｂｅａｒｅｒが必要となるリクエストを受信した際、ネットワークに対して、Ｄｅｄｉｃａｔｅｄ  ｂｅａｒｅｒを確立するためのＢｅａｒｅｒ  Ｒｅｓｏｕｒｃｅ  Ｍｏｄｉｆｉｃａｔｉｏｎ  ｒｅｑｕｅｓｔメッセージを送信する（図３のステップＳ３００９）。
【００１６】
ＬＩＰＡ  ＰＤＮコネクションのＤｅｆａｕｌｔ  Ｂｅａｒｅｒに加えて、Ｄｅｄｉｃａｔｅｄ  ｂｅａｒｅｒを確立するリクエストである場合には、Ｄｅｄｉｃａｔｅｄ  ｂｅａｒｅｒを確立するためのＢｅａｒｅｒ  Ｒｅｓｏｕｒｃｅ  Ｍｏｄｉｆｉｃａｔｉｏｎ  ｒｅｑｕｅｓｔメッセージを受信したネットワーク（ＭＭＥ４３０）は、現在のＬＩＰＡではＤｅｄｉｃａｔｅｄ  ｂｅａｒｅｒをサポートしていない（Ｄｅｆａｕｌｔ  ｂｅａｒｅｒのみサポートする）ため、リジェクト（確立拒絶）の理由を示すリジェクトコード（例えば、＃６０）を格納したリジェクトメッセージをＵＥ１００のＮＡＳ１２０に返信する（図３のステップＳ３０１１）。リジェクトメッセージを受信したＵＥ１００のＮＡＳ１２０は、ＵＥ１００のＮＡＳ１２０の仕様や上位レイヤ（アプリレイヤ１１０）の要求に基づいて、リクエストがリジェクトされたことをアプリレイヤ１１０へ伝える（図３のステップＳ３０１３）。
【００１７】
上述のように、ＵＥ１００が確立しているＬＩＰＡ  ＰＤＮコネクションではＤｅｆａｕｌｔ  ｂｅａｒｅｒのみがパケット通信に利用されるが、ＮＡＳ１２０は、確立されているＰＤＮコネクションがＬＩＰＡ  ＰＤＮコネクションなのか、あるいは、ＬＩＰＡ  ＰＤＮコネクションではないマクロネットワークへのＰＤＮコネクションなのか判断できない場合がある。このような場合に、ＮＡＳレイヤ１２０は、Ｄｅｄｉｃａｔｅｄ  ｂｅａｒｅｒが必要となるようなリクエストをアプリレイヤ１１０から受信すると、ネットワークに対して、ＬＩＰＡ  ＰＤＮコネクションのＤｅｆａｕｌｔ  ｂｅａｒｅｒに加えて、Ｄｅｄｉｃａｔｅｄ  ｂｅａｒｅｒを確立するためのＰｒｏｃｅｄｕｒｅを開始してしまう可能性がある。ＬＩＰＡではＤｅｄｉｃａｔｅｄ  ｂｅａｒｅｒをサポートしていないため、このＤｅｄｉｃａｔｅｄ  ｂｅａｒｅｒを確立するためのリクエストは、ネットワークによってリジェクトされてしまう。すなわち、結果的にリジェクトされてしまうＰｒｏｃｅｄｕｒｅに係る不必要な処理が行われることになり、無駄な通信リソースが割り当てられてしまうことになる。
【００１８】
ただし、Ｃｏｎｎｅｃｔｉｖｉｔｙ  ｔｙｐｅがネットワークからＵＥ１００のＮＡＳ１２０へ通知されている場合には、ステップＳ３００７において、ＵＥ１００のＮＡＳ１２０は、確立したＰＤＮコネクションがＬＩＰＡ  ＰＤＮコネクションか否か把握することが可能である。確立したＰＤＮコネクションがＬＩＰＡ  ＰＤＮコネクションであることを把握している場合には、ＵＥ１００のＮＡＳ１２０は、結果的にリジェクトされてしまうＤｅｄｉｃａｔｅｄ  ｂｅａｒｅｒ確立のためのＰｒｏｃｅｄｕｒｅを実施せずに（図３のステップＳ３００９、Ｓ３０１１のメッセージ伝送が行われずに）、アプリレイヤ１１０へリジェクトを通知することができる。すなわち、例えばＰＤＮコネクションの確立の際に、確立されたＰＤＮコネクションのＣｏｎｎｅｃｔｉｖｉｔｙ  ｔｙｐｅの通知が常に実行されるようにすることで、不必要な処理や通信リソースの割り当てを回避することが可能となる。
【先行技術文献】
【非特許文献】
【００１９】
【非特許文献１】3GPP TS 23.401 V11.0.0，December 2011
【非特許文献２】3GPP TR 23.829 V10.0.1，October 2011
【非特許文献３】3GPP TS 23.203 V11.0.0，December 2011
【非特許文献４】3GPP TS 24.301 V11.0.0，September 2011
【非特許文献５】3GPP TS 27.007 V11.0.0, September 2011
【非特許文献６】3GPP TS 24.008 V11.0.0, September 2011
【非特許文献７】3GPP TS 36.300 V10.5.0，October 2011
【非特許文献８】3GPP TR 22.896 V2.0.0，December 2011
【発明の概要】
【発明が解決しようとする課題】
【００２０】
従来の技術によれば、ＵＥ１００のＮＡＳ１２０は、確立されたＰＤＮコネクションがＬＩＰＡ  ＰＤＮコネクションか否かを把握していない場合、ＬＩＰＡにおいてサポートされていないＤｅｄｉｃａｔｅｄ  Ｂｅａｒｅｒの確立を試みてしまい、無駄な通信リソースが割り当てられてしまうという課題が生じる。
【００２１】
一方、上述のように、ネットワークがＵＥ１００のＮＡＳ１２０に対して、確立されたＰＤＮコネクションがＬＩＰＡ  ＰＤＮコネクションか否かを示すＣｏｎｎｅｃｔｉｖｉｔｙ  ｔｙｐｅ  ＩＥを必ず通知することも可能である。この場合には、ＵＥ１００のＮＡＳ１２０は、確立されたＰＤＮコネクションがＬＩＰＡ  ＰＤＮコネクションか否かを把握することが可能となる。しかしながら、不必要な通信リソースの割り当てを回避することが可能であるが、この場合には、ＵＥ１００のＮＡＳ１２０は、ＬＩＰＡ  ＰＤＮコネクションのＤｅｆａｕｌｔ  ｂｅａｒｅｒでは通信できないアプリケーションからのリクエストを全てリジェクトしてしまうことにある。つまり、ＬＩＰＡ  ＰＤＮコネクションのＤｅｆａｕｌｔ  ｂｅａｒｅｒでのパケット通信が、例えば、アプリケーションから要求されるＱｏＳ要件を満たさないと判断される場合には、ＵＥ１００のＮＡＳ１２０は、そのアプリケーションからのリクエストをリジェクトしてしまうという課題が生じる。
【００２２】
上記の課題に鑑み、本発明は、ＵＥ１００がＬＩＰＡを行う環境において、従来の技術ではリジェクトされてしまう可能性があったアプリケーションからのリクエストに基づく適切なパケット転送を実現し、かつ、不必要な処理及び不必要な通信リソースの割り当てを回避することが可能となる通信ノードを提供することを目的とする。
【課題を解決するための手段】
【００２３】
上記の目的を達成するため、本発明の通信ノードは、ネットワークとコネクションを確立可能な通信ノードであって、
アプリケーション要求情報と接続先情報との対応関係情報を保持する保持手段と、
前記対応関係情報に基づいて、前記ネットワークとのコネクションを確立するよう要求するアプリケーションリクエストに含まれているアプリケーション要求情報に対応した接続先情報を取得する取得手段と、
前記対応関係情報から取得した前記接続先情報に対応するローカルアクセス・コネクションが確立されているか否かを判断する判断手段と、
前記ローカルアクセス・コネクションが既に確立されている場合には、前記アプリケーションリクエストが要求するコネクションとして、前記ローカルアクセス・コネクションを利用する利用手段と、
前記ローカルアクセス・コネクションが確立されていない場合には、前記アプリケーションリクエストが要求するコネクションを確立するために、前記対応関係情報から取得した前記接続先情報を格納したコネクション確立リクエストメッセージを前記ネットワークへ送信する送信手段とを、
有する。
上記の構成により、通信ノード（ＵＥ）がＬＩＰＡを行う環境において、従来の技術ではリジェクトされてしまう可能性があったアプリケーションからのリクエストに基づく適切なパケット転送を実現し、かつ、不必要な処理及び不必要な通信リソースの割り当てを回避することが可能となる。
【００２４】
また、上記の目的を達成するため、本発明の通信ノードは、ネットワークとコネクションを確立可能な通信ノードであって、
アプリケーション要求情報と接続先情報との対応関係情報を保持する保持手段と、
前記対応関係情報に基づいて、前記ネットワークとのコネクションを確立するよう要求するアプリケーションリクエストに含まれているアプリケーション要求情報に対応した接続先情報を取得する取得手段と、
前記対応関係情報から取得した前記接続先情報に対応するローカルアクセス・コネクションが確立されているか否かを判断する判断手段と、
前記ローカルアクセス・コネクションを経由した通信相手と通信を行うことが可能な接続先情報を格納した確立許可情報を前記ネットワークから受信する受信手段と、
前記ローカルアクセス・コネクションが既に確立されている場合には、前記アプリケーションリクエストが要求するコネクションとして、前記ローカルアクセス・コネクションを利用する利用手段と、
前記ローカルアクセス・コネクションが確立されていない場合には、前記アプリケーションリクエストが要求するコネクションを確立するために、前記確立許可情報に格納されている接続先情報が、任意の接続先を示す情報を示しているとき、前記アプリケーションリクエストに含まれている接続先情報、又は、前記対応関係情報から取得した接続先情報を格納したコネクション確立リクエストメッセージを前記ネットワークへ送信する送信手段とを、
有する。
上記の構成により、通信ノード（ＵＥ）がＬＩＰＡを行う環境において、従来の技術ではリジェクトされてしまう可能性があったアプリケーションからのリクエストに基づく適切なパケット転送を実現し、かつ、不必要な処理及び不必要な通信リソースの割り当てを回避することが可能となる。
【発明の効果】
【００２５】
本発明は、上記の構成を有しており、通信ノード（ＵＥ）がＬＩＰＡを行う環境において、従来の技術ではリジェクトされてしまう可能性があったアプリケーションからのリクエストに基づく適切なパケット転送を実現するという効果、及び、不必要な処理及び不必要な通信リソースの割り当てを回避するという効果を有する。
【図面の簡単な説明】
【００２６】
【図１】本発明の第１から第３の実施の形態並びに従来の技術に共通するシステム構成の一例を示す図
【図２】従来の技術であるＵＥのレイヤ構成を説明する一例の図
【図３】従来の技術に係るシステム動作の一例であり、かつ、本発明の第１から第３の実施の形態において前提とするシステム動作の一例を説明するためのシーケンス図
【図４】従来の技術である“Ａｔｔａｃｈ  ｐｒｏｃｅｄｕｒｅ”を説明するためのシーケンス図
【図５】本発明の第１の実施の形態の動作の一例を説明するためのシーケンス図
【図６Ａ】本発明の第１から第３の実施の形態において用いられるテーブル情報の第１の例を示す図
【図６Ｂ】本発明の第１から第３の実施の形態において用いられるテーブル情報の第２の例を示す図
【図６Ｃ】本発明の第１から第３の実施の形態において用いられるテーブル情報の第３の例を示す図
【図６Ｄ】本発明の第１から第３の実施の形態において用いられるテーブル情報の第４の例を示す図
【図７】本発明の第１の実施の形態におけるＵＥの構成の一例を示す図
【図８】本発明の第１の実施の形態におけるＵＥの動作の一例を示すフローチャート
【図９】本発明の第１の実施の形態におけるＭＭＥの動作の一例を示すフローチャート
【図１０】本発明の第２と第３の実施の形態の動作の一例を説明するためのシーケンス図
【図１１】本発明の第２と第３の実施の形態において用いられる返信メッセージ（Ａｔｔａｃｈ  ａｃｃｅｐｔ）のフォーマット例を示す図
【図１２】本発明の第２と第３の実施の形態におけるＵＥの構成の一例を示す図
【図１３】本発明の第２の実施の形態におけるＵＥの動作の一例を示すフローチャート
【図１４】本発明の第２と第３の実施の形態におけるＭＭＥの構成の一例を示す図
【図１５】本発明の第２と第３の実施の形態におけるＭＭＥの動作の一例を示すフローチャート
【図１６】本発明の第３の実施の形態におけるＵＥの動作の一例を示すフローチャート
【発明を実施するための形態】
【００２７】
以下、図面を参照しながら、本発明の第１から第３の実施の形態について説明する。まず、図１を参照しながら、本発明の第１から第３の実施の形態に共通するシステム構成について説明する。図１は、本発明の第１から第３の実施の形態並びに従来の技術に共通するシステム構成の一例を示す図である。
【００２８】
上述のように、図１に図示されているネットワークは、ＵＥ１００と無線接続する基地局（Ｅ−ＵＴＲＡＮ３００ではｅＮＢ（ｅＮｏｄｅ  Ｂ）３１０、ローカルネットワーク（ＬＮ（Ｌｏｃａｌ  Ｎｅｔｗｏｒｋ）やＬＨＮ（Ｌｏｃａｌ  ＨｅＮＢ  Ｎｅｔｗｏｒｋ）とも呼ばれる）２００では、ＨｅＮＢ（Ｈｏｍｅ  ｅＮＢ）２１０と呼ばれる）、ＵＥ１００の移動管理を担当するＭＭＥ４３０、ＵＥ１００のサブスクリプション情報を保持するＨＳＳ４４０、ユーザデータ配信制御を行うＳＧＷ４１０、ＵＥ１００に対するアドレス割り当てやＰＤＮ５００とＳＧＷ４１０との間のユーザデータ転送並びに経路制御を行うＰＧＷ４２０、ＬＨＮ２００においてＥｎｔｅｒｐｒｉｓｅ／Ｒｅｓｉｄｅｎｔｉａｌネットワーク６００とＳＧＷ４１０、若しくは、Ｅｎｔｅｒｐｒｉｓｅ／Ｒｅｓｉｄｅｎｔｉａｌネットワーク６００とＨｅＮＢ２１０との間のユーザデータ転送並びに経路制御を行うＬＧＷ２２０、ＵＥ１００のサブスクリプションデータ（Ｓｕｂｓｃｒｉｐｔｉｏｎ  ｄａｔａ）並びに通信コンテキストなどを管理保持しているサーバ（ＨＳＳ４４０）、課金ルールやユーザとネットワークオペレータ間の契約情報からＱｏＳを算出するＰＣＲＦ４５０を有している。なお、ＵＥ１００は、このネットワークを介すことで、Ｅｎｔｅｒｐｒｉｓｅ／Ｒｅｓｉｄｅｎｔｉａｌネットワーク６００やＰＤＮ５００と通信可能である。また、図１では、ＬＧＷ２２０はＨｅＮＢ２１０とは別の装置としているが、物理的に１つの装置として扱い、論理的に別装置として扱ってもよい。
【００２９】
ここで、ＵＥ１００は少なくとも１つ以上の通信インタフェースを持ち、ネットワーク（例えば、Ｅ−ＵＴＲＡＮ１１４又はＬＨＮ２００）に接続することが可能である。なお、ＵＥ１００は、図示されているネットワーク（例えば、Ｅ−ＵＴＲＡＮ３００又はＬＨＮ２００）に、同時に、あるいは排他的に接続するものであってもよいが、１つの通信インタフェースで同時に接続できるのは１つのネットワークのみとする。ＵＥ１００は、ＨｅＮＢ２１０やｅＮＢ３１０などの基地局を介して通信システムに接続し、当該ネットワークを通じて、ＰＤＮ５００やＥｎｔｅｒｎｐｒｉｓｅ／Ｒｅｓｉｄｅｎｔｉａｌネットワーク６００と通信可能である。なお、ＵＥ１００がＬＨＮ２００のＬＧＷ２２０との間にＬＩＰＡ  ＰＤＮコネクションを確立する場合、ＥＰＣ４００内のエンティティ（ＭＭＥ４３０やＳＧＷ４１０など）が動作してＬＩＰＡ  ＰＤＮコネクションを確立し、ＵＥ１００はＥｎｔｅｒｐｒｉｓｅ／Ｒｅｓｉｄｅｎｔｉａｌネットワーク６００と通信可能になる。
【００３０】
また、上述したように、ＵＥ１００は３ＧＰＰが制定する手順を用いることで、ＬＨＮ２００のＬＧＷ２２０との間にＬＩＰＡ  ＰＤＮコネクションを確立することができる。なお、以下では、主に図１で示したネットワークの構成要素を用いて、ＬＩＰＡ  ＰＤＮコネクションを確立する場合について説明するが、３ＧＰＰが制定するＵＴＲＡＮ（ＵＭＴＳ  Ｔｅｒｒｅｓｔｒｉａｌ  Ｒａｄｉｏ  Ａｃｃｅｓｓ  Ｎｅｔｗｏｒｋ）に対しても、本発明は適用可能である。
【００３１】
以下、本発明の第１から第３の実施の形態において前提とするシステム動作の一例について、図４を用いて説明する。図４は、従来技術のネットワーク接続手順（Ａｔｔａｃｈ  ｐｒｏｃｅｄｕｒｅとも呼ばれる）であり、かつ、本発明の第１から第３の実施の形態において前提とするシステム動作の一例を説明するためのシーケンス図である。なお、図４は、非特許文献１のＦｉｇｕｒｅ  ５．３．２．１−１：  Ａｔｔａｃｈ  ｐｒｏｃｅｄｕｒｅであり、各シーケンスの詳細な説明は非特許文献１に基づくものとする。以下、図４を参照しながら、本発明の第１から第３の実施の形態の説明例として、ＵＥ１００が、ＬＨＮ２００のＨｅＮＢ２１０とＥＰＣ４００のＭＭＥ４３０、ＳＧＷ４１０を経由して、ＬＩＰＡ  ＰＤＮコネクションを確立する場合を説明する。
【００３２】
ＵＥ１００がＬＨＮ２００のＨｅＮＢ２１０経由でＬＧＷ２２０とＬＩＰＡ  ＰＤＮコネクションを確立する手順は、ＵＥ１００がＥ−ＵＴＲＡＮ３００のｅＮＢ３１０経由でＰＧＷ４２０とＰＤＮコネクションを確立する手順（図４）と一部を除いて同じ手順となっている。ＬＩＰＡ  ＰＤＮコネクションを確立する手順がＥ−ＵＴＲＡＮ３００のｅＮＢ３１０経由で確立する手順と異なる点は、確立するＰＤＮコネクションがＬＩＰＡを目的としたものとネットワーク（ＭＭＥ４３０）で判断された場合（例えば、ＵＥ１００からのＡｔｔａｃｈ  ｒｅｑｕｅｓｔメッセージに格納されたＡＰＮがＬＩＰＡ向けＡＰＮであると判断された場合や、ＨｅＮＢ２１０からＬＧＷアドレスが通知される場合）、ＰＤＮコネクションの終端端末が従来のＰＧＷ４２０ではなく、ＬＧＷ２２０となる点が挙げられる。
【００３３】
また、従来のＰＤＮコネクションを確立する手順には、確立したＰＤＮコネクションが最終的にＬＩＰＡ  ＰＤＮコネクションか通常のＰＤＮコネクション（ＰＧＷ４２０で終端するＰＤＮコネクション）のどちらであるかをＵＥ１００に通知するオプションの情報（Ｃｏｎｎｅｃｔｉｖｉｔｙ  ｔｙｐｅ  ＩＥ（Ｉｎｆｏｒｍａｔｉｏｎ  Ｅｌｅｍｅｎｔ））が存在している。本発明では、従来ではオプションとして扱われていた上記Ｃｏｎｎｅｃｔｉｖｉｔｙ  ｔｙｐｅ  ＩＥを確実（マンダトリー）に、例えば、ネットワーク接続手順時などでＵＥ１００へ送信する情報であることを前提とする。このＣｏｎｎｅｃｔｉｖｉｔｙ  ｔｙｐｅ  ＩＥが、ネットワーク（ＭＭＥ４３０）からＵＥ１００に通知されるタイミングは、図４のステップ１７である（非特許文献４を参照）。ＵＥ１００とネットワークとの間で、図４に示す手順を行うことによって、ＵＥ１００はネットワーク（ＬＧＷ２２０）との間にＬＩＰＡ  ＰＤＮコネクションを確立することが可能となる。
【００３４】
＜第１の実施の形態＞
以下、本発明の第１の実施の形態について説明する。
【００３５】
図５では、ＵＥ１００のＮＡＳ１２０は、図４で示すネットワーク接続手順を用いて、ネットワークとの間にＬＩＰＡ  ＰＤＮコネクションを確立する。また、そのＬＩＰＡ  ＰＤＮコネクション確立手順中に、ネットワーク（ＭＭＥ４３０）は、ＵＥ１００のＮＡＳ１２０に対して、確立したＰＤＮコネクションはＬＩＰＡ  ＰＤＮコネクションであることを示す情報（Ｃｏｎｎｅｃｔｉｖｉｔｙ  ｔｙｐｅ  ＩＥ）を通知する（図５のステップＳ５００１）。図５のステップＳ５００１は、図４で示すネットワーク接続手順に相当するステップである。
【００３６】
続いて、例えば、ＵＥ１００を操作するユーザや自動更新が設定されているアプリケーションによって、上位レイヤのアプリレイヤ１１０においてアプリが起動される（図５のステップＳ５００３）。アプリ起動後、アプリレイヤ１１０から下位レイヤのＮＡＳ１２０に対して、アプリケーションのパケットを通信するために必要な情報（アプリケーション要求情報：例えば、ＥＰＳベアラにおけるＱｏＳ情報（例えば、ＱＣＩ）やＡＰＮ、アプリケーションＩＤ、ＧＢＲ、ＭＢＲなどの中の少なくとも１種類又は複数種類）が格納されたリクエストが送信される（図５のステップＳ５００５）。従来の技術では、確立されているＰＤＮコネクションがＬＩＰＡ  ＰＤＮコネクションであるか否かをＮＡＳレイヤ１２０からアプリレイヤ１１０へ通知する手段が規定されていない（非特許文献５を参照）。したがって、アプリレイヤ１１０は、確立されたＰＤＮコネクションがＬＩＰＡ  ＰＤＮコネクションであっても、Ｄｅｄｉｃａｔｅｄ  ｂｅａｒｅｒの確立を要求するための情報（例えば、ＱＣＩやＧＢＲなどのＱｏＳ情報）を格納したリクエストメッセージをＮＡＳレイヤ１２０に送信する可能性がある。
【００３７】
従来の技術では、図３のステップＳ３００９で示すように、Ｂｅａｒｅｒ  Ｒｅｓｏｕｒｃｅ  Ｍｏｄｉｆｉｃａｔｉｏｎ  Ｒｅｑｕｅｓｔを送信して、ネットワーク（ＭＭＥ）によってリジェクトされるか（ＮＡＳ１２０がＬＩＰＡ  ＰＤＮコネクションか否かを識別できない場合）、あるいは、リクエストのリジェクトをアプリレイヤ１１０に対して通知する（ＮＡＳ１２０がＬＩＰＡ  ＰＤＮコネクションか否かを識別できる場合）。
【００３８】
一方、本発明の第１の実施の形態では、ステップＳ５００５のリクエストメッセージをアプリレイヤ１１０から受信した際、ＮＡＳレイヤ１２０は、アプリレイヤ１１０から受信したリクエストメッセージに基づくＤｅｄｉｃａｔｅｄ  ｂｅａｒｅｒをマクロネットワークで確立できるか否かを判断する。具体的には、ＮＡＳレイヤ１２０は、例えばＵＥ１００があらかじめ保持している対応関係情報（例えばテーブル情報として保持）を参照して、このリクエストに応じたＤｅｄｉｃａｔｅｄ  ｂｅａｒｅｒをマクロネットワークで確立できるか否かを判断する（図５のステップＳ５００７）。なお、アプリレイヤ１１０から受信したリクエストメッセージにＡＰＮが格納されている場合には、ＮＡＳレイヤ１２０は、ステップＳ５００７の判断を行う前に、リクエストメッセージに格納されているＡＰＮが、確立済みのＬＩＰＡ  ＰＤＮコネクションの接続先として使用されているＡＰＮと一致するか否かを判断し、確立済みのＬＩＰＡ  ＰＤＮコネクションの接続先として使用されているＡＰＮと一致する場合にのみ、ステップＳ５００７以降の処理を行ってもよい。
【００３９】
ＵＥ１００のＮＡＳレイヤ１２０は、ＬＨＮ２００のＬＧＷ２２０との間に確立するＬＩＰＡ  ＰＤＮコネクション内のＤｅｆａｕｌｔ  ｂｅａｒｅｒを利用してＤｅｄｉｃａｔｅｄ  ｂｅａｒｅｒの確立を試みるのではなく、例えばＵＥ１００があらかじめ保持しているテーブル情報を参照することによって、マクロネットワークのＰＧＷ４３０との間に新たなＰＤＮコネクションを確立し、アプリレイヤ１１０から要求されるＱｏＳ情報を満たすＤｅｄｉｃａｔｅｄ  ｂｅａｒｅｒを確立することが可能となる。
【００４０】
なお、テーブル情報は、例えば、アプリレイヤ１１０から送信されたリクエストの送信元であるアプリケーション情報（アプリケーションＩＤ）と、そのリクエストに係る通信を行うためのＡＰＮとが関連付けられている“ＡＰＮ−アプリ”テーブル情報（図６Ａ、図６Ｂ）や、アプリレイヤ１１０から送信されたリクエストに含まれるＱｏＳ情報（ＱＣＩなど）と、そのリクエストに係る通信を行うためのＡＰＮとが関連付けられている“ＡＰＮ−ＱｏＳ”テーブル情報（図６Ｃ、図６Ｄ）などが利用可能である。図６Ａ〜図６Ｄの各テーブル情報を用いた判断方法については、図８のフローチャートの説明の際に詳述する。
【００４１】
ステップＳ５００７において、ＵＥ１００のＮＡＳレイヤ１２０が、アプリレイヤ１１０からのリクエストに基づくＤｅｄｉｃａｔｅｄ  ｂｅａｒｅｒを確立することが不可能であると判断した場合には、ＮＡＳレイヤ１２０は、アプリレイヤ１１０に対して、ステップＳ５００５で受信したリクエストメッセージに対するリジェクトメッセージを返信する（図５のステップＳ５００９）。一方、ステップＳ５００７において、ＵＥ１００のＮＡＳレイヤ１２０が、アプリレイヤ１１０からのリクエストに基づくＤｅｄｉｃａｔｅｄ  ｂｅａｒｅｒを確立することが可能であると判断した場合には、テーブル情報から取得したＡＰＮ情報を格納したＰＤＮコネクション確立リクエストメッセージをネットワーク（ＭＭＥ４３０）に送信することでＰＤＮコネクション確立手順を開始する（図５のステップＳ５０１１）。なお、このＰＤＮコネクション確立手順は、非特許文献１で開示されるＵＥ  ｒｅｑｕｅｓｔｅｄ  ＰＤＮ  ｃｏｎｎｅｃｔｉｖｉｔｙ  ｐｒｏｃｅｄｕｒｅを利用してもよい。
【００４２】
ステップＳ５０１１でＵＥ１００から送信されたＰＤＮコネクション確立リクエストメッセージを受信したネットワーク（ＭＭＥ４３０）は、このリクエストメッセージに格納されているＡＰＮ情報を用いたＰＤＮコネクションを確立することが可能か否かを判断する（図５のステップＳ５０１３）。このとき、ネットワーク（ＭＭＥ４３０）がＰＤＮコネクションを確立することが可能か否かを判断する材料として、例えば、非特許文献１で開示されているＡＰＮ  Ｒｅｓｔｒｉｃｔｉｏｎ  ｖａｌｕｅ（例えば、ＬＩＰＡ  ＡＰＮとのＰＤＮコネクションを確立している状態で、マクロネットワークから接続するＡＰＮへのＰＤＮコネクションを同時に保持してもよいか否かなど示す値）や、ＡＰＮの混雑状況などを利用してもよい。
【００４３】
ネットワーク（ＭＭＥ４３０）は、ＵＥ１００から通知されたＡＰＮへのＰＤＮコネクション確立を許可できるか否かの判断結果（確立許可又は確立拒絶）をＵＥ１００に返信する（図５のステップＳ５０１５）。なお、ネットワーク（ＭＭＥ４３０）は、ＵＥ１００に送信するメッセージとして、例えば、非特許文献１に開示されている、確立許可（ＯＫ）を示すＰＤＮ  ｃｏｎｎｅｃｔｉｖｉｔｙ  ａｃｃｅｐｔメッセージや、確立拒絶（ＮＧ）を示すＰＤＮ  ｃｏｎｎｅｃｔｉｖｉｔｙ  ｒｅｊｅｃｔメッセージを利用してもよい。ネットワーク（ＭＭＥ４３０）から返信メッセージを受信したＵＥ１００のＮＡＳレイヤ１２０は、アプリレイヤ１１０に対して返信メッセージの内容を送信する（図５のステップＳ５０１７）。
【００４４】
なお、ＵＥ１００は、アプリケーションからのリクエストに関連付けられているＡＰＮ情報を取得するためのテーブル情報をあらかじめ実装していてもよく、任意のタイミングで他のノードから取得してもよい。また、図６Ａ〜図６Ｄに模式的に示されているテーブル情報として保持せずに、例えばコンテキスト情報の一部として保持していてもよく、あるいは、ＱＣＩ値やアプリケーションＩＤの入力で特定のＡＰＮを出力するような関数として実現されてもよい。
【００４５】
次に、図７を参照しながら、本発明の第１の実施の形態におけるＵＥの構成について説明する。図７は、本発明の第１の実施の形態におけるＵＥの構成の一例を示す図である。図７において、ＵＥ１００はネットワーク（例えば、Ｅ−ＵＴＲＡＮ３００やＬＨＮ２００）と接続して下位レイヤにおける通信処理とＮＡＳレイヤ１２０とのＩＰなどのパケット通信・交換処理を実施する通信処理部７０１と、アプリレイヤ１１０とのＰＤＮコネクション確立やＥＰＳベアラ確立・修正・削除などのメッセージ処理と、アプリレイヤ１１０からのリクエストメッセージ受信時に、確立済のＰＤＮコネクションを利用するか、新たにＰＤＮコネクションを確立するかをテーブル情報を用いて判断処理するＮＡＳ処理部７０２、図６Ａ〜図６Ｄに示すようなテーブル情報を保持するテーブル情報保持部７０３、アプリケーションを介してユーザからの入力を処理（例えば、ＱｏＳ変換やＡＰＮ設定など）するアプリ処理部７０４を少なくとも有する。なお、上記したＵＥ１００の構成は一例を示したものであり、例えば、ＮＡＳ処理部７０２がテーブル情報保持部７０３を含むように設計してもよい。また、アプリ処理部７０４の一部の機能（例えば、ＡＰＮ設定など）をＮＡＳ処理部７０２が担うように設計してもよい。また、テーブル情報保持部７０３において保持されるテーブル情報は、あらかじめ静的に組み込まれていてもよいし、又は、ＵＥ１００が保持する情報（例えば、保持しておいた過去に接続したＡＰＮ情報など）からテーブル情報を生成してもよい。
【００４６】
テーブル情報保持部７０３に保持されているテーブル情報は、例えば図６Ａ〜図６Ｄに図示されているように、ＱＣＩ値又はアプリケーションＩＤに基づいて、関連するＡＰＮが取得できるように構成されている。例えば、テーブル情報はＱＣＩ値（あるいは、ＱＣＩ値の範囲）又はアプリケーションＩＤとＡＰＮとの対応関係（エントリ）を含んでおり、ＮＡＳレイヤ１２０は、テーブル情報に基づいて、特定のアプリケーションＩＤ又はＱＣＩ値又に関連付けられているＡＰＮを取得することが可能である。また、図６Ｂ及び図６Ｄに図示されているように、高品質を要するか否かを示す情報（フラグなどによって実現可能）が各エントリに明記されていてもよい。
【００４７】
次に、図７に図示されている構成を有するＵＥ１００について、本発明における特徴的な処理を中心に、図８を用いて詳しく説明する。図８は、本発明の第１の実施の形態におけるＵＥ１００のＮＡＳレイヤ１２０における動作の一例を示すフローチャートである。
【００４８】
ＵＥ１００のＮＡＳレイヤ１２０は、ネットワークとの間にＬＩＰＡ  ＰＤＮコネクションを確立し（図５のステップＳ５００１に対応する処理、図８では不図示）、その後、新たなＰＤＮコネクション（Ｄｅｄｉｃａｔｅｄ  ｂｅａｒｅｒ）の確立が必要となるＱｏＳ情報を格納したリクエストメッセージをアプリレイヤ１１０から受信する（図８のステップＳ８００１）。なお、このリクエストメッセージは、例えば、従来のＡＴ  Ｃｏｍｍａｎｄであってもよい。
【００４９】
上記リクエストメッセージを受信したＵＥ１００のＮＡＳレイヤ１２０は、例えば図６Ａ〜図６Ｄに図示されているテーブル情報を用いて、マクロネットワークとの間で新たなＰＤＮコネクションを確立する必要があるか否か（あるいは、既に確立済みのＬＩＰＡ  ＰＤＮコネクションを利用することが可能か否か）を判断する。
【００５０】
具体的には、ＮＡＳレイヤ１２０は、まず、アプリレイヤ１１０から受信したリクエストメッセージに含まれているＱＣＩ又はアプリケーションの種類（アプリケーションＩＤ）を参照し、参照したＱＣＩ又はアプリケーションＩＤに該当するエントリがテーブル情報に含まれているか否かを判断する（図８のステップＳ８００３）。参照したＱＣＩ又はアプリケーションＩＤに該当するエントリがテーブル情報に含まれていない場合には、ＮＡＳレイヤ１２０は、アプリレイヤ１１０に対してリジェクトを通知する（図８のステップＳ８００５）。すなわち、図８のステップＳ８００３の判断は、アプリレイヤ１１０から受信したリクエストに応じたＰＤＮコネクションをネットワークとの間で確立できるか否かを判断するものである。
【００５１】
一方、参照したＱＣＩ又はアプリケーションＩＤに該当するエントリがテーブル情報に含まれている場合には、ＮＡＳレイヤ１２０は、アプリレイヤ１１０からリクエストされた通信が高品質を必要とするか否か（ＱＣＩ値が相対的に小さいか否か）を判断する（図８のステップＳ８００７）。アプリレイヤ１１０からリクエストされたＰＤＮコネクションが高品質を必要とすると判断された場合には、該当するエントリに規定されているＡＰＮを取得し（ステップＳ８００８）、マクロネットワークとの間で新たなＰＤＮコネクションを確立するために、取得したＡＰＮを含むＰＤＮコネクション確立リクエストをネットワークへ送信する（図８のステップＳ８００９）。すなわち、図８のステップＳ８００７の判断は、アプリレイヤ１１０から受信したリクエストに応じたＰＤＮコネクションが高品質を要するか否かを判断するものであり、高品質を要すると判断された場合には、マクロネットワークとの間で新たなＰＤＮコネクションの確立を試みる。
【００５２】
一方、リクエストされているＰＤＮコネクションが高品質を必要としないと判断された場合には、該当するエントリに規定されているＡＰＮを取得し（ステップＳ８０１１）。例えばアプリケーションＩＤとしてアプリケーションＣが格納されているリクエストメッセージの場合には、図６Ａに図示されているテーブル情報を保持しているＮＡＳレイヤ１２０は、関連するＡＰＮ情報としてＡＰＮ２を取得する。また、例えば「ＱＣＩ＝１」が格納されているリクエストメッセージの場合には、図６Ｃに図示されているテーブル情報を保持しているＮＡＳレイヤ１２０は、関連するＡＰＮ情報としてＡＰＮ２を取得する。
【００５３】
そして、ＵＥ１００のＮＡＳレイヤ１２０は、取得したＡＰＮと関連するＬＩＰＡ  ＰＤＮコネクションが既に確立されているか否かを判断する（ステップＳ８０１３）。取得したＡＰＮと関連するＬＩＰＡ  ＰＤＮコネクションが既に確立されていると判断された場合には、この確立済みのＬＩＰＡ  ＰＤＮコネクション（Ｄｅｆａｕｌｔ  Ｂｅａｒｅｒ）を利用して、アプリレイヤ１１０からリクエストされた通信を行う（図８のステップＳ８０１５）。また、取得したＡＰＮと関連するＬＩＰＡ  ＰＤＮコネクションが確立されていないと判断された場合には、マクロネットワークとの間で新たなＰＤＮコネクションを確立するためのＰＤＮコネクション確立リクエストを送信する（図８のステップＳ８００９）。すなわち、図８のステップＳ８０１３の判断は、ＬＩＰＡ  ＰＤＮコネクションが確立済みの場合には、このＬＩＰＡ  ＰＤＮコネクションを利用して、アプリレイヤ１１０からリクエストされた低品質の通信を行えるようにするものである。
【００５４】
なお、図８のステップＳ８０１３の判断においては、あるＡＰＮに対して既に確立済みのＰＤＮコネクションがＬＩＰＡ  ＰＤＮコネクションか否かを判断する必要がある。ＰＤＮコネクションがＬＩＰＡを目的としたものであるか否かは、例えば、ＰＤＮコネクションに関連するＣｏｎｎｅｃｔｉｖｉｔｙ  ｔｙｐｅ  ＩＥに基づいて判断することが可能である。
【００５５】
また、図８では、取得したＡＰＮと関連するＬＩＰＡ  ＰＤＮコネクションが確立されていないと判断された場合（図８のステップＳ８０１３）には、マクロネットワークとの間で新たなＰＤＮコネクションの確立を行っているが（図８のステップＳ８００９）、アプリレイヤ１１０からリクエストされた通信はＬＩＰＡ  ＰＤＮコネクションのＤｅｆａｕｌｔ  Ｂｅａｒｅｒを利用できるものであるため、新たにＬＩＰＡ  ＰＤＮコネクションの確立を試みてもよい。
【００５６】
なお、基本的には、ＵＥ１００のＮＡＳレイヤ１２０は、上述した図８のフローチャートに基づく動作を行うが、ＮＡＳレイヤ１２０が保持及び参照するテーブル情報（図６Ａ〜図６Ｄのテーブル情報）に応じて、以下のように動作が異なっている。
【００５７】
例えば、図６Ａ及び図６Ｂに示す“ＡＰＮ−アプリ”テーブル情報を保持するＮＡＳレイヤ１２０は、アプリレイヤ１１０から送信されたリクエストメッセージの送信元アプリケーションの種類を、例えば、アプリケーションＩＤや非特許文献５で開示される特定のトラフィックを識別する“ｃｉｄ”を用いて確認することで、どのＡＰＮを用いるか判断する。
【００５８】
例えば、ＵＥ１００があらかじめ図６Ａのテーブル情報を保持している場合には、ＮＡＳレイヤ１２０は、アプリケーションＡ又はアプリケーションＢからリクエストを受信した際に、このリクエストに関連付けられているＡＰＮ情報としてＡＰＮ１を取得し、アプリケーションＣからリクエストを受信した際に、このリクエストに関連付けられているＡＰＮ情報としてＡＰＮ２を取得する。ＡＰＮ１がＬＩＰＡ  ＰＤＮコネクションを確立するためのＡＰＮであり、ＡＰＮ２がマクロネットワークとの間の通常のＰＤＮコネクションを確立するためのＡＰＮである場合には、ＮＡＳレイヤ１２０は、アプリケーションＡ又はアプリケーションＢからリクエストについては、接続先をＡＰＮ１とするＬＩＰＡ  ＰＤＮコネクションのＤｅｆａｕｌｔ  ｂｅａｒｅｒを利用し、アプリケーションＣからのリクエストについては、ＡＰＮ２を用いた新たなＰＤＮコネクションを確立する必要があると判断する。
【００５９】
なお、例えば、ＬＩＰＡ  ＰＤＮコネクションを確立するためのＡＰＮと、マクロネットワークとの間の通常のＰＤＮコネクションを確立するためのＡＰＮとがそれぞれ異なるようネットワークが設計されている場合には、アプリケーションからのリクエストに対してＡＰＮを特定することによって、Ｄｅｄｉｃａｔｅｄ  ｂｅａｒｅｒの確立が必要か否か（高品質の通信を要求されているか否か）も特定されることになる。したがって、このような場合には、図８のステップＳ８００７の処理は実行される必要はない。
【００６０】
一方、例えば、ＬＩＰＡ  ＰＤＮコネクション（ＬＧＷ２２０経由）と、マクロネットワークとの間の通常のＰＤＮコネクション（ＰＧＷ４２０経由）との両方に共通のＡＰＮが使用されるようネットワークが設計されている場合には、あるアプリケーションからのリクエストに対して特定されたＡＰＮが、ＬＩＰＡ  ＰＤＮコネクションを確立するためのＡＰＮか否かを特定することができない。例えば、アプリケーションＡに関してはＡＰＮ１を用いたＬＩＰＡ  ＰＤＮコネクションの確立が要請され、アプリケーションＢに関してはＡＰＮ１を用いたマクロネットワークとの間の通常のＰＤＮコネクションの確立が要請される場合もある。図６Ａに図示されているテーブル情報を保持している場合には、ＵＥ１００のＮＡＳレイヤ１２０は、図８のステップＳ８００７において、例えばアプリケーションＡからのリクエストに格納されているＱｏＳ情報（ＱＣＩなど）と所定の閾値とを比較することによって、Ｄｅｄｉｃａｔｅｄ  ｂｅａｒｅｒの確立が必要か否か（高品質の通信を要求されているか否か）を判断することが可能である。また、図６Ｂに図示されているテーブル情報を保持している場合には、ＵＥ１００のＮＡＳレイヤ１２０は、図８のステップＳ８００７において、特定されたエントリ内の“高品質／低品質”（あるいは“マクロ／ＬＩＰＡ”）の記載を確認することで、Ｄｅｄｉｃａｔｅｄ  ｂｅａｒｅｒの確立が必要か否か（高品質の通信を要求されているか否か）を判断することが可能である。なお、ＵＥ１００のＮＡＳ１２０は、ＬＧＷ２２０経由のコネクションと、ＰＧＷ４２０経由のコネクションの両方に共通のＡＰＮが使用されている場合に、マクロネットワークのＰＧＷ４２０経由のＰＤＮコネクション確立リクエストを送信する際には、マクロネットワークのＰＧＷ４２０経由のＰＤＮコネクション確立リクエストであることを示す識別子をＰＤＮコネクション確立リクエストに付加してもよい。
【００６１】
また、図６Ｃ及び図６Ｄに示す“ＡＰＮ−ＱｏＳ”テーブル情報をＮＡＳレイヤが保持するＮＡＳレイヤ１２０は、アプリレイヤ１１０から送信されたリクエストメッセージに格納されているＱｏＳ情報が、どのＡＰＮと関連付けられているかを確認する。例えば、ＱｏＳ情報として、「ＱＣＩ＝７」が格納されたリクエストメッセージをＮＡＳレイヤ１２０が受信した場合、ＡＰＮ１を用いて送信元アプリケーションのパケット転送を開始すると判断する。ここで、ＡＰＮ１がＬＩＰＡ  ＰＤＮコネクションを確立した際のＡＰＮであるとすると、送信元アプリケーションのパケット転送は、確立済みのＬＩＰＡ  ＰＤＮコネクションのＤｅｆａｕｌｔ  ｂｅａｒｅｒを用いて、パケット転送を行うと判断する。また、ＱｏＳ情報として、低遅延や低エラービットレートを示す「ＱＣＩ＝１」が格納されたリクエストメッセージをＮＡＳレイヤ１２０が受信した場合には、ＡＰＮ２を用いて送信元アプリケーションのパケット転送を開始すると判断する。非特許文献３で開示されるように、「ＱＣＩ＝１」のアプリケーション例としては、ＶｏＩＰ（Ｖｏｉｃｅ  Ｏｖｅｒ  Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ）などのＩＭＳ（ＩＰ  Ｍｕｌｔｉｍｅｄｉａ  Ｓｕｂｓｙｓｔｅｍ）アプリケーションがある。
【００６２】
また、例えば、ＬＩＰＡ  ＰＤＮコネクション（ＬＧＷ２２０経由）と、マクロネットワークとの間の通常のＰＤＮコネクション（ＰＧＷ４２０経由）の両方に共通のＡＰＮが使用されるようネットワークが設計されている場合もある。図６Ｃに図示されているテーブル情報を保持している場合には、ＵＥ１００のＮＡＳレイヤ１２０は、図８のステップＳ８００７において、受信したリクエストに格納されているＱｏＳ情報（ＱＣＩなど）と所定の閾値とを比較することによって、Ｄｅｄｉｃａｔｅｄ  ｂｅａｒｅｒの確立が必要か否か（高品質の通信を要求されているか否か）を判断することが可能である。また、図６Ｄに図示されているテーブル情報を保持している場合には、ＵＥ１００のＮＡＳレイヤ１２０は、図８のステップＳ８００７において、特定されたエントリ内の“高品質／低品質”（あるいは“マクロ／ＬＩＰＡ”）の記載を確認することで、Ｄｅｄｉｃａｔｅｄ  ｂｅａｒｅｒの確立が必要か否か（高品質の通信を要求されているか否か）を判断することが可能である。なお、ＵＥ１００のＮＡＳ１２０は、ＬＧＷ２２０経由のコネクションと、ＰＧＷ４２０経由のコネクションの両方に共通のＡＰＮが使用されている場合に、マクロネットワークのＰＧＷ４２０経由のＰＤＮコネクション確立リクエストを送信する際には、マクロネットワークのＰＧＷ４２０経由のＰＤＮコネクション確立リクエストであることを示す識別子をＰＤＮコネクション確立リクエストに付加してもよい。
【００６３】
次に、本発明の第１の実施の形態におけるＭＭＥ４３０について、本発明における特徴的な処理を中心に、図９を用いて詳しく説明する。図９は、本発明の第１の実施の形態におけるネットワーク（ＭＭＥ４３０）の動作の一例を示すフローチャートである。
【００６４】
ネットワーク（ＭＭＥ４３０）は、ＵＥ１００から送信されるＬＩＰＡ向けのＡＰＮが格納されたＰＤＮコネクション確立リクエストを受信する（図９のステップＳ９００１）続いて、ネットワーク（ＭＭＥ４３０）が受信したＰＤＮコネクション確立リクエストを許可する場合、確立するＰＤＮコネクションがＬＩＰＡ  ＰＤＮコネクションであることを示すＣｏｎｎｅｃｔｉｖｉｔｙ  ｔｙｐｅ  ＩＥを格納したＰＤＮコネクション確立許可レスポンスをＵＥ１００に返信する（図９のステップＳ９００３）。なお、図９のステップＳ９００１とＳ９００３は、図５のステップＳ５００１（ＬＩＰＡ  ＰＤＮコネクション確立）の処理に相当する。
【００６５】
続いて、ＵＥ１００から再度ＰＤＮコネクション確立リクエストを受信する（図９のステップＳ９００５）。このＰＤＮコネクション確立リクエストには、マクロネットワークのＰＧＷ４２０経由で接続可能なＡＰＮが格納されている。なお、ＵＥ１００が確立済のＬＩＰＡ  ＰＤＮコネクションとは別に、追加のＬＩＰＡ  ＰＤＮコネクションを確立したい場合には、確立済みのＬＩＰＡ  ＰＤＮコネクションが関連するＡＰＮと同じＬＩＰＡ向けＡＰＮが格納される場合もある。その場合も同様に、ネットワーク（ＭＭＥ４３０）は、次ステップで説明する確立リクエストの許可判断を行う。
【００６６】
続いて、ネットワーク（ＭＭＥ４３０）は受信したＰＤＮコネクション確立リクエストを許可するか判断する（図９のステップＳ９００７）。この際、ネットワーク（ＭＭＥ４３０）は、例えば、非特許文献１で開示されるＡＰＮ  Ｒｅｓｔｒｉｃｔｉｏｎ  ｖａｌｕｅ（確立許可を示すＰＤＮコネクション（ＡＰＮ）の組み合わせ）やＡＰＮの混雑状態、オペレータのポリシ、ＵＥ１００の課金契約などに鑑みて判断してもよい。ネットワーク（ＭＭＥ４３０）が、受信したＰＤＮコネクション確立リクエストを許可する場合、ＰＤＮコネクション確立許可メッセージを返信する（図９のステップＳ９００９）。この際も同様に、確立するＰＤＮコネクションのＣｏｎｎｅｃｔｉｖｉｔｙ  ｔｙｐｅ  ＩＥを格納するものとする。また、ネットワーク（ＭＭＥ４３０）が、受信したＰＤＮコネクション確立リクエストを拒絶する場合、ＰＤＮコネクション確立拒絶メッセージを返信する（図９のステップＳ９０１１）。
【００６７】
なお、本発明の第１の実施の形態を容易に説明するために、ＵＥ１００が、非特許文献１で開示されるネットワーク接続手順（Ａｔｔａｃｈ  ｐｒｏｃｅｄｕｒｅ）を用いてネットワークとの間にＬＩＰＡ  ＰＤＮコネクションを確立する動作を一例として説明したが、既にＰＤＮコネクションを複数確立済みの状態で、新たなアプリケーションがＵＥ１００のＮＡＳに新たなＰＤＮコネクション（Ｄｅｄｉｃａｔｅｄ  ｂｅａｒｅｒ）の確立が必要となるケースにおいても、本発明の第１の実施の形態は適用可能である。
【００６８】
従来の技術であれば、ＵＥ１００のアプリレイヤ１１０が新たにＰＤＮコネクション（Ｄｅｄｉｃａｔｅｄ  ｂｅａｒｅｒ）を必要とするようなＱｏＳ情報を格納したリクエストメッセージをＮＡＳレイヤ１２０に送信した場合、従来であれば、ネットワークがＬＩＰＡをサポートしているか否かの情報（ネットワーク（ＭＭＥ）から受信したメッセージに格納されているＣｏｎｎｅｃｔｉｖｉｔｙ  ｔｙｐｅ  ＩＥ）のみで、Ｄｅｄｉｃａｔｅｄ  ｂｅａｒｅｒの確立許可又は確立拒絶の判断を行っていた。一方、本発明の第１の実施の形態によれば、例えば、マクロネットワークのＰＧＷ４２０へのＰＤＮコネクションを確立することによって、不必要な通信リソースの割り当て（例えば、ＬＩＰＡ  ＰＤＮコネクションのＤｅｆａｕｌｔ  ｂｅａｒｅｒに加えて、Ｄｅｄｉｃａｔｅｄ  Ｂｅａｒｅｒを確立するために実施される通信リソースの割り当て）を回避し、かつ、従来ではリジェクトされてしまう可能性があったアプリレイヤ１１０からのリクエストメッセージに対して、ＵＥ１００の保持するテーブル情報に基づく確立許可の判断を行うことが可能となる。
【００６９】
＜第２の実施の形態＞
本発明の第１の実施の形態では、ＵＥ１００のＮＡＳレイヤが、例えば図６Ａ〜図６Ｄで示すテーブル情報を保持することによって、例えば、Ｂｅａｒｅｒ  Ｒｅｓｏｕｒｃｅ  Ｍｏｄｉｆｉｃａｔｉｏｎ  ｐｒｏｃｅｄｕｒｅを実施せずに、アプリレイヤからのリクエストメッセージの許可又は拒絶（新たなＰＤＮコネクションの確立許可又は確立拒絶）の判断を行うことが可能である。新たなＰＤＮコネクションを確立可能であるとＵＥ１００のＮＡＳ１２０が判断する際は、本発明の第１の実施の形態で示したように、例えば、ＰＤＮ  Ｃｏｎｎｅｃｔｉｖｉｔｙ  Ｅｓｔａｂｌｉｓｈｍｅｎｔ  ｒｅｑｕｅｓｔがネットワークに送信される。このリクエストメッセージを許可するか、又は、拒絶するかのネットワーク（ＭＭＥ４３０）による判断は、上記したように、ＡＰＮ  Ｒｅｓｔｒｉｃｔｉｏｎ  ｖａｌｕｅ（確立許可を示すＰＤＮコネクション（ＡＰＮ）の組み合わせ）やＡＰＮの混雑状態、オペレータのポリシ、ＵＥ１００の課金契約などに鑑みて行われる（図５のステップＳ５０１３や図９のステップＳ９００７に相当）。つまり、ネットワーク（ＭＭＥ４３０）の判断によっては、新たなＰＤＮコネクションを確立するためのリクエストメッセージが、リジェクトされる可能性がある。このようにリクエストメッセージがリジェクトされる場合は、ＰＤＮコネクションを確立するための手順（例えば、非特許文献１で開示されるＵＥ  ｒｅｑｕｅｓｔｅｄ  ＰＤＮ  ｃｏｎｎｅｃｔｉｖｉｔｙ  ｐｒｏｃｅｄｕｒｅ）に割り当てられた通信リソースが無駄になってしまう（不要な通信リソースの割り当てを行ってしまう）。
【００７０】
本発明の第２の実施の形態では、上述した本発明の第１の実施の形態に加えて、さらに、ＵＥ１００のＮＡＳレイヤ１２０が、ＰＤＮコネクションを確立するための手順を実行する前に、ネットワーク（ＭＭＥ４３０）からＰＤＮコネクションの確立が許可されているか否かを把握できるようにすることで、不要な通信リソースの割り当てを回避する。
【００７１】
図１０では、ＵＥ１００は本発明の第１の実施の形態と同様に、図４で示すネットワーク接続手順を用いて、ネットワークとの間にＬＩＰＡ  ＰＤＮコネクションを確立する。また、そのＬＩＰＡ  ＰＤＮコネクション確立手順中に、ネットワーク（ＭＭＥ４３０）は、ＵＥ１００に対して、確立したＰＤＮコネクションはＬＩＰＡ  ＰＤＮコネクションであることを示す情報（Ｃｏｎｎｅｃｔｉｖｉｔｙ  ｔｙｐｅ  ＩＥ）を通知する（図１０のステップＳ１０００１）。
【００７２】
このとき、ネットワーク（ＭＭＥ４３０）は、ＬＩＰＡ  ＰＤＮコネクションであることを示す情報（Ｃｏｎｎｅｃｔｉｖｉｔｙ  ｔｙｐｅ  ＩＥ）に加えて、確立済みのＬＩＰＡ  ＰＤＮコネクションと並列してＰＤＮコネクションを確立することを許可する確立許可情報をＵＥ１００に通知する。このときに使用されるメッセージのフォーマット例については後述する。
【００７３】
確立済みのＬＩＰＡ  ＰＤＮコネクションと並列してＰＤＮコネクションを確立することを許可する確立許可情報は、具体的には、マクロネットワークのＰＧＷ４２０経由でＰＤＮへ接続可能なことを示す情報であり、マクロネットワークのＰＧＷ４２０経由で接続する際に使用可能なＡＰＮ情報（あるいは、複数のＡＰＮ情報を含むＡＰＮリスト）を含んでいてもよい。例えば、ＬＩＰＡ  ＰＤＮコネクションの接続先としてＡＰＮ１が使用されているとき、マクロネットワークのＰＧＷ４２０経由のＰＤＮコネクション（例えば、接続先としてＡＰＮ２を使用）によってＥｎｔｅｒｐｒｉｓｅ／Ｒｅｓｉｄｅｎｔｉａｌネットワーク６００と通信を行える場合や、ＰＤＮへアクセスしたい場合には、ネットワーク（ＭＭＥ４３０）は、ＡＰＮ２を格納した確立許可情報をＵＥ１００へ通知することが可能である。この確立許可情報を受信したＵＥ１００は、ＬＩＰＡ  ＰＤＮコネクションの代わりに、確立許可情報によって示されるＡＰＮを使用したＰＤＮコネクションを利用して、Ｅｎｔｅｒｐｒｉｓｅ／Ｒｅｓｉｄｅｎｔｉａｌネットワーク６００やＰＤＮとの通信を行うことが可能である。
【００７４】
ネットワーク（ＭＭＥ４３０）は、例えば、ＡＰＮ  Ｒｅｓｔｒｉｃｔｉｏｎ  ｖａｌｕｅに基づいて、マクロネットワークのＰＧＷ４２０経由のＡＰＮを特定することが可能である。また、ＵＥ１００へ通知する確立許可情報としては、特定のＩＥを利用したり、あるいは、１ビットフラグを利用したりすることが可能である。）
【００７５】
なお、ＬＩＰＡ  ＰＤＮコネクションに関する確立許可情報は、必ずしもＬＩＰＡ  ＰＤＮコネクションの確立通知と同時に通知される必要はなく、ＬＩＰＡ  ＰＤＮコネクションが確立される前後の任意のタイミングで通知されてもよい。
【００７６】
続いて、ＵＥ１００のアプリレイヤ１１０におけるアプリケーション起動（図１０のステップＳ１０００３）、Ｄｅｄｉｃａｔｅｄ  ｂｅａｒｅｒの確立を目的としたアプリレイヤ１１０からＮＡＳレイヤ１２０へのリクエストメッセージの送信（図１０のステップＳ１０００５）が行われる。なお、図１０のステップＳ１０００３及びステップＳ１０００５の処理は、図５のステップＳ５００３及びステップＳ５００５と同様であり、ここでは説明を省略する。
【００７７】
アプリレイヤ１１０からリクエストメッセージを受信したＵＥ１００のＮＡＳ１２０は、例えば図６Ａ〜図６Ｄに示すＵＥのＮＡＳが保持するテーブル情報と、ステップＳ１０００１でネットワーク（ＭＭＥ４３０）から受信した確立許可情報とを用いて、アプリレイヤ１１０から受信したリクエストメッセージに応じたＤｅｄｉｃａｔｅｄ  ｂｅａｒｅｒを確立できるか否かを判断する（図１０のステップＳ１０００７）。具体的には、ＵＥ１００のＮＡＳ１２０は、上述した第１の実施の形態でのテーブル情報に基づく判断（図５のステップＳ５００７）に加えて、さらに確立許可情報に基づき、ネットワーク（ＭＭＥ４３０）からＰＤＮコネクションの確立が許可されているか否かを判断する。
【００７８】
ステップＳ１０００７の判断において、ＵＥ１００が新たなＰＤＮコネクションを確立することが不可能であると判断した場合には、ＮＡＳレイヤ１２０は、アプリレイヤ１１０に対して、ステップＳ１０００５で受信したリクエストメッセージに対するリジェクトメッセージを返信する（図１０のステップＳ１０００９）。一方、ステップＳ１０００７の判断において、ＵＥ１００が新たなＰＤＮコネクションを確立することが可能であると判断した場合には、ステップＳ１０００７においてテーブル情報から取得したＡＰＮ情報を格納したＰＤＮコネクション確立リクエストメッセージをネットワーク（ＭＭＥ４３０）に送信することでＰＤＮコネクション確立手順を開始する（図１０のステップＳ１００１１）。なお、本ステップＳ１００１１は、本発明の第１の実施の形態におけるステップＳ５０１１と同様である。
【００７９】
ステップＳ１００１１でＵＥ１００から送信されたＰＤＮコネクション確立リクエストメッセージには、ネットワーク（ＭＭＥ４３０）が、ＰＤＮコネクションの確立が可能であると判断したＡＰＮが含まれている。ネットワーク（ＭＭＥ４３０）は、例えば、このリクエストメッセージに格納されているＡＰＮを接続先とするＰＤＮコネクションの確立が可能であることを確認し（図１０のステップＳ１００１３）、確立許可を示すＰＤＮコネクション確立許可メッセージを返信する（図１０のステップＳ１００１５）。なお、このＰＤＮコネクション確立許可メッセージとして、非特許文献１で開示されているＰＤＮ  ｃｏｎｎｅｃｔｉｖｉｔｙ  ａｃｃｅｐｔメッセージを用いてもよい。ＰＤＮコネクション確立許可メッセージを受信したＵＥ１００のＮＡＳ１２０は、リクエストされたＱｏＳ情報などを許可することを示すメッセージをアプリレイヤ１１０に対して返信する（図１０のステップＳ１００１７）。
【００８０】
なお、ネットワーク（ＭＭＥ４３０）が確立許可情報をＰＤＮコネクション確立許可情報に格納するために、ＡＰＮ  Ｒｅｓｔｒｉｃｔｉｏｎ  ｖａｌｕｅを確認し、確立可能なＡＰＮ情報を用いてもよい。また、マクロネットワークのＰＧＷ４２０経由で接続可能なＰＤＮ（ＡＰＮ）が１つしかない場合、そのＡＰＮを選択し、確立許可情報として用いてもよい。
【００８１】
また、ネットワーク（ＭＭＥ４３０）は、ＬＩＰＡ  ＰＤＮコネクションを確立すると判断した場合（例えば、ＬＩＰＡ向けＡＰＮが格納されている場合や、ＬＧＷアドレスが付加されている場合など）には、必ず確立許可情報（例えば、特定のＡＰＮ情報やＡＰＮリスト情報（確立許可のＡＰＮの群をＥｑｕｉｖａｌｅｎｔ  ＡＰＮ  ｌｉｓｔとも呼ぶ））を格納して、ＵＥ１００に通知してもよい。
【００８２】
次に、図１１に基づいて、ネットワーク（ＭＭＥ４３０）からＵＥ１００への確立許可情報の通知方法の一例について説明する。ネットワーク（ＭＭＥ４３０）は、例えば、ステップＳ１０００１のＬＩＰＡ  ＰＤＮコネクションの確立の際に、Ａｔｔａｃｈ  ａｃｃｅｐｔメッセージに確立許可情報を含ませることが可能である。図１１は、図１０のステップＳ１０００１で、ネットワーク（ＭＭＥ４３０）がＵＥ１００に対して送信するＡｔｔａｃｈ  ａｃｃｅｐｔメッセージ構成の一例である。
【００８３】
図１１に図示されているＡｔｔａｃｈ  ａｃｃｅｐｔメッセージは、通常のＡｔｔａｃｈ  ａｃｃｅｐｔメッセージで必要となる情報が格納される“従来のＡｔｔａｃｈ  ａｃｃｅｐｔメッセージフィールド”と、確立済みのＬＩＰＡ  ＰＤＮコネクションと並列してＰＤＮコネクション（マクロネットワークのＰＧＷ４２０経由）の確立許可を示す“確立許可情報フィールド”で構成される。確立許可情報フィールドには、ＵＥ１００のＮＡＳ１２０が保持するテーブル情報を用いた判断に加えて、ネットワークがＵＥ１００における確立済みＬＩＰＡ  ＰＤＮコネクションと並列して新たなＰＤＮコネクション（マクロネットワーク経由）を確立可能であるか否かを判断できることを示す情報が格納される。
【００８４】
次に、図１２を参照しながら、本発明の第２の実施の形態におけるＵＥ１００の構成について説明する。図１２は、本発明の第２の実施の形態におけるＵＥ１００の構成の一例を示す図である。本発明の第２の実施の形態におけるＵＥ１００の構成は、確立許可情報確認部７０５以外は同様なため、確立許可情報確認部７０５以外の説明は省略する。ＵＥ１００の確立許可情報確認部７０５は、図１０のステップＳ１０００１でネットワーク（ＭＭＥ４３０）から受信した確立許可情報に格納されている情報（例えば、特定のＡＰＮ情報や、ネットワークオペレータから確立許可されるＡＰＮのリストなど）を処理する機能部である。各情報における具体的な処理方法については、後述する。
【００８５】
次に、図１２に図示されている構成を有するＵＥ１００について、本発明における特徴的な処理を中心に、図１３を用いて詳しく説明する。図１３は、本発明の第２の実施の形態におけるＵＥ１００の動作の一例を示すフローチャートである。本発明の第２の実施の形態におけるＵＥ１００の動作は、本発明の第１の実施の形態におけるＵＥ１００の動作の一例をベースにしており、以下では本発明の第２の実施の形態における特徴的な処理を中心に説明する。
【００８６】
本発明の第１の実施の形態と同様に、ＵＥ１００のＮＡＳレイヤ１２０は、ネットワークとの間にＬＩＰＡ  ＰＤＮコネクションを確立し（図１３では不図示）、その後、新たなＰＤＮコネクション（Ｄｅｄｉｃａｔｅｄ  ｂｅａｒｅｒ）の確立が必要となるＱｏＳ情報を格納したリクエストメッセージをアプリレイヤ１１０から受信する（図１３のステップＳ８００１）。なお、本発明の第２の実施の形態では、ネットワークとの間にＬＩＰＡ  ＰＤＮコネクションを確立する際、ネットワーク（ＭＭＥ４３０）から確立許可情報を受信する。なお、確立許可情報を受信するタイミングは、ＰＤＮコネクションを確立する際や確立後、または、特定のセルやエリアに入った際に受信してもよい。
【００８７】
続いて、アプリレイヤ１１０から上記リクエストメッセージを受信したＵＥ１００のＮＡＳレイヤ１２０は、本発明の第１の実施の形態と同様に、テーブル情報を用いて、マクロネットワークとの間で新たなＰＤＮコネクションを確立する必要があるか否か（あるいは、既に確立済みのＬＩＰＡ  ＰＤＮコネクションを利用することが可能か否か）を判断する（図１３のステップＳ８００３及びステップＳ８００７）。その後の図１３のステップＳ８００３及びステップＳ８００７では、図８のステップＳ８００３及びステップＳ８００７と同様の処理が行われる。
【００８８】
本発明の第２の実施の形態では、アプリレイヤ１１０から受信したリクエストメッセージに含まれているＱＣＩ又はアプリケーションの種類（アプリケーションＩＤ）を参照し、参照したＱＣＩ又はアプリケーションＩＤに該当するエントリがテーブル情報に含まれており、かつ、アプリレイヤ１１０からリクエストされたＰＤＮコネクションが高品質を必要としないと判断された場合に、さらに図１３のステップＳ１３００１において、取得したＡＰＮ情報が確立許可情報のＡＰＮ情報と一致するか否かの判断が行われる。
【００８９】
図１３のステップＳ１３００１において、ＵＥ１００のＮＡＳ１２０は、取得したＡＰＮ情報が確立許可情報のＡＰＮ情報と一致しない場合には、アプリレイヤ１１０に対してリジェクトを通知する（図１３のステップＳ８００５）。一方、取得したＡＰＮ情報が確立許可情報のＡＰＮ情報と一致した場合には、本発明の第１の実施の形態と同様に、取得したＡＰＮと関連するＬＩＰＡ  ＰＤＮコネクションが既に確立されているか否かを判断する（図１３のステップＳ８０１３）。
【００９０】
例えば、図８のステップＳ８０１１において、ＱＣＩ＝１が格納されているリクエストメッセージの場合、図６Ｃ又は図６Ｄのテーブル情報に基づき、関連するＡＰＮ情報としてＡＰＮ２が取得されたとする。続いて、ＵＥ１００のＮＡＳレイヤ１２０は、テーブル情報から取得したＡＰＮ情報（上記例では、ＡＰＮ２に相当）が、ネットワーク（ＭＭＥ４３０）から受信した確立許可情報に格納されている特定のＡＰＮ情報と一致しているか否かを確認する。この確立許可情報にＡＰＮ２が格納されている場合は、一致していると判断し、また、確立許可情報にＡＰＮ２が格納されていない場合には、不一致と判断する。
【００９１】
次に、図１４を参照しながら、本発明の第２の実施の形態におけるＭＭＥ４３０の構成について説明する。図１４は、本発明の第２の実施の形態におけるＭＭＥ４３０の構成の一例を示す図である。図１４において、ＭＭＥ４３０は、Ｅ−ＵＴＲＡＮ３００上のｅＮＢ３１０やＬＨＮ２００上のＨｅＮＢ２１０、ＥＰＣ４００のＳＧＷ４１０と通信処理を実施する通信処理部１４０１と、ＵＥ１００のＮＡＳ１２０とのネットワーク接続処理やＰＤＮコネクション確立処理などのＮＡＳシグナリング（ｅＮＢ３１０やＨｅＮＢ２１０においては透過的なシグナリング）を処理するＮＡＳ処理部１４０２と、図１０のステップＳ１０００１でネットワーク（ＭＭＥ４３０）からＵＥ１００に通知する確立許可情報を生成する確立許可情報生成部１４０３を少なくとも有する。
【００９２】
なお、上記したＭＭＥ４３０の構成は一例を示したものであり、例えば、ＮＡＳ処理部１４０２が確立許可情報生成部１４０３を含むように設計してもよい。また、確立許可情報生成部１４０３は、ＭＭＥ４３０が静的に保持する情報や、ＨＳＳ４４０に問い合わせて取得するＳｕｂｓｃｒｉｐｔｉｏｎ  ｄａｔａや、ＵＥ１００に過去に利用した履歴情報（例えば、過去に接続したＡＰＮ情報）などから確立許可情報を生成してもよい。
【００９３】
次に、図１４に図示されている構成を有するＭＭＥ４３０について、本発明における特徴的な処理を中心に、図１５を用いて詳しく説明する。図１５は、本発明の第２の実施の形態におけるＭＭＥ４３０の動作の一例を示すフローチャートである。本発明の第２の実施の形態におけるＭＭＥ４３０の動作は、本発明の第１の実施の形態におけるＭＭＥ４３０の動作の一例をベースにしており、以下では本発明の第２の実施の形態における特徴的な処理を中心に説明する。
【００９４】
図１５のステップＳ１５００１とステップＳ１５００３は、図９のステップＳ９００１とステップＳ９００３と同様なため、説明を省略する。続いて、ＭＭＥ４３０はＰＤＮコネクション確立許可メッセージに格納するための確立許可情報を生成する（図１５のステップＳ１５００４）。ＭＭＥ４３０によって生成される確立許可情報は、ＵＥ１００における新たなＰＤＮコネクションを確立するか否かを判断する判断材料として提供することを目的としている。
【００９５】
以下、ＭＭＥ４３０が、特定のＡＰＮ情報を確立許可情報として用いる場合の詳細な処理手順の一例について説明する。最初に、ＭＭＥ４３０がＬＩＰＡ  ＰＤＮコネクションを確立すると判断した際（例えば、ＵＥ１００から通知されるＰＤＮコネクション確立リクエストやＡｔｔａｃｈ  ｒｅｑｕｅｓｔメッセージに格納されているＡＰＮ情報がＬＩＰＡ向けのＡＰＮであると判断した場合や、ＨｅＮＢ２１０によってＬＧＷ２２０のアドレスがＭＭＥ４３０へのメッセージ（例えば、非特許文献１で開示されるＡｔｔａｈ  ｒｅｑｕｅｓｔメッセージやＵｐｌｉｎｋ  ＮＡＳ  ｔｒａｎｓｐｏｒｔメッセージ）に格納される場合）、確立済みのＬＩＰＡ  ＰＤＮコネクションと並列して確立可能なＰＤＮコネクションに関連するＡＰＮ情報を選択する。なお、本発明では、マクロネットワークにおけるＰＧＷ４２０とのＰＤＮコネクションを確立することを許可する場合を想定しているため、ＰＧＷ４２０経由で接続可能なＡＰＮを選択する。
【００９６】
次に、ＭＭＥ４３０が、Ｅｑｕｉｖａｌｅｎｔ  ＡＰＮ  ｌｉｓｔを確立許可情報として用いる場合の詳細な処理手順の一例を説明する。Ｅｑｕｉｖａｌｅｎｔ  ＡＰＮ  ｌｉｓｔが確立許可情報として用いられる場合、ネットワーク（ＭＭＥ４３０）によって複数の確立許可されるＡＰＮがリストとして生成される。例えば、ネットワークオペレータが管理しているマクロネットワークのＰＧＷ４２０経由でアクセス可能なＡＰＮを全て、又は、一部をオペレータポリシやＵＥ１００のＳｕｂｓｃｒｉｐｔｉｏｎ  ｄａｔａ（例えば、ロケーション情報や課金契約情報、ローミング情報など）に基づいて生成・選択して格納する。
【００９７】
ＭＭＥ４３０は、上記のように選択・生成した確立許可情報をＰＤＮコネクション確立許可メッセージに格納して（図１５のステップＳ１５００４）、ＵＥ１００に送信する。なお、図１０のステップＳ１５００３（Ｃｏｎｎｅｃｔｉｖｉｔｙ  ｔｙｐｅ  ＩＥを格納）と、図１０のステップＳ１５００４（確立許可情報を選択・生成・格納）を実施する順番は順不同である。続くステップＳ１５００５以降の処理は、本発明の第１の実施の形態における図９のステップＳ９００５以降と同様であり、ここでは説明を省略する。
【００９８】
なお、本発明の第２の実施の形態を容易に説明するために、ＵＥ１００が、非特許文献１で開示されるネットワーク接続手順（Ａｔｔａｃｈ  ｐｒｏｃｅｄｕｒｅ）を用いてネットワークとの間にＬＩＰＡ  ＰＤＮコネクションを確立する動作を一例として説明したが、既にＰＤＮコネクションを複数確立済みの状態で、新たなアプリケーションがＵＥ１００のＮＡＳ１２０に新たなＰＤＮコネクション（Ｄｅｄｉｃａｔｅｄ  ｂｅａｒｅｒ）の確立が必要となるケースにおいても、本発明の第２の実施の形態は適用可能である。
【００９９】
以上、本発明の第２の実施の形態によれば、本発明の第１の実施の形態における効果に加えて、ＬＩＰＡ  ＰＤＮコネクションと並列して確立可能なＰＤＮコネクションに関する確立許可情報（例えば、特定のＡＰＮ情報やＡＰＮリストなど）がネットワーク（ＭＭＥ４３０）からＵＥ１００に通知されることによって、ＵＥ１００は、ＬＩＰＡ  ＰＤＮコネクションに加えて、新たなＰＤＮコネクションを確立することが可能か否かを判断することが可能となる。その結果、ＵＥ１００は、ＰＤＮコネクションを確立できることが確認された場合にのみ、ＰＤＮコネクション確立リクエストを送信することができるようになり、ＰＤＮコネクション確立リクエストがリジェクトされることによる通信リソースの不要な割り当てを回避することができる。
【０１００】
＜第３の実施の形態＞
本発明の第２の実施の形態では、ネットワーク（ＭＭＥ４３０）からＵＥ１００に通知する確立許可情報として、例えば、特定のＡＰＮ情報や、ネットワークオペレータから確立許可されるＡＰＮのリストなどが用いられている。一方、本発明の第３の実施の形態では、確立許可情報として、任意のＡＰＮへのＰＤＮコネクション確立許可を示すＩｎｄｉｃａｔｏｒが用いられる場合について説明する。
【０１０１】
本発明の第３の実施の形態では、確立許可情報として、任意のＡＰＮへのＰＤＮコネクション確立許可を示すＩｎｄｉｃａｔｏｒが用いられる。任意のＡＰＮへのＰＤＮコネクション確立許可を示すＩｎｄｉｃａｔｏｒは、任意のＡＰＮを用いてＬＩＰＡ  ＰＤＮコネクションに加えて、マクロネットワーク経由でＰＤＮへ接続するＰＤＮコネクション（ＰＧＷ４２０経由）を確立することが可能である旨を通知する情報である。本発明の第２の実施の形態では特定のＡＰＮ情報や確立許可されるＡＰＮのリストなどが確立許可情報として通知されるのに対して、本発明の第３の実施の形態では、任意のＡＰＮへのＰＤＮコネクション確立許可を示すＩｎｄｉｃａｔｏｒが確立許可情報として用いられることで、ＵＥ１００が保持するテーブル情報に登録されているＡＰＮ情報と一致しない場合においても、新たなＰＤＮコネクション確立を許可することをＵＥ１００に示すことができる。
【０１０２】
例えば、ネットワーク（ＭＭＥ４３０）が、ＵＥ１００によって保持されるテーブル情報に登録されているＡＰＮ情報を把握していない場合（例えば、静的にテーブル情報が保持されている場合）においても、アプリレイヤ１１０から通知されるＱｏＳ情報を満たすことができるＰＤＮコネクション（Ｄｅｄｉｃａｔｅｄ  ｂｅａｒｅｒ）を任意のＡＰＮで確立することができる。
【０１０３】
また、マクロネットワークのＰＧＷ４２０経由で接続するＰＤＮコネクションとＬＨＮ２００のＬＧＷ２１０経由で接続するＰＤＮコネクションにおいて共通のＡＰＮを利用する場合、ネットワーク（ＭＭＥ４３０）はオペレータポリシや、ＨｅＮＢ２１０から転送されるメッセージ（例えば、非特許文献１で開示されるＡｔｔａｃｈ  ｒｅｑｕｅｓｔメッセージやＵｐｌｉｎｋ  ＮＡＳ  ｔｒａｎｓｐｏｒｔメッセージなど）にＨｅＮＢ２１０によって追加されるＬＧＷアドレスの有無に基づいて、ＬＩＰＡ  ＰＤＮコネクションの確立リクエストであるか識別する。ネットワーク（ＭＭＥ４３０）において、確立リクエストが上記オペレータポリシやＬＧＷアドレスの有無（基本的にＨｅＮＢ２１０は常にＬＧＷアドレスを格納する（非特許文献１を参照））に基づいて、ＬＩＰＡ  ＰＤＮコネクションの確立リクエストであると判断されるため、アプリレイヤ１１０から通知されるＱｏＳ情報を満たすＰＤＮコネクション（Ｄｅｄｉｃａｔｅｄ  ｂｅａｒｅｒ）を確立することができない。
【０１０４】
しかし、本発明の第３の実施の形態では、任意のＡＰＮへのＰＤＮコネクション確立許可を示すＩｎｄｉｃａｔｏｒ（例えば、ネットワーク（ＭＭＥ４３０）が生成するトークンや、ＵＥ１００とＭＭＥ４３０のみが識別可能な鍵情報など）を確立許可情報として利用することで、例えば、ＵＥ１００のＮＡＳ１２０からネットワーク（ＭＭＥ４３０）に送信するＰＤＮコネクション確立リクエストメッセージに、受信した確立許可情報（例えば、上記トークンや鍵情報など）を格納することで、ＬＩＰＡ  ＰＤＮコネクションの確立リクエストではなく、マクロネットワークのＰＧＷ４２０経由で接続するＰＤＮ（ＡＰＮ）とのＰＤＮコネクション確立リクエストであることを示すことができる。
【０１０５】
以下に、上記した任意のＡＰＮへのＰＤＮコネクション確立許可を示すＩｎｄｉｃａｔｏｒを確立許可情報として用いる本発明の第３の実施の形態の手段について説明する。
【０１０６】
本発明の第３の実施の形態におけるシーケンスは、本発明の第２の実施の形態におけるシーケンス（図１０に図示されているシーケンス）と同じであり、ここでは説明を省略する。また、本発明の第３の実施の形態におけるＵＥ１００及びＭＭＥ４３０の構成は、本発明の第２の実施の形態における構成（図１２に図示されているＵＥ１００の構成、及び、図１４に図示されているＭＭＥ４３０の構成）と同じであり、ここでは説明を省略する。
【０１０７】
次に、図１２に図示されている構成を有するＵＥについて、本発明における特徴的な処理を中心に、図１６を用いて詳しく説明する。図１６は、本発明の第３の実施の形態におけるＵＥ１００の動作の一例を示すフローチャートである。本発明の第３の実施の形態におけるＵＥ１００の動作は、本発明の第２の実施の形態におけるＵＥの動作の一例をベースにしており、以下では本発明の第３の実施の形態における特徴的な処理を中心に説明する。
【０１０８】
本発明の第３の実施の形態では、本発明の第２の実施の形態と同様に、ＵＥ１００のＮＡＳレイヤ１２０は、ネットワークとの間にＬＩＰＡ  ＰＤＮコネクションを確立した際に、ネットワーク（ＭＭＥ４３０）から確立許可情報を受信する。ＵＥ１００のＮＡＳ１２０は、受信した確立許可情報が任意Ｉｎｄｉｃａｔｏｒか否かを判断する（図１６のステップＳ１６００１）。受信した確立許可情報が任意Ｉｎｄｉｃａｔｏｒではない場合（すなわち、特定のＡＰＮ情報やＡＰＮリストなどを含む確立許可情報の場合）には、上述した本発明の第２の実施の形態に係る動作（図１３に図示されているフローチャート）を実施する。一方、受信した確立許可情報が任意Ｉｎｄｉｃａｔｏｒである場合には、図１６のステップＳ１６００３以降に示される本発明の第３の実施の形態に係る動作を実施する。
【０１０９】
その後、ＵＥ１００のＮＡＳレイヤ１２０は、新たなＰＤＮコネクション（Ｄｅｄｉｃａｔｅｄ  ｂｅａｒｅｒ）の確立が必要となるＱｏＳ情報を格納したリクエストメッセージをアプリレイヤ１１０から受信すると（図１６のステップＳ１６００３）、ＵＥ１００のＮＡＳレイヤ１２０は、新たなＰＤＮコネクションの確立を必要と判断した場合（例えば、アプリレイヤ１１０からのリクエストがＤｅｄｉｃａｔｅｄ  ｂｅａｒｅｒの確立であることを確認した場合）、リクエストメッセージに格納されているＡＰＮ情報を取得し（図１６のステップＳ１６００５）、取得したＡＰＮ及び任意ＩｎｄｉｃａｔｏｒをＰＤＮコネクション確立リクエストメッセージに格納する（図１６のステップＳ１６００７）。そして、ＵＥ１００のＮＡＳレイヤ１２０は、ＡＰＮ情報及び任意Ｉｎｄｉｃａｔｏｒなどを格納したＰＤＮコネクション確立リクエストメッセージをネットワークへ送信する（図１６のステップＳ１６００９）。
【０１１０】
任意ＩｎｄｉｃａｔｏｒをＰＤＮコネクション確立リクエストメッセージに格納することによって、例えば上記したように、ネットワークオペレータのサービス運用上、マクロネットワークのＰＧＷ４２０経由で接続するＰＤＮコネクションとＬＨＮ２００のＬＧＷ経由で接続するＰＤＮコネクションにおいて共通のＡＰＮを利用する場合に、マクロネットワークのＰＧＷ４２０経由で接続するＰＤＮコネクション確立リクエストであることを明示的に示すことが可能となる。ＵＥ１００は、ネットワーク（ＭＭＥ４３０）から受信した任意Ｉｎｄｉｃａｔｏｒをネットワーク（ＭＭＥ４３０）に通知することによって、従来であれば、ＨｅＮＢ２１０がＬＧＷアドレスを格納するため、ＬＩＰＡ  ＰＤＮコネクション確立リクエストとして扱われていたが、マクロネットワークのＰＧＷ経由のＰＤＮ（ＡＰＮ）へのＰＤＮコネクション確立リクエストとしてネットワーク（ＭＭＥ４３０）が扱えるようにすることが可能となる。
【０１１１】
なお、図１６では、ＵＥ１００がアプリレイヤ１１０から受信したリクエストメッセージ内のＡＰＮを取得してＰＤＮコネクション確立リクエストに格納しているが、本発明の第３の実施の形態では、任意のＡＰＮへのＰＤＮコネクション確立がネットワークによって許可されているため、任意のＡＰＮ（図６Ａ〜図６Ｄに示すようなテーブル情報から取得したＡＰＮ）をＰＤＮコネクション確立リクエストに格納してもよい。テーブル情報を用いてＡＰＮ情報を取得した場合には、アプリレイヤ１１０がリクエスト（要望）するＱｏＳ情報に関連付けられているＡＰＮ情報を選択して、ＰＤＮコネクション確立リクエストに格納することができる。
【０１１２】
また、本発明の第３の実施の形態におけるＭＭＥの動作は、一部を除いて、図１５に示す本発明の第２の実施の形態におけるＭＭＥの動作と同じである。以下では、図１５を参照しながら、本発明の第３の実施の形態における特徴的な処理を中心に説明し、同じ動作の部分については説明を省略する。
【０１１３】
本発明の第２と第３の実施の形態では、ＰＤＮコネクション確立時にネットワーク（ＭＭＥ４３０）からＵＥ１００に通知される確立許可情報の種類が異なっている。本発明の第３の実施の形態におけるＭＭＥ４３０は、図１５のステップＳ１５００４（確立許可情報の選択・生成・格納）でＵＥ１００に通知する確立許可情報として、任意Ｉｎｄｉｃａｔｏｒを使用する。また、任意Ｉｎｄｉｃａｔｏｒは、ＵＥ１００から送信されるＰＤＮコネクション確立リクエストメッセージにおいても格納される場合（例えば、トークンや鍵情報を用いて、新たなＰＤＮコネクションの確立を許可したＵＥ１００であるか識別する場合）がある。
【０１１４】
この任意Ｉｎｄｉｃａｔｏｒは、例えば、上述のように、ＵＥ１００及びネットワーク（ＭＭＥ４３０）が認識可能なトークンや、非特許文献１で開示されているＵＥのＣｏｎｔｅｘｔ情報（例えば、ＩＰアドレスや、ＮＡＳ  ＣＯＵＮＴパラメータ、Ｄｅｆａｕｌｔ  ｂｅａｒｅｒのＢｅａｒｅｒ  ＩＤ、ＩＭＳＩ、鍵を用いた相互認証鍵など）、独自の鍵情報などが考えられる。上記トークンが、任意Ｉｎｄｉｃａｔｏｒとして用いられる場合、例えば、トークンはＵＥ１００とネットワーク（ＭＭＥ４３０）における簡易相互認証鍵として用いることができる。ＵＥ１００が送信するＰＤＮコネクション確立リクエストメッセージにネットワークが通知したトークンを格納することによって、ネットワーク（ＭＭＥ４３０）は同一のトークンであるか否かを確認できるようになり、同一のトークンであると判断した場合に、ネットワーク（ＭＭＥ４３０）は、ＰＤＮコネクション確立リクエストメッセージを許可するようにしてもよい。
【０１１５】
また、上記ＵＥ１００のＣｏｎｔｅｘｔの情報であるＩＰアドレスが任意Ｉｎｄｉｃａｔｏｒとして用いられる場合、ネットワーク（ＭＭＥ４３０）は、ＵＥ１００に割り当てたＩＰアドレスを任意Ｉｎｄｉｃａｔｏｒ（確立許可情報）として利用し、このＩＰアドレスを図１１で示す確立許可情報フィールドに格納してもよい。しかし、ＵＥ１００に割り当てるＩＰアドレスは、非特許文献１で開示されているように、別手段（例えば、ＩＰｖ４アドレスの場合は、ＰＧＷ４２０が割り当ててもよいし、外部サーバ（例えば、ＤＨＣＰサーバ）にＵＥ１００が問い合わせるようにして、ＩＰアドレスを取得してもよい。ＩＰｖ６アドレスの場合は、ＩＰｖ６プレフィックスをＲＡ（Ｒｏｕｔｅｒ  Ａｄｖｅｒｔｉｓｅｍｅｎｔ）メッセージに格納して、ＵＥにおいてＩＰｖ６プレフィックスからＩＰｖ６アドレスを生成させる）でＵＥ１００に通知することができるため、改めて確立許可情報フィールドに格納する必要はない（明示的に確立許可情報フィールドに格納することで、ＵＥ１００における処理の容易性を考慮してもよい）。ＭＭＥ４３０は、特定のＩＰアドレスから受信するＰＤＮコネクション確立リクエストを許可するようにすることで、ＵＥ１００のアプリレイヤ１１０がリクエストするＰＤＮコネクション（Ｄｅｄｉｃａｔｅｄ  ｂｅａｒｅｒ）を確立することができる。上記他の任意Ｉｎｄｉｃａｔｏｒのパラメータ（ＵＥ  Ｃｏｎｔｅｘｔ情報など）においても同様である。
【０１１６】
また、ＵＥ１００へ任意Ｉｎｄｉｃａｔｏｒを通知する場合、ＰＤＮコネクション確立許可メッセージ（例えば、非特許文献１で開示されるようなＡｔｔａｃｈ  ａｃｃｅｐｔメッセージやＰＤＮ  ｃｏｎｎｅｃｔｉｖｉｔｙ  ａｃｃｅｐｔメッセージ）に格納されてもよい。例えば、任意ＩｎｄｉｃａｔｏｒがＡｔｔａｃｈ  ａｃｃｅｐｔメッセージに格納される場合には、図１１に示すように既存のＡｔｔａｃｈ  ａｃｃｅｐｔメッセージに新たなＩＥを追加してもよい。また、ＰＤＮコネクション確立後に、ＭＭＥ４３０からＨｅＮＢ２１０やｅＮＢ３１０に対して、任意ＩｎｄｉｃａｔｏｒをＵＥ１００に通知するためのブロードキャスト情報を送信してもよい。これにより、ＨｅＮＢ２１０やｅＮＢ３１０が、ＵＥ１００に対して、非特許文献７で開示されるＳＩＢ（Ｓｙｓｔｅｍ  Ｉｎｆｏｒｍａｔｉｏｎ  Ｂｌｏｃｋ）を用いて通知することもできる。
【０１１７】
なお、本発明の第３の実施の形態も、本発明の第１と第２の実施の形態と同様に、非特許文献１で開示されるネットワーク接続手順（Ａｔｔａｃｈ  ｐｒｏｃｅｄｕｒｅ）を用いてネットワークとの間にＬＩＰＡ  ＰＤＮコネクションを確立する動作を一例として説明したが、既にＰＤＮコネクションを複数確立済みの状態で、新たなアプリケーションがＵＥのＮＡＳに新たなＰＤＮコネクション（Ｄｅｄｉｃａｔｅｄ  ｂｅａｒｅｒ）の確立が必要となるケースにおいても、本発明の第３の実施の形態は適用可能である。
【０１１８】
以上、本発明の第３の実施の形態によれば、本発明の第１及び第２の実施の形態における効果に加えて、ネットワーク（ＭＭＥ４３０）が、任意のＡＰＮへのＰＤＮコネクションの確立を許可する確立許可情報をＵＥ１００へ通知することによって、ネットワーク（ＭＭＥ４３０）が確立許可情報に格納するためのＡＰＮ情報生成・選択処理に係る負荷の軽減、ＵＥ１００におけるＡＰＮ情報の一致の確認処理に係る負荷の軽減など実現することができる。
【０１１９】
なお、本発明の第１〜第３の実施の形態におけるＵＥ１００のＮＡＳ１２０が使用するテーブル情報は、本発明の第１の実施の形態で説明したように、あらかじめ実装してある（静的に保持している）ものであってもよいし、ネットワークから動的に通知されるものでもよい。例えば、オペレータポリシに基づいて、ネットワーク（ＭＭＥ４３０）からＨｅＮＢ２１０やｅＮＢ３１０に対して、ネットワークによって生成したテーブル情報、又は、テーブル情報を生成する材料をＵＥ１００に通知するように指示し、ＨｅＮＢ２１０やｅＮＢ３１０はブロードキャスト、又は、特定のＵＥ１００に向けての送信するためのリソース（ＳＩＢなど）を用いて、テーブル情報に関連した情報を送信してもよい。テーブル情報を生成する材料（例えば、アプリケーションＩＤの一覧や、ＱＣＩの一覧など）がＵＥ１００に通知される場合、ＵＥ１００は受信した材料を用いて、図６Ａ〜図６Ｄに示すようなテーブル情報を構築することができる。
【０１２０】
なお、本発明の第１〜第３の実施の形態では、ＬＩＰＡ  ＰＤＮコネクションを確立済みの状態のＵＥ１００において、新たなＰＤＮコネクションを確立すると判断した場合、マクロネットワークのＰＧＷ４２０経由でＰＤＮコネクションを確立することを前提として説明したが、ＵＥ１００が意図的に新たなＰＤＮコネクションをＬＩＰＡ  ＰＤＮコネクションとして確立したいと判断する場合（例えば、任意Ｉｎｄｉｃａｔｏｒを受信した後、図６Ａ〜図６Ｄに示すようなテーブル情報を用いるようにし、ＡＰＮ情報を選択できるようにする場合）は、例えば、本発明の第３の実施の形態を例に説明すると、任意Ｉｎｄｉｃａｔｏｒを意図的に格納しないで、ＰＤＮコネクション確立リクエストメッセージを送信してもよい。また、ネットワーク（ＭＭＥ４３０）がＵＥ１００に通知する確立許可情報として、ＬＩＰＡ  ＰＤＮコネクション確立をＵＥがリクエストできるような情報（例えば、トークンを２種類用意しておき、１つはＬＩＰＡ  ＰＤＮコネクションとして扱い、もう１つは第３の実施の形態のようにマクロネットワークのＰＧＷとのＰＤＮコネクションとして扱う）を用いてもよい。
【０１２１】
なお、本発明の第２と第３の実施の形態では、ネットワーク（ＭＭＥ４３０）がＬＩＰＡ  ＰＤＮコネクション確立時に確立許可情報を通知する例を用いて説明した。これに加えて、ＬＨＮ２００のＬＧＷ２２０が、ＬＩＰＡ  ＰＤＮコネクション確立時に、ＬＧＷ２２０とＵＥ１００のみが扱う情報を用いて、確立許可情報を利用してもよい。例えば、非特許文献１で開示されるＵＥ１００とＬＧＷ２２０（ＰＧＷ）以外の装置（ＭＭＥ４３０やＳＧＷ４１０、ＨｅＮＢ２１０など）上では透過的に扱われるパラメータであるＰＣＯ（Ｐｒｏｔｏｃｏｌ  Ｃｏｎｆｉｇｕｒａｔｉｏｎ  Ｏｐｔｉｏｎ）を用いて、ＬＧＷ２２０からＵＥに確立許可情報を通知してもよい。ＬＧＷ２２０は、管理している複数のＡＰＮ情報をリスト（Ｅｑｕｉｖａｌｅｎｔ  ＡＰＮ  ｌｉｓｔ）として、ＵＥ１００に送信してもよい。一般的にＬＧＷ２２０（ＰＧＷ）は、複数のＰＤＮ（ＡＰＮ）と関連付いている場合があり、Ｅｑｕｉｖａｌｅｎｔ  ＡＰＮ  ｌｉｓｔを確立許可情報として利用する場合は、ＰＤＮコネクション確立が可能なＡＰＮを他の装置に問い合わせる必要もない観点で有効である。
【０１２２】
なお、本発明の第２と第３の実施の形態では、ネットワークからＵＥ１００に対して、確立許可情報を通知するタイミングとして、ＬＩＰＡ  ＰＤＮコネクション確立時を一例として説明したが、ＰＤＮコネクション確立時ではなく、非特許文献１で開示されるハンドオーバ手順や、ＩＤＬＥ状態のＵＥ１００が他セルのカバレッジ配下にいるときにＵＥへ通知可能なＳＩＢなどを用いてもよい。これにより、ＰＤＮコネクション確立時ではなく、任意のタイミングで、ネットワークは確立許可情報をＵＥに通知することができる。
【０１２３】
なお、本発明の第２と第３の実施の形態における確立許可情報では、特定のＡＰＮ、Ｅｑｕｉｖａｌｅｎｔ  ＡＰＮ  ｌｉｓｔ、任意Ｉｎｄｉｃａｔｏｒのいずれかが格納されるように説明したが、例えば、特定のＡＰＮとＥｑｕｉｖａｌｅｎｔ  ＡＰＮ  ｌｉｓｔの両方を確立許可情報としてＵＥ１００に通知することで、特定のＱＣＩの場合は特定ＡＰＮを利用するようにし、それ以外のＱＣＩの場合は、Ｅｑｕｉｖａｌｅｎｔ  ＡＰＮ  ｌｉｓｔを利用するようにしてもよい。
【０１２４】
また、本発明の第１から第３の実施の形態におけるＵＥでは、アプリレイヤから高ＱｏＳの通信経路（Ｄｅｄｉｃａｔｅｄ  ｂｅａｒａｒ）の確立がリクエストされ、マクロネットワーク経由でＰＤＮコネクションを確立するように説明したが、このときＵＥ１００はマクロネットワークと接続できる環境（ＬＨＮ２００やＥ−ＵＴＲＡＮ３００のカバレッジ内）であれば、マクロネットワークの基地局（ｅＮＢ３１０）に接続するための移動などをしなくてよい。
【０１２５】
また、マクロネットワーク経由でＰＧＷ４２０と確立するＰＤＮコネクションと、ＬＨＮ２００経由のＬＧＷ２２０と確立するＬＩＰＡ  ＰＤＮコネクションが関連するＡＰＮが異なる場合、ネットワークオペレータから割り当てられるＤｅｆａｕｌｔ  ＱｏＳ（Ｄｅｆａｕｌｔ  ｂｅａｒｅｒに割り当てられるＱｏＳ）が異なる可能性がある。この場合、ＵＥ１００はどちらのＤｅｆａｕｌｔ  ｂｅａｒｅｒをアプリからのリクエストに対して適用するか、リクエストメッセージに格納されているＱｏＳ情報（例えば、ＱＣＩやＧＢＲ、ＭＢＲ）を基に判断してもよい。
【０１２６】
また、本発明の第１から第３の実施の形態において、ＵＥ１００のＮＡＳ１２０が利用するテーブル情報の変化形として、特定の情報（例えば、特定のＱＣＩや、特定のＡＰＮなど）が格納されている場合に、対応するＡＰＮ情報を探すのではなく、エラー、又は、拒絶する処理をしてもよい。例えば、図６Ｃ又は図６Ｄに示す「ＡＰＮとＱｏＳ情報対応テーブル」におけるＡＰＮ列欄にエラー、又は、拒絶を示す値を格納しておくことで対応してもよい。
【０１２７】
また、ＵＥ１００のＮＡＳ１２０によるテーブル情報の使い方の変化形として、例えば、「ＱＣＩ＝７〜８」と登録されたテーブル情報をＵＥ１００のＮＡＳ１２０が保持する場合に、アプリレイヤ１１０からのリクエストメッセージに格納されるＱＣＩが「ＱＣＩ＝７、又は、８」が格納される際、ＵＥ１００のＮＡＳ１２０はＡＰＮ１を選択するという使い方にしてもよい（不図示）。また、「１＞ＱＣＩ＞＝７」と登録されたテーブル情報をＵＥ１００のＮＡＳ１２０が保持する場合に、アプリレイヤ１１０からのリクエストメッセージに格納されるＱＣＩが「ＱＣＩ＝２」や「ＱＣＩ＝７」などが格納される際、関連するＡＰＮ（例えば、ＡＰＮ１）を選択するという使い方にしてもよい（不図示）。
【０１２８】
また、ＵＥ１００によるＥｎｔｅｒｐｒｉｓｅ／Ｒｅｓｉｄｅｎｔｉａｌネットワーク６００へのアクセス手段として、ＵＥ１００がマクロネットワークのＰＧＷ４２０との間にＰＤＮコネクションを確立し、ＰＤＮ５００経由で、例えば、ＶＰＮ（Ｖｉｒｔｕａｌ  Ｐｒｉｖａｔｅ  Ｎｅｔｗｏｒｋ）セッションを確立して、Ｅｎｔｅｒｐｒｉｓｅ／Ｒｅｓｉｄｅｎｔｉａｌネットワーク６００にリモートアクセスするケースや、マクロネットワークのＰＧＷ４２０からアクセス可能なＰＤＮ５００を経由せずにＳＧＷ４１０とＬＨＮ２００のＬＧＷ２２０又はＨｅＮＢ２１０間のインタフェース（図１のバックホール７００を通過するインタフェースに相当）を利用してリモートアクセスするケースなどがある（非特許文献８を参照）。このようなリモートアクセスは、ＲＩＰＡ（Ｒｅｍｏｔｅ  ＩＰ  Ａｃｃｅｓｓ）やＭＲＡ（Ｍａｎａｇｅｄ  Ｒｅｍｏｔｅ  Ａｃｃｅｓｓ  ｔｏ  ｈｏｍｅ  ｂａｓｅｄ  ｎｅｔｗｏｒｋ）、ＣＳＮ（Ｃｏｎｔｉｎｕｉｔｙ  ｏｆ  Ｄａｔａ  Ｓｅｓｓｉｏｎｓ  ｔｏ  Ｌｏｃａｌ  Ｎｅｔｗｏｒｋｓ）などとも呼ばれる。
【０１２９】
このリモートアクセス時においても、本発明は適用できる。例えば、ＵＥ１００が特定のＨｅＮＢ２１０や、ＣＳＧ（Ｃｌｏｓｅｄ  Ｓｕｂｓｃｒｉｂｅｒ  Ｇｒｏｕｐ）セル、フェムトセルにハンドオーバ時に、ＵＥ１００のＮＡＳ１２０が保持するテーブル情報やネットワーク（ＭＭＥ４３０やＬＧＷ２２０）から通知される確立許可情報の使用を開始してもよい。例えば、ＵＥ１００は、非特許文献１で開示されるハンドオーバ手順でネットワークから通知されるメッセージ（例えば、Ｈａｎｄｏｖｅｒ  ｃｏｍｍａｎｄメッセージ）を受信することで、テーブル情報や確立許可情報の使用を開始してもよい。
【０１３０】
なお、上記ではハンドオーバのようなＵＥ１００が通信状態（ＣＯＮＮＥＣＴＥＤモード）を例に説明したが、非通信時のアイドルモード時のＵＥ１００が、特定のＨｅＮＢ２１０やＣＳＧセル、フェムトセル配下に移動する際においても同様に適用可能である。つまり、ＵＥ１００が特定のロケーション（例えば、特定の基地局（ＨｅＮＢ２１０、ＣＳＧセル、フェムトセル）のカバレッジ内）いるとき（ＵＥ１００が特定の基地局のカバレッジ内にいることを検知可能な報知情報（例えば、基地局ＩＤやセルＩＤなど）を受信した際）や特定のオペレータネットワークに接続しているとき（ＵＥ１００がオペレータを識別可能なＰＬＭＮ（Ｐｕｂｌｉｃ  Ｌａｎｄ  Ｍｏｂｉｌｅ  Ｎｅｔｗｏｒｋ）  ＩＤを受信した際）、特定のＡＰＮを使用するとき（例えば、契約サービスで利用可能なＡＰＮが異なっていて、ＵＥ１００毎に利用するＡＰＮが異なる場合があるとき）のみ、テーブル情報や確立許可情報を用いるようにしてもよい。
【０１３１】
また、本発明の第１から第３の実施の形態では、ＵＥ１００のＮＡＳ１２０がアプリレイヤ１１０から送信されるアプリケーションリクエストに格納されているアプリケーションのパケットを通信するために必要な情報（例えば、ＱｏＳ情報（例えば、ＱＣＩやＧＢＲ、ＭＢＲなど）やＡＰＮ情報）を用いて、Ｄｅｄｉｃａｔｅｄ  ｂｅａｒｅｒを確立できないと判断する際に、確立済みのＬＩＰＡ  ＰＤＮコネクションとは別に、マクロネットワークのＰＧＷ４２０との間に新たなＰＤＮコネクションを確立できるか否かの情報を用いて判断してもよい。つまり、図８のステップＳ８００１とステップＳ８００３、又は、図１３のステップＳ８００１とＳ８００３の間で、Ｄｅｄｉｃａｔｅｄ  ｂｅａｒｅｒを確立可能か否かについて判断してもよい。ＵＥ１００のＮＡＳ１２０がＤｅｄｉｃａｔｅｄ  ｂｅａｒｅｒを確立できないと判断した場合、図８のステップＳ８００３や図１３のステップＳ８００３を実施する。また、Ｄｅｄｉｃａｔｅｄ  ｂｅａｒｅｒを確立できると判断した場合には、Ｄｅｄｉｃａｔｅｄ  ｂｅａｒｅｒを確立する処理（例えば、非特許文献１で開示されるＢｅａｒｅｒ  Ｒｅｓｏｕｒｃｅ  Ｍｏｄｉｆｉｃａｔｉｏｎリクエストメッセージ送信）を実施する。
【０１３２】
このＤｅｄｉｃａｔｅｄ  ｂｅａｒｅｒの確立可否の判断は、ネットワークから通知される情報（例えば、Ｃｏｎｎｅｃｔｉｖｉｔｙ  ｔｙｐｅ  ＩＥやベアラ確立拒絶メッセージ／ＰＤＮコネクション確立拒絶メッセージに格納されている拒絶理由など）を用いてもよい。
【０１３３】
例えば、ネットワークから通知される情報として、Ｃｏｎｎｅｃｔｉｖｉｔｙ  ｔｙｐｅ  ＩＥが用いられる場合、ＵＥ１００のＮＡＳ１２０はアプリレイヤ１１０からアプリケーションリクエスト受信時に、ＵＥ１００が保持しているコンテキスト情報から確立済みのＰＤＮコネクションのタイプ情報を取得し、ＬＩＰＡ  ＰＤＮコネクションを示している場合（Ｄｅｄｉｃａｔｅｄ  ｂｅａｒｅｒを確立できないと判断する場合）に限り、新たなＰＤＮコネクションを確立可能か確認する処理（テーブル情報や確立許可情報を用いた確認処理）を実施してもよい。
【０１３４】
また、ネットワークから通知される情報として、ベアラ確立拒絶メッセージ／ＰＤＮコネクション確立拒絶メッセージが用いられる場合、確立済みのＰＤＮコネクションのタイプ情報を確認しなくても、ベアラ確立／ＰＤＮコネクション確立リクエストメッセージの結果を用いて、新たなＰＤＮコネクションを確立可能か否かを確認する処理（テーブル情報や確立許可情報を用いた確認処理）を実施してもよい。
【０１３５】
また、上記の本発明の実施の形態の説明で用いた機能ブロックは、典型的には集積回路であるＬＳＩ（Ｌａｒｇｅ  Ｓｃａｌｅ  Ｉｎｔｅｇｒａｔｉｏｎ）として実現される。これらは個別に１チップ化されてもよいし、一部又はすべてを含むように１チップ化されてもよい。なお、ここでは、ＬＳＩとしたが、集積度の違いにより、ＩＣ（Iｎｔｅｇｒａｔｅｄ  Ｃｉｒｃｕｉｔ）、システムＬＳＩ、スーパーＬＳＩ、ウルトラＬＳＩと呼称されることもある。
【０１３６】
また、集積回路化の手法はＬＳＩに限るものではなく、専用回路又は汎用プロセッサで実現してもよい。ＬＳＩ製造後に、プログラムすることが可能なＦＰＧＡ（Ｆｉｅｌｄ  Ｐｒｏｇｒａｍｍａｂｌｅ  Ｇａｔｅ  Ａｒｒａｙ）や、ＬＳＩ内部の回路セルの接続や設定を再構成可能なリコンフィギュラブル・プロセッサを利用してもよい。
【０１３７】
さらには、半導体技術の進歩又は派生する別技術によりＬＳＩに置き換わる集積回路化の技術が登場すれば、当然、その技術を用いて機能ブロックの集積化を行ってもよい。例えば、バイオ技術の適応などが可能性としてあり得る。
【産業上の利用可能性】
【０１３８】
本発明は、通信ノード（ＵＥ）がＬＩＰＡを行う環境において、従来の技術ではリジェクトされてしまう可能性があったアプリケーションからのリクエストに基づく適切なパケット転送を実現するという効果、及び、不必要な処理及び不必要な通信リソースの割り当てを回避するという効果を有し、ＬＩＰＡを実施するための通信技術に適用可能である。
【符号の説明】
【０１３９】
１００  ＵＥ（通信ノード）
１０１  アプリケーションレイヤ
１０２  ＴＥ
１０３  ＴＡ
１０４  ＭＴ
１１０  アプリレイヤ
１２０  ＮＡＳレイヤ
２００  ＬＨＮ（ローカルネットワーク）
２１０  ＨｅＮＢ（基地局）
２２０  ＬＧＷ（ゲートウェイ）
３００  Ｅ−ＵＴＲＡＮ
３１０  ｅＮＢ
４００  ＥＰＣ（マクロネットワーク）
４１０  ＳＧＷ
４２０  ＰＧＷ
４３０  ＭＭＥ
４４０  ＨＳＳ
４５０  ＰＣＲＦ
５００  ＰＤＮ
６００  Ｅｎｔｅｒｐｒｉｓｅ／Ｒｅｓｉｄｅｎｔｉａｌネットワーク
７００  バックホール
７０１、１４０１  通信処理部
７０２、１４０２  ＮＡＳ処理部
７０３  テーブル情報保持部
７０４  アプリ処理部
７０５  確立許可情報確認部
１４０３  確立許可情報生成部
【図１】
2013141106.tif 000003
【図２】
2013141106.tif 000004
【図３】
2013141106.tif 000005
【図４】
2013141106.tif 000006
【図５】
2013141106.tif 000007
【図６Ａ】
2013141106.tif 000008
【図６Ｂ】
2013141106.tif 000009
【図６Ｃ】
2013141106.tif 000010
【図６Ｄ】
2013141106.tif 000011
【図７】
2013141106.tif 000012
【図８】
2013141106.tif 000013
【図９】
2013141106.tif 000014
【図１０】
2013141106.tif 000015
【図１１】
2013141106.tif 000016
【図１２】
2013141106.tif 000017
【図１３】
2013141106.tif 000018
【図１４】
2013141106.tif 000019
【図１５】
2013141106.tif 000020
【図１６】
2013141106.tif 000021