(57)【特許請求の範囲】
【請求項１】
無線アクセスネットワークに結合して配置されるエッジサーバであって、
前記無線アクセスネットワークに接続する無線端末に向けたサービス又はアプリケーションに関するエッジ・コンピューティングのためにコンピューティング・リソース及びストレージ・リソースのうち少なくとも１つを提供するよう構成されたエッジ・コンピューティング・プラットフォームと、
前記無線端末を含む複数の無線端末のうち少なくとも１つに対する無線リソース管理のために前記無線アクセスネットワーク内で利用される制御情報を前記無線端末の特性に基づいて決定するよう構成された制御モジュールと、
を備え、
前記制御情報は、遅延要件、スループット要件、プライオリティ要件、及びモビリティ要件のうち少なくとも１つを含む、
エッジサーバ。
【請求項２】
前記無線端末の前記特性は、前記無線端末の端末種別、前記無線端末の通信データ種別、前記無線端末の位置、前記無線端末の移動特性、前記無線端末の通信間隔、及び前記無線端末の通信データ量のうち少なくとも１つを含む、
請求項１に記載のエッジサーバ。
【請求項３】
前記遅延要件は、最大遅延、平均遅延、遅延ジッタ、及び遅延保証に関する優先度、のうち少なくとも１つを指定する、
請求項１又は２に記載のエッジサーバ。
【請求項４】
前記遅延要件は、当該遅延要件が必要とされる期間、スケジュール、又は回数を指定する、
請求項１〜３のいずれか１項に記載のエッジサーバ。
【請求項５】
前記スループット要件は、最低スループット、平均スループット、要求スループット、最小無線帯域、平均無線帯域、及び要求無線帯域、のうち少なくとも１つを指定する、
請求項１〜４のいずれか１項に記載のエッジサーバ。
【請求項６】
前記制御情報は、前記遅延要件を含み、
前記制御モジュールは、前記無線端末が所定の地点の近くにいる場合に、前記無線端末が前記所定の地点から遠く離れている場合に比べて前記無線端末が低遅延で無線通信することを可能とするように前記無線アクセスネットワークに要求するよう構成されている、
請求項１〜５のいずれか１項に記載のエッジサーバ。
【請求項７】
前記制御情報は、前記遅延要件を含み、
前記制御モジュールは、前記無線端末が所定の地点に近づいている場合に、前記無線端末が前記所定の地点から遠ざかっている場合に比べて前記無線端末が低遅延で無線通信することを可能とするように前記無線アクセスネットワークに要求するよう構成されている、
請求項１〜５のいずれか１項に記載のエッジサーバ。
【請求項８】
前記制御情報は、前記遅延要件を含み、
前記制御モジュールは、前記無線端末が高速で移動している場合に、前記無線端末が低速で移動している場合に比べて前記無線端末が低遅延で無線通信することを可能とするように前記無線アクセスネットワークに要求するよう構成されている、
請求項１〜５のいずれか１項に記載のエッジサーバ。
【請求項９】
前記制御情報は、前記スループット要件を含み、
前記制御モジュールは、前記無線端末が結合されているビデオカメラが高解像度である場合に、前記ビデオカメラが低解像度である場合に比べて前記無線端末に高いスループットを与えるように前記無線アクセスネットワークに要求するよう構成されている、
請求項１〜５のいずれか１項に記載のエッジサーバ。
【請求項１０】
前記制御情報は、前記スループット要件を含み、
前記制御モジュールは、前記無線端末が結合されているビデオカメラの撮影状況に応じて前記無線端末のための前記スループット要件を決定するよう構成されている、
請求項１〜５のいずれか１項に記載のエッジサーバ。
【請求項１１】
前記制御情報は、前記スループット要件を含み、
前記制御モジュールは、前記無線端末が結合されているビデオカメラの設置場所に応じて前記無線端末のための前記スループット要件を決定するよう構成されている、
請求項１〜５のいずれか１項に記載のエッジサーバ。
【請求項１２】
前記制御情報は、前記スループット要件を含み、
前記制御モジュールは、前記無線端末が結合されているビデオカメラの設置場所に応じて前記無線端末のための前記スループット要件を決定するよう構成されている、
請求項１〜５のいずれか１項に記載のエッジサーバ。
【請求項１３】
前記制御情報は、前記スループット要件を含み、
前記制御モジュールは、イベントが行われる会場内での前記無線端末の位置に応じて前記無線端末のための前記スループット要件を決定するよう構成されている、
請求項１〜５のいずれか１項に記載のエッジサーバ。
【請求項１４】
無線アクセスネットワークに結合して配置され、前記無線アクセスネットワークに接続する無線端末に向けたサービス又はアプリケーションに関するエッジ・コンピューティングのためにコンピューティング・リソース及びストレージ・リソースのうち少なくとも１つを提供するエッジサーバにおける方法であって、
前記無線端末を含む複数の無線端末のうち少なくとも１つに対する無線リソース管理のために前記無線アクセスネットワーク内で利用される制御情報を前記無線端末の特性に基づいて決定すること、
を備え、
前記制御情報は、遅延要件、スループット要件、プライオリティ要件、及びモビリティ要件のうち少なくとも１つを含む、
方法。
【請求項１５】
前記無線端末の前記特性は、前記無線端末の端末種別、前記無線端末の通信データ種別、前記無線端末の位置、前記無線端末の移動特性、前記無線端末の通信間隔、及び前記無線端末の通信データ量のうち少なくとも１つを含む、
請求項１４に記載の方法。
【請求項１６】
前記制御情報は、前記遅延要件を含み、
前記無線端末が所定の地点の近くにいる場合に、前記無線端末が前記所定の地点から遠く離れている場合に比べて前記無線端末が低遅延で無線通信することを可能とするように前記無線アクセスネットワークに要求することをさらに備える、
請求項１４又は１５に記載の方法。
【請求項１７】
前記制御情報は、前記遅延要件を含み、
前記無線端末が所定の地点に近づいている場合に、前記無線端末が前記所定の地点から遠ざかっている場合に比べて前記無線端末が低遅延で無線通信することを可能とするように前記無線アクセスネットワークに要求することをさらに備える、
請求項１４又は１５に記載の方法。
【請求項１８】
前記制御情報は、前記遅延要件を含み、
前記無線端末が高速で移動している場合に、前記無線端末が低速で移動している場合に比べて前記無線端末が低遅延で無線通信することを可能とするように前記無線アクセスネットワークに要求することをさらに備える、
請求項１４又は１５に記載の方法。
【請求項１９】
前記制御情報は、前記スループット要件を含み、
前記無線端末が結合されているビデオカメラが高解像度である場合に、前記ビデオカメラが低解像度である場合に比べて前記無線端末に高いスループットを与えるように前記無線アクセスネットワークに要求することをさらに備える、
請求項１４又は１５に記載の方法。
【請求項２０】
前記制御情報は、前記スループット要件を含み、
前記決定することは、前記無線端末が結合されているビデオカメラの撮影状況に応じて前記無線端末のための前記スループット要件を決定することを含む、
請求項１４又は１５に記載の方法。
【請求項２１】
前記制御情報は、前記スループット要件を含み、
前記決定することは、前記無線端末が結合されているビデオカメラの設置場所に応じて前記無線端末のための前記スループット要件を決定することを含む、
請求項１４又は１５に記載の方法。
【請求項２２】
前記制御情報は、前記スループット要件を含み、
前記決定することは、前記無線端末が結合されているビデオカメラの設置場所に応じて前記無線端末のための前記スループット要件を決定することを含む、
請求項１４又は１５に記載の方法。
【請求項２３】
前記制御情報は、前記スループット要件を含み、
前記決定することは、イベントが行われる会場内での前記無線端末の位置に応じて前記無線端末のための前記スループット要件を決定することを含む、
請求項１４又は１５に記載の方法。
【請求項２４】
無線アクセスネットワークに結合して配置され、前記無線アクセスネットワークに接続する無線端末に向けたサービス又はアプリケーションに関するエッジ・コンピューティングのためにコンピューティング・リソース及びストレージ・リソースのうち少なくとも１つを提供するエッジサーバにおける方法をコンピュータに行わせるためのプログラムであって、
前記方法は、前記無線端末を含む複数の無線端末のうち少なくとも１つに対する無線リソース管理のために前記無線アクセスネットワーク内で利用される制御情報を前記無線端末の特性に基づいて決定することを含み、
前記制御情報は、遅延要件、スループット要件、プライオリティ要件、及びモビリティ要件のうち少なくとも１つを含む、
プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本開示は、モバイル通信ネットワークに関し、特にモバイル・エッジ・コンピューティングのための装置及び方法に関する。
【背景技術】
【０００２】
European Telecommunications Standards Institute（ETSI）は、Mobile Edge Computing（MEC）の標準化を開始している（非特許文献１を参照）。MECは、アプリケーション開発者（application developers）及びコンテンツプロバイダに対して、モバイル加入者（mobile subscribers）に近接した無線アクセスネットワーク（Radio Access Network (RAN)）内でのクラウド・コンピューティング能力（capabilities）及びinformation technology（IT）サービス環境を提供する。この環境は、超低遅延（ultra-low latency）及び高帯域幅（high bandwidth）に加えて、アプリケーション及びサービスによって活用される（leveraged）ことができる無線ネットワーク情報（加入者位置、セル負荷など）への直接アクセスを提供する。
【０００３】
MECサーバは、RANノードと統合して配置される。具体的には、MECサーバは、Long Term Evolution（LTE）基地局（eNodeB）サイト、3G Radio Network Controller（RNC）サイト、又はmulti-technologyセル集約（cell aggregation）サイトに配置されることができる。multi-technologyセル集約サイトは、多数の局所的なmulti-technologyアクセスポイントを制御するために、企業の屋内（indoors within an enterprise）（e.g., 病院、大企業の本社）に置かれてもよいし、公共の建物又はアリーナ（e.g., ショッピングモール、スタジアム）の屋内／屋外に置かれてもよい。
【０００４】
MECサーバは、コンピューティング・リソース、ストレージ容量（capacity）、接続性（connectivity）、並びにユーザトラフィック及び無線ネットワーク情報へのアクセスを提供する。より具体的には、MECサーバは、Infrastructure as a Service（IaaS）又はPlatform as a Service（PaaS）機能（facility）を提供することによって、アプリケーションのためのホスティング環境を提供する。
【０００５】
非特許文献１は、MECのユースケースのいくつかの例を示している。あるユースケース（Active Device Location Tracking）では、MECサーバ上にホストされている位置情報（geo-location）アプリケーションは、eNodeB／RNCから受信した無線ネットワークの計測結果を用いて無線端末の位置をトラッキングし、無線端末の位置情報をセントラル・サーバに送信する。これにより、Global Positioning System（GPS）を用いずに、位置に基づくサービスを提供できる。
【０００６】
あるユースケース（Intelligent Video Analytics）では、MECサーバ上にホストされているビデオ解析アプリケーションは、ライブ・ビデオ・ストリームを無線端末から受信し、トリガーイベント（e.g., 物体の移動、放置された（abandoned）荷物、行方不明の物体など）を検出するためにライブ・ビデオ・ストリームを解析し、データベース検索のために低帯域幅のビデオメタデータをセントラル・サーバに送信する。
【０００７】
あるユースケース（Augmented Reality Content Delivery）では、MECサーバ上にホストされているアプリケーションは、無線端末の内蔵カメラで撮影された映像中の物体を解析し、MECサーバのARデータキャッシュに格納されているARコンテンツを無線端末に送信する。このソリューションは、ラウンドトリップ時間を最小化でき、Quality of Experience（QoE）の向上に寄与できる。
【０００８】
あるユースケース（RAN-aware & Application-aware Content Optimization）では、MECサーバ上にホストされているアプリケーションは、セル又は無線端末の無線情報（e.g., セル負荷、リンク品質）をeNodeB／RNCから受信し、この情報をコンテツ最適化のためにセントラル・サーバ（コンテンツ・オプティマイザ）に送信する。このような動的なコンテンツ最適化は、ビデオの失速（stalling）の低減、及び再生開始までの時間（time-to-start）の低減といったビデオ品質の改善を通じて、ビデオ配信を促進できる。
【先行技術文献】
【非特許文献】
【０００９】
【非特許文献１】“Mobile-edge Computing Introductory Technical White Paper”, the European Telecommunications Standards Institute, September 2014, [retrieved on 2015-06-24], Retrieved from the Internet: <URL: https://portal.etsi.org/Portals/0/TBpages/MEC/Docs/Mobile-edge_Computing_-_Introductory_Technical_White_Paper_V1%2018-09-14.pdf>
【発明の概要】
【発明が解決しようとする課題】
【００１０】
本件の発明者等は、MECに関するいくつかの課題、特に遅延（レイテンシ）に関する課題を見出した。上述したように、MECは、無線端末に向けたアプリケーション及びサービスの低遅延化に寄与し、これによりユーザのQoEの向上に寄与することが期待される。しかしながら、例えば、多くの無線端末がRANに接続している状況では、RANは、MECを利用する又はMECに関係する無線端末が必要としている遅延要件を満足できないおそれがある。
【００１１】
この問題を解決するためには、RAN内での無線リソース管理（Radio Resource Management: RRM）又はスケジューリング等に関して、MECを利用する又はMECに関係する無線端末に対する特別な配慮をMECサーバからRANノード（eNodeB／RNC）に求めることができると有効であるかもしれない。しかしながら、非特許文献１は、MECサーバがRANノード（eNodeB／RNC）から得られる無線ネットワーク情報（e.g., 加入者位置、セル負荷、リンク品質など）を活用することを記載しているが、MECサーバがRANノード（eNodeB／RNC）に対してアクセス層の制御を依頼することについて記載していない。
【００１２】
本明細書に開示される実施形態が達成しようとする目的の１つは、モバイル・エッジ・コンピューティング環境に適した無線アクセスネットワークでの制御を実現することに寄与する装置、方法、及びプログラムを提供することである。
【課題を解決するための手段】
【００１３】
第１の態様では、無線アクセスネットワークに結合して配置されるエッジサーバは、エッジ・コンピューティング・プラットフォーム及び制御モジュールを含む。前記エッジ・コンピューティング・プラットフォームは、前記無線アクセスネットワークに接続する無線端末に向けたサービス又はアプリケーションに関するエッジ・コンピューティングのためにコンピューティング・リソース及びストレージ・リソースのうち少なくとも１つを提供するよう構成されている。前記制御モジュールは、前記無線端末を含む複数の無線端末のうち少なくとも１つに対する無線リソース管理のために前記無線アクセスネットワーク内で利用される制御情報を前記無線端末の特性に基づいて決定するよう構成されている。
【００１４】
第２の態様では、無線アクセスネットワークに結合して配置されるエッジサーバにおける方法は、複数の無線端末のうち少なくとも１つに対する無線リソース管理のために前記無線アクセスネットワーク内で利用される制御情報を無線端末の特性に基づいて決定することを含む。
【００１５】
第３の態様では、プログラムは、コンピュータに読み込まれた場合に、上述の第２に係る方法をコンピュータに行わせるための命令群（ソフトウェアコード）を含む。
【発明の効果】
【００１６】
上述の態様によれば、モバイル・エッジ・コンピューティング環境に適した無線アクセスネットワークでの制御を実現することに寄与する装置、方法、及びプログラムを提供できる。
【図面の簡単な説明】
【００１７】
【図１】いくつかの実施形態に係るモバイル通信ネットワークの構成例を示す図である。
【図２】第１の実施形態に係るeNodeB及びMECサーバの動作の一例を示すシーケンス図である。
【図３】第１の実施形態に係るMECサーバの動作の一例を示すフローチャートである。
【図４】第１の実施形態に係るeNodeBの動作の一例を示すフローチャートである。
【図５】第１の実施形態に係るeNodeBの動作の一例を示すシーケンス図である。
【図６】第２の実施形態に係るeNodeB、PCRF、及びMECサーバの動作の一例を示すシーケンス図である。
【図７】いくつかの実施形態に係るMECサーバの構成例を示す図である。
【図８】いくつかの実施形態に係るeNodeBの構成例を示す図である。
【図９】いくつかの実施形態に係るPCRFの構成例を示す図である。
【発明を実施するための形態】
【００１８】
以下では、具体的な実施形態について、図面を参照しながら詳細に説明する。各図面において、同一又は対応する要素には同一の符号が付されており、説明の明確化のため、必要に応じて重複説明は省略される。
【００１９】
以下に示される複数の実施形態は、LTE及びLTE-Advancedを主な対象として説明される。しかしながら、これらの実施形態は、LTE及びLTE-Advancedに限定されるものではなく、他のモバイル通信ネットワーク又はシステム、例えば3rd Generation Partnership Project (3GPP) Universal Mobile Telecommunications System（UMTS）、3GPP2 CDMA2000システム、Global System for Mobile communications（GSM（登録商標））/ General packet radio service（GPRS）システム、WiMAXシステム、又はモバイルWiMAXシステム等に適用されてもよい。
【００２０】
＜第１の実施形態＞
図１は、本実施形態を含むいくつかの実施形態に係るモバイル通信ネットワークの構成例を示している。図１の例では、モバイル通信ネットワークは、RAN３（Evolved UMTS Terrestrial Radio Access Network（E-UTRAN））及びコアネットワーク４（Evolved Packet Core（EPC））を含む。RAN３は、eNodeB２を含む。eNodeB２は、RAN３に配置され、RAN３に接続する複数の無線端末１（User Equipment（UE））と通信し、これらUEs１のための無線リソース管理を提供するよう構成されている。無線リソース管理は、例えば、各UE１との無線接続（e.g., Radio Resource Control（RRC）コネクション）の確立・修正・解放、各UE１への無線リソースのスケジューリング、各UE１に対する個別スケジューリング要求（Dedicated Scheduling Request（D-SR））リソースの設定、及び各UE１のハンドオーバの制御を含む。
【００２１】
なお、図１に示されたeNodeB２は、Centralized Radio Access Network（C-RAN）アーキテクチャで使用されるBaseband Unit（BBU）であってもよい。言い換えると、図１に示されたeNodeB２は、１又は複数のRemote Radio Head（RRH）に接続されるRANノードであってもよい。いくつかの実装において、BBUとしてのeNodeB２は、EPC４に接続されるとともに、無線リソース管理を含むコントロール・プレーン処理とユーザ・プレーンのデジタルベースバンド信号処理を担当する。一方、RRUは、アナログRadio Frequency（RF）信号処理（e.g., 周波数変換および信号増幅）を担当する。なお、C-RANは、Cloud RANと呼ばれることもある。また、BBUは、Radio Equipment Controller（REC）又はData Unit（DU）と呼ばれることもある。RRHは、Radio Equipment（RE）、Radio Unit（RU）、又はRemote Radio Unit（RRU）と呼ばれることもある。
【００２２】
コアネットワーク４は、主にモバイル通信サービスを提供するオペレータによって管理されるネットワークである。コアネットワーク４は、複数のユーザープレーン・エンティティ（e.g., Serving Gateway (S-GW)及びPacket Data Network Gateway (P-GW)）、及び複数のコントロールプレーン・エンティティ（e.g., Mobility Management Entity（MME）及びHome Subscriber Server（HSS）、Policy and Charging Rule Function（PCRF））を含む。複数のユーザープレーン・エンティティは、RAN３と外部ネットワーク（Packet Data Network (PDN)）との間でUEs１のユーザデータを中継する。複数のコントロールプレーン・エンティティは、UEs１のモビリティ管理、セッション管理（ベアラ管理）、加入者情報管理、及び課金管理を含む様々な制御を行う。
【００２３】
Mobile Edge Computing（MEC）サーバ５は、eNodeB２と直接的に（つまり、コアネットワーク４を介さずに）通信できるように、RAN３内に配置される。いくつかの実装において、MECサーバ５は、eNodeB２と物理的に統合されてもよい。いくつかの実装において、MECサーバ５は、eNodeB２と同じ建物（サイト）に配置され、eNodeB２と通信できるように当該サイト内のLocal Area Network（LAN）に接続されてもよい。
【００２４】
MECサーバ５は、１又は複数のUE１に向けたサービス又はアプリケーションに関するエッジ・コンピューティングのためにコンピューティング・リソース及びストレージ・リソース（ストレージ容量（capacity））のうち少なくとも１つを提供するよう構成されている。いくつかの実装において、MECサーバ５は、IaaS又はPaaS機能（facility）を提供することによって、アプリケーションのためのホスティング環境を提供してもよい。
【００２５】
MECサーバ５は、さらに、コアネットワーク４の一部の機能を有してもよい。例えば、MECサーバ５は、S-GWまたはS-GW/P-GWの機能を有し、MECを利用するUE１のユーザデータを直接MECサーバ５で終端してもよい。
【００２６】
背景技術で説明されたMECのユースケースのいくつかの例と同様に、MECサーバ５は、アプリケーション又はサービスを提供するために１又は複数のセントラル・サーバ６と通信してもよい。MECサーバ５とセントラル・サーバ６の間の通信は、コアネットワーク４を経由して行われてもよいし、コアネットワーク４を経由しない通信回線又はネットワーク上で行われてもよい。
【００２７】
続いて以下では、本実施形態に係るeNodeB２による動的な無線リソース管理について説明する。図２は、eNodeB２及びMECサーバ５の動作の一例（処理２００）を示すシーケンス図である。ステップ２０１では、MECサーバ５は、MEC制御情報を明示的又は暗示的に示すメッセージをeNodeB２に送信する。当該MEC制御情報は、MECサーバ５上にホストされているアプリケーション（サービス）を利用する又は当該アプリケーションに関係するUE１の特性から導かれる。いくつかの実装において、MECサーバ５は、UE１の特性からMEC制御情報を決定してもよい。
【００２８】
当該MEC制御情報を求めるために参照されるUE１の特性は、例えば、UE１の端末種別（e.g., カーナビゲーションシステム、スマートメータ）、UE１の端末カテゴリ（e.g., Access Class、UE category）、UE１の通信データ種別（e.g., ビデオストリーム、Hypertext Transfer Protocol（HTTP））、及びUE１が利用するサービス又はアプリケーションの種別、のうち少なくとも１つを含む。さらに又はこれに代えて、当該UE１の特性は、UE１の位置関連情報（e.g., 交差点付近、歩道上、自宅）、UE１の移動特性（e.g., 高速、低速、移動方向）、及びUE１の通信特性（e.g., 無線品質、スループット）のうち少なくとも１つを含んでもよい。さらに又はこれに代えて、当該UE１の特性は、UE１の通信間隔及び通信データ量のうち少なくとも１つを含んでもよい。なお、通信間隔または通信データ量は、アプリケーション毎またはサービス毎でもよいし、当該UE１が実行中の複数または全てのアプリケーションまたはサービス単位でもよい。さらに又はこれに代えて、当該UE１の特性は、UE１の無線リンク品質（e.g., Reference Signal Received Power（RSRP）、Reference Signal Received Quality（RSRQ））を含んでもよい。
【００２９】
UE１の特性から導かれるMEC制御情報は、例えば、以下の少なくともいずれか、または任意の組み合わせでもよい。
・遅延要件
・スループット要件
・プライオリティ要件
・モビリティ要件
【００３０】
遅延要件は、最大遅延、平均遅延、遅延ジッタ、及び遅延保証に関する優先度、のうち少なくとも１つを指定してもよい。当該遅延要件は、遅延要件が必要とされる期間、スケジュール、又は回数を指定してもよい。さらに、ここで言う遅延は、例えば、UE１がデータをRAN３に送信完了するまでの遅延、UE１のデータが当該データの送信先（e.g., サーバ、他のUE１）に到達するまでの遅延、RAN３がデータをUE１に送信完了するまでの遅延、のいずれかでもよい。
【００３１】
スループット要件は、最低スループット（保証すべき最小スループット）、平均スループット、要求スループット（十分なスループット）、のうち少なくとも１つを指定してもよい。
【００３２】
プライオリティ要件は、MECを利用するUE１間の相対的な優先度または絶対的な優先度、或いは、他のMECを利用していないUE１に対するMECを利用するUE１の相対的な優先度または絶対的な優先度、のうち少なくとも１つを指定してもよい。
【００３３】
モビリティ要件は、モビリティを保証するか否か、モビリティを保証する移動速度の値またはレベル（e.g. high, medium (or normal), low）、のうちの少なくとも１つを指定してもよい。
【００３４】
MEC制御情報は、当該MEC制御情報（e.g., 遅延要件）が適用されるべきデータフローを特定するために、データパターン、アプリケーション又はサービスの種別を指定してもよい。当該MEC制御情報は、それが適用されるべきUE１を指定するために、セル若しくはセルグループ、周波数若しくは周波数グループ、UE若しくはUEグループ、又はこれらの任意の組合せを指定してもよい。
【００３５】
さらに又はこれに代えて、当該MEC制御情報（e.g., 遅延要件）は、特定のUEグループに属する複数のUEs１のうち所定の要件（e.g., 遅延）が保証されるべきUE数又は割合を指定してもよい。具体例を示すと、遅延要件は、１０台のUE１のうち３台について所定の遅延が保証されることを示してもよい。なお、当該UE１それぞれに対する遅延要件は同じでもよいし、異なってもよい。
【００３６】
MEC制御情報は、EPSベアラに関するQuality of Service（QoS）ポリシ、QoSルール、又はPolicy and Charging Control（PCC）ルールを含んでもよい。MEC制御情報は、例えば、Quality Class Indicator（QCI）及び Allocation Retention Priority（ARP)を示してもよい。EPSベアラに関するMEC制御情報（QoSポリシ又はQoSルール）は、eNodeB２において、E-UTRAN Radio Access Bearer (E-RAB) QoS及びradio bearer QoSに対応付けられてもよい。
【００３７】
以上の説明から理解されるように、本実施形態では、MECサーバ５は、MECを利用する又はMECに関係するUE１の特性から導かれるMEC制御情報（e.g., 遅延要件）をRAN３において複数のUEs１の無線リソース管理を担うeNodeB２に通知するよう構成されている。従って、eNodeB２は、MECサーバ５から受け取ったMEC制御情報に基づいて、MECを利用する又はMECに関係するUE１又は他のUE１のための無線リソース管理を行うことができる。これにより、eNodeB２は、MECサーバ５により提供されるエッジ・コンピューティングを利用する（又は関係する）UE１の特性から導かれるMEC制御情報をRAN３内の無線リソース管理において考慮することができる。
【００３８】
続いて以下では、eNodeB２及びMECサーバ５の動作についてより詳しく説明する。図３は、MECサーバ５の動作の一例（処理３００）を示すフローチャートである。ブロック３０１では、MECサーバ５は、MECを利用する(又は関係する）UE１の特性からMEC制御情報を決定する。ブロック３０２では、MECサーバ５は、決定したMEC制御情報を明示的又は暗示的に示すメッセージをeNodeB２に送信する。
【００３９】
図４は、eNodeB２の動作の一例（処理４００）を示すフローチャートである。ブロック４０１では、eNodeB２は、MEC制御情報を明示的又は暗示的に示すメッセージをMECサーバ５から受信する。ブロック４０２では、eNodeB２は、MECサーバ５から受信したMEC制御情報に基づいて、少なくとも1つのUE１に対する無線リソース管理を行う。
【００４０】
続いて、MECサーバ５からのMEC制御情報を考慮する無線リソース管理のいくつかの例を説明する。MECサーバ５からのMEC制御情報を考慮した無線リソース管理は、少なくとも１つのUE１との無線接続（e.g., RRCコネクション）の解放、少なくとも１つのUE１への無線リソースのスケジューリング、少なくとも１つのUE１に対するD-SRリソースの設定、及び少なくとも１つのUE１のハンドオーバ、のうち少なくとも１つを含んでもよい。
【００４１】
いくつかの実装において、eNodeB２は、MECを利用する（又は関係する）UE１のための要求条件（e.g., 要求遅延）が、MECに関係しない他のUE１のための要求条件（e.g., 要求遅延）に比べて優先的に満足されるように、無線リソース管理を行ってもよい。これにより、例えば、MECを利用する（又は関係する）UE１に所定の遅延（e.g., 10ミリ秒以下）を保証することが容易になる。
【００４２】
いくつかの実装において、eNodeB２は、MECを利用する（又は関係する）UE１のためのMEC制御情報（e.g., 遅延要件）を満足するために、MECに関係しない他のUE１との無線接続（e.g., RRCコネクション）を解放してもよい。
【００４３】
いくつかの実装において、eNodeB２は、MECを利用する（又は関係する）UE１のためのMEC制御情報（e.g., 遅延要件）を満足するために、MECを利用する（又は関係する）UE１のD-SRリソースの周期をMEC制御情報に基づいて調整してもよい。あるいは、eNodeB２は、MECに関係しないUE１のD-SRリソースの周期を調整してもよい。例えば、eNodeB２は、MECを利用する（又は関係する）UE１のD-SRリソースの周期を、MECに関係しないUE１の周期（e.g., 5-10ミリ秒）に比べて短い周期（e.g., 1又は2ミリ秒）にしてもよい。これにより、MECを利用する（又は関係する）UE１は、スケジューリング要求の送信機会を短い周期で得ることができ、したがって、MECを利用する（又は関係する）UE１の遅延（レイテンシ）の低減に寄与できる。
【００４４】
いくつかの実装において、eNodeB２は、MECを利用する（又は関係する）UE１のためのMEC制御情報（e.g., 遅延要件）を満足するために、MECを利用する（又は関係する）UE１に適用されるスケジューリング・メトリックをMEC制御情報に基づいて調整してもよい。あるいは、eNodeB２は、MECに関係しないUE１に適用されるスケジューリング・メトリックを調整してもよい。例えば、eNodeB２は、MECを利用する（又は関係する）UE１に対して優先的に無線リソース割り当てが行われるように、MECを利用する（又は関係する）UE１に適用されるスケジューリング・メトリックに作用する重みを調整してもよい。proportional fairness（PF）アルゴリズムの場合、スケジューリング・メトリック（PFメトリック）は、瞬時スループットの平均スループットに対する比率（i.e., 瞬時スループット／平均スループット）であってもよい。
【００４５】
なお、上述したD-SRリソース及びスケジューリング・メトリックの調整は、所定の遅延（e.g., 10ミリ秒以内）を要求する複数のUEs１のうち、一部のUE１を所定の遅延のまま維持し、他のUE１の遅延を長くする又はベストエフォートにするために行われてもよい。あるいは、これらの調整は、所定の遅延（e.g., 10ミリ秒以内）を要求する複数のUEs１の全ての遅延を長くする（e.g., 11ミリ秒以内）ことを許容する制御をするために行われてもよい。
【００４６】
いくつかの実装において、eNodeB２は、MECを利用する（又は関係する）UE１のためのMEC制御情報（e.g., 遅延要件）を満足するために、MECに関係しないUE１を他のセルに強制的にハンドオーバさせてもよい。これに代えて、eNodeB２は、MECを利用する（又は関係する）UE１を、当該UE１にとって通信特性の良い（例えば、無線品質が良い、又はセル負荷が小さい）他のセルに強制的にハンドオーバさせてもよい。eNodeB２（ソースeNodeB２Ｓ）は、ハンドオーバ要求を他のeNodeB２（ターゲットeNodeB２Ｔ）に送信してもよい（X2ハンドオーバの場合）。X2ハンドオーバが利用できない場合、eNodeB２（ソースeNodeB２Ｓ）は、コアネットワーク４内のノード（つまり、MME）にハンドオーバ要求を送信してもよい。
【００４７】
例えば、図５に示されるように、ソースeNodeB２ＳからターゲットeNodeB２Ｔに送信されるハンドオーバ要求は、ハンドオーバを行うUE１がエッジ・コンピューティング（MEC）を利用するか否か（または利用しているか否か）を示してもよいし、MECを利用すること（または利用していること）を示してもよい。これは、例えば、HANDOVER REQUEST messageに、MEC Required IEを追加することで行われてもよいし、MEC Authorized IEを追加することで行われてもよい。図５の例（処理５００）では、ソースeNodeB２Ｓは、MECが必要とされるか否かを示すハンドオーバ要求をターゲットeNodeB２Ｔに送信する（ステップ５０１）。ターゲットeNodeB２Ｔは、MECを利用する（又は関係する）UE１のハンドオーバを受け入れられない場合、ハンドオーバ要求を拒絶してもよい。この場合、ハンドオーバ拒絶メッセージは、MECを提供できないこと、MECをサポートしていないこと、又はMECのための遅延要件を満足できないこと、を示してもよい。これにより、ターゲットeNodeB２Ｔは、MECの提供可否を考慮してハンドオーバを受け入れるか否かを判断することができる。あるいは、ターゲットeNodeB２Ｔは、MECを提供できる他のセルをハンドオーバのターゲットセルとして指定し、ソースeNodeB２Ｓにハンドオーバ要求許諾メッセージを送信してもよい。
【００４８】
例えば、ソースeNodeB２Ｓは、１又は複数のターゲットセル候補の中からターゲットセルを決定する際に、各ターゲットセル候補がMECを提供できるか否か、又はMECにより期待される（必要とされる）遅延要件を満たすか否かを考慮してもよい。そのために、複数のeNodeB２は、基地局間インタフェース（e.g., X2インタフェース）を介して、MECサポート及びセル負荷等の情報を交換してもよい。これは、例えば、X2インタフェースの確立手順（X2 Setup Procedure）において実行されてもよいし、基地局の設定を更新する通知（ENB CONFIGURATION UPDATE）によって行われてもよい。
【００４９】
続いて以下では、UE１の特性から導かれるMEC制御情報の具体例を説明する。はじめに、UE１の特性からMEC制御情報としての遅延要件を決定するいくつかの例が説明される。ユーザ（又は車両）の位置情報をMECサーバ５又はセントラル・サーバ６に送信するためにUE１が使用されるケースを考える。一例において、UE１の利用用途・種別（e.g., 自動車、トラック、タクシー、バイク、自転車、歩行者、歩行者の年齢、歩行者の性別など）に応じて、UE１の遅延要件を決定してもよい。MECサーバ５は、交通事故の発生率が高い利用用途・種別のUE１に対して、当該発生率が低い利用用途・種別のUE１よりも厳しい遅延要件（e.g., 小さい最大遅延、小さい平均遅延、又は小さい遅延ジッタ）を決定してもよい。MECサーバ５は、交通事故の影響が深刻である利用用途・種別のUE１に対して、そうでない利用用途・種別のUE１よりも厳しい遅延要件を決定してもよい。
【００５０】
さらに又はこれに代えて、MECサーバ５は、UE１の位置が所定の地点（e.g., 交差点、急カーブ、観光名所）の付近であるときに、UE１の位置が所定の地点から遠い場合に比べて厳しい遅延要件を決定してもよい。さらに又はこれに代えて、MECサーバ５は、UE１が所定の地点に近づいているときに、UE１が所定の地点から遠ざかっているときに比べて厳しい遅延要件を決定してもよい。さらに又はこれに代えて、MECサーバ５は、UE１が高速で移動（走行）しているときに、UE１が低速で移動（走行）しているときに比べて厳しい遅延要件を決定してもよい。
【００５１】
さらに又はこれに代えて、MECサーバ５は、時刻や混雑状況（人又は車の混み具合）に応じて、UE１の遅延要件を決定してもよい。例えば、MECサーバ５は、混雑が予想される時刻または混雑が発生している時に、そうでない場合に比べて厳しい遅延要件を決定してもよい。
【００５２】
遅延要件の決定は、予め定められた複数の遅延要件のクラスのいずれかにUE１を分類する（割り当てる）ことによって行われてもよい。
【００５３】
これらの例によれば、例えば、交差点付近などの交通事故の発生率の高い場所又は利用用途・種別に関連付けられたUE１が低遅延で通信することを可能にできる。
【００５４】
次に、UE１の特性からMEC制御情報としてのスループット要件（無線帯域要件）を決定するいくつかの例が説明される。複数のUEs１の各々がビデオカメラに結合され、ビデオカメラによって得られたビデオストリームをMECサーバ５又はセントラル・サーバ６に送信するために複数のUEs１が使用されるケースを考える。一例において、MECサーバ５は、ビデオカメラの設置場所に応じて、当該ビデオカメラに結合されたUE１のスループット要件（最小スループット（無線帯域）、平均スループット（無線帯域））を決定してもよい。例えば、MECサーバ５は、スタジアム内においてフィールド近くに設置されたビデオカメラに結合されたUE１に高いスループットを与えるようにeNodeB２に要求し、フィールドから遠く離れて設置されたUE１に低いスループットを与えるようにeNodeB２に要求してもよい。
【００５５】
さらに又はこれに代えて、MECサーバ５は、ビデオカメラの種別（e.g., High Definition（HD）カメラ、又は4K Ultra HDカメラ）に応じて、当該ビデオカメラに結合されたUE１のスループット要件を決定してもよい。一例において、MECサーバ５は、高解像度（4K UHD）のビデオカメラに結合されたUE１に高いスループットを与えるようにeNodeB２に要求し、低解像度（eg., HD）のビデオカメラに結合されたUE１に低いスループットを与えるようにeNodeB２に要求してもよい。
【００５６】
さらに又はこれに代えて、MECサーバ５は、各ビデオカメラの撮影状況（例えば、重要な被写体を撮影しているか否か、又は重要な被写体の近くであるか否か）に応じて、当該ビデオカメラに結合されたUE１のスループット要件を決定してもよい。一例において、MECサーバ５は、重要な被写体（例えば、サッカー（フットボール）の試合中のボール）に近いビデオカメラに結合されたUE１に高いスループットを与えるようにeNodeB２に要求してもよい。
【００５７】
さらに又はこれに代えて、時刻や混雑状況（観客の混み具合）に応じて、UE１のスループット要件を決定してもよい。
【００５８】
これらの例によれば、例えば、高解像度のビデオストリームを送信するべきビデオカメラに結合されたUE１に対して動的に広帯域を保証することができる。
【００５９】
次に、スタジアム又はコンサートホール等のイベント会場内の観客へのライブストリーミングのケースについて考える。一例において、MECサーバ５は、スタジアム又はコンサートホール内での観客の位置に応じて、UE１のスループット要件（最小スループット（無線帯域）、平均スループット（無線帯域））を決定してもよい。例えば、フィールド又はステージから遠く離れている観客のUE１に高いスループットを与えるようにeNodeB２に要求し、フィールド又はステージの近くにいる観客のUE１に低いスループットを与えるようにeNodeB２に要求してもよい。さらに又はこれに代えて、時刻や混雑状況（観客の混み具合）に応じて、UE１のスループット要件を決定してもよい。
【００６０】
これらの例によれば、例えば、フィールド又はステージから遠いためにUE１に配信されるライブストリーミングビデオを利用する可能性が高い観客のUE１に対して動的に広帯域を保証することができる。
【００６１】
＜第２の実施形態＞
本実施形態では、第１の実施形態で説明されたeNodeB２による動的な無線リソース管理の変形例が説明される。第１の実施形態では、MECを利用する（又は関係する）UE１の特性から導かれたMEC制御情報をMECサーバ５がeNodeB２に直接的に送信する例を示した。これに代えて、コアネットワーク４内のPCRF７がMEC制御情報の決定を行い、決定したMEC制御情報（Policy and Charging Control (PCC)ルール）をeNodeB２に指示してもよい。
【００６２】
図６は、MECを利用する（又は関係する）UE１の特性から導かれたMEC制御情報をeNodeB２に執行する（enforce）する手順の一例（処理６００）を示している。ステップ６０１では、MECサーバ５は、MECを利用する（又は関係する）UE１の特性情報をPCRF７に送信する。ステップ６０２では、PCRF７は、受信したUE１の特性情報からMEC制御情報を決定し、MEC制御情報をeNodeB２に送信する。ステップ６０２の代わりに、PCRF７は、決定したMEC制御情報をMECサーバ５へ送信し、MECサーバ５からeNodeB２に送信するようにしてもよい。
【００６３】
なお、いくつかの実装において、eNodeB２がPCRF７からMEC制御情報（PCCルール）を受信できるようにするために、eNodeB２は、P-GW機能を有してもよい。当該P-GW機能は、eNodeB２でのユーザトラフィックのオフロードのためにも利用されてもよい。PCRF７からeNodeB２に送られるMEC制御情報は、EPSベアラに関するQuality of Service（QoS）ポリシ又はQoSルール、例えば、Quality Class Indicator（QCI）及び Allocation Retention Priority（ARP)を示してもよい。EPSベアラに関するMEC制御情報（QoSポリシ又はQoSルール）は、eNodeB２において、E-UTRAN Radio Access Bearer (E-RAB) QoS及びradio bearer QoSに対応付けられる。
【００６４】
以上の説明から理解されるように、本実施形態では、MECを利用する又はMECに関係するUE１の特性から導かれるMEC制御情報（e.g., 遅延要件、スループット要件）をPCRF７がeNodeB２に送信する。従って、eNodeB２は、PCRF７から受け取ったMEC制御情報に基づいて、MECを利用する又はMECに関係するUE１又は他のUE１のための無線リソース管理を行うことができる。
【００６５】
最後に、上述の複数の実施形態に係るMECサーバ５、eNodeB２、及びPCRF７の構成例について説明する。図７は、MECサーバ５の構成例を示すブロック図である。図７を参照すると、MECサーバ５は、ネットワークインターフェース７０１、プロセッサ７０２、及びメモリ（ストレージ）７０３を含むハードウェア・コンポーネントを備える。ネットワークインターフェース７０１は、eNodeB２及びその他のネットワークノードと通信するために使用される。ネットワークインターフェース７０１は、例えば、IEEE 802.3 seriesに準拠したネットワークインタフェースカード（NIC）を含んでもよい。
【００６６】
プロセッサ７０２は、メモリ７０３からソフトウェア（コンピュータプログラム）を読み出して実行することで、上述の実施形態においてシーケンス図及びフローチャートを用いて説明されたMECサーバ５の処理を行う。プロセッサ７０２は、例えば、マイクロプロセッサ、Micro Processing Unit（MPU）、又はCentral Processing Unit（CPU）であってもよい。プロセッサ７０２は、複数のプロセッサを含んでもよい。
【００６７】
メモリ７０３は、揮発性メモリ及び不揮発性メモリの組み合わせによって構成される。メモリ７０３は、物理的に独立した複数のメモリデバイスを含んでもよい。揮発性メモリは、例えば、Static Random Access Memory（SRAM）若しくはDynamic RAM（DRAM）又はこれらの組み合わせである。不揮発性メモリは、マスクRead Only Memory（MROM）、Electrically Erasable Programmable ROM（EEPROM）、フラッシュメモリ、若しくはハードディスクドライブ、又はこれらの任意の組合せである。メモリ７０３は、プロセッサ７０２から離れて配置されたストレージを含んでもよい。この場合、プロセッサ７０２は、図示されていないI/Oインタフェースを介してメモリ７０３にアクセスしてもよい。
【００６８】
図７の例では、メモリ７０３は、MECのためのソフトウェアモジュール群７０４〜７０６と、eNodeB２又はPCRF７との通信を行う制御モジュール７０７を格納するために使用される。仮想化管理（virtualization management）ソフトウェア７０４は、プロセッサ７０２において実行され、ネットワークインターフェース７０１、プロセッサ７０２、及びメモリ７０３を含むハードウェア・コンポーネントを仮想化し、Infrastructure as a Service（IaaS）又はPlatform as a Service（PaaS）機能（facility）を提供し、これによりアプリケーションのためのホスティング環境を提供する。
【００６９】
アプリケーション・プラットフォーム・サービス（application platform services）ソフトウェア７０５は、プロセッサ７０２において実行され、通信サービス、無線ネットワーク情報サービス、トラフィックオフロード機能などのミドルウェア・サービスをアプリケーションに提供する。
【００７０】
１又は複数のアプリケーション７０６は、MECサーバ５上にホストされたアプリケーションである。１又は複数のアプリケーション７０６は、背景技術で説明された位置情報（geo-location）アプリケーション、ビデオ解析アプリケーション、及びコンテツ最適化アプリケーション等であってもよい。
【００７１】
制御モジュール７０７は、プロセッサ７０２において実行され、MECを利用する（又はMECに関係する）UE１の特性から導かれるMEC制御情報のeNodeB２への送信、又はUE１の特性のPCRF７等の動作をプロセッサ７０２に行わせる。
【００７２】
図８は、上述の実施形態に係るeNodeB２の構成例を示すブロック図である。図８を参照すると、eNodeB２は、RFトランシーバ８０１、ネットワークインターフェース８０３、プロセッサ８０４、及びメモリ８０５を含む。RFトランシーバ８０１は、UE１と通信するためにアナログRF信号処理を行う。RFトランシーバ８０１は、複数のトランシーバを含んでもよい。RFトランシーバ８０１は、アンテナ８０２及びプロセッサ８０４と結合される。RFトランシーバ８０１は、変調シンボルデータ（又はOFDMシンボルデータ）をプロセッサ８０４から受信し、送信RF信号を生成し、送信RF信号をアンテナ８０２に供給する。また、RFトランシーバ８０１は、アンテナ８０２によって受信された受信ＲＦ信号に基づいてベースバンド受信信号を生成し、これをプロセッサ８０４に供給する。なお、上述したように、eNodeB２は、C-RANアーキテクチャで使用されるBBU（REC）であってもよい。この場合、eNodeB２は、RFトランシーバ８０１を有していなくてもよい。
【００７３】
ネットワークインターフェース８０３は、ネットワークノード（e.g., MME及びS-GW）及びMECサーバ５と通信するために使用される。ネットワークインターフェース８０３は、例えば、IEEE 802.3 seriesに準拠したネットワークインターフェースカード（NIC）を含んでもよい。
【００７４】
プロセッサ８０４は、無線通信のためのデジタルベースバンド信号処理（データプレーン処理）とコントロール・プレーン処理を行う。例えば、LTEおよびLTE-Advancedの場合、プロセッサ８０４によるデジタルベースバンド信号処理は、PDCPレイヤ、RLCレイヤ、MACレイヤ、およびPHYレイヤの信号処理を含んでもよい。また、プロセッサ８０４によるコントロール・プレーン処理は、S1プロトコル、RRCプロトコル、及びMAC CEの処理を含んでもよい。
【００７５】
プロセッサ８０４は、複数のプロセッサを含んでもよい。例えば、プロセッサ８０４は、デジタルベースバンド信号処理を行うモデム・プロセッサ（e.g., DSP）とコントロール・プレーン処理を行うプロトコルスタック・プロセッサ（e.g., CPU又はMPU）を含んでもよい。
【００７６】
メモリ８０５は、揮発性メモリ及び不揮発性メモリの組み合わせによって構成される。揮発性メモリは、例えば、SRAM若しくはDRAM又はこれらの組み合わせである。不揮発性メモリは、例えば、MROM、PROM、フラッシュメモリ、若しくはハードディスクドライブ、又はこれらの組合せである。メモリ８０５は、プロセッサ８０４から離れて配置されたストレージを含んでもよい。この場合、プロセッサ８０４は、ネットワークインターフェース８０３又は図示されていないI/Oインタフェースを介してメモリ８０５にアクセスしてもよい。
【００７７】
メモリ８０５は、上述の複数の実施形態で説明されたeNodeB２による処理を行うための命令群およびデータを含むソフトウェアモジュール（コンピュータプログラム）を格納してもよい。いくつかの実装において、プロセッサ８０４は、当該ソフトウェアモジュールをメモリ８０５から読み出して実行することで、上述の実施形態でシーケンス図及びフローチャートを用いて説明されたeNodeB２の処理を行うよう構成されてもよい。
【００７８】
図８の例では、通信モジュール８０６及び制御モジュール８０７がメモリ８０５に格納されている。プロセッサ８０４は、通信モジュール８０６を読み出して実行することで、MECサーバ５との通信を行うことができる。プロセッサ８０４は、制御モジュール８０７を読み出して実行することで、UE１のMEC制御情報をMECサーバ５から受信し、当該MEC制御情報を考慮しながら無線リソース管理を行うことができる。
【００７９】
図９は、上述の実施形態に係るPCRF７の構成例を示すブロック図である。図９を参照すると、PCRF７は、ネットワークインターフェース９０１、プロセッサ９０２、及びメモリ９０３を含む。ネットワークインターフェース９０１は、ネットワークノード（e.g., MME、HSS、P-GW、eNodeB２）及びMECサーバ５と通信するために使用される。ネットワークインターフェース９０１は、例えば、IEEE 802.3 seriesに準拠したネットワークインタフェースカード（NIC）を含んでもよい。
【００８０】
プロセッサ９０２は、メモリ９０３からソフトウェア（コンピュータプログラム）を読み出して実行することで、上述の実施形態においてシーケンス図及びフローチャートを用いて説明されたPCRF７の処理を行う。プロセッサ９０２は、例えば、マイクロプロセッサ、MPU、又はCPUであってもよい。プロセッサ９０２は、複数のプロセッサを含んでもよい。
【００８１】
メモリ９０３は、揮発性メモリ及び不揮発性メモリの組み合わせによって構成される。メモリ９０３は、プロセッサ９０２から離れて配置されたストレージを含んでもよい。この場合、プロセッサ９０２は、図示されていないI/Oインタフェースを介してメモリ９０３にアクセスしてもよい。
【００８２】
図９の例では、メモリ９０３は、通信モジュール９０４及び制御モジュール９０５を含むソフトウェアモジュール群を格納するために使用される。プロセッサ９０２は、これらのソフトウェアモジュール群をメモリ９０３から読み出して実行することで、上述の実施形態において説明されたPCRF７の処理を行うことができる。
【００８３】
プロセッサ９０２は、通信モジュール９０４を読み出して実行することで、MECサーバ５との通信を行うことができる。プロセッサ９０２は、制御モジュール９０５を読み出して実行することで、UE１の特性情報をMECサーバ５から受信し、当該特性情報から導かれたMEC制御情報をeNodeB２に送信することができる。
【００８４】
図７〜図９を用いて説明したように、上述の実施形態に係るMECサーバ５、eNodeB２、及びPCRF７が有するプロセッサの各々は、図面を用いて説明されたアルゴリズムをコンピュータに行わせるための命令群を含む１又は複数のプログラムを実行する。このプログラムは、様々なタイプの非一時的なコンピュータ可読媒体（non-transitory computer readable medium）を用いて格納され、コンピュータに供給することができる。非一時的なコンピュータ可読媒体は、様々なタイプの実体のある記録媒体（tangible storage medium）を含む。非一時的なコンピュータ可読媒体の例は、磁気記録媒体（例えばフレキシブルディスク、磁気テープ、ハードディスクドライブ）、光磁気記録媒体（例えば光磁気ディスク）、Compact Disc Read Only Memory（CD-ROM）、CD-R、CD-R/W、半導体メモリ（例えば、マスクROM、Programmable ROM（PROM）、Erasable PROM（EPROM）、フラッシュROM、Random Access Memory（RAM））を含む。また、プログラムは、様々なタイプの一時的なコンピュータ可読媒体（transitory computer readable medium）によってコンピュータに供給されてもよい。一時的なコンピュータ可読媒体の例は、電気信号、光信号、及び電磁波を含む。一時的なコンピュータ可読媒体は、電線及び光ファイバ等の有線通信路、又は無線通信路を介して、プログラムをコンピュータに供給できる。
【００８５】
＜その他の実施形態＞
上述の実施形態では、無線リソース管理のためにeNodeB２において考慮されるMEC制御情報が遅延要件であるケースを主に説明した。しかしながら、当該MEC制御情報は、遅延要件に代えて又はこれと組合せて、他の要件（e.g., スループット要件）を含んでもよい。
【００８６】
上述の実施形態は以下のように変形されてもよい。すなわち、いくつかの実装において、MECを利用する（又は関係する）UE１の特性から導かれたMEC制御情報をMECサーバ５がPCRF７に送信してもよい。そして、PCRF７は、MECサーバ５から受信したMEC制御情報に基づくQoSポリシ（e.g., PCCルール）をeNodeB２に指示してもよい。PCRF７は、MECサーバ５から受信したMEC制御情報をそのままeNodeB２に伝えてもよいし、MECサーバ５から受信したMEC制御情報を修正することで得られるQoSポリシをeNodeB２に送信してもよい。
【００８７】
さらに、上述した実施形態は本件発明者により得られた技術思想の適用に関する例に過ぎない。すなわち、当該技術思想は、上述した実施形態のみに限定されるものではなく、種々の変更が可能であることは勿論である。
【符号の説明】
【００８８】
１  UE
２  eNodeB
３  無線アクセスネットワーク
４  コアネットワーク
５  MECサーバ
７  PCRF
７０７  制御モジュール
８０６  通信モジュール
８０７  制御モジュール
９０４  通信モジュール
９０５  制御モジュール
【図１】
0006561632.tif 000002
【図２】
0006561632.tif 000003
【図３】
0006561632.tif 000004
【図４】
0006561632.tif 000005
【図５】
0006561632.tif 000006
【図６】
0006561632.tif 000007
【図７】
0006561632.tif 000008
【図８】
0006561632.tif 000009
【図９】
0006561632.tif 000010