JP5357051B2

JP5357051B2 - パケットペイロードの長さに基づいて、パケットのヘッダ内のフィールドに割り当てられるサイズを決定する方法および無線通信システム

Info

Publication number: JP5357051B2
Application number: JP2009544481A
Authority: JP
Inventors: ポールバックネル; マシューベイカー
Original assignee: Koninklijke Philips NV; Koninklijke Philips Electronics NV
Current assignee: Koninklijke Philips NV
Priority date: 2007-01-09
Filing date: 2008-01-07
Publication date: 2013-12-04
Anticipated expiration: 2028-01-07
Also published as: TW200847713A; DE602008006530D1; CN101578824A; EP2119142A1; US20090310537A1; JP2010516073A; ATE507694T1; TWI521927B; US20150156126A1; CN101578824B; KR20090106507A; US10652161B2; US20180159784A1; US8953519B2; KR101453256B1; EP2119142B1; WO2008084426A1; US9887926B2

Description

本発明は、全般的に、無線通信システム内において、一次局から二次局へデータ信号を送信する方法に関するものである。

本発明はまた、二次局にデータ信号を送信する一次局であって、それら一次局および二次局が上記のような無線通信システムの一部である、一次局にも関するものである。

本発明は、たとえば移動体通信の分野、とりわけユニバーサル・モバイル・テレコミュニケーション・システム（ＵｎｉｖｅｒｓａｌＭｏｂｉｌｅＴｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎｓＳｙｓｔｅｍ；ＵＭＴＳ）移動体通信の分野において、用途を有するものである。

図１は、ＵＭＴＳのためのプロトコルスタックを示した図表である。無線インターフェースは、以下の３層のプロトコルレイヤーに分かれた層構造とされている。
− 物理レイヤー（Ｌ１）
− データリンクレイヤー（Ｌ２）
− ネットワークレイヤー（Ｌ３）
より詳細な説明は、３ＧＰＰ規格書ＴＳ２５．３０１に記載されている。

レイヤー２は、媒体アクセス制御（ＭｅｄｉｕｍＡｃｃｅｓｓＣｏｎｔｒｏｌ；ＭＡＣ）、無線リンク制御（ＲａｄｉｏＬｉｎｋＣｏｎｔｒｏｌ；ＲＬＣ）、パケットデータ収斂プロトコル（ＰａｃｋｅｔＤａｔａＣｏｎｖｅｒｇｅｎｃｅＰｒｏｔｏｃｏｌ；ＰＤＣＰ）、および同報通信／マルチキャスト制御（Ｂｒｏａｄｃａｓｔ／ＭｕｌｔｉｃａｓｔＣｏｎｔｒｏｌ；ＢＭＣ）という、サブレイヤーに分けられている。レイヤー３およびＲＬＣは、制御（Ｃ−）プレーンとユーザー（Ｕ−）プレーンとに分けられている。ＰＤＣＰおよびＢＭＣは、Ｕ−プレーン上のみに存在する。Ｃ−プレーン内において、レイヤー３はサブレイヤーに区分されており、無線リソース制御（ＲａｄｉｏＲｅｓｏｕｒｃｅＣｏｎｔｒｏｌ；ＲＲＣ）と呼ばれる最下層のサブレイヤーは、レイヤー２と接続しており、ＵＴＲＡＮ内において終端する。サブレイヤー間のインターフェースにおいて、ピア・ツー・ピア通信のためのサービスアクセスポイント（ＳｅｒｖｉｃｅＡｃｃｅｓｓＰｏｉｎｔ；ＳＡＰ）は、円印によって記されている。ＭＡＣと物理レイヤーとの間のＳＡＰは、トランスポートチャネルを提供する。ＲＬＣとＭＡＣサブレイヤーとの間のＳＡＰは、論理チャネルを提供する。

さらに、ローカルにおけるレイヤー間制御サービスを提供するものとして、ＲＲＣとＭＡＣとの間の接続、およびＲＲＣとＬ１との間の接続も図示されている。これらのインターフェースは、ＲＲＣが、より低位のレイヤーの設定を制御することを可能とする。この目的のため、ＲＲＣとより低位の各層（ＰＤＣＰ、ＲＬＣ、ＭＡＣおよびＬ１）との間に、別個の制御ＳＡＰが規定されている。ＲＬＣサブレイヤーは、セグメント化／再アセンブリ機能に加えて、再送信機能も提供することができる。ＭＡＣサブレイヤーは、適切なトランスポートチャネルへの論理チャネルのマッピング、適切なトランポートフォーマットの組合せ（ＴｒａｎｓｐｏｒｔＦｏｒｍａｔＣｏｍｂｉｎａｔｉｏｎ）の選択、およびより高位層のプロトコルデータユニット（ＰｒｏｔｏｃｏｌＤａｔａＵｎｉｔ；ＰＤＵ）をトランスポートチャネルのＰＤＵ（トランスポートブロックと呼ばれる）に多重化する処理ならびにトランスポートチャネルのＰＤＵからより高位層のＰＤＵを多重分離する処理を、提供する。これは、ＭＡＣＰＤＵが、ＲＬＣＰＤＵ＋ＭＡＣヘッダとして定義されることを意味する。

