JP4331598B2

JP4331598B2 - 通信ネットワーク内のデータ送信

Info

Publication number: JP4331598B2
Application number: JP2003524281A
Authority: JP
Inventors: サルッキネン，シニッカ; ファン，ウーンヘー
Original assignee: Nokia Oyj
Current assignee: Nokia Oyj
Priority date: 2001-08-21
Filing date: 2001-08-21
Publication date: 2009-09-16
Anticipated expiration: 2021-08-21
Also published as: US20140301399A1; CN1557105A; KR20040027916A; ES2518221T3; CA2456266C; BRPI0117120B1; EP2785132A2; BR0117120A; KR100825413B1; US20120320867A1; CN100474975C; US8280424B2; EP1419667A1; CA2456266A1; EP1419667B1; WO2003019960A1; EP2785132A3; JP2005501494A; US20050063347A1; US8774822B2

Description

本発明は、通信ネットワーク、例えばＵＴＲＡＮ（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)）”に記載されるＤＳＣＨ設定および再構成のためのＩｕｂに関する現在の適用プロトコル手順は、ＨＳ−ＤＳＣＨについて使用できない。例えば、ＨＳＤＰＡのケースでは、ＤＳＣＨについての無線リンク（ＲＬ）設定の間に、チャネルコーディングパラメータを提供する必要はない。なぜならば、これらのチャネルコーディングパラメータはノードＢ中で決定されるからである。他方では、ＤＳＣＨのためにノードＢにより要求されないいくつかのパラメータは、ノードＢがセル中にＨＳ−ＤＳＣＨ属性を構成できるように、セル構成手順の間にＨＳＤＰＡのためにノードＢに提供されるべきである。さらに、これらのパラメータを好ましくは準静的な方法でセルベースに変更することが可能であるべきである。

通信ネットワーク内で前記通信ネットワークのネットワーク要素において要求されるデータの送信を可能にすることが本発明の目的である。

ＵＴＲＡＮによるＨＳＤＰＡの使用を可能にすること、より具体的にはＵＴＲＡＮのＲＮＣがＨＳＤＰＡ関連データをＵＴＲＡＮのノードＢに提供できるようにすることも本発明の目的である。

ＲＮＣが適当な方法でＨＳＤＰＡ関連ユーザデータおよびＮＢＡＰ（ノードＢ適用部分）についてのＨＳＤＰＡ関連制御パラメータをノードＢに提供できるようにすることがとりわけ本発明の目的である。

本発明の第１の形態はユーザデータの送信を目的とするのに対して、本発明の第２の形態は制御パラメータの送信を目的とする。

本発明の第１の形態として、通信ネットワーク内でユーザデータをコントローラからネットワーク要素へインタフェース経由で送信するための方法が提案される。通信ネットワークは特にＵＴＲＡＮ、コントローラはＲＮＣ、ネットワーク要素はノードＢそしてインタフェースはＩｕｂインタフェースとすることができる。コントローラは、ユーザデータによってデータフレームを構成するために、少なくとも１つの専用フレーム構造、特に専用ＨＳＤＰＡＦＰフレーム構造を使う。次にデータフレームはインタフェース経由でネットワーク要素に送信される。フレーム構造は、ユーザデータを処理するために前記ネットワーク要素中で要求される情報を受信するための少なくとも１つのヘッダセクションを含んでいる。

本発明の第１の形態として、さらに、提案された方法を実現するための手段を含む、通信ネットワーク特にＵＴＲＡＮ、コントローラ特にＲＮＣ、およびネットワーク要素特にノードＢが提案される。

第１の形態に関し、本発明は、ＨＳＤＰＡ関連ユーザデータの処理に必要な情報の送信は、他の共用チャネルに使用される解決策と同様であるべきだが、ＨＳＤＰＡの要件についてなお最適化されるべきである、という考えから発している。提案された専用フレーム構造により、ＨＳＤＰＡにとりもはや必要ではないＤＳＣＨのための構造中で使用されたすべてのフィールドを削除すること、およびＨＳＤＰＡのために付加的に要求される情報のためのフィールドを挿入することが可能になる。かくして、Ｉｕｂインタフェース経由でのＨＳＤＰＡ関連ユーザデータのために必要な情報の最適化された送信が可能になる。同じ考えを他の通信ネットワーク、ネットワーク要素および状況に適用し得る。

