JP2015524227A - Ｄｒｘを用いた流入制御及びスケジューリングのためのリソース予約のためのシステム及び方法 - Google Patents

Abstract

システム及び方法は、通信ネットワークにおける流入制御の実行を提供する。当該方法は、上記通信ネットワークへの受け入れについてのエンティティ又はサービスのためのリクエストを受信することと；リソースを計算することと、当該リソースを計算するステップは、上記通信ネットワーク内の現行のエンティティ及びサービスについての第１の将来リソース使用を推定すること、及び上記リクエスト内で受信された上記エンティティ又はサービスについての第２の将来リソース使用を推定すること、を含むことと；上記リソースを計算するステップに少なくとも部分的に基づいて、受信された上記リクエストの上記通信ネットワークへの受け入れを判定することと；受信された上記リクエストについて受け入れが許可される場合、上記リソースを計算するステップに少なくとも部分的に基づいて、上記第１及び第２の将来リソース使用を予約するために、区分可能な予約ウィンドウを使用することと、を含む。

Description

ここで開示される主題の実施形態は、一般に、通信システムに関し、より具体的には、通信システムにおける流入制御及びスケジューリングに関する。

過去数年の間、日々の通信においてモバイルの及び地上回線／有線のコンピューティングデバイスを使用することへの関心は増加してきた。デスクトップコンピュータ、ワークステーション及び他の有線コンピュータは、現在のところ、ユーザが例えば電子メール、ビデオ会議及びインスタントメッセージング（ＩＭ）を介して通信することを可能とする。例えば携帯電話、手持ち型コンピュータ及びＰＤＡ（personal digital assistants）などのモバイルデバイスもまた、ユーザが電子メール、ビデオ会議及びＩＭなどを介して通信することを可能とする。携帯電話は、従来は音声通信デバイスとして供されてきたが、技術的な進展を通じて、近年ではデータ、グラフィックなどを通信するために有効なデバイスであることが判明した。異なるプラットフォームをまたいだシームレスな通信についてのユーザの需要が増加するにつれ、無線及び地上回線の技術はより統一化された通信システムへと統合を続けており、より多くの用途が生み出され、より多くのサービス及びシステムの改善がもたらされている。さらに、それら通信システムは、通信システムの新たな世代又は部分的な世代へと進化することができる。

顧客の需要をサポートする中でデバイス、ノード及びネットワークの間で情報を伝達し及び／又はリクエストするために、多様なシステム及び方法が使用されてきた。ルータ及びゲートウェイといったネットワーキングアプリケーション及びコンポーネントの文脈では、ネットワーキングシステムは、年々増加する量のデータ帯域幅を処理している。固定の及びモバイルのネットワーク上のインターネットの人口の急激な増大に伴って、多くのネットワーキングシステムは、しばしば、システム自体のその時点の既存のケイパビリティへのいかなる悪影響をも最小化しつつ、より多くのデータを処理し、より多くの帯域幅を提供し、及びシステムへより多くの特徴を迅速に取り入れる必要がある。

改善された量／質のデータを伝達するための１つのそうした進化したネットワークは、高速パケットアクセス（ＨＳＰＡ）技術へと進化しつつある、既存の第３世代（３Ｇ）無線通信システムであるＵＭＴＳ（Universal Mobile Telephone System）に基づいている。また別の例は、ＵＭＴＳフレームワーク内の別のエアインタフェース技術の導入であり、例えばいわゆるＬＴＥ（Long Term Evolution）技術である。

サービス品質（ＱｏＳ：quality of service）及びリソース制御（共に、ユーザ体験及び有限の帯域幅内のリソースの管理の双方にとって重要である）に影響を与える、それら通信ネットワークにおいて使用される１つの特徴は、流入制御（admission control）である。流入制御は、一般には、ネットワークノードによるサービスリクエストの受け入れ（admission）として説明されることができる。例えば、ＬＴＥ通信システムでは、ｅＮｏｄｅＢ（ｅＮＢ）が、ｅＮＢを通じてネットワークと通信する多様なユーザ機器（ＵＥ）について流入制御サービスを実行する。

通信システムのより大きい視点で流入制御を考慮すると、流入制御は、エンドツーエンドのユーザ及びサービスの差別化を提供するＱｏＳフレームワークの有用な部分である。無線アクセスネットワークにおいて、無線リンクは、ユーザのモビリティ及びセルエッジでの無線条件などといった課題に起因して、キャパシティの制約を有する。ユーザ及びその関連付けられるサービスもまた、許容される遅延、許容されるパケットロスなどといった追加的な制約を有する。流入制御は、ユーザ及びその関連付けられるサービスについての所望のＱｏＳを獲得するための解決策と一体的である。

現行の流入制御の解決策は、典型的には、エンティティ又はサービスのリクエストの時点での、利用可能なリソースの最新のレベル又は静的な量に焦点を当てている。ユーザの量、利用可能なサービス、及びより多くの帯域幅を使用したいという要望の増大につれて、期待される将来のシステム要件の全てを充足することはより困難となるであろう。

従って、システム内のユーザにリソースを提供するためのシステム及び方法が望ましい。

例示的な実施形態は、通信ネットワークのための流入制御手続を説明する。ここで説明される、将来のリソース可用性を考慮する例示的な流入制御の実施形態を実行することにより、流入制御の改善をなすことができる。

例示的な実施形態によれば、通信ネットワークにおいて流入制御を実行するための方法があり、当該方法は、上記通信ネットワークへの受け入れについてのエンティティ又はサービスのためのリクエストを受信することと；リソースを計算することと、当該リソースを計算するステップは、上記通信ネットワーク内の現行のエンティティ及びサービスについての第１の将来リソース使用を推定すること、及び上記リクエスト内で受信された上記エンティティ又はサービスについての第２の将来リソース使用を推定すること、を含むことと；上記リソースを計算するステップに少なくとも部分的に基づいて、受信された上記リクエストの上記通信ネットワークへの受け入れを判定することと；受信された上記リクエストについて受け入れが許可される場合、上記リソースを計算するステップに少なくとも部分的に基づいて、上記第１及び第２の将来リソース使用を予約するために、区分可能な予約ウィンドウを使用することと、を含む。

他の例示的な実施形態によれば、流入制御を実行するための通信ノードがある。当該通信ノードは、上記通信ネットワークへの受け入れについてのエンティティ又はサービスのためのリクエストを受信するように構成される通信インタフェースと、流入制御機能及びスケジューラを動作させるように構成されるプロセッサと、を含み、上記流入制御機能は、リソースを計算し、上記通信ネットワーク内の現行のエンティティ及びサービスについての第１の将来リソース使用を推定し、上記リクエスト内で受信された上記エンティティ又はサービスについての第２の将来リソース使用を推定し、上記リソースの計算の結果に少なくとも部分的に基づいて、受信された上記リクエストの上記通信ネットワークへの受け入れを判定する、ように構成され、上記流入制御機能は、受信された上記リクエストについて受け入れが許可される場合、上記リソースの計算の結果に少なくとも部分的に基づいて、上記第１及び第２の将来リソース使用を予約するために、区分可能な予約ウィンドウを使用する、ように構成される。

添付図面は、例示的な実施形態を描いている。