ＲＬＣは、より高位の層に対して、以下の３つの主たる伝達サービスを提供する。
− ＴＭ（ＴｒａｎｓｐｏｒｔＭｏｄｅ；トランスポートモード）：より高位の層のＰＤＵに対して、ヘッダ情報を追加しない。ただし、必要であれば情報をセグメント化し、その際、セグメントのサイズは、トランスポートフォーマットから決められる。
− ＵＭ（ＵｎａｃｋｎｏｗｌｅｄｇｅｄＭｏｄｅ；否定応答モード）：上記のＴＭと同様だが、より高位の層のＰＤＵの連結も可能とする。したがって、ヘッダが必要とされる。
− ＡＭ（ＡｃｋｎｏｗｌｅｄｇｅｄＭｏｄｅ；肯定応答モード）：セグメント化ならびに再アセンブリ、連結、エラー訂正、より高位の層のＰＤＵをシーケンスで伝達する処理、複製（ｄｕｐｌｉｃａｔｅ）の検出、フローの制御、および暗号化を提供する。

図２は、ダウンリンクに関しＵＭＴＳのリリース６につき現在規定されている（すなわち高速ダウンリンクパケットアクセスＨＳＤＰＡ（ＨｉｇｈＳｐｅｅｄＤｏｗｎｌｉｎｋＰａｃｋｅｔＡｃｃｅｓｓ）につき現在規定されている）、ＭＡＣヘッダおよびデータペイロードを示している。このＭＡＣヘッダは、以下のものを含んでいる。
− 拡張機能のためのＶＦ（ＶｅｒｓｉｏｎＦｌａｇ；バージョンフラグ）
− ＵＥ（ＵｓｅｒＥｑｕｉｐｍｅｎｔ；ユーザー装置）側における再順序付けのキューを識別するための、キューＩＤ
− 再順序付けの目的のために使用されるＴＳＮ（ＴｒａｎｓｍｉｓｓｉｏｎＳｅｑｕｅｎｃｅＮｕｍｂｅｒ；送信シーケンス番号）（すなわち、受信されたＭＡＣＰＤＵは、対応のＴＳＮに従って、再順序付けされる）
− 連続する同一の長さのＰＤＵの組の、サイズを示すＳＩＤ_ｋ（ＳｉｚｅＩｎｄｅｘＩＤｅｎｔｉｆｉｅｒ；サイズ指標識別子）
− 連続するＰＤＵの数を表すＮ_ｋ
− ＳＩＤ_ｋまたはＰＤＵが後続しているか否かを示すフラグであるＦ_ｋ（０＝ＳＩＤが後続している、１＝ＰＤＵが後続している）

ＵＭＴＳのリリース７においては、ＭＡＣおよびＲＬＣを以下のように設計しようという提案がなされている。ＲＬＣ−ＡＭ（ＲａｄｉｏＬｉｎｋＣｏｎｔｒｏｌＡｃｋｎｏｗｌｅｄｇｅｄｍｏｄｅ；無線リンク制御肯定応答モード）が強化され、フレキシブルなＰＤＵサイズをサポートするものとされる（１つのＰＤＵは、プロトコルスタック中のレイヤー間において受け渡される、データおよび制御情報を含んでいる）。ＭＡＣ−ｈｓ（すなわち、高速ダウンリンク共有チャネルＨＳ−ＤＳＣＨ（ＨｉｇｈＳｐｅｅｄＤｏｗｎｌｉｎｋＳｈａｒｅｄＣＨａｎｎｅｌ）を制御する基地局内のＭＡＣエンティティ）が強化され、ＲＬＣＰＤＵのセグメント化をサポートするものとされる。ＳＩＤおよびＮフィールドは、ＲＬＣＰＤＵのサイズを指示できるように、アップデートされる必要がある（ＳＩＤは、論理チャネルとＮ個の連続するＲＬＣＰＤＵのサイズとを識別し、Ｎは、連続するＲＬＣＰＤＵの数である）。ＭＡＣ−ｈｓヘッダ中においてＶＦフラグを用いることにより、後方互換性が維持される可能性が極めて高いと見られている。

