JP5266257B2 - フレキシブルな無線リンク制御パケットデータユニット長 - Google Patents

Description

本発明に従った実施形態は、一般に無線通信システムに関し、特に、移動通信システムにおけるデータフロー制御に関する。

広帯域符号分割多重アクセス無線アクセスネットワーク（ＷＲＡＮ：Wideband Code Division Multiple Access Radio Access Network）は、３ＧＰＰ Ｒｅｌｅａｓｅ５において、高速ダウンリンクパケットアクセス（ＨＳＤＰＡ：High Speed Downlink Packet Access）を導入し、３ＧＰＰ Ｒｅｌｅａｓｅ６において、高速アップリンクパケットアクセス（ＨＳＵＰＡ：High Speed Uplink Packet Access）／拡張アップリンク（ＥＵＬ：Enhanced Uplink）を導入した。高速パケットアクセス（ＨＳＰＡ：High Speed Packet Access）は、ＨＳＤＰＡとＥＵＬ双方に共通する用語である。Ｒｅｌｅａｓｅ４からＲｅｌｅａｓｅ６までの３ＧＰＰ仕様は、ＨＳＰＡのために、幾つかの固定されたメディアアクセス制御−ｄ（Medium Access Control-d：ＭＡＣ−ｄ）パケットデータユニット（ＰＤＵ）長を用いる。無線リンク制御（ＲＬＣ：Radio Link Control）の送信ウィンドウの制限は２０４７個のＰＤＵであると共に、ラウンドトリップ時間（サービス提供無線ネットワークコントローラからユーザ機器まで、及びその復路）はより長いことによって、セルラシステムにおけるピークのビットレートは制限される。

複数入力複数出力（ＭＩＭＯ：Multiple Input、Multiple Output）の導入、及び／又は、６４値直交振幅変調（ＱＡＭ：Quadrature Amplitude Modulation）によって、ピークのビットレートは４２メガビット／秒（Ｍｂｐｓ）となる。（２０４７のＲＬＣウィンドウサイズが維持されると仮定すると、）より高いＨＳＤＰＡピークのビットレートのためには、より長いＭＡＣ−ｄ ＰＤＵ長が必要である。整数個のＭＡＣ−ｄ ＰＤＵのみが無線インタフェースを介して１つの送信時間間隔（ＴＴＩ：Transmission Time Interval）においてスケジューリングされる限り、即ち、１個のＭＡＣ−ｄ ＰＤＵが１つのＴＴＩにおいて送信され得るデータの最小単位である限り、過度に長いＭＡＣ−ｄ ＰＤＵの使用によって、カバレージが制限されることになる。

ＲＬＣ確認応答モード（ＡＭ：Acknowledged Mode）は、フレキシブルなＰＤＵ長を利用するための構造を提供する。例えば、ＲＬＣ ＡＭ（３ＧＰＰ ＴＳ ２５．３２２、ＲＬＣプロトコル仕様）において、フレキシブルなＰＤＵ長の構造が定義されている。幾つかのＲＬＣ ＰＤＵ長を構成する可能性があるが、ヘッダフィールドは、使用可能な事実上の数を制限してもよい。例えば、現在では、最大８つの異なるＭＡＣ−ｄ ＰＤＵ長をＨＳ−ＤＳＣＨを通じて利用することが可能であるが、その場合、ＭＡＣ−ｄ ＰＤＵはＲＬＣ ＰＤＵと任意のＭＡＣ−ｄヘッダとを含む。従って、全く新しいＰＤＵ長の構造が最適な性能のために必要である。

高速ダウンリンク共有チャネル（ＨＳ−ＤＳＣＨ：High Speed Downlink Shared Channel）の容量割り当てのための現在の解決策、及び、ＨＳ−ＤＳＣＨデータフレームの定義は、フレキシブルなＲＬＣ（又は、フレキシブルなＰＤＵ長の構造）の解決策のためには効果的ではない。ＨＳ−ＤＳＣＨデータフレームのビットレートは、現在のＨＳ−ＤＳＣＨ容量割り当ての制御フレームフォーマットを用いては良好に制御され得ない。現在の制御フレームフォーマットは、所与の数の、所与の最大長（最大ＭＡＣ−ｄ ＰＤＵ長）のＰＤＵ（ＨＳ−ＤＳＣＨクレジット（Credit））が所与の間隔（ＨＳ−ＤＳＣＨ間隔）に送信可能であることを特定する。固定されたＭＡＣ−ｄ ＰＤＵ長を仮定すると、このフォーマットをある間隔内でのオクテットに、又はビットレートに翻訳することは容易である。しかし、フレキシブルなＲＬＣの導入によって、各Ｍａｃ−ｄ ＰＤＵ及び全Ｍａｃ−ｄ ＰＤＵが異なる長さとなる可能性がある。従って、１オクテットのＰＤＵは、１５００オクテットのＰＤＵと同様に全てのクレジットを消費し、それにより許可された間隔ごとのオクテット数又は許可されたビットレートを制御することは困難となる。

ＨＳ−ＤＳＣＨデータ転送の初期容量は、ＨＳ−ＤＳＣＨ初期容量割り当てを介して、無線リンク起動の手続、無線リンク再構成の手続、又は無線リンク追加の手続の間に、基地局により認められる。これら手続の間に、ＨＳ−ＤＳＣＨ初期容量割り当ては、基地局によりサービス提供無線ネットワークコントローラへと送信され、最大ＭＡＣ−ｄ ＰＤＵ長（最大ＭＡＣ−ｄ ＰＤＵサイズ）と、ＭＡＣ−ｄ ＰＤＵの数（ＨＳ−ＤＳＣＨ初期ウィンドウサイズ）とを特定する。このＨＳ−ＤＳＣＨ初期容量割り当ての現在の解釈は、固定されたＭＡＣ−ｄ ＰＵＵ長のために使用されており、フレキシブルなＲＬＣには明らかに適していない。

現在のＨＳ−ＤＳＣＨデータフレームフォーマットは、異なるＭＡＣ−ｄ ＰＤＵ長をサポートしない。異なる長さのＭＡＣ−ｄ ＰＤＵの送信は、異なる長さのＰＤＵごとに新しいデータフレームが必要なので、非常に効率が悪くなる可能性もある（例えば、トランスポートネットワークのオーバヘッドが非常に高くなる可能性がある）。さらに、現在のフォーマットでは、４ビットの予備拡張部が、データフレーム内の各ＭＡＣ−ｄ ＰＤＵの前に挿入され、一般的なケースであるがオクテット配列されたＰＤＵの場合にオーバヘッドを著しく増大させる。現在のフォーマットは、フレキシブルなＲＬＣのアプローチに対処することが出来ない（例えば、１５００オクテット長のインタネットプロトコル（ＩＰ）パケットを含むＭＡＣ−ｄ ＰＤＵが送信される場合）。同時に、現在のＭＡＣ−ｄ ＰＤＵ長さインジケータは、ビットによる粒度を想定しており、ＭＡＣ−ｄ多重化の排除（removal）に伴いＭＡＣ−ｄ ＰＤＵがオクテット配列になる場合には必要ではない。さらに、ＭＡＣ−ｄ多重化の排除により、ＨＳ−ＤＳＣＨデータフレームが幾つかのタイプの論理チャネルマッピングをサポートしない場合に、幾つかの無線ベアラが必要とするトランスポートネットワーク接続の数が著しく増加する可能性もある（例えば、１つの接続の代わりに４つの接続が、シグナリング・無線ベアラ（ＳＲＢ）のために必要な可能性がある）。

本発明の目的は、少なくとも幾つかの上記の不都合を克服し、通信システムのために改善されたデータフロー制御を提供することである。

発明を解決するための手段

本明細書に記載される実施形態は、異なる長さのＰＤＵの送信を可能にし得る新しいＨＳ−ＤＳＣＨフレーミングプロトコルフォーマット（本明細書では以下、「ＨＳ−ＤＳＣＨフレーミングプロトコルタイプ２フォーマット」と呼ぶ）を提供する。１つの実施形態において、フレーミングプロトコルタイプ２フォーマットは、（所与の最大長のＰＤＵ数の組み合わせとは対照的に）ＭＡＣ−ｄ ＰＤＵクレジッドをオクテット数により特定する、新しいＨＳ−ＤＳＣＨフレーミングプロトコルタイプタイプ２の容量割り当ての制御フレームフォーマットを提供する。ＨＳ−ＤＳＣＨフレーミングプロトコルタイプタイプ２の容量割り当ての制御フレームは、未使用のクレジットの再利用を可能にすることによって、より大きなＭＡＣ−ｄ ＰＤＵ長もサポートする。

新しい容量割り当ての制御フレームフォーマットに加えて、ＨＳ−ＤＳＣＨフレーミングプロトコルタイプタイプ２のフレームフォーマットは、新しいＨＳ−ＤＳＣＨフレーミングプロトコルタイプタイプ２のデータフレームフォーマットを提供する。ＨＳ−ＤＳＣＨフレーミングプロトコルタイプタイプ２のデータフレームは、同じデータフレーム内での１つより多いＰＤＵ長を可能にする可能性がある。さらに、ＨＳ−ＤＳＣＨフレーミングプロトコルタイプタイプ２のデータフレームフォーマットは、１つの実施形態において、同じデータフレームでの異なる論理チャネルと関連付けられた幾つかのＰＤＵの送信を可能にし得る。

新しいＨＳ−ＤＳＣＨフレーミングプロトコルタイプタイプ２のフレームフォーマットは、以下のことを提供し得る。
・１５００オクテットまでの最大ＭＡＣ−ｄ ＰＤＵ長、そして、ＭＡＣ−ｄ ＰＤＵ長におけるオクテットによる粒度（octet granularity）が効果的にサポートされる
・利用されるトランスポートネットワークの最大送信単位（Maximum Transmission Unit）の制限を考慮する能力
・フレキシブルなＭＡＣ−ｄ ＰＤＵ長をサポートする能力
・進化型の高速パケットアクセス（ＨＳＰＡ）のより高いビットレートをサポートする能力（例えば、４２メガビット／秒（Ｍｂｐｓ）まで）
・トランスポートネットワーク層の小さなオーバヘッド（データフレームヘッダ及び制御フレーム長）、及び、
・将来のより簡単な拡張に役立つ、単一のデータフレームフォーマット及び制御フレームフォーマット