例示的な実施形態に係るＬＴＥ（long term evolution）通信ネットワークを示している。 例示的な実施形態に係る予約ウィンドウを示している。 例示的な実施形態に係る保証ビットレート（ＧＢＲ）サービスのための流入制御方法を示している。 例示的な実施形態に係る非ＧＢＲサービスのための流入制御方法を示している。 例示的な実施形態に係るスケジューリングのためのフローチャートを示している。 例示的な実施形態に係る通信ノードを示している。 例示的な実施形態に係る方法のフローチャートを示している。 図８〜図１２は、ＵＥに関連付けられるＤＲＸパラメータが考慮される、流入制御の実施形態の多様な観点を示している。 図８〜図１２は、ＵＥに関連付けられるＤＲＸパラメータが考慮される、流入制御の実施形態の多様な観点を示している。 図８〜図１２は、ＵＥに関連付けられるＤＲＸパラメータが考慮される、流入制御の実施形態の多様な観点を示している。 図８〜図１２は、ＵＥに関連付けられるＤＲＸパラメータが考慮される、流入制御の実施形態の多様な観点を示している。 図８〜図１２は、ＵＥに関連付けられるＤＲＸパラメータが考慮される、流入制御の実施形態の多様な観点を示している。

例示的な実施形態の以下の詳細な説明は、添付図面を参照する。異なる図面における同一の参照番号は、同一の又は同様の要素を識別する。追加的に、図面は必ずしも実寸を描いてはいない。また、以下の詳細な説明は、本発明を限定しない。代わりに、本発明の範囲は、添付される特許請求の範囲により定義される。以下の実施形態は、簡明さのために、流入制御及びスケジューリングの文脈において、ＬＴＥ（Long Term Evolution）システムの用語及び構造を基準として議論される。しかしながら、ここで議論される実施形態は、ＬＴＥシステムに限定されず、例えばＷＣＤＭＡ（Wideband Code Division Multiple Access）、ＷｉＭａｘ（Worldwide Interoperability for Microwave Access ）、ＵＭＢ（Ultra Mobile Broadband）、ＧＳＭ（Global System for Mobile Communications）、ＷＬＡＮ（wireless local area network）及びＵＭＴＳ（Universal Mobile Telecommunication System）といった他の通信システム、並びに適用可能なそれらの関連するノードへ適用されてもよく、それらは、同様の流入制御機能及びスケジューリング機能のために使用される。

本明細書を通じて、「１つの実施形態」又は「一実施形態」との言及は、一実施形態との関わりにおいて説明される特定の特徴、構造又は特性が、開示された主題の少なくとも１つの実施形態に含まれることを意味する。よって、本明細書を通じた様々な場所での「１つの実施形態において」又は「一実施形態において」というフレーズの出現は、必ずしも同じ実施形態に言及するものではない。さらに、特定の特徴、構造又は特性は、１つ以上の実施形態において、どのような適当な手法で組み合わされてもよい。

例示的な実施形態によれば、流入制御システムにおいて、通信ネットワーク又はそのサブ部分（sub-portions）へエンティティ又はサービスが受け入れられる時間に先立って、リソースを予約することができる。これらサブ部分又は“システム”は、多様な通信システムのサブセットであることができ、例えばｅＮｏｄｅＢ（ｅＮＢ）、ゲートウェイ（ＧＷ）、ルータ、及びある程度の流入制御を実行する他のノードといった、多様な通信ノードによって、流入制御を実行することができる。通信ネットワークへエンティティ又はサービスを受け入れるか否かの決定は、将来に要すると推定されるリソースについてのリソースの可用性、予期されるサービスの寿命、及び（適用可能な場合）そのトラフィック特性に基づくことができる。現行のリソースレベルもまた、流入制御及びスケジューリングのために望ましいのであれば、考慮されることができる。例えば加入者若しくはＵＥといったエンティティ、及び／又は例えば加入者サービス、ＶｏＩＰ（voice over internet protocol）及びウェブブラウジングといったサービスのためにリソースを将来へ向けて予約する目的で、予約ウィンドウ（booking window）が使用可能である。これは、現在利用可能なシステムリソースがその時点では十分に無い場合であっても、エンティティ又はサービスが流入を許可されることを可能とすることができる。追加的に、所望のリソース使用量を時間にわたって分配することにより、サービスについてのビットレートを制限することができる。リソースとは、制御プレーン用のリソース、データパス用のリソースに加えて、メモリ、ストレージ、帯域幅などの他のシステムリソースを含み得る。

流入制御に関連付けられる例示的な実施形態をより詳細に説明する前に、図１を参照しながら、それら例示的な実施形態を実装可能な例示的なＬＴＥ通信ネットワーク２についてこれから説明する。まず、ＵＥ４は、ｅＮｏｄｅＢ（ｅＮＢ）６と通信関係にあり、ｅＮＢ６は、接続モビリティ制御、スケジューリング、流入制御及び無線リソース管理のための多様な制御機能を含む。ｅＮＢ６は、制御プレーンにおいて、モビリティ管理エンティティ（ＭＭＥ）８と通信する。ＭＭＥ８は、例えば、ｅＮＢ６へのページングメッセージの配信を管理することができ、ベアラアクティブ化／非アクティブ化処理にも関与する。追加的に、ＭＭＥ８は、ホーム加入者サーバ（ＨＳＳ）１０と通信関係にあり、ＨＳＳ１０は、加入者情報を含み、さらに、例えば特定のサービスに関連付けられる帯域幅といった特定のサービスに関連付けられる情報を含むデータベースである。

ｅＮＢ６は、ユーザプレーンにおいて（サービングゲートウェイ及び／又はパケットデータネットワーク（ＰＤＮ）ゲートウェイを表現し得る）ゲートウェイ１２（ＧＷ）とも通信関係にある。ＧＷ１２は、３ＧＰＰ内部のモビリティの機能に加えて、例えばＩＰ（Internet Protocol）マルチメディアサブシステム（ＩＭＳ）サービスといった事業者サービス１４へのアクセスを可能とすること、をサポートすることができる。追加的に、ＧＷ１２は、ＭＭＥ８と通信関係にある。例示的な実施形態によれば、ＧＷ１２は、ここで説明されるような流入制御ポリシーを、ｅＮＢ６とＧＷ１２との間のバックホール通信リンク１１上で実装することもできる。図１は例示的なＬＴＥネットワーク２の一部を示しているが、流入制御を実行するノード群を有する他の通信ネットワークもまたここで説明される例示的な実施形態のいくつか又は全てを実装可能であることが理解されるべきである。ここで説明される例示的な実施形態によって、複数のＵＥ４、複数のｅＮＢ６及び複数のＧＷ１２を使用し及び／又はサポートすることもできる。

例示的な実施形態によれば、通信ノードによる流入制御のサポートにおいて、エンティティ又はサービスに関連付けられる将来のリソースを予約するために、予約ウィンドウが使用され得る。ここで使用される“リソース”とは、例えば、システム内へ受け入れられ得る新たなサービス（あるいはサービス群）及び／又はエンティティ（あるいはエンティティ群）により影響を受ける通信ネットワークのサブセットといった、システム内の任意のリソースを含み得る。個々のリソースが別個の予約ウィンドウを有してもよく、複数のリソースが１つ以上の予約ウィンドウへと結合されてもよい。追加的に、リソースに関連付けられるベアラは、予約ウィンドウにより自動的に優先度付け（prioritize）され得る。

例示的な実施形態によれば、予約ウィンドウは、複数の属性を有し得る。予約ウィンドウは、時間長ｔの複数の時間スロットへと区分されることができ、ｔは設定可能な値であり得る。送信スロットは、当該送信スロットが継続する時間ピリオドにわたって、ユーザ及びユーザのサービスのためのトラフィック及び他の機能を処理するために要するリソースに関連付けられ得る。予約ウィンドウは、全ての将来の送信、送信スロット及びそれらの関連付けられるリソースを表現してもよい。この場合、予約ウィンドウは、無限であると見なされ得る。代替的に、予約ウィンドウは、設定可能な固定サイズのバッファで実装されてもよい。予約ウィンドウが固定サイズのバッファで実装される場合、当該バッファは、循環バッファと同様であってよく、無限の予約ウィンドウと同様のやり方で実行可能であり、例えば、当該バッファは、陳腐化した送信スロット又は解放済みの送信スロットを上書きする“ラップアラウンド（wrap around）”方式で動作し得る。

