(57)【要約】プロトコルスタックにおいて複数のプロトコルによる再度使用するシーケンス番号に関する技術が説明される。ある設計では、第１のプロトコルからの少なくとも１つのプロトコルデータユニット（ＰＤＵ）は、第１のプロトコルによって異なるシーケンス番号を割り当てられている各ＰＤＵと共に、第２のプロトコルで少なくとも１つのサービスデータユニット（ＳＤＵ）として受信されてもよい。各ＳＤＵのシーケンス番号は、第１のプロトコルからの対応するＰＤＵに関するシーケンス番号に基づいて決定されてもよい。ＰＤＵは、少なくとも１つのＳＤＵに基づいて第２のプロトコルによって形成されてもよい。ヘッダーは、ＰＤＵについて生成され、（ｉ）第１のＳＤＵに関するシーケンス番号および場合によってはセグメントオフセット、および（ｉｉ）それぞれ残りのＳＤＵに関するヘッダーブロックを含んでもよい。それは、セグメント長、シーケンス番号オフセット、およびＳＤＵに関するセグメントオフセットを含んでもよい。
2010527544.tif 000002
【特許請求の範囲】
【請求項１】
送信のためにデータを処理する方法であって、
第１のプロトコルによって第１のプロトコルデータユニット（ＰＤＵ）に割り当てられた第１のシーケンス番号を受信し、
第２のプロトコルで第１のプロトコルからの前記第１のシーケンス番号を用いる方法。
【請求項２】
前記第１のプロトコルはプロトコルスタックにおいて前記第２のプロトコルより上位であり、
前記方法は、
前記第２のプロトコルでサービスデータユニット（ＳＤＵ）として前記第１のプロトコルから前記第１のＰＤＵを受信し、
前記第１のＰＤＵに関する前記第１のシーケンス番号に基づいて前記ＳＤＵに関する第２のシーケンス番号を決定し、
前記ＳＤＵに基づいて前記第２のプロトコルで第２のＰＤＵを形成することをさらに具備する請求項１の方法。
【請求項３】
前記ＳＤＵの先頭からのオフセットおよび前記第２のシーケンス番号に基づいて前記ＳＤＵ内でデータをアドレッシングすることをさらに具備する請求項２の方法。
【請求項４】
ハンドオーバまたはコネクションセットアップで前記第２のプロトコルのシーケンス番号付けをリセットし、
シーケンス番号付けをリセットした後に、第１のプロトコルに関するシーケンス番号と第２のプロトコルに関するシーケンス番号との差に基づいてデルタを決定し、
前記第１のＰＤＵと前記デルタに関する第１のシーケンス番号に基づいて前記ＳＤＵに関する前記第２のシーケンス番号を決定することをさらに具備する請求項２の方法。
【請求項５】
前記第２のＰＤＵを形成することは、
前記ＳＤＵの一部を具備するセグメントを得るために前記ＳＤＵをセグメント化し、
前記セグメントを具備する前記第２のＰＤＵを形成し、
前記第２のＰＤＵに関するヘッダーを生成することを具備し、
前記ヘッダーは、前記ＳＤＵ内のセグメントの先頭を指示するセグメントオフセットおよび前記第２のシーケンス番号を含む請求項２に記載の方法。
【請求項６】
前記セグメントオフセットは、前記第２のＰＤＵにおける第１のバイトに対応する前記ＳＤＵにおける開始バイトを指示する請求項５の方法。
【請求項７】
前記第２のプロトコルで複数のサービスデータユニット（ＳＤＵ）として前記第１のプロトコルから複数のＰＤＵを受信し、
前記複数のＰＤＵのそれぞれは前記第１のプロトコルによって異なるシーケンス番号を割り当てられていて、
前記複数のＰＤＵは前記第１のＰＤＵを含み、
前記複数のＳＤＵは前記第１のＰＤＵに対応する第１のＳＤＵを含み、
前記複数のＳＤＵに基づいて前記第２のプロトコルで第２のＰＤＵを形成し、
前記第２のＰＤＵは第１のＳＤＵを含み、続いて前記複数のＳＤＵのうちの残りのものがある請求項１の方法。
【請求項８】
前記第２のＰＤＵは、前記第１のＳＤＵの全てまたは一部、前記複数のＳＤＵの中の最後のＳＤＵの全てまたは一部、および前記最初および最後のＳＤＵの間の各ＳＤＵの全てを具備する請求項７の方法。
【請求項９】
前記第２のＰＤＵは前記複数のＳＤＵのそれぞれの全てまたは一部を具備する請求項７の方法。
【請求項１０】
前記第１のＰＤＵに関する前記第１のシーケンス番号に基づいて前記第１のＳＤＵに関する第２のシーケンス番号を決定し、
前記第２のＰＤＵに関するヘッダーを生成し、
前記ヘッダーは、第１のＳＤＵに関する前記第２のシーケンス番号と前記複数のＳＤＵのうちの各残りのＳＤＵに関するヘッダーブロックを具備する請求項７の方法。
【請求項１１】
前記ヘッダーは、前記第２のＰＤＵにおける第１のバイトに対応する前記第１のＳＤＵにおける開始バイトを指示するセグメントオフセットをさらに具備する請求項１０の方法。
【請求項１２】
各残りのＳＤＵに関する前記ヘッダーブロックは、前記第２のＰＤＵにおいて送信されているＳＤＵからのデータ量を伝えるセグメント長を具備する請求項１０の方法。
【請求項１３】
各残りのＳＤＵに関する前記ヘッダーブロックは、前記ＳＤＵに関するシーケンス番号と、前記第２のＰＤＵにおける前のＳＤＵに関するシーケンス番号との差を伝えるシーケンス番号オフセットを具備する請求項１０の方法。
【請求項１４】
各残りのＳＤＵに関する前記ヘッダーブロックは、別のＳＤＵに関する別のヘッダーブロックが前記ヘッダーにおいて続くかどうか示す拡張ビットを具備する請求項１０の方法。
【請求項１５】
各残りのＳＤＵに関する前記ヘッダーブロックは、前記第２のＰＤＵにおいて送信されているＳＤＵにおける開始バイトを指示するセグメントオフセットを具備する請求項１０の方法。
【請求項１６】
前記第１のプロトコルはプロトコルスタックにおいて第２のプロトコルよりも下位であり、前記第１のシーケンス番号は前記第１のプロトコルから前記第２のプロトコルへ渡される請求項１の方法。
【請求項１７】
前記第１のプロトコルで生成された各ＰＤＵに、連続して増加するシーケンス番号を割り当て、
前記第１のプロトコルから前記第２のプロトコルで生成された各ＰＤＵに関する前記第２のプロトコルへシーケンス番号を渡し、
前記ＰＤＵに関する前記第１のプロトコルによって渡された前記シーケンス番号に基づいて決定されたシーケンス番号に、前記第２のプロトコルで生成された各ＰＤＵを割り当てることをさらに具備する請求項１の方法。
【請求項１８】
前記第１のプロトコルはパケットデータ収束プロトコル（ＰＤＣＰ）を具備し、前記第２のプロトコルは無線リンク制御（ＲＬＣ）を具備する請求項１の方法。
【請求項１９】
前記第１のプロトコルは無線リンク制御（ＲＬＣ）を具備し、前記第２のプロトコルはパケットデータ収束プロトコル（ＰＤＣＰ）を具備する請求項１の方法。
【請求項２０】
無線通信のための装置であって、
第１のプロトコルによって第１のプロトコルデータユニット（ＰＤＵ）に割り当てられた第１のシーケンス番号を受信し、第２のプロトコルで前記第１のプロトコルからの前記第１のシーケンス番号を用いる少なくとも１つのプロセッサを具備する装置。
【請求項２１】
前記少なくとも１つのプロセッサは、前記第２のプロトコルでサービスデータユニット（ＳＤＵ）として前記第１のプロトコルから前記第１のＰＤＵを受信し、前記第１のＰＤＵに関する前記第１のシーケンス番号に基づいて前記ＳＤＵに関する第２のシーケンス番号を決定し、前記ＳＤＵに基づいて前記第２のプロトコルで第２のＰＤＵを形成する請求項２０の装置。
【請求項２２】
前記少なくとも１つのプロセッサは、前記ＳＤＵの一部を具備するセグメントを得るために前記ＳＤＵをセグメント化し、前記セグメントを具備する前記第２のＰＤＵを形成し、前記ヘッダーは前記ＳＤＵ内の前記セグメントの開始を指示するセグメントオフセットと前記第２のシーケンス番号とを具備する請求項２１の装置。
【請求項２３】
前記少なくとも１つのプロセッサは、前記第２のプロトコルで複数のサービスデータユニット（ＳＤＵ）として第１のプロトコルから複数のＰＤＵを受信し、複数のＰＤＵのそれぞれは前記第１のプロトコルによって異なるシーケンス番号に割り当てられ、前記複数のＰＤＵは前記第１のＰＤＵを含み、前記複数のＳＤＵは前記第１のＰＤＵに対応する第１のＳＤＵを含み、前記複数のＳＤＵに基づいて前記第２のプロトコルで第２のＰＤＵを形成し、
前記第２のＰＤＵは第１のＳＤＵを含み、続いて前記複数のＳＤＵの残りのものがある請求項２０の装置。
【請求項２４】
前記少なくとも１つのプロセッサは、前記第１のＰＤＵに関する前記第１のシーケンス番号に基づいて前記第１のＳＤＵに関する第２のシーケンス番号を決定し、
前記第２のＰＤＵに関するヘッダーを生成し、前記ヘッダーは、前記第１のＳＤＵに関する前記第２のシーケンス番号と前記複数のＳＤＵのうちの各残りのものに関するヘッダーブロックとを具備し、各残りのＳＤＵに関する前記ヘッダーブロックはセグメント長、シーケンス番号オフセット、拡張ビット、およびセグメントオフセットのうちの少なくとも１つを具備する請求項２３の装置。
【請求項２５】
無線通信のための装置であって、
第１のプロトコルによって第１のプロトコルデータユニット（ＰＤＵ）に割り当てられた第１のシーケンス番号を受信する手段と、
第２のプロトコルで第１のプロトコルからの前記第１のシーケンス番号を用いる手段と、を具備する装置。
【請求項２６】
前記第２のプロトコルでサービスデータユニット（ＳＤＵ）として前記第１のプロトコルから前記第１のＰＤＵを受信する手段と、
前記第１のＰＤＵに関する前記第１のシーケンス番号に基づいて前記ＳＤＵに関する第２のシーケンス番号を決定する手段と、
前記ＳＤＵに基づいて前記第２のプロトコルで第２のＰＤＵを形成する手段と、をさらに具備する請求項２５の装置。
【請求項２７】
前記第２のＰＤＵを形成する手段は、前記ＳＤＵの一部を具備するセグメントを得るために前記ＳＤＵをセグメント化する手段と、前記セグメントを具備する前記第２のＰＤＵを形成する手段と、前記第２のＰＤＵに関するヘッダーを生成する手段と、を具備し、前記ヘッダーは、前記ＳＤＵ内のセグメントの先頭を指示するセグメントオフセットおよび前記第２のシーケンス番号を含む請求項２６の装置。
【請求項２８】
前記第２のプロトコルで複数のサービスデータユニット（ＳＤＵ）として前記第１のプロトコルから複数のＰＤＵを受信する手段と、前記複数のＰＤＵのそれぞれは前記第１のプロトコルによって異なるシーケンス番号を割り当てられていて、前記複数のＰＤＵは前記第１のＰＤＵを含み、前記複数のＳＤＵは前記第１のＰＤＵに対応する第１のＳＤＵを含み、
前記複数のＳＤＵに基づいて前記第２のプロトコルで第２のＰＤＵを形成する手段と、をさらに具備し、
前記第２のＰＤＵは第１のＳＤＵを含み、続いて前記複数のＳＤＵの残りがある請求項２５の装置。
【請求項２９】
前記第１のＰＤＵに関する前記第１のシーケンス番号に基づいて前記第１のＳＤＵに関する第２のシーケンス番号を決定する手段と、
前記第２のＰＤＵに関するヘッダーを生成する手段と、を具備し、
前記ヘッダーは、第１のＳＤＵに関する前記第２のシーケンス番号と前記複数のＳＤＵのうちの各残りのＳＤＵに関するヘッダーブロックを具備し、
各残りのＳＤＵに関する前記ヘッダーブロックは、セグメント長、シーケンス番号オフセット、拡張ビット、およびセグメントオフセットのうちの少なくとも１つを具備する請求項２８の装置。
【請求項３０】
少なくとも１つのコンピュータに、第１のプロトコルによって第１のプロトコルデータユニット（ＰＤＵ）に割り当てられた第１のシーケンス番号を受信させるためのコードと、
前記少なくとも１つのコンピュータに、第２のプロトコルで前記第１のプロトコルからの前記第１のシーケンス番号を用いさせるためのコードと、を具備するコンピュータ読取可能媒体を具備するコンピュータプログラムプロダクト。
【請求項３１】
データを受信する方法であって、
第１のプロトコルで第１のプロトコルデータユニット（ＰＤＵ）を受信し、
前記第１のＰＤＵに基づいて前記第１のプロトコルで第１のサービスデータユニット（ＳＤＵ）を形成し、
前記第１のＰＤＵに関するヘッダーに基づいて前記第１のＳＤＵに関する第１のシーケンス番号を決定し、
第２のプロトコルで第２のＰＤＵとして前記第１のＳＤＵを受信し、
前記第１のＳＤＵに関する前記第１のシーケンス番号に基づいて前記第２のＰＤＵに関する第２のシーケンス番号を決定することを具備する方法。
【請求項３２】
前記第２のシーケンス番号を決定することは、前記第１のＳＤＵとデルタに関する前記第１のシーケンス番号に基づいて前記第２のＰＤＵに関する前記第２のシーケンス番号を決定することを具備する請求項３１の方法。
【請求項３３】
前記第１のＳＤＵを形成することは、前記ヘッダーからセグメントオフセットを得て、前記セグメントオフセットによって決定された前記第１のＳＤＵにおいてある位置で始まる前記第１のＳＤＵに前記第１のＰＤＵをマッピングすることを具備する請求項３１の方法。
【請求項３４】
前記第１のＰＤＵに基づいて前記第１のプロトコルで複数のＳＤＵを形成し、
前記複数のＳＤＵは前記第１のＳＤＵを含み、続いて前記複数のＳＤＵのうちの残りのものがあり、
前記ヘッダーに基づいて前記第１のプロトコルで前記複数のＳＤＵのそれぞれに関するシーケンス番号を決定することをさらに具備する請求項３１の方法。
【請求項３５】
前記第１のプロトコルで前記複数のＳＤＵのそれぞれに関するシーケンス番号を決定することは、前記ヘッダーからそれぞれの残りのＳＤＵに関するシーケンス番号オフセットを得て、前記ＳＤＵに関する前記シーケンス番号オフセットと前のＳＤＵに関するシーケンス番号に基づいてそれぞれの残りのＳＤＵに関する前記シーケンス番号を決定する請求項３４の方法。
【請求項３６】
前記ヘッダーから前記複数のＳＤＵのそれぞれに関するセグメントオフセットを得て、
前記ＳＤＵに関する前記セグメントオフセットによって決定された前記ＳＤＵにおいてある位置で始まる前記複数のＳＤＵのそれぞれに、前記第１のＰＤＵにおけるデータの一部をマッピングすることをさらに具備する請求項３４の方法。
【請求項３７】
前記ヘッダーから前記複数のＳＤＵのそれぞれに関するセグメント長を得て、
前記ＰＤＵに関するセグメント長に基づいて前記複数のＳＤＵのそれぞれに関する前記第１のＰＤＵにおけるデータ量を決定することをさらに具備する請求項３４の方法。
【請求項３８】
前記第１のプロトコルは無線リンク制御（ＲＬＣ）を具備し、前記第２のプロトコルはパケットデータ収束プロトコル（ＰＤＣＰ）を具備する請求項３１の方法。
【請求項３９】
無線通信のための装置であって、
第１のプロトコルで第１のプロトコルデータユニット（ＰＤＵ）を受信し、前記第１のＰＤＵに基づいて前記第１のプロトコルで第１のサービスデータユニット（ＳＤＵ）を形成し、前記第１のＰＤＵに関するヘッダーに基づいて前記第１のＳＤＵに関する第１のシーケンス番号を決定し、第２のプロトコルで第２のＰＤＵとして前記第１のＳＤＵを受信し、前記第１のＳＤＵに関する前記第１のシーケンス番号に基づいて前記第２のＰＤＵに関する第２のシーケンス番号を決定する少なくとも１つのプロセッサを具備する装置。
【請求項４０】
前記少なくとも１つのプロセッサは、前記ヘッダーからセグメントオフセットを得て、前記セグメントオフセットによって決定された前記第１のＳＤＵにおいてある位置で始まる前記第１のＳＤＵに前記第１のＰＤＵをマッピングする請求項３９の装置。
【請求項４１】
前記少なくとも１つのプロセッサは、前記第１のＰＤＵに基づいて前記第１のプロトコルで複数のＳＤＵを形成し、前記複数のＳＤＵは前記第１のＳＤＵを含み、続いて前記複数のＳＤＵのうちの残りのものがあり、前記ヘッダーに基づいて前記第１のプロトコルで前記複数のＳＤＵのそれぞれに関するシーケンス番号を決定する請求項３９の装置。
【請求項４２】
前記少なくとも１つのプロセッサは、セグメント長、シーケンス番号オフセット、および前記ヘッダーからの残りのＳＤＵのそれぞれに関するセグメントオフセットのうちの少なくとも１つを得る請求項４１の装置。
【請求項４３】
送信のためのデータを処理する方法であって、
複数のサービスデータユニット（ＳＤＵ）を受信し、各ＳＤＵはそれぞれのシーケンス番号を割り当てられていて、
前記複数のＳＤＵを具備するプロトコルデータユニット（ＰＤＵ）を生成し、
前記ＰＤＵに関するヘッダーを生成し、前記ヘッダーは第１のＳＤＵに関するシーケンス番号と前記ＰＤＵにおける残りのＳＤＵのそれぞれに関するシーケンス番号オフセットを備えることを具備する方法。
【請求項４４】
前記ＳＤＵに関するシーケンス番号と前記ＰＤＵにおける前のＳＤＵに関するシーケンス番号との差に基づいてそれぞれの残りのＳＤＵに関する前記シーケンス番号オフセットを決定することをさらに具備する請求項４３の方法。
【請求項４５】
前記複数のＳＤＵは連続しないシーケンス番号を有する請求項４３の方法。
【請求項４６】
前記複数のＳＤＵを受信することは、無線リンク制御（ＲＬＣ）で前記複数のＳＤＵを受信することを具備する請求項４３の方法。
【請求項４７】
無線通信のための装置であって、
複数のサービスデータユニット（ＳＤＵ）を受信し、それぞれのＳＤＵはそれぞれのシーケンス番号に割り当てられていて、複数のＳＤＵを具備するプロトコルデータユニット（ＰＤＵ）を生成し、前記ＰＤＵに関するヘッダーを生成し、前記ＰＤＵに関するヘッダーを生成し、前記ヘッダーは第１のＳＤＵに関するシーケンス番号と前記ＰＤＵにおけるそれぞれの残りのＳＤＵに関するシーケンス番号オフセットを具備する少なくとも１つのプロセッサを具備する装置。
【請求項４８】
前記少なくとも１つのプロセッサは、前記ＳＤＵに関するシーケンス番号と前記ＰＤＵにおける前のＳＤＵに関するシーケンス番号との差に基づいてそれぞれの残りのＳＤＵに関する前記シーケンス番号オフセットを決定する請求項４７の装置。
【請求項４９】
データを受信する方法であって、
複数のサービスデータユニット（ＳＤＵ）を具備するプロトコルデータユニット（ＰＤＵ）を受信し、
前記ＰＤＵに関するヘッダーを受信し、前記ヘッダーは第１のＳＤＵに関するシーケンス番号と前記ＰＤＵにおけるそれぞれの残りのＳＤＵに関するシーケンス番号オフセットを具備し、
前記第１のＳＤＵに関する前記シーケンス番号およびそれぞれの残りのＳＤＵに関する前記シーケンス番号オフセットに基づいて前記複数のＳＤＵのそれぞれに関するシーケンス番号を決定する方法。
【請求項５０】
前記ＳＤＵに関する前記シーケンス番号オフセットおよび前記ＰＤＵにおける前のＳＤＵに関するシーケンス番号に基づいて、それぞれの残りのＳＤＵに関するシーケンス番号を決定することをさらに具備する請求項４９の方法。
【請求項５１】
前記複数のＳＤＵは連続しないシーケンス番号を持つことを特徴とする請求項４９の方法。
【請求項５２】
無線通信のための装置であって、
複数のサービスデータユニット（ＳＤＵ）を具備するプロトコルデータユニット（ＰＤＵ）を受信し、前記ＰＤＵに関するヘッダーを受信し、前記ヘッダーは第１のＳＤＵに関するシーケンス番号と前記ＰＤＵにおけるそれぞれの残りのＳＤＵに関するシーケンス番号オフセットを具備し、前記第１のＳＤＵに関する前記シーケンス番号およびそれぞれの残りのＳＤＵに関する前記シーケンス番号オフセットに基づいて前記複数のＳＤＵのそれぞれに関するシーケンス番号を決定する少なくとも１つのプロセッサを具備する装置。
【請求項５３】
前記少なくとも１つのプロセッサは、前記ＳＤＵに関する前記シーケンス番号オフセットおよび前記ＰＤＵにおける前のＳＤＵに関するシーケンス番号に基づいて、それぞれの残りのＳＤＵに関するシーケンス番号を決定する請求項５２の装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本開示は、一般的に通信に関連し、特に無線通信システムにおけるデータを送信するための技術に関する。
【０００２】
本願は、２００７年５月７日に提出され、譲受人にこれについて割り当てられ、参照することによりここに組み込まれる“A METHOD AND APPARATUS FOR RLC HEADER FORMATS FOR RLC REUSING PDCP SEQUENCE NUMBERING”と題された米国仮出願第６０／９１６，５１９に優先権を主張する。
【背景技術】
【０００３】
無線通信システムは、音声、ビデオ、パケットデータ、メッセージング、ブロードキャスト等のような種々の通信コンテンツを提供するために広く展開している。
【０００４】
これらの無線システムは、利用可能システムリソースを共有することによって複数ユーザをサポートすることができる多元接続システムである可能性がある。そのような多元接続システムの例は、符号分割多元接続（ＣＤＭＡ）システム、時分割多元接続（ＴＤＭＡ）システム、周波数分割多元接続（ＦＤＭＡ）システム、直交ＦＤＭＡ（ＯＦＤＭＡ）システム、およびシングルキャリアＦＤＭＡ（ＳＣ−ＦＤＭＡ）システムを含む。
【０００５】
無線通信システムでは、送信機は、受信機への送信に関する出力データを生成するために、プロトコルスタックにおいて１セットのプロトコルに従ってトラフィックデータを処理してもよい。プロトコルはそれぞれ、高次レイヤまたは（もしあれば）サブレイヤにおいてプロトコルからサービスデータユニット（ＳＤＵ）を受信し、下位レイヤまたは（もしあれば）サブレイヤにおいてプロトコルに関するプロトコルデータユニット（ＰＤＵ）を生成してもよい。ＰＤＵはそれぞれ、典型的にはそのＰＤＵに関する関連情報を含んでいるヘッダーを含んでいる。ヘッダーがオーバーヘッドを表わすので、ヘッダーオーバーヘッドを、効率を向上するために可能な程度に減少させることは望ましい。
【発明の概要】
【０００６】
ヘッダーオーバーヘッドを減少させるために、プロトコルスタックにおいて複数のプロトコルによってシーケンス番号を再度使用するための技術は、本明細書で記述される。ある設計では、プロトコルスタックにおいて第１のプロトコルによって割り当てられたシーケンス番号は、第２のプロトコルで再度用いられてもよい。ある設計では、第１のプロトコルはパケットデータ収束プロトコル（ＰＤＣＰ）かもしれないし、第２のプロトコルは無線リンク制御（ＲＬＣ）かもしれない。第１および第２のプロトコルはまた他のプロトコルかもしれない。
【０００７】
ある設計では、ＰＤＣＰ ＰＤＵは、ＰＤＣＰによってＰＤＣＰシーケンス番号（ＰＤＳＮ  ＳＮ）を割り当てられているＰＤＣＰ ＰＤＵと共に、ＲＬＣでＲＬＣ ＳＤＵとして受信されてもよい。ＲＬＣ ＳＤＵに関するＲＬＣシーケンス番号（ＲＬＣ ＳＮ）はＰＤＣＰ ＳＮに基づいて決定されてもよい。ＲＬＣ ＰＤＵはＲＬＣ ＳＤＵに基づいて形成されてもよく、ＲＬＣ ＳＤＵの全てまたはセグメントを含んでもよい。ヘッダーは、ＲＬＣ ＰＤＵについて生成されてもよく、ＲＬＣ ＰＤＵにおける第１バイトに対応するＲＬＣ ＳＤＵにおける開始バイトを指示するＲＬＣ ＳＮおよび場合によりセグメントオフセットを含んでもよい。
【０００８】
別の設計では、複数のＰＤＣＰ ＰＤＵは、ＰＤＣＰによって異なるＰＤＣＰ ＳＮを割り当てられている各ＰＤＣＰ ＰＤＵと共に、ＲＬＣで複数のＲＬＣ ＳＤＵとして受信されてもよい。各ＲＬＣ ＳＤＵに関するＲＬＣ ＳＮは対応するＰＤＣＰ ＰＤＵに関するＰＤＣＰ ＳＮに基づいて決定されてもよい。ＲＬＣ ＰＤＵは複数のＲＬＣ ＳＤＵに基づいて形成されてもよい。ヘッダーはＲＬＣ ＰＤＵについて生成されてもよく、第１のＲＬＣ ＳＤＵに関するＲＬＣ ＳＮおよび残りのＲＬＣ ＳＤＵのそれぞれに関するヘッダーブロックを含んでもよい。残りのＲＬＣ ＳＤＵのそれぞれに関するヘッダーブロックは以下を含んでもよい。  
（ｉ）ＲＬＣ ＰＤＵにおいて送られているＲＬＣ ＳＤＵからのデータ量を伝えるセグメント長、
（ｉｉ）ＲＬＣ ＳＤＵに関するＲＬＣ ＳＮと、ＲＬＣ ＰＤＵにおける前のＲＬＣ ＳＤＵに関するＲＬＣ ＳＮとの間の差を指示するＳＮオフセット、
（ｉｉｉ）ＲＬＣ ＰＤＵにおいて送られているＲＬＣ ＳＤＵにおける開始バイトを指示するセグメントオフセット、
（ｉｖ）別のヘッダーブロックが続くかどうか示す拡張ビット、および（または）（ｖ）他の何らかの情報。
【０００９】
以下、この開示の種々の態様および特徴をより詳しく説明する。
【図面の簡単な説明】
【００１０】
【図１】図１は、無線通信システムを示す。
【図２】図２は、システムにおける種々のエンティティに関する複数例のプロトコルスタックを示す。
【図３】図３は送信機でＰＤＣＰとＲＬＣによる処理を示す。
【図４】図４は、ＳＮ再使用を有するＲＬＣヘッダーの１つの設計を示す。
【図５】図５は、ＳＮ再使用を有するＲＬＣヘッダーの別の設計を示す。
【図６】図６は、ＳＮ再使用を有するＲＬＣヘッダーのさらに別の設計を示す。
【図７】図７は、送信機でＰＤＣＰに関するＲＬＣ ＳＮを再使用する設計を示す。
【図８】図８は、ＳＮ再使用を有するデータを送信するためのプロセスを示す。
【図９】図９は、ＳＮ再使用を有するデータを送信するための装置を示す。
【図１０】図１０は、ＳＮ再使用を有するデータを受信するためのプロセスを示す。
【図１１】図１１は、ＳＮ再使用を有するデータを受信するための装置を示す。
【図１２】図１２は、ＳＮオフセットを有するデータを送信するためのプロセスを示す。
【図１３】図１３は、ＳＮオフセットを有するデータを送信するための装置を示す。
【図１４】図１４は、ＳＮオフセットを有するデータを受信するためのプロセスを示す。
【図１５】図１５はＳＮオフセットを有するデータを受信するための装置を示す。
【図１６】図１６は、ノードＢとＵＥのブロック図を示す。
【発明を実施するための形態】
【００１１】
本明細書で説明された技術は、ＣＤＭＡ、ＴＤＭＡ、ＦＤＭＡ、ＯＦＤＭＡ、ＳＣ−ＦＤＭＡおよび他のシステムのような種々の無線通信システムに用いられてもよい。「システム」、「ネットワーク」という用語は、しばしば区別なく用いられる。ＣＤＭＡシステムは、ユニバーサル地上無線アクセス（ＵＴＲＡ）、ｃｄｍａ２０００などのような無線技術を実装してもよい。ＵＴＲＡは、広帯域ＣＤＭＡ（ＷＣＤＭＡ）およびＣＤＭＡの他の改良型を含んでいる。ｃｄｍａ２０００はＩＳ−２０００、ＩＳ−９５およびＩＳ−８５６標準をカバーする。ＴＤＭＡシステムは、グローバル移動体通信システム（ＧＳＭ）のような無線技術を実装してもよい。ＯＦＤＭＡシステムは、発展型ＵＴＲＡ（Ｅ−ＵＴＲＡ）、ウルトラモバイルブロードバンド（ＵＭＢ）、ＩＥＥＥ８０２．１１（Ｗｉ−Ｆｉ）、ＩＥＥＥ  ８０２．１６（ＷｉＭＡＸ）、ＩＥＥＥ  ８０２．２０、フラッシュＯＦＤＭなどのような無線技術を実装してもよい。ＵＴＲＡおよびＥ−ＵＴＲＡはユニバーサルモバイル通信システム（ＵＭＴＳ）の一部である。３ＧＰＰロングタームエボリューション（ＬＴＥ）はＥ−ＵＴＲＡを用いるＵＭＴＳの来るべきリリースであり、ダウンリンクにＯＦＤＭＡを用い、アップリンクにＳＣ−ＦＤＭＡを用いる。ＵＴＲＡ、Ｅ−ＵＴＲＡ、ＵＭＴＳ、ＬＴＥおよびＧＳＭは「３ｒｄ  Ｇｅｎｅｒａｔｉｏｎ  Ｐａｒｔｎｅｒｓｈｉｐ  Ｐｒｏｊｅｃｔ」（３ＧＰＰ）という名称の組織からの文献に記載されている。ｃｄｍａ２０００およびＵＭＢは「３ｒｄ  Ｇｅｎｅｒａｔｉｏｎ  Ｐａｒｔｎｅｒｓｈｉｐ  Ｐｒｏｊｅｃｔ  ２」（３ＧＰＰ２）という名称の組織からの文献に記載されている。明確にするために、技術のある態様はＬＴＥについて下記に述べられ、ＬＴＥ用語は以下の説明の多くにおいて用いられる。
【００１２】
図１は、複数のノードＢ１２０および１２２を有する無線通信システム１００を示す。ノードＢは、ＵＥと通信する固定局であってもよく、エボルブドノードＢ（ｅＮＢ）、基地局、アクセスポイントなどと称されることがある。ノードＢ１２０および１２２は、モビリティ管理エンティティ／システムアーキテクチャーエボリューション（ＭＭＥ／ＳＡＥ）ゲートウェイ１３０と通信してもよく、それは、ＵＥに関するデータサービスをサポートしてもよい。ＳＡＥゲートウェイ１３０は、コアおよび（または）データネットワーク１４０（例えばインターネット）に連結してもよく、コア／データネットワーク１４０に連結する他のエンティティ（例えばリモートサーバーおよび端末）と通信してもよい。ノードＢ１２０および１２２とＳＡＥゲートウェイ１３０との機能は、公に利用可能である「発展型ユニバーサル地上無線アクセス（Ｅ−ＵＴＲＡ）および発展型ユニバーサル地上無線アクセスネットワーク（Ｅ−ＵＴＲＡＮ）；全体の詳細な説明；ステージ２」と題されて、３ＧＰＰ  ＴＳ  ３６．３００で説明される。
【００１３】
ＵＥ１１０はダウンリンクとアップリンクを介してノードＢ１２０または１２２と通信してもよい。ダウンリンク（あるいはフォワードリンク）はノードＢからＵＥまでの通信リンクのことを示し、アップリンク（あるいはリバースリンク）はＵＥからノードＢまでの通信リンクのことを示す。ＵＥ１１０は固定型又は移動型でもよいし、移動局、端末、アクセス端末、加入者ユニット、局などと称されてもよい。ＵＥ１１０は、携帯電話、携帯情報端末（ＰＤＡ）、無線モデム、無線通信装置、携帯型のデバイス、ラップトップコンピュータ、コードレスホンなどかもしれない。
【００１４】
図２は、ＬＴＥにおいてユーザープレーンに関する複数例のプロトコルスタック２００を示す。ユーザープレーンは、ノードＢ１２０を介してＵＥ１１０とＳＡＥゲートウェイ１３０との間のトラフィックデータを運び、それはＵＥに関するサービングノードＢである。エンティティはそれぞれ、別のエンティティとの通信のためのプロトコルスタックを維持する。プロトコルスタックはそれぞれ典型的にはネットワークレイヤ（Ｌ３）、リンクレイヤ（Ｌ２）および物理レイヤ（Ｌ１）を含んでいる。ＵＥ１１０とＳＡＥゲートウェイ１３０は、ネットワークレイヤでインターネットプロトコル（ＩＰ）を用いて、データを交換してもよい。高次レイヤデータはＩＰパケットにおいてカプセル化されてもよく、それはノードＢ１２０によってＵＥ１１０とＳＡＥゲートウェイ１３０との間で交換されてもよい。
【００１５】
リンクレイヤは、無線技術に典型的に依存する。ＬＴＥについては、ＵＥ１１０に関するリンクレイヤは、ＰＤＣＰ、ＲＬＣ、およびメディアアクセス制御（ＭＡＣ）に関する３つのサブレイヤからなり、それはノードＢ１２０で終端となる。ＵＥ１１０は、さらに物理レイヤ（ＰＨＹ）でＥ−ＵＴＲＡエアリンクインターフェースを介してノードＢ１２０と通信する。ノードＢ１２０は、リンクと物理レイヤに関する技術依存のインタフェースおよびＩＰを介してＳＡＥゲートウェイ１３０と通信してもよい。
【００１６】
ＰＤＣＰは次のもののような機能および各種サービスを提供してもよい。  
・上位レイヤプロトコルヘッダーのヘッダー圧縮および解凍、および
・セキュリティのためのデータの暗号化および完全保護。
【００１７】
ＰＤＣＰは、公に利用可能である「発展型ユニバーサル地上無線アクセス（Ｅ−ＵＴＲＡ）；パケットデータ収束プロトコル（ＰＤＣＰ）規格」と題されて、３ＧＰＰ  ＴＳ  ３６．３２３で説明される。
【００１８】
ＲＬＣは次のような機能および各種サービスを提供してもよい。  
・送信機でのＲＬＣ ＳＤＵのセグメンテーションおよび連結、
・送信機によるＡｕｔｏｍａｔｉｃ  Ｒｅｐｅａｔ  ｒｅＱｕｅｓｔ（ＡＲＱ）を介しての誤り訂正、
・受信機での下位レイヤＳＤＵの複製検出、
・受信機でのＲＬＣ ＳＤＵの再順序付け、
・受信機での上位レイヤＰＤＵのシーケンス内配信。
【００１９】
ＲＬＣは、それは公に利用可能である「発展型ユニバーサル地上無線アクセス（Ｅ−ＵＴＲＡ）；無線リンク制御（ＲＬＣ）プロトコル規定」と題された、３ＧＰＰ  ＴＳ  ３６．３２２に説明される。ＲＬＣは、ＵＥ１１０とノードＢ１２０との間の無線リンクについて維持されてもよく、ＵＥが別のノードＢ１２２にハンドオーバされる場合にリセットされてもよい。ハンドオーバ中に、ＲＬＣはリセットされてもよく、複製検出の機能、ダウンリンクＲＬＣ ＳＤＵの再順序付け、およびアップリンクでの上位レイヤＰＤＵのシーケンス内配信は、ＰＤＣＰによって行なわれてもよい。
【００２０】
ＬＴＥにおける、ＰＤＣＰおよびＲＬＣによって提供されるサービスと機能は、他の無線技術における対応するプロトコルによって提供されてもよい。例えば、ｃｄｍａ２０００における、ＩＰアダプテーションレイヤおよび無線リンクプロトコル（ＲＬＰ）は、ＰＤＣＰとＲＬＣによって提供されるものに同様のサービスおよび機能をそれぞれ提供してもよい。
【００２１】
図３は送信機でＰＤＣＰとＲＬＣによって典型的な処理を示し、それはダウンリンクについてのデータ伝送についてノードＢ１２０またはアップリンクについてのデータ伝送に関するＵＥ１１０でもよい。ＰＤＣＰは高次レイヤプロトコルからＰＤＣＰ ＳＤＵを受信する。例えば、高次レイヤプロトコルはＩＰでもよく、ＰＤＣＰ ＳＤＵはそれぞれ１つ以上のＩＰパケットを含んでもよい。ＰＤＣＰは各ＰＤＣＰ ＳＤＵに連続して増加するＰＤＣＰ ＳＮを割り当てる。ある設計では、ＰＤＣＰは、各ＰＤＣＰ ＳＤＵに関するヘッダー圧縮、暗号化および完全保護を行ない、対応するＰＤＣＰ ＰＤＵを提供する。別の設計では、ＰＤＣＰ ＰＤＵは１つ以上のＰＤＣＰ ＳＤＵを含んでいてもよい。いずれにせよ、暗号化および完全保護については、ＰＤＣＰは、暗号化されている各データブロックに関するＣＯＵＮＴ値を用いる。データブロックは、ＰＤＣＰ ＳＤＵ、ＰＤＣＰ ＳＤＵのセグメント、または複数のＰＤＣＰ ＳＤＵの連結かもしれない。ＰＤＣＰは、暗号化および完全保護に関して、暗号の同期としてＣＯＵＮＴを用いる。ＣＯＵＮＴは、（ｉ）ＣＯＵＮＴの最上位ビット（ＭＳＢ）に関する超フレーム数（ＨＦＮ）および（ｉｉ）ＣＯＵＮＴの最下位ビット（ＬＳＢ）に関するＰＤＣＰ ＳＮとして表現されてもよい。ＣＯＵＮＴは、それぞれの暗号化されたブロックと共に、一度ＨＦＮをシグナリングし、その後ＰＤＣＰ ＳＮだけをシグナリングすることによって、しばしば伝えられる。ＣＯＵＮＴもハンドオーバで複製検出およびシーケンス内配信のために用いられてもよい。
【００２２】
ＲＬＣはＲＬＣ ＳＤＵと呼ばれるＰＤＣＰ ＰＤＵを受信する。一般的に、あるレイヤ／サブレイヤからのＰＤＵは、すぐ下のレイヤ／サブレイヤでＳＤＵと呼ばれてもよい。ＲＬＣはセグメント化および（または）ＲＬＣ ＳＤＵの連結を行ない、ＭＡＣに適切なサイズのＲＬＣ ＰＤＵを提供してもよい。セグメント化は、ＲＬＣセグメントと呼ばれるより小さなユニットへＲＬＣ ＳＤＵを分割するプロセスを示す。再セグメント化は、ＲＬＣセグメントと呼ばれるより小さなユニットへＲＬＣセグメントまたはＰＤＵを分割するプロセスを示す。ここで詳細な説明では、単純化のために、用語「セグメント化」は、ＲＬＣ ＰＤＵの再セグメント化と同様にＲＬＣ ＳＤＵのセグメント化を示すことが可能である。ＲＬＣセグメントはＲＬＣ ＳＤＵまたはＰＤＵの一部であり、セグメント化または再セグメント化から得られてもよい。ＲＬＣはまた、受信機によって誤って受信されたＲＬＣ ＳＤＵの全てまたは一部に関するＲＬＣ ＰＤＵを再送信してもよい。一般的に、下記に述べられるように、ＲＬＣ ＰＤＵはそれぞれ１つ以上のＲＬＣ ＳＤＵのそれぞれの全てまたは一部を含んでいてもよい。ＭＡＣは各ＲＬＣ ＰＤＵを処理し、対応するＭＡＣ ＰＤＵを生成してもよい。
【００２３】
ある態様では、ＰＤＣＰ ＳＮは、ヘッダーオーバーヘッドを縮小するためにＲＬＣで再度用いられてもよい。ＲＬＣは、複製検出、再順序付け、およびシーケンス内配信のような機能に関するＲＬＣ ＳＮを用いる。ＰＤＣＰが暗号化および他の機能のためにＰＤＣＰ ＳＮを既に生成し用いるので、ＰＤＣＰ ＳＮはＰＤＣＰとＲＬＣを横切ってＳＮオーバーヘッドを縮小するためにＲＬＣデータを扱うことに再度用いられてもよい。
【００２４】
ＰＤＣＰは、各ＰＤＣＰ ＰＤＵに連続して増加するＰＤＣＰ ＳＮを割り当て、ＲＬＣへそのＰＤＣＰ ＳＮと共にＰＤＣＰ ＰＤＵを渡してもよい。しかしながら、ＰＤＣＰ ＳＮはＰＤＣＰ ＰＤＵヘッダーに含まれていなくてもよい。一般的に、ＰＤＣＰ ＳＮは任意の適切な長さ、例えば５、７、１２、１６、３２または長さが他の何らかのビット数を有していてもよい。同様にＲＬＣ ＳＮは、ＰＤＣＰ ＳＮの長さに等しいか、もしくはより短い任意の適切な長さを有していてもよい。例えば、ＲＬＣ ＳＮは、５、７、１０、１２、３２または他の何らかのビット数の長さを有していてもよい。さらに、異なるＲＬＣ ＳＮ長は異なるタイプのＲＬＣ ＳＤＵのために用いられてもよい。さらに、ＲＬＣ ＳＮはサイズで制限されていてもよく、根本的なＣＯＵＮＴは３２ビットのように、より大きくてもよい。本明細書で説明された技術は、任意のＰＤＣＰ ＳＮ長、任意のＣＯＵＮＴ長および任意のＲＬＣ ＳＮ長のために用いられてもよい。明確にするために、以下の説明の多くは、１２ビットのＲＬＣ ＳＮ長を仮定する。ＲＬＣ ＳＮ長がＰＤＣＰ ＳＮ長より短い場合、ＰＤＣＰ ＳＮのＬＳＢ部分はＲＬＣ ＳＮのために用いられてもよく、ＰＤＣＰ ＳＮのＭＳＢ部分はコネクションセットアップで一度の信号で伝えられてもよい。十分なＰＤＣＰ ＳＮはコネクションセットアップでＵＥ１１０とノードＢ１２０との間で交換されてもよく、例えば、ＷＣＤＭＡでＳＴＡＲＴを交換するために使用されるのと同様な一つの機構を用いる。受信機は機構からＨＦＮを得、ＨＦＮとＰＤＣＰ ＳＮに基づいてＣＯＵＮＴを再構成してもよい。ここで説明では、ＲＬＣ ＳＮに関する追加は法Ｔの算術で行われ、ここでは１２ビットＲＬＣ ＳＮではＴ＝２１２である。このように、ＲＬＣ ＳＮは、Ｔ−１に達した後にゼロに包み込む。
【００２５】
ある設計では、ＲＬＣ ＰＤＵに関するＲＬＣ ＳＮは、以下のように、ＰＤＣＰ ＰＤＵに関するＰＤＣＰ ＳＮに基づいて決定されてもよい。  
ＲＬＣ ＳＮ  ＝  （ＰＤＣＰ ＳＮ  ＋Δ）  ｍｏｄ  Ｔ、Ｅｑ（１）
ここで、ΔはＰＤＣＰ ＳＮとＲＬＣ ＳＮとの間のＳＮ差またはデルタである。ＰＤＣＰ ＳＮは、ハンドオーバの間にさえ連続してインクリメントされてもよいが、ＲＬＣ ＳＮは新規のノードＢへの各ハンドオーバでリセットされてもよい。各ハンドオーバでは、現在のＰＤＣＰ ＳＮとリセットされたＲＬＣ ＳＮとの間の差は決定され、最新のＳＮデルタとして用いられてもよい。それは全通信セッションである可能性があるＰＤＣＰ ＳＮとＲＬＣ ＳＮがインクリメントされる間、同じＳＮデルタはＵＥとノードＢによって用いられてもよい。ＲＬＣ ＳＮも他の手法における（例えば他のオフセットによる）ＰＤＣＰ ＳＮから導き出されてもよい。
【００２６】
ＲＬＣは複数のＲＬＣセグメントへＲＬＣ ＳＤＵを分けてもよい。ＲＬＣ ＳＤＵの内でのＲＬＣアドレッシングは、サブシーケンス番号付けで実現されるか、またはバイトに基づくアドレッシングで実現されてもよい。サブシーケンス番号付けについては、複数のＲＬＣセグメントは異なるサブシーケンス番号を割り当てられてもよい。その後、ＲＬＣセグメントはそれぞれ、ＲＬＣセグメントに関するサブシーケンス番号と同様にＲＬＣ ＳＤＵに関するＲＬＣ ＳＮによってユニークに識別されてもよい。バイトに基づくアドレッシングについては、ＲＬＣ ＳＤＵにおけるバイトは連続して増加するバイトアドレスに割り当てられてもよい。その後、ＲＬＣセグメントはそれぞれ、ＲＬＣ ＳＤＵに関するＲＬＣ ＳＮ、ＲＬＣセグメントにおける第１のバイトのバイトアドレス、および、ＲＬＣセグメント長またはＲＬＣセグメントでの最終バイトのアドレスによってユニークに識別されてもよい。「バイト」、「オクテット」という用語は同意語で、区別なく用いられる。一般的に、ＲＬＣ ＳＤＵ内でのＲＬＣアドレッシングは、固定サイズまたは可変サイズのデータユニットへＲＬＣ ＳＤＵを分割し、これらのデータユニットに異なるアドレスを割り当てることにより実現されてもよい。データユニットは１バイト、複数のバイトなどでもよい。バイトに基づくアドレッシングを実装することは、より簡単である可能性があり、そのアドレッシングはサブシーケンス番号付けよりも再セグメント化に関する（例えば再送信に関する）より多くの柔軟性を提供する可能性がある。以下の説明は、ＲＬＣセグメントのバイトに基づくアドレッシングの使用を仮定する。
【００２７】
バイトに基づくアドレッシングについては、ＲＬＣセグメントは次のパラメータに基づいて定義されてもよい。  
・ＲＬＣ ＳＮ  −  ＲＬＣセグメントを含んでいるＲＬＣ ＳＤＵに関するシーケンス番号、
・セグメントオフセット（ＳＯ）  −  ＲＬＣセグメントにおける第１バイトのバイトアドレス、
・セグメント長（ＳＬ）  −  バイトを単位にして与えられたＲＬＣセグメントの長さ。
【００２８】
セグメント長も、ＲＬＣ ＰＤＵ内のＲＬＣ ＳＤＵの終端のバイトアドレスから与えられてもよい。セグメント長は、ＲＬＣが連結する場合に、ＲＬＣ ＳＤＵ境界を見つけるために用いられてもよい。
【００２９】
セグメントオフセットサイズおよびセグメント長サイズは最大のＲＬＣ ＳＤＵサイズに依存してもよい。以下の説明において仮定されるある設計では、最大のＲＬＣ ＳＤＵサイズは４０９６バイトであり、１２ビットはセグメントオフセットのために用いられてもよく、１２ビットもセグメント長のために用いられてもよい。他のセグメントオフセットとセグメント長サイズも用いられてもよい。
【００３０】
ある設計では、ＲＬＣ ＰＤＵはＲＬＣヘッダーおよびデータフィールドを含んでいる。データフィールドは、１つ以上のＲＬＣ ＳＤＵからデータを運んでもよい。データフィールドまたは全ＲＬＣ ＰＤＵの長さは、ＭＡＣヘッダーにおいて伝えられてもよい。ＲＬＣヘッダーは、ＲＬＣ ＰＤＵに関する（例えばＲＬＣ ＰＤＵに入れて運ばれた１つ以上のＲＬＣ ＳＤＵを記述するパラメータ）適切なパラメータのための種々のフィールドを含んでいてもよい。以下の説明では、ＲＬＣヘッダーでのフィールドは固定フィールドまたは拡張フィールドのいずれであってもよい。固定フィールドは、ＲＬＣヘッダーの中に常にあり、「Ｍ」として示される。拡張フィールドは、それが必要で「Ｏ」として示される場合、ＲＬＣヘッダーの中にある。固定および拡張フィールドはまた、それぞれ必須およびオプションフィールドと呼ばれてもよい。ＲＬＣ ＰＤＵの長さは、ＲＬＣ ＰＤＵを運ぶＭＡＣ ＰＤＵの長さに基づいて確認され（もしあれば）、このようにＲＬＣヘッダーから省略されてもよい。そうでなければ、ＲＬＣ ＰＤＵの長さはＲＬＣヘッダーに含まれていてもよい。
【００３１】
種々のＲＬＣヘッダーフォーマットは、ＲＬＣアドレッシングに関するＰＤＣＰ ＳＮの再使用をサポートするために定義されてもよい。いくつかの例のＲＬＣヘッダーフォーマットが下記に述べられる。
【００３２】
表１は、ＲＬＣ ＳＤＵの全てまたはセグメントを運ぶＲＬＣ ＰＤＵをサポートするＲＬＣヘッダーの設計を示す。この設計について連結は、ＲＬＣで行なわれず、ＭＡＣで必要に応じて行なわれてもよい。ＲＬＣヘッダーは、表１に与えられた固定の（Ｍ）および拡張（Ｏ）フィールドを含んでいてもよい。
【表１】
2010527544.tif 000003
【００３３】
セグメントオフセットフィールドは、ＲＬＣ ＳＤＵ内のＲＬＣセグメントの先頭を指示し、ＲＬＣセグメントにおいて第１バイトに対応するＲＬＣ ＳＤＵにおける開始バイトのバイトアドレスによって与えられてもよい。０のセグメントオフセットはＲＬＣ ＰＤＵがＲＬＣ ＳＤＵの始まりを含むことを意味するので、セグメント開始フィールドは必要ではない。表１に示される設計では、ＲＬＣヘッダーは、セグメントパラメータなしで２バイトのサイズ、セグメントパラメータありで４バイトのサイズを持っている。一般的に、連結のないＲＬＣヘッダーは、表１に示されるものよりも少ない、多い、または異なるフィールドを含んでいてもよい。さらに、フィールドは表１に与えられたものとは異なっているサイズを有していてもよい。
【００３４】
図４は、表１に示されるＲＬＣヘッダーを有するＲＬＣ ＰＤＵを示す。この例において、ＲＬＣ ＳＤＵはＮのＲＬＣ ＳＮを有する。ＲＬＣ ＰＤＵは、アドレスＢでのバイトに始まるＲＬＣ ＳＤＵのセグメントを運ぶ。ＲＬＣヘッダーについて、シーケンス番号（ＳＮ）フィールドはＮに設定され、セグメントエクステンション（ＳＥ）フィールドは「１」に設定され、セグメントオフセット（ＳＯ）フィールドはＢに設定される。データフィールドのサイズはＭＡＣヘッダー情報に基づいて確認することができる。ＲＬＣセグメントサイズは、Ｂのセグメントオフセットおよびデータフィールドサイズに基づいて決定されてもよい。
【００３５】
表２は、２つのＲＬＣセグメントまでを運ぶＲＬＣ ＰＤＵをサポートするＲＬＣヘッダーの設計を示す。ＲＬＣ ＰＤＵにおける第１のＲＬＣ ＳＤＵは全ＲＬＣ ＳＤＵまたはＲＬＣセグメントであるかもしれない。任意の数の全体のＲＬＣ ＳＤＵは第１のＲＬＣ ＳＤＵに続いてもよい。ＲＬＣ ＰＤＵにおける最後のＲＬＣ ＳＤＵは全ＲＬＣ ＳＤＵまたはＲＬＣセグメントかもしれない。ＲＬＣヘッダーは、表２に与えられた固定（Ｍ）および拡張（Ｏ）フィールドを含んでいてもよい。
【表２】
2010527544.tif 000004
【００３６】
表２に示される設計では、シーケンス番号フィールドは、ＲＬＣ ＰＤＵにおける第１のＲＬＣ ＳＤＵに関するＲＬＣ ＳＮを含んでいる。残りのＲＬＣ ＳＤＵのそれぞれに関するＲＬＣ ＳＮは、そのＲＬＣ ＳＤＵに関する長さインジケーターブロックにおいて伝えられる。ＲＬＣ ＰＤＵが第１のＲＬＣ ＳＤＵのセグメントを含んでいる場合、セグメントオフセットフィールドは、存在し、ＲＬＣ ＰＤＵにおける第１バイトに対応する第１のＲＬＣ ＳＤＵに開始バイトのアドレスを含んでいる。
【００３７】
表３は、表２に示されるＲＬＣヘッダーに関する長さインジケーターブロックの設計を示す。ヘッダー拡張フィールドが「１」に設定される場合、長さインジケーターブロックのＫインスタンスはＲＬＣヘッダーに含まれていてもよい（ここで一般にＫ≧１）。長さインジケーターブロックのインスタンスはそれぞれ関連するＲＬＣ ＳＤＵに関するパラメータを提供する。
【表３】
2010527544.tif 000005
【００３８】
ＲＬＣ ＰＤＵは、互いに接近しているＲＬＣ ＳＮによりＲＬＣ ＳＤＵを典型的には運ぶ。ヘッダーオーバーヘッドを省くために、（第１のＲＬＣ ＳＤＵを除いて）各ＲＬＣ ＳＤＵに関するＲＬＣ ＳＮは、前のＲＬＣ ＳＤＵに関するＲＬＣ ＳＮに関連のあるＳＮオフセットによって伝えられてもよい。ある設計では、ＲＬＣ ＳＤＵに関するＲＬＣ ＳＮは以下のように定義されてもよい。
【００３９】
ＲＬＣ＿ＳＮ（ｋ）＝ＲＬＣ＿ＳＮ（ｋ−１）＋ＳＮ＿Ｏｆｆｓｅｔ（ｋ），
ｋ＝１，…，Ｋ，                 Ｅｑ  （１）
ただし、SN_Offset(k)は、ＲＬＣ ＰＤＵにおけるｋ番目のＲＬＣ ＳＤＵに関するＳＮオフセットであり、RLC_SN(k)は、ＲＬＣ ＰＤＵにおけるｋ番目のＲＬＣ ＳＤＵに関するＲＬＣ ＳＮである。
【００４０】
ＳＮオフセットフィールドは、ＲＬＣ ＰＤＵが、再送信のための役立つ可能性のある不連続のＲＬＣ ＳＤＵを運ぶことを可能にする。０のＳＮオフセットは、ＲＬＣ ＰＤＵにおける同じＲＬＣ ＳＤＵの２つの不連続のセグメントを送信するために用いられてもよい。この場合、（ｋ−１）番目のＲＬＣ ＳＤＵに関するＲＬＣ ＳＮは、ＲＬＣ ＰＤＵにおけるｋ番目のＲＬＣ ＳＤＵに関するＲＬＣ ＳＮと同様である。ＳＮオフセットフィールドに関する３ビットでは、連続する２つのＲＬＣ ＳＤＵ間の最大のＳＮオフセットは７である。７より大きなＳＮオフセットは、０に設定されたセグメント長フィールドおよび適切な値に設定されたＳＮオフセットフィールドを有する１つ以上の追加／ダミーの長さインジケーターブロックを用いることにより得られてもよい。
【００４１】
別の設計では、シーケンス番号フィールドは、長さインジケーターブロックに含まれていてもよく、全体のＲＬＣ ＳＮを運んでもよい。さらに別の設計では、ＳＮオフセットフィールドまたはシーケンス番号フィールドは長さインジケーターブロックから除かれてもよい。この設計では、ＲＬＣ ＰＤＵは、連続して増加するＲＬＣ ＳＮにより連続的なＲＬＣ ＳＤＵを運んでもよい。
【００４２】
（第１のＲＬＣ ＳＤＵを除いて）各ＲＬＣ ＳＤＵの長さは、そのＲＬＣ ＳＤＵに関するセグメント長フィールドに基づいて決定されてもよい。全ＲＬＣ ＰＤＵの長さはＭＡＣヘッダー情報に基づいて決定されてもよい。その後、第１のＲＬＣ ＳＤＵの長さは、ＲＬＣ ＰＤＵの長さからそれぞれの続くＲＬＣ ＳＤＵの長さを減じることによって決定されてもよい。
【００４３】
表２および３に示される設計では、ＲＬＣヘッダーは、長さインジケーターブロックおよびセグメントオフセットフィールドなしで２バイトのサイズを持っている。ＲＬＣヘッダーは、各長さインジケーターブロックにつき２つの追加バイトを含んでおり、第１のＲＬＣ ＳＤＵが分割される場合、２つの追加バイトを含んでいる。一般的に、２つのＲＬＣセグメントまでの連結をサポートするＲＬＣヘッダーは、表２および３に示されるものよりも少ない、多い、または異なるフィールドを含んでもよい。例えば、連結が行なわれる場合、終了ビットフィールドはＲＬＣ ＰＤＵにとって、それがＲＬＣ ＳＤＵに関する最後のＲＬＣ ＰＤＵかどうか示すために、用いられてもよい。ＲＬＣヘッダーでのフィールドは表２および３に与えられたものとは異なっているサイズを有していてもよい。
【００４４】
図５は、表２および３に示されるＲＬＣヘッダーを有するＲＬＣ ＰＤＵを示す。この例において、ＲＬＣ ＰＤＵは、合計Ｋ＋１個のＲＬＣ ＳＤＵを運び、それはアドレスＢでのバイトに始まり、Ｋ−１個の全体のＲＬＣ ＳＤＵによって続き、最後のＲＬＣ ＳＤＵのセグメントで終了する第１のＲＬＣ ＳＤＵのセグメントを含んでいる。第１のＲＬＣ ＳＤＵにはＮ０のＲＬＣ ＳＮがある。第２のＲＬＣ ＳＤＵはＬ１の長さおよびＮ１＝Ｎ０＋Ｏ１のＲＬＣ ＳＮを持っている。ここで、Ｏ１は第１のＲＬＣ ＳＤＵに関するこのＲＬＣ ＳＤＵに関するＳＮオフセットである。それぞれの続くＲＬＣ ＳＤＵに関するＲＬＣ ＳＮは同じような手法において計算されてもよい。最後のＲＬＣ ＳＤＵのセグメントは、ＬＫの長さおよびＮｋ＝Ｎｋ−１＋ＯｋのＲＬＣ ＳＮを持っている。
【００４５】
ＲＬＣヘッダーについて、シーケンス番号（ＳＮ）フィールドはＮ０に設定され、セグメントエクステンション（ＳＥ）フィールドは「１」に設定され、セグメントオフセット（ＳＯ）フィールドは第１のＲＬＣ ＳＤＵについてＢに設定される。ヘッダー拡張フィールドは「１」（図５に図示せず）に設定され、ＲＬＣヘッダーは、Ｋ個の残りのＲＬＣ ＳＤＵに関するＫ個の長さインジケーターブロックを含んでいる。第２のＲＬＣ ＳＤＵに関する長さインジケーターブロックは、Ｌ１に設定されたセグメント長（ＳＬ）フィールド、「１」に設定された長さインジケーターエクステンション（ＬＩＥ）フィールド、およびＯ１に設定されたＳＮオフセット（ＳＮＯ）フィールドを有している。それぞれの続くＲＬＣ ＳＤＵに関する長さインジケーターブロックは同様な手法で設定されてもよい。最後のＲＬＣ ＳＤＵに関する長さインジケーターブロックは、ＬＫに設定されたセグメント長フィールド、「０」に設定された長さインジケーター拡張フィールド、およびＯＫに設定されたＳＮオフセットフィールドを有している。
【００４６】
表４は、任意の数のＲＬＣ ＳＤＵおよび任意の数のＲＬＣセグメントを運ぶＲＬＣ ＰＤＵをサポートするＲＬＣヘッダーの設計を示す。ＲＬＣヘッダーは、表４に与えられた固定（Ｍ）および拡張（Ｏ）フィールドを含んでいてもよい。
【表４】
2010527544.tif 000006
【００４７】
表４に示される設計では、シーケンス番号フィールドは、ＲＬＣ ＰＤＵにおける第１のＲＬＣ ＳＤＵに関するＲＬＣ ＳＮを含んでいる。残りのＲＬＣ ＳＤＵのそれぞれに関するＲＬＣ ＳＮは、そのＲＬＣ ＳＤＵに関する長さインジケーターブロックにおいて伝えられる。
【００４８】
表５は、表４に示されるＲＬＣヘッダーに関する長さインジケーターブロックの設計を示す。ヘッダー拡張フィールドが「１」に設定される場合、長さインジケーターブロックのＫ個のインスタンスはＲＬＣヘッダーに含まれていてもよい（ここで一般的にＫ≧１）。長さインジケーターブロックのインスタンスはそれぞれ関連するＲＬＣ ＳＤＵのためのパラメータを提供する。
【表５】
2010527544.tif 000007
【００４９】
（第１のＲＬＣ ＳＤＵを除いて）各ＲＬＣ ＳＤＵの長さは、そのＲＬＣ ＳＤＵに関するセグメント長フィールドに基づいて決定されてもよい。第１のＲＬＣ ＳＤＵの長さは、ＲＬＣ ＰＤＵの長さおよび残りのＲＬＣ ＳＤＵのそれぞれの長さに基づいて決定されてもよい。
【００５０】
表４および５に示される設計では、ＲＬＣヘッダーは、長さインジケーターブロックなしで２バイトのサイズを持っている。ＲＬＣヘッダーは、各長さインジケーターブロックにつき４つの追加バイトを含んでいる。一般的に、任意の数のＲＬＣセグメントの連結をサポートするＲＬＣヘッダーは、表４および５に示されるものよりも少ない、多い、または異なるフィールドを含んでいてもよい。さらに、フィールドは表４および５に与えられたものとは異なっているサイズを有していてもよい。
【００５１】
図６は、表４および５に示されるＲＬＣヘッダーを有するＲＬＣ ＰＤＵを示す。この例において、ＲＬＣ ＰＤＵは、合計Ｋ＋１個のＲＬＣ ＳＤＵを運び、ＲＬＣ ＳＤＵはそれぞれ全部もしくは分割されていてもよい。ＲＬＣ ＳＤＵは図５について以上説明されるように決定されてもよいＲＬＣ ＳＮを有している。図６に示される例において、ＲＬＣ ＰＤＵは、Ｂ０でバイトに始まりＬ０の長さを有する第１のＲＬＣ ＳＤＵのセグメントを運び、この後にＢ１でバイトに始まりＬ１の長さを有する第２のＲＬＣ ＳＤＵのセグメントなどが続き、ＢＫでのバイトに始まり、ＬＫの長さを有する最後のＲＬＣ ＳＤＵのセグメントで終了する。
【００５２】
ＲＬＣヘッダーについては、シーケンス番号（ＳＮ）フィールドは第１のＲＬＣ ＳＤＵについてＮ０に設定される。ヘッダー拡張フィールドは「１」（図６には図示せず）に設定され、ＲＬＣヘッダーは、Ｋ個の残りのＲＬＣ ＳＤＵに関するＫ個の長さインジケーターブロックを含んでいる。第２のＲＬＣ ＳＤＵに関する長さインジケーターブロックは、Ｌ１に設定されたセグメント長（ＳＬ）フィールド、Ｂ１に設定されたセグメントオフセット（ＳＯ）フィールド、「１」に設定された長さインジケーターエクステンション（ＬＩＥ）フィールド、およびＯ１に設定されたＳＮオフセット（ＳＮＯ）フィールドを有している。それぞれの続くＲＬＣ ＳＤＵに関する長さインジケーターブロックは同様な手法で設定されてもよい。最後のＲＬＣ ＳＤＵに関する長さインジケーターブロックは、ＬＫに設定されたセグメント長フィールド、ＢＫに設定されたセグメントオフセットフィールド、「０」に設定された長さインジケーター拡張フィールド、およびＯＫに設定されたＳＮオフセットフィールドを有している。
【００５３】
３つの特定のＲＬＣヘッダーフォーマットが以上説明された。他のＲＬＣヘッダーフォーマットも定義され、ＲＬＣ ＰＤＵのための用いられてもよい。ＲＬＣヘッダーフォーマットは連結をサポートしてもよいし、サポートしなくてもよい。連結がサポートされる場合、ＲＬＣヘッダーは、ＲＬＣ ＰＤＵで運ばれた各ＲＬＣ ＳＤＵまたはセグメントを記述するために適切なフィールドを含んでいてもよい。ＲＬＣヘッダーは、また他の機能をサポートするために他のフィールドを含んでいてもよい。
【００５４】
別の態様において、ＲＬＣ ＳＮは、ヘッダーオーバーヘッドを縮小するためにＰＤＣＰで再度用いられてもよい。ある設計では、ＲＬＣには次の特性があってもよい。  
・セグメンテーションはＲＬＣにおいてサポートされず、ＭＡＣにおいて行なわれてもよい、
・連結はＲＬＣにおいてサポートされず、異なるＲＬＣ ＳＮは各ＲＬＣ ＰＤＵのために用いられる。  
ＲＬＣは、可変サイズのＲＬＣ ＳＤＵを処理してもよく、ＬＴＥのような高スループット無線技術をサポートすることができてもよい。
【００５５】
図７は、送信機でＰＤＣＰに関する再度使用するＲＬＣ ＳＮの設計を示す。完全なＰＤＣＰ ＳＮは、適切な機構によってコネクションセットアップでＵＥ１１０とノードＢ１２０との間で交換されてもよい。ＰＤＣＰは、ＮのＰＤＣＰ ＳＮを有するＰＤＣＰ ＰＤＵを生成しＲＬＣに渡してもよい。ＲＬＣは、ＰＤＣＰ ＰＤＵに関して固定サイズまたは可変サイズの１つ以上の（Ｕ）ＲＬＣ ＰＤＵを生成し、各ＲＬＣ ＰＤＵにＲＬＣ ＳＮを割り当ててもよい。第１のＲＬＣ ＰＤＵに関するＲＬＣ ＳＮは、例えば、ゼロまたは非ゼロであるＳＮデルタにより式（１）において示されたように、ＰＤＣＰ ＳＮから導き出されてもよい。単純化のために、図７は、ゼロに等しいＳＮデルタを示す。ＲＬＣは、ＮのＲＬＣ ＳＮを有する第１のＲＬＣ ＰＤＵ、Ｎ＋１のＲＬＣ ＳＮを有する次のＲＬＣ ＰＤＵなど、Ｎ＋Ｕ−１のＲＬＣ ＳＮを有する最後のＲＬＣ ＰＤＵを割り当ててもよい。最後のＲＬＣ ＰＤＵは、それがＰＤＣＰ ＰＤＵに関する最後のＲＬＣ ＰＤＵであることを示すために、「１」に設定された終了ビット（ＥＢ）フィールドを有していてもよい。ＲＬＣは、ＰＤＣＰ ＰＤＵを送信するために、ＮからＮ＋Ｕ−１までのＵ個のＲＬＣ ＳＮを有するＲＬＣ ＰＤＵをＭＡＣに渡してもよい。
【００５６】
Ｕ個のＲＬＣ ＰＤＵがＰＤＣＰ ＰＤＵについて生成されることをＲＬＣが決めるとすぐに、ＲＬＣはＵをＰＤＣＰに通信してもよい。その後、ＰＤＣＰは、次のＰＤＣＰ ＰＤＵをＮ＋ＵのＰＤＣＰ ＳＮに割り当て、このＰＤＣＰ ＰＤＵを処理し、ＲＬＣに送信してもよい。ＲＬＣは、ＰＤＣＰ ＰＤＵに関する１つ以上の（Ｖ）ＲＬＣ ＰＤＵを生成し、Ｎ＋Ｕに始まる各ＲＬＣ ＰＤＵにＲＬＣ ＳＮを割り当ててもよい。ＰＤＣＰが、ＰＤＣＰ ＰＤＵに関するＮ＋Ｕの次の利用可能なＲＬＣ ＳＮを用いるので、ＲＬＣ ＰＤＵは連続して増加するＲＬＣ ＳＮを有し、ＲＬＣシーケンス番号付けにおいて穴またはオーバーラップもない。
【００５７】
受信機はコネクションセットアップで完全なＰＤＣＰ ＳＮを得てもよい。受信機のＲＬＣは、ＲＬＣ ＰＤＵごとにセグメント長および終了ビットフィールドによって指示されるように、ＭＡＣからＲＬＣ ＰＤＵを得、これらのＲＬＣ ＰＤＵを完全なＰＤＣＰ ＰＤＵへ組み立ててもよい。ＰＤＣＰは、ＰＤＣＰ ＰＤＵにおける第１のＲＬＣ ＰＤＵに関するＲＬＣ ＳＮに基づいて各ＰＤＣＰ ＰＤＵに関するＰＤＣＰ ＳＮを決定してもよい。このＲＬＣ ＳＮはＰＤＣＰ ＰＤＵと共にＰＤＣＰに渡されてもよい。受信機は、このようにＰＤＣＰ ＰＤＵにおける第１のＲＬＣ ＰＤＵに関するＲＬＣ ＳＮに基づいて正常に受信されたＰＤＣＰ ＰＤＵごとに、ＰＤＣＰ ＳＮを決定することができる。
【００５８】
図８は、シーケンス番号再利用でデータを送信するためのプロセス８００の設計を示す。プロセス８００は送信機によって行なわれてもよく、それは、ダウンリンクについてのデータ伝送のためのノードＢ、またはアップリンクについてのデータ伝送のためのＵＥでもよい。第１のプロトコルによって第１のＰＤＵに割り当てられた第１のシーケンス番号は、第２のプロトコル（ブロック８１０）で受信されてもよい。第１のプロトコルからの第１のシーケンス番号は第２のプロトコルで用いられてもよい（ブロック８２０）。
【００５９】
ある設計では、第１のプロトコルはプロトコルスタックにおいて第２のプロトコルより上位であってもよく、シーケンス番号は、プロトコルスタックに伝えられてもよい（例えば第１のプロトコルのＰＤＵの外部へ）。例えば、第１のプロトコルはＰＤＣＰであってもよいし、第２のプロトコルはＲＬＣでもよい。
【００６０】
ブロック８２０のある設計では、ブロック８３０で決定されるように、連結が行なわれない場合、第１のＰＤＵは第２のプロトコルでＳＤＵとして第１のプロトコルから受信されてもよい（ブロック８３２）。ＳＤＵに関する第２のシーケンス番号は第１のＰＤＵとデルタに関する第１のシーケンス番号に基づいて、例えば、式（１）において示されたように、決定されてもよい（ブロック８３４）。第２のプロトコルのシーケンス番号付けはハンドオーバまたはコネクションセットアップ、または他の瞬間でリセットされてもよい。デルタは、シーケンス番号付けをリセットした後に、第１のプロトコルに関するシーケンス番号と第２のプロトコルに関するシーケンス番号との間の差に基づいて決定されてもよい。ＳＤＵ内のデータは、ＳＤＵの先頭からのセグメントオフセットおよび第２のシーケンス番号に基づいてアドレスされてもよい。第２のＰＤＵはＳＤＵに基づいて第２のプロトコルで形成され、ＳＤＵの全てまたはセグメントを含んでもよい（ブロック８３６）。ヘッダーは第２のＰＤＵについて生成され、ＳＤＵの第２のシーケンス番号を含んでもよい（ブロック８３８）。第２のＰＤＵがＳＤＵのセグメントを含んでいる場合、ヘッダーはＳＤＵ内のセグメントの先頭（例えば第２のＰＤＵにおける第１のバイトに対応するＳＤＵにおける開始バイト）を指示するセグメントオフセットを含んでもよい。
【００６１】
ブロック８３０に決定されるように、連結が行なわれる場合、第１のプロトコルからの複数のＰＤＵは、第１のプロトコルによって異なるシーケンス番号を割り当てられている複数のＰＤＵのそれぞれと共に、第２のプロトコルで複数のＳＤＵとして受信されてもよい（ブロック８４２）。複数のＰＤＵは第１のＰＤＵを含んでもよく、複数のＳＤＵは第１のＰＤＵに対応する第１のＳＤＵを含んでもよい。複数のＳＤＵのそれぞれのシーケンス番号は、複数のＰＤＵおよびデルタの対応する１つに関するシーケンス番号に基づいて決定されてもよい（ブロック８４４）。（第１のＳＤＵを除く）各ＳＤＵに関するシーケンス番号オフセットは、ＳＤＵに関するシーケンス番号と前のＳＤＵのシーケンス番号との間の差に基づいて決定されてもよい（ブロック８４６）。
【００６２】
第２のＰＤＵは、複数のＳＤＵに基づいて第２のプロトコルで形成され、複数のＳＤＵの残りのものが後続する第１のＳＤＵを含んでもよい（ブロック８４８）。ある設計では、図５に示されるように、第２のＰＤＵは第１のＳＤＵ、最後のＳＤＵの全てまたは一部、ならびに最初のＳＤＵと最後のＳＤＵとの間の各ＳＤＵの全ての全てまたは一部を含んでもよい。別の設計では、図６に示されるように、第２のＰＤＵは複数のＳＤＵのそれぞれの全てまたは一部を含んでもよい。ヘッダーは、第２のＰＤＵについて生成され、第１のＳＤＵに関する第２のシーケンス番号および残りのＳＤＵのそれぞれに関するヘッダーブロック（例えば長さインジケーターブロック）を含んでもよい（ブロック８５０）。表２に示される設計について、ヘッダーは、第２のＰＤＵにおける第１のバイトに対応する第１のＳＤＵにおける開始バイトを指示するセグメントオフセットをさらに含んでいてもよい。残りのＳＤＵのそれぞれに関するヘッダーブロックは以下のものを含んでもよい。（ｉ）第２のＰＤＵにおいて送信されているＳＤＵからのデータ量を伝えるセグメント長、（ｉｉ）ＳＤＵに関するシーケンス番号オフセット、（ｉｉｉ）別のＳＤＵに関する別のヘッダーブロックがヘッダーに続くかどうか示す拡張ビット、（ｉｖ）第２のＰＤＵにおいて送信されているＳＤＵにおける開始バイトを指示するセグメントオフセット、および（または）（ｖ）他の何らかの情報。
【００６３】
別の設計では、第１のプロトコルはプロトコルスタックにおいて第２のプロトコルより下位でもよく、第１のシーケンス番号は第１のプロトコルから第２のプロトコルまで渡されてもよい。例えば、第１のプロトコルはＲＬＣでもよく、第２のプロトコルはＰＤＣＰでもよい。ある設計では、連続して増加するシーケンス番号は、第１のプロトコル（例えばＲＬＣ）で生成された各ＰＤＵに割り当てられてもよい。第１のプロトコルからのシーケンス番号は、第２のプロトコルで生成された各ＰＤＵに関する第２のプロトコル（例えばＰＤＣＰ）まで渡されてもよい。第２のプロトコルで生成された各ＰＤＵは、ＰＤＵの第１のプロトコルによって渡されたシーケンス番号に基づいて決定されたシーケンス番号が割り当てられてもよい。
【００６４】
図９は、シーケンス番号再利用でデータを送信するための装置９００の設計に示す。装置９００は、第１のプロトコルによって第１のＰＤＵに割り当てられた第１のシーケンス番号を受信するモジュール９１０、および第２のプロトコルで第１のプロトコルからの第１のシーケンス番号を用いるモジュール９２０を含んでいる。
【００６５】
図１０は、シーケンス番号再利用でデータを受信するためのプロセス１００の設計に示す。プロセス１０００は受信機によって行なわれてもよく、それは、ダウンリンクについてのデータ伝送に関するＵＥまたはアップリンクについてのデータ伝送に関するノードＢでもよい。第１のＰＤＵは第１のプロトコル（例えばＲＬＣ）で受信されてもよい（ブロック１０１２）。第１のＳＤＵは第１のＰＤＵに基づいて第１のプロトコルで形成されてもよい（ブロック１０１４）。第１のＳＤＵに関する第１のシーケンス番号は、第１のＰＤＵに関するヘッダーに基づいて（例えば、ヘッダーから得られて）決定されてもよい（ブロック１０１６）。第１のＳＤＵは第２のプロトコル（例えばＰＤＣＰ）での第２のＰＤＵとして受信されてもよい（ブロック１０１８）。第２のＰＤＵに関する第２のシーケンス番号は、第１のＳＤＵおよび場合によってはデルタに関する第１のシーケンス番号に基づいて決定されてもよい（ブロック１０２０）。
【００６６】
ある設計では、連結は行なわれない。ブロック１０１４について、第１のＰＤＵは、第１のＳＤＵの初め、またはヘッダーから得られたセグメントオフセットによって決定された位置のどちらかで始まる第１のＳＤＵにマッピングされてもよい。別の設計では、連結は行なわれる。ブロック１０１４について、複数のＳＤＵは、残りのＳＤＵが後続する第１のＳＤＵを含む複数のＳＤＵで、第１のＰＤＵに基づいて第１のプロトコルで形成されてもよい。各ＳＤＵのシーケンス番号は、第１のＳＤＵを除いて、（ヘッダーから得られてもよい）ＳＤＵに関するシーケンス番号オフセットおよび前のＳＤＵに関するシーケンス番号に基づいて決定されてもよい。各ＳＤＵに関するセグメント長および場合によってはセグメントオフセットも、ヘッダーから得られてもよい。その後、第１のＰＤＵからのデータは、各ＳＤＵに関するセグメント長およびセグメントオフセットによって指示されるように、複数のＳＤＵにマッピングされてもよい。
【００６７】
図１１は、シーケンス番号再利用でデータを受信するための装置１１００の設計を示す。装置１１００は、第１のプロトコルで第１のＰＤＵを受信するモジュール１１１２と、第１のＰＤＵに基づいて第１のプロトコルで第１のＳＤＵを形成するモジュール１１１４と、第１のＰＤＵのヘッダーに基づいて第１のＳＤＵに関する第１のシーケンス番号を決定するモジュール１１１６と、第２のプロトコルで第２のＰＤＵとして第１のＳＤＵを受信するモジュール１１１８と、第１のＳＤＵおよび場合によってはデルタに関する第１のシーケンス番号に基づいて第２のＰＤＵに関する第２のシーケンス番号を決定するモジュール１１２０を含んでいる。
【００６８】
図１２は、シーケンス番号オフセットによりデータを送信するプロセス１２００の設計を示す。プロセス１２００は送信機によって行なわれてもよい。複数のＳＤＵは、それぞれのシーケンス番号を割り当てられている各ＳＤＵと共に、受信されてもよい（例えばＲＬＣで）（ブロック１２１２）。複数のＳＤＵを具備するＰＤＵは生成されてもよい（ブロック１２１４）。複数のＳＤＵは連続するか連続しないシーケンス番号を有してもよい。シーケンス番号オフセットは、当該ＳＤＵに関するシーケンス番号と、ＰＤＵにおける前のＳＤＵに関するシーケンス番号との差に基づいて、第１のＳＤＵを除いてＳＤＵごとに決定されてもよい（ブロック１２１６）。ヘッダーはＰＤＵについて生成され、第１のＳＤＵに関するシーケンス番号と、ＰＤＵにおける残りの各ＳＤＵに関するシーケンス番号オフセットとを含んでもよい（ブロック１２１８）。
【００６９】
図１３は、シーケンス番号オフセットでデータを送信するための装置１３００の設計を示す。装置１３００は、それぞれのシーケンス番号を割り当てられている各ＳＤＵと共に複数のＳＤＵを受信するモジュール１３１２と、複数のＳＤＵを具備するＰＤＵを生成するモジュール１３１４と、各ＳＤＵに関するシーケンス番号オフセットを、当該ＳＤＵに関するシーケンス番号と、ＰＤＵにおける前のＳＤＵに関するシーケンス番号との差に基づいて決定するモジュール１３１６と、第１のＳＤＵに関するシーケンス番号とＰＤＵにおける残りのＳＤＵのそれぞれに関するシーケンス番号オフセットとを含んでもよい、ＰＤＵに関するヘッダーを生成するモジュール１３１８と、を含んでいる。
【００７０】
図１４は、シーケンス番号オフセットによりデータを受信するプロセス１４００の設計を示す。プロセス１４００は受信機によって行なわれてもよい。複数のＳＤＵを具備するＰＤＵは受信されてもよい（例えばＲＬＣで）（ブロック１４１２）。複数のＳＤＵは連続するかまたは連続しないシーケンス番号を有してもよい。ＰＤＵに関するヘッダーは、受信され第１のＳＤＵに関するシーケンス番号、およびＰＤＵにおける残りのＳＤＵのそれぞれに関するシーケンス番号オフセットを含んでもよい（ブロック１４１４）。複数のＳＤＵのそれぞれのシーケンス番号は、第１のＳＤＵに関するシーケンス番号、およびＰＤＵにおける残りのＳＤＵのそれぞれに関するシーケンス番号オフセットに基づいて決定されてもよい（ブロック１４１６）。例えば、残りのＳＤＵのそれぞれに関するシーケンス番号は、当該ＳＤＵに関するシーケンス番号オフセット、およびＰＤＵにおける前のＳＤＵに関するシーケンス番号に基づいて決定されてもよい。
【００７１】
図１５は、シーケンス番号オフセットによりデータを受信する装置１５００の設計を示す。装置１５００は、複数のＳＤＵを具備するＰＤＵを受信するモジュールと、ＰＤＵのヘッダーを受信するモジュール１５１４と、第１のＳＤＵに関するシーケンス番号および残りのＳＤＵのそれぞれに関するシーケンス番号オフセットに基づいて各ＳＤＵに関するシーケンス番号を決定するモジュール１５１６と、を含んでいる。
【００７２】
図１６は、ノードＢ１２０とＵＥ１１０の設計のブロック図を示す。この設計では、ノードＢ１２０はＴ本のアンテナ１６３４ａから１６３４ｔを装備していて、ＵＥ１１０はＲ本のアンテナ１６５２ａから１６５２ｒを装備している、ただし、一般に、Ｔ≧１とＲ≧１である。
【００７３】
ノードＢ１２０では、送信プロセッサ１６２０は、データソース１６１２から、１つ以上のＵＥに関するトラフィックデータを受信してもよい。送信プロセッサ１６２０は、出力データを得るために（例えば図２に示されたような）１セットのプロトコルに従って各ＵＥに関するトラフィックデータを処理してもよい。送信（ＴＸ）多入力多出力（ＭＩＭＯ）プロセッサ１６３０は、パイロットデータにより全てのＵＥに関する出力データを複数の化し、複数のデータを処理（例えばプリコード）し、Ｔ個の変調器（ＭＯＤ）１６３２ａから１６３２ｔにＴ個の出力シンボルストリームを提供してもよい。変調器１６３２はそれぞれ、出力チップストリームを得るためにそれぞれの（例えばＯＦＤＭ用の）出力シンボルストリームを処理してもよい。変調器１６３２はそれぞれ、ダウンリンク信号を得るためにさらに出力チップストリームを（例えば、アナログに変換して、増幅し、フィルターし、アップコンバートする）処理してもよい。変調器１６３２ａから１６３２ｔまでからのＴ個のダウンリンク信号は、Ｔ本のアンテナ１６３４ａから１６３４ｔを介してそれぞれ送信されてもよい。
【００７４】
ＵＥ１１０では、それぞれ、アンテナ１６５２ａから１６５２ｒはノードＢ１２０からダウンリンク信号を受信し、復調器（ＤＥＭＯＤ）１６５４ａから１６５４ｒに受信信号を提供してもよい。復調器１６５４はそれぞれ、サンプルを得るためにそれぞれの受信信号を（例えば、フィルターし、増幅し、ダウンコンバートし、デジタル化して）整え、受信シンボルを得るためにさらに（例えばＯＦＤＭ用の）サンプルを処理してもよい。ＭＩＭＯ検出器１６６０は全てのＲ個の復調器１６５４ａから１６５４ｒまでから受信シンボルを受信し処理し、検出されたシンボルを提供してもよい。受信プロセッサ１６７０はプロトコルのセットに従って検出されたシンボルを処理し、データ受信装置１６７２にＵＥ１１０に関する復号データを提供してもよい。一般的に、ＭＩＭＯ検出器１６６０および受信プロセッサ１６７０による処理は、ノードＢ１２０でのＴＸ ＭＩＭＯプロセッサ１６３０および送信プロセッサ１６２０による処理に相補的である。
【００７５】
アップリンクにおいて、ＵＥ１１０では、データソース１６７８からのトラフィックデータおよびシグナリングが送信プロセッサ１６８０によって処理され、さらに、（適用可能な場合には）ＴＸ ＭＩＭＯプロセッサ１６８２によって処理され、変調器１６５４ａから１６５４ｒによって整えられ、アンテナ１６５２ａから１６５２ｒを介して送信されてもよい。ノードＢ１２０では、ＵＥ１１０からのアップリンク信号はアンテナ１６３４によって受信され、復調器１６３２によって整えられ、ＭＩＭＯ検出器１６３６によって検出され、ノードＢ１２０によってＵＥ１１０に送信されたトラフィックデータおよびシグナリングを得るために受信プロセッサ１６３８によって処理されてもよい。
【００７６】
コントローラ／プロセッサ１６４０および１６９０は、ノードＢ１２０とＵＥ１１０での動作をそれぞれ指令してもよい。コントローラ／プロセッサ１６４０および１６９０はそれぞれ、図８におけるプロセス８００、図１０におけるプロセス１０００、図１２におけるプロセス１２００、図１４におけるプロセス１４００および（または）本明細書で説明された技術のための他のプロセスを実行してもよいし指図してもよい。メモリ１６４２および１６９２は、ノードＢ１２０とＵＥ１１０に関するデータとプログラムコードをそれぞれ記憶してもよい。スケジューラ１６４４はダウンリンクおよび（または）アップリンク送信に関するＵＥをスケジューリングし、スケジューリングされたＵＥに関するリソースの割当てを提供してもよい。
【００７７】
情報および信号が、様々な異なる技術および技法のうちのいずれかを使用して表され得ることを当業者は理解するであろう。例えば、以上の説明の至るところで参照され得るデータ、命令、コマンド、情報、信号、ビット、シンボル、およびチップは、電圧、電流、電磁波、磁場もしくは磁粒子、光場もしくは光粒子、またはそれらの任意の組合せによって表され得る。
【００７８】
当業者は、本明細書で開示される実施形態に関連して説明される様々な例示的な論理ブロック、モジュール、回路、およびアルゴリズムステップは、電子ハードウェア、コンピュータソフトウェア、またはそれら両方の組合せとして実装され得ることを認識するであろう。ハードウェアおよびソフトウェアのこの交換可能性を明瞭に例示するために、様々な例示的な成分、ブロック、モジュール、回路、およびステップが、一般的に、それらの機能性に関して上記に説明されている。かかる機能性がハードウェアとして実装されるかまたはソフトウェアとして実装されるかは、システム全体に課せられた特定の応用および設計の制約に依存する。当業者は、説明された機能性をそれぞれの特定の応用向けの様々な方法で実装する可能性があるが、かかる実装決定は、本開示の範囲からの逸脱を引き起こすと解釈されるべきではない。
【００７９】
本明細書に開示された実施形態に関して説明された様々な例示的な論理ブロック、モジュール、および回路は、汎用プロセッサ、デジタル信号プロセッサ（ＤＳＰ）、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラム可能なゲートアレイ信号（ＦＰＧＡ）またはその他のプログラム可能な論理素子、離散ゲートもしくはトランジスタ論理回路、離散的ハードウェア成分、あるいは本明細書で説明される機能を実行するように設計されたそれらの任意の組合せで実装または実行され得る。汎用プロセッサはマイクロプロセッサでもよいが、別の手法では、プロセッサは任意の通常のプロセッサ、コントローラ、マイクロコントローラ、または状態機械であってもよい。プロセッサは、コンピューティング装置の組合せ（例えば、ＤＳＰとマイクロプロセッサとの組合せ、複数のマイクロプロセッサ、ＤＳＰコアと連動する１以上のマイクロプロセッサ、または任意の他のそのような構成）として実装されてもよい。
【００８０】
本明細書で開示に関連して説明される方法またはアルゴリズムのステップは、ハードウェアの形で直接的に、プロセッサによって実行されるソフトウェアモジュールの形で、またはそれら２つの組合せの形で実施されてもよい。ソフトウェアモジュールは、ＲＡＭメモリ、フラッシュメモリ、ＲＯＭメモリ、ＥＰＲＯＭメモリ、ＥＥＰＲＯＭメモリ、レジスタ、ハードディスク、着脱可能ディスク、ＣＤ−ＲＯＭ、または当技術分野において知られている任意のその他の形式の記憶媒体の中に存在し得る。例示的な記憶媒体は、プロセッサが記憶媒体から情報を読み取り、記憶媒体に情報を書き込むことが可能であるようにプロセッサに結合される。別の手法では、記憶媒体はプロセッサに統合されてもよい。プロセッサおよび記憶媒体はＡＳＩＣ内に存在してもよい。ＡＳＩＣはユーザ端末内に存在してもよい。別の手法では、プロセッサおよび記憶媒体はユーザ端末における個別構成要素として存在してもよい。
【００８１】
１つ以上の例示的設計において、説明された機能は、ハードウェア、ソフトウェア、ファームウェア、あるいはそれらの任意の組み合わせで実装してもよい。ソフトウェアで実施される場合、機能は、１以上の命令またはコードとしてコンピュータ読取可能媒体上に記憶されること、または１以上の命令またはコードとしてコンピュータ読取可能媒体上で送信されることが可能である。コンピュータ読取可能媒体は、ある場所から別の場所へのコンピュータプログラムの転送を容易にするあらゆる媒体を含む通信媒体およびコンピュータ記憶媒体の両方を含む。記憶媒体は、汎用又は専用のコンピュータによってアクセスされ得る任意の利用可能な媒体であり得る。限定としてではなく、例として、かかるコンピュータ読取可能媒体は、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、ＣＤ−ＲＯＭ、もしくはその他の光ディスク記憶装置、磁気ディスク記憶装置もしくはその他の磁気記憶装置、または所望されるプログラムコード手段を命令またはデータ構造の形式で運ぶためまたは記憶するために使用されることが可能であり、かつ汎用または専用のコンピュータまたは汎用または専用のプロセッサによってアクセスされることが可能な任意のその他の媒体を具備し得る。また、任意の接続はコンピュータ読取可能媒体と適切に呼ばれる。例えば、ソフトウェアが同軸ケーブル、光ファイバケーブル、ツイストペア、デジタル加入者線（ＤＳＬ）、または赤外線、無線、およびマイクロ波などの無線技術を使用して、ウェブサイト、サーバ、またはその他の遠隔ソースから送信される場合、同軸ケーブル、光ファイバケーブル、ツイストペア、ＤＳＬ、または赤外線、無線、およびマイクロ波などの無線技術は媒体の定義に含まれる。本明細書で使用されるように、ディスク（ｄｉｓｋ）およびディスク（ｄｉｓｃ）は、コンパクトディスク（ＣＤ）、レーザディスク、光ディスク、デジタル多目的ディスク（ＤＶＤ）、フロッピー（登録商標）ディスクおよびブルーレイディスクを含み、ディスク（ｄｉｓｋ）は通常磁気によってデータを再生し、一方、ディスク（ｄｉｓｃ）はレーザを用いて光学的にデータを再生する。上記の組合せもコンピュータ読取可能媒体の範囲内に含まれるべきである。
【００８２】
本開示のこれまでの詳細な説明は、あらゆる当業者が、本開示をもたらし、本開示を用いて実施可能にするために提供される。本開示への種々の変更は、当業者であれば即座に明白になり、ここで定義された一般的な原理は、本開示の精神または範囲から逸脱することなく、他の変形に適用されてもよい。このように、本開示は、本明細書で説明された例および設計に限定されることは意図されておらず、ここで開示された原理および新規な特徴に相応しい最も広い範囲を与えられることである。
【図１】
2010527544.tif 000008
【図２】
2010527544.tif 000009
【図３】
2010527544.tif 000010
【図４】
2010527544.tif 000011
【図５】
2010527544.tif 000012
【図６】
2010527544.tif 000013
【図７】
2010527544.tif 000014
【図８】
2010527544.tif 000015
【図９】
2010527544.tif 000016
【図１０】
2010527544.tif 000017
【図１１】
2010527544.tif 000018
【図１２】
2010527544.tif 000019
【図１３】
2010527544.tif 000020
【図１４】
2010527544.tif 000021
【図１５】
2010527544.tif 000022
【図１６】
2010527544.tif 000023
【国際調査報告】
2010527544.tif 000024
2010527544.tif 000025
2010527544.tif 000026