JP6747513B2 - 通信装置、通信システム、通信方法、及びプログラム - Google Patents

Description

本発明は通信装置、通信システム、通信方法、及びプログラムに関し、特にフローの受付制御を行う通信装置、通信システム、通信方法、及びプログラムに関する。

現在、モバイルネットワークを介した超低遅延サービスを提供することが検討されている。超低遅延サービスは、例えば、モバイルネットワークを介して車載センサー情報、交通カメラ情報、及び地図情報等を伝送する自動運転サービスであってもよい。

モバイルキャリア（モバイル通信事業者）は、ユーザに対して超低遅延サービスを提供するために、ＳＬＡ（Service Level Agreement）を保証する必要がある。ＳＬＡは、例えば、超低遅延サービスにおいて保証する遅延時間等が規定されていてもよい。

例えば、特許文献１には、ネットワークの品質を維持するために実行されるアドミッションコントロールに関する処理が記載されている。例えば、特許文献１には、受け入れ制御装置ＡＣが、現行スループットを算出することが記載されている。さらに、受け入れ制御装置は、利用可能な最大スループットと現行スループットとの差を算出することによって、現在利用可能なスループットを決定する。受け入れ制御装置は、リアルタイムのデータトラヒックにおいて要求されたスループットが、現在利用可能なスループットを上回る場合に、リアルタイムのデータトラヒックの受け入れを拒否する。また、受け入れ制御装置は、受け入れを許容したリアルタイムのデータトラヒックに対して、送信デッドラインを設定する。

特開２００７−３１２４１３号公報

特許文献１に記載されたアドミッションコントロールは、データトラヒックの受け入れ時に、スループットを比較することによって受け入れ可否を決定する。しかし、リアルタイムのデータトラヒックのそれぞれは、異なるＳＬＡが設定されることがあり、要求される品質が異なる。そのため、スループットのみを用いて受け入れ可否を決定した場合、それぞれのリアルタイムのデータトラヒックに関するＳＬＡが満たされるか否かを正確に判定できない場合があるという問題がある。

本発明の目的は、データトラヒックの受け入れ時に、スループットのみを比較するのではなく、他のパラメータも考慮して、新たなデータトラヒックの受け入れ可否を判定することができる通信装置、通信システム、通信方法、及びプログラムを提供することにある。

本発明の第１の態様にかかる通信装置は、無線端末と基地局との間において伝送されるフローであって、送信デッドラインが定められている前記フローに含まれる複数のデータパケットの送信状況に応じて、新たな無線端末に関するフローを受け付けるか否かを判定する判定部と、前記新たな無線端末に関するフローを受け付けるか否かを示す指示情報を基地局へ送信する通信部と、を備えるものである。

本発明の第２の態様にかかる通信システムは、無線端末と基地局との間において伝送されるフローであって、送信デッドラインが定められている前記フローに含まれる複数のデータパケットの送信状況に応じて、新たな無線端末に関するフローを受け付けるか否かを判定し、前記新たな無線端末に関するフローを受け付けるか否かを示す指示情報を送信する通信装置と、前記指示情報を受信し、前記指示情報に従って新たな無線端末に関するフローを受け付ける処理もしくは拒否する処理を実行する基地局と、を備えるものである。

本発明の第３の態様にかかる通信方法は、無線端末と基地局との間において伝送されるフローであって、送信デッドラインが定められている前記フローに含まれる複数のデータパケットの送信状況に応じて、新たな無線端末に関するフローを受け付けるか否かを判定し、前記新たな無線端末に関するフローを受け付けるか否かを示す指示情報を基地局へ送信するものである。

本発明の第４の態様にかかるプログラムは、無線端末と基地局との間において伝送されるフローであって、送信デッドラインが定められている前記フローに含まれる複数のデータパケットの送信状況に応じて、新たな無線端末に関するフローを受け付けるか否かを判定し、前記新たな無線端末に関するフローを受け付けるか否かを示す指示情報を基地局へ送信することをコンピュータに実行させるものである。

本発明により、データトラヒックの受け入れ時に、スループットのみを比較するのではなく、他のパラメータも考慮して、新たなデータトラヒックの受け入れ可否を判定することができる通信装置、通信システム、通信方法、及びプログラムを提供することができる。

実施の形態１にかかる通信システムの構成図である。 実施の形態２にかかる通信システムの構成図である。 実施の形態２にかかるＭＥＣサーバの構成図である。 実施の形態２にかかるｅＮＢの構成図である。 実施の形態２にかかるＵＥの構成図である。 実施の形態２にかかるＭＥＣサーバがｅＮＢから無線リソースの通信品質を取得する処理の流れを示す図である。 実施の形態２にかかるWcqNotificationSetupメッセージに設定されるパラメータを示す図である。 実施の形態２にかかるWcqNotificationメッセージに設定されるパラメータを示す図である。 実施の形態２にかかるWcqNotificationメッセージに設定されるWcqValueを示す図である。 実施の形態２にかかるＭＥＣサーバがｅＮＢからスケジューラータイプを取得する処理の流れを示す図である。 実施の形態２にかかるSchedulingPolicyRequestメッセージに設定されるパラメータを示す図である。 実施の形態２にかかるSchedulingPolicyResponseメッセージに設定されるパラメータを示す図である。 実施の形態２にかかるＭＥＣサーバがｅＮＢからバッファサイズを取得する処理の流れを示す図である。 実施の形態２にかかるRemainBufferSizeSetupメッセージに設定されるパラメータを示す図である。 実施の形態２にかかるRemainBufferSizeNotificationメッセージに設定されるパラメータを示す図である。 実施の形態２にかかるRemainBufferSizeNotificationメッセージに設定されるRemainBuffeｒSizeを示す図である。 実施の形態２にかかるフローの追加を許可するか否かを判定する処理の流れを示す図である。 各実施の形態のｅＮＢの構成図である。 各実施の形態のＵＥの構成図である。 各実施の形態のＭＥＣサーバの構成図である。

（実施の形態１）
以下、図面を参照して本発明の実施の形態について説明する。図１を用いて本発明の実施の形態１にかかる通信システムの構成例について説明する。図１の通信システムは、通信装置１０、基地局２０、及び複数の無線端末３０を有している。通信装置１０、基地局２０、及び無線端末３０は、プロセッサがメモリに格納されたプログラムを実行することによって動作するコンピュータ装置であってもよい。

無線端末３０は、携帯電話端末、スマートフォン端末、もしくはタブレット型端末等であってもよい。もしくは、無線端末３０は、ＩｏＴ（Internet of Things）サービスに用いられるＩｏＴ端末、Ｍ２Ｍ（Machine to Machine）端末、もしくはＭＴＣ（Machine Type Communication）端末等であってもよい。無線端末３０は、基地局２０と無線通信を行う。

基地局２０は、３ＧＰＰ（3rd Generation Partnership Project）において規定されているｅＮＢ（evolved Node B）もしくはＮｏｄｅ Ｂであってもよい。ｅＮＢは、無線通信方式として、ＬＴＥ（Long Term Evolution）を用いる基地局である。Ｎｏｄｅ Ｂは、無線通信方式として、３ＧＰＰにおいて３Ｇと称される無線通信方式を用いる基地局である。また、基地局２０は、３ＧＰＰにおいて規定されている無線通信方式に制限されず、他の標準間団体において規定されている無線通信方式を用いてもよい。基地局２０は、無線アクセスネットワークノード等と称されてもよい。

