JP2024047106A

JP2024047106A - トラフィックの特性に応じて効率的に通信パラメータを変更する端末装置

Info

Publication number: JP2024047106A
Application number: JP2022152532A
Authority: JP
Inventors: 洋樹武田; 賢一山本; 泰成渡部
Original assignee: KDDI Corp
Current assignee: KDDI Corp
Priority date: 2022-09-26
Filing date: 2022-09-26
Publication date: 2024-04-05
Also published as: WO2024070471A1

Abstract

【課題】様々なトラフィックパターンでの通信が同時に実行されることが想定される状況において、適切な通信制御を提供すること【解決手段】端末装置は、端末装置によって実行されるアプリケーションが生成するフレームが複数のパケットに分割されて送信される場合の、先頭のパケットと最後尾のパケットとを認識し、先頭のパケットの受信時間を測定し、その測定結果から、フレーム周期とそのフレーム周期の揺らぎを算出し、算出結果を基地局装置へ報告する。端末装置は、基地局装置から、報告対象とすべきフレームに関する情報を取得する。【選択図】図９

Description

本発明は、セルラ通信システムにおける通信パラメータの変更技術に関する。

セルラ通信システムでは、ＣｏｎｆｉｇｕｒｅｄＧｒａｎｔ（ＣＧ）機能、Ｓｅｍｉ－ＰｅｒｓｉｓｔｅｎｔＳｃｈｅｄｕｌｉｎｇ（ＳＰＳ）機能といった無線リソースを定期的に割り当てることで通信を効率的に行う機能が、使用されうる。第３世代パートナーシッププロジェクト（３ＧＰＰ（登録商標））のリリース１７規格に向けて、アプリケーションのトラフィックパターンに合わせて、ＣＧ機能、ＳＰＳ機能のパラメータを最適化し、通信容量を改善する技術が提案されている（非特許文献１）。

３ＧＰＰ寄書、ＲＰ－２２０２８５、２０２２年３月

実際のアプリケーショントラフィックでは、様々なトラフィックパターンでの通信が同時に実行されることが想定される。

本発明は、このような状況において、それらのトラフィックパターンに応じた、適切な通信制御技術を提供する。

本発明の一態様による端末装置は、前記端末装置によって実行されるアプリケーションが生成するフレームが複数のパケットに分割されて送信される場合の、先頭のパケットと最後尾のパケットとを認識する認識手段と、前記認識手段で認識した前記先頭のパケットの受信時間を測定する測定手段と、前記測定手段による測定結果から、フレーム周期と当該フレーム周期の揺らぎを算出する算出手段と、前記算出の結果を基地局装置へ報告する報告手段と、前記基地局装置から、前記報告手段による報告対象とすべきフレームに関する情報を取得する取得手段と、を有する。

本発明の一態様による端末装置は、ＣｏｎｆｉｇｕｒｅｄＧｒａｎｔによって上りリンクのデータを送信する送信手段と、基地局装置から、ＣｏｎｆｉｇｕｒｅｄＧｒａｎｔの周期と無線リソースブロックの割り当て情報を、レイヤ３のシグナリングによって取得する取得手段と、前記基地局装置から前記ＣｏｎｆｉｇｕｒｅｄＧｒａｎｔの周期とリソースブロックの割り当て情報の変更指示を、レイヤ１又はレイヤ２のシグナリングによって受信する受信手段と、前記基地局装置に対して無線リソースブロックの割り当てタイミングの変更を要求する要求手段と、を有する。

本発明によれば、トラフィックパターンに応じた、適切な通信制御を実施することができる。

無線通信ネットワークの構成例を示す図である。ＳＰＳパラメータの変更例を示す図である。ＣＧパラメータの変更例を示す図である。ＣＤＲＸパラメータの変更例を示す図である。複数のＤＲＸパラメータの制御例を示す図である。装置のハードウェア構成例を示す図である。基地局装置の機能構成例を示す図である。端末装置の機能構成例を示す図である。無線通信ネットワークにおいて実行される処理の流れの例を示す図である。

以下、添付図面を参照して実施形態を詳しく説明する。なお、以下の実施形態は特許請求の範囲に係る発明を限定するものではなく、また実施形態で説明されている特徴の組み合わせの全てが発明に必須のものとは限らない。実施形態で説明されている複数の特徴のうち二つ以上の特徴は任意に組み合わされてもよい。また、同一若しくは同様の構成には同一の参照番号を付し、重複した説明は省略する。

（システム構成）
図１に、本実施形態に係る無線通信システムの構成例を示す。無線通信システムは、例えば、第３世代パートナーシッププロジェクト（３ＧＰＰ（登録商標））の第５世代（５Ｇ）のセルラ通信規格に準拠した無線通信システムでありうる。無線通信システムは、例えば、基地局装置１０１、及び、端末装置１１１、及び、コアネットワーク装置１２１、アプリケーションサーバー１３１を含む。一例において、端末装置１１１は、基地局装置１０１、コアネットワーク装置１２１を経由して、アプリケーションサーバー１３１とアプリケーショントラフィックに関するユーザーデータを送受信する。

アプリケーショントラフィックは、アプリケーションによって生成されて他の装置に送信される必要のある、又はアプリケーションによって使用されるために他の装置から受信されるトラフィックであり、様々な態様を取りうる。例えば、映像ストリーミング、クラウドゲーミング、ハプティック通信、タクタイル通信、メタバースを実現するアプリケーションなど、様々なアプリケーションによってデータが生成されて送受信される。ここで、アプリケーショントラフィックは、それぞれ異なる特性やデータ発生周期を有する複数のデータの集合体として捉えることができる。例えば、アプリケーションがゲームアプリケーションである場合、アプリケーショントラフィックは、映像情報、音声情報、操作情報などを含む。また、例えば、アプリケーションが映像ストリーミングアプリケーションである場合、アプリケーショントラフィックは、映像情報と音声情報との集合体として定義されうる。また、映像情報は、例えば、ＧＯＰ（ＧｒｏｕｐｏｆＰｉｃｔｕｒｅｓ）で構造化される異なる種別の映像フレーム、すなわち、Ｉピクチャ（Ｉフレーム）、Ｐピクチャ（Ｐフレーム）、Ｂピクチャ（Ｂフレーム）に分類されうる。なお、Ｉフレーム、Ｐフレーム、Ｂフレームは、それぞれ異なる周期で（例えば端末装置１１１とアプリケーションサーバー１３１との間で）送受信される。

アプリケーショントラフィックに含まれる上述のような複数の種別の送受信対象データは、遅延が許容されるデータと、遅延が許容されないデータとを含みうる。例えば、上述のＩフレーム、Ｐフレーム、Ｂフレームのうち、Ｉフレームは、他のフレームとの依存関係がなく、単独で復号（デコード）及び画像の生成が可能なフレームである一方、Ｐフレームは、過去のフレームから予測したデータとの差分を符号化したものであり、Ｂフレームは、過去、未来両方のフレームから予測したデータとの差分を符号化したものであるため、他のフレームに依存している。すなわち、Ｉフレームが遅延なく正確に受信されることが、ＰフレームやＢフレームの正確なデコードを可能とするため、Ｉフレームは遅延が許容されないデータと言うことができる。一方で、ＰフレームやＢフレームは必ずしも遅延が許容されないわけではない。このようなアプリケーショントラフィックに対しては、遅延が許容されないデータについて、遅延を発生させないよう、定期的に、無線リソースを割り当てることが要求される。一方で、遅延が許容されるデータについても、定期的に無線リソースを割り当てるようＣＧ機能、ＳＰＳ機能のパラメータを設定することはできるが、その場合、周期的に不必要に無線リソースが確保されることとなりうる。このため、その周期において、必ずしも無線リソースを確保する必要のないデータ送信のために無線リソースが確保されてしまっているため、他の端末装置が送信することを要求する、遅延が許容されないデータのために割り当て可能な無線リソースの不足を招きうる。

本実施形態では、このような事情に鑑み、さまざまなトラフィックパターンでの通信が同時に実行されることが想定される場合に、例えば、上記Ｉフレーム（キーフレーム）のような、アプリケーションの動作に大きく影響するデータについてのトラフィックパターンが特定されるようにする。そして、送受信遅延、送受信周期、ジッタ（周期のゆらぎ）などが規定値以内に収められるように、リソース割り当てが行われるようにする。以下では、そのようなトラフィックパターンの特定や無線リソースの割り当てを可能とするための技術について説明する。なお、以下では、アプリケーショントラフィックとして、Ｉフレーム、Ｐフレーム、Ｂフレームのそれぞれに対応する映像フレームデータが送受信される場合の例について言及することがあるが、これはデータの一例に過ぎず、様々な形式のデータの組み合わせからなるアプリケーショントラフィックに対して、以下の議論を適用することができる。

