(実施の形態1)
以下、図面を参照して本発明の実施の形態について説明する。図1を用いて本発明の実施の形態1にかかる通信システムの構成例について説明する。図1の通信システムは、通信装置10、基地局20、及び複数の無線端末30を有している。通信装置10、基地局20、及び無線端末30は、プロセッサがメモリに格納されたプログラムを実行することによって動作するコンピュータ装置であってもよい。
無線端末30は、携帯電話端末、スマートフォン端末、もしくはタブレット型端末等であってもよい。もしくは、無線端末30は、IoT(Internet of Things)サービスに用いられるIoT端末、M2M(Machine to Machine)端末、もしくはMTC(Machine Type Communication)端末等であってもよい。無線端末30は、基地局20と無線通信を行う。
基地局20は、3GPP(3rd Generation Partnership Project)において規定されているeNB(evolved Node B)もしくはNode Bであってもよい。eNBは、無線通信方式として、LTE(Long Term Evolution)を用いる基地局である。Node Bは、無線通信方式として、3GPPにおいて3Gと称される無線通信方式を用いる基地局である。また、基地局20は、3GPPにおいて規定されている無線通信方式に制限されず、他の標準間団体において規定されている無線通信方式を用いてもよい。基地局20は、無線アクセスネットワークノード等と称されてもよい。
通信装置10は、基地局20を制御する装置である。例えば、通信装置10は、基地局20において実行されるスケジューリングに関する制御を実施してもよい。基地局20において実行されるスケジューリングは、MAC(Medium Access Control)スケジューリング、もしくはパケットスケジューリング等と称されてもよい。
通信装置10は、例えば、3GPPにおいて規定されているSCEF(Service Capability Exposure Function)エンティティ(以下、SCEFと称する)であってもよい。SCEFは、例えば、モバイル通信事業者もしくはアプリケーションサービスプロバイダー等が管理するアプリケーションサーバに関する認証処理等を実行する。また、SCEFは、3GPPにおいて定められたリファレンスポイントを介してeNBである基地局20と通信する。SCEFは、例えば、コアネットワーク内において、制御データを伝送する。制御データは、例えば、無線端末30に関するユーザデータを伝送する通信経路の設定等を行うために用いられる。SCEFは、例えば、制御データを伝送するノード装置であるCPF(C-Plane Function)エンティティと称されてもよい。
また、通信装置10は、MEC(Mobile Edge Computing)サーバであってもよい。MECサーバは、基地局20と直接的に通信できる位置に配置されてもよい。直接的に通信できる位置とは、モバイル通信事業者が管理するコアネットワークを介することなく通信することができる位置である。例えば、MECサーバは、基地局20と物理的に統合されてもよい。もしくは、MECサーバは、基地局20と同じ建物に配置され、基地局20と通信できるように、建物内のLAN(Local Area Network)に接続されてもよい。MECサーバは、基地局20の近傍に配置されることによって、無線端末30との間の伝送遅延を短くすることができる。MECサーバは、例えば、超低遅延のアプリケーションサービスを提供するために用いられる。
また、通信装置10は、無線端末30へIoTサービスを提供するサーバ群を有するIoTプラットフォーム内に配置されてもよい。もしくは、通信装置10は、基地局20と直接もしくはネットワークを介して通信することができるサーバ装置であってもよい。通信装置10は、上記で例示した装置である場合であってもその他の装置であっても、ControlPlaneおよびUserPlaneいずれの機能を有していてもよい。
続いて、通信装置10の構成例について説明する。通信装置10は、判定部11及び通信部12を有している。判定部11及び通信部12は、プロセッサがメモリに格納されたプログラムを実行することによって処理が実行されるソフトウェアもしくはモジュールであってもよい。また、判定部11及び通信部12は、チップもしくは回路等のハードウェアであってもよい。
判定部11は、無線端末30と基地局20との間において伝送されるフローであって、送信デッドラインが定められているフローに含まれる複数のデータパケットの送信状況に応じて、新たな無線端末30に関するフローを受け付けるか否かを判定する。
無線端末30と基地局20との間において伝送されるフローは、例えば、無線端末30に提供されるアプリケーションサービスにおいて伝送される1又は複数のデータパケットを含む。データパケットは、データと称されてもよい。
無線端末30と基地局20との間において伝送されるフローは、無線端末30から基地局20へ送信されるフローもしくは基地局20から無線端末30へ送信されるフローであってもよい。もしくは、無線端末30と基地局20との間において伝送されるフローは、無線端末30から基地局20へ送信されるフロー及び基地局20から無線端末30へ送信されるフローを含んでもよい。無線端末30から基地局20へ送信されるフローに含まれるデータを、UL(Uplink)データと称する。また、基地局20から無線端末30へ送信されるフローに含まれるデータを、DL(Downlink)データと称する。アプリケーションサービスにおいて伝送されるデータは、例えば、画像データもしくは動画データ等であってもよい。また、アプリケーションデータには、画像データ等の送信を要求する要求メッセージもしくは要求メッセージに応答する応答メッセージ等が含まれてもよい。
送信デッドラインは、1回のフローに含まれる複数のデータパケットの送信を完了するべき期限を意味する。送信デッドラインは、アプリケーションによって要求される。送信デッドラインは、送信期限と言うこともできる。あるいは、送信デッドラインは、アプリケーションによって許容される最大送信遅延と言うこともできる。送信デッドラインは、様々に定義することができる。例えば、送信デッドラインは、アプリケーション・レイヤの発信者(sender)による送信の完了期限を示してもよい。あるいは、送信デッドラインは、無線レイヤの発信者による送信の完了期限を示してもよい。あるいは、送信デッドラインは、アプリケーション・レイヤの受信者(receiver)による受信の完了期限を示してもよい。あるいは、送信デッドラインは、無線レイヤの受信者による受信の完了期限を示してもよい。あるいは、より具体的に、送信デッドラインは、アプリケーションレイヤの発信者(sender)が1回のフローに関する最初のデータパケットを送信開始してからアプリケーションレイヤの受信者(receiver)が1回のフローに関する最後のデータパケットを受信完了する期限を示してもよい。あるいは、また、送信デッドラインは、無線レイヤの発信者が1回のフローに関する最初のデータパケットを送信開始してから無線レイヤの受信者が1回のフローに関する最後のデータパケットを受信完了する期限を示してもよい。送信デッドラインに関する情報は、MECサーバがアプリケーションサーバから受信してもよい。MECサーバは、MECサーバのユーザープレーンに届くデータについて、そのデータに適用されるサービスを判断し、そのサービスに基づいて送信デッドラインを判断してもよい。またMECサーバは、アプリケーションサーバから、データに適用されるサービスの情報を受信し、そのサービスに基づいて送信デッドラインを判断してもよい。
送信状況は、例えば、フローに含まれる複数のデータパケットのうち、未送信のデータパケット量、バッファサイズ、もしくはフローに含まれるすべてのデータパケットを送信デッドラインまでに送信可能か否か、等を示す情報であってもよい。
通信部12は、新たな無線端末に関するフローを受け付けるか否かを示す指示情報を基地局20へ送信する。基地局20は、通信装置10の判定部11において判定された判定結果に従って、新たな無線端末に関するフローの受付処理を実行する。言い換えると、基地局20は、通信装置10から送信された判定結果に従って、新たな無線端末30に関するスケジューリングを行う。
以上説明したように、図1の通信装置10は、送信デッドラインまでの時間を考慮したデータパケットの送信状況に応じて、新たな無線端末に関するフローを受け付けるか否かを判定することができる。言い換えると、基地局20は、既存のフローに関する送信デッドラインを満たすことができているか否かとするサービス品質に応じて、新たな無線端末に関するフローを受け付けるか否かを判定することができるため、基地局20におけるサービス品質の維持もしくは向上を図ることができる。
(実施の形態2)
続いて、図2を用いて本発明の実施の形態2にかかる通信システムの構成例について説明する。図2の通信システムは、3GPPにおいて規定されている通信システムを示している。図2の通信システムは、eNB60、アプリケーションサーバ70、コアネットワーク100、及び複数のUE80を有している。UE80は、3GPPにおいて用いられる通信端末の総称である。コアネットワーク100は、モバイル通信事業者が管理するネットワークである。コアネットワーク100は、MECサーバ40及びゲートウェイ50を有している。
ゲートウェイ50は、例えば、コアネットワーク100内において、UE80に関するユーザデータを伝送するSGW(Serving Gateway)もしくはPGW(Packet Data Network Gateway)であってもよい。もしくは、ゲートウェイ50は、UE80に関するユーザデータを伝送するノード装置である、UPF(U-Plane Function)エンティティであってもよい。ユーザデータは、例えば、画像データもしくは動画データ等であってもよい。
MECサーバ40は、例えば、コアネットワーク100内において、制御データを伝送する。制御データは、例えば、UE80に関するユーザデータを伝送する通信経路の設定等を行うために用いられる。MECサーバ40は、例えば、制御データを伝送するノード装置であるCPF(C-Plane Function)エンティティと称されてもよい。
アプリケーションサーバ70は、UE80へアプリケーションサービスを提供するサーバである。アプリケーションサーバ70は、例えば、ユーザデータをゲートウェイ50へ送信する。また、アプリケーションサーバ70は、1回のフローにおいて送信するユーザデータのデータサイズ(フローサイズ)、さらに、1回のフローにおける送信デッドラインに関する情報等をMECサーバ40へ送信する。
ゲートウェイ50は、アプリケーションサーバ70から送信されたユーザデータをeNB60へ送信する。また、ゲートウェイ50は、eNB60から送信されたユーザデータをアプリケーションサーバ70へ送信する。
MECサーバ40は、アプリケーションサーバ70から送信された情報と、eNB60から送信されたデータパケットの送信状況とを用いて、eNB60において新たな無線端末に関するフローを受け付けるか否かを判定する。MECサーバ40は、フローの受付に関する判定結果をeNB60へ送信する。
eNB60は、MECサーバ40から送信されたフローの受付に関する判定結果を用いて、UE80から要求されるフローを受け付ける処理もしくはフローを拒絶する処理を実行する。
続いて、図3を用いて実施の形態2にかかるMECサーバ40の構成例について説明する。MECサーバ40は、スケジューリング制御部41、受付判定部42、及びeNB通信部43を有している。スケジューリング制御部41、受付判定部42、及びeNB通信部43は、プロセッサがメモリに格納されたプログラムを実行することによって処理が実行されるソフトウェアもしくはモジュールであってもよい。または、スケジューリング制御部41、受付判定部42、及びeNB通信部43は、チップもしくは回路等のハードウェアであってもよい。
スケジューリング制御部41は、eNB60において実行されるMACスケジューリングを模擬する(emulate)ことによって、eNB60において処理される各フローが、送信デッドラインまでに完了するか否かを判定する。各フローが送信デッドラインまでに完了するとは、各フローに含まれる複数のデータパケットが送信デッドラインまでにすべて送信されることである。スケジューリング制御部41は、例えば、UE80もしくはeNB60において測定された無線リソースの通信品質を用いて、MACスケジューリングを模擬する。スケジューリング制御部41におけるMACスケジューリングを模擬した処理については後に詳述する。スケジューリング制御部41は、eNB60において処理される各フローが、送信デッドラインまでに完了するか否かを判定した判定結果を受付判定部42へ出力する。
また、スケジューリング制御部41は、UE80もしくはeNB60において測定された無線リソースの通信品質を用いて、将来の無線リソースに関する通信品質を推定する。通信品質は、例えば、CQI(Channel Quality Indicator)であってもよく、その他の品質を示す情報であってもよい。
スケジューリング制御部41は、例えば、過去に取得した無線リソースの通信品質の傾向、もしくは統計情報を用いて、将来の無線リソースに関する通信品質を推定する。例えば、スケジューリング制御部41は、過去に取得した無線リソースの通信品質が向上している傾向にある場合、将来の無線リソースに関する通信品質も向上していると推定してもよい。また、スケジューリング制御部41は、過去に取得した無線リソースの通信品質が低下している傾向にある場合、将来の無線リソースに関する通信品質も低下していると推定してもよい。
受付判定部42は、スケジューリング制御部41から出力された判定結果を用いて、eNB60において新たなUE80に関するフローを受け付けるか否かを判定する。例えば、受付判定部42は、eNB60において処理される複数のフローのうち、一つでも送信デッドラインまでに完了しないフローが存在する場合、新たなUE80に関するフローの受付を拒否してもよい。言い換えると、受付判定部42は、eNB60において処理される全てのフローが送信デッドラインまでに完了する場合、UE80に関するフローの受付を許可してもよい。また、受付判定部42は、eNB60において処理される複数のフローのうち、送信デッドラインまでに完了しないフローが、予め定められた閾値を超えている場合に、新たなUE80に関するフローの受付を拒否してもよい。さらに受付判定部42は、フローの受付を拒否するUE80の数や割合を予め定めて、新たなUE80に関するフローを受け付けるか否かの判定に用いてもよい。
eNB通信部43は、新たなUE80に関するフローを受け付けるか否かを示す指示情報をeNB60へ送信する。
続いて、図4を用いて実施の形態2にかかるeNB60の構成例について説明する。eNB60は、コアネットワークノード通信部61、無線環境取得部62、受付制御部63、及び無線部64を有している。コアネットワークノード通信部61、無線環境取得部62、受付制御部63、及び無線部64は、プロセッサがメモリに格納されたプログラムを実行することによって処理が実行されるソフトウェアもしくはモジュールであってもよい。また、コアネットワークノード通信部61、無線環境取得部62、受付制御部63、及び無線部64は、チップもしくは回路等のハードウェアであってもよい。
無線環境取得部62は、UE80から無線部64を介して受信したULデータを用いて、ULデータを伝送する無線リソースの通信品質を測定する。また、無線環境取得部62は、UE80においてDLデータを用いて測定されたDLデータを伝送する無線リソースの通信品質を、UE80から受信する。無線環境取得部62は、UE80から無線部64を介してDLデータを伝送する無線リソースの通信品質に関する情報を受信する。
無線環境取得部62は、UL及びDLデータを送信する無線リソースの通信品質を、コアネットワークノード通信部61を介してMECサーバ40へ送信する。
受付制御部63は、コアネットワークノード通信部61を介してMECサーバ40から送信された新たなUE80に関するフローを受け付けるか否かを示す指示情報を受信する。受付制御部63は、受信した指示情報を用いて、新たなUE80に関するフローの受付処理もしくは拒絶処理を実施する。UE80に関するフローの拒絶処理は、例えば、一時的にUE80に関するフローの受付を拒絶し、所定期間経過後にUE80に関するフローを受け付ける受付処理を実行することを含んでもよい。もしくは、UE80に関するフローの拒絶処理は、UE80に関するフローを受け付けた後に、所定期間、UE80に無線リソースの割当を行わないことを含んでもよい。ここで、フローの受付を拒絶されたUE80は、拒絶されたフローのデータパケットを廃棄してもよい。UE80は、discard timerを用いて、受付を拒絶されたフローのデータパケットを廃棄してもよい。
無線部64は、MACスケジューリングの結果、UE80へ割り当てられた無線リソースを用いて、UE80と無線通信を行う。MACスケジューリングは、例えば、PF(Proportional Fairness)、RR(Round Robin)もしくはMT(Maximum Throughput)等の方式もしくはスケジューラータイプが用いられてもよい。
続いて、図5を用いて実施の形態2にかかるUE80の構成例について説明する。UE80は、無線部81及び無線環境測定部82を有している。無線部81及び無線環境測定部82は、プロセッサがメモリに格納されたプログラムを実行することによって処理が実行されるソフトウェアもしくはモジュールであってもよい。または、無線部81及び無線環境測定部82は、チップもしくは回路等のハードウェアであってもよい。
無線環境測定部82は、eNB60から送信されたDLデータを用いてDLデータを伝送する無線リソースの通信品質を測定する。無線環境測定部82は、無線部81を介してDLデータを伝送する無線リソースの通信品質をeNB60へ送信する。
続いて、図6を用いて、MECサーバ40がeNB60から無線リソースの通信品質を取得する処理の流れについて説明する。はじめに、MECサーバ40は、無線リソースの通信品質を取得するために、eNB60へリクエストメッセージを送信する(S11)。具体的には、MECサーバ40は、WcqNotificationSetupメッセージをeNB60へ送信する。WCQ(Wireless Channel Quality)は、無線リソースの通信品質を示す。WCQは、例えば、CQI、信号レベル、もしくはノイズレベル等の情報であってもよい。信号レベル及びノイズレベルに関する情報は、例えば、信号の強度及びノイズの強度等を示す情報であってもよい。また、WCQは、信号レベル及びノイズレベルを用いて示されるSINR(Signal to Interference plus Noise power Ratio)であってもよい。WcqNotificationSetupメッセージには、図7に示されるパラメータが設定される。
例えば、WcqNotificationSetupメッセージには、送信先のeNB60を示すeNB ID、送信元のMECサーバ40を示すMECサーバ IDが設定される。さらに、MECサーバ40が取得を希望するWCQが、ULの無線リソースに関するWCQか、DLの無線リソースに関するWCQか、もしくはUL及びDLの無線リソースに関するWCQか、を示すDirectionが設定される。また、WcqNotificationSetupメッセージには、送信間隔を示すNotificationIntervalが設定されてもよい。
図6に戻り、次に、eNB60は、WcqNotificationSetupメッセージへの応答メッセージとして、WcqNotificationメッセージをMECサーバ40へ送信する(S12)。WcqNotificationメッセージには、図8に示されるパラメータが設定される。
例えば、WcqNotificationメッセージには、送信先のMECサーバ40を示すMECサーバ ID、送信元のeNB60を示すeNB IDが設定される。さらに、WcqNotificationメッセージに設定されるWCQが、ULの無線リソースに関するWCQか、DLの無線リソースに関するWCQか、もしくはUL及びDLの無線リソースに関するWCQか、を示すDirectionが設定される。
さらに、WcqNotificationメッセージには、それぞれのリソースブロックに関するUE毎のWCQの値を示すWcqValueが設定されている。ここでは、無線リソースの具体例として、リソースブロックを用いて説明している。リソースブロックは、時間情報と周波数情報とを用いて特定される。リソースブロック毎のWcqValueは、eNB60からMECサーバ40へ送信される。WcqValueは、例えば、レベル1、レベル2等の整数を用いて示されてもよい。この場合、値が大きくなるにつれて、当該リソースブロックの品質が良いことを示している。また、レベルX(Xは整数)以上は、Highレベル、レベルY(YはXよりも小さい整数)以上でありレベルX未満は、Middleレベル、レベルYよりも小さい場合、Lowレベルとしてもよい。
ここで、図9を用いてWcqNotificationメッセージに設定されるWcqValueについて説明する。リソースブロックは、RBindexを用いて識別される。図9においては、RBindexが1から100までのリソースブロックに関して、UE毎のWcqValueが設定されることを示している。図9の空欄に、WcqValueが設定される。UEは、UEIDを用いて識別される。図9は、それぞれのUEが、000001〜FFFFFFによって識別されていることを示している。UEIDは、例えば、MAC UEIDが用いられてもよい。
続いて、図10を用いて、MECサーバ40がeNB60からスケジューラータイプを取得する処理の流れについて説明する。はじめに、MECサーバ40は、スケジューラータイプを取得するために、eNB60へリクエストメッセージを送信する(S21)。具体的には、MECサーバ40は、SchedulingPolicyRequestメッセージをeNB60へ送信する。SchedulingPolicyRequestメッセージには、図11に示されるパラメータが設定される。
例えば、SchedulingPolicyRequestメッセージには、送信先のeNB60を示すeNB ID、送信元のSCEF40を示すMECサーバ IDが設定される。また、SchedulingPolicyRequestメッセージには、送信間隔を示すNotificationIntervalが設定されてもよい。
図10に戻り、次に、eNB60は、SchedulingPolicyRequestメッセージへの応答メッセージとして、SchedulingPolicyResponseメッセージをMECサーバ40へ送信する(S22)。SchedulingPolicyResponseメッセージには、図12に示されるパラメータが設定される。
例えば、SchedulingPolicyResponseメッセージには、送信先のMECサーバ40を示すMECサーバ ID、送信元のeNB60を示すeNB IDが設定される。さらに、eNB60において用いられているスケジューラタイプが設定される。スケジューラタイプとして、例えば、PF、RR、もしくはMTが設定されてもよい。
続いて、図13を用いて、MECサーバ40がeNB60からバッファサイズを取得する処理の流れについて説明する。バッファサイズは、例えば、eNB60がUE80へDLデータを送信するために用いるバッファサイズ及びUE80がeNB60へULデータを送信するために用いるバッファサイズの少なくも一方を含む。バッファサイズは、eNB60もしくはUE80における未送信データのサイズと言い換えられてもよい。
はじめに、MECサーバ40は、バッファサイズを取得するために、eNB60へリクエストメッセージを送信する(S31)。具体的には、MECサーバ40は、RemainBufferSizeSetupメッセージをeNB60へ送信する。RemainBufferSizeSetupメッセージには、図14に示されるパラメータが設定される。
例えば、RemainBufferSizeSetupメッセージには、送信先のeNB60を示すeNB ID、送信元のMECサーバ40を示すMECサーバ IDが設定される。また、RemainBufferSizeSetupメッセージには、送信間隔を示すNotificationIntervalが設定されてもよい。
図13に戻り、次に、eNB60は、RemainBufferSizeSetupメッセージへの応答メッセージとして、RemainBufferSizeNotificationメッセージをMECサーバ40へ送信する(S32)。RemainBufferSizeNotificationメッセージには、図15に示されるパラメータが設定される。
例えば、RemainBufferSizeNotificationメッセージには、送信先のMECサーバ40を示すMECサーバ ID、送信元のeNB60を示すeNB IDが設定される。さらに、Remain BufferSizeとして、それぞれのUE80に関するバッファサイズが設定される。eNB60は、DLデータに関するバッファサイズを設定する場合、バッファが設けられたメモリ等からバッファサイズに関する情報を取得する。また、eNB60は、ULデータに関するバッファサイズを設定する場合、UE80からバッファサイズに関する情報を取得する。例えば、eNB60は、RemainBufferSizeSetupメッセージを受信した場合、UE80からULデータに関するバッファサイズに関する情報を取得する処理を開始してもよい。なお、通信装置10としてSCEFが用いられる場合には、上記のMECサーバIDは、SCEF IDであってもよい。
ここで、図16を用いてRemainBufferSizeNotificationメッセージに設定されるRemainBufferSizeについて説明する。図16は、UE毎のバッファサイズを示している。例えば、UEIDが000001であるUEは、ULデータに関するバッファ(ulBufferSize)として5byte有し、eNB60は、UEIDが000001であるUEを宛先とするDLデータに関するバッファ(dlBufferSize)として30byte有することを示している。
図15に戻り、RemainBufferSizeNotificationメッセージには、さらに、RemainBufferSizeNotificationメッセージに設定されるバッファサイズが、ULデータに関するバッファサイズか、DLデータに関するバッファサイズか、もしくはULデータ及びDLデータに関するバッファサイズか、を示すDirectionが設定される。
続いて、図17を用いて実施の形態2にかかるフローの追加を許可するか否かを判定する処理の流れについて説明する。フローの追加を許可するか否かを判定する処理は、例えば、新たなUE80に関するフローに含まれるデータを伝送するために、eNB60に無線リソースの割当要求メッセージ等が送信された際に実行されてもよい。つまり、MECサーバ40は、eNB60において新たなUE80に関するフローに対する無線リソースの割当要求メッセージが送信されたことを、eNB60から通知された場合に、新たなUE80に関するフローをを受け付けるか否かを判定してもよい。もしくは、MECサーバ40は、UE80に関するフローに含まれる少なくとも1つのデータがeNB60から送信された場合に、受信した少なくとも1つのデータを含むUE80に関するフローを受け付けるか否かを判定してもよい。またMECサーバ40はこの場合において、将来任意のUEから要求されるフローを受け付けるか否かを判定してもよい。
また、フローの追加を許可するか否かを判定する処理は、eNB60において、あるUEに関するフローに含まれるすべてのデータの送信が完了した際に実行されてもよい。つまり、MECサーバ40は、UE80に関するフローに含まれるすべてのデータの送信が完了したことをeNB60から通知された場合に、将来任意のUEから要求されるフローを受け付けるか否かを判定してもよい。例えば、SCEF40は、eNB60から送信されるUE80に関するバッファサイズが0である場合に、UE80に関するフローに含まれるすべてのデータの送信を完了したと判定してもよい。もしくは、MECサーバ40は、UE80に関するフローに含まれるすべてのデータをeNB60から受信した場合に、将来任意のUEから要求されるフローを受け付けるか否かを判定してもよい。なお、UE80に関するフローに含まれるデータは、UE80がMECサーバ40へ直接送信してもよい。
はじめに、スケジューリング制御部41は、eNB60において処理もしくは転送されているフローのデータレートを算出する(S41)。スケジューリング制御部41は、eNB60において処理されている全てのフローを管理し、例えば、それぞれのフローにIDを付した管理リストを有しているとする。例えば、スケジューリング制御部41は、次の式1に従ってULデータのデータレートを算出する。
UL data rate(T2-T1)={ulBuf(T1)+(flowSize-ulBuf(T2))}/(T2-T1)・・・式1
UL data rate(T2-T1):時刻T1から時刻T2(例えば、T2が現在時刻であり、T1がT2より前の時刻)までの期間のULデータの送信データレート
ulBuf(T1):時刻T1におけるULデータに関するバッファサイズ(Byte)
ulBuf(T2):時刻T2におけるULデータに関するバッファサイズ(Byte)
flowSize:送信デッドラインまでに送信すべきデータサイズ(Byte)
式1においてはULデータのデータレートを算出したが、DLデータのデータレートについても同様に算出することが可能である。
次に、スケジューリング制御部41は、取得したCQI値に基づいて、将来のCQI値を推定し、推定したCQI値に基づいてデータレートを推定する(S42)。ここでは、WCQとしてCQIを用いて説明する。将来のCQI値は、例えば、現在時刻をtとすると、t+1ミリ秒のように、現在時刻に対して予め定められた期間を加算した時刻におけるCQI値であってもよい。現在時刻に対して加算する予め定められた期間は、1ミリ秒に限定されない。現在時刻に対して加算する予め定められた期間は、例えば、eNB60におけるスケジューリング周期である1TTIであってもよい。
例えば、スケジューリング制御部41は、過去に取得したCQI値の傾向に従って将来のCQI値を推定する。例えば、スケジューリング制御部41は、過去に取得した無線リソースのCQI値が向上している傾向にある場合、将来の無線リソースに関するCQI値も向上していると推定してもよい。また、スケジューリング制御部41は、過去に取得した無線リソースのCQI値が低下している傾向にある場合、将来の無線リソースに関するCQI値も低下していると推定してもよい。
スケジューリング制御部41は、例えば、t+1ミリ秒におけるCQI値が向上していると推定した場合、t+1ミリ秒におけるデータレートは、ステップS41において算出したデータレートよりも速いと推定してもよい。CQI値の向上に対してどの程度データレートが速くなるかについては、予め定められていてもよい。さらに、CQI値の低下に対して、どの程度データレートが遅くなるかについても、予め定められてもよい。
次に、スケジューリング制御部41は、eNB60において処理されているそれぞれのフローにおけるRFS(Remain Flow Size)を算出する(S43)。RFSは、ステップS42において推定したデータレートにて時刻T2におけるバッファに格納されているデータを送信した場合に、所定期間経過後にバッファに残るデータ量である。つまり、RFSは、ステップS42において推定したデータレートにて時刻T2におけるバッファに格納されているデータを送信した場合に、所定期間経過後に未送信となっているデータのデータ量である。所定期間は、例えば、t+1ミリ秒におけるCQIを推定した場合、1ミリ秒であってもよい。また、所定期間経過後は、送信デッドラインが満了する前のタイミングとする。RFSは、例えば、次の式2に従って計算されてもよい。
RFS=ulBuf(T2)−α×UL data rate(T2-T1)×所定期間・・・式2
α:推定したCQI値に応じて定まる定数。
α×UL data rate (T2-T1):所定期間経過後のデータレート(推定値)
スケジューリング制御部41は、ステップS43において、eNB60において処理されるすべてのフローに関して、RFSを算出する。
次に、スケジューリング制御部41は、RFS=0となるフローを、管理しているフローのリストから削除する(S44)。RFS=0とは、送信デッドラインまでにフローに含まれるすべてのデータを送信することができることを示している。次に、スケジューリング制御部41は、管理しているフローのリストから全てのフローが削除されたか否かを判定する(S45)。管理しているフローのリストから全てのフローが削除されるとは、eNB60において処理しているフローに含まれるデータが送信デッドラインまでにすべて送信されることを意図する。つまり、全てのフローが、送信デッドラインまでに完了することを意図する。そのため、スケジューリング制御部41において管理しているフローのリストから全てのフローが削除された場合、受付判定部42は、受付制限を行うことなく処理を完了する。つまり、受付判定部42は、現在無線リソースの割当を要求されているフロー、もしくは、次回以降に無線リソースの割当を要求されるフローを受けられる。
スケジューリング制御部41は、管理しているフローのリストから全てのフローが削除されていないと判定した場合、RFSのデータを送信デッドラインまでに送信を完了することができないフローが存在するか否かを判定する(S46)。例えば、スケジューリング制御部41は、RFSのデータの送信が完了するまでの時間FCT(Flow Complete Time)を次の式3に従って算出する。
FCT=uLBuf(T2)/UL data rate(T2-T1)・・・式3
式3は、時刻T2におけるデータレートにてバッファに格納されているデータを送信した場合のFCTを示している。推定したCQIに従って定まる所定期間経過後のデータレートを用いる場合、UL data rate(T2-T1)の代わりに、α×UL data rate(T2-T1)が用いられてもよい。
さらに、スケジューリング制御部41は、それぞれのフローのFCTと現在時刻から送信デッドラインまでの時間とを比較し、FCTの方が長いフローが存在する場合、RFSのデータを送信デッドラインまでに送信を完了することができないフローが存在すると判定する(S46)。また、スケジューリング制御部41は、FCTの方が長いフローが存在しない場合、RFSのデータを送信デッドラインまでに送信を完了することができないフローが存在しないと判定する(S46)。スケジューリング制御部41は、RFSのデータを送信デッドラインまでに送信を完了することができないフローが存在しないと判定した場合、ステップS42以降の処理を繰り返す。ステップS42以降の処理においては、例えば、t+2ミリ秒におけるCQI値に基づいてそれぞれのフローのデータレートを算出する。
受付判定部42は、スケジューリング制御部41において、RFSのデータを送信デッドラインまでに送信を完了することができないフローが存在すると判定された場合、新たなUE80に関するフローの追加を拒否する(S47)。
スケジューリング制御部41は、図17に示す処理を、eNB60における無線リソースの割当単位の最小単位である1TTI(Transmission Time Interval)毎に行ってもよく、数TTI毎に行ってもよい。1TTIは、例えば、1ミリ秒であってもよい。
以上説明したように、実施の形態2に係るフローの追加を許可するか否かを判定する処理を実行することによって、eNB60における処理負荷が高く送信デッドラインまでにすべてのデータを送信することができないような場合における、フローの追加を拒否することができる。これにより、eNB60に処理負荷の更なる増大を抑えることができる。
さらに、実施の形態2にかかるMECサーバ40は、アプリケーションサーバ70から1回のフローにおいて送信すべきデータサイズであるフローサイズ及び送信デッドラインに関する情報を取得することができる。これにより、MECサーバ40は、フロー毎のデータレートを算出することが可能であり、フロー毎に送信デッドラインまでにすべてのデータを送信することができるか否かを判定することができる。
一方、eNB60においてフロー毎に送信デッドラインまでにすべてのデータを送信することができるか否かを判定しようとした場合、UE80からフロー毎のフローサイズ等に関する情報を取得する必要がある。このような場合、UE80が送信するデータに、フローサイズを設定する等の処理が必要になり、UE80の処理負荷が増大し、さらに、UE80における機能追加が必要になる。
続いて以下では、上述の複数の実施形態で説明された、eNB60、MECサーバ40、及びUE80の構成例について説明する。図18は、eNB60の構成例を示すブロック図である。図18を参照すると、eNB60は、RFトランシーバ1001、ネットワークインターフェース1003、プロセッサ1004、及びメモリ1005を含む。RFトランシーバ1001は、UEsと通信するためにアナログRF信号処理を行う。RFトランシーバ1001は、複数のトランシーバを含んでもよい。RFトランシーバ1001は、アンテナ1002及びプロセッサ1004と結合される。RFトランシーバ1001は、変調シンボルデータ(又はOFDMシンボルデータ)をプロセッサ1004から受信し、送信RF信号を生成し、送信RF信号をアンテナ1002に供給する。また、RFトランシーバ1001は、アンテナ1002によって受信された受信RF信号に基づいてベースバンド受信信号を生成し、これをプロセッサ1004に供給する。
ネットワークインターフェース1003は、ネットワークノード(e.g., 他のコアネットワークノード)と通信するために使用される。ネットワークインターフェース1003は、例えば、IEEE 802.3 seriesに準拠したネットワークインターフェースカード(NIC)を含んでもよい。
プロセッサ1004は、無線通信のためのデジタルベースバンド信号処理を含むデータプレーン処理とコントロールプレーン処理を行う。例えば、LTEおよびLTE-Advancedの場合、プロセッサ1004によるデジタルベースバンド信号処理は、MACレイヤ、およびPHYレイヤの信号処理を含んでもよい。
プロセッサ1004は、複数のプロセッサを含んでもよい。例えば、プロセッサ1004は、デジタルベースバンド信号処理を行うモデム・プロセッサ(e.g., DSP)、及びコントロールプレーン処理を行うプロトコルスタック・プロセッサ(e.g., CPU又はMPU)を含んでもよい。
メモリ1005は、揮発性メモリ及び不揮発性メモリの組み合わせによって構成される。メモリ1005は、物理的に独立した複数のメモリデバイスを含んでもよい。揮発性メモリは、例えば、Static Random Access Memory(SRAM)若しくはDynamic RAM(DRAM)又はこれらの組み合わせである。不揮発性メモリは、マスクRead Only Memory(MROM)、Electrically Erasable Programmable ROM(EEPROM)、フラッシュメモリ、若しくはハードディスクドライブ、又はこれらの任意の組合せである。メモリ1005は、プロセッサ1004から離れて配置されたストレージを含んでもよい。この場合、プロセッサ1004は、ネットワークインターフェース1003又は図示されていないI/Oインタフェースを介してメモリ1005にアクセスしてもよい。
メモリ1005は、上述の複数の実施形態で説明されたeNB60による処理を行うための命令群およびデータを含むソフトウェアモジュール(コンピュータプログラム)を格納してもよい。いくつかの実装において、プロセッサ1004は、当該ソフトウェアモジュールをメモリ1005から読み出して実行することで、上述の実施形態で説明されたeNB60の処理を行うよう構成されてもよい。
図19は、UE80の構成例を示すブロック図である。Radio Frequency(RF)トランシーバ1101は、eNB60と通信するためにアナログRF信号処理を行う。RFトランシーバ1101により行われるアナログRF信号処理は、周波数アップコンバージョン、周波数ダウンコンバージョン、及び増幅を含む。RFトランシーバ1101は、アンテナ1102及びベースバンドプロセッサ1103と結合される。すなわち、RFトランシーバ1101は、変調シンボルデータ(又はOFDMシンボルデータ)をベースバンドプロセッサ1103から受信し、送信RF信号を生成し、送信RF信号をアンテナ1102に供給する。また、RFトランシーバ1101は、アンテナ1102によって受信された受信RF信号に基づいてベースバンド受信信号を生成し、これをベースバンドプロセッサ1103に供給する。
ベースバンドプロセッサ1103は、無線通信のためのデジタルベースバンド信号処理(データプレーン処理)とコントロールプレーン処理を行う。デジタルベースバンド信号処理は、(a) データ圧縮/復元、(b) データのセグメンテーション/コンカテネーション、(c) 伝送フォーマット(伝送フレーム)の生成/分解、(d) 伝送路符号化/復号化、(e) 変調(シンボルマッピング)/復調、及び(f) Inverse Fast Fourier Transform(IFFT)によるOFDMシンボルデータ(ベースバンドOFDM信号)の生成などを含む。一方、コントロールプレーン処理は、レイヤ1(e.g., 送信電力制御)、レイヤ2(e.g., 無線リソース管理、及びhybrid automatic repeat request(HARQ)処理)、及びレイヤ3(e.g., アタッチ、モビリティ、及び通話管理に関するシグナリング)の通信管理を含む。
例えば、LTEおよびLTE-Advancedの場合、ベースバンドプロセッサ1103によるデジタルベースバンド信号処理は、Packet Data Convergence Protocol(PDCP)レイヤ、Radio Link Control(RLC)レイヤ、MACレイヤ、およびPHYレイヤの信号処理を含んでもよい。また、ベースバンドプロセッサ1103によるコントロールプレーン処理は、Non-Access Stratum(NAS)プロトコル、RRCプロトコル、及びMAC CEの処理を含んでもよい。
ベースバンドプロセッサ1103は、デジタルベースバンド信号処理を行うモデム・プロセッサ(e.g., Digital Signal Processor(DSP))とコントロールプレーン処理を行うプロトコルスタック・プロセッサ(e.g., Central Processing Unit(CPU)、又はMicro Processing Unit(MPU))を含んでもよい。この場合、コントロールプレーン処理を行うプロトコルスタック・プロセッサは、後述するアプリケーションプロセッサ1104と共通化されてもよい。
アプリケーションプロセッサ1104は、CPU、MPU、マイクロプロセッサ、又はプロセッサコアとも呼ばれる。アプリケーションプロセッサ1104は、複数のプロセッサ(複数のプロセッサコア)を含んでもよい。アプリケーションプロセッサ1104は、メモリ1106又は図示されていないメモリから読み出されたシステムソフトウェアプログラム(Operating System(OS))及び様々なアプリケーションプログラム(例えば、通話アプリケーション、WEBブラウザ、メーラ、カメラ操作アプリケーション、音楽再生アプリケーション)を実行することによって、UE80の各種機能を実現する。
いくつかの実装において、図19に破線(1105)で示されているように、ベースバンドプロセッサ1103及びアプリケーションプロセッサ1104は、1つのチップ上に集積されてもよい。言い換えると、ベースバンドプロセッサ1103及びアプリケーションプロセッサ1104は、1つのSystem on Chip(SoC)デバイス1105として実装されてもよい。SoCデバイスは、システムLarge Scale Integration(LSI)またはチップセットと呼ばれることもある。
メモリ1106は、揮発性メモリ若しくは不揮発性メモリ又はこれらの組合せである。メモリ1106は、物理的に独立した複数のメモリデバイスを含んでもよい。揮発性メモリは、例えば、Static Random Access Memory(SRAM)若しくはDynamic RAM(DRAM)又はこれらの組み合わせである。不揮発性メモリは、マスクRead Only Memory(MROM)、Electrically Erasable Programmable ROM(EEPROM)、フラッシュメモリ、若しくはハードディスクドライブ、又はこれらの任意の組合せである。例えば、メモリ1106は、ベースバンドプロセッサ1103、アプリケーションプロセッサ1104、及びSoC1105からアクセス可能な外部メモリデバイスを含んでもよい。メモリ1106は、ベースバンドプロセッサ1103内、アプリケーションプロセッサ1104内、又はSoC1105内に集積された内蔵メモリデバイスを含んでもよい。さらに、メモリ1106は、Universal Integrated Circuit Card(UICC)内のメモリを含んでもよい。
メモリ1106は、上述の複数の実施形態で説明されたUE80による処理を行うための命令群およびデータを含むソフトウェアモジュール(コンピュータプログラム)を格納してもよい。いくつかの実装において、ベースバンドプロセッサ1103又はアプリケーションプロセッサ1104は、当該ソフトウェアモジュールをメモリ1106から読み出して実行することで、上述の実施形態で説明されたUE80の処理を行うよう構成されてもよい。
図20は、MECサーバ40の構成例を示すブロック図である。図20を参照すると、MECサーバ40は、ネットワークインターフェース1201、プロセッサ1202、及びメモリ1203を含む。ネットワークインターフェース1201は、ネットワークノード(e.g., リモートノード10、コアネットワーク40)と通信するために使用される。ネットワークインターフェース1201は、例えば、IEEE 802.3 seriesに準拠したネットワークインタフェースカード(NIC)を含んでもよい。
プロセッサ1202は、メモリ1203からソフトウェア(コンピュータプログラム)を読み出して実行することで、上述の実施形態においてシーケンス図及びフローチャートを用いて説明されたセンターノード20の処理を行う。プロセッサ1202は、例えば、マイクロプロセッサ、MPU、又はCPUであってもよい。プロセッサ1202は、複数のプロセッサを含んでもよい。
プロセッサ1202は、無線通信のためのデジタルベースバンド信号処理を含むデータプレーン処理とコントロールプレーン処理を行う。例えば、LTEおよびLTE-Advancedの場合、プロセッサ1004によるデジタルベースバンド信号処理は、PDCPレイヤ、RLCレイヤ、およびMACレイヤの信号処理を含んでもよい。さらに、プロセッサ1202による信号処理は、X2-Uインタフェース及びS1-UインタフェースでのGTP-U・UDP/IPレイヤの信号処理を含んでもよい。また、プロセッサ1004によるコントロールプレーン処理は、X2APプロトコル、S1-MMEプロトコルおよびRRCプロトコルの処理を含んでもよい。
プロセッサ1202は、複数のプロセッサを含んでもよい。例えば、プロセッサ1004は、デジタルベースバンド信号処理を行うモデム・プロセッサ(e.g., DSP)、X2-Uインタフェース及びS1-UインタフェースでのGTP-U・UDP/IPレイヤの信号処理を行うプロセッサ(e.g., DSP)、及びコントロールプレーン処理を行うプロトコルスタック・プロセッサ(e.g., CPU又はMPU)を含んでもよい。
メモリ1203は、揮発性メモリ及び不揮発性メモリの組み合わせによって構成される。メモリ1203は、プロセッサ1202から離れて配置されたストレージを含んでもよい。この場合、プロセッサ1202は、図示されていないI/Oインタフェースを介してメモリ1203にアクセスしてもよい。
図20の例では、メモリ1203は、ソフトウェアモジュール群を格納するために使用される。プロセッサ1202は、これらのソフトウェアモジュール群をメモリ1203から読み出して実行することで、上述の実施形態において説明されたMECサーバ40の処理を行うことができる。
図18〜図20を用いて説明したように、上述の実施形態におけるeNB60、MECサーバ40、及びUE80が有するプロセッサの各々は、図面を用いて説明されたアルゴリズムをコンピュータに行わせるための命令群を含む1又は複数のプログラムを実行する。
上述の例において、プログラムは、様々なタイプの非一時的なコンピュータ可読媒体(non-transitory computer readable medium)を用いて格納され、コンピュータに供給することができる。非一時的なコンピュータ可読媒体は、様々なタイプの実体のある記録媒体(tangible storage medium)を含む。非一時的なコンピュータ可読媒体の例は、磁気記録媒体(例えばフレキシブルディスク、磁気テープ、ハードディスクドライブ)、光磁気記録媒体(例えば光磁気ディスク)、CD−ROM(Read Only Memory)、CD−R、CD−R/W、半導体メモリ(例えば、マスクROM、PROM(Programmable ROM)、EPROM(Erasable PROM)、フラッシュROM、RAM(Random Access Memory))を含む。また、プログラムは、様々なタイプの一時的なコンピュータ可読媒体(transitory computer readable medium)によってコンピュータに供給されてもよい。一時的なコンピュータ可読媒体の例は、電気信号、光信号、及び電磁波を含む。一時的なコンピュータ可読媒体は、電線及び光ファイバ等の有線通信路、又は無線通信路を介して、プログラムをコンピュータに供給できる。
なお、本発明は上記実施の形態に限られたものではなく、趣旨を逸脱しない範囲で適宜変更することが可能である。また、本発明は、それぞれの実施の形態を適宜組み合わせて実施されてもよい。