WO2017037776A1

WO2017037776A1 - 端末とネットワークノードと通信制御方法並びにプログラム

Info

Publication number: WO2017037776A1
Application number: PCT/JP2015/074385
Authority: WO
Inventors: 俊康蔵杉; 尚志田部; 拓人大月
Original assignee: 日本電気株式会社
Priority date: 2015-08-28
Filing date: 2015-08-28
Publication date: 2017-03-09
Also published as: US20180249317A1; JPWO2017037776A1

Abstract

本発明は、端末側でＭＥＣサービスの提供を受けるか否かを選択可能とする。端末はＭＥＣサービスの提供を受けるか否かの判断に用いる情報の入力を受け付けるユーザインタフェースと、ネットワークノードでＭＥＣサービスを提供することの判断に用いる情報をネットワークに通知する通知部を有する。

Description

端末とネットワークノードと通信制御方法並びにプログラム

　本発明は、端末とネットワークノードと通信制御方法並びにプログラムに関する。

　ＬＴＥ（Long Term Evolution）基地局などのモバイル通信の基地局やアクセスポイントの近傍に、サーバを配置するモバイルエッジコンピューティング（Mobile Edge Computing：ＭＥＣ）が提唱されている。例えばＭＥＣサーバをユーザに近接配置することで、通信遅延（レイテンシ）を削減し、バックホールの帯域を削減するなどのメリットが高いとして、様々なユースケースも提案されている（例えば非特許文献１）。非特許文献１には、例えば、カメラで撮影したビデオストリームをＭＥＣサーバでトランスコードし該ＭＥＣサーバから低い帯域にてコア網に転送するというシステムや、コア網にキャッシュを備え、インターネット等のコンテンツ源からのパケットをコア網で一旦キャッシュし、該コア網から低い帯域のバックホール転送にてパケットをＬＴＥ基地局のＭＥＣサーバに送信してＭＥＣサーバのローカルキャッシュに格納し、端末に転送するシステムが提示されている。

　非特許文献２には、インターネットへのアクセスの経路を切り替え、オフロードする技術が記載されている。

　特許文献１には、会員端末は、共通サーバ装置からのホームページを受信して、ＬＣＤ（Liquid Crystal Display）に表示し、表示されたホームページに含まれるサービス選択用アイコンから、この会員端末の使用者が目的とする情報提供サービスに対応するサービス選択用アイコンの選択入力を受付けて、選択された情報提供サービスの実行を共通サーバ装置に要求する。これによって、会員端末の使用者は、共通サーバ装置から目的とする情報提供サービスを受けることができるようにされている構成が開示されている。

特開平１１－６８８２３号公報

