(57)【要約】  送信装置は、送信データを保持するバッファを有し、送信データに対して第１レイヤの処理を実行する第１レイヤ処理部（１１２）と、送信データに対して前記第１レイヤとは異なる第２レイヤの処理を実行する第２レイヤ処理部（１１３）と、前記第１レイヤ処理部及び前記第２レイヤ処理部によって処理された送信データを送信可能な送信部（１３０）とを有し、前記第１レイヤ処理部（１１２）は、前記第２レイヤの処理において送信制御に用いられるパラメータに応じて、前記バッファに保持された送信データを廃棄する。
2019244284.tif 000002
【特許請求の範囲】
【請求項１】
送信データを保持するバッファを有し、送信データに対して第１レイヤの処理を実行する第１レイヤ処理部と、
送信データに対して前記第１レイヤとは異なる第２レイヤの処理を実行する第２レイヤ処理部と、
前記第１レイヤ処理部及び前記第２レイヤ処理部によって処理された送信データを送信可能な送信部とを有し、
前記第１レイヤ処理部は、
前記第２レイヤの処理において送信制御に用いられるパラメータに応じて、前記バッファに保持された送信データを廃棄する
ことを特徴とする送信装置。
【請求項２】
前記第２レイヤ処理部は、
送信データに対してＭＡＣ（Medium  Access  Control）レイヤの処理を実行し、
前記第１レイヤ処理部は、
送信データが前記バッファに保持されてから、ＭＡＣレイヤの優先制御に用いられるＰＵＳＣＨ（Physical  Uplink  Shared  CHannel）の最大送信時間に応じた時間が経過した場合に、前記バッファに保持された送信データを廃棄する
ことを特徴とする請求項１記載の送信装置。
【請求項３】
前記第１レイヤ処理部は、
送信データに対してＰＤＣＰ（Packet  Data    Convergence  Protocol）レイヤの処理を実行し、
前記最大送信時間は、
ＰＤＣＰレイヤにおいてあらかじめ定められた廃棄までの時間を示す廃棄タイマよりも短い時間である
ことを特徴とする請求項２記載の送信装置。
【請求項４】
前記第１レイヤ処理部は、
送信データに対してＲＬＣ（Radio  Link  Control）レイヤの処理を実行し、
前記最大送信時間は、
ＲＬＣレイヤにおいてあらかじめ定められた廃棄までの時間を示す廃棄タイマよりも短い時間である
ことを特徴とする請求項２記載の送信装置。
【請求項５】
前記第２レイヤ処理部は、
送信データに対してＲＬＣレイヤの処理を実行し、
前記第１レイヤ処理部は、
前記バッファに保持された送信データの再送回数が、ＲＬＣレイヤの再送制御に用いられる最大再送回数に到達した場合に、前記バッファに保持された送信データを廃棄する
ことを特徴とする請求項１記載の送信装置。
【請求項６】
バッファに保持された送信データに対して第１レイヤの処理を実行し、
送信データに対して前記第１レイヤとは異なる第２レイヤの処理を実行し、
前記第２レイヤの処理において送信制御に用いられるパラメータに応じて、前記バッファに保持された送信データを廃棄する
処理を有することを特徴とするバッファ制御方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、送信装置及びバッファ制御方法に関する。
【背景技術】
【０００２】
現在のネットワークは、モバイル端末（スマートフォンやフィーチャーホン）のトラフィックがネットワークのリソースの大半を占めている。また、モバイル端末が使うトラフィックは、今後も拡大していく傾向にある。【０００３】
一方で、ＩｏＴ（Internet  of  a  things）サービス（例えば、交通システム、スマートメータ、装置等の監視システム）の展開に合わせて、多様な要求条件を持つサービスに対応することが求められている。そのため、第５世代移動体通信（５Ｇ又はＮＲ（Ｎｅｗ  Ｒａｄｉｏ））の通信規格では、４Ｇ（第４世代移動体通信）の標準技術（例えば、非特許文献１〜１１）に加えて、さらなる高データレート化、大容量化、低遅延化を実現する技術が求められている。なお、第５世代通信規格については、３ＧＰＰの作業部会（例えば、ＴＳＧ−ＲＡＮ  ＷＧ１、ＴＳＧ−ＲＡＮ  ＷＧ２等）で技術検討が進められている。（非特許文献１２〜３９）。現在、３ＧＰＰが規定する５Ｇの標準仕様の初版がリリースされている。【０００４】
上述したように、多種多様なサービスに対応するために、５Ｇでは、ｅＭＢＢ（Enhanced  Mobile  BroadBand）、Ｍａｓｓｉｖｅ  ＭＴＣ（Machine  Type  Communications）及びＵＲＬＬＣ（Ultra−Reliable  and  Low  Latency  Communication）に分類される多くのユースケースのサポートが想定されている。【０００５】
また、無線通信システムの通信規格では、一般に、無線通信の機能を一連の層（レイヤ）に分割したプロトコルスタック（階層型プロトコルとも称される）として、仕様が規定される。例えば、第一層として物理層が規定され、第二層としてデータリンク層が規定され、第三層としてネットワーク層が規定される。ＬＴＥ（Long  Term  Evolution）などの第４世代移動体通信システムでは、第二層は複数の副層に分割されており、ＭＡＣ（Medium  Access  Control）レイヤ、ＲＬＣ（Radio  Link  Control）レイヤ、ＰＤＣＰ（Packet  Data  Convergence  Protocol）レイヤから構成される。また、第４世代移動体通信システムにおいて、第一層はＰＨＹ（Physical）レイヤから構成されており、第三層はＲＲＣ（Radio  Resource  Control）レイヤから構成される（ＲＲＣレイヤは制御プレーンのみ）。なお、ＭＡＣレイヤ、ＲＬＣレイヤ、ＰＤＣＰレイヤについては、上述したように第二層の副層であることから、これらをＭＡＣサブレイヤ、ＲＬＣサブレイヤ、ＰＤＣＰサブレイヤと称しても良い。【０００６】
無線通信システムの送信装置における各レイヤは、上位レイヤからのデータブロック（サービスデータユニット（ＳＤＵ：Service  Data  Unit）とも称される）に対して、ヘッダを付すなどの所定のプロトコルに準拠した処理を行うことで、プロトコルデータユニット（ＰＤＵ：Protocol  Data  Unit）を生成し、下位レイヤに転送する。例えば、ＬＴＥのＲＬＣレイヤでは、上位レイヤであるＰＤＣＰレイヤからのデータブロックであるＰＤＣＰ−ＰＤＵをＲＬＣ−ＳＤＵとし、下位レイヤから通知されるＴＢ（Transport  Block）長に収まる範囲で複数のＲＬＣ−ＳＤＵを連結するなどして、ＲＬＣ−ＰＤＵを生成する。このようなＲＬＣ−ＰＤＵは、ＲＬＣレイヤにおけるシーケンス番号（ＳＮ：Sequence  Number）を有するＲＬＣヘッダが付された上で、下位レイヤであるＭＡＣレイヤに転送される。【０００７】
無線通信システムの受信装置における各レイヤは、下位レイヤからのデータブロック（すなわちＰＤＵ）を受けて、ヘッダを除去するなどして取り出したデータブロック（すなわちＳＤＵ）を上位レイヤへ転送する。例えば、ＬＴＥのＲＬＣレイヤでは、下位レイヤであるＭＡＣレイヤからのデータブロック（ＭＡＣ−ＳＤＵ又はＲＬＣ−ＰＤＵとも称される）に付されたＲＬＣヘッダを参照して、１個のＲＬＣ−ＰＤＵに格納された複数のＲＬＣ−ＳＤＵを再構成するなどの処理が行われ、上位レイヤであるＰＤＣＰレイヤにＲＬＣ−ＳＤＵを転送する。その際、上位レイヤに対してＲＬＣ−ＳＤＵの順序を補償するために、ＲＬＣ−ＳＤＵの再構成において、ＲＬＣヘッダが有するＲＬＣシーケンス番号に基づく整序処理が行われる。そして、ＲＬＣシーケンス番号に抜けが生じたことを検知した場合、送信装置に対してＲＬＣ−ＰＤＵの再送を要求するＲＬＣ再送制御が実行される。【０００８】
５Ｇの仕様では、ＭＡＣレイヤにおいて、ＬＣＰ（Logical  Channel  Prioritization）と呼ばれる上りデータの優先制御が実施される（非特許文献２２）。ＬＣＰでは、例えば、要求遅延に応じた優先的な無線リソース割り当てに伴う特性劣化（スターベーション）の発生を抑制するために、各データに対する優先制御が実施される。具体的には、各データが伝送される論理チャネル（LCH：Logical  CHannel）に対し、ビットレート等のパラメータが設定され、これらのパラメータ（要求条件でもある）を満足するように優先制御が実施される。ただし、個々のチャネルについて優先制御を実施すると、粒度が過剰に細かくなって端末装置のデータ処理量が多くなる。そこで、要求条件が同じ論理チャネルを集約してＬＣＧ（Logical  Channel  Group）を生成し、ＬＣＧごとに優先制御が実施されることがある。【０００９】
また、無線通信システムでは送信装置がデータを送信するまでに、例えばＲＬＣレイヤ又はＰＤＣＰレイヤにおいて、データが一時的にバッファに保持されることがある。バッファに保持されたデータは、例えばあらかじめ設定された廃棄タイマが満了すると廃棄される。
【先行技術文献】
【非特許文献】
【００１０】
【非特許文献１】3GPP  TS  36.133  V15.2.0（2018-03）
【非特許文献２】3GPP  TS  36.211  V15.1.0（2018-03）
【非特許文献３】3GPP  TS  36.212  V15.1.0（2018-03）
【非特許文献４】3GPP  TS  36.213  V15.1.0（2018-03）
【非特許文献５】3GPP  TS  36.300  V15.1.0（2018-03）
【非特許文献６】3GPP  TS  36.321  V15.1.0（2018-03）
【非特許文献７】3GPP  TS  36.322  V15.0.1（2018-04）
【非特許文献８】3GPP  TS  36.323  V14.5.0（2017-12）
【非特許文献９】3GPP  TS  36.331  V15.1.0（2018-03）
【非特許文献１０】3GPP  TS  36.413  V15.1.0（2018-03）
【非特許文献１１】3GPP  TS  36.423  V15.1.0（2018-03）
【非特許文献１２】3GPP  TS  36.425  V14.1.0（2018-03）
【非特許文献１３】3GPP  TS  37.340  V15.1.0（2018-03）
【非特許文献１４】3GPP  TS  38.201  V15.0.0（2017-12）
【非特許文献１５】3GPP  TS  38.202  V15.1.0（2018-03）
【非特許文献１６】3GPP  TS  38.211  V15.1.0（2018-03）
【非特許文献１７】3GPP  TS  38.212  V15.1.1（2018-04）
【非特許文献１８】3GPP  TS  38.213  V15.1.0（2018-03）
【非特許文献１９】3GPP  TS  38.214  V15.1.0（2018-03）
【非特許文献２０】3GPP  TS  38.215  V15.1.0（2018-03）
【非特許文献２１】3GPP  TS  38.300  V15.1.0（2018-03）
【非特許文献２２】3GPP  TS  38.321  V15.1.0（2018-03）
【非特許文献２３】3GPP  TS  38.322  V15.1.0（2018-03）
【非特許文献２４】3GPP  TS  38.323  V15.1.0（2018-03）
【非特許文献２５】3GPP  TS  38.331  V15.1.0（2018-03）
【非特許文献２６】3GPP  TS  38.401  V15.1.0（2018-03）
【非特許文献２７】3GPP  TS  38.410  V0.9.0（2018-04）
【非特許文献２８】3GPP  TS  38.413  V0.8.0（2018-04）
【非特許文献２９】3GPP  TS  38.420  V0.8.0（2018-04）
【非特許文献３０】3GPP  TS  38.423  V0.8.0（2018-04）
【非特許文献３１】3GPP  TS  38.470  V15.1.0（2018-03）
【非特許文献３２】3GPP  TS  38.473  V15.1.1（2018-04）
【非特許文献３３】3GPP  TR  38.801  V14.0.0（2017-04）
【非特許文献３４】3GPP  TR  38.802  V14.2.0（2017-09）
【非特許文献３５】3GPP  TR  38.803  V14.2.0（2017-09）
【非特許文献３６】3GPP  TR  38.804  V14.0.0（2017-03）
【非特許文献３７】3GPP  TR  38.900  V14.3.1（2017-07）
【非特許文献３８】3GPP  TR  38.912  V14.1.0（2017-06）
【非特許文献３９】3GPP  TR  38.913  V14.3.0（2017-06）
【発明の概要】
【発明が解決しようとする課題】
【００１１】
しかしながら、ＲＬＣレイヤ又はＰＤＣＰレイヤにおいてデータがバッファに保持される場合、バッファに滞留するデータによって、データに要求される遅延条件が満たされないことがあるという問題がある。例えば、廃棄タイマが例えば１０ｍｓなどの比較的長い時間に設定されている場合、バッファに滞留するデータが廃棄されるまでの時間が増大しＨＯＬ（Head  of  Line  blocking）が生じる。この結果、例えば要求される遅延量が１ｍｓ未満のデータ（低遅延データ）が新規に発生すると、低遅延データが送信されるまでに時間がかかり、遅延要求が満たされないことがある。【００１２】
開示の技術は、かかる点に鑑みてなされたものであって、低遅延データの遅延要求を満たすことができる送信装置及びバッファ制御方法を提供することを目的とする。
【課題を解決するための手段】
【００１３】
本願が開示する送信装置は、１つの態様において、送信データを保持するバッファを有し、送信データに対して第１レイヤの処理を実行する第１レイヤ処理部と、送信データに対して前記第１レイヤとは異なる第２レイヤの処理を実行する第２レイヤ処理部と、前記第１レイヤ処理部及び前記第２レイヤ処理部によって処理された送信データを送信可能な送信部とを有し、前記第１レイヤ処理部は、前記第２レイヤの処理において送信制御に用いられるパラメータに応じて、前記バッファに保持された送信データを廃棄する。
【発明の効果】
【００１４】
本願が開示する送信装置及びバッファ制御方法の１つの態様によれば、低遅延データの遅延要求を満たすことができるという効果を奏する。
【図面の簡単な説明】
【００１５】
【図１】図１は、実施の形態１に係る端末装置の構成を示すブロック図である。
【図２】図２は、実施の形態１に係るバッファ制御方法を示すフロー図である。
【図３】図３は、実施の形態２に係る端末装置の構成を示すブロック図である。
【図４】図４は、最大送信時間の具体例を示す図である。
【図５】図５は、実施の形態２に係るバッファ制御方法を示すフロー図である。
【図６】図６は、実施の形態２に係る内容の標準仕様書への記載例を示す図である。
【図７】図７は、実施の形態３に係るバッファ制御方法を示すフロー図である。
【図８】図８は、実施の形態３に係る内容の標準仕様書への記載例を示す図である。
【発明を実施するための形態】
【００１６】
以下、本願が開示する送信装置及びバッファ制御方法の実施の形態について、図面を参照して詳細に説明する。なお、この実施の形態により本発明が限定されるものではない。以下においては、送信装置の一例として端末装置を挙げて説明するが、送信装置は必ずしも端末装置に限定されず、例えば基地局装置も送信装置に含まれる。また、特に区別する場合を除いて、各レイヤのＳＤＵ（Service  Data  Unit）及びＰＤＵ（Protocol  Data  Unit）を単に「パケット」という。
【００１７】
（実施の形態１）
図１は、実施の形態１に係る端末装置１００の構成を示すブロック図である。図１に示す端末装置１００は、プロセッサ１１０、メモリ１２０及び無線通信部１３０を有する。
【００１８】
プロセッサ１１０は、例えばＣＰＵ（Central  Processing  Unit）、ＦＰＧＡ（Field  Programmable  Gate  Array）又はＤＳＰ（Digital  Signal  Processor）などを備え、端末装置１００の全体を統括制御する。具体的には、プロセッサ１１０は、アプリケーション処理部１１１、第１レイヤ処理部１１２及び第２レイヤ処理部１１３を有する。
【００１９】
アプリケーション処理部１１１は、種々のアプリケーションの処理を実行する。例えば、アプリケーション処理部１１１は、端末装置１００から図示しない基地局装置へ向かう上り回線によって伝送される送信データを生成する。送信データには、例えば要求される遅延量が１ｍｓ未満の低遅延データも含まれる。
【００２０】
第１レイヤ処理部１１２は、第１レイヤの処理を実行する。例えば、第１レイヤ処理部１１２は、アプリケーション処理部１１１によって生成された送信データのパケット（ＳＤＵ）に第１レイヤのヘッダを付加し、第１レイヤのＰＤＵを生成する。ここで、第１レイヤ処理部１１２は、バッファを有しており、処理対象のパケットをバッファに一時的に保持する。そして、第１レイヤ処理部１１２は、バッファに保持されたパケットの廃棄を制御する。
【００２１】
具体的には、第１レイヤ処理部１１２は、パケットがバッファに格納されると、このパケットを廃棄する条件を規定する第１の情報を設定する。このとき、第１レイヤ処理部１１２は、第２レイヤ処理部１１３において送信制御に用いられる第２の情報を取得し、第２の情報に応じて第１の情報を設定する。すなわち、第１レイヤ処理部１１２は、異なるレイヤ（例えば下位レイヤ）である第２レイヤのパラメータを用いて、パケットの廃棄条件を設定する。
【００２２】
パケットの廃棄条件を設定した後、第１レイヤ処理部１１２は、廃棄条件が満たされるか否かを監視し、廃棄条件が満たされる場合には、該当するパケットをバッファから廃棄する。
【００２３】
第２レイヤ処理部１１３は、第１レイヤよりも下位の第２レイヤの処理を実行する。例えば、第２レイヤ処理部１１３は、第１レイヤ処理部１１２によって生成された第１レイヤのＰＤＵをＳＤＵとして、このＳＤＵに第２レイヤのヘッダを付加し、第２レイヤのＰＤＵを生成する。第２レイヤ処理部１１３は、第２の情報を用いてパケットの送信制御を行う。すなわち、第２レイヤ処理部１１３は、例えば第２の情報に従ってパケットの送信の優先制御をしたり、再送制御をしたりする。上述したように、第２の情報は、第１レイヤ処理部１１２のパケットの廃棄条件の設定に用いられる。
【００２４】
メモリ１２０は、例えばＲＡＭ（Random  Access  Memory）又はＲＯＭ（Read  Only  Memory）などを備え、プロセッサ１１０が処理を実行するために使用する情報を記憶する。
【００２５】
無線通信部１３０は、プロセッサ１１０によって生成される送信データに対して、例えばＤ／Ａ（Digital/Analog）変換及びアップコンバートなどの無線送信処理を施し、アンテナを介して無線送信する。また、無線通信部１３０は、アンテナを介して無線受信した受信データに対して、例えばダウンコンバート及びＡ／Ｄ（Analog/Digital）変換などの無線受信処理を施し、プロセッサ１１０へ出力する。
【００２６】
次いで、上記のように構成された端末装置１００におけるバッファ制御方法について、図２に示すフロー図を参照しながら説明する。以下のバッファ制御方法は、第１レイヤ処理部１１２が有するバッファの制御方法である。
【００２７】
アプリケーション処理部１１１によって生成される送信データは、第１レイヤ処理部１１２へ出力され、所定長のパケットに分割された上で、第１レイヤ処理部１１２が有するバッファに格納される（ステップＳ１０１）。パケットがバッファに格納される際には、それぞれのパケットについて、廃棄条件を規定する第１の情報が設定される（ステップＳ１０２）。すなわち、第１レイヤ処理部１１２によって、第２レイヤ処理部１１３による送信制御に用いられる第２の情報が取得され、第２の情報に応じて第１の情報が設定される。
【００２８】
パケットの廃棄条件が設定されると、第１レイヤ処理部１１２は、パケットに対して第１レイヤの処理を実行しつつ、バッファに格納された各パケットについて、廃棄条件が満たされるか否かを監視する（ステップＳ１０３）。すなわち、第１の情報によって示される廃棄条件が満たされるか否かが監視され、パケットが廃棄条件を満たす場合には（ステップＳ１０３Ｙｅｓ）、このパケットが第１レイヤ処理部１１２によって廃棄される（ステップＳ１０４）。これにより、第１レイヤのパケットが下位の第２レイヤの送信制御に用いられるパラメータに応じた廃棄条件で廃棄され、第１レイヤのバッファにおけるパケットの滞留時間が短縮される。結果として、新たな送信データとして低遅延データが発生した場合でも、低遅延データのパケットに対する第１レイヤの処理が迅速に実行され、少ない遅延で低遅延データを送信することが可能となる。また、バッファにおけるパケットの滞留時間が短縮される結果、バッファサイズを小さくすることができる。
【００２９】
以上のように、本実施の形態によれば、第１レイヤのパケットの廃棄条件を規定する第１の情報を、第２レイヤの送信制御に関する第２の情報に応じて設定し、廃棄条件を満たすパケットを第１レイヤのバッファから廃棄する。このため、バッファにおけるパケットの滞留時間を短縮することができ、新規の送信データとして低遅延データが発生した場合でも、低遅延データが送信されるまでの遅延を削減することができる。結果として、低遅延データの遅延要求を満たすことができる。
【００３０】
なお、上記実施の形態１においては、主に第１レイヤのバッファに関するバッファ制御方法について説明したが、第１レイヤ及び第２レイヤとは異なる他のレイヤ処理部（例えば、第３レイヤ処理部）がバッファを有していても良い。そして、第３レイヤのバッファにパケットが格納される場合には、第３レイヤのバッファに対して上記実施の形態１で説明したバッファ制御方法が適用されても良い。この場合、既に無線伝送中の初送のパケット及び再送パケットには、このバッファ制御方法が適用されなくても良い。
【００３１】
（実施の形態２）
図３は、実施の形態２に係る端末装置１００の構成を示すブロック図である。図３において、図１と同じ部分には同じ符号を付し、その説明を省略する。図３に示す端末装置１００においては、プロセッサ１１０の内部構成が図１に示す端末装置１００と異なる。すなわち、図３に示すプロセッサ１１０は、アプリケーション処理部１１１に加えて、ＰＤＣＰ処理部２０１、ＲＬＣ処理部２０２及びＭＡＣ処理部２０３を有する。
【００３２】
ＰＤＣＰ処理部２０１は、ＰＤＣＰレイヤの処理を実行する。例えば、ＰＤＣＰ処理部２０１は、アプリケーション処理部１１１によって生成された送信データのパケット（ＰＤＣＰ−ＳＤＵ）にＰＤＣＰレイヤのヘッダを付加し、ＰＤＣＰ−ＰＤＵを生成する。ＰＤＣＰ処理部２０１は、バッファを有しており、処理対象のパケットをバッファに一時的に保持する。そして、ＰＤＣＰ処理部２０１は、バッファに保持されたパケットの廃棄を制御する。
【００３３】
具体的には、ＰＤＣＰ処理部２０１は、パケットがバッファに格納されると、このパケットを廃棄するまでの時間を規定する廃棄タイマを設定する。また、ＰＤＣＰ処理部２０１は、ＭＡＣ処理部２０３において送信制御に用いられる最大送信時間を取得し、最大送信時間に応じて、上記の廃棄タイマとは別にパケットの廃棄までの時間を設定する。すなわち、ＰＤＣＰ処理部２０１は、ＰＤＣＰレイヤよりも下位レイヤであるＭＡＣレイヤのパラメータを用いて、パケットの廃棄条件を設定する。
【００３４】
パケットの廃棄条件を設定した後、ＰＤＣＰ処理部２０１は、廃棄条件が満たされるか否かを監視し、廃棄条件が満たされる場合には、該当するパケットをバッファから廃棄する。
【００３５】
ＲＬＣ処理部２０２は、ＰＤＣＰレイヤよりも下位のＲＬＣレイヤの処理を実行する。例えば、ＲＬＣ処理部２０２は、ＰＤＣＰ処理部２０１によって生成されたＰＤＣＰ−ＰＤＵをＲＬＣ−ＳＤＵとして、このＲＬＣ−ＳＤＵにＲＬＣレイヤのヘッダを付加し、ＲＬＣ−ＰＤＵを生成する。ＲＬＣ処理部２０２が実行するＲＬＣレイヤの処理には、例えばパケットの再送制御などが含まれる。
【００３６】
ＲＬＣ処理部２０２は、バッファを有しており、例えばプリプロセッシングが行われる際、アプリケーション処理部１１１によって生成された送信データのパケットをＰＤＣＰ処理部２０１の代わりにバッファに一時的に保持する。このため、ＲＬＣ処理部２０２は、ＰＤＣＰ処理部２０１と同様に、バッファに保持されたパケットの廃棄を制御しても良い。
【００３７】
ＭＡＣ処理部２０３は、ＰＤＣＰレイヤ及びＲＬＣレイヤよりも下位のＭＡＣレイヤの処理を実行する。例えば、ＭＡＣ処理部２０３は、ＲＬＣ処理部２０２によって生成されたＲＬＣ−ＰＤＵをＭＡＣ−ＳＤＵとして、このＭＡＣ−ＳＤＵにＭＡＣレイヤのヘッダを付加し、ＭＡＣ−ＰＤＵを生成する。ＭＡＣ処理部２０３が実行するＭＡＣレイヤの処理には、例えばパケットのスケジューリングや優先制御などが含まれる。ＭＡＣ処理部２０３が実行する優先制御では、例えば論理チャネルの優先度を制御するＬＣＰ（Logical  Channel  Prioritization）が実行される。具体的には、要求されるＱｏＳ（Quality  of  Service）が同一の論理チャネルが集約されてＬＣＧ（Logical  Channel  Group）が生成され、ＬＣＧごとに優先制御が実施される。
【００３８】
ＭＡＣレイヤのＬＣＰでは、例えば以下の（１）〜（３）の３つのパラメータによって優先制御が実施される。
【００３９】
（１）allowedSCS-List：低遅延データを送信するＬＣＧのサブキャリアスペースを指定するパラメータである。
【００４０】
（２）maxPUSCH-Duration：ＬＣＧによる無線伝送において使用されるＰＵＳＣＨ（Physical  Uplink  Shared  CHannel）の最大送信時間を示すパラメータである。より具体的には、ＰＵＳＣＨを用いた送信が許可されるタイミングから実際にＰＵＳＣＨによって送信が実行されるタイミングまでの時間がこのパラメータによって規定される。設定されるmaxPUSCH-Durationが小さいほど、低遅延が要求されるＬＣＧであるといえる。maxPUSCH-Durationとしては、複数の候補から選択された値が設定される。すなわち、例えば図４に示すように、maxPUSCH-Durationの候補としては、０．０２ｍｓ、０．０４ｍｓ、０．０６２５ｍｓ、０．１２５ｍｓ、０．２５ｍｓ及び０．５ｍｓがあり、この中からＬＣＧの優先度に応じた値が設定される。
【００４１】
（３）configuredGrantType1Allowed：ＬＣＧによる無線伝送において使用される無線リソースが、例えば周期的な無線リソースのようにあらかじめ決定された無線リソースであるか、例えばＵＬグラント（UL  grant）によって動的に決定される無線リソースであるかを示すパラメータである。
【００４２】
上述したように、maxPUSCH-Durationによって示される最大送信時間は、ＰＤＣＰ処理部２０１のパケット廃棄までの時間として、廃棄タイマとは別に設定される。
【００４３】
次いで、上記のように構成された端末装置１００におけるバッファ制御方法について、図５に示すフロー図を参照しながら説明する。以下のバッファ制御方法は、ＰＤＣＰ処理部２０１が有するバッファの制御方法である。図５において、図２と同じ部分には同じ符号を付す。
【００４４】
アプリケーション処理部１１１によって生成される送信データは、ＰＤＣＰ処理部２０１へ出力され、所定長のパケットに分割された上で、ＰＤＣＰ処理部２０１が有するバッファに格納される（ステップＳ１０１）。パケットがバッファに格納される際には、それぞれのパケットについて、廃棄までの時間を規定する廃棄タイマが設定される（ステップＳ２０１）。廃棄タイマは、アプリケーションにとってのデータの期限に対応しており、例えば１０ｍｓ程度の時間が設定されても良い。
【００４５】
また、ＰＤＣＰ処理部２０１によって、ＭＡＣ処理部２０３における優先制御のパラメータの１つである最大送信時間が取得される（ステップＳ２０２）。この最大送信時間は、上記の廃棄タイマとは別に、パケットが廃棄されるまでの時間として用いられる。すなわち、ＰＤＣＰ処理部２０１によって、下位のＭＡＣレイヤの制御に用いられるパラメータが取得され、取得されたパラメータに応じてパケットの廃棄までの時間が設定される。図４に示したように、最大送信時間は、１ｍｓ未満の比較的短い時間である。
【００４６】
パケットの廃棄までの時間が設定されると、ＰＤＣＰ処理部２０１は、パケットに対してＰＤＣＰレイヤの処理を実行しつつ、バッファに格納された各パケットについて、廃棄条件が満たされるか否かを監視する。
【００４７】
具体的には、パケットごとに設定された廃棄タイマが満了したか否かが判定される（ステップＳ２０３）。この判定の結果、廃棄タイマが満了した場合には（ステップＳ２０３Ｙｅｓ）、このパケットがＰＤＣＰ処理部２０１によって廃棄される（ステップＳ１０４）。一方、廃棄タイマが満了していない場合には（ステップＳ２０３Ｎｏ）、パケットの受信が成功したことが通知されたか否かが判定される（ステップＳ２０４）。すなわち、ＰＤＣＰレイヤでは、定期的に状態報告（ＳＲ：Status  Report）が受信側の装置から送信されるため、この状態報告によってパケットの受信が成功したか否かが判別可能である。そこで、ＰＤＣＰ処理部２０１によって、パケットの受信が成功したことが通知されている場合には（ステップＳ２０４Ｙｅｓ）、このパケットがＰＤＣＰ処理部２０１によって廃棄される（ステップＳ１０４）。一方、受信成功の通知がない場合には（ステップＳ２０４Ｎｏ）、バッファにパケットが格納されてから最大送信時間が経過したか否かが判定される（ステップＳ２０５）。すなわち、ＭＡＣレイヤにおける優先制御のための最大送信時間が経過したか否かが判定される。そして、パケットが格納されてから最大送信時間が経過している場合には（ステップＳ２０５Ｙｅｓ）、このパケットがＰＤＣＰ処理部２０１によって廃棄される（ステップＳ１０４）。
【００４８】
このように、廃棄条件が満たされるか否かが監視され、廃棄条件を満たすパケットがバッファから廃棄されることにより、ＰＤＣＰレイヤのバッファにおけるパケットの滞留時間が短縮される。特に、ＰＤＣＰレイヤよりも下位のＭＡＣレイヤの優先制御において用いられる最大送信時間が廃棄条件として利用されることにより、アプリケーションに対応する廃棄タイマよりも短い時間でパケットが廃棄され、無線伝送の遅延を低減することができる。換言すれば、新たな送信データとして低遅延データが発生した場合でも、低遅延データのパケットに対するＰＤＣＰレイヤの処理が迅速に実行され、少ない遅延で低遅延データを送信することが可能となる。
【００４９】
以上のように、本実施の形態によれば、ＰＤＣＰレイヤのパケットの廃棄条件を規定する時間を、ＭＡＣレイヤの優先制御のための最大送信時間に応じて設定し、格納されてから最大送信時間が経過したパケットをＰＤＣＰレイヤのバッファから廃棄する。このため、バッファにおけるパケットの滞留時間を短縮することができ、新規の送信データとして低遅延データが発生した場合でも、低遅延データが送信されるまでの遅延を削減することができる。結果として、低遅延データの遅延要求を満たすことができる。
【００５０】
なお、上記実施の形態２に係るバッファ制御方法によれば、例えば、非特許文献２４（ＴＳ３８．３２３）に記載のＳＤＵ廃棄に関する項目を例えば図６のように改めることができる。つまり、ＰＤＣＰ−ＳＤＵのための廃棄タイマが満了した場合、状態報告によってＰＤＣＰ−ＳＤＵの受信が成功したことが確認された場合、又はmaxPUSCH-Durationが経過した場合にＰＤＣＰ−ＳＤＵが廃棄されるように規定しても良い。
【００５１】
また、上記実施の形態２においては、主にＰＤＣＰレイヤのバッファに関するバッファ制御方法について説明したが、上述したように、ＲＬＣ処理部２０２もバッファを有する。そして、例えばプリプロセッシングが行われる場合には、ＲＬＣレイヤのバッファにパケットが格納されるため、ＲＬＣレイヤのバッファに対して上記実施の形態２で説明したバッファ制御方法が適用されても良い。この場合、既に無線伝送中の初送のパケット及び再送パケットには、このバッファ制御方法が適用されなくても良い。
【００５２】
また、上記実施の形態２においては、性質が似ているレイヤ間（例えば、レイヤ２のうちのＰＤＣＰレイヤとＭＡＣレイヤ間）のクロスレイヤに収まる処理が実行されるので、性質が異なるレイヤ間（例えば、アプリケーションレイヤとレイヤ２間）の処理が実行されるよりもプロトコル（例えば、端末プロトコル）を簡素にすることができる。
【００５３】
（実施の形態３）
実施の形態３に係る端末装置の構成は、実施の形態２に係る端末装置１００（図３）と同様であるため、その説明を省略する。実施の形態３においては、ＰＤＣＰ処理部２０１におけるバッファ制御方法が実施の形態２とは異なる。
【００５４】
図７は、実施の形態３に係るバッファ制御方法を示すフロー図である。以下のバッファ制御方法は、ＰＤＣＰ処理部２０１が有するバッファの制御方法である。図７において、図２、５と同じ部分には同じ符号を付す。
【００５５】
アプリケーション処理部１１１によって生成される送信データは、ＰＤＣＰ処理部２０１へ出力され、所定長のパケットに分割された上で、ＰＤＣＰ処理部２０１が有するバッファに格納される（ステップＳ１０１）。パケットがバッファに格納される際には、それぞれのパケットについて、廃棄までの時間を規定する廃棄タイマが設定される（ステップＳ２０１）。廃棄タイマは、アプリケーションにとってのデータの期限に対応しており、例えば１０ｍｓ程度の時間が設定されても良い。
【００５６】
また、ＰＤＣＰ処理部２０１によって、ＲＬＣ処理部２０２における再送制御のパラメータの１つである最大再送回数が取得される（ステップＳ３０１）。この最大再送回数は、パケットの再送を制御するＲＬＣレイヤにおいて、再送が許容される最大の回数である。すなわち、ＲＬＣレイヤでは、パケットが正しく受信されないことを示すＮＡＣＫが受信側の装置から返送された場合にパケットの再送が実行されるが、再送が無制限に繰り返されるとスループットが低下するため、許容される最大の再送回数が設定されることがある。このため、ＰＤＣＰ処理部２０１によって、下位のＲＬＣレイヤの制御に用いられる最大再送回数が取得され、取得された最大再送回数に応じてパケットの廃棄条件が設定される。
【００５７】
パケットの廃棄条件が設定されると、ＰＤＣＰ処理部２０１は、パケットに対してＰＤＣＰレイヤの処理を実行しつつ、バッファに格納された各パケットについて、廃棄条件が満たされるか否かを監視する。
【００５８】
具体的には、パケットごとに設定された廃棄タイマが満了したか否かが判定される（ステップＳ２０３）。この判定の結果、廃棄タイマが満了した場合には（ステップＳ２０３Ｙｅｓ）、このパケットがＰＤＣＰ処理部２０１によって廃棄される（ステップＳ１０４）。一方、廃棄タイマが満了していない場合には（ステップＳ２０３Ｎｏ）、パケットの受信が成功したことが通知されたか否かが判定される（ステップＳ２０４）。すなわち、ＰＤＣＰレイヤでは、定期的に状態報告が受信側の装置から送信されるため、この状態報告によってパケットの受信が成功したか否かが判別可能である。そこで、ＰＤＣＰ処理部２０１によって、パケットの受信が成功したことが通知されている場合には（ステップＳ２０４Ｙｅｓ）、このパケットがＰＤＣＰ処理部２０１によって廃棄される（ステップＳ１０４）。一方、受信成功の通知がない場合には（ステップＳ２０４Ｎｏ）、バッファに格納されたパケットの再送回数が最大再送回数に到達したか否かが判定される（ステップＳ３０２）。すなわち、ＲＬＣレイヤにおける再送制御のための最大再送回数に到達したか否かが判定される。そして、パケットの再送回数が最大再送回数に到達している場合には（ステップＳ３０２Ｙｅｓ）、このパケットがＰＤＣＰ処理部２０１によって廃棄される（ステップＳ１０４）。
【００５９】
このように、廃棄条件が満たされるか否かが監視され、廃棄条件を満たすパケットがバッファから廃棄されることにより、ＰＤＣＰレイヤのバッファにおけるパケットの滞留時間が短縮される。特に、ＰＤＣＰレイヤよりも下位のＲＬＣレイヤの再送制御において用いられる最大再送回数が廃棄条件として利用されることにより、再送が失敗に終わるパケットが早期に廃棄され、無線伝送の遅延を低減することができる。換言すれば、新たな送信データとして低遅延データが発生した場合でも、低遅延データのパケットに対するＰＤＣＰレイヤの処理が迅速に実行され、少ない遅延で低遅延データを送信することが可能となる。
【００６０】
以上のように、本実施の形態によれば、ＰＤＣＰレイヤのパケットの廃棄条件を、ＲＬＣレイヤの再送制御のための最大再送回数に応じて設定し、再送回数が最大再送回数に到達したパケットをＰＤＣＰレイヤのバッファから廃棄する。このため、バッファにおけるパケットの滞留時間を短縮することができ、新規の送信データとして低遅延データが発生した場合でも、低遅延データが送信されるまでの遅延を削減することができる。結果として、低遅延データの遅延要求を満たすことができる。
【００６１】
なお、上記実施の形態３に係るバッファ制御方法によれば、例えば、非特許文献２４（ＴＳ３８．３２３）に記載のＳＤＵ廃棄に関する項目を例えば図８のように改めることができる。つまり、ＰＤＣＰ−ＳＤＵのための廃棄タイマが満了した場合、状態報告によってＰＤＣＰ−ＳＤＵの受信が成功したことが確認された場合、又は再送回数がＲＬＣレイヤの最大再送回数を示すmaxRetxThresholdに到達した場合にＰＤＣＰ−ＳＤＵが廃棄されるように規定しても良い。
【００６２】
また、上記各実施の形態においては、上位のレイヤのバッファにおけるパケットの廃棄条件を決定する情報が下位のレイヤの処理部から取得されるものとしたが、必ずしも下位のレイヤの処理部から情報が取得されなくても良い。すなわち、例えばＲＲＣ（Radio  Resource  Control）シグナリングによって、パケットの廃棄条件を決定する情報が基地局装置から通知されるようにしても良い。具体的には、例えば２ビットで表される第２の廃棄タイマとして（0.5ms,1ms,2ms,3ms）のいずれかの値を示すパラメータ（例えばdiscardTimer2などの名称が規定されたパラメータでも良い）がＲＲＣにおいて規定され、いずれかの値がＲＲＣシグナリング（例えば、RRC  Reconfiguration  message,  RRC  setup  messageなど）によって通知されても良い。また、第２の廃棄タイマを３ビットで表されるパラメータとして、上記実施の形態２のmaxPUSCH-Durationと同様の候補から値が指定されたり、さらに他の値が追加された候補から値が指定されたりしても良い。
【００６３】
また、ＲＲＣシグナリングによって、廃棄タイマの値をスケーリングするスケーリングファクタがＲＲＣにおいて規定され、スケーリングファクタの値が通知されても良い。例えばＰＤＣＰレイヤの廃棄タイマとして設定可能な値が（10ms,20ms,30ms,40ms,50ms,60ms,75ms,100ms,150ms,200ms,250ms,300ms,500ms,750ms,1500ms,無限）である場合、スケーリングファクタとして０．００２が通知されると、廃棄タイマの各値に０．００２が乗算されて廃棄条件に用いられるようにしても良い。この場合、廃棄条件として用いることが可能な値は（0.02ms,0.004ms,0.06ms,0.08ms,0.1ms,0.12ms,0.15ms,0.2ms,0.3ms,0.4ms,0.5ms,0.6ms,1.0ms,1.5ms,3.0ms,無限）となる。したがって、廃棄タイマの値をそのまま用いるよりも、パケットが廃棄されるまでの時間が短縮され、低遅延データの遅延要求を満たすことができる。スケーリングファクタは、複数の候補から動的に選択されるようにしても良い。
【００６４】
また、従来から規定されているパラメータが変更されても良い。例えばＰＤＣＰレイヤの従来の廃棄タイマとして設定可能な値が（10ms,20ms,30ms,40ms,50ms,60ms,75ms,100ms,150ms,200ms,250ms,300ms,500ms,750ms,1500ms,無限）であることを参考にして、無限を削除し1msを追加しても良い。この結果、廃棄タイマとして設定可能な値は（1ms,10ms,20ms,30ms,40ms,50ms,60ms,75ms,100ms,150ms,200ms,250ms,300ms,500ms,750ms,1500ms）となる。
【００６５】
なお、上記実施の形態１と実施の形態２とを組み合わせた場合、第１レイヤをＰＤＣＰレイヤ、第２レイヤをＭＡＣレイヤとしても良い。また、第１の情報を廃棄タイマの値、第２の情報をmaxPUSCH-Durationとしても良い。また、上記実施の形態１と実施の形態３とを組み合わせた場合、第１レイヤをＰＤＣＰレイヤ、第２レイヤをＭＡＣレイヤ、第３レイヤをＲＬＣレイヤとしても良い。
【符号の説明】
【００６６】
１１０  プロセッサ
１１１  アプリケーション処理部
１１２  第１レイヤ処理部
１１３  第２レイヤ処理部
１２０  メモリ
１３０  無線通信部
２０１  ＰＤＣＰ処理部
２０２  ＲＬＣ処理部
２０３  ＭＡＣ処理部
【図１】
2019244284.tif 000003
【図２】
2019244284.tif 000004
【図３】
2019244284.tif 000005
【図４】
2019244284.tif 000006
【図５】
2019244284.tif 000007
【図６】
2019244284.tif 000008
【図７】
2019244284.tif 000009
【図８】
2019244284.tif 000010
【手続補正書】
【提出日】令和3年1月6日(2021.1.6)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
送信データを保持するバッファを有し、送信データに対して第１レイヤの処理を実行する第１レイヤ処理部と、
送信データに対して前記第１レイヤとは異なる第２レイヤの処理を実行する第２レイヤ処理部と、
前記第１レイヤ処理部及び前記第２レイヤ処理部によって処理された送信データを送信可能な送信部とを有し、
前記第２レイヤ処理部は、
送信データに対してＭＡＣ（Medium  Access  Control）レイヤの処理を実行し、
前記第１レイヤ処理部は、
送信データに対してＰＤＣＰ（Packet  Data  Convergence  Protocol）レイヤの処理を実行し、送信データが前記バッファに保持されてから、ＭＡＣレイヤの優先制御に用いられるＰＵＳＣＨ（Physical  Uplink  Shared  CHannel）の最大送信時間であって、ＰＤＣＰレイヤにおいてあらかじめ定められた廃棄時間よりも短い時間に応じた時間が経過した場合に、前記バッファに保持された送信データを廃棄する
ことを特徴とする送信装置。
【請求項２】
前記送信装置は、移動局であることを特徴とする請求項１記載の送信装置。
【請求項３】
前記第１レイヤ処理部は、
送信データに対してＲＬＣ（Radio  Link  Control）レイヤの処理を実行し、
前記最大送信時間は、
ＲＬＣレイヤにおいてあらかじめ定められた廃棄時間よりも短い時間である
ことを特徴とする請求項１記載の送信装置。
【請求項４】
前記第２レイヤ処理部は、
送信データに対してＲＬＣレイヤの処理を実行し、
前記第１レイヤ処理部は、
前記バッファに保持された送信データの再送回数が、ＲＬＣレイヤの再送制御に用いられる最大再送回数に到達した場合に、前記バッファに保持された送信データを廃棄する
ことを特徴とする請求項１記載の送信装置。
【請求項５】
バッファに保持された送信データに対して第１レイヤの処理を実行し、
送信データに対して前記第１レイヤとは異なる第２レイヤの処理を実行し、
前記第２レイヤの処理において送信制御に用いられるパラメータに応じて、前記バッファに保持された送信データを廃棄する
処理を有することを特徴とするバッファ制御方法。
【請求項６】
ＲＲＣ（Radio Resource Control）シグナリングによって移動局を制御する基地局であって、
送信データが移動局のバッファに保持されてからＰＤＣＰ（Packet  Data  Convergence  Protocol）レイヤの処理として破棄されるまでの時間であって、ＭＡＣ（Medium  Access  Control）レイヤの優先制御に用いられるＰＵＳＣＨ（Physical  Uplink  Shared  CHannel）の最大送信時間に応じた時間を前記ＲＲＣシグナリングによって通知する制御部を有し、
前記最大送信時間は、ＰＤＣＰレイヤにおいてあらかじめ定められた廃棄時間よりも短い時間である
ことを特徴とする基地局。
【請求項７】
移動局と、前記移動局をＲＲＣ（Radio Resource Control）シグナリングによって制御する基地局とを有する無線通信システムであって、
前記移動局は、
送信データを保持するバッファを有し、送信データに対して第１レイヤの処理を実行する第１レイヤ処理部と、
送信データに対して前記第１レイヤとは異なる第２レイヤの処理を実行する第２レイヤ処理部と、
前記第１レイヤ処理部及び前記第２レイヤ処理部によって処理された送信データを送信可能な送信部とを有し、
前記第２レイヤ処理部は、
送信データに対してＭＡＣ（Medium  Access  Control）レイヤの処理を実行し、
前記第１レイヤ処理部は、
送信データに対してＰＤＣＰ（Packet  Data  Convergence  Protocol）レイヤの処理を実行し、
送信データが前記バッファに保持されてから、ＭＡＣレイヤの優先制御に用いられるＰＵＳＣＨ（Physical  Uplink  Shared  CHannel）の最大送信時間であって、ＰＤＣＰレイヤにおいてあらかじめ定められた廃棄時間よりも短い時間に応じた時間が経過した場合に、前記バッファに保持された送信データを廃棄する
ことを特徴とする無線通信システム。
【手続補正２】
【補正対象書類名】明細書
【補正対象項目名】０００３
【補正方法】変更
【補正の内容】
【０００３】
一方で、ＩｏＴ（Internet  of  things）サービス（例えば、交通システム、スマートメータ、装置等の監視システム）の展開に合わせて、多様な要求条件を持つサービスに対応することが求められている。そのため、第５世代移動体通信（５Ｇ又はＮＲ（Ｎｅｗ  Ｒａｄｉｏ））の通信規格では、４Ｇ（第４世代移動体通信）の標準技術（例えば、非特許文献１〜１１）に加えて、さらなる高データレート化、大容量化、低遅延化を実現する技術が求められている。なお、第５世代通信規格については、３ＧＰＰの作業部会（例えば、ＴＳＧ−ＲＡＮ  ＷＧ１、ＴＳＧ−ＲＡＮ  ＷＧ２等）で技術検討が進められている。（非特許文献１２〜３９）。現在、３ＧＰＰが規定する５Ｇの標準仕様の初版がリリースされている。
【手続補正３】
【補正対象書類名】明細書
【補正対象項目名】００１３
【補正方法】変更
【補正の内容】
【００１３】
本願が開示する送信装置は、１つの態様において、送信データを保持するバッファを有し、送信データに対して第１レイヤの処理を実行する第１レイヤ処理部と、送信データに対して前記第１レイヤとは異なる第２レイヤの処理を実行する第２レイヤ処理部と、前記第１レイヤ処理部及び前記第２レイヤ処理部によって処理された送信データを送信可能な送信部とを有し、前記第２レイヤ処理部は、送信データに対してＭＡＣ（Medium  Access  Control）レイヤの処理を実行し、前記第１レイヤ処理部は、送信データに対してＰＤＣＰ（Packet  Data  Convergence  Protocol）レイヤの処理を実行し、送信データが前記バッファに保持されてから、ＭＡＣレイヤの優先制御に用いられるＰＵＳＣＨ（Physical  Uplink  Shared  CHannel）の最大送信時間であって、ＰＤＣＰレイヤにおいてあらかじめ定められた廃棄時間よりも短い時間に応じた時間が経過した場合に、前記バッファに保持された送信データを廃棄する。
【手続補正４】
【補正対象書類名】明細書
【補正対象項目名】００６３
【補正方法】変更
【補正の内容】
【００６３】
また、ＲＲＣシグナリングによって、廃棄タイマの値をスケーリングするスケーリングファクタがＲＲＣにおいて規定され、スケーリングファクタの値が通知されても良い。例えばＰＤＣＰレイヤの廃棄タイマとして設定可能な値が（10ms,20ms,30ms,40ms,50ms,60ms,75ms,100ms,150ms,200ms,250ms,300ms,500ms,750ms,1500ms,無限）である場合、スケーリングファクタとして０．００２が通知されると、廃棄タイマの各値に０．００２が乗算されて廃棄条件に用いられるようにしても良い。この場合、廃棄条件として用いることが可能な値は（0.02ms,0.04ms,0.06ms,0.08ms,0.1ms,0.12ms,0.15ms,0.2ms,0.3ms,0.4ms,0.5ms,0.6ms,1.0ms,1.5ms,3.0ms,無限）となる。したがって、廃棄タイマの値をそのまま用いるよりも、パケットが廃棄されるまでの時間が短縮され、低遅延データの遅延要求を満たすことができる。スケーリングファクタは、複数の候補から動的に選択されるようにしても良い。
【国際調査報告】
2019244284.tif 000011
2019244284.tif 000012
2019244284.tif 000013
2019244284.tif 000014