ＲＬＣの設計は、所与の実装形態においてレイヤー２データの処理に利用可能なメモリ、サポートされる最大のＲＬＣウインドウサイズ（具体的には、受信先にとって現在許容可能なシーケンス番号の範囲）、およびＲＬＣのラウンドトリップ時間を考慮に入れるべきである。ある所与のデータ量に対するＲＬＣＰＤＵの数が増大させられると、ＲＬＣ送信ウインドウはより速く進み、受信先は、ステータスレポート中においてより多くのＡＣＫ／ＮＡＣＫ（ＡＣＫｎｏｗｌｅｄｇｅｍｅｎｔ／ＮｅｇａｔｉｖｅＡＣＫｎｏｗｌｅｄｇｅｍｅｎｔ；肯定応答／否定応答）を生成する。ＲＬＣウインドウがストール状態になることを回避するため、Ｌ２ＲＬＣＲＴＴを減らしたいという動機づけが存在する。ＲＬＣウインドウのストール状態とは、ＲＬＣエンティティが、再送信およびＰＤＵの肯定応答を待たなくてはならない（すなわちウインドウが進めない）状態を指す。最大の持続可能レートは、（ゼロＲＬＣレベルの再送信を想定して、）レート＝ウインドウのサイズ × ＰＤＵのサイズ／ＲＴＴにより見積もることができる。

ＲＬＣウインドウのサイズとして２０４７（最大サイズは４０９５）、ＲＬＣとＵＥとの間のラウンドトリップ遅延として１００ミリ秒、およびＲＬＣＰＤＵのサイズとして３２０ビットを有する典型的な例を仮定すると、エラーのないフローは、２０４７×３２０／０．１＝６．５５Ｍｂｐｓの最大データレートを持続させる（６４０ビットのＰＤＵに対しては１３．１Ｍｂｐｓ）。

上記の説明から分かるように、ＲＬＣの最大の持続可能データレートは、ＵＭＴＳのリリース７においてＭＩＭＯまたはより高次の変調（６４ＱＡＭ）が使用される際に予期されるデータレート（１４Ｍｂｐｓよりも大）をサポートするのに十分なほど高くはない。したがって、レイヤー２に対し、何らかの改善を行う必要がある。

本発明の１つの目的は、無線通信システム内において、一次局から二次局にデータ信号を送信するための、改善された方法を提供することである。

本発明の第１の側面によれば、無線通信システム内において一次局から二次局にデータ信号を送信する方法であって、上記のデータ信号が、ヘッダと、そのヘッダと組み合わされたプロトコルデータユニットとを含むものであり、上記のヘッダが、フィールドの組を含むものであり、当該方法が、上記の組に含まれる少なくとも１つのフィールドに割り当てられるサイズを、プロトコルデータユニットの長さに基づいて決定する工程を含むことを特徴とする方法が提供される。

かかる方法は、ヘッダ内に含まれるフィールドを、プロトコルデータユニットの長さの関数として最適化することにより、ヘッダ内のオーバーヘッド量を低減する。

より具体的には、この方法は、ＲＬＣＰＤＵのサイズ、多重化およびセグメント化の可能な範囲に亘る最適化を可能とする、フレキシブルなＭＡＣヘッダフォーマットを提案するものである。本発明は、ＭＡＣヘッダ内でシグナリングされ得るフィールドコンテンツのすべての組合せが、必ずしもすべてのシナリオで有用であるというわけではなく、したがってフィールドのうちの少なくとも１つのサイズを減らすことによって、ＭＡＣヘッダのサイズを減らすことができるという認識に基づき、ＭＡＣヘッダのサイズの低減を許容するものである。いくつかのケースでは、この低減は、ヘッダの異なる複数のフィールド間の依存性を認識することから生じるものである。たとえば、第１のフィールドが、広範な値をシグナリングできることを要求される（大きなフィールドサイズを要求される）フィールドであるような特定のシナリオにおいては、第２のフィールドにおいて要求される値の範囲は低減させられ得ると特定されるかもしれず、したがって第２のフィールドのサイズは低減させられ得ると特定されるかもしれない。

本発明の１つの実施形態によれば、プロトコルデータユニットの第１の長さに対して決定される、セグメント化指示フィールドに割り当てられるサイズが、上記の第１の長さよりも長いプロトコルデータユニットの第２の長さに対して決定されるサイズよりも小さくされ、上記のセグメント化指示フィールドは、上記のプロトコルデータユニットが何個のセグメントにサブ分割されるかを示すものとされる。

本発明の別の実施形態によれば、プロトコルデータユニットの第１の長さに対して決定される、送信シーケンス番号フィールドに割り当てられるサイズが、上記の第１の長さよりも長いプロトコルデータユニットの第２の長さに対して決定されるサイズよりも大きくされ、上記の送信シーケンス番号フィールドは、上記のプロトコルデータユニットを再順序付けするために用いられる。