本明細書に記載するシステム及び装置を実装することが可能な例示的なネットワークの図である。 図１の基地局の例示的な図である。 図１の基地局と関連付けられ得るコンピュータ読取り可能な媒体の例示的な図である。 図１の無線ネットワークコントローラの例示的な図である。 一例としての実施形態に従った、データフレームを送信するための例示的なステップのフローチャートである。 一例としての実施形態に従った、高速ダウンリンク共有チャネル（ＨＳ−ＤＳＣＨ）のフレーミングプロトコルタイプタイプ２の容量割り当ての制御フレームの例示的な図である。 一例としての実施形態に従った、ＨＳ−ＤＳＣＨフレーミングプロトコルタイプタイプ２のデータフレームの各部の例示的な図である。 一例としての実施形態に従った、ＨＳ−ＤＳＣＨフレーミングプロトコルタイプタイプ２のデータフレームの各部の例示的な図である。 一例としての実施形態に従った、ＨＳ−ＤＳＣＨフレーミングプロトコルタイプタイプ２のデータフレームの各部の例示的な図である。 一例としての実施形態に従った、ＨＳ−ＤＳＣＨフレーミングプロトコルタイプタイプ２のデータフレームの各部の例示的な図である。 ノードがＨＳ−ＤＳＣＨフレーミングプロトコルタイプ２フォーマットをサポートすることが可能かどうかについて判定するための例示的なステップのフローチャートである。 一例としての実施形態に従った、例示的なフロー図である。

発明を実施するための実施形態

以下の詳細な説明は、添付図面を参照してなされる。異なる図面における同一の参照符号は、同一の又は同様の要素を示し得る。さらに、以下の詳細な説明は本発明を限定するものではない。

本明細書において説明する実施形態は、異なる長さのＰＤＵの送信を可能にする（「ＨＳ−ＤＳＣＨフレーミングプロトコルタイプ２」と呼ばれる）ＨＳ−ＤＳＣＨフレーミングプロトコルを提供する。

図１は、本明細書において説明するシステム及び装置を実装することが可能な例示的なネットワーク１００の図である。ネットワーク１００は、一群のユーザ機器（ＵＥ）１１０−１〜１１０−Ｌ（と総称され、幾つかの例では個別に「ユーザ機器１１０」と呼ばれる）と、無線アクセスネットワーク（ＲＡＮ：radio access network）１２０と、コアネットワーク（ＣＮ：core network）１３０と、を含み得る。簡略化するために、ここでは、４つのユーザ機器１１０と、１つの無線アクセスネットワーク１２０と、１つのコアネットワーク１３０が示されている。実際には、より多くの又はより少ないユーザ機器、無線ネットワーク、及び／又はコアネットワークが存在してもよい。

ユーザ機器１１０は、無線アクセスネットワーク１２０への／無線アクセスネットワーク１２０からの、音声及び／又はデータを送信／受信することが可能な１つ以上の装置を含んでもよい。１つの実施形態において、ユーザ機器１１０は、例えば、無線電話、携帯端末（ＰＤＡ：personal digital assistant）、ラップトップ等を含んでもよい。

無線アクセスネットワーク１２０は、ユーザ装置１１０及びコアネットワーク１３０へと、音声及び／又はデータを送信するための１つ以上の装置を含み得る。図示しているように、無線アクセスネットワーク１２０は、一群の基地局（ＢＳ：base station）１２２−１〜１２２−Ｍ（「基地局１２２」と総称され、幾つかの例では個別に「基地局１２２」と呼ばれる）と、一群の無線ネットワークコントローラ（ＲＮＣ：radio network controller）１２４−１〜１２４−Ｎ（「無線ネットワークコントローラ１２4」と総称され、幾つかの例では個別に「無線ネットワークコントローラ１２４」と呼ばれる）と、を含んでもよい。簡略化するために、ここでは、４つの基地局１２２と、２つの無線ネットワークコントローラ１２４とが図１に示されている。実際には、より多くの又はより少ない基地局及び／又は無線ネットワークコントローラが存在してもよい。

（「ノードＢ」とも呼ばれる）基地局１２２は、無線ネットワークコントローラ１２４から音声及び／又はデータを受信し、この音声及び／又はデータを、無線インタフェースを介してユーザ機器１１０へと送信する１つ以上の装置を含み得る。基地局１２２は、無線インタフェースを介してユーザ機器１１０から音声及び／又はデータを受信し、この音声及び／又はデータを、無線ネットワークコントローラ１２４又は他のユーザ機器１１０へと送信する１つ以上の装置も含んでもよい。

無線ネットワークコントローラ１２４は、基地局１２２を制御し管理する１つ以上の装置を含み得る。無線ネットワークコントローラ１２４は、無線ネットワークサービスの利用を管理するためにユーザデータの処理を行なう装置をも含み得る。無線ネットワークコントローラ１２４は、基地局１２２、他の無線ネットワークコントローラ１２４、及び／又はコアネットワーク１３０への／基地局１２２、他の無線ネットワークコントローラ１２４、及び／又はコアネットワーク１３０からの、音声及びデータを送信／受信してもよい。

無線ネットワークコントローラ１２４は、制御無線ネットワークコントローラ（ＣＲＮＣ）、ドリフト無線ネットワークコントローラ（ＤＲＮＣ）、又はサービス提供無線ネットワークコントローラ（ＳＲＮＣ）として動作してもよい。ＣＲＮＣは、基地局１２２のリソースを制御する役割を果たす。一方、ＳＲＮＣは、特定のユーザ機器１１０にサービスを提供し、このユーザ機器１１０への接続を管理する。同様に、ＤＲＮＣは、ＳＲＮＣと同様の役割を果たす（例えば、ＳＲＮＣと特定のユーザ機器１１０との間のトラフィックをルーティングしてもよい）。

図１に示すように、無線ネットワークコントローラ１２４は、Ｉｕｂインタフェースを介して基地局１２２に接続されてもよく、Ｉｕｒインタフェースを介して他の無線ネットワークコントローラ１２４に接続されてもよい。

コアネットワーク１３０は、回線交換及び／又はパケット交換ネットワークへの音声及び／又はデータを転送／受信する１つ以上の装置を含んでもよい。１つの実施形態において、コアネットワーク１３０は、例えば、移動交換センタ（ＭＳＣ：Mobile Switching Center）、ゲートウェイＭＳＣ（ＧＭＳＣ）、メディアゲートウェイ（ＭＧＷ）、サービス提供ＧＰＲＳ（General Packet Radio Service）サポートノード（ＳＧＳＮ）、ゲートウェイＧＰＲＳサポートノード（ＧＧＳＮ）、及び／又は、他の装置を含んでもよい。

幾つかの実施形態において、ネットワーク１００の１つ以上の構成要素は、ネットワーク１００の１つ以上の他の構成要素により実行されるものとして説明される１つ以上のタスクを実行してもよい。

図２は、一例としての実施形態に従った、基地局１２２−１の例示的な図である。基地局１２２−２〜１２２−Ｍは、同様に構成され得る。図２に示すように、基地局１２２−１は、アンテナ２１０と、送受信機（ＴＸ／ＲＸ）２２０と、処理システム２３０と、Ｉｕｂインタフェース（Ｉ／Ｆ）２４０と、を含み得る。基地局１２２−１は、追加的な構成要素、及び／又は、図２に示すものとは異なる構成要素を含んでもよい。

アンテナ２１０は、１つ以上の指向性アンテナ及び／又は全指向性アンテナを含んでもよい。送受信機２２０は、アンテナ２１０と関連付けられてもよく、アンテナ２１０を介して、ネットワーク１１０のようなネットワークにおいてシンボルシーケンスを送信及び／又は受信するための送受信機の回路を含んでもよい。

処理システム２３０は、基地局１２２−１の稼動を制御することができる。処理システム２３０はまた、送受信機２２０及びＩｕｂインタフェース２４０を介して受信される情報を処理することができる。処理システム２３０はさらに、接続の品質及び強度を測定し、フレーム誤り率（ＦＥＲ：frame error rate）を判定してもよく、この情報を無線ネットワークコントローラ１２４−１へと送信してもよい。図に示すように、処理システム２３０は、処理部２３２と、一群の優先度付きキュー２３４と、論理チャネル識別子（ＩＤ）から優先度付きキューへのマッパ２３６と、を含み得る。当然のことながら、処理システム２３０は、追加的な構成要素、及び／又は、図２に示すものとは異なる構成要素を含んでもよい。

処理部２３２は、送受信機２２０及びＩｕｂインタフェース２４０を介して受信される情報を処理することができる。処理は、例えば、データ変換、前方誤り訂正（ＦＥＣ：forward error correction）、レート適応、広帯域符号分割多重アクセス（ＷＣＤＭＡ：Wideband Code Division Multiple Access）、拡散／逆拡散、位相偏移変調（ＱＰＳＫ：quadrature phase shift keying）等を含んでもよい。さらに、処理部２３２は、制御メッセージ及び／又はデータメッセージ（例えば、ＨＳ−ＤＳＣＨデータフレーム）を生成してもよく、これら制御メッセージ及び／又はデータメッセージを、送受信機２２０及び／又はＩｕｂインタフェース２４０を介して送信させてもよい。処理部２３２はまた、送受信機２２０及び／又はＩｕｂインタフェース２４０から受信される制御メッセージ及び／又はデータメッセージを処理してもよい。

優先度付きキュー２３４は、（例えば、ＰＤＵの形態で）ユーザ機器へと送信される情報、及び／又は、ユーザ機器１１０から受信された情報を格納することができる。１つの実施形態において、基地局１２２−１と関連付けられた各ユーザ機器１１０は、優先度付きキュー２３４からの１つ以上の優先度付きキューと関連付けられ得る。優先度付きキューは、例えば、あるユーザ機器１１０のためにＭＡＣ−ｄフローが確立された場合に、そのユーザ機器１１０のために初期化されてもよい。

論理チャネル識別子から優先度付きキューへのマッパ２３６は、受信された論理チャネル識別子を、優先度付きキュー識別子へとマッピングすることができる。１つの実施形態において、ＨＳ−ＤＳＣＨフレーミングプロトコルタイプ２のデータフレームは、１つ以上の論理チャネル識別子を、データフレームに格納された１つ以上のＰＤＵと関連付けてもよい。基地局１２２−１は、ＰＤＵを格納するために、論理チャネル識別子を用いて、優先度付きキュー２３４から適切な優先度付きキューを識別することができる。

Ｉｕｂインタフェース２４０は、基地局１２２−１が無線ネットワークコントローラ１２４−１へとデータを送信することを可能にし、かつ無線ネットワークコントローラ１２４−１からデータを受信することを可能にする１つ以上のラインカードを含んでもよい。

幾つかの実施形態において、基地局１２２−１の１つ以上の構成要素は、基地局１２２−１の１つ以上の他の構成要素により実行されるものとして説明されるタスクを実行してもよい。