通信装置１０は、基地局２０を制御する装置である。例えば、通信装置１０は、基地局２０において実行されるスケジューリングに関する制御を実施してもよい。基地局２０において実行されるスケジューリングは、ＭＡＣ（Medium Access Control）スケジューリング、もしくはパケットスケジューリング等と称されてもよい。

通信装置１０は、例えば、３ＧＰＰにおいて規定されているＳＣＥＦ（Service Capability Exposure Function）エンティティ（以下、ＳＣＥＦと称する）であってもよい。ＳＣＥＦは、例えば、モバイル通信事業者もしくはアプリケーションサービスプロバイダー等が管理するアプリケーションサーバに関する認証処理等を実行する。また、ＳＣＥＦは、３ＧＰＰにおいて定められたリファレンスポイントを介してｅＮＢである基地局２０と通信する。ＳＣＥＦは、例えば、コアネットワーク内において、制御データを伝送する。制御データは、例えば、無線端末３０に関するユーザデータを伝送する通信経路の設定等を行うために用いられる。ＳＣＥＦは、例えば、制御データを伝送するノード装置であるＣＰＦ（C-Plane Function）エンティティと称されてもよい。

また、通信装置１０は、ＭＥＣ（Mobile Edge Computing）サーバであってもよい。ＭＥＣサーバは、基地局２０と直接的に通信できる位置に配置されてもよい。直接的に通信できる位置とは、モバイル通信事業者が管理するコアネットワークを介することなく通信することができる位置である。例えば、ＭＥＣサーバは、基地局２０と物理的に統合されてもよい。もしくは、ＭＥＣサーバは、基地局２０と同じ建物に配置され、基地局２０と通信できるように、建物内のＬＡＮ（Local Area Network）に接続されてもよい。ＭＥＣサーバは、基地局２０の近傍に配置されることによって、無線端末３０との間の伝送遅延を短くすることができる。ＭＥＣサーバは、例えば、超低遅延のアプリケーションサービスを提供するために用いられる。

また、通信装置１０は、無線端末３０へＩｏＴサービスを提供するサーバ群を有するＩｏＴプラットフォーム内に配置されてもよい。もしくは、通信装置１０は、基地局２０と直接もしくはネットワークを介して通信することができるサーバ装置であってもよい。通信装置１０は、上記で例示した装置である場合であってもその他の装置であっても、ＣｏｎｔｒｏｌＰｌａｎｅおよびＵｓｅｒＰｌａｎｅいずれの機能を有していてもよい。

続いて、通信装置１０の構成例について説明する。通信装置１０は、判定部１１及び通信部１２を有している。判定部１１及び通信部１２は、プロセッサがメモリに格納されたプログラムを実行することによって処理が実行されるソフトウェアもしくはモジュールであってもよい。また、判定部１１及び通信部１２は、チップもしくは回路等のハードウェアであってもよい。

判定部１１は、無線端末３０と基地局２０との間において伝送されるフローであって、送信デッドラインが定められているフローに含まれる複数のデータパケットの送信状況に応じて、新たな無線端末３０に関するフローを受け付けるか否かを判定する。

無線端末３０と基地局２０との間において伝送されるフローは、例えば、無線端末３０に提供されるアプリケーションサービスにおいて伝送される１又は複数のデータパケットを含む。データパケットは、データと称されてもよい。

無線端末３０と基地局２０との間において伝送されるフローは、無線端末３０から基地局２０へ送信されるフローもしくは基地局２０から無線端末３０へ送信されるフローであってもよい。もしくは、無線端末３０と基地局２０との間において伝送されるフローは、無線端末３０から基地局２０へ送信されるフロー及び基地局２０から無線端末３０へ送信されるフローを含んでもよい。無線端末３０から基地局２０へ送信されるフローに含まれるデータを、ＵＬ（Uplink）データと称する。また、基地局２０から無線端末３０へ送信されるフローに含まれるデータを、ＤＬ（Downlink）データと称する。アプリケーションサービスにおいて伝送されるデータは、例えば、画像データもしくは動画データ等であってもよい。また、アプリケーションデータには、画像データ等の送信を要求する要求メッセージもしくは要求メッセージに応答する応答メッセージ等が含まれてもよい。

送信デッドラインは、１回のフローに含まれる複数のデータパケットの送信を完了するべき期限を意味する。送信デッドラインは、アプリケーションによって要求される。送信デッドラインは、送信期限と言うこともできる。あるいは、送信デッドラインは、アプリケーションによって許容される最大送信遅延と言うこともできる。送信デッドラインは、様々に定義することができる。例えば、送信デッドラインは、アプリケーション・レイヤの発信者（sender）による送信の完了期限を示してもよい。あるいは、送信デッドラインは、無線レイヤの発信者による送信の完了期限を示してもよい。あるいは、送信デッドラインは、アプリケーション・レイヤの受信者（receiver）による受信の完了期限を示してもよい。あるいは、送信デッドラインは、無線レイヤの受信者による受信の完了期限を示してもよい。あるいは、より具体的に、送信デッドラインは、アプリケーションレイヤの発信者（sender）が１回のフローに関する最初のデータパケットを送信開始してからアプリケーションレイヤの受信者（receiver）が１回のフローに関する最後のデータパケットを受信完了する期限を示してもよい。あるいは、また、送信デッドラインは、無線レイヤの発信者が１回のフローに関する最初のデータパケットを送信開始してから無線レイヤの受信者が１回のフローに関する最後のデータパケットを受信完了する期限を示してもよい。送信デッドラインに関する情報は、ＭＥＣサーバがアプリケーションサーバから受信してもよい。ＭＥＣサーバは、ＭＥＣサーバのユーザープレーンに届くデータについて、そのデータに適用されるサービスを判断し、そのサービスに基づいて送信デッドラインを判断してもよい。またＭＥＣサーバは、アプリケーションサーバから、データに適用されるサービスの情報を受信し、そのサービスに基づいて送信デッドラインを判断してもよい。

送信状況は、例えば、フローに含まれる複数のデータパケットのうち、未送信のデータパケット量、バッファサイズ、もしくはフローに含まれるすべてのデータパケットを送信デッドラインまでに送信可能か否か、等を示す情報であってもよい。

通信部１２は、新たな無線端末に関するフローを受け付けるか否かを示す指示情報を基地局２０へ送信する。基地局２０は、通信装置１０の判定部１１において判定された判定結果に従って、新たな無線端末に関するフローの受付処理を実行する。言い換えると、基地局２０は、通信装置１０から送信された判定結果に従って、新たな無線端末３０に関するスケジューリングを行う。

以上説明したように、図１の通信装置１０は、送信デッドラインまでの時間を考慮したデータパケットの送信状況に応じて、新たな無線端末に関するフローを受け付けるか否かを判定することができる。言い換えると、基地局２０は、既存のフローに関する送信デッドラインを満たすことができているか否かとするサービス品質に応じて、新たな無線端末に関するフローを受け付けるか否かを判定することができるため、基地局２０におけるサービス品質の維持もしくは向上を図ることができる。

（実施の形態２）
続いて、図２を用いて本発明の実施の形態２にかかる通信システムの構成例について説明する。図２の通信システムは、３ＧＰＰにおいて規定されている通信システムを示している。図２の通信システムは、ｅＮＢ６０、アプリケーションサーバ７０、コアネットワーク１００、及び複数のＵＥ８０を有している。ＵＥ８０は、３ＧＰＰにおいて用いられる通信端末の総称である。コアネットワーク１００は、モバイル通信事業者が管理するネットワークである。コアネットワーク１００は、ＭＥＣサーバ４０及びゲートウェイ５０を有している。

