JP6593527B2 - 無線アクセスネットワークノード、外部ノード、及びこれらの方法 - 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）サイト、又はセル集約（cell aggregation）サイトに配置されることができる。セル集約サイトは、多数の局所的なアクセスポイントを制御するために、企業の屋内（indoors within an enterprise）（e.g., 病院、大企業の本社）に置かれてもよいし、公共の建物又はアリーナ（e.g., ショッピングモール、スタジアム）の屋内／屋外に置かれてもよい。

MECサーバは、コンピューティング・リソース、ストレージ容量（capacity）、接続性（connectivity）、並びにユーザトラフィック及び無線ネットワーク情報へのアクセスをアプリケーション（MEC applications）に提供する。より具体的には、MECサーバは、Infrastructure as a Service（IaaS）又はPlatform as a Service（PaaS）機能（facility）を提供することによって、アプリケーションのためのホスティング環境を提供する。

MECは、Network Function Virtualization（NFV）と同様に、仮想化された（virtualized）プラットフォームに基づく。NFVはネットワーク機能に重点を置いているのに対して、MECは、ネットワークのエッジでのアプリケーションの実行を可能とする。MECをホストするインフラストラクチャは、NFV又はネットワーク機能をホストするインフラストラクチャと非常に類似している。したがって、Virtual Network Functions（VNFs）及びMECアプリケーション（MEC applications）の両方を同一のプラットフォーム上にホスティングすることで、NFVのインフラストラクチャ及びインフラストラクチャ管理をMECのために再利用することが有益である。

Yun Chao Hu, Milan Patel, Dario Sabella, Nurit Sprecher, and Valerie Young, ETSI White Paper No. 11 "Mobile Edge Computing A key technology towards 5G" First edition, the European Telecommunications Standards Institute, September 2015 ETSI GS MEC-IEG 004 V1.1.1 (2015-11) "Mobile-Edge Computing (MEC); Service Scenarios", the European Telecommunications Standards Institute, November 2015

本件の発明者等は、MECに関する幾つかの課題、特にRANノード（e.g., 無線基地局（eNodeB／RNC））によって行われるパケットスケジューリング（i.e., Medium Access Control（MAC）スケジューリング）に関する課題を見出した。

MACスケジューリングの役割は、ベアラ（論理チャネル）のquality of service（QoS）要件を含む制約（constraints）を満足しつつ、セル容量の最大化、公平性（fairness）の最大化、又は消費電力の最小化などの目的を達成することである。一般的なMACスケジューラは、チャネル品質を考慮し、容量最大化（capacity-maximizing）アルゴリズム若しくはproportional fair（PF）アルゴリズム又はこれらの組み合せを使用する。さらに、MACスケジューラに適用されるスケジューリング・アルゴリズムは、guaranteed bit rate（GBR）制約及び遅延制約などのQoS要件を満足するように工夫されている。具体的には、既存のMACスケジューラは、GBR制約及び遅延制約などのQoS要件を満足するために、各パケット又はセグメント（i.e., MAC Service Data Unit (SDU)、又はRadio Link Control Protocol (RLC) Protocol Data Unit (PDU)）の遅延及び送信デッドラインを考慮する。

幾つかの実装において、MACスケジューラは、Earliest Deadline First（EDF）アプローチに基づくスケジューリング・メトリック（i.e., EDFメトリック）を用いる。EDFメトリックは、遅延閾値（delay threshold）とhead of line delayとの差分の逆数に比例する。head of line delayは、ユーザの送信待ちの先頭パケットの遅延を意味する。

さらに又はこれに代えて、幾つかの実装において、MACスケジューラは、送信遅延に基づくファクターにより重み付けされたPFメトリックを使用する（例えば、modified largest weighted delay first（LWDF）アルゴリズム）。

さらに又はこれに代えて、幾つかの実装において、MACスケジューラは、無線端末の送信待ちパケットの量（つまり、バックログ又はキュー長）に比例するスケジューリング・メトリックを使用する。

さらに又はこれに代えて、幾つかの実装において、MACスケジューラは、時間ドメイン・スケジューラ及び周波数ドメイン・スケジューラを含む。時間ドメイン・スケジューラは、複数の無線端末を優先度付けし（prioritize）、各送信ピリオド（e.g., LTEサブフレーム）にスケジュールされる１又はそれ以上の無線端末を選択する。周波数ドメイン・スケジューラは、各送信ピリオド内の無線リソース（e.g., LTEリソースブロック）と時間ドメイン・スケジューラによって選択された無線端末との最適なマッピングを決定する。例えば、時間ドメイン・スケジューラは、GBRを下回る無線端末又はEDFメトリックが基準値を超える無線端末を現在の送信ピリオドにスケジュールされるために優先的に選択する。

本件発明者等は、RAN内でのパケットスケジューリング（MACスケジューリング）に関して、MECを利用する又はMECに関係する特定の無線端末に対する特別な配慮をMECサーバからRANノード（e.g., eNodeB、RNC）に求めることについて検討した。MECサーバ上にホストされている特定のMECアプリケーションは、RANノードに接続している無線端末にインストールされている特定のアプリケーションと通信する。このような特定のMECアプリケーションの通信は、通信特性が予測可能であるかもしれない。通信特性は、例えば、無線端末のアプリケーション・レイヤとMECアプリケーションとの間の１回の通信イベントにおいてダウンリンク（DL）又はアップリンク（UL）上で送信されるトータルのデータサイズである。

MECアプリケーションの通信特性をMACスケジューリングのためにRANノードにおいて考慮することは、例えば、MECを利用する又はMECに関係する特定の無線端末の遅延要件をRANにおいてより確実に保証することに寄与するかもしれない。あるいは、このことは、スケジューリングに対する制約を緩和し、無線リソース使用効率（又はシステム容量、システムスループット）を高めることに寄与するかもしれない。

なお、上述したRAN内でのパケットスケジューリングにおける特別な配慮は、無線端末とMECアプリケーションとの通信に限らず、無線端末の様々なアプリケーションの通信に関して有効であるかもしれない。

したがって、本明細書に開示される実施形態が達成しようとする目的の１つは、パケットスケジューリングを無線端末のアプリケーションの通信に適応させるための改良に寄与する装置、方法、及びプログラムを提供することである。なお、この目的は、本明細書に開示される複数の実施形態が達成しようとする複数の目的の１つに過ぎないことに留意されるべきである。その他の目的又は課題と新規な特徴は、本明細書の記述又は添付図面から明らかにされる。

第１の態様では、無線アクセスネットワークノードは、メモリと、前記メモリに結合され、複数のモジュールを実行するよう構成された少なくとも１つのプロセッサを含む。前記複数のモジュールは、通信モジュール及びスケジューラを含む。前記通信モジュールは、外部ノードと通信するよう構成されている。前記スケジューラは、第１の無線端末を含む複数の無線端末の各々のためのデータバッファからのデータセグメントのダウンリンク送信又はアップリンク送信をスケジュールするよう構成されている。ここで、前記第１の無線端末のための前記データバッファは、前記第１の無線端末又は前記無線アクセスネットワークノードに到着した各データパケットから生成される１又はそれ以上の送信されるためのデータセグメントを格納する。前記通信モジュールは、さらに、前記第１の無線端末の第１の通信イベントに関する送信履歴を前記外部ノードに送信するよう構成されている。前記通信モジュールは、さらに、前記通信モジュール、前記スケジューラ、前記データバッファ、及び前記第１の無線端末のうち少なくとも１つに対する制御要求を前記外部ノードから受信するよう構成されている。

第２の態様では、無線アクセスネットワークノードにおける方法は、
（ａ）第１の無線端末の第１の通信イベントに関する送信履歴を、外部ノードに送信すること、及び
（ｂ）前記無線アクセスネットワークノード内の前記外部ノードと通信するための通信モジュール、前記無線アクセスネットワークノード内のスケジューラ、前記無線アクセスネットワークノード又は前記第１の無線端末に配置されるデータバッファ、及び前記第１の無線端末のうち少なくとも１つに対する制御要求を前記外部ノードから受信すること、
を含む。

第３の態様では、外部ノードは、メモリと、前記メモリに結合され、無線アクセスネットワークノードと通信するよう構成された通信モジュールを含む複数のモジュールを実行するよう構成された少なくとも１つのプロセッサを含む。前記通信モジュールは、第１の無線端末の第１の通信イベントに関する送信履歴を前記無線アクセスネットワークノードから受信するよう構成され、前記無線アクセスネットワークノード内の前記外部ノードと通信するためのモジュール、前記無線アクセスネットワークノード内のスケジューラ、前記無線アクセスネットワークノード又は前記第１の無線端末に配置されるデータバッファ、及び前記第１の無線端末のうち少なくとも１つに対する制御要求を前記無線アクセスネットワークノードに送信するよう構成されている。

第４の態様では、MECサーバにおける方法は、
（ａ）第１の無線端末の第１の通信イベントに関する送信履歴を無線アクセスネットワークノードから受信すること、及び
（ｂ）前記無線アクセスネットワークノード内の前記外部ノードと通信するためのモジュール、前記無線アクセスネットワークノード内のスケジューラ、前記無線アクセスネットワークノード又は前記第１の無線端末に配置されるデータバッファ、及び前記第１の無線端末のうち少なくとも１つに対する制御要求を前記無線アクセスネットワークノードに送信すること、
を含む。

第５の態様では、プログラムは、コンピュータに読み込まれた場合に、上述の第２又は第４の態様に係る方法をコンピュータに行わせるための命令群（ソフトウェアコード）を含む。

上述の態様によれば、パケットスケジューリングを無線端末のアプリケーションの通信に適応させるための改良に寄与する装置、方法、及びプログラムを提供できる。

幾つかの実施形態に係るモバイル通信ネットワークの構成例を示す図である。 第１の実施形態に係るeNodeB及びMECサーバの動作の一例を示すシーケンス図である。 第１の実施形態に係るMECサーバの動作の一例を示すフローチャートである。 第１の実施形態に係るeNodeBの動作の一例を示すフローチャートである。 第１の実施形態に係るeNodeBのダウンリンク・スケジューリングに関する構成例を示すブロック図である。 第１の実施形態に係るeNodeBの動作の一例を示すフローチャートである。 第１の実施形態に係るeNodeBの動作の一例を示すフローチャートである。 第１の実施形態に係るeNodeBの動作の一例を示すフローチャートである。 第１の実施形態に係るeNodeBのアップリンク・スケジューリングに関する構成例を示すブロック図である。 第１の実施形態に係るMECサーバの構成例を示すブロック図である。 第２の実施形態に係るeNodeBの動作の一例を示すフローチャートである。 第２の実施形態に係るeNodeBの動作の一例を示すフローチャートである。 第３の実施形態に係るeNodeB及びMECサーバの動作の一例を示す図である。 幾つかの実施形態に係るMECサーバの構成例を示す図である。 幾つかの実施形態に係るeNodeBの構成例を示す図である。

以下では、具体的な実施形態について、図面を参照しながら詳細に説明する。各図面において、同一又は対応する要素には同一の符号が付されており、説明の明確化のため、必要に応じて重複説明は省略される。

以下に示される複数の実施形態は、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１のハンドオーバの制御を含む。図１に示されたeNodeB２は、マクロセル基地局であってもよいし、フェムトセル基地局であってもよい。

図１に示された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）と呼ばれることもある。

