JP3968097B2

JP3968097B2 - 通信システムにおけるステータス報告欠落検出

Info

Publication number: JP3968097B2
Application number: JP2004256413A
Authority: JP
Inventors: 孝祥江
Original assignee: Innovative Sonic Ltd
Current assignee: Innovative Sonic Ltd
Priority date: 2003-09-14
Filing date: 2004-09-03
Publication date: 2007-08-29
Anticipated expiration: 2024-09-03
Also published as: US20050066255A1; CN1595839A; EP1517468A2; KR20050027195A; KR100605318B1; TWI246284B; TW200511779A; JP2005094751A; CN100353701C; EP1517468A3

Description

本発明は、ワイヤレス通信システムに関し、特に、かかるシステムにおけるパケットによる通信の方法に関する。

ワイヤレス通信デバイスに対する一般の需要の高まりにより、業界では、更に高度な通信規格を策定することに関して圧力がかかっている。第３世代パートナーシッププロジェクト（３ＧＰＰ）は、こうした新しい通信プロトコルの例である。こうした規格では、通信に対する３層のアプローチを利用し得る。図１を参照する。図１は、こうした通信プロトコルにおける３層のブロック図である。通常のワイヤレス環境において、第１の局１０は、１つ以上の第２の局２０とワイヤレス通信する状態にある。第１の局１０のアプリケーション１３は、メッセージ１１を構成し、メッセージ１１を第３層インタフェース１２に渡すことで、メッセージ１１を第２の局２０に伝達させる。アプリケーション１３の送受信インタフェースとして使用されるのに加え、第３層インタフェース１２は、第１の局１０と第２の局２０との間での第３層の動作を制御する目的で、第３層信号メッセージ１２ａを生成してもよい。こうした第３層信号メッセージの例は、第１および第２の局の両方の第３層インタフェース１２，２２によってそれぞれ生成される暗号鍵の変更に関する要求である。第３層インタフェース１２は、メッセージ１１もしくは第３層信号メッセージ１２ａのいずれかを、第２層サービスデータユニット（ＳＤＵ）の形態で、第２層インタフェース１６に伝達する。第２層ＳＤＵ１４は、任意の長さにしてよく、第３層インタフェース１２，２２によって命令された内部形式を有する。第２層インタフェース１６は、ＳＤＵ１４を、１つ以上の第２層プロトコルデータユニット（ＰＤＵ）１８にする。各第２層ＰＤＵ１８は、固定長で、第２層インタフェース１６，２６によって命令された内部構造を有する。第２層ＰＤＵ１８は、次に、第１層インタフェース１９に渡される。第１層インタフェース１９は、物理層であり、データを第２の局２０に送信する。送信データは、第２の局２０の第１層インタフェース２９によって受信され、１つ以上のＰＤＵ２８に再構築され、その後、上の第２層インタフェース２６へ渡される。第２層インタフェース２６は、ＰＤＵ２８を受領し、１つ以上の第２層ＳＤＵ２４を構築する。第２層ＳＤＵ２４は、上の第３層インタフェース２２に渡される。第３層インタフェース２２は、次に、第２層ＳＤＵ２４を変換して、第１の局１０のアプリケーション１３によって生成されたオリジナルメッセージ１１と同一になるべきであるメッセージ２１か、あるいは、第３層インタフェース１２によって生成されたオリジナルの信号メッセージ１２ａと同一になるべきで、その後、第３層インタフェース２２によって処理される第３層信号メッセージ２２ａかの一方に戻される。受信メッセージ２１は、第２の局２０のアプリケーション２３に渡される。