本実施形態では、例えば、コアネットワーク装置１２１が、トラフィックパターンの特定を行うフレーム種別を決定する。この場合、コアネットワーク装置１２１は、基地局装置１０１に対して、トラフィックパターンの特定を行う対象とするフレーム種別（例えば、Ｉフレーム、Ｐフレーム、Ｂフレームの少なくともいずれか）に関する情報を通知する。また、この時、トラフィックパターンの特定の対象となるフレームについての特性を示すフレーム特性情報がコアネットワーク装置１２１から基地局装置１０１に対して通知されてもよい。フレーム特性情報は、例えば、フレームレート（ｆｒａｍｅｓｐｅｒｓｅｃｏｎｄ、ｆｐｓ）、データレート（Ｍｂｐｓ）、サービス品質（ＱｏＳ、ＱｕａｌｉｔｙｏｆＳｅｒｖｉｃｅ）、優先度（Ｐｒｉｏｒｉｔｙ）、パケットの伝送遅延の最大値（ＰａｃｋｅｔＤｅｌａｙＢｕｄｇｅｔ）、パケットエラー率（ＰａｃｋｅｔＥｒｒｏｒＬｏｓｓＲａｔｅ）、１フレームあたりのパケット数、ＰＤＵ数などの少なくともいずれかを含む。また、上記のトラフィックパターンの特定の対象とするフレーム種別に関する情報、および、関連するフレーム特性情報は、下りリンク方向（アプリケーションサーバー１３１→端末装置１１１）と上りリンク方向（端末装置１１１→アプリケーションサーバー１３１）とで、別々に通知されてもよい。これにより、例えば、上りリンク送信がボトルネックとなるようなＴＤＤ通信方式を用いる場合に、端末装置１１１から基地局装置１０１へ信号が送信される方向の上りリンク通信に関するトラフィックパターンを特定して、ＣＧ機能のパラメータの最適化などを行うことが可能になる。また、上りリンク方向（端末装置１１１→アプリケーションサーバー１３１）のトラフィックパターンの特定には、特定の対象のフレーム種別に関する情報、および、関連するフレーム特性情報を、端末装置１１１が取得することが必要となる。この場合、端末装置１１１は、例えば、基地局装置１０１又はコアネットワーク装置１２１から必要な情報を取得する。

アプリケーションサーバー１３１から送信されるフレームは、コアネットワーク装置１２１及び基地局装置１０１を経由して、端末装置１１１へ送信される。基地局装置１０１は、トラフィックパターンの特定の対象のフレームをコアネットワーク装置１２１から受信するたびに、その受信時間と、受信したフレームのデータサイズとを記録する。基地局装置１０１は、記録した受信時間から、受信するフレームの周期や、ジッタ（周期のゆらぎ）を算出する。そして、基地局装置１０１は、算出されたフレーム周期の情報を、ＳＰＳやＣＧのパラメータ決定に用いることが出来る。この際、フレーム周期やフレームデータサイズが複数存在する場合、基地局装置１０１は、その複数のフレーム周期やフレームデータサイズに対する統計処理を施してもよい。例えば、基地局装置１０１は、複数のフレーム周期についての最頻値や平均値、及び、標準偏差を特定し、トラフィックパターンの特定対象のデータについてのフレームの周期としてその最頻値や平均値を使用し、トラフィックパターンの特定対象のデータについてのジッタ（周期のゆらぎ）として、その標準偏差を使用することができる。

一つの実施例として、基地局装置１０１と端末装置１１１の間に、フレームの種別毎に、異なるＰＤＵｓｅｓｓｉｏｎを確立することが考えられる。この場合、基地局装置１０１は、ＰＤＵｓｅｓｓｉｏｎごとに受信するフレームの受信時間と、受信するフレームのサイズとをカウントする。これによれば、基地局装置１０１は、ＰＤＵｓｅｓｓｉｏｎを用いて、複数の種別のフレームのそれぞれを容易に区別して、フレームの受信時間とサイズとをフレームの種別ごとにカウントすることができる。また、別の実施例として、同一のＰＤＵｓｅｓｓｉｏｎ内に、フレームの種別毎に異なるＱｏＳｆｌｏｗが確立されることも考えうる。この場合、基地局装置１０１は、ＱｏＳｆｌｏｗごとに受信するフレームの受信時間と、受信するフレームのサイズとをカウントする。これによれば、基地局装置１０１は、ＱｏＳｆｌｏｗを用いて、複数の種別のフレームのそれぞれを容易に区別して、フレームの受信時間とサイズとをフレームの種別ごとにカウントすることができる。また、同一のＱｏＳｆｌｏｗ内で、複数の種別のフレームのユーザーデータが送受信されることも考えうる。この場合、アプリケーションサーバー１３１やコアネットワーク装置１２１などの上位レイヤを処理する装置において、フレームの種別を識別するための識別子がユーザーデータに付与される。そして、ＰＤＣＰ、ＲＬＣ、ＭＡＣ等の基地局装置１０１を構成するいずれかの機能部で、付与された識別子によってフレームの種別が認識され、フレームの種別毎に、フレームの受信時間、受信するフレームのサイズがカウントされる。また、フレームの種別毎に、それぞれ異なるネットワークスライスが割り当てられてもよい。この場合、カウントすべき種別のフレームに対応するネットワークスライスが使用するＰＤＵｓｅｓｓｉｏｎにおいて送受信されるデータがカウントされうる。なお、ひとつのネットワークスライスが複数のＰＤＵｓｅｓｓｉｏｎによって実現される場合は、当該ネットワークスライスに紐づけられるすべてのＰＤＵｓｅｓｓｉｏｎで送受信されるデータがカウントされうる。上記実施例において、アプリケーションサーバー１３１はＡＦ（ＡｐｐｌｉｃａｔｉｏｎＦｕｎｃｔｉｏｎ）、コアネットワーク装置１２１はＵＰＦ（ＵｓｅｒＰｌａｎｅＦｕｎｃｔｉｏｎ）、基地局装置１０１は、ｇＮＢでありうる。

基地局装置１０１においてコアネットワーク装置１２１から受信されるフレームは、１フレームが複数パケットに分割されて送受信されるバーストデータでありうる。この場合、基地局装置１０１は、いずれのパケットがそのフレームの先頭のパケット（最初に受信されたパケット）であり、いずれのパケットがそのフレームの最後尾のパケット（最後に受信されたパケット）であるかを認識する必要がある。このため、例えばコアネットワーク装置１２１が、各パケットのＲＴＰヘッダの情報から、フレーム種別と、そのパケットがフレームの先頭のパケットであるか否か、及び、そのパケットがフレームの最後尾のパケットであるか否かを判定することが考えうる。コアネットワーク装置１２１は、例えば、その判定の結果、各フレームの先頭のパケットと最後尾のパケットに、それぞれ識別子を付与することができる。基地局装置１０１は、付与された識別子から、そのパケットがフレームの先頭のパケットであるか、フレームの最後尾のパケットであるかを判定することができる。また、別の実施例において、コアネットワーク装置１２１から基地局装置１０１に対して１フレームあたりのパケット数が通知されてもよく、この場合、基地局装置１０１は、通知された１フレームあたりのパケット数の情報から、先頭のパケットと、最後尾のパケットとを特定してもよい。基地局装置１０１は、例えば、先頭のパケットの受信時間のみをカウントすることにより、フレームの周期を特定することができる。また、１フレームあたりのパケット数が動的に変化する場合、コアネットワーク装置１２１は、その変更を認識したタイミングにおいて、基地局装置１０１へ１フレームあたりのパケット数を通知しうる。

一実施形態において、基地局装置１０１から端末装置１１１へ、トラフィックパターンの特定と、フレーム周期の計測を指示する。この場合、トラフィックパターンの特定を行うフレーム種別が、基地局装置１０１から端末装置１１１へ通知されうる。この場合、さらに、例えば映像フレームのトラフィックパターンの特定を行う際のフレームレート（ｆｒａｍｅｓｐｅｒｓｅｃｏｎｄ、ｆｐｓ）等の、前述のフレームの特性情報が、基地局装置１０１から端末装置１１１へ通知されうる。また、基地局装置１０１は、特定したトラフィックパターンの報告の周期や期間、報告のフォーマット、形式に関わる情報を、端末装置１１１へ通知しうる。端末装置１１１は、通知された情報に基づき、基地局装置１０１へ送信するフレームのうち、特定対象の種類のフレームのトラフィックパターンとフレームの周期を測定する。そして、端末装置１１１は、基地局装置１０１から指定された周期や期間において、指定されたフォーマットや形式を用いて、基地局装置１０１へ測定結果を報告しうる。なお、基地局装置１０１は、端末装置１１１に対して、複数測定されるフレーム周期の測定データの統計処理を指示しうる。基地局装置１０１は、例えば、フレーム周期の平均値、最大値、最小値、最頻値、標準偏差などの統計情報を報告するように、端末装置１１１へ指示を送信する。また、基地局装置１０１は、測定されるフレーム周期の測定データのすべて、又は、特定の条件に合致する一部のデータを報告してもよい。

また、一例において、アプリケーションサーバー１３１から、コアネットワーク装置１２１を介して、基地局装置１０１に対して、各フレームで送信されるデータのジッタ（周期のゆらぎ）の許容値、パケットの伝送遅延の最大値（ＰａｃｋｅｔＤｅｌａｙＢｕｄｇｅｔ）が通知されてもよい。この場合、基地局装置１０１は、実際に測定したフレーム周期の標準偏差やジッタ（フレーム周期のゆらぎ）を、コアネットワーク装置１２１から通知された許容可能なジッタの許容値と比較し、比較結果をコアネットワーク装置１２１へ通知する。なお、基地局装置１０１は、実際に測定したフレーム周期の標準偏差やジッタ（フレーム周期のゆらぎ）をコアネットワーク装置１２１へ通知してもよい。この場合、測定値と許容値との比較は、コアネットワーク装置１２１やアプリケーションサーバー１３１によって実施されうる。アプリケーションサーバー１３１は、コアネットワーク装置１２１を介して、基地局装置１０１に対して、アプリケーションに必要な回線を確立する際にジッタの許容値やパケットの伝送遅延の最大値を通知しうる。この場合、基地局装置１０１は、過去に実測したジッタや遅延から、そのアプリケーションに必要な回線に求められる通信品質を担保可能であるか否かを判定し、その判定結果を、コアネットワーク装置１２１やアプリケーションサーバー１３１へ通知してもよい。

