JP2009509432A - 通信システムにおけるパケットの分割および連結をシグナリングする方法および装置 - Google Patents

Abstract

本発明は、プロトコルデータユニット（ＰＤＵ）を使用してサービスデータユニット（ＳＤＵ）のデータを伝送するデータパケット構造に関する。データパケットは、少なくとも１つのプロトコルデータユニット（ＰＤＵ）を備えているデータパケットペイロードであって、プロトコルデータユニット（ＰＤＵ）がサービスデータユニット（ＳＤＵ）またはサービスデータユニットのフラグメントを備えている、データパケットペイロードと、データパケットペイロードが、サービスデータユニットのフラグメントであるプロトコルデータユニット（ＰＤＵ）から始まっているか否かと、データパケットペイロードが、サービスデータユニットのフラグメントであるプロトコルデータユニット（ＰＤＵ）で終わっているか否かとを示すインジケータ（ＦＦＦ，ＳＦＦ）、を備えているデータパケットヘッダと、を備えている。

Description

本発明の分野は、通信システム（無線ネットワークまたは固定ネットワークのいずれかとすることができる）における上位層のパケットから下位層のフレームへのマッピングである。上位層によって渡されるパケットを物理ネットワークの能力（例えば最大フレームサイズ）に適合させる目的で、場合によっては、これらのパケットを、個別のフレームによって送信されるいくつかのブロックに分割またはフラグメント化する必要がある。同様に、送信効率を高める目的で、いくつかのパケットを１つのフレームに連結する必要が生じることもある。本発明は、送信機側において分割および連結がどのように行われたかを受信ユニットに伝える新しい効率的な方法を提案する。

上位層のパケットを物理ネットワークの特性に適合させる必要があることは、あらゆるタイプの通信システム、例えば、無線ネットワーク（ＧＳＭ、ＵＭＴＳ、ＷｉＬＡＮ、ＷｉＭａｘなど）、あるいは固定ネットワーク（ＩＰ、フレームリレー、ＰＰＰ、ＡＴＭなど）において、古典的な問題である。

ＯＳＩ層の概要
このセクションでは、以降の説明を進めるうえで使用しているＯＳＩモデル（図１を参照）について簡潔に紹介する。

開放型システム間相互接続参照モデル（略してＯＳＩモデルまたはＯＳＩ参照モデル）は、通信およびコンピュータネットワークのプロトコルの設計に関する階層的な抽象記述（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

本発明の目的は、パケット通信における効率的かつ実現可能な分割および連結を提供することである。

この目的は、独立請求項の主題によって解決されている。本発明の有利な実施形態は、従属請求項の主題である。

本発明の複数の異なる実施形態は、プロトコルデータユニットを使用してサービスデータユニットのデータを伝送するためのデータパケット構造、方法、装置、システム、およびコンピュータ可読媒体を提供する。データパケットは、少なくとも１つのプロトコルデータユニットを備えているパケットペイロードであって、プロトコルデータユニットがサービスデータユニットまたはサービスデータユニットのフラグメントを備えている、パケットペイロードと、データパケットペイロードが、サービスデータユニットのフラグメントであるプロトコルデータユニットから始まっているか否かと、データパケットペイロードが、サービスデータユニットのフラグメントであるプロトコルデータユニットで終わっているか否かとを示すインジケータ、を備えているデータパケットヘッダと、を備えている。

有利な実施形態によると、インジケータは２つのフラグから構成されており、第１のフラグは、データパケットペイロードが、サービスデータユニットのフラグメントであるプロトコルデータユニットから始まっているかを示しており、第２のフラグは、データパケットペイロードが、サービスデータユニットのフラグメントであるプロトコルデータユニットで終わっているかを示している。

この実施形態の利点は、フラグが、設定時に、サービスデータユニットのフラグメントであるプロトコルデータユニットを示すことである。

別の有利な実施形態によると、データパケット構造は、データパケットのシーケンスにおけるデータパケットのポジションを示すシーケンス番号インジケータを備えている。

さらに有利な実施形態においては、サービスデータユニットを備えているデータパケットを送信する方法は、サービスデータユニットまたはサービスデータユニットのフラグメントを備えている少なくとも１つのプロトコルデータユニットを形成するステップと、少なくとも１つのプロトコルデータユニットを備えているデータパケットペイロードを形成するステップと、データパケットペイロードが、サービスデータユニットのフラグメントであるプロトコルデータユニットから始まっているか否かと、データパケットペイロードが、サービスデータユニットのフラグメントであるプロトコルデータユニットで終わっているか否かとを示すインジケータ、を少なくとも備えているデータパケットヘッダを形成するステップと、データパケットヘッダとデータパケットペイロードとを備えているデータパケットを形成するステップと、データパケットをチャネルを通じて送信するステップと、を含んでいる。

別の有利な実施形態によると、データパケットペイロードは、複数のプロトコルデータユニットを備えており、データパケットペイロードは、最初のプロトコルデータユニットから始まっており、最後のプロトコルデータユニットで終わっている。

