JP2012517732A - 無線通信システムにおける方法および構成 - Google Patents

Abstract

端末（１２０）から受信されるデータの量を推定する基地局（１１０）における方法および構成である。基地局（１１０）および端末（１２０）は、無線通信システム（１１０）内に含まれる。端末（１２０）は、データを含むフレームをバッファリングするように構成されるバッファを備える。上記方法は、端末（１２０）により要求されるサービスを判定するステップ（４０１）と、判定されたサービスに基づいて、端末（１２０）から受信されるデータの到着時間を推定するステップ（４０３）と、データが到着したと推定される場合に、判定されたサービスについての推定されるフレームサイズに基づいて、受信されるデータの量の推定値を含むバッファ推定値を設定するステップ（４０４）と、を含む。
【選択図】図４

Description

本発明は、無線通信システムにおける方法および構成に関する。より具体的には、本発明は、バッファ推定の改善のためのメカニズムに関する。

第３世代パートナーシッププロジェクト（３ＧＰＰ）では、ＬＴＥ（Long Term Evolution）の成果の一部としてＥ−ＵＴＲＡ（UMTS Terrestrial Radio Access Network (UTRAN) evolution）の仕様について研究が行われている。

ＬＴＥでは、スケジューリングは、媒体アクセス制御（ＭＡＣ）層においてモデル化され、ｅＮｏｄｅＢ（ｅＮＢ）に属する。スケジューラは、物理ダウンリンク制御チャネル（ＰＤＣＣＨ）を使用して、ダウンリンク（割当て）およびアップリンク（許可）についてのリソースブロック（ＲＢ）とも呼ばれる無線リソースを割当てる。

無線アップリンクは、ユーザ機器（ＵＥ）とも呼ばれ得る端末から基地局またはｅＮｏｄｅＢへの通信パスである。ダウンリンクは、アップリンクの逆であり、すなわちｅＮｏｄｅＢから端末への送信パスである。

アップリンクのスケジューリングのために、ｅＮｏｄｅＢは、端末の中のバッファの現在の状態についての情報、すなわち端末が優先順位付待ち行列の中にどのくらいのデータを有しているかについての情報を必要とする。この情報は、１ビットのスケジューリング要求（ＳＲ）としてまたはバッファ状態報告（ＢＳＲ）により、端末からｅＮｏｄｅＢに送信される。スケジューリング要求は、物理アップリンク制御チャネル（ＰＵＣＣＨ）または無線アクセスチャネル（ＲＡＣＨ）等の制御チャネル上で送信される。一方で、ＢＳＲは、ほとんどの場合にユーザデータと共に、物理アップリンク共有チャネル（ＰＵＳＣＨ）等のデータチャネル上で送信される。

正確で最新のスケジューリング情報は、より正確なスケジューリングの決定を可能とし、ユーザおよび無線リソースの管理を最適化し、キャパシティを改善するのに役立つことの可能である。しかしながら、端末により提供される情報の正確性は、バッファ状態報告の粒度、スケジューリング要求およびバッファ状態報告の送信の頻度、並びにスケジューリング要求またはバッファ状態報告の受信とスケジューリングの決定との間の遅延によって、制限される。

ＶｏＩＰ（Voice over Internet Protocol）等の周期的なパケットの到着を伴う遅延センシティブのサービスについて、それが使用される場合にバッファ状態情報が古くなる可能性は高い。バッファ状態報告が送信されてから追加のデータが到着する可能性が高い。また、バッファは頻繁に空となり、したがって唯一の利用可能な情報は１ビットのスケジューリング要求となる可能性が高い。

正しくないアップリンク情報のために、スケジューラは、端末がパディングを送信してシステムのキャパシティを減少させ得ることになる大きすぎる許可（grant）、または無線リンク制御（ＲＬＣ）の分割につながって送信遅延を増加させ得る小さすぎる許可、のいずれかを提供する。

アップリンクのバッファ状態報告は、端末の中で送信を待つデータの量を基地局が知得するために必要である。Ｅ−ＵＴＲＡＮでは、アップリンクのバッファ状態報告は、端末の中で論理チャネルグループ（ＬＣＧ）についてバッファリングされるデータを参照する。４つのＬＣＧおよび２つのフォーマットが、アップリンクにおける報告について使用される。

短いバッファ状態報告のフォーマットは、１つのＬＣＧのバッファサイズを含み、長いバッファ状態報告のフォーマットは、４つのＬＣＧ全てのバッファサイズを含む。

アップリンクのバッファ状態報告は、ＭＡＣシグナリングを使用して送信される。