例示的な実施形態によれば、エンティティ又はサービスのために予約される送信スロットは、当該エンティティ又はサービスが終了する際に解放され得る。有限サイズのバッファについて、送信スロットは、予約ウィンドウサイズが許容する範囲内でのみ将来へと予約され得る。これら送信スロットは、エンティティ又はサービスのために予約されたままであってもよく、予約ウィンドウが時間にわたって反復するにつれて繰り返され又は再利用され得る。追加的に、エンティティ及びサービスを、それぞれの制約を充足し及び／又はサポートする手法で予約することができる。例えば、２０ｍｓという特定の遅延許容性を伴うＶｏＩＰ（Voice over IP）サービスを、遅延の制約が充足されることを保証するために、２０ｍｓ（又はそれ未満）だけ隔てられた送信スロット群と共に予約することができる。

例示的な実施形態に従って、図２に予約ウィンドウ１８が示されている。予約ウィンドウ１８は、Ｘ軸２０上の時刻と、Ｙ軸２２上のリソース利用率とを示している。予約ウィンドウは、例えば、送信スロットｔ０２４、ｔ１２６、ｔｎ２８へと区分され得る。送信スロットｔ０２４は現行の送信スロットを意味し、ｔｍ３０は送信スロットの単位での予約ウィンドウのサイズ、例えば送信スロットｍ個分、を意味する。予約ウィンドウ１８は、リソースの０〜１００％の予約のための通常予約セクション３２と、予約ウィンドウ１８を過予約（overbook）可能な過予約セクション３４とを示すこともできる。過予約は、送信スロットごとに生じ得る。追加的に、過予約は、例えば１つ以上の流入制御機能を実行する、例えばｅＮＢ６及び／又はＧＷ１２といったノードを担当するネットワーク事業者によって、その量が設定可能であり得る。但し、過予約の量を設定するために、例えば履歴データ、サービスの致命度（criticality）及び局所実験などといった、他のシステム、方法及び情報を使用することもできる。

例示的な実施形態に従って、図３に、保証ビットレート（ＧＢＲ）サービスのための流入制御に関連付けられるステップ群が示されている。まず、例えばリモートで若しくはローカルでサービスされるＵＥ４、又はリモートのアプリケーションサーバにより、流入制御機能３８を含むノードへ向けて、新たなＧＢＲサービスベアラ３６が送信される。流入制御機能３８は、リソース計算機能４０を含み、リソース計算機能４０は、（１）ステップ４２において、正味のペイロード及び送信インターバルを計算し、（２）ステップ４４において、ＵＥ４についての将来の無線条件を推定し、（３）ステップ４６において、サービス（又はエンティティ）について制御及びデータパスチャネルのために要する将来のリソースを推定する、というステップ群を実行可能である。リソース計算の完了後に、流入制御機能３８は、後により詳細に説明するように、ステップ４８において、サービスのについて適した送信スロットを予約するために、予約ウィンドウ１８を使用することができる。これは、例えば、ローカルＵＥからローカルＵＥへ、ローカルＵＥからリモートＵＥへ、ローカルサービスリクエストからリモートサービスリクエストへ、といった多様な用途のために実行可能である。

上述したように、例示的な実施形態に従って、図３は、ＧＢＲベアラを受け入れるための手続を示している。この例において、流入制御機能３８は、サービスベアラ（又はエンティティ）について将来に要するリソースを計算する。ＧＢＲベアラは最小の（又は保証される最小の）レートを有することから、予約スロットは、遅延の制約及びパケット間ジッタ要件に加えて、帯域幅要件、及びベアラのトラフィックの何らかの所望の他の特性を充足する送信インターバルを伴う反復パターンへと、固定化され得る。流入制御機能３８によって、サービスの優先度、サービス品質（ＱｏＳ）クラス、リソース利用率の現在の及び将来のレベル、並びにチャネル条件といった他の基準もまた考慮され得る。例えば、システムが一時的に過負荷である場合、例えば一日のピーク時間の期間中に、電子メール又はファイル転送プロトコル（ＦＴＰ）といったサービスは、初期遅延と共に受け入れられてもよく、これはそうした遅延によってサービス品質が有意に影響されないという前提の下になされる。この反復パターンは、図３において、送信スロットｔｎ５０、ｔ２ｎ５２及びｔ３ｎ５４によって示されているように理解されることができ、予約対象のサービスの反復的な性質が描かれている。

追加的に、例示的な実施形態によれば、流入制御機能３８によりＵＥ又はサービスが受け入れられるべきかを決定する際の考慮のために、ハード及びソフトのＱｏＳ制約を使用することができる。ハードＱｏＳ制約は、何らかのサービスについてサービスへの悪影響を回避するために充足されなければならず、例えば遅延、パケット間ジッタ及びエラー許容度（error tolerance）を含み得る。ソフトＱｏＳ制約は、サービスが許容し得るレベルの品質を有するために常に充足されなければならないわけではない制約である。例えば、流入制御機能３８は、ネットワーク輻輳の期間の間にサービスが飢餓状態となることを回避するために、非ＧＢＲサービスに、最小ビットレート又は最大遅延というソフトパラメータを追加することを選択してもよい。ＧＢＲサービスは、最大ビットレート（ＭＢＲ）であるソフト制約を有してもよい。

例示的な実施形態によれば、ＧＢＲベアラについて送信スロットを予約するために、以下の基準を使用することができる。まず、予約ウィンドウは、ＧＢＲベアラ要件を充足するために利用可能な十分なリソースを有するスロットを探索し得る。遅延及びジッタ制約を充足する固定的なインターバルで送信スロットは選択されることができ、例えば、送信時間インターバルは、遅延及び／又はジッタ以下である。送信スロットへの予約は、ベアラについてＱｏＳ制約を充足することのできる所望の確率を有するように行われ得る。

例示的な実施形態に従って、図４に、非ＧＢＲサービスのための流入制御に関連付けられるステップ群が示されている。まず、例えばリモートで若しくはローカルでサービスされるＵＥ４、又はリモートのアプリケーションサーバにより、流入制御機能３８を含む通信ノードへ向けて、新たな非ＧＢＲサービスベアラ５６が送信される。流入制御機能３８は、リソース計算機能４０を含み、リソース計算機能４０は、（１）ステップ５８において、（可能であれば）正味のペイロード並びに最小及び最大トラフィックレートを統合最大ビットレート（ＡＭＢＲ）に基づいて計算し、（２）ステップ４４において、ＵＥ４についての将来の無線条件を推定し、（３）ステップ４６において、サービス（又はエンティティ）について制御及びデータパスチャネルのために要する将来のリソースを推定する、というステップ群を実行可能である。ＡＭＢＲは、ＵＥ４についてその時点でアクティブな全ての非ＧＢＲサービスの平均ビットレートの許容される最大の合計であり、ＡＭＢＲは、非ＧＢＲサービスについてのトラフィックのポリシング及びシェイピングのために使用可能なＵＥ４についてのハード制約である。リソース計算の完了後に、流入制御機能３８は、後により詳細に説明するように、ステップ４８において、サービスについて適した送信スロットを予約するために、予約ウィンドウ１８を使用することができる。これは、例えば、ローカルＵＥからローカルＵＥへ、ローカルＵＥからリモートＵＥへ、ローカルサービスリクエストからリモートサービスリクエストへ、といった多様な用途のために実行可能である。