さらに、ベースバンド信号処理の一部をリモートサイトに配置するC-RANアーキテクチャも存在する。幾つかの実装では、レイヤ１（物理レイヤ）のベースバンド信号処理がリモートサイトに配置され、レイヤ２（MACサブレイヤ、RLCサブレイヤ、及びPacket Data Convergence Protocol（PDCP）サブレイヤ）及びレイヤ３信号処理がセントラルサイトに配置されてもよい。幾つかの実装では、レイヤ１並びにレイヤ２の一部又は全部の信号処理がリモートサイトに配置され、レイヤ３信号処理がセントラルサイト内に配置されてもよい。図１に示されたeNodeB２は、これらのC-RANアーキテクチャにおいてセントラルサイトに配置されるデータユニットであってもよい。

コアネットワーク４は、主にモバイル通信サービスを提供するオペレータによって管理されるネットワークである。コアネットワーク４は、複数のユーザープレーン・エンティティ（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））を含む。S/P-GWを含む複数のユーザープレーン・エンティティは、RAN３と外部ネットワーク（Packet Data Network (PDN)）との間でUEs１のユーザデータを中継する。MMEを含む複数のコントロールプレーン・エンティティは、UEs１のモビリティ管理、セッション管理（ベアラ管理）、加入者情報管理、及び課金管理を含む様々な制御を行う。

Mobile Edge Computing（MEC）サーバ５は、無線アクセスネットワークノード（RANノード）と直接的に（つまり、コアネットワーク４を介さずに）通信できるように、RAN３内に配置される。MECサーバ５は、エッジサーバと呼ぶこともできる。図１の例では、MECサーバ５は、eNodeB２と直接的に通信できるように、RAN３内に配置される。上述したように、eNodeB２は、BBUであってもよい。幾つかの実装において、MECサーバ５は、eNodeB２と物理的に統合されてもよい。幾つかの実装において、MECサーバ５は、eNodeB２と同じ建物（サイト）に配置され、eNodeB２と通信できるように当該サイト内のLocal Area Network（LAN）に接続されてもよい。

MECサーバ５は、１又は複数のUE１に向けたサービス又はアプリケーションに関するエッジ・コンピューティングのためにコンピューティング・リソース及びストレージ・リソース（ストレージ容量（capacity））のうち少なくとも１つを提供するよう構成されている。幾つかの実装において、MECサーバ５は、IaaS又はPaaS機能（facility）を提供することによって、MECアプリケーションのためのホスティング環境を提供してもよい。

MECサーバ５は、さらに、コアネットワーク４の一部の機能を有してもよい。例えば、MECサーバ５は、S-GWまたはS/P-GWの機能を有し、MECを利用するUE１のベアラ（Evolved Packet System（EPS）ベアラ）を終端してもよい。上述したように、MECのアーキテクチャは、NFVのアーキテクチャと類似している。したがって、MECサーバ５は、MECアプリケーションをホストするだけでなく、仮想化された（virtualized）S/P-GW（vS/P-GW）を含むネットワーク機能をホストしてもよい。

幾つかの実装において、MECサーバ５は、１又は複数のセントラル・サーバ９と通信してもよい。MECサーバ５は、コアネットワーク４を経由してセントラル・サーバ９と通信してもよいし、コアネットワーク４を経由しない通信回線又はネットワーク上でセントラル・サーバ９と通信してもよい。また、図１には示されていないが、MECサーバ５は、複数のeNodeB２に接続されてもよい。

続いて以下では、eNodeB２によるパケットスケジューリング（MACスケジューリング）をMECアプリケーションの通信に適応させるためのeNodeB２及びMECサーバ５の動作及び構成について説明する。図２は、eNodeB２及びMECサーバ５の動作の一例（処理２００）を示すシーケンス図である。ステップ２０１では、MECサーバ５は、MEC制御情報（MEC control information）をeNodeB２に送信する。当該MEC制御情報は、特定のUE１のアプリケーション・レイヤとMECサーバ５にホストされたMECアプリケーションとの間の通信イベントで送信される複数のデータパケットの合計サイズと、これら複数のデータパケットの送信デッドラインとを示す。幾つかの実装において、当該MEC制御情報は、１つのUEの識別子、複数のUE（UEグループ）の識別子、又はUE種別の識別子を示してもよい。これらの識別子は、当該合計サイズ及び送信デッドラインが適用される１又はそれ以上の特定のUE１を識別するためにeNB２によって使用される。

UE１のアプリケーションとMECアプリケーションとの間の１回の通信イベントは、通信トランザクション又は通信フローと言うこともできる。１回の通信イベント、通信トランザクション、又は通信フローは、特定のサービスに関する一方向（i.e., DL又はUL）又は双方向（i.e., DL及びUL）のデータ送信を含む。１回の通信イベントは、アプリケーション・レイヤにおいて取り扱われるデータ（e.g., 画像データ、又はGlobal Navigation Satellite Systems（GNSS）位置データ）の送信であってもよい。具体例を示すと、例えば、１回の通信イベントは、MECアプリケーションからUE１のアプリケーションへの１又は複数の画像データの送信であってもよい。この場合、通信イベントは、MECサーバ５からUE１への１又は複数の画像データのDL送信を少なくとも含む。さらに、この通信イベントは、UE１からMECサーバ５へのユーザデータ（e.g., 画像データの要求メッセージ、及び画像データ受信に基づく応答メッセージ）のUL送信を含んでもよい。

複数のデータパケットの合計サイズは、１回の通信イベントにおいて、一方向（i.e., DL又はUL）送信で送られる複数のデータパケットの合計サイズを示してもよい。これに代えて、複数のデータパケットの合計サイズは、１回の通信イベントにおいて、DL送信される複数のDLデータパケットの合計サイズとUL送信される複数のULデータパケットの合計サイズを示してもよい。

複数のデータパケットの送信デッドラインは、１回の通信イベントに関する複数のデータパケットの送信を完了するべき期限を意味する。送信デッドラインは、アプリケーションによって要求される。送信デッドラインは、送信期限と言うこともできる。あるいは、送信デッドラインは、アプリケーションによって許容される最大送信遅延と言うこともできる。送信デッドラインは、様々に定義することができる。例えば、送信デッドラインは、アプリケーション・レイヤの発信者（sender）（i.e., UE１のアプリケーション又はMECアプリケーション）による送信の完了期限を示してもよい。あるいは、送信デッドラインは、無線レイヤの発信者（i.e., UE１又はeNB２）による送信の完了期限を示してもよい。あるいは、送信デッドラインは、アプリケーション・レイヤの受信者（receiver）による（i.e., UE１のアプリケーション又はMECアプリケーション）による受信の完了期限を示してもよい。あるいは、送信デッドラインは、無線レイヤの受信者（i.e., UE１又はeNB２）による受信の完了期限を示してもよい。あるいは、より具体的に、送信デッドラインは、アプリケーションレイヤの発信者（sender）が１回の通信イベントに関する最初のデータパケットを送信開始してからアプリケーションレイヤの受信者（receiver）が１回の通信イベントに関する最後のデータパケットを受信完了する期限を示してもよい。あるいは、また、送信デッドラインは、無線レイヤの発信者が１回の通信イベントに関する最初のデータパケットを送信開始してから無線レイヤの受信者が１回の通信イベントに関する最後のデータパケットを受信完了する期限を示してもよい。

UE１とMECアプリケーションとの間の通信イベントで送信される複数のデータパケットの合計サイズ及び送信デッドラインは、eNodeB２の動作をMECアプリケーションの通信特性に適応させるためにeNodeB２によって使用される。言い換えると、合計サイズ及び送信デッドラインを示す当該MEC制御情報は、eNodeB２がeNodeB２の動作をMECアプリケーションの通信特性に適応させることを支援する。具体的には、eNodeB２は、当該通信イベントに関するeNodeB２によるDL送信履歴又はUE１によるUL送信履歴を取得し、取得した送信履歴と上述の合計サイズに基づいて残りの未送信データパケットのサイズを計算する。

なお、DL送信履歴は、当該通信イベントの１又はそれ以上のDLデータパケットから生成されたDLデータセグメント（e.g., DL RLC PDUs）の送信量であってもよい。eNodeB２は、eNodeB２内のUE１のためのDL送信データバッファの状態をモニタすることでDL RLC PDUsの送信量を取得してもよい。DL RLC PDUsの送信量は、eNodeB２内のMACスケジューラ（DL MACスケジューラ）によって取得されてもよい。同様に、UL送信履歴は、当該通信イベントの１又はそれ以上のULデータパケットから生成されたULデータセグメント（e.g., UL RLC PDUs）の送信量であってもよい。eNodeB２は、eNodeB２によってUE１から受信されたUL RLC PDUsを計測することで、UE１のUL RLC PDUsの送信量を取得してもよい。これに代えて、eNodeB２は、UE１に発行したULグラントに基づいてUE１のUL RLC PDUsの送信量を判定してもよい。

幾つかの実装において、eNodeB２は、UE１とMECアプリケーションとの間の通信イベントで送信される複数のデータパケットの送信が送信デッドラインまでに完了する確率（デッドライン達成確率（deadline completion probability））を判定してもよい。具体的には、eNodeB２は、残りの未送信データパケットのサイズ、上述の送信デッドライン、及びUE１のスループットに基づいてデッドライン達成確率を求めてもよい。ここで、UE１のスループットは、例えば、eNodeB２からUE１への通信速度、UE１からeNodeB２への通信速度、これら両方、あるいはこれら両方を合わせたものであってもよい。これに代えて、UE１のスループットは、MECサーバ５からUE１への通信速度、UE１からMECサーバ５への通信速度、これら両方、あるいはこれら両方を合わせたものであってもよい。eNodeB２は、デッドライン達成確率を求めるために、UE１の過去の平均スループットを使用してもよいし、現在又は将来の予測スループットを使用してもよい。

より具体的には、幾つかの実装において、eNodeB２は、通信イベントにおいて、UE１に存在する残りの未送信データパケットのサイズとUE１からeNodeB２への通信速度のスループット（あるいはUE１からMECサーバ５への通信速度のスループット）に基づいて送信完了までの時間を計算し、その送信完了までの時間と送信デッドラインからデッドライン達成確率を求めてもよい。他の実装において、eNodeB２は、通信イベントにおいて、MECサーバ５またはeNodeB２に存在する残りの未送信データパケットのサイズとeNodeB２からUE１への通信速度のスループット（あるいはMECサーバ５からUE１への通信速度のスループット）に基づいて送信完了までの時間を計算し、その送信完了までの時間と送信デッドラインからデッドライン達成確率を求めてもよい。

さらに他の実装において、eNodeB２は、UE１に存在する残りの未送信データパケットのサイズとUE１からeNodeB２への通信速度のスループット（あるいはUE１からMECサーバ５への通信速度のスループット）に基づいて計算した送信完了までの第１の時間を計算してもよい。さらに、eNodeB２は、MECサーバ５またはeNodeB２に存在する残りの未送信データパケットのサイズとeNodeB２からUE１への通信速度のスループット（あるいはMECサーバ５からUE１への通信速度のスループット）に基づいて計算した送信完了までの第２の時間を計算してもよい。そして、eNodeB２は、UE１に存在する残りの未送信データパケット及びMECサーバ５またはeNodeB２に存在する残りの未送信データパケットの両方の送信完了までに要する（総合的な）第３の時間をこれら第１及び第２の時間から導出し、当該第３の時間と送信デッドラインからデッドライン達成確率を求めてもよい。第３の時間は、第１及び第２の時間の単なる加算、減算、乗算、又は除算により導かれてもよいし、第１及び第２の時間にそれぞれ異なる重みを付けた加算、減算、乗算、又は除算により導かれてもよい。あるいは、第３の時間は、第１及び第２の時間を変数とした何らかの数学関数を用いた演算により導かれてもよい。