ＬＴＥにおける既知のソリューションによると、バッファ状態報告のためのフレームワークが仕様化されている。バッファ状態報告が端末により使用されて、送信のためにバッファに記憶されているデータの量がｅＮｏｄｅＢに報告される。ｅＮｏｄｅＢは、これらの報告を使用して、端末にリソースを割当て、様々な端末間でのリソース割当てに優先順位をつける。

アップリンクデータが送信可能であって、このデータが、バッファの中に既に存在するデータについての優先順位よりもより高い優先順位を伴う無線ベアラのグループ、すなわち論理的なチャネルのグループに属する場合に、または、この新たなデータが送信可能となる直前に端末のバッファが空である場合に、端末は通常のバッファ状態報告およびスケジューリング要求をトリガする。

送信のためのＭＡＣのプロトコルデータユニット（ＰＤＵ）の組立て時において転送ブロックサイズが送信可能なデータの量よりも大きい場合に、パディングバッファ状態報告と呼ばれる１つのバッファ状態報告が含まれる。端末が、１つの論理チャネルについての情報のみを含むことが可能なバッファ状態報告のフォーマット以外の１つを超える論理チャネルについてのデータを有する場合に、トランケート（truncate）されたフォーマットも、パディングバッファ状態報告として利用可能である。

別の種類のバッファ状態報告である周期的なバッファ状態報告は、連続的なフローについての報告を扱うために端末毎にタイマに基づくトリガを提供する。

図１は、ベストエフォート型のデータサービスについて採用されるスケジューリングの原理がＶｏＩＰに適用される場合に起こり得ることの単純化された例を示す。不要な遅延および多数の許可送信がもたらされている。スケジューリング要求は、バッファ状態報告および小さな量のデータのみを可能とする小さな許可をトリガする。許可を待つ間に、別のパケットが到着する。よって、最初の２つの許可は、１つの単一のパケットを送信するために費やされ、第２の許可を用いて送信できたパケットは、別の許可を待たなければならない。

現在のバッファ状態報告のフレームワークには、いくつかの欠点がある。例えば、バッファ状態情報は、スケジューリングの決定の中で使用される時に古くなっている可能性が高い。また、バッファ状態情報は、スケジューリングの決定において使用される場合に、１ビットのスケジューリング要求のみに基づく可能性が高い。さらに、より効率的な手法でバッファの状態を決定するソリューションは、非常に有用である。

上記デメリットの少なくともいくつかを取り除き、通信システム内で改善されたパフォーマンスを提供することが、目的である。

第１の形態によると、上記目的は、基地局における方法により達成される。方法は、端末から受信されるデータの量を推定することを目指す。基地局および端末は、無線通信システム内に含まれる。端末は、データを含むフレームをバッファリングするように構成されるバッファを備える。上記方法は、端末により要求されるサービスを判定するステップを含む。また、上記方法は、判定されたサービスに基づいて端末から受信されるデータの到着時間を推定するステップを含む。さらに、上記方法は、データが到着したと推定される場合に、判定されたサービスについての推定されるフレームサイズに基づいて、受信されるデータの量の推定値を含むバッファ推定値を設定するステップをさらに含む。

第２の形態によると、目的は、基地局における構成によっても達成される。上記構成は、端末から受信されるデータの量を推定することを目指す。基地局および端末は、無線通信システム内に含まれる。上記構成は、データを含むフレームをバッファリングするように構成されるバッファを備える。前記構成は、判定部を備える。当該判定部は、端末により要求されるサービスを判定するように適合される。上記構成は、推定部も備える。当該推定部は、判定されたサービスのフレーム間隔に基づいて、端末から受信されるデータの到着時間を推定するように適合される。さらに、上記構成は、設定部も備える。当該設定部は、判定されたサービスについての推定されるフレームサイズに基づいて、受信されるデータのサイズの推定値を含むバッファ推定値を設定するように適合される。

本方法および構成に従って端末から受信されるデータの量を推定することにより、改善されたスケジューリングの決定が、基地局によりとられることが可能となる。これは、パケットの遅延を減らし、無線リソースの利用を改善することができる。また、基地局と端末との間のシグナリングの総量が減少し得る。システム内で送信される許可の数は、同時にシステムを使用し得る端末の数を制限するため、より少ない許可が送信されなければならない場合に、より多くの端末に参加させることにより、システム内の負荷を増加させることが可能である。したがって、通信システム内の改善された性能が提供される。