本発明は、小さなプロトコルデータユニットが、より広い範囲の送信シーケンス番号を伴い、かつセグメント化をほとんどもしくは全く伴わないのに対し、プロトコルデータユニットが大きいときは、典型的には、より多くのセグメント化を伴って、より小さな範囲の送信シーケンス番号が必要とされるという認識に基づいている。

本発明の別の実施形態によれば、プロトコルデータユニットの長さに基づいて、フォーマットフィールドの値が決定され、そのフォーマットフィールドの値は、上記の組に含まれる上記の少なくとも１つのフィールドに割り当てられるサイズを示すものとされる。

有利な形態では、上記の無線通信システムは、ユニバーサル・モバイル・テレコミュニケーション・システム（ＵＭＴＳ）とされる。

本発明の第２の側面によれば、二次局にデータ信号を送信する一次局であって、当該一次局および二次局は無線通信システムの一部をなし、上記のデータ信号が、ヘッダと、そのヘッダと組み合わされたプロトコルデータユニットとを含むものであり、上記のヘッダが、フィールドの組を含むものであり、当該一次局が、上記の組に含まれる少なくとも１つのフィールドに割り当てられるサイズを、プロトコルデータユニットの長さに基づいて決定する手段を含むことを特徴とする一次局が提供される。

かかる一次局は、携帯電話または基地局であってもよい。上記の決定する手段は、たとえばコントローラまたはプロセッサとされる。

本発明の第３の側面によれば、無線通信システム内において使用する、ヘッダと、そのヘッダと組み合わされたプロトコルデータユニットとを含むデータ信号であって、上記のヘッダが、
− 上記のプロトコルデータユニットの長さを示す長さ指標と、
− 上記のプロトコルデータユニットを再順序付けするために用いられる送信シーケンス番号、および／または上記のプロトコルデータユニットが何個のセグメントにサブ分割されるかを示すセグメント化指標とを含み、
上記の長さ指標、送信シーケンス番号およびセグメント化指標の１つに割り当てられるサイズが、上記の長さ指標に基づいて決定されることを特徴とするデータ信号が提供される。

最後に、本発明は、一次局の内部メモリに直接ローディング可能なコンピュータプログラムであって、当該コンピュータプログラムが前記一次局上で実行された際に、上記の方法のすべての工程を実行するためのソフトウェアコード部分を含むことを特徴とするコンピュータプログラムにも関するものである。

本発明の上記およびその他の側面は、以下で説明される実施形態を参照することにより、明らかとなる。

ＵＭＴＳのためのプロトコルスタックを示したブロック図ＵＭＴＳのリリース６に従う、ＭＡＣヘッダの構造を示した図本発明の種々の実施形態のうちの１つに係るＭＡＣヘッダの構造を示した図本発明の種々の実施形態のうちの１つに係るＭＡＣヘッダの構造を示した図本発明の種々の実施形態のうちの１つに係るＭＡＣヘッダの構造を示した図本発明の種々の実施形態のうちの１つに係るＭＡＣヘッダの構造を示した図

以下、添付の図面を参照しながら、単なる一例としての本発明の実施形態を説明する。

ＵＭＴＳのリリース７では、より高いデータレートをサポートするため、ＲＬＣ−ＡＭが、フレキシブルなＲＬＣＰＤＵのサイズを使用できるように設計し直されている。この設計変更は、新たなＭＡＣヘッダに対し、ＨＡＲＱ（ＨｙｂｒｉｄＡｕｔｏｍａｔｉｃＲｅｐｅａｔＲｅｑｕｅｓｔ；ハイブリッド自動反復要求）プロセス中に亘って、ＲＬＣＰＤＵの送信をサポートすることを要求する。

本発明は、送信されるべきデータのパケットサイズおよび／またはデータのクラスに依存するＲＬＣＰＤＵの可能なサイズ範囲に対して、最適化を可能とするような、フレキシブルなＭＡＣヘッダフォーマットを提案するものである。これにはたとえば、ＲＬＣＰＤＵのサイズ、および／または利用可能なトランスポートブロックのサイズ、および／または送信されるべき論理チャネルが包含される。