また、アプリケーションサーバー１３１は、コアネットワーク装置１２１、基地局装置１０１を介して、端末装置１１１に対して、アプリケーションに必要な回線を確立する際にジッタの許容値やパケットの伝送遅延の最大値を通知しうる。この場合、端末装置１１１は、過去に実測したジッタや遅延から、そのアプリケーションに必要な回線に求められる通信品質を担保可能であるか否かを判定し、その判定結果を、基地局装置１０１、コアネットワーク装置１２１やアプリケーションサーバー１３１へ通知してもよい。なお、フレーム周期は、基地局装置１０１、端末装置１１１の内部のＳＤＡＰ（ＳｅｒｖｉｃｅＤａｔａＡｄａｐｔａｔｉｏｎＰｒｏｔｏｃｏｌ）、ＰＤＣＰ（ＰａｃｋｅｔＤａｔａＣｏｎｖｅｒｇｅｎｃｅＰｒｏｔｏｃｏｌ）、ＲＬＣ（ＲａｄｉｏＬｉｎｋＣｏｎｔｒｏｌ）、ＭＡＣ（ＭｅｄｉｕｍＡｃｃｅｓｓＣｏｎｔｒｏｌ）など内部の複数の機能ブロックにおいて、測定されうる。また、ジッタ（フレーム周期のゆらぎ）も、同様に、基地局装置１０１、端末装置１１１の内部の複数の機能ブロックにおいて測定されうる。また、パケットの伝送遅延についても、基地局装置１０１と端末装置１１１とのそれぞれにおいて、伝送遅延をどのように定義するかによって、測定値や許容値が異なりうる。伝送遅延は、一例として、基地局装置１０１のＳＤＡＰ（ＳｅｒｖｉｃｅＤａｔａＡｄａｐｔａｔｉｏｎＰｒｏｔｏｃｏｌ）機能ブロックがコアネットワーク装置１２１からフレームを受信してから、そのフレームが含まれるＰＤＳＣＨの送信開始までの期間として定義されうる。ただし、これは一例であり、他の定義が当然に可能である。このため、コアネットワーク装置１２１やアプリケーションサーバー１３１と基地局装置１０１、又は、端末装置１１１が、フレーム周期、ジッタ（フレーム周期のゆらぎ）、伝送遅延について、同一の定義を使用することができるように、コアネットワーク装置１２１やアプリケーションサーバー１３１から基地局装置１０１又は端末装置１１１へ、フレーム周期、ジッタ（フレーム周期のゆらぎ）、伝送遅延の定義に関する情報が通知されてもよい。

本実施形態では、基地局装置１０１は、自装置において特定したトラフィックパターンやフレーム周期に基づいて、半固定スケジューリング（Ｓｅｍｉ－ＰｅｒｓｉｓｔｅｎｔＳｃｈｅｄｕｌｉｎｇ（ＳＰＳ））を用いて、端末装置１１１へ下りリンクのフレームを送信するための無線リソースを周期的に割り当てる。例えば、基地局装置１０１は、フレーム周期ごとに、１フレームを構成するデータを送信するのに十分な下りリンクのリソースブロックを端末装置１１１に割り当てる設定を行うことができる。周期的なリソース割り当てを行うための半固定スケジューリング（ＳＰＳ）は、レイヤ３のシグナリング（ＲＲＣＲｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージ）を用いて行われ、下りリンクのリソース割り当て周期は、そのＲＲＣＲｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージ内のＳＰＳ－Ｃｏｎｆｉｇに含まれるｐｅｒｉｏｄｉｃｉｔｙによって設定することが考えられる。なお、通信中にフレームの周期が変化する場合、基地局装置１０１は、リソース割り当ての周期を、レイヤ１又はレイヤ２のシグナリングで変更しうる。また、基地局装置１０１は、レイヤ３のシグナリングで、複数の周期をあらかじめ設定しておき、レイヤ１又はレイヤ２のシグナリングによって、実際に使用する周期を指示するようにしてもよい。また、基地局装置１０１は、端末装置１１１に割り当てるリソースブロックを、特定したトラフィックパターンによって決定し、物理下りリンク制御チャネル（ＰＤＣＣＨ）に含まれる下りリンク制御情報（ＤＣＩ）を用いて、端末装置１１１に指示してもよい。ここで、図２の「１」と「２」のように、第１のＳＰＳ周期として５ｍｓ、第２のＳＰＳ周期として２０ｍｓが、レイヤ３シグナリングによって設定されているものとする。なお、「ｍｓ」は「ミリ秒」を指し、図２における１つのＳｕｂｆｒａｍｅが１ｍｓに対応する。ここで、例えば、図２の「１」に示されるように、５ｍｓのＳＰＳ周期が使用されている間に、アプリケーショントラフィックの周期が２０ｍｓとなったものとする。この場合、基地局装置１０１は、ＰＤＣＣＨで送信されるＤＣＩを用いて、ＳＰＳ周期を第１の周期５ｍｓから、図２の「２」に示される第２の周期２０ｍｓへ変更するように、端末装置１１１へ指示を送信しうる。また、端末装置１１１へ送信されるフレームが、複数パケットに分割されて送信されるバーストデータである場合、基地局装置１０１は、フレームの先頭のパケットが送信される周期に基づいて、周期的なリソース割り当ての開始、つまり、半固定スケジューリング（ＳＰＳ）の有効化を指示しうる。また、基地局装置１０１は、フレームの最後尾のパケットの送信タイミングに基づいて、周期リソース割り当ての終了、つまり、半固定スケジューリング（ＳＰＳ）の無効化を指示しうる。なお、上述の実施形態では、ＤＣＩが周期的に送信される例について説明したが、周期毎に送信されるフレームサイズが同一である場合や、特定サイズの幅に収まる場合、周期的に送信に割り当てられるリソースブロックのサイズや位置が同じであることが考えられ、その場合は、ＤＣＩの送信が省略されてもよい。

