JP4847541B2

JP4847541B2 - データパケットトラフィック輻輳を解決する方法及び装置

Info

Publication number: JP4847541B2
Application number: JP2008547153A
Authority: JP
Inventors: ガボールフドル，; ライネルルドウィグ，
Original assignee: テレフオンアクチーボラゲットエルエムエリクソン（パブル）
Priority date: 2005-12-23
Filing date: 2005-12-23
Publication date: 2011-12-28
Anticipated expiration: 2025-12-23
Also published as: EP1985092B1; US8339964B2; CN101346971A; TW200729851A; US20080304416A1; JP2009521831A; EP1985092A1; WO2007073271A1; EP1985092A4; TWI359588B; ATE515864T1; CN101346971B

Description

本発明は無線アクセスネットワークにおけるトラフィック輻輳問題に関する。より具体的には、本発明は無線アクセスネットワークにおけるデータパケット輻輳問題を解決するための方法及びノードに関する。

第３世代(3G)移動体システムが発展し続けるにつれ、高ビットレートのマルチメディアサービスに対する市場の注目もまた高まっている。一方で、3Gオペレータは、インターネットプロトコル(IP)ベースのマルチメディアサービス(IMS)やインターネットへの無線アクセスを提供する技術、例えばIEEE802.Xベースの技術を用いる、従来とは異なるビジネスモデルからの強い競合に直面している。

従って、移動体通信オペレータは自身の発展しつつある無線アクセスネットワーク(RAN)を、TCP（通信制御プロトコル）及びUDP（ユーザデータグラムプロトコル）ベースのアプリケーションを含む、ブロードバンドIPベースのサービス、を提供する能力を与える技術で拡張することに興味を有している。本明細書において、既存の3G無線アクセスネットワーク技術を超える高ビットレートのRANを、まとめて「4G RAN」と呼ぶ。以下の文献は本発明と関連する従来技術である。

［１］WINNER プロジェクト, 「特定された新規な中継ベースの無線ネットワーク配置コンセプトの説明及び、拡張無線インタフェース技術を用いた周知の配置コンセプトのベンチマークとの対比による第１回評価」(Description of identified new relay based radio network deployment concepts and first assessment by comparison against benchmarks of well known deployment concepts using enhanced radio interface technologies), IST-2003-507581 D3.1

［２］C. Barakat, P. Thiran, G. Iannaccone, C. Diot, P. Owezarski, 「インターネットバックボーントラフィックのためのフローベースモデル」(A Flow based model for Internet backbone traffic), http://www.imconf.net/imw- 2002/imw2002-papers/ 123.pdf
［３］CISCO文書、QoSの構築、http://www.cisco.com/univercd/cc/td/doc/product/lan/cat4000/ 12_2_25 /conf/qos.pdf

注目に値するのは、4GがIPベースのアプリケーション専用に好適に設計可能であることである。つまり、4G RANがセルラオペレータのパケット交換ドメインとのみ相互動作し、4G上で稼働する全てのアプリケーションはIPベースであると仮定することができる。要するに、TCPアプリケーションだけでなく、レート適応符号化器を用いたVoIP(Voice-over-IP)を含む多くのUDPアプリケーションを含めた全てのアプリケーションがレート適応可能であると仮定することができる。