本発明の他の目的、利点および新規の特徴は、以下の本発明の詳細な説明から明らかになるであろう。

本発明は、以下の同封の図面に関連してより詳細にここで説明されるであろう。
従来技術に従ったスケジューリングの通信を説明するブロック図である。 無線通信システムを説明する概略的なブロック図である。 いくつかの実施形態に従ったスケジューリングの通信を説明するフローチャートである。 無線基地局における方法のステップの実施形態を説明するフローチャートである。 無線基地局における構成の実施形態を説明するブロック図である。

本発明は、基地局における方法および構成として定義される。以下に説明される実施形態の中で実行され得る。しかしながら、この発明は、多数の様々な形式の中で具現化され得る。また、この発明は、ここで説明される実施形態に限定されて解釈されるべきではない。むしろ、これらの実施形態は、この開示が完全であり完成しているように提供され、当業者に本発明の範囲を十分に伝えるであろう。開示される特定の形式のいずれかに本方法および／または構成を限定する意図はなく、反対に、本方法および構成は、特許請求の範囲により定義されるように本発明の範囲に含まれる全ての改良、等価なものおよび代替するものをカバーするものである、ということが理解されるべきである。

当然ながら、本発明は、本発明の本質的な特徴から逸脱することなく、これらの具体的にここで説明される手法とは別の手法で実行されてもよい。本実施形態は、全ての点で限定ではなく説明ためのものと考えられるべきである。また、趣旨内にくる全ての変更および添付の特許請求の範囲の等価の範囲は、そこに包含されることを意図されている。

図２は、無線通信ネットワーク１００の概略的な説明である。無線通信ネットワーク１００は、少なくとも１つの基地局１１０を含み、少なくとも１つの端末１２０を含むように構成される。基地局１１０は、セル１３０内に位置する端末１２０へ無線信号を送信し、当該端末１２０から無線信号を受信し得る。

唯一の基地局１１０が図２の中に示されているが、基地局送受信機の別の構成は、無線通信ネットワーク１００を定義するために、例えば移動通信交換局および他のネットワークノードを通して接続され得る、ということが理解されるべきである。さらに、基地局１１０は、例えば使用される無線アクセス技術および専門用語に応じて、例えば、リモート無線ユニット、アクセスポイント、ＮｏｄｅＢ、ｅＮｏｄｅＢ、（evolved NodeB）および／または基地局送受信機局、無線基地局（ＲＢＳ）アクセスポイント基地局、基地局ルータ等と呼ばれてもよい。

いくつかの実施形態では、端末１２０は、無線通信装置、無線通信端末、モバイルセルラー電話、パーソナル通信システム端末、形態情報端末（ＰＤＡ）、ラップトップ、ユーザ機器（ＵＥ）、コンピュータ、または無線リソースを管理可能ないずれかの他の種類の装置により表されてもよい。

いくつかの任意の限定しない例を挙げると、無線通信ネットワーク１００は、例えば、ＬＴＥ（Long Time Evolution）、ＧＳＭ（Global System for Mobile Telecommunications）、ＥＤＧＥ（Enhanced Data rates for GSM Evolution）、ＧＰＲＳ（General Packet Radio Service）、符号分割多元接続（ＣＤＭＡ）、広帯域符号分割多元接続（ＷＣＤＭＡ）、ＣＤＭＡ２０００、高速弾リンクパケットデータアクセス（ＨＳＤＰＡ）、高速アップリンクパケットデータアクセス（ＨＳＵＰＡ）、ＨＤＲ（High Data Rate）、高速パケットデータアクセス（ＨＳＰＡ）、ＵＭＴＳ（Universal Mobile Telecommunications System）等の技術に基づいてもよい。

さらに、ここで使用されるように、無線通信ネットワーク１００は、いくつかの実施形態にしたがって、ＷｉＦｉ（Wireless Fidelity）およびＷｉＭＡＸ（Worldwide Interoperability for Microwave Access）、ブルートゥース等の、またはいずれかの他の無線通信技術に従った、無線ローカルエリアネットワーク（ＷＬＡＮ）にさらに言及してもよい。

しかしながら、本ソリューションは、無線通信ネットワーク１００内の無線インターフェース上でもっぱら実行されるようには全く限定されず、いくつかのノードが無線で接続していくつかのノードが有線接続を有する無線通信ネットワーク１００内で実行されてもよい、ということが留意されるべきである。

いくつかの特定の限定しない実施形態によると、無線通信ネットワーク１００は、例えば、ＶｏＩＰ（Voice Over IP）等の様々なサービスを端末１２０に提供するように適合されてもよい。