また、別の実施形態では、基地局装置１０１が、コアネットワーク装置１２１からフレームを受信してから、実際にそのフレームを端末装置１１１へ送信するまでに要する時間を計測する。例えば、図２の「１」や「２」の例では、基地局装置１０１は、ＳＦＮ＝０又は２かつＳｕｂｆｒａｍｅ＝１の時点で、コアネットワーク装置１２１から端末装置１１１へ送信すべきフレームを受信する。そして、基地局装置１０１は、同じＳＦＮのＳｕｂｆｒａｍｅ＝５の時点において、ＰＤＣＣＨで下りリンクのデータ送信のための制御情報を、また、同じＳＦＮのＳｕｂｆｒａｍｅ＝６～８の期間において、物理下りリンク共有チャネル（ＰＤＳＣＨ）でそのフレームの下りリンクデータを、それぞれ端末装置１１１へ送信する。この場合は、基地局装置１０１において、コアネットワーク装置１２１からフレームが受信されてから、そのフレームが端末装置１１１へ送信開始されるまでに４ｍｓの時間を要することとなる。基地局装置１０１は、計測した送信開始までに要する時間が、コアネットワーク装置１２１から通知されたパケットの伝送遅延の最大値（ＰａｃｋｅｔＤｅｌａｙＢｕｄｇｅｔ）に収まるように、端末装置１１１への下りリンクのデータ送信のタイミングを変更する。例えば、基地局装置１０１は、物理下りリンク制御チャネル（ＰＤＣＣＨ）に含まれる下りリンク制御情報（ＤＣＩ）の送信タイミングを変更することで、下りリンクのデータ送信のタイミングを変更する。例えば、図２の「２」のような状態で通信が行われている状態において、パケットの伝送遅延が、アプリケーションデータの到着完了からＰＤＳＣＨの送信開始までの時間と定義され、パケットの伝送遅延の最大値（ＰａｃｋｅｔＤｅｌａｙＢｕｄｇｅｔ）が２ｍｓであるものとする。この場合、基地局装置１０１は、図２の「３」に示すように、ＳＦＮ＝０かつＳｕｂｆｒａｍｅ＝８におけるＰＤＳＣＨの送信後に、次のＰＤＣＣＨの送信タイミングをＳＦＮ＝２かつＳｕｂｆｒａｍｅ＝５のタイミングからＳＦＮ＝２かつＳｕｂｆｒａｍｅ＝２のタイミングへシフトする。Ｓｕｂｆｒａｍｅの長さは１ｍｓであるから、これにより、遅延時間をＰａｃｋｅｔＤｅｌａｙＢｕｄｇｅｔの２ｍｓ以下となる１ｍｓへ短縮することができる。また、図２では、ＰＤＣＣＨの送信タイミングを調整したが、これに限られない。例えば、基地局装置１０１は、ＰＤＣＣＨをＳＦＮ＝１かつＳｕｂｆｒａｍｅ＝５のタイミングで送信し、そのＰＤＣＣＨによって指定されるＰＤＳＣＨの送信タイミングをＳＦＮ＝２かつＳｕｂｆｒａｍｅ＝２～４のタイミングとすることにより、データの送信タイミングがシフトされるようにしてもよい。これによっても、遅延時間をＰａｃｋｅｔＤｅｌａｙＢｕｄｇｅｔの２ｍｓ以下へ短縮することができる。また、端末装置１１１に送信されるデータがバーストデータである場合は、基地局装置１０１は、半固定スケジューリング（ＳＰＳ）の有効化の際に、半固定スケジューリング（ＳＰＳ）の有効化を指示する下りリンク制御情報（ＤＣＩ）で、ＰＤＣＣＨやＰＤＳＣＨの送信タイミングを指示してもよい。この場合、計測した送信までに要する時間が最小となるように、タイミングの変更が指示されてもよい。なお、上記の説明では、パケットの伝送遅延を、アプリケーションデータの到着完了からＰＤＳＣＨの送信開始までの時間として説明したが、パケットの伝送遅延を、アプリケーションデータの到着開始からＰＤＳＣＨの送信完了までとすること、アプリケーションデータの到着完了からＰＤＣＣＨの送信開始までとする等、パケットの伝送遅延が別の形式で定義されてもよい。
また、一実施形態において、基地局装置１０１は、端末装置１１１から報告されるトラフィックパターンやフレーム周期に基づいて、ＣｏｎｆｉｇｕｒｅｄＧｒａｎｔ（ＣＧ）を用いて、端末装置１１１が、基地局装置１０１へ上りリンクフレームを送信するための無線リソースを周期的に割り当てうる。例えば、基地局装置１０１は、１フレームを構成するデータを送信するのに十分な上りリンクのリソースブロックを、フレーム周期ごとに、端末装置１１１に割り当てる設定を行うことができる。基地局装置１０１は、周期的なリソース割り当てを行うためのＣＧの設定を、レイヤ３のシグナリング（ＲＲＣＲｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージ）を用いて行うことができる。この場合、上りリンクのリソースブロックに関する設定は、ＲＲＣＲｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージ内の、ｒｒｃ－ＣｏｎｆｉｇｕｒｅｄＵｐｌｉｎｋＧｒａｎｔに含まれるｔｉｍｅＤｏｍａｉｎＯｆｆｓｅｔ、ｔｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎ、ｆｒｅｑｕｅｎｃｙＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎを用いて設定されうる。また、リソース割り当て周期は、ＲＲＣＲｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージ内の、ＣｏｎｆｉｇｕｒｅｄＧｒａｎｔＣｏｎｆｉｇに含まれるｐｅｒｉｏｄｉｃｉｔｙを用いて設定されうる。なお、通信中にフレームの周期やサイズが変化する場合には、基地局装置１０１は、レイヤ１又はレイヤ２のシグナリングによって、リソース割り当ての周期や割り当てるリソースブロックを変更しうる。また、基地局装置１０１は、レイヤ３のシグナリングで、複数のリソース割り当ての周期や、複数の割り当てリソースブロックのパターンをあらかじめ設定しておき、レイヤ１又はレイヤ２のシグナリングで、実際に使用する設定を指示してもよい。ここで、図３の「１」と「２」のように、第１のＣＧ周期として５ｍｓ、第２のＣＧ周期として２０ｍｓが、レイヤ３シグナリングによって設定されているものとする。なお、図３においても、１つのＳｕｂｆｒａｍｅが１ｍｓに対応する。ここで、例えば、図３の「１」に示されるように、５ｍｓのＣＧ周期が使用されている間に、アプリケーショントラフィックの周期が２０ｍｓとなったものとする。この場合、基地局装置１０１は、例えば、ＳＦＮ＝０かつＳｕｂｆｒａｍｅ＝５の時点でデータ（物理上りリンク共有チャネル（ＰＵＳＣＨ）を受信したことに応答して、ＳＦＮ＝０かつＳｕｂｆｒａｍｅ＝６の時点で、そのＰＵＳＣＨへのＡＣＫ／ＮＡＣＫを示すＤＣＩを含んだＰＤＣＣＨを端末装置１１１へ送信する。このときに、基地局装置１０１は、そのＤＣＩを用いて、ＣＧ周期を、第１の周期の５ｍｓから第２の周期の２０ｍｓへ変更することを指示する情報を端末装置１１１へ送信しうる。また、端末装置１１１が送信するフレームが、１フレームが複数パケットに分割されて送信されるバーストデータである場合には、基地局装置１０１は、フレームの先頭のパケットが送信される周期に基づいて、周期的なリソース割り当ての開始、ＣＧの有効化を指示しうる。そして、基地局装置１０１は、フレームの最後尾のパケットの送信タイミングに基づいて、周期的なリソース割り当ての終了と、ＣＧの無効化を指示しうる。

また、別の実施形態では、端末装置１１１が、基地局装置１０１へ送信すべきフレームの発生を認識してから、そのフレームを基地局装置１０１へ実際に送信するまでに要する時間を計測する。端末装置１１１は、例えば、計測した送信までに要する時間が、コアネットワーク装置１２１から通知されたパケットの伝送遅延の最大値（ＰａｃｋｅｔＤｅｌａｙＢｕｄｇｅｔ）に収まるように、基地局装置１０１に対して、上りリンクのフレームの送信タイミングの補正を要求しうる。この場合、端末装置１１１は、送信フレームの発生を認識してから実際のフレーム送信までの待ち時間が最小となるように、又は、ＰａｃｋｅｔＤｅｌａｙＢｕｄｇｅｔに収まるように補正値を算出し、基地局装置１０１に対して補正値を通知しうる。基地局装置１０１は、端末装置１１１から受信した補正値に基づき、リソースブロックの割り当てタイミングを変更する。基地局装置１０１は、例えば、レイヤ１又はレイヤ２のシグナリングを用いて、現在の送信タイミングからのフレームやシンボルで表現される正／負のオフセットや、ＳＦＮ（ｓｙｓｔｅｍｆｒａｍｅｎｕｍｂｅｒ）を指定することにより、送信タイミングの変更を端末装置１１１へ指示しうる。例えば、図３の「２」のような状態で通信が行われている状態において、ＰａｃｋｅｔＤｅｌａｙＢｕｄｇｅｔが２ｍｓであるものとする。この場合、端末装置１１１は、図３の「３」に示すように、ＳＦＮ＝０かつＳｕｂｆｒａｍｅ＝５のＰＵＳＣＨを送信するタイミングで、レイヤ１又はレイヤ２のシグナリングを用いて、遅延が２ｍｓ以下となるように特定された補正値（たとえば、マイナス３ｍｓ）を用いたタイミング補正の要求を基地局装置１０１へ送信する。基地局装置１０１は、要求に含まれる補正値に基づき、ＳＦＮ＝２かつＳｕｂｆｒａｍｅ＝５のタイミングからＳＦＮ＝２かつＳｕｂｆｒａｍｅ＝２のタイミングへＰＵＳＣＨの送信タイミングをシフトする。この際に、基地局装置１０１は、端末装置１１１からの補正値に従うか否かの情報を端末装置へ返信しうる。また、基地局装置１０１は、端末装置１１１の通知する補正値と異なる値での補正を行う場合、その値を端末装置１１１へ通知してもよい。また、端末装置１１１が、送信フレームの発生を認識してから実際のフレーム送信までの待ち時間を基地局装置１０１へ報告し、基地局装置１０１が、待ち時間が最小となるように、又は、ＰａｃｋｅｔＤｅｌａｙＢｕｄｇｅｔに収まるように、補正値を決定して、送信タイミングを変更してもよい。例えば、図３の「１」や「２」の例では、端末装置１１１は、待ち時間が３ｍｓであることを基地局装置１０１へ通知し、基地局装置１０１は、自装置内で保持しているＰａｃｋｅｔＤｅｌａｙＢｕｄｇｅｔの値（２ｍｓ）と比較して、ＰＵＳＣＨの割り当てタイミングのシフト量（例えば２ｍｓ又は３ｍｓ）を決定しうる。そして、基地局装置１０１は、決定したシフト量だけ、ＰＵＳＣＨの割り当てタイミングをシフトさせ、さらに、そのＰＵＳＣＨの割り当てタイミングがシフトさせることやシフト量を示す値などを含んだ情報を端末装置１１１へ通知しうる。なお、基地局装置１０１は、例えば、ＳＦＮ＝０かつＳｕｂｆｒａｍｅ＝５のタイミングで受信したＰＵＳＣＨに対するＡＣＫ／ＮＡＣＫを送信するためのＤＣＩを含んだＰＤＣＣＨによって、その情報を端末装置１１１へ通知しうる。以上の方法により、ＳＦＮ＝２かつＳｕｂｆｒａｍｅ＝５のタイミングからＳＦＮ＝２かつＳｕｂｆｒａｍｅ＝２のタイミングへＰＵＳＣＨの割り当てタイミングが変更され、ＰａｃｋｅｔＤｅｌａｙＢｕｄｇｅｔ（＝２ｍｓ）を満たすようなタイミングでＰＵＳＣＨが送信されるようにすることができる。なお、上記の実施例では、伝送遅延として、端末装置１１１が、基地局装置１０１へ送信すべきフレームの発生を認識してから、そのフレームを基地局装置１０１へ実際に送信するまでに要する時間を計測するものと説明した。これは、実際には、端末装置１１１が、送信すべきフレームの発生を、ＳＤＡＰ（ＳｅｒｖｉｃｅＤａｔａＡｄａｐｔａｔｉｏｎＰｒｏｔｏｃｏｌ）、ＰＤＣＰ（ＰａｃｋｅｔＤａｔａＣｏｎｖｅｒｇｅｎｃｅＰｒｏｔｏｃｏｌ）、ＲＬＣ（ＲａｄｉｏＬｉｎｋＣｏｎｔｒｏｌ）、ＭＡＣ（ＭｅｄｉｕｍＡｃｃｅｓｓＣｏｎｔｒｏｌ）など内部の複数の機能ブロックにおいて、認識することによって行われうる。また、「送信するまで」とは、そのフレームのＰＤＳＣＨの送信開始までであるか、そのフレームのＰＤＳＣＨの送信完了までであるか、そのフレームのＰＤＳＣＨに対するＨＡＲＱ―ＡＣＫ受信までであるか、複数の解釈がありうる。このため、端末装置１１１と基地局装置１０１が、伝送遅延について同一の定義を認識することができるように、基地局装置１０１から端末装置１１１へ伝送遅延の定義に関する情報を通知してもよい。