一般的に言って、送信する第１の局１０の各層は、メッセージ１１と上層からの任意の付加データを運ぶために情報を追加する。例えば、第３層インタフェースは、アプリケーションメッセージ１１を１つ以上の第２層ＳＤＵ１４にパックする。各第２層ＳＤＵは、メッセージ１１からのデータを含むだけでなく、第３層インタフェース１２，２２によって必要とされる内部情報を含む。第２層インタフェース１６は、同じように、第２層ＳＤＵ１４を第２層ＰＤＵ１８にパックし、そのそれぞれは、第２層インタフェース１６，２６によって必要とされる追加情報も有する。受信側の第２の局２０では、各層が、その層に特定の追加情報を除去し、残りを上層に渡す。したがって、第２層インタフェース２６は、第２層ＰＤＵ２８の受信ストリームから第２層ＳＤＵ２４をアンパックし、第２層ＳＤＵ２４のみを上の第３層インタフェース２２に渡す。同様に、第３層インタフェース２２は、第２層ＳＤＵ２４からメッセージ２１をアンパックし、完全なメッセージデータ２１のみをアプリケーション２３に渡す。本開示を通じて使用される用語に関して、ＰＤＵは、情報を送受信するために層によって内部的に使用されるデータ単位であり、一方ＳＤＵは、上層へ渡される、あるいは、上層から受領するデータ単位である。したがって、第３層ＰＤＵは、第２層ＳＤＵと正確に同じである。同様に、第２層ＰＤＵは、第１層ＳＤＵと呼ぶことができる。以下の開示の目的から、短縮した「ＳＤＵ」という用語は、第２層ＳＤＵ（即ち、第３層ＰＤＵ）を示すのに使用され、「ＰＤＵ」という用語は、第２層ＰＤＵ（即ち、第１層ＳＤＵ）と理解するべきである。

特に関心を寄せるのは、アプリケーション１３，２３の相対的にハイエンドのデータ送受信要求と、第１層インタフェース１９，２９での物理的送受信プロセスの低レベルの要求との間でバッファとして機能する、第２層インタフェース１２，２２である。図２を参照する。図２は、第２層の観点から見た送信／受信プロセスの図である。トランスミッタ３０の第２層インタフェース３２は、基地局もしくはモバイルユニットのいずれかにしてよく、第３層インタフェース３３から第２層ＳＤＵ３４のストリングを受領する。第２層ＳＤＵ３４は、１〜５で連続的に順序付けられ、長さは等しくない。第２層インタフェース３２は、第２層ＳＤＵ３４のストリングを、第２層ＰＤＵ３６のストリングにパックする。第２層ＰＤＵ３６は、１〜４で連続的に順序付けられ、全て等しい長さである。第２層ＰＤＵ３６のストリングは、その後、送信のために第１層インタフェース３１へ送り出される。同じく基地局もしくはモバイルユニットにしてよい受信器側４０では、反対のプロセスが発生し、受信器の第２層インタフェース４２は、第２層ＰＤＵ４６の受信ストリングを、第２層ＳＤＵ４４の受信ストリングにアンパックする。特定の伝送モード下において、多層プロトコルは、受信器の第２層インタフェース４２が第２層ＳＤＵを第３層インタフェース４３に対して順番に提供することを求める。即ち、第２層インタフェース４２は、ＳＤＵ１で始まりＳＤＵ５で終了するＳＤＵ４４の連続的順序通りに、ＳＤＵ４４を第３層インタフェース４３に提供する必要がある。ＳＤＵ４４の順序はスクランブル化されず、後続のＳＤＵは、先行する全てのＳＤＵが伝達されるまで第３層に伝達されない。

ライン送信において、こうした要件は、比較的容易に満たされる。しかしながら、ワイヤレス送信のノイズの多い環境において、基地局もしくはモバイルユニットである受信器４０は、データを失う場合が多い。したがって、ＰＤＵ４６の受信ストリングにおいて、一部の第２層ＰＤＵが失われる。そのため、第２層ＳＤＵ４４が順番に提供される状態を確保することは、大きな困難を引き起こす可能性がある。ワイヤレスプロトコルは、こうした問題に対処するために慎重に設計される。

一般的には、２種類のＰＤＵ、即ち、制御ＰＤＵとデータＰＤＵとが存在する。制御ＰＤＵは、データ送信および受信プロトコルを制御するために、第２層インタフェース１６，２６によって使用される。これは、第３層インタフェース１２，２２の信号メッセージ１２ａ，２２ａの交換にいくらか類似する。しかしながら、第２層インタフェース１６，２６は、第３層信号メッセージ１２ａ，２２ａを解釈もしくは認識しないが、第２層インタフェース１６，２６は、第２層制御ＰＤＵを認識し、第２層制御ＰＤＵを上の第３層インタフェース１２，２２に渡さない。データＰＤＵは、上層、即ち、第３層インタフェース１２，２２からのデータを送信するのに使用される。データＰＤＵの受信時、内部に含まれるデータは再構築され、上の第３層インタフェース１２もしくは第３層インタフェース２２に提供される。