さらなる有利な実施形態においては、所定のサイズのデータパケットペイロードを形成するステップは、以下のサブステップａ）、ｂ）、ｃ）をさらに含んでいる。ａ）においては、データパケットペイロードにおける残余サイズが、次のサービスデータユニット、または前のサービスデータユニットからの残りのフラグメントを伝送するのに十分であるかを判定する。十分である場合、ｂ）において、次のサービスデータユニット、または前のサービスデータユニットのフラグメントを備えている次のプロトコルデータユニットを形成し、そのプロトコルデータユニットをデータパケットペイロードに追加する。十分でない場合、次のサービスデータユニット、または前のサービスデータユニットからの残りのフラグメントをフラグメント化し、サービスデータユニットの第１のフラグメント、または前のサービスデータユニットからの残りのフラグメントの第１のフラグメントを備えているプロトコルデータユニットを、プロトコルデータユニットのサイズがデータパケットペイロードの残余サイズに一致するように形成し、そのプロトコルデータユニットをデータパケットペイロードに追加する。データパケットペイロードの残余サイズが、次のサービスデータユニットを伝送するのに不十分なサイズになるまで、ステップａ）およびステップｂ）を繰り返す。

データパケットペイロードがプロトコルデータユニットによって満たされた時点で、データパケットペイロードが、サービスデータユニットのフラグメントであるプロトコルデータユニットから始まっているか否かと、データパケットペイロードが、サービスデータユニットのフラグメントであるプロトコルデータユニットで終わっているか否かとを示すように、インジケータを設定することは、さらに有利である。

別の有利な実施形態においては、データパケットペイロードは、無線状態およびバッファの占有度に応じて、リソース割り当てエンティティによって動的に決定される。

さらに有利な実施形態においては、データパケットヘッダとデータパケットペイロードとを備えているデータパケットを受信する方法であって、データパケットペイロードが、サービスデータユニットまたはサービスデータユニットのフラグメントを備えている少なくとも１つのプロトコルデータユニットを備えている、方法、を提供するが記載されている。この方法は、チャネルを通じてデータパケットを受信するステップであって、各データパケットはデータパケットペイロードとデータパケットヘッダとを備えており、データパケットヘッダが、データパケットのシーケンスにおけるデータパケットのポジションを示すシーケンス番号インジケータと、データパケットペイロードが、サービスデータユニットのフラグメントであるプロトコルデータユニットから始まっているか否かと、データパケットペイロードが、サービスデータユニットのフラグメントであるプロトコルデータユニットで終わっているか否かとを示すインジケータと、を備えている、ステップと、受信したデータパケットペイロードのプロトコルデータユニットと、前に受信したプロトコルデータユニットとを、シーケンス番号インジケータに従って順序どおりに受信バッファに保存するステップと、受信したデータパケットペイロードの最初のプロトコルデータユニットを、順序において前のプロトコルデータユニットと結合するべきかと、受信したデータパケットペイロードの最後のプロトコルデータユニットを、順序において次のプロトコルデータユニットと結合するべきかとをマークするステップと、を含んでいる。

さらなる有利な実施形態によると、プロトコルデータユニットがマークされているかに関して受信バッファを分析し、マークされている場合、プロトコルデータユニットを、他方のマークされているプロトコルデータユニットと結合して、サービスデータユニットを形成する。

別の有利な実施形態においては、サービスデータユニットを備えているデータパケットを送信する装置を提供する。この装置は、サービスデータユニットまたはサービスデータユニットのフラグメントを備えているプロトコルデータユニットを形成するようになされているプロトコルデータユニット形成手段と、少なくとも１つのプロトコルデータユニットを備えているデータパケットペイロードを形成するようになされているデータパケットペイロード形成手段と、データパケットペイロードが、サービスデータユニットのフラグメントであるプロトコルデータユニットから始まっているか否かと、データパケットペイロードが、サービスデータユニットのフラグメントであるプロトコルデータユニットで終わっているか否かとを示すインジケータ、を備えているデータパケットヘッダ、を形成するようになされているデータパケットヘッダ形成手段と、データパケットヘッダとデータパケットペイロードとを備えているデータパケットを形成するようになされているデータパケット形成手段と、データパケットをチャネルを通じて送信するようになされている送信手段と、を備えている。

本発明のさらなる実施形態は、データパケットヘッダとデータパケットペイロードとを備えているデータパケットを受信する装置であって、データパケットペイロードが、サービスデータユニットまたはサービスデータユニットのフラグメントを備えている少なくとも１つのプロトコルデータユニットを備えている、装置に関する。この装置は、チャネルを通じてデータパケットを受信するようになされている受信手段であって、各データパケットはデータパケットペイロードとデータパケットヘッダとを備えており、データパケットヘッダが、データパケットのシーケンスにおけるデータパケットのポジションを示すシーケンス番号インジケータと、データパケットペイロードが、サービスデータユニットのフラグメントであるプロトコルデータユニットから始まっているか否かと、データパケットペイロードが、サービスデータユニットのフラグメントであるプロトコルデータユニットで終わっているか否かとを示すインジケータと、を備えている、受信手段、を備えている。この装置は、受信したデータパケットペイロードのプロトコルデータユニットと、前に受信したプロトコルデータユニットとを、シーケンス番号インジケータに従って順序どおりに保存するようになされている受信バッファと、受信したデータパケットペイロードの最初のプロトコルデータユニットを、順序において前のプロトコルデータユニットと結合するべきかと、受信したデータパケットペイロードの最後のプロトコルデータユニットを、順序において次のプロトコルデータユニットと結合するべきかとをマークするようになされているマーキング手段と、をさらに備えている。