また、基地局装置１０１は、自装置に多数の端末装置が接続されており、特定のアプリケーションを使用する端末装置１１１に対して、ＣＧによって無線リソースを周期的に割り当てることが難しい場合には、その端末装置１０１に対して、動的な無線リソースの割り当てを適用しうる。動的な無線リソースの割り当てでは、端末装置１１１は、上りリンクのデータの送信前に、バッファ・ステータス・レポート（ＢＳＲ）によって、送信データサイズ、送信バッファサイズを基地局装置１０１へ通知する。そして、基地局装置１０１は、通知された送信バッファサイズに基づいて、端末装置１１１が使用すべき上りリンクの無線リソースを割り当てる。ＢＳＲは、３ＧＰＰ規格によって定められる２種類のバッファ・サイズ・テーブルに定義されるいずれかの値によって、送信バッファサイズを通知するように構成されている。これに対して、本発明の一つの実施例では、基地局装置１０１が特定したフレームデータサイズにカスタマイズされた別のバッファ・サイズ・テーブルを用いて、ＢＳＲで送信バッファサイズが通知されるようにしうる。例えば、バッファ・サイズ・テーブルを５ビットとする場合、基地局装置１０１が計測したフレームデータサイズの最小値をバッファ・サイズ・テーブルの最低値として決定し、バッファ・サイズ・テーブルの最大値とその最低値との差分を２５－１＝３１で除算した値により、バッファサイズの大きさを示すステップとすることが考えられる。この場合、基地局装置１０１は、端末装置１１１に対して、バッファ・サイズ・テーブルのビット数と、バッファ・サイズ・テーブルの最低値及び最大値を通知する。そして、端末装置１１１は、基地局装置１０１から取得した情報に基づいて、バッファ・サイズ・テーブルを特定し、そのバッファ・サイズ・テーブルを用いて、ＢＳＲ送信時の送信バッファサイズをエンコードする。これにより、バッファ・サイズ・テーブルを基地局装置１０１と端末装置１１１との間で共有することができ、基地局装置１０１は、端末装置１１１と同じバッファ・サイズ・テーブルに基づいて、受信したＢＳＲにおいて示された送信バッファサイズをデコードすることができる。基地局装置１０１は、複数のバッファ・サイズ・テーブルに関する情報を、端末装置１１１に通知してもよい。この場合、端末装置１１１は、ＢＳＲ送信の際に、通知された複数のバッファ・サイズ・テーブルのうちのどのバッファ・サイズ・テーブルで送信バッファサイズが表現されているかを、基地局装置１０１へ通知しうる。また、端末装置１１１は、ＢＳＲ送信の際に、端末装置１１１が基地局装置１０１への送信フレームの発生を認識してから実際のフレームが送信されるまでの待ち時間を、送信バッファサイズとともに、基地局装置１０１へ通知してもよい。なお、上記では、基地局装置１０１がＢＳＲに用いるバッファ・サイズ・テーブルを設定する例について説明したが、これに限られない。すなわち、端末装置１１１が、バッファ・サイズ・テーブルの設定を基地局装置１０１へ要求してもよい。その場合、端末装置１１１は、バッファ・サイズ・テーブルのビット数と、バッファ・サイズ・テーブルの最低値及び最大値を基地局装置１０１へ通知しうる。また、このときに、端末装置１１１は、バッファ・サイズ・テーブルのビット数、中央値、１ビットの示すバッファサイズを、基地局装置１０１へ通知してもよい。

また、一実施形態において、基地局装置１０１が、特定したトラフィックパターン及びフレーム周期に基づいて、ＣＤＲＸ（ＣｏｎｎｅｃｔｅｄＤｉｓｃｏｎｔｉｎｕｏｕｓＲｅｃｅｐｔｉｏｎ）に関するパラメータを変更しうる。例として、図４の「１」に示すように、ｓｈｏｒｔＤＲＸ－Ｃｙｃｌｅ（ショートＤＲＸ周期）＝５ｍｓ、ｏｎＤｕｒａｔｉｏｎＴｉｍｅｒ（ＤＲＸＯＮを維持する期間を制御するタイマ）＝２ｍｓ、ｄｒｘ－ｉｎａｃｔｉｖｉｔｙＴｉｍｅｒ（ＰＤＣＣＨ受信後に一定時間ＤＲＸＯＮを維持するために起動するＤＲＸ非活性タイマ）＝３ｍｓでＣＤＲＸが動作している場合を例に、パラメータの変更方法について説明する。基地局装置１０１は、コアネットワーク装置１２１からフレームを受信する時間を計測することでフレームの周期を認識する。図４の「１」等においては、１ｍｓ、２１ｍｓ、４１ｍｓ（ＳＦＮ＝０、２、又は４のＳｕｂｆｒａｍｅ＝１）で端末装置１１１への送信フレームが発生しており、基地局装置１０１は、２０ｍｓ周期のフレームが発生していることを認識する。基地局装置１０１は、このフレーム周期に基づいて、例えば、図４の「２」に示すように、ｓｈｏｒｔＤＲＸ－Ｃｙｃｌｅを５ｍｓから１６ｍｓへ変更する、また、基地局装置１０１は、図４の「３」に示すように、ｄｒｘ－ＳｌｏｔＯｆｆｓｅｔ＝１６ｍｓを新たに設定してもよい。また、基地局装置１０１は、ｄｒｘ－ｉｎａｃｔｉｖｉｔｙＴｉｍｅｒを０ｍｓにしてｓｈｏｒｔＤＲＸ－Ｃｙｃｌｅを２０ｍｓとするパラメータ変更をしてもよい。基地局装置１０１は、例えば、ＳＦＮ＝０かつＳｕｂｆｒａｍｅ＝５の時点において、ＰＤＣＣＨで送信されるＤＣＩを用いて、パラメータの変更を端末装置１１１へ指示しうる。また、基地局装置１０１は、レイヤ３のシグナリングで、ｓｈｏｒｔＤＲＸ－Ｃｙｃｌｅ、ｄｒｘ－ＳｌｏｔＯｆｆｓｅｔ、ｄｒｘ－ｉｎａｃｔｉｖｉｔｙＴｉｍｅｒについて、複数の設定値をあらかじめ設定しておき、ＤＣＩで、実際に使用する設定値を指示してもよい。なお、特定したトラフィックパターンがＳｕｂｆｒａｍｅの整数倍とならない場合は、ｓｈｏｒｔＤＲＸ－Ｃｙｃｌｅ＝１６ｍｓ、ｓｈｏｒｔＤＲＸ－Ｃｙｃｌｅ＝１６ｍｓ、ｓｈｏｒｔＤＲＸ－Ｃｙｃｌｅ＝１７ｍｓというように、複数のｓｈｏｒｔＤＲＸ－Ｃｙｃｌｅを特定回数分繰り返してもよい。この場合は、第１のＤＲＸ－Ｃｙｃｌｅと、第１のＤＲＸ－Ｃｙｃｌｅの繰り返し回数、第２のＤＲＸ－Ｃｙｃｌｅと、第２のＤＲＸ－Ｃｙｃｌｅの繰り返し回数とで、ＤＲＸのパターンを端末装置１１１へ設定することになりうる。なお、この場合、ＤＲＸ－Ｃｙｃｌｅ周期の繰り返し回数は、ＤＣＩで指示されてもよい。また、ｓｈｏｒｔＤＲＸ－Ｃｙｃｌｅではなく、複数のｄｒｘ－ＳｌｏｔＯｆｆｓｅｔ、ｄｒｘ－ｉｎａｃｔｉｖｉｔｙＴｉｍｅｒについて複数の値が設定され、それぞれの値が特定の繰り返し回数分繰り返し使用されてもよい。