本発明の第２の形態として、通信ネットワークのコントローラにおいて利用可能な制御パラメータを通信ネットワークのネットワーク要素に提供する方法が提案され、コントローラはインタフェース経由で前記ネットワーク要素に接続される。通信ネットワークは特にＵＴＲＡＮ、コントローラはＲＮＣ、ネットワーク要素はノードＢそしてインタフェースはＩｕｂインタフェースとすることができる。この方法は、少なくとも１つの制御パラメータ、特にＨＳＤＰＡ関連制御パラメータを、前記コントローラから前記ネットワーク要素へ前記インタフェース経由で送信された少なくとも１種類の制御メッセージ中に挿入することを可能にするインタフェース適用プロトコルを使用することを含む。

また本発明の第２の形態として、さらに、提案された方法を実現するための手段を含む、通信ネットワーク特にＵＴＲＡＮ、コントローラ特にＲＮＣ、およびネットワーク要素特にノードＢが提案される。

第２の形態に関し、本発明は、ＨＳＤＳＣＨチャネルを設定および再構成するために必要な制御パラメータをノードＢに提供するための最も効率的な方法は、ＲＮＣからノードＢに送信される制御メッセージ中にパラメータを含めることであるという考えに発する。ＲＮＣおよびノードＢはＩｕｂインタフェース経由で互いに接続されるので、従って、Ｉｕｂ適用プロトコルをそれに応じて変更することが提案される。結果として、ノードＢは、例えば、受信された制御パラメータに基づいてＨＳ−ＤＳＣＨチャネルを設定および再構成することが可能である。ノードＢは、従って、セル中のユーザ装置へのＨＳＤＰＡ関連データをサポートするようにＲＮＣによって構成できる。同じ考えを他の通信ネットワーク、ネットワーク要素および状況に適用し得る。

本発明の双方の形態は、ＲＮＣからノードＢへＩｕｂインタフェース経由でデータを送信するために使われる一般仕様のＨＳＤＰＡの特定の実現、すなわち、一方では専用フレーム構造の実現を、他方ではＨＳＤＰＡの特定の手順を持つＩｕｂ適用プロトコルの実現をこれらが含んでいるという点で共通している。

本発明の好ましい実施形態は、サブクレームから明らかになる。

本発明の第１の形態の好ましい実施形態において、フレーム構造は、前記コントローラによってＨＳＤＰＡ関連ユーザデータが配信された少なくとも１つのＳＤＵを受信するためのペイロードセクションをさらに含んでおり、ヘッダセクションは、ＨＳＤＰＡ関連ユーザデータを処理するためにネットワーク要素において要求される情報を受信する。かくして、ＨＳＤＰＡ関連ユーザデータを処理するためにノードＢにおいて要求される情報は、前記ユーザデータと一緒に単一フレームで有利に送信し得る。ＳＤＵは、特にＭＡＣ−ｄＳＤＵおよび／またはＭＡＣ−ｃ／ｓｈＳＤＵである。

本発明の第１の形態について、提案されたＨＳＤＰＡＦＰフレーム構造は、どのような数の情報も受信するように設計でき、情報は要件に従って任意に前もって決定し得る点に注目しなければならない。

さらに、ヘッダセクション中のみの情報、例えばＨＳＤＰＡフロー制御のための情報を送信するために同じ構造を使用し得るように、ペイロードセクションが、専用フレーム構造に従って構成されたフレーム中の任意のデータを含むことは必須とされるべきではない。