本発明の別の実施形態は、命令を格納しているコンピュータ可読媒体であって、命令が送信装置のプロセッサによって実行されたときに、それによって、送信装置が、サービスデータユニットを備えているデータパケットを送信する、コンピュータ可読媒体、に関する。この送信は、サービスデータユニットまたはサービスデータユニットのフラグメントを備えている少なくとも１つのプロトコルデータユニットを形成するステップと、プロトコルデータユニットを備えているデータパケットペイロードを形成するステップと、データパケットペイロードが、サービスデータユニットのフラグメントであるプロトコルデータユニットから始まっているか否かと、データパケットペイロードが、サービスデータユニットのフラグメントであるプロトコルデータユニットで終わっているか否かとを示すインジケータ、を少なくとも備えているデータパケットヘッダ、を形成するステップと、データパケットをチャネルを通じて送信するステップと、によって行われる。

さらなる有利な実施形態は、命令を格納しているコンピュータ可読媒体であって、命令が受信装置のプロセッサによって実行されたときに、それによって、受信装置が、データパケットヘッダとデータパケットペイロードとを備えているデータパケットを受信し、データパケットペイロードが、サービスデータユニットまたはサービスデータユニットのフラグメントを備えている少なくとも１つのプロトコルデータユニットを備えている、コンピュータ可読媒体、に関する。この受信方法は、チャネルを通じてデータパケットを受信するステップであって、各データパケットがデータパケットペイロードとデータパケットヘッダとを備えており、データパケットヘッダが、データパケットのシーケンスにおけるデータパケットのポジションを示すシーケンス番号インジケータと、データパケットペイロードがサービスデータユニットのフラグメントであるプロトコルデータユニットから始まっているか否かと、データパケットペイロードがサービスデータユニットのフラグメントであるプロトコルデータユニットで終わっているか否かとを示すインジケータと、を備えている、ステップと、受信したデータパケットペイロードのプロトコルデータユニットと、前に受信したプロトコルデータユニットとを、シーケンス番号インジケータに従って順序どおりに受信バッファに保存するステップと、受信したデータパケットペイロードの最初のプロトコルデータユニットを、順序において前のプロトコルデータユニットと結合するべきかと、受信したデータパケットペイロードの最後のプロトコルデータユニットを、順序において次のプロトコルデータユニットと結合するべきかとをマークするステップと、を含んでいる。

以下では、本発明について添付の図面を参照しながらさらに詳しく説明する。明細書および図面において対応する同一・相当の細部は、同じ参照数字によって表してある。

本発明は、可変長の送信フレームを使用する任意のデータパケット通信システム、例えば、無線ネットワーク（ＧＳＭ、ＵＭＴＳ、ＷｉＬＡＮ、ＷｉＭＡＸなど）、あるいは固定ネットワーク（ＩＰ、フレームリレー、ＰＰＰ、ＡＴＭなど）に適用することができる。

本発明の複数の異なる実施形態は、ＯＳＩ層モデル、特に、ＳＤＵ層とＰＤＵ層との間でのパケット交換に基づいて説明してある。ＯＳＩ層モデルの関連部分と、ＳＤＵおよびＰＤＵの詳しい説明については、［発明の背景］を参照されたい。［発明の背景］では、通信ネットワークにおいてフラグメント化もしくは分割、またはその両方を採用する理由も説明してある。

本発明では、一定のシグナリングコストによる、分割および連結の効率的な手順を可能にする方法であって、送信するトランスポートブロックの長さが増すほどオーバーヘッドの割合が減少する方法、を提案する。

ＳＤＵの分割およびＰＤＵの連結は、いずれも、次のＴＴＩにおける送信に割り当てられる物理リソースに依存する。例えば、図９に示したように、次のトランスポートチャネルブロックのペイロードのサイズ（Ｓｉｚｅ＿ｉｎｄ）をＳＡＲ機能に知らせることができる。

ＳＡＲ機能は、この指示情報に基づいてｎ個のＳＤＵを選択し、これらのＳＤＵの合計サイズはｓｉｚｅ＿ｉｎｄをちょうど超える大きさである。ｎ個のＳＤＵの長さの合計がｓｉｚｅ＿ｉｎｄよりも大きい場合、最後のＳＤＵを２つのフラグメントに分割する。ｎ−１番目までのＳＤＵとｎ番目のＳＤＵの最初のフラグメントとの合計がｓｉｚｅ＿ｉｎｄに等しい。これらのＳＤＵのそれぞれは、ＰＤＵに変換され、連続的に付されるシーケンス番号を受けとる。次の送信については、２番目のフラグメントを最初に考慮する。図１０は以上の操作を示しており、ＳＤＵ３が２個のＰＤＵ（ＰＤＵ３とＰＤＵ４）にフラグメント化されている。

