JP6627289B2 - 無線アクセスネットワークノード、エッジサーバ、ポリシ管理ノード、及びこれらの方法 - Google Patents

Description

本開示は、モバイル通信ネットワークに関し、特にモバイル・エッジ・コンピューティングのための装置及び方法に関する。

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
７０７ 制御モジュール
８０６ 通信モジュール
８０７ 制御モジュール
９０４ 通信モジュール
９０５ 制御モジュール

Claims (36)

1. 無線アクセスネットワークに配置される無線アクセスネットワークノードであって、
   前記無線アクセスネットワークに接続する無線端末のための無線リソース管理を提供するよう構成された制御モジュールと、
   前記無線端末に向けたサービス又はアプリケーションに関するエッジ・コンピューティングのためにコンピューティング・リソース及びストレージ・リソースのうち少なくとも１つを提供するエッジサーバと通信するよう構成された通信モジュールと、
   を備え、
   前記制御モジュールは、さらに、前記無線端末の特性から導かれる制御情報を示すメッセージを前記エッジサーバから前記通信モジュールを介して受信し、前記制御情報を考慮して、前記無線端末を含む複数の無線端末のうち少なくとも１つに対する無線リソース管理を行うよう構成され、
   前記制御情報は、遅延要件、スループット要件、プライオリティ要件、及びモビリティ要件のうち少なくとも１つを含む、
   無線アクセスネットワークノード。
2. 前記無線リソース管理は、前記少なくとも１つの無線端末とのコネクションの解放、前記少なくとも１つの無線端末への無線リソースのスケジューリング、前記少なくとも１つの無線端末に対する個別スケジューリング要求リソースの設定、及び前記少なくとも１つの無線端末のハンドオーバ、のうち少なくとも１つを含む、
   請求項１に記載の無線アクセスネットワークノード。
3. 前記無線リソース管理は、前記少なくとも１つの無線端末のハンドオーバを含み、
   前記制御モジュールは、前記少なくとも１つの無線端末のターゲットセルへのハンドオーバのためのハンドオーバ要求を他の無線アクセスネットワークノード又はコアネットワークノードに送信するよう構成されている、
   請求項２に記載の無線アクセスネットワークノード。
4. 前記ハンドオーバ要求は、前記少なくとも１つの無線端末が前記エッジ・コンピューティングを利用するか否かを示す、
   請求項３に記載の無線アクセスネットワークノード。
5. 前記無線リソース管理は、前記個別スケジューリング要求リソースの設定を含み、
   前記制御モジュールは、前記個別スケジューリング要求リソースの周期を前記制御情報に基づいて調整するよう構成されている、
   請求項２に記載の無線アクセスネットワークノード。
6. 前記無線リソース管理は、前記無線リソースのスケジューリングを含み、
   前記制御モジュールは、前記少なくとも１つの無線端末に適用されるスケジューリング・メトリックを前記制御情報に基づいて調整するよう構成されている、
   請求項２に記載の無線アクセスネットワークノード。
7. 前記遅延要件は、最大遅延、平均遅延、遅延ジッタ、及び遅延保証に関する優先度、のうち少なくとも１つを指定する、
   請求項１〜６のいずれか１項に記載の無線アクセスネットワークノード。
8. 前記遅延要件は、当該遅延要件が必要とされる期間、スケジュール、又は回数を指定する、
   請求項１〜７のいずれか１項に記載の無線アクセスネットワークノード。
9. 前記遅延要件は、特定の端末グループに属する複数の無線端末のうち所定の遅延が保証されるべき無線端末の数又は割合を指定する、
   請求項１〜８のいずれか１項に記載の無線アクセスネットワークノード。
10. 前記制御モジュールは、前記エッジ・コンピューティングを利用する又は関係する無線端末のための前記遅延要件によって要求される遅延が、前記エッジ・コンピューティングに関係しない無線端末の要求遅延に比べて優先的に満足されるように、前記無線リソース管理を行うよう構成されている、
    請求項１〜９のいずれか１項に記載の無線アクセスネットワークノード。