特に、ＭＡＣ／ＦＰＵＥ−ＩＤ多重化がＲＮＣ中で許可されているか、又は許可されていないかの場合のために、種々の各種ＦＰフレーム構造が提供され得る。ＵＥ−ＩＤ多重化は、種々のＵＥが同じトランスポートチャネル上に多重化されてＲＮＣのＭＡＣ層またはＦＰ層において実行できる多重化タイプである。ＦＰＵＥ−ＩＤ多重化のケースでは、ＦＰフレームのヘッダは常にＵＥ−ＩＤ識別を含むべきである。この識別は、例えばＲＮＴＩとすることができ、あるいは、この目的にのみ定義された新しい識別とし、従って現行のＲＮＴＩよりも短くすることができる。ＭＡＣＵＥ−ＩＤ多重化のケースでは、ＵＥ−ＩＤフィールドはＭＡＣヘッダ中で使用され、すなわち、ＲＮＴＩはＭＡＣヘッダ中に付加され、ＦＰフレーム中では識別が必然的に全く要求されない。ノードＢは、ＭＡＣヘッダを読むことによりＵＥ−ＩＤ情報を取り出すことができる。またその一方で、ＭＡＣヘッダ中へのＲＮＴＩの付加にもかかわらずＦＰフレームがＵＥ−ＩＤフィールドを含むことが望まれるのであれば、使用されるＵＥ−ＩＤは、例えばＲＮＴＩとすることができ、あるいは、この目的にのみ定義された新しい識別とし、従って現行ＲＮＴＩよりも短くすることができる。

多重化を実行できるさらに種々の選択可能な方法があり、使用される多重化方法は、ＦＰフレームの最適構造を決定する際に考慮されなければならないことがある。使用される多重化の種類は、特に、１つのＦＰフレーム中に提供される同じ種類のフィールド数への影響を特に持ち得る。多重化のための１つの代替方法は、時分割ベース多重化であり、これは、１つのＦＰデータフレームは、１つのＵＥにのみ属するデータを運ぶことができることを意味する。別の代替方法では、１つのＦＰフレーム中で種々のＵＥに属するデータを運ぶことが可能である。さらに、多重化は、ＦＰエンティティに、１つのＴＴＩ内の１つのＦＰフレームのみを送ることを可能にすることによって処理でき、このフレームは、ただ１つのＵＥに当てられるか、またはこのフレームは多くのＵＥのためのデータを送信できるであろう。多重化は、ＦＰエンティティが、１つのＵＥにすべて割当てられる１つのＴＴＩ内の１つより多いＦＰフレームを送り得ること、あるいは、各ＦＰフレームが、種々のＵＥのためのデータを運ぶことができるであろうことも意味し得る。

同様に、種々のＦＰフレーム構造は、ユーザ装置識別がＲＮＣからノードＢへ送信されなければならないか、またはされなくてもよい場合に提供できる。

１つの所定フレーム構造に基づくフレームのサイズは、各ユーザ装置またはデータが取られる各ＲＮＣバッファのための専用フィールドをヘッダセクション中のいくらかの情報に充てることによって可変にできる。フィールド構造は、情報のいくつかの挿入を任意にすることによりさらに一般化できる。

特定のフレーム構造により考慮に入れられるいくらかの情報は、ＲＮＣバッファまたはＲＮＣにおいてユーザデータをバッファリングするためにＨＳＤＰＡデータ通信において使用されるバッファリングと関連させることができる。ＲＮＣバッファリングまたはＲＮＣバッファの用語は、バッファの正確な位置を識別することなくＲＮＣにおけるバッファ能力を示すために使用されることに注目しなければならない。従って、バッファリングは、例えばＲＬＣ層上および／またはＭＡＣ層上で提供し得る。

本発明の第１の形態において、いくつかのユーザ装置の特定の情報はさらに、提案されたフレーム構造のヘッダセクションに含まれるか、あるいは提案されたフレーム構造のペイロードセクションに挿入されたそれぞれのＳＤＵのヘッダセクション中に含まれ得る。

本発明の第２の形態において、同様にＩｕｂ適用プロトコルは、任意の適当な種類および数のパラメータを要件に従って適当な種類のメッセージ中に含むことを可能にする。