図３は、基地局１２２−１のような基地局と関連付けられ得るコンピュータ読取り可能な媒体３００の例示的な図である。１つのコンピュータ読取り可能な媒体について以下に説明するが、当然のことながら、コンピュータ読取り可能な媒体３００は、基地局１２２−１にローカルに格納され、又は１つ以上の異なる離れた場所に格納され得る複数のコンピュータ読取り可能な媒体を含んでもよい。

図に示すように、コンピュータ読取り可能な媒体３００は、一群のエントリを以下の例示的なフィールド、即ち、論理チャネル識別子フィールド３１０、及び優先度付きキュー識別子フィールド３２０において保持してもよい。コンピュータ読取り可能な媒体３００は、追加的な情報、又は、図３に示される情報とは異なる情報を含んでもよい。

論理チャネル識別子フィールド３１０は、ユーザ機器１１０−１のようなユーザ機器と関連付けられた論理チャネルを識別する文字のシーケンスを格納することができる。１つの実施形態において、文字のシーケンスは、この特定の基地局のために一意であってよい。優先度付きキュー識別子フィールド３２０は、優先度付きキュー２３４内の優先度付きキューを識別する文字のシーケンスを格納してもよい。１つの実施形態において、優先度付きキュー２３４内の各優先度付きキューは、当該優先度付きキューについての識別子として機能する文字の一意のシーケンスと関連付けられ得る。

従って、コンピュータ読取り可能な媒体３００を介して、基地局１２２−１は、受信される論理チャネル識別子に基づいて、優先度付きキューを識別することができる。

図４は、一例としての実施形態に従った、無線ネットワークコントローラ１２４−１の例示的な図である。無線ネットワークコントローラ１２４−２も、同様に構成され得る。図４に示すように、無線ネットワークコントローラ１２４−１は、処理システム４１０、Ｉｕｂインタフェース４２０、Ｉｕｒインタフェース４３０、及び／又は、他のインタフェース４４０を含み得る。無線ネットワークコントローラ１２４−１は、追加的な構成要素、及び／又は、図４に示す構成要素とは異なる構成要素を含んでもよい。

処理システム４１０は、無線ネットワークコントローラ１２４−１の動作を制御してもよい。図に示すように、処理システム４１０は、Ｉｕｂインタフェース４２０と、Ｉｕｒインタフェース４３０と、他のインタフェース４４０との間のプロトコル交換を行なう処理部４１２を含んでもよい。さらに、処理部４１２は、制御メッセージ及び／又はデータメッセージを生成してもよく、これら制御メッセージ及び／又はデータメッセージを、インタフェース４２０〜４４０を介して送信してもよい。処理部４１２はまた、インタフェース４２０〜４４０から受信される制御メッセージ及び／又はデータメッセージを処理してもよい。

Ｉｕｂインタフェース４２０は、無線ネットワークコントローラ１２４−１が基地局１２２−１へと制御メッセージ及び／又はデータメッセージを送信することを可能にし、かつ基地局１２２−１から制御メッセージ及び／又はデータメッセージを受信することを可能にする１つ以上のラインカードを含み得る。Ｉｕｒインタフェース４３０は、無線ネットワークコントローラ１２４−１が無線ネットワークコントローラ１２４−２のような、他の無線ネットワークコントローラへと制御メッセージ及び／又はデータメッセージを送信することを可能にし、かつ無線ネットワークコントローラ１２４−２のような、他の無線ネットワークコントローラから制御メッセージ及び／又はデータメッセージを受信することを可能にする１つ以上のラインカードを含み得る。他のインタフェース４４０は、他の装置及び／又はネットワークへのインタフェースを含み得る。例えば、他のインタフェース４４０は、回線交換音声ネットワークへのコアネットワーク・インタフェースであるＩｕｃｓインタフェースと、パケット交換データネットワークへのコアネットワーク・インタフェースであるＩｕｐｓインタフェースとを、含んでもよい。

幾つかの実施形態において、無線ネットワークコントローラ１２４−１の１つ以上の構成要素は、無線ネットワークコントローラ１２４−１の１つ以上の他の構成要素により実行されるものとして説明されるタスクを実行してもよい。

図５は、一例としての実施形態に従った、データフレームを送信するための例示的なステップのフローチャートである。１つの実施形態において、図５に記載するステップの各部は、基地局１２２−１のような基地局によって実行されてもよく、ステップのある部分は、無線ネットワークコントローラ１２４−１のような無線ネットワークコントローラによって実行されてもよい。他の実施形態において、以下に記載する例示的なステップの幾つか又は全ては、他の装置によって、又は装置の組み合わせによって実行されてもよい。

例示的なステップは、基地局１２２−１がＨＳ−ＤＳＣＨフレーミングプロトコルタイプ２の容量割り当て（CAPACITY ALLOCATION）の制御フレームを生成するステップから、開始され得る（ブロック５０５）。１つの実施形態において、基地局１２２−１は、無線ネットワークコントローラ１２４−１からのＨＳ−ＤＳＣＨ容量要求に応じて、又は、任意の他の時点に、ＨＳ−ＤＳＣＨフレーミングプロトコルタイプ２の容量割り当ての制御フレームを生成してもよい。特に、ＨＳ−ＤＳＣＨフレーミングプロトコルタイプ２の容量割り当ての制御フレームは、ＭＡＣ−ｄ ＰＤＵクレジットを、ＰＤＵの数によってよりもオクテットで特定することができる。

図６は、一例としての実施形態に従った、ＨＳ−ＤＳＣＨフレーミングプロトコルタイプタイプ２の容量割り当ての制御フレーム６００の例示的な図である。図に示すように、ＨＳ−ＤＳＣＨフレーミングプロトコルタイプ２の容量割り当ての制御フレーム６００は、輻輳ステータスの情報エレメント６１０と、共通トランスポートチャネル優先度インジケータ（ＣｍＣＨ−ＰＩ：Common Transport Channel Priority Indicator）の情報エレメント６２０と、ＭＡＣ−ｄ ＰＤＵクレジットの情報エレメント６３０と、ＨＳ−ＤＳＣＨ間隔の情報エレメント６４０と、ＨＳ−ＤＳＣＨ繰返し周期の情報エレメント６５０と、予備拡張部の情報エレメント６６０と、を含み得る。他の実施形態において、ＨＳ−ＤＳＣＨフレーミングプロトコルタイプ２の容量割り当ての制御フレーム６００は、追加的な情報エレメント、又は、図６に示す情報エレメントとは異なる情報エレメントを保持してもよい。

輻輳ステータスの情報エレメント６１０は、輻輳ステータスが検出されているかどうかについて示す情報を含み得る。共通トランスポートチャネル優先度インジケータの情報エレメント６２０は、無線ネットワークコントローラ１２４−１から転送されるデータフレームの相対的な優先度を示す情報を含み得る。ＭＡＣ−ｄ ＰＤＵクレジットの情報エレメント６３０は、ＨＳ−ＤＳＣＨフレーミングプロトコルタイプ２の容量割り当ての制御フレーム６００によって、１つのＨＳ−ＤＳＣＨ間隔の間に無線ネットワークコントローラが送信することが許可される、ＭＡＣ−ｄ ＰＤＵのオクテット数を示す情報を含み得る。１つの実施形態において、ＭＡＣ−ｄ ＰＤＵクレジットのための値の情報エレメントは、例えば、０〜１６，７７７，２１５までの範囲であってもよく、この場合、「０」は送信停止を表し、「１６，７７７，２１５」は無制限の送信を表し得る。ＭＡＣ−ｄ ＰＤＵクレジットの情報エレメントのフィールド長は、２４ビットであってもよい。

代替的な実施形態において、ＭＡＣ−ｄ ＰＤＵクレジットの情報エレメント６３０は、２０ビットであってもよく、その場合、残りの４ビットのうちの３ビットは予備ビットとして用いられ、１ビットは未使用のクレジットのオクテットを次の間隔（next interval）で無線ネットワークコントローラ１２４−１により再利用できるか否かについて示すために用いられてもよい。

ＨＳ−ＤＳＣＨ間隔の情報エレメント６４０は、ＨＳ−ＤＳＣＨフレーミングプロトコルタイプ２の容量割り当ての制御フレーム６００においてＨＳ−ＤＳＣＨクレジットがその間に利用されてもよいと認められる時間間隔、を表す情報を格納し得る。ＨＳ−ＤＳＣＨ繰返し周期の情報エレメント６５０は、ＨＳ−ＤＳＣＨフレーミングプロトコルタイプ２の容量割り当ての制御フレーム６００におけるＨＳ−ＤＳＣＨクレジットが用いられてもよい後続の間隔（intervals）の数を表す情報を格納してもよい。予備拡張部の情報エレメント６６０は、ＨＳ−ＤＳＣＨフレーミングプロトコルタイプ２の容量割り当ての制御フレーム６００に追加され得る将来の情報エレメントのためのプレースホルダであってもよい。

従って、一例としての実施形態によれば、新しい「ＭＡＣ−ｄ ＰＤＵクレジット」の情報エレメント６３０がＨＳ−ＤＳＣＨ容量割り当ての制御フレームに導入され、これが旧来の「ＨＳ−ＤＳＣＨクレジット」のフィールドを置換する。（ＰＤＵ数ではなく）オクテットの粒度を有するＭＡＣ−ｄ ＰＤＵクレジットの情報エレメント６３０によって、（例えば、残っているオクテットの量が、待機中のＭＡＣ−ｄ ＰＤＵの長さより少ないために）ＨＳ−ＤＳＣＨ間隔の終わりに、１つ以上のオクテットが、ＭＡＣ−ｄ ＰＤＵの送信のために利用され得ない状況が起こる。ＨＳ−ＤＳＣＨ繰返し周期の情報エレメント６５０が、繰返し周期が１よりも大きい、又は０であることを示す場合には、「ＭＡＣ−ｄ ＰＤＵクレジット」は、各ＨＳ−ＤＳＣＨ間隔において、トランスポートネットワークのフローに付与されてもよい。この状況において、無線ネットワークコントローラは、次のＨＳ−ＤＳＣＨ間隔の開始時にこれら未使用のクレジットを再利用することができる。

図５に戻り、基地局１２２−１は、ＨＳ−ＤＳＣＨフレーミングプロトコルタイプ２の容量割り当ての制御フレーム（例えば、ＨＳ−ＤＳＣＨフレーミングプロトコルタイプ２の容量割り当ての制御フレーム６００）を、無線ネットワークコントローラ１２４−１へと転送し得る（ブロック５１０）。例えば、基地局１２２−１は、ＨＳ−ＤＳＣＨフレーミングプロトコルタイプ２の容量割り当ての制御フレームを、Ｉｕｂインタフェース２４０を介して無線ネットワークコントローラ１２４−１へと転送してもよい。