ゲートウェイ５０は、例えば、コアネットワーク１００内において、ＵＥ８０に関するユーザデータを伝送するＳＧＷ（Serving Gateway）もしくはＰＧＷ（Packet Data Network Gateway）であってもよい。もしくは、ゲートウェイ５０は、ＵＥ８０に関するユーザデータを伝送するノード装置である、ＵＰＦ（U-Plane Function）エンティティであってもよい。ユーザデータは、例えば、画像データもしくは動画データ等であってもよい。

ＭＥＣサーバ４０は、例えば、コアネットワーク１００内において、制御データを伝送する。制御データは、例えば、ＵＥ８０に関するユーザデータを伝送する通信経路の設定等を行うために用いられる。ＭＥＣサーバ４０は、例えば、制御データを伝送するノード装置であるＣＰＦ（C-Plane Function）エンティティと称されてもよい。

アプリケーションサーバ７０は、ＵＥ８０へアプリケーションサービスを提供するサーバである。アプリケーションサーバ７０は、例えば、ユーザデータをゲートウェイ５０へ送信する。また、アプリケーションサーバ７０は、１回のフローにおいて送信するユーザデータのデータサイズ（フローサイズ）、さらに、１回のフローにおける送信デッドラインに関する情報等をＭＥＣサーバ４０へ送信する。

ゲートウェイ５０は、アプリケーションサーバ７０から送信されたユーザデータをｅＮＢ６０へ送信する。また、ゲートウェイ５０は、ｅＮＢ６０から送信されたユーザデータをアプリケーションサーバ７０へ送信する。

ＭＥＣサーバ４０は、アプリケーションサーバ７０から送信された情報と、ｅＮＢ６０から送信されたデータパケットの送信状況とを用いて、ｅＮＢ６０において新たな無線端末に関するフローを受け付けるか否かを判定する。ＭＥＣサーバ４０は、フローの受付に関する判定結果をｅＮＢ６０へ送信する。

ｅＮＢ６０は、ＭＥＣサーバ４０から送信されたフローの受付に関する判定結果を用いて、ＵＥ８０から要求されるフローを受け付ける処理もしくはフローを拒絶する処理を実行する。

続いて、図３を用いて実施の形態２にかかるＭＥＣサーバ４０の構成例について説明する。ＭＥＣサーバ４０は、スケジューリング制御部４１、受付判定部４２、及びｅＮＢ通信部４３を有している。スケジューリング制御部４１、受付判定部４２、及びｅＮＢ通信部４３は、プロセッサがメモリに格納されたプログラムを実行することによって処理が実行されるソフトウェアもしくはモジュールであってもよい。または、スケジューリング制御部４１、受付判定部４２、及びｅＮＢ通信部４３は、チップもしくは回路等のハードウェアであってもよい。

スケジューリング制御部４１は、ｅＮＢ６０において実行されるＭＡＣスケジューリングを模擬する（emulate）ことによって、ｅＮＢ６０において処理される各フローが、送信デッドラインまでに完了するか否かを判定する。各フローが送信デッドラインまでに完了するとは、各フローに含まれる複数のデータパケットが送信デッドラインまでにすべて送信されることである。スケジューリング制御部４１は、例えば、ＵＥ８０もしくはｅＮＢ６０において測定された無線リソースの通信品質を用いて、ＭＡＣスケジューリングを模擬する。スケジューリング制御部４１におけるＭＡＣスケジューリングを模擬した処理については後に詳述する。スケジューリング制御部４１は、ｅＮＢ６０において処理される各フローが、送信デッドラインまでに完了するか否かを判定した判定結果を受付判定部４２へ出力する。

また、スケジューリング制御部４１は、ＵＥ８０もしくはｅＮＢ６０において測定された無線リソースの通信品質を用いて、将来の無線リソースに関する通信品質を推定する。通信品質は、例えば、ＣＱＩ（Channel Quality Indicator）であってもよく、その他の品質を示す情報であってもよい。

スケジューリング制御部４１は、例えば、過去に取得した無線リソースの通信品質の傾向、もしくは統計情報を用いて、将来の無線リソースに関する通信品質を推定する。例えば、スケジューリング制御部４１は、過去に取得した無線リソースの通信品質が向上している傾向にある場合、将来の無線リソースに関する通信品質も向上していると推定してもよい。また、スケジューリング制御部４１は、過去に取得した無線リソースの通信品質が低下している傾向にある場合、将来の無線リソースに関する通信品質も低下していると推定してもよい。

受付判定部４２は、スケジューリング制御部４１から出力された判定結果を用いて、ｅＮＢ６０において新たなＵＥ８０に関するフローを受け付けるか否かを判定する。例えば、受付判定部４２は、ｅＮＢ６０において処理される複数のフローのうち、一つでも送信デッドラインまでに完了しないフローが存在する場合、新たなＵＥ８０に関するフローの受付を拒否してもよい。言い換えると、受付判定部４２は、ｅＮＢ６０において処理される全てのフローが送信デッドラインまでに完了する場合、ＵＥ８０に関するフローの受付を許可してもよい。また、受付判定部４２は、ｅＮＢ６０において処理される複数のフローのうち、送信デッドラインまでに完了しないフローが、予め定められた閾値を超えている場合に、新たなＵＥ８０に関するフローの受付を拒否してもよい。さらに受付判定部４２は、フローの受付を拒否するＵＥ８０の数や割合を予め定めて、新たなＵＥ８０に関するフローを受け付けるか否かの判定に用いてもよい。

ｅＮＢ通信部４３は、新たなＵＥ８０に関するフローを受け付けるか否かを示す指示情報をｅＮＢ６０へ送信する。

続いて、図４を用いて実施の形態２にかかるｅＮＢ６０の構成例について説明する。ｅＮＢ６０は、コアネットワークノード通信部６１、無線環境取得部６２、受付制御部６３、及び無線部６４を有している。コアネットワークノード通信部６１、無線環境取得部６２、受付制御部６３、及び無線部６４は、プロセッサがメモリに格納されたプログラムを実行することによって処理が実行されるソフトウェアもしくはモジュールであってもよい。また、コアネットワークノード通信部６１、無線環境取得部６２、受付制御部６３、及び無線部６４は、チップもしくは回路等のハードウェアであってもよい。

無線環境取得部６２は、ＵＥ８０から無線部６４を介して受信したＵＬデータを用いて、ＵＬデータを伝送する無線リソースの通信品質を測定する。また、無線環境取得部６２は、ＵＥ８０においてＤＬデータを用いて測定されたＤＬデータを伝送する無線リソースの通信品質を、ＵＥ８０から受信する。無線環境取得部６２は、ＵＥ８０から無線部６４を介してＤＬデータを伝送する無線リソースの通信品質に関する情報を受信する。

無線環境取得部６２は、ＵＬ及びＤＬデータを送信する無線リソースの通信品質を、コアネットワークノード通信部６１を介してＭＥＣサーバ４０へ送信する。

受付制御部６３は、コアネットワークノード通信部６１を介してＭＥＣサーバ４０から送信された新たなＵＥ８０に関するフローを受け付けるか否かを示す指示情報を受信する。受付制御部６３は、受信した指示情報を用いて、新たなＵＥ８０に関するフローの受付処理もしくは拒絶処理を実施する。ＵＥ８０に関するフローの拒絶処理は、例えば、一時的にＵＥ８０に関するフローの受付を拒絶し、所定期間経過後にＵＥ８０に関するフローを受け付ける受付処理を実行することを含んでもよい。もしくは、ＵＥ８０に関するフローの拒絶処理は、ＵＥ８０に関するフローを受け付けた後に、所定期間、ＵＥ８０に無線リソースの割当を行わないことを含んでもよい。ここで、フローの受付を拒絶されたＵＥ８０は、拒絶されたフローのデータパケットを廃棄してもよい。ＵＥ８０は、discard timerを用いて、受付を拒絶されたフローのデータパケットを廃棄してもよい。