本発明は、以下の側面を考慮に入れたものである。シグナリングすることのできる送信シーケンス番号ＴＳＮ（ＴｒａｎｓｍｉｓｓｉｏｎＳｅｑｕｅｎｃｅＮｕｍｂｅｒ）の範囲が小さすぎる場合（すなわち、ＭＡＣヘッダ中のシーケンス番号フィールドが短すぎる場合）には、多くのＲＬＣＰＤＵが送信される際に、ＴＳＮがラップアラウンドし、したがって受信を行うＭＡＣエンティティがＲＬＣＰＤＵの正しい順序を再構成できない事態が生じ得る。一方、シグナリングすることのできるＴＳＮの範囲が大きすぎる場合には、必要な分よりも多くのビットが使用され、このことが、シグナリングのオーバーヘッド量を増大させ、したがって全体的なデータ送信の効率を低下させてしまう。同様に、セグメント化ビットの数が少なすぎる場合には、大きなパケットに対し、ＲＬＣＰＤＵを分割することのできるセグメント数が限定されすぎることとなるかもしれないし、一方でセグメント化ビットの数が多いと、セグメント化されない小さなＲＬＣＰＤＵに対し、ＭＡＣヘッダのオーバーヘッドが不必要に増大させられてしまうかもしれない。したがって、本発明の１つの目的は、ＭＡＣヘッダのオーバーヘッドを低減しながら、依然としてフレキシブルなセグメント化およびシーケンスの番号付けを提供することである。

本発明は、ＲＬＣＰＤＵが大きいときは、典型的には、より多くのセグメント化を伴うより小さなＴＳＮ範囲が必要とされ、一方、小さなＲＬＣＰＤＵは、典型的には、大きなＴＳＮ範囲を必要とし、かつセグメント化をほとんどもしくは全く必要としないという事実に基づいたものである。

図３は、本発明に従うＭＡＣヘッダ構造を示している。

リリース６のフィールドＮ（連続するＭＡＤ−ｄＰＤＵの数を表す）に代えて、長さインジケータＬＩ（ＬｅｎｇｔｈＩｎｄｉｃａｔｏｒ）が用いられる。この長さインジケータは、たとえばバイト整列の態様で作用し、ＭＡＣ−ｈｓのセグメント化において、バイト単位の精度を可能とする。長さインジケータは、（セグメント化が、等しいサイズのセグメントに分割するものとして予め決められている場合には、）ＲＬＣＰＤＵ全体の長さを示すものであってもよいし、現在のＭＡＣＰＤＵに含まれているＲＬＣＰＤＵのセグメントの長さを示すものであってもよい。加えて、一例として２ビットから構成されているセグメント化フィールドが示されている。このセグメント化フィールドは、リリース６のＲＬＣと同じように、ＭＡＣ−ｈｓＳＤＵの「最初のセグメント」、「第１の中間セグメント」、「第２の中間セグメント」および「最後のセグメント」という、最大４つのセグメントを示すことができる。あるいは、セグメント化が、ＲＬＣＰＤＵを３つのみのセグメントにサブ分割するものとして予め決められている場合には、上記の利用可能な４つの値のうち、３つのみが使用されてもよい。

図３の下半分には、ＭＡＣレイヤーに追加の２ビットのフォーマット（ＦＭＴ）フィールドが追加された様子が示されている。このフォーマットは、ＴＳＮおよびセグメント化の指標の、４とおりの可能な組合せを指示するために使用される。上記の例では、以下の４つのケースが示されている。
− フォーマット０（たとえば００）は、セグメント化が実行されず、したがって小さなＲＬＣＰＤＵが想定されるケースに対する、５ビットのＴＳＮに対応する。したがって、ウインドウのラップアラウンドを回避するように、ＴＳＮのシグナリングに最大数のビットが必要とされる。
− フォーマット１（たとえば０１）は、ＲＬＣＰＤＵのセグメント化のシグナリングに、２ビットが割り当てられるフォーマットである。この場合、ＲＬＣＰＤＵはより大きいと想定されるので、ＴＳＮのために必要とされるシグナリングの量はより小さくされる。
− フォーマット２（たとえば１０）は、より多くのセグメント化がシグナリングされ、したがってＲＬＣＰＤＵ送信シーケンス番号の範囲が、フォーマット１よりもさらに小さくされたフォーマットを示している。
− フォーマット３（たとえば１１）は、シーケンス番号が規定されず、残りのビットすべてがセグメント化指標に利用される、極端なケースを示している。しかしながらこのケースでは、典型的には、ＭＡＣヘッダも短くして、全体的なシグナリングの負荷を軽減すると、さらに効率的である。このフォーマットは、再順序付けを必要としない特定のデータフロー、たとえば極度に遅延に敏感なトラフィックに適しているかもしれない。

