(57)【要約】  通信機器（１１０）における受信状態報告の方法は、第１の状態報告タイプを第１の報告周期パラメータの値と関連付けると共に第２の状態報告タイプを第２の報告周期パラメータの値と関連付けることによる周期的受信状態報告のためにその通信機器を設定すること（Ｓ１）と、第１の報告周期パラメータの関連付けられた値に従う第１のタイプの受信状態報告と第２の報告周期パラメータのの関連付けられた値に従う第２のタイプの受信状態報告を周期的に送信すること（Ｓ２）と、を含み、第１の状態報告タイプは第２の状態報告タイプと異なり、第１の報告周期パラメータは第２の報告周期パラメータと異なる。【選択図】  図３
2019504576.tif 000002
【特許請求の範囲】
【請求項１】
通信機器（１１０）における受信状態報告の方法であって、
第１の状態報告タイプを第１の報告周期パラメータの値と関連付けると共に第２の状態報告タイプを第２の報告周期パラメータの値と関連付けることにより、周期的受信状態報告のために前記通信機器（１１０）を設定すること（Ｓ１）、
前記第１の報告周期パラメータの前記関連付けられた値に従う前記第１のタイプの受信状態報告と前記第２の報告周期パラメータの前記関連付けられた値に従う前記第２のタイプの受信状態報告とを、周期的に送信すること（Ｓ２）と、
を有し、
前記第１の状態報告タイプが前記第２の状態報告タイプと異なり、前記第１の報告周期パラメータが前記第２の報告周期パラメータと異なる方法。
【請求項２】
前記第１のタイプの受信状態報告の前記送信を制御するための第１のタイマと前記第２のタイプの受信状態報告の前記送信を制御するための第２のタイマとを使用すること（Ｔ１）を有する請求項１に記載の方法。
【請求項３】
前記第１のタイマ及び前記第２のタイマは、初期的に、所定のオフセットを用いて開始される、請求項２に記載の方法。
【請求項４】
−前記第１のタイマがトリガ条件を満たしたことを判定すること（Ｔ２）と、
−前記第１のタイプの受信状態報告を送信すること（Ｔ３）と、
−前記第１のタイマを再始動すること（Ｔ４）と、
を有する請求項１から３のいずれか１項に記載の方法。
【請求項５】
−前記第２のタイマがトリガ条件を満たしたことを判定すること（Ｔ５）と、
−前記第２のタイプの受信状態報告を送信すること（Ｔ６）と、
−前記第２のタイマを再始動すること（Ｔ７）と、
を有する請求項１から４のいずれか１項に記載の方法。
【請求項６】
−前記第１のタイプの受信状態報告の送信を要求するメッセージを受信すること（Ｕ１）と、
−前記第１のタイプの受信状態報告を送信すること（Ｕ２）と、
−前記第１のタイマを再始動すること（Ｕ３）と、
を有する請求項１から５のいずれか１項に記載の方法。
【請求項７】
前記第２のタイマを再始動すること（Ｕ４）も有する請求項６に記載の方法。
【請求項８】
−前記第２のタイプの受信状態報告の送信を要求するメッセージを受信すること（Ｖ１）と、
−前記第２のタイプの受信状態報告を送信すること（Ｖ２）と、
−前記第２のタイマを再始動すること（Ｖ３）と、
を有する請求項１から７のいずれか１項に記載の方法。
【請求項９】
前記第１のタイマを再始動すること（Ｖ４）も有する請求項８に記載の方法。
【請求項１０】
前記第１の状態報告タイプは第１の報告サイズと関連付けられ、前記第２の状態報告タイプは第２の報告サイズと関連付けられ、前記第１の報告サイズは前記第２の報告サイズより大きい、請求項１から９のいずれか１項に記載の方法。
【請求項１１】
前記第１の報告周期パラメータの前記関連付けられた値は、前記第２の報告周期パラメータの前記関連付けられた値より大きい、請求項１０に記載の方法。
【請求項１２】
第１の報告周期パラメータの前記関連付けられた値は、前記第２の報告周期パラメータの前記関連付けられた値の整数倍である、請求項１１に記載の方法。
【請求項１３】
前記第１のタイプの受信状態報告と前記第２のタイプの受信状態報告とのいずれかのみを互いに所定の時間期間内で送信することを有する、請求項１から１２のいずれか１項に記載の方法。
【請求項１４】
前記第１のタイプの受信状態報告と前記第２のタイプのの受信状態報告とのいずれかのみを同一の送信時間間隔内において送信することを有する請求項１３に記載の方法。
【請求項１５】
前記受信状態報告は、所定のプロトコルのステータスＰＤＵ又は制御ＰＤＵである請求項１から１４のいずれか１項に記載の方法。
【請求項１６】
前記コンバージェンスプロトコルがパケットデータ・コンバージェンスプロトコルである、請求項１５に記載の方法。
【請求項１７】
前記第１のタイプの受信状態報告は、欠落している最も低いシーケンス番号を有するＰＤＵである最初の欠落したＰＤＵと、前記最初の欠落したＰＤＵと最も高いシーケンス番号を有する受信したＰＤＵとの間でさらに欠落したＰＤＵを示すビットマップと、の表示を含む、請求項１５又は１６に記載の方法。
【請求項１８】
前記第２のタイプの受信状態報告は、欠落している最も低いシーケンス番号を有するＰＤＵである最初の欠落したＰＤＵの表示を含む、請求項１５から１７のいずれか１項に記載の方法。
【請求項１９】
前記通信機器（１００）は、さらに、第１の無線アクセス技術（ＬＴＥ−Ｕｕ）と第２の無線アクセス技術（ＷＬＡＮ）との間のアグリゲーションのために設定される、請求項１から１８のいずれか１項に記載の方法。
【請求項２０】
前記第１の無線アクセス技術（ＬＴＥ−Ｕｕ）はセルラ無線通信技術であり、前記第２の無線アクセス技術は、無線ローカルエリアネットワーク通信技術（ＷＬＡＮ）である、請求項１９に記載の方法。
【請求項２１】
前記アグリゲーションはＬＴＥ−ＷＬＡＮアグリゲーションである、請求項１９又は２０に記載の方法。
【請求項２２】
前記通信機器（１１０）は、無線通信ネットワークの移動端末である、請求項１から２１のいずれか１項に記載の方法。
【請求項２３】
周期的受信状態報告のために通信機器（１１０）を設定する方法であって、
第１の状態報告タイプを第１の報告周期パラメータの値と関連付けると共に第２の状態報告タイプを第２の報告周期パラメータの値と関連付けるための情報を含んだ設定情報要素を、前記通信機器（１１０）へ提供すること（Ｗ１）を有し、前記第１の状態報告タイプは前記第２の状態報告タイプと異なり、前記第１の報告周期パラメータは前記第２の報告周期パラメータと異なる、方法。
【請求項２４】
前記通信機器（１１０）は、無線通信ネットワークの移動端末である、請求項２３に記載の方法。
【請求項２５】
前記設定情報要素は無線通信ネットワークのアクセスノードによって提供される、請求項２３又は２４に記載の方法。
【請求項２６】
前記アクセスノードは基地局である、請求項２５に記載の方法。
【請求項２７】
前記設定情報要素は、無線リソース制御設定メッセージである、請求項２３から２６のいずれか１項に記載の方法。
【請求項２８】
前記第１の状態報告タイプは第１の報告サイズと関連付けられ、前記第２の状態報告タイプは第２の報告サイズと関連付けられ、前記第１の報告サイズは前記第２の報告サイズより大きく、前記第１の報告周期パラメータの前記関連付けられた値は前記第２の報告周期パラメータの前記関連付けられた値より大きい、請求項２３から２７のいずれか１項に記載の方法。
【請求項２９】
通信ネットワークのノードを動作させる方法であって、
前記通信ネットワークの通信機器（１１０）に対して、第１の状態報告タイプを第１の報告周期パラメータの値と関連付けると共に第２の状態報告タイプを第２の報告周期パラメータの値と関連付けるための設定情報要素を提供すること（Ｘ１）を有し、前記第１の状態報告タイプは前記第２の状態報告タイプと異なり、前記第１の報告周期パラメータは前記第２の報告周期パラメータと異なる、方法。
【請求項３０】
前記通信機器（１１０）へデータユニットを送信すること（Ｘ２）と、前記第１のタイプの受信状態報告と前記第２のタイプの受信状態報告とを受信すること（Ｘ３）と、をさらに有する請求項２９に記載の方法
【請求項３１】
請求項１から２２のいずれか１項に記載の方法を行うために通信機器（１１０）のプロセッサによって実行されるプログラムコードを含んだコンピュータプログラム。
【請求項３２】
請求項２２から３０のいずれか１項に記載の方法を行うために通信ネットワークノードのプロセッサによって実行されるプログラムコードを含んだコンピュータプログラム。
【請求項３３】
データユニットを受信し、第１の状態報告タイプを第１の報告周期パラメータの値と関連付けると共に第２の状態報告タイプを第２の報告周期パラメータに関連付けることによる周期的受信状態報告のために設定可能である通信機器（１１０）であって、前記第１の状態報告タイプは前記第２の状態報告タイプと異なり、前記第１の報告周期パラメータは前記第２の報告周期パラメータと異なる、通信機器（１１０）。
【請求項３４】
前記第１の報告周期パラメータの前記関連付けられた値に従う前記第１のタイプの受信状態報告と前記第２の報告周期パラメータの前記関連付けられた値に従う前記第２のタイプの受信状態報告とを周期的に送信するようにさらに構成される、請求項３３に記載の通信機器（１１０）。
【請求項３５】
インタフェース（１１１）及びプロセッサ（１１３）を有し、前記インタフェース（１１１）は、データユニットを受信して受信状態報告を送信するように構成され、前記プロセッサ（１１３）は、受信状態報告の前記送信を制御する、請求項３３又は３４に記載の通信機器（１１０）。
【請求項３６】
通信ネットワークのノードであって、前記ノードは、前記通信ネットワークの通信機器（１１０）に対して、第１の状態報告タイプを第１の報告周期パラメータの値と関連付けると共に第２の状態報告タイプを第２の報告周期パラメータの値と関連付けるための情報を含んだ設定情報要素を提供するように構成され、前記第１の状態報告タイプは前記第２の状態報告タイプと異なり、前記第１の報告周期パラメータは前記第２の報告周期パラメータと異なる、ノード。
【請求項３７】
前記通信機器（１１０）へデータユニットを送信し、前記第１のタイプの受信状態報告と前記第２のタイプの受信状態報告とを受信するようにさらに構成される、請求項３６に記載のノード。
【請求項３８】
インタフェース（１０１）及びプロセッサ（１０３）を有し、前記インタフェースはデータユニットを送信して受信状態報告を受信するように構成され、前記プロセッサ（１０３）は、データユニットの前記送信と受信状態報告に含まれる情報の処理とを制御するように構成される、請求項３６又は３７に記載のノード。
【発明の詳細な説明】
【技術分野】
【０００１】
本願は、データユニットが送信機器から受信機器へ送信されると共に、受信機器が受信状態報告を周期的に送信機器へ送信するシステムの分野に関する。
【背景技術】
【０００２】
データユニット送信者へ受信状態報告を周期的に送信するようにデータユニット送信者を構成するようにする可能性を提供することが知られている。例えば、所謂ＬＴＥ−ＷＬＡＮアグリゲーションの文脈において、制御ＰＤＵとも呼ばれうるＰＤＣＰ（パケットデータコンバージェンスプロトコル）状態ＰＤＵを周期的に送信するようにユーザ端末（ＵＥ）を構成することができることが提案されている。
【発明の概要】
【０００３】
本発明の目的は、受信状態報告を送信するための改善されたコンセプトを提供することである。
【０００４】
実施形態によれば、第１の状態報告タイプを第１の報告周期パラメータの値と関連付けると共に第２の状態報告タイプを第２の報告周期パラメータの値と関連付けることにより周期的受信状態報告のための通信機器を設定することを含んだ、前記通信機器における受信状態報告の方法が提案され、前記第１の状態報告タイプは前記第２の状態報告タイプと異なり、前記第１の報告周期パラメータは前記第２の報告周期パラメータと異なる。
【０００５】
本方法は、さらに、前記第１の報告周期パラメータの前記関連付けられた値に従う前記第１のタイプの受信状態報告、及び、前記第２の報告周期パラメータの前記関連付けられた値に従う前記第２のタイプの受信状態報告の周期的な送信を含みうる。
【０００６】
別の実施形態によれば、第１の状態報告タイプを第１の報告周期パラメータの値と関連付けると共に第２の状態報告タイプを第２の報告周期パラメータの値と関連付けるための設定情報を通信機器へ提供することを含んだ、周期的受信状態報告のために前記通信機器を設定する方法が提案され、前記第１の状態報告タイプは前記第２の状態報告タイプと異なり、前記第１の報告周期パラメータは前記第２の報告周期パラメータと異なる。
【０００７】
さらなる実施形態によれば、第１の状態報告タイプを第１の報告周期パラメータの値と関連付けると共に第２の状態報告タイプを第２の報告周期パラメータと関連付けるための設定情報を前記通信ネットワークの通信機器へ提供することを含んだ、通信ネットワークのノードを動作させる方法が提案され、前記第１の状態報告タイプは前記第２の状態報告タイプと異なり、前記第１の報告周期パラメータは前記第２の報告周期パラメータと異なる。
【０００８】
さらなる実施形態によれば、データユニットを受信し、第１の状態報告タイプを第１の報告周期パラメータの値と関連付けると共に第２の状態報告タイプを第２の報告周期パラメータの値と関連付けることにより周期的受信状態報告を行うために設定可能に構成される通信機器が提案され、前記第１の状態報告タイプは前記第２の状態報告タイプと異なり、前記第１の報告周期パラメータは前記第２の報告周期パラメータと異なる。
【０００９】
さらなる実施形態によれば、通信ネットワークのノードが提案され、前記ノードは、第１の状態報告タイプを第１の報告周期パラメータの値と関連付けると共に第２の状態報告タイプを第２の報告周期パラメータの値と関連付けるための情報を含んだ設定情報要素を前記通信ネットワークの通信機器へ提供するように構成され、前記第１の状態報告タイプは前記第２の状態報告タイプと異なり、前記第１の報告周期パラメータは前記第２の報告周期パラメータと異なる。
【図面の簡単な説明】
【００１０】
【図１】図１は、本開示の概念を具現化する２つの通信機器の概略的表現を示す図である。
【図２】図２は、ＬＴＥ−ＷＬＡＮアグリゲーションのプロトコルアーキテクチャの例を示す図である。
【図３】図３は、本開示による方法ステップの第１の実施形態を示す図である。
【図４】図４は、本開示による方法ステップの第２の実施形態を示す図である。
【図５】図５は、本開示による方法ステップの第３の実施形態を示す図である。
【図６】図６は、本開示による方法ステップの第４の実施形態を示す図である。
【図７】図７は、本開示による方法ステップの第５の実施形態を示す図である。
【図８】図８は、本開示による方法ステップの第６の実施形態を示す図である。
【発明を実施するための形態】
【００１１】
図１は、所定の通信プロトコル、例えばＰＤＣＰに関連付けられたデータユニット１２０、例えば、プロトコルデータユニット（ＰＤＵ）を、データユニット１２０を受信するように構成されたさらなる通信機器１１０へ送信するように構成された、通信機器１００を含んだシステムを示している。
【００１２】
通信機器１００は、通信ネットワークのネットワークノードに含まれてもよいし、このようなノード、例えば基地局のような無線通信システムのアクセスノードであってもよい。実施形態によれば、機器１００は、ｅＮｏｄｅＢに含まれる。機器１００は、例えば無線送信及び受信に適合されたインタフェース１０１と、代わりにプロセッサ１０３及びメモリ１０４を含みうる制御パート１０２とを有する。
【００１３】
通信機器１１０は、同じ通信ネットワークの一部であり、例えば、無線通信システムの移動端末でありうる。実施形態によれば、機器１１０は、無線通信システム、例えばＬＴＥの、ユーザ端末（ＵＥ）である。機器１１０は、例えば無線送信及び受信に適合されたインタフェース１１１と、代わりにプロセッサ１１３及びメモリ１１４を含みうる制御パート１１２とを有する。
【００１４】
実施形態によれば、通信機器１１０は、データユニット１２０を受信し、周期的な受信状態報告を行う、すなわち、データユニット１２０の受信状態の情報を提供する受信状態報告１３０を送信するように設定可能に構成される。例えば、シーケンス番号（ＳＮ）が個別のデータユニットを区別するために使用されてもよく、受信状態報告がこのようなＳＮを用いて受信状態の情報を提供してもよい。受信状態情報は、任意の適切な又は望ましい方法で選択され、「受信（received）」又は「欠落（missing）」などの状態を例えば区別しうる。
【００１５】
少なくとも受信状態報告の第１のタイプと第２のタイプの受信状態報告が提供される。以下では、２つのタイプの状態報告のみを参照するが、本発明は２つに限定されるものではなく、２つより多くのタイプの状態報告の場合にも適用可能である。本実施形態によれば、機器１１０は、第１の状態報告タイプを第１の報告周期パラメータのある値に関連付けると共に第２の状態報告タイプを第２の報告周期パラメータのある値に関連付けることにより、周期的な受信状態報告を行うように設定可能である。第１の状態報告タイプは第２の状態報告タイプと異なり、第１の報告周期パラメータは第２の報告周期パラメータと異なる。
【００１６】
機器１１０の設定は、任意の適切な又は望ましい方法で、例えば、第１の状態報告タイプを第１の報告周期パラメータのある値に関連付けると共に第２の状態報告タイプを第２の報告周期パラメータのある値に関連付けるための情報を含んだ設定情報要素を、通信機器１１０に提供することによって、なされてもよく、ここで、第１の状態報告タイプは第２の状態報告タイプと異なり、第１の報告周期パラメータは第２の報告周期パラメータと異なる。このような設定情報要素は、例えば、データユニット１２０の送信の開始に先立つある時刻において、機器１００から機器１１０へ提供されうる。しかしながら、これは、機器１００及び機器１１０の通信ネットワークの内部又は外部の他の何らかのソースによって提供されてもよい。
【００１７】
好ましくは、設定されたことに応じて、かつ、データユニット１２０を受信したときに、機器１１０は、第１の報告周期パラメータの関連付けられた値に従う第１のタイプ及び第２の報告周期パラメータの関連付けられた値に従う第２のタイプの受信状態報告の受信状態報告を周期的に送信する。
【００１８】
報告周期パラメータは、任意の適切な又は好ましい方法で選択されうる。例えば、それは、例えばミリ秒で示される時間周期を表すように選択されてもよく、この時間周期は対応する受信状態報告の連続した送信の間の時間間隔を示す。その一方で、報告周期は、例えば１／ｓで示される頻度を表すように同様に良好に選択されてもよく、この頻度は対応する受信状態報告の繰り返しの頻度を示す
本実施形態によれば、１つのタイプのみの受信状態報告を選択することを許容して所与の周期でその選択された１つのタイプを送信することに代えて、説明するコンセプトは、それぞれがそれ自身の個別の周期を有する２つの異なるタイプの受信状態報告を並行して送信することを許容する。これは、柔軟性の顕著な増加を与え、動作のさらなる自由度を持ち込む。
【００１９】
例えば、第１の状態報告タイプは、第１の報告サイズに関連付けられてもよく、第２の状態報告タイプは、第２の報告サイズに関連付けられてもよく、ここで、第１の報告サイズは第２の報告サイズより大きい。換言すれば、第１の報告タイプは第２の報告タイプより多くの状態情報を含みうる。本実施形態によれば、第１の報告周期パラメータの関連付けられた値を第２の報告周期パラメータの関連付けられた値より大きく、すなわち、報告ごとに多量の状態情報を設定することが可能となり、これは時々データユニット１２０の送信制御のために重要であるが顕著に送信リソースを消費し、報告ごとのより少量の状態情報よりは低頻度で送信され、これは頻繁にデータユニット１２０の適切な送信制御に十分に足りうるものであり、それにより、報告効率とリソース消費との間の良好なバランスを達成する。
【００２０】
例として、第１のタイプの受信状態報告は、欠落している最も低いシーケンス番号のＰＤＵである最初の欠落したＰＤＵの表示と、最初の欠落したＰＤＵと最も高い番号を有する受信したＰＤＵとの間のさらなる欠落したＰＤＵを表示するビットマップとを含みうる。第２のタイプの受信状態報告は、最初の欠落したＰＤＵを含みうるが、ビットマップを含まない。
【００２１】
なお、第１の報告周期パラメータは上記第２の報告周期パラメータと異なる（すなわち、独立している）が、２つの周期に対して設定される値は同一であってもよい。その一方で、その値が異なるように設定される場合に、１つの有利な実施形態は、シグナリングを減らすことを可能とするように、第２の報告周期パラメータの値の整数倍として第１の報告周期パラメータの値を選択することを含む。
【００２２】
受信状態報告の周期的送信を制御する動作は、任意の適切な又は望ましい方法で実行されうる。例えば、第１のタイプの受信状態報告の送信を制御する第１のタイマと第２のタイプの受信状態報告の送信を制御するための第２のタイマとを使用することを含んでもよい。２つのタイマは、設定後に同時に開始されてもよいが、望ましい実施形態によれば、第１のタイマ及び第２のタイマは、初期的に、所定のオフセットを伴って開始される。このオフセットは、好ましくは、第１のタイプの受信状態報告の送信のトリガリングが第２のタイプの受信状態報告のトリガリングと一致しないように、選択される。このオフセットは、事前設定されてもよく、同様に、例えば機器１００によって送信される設定情報要素を用いて実行される、機器１１０の設定動作の不可欠な要素でありうる。例として、第１の報告周期のために設定される値が２００ｍｓであり第２の報告周期のために設定される値が５０ｍｓである場合、オフセットは、例えば、２５ｍｓに設定されうる。
【００２３】
制御動作は、
−（例えばタイマが満了した際に）上記第１のタイマがトリガ条件に達したと判定することと、
−上記第１のタイプの受信状態報告を送信することと、
−上記第１のタイマを再開することと、
を含むようにされうる。
【００２４】
制御動作は、さらに、
−（例えばタイマが満了した際に）上記第２のタイマがトリガ条件に達したと判定することと、
−上記第２のタイプの受信状態報告を送信することと、
−上記第２のタイマを再始動することと、
を含むようにされうる。
【００２５】
他の実施形態によれば、機器１１０は、受信状態報告の送信を要求するメッセージ、例えば、ポーリング要求、を受信するように構成されうる。受信状態報告の送信を要求するこのようなメッセージは、例えば、機器１００によって送信されうる。
【００２６】
その時、制御動作は、さらに、
−上記第１のタイプの受信状態報告の送信を要求するメッセージを受信することと、
−上記第１のタイプの受信状態報告を送信することと、
−上記第１のタイマを再始動することと、
を含むようにされうる。制御動作は、第１のタイマのみを再始動するようにされうるが、第１及び第２のタイマの両方を再始動することも可能である。両方のタイマを再始動すべき場合、一方が、他方に対して所定のオフセットを用いて再始動されるのが好ましい。このオフセットは、初期開始について上述したのと同じとなるように選択されてもよいし、異なるように選択されてもよい。好ましくは、オフセットが（例えば、機器１００から機器１１０へ送信される情報要素により）設定され、両方のタイマの初期開始のためと両方のタイマの再始動のためとで同じオフセットが使用される。
【００２７】
制御動作は、さらに、
−上記第２のタイプの受信状態報告の送信を要求するメッセージを受信することと、
−上記第２のタイプの受信状態報告を送信することと、
−上記第２のタイマを再始動することと、
を含むようにされうる。制御動作は、第２のタイマのみを再始動するようにされうるが、第１及び第２のタイマの両方を再始動することも可能である。両方のタイマを再始動すべき場合、一方が、他方に対して所定のオフセットを用いて再始動されるのが好ましい。このオフセットは、初期開始について上述したのと同じとなるように選択されてもよいし、異なるように選択されてもよい。好ましくは、オフセットが（例えば、機器１００から機器１１０へ送信される情報要素により）設定され、両方のタイマの初期開始のためと両方のタイマの再始動のためとで同じオフセットが使用される。
【００２８】
上述のように、ここで説明しているコンセプトは、それぞれが独立して設定可能な周期を有する２つの異なる種類の受信状態報告を並行して送信することを可能とする。より効率的に伝送リソースを使用するために、本動作は、第１及び第２のタイプの受信状態報告のうち１つのみを互いに所定の時間期間内で送信することを含むような方法で制御されうる。例えば、この時間期間は、方法が同じ送信時間間隔内で第１及び第２の受信状態報告のうち１つのみを送信することを含むように、送信時間間隔（ＴＴＩ）でありうる。しかしながら、時間期間は、より長く、例えば複数のＴＴＩに設定されてもよい。
【００２９】
また、ここで説明しているコンセプトは、機器１１０などの通信機器のプロセッサ（例えばプロセッサ１１３）によって、上述の方法の実施形態のいずれかによる方法を行うために実行されるべきプログラムコードを含んだ、コンピュータプログラムプロダクトとして具現化されてもよい。
【００３０】
また、ここで説明しているコンセプトは、機器１００などの通信ネットワークノードのプロセッサ（例えばプロセッサ１０３）によって、上述の方法の実施形態のいずれかによる方法を行うために実行されるべきプログラムコードを含んだ、コンピュータプログラムプロダクトとして具現化されてもよい。
【００３１】
以下では、上述のコンセプトのさらなる例について、より詳細な文脈において説明する。これは、本コンセプトをより良く説明するために役立つだけのものであり、限定することを意図したものではない。
【００３２】
ここでの例については、ＬＴＥ及びＷＬＡＮの集約の文脈の中で説明する。しかしながら、ここで説明される課題と解決策は、他のアクセス技術及び標準を実装する無線アクセスネットワーク及びユーザ端末（ＵＥ）にも等しく適用可能であることが理解されるべきである。ＬＴＥ及びＷＬＡＮは、本発明が適している例示の技術として用いられており、したがって、説明においてＬＴＥ及びＷＬＡＮを使用することは、課題とその課題を解決する解決策とを理解するのに特に有用である。
【００３３】
ＬＴＥ−ＷＬＡＮアグリゲーション（ＬＷＡ）は、ＵＥがｅＮＢとＷＬＡＮとの両方へのリンクを用いて受信及び送信を行いうる機能である。この機能については、３ＧＰＰにより、ＲＰ−１５１１１４において修正されたＲＰ−１５０５１０の一部として、リリース１３で記述されている。ＬＴＥ−ＷＬＡＮアグリゲーションのための様々なアーキテクチャオプションが存在する。オプション３Ｃとも表示されるスプリットベアラアーキテクチャのオプションでは、データはＰＤＣＰレイヤで分割される。下りリンク方向のために、この分割がｅＮＢにおいてなされる。ｅＮＢは、どのようにＰＤＣＰ  ＰＤＵをＵＥへルーティングするかを−ＬＴＥ  ＲＬＣ、ＬＴＥ  ＭＡＣ及びＬＴＥ  ＰＨＹを使用して直接ＵＥへ、又は、バックホールチャネルを介してＷＬＡＮへ、そして、８０２．１１  ＭＡＣ及び８０２．１１  ＰＨＹを用いてＵＥへ、のいずれかに−動的に決定しうる。
【００３４】
図２は、ＬＴＥ−ＷＬＡＮアグリゲーションのための予想されるプロトコルアーキテクチャを示している。ネットワーク内のＷＬＡＮターミネーション（ＷＴ）ポイントは、ＷＬＡＮアクセスポイント（ＡＰ）および／またはアクセスコントローラ（ＡＣ）若しくはさらなるネットワークノードによって実装されうる。ｅＮＢとＷＴとの間のインタフェースプロトコルは、Ｘｗと表される。
【００３５】
３ＧＰＰ  ＲＡＮ２における現在の作業の前提は、周期的に又はｅＮＢによるポーリングに基づいて使用されうる、新しいＰＤＣＰ状態報告フォーマットを導入することである。ＰＤＣＰ状態報告を用いて、一般的に、ＵＥは、ＵＥにおけるＰＤＣＰ受信状態についてｅＮＢへ通知する。
【００３６】
従来の報告は、最初の欠落したＰＤＣＰ  ＳＤＵに設定される、最初の欠落したシーケンス（ＦＭＳ）番号のためのフィールドと、最初の欠落したＰＤＣＰ  ＳＤＵから最後の順序から外れたシーケンスのＰＤＣＰ  ＳＤＵまでの次の８の倍数に切り上げられたＰＤＣＰ  ＳＮの数であって、最初の欠落したＰＤＣＰ  ＳＤＵを含まず、かつ、最後の順序から外れたシーケンスのＰＤＣＰ  ＳＤＵを含んだＰＤＣＰ  ＳＮの数に等しいビットの長さを有するビットマップフィールドとを含む。以下では、ＦＭＳとビットマップとがどのようにｅＮＢによって使用されうるかについて説明する。
【００３７】
ＦＭＳ：ＦＭＳフィールドを用いて、ｅＮＢは、どれだけの量のデータが飛んでいるか、すなわち、送信されていると共にｅＮＢとＵＥ  ＰＤＣＨの間でのリオーダリング処理にあるか、を知る。この情報は、ｅＮＢが自身の送信を制限し、ＰＤＣＰ  ＳＮスペースの１／２より多くが飛んでいる状態としないようにするのに有用である。さらに、その後の報告の間でＦＭＳフィールドがどのように進むかを比較することによって、平均ＰＤＣＰ受信レートを推定することができる。ＲＬＣ（ＬＴＥ）受信レートも（ＲＬＣフィードバックに基づいて）ｅＮＢにおいて知られるため、ｅＮＢは、その上に、ＷＬＡＮ受信レートを推定することができる。同様に、ｅＮＢは、ＷＬＡＮリンク上で飛んでいるデータを推定することができる（＝送信されたデータ−ＦＭＳ＋１−送信されたがＬＴＥ  ＲＬＣを介して受信されていないデータ）。これらの情報の両方が、ＰＤＣＰデータのフロー制御及びマルチパススケジューリング（ＬＴＥ又はＷＬＡＮ）のために、ｅＮＢにとって有用でありうる。
【００３８】
ビットマップ：ｅＮＢは、すでにＦＭＳを知ることだけで、ＬＴＥ単独のコネクティビティにおけるハンドオーバの後に、（送信された最も高いＳＮとＦＭＳとの間の全てのデータの）ＰＤＣＰ再送信を行うことができた。しかしながら、そのデータの一部が、ハンドオーバの後のＲＬＣの順序から外れた配信により、ＵＥによってすでに受信されていることがありうる。そのためにビットマップが導入された：それにより、どのＳＮが未完了でありどのＳＮが既に受信されているかを正確に示される。ビットマップにより、選択的な再送信が可能となる。ＬＷＡにおいてもＰＤＣＰレベルでの選択的な再送信を検討する場合に、ビットマップ（又は最も高い順序から外れて受信されたＳＮより小さい欠落したＳＮのリスト、ただしこれはビットマップより高いオーバヘッドを招きうる）が有用である。これらの選択的なＰＤＣＰ再送信は、例えばＷＬＡＮにおいてＰＤＵが失われた場合に、行われうる。ＬＴＥ  ＰＤＣＰによってこのギャップが回復させることにより、エンドユーザの性能を改善することができる。このような再送信が行われるかどうかはｅＮＢの実装次第でありうる。
【００３９】
ビットマップの最大サイズは、ＳＮ空間の１／２である。したがって、１５ビットのＳＮに対して、その最大サイズは、２ＫＢである。理論的な最大ＵＬレートが７５３７６ビット／ＴＴＩのＣａｔ５のＵＥに対して、これは、このＴＴＩ内の２１％のオーバヘッドを招き、これは非常に大きく、したがって、このビットマップを含んだ頻繁なフィードバックは好ましくは避けるべきである。
【００４０】
本文書において概説される方法を用いると、周期的報告のための２つの異なるＰＤＣＰ状態報告フォーマットを用いてＵＥを設定することができる。異なるフォーマットに基づく報告は、周期的報告を開始するための異なる周期と時間オフセットを有しうる。これは、ｅＮＢが詳細なＰＤＣＰ状態報告をより低い頻度で受信し、これにより上りリンクのオーバヘッドを回避するが、より詳細でないＰＤＣＰ状態報告をなおも非常に頻繁に受信することを可能とする。詳細なＰＤＣＰ状態報告は、レガシのＰＤＣＰ状態報告フォーマットを使用してもよく、頻繁なＰＤＣＰ状態報告は、例えばＦＭＳを含むのみの、新しいフォーマットを使用しうる。
【００４１】
本新規コンセプトは、より効率的なＰＤＣＰ状態報告を可能とする。本コンセプトは、２つの異なる状態報告フォーマットを利用する利点を使用することを可能とする。典型的には、それらのうちの１つはよりリソース効率がよく、したがって、上りリンクオーバヘッドが少なく、一方で、他のフォーマットは、より詳細化されており、例えば欠落したデータユニットの選択的な再送信を可能とすることができるが、より多くのＵＬ無線リソースを使用する。
【００４２】
１つの実施形態において、ＵＥは、２つの異なる設定可能な周期を有する２つの異なるＰＤＣＰ状態報告フォーマットに基づいて、周期的にＰＤＣＰ状態報告を行うように構成される。２つより多くのフォーマット（及び２つより多くの周期）が用いられてもよいが、ここでは例として２つのフォーマットが使用されることを仮定していることが理解されるべきである。
【００４３】
１つの実施形態において、第１の周期は、他の周期の倍数である。これは、シグナリングを減らすことを可能とする。
【００４４】
頻度の少ない報告は、詳細なＰＤＣＰ状態報告フォーマット、例えば、ＦＭＳ及びビットマップを含んだレガシのＰＤＣＰ状態報告フォーマットに対して、設定されうる。
【００４５】
頻度の多い報告は、より詳細でないＰＤＣＰ状態報告フォーマット、例えば、ＦＭＳにのみ基づきうる新しいフォーマットに対して設定されうる。
【００４６】
換言すれば、１つの実施形態において、２つの異なる周期、ＦＭＳ及びビットマップを報告するための１つの周期と、報告からビットマップを除いた、すなわちＦＭＳのみの他の周期が、周期的ＰＤＣＰ状態報告に対して設定されうる。
【００４７】
１つの実施形態において、ＵＥは、より多くの情報（例えばレガシのフォーマット、すなわち、ＦＭＳ及びビットマップ）を伴うフォーマットが、同時に、例えば同じＴＴＩで送信される場合、より少ない情報（例えばＦＭＳのみ）を伴うフォーマットの送信を省略するだろう。
【００４８】
１つの実施形態において、（例えば、t-StatusReportType1及びt-StatusReportType2と呼ばれ、本文書において、これより先により詳細に説明されるような）２つの異なるタイマが、異なるフォーマットに基づく状態報告の送信のタイミングを操作するために、ＵＥのＰＤＣＰ実装において使用される。
【００４９】
別の実施形態において、ＵＥは、２つのフォーマットの周期的報告の開始点の間のタイミングオフセットを用いて設定される。例えば、１つのタイマが既に動作しており、時刻ｔ１において開始されている場合、第２のタイマは、時刻ｔ２＝ｔ１＋オフセットで開始される。
【００５０】
１つの実施形態において、ＵＥは、ｅＮＢのポーリングによってトリガされたＰＤＣＰ報告を送信すると、周期タイマを再始動する。この実施形態の１つのバージョンにおいて、ＵＥは、ポーリングされたタイプの報告のための周期タイマのみを再始動する。例えば、ＦＭＳ＋ビットマップを伴う周期的報告を１００ｍｓごとに送信するようにｅＮＢがＵＥを設定し、また、ＦＭＳのみを伴う周期的報告を５０ｍｓごとに送信するようにＵＥを設定し、ｅＮＢがＦＭＳ＋ビットマップを伴う報告を取得するためにＵＥをポーリングした場合、ＵＥは、ＦＭＳ＋ビットマップを伴う報告をいつ送信するかを決定するために使用されるタイマを再始動する（が、ＦＭＳのみを伴う報告をいつ送信するかを決定するためのタイマを再始動しない）。代わりに、ＵＥは、いずれかの報告がポーリングされた場合に全ての周期タイマを再始動してもよく、すなわち、ここに上で与えられた例において、ＵＥは、ＦＭＳ＋ビットマップを伴う報告をいつ送信するかを決定するために用いられるタイマとＦＭＳのみを伴う報告をいつ送信するかを決定するために用いられるタイマとの両方を再始動する。
【００５１】
以下では、設定情報要素の例、より具体的には２つの独立した周期パラメータの新規のコンセプトがハイライトされた無線リソース制御（ＲＲＣ）制御メッセージを与える：
PDCP-Config ::=                      SEQUENCE {
discardTimer                     ENUMERATED {
ms50, ms100, ms150, ms300, ms500,
ms750, ms1500, infinity
}                                                      OPTIONAL,          -- Cond Setup
rlc-AM                           SEQUENCE {
statusReportRequired             BOOLEAN
}                                                      OPTIONAL,         -- Cond Rlc-AM
rlc-UM                           SEQUENCE {
pdcp-SN-Size                    ENUMERATED {len7bits, len12bits}
}                                                      OPTIONAL,          -- Cond Rlc-UM
headerCompression                CHOICE {
notUsed                          NULL,
rohc                             SEQUENCE {
maxCID                           INTEGER 
(1..16383)           DEFAULT 15,
profiles                         SEQUENCE {
profile0x0001                    BOOLEAN,
profile0x0002                    BOOLEAN,
profile0x0003                    BOOLEAN,
profile0x0004                    BOOLEAN,
profile0x0006                    BOOLEAN,
profile0x0101                    BOOLEAN,
profile0x0102                    BOOLEAN,
profile0x0103                    BOOLEAN,
profile0x0104                    BOOLEAN
},
...
}
},
...,
[[  rn-IntegrityProtection-r10       ENUMERATED {enabled}  OPTIONAL   -- Cond RN
]],
[[  pdcp-SN-Size-v1130           ENUMERATED {len15bits}    OPTIONAL   -- Cond Rlc-AM2
]],
[[  ul-DataSplitDRB-ViaSCG-r12       BOOLEAN    OPTIONAL,  -- Need ON
t-Reordering-r12             ENUMERATED {
ms0, ms20, ms40, ms60, ms80, ms100, ms120, ms140,
ms160, ms180, ms200, ms220, ms240, ms260, ms280, ms300,
ms500, ms750, spare14, spare13, spare12, spare11, spare10,
spare9, spare8, spare7, spare6, spare5, spare4, spare3,
spare2, spare1}                  OPTIONAL   -- Cond SetupS
]],
[[  statusFeedbackRequired-r13       BOOLEAN    OPTIONAL,  -- Need ON
statusPDU-TypeForPolling-r13     ENUMERATED {type1, type2}    OPTIONAL,  
statusPDU-PeriodicityType1-r13    ENUMERATED {ms50, ms100, ms150, ms200, ms300, ms500, ms1000, ms2000, ms5000, ms10000, ms20000, ms50000,
spare4, spare3, spare2, spare1}      OPTIONAL 
statusPDU-PeriodicityType2-r13    ENUMERATED {ms50, ms100, ms150, ms200, ms300, ms500, ms1000, ms2000, ms5000, ms10000, ms20000, ms50000,
spare4, spare3, spare2, spare1}      OPTIONAL 
]]
}
【００５２】
さらに、以下に、ＬＷＡ状態報告が受信状態報告の例である場合の、２つのタイマに従う制御を特定する例を与える：
（設定されている場合）t-StatusReportType1が満了したときに、ＵＥは、
−ＬＷＡベアラが上りリンクにおいてＰＤＣＰ状態報告を送信するように上位レイヤによって設定されている場合（statusFeedback [3]）：
−従属節５．３．１において規定されるように、タイプ１のＰＤＣＰ状態報告、すなわち、レガシのＰＤＣＰ状態報告を編集して送信し；
−t-StatusReportType1を開始しなければならない。
（設定されている場合）t-StatusReportType2が満了したときに、ＵＥは、
−ＬＷＡベアラが上りリンクにおいてＰＤＣＰ状態報告を送信するように上位レイヤに設定されている場合（statusFeedback [3]）：
−従属節５．ｘ．１において規定されるように、タイプ２のＰＤＣＰ状態報告、すなわち、ＬＷＡ  ＰＤＣＰ状態報告を編集して送信し；
−t-StatusReportType2を開始しなければならない。
t-StatusReportType1の値が上位レイヤによって設定され又は再設定されたときに、ＵＥは、
−t-StatusReportType1が動作している場合：
−t-StatusReportType1を停止して再始動し；
−t-StatusReportType1が動作していない場合：
−t-StatusReportType1を開始しなければならない。
t-StatusReportType2の値が上位レイヤによって設定され又は再設定されたときに、ＵＥは、
−t-StatusReportType2が動作している場合：
−t-StatusReportType2を停止して再始動し；
−t-StatusReportType2が動作していない場合：
−t-StatusReportType2を開始しなければならない。
タイマ記述：
ｂ）t-StatusReportType1
タイマの区間は、上位レイヤによって設定される（statusPDU-PeriodicityType1 [3]）。設定された場合、このタイマは、従属節５．ｘに規定されるように、ＬＷＡのためのタイプ１の状態報告送信をトリガするのに使用される。
ｃ）t-StatusReportType2
タイマの区間は、上位レイヤによって設定される（statusPDU-PeriodicityType2 [3]）。設定された場合、このタイマは、従属節５．ｘに規定されるように、ＬＷＡのためのタイプ２の状態報告送信をトリガするのに使用される。
【００５３】
なお、タイミングオフセット設定は、先の例に含まれない。
【００５４】
以下に、タイミングオフセット設定を含んだ例を与える。
-- ASN1START
PDCP-Config ::=                        SEQUENCE {
discardTimer                        ENUMERATED {
ms50, ms100, ms150, ms300, ms500,
ms750, ms1500, infinity
}                                                            OPTIONAL,            -- Cond Setup
rlc-AM                                SEQUENCE {
statusReportRequired                BOOLEAN
}                                                            OPTIONAL,            -- Cond Rlc-AM
rlc-UM                                SEQUENCE {
pdcp-SN-Size                        ENUMERATED {len7bits, len12bits}
}                                                            OPTIONAL,            -- Cond Rlc-UM
headerCompression                    CHOICE {
notUsed                                NULL,
rohc                                SEQUENCE {
maxCID                                INTEGER (1..16383)                DEFAULT 15,
profiles                            SEQUENCE {
profile0x0001                        BOOLEAN,
profile0x0002                        BOOLEAN,
profile0x0003                        BOOLEAN,
profile0x0004                        BOOLEAN,
profile0x0006                        BOOLEAN,
profile0x0101                        BOOLEAN,
profile0x0102                        BOOLEAN,
profile0x0103                        BOOLEAN,
profile0x0104                        BOOLEAN
},
...
}
},
...,
[[    rn-IntegrityProtection-r10        ENUMERATED {enabled}    OPTIONAL    -- Cond RN
]],
[[    pdcp-SN-Size-v1130                ENUMERATED {len15bits}    OPTIONAL    -- Cond Rlc-AM2
]],
[[    ul-DataSplitDRB-ViaSCG-r12        BOOLEAN        OPTIONAL,    -- Need ON
t-Reordering-r12                ENUMERATED {
ms0, ms20, ms40, ms60, ms80, ms100, ms120, ms140,
ms160, ms180, ms200, ms220, ms240, ms260, ms280, ms300,
ms500, ms750, spare14, spare13, spare12, spare11, spare10,
spare9, spare8, spare7, spare6, spare5, spare4, spare3,
spare2, spare1}                 OPTIONAL    -- Cond SetupS
]],
[[    ul-DataSplitThreshold-r13        CHOICE {
release                        NULL,
setup                        ENUMERATED {
b0, b100, b200, b400, b800, b1600, b3200, b6400, b12800,
b25600, b51200, b102400, b204800, b409600, b819200,
spare1}
}                                                               OPTIONAL,    -- Need ON
pdcp-SN-Size-v13xx                ENUMERATED {len18bits}    OPTIONAL,    -- Cond Rlc-AM3
statusFeedback                    CHOICE {
release                        NULL,
setup                        SEQUENCE {
statusPDU-TypeForPolling-r13    ENUMERATED {type1, type2}        OPTIONAL,
statusPDU-TypeForPeriodic-r13    ENUMERATED {type1, type2}        OPTIONAL,                            statusPDU-Periodicity-Type1-r13        ENUMERATED {ms50, ms100, ms150, ms200, ms300, ms500,
ms1000, ms2000, ms5000, ms10000, ms20000, ms50000,
spare4, spare3, spare2, spare1}        OPTIONAL        
statusPDU-Periodicity-Type2-r13        ENUMERATED {ms50, ms100, ms150, ms200, ms300, ms500,
ms1000, ms2000, ms5000, ms10000, ms20000, ms50000,
spare4, spare3, spare2, spare1}        OPTIONAL        
statusPDU-PeriodOffset-r13        ENUMERATED {ms50, ms100, ms150, ms200, ms300, ms500,
ms1000, ms2000, ms5000, ms10000, ms20000, spare5,
spare4, spare3, spare2, spare1}        OPTIONAL        -- Cond Lwa-TwoPeriodicReports
}
}                                                               OPTIONAL    -- Need ON 
]]
}
-- ASN1STOP
【００５５】
理解されるように、フィールド「statusPDU-PeriodOffset」が、情報要素に追加されている。
【００５６】
タイマのための制御の規定は、以下のように改正されうる：
t-StatusReportType1又はt-StatusReportType2の値が上位レイヤによって設定され又は再設定されたとき、ＵＥは、
−t-StatusReportType1が動作している場合：
−t-StatusReportType1を停止して再始動し；
−t-StatusReportType1が動作していない場合：
−t-StatusReportType1を開始し；
−t-StatusReportType2が動作している場合：
−t-StatusReportType2を停止し、t-StatusReportType1の開始と比して、設定されている場合にタイミングオフセットstatusPDU-PeriodOffset [3]の後に再始動し；
−t-StatusReportType2が動作していない場合：
−t-StatusReportType2を、t-StatusReportType1の開始と比して、設定されている場合にタイミングオフセットstatusPDU-PeriodOffset [3]の後に開始しなければならない。
【図１】
2019504576.tif 000003
【図２】
2019504576.tif 000004
【図３】
2019504576.tif 000005
【図４】
2019504576.tif 000006
【図５】
2019504576.tif 000007
【図６】
2019504576.tif 000008
【図７】
2019504576.tif 000009
【図８】
2019504576.tif 000010
【国際調査報告】
2019504576.tif 000011
2019504576.tif 000012
2019504576.tif 000013