無線部６４は、ＭＡＣスケジューリングの結果、ＵＥ８０へ割り当てられた無線リソースを用いて、ＵＥ８０と無線通信を行う。ＭＡＣスケジューリングは、例えば、ＰＦ（Proportional Fairness）、ＲＲ（Round Robin）もしくはＭＴ（Maximum Throughput）等の方式もしくはスケジューラータイプが用いられてもよい。

続いて、図５を用いて実施の形態２にかかるＵＥ８０の構成例について説明する。ＵＥ８０は、無線部８１及び無線環境測定部８２を有している。無線部８１及び無線環境測定部８２は、プロセッサがメモリに格納されたプログラムを実行することによって処理が実行されるソフトウェアもしくはモジュールであってもよい。または、無線部８１及び無線環境測定部８２は、チップもしくは回路等のハードウェアであってもよい。

無線環境測定部８２は、ｅＮＢ６０から送信されたＤＬデータを用いてＤＬデータを伝送する無線リソースの通信品質を測定する。無線環境測定部８２は、無線部８１を介してＤＬデータを伝送する無線リソースの通信品質をｅＮＢ６０へ送信する。

続いて、図６を用いて、ＭＥＣサーバ４０がｅＮＢ６０から無線リソースの通信品質を取得する処理の流れについて説明する。はじめに、ＭＥＣサーバ４０は、無線リソースの通信品質を取得するために、ｅＮＢ６０へリクエストメッセージを送信する（Ｓ１１）。具体的には、ＭＥＣサーバ４０は、WcqNotificationSetupメッセージをｅＮＢ６０へ送信する。ＷＣＱ（Wireless Channel Quality）は、無線リソースの通信品質を示す。ＷＣＱは、例えば、ＣＱＩ、信号レベル、もしくはノイズレベル等の情報であってもよい。信号レベル及びノイズレベルに関する情報は、例えば、信号の強度及びノイズの強度等を示す情報であってもよい。また、ＷＣＱは、信号レベル及びノイズレベルを用いて示されるＳＩＮＲ（Signal to Interference plus Noise power Ratio）であってもよい。WcqNotificationSetupメッセージには、図７に示されるパラメータが設定される。

例えば、WcqNotificationSetupメッセージには、送信先のｅＮＢ６０を示すeNB ID、送信元のＭＥＣサーバ４０を示すＭＥＣサーバ IDが設定される。さらに、ＭＥＣサーバ４０が取得を希望するＷＣＱが、ＵＬの無線リソースに関するＷＣＱか、ＤＬの無線リソースに関するＷＣＱか、もしくはＵＬ及びＤＬの無線リソースに関するＷＣＱか、を示すDirectionが設定される。また、WcqNotificationSetupメッセージには、送信間隔を示すNotificationIntervalが設定されてもよい。

図６に戻り、次に、ｅＮＢ６０は、WcqNotificationSetupメッセージへの応答メッセージとして、WcqNotificationメッセージをＭＥＣサーバ４０へ送信する（Ｓ１２）。WcqNotificationメッセージには、図８に示されるパラメータが設定される。

例えば、WcqNotificationメッセージには、送信先のＭＥＣサーバ４０を示すＭＥＣサーバ ID、送信元のｅＮＢ６０を示すeNB IDが設定される。さらに、WcqNotificationメッセージに設定されるＷＣＱが、ＵＬの無線リソースに関するＷＣＱか、ＤＬの無線リソースに関するＷＣＱか、もしくはＵＬ及びＤＬの無線リソースに関するＷＣＱか、を示すDirectionが設定される。

さらに、WcqNotificationメッセージには、それぞれのリソースブロックに関するＵＥ毎のＷＣＱの値を示すWcqValueが設定されている。ここでは、無線リソースの具体例として、リソースブロックを用いて説明している。リソースブロックは、時間情報と周波数情報とを用いて特定される。リソースブロック毎のWcqValueは、ｅＮＢ６０からＭＥＣサーバ４０へ送信される。WcqValueは、例えば、レベル１、レベル２等の整数を用いて示されてもよい。この場合、値が大きくなるにつれて、当該リソースブロックの品質が良いことを示している。また、レベルＸ（Ｘは整数）以上は、Ｈｉｇｈレベル、レベルＹ（ＹはＸよりも小さい整数）以上でありレベルＸ未満は、Ｍｉｄｄｌｅレベル、レベルＹよりも小さい場合、Ｌｏｗレベルとしてもよい。

ここで、図９を用いてWcqNotificationメッセージに設定されるWcqValueについて説明する。リソースブロックは、RBindexを用いて識別される。図９においては、RBindexが１から１００までのリソースブロックに関して、ＵＥ毎のWcqValueが設定されることを示している。図９の空欄に、WcqValueが設定される。ＵＥは、ＵＥＩＤを用いて識別される。図９は、それぞれのＵＥが、０００００１〜ＦＦＦＦＦＦによって識別されていることを示している。ＵＥＩＤは、例えば、ＭＡＣ ＵＥＩＤが用いられてもよい。

続いて、図１０を用いて、ＭＥＣサーバ４０がｅＮＢ６０からスケジューラータイプを取得する処理の流れについて説明する。はじめに、ＭＥＣサーバ４０は、スケジューラータイプを取得するために、ｅＮＢ６０へリクエストメッセージを送信する（Ｓ２１）。具体的には、ＭＥＣサーバ４０は、SchedulingPolicyRequestメッセージをｅＮＢ６０へ送信する。SchedulingPolicyRequestメッセージには、図１１に示されるパラメータが設定される。

例えば、SchedulingPolicyRequestメッセージには、送信先のｅＮＢ６０を示すeNB ID、送信元のＳＣＥＦ４０を示すＭＥＣサーバ IDが設定される。また、SchedulingPolicyRequestメッセージには、送信間隔を示すNotificationIntervalが設定されてもよい。

図１０に戻り、次に、ｅＮＢ６０は、SchedulingPolicyRequestメッセージへの応答メッセージとして、SchedulingPolicyResponseメッセージをＭＥＣサーバ４０へ送信する（Ｓ２２）。SchedulingPolicyResponseメッセージには、図１２に示されるパラメータが設定される。

例えば、SchedulingPolicyResponseメッセージには、送信先のＭＥＣサーバ４０を示すＭＥＣサーバ ID、送信元のｅＮＢ６０を示すeNB IDが設定される。さらに、ｅＮＢ６０において用いられているスケジューラタイプが設定される。スケジューラタイプとして、例えば、ＰＦ、ＲＲ、もしくはＭＴが設定されてもよい。

続いて、図１３を用いて、ＭＥＣサーバ４０がｅＮＢ６０からバッファサイズを取得する処理の流れについて説明する。バッファサイズは、例えば、ｅＮＢ６０がＵＥ８０へＤＬデータを送信するために用いるバッファサイズ及びＵＥ８０がｅＮＢ６０へＵＬデータを送信するために用いるバッファサイズの少なくも一方を含む。バッファサイズは、ｅＮＢ６０もしくはＵＥ８０における未送信データのサイズと言い換えられてもよい。