従って、構造に関して、形成されるＰＤＵは、トランスポートブロック（ＴｒＢｌｋ）内の最初のＰＤＵと最後のＰＤＵとを除いて（これらはＳＤＵのフラグメントであることがある）、すべて完全なＳＤＵである。最初と最後を除くすべてのＰＤＵが完全なＳＤＵであるため、受信機には、トランスポートブロック内の最初のＰＤＵと最後のＰＤＵがＳＤＵのフラグメントであるのか完全なＳＤＵであるのかを示せば十分である。この通知は、トランスポートブロックヘッダに付加される２個の１ビットフラグ、すなわち２個のフラグメント化フラグによって容易に行うことができる。最初のフラグメント化フラグ（ＦＦＦ）は、トランスポートブロック内の最初のＳＡＲ ＰＤＵがＳＤＵのフラグメントであるか否かを示し、２番目のフラグメント化フラグ（ＳＦＦ）は、トランスポートブロック内の最後のＳＡＲ ＰＤＵがＳＤＵのフラグメントであるか否かを示す。

このプロセスは、図１２のラインに沿った一般的な形式として記述することができる。ＳＤＵまたはＳＤＵのフラグメントをバッファから取得し、そのＳＤＵまたはＳＤＵのフラグメントがトランスポートブロックの残余サイズ（トランスポートブロック全体またはその一部）に収まるかを判定する。完全なＳＤＵまたはＳＤＵのフラグメントがトランスポートブロックの残余サイズに収まる場合、そのＳＤＵからＰＤＵを作成する。そのＰＤＵをトランスポートブロックに挿入する。

サイズが残っているか、トランスポートブロックを調べる。残っている場合、プロセスが再び最初から始まる。残っていない場合、インジケータを追加し、そのインジケータとともにトランスポートブロックを送信する。

しかしながら、ＳＤＵまたはＳＤＵのフラグメントがトランスポートブロックの残余サイズに収まらない場合、トランスポートブロックの残余サイズに収まるように、ＳＤＵをフラグメント化し、そのＳＤＵのフラグメントからＰＤＵを作成する。ＳＤＵの２番目のフラグメントをバッファに格納し、ＰＤＵをトランスポートブロックに挿入し、インジケータを追加する。

最初のフラグメント化フラグ（ＦＦＦ）は、トランスポートブロック内の最初のＰＤＵがＳＤＵのフラグメントであるか否かを示し、２番目のフラグメント化フラグ（ＳＦＦ）は、トランスポートブロック内の最後のＰＤＵがＳＤＵのフラグメントであるか否かを示す。

最後に、トランスポートブロックをインジケータと一緒に送信し、プロセスを再び開始することができる。

受信機は、ＦＦＦが１に設定されているトランスポートブロックｎを受信したとき、そのトランスポートブロック内の最初のＳＡＲ ＰＤＵを、前のトランスポートブロックｎ−１の最後のＳＡＲ ＰＤＵと結合しなければならないことを認識する。さらに、このトランスポートブロックの中の最後のＳＡＲ ＰＤＵがＳＤＵのフラグメントである場合、ＳＦＦを１に設定することによってそのことが示されている。

消失が起こらないシステムにおいては、ＦＦＦおよびＳＦＦは冗長情報となり、必ずしも必要ではない。しかしながら、消失が起こるシステム（例えば無線システム）においては、この冗長情報は、エラー伝搬を防止するうえで役立つ。例えば、前の例において（ｎ−１）番目のトランスポートブロックが失われた場合、受信機ユニットは、ＳＡＲ ＰＤＵのシーケンスナンバリングに基づいてこの消失を検出し、ｎ番目のトランスポートブロック内のＦＦＦによって、最初のＰＤＵは対応するＳＤＵが不完全であるため破棄できることが示される。しかしながら、ｎ番目のトランスポートブロック内の２番目およびそれ以降のＰＤＵは維持されており、これらを再構築機能において使用する。

ＳＤＵあたり送信されるＰＤＵが１つのみである場合でも、ＦＦＦとＳＦＦとが異なる値を持つことがある。ＦＦＦは、ＰＤＵを前のトランスポートチャネルブロックの最後のＰＤＵと結合すべきかを示し、ＳＦＦは、ＰＤＵを次のトランスポートチャネルブロックの最初のＰＤＵと結合すべきかを示す。

本発明の１つの重要な側面は、ＰＤＵレベル（すなわちＰＤＵヘッダ内で）ではなくトランスポートブロックヘッダ内でＳＡＲ情報をシグナリングすることである。可変サイズのＰＤＵと、分割および連結の単純な規則とを使用することによって、トランスポートブロックヘッダあたりわずか２個のビット（トランスポートブロック内で連結されている最初と最後のＰＤＵのステータス（フラグメント化されている、されていない）を示す）によってＳＡＲ情報を示すことを提案する。