いくつかのオプションの実施形態によると、無線通信ネットワーク１００は、例えば使用されるアクセス技術に応じて制御ノードを含んでもよい。制御ノードは、例えば無線ネットワークコントローラ（ＲＮＣ）であってもよい。制御ノードは、無線通信ネットワーク１００の中の統制要素であり、制御ノードに接続される基地局１１０の制御を担う。制御ノードのいくつかの機能性の候補を説明するいくつかの簡単な例を挙げると、オプションの制御ノードは、例えば、移動性管理機能のいくつかのような無線リソース管理をさらに実行してもよく、基地局１１０から端末１２０に送信される情報データに関連付けられる変調情報を提供してもよい。

端末１２０は、無線通信ネットワーク１００内に含まれる基地局１１０を介して、図１に示されていない他の端末とさらに通信してもよい。

基地局１１０は、端末１２０から基地局１１０へのアップリンク送信をスケジューリングするようにさらに適合されてもよい。図３に関連してより詳細にさらに説明されるように、特定の端末１２０に特定のアップリンクリソースへのアクセスを許可するために、端末１２０における推定されたバッファ状態に基づいて、許可が基地局１１０から特定の端末１２０に送信される。

「ダウンリンク」という表現は、基地局１１０から端末１２０への送信を特定するためにここでは使用され、「アップリンク」という表現は、端末１２０から基地局１１０への送信を示すために使用される。

図３は、いくつかの実施形態に従った、バッファ状態の推定のためのメカニズムを説明する。基地局１１０は、第１のパケットが端末１２０のバッファにいつ到着したかについての推測を確立し得る。上記推測は、到着時間およびパケットサイズを推測するためのサービスの振るまいについての知識に基づき得る。当該知識は、例えばほとんどのＶｏＩＰのコーデックは通話時に２０ｍｓの固定のフレーム間隔を有することを含んでもよい。また、無音状態では、フレーム間隔は例えば１６０ｍｓ（ＡＭＲ）にまで増加し得る。さらに、例えばパケットサイズは前回のパケットと同じサイズであると推定され得る、ということが仮定されてもよい。それは、ＲＯＨＣ（Robust Header Compression）が適用される場合にも有効であってもよい。さらに、いくつかの実施形態によると、通話状態から無音状態への変化等のコーデックの状態の変化が、受信パケットのサイズを調べることによって検出されてもよい。

本方法は、可能な限り短い遅延で効率的にデータをスケジューリングすることを目指す。図３において説明された限定しない説明のための例に見られるように、３２０ビットのデータパケットが端末１２０の中でバッファリングされる。状態報告（ＳＲ）が、端末１２０から基地局１１０に送信されてもよい。基地局１１０は、基地局１１０から送信される許可が端末１２０に伝えられる前にさらなる３２０ビットのパケットが端末１２０に到着し得ると推定する。したがって、６４０ビットの許可が基地局１１０から端末１２０に送信され得る。上記許可が受信されると、端末１２０は、６４０ビットを含む２つのデータパケットを基地局１１０に送信し得る。

基地局１１０での端末のバッファの推定は、通話フレームがユーザの通話時に２０ｍｓ毎等の既知の期間での送信の準備ができているという知識を利用することによってＶｏＩＰのキャパシティを増加させることを意図されるアルゴリズムを適用することにより、実行されてもよい。この知識を使用することにより、バッファ推定部は、ＳＲまたはＢＳＲのいずれも受信しなくても端末１２０に許可するために、先にバッファの推定値を端末１２０に加え得る。したがって、先回りの許可が、基地局１１０から端末１２０に送信され、したがってシステム１００内の全体のトラフィック負荷を低減し得る。高い負荷のかかるシステム１００の中におけるバッファ状態のより正確な推定も可能となる。端末１２０がスケジューリングされる間隔は２０ｍｓよりも高くてもよく、したがって、複数のフレームが単一の許可の中で含まれてもよい。

上記アルゴリズムは、さらに、ＳＩＤおよびＴＡＬＫのような少なくとも２つの状態を区別し、当該少なくとも２つの状態の間で変わってもよい。状態の変化は、通話状態および無音状態のような対応する状態の間でコーデックが切り替わる場合に発生し得る。ＴＡＬＫ状態は、次の通話フレームがいつ到着するかおよび当該通話フレームはどのサイズを有するかを推測する、先回りの（proactive）バッファ推定の状態と考えら得る。一方で、ＳＩＤ状態は、端末１２０のためにデータが到着した場合にＳＲを期待する、消極的な（passive）状態と考えられ得る。