無線ネットワークコントローラ１２４−１は、ＨＳ−ＤＳＣＨフレーミングプロトコルタイプ２の容量割り当ての制御フレームを受信し得る（ブロック５１５）。例えば、無線ネットワークコントローラ１２４−１は、Ｉｕｂインタフェース４２０を介して、ＨＳ−ＤＳＣＨフレーミングプロトコルタイプ２の容量割り当ての制御フレームを受信してもよい。ＨＳ−ＤＳＣＨフレーミングプロトコルタイプ２の容量割り当ての制御フレームの受信への応答として、無線ネットワークコントローラ１２４−１は、ＨＳ−ＤＳＣＨフレーミングプロトコルタイプ２のデータフレームを生成し得る（ブロック５２０）。特に、ＨＳ−ＤＳＣＨフレーミングプロトコルタイプ２のデータフレームは、同じ長さのＰＤＵブロックを格納してもよく、その場合、１つのブロックのＰＤＵは、他のブロックのＰＤＵと長さが異なってもよい。

図７Ａは、一例としての実施形態に従った、ＨＳ−ＤＳＣＨフレーミングプロトコルタイプタイプ２のデータフレーム７００の例示的な図である。図に示すように、ＨＳ−ＤＳＣＨフレーミングプロトコルタイプ２のデータフレーム７００は、ヘッダ７０１とペイロード７１５とを含み得る。ヘッダ７０１は、ヘッダ巡回冗長検査（ＣＲＣ：Cyclic Redundancy Checksum）の情報エレメント７０２と、フレームタイプ（ＦＴ）の情報エレメント７０３と、フレームシーケンス（Sec．）番号の情報エレメント７０４と、共通トランスポートチャネル優先度インジケータ（ＣｍＣＨ−ＰＩ）の情報エレメント７０５と、フラッシュの情報エレメント７０６と、論理（Log．）チャネル（Ch．）識別子（ＩＤ）の情報エレメント７０７と、ユーザバッファサイズの情報エレメント７０８と、ＰＤＵブロック総数の情報エレメント７０９と、ＰＤＵブロック記述の数（＃）の情報エレメント７１０（例えば、各ブロックがブロック内でのＭＡＣ−ｄ ＰＤＵ長の情報エレメント７１１及びブロック内でのＰＤＵ数（＃ＰＤＵ）の情報エレメント７１２と関連付けられる場合）と、を含み得る。他の実施形態において、ヘッダ７０１は、追加的な情報エレメント、及び／又は、図７Ａに示すものとは異なる情報エレメントを含んでもよい。

ヘッダＣＲＣの情報エレメント７０２は、計算されたＣＲＣを、データフレーム７００のヘッダ７０１に格納し得る。フレームタイプの情報エレメント７０３は、フレーム７００がデータフレーム又は制御フレームのいずれかを示す情報を格納し得る。フレームシーケンス番号の情報エレメント７０４は、ＭＡＣ−ｄフロー内でのデータフレーム７００についてのフレームシーケンス番号を表す値を格納し得る。共通トランスポートチャネル優先度インジケータの情報エレメント７０５は、データフレーム７００の相対的な優先度を示す情報を含み得る。フラッシュの情報エレメント７０６は、ＤＲＮＣが同じ送信ベアラ上でデータフレーム７００より前に受信された対応する優先度付きキューから、全ＭＡＣ−ｄ ＰＤＵを削除するべきか否かについて示す情報を格納し得る。論理チャネル識別子の情報エレメント７０７は、複数の論理チャネルが同じトランスポートネットワークフローにおいて担われる場合に論理チャネルのインスタンスを識別する情報を格納し得る。１つの実施形態において、論理チャネル識別子の情報エレメント７０７は、例えば、０〜１５の間の値を格納してもよく、その場合、値０〜１４は論理チャネル１〜１５を識別し、値１５は将来の利用のために予約され得る。論理チャネル識別子の情報エレメント７０７のフィールド長は、一例としての実施形態において４ビットであってもよい。ユーザバッファサイズの情報エレメント７０８は、所与の共通トランスポートチャネル優先度インジケータのレベルについて、バッファサイズ（例えばバッファ内のデータ量）をオクテットで表す情報を格納し得る。

ＰＤＵブロック総数の情報エレメント７０９は、データフレーム７００内でのＰＤＵブロックの総数を表す情報を格納し得る。ＰＤＵブロックは、１つ以上の同じ長さのＰＤＵとして定義されてもよい。各ＰＤＵブロックは、ブロック内でのＰＤＵの長さ、及びＰＤＵ数によって記述され得る。順序通りの伝達が望まれる状況では、同じ長さの１つ以上のＰＤＵを有するブロックが、データフレーム７００内に含まれてもよい。例えば、最大ＰＤＵ長が完全なＩＰパケットよりも著しく小さい場合に、ＩＰパケットは、それぞれ同じ最大ＰＤＵ長である複数のＰＤＵのシーケンスにセグメント化されてもよい。１つの実施形態において、ＰＤＵブロックは、ＩＰパケットと同じ長さ（例えば、１５００オクテット）のＰＤＵ長をサポートしてもよい。ＰＤＵブロック総数の情報エレメント７０９は、例えば、０〜３１の間の値を格納してもよく、その場合、値「０」は無効値を表してもよい。ＰＤＵブロック総数の情報エレメント７０９のフィールド長は、一例としての実施形態において５ビットであってもよい。

先に示したように、データフレーム７００内の各ＰＤＵブロックは、ＰＤＵブロック記述の情報エレメント７１０と関連付けられてもよい。ＰＤＵブロック記述の情報エレメント７１０は、ブロック内でのＭＡＣ−ｄ ＰＤＵ長の情報エレメント７１１、及び、ブロック内でのＰＤＵ数（＃）の情報エレメント７１２を含み得る。ブロック内でのＭＡＣ−ｄ ＰＤＵ長の情報エレメント７１１は、この特定のブロック内での各ＭＡＣ−ｄ ＰＤＵの長さを表す情報を格納し得る。長さは、オクテットで提供されることができる。１つの実施形態において、ブロック内でのＭＡＣ−ｄ ＰＤＵ長の情報エレメント７１１は、例えば、０〜２０４７の間の値であってもよく、その場合、値「０」は無効値を表してもよい。ブロック内でのＭＡＣ−ｄ ＰＤＵ長の情報エレメント７１１のフィールド長は、一例としての実施形態において１１ビットであってもよい。ブロック内でのＰＤＵ数の情報エレメント７１２は、例えば、０〜３１の間の値を格納してもよく、その場合、値「０」は無効値を表してもよい。ブロック内でのＰＤＵ数の情報エレメント７１２のフィールド長は、一例としての実施形態において５ビットであってもよい。

ペイロード７１５は、１つ以上のＰＤＵブロック７１６と、新たな情報エレメント（ＩＥ）フラグの情報エレメント７１７と、遅延基準時間（ＤＲＴ：Delay Reference Time）の情報エレメント７１８と、予備拡張部の情報エレメント７１９と、ペイロードＣＲＣの情報エレメント７２０と、を含み得る。他の実施形態において、ペイロード７１５は、追加的な情報エレメント、及び／又は、図７Ａに示すものと異なる情報エレメントを含んでもよい。

ペイロード７１５におけるＰＤＵブロック７１６の順序は、ヘッダ７０１内のＰＤＵブロック記述の情報エレメントの対応する順序に従ってもよい。図７Ａに示す例示的な構成において、ヘッダ７０１は、ＰＤＵブロック１〜ｎについての記述を含む。従って、ペイロード７１５は、０〜ｎまで順序付けられたｎ個のＰＤＵブロックを含み得る。先に示したように、各ＰＤＵブロックは、１つ以上の同じ長さのＰＤＵを含み得る。しかし、１つのブロック内でのＰＤＵの長さは、ペイロード７１５における他のブロック内でのＰＤＵの長さと異なってもよい。

新情報エレメントフラグの情報エレメント７１７は、少なくとも１つの新しい情報エレメントがデータフレーム７００内に存在する場合に、情報（例えば、１つ以上のフラグ）を格納し得る。各フラグは、新情報エレメントフラグの情報エレメント７１７に従ってどの新しい情報エレメントが存在するのかについて示してもよい。遅延基準時間の情報エレメント７１８は、動的な遅延測定のために用いられる情報を格納し得る。予備拡張部の情報エレメント７１９は、データフレーム６００に追加されてもよい将来の情報エレメントのためのプレースホルダであってもよい。ペイロードＣＲＣの情報エレメント７２０は、計算されたＣＲＣを、データフレーム７００のペイロード７１５に格納し得る。

図７Ａに示す例示的な構成の代替案として、ブロック内でのＭＡＣ−ｄ ＰＤＵ長の情報エレメントは、４ビットのＭＡＣ−ｄ ＰＤＵ長の粒度をサポートできるようにするために、１ビット分増加されてもよい。この代替的な実施形態は、ＭＡＣ−ｄ ＰＤＵ多重化を可能にすることによって、レガシーのユーザ機器をサポートしてもよい。ＭＡＣ−ｄ多重化を除去することが無線アクセスネットワーク内で許容されない場合には、ブロック内でのＭＡＣ−ｄ ＰＤＵ長の情報エレメントの長さは、長さを４ビットの単位で表すために増加され、論理チャネル識別子の情報エレメントは削除されてもよい。

幾つかの状況において（例えば、データフレームが異なる長さの小さいＰＤＵを含む場合に）、１ビットの「詳細情報」（“more information”）の情報エレメントが、ヘッダ７０１におけるＰＤＵブロック記述の情報エレメント７１０内に含まれてもよい。この代替的な実施形態についての代替的なＰＤＵ記述の情報エレメント７２５の例示的な図が、図７Ｂに示されている。図示している、データフレーム７００からの、ブロック内でのＭＡＣ−ｄ ＰＤＵ長の情報エレメントと、ブロック内でのＰＤＵ数（＃）の情報エレメントとが、「詳細情報」（ＭＩ）の情報エレメント７２６で補完されており、この詳細情報はブロック内でのＰＤＵに関する情報を格納し得る。１つの実施形態において、「詳細情報」の情報エレメント７２６が０の値を格納する場合に、関連付けられるブロック内でのＭＡＣ−ｄ ＰＤＵ長の情報エレメントは７ビットの長さであってもよく、所与のブロック内でのＰＤＵ数は１であってもよい。一方、「詳細情報」の情報エレメント７２６が１の値を格納する場合に、次のオクテットの４ビットは長さを示してもよく（全部で１３ビット）、他の４ビットはＰＤＵ数を示してもよい。