従来技術の解決策と比べると、ＳＡＲ情報はトランスポートブロックあたり２ビットのみであり、先頭／終端フラグを使用してのＳＡＲシグナリングの場合におけるトランスポートブロックあたり２＊ｎ個のビット（ｎはトランスポートブロック内のＰＤＵの数）と比較されたい。同じトランスポートブロック内に多数のＰＤＵが連結されるとき、これは大幅な低減である。

上述したように、ＳＡＲ ＰＤＵのサイズが可変であると想定する。例えば、ＵＭＴＳでは、現在のところＰＤＵのサイズは固定されており、サービスの伝送に使用されるベアラの静的パラメータである。場合によっては、ＰＤＵ境界の位置を受信機に知らせる必要がある。その場合、図１１に示したように、各ＰＤＵの長さをＳＡＲ ＰＤＵヘッダ内の長さインジケータによって示すことが要求される。このインジケータは、実際には、長さインジケータによるＳＡＲシグナリング手法において、各ＰＤＵ内のＳＤＵ境界をシグナリングするために使用される長さインジケータフィールドと同等である。

さらに、トランスポートブロックあたり１つのみのＳＡＲ ＰＤＵシーケンス番号をシグナリングすることによって、空間をさらに節約することが可能である。この目的には、トランスポートブロック内の最初のＰＤＵまたは最後のＰＤＵのシーケンス番号を使用することができる。受信機は、トランスポートブロック内に含まれている長さインジケータの数をカウントし、連結されているＰＤＵの数を取得する、または、図１１に示したように、この数を示す小さなフィールドＮをトランスポートブロックヘッダに追加することができる。

本発明の別の実施形態は、上述したさまざまな実施形態をハードウェアおよびソフトウェアを使用して実施することに関する。上述したさまざまな方法は、コンピューティングデバイス（プロセッサ）、例えば、汎用プロセッサ、デジタル信号プロセッサ（ＤＳＰ）、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、またはその他のプログラマブルロジックデバイスなどを使用して、実施または実行できることを認識されたい。本発明のさまざまな実施形態は、これらのデバイスの組合せによって実行または具体化することもできる。

さらには、本発明のさまざまな実施形態は、プロセッサによって実行されるソフトウェアモジュールによって実施する、あるいはハードウェアに直接実装することもできる。また、ソフトウェアモジュールとハードウェア実装とを組み合わせることも可能である。

ソフトウェアモジュールは、任意の種類のコンピュータ可読ストレージ媒体、例えば、ＲＡＭ、ＥＰＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリ、レジスタ、ハードディスク、ＣＤ−ＲＯＭ、ＤＶＤなどに格納することができる。

ＯＳＩ層モデルを示している。 ＯＳＩ層モデルにおけるＳＤＵおよびＰＤＵを示している。 フラグメントナンバリングによるＳＡＲシグナリングを示している。 先頭フラグおよび終端フラグを使用してのＳＡＲシグナリングを示している。 長さインジケータを使用してのＳＡＲシグナリングを示している。 ＳＤＵ分割プロセスおよびＰＤＵ連結プロセスを示している。 トランスポートチャネルブロックの生成を示している。 ＵＭＴＳ Ｒ９９におけるエラー伝搬を示している。 本発明の実施形態のＳＡＲおよび連結のプロセスを示している。 本発明の実施形態の、フラグメント化フラグを使用してのＳＡＲおよび連結プロセスを示している。 本発明の実施形態による、フラグメント化フラグを使用してのＳＡＲシグナリングを示している。 分割および連結のプロセスの流れ図を示している。

Claims (31)

1. プロトコルデータユニット（ＰＤＵ）を使用してサービスデータユニット（ＳＤＵ）のデータを伝送するデータパケット構造であって、前記データパケットは、
   少なくとも１つのプロトコルデータユニット（ＰＤＵ）を備えているデータパケットペイロードであって、プロトコルデータユニット（ＰＤＵ）がサービスデータユニット（ＳＤＵ）またはサービスデータユニットのフラグメントを備えている、前記データパケットペイロードと、
   前記データパケットペイロードがサービスデータユニットのフラグメントであるプロトコルデータユニット（ＰＤＵ）から始まっているか否かと、前記データパケットペイロードが前記サービスデータユニットのフラグメントであるプロトコルデータユニット（ＰＤＵ）で終わっているか否かとを示すインジケータ（ＦＦＦ，ＳＦＦ）、を備えているデータパケットヘッダと、
   を備えている、データパケット構造。
2. 前記インジケータは２つのフラグから構成されており、第１のフラグ（ＦＦＦ）が、前記データパケットペイロードがサービスデータユニットのフラグメントであるプロトコルデータユニット（ＰＤＵ）から始まっているかを示しており、第２のフラグ（ＳＦＦ）が、前記データパケットペイロードが前記サービスデータユニットのフラグメントであるプロトコルデータユニット（ＰＤＵ）で終わっているかを示している、請求項１に記載のデータパケット構造。
3. 前記フラグが、設定時に、サービスデータユニットのフラグメントであるプロトコルデータユニットを示す、請求項２に記載のデータパケット構造。
4. データパケットのシーケンスにおける前記データパケットのポジションを示すシーケンス番号インジケータ（ＳＮ）、
   を備えている、請求項１に記載のデータパケット構造。