本発明の第２の形態に従ってＲＮＣからノードＢへ提供されなければならないことがあり得る２クラスの制御パラメータがある。ＲＮＣがパラメータの正確な値を決めてノードＢがこの決定に続かなければならないか、さもなければＲＮＣは可能な選択の限界を提供する。後者のケースにおいて、ノードＢは、提供された限界内のそれ自身の条件に従って値を決めることができる。かくして、各制御パラメータの内容は、固定値、その値についての範囲の表示、または前記ノードＢにより使用されるべき許可された値のセットのいずれかである。

本発明の第２の形態の制御パラメータは特に、例えばセルの設定および／または再構成のためにノードＢにおいて要求されるセルの特定パラメータ、あるいは例えば無線リンクの設定および／または再構成のためにノードＢにおいて要求される無線リンクの特定パラメータとし得る。次に、パラメータが、セル設定または再構成に関連する制御メッセージ中あるいはＲＬ設定または再構成にそれぞれ関連する制御メッセージ中に含められるべきであることがＩｕｂ適用プロトコルによって決定され得る。

セルの特定パラメータおよびＲＬの特定パラメータ双方は、特定値または選択限界として提供できる。

本発明の第２の形態の制御パラメータを制御メッセージ中に含めるために、好ましくは１つ以上の情報要素（ＩＥ）またはＩＥのグループが定義される。各ＩＥは次に、特定状況のために要求される各パラメータのためのフィールドを含み得る。ＩＥは、この特定の状況おいて送信されなければならない制御メッセージに付加できる。さらに、ＤＳＣＨまたは対応するＩＥについて定義されたＩＥは、要求されるパラメータがいくつかの状況について同じである限り、使用することができる。それぞれの状況のために何らかの制御メッセージに付加されるべき特定の状況についてのＩＥのセットおよび／またはＩＥのグループを定義することも可能である。

以下、図面を参照して本発明をより詳細に説明する。

最初に、本発明の第１の形態に応じたＨＳＤＰＡＦＰフレーム構造の３つの実施形態を提示する。

それぞれのフレーム構造は、ＵＴＲＡＮ内でＨＳＤＰＡ関連ユーザデータをＲＮＣのＭＡＣ−ｃ／ｓｈからＩｕｂインタフェース経由でノードＢのＭＡＣ−ｈｓへ送信するために使用されるものである。ユーザデータがアドレスされるＵＥは、このノードＢに接続される。

適当なフレーム構造を決定する際、ネットワーク要素の要件および機能、すなわちＲＮＣおよびノードＢが考慮されるべきである。考慮されるべき１つの要因は、例えばＭＡＣ／ＦＰＵＥ−ＩＤ多重化であり、これは以下で説明されるように、ＲＮＣにおいて許可することもできるし、許可しないこともできる。

図５で例示される第１のモデルにおいて、ＲＮＣは、ＭＡＣ／ＦＰＵＥ−ＩＤレベル多重化を実行することができない。

図５は、Ｉｕｂインタフェースにより相互接続されたＲＮＣ４およびノードＢ５を概略的に示している。ＲＮＣ４は、ＲＬＣ６、ＭＡＣ−ｄおよびＭＡＣ−ｃ／ｓｈ２、３ならびにＦＰエンティティ７を含んでいる。同様にノードＢ５は、ＦＰエンティティ８、およびＭＡＣ−ｈｓ１を含んでいる。図示では、３つの無線ベアラＲＢｗ、ｚおよびｖは、第１のユーザ装置ＵＥｘに割り当てられるのに対して、さらに２つの無線ベアラＲＢｍおよびｎは、第２のユーザ装置ＵＥｙに割り当てられる。ＵＥｙのＲＢおよび同様にＵＥｘのＲＢｖは、多重化せずに論理チャネル中のＲＬＣ６からＭＡＣ−ｄおよびＭＡＣ−ｃ／ｓｈ２、３ならびにＦＰエンティティ７、ＩｕｂインタフェースおよびノードＢ５のＦＰエンティティ８経由でＭＡＣ−ｈｓ１へ渡される。ＵＥｘのＲＢｗおよびｚは、ＲＮＣ４のＭＡＣ層中でＣ／Ｔ多重化され、シングルトランスポート接続上を同じエンティティ経由でノードＢ５へ送信される。Ｃ／Ｔ多重化は、種々のＲＢ、すなわち種々の論理チャネルを使用しており、同じトランスポートチャネル上の同じＵＥにすべてが割り当てられるＲＢの多重化を意味する。次にＭＡＣ−ｈｓ１は、受信された論理チャネルをトランスポートチャネル上にマッピングする。