図７Ｃは、一例としての実施形態に従った、ＨＳ−ＤＳＣＨフレーミングプロトコルタイプタイプ２のデータフレーム７３０の例示的な図である。本実施形態において、各ブロックについてのＰＤＵ記述の情報エレメント７１０（即ち、ブロック内でのＭＡＣ−ｄ ＰＤＵ長の情報エレメント７１１、及びブロック内でのＰＤＵ数の情報エレメント７１２）は、（データフレーム７００におけるような）ヘッダ７０１の代わりに、ペイロード７１５に割り振られる。図に示すように、所与のブロックのためのＰＤＵ記述の情報エレメント７１０は、このブロックのためのＰＤＵ７１６の直前に置かれてもよい。

他の実施形態において、各ＭＡＣ−ｄ ＰＤＵについての長さインジケータ（例えば、１２ビットのインジケータ）は、ＨＳ−ＤＳＣＨフレーミングプロトコルタイプ２のデータフレームのヘッダ又はペイロード内に含まれてもよい。ヘッダ部分７４０内に長さインジケータを備える、例示的なＨＳ−ＤＳＣＨフレーミングプロトコルタイプ２のデータフレーム７３５が、図７Ｄに示されている。図示しているように、ＨＳ−ＤＳＣＨフレーミングプロトコルタイプ２のデータフレーム７３５のヘッダ７４０は、ヘッダ巡回冗長検査（ＣＲＣ）の情報エレメント７０２と、フレームタイプ（ＦＴ）の情報エレメント７０３と、フレームシーケンス（Seq．）番号の情報エレメント７０４と、共通トランスポートチャネル優先度インジケータ（ＣｍＣＨ−ＰＩ）の情報エレメント７０５と、フラッシュの情報エレメント７０６と、論理（Log．）チャネル（ch．）識別子（ＩＤ）の情報エレメント７０７と、ユーザバッファサイズの情報エレメント７０８と、ＰＤＵ総数の情報エレメント７４１と、複数のＭＡＣ−ｄ ＰＤＵ長さインジケータの情報エレメント７４２（例えば、データフレーム７３５内のＰＤＵごとに１つ）と、を含み得る。他の実施形態において、ヘッダ７４０は、追加的な情報エレメント、及び／又は、図７Ｄに示す情報エレメントとは異なる情報エレメントを含んでもよい。

ヘッダ巡回冗長検査の情報エレメント７０２と、フレームタイプの情報エレメント７０３と、フレームシーケンス番号の情報エレメント７０４と、共通トランスポートチャネル優先度インジケータの情報エレメント７０５と、フラッシュの情報エレメント７０６と、論理チャネル識別子の情報エレメント７０７と、ユーザバッファサイズの情報エレメント７０８とは、図７Ａに関して先に記述された情報と同様の情報を含み得る。ＰＤＵ総数の情報エレメント７４１は、データフレーム７３５内でのＰＤＵ数（又は量）を表す情報を格納し得る。各ＭＡＣ−ｄ ＰＤＵ長さインジケータの情報エレメント７４２は、ペイロード７４５内での対応するＰＤＵ長さを（例えば、オクテットで）表す情報を格納し得る。例えば、ＰＤＵ＃１が８オクテットの長さを有する場合に、ＰＤＵ＃１のためのＭＡＣ−ｄ ＰＤＵ長さインジケータの情報エレメントは、８オクテットを示す値を格納し得る。

ペイロード７４５は、１つ以上のＰＤＵ７４６と、新たな情報エレメント（ＩＥ）フラグの情報エレメント７１７と、遅延基準時間（ＤＲＴ）の情報エレメント７１８と、予備拡張部の情報エレメント７１９と、ペイロードＣＲＣの情報エレメント７２０と、を含み得る。他の実施形態において、ペイロード７４５は、追加的な情報エレメント、及び／又は、図７Ｄに示すものとは異なる情報エレメントを含んでもよい。

ペイロード７４５において、各ＰＤＵは、並べ替えを避けるために自身の元の順序で配置され得る。ＰＤＵの順序は、ヘッダ７４０内のＭＡＣ−ｄ ＰＤＵ長さインジケータ７４２の順序に対応してもよい。新情報エレメントフラグの情報エレメント７１７と、遅延基準時間の情報エレメント７１８と、予備拡張部の情報エレメント７１９と、ペイロードＣＲＣの情報エレメント７２０とは、図７Ａに関して先に記述された情報と同様の情報を含み得る。

幾つかの実施形態において、論理チャネル識別子は、図７Ａのデータフレーム７００のような、ＨＳ−ＤＳＣＨフレーミングプロトコルタイプ２のデータフレーム全体についても同じであってもよい。他の実施形態において、特定のＨＳ−ＤＳＣＨフレーミングプロトコルタイプ２のデータフレームは、１つより多い論理チャネル識別子と関連付けられてもよい。図７Ｅは、１つより多い論理チャネル識別子と関連付けられたＨＳ−ＤＳＣＨフレーミングプロトコルタイプ２のデータフレーム７５０の例示的な図である。図示しているように、ＨＳ−ＤＳＣＨフレーミングプロトコルタイプ２のデータフレーム７５０のヘッダ７５５は、ヘッダ巡回冗長検査（ＣＲＣ）の情報エレメント７０２と、フレームタイプ（ＦＴ）の情報エレメント７０３と、フレームシーケンス（Seq．）番号の情報エレメント７０４と、共通トランスポートチャネル優先度インジケータ（ＣｍＣＨ−ＰＩ）の情報エレメント７０５と、フラッシュの情報エレメント７０６と、ユーザバッファサイズの情報エレメント７０８と、ＰＤＵブロック総数の情報エレメント７０９と、複数のＭＡＣ−ｄ ＰＤＵ記述の情報エレメント７５１（例えば、データフレーム７５０内のＰＤＵごとに１つ）と、を含んでもよく、その場合、特定のＰＤＵのためのＭＡＣ−ｄ ＰＤＵ記述の情報エレメント７５１は、ＰＤＵのための論理チャネル識別子の情報エレメント７５２と、ＭＡＣ−ｄ ＰＤＵ長さインジケータの情報エレメント７５３とを含む。他の実施形態において、ヘッダ７５５は、追加的な情報エレメント、及び／又は、図７Ｅに示すものとは異なる情報エレメントを含んでもよい。

ヘッダ巡回冗長検査の情報エレメント７０２と、フレームタイプの情報エレメント７０３と、フレームシーケンス番号の情報エレメント７０４と、共通トランスポートチャネル優先度インジケータの情報エレメント７０５と、フラッシュの情報エレメント７０６と、ユーザバッファサイズの情報エレメント７０８と、ＰＤＵブロック総数の情報エレメント７０９とは、図７Ａに関して先に記述された情報と同様の情報を含み得る。ＰＤＵのための論理チャネル識別子の情報エレメント７５２は、ＰＤＵのための論理チャネル・インスタンスを識別する情報を格納し得る。１つの実施形態において、論理チャネル識別子の情報エレメント７５２は、例えば、０〜１５の間の値を格納してもよく、その場合、０から１４までの値は論理チャネル１〜１５を示し、値「１５」は将来の利用のために予約されてもよい。論理チャネル識別子の情報エレメント７５２のフィールド長は、一例としての実施形態において４ビットであってもよい。ＰＤＵのためのＭＡＣ−ｄ ＰＤＵ長さインジケータの情報エレメント７５３は、ペイロード７６０内の対応するＰＤＵの長さを（例えば、オクテットで）表す情報を格納し得る。例えば、ＰＤＵ＃１が８オクテットの長さを有する場合に、ＰＤＵ＃１のためのＭＡＣ−ｄ ＰＤＵ長さインジケータの情報エレメント７５３は、８オクテットを示す値を格納し得る。

ペイロード７６０は、１つ以上のＰＤＵ７６１と、新たな情報エレメント（ＩＥ）フラグの情報エレメント７１７と、遅延基準時間（ＤＲＴ）の情報エレメント７１８と、予備拡張部の情報エレメント７１９と、ペイロードＣＲＣの情報エレメント７２０と、を含み得る。他の実施形態において、ペイロード７６０は、追加的な情報エレメント、及び／又は、図７Ｅに示すものとは異なる情報エレメントを含んでもよい。

ペイロード７６０において、各ＰＤＵは並べ替えを避けるために自身の元の順序で配置され得る。ＰＤＵ７１６の順序は、ヘッダ７５５内のＭＡＣ−ｄ ＰＤＵ長さインジケータ７５３の順序に対応してもよい。新情報フラグの情報エレメント７１７と、遅延基準時間の情報エレメント７１８と、予備拡張部の情報エレメント７１９と、ペイロードＣＲＣの情報エレメント７２０とは、図７Ａに関して先に記述された情報と同様の情報を含み得る。

図５に戻り、無線ネットワークコントローラ１２４−１は、ＨＳ−ＤＳＣＨフレーミングプロトコルタイプ２のデータフレーム（例えば、データフレーム７００、７３０、７３５、又は７５０）を、基地局１２２−１へと転送し得る（ブロック５２５）。例えば、無線ネットワークコントローラ１２４−１は、ＨＳ−ＤＳＣＨフレーミングプロトコルタイプ２のデータフレームを、Ｉｕｂインタフェース４２０を介して基地局１２２−１へと転送し得る。

基地局１２２−１は、無線ネットワークコントローラ１２４−１から、ＨＳ−ＤＳＣＨフレーミングプロトコルタイプ２のデータフレームを受信してもよい。例えば、基地局１２２−１は、ＨＳ−ＤＳＣＨフレーミングプロトコルタイプ２のデータフレームを、Ｉｕｂ２４０を介して受信してもよい。基地局１２２−１は、ＨＳ−ＤＳＣＨフレーミングプロトコルタイプ２のデータフレームから（例えば、ＨＳ−ＤＳＣＨフレーミングプロトコルタイプ２のデータフレーム７００のヘッダ７０１内の論理チャネル識別子の情報エレメント７０７から）論理チャネル識別子を抽出し、ＨＳ−ＤＳＣＨフレーミングプロトコルタイプ２のデータフレームを解析して、抽出された論理チャネル識別子を優先度付きキュー識別子へとマッピングし得る（ブロック５３５）。例えば、基地局１２２−１は、論理チャネル識別子から優先度付きキューへのマッパ２３６を介して、抽出された論理チャネル識別子を用いることで、優先度付きキュー２３４内にあるデータフレームのＰＤＵについての優先度付きキューのための識別子を（例えば、コンピュータ読取り可能な媒体３００を介して）ルックアップしてもよい。ＨＳ−ＤＳＣＨフレーミングプロトコルタイプ２のデータフレームが複数の論理チャネル識別子を含む状況（例えば、図７Ｅのデータフレーム７５０）では、基地局１２２−１は、論理チャネル識別子と関連づけられたＰＤＵについての優先度付きキューを識別するために、複数のルックアップ動作を実行してもよい。