ＦＭＴフィールドを利用するのに代えて、ＲＲＣシグナリングによってＭＡＣヘッダのフォーマットを有利に構成することも可能である。これにより、ＦＭＴフィールドを追加することによる、ＭＡＣヘッダのオーバーヘッドの増大が回避される。より具体的にいうと、ＲＲＣシグナリングの代替形態は、半静的な方法でフォーマットを予め規定する点にある。たとえば、ＵＥとネットワークとの間で最初の接続が確立される際の手続きは、ユーザープレーンまたは制御プレーン内でデータを送信するための、無線ベアラのセットアップを必然的に伴う。この無線ベアラがセットアップされると、その無線ベアラ内で搬送されるデータに対するＭＡＣヘッダのフォーマットも、同時にセットアップされる。その後、このヘッダフォーマットが、その無線ベアラの寿命の持続時間に亘って、典型的にはその無線ベアラが使用されている限りにおいて利用される。

ＦＭＴフィールドの利用とＲＲＣシグナリングの利用との何らかの組合せであって、ＲＲＣシグナリングがフォーマットの範囲を指示し、フォーマットインジケータがその特定された範囲のサブ範囲を指示するような組合せを、用いることも可能かもしれない。

本発明の１つの実施形態によれば、ＲＬＣＰＤＵのサイズと、必要とされるセグメント化の量ＳＥＧと間の、依存関係が利用される。ＲＬＣＰＤＵが多くの部分にセグメント化される場合には、典型的にはより大きなＲＬＣＰＤＵが使用されており、可能性のある長さの範囲をシグナリングするのにより多くのビットが必要とされる。一方、より少ないセグメント化が行われる場合には、典型的にはＲＬＣＰＤＵはより小さく、シグナリングが必要とされる長さ範囲はより小さい。要約すると、
− 大きなＲＬＣＰＤＵ → 大きなＬＩ、大きなＳＥＧ
− 小さなＲＬＣＰＤＵ → 小さなＬＩ、小さなＳＥＧ
となる。

したがって、ＳＥＧフィールドの長さを、ＬＩフィールドの長さから独立に設定することは必要でないかもしれず、一方の長さを、他方の長さから推測される長さとしてもよい。

この実施形態の１つの拡張形態では、図４の例に示されるように、論理チャネルＩＤ（ＬｏｇｉｃａｌＣｈａｎｎｅｌＩＤ；ＬＣｉｄ）を用いて、ＬＩのサイズが指示される。たとえば、あるＬＣｉｄの範囲が規定され、その範囲の一部が、より小さなサイズのＬＩが使用されることを示すようになしてもよい。ここで、より小さなサイズのＬＩは、典型的には、より小さなＰＤＵが送信される際に使用される。要約すると、
− 大きなＲＬＣＰＤＵ → ＬＣｉｄの第１の組を使用 → 大きなＬＩ、大きなＳＥＧ
− 小さなＲＬＣＰＤＵ → ＬＣｉｄの第２の組を使用 → 小さなＬＩ、小さなＳＥＧ
となる。

図４に示した例では、３２個の論理チャネルの範囲をシグナリングできるように、５ビットが論理チャネルＩＤに使用されている。たとえばこれら３２個の論理チャネルのうちいくつかが、典型的にはより小さなＰＤＵしか担持していないものである場合には、そのＰＤＵの長さに必要なシグナリングの量は典型的にはずっと小さく、したがって長さを指示するのに用いられるフィールド（ＬＩフィールド）のサイズも、同様にずっと小さくなる。図示されている例では、ＬＣｉｄの別の範囲３が利用される場合には、セグメント化の指標を伴わずに、長さインジケータのみが送信され得る。

別の実施形態では、ＬＩフィールドの長さが、ＳＥＧフィールドの判読を決定することができる。たとえば、１つのＭＡＣ−ｈｓＰＤＵに入りきらない可能性のある大きなＰＤＵに対しては、セグメント化が必要な可能性がより高い。より小さなＲＬＣＰＤＵに対しては、一般的に、セグメント化が必要な可能性はより低い。しかしながら、小さな複数のＲＬＣが１つのＭＡＣ−ｈｓＰＤＵ内に組み合わされているときには、これらのＲＬＣＰＤＵのうち１つより多くのＲＬＣＰＤＵに対して、同一のＭＡＣ−ｈｓＰＤＵで送信されるべく利用可能なスペースがあるかもしれない。その場合、ＭＡＣ−ｈｓＰＤＵ内に連結されて含まれている、同一のＬＣｉｄを有する連続したＲＬＣＰＤＵの数を示す指標として、ＳＥＧフィールドを再利用することができる。このケースの例として、図５は、セグメント化フィールドの利用形態の、２つの可能なケースを示している。第１の例では、ＲＬＣＰＤＵが、ＭＡＣ−ｈｓＰＤＵ１とＭＡＣ−ｈｓＰＤＵ２とにセグメント化され、ＳＥＧフィールドが、セグメント識別子として働く。一方、第２の例では、より小さな３つのＲＬＣＰＤＵ（１、２、３と番号付けされている）が、１つのＭＡＣ−ｈｓＰＤＵ内に連結されて含まれている。第２の例では、ＳＥＧフィールドは、もはやセグメント化の指標ではなく、（どちらかというと多重化識別子のように、）そのＭＡＣ−ｈｓＰＤＵ内に含まれているＲＬＣＰＤＵの厳密な数を示すために用いられるものとなっている。これを要約すると、
− ＬＩの長さ（または所与のＬＩの長さを示すＬＣｉｄ）＞閾値である場合には、ＳＥＧ＝セグメント化の指標
− ＬＩの長さ（または所与のＬＩの長さを示すＬＣｉｄ）＜閾値である場合には、ＳＥＧ＝連続して連結されているＲＬＣＰＤＵの数の指標
となる。ここで、閾値は予め規定されたＬＩの尺度であり、この閾値を超えると、ＲＬＣＰＤＵのサイズは、一般的に連結よりもむしろセグメント化が必要とされる程度に十分に大きい、ということになる。