図３は、３ＧＰＰＴＳ２５．３２２規格において定義される、応答モードデータＰＤＵ（ＡＭＤＰＤＵ）５０の簡略化ブロック図である。ＡＭＤＰＤＵ５０は、データＰＤＵであり、第２層プロトコルによって定義されるように、いくつかのフィールドに分割される。第１のフィールド５１は、ＰＤＵ５０がデータＰＤＵ（「Ｄ」）もしくは制御ＰＤＵ（「Ｃ」）のいずれであるかを示す単一ビットである。データ／制御ビット５１が設定された場合（即ち、１に等しい場合）、ＰＤＵ５０は、データＰＤＵとされる。第２のフィールド５２は、シーケンス番号フィールドである。連続するＰＤＵ１８，２８は、連続して高くなるシーケンス番号を有し、これにより、第２の局２０は、第２層ＰＤＵ２８を正確に再構築し、第２層ＳＤＵ２４を形成できる。即ち、第１のＰＤＵ１８が５３６に等しいシーケンス番号を伴って送信された場合、次のＰＤＵ１８は、５３７に等しいシーケンス番号を伴って送信され、その後も同様となる。シーケンス番号フィールド５２が長さ１２ビットである場合、シーケンス番号フィールド５２は、最大値４０９５を保持できる。この最大値４０９５の後、ＰＤＵ１８，２８のシーケンス番号は、ゼロに戻り、再び増分を始める。単一のポーリングビット５３が、シーケンス番号フィールド５２に続く。ポーリングビット５３が設定される場合（即ち、「１」の場合）、このＰＤＵに応答したステータス報告が必要となる。ポーリングビット５３に続くのは、リザーブされ、ゼロに設定される単一ビット５４ａである。次のビット５５ａは拡張ビットであり、設定される時には、それぞれの拡張ビット５５ｂ，５５ｃを有する１つ以上の後続の長さインジケータ５６ａ，５６ｂの存在を示す。長さインジケータは、通常、７ビット長または１５ビット長であり、第２層ＰＤＵ５０内の第２層ＳＤＵデータの終了位置を示すために使用される。長さインジケータに続くのは、ＳＤＵデータ５７ａと、パディングもしくはピギーバックステータスＰＤＵ５７ｂとである。

長さインジケータと、データと、パディングもしくはピギーバックステータスＰＤＵとの量は、図解したＰＤＵの例から変化させることが可能であり、これを決定する条件は広く知られている。

ポーリングビット５３は、ＰＤＵ５０の受信器（即ち、第２の局２０）が１つ以上のステータスＰＤＵを含むステータス報告により応答するべきであることを示すために設定される。ステータス報告は、受信器、即ち、第２の局２０の受信ステータスを、トランスミッタ、即ち、第１の局１０に対して通知するために使用される。ステータス報告により、第１の局１０は、どのＰＤＵ１８が第２の局２０によって受信されたかを判断でき、したがって、どのＰＤＵ１８を再送信する必要があるかを判断できる。第１の局１０は、第２の局２０にステータス報告の送信を要求するために、ポーリングビット５３を「１」に設定する。

図４は、代表的なステータスＰＤＵ６０を例示している。ステータスＰＤＵは、ステータスＰＤＵが制御ＰＤＵであるため未設定（「０」）となるデータ／制御ビット６１と、この場合は「０００」に設定されるＰＤＵタイプフィールドと、複数の変数のスーパフィールド６３ａ〜６３ｋと、必要な場合や時期にはパディング６４とを含む。以前に説明したＡＭＤＰＤＵ５０のように、ステータスＰＤＵ６０がＡＭＤＰＤＵにピギーバックされる時、データ／制御ビット６１は、リザーブビットとなる。ステータスＰＤＵ６０がステータス報告の全体もしくは一部を提供できる方法の１つは、正確に受信されなかったＰＤＵのリストをスーパフィールド６３ａ〜６３ｋに含めることである。こうしたリストは、通常、正確に受信されなかったＰＤＵのシーケンス番号および長さを含む。