ＴＡＬＫ状態において
要求受信のスケジューリングにおいて、最新のバッファ推定値が０であれば、バッファサイズは１つの通話フレームの期待サイズに設定され、推定到着時間が要求送信の時間に設定される。また、要求受信のスケジューリングにおいて、この端末１２０についての最新のバッファ推定値が０でなければ、いくつかの実施形態によると、何も行われない。

最近の推定される到着後の通話フレームの間隔について、バッファサイズの推定値は、最後の受信フレームのサイズにより増加され、最近の推定到着時間を最新の時間に設定され得る。

ＢＳＲの受信において、バッファサイズの推定値は、報告に従って更新され得る。

ＲＬＣのＳＤＵの受信において、ＳＩＤフレームのサイズと通話フレームのサイズとの間であり得る通話閾値よりもＳＤＵのサイズが小さい場合に、ＳＩＤの状態となり得る。

したがって、いくつかの実施形態では、以下のとおりである。

転送ブロックの受信において、いくつかの実施形態によると、２つの連続する信号がパディングのみで受信される場合に、ＳＩＤ状態となり得る。

ＳＩＤ状態において
要求受信のスケジューリングにおいて、最新のバッファ推定値が０であれば、バッファサイズはＳＩＤフレームの期待サイズに設定され、推定到着時間は要求送信時間に設定され得る。このユーザについての最新のバッファ推定値が０でなければ、いくつかの実施形態によると、何も行われない。

ＢＳＲの受信において、バッファサイズの推定値は報告に従って更新され得る。また、ＢＳＲの受信において、ＶｏＩＰの待ち行列において示される残りのサイズが、ＳＩＤフレームのサイズに類似し得るＳＩＤ閾値よりも大きい場合に、ＴＡＬＫ状態となり得る。

ＲＬＣのＳＤＵの受信において、ＳＤＵのサイズが、ＳＩＤフレームのサイズと通話フレームのサイズとの間であるべき通話閾値よりも大きい場合に、ＴＡＬＫ状態となり得る。

図４は、基地局１１０の中で実行される方法のステップ４０１−４１０の実施形態を説明するフローチャートである。当該方法は、端末１２０から受信されるデータの量を推定することを目指す。基地局１１０および端末１２０は、無線通信システム１００内に含まれる。端末１２０は、データを含むフレームをバッファリングするように構成されるバッファを含む。上記方法は、第１の先回りのバッファ推定状態または第２の消極的な状態のいずれかで実行され得る。第１の先回りのバッファ推定状態は、通話コーデックの状態に対応し得る。第２の消極的な状態は、無音コーデックの状態に対応する。

端末１２０から受信されるデータの量を適切に推定するために、方法は、いくつかの方法のステップ４０１−４１０を含み得る。

しかしながら、方法のステップ４０１−４１０のうちのいくつかは、オプションであり、いくつかの実施形態でのみ実行されてもよい、ということが留意されるべきである。さらに、様々な実施形態によれば、方法のステップ４０１−４１０は、任意の時系列の順序で実行されてもよく、ステップ４０６およびステップ４０７等の方法のステップのうちのいくつか、またはステップ４０１−４１０の全ては、同時に、または変えられ、任意に再配置され、分解され、若しくは完全に逆にされた時系列の順序で、実行されてもよい。方法は、以下のステップを含み得る。

ステップ４０１
端末１２０がどのサービスを要求するかが判定される。サービスは、例を挙げると、例えばＶｏＩＰであってもよい。

ステップ４０２
このステップは、オプションであり、いくつかの実施形態でのみ実行されてもよい。

スケジューリング要求が端末１２０から受信される。

ステップ４０３
端末１２０から受信されるデータの到着時間が、判定されたサービスに基づいて推定される。いくつかの実施形態によると、到着時間の推定は、判定されたサービスのフレーム間隔に基づいてもよい。

データの到着時間の推定は、オプションで、受信されたスケジューリング要求に基づいてもよい。

ステップ４０４
データが到着したと推定される場合に、受信されるデータの量の推定値を含むバッファ推定値が、判定されたサービスについての推定されるフレームサイズに基づいて設定される。

バッファ推定値は、オプションで、端末１２０から受信されるバッファ状態報告に従って更新されてもよい。

ステップ４０５
このステップは、オプションであり、いくつかの実施形態でのみ実行されてもよい。

許可が端末１２０へ送信されてもよい。許可は、許可のサイズを上限としてデータを送信することを端末１２０に可能にする。