先行技術において、高速ダウンリンクパケットアクセス（ＨＳＤＰＡ）の基地局は、複数の優先度付きキューを保持している。優先度付きキューのインスタンスは、ノードＢ Ａｐｐｌｉｃａｔｉｏｎ Ｐａｒｔ（ＮＢＡＰ）メッセージを介してＭＡＣ−ｄ ＰＤＵフローが確立された場合に初期化される。さらに、１つの優先度付きキューは、幾つかの論理チャネル（又は無線ベアラ）にサービスを提供してもよい。先行技術は、ユーザデータ送信のためＨＳ−ＤＳＣＨ無線リンク／無線ベアラを用いる論理チャネル（又は無線ベアラ）への優先度付きキューのマッピングをサポートするために、基地局にシグナリングすることを含んでいない。この結果、優先度付きキュー識別子は各ＰＤＵのための論理チャネルと共にユーザ機器へ送信されるので、ユーザ機器は、１）どの論理チャネルにＰＤＵが所属するのか、かつ、２）どの優先度付きキューがスケジューリング及び並べ替えのために用いられたのか、について判断することができる。これは、無線インタフェース上でのオーバヘッドが不必要に大きいことに繋がる。

全く対照的に、本明細書に記載する実施形態において、無線ネットワークコントローラは、基地局へと、論理チャネルと優先度付きキューとの間のマッピングを提供する制御メッセージを送信することができる。このマッピングは、制御無線ネットワークコントローラ／サービス提供無線ネットワークコントローラ（ＣＲＮＣ／ＳＲＮＣ）とユーザ機器との間のシグナリングに関しては、既に先行技術にも含まれている。そして、基地局にも同じマッピングをシグナリングすることにより、基地局からユーザ機器へ送信される各ＰＤＵには、論理チャネルの識別のみが追加される必要がある。そうすると、ユーザ機器は、論理チャネル識別子から正しい優先度付きキュー識別子を判定し得る。従って、無線インタフェースにおけるオーバヘッドを低減することができる。

表１は、旧ＨＳ−ＤＳＣＨデータフレームフォーマット（即ち、ＨＳ−ＤＳＣＨフレーミングプロトコルタイプ１のデータフレーム）と、新ＨＳ−ＤＳＣＨデータフレームフォーマット（即ち、本明細書に記載される一例としての実施形態に従った、ＨＳ−ＤＳＣＨフレーミングプロトコルタイプ２のデータフレーム）と、に関するオーバヘッド値の例を示している。かかる例において、遅延基準時間の情報エレメントがデータフレーム内に存在しないものと仮定している。図示しているように、新ＨＳ−ＤＳＣＨデータフレームフォーマットは、各状況において（１０オクテットの単一のＰＤＵが送信される場合は除く、即ち、その状況ではオーバヘッドは等しいであろう）相当な量のオーバヘッドが省略される。

優先度付きキューが一度識別されると、基地局１２２−１は、ユーザ機器１１０への後の送信のために、ＨＳ−ＤＳＣＨフレーミングプロトコルタイプ２のデータフレームからのＰＤＵを、優先度付きキュー２３４内の適切な優先度付きキューに格納し得る（ブロック５４０）。

ブロック５２５に戻り、無線ネットワークコントローラ１２４−１が一度ＨＳ−ＤＳＣＨフレーミングプロトコルタイプ２のデータフレームを送信すると、無線ネットワークコントローラ１２４−１は、未使用のクレジットが残っているか否か、ＨＳ−ＤＳＣＨフレーミングプロトコルタイプ２の容量割り当ての制御フレームから判定し得る（ブロック５４５）。先に示したように、ＨＳ−ＤＳＣＨフレーミングプロトコルタイプ２の容量割り当ての制御フレームのＭＡＣ−ｄ ＰＤＵクレジットの情報エレメントは、ＨＳ−ＤＳＣＨフレーミングプロトコルタイプ２の容量割り当ての制御フレームにおいて（例えば、ＭＡＣ−ｄ ＰＤＵクレジットの情報エレメント６３０において）認められる、１つのＨＳ−ＤＳＣＨ間隔の間に無線ネットワークコントローラが送信することが許可される、ＭＡＣ−ｄ ＰＤＵのオクテット数、を示す。容量割り当ての制御フレームが１つより多い間隔について有効な場合には、無線ネットワークコントローラは、後続の間隔において、一定の間隔内に利用されなかったクレジットを再利用してもよい。

無線ネットワークコントローラ１２４−１が、未使用のクレジットが残っているとＨＳ−ＤＳＣＨフレーミングプロトコルタイプ２の容量割り当ての制御フレームから判定した場合には（ブロック５４５−ＹＥＳ）、無線ネットワークコントローラ１２４−１は、次の間隔において未使用のクレジットを利用してもよい（ブロック５５０）。１つの実施形態において、無線ネットワークコントローラ１２４−１は、次回の間隔においてのみ（次の間隔よりも先の複数の間隔においてではなく）未使用のクレジットを利用してもよい。先行する間隔において利用されなかったクレジットを次の間隔において利用する能力は、安定したビットレートを提供する。一方、無線ネットワークコントローラ１２４−１が、未使用のクレジットが残っていないことをＨＳ−ＤＳＣＨフレーミングプロトコルタイプ２の容量割り当ての制御フレームから判定した場合には（ブロック５４５−ＮＯ）、処理は終了し得る。例えば、処理はブロック５１５へと戻ってもよく、無線ネットワークコントローラ１２４−１は、その場合、他のＨＳ−ＤＳＣＨフレーミングプロトコルタイプ２の容量割り当ての制御フレームが受信される。

図８は、一例としての実施形態に従った、ノードがＨＳ−ＤＳＣＨフレーミングプロトコルタイプ２フォーマットをサポートすることが可能かどうかについて判定するための例示的なステップのフローチャートである。１つの実施形態において、図８に記載されるステップの各部は、基地局１２２−１のような基地局によって実行されてもよく、処理の一部は、無線ネットワークコントローラ１２４−１のような、無線ネットワークコントローラによって実行されてもよい。他の実施形態において、以下に記載する例示的なステップの幾つか、又は全ては、他の装置、又は装置の組み合わせによって実行されてもよい。例えば、以下に記載するステップは、第１の無線ネットワークコントローラ及び第２の無線ネットワークコントローラによって実行されてもよい。

例示的なステップは、無線ネットワークコントローラがサポートされたＨＳ−ＤＳＣＨフレーミングプロトコルタイプを識別する制御メッセージを生成するステップから、開始され得る（ブロック８０５）。１つの実施形態において、制御メッセージは、例えば、ＲＡＤＩＯ ＬＩＮＫ ＳＥＴＵＰ ＲＥＱＵＥＳＴメッセージ、ＲＡＤＩＯ ＬＩＮＫ ＡＤＤＩＴＩＯＮ ＲＥＱＵＥＳＴメッセージ、ＲＡＤＩＯ ＬＩＮＫ ＲＥＣＯＮＦＩＧＵＲＡＴＩＯＮ ＲＥＱＵＥＳＴメッセージ、ＲＡＤＩＯ ＬＩＮＫ ＲＥＣＯＮＦＩＧＵＲＡＴＩＯＮ ＰＲＥＰＡＲＡＴＩＯＮ ＲＥＱＵＥＳＴメッセージ、ＰＨＹＳＩＣＡＬ ＳＨＡＲＥＤ ＣＨＡＮＮＥＬ ＲＥＧＯＮＦＩＧＵＲＡＴＩＯＮ ＲＥＱＵＥＳＴメッセージ、及び／又は、他のタイプの制御メッセージを含み得る。１つの実施形態において、制御メッセージは、ＨＳ−ＤＳＣＨ周波数分割複信（ＦＤＤ：Frequency Division Duplex）情報の情報エレメントに、ＨＳ−ＤＳＣＨフレーミングプロトコルタイプサポートの情報エレメントを含み得る。ＨＳ−ＤＳＣＨフレーミングプロトコルタイプサポートの情報エレメントの例示的なコーディングが、表２に示されている。図に示すように、ＨＳ−ＤＳＣＨフレーミングプロトコルタイプサポートの情報エレメントは、一例としての実施形態において、８ビットのブール値のリストを格納し得る。他のサイズのブール値のリストも可能である。ＨＳ−ＤＳＣＨフレーミングプロトコルタイプサポートの情報エレメントは、どのＨＳ−ＤＳＣＨフレーミングプロトコルタイプがサポートされるかについて示してもよい。１つより多いフレーミングプロトコルタイプがサポートされてもよい。ブール値のリストの右から左に、各位置は、ＨＳ−ＤＳＣＨフレーミングプロトコルタイプ１〜８を示してもよい。１つの実施形態において、「０」は、そのタイプがサポートされないことを示してもよく、「１」は、そのタイプがサポートされることを示してもよい。例えば、「１１００００００」のブールリストは、タイプ１及びタイプ２双方のフレーミングプロトコルフォーマットがサポートされることを示してもよい。

無線ネットワークコントローラ１２４−１は、基地局１２２−１へと制御メッセージを送信し得る（ブロック８１０）。例えば、無線ネットワークコントローラ１２４−１は、Ｉｕｂインタフェース４２０を介して制御メッセージを送信してもよい。基地局１２２−１は、制御メッセージを受信し得る（ブロック８１５）。例えば、基地局１２２−１は、Ｉｕｂインタフェース２４０を介して制御メッセージを受信してもよい。（ＨＳ−ＤＳＣＨフレーミングプロトコルタイプの情報エレメントを含む）この制御メッセージの受信の後に、基地局１２２−１は、ＨＳ−ＤＳＣＨフレーミングプロトコルタイプを選択し得る（ブロック８２０）。基地局１２２−１は、複数の要因に基づいて選択を行なってもよい。例えば、１つの実施形態において、基地局１２２−１は、ＨＳ−ＤＳＣＨフレーミングプロトコルタイプ２を、基地局１２２−１がこのフレーミングプロトコルフォーマットと互換性がある場合には常に選択することとしてもよい。

