(57)【特許請求の範囲】
【請求項１】
受信方法であって、
複数のサービスデータユニット（ＳＤＵ）、複数のセグメントされたサービスデータユニット、または少なくとも１つのサービスデータユニットと少なくとも１つのセグメントされたサービスデータユニットを含むデータパケットペイロードと、
インディケータを含むデータパケットヘッダと、
を含むデータパケットを受信するステップを含み、
前記インディケータは、前記データパケットペイロードが前記セグメントされたサービスデータユニットで始まっているか否かと、前記データパケットペイロードが前記セグメントされたサービスデータユニットで終わっているか否か、を示し、
前記インディケータの情報に基づいて、受信した前記サービスデータユニットを再構成するステップ、
を含む受信方法。
【請求項２】
データパケットを受信する装置であって、
複数のサービスデータユニット（ＳＤＵ）、複数のセグメントされたサービスデータユニット、または少なくとも１つのサービスデータユニットと少なくとも１つのセグメントされたサービスデータユニットを含むデータパケットペイロードと、
インディケータを含むデータパケットヘッダと、
を含むデータパケットを受信する受信部を含み、
前記インディケータは、前記データパケットペイロードが前記セグメントされたサービスデータユニットで始まっているか否かと、前記データパケットペイロードが前記セグメントされたサービスデータユニットで終わっているか否かと、を示し、
前記インディケータの情報に基づいて、受信した前記サービスデータユニットを再構成する手段、
を含む装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明の分野は、通信システム（無線ネットワークまたは固定ネットワークのいずれかとすることができる）における上位層のパケットから下位層のフレームへのマッピングである。上位層によって渡されるパケットを物理ネットワークの能力（例えば最大フレームサイズ）に適合させる目的で、場合によっては、これらのパケットを、個別のフレームによって送信されるいくつかのブロックに分割またはフラグメント化する必要がある。同様に、送信効率を高める目的で、いくつかのパケットを１つのフレームに連結する必要が生じることもある。本発明は、送信機側において分割および連結がどのように行われたかを受信ユニットが受信する新しい効率的な方法を提案する。
【背景技術】
【０００２】
上位層のパケットを物理ネットワークの特性に適合させる必要があることは、あらゆるタイプの通信システム、例えば、無線ネットワーク（ＧＳＭ（登録商標）、ＵＭＴＳ、ＷｉＬＡＮ、ＷｉＭａｘなど）、あるいは固定ネットワーク（ＩＰ、フレームリレー、ＰＰＰ、ＡＴＭなど）において、古典的な問題である。
【０００３】
ＯＳＩ層の概要
このセクションでは、以降の説明を進めるうえで使用しているＯＳＩモデル（図１を参照）について簡潔に紹介する。
【０００４】
開放型システム間相互接続参照モデル（略してＯＳＩモデルまたはＯＳＩ参照モデル）は、通信およびコンピュータネットワークのプロトコルの設計に関する階層的な抽象記述（layered abstract description）である。ＯＳＩモデルでは、システムの機能を一連の層（レイヤ）に分割する。各層は、その性質として、自身より下位の層の機能を使用するだけであり、自身の機能を自身より上位の層にエクスポートするだけである。一連のこれらの層から構成されているプロトコル動作を実施するシステムは、「プロトコルスタック」または「スタック」として知られている。その主たる機能は、層と層を結合することであり、１つの層と別の層との間の相互作用の仕様を決めている。このことは、原理的には、ある製造者によって書かれた層と、別の製造者の層とが共に動作できることを意味する。本明細書では、最初の３つの層のみについて説明する。
【０００５】
物理層、すなわち第１層の主たる目的は、特定の物理媒体（例えば、同軸ケーブル、ツイストペア、光ファイバ、無線）を通じて情報（ビット）を伝送することである。この層は、データを、通信チャネルを通じて送信される信号に変換または変調する。
【０００６】
データリンク層、すなわち第２層の目的は、入力データをデータフレームに分割することによって、特定の物理層と両立する方式で情報フローを形成することである（分割および再構築（Segmentation And Re-assembly）機能、すなわちＳＡＲ機能）。さらに、この層では、消失フレームの再送を要求することによって、発生しうる送信エラーを検出・訂正することができる。この層は、アドレッシングメカニズムを提供し、データレートを受信機の能力に合わせる目的でフロー制御アルゴリズムを提供することができる。さらには、共有されている媒体が複数の送信機および受信機によって同時に使用されているとき、この層は、その物理媒体へのアクセスを調整および制御するメカニズムを提供する。データリンク層は、その機能の範囲が広いため、２つのサブレイヤに分割されることがしばしばある（例えばＵＭＴＳにおけるＲＬＣサブレイヤとＭＡＣサブレイヤ）。第２層プロトコルの代表的な例としては、固定ネットワーク用のＰＰＰ／ＨＤＬＣ、ＡＴＭ、フレームリレー、無線システム用のＲＬＣ、ＬＬＣ、ＭＡＣが挙げられる。
【０００７】
ネットワーク層、すなわち第３層は、トランスポート層によって要求されるサービス品質を維持しながら、送信元から１つ以上のネットワークを介して送信先まで可変長パケットを伝送する機能および手順に関する手段を提供する。ネットワーク層の主たる目的は、ネットワークルーティング機能と、ネットワークのフラグメント化機能と、輻輳制御機能とを実行することである。ネットワーク層プロトコルの主な例は、ＩＰインターネットプロトコルまたはＸ．２５である。
【０００８】
ＯＳＩ層モデルに関するさらなる説明は、非特許文献１に記載されている。
【０００９】
ＳＤＵおよびＰＤＵの定義
ＯＳＩモデルにおける層間でのパケット交換を包括的かつ公式に記述する目的で、ＳＤＵ（サービスデータユニット）エンティティと、ＰＤＵ（プロトコルデータユニット）エンティティとが定義されている。ＳＤＵは、第Ｎ層に位置しているプロトコルにＳＡＰ（サービスアクセスポイント）を介してのサービスを要求する、第Ｎ＋１層におけるプロトコルから送信される情報の単位である。ＰＤＵは、送信機および受信機において同じ第Ｎ層に位置する同じプロトコルのピアプロセス間で交換される情報の単位である。ＰＤＵは、一般的には、受信したＳＤＵの処理後のバージョンから構成されるペイロード部分と、制御情報（例えば、第Ｎ層に固有のヘッダ）と、場合によっては最後のトレイラとによって形成されている。これらのピアプロセスの間には、（第１層を除いて）直接的な物理接続が存在しないため、ＰＤＵを第Ｎ−１層に転送して処理する。従って、第Ｎ層のＰＤＵは、第Ｎ−１層にとってのＳＤＵである。図２はこの状況を示している。
【００１０】
フラグメント化／分割の目的
フラグメント化（同義には分割）が必要となることがある理由として、以下の３つが挙げられる。
第一に、データグラムまたはパケットを、それらのサイズよりもデータグラムの最大許容サイズまたは最大転送単位（ＭＴＵ）が小さいネットワークを通じて伝送するために、フラグメント化が必要となることがある。データグラムのフラグメント化は、一般にＩＰ層において実装され、標準規格のＩＰｖ４またはＩＰｖ６バージョンにおいては、ＩＰフラグメンテーションとして規定されている。同様に、ＡＴＭネットワークを通じてデータを伝送するとき、４８オクテットのペイロードサイズをＡＴＭセルに収める目的で、フラグメント化が必要である。このフラグメント化は、ＡＴＭの第２層とトランスポート層（例えばＩＰ）の間のＡＴＭ適合層（ＡＡＬ）において実行される。
【００１１】
第二に、並列リンク（例えば並列ＩＳＤＮリンク）におけるトラフィック負荷をバランシングする目的で、フラグメント化を行うことができる。ＰＰＰをベースとするＰＰＰマルチリンクプロトコル（ＭＰ）（「The PPP Multilink Protocol (MP)」（非特許文献２）には、複数の論理データリンクにわたってデータグラムを分割、再結合、および並べ替える方法が記述されている。
【００１２】
第三に、無線システムにおいては、上位層のパケットを、下位層によって提供されるリソースに適合させる目的で、パケット分割を、場合によっては連結と組み合わせて第２層において実行することがしばしばある（例えば、ＵＭＴＳにおけるＲＬＣサブレイヤ（非特許文献３）。無線環境においては一般にリソースが十分ではないため、全体的なシステム効率を高める目的で、いくつかの上位層パケットを連結することが推奨されている。
【００１３】
受信機ユニットが、連結されているフラグメントを分離して、受信したフラグメントを元のパケットに正しく再結合するためには、分割情報を受信ユニットに供給する必要がある。この情報（通常では、各フラグメントにタグを付けるナンバリング（numbering）手法と組み合わされる）により、受信機における第２層は、完全かつ整合性のあるパケットを次の上位層に渡すことができる。
【００１４】
以下のセクションでは、分割をシグナリングするためのいくつかの既存の方法について説明する。これらは本発明との違いを理解するうえで役立つであろう。
【００１５】
フラグメントナンバリング（fragment numbering）によるＳＡＲのシグナリング
フラグメント化を伝えるための第一のタイプの方法として、ソースパケットの中でのフラグメントのポジションを示すいくつかの類似する手法が挙げられる。２つの要素が必要である。第１の要素は、ソースパケットの中でのフラグメントのポジションを指すインデックスである。このインデックスは、フラグメンテーションオフセット（ＩＰフラグメンテーション（非特許文献１を参照）、またはこれと同等であるフラグメントシーケンス番号ＦＳＮ（非特許文献４を参照）のいずれかの形式をとることができる。
【００１６】
このインデックスは、ソースパケットの最初のフラグメントに対して、既知の値（例えばＦＳＮ＝０）に初期化しなければならない。受信機ユニットは、このインデックスを使用してフラグメントを正しい順序に並べ替え、消失したフラグメントを検出する。さらに、パケットの最後のフラグメントが、１ビットフラグ（ＬＦ）によって示される。フラグメント化されていないパケットは、インデックスを先頭ポジション（例えばＦＳＮ＝０）に設定すると同時に、そのパケットがソースパケット内の最後のフラグメントであることを示すことによって、受信機側にシグナリングされる。この手法は、例えば、ＩＰフラグメンテーションプロトコル、あるいはＡＴＭ適合層ＡＡＬ−１において使用されている。８０２．１１  ＷｉＬＡＮ  ＭＡＣ層でも同じ手法を使用する。ＷｉＬＡＮでは、さらに、ソースパケットを識別するフィールドを各フラグメントに付加する。このフィールドが必要である理由として、８０２．１１  ＭＡＣでは、受信機側において次の上位層に渡す前にパケットを並べ替えるように構成されることがあるためである。ＩＰ層では、このように正しい順序で渡すことは要求されない。なぜなら、並べ替えが必要ないか、または並べ替えが上位層（例えばＴＣＰ）によって実行されるためである。
【００１７】
図３は、ＷｉＬＡＮにおけるフラグメントナンバリングによるＳＡＲ手法の原理を示している。
【００１８】
シグナリングのオーバーヘッドは比較的大きく、なぜなら、各フラグメントが、最終フラグメントフラグＬＦと、フラグメントシーケンス番号ＦＳＮと、場合によってはソースパケットのシーケンス番号ＳＮとを少なくとも運ばなくてはならないためである。
【００１９】
先頭フラグ／終端フラグによるＳＡＲシグナリング
２番目のタイプのＳＡＲ方法は、さまざまなプロトコル、例えば、ＡＴＭ適合層ＡＡＬ−３／４、フレームリレー（非特許文献５）、ＷｉＭａｘ、ＰＰＰマルチリンク（ＭＰ）（非特許文献２）などにおいて、広く使用されている。この２番目のタイプのＳＡＲ手法の中心的な発想は、各ＳＡＲ  ＰＤＵについて、そのＰＤＵがＳＤＵの最初、最後、またはこれらの間のフラグメントであるか、あるいはそのＰＤＵが完全なＳＡＲ  ＳＤＵであるかを、２つの１ビットフラグを使用して示すことである。いずれのフラグもＰＤＵヘッダの一部である。いくつかの実施形態（フレームリレー、ＰＰＰマルチリンク）においては、２つのフラグの機能は、一方のフラグがＳＤＵの先頭を示し、他方のフラグがＳＤＵの最後を示すものとして区別される。先頭フラグメントビットＢは、ＳＡＲ  ＳＤＵから導かれる最初のフラグメントに対して１に設定され、同じＳＤＵからの他のすべてのフラグメントに対して０に設定される。終端フラグメントビットＥは、最後のフラグメントに対して１に設定され、それ以外のすべてのフラグメントに対して０に設定される。ＰＤＵの先頭フラグメントビットおよび終端フラグメントビットの両方を１に設定することができる。この場合、分割が行われていないことを示している。さらには、リンクにおいてＰＤＵの順序が維持されない場合に、受信機ユニットがフラグメントの消失を検出し、場合によってはＰＤＵの並べ替えを実行する目的で、フラグメントシーケンスナンバリングが加えられている。並べ替えの後、受信機は、ＢビットおよびＥビットを調べることにより、元のＳＤＵを再構築するのにどのＳＡＲ  ＰＤＵを結合する必要があるかを容易に識別することができる。図４は、この手法を説明している。
【００２０】
長さインディケータによるＳＡＲシグナリング
３番目のタイプは、ＳＤＵの境界を示すためのポインタとして長さインディケータフィールドを使用する一連の手法から構成される。代表的な例は、ＵＭＴＳ  Ｒ９９におけるＲＬＣ（Radio Link Control）である。ＲＬＣにおいては、ＲＬＣ  ＰＤＵは、いくつかのＳＤＵの断片またはパディングビットを運ぶことができる。実際には、ＵＭＴＳ  Ｒ９９は固定サイズのＰＤＵにおいて動作し、ＰＤＵのサイズと、送信するＳＤＵの長さとが合わないことがある。無線リソースは十分ではないため、ＰＤＵレベルにおいてＳＤＵを連結できることが必要であると考えられた。一般的な方法においては、ＰＤＵヘッダに可変数の長さインディケータ（ＬＩ）を追加する。長さインディケータは、末端がＰＤＵの中にある各ＲＬＣ  ＳＤＵの最後のオクテットを示すために使用される。他の方法と同様に、消失の検出および並べ替えを行うことができるように、ＰＤＵに基づくシーケンスナンバリングがヘッダに追加されている。従って、受信機は、並べ替えを実行し、消失ＰＤＵの再送を要求し、ＳＤＵを再構築することができる。さらに、特殊な値のＬＩは、ＰＤＵの最後を埋めるためにパディングが使用されていることを示す。
【００２１】
この手法の主たる欠点は、オーバーヘッドがＰＤＵの中のＳＤＵ断片の数に依存することと、このためヘッダのサイズも変化することである。さらに、特殊フィールドを使用することにより、ＲＬＣの複雑さも増す傾向にある。
【００２２】
最後に、ＰＤＵのサイズが可変である場合を考えると、この手法はさほど効率的ではなく、ＰＤＵサイズが可変であれば、よりフレキシブルであり、無線システムにおける完全なパケットをベースとする環境に良好に適合させることができる。図５は、この手法の一般的な例を示している。
【００２３】
無線システムにおける連結機能
連結は、無線システムの場合に特に有用な機能である。分割と連結とを組み合わせることによって、送信機は、入力される可変長のＳＤＵを、提供されるリソースに良好に適合させることができる。無線システムの場合、送信時間間隔（ＴＴＩ）の間に送信できるビットの数は、無線状態、コードレート、送信に割り当てられる物理リソースに依存して大幅に変化しうる。例えば、送信機に近い移動局では、送信機から離れている移動局よりも必要なチャネル符号化が少ない。割り当てられている物理リソースと送信出力とが同じである場合、前者の移動局は、後者の移動局よりも多くのデータを受信することができる。さらに、パケットサービスを考えるとき、サーバによって提供されるデータレートは、原理的には時間とともに大きく変化する。
【００２４】
ＵＭＴＳにおいては、ＳＤＵの分割と、ＳＤＵの断片からＰＤＵへの連結は、提供される物理リソースには関係なく、所定の決まったＰＤＵサイズで、ＲＬＣレベルにおいて実行される。ＭＡＣ層では、何らかの動的挙動をエミュレートする目的で、物理層からの何らかの情報に基づいて、ＴＴＩあたり送信するＰＤＵの数を決定する。ＵＭＴＳ  Ｒ９９においては、選択されたＰＤＵを、いわゆるトランスポートチャネルブロック（ＴｒＣＨ  ＢｌｋまたはＴｒＢｌｋ）の形式で物理層に渡し、物理層は、これらのブロックを連結してトランスポートチャネルブロックセットを形成する。ＵＭＴＳ  Ｒｅｌ−５  ＨＳＤＰＡにおいては、選択されたＰＤＵを、ＭＡＣ層において直接連結してトランスポートチャネルブロック（ＴｒＣＨ  ＢｌｋまたはＴｒＢｌｋ）とし、従って、このブロックは、図７に示したようにいくつかのＰＤＵを含んでいる。ＴＴＩあたり選択されるＰＤＵの数は、図７に示したように、無線状態あるいはその他の変数に依存して変化する。従って、ＲＬＣ層におけるＳＤＵの分割および連結と、ＭＡＣ層（ＵＭＴＳ  Ｒｅｌ−５  ＨＳＤＰＡ）または物理層（ＵＭＴＳ  Ｒ９９）におけるＰＤＵの連結を連続的に使用することにより、送信機は、瞬間的に変動するもの（上位層から入力されるデータ、下位層によって提供されるリソース）に対して、送信を動的に適合させることができる。
【００２５】
ＵＭＴＳにおいては、ＴＴＩあたり送信されるＰＤＵの数は、帯域外シグナリング（トランスポートフォーマット組合せインディケータ（Transport Format Combination Indicator:TFCI））または特定のヘッダ（例えばＨＳＤＰＡにおけるＭＡＣ−ｈｓヘッダ）における帯域内シグナリングのいずれかによって、受信機ユニットに通知される。なお、ＰＤＵの連結ステップは、一般的にはＰＤＵの構造とは無関係に実行され、従って、ＳＤＵがいくつかのＴＴＩにまたがることもある。
【００２６】
データレートが大きく変動するシステムにおける効率的なオーバーヘッド
上述したようにＳＤＵの分割とＰＤＵの連結を連続的に使用することは、送信されるＰＤＵの数の範囲が大きすぎないときには良好に機能する。しかしながら、変動性の高いシステム（物理リソースの変動が大きく、データレートの変動が大きい）（今後の高帯域幅システムにおいてより一般的になりうる）の場合、固定サイズのＰＤＵを使用することが最適にならない傾向にある。なぜなら、ＰＤＵのサイズをデータレート範囲全体にわたり適合させることができないためである。実際に、パケットサービスの場合、ＳＤＵのサイズは、原理的には、ＴＣＰ  ＡＣＫの場合の４０オクテットから、ＭＴＵのサイズ（例えばイーサネット（登録商標）の場合の約１５００オクテット）まで変化しうる。物理層側においては、スケジューリング型の共有システム（例えばＵＭＴＳにおけるＨＳＤＰＡ）では、ＴＴＩあたり提供される物理リソースが、数ｋｂｐｓから全帯域幅（例えばＨＳＤＰＡにおける１４Ｍｂｐｓ）まで変化しうる。今後の無線システムにおいて、この傾向は変わらないものと予測される。
【００２７】
問題は、データレート範囲の下側において最適である小さなＰＤＵサイズが、データレート範囲の上側を考慮すると負荷が重くなることに起因する。実際に、受信機が処理するＴＴＩあたりのＰＤＵが増し、より多くの演算処理が要求される。さらに、ＰＤＵを識別するシーケンス番号の範囲が短すぎることになる可能性があり、ラップアラウンド問題が生じることがある。さらには、オーバーヘッド（ｎ＊ＰＤＵヘッダサイズに等しい）は、トランスポートチャネルブロックの長さとともにほぼ線形的に増大する。大きなＰＤＵを使用すると、送信機は、ＰＤＵをデータで満たすため、あるいはＰＤＵ内の未使用のスペースを低いデータレートで大量にパディングするために、送信を遅らせなければならない。大きなジッタや大量のパディングは、無線システムの効率に大きな悪影響を及ぼすため、回避すべきである。
【００２８】
ＰＤＵのサイズは、一般的には、対象のサービスの伝送に使用される無線ベアラの静的パラメータである。このパラメータは、大規模な再構成手順を行わないと変更することができない。従って、データレート、またはＴＴＩあたりの割当可能な物理リソースの範囲のいずれかを大きく制限しない限りは、入力されるＳＤＵの特性、または下位層によって提供されるリソースに、リンクを効率的に適合させることは難しい。
【００２９】
エラー伝搬
長さインディケータを使用してのＳＡＲシグナリング手法は、エラー伝搬の影響が大きい。実際に、ＰＤＵが消失すると、受信機は、正しく受信したＳＤＵを、ＳＤＵの境界が不確定であるために意図的にドロップせざるを得ないことがある。図８に示したように、ＰＤＵ  ｉ＋２が消失すると、受信機は、正しく受信したＰＤＵ  ｉ＋３をドロップさせなくてはならない。なぜなら、ＰＤＵ  ｉ＋３に含まれているフラグメントが完全なＳＤＵである（候補１）のか、ＳＤＵの断片である（候補２）のかを判定できないためである。
【００３０】
ＵＭＴＳ  Ｒｅｌ−６においては、ＳＤＵのサイズがＰＤＵのサイズに一致する特定の条件時にこの問題を限定してオーバーヘッドを低減させるいくつかの試みが行われている。しかしながら、一般的な場合、この問題は、各ＰＤＵが、自身の構造に関する情報を、隣接するＰＤＵの内部構造とは無関係に運ぶことに起因する。
【００３１】
先頭フラグ／終端フラグ、またはフラグメントナンバリングを使用してのＳＡＲシグナリング手法では、受信機は十分なＰＤＵを受信したことを正確に認識するため、このエラー伝搬に関して堅牢性が高い。しかしながら、これらの手法のオーバーヘッドは、連結されるＰＤＵの数とともに線形的に増大する。
【００３２】
上述したように、分割および連結をシグナリングするための手法はいくつか存在している。しかしながら、これらの手法は、大きなオーバーヘッド、あるいは柔軟性の欠如に起因する問題があったり、受信機側の複雑さが増大することがある。さらには、エラー伝搬に対する堅牢性もない。
【先行技術文献】
【非特許文献】
【００３３】
【非特許文献１】“Computer Networks”, (Andrew S. Tanenbaum, fourth edition, Prentice Hall International Edition, page 37-41, section 1.4.)
【非特許文献２】"The PPP Multilink Protocol (MP)", RFC 1990, Sklower, K., Lloyd, B., McGregor, G., Carr, D. and  T.Coradetti, August 1996
【非特許文献３】3GPP TS 25.322, v6.4.0, "Radio Link Control (RLC) protocol specification"
【非特許文献４】WiLAN, see 802.11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) specifications
【非特許文献５】Frame Relay Fragmentation Implementation Agreement FRF.12, Frame Relay Forum Technical Committee
【発明の概要】
【００３４】
本発明の目的は、パケット通信における効率的かつ実現可能な分割および連結を提供することである。
【００３５】
この目的は、独立請求項の主題によって解決されている。本発明の有利な実施形態は、従属請求項の主題である。
【００３６】
本発明は、受信方法であって、複数のサービスデータユニット（ＳＤＵ）、複数のセグメントされたサービスデータユニット、または少なくとも１つのサービスデータユニットと少なくとも１つのセグメントされたサービスデータユニットを含むデータパケットペイロードと、インディケータを含むデータパケットヘッダと、を含むデータパケットを受信するステップを含み、前記インディケータは、前記データパケットペイロードが前記セグメントされたサービスデータユニットで始まっているか否かと、前記データパケットペイロードが前記セグメントされたサービスデータユニットで終わっているか否か、を示し、前記インディケータの情報に基づいて、受信した前記サービスデータユニットを再構成するステップ、を含む受信方法である。
他の本発明は、データパケットを受信する装置であって、複数のサービスデータユニット（ＳＤＵ）、複数のセグメントされたサービスデータユニット、または少なくとも１つのサービスデータユニットと少なくとも１つのセグメントされたサービスデータユニットを含むデータパケットペイロードと、インディケータを含むデータパケットヘッダと、を含むデータパケットを受信する受信部を含み、前記インディケータは、前記データパケットペイロードが前記セグメントされたサービスデータユニットで始まっているか否かと、前記データパケットペイロードが前記セグメントされたサービスデータユニットで終わっているか否かと、を示し、前記インディケータの情報に基づいて、受信した前記サービスデータユニットを再構成する手段、を含む装置である。
他の本発明は、データパケットを受信する装置であって、複数のサービスデータユニット（ＳＤＵ）、複数のセグメントされたサービスデータユニット、または少なくとも１つのサービスデータユニットと少なくとも１つのセグメントされたサービスデータユニットを含むデータパケットペイロードと、インディケータを含むデータパケットヘッダと、を含むデータパケットを受信する受信部と、前記インディケータの情報に基づいて、受信した前記サービスデータユニットを再構成する手段と、を含む装置である。
本発明は、送信方法であって、複数のサービスデータユニット（ＳＤＵ）、複数のセグメントされたサービスデータユニット、または少なくとも１つのサービスデータユニットと少なくとも１つのセグメントされたサービスデータユニットをデータパケットのデータパケットペイロードに配置し、インディケータをデータパケットヘッダに配置するステップと、前記データパケットを送信するステップと、を含む、データパケット送信方法である。
他の本発明は、データパケットを送信する装置であって、複数のサービスデータユニット（ＳＤＵ）、複数のセグメントされたサービスデータユニット、または少なくとも１つのサービスデータユニットと少なくとも１つのセグメントされたサービスデータユニットをデータパケットペイロードに配置し、インディケータをデータパケットヘッダに配置する配置部と、前記データパケットを送信する送信部とを含む、装置である。
他の本発明は、受信方法であって、複数のサービスデータユニット（ＳＤＵ）、複数のセグメントされたサービスデータユニット、または少なくとも１つのサービスデータユニットと少なくとも１つのセグメントされたサービスデータユニットを含むデータパケットペイロードと、インディケータを含むデータパケットヘッダと、を含むデータパケットを受信するステップを含み、前記インディケータが、前記データパケットペイロードが前記セグメントされたサービスデータユニットで始まっているか否かと、前記データパケットペイロードが前記セグメントされたサービスデータユニットで終わっているか否かと、を示す、受信方法である。
他の本発明は、データパケットを受信する装置であって、複数のサービスデータユニット（ＳＤＵ）、複数のセグメントされたサービスデータユニット、または少なくとも１つのサービスデータユニットと少なくとも１つのセグメントされたサービスデータユニットを含むデータパケットペイロードと、インディケータを含むデータパケットヘッダと、を含むデータパケットを受信する受信部を含み、前記インディケータが、前記データパケットペイロードが前記セグメントされたサービスデータユニットで始まっているか否かと、前記データパケットペイロードが前記セグメントされたサービスデータユニットで終わっているか否かと、を示す、装置である。
他の本発明は、データパケットを送信する送信装置によって実行される方法であって、複数のサービスデータユニット（ＳＤＵ）、複数のセグメントされたサービスデータユニット、または少なくとも１つのサービスデータユニットと少なくとも１つのセグメントされたサービスデータユニットをデータパケットペイロードに配置するステップと、インディケータをデータパケットヘッダに配置するステップと、前記データパケットヘッダと前記データパケットペイロードを含むデータパケットを形成するステップと、前記送信装置が、前記データパケットを送信するステップと、を含み、前記インディケータは、前記データパケットペイロードが前記セグメントされたサービスデータユニットで始まっているか否かと、前記データパケットペイロードが前記セグメントされたサービスデータユニットで終わっているか否かと、を示すものである、データパケット送信方法である。
他の本発明は、前記インディケータは第１ビットと第２ビットを含み、前記第１ビットは前記データパケットペイロードが前記セグメントされたサービスデータユニットで始まっているか否かを示し、前記第２ビットは前記データパケットペイロードが前記セグメントされたサービスデータユニットで終わっているか否かを示す、データパケット送信方法である。
他の本発明は、前記データパケットペイロードが、前記データパケットペイロードの最初または最後に配置されるサービスデータユニットまたはセグメントされたサービスデータユニットの他に、少なくとも１つのサービスデータユニットを含む、データパケット送信方法である。
他の本発明は、データパケットを送信する装置であって、複数のサービスデータユニット（ＳＤＵ）、複数のセグメントされたサービスデータユニット、または少なくとも１つのサービスデータユニットと少なくとも１つのセグメントされたサービスデータユニットをデータパケットペイロードに配置するデータパケットペイロード配置部と、インディケータをデータパケットヘッダに配置するデータパケットヘッダ配置部と、前記データパケットヘッダと前記データパケットペイロードを含むデータパケットを形成するデータパケット形成部と、前記データパケットを送信する送信部とを含み、前記インディケータは、前記データパケットペイロードがセグメントされたサービスデータユニットで始まっているか否かと、前記データパケットペイロードがセグメントされたサービスデータユニットで終わっているか否かとを示す、装置である。
他の本発明は、前記インディケータは第１ビットと第２ビットを含み、前記第１ビットは前記データパケットペイロードが前記セグメントされたサービスデータユニットで始まっているか否かを示し、前記第２ビットは前記データパケットペイロードが前記セグメントされたサービスデータユニットで終わっているか否かを示す、装置である。
他の本発明は、前記データパケットペイロードが、前記データパケットペイロードの最初または最後に配置されるサービスデータユニットまたはセグメントされたサービスデータユニットの他に、少なくとも１つのサービスデータユニットを含む、装置である。
他の本発明は、データパケットヘッダとデータパケットペイロードを含むデータパケットを受信する受信装置によって実行される方法であって、前記受信装置が、複数のサービスデータユニット（ＳＤＵ）、複数のセグメントされたサービスデータユニット、または少なくとも１つのサービスデータユニットと少なくとも１つのセグメントされたサービスデータユニットを含むデータパケットペイロードと、インディケータを含むデータパケットヘッダと、を含むデータパケットを受信するステップと、前記データパケットペイロードが前記セグメントされたサービスデータユニットで始まっているか否かと、前記データパケットペイロードが前記セグメントされたサービスデータユニットで終わっているか否かと、を示す情報を前記インディケータから取得するステップと、を含む、データパケット受信方法である。
他の本発明は、前記インディケータは第１ビットと第２ビットを含み、前記第１ビットは前記データパケットペイロードが前記セグメントされたサービスデータユニットで始まっているか否かを示し、前記第２ビットは前記データパケットペイロードが前記セグメントされたサービスデータユニットで終わっているか否かを示す、データパケット受信方法である。
他の本発明は、前記データパケットペイロードが、前記データパケットペイロードの最初または最後に配置されるサービスデータユニットまたはセグメントされたサービスデータユニットの他に、少なくとも１つのサービスデータユニットを含む、データパケット受信方法である。
他の本発明は、データパケットヘッダとデータパケットペイロードを含むデータパケットを受信する装置であって、複数のサービスデータユニット（ＳＤＵ）、複数のセグメントされたサービスデータユニット、または少なくとも１つのサービスデータユニットと少なくとも１つのセグメントされたサービスデータユニットを含むデータパケットペイロードと、インディケータを含むデータパケットヘッダと、を含むデータパケットを受信する受信部と、前記データパケットペイロードが前記セグメントされたサービスデータユニットで始まっているか否かと、前記データパケットペイロードが前記セグメントされたサービスデータユニットで終わっているか否かと、を示す情報を前記インディケータから取得する取得部と、を含む、装置である。
他の本発明は、前記インディケータは第１ビットと第２ビットを含み、前記第１ビットは前記データパケットペイロードが前記セグメントされたサービスデータユニットで始まっているか否かを示し、前記第２ビットは前記データパケットペイロードが前記セグメントされたサービスデータユニットで終わっているか否かを示す、装置である。
他の本発明は、前記データパケットペイロードが、前記データパケットペイロードの最初または最後に配置されるサービスデータユニットまたはセグメントされたサービスデータユニットの他に、少なくとも１つのサービスデータユニットを含む、装置である。
本発明の複数の異なる実施形態は、プロトコルデータユニットを使用してサービスデータユニットのデータを伝送するためのデータパケット構造、方法、装置、システム、およびコンピュータ可読媒体を提供する。データパケットは、少なくとも１つのプロトコルデータユニットを備えているパケットペイロードであって、プロトコルデータユニットがサービスデータユニットまたはサービスデータユニットのフラグメントを備えている、パケットペイロードと、データパケットペイロードが、サービスデータユニットのフラグメントであるプロトコルデータユニットから始まっているか否かと、データパケットペイロードが、サービスデータユニットのフラグメントであるプロトコルデータユニットで終わっているか否かとを示すインディケータ、を備えているデータパケットヘッダと、を備えている。
【００３７】
有利な実施形態によると、インディケータは２つのフラグから構成されており、第１のフラグは、データパケットペイロードが、サービスデータユニットのフラグメントであるプロトコルデータユニットから始まっているかを示しており、第２のフラグは、データパケットペイロードが、サービスデータユニットのフラグメントであるプロトコルデータユニットで終わっているかを示している。
【００３８】
この実施形態の利点は、フラグが、設定時に、サービスデータユニットのフラグメントであるプロトコルデータユニットを示すことである。
【００３９】
別の有利な実施形態によると、データパケット構造は、データパケットのシーケンスにおけるデータパケットのポジションを示すシーケンス番号インディケータを備えている。
【００４０】
さらに有利な実施形態においては、サービスデータユニットを備えているデータパケットを送信する方法は、サービスデータユニットまたはサービスデータユニットのフラグメントを備えている少なくとも１つのプロトコルデータユニットを形成するステップと、少なくとも１つのプロトコルデータユニットを備えているデータパケットペイロードを形成するステップと、データパケットペイロードが、サービスデータユニットのフラグメントであるプロトコルデータユニットから始まっているか否かと、データパケットペイロードが、サービスデータユニットのフラグメントであるプロトコルデータユニットで終わっているか否かとを示すインディケータ、を少なくとも備えているデータパケットヘッダを形成するステップと、データパケットヘッダとデータパケットペイロードとを備えているデータパケットを形成するステップと、データパケットをチャネルを通じて送信するステップと、を含んでいる。
【００４１】
別の有利な実施形態によると、データパケットペイロードは、複数のプロトコルデータユニットを備えており、データパケットペイロードは、最初のプロトコルデータユニットから始まっており、最後のプロトコルデータユニットで終わっている。
【００４２】
さらなる有利な実施形態においては、所定のサイズのデータパケットペイロードを形成するステップは、以下のサブステップａ）、ｂ）、ｃ）をさらに含んでいる。ａ）においては、データパケットペイロードにおける残余サイズが、次のサービスデータユニット、または前のサービスデータユニットからの残りのフラグメントを伝送するのに十分であるかを判定する。十分である場合、ｂ）において、次のサービスデータユニット、または前のサービスデータユニットのフラグメントを備えている次のプロトコルデータユニットを形成し、そのプロトコルデータユニットをデータパケットペイロードに追加する。十分でない場合、次のサービスデータユニット、または前のサービスデータユニットからの残りのフラグメントをフラグメント化し、サービスデータユニットの第１のフラグメント、または前のサービスデータユニットからの残りのフラグメントの第１のフラグメントを備えているプロトコルデータユニットを、プロトコルデータユニットのサイズがデータパケットペイロードの残余サイズに一致するように形成し、そのプロトコルデータユニットをデータパケットペイロードに追加する。データパケットペイロードの残余サイズが、次のサービスデータユニットを伝送するのに不十分なサイズになるまで、ステップａ）およびステップｂ）を繰り返す。
【００４３】
データパケットペイロードがプロトコルデータユニットによって満たされた時点で、データパケットペイロードが、サービスデータユニットのフラグメントであるプロトコルデータユニットから始まっているか否かと、データパケットペイロードが、サービスデータユニットのフラグメントであるプロトコルデータユニットで終わっているか否かとを示すように、インディケータを設定することは、さらに有利である。
【００４４】
別の有利な実施形態においては、データパケットペイロードは、無線状態およびバッファの占有度に応じて、リソース割り当てエンティティによって動的に決定される。
【００４５】
さらに有利な実施形態においては、データパケットヘッダとデータパケットペイロードとを備えているデータパケットを受信する方法であって、データパケットペイロードが、サービスデータユニットまたはサービスデータユニットのフラグメントを備えている少なくとも１つのプロトコルデータユニットを備えている、方法、を提供するが記載されている。この方法は、チャネルを通じてデータパケットを受信するステップであって、各データパケットはデータパケットペイロードとデータパケットヘッダとを備えており、データパケットヘッダが、データパケットのシーケンスにおけるデータパケットのポジションを示すシーケンス番号インディケータと、データパケットペイロードが、サービスデータユニットのフラグメントであるプロトコルデータユニットから始まっているか否かと、データパケットペイロードが、サービスデータユニットのフラグメントであるプロトコルデータユニットで終わっているか否かとを示すインディケータと、を備えている、ステップと、受信したデータパケットペイロードのプロトコルデータユニットと、前に受信したプロトコルデータユニットとを、シーケンス番号インディケータに従って順序どおりに受信バッファに保存するステップと、受信したデータパケットペイロードの最初のプロトコルデータユニットを、順序において前のプロトコルデータユニットと結合するべきかと、受信したデータパケットペイロードの最後のプロトコルデータユニットを、順序において次のプロトコルデータユニットと結合するべきかとをマークするステップと、を含んでいる。
【００４６】
さらなる有利な実施形態によると、プロトコルデータユニットがマークされているかに関して受信バッファを分析し、マークされている場合、プロトコルデータユニットを、他方のマークされているプロトコルデータユニットと結合して、サービスデータユニットを形成する。
【００４７】
別の有利な実施形態においては、サービスデータユニットを備えているデータパケットを送信する装置を提供する。この装置は、サービスデータユニットまたはサービスデータユニットのフラグメントを備えているプロトコルデータユニットを形成するようになされているプロトコルデータユニット形成手段と、少なくとも１つのプロトコルデータユニットを備えているデータパケットペイロードを形成するようになされているデータパケットペイロード形成手段と、データパケットペイロードが、サービスデータユニットのフラグメントであるプロトコルデータユニットから始まっているか否かと、データパケットペイロードが、サービスデータユニットのフラグメントであるプロトコルデータユニットで終わっているか否かとを示すインディケータ、を備えているデータパケットヘッダ、を形成するようになされているデータパケットヘッダ形成手段と、データパケットヘッダとデータパケットペイロードとを備えているデータパケットを形成するようになされているデータパケット形成手段と、データパケットをチャネルを通じて送信するようになされている送信手段と、を備えている。
【００４８】
本発明のさらなる実施形態は、データパケットヘッダとデータパケットペイロードとを備えているデータパケットを受信する装置であって、データパケットペイロードが、サービスデータユニットまたはサービスデータユニットのフラグメントを備えている少なくとも１つのプロトコルデータユニットを備えている、装置に関する。この装置は、チャネルを通じてデータパケットを受信するようになされている受信手段であって、各データパケットはデータパケットペイロードとデータパケットヘッダとを備えており、データパケットヘッダが、データパケットのシーケンスにおけるデータパケットのポジションを示すシーケンス番号インディケータと、データパケットペイロードが、サービスデータユニットのフラグメントであるプロトコルデータユニットから始まっているか否かと、データパケットペイロードが、サービスデータユニットのフラグメントであるプロトコルデータユニットで終わっているか否かとを示すインディケータと、を備えている、受信手段、を備えている。この装置は、受信したデータパケットペイロードのプロトコルデータユニットと、前に受信したプロトコルデータユニットとを、シーケンス番号インディケータに従って順序どおりに保存するようになされている受信バッファと、受信したデータパケットペイロードの最初のプロトコルデータユニットを、順序において前のプロトコルデータユニットと結合するべきかと、受信したデータパケットペイロードの最後のプロトコルデータユニットを、順序において次のプロトコルデータユニットと結合するべきかとをマークするようになされているマーキング手段と、をさらに備えている。
【００４９】
本発明の別の実施形態は、命令を格納しているコンピュータ可読媒体であって、命令が送信装置のプロセッサによって実行されたときに、それによって、送信装置が、サービスデータユニットを備えているデータパケットを送信する、コンピュータ可読媒体、に関する。この送信は、サービスデータユニットまたはサービスデータユニットのフラグメントを備えている少なくとも１つのプロトコルデータユニットを形成するステップと、プロトコルデータユニットを備えているデータパケットペイロードを形成するステップと、データパケットペイロードが、サービスデータユニットのフラグメントであるプロトコルデータユニットから始まっているか否かと、データパケットペイロードが、サービスデータユニットのフラグメントであるプロトコルデータユニットで終わっているか否かとを示すインディケータ、を少なくとも備えているデータパケットヘッダ、を形成するステップと、データパケットをチャネルを通じて送信するステップと、によって行われる。
【００５０】
さらなる有利な実施形態は、命令を格納しているコンピュータ可読媒体であって、命令が受信装置のプロセッサによって実行されたときに、それによって、受信装置が、データパケットヘッダとデータパケットペイロードとを備えているデータパケットを受信し、データパケットペイロードが、サービスデータユニットまたはサービスデータユニットのフラグメントを備えている少なくとも１つのプロトコルデータユニットを備えている、コンピュータ可読媒体、に関する。この受信方法は、チャネルを通じてデータパケットを受信するステップであって、各データパケットがデータパケットペイロードとデータパケットヘッダとを備えており、データパケットヘッダが、データパケットのシーケンスにおけるデータパケットのポジションを示すシーケンス番号インディケータと、データパケットペイロードがサービスデータユニットのフラグメントであるプロトコルデータユニットから始まっているか否かと、データパケットペイロードがサービスデータユニットのフラグメントであるプロトコルデータユニットで終わっているか否かとを示すインディケータと、を備えている、ステップと、受信したデータパケットペイロードのプロトコルデータユニットと、前に受信したプロトコルデータユニットとを、シーケンス番号インディケータに従って順序どおりに受信バッファに保存するステップと、受信したデータパケットペイロードの最初のプロトコルデータユニットを、順序において前のプロトコルデータユニットと結合するべきかと、受信したデータパケットペイロードの最後のプロトコルデータユニットを、順序において次のプロトコルデータユニットと結合するべきかとをマークするステップと、を含んでいる。
【図面の簡単な説明】
【００５１】
【図１】ＯＳＩ層モデルを示している。
【図２】ＯＳＩ層モデルにおけるＳＤＵおよびＰＤＵを示している。
【図３】フラグメントナンバリングによるＳＡＲシグナリングを示している。
【図４】先頭フラグおよび終端フラグを使用してのＳＡＲシグナリングを示している。
【図５】長さインディケータを使用してのＳＡＲシグナリングを示している。
【図６】ＳＤＵ分割プロセスおよびＰＤＵ連結プロセスを示している。
【図７】トランスポートチャネルブロックの生成を示している。
【図８】ＵＭＴＳ  Ｒ９９におけるエラー伝搬を示している。
【図９】本発明の実施形態のＳＡＲおよび連結のプロセスを示している。
【図１０】本発明の実施形態の、フラグメント化フラグを使用してのＳＡＲおよび連結プロセスを示している。
【図１１】本発明の実施形態による、フラグメント化フラグを使用してのＳＡＲシグナリングを示している。
【図１２】分割および連結のプロセスの流れ図を示している。
【発明を実施するための形態】
【００５２】
以下では、本発明について添付の図面を参照しながらさらに詳しく説明する。明細書および図面において対応する同一・相当の細部は、同じ参照数字によって表してある。
【００５３】
本発明は、可変長の送信フレームを使用する任意のデータパケット通信システム、例えば、無線ネットワーク（ＧＳＭ、ＵＭＴＳ、ＷｉＬＡＮ、ＷｉＭＡＸなど）、あるいは固定ネットワーク（ＩＰ、フレームリレー、ＰＰＰ、ＡＴＭなど）に適用することができる。
【００５４】
本発明の複数の異なる実施形態は、ＯＳＩ層モデル、特に、ＳＤＵ層とＰＤＵ層との間でのパケット交換に基づいて説明してある。ＯＳＩ層モデルの関連部分と、ＳＤＵおよびＰＤＵの詳しい説明については、［発明の背景］を参照されたい。［発明の背景］では、通信ネットワークにおいてフラグメント化もしくは分割、またはその両方を採用する理由も説明してある。
【００５５】
本発明では、一定のシグナリングコストによる、分割および連結の効率的な手順を可能にする方法であって、送信するトランスポートブロックの長さが増すほどオーバーヘッドの割合が減少する方法、を提案する。
【００５６】
ＳＤＵの分割およびＰＤＵの連結は、いずれも、次のＴＴＩにおける送信に割り当てられる物理リソースに依存する。例えば、図９に示したように、次のトランスポートチャネルブロックのペイロードのサイズ（Ｓｉｚｅ＿ｉｎｄ）をＳＡＲ機能に知らせることができる。
【００５７】
ＳＡＲ機能は、この指示情報に基づいてｎ個のＳＤＵを選択し、これらのＳＤＵの合計サイズはｓｉｚｅ＿ｉｎｄをちょうど超える大きさである。ｎ個のＳＤＵの長さの合計がｓｉｚｅ＿ｉｎｄよりも大きい場合、最後のＳＤＵを２つのフラグメントに分割する。ｎ−１番目までのＳＤＵとｎ番目のＳＤＵの最初のフラグメントとの合計がｓｉｚｅ＿ｉｎｄに等しい。これらのＳＤＵのそれぞれは、ＰＤＵに変換され、連続的に付されるシーケンス番号を受けとる。次の送信については、２番目のフラグメントを最初に考慮する。図１０は以上の操作を示しており、ＳＤＵ３が２個のＰＤＵ（ＰＤＵ３とＰＤＵ４）にフラグメント化されている。
【００５８】
従って、構造に関して、形成されるＰＤＵは、トランスポートブロック（ＴｒＢｌｋ）内の最初のＰＤＵと最後のＰＤＵとを除いて（これらはＳＤＵのフラグメントであることがある）、すべて完全なＳＤＵである。最初と最後を除くすべてのＰＤＵが完全なＳＤＵであるため、受信機には、トランスポートブロック内の最初のＰＤＵと最後のＰＤＵがＳＤＵのフラグメントであるのか完全なＳＤＵであるのかを示せば十分である。この通知は、トランスポートブロックヘッダに付加される２個の１ビットフラグ、すなわち２個のフラグメント化フラグによって容易に行うことができる。最初のフラグメント化フラグ（ＦＦＦ）は、トランスポートブロック内の最初のＳＡＲ  ＰＤＵがＳＤＵのフラグメントであるか否かを示し、２番目のフラグメント化フラグ（ＳＦＦ）は、トランスポートブロック内の最後のＳＡＲ  ＰＤＵがＳＤＵのフラグメントであるか否かを示す。
【００５９】
このプロセスは、図１２のラインに沿った一般的な形式として記述することができる。ＳＤＵまたはＳＤＵのフラグメントをバッファから取得し、そのＳＤＵまたはＳＤＵのフラグメントがトランスポートブロックの残余サイズ（トランスポートブロック全体またはその一部）に収まるかを判定する。完全なＳＤＵまたはＳＤＵのフラグメントがトランスポートブロックの残余サイズに収まる場合、そのＳＤＵからＰＤＵを作成する。そのＰＤＵをトランスポートブロックに挿入する。
【００６０】
サイズが残っているか、トランスポートブロックを調べる。残っている場合、プロセスが再び最初から始まる。残っていない場合、インディケータを追加し、そのインディケータとともにトランスポートブロックを送信する。
【００６１】
しかしながら、ＳＤＵまたはＳＤＵのフラグメントがトランスポートブロックの残余サイズに収まらない場合、トランスポートブロックの残余サイズに収まるように、ＳＤＵをフラグメント化し、そのＳＤＵのフラグメントからＰＤＵを作成する。ＳＤＵの２番目のフラグメントをバッファに格納し、ＰＤＵをトランスポートブロックに挿入し、インディケータを追加する。
【００６２】
最初のフラグメント化フラグ（ＦＦＦ）は、トランスポートブロック内の最初のＰＤＵがＳＤＵのフラグメントであるか否かを示し、２番目のフラグメント化フラグ（ＳＦＦ）は、トランスポートブロック内の最後のＰＤＵがＳＤＵのフラグメントであるか否かを示す。
【００６３】
最後に、トランスポートブロックをインディケータと一緒に送信し、プロセスを再び開始することができる。
【００６４】
受信機は、ＦＦＦが１に設定されているトランスポートブロックｎを受信したとき、そのトランスポートブロック内の最初のＳＡＲ  ＰＤＵを、前のトランスポートブロックｎ−１の最後のＳＡＲ  ＰＤＵと結合しなければならないことを認識する。さらに、このトランスポートブロックの中の最後のＳＡＲ  ＰＤＵがＳＤＵのフラグメントである場合、ＳＦＦを１に設定することによってそのことが示されている。
【００６５】
消失が起こらないシステムにおいては、ＦＦＦおよびＳＦＦは冗長情報となり、必ずしも必要ではない。しかしながら、消失が起こるシステム（例えば無線システム）においては、この冗長情報は、エラー伝搬を防止するうえで役立つ。例えば、前の例において（ｎ−１）番目のトランスポートブロックが失われた場合、受信機ユニットは、ＳＡＲ  ＰＤＵのシーケンスナンバリングに基づいてこの消失を検出し、ｎ番目のトランスポートブロック内のＦＦＦによって、最初のＰＤＵは対応するＳＤＵが不完全であるため破棄できることが示される。しかしながら、ｎ番目のトランスポートブロック内の２番目およびそれ以降のＰＤＵは維持されており、これらを再構築機能において使用する。
【００６６】
ＳＤＵあたり送信されるＰＤＵが１つのみである場合でも、ＦＦＦとＳＦＦとが異なる値を持つことがある。ＦＦＦは、ＰＤＵを前のトランスポートチャネルブロックの最後のＰＤＵと結合すべきかを示し、ＳＦＦは、ＰＤＵを次のトランスポートチャネルブロックの最初のＰＤＵと結合すべきかを示す。
【００６７】
本発明の１つの重要な側面は、ＰＤＵレベル（すなわちＰＤＵヘッダ内で）ではなくトランスポートブロックヘッダ内でＳＡＲ情報をシグナリングすることである。可変サイズのＰＤＵと、分割および連結の単純な規則とを使用することによって、トランスポートブロックヘッダあたりわずか２個のビット（トランスポートブロック内で連結されている最初と最後のＰＤＵのステータス（フラグメント化されている、されていない）を示す）によってＳＡＲ情報を示すことを提案する。
【００６８】
従来技術の解決策と比べると、ＳＡＲ情報はトランスポートブロックあたり２ビットのみであり、先頭／終端フラグを使用してのＳＡＲシグナリングの場合におけるトランスポートブロックあたり２＊ｎ個のビット（ｎはトランスポートブロック内のＰＤＵの数）と比較されたい。同じトランスポートブロック内に多数のＰＤＵが連結されるとき、これは大幅な低減である。
【００６９】
上述したように、ＳＡＲ  ＰＤＵのサイズが可変であると想定する。例えば、ＵＭＴＳでは、現在のところＰＤＵのサイズは固定されており、サービスの伝送に使用されるベアラの静的パラメータである。場合によっては、ＰＤＵ境界の位置を受信機に知らせる必要がある。その場合、図１１に示したように、各ＰＤＵの長さをＳＡＲ  ＰＤＵヘッダ内の長さインディケータによって示すことが要求される。このインディケータは、実際には、長さインディケータによるＳＡＲシグナリング手法において、各ＰＤＵ内のＳＤＵ境界をシグナリングするために使用される長さインディケータフィールドと同等である。
【００７０】
さらに、トランスポートブロックあたり１つのみのＳＡＲ  ＰＤＵシーケンス番号をシグナリングすることによって、空間をさらに節約することが可能である。この目的には、トランスポートブロック内の最初のＰＤＵまたは最後のＰＤＵのシーケンス番号を使用することができる。受信機は、トランスポートブロック内に含まれている長さインディケータの数をカウントし、連結されているＰＤＵの数を取得する、または、図１１に示したように、この数を示す小さなフィールドＮをトランスポートブロックヘッダに追加することができる。
【００７１】
本発明の別の実施形態は、上述したさまざまな実施形態をハードウェアおよびソフトウェアを使用して実施することに関する。上述したさまざまな方法は、コンピューティングデバイス（プロセッサ）、例えば、汎用プロセッサ、デジタル信号プロセッサ（ＤＳＰ）、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、またはその他のプログラマブルロジックデバイスなどを使用して、実施または実行できることを認識されたい。本発明のさまざまな実施形態は、これらのデバイスの組合せによって実行または具体化することもできる。
【００７２】
さらには、本発明のさまざまな実施形態は、プロセッサによって実行されるソフトウェアモジュールによって実施する、あるいはハードウェアに直接実装することもできる。また、ソフトウェアモジュールとハードウェア実装とを組み合わせることも可能である。
【００７３】
ソフトウェアモジュールは、任意の種類のコンピュータ可読ストレージ媒体、例えば、ＲＡＭ、ＥＰＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリ、レジスタ、ハードディスク、ＣＤ−ＲＯＭ、ＤＶＤなどに格納することができる。
【図１】
0005568658.tif 000002
【図２】
0005568658.tif 000003
【図３】
0005568658.tif 000004
【図４】
0005568658.tif 000005
【図５】
0005568658.tif 000006
【図６】
0005568658.tif 000007
【図７】
0005568658.tif 000008
【図８】
0005568658.tif 000009
【図９】
0005568658.tif 000010
【図１０】
0005568658.tif 000011
【図１１】
0005568658.tif 000012
【図１２】
0005568658.tif 000013