ステップ４０６
このステップは、オプションであり、いくつかの実施形態でのみ実行されてもよい。

データが端末１２０から受信されてもよい。

限界値（threshold limit value）よりも小さいサービスデータユニット（ＳＤＵ）が端末１２０から受信される場合に、方法の状態は、消極的な状態に設定されてもよく、そうでなければ、方法の状態は、先回りのバッファ推定の状態に設定されてもよい。

限界値は、オプションで、無音挿入記述子（ＳＩＤ）フレームのサイズ以上かつ通話フレームのサイズ以下の値に設定されてもよい。

パディングのみを含む２つの連続するフレームが、端末１２０から受信される場合に、方法の状態は、消極的な状態に設定されてもよい。

ステップ４０７
このステップは、オプションであり、いくつかの実施形態でのみ実行されてもよい。

受信データのサイズが判定されてもよい。

ステップ４０８
このステップは、オプションであり、いくつかの実施形態でのみ実行されてもよい。

状態は、判定された受信データのサイズに基づいて設定されてもよい。状態は、第１の先回りのバッファ推定の状態または第２の消極的な状態のいずれかであってもよい。

ステップ４０９
このステップは、オプションであり、いくつかの実施形態でのみ実行されてもよい。

バッファの推定値が０に設定される場合に、推定される到着時間は、スケジューリング要求の送信時間に設定されてもよく、バッファ推定値は、設定された状態に従って１つの状態固有のフレームサイズの期待サイズに設定されてもよい。

ステップ４１０
このステップは、オプションであり、いくつかの実施形態でのみ実行されてもよい。

方法が第１の先回りのバッファ推定状態で実行される場合に、最後の期待到着時間の後の１フレーム間隔で、バッファ推定値は、推定されるフレームサイズのサイズだけ増加させられてもよく、最近の推定される到着時間がその時点の時間に設定されてもよい。推定されるフレームサイズは、最後の受信フレームのサイズであってもよい。

図５は、基地局１１０の中に位置する構成５００の実施形態を説明するブロック図である。構成５００は、端末１２０から受信されるデータの量を推定する方法のステップ４０１−４１０を実行するように構成される。基地局１１０および端末１２０は、無線通信システム１００内に含まれる。端末１２０は、データを含むフレームをバッファリングするように構成されるバッファを含む。

明確性のために、本方法を実行するために完全に必要というわけではない、構成５００のいずれかの内部の電子機器は、図５から省略されている。

構成５００は、第１の判定部５０１を備える。第１の判定部５０１は、端末１２０により要求されるサービスを判定するように適合される。さらに、構成５００は、推定部５０３を備える。推定部５０３は、判定されたサービスのフレーム間隔に基づいて、端末１２０から受信されるデータの到着時間を推定するように適合される。また、構成５００は、第１の設定部５０４を備える。第１の設定部５０４は、判定されたサービスについての推定されるフレームサイズに基づいて、受信されるデータのサイズの推定値を含むバッファ推定値を設定するように適合される。

構成５００は、受信部５０２をさらに備えてもよい。受信部５０２は、スケジューリング要求および／若しくはデータ並びに／またはバッファ状態報告を端末１２０から受信するように適合されてもよい。さらに、構成５００は、送信部５０５を備えてもよい。送信部５０５は、端末１２０へ許可を送信するように適合されてもよい。さらに、構成５００は、追加で第２の判定部５０７を備えてもよい。第２の判定部５０７は、受信データのサイズを判定するように適合されてもよい。また、構成５００は、オプションで、第２の設定部５０８を備えてもよい。第２の設定部５０８は、判定された受信データのサイズに基づいて状態を設定するように適合されてもよい。さらに、構成５００は、第３の設定部５０９も備えてもよい。第３の設定部５０９は、推定される到着時間をスケジューリング要求の送信時間に設定し、設定された状態に従って、バッファ推定値を１つの状態固有のフレームサイズの期待サイズに設定するように、適合されてもよい。さらに、構成５００は、増加部５１０をさらに備えてもよい。増加部５１０は、最後の期待される到着時間の後の１フレーム間隔で、推定されるフレームサイズのサイズだけバッファ推定値を増加させ、最近の推定される到着時間をその時点の時間に設定するように、適合されてもよい。

いくつかの実施形態によると、構成５００は、処理部５２０をさらに含む。処理部５２０は、中央制御装置（ＣＰＵ）、プロセッサ、マイクロプロセッサ、または命令を解釈し実行し得る他の処理ロジック等によって、繰り返されてもよい。処理部５２０は、入力、出力、並びに、呼処理制御、ユーザインターフェース制御等の装置制御機能およびデータのバッファリングを含むデータ処理のための、全てのデータ処理機能を実行してもよい。