上述したように、例示的な実施形態に従って、図４は、非ＧＢＲベアラを受け入れるための手続を示している。この例において、流入制御機能３８は、サービスベアラ（又はエンティティ）について将来に要するリソースを計算する。非ＧＢＲベアラは最小の（又は保証される最小の）レートを有しないことから、予約スロットは、同様の送信インターバルの反復パターンへと固定化されなくてよい。但し、非ＧＢＲサービスが偶然に識別可能なＱｏＳ制約を有する場合、予約処理は、任意の他の所望のベアラのトラフィックの特性と共に、その制約を考慮に入れることを試みてもよい。追加的に、全てのサービスリクエストについて正味のペイロードを計算することは可能ではないかもしれない。例えば、サービスリクエストがウェブブラウジング用である場合、ユーザがどういったウェブブラウジングをし得るかを予め決定しそして関連する正味のペイロードを計算することは、困難か不可能であり得る。本例では、非ＧＢＲサービスについて予約される送信スロットが十分なリソースを有するように見出され、送信スロットｔａ６０、ｔｂ６２及びｔｃ６４によって識別されている。

例示的な実施形態によれば、非ＧＢＲベアラについて送信スロットを予約するために、以下の基準を使用することができる。まず、予約ウィンドウ１８は、利用可能な十分なリソースを有するスロットを探索し得る。送信スロットが予約される際、加入者のＡＭＢＲが、予約ウィンドウ内で超過されないようにチェックされる。非ＧＢＲベアラについて送信スロットを予約する際、非ＧＢＲベアラが飢餓状態にならないことを保証するために、最小ビットレートが使用されてもよい。当該最小レートは、加入者のＡＭＢＲのある割合、他のＱｏＳパラメータから推論される値、又は設定される定数であってもよい。

非ＧＢＲベアラについてどういったトラフィックレートを予約すべきかを決定するために、全体的なウィンドウ負荷をチェックすることができる。予約されるトラフィックレートは、図４のステップ５８において計算される最小レートと最大レートとの間になる。非ＧＢＲベアラが許容されるジッタ、遅延などといった制約を有する場合、予約ウィンドウは、制約が充足される確率が所望の通りに改善し、最適化され又は最大化されるようにセットアップされ得る。追加的に、非ＧＢＲベアラについて、ペイロードサイズ及び送信インターバルに関する決定を行うために十分な情報又はＱｏＳ制約が常には存在しないかもしれない。従って、本文脈において、非ＧＢＲベアラは、ＧＢＲベアラよりも柔軟であってよく、より多くを要求するＧＢＲサービスにより使用されない送信スロット（又は送信スロットの一部）を埋めるために使用されてもよい。

例示的な実施形態によれば、流入制御機能３８を含む通信ノードの一部であり得るスケジューラは、予約ウィンドウ内の情報を用いて、現行の送信時間インターバル（ＴＴＩ）、即ち現行の送信スロットにおける送信をスケジューリングし得る。スケジューラは、ＧＢＲサービスをスケジューリングし、続いて非ＧＢＲサービスをスケジューリングし得る。ベアラが最小レートといったような１つ以上の制約を充足しないリスクがある場合、非ＧＢＲベアラの優先度付けが考慮されてもよい。スケジューラは、利用可能であれば、現行のＴＴＩのスケジューリングのサポートにおいて予約ウィンドウからの以下の情報を少なくとも活用し得る：（１）送信のためにスケジューリングすべき加入者、（２）送信のためにスケジューリングすべき加入者についてのベアラ、（３）各ベアラについての正味のペイロード、即ち送信すべきビット群。

例示的な実施形態に従って、図５（ａ）及び図５（ｂ）のフローチャートに、ベアラをスケジューリングするための方法が示されている。まず、スケジューラは、ステップ６６において、予約ウィンドウ１８からの加入者／ベアラを選択し得る。そして、スケジューラは、ステップ６８において、ＵＥ４のその時点のチャネル条件に基づいて、例えば優先されるビットレート、変調符号化方式などのチャネルリソースを計算し得る。選択したベアラが送信すべき情報を有していなければ、スケジューラは、ステップ７０において次のサービスと共に処理を進め得る。選択したベアラが送信すべき十分な情報を有していなければ、スケジューラは、ステップ７２において、有している利用可能なものを送信し、次のサービスと共に処理を進め得る。選択したベアラが予約ウィンドウ１８により特定されるよりも多くの送信すべき情報を有していれば、スケジューラは、ボックス７４に示されているように、ステップ７４Ａ又はステップ７４Ｂのうちの１つと、適切ならばステップ７４Ｃとを実行し得る。

ＧＢＲベアラについて、選択したベアラが予約ウィンドウ１８により特定されるよりも多くの送信すべき情報を有していれば、スケジューラは、ステップ７４Ａにおいて、予約ウィンドウ１８により示されるペイロードサイズを送信し得る。但し、特定のＴＴＩについてスケジューリング手続の最後にスペースが残されている場合にスケジューリングすべき潜在的な候補であるベアラを含むオーバフローリストへ、当該ベアラが追加されてもよい。非ＧＢＲベアラについては、まず、ステップ７４Ｂにおいて、予約ウィンドウにより示される送信ペイロードサイズのみが送信され得る。但し、特定のＴＴＩについてスケジューリング手続の最後にスペースが残されている場合にスケジューリングすべきベアラの候補のリストへ、当該ベアラが追加されてもよい。スケジューラにより維持され得るオーバフローリストは、どのベアラがそのＱｏＳ制約を充足しない場合により高いリスクを有するかなどといった多様な基準に基づいてステップ７４Ｃにおいて優先度付けされるエントリを含む。追加的に、オーバフローリストを優先度付けするために、例えばチャネル条件、サービス又はベアラに関連付けられる優先度、サービスのタイプ、予約ウィンドウ１８において推定されるビットレートをサービスが上回るか若しくは下回るか、及び／又はパケットを送信するためのサービスの待ち時間といった他のパラメータが使用されてもよい。

上述したような初期の送信の実行の後、ベアラの全てのスケジューリング後に依然としてリソースが残されていれば、スケジューラは、ステップ７６において、ＴＴＩを埋めるためにオーバフローリストを使用し得る。ステップ７６の後に依然として利用可能なリソースが存在する場合、スケジューラは、ステップ７８において、より多くのベアラをスケジューリングするために、次の送信スロットからのベアラを用いる、及び／又はより高い優先度のサービスが続きより低い優先度のサービスがさらに続き得る再送リストを用いる、といったような様々な戦略を使用し得る。例示的な実施形態によれば、予約ウィンドウ１８が過度に不正確であるとスケジューラが判定した場合、例えば、ＵＥ４ごとの平均的な無線条件、及びＵＥ４又はベアラごとの平均的な過去のペイロード／キューサイズに基づいて、将来の予約スロットについての調整が行われ得る。図５（ａ）及び図５（ｂ）に関連付けられる上述した例は、スケジューリングの目的でのリソース予約ウィンドウ１８の活用のための１つの方法であるが、代替的に他の方法も使用されてよい。

上述した例示的な実施形態を用いて、ＶｏＩＰサービス用のＧＢＲベアラについての正味ペイロード推定についての、純粋に説明のための例をここで説明する。下記の表１に、ＶｏＩＰサービスに関連付けられる初期のパラメータが示されている。

