(57)【要約】【課題】過度にオーバーヘッドを増加させることなく、データ・ブロックの最初の送信と再送との間のディレイを最小化するために、ＡＣＫ／ＮＡＣＫ報告を改善する。【解決手段】無線リンク制御/メディア・アクセス制御（ＲＬＣ／ＭＡＣ）データ転送ブロックの中に、受信確認（ＡＣＫ）情報を含めるべきかどうか決定するための方法と装置が提供される。受信確認（ＡＣＫ）情報がデータ転送ブロックに含まれるべきである場合には、受信確認（ＡＣＫ）情報は、可変長であり得る。受信確認（ＡＣＫ）情報は、また、ＲＬＣ／ＭＡＣデータ転送ブロックの他の全ての部分と独立して、コード化することができる。【選択図】図９
2010503250.tif 000002
【特許請求の範囲】
【請求項１】
データ転送ブロックの受信確認（ＡＣＫ）情報を含むことと、
データ転送ブロックの少なくとも部分から独立に受信確認（ＡＣＫ）情報をコード化することと、を含む方法。
【請求項２】
受信確認（ＡＣＫ）情報は、可変長の受信確認（ＡＣＫ）ビットマップを含む、請求項１に記載の方法。
【請求項３】
前記データ転送ブロックが、少なくとも１つのデータ・ブロックを含む、請求項１に記載の方法。
【請求項４】
前記データ転送ブロックが、プロトコル情報を含むヘッダを含む、請求項３に記載の方法。
【請求項５】
前記ヘッダは、前記受信確認（ＡＣＫ）情報が前記データ転送ブロックに含まれていることを示す、請求項４に記載の方法。
【請求項６】
前記ヘッダが、前記受信確認（ＡＣＫ）情報の長さを示す、請求項４に記載の方法。
【請求項７】
前記受信確認（ＡＣＫ）情報が、該受信確認（ＡＣＫ）情報が関連するＴＢＦ（一時的ブロック・フロー）を同定するアドレスを含む、請求項１に記載の方法。
【請求項８】
前記受信確認（ＡＣＫ）情報が、ＳＳＮ（starting sequence number、開始シーケンス番号）を備える、請求項１に記載の方法。
【請求項９】
前記コンピュータ・プログラムコードのコンピュータプロセッサによる実行をコンピュータ・プログラムコードに実現させる計算機可読の蓄積構造であって、前記コンピュータ・プログラムコードが、データ転送ブロックの受信確認（ＡＣＫ）情報を含むことと、データ転送ブロックの少なくとも部分から独立に受信確認（ＡＣＫ）情報をコード化することを含む方法を実行するための命令を含む、計算機可読の蓄積構造を備える、コンピュータ・プログラム・プロダクト。
【請求項１０】
受信確認（ＡＣＫ）情報は、可変長の受信確認（ＡＣＫ）ビットマップを含む、請求項９に記載のコンピュータ・プログラム・プロダクト。
【請求項１１】
受信確認（ＡＣＫ）情報をデータ転送ブロックに含むように構成されたモジュールと、
前記データ転送ブロックと独立に、前記受信確認（ＡＣＫ）情報をコード化するように構成された変調器と、を備える装置。
【請求項１２】
受信確認（ＡＣＫ）情報は、可変長の受信確認（ＡＣＫ）ビットマップを含む、請求項１１に記載の装置。
【請求項１３】
前記データ転送ブロックが、少なくとも１つのデータ・ブロックを含む、請求項１１に記載の装置。
【請求項１４】
前記データ転送ブロックが、プロトコル情報を含むヘッダを含む、請求項１１に記載の装置。
【請求項１５】
前記ヘッダは、前記受信確認（ＡＣＫ）情報が前記データ転送ブロックに含まれていることを示す、請求項１４に記載の装置。
【請求項１６】
前記ヘッダが、前記受信確認（ＡＣＫ）情報の長さを示す、請求項１４に記載の装置。
【請求項１７】
前記受信確認（ＡＣＫ）情報が、該受信確認（ＡＣＫ）情報が関連するＴＢＦ（一時的ブロック・フロー）を同定するアドレスを含む、請求項１１に記載の装置。
【請求項１８】
前記受信確認（ＡＣＫ）情報が、ＳＳＮ（starting sequence number、開始シーケンス番号）を備える、請求項１１に記載の装置。
【請求項１９】
受信確認（ＡＣＫ）情報をデータ転送ブロックに含ませる手段と、
前記データ転送ブロックと独立に、前記受信確認（ＡＣＫ）情報をコード化する手段と、を備える装置。
【請求項２０】
受信確認（ＡＣＫ）情報は、可変長の受信確認（ＡＣＫ）ビットマップを含む、請求項１９に記載の装置。
【請求項２１】
送信エンティティと、
受信エンティティと、を備えるシステムであって、
前記送信エンティティが、受信エンティティに送信するために、受信確認（ＡＣＫ）情報をデータ転送ブロックに含ませるモジュールを備え、
前記送信エンティティが、前記データ転送ブロック独立して、前記受信確認（ＡＣＫ）情報をコード化する変調器を備える、システム。
【請求項２２】
受信確認（ＡＣＫ）情報は、可変長の受信確認（ＡＣＫ）ビットマップを含む、請求項２１に記載のシステム。
【請求項２３】
前記データ転送ブロックが、少なくとも１つのデータ・ブロックを含む、請求項２１に記載のシステム。
【請求項２４】
前記データ転送ブロックが、プロトコル情報を含むヘッダを含む、請求項２１に記載のシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
［関連出願の相互参照］
本出願は、２００６年８月３０日に出願した米国仮特許出願番号第６０／８４１，６４９号の、米国特許法１１９条（ｅ）の下での利益を主張するものである。
【０００２】
本願発明は、コミュニケーション・システムの要素間の協調に関し、より詳細には、本願発明は、受信確認（ＡＣＫ）情報をデータ転送ブロックに含めることに関する。
【背景技術】
【０００３】
ＥＧＰＲＳ（Enhanced General Packet Radio Service）において、ＲＬＣ（radio link control）送信機は、ＲＬＣ受信確認モードおよびＲＬＣ非持続モードにおける受信データ・ブロックないし欠落データ・ブロックについての情報を提供するために、ＲＬＣ受信機に依存する。ＲＬＣ受信機は、（ＥＧＰＲＳ）パケット・アップリンク／ダウンリンク・ＡＣＫ／ＮＡＣＫ制御メッセージで運ばれる受信ビットマップを通して、そのＲＬＣ受信ウインドウのＡＣＫ状態をＲＬＣ送信機に報告する。これは、３ＧＰＰ・ＴＳ４４．０６０、技術仕様書グループ、ＧＳＭ／ＥＤＧＥ無線アクセスネットワーク、ＧＰＲＳ（General Packet Radio Service）、ＭＳ（Mobile Station）−ＢＳＳ（Base Station System）インターフェース、ＲＬＣ／ＭＡＣ（Radio Link Control/Medium Access Control）プロトコル（リリース７）（２００５−０７）に議論されている。この開示は引用によって本明細書に全体が組み込まれる。ＡＣＫ／ＮＡＣＫ制御メッセージは、どのデータパケットが、首尾よく受信され、どれが、ＲＬＣ送信機によって再送される必要があるかを示す。しかしながら、ＡＣＫ／ＮＡＣＫ制御メッセージは、ＲＬＣデータ・ブロックごとに送ることができないため、結果として受け入れがたいほどのオーバーヘッドになってしまう。その代わりに、ダウンリンク・データ転送の場合には、ＲＬＣ送信機からのポーリングの受信の際に、例えば、移動局（ＭＳ）に対して、ＡＣＫ／ＮＡＣＫメッセージが、ＲＬＣ受信機により送られる。ＲＬＣ受信機、たとえば基地局システム（ＢＳＳ）は、アップリンク・データ転送の場合には、いつＡＣＫ／ＮＡＣＫメッセージを送るべきかについて、それ自身で決定する。結果として、データ・ブロックの最初の送信と、再送との間のディレイは、部分的には、報告が提供される頻度の関数である。このことは、時間に感度が高いアプリケーションにとって、ディレイが大きすぎる、あるいは、逆に、オーバーヘッドが大きくなりすぎる結果となり得る。
【０００４】
過度にオーバーヘッドを増加させることなく、最初の送信と再送との間のディレイを最小化するために、ＡＣＫ／ＮＡＣＫ報告を改善するシステムが必要である。
【先行技術文献】
【非特許文献】
【０００５】
【非特許文献１】３ＧＰＰ・ＴＳ４４．０６０、技術仕様書グループ、ＧＳＭ／ＥＤＧＥ無線アクセスネットワーク、ＧＰＲＳ（General Packet Radio Service）、ＭＳ（Mobile Station）−ＢＳＳ（Base Station System）インターフェース、ＲＬＣ／ＭＡＣ（Radio Link Control/Medium Access Control）プロトコル（リリース７）（２００５−０７）
【発明の概要】
【０００６】
上で議論した問題を克服するために、短い受信ブロック・ビットマップを、データ転送のための無線リンク制御/メディア・アクセス制御（ＲＬＣ／ＭＡＣ）ブロックの中に含めることができる。データ転送のためのＲＬＣ／ＭＡＣブロックの中にＡＣＫ／ＮＡＣＫ情報を含めることは、本明細書では、ピギーバック・ＡＣＫ／ＮＡＣＫ情報（ＰＡＮ）と呼ばれる。ＲＬＣ／ＭＡＣブロックの中に含まれるＡＣＫ／ＮＡＣＫフィールドは、可変長（可変なＡＣＫ／ＮＡＣＫビットマップ・サイズ）であり得る。この可変長は、必要に応じて短いビットマップを挿入することを可能とし、それにより、データを含むブロックのＲＬＣ／ＭＡＣブロック内により多くのスペースを提供する。これにより、ＰＡＮ長が固定される場合とは対照的にデータ部分のより良いチャネルコーディングを可能とする。ＡＣＫ／ＮＡＣＫフィールドは、ＲＬＣ／ＭＡＣブロックの他の部分の全てから独立してコード化することが可能である。独立してコード化されたＰＡＮは、データ部分よりロバストなチャネルコーディングによって保護することができる。
【０００７】
本発明の第１の態様において、受信確認（ＡＣＫ）情報をデータ転送ブロックに含めるべきかどうか決定すること、受信確認（ＡＣＫ）情報を含めるべきと判断した場合には、受信確認（ＡＣＫ）情報をデータ転送ブロックに含めること、を含む方法が提供される。ここで、受信確認（ＡＣＫ）情報は、可変長受信確認（ＡＣＫ）ビットマップを含むことができる。
【０００８】
本発明の第１の態様によれば、受信確認（ＡＣＫ）情報は、データ転送ブロックと独立にコード化することができる。
【０００９】
本発明の第１の態様によれば、データ転送ブロックは、少なくとも１つのデータ・ブロックを含むことができる。
【００１０】
本発明の第１の態様によれば、データ転送ブロックは、プロトコル情報を含むヘッダを含むことができる。
【００１１】
本発明の第１の態様によれば、ヘッダは、受信確認（ＡＣＫ）情報の存在を示すことができる。
【００１２】
本発明の第１の態様によれば、ヘッダは、受信確認（ＡＣＫ）情報の長さを示すことができる。
【００１３】
本発明の第１の態様によれば、受信確認（ＡＣＫ）情報は、受信確認（ＡＣＫ）情報が参照しているＴＢＦ（一時的ブロック・フロー）を同定するアドレスを含むことができる。
【００１４】
本発明の第１の態様によれば、受信確認（ＡＣＫ）情報が、ＳＳＮ（starting sequence number、開始シーケンス番号）を含むことができる。
【００１５】
本発明の第１の態様によれば、受信確認（ＡＣＫ）情報が２１ビット以下である場合には、少なくとも１つのデータ・ブロックに対して、０．３７と０．９７の間の符号化レートを使用することができる。
【００１６】
本発明の第１の態様によれば、受信確認（ＡＣＫ）情報が２１ビットより大きい場合には、少なくとも１つのデータ・ブロックに対して、０．３９と１の間の符号化レートを使用することができる。
【００１７】
本発明の第１の態様によれば、受信確認（ＡＣＫ）情報に対して、０．３３と０．６３の間の符号化レートを使用することができる。
【００１８】
本発明の第１の態様によれば、ダウンリンクにおいてヘッダが含まれる場合には、０．３６と０．５７の間の符号化レートを使用することができる。
【００１９】
本発明の第１の態様によれば、アップリンクにおいてヘッダが含まれる場合には、０．３３と０．５１の間の符号化レートを使用することができる。
【００２０】
本発明の第１の態様によれば、コンピュータ・プログラムコードのコンピュータプロセッサによる実行を、コンピュータ・プログラムコードに実現させる計算機可読の蓄積構造を備えるコンピュータ・プログラム・プロダクトが提供される。ここで、コンピュータ・プログラムコードは、本発明の第１の態様により方法を実行するための命令を含む。
【００２１】
本発明の第２の態様によれば、受信確認（ＡＣＫ）情報をデータ転送ブロックに含むべきかどうかを決定するように構成されたプロセッサーと、プロセッサーによる決定に基づいて、受信確認（ＡＣＫ）情報をデータ転送ブロックに含むように構成されたモジュールと、を備える装置が提供される。ここで、受信確認（ＡＣＫ）情報は可変長受信確認（ＡＣＫ）ビットマップを含む。
【００２２】
本発明の第２の態様によれば、受信確認（ＡＣＫ）情報は、データ転送ブロックと独立にコード化することができる。
【００２３】
本発明の第２の態様によれば、データ転送ブロックは、少なくとも１つのデータ・ブロックを含むことができる。
【００２４】
本発明の第２の態様によれば、データ転送ブロックは、プロトコル情報を含むヘッダを含むことができる。
【００２５】
本発明の第２の態様によれば、ヘッダは、受信確認（ＡＣＫ）情報の存在を示すことができる。
【００２６】
本発明の第２の態様によれば、ヘッダは、受信確認（ＡＣＫ）情報の長さを示すことができる。
【００２７】
本発明の第２の態様によれば、受信確認（ＡＣＫ）情報は、受信確認（ＡＣＫ）情報が参照しているＴＢＦ（一時的ブロック・フロー）を同定するアドレスを含むことができる。
【００２８】
本発明の第２の態様によれば、受信確認（ＡＣＫ）情報が、ＳＳＮ（starting sequence number、開始シーケンス番号）を含むことができる。
【００２９】
本発明の第２の態様によれば、受信確認（ＡＣＫ）情報が２１ビット以下である場合には、少なくとも１つのデータ・ブロックに対して、０．３７と０．９７の間の符号化レートを使用することができる。
【００３０】
本発明の第２の態様によれば、受信確認（ＡＣＫ）情報が２１ビットより大きい場合には、少なくとも１つのデータ・ブロックに対して、０．３９と１の間の符号化レートを使用することができる。
【００３１】
本発明の第２の態様によれば、受信確認（ＡＣＫ）情報に対して、０．３３と０．６３の間の符号化レートを使用することができる。
【００３２】
本発明の第２の態様によれば、ダウンリンクにおいてヘッダが含まれる場合には、０．３６と０．５７の間の符号化レートを使用することができる。
【００３３】
本発明の第２の態様によれば、アップリンクにおいてヘッダが含まれる場合には、０．３３と０．５１の間の符号化レートを使用することができる。
【００３４】
本発明の第３の態様によれば、受信確認（ＡＣＫ）情報をデータ転送ブロックに含めるべきかどうか決定する手段と、決定する手段による決定に基づいて、受信確認（ＡＣＫ）情報をデータ転送ブロックに含める手段と、を備える装置が提供される。ここで、受信確認（ＡＣＫ）情報は、可変長受信確認（ＡＣＫ）ビットマップを含むことができる。
【００３５】
本発明の第４の態様によれば、受信エンティティと、送信エンティティと、を備えるシステムが提供される。受信エンティティまたは送信エンティティは、データ転送ブロックにおいて、可変長受信確認（ＡＣＫ）ビットマップを含む受信確認（ＡＣＫ）情報を含むように構成される。
【図面の簡単な説明】
【００３６】
本発明の上記および他の目的、特徴、優位点は、以下の詳細な記載を添付図面と照らし合わせて検討することから明らかになる。
【図１】ＡＣＫ／ＮＡＣＫフィールドを含むデータ転送ブロックである。
【図２ａ】ＡＣＫ／ＮＡＣＫフィールドの存在と長さを示している情報を含むヘッダフォーマットである。
【図２ｂ】ＡＣＫ／ＮＡＣＫフィールドの存在と長さを示している情報を含むヘッダフォーマットである。
【図２ｃ】ＡＣＫ／ＮＡＣＫフィールドの存在と長さを示している情報を含むヘッダフォーマットである。
【図３ａ】ＡＣＫ／ＮＡＣＫフィールドの存在と長さを示している情報を含むヘッダフォーマットである。
【図３ｂ】ＡＣＫ／ＮＡＣＫフィールドの存在と長さを示している情報を含むヘッダフォーマットである。
【図３ｃ】ＡＣＫ／ＮＡＣＫフィールドの存在と長さを示している情報を含むヘッダフォーマットである。
【図４ａ】ＡＣＫ／ＮＡＣＫフィールドの存在と長さを示している情報を含むヘッダフォーマットである。
【図４ｂ】ＡＣＫ／ＮＡＣＫフィールドの存在と長さを示している情報を含むヘッダフォーマットである。
【図４ｃ】ＡＣＫ／ＮＡＣＫフィールドの存在と長さを示している情報を含むヘッダフォーマットである。
【図５】ＡＣＫ／ＮＡＣＫフィールドを含むデータ転送ブロックのチャネルコーディング・プロセスを示す図である。
【図６】本発明を実装することができる無線通信システムのブロック図／フローチャートである。種々の通信端末を含んでいる。
【図７】マルチレイヤ・コミュニケーション・プロトコルスタックの用語による図６の２台の通信端末についての減少したブロック図である。
【図８】本発明の一態様による、通信端末の減少したブロック図である。
【図９】本発明の一態様による方法を示すフローチャートである。
【発明を実施するための形態】
【００３７】
本願発明は、コミュニケーション・システムの要素間の協調を含む、あるいは要素間の協調関するものである。無線通信システムの例は、ＧＳＭ（Global System for Mobile Communication）の実装、ＵＭＴＳ（Universal Mobile Telecommunication System）の実装を含む。そのような無線通信システムは夫々、ラジオ・アクセスネットワーク（ＲＡＮ）を含む。ＧＳＭ・ＲＡＮは、１つ以上の基地局コントローラ（ＢＳＣ）を含み、各々、一つ以上の無線基地局（ＢＴＳ）をコントロールする。それが制御するＢＳＣとＢＴＳの組合せは、基地局システム（ＢＳＳ）と呼ばれている。
【００３８】
ここで、図６を参照すると、本発明を実装することができる無線通信システム６７が示される。モバイル端末６１、ラジオアクセス・ネットワーク６８、コアネットワーク６４およびゲートウェイ６５を含み、別の通信システム６６へゲートウェイを介して連結する。例えば、インターネット、（いわゆる普通の従来の電話システムを含む）有線通信システムや、他の無線通信システムである。ラジオアクセス・ネットワークは、無線ターミナル６２（例えば、ノードＢまたはＢＴＳ）とコントローラ６３（例えばＲＮＣまたはＢＳＣ）を含む。コントローラは、コアネットワークと有線で通信している。コアネットワークは、一般的に、回線交換通信およびパケット交換コミュニケーションのＳＧＳＮ（a serving general packet radio service support node ）のためのＭＳＣ（mobile switching center）を含む。
【００３９】
図１は、ＲＬＣ／ＭＡＣ（無線リンク制御／メディア・アクセス制御）データ転送ブロック１１におけるＡＣＫ／ＮＡＣＫフィールド１３の形で、受信確認（ＡＣＫ）情報を含むことを示す。受信確認（ＡＣＫ）情報は、特定のデータパケットが受信エンティティによってうまく受信されたかどうかに関する標示を提供する。したがって、ＡＣＫは、データパケットがうまく受信されたことを示し、一方、ＮＡＣＫは、データパケットはうまく受信されなかったことを示す。データ転送ブロック１１は、ヘッダフィールド１２とデータ・ブロック１４も含むことができる。データ転送ブロック１１は、第２のデータ・ブロック１５も含むことができる。
【００４０】
データ転送ブロック11に受信確認（ＡＣＫ）情報１３をふくむことは、オプションであり、受信確認（ＡＣＫ）情報１３を含むべきかどうかは送信の間に採用される異なるポリシーに基づくことができる。受信確認（ＡＣＫ）情報を含むか否かの決定は、受信確認（ＡＣＫ）情報を送信するＲＬＣ（radio link control）エンティティ、すなわち移動局（MS）のようなＲＬＣ（radio link control）受信機により行うことが可能である。たとえば、信頼モードオペレーション中に、受信確認（ＡＣＫ）情報を、各々のＲＬＣ／ＭＡＣデータ転送ブロックに含むことができる。これは、ＲＬＣ送信機が、ＲＬＣ受信機の受信ウインドウの状態に関して最新の情報を有することを確実にする。本発明の別の典型的な実施形態において、受信ウインドウの状態のダイナミックスさが考慮され、ＲＬＣ受信機は、受信確認（ＡＣＫ）情報を、受信確認（ＡＣＫ）情報を含めることが決定されたあと、連続的なＲＬＣ／ＭＡＣデータ転送ブロックに挿入することができる。受信確認（ＡＣＫ）情報を含むか否かの決定は、データを送るＲＬＣ（radio link control）エンティティ、すなわち基地局システム（ＢＳＳ）のようなＲＬＣ（radio link control）送信機によっても行うことができる。この場合、ＲＬＣ送信機は、受信確認（ＡＣＫ）情報を受けるという決定に際して、この情報を送るために、ＲＬＣ受信機にポーリングを行う。
【００４１】
受信確認（ＡＣＫ）情報、すなわちＡＣＫ／ＮＡＣＫフィールドまたはピギーバック・ＡＣＫ／ＮＡＣＫ情報（ＰＡＮ）は、アドレス、ＳＳＮ（starting sequence number、開始シーケンス番号）とビットマップを含むことができる。ＡＣＫ／ＮＡＣＫフィールドとＰＡＮの用語は、交換可能であり、両方とも受信確認（ＡＣＫ）情報を意味することが理解される。アドレスは、ゼロないし５ビットの長さが可能であり、ＡＣＫ／ＮＡＣＫフィールドにより確認されるＴＢＦ（一時的ブロック・フロー）のユニークな同定を提供する。アドレス・フィールドは、強制あるいはオプションであることができる。アドレス・フィールドがオプションである場合、本発明の１つの実施形態において、移動局（ＭＳ）などのＲＬＣ受信機が、ＲＬＣ（radio link control）ＡＣＫモード、または反対方向で割り当てたＲＬＣ（radio link control）ノンパーシスタント・モードで動作している単一のＴＢＦ（一時的なブロック・フロー）を有するのみであるとき、アドレス・フィールドが含まれない。移動局が、ＲＬＣ（radio link control）ＡＣＫモード、またはＲＬＣ（radio link control）ノンパーシスタント・モードで動作している反対方向で１つ以上のＴＢＦ（一時的なブロック・フロー）を持つとき、アドレス・フィールドを含むことができる。１つの実施形態において、アドレス・フィールドは、反対方向に移動局に割り当てられ、昇順でソートされたすべてのＴＦＩ（temporary flow identity）のＴＦＩシーケンス番号として規定できる。別の実施形態では、アドレス・フィールドは、受信確認されたＴＢＦ（一時的ブロック・フロー）の実際のＴＦＩ（temporary flow identity）として規定できる。別の実施形態では、受信確認されたＴＢＦ（一時的なブロック・フロー）が割り当てられるデュアルあるいはマルチ・キャリア転送が用いられる場合には、アドレス・フィールドは、タイムスロット番号と、おそらくキャリヤー番号を含むものとして規定できる。
【００４２】
ＡＣＫ／ＮＡＣＫフィールドまたはＰＡＮ１３は、基地局またはノードＢに、たとえばまだ受信されていない最も古いデータ・ブロックを示すことができるＳＳＮ（starting sequence number、開始シーケンス番号）も含むことができる。ＳＳＮ（starting sequence number、開始シーケンス番号）は、長さ１１ビットであることができ、実際のＳＳＮ（starting sequence number、開始シーケンス番号）として、または、最下位ビットまたは実際のＳＳＮ（starting sequence number、開始シーケンス番号）のビットによってコード化することができる。
【００４３】
ＡＣＫ／ＮＡＣＫフィールドまたはＰＡＮ１３は、特定のデータパケットがうまく受信されたことを意味するＡＣＫ、またはＮＡＣＫを示すことができるビットマップをも含むことができる。特定のデータパケットがうまく受信されたことを意味するＡＣＫ、またはＮＡＣＫを示すことができる。本発明の１つの実施形態において、０を、ＮＡＣＫを示すのに用いることができ、１を、ＡＣＫを示すのに用いることができる。ビットマップは、可変長であることができ、その長さは、ＡＣＫ／ＮＡＣＫフィールド１３の全体長に依存することができる。ＲＬＣ／ＭＡＣデータ転送ブロックに含まれるＡＣＫ／ＮＡＣＫフィールド１３の長さの決定は、他の要素と同様に、ビットマップ長、データ・パート・コーディングのロバスト性、受信ウインドウの状態のダイナミックスさなどの要因に基づくことができる。
【００４４】
ＡＣＫ／ＮＡＣＫフィールドまたはＰＡＮ１３がデータ転送ブロック１１に含まれるならば、ヘッダ１２は、ＡＣＫ／ＮＡＣＫフィールド１３が含まれることの標示を含むことができ、ヘッダ１２の同じ標示または別の標示が、ＡＣＫ／ＮＡＣＫフィールド１３に関する情報を提供することができる。
【００４５】
表１と表２は、どのように、ヘッダ１３内のフィールドを、ＡＣＫ／ＮＡＣＫフィールドがいつデータ転送ブロックに含まれ、いつＡＣＫ／ＮＡＣＫフィールドの長さがデータ転送ブロックに含まれるかについて示すのに使うことができるかの例を提供する。表１と表２は、ダウンリンク・ヘッダに、ＡＣＫ／ＮＡＣＫフィールドが含まれているか、その長さが含まれているかどうかを示すために、ＥＳ／Ｐ（EGPRS supplementary/polling）とＲＲＢＰ（relative reserved block period）フィールドを使用することを示す。
【表１】
2010503250.tif 000003
【００４６】
表２は、ＥＳ／Ｐ（EGPRS Supplementary/Polling）が表１に示すように「０  ０」である場合、相対予約ブロック時間（ＲＲＢＰ：relative reserve block period）の値を示す。
【表２】
2010503250.tif 000004
【００４７】
本発明の典型的な実施形態によれば、図２ａから図２ｃは、ＡＣＫ／ＮＡＣＫフィールドの存在とその長さを、アップリンク・ヘッダ中に、どのように示すことができるかを表す。本発明の典型的な実施形態によれば、図２ａは、変調・符号化スキーマ７、８、９のためのアップリンク・ヘッダのフォーマットを示す。図２ｂは、変調・符号化スキーマ５、６のためのアップリンク・ヘッダのフォーマットを示す。図２ｃは、変調・符号化スキーマ１、２、３、４のためのアップリンク・ヘッダのフォーマットを示す。本発明の実施形態によれば、各々のヘッダフォーマットは、ＡＣＫ／ＮＡＣＫ（ＰＡＮＩ）に関する指示を含むことができる。リセット・ブロック・ビット（ＲＳＢ）は、また、ＡＣＫ／ＮＡＣＫフィールド（すなわちその存在や長さ）に関して情報を提供するためも再定義することができる。
【００４８】
表３は、ＡＣＫ／ＮＡＣＫフィールドに関して情報を提供するために、ＲＳＢとＰＡＮＩに関するビットが、どのように使用できるかの例を提供する。
【表３】
2010503250.tif 000005
【００４９】
本発明の別の典型的な実施形態において、ヘッダは、ＡＣＫ／ＮＡＣＫフィールドの発生と長さを特定することができる分離したフィールド（ＰＡＮＩ）を含むことができる。表４は、ＡＣＫ／ＮＡＣＫ標示を提供するのに３ビットが用いられる典型的な実施形態を示す。３ビットより小さいかまたは越えるいかなるビット数も、ＡＣＫ／ＮＡＣＫフィールドの長さと発生を指定するのに用いることができることが理解される。加えて、ＡＣＫ／ＮＡＣＫフィールドの長さは、表４にリストされるもの以外のビット情報によって長さが示されることが可能であるので、表４にリストされるビット情報に制限されない。ＡＣＫ／ＮＡＣＫフィールドの長さは、可能な長さの例であり、他のビット長がＡＣＫ／ＮＡＣＫフィールドのために使われることができたと考えられる。ＡＣＫ／ＮＡＣＫフィールドに対して他のビット長を使用することができたと考えられる。
【表４】
2010503250.tif 000006
【００５０】
別々のフィールドのヘッダへの追加は、ダウンリンク・ヘッダの長さを増加する可能性がある。それは、データ転送ブロックの全ての部分の符号化速度に影響を及ぼすかもしれない、表３Ａから表３Ｃは、３ビットの別々のフィールド（ＰＡＮＩ）がＡＣＫ／ＮＡＣＫフィールドの長さと発生を示すためにダウンリンク・ヘッダで使われる場合に、３つのダウンリンク・ヘッダ・タイプの典型的な実施形態を提供する。
【００５１】
図３ａは、データ転送ブロックに２つのデータ・ブロックがあり、８フェーズシフト・キーイング（８ＰＳＫ）変調が使われる場合に、使用することができるダウンリンク・ヘッダを表す。
【００５２】
図３ｂは、データ転送ブロックに１つのデータ・ブロックがあり、８ＰＳＫ変調が使われる場合に、使用することができるダウンリンク・ヘッダを表す。
【００５３】
図３ｃは、データ転送ブロックに１つのデータ・ブロックがあり、ガウス最小シフトキー・キーイング（ＧＢＳＫ）が使用される場合に、使用することができるダウンリンク・ヘッダを表す。他のダウンリンク・ヘッダフォーマットが可能であることが理解される。
【００５４】
表４Ａから表４Ｃは、３ビットの別々のフィールド（ＰＡＮＩ）がＡＣＫ／ＮＡＣＫフィールドの長さと発生を示すためにアップリンク・ヘッダで使われる場合に、３つのアップリンク・ヘッダ・タイプの典型的な実施形態を提供する。
【００５５】
図４ａは、データ転送ブロックに２つのデータ・ブロックがあり、８ＰＳＫ変調が使われる場合に、使用することができるアップリンク・ヘッダを表す。図４ａに示されるアップリンク・ヘッダは、他の変調・符号化スキーマだけでなく、変調・符号化スキーマ７、８、９に適合することができる。
【００５６】
図４ｂは、データ転送ブロックに１つのデータ・ブロックがあり、８ＰＳＫ変調が使われる場合に、使用することができるアップリンク・ヘッダを表す。図４ａに示されるアップリンク・ヘッダは、他の変調・符号化スキーマだけでなく、変調・符号化スキーマ５、６に適合することができる。
【００５７】
図４ｃは、データ転送ブロックに１つのデータ・ブロックがあり、ＧＭＳＫ変調が使われる場合に、使用することができるアップリンク・ヘッダを表す。図４ｃに示されるアップリンク・ヘッダは、他の変調・符号化スキーマだけでなく、変調・符号化スキーマ２、３、４に適合することができる。
【００５８】
図５は、ＡＣＫ／ＮＡＣＫフィールドを含むデータ転送ブロックのためのチャネルコーディング方法を表す。図５は、ダウンリンク方向で、表現されているが、チャネルコーディング・プロセスはアップリンク方向でも、アップリンク・ステージフラグ（ＵＳＦ）がないことを除いて、同様であることができることが理解される。ＡＣＫ／ＮＡＣＫフィールドは、最初に、例えば３ビットを使用した短いＣＲＣ（cyclic redundancy check）によって保護することができる。たとえば、３つのパリティービットを、エンコーダに送給されるＡＣＫ／ＮＡＣＫフィールドに加えることができる。最後の６つのＡＣＫ／ＮＡＣＫフィールドビットは、情報とパリティービット（すなわちテールビット）の前に加えることができる。次に、ＡＣＫ／ＮＡＣＫフィールドは、ヘッダに使用することができるのと同じ１／３レート畳込み符号の、そのＣＲＣでコード化することができる。ヘッダとＡＣＫ／ＮＡＣＫフィールドは、パンクチャリングマトリクスあるいはパンクチャリングスキーマにしたがって、パンクチャすることができる。本発明の典型的な実施形態において、３ＧＰＰ・ＴＳ４５．００３第３世代パートナーシッププロジェクト、技術仕様書グループ・ＧＳＭ／ＥＤＧＥ無線アクセスネットワーク、チャンネル・コーディングで規定されたＦＬＯ（Flexible Layer One）パンクチャリング・フォーミュラを、データ転送ブロックのデータ・ブロックのパンクチャリングに使用することができる。この開示は引用によって本明細書に全体が組み込まれる。
【００５９】
本発明の典型的な実施形態において、ＵＳＦコーディングは、ヘッダ・エンコーディングとは別に実行することができ、ヘッダ・コーディングが変わる場合でも、変化しない。
【００６０】
ＡＣＫ／ＮＡＣＫフィールド長は、データ転送ブロックの最初の送信と再送信の間で変化することが可能である。したがって、データ転送ブロックのエンコーディング率を、最初の送信と再送信の間で変えることは、実際の（符号化されていない）データを不変に保つために、そして、したがって、受信機においてレシーバーでソフトバインディングの可能性を維持するために、そして、また、ＡＣＫ／ＮＡＣＫフィールドをロバストに符号化するように保つために、望ましいことであり得る。ＦＬＯ規定からのパンクチャリング・フォーミュラを再利用することも、望ましいことであり得る。これは、また、冗長パターン・インデックスに基づくインクリメンタル・リダンダンシーの可能性をも提供することができる。
【００６１】
表５は、本発明の典型的な実施形態による、変調および符号化スキーム・ファミリをリストする。変調・符号化スキーマのためのペイロードは、ＡＣＫ／ＮＡＣＫフィールドの挿入のために減らされる。ペイロード長は、ファミリと共に表５にリストされる。
【００６２】
本発明の典型的な実施形態によれば、表６ないし表９は、使用することができる、ヘッダ、ＡＣＫ／ＮＡＣＫフィールド、データ・ブロックの符号化速度をリストする。表６および表７は、ＡＣＫ／ＮＡＣＫフィールドが３７ビットの長さを持つ場合の符号化速度を示す。表８および表９は、ＡＣＫ／ＮＡＣＫフィールドが２１ビットの長さを持つ場合の符号化速度を示す。
【表５】
2010503250.tif 000007
【表６】
2010503250.tif 000008
【表７】
2010503250.tif 000009
【表８】
2010503250.tif 000010
【表９】
2010503250.tif 000011
【００６３】
表１０ないし表１３は、本発明のもう一つの典型的な実施形態による、データ転送ブロックのヘッダ、ＡＣＫ／ＮＡＣＫフィールド、データ・ブロックのための符号化速度を示す。
【表１０】
2010503250.tif 000012
【表１１】
2010503250.tif 000013
【表１２】
2010503250.tif 000014
【表１３】
2010503250.tif 000015
【００６４】
ここで、図７を参照すると、本発明の典型的な実施形態による、図６の無線通信システムが、通信の実行が従うプロトコルのレイヤの観点から示される。プロトコルのレイヤは、プロトコルスタックを形成し、ＲＬＣ受信機７１とＲＬＣ送信機７５に位置するＣＮプロトコルレイヤ７２を含み、ＲＬＣ受信機７１とＲＬＣ送信機７５に位置するプロトコルレイヤ７３に無線で連絡する。通信はピア・ツー・ピアである。このように、受信機７１におけるＣＮプロトコルレイヤは、送信機７５における対応するレイヤと通信する。また、その逆も同様である。そして、通信は、より下位ないし中間のレイヤを介して提供される。より下位ないし中間のレイヤは、こうして、プロトコルスタックにおけるそれらのすぐ上位のレイヤに対するサービスとして、通信（制御信号またはユーザデータ）の単位のパッケージングまたはアンパッケージングを提供する。
【００６５】
ＣＮプロトコルは、一般的に１つ以上の制御プロトコルレイヤやユーザデータ・プロトコルレイヤを含む（例えば、アプリケーション・レイヤ、すなわち、カレンダー・アプリケーションやゲーム・アプリケーションのような、直接アプリケーションとインターフェースするプロトコルスタックのレイヤ）。
【００６６】
ラジオ・プロトコルは、一般的にラジオ資源管理（プロトコル）レイヤを含む。これは、ラジオベアラの、相当数の他者、体制、再構成、開放の間に、その責任を有する。別のラジオ・プロトコルレイヤは、ＲＬＣ／ＭＡＣ（radio link control/ media access control）である（これは、２つの別々のレイヤとして存在し得る）。このレイヤは、活動中に、物理レイヤ、ラジオ・アクセス・プロトコルレイヤの別のレイヤ、と、エア・インタフェース上の実際の通信を可能とするインターフェースを提供する。
【００６７】
図８は、通信端末８１のいくつかのコンポーネントを示す。それはＲＬＣ受信機７１または、図７のＲＬＣ送信機７５であり得る。通信ターミナルは、すべての入出力を含む、デバイスの作動をコントロールするためのプロセッサー８２を含む。本発明の典型的な実施形態において、プロセッサー８２は、受信確認（ＡＣＫ）情報をＲＬＣ／ＭＡＣデータ転送ブロックに含むべきかどうか決定するように構成される。プロセッサーが、受信確認（ＡＣＫ）情報を含むべきであると決定する場合には、モジュール８９は、受信確認（ＡＣＫ）情報をＲＬＣ／ＭＡＣデータ転送ブロックに含む。必要に応じて、変調器８８は、ヘッダを含むデータ転送ブロックのための変調と同様に、データ転送ブロックに含まれる受信確認（ＡＣＫ）情報に対して必要な変調を実行する。
【００６８】
スピード／タイミングがクロック８２Ａによって管理され得るプロセッサーは、ＢＩＯＳ（基本入出力システム）を含むことができ、あるいは、キーボードからのユーザー入力だけでなくユーザ・オーディオとビデオ入出力を制御するデバイスハンドラを含むことができる。ＢＩＯＳ／デバイスハンドラは、ネットワークインターフェイスカードからの入力と出力も可能にすることができる。ＢＩＯＳ／デバイスハンドラはまた、デジタルシグナルプロセッサ（ＤＳＰ）、特定用途向け集積回路（ＡＳＩＣ）やフィールドプログラマブルゲートアレイ（ＦＰＧＡ）の１つ以上をおそらく含む、ＴＲＸインターフェース８５を介してトランシーバ（ＴＲＸ）８６への入出力の制御を規定する。ＴＲＸは、別の同様に備えられた通信端末とのエア上の通信を可能にする。
【００６９】
続いて図８を参照すると、通信端末は、揮発性メモリ、すなわちいわゆる実行可能メモリ８３、更には、不揮発性メモリ８４、すなわち蓄積メモリを含む。プロセッサー８２は、不揮発性記憶に格納された例えばカレンダー・アプリケーションまたはゲームなどのアプリケーションを、実行のために実行可能メモリに、コピーすることができる。オペレーティングシステムにしたがって、プロセッサーが機能し、それにより、プロセッサーは、オペレーティングシステムの対応する部分を起動するために、蓄積メモリから実行可能メモリに、少なくともオペレーティングシステムの一部をロードすることができる。オペレーティングシステムの他の部分、具体的には、しばしば、ＢＩＯＳの少なくとも部分は、ファームウェアとして通信端末の中に存在することができ、実行されるために、実行可能メモリにコピーされない。ブートアップ命令は、そのようなオペレーティングシステムの一部である。
【００７０】
図９は、本発明の典型的な実施形態を表す。ステップＳ２０において、受信確認（ＡＣＫ）情報をＲＬＣ／ＭＡＣデータ転送ブロックに含むべきかどうかが、決定される。受信確認（ＡＣＫ）情報（すなわちＡＣＫ／ＮＡＣＫフィールド）がＲＬＣ／ＭＡＣデータ転送ブロックに含まれるべきであると決定される場合には、次に、受信確認（ＡＣＫ）情報が、ステップＳ２１において、含まれる。
【００７１】
上述の機能（ラジオアクセス・ネットワークとＵＥの両方）は、不揮発性記憶に格納され、実行可能ＲＡＭ（ランダムアクセスメモリー）にソフトウェアの全部または一部をコピーした後に、プロセッサーによって必要に応じて実行されるソフトウェアモジュールとして、インプリメントすることができる。代替的に、そのようなソフトウェアにより提供される論理は、ＡＳＩＣ（特定用途向け集積回路）によって提供することもできる。ソフトウェア・インプリメンテーションの場合には、本発明は、コンピュータプロセッサによる実行を、コンピュータ・プログラムコードに実現させるコンピュータ可読の蓄積構造を含むコンピュータ・プログラム・プロダクトとして提供される。
【００７２】
上記の構成は、本発明の原理の応用の説明に過ぎないことが理解されるべきである。多数の変形や代替的は仕組みを、本発明の範囲から出ることなく、当業者は考案することができる。当業者は、本願のステップと信号は、一般的な因果関係を表現するものであることを理解するであろう。それは、種々のタイプの中間的な解釈を除外するものではない。さらに、本願で記述された種々のステップや構造が、ここにさらに詳述するまでもないハードとソフトのいろいろな組合せを使うことにより、種々の異なる順序および構成によってインプリメントできることを理解するであろう。
【図１】
2010503250.tif 000016
【図２ａ】
2010503250.tif 000017
【図２ｂ】
2010503250.tif 000018
【図２ｃ】
2010503250.tif 000019
【図３ａ】
2010503250.tif 000020
【図３ｂ】
2010503250.tif 000021
【図３ｃ】
2010503250.tif 000022
【図４ａ】
2010503250.tif 000023
【図４ｂ】
2010503250.tif 000024
【図４ｃ】
2010503250.tif 000025
【図５】
2010503250.tif 000026
【図６】
2010503250.tif 000027
【図７】
2010503250.tif 000028
【図８】
2010503250.tif 000029
【図９】
2010503250.tif 000030
【手続補正書】
【提出日】平成21年4月27日(2009.4.27)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
受信確認（ＡＣＫ）情報がデータ転送ブロックに含まれるべきかを決定するステップと、
データ転送ブロックの少なくとも部分から独立に受信確認（ＡＣＫ）情報をコード化するステップと、を含む方法。
【請求項２】
前記受信確認（ＡＣＫ）情報が、可変長の受信確認（ＡＣＫ）ビットマップを含む、請求項１に記載の方法。
【請求項３】
前記データ転送ブロックが、少なくとも１つのデータブロックと、プロトコル情報を含む、請求項１ないし２のいずれか１項に記載の方法。
【請求項４】
前記ヘッダは、前記受信確認（ＡＣＫ）情報が前記データ転送ブロックに含まれていることを示す、請求項３に記載の方法。
【請求項５】
前記ヘッダが、前記受信確認（ＡＣＫ）情報の長さを示す、請求項３に記載の方法。
【請求項６】
前記受信確認（ＡＣＫ）情報が、該受信確認（ＡＣＫ）情報が関連するＴＢＦ（一時的ブロック・フロー）を同定するアドレスを含む、請求項１ないし５のいずれか１項に記載の方法。
【請求項７】
前記受信確認（ＡＣＫ）情報が、ＳＳＮ（starting sequence number、開始シーケンス番号）を含む、請求項１ないし５のいずれか１項に記載の方法。
【請求項８】
請求項１ないし７のいずれか１項に記載の方法を実行する命令を含むコンピュータ・プログラム。
【請求項９】
受信確認（ＡＣＫ）情報をデータ転送ブロックに含むように構成されたモジュールと、
前記データ転送ブロックと独立に、前記受信確認（ＡＣＫ）情報をコード化するように構成された変調器と、を備える装置。
【請求項１０】
前記受信確認（ＡＣＫ）情報が、可変長の受信確認（ＡＣＫ）ビットマップを含む、請求項９に記載の装置。
【請求項１１】
前記データ転送ブロックが、少なくとも１つのデータブロックを含む、請求項９ないし１０のいずれか１項に記載の装置。
【請求項１２】
前記データ転送ブロックが、プロトコル情報を含むヘッダを含む、請求項９ないし１０のいずれか１項に記載の装置。
【請求項１３】
前記ヘッダが、前記受信確認（ＡＣＫ）情報が前記データ転送ブロックに含まれていることを示す、請求項１２に記載の装置。
【請求項１４】
前記ヘッダが、前記受信確認（ＡＣＫ）情報の長さを示す、請求項１２に記載の装置。
【請求項１５】
前記受信確認（ＡＣＫ）情報が、該受信確認（ＡＣＫ）情報が関連するＴＢＦ（一時的ブロック・フロー）を同定するアドレスを含む、請求項９ないし１２のいずれか１項に記載の装置。
【請求項１６】
前記受信確認（ＡＣＫ）情報が、ＳＳＮ（starting sequence number、開始シーケンス番号）を含む、請求項９ないし１２のいずれか１項に記載の装置。
【請求項１７】
受信確認（ＡＣＫ）情報をデータ転送ブロックに含める手段と、
前記データ転送ブロックと独立に、前記受信確認（ＡＣＫ）情報をコード化する手段と、を備える装置。
【請求項１８】
前記受信確認（ＡＣＫ）情報が、可変長の受信確認（ＡＣＫ）ビットマップを含む、請求項１７に記載の装置。
【請求項１９】
送信エンティティと、
受信エンティティと、を備えるシステムであって、
前記送信エンティティが、前記受信エンティティに送信するために、受信確認（ＡＣＫ）情報をデータ転送ブロックに含めるモジュールを備え、
前記送信エンティティが、前記データ転送ブロックと独立に、前記受信確認（ＡＣＫ）情報をコード化する変調器を備える、システム。 
【請求項２０】
前記受信確認（ＡＣＫ）情報が、可変長の受信確認（ＡＣＫ）ビットマップを含む、請求項２１に記載のシステム。
【国際調査報告】
2010503250.tif 000031
2010503250.tif 000032
2010503250.tif 000033
2010503250.tif 000034