5. サービスデータユニットを備えているデータパケットを送信する方法であって、
   サービスデータユニットまたはサービスデータユニットのフラグメントを備えている少なくとも１つのプロトコルデータユニットを形成する（１２０３，１２０８）ステップと、
   プロトコルデータユニットを備えているデータパケットペイロードを形成する（１２０５，１２０９）ステップと、
   前記データパケットペイロードがサービスデータユニットのフラグメントであるプロトコルデータユニットから始まっているか否かと、前記データパケットペイロードが前記サービスデータユニットのフラグメントであるプロトコルデータユニットで終わっているか否かとを示すインジケータ、を少なくとも備えているデータパケットヘッダを形成するステップと、
   前記データパケットヘッダと前記データパケットペイロードとを備えているデータパケットを形成するステップと、
   前記データパケットをチャネルを通じて送信する（１２０７）ステップと、
   を含んでいる、方法。
6. 前記データパケットペイロードが、複数のプロトコルデータユニットを備えており、前記データパケットペイロードが、最初のプロトコルデータユニットから始まっており、最後のプロトコルデータユニットで終わっている、請求項５に記載の方法。
7. 所定のサイズのデータパケットペイロードを形成する前記ステップは、
   以下のサブステップ、すなわち、
   ａ）前記データパケットペイロードにおける残余サイズが、次のサービスデータユニット、または前のサービスデータユニットからの残りのフラグメントを伝送するのに十分であるかを判定する（１２０２）ステップと、
   ｂ）十分である場合、前記次のサービスデータユニット、または前のサービスデータユニットからの前記残りのフラグメントを備えているプロトコルデータユニットを形成し（１２０８）、前記プロトコルデータユニットを前記データパケットペイロードに追加する（１２０９）ステップと、
   ｃ）十分でない場合、前記次のサービスデータユニット、または前のサービスデータユニットからの前記残りのフラグメントをフラグメント化し（１２０３）、前記サービスデータユニットの第１のフラグメント、または前のサービスデータユニットからの前記残りのフラグメントの第１のフラグメント、を備えているプロトコルデータユニットを、前記プロトコルデータユニットのサイズが前記データパケットペイロードの前記残余サイズに一致するように形成し、前記プロトコルデータユニットを前記データパケットペイロードに追加する（１２０５）ステップと、
   を含んでおり、
   前記データパケットペイロードの残余サイズが、次のサービスデータユニットを伝送するのに不十分なサイズになるまで、ステップａ）およびステップｂ）を繰り返す、
   請求項６に記載の方法。
8. 前記データパケットペイロードがプロトコルデータユニットによって満たされた時点で、前記データパケットペイロードがサービスデータユニットのフラグメントであるプロトコルデータユニットから始まっているか否かと、前記データパケットペイロードがサービスデータユニットのフラグメントであるプロトコルデータユニットで終わっているか否かとを示すようにインジケータを設定する、請求項７に記載の方法。
9. 前記データパケットペイロードのサイズが、無線状態およびバッファの占有度に応じて、リソース割り当てエンティティによって動的に決定される、請求項５から請求項８のいずれかに記載の方法。
10. 前記インジケータが２つのフラグから構成されており、第１のフラグが、前記データパケットペイロードがサービスデータユニットのフラグメントであるプロトコルデータユニットから始まっているかを示しており、第２のフラグが、前記データパケットペイロードが前記サービスデータユニットのフラグメントであるプロトコルデータユニットで終わっているかを示している、請求項５から請求項９のいずれかに記載の方法。
11. 前記フラグが、設定時に、サービスデータユニットのフラグメントであるプロトコルデータユニットを示す、請求項１０に記載の方法。
12. データパケットヘッダとデータパケットペイロードとを備えているデータパケットを受信する方法であって、前記データパケットペイロードが、サービスデータユニットまたはサービスデータユニットのフラグメントを備えている少なくとも１つのプロトコルデータユニットを備えており、
    チャネルを通じてデータパケットを受信するステップであって、各データパケットはデータパケットペイロードとデータパケットヘッダとを備えており、前記データパケットヘッダが、データパケットのシーケンスにおける前記データパケットのポジションを示すシーケンス番号インジケータと、前記データパケットペイロードがサービスデータユニットのフラグメントであるプロトコルデータユニットから始まっているか否かと、前記データパケットペイロードがサービスデータユニットのフラグメントであるプロトコルデータユニットで終わっているか否かとを示すインジケータと、を備えている、前記ステップと、
    前記受信したデータパケットペイロードの前記プロトコルデータユニットを、前に受信したプロトコルデータユニットと共に、前記シーケンス番号インジケータに従って順序どおりに受信バッファに保存するステップと、
    前記受信したデータパケットペイロードの最初のプロトコルデータユニットを、順序において前のプロトコルデータユニットと結合するべきかと、前記受信したデータパケットペイロードの最後のプロトコルデータユニットを、順序において次のプロトコルデータユニットと結合するべきかとをマークするステップと、
    を含んでいる、方法。