上記パラメータ及びその値を判定するために、通信ネットワーク内の多様な場所から情報を取得することができる。例えば、いくつかのケースでは、あるサービスについて、特定のコーデックがサービスに関連付けられる場合に、上記情報は、ＨＳＳ１０から取得され又は他の場所でルックアップされることができる。追加的に、ネットワーク事業者から他の情報が取得され得るはずである。

ＧＢＲベアラについてのこの正味ペイロード推定を続けると、推定される平均ペイロードは、提供されるサービス情報（６４ｋｂｐｓ）から計算されることができ、例えば多様なヘッダといった追加され得る他のデータからの追加的なペイロードについての推定値が加えられ、下記の式（１）のように示される。
Ｐ１＝６９ ｋｂｐｓ （１）
送信ごとに推定されるペイロードは、式（２）に示されている。
Ｐ２＝（ｒ／１０００）×ｄ （２）
＝（６４ｋｂｐｓ／１０００ｍｓ）×２０ｍｓ
＝毎送信１２８０ビット
ここで使用した推定は、以下のものも含む：（１）パケットは２０ｍｓごとに送信される、９２）送信されるペイロードは１２８０ビットである。

例示的な実施形態によれば、いくつかのケースでは、非ＧＢＲサービスについてリソースを推定することができる。例えば、加入者の多様な過去の及び現在の振る舞いを用いて、ペイロードサイズ、送信インターバル、（前に列挙した２つのパラメータにより示唆され得る）トラフィックレート及び呼の持続期間などといったパラメータを推定することができる。これらパラメータは、新たなベアラの受け入れの期間中のより正確なリソースの予約を可能とし得る。加入者の統計から推論され使用され得る他のパラメータは、限定ではないものの：デバイスのケイパビリティ、平均チャネル条件、モビリティパターン、一日の様々な時刻における振る舞い、及び／又は一月の様々な日付における振る舞いなど、を含む。

例示的な実施形態によれば、ＵＥ４は、それぞれのｅＮＢ６へ、チャネル条件を記述した周期的なレポートを送信し得る。それらチャネル条件レポートをある時間ピリオドにわたって用いて、ＵＥ４についての平均的なチャネル条件を計算することができる。そして、それら値は、ＵＥ４のために予約された任意の又は全ての送信について予約ウィンドウ１８の負荷を更新するために使用され得る。ＵＥ４は、ＵＥ４により送信すべきデータが存在することを示すバッファステータス情報をもｅＮＢ６へ送信し得る。そして、この情報は、送信が望ましく及び／又は必要とされるかを決定するために、予約ウィンドウ１８内の情報と組み合わされ得る。ｅＮＢ６内のスケジューラは、予約されているものとイベント又は加入者サービスにより要するリソースとの間の不均衡が存在することを見出し得る。不均衡がある時間ピリオドにわたって過剰に大きい場合、将来の予約スロットについての調整が行われ得る。

通信ノード間の流入制御について例示的な実施形態を説明した。これら例示的な実施形態は、アップリンク及びダウンリンクの双方において、説明した通りに生じ得る。次の加入者サービスを選択するために、何らかのトラフィック特性又は全体的なシステム負荷を無視し得る複雑なスケジューリングアルゴリズムを用いることのない予約ウィンドウ１８にスケジューラが依拠し得ることから、例示的な実施形態は、スケジューリング手続の簡略化を提供することができる。ベアラごと及び加入者ごとの自動的なトラフィックシェイピング及びトラフィックポリシングが実行され得る。予約ウィンドウ１８は、あるタイムスロットにおいてあるレートでのみベアラが送信を行うように制限し得るため、ベアラ及びユーザレートのシェイピング及びポリシングは“フリー”となり、例えば過剰なトラフィックが到来した際に予約されたリソースが全て利用されていれば、パケットの破棄が実装され得る。これは、エンドユーザのより高い満足をも潜在的にもたらす一方で、ユーザ間のリソースのよりバランスのとれた使用をもたらすことができる。

上述した例示的な実施形態は、通信システム内のノードのための流入制御及びスケジューリングを提供する。例えばｅＮＢ６、ＧＷ１２、ＭＭＥ８（制御プレーンのスケジューリング用）、及び他のＩＰルータ（又はノード）といった、流入制御及び／又はスケジューリングを実行可能な例示的な通信ノード８０について、図６を基準としてこれより説明する。通信ノード８０は、流入制御機能３８及びスケジューラ８４を含み得るプロセッサ８２（又は複数のプロセッサコア）と、メモリ８６と、１つ以上のセカンダリストレージデバイス８８と、インタフェースユニット９０とを含み得る。インタフェースユニット９０は、通信ノード８０と、通信システムと共に通信する他のノード／デバイスとの間の通信を遂行する。関連付けられる流入制御機能３８及びスケジューラ８４を伴うプロセッサ８２は、ここで説明した流入制御機能及びスケジューリング機能に関して上述した例示的な実施形態を遂行する命令を実行し得る。メモリ８６は、流入制御及びスケジューリングに関連付けられる情報であって、コーデック情報、チャネル条件情報、優先度基準及びリソース計算結果を所望の通りに含む情報を記憶するために使用され得る。よって、通信ノード８０は、例えばｅＮＢ６、ＭＭＥ８、ＧＷ１２、及び多様なルータといった、流入制御及び／又はスケジューリングを実行する任意のノードについて、ここで説明した例示的な実施形態を実行することができる。

図７に、通信ネットワークにおいて流入制御を実行するための例示的な方法が描かれている。そこでは、ステップ９２において、通信ネットワークへの受け入れについてのエンティティ又はサービスのためのリクエストが受信され、ステップ９４において、リソースが計算され、当該リソースを計算するステップは、ステップ９６において、通信ネットワーク内の現行のエンティティ及びサービスについての第１の将来リソース使用を推定することと、ステップ９８において、上記リクエスト内で受信されたエンティティ又はサービスについての第２の将来リソース使用を推定することと、を含み、ステップ１００において、リソースを計算する上記ステップに少なくとも部分的に基づいて、受信されたリクエストの上記通信ネットワークへの受け入れが判定され、ステップ１０２において、受信されたリクエストについて受け入れが許可される場合、上記リソースを計算するステップに少なくとも部分的に基づいて、第１及び第２の将来リソース使用を予約するために、区分可能な予約ウィンドウが使用される。

［リソース予約ウィンドウ及びＤＲＸ］
前述の実施形態は、スケジューラが例えば完全なサービスリストを縦覧する（traverse）ことにより特定のＴＴＩについて考慮するための候補リストを選択する。しかしながら、サービスリストが例えば数千ものサービスが存在するように巨大である場合、選択処理は、完全なリストを考慮するための時間を有しないかもしれない。この場合、サービスリストはサブセクション（サブリスト）へとブレークダウンされることができ、ＴＴＩごとに１つのサブセクションが考慮される。しかしながら、このアプローチは、サービスのいくつかのＱｏＳ制約に副作用を及ぼす。例えば、低優先度のベストエフォート型のサービスのみを伴うサブリストが、高優先度のＧＢＲサービスのみを含むサブリストと同様の処理において同等に考慮される。サブリストは独立的であり異なるＴＴＩにおいて調査されることから、この例におけるベストエフォート型のサービスとＧＢＲサービスとは、同等に扱われる。本問題を解決する１つの手法は、異なる優先度のサービスが混在するような手法でサブリストをソートすることである。

