(57)【要約】  本発明は、次のステップを含むデータ再送信方法を開示している。送信側が、物理層の送信フォーマットに従って、データセルの分割処理を実行すると共に、分割ブロックに分割ＩＤを記録する。分割ＩＤは、送信側に格納されたすべての分割ブロックから、分割ブロックを特定することができるものである。そして、上記送信側は、受信側が上記分割ブロックを正常に受信していないと判断したときに、分割ＩＤに基づいて、格納された分割ブロックから対応する分割ブロックを抽出し、再送信する。また、本発明は、データ送信装置およびデータ送信システムも提供する。
2009517930.tif 000002
【特許請求の範囲】
【請求項１】
送信側が、物理層の送信フォーマットに従ってデータユニットの分割処理を行うときに、上記分割ブロックに対して、該送信側が格納している全ての分割ブロックの中から分割ブロックを特定することができる、当該分割ブロックの分割ＩＤを記録するステップと、
上記送信側が、上記分割ブロックが受信側に正常に受信されていないと判断した場合に、上記分割ＩＤに基づいて、格納している分割ブロック中から、上記分割ブロックに対応する分割ブロックを抽出して再送信するステップとを含むことを特徴とするデータ再送信方法。
【請求項２】
物理フレーム内の各分割ブロックが有する分割ブロックの上記分割ＩＤは、上記受信側が上記物理フレームを受信した後で上記送信側に返信される受信確認メッセージに付加されることを特徴とする請求項１に記載のデータ再送信方法。
【請求項３】
上記送信側は、上記物理層の送信フォーマットのみに従って、送信するデータユニットの分割処理を行うことを特徴とする請求項１に記載のデータ再送信方法。
【請求項４】
上記分割ブロックの再送信前に、該分割ブロックのさらなる分割処理を上記物理層の送信フォーマットに従って行い、上記さらなる分割処理によって得られた分割ブロックの分割ＩＤを、当該分割ブロックの分割プロパティフィールドに記録することを特徴とする請求項１に記載のデータ再送信方法。
【請求項５】
分割ブロックの上記分割ＩＤを、当該分割ブロックに付加された分割プロパティフィールドに記録し、該分割プロパティフィールドは、上記分割したデータユニットのヘッダ情報の一部であることを特徴とする、請求項１から４の何れか１項に記載のデータ再送信方法。
【請求項６】
上記分割したデータユニットのヘッダ情報は、シーケンスナンバーと、当該データユニットのコンテンツが、データ情報であるか、制御情報であるかを示すコンテンツタイプとを含むことを特徴とする請求項５に記載のデータ再送信方法。
【請求項７】
上記分割プロパティフィールドは、当該分割ブロックの長さを示す情報、最後の分割ブロックであることを示す情報、当該分割ブロックの分割深さ、および上記分割による分割ブロック数をさらに含むことを特徴とする請求項６に記載のデータ再送信方法。
【請求項８】
上記分割ブロックの上記分割ＩＤは、上記データユニットの上記シーケンスナンバー、当該分割ブロックの分割深さ、および上記分割による分割ブロック数を含むことを特徴とする請求項７に記載のデータ再送信方法。
【請求項９】
上記受信側は、分割ブロックのシーケンスナンバー、分割深さ、および分割ブロック数に基づいて、上記受信した分割ブロックを配列して、上記送信側が分割した上記データユニットを復元することを特徴とする請求項８に記載のデータ再送信方法。
【請求項１０】
上記分割ブロック数を記録するフィールドのフィールド長は、上記分割ブロックの上記分割深さによって決定され、１回の分割による分割ブロック数は、各フィールド長に記録されることを特徴とする請求項８に記載のデータ再送信方法。
【請求項１１】
上記送信側が連結した上記物理フレームのフレームヘッダは、上記プロトコルのバージョンナンバー、スケジューリングの優先度、および送信のためのシーケンスナンバーを含むことを特徴とする請求項７に記載のデータ再送信方法。
【請求項１２】
上記分割プロパティフィールドは、上記分割ブロックの長さを示す情報、最後の分割であることを示す情報、および上記分割ブロック数をさらに含み、
上記分割ブロック数は、２つのフィールドによって表され、
第１フィールドは、現在の分割以前に行われた分割による分割ブロック数を表し、
第２フィールドは、上記現在の分割における分割ブロック数を表すことを特徴とする請求項６に記載のデータ再送信方法。
【請求項１３】
分割ブロックの上記分割ＩＤは、上記データユニットの上記シーケンスナンバーと、上記分割ブロック数とを含み、
上記受信側は、上記分割ブロックの上記シーケンスナンバーおよび上記分割ブロック数に基づいて、受信した上記データユニットの全分割ブロックを配列して、現在の分割に対して再度ナンバーを割り当てて上記分割ブロック数を更新し、上記送信側が分割した上記データユニットを復元することを特徴とする請求項１２に記載のデータ再送信方法。
【請求項１４】
上記送信側が連結した上記物理フレームのフレームヘッダは、上記プロトコルのバージョンナンバー、スケジューリングの優先度、および送信のためのシーケンスナンバーを含むことを特徴とする請求項１２に記載のデータ再送信方法。
【請求項１５】
上記データユニットは、レイヤ２プロトコル・データユニット、またはレイヤ２・サービス・データユニットであることを特徴とする請求項１に記載のデータ再送信方法。
【請求項１６】
物理層の送信フォーマットに従ってデータユニットの分割処理を行うときに、格納した全ての分割ブロックの中から分割ブロックを特定することができる、分割ブロックの分割ＩＤを当該分割ブロックに記録するモジュールと、
上記分割ブロックが受信側に正常に受信されなかったと判断したときに、上記分割ブロックの分割ＩＤに基づいて、上記格納した分割ブロックの中から、上記分割ブロックに対応する分割ブロックを抽出して再送信するモジュールとを含むことを特徴とするデータ送信装置。
【請求項１７】
上記分割ブロックが再送信されたときに、最初に送信された上記分割ブロックを必要に応じて再分割し、該再分割した分割ブロックに上記分割ブロックの分割ＩＤを記録するモジュールをさらに含むことを特徴とする請求項１６に記載のデータ送信装置。
【請求項１８】
プロトコル・データユニットとして送信されるサービス・データユニットをカプセル化する、または上記プロトコル・データユニットから上記サービス・データユニットを復元する第１モジュールと、
物理層の送信フォーマットに従って、上記第１モジュールがカプセル化した上記プロトコル・データユニットに分割処理を施すと共に、各分割ブロックを特定して、ハイブリッド・オートマティック・リピート・プロトコル・データユニットを形成して送信する、または上記分割ブロックの上記分割ＩＤに基づいて、上記ハイブリッド・オートマティック・リピート・プロトコルのデータユニットから上記プロトコル・データユニットを復元し、該復元したプロトコル・データユニットを上記第１モジュールに送信する第２モジュールと、
上記第２モジュールが送信した上記ハイブリッド・オートマティック・リピート・プロトコル・データユニットを処理して形成した物理フレームをワイヤレスリンクに送信する、または該ワイヤレスリンクから上記物理フレームを受信し、上記物理フレームから上記ハイブリッド・オートマティック・リピート・プロトコル・データユニットを復元して上記第２モジュールに送信する送受信モジュールとを含み、
上記第２モジュールは、上記分割ブロックの再送信が必要であると判断したときに、上記分割ブロックの上記分割ＩＤに基づいて、上記分割ブロックに対応する分割ブロックを格納している分割ブロックの中から抽出することを特徴とするデータ送信装置。
【請求項１９】
上記第２モジュールは、上記分割ブロックを再送信するときに、最初に送信された分割ブロックを再分割し、該再分割した分割ブロックに上記分割ＩＤを記録することを特徴とする請求項１８に記載のデータ送信装置。
【請求項２０】
物理フレームを送信するデータ送信装置であって、物理層の送信フォーマットに従ってデータユニットの分割処理を行うときに、分割ブロックに付加された分割プロパティフィールドに、自装置が格納している全ての分割ブロックの中から分割ブロックを特定することができる、当該分割ブロックの分割ＩＤを記録するデータ送信装置と、
上記物理フレームを受信して、上記データ送信装置に返信する受信確認メッセージに上記物理フレームの各分割ブロックの分割ＩＤを付加するデータ受信装置とを含み、
上記データ送信装置は、上記分割ブロックが上記データ受信装置に正常に受信されなかったと判断したときに、上記分割ブロックの上記分割ＩＤに基づいて、格納している分割ブロックの中から、上記分割ブロックに対応する分割ブロックを抽出して再送信することを特徴とするデータ送信システム。
【請求項２１】
上記データ送信装置は、上記データ送信装置が上記分割ブロックを再送信するときに、最初に送信された上記分割ブロックを再分割し、該再分割した分割ブロックに上記分割ＩＤを記録することを特徴とする請求項２０に記載のデータ送信システム。
【発明の詳細な説明】
【発明の詳細な説明】
【０００１】
〔発明の技術分野〕
本発明は、広くコンピュータ及び通信の分野に関し、特にデータ再送信方法、データ送信装置、およびデータ送信システムに関する。
【０００２】
〔背景〕
ＷＣＤＭＡシステムの技術仕様は、リリース９９、リリース４、リリース５、およびリリース６の段階を経てきた。リリース７の標準化は、近年始まったばかりである。その一方で、ＬＴＥ（Long Term Evolution）の研究は、次第に標準化の新しい注目の的となってきている。
【０００３】
リリース９９のシステムにおいて、専用チャネルは、アップリンクとダウンリンクに使用される。ここで、最大データレートは、３８４ｋｂｐｓに達する。リリース４の段階からは、制御とサービスとを分離するために、モバイル・サービス・スイッチ・センター（ＭＳＣ）が、ＭＳＣサーバとマルチメディア・ゲートウェイ（ＭＧＷ）とに分割されるようになった。リリース５の段階では、ＩＰマルチメディア・サブシステム（ＩＭＳ）の概念が導入された。ＩＭＳでは、ＩＰ送信レイヤに基づく無線アクセス技術である、高速ダウンリンクパケットアクセス（ＨＳＤＰＡ）が採用されることによって、ダウンリンクのデータレートが、１４．４Ｍｂｐｓにまで高まった。リリース６の段階では、高速アップリンクパケットアクセス（ＨＳＵＰＡ）技術が導入されることによって、アップリンクのデータレートが、５．７６Ｍｂｐｓにまで高まった。上記の規格は比較的安定してきている。現在議論されているリリース７プロトコルの目的は、リリース６をベースに微修正を行うことによって、システム性能を改善することにある。ＬＴＥは、システムフレームワークと物理層との観点から、全く新しいものであり、より高いデータレートとより良いサービスとをユーザに提供するためのものである。ＬＴＥのＵＭＴＳ ＵＴＲＡ（UMTS Terrestrial Radio Access）は、Ｅ−ＵＴＲＡと呼ばれている。
【０００４】
リリース７以前のワイヤレス・インターフェース・プロトコルには、３つの層がある。図１に示すように、レイヤ３は、ラジオ・リソース・コントロール層である。また、レイヤ２は、パケットデータ集中プロトコル（ＰＤＣＰ）層、ブロードキャスト／マルチブロードキャスト・コントロール（ＢＭＣ）層、ラジオ・リンク・コントロール（ＲＬＣ）層、およびメディア・アクセス・コントロール（ＭＡＣ）層に分けられる。そして、レイヤ１は、物理層である。アップリンク及びダウンリンクでは、パケット・サービスデータは、次の順序で送信される。すなわち、ＰＤＣＰ／ＢＭＣ層、ＲＬＣ層、ＭＡＣ層、物理層、相手側の物理層、相手側のＭＡＣ層、相手側のＲＬＣ層、相手側のＰＤＣＰ／ＢＭＣ層という順である。このとき、信号は、ＲＬＣ層から相手側のＲＬＣ層に直接伝達される。上位層から下位層へのデータ転送のプロセスでは、データが層を通過するたびに、その層に関連するデータヘッダがそのデータに付加される。そして、相手側のピア層に到達すると、対応するデータヘッダが削除され、データのコンテンツは次の上位層に送信される。データ送信のプロセスでは、上位層からのデータは、ＲＬＣ層および物理層によって分割（segmented）または連結（concatenated）される。ここで、上位層（ＲＬＣ ＳＤＵ）からのデータは、ＲＬＣ層によって、均等サイズのデータブロックに分割される。また、分割の後に、ヘッダ情報が上記データブロックに付加される。そして、ＲＬＣ ＰＤＵが形成され、ＭＡＣ層に送信される。物理層では、ＭＡＣ層からのデータが、送信に適切なサイズの物理フレームになるように、分割／連結される。受信側は、分割／連結の逆のプロセスを行う。ＲＬＣ層では、ＳＤＵを形成するすべてのデータが正確に受信された後で、ＲＬＣ ＳＤＵが上位層に送信される。
【０００５】
ＷＣＤＭＡシステムにおいて、データが何らかのエラーを伴って受信された場合には、送信機は、再送信を行うべきである。伝送エラーを伴うサービスデータは、３回まで再送信される。再送信には、上位層から下位層までが含まれる。具体的には、サーバからの再送信、ＲＬＣ層からの再送信、および物理層からの再送信が含まれる。上位のプロトコル層に再送信が起こった場合ほど、再送信に必要な時間はより長くなり、サービス遅延も重大になり、これによりユーザに不快感を与えてしまう。物理層において再送信されるものは、伝送エラーを伴う物理フレームである。一方、ＲＬＣ層では、伝送エラーを伴うＲＬＣ ＰＤＵが再送信され、また、サーバでは、ＴＣＰパケットが再送信される。
【０００６】
ＲＬＣ層には、３つのサービスモードがある。これらは、透過モード、非確認モード、および確認モードである。このうち、確認モードのサービスだけが、ＲＬＣ層によって再送信される。これに対して、他のモードにおいて送信されるデータは、エラーとなっていてもＲＬＣ層によって再送信されることはない。
【０００７】
リリース５及びリリース６では、ＭＡＣ−ｈｓおよびＭＡＣ−ｅエンティティがＭＡＣ層に導入されている。可能な限り効率良くデータを伝送するために、伝送レートとパケットサイズが動的に調整されるように、送信フォーマットが、物理チャネルの特性とスケジューリング情報とに従って選択されるようにすることもできる。
【０００８】
物理フレームが物理層によって再送信されるときには、先の伝送におけるデータフォーマットが継続して使用される。換言すれば、先に伝送された物理フレームがそのまま再送信される。ＲＬＣ ＰＤＵが再送信されるときは、再送信されるものはＲＬＣ ＰＤＵであるが、これは、物理層にとっては新しいパケットである。そこで、物理層は、前回送信されたＰＤＵの送信フォーマットに拘らず、そのパケットのための送信フォーマットを再選択する。サーバが再送信したＴＣＰパケットもまた、物理層にとっては新しいパケットである。ＭＡＣ層は、物理チャネルの特性およびスケジューリング情報に従って送信フォーマットを選択する。
【０００９】
現在のプロトコルでは、ＲＬＣ ＰＤＵおよびＭＡＣ−ｈｓ／ＭＡＣ−ｅ ＰＤＵが形成されるときには、全てのデータを分割／連結する必要がある。
【００１０】
ＲＬＣ層では、ＲＬＣ ＳＤＵは、上位層が設定したＲＬＣ ＰＤＵのサイズに従って分割され、分割されたＲＬＣ ＳＤＵには、分割の際にＰＤＵが取得した、受信および再送信のＩＤとして機能する番号が一律に付される。現在のプロトコルでは、ＲＬＣ ＰＤＵの番号は、シーケンスナンバーと呼ばれる。確認モードのシーケンスナンバーの長さは、１２ビットであり、非確認モードのシーケンスナンバーの長さは７ビットである。
【００１１】
現在のプロトコルでは、ＲＬＣ ＰＤＵのサイズは、対応するＲＬＣエンティティがサービスとして設定されるときに定義される。ＲＬＣ ＳＤＵが分割される際に、分割後のデータブロックのサイズがＰＤＵのサイズより小さくなる場合には、ＰＤＵのサイズを確実に一定にするために、パディングビットがデータブロックに付加される。
【００１２】
ＨＳＤＰＡ／ＨＳＵＰＡシステムでは、ＭＡＣ−ｄエンティティによってＭＡＣデータヘッダがＲＬＣ ＰＤＵに付加されて、ＭＡＣ−ｄ ＰＤＵが形成される。その後、それらは、ＭＡＣ−ｈｓ／ＭＡＣ−ｅエンティティによって連結され、さらにデータヘッダが付加されて、物理フレームが形成される。物理フレームのサイズは、送信フォーマットによって決定される。ＭＡＣ−ｄ ＰＤＵによって連結された後に取得されたデータブロックのサイズが、物理フレームのサイズより小さい場合には、その物理フレームを形成するために、パディングビットを付加してもよい。これらのデータフローとフォーマットとは、図２に示されている。図中の変数の説明は、下記の表１の通りである。
【００１３】
【表１】
2009517930.tif 000003
ＷＣＤＭＡ標準の進化に伴い、ＬＴＥによってＷＣＤＭＡシステムのプロトコル・フレームワークが最適化および簡略化されることが見込まれる。この分野では、現在のプロトコルにおける２度の分割／連結を簡易化するべきであると提案されている。換言すれば、ＲＬＣ ＰＤＵのサイズを定義する代わりに、ＲＬＣ ＰＤＵを上位層のデータのペイロードから直接形成することが提案されている。ＴＣＰ／ＩＰサービスでは、ＲＬＣ ＰＤＵのサイズは、ＩＰパケットのサイズと等しい。分割の機能は、ＲＬＣ ＰＤＵを分割／連結によって物理フレームを形成するために、ＭＡＣ層に追加されている。つまり、分割／連結は、システム全体において、ＭＡＣ層で１度だけ実行される。これにより、システム構造を簡易化すること、システムが物理層の変化に素早く適応すること、およびエアー・インターフェースで伝送されるデータに付加されるビット数を減らすことができる。このような提案されたプロトコル構造において、物理層で再送信されるものは、ＭＡＣ層の分割／連結の後に形成された物理層フレームであり、ＲＬＣ層において再送信されるものは、ＲＬＣ ＰＤＵ全体である。その代わりに、上位層からのデータのペイロードは、その送信フォーマットに従って、ＲＬＣ ＰＤＵに直接分割され、ＭＡＣ層で連結される。ＲＬＣ層とＭＡＣ層とが同じエンティティにあるときは、２つの方法は同等である。
【００１４】
１度だけ分割を行う上記方法によれば、送信するパディングビット数を減らすことが可能になるが、この方法には問題がある。すなわち、ＲＬＣ ＰＤＵは、物理層において、先の伝送のための複数の物理フレームに分割される。ここで、物理層が、送信を行った後に、１つの物理フレームに含まれるデータのみにエラーが存在するときには、送信機がエラーの存在する物理フレームを識別することができないために、ＲＬＣ層では、全てのＲＬＣ ＰＤＵを再送信する必要が生じる。このため、ＲＬＣ ＰＤＵのサイズが大きいときには、エアー・インターフェースの伝送効率は下がり、システムリソースが浪費されてしまう。
【００１５】
〔発明の要約〕
本発明は、関連技術において、物理層における送信が失敗したときに、データの送信側が、分割前のデータユニット全体を再送信する必要があり、これにより伝送効率が低下し、またシステムリソースが浪費されるという問題を解決するための、データ再送信方法、装置、およびシステムを提供する。
【００１６】
本発明に係るデータ再送信方法は、
送信側が、物理層の送信フォーマットに従ってデータユニットの分割処理を行うときに、上記分割ブロックに対して、上記送信側が格納している全ての分割ブロックの中から分割ブロックを特定することができる、当該分割ブロックの分割ＩＤを記録するステップと、
上記送信側が、上記分割ブロックが受信側に正常に受信されていないと判断した場合に、上記送信側が、上記分割ＩＤに基づいて、上記格納された分割ブロックの中から、上記分割ブロックに対応する分割ブロックを抽出して再送信するステップとを含む。
【００１７】
また、本発明に係るデータ送信装置は、
プロトコル・データユニットとして送信するサービス・データユニットをカプセル化する、または上記プロトコル・データユニットから上記サービス・データユニットを復元する第１モジュールと、
物理層の送信フォーマットに従って、上記第１モジュールがカプセル化した上記プロトコル・データユニットに分割処理を施すと共に、各分割ブロックを特定して、ハイブリッド・オートマティック・リピート・プロトコル・データユニットを形成して送信する、または上記分割ブロックの上記分割ＩＤに基づいて、上記ハイブリッド・オートマティック・リピート・プロトコルのデータユニットから上記プロトコル・データユニットを復元し、該復元したプロトコル・データユニットを上記第１モジュールに送信する第２モジュールと、
上記第２モジュールが送信した上記ハイブリッド・オートマティック・リピート・プロトコル・データユニットを処理して形成した物理フレームをワイヤレスリンクに送信する、または該ワイヤレスリンクから上記物理フレームを受信し、上記物理フレームから上記ハイブリッド・オートマティック・リピート・プロトコル・データユニットを復元して上記第２モジュールに送信する送受信モジュールとを含み、
上記第２モジュールは、上記分割ブロックの再送信が必要であると判断したときに、上記分割ブロックの上記分割ＩＤに基づいて、上記分割ブロックに対応する分割ブロックを上記格納された分割ブロックの中から抽出する。
【００１８】
また、本発明に係るデータ送信装置は、
物理層の送信フォーマットに従ってデータユニットの分割処理が行われるときに、格納された全ての分割ブロックの中から分割ブロックを特定することができる、分割ブロックの分割ＩＤを当該分割ブロックに記録するモジュールと、
上記分割ブロックが受信側に正常に受信されなかったと判断したときに、上記分割ブロックの分割ＩＤに基づいて、上記格納された分割ブロックの中から、上記分割ブロックに対応する分割ブロックを抽出して再送信するモジュールとを含む。
【００１９】
また、本発明に係るデータ送信システムは、
物理フレームを送信するデータ送信装置であって、物理層の送信フォーマットに従ってデータユニットの分割処理が行われるときに、分割ブロックに付加された分割プロパティフィールドに、自装置が格納している全ての分割ブロックの中から分割ブロックを特定することができる、当該分割ブロックの分割ＩＤを記録するデータ送信装置と、
上記物理フレームを受信して、上記データ送信装置に返信する受信確認メッセージに上記物理フレームの各分割ブロックの分割ＩＤを付加するデータ受信装置とを含み、
上記データ送信装置は、上記分割ブロックが上記データ受信装置に正常に受信されなかったと判断したときに、上記分割ブロックの上記分割ＩＤに基づいて、格納している分割ブロックの中から、上記分割ブロックに対応する分割ブロックを抽出して再送信する。
【００２０】
本発明の一実施形態では、分割／連結されたデータを特定するので、送信の際に分割ブロックの一部がエラーとなった場合に、その分割ブロックのみを再送信すればよい。これにより、送信の際に一部のデータのみがエラーとなる場合に、大量のデータブロックを再送信する必要がなくなる。したがって、システムリソースの浪費を低減し、また複数の物理フレームに分割された大きなデータブロックを再送信することによる再送信時間の長大化という問題を解決する。
【００２１】
〔図面の簡単な説明〕
図１は、関連技術における、ワイヤレス・インターフェース・プロトコルのフレームワークを示す図である。
【００２２】
図２は、関連技術における、エアー・インターフェース・プロトコルのためのデータフローおよびモードを示す図である。
【００２３】
図３は、本発明の一実施形態を示すものであり、データ再送信のフローチャートである。
【００２４】
図４は、本発明の一実施形態を示すものであり、エアー・インターフェース・プロトコルのデータフローを示す図である。
【００２５】
図５および図６は、本発明の一実施形態を示すものであり、エアー・インターフェース・プロトコルのデータフローおよびモードを示す図である。
【００２６】
図７は、本発明の一実施形態を示すものであり、データ送信システムおよびデータ送信装置の構成を示す図である。
【００２７】
〔詳細な説明〕
本実施形態では、ＷＣＤＭＡシステムを例にデータ送信について説明する。
【００２８】
本発明の実施形態では、物理層における送信において、分割ブロックにエラーが発生したときに、全てのデータユニットを再送することを避けるために、データユニットが、物理層の送信フォーマットに従って複数の分割ブロックに分割された後で、各分割ブロックに付加された分割プロパティフィールドに分割ＩＤが記録される。この分割ＩＤによって、送信機に格納されている全ての分割ブロックの中から、分割ブロックを特定することもできる。すなわち、各分割ブロックは、個別に識別される。これにより、物理層の送信において、データユニットの分割の後で、連結された物理フレームにエラーがあるときにも、分割ＩＤに従って、格納されている分割ブロックの中から、エラーのある分割ブロックに一致するものを回収しさえすればよい。
【００２９】
上記データユニットは、レイヤ２プロトコル・データユニット（ＰＤＵ）であってもよいし、レイヤ２サービス・データユニット（ＳＤＵ）であってもよい。以下では、レイヤ２プロトコル・データユニットを例に詳細に説明する。
【００３０】
分割されたＰＤＵは、２度分割／連結を行う方法に従って、ラジオ・リンク・コントロール（ＲＬＣ）層にて分割された後のＰＤＵであってもよいし、１度分割／連結を行う方法に従って、ＲＬＣ層にてカプセル化（encapsulation）された後のＰＤＵであってもよい。
【００３１】
図３に示すように、処理のフローは、上位層のデータの受信に始まり、送信側のデータの再送信で終わる（以下では、一例として高速ダウンリンク・シェア・チャンネル（ＨＳ−ＤＳＣＨ）データフローを示す）。
【００３２】
ステップ１００：送信側が上位層から送信されたＳＤＵにヘッダ情報を付加してＬ２ＰＤＵを形成する。このヘッダ情報には、少なくともシーケンスナンバーが含まれる。
【００３３】
ステップ１１０：送信側のハイブリッドＡＲＱ（ＨＡＲＱ：Hybrid Automatic Repeat Request）エンティティが、Ｌ２ＰＤＵのサイズおよび入手可能な物理送信フォーマットに基づいて、Ｌ２ＰＤＵを分割する。
【００３４】
上記の分割には、１回以上の分割が含まれると共に、０回の分割（すなわち分割を行わない場合）も含まれる。
【００３５】
ステップ１２０：各分割ブロックの分割後に、分割プロパティフィールド（すなわち、分割ブロックのヘッダ情報）の付加および格納が行われる。これにより、分割プロパティフィールドには、各分割ブロックの分割ＩＤが記録される。この分割ＩＤは、格納される全ての分割ブロックの中から特定の分割ブロックを識別し得るものである。
【００３６】
ステップ１３０：ＭＡＣ層で選択された送信フォーマットに従って、上記の分割ブロックの連結が必要であるか否かが判断され、ＨＡＲＱ関連情報ヘッダが付加されてＨＡＲＱ ＰＤＵが形成される。そして、ＨＡＲＱ ＰＤＵが、物理層に送信される。
【００３７】
連結処理では、必要に応じて冗長ビットを付加してもよい。
【００３８】
ステップ１４０：ＨＡＲＱに対してベースバンド処理が行われた後で、送信側の物理層が、物理フレームを形成してワイヤレスリンクに送信する。
【００３９】
ステップ１５０：受信側が、送信側からのポーリングリクエストに対して、上記分割ＩＤを含む受信確認メッセージを返信する。ここで返信される上記分割ＩＤは、正常な受信か、正常でない受信かを示している。
【００４０】
ステップ１６０：分割ＩＤが配列された後に、送信側が、１つのデータユニット中のある１つの分割ブロック（または、複数の分割ブロック。例えば、２つの分割ブロック）に送信エラーがあり、その分割ブロックを再送信する必要があると判断する。
【００４１】
ステップ１７０：ＨＡＲＱエンティティは、上記分割ＩＤに基づいて、格納している分割ブロックの中から、上記分割ブロックを抽出し、それを他の分割ブロックと連結してＨＡＲＱ ＰＤＵを形成し、これを物理層に送信する。
【００４２】
再送信を要する分割ブロックについては、再分割を行い、再分割後に他の分割ブロックと連結して新しいＨＡＲＱ ＰＤＵを形成するようにしてもよい。
【００４３】
ステップ１８０：ステップ１７０で形成されたＨＡＲＱ ＰＤＵに対してベースバンド処理が行われた後に、送信側は、物理層において物理フレームを形成し、形成した物理フレームをワイヤレスリンクに送信する。
【００４４】
受信側では、ＨＡＲＱエンティティが、正しく受信した分割ブロックを、分割ＩＤに従って配列する。また、Ｌ２ ＰＤＵが復元されてＬ２層に送信される。これは、送信側で行われる処理と逆の処理である。送信側および受信側のデータフローを図４に示している。
【００４５】
以下では、分割／連結後におけるＰＤＵおよびデータフォーマットについて述べる。
【００４６】
図５に示すように、Ｌ２ ＰＤＵのデータフォーマットは、ヘッダ情報と上位層からのＳＤＵとで構成されている。そして、ヘッダ情報には、以下の情報が含まれている。
【００４７】
Ｔｙｐｅ：ＰＤＵの中身が制御情報であるか、データ情報であるか、また再送信データであるかを示す。２ビット。
【００４８】
ＳＮ：Ｌ２ ＰＤＵを特定する。１２ビット。
【００４９】
ＨＡＲＱ ＰＤＵのデータフォーマットには、以下の情報が含まれている。
【００５０】
ＶＦおよびＴＳＮは、それぞれプロトコル・バージョンナンバーおよびＨＡＲＱ送信シーケンスナンバーであり、現在のプロトコルに従う。１ビット。
【００５１】
ＳＰ（スケジュール優先度）：スケジューリングの優先度を示す数字。３ビット。
【００５２】
ＰＡＤ（パディング）：ＨＡＲＱ ＰＤＵの形成時に、送信するデータのサイズが、送信フォーマットが許容する下限よりも小さいときに付加されるパディングビットおよび冗長ビット。
【００５３】
Ｈｎ：ＨＡＲＱ ＰＤＵに含まれるｎ番目のＬ２ ＰＤＵ分割ブロックのヘッダ情報。Ｈｎの最大長は５４ビットであり、最小長は１５ビットである。また、Ｈｎは、下記のサブ項目を含む。
【００５４】
ＬＩ（長さ指標）：現在のＬ２ ＰＤＵの分割ブロックの長さを示すものである。１２ビット。
【００５５】
Ｆ：ＰＤＵが、現在の分割深さ（segmentation depth）における最後の分割ブロックであるか否かを示す。１ビット。
【００５６】
ＳＤ（分割深さ）：ＰＤＵ分割ブロックの深さを示す。すなわち、分割が行われた回数を示す。例えば、最初に送信されたＬ２ ＰＤＵのＳＤが０であれば、分割が行われておらず、当該Ｌ２ ＰＤＵは、ＰＤＵ全体を含んでいることを示す。また、２回目の送信では、分割が必要になるので、ＳＤは１となる。以下、同様である。ＳＤは、２〜３ビットであり、ＳＤ＝０であればＦは１である。
【００５７】
ＳＳＮｍ（分割シーケンスナンバー）：ｍ回目の分割における分割ブロックの分割ブロック数を示す。２〜３ビット。
【００５８】
このような構成のＨＡＲＱ ＰＤＵでは、ＳＤによってＳＳＮの数が決定される。ＳＤ＝０であれば、分割は行われていないので、ＳＳＮフィールドは存在しない。ＳＤ＝１であれば、分割が１回行われているので、ＳＳＮフィールドは、ＳＳＮ１（３ビット）のみを有する。以下、同様である。ＳＳＮフィールドの長さは、ＳＤの値によって決定されるので、柔軟な構成が可能となる。
【００５９】
このフォーマットでは、分割ＩＤは、ＳＮ、ＳＤ、およびＳＳＮで構成される。
【００６０】
ＳＮ、ＳＤ、およびＳＳＮの構成、およびデータ再送信処理については、図５に示すフォーマットを用い、具体例を挙げて説明する。
【００６１】
最初に送信されるＬ２ ＰＤＵ（ＳＮ＝Ｍ）は、ＨＡＲＱ ＰＤＵが形成されたときに、３つのブロックに分割され、分割された３つのブロックは、順番に送信される。これら３つのブロックのＳＮ＝Ｍであり、ＳＤ＝００１である。また、ＳＳＮは、それぞれ０００、００１、および０１０であり、ＬＩエンティティは、それらの真の長さを示している。受信側では、ＳＮ、ＳＤ、およびＳＳＮに基づいて、受信したＬ２ ＰＤＵを配列してＳＤＵを復元してもよい。
【００６２】
確認モードにおけるサービスでは、送信側は、確認を示す情報が受信されない場合には、ＨＡＲＱ ＰＤＵを形成する間に分割されたＬ２ ＰＤＵ分割ブロックの消去を行わない。ＳＮ、ＳＤ、ＳＳＮ、およびＬＩは、受信側からのフィードバック情報に含まれる。送信側は、フィードバック情報に含まれるＳＮ、ＳＤ、ＳＳＮ、およびＬＩに基づいて再送信するＬ２ ＰＤＵ分割ブロックを選択してもよい。再送信を要するＬ２ ＰＤＵ分割ブロックが、ＨＡＲＱ ＰＤＵの形成の際に再分割を要する場合には、再分割された分割ブロックのために、新しいＳＤ、ＳＳＮ、およびＬＩヘッダ情報を作成する必要があり、送信側はこれらの新しいＳＤ、ＳＳＮ、およびＬＩ情報も記録する。
【００６３】
上記の例における通信では、最初に送信されるＬ２ ＰＤＵの１番目と３番目の部分が正常に受信され、２番目の部分が再送信を要することを想定している。２番目の部分を再送信する処理では、オリジナルのヘッダ情報が、ＳＮ＝Ｍ、ＳＤ＝００１、およびＳＳＮ＝００１である分割ブロックを、２つのブロックに再分割し、２つのＨＡＲＱ ＰＤＵとして送信する必要がある。そして、新たに分割された２つのＬ２ ＰＤＵ分割ブロックは、ＳＮ＝Ｍ、ＳＤ＝０１０であり、ＳＳＮはそれぞれ、００１ ０００、および００１ ００１である。このヘッダ情報から、データブロックがＳＮ＝ＭのＬ２ ＰＤＵに属し、２回分割されており、各々が全体として２つのブロックに分割されていることが分かる。ここで、新規分割データの２つの部分が、正常に受信された場合には、受信側で正常に受信したデータブロックの数は４になる。上記ヘッダ情報を表２に示している。
【００６４】
【表２】
2009517930.tif 000004
受信側は、ヘッダ情報に基づいて受信データを配列させてＳＤＵ全体を復元してもよい。
【００６５】
ＨＡＲＱ ＰＤＵのＬ２ ＰＤＵ分割ブロックｎにおけるヘッダ情報Ｈｎは、図６に示すフォーマットを用いて定義してもよい。
【００６６】
ＳＮおよびＴｙｐｅ：図５と同様の定義。
【００６７】
ＳＳＮ１：現在の分割ブロックが含まれる分割ブロックの過去の分割回数。４ビット。
【００６８】
ＳＳＮ２：現在の分割における現在の分割ブロック数。３ビット。
【００６９】
Ｆ：ＰＤＵが現在の分割において最後の分割ブロックであるか否かを示す。１ビット。
【００７０】
このヘッダ情報記録方法では、合計２１ビット必要になる。
【００７１】
この構成では、分割ブロックの分割ＩＤは、ＳＮ、ＳＳＮ１、およびＳＳＮ２で構成される。
【００７２】
上記のフォーマットを用いる場合には、受信側は、Ｌ２ ＰＤＵ分割ブロックを受信する度に、ナンバー（ＳＳＮ１およびＳＳＮ２フィールド）を更新する。このとき、ＳＳＮ１は、全ての受信データブロックが再配列された後で、数値として形成され、ＳＳＮ２は０００に設定される。再送信が必要なデータについては、ＳＳＮ１、最後に送信されたＳＳＮ２コンテンツ、および受信後に再配列したＳＳＮ１がフィードバックされる。
【００７３】
ＳＮ＝ＭであるＬ２ ＰＤＵを例に採れば下記のようになる。
【００７４】
（１）最初の送信
最初の送信では、Ｌ２ ＰＤＵは、３つのブロックに分割されることとする。この場合には、表３に示すように、ヘッダ情報と３つの分割ブロックのデータとが送信側において共に格納される。
【００７５】
【表３】
2009517930.tif 000005
３つのブロックのヘッダ情報は、受信側で更新される。表４に示すように、ＳＳＮ１のコンテンツは、最後に送信されたＳＳＮ２フィールドのコンテンツと一致している。
【００７６】
【表４】
2009517930.tif 000006
受信したＳＳＮ１、ＳＳＮ２、および受信側で更新されたＳＳＮ１は、フィードバックされる。
【００７７】
（２）２回目の送信
２回目の送信では、１回目の送信で２番目のブロックが正常に受信され、１番目および３番目のブロックがエラーを伴って受信され、これらについて再送信を行うものとする。また、ここでは、１番目のブロックは、再送信の際に３ブロックに再分割する必要があり、３番目のブロックは、再送信の際に２つのブロックに分割する必要があることを想定している。したがって、これらのブロックは、合計５つのブロックに分割されることになる。送信側は、これらの新しい分割ブロックに再度ナンバー付けを行い、ＳＳＮ１フィールドのコンテンツは、受信側で更新されたＳＳＮ１で更新される。また、ＳＳＮ２フィールドは、現在の分割における現在の分割ブロック数を示し、これらの数を表５に示す。
【００７８】
【表５】
2009517930.tif 000007
更新されたヘッダ情報は、分割ブロックと共に送信側で格納される。
【００７９】
受信側では、５つのデータブロックを受信すると、シーケンスナンバーがＭとなるデータブロックは６つになる。これらのヘッダを表６に示す。
【００８０】
【表６】
2009517930.tif 000008
受信側は、受信したデータをそのデータのＳＳＮ１に従って配列する。１番目から３番目のブロックが最初に位置しており、その後に６番目のブロックが続き、最後に４番目と５番目のブロックが位置していることがわかる。
【００８１】
受信側では、２回目の送信を終え、６つのブロックのデータが受信されると、６つのデータブロックのヘッダ情報は、表７に示すように更新される。
【００８２】
【表７】
2009517930.tif 000009
ここで、４番目のブロックに再度送信エラーが発生した場合には、送信時のＳＳＮ１＝００１０、ＳＳＮ２＝０００のナンバーが送信側にフィードバックされる。また、対応するブロックが送信側で発見されて再送信されるように、ＳＳＮ１フィールドのコンテンツとしてＳＳＮ１＝０１００という更新された情報が送信側にフィードバックされる。
【００８３】
また、上述した本発明の一実施形態に係る方法を実行するデータ送信システムを図７に示している。図示のように、データ送信装置６０は、第１モジュール６００、第２モジュール６１０、および送受信モジュール６２０を含む構成である（第１モジュールには機能モジュールが存在するが、図示していない）。第１モジュール６００は、ＰＤＵとして送信する必要のあるＳＤＵをカプセル化することにより、ＰＤＵからＳＤＵを復元する。第２モジュール６１０は、第１モジュールと論理的に接続しており、物理送信フォーマットに従って、第１ユニット６００でカプセル化されたＰＤＵの分割処理を実行する。そして、第２モジュール６１０は、各分割ブロックを識別し、これらの分割ブロックを連結してＨＡＲＱ ＰＤＵを形成する。また、第２モジュール６１０は、ＨＡＲＱ ＰＤＵからＰＤＵを復元して第１モジュール６００に送信する。送受信モジュール６２０は、上記第２モジュールと論理的に接続しており、第２モジュール６１０が連結したＨＡＲＱ ＰＤＵにベースバンド処理を施して物理フレームを生成し、これをワイヤレスリンクに送信する。そして、ワイヤレスリンクから物理フレームを受信し、ベースバンドで処理が行われた後、これらは第２モジュール６１０に送信される。第２モジュール６１０は、分割ＩＤに基づいて、格納されている分割ブロックの中から、対応する分割ブロックを抽出することによって、受信側が当該分割ブロックを正常に受信していないと決定し、それらを連結してＨＡＲＱ ＰＤＵを形成する。この分割ブロックは、送受信モジュール６２０によって再送信される。第２モジュール６１０は、分割ブロックを再送信するときに、最初に送信した分割ブロックを必要に応じて再分割し、分割ＩＤを再分割で得られた分割ブロックに記録してもよい。第１モジュール６００は、ワイヤレスリンク層のモジュールであり、第２モジュール６１０は、ＨＡＲＱのモジュールであり、送受信モジュール６２０は、物理層のモジュールである。処理は、上述の記載を参照することとし、ここでは説明を繰り返さない。
【００８４】
Ｌ２ ＰＤＵは、上位層から送信されたＳＤＵにヘッダ情報を付加して形成される。このため、ＲＬＣ ＳＤＵが、送信のために、送信ブロックのサイズに従って（すなわち、物理層の送信フォーマットに従って）、異なるサイズの複数のＲＬＣ ＰＤＵに分割される場合に、分割されたＲＬＣ ＰＤＵに分割ＩＤが付加されても問題がない。この処理方法は、すでに述べた処理と同様である。
【００８５】
当業者であれば、上記の記載に従って、本実施形態のデータ送信を行うデバイスを容易に入手することができる。この装置には、データユニットが物理層の送信フォーマットに従って分割されるときに、分割ブロックに分割ＩＤを記録するモジュールと、受信側が上記分割ブロックが正常に受信されなかったと判断したときに、上記分割ＩＤに基づいて、格納されている分割ブロックの中から、対応する分割ブロックを抽出して再送信するモジュールとが含まれている。さらに、上記装置には、再送信を行うときに、必要に応じて最初の送信時の分割ブロックを再分割し、再分割した分割ブロックに分割ＩＤを記録するモジュールが含まれている。
【００８６】
上記本発明の実施形態によれば、分割ブロックの一部にエラーがある場合には、エラーのある分割ブロックの再送信のみが必要となる。このため、送信されたデータの一部にエラーがあるという理由のみで、大きなデータブロックを再送信することを回避し、システムリソースの浪費を低減することができる。そして、これにより、大きなデータブロックが再送信されたときに、複数の物理フレームが送信されることによって、再送信に要する時間が極めて長くなるという問題を解決することができる。また、送信側のスケジューラは、分割深さフラグに基づいて、再送信するデータを認識することができるので、再送信するデータを優先することにより、迅速な再送信を行うこともできる。
【００８７】
上記方法は、ＷＣＤＭＡシステムに限定されず、発展ＵＴＲＡ（evolved UTRA）システムにおいても同様に適用することができる。このシステムにおけるデータ再送信処理は、上述した方法と同様であるから、ここでは説明を繰り返さない。
【００８８】
当業者であれば、本発明の精神および範囲を逸脱せずに、修正や変形を行うことができるのは、明らかである。したがって、請求項に記載の範囲内の修正および変形も本発明に含まれる。
【図面の簡単な説明】
【００８９】
【図１】関連技術における、ワイヤレス・インターフェース・プロトコルのフレームワークを示す図である。
【図２】関連技術における、エアー・インターフェース・プロトコルのためのデータフローおよびモードを示す図である。
【図３】本発明の一実施形態を示すものであり、データ再送信のフローチャートである。
【図４】本発明の一実施形態を示すものであり、エアー・インターフェース・プロトコルのデータフローを示す図である。
【図５】本発明の一実施形態を示すものであり、エアー・インターフェース・プロトコルのデータフローおよびモードを示す図である。
【図６】本発明の一実施形態を示すものであり、エアー・インターフェース・プロトコルのデータフローおよびモードを示す図である。
【図７】本発明の一実施形態を示すものであり、データ送信システムおよびデータ送信装置の構成を示す図である。
【図１】
2009517930.tif 000010
【図２】
2009517930.tif 000011
【図３】
2009517930.tif 000012
【図４】
2009517930.tif 000013
【図５】
2009517930.tif 000014
【図６】
2009517930.tif 000015
【図７】
2009517930.tif 000016
【手続補正書】
【提出日】平成20年7月2日(2008.7.2)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
送信側が、物理層の送信フォーマットに従ってデータユニットの分割処理を行うときに、当該送信側が格納する全ての分割ブロックの中から分割ブロックを特定する分割ＩＤを記録する処理を上記データユニットの各分割ブロックについて行うステップと、
上記送信側が、受信した確認メッセージに基づいて、受信側に正常に受信されなかった分割ブロックを決定するステップと、
上記送信側が、上記分割ＩＤに基づいて、格納している分割ブロック中から、正常に受信されなかった上記分割ブロックを再送信するステップとを含む、データ再送信方法。
【請求項２】
上記送信側が、正常に受信されなかった上記分割ブロックを再送信するときに、
物理層の送信フォーマットに従って、正常に受信されなかった上記分割ブロックを再分割して、該再分割による各分割ブロックの分割ＩＤを記録し、
再分割による上記分割ブロックを再送信する、請求項１に記載のデータ再送信方法。
【請求項３】
各分割ブロックに付加される分割プロパティフィールドに各分割ブロックの分割ＩＤを記録し、
上記分割プロパティフィールドは、上記分割されたデータユニットのヘッダ情報を含み、該ヘッダ情報は、上記分割されたデータユニットのシーケンスナンバーを含む、請求項１に記載のデータ再送信方法。
【請求項４】
上記分割プロパティフィールドは、さらに、
分割ブロックの長さを示す情報と、
最後の分割ブロックであることを示す情報とを含む、請求項３に記載のデータ再送信方法。
【請求項５】
分割ブロックの上記分割ＩＤは、
分割された上記データユニットのシーケンスナンバーと、
当該分割ブロックの分割深さと、
当該分割ブロックの最初の分割シーケンスナンバーとを含む、請求項４に記載のデータ再送信方法。
【請求項６】
受信側が、分割された上記データユニットのシーケンスナンバーと、上記分割ブロックの分割深さと、当該分割ブロックの分割シーケンスナンバーとに基づいて、受信した上記分割ブロックを再配列して、上記送信側が分割した上記データユニットを復元するステップをさらに含む、請求項５に記載のデータ再送信方法。
【請求項７】
分割ブロックの上記分割ＩＤは、分割された上記データユニットのシーケンスナンバーと、上記分割ブロックの第２分割シーケンスナンバーとを含み、
上記第２分割シーケンスナンバーは、２つのフィールドで表され、第１フィールドは、現在の分割以前に行われた分割による分割ブロック数を含み、第２フィールドは、現在の分割における分割ブロック数を含む、請求項４に記載のデータ再送信方法。
【請求項８】
上記受信側が、分割された上記データユニットの上記シーケンスナンバーと、上記分割ブロックの第２分割シーケンスナンバーとに基づいて、受信した上記分割ブロックを配列して、現在の分割についてナンバーの再割り当てを行い、上記第２分割シーケンスナンバーを更新する、請求項７に記載のデータ再送信方法。
【請求項９】
上記送信側が受信する上記確認メッセージは、上記各分割ブロックの分割ＩＤが含まれる受信確認メッセージを含む、請求項１から８の何れか１項に記載のデータ再送信方法。
【請求項１０】
上記データユニットは、レイヤ２プロトコル・データユニット、またはレイヤ２・サービス・データユニットである、請求項１から８の何れか１項に記載のデータ再送信方法。
【請求項１１】
物理層の送信フォーマットに従ってデータユニットの分割処理が行われるときに、送信側が格納している全ての分割ブロックの中から分割ブロックを特定する分割ＩＤを記録する処理を、上記データユニットの各分割ブロックについて行う第１モジュールと、
受信した確認メッセージに基づいて、受信側に正常に受信されなかった分割ブロックを決定する第２モジュールと、
上記分割ブロックの分割ＩＤに基づいて、格納している上記分割ブロック中から、正常に受信されなかった上記分割ブロックを再送信する第３モジュールとを含む、データ送信装置。
【請求項１２】
物理層の送信フォーマットに従って、正常に受信されなかった上記分割ブロックを再分割し、該再分割による各分割ブロックの分割ＩＤを記録する第４モジュールをさらに備えている、請求項１１に記載のデータ送信装置。
【請求項１３】
上記第１モジュールは、各分割ブロックに付帯する分割プロパティフィールドに各分割ブロックの分割ＩＤを記録し、
上記分割プロパティフィールドは、上記分割されたデータユニットのヘッダ情報を含み、該ヘッダ情報は、上記分割されたデータユニットのシーケンスナンバーを含む、請求項１１に記載のデータ送信装置。
【請求項１４】
請求項１１から１３の何れか１項に記載のデータ送信装置とデータ受信装置とを含むデータ送信システムであって、上記データ受信装置は、
物理層の送信フォーマットに従って上記データユニットが分割された後、上記データ送信装置から上記分割ブロックを受信する第１ユニットと、
上記データユニットに分割処理を行う際に上記データ送信装置が記録した分割ブロックの分割ＩＤに基づいて、受信した分割ブロックを配列して、上記データ送信装置が分割した上記データユニットを復元する第２ユニットとを含むデータ送信システム。
【請求項１５】
上記データ受信装置は、各分割ブロックの分割ＩＤを含む受信確認メッセージを上記データ送信装置に返信する、請求項１４に記載のデータ送信システム。
【国際調査報告】
2009517930.tif 000017
2009517930.tif 000018
2009517930.tif 000019
2009517930.tif 000020