デッドライン達成確率は、例えば、上述の送信完了までの時間（あるいは複数の送信完了までの時間を合算した時間）が送信デッドラインに到達しそうであるほど低く（すなわち送信デッドラインを超過する可能性が高いため達成確率を低く）なるように定義してもよい。言い換えると、デッドライン達成確率は、上述の送信完了までの時間（あるいは複数の送信完了までの時間を合算した時間）が送信デッドラインに到達しそうでないほど高く（すなわち送信デッドラインを超過する可能性が低いため達成確率を高く）なるように定義されてもよい。

eNodeB２は、デッドライン達成確率が所定の閾値以下（又は閾値以上）であることを判定してもよい。あるいは、eNodeB２は、デッドライン達成確率の履歴が徐々に低下（又は増加）する傾向を示すことを判定してもよい。eNodeB２は、デッドライン達成確率の代わりに、デッドラインを失敗する確率（デッドライン違反確率（deadline violation probability））を判定してもよい。

例えば、eNodeB２は、デッドライン達成確率の低下（つまり、デッドライン違反確率の増加）に応答して、特定のUE１への割り当て無線リソースを増やす又は他のUE１への割り当て無線リソースを減らすようにMACスケジューラを制御してもよい。これにより、eNodeB２は、当該特定のUE１のデッドライン達成の可能性を高めることができる。あるいは、eNodeB２は、デッドライン達成確率の低下（つまり、デッドライン違反確率の増加）に応答して、特定のUE１への割り当て無線リソースを減らす又は他のUE１への割り当て無線リソースを増やすようにMACスケジューラを制御してもよい。これにより、eNodeB２は、当該他のUE１のデッドライン達成の可能性を高めることができる。

具体的には、eNodeB２は、各UE１のデッドライン達成確率の値の大きさを比較して、各UE１に無線リソース（リソースブロック：Resource Block:RB）を割り当てるスケジューリングをしてもよい。より具体的に、例えば、このスケジューリングは、デッドライン達成確率の値が大きいUE１により多くのRBを割り当てるように動作してもよい。また逆に、デッドライン達成確率の値が小さいUE１により多くのRBを割り当てるように動作してもよい。あるいは他に、デッドライン達成確率の値が平均的な（あるいは中央値を示す）UE１により多くのRBを割り当てるように動作してもよい。なお、スケジューリングを行う周期は、MACスケジューラのスケジューリング周期（送信ピリオド又はTransmission Time Interval（TTI））と同じでもよいし、長くてもよい。例えば、１ミリ秒のサブフレーム毎にスケジューリングを行うLTE MACスケジューラの場合、当該所定の期間は、１０ミリ秒（i.e., １フレーム）であってもよいし、さらに別の期間であってもよい。

あるいは、eNodeB２は、MACスケジューラによって考慮されるパラメータを変更してもよい。パラメータは、例えば、UE優先度レベル、QoSパラメータ（e.g., QoS Class Indicator（QCI）、GBR、Prioritized Bit Rate（PBR））、遅延閾値、及びデータ送信ボリュームのうち少なくとも１つを含む。データ送信ボリュームは、特定のUE１又はその特定の論理チャネル（ベアラ）について所定の期間に送信されるべきデータ量を示す。当該所定の期間は、MACスケジューラのスケジューリング周期（送信ピリオド又はTransmission Time Interval（TTI））と同じでもよいし、長くてもよい。例えば、１ミリ秒のサブフレーム毎にスケジューリングを行うLTE MACスケジューラの場合、当該所定の期間は、１０ミリ秒（i.e., １フレーム）であってもよい。あるいは、eNodeB２は、MACスケジューラに適用されるスケジューリング戦略アルゴリズムを変更してもよい。スケジューリング戦略は、スケジューリング・ポリシと言うこともできる。スケジューリング戦略の変更は、スケジューリング・アルゴリズムを変更すること、スケジューリング・アルゴリズムで使用されるスケジューリング・メトリックの定義（計算式）を変更すること、スケジューリングで考慮される制約条件（constraints）を変更すること、又はこれらの任意の組み合せを含む。

これとは反対に、例えば、eNodeB２は、デッドライン達成確率の増加（つまり、デッドライン違反確率の低下）に応答して、特定のUE１への割り当て無線リソースを減らす又は他のUE１への割り当て無線リソースを増やすようにMACスケジューラを制御してもよい。これにより、eNodeB２は、スケジューリングに対する制約を緩和することができ、したがって無線リソース使用効率を高めることに寄与できる。あるいは、eNodeB２は、デッドライン達成確率の増加（つまり、デッドライン違反確率の低下）に応答して、特定のUE１への割り当て無線リソースを増やす又は他のUE１への割り当て無線リソースを減らすようにMACスケジューラを制御してもよい。これにより、eNodeB２は、特定のUE１の通信をより短時間で完了させることができ、その完了後に無線リソースを他のUE１のためだけに割り当てることができ、したがって無線リソースの使用効率を高めることができる。

例えば、eNodeB２は、デッドライン達成確率の低下（つまり、デッドライン違反確率の増加）に応答して、特定のUE１の特定のUL論理チャネル（ベアラ）への無線リソース割り当てを増やすために、当該特定のUE１のMACレイヤにより行われるLogical Channel Prioritization（LCP）手順に影響を与える少なくとも１つのパラメータを変更してもよい。当該少なくとも１つのパラメータは、論理チャネル優先度、PBR、Bucket Size Duration（BSD）、又はこれらの任意の組み合せを含む。UL MAC PDU（i.e., トランスポートブロック）の生成では、UE１は、UE１に設定されている複数の論理チャネルを１つのMAC PDUに多重化する。１つのMAC PDU（トランスポートブロック）のサイズは、eNodeB２からのULグラントによってUE１に割り当てられたリソースに依存する。UL MAC PDU の生成では、ULに設定された各無線ベアラのQoS（i.e., PBR）が保証されなければならない。したがって、UE１は、LCP手順に従ってUL MAC PDUを生成する。LCP手順では、各論理チャネルの優先度及びPBRが考慮される。PBRは、プリオリティのより低い論理チャネルに対して何らかのリソースが割り当てられるよりも前に各論理チャネルに提供されるビットレートである。LCP手順は第１ラウンド及び第２ラウンドを含む。第１ラウンドでは、全ての論理チャネルは、優先度の高いものから順にPBRに対応するリソースが割り当てられる。なお、第１ラウンドにおいて各論理チャネルに割り当てられるリソースの上限は、各論理チャネルのbucket sizeに等しい。各論理チャネルのbucket sizeは、PBRにBSDを掛けて得られる値である。次に、第２ラウンドでは、全ての論理チャネルにPBRに対応するリソースが提供されてもまだ利用可能なリソースに余りがある場合に、優先度の高い論理チャネルのデータから順に、その論理チャネルのデータが無くなるか又は割り当てられたリソースが使い尽くされるまでリソースが割り当てられる。

ULと同様に、eNodeB２は、特定のUE１の特定のDL論理チャネル（ベアラ）への無線リソース割り当てを増やすために、トランスポートブロック（MAC PDU）を生成するためのDL論理チャネルの多重化に影響を与える少なくとも１つのパラメータを変更してもよい。当該少なくとも１つのパラメータは、論理チャネル優先度、PBR、BSD、又はこれらの任意の組み合せを含む。

eNodeB２は、特定のUE１とMECアプリケーションとの間の特定の通信イベントに関するデッドライン達成確率の低下（つまり、デッドライン違反確率の増加）に応答して、当該特定の通信イベントに関する特定のデータ無線ベアラ（論理チャネル）の優先度を上げてもよいし、PBRを増やしてもよいし、BSDを増やしてもよい。さらに又はこれに代えて、eNodeB２は、他のデータ無線ベアラ（論理チャネル）の優先度を下げてもよいし、PBRを減らしてもよいし、BSDを減らしてもよい。これにより、eNodeB２は、特定のUE１とMECアプリケーションとの間の特定の通信イベントに関するデッドライン達成の可能性を高めることができる。

例えば、eNodeB２は、デッドライン達成確率の低下（つまり、デッドライン違反確率の増加）に応答して、eNodeB２内のDL送信データバッファに格納されている当該通信イベントに関係するDLデータセグメント（i.e., DL RLC PDUs）を破棄してもよい。当該動作によれば、eNodeB２は、もはや送信デッドラインを達成できる見込みのない通信イベントのデータ送信のために無線リソースが消費されることを抑止できる。

例えば、eNodeB２は、デッドライン達成確率の低下（つまり、デッドライン違反確率の増加）に応答して、当該通信イベントのDL（又はUL）送信データレートの変更、又は他のUE１に関する他の通信イベントのDL（又はUL）送信データレートの変更をMECサーバ５に要求してもよい。eNodeB２による送信データレートの変更の要求は、MECアプリケーションによるDL送信データレート又はUE１のアプリケーションのUL送信データレートを調整するようにMECサーバ５をトリガーする。具体的には、MECサーバ５は、eNodeB２からの要求に応答して、MECアプリケーションによるDL送信データレート又はUE１のアプリケーションのUL送信データレートを調整するように、MECアプリケーションに指示してもよい。さらに又はこれに代えて、eNodeB２は、当該通信イベントの合計サイズの減少又は送信デッドラインの延期をMECサーバ５に要求してもよい。これにより、eNodeB２は、デッドライン達成の可能性を高めることができる。

なお、上述されたデッドライン達成確率及びデッドライン違反確率は、送信デッドラインを達成できる見込み・可能性（possibility、feasibility、又はlikelihood）を判定するためにeNodeB２が使用できるパラメータの具体例の１つである。eNodeB２は、他のパラメータ又は他の手法に基づいて、送信デッドラインを達成できる見込み・可能性を判定してもよく、送信デッドラインの達成見込み・可能性の低下又は増加に応答して、上述したスケジューリング制御、送信データバッファ制御、又はMECサーバ５への要求を行ってもよい。

例えば、eNodeB２は、残りの未送信データパケットのサイズ、上述の送信デッドライン、及びUE１のスループットに基づいて、残りの未送信データパケットの送信に要する時間（送信所要時間）と送信デッドラインまでの残り時間との差分を計算してもよい。そして、eNodeB２は、スケジューリング、送信データバッファ、又はMECサーバ５への要求を制御するためのトリガー・メトリックとして当該差分を使用してもよい。

以下では、本実施形態に係るeNodeB２及びMECサーバ５の動作及び構成の具体例をより詳細に説明する。図３は、MECサーバ５の動作の一例（処理３００）を示すフローチャートである。ステップ３０１では、MECサーバ５は、MECサーバ５にホストされているMECアプリケーションと特定のUE１との間の１回の通信イベントで送信される複数のデータパケットの合計サイズ及び送信デッドラインを決定する。当該合計サイズ及び送信デッドラインは、MECアプリケーションの識別子又は種別と関連付けられてもよい。すなわち、MECサーバ５は、特定のUE１と通信するMECアプリケーションを決定し、当該MECアプリケーションの識別子又は種別に応じて、１回の通信イベントで送信される複数のデータパケットの合計サイズ及び送信デッドラインを決定してもよい。

さらに又はこれに代えて、MECサーバ５は、アプリケーションの状況（e.g., 処理時間）に応じて送信デッドラインを動的に更新してもよい。あるアプリケーションの処理時間は変動する可能性がある。幾つかの実装において、当該処理時間は、例えば、MECサーバ５又はUE１において当該アプリケーションに割り当てられるCentral Processing Unit（CPU）リソース及びメモリ・リソースに依存する。あるいは、当該処理時間は、当該アプリケーションに関するCPUの演算量の大きさに依存する。あるいは、当該処理時間は、MECサーバ５又はUE１が他のノード（e.g., データベース）との通信に要する時間に依存する。当該アプリケーションの処理時間の変動に起因して、エンド・ツー・エンドの遅延要件を保証するためにモバイル通信ネットワークに要求される遅延要件（i.e., 送信デッドライン）も変動する。