以下に説明する実施形態によれば、上述したリソース予約ウィンドウが、例えばサービスのＱｏＳ特性及び制約、サービスを所有するＵＥの不連続受信（ＤＲＸ）サイクル、サービスの様々なタイプについて望ましいパケットバンドリングのレベル、送信ごと及びサービスごとに推奨される最大パケットサイズ、並びに／又は遅延バジェットに基づいてＴＴＩごとのサブリストを均衡化（balance）するために使用される。これら実施形態は、例えばＵＥのＤＲＸ構成及びＶｏＩＰパケットバンドリングの双方を、遅延ベーススケジューリングと共に考慮することができる。よって、前述の実施形態がとりわけサービスのＱｏＳ特性、サービスのＱｏＳ制約及びシステム内のリソース可用性を用いてサービスのために将来へ向けてリソースを予約する一方で、以下の実施形態は、サービスの受け入れの決定の一部として、ＵＥのＤＲＸパラメータ、ＶｏＩＰパケットバウンディングバンドリング及び／又は遅延ベーススケジューリングを追加する。結果として、受け入れられるサービスは、例えば以下に基づいて、将来のために予約されたリソースを有する：
１．ＵＥのＤＲＸアクティブ及び非アクティブサイクル
２．保証ビットレート（ＧＢＲ）及び統合最大ビットレート（ＡＭＢＲ）などといったＱｏＳ特性
３．最大遅延、許容されるジッタなどといったＱｏＳ制約
４．将来のスロットについての異なる複数の時点でのシステムリソースレベル
５．パケットバンドリング及び遅延バジェットといった機能性を可能とするパラメータの構成

また、上の実施形態において説明したように、当該実施形態は、サービスのＱｏＳ特性及び制約を用いて将来に向けてサービスを予めスケジューリングする（pre-schedule）流入制御モジュールをも提供する。そこで、リソース予約ウィンドウは複数の時間スロットへと分割され、例えば１つのスロットが、図８に示したように、ＬＴＥ標準に従って動作する無線通信システムにおいて使用される１ｍｓのＴＴＩへとマッピングされ得る。よって、リソース予約／スケジューリングは、図９のフロー図において概略的に示されているように、ＤＲＸを考慮に入れることができる。そこでは、例えばＬＴＥ送信時間（ＴＴＩ）スロットへ適合する１ｍｓ時間スロットを有するリソース予約ウィンドウが、ステップ９００により表現されるように、ＤＲＸオフセット用の３ＧＰＰの定式、即ちオフセット＝（ＳＦＮ×１０）＋サブフレームを用いて、ノードからＵＥへ向けて送信されるフレーム及びサブフレームへと同期される。次に、ステップ９０２により表現されるように、ＵＥへ提供されるべき潜在的な新たなサービスについて、リソーススロットが選択される。ステップ９０２は、例えば、ＵＥのＤＲＸサイクルに適合し且つサービスのＱｏＳ要件及びＱｏＳ制約を充足するリソースウィンドウの範囲を計算することにより、又はリソースウィンドウ内の最良のリソーススロットを選択しＵＥのＤＲＸパラメータを調整することにより実行され得る。次に、ステップ９０４において、ＤＲＸパラメータが変更された場合には新たなＤＲＸパラメータがＵＥへシグナリングされ、ステップ９０２におけるリソーススロットの選択に基づいて、ＵＥへ向けて新たなサービスの許可又は拒否のいずれかが行われる。この流入制御のための概略的な方法は、以下により詳細に説明されるであろう。

まず、３ＧＰＰ標準において実装される通りのＤＲＸの簡潔な議論が、文脈のためにここに提供される。３ＧＰＰ標準は、ＵＥが電力を節約することを可能とする手法として、ＤＲＸの機能性を定義している。ＵＥは、アクティブピリオド及び非アクティブ（電力節約）ピリオドを含むＤＲＸサイクルで構成される。ＲＲＣレイヤは、サービス中の又はサービスされようとしている各ＵＥについてＤＲＸパラメータがとる値を構成する。それらＤＲＸパラメータはＵＥへシグナリングされ、それにより、ｅＮｏｄｅＢ及びそこにアタッチしているＵＥは、各ＵＥがアクティブ又は非アクティブであるインターバルの観点で同期する。興味のある読者のために、ＤＲＸの機能性に関連付けられるより多くの情報を“３ＧＰＰ ＴＳ３６．３２１”として知られる３ＧＰＰ標準において見出すことができる。

ＤＲＸの機能性は、２つのＵＥステートにおいてサポートされる。ＲＲＣ＿ＩＤＬＥステート及びＲＲＣ＿ＣＯＮＮＥＣＴＥＤである。この実施形態は、ＵＥがＲＲＣ＿ＣＯＮＮＥＣＴＥＤステートにあるケース、及びより具体的にはＲＲＣ＿ＣＯＮＮＥＣＴＥＤステートの２つのサブケースに関連付けられる。第１のサブケースは、ＲＲＣレイヤがＤＲＸパラメータを構成し、それらパラメータがサービスを受け入れ及び将来のＴＴＩにおけるリソースを割り当てる基準の一部として考慮される場合である。第２のサブケースは、リソースの可用性及び割り当てに基づいてＲＲＣレイヤにおいて構成されたＤＲＸパラメータを動的に修正することに関与する。

３ＧＰＰにおいて定義された通りのＤＲＸ技法は、特定のエンドユーザの１つ以上のサービスにフィットするためにＵＥごとに構成可能な複数の異なるサイクル及びタイマからなり、それらは図１０に示されている。以下のパラメータは、これら実施形態に係る流入制御のために使用されるべき、リソースを予約する際に考慮されることになるＤＲＸパターンを定義する。
・ロングＤＲＸサイクル（longDRX-Cycle）：on-durationタイマにより定義される、アクティブ時間の周期的な繰り返しであって、あり得る非アクティビティのピリオドが後へ続く。このパラメータは、ＵＥがロングＤＲＸサイクルに従う場合に適用される。
・ショートＤＲＸサイクル（shortDRX-Cycle，オプション）：on-durationタイマにより定義される、アクティブ時間の周期的な繰り返しであって、あり得る非アクティビティのピリオドが後へ続く。このパラメータは、ＵＥがショートＤＲＸサイクルに従う場合に適用される。
・ＤＲＸショートサイクルタイマ（drxShortCycleTimer，オプション）：ＤＲＸ非アクティビティタイマが失効した後にＵＥがショートＤＲＸサイクルに従うものとされる連続するサブフレームの数である。

多様な実施形態が、リソース制御及びサービス受入れのためにＵＥに関連付けられるＤＲＸサイクル情報を考慮することができる。第１の実施形態によれば、リソース制御モジュールは、３ＧＰＰ ＴＳ３６．３２１において定義されているアルゴリズムを用いて将来の特定のスロットについてＵＥがアクティブサイクル中か非アクティブサイクル中かを決定することにより、リソースの割り当てをＵＥのＤＲＸサイクルに適合させ、次のようにサービス受入れの決定をすることができる。
１．リソースウィンドウ内のスロットへ３ＧＰＰ ＴＳ３６．３２１において定義されているアルゴリズムを適用することにより、ＵＥのアクティブサイクルに適合する将来のスロットを選択。
２．上の１において選択したスロットの範囲内でサービスにより適したスロットを予約。サービスのＱｏＳ制約が高い確度で充足されるべきである。
３．選択されたリソースが不適当である場合、サービスへの流入が拒否される。
この実施形態を、例えば図１１に示したように可視化することができ、これは図３の修正バージョンであって、図３の実施形態と共通の上述したエレメントを参照するために同じ参照番号が使用されている。図示したように、本実施形態は、ブロック１１００におけるＤＲＸパラメータの考慮を追加しており、それは上述したやり方での正味のペイロード及び送信インターバル４２の計算の一部として使用され得る。