一般に、応答モード（ＡＭ）において、第１の局１０もしくは第２の局２０のような受信器は、第１の局１０もしくは第２の局２０のような送信器に対して報告を送り返す。送信器は、その後、これに応じて、否定応答されたＰＤＵを再送信し、肯定応答されたＰＤＵをバッファから廃棄する。あらゆるＰＤＵと同様に、ステータス報告の全体もしくは一部を形成するステータスＰＤＵは、無線リンクにおいて失われる可能性がある。従来技術では、欠落したステータスＰＤＵを検出するために、推定ＰＤＵカウンタ（ＥＰＣ）メカニズムが使用される。ＥＰＣメカニズムは、１つのＥＰＣタイマと、１つのＥＰＣ状態変数とを使用する。

ＥＰＣタイマでは、ステータス報告の送信と第１の再送信ＡＭＤＰＤＵとの間の往復時間を考慮することが意図される。基本的には、ＥＰＣタイマは、ステータス報告の第１のステータスＰＤＵが送信された時にスタートする。ＥＰＣタイマが満了すると、ＥＰＣ状態変数ＶＲ（ＥＰ）が減分される。ＶＲ（ＥＰ）は、最新のステータス報告の送信の結果として、再送信が依然として予想されるＡＭＤＰＤＵの数として定義される。したがって、送信時間間隔（ＴＴＩ）の終わりに、ＶＲ（ＥＰ）は、対応する論理チャネル上のＴＴＩ中に受信されたはずであるＡＭＤＰＤＵの推定数によって減分される。

技術仕様書（３ＧＰＰＴＳ２５．３２１）技術仕様書（３ＧＰＰＴＳ２５．３２２）

しかしながら、従来技術の主要な欠点の１つは、ＴＴＩ内での受信済みＡＭＤＰＤＵの推定数が不確実なことである。更に、高速ダウンリンクパケットアクセス（ＨＳＤＰＡ）において使用されるハイブリッド自動反復要求（ＨＡＲＱ）手順では、中間アクセス制御（ＭＡＣ）層においてＰＤＵが実際に再送信され得るため、ＶＲ（ＥＰ）カウントダウンプロセスは不適切である。上記のシステムのその他の不都合は、特定の用途において明らかになり得る。

したがって、本発明の主要な目的は、上記の問題を解決するために、欠落したステータス報告の検出に関する方法を提供することである。

簡単にまとめると、本発明による、欠落したステータス報告を通信システムの受信器によって検出する方法は、１回目のステータス報告を送信器に送るステップと、往復タイマを開始するステップと、往復タイマを満了させるステップと、１回目のステータス報告において特定された全ての否定応答ＡＭＤＰＤＵが受信器で受信される前に所定のＡＭＤＰＤＵを受信するステップと、これにより、２回目のステータス報告が必要であることを判断するステップとを含む。

本発明による方法の利点は、この方法が決定論的であり、通信システムの送信条件に対する適応性を有することである。

本発明による方法の利点は、この方法が送信スループットを向上させることである。

本発明の上記その他の目的は、様々な図および図面において例示される以下の好適な実施形態の詳細な説明を読んだ後、当業者には疑いなく明らかとなろう。

以下の説明では、３ＧＰＰ規格ＴＳ２５．３２２Ｖ４．９．０において開示される通信プロトコルを例として使用する。しかしながら、第３層データを第２層プロトコルデータユニット（ＰＤＵ）にパックする任意のワイヤレス通信プロトコルは、本明細書に含まれる開示から利益を得る場合がある。更に、以下の詳細な説明の送信器および受信器は、携帯／移動電話、パーソナルデジタルアシスタント（ＰＤＡ）、パーソナルコンピュータ（ＰＣ）、基地局、ネットワーク、あるいは、３層ワイヤレス通信プロトコルを利用する他の任意のデバイスを含むことができる。

図５を参照すると、本発明による方法の概略図が例示されている。図５において、時間は、下に向かって進む。通信システム１００は、無線リンクを通じて通信する図１の第１の局１０および第２の局２０のような装置にすることが可能な送信器１０２と受信器１０４とを含む。

図５に示すように、受信器１０４は、単一のステータスＰＤＵ１０６を含む１回目のステータス報告を送信する。ステータス報告は１つもしくは複数のステータスＰＤＵを有することができるが、ここでは例示の目的でのみ、１つのものが使用される。受信器１０４は、受信済みＡＭＤＰＤＵにポーリングビットが設定されていること（図３、ポーリングビット５３を参照）、受信器１０４が欠落したＡＭＤＰＤＵを検出したこと、周期的なステータスタイマ（「Ｔｉｍｅｒ＿Ｓｔａｔｕｓ＿Ｐｅｒｉｏｄｉｃ」として知られる）の満了を検出したこと、あるいは、その他の類似するもしくは周知のイベントに応答して、ステータスＰＤＵ１０６を送信する。ステータス報告は、技術の更なる進歩に応じて、説明したものとは異なる別の条件によってトリガされることも可能である。