4G RANについて、多くの特徴がリストアップされている。
- IPベース及びレート適応型アプリケーションへの特化
- セル当たりただ１つの共有トラフィックチャネル - 利用可能な全帯域へのインスタントアクセス
- セッションベースのアドミッション制御リソース予約の非サポート（単独ベアラコンセプト）
- リアルタイム、疑似リアルタイム及び非リアルタイムの非区別 - IPパケット単位の有界再送遅延を用いたロスレスHARQ
- 純粋なエンドツーエンドメカニズムベースの輻輳制御（フロークラスキューイング及びアクティブキュー管理）
- 4G RANは、異なるサービスクラスを通じた(DiffServ風の）ホップ単位のQoSを提供する
- サービスクラス間のポリシベースのスケジューリング

4Gシステムにおける重要な要求は、システムの複雑さをできる限り低く維持しなければならないことである。これは、輻輳状況におけるシステム安定性を確保するだけでなく、サービス差別化のある基本的なレベルを提供することを目的としたサービス品質(QoS)手法に特に当てはまる。

インターネットはエンドツーエンドのQoSを提供しておらず、また様々な理由により、今後も提供されそうもない差別化サービス(DiffServ, DS)のホップ単位モデルは、ネットワークの複数のエッジノード間にQoSを提供するための魅力的な仕組みであり、そのため、4G RANにおいてQoSを提供するための用途には非常に都合がよい。（IETF RFC2475標準文書による）DiffServは、それが１つのオペレータのドメイン内で主に実装される場合、インターネットにおいて部分的に成功してきた。DiffServはIPパケットのサービスクラスを記すため、IPヘッダ内の６ビットのDSフィールドを用いる。この手法の大きな利点は、IP sec（IPセキュリティ手法）がDSフィールドを暗号化しないことである。IPsecは例えば企業向けアクセスに対して次第に用いられるようになってきた。そのため、4G RANは様々なサービスクラスを提供するために実装されるものと想定されている。IPパケットのサービスクラスはDSフィールドに記される。サービスクラスをいくつサポートするかは4Gオペレータに任されている。

従って、サービス品質(QoS)と言う言葉は、以下のように定義される。「共用インフラストラクチャに渡って、さまざまな、区別可能なサービス品質レベルを提供できる場合、ネットワークはQoSをサポートすると言われる。」

このQoSの定義において、ネットワーク上の負荷が低く、全ユーザ端末(UT)が十分なカバレージ（十分高い受信機レベル）を有する場合、異なるサービスクラス間での差がないことに留意されたい。そのような状況において、4G RANはより速く（IPパケット損失がなく、遅延が十分小さく）データを通信することが可能であり、従って、あるセル内の全ユーザ端末で使用されているアプリケーションはデータを配信可能である。

4Gがサポートを必要とする重要な機能は、オペレータのサービスネットワークを通じてオペレータが提供するアプリケーション、又はオペレータが選んだサードパーティが提供するアプリケーションと、所定のQoSレベルとを、オペレータが関連付けることを可能にする仕組みである。サービスは「パブリック」及び「プライベート」サービスクラスに分割することができる。パブリックサービスクラスは公然と提供され、4Gユーザが加入可能である。各ユーザ端末が例えば、「金」、「銀」、「銅」のいずれかの公衆サービスクラスの１つに属するという考え方である。公衆サービスクラス「金」は、ユーザの加入と抱き合わせの可能性がある。プライベートサービスクラスは4Gオペレータのみが設定可能であり、4Gユーザは利用できない。その考え方は、オペレータに選択されたアプリケーションに属するパケットがプライベートサービスクラス（以下では「プラチナ」という）に割り当てられるというものである。そのようにして、4Gオペレータはそれらのパケットが4G RANにおいて差別化されること、例えば公衆サービスクラスのパケットよりも優先されること、を確保することができる。この手法により、4Gオペレータによって選択された特定のサービスに関連付け可能な、保証されたビットレートをエミュレートすることが可能となるであろう。これには、適切なネットワークの容量設定(dimensioning)及び、それに対応する、様々なサービスクラス（優先度、最低ビットレート、等）を取り扱うためのポリシが必要となる。

図２の、QoSをサポートするシステムアーキテクチャについて検討する。システム内の総トラフィック負荷が増加するにつれ、システムの輻輳レベルも増加し始め、最終的には（第２レベルスケジューリング機構により）「プラチナ」ユーザトラフィックのみが処理されうる状況になる。

プラチナユーザからのトラフィック負荷のみにより高負荷の領域に達した場合、一部のプラチナユーザを優先させる必要がある。つまり、プラチナトラフィックを全てはスケジュールできない程度にシステムが輻輳した場合に、どのプラチナユーザを無線インタフェース上でスケジュールするかを決定するアルゴリズムが必要とされている。

同じ優先クラス（例えば「プラチナ」）に属する２つのユーザをシステムは差別化しないので、この問題は無視できない。図２に示すように、第２レベルスケジューラは、クラス間ポリシに関連付けされることができ、未処理のIPパケットの古さ(age)の経過を追うことができる。しかしながら、これらの情報からは、同じ古さの未処理IPパケットを有する同じクラス（例えばプラチナ）の複数のユーザを識別することができないため、これらの情報では不十分である。

簡単に言えば、輻輳時に、MACレベルでスケジュールされたリソースをどのユーザ端末のセッションに与えないべきかを決定するアルゴリズムが必要とされている。この問題はクラス内ユーザ端末ブロッキング問題と呼ばれる。

（発明の簡単な説明）
上述の問題に対して本願が提案する解決策は、明示的なセッションベース及びフローベースのシグナリングに依存せずに、ユーザ端末から無線インタフェース（ダウンリンク(DL)及びアップリンク(UL)）へのアクセスをブロック可能とする。DLにおいては、（媒体アクセス制御(MAC)レイヤ上でさえも）シグナリングを全く必要としない。

本発明は、無線リンク上でレート適応型のIPベースアプリケーションに適用可能な、複雑度が低く、かつ効率的なQoS手法を考案する際の重要なパズルのコマと見なすことができる。提案するQoS手法の基本的な考え方は、4G特有の仮定（高ビットレート、低い輻輳確率、適応型IPベースアプリケーション）の利点を利用し、セッションレベルのシグナリングとアドミッション制御を用いないサービス差別化を提供するというものである。このようなQoS手法はほぼ間違いなく、アプリケーションへの依存性が低く、必要とする状態情報が最小であり、事前のアプリケーションQoSシグナリング及びリソース予約を必要としない。

本発明は請求項１に係るトラフィック解決方法に関する。方法の様々なバリエーションが、従属請求項2-12に規定される。

本発明はまた、独立請求項１３に係るノードに関する。このノードは本発明の方法を実行する手段を備える。ノードの様々な実施形態が、従属請求項14-20に規定される。

本発明の利点は、そのようなQoS手法に関する重要な問題、すなわち、重い輻輳状態の間に一部のユーザ端末がブロッキングされるという問題を、ユーザデータ送信に先立つアドミッション制御を実行するためのセッションの確立及びユーザ端末−RANシグナリング手順およびリソース予約を必要とせずに解決することである。従って、提案する手法はネットワーク内で輻輳が生じている際のシステムの安定性を確保するために必要である。

以下、添付図面を参照しながら、本発明をより詳細に説明する。
図１は、UMTS(Universal Mobile Telecommunications System)のようなセルラ無線通信用の無線アクセスネットワーク(RAN)を示す図である。例えば移動無線端末であるユーザ端末UT(UT-1, UT-2, UT-3, ...)をセルC(C-1, C-2, ...)内で無線通信目的で使用するための能力は、例えば無線ネットワークコントローラ（GSM(Global System for Mobile communication)における基地局）、等のノード２によって提供される。ノード２はネットワーク内の別のノード４である基地局アンテナ４に接続される。基地局アンテナ４は、セル内で最良の無線信号カバレージを実現するように計画的に配置されている（UMTS技術において、基地局は通常ノードBと表され、RNCによって制御されるが、より一般的な意味において、RNCもまたシステム又はネットワークのノードとして見なしたり、表記したりすることが可能である）。各RNCノードは通常、複数の信号コネクション８を通じて複数のセル及びノードＢを制御している。

この模式図において、基地局アンテナ４はセルの中心に配置されているが、中心以外への配置も可能である。基地局アンテナ４は、無線送受信器装置（不図示）に接続される、少なくとも１つの無指向性又は指向性アンテナを備える。ユーザ端末UT及びRNCノードは基地局アンテナ４及びエアインタフェースを通じ、ユーザ端末UTから基地局アンテナ４へのアップリンク(Ulink)及び基地局アンテナ４からのダウンリンク(Dlink)の双方向で相互に通信可能である。移動体無線電話通信システムは、無線アクセスネットワークRANを備える。無線アクセスネットワークRANは通常、複数のコネクション６を介して相互接続されるとともに、コアネットワーク、PSTN、ISDN、LAN、WLANなどの他のネットワークにも接続される複数のRNCノードを備える。送受信器装置（不図示）は、無線ネットワークコントローラによって監視並びに制御される。なお、移動無線通信システムをUMTSシステムとして説明するが、これは単に説明上の単純化であって、本発明の範囲を限定する意図はない。従って、本発明は１つの移動無線通信標準に制限されず、逆に、以下に説明する本発明は任意の既知の移動無線通信標準に適用可能である。

図２は、WINNERプロジェクト（従来技術文献１）に従った、従来技術によるスケジューラアーキテクチャ設計１００の構成を模式的に示すブロック図である。図２は、4G QoSを処理するための様々な要素を、ダウンリンクにどのように実施することができるかの実施形態である。この実施形態は、２つの公衆サービスクラス、金(G)及び銀(S)と、１つのプライベートサービスクラス、プラチナ(P)とを備えている。優先度の高いサービスクラスから順に、プラチナ(P)、金(G)、銀(S)である。しかし、本発明の範囲内で他のクラス構成を用いることも可能である。セル内にＮの加入者がおり、そのうちＫがプラチナ加入者、Ｌが金加入者、(N-(K+L))が銀加入者であるトラフィック状況を仮定する。ここで、ユーザ端末UTは、4Gオペレータのサービスネットワークから提供される対応アプリケーション、例えばVoIPサービスが現在使用されている場合、公衆サービスクラスとは独立してプラチナクラスにも属することができることに留意されたい。

全てのアプリケーションがレート適応型であることが好ましい。レート適応型アプリケーションは標準で輻輳制御を有するため、4G無線アクセスネットワーク(RAN)へ輻輳制御のための明確なサポートを設計する必要がない。代わりに、フローベースキューイング及びアクティブキュー管理を4G RANに実装することが好ましい（従来技術文献２）。

2G及び3Gと同様、ユーザ端末(UT)１０（１２，．．．）毎に、少なくとも１つのIP（インターネットプロトコル）パケットキュー１０Ａ，１０Ｂ（１２Ａ，１２Ｂ，．．．）が存在する。（１つはRANのノードにおけるダウンリンク(DL)に、１つはUT（図示せず）におけるアップリンク(UL)に。）これは（標準的なIEEE802.11のように全端末がリンク層を共用するのとは対照的に）UT毎に独立したリンク層を実装していることの直接的な結果である。同じUTへの／からの様々なアプリケーションパケットが、分離または隔離される。そうしないと、バルクデータ転送は簡単に行頭(head-of-line)ブロッキングを引き起こし、結果としてその同じUT上での並列VoIPセッションの品質を低下させうる。これを回避するため、フローベースキューイング、すなわち、様々なフロー又は様々なフロークラスを別々にキューに入れる方法を用いることができる。フロークラスはソース及びデスティネーションIPアドレスの同一タプル上で規定することができる。

論理的に、既知のQoSアーキテクチャ設計は4Gネットワーク内に配置される３レベルのスケジューラを備えている。第１スケジューラ２２はユーザ端末に関連付けられ、様々なアプリケーションからの競合パケットをスケジュールする。第２スケジューラ２８は特定のUTのキューを選択し、対応するIPパケットを第３レベルスケジューラ３０に受け渡す。この第３レベルスケジューラ３０はMACスケジューラであり、未処理の、MACレベルスケジュールを待機しているIPパケットの１つを選択する。

4Gユーザ端末(UT)上で稼働するアプリケーションについてのQoSプロビジョニングは、３レベルのスケジューラによって与えられる。これらレベルの機能について、以下詳細に説明する。

１つの4G UT１０（１２，１４，１６，１８，２０）上では、いくつかのアプリケーション１０Ａ、１０Ｂ（１２Ａ，１２Ｂ、等）が動作しているであろう。そして、それらアプリケーションの各々は、トラフィックパターン及びQoS条件と関連付けられている。概念的に、複数のアプリケーションは、通常はオペレーティングシステムによって管理される複数のバッファ内の複数のキューにIPパケットを生成する。各UTにはスケジューラ２２が関連付けられており、スケジューラ２２の役目はアプリケーションキュー内で待機している未処理のパケットのどれを最初に処理すべきかの決定である。この実施形態では、重み付けラウンドロビン(WRR)スケジューラを用いるが、パケットサイズの違いを考慮しながら様々なフロークラスに対してUT（サービスクラス）毎の集合ビットレートを公平に分け与えることにより、他のスケジューラもまた同様に用いることができる。あるいは、そのようなスケジューラの制御をユーザが行うようにしてもよい。後者は、習熟したユーザが、所定のアプリケーション（例えばユーザが好むVoIPクライアント）に対するデフォルトの優先度を書き換えることを可能にするであろう。

このレベルでは、IPキューを保守するための手法が用いられる。アクティブキュー管理(AQM)はIPキューを効率よく保守するための実績ある手法である。この手法は、最新型ルータの多くでサポートされている（従来技術文献３）。AQMは「パケット廃棄」を暗示的な輻輳信号として用いて、あるいは（IETF RF3168に記載される）パケットを廃棄する代わりに「輻輳を受けた」というマークを付す明示的輻輳通知(ECN)を用いて動作することができる。このマークは受信側のレート適応型アプリケーション（例えばTCP）によって複製（エコー）される。AQMの主要な特徴は、バッファスペースを、一時的なパケットバーストを吸収するために残したり、エンドツーエンドスループットを最大化するために必要なだけのパケットをキューに入れたりするために、キューが一杯になる前に反応する（パケットを廃棄するか、パケットにマークを付す）ことである。

次のレベル２４で、4Gアクセスポイント(AP)はUT毎のキューを保守する。すなわち、第１レベルスケジューラ２２によって選択されている１つのIPパケットが、このUT毎のキューに収容される。APでのこれら論理キュー２６は、ユーザ端末に位置するそれらのピアエンティティに関連付けられたハイブリッド自動再送要求(HARQ)送信器２４を有する。第２レベルスケジューラ２８の役割は、未処理のIPパケットのうち、どの１つ以上をMACレベルスケジューラ３０用に選択すべきかを決定することである。このスケジューラはクラス間ポリシ（すなわち、様々なサービスクラスＰ，Ｇ及びＳ間の優先度処理）、さらにはUT毎のキュー２６で待機しているIPパケットの古さ(age)を考慮することができる。

様々なクラスＰ，Ｇ及びＳ間のスケジュールは、任意の特定のサービスクラスに対して提供されるQoSのレベルを決定するものである。１つのサービスクラス内のスケジューリングは、同一サービスクラスの複数のUTをどのように取り扱うか、例えば、送信バイト又はパケット数に基づく公平性、消費無線リソース量に基づく公平性、等を決定する。

１つのスケジューラ、ポリシベーススケジューラ２８が、サービスクラス間のスケジュールを実行すべきである。

このスケジューラの動作は、できる限りオペレータポリシによって決定されるべきである。すなわち、4G標準又はベンダ固有4G実装によるスケジューラへの組み込みは、最小限の関数、機能及びポリシに止めるべきである。

以下、考えられるスケジュールポリシのいくつかの例を説明する。

１つのプライベートサービスクラス（プラチナ）に関し、4Gオペレータは、4Gオペレータのサービスネットワークから提供されるサービスに対してセル当たりどれくらいの帯域を予約すべきであるかを求めることができる。これは、任意の時刻においてそのサービスを実際に使用しているユーザ数、最大品質に対しそのサービスが必要とするビットレート、等に対して適応的にすることができる（するべきである）。

２つの公衆サービスクラス（金G、銀S）に関し、4Gオペレータは、金Gクラスが、ピークトラフィック時において銀トラフィックを飢餓的な状況にしうるような、絶対的な優先度を有するものと決定することができる。あるいは、金トラフィック用に、金クラスでアクティブな（送受信中の）UTの数に基づく、適応的な所定の最小帯域を確保しておいてもよい。

様々な、固定スケジューリング重み（優先度に比例した公平性）を様々なサービスクラスに割り当ててもよい。

サービス単位で割り当て可能な最小ビットレートは、ある特定のUTの受信機信号強度に潜在的に依存する。例えば、受信機レベルが３以上のプラチナユーザに対しては2Mb/sの最小レートを、受信機レベルが４以上の金ユーザに対しては0.1Mb/sの最小レートをそれぞれ割り当て、銀ユーザに対しては最小レートを割り当てない。

この設計において、ポリシスケジューラ及びMACスケジューラ３０は別個のエンティティである。そうすることで、MACスケジューラ３０は、チャネル依存スケジューリングを通じたマルチユーザゲインに純粋にフォーカスして、独立動作できる。

MACスケジューラはポリシスケジューラ２８から、ポリシスケジューラがMACスケジューラからの要求時に割り当てる送信トークン(Send-Token)３２を通じて制御される。

各送信トークン３２は、１つの特定のUT-iに属し、１つのL2-PDU（IPパケット）の送信が成功するまで「有効」である。

クラス間ポリシとは別に、ポリシスケジューラ２８はIPパケットの「古さ」も考慮する必要がある。各IPパケットが、IPキューに格納される際にタイムスタンプ、例えば現在システム時刻を割り当てられるということである。「古い」パケットほど高い優先度又は重みとなり、ポリシスケジューラによってスケジュールされる可能性が高くなる。ここでは、HARQ送信器２４が最も古いL2-PDU（IPパケット）再送を常に再／送信キューの一番前に配置する、すなわち、再送が常に新しい送信よりも優先されるものと仮定している。

つまり、MACスケジューラ３０は十分高いマルチユーザゲインを実現するため、自由に使用できる十分な量のトークンを常に有することができるように、トークン３２を常に要求するということである。

同時に、MACスケジューラは、全てのトークン３２に関連付けられたペイロードを、短時間内に、例えば１０ｍｓ未満で送信できることを保証しなければならない。さもないと、MACスケジューラ３０は行頭ブロッキング及び過剰な遅延を発生しうる。MACスケジューラがトークン３２をスケジュールする際、対応するUTに、任意のチャネル品質(CQI)３４の所定量のチャンク提供を申し出る。そして、UTは、使用したいチャンクの数を決定し、適合する前方誤り訂正(FEC)フラグメントを生成する。

続いてMACスケジューラは、送信フレーム（フレームビット又はMACプロトコルデータユニット）を一杯にするまで、次のトークンをスケジュールする。ポリシスケジューラ２８がパケットの古さを保守するのと同様、MACスケジューラもトークンの古さを保守する必要がある。これは、特定のトークンに属するUTが飢餓状態(starvation)になるのを防止するためである。従って、たとえその時点でチャネル品質(CQI)が良好なチャンクが依然としてわずかしか存在していないとしても、古いトークンほどMACスケジューラ３０によってスケジュールされやすくなる。早晩MACスケジューラが自身に割り当てられたIPパケットをスケジュールしなくてはならないので、これは、ポリシベーススケジューラ(PBS)２８が受け持つIPパケットを送信すべきか否か、及びいつ送信すべきか、に関する事実上の最終決定を意味する。これはまた、MACスケジューラ３０にとってサービスクラスが透過的であることも意味する。

上述した、QoS処理のための4Gスケジューラアーキテクチャの機能について、図３の信号方式を参照して説明する。

所定のアプリケーションに属し、あるUTに宛てられたIPデータパケットが、第１スケジューラレベル２２に到着する。HARQ送信器２４に送信されるために選択されるのを待機しているIPパケットは、バッファ２６内のフロークラス単位キューイングに従ったキューに収容されている。次のステップで、HARQ送信器２４は、次レベルのスケジューラ２８、PBSへの送信要求を生成し、PBSは要求受信時刻をIPパケットに設定する。PBSはUTあたり１つの要求のみ受信する。

PBS２８はクラス間ポリシ及びIPパケットの古さをチェックする。要求を受け入れる場合、PBSは送信トークンをCD-MAC（チャネル依存媒体アクセスコントローラ）へ発行する。UTは、そのUT内の対応するピアHARQへ無線インタフェースを介して送信されるべきIPパケットがHARQバッファ内で待機中の候補である。発行された送信トークンは、CD-MACスケジューラ３０によって管理及び操作されるメモリ空間である候補領域(candidate room)に格納される。CD-MACはピアUTタイマを保守する。つまり、各UTは自身のタイマを有している。

そのため、CD-MACスケジューラは、個々の送信トークンの古さを監視し、予め定められた古さを超えた送信トークンを廃棄することが可能である。MACスケジューラ３０はトークンによって制御され、処理を待っているUT当たり１つのみの送信トークンが存在する。送信トークンはそのUT候補に関する情報を格納する。CD-MACはどのUTが候補であるかを知っているので、候補領域に示される各UTの無線チャネル品質CQIをチェックする。MACからコンタクトを受けたUTは、チャネル品質に応じた前方誤り訂正(FEC)冗長性を設定して応答する（チャネル品質が良ければ必要なFEC冗長ビット数も少ない）。MACスケジューラ３０は（PBSに知らせることなく）直接HARQ送信器２４と通信し、測定並びに決定されたCQIに起因するFECレベルを設定する。MAC３０が依然としてUTと通信可能であれば、MACは、必要なFECレベルを含んだ「HARQパケットフェッチ」命令をHARQ送信器に送信する。一方、UTへの通信ができないと判断されれば、MAC３０は「HARQパケット廃棄」コマンドを対象のHARQ送信器へ送信する。

対象のHARQ送信器が「HARQパケットフェッチ」コマンドを受信した場合、HARQはチャネルに対する現在のFECレベルを含んだHARQヘッダをIPパケットに付与する。HARQ送信器はHARQパケットを、UT内の対応するピアHARQへ送信する。このピアHARQがデータパケットを正しく受信した場合、ピアHARQはRNC内の対応するピアHARQへ確認応答を返送する。HARQが確認応答を受信すると、HARQは、「確認応答受信」通知をMACへ送信し、MACは候補領域内の送信トークンを廃棄する。

同じクラスに属する複数のユーザからの選択が必要になることもある。この問題は上述した既知のアーキテクチャでは解決されない。

このクラス内スケジュール問題は、スケジューラ及び無線通信インタフェースが、同一クラスに属する入来IPパケットの全部は処理できない場合に発生する。これは、データパケットがシステム内で待たされる時間が長すぎることを意味する。キューはオーバフローするであろう。この状況はトラフィック輻輳と呼ばれる。従って、同一クラス内で一部のUTを選択し、他のUTよりも優先させる必要がある。これはクラス内選択と呼ばれる。クラス内選択、即ち様々なサービスクラスからのUT選択は、ポリシベーススケジューラ２８内に組み込まれているトラフィックポリシにオペレータが規定している。

従来技術によるシステムでは、アドミッション制御を用いてこの問題を解決している。しかし、アドミッション制御は無線インタフェース上でのシグナリングを必要とする。シグナリングは利用可能な無線リソース及び帯域を制限するであろう。そのため、WINNERプロジェクトが提案している4Gシステム（従来技術文献１）においては、アドミッション制御は必須でなく、各ユーザが起動し、データパケットの送信を開始することを許可している。従って、無線シグナリングを行わないか、あるいは厳密に制限された量しか行わない本発明によるクラス内選択手法は、大変重要である。

可能性のある方法は、クラス内の複数のUTの無作為な選択である。しかし、以下では図４を参照して、選択問題の本発明に係る解決方法について説明する。アーキテクチャの詳細の多くは図２に関して既に説明してきたので、図４において共通する詳細については同じ参照数字を付してある。

本発明は、チャネル依存MACスケジューラ３０を含む、ブロッキングの仕組みを備えたトラフィック輻輳解決方法である。CD-MACは複数のピアUTタイマ３８を保守する。つまり、各UT４６は自身のタイマを有している。さらに、CD-MACスケジューラはテーブル４０(ブロッキングテーブルとも表記する）に、セル内に存在するUTを登録する。

本発明の仕組みは、輻輳又は輻輳の警戒状態で開始し、異なる複数のUTをアクティブ４２又はアイドル４４に分類するステップと、この情報を、システム内に存在するUTと同数のタイマ３８を備えるブロッキングテーブル４０に格納するステップとを含む。ブロッキングテーブル４０は、輻輳又は輻輳の警報が存在する際に、チャネル依存MACスケジューラ３０によって保守される。ブロッキングテーブル４０は、システム内に現在存在する全てのUTに渡るレジストリであり、どのUTがアクティブで、どのUTが非アクティブであるかの情報を保持する。セル内に存在するUTに関するセル内の情報は、トークンタイマ情報の古さに加えてUT情報を格納する送信トークンから収集される。

輻輳期間又は輻輳警戒期間において、MACスケジューラは、無線インタフェース上で送信するHARQパケットを選択する際に、この情報及びCQI情報の両方を考慮する。UTがアクティブ／非アクティブに関連付けられると、この情報をMACスケジューラが利用可能になる。このアクティブ／非アクティブ状態情報が保守されるようにするため、輻輳期間もしくは輻輳の前期間において、UTをアクティブ／非アクティブに分類し、ブロッキングテーブル４０内の状態情報が最新の状態であることを確保するための仕組みが必要である。

輻輳検出：
MACスケジューラ３０及びPBSスケジューラ２８は、輻輳及び／又はその前兆(pre-state)を検出することが可能である。従って、ノードには、コンピュータソフトウェア又はハードウェアで実施可能な輻輳監視手段が設けられている。システムがほとんど輻輳しかかっている際、低いサービスクラス、例えば金や銀に属するユーザ端末は、すでにデータパケット送信を完全にブロックされているであろう。

輻輳の前兆状態又は輻輳警戒状態を判別可能とするためには、輻輳レベルを定義する必要がある。輻輳レベルは、予め定められた閾値を超える、単位時間当たりのHARQからの入来送信要求数（即ち、入来レート）と単位時間当たりの総ダウンリンク容量又はパケットの出力(out-going)レートとの比として定義することができる。別の有用な輻輳レベル定義は、MACスケジューラ内の候補保存場所(store)における送信トークンの危機的な合計数である。輻輳の始まりまたは現実の輻輳のさらに別の有用な定義は、候補保存場所内の送信トークンタイマの時間合計(time-sum)が予め定められた閾値、例えば１０ｍｓを超えることである。輻輳警告機構が輻輳警戒状態又は実際の輻輳を検出した場合、MACスケジューラは上述したブロッキングテーブルを生成することが可能である。

分類アルゴリズム：
輻輳又は輻輳警戒状態において、候補保存場所内のUTの各々はブロッキングテーブル４０においてアイドルに分類される。

MACスケジューラが送信のためのHARQパケットをスケジュールする際、スケジューラはそのパケットが無線インタフェース上で成功裏に送信されるのを待つ。MACスケジューラはHARQ送信器アルゴリズムが現在のHARQパケットの送信を成功裏に終了した後で、送信トークンを廃棄する。HARQパケットが正しく送信されると、MACスケジューラはブロッキングテーブル４０内の対応するUTのエントリを、アイドルからアクティブに変更する。スケジューラはさらに、そのUTのタイマを、大きな正の値Ｎに設定する。

HARQパケットが成功裏にスケジュールされる毎に、MACスケジューラはパケットをスケジュールしたばかりの１つのUTを除く個々のUTについて、Ｎを減少させる。UTのタイマが０に達すると（すなわち、Ｎが０になると）、そのUTは再びアイドル状態に分類される。Ｎは、HARQパケットのスケジュールとは無関係に、予め定められた時間の経過後に減少させてもよい。ここで、あるUTに属している複数の送信トークンの１つの古さを参照するだけでは、そのUTがアイドルかアクティブかを分類することができないことに気付くことは重要である。あるUTの送信トークン全てを考慮する必要があり、全ての送信トークンが送信するには古すぎる場合そのUTはアイドルと見なされる。

ブロッキング手法：
輻輳時、MACスケジューラ３０は、アイドルに分類されているUTの送信トークン及び対応するHARQパケットを廃棄する。それにより、アクティブに分類されているUTは自身のHARQパケットがスケジュールされる確率が高くなる。

上述したアルゴリズムは、輻輳期間中にアクティブユーザとアイドルユーザとの間を適合的に差別化するための簡単な手段を提供する。大まかにいえば、そのような輻輳期間がめったに生じないようにシステム容量を定めるべきである。すなわち、通常時はもとより「軽い」輻輳期間であっても、サービスクラスに基づく差別化によって、十分ユーザ間を差別化し、かつシステムの安定性を保つことができるべきである。しかし、プラチナユーザだけでシステムを過負荷にするようなまれな場合には、クラス内差別化を可能にする必要がある。そのような厳しい輻輳期間（「大晦日」現象と呼ばれるような、短期間に膨大な発呼がセルラセル内に生じる場合）に、本発明が適用可能になる。典型的には、システム負荷は「通常」レベルから、極度の輻輳レベルまで段階的に上昇する。

システム内にプラチナユーザがいない際の状態を考えてみる。しかしながら、金及び銀ユーザがシステムを厳しい輻輳状態とするトラフィック負荷を生成する。この場合、金ユーザ間の差別化が問題となるが、プラチナユーザについて説明した方法とほとんど同じである。上述したクラス内選択は、説明した「プラチナユーザ」以外のサービスクラスに対しても適用可能である。

上述したブロッキングアルゴリズムの実施形態は、セルのRANノードからUTへのダウンリンク(フォーワードリンク）方向において説明した。

しかし、アップリンク(リバースリンク）においても、ダウンリンクと同じ機能構成要素及びエンティティが存在する。ユーザ端末において、IPパケットはHARQによって処理され、少なくとも１つのキューに編成され、IPパケットはピアHARQへ送信されるべく待機する。スケジュール制御は基地局(又は無線ネットワーク）コントローラ、すなわちBSC/RNCによって処理される。

アップリンクMACスケジューラは、UTのキュー全ての状態についての全体的な知見を持たない。しかし、ダウンリンクの場合とアップリンクの場合とでの違いは、HARQ送信器とアップリンクRBSとアップリンクMACスケジューラとの間の制御プレーンで通信されるコマンドとがRNCノード内部ではなくエアインタフェースを通じて送信されることのみである。

本発明はまた、セルラ無線通信のための無線アクセスネットワーク(RAN)におけるノード２、例えば無線ネットワークコントローラ、基地局コントローラ、等である。ノード２は、送受信器手段、基地局アンテナ４など、ノード２とセルエリアC-1内の複数のユーザ無線端末UT(UT-1, UT-2,...)の間のエアインタフェース上でデータパケット（IPパケット）を送信及び受信するための手段に接続される。ノード２は、チャネル品質表示(CQI)及び保存データパケット情報３２、例えば特定並びにアドレス指定されたユーザ端末UTへの／からの伝送のための選択待ち状態のデータパケットに属するトークン、に起因してUTスケジューリングを関し及び制御するためのチャネル依存スケジューラ３０を備える。ノード２は、以下に説明する、本発明のトラフィック輻輳解決方法を実行する能力を提供する複数の手段を備える。

ノード２は、以下ではブロッキングテーブルと表記するテーブル４０を生成する手段を備える。テーブル４０は、トラフィック輻輳状態が発生している、あるいは発生しそうである場合に、同一サービスクラス（P, G, S,...)に属するユーザ端末を含んでいる。さらに、ノード２は、輻輳状態が存在している限り（好ましくは輻輳状態が存在する期間のみ）ブロッキングテーブル４０を保守するための手段を備える。さらに、ノード２は、ブロッキングテーブル４０がスケジューラ(30)に、ユーザ端末(UT)が所定時間以上アイドル状態と判定されていることを通知した場合に、そのユーザ端末UTとノード２との間におけるデータパケットの送信を、アップリンク（Ulink)及びダウンリンク(Dlink)の両方向でブロックするための手段を備える。ノード２にはさらに、ブロッキングテーブルがスケジューラに、ユーザ端末が依然としてアクティブ状態であると判定されていることを通知した場合に、そのユーザ端末とノードとの間におけるデータパケットの送信をアップリンク及びダウンリンクの両方向で許可するための手段も備える。上述した手段の全ては、例えば無線ネットワークコントローラ(RNC)内において、ノード２内部の、あるいはノード２に接続されたコンピュータ、プロセッサ、ＣＰＵ、マイクロプロセッサ等によって読み込み可能かつ実行可能なプログラム命令として実装されることが好ましい。プログラム命令はソフトウェア又はハードウェアで実現することができる。

本発明の一実施形態によれば、ノード２はさらに、上述のブロッキングテーブル４０にユーザ端末UTごとに１つのエントリを、ユーザ端末ごとに１つのUT毎タイマを導入する手段と、テーブルに表されているユーザ端末の各々をアイドルに設定し、対応するUT毎タイマを予め定められた開始値に設定する手段を有する。

以下に列挙する、本発明の様々な実施形態を規定する手段は、例えば無線ネットワークコントローラ(RNC)内において、ノード２内部の、あるいはノード２に接続されたコンピュータ、プロセッサ、ＣＰＵ、マイクロプロセッサ等によって読み込み可能かつ実行可能なプログラム命令として実装されることが好ましい。プログラム命令はソフトウェア又はハードウェアで実現することができる。
- 対応する１つ以上のデータパケットが成功裏に送信されたならば、例えば、受信側から確認応答が受信されているならば、ブロッキングテーブル４０内のユーザ端末エントリ４６をアイドル４２からアクティブ４４に変更する手段、
- 対応するUT毎タイマ３８のカウント値を、予め定められた開始値に設定する手段、
- 対応するUT毎タイマ３８のカウント値を、予め定められた大きな正の開始値Ｎに設定する手段、
- １つ以上のデータパケットが成功裏に送信されたばかりの１つのUTを除く、UT毎タイマ３８それぞれのカウント値を減少させる手段、
- UT毎タイマ３８のそれぞれのカウント値を予め定められた減少値だけ減少させる手段、
- 対応するUT毎タイマ４０が予め定められた停止値に達した場合にユーザ端末をアイドル４２に設定する手段。

本発明の他の一実施形態によれば、チャネル依存スケジューラ３０は媒体アクセス制御(MAC)スケジューラであり、対応するUT毎タイマが予め定められた停止値に達した結果としてアイドルであることがテーブルにおいて示されるユーザ端末に属する保存データパケット情報を表す、１つ又は複数の対応する送信トークンを廃棄することにより、特定されアドレス指定されたユーザ端末への／からの送信のために選択されるのを待機している１つ以上のデータパケットをブロックすることが可能である。

さらに別の実施形態において、ノードはさらにポリシベースのIP/L2-PDU（インターネットプロトコルレイヤ２パケットデータユニット）スケジューラ２８を有する。このスケジューラは、ノード２における送信エンティティ２４によって生成され、受け入れられた「送信要求」を、この受け入れられた送信要求を送信トークン３２として保存可能なMACスケジューラ３０へスケジュールする。送信エンティティ２４は、ハイブリッド自動再送要求(HARQ)として実装することができる。

データパケット輻輳を解決する手段を有する本発明の方法及びノードが、ユーザデータ送信に先立つアドミッション制御及びリソース予約のためのセッションの確立並びにUT-RANシグナリング手順を行わずに、どのようにして無線アクセスネットワークRANにおける輻輳状態を検出し、処理することが可能なのかについて説明してきた。本発明は、上述した好適な実施形態には限定されない。様々な代替物、変形物及び等価物を使用可能である。従って、本発明の範囲は特許請求の範囲によって規定され、上述の実施形態は本発明の範囲を限定するものとして解すべきものではない。

セルラ無線通信用の無線アクセスネットワーク(RAN)におけるセル及び一部の機能要素を模式的に示すブロック図である。従来技術によるスケジューラアーキテクチャの構成を模式的に示すブロック図である。従来技術によるスケジューラアーキテクチャにおけるコマンドシグナリング方法を示す図である。本発明によるスケジューラアーキテクチャの構成を模式的に示すブロック図である。

Claims

無線アクセスネットワーク(RAN)を備えるセルラ無線通信のためのデータパケット輻輳解決方法であって、前記ネットワークは少なくとも１つのノード(2)を含み、前記ノードはチャネル依存スケジューラ(30)を有し、前記チャネル依存スケジューラは、チャネル品質表示(CQI)及び特定されアドレス指定されたユーザ端末UTへの／からの送信のために選択されることを待機しているデータパケットに属する保存データパケット情報（送信トークン,32）とによってUTスケジューリングを監視及び制御し、前記方法が、
- トラフィック輻輳状態が発生している、あるいは発生しそうである場合に、前記ユーザ端末UTのうち、同一サービスクラス（P)に属するユーザ端末を含んだテーブル(40, ブロッキングテーブル)を生成するステップと、
- 前記輻輳状態が存在する限り前記テーブル(40)を保守するステップと、
- 前記テーブル(40)が前記スケジューラ(30)に、ユーザ端末(UT-1)が予め定められた時間を超えてアイドル(42)であると判別されていることを通知した場合、前記ユーザ端末(UT)と前記ノード(2)との間のデータパケットの送信をアップリンク及びダウンリンク両方向でブロックするステップとを有することを特徴とする方法。
さらに、
- 前記スケジューラ(30)が読み取り可能なテーブル(40)が前記スケジューラに、前記ユーザ端末が依然としてアクティブ(44)であると判定されることを通知した場合に、前記ユーザ端末(UT-2)と前記ノード(2)との間におけるデータパケットの送信をアップリンク及びダウンリンクの両方向で許可するステップを有することを特徴とする請求項１記載の方法。
前記生成するステップが、
- 前記テーブル(40)に、各ユーザ端末に対して１つのエントリ(46)を、各ユーザ端末に対して１つのUT毎タイマ(38)を導入するステップを含むことを特徴とする請求項１記載の方法。
前記生成するステップが、
- 示されるユーザ端末(UT,46)の各々をアイドル(42)と設定するとともに、前記対応するUT毎タイマ(38)を予め定められた開始値に設定するステップを含むことを特徴とする請求項３記載の方法。
前記保守するステップが、
- 対応する１つ以上のデータパケットが成功裏に送信されたならば、前記テーブル(40)内のユーザ端末エントリ(46)をアイドル(42)からアクティブ(44)に変更するステップを含むことを特徴とする請求項１記載の方法。
前記保守するステップがさらに、
- 前記対応するUT毎タイマ(38)のカウント値を、予め定められた開始値に設定するステップを含むことを特徴とする請求項５記載の方法。
前記保守するステップがさらに、
- 前記対応するUT毎タイマ(38)のカウント値を、予め定められた大きな正の開始値Ｎに設定するステップを含むことを特徴とする請求項６記載の方法。
前記保守するステップがさらに、
- １つ以上のデータパケットが成功裏に送信されたばかりの１つのUTを除く、前記UT毎タイマ(38)それぞれの前記カウント値を減少させるステップを含むことを特徴とする請求項７記載の方法。
前記保守するステップがさらに、
- 前記UT毎タイマ(38)のそれぞれの前記カウント値を予め定められた減少値だけ減少させるステップをさらに有することを特徴とする請求項７記載の方法。
前記保守するステップが、
- 前記対応するUT毎タイマ(38)が予め定められた停止値に達した場合にユーザ端末をアイドル(42)に設定するステップをさらに有することを特徴とする請求項８又は請求項９に記載の方法。
前記生成するステップ、前記保守するステップ、及び前記ブロックするステップが、媒体アクセス制御(MAC)スケジューラである前記チャネル依存スケジューラ(30)によって制御されることを特徴とする請求項１乃至請求項１０のいずれか１項に記載の方法。
前記媒体アクセス制御スケジューラ(30)は、対応するUT毎タイマ(38)が予め定められた停止値に達した結果として前記テーブル(40)においてアイドル(42)であることが示されるユーザ端末に属する保存データパケット情報を表す、１つ又は複数の対応する送信トークン(32)を廃棄することにより、特定されアドレス指定されたユーザ端末への／からの送信のために選択されるのを待機している１つ以上のデータパケットをブロックすることが可能であることを特徴とする請求項１１記載の方法。
セルラ無線通信のための無線アクセスネットワーク(RAN)におけるノード(2，無線ネットワークコントローラ)であって、前記ノードは、チャネル品質表示(CQI)及び特定されアドレス指定されたユーザ端末UTへの／からの送信のために選択されることを待機しているデータパケットに属する保存データパケット情報（送信トークン,32）とによってUTスケジューリングを監視及び制御するチャネル依存スケジューラ(30)を有し、トラフィック輻輳を解決するための手段であって、
- トラフィック輻輳状態が発生している、あるいは発生しそうである場合に、前記ユーザ端末(UT)のうち、同一サービスクラス(P)に属するユーザ端末を含んだテーブル(40, ブロッキングテーブル)を生成する手段と、
- 前記輻輳状態が存在する限り前記テーブル(40)を保守する手段と、前記テーブル(40)が前記スケジューラ(30)に、ユーザ端末が予め定められた時間を超えてアイドル(42)であると判別されていることを通知した場合、前記ユーザ端末(UT)と前記ノード(2)との間のデータパケットの送信をアップリンク及びダウンリンク両方向でブロックする手段とを有することを特徴とするノード。
前記スケジューラ(30)が読み取り可能なテーブル(40)が前記スケジューラに、前記ユーザ端末が依然としてアクティブ(44)であると判定されることを通知した場合に、前記ユーザ端末(UT)と前記ノード(2)との間におけるデータパケットの送信をアップリンク及びダウンリンクの両方向で許可する手段をさらに有することを特徴とする請求項１３記載のノード。
前記テーブル(40)に、各ユーザ端末に対して１つのエントリ(46)を、各ユーザ端末に対して１つのUT毎タイマ(38)を導入する手段をさらに有することを特徴とする請求項１３記載のノード。
前記テーブルにおいて、示されるユーザ端末の各々をアイドル(42)と設定するとともに、前記対応するUT毎タイマ(38)を予め定められた開始値に設定する手段をさらに有することを特徴とする請求項１５記載のノード。
前記チャネル依存スケジューラ(30)が媒体アクセス制御(MAC)スケジューラであることを特徴とする請求項１３乃至請求項１６のいずれか１項に記載のノード。
前記媒体アクセス制御スケジューラ(30)は、対応するUT毎タイマ(38)が予め定められた停止値に達した結果として前記テーブル(40)においてアイドル(42)であることが示されるユーザ端末に属する保存データパケット情報を表す、１つ又は複数の対応する送信トークン(32)を廃棄することにより、特定されアドレス指定されたユーザ端末への／からの送信のために選択されるのを待機している１つ以上のデータパケットをブロックする手段を備えることを特徴とする請求項１７記載のノード。
前記ノードがさらに、前記ノード(2)における送信エンティティ(24)で生成され、受け入れられた送信要求を、前記要求を送信トークン(32)として保存可能な前記MACスケジューラ(30)へスケジュールする、ポリシベースのIP/L2-PDUスケジューラ(28)を有することを特徴とする請求項１８記載のノード。
前記送信エンティティ(24)がハイブリッド自動再送要求(HARQ)であることを特徴とする請求項１８又は請求項１９記載のノード。