また、基地局装置１０１は、ＤＲＸＯＦＦの期間によって生じる、端末装置１１１への下りリンクのフレームの送信遅延を最小化するように、ＤＲＸＯＮ、ＤＲＸＯＦＦのタイミングを調整するためのオフセット値を端末装置へ通知しうる。図４の例では、調整を行わない場合は、図４の「１」に示すように、ＳＦＮ＝２かつＳｕｂｆｒａｍｅ＝１において送信フレームが発生し、そのフレームを送信するためのＰＤＣＣＨ（ＤＣＩ）が、ＳＦＮ＝２かつＳｕｂｆｒａｍｅ＝５において送信され、実際にフレームが送信されるのが、ＳＦＮ＝２かつＳｕｂｆｒａｍｅ＝６である。この場合、５ｍｓの遅延が発生する。この場合に、基地局装置１０１は、図４の「４」に示すように、ＳＦＮ＝０かつＳｕｂｆｒａｍｅ＝５において送信するＤＣＩにおいて、ｄｒｘ－ｉｎａｃｔｉｖｉｔｙＴｉｍｅｒ満了後に一度限り使用されるＤＲＸＯＮ開始までのオフセット値＝１３ｍｓを指示することが考えられる。端末装置１１１は、この一度限り使用されるＤＲＸＯＮ開始までのオフセット値を受信すると、図４の「４」に示すように、ＳＦＮ＝２かつＳｕｂｆｒａｍｅ＝２において、ＤＲＸＯＮすることになる。このため、基地局装置１０１は、送信フレームの発生後、遅延無く、下りリンクのデータを送信するためのＰＤＣＣＨ（ＤＣＩ）を送信することができる。なお、ここでは、基地局装置１０１において送信フレームが到達した直後に、下りリンクのデータを送信するためのＰＤＣＣＨ（ＤＣＩ）を送信可能となるように、ＤＲＸＯＮ、ＤＲＸＯＦＦのタイミングを調整するためのオフセット値が決定される例を示したが、これに限られない。すなわち、基地局装置１０１は、ＰａｃｋｅｔＤｅｌａｙＢｕｄｇｅｔに収まる範囲で、オフセット値を決定してもよい。基地局装置１０１は、アプリケーションが使用されている間、下りリンクのフレームの送信状況により動的に変動する遅延時間を周期的に確認し、その都度、必要に応じて、適切なオフセット値を決定し、端末装置１１１へＤＲＸＯＮ、ＤＲＸＯＦＦのタイミングの変更を指示しうる。

上記の例では、基地局装置１０１から端末装置１１１へ周期的に送信される下りリンクのアプリケーションフレームの周期に基づいて、ＣＤＲＸに関するパラメータを変更する例を示したが、端末装置１１１から基地局装置１０１へ周期的に送信される上りリンクのアプリケーションフレームの周期に基づいて、ＣＤＲＸに関するパラメータが変更されてもよい。この場合、基地局装置１０１は、端末装置１１１から報告されるトラフィックパターンやフレーム周期に基づいて、ｓｈｏｒｔＤＲＸ－Ｃｙｃｌｅ、ｄｒｘ－ＳｌｏｔＯｆｆｓｅｔ、ｄｒｘ－ｉｎａｃｔｉｖｉｔｙＴｉｍｅｒを変更する。また、ＤＲＸＯＦＦの期間によって生じる端末装置１１１から基地局装置１０１への上りリンクのフレームの送信遅延を最小化するように、端末装置１１１は、基地局装置１１１に対して、ＤＲＸＯＮ、ＤＲＸＯＦＦのタイミング補正を要求してもよい。このときに、端末装置１１１は、どの程度のタイミング補正が行われるべきかを示す補正値を、基地局装置１０１へ通知してもよい。一例として、端末装置１１１は、基地局装置１０１へＰＵＳＣＨを送信するタイミングにおいて、レイヤ１又はレイヤ２のシグナリングを用いて、ｄｒｘ－ｉｎａｃｔｉｖｉｔｙＴｉｍｅｒ満了後に一度限り使用されるＤＲＸＯＮ開始までのオフセット値を通知し、基地局装置１０１へＤＲＸＯＮ、ＤＲＸＯＦＦのタイミング補正を要求する。

また、考慮すべきトラフィックパターンやフレーム周期が２種類存在することも考えうる。例えば、図５に示すように、２０ｍｓ周期のフレーム（トラフィック１）と、１０ｍｓの周期のフレーム（トラフィック２）が同時に発生する場合には、それぞれの周期のフレームに対して、ＤＲＸ制御を行い、どちらかのＤＲＸがＯＮとなっている場合（ＯＲ条件）、つまり、図５においては、２ｍｓ～１０ｍｓ、１７ｍｓ～３０ｍｓ、３７ｍｓ～４９ｍｓにおいてＰＤＣＣＨをモニタするように端末装置１１１が制御されうる。また、図５の場合には、２０ｍｓ周期のフレーム（トラフィック１）を送信するためのＰＤＣＣＨ（ＤＣＩ）の送信タイミングを１０ｍｓの周期のフレーム（トラフィック２）のＰＤＣＣＨ（ＤＣＩ）の送信タイミングに合わせ、送信遅延を許容する代わりに、ＤＲＸＯＮの期間を長くできるように端末装置１１１が制御されてもよい。また、例えば、図５に示す２０ｍｓ周期のフレーム（トラフィック１）が、上りリンクのフレームの送信周期であるＣＧに基づくＤＲＸ制御であり、１０ｍｓの周期のフレーム（トラフィック２）が、下りリンクのフレームの送信周期であるＳＰＳに基づくＤＲＸ制御であってもよい。

なお、上記では、フレーム周期が２種類存在する場合の制御について説明したが、フレーム周期が２種類以上あってもよい。この場合、基地局装置１０１は、例えば、ＲＲＣＲｅｃｏｎｆｉｇｕｒａｔｉｏｎなどのレイヤ３のシグナリングで複数のＤＲＸ設定を端末装置１１１に設定し、ＤＣＩなどのレイヤ１又はレイヤ２のシグナリングで、どのＤＲＸ設定をアクティブにするか、デアクティブにするかを動的に指示しうる。端末装置１１１は、アクティブとするように指示を受けたＤＲＸ設定が複数存在する場合に、そのＤＲＸ設定のいずれかがＤＲＸＯＮとなっている場合に、ＰＤＣＣＨをモニタするように動作しうる。また、消費電力を最小とするために、送信遅延を許容する代わりに、複数あるうちの一つのＤＲＸ設定のみをアクティブとし、端末装置１１１がＰＤＣＣＨをモニタする時間を限定するように制御されてもよい。

また、端末装置１１１が基地局装置１０１へ送信するフレームが、１フレームが複数パケットに分割されて送信されるバーストデータである場合、又は、基地局装置１０１が端末装置１１１へ送信するフレームがバーストデータである場合には、フレームの先頭のパケットが送信される周期と、フレームの最後尾のパケットの送信タイミングから、バーストデータの周期とバーストデータの継続時間とが特定されうる。バーストデータの周期とバーストデータの継続時間に基づいて、ＤＲＸＯＮの周期とＤＲＸＯＮの継続時間、ＣＧ、ＳＰＳの周期的なリソース割り当てを実施する期間と実施しない期間、ＢＳＲの送信期間と非送信期間が決定されうる。また、ＢＳＲの送信禁止期間を制御するためのタイマｓｒ－ｐｒｏｈｉｂｉｔＴｉｍｅｒがバーストデータの周期とバーストデータの継続時間に基づいて決定されてもよい。また、バーストデータの周期、バースト周期当たりの受信データパケット数、受信データパケットのサイズが、コアネットワーク装置１２１やアプリケーションサーバー１３１から基地局装置１０１へ通知される場合、その通知された情報と、無線区間の伝送速度より、バーストデータの継続時間が理論的に算出されてもよい。

なお、本実施形態における基地局装置１０１から端末装置１１１への通知、指示、設定は、下りリンク制御情報（ＤＣＩ）を用いたレイヤ１のシグナリングや、下りリンクの媒体アクセス制御・制御エレメント（ＤＬＭＡＣＣＥ）を用いたレイヤ２のシグナリングによりなされうる。また、端末装置１１１から基地局装置１０１への通知、要求、報告は、上りリンク制御情報（ＵＣＩ）を用いたレイヤ１のシグナリングや、上りリンクの媒体アクセス制御・制御エレメント（ＵＬＭＡＣＣＥ）を用いたレイヤ２のシグナリングによりなされうる。また、上述のトラフィックパターンの特定、フレーム周期の計測、伝送遅延に関わる機能、ＳＰＳ、ＣＧ、ＤＲＸの周期やタイミングの変更、バッファ・サイズ・テーブルの設定などの各機能が端末装置において実装されているか否かについて、能力情報（ＵＥＣａｐａｂｉｌｉｔｙ）が基地局装置へ通知されてもよい。この場合、基地局装置１０１は、端末装置１１１によって通知された能力情報に応じて、各機能の実行を端末装置１１１へ指示しうる。