本発明によれば、１回目のステータス報告を送信した後、受信器１０４は、図５において１１２として概略的に表される往復タイマを初期化すなわち開始する。往復タイマ１１２の継続時間は、少なくとも、往復伝搬遅延と、送信器１０２の処理時間と、受信器１０４の処理時間との和に設定される。これは、推定値、測定値、あるいは、上層によって決定される規定値である。送信器１０２および受信器１０４での処理時間は、これらの装置がどのくらい迅速にＰＤＵを解釈、組み立て、分解、処理できるかによって決まる。往復タイマ１１２は、開始された後、満了するまで、アクティブであるとみなされる。好適な実施形態において、往復タイマ１１２は、受信器１０４に位置する。

往復タイマ１１２がアクティブである間に、受信器１０４は、１回目のステータス報告が送信されていないかのように、通常通りＡＭＤＰＤＵを受信する。往復タイマ１１２が満了になった後、１回目のステータス報告において特定された否定応答ＡＭＤＰＤＵが受信される前に、受信器は所定のタイプのＡＭＤＰＤＵ１８を待ち受け、検出する。所定のタイプとは、単に、以下のいずれかであるＡＭＤＰＤＵを意味する：１回目のステータス報告において否定応答されなかったＡＭＤＰＤＵ、ポーリングビットが設定されたＡＭＤＰＤＵ（図３、ポーリングビット５３を参照）、直前の否定応答ＡＭＤＰＤＵ、あるいは、欠落した１回目のステータス報告において連続的に先行する否定応答ＡＭＤＰＤＵを伴う否定応答ＡＭＤＰＤＵ。つまり、受信器１０４は、これらのタイプのＰＤＵのうち任意の１つ、２つ、３つ、または４つに応答するように構成できる。必然的に、受信器１０４は、所定のＡＭＤＰＤＵを検出しながら、通常の動作もしくはプロセスを引き続き実行可能であり、受信器１０４がサスペンド状態に入る必要はない。しかしながら、受信器１０４は、往復タイマ１１２がアクティブである間、その他のステータス報告の送信を遅延させることができる。往復タイマ１１２の満了後、（図５に示すケースのように）所定のタイプのＡＭＤＰＤＵ１０８が送信器１０２から到着した場合、受信器１０４は、これに応じて、２回目のステータス報告が必要であると判断する。

上記の所定のタイプのＡＭＤＰＤＵ１０８によってトリガされる２回目のステータス報告を除き、周期的ステータスタイマの満了等、他の何らかの原因により往復タイマ１１２が満了となった後、３回目のステータス報告がトリガされた場合、受信器１０４は、１回目のステータス報告のモニタリングプロセスが終了するまで、あるいは、２回目のステータス報告がトリガされるまで、３回目のステータス報告を保留すなわち遅延する。当然ながら、２回目のステータス報告がトリガされた場合、３回目のステータス報告と２回目のステータス報告とは、結合されて１つになる。

受信器１０４によって２回目のステータス報告が必要であると判断された時、受信器１０４は、ステータスＰＤＵ１１０によって例示する１つ以上のステータスＰＤＵを含んだ更新済みステータス報告を送信する。更新済みステータス報告を送信する前に、受信器１０４は、こうしたステータス報告が禁止されているかどうかを判断できる。ステータス報告が禁止されている場合、受信器１０４は、こうした禁止が無効になるのを待つ、あるいは、上層もしくは下層に連絡するといった別の行動方針をとることができる。２回目のステータス報告が必要であることを判断する代わりに、受信器１０４が１回目のステータス報告において特定された全ての否定応答ＡＭＤＰＤＵを受信した場合、受信器１０４は、１回目のステータス報告が送信器１０２によって受信されたと判断する。したがって、受信器１０４は、１回目のステータス報告のモニタリングを停止し、往復タイマ１１２を停止もしくは無効化し、トリガされていた遅延中の３回目のステータス報告を送信し、通常動作に戻る。