はじめに、ＭＥＣサーバ４０は、バッファサイズを取得するために、ｅＮＢ６０へリクエストメッセージを送信する（Ｓ３１）。具体的には、ＭＥＣサーバ４０は、RemainBufferSizeSetupメッセージをｅＮＢ６０へ送信する。RemainBufferSizeSetupメッセージには、図１４に示されるパラメータが設定される。

例えば、RemainBufferSizeSetupメッセージには、送信先のｅＮＢ６０を示すeNB ID、送信元のＭＥＣサーバ４０を示すＭＥＣサーバ IDが設定される。また、RemainBufferSizeSetupメッセージには、送信間隔を示すNotificationIntervalが設定されてもよい。

図１３に戻り、次に、ｅＮＢ６０は、RemainBufferSizeSetupメッセージへの応答メッセージとして、RemainBufferSizeNotificationメッセージをＭＥＣサーバ４０へ送信する（Ｓ３２）。RemainBufferSizeNotificationメッセージには、図１５に示されるパラメータが設定される。

例えば、RemainBufferSizeNotificationメッセージには、送信先のＭＥＣサーバ４０を示すＭＥＣサーバ ID、送信元のｅＮＢ６０を示すeNB IDが設定される。さらに、Remain BufferSizeとして、それぞれのＵＥ８０に関するバッファサイズが設定される。ｅＮＢ６０は、ＤＬデータに関するバッファサイズを設定する場合、バッファが設けられたメモリ等からバッファサイズに関する情報を取得する。また、ｅＮＢ６０は、ＵＬデータに関するバッファサイズを設定する場合、ＵＥ８０からバッファサイズに関する情報を取得する。例えば、ｅＮＢ６０は、RemainBufferSizeSetupメッセージを受信した場合、ＵＥ８０からＵＬデータに関するバッファサイズに関する情報を取得する処理を開始してもよい。なお、通信装置１０としてＳＣＥＦが用いられる場合には、上記のＭＥＣサーバIDは、SCEF IDであってもよい。

ここで、図１６を用いてRemainBufferSizeNotificationメッセージに設定されるRemainBuffeｒSizeについて説明する。図１６は、ＵＥ毎のバッファサイズを示している。例えば、ＵＥＩＤが０００００１であるＵＥは、ＵＬデータに関するバッファ（ulBufferSize）として5byte有し、ｅＮＢ６０は、ＵＥＩＤが０００００１であるＵＥを宛先とするＤＬデータに関するバッファ（dlBufferSize）として30byte有することを示している。

図１５に戻り、RemainBufferSizeNotificationメッセージには、さらに、RemainBufferSizeNotificationメッセージに設定されるバッファサイズが、ＵＬデータに関するバッファサイズか、ＤＬデータに関するバッファサイズか、もしくはＵＬデータ及びＤＬデータに関するバッファサイズか、を示すDirectionが設定される。

続いて、図１７を用いて実施の形態２にかかるフローの追加を許可するか否かを判定する処理の流れについて説明する。フローの追加を許可するか否かを判定する処理は、例えば、新たなＵＥ８０に関するフローに含まれるデータを伝送するために、ｅＮＢ６０に無線リソースの割当要求メッセージ等が送信された際に実行されてもよい。つまり、ＭＥＣサーバ４０は、ｅＮＢ６０において新たなＵＥ８０に関するフローに対する無線リソースの割当要求メッセージが送信されたことを、ｅＮＢ６０から通知された場合に、新たなＵＥ８０に関するフローをを受け付けるか否かを判定してもよい。もしくは、ＭＥＣサーバ４０は、ＵＥ８０に関するフローに含まれる少なくとも１つのデータがｅＮＢ６０から送信された場合に、受信した少なくとも１つのデータを含むＵＥ８０に関するフローを受け付けるか否かを判定してもよい。またＭＥＣサーバ４０はこの場合において、将来任意のＵＥから要求されるフローを受け付けるか否かを判定してもよい。

また、フローの追加を許可するか否かを判定する処理は、ｅＮＢ６０において、あるＵＥに関するフローに含まれるすべてのデータの送信が完了した際に実行されてもよい。つまり、ＭＥＣサーバ４０は、ＵＥ８０に関するフローに含まれるすべてのデータの送信が完了したことをｅＮＢ６０から通知された場合に、将来任意のＵＥから要求されるフローを受け付けるか否かを判定してもよい。例えば、ＳＣＥＦ４０は、ｅＮＢ６０から送信されるＵＥ８０に関するバッファサイズが０である場合に、ＵＥ８０に関するフローに含まれるすべてのデータの送信を完了したと判定してもよい。もしくは、ＭＥＣサーバ４０は、ＵＥ８０に関するフローに含まれるすべてのデータをｅＮＢ６０から受信した場合に、将来任意のＵＥから要求されるフローを受け付けるか否かを判定してもよい。なお、ＵＥ８０に関するフローに含まれるデータは、ＵＥ８０がＭＥＣサーバ４０へ直接送信してもよい。

はじめに、スケジューリング制御部４１は、ｅＮＢ６０において処理もしくは転送されているフローのデータレートを算出する（Ｓ４１）。スケジューリング制御部４１は、ｅＮＢ６０において処理されている全てのフローを管理し、例えば、それぞれのフローにＩＤを付した管理リストを有しているとする。例えば、スケジューリング制御部４１は、次の式１に従ってＵＬデータのデータレートを算出する。

UL data rate(T2-T1)＝{ulBuf(T1)＋(flowSize-ulBuf(T2))}/(T2-T1)・・・式１
UL data rate(T2-T1)：時刻Ｔ１から時刻Ｔ２（例えば、Ｔ２が現在時刻であり、Ｔ１がＴ２より前の時刻）までの期間のＵＬデータの送信データレート
ulBuf(T1)：時刻Ｔ１におけるＵＬデータに関するバッファサイズ（Byte）
ulBuf(T2)：時刻Ｔ２におけるＵＬデータに関するバッファサイズ（Byte）
flowSize：送信デッドラインまでに送信すべきデータサイズ（Byte）

式１においてはＵＬデータのデータレートを算出したが、ＤＬデータのデータレートについても同様に算出することが可能である。

次に、スケジューリング制御部４１は、取得したＣＱＩ値に基づいて、将来のＣＱＩ値を推定し、推定したＣＱＩ値に基づいてデータレートを推定する（Ｓ４２）。ここでは、ＷＣＱとしてＣＱＩを用いて説明する。将来のＣＱＩ値は、例えば、現在時刻をｔとすると、ｔ＋１ミリ秒のように、現在時刻に対して予め定められた期間を加算した時刻におけるＣＱＩ値であってもよい。現在時刻に対して加算する予め定められた期間は、１ミリ秒に限定されない。現在時刻に対して加算する予め定められた期間は、例えば、ｅＮＢ６０におけるスケジューリング周期である１ＴＴＩであってもよい。

例えば、スケジューリング制御部４１は、過去に取得したＣＱＩ値の傾向に従って将来のＣＱＩ値を推定する。例えば、スケジューリング制御部４１は、過去に取得した無線リソースのＣＱＩ値が向上している傾向にある場合、将来の無線リソースに関するＣＱＩ値も向上していると推定してもよい。また、スケジューリング制御部４１は、過去に取得した無線リソースのＣＱＩ値が低下している傾向にある場合、将来の無線リソースに関するＣＱＩ値も低下していると推定してもよい。

スケジューリング制御部４１は、例えば、ｔ＋１ミリ秒におけるＣＱＩ値が向上していると推定した場合、ｔ＋１ミリ秒におけるデータレートは、ステップＳ４１において算出したデータレートよりも速いと推定してもよい。ＣＱＩ値の向上に対してどの程度データレートが速くなるかについては、予め定められていてもよい。さらに、ＣＱＩ値の低下に対して、どの程度データレートが遅くなるかについても、予め定められてもよい。