図６は、本発明の実施形態の別の側面を示しており、この側面によれば、追加の２ビットのフォーマット（ＦＭＴ）フィールドが、長さおよびセグメント化の指標の４つの可能な組合せを示すものとして、ＭＡＣヘッダ内に導入される。上記の例では、以下の４つのケースが規定されている。
フォーマット０：最大３ビット分のセグメント化が実行されるケースに対し、１０ビットのＬＩが存在する。したがって、可能性のあるＲＬＣＰＤＵのサイズ範囲として、広範な範囲が可能であり、長さの指標および可能性のあるＭＡＣセグメント化をシグナリングするのに、最大限のビットの数が必要とされる。
フォーマット１では、ＭＡＣレベルのセグメント化をシグナリングするのに、２ビットが割り当てられている。このケースでは、長さの指標に必要とされるシグナリング量は、より少ない（９ビット）。
フォーマット２は、何らセグメント化がシグナリングされない状態を示しており、したがって、シグナリングが必要とされるＲＬＣＰＤＵサイズの長さの範囲は、さらに小さい（５ビット）。
フォーマット３は、全体で１種類のみのＲＬＣＰＤＵの長さが規定されており、長さまたはセグメント化の指標に使われるビットがない、極端なケースを示している。このケースでは、ＭＡＣヘッダのサイズは低減させられ、したがって全体的なシグナリング負荷も低減される。このフォーマットは、常に固定された長さの送信パケットサイズを有し、セグメント化が必要とされないような特定のデータフローに適し得る。

あるいは、前述したように、ＦＭＴフィールドを利用するのではなく、ＲＲＣシグナリングによってＭＡＣヘッダのフォーマットを設定してもよい。

また、上記で既に説明した実施形態に対する１つの代替実施形態として、ＭＡＣヘッダ内において何らセグメント化フィールドが規定されず、ＬＩフィールドのサイズのみが変化するケースもある点に留意されたい。

以下の要素のうちの１つまたは複数が、新規な最適化されたＭＡＣヘッダのフォーマットの選択肢を決定し得る。
− 送信される最大のＲＬＣＰＤＵのサイズ
− 無線ベアラのセットアップ時において論理チャネルが規定される際にＲＲＣによって設定され得る、送信されるべき論理チャネル
− 利用可能なトランスポートブロックサイズ（これが小さい場合、ＲＬＣＰＤＵを効率的に送信するため、より多くのセグメント化を実行することが必要とされ得る）

上記の説明は「ダウンリンク」（すなわち基地局から移動局への送信）に関連した説明であったが、本発明は、アップリンク（すなわち移動局から基地局への送信）にも同様に適用可能である点に留意されたい。

上記で述べた実施形態は、本発明を限定するものではなく説明するためのものであり、当業者においては、特許請求の範囲において規定される本発明の技術的範囲から逸脱することなく、多くの変更実施形態を設計することが可能である点に留意されたい。たとえば、本発明の１つの実施形態は、無線通信システム内において一次局から二次局にデータ信号を送信する方法であって、上記のデータ信号が、ヘッダと、少なくとも１つのプロトコルデータユニットおよび／または１つのプロトコルデータユニットの少なくとも１つの部分とを含む、データパケットを含むものであり、上記のヘッダが、パラメータの組を含むものであり、当該方法が、上記の組に含まれる少なくとも１つのパラメータを送信するためのフィールドに割り当てられるサイズを、少なくとも１つの他のフィールドのサイズおよび／または上記のパラメータのうちの少なくとも１つの値に基づいて、決定する工程を含んでいる方法に関するものである。上記のパラメータの組は、送信シーケンス番号フィールド、セグメント化指示フィールド、長さ指示フィールドおよび論理チャネルＩＤフィールドのうちの、１つまたは複数を含む。