さらに又はこれに代えて、MECサーバ５は、UE１、eNodeB２、又はRAN３の状態（コンテキスト）の変化に応答して、１回の通信イベントで送信される複数のデータパケットの合計サイズ若しくは送信デッドライン又は両方を更新してもよい。例えば、MECサーバ５は、UE１、eNodeB２、又はRAN３の状態の変化を示す情報をeNodeB２から受信してもよい。

ステップ３０２では、MECサーバ５は、決定した合計サイズ及び送信デッドラインを示す制御メッセージをeNodeB２に送信する。

幾つかの実装において、MECサーバ５は、eNodeB２からの要求又は通知の受信に応答して、図３に示された手順を実行してもよい。さらに又はこれに代えて、MECサーバ５は、UE１との通信の要求をMECアプリケーションから受信したことに応答して、図３に示された手順を実行してもよい。さらに又はこれに代えて、MECサーバ５は、MECアプリケーションからの要求に基づいてUE１をページングする際に、図３に示された手順を実行してもよい。

図４は、eNodeB２の動作の一例（処理４００）を示すフローチャートである。ステップ４０１では、eNodeB２は、特定のMECアプリケーションと特定のUE１との間の１回の通信イベントで送信される複数のデータパケットの合計サイズ及びデッドラインを示す制御メッセージをMECサーバ５から受信する。ステップ４０２では、eNodeB２は、合計サイズ及び特定のUE１の送信履歴から残りの未送信データパケットのサイズを計算する。eNodeB２は、ステップ４０２の処理を繰り返し行い、残りの未送信データパケットのサイズの値をアップデートする。例えば、eNodeB２は、MACスケジューラの各スケジューリング周期（i.e., １ミリ秒）において、残りの未送信データパケットのサイズを計算してもよい。

ステップ４０３では、eNodeB２は、残りの未送信データパケットのサイズと送信デッドラインとに基づいて、通信モジュール、MACスケジューラ、及び送信データバッファの少なくとも１つを制御する。既に説明したように、eNodeB２は、デッドライン達成確率又はデッドライン違反確率を計算し、デッドライン達成確率の低下（又はデッドライン違反確率の増加）に応答して、通信モジュール（又はMECインタフェース）、MACスケジューラ、送信データバッファ、及びUE１（e.g., UE１によるLCP手順）の少なくとも１つを制御してもよい。ここで、通信モジュール（又はMECインタフェース）は、MECサーバ５とのインタフェースを提供し、MECサーバ５への制御メッセージの送信をeNodeB２に可能とする。MACスケジューラは、DL MACスケジューラ及びUL MACスケジューラを含む。送信データバッファは、eNodeB２に配置され且つDLデータセグメント（DL RLC PDUs）を格納するDL送信データバッファ、及びUE１に配置され且つULデータセグメント（UL RLC PDUs）を格納するUL送信データバッファを含む。

以下では、図４のステップ４０３で行われる処理の具体例が説明される。初めに図５〜図８を参照して、DLデータ送信に関する処理の幾つかの例が説明される。図５は、DL送信に関係するeNodeB２の構成例を示すブロック図である。MACサブレイヤ５０１は、DL送信データバッファ５０２、DLスケジューラ５０３、マルチプレクサ５０４、及びHybrid Automatic Repeat reQuest（HARQ）エンティティ５０５を含む。DL送信データバッファ５０２は、各UE１の１又はそれ以上のDL論理チャネルのデータセグメント（i.e., DL RLC PDUs）を格納する。DL送信データバッファ５０２は、DL送信キュー又はRLCキューと呼ぶこともできる。図５に示されたDL送信データバッファ５０２Ａは、UE１Ａの１又はそれ以上のDL論理チャネルのRLC PDUsを格納する。DL送信データバッファ５０２Ｂは、UE１Ｂの１又はそれ以上のDL論理チャネルのRLC PDUsを格納する。DL送信データバッファ５０２は、MACレイヤ５０１ではなくRLCレイヤに配置されてもよい。

DLスケジューラ５０３は、DL送信データバッファ５０２のバッファ状態及びDLチャネルの品質状態に少なくとも部分的に基づいて、現在の送信ピリオド（i.e., サブフレーム）における複数のUEs１のDL送信をスケジュールする。DLチャネルの品質状態は、各UE１からのChannel Quality Information（CQI）報告から得られる。DLスケジューラ５０３は、他の情報及び制約（constraints）をDLスケジューリングのために考慮してもよい。例えば、DLスケジューラ５０３は、各UE１のQoS要件（e.g., GBR）、各UE１の伝送レートの履歴、若しくは各UE１の優先度、又はこれらの任意の組合せを考慮してもよい。幾つかの実装において、DLスケジューラ５０３は、時間ドメイン・スケジューラ及び周波数ドメイン・スケジューラを含む。時間ドメイン・スケジューラは、複数のUE１を優先度付けし（prioritize）、各送信ピリオド（i.e., サブフレーム）にスケジュールされる１又はそれ以上のUEs１を選択する。周波数ドメイン・スケジューラは、各送信ピリオド内の無線リソース（i.e., リソースブロック）と時間ドメイン・スケジューラによって選択されたUEsとの最適なマッピングを決定する。

マルチプレクサ５０４は、現在の送信ピリオドで送信されるためのトランスポートブロック（i.e., MAC PDU）を、DLスケジューラ５０３による各UE１への無線リソース割り当て及びModulation and Coding Scheme（MCS）に基づいて生成する。図５に示されたマルチプレクサ５０４Ａは、UE１Ａに送信されるDLトランスポートブロックを生成する。マルチプレクサ５０４Ｂは、UE１Ｂに送信されるDLトランスポートブロックを生成する。

HARQエンティティ５０５は、送信HARQ動作を担う。送信HARQ動作は、トランスポートブロックの送信及び再送信、並びにACK/NACKシグナリングの受信及び処理を含む。図５に示されたHARQエンティティ５０５Ａは、UE１Ａのための送信HARQ動作を担う。HARQエンティティ５０５Ｂは、UE１Ｂのための送信HARQ動作を担う。

物理レイヤ５０６は、DLスケジューラ５０３により決定されたMCS及びリソース割り当てに従って、各トランスポートブロックをコーディングし、変調シンボル（Physical Downlink Shared Channel（PDSCH）symbols）を生成し、変調シンボルをリソースブロックにマッピングする。

MECインタフェース（MEC I/F）５２１は、MECサーバ５とのインタフェースを提供し、MECサーバ５への制御メッセージの送信及びMECサーバ５からの制御メッセージの受信をeNodeB２に可能とする。MECインタフェース５２１は、特定のUE１（e.g., UE１Ａ）と特定のMECアプリケーションとの間の通信イベントで送信される複数のDLデータパケットの合計サイズ及び送信デッドラインをMECサーバ５から受信する（５４１）。MECインタフェース５２１は、受信した合計サイズ及び送信デッドラインをコントローラ５２２に送る（５４２）。

コントローラ５２２は、特定のUE１（e.g., UE１Ａ）に送信される複数のDLデータパケットの合計サイズ（５４２）及び当該特定のUE１へのDL送信履歴（５４３）に基づいて、残りの未送信データパケットのサイズを計算する。コントローラ５２２は、計算された残りの未送信データパケットのサイズと送信デッドライン（５４２）に基づいて、MECインタフェース５２１、DLスケジューラ５０３、及びDL送信データバッファ５０２のうち少なくとも１つを制御する。

コントローラ５２２は、DL送信履歴（５４３）をDLスケジューラ５０３から受信してもよい。これに代えて、コントローラ５２２は、DL送信履歴（５４３）を取得するためにDL送信データバッファ５０２のバッファ状態の変化を監視してもよい。

幾つかの実装において、コントローラ５２２は、特定の通信イベントのデッドライン達成確率の低下に応答して、制御コマンドをDL送信データバッファ５０２に送信してもよい（５６１）。当該制御コマンドは、特定のUE１（e.g., UE１Ａ）のDL送信データバッファ５０２（e.g., バッファ５０２Ａ）に格納されている当該通信イベントに関係するDLデータセグメント（i.e., DL RLC PDUs）の破棄をDL送信データバッファ５０２にトリガーする。

図６は、コントローラ５２２の動作の一例（処理６００）を示すフローチャートである。ステップ６０１では、コントローラ５２２は、残りの未送信データパケットのサイズと送信デッドラインとに基づいて、特定の通信イベントに関する全てのDLデータパケットの送信が送信デッドラインまでに完了するか否かを予測する。ステップ６０２では、コントローラ５２２は、全てのDLデータパケットの送信が送信デッドラインまでに完了できないと判定したことに応答して、残りの未送信データパケットに対応するRLC PDUsを破棄するようにDL送信データバッファ５０２を制御する。

幾つかの実装において、コントローラ５２２は、DLスケジューラ５０３によるスケジューリングを制御してもよい（５６２）。例えば、コントローラ５２２は、特定の通信イベントのデッドライン達成確率の低下に応答して、特定のUE１（e.g., UE１Ａ）への割り当て無線リソースを増やす又は他のUE１（e.g., UE１Ｂ）への割り当て無線リソースを減らすようにDLスケジューラ５０３を制御してもよい。これとは反対に、コントローラ５２２は、デッドライン達成確率の増加に応答して、特定のUE１（e.g., UE１Ａ）への割り当て無線リソースを減らす又は他のUE１（e.g., UE１Ｂ）への割り当て無線リソースを増やすようにDLスケジューラ５０３を制御してもよい。さらに、コントローラ５２２は、デッドライン達成確率の低下に応答して、特定のUE１（e.g., UE１Ａ）への割り当て無線リソースを減らす又は他のUE１（e.g., UE１Ｂ）への割り当て無線リソースを増やすようにDLスケジューラ５０３を制御してもよい。また、コントローラ５２２は、デッドライン達成確率の増加に応答して、特定のUE１（e.g., UE１Ａ）への割り当て無線リソースを増やす又は他のUE１（e.g., UE１Ｂ）への割り当て無線リソースを減らすようにDLスケジューラ５０３を制御してもよい。具体的には、コントローラ５２２は、DLスケジューラ５０３によって考慮されるパラメータを変更してもよい。パラメータは、例えば、UE優先度レベル、QoSパラメータ（e.g., QCI、GBR、PBR）、遅延閾値、及びデータ送信ボリュームのうち少なくとも１つを含む。さらに又はこれに代えて、コントローラ５２２は、DLスケジューラ５０３に適用されるスケジューリング戦略を変更してもよい。

図７は、コントローラ５２２の動作の一例（処理７００）を示すフローチャートである。ステップ７０１では、コントローラ５２２は、残りの未送信データパケットのサイズと送信デッドラインとに基づいて、特定の通信イベントのデッドライン達成確率を計算する。デッドライン達成確率は、特定の通信イベントに関する全てのデータパケットのDL送信が送信デッドラインまでに完了する確率である。ステップ７０２では、コントローラ５２２は、デッドライン達成確率の低下に応答して、当該特定の通信イベントに関与する特定のUE１への割り当て無線リソースを増やすようにDLスケジューラ５０３を制御する。