11. 無線アクセスネットワークに配置される無線アクセスネットワークノードにおける方法であって、
    前記無線アクセスネットワークに接続する無線端末の特性から導かれる制御情報を示すメッセージをエッジサーバから受信すること、ここで、前記エッジサーバは、前記無線アクセスネットワークに結合して配置されるとともに、前記無線端末に向けたサービス又はアプリケーションに関するエッジ・コンピューティングのためにコンピューティング・リソース及びストレージ・リソースのうち少なくとも１つを提供する、及び
    前記制御情報を考慮して、前記無線端末を含む複数の無線端末のうち少なくとも１つに対する無線リソース管理を行うこと、
    を備え、
    前記制御情報は、遅延要件、スループット要件、プライオリティ要件、及びモビリティ要件のうち少なくとも１つを含む、
    方法。
12. 前記無線リソース管理は、前記少なくとも１つの無線端末とのコネクションの解放、前記少なくとも１つの無線端末への無線リソースのスケジューリング、前記少なくとも１つの無線端末に対する個別スケジューリング要求リソースの設定、及び前記少なくとも１つの無線端末のハンドオーバ、のうち少なくとも１つを含む、
    請求項１１に記載の方法。
13. 無線アクセスネットワークに配置される無線アクセスネットワークノードにおける方法をコンピュータに行わせるためのプログラムであって、
    前記方法は、前記無線アクセスネットワークに接続する無線端末の特性から導かれる制御情報を示すメッセージをエッジサーバから受信すること、及び
    前記制御情報を考慮して、前記無線端末を含む複数の無線端末のうち少なくとも１つに対する無線リソース管理を行うこと、
    を含み、
    前記エッジサーバは、前記無線アクセスネットワークに結合して配置されるとともに、前記無線端末に向けたサービス又はアプリケーションに関するエッジ・コンピューティングのためにコンピューティング・リソース及びストレージ・リソースのうち少なくとも１つを提供するよう構成されており、
    前記制御情報は、遅延要件、スループット要件、プライオリティ要件、及びモビリティ要件のうち少なくとも１つを含む、
    プログラム。
14. 無線アクセスネットワークに結合して配置されるエッジサーバであって、
    前記無線アクセスネットワークに接続する無線端末に向けたサービス又はアプリケーションに関するエッジ・コンピューティングのためにコンピューティング・リソース及びストレージ・リソースのうち少なくとも１つを提供するよう構成されたエッジ・コンピューティング・プラットフォームと、
    前記無線端末の特性から導かれる制御情報を示すメッセージを前記無線アクセスネットワーク内の無線アクセスネットワークノードに送信するよう構成された制御モジュールと、
    を備え、
    前記制御情報は、前記無線端末を含む複数の無線端末のうち少なくとも１つに対する無線リソース管理のために前記無線アクセスネットワークノードによって考慮され、
    前記制御情報は、遅延要件、スループット要件、プライオリティ要件、及びモビリティ要件のうち少なくとも１つを含む、
    エッジサーバ。
15. 前記無線リソース管理は、前記少なくとも１つの無線端末とのコネクションの解放、前記少なくとも１つの無線端末への無線リソースのスケジューリング、前記少なくとも１つの無線端末に対する個別スケジューリング要求リソースの設定、及び前記少なくとも１つの無線端末のハンドオーバ、のうち少なくとも１つを含む、
    請求項１４に記載のエッジサーバ。
16. 前記制御モジュールは、前記無線端末の特性から前記制御情報を決定するよう構成され、
    前記無線端末の特性は、前記無線端末の端末種別、前記無線端末の通信データ種別、及び前記無線端末が利用するサービス又はアプリケーションの種別、のうち少なくとも１つを含む、
    請求項１４又は１５に記載のエッジサーバ。