図６は、受信器１０４で実行されるものとして、本発明による方法２００の簡略化フローチャートを例示している。最初に、ステップ２０２において、受信器１０４は、１回目のステータス報告（図４のＰＤＵ６０もしくは図５のＰＤＵ１０６等）を送信器１０２に送る。次に、受信器１０４は、ステップ２０４において、往復タイマ１１２を開始する。受信器１０４は、ステップ２１０において、往復タイマ１１２の満了をチェックする。ステップ２１０は、タイマ１１２の満了まで、繰り返しチェックされる。その後、受信器１０４は、１回目のステータス報告に記載された全ての否定応答ＡＭＤＰＤＵが受信されたかをステップ２０６で判断する。こうした全てのＡＭＤＰＤＵが受信されている場合、ステップ２１４が実行され、受信器１０４は、送信器１０２が１回目のステータス報告の受信に成功すると判断し、方法２００は終了する。全ての否定応答ＡＭＤＰＤＵが受信されなかった場合、ステップ２０８において、所定のＡＭＤＰＤＵ（ＰＤＵ１０８、図５）が受信されたかどうかを判断し、これにおいて、所定のＡＭＤＰＤＵのタイプは上記の通りである。所定のＡＭＤＰＤＵが受信されなかった場合、受信器１０４は、ステップ２０６に戻る。こうした所定のタイプのＰＤＵが受信された場合、受信器１０４は、ステップ２１２において、１回目のステータス報告に記載された全ての否定応答ＡＭＤＰＤＵが受信され、ステップ２０２で最初のステータス報告が送出された後、ポールが受信されていないかをチェックする。このチェックの結果が真である場合、ステップ２１４が実行され、受信器１０４は、送信器１０２が１回目のステータス報告の受信に成功したものと判断し、方法２００は終了する。そうではなく、１回目のステータス報告に記載された少なくとも１つの否定応答ＡＭＤＰＤＵが受信されなかった場合、あるいは、ステップ２０２の後でポールが受信された場合、受信器１０４は、ステップ２１６において、２回目のステータス報告（例えば、ステータスＰＤＵ１１０、図５）を送信し、方法２００は終了する。少なくとも１つの否定応答ＡＭＤＰＤＵが受信されず、所定のタイプのＰＤＵが受信された時、方法２００は、２回目のステータス報告により終了し、全ての否定応答ＡＭＤＰＤＵが受信された時、方法２００は、２回目のステータス報告を伴わずに終了すると理解できる。結果として、受信器１０４によって実行される方法２００は、本発明の一実施形態を提供する。

方法２００の別の実施形態において、ステップは、図６に示す順序にする必要はない。例えば、ステップ２０６およびステップ２０８は、容易に逆にすることができる。加えて、別の実施形態では、いずれか、もしくは全てのステップを、受信器１０４以外のデバイスに実行させることができる。更に、ステップ２１４等、一部のステップは、特定の用途に合わせて省略できる。方法２００には開始および終了があるが、受信器１０４は、方法２００の実行中に、他の動作に着手するのを妨げられないと理解するべきである。更に、２回目のステータス報告を送るためにステップ２１６が実行される場合、方法２００は、反復することができる。言い換えると、ステップ２１６の後、受信器１０４は、ステップ２０４を実行し、次の反復の１回目のステータス報告として、２回目のステータス報告を処理する。

本発明による方法は、マイクロプロセッサ、プロセッサ、中央演算処理装置（ＣＰＵ）、コンピュータ、デジタルカウンタ、または、論理回路といったハードウェア、プログラム命令、実行可能コード、または、ファームウェアといったソフトウェア、あるいは、ハードウェアおよびソフトウェアの組み合わせにより格納し、実行することができる。

従来技術とは対照的に、本発明は、往復タイマの満了後、１回目のステータス報告において特定された全ての否定応答ＡＭＤＰＤＵが受信される前に、１回目のステータス報告において否定応答されなかったＡＭＤＰＤＵ、ポーリングビットが設定されたＡＭＤＰＤＵ、直前の否定応答ＡＭＤＰＤＵ、あるいは、欠落した１回目のステータス報告において連続的に先行する否定応答ＡＭＤＰＤＵを伴う否定応答ＡＭＤＰＤＵが受信された時、更新したステータス報告が必要であると判断する。そのため、本発明は、欠落したステータス報告を検出する決定論的方法を提供し、多くの利点の一つとして、送信スループットの改善が伴う。