幾つかの実装において、コントローラ５２２は、MECインタフェース５２１を介してMECサーバ５に制御要求を送信してもよい（５６３、５６４）。例えば、コントローラ５２２は、特定の通信イベントのデッドライン達成確率の低下に応答して、当該特定の通信イベントのDL送信データレートの変更、又は他の通信イベントのDL送信データレートの変更をMECサーバ５に要求してもよい。具体的には、データレートの変更は、MECサーバ５のInternet Protocol（IP）キュー（あるいはバッファ）の制御、あるいはTransmission Control Protocol（TCP）キュー（あるいはバッファ）の制御、あるいはアプリケーションキュー（あるいはバッファ）の制御によって実現されてもよい。なお、これらキュー（あるいはバッファ）の制御とは、キュー（あるいはバッファ）内の特定のパケットの送信順番を優先する優先制御であってもよい。さらに又はこれに代えて、コントローラ５２２は、特定の通信イベントの合計サイズの減少又は送信デッドラインの延期をMECサーバ５に要求してもよい。

図８は、コントローラ５２２の動作の一例（処理８００）を示すフローチャートである。ステップ８０１では、コントローラ５２２は、残りの未送信データパケットのサイズと送信デッドラインとに基づいて、特定の通信イベントのデッドライン達成確率を計算する。ステップ８０２では、コントローラ５２２は、デッドライン達成確率の低下に応答して、制御要求をMECサーバ５に送信する。当該制御要求は、例えば、当該特定の通信イベントのDL送信レートの低下をMECサーバ５に要求する。

さらに、コントローラ５２２は、１回の通信イベントで送信される複数のDLデータパケットの合計サイズ及び送信デッドラインのうち少なくとも１つの動的な更新を示す通知をMECインタフェース５２１を介してMECサーバ５から受信してもよい。コントローラ５２２は、当該通知の受信に応答して、動的に更新された合計サイズ又は送信デッドラインに基づいて、MECインタフェース５２１、DLスケジューラ５０３、及びDL送信データバッファ５０２のうち少なくとも１つを制御してもよい。

続いて、図９を参照して、ULデータ送信に関して図４のステップ４０３で行われる処理の具体例が説明される。図９は、UL送信に関係するeNodeB２の構成例を示すブロック図である。ULスケジューラ９０３は、UE１（e.g., UE１Ａ）内のUL送信データバッファ１１（e.g., バッファ１１Ａ）のバッファ状態及びULチャネルの品質状態に少なくとも部分的に基づいて、現在の送信ピリオド（i.e., サブフレーム）における複数のUEs１のUL送信をスケジュールする。ULチャネルの品質状態は、物理レイヤ９０６によって取得される。ULチャネルの品質状態は、各UE１とeNodeB２との間の複数のリソースブロックに渡るチャネル品質を示す。UL送信データバッファ１１のバッファ状態は、各UE１からのバッファ状態報告（Buffer Status Report（BSR））から得られる。上述したDLスケジューラ５０３と同様に、ULスケジューラ９０３は、他の情報及び制約（constraints）をULスケジューリングのために考慮してもよい。幾つかの実装において、ULスケジューラ９０３は、時間ドメイン・スケジューラ及び周波数ドメイン・スケジューラを含む。

デマルチプレクサ９０４は、受信されたトランスポートブロック（i.e., UL MAC PDU）から１又はそれ以上の論理チャネルからのデータセグメント（i.e., UL RLC PDUs）を取り出し、これらを適切なRLCエンティティに送る。また、デマルチプレクサ９０４は、受信されたトランスポートブロックからMACコントロールエレメント（MAC CE）を取り出し、これをULスケジューラ９０３に送る。UE１からのMAC CEは、BSRを含む。図９に示されたデマルチプレクサ９０４Ａは、UE１Ａからのトランスポートブロックを処理する。デマルチプレクサ９０４Ｂは、UE１Ｂからのトランスポートブロックを処理する。

HARQエンティティ９０５は、受信HARQ動作を担う。受信HARQ動作は、トランスポートブロックの受信、受信データの合成、及びACK/NACKシグナリングの生成を含む。図９に示されたHARQエンティティ９０５Ａは、UE１Ａのための受信HARQ動作を担う。HARQエンティティ９０５Ｂは、UE１Ｂのための受信HARQ動作を担う。

MECインタフェース（MEC I/F）９２１は、MECサーバ５とのインタフェースを提供し、MECサーバ５への制御メッセージの送信及びMECサーバ５からの制御メッセージの受信をeNodeB２に可能とする。MECインタフェース９２１は、特定のUE１（e.g., UE１Ａ）と特定のMECアプリケーションとの間の通信イベントで送信される複数のULデータパケットの合計サイズ及び送信デッドラインをMECサーバ５から受信する（９４１）。MECインタフェース９２１は、受信した合計サイズ及び送信デッドラインをコントローラ９２２に送る（９４２）。

コントローラ９２２は、特定のUE１（e.g., UE１Ａ）から送信される複数のULデータパケットの合計サイズ（９４２）及び当該特定のUE１のUL送信履歴（９４３）に基づいて、残りの未送信データパケットのサイズを計算する。コントローラ９２２は、計算された残りの未送信データパケットのサイズと送信デッドライン（９４２）に基づいて、MECインタフェース９２１、ULスケジューラ９０３、及びUL送信データバッファ１１のうち少なくとも１つを制御する。

既に説明したように、UL送信履歴（９４３）は、当該通信イベントの１又はそれ以上のULデータパケットから生成されたULデータセグメント（e.g., UL RLC PDUs）の送信量であってもよい。コントローラ９２２は、UL送信履歴（９４３）をULスケジューラ９０３から受信してもよい。ULスケジューラ９０３は、UE１から受信されたUL RLC PDUsを計測することで、UE１のUL RLC PDUsの送信量を取得してもよい。これに代えて、ULスケジューラ９０３は、UE１に発行したULグラントに基づいてUE１のUL RLC PDUsの送信量を判定してもよい。

幾つかの実装において、コントローラ９２２は、特定の通信イベントのデッドライン達成確率の低下に応答して、制御コマンドを特定のUE１（e.g., UE１Ａ）に送信してもよい。当該制御コマンドは、例えば、RRCエンティティ９０７を介してRRCメッセージを用いて特定のUE１に送信されてもよい（９６１）。当該制御コマンドは、特定のUE１（e.g., UE１Ａ）のUL送信データバッファ１１（e.g., バッファ１１Ａ）に格納されている当該通信イベントに関係するULデータセグメント（i.e., UL RLC PDUs）の破棄を特定のUE１（e.g., UE１Ａ）にトリガーする。

幾つかの実装において、コントローラ９２２は、ULスケジューラ９０３によるスケジューリングを制御してもよい（９６２）。例えば、コントローラ９２２は、特定の通信イベントのデッドライン達成確率の低下に応答して、特定のUE１（e.g., UE１Ａ）への割り当て無線リソースを増やす又は他のUE１（e.g., UE１Ｂ）への割り当て無線リソースを減らすようにULスケジューラ９０３を制御してもよい。これとは反対に、コントローラ９２２は、デッドライン達成確率の増加に応答して、特定のUE１（e.g., UE１Ａ）への割り当て無線リソースを減らす又は他のUE１（e.g., UE１Ｂ）への割り当て無線リソースを増やすようにULスケジューラ９０３を制御してもよい。さらに、コントローラ９２２は、デッドライン達成確率の低下に応答して、特定のUE１（e.g., UE１Ａ）への割り当て無線リソースを減らす又は他のUE１（e.g., UE１Ｂ）への割り当て無線リソースを増やすようにULスケジューラ９０３を制御してもよい。また、コントローラ９２２は、デッドライン達成確率の増加に応答して、特定のUE１（e.g., UE１Ａ）への割り当て無線リソースを増やす又は他のUE１（e.g., UE１Ｂ）への割り当て無線リソースを減らすようにULスケジューラ９０３を制御してもよい。具体的には、コントローラ９２２は、ULスケジューラ９０３によって考慮されるパラメータを変更してもよい。パラメータは、例えば、UE優先度レベル、QoSパラメータ（e.g., QCI、GBR、PBR）、遅延閾値、及びデータ送信ボリュームのうち少なくとも１つを含む。さらに又はこれに代えて、コントローラ９２２は、ULスケジューラ９０３に適用されるスケジューリング戦略を変更してもよい。

幾つかの実装において、コントローラ９２２は、MECインタフェース９２１を介してMECサーバ５に制御要求を送信してもよい（９６３、９６４）。例えば、コントローラ９２２は、特定の通信イベントのデッドライン達成確率の低下に応答して、当該特定の通信イベントのUL送信データレートの変更、又は他の通信イベントのUL送信データレートの変更をMECサーバ５に要求してもよい。具体的には、データレートの変更は、MECサーバ５のIPキュー（あるいはバッファ）の制御、あるいはTCPキュー（あるいはバッファ）の制御、あるいはアプリケーションキュー（あるいはバッファ）の制御によって実現されてもよい。なお、これらキュー（あるいはバッファ）の制御とは、キュー（あるいはバッファ）内の特定のパケットの送信順番を優先する優先制御であってもよい。さらに又はこれに代えて、コントローラ９２２は、特定の通信イベントの合計サイズの減少又は送信デッドラインの延期をMECサーバ５に要求してもよい。

さらに、コントローラ９２２は、１回の通信イベントで送信される複数のULデータパケットの合計サイズ及び送信デッドラインのうち少なくとも１つの動的な更新を示す通知をMECインタフェース５２１を介してMECサーバ５から受信してもよい。コントローラ９２２は、当該通知の受信に応答して、動的に更新された合計サイズ又は送信デッドラインに基づいて、MECインタフェース９２１、ULスケジューラ９０３、及びUL送信データバッファ１１のうち少なくとも１つを制御してもよい。

続いて、図１０を参照して、MECサーバ５の構成例を説明する。図１０の例では、MECサーバ５は、MECアプリケーション１００１、コントローラ１００２、及びeNodeBインタフェース（eNodeB I/F）１００３を含む。MECアプリケーション１００１は、MECサーバ５上にホストされている。コントローラ１００２は、MECアプリケーション１００１と特定のUE１との間の通信イベントで送信される複数のデータパケットの合計サイズと送信デッドラインを決定し、これらをeNodeBインタフェース１００３を介してeNodeB２に送信する（１０４２、１０４３）。

既に説明したように、１回の通信イベントで送信される複数のデータパケットの合計サイズ及び送信デッドラインは、MECアプリケーション１００１の識別子又は種別と関連付けられてもよい。コントローラ１００２は、特定のUE１と通信するMECアプリケーション１００１を決定し、当該MECアプリケーション１００１の識別子又は種別に応じて、１回の通信イベントで送信される複数のデータパケットの合計サイズ及び送信デッドラインを決定してもよい。コントローラ１００２は、MECアプリケーション１００１から１回の通信イベントで送信される複数のデータパケットの合計サイズ及び送信デッドラインを受信してもよい（１０４１）。

さらに、コントローラ１００２は、eNodeB２からの制御要求をeNodeBインタフェース１００３を介して受信してもよい（１０６１、１０６２）。一例において、当該制御要求は、DL（又はUL）送信データレートの調整を要求する。他の例において、当該制御要求は、１回の通信イベントで送信される複数のデータパケットの合計サイズ又は送信デッドラインの変更を要求する。コントローラ１００２は、eNodeB２からの制御要求の受信に応答して、送信データレート、合計サイズ、又は送信デッドラインの調整をMECアプリケーション１００１に要求してもよい（１０６３）。

さらに、コントローラ１００２は、１回の通信イベントで送信される複数のデータパケットの合計サイズ及び送信デッドラインのうち少なくとも１つの動的な更新を決定し、これらの更新を示す通知をeNodeBインタフェース１００３を介してeNodeB２に送信してもよい。例えば、既に説明したように、コントローラ１００２は、アプリケーションの状況（e.g., 処理時間）に応じて送信デッドラインを動的に決定してもよい。