17. 前記制御モジュールは、前記無線端末の特性から前記制御情報を決定するよう構成され、
    前記無線端末の特性は、前記無線端末の位置および前記無線端末の移動特性のうち少なくとも１つを含む、
    請求項１４又は１５に記載のエッジサーバ。
18. 前記制御モジュールは、前記無線端末の特性から前記制御情報を決定するよう構成され、
    前記無線端末の特性は、前記無線端末の通信間隔および前記無線端末の通信データ量のうち少なくとも１つを含む、
    請求項１４又は１５に記載のエッジサーバ。
19. 前記遅延要件は、最大遅延、平均遅延、遅延ジッタ、及び遅延保証に関する優先度、のうち少なくとも１つを指定する、
    請求項１４〜１８のいずれか１項に記載のエッジサーバ。
20. 前記遅延要件は、当該遅延要件が必要とされる期間、スケジュール、又は回数を指定する、
    請求項１４〜１９のいずれか１項に記載のエッジサーバ。
21. 前記遅延要件は、特定の端末グループに属する複数の無線端末のうち所定の遅延が保証されるべき無線端末の数又は割合を指定する、
    請求項１４〜２０のいずれか１項に記載のエッジサーバ。
22. 無線アクセスネットワークに結合して配置され、前記無線アクセスネットワークに接続する無線端末に向けたサービス又はアプリケーションに関するエッジ・コンピューティングのためにコンピューティング・リソース及びストレージ・リソースのうち少なくとも１つを提供するエッジサーバにおける方法であって、
    前記無線端末の特性から導かれる制御情報を示すメッセージを前記無線アクセスネットワーク内の無線アクセスネットワークノードに送信すること、
    を備え、
    前記制御情報は、前記無線端末を含む複数の無線端末のうち少なくとも１つに対する無線リソース管理のために前記無線アクセスネットワークノードによって考慮され、
    前記制御情報は、遅延要件、スループット要件、プライオリティ要件、及びモビリティ要件のうち少なくとも１つを含む、
    方法。
23. 前記無線リソース管理は、前記少なくとも１つの無線端末とのコネクションの解放、前記少なくとも１つの無線端末への無線リソースのスケジューリング、前記少なくとも１つの無線端末に対する個別スケジューリング要求リソースの設定、及び前記少なくとも１つの無線端末のハンドオーバ、のうち少なくとも１つを含む、
    請求項２２に記載の方法。
24. 前記無線端末の特性から前記制御情報を決定することをさらに備える、
    請求項２２又は２３に記載の方法。
25. 前記無線端末の特性は、前記無線端末の端末種別、前記無線端末の通信データ種別、及び前記無線端末が利用するサービス又はアプリケーションの種別、前記無線端末の位置、前記無線端末の移動特性、前記無線端末の通信間隔、及び前記無線端末の通信データ量、のうち少なくとも１つを含む、
    請求項２４に記載の方法。
26. 無線アクセスネットワークに結合して配置され、前記無線アクセスネットワークに接続する無線端末に向けたサービス又はアプリケーションに関するエッジ・コンピューティングのためにコンピューティング・リソース及びストレージ・リソースのうち少なくとも１つを提供するエッジサーバにおける方法をコンピュータに行わせるためのプログラムであって、
    前記方法は、前記無線端末の特性から導かれる制御情報を示すメッセージを前記無線アクセスネットワーク内の無線アクセスネットワークノードに送信することを含み、
    前記制御情報は、前記無線端末を含む複数の無線端末のうち少なくとも１つに対する無線リソース管理のために前記無線アクセスネットワークノードによって考慮され、
    前記制御情報は、遅延要件、スループット要件、プライオリティ要件、及びモビリティ要件のうち少なくとも１つを含む、
    プログラム。