次に、スケジューリング制御部４１は、ｅＮＢ６０において処理されているそれぞれのフローにおけるＲＦＳ（Remain Flow Size）を算出する（Ｓ４３）。ＲＦＳは、ステップＳ４２において推定したデータレートにて時刻Ｔ２におけるバッファに格納されているデータを送信した場合に、所定期間経過後にバッファに残るデータ量である。つまり、ＲＦＳは、ステップＳ４２において推定したデータレートにて時刻Ｔ２におけるバッファに格納されているデータを送信した場合に、所定期間経過後に未送信となっているデータのデータ量である。所定期間は、例えば、ｔ＋１ミリ秒におけるＣＱＩを推定した場合、１ミリ秒であってもよい。また、所定期間経過後は、送信デッドラインが満了する前のタイミングとする。ＲＦＳは、例えば、次の式２に従って計算されてもよい。

ＲＦＳ＝ulBuf(T2)−α×UL data rate（T2-T1）×所定期間・・・式２
α：推定したＣＱＩ値に応じて定まる定数。
α×UL data rate (T2-T1)：所定期間経過後のデータレート（推定値）

スケジューリング制御部４１は、ステップＳ４３において、ｅＮＢ６０において処理されるすべてのフローに関して、ＲＦＳを算出する。

次に、スケジューリング制御部４１は、ＲＦＳ＝０となるフローを、管理しているフローのリストから削除する（Ｓ４４）。ＲＦＳ＝０とは、送信デッドラインまでにフローに含まれるすべてのデータを送信することができることを示している。次に、スケジューリング制御部４１は、管理しているフローのリストから全てのフローが削除されたか否かを判定する（Ｓ４５）。管理しているフローのリストから全てのフローが削除されるとは、ｅＮＢ６０において処理しているフローに含まれるデータが送信デッドラインまでにすべて送信されることを意図する。つまり、全てのフローが、送信デッドラインまでに完了することを意図する。そのため、スケジューリング制御部４１において管理しているフローのリストから全てのフローが削除された場合、受付判定部４２は、受付制限を行うことなく処理を完了する。つまり、受付判定部４２は、現在無線リソースの割当を要求されているフロー、もしくは、次回以降に無線リソースの割当を要求されるフローを受けられる。

スケジューリング制御部４１は、管理しているフローのリストから全てのフローが削除されていないと判定した場合、ＲＦＳのデータを送信デッドラインまでに送信を完了することができないフローが存在するか否かを判定する（Ｓ４６）。例えば、スケジューリング制御部４１は、ＲＦＳのデータの送信が完了するまでの時間ＦＣＴ（Flow Complete Time）を次の式３に従って算出する。

ＦＣＴ＝uLBuf(T2)／UL data rate(T2-T1)・・・式３

式３は、時刻Ｔ２におけるデータレートにてバッファに格納されているデータを送信した場合のＦＣＴを示している。推定したＣＱＩに従って定まる所定期間経過後のデータレートを用いる場合、UL data rate(T2-T1)の代わりに、α×UL data rate(T2-T1)が用いられてもよい。

さらに、スケジューリング制御部４１は、それぞれのフローのＦＣＴと現在時刻から送信デッドラインまでの時間とを比較し、ＦＣＴの方が長いフローが存在する場合、ＲＦＳのデータを送信デッドラインまでに送信を完了することができないフローが存在すると判定する（Ｓ４６）。また、スケジューリング制御部４１は、ＦＣＴの方が長いフローが存在しない場合、ＲＦＳのデータを送信デッドラインまでに送信を完了することができないフローが存在しないと判定する（Ｓ４６）。スケジューリング制御部４１は、ＲＦＳのデータを送信デッドラインまでに送信を完了することができないフローが存在しないと判定した場合、ステップＳ４２以降の処理を繰り返す。ステップＳ４２以降の処理においては、例えば、ｔ＋２ミリ秒におけるＣＱＩ値に基づいてそれぞれのフローのデータレートを算出する。

受付判定部４２は、スケジューリング制御部４１において、ＲＦＳのデータを送信デッドラインまでに送信を完了することができないフローが存在すると判定された場合、新たなＵＥ８０に関するフローの追加を拒否する（Ｓ４７）。

スケジューリング制御部４１は、図１７に示す処理を、ｅＮＢ６０における無線リソースの割当単位の最小単位である１ＴＴＩ（Transmission Time Interval）毎に行ってもよく、数ＴＴＩ毎に行ってもよい。１ＴＴＩは、例えば、１ミリ秒であってもよい。

以上説明したように、実施の形態２に係るフローの追加を許可するか否かを判定する処理を実行することによって、ｅＮＢ６０における処理負荷が高く送信デッドラインまでにすべてのデータを送信することができないような場合における、フローの追加を拒否することができる。これにより、ｅＮＢ６０に処理負荷の更なる増大を抑えることができる。

さらに、実施の形態２にかかるＭＥＣサーバ４０は、アプリケーションサーバ７０から１回のフローにおいて送信すべきデータサイズであるフローサイズ及び送信デッドラインに関する情報を取得することができる。これにより、ＭＥＣサーバ４０は、フロー毎のデータレートを算出することが可能であり、フロー毎に送信デッドラインまでにすべてのデータを送信することができるか否かを判定することができる。

一方、ｅＮＢ６０においてフロー毎に送信デッドラインまでにすべてのデータを送信することができるか否かを判定しようとした場合、ＵＥ８０からフロー毎のフローサイズ等に関する情報を取得する必要がある。このような場合、ＵＥ８０が送信するデータに、フローサイズを設定する等の処理が必要になり、ＵＥ８０の処理負荷が増大し、さらに、ＵＥ８０における機能追加が必要になる。

続いて以下では、上述の複数の実施形態で説明された、ｅＮＢ６０、ＭＥＣサーバ４０、及びＵＥ８０の構成例について説明する。図１８は、ｅＮＢ６０の構成例を示すブロック図である。図１８を参照すると、ｅＮＢ６０は、RFトランシーバ１００１、ネットワークインターフェース１００３、プロセッサ１００４、及びメモリ１００５を含む。RFトランシーバ１００１は、UEsと通信するためにアナログRF信号処理を行う。RFトランシーバ１００１は、複数のトランシーバを含んでもよい。RFトランシーバ１００１は、アンテナ１００２及びプロセッサ１００４と結合される。RFトランシーバ１００１は、変調シンボルデータ（又はOFDMシンボルデータ）をプロセッサ１００４から受信し、送信RF信号を生成し、送信RF信号をアンテナ１００２に供給する。また、RFトランシーバ１００１は、アンテナ１００２によって受信された受信ＲＦ信号に基づいてベースバンド受信信号を生成し、これをプロセッサ１００４に供給する。

ネットワークインターフェース１００３は、ネットワークノード（e.g., 他のコアネットワークノード）と通信するために使用される。ネットワークインターフェース１００３は、例えば、IEEE 802.3 seriesに準拠したネットワークインターフェースカード（NIC）を含んでもよい。

プロセッサ１００４は、無線通信のためのデジタルベースバンド信号処理を含むデータプレーン処理とコントロールプレーン処理を行う。例えば、LTEおよびLTE-Advancedの場合、プロセッサ１００４によるデジタルベースバンド信号処理は、MACレイヤ、およびPHYレイヤの信号処理を含んでもよい。