＜第２の実施形態＞
本実施形態では、第１の実施形態で説明されたeNodeB２の動作の変形例が説明される。本実施形態のモバイル通信ネットワークの構成例は、図１と同様である。

第１の実施形態では、MECアプリケーションに関する複数のDLデータパケット送信のデッドライン達成の見込み・可能性に基づいて、eNodeB２がDLに関する制御を行う例が説明された。DLに関する制御は、例えば、DL RLC PDUsの破棄、DLスケジューリング制御、又はDLに関する制御要求のMECサーバ５への送信である。同様に、第１の実施形態では、MECアプリケーションに関する複数のULデータパケット送信のデッドライン達成確率に基づいて、eNodeB２がULに関する制御を行う例が説明された。ULに関する制御は、例えば、UL RLC PDUsの破棄、ULスケジューリング制御、又はULに関する制御要求のMECサーバ５への送信である。

これに対して、本実施形態では、eNodeB２は、MECアプリケーションに関する複数のDLデータパケット送信のデッドライン達成の見込み・可能性に基づいて、ULに関する制御を行う。また、eNodeB２は、MECアプリケーションに関する複数のULデータパケット送信のデッドライン達成の見込み・可能性に基づいて、DLに関する制御を行う。さらに、eNodeB２は、MECアプリケーションに関する複数のDLデータパケット送信のデッドライン達成の見込み・可能性とMECアプリケーションに関する複数のULデータパケット送信のデッドライン達成の見込み・可能性の両方（あるいは両方を合算した結果）に基づいて、ULおよびDLに関する制御を行う。UE１のアプリケーション・レイヤとMECアプリケーションとの間の幾つかの通信イベントは、双方向（i.e., DL及びUL）のデータ送信を含むことがある。例えば、リクエスト・レスポンス型の通信の場合、一方向（e.g., UL送信）の遅延がもう１つの方向（e.g., DL送信）の遅延をもたらす可能性がある。あるいは、仮に一方向のデータ送信（e.g., UL送信）が送信デッドラインを守れないと、もう１つの方向のデータ送信（e.g., DL送信）を継続する必要性が失われることもあるかもしれない。本実施形態によれば、eNodeB２によるパケットスケジューリングを双方向型のMECアプリケーションの通信に適応させることができる。

図１１は、eNodeB２の動作の一例（処理１１００）を示すフローチャートである。ステップ１１０１では、eNodeB２（図５に示されたコントローラ５２２又は図９に示されたコントローラ９２２）は、残りの未送信データパケットのサイズと送信デッドラインとに基づいて、特定の通信イベントに関する全てのDLデータパケットの送信が送信デッドラインまでに完了するか否かを予測する。ステップ１１０２では、eNodeB２は、全てのDLデータパケットの送信が送信デッドラインまでに完了できないと判定したことに応答して、当該通信イベントに関するUE１からのUL送信を抑止するようにULスケジューラ９０３又は当該UE１を制御する。例えば、eNodeB２は、UL送信データバッファ１１に格納されているデータセグメントの破棄をUE１に指示してもよい。

図１１に示されたULとDLの役割は反対であってもよい。すなわち、eNodeB２は、全てのULデータパケットの送信が送信デッドラインまでに完了できないと判定したことに応答して、当該通信イベントに関するUE１からのDL送信を抑止するようにDLスケジューラ５０３又はDL送信データバッファ５０２を制御してもよい。これらの動作によれば、一方向（e.g., DL）の送信デッドラインを達成できる見込みのない通信イベントのために、もう１つの方向（e.g., UL）の無線リソースが消費されることを抑止できる。

図１２は、eNodeB２の動作の他の例（処理１２００）を示すフローチャートである。ステップ１２０１では、eNodeB２（図５に示されたコントローラ５２２又は図９に示されたコントローラ９２２）は、残りの未送信データパケットのサイズと送信デッドラインとに基づいて、特定の通信イベントのDLデッドライン達成確率を計算する。DLデッドライン達成確率は、特定の通信イベントに関する全てのDLデータパケットの送信が送信デッドラインまでに完了する確率である。ステップ１２０２では、eNodeB２は、DLデッドライン達成確率の低下に応答して、当該特定の通信イベントに関与する特定のUE１への割り当て無線リソースを増やすようにULスケジューラ９０３を制御する。

図１２に示されたULとDLの役割は反対であってもよい。すなわち、eNodeB２は、ULデッドライン達成確率の低下に応答して、当該特定の通信イベントに関与する特定のUE１への割り当て無線リソースを増やすようにDLスケジューラ５０３を制御してもよい。これらの動作によれば、一方向（e.g., DL）の送信デッドラインの達成を支援するために、もう１つの方向（e.g., UL）のスケジューリングを調整できる。これにより、eNodeB２は、デッドライン達成の可能性を高めることができる。

さらに、eNodeB２は、ULとDLのデッドライン達成確率を合算した結果に基づいてULスケジューラ９０３またはDLスケジューラ５０３を制御してもよい。

第１の実施形態で既に説明したように、デッドライン達成確率は、送信デッドラインを達成できる見込み・可能性（possibility、feasibility、likelihood）を判定するためにeNodeB２が使用できるパラメータの具体例の１つである。eNodeB２は、他のパラメータ又は他の手法に基づいて、送信デッドラインを達成できる見込み・可能性を判定してもよく、送信デッドラインの達成見込み・可能性の低下又は増加に応答して、通信モジュール、MACスケジューラ、及び送信データバッファの少なくとも１つを制御してもよい。

＜第３の実施形態＞
本実施形態では、第１及び第２の実施形態で説明されたeNodeB２及びMECサーバ５の動作の変形例が説明される。本実施形態のモバイル通信ネットワークの構成例は、図１と同様である。

第１及び第２の実施形態では、eNodeB２が、未送信データパケットのサイズと送信デッドラインに基づいて、データセグメント破棄、スケジューリング制御、又はMECアプリケーションへの制御要求の実行を決定する例が説明された。例えば、eNodeB２は、特定の通信イベントに関する全てのデータパケットの送信が送信デッドラインまでに完了するか否かを予測し、送信デッドラインを達成できないとの判定に応答して、DL（又はUL）送信データバッファから当該特定の通信イベントに関するデータセグメントを破棄する。あるいは、eNodeB２は、デッドライン達成見込みを推定し、デッドライン達成見込みの低下又は増加に応答して、DL（又はUL）スケジューラによるスケジューリングを調整する。例えば、eNodeB２は、デッドライン達成確率を計算し、デッドライン達成確率が所定の閾値以下であることを判定したことに応答して、特定のUE１への割り当て無線リソースを増やす又は他のUE１への割り当て無線リソースを減らすようにDL（又はUL）スケジューラを制御する。

本実施形態では、第１及び第２の実施形態で説明されたこれらの処理をMECサーバ５がeNodeB２に代わって行う。図１３を参照して、本実施形態のeNodeB２及びMECサーバ５の動作を説明する。eNodeB２は、MECアプリケーションに関する特定の通信イベントに関する送信履歴をMECサーバ５に送信する（１３０１）。当該送信履歴は、DL送信履歴及びUL送信履歴のいずれか又は両方であってもよい。DL送信履歴は、当該特定の通信イベントの１又はそれ以上のDLデータパケットから生成されたDLデータセグメント（e.g., DL RLC PDUs）の送信量であってもよい。UL送信履歴は、当該特定の通信イベントの１又はそれ以上のULデータパケットから生成されたULデータセグメント（e.g., UL RLC PDUs）の送信量であってもよい。

MECサーバ５は、制御要求をeNodeB２に送信する（１３０２）。幾つかの実装において、当該制御要求は、eNodeB２内のDL送信データバッファ若しくはUE１内のUL送信データバッファ、又はこれら両方に対するデータ破棄の要求であってもよい。例えば、MECサーバ５は、MECサーバ５が計算した特定の通信イベントのデッドライン達成見込みの低下に応答して、eNodeB２内のDL送信データバッファ５０２から当該特定の通信イベントに関するデータセグメントを破棄するようにeNodeB２に要求してもよい。これらの動作によれば、eNodeB２及びMECサーバ５は、もはや送信デッドラインを達成できる見込みのない通信イベントのデータ送信のために無線リソースが消費されることを抑止できる。

さらに又はこれに代えて、当該制御要求は、eNodeB２内のスケジューラ（DLスケジューラ５０３及びULスケジューラ９０３のいずれか又は両方）にスケジューリングの調整を要求してもよい。例えば、MECサーバ５は、特定の通信イベントのDLデッドライン達成見込みの低下に応答して、特定のUE１（e.g., UE１Ａ）への割り当て無線リソースを増やす又は他のUE１（e.g., UE１Ｂ）への割り当て無線リソースを減らすようにeNodeB２（DLスケジューラ５０３）に要求してもよい。具体的には、当該制御要求は、スケジューラによって考慮されるパラメータを指定してもよい。既に説明したように、スケジューラによって考慮されるパラメータは、例えば、UE優先度レベル、QoSパラメータ（e.g., QCI、GBR、PBR）、遅延閾値、及びデータ送信ボリュームのうち少なくとも１つを含む。さらに又は、当該制御指示は、スケジューラに適用されるスケジューリング戦略の変更を要求してもよい。これにより、eNodeB２及びMECサーバ５は、デッドライン達成の可能性を高めることができる。

さらに又はこれに代えて、当該制御要求は、UE１によるLCP手順の変更をeNodeB２に要求してもよい。例えば、MECサーバ５は、特定の通信イベントのDLデッドライン達成確率の低下に応答して、当該特定の通信イベントに関する特定の無線ベアラ（論理チャネル）のへの割り当て無線リソースを増やすようにeNodeB２（コントローラ５２２、９２２）に要求してもよい。具体的には、当該制御要求は、LCP手順において考慮されるパラメータを指定してもよい。既に説明したように、LCP手順において考慮されるパラメータは、論理チャネル優先度、PBR、及びBSDのうち少なくとも１つを含む。これにより、eNodeB２及びMECサーバ５は、デッドライン達成の可能性を高めることができる。

さらに又はこれに代えて、当該制御要求は、eNodeB２内のMECサーバ５と通信するための通信モジュール（MECインタフェース５２１又は９２１）に対する制御要求であってもよい。当該制御要求は、例えば、MECアプリケーションに対する要求の送信をeNodeB２に許可してもよい。MECアプリケーションに対する要求は、例えば、MECアプリケーションのDL（又はUL）送信データレートの調整を要求してもよいし、MECアプリケーションと特定のUE１との間の１回の通信イベントで送信される複数のデータパケットの合計サイズ又は送信デッドラインの変更を要求してもよい。

より具体的に述べると、MECサーバ５は、以下のように動作してもよい。MECサーバ５は、MECアプリケーションの特定のUE１との間の１回の通信イベントで送信される複数のデータパケットの合計サイズ又は送信デッドラインを取得する。既に説明したように、MECサーバ５は、MECアプリケーションの識別子又は種別に応じて、１回の通信イベントで送信される複数のデータパケットの合計サイズ及び送信デッドラインを決定してもよい。あるいは、MECサーバ５は、これら合計サイズ及び送信デッドラインをMECアプリケーションからを受信してもよい。さらに、MECサーバ５は、当該合計サイズとeNodeB２から受信した送信履歴とに基づいて、残りの未送信データパケットのサイズを計算する。さらにまた、MECサーバ５は、残りの未送信データパケットのサイズと送信デッドラインとに基づいて、特定の通信イベントのデッドライン達成確率を判定する。MECサーバ５は、デッドライン達成確率が所定の閾値以下（又は閾値以上）であることを判定してもよい。あるいは、MECサーバ５は、デッドライン達成確率の履歴が徐々に低下（又は増加）する傾向を示すことを判定してもよい。MECサーバ５は、デッドライン達成確率の代わりに、デッドラインを失敗する確率（デッドライン違反確率（deadline violation probability））を判定してもよい。なお、本実施形態におけるデッドライン達成確率（又はデッドライン違反確率）の定義、及びデッドライン達成確率（又はデッドライン違反確率）の計算の具体例は、第１の実施形態で説明したものと同様であるから、ここでは重複説明を省略する。