27. コアネットワークに配置されるポリシ管理ノードであって、
    エッジサーバと通信するよう構成された通信モジュールと、ここで、前記エッジサーバは、無線アクセスネットワークに結合して配置されるとともに、前記無線アクセスネットワークに接続する無線端末に向けたサービス又はアプリケーションに関するエッジ・コンピューティングのためにコンピューティング・リソース及びストレージ・リソースのうち少なくとも１つを提供する；
    前記無線端末の特性情報を前記エッジサーバから前記通信モジュールを介して受信し、前記特性情報から導かれる制御情報を前記無線アクセスネットワーク内に配置された無線アクセスネットワークノードに送信するよう構成された制御モジュールと、
    を備え、
    前記制御情報は、前記無線端末を含む複数の無線端末のうち少なくとも１つに対する無線リソース管理を行うことを前記無線アクセスネットワークノードに要求する、
    ポリシ管理ノード。
28. 前記無線リソース管理は、前記少なくとも１つの無線端末への無線リソースのスケジューリング、前記少なくとも１つの無線端末に対する個別スケジューリング要求リソースの設定、及び前記少なくとも１つの無線端末のハンドオーバ、のうち少なくとも１つを含む、
    請求項２７に記載のポリシ管理ノード。
29. 前記制御情報は、遅延要件、スループット要件、プライオリティ要件、及びモビリティ要件のうち少なくとも１つを含む、
    請求項２７又は２８に記載のポリシ管理ノード。
30. 前記遅延要件は、最大遅延、平均遅延、遅延ジッタ、及び遅延保証に関する優先度、のうち少なくとも１つを指定する、
    請求項２９に記載のポリシ管理ノード。
31. 前記遅延要件は、当該遅延要件が必要とされる期間、スケジュール、又は回数を指定する、
    請求項２９又は３０に記載のポリシ管理ノード。
32. 前記遅延要件は、特定の端末グループに属する複数の無線端末のうち所定の遅延が保証されるべき無線端末の数又は割合を指定する、
    請求項２９〜３１のいずれか１項に記載のポリシ管理ノード。
33. コアネットワークに配置されるポリシ管理ノードにおける方法であって、
    無線端末の特性情報をエッジサーバから受信すること、ここで、前記エッジサーバは、無線アクセスネットワークに結合して配置されるとともに、前記無線アクセスネットワークに接続する前記無線端末に向けたサービス又はアプリケーションに関するエッジ・コンピューティングのためにコンピューティング・リソース及びストレージ・リソースのうち少なくとも１つを提供する；及び
    前記特性情報から導かれる制御情報を前記無線アクセスネットワーク内に配置された無線アクセスネットワークノードに送信すること、
    を備え、
    前記制御情報は、前記無線端末を含む複数の無線端末のうち少なくとも１つに対する無線リソース管理を行うことを前記無線アクセスネットワークノードに要求する、
    方法。
34. 前記無線リソース管理は、前記少なくとも１つの無線端末への無線リソースのスケジューリング、前記少なくとも１つの無線端末に対する個別スケジューリング要求リソースの設定、及び前記少なくとも１つの無線端末のハンドオーバ、のうち少なくとも１つを含む、
    請求項３３に記載の方法。
35. 前記制御情報は、遅延要件、スループット要件、プライオリティ要件、及びモビリティ要件のうち少なくとも１つを含む、
    請求項３３又は３４に記載の方法。
36. コアネットワークに配置されるポリシ管理ノードにおける方法をコンピュータに行わせるためのプログラムであって、
    前記方法は、
    無線端末の特性情報をエッジサーバから受信すること、ここで、前記エッジサーバは、無線アクセスネットワークに結合して配置されるとともに、前記無線アクセスネットワークに接続する前記無線端末に向けたサービス又はアプリケーションに関するエッジ・コンピューティングのためにコンピューティング・リソース及びストレージ・リソースのうち少なくとも１つを提供する；及び
    前記特性情報から導かれる制御情報を前記無線アクセスネットワーク内に配置された無線アクセスネットワークノードに送信すること、
    を含み、
    前記制御情報は、前記無線端末を含む複数の無線端末のうち少なくとも１つに対する無線リソース管理を行うことを前記無線アクセスネットワークノードに要求する、
    プログラム。

Images