同じＵＥにすべてが割り当てられる無線ベアラ（ＲＢ）の間でＣ／Ｔ多重化が実行可能であれば、要求されるＩｕｂ送信接続の最小数は、ＨＳ−ＤＳＣＨにアクセスできるＵＥの数と等しい。Ｃ／Ｔ多重化は、例えば図５におけるように、いくつかのＵＥのいくつかのＲＢについてのみ、またはすべてのＵＥのすべてのＲＢについて、ＲＮＣにより使用され得る。

代わりに、同じＩｕｂ送信接続への種々の無線ベアラＲＢのＣ／Ｔ多重化は、図５のＲＮＣ４において許可されなくてもよい。Ｃ／Ｔ多重化は、すべての無線ベアラが同じＵＥに割り当てられれば、例えば種々の優先順位レベルのせいで、提供することさえできなくてもよい。このケースでは、Ｉｕｂインタフェース上のトランスポート接続の数は、ＨＳＤＰＡタイプトランスポート方法を使用している無線ベアラの数と等しい。

図６において例示される第２のモデルにおいて、ＲＮＣ４は対照的に、ＭＡＣレベルＵＥ−ＩＤ多重化を実行できる。

図６は、図５のようにＩｕｂインタフェースにより相互接続されたＲＮＣ４およびノードＢ５の同じ構造を概略的に示す。このケースにおいてのみ、独立したＭＡＣ−ｄ３およびＭＡＣ−ｃ／ｓｈ２が描かれている。さらに、同じ無線ベアラＲＢｗ、ｚ、ｖ、ｍおよびｎは、図５のように同じユーザ装置ＵＥｘ、ＵＥｙに割り当てられている。無線ベアラＲＢｗおよびＲＢｚは、再度ＭＡＣ層において、より詳細にはＭＡＣ−ｄ３により、Ｃ／Ｔ多重化される。さらに、Ｃ／Ｔ多重化ならびに３つの他の無線ベアラＲＢｖ、ｍおよびｎの出力は、ＭＡＣ−ｃ／ｓｈ２により、ＲＮＣ４のＦＰ層７、ＩｕｂインタフェースおよびノードＢ５のＦＰ層８経由でＭＡＣ−ｈｓ１へ送信するための単一のシングルトランスポート接続に多重化にされたＵＥ−ＩＤである。ＭＡＣ−ｈｓ１は最初に多重分離を実行し、次にトランスポートチャネル上への論理チャネルのマッピングを実行する。

ノードＢ５において、ＭＡＣ層は、受信した情報を、図５におけるようにこれをＨＳ−ＤＳＣＨにさらにＨＳ−ＰＤＳＣＨ上にマッピングする前に、対応して多重分離する。

多重化において使用される１つより多いトランスポート接続もあり得る。多重化における一般的な概念は、同じ基準を満たすすべてのＵＥは同じトランスポート資源を使うことが可能であるということである。多重化は、例えばノードＢ中のセル数に基づくことができる。これが意味するのは、もしノードＢが１より多いセルをサポートすれば、セル当たり１つのトランスポートが提供されるということである。代わりに、多重化は、論理チャネルに割り当てられた優先順位レベルに基づくことができ、すなわち優先準位当たり１つのトランスポート接続が提供される。さらに、単一トランスポート接続のみが１つのノード−Ｂに提供できる。多重化は、無線インタフェース上のＨＳＤＰＡ関連物理チャネル数に基づくこともできるであろう。

第２のモデルにおいて、ＭＡＣ／ＦＰＵＥ−ＩＤ多重化は、どのようにも限定されておらず、このことは、すべてのＵＥがＩｕｂインタフェース上の同じトランスポート接続を使用できることを意味する。