当業者は、本発明の教示内容を維持しつつ、装置の多数の変形および変更を実施し得ることを容易に見いだせると考えられる。したがって、上記の開示内容は、添付した特許請求の境界によってのみ限定されるべきである。

従来の３層通信プロトコルのブロック図。第２層の観点から見た従来の送信／受信プロセスの簡略図。従来のＡＭＤＰＤＵの簡略ブロック図。従来のステータスＰＤＵの簡略ブロック図。欠落したステータス報告を検出する本発明の方法の概略図。欠落したステータス報告を検出する本発明の方法のフローチャート。

Claims

受信器と送信器とを含みデータが応答モードデータプロトコルデータユニットにより通信される通信システムにおいて、欠落したステータス報告を受信器により検出する方法であって、
第１のトリガに応答して１回目のステータス報告を前記送信器に送るステップと、
往復タイマを開始するステップと、
前記往復タイマの満了後、前記１回目のステータス報告において特定された全ての否定応答応答モードデータプロトコルデータユニットが前記受信器で受領される前に、所定の応答モードデータプロトコルデータユニットを受領するステップと、
前記所定の応答モードデータプロトコルデータユニットの受領に応じて、２回目のステータス報告が必要であると判断するステップと、
を備える方法。
請求項１記載の方法であって、
前記２回目のステータス報告が必要であると判断するステップは、さらに、
前記２回目のステータス報告を前記送信器に送るステップを含む、方法。
請求項１記載の方法であって、
前記２回目のステータス報告が必要であると判断するステップは、さらに、
ステータス報告が禁止されていないと判断するステップと、
前記２回目のステータス報告を前記送信器に送るステップと、
を含む、方法。
請求項３記載の方法であって、
前記ステータス報告が禁止されていないと判断するステップは、ステータス報告禁止タイマをチェックすることで実行される、方法。
請求項１記載の方法であって、
前記往復タイマの継続時間は、少なくとも、伝搬遅延時間と、前記送信器または前記受信器の少なくとも一方の処理時間と、の和に設定される、方法。
請求項１記載の方法であって、
前記往復タイマの継続時間は、少なくとも、往復伝搬遅延時間と前記送信器の処理時間と前記受信器の処理時間との和に設定される、方法。
請求項１記載の方法であって、
前記所定の応答モードデータプロトコルデータユニットは、前記１回目のステータス報告において否定応答されなかった応答モードデータプロトコルデータユニットである、方法。
請求項１記載の方法であって、
前記所定の応答モードデータプロトコルデータユニットは、ポーリングビットが設定された応答モードデータプロトコルデータユニットである、方法。
請求項１記載の方法であって、
前記所定の応答モードデータプロトコルデータユニットは、前記１回目のステータス報告における直前の否定応答応答モードデータプロトコルデータユニットである、方法。
請求項１記載の方法であって、
前記第１のトリガは、期間タイマの満了の検出である、方法。
請求項１記載の方法であって、
前記第１のトリガは、ポーリングビットが設定された応答モードデータプロトコルデータユニットの受領である、方法。
請求項１記載の方法であって、
前記第１のトリガは、少なくとも１つの欠落した応答モードデータプロトコルデータユニットの検出である、方法。
請求項１記載の方法であって、
前記１回目のステータス報告は現行のステータス報告であり、前記２回目のステータス報告は後続のステータス報告であり、
前記方法は、さらに、
全てのステップを反復的に繰り返して、前記後続のステータス報告を前記１回目のステータス報告とするステップを備える、方法。
請求項１記載の方法であって、
前記２回目のステータス報告は、前記受信器の更新された受信ステータスを含む、方法。
請求項１記載の方法であって、
前記第１のトリガに応答して前記１回目のステータス報告を前記送信器に送るステップは、さらに、第２のトリガに応答した３回目のステータス報告の前記送信器への送信を遅延させるステップを含む、方法。
請求項１５記載の方法であって、
前記第２のトリガは、期間タイマの満了である、方法。
請求項１５記載の方法であって、
２回目のステータス報告が必要であると判断された後、
前記１回目のステータス報告において特定された全ての否定応答応答モードデータプロトコルデータユニットを受信し、
前記１回目のステータス報告が前記送信器により受信されたと判断し、
遅延された前記第２のトリガに応答して、前記３回目のステータス報告を送信する、方法。