構成５００内に備えられる説明された５０１−５２０の部は、別々の論理的なエンティティとみなされてもよいが、必ずしも別々の物理的なエンティティとみなされなくてもよい、ということが留意されるべきである。５１０−５２０の部のいずれか、いくつかまたは全ては、同一の物理的な装置内に含まれ、または配置されてもよい。しかしながら、構成５００の機能性の理解を容易にするために、備えられる５０１−５２０の部は、図５では別々の部として説明される。

したがって、いくつかの実施形態によると、送信部５０５および例えば受信部５０２は、１つの物理的な装置である送受信機内に含まれてもよい。当該送受信機は、オプションのアンテナを介して、それぞれ、端末１２０への発信無線周波数信号を送信し、端末１２０からの着信無線周波数信号を受信する、送信回路および受信回路を含み得る。基地局１１０と端末１２０との間で通信される無線周波数信号は、着呼のためのページング信号／メッセージ等のトラフィック信号および制御信号の両方を含んでもよい。当該トラフィック信号および当該制御信号は、使用されて、相手との音声電話通信を確立し維持し、ＳＭＳ,ｅ−ｍａｉｌ、またはＭＭＳメッセージ等のデータを送信しおよび／または受信し得る。

基地局１１０におけるコンピュータプログラムプロダクト
基地局１１０における方法のステップ４０１−４１０は、本方法４０１−４１０の機能を実行するためのコンピュータプログラムコードと共に基地局１１０の中の１つ以上の処理部５２０を通じて実装され得る。したがって、基地局１１０における方法のステップ４０１−４１０を実行するための命令を含むコンピュータプログラムプロダクトは、端末１２０から受信されるデータの量を推定し得る。

上記コンピュータプログラムプロダクトは、例えば、処理部５２０に読み込まれると本ソリューションに従った方法のステップを実行するコンピュータプログラムコードを搬送するデータキャリアの形式で提供されてもよい。データキャリアは、ハードディスク、ＣＤ−ＲＯＭ、メモリスティック、光記憶装置、磁気記憶装置、または、機械により読み取り可能なデータを保持可能なディスク若しくはテープ等のいずれかの他の適切な媒体であってもよい。コンピュータプログラムコードは、さらに、サーバ上で純粋なプログラムとして提供され、例えばインターネットまたはイントラネットの接続上でリモートで基地局１１０にダウンロードされることも可能である。

さらに、コンピュータプログラムプロダクトが基地局１１０内に備えられる処理部５２０上で実行される場合に、方法のステップ４１０−４１０のうちの少なくともいくつかを実行するための命令を含むコンピュータプログラムプロダクトが、基地局１１０の中で上記方法を実装するために使用されてもよい。

本発明は、無線基地局１１０における方法および構成、並びに／またはコンピュータプログラムプロダクトとして、具現化されてもよい。したがって、本発明は、完全にハードウェアの実施形態、ソフトウェアの実施形態、またはソフトウェアおよびハードウェアの組合せの携帯の形式をとってもよく、それら全ては、概してここでは「回路」と呼ばれる。さらに、本発明は、媒体の中で具現化されたコンピュータに使用可能なプログラムコードを有するコンピュータに使用可能な記憶媒体上のコンピュータプログラムプロダクトの形式をとってもよい。ハードディスク、ＣＤ−ＲＯＭ、光記憶装置、インターネット若しくはイントラネットをサポートする通信媒体等の通信媒体、、または磁気記憶装置を含む、いずれかの適したコンピュータに読み取り可能な媒体が、利用されてもよい。

添付の図面の中で説明された具体的な例示の実施形態の詳細な説明で使用された用語は、本発明を限定することを意図されていない。

ここで使用されるように、単数形の「a」「an」および「the」は、明示的にそうではないと記載されなければ、複数形も含むことを意図されている。用語「含む（include,including）」および／または「備える、含む（comprise,comprising）」は、この明細書中で使用される場合に、記載された特徴、整数、ステップ、動作、要素および／またはコンポーネントの存在を特定するが、１つ以上の他の特徴、整数、ステップ、動作、要素、コンポーネント、および／またはそれらのグループの存在または追加を除外しない、ということがさらに理解されるであろう。要素が他の要素と「接続される(connected)」または「結合される(coupled)」と呼ばれる場合に、当該要素は直接的に他の要素に接続されまたは結合されることが可能であり、または介在する要素が存在してもよい、ということが理解されるであろう。さらに、ここで使用されるように「接続される(connected)」または「結合される(coupled)」は、無線で接続されまたは結合されることを含み得る。ここで使用されるように、用語「および／または（and/or）」は、関連付けられるリスト化された項目のうちの１つ以上のいずれかの組合せおよび全ての組合せを含む。