13. 前記プロトコルデータユニットがマークされているかに関して前記受信バッファを分析するステップと、
    マークされている場合、前記プロトコルデータユニットを、他方のマークされているプロトコルデータユニットと結合して、サービスデータユニットを形成するステップと、
    をさらに含んでいる、請求項１２に記載の方法。
14. 前記インジケータが２つのフラグから構成されており、第１のフラグが、前記データパケットペイロードがサービスデータユニットのフラグメントであるプロトコルデータユニットから始まっているかを示しており、第２のフラグが、前記データパケットペイロードが前記サービスデータユニットのフラグメントであるプロトコルデータユニットで終わっているかを示している、請求項１２または請求項１３に記載の方法。
15. 前記フラグが、設定時に、サービスデータユニットのフラグメントであるプロトコルデータユニットを示す、請求項１４に記載の方法。
16. サービスデータユニットを備えているデータパケットを送信する装置であって、
    サービスデータユニットまたはサービスデータユニットのフラグメントを備えているプロトコルデータユニットを形成するようになされているプロトコルデータユニット形成手段と、
    少なくとも１つのプロトコルデータユニットを備えているデータパケットペイロードを形成するようになされているデータパケットペイロード形成手段と、
    前記データパケットペイロードがサービスデータユニットのフラグメントであるプロトコルデータユニットから始まっているか否かと、前記データパケットペイロードがサービスデータユニットのフラグメントであるプロトコルデータユニットで終わっているか否かとを示すインジケータ、を備えているデータパケットヘッダ、を形成するようになされているデータパケットヘッダ形成手段と、
    前記データパケットヘッダと前記データパケットペイロードとを備えているデータパケットを形成するようになされているデータパケット形成手段と、
    前記データパケットをチャネルを通じて送信するようになされている送信手段と、
    を備えている、装置。
17. 前記データパケットペイロードは、複数のプロトコルデータユニットを備えており、前記データパケットペイロードは、最初のプロトコルデータユニットから始まっており、最後のプロトコルデータユニットで終わっている、請求項１６に記載の装置。
18. 前記データパケットペイロード形成手段は、所定のサイズのデータパケットペイロードを形成するようにさらになされており、
    前記データパケットペイロード形成手段は、
    前記データパケットペイロードにおける残余サイズが、次のサービスデータユニット、または前のサービスデータユニットからの残りのフラグメントを伝送するのに十分であるかを判定するようにされている判定手段、
    をさらに備えており、
    前記データパケットペイロード形成手段は、前記サービスデータユニットを備えている次のプロトコルデータユニットを形成して前記プロトコルデータユニットを前記データパケットペイロードに追加するようにさらになされており、かつ前記サービスデータユニットの前記フラグメントを備えている次のプロトコルデータユニットを形成して前記プロトコルデータユニットを前記データパケットペイロードに追加するようにさらになされている、
    請求項１７に記載の装置。
19. 前記データパケット形成手段は、
    前記データパケットペイロードがプロトコルデータユニットによって満たされた時点で、前記データパケットペイロードがサービスデータユニットのフラグメントであるプロトコルデータユニットから始まっているか否かと、前記データパケットペイロードがサービスデータユニットのフラグメントであるプロトコルデータユニットで終わっているか否かとを示すようにインジケータを設定するようにされている、
    請求項１８に記載の装置。
20. 前記データパケットペイロードのサイズは、無線状態およびバッファの占有度に応じて、リソース割り当てエンティティによって動的に決定される、請求項１６から請求項１９のいずれかに記載の装置。
21. 前記インジケータは２つのフラグから構成されており、第１のフラグが、前記データパケットペイロードがサービスデータユニットのフラグメントであるプロトコルデータユニットから始まっているかを示しており、第２のフラグが、前記データパケットペイロードが前記サービスデータユニットのフラグメントであるプロトコルデータユニットで終わっているかを示している、請求項１６から請求項２０のいずれかに記載の装置。
22. 前記フラグは、設定時に、サービスデータユニットのフラグメントであるプロトコルデータユニットを示す、請求項２１に記載の装置。
23. データパケットヘッダとデータパケットペイロードとを備えているデータパケットを受信する装置であって、データパケットペイロードは、サービスデータユニットまたはサービスデータユニットのフラグメントを備えている少なくとも１つのプロトコルデータユニットを備えており、
    チャネルを通じてデータパケットを受信するようになされている受信手段であって、各データパケットがデータパケットペイロードとデータパケットヘッダとを備えており、前記データパケットヘッダは、データパケットのシーケンスにおける前記データパケットのポジションを示すシーケンス番号インジケータと、前記データパケットペイロードがサービスデータユニットのフラグメントであるプロトコルデータユニットから始まっているか否かと、前記データパケットペイロードが前記サービスデータユニットのフラグメントである前記プロトコルデータユニットで終わっているか否かとを示すインジケータと、を備えている、前記受信手段と、
    前記受信したデータパケットペイロードの前記プロトコルデータユニットと、前に受信したプロトコルデータユニットとを、前記シーケンス番号インジケータに従って順序どおりに保存するようになされている受信バッファと、
    前記受信したデータパケットペイロードの最初のプロトコルデータユニットを、順序において前の前記プロトコルデータユニットと結合するべきかと、前記受信したデータパケットペイロードの最後のプロトコルデータユニットを、順序において次のプロトコルデータユニットと結合するべきかとをマークするようになされているマーキング手段と、
    を備えている、装置。