本実施形態によれば、第１及び第２の実施形態と同様に、eNodeB２によるパケットスケジューリングをMECアプリケーションの通信に適応させることができる。

最後に、上述の複数の実施形態に係るMECサーバ５及びeNodeB２の構成例について説明する。図１４は、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のためのソフトウェアモジュール群１４０４〜１４０７と、通信モジュール１４０８及びコントローラ・モジュール１４０９を格納するために使用される。仮想化管理（virtualization management）ソフトウェア１４０４は、プロセッサ１４０２において実行され、ネットワークインターフェース１４０１、プロセッサ１４０２、及びメモリ１４０３を含むハードウェア・コンポーネントを仮想化し、Infrastructure as a Service（IaaS）又はPlatform as a Service（PaaS）機能（facility）を提供し、これによりアプリケーションのためのホスティング環境を提供する。

アプリケーション・プラットフォーム・サービス（application platform services）ソフトウェア１４０５は、プロセッサ１４０２において実行され、通信サービス、無線ネットワーク情報サービス、トラフィックオフロード機能などのミドルウェア・サービスをアプリケーションに提供する。

アプリケーション・プラットフォーム・サービス・ソフトウェア１４０５は、仮想化S/P-GWソフトウェアモジュール１４０６を含んでもよい。仮想化S/P-GWソフトウェアモジュール１４０６は、仮想化管理ソフトウェア１４０４によって提供されるホスティング環境を使用し、S-GW又はP-GW又はこれら両方の機能を提供する。

１又は複数のアプリケーション１４０７は、MECサーバ５上にホストされたMECアプリケーションである。１又は複数のアプリケーション１４０７は、アプリケーション・プラットフォーム・サービス・ソフトウェア１４０５又は通信モジュール１４０８によって提供される通信サービスを利用してUE１と通信する。

通信モジュール１４０８は、プロセッサ１４０２において実行され、上述の実施形態に係るRANノード（e.g., eNodeB２）との通信サービスをMECアプリケーション１４０７及びコントローラ・モジュール１４０８に適用する。例えば、プロセッサ１４０２は、通信モジュール１４０８を実行することにより、図１０に示されたeNodeBインタフェース１００３として動作することができる。幾つかの実装において、通信モジュール１４０８は、アプリケーション・プラットフォーム・サービス・ソフトウェア１４０５に含まれてもよい。

コントローラ・モジュール１４０９は、プロセッサ１４０２において実行されることにより、上述の実施形態に係るMECサーバ５の制御を提供する。例えば、プロセッサ１４０２は、コントローラ・モジュール１４０９を実行することにより、図１０に示されたコントローラ１００２として動作することができる。

図１５は、上述の実施形態に係るeNodeB２の構成例を示すブロック図である。図１５を参照すると、eNodeB２は、RFトランシーバ１５０１、ネットワークインターフェース１５０３、プロセッサ１５０４、及びメモリ１５０５を含む。RFトランシーバ１５０１は、UE１と通信するためにアナログRF信号処理を行う。RFトランシーバ１５０１は、複数のトランシーバを含んでもよい。RFトランシーバ１５０１は、アンテナ１５０２及びプロセッサ１５０４と結合される。幾つかの実装において、RFトランシーバ１５０１は、変調シンボルデータ（又はOFDMシンボルデータ）をプロセッサ１５０４から受信し、送信RF信号を生成し、送信RF信号をアンテナ１５０２に供給する。また、RFトランシーバ１５０１は、アンテナ１５０２によって受信された受信ＲＦ信号に基づいてベースバンド受信信号を生成し、これをプロセッサ１５０４に供給する。なお、上述したように、eNodeB２は、C-RANアーキテクチャで使用されるBBU（REC）であってもよい。この場合、eNodeB２は、RFトランシーバ１５０１を有していなくてもよい。

ネットワークインターフェース１５０３は、ネットワークノード（e.g., MME及びS/P-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サーバ５との通信を行うことができる。プロセッサ１５０４は、スケジューラ・モジュール１５０７を読みだして実行することで、DLスケジューラ及びULスケジューラとして動作することができる。プロセッサ１５０４は、コントローラ・モジュール１５０８を読み出して実行することで、上述の実施形態に係る送信デッドラインに基づく各種の制御を提供する。例えば、プロセッサ１５０４は、コントローラ・モジュール１５０８を実行することにより、図５に示されたコントローラ５２２又は図９に示されたコントローラ９２２として動作することができる。

図１４及び図１５を用いて説明したように、上述の実施形態に係るMECサーバ５及びeNodeB２が有するプロセッサの各々は、図面を用いて説明されたアルゴリズムをコンピュータに行わせるための命令群を含む１又は複数のプログラムを実行する。このプログラムは、様々なタイプの非一時的なコンピュータ可読媒体（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）によってコンピュータに供給されてもよい。一時的なコンピュータ可読媒体の例は、電気信号、光信号、及び電磁波を含む。一時的なコンピュータ可読媒体は、電線及び光ファイバ等の有線通信路、又は無線通信路を介して、プログラムをコンピュータに供給できる。

＜その他の実施形態＞
上述の実施形態は、各々独立に実施されてもよいし、適宜組み合わせて実施されてもよい。

上述の第１及び第２の実施形態では、UE１のアプリケーション・レイヤとMECアプリケーションとの間の通信イベントで送信される複数のデータパケットの合計サイズ及び送信デッドラインを、MECサーバ５がeNodeB２に通知する例を示した。これに代えて、別の実施形態では、MECサーバ５とは異なる他の外部ノードが、当該合計サイズ及び送信デッドラインをeNodeB２に通知してもよい。さらに別の実施形態では、MECサーバ５とは異なる他の外部ノードが、eNodeB２から送信履歴（１３０１）を受信し、制御要求（１３０２）をeNodeB２に送信してもよい。

上述の第１〜第３の実施形態に係る通信イベントは、UE１のアプリケーション・レイヤとMECアプリケーションとの通信でなくてもよい。言い換えると、上述の実施形態に係る通信イベントは、MECサーバ５ではない他の外部サーバとUE１のアプリケーションとの間の通信イベントであってもよい。外部サーバは、例えば、アプリケーションサーバ、Machine-to-Machine（M2M）サービスプラットフォーム内のエンティティ、又はCellular IoT（CIoT）サービスプラットフォーム内のエンティティであってもよい。

既に説明したように、上述の実施形態は、LTE及びLTE-Advanced以外の他のモバイル通信ネットワークに適用されてもよい。例えば、上述の実施形態が3GPP UMTSに適用される場合、MECサーバ５は、RANノード又は無線基地局としてのRNCと直接的に通信できるように配置されてもよい。幾つかの実装において、MECサーバ５は、RNCと物理的に統合されてもよい。幾つかの実装において、MECサーバ５は、RNCと同じ建物（サイト）に配置され、RNCと通信できるように当該サイト内のLANに接続されてもよい。上述の実施形態は、現在のLTE及びLTE-Advancedの発展（3GPP LTE-Advanced Pro 、LTE+、又はenhanced LTE（eLTE））の通信ネットワークに適用されてもよい。この場合、eNodeB２は、3GPP LTE-Advanced Pro 、LTE+、又はenhanced LTE（eLTE）の基地局であってもよい。さらに、eNodeB２は、3GPP Release 14として標準化される予定の新たな5Gエア・インタフェース（新たなRadio Access Technology（RAT））を提供する基地局であってもよい。

上述した実施形態は本件発明者により得られた技術思想の適用に関する例に過ぎない。すなわち、当該技術思想は、上述した実施形態のみに限定されるものではなく、種々の変更が可能であることは勿論である。

例えば、上記の実施形態の一部又は全部は、以下の付記のようにも記載され得るが、以下には限られない。

（付記１）
無線アクセスネットワークノードであって、
メモリと、
前記メモリに結合され、複数のモジュールを実行するよう構成された少なくとも１つのプロセッサと、
を備え、
前記複数のモジュールは、
外部ノードと通信するよう構成された通信モジュールと、
第１の無線端末を含む複数の無線端末の各々のためのデータバッファからのデータセグメントのダウンリンク送信又はアップリンク送信をスケジュールするよう構成されたスケジューラと、ここで、前記第１の無線端末のための前記データバッファは、前記第１の無線端末又は前記無線アクセスネットワークノードに到着した各データパケットから生成される１又はそれ以上の送信されるためのデータセグメントを格納する、；
を備え、
前記通信モジュールは、前記第１の無線端末の第１の通信イベントに関する送信履歴を前記外部ノードに送信するよう構成され、
前記通信モジュールは、前記通信モジュール、前記スケジューラ、前記データバッファ、及び前記第１の無線端末のうち少なくとも１つに対する制御要求を前記外部ノードから受信するよう構成されている、
無線アクセスネットワークノード。

（付記２）
前記制御要求は、前記第１の通信イベントで送信される複数のデータパケットの送信が送信デッドラインまでに完了する見込みの低下に応答して送信され、
前記制御要求は、前記複数のデータパケットから生成されたデータセグメントの破棄を前記データバッファに要求する、
付記１に記載の無線アクセスネットワークノード。

（付記３）
前記制御要求は、前記第１の通信イベントで送信される複数のデータパケットの送信が送信デッドラインまでに完了する見込みの低下又は増加に応答して送信され、
前記制御要求は、前記スケジューラによって考慮される第１のパラメータ又は前記スケジューラに適用されるスケジューリング戦略の変更を前記スケジューラに要求する、
付記１又は２に記載の無線アクセスネットワークノード。

（付記４）
前記第１のパラメータは、前記第１の無線端末又は他の無線端末に関係する、端末優先度レベル、Quality of Service（QoS）パラメータ、遅延閾値、及びデータ送信ボリュームのうち少なくとも１つを含む、
付記３に記載の無線アクセスネットワークノード。

（付記５）
前記制御要求は、前記第１の通信イベントで送信される複数のデータパケットの送信が送信デッドラインまでに完了する見込みの低下に応答して送信され、
前記制御要求は、前記第１の無線端末への割り当て無線リソースを増やす又は他の無線端末への割り当て無線リソースを減らすことを前記スケジューラに要求する、
付記１〜４のいずれか１項に記載の無線アクセスネットワークノード。

（付記６）
前記制御要求は、前記第１の通信イベントに関する特定の無線ベアラ又は論理チャネルへの割り当て無線リソースを調整するために、前記第１の無線端末におけるLogical Channel Prioritization（LCP）手順において使用される第２のパラメータの変更を要求する、
付記１〜５のいずれか１項に記載の無線アクセスネットワークノード。

（付記７）
前記第２のパラメータは、論理チャネル優先度、Prioritized Bit Rate（PBR）、及びBucket Size Duration（BSD）のうち少なくとも１つを含む、
付記６に記載の無線アクセスネットワークノード。

（付記８）
前記外部ノードは、モバイル・エッジ・コンピューティング（MEC）サーバである、
付記１〜７のいずれか１項に記載の無線アクセスネットワークノード。

（付記９）
前記第１の通信イベントは、前記第１の無線端末のアプリケーション・レイヤと前記MECサーバにホストされたMECアプリケーションとの間の通信イベントである、
付記８に記載の無線アクセスネットワークノード。