基地局１２２−１は、被選択ＨＳ−ＤＳＣＨフレーミングプロトコルタイプを識別する応答メッセージを生成し得る（ブロック８２５）。１つの実施形態において、応答メッセージは、例えば、ＲＡＤＩＯ ＬＩＮＫ ＳＥＴＵＰ ＲＥＳＰＯＮＳＥメッセージ、ＲＡＤＩＯ ＬＩＮＫ ＡＤＤＩＴＩＯＮ ＲＥＳＰＯＮＳＥメッセージ、ＲＡＤＩＯ ＬＩＮＫ ＲＥＣＯＮＦＩＧＵＲＡＴＩＯＮ ＲＥＳＰＯＮＳＥメッセージ、ＲＡＤＩＯ ＬＩＮＫ ＲＥＣＯＮＦＩＧＵＲＡＴＩＯＮ ＰＲＥＰＡＲＡＴＩＯＮ ＲＥＳＰＯＮＳＥメッセージ、ＰＨＹＳＩＣＡＬ ＳＨＡＲＥＤ ＣＨＡＮＮＥＬ ＲＥＧＯＮＦＩＧＵＲＡＴＩＯＮ ＲＥＳＰＯＮＳＥメッセージ、及び／又は、他のタイプの応答メッセージを含み得る。生成される応答メッセージのタイプは、無線ネットワークコントローラ１２４−１から受信される制御メッセージに基づいてもよい。１つの実施形態において、応答メッセージは、ＨＳ−ＤＳＣＨ周波数分割複信（ＦＤＤ）情報応答の情報エレメントに、被選択ＨＳ−ＤＳＣＨフレーミングプロトコルタイプの情報エレメントを含み得る。被選択ＨＳ−ＤＳＣＨフレーミングプロトコルタイプの情報エレメントの例示的なコーディングが、表３に示されている。図に示すように、被選択ＨＳ−ＤＳＣＨフレーミングプロトコルタイプの情報エレメントは、一例としての実施形態において、プロトコルタイプの数を表す（例えば、１〜８の）整数を格納し得る。被選択ＨＳ−ＤＳＣＨフレーミングプロトコルタイプの情報エレメントは、使用されるＨＳ−ＤＳＣＨフレーミングプロトコルタイプを示してもよい。例えば、「１」の値はフレーミングプロトコルタイプ１が選択されていることを示してもよく、「２」の値はＨＳ−ＤＳＣＨフレーミングプロトコルタイプ２が選択されていることを示してもよい。

１つの実施形態において、基地局１２２−１は、応答メッセージにＨＳ−ＤＳＣＨ初期容量割り当て（Initial Capacity Allocation）の情報エレメントを含み得る。ＨＳ−ＤＳＣＨ初期容量割り当ての情報エレメントは、Ｉｕｂインタフェースを通じたＨＳ−ＤＳＣＨフレーミングプロトコルのための各スケジューリング優先度クラスについてのフロー制御情報を提供してもよい。ＨＳ−ＤＳＣＨ初期容量割り当ての情報エレメントは、（ＨＳ−ＤＳＣＨデータフレームの相対的な優先度を表す情報を格納することも可能な）スケジューリングインジケータの情報エレメントと、（ＭＡＣ−ｄ ＰＤＵの長さを（例えばビットで）表す情報を格納することも可能な）最大ＭＡＣ−ｄ ＰＤＵサイズの情報エレメントと、（新しいクレジットが基地局１２２−１から受信される前に無線ネットワークコントローラ１２４−１によって送信され得るＭＡＣ−ｄ ＰＤＵの初期数を表す情報も格納することも可能な）ＨＳ−ＤＳＣＨ初期ウィンドウサイズの情報エレメントと、を含み得る。ＨＳ−ＤＳＣＨ初期容量割り当ての情報エレメントの解釈は、選択されたフレーミングプロトコルタイプに基づいて様々であってもよい。例えば、フレーミングプロトコルタイプ２について、ＨＳ−ＤＳＣＨ初期容量割り当ての情報エレメントは、最大ＭＡＣ−ｄ ＰＤＵ長（最大ＭＡＣ−ｄ ＰＤＵサイズ）に、ＭＡＣ−ｄ ＰＤＵ数（ＨＳ−ＤＳＣＨ初期ウィンドウサイズ）を掛けることによって解釈されてもよい。これによって、ビット（又はオクテット）の総数が与えられる。

１つの実施形態において、基地局１２２−１は、ＨＳ−ＤＳＣＨ周波数分割複信（ＦＤＤ）情報応答の情報エレメントに、最大ＨＳ−ＤＳＣＨフレーミングプロトコルデータフレーム長の情報エレメントを含め得る（ブロック８３０）。ＨＳ−ＤＳＣＨフレーミングプロトコルデータフレーム長の情報エレメントの例示的なコーディングが、表４に示されている。図に示すように、ＨＳ−ＤＳＣＨフレーミングプロトコルデータフレーム長の情報エレメントは、一例としての実施形態において、最大ＨＳ−ＤＳＣＨフレーミングプロトコルデータフレーム長をオクテットで表す（例えば、１〜５０００以上までの）整数を格納し得る。実際には、無線ネットワークコントローラ１２４−１が、ＨＳ−ＤＳＣＨフレーミングプロトコルデータフレーム長の情報エレメントにおける最大長と等しい長さを有する、受信用フレーミングプロトコルの最大送信単位（Maximum Transmission Unit）を有する場合には、無線ネットワークコントローラ１２４−１は、自身のフレーミングプロトコルの最大送信単位を考慮し、従って、無線リンク制御の最大ＰＤＵ長をトリガしてもよい。この情報エレメントは、全ＨＳ−ＤＳＣＨフレーミングプロトコルタイプに適用可能であってもよい。

応答メッセージが一度生成されると、基地局１２２−１は、無線ネットワークコントローラ１２４−１に応答メッセージを送信し得る（ブロック８３５）。例えば、基地局１２２−１は、Ｉｕｂインタフェース２４０を介して制御メッセージを送信してもよい。無線ネットワークコントローラ１２４−１は、制御メッセージを受信し得る（ブロック８４０）。例えば、無線ネットワークコントローラ１２４−１は、Ｉｕｂインタフェース４２０を介して制御メッセージを受信してもよい。無線ネットワークコントローラ１２４−１は、フレーミングプロトコルタイプが基地局１２２−１によって選択されているか否かを判定し得る（ブロック８４５）。例えば、無線ネットワークコントローラ１２４−１は、応答メッセージを解析して、応答メッセージが被選択ＨＳ−ＤＳＣＨフレーミングプロトコルタイプの情報エレメントを含むか否かを判定してもよい。

被選択ＨＳ−ＤＳＣＨフレーミングプロトコルタイプの情報エレメントが受信された応答メッセージに含まれる場合には（ブロック８４５−ＹＥＳ）、無線ネットワークコントローラ１２４−１は、この情報エレメントに基づいて、基地局１２２−１によって選択されたＨＳ−ＤＳＣＨフレーミングプロトコルタイプを識別することができる。無線ネットワークコントローラ１２４−１は、選択された被選択ＨＳ−ＤＳＣＨフレーミングプロトコルタイプに従って、基地局１２２−１へのＨＳ−ＤＳＣＨデータフレームを生成し得る（ブロック８５０）。例えば、被選択ＨＳ−ＤＳＣＨフレーミングプロトコルタイプの情報エレメントが、基地局１２２−１がＨＳ−ＤＳＣＨフレーミングプロトコルタイプ２フォーマットを選択したことを示す場合には、無線ネットワークコントローラ１２４−１は、基地局１２２−１へのＨＳ−ＤＳＣＨフレーミングプロトコルタイプ２のデータフレームを生成し、送信することができる。

一方、被選択ＨＳ−ＤＳＣＨフレーミングプロトコルタイプの情報エレメントが受信された応答メッセージに含まれていない場合には（又は、例えば、基地局１２２−１から何も応答が受信されない場合には）（ブロック８４５−ＮＯ）、無線ネットワークコントローラ１２４−１は、所定のＨＳ−ＤＳＣＨフレーミングプロトコルタイプに基づいて基地局１２２−１へのＨＳ−ＤＳＣＨデータフレームを生成し、送信し得る。１つの実施形態において、所定のＨＳ−ＤＳＣＨフレーミングプロトコルタイプは、ＨＳ−ＤＳＣＨフレーミングプロトコルタイプ１フォーマットを含み得る。

図８に関して先に記述したステップの代替手段として、異なるＨＳ−ＤＳＣＨフレーミングプロトコルタイプを処理する基地局の機能は、基地局と関連付けられた無線ネットワークにおいて構成されてもよい。例えば、無線ネットワークコントローラ１２４−１は、基地局１２２−１及び１２２−２によりサポートされるＨＳ−ＤＳＣＨフレーミングプロトコルタイプを識別する情報により構成されてもよい。従って、例えば、無線ネットワークコントローラ１２４−１が基地局１２２−１に送信すべきＰＤＵを有する場合に、無線ネットワークコントローラ１２４−１は、（例えば、無線ネットワークコントローラ１２４−１と関連づけられたメモリ内の情報をルックアップすることにより）基地局１２２−１がＨＳ−ＤＳＣＨフレーミングプロトコルタイプ２に対処することが可能かどうかについて判定することが可能である。基地局１２２−１がＨＳ−ＤＳＣＨフレーミングプロトコルタイプ２に対処することが可能である場合に、無線ネットワークコントローラ１２４−１は、本明細書にて説明しているような、ＰＤＵを含むＨＳ−ＤＳＣＨフレーミングプロトコルタイプ２のデータフレームを生成し、そのデータフレームを基地局１２２−１へと転送することが可能である。

図９に図示するような１つの実施形態においては、サービス提供無線ネットワークコントローラ（ＳＲＮＣ）は、ドリフト無線ネットワークコントローラ（ＤＲＮＣ）がフレキシブルなＰＤＵ長（即ち、ＨＳ−ＤＳＣＨフレーミングプロトコルタイプ２フォーマット）をサポートするか否かを知らなければならない可能性がある。ドリフト無線ネットワークコントローラと関連付けられた全ての基地局が新しいフレキシブルなＰＤＵ長のデータフレームをサポートしない可能性もあり、このサポートはセルごとに異なってもよい。このための解決策は、ドリフト無線ネットワークコントローラからサービス提供無線ネットワークコントローラへと送信される機能コンテナ（CAPABILITY CONTAINER）の情報エレメント９１０において、セルごとのフレキシブルなＰＤＵ長のためのサポートについての情報を含むことである。同様に、サービス提供無線ネットワークコントローラのリロケーションについて、情報エレメントが、リロケーションするサービス提供無線ネットワークコントローラから目標無線ネットワークコントローラへと送信される目標ＲＮＣへのソースＲＮＣの透過的コンテナ（SOURCE RNC TARGET RNC TRANSPARENT CONTAINER）に含まれてもよく、これによって、フレキシブルなＰＤＵ長のデータフレームに対処する能力が伝達される。

フレキシブルなＰＤＵ長のデータフレームをサポートする能力は、ユーザ機器１１０へも伝達されてもよい。例えば、基地局がフレキシブルなＰＤＵ長のデータフレームをサポートすることが可能か否かについて示す情報エレメントが、ユーザ機器１１０への制御メッセージに含まれてもよい。制御メッセージは、例えば、ＲＡＤＩＯ ＢＥＡＲＥＲ ＳＥＴＵＰメッセージ、ＲＡＤＩＯ ＢＥＡＲＥＲ ＲＥＣＯＮＦＩＧＵＲＡＴＩＯＮメッセージ、ＴＲＡＮＳＰＯＲＴ ＣＨＡＮＮＥＬ ＲＥＣＯＮＦＩＧＵＲＡＴＩＯＮメッセージ、及び／又は、他のタイプの制御メッセージを含み得る。