第２のモデルは、ＵＥ−ＩＤ多重化をＦＰ層に置くことによっても提供できる。両方のケースにおいて、もしＲＮＴＩがＭＡＣヘッダ中で使用されれば、ＦＰフレーム中でどのようなＵＥ−ＩＤも強制的ではなく、さらにもし識別がＭＡＣヘッダ中に全く含まれなくても多重化が可能であれば、ＦＰヘッダはＵＥ−ＩＤフィールドも含むはずである。

ＭＡＣ／ＦＰＵＥ−ＩＤ多重化が許可される場合、フレーム構造は、種々のＵＥに属する情報を受信されたＨＳＤＰＡフレームから受信機が正しく抽出できるように定義されるべきである。

ところで図７〜１０は、比較のために提示されたＩｕｂインタフェースのために定義された従来のＤＳＣＨＦＰフレーム構造、ＵＥ−ＩＤ多重化が全く許可されないケースについてのＨＳＤＰＡＦＰフレーム構造の第１の実施形態ならびにＵＥ−ＩＤ多重化が許可されケースについてのＨＳＤＰＡＦＰフレーム構造の第２および第３の実施形態を示す。

図７のＤＳＣＨＦＰフレーム構造は、技術仕様書３ＧＰＰＴＳ２５．４３５、Ｖ３．５．０（２０００−１２）：“第３世代パートナーシッププロジェクト；技術仕様書グループ無線アクセスネットワーク；共通トランスポートチャネルデータストリームのためのＵＴＲＡＮＩｕｂインタフェースユーザプレーンプロトコル（リリース１９９９）”から取った。このフレーム構造は、ペイロードセクションとヘッダセクションとで構成されており、各々が８ビット０−７の行に分割されている。ペイロードセクションは、第１から最終のＴＢ（トランスポートブロック）、“予備エクステンション”、および“ペイロードＣＲＣ”（巡回冗長検査）を含む。ヘッダセクションは、フィールド“ヘッダＣＲＣ”、“ＦＴ”、“ＣＦＮ”、“ＴＦＩ”、“パワーオフセット”、“コードナンバー”、“ＳＦ”および“ＭＣ情報”を含む。

“ＣＦＮ”フィールドは、接続フレーム数（ＣＦＮ）を示すために使用され、そこではフレームのデータは無線インタフェースを通して送信されるべきである。ＨＳＤＰＡ概念において、このフィールドの値は、対応するデータの無線インタフェースへのスケジューリング後に初めてノードＢにより知られ、従ってＲＮＣはこのフィールドをノードＢへ提供できない。

“ＴＦＩ”フィールドは、フレーム中のデータにとり有効なトランスポートフォーマット（ＴＦ）を示すために使用される。ＨＳＤＰＡ概念において、ＴＦＣ選択はノードＢにおいて実行され、従って、ＲＮＣはそのような情報をノードＢに送出できない。

“パワーオフセット”フィールドは、対応するＦＰフレームのデータを送信するために要求されるパワーレベルを示すために使用される。ＤＳＣＨのために閉ループパワー制御が提供されるので、このフィールドはＤＳＣＨのケースにおいて要求される。ＨＳＤＰＡのケースでは、閉ループパワー制御は全く提供されず、従って、パワー制御情報はＲＮＣから全く要求されない。

“コードナンバー”フィールドは、ＤＳＣＨのために使用されるコードを示す。ＨＳＤＰＡのケースでは、コード選択はノードＢにおいてなされ、従って、そのような情報はＲＮＣから全く要求されない。

“ＳＦ”フィールドは、フレーム中の対応データパケットのためにＰＤＳＣＨ中で使用される拡散率（ＳＦ）を特定する。ＨＳＤＰＡ概念において、ＳＦはノードＢにおいて定義され、従って、そのような情報はＲＮＣから全く要求されない。

