(57)【要約】  自動再送要求（ＡＲＱ）及び複合自動再送要求（ＨＡＲＱ）が共に動作する移動通信システムにおける状態報告を送受信する方法及び装置を提供する。ＡＲＱ Ｒｘエンティティは、所定の状態報告生成条件が満たされると、上記状態報告の送信が許可されるか否かを判定する。上記状態報告の送信が許可された場合には、上記ＡＲＱ Ｒｘエンティティは、上記状態報告の送信が許可された時点までのＡＲＱパケットの受信状況に応じて状態報告を生成し、上記生成された状態報告を割り当てられた送信リソースを介してＡＲＱ Ｔｘエンティティに送信する。上記ＡＲＱ Ｔｘエンティティは、上記状態報告を含むＨＡＲＱパケットの最初受信時点を上記状態報告の生成時間として判定し、上記状態報告に従って再送信を実行する。
2009533942.tif 000002
【特許請求の範囲】
【請求項１】
自動再送要求（ＡＲＱ）レイヤー及び複合自動再送要求（ＨＡＲＱ）レイヤーを含む移動通信システムにおけるＡＲＱレイヤーの状態報告を送信する方法であって、
ＡＲＱ受信（Ｒｘ）エンティティで所定の状態報告生成条件が満たされると、前記状態報告の送信が許可されるか否かを判定するステップと、
前記状態報告の送信が許可された場合に、前記状態報告の送信が許可された時点までのＡＲＱパケットの受信状況に応じて状態報告を生成するステップと、
前記生成された状態報告を割り当てられた送信リソースを介してＡＲＱ送信（Ｔｘ）エンティティに送信するステップと、
を有することを特徴とする方法。
【請求項２】
前記状態報告は、
前記状態報告の送信が許可された時点までに成功裡に受信されたＡＲＱパケットのシーケンス番号と、
前記状態報告の送信が許可された時点までに受信されていないＡＲＱパケットのシーケンス番号と、
を含むことを特徴とする請求項１に記載の方法。
【請求項３】
前記状態報告の送信が許可された時点は、前記状態報告を含むデータを送信するために使用される送信リソースが割り当てられた時点を示すことを特徴とする請求項１に記載の方法。
【請求項４】
現在の時間が所定の期間に基づく送信時間間隔に到達すると、前記状態報告生成条件が満たされたと判定するステップをさらに有することを特徴とする請求項１に記載の方法。
【請求項５】
前記ＡＲＱ ＴｘエンティティからＡＲＱパケットを受信する過程で、未受信ＡＲＱパケットが検出された場合に、前記状態報告生成条件が満たされたと判定するステップをさらに有することを特徴とする請求項１に記載の方法。
【請求項６】
自動再送要求（ＡＲＱ）レイヤー及び複合自動再送要求（ＨＡＲＱ）レイヤーを含む移動通信システムにおけるＡＲＱレイヤーの状態報告を受信する方法であって、
ＨＡＲＱパケットをＡＲＱ受信（Ｒｘ）エンティティから最初に受信したとき、ＨＡＲＱ送受信（Ｔｘ／Ｒｘ）エンティティで前記ＨＡＲＱパケットの最初受信時点を記録するステップと、
前記ＨＡＲＱパケットが成功裡に受信されたものと判定された場合に、前記ＨＡＲＱパケットに含まれている状態報告を検出し、前記検出された状態報告を前記ＨＡＲＱパケットの最初受信時点と共にＡＲＱ送信（Ｔｘ）エンティティに送信するステップと、
前記ＡＲＱ Ｔｘエンティティで前記最初受信時点を前記状態報告の生成時間として認識し、前記状態報告に従って再送信が必要なＡＲＱパケットを再送信するステップと、
を有することを特徴とする方法。
【請求項７】
前記状態報告は、
前記状態報告の送信が許可された時点までに前記ＡＲＱ Ｒｘエンティティで成功裡に受信したＡＲＱパケットのシーケンス番号と、
前記状態報告の送信が許可された時点までに前記ＡＲＱ Ｒｘエンティティで受信していないＡＲＱパケットのシーケンス番号と、
を含むことを特徴とする請求項６に記載の方法。
【請求項８】
前記状態報告の送信が許可された時点は、前記状態報告を含むデータを送信するために使用される送信リソースが割り当てられた時点を示すことを特徴とする請求項７に記載の方法。
【請求項９】
制御チャネルを介して前記ＨＡＲＱパケットのデコーディング制御情報を受信し、前記デコーディング制御情報に含まれている再送信シーケンス番号（ＲＳＮ）及び新たなデータ指示子（ＮＤＩ）を確認するステップと、
前記ＲＳＮが‘０’に設定されるか、又は前記ＮＤＩが以前の値とは異なる値に設定される場合に、前記ＨＡＲＱパケットが最初に受信されたものと判定するステップと、
をさらに有することを特徴とする請求項６に記載の方法。
【請求項１０】
自動再送要求（ＡＲＱ）レイヤー及び複合自動再送要求（ＨＡＲＱ）レイヤーを含む移動通信システムにおけるＡＲＱレイヤーの状態報告を送信する装置であって、
ＡＲＱ受信（Ｒｘ）エンティティで所定の状態報告生成条件が満たされると、前記状態報告の送信が許可されるか否かを判定し、前記状態報告の送信が許可された場合に、前記状態報告の送信が許可された時点までのＡＲＱパケットの受信状況に応じて状態報告を生成する状態報告生成部と、
前記生成された状態報告を割り当てられた送信リソースを介してＡＲＱ送信（Ｔｘ）エンティティに送信する送信部と、
を具備することを特徴とする装置。
【請求項１１】
前記状態報告は、
前記状態報告の送信が許可された時点までに成功裡に受信されたＡＲＱパケットのシーケンス番号と、
前記状態報告の送信が許可された時点までに受信されていないＡＲＱパケットのシーケンス番号と、
を含むことを特徴とする請求項１０に記載の装置。
【請求項１２】
前記状態報告の送信が許可された時点は、前記状態報告を含むデータを送信するために使用される送信リソースが割り当てられた時点を示すことを特徴とする請求項１０に記載の装置。
【請求項１３】
前記状態報告生成部は、現在の時間が所定の期間に基づく送信時間間隔に到達すると、前記状態報告生成条件が満たされたと判定することを特徴とする請求項１０に記載の装置。
【請求項１４】
前記状態報告生成部は、前記ＡＲＱ ＴｘエンティティからＡＲＱパケットを受信する過程で、未受信ＡＲＱパケットが検出されると、前記状態報告生成条件が満たされたと判定することを特徴とする請求項１０に記載の装置。
【請求項１５】
自動再送要求（ＡＲＱ）レイヤー及び複合自動再送要求（ＨＡＲＱ）レイヤーを含む移動通信システムにおけるＡＲＱレイヤーの状態報告を受信する装置であって、
前記ＨＡＲＱパケットが成功裡に受信されたものと判定された場合に、前記ＨＡＲＱパケットに含まれている状態報告を検出し、前記検出された状態報告を前記ＨＡＲＱパケットの最初受信時点と共に出力するＨＡＲＱ送信／受信（Ｔｘ／Ｒｘ）エンティティと、
前記最初受信時点を前記状態報告の生成時間として認識し、前記状態報告に従って再送信が必要なＡＲＱパケットを再送信するＡＲＱ送信（Ｔｘ）エンティティと、
を具備することを特徴とする装置。
【請求項１６】
前記状態報告は、
前記状態報告の送信が許可された時点までに前記ＡＲＱ Ｒｘエンティティで成功裡に受信されたＡＲＱパケットのシーケンス番号と、
前記状態報告の送信が許可された時点までに前記ＡＲＱ Ｒｘエンティティで受信されていないＡＲＱパケットのシーケンス番号と、
を含むことを特徴とする請求項１５に記載の装置。
【請求項１７】
前記状態報告の送信が許可された時点は、前記状態報告を含むデータを送信するために使用される送信リソースが割り当てられた時点を示すことを特徴とする請求項１６に記載の装置。
【請求項１８】
前記ＨＡＲＱ Ｔｘ／Ｒｘエンティティは、制御チャネルを介して前記ＨＡＲＱパケットのデコーディング制御情報を受信し、前記デコーディング制御情報に含まれている再送信シーケンス番号（ＲＳＮ）及び新たなデータ指示子（ＮＤＩ）を確認し、前記ＲＳＮが‘０’に設定されるか、又は前記ＮＤＩが以前の値とは異なる値に設定される場合に、前記ＨＡＲＱパケットが最初に受信されたものと判定することを特徴とする請求項１５に記載の装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、移動通信システムに関し、特に、自動再送要求（automatic repeat request：以下、“ＡＲＱ”と称する）レイヤーでのＡＲＱの状態報告を送受信する方法及び装置に関する。
【背景技術】
【０００２】
第３世代の非同期移動通信システムであるユニバーサル移動通信サービス（Universal Mobile Telecommunication Service：以下、“ＵＭＴＳ”と称する）システムは、広帯域符号分割多重接続（Code Division Multiple Access：以下、“ＣＤＭＡ”と称する）を使用する。ＵＭＴＳは、ヨーロッパ式移動通信システムであるＧＰＲＳ（General Packet Radio Services）及びＧＳＭ（Global System for Mobile Communications）に基づく。
ＵＭＴＳ標準化を担当している第３世代パートナーシッププロジェクト（3rd Generation Partnership Project：以下、“３ＧＰＰ”と称する）において、ロングタームエボルーション（Long Term Evolution：以下、“ＬＴＥ”と称する）は、ＵＭＴＳシステムの次世代移動通信システムとして議論が進んでいる。ＬＴＥは、２０１０年ごろに商用化することを目標にしており、１００Ｍｂｐｓ程度の高速パケット基盤通信を実現するための技術である。このために、様々な方法が論議されている。例えば、ネットワーク構成を簡素化することにより、通信経路上のノードの数を減少させる方式及び無線プロトコルを無線チャネルに最大に近接させる方式などがある。
【０００３】
図１は、次世代（Evolved）ＵＭＴＳ移動通信システムの構成の一例を示す。
図１を参照すると、次世代ＵＭＴＳ無線アクセスネットワーク（Evolved UMTS Radio Access Network：以下、“Ｅ-ＵＴＲＡＮ”又は“Ｅ-ＲＡＮ”と称する）１３５及び１４０の構成は、次世代基地局（Evolved Node B：以下、“ＥＮＢ”又は“ノードＢ”と称する）１１０乃至１３０と、アンカーノード１４５及び１５０との２ノード構成に簡素化される。ユーザー端末（User Equipment：以下、“ＵＥ”と称する）１０５は、Ｅ-ＲＡＮ１３５及び１４０によりインターネットプロトコル（以下、“ＩＰ”と称する）ネットワークに接続する。
既存のノードＢに対応するノードＥＮＢ１１０乃至１３０は、無線チャネルを介してＵＥ１０５に接続される。既存のノードＢに比べて、ＥＮＢ１１０乃至１３０は、より複雑な機能を遂行する。
【０００４】
ＬＴＥでは、インターネットプロトコルを介した音声サービス（Voice over IP：以下、“ＶｏＩＰ”と称する）のようなリアルタイムサービスを含む全てのユーザトラフィックは、共用チャネル（ＳＣＨ）を介してサービスされる。これは、ＵＥの状況情報を収集し、スケジューリングを実行する装置が必要であることを意味し、ＥＮＢ１１０乃至１３０がこのスケジューリングを担当する。下記の説明において、“ＥＮＢ”と“ノードＢ”とは、交互に使用される。
ＬＴＥにおいて、高速ダウンリンクパケットアクセス（High Speed Downlink Packet Access：ＨＳＤＰＡ）や拡張されたアップリンク専用チャネル（Enhanced uplink Dedicated Channel：Ｅ-ＤＣＨ）と同様に、ハイブリッド自動再送要求（Hybrid Automatic Repeat ReQuest（ARQ）：ＨＡＲＱ）は、ＥＮＢ１１０乃至１３０とＵＥ１０５との間で行われる。しかしながら、ＬＴＥは、ＨＡＲＱ方式の使用だけでは、様々なサービス品質（Quality of Service：ＱｏＳ）の要求を満足することができない。したがって、別個のＡＲＱ（すなわち、ｏｕｔｅｒ-ＡＲＱ）は、上位レイヤーで行われることができ、この別個のＡＲＱは、ＥＮＢ１１０乃至１３０とＵＥ１０５との間でも行われる。
【０００５】
最大１００Ｍｂｐｓの送信速度を実現するために、ＬＴＥは、２０ＭＨｚの帯域幅で直交周波数分割多重化（Orthogonal Frequency Division Multiplexing：ＯＦＤＭ）方式を無線接続技術として使用するものと予想される。また、ＬＴＥは、ＵＥのチャネル状態に適合した変調方式及びチャネル符号化率を決定する適応変調符号化（Adaptive Modulation & Coding：ＡＭＣ）方式を適用するのであろう。ＬＴＥをはじめとして現在議論されている多くの移動通信システムは、ＨＡＲＱ及びＡＲＱのすべてをエラー訂正技術として使用する。
【０００６】
ＨＡＲＱは、以前に受信したデータを廃棄することなく、再送信されたデータと以前に受信したデータをソフトコンバイニングし、これにより、受信成功率を増加させるための技術である。より詳細に、ＨＡＲＱ受信（Receiving：以下、“Ｒｘ”と称する）エンティティは、受信したパケットのエラーが存在するか否かを判定した後に、エラーが存在するか否かに従って肯定応答（ACKnowledged：以下、“ＡＣＫ”と称する）信号又は否定応答（Non-ACKnowledged：以下、“ＮＡＣＫ”と称する）信号をＨＡＲＱ送信（transmitting：以下、“Ｔｘ”と称する）エンティティに送信する。ＨＡＲＱ Ｔｘエンティティは、ＨＡＲＱ ＡＣＫ／ＮＡＣＫ信号に従って、ＨＡＲＱパケットの再送信又は新たなＨＡＲＱパケットの送信を実行する。ＨＡＲＱは、再送信されたパケットを以前に受信したパケットとソフトコンバイニングすることにより、エラー発生確率を減少させることができる。
しかしながら、ＡＲＱは、受信したパケットのシーケンス番号を検査し、受信に失敗したパケットに対する再送信要請を状態報告を使用して送信する技術であり、事前に受信したパケットを再送信されたパケットとソフトコンバイニングしない。
【０００７】
ＡＲＱ及びＨＡＲＱがどちらもエラーのあるパケットを復元する機能を有するために、ＡＲＱ及びＨＡＲＱをともに行う必要がないと見なされる。しかしながら、ＨＡＲＱだけでは、十分に低いパケットエラー率を得ることができないために、ＡＲＱ及びＨＡＲＱは、大部分のパケットサービスでともに行われなければならない。
ＨＡＲＱにおいて、ＨＡＲＱ ＡＣＫ／ＮＡＣＫ信号が１ビット応答信号であるため、チャネル符号化を介してエラー率を減少させることは難しい。したがって、ＨＡＲＱだけでは、低いパケットエラー率を達成することが難しい。すなわち、ＨＡＲＱ ＮＡＣＫ信号がＨＡＲＱ ＡＣＫ信号として間違って認識される場合には、対応するパケットをＨＡＲＱレイヤーで完全に見失う。したがって、ＨＡＲＱ ＡＣＫ／ＮＡＣＫ信号の信頼度がＨＡＲＱレイヤーでのパケットエラー率の決定に重要な要素として作用する。
【０００８】
ＡＲＱ及びＨＡＲＱがともに動作するシステムは、ＨＡＲＱレイヤーからの情報を使用してＡＲＱ動作の効率性を向上させることができる。例えば、ＨＡＲＱ Ｔｘエンティティは、ＡＲＱパケットの送信完了時間情報をＡＲＱ Ｔｘエンティティに送信し、ＡＲＱ Ｔｘエンティティは、この状態報告が生成された時間をＡＲＱパケット送信が完了した時間と比較することにより、不必要な再送信を防止することができる。
この状態報告の生成及び送信が同一の時間の間になされる場合には、この状態報告を含むＨＡＲＱパケットが最初に受信された時点は、この状態報告が生成された時間と実質的に同一である。しかしながら、この状態報告の生成時間がこの状態報告の送信時間と異なる場合には、ＡＲＱ Ｔｘエンティティは、この状態報告の生成時間を推定することができず、この状態報告を含むＨＡＲＱパケットが最初に受信された時点をこの状態報告の生成時間として単に認識する。
【０００９】
例えば、ＡＲＱ Ｒｘエンティティで状態報告の生成時間から送信時間までの遅延時間の間に受信した特定のＡＲＱパケットに関する成功／失敗情報の受信は、前に生成された状態報告に含まれることができない。この状態報告がこの特定のＡＲＱパケットに関する成功／失敗情報を受信していないため、ＡＲＱ Ｔｘエンティティは、この特定のＡＲＱパケットの送信に失敗したものと見なし、この特定のＡＲＱパケットをＡＲＱ Ｒｘエンティティに再送信する。したがって、従来の移動通信システムでは、不必要な再送信が発生し得るという問題点があった。
【発明の開示】
【発明が解決しようとする課題】
【００１０】
したがって、本発明は、上述した従来技術の問題点を解決するために提案されたものであり、その目的は、移動通信システムにおけるＡＲＱ受信（Ｒｘ）エンティティが状態報告を実質的に送信することができる時点で状態報告を生成して送信する方法及び装置を提供することにある。
本発明の他の目的は、移動通信システムにおけるＡＲＱ送信（Ｔｘ）エンティティが状態報告を受信した後に、状態報告の生成時間を推定する方法及び装置を提供することにある。
本発明のまた他の目的は、ＡＲＱ及びＨＡＲＱがともに動作する移動通信システムにおけるＡＲＱ ＴｘエンティティがＨＡＲＱレイヤーで状態報告が生成された時間を推定する方法及び装置を提供することにある。
本発明のさらなる目的は、ＡＲＱ及びＨＡＲＱがともに動作する移動通信システムにおけるＡＲＱ Ｔｘエンティティが状態報告を含むＨＡＲＱパケットの最初受信時点で状態報告の生成時間を推定する際に、ＨＡＲＱパケットのスケジューリング遅延による時間誤差を除去する方法及び装置を提供することにある。
【課題を解決するための手段】
【００１１】
上記のような目的を達成するために、本発明の一態様によれば、自動再送要求（ＡＲＱ）レイヤー及び複合自動再送要求（ＨＡＲＱ）レイヤーを含む移動通信システムにおけるＡＲＱレイヤーの状態報告を送信する方法は、ＡＲＱ受信（Ｒｘ）エンティティで所定の状態報告生成条件が満たされると、上記状態報告の送信が許可されるか否かを判定するステップと、上記状態報告の送信が許可された場合に、上記状態報告の送信が許可された時点までのＡＲＱパケットの受信状況に応じて状態報告を生成するステップと、上記生成された状態報告を割り当てられた送信リソースを介してＡＲＱ送信（Ｔｘ）エンティティに送信するステップと、を有することを特徴とする。
【００１２】
本発明の他の態様によれば、自動再送要求（ＡＲＱ）レイヤー及び複合自動再送要求（ＨＡＲＱ）レイヤーを含む移動通信システムにおけるＡＲＱレイヤーの状態報告を受信する方法は、ＨＡＲＱパケットをＡＲＱ受信（Ｒｘ）エンティティから最初に受信したとき、ＨＡＲＱ送受信（Ｔｘ／Ｒｘ）エンティティで上記ＨＡＲＱパケットの最初受信時点を記録するステップと、上記ＨＡＲＱパケットが成功裡に受信されたものと判定された場合に、上記ＨＡＲＱパケットに含まれた状態報告を検出し、上記検出された状態報告を上記ＨＡＲＱパケットの最初受信時点と共にＡＲＱ送信（Ｔｘ）エンティティに送信するステップと、上記ＡＲＱ送信 Ｔｘエンティティで上記最初受信時点を上記状態報告の生成時間として認識し、上記状態報告に従って再送信が必要なＡＲＱパケットを再送信するステップと、を有することを特徴とする。
【００１３】
本発明のさらなる他の態様によれば、自動再送要求（ＡＲＱ）レイヤー及び複合自動再送要求（ＨＡＲＱ）レイヤーを含む移動通信システムにおけるＡＲＱレイヤーの状態報告を送信する装置は、ＡＲＱ受信（Ｒｘ）エンティティで所定の状態報告生成条件が満たされると、上記状態報告の送信が許可されるか否かを判定し、上記状態報告の送信が許可された場合に、上記状態報告の送信が許可された時点までのＡＲＱパケットの受信状況に応じて状態報告を生成する状態報告生成部と、上記生成された状態報告を割り当てられた送信リソースを介してＡＲＱ送信（Ｔｘ）エンティティに送信する送信部と、を具備することを特徴とする。
【００１４】
本発明のさらにまた他の態様によれば、自動再送要求（ＡＲＱ）レイヤー及び複合自動再送要求（ＨＡＲＱ）レイヤーを含む移動通信システムにおけるＡＲＱレイヤーの状態報告を受信する装置は、上記ＨＡＲＱパケットが成功裡に受信されたものと判定された場合に、上記ＨＡＲＱパケットに含まれた状態報告を検出し、上記検出された状態報告を上記ＨＡＲＱパケットの最初受信時点と共に出力するＨＡＲＱ送信／受信（Ｔｘ／Ｒｘ）エンティティと、上記最初受信時点を上記状態報告の生成時間として認識し、上記状態報告に従って再送信が必要なＡＲＱパケットを再送信するＡＲＱ送信（Ｔｘ）エンティティと、を具備することを特徴とする。
【発明の効果】
【００１５】
本発明によれば、ＡＲＱ Ｒｘエンティティは、スケジューリング遅延の後に状態報告を生成して送信し、ＡＲＱ Ｔｘエンティティは、状態報告を含むＨＡＲＱパケットの最初受信時点を状態報告の生成時間として測定し、これにより、状態報告生成時間と最初受信時点との間のエラーによる不必要な再送信を防止することができるという長所がある。
【発明を実施するための最良の形態】
【００１６】
以下、本発明の好適な一実施形態を、添付図面を参照しつつ詳細に説明する。下記の説明において、明瞭性と簡潔性の観点から、本発明に関連した公知の機能や構成に関する具体的な説明が本発明の要旨を不明瞭にすると判断される場合には、その詳細な説明を省略する。
本発明は、ＡＲＱ及びＨＡＲＱがともに動作する移動通信システムにおいて、ＡＲＱ送信エンティティがＨＡＲＱレイヤーで状態報告が生成された時間を推定する場合に、この状態報告のスケジューリング遅延による誤差を除去する方式を提案する。
【００１７】
図２を参照すると、ステップ２２５で、ＡＲＱ送信（transmitting：以下、“Ｔｘ”と称する）エンティティ２０５は、ＨＡＲＱ Ｔｘ／Ｒｘエンティティ２１０及び２１５を介してＡＲＱパケットをＡＲＱ受信（receiving：以下、“Ｒｘ”と称する）エンティティ２２０に送信する。３ＧＰＰにおいて、プロトコルデータユニット（Protocol Data Unit：以下、“ＰＤＵ”と称する）という用語は、一般的に、‘パケット’という用語の代わりに使用される。したがって、本発明では、‘パケット’及び‘ＰＤＵ’を混用する。ステップ２３０で、所定の状態報告生成条件のうちの１つが満たされると、ＡＲＱ Ｒｘエンティティ２２０は、状態報告の生成をトリガーした後に、この状態報告をＡＲＱ Ｔｘエンティティ２０５に送信することにより、未受信（すなわち、受信に失敗した）ＡＲＱ ＰＤＵに対する再送信を要請し、及び／又は、成功裡に受信したＡＲＱ ＰＤＵを通知する。
【００１８】
ＡＲＱ Ｒｘエンティティ２２０が状態報告を生成する条件は、呼設定過程で定義されることができ、この条件は、次のような条件を含むことができる。
- ＡＲＱ Ｒｘエンティティ２２０は、未受信ＡＲＱ ＰＤＵを検出すると、状態報告を生成する。
- ＡＲＱ Ｒｘエンティティ２２０は、所定の期間で状態報告を生成する。
この状態報告生成条件のうちの少なくとも１つが満たされると、ＡＲＱ Ｒｘエンティティ２２０は、状態報告の生成をトリガーする。
【００１９】
好ましくは、この状態報告は、生成と同時に送信される。しかしながら、ＬＴＥのようなＥＮＢスケジューリングが適用される通信システムでは、スケジューリング遅延２３５が適用される可能性が高い。例えば、ＡＲＱ Ｒｘエンティティ２２０を含むＵＥがこの状態報告が生成された時点２３０で割り当てられた送信リソースを有していない場合には、ＵＥは、送信リソースを要請し、割り当てられた送信リソースを受信するスケジューリング過程をまず経らなければならず、このスケジューリング過程で少なくとも数十ｍｓｅｃ以上のスケジューリング遅延２３５は、スケジューリング過程で必要とされる。
ＡＲＱ Ｒｘエンティティ２２０がスケジューリング遅延２３５を経験した後に、この状態報告は、ステップ２４０で、ＨＡＲＱ Ｔｘ／Ｒｘエンティティ２１５によりＨＡＲＱパケットに含まれ、最終的にＡＲＱ Ｔｘエンティティ２０５の下位レイヤーであるＨＡＲＱ Ｔｘ／Ｒｘエンティティ２１０に送信される。
下記の説明では、この状態報告を含むＨＡＲＱパケットが、例えば、３回の反復送信を介してＡＲＱ Ｔｘエンティティ２０５への受信に成功すると仮定する。
【００２０】
すなわち、ステップ２４０で、ＡＲＱ Ｒｘエンティティ２２０がこの状態報告を受信側ＨＡＲＱ Ｔｘ／Ｒｘエンティティ２１５（すなわち、受信側エンティティでのＨＡＲＱ Ｔｘ／Ｒｘエンティティ）に送信すると、受信側ＨＡＲＱ Ｔｘ／Ｒｘエンティティ２１５は、ステップ２４５で、この状態報告をＨＡＲＱパケットに含み、送信側ＨＡＲＱ Ｔｘ／Ｒｘエンティティ２１０（すなわち、送信側エンティティでのＨＡＲＱ Ｔｘ／Ｒｘエンティティ）に送信する（１番目の送信）。ここで、送信側ＨＡＲＱ Ｔｘ／Ｒｘエンティティ２１０は、ステップ２５０で、ＨＡＲＱパケットを最初に受信した最初受信時点を確認し、ＨＡＲＱパケットがエラーなしに成功裡に受信されたか否かを判定する。この判定の結果、ＨＡＲＱパケットの成功的な受信に失敗したと判定される場合には、ステップ２５５で、送信側ＨＡＲＱ Ｔｘ／Ｒｘエンティティ２１０は、受信側ＨＡＲＱ Ｔｘ／Ｒｘエンティティ２１５にＮＡＣＫを送信し、ＮＡＣＫに応答して、受信側ＨＡＲＱ Ｔｘ／Ｒｘエンティティ２１５は、ステップ２６０で、ＨＡＲＱパケットを送信側ＨＡＲＱ Ｔｘ／Ｒｘエンティティ２１０に再送信する（２番目の送信）。送信側ＨＡＲＱ Ｔｘ／Ｒｘエンティティ２１０は、２番目に送信されたＨＡＲＱパケットを１番目に送信されたＨＡＲＱパケットとコンバイニングした後に、ＨＡＲＱパケットが成功裡に受信されたか否かを判定する。
【００２１】
送信側ＨＡＲＱ Ｔｘ／Ｒｘエンティティ２１０がＨＡＲＱパケットの成功的な受信にさらに失敗した場合に、送信側ＨＡＲＱ Ｔｘ／Ｒｘエンティティ２１０は、ステップ２６５で、ＮＡＣＫを受信側ＨＡＲＱ Ｔｘ／Ｒｘエンティティ２１５にさらに送信する。受信側ＨＡＲＱ Ｔｘ／Ｒｘエンティティ２１５は、ステップ２７０で、ＮＡＣＫに応答して、ＨＡＲＱパケットを送信側ＨＡＲＱ Ｔｘ／Ｒｘエンティティ２１０にさらに再送信する（３番目の送信）。送信側ＨＡＲＱ Ｔｘ／Ｒｘエンティティ２１０がＨＡＲＱパケットの受信に成功した場合には、送信側ＨＡＲＱ Ｔｘ／Ｒｘエンティティ２１０は、ステップ２７５で、ＨＡＲＱパケットに含まれた状態報告を抽出し、この抽出された状態報告をＡＲＱ Ｔｘエンティティ２０５に送信した後に、ステップ２８０で、ＨＡＲＱパケットに対するＡＣＫを受信側ＨＡＲＱ Ｔｘ／Ｒｘエンティティ２１５に送信する。
【００２２】
ＡＲＱ Ｔｘエンティティ２０５は、状態報告が生成された状態報告生成時間２３０を認識することにより、ＡＲＱ ＰＤＵの不必要な再送信を防止する。状態報告生成時間２３０に対して、この状態報告に明示的に表示されるか、またはＨＡＲＱ Ｔｘエンティティ２０５がこの状態報告を含むＨＡＲＱパケットの最初受信時点２５０を用いて状態報告生成時間２３０を推定する。しかしながら、ＨＡＲＱパケットの最初受信時点２５０を使用する方法は、この状態報告に適用されたスケジューリング遅延２３５を無視するという観点で正確でない。
したがって、本発明の好ましい実施形態は、この状態報告を含むＨＡＲＱパケットの最初受信時点からこの状態報告生成時間を推定する際に、状態報告に適用されたスケジューリング遅延による誤差を除去する。すなわち、ＡＲＱ Ｒｘエンティティは、この状態報告生成条件が満たされても、この状態報告を即座に生成しないが、送信リソースの割当など状態報告を送信する準備が完了した後に、状態報告を生成する。また、ＡＲＱ Ｔｘエンティティは、状態報告を含むＨＡＲＱパケットの最初受信時点を状態報告生成時間として認識する。
【００２３】
図３を参照すると、ステップ３２５で、ＡＲＱ Ｒｘエンティティ３２０で状態報告生成条件のうちの１つが満たされる場合に、状態報告がトリガーされる。この状態報告生成条件は、周期的な状態報告の生成、又は未受信ＡＲＱ ＰＤＵの検出などであることができる。この際に、この状態報告がトリガーされても、ＡＲＱ Ｒｘエンティティ３２０は、状態報告を即座に生成することなく次の動作を実行する。
すなわち、ＡＲＱ Ｒｘエンティティ３２０は、送信データの存在を下位レイヤー（図示せず）に通知し、実際に割り当てられたある送信リソースが存在する場合には、この下位レイヤーは、ＡＲＱ Ｒｘエンティティ３２０が送信データを伝達するように許可する。例えば、送信リソースの管理を担当するエンティティである下位レイヤーは、ＥＮＢでは、スケジューラーであり、ＵＥでは、送信リソース管理部である。ＡＲＱ Ｒｘエンティティ３２０が送信データの存在を通知する現在の時点で割り当てられた送信資源がない場合には、下位レイヤーは、適切な過程を介して送信リソースを割り当てられる。ＡＲＱ Ｒｘエンティティ３２０がＵＥに属している場合には、この下位レイヤーは、送信リソースの割当要請をＥＮＢに送信し、送信リソースがＥＮＢから割り当てられるまで待機する。送信リソースが割り当てられる場合には、この下位レイヤーは、ＡＲＱ Ｒｘエンティティ３２０が送信データを伝達するように許可する。
【００２４】
ＡＲＱ Ｒｘエンティティ３２０は、ステップ３３０で、下位レイヤーから送信許可を取得すると、状態報告を構成する。この状態報告は、再送信要請のための未受信ＡＲＱ ＰＤＵのシーケンス番号と、この状態報告を構成する時点まで受信に成功したＡＲＱ ＰＤＵのシーケンス番号と、を含む。ここで、この未受信ＡＲＱ ＰＤＵは、受信に失敗した（すなわち、ＮＡＣＫ-ｅｄ）ものと確認されたＡＲＱ ＰＤＵを意味し、ＡＲＱ Ｔｘエンティティ３０５により送信されたか否かを確認できないＡＲＱ ＰＤＵは、未受信ＡＲＱ ＰＤＵに該当しない。
ＡＲＱ Ｒｘエンティティ３２０は、ステップ３３５で、この状態報告を受信側ＨＡＲＱ Ｔｘ／Ｒｘエンティティ３１５に送信し、受信側ＨＡＲＱ Ｔｘ／Ｒｘエンティティ３１５は、ステップ３４５で、この状態報告を含むＨＡＲＱパケットを生成した後に、割り当てられた送信リソースを使用してＨＡＲＱパケットを送信側ＨＡＲＱ Ｔｘ／Ｒｘエンティティ３１０に送信する。
【００２５】
送信側ＨＡＲＱ Ｔｘ／Ｒｘエンティティ３１０は、ＨＡＲＱパケットの最初受信時点３４０を記録し、ＨＡＲＱパケットが成功裡に受信されたか否かを判定する。ＨＡＲＱパケットが成功裡に受信された場合には、ステップ３５０で、送信側ＨＡＲＱ Ｔｘ／Ｒｘエンティティ３１０は、ＨＡＲＱパケットに含まれた状態報告とともに、ＨＡＲＱパケットの最初受信時点３４０をＡＲＱ Ｔｘエンティティ３０５に送信する。
ステップ３５５で、ＡＲＱ Ｔｘエンティティ３０５は、この状態報告とともに、ステップ３５０で送信された最初受信時点３４０をこの状態報告生成時間として認識する。この状態報告生成時間の前に送信したが、この状態報告により受信が確認されない（ＮＡＣＫ-ｅｄ）ＡＲＱ ＰＤＵが存在する場合には、ＡＲＱ Ｔｘエンティティ３０５は、ＡＲＱ ＰＤＵが再送信を必要とすると判定する。
【００２６】
図４を参照すると、ステップ４０５で、状態報告生成条件が満たされ、この状態報告の生成がトリガーされると、ステップ４１０で、ＡＲＱ Ｒｘエンティティは、送信データの存在を送信リソースの管理を担当する下位レイヤーに通知する。ここで、この送信データは、送信される状態報告を含む。ステップ４１５で、この下位レイヤーが状態報告を含むデータの送信のために使用される送信リソースを割り当てることによりデータ送信を許可すると、ＡＲＱ Ｒｘエンティティは、ステップ４２０に進み、データ送信が許可されない場合には、データ送信が許可されるときまで待機する。例えば、ＡＲＱ Ｒｘエンティティを含むＵＥが現在の送信時間間隔でスケジューリングされるか、又はＡＲＱ Ｒｘエンティティを含むＥＮＢがこの状態報告を送信するＵＥをスケジューリングした場合に、ＡＲＱ Ｒｘエンティティは、この状態報告を含むデータの送信が可能であると判定する。
【００２７】
ステップ４２０で、ＡＲＱ Ｒｘエンティティは、現在の時点までのＡＲＱ ＰＤＵ受信状況に基づく状態報告を生成する。この状態報告は、この状態報告が生成される現在の時点まで成功裡に受信されたＡＲＱ ＰＤＵ、すなわち、受信が確認された（ＡＣＫ-ｅｄ）ＡＲＱ ＰＤＵ等のシーケンス番号と、この現在の時点まで受信に失敗したＡＲＱ ＰＤＵ、すなわち、ＮＡＣＫ-ｅｄ ＡＲＱ ＰＤＵ等のシーケンス番号と、を含む。この際に、ＡＲＱ Ｒｘエンティティが下位のＨＡＲＱ Ｔｘ／ＲｘエンティティでＨＡＲＱ手続きの中にあるか、又は送信過程で完全に見失ったＡＲＱ ＰＤＵの存在を認識することができないため、ＡＲＱ Ｒｘエンティティは、この状態報告にＡＲＱ ＰＤＵのシーケンス番号を含ませない。その後に、ステップ４２５で、ＡＲＱ Ｒｘエンティティは、この状態報告を下位のＨＡＲＱ Ｔｘ／Ｒｘエンティティに伝達し、ＨＡＲＱ Ｔｘ／Ｒｘエンティティは、この状態報告をＨＡＲＱパケットに含ませ、相手側ＨＡＲＱ Ｔｘ／Ｒｘエンティティを介してＡＲＱ Ｔｘエンティティに送信する。
【００２８】
要約すると、この状態報告生成条件が満たされると、ＡＲＱ Ｒｘエンティティは、この状態報告を実際に送信することができる時点まで待機した後に、状態報告を送信できる時点でこの状態報告を生成する。このような方式で、ＡＲＱ Ｒｘエンティティは、この状態報告が生成した時間を状態報告の送信が開始された時間に最大に近接させる。したがって、ＡＲＱ Ｔｘエンティティは、‘状態報告受信時点’が‘状態報告生成時点’と実質的に同一であると判定することができる。この際に、この状態報告を含むＨＡＲＱパケットが受信側ＨＡＲＱ Ｔｘ／Ｒｘエンティティから送信される時間とＨＡＲＱパケットが送信側ＨＡＲＱ Ｔｘ／Ｒｘエンティティで受信される時間との間で、伝播遅延（propagation delay）が考慮されることができる。しかしながら、これは、本発明の主な要旨とは関連がないので、詳細な説明を省略する。
【００２９】
図５を参照すると、ステップ５０５で、新たなＨＡＲＱパケットが受信されると、すなわち、ＨＡＲＱパケットが最初に受信されると、ＨＡＲＱ Ｔｘ／Ｒｘエンティティは、ステップ５１０で、ＨＡＲＱパケットの最初受信時点を記録する。
ＨＡＲＱ Ｔｘ／Ｒｘエンティティは、再送信シーケンス番号（Retransmission Sequence Number：以下、“ＲＳＮ”と称する）又は新規データ指示子（New Data Indicator：以下、“ＮＤＩ”と称する）のように、制御チャネルを介して送信されるＨＡＲＱパケットのデコーディング制御情報に基づいて、新たなＨＡＲＱパケットの受信を認識する。例えば、ＲＳＮが‘０’に設定されるか、又はＮＤＩが以前の値とは異なる値に設定される場合には、新たなＨＡＲＱパケットの送信が開始されることを意味する。
【００３０】
ステップ５１５で、ＨＡＲＱ Ｔｘ／Ｒｘエンティティは、ＨＡＲＱパケットのＨＡＲＱ受信過程を実行する。すなわち、ＨＡＲＱ Ｔｘ／Ｒｘエンティティは、ＨＡＲＱパケットの巡回冗長検査（Cyclic Redundancy Checking：以下、“ＣＲＣ”と称する）を介してＨＡＲＱパケット内にエラーが存在するか否かを判定する。上記判定の結果、ＣＲＣエラーが存在する場合には、ＨＡＲＱ Ｔｘ／Ｒｘエンティティは、ソフトコンバイニングのために、ＨＡＲＱパケットを対応するＨＡＲＱプロセッサのソフトバッファに格納する。しかしながら、ＣＲＣエラーが存在しない場合には、ＨＡＲＱ Ｔｘ／Ｒｘエンティティは、ＨＡＲＱパケットを処理し、上位レイヤーに伝達する。
【００３１】
ステップ５２０で、このＨＡＲＱパケットの受信が成功すると、すなわち、これ以上ＨＡＲＱパケットにエラーが存在しないと、ＨＡＲＱ Ｔｘ／Ｒｘエンティティは、ステップ５２５に進み、ＨＡＲＱパケットに含まれている上位レイヤーデータを逆多重化する。この後に、ステップ５３０で、ＨＡＲＱ Ｔｘ／Ｒｘエンティティは、この逆多重化された上位レイヤーデータを適切な上位レイヤーに伝達する。特に、この逆多重化された上位レイヤーデータ内の状態報告は、ＡＲＱ Ｔｘエンティティに送信される。この際に、ステップ５１０で記録しておいたＨＡＲＱパケットの最初受信時点は、ＡＲＱ Ｔｘエンティティとともに送信される。ステップ５３５で、ＨＡＲＱ Ｔｘ／Ｒｘエンティティは、ステップ５１０で記録しておいた最初受信時点を削除した後に、ステップ５４０に進み、ＨＡＲＱプロセッサのソフトバッファを空ける（flush）。
ステップ５２０で、ＨＡＲＱパケットの受信に失敗すると、すなわち、ＨＡＲＱパケットにやはりエラーが存在するが、新たなＨＡＲＱパケットの送信が開始されると、ＨＡＲＱ Ｔｘ／Ｒｘエンティティは、ステップ５３５で、このＨＡＲＱパケットに対する最初受信時点を削除し、ステップ５４０で、ＨＡＲＱプロセッサのソフトバッファを空ける。
【００３２】
図６を参照すると、ＡＲＱ Ｔｘエンティティは、ステップ６０５で、下位レイヤーである送信側ＨＡＲＱ Ｔｘ／Ｒｘエンティティから状態報告及び最初受信時点を受信する場合には、ＡＲＱ Ｔｘエンティティは、ステップ６１０で、この最初受信時点を状態報告生成時間として認識し、この状態報告の内容に従って必要な動作を実行する。言い換えれば、ＡＲＱ Ｔｘエンティティは、この状態報告に示された未受信ＡＲＱ ＰＤＵと、この状態報告生成時間の前に送信されたが、この状態報告により受信が確認されないＡＲＱ ＰＤＵと、を再送信する。
【００３３】
一方、本明細書で使用された‘時間’についてさらに詳細に説明すると、次のとおりである。
本発明は、‘状態報告生成時間’、‘最初受信時点’、及び‘送信完了時間’のように、ＵＥ及びＥＮＢが同一に認識されなければならない時間が複数使用される。ある時間を示すインデックスが２ノード間で同一の意味を有するようにする最も簡素な方法として、ＵＥ及びＥＮＢは、互いに同期が取られたタイマーを備えるものである。しかしながら、通常の移動通信では、同期化した個々のタイマーを使用するよりは、ＵＥがＥＮＢによりブロードキャストされるシステム時間を使用する場合がさらに普遍的である。
【００３４】
移動通信において、フレームは、時間単位として使用される。このフレームは、送受信の基本単位として使用される期間を意味する。例えば、ＵＭＴＳにおいて、１つのフレームの長さは、１０ｍｓｅｃである。
ＵＭＴＳのような従来の移動通信システムにおいて、ＥＮＢは、フレーム境界ごとに１ずつ増加するタイマー（又はカウンター）を含む。このタイマーは、１０ｍｓｅｃごとに１ずつ増加し、フレームが開始される度に開始される。このタイマーの出力値は、このフレーム境界ごとに１ずつ増加し、フレーム番号と呼ばれる。ＥＮＢがこのフレーム番号を周期的にブロードキャストすることにより、ＵＥ及びＥＮＢは、特定のフレームに対するフレーム番号を識別することができる。
【００３５】
したがって、ＥＮＢがブロードキャストするフレーム番号は、本発明で説明された‘時間’として使用されることができる。例えば、状態報告生成時間は、状態報告が生成したフレームのフレーム番号に置き換えられることができ、送信完了時間は、送信が完了したフレームのフレーム番号に置き換えられることができる。具体的に、このフレーム番号は、階層的な構成を有しても良い。例えば、ＬＴＥでは、送受信単位が０．５ｍｓｅｃの短い期間であるため、システムは、０．５ｍｓｅｃの単位でフレームを認識するよりは、フレームの単位として１０ｍｓｅｃより長い期間を使用し、サブフレームの単位として０．５ｍｓｅｃを使用することができる。すなわち、１０ｍｓｅｃの長さを有する１つのフレームが０．５ｍｓｅｃの長さを有する２０個のサブフレームで構成されるシステムにおいて、フレーム番号とサブフレーム番号との組合せは、時間のインデックスとして使用されることができる。例えば、時間２５０５．１１は、フレーム＃２５０５内のサブフレーム＃１１を意味する。
【００３６】
図７に示すように、ＡＲＱエンティティ７００は、送信制御部７０５と、送信バッファ７１０と、フレーミング装置７１５と、再送信バッファ７２０と、状態報告生成部７４０と、受信バッファ７４５と、を含む。また、ＡＲＱエンティティ７００は、多重化器（ＭＵＸ）７２５及び逆多重化器（ＤＥ-ＭＵＸ）７５０に接続される。ここには、１つのＡＲＱエンティティ７００のみを図示しているが、図示していない複数のＡＲＱエンティティが提供されてよい。多重化器７２５は、複数のＡＲＱエンティティ７００から伝達されたＡＲＱパケット（すなわち、ＡＲＱ ＰＤＵ）を１つのＨＡＲＱパケットに多重化し、逆多重化器７５０は、ＨＡＲＱプロセッサ７３０から伝達されたＨＡＲＱパケットを複数のＡＲＱパケット（すなわち、ＡＲＱ ＰＤＵ）に逆多重化し、ＡＲＱパケットを対応するＡＲＱエンティティに伝達する。
ＨＡＲＱプロセッサ７３０は、特定のＨＡＲＱ動作を介してＨＡＲＱパケットを送受信する装置であり、送受信部７３５は、ＨＡＲＱパケットを無線信号に変調して送信し、受信した無線信号を復調する装置である。逆多重化器７５０は、受信したＡＲＱ ＰＤＵを受信バッファ７４５に格納する。
【００３７】
状態報告生成部７４０は、所定の状態報告生成条件のうちのいずれか１つが満たされると、状態報告がトリガーされることを送信制御部７０５に報告する。この後に、送信制御部７０５が状態報告の送信を許可すると、状態報告生成部７４０は、受信バッファ７４５に記憶されているＡＲＱ ＰＤＵのシーケンス番号を検査し、成功裡に受信されたＡＲＱ ＰＤＵ及び再送信のために要請されるＡＲＱ ＰＤＵのシーケンス番号を認識し、これに従って状態報告を構成する。状態報告生成部７４０は、この構成された状態報告を多重化器７２５を介して相手側ノードに送信する。
上位レイヤーで発生したパケットは、送信バッファ７１０に格納される。この上位レイヤーパケットは、フレーミング装置７１５により適切なサイズでフレーミングされ、ここに挿入されたシーケンス番号を含むヘッダー情報を有するＡＲＱパケットに構成された後に、多重化器７２５に伝達される。この際には、ＡＲＱパケットのコピーは、再送信バッファ７２０に格納される。
【００３８】
送信制御部７０５は、状態報告生成部７４０から伝達された状態報告のトリガー報告を解析し、この解析の結果に基づいて、送信バッファ７１０及び再送信バッファ７２０のデータ送信を制御する。具体的に、送信制御部７０５は、バッファ７１０及び７２０に格納されているデータの量を下位レイヤーに報告し、下位レイヤーから報告された次の送信期間で送信可能なデータの量に基づいており、送信制御部７０５は、次の送信期間で送信されるデータを決定し、バッファ７１０及び７２０を制御することにより、適切なデータを出力する。この送信可能なデータの量は、割り当てられた送信リソースに従って決定される。
特に、状態報告生成部７４０から状態報告のトリガー報告を受信すると、送信制御部７０５は、データ送信の許可を下位レイヤーから受信する場合には、状態報告を生成するように、これを状態報告生成部７４０に通知する。したがって、ＡＲＱエンティティ７００において、データ送信が実際に許可された時点で、状態報告生成部７４０は、状態報告を生成し、この状態報告は、割り当てられた送信リソースを用いて直ちに送信される。
【００３９】
ＥＮＢスケジューリングが適用される移動通信システムにおいて、本発明は、ＡＲＱ Ｒｘエンティティで状態報告が生成される時点を状態報告が実際に送信される時点に一致させることにより、ＡＲＱ Ｔｘエンティティは、この状態報告を含むＨＡＲＱパケットの最初受信時点からこの状態報告が生成された時間を知ることができ、不正確な状態報告による非効率性を最小にすることができる。
【００４０】
以上、本発明を具体的な実施形態を参照して詳細に説明してきたが、本発明の範囲及び趣旨を逸脱することなく様々な変更が可能であるということは、当業者には明らかであり、本発明の範囲は、上述の実施形態に限定されるべきではなく、特許請求の範囲の記載及びこれと均等なものの範囲内で定められるべきである。
【図面の簡単な説明】
【００４１】
【図１】次世代ＵＭＴＳ移動通信システムの構成の一例を示す図である。
【図２】一般的な移動通信システムにおける状態報告送信手続きを示すフロー図である。
【図３】本発明の好ましい実施形態による状態報告送信手続きを示すフロー図である。
【図４】本発明の好ましい実施形態によるＡＲＱ Ｒｘエンティティにおける状態報告の生成及び送信過程を示すフローチャートである。
【図５】本発明の好ましい実施形態によるＨＡＲＱ Ｒｘエンティティの動作を示すフローチャートである。
【図６】本発明の好ましい実施形態によるＡＲＱ Ｔｘエンティティの動作を示すフローチャートである。
【図７】本発明の好ましい実施形態によるＡＲＱ Ｔｘ／Ｒｘエンティティの構成を示すブロック図である。
【符号の説明】
【００４２】
７００  ＡＲＱエンティティ
７０５  送信制御部
７１０  送信バッファ
７１５  フレーミング装置
７２０  再送信バッファ
７２５  ＭＵＸ
７３０  ＨＡＲＱプロセッサ
７３５  送受信部
７４０  状態報告生成部
７４５  受信バッファ
７５０  ＤＥ−ＭＵＸ
【図１】
2009533942.tif 000003
【図２】
2009533942.tif 000004
【図３】
2009533942.tif 000005
【図４】
2009533942.tif 000006
【図５】
2009533942.tif 000007
【図６】
2009533942.tif 000008
【図７】
2009533942.tif 000009
【国際調査報告】
2009533942.tif 000010
2009533942.tif 000011