ネットワークとコネクションを確立可能な通信ノードであって、アプリケーション要求情報と接続先情報との対応関係情報を保持する保持手段と、前記対応関係情報に基づいて、前記ネットワークとのコネクションを確立するよう要求するアプリケーションリクエストに含まれているアプリケーション要求情報に対応した接続先情報を取得する取得手段と、前記対応関係情報から取得した前記接続先情報に対応するローカルアクセスコネクションが確立されているか否かを判断する判断手段と、前記ローカルアクセスコネクションが既に確立されている場合には、前記アプリケーションリクエストが要求するコネクションとして、前記ローカルアクセスコネクションを利用する利用手段と、前記ローカルアクセスコネクションが確立されていない場合には、前記アプリケーションリクエストが要求するコネクションを確立するために、前記対応関係情報から取得した前記接続先情報を格納したコネクション確立リクエストメッセージを前記ネットワークへ送信する送信手段とを、有する通信ノード。前記ローカルアクセスコネクションを経由した通信相手と通信を行うことが可能な接続先情報を格納した確立許可情報を前記ネットワークから受信する受信手段をさらに有し、前記確立許可情報に格納されている接続先情報が、特定の接続先を示す情報を示しているとき、前記ローカルアクセスコネクションが確立されていない場合であって、さらに、前記対応関係情報から取得した前記接続先情報が前記確立許可情報に格納されている前記特定の接続先を示す情報に含まれている場合にのみ、前記アプリケーションリクエストが要求するコネクションを確立するために、前記対応関係情報から取得した接続先情報を格納した前記コネクション確立リクエストメッセージを前記ネットワークへ送信する請求項1に記載の通信ノード。前記接続先情報は、ローカルアクセス又は非ローカルアクセスのいずれか一方のコネクションの確立でのみ使用されるよう割り当てられている請求項1に記載の通信ノード。前記アプリケーション要求情報は、QoS情報又はアプリケーションID情報を含む請求項1に記載の通信ノード。前記接続先情報は、ローカルアクセス及び非ローカルアクセスの両方で使用可能な共通の情報として割り当てられている請求項1に記載の通信ノード。前記アプリケーションリクエストに含まれているアプリケーション要求情報に基づいて、前記取得手段と前記判断手段と前記利用手段と前記送信手段とを動作させるか否かを判断する制御手段をさらに有する請求項1に記載の通信ノード。前記制御手段が、前記取得手段と前記判断手段と前記利用手段と前記送信手段とを動作させるか否かを判断する際に、事前にネットワークから通知された情報をさらに用いる請求項6に記載の通信ノード。前記事前にネットワークから通知された情報は、ConnectivitytypeIEを含む請求項7に記載の通信ノード。前記制御手段が、前記取得手段と前記判断手段と前記利用手段と前記送信手段とを動作させるか否かを判断する際に、前記ローカルアクセスコネクション内の通信経路の確立を試みた結果をさらに用いる請求項6に記載の通信ノード。前記通信経路の確立を試みた結果は、通信経路確立拒絶メッセージに格納されている拒絶理由を含む請求項9に記載の通信ノード。ネットワークとコネクションを確立可能な通信ノードであって、アプリケーション要求情報と接続先情報との対応関係情報を保持する保持手段と、前記対応関係情報に基づいて、前記ネットワークとのコネクションを確立するよう要求するアプリケーションリクエストに含まれているアプリケーション要求情報に対応した接続先情報を取得する取得手段と、前記対応関係情報から取得した前記接続先情報に対応するローカルアクセスコネクションが確立されているか否かを判断する判断手段と、前記ローカルアクセスコネクションを経由した通信相手と通信を行うことが可能な接続先情報を格納した確立許可情報を前記ネットワークから受信する受信手段と、前記ローカルアクセスコネクションが既に確立されている場合には、前記アプリケーションリクエストが要求するコネクションとして、前記ローカルアクセスコネクションを利用する利用手段と、前記ローカルアクセスコネクションが確立されていない場合には、前記アプリケーションリクエストが要求するコネクションを確立するために、前記確立許可情報に格納されている接続先情報が、任意の接続先を示す情報を示しているとき、前記アプリケーションリクエストに含まれている接続先情報、又は、前記対応関係情報から取得した接続先情報を格納したコネクション確立リクエストメッセージを前記ネットワークへ送信する送信手段とを、有する通信ノード。前記ネットワークへ送信する前記コネクション確立リクエストに、前記確立許可情報に格納されている情報を挿入する請求項11に記載の通信ノード。従来の技術によれば、UE100のNAS120は、確立されたPDNコネクションがLIPAPDNコネクションか否かを把握していない場合、LIPAにおいてサポートされていないDedicatedBearerの確立を試みてしまい、無駄な通信リソースが割り当てられてしまうという課題が生じる。一方、上述のように、ネットワークがUE100のNAS120に対して、確立されたPDNコネクションがLIPAPDNコネクションか否かを示すConnectivitytypeIEを必ず通知することも可能である。この場合には、UE100のNAS120は、確立されたPDNコネクションがLIPAPDNコネクションか否かを把握することが可能となる。しかしながら、不必要な通信リソースの割り当てを回避することが可能であるが、この場合には、UE100のNAS120は、LIPAPDNコネクションのDefaultbearerでは通信できないアプリケーションからのリクエストを全てリジェクトしてしまうことにある。つまり、LIPAPDNコネクションのDefaultbearerでのパケット通信が、例えば、アプリケーションから要求されるQoS要件を満たさないと判断される場合には、UE100のNAS120は、そのアプリケーションからのリクエストをリジェクトしてしまうという課題が生じる。上記の課題に鑑み、本発明は、UE100がLIPAを行う環境において、従来の技術ではリジェクトされてしまう可能性があったアプリケーションからのリクエストに基づく適切なパケット転送を実現し、かつ、不必要な処理及び不必要な通信リソースの割り当てを回避することが可能となる通信ノードを提供することを目的とする。上記の目的を達成するため、本発明の通信ノードは、ネットワークとコネクションを確立可能な通信ノードであって、アプリケーション要求情報と接続先情報との対応関係情報を保持する保持手段と、前記対応関係情報に基づいて、前記ネットワークとのコネクションを確立するよう要求するアプリケーションリクエストに含まれているアプリケーション要求情報に対応した接続先情報を取得する取得手段と、前記対応関係情報から取得した前記接続先情報に対応するローカルアクセスコネクションが確立されているか否かを判断する判断手段と、前記ローカルアクセスコネクションが既に確立されている場合には、前記アプリケーションリクエストが要求するコネクションとして、前記ローカルアクセスコネクションを利用する利用手段と、前記ローカルアクセスコネクションが確立されていない場合には、前記アプリケーションリクエストが要求するコネクションを確立するために、前記対応関係情報から取得した前記接続先情報を格納したコネクション確立リクエストメッセージを前記ネットワークへ送信する送信手段とを、有する。上記の構成により、通信ノードUEがLIPAを行う環境において、従来の技術ではリジェクトされてしまう可能性があったアプリケーションからのリクエストに基づく適切なパケット転送を実現し、かつ、不必要な処理及び不必要な通信リソースの割り当てを回避することが可能となる。また、上記の目的を達成するため、本発明の通信ノードは、ネットワークとコネクションを確立可能な通信ノードであって、アプリケーション要求情報と接続先情報との対応関係情報を保持する保持手段と、前記対応関係情報に基づいて、前記ネットワークとのコネクションを確立するよう要求するアプリケーションリクエストに含まれているアプリケーション要求情報に対応した接続先情報を取得する取得手段と、前記対応関係情報から取得した前記接続先情報に対応するローカルアクセスコネクションが確立されているか否かを判断する判断手段と、前記ローカルアクセスコネクションを経由した通信相手と通信を行うことが可能な接続先情報を格納した確立許可情報を前記ネットワークから受信する受信手段と、前記ローカルアクセスコネクションが既に確立されている場合には、前記アプリケーションリクエストが要求するコネクションとして、前記ローカルアクセスコネクションを利用する利用手段と、前記ローカルアクセスコネクションが確立されていない場合には、前記アプリケーションリクエストが要求するコネクションを確立するために、前記確立許可情報に格納されている接続先情報が、任意の接続先を示す情報を示しているとき、前記アプリケーションリクエストに含まれている接続先情報、又は、前記対応関係情報から取得した接続先情報を格納したコネクション確立リクエストメッセージを前記ネットワークへ送信する送信手段とを、有する。上記の構成により、通信ノードUEがLIPAを行う環境において、従来の技術ではリジェクトされてしまう可能性があったアプリケーションからのリクエストに基づく適切なパケット転送を実現し、かつ、不必要な処理及び不必要な通信リソースの割り当てを回避することが可能となる。本発明は、上記の構成を有しており、通信ノードUEがLIPAを行う環境において、従来の技術ではリジェクトされてしまう可能性があったアプリケーションからのリクエストに基づく適切なパケット転送を実現するという効果、及び、不必要な処理及び不必要な通信リソースの割り当てを回避するという効果を有する。以下、図面を参照しながら、本発明の第1から第3の実施の形態について説明する。まず、図1を参照しながら、本発明の第1から第3の実施の形態に共通するシステム構成について説明する。図1は、本発明の第1から第3の実施の形態並びに従来の技術に共通するシステム構成の一例を示す図である。上述のように、図1に図示されているネットワークは、UE100と無線接続する基地局E-UTRAN300ではeNBeNodeB310、ローカルネットワークLNLocalNetworkやLHNLocalHeNBNetworkとも呼ばれる200では、HeNBHomeeNB210と呼ばれる、UE100の移動管理を担当するMME430、UE100のサブスクリプション情報を保持するHSS440、ユーザデータ配信制御を行うSGW410、UE100に対するアドレス割り当てやPDN500とSGW410との間のユーザデータ転送並びに経路制御を行うPGW420、LHN200においてEnterprise/Residentialネットワーク600とSGW410、若しくは、Enterprise/Residentialネットワーク600とHeNB210との間のユーザデータ転送並びに経路制御を行うLGW220、UE100のサブスクリプションデータSubscriptiondata並びに通信コンテキストなどを管理保持しているサーバHSS440、課金ルールやユーザとネットワークオペレータ間の契約情報からQoSを算出するPCRF450を有している。なお、UE100は、このネットワークを介すことで、Enterprise/Residentialネットワーク600やPDN500と通信可能である。また、図1では、LGW220はHeNB210とは別の装置としているが、物理的に1つの装置として扱い、論理的に別装置として扱ってもよい。ここで、UE100は少なくとも1つ以上の通信インタフェースを持ち、ネットワーク例えば、E-UTRAN114又はLHN200に接続することが可能である。なお、UE100は、図示されているネットワーク例えば、E-UTRAN300又はLHN200に、同時に、あるいは排他的に接続するものであってもよいが、1つの通信インタフェースで同時に接続できるのは1つのネットワークのみとする。UE100は、HeNB210やeNB310などの基地局を介して通信システムに接続し、当該ネットワークを通じて、PDN500やEnternprise/Residentialネットワーク600と通信可能である。なお、UE100がLHN200のLGW220との間にLIPAPDNコネクションを確立する場合、EPC400内のエンティティMME430やSGW410などが動作してLIPAPDNコネクションを確立し、UE100はEnterprise/Residentialネットワーク600と通信可能になる。また、上述したように、UE100は3GPPが制定する手順を用いることで、LHN200のLGW220との間にLIPAPDNコネクションを確立することができる。なお、以下では、主に図1で示したネットワークの構成要素を用いて、LIPAPDNコネクションを確立する場合について説明するが、3GPPが制定するUTRANUMTSTerrestrialRadioAccessNetworkに対しても、本発明は適用可能である。以下、本発明の第1から第3の実施の形態において前提とするシステム動作の一例について、図4を用いて説明する。図4は、従来技術のネットワーク接続手順Attachprocedureとも呼ばれるであり、かつ、本発明の第1から第3の実施の形態において前提とするシステム動作の一例を説明するためのシーケンス図である。なお、図4は、非特許文献1のFigure5.3.2.1-1:Attachprocedureであり、各シーケンスの詳細な説明は非特許文献1に基づくものとする。以下、図4を参照しながら、本発明の第1から第3の実施の形態の説明例として、UE100が、LHN200のHeNB210とEPC400のMME430、SGW410を経由して、LIPAPDNコネクションを確立する場合を説明する。UE100がLHN200のHeNB210経由でLGW220とLIPAPDNコネクションを確立する手順は、UE100がE-UTRAN300のeNB310経由でPGW420とPDNコネクションを確立する手順図4と一部を除いて同じ手順となっている。LIPAPDNコネクションを確立する手順がE-UTRAN300のeNB310経由で確立する手順と異なる点は、確立するPDNコネクションがLIPAを目的としたものとネットワークMME430で判断された場合例えば、UE100からのAttachrequestメッセージに格納されたAPNがLIPA向けAPNであると判断された場合や、HeNB210からLGWアドレスが通知される場合、PDNコネクションの終端端末が従来のPGW420ではなく、LGW220となる点が挙げられる。また、従来のPDNコネクションを確立する手順には、確立したPDNコネクションが最終的にLIPAPDNコネクションか通常のPDNコネクションPGW420で終端するPDNコネクションのどちらであるかをUE100に通知するオプションの情報ConnectivitytypeIEInformationElementが存在している。本発明では、従来ではオプションとして扱われていた上記ConnectivitytypeIEを確実マンダトリーに、例えば、ネットワーク接続手順時などでUE100へ送信する情報であることを前提とする。このConnectivitytypeIEが、ネットワークMME430からUE100に通知されるタイミングは、図4のステップ17である非特許文献4を参照。UE100とネットワークとの間で、図4に示す手順を行うことによって、UE100はネットワークLGW220との間にLIPAPDNコネクションを確立することが可能となる。<第1の実施の形態>以下、本発明の第1の実施の形態について説明する。図5では、UE100のNAS120は、図4で示すネットワーク接続手順を用いて、ネットワークとの間にLIPAPDNコネクションを確立する。また、そのLIPAPDNコネクション確立手順中に、ネットワークMME430は、UE100のNAS120に対して、確立したPDNコネクションはLIPAPDNコネクションであることを示す情報ConnectivitytypeIEを通知する図5のステップS5001。図5のステップS5001は、図4で示すネットワーク接続手順に相当するステップである。続いて、例えば、UE100を操作するユーザや自動更新が設定されているアプリケーションによって、上位レイヤのアプリレイヤ110においてアプリが起動される図5のステップS5003。アプリ起動後、アプリレイヤ110から下位レイヤのNAS120に対して、アプリケーションのパケットを通信するために必要な情報アプリケーション要求情報:例えば、EPSベアラにおけるQoS情報例えば、QCIやAPN、アプリケーションID、GBR、MBRなどの中の少なくとも1種類又は複数種類が格納されたリクエストが送信される図5のステップS5005。従来の技術では、確立されているPDNコネクションがLIPAPDNコネクションであるか否かをNASレイヤ120からアプリレイヤ110へ通知する手段が規定されていない非特許文献5を参照。したがって、アプリレイヤ110は、確立されたPDNコネクションがLIPAPDNコネクションであっても、Dedicatedbearerの確立を要求するための情報例えば、QCIやGBRなどのQoS情報を格納したリクエストメッセージをNASレイヤ120に送信する可能性がある。従来の技術では、図3のステップS3009で示すように、BearerResourceModificationRequestを送信して、ネットワークMMEによってリジェクトされるかNAS120がLIPAPDNコネクションか否かを識別できない場合、あるいは、リクエストのリジェクトをアプリレイヤ110に対して通知するNAS120がLIPAPDNコネクションか否かを識別できる場合。一方、本発明の第1の実施の形態では、ステップS5005のリクエストメッセージをアプリレイヤ110から受信した際、NASレイヤ120は、アプリレイヤ110から受信したリクエストメッセージに基づくDedicatedbearerをマクロネットワークで確立できるか否かを判断する。具体的には、NASレイヤ120は、例えばUE100があらかじめ保持している対応関係情報例えばテーブル情報として保持を参照して、このリクエストに応じたDedicatedbearerをマクロネットワークで確立できるか否かを判断する図5のステップS5007。なお、アプリレイヤ110から受信したリクエストメッセージにAPNが格納されている場合には、NASレイヤ120は、ステップS5007の判断を行う前に、リクエストメッセージに格納されているAPNが、確立済みのLIPAPDNコネクションの接続先として使用されているAPNと一致するか否かを判断し、確立済みのLIPAPDNコネクションの接続先として使用されているAPNと一致する場合にのみ、ステップS5007以降の処理を行ってもよい。UE100のNASレイヤ120は、LHN200のLGW220との間に確立するLIPAPDNコネクション内のDefaultbearerを利用してDedicatedbearerの確立を試みるのではなく、例えばUE100があらかじめ保持しているテーブル情報を参照することによって、マクロネットワークのPGW430との間に新たなPDNコネクションを確立し、アプリレイヤ110から要求されるQoS情報を満たすDedicatedbearerを確立することが可能となる。なお、テーブル情報は、例えば、アプリレイヤ110から送信されたリクエストの送信元であるアプリケーション情報アプリケーションIDと、そのリクエストに係る通信を行うためのAPNとが関連付けられているAPN-アプリテーブル情報図6A、図6Bや、アプリレイヤ110から送信されたリクエストに含まれるQoS情報QCIなどと、そのリクエストに係る通信を行うためのAPNとが関連付けられているAPN-QoSテーブル情報図6C、図6Dなどが利用可能である。図6A~図6Dの各テーブル情報を用いた判断方法については、図8のフローチャートの説明の際に詳述する。ステップS5007において、UE100のNASレイヤ120が、アプリレイヤ110からのリクエストに基づくDedicatedbearerを確立することが不可能であると判断した場合には、NASレイヤ120は、アプリレイヤ110に対して、ステップS5005で受信したリクエストメッセージに対するリジェクトメッセージを返信する図5のステップS5009。一方、ステップS5007において、UE100のNASレイヤ120が、アプリレイヤ110からのリクエストに基づくDedicatedbearerを確立することが可能であると判断した場合には、テーブル情報から取得したAPN情報を格納したPDNコネクション確立リクエストメッセージをネットワークMME430に送信することでPDNコネクション確立手順を開始する図5のステップS5011。なお、このPDNコネクション確立手順は、非特許文献1で開示されるUErequestedPDNconnectivityprocedureを利用してもよい。ステップS5011でUE100から送信されたPDNコネクション確立リクエストメッセージを受信したネットワークMME430は、このリクエストメッセージに格納されているAPN情報を用いたPDNコネクションを確立することが可能か否かを判断する図5のステップS5013。このとき、ネットワークMME430がPDNコネクションを確立することが可能か否かを判断する材料として、例えば、非特許文献1で開示されているAPNRestrictionvalue例えば、LIPAAPNとのPDNコネクションを確立している状態で、マクロネットワークから接続するAPNへのPDNコネクションを同時に保持してもよいか否かなど示す値や、APNの混雑状況などを利用してもよい。ネットワークMME430は、UE100から通知されたAPNへのPDNコネクション確立を許可できるか否かの判断結果確立許可又は確立拒絶をUE100に返信する図5のステップS5015。なお、ネットワークMME430は、UE100に送信するメッセージとして、例えば、非特許文献1に開示されている、確立許可OKを示すPDNconnectivityacceptメッセージや、確立拒絶NGを示すPDNconnectivityrejectメッセージを利用してもよい。ネットワークMME430から返信メッセージを受信したUE100のNASレイヤ120は、アプリレイヤ110に対して返信メッセージの内容を送信する図5のステップS5017。なお、UE100は、アプリケーションからのリクエストに関連付けられているAPN情報を取得するためのテーブル情報をあらかじめ実装していてもよく、任意のタイミングで他のノードから取得してもよい。また、図6A~図6Dに模式的に示されているテーブル情報として保持せずに、例えばコンテキスト情報の一部として保持していてもよく、あるいは、QCI値やアプリケーションIDの入力で特定のAPNを出力するような関数として実現されてもよい。次に、図7を参照しながら、本発明の第1の実施の形態におけるUEの構成について説明する。図7は、本発明の第1の実施の形態におけるUEの構成の一例を示す図である。図7において、UE100はネットワーク例えば、E-UTRAN300やLHN200と接続して下位レイヤにおける通信処理とNASレイヤ120とのIPなどのパケット通信交換処理を実施する通信処理部701と、アプリレイヤ110とのPDNコネクション確立やEPSベアラ確立修正削除などのメッセージ処理と、アプリレイヤ110からのリクエストメッセージ受信時に、確立済のPDNコネクションを利用するか、新たにPDNコネクションを確立するかをテーブル情報を用いて判断処理するNAS処理部702、図6A~図6Dに示すようなテーブル情報を保持するテーブル情報保持部703、アプリケーションを介してユーザからの入力を処理例えば、QoS変換やAPN設定などするアプリ処理部704を少なくとも有する。なお、上記したUE100の構成は一例を示したものであり、例えば、NAS処理部702がテーブル情報保持部703を含むように設計してもよい。また、アプリ処理部704の一部の機能例えば、APN設定などをNAS処理部702が担うように設計してもよい。また、テーブル情報保持部703において保持されるテーブル情報は、あらかじめ静的に組み込まれていてもよいし、又は、UE100が保持する情報例えば、保持しておいた過去に接続したAPN情報などからテーブル情報を生成してもよい。テーブル情報保持部703に保持されているテーブル情報は、例えば図6A~図6Dに図示されているように、QCI値又はアプリケーションIDに基づいて、関連するAPNが取得できるように構成されている。例えば、テーブル情報はQCI値あるいは、QCI値の範囲又はアプリケーションIDとAPNとの対応関係エントリを含んでおり、NASレイヤ120は、テーブル情報に基づいて、特定のアプリケーションID又はQCI値又に関連付けられているAPNを取得することが可能である。また、図6B及び図6Dに図示されているように、高品質を要するか否かを示す情報フラグなどによって実現可能が各エントリに明記されていてもよい。次に、図7に図示されている構成を有するUE100について、本発明における特徴的な処理を中心に、図8を用いて詳しく説明する。図8は、本発明の第1の実施の形態におけるUE100のNASレイヤ120における動作の一例を示すフローチャートである。UE100のNASレイヤ120は、ネットワークとの間にLIPAPDNコネクションを確立し図5のステップS5001に対応する処理、図8では不図示、その後、新たなPDNコネクションDedicatedbearerの確立が必要となるQoS情報を格納したリクエストメッセージをアプリレイヤ110から受信する図8のステップS8001。なお、このリクエストメッセージは、例えば、従来のATCommandであってもよい。上記リクエストメッセージを受信したUE100のNASレイヤ120は、例えば図6A~図6Dに図示されているテーブル情報を用いて、マクロネットワークとの間で新たなPDNコネクションを確立する必要があるか否かあるいは、既に確立済みのLIPAPDNコネクションを利用することが可能か否かを判断する。具体的には、NASレイヤ120は、まず、アプリレイヤ110から受信したリクエストメッセージに含まれているQCI又はアプリケーションの種類アプリケーションIDを参照し、参照したQCI又はアプリケーションIDに該当するエントリがテーブル情報に含まれているか否かを判断する図8のステップS8003。参照したQCI又はアプリケーションIDに該当するエントリがテーブル情報に含まれていない場合には、NASレイヤ120は、アプリレイヤ110に対してリジェクトを通知する図8のステップS8005。すなわち、図8のステップS8003の判断は、アプリレイヤ110から受信したリクエストに応じたPDNコネクションをネットワークとの間で確立できるか否かを判断するものである。一方、参照したQCI又はアプリケーションIDに該当するエントリがテーブル情報に含まれている場合には、NASレイヤ120は、アプリレイヤ110からリクエストされた通信が高品質を必要とするか否かQCI値が相対的に小さいか否かを判断する図8のステップS8007。アプリレイヤ110からリクエストされたPDNコネクションが高品質を必要とすると判断された場合には、該当するエントリに規定されているAPNを取得しステップS8008、マクロネットワークとの間で新たなPDNコネクションを確立するために、取得したAPNを含むPDNコネクション確立リクエストをネットワークへ送信する図8のステップS8009。すなわち、図8のステップS8007の判断は、アプリレイヤ110から受信したリクエストに応じたPDNコネクションが高品質を要するか否かを判断するものであり、高品質を要すると判断された場合には、マクロネットワークとの間で新たなPDNコネクションの確立を試みる。一方、リクエストされているPDNコネクションが高品質を必要としないと判断された場合には、該当するエントリに規定されているAPNを取得しステップS8011。例えばアプリケーションIDとしてアプリケーションCが格納されているリクエストメッセージの場合には、図6Aに図示されているテーブル情報を保持しているNASレイヤ120は、関連するAPN情報としてAPN2を取得する。また、例えばQCI=1が格納されているリクエストメッセージの場合には、図6Cに図示されているテーブル情報を保持しているNASレイヤ120は、関連するAPN情報としてAPN2を取得する。そして、UE100のNASレイヤ120は、取得したAPNと関連するLIPAPDNコネクションが既に確立されているか否かを判断するステップS8013。取得したAPNと関連するLIPAPDNコネクションが既に確立されていると判断された場合には、この確立済みのLIPAPDNコネクションDefaultBearerを利用して、アプリレイヤ110からリクエストされた通信を行う図8のステップS8015。また、取得したAPNと関連するLIPAPDNコネクションが確立されていないと判断された場合には、マクロネットワークとの間で新たなPDNコネクションを確立するためのPDNコネクション確立リクエストを送信する図8のステップS8009。すなわち、図8のステップS8013の判断は、LIPAPDNコネクションが確立済みの場合には、このLIPAPDNコネクションを利用して、アプリレイヤ110からリクエストされた低品質の通信を行えるようにするものである。なお、図8のステップS8013の判断においては、あるAPNに対して既に確立済みのPDNコネクションがLIPAPDNコネクションか否かを判断する必要がある。PDNコネクションがLIPAを目的としたものであるか否かは、例えば、PDNコネクションに関連するConnectivitytypeIEに基づいて判断することが可能である。また、図8では、取得したAPNと関連するLIPAPDNコネクションが確立されていないと判断された場合図8のステップS8013には、マクロネットワークとの間で新たなPDNコネクションの確立を行っているが図8のステップS8009、アプリレイヤ110からリクエストされた通信はLIPAPDNコネクションのDefaultBearerを利用できるものであるため、新たにLIPAPDNコネクションの確立を試みてもよい。なお、基本的には、UE100のNASレイヤ120は、上述した図8のフローチャートに基づく動作を行うが、NASレイヤ120が保持及び参照するテーブル情報図6A~図6Dのテーブル情報に応じて、以下のように動作が異なっている。例えば、図6A及び図6Bに示すAPN-アプリテーブル情報を保持するNASレイヤ120は、アプリレイヤ110から送信されたリクエストメッセージの送信元アプリケーションの種類を、例えば、アプリケーションIDや非特許文献5で開示される特定のトラフィックを識別するcidを用いて確認することで、どのAPNを用いるか判断する。例えば、UE100があらかじめ図6Aのテーブル情報を保持している場合には、NASレイヤ120は、アプリケーションA又はアプリケーションBからリクエストを受信した際に、このリクエストに関連付けられているAPN情報としてAPN1を取得し、アプリケーションCからリクエストを受信した際に、このリクエストに関連付けられているAPN情報としてAPN2を取得する。APN1がLIPAPDNコネクションを確立するためのAPNであり、APN2がマクロネットワークとの間の通常のPDNコネクションを確立するためのAPNである場合には、NASレイヤ120は、アプリケーションA又はアプリケーションBからリクエストについては、接続先をAPN1とするLIPAPDNコネクションのDefaultbearerを利用し、アプリケーションCからのリクエストについては、APN2を用いた新たなPDNコネクションを確立する必要があると判断する。なお、例えば、LIPAPDNコネクションを確立するためのAPNと、マクロネットワークとの間の通常のPDNコネクションを確立するためのAPNとがそれぞれ異なるようネットワークが設計されている場合には、アプリケーションからのリクエストに対してAPNを特定することによって、Dedicatedbearerの確立が必要か否か高品質の通信を要求されているか否かも特定されることになる。したがって、このような場合には、図8のステップS8007の処理は実行される必要はない。一方、例えば、LIPAPDNコネクションLGW220経由と、マクロネットワークとの間の通常のPDNコネクションPGW420経由との両方に共通のAPNが使用されるようネットワークが設計されている場合には、あるアプリケーションからのリクエストに対して特定されたAPNが、LIPAPDNコネクションを確立するためのAPNか否かを特定することができない。例えば、アプリケーションAに関してはAPN1を用いたLIPAPDNコネクションの確立が要請され、アプリケーションBに関してはAPN1を用いたマクロネットワークとの間の通常のPDNコネクションの確立が要請される場合もある。図6Aに図示されているテーブル情報を保持している場合には、UE100のNASレイヤ120は、図8のステップS8007において、例えばアプリケーションAからのリクエストに格納されているQoS情報QCIなどと所定の閾値とを比較することによって、Dedicatedbearerの確立が必要か否か高品質の通信を要求されているか否かを判断することが可能である。また、図6Bに図示されているテーブル情報を保持している場合には、UE100のNASレイヤ120は、図8のステップS8007において、特定されたエントリ内の高品質/低品質あるいはマクロ/LIPAの記載を確認することで、Dedicatedbearerの確立が必要か否か高品質の通信を要求されているか否かを判断することが可能である。なお、UE100のNAS120は、LGW220経由のコネクションと、PGW420経由のコネクションの両方に共通のAPNが使用されている場合に、マクロネットワークのPGW420経由のPDNコネクション確立リクエストを送信する際には、マクロネットワークのPGW420経由のPDNコネクション確立リクエストであることを示す識別子をPDNコネクション確立リクエストに付加してもよい。また、図6C及び図6Dに示すAPN-QoSテーブル情報をNASレイヤが保持するNASレイヤ120は、アプリレイヤ110から送信されたリクエストメッセージに格納されているQoS情報が、どのAPNと関連付けられているかを確認する。例えば、QoS情報として、QCI=7が格納されたリクエストメッセージをNASレイヤ120が受信した場合、APN1を用いて送信元アプリケーションのパケット転送を開始すると判断する。ここで、APN1がLIPAPDNコネクションを確立した際のAPNであるとすると、送信元アプリケーションのパケット転送は、確立済みのLIPAPDNコネクションのDefaultbearerを用いて、パケット転送を行うと判断する。また、QoS情報として、低遅延や低エラービットレートを示すQCI=1が格納されたリクエストメッセージをNASレイヤ120が受信した場合には、APN2を用いて送信元アプリケーションのパケット転送を開始すると判断する。非特許文献3で開示されるように、QCI=1のアプリケーション例としては、VoIPVoiceOverInternetProtocolなどのIMSIPMultimediaSubsystemアプリケーションがある。また、例えば、LIPAPDNコネクションLGW220経由と、マクロネットワークとの間の通常のPDNコネクションPGW420経由の両方に共通のAPNが使用されるようネットワークが設計されている場合もある。図6Cに図示されているテーブル情報を保持している場合には、UE100のNASレイヤ120は、図8のステップS8007において、受信したリクエストに格納されているQoS情報QCIなどと所定の閾値とを比較することによって、Dedicatedbearerの確立が必要か否か高品質の通信を要求されているか否かを判断することが可能である。また、図6Dに図示されているテーブル情報を保持している場合には、UE100のNASレイヤ120は、図8のステップS8007において、特定されたエントリ内の高品質/低品質あるいはマクロ/LIPAの記載を確認することで、Dedicatedbearerの確立が必要か否か高品質の通信を要求されているか否かを判断することが可能である。なお、UE100のNAS120は、LGW220経由のコネクションと、PGW420経由のコネクションの両方に共通のAPNが使用されている場合に、マクロネットワークのPGW420経由のPDNコネクション確立リクエストを送信する際には、マクロネットワークのPGW420経由のPDNコネクション確立リクエストであることを示す識別子をPDNコネクション確立リクエストに付加してもよい。次に、本発明の第1の実施の形態におけるMME430について、本発明における特徴的な処理を中心に、図9を用いて詳しく説明する。図9は、本発明の第1の実施の形態におけるネットワークMME430の動作の一例を示すフローチャートである。ネットワークMME430は、UE100から送信されるLIPA向けのAPNが格納されたPDNコネクション確立リクエストを受信する図9のステップS9001続いて、ネットワークMME430が受信したPDNコネクション確立リクエストを許可する場合、確立するPDNコネクションがLIPAPDNコネクションであることを示すConnectivitytypeIEを格納したPDNコネクション確立許可レスポンスをUE100に返信する図9のステップS9003。なお、図9のステップS9001とS9003は、図5のステップS5001LIPAPDNコネクション確立の処理に相当する。続いて、UE100から再度PDNコネクション確立リクエストを受信する図9のステップS9005。このPDNコネクション確立リクエストには、マクロネットワークのPGW420経由で接続可能なAPNが格納されている。なお、UE100が確立済のLIPAPDNコネクションとは別に、追加のLIPAPDNコネクションを確立したい場合には、確立済みのLIPAPDNコネクションが関連するAPNと同じLIPA向けAPNが格納される場合もある。その場合も同様に、ネットワークMME430は、次ステップで説明する確立リクエストの許可判断を行う。続いて、ネットワークMME430は受信したPDNコネクション確立リクエストを許可するか判断する図9のステップS9007。この際、ネットワークMME430は、例えば、非特許文献1で開示されるAPNRestrictionvalue確立許可を示すPDNコネクションAPNの組み合わせやAPNの混雑状態、オペレータのポリシ、UE100の課金契約などに鑑みて判断してもよい。ネットワークMME430が、受信したPDNコネクション確立リクエストを許可する場合、PDNコネクション確立許可メッセージを返信する図9のステップS9009。この際も同様に、確立するPDNコネクションのConnectivitytypeIEを格納するものとする。また、ネットワークMME430が、受信したPDNコネクション確立リクエストを拒絶する場合、PDNコネクション確立拒絶メッセージを返信する図9のステップS9011。なお、本発明の第1の実施の形態を容易に説明するために、UE100が、非特許文献1で開示されるネットワーク接続手順Attachprocedureを用いてネットワークとの間にLIPAPDNコネクションを確立する動作を一例として説明したが、既にPDNコネクションを複数確立済みの状態で、新たなアプリケーションがUE100のNASに新たなPDNコネクションDedicatedbearerの確立が必要となるケースにおいても、本発明の第1の実施の形態は適用可能である。従来の技術であれば、UE100のアプリレイヤ110が新たにPDNコネクションDedicatedbearerを必要とするようなQoS情報を格納したリクエストメッセージをNASレイヤ120に送信した場合、従来であれば、ネットワークがLIPAをサポートしているか否かの情報ネットワークMMEから受信したメッセージに格納されているConnectivitytypeIEのみで、Dedicatedbearerの確立許可又は確立拒絶の判断を行っていた。一方、本発明の第1の実施の形態によれば、例えば、マクロネットワークのPGW420へのPDNコネクションを確立することによって、不必要な通信リソースの割り当て例えば、LIPAPDNコネクションのDefaultbearerに加えて、DedicatedBearerを確立するために実施される通信リソースの割り当てを回避し、かつ、従来ではリジェクトされてしまう可能性があったアプリレイヤ110からのリクエストメッセージに対して、UE100の保持するテーブル情報に基づく確立許可の判断を行うことが可能となる。<第2の実施の形態>本発明の第1の実施の形態では、UE100のNASレイヤが、例えば図6A~図6Dで示すテーブル情報を保持することによって、例えば、BearerResourceModificationprocedureを実施せずに、アプリレイヤからのリクエストメッセージの許可又は拒絶新たなPDNコネクションの確立許可又は確立拒絶の判断を行うことが可能である。新たなPDNコネクションを確立可能であるとUE100のNAS120が判断する際は、本発明の第1の実施の形態で示したように、例えば、PDNConnectivityEstablishmentrequestがネットワークに送信される。このリクエストメッセージを許可するか、又は、拒絶するかのネットワークMME430による判断は、上記したように、APNRestrictionvalue確立許可を示すPDNコネクションAPNの組み合わせやAPNの混雑状態、オペレータのポリシ、UE100の課金契約などに鑑みて行われる図5のステップS5013や図9のステップS9007に相当。つまり、ネットワークMME430の判断によっては、新たなPDNコネクションを確立するためのリクエストメッセージが、リジェクトされる可能性がある。このようにリクエストメッセージがリジェクトされる場合は、PDNコネクションを確立するための手順例えば、非特許文献1で開示されるUErequestedPDNconnectivityprocedureに割り当てられた通信リソースが無駄になってしまう不要な通信リソースの割り当てを行ってしまう。本発明の第2の実施の形態では、上述した本発明の第1の実施の形態に加えて、さらに、UE100のNASレイヤ120が、PDNコネクションを確立するための手順を実行する前に、ネットワークMME430からPDNコネクションの確立が許可されているか否かを把握できるようにすることで、不要な通信リソースの割り当てを回避する。図10では、UE100は本発明の第1の実施の形態と同様に、図4で示すネットワーク接続手順を用いて、ネットワークとの間にLIPAPDNコネクションを確立する。また、そのLIPAPDNコネクション確立手順中に、ネットワークMME430は、UE100に対して、確立したPDNコネクションはLIPAPDNコネクションであることを示す情報ConnectivitytypeIEを通知する図10のステップS10001。このとき、ネットワークMME430は、LIPAPDNコネクションであることを示す情報ConnectivitytypeIEに加えて、確立済みのLIPAPDNコネクションと並列してPDNコネクションを確立することを許可する確立許可情報をUE100に通知する。このときに使用されるメッセージのフォーマット例については後述する。確立済みのLIPAPDNコネクションと並列してPDNコネクションを確立することを許可する確立許可情報は、具体的には、マクロネットワークのPGW420経由でPDNへ接続可能なことを示す情報であり、マクロネットワークのPGW420経由で接続する際に使用可能なAPN情報あるいは、複数のAPN情報を含むAPNリストを含んでいてもよい。例えば、LIPAPDNコネクションの接続先としてAPN1が使用されているとき、マクロネットワークのPGW420経由のPDNコネクション例えば、接続先としてAPN2を使用によってEnterprise/Residentialネットワーク600と通信を行える場合や、PDNへアクセスしたい場合には、ネットワークMME430は、APN2を格納した確立許可情報をUE100へ通知することが可能である。この確立許可情報を受信したUE100は、LIPAPDNコネクションの代わりに、確立許可情報によって示されるAPNを使用したPDNコネクションを利用して、Enterprise/Residentialネットワーク600やPDNとの通信を行うことが可能である。ネットワークMME430は、例えば、APNRestrictionvalueに基づいて、マクロネットワークのPGW420経由のAPNを特定することが可能である。また、UE100へ通知する確立許可情報としては、特定のIEを利用したり、あるいは、1ビットフラグを利用したりすることが可能である。なお、LIPAPDNコネクションに関する確立許可情報は、必ずしもLIPAPDNコネクションの確立通知と同時に通知される必要はなく、LIPAPDNコネクションが確立される前後の任意のタイミングで通知されてもよい。続いて、UE100のアプリレイヤ110におけるアプリケーション起動図10のステップS10003、Dedicatedbearerの確立を目的としたアプリレイヤ110からNASレイヤ120へのリクエストメッセージの送信図10のステップS10005が行われる。なお、図10のステップS10003及びステップS10005の処理は、図5のステップS5003及びステップS5005と同様であり、ここでは説明を省略する。アプリレイヤ110からリクエストメッセージを受信したUE100のNAS120は、例えば図6A~図6Dに示すUEのNASが保持するテーブル情報と、ステップS10001でネットワークMME430から受信した確立許可情報とを用いて、アプリレイヤ110から受信したリクエストメッセージに応じたDedicatedbearerを確立できるか否かを判断する図10のステップS10007。具体的には、UE100のNAS120は、上述した第1の実施の形態でのテーブル情報に基づく判断図5のステップS5007に加えて、さらに確立許可情報に基づき、ネットワークMME430からPDNコネクションの確立が許可されているか否かを判断する。ステップS10007の判断において、UE100が新たなPDNコネクションを確立することが不可能であると判断した場合には、NASレイヤ120は、アプリレイヤ110に対して、ステップS10005で受信したリクエストメッセージに対するリジェクトメッセージを返信する図10のステップS10009。一方、ステップS10007の判断において、UE100が新たなPDNコネクションを確立することが可能であると判断した場合には、ステップS10007においてテーブル情報から取得したAPN情報を格納したPDNコネクション確立リクエストメッセージをネットワークMME430に送信することでPDNコネクション確立手順を開始する図10のステップS10011。なお、本ステップS10011は、本発明の第1の実施の形態におけるステップS5011と同様である。ステップS10011でUE100から送信されたPDNコネクション確立リクエストメッセージには、ネットワークMME430が、PDNコネクションの確立が可能であると判断したAPNが含まれている。ネットワークMME430は、例えば、このリクエストメッセージに格納されているAPNを接続先とするPDNコネクションの確立が可能であることを確認し図10のステップS10013、確立許可を示すPDNコネクション確立許可メッセージを返信する図10のステップS10015。なお、このPDNコネクション確立許可メッセージとして、非特許文献1で開示されているPDNconnectivityacceptメッセージを用いてもよい。PDNコネクション確立許可メッセージを受信したUE100のNAS120は、リクエストされたQoS情報などを許可することを示すメッセージをアプリレイヤ110に対して返信する図10のステップS10017。なお、ネットワークMME430が確立許可情報をPDNコネクション確立許可情報に格納するために、APNRestrictionvalueを確認し、確立可能なAPN情報を用いてもよい。また、マクロネットワークのPGW420経由で接続可能なPDNAPNが1つしかない場合、そのAPNを選択し、確立許可情報として用いてもよい。また、ネットワークMME430は、LIPAPDNコネクションを確立すると判断した場合例えば、LIPA向けAPNが格納されている場合や、LGWアドレスが付加されている場合などには、必ず確立許可情報例えば、特定のAPN情報やAPNリスト情報確立許可のAPNの群をEquivalentAPNlistとも呼ぶを格納して、UE100に通知してもよい。次に、図11に基づいて、ネットワークMME430からUE100への確立許可情報の通知方法の一例について説明する。ネットワークMME430は、例えば、ステップS10001のLIPAPDNコネクションの確立の際に、Attachacceptメッセージに確立許可情報を含ませることが可能である。図11は、図10のステップS10001で、ネットワークMME430がUE100に対して送信するAttachacceptメッセージ構成の一例である。図11に図示されているAttachacceptメッセージは、通常のAttachacceptメッセージで必要となる情報が格納される従来のAttachacceptメッセージフィールドと、確立済みのLIPAPDNコネクションと並列してPDNコネクションマクロネットワークのPGW420経由の確立許可を示す確立許可情報フィールドで構成される。確立許可情報フィールドには、UE100のNAS120が保持するテーブル情報を用いた判断に加えて、ネットワークがUE100における確立済みLIPAPDNコネクションと並列して新たなPDNコネクションマクロネットワーク経由を確立可能であるか否かを判断できることを示す情報が格納される。次に、図12を参照しながら、本発明の第2の実施の形態におけるUE100の構成について説明する。図12は、本発明の第2の実施の形態におけるUE100の構成の一例を示す図である。本発明の第2の実施の形態におけるUE100の構成は、確立許可情報確認部705以外は同様なため、確立許可情報確認部705以外の説明は省略する。UE100の確立許可情報確認部705は、図10のステップS10001でネットワークMME430から受信した確立許可情報に格納されている情報例えば、特定のAPN情報や、ネットワークオペレータから確立許可されるAPNのリストなどを処理する機能部である。各情報における具体的な処理方法については、後述する。次に、図12に図示されている構成を有するUE100について、本発明における特徴的な処理を中心に、図13を用いて詳しく説明する。図13は、本発明の第2の実施の形態におけるUE100の動作の一例を示すフローチャートである。本発明の第2の実施の形態におけるUE100の動作は、本発明の第1の実施の形態におけるUE100の動作の一例をベースにしており、以下では本発明の第2の実施の形態における特徴的な処理を中心に説明する。本発明の第1の実施の形態と同様に、UE100のNASレイヤ120は、ネットワークとの間にLIPAPDNコネクションを確立し図13では不図示、その後、新たなPDNコネクションDedicatedbearerの確立が必要となるQoS情報を格納したリクエストメッセージをアプリレイヤ110から受信する図13のステップS8001。なお、本発明の第2の実施の形態では、ネットワークとの間にLIPAPDNコネクションを確立する際、ネットワークMME430から確立許可情報を受信する。なお、確立許可情報を受信するタイミングは、PDNコネクションを確立する際や確立後、または、特定のセルやエリアに入った際に受信してもよい。続いて、アプリレイヤ110から上記リクエストメッセージを受信したUE100のNASレイヤ120は、本発明の第1の実施の形態と同様に、テーブル情報を用いて、マクロネットワークとの間で新たなPDNコネクションを確立する必要があるか否かあるいは、既に確立済みのLIPAPDNコネクションを利用することが可能か否かを判断する図13のステップS8003及びステップS8007。その後の図13のステップS8003及びステップS8007では、図8のステップS8003及びステップS8007と同様の処理が行われる。本発明の第2の実施の形態では、アプリレイヤ110から受信したリクエストメッセージに含まれているQCI又はアプリケーションの種類アプリケーションIDを参照し、参照したQCI又はアプリケーションIDに該当するエントリがテーブル情報に含まれており、かつ、アプリレイヤ110からリクエストされたPDNコネクションが高品質を必要としないと判断された場合に、さらに図13のステップS13001において、取得したAPN情報が確立許可情報のAPN情報と一致するか否かの判断が行われる。図13のステップS13001において、UE100のNAS120は、取得したAPN情報が確立許可情報のAPN情報と一致しない場合には、アプリレイヤ110に対してリジェクトを通知する図13のステップS8005。一方、取得したAPN情報が確立許可情報のAPN情報と一致した場合には、本発明の第1の実施の形態と同様に、取得したAPNと関連するLIPAPDNコネクションが既に確立されているか否かを判断する図13のステップS8013。例えば、図8のステップS8011において、QCI=1が格納されているリクエストメッセージの場合、図6C又は図6Dのテーブル情報に基づき、関連するAPN情報としてAPN2が取得されたとする。続いて、UE100のNASレイヤ120は、テーブル情報から取得したAPN情報上記例では、APN2に相当が、ネットワークMME430から受信した確立許可情報に格納されている特定のAPN情報と一致しているか否かを確認する。この確立許可情報にAPN2が格納されている場合は、一致していると判断し、また、確立許可情報にAPN2が格納されていない場合には、不一致と判断する。次に、図14を参照しながら、本発明の第2の実施の形態におけるMME430の構成について説明する。図14は、本発明の第2の実施の形態におけるMME430の構成の一例を示す図である。図14において、MME430は、E-UTRAN300上のeNB310やLHN200上のHeNB210、EPC400のSGW410と通信処理を実施する通信処理部1401と、UE100のNAS120とのネットワーク接続処理やPDNコネクション確立処理などのNASシグナリングeNB310やHeNB210においては透過的なシグナリングを処理するNAS処理部1402と、図10のステップS10001でネットワークMME430からUE100に通知する確立許可情報を生成する確立許可情報生成部1403を少なくとも有する。なお、上記したMME430の構成は一例を示したものであり、例えば、NAS処理部1402が確立許可情報生成部1403を含むように設計してもよい。また、確立許可情報生成部1403は、MME430が静的に保持する情報や、HSS440に問い合わせて取得するSubscriptiondataや、UE100に過去に利用した履歴情報例えば、過去に接続したAPN情報などから確立許可情報を生成してもよい。次に、図14に図示されている構成を有するMME430について、本発明における特徴的な処理を中心に、図15を用いて詳しく説明する。図15は、本発明の第2の実施の形態におけるMME430の動作の一例を示すフローチャートである。本発明の第2の実施の形態におけるMME430の動作は、本発明の第1の実施の形態におけるMME430の動作の一例をベースにしており、以下では本発明の第2の実施の形態における特徴的な処理を中心に説明する。図15のステップS15001とステップS15003は、図9のステップS9001とステップS9003と同様なため、説明を省略する。続いて、MME430はPDNコネクション確立許可メッセージに格納するための確立許可情報を生成する図15のステップS15004。MME430によって生成される確立許可情報は、UE100における新たなPDNコネクションを確立するか否かを判断する判断材料として提供することを目的としている。以下、MME430が、特定のAPN情報を確立許可情報として用いる場合の詳細な処理手順の一例について説明する。最初に、MME430がLIPAPDNコネクションを確立すると判断した際例えば、UE100から通知されるPDNコネクション確立リクエストやAttachrequestメッセージに格納されているAPN情報がLIPA向けのAPNであると判断した場合や、HeNB210によってLGW220のアドレスがMME430へのメッセージ例えば、非特許文献1で開示されるAttahrequestメッセージやUplinkNAStransportメッセージに格納される場合、確立済みのLIPAPDNコネクションと並列して確立可能なPDNコネクションに関連するAPN情報を選択する。なお、本発明では、マクロネットワークにおけるPGW420とのPDNコネクションを確立することを許可する場合を想定しているため、PGW420経由で接続可能なAPNを選択する。次に、MME430が、EquivalentAPNlistを確立許可情報として用いる場合の詳細な処理手順の一例を説明する。EquivalentAPNlistが確立許可情報として用いられる場合、ネットワークMME430によって複数の確立許可されるAPNがリストとして生成される。例えば、ネットワークオペレータが管理しているマクロネットワークのPGW420経由でアクセス可能なAPNを全て、又は、一部をオペレータポリシやUE100のSubscriptiondata例えば、ロケーション情報や課金契約情報、ローミング情報などに基づいて生成選択して格納する。MME430は、上記のように選択生成した確立許可情報をPDNコネクション確立許可メッセージに格納して図15のステップS15004、UE100に送信する。なお、図10のステップS15003ConnectivitytypeIEを格納と、図10のステップS15004確立許可情報を選択生成格納を実施する順番は順不同である。続くステップS15005以降の処理は、本発明の第1の実施の形態における図9のステップS9005以降と同様であり、ここでは説明を省略する。なお、本発明の第2の実施の形態を容易に説明するために、UE100が、非特許文献1で開示されるネットワーク接続手順Attachprocedureを用いてネットワークとの間にLIPAPDNコネクションを確立する動作を一例として説明したが、既にPDNコネクションを複数確立済みの状態で、新たなアプリケーションがUE100のNAS120に新たなPDNコネクションDedicatedbearerの確立が必要となるケースにおいても、本発明の第2の実施の形態は適用可能である。以上、本発明の第2の実施の形態によれば、本発明の第1の実施の形態における効果に加えて、LIPAPDNコネクションと並列して確立可能なPDNコネクションに関する確立許可情報例えば、特定のAPN情報やAPNリストなどがネットワークMME430からUE100に通知されることによって、UE100は、LIPAPDNコネクションに加えて、新たなPDNコネクションを確立することが可能か否かを判断することが可能となる。その結果、UE100は、PDNコネクションを確立できることが確認された場合にのみ、PDNコネクション確立リクエストを送信することができるようになり、PDNコネクション確立リクエストがリジェクトされることによる通信リソースの不要な割り当てを回避することができる。<第3の実施の形態>本発明の第2の実施の形態では、ネットワークMME430からUE100に通知する確立許可情報として、例えば、特定のAPN情報や、ネットワークオペレータから確立許可されるAPNのリストなどが用いられている。一方、本発明の第3の実施の形態では、確立許可情報として、任意のAPNへのPDNコネクション確立許可を示すIndicatorが用いられる場合について説明する。本発明の第3の実施の形態では、確立許可情報として、任意のAPNへのPDNコネクション確立許可を示すIndicatorが用いられる。任意のAPNへのPDNコネクション確立許可を示すIndicatorは、任意のAPNを用いてLIPAPDNコネクションに加えて、マクロネットワーク経由でPDNへ接続するPDNコネクションPGW420経由を確立することが可能である旨を通知する情報である。本発明の第2の実施の形態では特定のAPN情報や確立許可されるAPNのリストなどが確立許可情報として通知されるのに対して、本発明の第3の実施の形態では、任意のAPNへのPDNコネクション確立許可を示すIndicatorが確立許可情報として用いられることで、UE100が保持するテーブル情報に登録されているAPN情報と一致しない場合においても、新たなPDNコネクション確立を許可することをUE100に示すことができる。例えば、ネットワークMME430が、UE100によって保持されるテーブル情報に登録されているAPN情報を把握していない場合例えば、静的にテーブル情報が保持されている場合においても、アプリレイヤ110から通知されるQoS情報を満たすことができるPDNコネクションDedicatedbearerを任意のAPNで確立することができる。また、マクロネットワークのPGW420経由で接続するPDNコネクションとLHN200のLGW210経由で接続するPDNコネクションにおいて共通のAPNを利用する場合、ネットワークMME430はオペレータポリシや、HeNB210から転送されるメッセージ例えば、非特許文献1で開示されるAttachrequestメッセージやUplinkNAStransportメッセージなどにHeNB210によって追加されるLGWアドレスの有無に基づいて、LIPAPDNコネクションの確立リクエストであるか識別する。ネットワークMME430において、確立リクエストが上記オペレータポリシやLGWアドレスの有無基本的にHeNB210は常にLGWアドレスを格納する非特許文献1を参照に基づいて、LIPAPDNコネクションの確立リクエストであると判断されるため、アプリレイヤ110から通知されるQoS情報を満たすPDNコネクションDedicatedbearerを確立することができない。しかし、本発明の第3の実施の形態では、任意のAPNへのPDNコネクション確立許可を示すIndicator例えば、ネットワークMME430が生成するトークンや、UE100とMME430のみが識別可能な鍵情報などを確立許可情報として利用することで、例えば、UE100のNAS120からネットワークMME430に送信するPDNコネクション確立リクエストメッセージに、受信した確立許可情報例えば、上記トークンや鍵情報などを格納することで、LIPAPDNコネクションの確立リクエストではなく、マクロネットワークのPGW420経由で接続するPDNAPNとのPDNコネクション確立リクエストであることを示すことができる。以下に、上記した任意のAPNへのPDNコネクション確立許可を示すIndicatorを確立許可情報として用いる本発明の第3の実施の形態の手段について説明する。本発明の第3の実施の形態におけるシーケンスは、本発明の第2の実施の形態におけるシーケンス図10に図示されているシーケンスと同じであり、ここでは説明を省略する。また、本発明の第3の実施の形態におけるUE100及びMME430の構成は、本発明の第2の実施の形態における構成図12に図示されているUE100の構成、及び、図14に図示されているMME430の構成と同じであり、ここでは説明を省略する。次に、図12に図示されている構成を有するUEについて、本発明における特徴的な処理を中心に、図16を用いて詳しく説明する。図16は、本発明の第3の実施の形態におけるUE100の動作の一例を示すフローチャートである。本発明の第3の実施の形態におけるUE100の動作は、本発明の第2の実施の形態におけるUEの動作の一例をベースにしており、以下では本発明の第3の実施の形態における特徴的な処理を中心に説明する。本発明の第3の実施の形態では、本発明の第2の実施の形態と同様に、UE100のNASレイヤ120は、ネットワークとの間にLIPAPDNコネクションを確立した際に、ネットワークMME430から確立許可情報を受信する。UE100のNAS120は、受信した確立許可情報が任意Indicatorか否かを判断する図16のステップS16001。受信した確立許可情報が任意Indicatorではない場合すなわち、特定のAPN情報やAPNリストなどを含む確立許可情報の場合には、上述した本発明の第2の実施の形態に係る動作図13に図示されているフローチャートを実施する。一方、受信した確立許可情報が任意Indicatorである場合には、図16のステップS16003以降に示される本発明の第3の実施の形態に係る動作を実施する。その後、UE100のNASレイヤ120は、新たなPDNコネクションDedicatedbearerの確立が必要となるQoS情報を格納したリクエストメッセージをアプリレイヤ110から受信すると図16のステップS16003、UE100のNASレイヤ120は、新たなPDNコネクションの確立を必要と判断した場合例えば、アプリレイヤ110からのリクエストがDedicatedbearerの確立であることを確認した場合、リクエストメッセージに格納されているAPN情報を取得し図16のステップS16005、取得したAPN及び任意IndicatorをPDNコネクション確立リクエストメッセージに格納する図16のステップS16007。そして、UE100のNASレイヤ120は、APN情報及び任意Indicatorなどを格納したPDNコネクション確立リクエストメッセージをネットワークへ送信する図16のステップS16009。任意IndicatorをPDNコネクション確立リクエストメッセージに格納することによって、例えば上記したように、ネットワークオペレータのサービス運用上、マクロネットワークのPGW420経由で接続するPDNコネクションとLHN200のLGW経由で接続するPDNコネクションにおいて共通のAPNを利用する場合に、マクロネットワークのPGW420経由で接続するPDNコネクション確立リクエストであることを明示的に示すことが可能となる。UE100は、ネットワークMME430から受信した任意IndicatorをネットワークMME430に通知することによって、従来であれば、HeNB210がLGWアドレスを格納するため、LIPAPDNコネクション確立リクエストとして扱われていたが、マクロネットワークのPGW経由のPDNAPNへのPDNコネクション確立リクエストとしてネットワークMME430が扱えるようにすることが可能となる。なお、図16では、UE100がアプリレイヤ110から受信したリクエストメッセージ内のAPNを取得してPDNコネクション確立リクエストに格納しているが、本発明の第3の実施の形態では、任意のAPNへのPDNコネクション確立がネットワークによって許可されているため、任意のAPN図6A~図6Dに示すようなテーブル情報から取得したAPNをPDNコネクション確立リクエストに格納してもよい。テーブル情報を用いてAPN情報を取得した場合には、アプリレイヤ110がリクエスト要望するQoS情報に関連付けられているAPN情報を選択して、PDNコネクション確立リクエストに格納することができる。また、本発明の第3の実施の形態におけるMMEの動作は、一部を除いて、図15に示す本発明の第2の実施の形態におけるMMEの動作と同じである。以下では、図15を参照しながら、本発明の第3の実施の形態における特徴的な処理を中心に説明し、同じ動作の部分については説明を省略する。本発明の第2と第3の実施の形態では、PDNコネクション確立時にネットワークMME430からUE100に通知される確立許可情報の種類が異なっている。本発明の第3の実施の形態におけるMME430は、図15のステップS15004確立許可情報の選択生成格納でUE100に通知する確立許可情報として、任意Indicatorを使用する。また、任意Indicatorは、UE100から送信されるPDNコネクション確立リクエストメッセージにおいても格納される場合例えば、トークンや鍵情報を用いて、新たなPDNコネクションの確立を許可したUE100であるか識別する場合がある。この任意Indicatorは、例えば、上述のように、UE100及びネットワークMME430が認識可能なトークンや、非特許文献1で開示されているUEのContext情報例えば、IPアドレスや、NASCOUNTパラメータ、DefaultbearerのBearerID、IMSI、鍵を用いた相互認証鍵など、独自の鍵情報などが考えられる。上記トークンが、任意Indicatorとして用いられる場合、例えば、トークンはUE100とネットワークMME430における簡易相互認証鍵として用いることができる。UE100が送信するPDNコネクション確立リクエストメッセージにネットワークが通知したトークンを格納することによって、ネットワークMME430は同一のトークンであるか否かを確認できるようになり、同一のトークンであると判断した場合に、ネットワークMME430は、PDNコネクション確立リクエストメッセージを許可するようにしてもよい。また、上記UE100のContextの情報であるIPアドレスが任意Indicatorとして用いられる場合、ネットワークMME430は、UE100に割り当てたIPアドレスを任意Indicator確立許可情報として利用し、このIPアドレスを図11で示す確立許可情報フィールドに格納してもよい。しかし、UE100に割り当てるIPアドレスは、非特許文献1で開示されているように、別手段例えば、IPv4アドレスの場合は、PGW420が割り当ててもよいし、外部サーバ例えば、DHCPサーバにUE100が問い合わせるようにして、IPアドレスを取得してもよい。IPv6アドレスの場合は、IPv6プレフィックスをRARouterAdvertisementメッセージに格納して、UEにおいてIPv6プレフィックスからIPv6アドレスを生成させるでUE100に通知することができるため、改めて確立許可情報フィールドに格納する必要はない明示的に確立許可情報フィールドに格納することで、UE100における処理の容易性を考慮してもよい。MME430は、特定のIPアドレスから受信するPDNコネクション確立リクエストを許可するようにすることで、UE100のアプリレイヤ110がリクエストするPDNコネクションDedicatedbearerを確立することができる。上記他の任意IndicatorのパラメータUEContext情報などにおいても同様である。また、UE100へ任意Indicatorを通知する場合、PDNコネクション確立許可メッセージ例えば、非特許文献1で開示されるようなAttachacceptメッセージやPDNconnectivityacceptメッセージに格納されてもよい。例えば、任意IndicatorがAttachacceptメッセージに格納される場合には、図11に示すように既存のAttachacceptメッセージに新たなIEを追加してもよい。また、PDNコネクション確立後に、MME430からHeNB210やeNB310に対して、任意IndicatorをUE100に通知するためのブロードキャスト情報を送信してもよい。これにより、HeNB210やeNB310が、UE100に対して、非特許文献7で開示されるSIBSystemInformationBlockを用いて通知することもできる。なお、本発明の第3の実施の形態も、本発明の第1と第2の実施の形態と同様に、非特許文献1で開示されるネットワーク接続手順Attachprocedureを用いてネットワークとの間にLIPAPDNコネクションを確立する動作を一例として説明したが、既にPDNコネクションを複数確立済みの状態で、新たなアプリケーションがUEのNASに新たなPDNコネクションDedicatedbearerの確立が必要となるケースにおいても、本発明の第3の実施の形態は適用可能である。以上、本発明の第3の実施の形態によれば、本発明の第1及び第2の実施の形態における効果に加えて、ネットワークMME430が、任意のAPNへのPDNコネクションの確立を許可する確立許可情報をUE100へ通知することによって、ネットワークMME430が確立許可情報に格納するためのAPN情報生成選択処理に係る負荷の軽減、UE100におけるAPN情報の一致の確認処理に係る負荷の軽減など実現することができる。なお、本発明の第1~第3の実施の形態におけるUE100のNAS120が使用するテーブル情報は、本発明の第1の実施の形態で説明したように、あらかじめ実装してある静的に保持しているものであってもよいし、ネットワークから動的に通知されるものでもよい。例えば、オペレータポリシに基づいて、ネットワークMME430からHeNB210やeNB310に対して、ネットワークによって生成したテーブル情報、又は、テーブル情報を生成する材料をUE100に通知するように指示し、HeNB210やeNB310はブロードキャスト、又は、特定のUE100に向けての送信するためのリソースSIBなどを用いて、テーブル情報に関連した情報を送信してもよい。テーブル情報を生成する材料例えば、アプリケーションIDの一覧や、QCIの一覧などがUE100に通知される場合、UE100は受信した材料を用いて、図6A~図6Dに示すようなテーブル情報を構築することができる。なお、本発明の第1~第3の実施の形態では、LIPAPDNコネクションを確立済みの状態のUE100において、新たなPDNコネクションを確立すると判断した場合、マクロネットワークのPGW420経由でPDNコネクションを確立することを前提として説明したが、UE100が意図的に新たなPDNコネクションをLIPAPDNコネクションとして確立したいと判断する場合例えば、任意Indicatorを受信した後、図6A~図6Dに示すようなテーブル情報を用いるようにし、APN情報を選択できるようにする場合は、例えば、本発明の第3の実施の形態を例に説明すると、任意Indicatorを意図的に格納しないで、PDNコネクション確立リクエストメッセージを送信してもよい。また、ネットワークMME430がUE100に通知する確立許可情報として、LIPAPDNコネクション確立をUEがリクエストできるような情報例えば、トークンを2種類用意しておき、1つはLIPAPDNコネクションとして扱い、もう1つは第3の実施の形態のようにマクロネットワークのPGWとのPDNコネクションとして扱うを用いてもよい。なお、本発明の第2と第3の実施の形態では、ネットワークMME430がLIPAPDNコネクション確立時に確立許可情報を通知する例を用いて説明した。これに加えて、LHN200のLGW220が、LIPAPDNコネクション確立時に、LGW220とUE100のみが扱う情報を用いて、確立許可情報を利用してもよい。例えば、非特許文献1で開示されるUE100とLGW220PGW以外の装置MME430やSGW410、HeNB210など上では透過的に扱われるパラメータであるPCOProtocolConfigurationOptionを用いて、LGW220からUEに確立許可情報を通知してもよい。LGW220は、管理している複数のAPN情報をリストEquivalentAPNlistとして、UE100に送信してもよい。一般的にLGW220PGWは、複数のPDNAPNと関連付いている場合があり、EquivalentAPNlistを確立許可情報として利用する場合は、PDNコネクション確立が可能なAPNを他の装置に問い合わせる必要もない観点で有効である。なお、本発明の第2と第3の実施の形態では、ネットワークからUE100に対して、確立許可情報を通知するタイミングとして、LIPAPDNコネクション確立時を一例として説明したが、PDNコネクション確立時ではなく、非特許文献1で開示されるハンドオーバ手順や、IDLE状態のUE100が他セルのカバレッジ配下にいるときにUEへ通知可能なSIBなどを用いてもよい。これにより、PDNコネクション確立時ではなく、任意のタイミングで、ネットワークは確立許可情報をUEに通知することができる。なお、本発明の第2と第3の実施の形態における確立許可情報では、特定のAPN、EquivalentAPNlist、任意Indicatorのいずれかが格納されるように説明したが、例えば、特定のAPNとEquivalentAPNlistの両方を確立許可情報としてUE100に通知することで、特定のQCIの場合は特定APNを利用するようにし、それ以外のQCIの場合は、EquivalentAPNlistを利用するようにしてもよい。また、本発明の第1から第3の実施の形態におけるUEでは、アプリレイヤから高QoSの通信経路Dedicatedbeararの確立がリクエストされ、マクロネットワーク経由でPDNコネクションを確立するように説明したが、このときUE100はマクロネットワークと接続できる環境LHN200やE-UTRAN300のカバレッジ内であれば、マクロネットワークの基地局eNB310に接続するための移動などをしなくてよい。また、マクロネットワーク経由でPGW420と確立するPDNコネクションと、LHN200経由のLGW220と確立するLIPAPDNコネクションが関連するAPNが異なる場合、ネットワークオペレータから割り当てられるDefaultQoSDefaultbearerに割り当てられるQoSが異なる可能性がある。この場合、UE100はどちらのDefaultbearerをアプリからのリクエストに対して適用するか、リクエストメッセージに格納されているQoS情報例えば、QCIやGBR、MBRを基に判断してもよい。また、本発明の第1から第3の実施の形態において、UE100のNAS120が利用するテーブル情報の変化形として、特定の情報例えば、特定のQCIや、特定のAPNなどが格納されている場合に、対応するAPN情報を探すのではなく、エラー、又は、拒絶する処理をしてもよい。例えば、図6C又は図6Dに示すAPNとQoS情報対応テーブルにおけるAPN列欄にエラー、又は、拒絶を示す値を格納しておくことで対応してもよい。また、UE100のNAS120によるテーブル情報の使い方の変化形として、例えば、QCI=7~8と登録されたテーブル情報をUE100のNAS120が保持する場合に、アプリレイヤ110からのリクエストメッセージに格納されるQCIがQCI=7、又は、8が格納される際、UE100のNAS120はAPN1を選択するという使い方にしてもよい不図示。また、1>QCI>=7と登録されたテーブル情報をUE100のNAS120が保持する場合に、アプリレイヤ110からのリクエストメッセージに格納されるQCIがQCI=2やQCI=7などが格納される際、関連するAPN例えば、APN1を選択するという使い方にしてもよい不図示。また、UE100によるEnterprise/Residentialネットワーク600へのアクセス手段として、UE100がマクロネットワークのPGW420との間にPDNコネクションを確立し、PDN500経由で、例えば、VPNVirtualPrivateNetworkセッションを確立して、Enterprise/Residentialネットワーク600にリモートアクセスするケースや、マクロネットワークのPGW420からアクセス可能なPDN500を経由せずにSGW410とLHN200のLGW220又はHeNB210間のインタフェース図1のバックホール700を通過するインタフェースに相当を利用してリモートアクセスするケースなどがある非特許文献8を参照。このようなリモートアクセスは、RIPARemoteIPAccessやMRAManagedRemoteAccesstohomebasednetwork、CSNContinuityofDataSessionstoLocalNetworksなどとも呼ばれる。このリモートアクセス時においても、本発明は適用できる。例えば、UE100が特定のHeNB210や、CSGClosedSubscriberGroupセル、フェムトセルにハンドオーバ時に、UE100のNAS120が保持するテーブル情報やネットワークMME430やLGW220から通知される確立許可情報の使用を開始してもよい。例えば、UE100は、非特許文献1で開示されるハンドオーバ手順でネットワークから通知されるメッセージ例えば、Handovercommandメッセージを受信することで、テーブル情報や確立許可情報の使用を開始してもよい。なお、上記ではハンドオーバのようなUE100が通信状態CONNECTEDモードを例に説明したが、非通信時のアイドルモード時のUE100が、特定のHeNB210やCSGセル、フェムトセル配下に移動する際においても同様に適用可能である。つまり、UE100が特定のロケーション例えば、特定の基地局HeNB210、CSGセル、フェムトセルのカバレッジ内いるときUE100が特定の基地局のカバレッジ内にいることを検知可能な報知情報例えば、基地局IDやセルIDなどを受信した際や特定のオペレータネットワークに接続しているときUE100がオペレータを識別可能なPLMNPublicLandMobileNetworkIDを受信した際、特定のAPNを使用するとき例えば、契約サービスで利用可能なAPNが異なっていて、UE100毎に利用するAPNが異なる場合があるときのみ、テーブル情報や確立許可情報を用いるようにしてもよい。また、本発明の第1から第3の実施の形態では、UE100のNAS120がアプリレイヤ110から送信されるアプリケーションリクエストに格納されているアプリケーションのパケットを通信するために必要な情報例えば、QoS情報例えば、QCIやGBR、MBRなどやAPN情報を用いて、Dedicatedbearerを確立できないと判断する際に、確立済みのLIPAPDNコネクションとは別に、マクロネットワークのPGW420との間に新たなPDNコネクションを確立できるか否かの情報を用いて判断してもよい。つまり、図8のステップS8001とステップS8003、又は、図13のステップS8001とS8003の間で、Dedicatedbearerを確立可能か否かについて判断してもよい。UE100のNAS120がDedicatedbearerを確立できないと判断した場合、図8のステップS8003や図13のステップS8003を実施する。また、Dedicatedbearerを確立できると判断した場合には、Dedicatedbearerを確立する処理例えば、非特許文献1で開示されるBearerResourceModificationリクエストメッセージ送信を実施する。このDedicatedbearerの確立可否の判断は、ネットワークから通知される情報例えば、ConnectivitytypeIEやベアラ確立拒絶メッセージ/PDNコネクション確立拒絶メッセージに格納されている拒絶理由などを用いてもよい。例えば、ネットワークから通知される情報として、ConnectivitytypeIEが用いられる場合、UE100のNAS120はアプリレイヤ110からアプリケーションリクエスト受信時に、UE100が保持しているコンテキスト情報から確立済みのPDNコネクションのタイプ情報を取得し、LIPAPDNコネクションを示している場合Dedicatedbearerを確立できないと判断する場合に限り、新たなPDNコネクションを確立可能か確認する処理テーブル情報や確立許可情報を用いた確認処理を実施してもよい。また、ネットワークから通知される情報として、ベアラ確立拒絶メッセージ/PDNコネクション確立拒絶メッセージが用いられる場合、確立済みのPDNコネクションのタイプ情報を確認しなくても、ベアラ確立/PDNコネクション確立リクエストメッセージの結果を用いて、新たなPDNコネクションを確立可能か否かを確認する処理テーブル情報や確立許可情報を用いた確認処理を実施してもよい。また、上記の本発明の実施の形態の説明で用いた機能ブロックは、典型的には集積回路であるLSILargeScaleIntegrationとして実現される。これらは個別に1チップ化されてもよいし、一部又はすべてを含むように1チップ化されてもよい。なお、ここでは、LSIとしたが、集積度の違いにより、ICIntegratedCircuit、システムLSI、スーパーLSI、ウルトラLSIと呼称されることもある。また、集積回路化の手法はLSIに限るものではなく、専用回路又は汎用プロセッサで実現してもよい。LSI製造後に、プログラムすることが可能なFPGAFieldProgrammableGateArrayや、LSI内部の回路セルの接続や設定を再構成可能なリコンフィギュラブルプロセッサを利用してもよい。さらには、半導体技術の進歩又は派生する別技術によりLSIに置き換わる集積回路化の技術が登場すれば、当然、その技術を用いて機能ブロックの集積化を行ってもよい。例えば、バイオ技術の適応などが可能性としてあり得る。