24. 前記プロトコルデータユニットがマークされているかに関して前記受信バッファを分析するようになされている分析手段と、
    前記プロトコルデータユニットがマークされている場合、前記プロトコルデータユニットを、他方のマークされているプロトコルデータユニットと結合して、サービスデータユニットを形成するようにされている結合手段と、
    をさらに備えている、請求項２３に記載の装置。
25. 前記インジケータが２つのフラグから構成されており、第１のフラグが、前記データパケットペイロードがサービスデータユニットのフラグメントであるプロトコルデータユニットから始まっているかを示しており、第２のフラグが、前記データパケットペイロードが前記サービスデータユニットのフラグメントであるプロトコルデータユニットで終わっているかを示している、請求項２３または請求項２４に記載の装置。
26. 前記フラグが、設定時に、サービスデータユニットのフラグメントであるプロトコルデータユニットを示す、請求項２５に記載の装置。
27. 請求項１６〜２２のいずれか１項に記載の送信する装置と、請求項２３から請求項２６のいずれかに記載の受信する装置とを備えているシステム。
28. 命令を格納しているコンピュータ可読媒体であって、前記命令が送信装置のプロセッサによって実行されたときに、それによって、前記送信装置は、以下のステップ、すなわち、
    サービスデータユニットまたはサービスデータユニットのフラグメントを備えている少なくとも１つのプロトコルデータユニットを形成するステップと、
    プロトコルデータユニットを備えているデータパケットペイロードを形成するステップと、
    前記データパケットペイロードが前記サービスデータユニットのフラグメントであるプロトコルデータユニットから始まっているか否かと、前記データパケットペイロードが前記サービスデータユニットのフラグメントであるプロトコルデータユニットで終わっているか否かとを示すインジケータ、を少なくとも備えているパケットヘッダ、を形成するステップと、
    前記データパケットヘッダと前記データパケットペイロードとを備えているデータパケットを形成するステップと、
    前記データパケットをチャネルを通じて送信するステップと、
    によって、サービスデータユニットを備えているデータパケットを送信する、
    コンピュータ可読媒体。
29. 前記命令が送信装置のプロセッサによって実行されたときに、それによって、前記送信装置が、請求項６から請求項１１のいずれかのステップを実行することによって、サービスデータユニットを備えているデータパケットを送信する、請求項２８に記載のコンピュータ可読媒体。
30. 命令を格納しているコンピュータ可読媒体であって、前記命令が受信装置のプロセッサによって実行されたときに、それによって、前記受信装置は、データパケットヘッダとデータパケットペイロードとを備えているデータパケットを受信し、前記データパケットペイロードは、サービスデータユニットまたはサービスデータユニットのフラグメントを備えている少なくとも１つのプロトコルデータユニットを備えており、前記方法は、
    チャネルを通じてデータパケットを受信するステップであって、各データパケットがデータパケットペイロードとデータパケットヘッダとを備えており、前記データパケットヘッダが、データパケットのシーケンスにおける前記データパケットのポジションを示すシーケンス番号インジケータと、前記データパケットペイロードがサービスデータユニットのフラグメントであるプロトコルデータユニットから始まっているか否かと、前記データパケットペイロードがサービスデータユニットのフラグメントであるプロトコルデータユニットで終わっているか否かとを示すインジケータと、を備えている、前記ステップと、
    前記受信したデータパケットペイロードの前記プロトコルデータユニットと、前に受信したプロトコルデータユニットとを、前記シーケンス番号インジケータに従って順序どおりに受信バッファに保存するステップと、
    前記受信したデータパケットペイロードの最初のプロトコルデータユニットを、順序において前の前記プロトコルデータユニットと結合するべきかと、前記受信したデータパケットペイロードの最後のプロトコルデータユニットを、順序において次のプロトコルデータユニットと結合するべきかとをマークするステップと、
    を含んでいる、
    コンピュータ可読媒体。
31. 前記命令が受信装置のプロセッサによって実行されたときに、それによって、前記受信装置が、請求項１３から請求項１５のいずれかに記載の方法のステップを実行することによって、データパケットヘッダとデータパケットペイロードとを備えているデータパケットを受信し、前記データパケットペイロードが、サービスデータユニットまたはサービスデータユニットのフラグメントを備えている少なくとも１つのプロトコルデータユニットを備えている、請求項３０に記載のコンピュータ可読媒体。
    

Images