通信ネットワーク内のデータ送信
【課題】通信ネットワークのネットワーク要素にデータ特にＨＳＤＰＡ関連データを提供するための方法に関する。
【解決手段】ユーザデータの送信を可能にするために、ネットワークのコントローラ４が、前記ユーザデータでフレームを構成するための専用フレーム構造を使うことが提案される。次にフレームは、コントローラ４からインタフェース経由でネットワーク要素５へ送ることができる。制御パラメータの送信を可能にするために、コントローラ４からインタフェース経由でネットワーク要素５へ送信される制御メッセージにコントローラ４が制御パラメータを付加できるようにするインタフェース適用プロトコルを使用する。
【解決手段】ユーザデータの送信を可能にするために、ネットワークのコントローラ４が、前記ユーザデータでフレームを構成するための専用フレーム構造を使うことが提案される。次にフレームは、コントローラ４からインタフェース経由でネットワーク要素５へ送ることができる。制御パラメータの送信を可能にするために、コントローラ４からインタフェース経由でネットワーク要素５へ送信される制御メッセージにコントローラ４が制御パラメータを付加できるようにするインタフェース適用プロトコルを使用する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、通信ネットワーク、例えばＵＴＲＡＮ（Universal mobile telecommunication services terrestrial radio access network：汎用移動通信サービス地上無線アクセスネットワーク）のネットワーク要素、例えばノードＢに、データ、例えば前記ネットワーク要素において要求されるＨＳＤＰＡ（高速ダウンリンクパケットアクセス）関連データを提供するための方法に関する。一方では、本発明はより具体的には、通信ネットワーク内でユーザデータ、例えばＨＳＤＰＡ関連ユーザデータをコントローラからネットワーク要素へインタフェース、例えばＩｕｂインタフェースを介して送信するための方法に関する。他方では、本発明はより具体的には、通信ネットワーク、例えばＵＴＲＡＮの、ネットワーク要素、例えばノードＢに、インタフェース、例えばＩｕｂインタフェース経由で前記ネットワーク要素に接続されるコントローラである前記通信ネットワークのコントローラ、例えばＲＮＣにおいて利用可能な制御パラメータ、例えばＨＳＤＰＡ関連制御パラメータを提供するための方法に関する。本発明は、対応する通信ネットワーク、ネットワーク要素およびコントローラにも同様に関する。
【背景技術】
【０００２】
ＨＳＤＰＡは、３ＧＰＰ（第３世代パートナーシッププロジェクト）における共用チャネル概念の機能拡張としてＵＴＲＡＮアーキテクチャのために導入された概念である。
【０００３】
ＵＭＴＳにおいて、ＵＴＲＡＮは、すべての無線関連機能を取り扱う。この目的のために、ＵＴＲＡＮは、１つより多いＲＮＣを含み、各ＲＮＣに１つ以上のノードＢが接続される。ＵＴＲＡＮのＲＮＣは、Ｉｕインタフェース経由でコアネットワークに接続される。１つのＵＴＲＡＮのＲＮＣは、Ｉｕｒインタフェースによってさらに相互接続できる。ダウンリンク送信において、ＲＮＣは、ことによると別のＲＮＣ経由で、コアネットワークからユーザデータを受信し、これをＩｕｂインタフェース経由でノードＢへ送出する。ノードＢは次に、このデータをアドレス指定されたユーザ装置ＵＥへＵｕインタフェース経由で送信する。
【０００４】
ＵＴＲＡＮのＲＮＣは、種々の役割を担うことがある。制御ＲＮＣ（ＣＲＮＣ）は、例えばノードＢの特定のセットについて定義し得る。任意のノードＢについて、ただ１つのＣＲＮＣがある。ＣＲＮＣは、そのノードＢの論理資源についての全体的制御を有している。サービングＲＮＣ（ＳＲＮＣ）は、ＵＥとＵＴＲＡＮとの間の特定接続に関して定義し得る。ＵＴＲＡＮとの接続を有している各ＵＥについて１つのＳＲＮＣがある。ＳＲＮＣは、ＵＥとＵＴＲＡＮとの間の無線資源制御（ＲＲＣ）接続を担う。サービングＲＮＣは、このＵＥのためのＩｕも終了する。
【０００５】
ＦＤＤモードのためのＵＴＲＡＮにおける共用チャネル概念において、ＤＳＣＨ（ダウンリンク共用チャネル）は、いくつかのＵＥ間で動的に共用されるダウンリンクトランスポートチャネルとして定義される。ＤＳＣＨは、例えば技術仕様書３ＧＰＰ ＴＳ ２５．３０１ Ｖ３．６．０（２０００−０９）：“第３世代パートナーシッププロジェクト；技術仕様書グループ無線アクセスネットワーク；無線インタフェースプロトコルアーキテクチャ（リリース１９９９）（3rd Generation Partnership Project; Technical Specification Group Radio Access Network; Radio Interface Protocol Architecture (Release 1999)）”に記載されるように、ＣＲＮＣ中で構成されてノードＢ経由でＵＥへ送信される。
【０００６】
ＨＳＤＰＡの基本的な考え方は、ダウンリンク送信用にデータレートがより高くノードＢからのより迅速な再送信機構を有する共有高速チャネルを提供することである。共用高速チャネルは、トランスポートチャネルとしてのＨＳ−ＤＳＣＨ（高速ダウンリンク共用チャネル）およびＨＳ−ＰＤＳＣＨ（高速物理ダウンリンク共用チャネル）と共に別個の共用物理制御チャネルと組み合わされたＤＰＣＨ（専用物理チャネル）を含むことになっている。ノードＢ中に実装される高速再送信機構は、ＨＡＲＱ（ハイブリッド自動再送要求）である。
【０００７】
現在使用されているＤＳＣＨは、高いデータレートもサポートできるが、再送信は常に、ＲＮＣ中のＲＬＣ（無線リンク制御）層により提供され、このことがトランザクションを低下させる。
【０００８】
新しい機能、特にＨＡＲＱをサポートするため、参照により本明細書に組み込まれる技術報告書３ＧＰＰ ＴＲ ２５．８５５ Ｖ１．０．０（２００１−０６）：“第３世代パートナーシッププロジェクト；技術仕様書グループ無線アクセスネットワーク；高速ダウンリンクパケットアクセス；オーバーオールＵＴＲＡＮデスクリプション（リリース５）（3rd Generation Partnership Project; Technical Specification Group Radio Access Network; High Speed Downlink Packet Access; Overall UTRAN Description (Release 5)）”中に、新しいＭＡＣ（メディアアクセス制御）エンティティが導入された。新しいＭＡＣエンティティは、ＭＡＣ−ｈｓと呼ばれ、常にノードＢ中に置かれる。３ＧＰＰの前のリリースでは、ユーザプレーンデータも取り扱うことが可能なすべてのＵＴＲＡＮ
ＭＡＣエンティティは、常にもっぱらＲＮＣ中に置かれた。ＨＳＤＰＡ概念をサポートするようにセルが構成されている場合にのみ、ＭＡＣ−ｈｓは存在し、これはＲＮＣ中に置かれたＭＡＣ−ｃ／ｓｈにＩｕｂインタフェース経由で接続される。
【０００９】
論理チャネルをトランスポートチャネルにマッピングするＭＡＣ層が用いられる。論理チャネルは、ＲＮＣ中の無線リンク制御（ＲＬＣ）とＭＡＣ層との間に定義されるチャネルタイプである。各論理チャネルは、これを通ってどのような種類のデータが送信されようとしているかを定義する。ＨＳＤＰＡのケースでは、論理チャネルは常にＳＲＮＣ中に位置する。トランスポートチャネルは、ＭＡＣ層とＬ１（層１）との間で定義されるチャネルタイプである。これは、データが無線リンクを通ってどのように送信されるべきかを記述する。ＤＳＣＨ概念においては、トランスポートチャネルがＩｕｂインタフェース上に見られるのに対して、ＨＳＤＰＡ概念においては、トランスポートチャネルはノードＢ中の内部チャネルである。
【００１０】
ＨＳＤＰＡのためのＵＴＡＮの種々のＭＡＣの接続は図１に例示してあり、この図は上記引用の技術報告書ＴＲ２５．８５５から取った。
【００１１】
図１は、ノードＢ中に置かれたＭＡＣ−ｈｓ１、さらに１以上のＲＮＣ中に置かれたＭＡＣ−ｃ／ｓｈ２およびＭＡＣ−ｄ３を示す。ＭＡＣ−ｈｓ１はＩｕｂインタフェース経由でＭＡＣ−ｃ／ｓｈ２に接続されており、それに対して、ＭＡＣ−ｃ／ｓｈ２はＩｕｒインタフェース経由でＭＡＣ−ｄ３に、これらが異なるＲＮＣ中に置かれる場合には、接続されており、そうでなければ、これらのＭＡＣ２、３は局所的に相互接続される。ＭＡＣ制御は、ＭＡＣ１〜３の各々にアクセスできる。ＰＣＣＨ（ページングチャネル）およびＢＣＣＨ（報知制御チャネル）のような論理チャネルは、ＭＡＣ−ｄ３の介入なしにＭＡＣ−ｓｈ２に直接的にマッピングされる。しかしながら、ＤＣＣＨ（専用制御チャネル）およびＤＴＣＨ（専用トラフィックチャネル）のような論理チャネルは常にＭＡＣ−ｄ３に接続されており、これは、もしＵＥが共通チャネルあるいは共用チャネルへのアクセス権を有していれば、受信したデータパケットをＭＡＣ−ｃ／ｓｈ２へ送出する。ノードＢを介したＵＥへの送信のために、ＭＡＣ−ｃ／ｓｈ２およびＭＡＣ−ｄ３は、ＰＣＨ（ページングチャネル）、ＦＡＣＨ（順方向アクセスチャネル）、ＤＣＨ（専用チャネル）等の様々な種類の論理チャネルをトランスポートチャネル上へマッピングする。受信されたＨＳＤＰＡ関連データは、ＨＳ ＤＳＣＨにおけるＵＥへの送信のためのノードＢのＭＡＣ−ｈｓ１へのマッピングなしで、ＭＡＣ−ｄ３によりＭＡＣ−ｃ／ｓｈ２経由で提供される。図１の詳細については、技術報告書ＴＲ２５．８５５を参照されたい。
【００１２】
代わりに、ＭＡＣ−ｈｓはＭＡＣ−ｄに直接接続することもできるであろう。
【００１３】
以前はＲＮＣ中のみに実装された機能が、現在ではＴＦＣ（トランスポート形式組合わせ）選択のように、ノードＢにおいても提供されなければならないので、ノードＢとＲＮＣとの間の機能分割が再編成された。機能性の新しい分配は、図２および３に示してあり、これらの図は、同様に技術報告書ＴＲ２５．８５５から取られたものであり、ＭＡＣ−ｃ／ｓｈ２およびＭＡＣ−ｈｓ１によりそれぞれ提供される機能のいくつかをより詳細に提示している。
【００１４】
再編成と同時に、スケジューリング／優先順位取り扱いおよびＴＦＣ選択機能はＨＳＤＰＡ関連ダウンリンク送信のために図２におけるＲＮＣのＭＡＣ−ｃ／ｓｈ２から取り去られて、図３におけるノードＢのＭＡＣ−ｈｓ１に付加された。かくして、最終スケジューリングおよびリアルタイムトラフィック制御は、ＨＳＤＰＡについてはもはやＲＮＣの制御下にない。従って、図２におけるＭＡＣ−ｃ／ｓｈ２においては、ＭＡＣ−ｄから受信されたＨＳＤＰＡ関連データは、他のダウンリンクデータについてどのようなスケジューリング、優先順位取り扱いまたはＴＦＣ選択等も実行されることなく、図３のＭＡＣ−ｈｓ１に渡される。以前は、これらの機能は、ノードＢがＳＲＮＣに直接接続される場合にはＳＲＮＣにおいて、あるいはノードＢがＣＲＮＣに接続される場合にはＣＲＮＣにおいて、常に処理された。さらに、ＨＡＲＱは、図３の新しいＭＡＣ−ｈｓ１中に実装される。図２および３の詳細については、上記引用の技術報告書ＴＲ２５．８５５を参照されたい。
【００１５】
機能性の再編成は、ＲＮＣからノードＢへのダウンリンクユーザデータおよび要求される制御情報の既知の送信が適合させられなければならないことを意味する。
【００１６】
ダウンリンクユーザデータの送信については、ＲＬＣ層が変更されないことが提案された。このことは、ＲＬＣがこれまでのようにＲＬＣ ＰＤＵ（プロトコルデータユニット）をＲＮＣバッファ中にバッファすること、およびＲＮＣ、すなわちＭＡＣ−ｄ３上にあるＭＡＣ層の要求があった時にのみＲＬＣがデータを下層に送出することを意味する。従って、ＲＮＣ中のＭＡＣエンティティとノードＢ中のＭＡＣ−ｈｓ１との間のデータ送信をサポートするトランザクションは、現在高レベルにおいてのみ定義されるが、詳細はいまだ欠けている。これらの高レベル定義によって、ＲＮＣからノードＢへのデータフローを制御するために、図３に示されるように、フロー制御機能がＭＡＣ−ｃ／ｓｈ２とＭＡＣ−ｈｓ１との間で新しい特徴として定義される。
【００１７】
Ｉｕｂ−インタフェース上での実際のデータ送信をサポートするために、さらにＨＳ−ＤＳＣＨフレームプロトコル層（ＨＳ−ＤＳＣＨ ＦＰ）が、ＭＡＣ−ｃ／ｓｈの下およびＭＡＣ−ｈｓの上に含まれた。この層は図４に示してあり、この図もやはり技術報告書ＴＲ２５．８５５から取ったものである。図４は、ＨＳＤＰＡの無線インタフェースプロトコルアーキテクチャ、より具体的にはネットワーク要素の層を示し、このネットワーク要素は、左から右へかけて、Ｕｕインタフェース経由でノードＢに接続されるユーザ装置ＵＥであり、このノードＢはさらにＩｕｂインタフェース経由で第１のＲＮＣに接続され、この第１のＲＮＣはＩｕｒインタフェース経由で最終的に第２のＲＮＣに接続される。ノードＢ、第１および第２のＲＮＣの各々は、それぞれのＭＡＣエンティティに加えてＨＳ−ＤＳＣＨ ＦＰを含む。このＨＳ−ＤＳＣＨ ＦＰは、ＲＮＣからノードＢへのデータパケットだけでなく、関連制御情報も送信することを意図している。そのようなＦＰプロトコルが、ＩｕｂおよびＩｕｒインタフェース双方でのダウンリンクのデータ送信のためのどのような詳細もなしに提案されており、この送信は、ＭＡＣおよびＲＬＣのＬ２（層２）のサービスを使用している。図４の詳細については、上記引用の技術報告書ＴＲ２５．８５５を参照されたい。
【００１８】
しかしながら、Ｉｕｂインタフェースについて定義された現在のＦＰフレーム構造はどれもＨＳＤＰＡに適用可能ではない。特に、ＨＳＤＰＡについての提案がそれから生じるＤＳＣＨのために使用されるＦＰフレーム構造は、ＨＳＤＰＡデータ送信に適していない。なぜならば、ＤＳＣＨ ＦＰフレームは、スケジューリングまたはＴＦＣ選択がすでになされていた場合にのみその値が定義され得るフィールドを含んでいるからである。上記で言及したように、これらの機能はＨＳＤＰＡ関連送信のためにノードＢにシフトされた。さらに、ＤＳＣＨ ＦＰフレームは、ＨＳＤＰＡがＲＮＣとノードＢとの間のフロー制御をサポートするために必要な情報をすべて含んでいるわけではない。
【００１９】
ＨＳＤＰＡ関連ユーザデータに加え、ノードＢが送信のためのＨＳ−ＤＳＣＨチャネルを設定および再構成できるように、ノードＢにおいて制御情報も利用可能でなければならない。
【００２０】
機能の再編成に起因して、例えば技術仕様書３ＧＰＰ ＴＳ ２５．４３３ Ｖ３．４．１（２０００−１２）：“第３世代パートナーシッププロジェクト；技術仕様書グループ無線アクセスネットワーク；ＵＴＲＡＮＩｕｂインタフェースＮＢＡＰシグナリング（リリース１９９９）（3rd Generation Partnership Project ; Technical Specification Group Radio Access Network; UTRAN Iub Interface NBAP Signalling (Release 1999)）”に記載されるＤＳＣＨ設定および再構成のためのＩｕｂに関する現在の適用プロトコル手順は、ＨＳ−ＤＳＣＨについて使用できない。例えば、ＨＳＤＰＡのケースでは、ＤＳＣＨについての無線リンク（ＲＬ）設定の間に、チャネルコーディングパラメータを提供する必要はない。なぜならば、これらのチャネルコーディングパラメータはノードＢ中で決定されるからである。他方では、ＤＳＣＨのためにノードＢにより要求されないいくつかのパラメータは、ノードＢがセル中にＨＳ−ＤＳＣＨ属性を構成できるように、セル構成手順の間にＨＳＤＰＡのためにノードＢに提供されるべきである。さらに、これらのパラメータを好ましくは準静的な方法でセルベースに変更することが可能であるべきである。
【先行技術文献】
【非特許文献】
【００２１】
【非特許文献１】3GPP TS 25.435 V4.1.0，２００１年６月
【非特許文献２】3GPP TR 25.855 V1.0.0，２００１年６月
【非特許文献３】3GPP TS 25.425 V4.0.0，２００１年３月
【非特許文献４】3GPP TS 25.433 V4.1.0，２００１年６月
【発明の概要】
【課題を解決するための手段】
【００２２】
通信ネットワーク内で前記通信ネットワークのネットワーク要素において要求されるデータの送信を可能にすることが本発明の目的である。
【００２３】
ＵＴＲＡＮによるＨＳＤＰＡの使用を可能にすること、より具体的にはＵＴＲＡＮのＲＮＣがＨＳＤＰＡ関連データをＵＴＲＡＮのノードＢに提供できるようにすることも本発明の目的である。
【００２４】
ＲＮＣが適当な方法でＨＳＤＰＡ関連ユーザデータおよびＮＢＡＰ（ノードＢ適用部分）についてのＨＳＤＰＡ関連制御パラメータをノードＢに提供できるようにすることがとりわけ本発明の目的である。
【００２５】
本発明の第１の形態はユーザデータの送信を目的とするのに対して、本発明の第２の形態は制御パラメータの送信を目的とする。
【００２６】
本発明の第１の形態として、通信ネットワーク内でユーザデータをコントローラからネットワーク要素へインタフェース経由で送信するための方法が提案される。通信ネットワークは特にＵＴＲＡＮ、コントローラはＲＮＣ、ネットワーク要素はノードＢそしてインタフェースはＩｕｂインタフェースとすることができる。コントローラは、ユーザデータによってデータフレームを構成するために、少なくとも１つの専用フレーム構造、特に専用ＨＳＤＰＡ ＦＰフレーム構造を使う。次にデータフレームはインタフェース経由でネットワーク要素に送信される。フレーム構造は、ユーザデータを処理するために前記ネットワーク要素中で要求される情報を受信するための少なくとも１つのヘッダセクションを含んでいる。
【００２７】
本発明の第１の形態として、さらに、提案された方法を実現するための手段を含む、通信ネットワーク特にＵＴＲＡＮ、コントローラ特にＲＮＣ、およびネットワーク要素特にノードＢが提案される。
【００２８】
第１の形態に関し、本発明は、ＨＳＤＰＡ関連ユーザデータの処理に必要な情報の送信は、他の共用チャネルに使用される解決策と同様であるべきだが、ＨＳＤＰＡの要件についてなお最適化されるべきである、という考えから発している。提案された専用フレーム構造により、ＨＳＤＰＡにとりもはや必要ではないＤＳＣＨのための構造中で使用されたすべてのフィールドを削除すること、およびＨＳＤＰＡのために付加的に要求される情報のためのフィールドを挿入することが可能になる。かくして、Ｉｕｂインタフェース経由でのＨＳＤＰＡ関連ユーザデータのために必要な情報の最適化された送信が可能になる。同じ考えを他の通信ネットワーク、ネットワーク要素および状況に適用し得る。
【００２９】
本発明の第２の形態として、通信ネットワークのコントローラにおいて利用可能な制御パラメータを通信ネットワークのネットワーク要素に提供する方法が提案され、コントローラはインタフェース経由で前記ネットワーク要素に接続される。通信ネットワークは特にＵＴＲＡＮ、コントローラはＲＮＣ、ネットワーク要素はノードＢそしてインタフェースはＩｕｂインタフェースとすることができる。この方法は、少なくとも１つの制御パラメータ、特にＨＳＤＰＡ関連制御パラメータを、前記コントローラから前記ネットワーク要素へ前記インタフェース経由で送信された少なくとも１種類の制御メッセージ中に挿入することを可能にするインタフェース適用プロトコルを使用することを含む。
【００３０】
また本発明の第２の形態として、さらに、提案された方法を実現するための手段を含む、通信ネットワーク特にＵＴＲＡＮ、コントローラ特にＲＮＣ、およびネットワーク要素特にノードＢが提案される。
【００３１】
第２の形態に関し、本発明は、ＨＳ ＤＳＣＨチャネルを設定および再構成するために必要な制御パラメータをノードＢに提供するための最も効率的な方法は、ＲＮＣからノードＢに送信される制御メッセージ中にパラメータを含めることであるという考えに発する。ＲＮＣおよびノードＢはＩｕｂインタフェース経由で互いに接続されるので、従って、Ｉｕｂ適用プロトコルをそれに応じて変更することが提案される。結果として、ノードＢは、例えば、受信された制御パラメータに基づいてＨＳ−ＤＳＣＨチャネルを設定および再構成することが可能である。ノードＢは、従って、セル中のユーザ装置へのＨＳＤＰＡ関連データをサポートするようにＲＮＣによって構成できる。同じ考えを他の通信ネットワーク、ネットワーク要素および状況に適用し得る。
【００３２】
本発明の双方の形態は、ＲＮＣからノードＢへＩｕｂインタフェース経由でデータを送信するために使われる一般仕様のＨＳＤＰＡの特定の実現、すなわち、一方では専用フレーム構造の実現を、他方ではＨＳＤＰＡの特定の手順を持つＩｕｂ適用プロトコルの実現をこれらが含んでいるという点で共通している。
【００３３】
本発明の好ましい実施形態は、サブクレームから明らかになる。
【００３４】
本発明の第１の形態の好ましい実施形態において、フレーム構造は、前記コントローラによってＨＳＤＰＡ関連ユーザデータが配信された少なくとも１つのＳＤＵを受信するためのペイロードセクションをさらに含んでおり、ヘッダセクションは、ＨＳＤＰＡ関連ユーザデータを処理するためにネットワーク要素において要求される情報を受信する。かくして、ＨＳＤＰＡ関連ユーザデータを処理するためにノードＢにおいて要求される情報は、前記ユーザデータと一緒に単一フレームで有利に送信し得る。ＳＤＵは、特にＭＡＣ−ｄ ＳＤＵおよび／またはＭＡＣ−ｃ／ｓｈ ＳＤＵである。
【００３５】
本発明の第１の形態について、提案されたＨＳＤＰＡ ＦＰフレーム構造は、どのような数の情報も受信するように設計でき、情報は要件に従って任意に前もって決定し得る点に注目しなければならない。
【００３６】
さらに、ヘッダセクション中のみの情報、例えばＨＳＤＰＡフロー制御のための情報を送信するために同じ構造を使用し得るように、ペイロードセクションが、専用フレーム構造に従って構成されたフレーム中の任意のデータを含むことは必須とされるべきではない。
【００３７】
特に、ＭＡＣ／ＦＰ ＵＥ−ＩＤ多重化がＲＮＣ中で許可されているか、又は許可されていないかの場合のために、種々の各種ＦＰフレーム構造が提供され得る。ＵＥ−ＩＤ多重化は、種々のＵＥが同じトランスポートチャネル上に多重化されてＲＮＣのＭＡＣ層またはＦＰ層において実行できる多重化タイプである。ＦＰ ＵＥ−ＩＤ多重化のケースでは、ＦＰフレームのヘッダは常にＵＥ−ＩＤ識別を含むべきである。この識別は、例えばＲＮＴＩとすることができ、あるいは、この目的にのみ定義された新しい識別とし、従って現行のＲＮＴＩよりも短くすることができる。ＭＡＣ ＵＥ−ＩＤ多重化のケースでは、ＵＥ−ＩＤフィールドはＭＡＣヘッダ中で使用され、すなわち、ＲＮＴＩはＭＡＣヘッダ中に付加され、ＦＰフレーム中では識別が必然的に全く要求されない。ノードＢは、ＭＡＣヘッダを読むことによりＵＥ−ＩＤ情報を取り出すことができる。またその一方で、ＭＡＣヘッダ中へのＲＮＴＩの付加にもかかわらずＦＰフレームがＵＥ−ＩＤフィールドを含むことが望まれるのであれば、使用されるＵＥ−ＩＤは、例えばＲＮＴＩとすることができ、あるいは、この目的にのみ定義された新しい識別とし、従って現行ＲＮＴＩよりも短くすることができる。
【００３８】
多重化を実行できるさらに種々の選択可能な方法があり、使用される多重化方法は、ＦＰフレームの最適構造を決定する際に考慮されなければならないことがある。使用される多重化の種類は、特に、１つのＦＰフレーム中に提供される同じ種類のフィールド数への影響を特に持ち得る。多重化のための１つの代替方法は、時分割ベース多重化であり、これは、１つのＦＰデータフレームは、１つのＵＥにのみ属するデータを運ぶことができることを意味する。別の代替方法では、１つのＦＰフレーム中で種々のＵＥに属するデータを運ぶことが可能である。さらに、多重化は、ＦＰエンティティに、１つのＴＴＩ内の１つのＦＰフレームのみを送ることを可能にすることによって処理でき、このフレームは、ただ１つのＵＥに当てられるか、またはこのフレームは多くのＵＥのためのデータを送信できるであろう。多重化は、ＦＰエンティティが、１つのＵＥにすべて割当てられる１つのＴＴＩ内の１つより多いＦＰフレームを送り得ること、あるいは、各ＦＰフレームが、種々のＵＥのためのデータを運ぶことができるであろうことも意味し得る。
【００３９】
同様に、種々のＦＰフレーム構造は、ユーザ装置識別がＲＮＣからノードＢへ送信されなければならないか、またはされなくてもよい場合に提供できる。
【００４０】
１つの所定フレーム構造に基づくフレームのサイズは、各ユーザ装置またはデータが取られる各ＲＮＣバッファのための専用フィールドをヘッダセクション中のいくらかの情報に充てることによって可変にできる。フィールド構造は、情報のいくつかの挿入を任意にすることによりさらに一般化できる。
【００４１】
特定のフレーム構造により考慮に入れられるいくらかの情報は、ＲＮＣバッファまたはＲＮＣにおいてユーザデータをバッファリングするためにＨＳＤＰＡデータ通信において使用されるバッファリングと関連させることができる。ＲＮＣバッファリングまたはＲＮＣバッファの用語は、バッファの正確な位置を識別することなくＲＮＣにおけるバッファ能力を示すために使用されることに注目しなければならない。従って、バッファリングは、例えばＲＬＣ層上および／またはＭＡＣ層上で提供し得る。
【００４２】
本発明の第１の形態において、いくつかのユーザ装置の特定の情報はさらに、提案されたフレーム構造のヘッダセクションに含まれるか、あるいは提案されたフレーム構造のペイロードセクションに挿入されたそれぞれのＳＤＵのヘッダセクション中に含まれ得る。
【００４３】
本発明の第２の形態において、同様にＩｕｂ適用プロトコルは、任意の適当な種類および数のパラメータを要件に従って適当な種類のメッセージ中に含むことを可能にする。
【００４４】
本発明の第２の形態に従ってＲＮＣからノードＢへ提供されなければならないことがあり得る２クラスの制御パラメータがある。ＲＮＣがパラメータの正確な値を決めてノードＢがこの決定に続かなければならないか、さもなければＲＮＣは可能な選択の限界を提供する。後者のケースにおいて、ノードＢは、提供された限界内のそれ自身の条件に従って値を決めることができる。かくして、各制御パラメータの内容は、固定値、その値についての範囲の表示、または前記ノードＢにより使用されるべき許可された値のセットのいずれかである。
【００４５】
本発明の第２の形態の制御パラメータは特に、例えばセルの設定および／または再構成のためにノードＢにおいて要求されるセルの特定パラメータ、あるいは例えば無線リンクの設定および／または再構成のためにノードＢにおいて要求される無線リンクの特定パラメータとし得る。次に、パラメータが、セル設定または再構成に関連する制御メッセージ中あるいはＲＬ設定または再構成にそれぞれ関連する制御メッセージ中に含められるべきであることがＩｕｂ適用プロトコルによって決定され得る。
【００４６】
セルの特定パラメータおよびＲＬの特定パラメータ双方は、特定値または選択限界として提供できる。
【００４７】
本発明の第２の形態の制御パラメータを制御メッセージ中に含めるために、好ましくは１つ以上の情報要素（ＩＥ）またはＩＥのグループが定義される。各ＩＥは次に、特定状況のために要求される各パラメータのためのフィールドを含み得る。ＩＥは、この特定の状況おいて送信されなければならない制御メッセージに付加できる。さらに、ＤＳＣＨまたは対応するＩＥについて定義されたＩＥは、要求されるパラメータがいくつかの状況について同じである限り、使用することができる。それぞれの状況のために何らかの制御メッセージに付加されるべき特定の状況についてのＩＥのセットおよび／またはＩＥのグループを定義することも可能である。
【００４８】
以下、図面を参照して本発明をより詳細に説明する。
【図面の簡単な説明】
【００４９】
【図１】ＨＳＤＰＡのために定義された既知のＵＴＲＡＮ−サイドの全体のＭＡＣアーキテクチャを示す図である。
【図２】ＲＮＣの既知のＭＡＣ−ｃ／ｓｈの詳細を示す図である。
【図３】ノードＢの既知のＭＡＣ−ｈｓの詳細を示す図である。
【図４】ＨＳＤＰＡのために定義された既知の無線インタフェースプロトコルアーキテクチャを示す図である。
【図５】ＭＡＣレベル多重化がＲＮＣ中で全く許可されない場合の、Ｉｕｂのためのモデルを示す図である。
【図６】ＭＡＣレベル多重化がＲＮＣ中で許可される場合の、Ｉｕｂのためのモデルを示す図である。
【図７】既知のＤＳＣＨ ＦＰフレーム構造を示す図である。
【図８】本発明によるＨＤＳＰＡ ＦＰフレーム構造の第１の実施形態を示す図である。
【図９】本発明によるＨＤＳＰＡ ＦＰフレーム構造の第２の実施形態を示す図である。
【図１０】本発明によるＨＤＳＰＡ ＦＰフレーム構造の第３の実施形態を示す図である。
【図１１】ＭＡＣ ＰＤＵ構造を例示する図である。
【図１２】図１０の実施形態のための可能なＦＰフレームヘッダフィールド値の第１の例を示す図である。
【図１３】図１０の実施形態のための可能なＦＰフレームヘッダフィールド値の第２の例を示す図である。
【図１４】本発明の第２の形態の実施形態のためのセルの特定ＩＥのセットを示す図である。
【図１５】本発明の第２の形態の実施形態のためのＲＬセルの特定ＩＥのセットを示す図である。
【図１６】本発明の第２の形態の実施形態のためのＲＬセルの特定ＩＥの第１のセットを示す図である。
【図１７】本発明の第２の形態の実施形態のためのＲＬセルの特定ＩＥの第２のセットを示す図である。
【図１８】本発明の第２の形態の実施形態のための既知のＴＦＳの変更を例示する図である。
【発明を実施するための形態】
【００５０】
最初に、本発明の第１の形態に応じたＨＳＤＰＡ ＦＰフレーム構造の３つの実施形態を提示する。
【００５１】
それぞれのフレーム構造は、ＵＴＲＡＮ内でＨＳＤＰＡ関連ユーザデータをＲＮＣのＭＡＣ−ｃ／ｓｈからＩｕｂインタフェース経由でノードＢのＭＡＣ−ｈｓへ送信するために使用されるものである。ユーザデータがアドレスされるＵＥは、このノードＢに接続される。
【００５２】
適当なフレーム構造を決定する際、ネットワーク要素の要件および機能、すなわちＲＮＣおよびノードＢが考慮されるべきである。考慮されるべき１つの要因は、例えばＭＡＣ／ＦＰ ＵＥ−ＩＤ多重化であり、これは以下で説明されるように、ＲＮＣにおいて許可することもできるし、許可しないこともできる。
【００５３】
図５で例示される第１のモデルにおいて、ＲＮＣは、ＭＡＣ／ＦＰ ＵＥ−ＩＤレベル多重化を実行することができない。
【００５４】
図５は、Ｉｕｂインタフェースにより相互接続されたＲＮＣ４およびノードＢ５を概略的に示している。ＲＮＣ４は、ＲＬＣ６、ＭＡＣ−ｄおよびＭＡＣ−ｃ／ｓｈ２、３ならびにＦＰエンティティ７を含んでいる。同様にノードＢ５は、ＦＰエンティティ８、およびＭＡＣ−ｈｓ１を含んでいる。図示では、３つの無線ベアラＲＢｗ、ｚおよびｖは、第１のユーザ装置ＵＥｘに割り当てられるのに対して、さらに２つの無線ベアラＲＢｍおよびｎは、第２のユーザ装置ＵＥｙに割り当てられる。ＵＥｙのＲＢおよび同様にＵＥｘのＲＢｖは、多重化せずに論理チャネル中のＲＬＣ６からＭＡＣ−ｄおよびＭＡＣ−ｃ／ｓｈ２、３ならびにＦＰエンティティ７、ＩｕｂインタフェースおよびノードＢ５のＦＰエンティティ８経由でＭＡＣ−ｈｓ１へ渡される。ＵＥｘのＲＢｗおよびｚは、ＲＮＣ４のＭＡＣ層中でＣ／Ｔ多重化され、シングルトランスポート接続上を同じエンティティ経由でノードＢ５へ送信される。Ｃ／Ｔ多重化は、種々のＲＢ、すなわち種々の論理チャネルを使用しており、同じトランスポートチャネル上の同じＵＥにすべてが割り当てられるＲＢの多重化を意味する。次にＭＡＣ−ｈｓ１は、受信された論理チャネルをトランスポートチャネル上にマッピングする。
【００５５】
同じＵＥにすべてが割り当てられる無線ベアラ（ＲＢ）の間でＣ／Ｔ多重化が実行可能であれば、要求されるＩｕｂ送信接続の最小数は、ＨＳ−ＤＳＣＨにアクセスできるＵＥの数と等しい。Ｃ／Ｔ多重化は、例えば図５におけるように、いくつかのＵＥのいくつかのＲＢについてのみ、またはすべてのＵＥのすべてのＲＢについて、ＲＮＣにより使用され得る。
【００５６】
代わりに、同じＩｕｂ送信接続への種々の無線ベアラＲＢのＣ／Ｔ多重化は、図５のＲＮＣ４において許可されなくてもよい。Ｃ／Ｔ多重化は、すべての無線ベアラが同じＵＥに割り当てられれば、例えば種々の優先順位レベルのせいで、提供することさえできなくてもよい。このケースでは、Ｉｕｂインタフェース上のトランスポート接続の数は、ＨＳＤＰＡタイプトランスポート方法を使用している無線ベアラの数と等しい。
【００５７】
図６において例示される第２のモデルにおいて、ＲＮＣ４は対照的に、ＭＡＣレベルＵＥ−ＩＤ多重化を実行できる。
【００５８】
図６は、図５のようにＩｕｂインタフェースにより相互接続されたＲＮＣ４およびノードＢ５の同じ構造を概略的に示す。このケースにおいてのみ、独立したＭＡＣ−ｄ３およびＭＡＣ−ｃ／ｓｈ２が描かれている。さらに、同じ無線ベアラＲＢｗ、ｚ、ｖ、ｍおよびｎは、図５のように同じユーザ装置ＵＥｘ、ＵＥｙに割り当てられている。無線ベアラＲＢｗおよびＲＢｚは、再度ＭＡＣ層において、より詳細にはＭＡＣ−ｄ３により、Ｃ／Ｔ多重化される。さらに、Ｃ／Ｔ多重化ならびに３つの他の無線ベアラＲＢｖ、ｍおよびｎの出力は、ＭＡＣ−ｃ／ｓｈ２により、ＲＮＣ４のＦＰ層７、ＩｕｂインタフェースおよびノードＢ５のＦＰ層８経由でＭＡＣ−ｈｓ１へ送信するための単一のシングルトランスポート接続に多重化にされたＵＥ−ＩＤである。ＭＡＣ−ｈｓ１は最初に多重分離を実行し、次にトランスポートチャネル上への論理チャネルのマッピングを実行する。
【００５９】
ノードＢ５において、ＭＡＣ層は、受信した情報を、図５におけるようにこれをＨＳ−ＤＳＣＨにさらにＨＳ−ＰＤＳＣＨ上にマッピングする前に、対応して多重分離する。
【００６０】
多重化において使用される１つより多いトランスポート接続もあり得る。多重化における一般的な概念は、同じ基準を満たすすべてのＵＥは同じトランスポート資源を使うことが可能であるということである。多重化は、例えばノードＢ中のセル数に基づくことができる。これが意味するのは、もしノードＢが１より多いセルをサポートすれば、セル当たり１つのトランスポートが提供されるということである。代わりに、多重化は、論理チャネルに割り当てられた優先順位レベルに基づくことができ、すなわち優先準位当たり１つのトランスポート接続が提供される。さらに、単一トランスポート接続のみが１つのノード−Ｂに提供できる。多重化は、無線インタフェース上のＨＳＤＰＡ関連物理チャネル数に基づくこともできるであろう。
【００６１】
第２のモデルにおいて、ＭＡＣ／ＦＰ ＵＥ−ＩＤ多重化は、どのようにも限定されておらず、このことは、すべてのＵＥがＩｕｂインタフェース上の同じトランスポート接続を使用できることを意味する。
【００６２】
第２のモデルは、ＵＥ−ＩＤ多重化をＦＰ層に置くことによっても提供できる。両方のケースにおいて、もしＲＮＴＩがＭＡＣヘッダ中で使用されれば、ＦＰフレーム中でどのようなＵＥ−ＩＤも強制的ではなく、さらにもし識別がＭＡＣヘッダ中に全く含まれなくても多重化が可能であれば、ＦＰヘッダはＵＥ−ＩＤフィールドも含むはずである。
【００６３】
ＭＡＣ／ＦＰ ＵＥ−ＩＤ多重化が許可される場合、フレーム構造は、種々のＵＥに属する情報を受信されたＨＳＤＰＡフレームから受信機が正しく抽出できるように定義されるべきである。
【００６４】
ところで図７〜１０は、比較のために提示されたＩｕｂインタフェースのために定義された従来のＤＳＣＨ ＦＰフレーム構造、ＵＥ−ＩＤ多重化が全く許可されないケースについてのＨＳＤＰＡ ＦＰフレーム構造の第１の実施形態ならびにＵＥ−ＩＤ多重化が許可されケースについてのＨＳＤＰＡ ＦＰフレーム構造の第２および第３の実施形態を示す。
【００６５】
図７のＤＳＣＨ ＦＰフレーム構造は、技術仕様書３ＧＰＰ ＴＳ ２５．４３５、Ｖ３．５．０（２０００−１２）：“第３世代パートナーシッププロジェクト；技術仕様書グループ無線アクセスネットワーク；共通トランスポートチャネルデータストリームのためのＵＴＲＡＮ Ｉｕｂインタフェースユーザプレーンプロトコル（リリース１９９９）”から取った。このフレーム構造は、ペイロードセクションとヘッダセクションとで構成されており、各々が８ビット０−７の行に分割されている。ペイロードセクションは、第１から最終のＴＢ（トランスポートブロック）、“予備エクステンション”、および“ペイロードＣＲＣ”（巡回冗長検査）を含む。ヘッダセクションは、フィールド“ヘッダＣＲＣ”、“ＦＴ”、“ＣＦＮ”、“ＴＦＩ”、“パワーオフセット”、“コードナンバー”、“ＳＦ”および“ＭＣ情報”を含む。
【００６６】
“ＣＦＮ”フィールドは、接続フレーム数（ＣＦＮ）を示すために使用され、そこではフレームのデータは無線インタフェースを通して送信されるべきである。ＨＳＤＰＡ概念において、このフィールドの値は、対応するデータの無線インタフェースへのスケジューリング後に初めてノードＢにより知られ、従ってＲＮＣはこのフィールドをノードＢへ提供できない。
【００６７】
“ＴＦＩ”フィールドは、フレーム中のデータにとり有効なトランスポートフォーマット（ＴＦ）を示すために使用される。ＨＳＤＰＡ概念において、ＴＦＣ選択はノードＢにおいて実行され、従って、ＲＮＣはそのような情報をノードＢに送出できない。
【００６８】
“パワーオフセット”フィールドは、対応するＦＰフレームのデータを送信するために要求されるパワーレベルを示すために使用される。ＤＳＣＨのために閉ループパワー制御が提供されるので、このフィールドはＤＳＣＨのケースにおいて要求される。ＨＳＤＰＡのケースでは、閉ループパワー制御は全く提供されず、従って、パワー制御情報はＲＮＣから全く要求されない。
【００６９】
“コードナンバー”フィールドは、ＤＳＣＨのために使用されるコードを示す。ＨＳＤＰＡのケースでは、コード選択はノードＢにおいてなされ、従って、そのような情報はＲＮＣから全く要求されない。
【００７０】
“ＳＦ”フィールドは、フレーム中の対応データパケットのためにＰＤＳＣＨ中で使用される拡散率（ＳＦ）を特定する。ＨＳＤＰＡ概念において、ＳＦはノードＢにおいて定義され、従って、そのような情報はＲＮＣから全く要求されない。
【００７１】
“ＭＣ情報”フィールドは、ＤＳＣＨデータがその上を運ばれる平行ＰＤＳＣＨコードの数を示すために使用される。ＨＳＤＰＡ概念において、この種の情報はノードＢにおいて定義されて、従って、そのような情報はＲＮＣから全く要求されない。
【００７２】
かくして、“ヘッダＣＲＣ”フィールドおよび“ＦＴ”（フレームタイプ）フィールドを除くヘッダセクションのフィールドのどれもＨＳＤＰＡのために要求されず、これらのフィールドは、ＨＳＤＰＡＦＰフレーム構造を設計する際に排除し得る。しかし、他方で、もしフィールドが単に排除されると、ノードＢは、受信されたＦＰフレームを抽出するための十分な情報を受信しない。従って、新しいＭＡＣエンティティＭＡＣ−ｈｓがノードＢ中に置かれる時にフロー制御機構が機能することを保証するために、新しいフィールドが要求される。
【００７３】
図８は、ＭＡＣ／ＦＰ ＵＥ−ＩＤ多重化が全く許可されないケースのためのそのような新しいフィールドを含むＨＳＤＰＡフレーム構造を示す。これも、ペイロードセクションとヘッダセクションとで構成されており、各々が８ビットの行に分割されている。ＤＳＣＨフレーム構造と同様に、ペイロードセクションは、第１から最終のＭＡＣ−ｃ／ｓｈ
ＳＤＵ（サービスデータユニット）、“予備エクステンション”、および“ペイロードＣＲＣ”を含む。可変ヘッダを持つＭＡＣ ＳＤＵの構造は、ＭＡＣ ＰＤＵとして最新技術から既知であり、図１１を参照して以下で説明される。ヘッダセクションは現在、“ヘッダＣＲＣ”、“ＦＴ”、“NumOfSDUs”、“ユーザバッファサイズ”、“ＵＥ−ＩＤタイプ”、および“ＣＭＣＨ−ＰＩ”と呼ばれるフィールドを含んでいる。特に、最後の２つのフィールドの導入は任意である。
【００７４】
“NumOfSDUs”フィールドは、フレーム中のＭＡＣ−ｃ／ｈｓ ＳＤＵの数を示すために使用される。フィールドの長さは適切に選択され得る。
【００７５】
“ユーザバッファサイズ”フィールドは、ＲＮＣバッファ中のそれぞれのＵＥに割り当てられたバッファの状態を示すために使用される（例えば、バイトで）。このフィールドは、同じデータフローに属するデータがＲＮＣ中にまだどれだけ残されているかをノードＢに知らせる。対応するＦＰデータフレーム中で運ばれたデータ量は、ユーザバッファサイズ情報フィールドから除外されるか、あるいはそれに含まれ得る。ノードＢは、例えばスケジューリングにおいてこの情報を使用することができ、その結果、優先順位が最も高くＲＮＣバッファ中の大部分のデータを有するデータフローは、優先順位がより低くＲＮＣバッファ中のデータをより少なく有するデータフローよりも早くＨＳＤＰＡチャネルにアクセスできる。用語ＲＮＣバッファの種々の考えられる意味は、以下で図１２および１３を参照して説明される。フィールドの長さは適切に選ばれ得る。
【００７６】
“ＵＥ Ｉｄタイプ”フィールドは、どのような種類のＲＮＴＩ、すなわちｃ−ＲＮＴＩまたはＵ−ＲＮＴＩを、ノードＢのＭＡＣ−ｈｓがＭＡＣヘッダに加えるべきかを示すために使用される。タイプＵ−ＲＮＴＩ（ＵＴＲＡＮ無線ネットワーク一時アイデンティティ）は、ＭＡＣ ＰＤＵのＭＡＣヘッダにおいて使用することができ、ペイロード部分は、Ｕ−ＲＮＴＩの使用が強制的な場合に、特定のＬ３（ＲＲＣ）シグナリングメッセージを含む。この種の状況は、ＭＡＣヘッダ中のＣ−ＲＮＴＩの代わりにＵ−ＲＮＴＩを使用する命令をＬ２（ＲＬＣ層経由でＭＡＣ層）に送ることによってＲＲＣにより報告される。タイプＣ−ＲＮＴＩ（セル無線ネットワーク一時アイデンティティ）は、ＦＤＤ（周波数分割二重）モードでＤＴＣＨおよびＤＳＣＨ上で使用され、Ｕ−ＲＮＴＩを使用する要求が上位層（ＲＲＣ）から全く受信されない場合に、ＭＡＣヘッダ中で使用し得る。ＲＮＴＩがノードＢに加えられるように指定される場合に限り、ＵＥ ＩＤタイプフィールドが要求される。もしＲＮＴＩがＳＲＮＣに加えられるように指定されるか、あるいはＨＳＤＰＡデータ通信のためにＲＮＴＩが全く使用されなければ、そのようなフィールドはＨＳＤＰＡ ＦＰデータフレームにおいて要求されない。フィールド長さは１ビットである。
【００７７】
共通トランスポートチャネル優先順位インジケータ（“ＣＭＣＨ−ＰＩ”）フィールドは、データフレームおよび／または含まれているＳＤＵの相対的優先順位を示すために使用される。ＨＳＤＰＡデータ送信のためにこのフィールドの使用を導入できるが、多重化が全く提供されない場合にＲＢの優先順位は、Ｉｕｂを介した対応するトランスポート接続が構成された時の直後に導入できるであろう。
【００７８】
ＨＳＤＰＡ ＦＰフレーム構造のこの第１の実施形態においては、ＭＡＣ ＳＤＵサイズ情報のためのフィールドが含まれる必要はない。なぜならば、ＨＳＤＰＡについては、準静的ＴＢサイズが使用されることが定義されており、そこにおいてＭＡＣ ＳＤＵは、多重化が全く許可されないケースでは固定サイズになるからである。
【００７９】
図９は、ＭＡＣ／ＦＰ ＵＥ−ＩＤ多重化が許可されるケースのための新しいフィールドを含むＨＳＤＰＡフレーム構造を示す。これも、ペイロードセクションとヘッダセクションとで構成されており、各々が８ビットの行に分割されている。ＤＳＣＨ ＦＰフレーム構造およびＨＳＤＰＡ ＦＰフレーム構造の第１の実施形態と同様に、ペイロードセクションは、第１から最終のＭＡＣ−ｃ／ｓｈ ＳＤＵ（サービスデータユニット）、“予備エクステンション”、および“ペイロードＣＲＣ”を含んでいる。ヘッダセクションは現在、“ヘッダＣＲＣ”、“ＦＴ”、“NumOfSDUs”、“NumOfBuff”、“ＭＡＣ ＳＤＵのサイズ”、“ユーザバッファサイズ”１−Ｎ、“ＵＥ−ＩＤタイプ”、および“ＣＭＣＨ−ＰＩ”と呼ばれるフィールドを含んでいる。“NumOfSDUs”、“NumOfBuff2”、“ＭＡＣ ＳＤＵのサイズ”、および“ＣＭＣＨ−ＰＩ”についても、たとえ各パラメータについて１つのフィールドしか図中に示されていなくても、複数のフィールドがあり得る。
【００８０】
“NumOfSDUs”フィールドは、１つのＲＮＣバッファから取られたＭＡＣ−ｃ／ｓｈ ＳＤＵの数を識別するために使用される。フィールド長さは適切に設定できる。この種のフィールドの数は、“NumOfBuff”フィールドの数と等しい。
【００８１】
“NumOfBuff”フィールドは、いくつのＲＮＣバッファからデータがこのＦＰフレームに供給されたかを示す。このフィールドは、データがそれから供給できたＲＮＣバッファの数を記述するわけではないことに注目しなければならない。フィールド長さは適切に設定できる。
【００８２】
ＭＡＣ多重化が強制的な特徴ではない、すなわちＭＡＣ／ＦＰ ＵＥ−ＩＤ多重化が許可されていたとしてもオペレータによってはそれを使わないことを望むことがあり得るので、“ＭＡＣ ＳＤＵのサイズ”フィールドが導入される。従って、ＭＡＣ／ＦＰ ＵＥ−ＩＤ多重化が許可されている場合にマルチベンダのケースをサポートするため、ＭＡＣ
ＳＤＵのサイズフィールドがそれぞれのフレーム中のＳＤＵのサイズを定義する。原則的に、ＴＢは、ＨＳＤＰＡ中で常に固定サイズを有しているが、ＭＡＣ／ＦＰ ＵＥ−ＩＤ多重化がサポートされているかいないかに応じてＭＡＣヘッダの長さが可変なので、ＭＡＣ ＳＤＵのサイズは、ＭＡＣヘッダの内容または存在に応じて変わり得る。この情報は、ＨＳＤＰＡデータフレームからＳＤＵを正しく抽出するために、受信機側で要求される。フィールドの長さは適切に設定できる。
【００８３】
“ユーザバッファサイズ”フィールドは、ＲＮＣバッファ中の１つのＵＥに割り当てられたバッファの状態をバイトで示すために使用される。フィールドの長さは適切に設定できる。フレーム中のこの種のフィールドの数は、“NumOfBuff”フィールドの数と等しい。
【００８４】
“ＣＭＣＨ−ＰＩ”フィールドは、ＭＡＣ／ＦＰ ＵＥ−ＩＤ多重化が許可されている場合にデータの優先順位についての情報を提供するために使用できるであろう。種々の優先順位レベルを有するデータを多重化することが可能であれば、この種のフィールドの数は、“NumOfBuffer”フィールドの数と等しくなければならないが、そのような多重化が全く許可されないのであれば、フレーム当たり１つの“ＣＭＣＨ−ＰＩ”フィールドを提供すれば十分である。
【００８５】
たとえＭＡＣ／ＦＰ ＵＥ−ＩＤ多重化が許可されていても、１つのＨＳＤＰＡ ＦＰフレームが、１つのＵＥまたはＲＢに属するデータのみを含み得るという制約が識別されれば、それぞれの多重化関連フィールド“NumOfSDU”、“ユーザバッファサイズ”、“ＭＡＣ ＳＤＵのサイズ”および“ＣＭＣＨ−ＰＩ”の数を減らすことができる点に注目しなければならない。このケースにおいて、ＭＡＣ／ＦＰ ＵＥ−ＩＤ多重化は、時分割法に基づいてなされる。
【００８６】
第３の実施形態として提示されるＨＳＤＰＡ ＦＰフレーム構造のさらなる変更は、ＨＳＤＰＡ関連データ送信におけるユーザ装置の識別に関する。
【００８７】
もしノードＢにおいてＵＥ識別が全く要求されず、従ってＭＡＣ／ＦＰ ＵＥ−ＩＤ多重化がＲＮＣにおいて全く許可されなければ、ＵＥの識別は、ＲＮＣにもノードＢにも含まれない。むしろデータは、他の方法を使用して識別される。
【００８８】
しかしながら、ＵＥ識別が要求されるのであれば、この情報がデータと結合され得る場所は、ＣＲＮＣ中のＭＡＣ−ｃ／ｓｈまたはノードＢ中のＭＡＣ−ｈｓである。最初のケースでは、使用されるＵＥ識別は、現在使用されているＲＮＴＩとするか、Ｉｕｂインタフェースを介してのデータ送信についてのみ定義される新しいＵＥ識別とし得る。
【００８９】
もしＲＮＴＩが使用されれば、ＵＥ識別情報は、この目的のためのフィールドをすでに有しているＭＡＣ−ｃ／ｓｈ ＳＤＵヘッダ中か、それぞれのＨＳＤＰＡ ＦＰデータフレームのヘッダセクション中に含まれ得る。もしＭＡＣ−ｃ／ｓｈ ＳＤＵヘッダ中に含まれれば、ノードＢは、ＵＥのアイデンティティを見い出すために、このヘッダ部分を抽出しなければならない。もしＵＥアイデンティティがＨＳＤＰＡ ＦＰデータフレームのヘッダセクション中に含まれれば、抽出は全く要求されない。
【００９０】
図９のフレーム構造については、もしＵＥ識別が要求されれば、識別はＲＮＴＩであり、ＣＲＮＣ中かノードＢ中のＭＡＣ ＳＤＵヘッダ中に含まれると想定された。
【００９１】
エアインタフェース上においてＲＮＴＩは全く要求されないが、Ｉｕｂ上でＵＥ識別が依然として要求されるケースについては、フレーム構造の第３の実施形態が提案され、これは図１０に例示される。
【００９２】
図１０のフレーム構造は、ＭＡＣ／ＦＰ ＵＥ−ＩＤ多重化を再びサポートし、図９のフレーム構造中に存在するすべてのフィールドを含む。このフレーム構造は、ＵＥを識別するための付加的フィールド“ＵＥ−ｉｄ１”から“ＵＥ−ＩｉｄＮ”までを含み、ペイロードセクション中のＭＡＣ−ｃ／ｓｈ ＳＤＵ中にはＵＥのためのデータが含まれる。この図には、それぞれ明示的に示されるＮ個の異なるフィールド“NumOfBuff”、“NumOfSDUs”、“ＭＡＣ ＳＤＵのサイズ”、および“ＣＭＣＨ−ＰＩ”もある。
【００９３】
ＵＥ識別フィールド“ＵＥ−ｉｄ”の内容はＲＮＴＩとすることができるが、Ｉｕｂインタフェース上での送信容量を節約するために、新たなより短い識別も定義できるであろう。かくしてこのフィールドの長さは、選択された識別の種類によって決まる。“ＵＥ−ｉｄ”フィールドの数は、１つのＨＳＤＰＡフレームが種々のＵＥのためのデータを含むことができるかどうかで決まる。もしこれが可能であれば、フィールドの数は“NumOfBuff”フィールドの数と等しくなければならない。しかしながら、もしＭＡＣ／ＦＰ ＵＥ−ＩＤ多重化が可能であれば、すなわち１より多いＵＥがＩｕｂインタフェース上で同じトランスポート接続を使用しているが、１つのＨＳＤＰＡ ＦＰフレームが１つのＲＮＣバッファのみからのデータを含み得るのであれば、要求されるＵＥ識別フィールドの数は１である。
【００９４】
図１１は、ＤＴＣＨまたはＤＣＣＨがＤＳＣＨにマッピングされる時およびＤＴＣＨまたはＤＣＣＨが唯一の論理チャネルである時のＭＡＣ ＰＤＵ構造を示し、これはＨＳＤＰＡについても使用できる。この図は、技術仕様書３ＧＰＰ ＴＳ ２５．３２１ Ｖ３．６．０（２０００−１２）：“第３世代パートナーシッププロジェクト；技術仕様書グループ無線アクセスネットワーク；ＭＡＣプロトコル仕様書（リリース１９９９）（3rd Generation Partnership Project; Technical Specification Group Radio Access Network; MAC protocol specification (Release 1999)）”から取った。
【００９５】
図１１のＭＡＣ ＰＤＵは、ＭＡＣ ＳＤＵとＭＡＣヘッダとで構成されている。ヘッダは、“ＵＥ−Ｉｄタイプ”フィールド、“ＵＥ−Ｉｄ”フィールドおよび“Ｃ／Ｔ”フィールドを含む。“ＵＥ−Ｉｄタイプ”および“ＵＥ−Ｉｄ”フィールドは、ＦＤＤのみのためにＭＡＣヘッダに含まれる。“ＵＥ−Ｉｄ”フィールドは、共通トランスポートチャネル上のＵＥの識別子を提供する。“ＵＥ−Ｉｄタイプ”フィールドは、ＭＡＣヘッダ中のＵＥ−Ｉｄフィールドの正確な復号を保証するために必要である。もしＭＡＣ上でのＣ／Ｔ多重化が適用されれば、“Ｃ／Ｔ”フィールドはＭＡＣヘッダに含まれる。多重論理チャネルが同じトランスポートチャネル上で運ばれる場合、“Ｃ／Ｔ”フィールドは論理チャネルインスタンスの識別を提供する。“Ｃ／Ｔ”フィールドは、ユーザデータ通信のために使用される場合に、専用トランスポートチャネル上ならびにＦＡＣＨ（順方向アクセスチャネル）およびＲＡＣＨ（ランダムアクセスチャネル）上の論理チャネルタイプの識別を提供するために使用される。“Ｃ／Ｔ”フィールドのサイズは、共通トランスポートチャネルおよび専用トランスポートチャネルの双方について４ビットに固定されている。
【００９６】
本発明の第１の形態として、図１０のフレーム構造に従ったフレーム中のＦＰフレームヘッダフィールド値が、ＲＮＣバッファのための２つの異なるモデルについてどのように設定されるかの例が最後に示される。
【００９７】
第１のバッファリングモデルは、図１２に例示される。この代替例において、ノードＢバッファ前の最後のＲＮＣバッファは、ＲＮＣ中のＲＬＣ層上に置かれる。
【００９８】
図１２は、そのようなＲＮＣバッファ９、ＲＬＣバッファｚ、ｈ、ｋ、ｙおよびｕの５つを示す。ＲＬＣバッファｚは、ユーザ装置ＵＥｘのためのデータ、より具体的にはこのＵＥのために使用された無線ベアラＲＢｚに割り当てられる。これは、１つのＲＬＣ ＰＤＵ中での使用のための優先順位レベルｒを有するデータを出力する。ＲＬＣバッファｈおよびｋは、双方ともユーザ装置ＵＥｙのために使用される無線ベアラＲＢｈおよびＲＢｋにそれぞれ割り当てられる。しかしながら、バッファｋのみは、配信用データをＲＬＣ
ＰＤＵに出力する。より具体的には、２つの論理チャネルがバッファｋによってＲＬＣ層から提供される。データに優先順位レベルｍが割り当てられ、このデータは２つのＲＬＣ ＰＤＵに配信される。ＲＬＣバッファｙおよびｕは、双方ともユーザ装置ＵＥｚのために使用される無線ベアラＲＢｙおよびＲＢｕにそれぞれ割り当てられる。バッファｖは、１つのＲＬＣ ＰＤＵ中で使用するための優先順位レベルｒを有するデータを出力する。バッファｕは、優先順位レベルｍを有するデータを出力し、このデータは、３つのＲＬＣ ＰＤＵに配信される。各ＲＬＣ ＰＤＵは、構成されれたＨＳＤＰＡ ＦＰフレーム中の１つのＭＡＣ−ｃ／ｓｈ ＳＤＵのための基礎としてＭＡＣ層中で使用される。
【００９９】
図１２のモデルにおいては、フィールド“NumOfBuff”の値をＲＢに基づいて定義できる。このことは、フィールド“NumOfBuff”の値がＲＢの数、従ってＨＳＤＰＡ ＦＰフレームのためのデータを提供するＲＬＣバッファ９の数と等しいことを意味する。かくして、提示された例において、図１０のフレーム構造に基づくデータフレームのフィールド“NumOfBuff”の値は４である。なぜならば、データは、ＲＮＣバッファのうちの４つ、すなわちＲＬＣバッファｚ、ｋ、ｙおよびｕから抽出されるからである。
【０１００】
ＲＬＣバッファｚについてのフィールド“NumOfSDUs”の値は１に設定される。なぜならば、現在のフレームのためのこのバッファから１つのＲＬＣ ＰＤＵのための唯一のデータが抽出されたからである。ＲＬＣバッファｋについては、フィールド“NumOfSDUs”の値は２に設定される。なぜならば、現在のフレームのためのこのバッファから２つのＲＬＣ ＰＤＵのためのデータが抽出されたからである。ＲＬＣバッファｖについては、フィールド“NumOfSDUs”の値は再度１に設定される。なぜならば、現在のフレームのためのこのバッファから１つのＲＬＣ ＰＤＵのための唯一のデータが抽出されたからである。ＲＬＣバッファｕについては、フィールド“NumOfSDUs”の値は３に設定される。なぜならば、現在のフレームのためのこのバッファから３つのＲＬＣ ＰＤＵのためのデータが抽出されたからである。
【０１０１】
フィールド“SizeOfSDUs”および“ユーザバッファサイズ”の値は、それぞれ適用可能な値に設定される。図示した例では、ユーザ装置ＵＥｙはＲＬＣエンティティを有しており、図に示されるように、これから２つの異なる論理チャネルがＭＡＣ層に提供される。そのような構成は、確認されたＲＬＣモードで可能である。たとえデータが２つの論理チャネルから受信されたとしても、バッファサイズ情報は結合される必要があり、このことは、“ユーザバッファサイズ”フィールドがＲＬＣバッファｋの状態についての情報を含んでいることを意味する。
【０１０２】
ＲＬＣバッファｚのためのフィールド“ＵＥ−ｉｄ”の値はｘに設定される。なぜならば、このバッファ中のデータはＵＥｘ用だからである。ＲＬＣバッファｋのためのフィールド“ＵＥ−ｉｄ”の値はｙに設定される。なぜならば、このバッファ中のデータはＵＥｙ用だからである。ＲＬＣバッファｙ及びｕのためのフィールド“ＵＥ−ｉｄ”の値はｚに設定される。なぜならば、これらのバッファ中のデータはＵＥｚ用だからである。
【０１０３】
ＲＬＣバッファｚおよびＲＬＣバッファｖそれぞれについてのフィールド“ＣＭＣＨ−ＰＩ”の値はｒに設定される。なぜならば、これらの２つのバッファから抽出されたデータについての優先順位レベルがｒに設定されたからである。ＲＬＣバッファｋおよびＲＬＣバッファｕそれぞれについてのフィールド“ＣＭＣＨ−ＰＩ”の値はｍに設定される。なぜならば、これらの２つのバッファから抽出されたデータについての優先順位レベルがｍに設定されたからである。
【０１０４】
ＲＮＣバッファを実現する別の方法は、ノードＢバッファ前の最後のバッファを、ＲＮＣのＭＡＣ層、例えば図１３に例示されるＭＡＣ−ｃ／ｓｈに置くことである。
【０１０５】
図１３に再度、ＲＮＣ、ＲＬＣバッファｚ、ｈ、ｋ、ｖおよびｕの５つのＲＬＣ層バッファ１０を示す。しかしながら、このケースでは、ＭＡＣバッファｚ、ｈ、ｋおよびｕｖという４つのＭＡＣ層バッファ１１がさらに存在する。
【０１０６】
ＲＬＣバッファｚは、ユーザ装置ＵＥｘのために使用される無線ベアラＲＢｚに再度割り当てられる。ＲＬＣバッファｚは、優先順位レベルｐを有するデータをＭＡＣバッファｚへ出力し、このＭＡＣバッファは、１つのＭＡＣ ＳＤＵにおいて使用するためのデータを出力する。ＲＬＣバッファｈおよびｋは、双方ともユーザ装置ＵＥｙにより使用される無線ベアラＲＢｈおよびＲＢｋにそれぞれ再度割り当てられる。ＲＬＣバッファｈはＭＡＣバッファｈに接続され、ＲＬＣバッファｋはＭＡＣバッファｋに接続されるが、ＲＬＣバッファｋのみが、ｍの優先順位レベルが割り当てられたデータをＭＡＣバッファｋに転送する。ＭＡＣバッファｋは、２つのＭＡＣ ＳＤＵに配信されるデータを出力する。ＲＬＣバッファｖおよびｕは、双方ともユーザ装置ＵＥｚにより使用される無線ベアラＲＢｙおよびＲＢｕにそれぞれ再度割り当てられる。ＲＬＣバッファｖおよびＲＬＣバッファｕは両方とも、同じ優先順位レベルｒを有する受信データをＭＡＣバッファｕｖへ出力する。ＭＡＣバッファｕｖは、４つのＭＡＣ ＳＤＵに配信されるデータを出力する。
【０１０７】
図１３によるバッファリングモデルにおいて、“NumOfBuff”フィールドの値は、ＭＡＣレベルバッファ１１の数を定義し、このバッファからデータが対応するＨＳＤＰＡ ＦＰデータフレームに供給される。かくして、提示された例においては、図１０のフレーム構造に基づくデータフレームのフィールド“NumOfBuff”の値は３に設定される。なぜならば、データは、３つのＭＡＣバッファ、すなわちＭＡＣバッファｚ、ｋ、およびｖｕから抽出されるからである。
【０１０８】
ＭＡＣバッファｚについてのフィールド“NumOfSDUs”の値は１に設定される。なぜならば、１つのＭＡＣ ＳＤＵについてのデータのみが、現在のフレームのためのこのバッファから抽出されたからである。ＭＡＣバッファｋについては、フィールド“NumOfSDUs”の値は２に設定される。なぜならば、２つのＭＡＣ ＳＤＵについてのデータが、現在のフレームのためのこのバッファから抽出されたからである。ＭＡＣバッファｕｖについては、フィールド“NumOfSDUs”の値は４に設定される。なぜならば、４つのＭＡＣ ＳＤＵについてのデータが、現在のフレームのためのこのバッファから抽出されたからである。
【０１０９】
フィールド“SizeOfSDUs”および“ユーザバッファサイズ”の値は、それぞれ適用可能な値に設定される。
【０１１０】
ＭＡＣバッファｚについてのフィールド“ＵＥ−ｉｄ”の値はｘに設定される。なぜならば、このバッファ中のデータはＵＥｘ用だからである。ＭＡＣバッファｋについてのフィールド“ＵＥ−ｉｄ”の値はｙに設定される。なぜならば、このバッファ中のデータはＵＥｙ用だからである。ＭＡＣバッファｕｖについてのフィールド“ＵＥ−ｉｄ”の値はｚに設定される。なぜならば、このバッファ中のデータはＵＥｚ用だからである。
【０１１１】
ＭＡＣバッファｚについてのフィールド“ＣＭＣＨ−ＰＩ”の値はｐに設定される。なぜならば、このバッファに提供されるデータについての優先順位レベルがｐに設定されたからである。ＭＡＣバッファｋについてのフィールド“ＣＭＣＨ−ＰＩ”の値はｍに設定される。なぜならば、このバッファに提供されるデータについての優先順位レベルがｍに設定されたからである。ＭＡＣバッファｕｖについてのフィールド“ＣＭＣＨ−ＰＩ”の値はｒに設定される。なぜならば、このバッファに提供されるデータについての優先順位レベルがｒに設定されたからである。
【０１１２】
図１３の例において、同じＵＥに割り当てられたいくつかのＲＢは、もしこれらが、例えば共通の優先順位値を持っていれば、共通ＭＡＣバッファ１１を使用し得る。ＲＢが割り当てられるＵＥにかかわらず、送信されたＵＥ情報についての共通の優先準位値を有するすべてのＲＢについて共通ＭＡＣバッファ１１を使うことが可能であろう。ただし、これによってフロー制御はずっと複雑になるであろう。
【０１１３】
一般に、本発明の第１の形態による種々のＨＳＤＰＡ ＦＰフレーム構造が提示され、これらは、ＨＳＤＰＡ関連ユーザデータを要求される付加情報と共にＲＮＣからＵＴＲＡＮのノードＢへ送信するための種々の状況について有利に使用し得る。提示されたフレーム構造は、特定の要件への最適適合を提供するためにどのような適当な方法ででも変更できる。
【０１１４】
ここで、Ｉｕｂインタフェースにより相互接続されたＲＮＣおよびノードＢを含むＨＳＤＰＡ可能ＵＴＲＡＮについて本発明の第２の形態の実施形態を提示する。この実施形態においては、Ｉｕｂ適用プロトコルが提供され、これは、ノードＢがＨＳＤＰＡを構成できるようにするために、Ｉｕｂインタフェース経由でノードＢへ送信される選択された制御メッセージにＲＮＣにより付加し得るいくつかのＩＥを定義する。
【０１１５】
図１４は、新しい準静的“ＨＳ＿ＤＳＣＨ情報”ＩＥのセットを有する表を示し、この表は、セル中でＨＳＤＰＡを構成するためにノードＢにより使用できるＨＳ−ＤＳＣＨ関連情報を有するセル関連パラメータおよび実装されたＨＡＲＱの特性を含む。この表は、例えば上記引用の技術仕様書ＴＳ ２５．４３３におけるＩＥを定義するために３ＧＰＰにより使用された表形式を備えている。これらの表は、ＩＥ／グループ名、ＩＥの存在に関する要件、範囲、ＩＥタイプおよび参照、意味説明、クリティカリティ、ならびに割り当てられたクリティカリティのためのそれぞれの列を含む。図１４では、列“ＩＥ／グループ名”のみが使用される。他の列は、それぞれの要件に応じて記入され得る。
【０１１６】
図１４の表のセット中の第１のＩＥは、“ＭＣＳセット”と呼ばれる。これは、ノードＢが送信のためのあらゆるＴＴＩを選ぶことができる変調および符号化方式（ＭＣＳ）のセットを含む。
【０１１７】
このセット中の第２のＩＥは、“ＨＳ＿ＤＳＣＨパワーレベル”と呼ばれる。このＩＥは、ＮＱＡＭ（ｎ−記号直交振幅変調）の場合にＨＳ−ＤＳＣＨとＣＰＩＣＨ（共通パイロットチャネル）コードパワーレベルとの間の関係を定義する。
【０１１８】
このセット中の第３のＩＥは、“NumOfCodes”と呼ばれ、これは、ＨＳ−ＤＳＣＨに割り当てられるコードチャネル数を定義する。ＲＮＣは、ＨＳ−ＤＳＣＨ特性の構成を可能にするために、セルについてのコードチャネル数を割り当てることができる。
【０１１９】
このセット中の第４のＩＥは、“ＴＴＩ選択”と呼ばれる。“ＴＴＩ選択”は、ノードＢが使用するＴＴＩ長さについての情報を含む。
【０１２０】
表中には“ＨＡＲＱ情報”がさらに含まれ、これは、いくつかのＨＡＲＱの特定ＩＥを含むことがあるＩＥグループであり、このＩＥは、選択されたＨＡＲＱ実装によって決まる。“ＨＡＲＱ情報”グループは、ノードＢ中でＨＡＲＱを構成するための情報を定義する。このグループのパラメータにより、ＲＮＣは、ノードＢの容量を限定することが可能になる。図１４において、ＩＥグループ“ＨＡＲＱ情報”は、ＩＥ“NumOfChannel”、“MaxAttempt”および“RedudancyVer”を含んでいる。ｎ−チャネルＳＡＷ−ＨＡＲＱが使用される場合、ＩＥ“NumOfChannel”は、ＲＮＣがチャネル数を構成できるようにするために含まれ得る。一定回数の試行後にノードＢがＵＥ再送信要求を拒否できることをさらに想定すると、ＩＥ“MaxAttempt”を含ませることによってＲＮＣは最大試行数をノードＢに提供することができ、ノードＢは、それ自身の条件に従ってこの制限の下で要求を拒否するかしないかを決めることができる。最後に、ソフトチェイズ（soft/chaise）組合わせ法の代わりに増分冗長度法（incremental redundancy）が使用される場合、ＩＥ“RedundancyVer”は、ノードＢがそれから選ぶことができる冗長度バージョンの制限を定義することができる。
【０１２１】
特に、ＩＥ“NumOfCodes”およびＩＥグループ“ＨＡＲＱ情報”に属するＩＥは、許容限度をノードＢに提供しており、このノードＢは、設定された限界内で適当な値を動的に選択することができる。代わりに、固定値としておよび／またはＲＬ特定値としてこれらのパラメータを区分することも可能であろう。
【０１２２】
説明したセルの特定ＩＥは、セル設定手順およびセル再構成手順に付加することができ、さらにＲＮＣによりノードＢに送信されるＨＳＤＰＡ関連セル設定要求メッセージおよびセル再構成要求メッセージ中にＲＮＣによって含めることができる。
【０１２３】
図１５〜１７はそれぞれ、ＨＳ−ＤＳＣＨチャネルを設定し再構成するためにノードＢにより使用できるＲＬ関連パラメータを含むＩＥのセットを有する表を示す。ＩＥは、無線リンク設定手順および同期無線リンク再構成準備手順中に加えることができる。これらの表は、図１４の表と同じ形式を有している。
【０１２４】
図１５の表は、ＩＥ“ＨＳ＿ＤＳＣＨ ＩＤ”のみを含んでいる。このＩＥは、ノードＢ通信コンテキスト内のＨＳ−ＤＳＣＨを一意に識別する。
【０１２５】
図１６の表は、“ＨＳ＿ＤＳＣＨ情報応答”ＩＥを含み、これらは、確立または変更されたＨＳ−ＤＳＣＨに情報を提供する。各ＩＥについてのエントリの範囲は、１から１つのＵＥ当たりのＨＳ−ＤＳＣＨの最大数までである。
【０１２６】
このセット中の第１のＩＥも、すでに言及したＩＥ“ＨＳ＿ＤＳＣＨ ＩＤ”であり、これは強制的に含まれるべきである。
【０１２７】
このセット中の第２のＩＥは、“バインディングＩＤ”と呼ばれ、任意に含み得る。“バインディングＩＤ”は、ユーザデータストリームの識別子である。この識別子はノードＢにおいて割り当てられ、これは、ノードＢへまたはノードＢからの確立中の各トランスポートベアラについて一意である。従って、意味はＤＳＣＨについてと同じである。
【０１２８】
このセット中の第３のＩＥは、“トランスポート層アドレス”と呼ばれ、同様に任意に含み得る。このＩＥは、ノードＢのトランスポートアドレスを定義する。従って、意味はＤＳＣＨについてと同じである。
【０１２９】
図１６の表のＩＥは、無線設定応答メッセージおよび無線リンク再構成実行可能メッセージ中に含めることができる。
【０１３０】
図１７の表は、“ＨＳ＿ＤＳＣＨ ＦＤＤ情報”ＩＥを含み、これは、確立されるＨＳ−ＤＳＣＨに情報を提供する。各ＩＥについてのエントリの範囲は再度、１から１つのＵＥ当たりのＨＳ−ＤＳＣＨの最大数までである。
【０１３１】
このセット中の第１のＩＥも、上記で言及したＩＥ“ＨＳ＿ＤＳＣＨ ＩＤ”である。
【０１３２】
このセット中の第２のＩＥは、“ＵＥ＿ＩＤ”と呼ばれ、ノードＢが種々のＵＥを識別できるようにするために使用される。このＩＥは、ＭＡＣヘッダに書き込むために使用される。これは、ＲＮＴＩまたは何か他のもの、例えば、ＵＥにとって分かりやすくなり得る新しい種類のユーザ装置アイデンティティ表示とし得る。
【０１３３】
このセット中の第３のＩＥは、“トランスポート形式セット”と呼ばれる。“トランスポート形式セット”は、トランスポートチャネル、例えばＨＳ−ＤＳＣＨに関連付けられたトランスポート形式のセットとして定義される。
【０１３４】
このセットの中第４のＩＥは、“割り当て／保持優先順位”と呼ばれる。このパラメータは、ノードＢの内部資源の割り当ておよび保持における優先順位レベルを示す。従って、意味はＤＳＣＨについてと同じである。
【０１３５】
このセットの第５のＩＥは、“フレーム取り扱い優先順位”と呼ばれる。このパラメータは、過負荷による割り当てられた資源の一時的制限のためにＨＳ−ＤＳＣＨの寿命の間に使用される優先順位レベルを示す。従って、意味はＤＳＣＨについて同じである。
【０１３６】
このセットの第６のＩＥは、“ToAWE”と呼ばれる。パラメータ“ToAWE”は、ウインドウエンドポイントの到着時間である。ダウンリンクデータフレームは、このウインドウエンドポイントの前に受信されると予想される。従って、意味はＤＳＣＨについて同じである。
【０１３７】
このセットの第７のＩＥは、“ToAWS”と呼ばれる。パラメータ“ToAWS”は、ウインドウスタートポイントの到着時間である。ダウンリンクデータフレームは、このウインドウスタートポイントの後に受信されると予想される。従って、意味はＤＳＣＨについて同じである。
【０１３８】
このセットの第８のＩＥは、“NumOfCodes”と呼ばれ、考えられるセルベースパラメータとしてすでに言及された。ＲＮＣは、それぞれのＵＥ機能に従ってこのパラメータについての値を選択することができるであろう。
【０１３９】
このセットの第９のＩＥは、“BufferStatus”と呼ばれ、ＲＮＣバッファの現在の状態を示す。このパラメータは、フロー制御のための接続の最初に使用できる。
【０１４０】
このセットには“ＨＡＲＱ容量”がさらに含まれており、これは、図１４の表中の”ＨＡＲＱ情報グループ“のものと同一のＨＡＲＱの特定ＩＥをいくつか含み得るＩＥグループである。ただし、たとえＩＥの名前がセル特定およびＲＬ特定双方のケースで同一であったとしても、意味は若干異なる。なぜならば、セル特定のケースにおいては、“ＨＡＲＱ情報”はセル容量を制限するのに対して、ＲＬ−特定のケースにおいては、“ＨＡＲＱ容量”は無線リンクまたはＵＥ機能のＱｏＳ（サービス品質）を反映するからである。
【０１４１】
この表のＩＥは、無線リンク設定要求メッセージおよび無線リンク再構成準備メッセージ中に含め得る。
【０１４２】
さらなるＨＳＤＰＡの特定のＩＥのセットは、変更されるＨＳ−ＤＳＣＨ情報について定義される。このセットは、“ＨＳ−ＤＳＣＨ ＦＤＤ情報”についてのセットのサブセットを含む。より具体的には、これは、ＩＥ“ＨＳ−ＤＳＣＨ ＩＤ”、“トランスポート形式セット”、“割り当て／保持優先順位”、“フレーム取り扱い優先順位”、“ToAWS”、“ToAWE”、および“NumOfCodes”を含み、そしてことによると“ＨＡＲＱ容量”グループのＩＥを含む。このセットのＩＥは、無線リンク再構成準備メッセージ中に含めることもできる。
【０１４３】
ＲＬ関連ＩＥの多くは、例えば、参照により本明細書に組み込まれ、更なる詳細について参照される上記引用の技術仕様書ＴＳ ２５．４３３中に提示されるＤＳＣＨ関連ＩＥと対応する意味を有している。
【０１４４】
ＤＳＣＨについてＩＥグループ“ＨＡＲＱ容量”が知られておらず、これはＲＬのＨＡＲＱ特徴を表すものであり、ＵＥ機能および／またはＲＬのＱｏＳも反映できる。
【０１４５】
さらに、ノードＢ中のＭＡＣヘッダの完了を助けるために、ＩＥ“ＵＥ＿ＩＤ”が新しいパラメータとして加えられた。もしＩＤがＭＡＣヘッダ中に全く含まれないか、または要求されなければ、このパラメータは代わりにＦＰ層上で同じ目的のために使用され得る。
【０１４６】
ＩＥ“トランスポート形式セット”は、ＤＳＣＨについての対応するＩＥと非常に似ているが、ＨＳ−ＤＳＣＨをサポートするために、いくつかのＩＥについて新規な値が定義されねばならない。これは図１８に示してあり、この図は、上記引用の仕様書ＴＳ ２５．４３３から取られたＤＳＣＨトランスポート形式セットについての表を示し、いくつかの変更には下線が付してある。
【０１４７】
より具体的には、“送信時間間隔”ＩＥについてより可能性のある値、すなわち“１スロット”、“３スロット”、“５スロット”および“１５スロット”が加えられる。これらの値は、ＨＳ−ＤＳＣＨのためのみに使用されるべきであり、他のどの値もＨＳ−ＤＳＣＨに適用されるべきではない。加えて、“畳み込み”値は、ＨＳＤＰＡについての“チャネルコーディングのタイプ”ＩＥにおいて使用されるべきではない。
【０１４８】
かくして、本発明の第２の形態の提示された実施形態において、基本的ＩＥが定義され、これらは、ＨＳＤＰＡをサポートするために、セル設定および再構成ならびにＲＬ設定および再構成の間に提供され得る。説明したＩＥのセットおよびＩＥ自身は、特定の要件に適合するように、任意の適当な方法で変更され得る。同様に、ＨＳＤＰＡ関連制御情報のどのような必要な転送も可能にするために、さらなるＩＥのセットがＩｕｂ適用プロトコル中に定義し得る。
【技術分野】
【０００１】
本発明は、通信ネットワーク、例えばＵＴＲＡＮ（Universal mobile telecommunication services terrestrial radio access network：汎用移動通信サービス地上無線アクセスネットワーク）のネットワーク要素、例えばノードＢに、データ、例えば前記ネットワーク要素において要求されるＨＳＤＰＡ（高速ダウンリンクパケットアクセス）関連データを提供するための方法に関する。一方では、本発明はより具体的には、通信ネットワーク内でユーザデータ、例えばＨＳＤＰＡ関連ユーザデータをコントローラからネットワーク要素へインタフェース、例えばＩｕｂインタフェースを介して送信するための方法に関する。他方では、本発明はより具体的には、通信ネットワーク、例えばＵＴＲＡＮの、ネットワーク要素、例えばノードＢに、インタフェース、例えばＩｕｂインタフェース経由で前記ネットワーク要素に接続されるコントローラである前記通信ネットワークのコントローラ、例えばＲＮＣにおいて利用可能な制御パラメータ、例えばＨＳＤＰＡ関連制御パラメータを提供するための方法に関する。本発明は、対応する通信ネットワーク、ネットワーク要素およびコントローラにも同様に関する。
【背景技術】
【０００２】
ＨＳＤＰＡは、３ＧＰＰ（第３世代パートナーシッププロジェクト）における共用チャネル概念の機能拡張としてＵＴＲＡＮアーキテクチャのために導入された概念である。
【０００３】
ＵＭＴＳにおいて、ＵＴＲＡＮは、すべての無線関連機能を取り扱う。この目的のために、ＵＴＲＡＮは、１つより多いＲＮＣを含み、各ＲＮＣに１つ以上のノードＢが接続される。ＵＴＲＡＮのＲＮＣは、Ｉｕインタフェース経由でコアネットワークに接続される。１つのＵＴＲＡＮのＲＮＣは、Ｉｕｒインタフェースによってさらに相互接続できる。ダウンリンク送信において、ＲＮＣは、ことによると別のＲＮＣ経由で、コアネットワークからユーザデータを受信し、これをＩｕｂインタフェース経由でノードＢへ送出する。ノードＢは次に、このデータをアドレス指定されたユーザ装置ＵＥへＵｕインタフェース経由で送信する。
【０００４】
ＵＴＲＡＮのＲＮＣは、種々の役割を担うことがある。制御ＲＮＣ（ＣＲＮＣ）は、例えばノードＢの特定のセットについて定義し得る。任意のノードＢについて、ただ１つのＣＲＮＣがある。ＣＲＮＣは、そのノードＢの論理資源についての全体的制御を有している。サービングＲＮＣ（ＳＲＮＣ）は、ＵＥとＵＴＲＡＮとの間の特定接続に関して定義し得る。ＵＴＲＡＮとの接続を有している各ＵＥについて１つのＳＲＮＣがある。ＳＲＮＣは、ＵＥとＵＴＲＡＮとの間の無線資源制御（ＲＲＣ）接続を担う。サービングＲＮＣは、このＵＥのためのＩｕも終了する。
【０００５】
ＦＤＤモードのためのＵＴＲＡＮにおける共用チャネル概念において、ＤＳＣＨ（ダウンリンク共用チャネル）は、いくつかのＵＥ間で動的に共用されるダウンリンクトランスポートチャネルとして定義される。ＤＳＣＨは、例えば技術仕様書３ＧＰＰ ＴＳ ２５．３０１ Ｖ３．６．０（２０００−０９）：“第３世代パートナーシッププロジェクト；技術仕様書グループ無線アクセスネットワーク；無線インタフェースプロトコルアーキテクチャ（リリース１９９９）（3rd Generation Partnership Project; Technical Specification Group Radio Access Network; Radio Interface Protocol Architecture (Release 1999)）”に記載されるように、ＣＲＮＣ中で構成されてノードＢ経由でＵＥへ送信される。
【０００６】
ＨＳＤＰＡの基本的な考え方は、ダウンリンク送信用にデータレートがより高くノードＢからのより迅速な再送信機構を有する共有高速チャネルを提供することである。共用高速チャネルは、トランスポートチャネルとしてのＨＳ−ＤＳＣＨ（高速ダウンリンク共用チャネル）およびＨＳ−ＰＤＳＣＨ（高速物理ダウンリンク共用チャネル）と共に別個の共用物理制御チャネルと組み合わされたＤＰＣＨ（専用物理チャネル）を含むことになっている。ノードＢ中に実装される高速再送信機構は、ＨＡＲＱ（ハイブリッド自動再送要求）である。
【０００７】
現在使用されているＤＳＣＨは、高いデータレートもサポートできるが、再送信は常に、ＲＮＣ中のＲＬＣ（無線リンク制御）層により提供され、このことがトランザクションを低下させる。
【０００８】
新しい機能、特にＨＡＲＱをサポートするため、参照により本明細書に組み込まれる技術報告書３ＧＰＰ ＴＲ ２５．８５５ Ｖ１．０．０（２００１−０６）：“第３世代パートナーシッププロジェクト；技術仕様書グループ無線アクセスネットワーク；高速ダウンリンクパケットアクセス；オーバーオールＵＴＲＡＮデスクリプション（リリース５）（3rd Generation Partnership Project; Technical Specification Group Radio Access Network; High Speed Downlink Packet Access; Overall UTRAN Description (Release 5)）”中に、新しいＭＡＣ（メディアアクセス制御）エンティティが導入された。新しいＭＡＣエンティティは、ＭＡＣ−ｈｓと呼ばれ、常にノードＢ中に置かれる。３ＧＰＰの前のリリースでは、ユーザプレーンデータも取り扱うことが可能なすべてのＵＴＲＡＮ
ＭＡＣエンティティは、常にもっぱらＲＮＣ中に置かれた。ＨＳＤＰＡ概念をサポートするようにセルが構成されている場合にのみ、ＭＡＣ−ｈｓは存在し、これはＲＮＣ中に置かれたＭＡＣ−ｃ／ｓｈにＩｕｂインタフェース経由で接続される。
【０００９】
論理チャネルをトランスポートチャネルにマッピングするＭＡＣ層が用いられる。論理チャネルは、ＲＮＣ中の無線リンク制御（ＲＬＣ）とＭＡＣ層との間に定義されるチャネルタイプである。各論理チャネルは、これを通ってどのような種類のデータが送信されようとしているかを定義する。ＨＳＤＰＡのケースでは、論理チャネルは常にＳＲＮＣ中に位置する。トランスポートチャネルは、ＭＡＣ層とＬ１（層１）との間で定義されるチャネルタイプである。これは、データが無線リンクを通ってどのように送信されるべきかを記述する。ＤＳＣＨ概念においては、トランスポートチャネルがＩｕｂインタフェース上に見られるのに対して、ＨＳＤＰＡ概念においては、トランスポートチャネルはノードＢ中の内部チャネルである。
【００１０】
ＨＳＤＰＡのためのＵＴＡＮの種々のＭＡＣの接続は図１に例示してあり、この図は上記引用の技術報告書ＴＲ２５．８５５から取った。
【００１１】
図１は、ノードＢ中に置かれたＭＡＣ−ｈｓ１、さらに１以上のＲＮＣ中に置かれたＭＡＣ−ｃ／ｓｈ２およびＭＡＣ−ｄ３を示す。ＭＡＣ−ｈｓ１はＩｕｂインタフェース経由でＭＡＣ−ｃ／ｓｈ２に接続されており、それに対して、ＭＡＣ−ｃ／ｓｈ２はＩｕｒインタフェース経由でＭＡＣ−ｄ３に、これらが異なるＲＮＣ中に置かれる場合には、接続されており、そうでなければ、これらのＭＡＣ２、３は局所的に相互接続される。ＭＡＣ制御は、ＭＡＣ１〜３の各々にアクセスできる。ＰＣＣＨ（ページングチャネル）およびＢＣＣＨ（報知制御チャネル）のような論理チャネルは、ＭＡＣ−ｄ３の介入なしにＭＡＣ−ｓｈ２に直接的にマッピングされる。しかしながら、ＤＣＣＨ（専用制御チャネル）およびＤＴＣＨ（専用トラフィックチャネル）のような論理チャネルは常にＭＡＣ−ｄ３に接続されており、これは、もしＵＥが共通チャネルあるいは共用チャネルへのアクセス権を有していれば、受信したデータパケットをＭＡＣ−ｃ／ｓｈ２へ送出する。ノードＢを介したＵＥへの送信のために、ＭＡＣ−ｃ／ｓｈ２およびＭＡＣ−ｄ３は、ＰＣＨ（ページングチャネル）、ＦＡＣＨ（順方向アクセスチャネル）、ＤＣＨ（専用チャネル）等の様々な種類の論理チャネルをトランスポートチャネル上へマッピングする。受信されたＨＳＤＰＡ関連データは、ＨＳ ＤＳＣＨにおけるＵＥへの送信のためのノードＢのＭＡＣ−ｈｓ１へのマッピングなしで、ＭＡＣ−ｄ３によりＭＡＣ−ｃ／ｓｈ２経由で提供される。図１の詳細については、技術報告書ＴＲ２５．８５５を参照されたい。
【００１２】
代わりに、ＭＡＣ−ｈｓはＭＡＣ−ｄに直接接続することもできるであろう。
【００１３】
以前はＲＮＣ中のみに実装された機能が、現在ではＴＦＣ（トランスポート形式組合わせ）選択のように、ノードＢにおいても提供されなければならないので、ノードＢとＲＮＣとの間の機能分割が再編成された。機能性の新しい分配は、図２および３に示してあり、これらの図は、同様に技術報告書ＴＲ２５．８５５から取られたものであり、ＭＡＣ−ｃ／ｓｈ２およびＭＡＣ−ｈｓ１によりそれぞれ提供される機能のいくつかをより詳細に提示している。
【００１４】
再編成と同時に、スケジューリング／優先順位取り扱いおよびＴＦＣ選択機能はＨＳＤＰＡ関連ダウンリンク送信のために図２におけるＲＮＣのＭＡＣ−ｃ／ｓｈ２から取り去られて、図３におけるノードＢのＭＡＣ−ｈｓ１に付加された。かくして、最終スケジューリングおよびリアルタイムトラフィック制御は、ＨＳＤＰＡについてはもはやＲＮＣの制御下にない。従って、図２におけるＭＡＣ−ｃ／ｓｈ２においては、ＭＡＣ−ｄから受信されたＨＳＤＰＡ関連データは、他のダウンリンクデータについてどのようなスケジューリング、優先順位取り扱いまたはＴＦＣ選択等も実行されることなく、図３のＭＡＣ−ｈｓ１に渡される。以前は、これらの機能は、ノードＢがＳＲＮＣに直接接続される場合にはＳＲＮＣにおいて、あるいはノードＢがＣＲＮＣに接続される場合にはＣＲＮＣにおいて、常に処理された。さらに、ＨＡＲＱは、図３の新しいＭＡＣ−ｈｓ１中に実装される。図２および３の詳細については、上記引用の技術報告書ＴＲ２５．８５５を参照されたい。
【００１５】
機能性の再編成は、ＲＮＣからノードＢへのダウンリンクユーザデータおよび要求される制御情報の既知の送信が適合させられなければならないことを意味する。
【００１６】
ダウンリンクユーザデータの送信については、ＲＬＣ層が変更されないことが提案された。このことは、ＲＬＣがこれまでのようにＲＬＣ ＰＤＵ（プロトコルデータユニット）をＲＮＣバッファ中にバッファすること、およびＲＮＣ、すなわちＭＡＣ−ｄ３上にあるＭＡＣ層の要求があった時にのみＲＬＣがデータを下層に送出することを意味する。従って、ＲＮＣ中のＭＡＣエンティティとノードＢ中のＭＡＣ−ｈｓ１との間のデータ送信をサポートするトランザクションは、現在高レベルにおいてのみ定義されるが、詳細はいまだ欠けている。これらの高レベル定義によって、ＲＮＣからノードＢへのデータフローを制御するために、図３に示されるように、フロー制御機能がＭＡＣ−ｃ／ｓｈ２とＭＡＣ−ｈｓ１との間で新しい特徴として定義される。
【００１７】
Ｉｕｂ−インタフェース上での実際のデータ送信をサポートするために、さらにＨＳ−ＤＳＣＨフレームプロトコル層（ＨＳ−ＤＳＣＨ ＦＰ）が、ＭＡＣ−ｃ／ｓｈの下およびＭＡＣ−ｈｓの上に含まれた。この層は図４に示してあり、この図もやはり技術報告書ＴＲ２５．８５５から取ったものである。図４は、ＨＳＤＰＡの無線インタフェースプロトコルアーキテクチャ、より具体的にはネットワーク要素の層を示し、このネットワーク要素は、左から右へかけて、Ｕｕインタフェース経由でノードＢに接続されるユーザ装置ＵＥであり、このノードＢはさらにＩｕｂインタフェース経由で第１のＲＮＣに接続され、この第１のＲＮＣはＩｕｒインタフェース経由で最終的に第２のＲＮＣに接続される。ノードＢ、第１および第２のＲＮＣの各々は、それぞれのＭＡＣエンティティに加えてＨＳ−ＤＳＣＨ ＦＰを含む。このＨＳ−ＤＳＣＨ ＦＰは、ＲＮＣからノードＢへのデータパケットだけでなく、関連制御情報も送信することを意図している。そのようなＦＰプロトコルが、ＩｕｂおよびＩｕｒインタフェース双方でのダウンリンクのデータ送信のためのどのような詳細もなしに提案されており、この送信は、ＭＡＣおよびＲＬＣのＬ２（層２）のサービスを使用している。図４の詳細については、上記引用の技術報告書ＴＲ２５．８５５を参照されたい。
【００１８】
しかしながら、Ｉｕｂインタフェースについて定義された現在のＦＰフレーム構造はどれもＨＳＤＰＡに適用可能ではない。特に、ＨＳＤＰＡについての提案がそれから生じるＤＳＣＨのために使用されるＦＰフレーム構造は、ＨＳＤＰＡデータ送信に適していない。なぜならば、ＤＳＣＨ ＦＰフレームは、スケジューリングまたはＴＦＣ選択がすでになされていた場合にのみその値が定義され得るフィールドを含んでいるからである。上記で言及したように、これらの機能はＨＳＤＰＡ関連送信のためにノードＢにシフトされた。さらに、ＤＳＣＨ ＦＰフレームは、ＨＳＤＰＡがＲＮＣとノードＢとの間のフロー制御をサポートするために必要な情報をすべて含んでいるわけではない。
【００１９】
ＨＳＤＰＡ関連ユーザデータに加え、ノードＢが送信のためのＨＳ−ＤＳＣＨチャネルを設定および再構成できるように、ノードＢにおいて制御情報も利用可能でなければならない。
【００２０】
機能の再編成に起因して、例えば技術仕様書３ＧＰＰ ＴＳ ２５．４３３ Ｖ３．４．１（２０００−１２）：“第３世代パートナーシッププロジェクト；技術仕様書グループ無線アクセスネットワーク；ＵＴＲＡＮＩｕｂインタフェースＮＢＡＰシグナリング（リリース１９９９）（3rd Generation Partnership Project ; Technical Specification Group Radio Access Network; UTRAN Iub Interface NBAP Signalling (Release 1999)）”に記載されるＤＳＣＨ設定および再構成のためのＩｕｂに関する現在の適用プロトコル手順は、ＨＳ−ＤＳＣＨについて使用できない。例えば、ＨＳＤＰＡのケースでは、ＤＳＣＨについての無線リンク（ＲＬ）設定の間に、チャネルコーディングパラメータを提供する必要はない。なぜならば、これらのチャネルコーディングパラメータはノードＢ中で決定されるからである。他方では、ＤＳＣＨのためにノードＢにより要求されないいくつかのパラメータは、ノードＢがセル中にＨＳ−ＤＳＣＨ属性を構成できるように、セル構成手順の間にＨＳＤＰＡのためにノードＢに提供されるべきである。さらに、これらのパラメータを好ましくは準静的な方法でセルベースに変更することが可能であるべきである。
【先行技術文献】
【非特許文献】
【００２１】
【非特許文献１】3GPP TS 25.435 V4.1.0，２００１年６月
【非特許文献２】3GPP TR 25.855 V1.0.0，２００１年６月
【非特許文献３】3GPP TS 25.425 V4.0.0，２００１年３月
【非特許文献４】3GPP TS 25.433 V4.1.0，２００１年６月
【発明の概要】
【課題を解決するための手段】
【００２２】
通信ネットワーク内で前記通信ネットワークのネットワーク要素において要求されるデータの送信を可能にすることが本発明の目的である。
【００２３】
ＵＴＲＡＮによるＨＳＤＰＡの使用を可能にすること、より具体的にはＵＴＲＡＮのＲＮＣがＨＳＤＰＡ関連データをＵＴＲＡＮのノードＢに提供できるようにすることも本発明の目的である。
【００２４】
ＲＮＣが適当な方法でＨＳＤＰＡ関連ユーザデータおよびＮＢＡＰ（ノードＢ適用部分）についてのＨＳＤＰＡ関連制御パラメータをノードＢに提供できるようにすることがとりわけ本発明の目的である。
【００２５】
本発明の第１の形態はユーザデータの送信を目的とするのに対して、本発明の第２の形態は制御パラメータの送信を目的とする。
【００２６】
本発明の第１の形態として、通信ネットワーク内でユーザデータをコントローラからネットワーク要素へインタフェース経由で送信するための方法が提案される。通信ネットワークは特にＵＴＲＡＮ、コントローラはＲＮＣ、ネットワーク要素はノードＢそしてインタフェースはＩｕｂインタフェースとすることができる。コントローラは、ユーザデータによってデータフレームを構成するために、少なくとも１つの専用フレーム構造、特に専用ＨＳＤＰＡ ＦＰフレーム構造を使う。次にデータフレームはインタフェース経由でネットワーク要素に送信される。フレーム構造は、ユーザデータを処理するために前記ネットワーク要素中で要求される情報を受信するための少なくとも１つのヘッダセクションを含んでいる。
【００２７】
本発明の第１の形態として、さらに、提案された方法を実現するための手段を含む、通信ネットワーク特にＵＴＲＡＮ、コントローラ特にＲＮＣ、およびネットワーク要素特にノードＢが提案される。
【００２８】
第１の形態に関し、本発明は、ＨＳＤＰＡ関連ユーザデータの処理に必要な情報の送信は、他の共用チャネルに使用される解決策と同様であるべきだが、ＨＳＤＰＡの要件についてなお最適化されるべきである、という考えから発している。提案された専用フレーム構造により、ＨＳＤＰＡにとりもはや必要ではないＤＳＣＨのための構造中で使用されたすべてのフィールドを削除すること、およびＨＳＤＰＡのために付加的に要求される情報のためのフィールドを挿入することが可能になる。かくして、Ｉｕｂインタフェース経由でのＨＳＤＰＡ関連ユーザデータのために必要な情報の最適化された送信が可能になる。同じ考えを他の通信ネットワーク、ネットワーク要素および状況に適用し得る。
【００２９】
本発明の第２の形態として、通信ネットワークのコントローラにおいて利用可能な制御パラメータを通信ネットワークのネットワーク要素に提供する方法が提案され、コントローラはインタフェース経由で前記ネットワーク要素に接続される。通信ネットワークは特にＵＴＲＡＮ、コントローラはＲＮＣ、ネットワーク要素はノードＢそしてインタフェースはＩｕｂインタフェースとすることができる。この方法は、少なくとも１つの制御パラメータ、特にＨＳＤＰＡ関連制御パラメータを、前記コントローラから前記ネットワーク要素へ前記インタフェース経由で送信された少なくとも１種類の制御メッセージ中に挿入することを可能にするインタフェース適用プロトコルを使用することを含む。
【００３０】
また本発明の第２の形態として、さらに、提案された方法を実現するための手段を含む、通信ネットワーク特にＵＴＲＡＮ、コントローラ特にＲＮＣ、およびネットワーク要素特にノードＢが提案される。
【００３１】
第２の形態に関し、本発明は、ＨＳ ＤＳＣＨチャネルを設定および再構成するために必要な制御パラメータをノードＢに提供するための最も効率的な方法は、ＲＮＣからノードＢに送信される制御メッセージ中にパラメータを含めることであるという考えに発する。ＲＮＣおよびノードＢはＩｕｂインタフェース経由で互いに接続されるので、従って、Ｉｕｂ適用プロトコルをそれに応じて変更することが提案される。結果として、ノードＢは、例えば、受信された制御パラメータに基づいてＨＳ−ＤＳＣＨチャネルを設定および再構成することが可能である。ノードＢは、従って、セル中のユーザ装置へのＨＳＤＰＡ関連データをサポートするようにＲＮＣによって構成できる。同じ考えを他の通信ネットワーク、ネットワーク要素および状況に適用し得る。
【００３２】
本発明の双方の形態は、ＲＮＣからノードＢへＩｕｂインタフェース経由でデータを送信するために使われる一般仕様のＨＳＤＰＡの特定の実現、すなわち、一方では専用フレーム構造の実現を、他方ではＨＳＤＰＡの特定の手順を持つＩｕｂ適用プロトコルの実現をこれらが含んでいるという点で共通している。
【００３３】
本発明の好ましい実施形態は、サブクレームから明らかになる。
【００３４】
本発明の第１の形態の好ましい実施形態において、フレーム構造は、前記コントローラによってＨＳＤＰＡ関連ユーザデータが配信された少なくとも１つのＳＤＵを受信するためのペイロードセクションをさらに含んでおり、ヘッダセクションは、ＨＳＤＰＡ関連ユーザデータを処理するためにネットワーク要素において要求される情報を受信する。かくして、ＨＳＤＰＡ関連ユーザデータを処理するためにノードＢにおいて要求される情報は、前記ユーザデータと一緒に単一フレームで有利に送信し得る。ＳＤＵは、特にＭＡＣ−ｄ ＳＤＵおよび／またはＭＡＣ−ｃ／ｓｈ ＳＤＵである。
【００３５】
本発明の第１の形態について、提案されたＨＳＤＰＡ ＦＰフレーム構造は、どのような数の情報も受信するように設計でき、情報は要件に従って任意に前もって決定し得る点に注目しなければならない。
【００３６】
さらに、ヘッダセクション中のみの情報、例えばＨＳＤＰＡフロー制御のための情報を送信するために同じ構造を使用し得るように、ペイロードセクションが、専用フレーム構造に従って構成されたフレーム中の任意のデータを含むことは必須とされるべきではない。
【００３７】
特に、ＭＡＣ／ＦＰ ＵＥ−ＩＤ多重化がＲＮＣ中で許可されているか、又は許可されていないかの場合のために、種々の各種ＦＰフレーム構造が提供され得る。ＵＥ−ＩＤ多重化は、種々のＵＥが同じトランスポートチャネル上に多重化されてＲＮＣのＭＡＣ層またはＦＰ層において実行できる多重化タイプである。ＦＰ ＵＥ−ＩＤ多重化のケースでは、ＦＰフレームのヘッダは常にＵＥ−ＩＤ識別を含むべきである。この識別は、例えばＲＮＴＩとすることができ、あるいは、この目的にのみ定義された新しい識別とし、従って現行のＲＮＴＩよりも短くすることができる。ＭＡＣ ＵＥ−ＩＤ多重化のケースでは、ＵＥ−ＩＤフィールドはＭＡＣヘッダ中で使用され、すなわち、ＲＮＴＩはＭＡＣヘッダ中に付加され、ＦＰフレーム中では識別が必然的に全く要求されない。ノードＢは、ＭＡＣヘッダを読むことによりＵＥ−ＩＤ情報を取り出すことができる。またその一方で、ＭＡＣヘッダ中へのＲＮＴＩの付加にもかかわらずＦＰフレームがＵＥ−ＩＤフィールドを含むことが望まれるのであれば、使用されるＵＥ−ＩＤは、例えばＲＮＴＩとすることができ、あるいは、この目的にのみ定義された新しい識別とし、従って現行ＲＮＴＩよりも短くすることができる。
【００３８】
多重化を実行できるさらに種々の選択可能な方法があり、使用される多重化方法は、ＦＰフレームの最適構造を決定する際に考慮されなければならないことがある。使用される多重化の種類は、特に、１つのＦＰフレーム中に提供される同じ種類のフィールド数への影響を特に持ち得る。多重化のための１つの代替方法は、時分割ベース多重化であり、これは、１つのＦＰデータフレームは、１つのＵＥにのみ属するデータを運ぶことができることを意味する。別の代替方法では、１つのＦＰフレーム中で種々のＵＥに属するデータを運ぶことが可能である。さらに、多重化は、ＦＰエンティティに、１つのＴＴＩ内の１つのＦＰフレームのみを送ることを可能にすることによって処理でき、このフレームは、ただ１つのＵＥに当てられるか、またはこのフレームは多くのＵＥのためのデータを送信できるであろう。多重化は、ＦＰエンティティが、１つのＵＥにすべて割当てられる１つのＴＴＩ内の１つより多いＦＰフレームを送り得ること、あるいは、各ＦＰフレームが、種々のＵＥのためのデータを運ぶことができるであろうことも意味し得る。
【００３９】
同様に、種々のＦＰフレーム構造は、ユーザ装置識別がＲＮＣからノードＢへ送信されなければならないか、またはされなくてもよい場合に提供できる。
【００４０】
１つの所定フレーム構造に基づくフレームのサイズは、各ユーザ装置またはデータが取られる各ＲＮＣバッファのための専用フィールドをヘッダセクション中のいくらかの情報に充てることによって可変にできる。フィールド構造は、情報のいくつかの挿入を任意にすることによりさらに一般化できる。
【００４１】
特定のフレーム構造により考慮に入れられるいくらかの情報は、ＲＮＣバッファまたはＲＮＣにおいてユーザデータをバッファリングするためにＨＳＤＰＡデータ通信において使用されるバッファリングと関連させることができる。ＲＮＣバッファリングまたはＲＮＣバッファの用語は、バッファの正確な位置を識別することなくＲＮＣにおけるバッファ能力を示すために使用されることに注目しなければならない。従って、バッファリングは、例えばＲＬＣ層上および／またはＭＡＣ層上で提供し得る。
【００４２】
本発明の第１の形態において、いくつかのユーザ装置の特定の情報はさらに、提案されたフレーム構造のヘッダセクションに含まれるか、あるいは提案されたフレーム構造のペイロードセクションに挿入されたそれぞれのＳＤＵのヘッダセクション中に含まれ得る。
【００４３】
本発明の第２の形態において、同様にＩｕｂ適用プロトコルは、任意の適当な種類および数のパラメータを要件に従って適当な種類のメッセージ中に含むことを可能にする。
【００４４】
本発明の第２の形態に従ってＲＮＣからノードＢへ提供されなければならないことがあり得る２クラスの制御パラメータがある。ＲＮＣがパラメータの正確な値を決めてノードＢがこの決定に続かなければならないか、さもなければＲＮＣは可能な選択の限界を提供する。後者のケースにおいて、ノードＢは、提供された限界内のそれ自身の条件に従って値を決めることができる。かくして、各制御パラメータの内容は、固定値、その値についての範囲の表示、または前記ノードＢにより使用されるべき許可された値のセットのいずれかである。
【００４５】
本発明の第２の形態の制御パラメータは特に、例えばセルの設定および／または再構成のためにノードＢにおいて要求されるセルの特定パラメータ、あるいは例えば無線リンクの設定および／または再構成のためにノードＢにおいて要求される無線リンクの特定パラメータとし得る。次に、パラメータが、セル設定または再構成に関連する制御メッセージ中あるいはＲＬ設定または再構成にそれぞれ関連する制御メッセージ中に含められるべきであることがＩｕｂ適用プロトコルによって決定され得る。
【００４６】
セルの特定パラメータおよびＲＬの特定パラメータ双方は、特定値または選択限界として提供できる。
【００４７】
本発明の第２の形態の制御パラメータを制御メッセージ中に含めるために、好ましくは１つ以上の情報要素（ＩＥ）またはＩＥのグループが定義される。各ＩＥは次に、特定状況のために要求される各パラメータのためのフィールドを含み得る。ＩＥは、この特定の状況おいて送信されなければならない制御メッセージに付加できる。さらに、ＤＳＣＨまたは対応するＩＥについて定義されたＩＥは、要求されるパラメータがいくつかの状況について同じである限り、使用することができる。それぞれの状況のために何らかの制御メッセージに付加されるべき特定の状況についてのＩＥのセットおよび／またはＩＥのグループを定義することも可能である。
【００４８】
以下、図面を参照して本発明をより詳細に説明する。
【図面の簡単な説明】
【００４９】
【図１】ＨＳＤＰＡのために定義された既知のＵＴＲＡＮ−サイドの全体のＭＡＣアーキテクチャを示す図である。
【図２】ＲＮＣの既知のＭＡＣ−ｃ／ｓｈの詳細を示す図である。
【図３】ノードＢの既知のＭＡＣ−ｈｓの詳細を示す図である。
【図４】ＨＳＤＰＡのために定義された既知の無線インタフェースプロトコルアーキテクチャを示す図である。
【図５】ＭＡＣレベル多重化がＲＮＣ中で全く許可されない場合の、Ｉｕｂのためのモデルを示す図である。
【図６】ＭＡＣレベル多重化がＲＮＣ中で許可される場合の、Ｉｕｂのためのモデルを示す図である。
【図７】既知のＤＳＣＨ ＦＰフレーム構造を示す図である。
【図８】本発明によるＨＤＳＰＡ ＦＰフレーム構造の第１の実施形態を示す図である。
【図９】本発明によるＨＤＳＰＡ ＦＰフレーム構造の第２の実施形態を示す図である。
【図１０】本発明によるＨＤＳＰＡ ＦＰフレーム構造の第３の実施形態を示す図である。
【図１１】ＭＡＣ ＰＤＵ構造を例示する図である。
【図１２】図１０の実施形態のための可能なＦＰフレームヘッダフィールド値の第１の例を示す図である。
【図１３】図１０の実施形態のための可能なＦＰフレームヘッダフィールド値の第２の例を示す図である。
【図１４】本発明の第２の形態の実施形態のためのセルの特定ＩＥのセットを示す図である。
【図１５】本発明の第２の形態の実施形態のためのＲＬセルの特定ＩＥのセットを示す図である。
【図１６】本発明の第２の形態の実施形態のためのＲＬセルの特定ＩＥの第１のセットを示す図である。
【図１７】本発明の第２の形態の実施形態のためのＲＬセルの特定ＩＥの第２のセットを示す図である。
【図１８】本発明の第２の形態の実施形態のための既知のＴＦＳの変更を例示する図である。
【発明を実施するための形態】
【００５０】
最初に、本発明の第１の形態に応じたＨＳＤＰＡ ＦＰフレーム構造の３つの実施形態を提示する。
【００５１】
それぞれのフレーム構造は、ＵＴＲＡＮ内でＨＳＤＰＡ関連ユーザデータをＲＮＣのＭＡＣ−ｃ／ｓｈからＩｕｂインタフェース経由でノードＢのＭＡＣ−ｈｓへ送信するために使用されるものである。ユーザデータがアドレスされるＵＥは、このノードＢに接続される。
【００５２】
適当なフレーム構造を決定する際、ネットワーク要素の要件および機能、すなわちＲＮＣおよびノードＢが考慮されるべきである。考慮されるべき１つの要因は、例えばＭＡＣ／ＦＰ ＵＥ−ＩＤ多重化であり、これは以下で説明されるように、ＲＮＣにおいて許可することもできるし、許可しないこともできる。
【００５３】
図５で例示される第１のモデルにおいて、ＲＮＣは、ＭＡＣ／ＦＰ ＵＥ−ＩＤレベル多重化を実行することができない。
【００５４】
図５は、Ｉｕｂインタフェースにより相互接続されたＲＮＣ４およびノードＢ５を概略的に示している。ＲＮＣ４は、ＲＬＣ６、ＭＡＣ−ｄおよびＭＡＣ−ｃ／ｓｈ２、３ならびにＦＰエンティティ７を含んでいる。同様にノードＢ５は、ＦＰエンティティ８、およびＭＡＣ−ｈｓ１を含んでいる。図示では、３つの無線ベアラＲＢｗ、ｚおよびｖは、第１のユーザ装置ＵＥｘに割り当てられるのに対して、さらに２つの無線ベアラＲＢｍおよびｎは、第２のユーザ装置ＵＥｙに割り当てられる。ＵＥｙのＲＢおよび同様にＵＥｘのＲＢｖは、多重化せずに論理チャネル中のＲＬＣ６からＭＡＣ−ｄおよびＭＡＣ−ｃ／ｓｈ２、３ならびにＦＰエンティティ７、ＩｕｂインタフェースおよびノードＢ５のＦＰエンティティ８経由でＭＡＣ−ｈｓ１へ渡される。ＵＥｘのＲＢｗおよびｚは、ＲＮＣ４のＭＡＣ層中でＣ／Ｔ多重化され、シングルトランスポート接続上を同じエンティティ経由でノードＢ５へ送信される。Ｃ／Ｔ多重化は、種々のＲＢ、すなわち種々の論理チャネルを使用しており、同じトランスポートチャネル上の同じＵＥにすべてが割り当てられるＲＢの多重化を意味する。次にＭＡＣ−ｈｓ１は、受信された論理チャネルをトランスポートチャネル上にマッピングする。
【００５５】
同じＵＥにすべてが割り当てられる無線ベアラ（ＲＢ）の間でＣ／Ｔ多重化が実行可能であれば、要求されるＩｕｂ送信接続の最小数は、ＨＳ−ＤＳＣＨにアクセスできるＵＥの数と等しい。Ｃ／Ｔ多重化は、例えば図５におけるように、いくつかのＵＥのいくつかのＲＢについてのみ、またはすべてのＵＥのすべてのＲＢについて、ＲＮＣにより使用され得る。
【００５６】
代わりに、同じＩｕｂ送信接続への種々の無線ベアラＲＢのＣ／Ｔ多重化は、図５のＲＮＣ４において許可されなくてもよい。Ｃ／Ｔ多重化は、すべての無線ベアラが同じＵＥに割り当てられれば、例えば種々の優先順位レベルのせいで、提供することさえできなくてもよい。このケースでは、Ｉｕｂインタフェース上のトランスポート接続の数は、ＨＳＤＰＡタイプトランスポート方法を使用している無線ベアラの数と等しい。
【００５７】
図６において例示される第２のモデルにおいて、ＲＮＣ４は対照的に、ＭＡＣレベルＵＥ−ＩＤ多重化を実行できる。
【００５８】
図６は、図５のようにＩｕｂインタフェースにより相互接続されたＲＮＣ４およびノードＢ５の同じ構造を概略的に示す。このケースにおいてのみ、独立したＭＡＣ−ｄ３およびＭＡＣ−ｃ／ｓｈ２が描かれている。さらに、同じ無線ベアラＲＢｗ、ｚ、ｖ、ｍおよびｎは、図５のように同じユーザ装置ＵＥｘ、ＵＥｙに割り当てられている。無線ベアラＲＢｗおよびＲＢｚは、再度ＭＡＣ層において、より詳細にはＭＡＣ−ｄ３により、Ｃ／Ｔ多重化される。さらに、Ｃ／Ｔ多重化ならびに３つの他の無線ベアラＲＢｖ、ｍおよびｎの出力は、ＭＡＣ−ｃ／ｓｈ２により、ＲＮＣ４のＦＰ層７、ＩｕｂインタフェースおよびノードＢ５のＦＰ層８経由でＭＡＣ−ｈｓ１へ送信するための単一のシングルトランスポート接続に多重化にされたＵＥ−ＩＤである。ＭＡＣ−ｈｓ１は最初に多重分離を実行し、次にトランスポートチャネル上への論理チャネルのマッピングを実行する。
【００５９】
ノードＢ５において、ＭＡＣ層は、受信した情報を、図５におけるようにこれをＨＳ−ＤＳＣＨにさらにＨＳ−ＰＤＳＣＨ上にマッピングする前に、対応して多重分離する。
【００６０】
多重化において使用される１つより多いトランスポート接続もあり得る。多重化における一般的な概念は、同じ基準を満たすすべてのＵＥは同じトランスポート資源を使うことが可能であるということである。多重化は、例えばノードＢ中のセル数に基づくことができる。これが意味するのは、もしノードＢが１より多いセルをサポートすれば、セル当たり１つのトランスポートが提供されるということである。代わりに、多重化は、論理チャネルに割り当てられた優先順位レベルに基づくことができ、すなわち優先準位当たり１つのトランスポート接続が提供される。さらに、単一トランスポート接続のみが１つのノード−Ｂに提供できる。多重化は、無線インタフェース上のＨＳＤＰＡ関連物理チャネル数に基づくこともできるであろう。
【００６１】
第２のモデルにおいて、ＭＡＣ／ＦＰ ＵＥ−ＩＤ多重化は、どのようにも限定されておらず、このことは、すべてのＵＥがＩｕｂインタフェース上の同じトランスポート接続を使用できることを意味する。
【００６２】
第２のモデルは、ＵＥ−ＩＤ多重化をＦＰ層に置くことによっても提供できる。両方のケースにおいて、もしＲＮＴＩがＭＡＣヘッダ中で使用されれば、ＦＰフレーム中でどのようなＵＥ−ＩＤも強制的ではなく、さらにもし識別がＭＡＣヘッダ中に全く含まれなくても多重化が可能であれば、ＦＰヘッダはＵＥ−ＩＤフィールドも含むはずである。
【００６３】
ＭＡＣ／ＦＰ ＵＥ−ＩＤ多重化が許可される場合、フレーム構造は、種々のＵＥに属する情報を受信されたＨＳＤＰＡフレームから受信機が正しく抽出できるように定義されるべきである。
【００６４】
ところで図７〜１０は、比較のために提示されたＩｕｂインタフェースのために定義された従来のＤＳＣＨ ＦＰフレーム構造、ＵＥ−ＩＤ多重化が全く許可されないケースについてのＨＳＤＰＡ ＦＰフレーム構造の第１の実施形態ならびにＵＥ−ＩＤ多重化が許可されケースについてのＨＳＤＰＡ ＦＰフレーム構造の第２および第３の実施形態を示す。
【００６５】
図７のＤＳＣＨ ＦＰフレーム構造は、技術仕様書３ＧＰＰ ＴＳ ２５．４３５、Ｖ３．５．０（２０００−１２）：“第３世代パートナーシッププロジェクト；技術仕様書グループ無線アクセスネットワーク；共通トランスポートチャネルデータストリームのためのＵＴＲＡＮ Ｉｕｂインタフェースユーザプレーンプロトコル（リリース１９９９）”から取った。このフレーム構造は、ペイロードセクションとヘッダセクションとで構成されており、各々が８ビット０−７の行に分割されている。ペイロードセクションは、第１から最終のＴＢ（トランスポートブロック）、“予備エクステンション”、および“ペイロードＣＲＣ”（巡回冗長検査）を含む。ヘッダセクションは、フィールド“ヘッダＣＲＣ”、“ＦＴ”、“ＣＦＮ”、“ＴＦＩ”、“パワーオフセット”、“コードナンバー”、“ＳＦ”および“ＭＣ情報”を含む。
【００６６】
“ＣＦＮ”フィールドは、接続フレーム数（ＣＦＮ）を示すために使用され、そこではフレームのデータは無線インタフェースを通して送信されるべきである。ＨＳＤＰＡ概念において、このフィールドの値は、対応するデータの無線インタフェースへのスケジューリング後に初めてノードＢにより知られ、従ってＲＮＣはこのフィールドをノードＢへ提供できない。
【００６７】
“ＴＦＩ”フィールドは、フレーム中のデータにとり有効なトランスポートフォーマット（ＴＦ）を示すために使用される。ＨＳＤＰＡ概念において、ＴＦＣ選択はノードＢにおいて実行され、従って、ＲＮＣはそのような情報をノードＢに送出できない。
【００６８】
“パワーオフセット”フィールドは、対応するＦＰフレームのデータを送信するために要求されるパワーレベルを示すために使用される。ＤＳＣＨのために閉ループパワー制御が提供されるので、このフィールドはＤＳＣＨのケースにおいて要求される。ＨＳＤＰＡのケースでは、閉ループパワー制御は全く提供されず、従って、パワー制御情報はＲＮＣから全く要求されない。
【００６９】
“コードナンバー”フィールドは、ＤＳＣＨのために使用されるコードを示す。ＨＳＤＰＡのケースでは、コード選択はノードＢにおいてなされ、従って、そのような情報はＲＮＣから全く要求されない。
【００７０】
“ＳＦ”フィールドは、フレーム中の対応データパケットのためにＰＤＳＣＨ中で使用される拡散率（ＳＦ）を特定する。ＨＳＤＰＡ概念において、ＳＦはノードＢにおいて定義され、従って、そのような情報はＲＮＣから全く要求されない。
【００７１】
“ＭＣ情報”フィールドは、ＤＳＣＨデータがその上を運ばれる平行ＰＤＳＣＨコードの数を示すために使用される。ＨＳＤＰＡ概念において、この種の情報はノードＢにおいて定義されて、従って、そのような情報はＲＮＣから全く要求されない。
【００７２】
かくして、“ヘッダＣＲＣ”フィールドおよび“ＦＴ”（フレームタイプ）フィールドを除くヘッダセクションのフィールドのどれもＨＳＤＰＡのために要求されず、これらのフィールドは、ＨＳＤＰＡＦＰフレーム構造を設計する際に排除し得る。しかし、他方で、もしフィールドが単に排除されると、ノードＢは、受信されたＦＰフレームを抽出するための十分な情報を受信しない。従って、新しいＭＡＣエンティティＭＡＣ−ｈｓがノードＢ中に置かれる時にフロー制御機構が機能することを保証するために、新しいフィールドが要求される。
【００７３】
図８は、ＭＡＣ／ＦＰ ＵＥ−ＩＤ多重化が全く許可されないケースのためのそのような新しいフィールドを含むＨＳＤＰＡフレーム構造を示す。これも、ペイロードセクションとヘッダセクションとで構成されており、各々が８ビットの行に分割されている。ＤＳＣＨフレーム構造と同様に、ペイロードセクションは、第１から最終のＭＡＣ−ｃ／ｓｈ
ＳＤＵ（サービスデータユニット）、“予備エクステンション”、および“ペイロードＣＲＣ”を含む。可変ヘッダを持つＭＡＣ ＳＤＵの構造は、ＭＡＣ ＰＤＵとして最新技術から既知であり、図１１を参照して以下で説明される。ヘッダセクションは現在、“ヘッダＣＲＣ”、“ＦＴ”、“NumOfSDUs”、“ユーザバッファサイズ”、“ＵＥ−ＩＤタイプ”、および“ＣＭＣＨ−ＰＩ”と呼ばれるフィールドを含んでいる。特に、最後の２つのフィールドの導入は任意である。
【００７４】
“NumOfSDUs”フィールドは、フレーム中のＭＡＣ−ｃ／ｈｓ ＳＤＵの数を示すために使用される。フィールドの長さは適切に選択され得る。
【００７５】
“ユーザバッファサイズ”フィールドは、ＲＮＣバッファ中のそれぞれのＵＥに割り当てられたバッファの状態を示すために使用される（例えば、バイトで）。このフィールドは、同じデータフローに属するデータがＲＮＣ中にまだどれだけ残されているかをノードＢに知らせる。対応するＦＰデータフレーム中で運ばれたデータ量は、ユーザバッファサイズ情報フィールドから除外されるか、あるいはそれに含まれ得る。ノードＢは、例えばスケジューリングにおいてこの情報を使用することができ、その結果、優先順位が最も高くＲＮＣバッファ中の大部分のデータを有するデータフローは、優先順位がより低くＲＮＣバッファ中のデータをより少なく有するデータフローよりも早くＨＳＤＰＡチャネルにアクセスできる。用語ＲＮＣバッファの種々の考えられる意味は、以下で図１２および１３を参照して説明される。フィールドの長さは適切に選ばれ得る。
【００７６】
“ＵＥ Ｉｄタイプ”フィールドは、どのような種類のＲＮＴＩ、すなわちｃ−ＲＮＴＩまたはＵ−ＲＮＴＩを、ノードＢのＭＡＣ−ｈｓがＭＡＣヘッダに加えるべきかを示すために使用される。タイプＵ−ＲＮＴＩ（ＵＴＲＡＮ無線ネットワーク一時アイデンティティ）は、ＭＡＣ ＰＤＵのＭＡＣヘッダにおいて使用することができ、ペイロード部分は、Ｕ−ＲＮＴＩの使用が強制的な場合に、特定のＬ３（ＲＲＣ）シグナリングメッセージを含む。この種の状況は、ＭＡＣヘッダ中のＣ−ＲＮＴＩの代わりにＵ−ＲＮＴＩを使用する命令をＬ２（ＲＬＣ層経由でＭＡＣ層）に送ることによってＲＲＣにより報告される。タイプＣ−ＲＮＴＩ（セル無線ネットワーク一時アイデンティティ）は、ＦＤＤ（周波数分割二重）モードでＤＴＣＨおよびＤＳＣＨ上で使用され、Ｕ−ＲＮＴＩを使用する要求が上位層（ＲＲＣ）から全く受信されない場合に、ＭＡＣヘッダ中で使用し得る。ＲＮＴＩがノードＢに加えられるように指定される場合に限り、ＵＥ ＩＤタイプフィールドが要求される。もしＲＮＴＩがＳＲＮＣに加えられるように指定されるか、あるいはＨＳＤＰＡデータ通信のためにＲＮＴＩが全く使用されなければ、そのようなフィールドはＨＳＤＰＡ ＦＰデータフレームにおいて要求されない。フィールド長さは１ビットである。
【００７７】
共通トランスポートチャネル優先順位インジケータ（“ＣＭＣＨ−ＰＩ”）フィールドは、データフレームおよび／または含まれているＳＤＵの相対的優先順位を示すために使用される。ＨＳＤＰＡデータ送信のためにこのフィールドの使用を導入できるが、多重化が全く提供されない場合にＲＢの優先順位は、Ｉｕｂを介した対応するトランスポート接続が構成された時の直後に導入できるであろう。
【００７８】
ＨＳＤＰＡ ＦＰフレーム構造のこの第１の実施形態においては、ＭＡＣ ＳＤＵサイズ情報のためのフィールドが含まれる必要はない。なぜならば、ＨＳＤＰＡについては、準静的ＴＢサイズが使用されることが定義されており、そこにおいてＭＡＣ ＳＤＵは、多重化が全く許可されないケースでは固定サイズになるからである。
【００７９】
図９は、ＭＡＣ／ＦＰ ＵＥ−ＩＤ多重化が許可されるケースのための新しいフィールドを含むＨＳＤＰＡフレーム構造を示す。これも、ペイロードセクションとヘッダセクションとで構成されており、各々が８ビットの行に分割されている。ＤＳＣＨ ＦＰフレーム構造およびＨＳＤＰＡ ＦＰフレーム構造の第１の実施形態と同様に、ペイロードセクションは、第１から最終のＭＡＣ−ｃ／ｓｈ ＳＤＵ（サービスデータユニット）、“予備エクステンション”、および“ペイロードＣＲＣ”を含んでいる。ヘッダセクションは現在、“ヘッダＣＲＣ”、“ＦＴ”、“NumOfSDUs”、“NumOfBuff”、“ＭＡＣ ＳＤＵのサイズ”、“ユーザバッファサイズ”１−Ｎ、“ＵＥ−ＩＤタイプ”、および“ＣＭＣＨ−ＰＩ”と呼ばれるフィールドを含んでいる。“NumOfSDUs”、“NumOfBuff2”、“ＭＡＣ ＳＤＵのサイズ”、および“ＣＭＣＨ−ＰＩ”についても、たとえ各パラメータについて１つのフィールドしか図中に示されていなくても、複数のフィールドがあり得る。
【００８０】
“NumOfSDUs”フィールドは、１つのＲＮＣバッファから取られたＭＡＣ−ｃ／ｓｈ ＳＤＵの数を識別するために使用される。フィールド長さは適切に設定できる。この種のフィールドの数は、“NumOfBuff”フィールドの数と等しい。
【００８１】
“NumOfBuff”フィールドは、いくつのＲＮＣバッファからデータがこのＦＰフレームに供給されたかを示す。このフィールドは、データがそれから供給できたＲＮＣバッファの数を記述するわけではないことに注目しなければならない。フィールド長さは適切に設定できる。
【００８２】
ＭＡＣ多重化が強制的な特徴ではない、すなわちＭＡＣ／ＦＰ ＵＥ−ＩＤ多重化が許可されていたとしてもオペレータによってはそれを使わないことを望むことがあり得るので、“ＭＡＣ ＳＤＵのサイズ”フィールドが導入される。従って、ＭＡＣ／ＦＰ ＵＥ−ＩＤ多重化が許可されている場合にマルチベンダのケースをサポートするため、ＭＡＣ
ＳＤＵのサイズフィールドがそれぞれのフレーム中のＳＤＵのサイズを定義する。原則的に、ＴＢは、ＨＳＤＰＡ中で常に固定サイズを有しているが、ＭＡＣ／ＦＰ ＵＥ−ＩＤ多重化がサポートされているかいないかに応じてＭＡＣヘッダの長さが可変なので、ＭＡＣ ＳＤＵのサイズは、ＭＡＣヘッダの内容または存在に応じて変わり得る。この情報は、ＨＳＤＰＡデータフレームからＳＤＵを正しく抽出するために、受信機側で要求される。フィールドの長さは適切に設定できる。
【００８３】
“ユーザバッファサイズ”フィールドは、ＲＮＣバッファ中の１つのＵＥに割り当てられたバッファの状態をバイトで示すために使用される。フィールドの長さは適切に設定できる。フレーム中のこの種のフィールドの数は、“NumOfBuff”フィールドの数と等しい。
【００８４】
“ＣＭＣＨ−ＰＩ”フィールドは、ＭＡＣ／ＦＰ ＵＥ−ＩＤ多重化が許可されている場合にデータの優先順位についての情報を提供するために使用できるであろう。種々の優先順位レベルを有するデータを多重化することが可能であれば、この種のフィールドの数は、“NumOfBuffer”フィールドの数と等しくなければならないが、そのような多重化が全く許可されないのであれば、フレーム当たり１つの“ＣＭＣＨ−ＰＩ”フィールドを提供すれば十分である。
【００８５】
たとえＭＡＣ／ＦＰ ＵＥ−ＩＤ多重化が許可されていても、１つのＨＳＤＰＡ ＦＰフレームが、１つのＵＥまたはＲＢに属するデータのみを含み得るという制約が識別されれば、それぞれの多重化関連フィールド“NumOfSDU”、“ユーザバッファサイズ”、“ＭＡＣ ＳＤＵのサイズ”および“ＣＭＣＨ−ＰＩ”の数を減らすことができる点に注目しなければならない。このケースにおいて、ＭＡＣ／ＦＰ ＵＥ−ＩＤ多重化は、時分割法に基づいてなされる。
【００８６】
第３の実施形態として提示されるＨＳＤＰＡ ＦＰフレーム構造のさらなる変更は、ＨＳＤＰＡ関連データ送信におけるユーザ装置の識別に関する。
【００８７】
もしノードＢにおいてＵＥ識別が全く要求されず、従ってＭＡＣ／ＦＰ ＵＥ−ＩＤ多重化がＲＮＣにおいて全く許可されなければ、ＵＥの識別は、ＲＮＣにもノードＢにも含まれない。むしろデータは、他の方法を使用して識別される。
【００８８】
しかしながら、ＵＥ識別が要求されるのであれば、この情報がデータと結合され得る場所は、ＣＲＮＣ中のＭＡＣ−ｃ／ｓｈまたはノードＢ中のＭＡＣ−ｈｓである。最初のケースでは、使用されるＵＥ識別は、現在使用されているＲＮＴＩとするか、Ｉｕｂインタフェースを介してのデータ送信についてのみ定義される新しいＵＥ識別とし得る。
【００８９】
もしＲＮＴＩが使用されれば、ＵＥ識別情報は、この目的のためのフィールドをすでに有しているＭＡＣ−ｃ／ｓｈ ＳＤＵヘッダ中か、それぞれのＨＳＤＰＡ ＦＰデータフレームのヘッダセクション中に含まれ得る。もしＭＡＣ−ｃ／ｓｈ ＳＤＵヘッダ中に含まれれば、ノードＢは、ＵＥのアイデンティティを見い出すために、このヘッダ部分を抽出しなければならない。もしＵＥアイデンティティがＨＳＤＰＡ ＦＰデータフレームのヘッダセクション中に含まれれば、抽出は全く要求されない。
【００９０】
図９のフレーム構造については、もしＵＥ識別が要求されれば、識別はＲＮＴＩであり、ＣＲＮＣ中かノードＢ中のＭＡＣ ＳＤＵヘッダ中に含まれると想定された。
【００９１】
エアインタフェース上においてＲＮＴＩは全く要求されないが、Ｉｕｂ上でＵＥ識別が依然として要求されるケースについては、フレーム構造の第３の実施形態が提案され、これは図１０に例示される。
【００９２】
図１０のフレーム構造は、ＭＡＣ／ＦＰ ＵＥ−ＩＤ多重化を再びサポートし、図９のフレーム構造中に存在するすべてのフィールドを含む。このフレーム構造は、ＵＥを識別するための付加的フィールド“ＵＥ−ｉｄ１”から“ＵＥ−ＩｉｄＮ”までを含み、ペイロードセクション中のＭＡＣ−ｃ／ｓｈ ＳＤＵ中にはＵＥのためのデータが含まれる。この図には、それぞれ明示的に示されるＮ個の異なるフィールド“NumOfBuff”、“NumOfSDUs”、“ＭＡＣ ＳＤＵのサイズ”、および“ＣＭＣＨ−ＰＩ”もある。
【００９３】
ＵＥ識別フィールド“ＵＥ−ｉｄ”の内容はＲＮＴＩとすることができるが、Ｉｕｂインタフェース上での送信容量を節約するために、新たなより短い識別も定義できるであろう。かくしてこのフィールドの長さは、選択された識別の種類によって決まる。“ＵＥ−ｉｄ”フィールドの数は、１つのＨＳＤＰＡフレームが種々のＵＥのためのデータを含むことができるかどうかで決まる。もしこれが可能であれば、フィールドの数は“NumOfBuff”フィールドの数と等しくなければならない。しかしながら、もしＭＡＣ／ＦＰ ＵＥ−ＩＤ多重化が可能であれば、すなわち１より多いＵＥがＩｕｂインタフェース上で同じトランスポート接続を使用しているが、１つのＨＳＤＰＡ ＦＰフレームが１つのＲＮＣバッファのみからのデータを含み得るのであれば、要求されるＵＥ識別フィールドの数は１である。
【００９４】
図１１は、ＤＴＣＨまたはＤＣＣＨがＤＳＣＨにマッピングされる時およびＤＴＣＨまたはＤＣＣＨが唯一の論理チャネルである時のＭＡＣ ＰＤＵ構造を示し、これはＨＳＤＰＡについても使用できる。この図は、技術仕様書３ＧＰＰ ＴＳ ２５．３２１ Ｖ３．６．０（２０００−１２）：“第３世代パートナーシッププロジェクト；技術仕様書グループ無線アクセスネットワーク；ＭＡＣプロトコル仕様書（リリース１９９９）（3rd Generation Partnership Project; Technical Specification Group Radio Access Network; MAC protocol specification (Release 1999)）”から取った。
【００９５】
図１１のＭＡＣ ＰＤＵは、ＭＡＣ ＳＤＵとＭＡＣヘッダとで構成されている。ヘッダは、“ＵＥ−Ｉｄタイプ”フィールド、“ＵＥ−Ｉｄ”フィールドおよび“Ｃ／Ｔ”フィールドを含む。“ＵＥ−Ｉｄタイプ”および“ＵＥ−Ｉｄ”フィールドは、ＦＤＤのみのためにＭＡＣヘッダに含まれる。“ＵＥ−Ｉｄ”フィールドは、共通トランスポートチャネル上のＵＥの識別子を提供する。“ＵＥ−Ｉｄタイプ”フィールドは、ＭＡＣヘッダ中のＵＥ−Ｉｄフィールドの正確な復号を保証するために必要である。もしＭＡＣ上でのＣ／Ｔ多重化が適用されれば、“Ｃ／Ｔ”フィールドはＭＡＣヘッダに含まれる。多重論理チャネルが同じトランスポートチャネル上で運ばれる場合、“Ｃ／Ｔ”フィールドは論理チャネルインスタンスの識別を提供する。“Ｃ／Ｔ”フィールドは、ユーザデータ通信のために使用される場合に、専用トランスポートチャネル上ならびにＦＡＣＨ（順方向アクセスチャネル）およびＲＡＣＨ（ランダムアクセスチャネル）上の論理チャネルタイプの識別を提供するために使用される。“Ｃ／Ｔ”フィールドのサイズは、共通トランスポートチャネルおよび専用トランスポートチャネルの双方について４ビットに固定されている。
【００９６】
本発明の第１の形態として、図１０のフレーム構造に従ったフレーム中のＦＰフレームヘッダフィールド値が、ＲＮＣバッファのための２つの異なるモデルについてどのように設定されるかの例が最後に示される。
【００９７】
第１のバッファリングモデルは、図１２に例示される。この代替例において、ノードＢバッファ前の最後のＲＮＣバッファは、ＲＮＣ中のＲＬＣ層上に置かれる。
【００９８】
図１２は、そのようなＲＮＣバッファ９、ＲＬＣバッファｚ、ｈ、ｋ、ｙおよびｕの５つを示す。ＲＬＣバッファｚは、ユーザ装置ＵＥｘのためのデータ、より具体的にはこのＵＥのために使用された無線ベアラＲＢｚに割り当てられる。これは、１つのＲＬＣ ＰＤＵ中での使用のための優先順位レベルｒを有するデータを出力する。ＲＬＣバッファｈおよびｋは、双方ともユーザ装置ＵＥｙのために使用される無線ベアラＲＢｈおよびＲＢｋにそれぞれ割り当てられる。しかしながら、バッファｋのみは、配信用データをＲＬＣ
ＰＤＵに出力する。より具体的には、２つの論理チャネルがバッファｋによってＲＬＣ層から提供される。データに優先順位レベルｍが割り当てられ、このデータは２つのＲＬＣ ＰＤＵに配信される。ＲＬＣバッファｙおよびｕは、双方ともユーザ装置ＵＥｚのために使用される無線ベアラＲＢｙおよびＲＢｕにそれぞれ割り当てられる。バッファｖは、１つのＲＬＣ ＰＤＵ中で使用するための優先順位レベルｒを有するデータを出力する。バッファｕは、優先順位レベルｍを有するデータを出力し、このデータは、３つのＲＬＣ ＰＤＵに配信される。各ＲＬＣ ＰＤＵは、構成されれたＨＳＤＰＡ ＦＰフレーム中の１つのＭＡＣ−ｃ／ｓｈ ＳＤＵのための基礎としてＭＡＣ層中で使用される。
【００９９】
図１２のモデルにおいては、フィールド“NumOfBuff”の値をＲＢに基づいて定義できる。このことは、フィールド“NumOfBuff”の値がＲＢの数、従ってＨＳＤＰＡ ＦＰフレームのためのデータを提供するＲＬＣバッファ９の数と等しいことを意味する。かくして、提示された例において、図１０のフレーム構造に基づくデータフレームのフィールド“NumOfBuff”の値は４である。なぜならば、データは、ＲＮＣバッファのうちの４つ、すなわちＲＬＣバッファｚ、ｋ、ｙおよびｕから抽出されるからである。
【０１００】
ＲＬＣバッファｚについてのフィールド“NumOfSDUs”の値は１に設定される。なぜならば、現在のフレームのためのこのバッファから１つのＲＬＣ ＰＤＵのための唯一のデータが抽出されたからである。ＲＬＣバッファｋについては、フィールド“NumOfSDUs”の値は２に設定される。なぜならば、現在のフレームのためのこのバッファから２つのＲＬＣ ＰＤＵのためのデータが抽出されたからである。ＲＬＣバッファｖについては、フィールド“NumOfSDUs”の値は再度１に設定される。なぜならば、現在のフレームのためのこのバッファから１つのＲＬＣ ＰＤＵのための唯一のデータが抽出されたからである。ＲＬＣバッファｕについては、フィールド“NumOfSDUs”の値は３に設定される。なぜならば、現在のフレームのためのこのバッファから３つのＲＬＣ ＰＤＵのためのデータが抽出されたからである。
【０１０１】
フィールド“SizeOfSDUs”および“ユーザバッファサイズ”の値は、それぞれ適用可能な値に設定される。図示した例では、ユーザ装置ＵＥｙはＲＬＣエンティティを有しており、図に示されるように、これから２つの異なる論理チャネルがＭＡＣ層に提供される。そのような構成は、確認されたＲＬＣモードで可能である。たとえデータが２つの論理チャネルから受信されたとしても、バッファサイズ情報は結合される必要があり、このことは、“ユーザバッファサイズ”フィールドがＲＬＣバッファｋの状態についての情報を含んでいることを意味する。
【０１０２】
ＲＬＣバッファｚのためのフィールド“ＵＥ−ｉｄ”の値はｘに設定される。なぜならば、このバッファ中のデータはＵＥｘ用だからである。ＲＬＣバッファｋのためのフィールド“ＵＥ−ｉｄ”の値はｙに設定される。なぜならば、このバッファ中のデータはＵＥｙ用だからである。ＲＬＣバッファｙ及びｕのためのフィールド“ＵＥ−ｉｄ”の値はｚに設定される。なぜならば、これらのバッファ中のデータはＵＥｚ用だからである。
【０１０３】
ＲＬＣバッファｚおよびＲＬＣバッファｖそれぞれについてのフィールド“ＣＭＣＨ−ＰＩ”の値はｒに設定される。なぜならば、これらの２つのバッファから抽出されたデータについての優先順位レベルがｒに設定されたからである。ＲＬＣバッファｋおよびＲＬＣバッファｕそれぞれについてのフィールド“ＣＭＣＨ−ＰＩ”の値はｍに設定される。なぜならば、これらの２つのバッファから抽出されたデータについての優先順位レベルがｍに設定されたからである。
【０１０４】
ＲＮＣバッファを実現する別の方法は、ノードＢバッファ前の最後のバッファを、ＲＮＣのＭＡＣ層、例えば図１３に例示されるＭＡＣ−ｃ／ｓｈに置くことである。
【０１０５】
図１３に再度、ＲＮＣ、ＲＬＣバッファｚ、ｈ、ｋ、ｖおよびｕの５つのＲＬＣ層バッファ１０を示す。しかしながら、このケースでは、ＭＡＣバッファｚ、ｈ、ｋおよびｕｖという４つのＭＡＣ層バッファ１１がさらに存在する。
【０１０６】
ＲＬＣバッファｚは、ユーザ装置ＵＥｘのために使用される無線ベアラＲＢｚに再度割り当てられる。ＲＬＣバッファｚは、優先順位レベルｐを有するデータをＭＡＣバッファｚへ出力し、このＭＡＣバッファは、１つのＭＡＣ ＳＤＵにおいて使用するためのデータを出力する。ＲＬＣバッファｈおよびｋは、双方ともユーザ装置ＵＥｙにより使用される無線ベアラＲＢｈおよびＲＢｋにそれぞれ再度割り当てられる。ＲＬＣバッファｈはＭＡＣバッファｈに接続され、ＲＬＣバッファｋはＭＡＣバッファｋに接続されるが、ＲＬＣバッファｋのみが、ｍの優先順位レベルが割り当てられたデータをＭＡＣバッファｋに転送する。ＭＡＣバッファｋは、２つのＭＡＣ ＳＤＵに配信されるデータを出力する。ＲＬＣバッファｖおよびｕは、双方ともユーザ装置ＵＥｚにより使用される無線ベアラＲＢｙおよびＲＢｕにそれぞれ再度割り当てられる。ＲＬＣバッファｖおよびＲＬＣバッファｕは両方とも、同じ優先順位レベルｒを有する受信データをＭＡＣバッファｕｖへ出力する。ＭＡＣバッファｕｖは、４つのＭＡＣ ＳＤＵに配信されるデータを出力する。
【０１０７】
図１３によるバッファリングモデルにおいて、“NumOfBuff”フィールドの値は、ＭＡＣレベルバッファ１１の数を定義し、このバッファからデータが対応するＨＳＤＰＡ ＦＰデータフレームに供給される。かくして、提示された例においては、図１０のフレーム構造に基づくデータフレームのフィールド“NumOfBuff”の値は３に設定される。なぜならば、データは、３つのＭＡＣバッファ、すなわちＭＡＣバッファｚ、ｋ、およびｖｕから抽出されるからである。
【０１０８】
ＭＡＣバッファｚについてのフィールド“NumOfSDUs”の値は１に設定される。なぜならば、１つのＭＡＣ ＳＤＵについてのデータのみが、現在のフレームのためのこのバッファから抽出されたからである。ＭＡＣバッファｋについては、フィールド“NumOfSDUs”の値は２に設定される。なぜならば、２つのＭＡＣ ＳＤＵについてのデータが、現在のフレームのためのこのバッファから抽出されたからである。ＭＡＣバッファｕｖについては、フィールド“NumOfSDUs”の値は４に設定される。なぜならば、４つのＭＡＣ ＳＤＵについてのデータが、現在のフレームのためのこのバッファから抽出されたからである。
【０１０９】
フィールド“SizeOfSDUs”および“ユーザバッファサイズ”の値は、それぞれ適用可能な値に設定される。
【０１１０】
ＭＡＣバッファｚについてのフィールド“ＵＥ−ｉｄ”の値はｘに設定される。なぜならば、このバッファ中のデータはＵＥｘ用だからである。ＭＡＣバッファｋについてのフィールド“ＵＥ−ｉｄ”の値はｙに設定される。なぜならば、このバッファ中のデータはＵＥｙ用だからである。ＭＡＣバッファｕｖについてのフィールド“ＵＥ−ｉｄ”の値はｚに設定される。なぜならば、このバッファ中のデータはＵＥｚ用だからである。
【０１１１】
ＭＡＣバッファｚについてのフィールド“ＣＭＣＨ−ＰＩ”の値はｐに設定される。なぜならば、このバッファに提供されるデータについての優先順位レベルがｐに設定されたからである。ＭＡＣバッファｋについてのフィールド“ＣＭＣＨ−ＰＩ”の値はｍに設定される。なぜならば、このバッファに提供されるデータについての優先順位レベルがｍに設定されたからである。ＭＡＣバッファｕｖについてのフィールド“ＣＭＣＨ−ＰＩ”の値はｒに設定される。なぜならば、このバッファに提供されるデータについての優先順位レベルがｒに設定されたからである。
【０１１２】
図１３の例において、同じＵＥに割り当てられたいくつかのＲＢは、もしこれらが、例えば共通の優先順位値を持っていれば、共通ＭＡＣバッファ１１を使用し得る。ＲＢが割り当てられるＵＥにかかわらず、送信されたＵＥ情報についての共通の優先準位値を有するすべてのＲＢについて共通ＭＡＣバッファ１１を使うことが可能であろう。ただし、これによってフロー制御はずっと複雑になるであろう。
【０１１３】
一般に、本発明の第１の形態による種々のＨＳＤＰＡ ＦＰフレーム構造が提示され、これらは、ＨＳＤＰＡ関連ユーザデータを要求される付加情報と共にＲＮＣからＵＴＲＡＮのノードＢへ送信するための種々の状況について有利に使用し得る。提示されたフレーム構造は、特定の要件への最適適合を提供するためにどのような適当な方法ででも変更できる。
【０１１４】
ここで、Ｉｕｂインタフェースにより相互接続されたＲＮＣおよびノードＢを含むＨＳＤＰＡ可能ＵＴＲＡＮについて本発明の第２の形態の実施形態を提示する。この実施形態においては、Ｉｕｂ適用プロトコルが提供され、これは、ノードＢがＨＳＤＰＡを構成できるようにするために、Ｉｕｂインタフェース経由でノードＢへ送信される選択された制御メッセージにＲＮＣにより付加し得るいくつかのＩＥを定義する。
【０１１５】
図１４は、新しい準静的“ＨＳ＿ＤＳＣＨ情報”ＩＥのセットを有する表を示し、この表は、セル中でＨＳＤＰＡを構成するためにノードＢにより使用できるＨＳ−ＤＳＣＨ関連情報を有するセル関連パラメータおよび実装されたＨＡＲＱの特性を含む。この表は、例えば上記引用の技術仕様書ＴＳ ２５．４３３におけるＩＥを定義するために３ＧＰＰにより使用された表形式を備えている。これらの表は、ＩＥ／グループ名、ＩＥの存在に関する要件、範囲、ＩＥタイプおよび参照、意味説明、クリティカリティ、ならびに割り当てられたクリティカリティのためのそれぞれの列を含む。図１４では、列“ＩＥ／グループ名”のみが使用される。他の列は、それぞれの要件に応じて記入され得る。
【０１１６】
図１４の表のセット中の第１のＩＥは、“ＭＣＳセット”と呼ばれる。これは、ノードＢが送信のためのあらゆるＴＴＩを選ぶことができる変調および符号化方式（ＭＣＳ）のセットを含む。
【０１１７】
このセット中の第２のＩＥは、“ＨＳ＿ＤＳＣＨパワーレベル”と呼ばれる。このＩＥは、ＮＱＡＭ（ｎ−記号直交振幅変調）の場合にＨＳ−ＤＳＣＨとＣＰＩＣＨ（共通パイロットチャネル）コードパワーレベルとの間の関係を定義する。
【０１１８】
このセット中の第３のＩＥは、“NumOfCodes”と呼ばれ、これは、ＨＳ−ＤＳＣＨに割り当てられるコードチャネル数を定義する。ＲＮＣは、ＨＳ−ＤＳＣＨ特性の構成を可能にするために、セルについてのコードチャネル数を割り当てることができる。
【０１１９】
このセット中の第４のＩＥは、“ＴＴＩ選択”と呼ばれる。“ＴＴＩ選択”は、ノードＢが使用するＴＴＩ長さについての情報を含む。
【０１２０】
表中には“ＨＡＲＱ情報”がさらに含まれ、これは、いくつかのＨＡＲＱの特定ＩＥを含むことがあるＩＥグループであり、このＩＥは、選択されたＨＡＲＱ実装によって決まる。“ＨＡＲＱ情報”グループは、ノードＢ中でＨＡＲＱを構成するための情報を定義する。このグループのパラメータにより、ＲＮＣは、ノードＢの容量を限定することが可能になる。図１４において、ＩＥグループ“ＨＡＲＱ情報”は、ＩＥ“NumOfChannel”、“MaxAttempt”および“RedudancyVer”を含んでいる。ｎ−チャネルＳＡＷ−ＨＡＲＱが使用される場合、ＩＥ“NumOfChannel”は、ＲＮＣがチャネル数を構成できるようにするために含まれ得る。一定回数の試行後にノードＢがＵＥ再送信要求を拒否できることをさらに想定すると、ＩＥ“MaxAttempt”を含ませることによってＲＮＣは最大試行数をノードＢに提供することができ、ノードＢは、それ自身の条件に従ってこの制限の下で要求を拒否するかしないかを決めることができる。最後に、ソフトチェイズ（soft/chaise）組合わせ法の代わりに増分冗長度法（incremental redundancy）が使用される場合、ＩＥ“RedundancyVer”は、ノードＢがそれから選ぶことができる冗長度バージョンの制限を定義することができる。
【０１２１】
特に、ＩＥ“NumOfCodes”およびＩＥグループ“ＨＡＲＱ情報”に属するＩＥは、許容限度をノードＢに提供しており、このノードＢは、設定された限界内で適当な値を動的に選択することができる。代わりに、固定値としておよび／またはＲＬ特定値としてこれらのパラメータを区分することも可能であろう。
【０１２２】
説明したセルの特定ＩＥは、セル設定手順およびセル再構成手順に付加することができ、さらにＲＮＣによりノードＢに送信されるＨＳＤＰＡ関連セル設定要求メッセージおよびセル再構成要求メッセージ中にＲＮＣによって含めることができる。
【０１２３】
図１５〜１７はそれぞれ、ＨＳ−ＤＳＣＨチャネルを設定し再構成するためにノードＢにより使用できるＲＬ関連パラメータを含むＩＥのセットを有する表を示す。ＩＥは、無線リンク設定手順および同期無線リンク再構成準備手順中に加えることができる。これらの表は、図１４の表と同じ形式を有している。
【０１２４】
図１５の表は、ＩＥ“ＨＳ＿ＤＳＣＨ ＩＤ”のみを含んでいる。このＩＥは、ノードＢ通信コンテキスト内のＨＳ−ＤＳＣＨを一意に識別する。
【０１２５】
図１６の表は、“ＨＳ＿ＤＳＣＨ情報応答”ＩＥを含み、これらは、確立または変更されたＨＳ−ＤＳＣＨに情報を提供する。各ＩＥについてのエントリの範囲は、１から１つのＵＥ当たりのＨＳ−ＤＳＣＨの最大数までである。
【０１２６】
このセット中の第１のＩＥも、すでに言及したＩＥ“ＨＳ＿ＤＳＣＨ ＩＤ”であり、これは強制的に含まれるべきである。
【０１２７】
このセット中の第２のＩＥは、“バインディングＩＤ”と呼ばれ、任意に含み得る。“バインディングＩＤ”は、ユーザデータストリームの識別子である。この識別子はノードＢにおいて割り当てられ、これは、ノードＢへまたはノードＢからの確立中の各トランスポートベアラについて一意である。従って、意味はＤＳＣＨについてと同じである。
【０１２８】
このセット中の第３のＩＥは、“トランスポート層アドレス”と呼ばれ、同様に任意に含み得る。このＩＥは、ノードＢのトランスポートアドレスを定義する。従って、意味はＤＳＣＨについてと同じである。
【０１２９】
図１６の表のＩＥは、無線設定応答メッセージおよび無線リンク再構成実行可能メッセージ中に含めることができる。
【０１３０】
図１７の表は、“ＨＳ＿ＤＳＣＨ ＦＤＤ情報”ＩＥを含み、これは、確立されるＨＳ−ＤＳＣＨに情報を提供する。各ＩＥについてのエントリの範囲は再度、１から１つのＵＥ当たりのＨＳ−ＤＳＣＨの最大数までである。
【０１３１】
このセット中の第１のＩＥも、上記で言及したＩＥ“ＨＳ＿ＤＳＣＨ ＩＤ”である。
【０１３２】
このセット中の第２のＩＥは、“ＵＥ＿ＩＤ”と呼ばれ、ノードＢが種々のＵＥを識別できるようにするために使用される。このＩＥは、ＭＡＣヘッダに書き込むために使用される。これは、ＲＮＴＩまたは何か他のもの、例えば、ＵＥにとって分かりやすくなり得る新しい種類のユーザ装置アイデンティティ表示とし得る。
【０１３３】
このセット中の第３のＩＥは、“トランスポート形式セット”と呼ばれる。“トランスポート形式セット”は、トランスポートチャネル、例えばＨＳ−ＤＳＣＨに関連付けられたトランスポート形式のセットとして定義される。
【０１３４】
このセットの中第４のＩＥは、“割り当て／保持優先順位”と呼ばれる。このパラメータは、ノードＢの内部資源の割り当ておよび保持における優先順位レベルを示す。従って、意味はＤＳＣＨについてと同じである。
【０１３５】
このセットの第５のＩＥは、“フレーム取り扱い優先順位”と呼ばれる。このパラメータは、過負荷による割り当てられた資源の一時的制限のためにＨＳ−ＤＳＣＨの寿命の間に使用される優先順位レベルを示す。従って、意味はＤＳＣＨについて同じである。
【０１３６】
このセットの第６のＩＥは、“ToAWE”と呼ばれる。パラメータ“ToAWE”は、ウインドウエンドポイントの到着時間である。ダウンリンクデータフレームは、このウインドウエンドポイントの前に受信されると予想される。従って、意味はＤＳＣＨについて同じである。
【０１３７】
このセットの第７のＩＥは、“ToAWS”と呼ばれる。パラメータ“ToAWS”は、ウインドウスタートポイントの到着時間である。ダウンリンクデータフレームは、このウインドウスタートポイントの後に受信されると予想される。従って、意味はＤＳＣＨについて同じである。
【０１３８】
このセットの第８のＩＥは、“NumOfCodes”と呼ばれ、考えられるセルベースパラメータとしてすでに言及された。ＲＮＣは、それぞれのＵＥ機能に従ってこのパラメータについての値を選択することができるであろう。
【０１３９】
このセットの第９のＩＥは、“BufferStatus”と呼ばれ、ＲＮＣバッファの現在の状態を示す。このパラメータは、フロー制御のための接続の最初に使用できる。
【０１４０】
このセットには“ＨＡＲＱ容量”がさらに含まれており、これは、図１４の表中の”ＨＡＲＱ情報グループ“のものと同一のＨＡＲＱの特定ＩＥをいくつか含み得るＩＥグループである。ただし、たとえＩＥの名前がセル特定およびＲＬ特定双方のケースで同一であったとしても、意味は若干異なる。なぜならば、セル特定のケースにおいては、“ＨＡＲＱ情報”はセル容量を制限するのに対して、ＲＬ−特定のケースにおいては、“ＨＡＲＱ容量”は無線リンクまたはＵＥ機能のＱｏＳ（サービス品質）を反映するからである。
【０１４１】
この表のＩＥは、無線リンク設定要求メッセージおよび無線リンク再構成準備メッセージ中に含め得る。
【０１４２】
さらなるＨＳＤＰＡの特定のＩＥのセットは、変更されるＨＳ−ＤＳＣＨ情報について定義される。このセットは、“ＨＳ−ＤＳＣＨ ＦＤＤ情報”についてのセットのサブセットを含む。より具体的には、これは、ＩＥ“ＨＳ−ＤＳＣＨ ＩＤ”、“トランスポート形式セット”、“割り当て／保持優先順位”、“フレーム取り扱い優先順位”、“ToAWS”、“ToAWE”、および“NumOfCodes”を含み、そしてことによると“ＨＡＲＱ容量”グループのＩＥを含む。このセットのＩＥは、無線リンク再構成準備メッセージ中に含めることもできる。
【０１４３】
ＲＬ関連ＩＥの多くは、例えば、参照により本明細書に組み込まれ、更なる詳細について参照される上記引用の技術仕様書ＴＳ ２５．４３３中に提示されるＤＳＣＨ関連ＩＥと対応する意味を有している。
【０１４４】
ＤＳＣＨについてＩＥグループ“ＨＡＲＱ容量”が知られておらず、これはＲＬのＨＡＲＱ特徴を表すものであり、ＵＥ機能および／またはＲＬのＱｏＳも反映できる。
【０１４５】
さらに、ノードＢ中のＭＡＣヘッダの完了を助けるために、ＩＥ“ＵＥ＿ＩＤ”が新しいパラメータとして加えられた。もしＩＤがＭＡＣヘッダ中に全く含まれないか、または要求されなければ、このパラメータは代わりにＦＰ層上で同じ目的のために使用され得る。
【０１４６】
ＩＥ“トランスポート形式セット”は、ＤＳＣＨについての対応するＩＥと非常に似ているが、ＨＳ−ＤＳＣＨをサポートするために、いくつかのＩＥについて新規な値が定義されねばならない。これは図１８に示してあり、この図は、上記引用の仕様書ＴＳ ２５．４３３から取られたＤＳＣＨトランスポート形式セットについての表を示し、いくつかの変更には下線が付してある。
【０１４７】
より具体的には、“送信時間間隔”ＩＥについてより可能性のある値、すなわち“１スロット”、“３スロット”、“５スロット”および“１５スロット”が加えられる。これらの値は、ＨＳ−ＤＳＣＨのためのみに使用されるべきであり、他のどの値もＨＳ−ＤＳＣＨに適用されるべきではない。加えて、“畳み込み”値は、ＨＳＤＰＡについての“チャネルコーディングのタイプ”ＩＥにおいて使用されるべきではない。
【０１４８】
かくして、本発明の第２の形態の提示された実施形態において、基本的ＩＥが定義され、これらは、ＨＳＤＰＡをサポートするために、セル設定および再構成ならびにＲＬ設定および再構成の間に提供され得る。説明したＩＥのセットおよびＩＥ自身は、特定の要件に適合するように、任意の適当な方法で変更され得る。同様に、ＨＳＤＰＡ関連制御情報のどのような必要な転送も可能にするために、さらなるＩＥのセットがＩｕｂ適用プロトコル中に定義し得る。
【特許請求の範囲】
【請求項１】
通信ネットワーク内でユーザデータをコントローラ（４）からネットワーク要素（５）へインタフェースを介して送信するための方法であって、前記コントローラ（４）は、前記ユーザデータでデータフレームを構成するための少なくとも１つの専用フレーム構造を使用し、データフレームは、前記インタフェース経由で前記ネットワーク要素（５）へ送信され、前記フレーム構造は、前記ユーザデータの処理のために前記ネットワーク要素（５）中で要求される情報を受信するための少なくとも１つのヘッダセクションを含む方法。
【請求項２】
前記フレーム構造は、ＨＳＤＰＡ関連ユーザデータが前記コントローラによって配信される少なくとも１つのＳＤＵを受信するためのペイロードセクションをさらに含む請求項１に記載の方法。
【請求項３】
前記ユーザデータはＨＳＤＰＡ（高速ダウンリンクパケットアクセス）関連ユーザデータであり、前記通信ネットワークはＵＴＲＡＮ（汎用移動通信サービス地上無線アクセスネットワーク）であり、前記コントローラはＲＮＣ（無線ネットワークコントローラ）であり、前記ネットワーク要素はノードＢであり、前記インタフェースはＩｕｂインタフェースであり、前記および少なくとも１つのフレーム構造は少なくとも１つの専用ＨＳＤＰＡ ＦＰ（フレームプロトコル）フレーム構造である請求項１または２に記載の方法。
【請求項４】
前記少なくとも１つの専用ＨＳＤＰＡ ＦＰフレーム構造の１つに従って前記ＲＮＣ（４）により構成されるフレーム用に、前記ヘッダセクションは、ＨＳＤＰＡ関連情報を受信するために、前記データフレームの前記ヘッダセクション中に挿入されたデータのための少なくとも１つの巡回冗長検査情報のための専用フィールド（“ヘッダＣＲＣ”）を含む請求項３に記載の方法。
【請求項５】
前記少なくとも１つの専用ＨＳＤＰＡ ＦＰフレーム構造の１つに従って前記ＲＮＣ（４）により構成されるフレーム用に、前記ヘッダセクションは、ＨＳＤＰＡ関連情報を受信するために、前記データフレームのフレームタイプの少なくとも１つの表示のための専用フィールド（“ＦＴ”）を含む請求項３または４に記載の方法。
【請求項６】
前記少なくとも１つの専用ＨＳＤＰＡ ＦＰフレーム構造の１つに従って前記ＲＮＣ（４）により構成されるフレーム用に、前記ヘッダセクションは、ＨＳＤＰＡ関連情報を受信するために、前記データフレームの前記ペイロードセクション中に含まれるＳＤＵの数の少なくとも１つの表示のための専用フィールド（“NumOfSDUs”）を含む請求項３〜５のいずれか１項に記載の方法。
【請求項７】
前記少なくとも１つの専用ＨＳＤＰＡ ＦＰフレーム構造の１つに従って前記ＲＮＣ（４）により構成されるフレーム用に、前記ヘッダセクションは、ＨＳＤＰＡ関連情報を受信するために、ＲＮＣバッファ中のユーザ装置に割り当てられたバッファのステータスの少なくとも１つの表示のための専用フィールド（“User_Buffer_size”）を含み、割り当てられたバッファは、前記ＲＮＣ（４）中の前記ユーザ装置のユーザデータを、これをノードＢ（５）へ送信する前に、バッファリングするために使用される請求項３〜６のいずれか１項に記載の方法。
【請求項８】
前記少なくとも１つの専用ＨＳＤＰＡ ＦＰフレーム構造の１つに従って前記ＲＮＣ（４）により構成されるフレーム用に、前記ヘッダセクションは、ＨＳＤＰＡ関連情報を受信するために、前記データフレームの相対優先順位および前記データフレームの前記ペイロードセクション中に含まれる前記ＳＤＵの相対優先順位の少なくとも１つの表示のための専用フィールド（“ＣＭＣＨ−ＰＩ”）を含む請求項３〜７のいずれか１項に記載の方法。
【請求項９】
前記少なくとも１つの専用ＨＳＤＰＡ ＦＰフレーム構造の１つに従って前記ＲＮＣ（４）により構成されるフレーム用に、前記ヘッダセクションは、ＨＳＤＰＡ関連情報を受信するために、ユーザ装置識別の種類の少なくとも１つの表示のための専用フィールド（“UE_Id type”）を含み、もしあれば、受信ノードＢ（５）は、前記ＳＤＵのためのヘッダを含み、この場合該ヘッダは、前記ＲＮＣ（４）により前記ＳＤＵへすでに付加されている可能性がある請求項３〜８のいずれか１項に記載の方法。
【請求項１０】
前記ＲＮＣ（４）は、いくつかのユーザ装置を目的とするＨＳＤＰＡ関連ユーザデータを単一のＩｕｂ送信接続のフレームへ多重送信でき、多重化データは、前記ノードＢ（５）により多重分離され、前記少なくとも１つの専用ＨＳＤＰＡ ＦＰフレーム構造の１つに従って前記ＲＮＣ（４）により構成されたデータフレーム用に、前記ヘッダセクションは、ＨＳＤＰＡ関連情報を受信するために、前記データフレームの前記ペイロードセクション中にユーザデータが挿入されるＲＮＣバッファの数の少なくとも１つの表示のための専用フィールド（“NumOfBuff”）を含む請求項３〜９のいずれか１項に記載の方法。
【請求項１１】
前記ＲＮＣ（４）は、いくつかのユーザ装置を目的とするＨＳＤＰＡ関連ユーザデータを単一のＩｕｂ送信接続のフレームへ多重送信でき、多重化データは、前記ノードＢ（５）により多重分離され、前記少なくとも１つの専用ＨＳＤＰＡ ＦＰフレーム構造の１つに従って前記ＲＮＣ（４）により構成されたデータフレーム用に、前記ヘッダセクションは、ＨＳＤＰＡ関連情報を受信するために、単一のＲＮＣバッファ（９、１１）から発生するユーザデータを含む前記データフレーム中のＳＤＵの数の少なくとも１つの表示のための専用フィールド（“NumOfSDUs”）を含む請求項３〜１０のいずれか１項に記載の方法。
【請求項１２】
前記ＲＮＣ（４）は、いくつかのユーザ装置を目的とするＨＳＤＰＡ関連ユーザデータを単一のＩｕｂ送信接続のフレームへ多重送信でき、多重化データは、前記ノードＢ（５）により多重分離され、前記少なくとも１つの専用ＨＳＤＰＡ ＦＰフレーム構造の１つに従って前記ＲＮＣ（４）により構成されたデータフレーム用に、前記ヘッダセクションは、ＨＳＤＰＡ関連情報を受信するために、前記データフレーム中のＳＤＵのサイズの少なくとも１つの表示のための専用フィールド（“Size_of_MAC SDU”）を含む請求項３〜１１のいずれか１項に記載の方法。
【請求項１３】
前記ＲＮＣ（４）は、いくつかのユーザ装置を目的とするＨＳＤＰＡ関連ユーザデータを単一のＩｕｂ送信接続のフレームへ多重送信でき、多重化データは、前記ノードＢ（５）により多重分離され、前記少なくとも１つの専用ＨＳＤＰＡ ＦＰフレーム構造の１つに従って前記ＲＮＣ（４）により構成されたデータフレーム用に、前記ヘッダセクションは、ＨＳＤＰＡ関連情報を受信するために、ＲＮＣバッファ（９、１１）中のそれぞれのユーザ装置に割り当てられたバッファの状態の少なくとも１つの表示のための専用フィールド（“User_Buffer_size”）を含み、割り当てられたバッファは、前記ＲＮＣ（４）中の前記ユーザ装置についてのユーザデータを、これをノードＢ（５）へ送信する前にバッファリングするために使用される請求項３〜１２のいずれか１項に記載の方法。
【請求項１４】
前記ＲＮＣ（４）は、いくつかのユーザ装置を目的とするＨＳＤＰＡ関連ユーザデータを単一のＩｕｂ送信接続のフレームへ多重送信でき、多重化データは、前記ノードＢ（５）により多重分離され、前記少なくとも１つの専用ＨＳＤＰＡ ＦＰフレーム構造の１つに従って前記ＲＮＣ（４）により構成されたデータフレーム用に、前記ヘッダセクションは、ＨＳＤＰＡ関連情報を受信するために、フレームおよび／または前記データフレーム中に含まれる前記ＳＤＵの相対優先順位の少なくとも１つの表示のための専用フィールド（“ＣＭＣＨ−ＰＩ”）を含む請求項３〜１３のいずれか１項に記載の方法。
【請求項１５】
前記ＲＮＣ（４）は、いくつかのユーザ装置を目的とするＨＳＤＰＡ関連ユーザデータを単一のＩｕｂ送信接続のフレームへ多重送信でき、多重化データは、前記ノードＢ（５）により多重分離され、前記少なくとも１つの専用ＨＳＤＰＡ ＦＰフレーム構造の１つに従って前記ＲＮＣ（４）により構成されたデータフレーム用に、前記ヘッダセクションは、ＨＳＤＰＡ関連情報を受信するために、ユーザ装置識別の種類の少なくとも１つの表示のための専用フィールド（“UE_ID type”）を含み、もしあれば、受信ノードＢ（５）は、前記ＳＤＵに付加されたヘッダを含み、この場合該ヘッダは、前記ＲＮＣ（４）により前記ＳＤＵへすでに付加されている可能性がある請求項３〜１４のいずれか１項に記載の方法。
【請求項１６】
前記ＳＤＵに配信された前記ＨＳＤＰＡ関連ユーザデータの目的とするユーザ装置の識別が前記ノードＢ（５）において要求され、前記少なくとも１つの専用ＨＳＤＰＡ ＦＰフレーム構造の１つのために、前記ヘッダセクションは、ユーザ装置識別情報を含むための少なくとも１つの専用フィールド（“ＵＥ＿ｉｄ”）を含む請求項３〜１５のいずれか１項に記載の方法。
【請求項１７】
前記ＳＤＵに配信された前記ＨＳＤＰＡ関連ユーザデータが目的とするユーザ装置の識別が前記ノードＢ（５）において要求され、前記少なくとも１つの専用ＨＳＤＰＡ ＦＰフレーム構造の１つのために、ユーザ装置識別情報が、前記ペイロードセクション中に含まれる前記ＳＤＵに付加される請求項３〜１５のいずれか１項に記載の方法。
【請求項１８】
ユーザ装置に割り当てられるＲＮＴＩ（無線ネットワーク一時的ＩＤ）がそれぞれのユーザ装置識別情報として使用される請求項１６または１７に記載の方法。
【請求項１９】
前記ＳＤＵは、ＭＡＣ−ｄおよび／またはＭＡＣ−ｃ／ｓｈ ＳＤＵである請求項２〜１８のいずれか１項に記載の方法。
【請求項２０】
少なくとも１つのコントローラ（４）と少なくとも１つのネットワーク要素（５）とを含み、少なくとも１つのフレーム構造が、ユーザデータを処理するために前記ネットワーク要素（５）において要求される情報を前記コントローラ（４）から前記ネットワーク要素（５）へインタフェースを介して請求項１〜２０のいずれか一項に記載の方法に従って送信するために定義される通信ネットワークであって、
コントローラ（４）およびネットワーク要素（５）は、前記インタフェース経由で互いに接続されており、前記コントローラ（４）は、前記インタフェース経由で前記ネットワーク要素（５）へ前記情報を送信するために前記情報でフレームを構成するために前記少なくとも１つのフレーム構造を使用する手段を含み、前記ネットワーク要素（５）は、前記少なくとも１つのフレーム構造を有する受信されたフレームから前記情報を抽出するための手段を含む通信ネットワーク。
【請求項２１】
前記通信ネットワークはＵＴＲＡＮ（汎用移動通信サービス地上無線アクセスネットワーク）であり、前記コントローラはＲＮＣ（無線ネットワークコントローラ）（４）であり、前記ネットワーク要素はノードＢ（５）であり、前記インタフェースはＩｕｂインタフェースである請求項２０に記載の通信ネットワーク。
【請求項２２】
前記ＲＮＣ（４）の前記手段はＭＡＣ−ｃ／ｓｈ（２）および／またはＭＡＣ−ｄ（３）であり、前記ノードＢ（５）の前記手段はＭＡＣ−ｈｓ（１）である請求項２１に記載の通信ネットワーク。
【請求項２３】
通信ネットワークのためのコントローラであって、情報をインタフェース経由で請求項２０〜２２のいずれか１項に記載のネットワーク要素（５）へ送信するためにユーザデータを処理するために前記通信ネットワークのネットワーク要素（５）により要求される前記情報でフレームを構成するためにフレーム構造を使用するための手段を含むコントローラ。
【請求項２４】
前記コントローラ（４）は、ＵＴＲＡＮのＲＮＣ（無線ネットワークコントローラ）である請求項２３に記載のコントローラ。
【請求項２５】
通信ネットワークのためのネットワーク要素（５）であって、ユーザデータを処理するために前記ネットワーク要素（５）において要求される情報を、前記通信ネットワークのコントローラ（４）からインタフェース経由で受信されたフレームから抽出するための手段を含み、フレームは、請求項２０〜２２に記載の通信ネットワークのフレーム構造を有しているネットワーク要素。
【請求項２６】
前記ネットワーク要素はＵＴＲＡＮ（汎用移動通信サービス地上無線アクセスネットワーク）のノードＢである請求項２５に記載のネットワーク要素（５）。
【請求項２７】
通信ネットワークのネットワーク要素（５）に前記通信ネットワークのコントローラ（４）において利用可能な制御パラメータを提供するための方法であって、コントローラ（４）は、インタフェース経由で前記ネットワーク要素（５）に接続されており、前記方法は、前記コントローラ（４）から前記ネットワーク要素（５）へ前記インタフェースを介して送信される少なくとも１種類の制御メッセージ中に少なくとも１つの制御パラメータを挿入することを可能にするインタフェース適用プロトコルを使用することを含む方法。
【請求項２８】
前記通信ネットワークはＵＴＲＡＮ（汎用移動通信サービス地上無線アクセスネットワーク）であり、前記ネットワーク要素はノードＢであり、前記コントローラはＲＮＣ（無線ネットワークコントローラ）であり、前記インタフェースはＩｕｂインタフェースである請求項２７に記載の方法。
【請求項２９】
前記制御パラメータはＨＳＤＰＡ（高速ダウンリンクパケットアクセス）関連制御パラメータである請求項２８に記載の方法。
【請求項３０】
前記少なくとも１つのＨＳＤＰＡ関連制御パラメータの内容は、固定値、制限値または前記ノードＢ（５）により使用が可能な値のシーケンスである請求項２９に記載の方法。
【請求項３１】
前記少なくとも１つのＨＳＤＰＡ関連制御パラメータは、少なくとも１つの情報要素（ＩＥ）中に含まれ、かつ前記ＵＴＲＡＮの前記ＲＮＣ（４）から前記ノードＢ（５）へ前記Ｉｕｂインタフェースを介して送信される前記少なくとも１種類の制御メッセージの制御メッセージに前記情報要素を付加することにより制御メッセージ中に挿入される請求項２９または３０に記載の方法。
【請求項３２】
前記少なくとも１つのＨＳＤＰＡ関連制御パラメータの少なくとも１つは、セルの設定および／またはセルの再構成のために前記ノードＢ（５）により要求されるセル特定制御パラメータである請求項２９〜３１のいずれか１項に記載の方法。
【請求項３３】
前記少なくとも１つのセル特定制御パラメータは、少なくとも１種類の制御メッセージ中に挿入するために、
変調および符号化方式（ＭＣＳ）のセットであって、該セットからＨＳＤＰＡ送信のためのあらゆるＴＴＩ（送信時間間隔）を前記ノードＢ（５）が選ぶことができるセット、
ＨＳＤＰＡにおけるＨＳ−ＤＳＣＨ（高速ダウンリンク共用チャネル）のために前記ノードＢ（５）により使用されるパワーレベル、
前記ノードＢ（５）により使用されるＨＳ−ＤＳＣＨに割り当てられるコードチャネルの数、
前記ノードＢ（５）により使用されるＴＴＩ長さの表示、および
前記ノードＢ（５）中に実装されるＨＡＲＱ（ハイブリッド自動再送要求）を構成するために前記ノードＢ（５）により使用される１つ以上のパラメータ、
のパラメータのうち、少なくとも１つを含む請求項３２に記載の方法。
【請求項３４】
ＨＡＲＱを構成するために前記ノードＢ（５）により使用される前記１つ以上のパラメータは、ＨＡＲＱのために使用されるチャネルの数、ＨＡＲＱのための試行の最大数、および前記ノードＢ（５）が選ぶことができる冗長度バージョンの制限、のうちの少なくとも１つを含む請求項３３に記載の方法。
【請求項３５】
前記少なくとも１種類の制御メッセージは、セル設定要求メッセージおよび／またはセル再構成要求メッセージである請求項３２〜３４のいずれか１項に記載の方法。
【請求項３６】
前記少なくとも１つのＨＳＤＰＡ関連制御パラメータの少なくとも１つは、無線リンクの設定および／または無線リンクの再構成のために要求される無線リンク特定制御パラメータである請求項２９〜３１のいずれか１項に記載の方法。
【請求項３７】
前記少なくとも１つの無線リンク特定制御パラメータは、少なくとも１種類の制御メッセージ中への挿入のために、ＨＳＤＰＡのために前記ノードＢ（５）により現在使用されるＨＳ ＤＳＣＨ（高速ダウンリンク共用チャネル）の少なくともアイデンティティを含む請求項３６に記載の方法。
【請求項３８】
前記少なくとも１つの無線リンク特定制御パラメータは、少なくとも１種類の制御メッセージ中への挿入のために、
ＨＳＤＰＡのために前記ノードＢ（５）により現在使用されるＨＳ ＤＳＣＨ（高速ダウンリンク共用チャネル）のアイデンティティ、
前記ノードＢ（５）により現在送信されるユーザデータストリームを識別するバインディングアイデンティティ、および
前記ノードＢ（５）の現在のトランスポートアドレスを定義するトランスポート層アドレス、
のパラメータのうちの少なくとも１つを含む請求項３６または３７に記載の方法。
【請求項３９】
前記少なくとも１つの無線リンク特定制御パラメータは、少なくとも１種類の制御メッセージ中への挿入のために、
ＨＳＤＰＡのために前記ノードＢ（５）により現在使用されるＨＳ ＤＳＣＨ（高速ダウンリンク共用チャネル）のアイデンティティ、
ＨＳＤＰＡによって前記ノードＢ（５）によりユーザデータが送信されるユーザ装置のアイデンティティ、
前記ノードＢ（５）により現在使用されるトランスポート形式セット、
前記ノードＢ（５）の内部資源の割り当ておよび／または保持における優先順位レベルを示す割り当ておよび／または保持優先順位、
過負荷による割り当てられた資源の一時的制限のためにＨＳ−ＤＳＣＨの寿命の間に前記ノードＢ（Ｂ）により使用される優先順位レベルを示すフレーム取り扱い優先順位、
ダウンリンクデータフレームがその後に前記ノードＢ（５）において受信されると予想されるウインドウスタートポイントの到着時間（ToAWS）、
ダウンリンクデータフレームがその前に前記ノードＢ（５）において受信されると予想されるウインドウエンドポイントの到着時間（ToAWE）、
前記ノードＢ（５）により使用されるＨＳ ＤＳＣＨに現在割り当てられるコードチャネルの数、
前記ＲＮＣ（４）のバッファの現在の状態を示すバッファステータス（BufferStatus）、および
前記ノードＢ（５）中に実装されるＨＡＲＱ（ハイブリッド自動再送要求）を構成するために前記ノードＢ（５）により現在使用される１つ以上のパラメータ、
のパラメータのうちの少なくとも１つを含む請求項３６〜３８のいずれか１項に記載の方法。
【請求項４０】
ＨＡＲＱを構成するために前記ノードＢ（５）により使用される前記１つ以上のパラメータは、ＨＡＲＱのために使用されるチャネルの数、ＨＡＲＱのための許可された最大試行回数、および前記ノードＢ（５）が選ぶことができる冗長度バージョンの制限のうちの少なくとも１つを含む請求項３９に記載の方法。
【請求項４１】
前記少なくとも１種類の制御メッセージは、無線リンク設定要求メッセージ、無線リンク設定応答メッセージ、無線リンク再構成準備メッセージおよび無線リンク再構成実行可能メッセージのうちの少なくとも１つである請求項３６〜４０のいずれか１項に記載の方法。
【請求項４２】
少なくとも１つのコントローラ（４）と少なくとも１つのネットワーク要素（５）とを含む通信ネットワークであって、コントローラ（４）およびネットワーク要素（５）は、インタフェース経由で互いに接続されており、前記通信ネットワークは、請求項３６〜４１のいずれか１項に記載の方法に従って前記コントローラ（４）から前記ネットワーク要素（５）へ前記インタフェースを介して送信される少なくとも１種類の制御メッセージ中に少なくとも１つの制御パラメータを挿入することにより前記コントローラ（４）が前記ネットワーク要素（５）に前記少なくとも１つの制御パラメータを提供できるようにするインタフェース適用プロトコルの実装をさらに含む通信ネットワーク。
【請求項４３】
前記通信ネットワークはＵＴＲＡＮ（汎用移動通信サービス地上無線アクセスネットワーク）であり、前記コントローラはＲＮＣ（無線ネットワークコントローラ）（４）であり、前記ネットワーク要素はノードＢ（５）であり、前記インタフェースはＩｕｂインタフェースである請求項４２に記載の通信ネットワーク。
【請求項４４】
通信ネットワークのためのコントローラ（４）であって、該コントローラ（４）は、請求項４２または４３に記載の通信ネットワークによりインタフェースを介して前記コントローラ（４）から前記ネットワーク要素（５）へ送信される制御メッセージ中に前記少なくとも１つの制御パラメータを挿入することにより、インタフェース適用プロトコルに従って前記インタフェース経由で前記通信ネットワークのネットワーク要素（５）に少なくとも１つの制御パラメータを、供給するための手段を含むコントローラ。
【請求項４５】
前記コントローラはＵＴＲＡＮのＲＮＣ（無線ネットワークコントローラ）である請求項４４に記載のコントローラ（４）。
【請求項４６】
通信ネットワークのためのネットワーク要素（５）であって。前記通信ネットワークのコントローラ（４）からインタフェース経由で制御メッセージを受信し、請求項４２または４３記載の通信ネットワークによって前記コントローラ（４）により少なくとも１つの制御パラメータが中に挿入された少なくとも１種類の受信メッセージから少なくとも１つの制御パラメータを抽出するための手段を含むネットワーク要素。
【請求項４７】
前記ネットワーク要素（５）は、ＵＴＲＡＮ（汎用移動通信サービス地上無線アクセスネットワーク）のノードＢである請求項４６に記載のネットワーク要素。
【請求項１】
通信ネットワーク内でユーザデータをコントローラ（４）からネットワーク要素（５）へインタフェースを介して送信するための方法であって、前記コントローラ（４）は、前記ユーザデータでデータフレームを構成するための少なくとも１つの専用フレーム構造を使用し、データフレームは、前記インタフェース経由で前記ネットワーク要素（５）へ送信され、前記フレーム構造は、前記ユーザデータの処理のために前記ネットワーク要素（５）中で要求される情報を受信するための少なくとも１つのヘッダセクションを含む方法。
【請求項２】
前記フレーム構造は、ＨＳＤＰＡ関連ユーザデータが前記コントローラによって配信される少なくとも１つのＳＤＵを受信するためのペイロードセクションをさらに含む請求項１に記載の方法。
【請求項３】
前記ユーザデータはＨＳＤＰＡ（高速ダウンリンクパケットアクセス）関連ユーザデータであり、前記通信ネットワークはＵＴＲＡＮ（汎用移動通信サービス地上無線アクセスネットワーク）であり、前記コントローラはＲＮＣ（無線ネットワークコントローラ）であり、前記ネットワーク要素はノードＢであり、前記インタフェースはＩｕｂインタフェースであり、前記および少なくとも１つのフレーム構造は少なくとも１つの専用ＨＳＤＰＡ ＦＰ（フレームプロトコル）フレーム構造である請求項１または２に記載の方法。
【請求項４】
前記少なくとも１つの専用ＨＳＤＰＡ ＦＰフレーム構造の１つに従って前記ＲＮＣ（４）により構成されるフレーム用に、前記ヘッダセクションは、ＨＳＤＰＡ関連情報を受信するために、前記データフレームの前記ヘッダセクション中に挿入されたデータのための少なくとも１つの巡回冗長検査情報のための専用フィールド（“ヘッダＣＲＣ”）を含む請求項３に記載の方法。
【請求項５】
前記少なくとも１つの専用ＨＳＤＰＡ ＦＰフレーム構造の１つに従って前記ＲＮＣ（４）により構成されるフレーム用に、前記ヘッダセクションは、ＨＳＤＰＡ関連情報を受信するために、前記データフレームのフレームタイプの少なくとも１つの表示のための専用フィールド（“ＦＴ”）を含む請求項３または４に記載の方法。
【請求項６】
前記少なくとも１つの専用ＨＳＤＰＡ ＦＰフレーム構造の１つに従って前記ＲＮＣ（４）により構成されるフレーム用に、前記ヘッダセクションは、ＨＳＤＰＡ関連情報を受信するために、前記データフレームの前記ペイロードセクション中に含まれるＳＤＵの数の少なくとも１つの表示のための専用フィールド（“NumOfSDUs”）を含む請求項３〜５のいずれか１項に記載の方法。
【請求項７】
前記少なくとも１つの専用ＨＳＤＰＡ ＦＰフレーム構造の１つに従って前記ＲＮＣ（４）により構成されるフレーム用に、前記ヘッダセクションは、ＨＳＤＰＡ関連情報を受信するために、ＲＮＣバッファ中のユーザ装置に割り当てられたバッファのステータスの少なくとも１つの表示のための専用フィールド（“User_Buffer_size”）を含み、割り当てられたバッファは、前記ＲＮＣ（４）中の前記ユーザ装置のユーザデータを、これをノードＢ（５）へ送信する前に、バッファリングするために使用される請求項３〜６のいずれか１項に記載の方法。
【請求項８】
前記少なくとも１つの専用ＨＳＤＰＡ ＦＰフレーム構造の１つに従って前記ＲＮＣ（４）により構成されるフレーム用に、前記ヘッダセクションは、ＨＳＤＰＡ関連情報を受信するために、前記データフレームの相対優先順位および前記データフレームの前記ペイロードセクション中に含まれる前記ＳＤＵの相対優先順位の少なくとも１つの表示のための専用フィールド（“ＣＭＣＨ−ＰＩ”）を含む請求項３〜７のいずれか１項に記載の方法。
【請求項９】
前記少なくとも１つの専用ＨＳＤＰＡ ＦＰフレーム構造の１つに従って前記ＲＮＣ（４）により構成されるフレーム用に、前記ヘッダセクションは、ＨＳＤＰＡ関連情報を受信するために、ユーザ装置識別の種類の少なくとも１つの表示のための専用フィールド（“UE_Id type”）を含み、もしあれば、受信ノードＢ（５）は、前記ＳＤＵのためのヘッダを含み、この場合該ヘッダは、前記ＲＮＣ（４）により前記ＳＤＵへすでに付加されている可能性がある請求項３〜８のいずれか１項に記載の方法。
【請求項１０】
前記ＲＮＣ（４）は、いくつかのユーザ装置を目的とするＨＳＤＰＡ関連ユーザデータを単一のＩｕｂ送信接続のフレームへ多重送信でき、多重化データは、前記ノードＢ（５）により多重分離され、前記少なくとも１つの専用ＨＳＤＰＡ ＦＰフレーム構造の１つに従って前記ＲＮＣ（４）により構成されたデータフレーム用に、前記ヘッダセクションは、ＨＳＤＰＡ関連情報を受信するために、前記データフレームの前記ペイロードセクション中にユーザデータが挿入されるＲＮＣバッファの数の少なくとも１つの表示のための専用フィールド（“NumOfBuff”）を含む請求項３〜９のいずれか１項に記載の方法。
【請求項１１】
前記ＲＮＣ（４）は、いくつかのユーザ装置を目的とするＨＳＤＰＡ関連ユーザデータを単一のＩｕｂ送信接続のフレームへ多重送信でき、多重化データは、前記ノードＢ（５）により多重分離され、前記少なくとも１つの専用ＨＳＤＰＡ ＦＰフレーム構造の１つに従って前記ＲＮＣ（４）により構成されたデータフレーム用に、前記ヘッダセクションは、ＨＳＤＰＡ関連情報を受信するために、単一のＲＮＣバッファ（９、１１）から発生するユーザデータを含む前記データフレーム中のＳＤＵの数の少なくとも１つの表示のための専用フィールド（“NumOfSDUs”）を含む請求項３〜１０のいずれか１項に記載の方法。
【請求項１２】
前記ＲＮＣ（４）は、いくつかのユーザ装置を目的とするＨＳＤＰＡ関連ユーザデータを単一のＩｕｂ送信接続のフレームへ多重送信でき、多重化データは、前記ノードＢ（５）により多重分離され、前記少なくとも１つの専用ＨＳＤＰＡ ＦＰフレーム構造の１つに従って前記ＲＮＣ（４）により構成されたデータフレーム用に、前記ヘッダセクションは、ＨＳＤＰＡ関連情報を受信するために、前記データフレーム中のＳＤＵのサイズの少なくとも１つの表示のための専用フィールド（“Size_of_MAC SDU”）を含む請求項３〜１１のいずれか１項に記載の方法。
【請求項１３】
前記ＲＮＣ（４）は、いくつかのユーザ装置を目的とするＨＳＤＰＡ関連ユーザデータを単一のＩｕｂ送信接続のフレームへ多重送信でき、多重化データは、前記ノードＢ（５）により多重分離され、前記少なくとも１つの専用ＨＳＤＰＡ ＦＰフレーム構造の１つに従って前記ＲＮＣ（４）により構成されたデータフレーム用に、前記ヘッダセクションは、ＨＳＤＰＡ関連情報を受信するために、ＲＮＣバッファ（９、１１）中のそれぞれのユーザ装置に割り当てられたバッファの状態の少なくとも１つの表示のための専用フィールド（“User_Buffer_size”）を含み、割り当てられたバッファは、前記ＲＮＣ（４）中の前記ユーザ装置についてのユーザデータを、これをノードＢ（５）へ送信する前にバッファリングするために使用される請求項３〜１２のいずれか１項に記載の方法。
【請求項１４】
前記ＲＮＣ（４）は、いくつかのユーザ装置を目的とするＨＳＤＰＡ関連ユーザデータを単一のＩｕｂ送信接続のフレームへ多重送信でき、多重化データは、前記ノードＢ（５）により多重分離され、前記少なくとも１つの専用ＨＳＤＰＡ ＦＰフレーム構造の１つに従って前記ＲＮＣ（４）により構成されたデータフレーム用に、前記ヘッダセクションは、ＨＳＤＰＡ関連情報を受信するために、フレームおよび／または前記データフレーム中に含まれる前記ＳＤＵの相対優先順位の少なくとも１つの表示のための専用フィールド（“ＣＭＣＨ−ＰＩ”）を含む請求項３〜１３のいずれか１項に記載の方法。
【請求項１５】
前記ＲＮＣ（４）は、いくつかのユーザ装置を目的とするＨＳＤＰＡ関連ユーザデータを単一のＩｕｂ送信接続のフレームへ多重送信でき、多重化データは、前記ノードＢ（５）により多重分離され、前記少なくとも１つの専用ＨＳＤＰＡ ＦＰフレーム構造の１つに従って前記ＲＮＣ（４）により構成されたデータフレーム用に、前記ヘッダセクションは、ＨＳＤＰＡ関連情報を受信するために、ユーザ装置識別の種類の少なくとも１つの表示のための専用フィールド（“UE_ID type”）を含み、もしあれば、受信ノードＢ（５）は、前記ＳＤＵに付加されたヘッダを含み、この場合該ヘッダは、前記ＲＮＣ（４）により前記ＳＤＵへすでに付加されている可能性がある請求項３〜１４のいずれか１項に記載の方法。
【請求項１６】
前記ＳＤＵに配信された前記ＨＳＤＰＡ関連ユーザデータの目的とするユーザ装置の識別が前記ノードＢ（５）において要求され、前記少なくとも１つの専用ＨＳＤＰＡ ＦＰフレーム構造の１つのために、前記ヘッダセクションは、ユーザ装置識別情報を含むための少なくとも１つの専用フィールド（“ＵＥ＿ｉｄ”）を含む請求項３〜１５のいずれか１項に記載の方法。
【請求項１７】
前記ＳＤＵに配信された前記ＨＳＤＰＡ関連ユーザデータが目的とするユーザ装置の識別が前記ノードＢ（５）において要求され、前記少なくとも１つの専用ＨＳＤＰＡ ＦＰフレーム構造の１つのために、ユーザ装置識別情報が、前記ペイロードセクション中に含まれる前記ＳＤＵに付加される請求項３〜１５のいずれか１項に記載の方法。
【請求項１８】
ユーザ装置に割り当てられるＲＮＴＩ（無線ネットワーク一時的ＩＤ）がそれぞれのユーザ装置識別情報として使用される請求項１６または１７に記載の方法。
【請求項１９】
前記ＳＤＵは、ＭＡＣ−ｄおよび／またはＭＡＣ−ｃ／ｓｈ ＳＤＵである請求項２〜１８のいずれか１項に記載の方法。
【請求項２０】
少なくとも１つのコントローラ（４）と少なくとも１つのネットワーク要素（５）とを含み、少なくとも１つのフレーム構造が、ユーザデータを処理するために前記ネットワーク要素（５）において要求される情報を前記コントローラ（４）から前記ネットワーク要素（５）へインタフェースを介して請求項１〜２０のいずれか一項に記載の方法に従って送信するために定義される通信ネットワークであって、
コントローラ（４）およびネットワーク要素（５）は、前記インタフェース経由で互いに接続されており、前記コントローラ（４）は、前記インタフェース経由で前記ネットワーク要素（５）へ前記情報を送信するために前記情報でフレームを構成するために前記少なくとも１つのフレーム構造を使用する手段を含み、前記ネットワーク要素（５）は、前記少なくとも１つのフレーム構造を有する受信されたフレームから前記情報を抽出するための手段を含む通信ネットワーク。
【請求項２１】
前記通信ネットワークはＵＴＲＡＮ（汎用移動通信サービス地上無線アクセスネットワーク）であり、前記コントローラはＲＮＣ（無線ネットワークコントローラ）（４）であり、前記ネットワーク要素はノードＢ（５）であり、前記インタフェースはＩｕｂインタフェースである請求項２０に記載の通信ネットワーク。
【請求項２２】
前記ＲＮＣ（４）の前記手段はＭＡＣ−ｃ／ｓｈ（２）および／またはＭＡＣ−ｄ（３）であり、前記ノードＢ（５）の前記手段はＭＡＣ−ｈｓ（１）である請求項２１に記載の通信ネットワーク。
【請求項２３】
通信ネットワークのためのコントローラであって、情報をインタフェース経由で請求項２０〜２２のいずれか１項に記載のネットワーク要素（５）へ送信するためにユーザデータを処理するために前記通信ネットワークのネットワーク要素（５）により要求される前記情報でフレームを構成するためにフレーム構造を使用するための手段を含むコントローラ。
【請求項２４】
前記コントローラ（４）は、ＵＴＲＡＮのＲＮＣ（無線ネットワークコントローラ）である請求項２３に記載のコントローラ。
【請求項２５】
通信ネットワークのためのネットワーク要素（５）であって、ユーザデータを処理するために前記ネットワーク要素（５）において要求される情報を、前記通信ネットワークのコントローラ（４）からインタフェース経由で受信されたフレームから抽出するための手段を含み、フレームは、請求項２０〜２２に記載の通信ネットワークのフレーム構造を有しているネットワーク要素。
【請求項２６】
前記ネットワーク要素はＵＴＲＡＮ（汎用移動通信サービス地上無線アクセスネットワーク）のノードＢである請求項２５に記載のネットワーク要素（５）。
【請求項２７】
通信ネットワークのネットワーク要素（５）に前記通信ネットワークのコントローラ（４）において利用可能な制御パラメータを提供するための方法であって、コントローラ（４）は、インタフェース経由で前記ネットワーク要素（５）に接続されており、前記方法は、前記コントローラ（４）から前記ネットワーク要素（５）へ前記インタフェースを介して送信される少なくとも１種類の制御メッセージ中に少なくとも１つの制御パラメータを挿入することを可能にするインタフェース適用プロトコルを使用することを含む方法。
【請求項２８】
前記通信ネットワークはＵＴＲＡＮ（汎用移動通信サービス地上無線アクセスネットワーク）であり、前記ネットワーク要素はノードＢであり、前記コントローラはＲＮＣ（無線ネットワークコントローラ）であり、前記インタフェースはＩｕｂインタフェースである請求項２７に記載の方法。
【請求項２９】
前記制御パラメータはＨＳＤＰＡ（高速ダウンリンクパケットアクセス）関連制御パラメータである請求項２８に記載の方法。
【請求項３０】
前記少なくとも１つのＨＳＤＰＡ関連制御パラメータの内容は、固定値、制限値または前記ノードＢ（５）により使用が可能な値のシーケンスである請求項２９に記載の方法。
【請求項３１】
前記少なくとも１つのＨＳＤＰＡ関連制御パラメータは、少なくとも１つの情報要素（ＩＥ）中に含まれ、かつ前記ＵＴＲＡＮの前記ＲＮＣ（４）から前記ノードＢ（５）へ前記Ｉｕｂインタフェースを介して送信される前記少なくとも１種類の制御メッセージの制御メッセージに前記情報要素を付加することにより制御メッセージ中に挿入される請求項２９または３０に記載の方法。
【請求項３２】
前記少なくとも１つのＨＳＤＰＡ関連制御パラメータの少なくとも１つは、セルの設定および／またはセルの再構成のために前記ノードＢ（５）により要求されるセル特定制御パラメータである請求項２９〜３１のいずれか１項に記載の方法。
【請求項３３】
前記少なくとも１つのセル特定制御パラメータは、少なくとも１種類の制御メッセージ中に挿入するために、
変調および符号化方式（ＭＣＳ）のセットであって、該セットからＨＳＤＰＡ送信のためのあらゆるＴＴＩ（送信時間間隔）を前記ノードＢ（５）が選ぶことができるセット、
ＨＳＤＰＡにおけるＨＳ−ＤＳＣＨ（高速ダウンリンク共用チャネル）のために前記ノードＢ（５）により使用されるパワーレベル、
前記ノードＢ（５）により使用されるＨＳ−ＤＳＣＨに割り当てられるコードチャネルの数、
前記ノードＢ（５）により使用されるＴＴＩ長さの表示、および
前記ノードＢ（５）中に実装されるＨＡＲＱ（ハイブリッド自動再送要求）を構成するために前記ノードＢ（５）により使用される１つ以上のパラメータ、
のパラメータのうち、少なくとも１つを含む請求項３２に記載の方法。
【請求項３４】
ＨＡＲＱを構成するために前記ノードＢ（５）により使用される前記１つ以上のパラメータは、ＨＡＲＱのために使用されるチャネルの数、ＨＡＲＱのための試行の最大数、および前記ノードＢ（５）が選ぶことができる冗長度バージョンの制限、のうちの少なくとも１つを含む請求項３３に記載の方法。
【請求項３５】
前記少なくとも１種類の制御メッセージは、セル設定要求メッセージおよび／またはセル再構成要求メッセージである請求項３２〜３４のいずれか１項に記載の方法。
【請求項３６】
前記少なくとも１つのＨＳＤＰＡ関連制御パラメータの少なくとも１つは、無線リンクの設定および／または無線リンクの再構成のために要求される無線リンク特定制御パラメータである請求項２９〜３１のいずれか１項に記載の方法。
【請求項３７】
前記少なくとも１つの無線リンク特定制御パラメータは、少なくとも１種類の制御メッセージ中への挿入のために、ＨＳＤＰＡのために前記ノードＢ（５）により現在使用されるＨＳ ＤＳＣＨ（高速ダウンリンク共用チャネル）の少なくともアイデンティティを含む請求項３６に記載の方法。
【請求項３８】
前記少なくとも１つの無線リンク特定制御パラメータは、少なくとも１種類の制御メッセージ中への挿入のために、
ＨＳＤＰＡのために前記ノードＢ（５）により現在使用されるＨＳ ＤＳＣＨ（高速ダウンリンク共用チャネル）のアイデンティティ、
前記ノードＢ（５）により現在送信されるユーザデータストリームを識別するバインディングアイデンティティ、および
前記ノードＢ（５）の現在のトランスポートアドレスを定義するトランスポート層アドレス、
のパラメータのうちの少なくとも１つを含む請求項３６または３７に記載の方法。
【請求項３９】
前記少なくとも１つの無線リンク特定制御パラメータは、少なくとも１種類の制御メッセージ中への挿入のために、
ＨＳＤＰＡのために前記ノードＢ（５）により現在使用されるＨＳ ＤＳＣＨ（高速ダウンリンク共用チャネル）のアイデンティティ、
ＨＳＤＰＡによって前記ノードＢ（５）によりユーザデータが送信されるユーザ装置のアイデンティティ、
前記ノードＢ（５）により現在使用されるトランスポート形式セット、
前記ノードＢ（５）の内部資源の割り当ておよび／または保持における優先順位レベルを示す割り当ておよび／または保持優先順位、
過負荷による割り当てられた資源の一時的制限のためにＨＳ−ＤＳＣＨの寿命の間に前記ノードＢ（Ｂ）により使用される優先順位レベルを示すフレーム取り扱い優先順位、
ダウンリンクデータフレームがその後に前記ノードＢ（５）において受信されると予想されるウインドウスタートポイントの到着時間（ToAWS）、
ダウンリンクデータフレームがその前に前記ノードＢ（５）において受信されると予想されるウインドウエンドポイントの到着時間（ToAWE）、
前記ノードＢ（５）により使用されるＨＳ ＤＳＣＨに現在割り当てられるコードチャネルの数、
前記ＲＮＣ（４）のバッファの現在の状態を示すバッファステータス（BufferStatus）、および
前記ノードＢ（５）中に実装されるＨＡＲＱ（ハイブリッド自動再送要求）を構成するために前記ノードＢ（５）により現在使用される１つ以上のパラメータ、
のパラメータのうちの少なくとも１つを含む請求項３６〜３８のいずれか１項に記載の方法。
【請求項４０】
ＨＡＲＱを構成するために前記ノードＢ（５）により使用される前記１つ以上のパラメータは、ＨＡＲＱのために使用されるチャネルの数、ＨＡＲＱのための許可された最大試行回数、および前記ノードＢ（５）が選ぶことができる冗長度バージョンの制限のうちの少なくとも１つを含む請求項３９に記載の方法。
【請求項４１】
前記少なくとも１種類の制御メッセージは、無線リンク設定要求メッセージ、無線リンク設定応答メッセージ、無線リンク再構成準備メッセージおよび無線リンク再構成実行可能メッセージのうちの少なくとも１つである請求項３６〜４０のいずれか１項に記載の方法。
【請求項４２】
少なくとも１つのコントローラ（４）と少なくとも１つのネットワーク要素（５）とを含む通信ネットワークであって、コントローラ（４）およびネットワーク要素（５）は、インタフェース経由で互いに接続されており、前記通信ネットワークは、請求項３６〜４１のいずれか１項に記載の方法に従って前記コントローラ（４）から前記ネットワーク要素（５）へ前記インタフェースを介して送信される少なくとも１種類の制御メッセージ中に少なくとも１つの制御パラメータを挿入することにより前記コントローラ（４）が前記ネットワーク要素（５）に前記少なくとも１つの制御パラメータを提供できるようにするインタフェース適用プロトコルの実装をさらに含む通信ネットワーク。
【請求項４３】
前記通信ネットワークはＵＴＲＡＮ（汎用移動通信サービス地上無線アクセスネットワーク）であり、前記コントローラはＲＮＣ（無線ネットワークコントローラ）（４）であり、前記ネットワーク要素はノードＢ（５）であり、前記インタフェースはＩｕｂインタフェースである請求項４２に記載の通信ネットワーク。
【請求項４４】
通信ネットワークのためのコントローラ（４）であって、該コントローラ（４）は、請求項４２または４３に記載の通信ネットワークによりインタフェースを介して前記コントローラ（４）から前記ネットワーク要素（５）へ送信される制御メッセージ中に前記少なくとも１つの制御パラメータを挿入することにより、インタフェース適用プロトコルに従って前記インタフェース経由で前記通信ネットワークのネットワーク要素（５）に少なくとも１つの制御パラメータを、供給するための手段を含むコントローラ。
【請求項４５】
前記コントローラはＵＴＲＡＮのＲＮＣ（無線ネットワークコントローラ）である請求項４４に記載のコントローラ（４）。
【請求項４６】
通信ネットワークのためのネットワーク要素（５）であって。前記通信ネットワークのコントローラ（４）からインタフェース経由で制御メッセージを受信し、請求項４２または４３記載の通信ネットワークによって前記コントローラ（４）により少なくとも１つの制御パラメータが中に挿入された少なくとも１種類の受信メッセージから少なくとも１つの制御パラメータを抽出するための手段を含むネットワーク要素。
【請求項４７】
前記ネットワーク要素（５）は、ＵＴＲＡＮ（汎用移動通信サービス地上無線アクセスネットワーク）のノードＢである請求項４６に記載のネットワーク要素。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【公開番号】特開２００９−１５３１８３（Ｐ２００９−１５３１８３Ａ）
【公開日】平成２１年７月９日（２００９．７．９）
【国際特許分類】
【出願番号】特願２００９−４３１０９（Ｐ２００９−４３１０９）
【出願日】平成２１年２月２５日（２００９．２．２５）
【分割の表示】特願２００３−５２４２８１（Ｐ２００３−５２４２８１）の分割
【原出願日】平成１３年８月２１日（２００１．８．２１）
【出願人】（３９８０１２６１６）ノキア コーポレイション (1,359)
【Ｆターム（参考）】
【公開日】平成２１年７月９日（２００９．７．９）
【国際特許分類】
【出願日】平成２１年２月２５日（２００９．２．２５）
【分割の表示】特願２００３−５２４２８１（Ｐ２００３−５２４２８１）の分割
【原出願日】平成１３年８月２１日（２００１．８．２１）
【出願人】（３９８０１２６１６）ノキア コーポレイション (1,359)
【Ｆターム（参考）】
[ Back to top ]