プロセッサ１００４は、複数のプロセッサを含んでもよい。例えば、プロセッサ１００４は、デジタルベースバンド信号処理を行うモデム・プロセッサ（e.g., DSP）、及びコントロールプレーン処理を行うプロトコルスタック・プロセッサ（e.g., CPU又はMPU）を含んでもよい。

メモリ１００５は、揮発性メモリ及び不揮発性メモリの組み合わせによって構成される。メモリ１００５は、物理的に独立した複数のメモリデバイスを含んでもよい。揮発性メモリは、例えば、Static Random Access Memory（SRAM）若しくはDynamic RAM（DRAM）又はこれらの組み合わせである。不揮発性メモリは、マスクRead Only Memory（MROM）、Electrically Erasable Programmable ROM（EEPROM）、フラッシュメモリ、若しくはハードディスクドライブ、又はこれらの任意の組合せである。メモリ１００５は、プロセッサ１００４から離れて配置されたストレージを含んでもよい。この場合、プロセッサ１００４は、ネットワークインターフェース１００３又は図示されていないI/Oインタフェースを介してメモリ１００５にアクセスしてもよい。

メモリ１００５は、上述の複数の実施形態で説明されたｅＮＢ６０による処理を行うための命令群およびデータを含むソフトウェアモジュール（コンピュータプログラム）を格納してもよい。いくつかの実装において、プロセッサ１００４は、当該ソフトウェアモジュールをメモリ１００５から読み出して実行することで、上述の実施形態で説明されたｅＮＢ６０の処理を行うよう構成されてもよい。

図１９は、ＵＥ８０の構成例を示すブロック図である。Radio Frequency（RF）トランシーバ１１０１は、ｅＮＢ６０と通信するためにアナログRF信号処理を行う。RFトランシーバ１１０１により行われるアナログRF信号処理は、周波数アップコンバージョン、周波数ダウンコンバージョン、及び増幅を含む。RFトランシーバ１１０１は、アンテナ１１０２及びベースバンドプロセッサ１１０３と結合される。すなわち、RFトランシーバ１１０１は、変調シンボルデータ（又はOFDMシンボルデータ）をベースバンドプロセッサ１１０３から受信し、送信RF信号を生成し、送信RF信号をアンテナ１１０２に供給する。また、RFトランシーバ１１０１は、アンテナ１１０２によって受信された受信ＲＦ信号に基づいてベースバンド受信信号を生成し、これをベースバンドプロセッサ１１０３に供給する。

ベースバンドプロセッサ１１０３は、無線通信のためのデジタルベースバンド信号処理（データプレーン処理）とコントロールプレーン処理を行う。デジタルベースバンド信号処理は、(a) データ圧縮／復元、(b) データのセグメンテーション／コンカテネーション、(c) 伝送フォーマット（伝送フレーム）の生成／分解、(d) 伝送路符号化／復号化、(e) 変調（シンボルマッピング）／復調、及び(f) Inverse Fast Fourier Transform（IFFT）によるOFDMシンボルデータ（ベースバンドOFDM信号）の生成などを含む。一方、コントロールプレーン処理は、レイヤ１（e.g., 送信電力制御）、レイヤ２（e.g., 無線リソース管理、及びhybrid automatic repeat request（HARQ）処理）、及びレイヤ３（e.g., アタッチ、モビリティ、及び通話管理に関するシグナリング）の通信管理を含む。

例えば、LTEおよびLTE-Advancedの場合、ベースバンドプロセッサ１１０３によるデジタルベースバンド信号処理は、Packet Data Convergence Protocol（PDCP）レイヤ、Radio Link Control（RLC）レイヤ、MACレイヤ、およびPHYレイヤの信号処理を含んでもよい。また、ベースバンドプロセッサ１１０３によるコントロールプレーン処理は、Non-Access Stratum（NAS）プロトコル、RRCプロトコル、及びMAC CEの処理を含んでもよい。

ベースバンドプロセッサ１１０３は、デジタルベースバンド信号処理を行うモデム・プロセッサ（e.g., Digital Signal Processor（DSP））とコントロールプレーン処理を行うプロトコルスタック・プロセッサ（e.g., Central Processing Unit（CPU）、又はMicro Processing Unit（MPU））を含んでもよい。この場合、コントロールプレーン処理を行うプロトコルスタック・プロセッサは、後述するアプリケーションプロセッサ１１０４と共通化されてもよい。

アプリケーションプロセッサ１１０４は、CPU、MPU、マイクロプロセッサ、又はプロセッサコアとも呼ばれる。アプリケーションプロセッサ１１０４は、複数のプロセッサ（複数のプロセッサコア）を含んでもよい。アプリケーションプロセッサ１１０４は、メモリ１１０６又は図示されていないメモリから読み出されたシステムソフトウェアプログラム（Operating System（OS））及び様々なアプリケーションプログラム（例えば、通話アプリケーション、WEBブラウザ、メーラ、カメラ操作アプリケーション、音楽再生アプリケーション）を実行することによって、ＵＥ８０の各種機能を実現する。

いくつかの実装において、図１９に破線（１１０５）で示されているように、ベースバンドプロセッサ１１０３及びアプリケーションプロセッサ１１０４は、１つのチップ上に集積されてもよい。言い換えると、ベースバンドプロセッサ１１０３及びアプリケーションプロセッサ１１０４は、１つのSystem on Chip（SoC）デバイス１１０５として実装されてもよい。SoCデバイスは、システムLarge Scale Integration（LSI）またはチップセットと呼ばれることもある。

メモリ１１０６は、揮発性メモリ若しくは不揮発性メモリ又はこれらの組合せである。メモリ１１０６は、物理的に独立した複数のメモリデバイスを含んでもよい。揮発性メモリは、例えば、Static Random Access Memory（SRAM）若しくはDynamic RAM（DRAM）又はこれらの組み合わせである。不揮発性メモリは、マスクRead Only Memory（MROM）、Electrically Erasable Programmable ROM（EEPROM）、フラッシュメモリ、若しくはハードディスクドライブ、又はこれらの任意の組合せである。例えば、メモリ１１０６は、ベースバンドプロセッサ１１０３、アプリケーションプロセッサ１１０４、及びSoC１１０５からアクセス可能な外部メモリデバイスを含んでもよい。メモリ１１０６は、ベースバンドプロセッサ１１０３内、アプリケーションプロセッサ１１０４内、又はSoC１１０５内に集積された内蔵メモリデバイスを含んでもよい。さらに、メモリ１１０６は、Universal Integrated Circuit Card（UICC）内のメモリを含んでもよい。

メモリ１１０６は、上述の複数の実施形態で説明されたＵＥ８０による処理を行うための命令群およびデータを含むソフトウェアモジュール（コンピュータプログラム）を格納してもよい。いくつかの実装において、ベースバンドプロセッサ１１０３又はアプリケーションプロセッサ１１０４は、当該ソフトウェアモジュールをメモリ１１０６から読み出して実行することで、上述の実施形態で説明されたＵＥ８０の処理を行うよう構成されてもよい。

図２０は、ＭＥＣサーバ４０の構成例を示すブロック図である。図２０を参照すると、ＭＥＣサーバ４０は、ネットワークインターフェース１２０１、プロセッサ１２０２、及びメモリ１２０３を含む。ネットワークインターフェース１２０１は、ネットワークノード（e.g., リモートノード１０、コアネットワーク４０）と通信するために使用される。ネットワークインターフェース１２０１は、例えば、IEEE 802.3 seriesに準拠したネットワークインタフェースカード（NIC）を含んでもよい。