Claims (11)

1. 端末（１２０）から受信されるデータの量を推定する基地局（１１０）における方法であって、前記基地局（１１０）および前記端末（１２０）は、無線通信システム（１００）内に含まれ、前記端末（１２０）は、データを含むフレームをバッファリングするように構成されるバッファを備え、前記方法は：
   前記端末（１２０）により要求されるサービスを判定するステップ（４０１）と；
   判定された前記サービスに基づいて、前記端末（１２０）から受信されるデータの到着時間を推定するステップ（４０３）と；
   データが到着したと推定される場合に、判定された前記サービスについての推定されるフレームサイズに基づいて、受信されるデータの量の推定値を含むバッファ推定値を設定するステップ（４０４）と；
   を含む、方法。
2. 前記データの到着時間を推定する前記ステップ（４０３）は、判定された前記サービスのフレーム間隔に基づいて前記推定を行うことを含む、請求項１に記載の方法。
3. 前記端末（１２０）からのスケジューリング要求を受信するステップ（４０２）をさらに含み、
   前記データの到着時間を推定する前記ステップ（４０３）は、受信された前記スケジューリング要求に基づいて前記データの到着時間の前記推定を行うことを含む、
   請求項１または２に記載の方法。
4. 前記端末（１２０）に許可を送信するステップ（４０５）をさらに含み、
   前記許可は、当該許可のサイズを上限としてデータを送信することを前記端末（１２０）に可能にする、
   請求項１から３のいずれかに記載の方法。
5. 前記方法は、第１の先回りのバッファ推定の状態または第２の受動的な状態のいずれかで実行され、前記方法は：
   前記端末（１２０）からデータを受信するステップ（４０６）と；
   前記受信データのサイズを判定するステップ（４０７）と；
   判定された前記受信データの前記サイズに基づいて、前記状態を設定するステップ（４０８）と；
   をさらに含む、請求項１から４のいずれかに記載の方法。
6. 前記バッファ推定値がゼロに設定される場合に、推定される前記到着時間を前記スケジューリング要求の送信時間に設定し、設定された前記状態に従って前記バッファ推定値を１つの状態固有のフレームサイズの期待サイズに設定するステップ（４０９）、
   をさらに含む、請求項１から５のいずれかに記載の方法。
7. 前記方法が前記第１の先回りのバッファ推定の状態で実行される場合に、最後の期待到着時間の後の１フレーム間隔で、最後の受信フレームのサイズだけ前記バッファ推定値を増加させ、最近の推定される到着時間をその時点の時間に設定するステップ（４１０）、
   をさらに含む、請求項１から６のいずれかに記載の方法。
8. 限界値よりも小さいサービスデータユニット（ＳＤＵ）が前記端末（１２０）により受信される場合に、方法の前記状態は前記消極的な状態に設定され、そうでなければ、方法の前記状態は前記先回りのバッファ推定の状態に設定される、請求項１から７のいずれかに記載の方法。
9. 前記限界値は、無音挿入記述子（ＳＩＤ）のサイズ以上かつ通話フレームのサイズ以下の値に設定される、請求項８に記載の方法。
10. パディングのみを含む２つの連続するフレームが前記端末（１２０）から受信される場合に、方法の前記状態は前記消極的な状態に設定される、請求項１から９のいずれかに記載の方法。
11. 端末（１２０）から受信されるデータの量を推定する基地局（１１０）における構成（５００）であって、前記基地局（１１０）および前記端末（１２０）は、無線通信システム（１００）内に含まれ、前記端末（１２０）は、データを含むフレームをバッファリングするように構成されるバッファを備え、前記構成（５００）は：
    前記端末（１２０）により要求されるサービスを判定するように適合される判定部（５０１）と；
    判定された前記サービスのフレーム間隔に基づいて、前記端末（１２０）から受信されるデータの到着時間を推定するように適合される推定部（５０３）と；
    判定された前記サービスについての推定されるフレームサイズに基づいて、受信されるデータのサイズの推定値を含むバッファ推定値を設定するように適合される設定部（５０４）と；
    を備える、構成。

Images