“ＭＣ情報”フィールドは、ＤＳＣＨデータがその上を運ばれる平行ＰＤＳＣＨコードの数を示すために使用される。ＨＳＤＰＡ概念において、この種の情報はノードＢにおいて定義されて、従って、そのような情報はＲＮＣから全く要求されない。

かくして、“ヘッダＣＲＣ”フィールドおよび“ＦＴ”（フレームタイプ）フィールドを除くヘッダセクションのフィールドのどれもＨＳＤＰＡのために要求されず、これらのフィールドは、ＨＳＤＰＡＦＰフレーム構造を設計する際に排除し得る。しかし、他方で、もしフィールドが単に排除されると、ノードＢは、受信されたＦＰフレームを抽出するための十分な情報を受信しない。従って、新しいＭＡＣエンティティＭＡＣ−ｈｓがノードＢ中に置かれる時にフロー制御機構が機能することを保証するために、新しいフィールドが要求される。

図８は、ＭＡＣ／ＦＰＵＥ−ＩＤ多重化が全く許可されないケースのためのそのような新しいフィールドを含むＨＳＤＰＡフレーム構造を示す。これも、ペイロードセクションとヘッダセクションとで構成されており、各々が８ビットの行に分割されている。ＤＳＣＨフレーム構造と同様に、ペイロードセクションは、第１から最終のＭＡＣ−ｃ／ｓｈＳＤＵ（サービスデータユニット）、“予備エクステンション”、および“ペイロードＣＲＣ”を含む。可変ヘッダを持つＭＡＣＳＤＵの構造は、ＭＡＣＰＤＵとして最新技術から既知であり、図１１を参照して以下で説明される。ヘッダセクションは現在、“ヘッダＣＲＣ”、“ＦＴ”、“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”を含み、そしてことによると“ＨＡＲＱ容量”グループのＩＥを含む。このセットのＩＥは、無線リンク再構成準備メッセージ中に含めることもできる。

ＲＬ関連ＩＥの多くは、例えば、参照により本明細書に組み込まれ、更なる詳細について参照される上記引用の技術仕様書ＴＳ２５．４３３中に提示されるＤＳＣＨ関連ＩＥと対応する意味を有している。

ＤＳＣＨについてＩＥグループ“ＨＡＲＱ容量”が知られておらず、これはＲＬのＨＡＲＱ特徴を表すものであり、ＵＥ機能および／またはＲＬのＱｏＳも反映できる。

さらに、ノードＢ中のＭＡＣヘッダの完了を助けるために、ＩＥ“ＵＥ＿ＩＤ”が新しいパラメータとして加えられた。もしＩＤがＭＡＣヘッダ中に全く含まれないか、または要求されなければ、このパラメータは代わりにＦＰ層上で同じ目的のために使用され得る。

ＩＥ“トランスポート形式セット”は、ＤＳＣＨについての対応するＩＥと非常に似ているが、ＨＳ−ＤＳＣＨをサポートするために、いくつかのＩＥについて新規な値が定義されねばならない。これは図１８に示してあり、この図は、上記引用の仕様書ＴＳ２５．４３３から取られたＤＳＣＨトランスポート形式セットについての表を示し、いくつかの変更には下線が付してある。

より具体的には、“送信時間間隔”ＩＥについてより可能性のある値、すなわち“１スロット”、“３スロット”、“５スロット”および“１５スロット”が加えられる。これらの値は、ＨＳ−ＤＳＣＨのためのみに使用されるべきであり、他のどの値もＨＳ−ＤＳＣＨに適用されるべきではない。加えて、“畳み込み”値は、ＨＳＤＰＡについての“チャネルコーディングのタイプ”ＩＥにおいて使用されるべきではない。

かくして、本発明の第２の形態の提示された実施形態において、基本的ＩＥが定義され、これらは、ＨＳＤＰＡをサポートするために、セル設定および再構成ならびにＲＬ設定および再構成の間に提供され得る。説明したＩＥのセットおよびＩＥ自身は、特定の要件に適合するように、任意の適当な方法で変更され得る。同様に、ＨＳＤＰＡ関連制御情報のどのような必要な転送も可能にするために、さらなるＩＥのセットがＩｕｂ適用プロトコル中に定義し得る。