プロセッサ１２０２は、メモリ１２０３からソフトウェア（コンピュータプログラム）を読み出して実行することで、上述の実施形態においてシーケンス図及びフローチャートを用いて説明されたセンターノード２０の処理を行う。プロセッサ１２０２は、例えば、マイクロプロセッサ、MPU、又はCPUであってもよい。プロセッサ１２０２は、複数のプロセッサを含んでもよい。

プロセッサ１２０２は、無線通信のためのデジタルベースバンド信号処理を含むデータプレーン処理とコントロールプレーン処理を行う。例えば、LTEおよびLTE-Advancedの場合、プロセッサ１００４によるデジタルベースバンド信号処理は、PDCPレイヤ、RLCレイヤ、およびMACレイヤの信号処理を含んでもよい。さらに、プロセッサ１２０２による信号処理は、X2-Uインタフェース及びS1-UインタフェースでのGTP-U・UDP/IPレイヤの信号処理を含んでもよい。また、プロセッサ１００４によるコントロールプレーン処理は、X2APプロトコル、S1-MMEプロトコルおよびRRCプロトコルの処理を含んでもよい。

プロセッサ１２０２は、複数のプロセッサを含んでもよい。例えば、プロセッサ１００４は、デジタルベースバンド信号処理を行うモデム・プロセッサ（e.g., DSP）、X2-Uインタフェース及びS1-UインタフェースでのGTP-U・UDP/IPレイヤの信号処理を行うプロセッサ（e.g., DSP）、及びコントロールプレーン処理を行うプロトコルスタック・プロセッサ（e.g., CPU又はMPU）を含んでもよい。

メモリ１２０３は、揮発性メモリ及び不揮発性メモリの組み合わせによって構成される。メモリ１２０３は、プロセッサ１２０２から離れて配置されたストレージを含んでもよい。この場合、プロセッサ１２０２は、図示されていないI/Oインタフェースを介してメモリ１２０３にアクセスしてもよい。

図２０の例では、メモリ１２０３は、ソフトウェアモジュール群を格納するために使用される。プロセッサ１２０２は、これらのソフトウェアモジュール群をメモリ１２０３から読み出して実行することで、上述の実施形態において説明されたＭＥＣサーバ４０の処理を行うことができる。

図１８〜図２０を用いて説明したように、上述の実施形態におけるｅＮＢ６０、ＭＥＣサーバ４０、及びＵＥ８０が有するプロセッサの各々は、図面を用いて説明されたアルゴリズムをコンピュータに行わせるための命令群を含む１又は複数のプログラムを実行する。

上述の例において、プログラムは、様々なタイプの非一時的なコンピュータ可読媒体（non-transitory computer readable medium）を用いて格納され、コンピュータに供給することができる。非一時的なコンピュータ可読媒体は、様々なタイプの実体のある記録媒体（tangible storage medium）を含む。非一時的なコンピュータ可読媒体の例は、磁気記録媒体（例えばフレキシブルディスク、磁気テープ、ハードディスクドライブ）、光磁気記録媒体（例えば光磁気ディスク）、ＣＤ−ＲＯＭ（Read Only Memory）、ＣＤ−Ｒ、ＣＤ−Ｒ／Ｗ、半導体メモリ（例えば、マスクＲＯＭ、ＰＲＯＭ（Programmable ROM）、ＥＰＲＯＭ（Erasable PROM）、フラッシュＲＯＭ、ＲＡＭ（Random Access Memory））を含む。また、プログラムは、様々なタイプの一時的なコンピュータ可読媒体（transitory computer readable medium）によってコンピュータに供給されてもよい。一時的なコンピュータ可読媒体の例は、電気信号、光信号、及び電磁波を含む。一時的なコンピュータ可読媒体は、電線及び光ファイバ等の有線通信路、又は無線通信路を介して、プログラムをコンピュータに供給できる。

なお、本発明は上記実施の形態に限られたものではなく、趣旨を逸脱しない範囲で適宜変更することが可能である。また、本発明は、それぞれの実施の形態を適宜組み合わせて実施されてもよい。

１０ 通信装置
１１ 判定部
１２ 通信部
２０ 基地局
３０ 無線端末
４０ ＭＥＣサーバ
４１ スケジューリング制御部
４２ 受付判定部
４３ ｅＮＢ通信部
５０ ゲートウェイ
６０ ｅＮＢ
６１ コアネットワークノード通信部
６２ 無線環境取得部
６３ 受付制御部
６４ 無線部
７０ アプリケーションサーバ
８０ ＵＥ
８１ 無線部
８２ 無線環境測定部
１００ コアネットワーク

Claims (10)

1. 無線端末と基地局との間において伝送されるフローであって、送信デッドラインが定められている前記フローに含まれる複数のデータパケットの送信状況に応じて、新たな無線端末に関するフローを受け付けるか否かを判定する判定部と、
   前記新たな無線端末に関するフローを受け付けるか否かを示す指示情報を基地局へ送信する通信部と、を備える通信装置。
2. 前記判定部は、
   前記複数のデータパケットが送信デッドラインまでにすべて送信されるか否かに関する情報を用いて、前記新たな無線端末に関するフローを受け付けるか否かを判定する、請求項１に記載の通信装置。
3. 前記判定部は、
   前記複数のデータパケットを送信する際のデータレートと、未送信データパケットのサイズとを用いて、前記未送信データパケットが、送信デッドラインまでにすべて送信されるか否かを判定する、請求項２に記載の通信装置。
4. 前記判定部は、
   前記無線端末もしくは前記基地局においてフローに含まれる複数のデータパケットを送信するために用いられるバッファサイズ及びフローに含まれる複数のデータパケットのデータサイズとを用いて、それぞれのフローのデータレートを算出する、請求項３に記載の通信装置。
5. 前記判定部は、
   前記複数のデータパケットを送信する無線リソースの品質を推定し、推定した前記無線リソースの品質を用いて前記データレートを決定する、請求項３又は４に記載の通信装置。
6. 前記判定部は、
   送信デッドラインまでに全てのデータパケットを送信することができない無線端末の数が、予め定められた数を超える場合に、前記新たな無線端末に関するフローの受付を停止する、請求項２乃至５のいずれか１項に記載の通信装置。
7. 前記判定部は、
   前記基地局が実行するデータパケットのスケジューリング制御を模擬し、前記複数のデータパケットが送信デッドラインまでにすべて送信されるか否かを判定する、請求項２乃至６のいずれか１項に記載の通信装置。
8. 無線端末と基地局との間において伝送されるフローであって、送信デッドラインが定められている前記フローに含まれる複数のデータパケットの送信状況に応じて、新たな無線端末に関するフローを受け付けるか否かを判定し、前記新たな無線端末に関するフローを受け付けるか否かを示す指示情報を送信する通信装置と、
   前記指示情報を受信し、前記指示情報に従って新たな無線端末に関するフローを受け付ける処理もしくは拒否する処理を実行する基地局と、を備える通信システム。
9. 通信装置が、
   無線端末と基地局との間において伝送されるフローであって、送信デッドラインが定められている前記フローに含まれる複数のデータパケットの送信状況に応じて、新たな無線端末に関するフローを受け付けるか否かを判定し、
   前記新たな無線端末に関するフローを受け付けるか否かを示す指示情報を基地局へ送信する、通信方法。
   
   
10. 無線端末と基地局との間において伝送されるフローであって、送信デッドラインが定められている前記フローに含まれる複数のデータパケットの送信状況に応じて、新たな無線端末に関するフローを受け付けるか否かを判定し、
    前記新たな無線端末に関するフローを受け付けるか否かを示す指示情報を基地局へ送信することをコンピュータに実行させるプログラム。

Images