従って、本明細書に記載するように、ＨＳ−ＤＳＣＨフレーミングプロトコルタイプ２のフレームフォーマットは以下のことを提供し得る。
・１５００オクテットまでの最大ＭＡＣ−ｄ ＰＤＵ長、そして、ＭＡＣ−ｄ ＰＤＵ長におけるオクテットによる粒度が効果的にサポートされる
・利用されるトランスポートネットワークの最大送信単位の制限を考慮する能力
・フレキシブルなＭＡＣ−ｄ（ＲＬＣ）ＰＤＵ長をサポートする能力
・進化型の高速パケットアクセス（ＨＳＰＡ）のより高いビットレートサポートする能力（例えば、４２メガビット／秒（Ｍｂｐｓ）まで）
・トランスポートネットワーク層の小さなオーバヘッド（データフレームヘッダ及び制御フレーム長）、及び、
・将来のより簡単な拡張に役立つ、Ｒｅｌｅａｓｅ７のための単一のデータフレームフォーマット及び制御フレームフォーマット
ＨＳ−ＤＳＣＨフレーミングプロトコルタイプ２の容量割り当ての制御フレームは、以下のことを提供し得る。
・（ＰＤＵ数、及び最大ＰＤＵ長の代わりに）オクテット又はビットレートを表す能力
・良好なビットレートの粒度を有する能力、及び、
・小さな待ち時間で、トランスポートネットワークに対して過度に集中的な負荷を掛けずに、大きい又は小さいＰＤＵを送信する能力
ＨＳ−ＤＳＣＨフレーミングプロトコルタイプ２のデータフレームは、以下のことを提供し得る。
・フレキシブルなＭＡＣ−ｄ ＰＤＵ長をサポートする能力
・全ての事例についての小さなオーバヘッド、例えば同じデータフレーム内での異なる長さのＰＤＵ、及び、
・同じ長さの小さなＰＤＵ

ここで説明した実施形態は、フレキシブルなＰＤＵ長のデータフレームのためのトランスポートネットワークのサポートについての効果的な解決策を提供する。ＨＳ−ＤＳＣＨフレーミングプロトコルタイプ２の容量割り当ての制御フレームは、未使用のクレジットの再利用を可能にすることによって、より大きなＭＡＣ−ｄ ＰＤＵ長をサポートする。ＨＳ−ＤＳＣＨフレーミングプロトコルタイプ２のデータフレームは、大きなＭＡＣ−ｄ ＰＤＵ長を可能にし、同じデータフレームにおいて１つより多いＰＤＵ長を可能にする。さらに、ＨＳ−ＤＳＣＨフレーミングプロトコルタイプ２のデータフレームは、１つの接続内で幾つかの論理チャネルからのＭＡＣ−ｄ ＰＤＵを可能にする。ヘッダのオーバヘッド、及び、トランスポートネットワークのためのパディングは、典型的な使用状況について小さく保たれる。

ここで説明した新しい情報エレメントは、新しいシグナリングメッセージを追加することなく、異なるフレームフォーマットの間での改善された相互運用性を可能にする。ＨＳ−ＤＳＣＨ初期容量割り当ての情報エレメントの新しい解釈によって、情報エレメントの定義が変えられることなく、フレキシブルなＰＤＵ長のデータフレームがサポートされる。

ここで説明した実施形態は、説明図と詳細な説明とを提供する一方、網羅的なものであること、又は開示された通りの厳密な形に実装を限定することを意図するものではない。上記の開示に照らして、又は現実的な実装から、修正及び変形を行うことは可能である。例えば、以下の記述はユニバーサル移動通信システム（ＵＭＴＳ：Universal Mobile Telecommunications System）地上波無線アクセスネットワーク（ＵＴＲＡＮ：UMTS Terrestrial Radio Access Network）のアーキテクチャに焦点を合わせているが、当然のことながら、本明細書に記載される技術は、ＵＴＲＡＮのフラットなアーキテクチャのような、他のタイプのアーキテクチャにも等しく適応可能である。ＵＴＲＡＮのフラットなアーキテクチャにおいて、無線ネットワークコントローラ（ＲＮＣ）及び基地局（ＢＳ）は、１つのＲＮＣ／ＢＳノードに結合されてもよい。ゲートウェイ装置は、コアネットワークとＲＮＣ／ＢＳノードとの間のトラフィックをトランスポートネットワークを介して転送してもよい。

図５及び図８に関して一連の動作が記載されているが、動作の順序は他の実施形態において変更されてもよい。さらに、独立した動作が、並行して実行されてもよい。

一例としての実施形態は、先に述べたように、ソフトウェア、ファームウェア、及びハードウェアの複数の異なる形態で、図示された実装において実現されてもよい。本明細書に記載される一例としての実施形態を実現するために用いられる、実際のソフトウェアコード又は制御用に特化したハードウェアは、本発明を限定しない。従って、一例としての実施形態の運用及び動作は、特定のソフトウェアコードを参照することなく説明されている。即ち、本明細書の記述に基づき一例としての実施形態を実現するために、ソフトウェア及び制御ハードウェアを設計することが可能であるものと理解されたい。

さらに、本発明のある部分は、１つ以上の機能を実行する「ロジック」（“logic”）として実現されてもよい。このロジックは、特定用途向け集積回路、フィールドプログラマブルゲートアレイ、プロセッサ若しくはマイクロプロセッサのようなハードウェア、ソフトウェア、又は、ハードウェアとソフトウェアとの組み合わせを含んでもよい。

特徴の特定の組み合わせが、特許請求の範囲に記述され、及び／又は明細書において開示されているが、これらの組み合わせは、本発明を限定するものではない。実際に、これらの特徴の多くが、特別には特許請求の範囲に記述されていない、及び／又は明細書で開示されていないやり方で組み合わされてもよい。

本明細書で用いられる際に「含む／含んでいる」（“comprise/comprising”）という語は、述べられた特徴、整数、ステップ、又は構成要素の存在を明記するために利用され、１つ以上の他の特徴、整数、ステップ、構成要素、又はその集合の存在又は追加を排除しないことを重視されたい。

本願の記載において用いられるどの要素、動作、又は命令も、そのように明示的に記載していない限り、本発明にとって不可欠である、又は本質的であるとして見なされるものではない。さらに、本明細書では、冠詞「ａ」は、１つ以上の項目を含むものとする。1つの項目のみが意図される場合には、「１つの」（“one”）という語、又は同様の語句が用いられる。さらに、「〜に基づいて」（“based on”）という語句は、例示的に他に述べていない限り、「少なくとも部分的に、〜に基づいて」（“based，at least in part，on”）を意味するものとする。

Claims (9)

1. 高速ダウンリンクパケットアクセス環境（１００）において第１の装置（１２４）により実行される方法であって、
   パケットデータユニット（７１６）の複数のブロックを含む高速ダウンリンク共有チャネルデータフレーム（７００、７３０、７３５、７５０）を生成するステップであって、前記複数のブロックのうちの第１のブロックは第１の長さのパケットデータユニットを含み、及び前記複数のブロックのうちの第２のブロックは異なる第２の長さのパケットデータユニットを含む、前記ステップと、
   前記高速ダウンリンク共有チャネルデータフレーム（７００、７３０、７３５、７５０）を第２の装置（１２２）へ転送するステップと、
   前記高速ダウンリンク共有チャネルデータフレームは、前記複数のブロック（７１６）の各ブロックについての、当該各ブロック内の１つ以上のパケットデータユニットの長さを示す第１情報エレメント（７１１）、及び当該各ブロック内のパケットデータユニットの量を示す第２情報エレメント（７１２）、をさらに含むことと、
   を特徴とする、方法。
2. 前記第１情報エレメント（７１１）及び前記第２情報エレメント（７１２）は、前記高速ダウンリンク共有チャネルデータフレームのヘッダ（７０１）内に位置する、請求項１に記載の方法。
3. 前記第１情報エレメント（７１１）及び前記第２情報エレメント（７１２）は、前記高速ダウンリンク共有チャネルデータフレームのペイロード（７１５）内に位置する、請求項１に記載の方法。
4. 前記高速ダウンリンク共有チャネルデータフレームは、パケットデータユニットの前記複数のブロックと関連付けられる論理チャネル識別子（７０７）をさらに含む、請求項１に記載の方法。
5. 前記高速ダウンリンク共有チャネルデータフレームは、複数の論理チャネル識別子（７５２）を含み、各論理チャネル識別子はパケットデータユニットの前記複数のブロックのうちの１つのパケットデータユニットと関連付けられる、請求項１に記載の方法。
6. 前記高速ダウンリンク共有チャネルデータフレームは、パケットデータユニットの前記複数のブロックと関連付けられる複数の情報エレメント（７４２）をさらに含み、前記複数の情報エレメントの各情報エレメントは、当該各情報エレメントと関連付けられる前記パケットデータユニットの長さを示す、請求項１に記載の方法。
7. パケットデータユニット（７１６）の複数のブロックを含む高速ダウンリンク共有チャネルデータフレーム（７００、７３０、７３５、７５０）を生成するように適合された処理システム（４１２）であって、前記複数のブロックのうちの第１のブロックは第１の長さのパケットデータユニットを含み、前記複数のブロックのうちの第２のブロックは異なる第２の長さのパケットデータユニットを含む、前記処理システム（４１２）と、
   前記高速ダウンリンク共有チャネルデータフレーム（７００、７３０、７３５、７５０）を転送するように適合されたＩｕｂインタフェース（４２０）と、
   前記高速ダウンリンク共有チャネルデータフレーム（７００、７３０、７３５、７５０）は、前記複数のブロックの各ブロックについての、当該各ブロックにおける各パケットデータユニットの長さを示す第１情報エレメント（７１１）、及び当該各ブロックにおけるパケットデータユニットの量を示す第２情報エレメント（７１２）、を含むことと、
   を特徴とする装置。
8. 前記高速ダウンリンク共有チャネルデータフレームは、パケットデータユニットの前記複数のブロックと関連付けられる論理チャネル識別子（７０７）をさらに含む、請求項７に記載の装置。
9. 前記高速ダウンリンク共有チャネルデータフレームは、複数の論理チャネル識別子（７５２）を含み、各論理チャネル識別子は、パケットデータユニットの前記複数のブロックのうちの１つのブロックのパケットデータユニットと関連付けられる、請求項７に記載の装置。
   

Images