他の実施形態によれば、ＵＥに関連付けられるＤＲＸ情報は、当該ＵＥを許可／拒否するためにリソース制御モジュールにより考慮される単一のサービスについて利用可能なリソースを適合させることにより、考慮に入れられ得る。この処理は、次のように実行され得る：
１．サービスのＱｏＳ要件及びサービスの制約を充足するリソーススロットを選択、
２．選択されたリソーススロットに適合するようにＵＥについてのＤＲＸサイクルを調整、
３．新たなＤＲＸパラメータをＵＥへシグナリング。

また別の例示的な実施形態によれば、前の実施形態を、特定のＵＥへの複数のサービスを同時に許可／拒否することをリソース制御モジュールが考慮しているケースを扱うように拡張することができ、それはＵＥにとって利用可能なそれらリソースを当該複数のサービスへと次のように適合させることにより行われ得る。
１．サービスのＱｏＳ要件及びサービスの制約を充足するリソーススロットを選択、
２．１におけるスロットのリストから、ＵＥのアクティブＤＲＸサイクルの範囲内のスロットの選択を試行
３．依然としていくつかのリソーススロットがアクティブＵＥサイクルの外側に出る場合、他のＵＥの既存のサービスを可能な限り近くなるように調整
４．全てのＵＥサービスのために選択されたリソーススロットに適合するように、ＵＥについてのＤＲＸサイクルを調整、
５．新たなＤＲＸパラメータをＵＥへシグナリング。

直近の２つの実施形態を、例えば図１２に示したように可視化することができ、これは図３の修正バージョンであって、図３の実施形態と共通の上述したエレメントを参照するために同じ参照番号が使用されている。図示したように、本実施形態は、ブロック１２００におけるＤＲＸパラメータの考慮を追加しており、それは上述したやり方での正味のペイロード及び送信インターバル４２の計算の一部として使用され得る。追加的に、新たなサービスの許可を実装するために本処理の一部としてＤＲＸパラメータの１つ以上が修正され得るため、ブロック１２０２により示したように、ＤＲＸパラメータが再計算され又は調整されて、ＵＥへとシグナリングされ得る。

上述した例示的な実施形態は、あらゆる観点で、本発明の限定よりもむしろ例示であることを意図している。よって、本発明について、ここに含まれる説明から当業者により導かれ得る詳細な実装における多くのバリエーションが可能である。そうした全てのバリエーション及び修正は、以下の特許請求の範囲により定義される通りの本発明の範囲及び思想に含まれるものと見なされる。本出願の説明において使用されたいかなるエレメント、動作、及び命令も、そのような明示的な説明の無い限り、本発明にとって必須又は不可欠であると解釈されるべきでない。また、ここで使用されるところによれば、冠詞の“ａ”は、１つ以上の項目を含むものと意図される。

この書面での説明は、開示される主題を当業者が実践することを可能とするためにその例を使用しており、それは何らかのデバイス又はシステムを生成し使用すること、及び任意の取り入れられる方法を実行することを含む。その主題の特許可能な範囲は、特許請求の範囲により定義され、当業者にとって思い浮かぶ他の例を含み得る。そうした他の例は、請求項の範囲内に含まれるものと意図される。

Claims (26)

1. 通信ネットワーク内で流入制御を実行するための方法であって、
   通信ノードにおいて、前記通信ネットワークへの受け入れについてのエンティティ又はサービスのためのリクエストを受信することと、
   リソースを計算することと、当該リソースを計算するステップは、
   前記通信ネットワーク内の現行のエンティティ及びサービスについての第１の将来リソース使用を推定することと、前記サービスは、サービスの複数のサブリストへとブレークダウン可能であることと、
   前記リクエスト内で受信された前記エンティティ又はサービスについての第２の将来リソース使用を推定することと、
   を含むことと、
   前記リソースを計算するステップに少なくとも部分的に基づいて、受信された前記リクエストの前記通信ネットワークへの受け入れを判定することと、
   受信された前記リクエストについて受け入れが許可される場合、前記リソースを計算するステップに少なくとも部分的に基づいて、前記第１及び第２の将来リソース使用を予約するために、区分可能な予約ウィンドウを使用することと、
   前記第１及び第２の将来リソースを、前記区分可能な予約ウィンドウ内の複数の遷移時間インターバルスロットへとスケジューリングすることと、
   を含む方法。
2. 前記通信ネットワークへの受け入れについてのエンティティ又はサービスのための前記リクエストは、サービスのリストについてのリクエストであり、サービスの前記リストは、複数のサブリストへと分割されて１つのサブリストが各送信時間インターバル（ＴＴＩ）について考慮される、請求項１の方法。
3. 異なる優先度のサービスが前記サブリスト内に混在するように、ＴＴＩごとの前記サブリストを均衡化すること、をさらに含む、請求項２の方法。
4. 受け入れられる各サブリストは、当該サブリスト内の各ＵＥのアクティブ及び非アクティブサイクル、当該サブリスト内の各サービスのサービス品質（ＱｏＳ）特性、当該サブリスト内の各サービスのＱｏＳ制約、並びに将来スロットについての異なる複数の時点でのリソース可用性、のうちの少なくとも１つに基づいて、前記区分可能な予約ウィンドウを用いてスケジューリングされる、請求項２の方法。
5. ユーザ機器（ＵＥ）へ送信されるフレーム及びサブフレームへ前記区分可能な予約ウィンドウを同期させることと、
   不連続受信（ＤＲＸ）パラメータを前記ＵＥへ送信することと、
   をさらに含む、請求項１の方法。
6. ユーザ機器（ＵＥ）から受信されるフレーム及びサブフレームへ前記区分可能な予約ウィンドウを同期させることと、
   不連続受信（ＤＲＸ）パラメータを前記ＵＥへ送信することと、
   をさらに含む、請求項１の方法。
7. 通信ネットワークにおいて流入制御を実行するように構成される通信ノードであって、前記通信ノードは、
   前記通信ネットワークへの受け入れについてのエンティティ又はサービスのためのリクエストを受信するように構成される通信インタフェースと、
   流入制御機能及びスケジューラを動作させるように構成されるプロセッサと、
   を備え、
   前記流入制御機能は、リソースを計算し、前記通信ネットワーク内の現行のエンティティ及びサービスについての第１の将来リソース使用を推定し、前記リクエスト内で受信された前記エンティティ又はサービスについての第２の将来リソース使用を推定し、前記リソースの計算の結果に少なくとも部分的に基づいて、受信された前記リクエストの前記通信ネットワークへの受け入れを判定する、ように構成され、前記サービスは、サービスの複数のサブリストへとブレークダウン可能であり、前記流入制御機能は、受信された前記リクエストについて受け入れが許可される場合、前記リソースの計算の結果に少なくとも部分的に基づいて、前記第１及び第２の将来リソース使用を予約するために、区分可能な予約ウィンドウを使用する、ように構成され、
   前記スケジューラは、前記第１及び第２の将来リソースを、前記区分可能な予約ウィンドウ内の複数の遷移時間インターバルスロットへとスケジューリングする、ように構成される、
   通信ノード。