ＨＳＤＰＡのために定義された既知のＵＴＲＡＮ−サイドの全体のＭＡＣアーキテクチャを示す図である。ＲＮＣの既知のＭＡＣ−ｃ／ｓｈの詳細を示す図である。ノードＢの既知のＭＡＣ−ｈｓの詳細を示す図である。ＨＳＤＰＡのために定義された既知の無線インタフェースプロトコルアーキテクチャを示す図である。ＭＡＣレベル多重化がＲＮＣ中で全く許可されない場合の、Ｉｕｂのためのモデルを示す図である。ＭＡＣレベル多重化がＲＮＣ中で許可される場合の、Ｉｕｂのためのモデルを示す図である。既知のＤＳＣＨＦＰフレーム構造を示す図である。本発明によるＨＤＳＰＡＦＰフレーム構造の第１の実施形態を示す図である。本発明によるＨＤＳＰＡＦＰフレーム構造の第２の実施形態を示す図である。本発明によるＨＤＳＰＡＦＰフレーム構造の第３の実施形態を示す図である。ＭＡＣＰＤＵ構造を例示する図である。図１０の実施形態のための可能なＦＰフレームヘッダフィールド値の第１の例を示す図である。図１０の実施形態のための可能なＦＰフレームヘッダフィールド値の第２の例を示す図である。本発明の第２の形態の実施形態のためのセルの特定ＩＥのセットを示す図である。本発明の第２の形態の実施形態のためのＲＬセルの特定ＩＥのセットを示す図である。本発明の第２の形態の実施形態のためのＲＬセルの特定ＩＥの第１のセットを示す図である。本発明の第２の形態の実施形態のためのＲＬセルの特定ＩＥの第２のセットを示す図である。本発明の第２の形態の実施形態のための既知のＴＦＳの変更を例示する図である。

Claims

少なくとも１種類の制御メッセージ中に少なくとも１つの制御パラメータを挿入するためにインタフェース適用プロトコルを使用するステップと、
通信ネットワークのコントローラから前記通信ネットワークのネットワーク要素へ、インタフェースを介して前記制御メッセージを送信するステップと、
を有し、
前記少なくとも１つの制御パラメータは、
前記ネットワーク要素が使用するチャネルに割り当てられるコードチャネルの数と、
前記ネットワーク要素が使用する送信時間間隔長の表示と、
前記ネットワーク要素中に実装されるハイブリッド自動再送要求を構成するために前記ネットワーク要素が使用する１又は複数のパラメータと、
のうち少なくとも一つを含む方法。
通信ネットワークのための装置であって、
該装置から前記通信ネットワークのネットワーク要素へインタフェースを介して送信される制御メッセージ中に少なくとも１つの制御パラメータを挿入することによって、インタフェース適用プロトコルに従って前記インタフェースを介して前記ネットワーク要素に前記少なくとも１つの制御パラメータを提供するための手段
を備え、
前記少なくとも一つの制御パラメータは、
前記ネットワーク要素が使用するチャネルに割り当てられるコードチャネルの数と、
前記ネットワーク要素が使用する送信時間間隔長の表示と、
前記ネットワーク要素中に実装されるハイブリッド自動再送要求を構成するために前記ネットワーク要素が使用する１又は複数のパラメータと、
のうち少なくとも一つを含む装置。
通信ネットワークのための装置であって、
前記通信ネットワークのコントローラからインタフェースを介して制御メッセージを受信し、前記コントローラによってインタフェース適用プロトコルに従って少なくとも１つの制御パラメータが中に挿入された少なくとも１種類の受信メッセージから少なくとも１つの制御パラメータを抽出するための手段
を備え、前記少なくとも１つの制御パラメータは、
前記装置が使用するチャネルに割り当てられるコードチャネルの数と、
前記装置が使用する送信時間間隔長の表示と、
前記装置中に実装されるハイブリッド自動再送要求を構成するために前記装置が使用する１又は複数のパラメータと、
のうち少なくとも一つを含む装置。