(57)【特許請求の範囲】
【請求項１】
無線通信システム（100）に含まれる第１のノード（110）と第２のノード（130）との間の無線リンクを介したデータユニットの送信を制御するための、前記第１のノード（110）における方法であって、
前記第１のノード及び前記第２のノードのうちの一方が基地局であり、他方がユーザ装置であり、前記方法は、
データユニットを前記第２のノード（130）から受信するステップ（401）と、
前記第２のノード（130）から受信されていることが期待されている任意のデータユニットが、未受信であるかどうかを検出するステップ（402）と、
未受信のデータユニットについて行われた前記検出に基づいて、状態報告を生成するステップ（403）と、
前記生成された状態報告をバッファ（503）にバッファリングするステップ（404）と、
受信されたデータユニット又は未受信のデータユニットについての変化が検出されると、前記バッファリングされた状態報告を更新するステップ（405）と、
前記第２のノード（130）から状態報告のリクエストを受信するステップ（406）と、
前記受信された状態報告のリクエストに対する応答として、前記生成された状態報告を前記第２のノード（130）に送信するステップ（412）と
を含み、
前記第１のノード（110）は、受信された状態報告のリクエストに対する応答として送信された状態報告の数を計数するトリガカウンタ（512）を備え、
前記方法は、
受信されたリクエストに起因して状態報告が送信されるごとに、前記トリガカウンタの値を１だけインクリメントするステップ（407）と、
インクリメントされた前記トリガカウンタの値を前記バッファリングされた状態報告に付加するステップ（408）と
をさらに含むことを特徴とする方法。
【請求項２】
最新の状態報告が前記第２のノード（130）に送信されてから経過した時間を測定するステップ（409）と、
前記測定された時間が、予め定められた閾値を超えるかどうかを検査するステップ（410）と、
前記状態報告のインクリメントされた前記トリガカウンタの値が、前記最新の状態報告の前記トリガカウンタの値と異なるかどうかを検査するステップ（411）と
をさらに含むことを特徴とする請求項１に記載の方法。
【請求項３】
前記状態報告を前記第２のノードに送信する前記ステップ（412）は、前記測定された時間が予め定められた閾値を超え、かつ、前記状態報告のインクリメントされた前記トリガカウンタの値が、前記最新の状態報告の前記トリガカウンタの値と異なる場合にのみ、実行されることを特徴とする請求項１または２に記載の方法。
【請求項４】
前記第１の装置（110）は、携帯電話を含む、ユーザ装置によって代表されることを特徴とする請求項１乃至３の何れか１項に記載の方法。
【請求項５】
前記第１の装置（110）は、ｅノードＢを含む、基地局によって代表されることを特徴とする請求項１乃至４の何れか１項に記載の方法。
【請求項６】
無線通信システム（100）に含まれる第１のノード（110）と第２のノード（130）との間の無線リンクを介したデータユニットの送信を制御するための、前記第１のノード（110）における装置（500）であって、
データユニットと状態報告のリクエストとをそれぞれ前記第２のノード（130）から受信する受信機（505）と、
前記第２のノード（130）から受信されていることが期待されている任意のデータユニットが、未受信であるかどうかを検出する検出部（501）と、
前記未受信のデータユニットについて行われた前記検出に基づいて、状態報告を生成する状態報告生成部（502）と、
前記生成された状態報告をバッファリングするバッファ（503）と、
受信されたデータユニット又は未受信のデータユニットについての変化が検出されると、前記バッファリングされた状態報告を更新する更新部（504）と、
前記受信された状態報告のリクエストに対する応答として、前記状態報告を前記第２のノード（130）に送信する送信機（511）と、
受信された状態報告のリクエストに対する応答として送信された状態報告の数を計数するトリガカウンタ（512）と
を備え、
前記トリガカウンタの値は、受信されたリクエストに起因して状態報告が送信されるごとに、１だけインクリメントされ、インクリメントされた前記トリガカウンタの値は、前記バッファリングされた状態報告に付加されることを特徴とする装置。
【請求項７】
前記第１の装置（110）は、携帯電話を含む、ユーザ装置によって代表されることを特徴とする請求項６に記載の装置。
【請求項８】
前記第１の装置（110）は、ｅノードＢを含む、基地局によって代表されることを特徴とする請求項６に記載の装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本主題は、無線通信システムに含まれる第１のノードにおける方法及び装置に関するものである。具体的には、本主題は、無線通信システム内でデータユニットの送信を制御するための仕組みに関するものである。
【背景技術】
【０００２】
無線通信システム内の基地局及びユーザ装置等の２つのノード間における、無線通信の伝送品質と通信チャネルのコヒーレンス特性との少なくとも何れかは、信号に対する複数の不要な干渉と無線伝搬状況とに依存して異なる。そのような不要な干渉についての非限定的ないくつかの例は、例えば、熱雑音、干渉であり、伝搬状況に悪影響を与える現象のいくつかの例は、パスロス、信号のマルチパス、ドップラー・スプレッドである。さらに、チャネル推定の精度は伝送品質に影響する。従って、１つのノードから送信されるパケットデータユニット（ＰＤＵ）等のデータユニットは、受信ノードに無秩序に到達するか、歪んで到達するか、又は全く到達しない可能性がある。
【０００３】
このため、送信ノードは、損失したＰＤＵ又は歪んだＰＤＵを受信ノードに再送する必要がありうる。再送を実行するためには、送信ノードは、必要であれば、何れのデータを受信ノードに再送するのかを何とかして通知される必要がある。
【０００４】
データを再送する必要があるかどうかを送信ノードが知るために使用されうる１つの仕組みは、状態報告（status report）を送信ノードに送り返すように、受信ノードに対してポーリング（poll）を行うことである。
【０００５】
第３世代パートナシップ・プログラム（３ＧＰＰ）は、現在、３Ｇのロング・ターム・エヴォリューション（ＬＴＥ：Long Term Evolution）と呼ばれる新たな無線アクセスシステムを標準化しており、進化型（evolved）ＵＴＲＡＮ（Ｅ−ＵＴＲＡＮ）とも称される。
【０００６】
ＵＭＴＳ地上波無線アクセスネットワーク（ＵＴＲＡＮ：UMTS Terrestrial Radio Access Network）等のいくつかの先行システムのように、このシステム（Ｅ−ＵＴＲＡＮ）は、無線リンク上のデータの損失を最小化することを意図した無線プロトコルを含むことになる。これらのプロトコルのうちの１つは、無線リンク制御（ＲＬＣ：Radio Link Control）プロトコルである。ＲＬＣは、第２層のプロトコルとみなされている。ＲＬＣの最も重要な機能の１つは、確認応答モード（ＲＬＣ ＡＭ）において、下位層のプロトコルによって生じる残留誤差を補償することである。
【０００７】
ＲＬＣ ＡＭの動作には、高位層のデータを搬送する無線インタフェースを介したＰＤＵの送信と、受信機側におけるそれらのＰＤＵの並べ替えと、損失したＰＤＵの検出と、損失したとみなされたそれらのＰＤＵについての再送信のリクエストとが含まれる。再送信は、ＳＴＡＴＵＳ ＰＤＵ、又は単にＳＴＡＴＵＳと称される、特別な制御ＰＤＵでリクエストされる。
【０００８】
ＳＴＡＴＵＳは、特別なＰＯＬＬビットを用いて送信機によってリクエストされた際、又は損失したＰＤＵが検出された際に、トリガされる（triggered）。前回のメッセージの後の一定期間内に新たなＳＴＡＴＵＳが送信されることを禁止するために、ＳＴＡＴＵＳメッセージが送信されるごとに、ステータス禁止タイマ（status prohibit timer）が起動されうる。
【０００９】
ＵＭＴＳ地上波無線アクセスネットワーク（ＵＴＲＡＮ）において、ＳＴＡＴＵＳメッセージは、トリガされた際に形成され、又はタイマの終了に応じて形成され、その後、次の送信可能な時に送信するためにバッファリングされていた。これにより、ユーザデータとバッファリングされたＳＴＡＴＵＳメッセージとの両方を含む、即時の送信に利用可能なデータの量を、送信機が正確に知ることを可能にしていた。さらに、例えば基地局において、ＲＬＣ ＡＭエンティティを送信機及び受信機に分割可能にしていた。このため、送信機及び受信機は、場合によっては、物理的に分離可能であった。従って、受信機は、受信したＰＤＵに関する情報を使用してＳＴＡＴＵＳメッセージを生成して、それを送信機に転送可能であった。
【００１０】
ＵＴＲＡＮ リリース６ ＲＬＣについての単純化している他の面は、ＳＴＡＴＵＳ ＰＤＵサイズも、ＰＤＵを送信する論理チャネル上のＰＤＵサイズと一致すると知られていたことである。
【００１１】
Ｅ−ＵＴＲＡＮ ＲＬＣプロトコルは、様々な面でＵＴＲＡＮ ＲＬＣとは異なっている。特に、ＳＴＡＴＵＳは、無線インタフェースを介した送信の前の、可能な限り最も遅い時期に形成されなければならない。ＲＬＣプロトコルは、それ自体、無線インタフェースを介した送信の時刻を決定することはないため、受信されたトリガに起因してＳＴＡＴＵＳが生成される時刻と、ＳＴＡＴＵＳが実際に無線で送信可能な時刻との間に遅延が生じる可能性がある。
【００１２】
従って、Ｅ−ＵＴＲＡＮでは、送信の可能性が得られる際にのみ、即ち、送信前の可能な限り最も遅い時期に、ＳＴＡＴＵＳは形成されなければならないため、ＳＴＡＴＵＳ ＰＤＵを形成して、それらが生成されるのに合わせて下位層に送信することは不可能である。さらに、ＳＴＡＴＵＳ ＰＤＵのサイズは、否定確認応答（ＮＡＣＫ）が送信された数と、それらが、完全なＰＤＵである確認応答モード・データ（ＡＭＤ：Acknowledged Mode Data）用であるか、又はＰＤＵのセグメントであるＡＭＤ用であるかと、に依存して変化する。このことはさらに、送信リソースを予約することを目的として、下位層がＳＴＡＴＵＳ ＰＤＵのサイズに関する情報を必要とするため、問題を生じさせる。
【００１３】
また、この問題は、バッファ状態の報告及びスケジューリングと相まって、上りリンクのＳＴＡＴＵＳ送信に関連している。無線上りリンクは、携帯電話等のユーザ装置からｅノードＢ等の基地局への送信パスである。上りリンク送信は、ユーザ装置においてメディアアクセス制御（ＭＡＣ）層でトリガされるバッファ状態報告によって開始される。これにより、基地局にリクエストが送信される。当該リクエストの受信後、基地局は、上りリンク送信用のリソースをスケジューリングして、適切なグラント（許可信号）をユーザ装置に送信する。当該グラントを受信すると、ユーザ装置のＭＡＣ層は、ＲＬＣ層からのデータをリクエストして、実際の上りリンク送信を生じさせる。
【００１４】
この処理が機能するためには、ＭＡＣが基地局からの送信リソースをリクエストできるように、ＲＬＣにおいてＳＴＡＴＵＳ ＰＤＵがトリガされたことがＭＡＣによって即座に認識されることが必要である。当該リクエストによって生じる遅延は、通常は少なくとも８ｍｓであり、この期間にＲＬＣの状態は著しく変化しうる。これにより、実際に送信されるＳＴＡＴＵＳ ＰＤＵが、送信時に生成されるはずの実際のＳＴＡＴＵＳ ＰＤＵと異なるものになる可能性がある。
【００１５】
従って、第１のＳＴＡＴＵＳ ＰＤＵは、それがトリガされる第１の時刻と、それがｅノードＢに送信される直前の第２の時刻とにおいて、生成されなければならないと考えられる。しかし、これら２つのイベント間の時間は、ＳＴＡＴＵＳ ＰＤＵが送信されうる頻度を規定するステータス禁止時間よりも短い可能性がある。可能性のある解決策は、ステータス禁止時間を、非常に低い値に設定することか、又は、ステータス禁止時間機能を停止することかもしれない。しかし、これにより、上述したように、ＳＴＡＴＵＳ ＰＤＵを不必要に送信する結果となる可能性がある。
【００１６】
上述したように、基地局側又はユーザ装置において、ＲＬＣ ＡＭエンティティを２つの部分（送信機及び受信機）に分割する場合に、関連する問題が生じる。当該問題は、受信機がＳＴＡＴＵＳ ＰＤＵを生成する一方で、送信機がＳＴＡＴＵＳ ＰＤＵの送信時刻について知ることである。これは、物理層、ＭＡＣ層、ＲＬＣ層、及び他のプロトコル層を含み、ハードウェア全体を送信機と受信機とに分割することが通常である基地局において、特に厄介な問題となる可能性がある。このような実施において、スケジューラと送信ＭＡＣエンティティは、スケジューリングの決定前に、各ＲＬＣエンティティからの送信用に利用可能なデータ量に関する最新の情報を有している必要がある。このことには、ＳＴＡＴＵＳ ＰＤＵが送信に利用可能であるかどうかと、その場合においてそれがどのようなサイズを有しているかとを知ることが含まれる。リアルタイム要求要件は、多くの場合、このような情報が必要とされる際に、送信側がＲＬＣ受信機からのこのような情報をリクエストすることを不可能にする。このため、自然な解決策は、ＳＴＡＴＵＳメッセージを、それがトリガされた際に受信機において生成することであり、それにより、当該メッセージを、送信可能となるまで送信側においてバッファリングすることであるが、これは、ＳＴＡＴＵＳが送信前に即座に生成されなければならないので適切ではない。
【００１７】
無線通信ネットワーク環境におけるユーザのアクセス品質とシステム全体の容量とは、データの損失とプロトコルの行き詰まり（stalling）とによる影響だけでなく、不必要なポーリングとデータの再送とによる影響も受ける。
【発明の概要】
【００１８】
従って、上記の不利益の少なくとも一部を取り除いて、改善した無線通信システムを提供することを目的とする。
【００１９】
第１の態様によれば、本目的は、第１のノードと第２のノードとの間の無線リンクを介したデータユニットの送信を制御するための、当該第１のノードにおける方法によって達成される。第１のノード及び第２のノードは、無線通信システムに含まれる。本方法は、データユニットを第２のノードから受信するステップを含む。本方法はまた、第２のノードから受信されていることが期待されている任意のデータユニットが、未受信であるかどうかを検出するステップを含む。さらに、本方法は、未受信のデータユニットについて行われた検出に基づいて、状態報告を生成するステップを含む。さらにまた、本方法は、生成された状態報告をバッファにバッファリングするステップを含む。またさらに、本方法は、受信されたデータユニット又は未受信のデータユニットについての変化が検出されると、バッファリングされた状態報告を更新するステップを含む。さらに、本方法は、第２のノードから状態報告のリクエストを受信するステップを含む。また、本方法はさらに、受信された状態報告のリクエストに対する応答として、生成された状態報告を第２のノードに送信するステップを含む。
【００２０】
第２の態様によれば、本目的は、第１のノードと第２のノードとの間の無線リンクを介したデータユニットの送信を制御するための、当該第１のノードにおける装置によって達成される。第１のノード及び第２のノードは、無線通信システムに含まれる。本装置は、受信機を備える。受信機は、データユニットと状態報告のリクエストとをそれぞれ第２のノードから受信する。本装置はまた、検出部を備える。検出部は、第２のノードから受信されていることが期待されている任意のデータユニットが、未受信であるかどうかを検出する。本装置は、状態報告生成部をさらに備える。状態報告生成部は、未受信のデータユニットについて行われた検出に基づいて、状態報告を生成する。さらにまた、本装置は、バッファを備える。バッファは、生成された状態報告をバッファリングする。またさらに、本装置は、更新部を備える。更新部は、受信されたデータユニット又は未受信のデータユニットについての変化が検出されると、バッファリングされた状態報告を更新する。さらに、本装置は、送信機を備える。送信機は、受信された状態報告のリクエストに対する応答として、状態報告を第２のノードに送信する。
【００２１】
本方法及び本装置によって、ＳＴＡＴＵＳ ＰＤＵのサイズは、ＳＴＡＴＵＳ ＰＤＵが実際に利用可能となる前に推定されうる。また、いったん送信の機会が生じると、ＳＴＡＴＵＳ ＰＤＵの形式で、最新の可能な限りの状態情報が下位層に提供される。これは、受信バッファが変化するごとに新しいＳＴＡＴＵＳ ＰＤＵを生成してバッファリングすること、及び、ＳＴＡＴＵＳ ＰＤＵが１回だけ送信されることを確実にするためのトリガカウンタを管理することによって行われる。このため、ＳＴＡＴＵＳ ＰＤＵが最近、既に送信されている場合に、ＳＴＡＴＵＳ ＰＤＵが不必要に送信されることが回避される。これにより、無線通信システム内に含まれるノード間における不必要なシグナリングが低減され、その結果、オーバヘッド・シグナリングが低減され、それによりシステム容量が増大する。従って、無線通信システム内でデータユニットの送信を制御するための改善された本発明の仕組みの結果として、無線通信システムについて改善した性能が提供される。
【００２２】
本方法及び本装置の利点は、その実施において、ＲＬＣ送信機とＲＬＣ受信機とを、厳密なリアルタイム・コネクションを有する必要のない２つのエンティティに分離することを可能にすることである。
【００２３】
本方法及び本装置についての他の目的、利点、及び新規な特徴は、本方法及び本装置に関する以下の詳細な説明から明らかとなろう。
【図面の簡単な説明】
【００２４】
以下では、本発明の方法及び装置について、下記の添付の図面に関連してより詳細に説明する。
【００２５】
【図１】無線通信システムの実施形態を示す概略的なブロック図である。
【図２】いくつかの実施形態に係る、第１のノード内に位置付けられたエンティティの実施形態を示すブロック図である。
【図３】本方法の一実施形態を示すフローチャート及びブロック図の組み合わせである。
【図４】本方法の実施形態を示すフローチャートである。
【図５】第１のノード内の装置の実施形態を示すブロック図である。
【発明を実施するための形態】
【００２６】
本発明の方法及び装置は、後述する実施形態において実施されうる。しかし、これらの方法及び装置は、多くの異なる形態でも具体化されうるとともに、本明細書で説明する実施形態に限定されると解釈されるべきではない。むしろ、これらの実施形態は、その開示が、詳細かつ完全となり、本発明の方法及び装置の範囲を十分に伝えるように、提供される。本発明の方法及び装置の少なくとも何れかを、開示されている特定の形態の何れかに限定する意図はなく、逆に、本発明の方法及び装置は、特許請求の範囲によって規定される本発明の方法及び装置の範囲内に含まれる、あらゆる変形、均等物、及び代替手段を包含することが、理解されるべきである。
【００２７】
図１は、無線通信システム１００において第２のノード１３０と通信する第１のノード１１０を示している。第１のノード１１０と第２のノード１３０との間の通信は、例えば、無線通信システム１００に含まれるセル１２０における通信キャリヤを介して行われうる。
【００２８】
図１に示す構成要素の数は単に例示であることが理解されよう。より多くの構成要素、より少ない構成要素、又は異なる構成要素の配置を有する、他の構成も実施されうる。さらに、いくつかの実施形態において、図１における１つ以上の他の構成要素によって実行されることが説明される１つ以上のタスクを、図１における１つ以上の構成要素が実行してもよい。
【００２９】
無線通信システム１００は、いくつかの任意的な実施形態によれば、使用される技術に依存して、制御ノードをも含んでいてもよい。制御ノードは、例えば、無線ネットワーク制御装置（Radio Network Controller）であってもよい。
【００３０】
制御ノードは、無線通信システム１００における管理エレメントであり、当該制御ノードに接続されうる第２のノード１３０等の基地局の制御を担っていてもよい。制御ノードは、無線リソース管理とモビリティ管理機能の一部とを実行してもよい。
【００３１】
いくつかの実施形態においては、第１のノード１１０は、例えば、ユーザ装置（ＵＥ）、無線通信端末、セルラー携帯電話、パーソナル通信システム端末、パーソナル・ディジタル・アシスタント（ＰＤＡ）、ラップトップ、コンピュータ、又は、無線リソースを管理可能な他の任意の種類の装置によって代表されうる。パーソナル通信システム端末は、セルラ無線電話を、データ処理機能、ファクシミリ機能、及びデータ通信機能と組み合わせうる。ＰＤＡは、無線電話、ページャ、インターネット／イントラネット・アクセス装置、ウェブブラウザ、システム手帳、カレンダ等を含みうる。
【００３２】
しかし、第１のノード１１０は、いくつかの実施形態においては、使用される無線アクセス技術及び専門用語等に依存して、アクセスポイント、ノードＢ、進化型ノードＢ（ｅノードＢ）、及び無線基地局の少なくとも何れか、アクセスポイント基地局、基地局ルータ等といった、基地局によって代表されてもよい。
【００３３】
第２のノード１３０は、いくつかの実施形態においては、使用される無線アクセス技術及び専門用語等に依存して、アクセスポイント、ノードＢ、進化型ノードＢ（ｅノードＢ）、及び無線基地局の少なくとも何れか、アクセスポイント基地局、基地局ルータ等といった、基地局と称されてもよい。
【００３４】
さらに、いくつかの実施形態によれば、第２のノード１３０は、例えば、ユーザ装置（ＵＥ）、無線通信端末、セルラ携帯電話、パーソナル通信システム端末、パーソナル・ディジタル・アシスタント（ＰＤＡ）、ラップトップ、コンピュータ、又は、無線リソースを管理可能な他の任意の種類の装置によって代表されうる。
【００３５】
しかし、図１に示す非限定的な例においては、第１のノード１１０はセルラ携帯電話であり、第２のノード１３０は基地局である。
【００３６】
無線通信システム１００は、（ＬＴＥとしても知られている）Ｅ−ＵＴＲＡＮ、符号分割多元接続（ＣＤＭＡ）、広帯域符号分割多元接続（ＷＣＤＭＡ）、ＣＤＭＡ２０００、高速下りリンク・パケット・データ・アクセス（ＨＳＤＰＡ）、高速上りリンク・パケット・データ・アクセス（ＨＳＵＰＡ）、ハイ・データ・レート（ＨＤＲ）、ＴＤ−ＳＣＤＭＡ等の技術に基づきうる。
【００３７】
非限定的な例示のみとして、かつ、単に例示を目的として、この明細書は、Ｅ−ＵＴＲＡＮ環境において具体化された本発明の方法及び装置を用いて記述されている。しかし、本発明の方法及び装置は、他の技術を用いた環境においても使用されうる。
【００３８】
図２は、ＲＬＣエンティティ２００の実施形態を示すブロック図である。いくつかの実施形態によれば、ＲＬＣエンティティ２００は、無線通信システム１００内の第１のノード１１０及び第２のノード１３０の少なくとも何れかに位置付けられうる。
【００３９】
いくつかの実施形態によれば、ＲＬＣエンティティ２００は、ＲＬＣ受信機２１０とＲＬＣ送信機２３０とに分割される。しかし、他の実施形態によれば、ＲＬＣ受信機２１０とＲＬＣ送信機２３０とは、ロジックを変更することなく一緒にされうる。
【００４０】
ＲＬＣ受信機２１０は、受信バッファ２２０を備えていてもよい。受信バッファ２２０は、受信データをバッファリングしうる。
【００４１】
ＲＬＣ送信機２３０は、ＳＴＡＴＵＳ ＰＤＵをバッファリングするＳＴＡＴＵＳバッファ２４０を備えていてもよい。さらに、ＲＬＣ送信機２３０は、ユーザデータバッファ２５０を備えていてもよい。しかし、いくつかの実施形態によれば、ＳＴＡＴＵＳバッファは、下位層に存在しうる。さらに、いくつかの実施形態によれば、ユーザデータバッファ２５０は、代替的に、ＲＬＣ ＳＤＵバッファとＲＬＣ ＰＤＵバッファとに分割されうる。
【００４２】
図３は、方法のステップ、及び無線通信システム１００内の第１のノード１１０と第２のノード１３０の間の信号の伝送を示す、シグナリング及びフローチャートの組み合わせである。
【００４３】
本発明の方法及び装置の全体的なコンセプトは、ＳＴＡＴＵＳ ＰＤＵのサイズを、それが実際に利用可能になる前に推定し、その後いったん送信の機会が生じると、ＳＴＡＴＵＳ ＰＤＵの形式で、最新の可能な限りの状態情報を下位層に提供するという問題を解決するための、現実的な実現の手段を提供することである。これは、受信バッファ２００が変化するごとに新しいＳＴＡＴＵＳ ＰＤＵを生成してＳＴＡＴＵＳバッファ２４０内にバッファリングするとともに、ＳＴＡＴＵＳ ＰＤＵが１回のみ送信されることを確実にするためのトリガカウンタを管理することによって、行われうる。これにより、１回のトリガによって、最大で１回のステータス送信を生じさせることができる。
【００４４】
３１０
この例示的な実施形態においては、ＲＬＣ受信機２１０とＲＬＣ送信機２３０とは、第１のノード１１０内に位置付けられる。
【００４５】
ＲＬＣ受信機２１０は、状態が変化するとすぐに新しいＳＴＡＴＵＳ ＰＤＵを生成する。ＲＬＣ受信機２１０は、状態トリガによってのみならず、送信時間間隔（ＴＴＩ：Transmission Time Interval）ごとに、新しいＳＴＡＴＵＳ ＰＤＵを生成してもよい。
【００４６】
生成されたＳＴＡＴＵＳ ＰＤＵは、その後、ＲＬＣ受信機２１０からＲＬＣ送信機２３０へ転送されうる。
【００４７】
ＲＬＣ送信機２３０は、当該転送された新しいＳＴＡＴＵＳ ＰＤＵを、想定される送信のために受信して、それをＳＴＡＴＵＳバッファ２４０にバッファリングする。ＳＴＡＴＵＳバッファ２４０に含まれている可能性がある、それ以前のＳＴＡＴＵＳ ＰＤＵは、新しいＳＴＡＴＵＳ ＰＤＵによって上書きされてもよい。
【００４８】
さらに、ＲＬＣ送信機２３０はステータス禁止タイマを管理し、当該ステータス禁止タイマは、ＳＴＡＴＵＳ ＰＤＵがあまりに頻繁に送信されないように、送信されるＳＴＡＴＵＳ ＰＤＵとＳＴＡＴＵＳ ＰＤＵとの間の期間の計時のために適合しうる。
【００４９】
さらにまた、ＲＬＣ受信機２１０は、各ＳＴＡＴＵＳ ＰＤＵに「トリガカウンタ」を付加してもよい。トリガカウンタは、ＳＴＡＴＵＳ ＰＤＵが実際にトリガされるごとにインクリメントされる。ＳＴＡＴＵＳ ＰＤＵは、第２のノード１３０から受信されたポーリング、又は損失したデータユニットに起因して、トリガされうる。
【００５０】
ＲＬＣ送信機２３０は、最後に送信されたＳＴＡＴＵＳ ＰＤＵの「トリガカウンタ」のトラッキングをし続けるが、同一のカウンタ値を有する新しい状態メッセージを送信することはない。いくつかの実施形態によれば、トリガカウンタは、同一ノード内のＲＬＣ受信機２１０とＲＬＣ送信機２３０との間でやりとりされるのみであってもよい。
【００５１】
送信された最新のトリガカウンタとは異なるトリガカウンタを有する、バッファリングされたＳＴＡＴＵＳ ＰＤＵが存在せず、かつ、ステータス禁止タイマが動作していない場合にはいつでも、ＲＬＣ送信機２３０は、バッファリングされているＳＴＡＴＵＳ ＰＤＵを送信用に利用可能であるとみなしうる。このため、ＳＴＡＴＵＳ ＰＤＵのサイズは、利用可能なデータをＭＡＣに報告する際に含まれうる。機会があり次第、ＳＴＡＴＵＳ ＰＤＵは送信され、送信された最新のトリガカウンタが更新されうる。
【００５２】
従って、「トリガカウンタ」は、実際にトリガされてない際にＳＴＡＴＵＳ ＰＤＵの送信を妨げる、という目的を果たしうる。これは、ＳＴＡＴＵＳ ＰＤＵを生成するためのトリガが受信されているか否かにかかわらず、ＲＬＣ受信機２１０がＳＴＡＴＵＳ ＰＤＵを生成するためである。
【００５３】
３２０
ポーリングが、第２のノード１３０から第１のノード１１０へ送信される。
【００５４】
３３０
生成されたＳＴＡＴＵＳ ＰＤＵは、当該ポーリングに対する応答として、第１のノード１１０から第２のノードに送信される。
【００５５】
３４０
第２のノード１３０は、生成されたＳＴＡＴＵＳ ＰＤＵを受信するとともに、例えば、損失したデータユニットの再送を実行するために、状態報告を使用しうる。
【００５６】
上述の手順の利点は、プロトコルを実際の製品に実装する際にＲＬＣの仕様が満足されうることである。このため、分離された送信機２３０及び受信機２１０を含む実装を、厳密なリアルタイム・コネクションを有する必要のない２つのエンティティに対して実現することも可能である。
【００５７】
本発明の方法及び装置について、進化型ＵＴＲＡＮ（Ｅ−ＵＴＲＡＮ）環境における実装用に説明してきたものの、同様の原理は、例えば、可変のＲＬＣ ＰＤＵが導入される場合のＵＴＲＡＮに対しても適用可能でありうる。
【００５８】
図４は、第１のノード１１０において実行される方法のステップ４０１〜４１２を含む実施形態を示すフローチャートである。本方法は、第１のノード１１０と第２のノード１３０との間の無線リンクを介したデータユニットの送信を制御することを目的としている。第１のノード１１０及び第２のノード１３０は、無線通信システム１００に含まれている。
【００５９】
これまでに議論したように、第１のノード１１０は、携帯電話等のユーザ端末であってもよく、第２のノード１３０は、進化型ノードＢ（ｅノードＢ）等の基地局であってもよい。しかし、いくつかの実施形態によれば、第１のノード１１０が基地局であってもよく、第２のノード１３０がユーザ端末であってもよい。
【００６０】
第２のノードからのデータユニットの送信を適切に制御するために、本方法は、多数の方法ステップ４０１〜４１２を含みうる。しかし、説明する方法ステップのうちの一部は、任意的であり、一部の実施形態にのみ含まれうることに留意されたい。さらに、方法ステップ４０１〜４１２が、あらゆる任意の時間的順序で実行されうること、及び、それらのうちのいくつか（例えばステップ４０９とステップ４１１）又は全てのステップが、同時に、変更された時間的順序で、任意に並べ直された時間的順序で、分解された時間的順序で、又は完全に逆の時間的順序でも実行されうることに留意されたい。
【００６１】
ステップ４０１
データユニットが、第２のノード１３０から受信される。いくつかの実施形態によれば、データユニットは、例えばパッケージ・データユニット（ＰＤＵ：Package Data Unit）であってもよい。
【００６２】
ステップ４０２
第２のノード１３０から受信されていることが期待されている任意のデータユニットが、未受信であるかどうかを検出する。これにより、損失したデータの制御が実行される。
【００６３】
ステップ４０３
未受信のデータユニットについて行われた検出に基づいて、状態報告が生成される。
【００６４】
ステップ４０４
生成された状態報告が、バッファ５０３にバッファリングされる。
【００６５】
ステップ４０５
バッファリングされた状態報告が、受信されたデータユニット又は未受信のデータユニットについての変化が検出された際に更新される。
【００６６】
ステップ４０６
状態報告のリクエストが、第２のノード１３０から受信される。
【００６７】
ステップ４０７
このステップは任意的であり、本発明の方法についてのいくつかの実施形態にのみ含まれうる。いくつかの実施形態によれば、第１のノード１１０は、受信された状態報告のリクエストに対する応答として送信された状態報告の数を計数するトリガカウンタ５１２を備えていてもよい。
【００６８】
トリガカウンタ５１２のトリガカウンタ値は、受信されたリクエストに起因して状態報告が送信されるごとに、１だけインクリメントされうる。
【００６９】
ステップ４０８
このステップは任意的であり、本発明の方法についてのいくつかの実施形態にのみ含まれうる。
【００７０】
インクリメントされたトリガカウンタ値が、バッファリングされた状態報告に付加されうる。
【００７１】
ステップ４０９
このステップは任意的であり、本発明の方法についてのいくつかの実施形態にのみ含まれうる。
【００７２】
最新の状態報告が第２のノード１３０に送信されてから経過している時間が測定されうる。当該測定は、例えば、第１のノード１１０内に含まれるタイマによって、行われうる。いくつかの実施形態によれば、状態報告が送信された際に、当該タイマはゼロに初期化される。
【００７３】
ステップ４１０
このステップは任意的であり、本発明の方法についてのいくつかの実施形態にのみ含まれうる。
【００７４】
測定された時間が、特定の予め定められた閾値を超えたかどうかが検査されうる。
【００７５】
ステップ４１１
このステップは任意的であり、本発明の方法についてのいくつかの実施形態にのみ含まれうる。
【００７６】
状態報告のインクリメントされたトリガカウンタ値が、送信された最新の状態報告のトリガカウンタ値と異なるかどうかが検査されうる。
【００７７】
ステップ４１２
生成された状態報告が、受信された状態報告のリクエストに対する応答として第２のノード１３０に送信される。
【００７８】
いくつかの任意的な実施形態によれば、最後の状態報告が送信されてから、特定の予め定められた時間が経過しているように、生成された状態報告は、特定の条件が満足された場合にのみ第２のノード１３０に送信される。
【００７９】
さらに、いくつかの実施形態によれば、第２のノード１３０への状態報告は、測定された時間が、特定の予め定められた閾値を超えた場合、及び、状態報告のインクリメントされたトリガカウンタ値が、送信された最新の状態報告のトリガカウンタ値と異なる場合にのみ送信される。
【００８０】
図５は、第１のノード１１０に位置付けられる装置５００の実施形態を示すブロック図である。装置５００は、第１のノード１１０と第２のノード１３０との間の無線リンクを介したデータユニットの送信を制御するための方法ステップ４０１〜４１２を実行する。上記したように、第１のノード１１０及び第２のノード１３０の両方は、無線通信システム１００内に含まれる。
【００８１】
状態報告は、第２のノード１３０から送信され、第１のノード１１０によって受信されるデータユニットについての肯定確認応答及び否定確認応答の少なくとも何れかを含む。本装置５００が含まれる第１のノード１１０は、いくつかの実施形態によれば、携帯電話等のユーザ装置によって代表されうる。しかし、いくつかの実施形態によれば、第１のノード１１０は、進化型ノードＢ（ｅノードＢ）等の基地局によって代表されてもよい。
【００８２】
装置５００に含まれる内部の電子機器であって、本発明の方法の実行に完全には必要であるわけではない電子機器については、明確化のために図５から省略されている。
【００８３】
装置５００は、受信機５０５を備える。受信機５０５は、データユニットと状態報告のリクエストとをそれぞれ第２のノード１３０から受信する。装置５００はまた、検出部５０１を備える。検出部５０１は、第２のノード１３０から受信されるていることが期待されている任意のデータユニットが、未受信であるかどうかを検出する。さらに、装置５００は、状態報告生成部５０２を備える。状態報告生成部５０２は、未受信のデータユニットについて行われた検出に基づいて、状態報告を生成する。また、装置５００は、バッファ５０３をさらに備える。バッファ５０３は、生成された状態報告をバッファリングする。またさらに、装置５００は、更新部５０４を備える。更新部５０４は、受信されたデータユニット又は未受信のデータユニットについての変化が検出された際に、バッファリングされている状態報告を更新する。さらにまた、装置５００は、送信機５１１を備える。送信機５１１は、受信された状態報告のリクエストに対する応答として、第２のノード１３０に状態報告を送信する。
【００８４】
いくつかの実施形態によれば、装置５００は、インクリメント部５０６を備えていてもよい。インクリメント部５０６は、受信されたリクエストに起因して状態報告が送信されるごとに、トリガカウンタ値を１だけインクリメントしうる。
【００８５】
いくつかの実施形態によれば、任意的に、装置５００は付加部５０７を備えていてもよい。付加部５０７は、インクリメントされたトリガカウンタ値を、バッファリングされている状態報告に付加しうる。
【００８６】
いくつかの実施形態によれば、装置５００は、タイマ５０８を備えていてもよい。タイマ５０８は、第２のノード１３０に最新の状態報告が送信されてから経過している時間を測定しうる。
【００８７】
任意的でありうる装置５００のいくつかの実施形態は、時間検査部５０９を備えていてもよい。任意の時間検査部５０９は、測定した時間が、特定の予め定められた閾値を超えたかどうかを検査しうる。このため、時間検査部５０９は、ウォッチドッグ・タイマ（watch dog timer）として機能しうる。
【００８８】
装置５００のいくつかの任意的な実施形態によれば、トリガ検査部５１０が備えられていてもよい。トリガ検査部５１０は、状態報告のインクリメントされたトリガカウンタ値が、送信された最新の状態報告のトリガカウンタ値と異なるかどうかを検査しうる。
【００８９】
いくつかの任意的な実施形態は、トリガカウンタ部５１２を備えていてもよい。トリガカウンタ部５１２は、状態報告の送信のために受信されたトリガの数を計数しうる。
【００９０】
装置５００のさらにいくつかの任意的な実施形態は、処理部５１３を備えていてもよい。処理部５１３は、中央処理装置（ＣＰＵ）、マイクロプロセッサ、周辺機器インタフェース・コントローラ（ＰＩＣ）マイクロコントローラ、又は、コンピュータプログラム命令及び処理データを解釈しうる他の任意の適切な装置であってもよい。
【００９１】
装置５００に備えられた、記載したユニット５０１〜５１３は、別々の論理的なエンティティとされているが、別々の物理的なエンティティである必要はないことに留意されたい。ユニット５０１〜５１３のうちの何れか、一部又は全ては、同一の物理ユニット内に備えられてもよいし、共通配置されてもよい。しかし、装置５００の機能の理解を容易にするために、備えられたユニット５０１〜５１３は、図５においては別々の物理ユニットとして示されている。
【００９２】
いくつかの特定の実施形態
第１のノード１１０と第２のノード１３０との間の無線リンクを介したデータユニットの送信を制御するための、第１のノード１１０における方法は、当該方法の機能を実行するためのコンピュータプログラム・コードとともに、第１のノード１１０の１つ以上のプロセッサ５１３を介して実施されうる。上記したプログラム・コードは、例えば、処理部５１３にロードされた際に本発明の方法及び装置に係る方法ステップを実行するためのコンピュータプログラム・コードを保持するデータ記憶媒体の形式で、コンピュータ・プログラムとしても提供されうる。当該データ記憶媒体は、ＣＤ−ＲＯＭディスク、メモリスティック、又は、機械可読データを保持可能なディスク若しくはテープ等の他の任意の適切な媒体であってもよい。コンピュータプログラム・コードは、サーバ上の単なるプログラム・コードとしてもさらに提供されうるとともに、第１のノード１１０に対して間接的にダウンロードされうる。
【００９３】
従って、方法ステップ４０１〜４１２のうち少なくとも一部による方法を実行するための命令セットを含むコンピュータプログラムが、これまでに説明した方法を実施するために使用されうる。
【００９４】
本方法及び装置５００は、例えば、第１のノード１１０内の装置５００、方法、又はプログラムとして具体化されうる。従って、本方法及び装置は、完全なハードウェアの実施形態、ソフトウェアの実施形態、又は、本明細書では全てが「回路」若しくは「モジュール」と一般に称される、ソフトウェア態様及びハードウェア態様を組み合わせた実施形態の形式をとりうる。さらに、本方法及び装置は、記録媒体において具体化される、コンピュータで使用可能なプログラムを含むコンピュータで使用可能な当該記憶媒体上の、コンピュータプログラム製品の形式をとりうる。ハードディスク、ＣＤ−ＲＯＭ、光学記憶装置、インターネット若しくはイントラネットをサポートする伝送媒体、又は磁気記憶装置を含む、あらゆる適切なコンピュータ可読媒体が、利用されうる。
【００９５】
本方法及び装置の動作を実行するためのコンピュータプログラム・コードは、Ｊａｖａ（登録商標）、Ｓｍａｌｌｔａｌｋ、又はＣ＋＋等の、任意のオブジェクト指向プログラミング言語で記述されうる。しかし、本方法のステップを実行するためのコンピュータプログラム・コードは、「Ｃ」プログラミング言語、及びより低レベルのアセンブラ言語の少なくとも何れか等の、任意の従来の手続きプログラミング言語でも記述されうる。プログラム・コードは、装置５００上で完全に、装置５００上で部分的に、スタンドアロン・ソフトウェアパッケージとして装置５００上で部分的に、及び、リモート・コンピューティング装置上で部分的又は完全に、実行されうる。後者のシナリオでは、リモート・コンピューティング装置は、ローカル・エリア・ネットワーク（ＬＡＮ）若しくはワイド・エリア・ネットワーク（ＷＡＮ）を介して装置５００に接続されうるか、又は、当該接続は、例えば、インターネット・サービス・プロバイダ（ＩＳＰ）等を使用してインターネットを介して、外部コンピュータに対して構成されうる。
【００９６】
さらに、本方法について、図４におけるフローチャートの図示及び図５における装置のブロック図の少なくとも何れかと、本方法及び装置の実施形態に係るコンピュータプログラムとを参照しながら、上記ではある程度説明している。フローチャートの図示及びブロック図の少なくとも何れかに含まれる各ブロックは、コンピュータプログラム命令によって実施されてもよいことが理解されよう。これらのコンピュータプログラム命令が、汎用コンピュータのプロセッサ、特殊用途コンピュータ、又は機械を形成する他のプログラマブル・データ処理装置に対して提供されうることによって、コンピュータ又は他のプログラマブル・データ処理装置のプロセッサを介して実行される命令が、フローチャートとブロック図の（１つ又は複数の）ブロックとの少なくとも何れかにおいて特定される機能／動作を実施する手段をもたらす。
【００９７】
これらのコンピュータプログラム命令が、コンピュータ又は他のプログラマブルデータ処理装置に、特定の態様で機能するように指示することが可能なコンピュータ可読メモリにも格納されうることによって、当該コンピュータ可読メモリに格納された命令が、図４又は図５のフローチャートとブロック図の（１つ又は複数の）ブロックとの少なくとも何れかにおいて特定される機能／動作を実施する命令手段を含む製品を生産する。
【００９８】
また、コンピュータプログラム命令は、コンピュータ又は他のプログラマブル・データ処理装置にロードされることで、当該コンピュータ上、又はコンピュータで実施される処理を生成する他のプログラマブル・データ処理装置上で、一連の動作ステップを実行させうることによって、当該コンピュータ又は他のプログラマブル装置上で実行される命令が、フローチャートとブロック図の（１つ又は複数の）ブロックとの少なくとも何れかにおいて特定される機能／動作を実施するためのステップを提供する。
【００９９】
添付の図面に図示されている特定の例示的な実施形態についての詳細な説明において使用されている用語は、本方法及び装置を限定することを意図したものではない。
【０１００】
本明細書で使用している単数形の「a」、「an」及び「the」は、特に明示的な記述のない限り、複数形も同様に含むことを意図している。「含む（includes）」、「備える（含む）（comprises）」、「含んでいる（including）」及び「備えている（含んでいる）（comprising）」の少なくとも何れかの用語は、本明細書で使用されている場合には、記述した特徴、整数、ステップ、動作、エレメント及び構成要素の少なくとも何れかの存在を特定する一方で、１つ以上の他の特徴、整数、ステップ、動作、エレメント、構成要素及びそれらのグループの少なくとも何れかの存在又は追加を除外することはないことが、さらに理解されよう。本明細書で使用している「接続されている（connected）」又は「接続されている（coupled）」は、無線接続を含んでもよい。本明細書で使用されている、「少なくとも何れか（and/or）」という用語は、関連してリストされている項目のうちの１つ以上の組み合わせの何れかと、組み合わせの全てとを含む。
【図１】
0005335928.tif 000002
【図２】
0005335928.tif 000003
【図３】
0005335928.tif 000004
【図４】
0005335928.tif 000005
【図５】
0005335928.tif 000006