（装置の構成）
図６を用いて、基地局装置および端末装置のハードウェア構成例について説明する。基地局装置および端末装置は、一例において、プロセッサ２０１、ＲＯＭ２０２、ＲＡＭ２０３、記憶装置２０４、及び、通信回路２０５を含んで構成される。プロセッサ２０１は、汎用のＣＰＵ（中央演算装置）や、ＡＳＩＣ（特定用途向け集積回路）等の、１つ以上の処理回路を含んで構成されるコンピュータであり、ＲＯＭ２０２や記憶装置２０４に記憶されているプログラムを読み出して実行することにより、装置の全体の処理や、上述の各処理を実行する。ＲＯＭ２０２は、基地局装置および端末装置が実行する処理に関するプログラムや各種パラメータ等の情報を記憶する読み出し専用メモリである。ＲＡＭ２０３は、プロセッサ２０１がプログラムを実行する際のワークスペースとして機能し、また、一時的な情報を記憶するランダムアクセスメモリである。記憶装置２０４は、例えば着脱可能な外部記憶装置等によって構成される。通信回路２０５は、例えば、５Ｇやその後継規格の無線通信用の回路によって構成される。なお、図６では、１つの通信回路２０５が図示されているが、例えば基地局装置及び端末装置は、２つ以上の通信回路を有してもよい。また、例えば、基地局装置および端末装置は、５Ｇ用やその後継規格用の無線通信回路と共通のアンテナを有しうる。なお、基地局装置および端末装置は、５Ｇ用のアンテナとその後継規格用のアンテナとを別個に有してもよい。また、端末装置は、無線ＬＡＮ等の他の無線通信ネットワークのための通信回路を有してもよい。なお、基地局装置および端末装置は、使用可能な複数の周波数帯域のそれぞれについて別個の通信回路を有してもよいし、それらの周波数帯域の少なくとも一部に対して共通の通信回路を有してもよい。なお、本実施形態では、端末装置は、共通の周波数帯域での通信が可能な複数の通信回路を有するものとする。また、基地局装置は、さらに、他の基地局装置やコアネットワークのノードと通信する際に使用される有線通信回路を有しうる。

図７は、基地局装置の機能構成例を示す図である。基地局装置は、その機能として、例えば、ＳＤＡＰ（ＳｅｒｖｉｃｅＤａｔａＡｄａｐｔａｔｉｏｎＰｒｏｔｏｃｏｌ）機能部３０１、ＰＤＣＰ（ＰａｃｋｅｔＤａｔａＣｏｎｖｅｒｇｅｎｃｅＰｒｏｔｏｃｏｌ）機能部３０２、ＲＬＣ（ＲａｄｉｏＬｉｎｋＣｏｎｔｒｏｌ）機能部３０３、ＭＡＣ（ＭｅｄｉｕｍＡｃｃｅｓｓＣｏｎｔｒｏｌ）機能部３０４、トラフィックパターン測定部３０５、通信パラメータ制御部３０６を有する。なお、図７では、本実施形態に特に関係する機能のみを示しており、基地局装置が有しうる他の各種機能については図示を省略している。例えば、基地局装置は、５Ｇやその後継規格の基地局装置が一般的に有する他の機能を当然に有する。また、図７の機能ブロックは概略的に示したものであり、それぞれの機能ブロックが一体化されて実現されてもよいし、さらに細分化されてもよい。また、図７の各機能は、例えば、プロセッサ２０１がＲＯＭ２０２や記憶装置２０４に記憶されているプログラムを実行することにより実現されてもよいし、例えば通信回路２０５の内部に存在するプロセッサが所定のソフトウェアを実行することによって実現されてもよい。なお、各機能部が実行する処理の詳細について、上述の詳細についてはここでは説明せず、その大まかな機能のみを概説する。

ＳＤＡＰ機能部３０１、ＰＤＣＰ機能部３０２、ＲＬＣ機能部３０３、及び、ＭＡＣ機能部３０４は、それぞれ上位レイヤに位置する機能部から端末装置１１１への送信フレームを受信した場合に、その受信時間およびそのフレームのデータサイズを特定し、特定した情報をトラフィックパターン測定部３０５へ通知する。なお、これらの機能部は、ＵｓｅｒＰｌａｎｅにおけるプロトコルスタックに該当し、ＳＤＡＰ機能部３０１がこれらの機能部の中で最上位のレイヤに対応し、ＰＤＣＰ機能部３０２が２番目に上位のレイヤに対応し、ＲＬＣ機能部３０３が３番目に上位のレイヤに対応し、ＭＡＣ機能部３０４は、これらの機能部の中で最も下位のレイヤに対応する。トラフィックパターン測定部３０５は、受信時間から、トラフィックの周期を算出し、複数算出されるフレーム周期の統計処理を実施する。トラフィックパターン測定部３０５は、例えば、フレーム周期の平均値、最大値、最小値、最頻値、標準偏差などの統計情報を算出する。また、トラフィックパターン測定部３０５は、データサイズについても、平均値、最大値、最小値、最頻値、標準偏差などの統計情報を算出しうる。また、アプリケーションにより生成されるフレームが複数のパケットに分割されて送信されるバーストデータである場合には、トラフィックパターン測定部３０５は、ＳＤＡＰ機能部３０１、ＰＤＣＰ機能部３０２、ＲＬＣ機能部３０３、ＭＡＣ機能部３０４から先頭パケットと最後尾パケットの受信時間を取得する。これにより、トラフィックパターン測定部３０５は、各機能部におけるバーストデータの周期とバーストデータの継続時間を算出する。トラフィックパターン測定部３０５は、バーストデータの周期とバーストデータの継続時間についても、複数のデータが得られることが想定され、平均値、最大値、最小値、最頻値、標準偏差などの統計情報を算出する。また、トラフィックパターン測定部３０５は、測定対象とする特定のフレームに関する情報のみに絞って、各機能部にフレームの受信時間などの測定データの提供を要求することができる。この場合、各機能部は、必要に応じて、特定のフレームに関わるＰＤＵｓｅｓｓｉｏｎ、ＱｏＳｆｌｏｗ、ネットワークスライスに関するデータを提供する。各機能部は、測定対象とするフレームをアプリケーションサーバー１３１やコアネットワーク装置１２１などの上位レイヤが付与する識別子から判定し、フレームの受信時間を記録することも考えられる。

トラフィックパターン測定部３０５は、フレームの周期やフレームサイズ、バーストデータの周期とバーストデータの継続時間などの情報を、通信パラメータ制御部３０６へ通知する。通信パラメータ制御部３０６は、受信した情報をもとに、ＳＰＳ、ＣＧ、ＤＲＸのパラメータを決定し、そのパラメータを用いて端末装置１１１の設定を行う。通信パラメータ制御部３０６は、通信中に、トラフィックパターン測定部３０５から新たな情報が通知された場合は、その通知された情報をもとに、各パラメータの変更要否を判定する。そして、通信パラメータ制御部３０６は、変更が必要と判定した場合、端末装置１１１に対して、設定の変更を要求する。

図８は、端末装置の機能構成例を示す図である。端末装置は、その機能として、例えば、ＳＤＡＰ機能部４０１、ＰＤＣＰ機能部４０２、ＲＬＣ機能部４０３、ＭＡＣ機能部４０４、トラフィックパターン測定部４０５を有する。なお、図８では、本実施形態に特に関係する機能のみを示しており、端末装置が有しうる他の各種機能については図示を省略している。例えば、端末装置は、５Ｇやその後継規格の端末装置が一般的に有する他の機能を当然に有する。また、図８の機能ブロックは概略的に示したものであり、それぞれの機能ブロックが一体化されて実現されてもよいし、さらに細分化されてもよい。また、図８の各機能は、例えば、プロセッサ２０１がＲＯＭ２０２や記憶装置２０４に記憶されているプログラムを実行することにより実現されてもよいし、例えば通信回路２０５の内部に存在するプロセッサが所定のソフトウェアを実行することによって実現されてもよい。なお、各機能部が実行する処理の詳細について、上述の詳細についてはここでは説明せず、その大まかな機能のみを概説する。

ＳＤＡＰ機能部４０１、ＰＤＣＰ機能部４０２、ＲＬＣ機能部４０３、及びＭＡＣ機能部４０４は、基地局装置の対応する機能部と同様であり、それぞれ、ＵｓｅｒＰｌａｎｅにおけるプロトコルスタックの各レイヤに対応する。トラフィックパターン測定部４０５は、基地局装置から、トラフィックパターンの特定やフレーム周期の計測の指示を受信する。トラフィックパターン測定部４０５は、基地局装置からの指示に基づき、ＳＤＡＰ機能部４０１、ＰＤＣＰ機能部４０２、ＲＬＣ機能部４０３、及びＭＡＣ機能部４０４へ、測定に関わるデータの提供を要求する。測定に関わるデータは、一例として、各機能部が上位レイヤの機能部からのフレームを受信した時刻、フレームサイズ、各機能部が上位レイヤからフレームを受信してから下位レイヤの機能部へフレームを送出するまでの遅延時間でありうる。また、ＭＡＣ機能部４０４で計測される遅延時間には、基地局装置へ送信するフレームのためのＢＳＲの送信や、基地局装置がＢＳＲを受信して、実際に上りリンクの無線リソースの割り当てが行われるまでの時間が含まれてもよい。トラフィックパターン測定部４０５は、各機能部から取得したデータについて、必要に応じて、平均値、最大値、最小値、最頻値、標準偏差などの統計情報を算出し、取得したデータや統計情報の算出結果を基地局装置へ報告する。