特許請求の範囲においては、括弧内に配されたいずれの参照符号も、特許請求の範囲を限定するものと捉えられるべきではない。「含む」および「備える」等の語は、いずれの請求項または明細書全体においても、列挙されたもの以外の他の要素または工程の存在を排除するものではない。ある要素を単数のものとして言及することは、かかる要素が複数存在することを排除するものではなく、またその逆もいえる。

本発明は、いくつかの別個の要素を含むハードウェアによって実装されてもよいし、適切にプログラミングされたコンピュータによって実装されてもよい。いくつかの手段を列挙した装置のクレームでは、それらの手段のうちのいくつかが、１つの同一のハードウェア要素によって実現されてもよい。単に特定の施策が互いに異なる従属請求項に記載されていることは、それらの施策の組合せは有利に用いることができないということを示すものではない。

Claims

無線通信システム内において一次局から二次局にデータ信号を送信する方法であって、前記データ信号が、ヘッダと、該ヘッダと組み合わされたプロトコルデータユニットとを含むものであり、前記ヘッダが、前記プロトコルデータユニットが何個のセグメントにサブ分割されるかを示すセグメント化指示フィールド、及び、前記プロトコルデータユニットを再順序付けするために用いられる送信シーケンス番号フィールドの組を含むものであり、当該方法が、少なくとも１つの前記フィールドに割り当てられるサイズを、前記プロトコルデータユニットの長さに基づいて決定する工程を含むことを特徴とし、前記プロトコルデータユニットの第１の長さに対して決定される、セグメント化指示フィールドに割り当てられるサイズが、前記第１の長さよりも長い前記プロトコルデータユニットの第２の長さに対して決定されるサイズよりも小さく、前記プロトコルデータユニットの第１の長さに対して決定される、送信シーケンス番号フィールドに割り当てられるサイズが、前記第１の長さよりも長い前記プロトコルデータユニットの第２の長さに対して決定されるサイズよりも大きい、方法。
前記プロトコルデータユニットの前記長さに基づいて、フォーマットフィールドの値が決定され、該フォーマットフィールドの値は、前記組に含まれる少なくとも１つのフィールドに割り当てられる前記サイズを示すものであることを特徴とする請求項１記載の方法。
前記プロトコルデータユニットの第１の長さに対して決定される、長さ指示フィールドに割り当てられるサイズが、前記第１の長さよりも長い前記プロトコルデータユニットの第２の長さに対して決定されるサイズよりも小さく、前記長さ指示フィールドは、前記プロトコルデータユニットの長さを示すものであることを特徴とする請求項１記載の方法。
前記長さ指示フィールドに割り当てられる前記サイズを示すために、論理チャネル識別子フィールドが使用されることを特徴とする請求項３記載の方法。
前記無線通信システムが、ユニバーサル・モバイル・テレコミュニケーション・システムであることを特徴とする請求項１記載の方法。
二次局にデータ信号を送信する一次局であって、当該一次局および前記二次局は無線通信システムの一部をなし、前記データ信号が、ヘッダと、該ヘッダと組み合わされたプロトコルデータユニットとを含むものであり、前記ヘッダが、前記プロトコルデータユニットが何個のセグメントにサブ分割されるかを示すセグメント化指示フィールド、及び、前記プロトコルデータユニットを再順序付けするために用いられる送信シーケンス番号フィールドの組を含むものであり、当該一次局が、前記組に含まれる少なくとも１つのフィールドに割り当てられるサイズを、前記プロトコルデータユニットの長さに基づいて決定する手段を含むことを特徴とし、前記プロトコルデータユニットの第１の長さに対して決定される、セグメント化指示フィールドに割り当てられるサイズが、前記第１の長さよりも長い前記プロトコルデータユニットの第２の長さに対して決定されるサイズよりも小さく、前記プロトコルデータユニットの第１の長さに対して決定される、送信シーケンス番号フィールドに割り当てられるサイズが、前記第１の長さよりも長い前記プロトコルデータユニットの第２の長さに対して決定されるサイズよりも大きい、一次局。
携帯電話であることを特徴とする請求項６記載の一次局。
一次局の内部メモリに直接ローディング可能なコンピュータプログラムであって、当該コンピュータプログラムが、前記一次局が有するコンピュータ上で実行された際に、請求項１記載の方法のすべての工程を前記コンピュータに実行させるためのソフトウェアコード部分を含むことを特徴とするコンピュータプログラム。