（付記１０）
無線アクセスネットワークノードにおける方法であって、
第１の無線端末の第１の通信イベントに関する送信履歴を、外部ノードに送信すること、及び
前記無線アクセスネットワークノード内の前記外部ノードと通信するための通信モジュール、前記無線アクセスネットワークノード内のスケジューラ、前記無線アクセスネットワークノード又は前記第１の無線端末に配置されるデータバッファ、及び前記第１の無線端末のうち少なくとも１つに対する制御要求を前記外部ノードから受信すること、
を備える、方法。

（付記１１）
外部ノードであって、
メモリと、
前記メモリに結合され、無線アクセスネットワークノードと通信するよう構成された通信モジュールを含む複数のモジュールを実行するよう構成された少なくとも１つのプロセッサと、
を備え、
前記通信モジュールは、第１の無線端末の第１の通信イベントに関する送信履歴を無線アクセスネットワークノードから受信するよう構成され、前記無線アクセスネットワークノード内の前記外部ノードと通信するためのモジュール、前記無線アクセスネットワークノード内のスケジューラ、前記無線アクセスネットワークノード又は前記第１の無線端末に配置されるデータバッファ、及び前記第１の無線端末のうち少なくとも１つに対する制御要求を前記無線アクセスネットワークノードに送信するよう構成されている、
外部ノード。

（付記１２）
前記通信モジュールは、前記第１の通信イベントで送信される複数のデータパケットの送信が送信デッドラインまでに完了する見込みの低下に応答して、前記制御要求を送信するよう構成され、
前記制御要求は、前記複数のデータパケットから生成されたデータセグメントの破棄を前記データバッファに要求する、
付記１１に記載の外部ノード。

（付記１３）
前記通信モジュールは、前記第１の通信イベントで送信される複数のデータパケットの送信が送信デッドラインまでに完了する見込みの低下又は増加に応答して、前記制御要求を送信するよう構成され、
前記制御要求は、前記スケジューラによって考慮される第１のパラメータ又は前記スケジューラに適用されるスケジューリング戦略の変更を前記スケジューラに要求する、
付記１１又は１２に記載の外部ノード。

（付記１４）
前記第１のパラメータは、前記第１の無線端末又は他の無線端末に関係する、端末優先度レベル、Quality of Service（QoS）パラメータ、遅延閾値、及びデータ送信ボリュームのうち少なくとも１つを含む、
付記１３に記載の外部ノード。

（付記１５）
前記通信モジュールは、前記第１の通信イベントで送信される複数のデータパケットの送信が送信デッドラインまでに完了する見込みの低下に応答して、前記制御要求を送信するよう構成され、
前記制御要求は、前記第１の無線端末への割り当て無線リソースを増やす又は他の無線端末への割り当て無線リソースを減らすことを前記スケジューラに要求する、
付記１１〜１４のいずれか１項に記載の外部ノード。

（付記１６）
前記制御要求は、前記第１の通信イベントに関する特定の無線ベアラ又は論理チャネルへの割り当て無線リソースを調整するために、前記第１の無線端末におけるLogical Channel Prioritization（LCP）手順において使用される第２のパラメータの変更を要求する、
付記１１〜１５のいずれか１項に記載の外部ノード。

（付記１７）
前記第２のパラメータは、論理チャネル優先度、Prioritized Bit Rate（PBR）、及びBucket Size Duration（BSD）のうち少なくとも１つを含む、
付記１６に記載の外部ノード。

（付記１８）
前記複数のモジュールは、前記第１の通信イベントで送信される複数のデータパケットの合計サイズ及び前記第１の無線端末に関する送信履歴から導かれる残りの未送信データパケットのサイズと前記複数のデータパケットの送信デッドラインとに基づいて、前記制御要求を送信するか否かを決定するコントローラをさらに含む、
付記１１〜１７のいずれか１項に記載の外部ノード。

（付記１９）
前記第１の通信イベントは、前記第１の無線端末のアプリケーション・レイヤの通信イベントである、
付記１１〜１８のいずれか１項に記載の外部ノード。

（付記２０）
前記外部ノードは、モバイル・エッジ・コンピューティング（MEC）サーバである、
付記１１〜１９のいずれか１項に記載の外部ノード。

（付記２１）
外部ノードにおける方法であって、
第１の無線端末の第１の通信イベントに関する送信履歴を無線アクセスネットワークノードから受信すること、及び
前記無線アクセスネットワークノード内の前記外部ノードと通信するためのモジュール、前記無線アクセスネットワークノード内のスケジューラ、前記無線アクセスネットワークノード又は前記第１の無線端末に配置されるデータバッファ、及び前記第１の無線端末のうち少なくとも１つに対する制御要求を前記無線アクセスネットワークノードに送信すること、
を備える、方法。

（付記２２）
無線アクセスネットワークノードにおける方法をコンピュータに行わせるためのプログラムであって、
前記方法は、
第１の無線端末の第１の通信イベントに関する送信履歴を、外部ノードに送信すること、及び
前記無線アクセスネットワークノード内の前記外部ノードと通信するための通信モジュール、前記無線アクセスネットワークノード内のスケジューラ、前記無線アクセスネットワークノード又は前記第１の無線端末に配置されるデータバッファ、及び前記第１の無線端末のうち少なくとも１つに対する制御要求を前記外部ノードから受信すること、
を備える、
プログラム。

（付記２３）
外部ノードにおける方法をコンピュータに行わせるためのプログラムであって、
前記方法は、
第１の無線端末の第１の通信イベントに関する送信履歴を無線アクセスネットワークノードから受信すること、及び
前記無線アクセスネットワークノード内の前記外部ノードと通信するためのモジュール、前記無線アクセスネットワークノード内のスケジューラ、前記無線アクセスネットワークノード又は前記第１の無線端末に配置されるデータバッファ、及び前記第１の無線端末のうち少なくとも１つに対する制御要求を前記無線アクセスネットワークノードに送信すること、
を備える、
プログラム。

この出願は、２０１６年３月３１日に出願された日本出願特願２０１６−０７２４２２を基礎とする優先権を主張し、その開示の全てをここに取り込む。

１ UE
２ eNodeB
３ 無線アクセスネットワーク
４ コアネットワーク
５ MECサーバ
５０３ ダウンリンク・スケジューラ
５２１ MECインタフェース
５２２ コントローラ
９０３ アップリンク・スケジューラ
９２１ MECインタフェース
９２２ コントローラ
１００２ コントローラ
１００３ eNodeBインタフェース
１４０５ アプリケーション・プラットフォーム・サービス・ソフトウェア
１４０８ 通信モジュール
１４０９ コントローラ・モジュール
１５０６ 通信モジュール
１５０７ スケジューラ・モジュール
１５０８ コントローラ・モジュール

Claims (10)

1. 無線アクセスネットワークノードであって、
   メモリと、
   前記メモリに結合され、複数のモジュールを実行するよう構成された少なくとも１つのプロセッサと、
   を備え、
   前記複数のモジュールは、
   外部ノードと通信するよう構成された通信モジュールと、
   第１の無線端末を含む複数の無線端末の各々のためのデータバッファからのデータセグメントのダウンリンク送信又はアップリンク送信をスケジュールするよう構成されたスケジューラと、ここで、前記第１の無線端末のための前記データバッファは、前記第１の無線端末又は前記無線アクセスネットワークノードに到着した各データパケットから生成される１又はそれ以上の送信されるためのデータセグメントを格納する、；
   を備え、
   前記通信モジュールは、前記第１の無線端末の第１の通信イベントに関する送信履歴を前記外部ノードに送信するよう構成され、
   前記通信モジュールは、前記通信モジュール、前記スケジューラ、前記データバッファ、及び前記第１の無線端末のうち少なくとも１つに対する制御要求を前記外部ノードから受信するよう構成され、
   前記制御要求は、前記第１の通信イベントで送信される複数のデータパケットの送信が送信デッドラインまでに完了する見込みの低下又は増加に応答して送信される、
   無線アクセスネットワークノード。
2. 前記制御要求は、前記第１の通信イベントで送信される複数のデータパケットの送信が前記送信デッドラインまでに完了する見込みの低下に応答して送信され、
   前記制御要求は、前記複数のデータパケットから生成されたデータセグメントの破棄を前記データバッファに要求する、
   請求項１に記載の無線アクセスネットワークノード。
3. 前記制御要求は、前記スケジューラによって考慮される第１のパラメータ又は前記スケジューラに適用されるスケジューリング戦略の変更を前記スケジューラに要求する、
   請求項１又は２に記載の無線アクセスネットワークノード。
4. 前記第１のパラメータは、前記第１の無線端末又は他の無線端末に関係する、端末優先度レベル、Quality of Service（QoS）パラメータ、遅延閾値、及びデータ送信ボリュームのうち少なくとも１つを含む、
   請求項３に記載の無線アクセスネットワークノード。
5. 前記制御要求は、前記第１の通信イベントで送信される複数のデータパケットの送信が前記送信デッドラインまでに完了する見込みの低下に応答して送信され、
   前記制御要求は、前記第１の無線端末への割り当て無線リソースを増やす又は他の無線端末への割り当て無線リソースを減らすことを前記スケジューラに要求する、
   請求項１〜４のいずれか１項に記載の無線アクセスネットワークノード。
6. 前記制御要求は、前記第１の通信イベントに関する特定の無線ベアラ又は論理チャネルへの割り当て無線リソースを調整するために、前記第１の無線端末におけるLogical Channel Prioritization（LCP）手順において使用される第２のパラメータの変更を要求する、
   請求項１〜５のいずれか１項に記載の無線アクセスネットワークノード。
7. 前記第２のパラメータは、論理チャネル優先度、Prioritized Bit Rate（PBR）、及びBucket Size Duration（BSD）のうち少なくとも１つを含む、
   請求項６に記載の無線アクセスネットワークノード。
8. 前記外部ノードは、モバイル・エッジ・コンピューティング（MEC）サーバである、
   請求項１〜７のいずれか１項に記載の無線アクセスネットワークノード。
9. 無線アクセスネットワークノードにおける方法であって、
   第１の無線端末の第１の通信イベントに関する送信履歴を、外部ノードに送信すること、及び
   前記無線アクセスネットワークノード内の前記外部ノードと通信するための通信モジュール、前記無線アクセスネットワークノード内のスケジューラ、前記無線アクセスネットワークノード又は前記第１の無線端末に配置されるデータバッファ、及び前記第１の無線端末のうち少なくとも１つに対する制御要求を前記外部ノードから受信すること、
   を備え、
   前記制御要求は、前記第１の通信イベントで送信される複数のデータパケットの送信が送信デッドラインまでに完了する見込みの低下又は増加に応答して送信される、
   方法。
10. 外部ノードであって、
    メモリと、
    前記メモリに結合され、無線アクセスネットワークノードと通信するよう構成された通信モジュールを含む複数のモジュールを実行するよう構成された少なくとも１つのプロセッサと、
    を備え、
    前記通信モジュールは、第１の無線端末の第１の通信イベントに関する送信履歴を無線アクセスネットワークノードから受信するよう構成され、
    前記通信モジュールは、前記無線アクセスネットワークノード内の前記外部ノードと通信するためのモジュール、前記無線アクセスネットワークノード内のスケジューラ、前記無線アクセスネットワークノード又は前記第１の無線端末に配置されるデータバッファ、及び前記第１の無線端末のうち少なくとも１つに対する制御要求を、前記第１の通信イベントで送信される複数のデータパケットの送信が送信デッドラインまでに完了する見込みの低下又は増加に応答して、前記無線アクセスネットワークノードに送信するよう構成されている、
    外部ノード。

Images