トラフィックパターン測定部４０５は、フレームの周期やフレームサイズ、バーストデータの周期とバーストデータの継続時間などの情報を、ＭＡＣ機能部４０４へ通知する。ＭＡＣ機能部４０４は、トラフィックパターン測定部４０５から取得した情報に基づいて、適切なバッファ・サイズ・テーブルの設定を決定し、決定結果の一例であるバッファ・サイズ・テーブルのビット数、バッファ・サイズ・テーブルの最低値、最大値を基地局装置へ通知する。また、ＭＡＣ機能部４０４は、計測した送信までに要する遅延時間が、コアネットワーク装置や基地局装置から通知されたパケットの伝送遅延の最大値（ＰａｃｋｅｔＤｅｌａｙＢｕｄｇｅｔ）に収まるように、基地局装置１０１に対して、上りリンクのフレームの送信タイミングの補正を要求しうる。

（処理の流れ）
続いて、図９を用いて、無線通信システムにおいて実行される処理の流れの例について説明する。ここでは、図１のように、基地局装置１０１に接続された端末装置１１１が、上りリンクのフレームの送信タイミングの補正を要求する場合、つまり、パケットの伝送遅延の最大値（ＰａｃｋｅｔＤｅｌａｙＢｕｄｇｅｔ）内に、実際に測定した送信遅延時間が、収まるように、端末装置１１１から基地局装置１０１に対して、上りリンクのフレームの送信タイミングの補正を要求する場合の例について説明する。

まず、トラフィックパターンの特定が行われるべきフレーム種別に関する情報、および、フレーム特性情報を、端末装置１１１が基地局装置１０１から取得する（Ｓ９０１）。例えば、基地局装置１０１は、トラフィックパターンの特定が行われるべきフレームの送受信に用いられるＬｏｇｉｃａｌＣｈａｎｎｅｌｉｄｅｎｔｉｔｙ（ＬＣＩＤ）、ＤＲＢ－Ｉｄｅｎｔｉｔｙ、ＰＤＵ－ＳｅｓｓｉｏｎＩＤ、ＱＦＩｖａｌｕｅ（ＱｏＳｆｌｏｗ）を端末装置１１１へ通知する。このとき、（例えば映像フレームの）フレームレート（ｆｒａｍｅｓｐｅｒｓｅｃｏｎｄ、ｆｐｓ）、データレート（Ｍｂｐｓ）、サービス品質（ＱｏＳ、ＱｕａｌｉｔｙｏｆＳｅｒｖｉｃｅ）、優先度（Ｐｒｉｏｒｉｔｙ）、パケットの伝送遅延の最大値（ＰａｃｋｅｔＤｅｌａｙＢｕｄｇｅｔ）、パケットエラー率（ＰａｃｋｅｔＥｒｒｏｒＬｏｓｓＲａｔｅ）、１フレームあたりのパケット数、ＰＤＵ数などの特定を行うべき映像フレームの特性情報も、例えば、ＲＲＣＲｅｃｏｎｆｉｇｕｒａｔｉｏｎなどのレイヤ３シグナリングによって、あわせて通知されうる。トラフィックパターンの特定が行われるべきフレームが複数存在する場合には、例えば、ＬＣＩＤ＝１のＰａｃｋｅｔＤｅｌａｙＢｕｄｇｅｔ＝２ｍｓ、ＬＣＩＤ＝２のＰａｃｋｅｔＤｅｌａｙＢｕｄｇｅｔ＝５ｍｓというように、トラフィックパターンの特定が行われるべきフレームの個数だけ情報がリスト化されて通知されうる。

端末装置１１１は、送信フレームの発生を認識してから、実際にそのフレームを基地局装置１０１へ送信するまでに要する時間を計測する（Ｓ９０２）。一例として、端末装置１１１は、端末装置１１１内部のＭＡＣ機能部が、送信フレームを上位のＲＬＣ機能部から受信するタイミングから、実際にそのフレームを含むＰＵＳＣＨを送信するタイミングまでに要する時間を計測する。なお、計測時間の開始タイミングは、ＭＡＣ機能部におけるフレーム受信時点に限られず、ＲＬＣ機能部や、ＰＤＣＰ機能部、ＳＤＡＰ機能部などがそのフレームを上位レイヤに位置する機能部から受信した時点、又は、下位レイヤに位置する機能部へそのフレームを送信した時点としてもよい。また、計測時間の終了タイミングは、フレーム送信のための無線リソースの割り当てに関する情報を含むＤＣＩを端末装置１１１が受信した時点、ＰＵＳＣＨでのフレーム送信を開始した時点、又は、ＰＵＳＣＨでのフレーム送信を終了した時点のいずれかであってもよい。

端末装置１１１は、前述の計測値と、パケットの伝送遅延の最大値（ＰａｃｋｅｔＤｅｌａｙＢｕｄｇｅｔ）を用いて、上りリンクのフレームの送信タイミングの補正値を決定する（Ｓ９０３）。ここで、複数の計測値が存在する場合は、端末装置１１１は、平均値、最頻値を用いて、補正値を決定してもよいし、ＰａｃｋｅｔＤｅｌａｙＢｕｄｇｅｔを用いずに補正値を決定してもよい。補正値は、現在の送信タイミングからの、フレーム数やシンボル数で表現される正／負のオフセットや、ＳＦＮ（ｓｙｓｔｅｍｆｒａｍｅｎｕｍｂｅｒ）を用いて表現されうる。

端末装置１１１は、送信タイミングの変更を、基地局装置１０１へ要求する（Ｓ９０４）。例えば、端末装置１１１は、レイヤ１又はレイヤ２のシグナリングを用いて、送信タイミングの変更要求を基地局装置１０１へ通知しうる。このときに、端末装置１１１は、さらに、決定した補正値を、基地局装置１０１へ通知してもよい。また、送信タイミングの変更要求や、補正値の通知は、ＢＳＲで実施されてもよい。

基地局装置１０１は、端末装置１１１からの送信タイミングの変更要求に従うか否かを判定し、その結果を端末装置１１１へ応答する（Ｓ９０５）。例えば、基地局装置１０１は、端末装置１１１からの補正値に従うか否かの情報を端末装置へ返信する。また、基地局装置１０１は、端末装置１１１によって通知された補正値と異なる値での補正を行う場合は、その異なる補正値の値を端末装置１１１へ通知してもよい。また、基地局装置１０１は、端末装置１１１へ割り当てるＰＵＳＣＨの無線リソースの割り当てタイミングをＰＤＣＣＨで通知することを持って、応答の代わりとすることも考えられる。

以上のように、本実施形態によれば、実際のアプリケーショントラフィックにおいて、様々なトラフィックパターンでの通信が同時に実行されることが想定される状況において、それらのトラフィックパターンに応じた、適切な通信制御を提供することが可能となる。よって、国連が主導する持続可能な開発目標（ＳＤＧｓ）の目標９「レジリエントなインフラを整備し、持続可能な産業化を推進するとともに、イノベーションの拡大を図る」に貢献することが可能となる。

発明は上記の実施形態に制限されるものではなく、発明の要旨の範囲内で、種々の変形・変更が可能である。

本発明の一態様による端末装置は、前記端末装置によって実行されるアプリケーションが生成するフレームが複数のパケットに分割されたバーストデータとして送信される場合の、前記バーストデータの先頭のパケットを認識する認識手段と、前記認識の結果に基づいて、前記バーストデータの周期と当該バーストデータのジッタを特定する特定手段と、前記特定の結果を基地局装置へ報告する報告手段と、前記基地局装置から、前記報告手段による報告対象とすべきフレームに関する情報を取得する取得手段と、を有する。

Claims

端末装置であって、
前記端末装置によって実行されるアプリケーションが生成するフレームが複数のパケットに分割されて送信される場合の、先頭のパケットと最後尾のパケットとを認識する認識手段と、
前記認識手段で認識した前記先頭のパケットの受信時間を測定する測定手段と、
前記測定手段による測定結果から、フレーム周期と当該フレーム周期の揺らぎを算出する算出手段と、
前記算出の結果を基地局装置へ報告する報告手段と、
前記基地局装置から、前記報告手段による報告対象とすべきフレームに関する情報を取得する取得手段と、
を有することを特徴とする端末装置。
端末装置であって、
ＣｏｎｆｉｇｕｒｅｄＧｒａｎｔによって上りリンクのデータを送信する送信手段と、
基地局装置から、ＣｏｎｆｉｇｕｒｅｄＧｒａｎｔの周期と無線リソースブロックの割り当て情報を、レイヤ３のシグナリングによって取得する取得手段と、
前記基地局装置から前記ＣｏｎｆｉｇｕｒｅｄＧｒａｎｔの周期とリソースブロックの割り当て情報の変更指示を、レイヤ１又はレイヤ２のシグナリングによって受信する受信手段と、
前記基地局装置に対して無線リソースブロックの割り当てタイミングの変更を要求する要求手段と、
を有することを特徴とする端末装置。
バッファ・ステータス・レポート（ＢＳＲ）によって送信バッファサイズを基地局装置へ通知する通知手段と、
前記ＢＳＲの通知に用いられるバッファ・サイズ・テーブルの最低値と、ビット数と、１ビットのステップの大きさを取得する取得手段と、
を有することを特徴とする端末装置。
前記端末装置に含まれる媒体アクセス制御（ＭＡＣ）の機能において送信データを認識してから、前記送信データが物理上りリンク共有チャネル（ＰＵＳＣＨ）において送信されるまでの送信待ち時間を、前記ＢＳＲにおいて前記基地局装置へ報告する報告手段をさらに有する、ことを特徴とする請求項３に記載の端末装置。