"Mobile Edge Computing - Introductory Technical White Paper"(インターネット［２０１５年７月１日検索］＜ＵＲＬ：http://portal.etsi.org/Portals/0/TBpages/MEC/Docs/Mobile-edge_Computing_-_Introductory_Technical_White_Paper_V1%2018-09-14.pdf＞インターネット白書2011、財団法人インターネット協会（監修）、インプレスジャパン　2011年7月29日刊、134ページ

　ＭＥＣサービスにおいて、端末が移動するなどにより、サービスの継続性を確保できないことが課題となっている。例えば、基地局においてＭＥＣサービスが提供されており、端末が移動で基地局間をハンドオーバした際に、サービスの継続性が確保できない状況が発生し得る。このような状況で、端末にＭＥＣサービスを提供すると、サービスが途切れる、品質（例えばＱｏＥ（Quality of Experience））が下がる等の問題が発生し、顧客満足度を著しく低下させる可能性がある。

　サービスの継続性が高い場合に絞って、端末に対してＭＥＣサービスを提供することで、顧客満足の著しい低下を低減できる可能性がある（本願発明者等による知見）。

　本発明は、上記課題に鑑みて創案されたものであって、その主たる目的は、ＭＥＣサービスの提供を受けるか否かを選択可能とした端末、該端末からの情報に応じてＭＥＣサービスの提供を制御するネットワークノードと通信制御方法、並びにプログラムを提供することにある。

　本発明の１つの側面によれば、ＭＥＣサービスの提供を受けるか否かの判断に用いる情報の入力を受け付けるユーザインタフェースと、ネットワークノードでＭＥＣサービスを提供することの判断に用いる情報をネットワークに通知する通知部と、を有する端末が提供される。

　本発明の他の側面によれば、ＭＥＣサービスを提供することの判断に用いる情報を端末から受信する受信部と、前記受信した情報から、ＭＥＣサービスを提供する端末を判断する判断部と、前記ＭＥＣサービスを提供する端末のコネクションを、ＭＥＣサーバとの間で設定するコネクション設定部と、を有するネットワークノードが提供される。

　本発明のさらに別の側面によれば、端末と、ネットワークノードと、を備えたネットワークシステムにおける前記端末の通信制御方法であって、ＭＥＣサービスの提供を受けるか否かの判断に用いる情報の入力を受け付け、ネットワークノードでＭＥＣサービスを提供することの判断に用いる情報を前記ネットワークに通知する、端末の通信制御方法が提供される。

　本発明のさらに別の側面によれば、端末と、ネットワークノードと、を備えたネットワークシステムにおける前記ネットワークノードの通信制御方法であって、ＭＥＣサービスを提供することの判断に用いる情報を前記端末から受信し、前記受信した情報から、ＭＥＣサービスを提供する端末を判断し、前記ＭＥＣサービスを提供する端末のコネクションを、ＭＥＣサーバとの間で設定するネットワークノードの通信制御方法が提供される。

　本発明のさらに別の側面によれば、端末を構成するコンピュータに、
　ＭＥＣサービスの提供を受けるか否かの判断に用いる情報の入力を受け付ける処理と、
　ネットワークノードでＭＥＣサービスを提供することの判断に用いる情報をネットワークに通知する処理と、を実行させるプログラムが提供される。

　本発明のさらに別の側面によれば、ネットワークノードを構成するコンピュータに、
　ＭＥＣサービスを提供することの判断に用いる情報を端末から受信する処理と、
　前記受信した情報から、ＭＥＣサービスを提供する端末を判断する処理と、
　前記ＭＥＣサービスを提供する端末のコネクションを、ＭＥＣサーバとの間で設定する処理と、を実行させるプログラムが提供される。

　本発明によれば、前記プログラムを記録したコンピュータ読み出し可能な記録媒体（半導体メモリや、磁気記録媒体、ＣＤ（Compact Disk）－ＲＯＭ（Read Only Memory）等のストレージ）が提供される。

　本発明によれば、端末側でＭＥＣサービスの提供を受けるか否かを選択可能としている。

本発明の例示的な一実施形態のシステムの一例を模式的に説明する図である。本発明の例示的な一実施形態の端末の構成を説明する図である。（Ａ）乃至（Ｄ）は本発明の例示的な一実施形態の端末の表示画面の例を説明する図である。（Ａ）乃至（Ｄ）は本発明の例示的な一実施形態の端末の表示画面の例を説明する図である。（Ａ）本発明の例示的な一実施形態の端末の構成の一例を模式的に例示する図である。（Ｂ）はメモリに記憶される情報の一例を模式的に示す図である。（Ａ）、（Ｂ）は端末の通知部を例示する図である。（Ｃ）は、（Ｂ）の端末の動作を説明する図である。本発明の例示的な一実施形態の基地局の構成の一例を模式的に例示する図である。本発明の例示的な一実施形態の一例を模式的に例示する図である。本発明の例示的な一実施形態の別の例を模式的に例示する図である。本発明の例示的な一実施形態の別の例を模式的に例示する図である。本発明の例示的な一実施形態のさらに別の例を模式的に例示する図である。本発明の例示的な一実施形態のメッセージの一例を示す図である。本発明の例示的な一実施形態のメッセージの別の例を示す図である。本発明の例示的な一実施形態のメッセージのさらに別の例を示す図である。

　本発明の例示的な実施形態について図面を参照して説明する。本発明のいくつかの形態の一つによれば、端末側で、ＭＥＣの利用の有無を設定可能としている。そして、ＭＥＣ誘導可の端末を選択的にＭＥＣサービスへ誘導する構成としてもよい。以下に示される複数の実施形態は、LTE及びSAE(System Architecture Evolution）を収容するEvolved Packet System（EPS）を主な対象として説明される。しかしながら、これらの実施形態は、EPSに限定されるものではなく、他のモバイル通信ネットワーク又はシステム、例えば3GPP(3rd Generation Partnership Project) UMTS(Universal Mobile Telecommunications System)、3GPP2 CDMA2000システム（1xRTT(Single-Carrier Radio Transmission Technology), HRPD (High Rate Packet Data)）、global system for mobile communications（GSM（登録商標））/ General packet radio service（GPRS）システム、及びWiMAX（Worldwide Interoperability for Microwave Access）システム等に適用されてもよい。

＜システム構成＞
　図１は、例示的な一実施形態のシステム構成の一例を模式的に示す図である。図１を参照すると、ＬＴＥ対応の端末（User Equipment:ＵＥ）１０は、ＬＴＥの基地局（evolved NodeB:ｅＮｏｄｅＢ）２０Ａ、Ｓ―ＧＷ（Serving Cateway）２３、Ｐ－ＧＷ（PDN(Packet Data Network) Gatewaｙ）２４を介してパケットデータ網（ＰＤＮ）３０に接続する。端末１０が、３G（3rd Generation）対応の場合、ＵＴＲＡＮ（Universal Terrestrial Radio Access Network）の基地局（ＮｏｄｅＢ）／無線ネットワーク制御局（Radio Network Controller: ＲＮＣ）２０Ｂを介して、ＳＧＳＮ（Serving GPRS(General Packet Radio System) Support Node）２２に接続し、ＳＧＳＮ２２から、Ｓ―ＧＷ２３、Ｐ－ＧＷ２４を介して、パケットデータ網（ＰＤＮ）３０に接続する。図１において、ＭＭＥ（Mobility Management Entity）２１は、加入者プロファイルを保持するＨＳＳ（Home Subscriber Server）２５と連携してユーザの認証(authentication)や、端末１０の移動管理（Mobility Management）やＮＡＳ（Non-Access Stratum）シグナリング等のセッション管理（Session Management）や、ＥＰＳ（Evolved Packet System）ベアラ管理等を行う。Ｓ―ＧＷ２３は基地局との間でユーザデータの送受信を行い、Ｐ―ＧＷ２４との間の通信経路の設定・解放を行う。Ｐ―ＧＷ２４はＩＭＳ（IP（Internet Protocol） Multimedia Subsystem）やインターネット等のパケットデータ網（ＰＤＮ）３０と接続する。またＰ－ＧＷ２４は端末１０に対するＩＰ(Internet Protocol)アドレス（プライベートＩＰアドレス）の割当て等を行う。ＰＣＲＦ（Policy and Charging Rules Function）２６はＱｏＳ（Quality of Service）等のポリシ制御や課金制御ルールを決定する。Ｐ―ＧＷ２４及びＳ―ＧＷ２３はＰＣＲＦ２６からの通知情報に基づき例えばパケット単位にポリシ制御を行う。なお、図１において、各ノード間の線の符号Ｓ１、Ｓ４、Ｓ５等はインタフェースを表している。各ノード間を結ぶ破線はコントロールプレーン（Control-Plane: C-Plane）、実線はユーザプレーン（User-Plane：U-Plane）の信号（データ）を表している。図１では、ＭＥＣサーバとして、ｅＮｏｄｅＢ２０Ａと、ＲＮＣ／ＮｏｄｅＢ２０Ｂにそれぞれ接続された二つのサーバ２９Ａ、２９Ｂが図示されているが、いずれか一方に接続するようにしてもよいし、他のネットワークノードに接続してもよいことは勿論である。２７ＡはＬＴＥ無線アクセス収容網、２７Ｂは３Ｇ無線アクセス収容網、２８はＥＰＣのＬＴＥ無線アクセス収容網２７Ａと３Ｇ無線アクセス収容網２７Ｂに共通のコア網である。

　本発明のいくつかの形態の一つによれば、端末１０は、ＭＥＣサービスの提供を受けるか否かの判断に用いる情報の入力を受け付け、ネットワークノードでＭＥＣサービスを提供することの判断に用いる情報をネットワークに通知するようにしてもよい。

　本発明のいくつかの形態の一つによれば、ネットワークノード（例えば基地局あるいはＭＭＥ等のノード）は、ＭＥＣサービスを提供することの判断に用いる情報を端末１０から受信し、前記受信した情報から、ＭＥＣサービスを提供する端末を判断し、前記ＭＥＣサービスを提供する端末のコネクションを、ＭＥＣサーバとの間で設定するようにしてもよい。

　本発明のいくつかの形態の一つによれば、端末１０と通信接続するＭＥＣサーバ２９Ａ／２９Ｂはコア網２８を介してインターネット等のパケットデータ網３０に接続するようにしてもよい。あるいは、ＭＥＣサーバ２９Ａ／２９Ｂはコア網２８を介さずにインターネット等のパケットデータ網３０に接続するようにしてもよい。

　さらに、ＭＥＣサービスはパケットデータ網（ＰＤＮ）に誘導されないものであってもよい。例えば、ＭＥＣサーバ２９Ａ／２９Ｂは、基地局に接続するキャリアのプライベートネットワーク内に配置されていても良い。この場合、端末―ＭＥＣサーバ間の通信となり、コア網においてＰＤＮへの接続のためのベアラ設定等は不要となる場合もある。例として、ＭＥＣサーバ２９Ａ／２９Ｂは、保持するコンテンツ等を端末１０に配信するコンテンツ配信サービス（Content Delivery Service：CDS）を提供するサーバ（エッジサーバ）として機能するようにしてもよい。なお、ＭＥＣサーバ２９Ａ／２９Ｂにおいて、端末１０から要求されたコンテンツを保持（キャッシュ）していない場合、インターネット上のオリジンサーバ等から取得した上で、キャッシュから端末１０に配信する構成としてもよい。ただし、本発明において、ＭＥＣサービスは、コンテンツ配信サービスに制限されるものでないことは勿論である。例えば、Augmented Reality(AR)サービスのためのサーバであっても良いし、ユーザの位置情報に応じて広告を提供するサービスのためのサーバであっても良いし、映像解析を行うサービスのためのサーバであっても良く、様々なサービスを提供するためのサーバとすることができる。

　以下では、まず、例示的な実施形態の端末について説明し、つづいてネットワークノード（例えば基地局）について説明する。

＜端末の構成＞
　図２は、例示的な実施形態の端末１０の構成の一例を模式的に例示する図である。図２を参照すると、端末１０は、不図示の基地局との間で情報を無線伝送するためのアンテナ１０１と、ＬＴＥ又は３Ｇ対応の通信モジュール１０２と、ＭＥＣサービスの提供を受けるか否かの判断に用いる情報の入力を受け付けるユーザインタフェース（ユーザＩＦ）１０４と、ネットワークノードでＭＥＣサービスを提供することの判断に用いる情報をネットワークに通知する通知部１０３と、各種情報を記憶するメモリ１０５、とを備えている。通信モジュール１０２は、送信中間周波信号を周波数変換し電力増幅してアンテナ１０１から送信し、アンテナ１０１で受信した信号を増幅し中間周波信号への周波数変換を行うＲＦ（Radio Frequency）送受信部（不図示）と、中間周波信号の変調・復調を行うベースバンド部（不図示）と、通信制御を行う通信コンローラ（不図示）等を含むようにしてもよい。なお、通信モジュール１０２はＬＴＥと３Ｇのいずれかに切り替え設定自在な構成としてもよい。ネットワークノードが、基地局の場合、通知部１０３は、通信モジュール１０２から、ＭＥＣサービスを提供することの判断に用いる情報を該基地局に送信する。

　なお、メモリ１０５は、ＤＲＡＭ（Dynamic Random Access Memory）やＥＥＰＲＯＭ（Electrically Erasable Programmable Read-Only Memory）等のＲＯＭ（Read-Only Memory）等の半導体ストレージやＨＤＤ(Hard Disk Drive)等を備えた構成としてもよい。特に制限されないが、通知部１０３とユーザＩＦ１０４の各処理の少なくとも一部をＣＰＵ（Central Processing Unit）等のプロセッサ１０６で実行されるプログラムで実現するようにしてもよい。この場合、特に制限されないが、該プログラムをメモリ１０５に記憶しておき、プロセッサ１０６で該プログラムを読み込み実行するようにしてもよい。

＜ユーザＩＦ＞
　次に図３を参照して、図２のユーザＩＦ１０４について、該ユーザＩＦ１０４が出力するいくつかの表示画面を例に説明する（ただし、以下に制限されない）。

　図３（Ａ）は、端末１０の表示画面１１にポップアップ１１１が表示された様子を例示した図である。ポップアップ（「ポップアップ画面」、「ポップアップウインドウ」ともいう）は、ウェブブラウザ等の画面上で最前面に別のウインドウ等を自動的に表示させること、及び表示された画面をいい、例えば、利用者にメッセージを伝えたり、特定の操作を促したりするために用いられる。なお、表示形態は、ポップアップ画面に制限されるものでないことは勿論である。

　図３（Ｂ）は、図３（Ａ）のポップアップ１１１を例示した図である。図３（Ｂ）に示すように、ポップアップ１１１には、「ＭＥＣを利用しますか？」のメッセージ１１２Ａ等が表示されるようにしてもよい。端末１０のユーザは、ＭＥＣを利用する場合、「はい」のボタン１１３、ＭＥＣを利用しない場合、「いいえ」のボタン１１４を選ぶ（タップする）。なお、この画面に配設されるボタンは、「はい」、「いいえ」に制限されるものでなく、例えば「キャンセル」ボタンを備えてもよい。

　特に制限されるものではないが、端末１０の表示画面１１にポップアップ１１１が出力されるタイミングとしては、例えば以下が挙げられる。端末１０において、
・ＭＥＣサービスの対象のアプリケーション（ＭＥＣサーバから提供されるサービスを利用するアプリケーション）が立ち上がるとき。
・端末１０の電源オン時。
・端末１０が新たなセルに在圏した場合。
・端末１０がトラッキングエリア(Tracking Area：ＴＡ）を移動した場合（UTRANでは、ルーティングエリア（Routing Area：RA）やロケーションエリア（Location Area : LA）を移動した場合）。
・端末１０がトラッキングエリアリスト（Tracking Area List：ＴＡＬ）外に移動して、TＡＵ要求(Tracking Area Update　Request)を上げるとき(UTRANではRAU要求やLAU要求)。
・ＰＤＮ（Packet Data Network）コネクションの確立や、ＥＰＳ（Evolved Packet System）ベアラが確立された時。

　なお、ＰＤＮコネクションは、端末１０からＰ－ＧＷ２４に至る論理的な通信路である。また、ＥＰＳベアラは、端末１０毎に、Ｐ―ＧＷ２４と端末１０との間で確立され、ＩＰ（Internet Protocol）パケットを転送する論理パスをいう。

　特に制限されるものでないが、端末１０に表示されるポップアップ１１１において、端末１０の利用シーンの選択肢として、例えば図３（Ｃ）に示すように、「家」、「オフィス」、「徒歩」、「自転車」、「車」、「列車」などをメニューバー１１５に表示し、ユーザがいずれかを選択するようにしてもよい。この場合、自転車、車、列車等は端末１０が移動する状況にあることを表している。

　あるいは、図３（Ｄ）に示すように、端末１０に表示されるポップアップ１１１に、「移動しますか？」というメッセージ１１２Ｂが出力され、ユーザは「はい」のボタン１１３、又は「いいえ」のボタン１１４を選ぶようにしてもよい。この場合、ユーザが「はい」のボタン１１３を選択することは、端末１０ではＭＥＣサービスの提供を受けないこと（ＭＥＣサービスを利用しないこと）を選択したことに相当する。

　あるいは、ユーザＩＦ１０４の別の表示形態として、例えば図４（Ａ）に示すように、ネットワーク等のセットアップに用いられる設定画面（セットアップ画面）１１６上で、ＭＥＣサーバを利用する、しない、などの設定項目を備えた構成としてもよい。

　あるいは、図４（Ｂ）に示すように、設定画面１１６において選択したエリア内に限り、ＭＥＣサービスを利用するなどの設定をするようにしてもよい。なお、設定画面１１６のエリアボタン１１８をタップすると、図示されない、エリア選択メニューが画面に表示され、エリア選択メニューでは、都道府県、市町村等を適宜選択するようにしてもよい。

　さらに、図４（Ｃ）に示すように、設定画面１１６において、アクセスポイント名（Access Point Name：ＡＰＮ）の設定欄１１９を、ＭＥＣサービス専用に用意しておき、端末１０から、そのＡＰＮ（インターネットやＩＭＳ等に接続するＰＤＮ）を設定するようにしてもよい。設定画面で、ＡＰＮ名を設定し、設定を保存する。なお、ＡＰＮは、パケットデータ網へのアクセスポイントを記述するＤＮＳ（Domain Name System）の命名方式である。

　また、図４（Ｄ）に示すように、アクセスポイントタイプ（Access Point Type）１２０を、ＭＥＣサービス識別用に用意し、そのアクセスポイントタイプを設定するようにしてもよい。アクセスポイントタイプ（ＡＰＮ種別）は、ＡＰＮに対して行う通信のタイプである。例えば、デフォルト設定、ｓｕｐｌ(secure user plane location)、ａｇｐｓ(assisted gps(global positioning system))、ｍｍｓ（multi-media message）等がある。

　次に、図５（Ａ）を参照して、図２の端末１０のユーザＩＦ１０４の構成例について説明する。図５（Ａ）を参照すると、端末１０は、タッチパネル１０４１と、タッチパネル１０４１への入出力を制御する入出力部１０４２と、ＭＥＣサービスを利用するアプリケーションであって入出力部１０４２を介して、例えば図３（Ｂ）乃至図３（Ｄ）に例示した画面を表示するアプリケーション１０４３と、図４（Ａ）乃至図４（Ｄ）に例示した設定画面を表示し端末１０でのネットワークの設定（セットアップ）等を行うセットアップ部１０４４と、アプリケーション１０４３と、セットアップ部１０４４の起動等を制御し、タッチパネル１０４１からの入力情報をメモリ１０５に記憶する制御を行う制御部１０７を備えている。図５（Ａ）において、タッチパネル１０４１、入出力部１０４２、アプリケーション１０４３、セットアップ部１０４４は、図２のユーザＩＦ１０４を構成している。

　制御部１０７は、端末１０の電源オン時や、通信モジュール１０２で送受信した信号に基づき、端末１０が新たなセルに在圏した場合、あるいは、端末１０がトラッキングエリア(Tracking Area：ＴＡ）を移動した場合（ＵＴＲＡＮでは、ルーティングエリア（Routing Area：RA）を移動した場合）、あるいは、端末１０がトラッキングエリア更新要求（ＴＡＵ（Tracking Area Update）Request)を送信するとき、あるいは、ＰＤＮコネクションの確立や、ＥＰＳベアラが確立されたときのいずれかの場合、アプリケーション１０４３を介して、あるいは、直接、図３（Ａ）乃至図３（Ｄ）を参照して説明したポップアップ画面１１１を出力するように、入出力部１０４２を制御するようにしてもよい。また制御部１０７は、端末１０の通信モジュール１０２からトラッキングエリア更新要求（ＴＡＵ（Tracking Area Update）Ｒｅｑｕｅｓｔ）あるいはアタッチ要求（Attach Request）等のＮＡＳメッセージを送信するときに、通知部１０３に対して、ＭＥＣサービスを提供することの判断に用いる情報を、当該ＮＡＳメッセージに挿入して通知する、ことを指示する構成としてもよい。あるいは、制御部１０７は、ネットワーク側からＭＥＣサービス提供可である旨の通知を受信した場合、アプリケーション１０４３を介して、あるいは、直接、図３（Ａ）乃至図３（Ｄ）を参照して説明したポップアップ画面１１１を出力するように、入出力部１０４２を制御するようにしてもよい。

　図５（Ｂ）は、例えば図４（Ａ）に例示した設定画面で設定されたＭＥＣサービスの利用の有無（フラグ情報）を記憶するメモリ１０５のデータフォーマットを例示した図である。メモリ１０５には、サービス種別と、設定情報とを関連付けて記憶する。

＜端末：通知部＞
　次に、端末１０における通知部１０３（図２）について説明する。通知部１０３は、ＭＥＣサービスの提供を受けるか否かの判断に用いる情報の入力を受け、ＭＥＣサービスを提供することの判断に用いる情報をネットワークノード（例えば基地局）に通知する。より詳しくは、通知部１０３は、図５（Ａ）のアプリケーション１０４３を介して入力したＭＥＣサービスに関する利用の有無の情報、又は、メモリ１０５に記憶されたＭＥＣサービスに関する利用の有無の情報（図５（Ｂ））を、制御部１０７を介して受け取り、所定のＮＡＳメッセージ等に該情報を含め、通信モジュール１０２、アンテナ１０１を介して、ネットワーク（基地局）に送信する。

　図６（Ａ）は、図２の通知部１０３を、モビリティ管理（Mobility Management）／セッション管理(Session Management)プロトコル処理部１０３１で構成した例を示す図である。モビリティ管理とセッション管理はＮＡＳ（Non-Access Stratum）の二つの主たる機能である。ＮＡＳレイヤでのメッセージは、端末とＭＭＥ（ＳＧＳＮ）間で透過的に送受信される制御メッセージである。端末１０からＭＭＥ２１（ＳＧＳＮ２２）に送られるＮＡＳメッセージは、アタッチ要求、デタッチ要求、セッション（ベアラ）要求、及び位置更新要求などの要求メッセージを含む。ＥＰＳ（Evolved Packet System）の場合、端末（ＵＥ）からのＮＡＳ要求メッセージは、例えば、
・アタッチ要求（Attach Request）、
・サービス要求（Service Request）、
・ＰＤＮ接続性要求（PDN connectivity request）、
・ベアラリソース割り当て要求（Bearer Resource Allocation Request）、
・ベアラリソース修正要求（Bearer Resource Modification Request）、
・トラッキングエリア更新要求（TAU (Tracking Area Update) Request）、及び、
・ルーティングエリア更新要求（RAU (Routing Area Update) Request）
などのうち少なくとも１つを含む。

　一方、ＭＭＥ２１（ＳＧＳＮ２２）から端末１０に送信されるＮＡＳメッセージは、これらのＮＡＳ要求メッセージに対する受諾（ACCEPT）メッセージ、拒絶（REJECT）メッセージを含む。Ｅ－ＵＴＲＡＮ端末とネットワーク間のモビリティ管理はＭＭＥのＣ－ＰｌａｎｅのＮＡＳレイヤのプロトコルで制御される。Ｅ－ＵＲＡＮの端末とＭＭＥ間のモビリティ管理の共通の手続きは、ＧＵＴＩ（Global Unique Temporary Identity：ＭＭＥが端末（ＵＥ）に割り当てる一時的な端末識別子）の割り当て、認証、セキュリティモード制御、端末（ＵＥ）識別等を含み、アタッチ、デタッチ、位置登録エリア更新（ＴＡＵ）を含むほか、ＥＭＭ（EPS Mobility Management）接続管理として、サービス要求、ページング、ＮＡＳメッセージ転送等を含む。

　本実施形態では、端末１０のモビリティ管理／セッション管理プロトコル処理部１０３１が、図３（Ｂ）乃至図３（Ｄ）に示した画面から、ユーザＩＦ１０４に入力された情報を、トラッキングエリア更新要求（TAU　Request）に載せるようにしてもよい。端末１０が新たなトラッキングエリア（ＴＡ）に移動し、新たなトラッキングエリア（ＴＡ）が、端末に設定されたトラッキングエリアリスト（TA-List）に含まれない場合、端末は、基地局に、トラッキングエリア更新要求（TAU Request）メッセージを送信することで、ＴＡＵ手順が開示される。ただし、端末が新しいトラッキングエリアに入ったとき、該トラッキングエリアが、端末に設定されているトラッキングエリアリスト（TA-List）に含まれている場合には、トラッキングエリア更新要求（TAU Request）を送信しないようにしてもよい。

　本実施形態によれば、トラッキングエリア更新要求（TAU Request）に、ＭＥＣサービスの利用情報を送るためのフィールドを新たに設けるようにしてもよい。なお、TAU Requestメッセージには、UE Core Network Capability, MS Network Capability, old GUTI（Global Unique Temporary Identity）, Old GUTI type, last visited TAI（Tracking Area Identity）, active flag, EPS bearer status, P-TMSI（Packet-Temporary Mobile Subscriber Identity） Signature, additional GUTI, eKSI(Key Set Identifier in E-UTRAN), NAS sequence number, NAS-MAC(Message Authentication Code), KSI, Voice domain preference and UE's usage setting等の情報アイテム（Information Item :IE）が含まれる。

　端末１０のモビリティ管理／セッション管理プロトコル処理部１０３１では、図３（Ｂ）乃至図３（Ｄ）に示した画面からユーザＩＦ１０４に入力された情報は、ＭＥＣサービスに誘導して良いか否かのみを示す１ビットを、トラッキングエリア更新（TAU）要求メッセージに設けるようにしてもよいし、例えば図３（Ｃ）に示したように、利用シーンを表すビット（利用シーンが８個の場合、３ビット）であっても良い。また、端末１０内の例えば制御部１０７において、利用シーンの一部（例えば、移動が予想される徒歩、自転車、車、列車）についてＭＥＣサービスに誘導しないことを示すビットに、その他の利用シーンを、ＭＥＣサービスに誘導して良いことを示すビットに変換して、メッセージに設定するようにしても良い。

　本実施形態において、モビリティ管理／セッション管理プロトコル処理部１０３１は、ＭＥＣサービスの利用情報を送るために、ＴＡＵ要求に代えて、アタッチ要求（Attach Request）メッセージを用いて、端末１０をＭＥＣサービスに誘導して良いか否を示す情報を送信するようにしてもよい。アタッチ要求でＭＥＣサービスの利用の有無の情報を送信する場合は、端末１０での設定画面（図４参照）で設定することが好適である。

　さらに、本実施形態において、モビリティ管理／セッション管理プロトコル処理部１０３１は、ＭＥＣサービスの利用情報を送るために、サービス要求（Service Request）を用いてもよい。サービス要求（Service Request）は、端末１０をネットワークに接続するＥＭＭ（EPS Mobility Management）接続管理手順であり、端末１０側から開始されるか、又はネットワーク側からページングを端末１０に送信することで開始され、ＮＡＳシグナリング接続確立をスタートさせる。

　あるいは、本実施形態において、モビリティ管理／セッション管理プロトコル処理部１０３１が、ＮＡＳメッセージに、端末１０をＭＥＣサービスに誘導して良いか否を示すＭＥＣサービスの利用情報を載せるようにしてもよい。例えば、セッション管理プロトコルの処理の機能を変えなくとも、上記のアクセスポイント名（ＡＰＮ）やアクセスポイントタイプ（ＡＰＮ　Ｔｙｐｅ）の情報をセッション管理プロトコルのＮＡＳメッセージに載せることができる。

　本実施形態において、端末１０のモビリティ管理／セッション管理プロトコル処理部１０３１は、セッション管理手順として、例えばアタッチ手順（Attach Procedure）の一部ではなく、例えばＰＤＮ接続性要求（PDN connectivity request）メッセージ（スタンドアロン型）を用いて、端末１０をＭＥＣサービスに誘導して良いか否を示す情報を送信するようにしてもよい。

　端末１０からのＮＡＳメッセージとしてＭＭＥに送信されるＰＤＮ接続性要求（PDN connectivity request）には、ＡＰＮやＰＤＮアドレス等が含まれる。このＡＰＮが、図３（Ｃ）のＡＰＮと一致している場合、端末１０のモビリティ管理／セッション管理プロトコル処理部１０３１は、ＭＥＣサービスに誘導して良いか否を示す情報を送信するようにしてもよい。また端末１０のモビリティ管理／セッション管理プロトコル処理部１０３１は、セッション管理手順として、ベアラリソース割り当て要求メッセージ等を用いて、端末１０をＭＥＣサービスに誘導して良いか否を示す情報を送信するようにしてもよい。

　ＥＰＳでは、端末とＰＤＮ間のＩＰ接続性を定義するために、ＰＤＮコネクションと、ＥＰＳベアラが導入されている。ＰＤＮコネクションは、ＰＤＮコネクション確立時に作成されるデフォルトＥＰＳベアラのほか、特定のＱｏＳ（Quality of Service）等の扱いが必要な場合、専用ＥＰＳベアラが確立される。

　あるいは、図６（Ｂ）に示すように、ＮＡＳメッセージ等による通信プロトコルではなく、例えば、端末１０において、ＰＤＮコネクション確立後、アプリケーション１０３２で、一旦、パケットデータ網（ＰＤＮ）のサーバ宛てに、端末１０をＭＥＣサービスに誘導して良いか否を示す情報を送信し、当該サーバが、基地局に、何らかの手段で、端末１０をＭＥＣサービスに誘導して良いか否を示す情報を通知するようにしてもよい。

　この場合、例えば図６（Ｃ）に示すように、端末１０から、基地局２０Ａ、コア網２８のＳ－ＧＷ２３、Ｐ－ＧＷ２４を介して、ＰＤＮ３０のサーバ３１に対して、端末１０をＭＥＣサービスに誘導して良いか否を示す情報（ユーザプレーン・データ）が送信される。サーバ３１は、該情報を受信すると、基地局２０Ａに対して、端末１０をＭＥＣサービスに誘導して良いか否を示す情報を通知するための制御データを送信する。その際、該サーバ３１は、Ｐ－ＧＷ２４等に対して該制御データを送信し、Ｐ－ＧＷ２４から、Ｓ－ＧＷ２３を介して、基地局（ｅＮｏｄｅＢ）２０Ａに通知するようにしてもよい。

＜ネットワークノード：基地局＞
　図７は、ネットワークノードとしての基地局を説明する図である。図７を参照すると、基地局２０は、アンテナ２０１、無線部とベースバンド処理部を備えた通信装置２０２、ＭＥＣ情報受信部２０３、判断部２０４、コネクション設定部２０５、メモリ２０６を備え、ＭＭＥ２１、Ｓ－ＧＷ２２、ＭＥＣサーバ２９とそれぞれ接続するネットワークインタ（ＮＷ）フェース２０７、２０８、２０９を備えている。ＮＷインタフェース２０７は、図１の基地局２０ＡのＭＭＥ２１側のインタフェースである、コントロールプレーン（Ｃ－Ｐｌａｎｅ）のＳ１－ＭＭＥに対応している。ＮＷインタフェース２０８、２０９は、図１の基地局２０ＡのＳ－ＧＷ２３側のインタフェースであるＳ１－Ｕに対応している。

　ＭＥＣ情報受信部２０３は、通信装置２０２が端末１０から受信したデータから、ＭＥＣサービスを提供することの判断に用いる情報を取得する。判断部２０４は、取得した情報から、ＭＥＣサービスを提供する端末を判断する。コネクション設定部２０５は、判断部２０４で、ＭＥＣサービスを提供する端末と判断した端末１０と、ＭＥＣサーバ２９との間の接続を設定する。コネクション設定部２０５での設定により、ＭＥＣサーバ２９はネットワークインタフェース２０７を介して通信装置２０２に接続し、端末１０との間でデータを送信又は受信する。基地局２０は、ＭＥＣサーバ２９に接続していることの通知（ＭＥＣサービス提供可である旨の通知）を端末に行うようにしてもよい。なお、図７では、基地局２０とＭＥＣサーバ２９は互いに別のユニットとして例示されているが、基地局２０とＭＥＣサーバ２９は一ユニット（一体）に統合してもよい。

　ＭＥＣ情報受信部２０３は、例えば端末１０から送信されたＮＡＳメッセージの予め定められた所定のビットフィールドを抽出し、ＭＥＣサービスを提供することの判断に用いる情報を取得する。

　判断部２０４では、ＭＥＣサービスを提供することの判断に用いる情報がＭＥＣサービスの提供の可否のフラグの場合には、該フラグの値にしたがって、ＭＥＣサービス提供の有無を判断する。

　端末１０から送信された情報が、利用シーンのように、単純な可否情報でない場合は、例えば、「家」、「オフィス」のユーザは、移動しないと判断し、MECサービス提供可と判断する。一方、「徒歩」、「自転車」、「車」、「電車」などの場合には、MECサービス提供否、と判断するようにしてもよい。また、Ｃ－ＲＡＮ（Centralized Radio Access Network）のようになっていたり、あるいは、カバレージが広い基地局の場合は、「徒歩」、「自転車」の場合、ＭＥＣサービス提供可と判断するようにしてもよい。なお、Ｃ－ＲＡＮは、基地局の無線制御部（Base-Band Unit：ＢＢＵ）を収容局（Central Office）にまとめ、例えば一つの無線制御部で複数の基地局の動作を制御するネットワーク（ＲＡＮ）構成である。

　コネクション設定部２０５は、受信した情報から、ＭＥＣサービスを利用させると判断した端末１０を、ネットワークノード（例えば基地局）の近傍に設置、あるいは、一体化されたＭＥＣサーバ２９と、端末１０との間でコネクションを設定する。

　なお、メモリ２０６は、ＤＲＡＭ（Dynamic Random Access Memory）やＥＥＰＲＯＭ（Electrically Erasable Programmable Read-Only Memory）等のＲＯＭ（Read-Only Memory）等の半導体ストレージや、ＨＤＤ(Hard Disk Drive)、あるいはＣＤ（Compact Disk）－ＲＯＭ、ＤＶＤ(Digital Versatile Disk)等を備えた構成としてもよい。特に制限されないが、ＭＥＣ情報受信部２０３、判断部２０４、コネクション設定部２０５の各処理の少なくとも一部をＣＰＵ等のプロセッサ２１０で実行されるプログラムで実現するようにしてもよい。この場合、特に制限されないが、該プログラムをメモリ２０６に記憶しておき、プロセッサ２１０で該プログラムを読み込み実行するようにしてもよい。

　基地局２０のＭＥＣ情報受信部２０３を、端末に関して図６（Ａ）を参照して説明したモビリティ管理（Mobility Management）／セッション管理（Session Management）プロトコルの処理を行う構成とし、端末１０から送信されるＮＡＳメッセージに含まれるＭＥＣサービス情報（端末がＭＥＣサービス利用可／不可等）を解析して、端末とＭＥＣサーバを接続する例のいくつかを以下に説明する。

＜トラッキングエリア更新要求の例＞
　図８に示すように、端末（ＵＥ）から基地局（ｅＮｏｄｅＢ）に送信されたトラッキングエリア更新要求（TAU Request）の予め定められたフィールドを、基地局の例えば、ＭＥＣ情報受信部２０３が解析してＭＥＣサービスを提供することの判断に用いる情報を取得するようにしてもよい。なお、図８の端末（ＵＥ）、基地局（ｅＮｏｄｅＢ）、ＭＥＣサーバ、ＭＭＥ、Ｓ－ＧＷ、Ｐ－ＧＷ、ＨＳＳは、図１の１０、２０Ａ、２９Ａ、２１、２３、２４、２５にそれぞれ対応している（後述する図９－図１１についても同様である）。

　図８では、端末（ＵＥ）のトラッキングエリア（ＴＡ）の移動により、ＭＭＥが新たなＭＭＥになるが、Ｓ－ＧＷが変わらない場合に対応している。端末（ＵＥ）がトラッキングエリア（ＴＡ）を移動する等、ＴＡＵ手続開始のトリガが発生すると（Ｓ１０１）、端末（ＵＥ）は基地局（ｅＮｏｄｅＢ）にＴＡＵ　Ｒｅｑｕｅｓｔを送信する（Ｓ１０２）。基地局（ｅＮｏｄｅＢ）は、ＴＡＵ　Ｒｅｑｕｅｓｔを新ＭＭＥに送信する（Ｓ１０３）。新ＭＭＥは、旧ＭＭＥにコンテキスト要求(Context Request)を送信して（Ｓ１０４）、旧ＭＭＥから端末（ＵＥ）の情報を取得し（Ｓ１０５）、コンテキストアクノリッジ(Context Acknowledge)を旧ＭＭＥに送信する（Ｓ１０６）。新ＭＭＥは、Ｓ－ＧＷにベアラ更新要求(Create Session Request)を行い（Ｓ１０７）、Ｓ－ＧＷとＰ－ＧＷ間のベアラを設定し（Ｓ１０８－Ｓ１０９）、Ｓ－ＧＷからベアラ更新応答を受信する（Ｓ１１０）。さらに、新ＭＭＥはＨＳＳに位置更新を要求し（Ｓ１１１－Ｓ１１４）、端末（ＵＥ）に、トラッキングエリア更新要求の受理を示すＴＡＵ　Ａｃｃｅｐｔを送信する（Ｓ１１５）。

　基地局（ｅＮｏｄｅＢ）では、ステップＳ１０２で端末（ＵＥ）から送信されたＴＡＵ　Ｒｅｑｕｅｓｔに含まれる情報をメモリ２０６に記憶しておき、判断部２０４で、ＴＡＵ　Ｒｅｑｕｅｓｔのビットフィールドを解析し、端末（ＵＥ）がＭＥＣサービス可の場合、端末（ＵＥ）とＭＥＣサーバとの接続を設定することができる（Ｓ１１６）。なお、基地局（ｅＮｏｄｅＢ）における端末（ＵＥ）とＭＥＣサーバのコネクション設定処理は、ＴＡＵ　Ａｃｃｅｐｔの送信の後に制限されるものでないことは勿論である。なお、提供するサービスに応じて、ＭＥＣサーバは、コア網のＰ－ＧＷを介してパケットデータ網（ＰＤＮ）に接続するようにしてもよい。

　なお、図８において、ステップＳ１０３からＳ１１４のステップ（またはその一部）は、ＭＥＣサービス可の場合は、基地局とＭＥＣサーバの間で仮想的に実行することで、Ｓ１１６の処理とするのが好適である。その理由は、ＭＥＣサービス可の場合、実際のサービスがパケットデータ網（ＰＤＮ）に誘導されないため、コア網での処理（またはその一部）は不要となるためである。冗長にはなるが、ステップＳ１０３からＳ１１４のステップ（またはその一部）も実行するが、同等の処理を、基地局とＭＥＣサーバの間で仮想的に実行するようにすることも可能である。前者の場合は、ステップＳ１１５のＴＡＵ　Ａｃｃｅｐｔを基地局（ｅＮｏｄｅＢ）が新ＭＭＥに代わり、返すようにすることが好適である。

　なお、端末（ＵＥ）に対して、ＭＥＣサービスの提供を受けるか否かの判断に用いる情報は、必ずしも基地局（ｅＮｏｄｅＢ）が解析しなくても良く、例えば、ＴＡＵ　Ｒｅｑｕｅｓｔを受け取った新ＭＭＥが解析し、基地局に通知するようにしても良い。この場合、この通知は、ステップＳ１１５のＴＡＵ　Ａｃｃｅｐｔに含めて送るようにしても良いし、別のメッセージとして通知しても良い。また、ステップＳ１０４からＳ１１４のステップ（またはその一部）は、ＭＥＣサービス可の場合には、基地局とＭＥＣサーバの間で仮想的に実行するようにしても良い。その理由は、ＭＥＣサービス可の場合には、実際のサービスがコア網（パケットデータ網）に誘導されないため、これらの処理（またはその一部）は不要となるためである。

＜アタッチ要求の例＞
　図９に示すように、端末（ＵＥ）から基地局（ｅＮｏｄｅＢ）に送信されたアタッチ要求（Attach Request）メッセージの予め定められたフィールドを、基地局の例えば、ＭＥＣ情報受信部２０３が解析して、ＭＥＣサービスの提供を受けるか否かの判断に用いる情報を取得するようにしてもよい。アタッチ要求（Attach Request）（Ｓ２０３）の前に、端末は、基地局にＲＲＣ（Radio Resource Control）接続要求（RRC Connection Request）を送信し（Ｓ２０１）、基地局はＲＲＣ接続セットアップ（RRC Connection Setup）を送信する（Ｓ２０２）ことで、端末と基地局間でＲＲＣ接続が行われる。

　端末（ＵＥ）は、アタッチ要求（Attach Request）をＲＲＣ接続セットアップ完了（RRC Connection Setup　Complete）メッセージに含ませて、基地局（ｅＮｏｄｅＢ）に送信する（Ｓ２０３）。

　基地局（ｅＮｏｄｅＢ）は、ＭＭＥに送信するイニシャルＵＥメッセージ（Initial UE Message）にアタッチ要求を埋め込んでＭＭＥに送信する（Ｓ２０４）。なお、イニシャルＵＥメッセージ（Initial UE Message）には、ＰＤＮ接続性要求（PDN Connectivity Request）等も含まれる。ステップＳ２０４の結果、基地局（ｅＮｏｄｅＢ）とＭＭＥ間にＳ１　Ｓｉｇｎａｌｉｎｇ　Ｃｏｎｎｅｃｔｉｏｎが確立する。その後、認証・セキュリティ手順が行われ（Ｓ２０５）、ＭＭＥはＨＳＳへの位置登録要求（Ｓ２０６、Ｓ２０７）、Ｓ－ＧＷに対してベアラ設定要求を行い（Ｓ２０８）、Ｓ－ＧＷとＰ－ＧＷ間でベアラ設定要求、応答が行われ（Ｓ２０９、Ｓ２１０）、Ｓ－ＧＷとＰ－ＧＷ間のＳ５ベアラが確立され、Ｓ－ＧＷは、ベアラ設定応答をＭＭＥに返し（Ｓ２１１）、ＭＭＥは、コンテキスト設定要求を基地局（ｅＮｏｄｅＢ）に送信する（Ｓ２１２）。

　基地局（ｅＮｏｄｅＢ）は、アタッチアクセプト（Attach Accept）を、ＲＲＣ接続再設定（RRC Connection Reconfiguration）メッセージに含めて端末（ＵＥ）に送信する（Ｓ２１３）。端末（ＵＥ）と基地局（ｅＮｏｄｅＢ）間のデータ無線ベアラ（Data Radio Bearer: DRB）が確立し（Ｓ２１４）、基地局（ｅＮｏｄｅＢ）はＭＭＥにコンテキスト設定応答を返し（Ｓ２１５）、端末（ＵＥ）は、アタッチ完了（Attach Complete）をＭＭＥに返す（Ｓ２１６）。ＭＭＥはＳ－ＧＷとの間のＳ１ベアラを更新する（Ｓ２１７、Ｓ２１８）。

　以上により、ユーザプレーン（U-plane）において、端末と基地局間のデータ無線ベアラ、基地局とＳ－ＧＷ間のＳ１ベアラ、Ｓ－ＧＷとＰ－ＧＷ間のＳ５ベアラが全て確立され、ＮＡＳシグナリング接続（端末と基地局間のRRC Connection、基地局とＭＭＥ間のS1 Signaling Connection）が確立する。

　基地局（ｅＮｏｄｅＢ）は、例えばステップＳ２０３で端末（ＵＥ）から送信されたアタッチ要求（RRC Connection Setup Complete）に含まれるＭＥＣサービス情報をメモリ２０６に記憶しておき、端末（ＵＥ）がＭＥＣサービス対応可の場合、データ無線ベアラが設定された端末とＭＥＣサーバとを接続するようにしてもよい（Ｓ２１９）。なお、基地局（ｅＮｏｄｅＢ）における端末（ＵＥ）とＭＥＣサーバのコネクション設定処理は、アタッチ完了（Ｓ２１６）等の後に制限されるものでなく、例えば端末（ＵＥ）と基地局（ｅＮｏｄｅＢ）間のデータ無線ベアラ（ＤＲＢ）が確立した後であれば、任意のタイミングで行うようにしてもよい。なお、提供するサービスに応じて、ＭＥＣサーバは、コア網のＰ－ＧＷを介してパケットデータ網に接続するようにしてもよい。

　なお、図９において、ステップＳ２０４からＳ２１２、Ｓ２１５、及びＳ２１７のステップ（またはその一部）は、ＭＥＣサービス可の場合は、基地局とＭＥＣサーバの間で仮想的に実行することで、Ｓ２１９の処理とするのが好適である場合もある。その理由は、ＭＥＣサービス可の場合は、実際のサービスがパケットデータ網（ＰＤＮ）に誘導されないため、コア網での処理（またはその一部）は不要となるためである。冗長にはなるが、これらのコア網での処理（またはその一部）も実行するが、同等の処理を、基地局とＭＥＣサーバの間で仮想的に実行するようにすることも可能である。前者の場合は、ステップＳ２１６のアタッチ完了（Attach Complete）を基地局（ｅＮｏｄｅＢ）がＭＭＥに中継しないようにすることが好適である。

　なお、端末（ＵＥ）に対して、ＭＥＣサービスの提供を受けるか否かの判断に用いる情報は、必ずしも基地局（ｅＮｏｄｅＢ）が解析しなくても良く、例えば、Ａｔｔａｃｈ　Ｒｅｑｕｅｓｔを受け取ったＭＭＥが解析し、基地局に通知するようにしても良い。この場合、基地局は、その後の処理を基地局とＭＥＣサーバの間で仮想的に実行するようにすることが好適である。

＜サービス要求の例＞
　あるいは、図１０に示すように、端末（ＵＥ）から基地局（ｅＮｏｄｅＢ）に送信されたサービス要求（Service Request）メッセージの予め定められたフィールドを解析してＭＥＣサービスを提供することの判断に用いる情報を取得するようにしてもよい。図１０では、端末主導のサービス要求（UE triggered Service Request）の手順が例示されているが、ネットワーク側からのトリガによるサービス要求（Network triggered Service Request）についても同様にして適用される。

　端末（ＵＥ）からＰＤＮ側へデータを送信する場合、端末（ＵＥ）は、サービス要求（Service Request）を、ＲＲＣ接続設定完了（RRC Connection Setup Complete）メッセージで基地局（ｅＮｏｄｅＢ）に送信する（Ｓ３０３）。つづいて基地局（ｅＮｏｄｅＢ）は、端末（ＵＥ）から送信されたサービス要求を例えばイニシャルＵＥメッセージ(Initial UE Massage)に含めて、ＭＭＥに送信する（Ｓ３０４）。

　端末（ｅＮｏｄｅＢ）、ＭＭＥ、ＨＳＳ間で認証・セキュリティ手順が行われ（Ｓ３０５）、ＭＭＥはコンテキスト設定要求を基地局に送信する（Ｓ３０６）。基地局（ｅＮｏｄｅＢ）はＲＲＣ接続再構成（RRC Connection Reconfiguration）を端末（ＵＥ）に送信する（Ｓ３０７）。データ無線ベアラが確立し（Ｓ３０８）、端末（ＵＥ）は、基地局（ｅＮｏｄｅＢ）、Ｓ－ＧＷ、Ｐ－ＧＷを介してＰＤＮにデータを送信する（Ｓ３０９）。基地局（ｅＮｏｄｅＢ）はＭＭＥにコンテキスト設定応答を送信する（Ｓ３１０）。ＭＭＥはＳ－ＧＷにベアラ更新要求を送信し（Ｓ３１１）、Ｓ－ＧＷとの間のＳ１ベアラを設定し、Ｓ－ＧＷはベアラ更新応答を返す（Ｓ３１２）。

　基地局（ｅＮｏｄｅＢ）は、例えばステップＳ３０３で端末（ＵＥ）から送信されたサービス要求（RRC　Connection Setup Complete）に含まれるＭＥＣサービス情報（ＭＥＣサービスを提供することの判断に持ちる情報）をメモリ２０６に記憶しておき、端末（ＵＥ）がＭＥＣサービス対応可の場合、ステップＳ３０８でデータ無線ベアラが設定された端末とＭＥＣサーバとを接続するようにしてもよい（Ｓ３１３）。なお、提供するサービスに応じて、ＭＥＣサーバは、コア網のＰ－ＧＷを介してパケットデータ網に接続するようにしてもよい。

　なお、図１０において、ステップＳ３０４からＳ３０７、Ｓ３１０及びＳ３１１のステップ（またはその一部）は、ＭＥＣサービス可の場合は、基地局とＭＥＣサーバの間で仮想的に実行することで、Ｓ３１３の処理とするのが好適の場合もある。その理由は、ＭＥＣサービス可の場合は、実際のサービスがパケットデータ網（ＰＤＮ）に誘導されないため、コア網での処理（またはその一部）は不要となるためである。冗長にはなるが、これらのコア網での処理（またはその一部）も実行するが、同等の処理を、基地局とＭＥＣサーバの間で仮想的に実行するようにすることも可能である。前者の場合は、Ｓ３０９のアップリンクデータの送信後、例えば、ステップＳ３１０のコンテキスト設定応答を基地局（ｅＮｏｄｅＢ）がＭＭＥに送信しないようにすることが好適である。

　なお、端末（ＵＥ）に対して、ＭＥＣサービスの提供を受けるか否かの判断に用いる情報は、必ずしも基地局（ｅＮｏｄｅＢ）が解析しなくても良く、例えば、サービス要求（Service Request）を受け取ったＭＭＥが解析し、基地局に通知するようにしても良い。この場合、基地局は、その後の処理を基地局とＭＥＣサーバの間で仮想的に実行するようにすることが好適である。

＜ＰＤＮ接続性要求の例＞
　図１１に示すように、端末（ＵＥ）から基地局（ｅＮｏｄｅＢ）に送信されたＰＤＮ接続性要求（PDN Connectivity Request）メッセージのアクセスポイント名（ＡＰＮ）等から、ＭＥＣサービスを提供することの判断に用いる情報を取得するようにしてもよい。図１１は、端末により要求されたＰＤＰ接続性手順を例示する図である。端末（ＵＥ）は、Ｅ－ＵＴＲＡＮを介してあるＰＤＮに接続している場合であっても、さらに追加のＰＤＮへの接続要求を行うことができる。

　端末（ＵＥ）からＰＤＮ接続性の更新を行う場合、端末（ＵＥ）はＰＤＮ接続性要求（PDN Connectivity Request）メッセージをＭＭＥに送信する（Ｓ４０１、Ｓ４０２）。ＭＭＥは、ＰＤＮ接続性要求（PDN Connectivity Request）で指定されたＡＰＮに対応する新Ｐ－ＧＷを選択し、新Ｓ－ＧＷにベアラ設定要求を送信し（Ｓ４０３）、新Ｓ－ＧＷと新Ｐ－ＧＷ間のＳ５ベアラを設定し（Ｓ４０４、Ｓ４０５）、新Ｓ－ＧＷにベアラ設定応答を受けとる（Ｓ４０６）。ＭＭＥは基地局（ｅＮｏｄｅＢ）にコンテキスト設定要求を送信し（Ｓ４０７）、基地局（ｅＮｏｄｅＢ）は端末（ＵＥ）に、無線ベアラ設定要求（PDN Connectivity Accept）を送信する（Ｓ４０８）。端末（ＵＥ）は、無線ベアラ設定応答を基地局（ｅＮｏｄｅＢ）に送信し（Ｓ４０９）、基地局（ｅＮｏｄｅＢ）はＭＭＥにコンテキスト設定応答を送信する（Ｓ４１０）。ＭＭＥは、Ｓ－ＧＷにベアラ更新要求を送信し（Ｓ４１１）、Ｓ－ＧＷとの間のＳ１ベアラを設定し、Ｓ－ＧＷはベアラ更新応答を返す（Ｓ４１２）。

　基地局（ｅＮｏｄｅＢ）は、ステップＳ４０１で端末（ＵＥ）から送信されたＰＤＮ接続性要求（PDN Connectivity Request）メッセージに含まれるアクセスポイント名（ＡＰＮ）等の情報要素を抽出する。本実施形態において、ＭＥＣサービスを提供することの判断に用いる情報が、アクセスポイント名（ＡＰＮ）やアクセスポイントタイプ（ＡＰＮ　Ｔｙｐｅ）等である場合、ＭＥＣサーバに紐付けされているアクセスポイント名（ＡＰＮ）やアクセスポイントタイプ（ＡＰＮ　Ｔｙｐｅ）を、予めメモリ（図７の２０６)に記憶しておく。基地局（ｅＮｏｄｅＢ）は、例えば端末（ＵＥ）から送信されたＰＤＮ接続性要求（PDN Connectivity Request）メッセージに含まれるアクセスポイント名（ＡＰＮ）やアクセスポイントタイプ（ＡＰＮ　Ｔｙｐｅ）等が、予めメモリに記憶されている情報と一致する場合、ＭＥＣサービス提供可と判断する。例えば、ＰＤＮ接続性要求（PDN Connectivity Request）メッセージに含まれるＡＰＮが、ＭＥＣサービス提供可としてメモリに設定登録されたＡＰＮである場合、端末（ＵＥ）とＭＥＣサーバとの接続を設定する（Ｓ４１３）。その際、基地局（ｅＮｏｄｅＢ）は、端末（ＵＥ）から送信されたＰＤＮ接続性要求（PDN Connectivity Request）メッセージに含まれるアクセスポイント名（ＡＰＮ）から、端末（ＵＥ）とＭＥＣサーバとの接続を制御するだけでなく、ＰＤＮ接続性要求（PDN Connectivity Request）に、端末（ＵＥ）からのＭＥＣサービス情報が含まれ、ＭＥＣサービス利用可に設定されている場合に限り、端末（ＵＥ）とＭＥＣサーバとの接続を行うようにしてもよい。なお、提供するサービスに応じて、ＭＥＣサーバは、コア網のＰ－ＧＷを介してパケットデータ網（ＰＤＮ）に接続するようにしてもよい。

　なお、図１１において、ステップＳ４０２からＳ４０７、Ｓ４１０及びＳ４１１のステップ（またはその一部）は、ＭＥＣサービス可の場合は、基地局とＭＥＣサーバの間で仮想的に実行することで、ステップＳ４１３の処理とするのが好適である場合がある。その理由は、ＭＥＣサービス可の場合は、実際のサービスがパケットデータ網（ＰＤＮ）に誘導されないため、コア網での処理（またはその一部）は不要となるためである。冗長にはなるが、これらのコア網での処理（またはその一部）も実行するが、同等の処理を、基地局とＭＥＣサーバの間で仮想的に実行するようにすることも可能である。前者の場合は、例えば、ステップＳ４１０のコンテキスト設定応答を基地局（ｅＮｏｄｅＢ）がＭＭＥに中継しないようにすることが好適である。　

　なお、端末（ＵＥ）に対して、ＭＥＣサービスの提供を受けるか否かの判断に用いる情報は、必ずしも基地局（ｅＮｏｄｅＢ）が解析しなくても良く、例えば、ステップＳ４０２でＰＤＮ接続性要求（PDN Connectivity Request）を受け取ったＭＭＥが解析し、基地局に通知するようにしても良い。この場合、基地局は、その後の処理を基地局とＭＥＣサーバの間で仮想的に実行するようにすることが好適である。

　以上、端末１０の通知部１０３（図２）が、ネットワークノードでＭＥＣサービスを提供することの判断に用いる情報を通知するためのメッセージの例をいくつかを説明したが、ネットワークノードでＭＥＣサービスを提供することの判断に用いる情報の通知は、上記したメッセージに制限されるものでないことは勿論である。例えば、端末１０の通知部１０３は、専用のメッセージを用いて、ＭＥＣサービスを提供することの判断に用いる情報を、ネットワークノードに通知してもよいことは勿論である。また、図７において、基地局２０のＭＥＣ情報受信部２０３は、端末１０から送信されたメッセージから、ＭＥＣサービスを提供することの判断に用いる情報を取得する構成に限定されるものではない。基地局２０のＭＥＣ情報受信部２０３は、例えば図６（Ｃ）に示したように、ＰＤＮ３０に接続するサーバ３１から送信された情報（ＭＥＣサービスを提供する端末を判断する情報）を受信するようにしてもよい。

　コネクション設定部２０５は、例えばＳＤＮ（Software Design Network）、ＮＦＶ(Network Function Virtualization)など、サーバ仮想化技術により実現するようにしてもよい。

　以上、ＭＥＣサービスを提供する端末を判断する情報を受信してＭＥＣサービスを提供する端末を判断し、端末とＭＥＣサーバとのコネクションを設定するネットワークノードとして、基地局を例に説明したが、該ネットワークノードは、基地局に制限されるものでなく、例えばＭＭＥなどで実現するようにしてもよい。

　本実施形態において、ネットワークノードが、ＭＥＣサービスを提供できるか否かを、下記のいずれかの無線通信プロトコルのシグナルで端末１０に通知する構成としてもよい。いずれもＭＥＣサービス用に割り当てられたＩＤが付与される。例えば、上／下何ケタかのビットを１／０にする、あるレンジの値とする等。例えば、
・RRC Connection Reconfigurationメッセージに含まれるモビリティ制御情報（mobility Control IE：３GPP TS36.331 v8.21.0 5.3.5.4や6.3.4に規定される）に含まれる
・ECGI（E-UTRAN Cell Global Identifier） cellGlobalEUTRA
・Physical Cell ID physCellIdや、
・CSG（Closed Subscriber Group） ID
等の情報ビットのうちの予め定められた上／下何ケタかのビットをＭＥＣサービスが提供できる場合に１／０にすることなどができる。

　端末（ＵＥ）は、上記の通知で、端末が在圏する基地局がＭＥＣサービスをサポートする／しないことがわかったときに、端末の表示画面にポップアップ等の表示する、あるいは、ネットワークに対して、ＭＥＣサービスを提供する端末を判断する情報を通知する、構成としてもよい。

　端末（ＵＥ）からネットワークへの情報の通知は、ＭＥＣサービスの利用可の場合のみ、あるいは、ＭＥＣサービスの利用可否の否の場合のみ、などとしてもよい。

　ＭＭＥが、ＭＥＣサービス利用可の端末については、ＰＤＮ　ＣｏｎｎｅｃｔｉｏｎやＥＰＳベアラの設定の際に、ＭＥＣサーバの位置するＰＤＮやＡＰＮに変更することで、ＭＥＣサーバと端末の間にコネクションやＥＰＳベアラを設定するようにしてもよい。この場合、基地局でのコネクション設定手段は不要となる。ただし、ＰＤＮやＡＰＮを、ＭＥＣサーバ用に割り振ることが事前に必要である。ＭＭＥは、この情報（ＰＤＮやＡＰＮの割り当て情報）を記憶しておき、通常のＰＤＮ／ＡＰＮとＭＥＣ用のＰＤＮ／ＡＰＮの対応関係も記憶しておくようにしてもよい。

　受信した情報から、ＭＥＣサービスを利用させると判断したユーザを、ネットワークノード近傍に、設置／一体化されたＭＥＣサーバと、端末との間でコネクションを設定する。ＳＤＮ、ＮＦＶなどにより、実現できるはずであるが、どうコネクションを設定するかの手段は問わない。基地局の傍などにあるＭＥＣか、インターネットの先かを選択するものである。

　無線線通信システムは、ＬＴＥを例とするが、Ｗ－ＣＤＭＡ(Wideband Code Division Multiple Access)や５Ｇ（Fifth Generation）等であってもよい。その際、本願の実施形態で示されるシグナルやＩＥ等は、等価なものに置き換えてもよい。

　端末１０から基地局２０へのRRC Connection Setup CompleteメッセージでＭＥＣサービスを提供することの判断に用いる情報が、ネットワークノードに通知されるようにしてもよい。

＜ＭＥＣサービスを提供する端末を判断する情報を転送するメッセージの設定例＞
　上記したように、本実施形態では、ＭＥＣサービスを提供することの判断に用いる情報を、例えば以下のメッセージに格納してネットワークに送信する（ただし、以下に制限されない）。

１．RRC connection establishment：　
　・RRC Connection Request　
　・RRC Connection Setup Complete
２．RRC Connection Reconfiguration Complete：
３．UE capability Information：
４．その他、「ＭＥＣサービスを提供する端末を判断する情報を」を端末（ＵＥ）から基地局（ｅＮｏｄｅＢ）へ送信するためのＲＲＣメッセージが規定されてもよい。

　特に制限されるものではないが、ＭＥＣサービスを提供することの判断に用いる情報として、例えば次の少なくともいずれかを含むようにしてもよい（IEはInformation Element）。

・端末がMECサービスを希望/要求すること⇒　mecServiceRequest-IE、
・端末がMECサービスを希望/要求しないこと⇒mecNoServiceRequest-IE、
・端末が所定のエリア（在圏セル）から移動しないこと⇒mecNoMobility-IE。

　図１２を参照すると、端末（ＵＥ）から送信されたRRC Connection Setup Completeメッセージ（Ｓ５０３）にて、上記情報を受信した基地局（ｅＮｏｄｅＢ）は、ＭＥＣサービスのための構成情報（Configuration）を、端末（ＵＥ）へ送信するようにしてもよい。

　端末（ＵＥ）からE-UTRANネットワークノード（基地局）へ送信されるRRC Connection Requestメッセージ（Ｓ５０１）のEstablishment Cause（接続要求信号(RRC Connection Request)を発信した原因を示す情報要素）内の“MEC Service”が「MECサービスを希望／要求すること」を示す情報を設定するようにしてもよい。

　ＭＥＣサービス有の場合、例えば3GPP TS　36.331 5.3.3.3にしたがって、RRC Connection Requestは、以下のように定義される（[…]は省略箇所を表している）。

RRCConnectionRequest-r8-IEs ::=SEQUENCE {
ue-Identity 　InitialUE-Identity,
establishmentCause 　　　　EstablishmentCause,
spare　　　　　　BIT STRING (SIZE (1))
[…]
EstablishmentCause ::=　　　ENUMERATED {
　　　　　　　　　　　emergency, highPriorityAccess, mt-Access, mo-Signalling,
　　　　　　　　　　　mo-Data, delayTolerantAccess-v1020, MEC-Service}
}

　例えばＭＥＣサービス要求が有の場合、３GPP TS 36.331 5.3.3.4にしたがって、RRC Connection Setupを受信した端末（ＵＥ）でのRRC Connection Setup Completeメッセージ（Ｓ５０３）の設定を、例えば以下のように定義してもよい。

　RRC Connection Setup Completeメッセージの内容を、以下のようにセットする。

　上位層が、MECサービス要求（MEC Service Request）を備えていれば、上位層で提供されるmecServiceRequestを含める。

RRCConnectionSetupComplete message
[…]
RRCConnectionSetupComplete-vXXYY-IEs ::= SEQUENCE {
　　　　　　　mecServiceRequest-rXX　ENUMERATED {true}　　　　　　　
}　　　　　　　　　　　　OPTIONAL,

　また、図１３を参照すると、E-UTRANネットワークノード（基地局）から端末（ＵＥ）へのRRC Connection Reconfigurationメッセージ（Ｓ６０１）が、モビリティ制御情報（mobilityControlInformation）を含み／含まず、端末がこのメッセージに含まれる構成に準拠（互換）する場合、端末（ＵＥ）は、RRC Connection Reconfiguration Completeメッセージ（Ｓ６０２）のコンテンツを、以下のように設定するようにしてもよい。

　端末（ＵＥ）が、ＭＥＣサービス情報を有する場合、RRC Connection Reconfiguration Completeメッセージに、mecServiceRequestを含める。なお、RRC Connection Reconfiguration Completeメッセージは、RRC Connection Reconfigurationの成功完了を確認するために用いられる。

　例えばＭＥＣサービス要求が有の場合、３GPP TS 36.331 5.3.5.3にしたがって、RRC Connection Reconfigurationメッセージを受信した端末（UE）のRRC Connection Reconfiguration Completeメッセージの設定は、例えば以下のように定義してもよい。

　RRC Connection Reconfigurationメッセージが mobilityControlInformationを含む/含まず、端末（ＵＥ）が当該メッセージの構成に準拠する場合、RRC Connection Reconfiguration Completeメッセージを以下のようにセットしてもよい。

　端末がＭＥＣサービス情報を有する場合、mecServiceRequestを含める。
RRCConnectionReconfigurationComplete message
[…]
RRCConnectionSetupComplete-vXXYY-IEs ::= SEQUENCE {
　mecServiceRequest-rXX　　　ENUMERATED {true}　　　　　　　OPTIONAL,
　nonCriticalExtension　　　　SEQUENCE {}　　　　　OPTIONAL
}

　図１４を参照すると、端末（ＵＥ）からＥ－ＵＴＲＡＮネットワークノード（基地局）に送信される端末能力情報（UE capability information）（Ｓ７０２）に、ＭＥＣサービスを提供することの判断に用いる情報を設定して送信するようにしてもよい。端末能力情報（UE capability information）は、基地局（ｅＮｏｄｅＢ）から端末に送信された端末能力問い合わせ（UE capability Enquiry）（Ｓ７０１）に応答して送信する。

　ＭＥＣサービスを提供することの判断に用いる情報として、端末能力情報（UE capability information）内の“UE-EUTRA-Capability”内に、ＵＥカテゴリ（“UE Category”）とＭＥＣパラメータ（“MEC parameters”）を含めて送信するようにしてもよい。UE Categoryは、ＭＥＣサービスを利用可能な端末であることを表す。MEC parametersは、ＭＥＣサービスを利用可能な端末内で使用可能なＭＥＣのパラメータを示す。ＭＥＣサービス要求が有の場合、３GPP TS　36.331 5.6.3.3にしたがって、端末能力問い合わせ（UE capability Enquiry）を受信した端末（ＵＥ）の端末能力情報（UE capability information）の設定は、例えば以下のように定義してもよい。

UE-EUTRA-Capability information element
[…]
UE-EUTRA-Capability-vXXYY-IEs ::=　　　　SEQUENCE {
ue-Category-vXXYY　　　　　INTEGER　　　　　　OPTIONAL,
mec-Parameters　　　　　　MEC-Parameters
nonCriticalExtension　　　　SEQUENCE {}　　　OPTIONAL
}

　上記したいずれの実施形態においても、端末側でＭＥＣサービスの提供を選択可能としている。この結果、例えば、ＭＥＣサービスを継続的に受けることができる端末に対して、ＭＥＣサービスを提供することで、顧客満足の低下を回避又は低減可能としている。

　上記した各実施形態は例えば以下のように付記される（ただし、以下に制限されない）。

(付記１）　　　　
　ＭＥＣ（Mobile Edge Computing）サービスの提供を受けるか否かの判断に用いる情報の入力を受け付けるユーザインタフェースと、
　ネットワークノードでＭＥＣサービスを提供することの判断に用いる情報をネットワークに通知する通知部と、
　を有する端末。

(付記２）　　　　
　前記ユーザインタフェースで情報の入力を受け付けるための画面を、
　ＭＥＣサービスの対象のアプリケーションの動作時、
　前記端末の電源オン時、
　前記端末が新たなセルに在圏しているとき、
　前記端末が位置登録エリアを移動した場合、
　前記端末が位置登録更新要求を上げるとき、
　前記端末がパケットデータ網との間のコネクションの確立やコア網のベアラが確立された時、の少なくともいずれかに表示する、付記１記載の端末。

(付記３）
　前記ユーザインタフェースで情報の入力を受け付けるための画面として、前記端末の利用シーンを選択するための画面を表示し、選択された利用シーンの情報を、前記ＭＥＣサービスの提供を受けるか否かの判断に用いる情報とする、付記１又は２記載の端末。

(付記４）
　前記ユーザインタフェースで情報の入力を受け付けるためのセットアップ画面を備えた、付記１記載の端末。

(付記５）
　前記ＭＥＣサービスの利用、
　前記ＭＥＣサービスを利用するエリア、
　前記ＭＥＣサービスを利用するアクセスポイント名又はアクセスポイントタイプ、
　の少なくとも一つを選択するための画面を表示する、付記４記載の端末。

(付記６）
　前記通知部は、モビリティ管理又はセッション管理プロトコルの予め定められた要求又は応答メッセージに、前記ネットワークノードでＭＥＣサービスの提供を受けるか否かの判断に用いる情報を含めて、前記ネットワークに通知する、付記１乃至５のいずれか一に記載の端末。

(付記７）
　前記端末が前記ネットワーク側からの問い合わせに対して送信する端末能力情報に、前記ネットワークノードでＭＥＣサービスの提供を受けるか否かの判断に用いる情報を含めて送信する、付記１乃至６のいずれか一に記載の端末。

(付記８）
　前記ＭＥＣサービスの提供を受けるか否かの判断に用いる情報が、
　前記端末が、ＭＥＣサービスを希望／要求すること、
　前記端末がＭＥＣサービスを希望／要求しないこと、
　前記端末が所定のエリアから移動しないこと、
　の少なくともいずれかを含む、付記１乃至７のいずれか一に記載の端末。

(付記９）
　前記ネットワーク側からＭＥＣサービス提供可である旨の通知を受信する付記１乃至８のいずれか一に記載の端末。

(付記１０）
　ＭＥＣサービスを提供することの判断に用いる情報を端末から受信する受信部と、
　前記受信した情報から、ＭＥＣサービスを提供する端末を判断する判断部と、
　前記ＭＥＣサービスを提供する端末のコネクションを、ＭＥＣサーバとの間で設定するコネクション設定部と、
　を有するネットワークノード。

(付記１１）
　前記端末は、モビリティ管理又はセッション管理プロトコルの予め定められた要求又は応答メッセージに、ネットワークノードでＭＥＣサービスを提供することの判断に用いる情報を含めて、前記ネットワークノードに通知し、
　前記受信部は、前記要求又は応答メッセージから、前記ＭＥＣサービスを提供することの判断に用いる情報を取得する、付記１０記載のネットワークノード。

(付記１２）
　前記端末は、前記ネットワークを介してパケットデータネットワークのサーバに、前記ＭＥＣサービスを提供することの判断に用いる情報を通知し、
　前記受信部は、前記サーバから前記ネットワークノードに通知された、前記ＭＥＣサービスを提供することの判断に用いる情報を受信する、付記１１記載のネットワークノード。

(付記１３）
　前記受信部は、前記端末から送信された端末能力情報を受信し、前記端末能力情報に含まれる、前記ＭＥＣサービスを提供することの判断に用いる情報を取得する、付記１０乃至１２のいずれか一に記載のネットワークノード。

(付記１４）
　前記ＭＥＣサービスを提供することの判断に用いる情報が、
　前記端末がＭＥＣサービスを希望／要求すること、
　前記端末がＭＥＣサービスを希望／要求しないこと、
　前記端末が所定のエリアから移動しないこと、
　の少なくともいずれかを含む、付記１０乃至１３のいずれか一に記載のネットワークノード。

(付記１５）
　端末と、ネットワークノードと、を備えたネットワークシステムであって、
　前記端末は、ＭＥＣサービスの提供を受けるか否かの判断に用いる情報の入力を受け付け、前記情報を前記ネットワークに通知し、
　前記ネットワークノードは、前記ＭＥＣサービスの提供を受けるか否かの判断に用いる情報を前記端末から受信し、前記受信した情報から、ＭＥＣサービスを提供する端末を判断し、
　前記ＭＥＣサービスを提供する端末のコネクションを、ＭＥＣサーバとの間で設定する、ネットワークシステム。

(付記１６）
　端末と、ネットワークノードと、を備えたネットワークシステムにおける通信制御方法であって、
　前記端末は、
　ＭＥＣサービスの提供を受けるか否かの判断に用いる情報の入力を受け付け、ネットワークノードでＭＥＣサービスを提供することの判断に用いる情報をネットワークに通知し、
　前記ネットワークノードは、
　前記ＭＥＣサービスの提供を受けるか否かの判断に用いる情報を前記端末から受信し、前記受信した情報から、ＭＥＣサービスを提供する端末を判断し、
　前記ＭＥＣサービスを提供する端末のコネクションを、ＭＥＣサーバとの間で設定する、通信制御方法。

(付記１７）
　端末と、ネットワークノードと、を備えたネットワークシステムにおける前記端末の通信制御方法であって、
　ＭＥＣサービスの提供を受けるか否かの判断に用いる情報の入力を受け付け、
　前記ネットワークノードでＭＥＣサービスを提供することの判断に用いる情報をネットワークに通知する、端末の通信制御方法。

(付記１８）
　端末と、ネットワークノードと、を備えたネットワークシステムにおける前記ネットワークノードの通信制御方法であって、
　ＭＥＣサービスの提供を受けるか否かの判断に用いる情報を前記端末から受信し、前記受信した情報から、ＭＥＣサービスを提供する端末を判断し、
　前記ＭＥＣサービスを提供する端末のコネクションを、ＭＥＣサーバとの間で設定するネットワークノードの通信制御方法。

(付記１９）
　端末を構成するコンピュータに、
　ＭＥＣサービスの提供を受けるか否かの判断に用いる情報の入力を受け付ける処理と、
　ネットワークノードでＭＥＣサービスを提供することの判断に用いる情報をネットワークに通知する処理と、を実行させるプログラム。

(付記２０）
　ネットワークノードを構成するコンピュータに、
　ＭＥＣサービスの提供を受けるか否かの判断に用いる情報を端末から受信する処理と、
　前記受信した情報から、ＭＥＣサービスを提供する端末を判断する処理と、
　前記ＭＥＣサービスを提供する端末のコネクションを、ＭＥＣサーバとの間で設定する処理と、を実行させるプログラム。

(付記２１）
　ＭＥＣサービスを提供することの判断に用いる情報を端末から受信し、前記受信した情報から、ＭＥＣサービスを提供する端末を判断するネットワークノードに接続されたサーバ装置であって、
　前記ネットワークノードによるコネクションの設定により、前記ＭＥＣサービスを提供する端末に対して、ＭＥＣサービスを提供するサーバ装置。

　なお、上記の特許文献１、非特許文献１、２の各開示を、本書に引用をもって繰り込むものとする。本発明の全開示（請求の範囲を含む）の枠内において、さらにその基本的技術思想に基づいて、実施形態ないし実施例の変更・調整が可能である。また、本発明の請求の範囲の枠内において種々の開示要素（各付記の各要素、各実施例の各要素、各図面の各要素等を含む）の多様な組み合わせ乃至選択が可能である。すなわち、本発明は、請求の範囲を含む全開示、技術的思想にしたがって当業者であればなし得るであろう各種変形、修正を含むことは勿論である。

１０　端末
１１　表示装置（表示画面）
２０、２０Ａ　基地局
２０Ｂ　ＲＮＣ／ＮｏｄｅＢ
２１　ＭＭＥ
２２　ＳＧＳＮ
２３　Ｓ－ＧＷ
２４　Ｐ－ＧＷ
２５　ＨＳＳ
２６　ＰＣＲＦ
２７Ａ　ＬＴＥ無線アクセス収容網
２７Ｂ　３Ｇ無線アクセス収容網
２８　コア網（ＥＰＣ）
２９、２９Ａ、２９Ｂ　ＭＥＣサーバ
３０　ＰＤＮ
３１　サーバ
１０１　アンテナ
１０２　通信モジュール
１０３　通知部
１０４　ユーザインタフェース
１０５　メモリ
１０６　プロセッサ
１０７　制御部
１１１　ポップアップ画面（ウインドウ）
１１２Ａ、１１２Ｂ　メッセージ
１１３　ボタン（はい）
１１４　ボタン（いいえ）
１１５　メニューバー（利用シーン）
１１６　設定画面
１１７　スイッチ
１１８　エリアボタン
１１９　アクセスポイントネーム
１２０　アクセスポイントタイプ
２０１　アンテナ
２０２　通信装置
２０３　ＭＥＣ情報受部
２０４　判断部
２０５　コネクション設定部
２０６　メモリ
２０７－２０９　ネットワークインタフェース
２１０　プロセッサ
１０４１　タッチパネル
１０４２　入出力部
１０４３　アプリケーション
１０４４　セットアップ部
１０３１　モビリティ管理／セッション管理プロトコル処理部
１０３２　アプリケーション

Claims

　ＭＥＣ（Mobile Edge Computing）サービスの提供を受けるか否かの判断に用いる情報の入力を受け付けるユーザインタフェースと、
　ネットワークノードでＭＥＣサービスを提供することの判断に用いる情報をネットワークに通知する通知部と、
　を有する端末。
　前記ユーザインタフェースで情報の入力を受け付けるための画面を、
　ＭＥＣサービスの対象のアプリケーションの動作時、
　前記端末の電源オン時、
　前記端末が新たなセルに在圏しているとき、
　前記端末が位置登録エリアを移動した場合、
　前記端末が位置登録更新要求を上げるとき、
　前記端末がパケットデータ網との間のコネクションの確立やコア網のベアラが確立された時、の少なくともいずれかに表示する、請求項１記載の端末。
　前記ユーザインタフェースで情報の入力を受け付けるための画面として、前記端末の利用シーンを選択するための画面を表示し、選択された利用シーンの情報を、前記ＭＥＣサービスを提供することの判断に用いる情報とする、請求項１又は２記載の端末。
　前記ユーザインタフェースで情報の入力を受け付けるためのセットアップ画面を備えた、請求項１記載の端末。
　前記ＭＥＣサービスの利用、
　前記ＭＥＣサービスを利用するエリア、
　前記ＭＥＣサービスを利用するアクセスポイント名又はアクセスポイントタイプ、
　の少なくとも一つを選択するための画面を表示する、請求項４記載の端末。
　前記通知部は、モビリティ管理又はセッション管理プロトコルの予め定められた要求又は応答メッセージに、前記ネットワークノードでＭＥＣサービスを提供することの判断に用いる情報を含めて、前記ネットワークに通知する、請求項１乃至５のいずれか１項に記載の端末。
　前記端末が前記ネットワーク側からの問い合わせに対して送信する端末能力情報に、前記ネットワークノードでＭＥＣサービスを提供することの判断に用いる情報を含めて送信する、請求項１乃至６のいずれか１項に記載の端末。
　ＭＥＣ（Mobile Edge Computing）サービスを提供することの判断に用いる情報を端末から受信する受信部と、
　前記受信した情報から、ＭＥＣサービスを提供する端末を判断する判断部と、
　前記ＭＥＣサービスを提供する端末のコネクションを、ＭＥＣサーバとの間で設定するコネクション設定部と、
　を有するネットワークノード。
　端末と、ネットワークノードと、を備えたネットワークシステムにおける前記端末の通信制御方法であって、
　ＭＥＣ（Mobile Edge Computing）サービスの提供を受けるか否かの判断に用いる情報の入力を受け付け、
　ネットワークノードでＭＥＣサービスを提供することの判断に用いる情報をネットワークに通知する、端末の通信制御方法。
　端末と、ネットワークノードと、を備えたネットワークシステムにおける前記ネットワークノードの通信制御方法であって、
　前記ネットワークノードは、ＭＥＣサービスを提供することの判断に用いる情報を前記端末から受信し、
　前記受信した情報から、ＭＥＣサービスを提供する端末を判断し、
　前記ＭＥＣサービスを提供する端末のコネクションを、ＭＥＣサーバとの間で設定する、ネットワークノードの通信制御方法。
　端末を構成するコンピュータに、
　ＭＥＣ（Mobile Edge Computing）サービスの提供を受けるか否かの判断に用いる情報の入力を受け付ける処理と、
　ネットワークノードでＭＥＣサービスを提供することの判断に用いる情報をネットワークに通知する処理と、
　を実行させるプログラム。
　ネットワークノードを構成するコンピュータに、
　ＭＥＣサービスを提供することの判断に用いる情報を端末から受信する処理と、
　前記受信した情報から、ＭＥＣサービスを提供する端末を判断する処理と、
　前記ＭＥＣサービスを提供する端末のコネクションを、ＭＥＣサーバとの間で設定する処理と、
　を実行させるプログラム。