8. 前記通信ネットワークへの受け入れについてのエンティティ又はサービスのための前記リクエストは、サービスのリストについてのリクエストであり、サービスの前記リストは、複数のサブリストへと分割されて１つのサブリストが各送信時間インターバル（ＴＴＩ）について考慮される、請求項１の通信ノード。
9. 異なる優先度のサービスが前記サブリスト内に混在するように、ＴＴＩごとの前記サブリストを均衡化すること、をさらに含む、請求項８の通信ノード。
10. 受け入れられる各サブリストは、当該サブリスト内の各ＵＥのアクティブ及び非アクティブサイクル、当該サブリスト内の各サービスのサービス品質（ＱｏＳ）特性、当該サブリスト内の各サービスのＱｏＳ制約、並びに将来スロットについての異なる複数の時点でのリソース可用性、のうちの少なくとも１つに基づいて、前記区分可能な予約ウィンドウを用いてスケジューリングされる、請求項８の通信ノード。
11. 前記プロセッサは、ユーザ機器（ＵＥ）へ送信されるフレーム及びサブフレームへ前記区分可能な予約ウィンドウを同期させるように構成されることと、
    前記通信インタフェースは、不連続受信（ＤＲＸ）パラメータを前記ＵＥへ送信するように構成されることと、
    をさらに含む、請求項７の通信ノード。
12. 前記プロセッサは、ユーザ機器（ＵＥ）から受信されるフレーム及びサブフレームへ前記区分可能な予約ウィンドウを同期させるように構成されることと、
    前記通信インタフェースは、不連続受信（ＤＲＸ）パラメータを前記ＵＥへ送信するように構成されることと、
    をさらに含む、請求項７の通信ノード。
13. 通信ネットワーク内で、受け入れのためのサービスの候補リストを選択し、及び複数の時間スロットを含む区分可能なリソース予約ウィンドウへスケジューリングするための方法であって、
    前記候補リストを複数の候補サブリストへと分割することと、前記複数の時間スロット内の異なる時間スロットについて各サブリストが考慮されることと、
    前記サービスに関連付けられる複数のユーザ機器（ＵＥ）の不連続受信（ＤＲＸ）サイクル、並びに前記サービス品質（ＱｏＳ）特性及び前記サービスの制約と共に、前記サブリスト内のサービスの各タイプについて望まれるパケットバンドリングのレベル、サービスごと及び送信ごとに推奨される最大パケットサイズ、並びに遅延バジェット、のうちの少なくとも１つ、に従って前記サブリストを均衡化することと、
    を含む方法。
14. 受け入れられる各サブリストは、当該サブリスト内の各ＵＥのアクティブ及び非アクティブサイクル、当該サブリスト内の各サービスの前記ＱｏＳ特性、当該サブリスト内の各サービスのＱｏＳ制約、並びに将来スロットについての異なる複数の時点でのリソース可用性、のうちの少なくとも１つに基づいて、前記区分可能な予約ウィンドウを用いてスケジューリングされる、請求項１３の方法。
15. 通信ネットワーク内で、受け入れのためのサービスの候補リストを選択し、及び複数の時間スロットを含む区分可能なリソース予約ウィンドウへスケジューリングするように構成される通信ノードであって、
    前記候補リストを複数の候補サブリストへと分割するように構成されるプロセッサ、を備え、前記複数の時間スロット内の異なる時間スロットについて各サブリストが考慮され、
    前記プロセッサは、前記サービスに関連付けられる複数のユーザ機器（ＵＥ）の不連続受信（ＤＲＸ）サイクル、並びに前記サービス品質（ＱｏＳ）特性及び前記サービスの制約と共に、前記サブリスト内のサービスの各タイプについて望まれるパケットバンドリングのレベル、サービスごと及び送信ごとに推奨される最大パケットサイズ、並びに遅延バジェット、のうちの少なくとも１つ、に従って前記サブリストを均衡化する、ように構成される、
    通信ノード。
16. 受け入れられる各サブリストは、当該サブリスト内の各ＵＥのアクティブ及び非アクティブサイクル、当該サブリスト内の各サービスの前記ＱｏＳ特性、当該サブリスト内の各サービスのＱｏＳ制約、並びに将来スロットについての異なる複数の時点でのリソース可用性、のうちの少なくとも１つに基づいて、前記区分可能な予約ウィンドウを用いてスケジューリングされる、請求項１５の通信ノード。
17. 通信ネットワークにおいてリソース予約を実行するための方法であって、
    ユーザ機器（ＵＥ）に関連付けられるフレーム及びサブフレームへリソース予約ウィンドウを同期させることと、
    前記ＵＥについて潜在的な新たなサービスのためのリソーススロットを選択することと、
    不連続受信（ＤＲＸ）パラメータを前記ＵＥへ送信することと、
    を含む方法。
18. 前記ＵＥについて潜在的な新たなサービスのためのリソーススロットを選択する前記ステップは、
    前記ＵＥのＤＲＸサイクルに適合し、前記新たなサービスのサービス品質（ＱｏＳ）要件及びＱｏＳ制約の双方をも充足する前記リソース予約ウィンドウの範囲を計算すること、
    をさらに含む、請求項１７の方法。
19. 前記ＵＥについて潜在的な新たなサービスのためのリソーススロットを選択する前記ステップは、
    前記リソース予約ウィンドウ内の最適なリソーススロットを選択することと、
    前記リソース予約ウィンドウ内の最適なリソーススロットを選択する前記ステップに基づいて、前記ＤＲＸパラメータを調整することと、
    をさらに含む、請求項１７の方法。
20. 前記ユーザ機器（ＵＥ）に関連付けられるフレーム及びサブフレームへリソース予約ウィンドウを同期させる前記ステップは、前記リソース予約ウィンドウを、前記ＵＥへ送信されるフレーム及びサブフレームへ同期させる、請求項１７の方法。
21. 前記ユーザ機器（ＵＥ）に関連付けられるフレーム及びサブフレームへリソース予約ウィンドウを同期させる前記ステップは、前記リソース予約ウィンドウを、前記ＵＥから受信されるフレーム及びサブフレームへ同期させる、請求項１７の方法。
22. 通信ネットワークにおいてリソース予約を実行するように構成される通信ノードであって、
    ユーザ機器（ＵＥ）に関連付けられるフレーム及びサブフレームへリソース予約ウィンドウを同期させるように構成されるプロセッサ、を備え、
    前記プロセッサは、前記ＵＥについて潜在的な新たなサービスのためのリソーススロットを選択する、ように構成され、
    不連続受信（ＤＲＸ）パラメータを前記ＵＥへ送信するように構成される通信インタフェース、を備える、
    通信ノード。
23. 前記ＵＥについて潜在的な新たなサービスのためのリソーススロットを選択することは、
    前記ＵＥのＤＲＸサイクルに適合し、前記新たなサービスのサービス品質（ＱｏＳ）要件及びＱｏＳ制約の双方をも充足する前記リソース予約ウィンドウの範囲を計算するように、前記プロセッサが構成されること、
    をさらに含む、請求項２２の通信ノード。
24. 前記ＵＥについて潜在的な新たなサービスのためのリソーススロットを選択することは、
    前記リソース予約ウィンドウ内の最適なリソーススロットを選択するように、前記プロセッサが構成されることと、
    前記リソース予約ウィンドウ内の最適なリソーススロットを選択する前記ステップに基づいて、前記ＤＲＸパラメータを調整するように、前記プロセッサが構成されることと、
    をさらに含む、請求項２２の通信ノード。
25. 前記ユーザ機器（ＵＥ）に関連付けられるフレーム及びサブフレームへリソース予約ウィンドウを同期させることは、前記リソース予約ウィンドウを、前記ＵＥへ送信されるフレーム及びサブフレームへ同期させる、請求項２２の通信ノード。
26. 前記ユーザ機器（ＵＥ）に関連付けられるフレーム及びサブフレームへリソース予約ウィンドウを同期させることは、前記リソース予約ウィンドウを、前記ＵＥから受信されるフレーム及びサブフレームへ同期させる、請求項１７の通信ノード。
    

Images