(57)【要約】通信装置は、トランシーバ（３３）と、無線リンク制御エンティティ（５０）と、無線リンク制御（ＲＬＣ）バッファメモリ（１５０）とを有している。トランシーバ（３３）は、その装置の空中インタフェース（３２）による通信を可能にする。無線リンク制御（ＲＬＣ）エンティティ（５０）は、空中インタフェース（３２）による送信のためのアップリンクＲＬＣプロトコルデータユニット（ＰＤＵ）を形成し、空中インタフェース（３２）によりダウンリンクＲＬＣプロトコルデータユニット（ＰＤＵ）を受信する。無線リンク制御（ＲＬＣ）バッファメモリ（１５０）は、アップリンクＲＬＣプロトコルデータユニット（ＰＤＵ）を格納する送信機バッファとダウンリンクＲＬＣプロトコルデータユニット（ＰＤＵ）を格納する受信機バッファとを含むように構成される。無線リンク制御エンティティは、送信機バッファウィンドウのサイズと受信機バッファウィンドウのサイズとの内の少なくとも１つを再構成するＲＬＣ再構成ロジック手段（２００）を含む。その再構成を実行するときに、ＲＬＣ再構成ロジック手段は、（１）新しい受信機バッファウィンドウの外側にあるダウンリンクＲＬＣプロトコルデータユニット（ＰＤＵ）と（２）新しい送信機バッファウィンドウの外側にあるか或いは無線アクセスネットワークによる受信が肯定的に確認応答されなかったアップリンクＲＬＣプロトコルデータユニットとの内の少なくとも１つを処理する方策を実施する。
2006522560.tif 000002
【特許請求の範囲】
【請求項１】
通信装置であって、
空中インタフェース（３２）により前記装置の通信を可能にするトランシーバ（３３）と、
前記空中インタフェース（３２）による送信のためのアップリンクＲＬＣプロトコルデータユニット（ＰＤＵ）を形成し、前記空中インタフェース（３２）によりダウンリンクＲＬＣプロトコルデータユニット（ＰＤＵ）を受信する無線リンク制御エンティティ（５０）と、
前記アップリンクＲＬＣプロトコルデータユニット（ＰＤＵ）を格納する送信機バッファと前記ダウンリンクＲＬＣプロトコルデータユニット（ＰＤＵ）を格納する受信機バッファとを含むように構成された無線リンク制御（ＲＬＣ）バッファメモリ（１５０）とを有しており、
（１）新しい受信機バッファウィンドウの外側にあるダウンリンクＲＬＣプロトコルデータユニット（ＰＤＵ）と（２）新しい送信機バッファウィンドウの外側にあるか或いは無線アクセスネットワークによる受信が肯定的に確認応答されなかったアップリンクＲＬＣプロトコルデータユニット（ＰＤＵ）との内の少なくとも１つを処理する方策を実施することにより、送信機バッファウィンドウのサイズと受信機バッファウィンドウのサイズとの内の少なくとも１つを再構成するように構成されたＲＬＣ再構成ロジック手段を有することを特徴とする通信装置。
【請求項２】
前記通信装置は、ユーザ機器ユニットであり、
前記ＲＬＣ再構成ロジック手段は、
（Ａ）古い受信機バッファウィンドウ内にあるものとして受信されるが前記新しい受信機バッファウィンドウの外側にあるダウンリンクＲＬＣプロトコルデータユニット（ＰＤＵ）を破棄し、
（Ｂ）前記無線リンク制御（ＲＬＣ）バッファメモリ（１５０）に前記無線アクセスネットワークによる受信が肯定的に確認応答されなかったアップリンクＲＬＣプロトコルデータユニット（ＰＤＵ）を保持する
方策を実施するように構成されていることを特徴とする請求項１に記載の装置。
【請求項３】
前記無線リンク制御エンティティ（５０）はさらに、前記再構成後に、前記無線アクセスネットワークにより否定的に確認応答された前記アップリンクＲＬＣプロトコルデータユニット（ＰＤＵ）を再送信するように構成されていることを特徴とする請求項２に記載の装置。
【請求項４】
前記無線リンク制御エンティティ（５０）はさらに、前記再構成後に前記無線リンク制御（ＲＬＣ）バッファメモリ（１５０）がメモリサイズの制約を経験するとき、上位層から受信されたサービスデータユニット（ＳＤＵ）の分割を要求しないように構成されていることを特徴とする請求項２に記載の装置。
【請求項５】
前記無線リンク制御エンティティ（５０）は、前記古い受信機バッファウィンドウに受信されたが前記新しい受信機バッファウィンドウの外側にあるダウンリンクＲＬＣプロトコルデータユニット（ＰＤＵ）を否定的に確認応答しないことを特徴とする請求項２に記載の装置。
【請求項６】
前記通信装置は、ユーザ機器ユニットであり、
前記ＲＬＣ再構成ロジック手段は、
（Ａ）たとえ前記新しい受信機バッファの外側にあったとしても、前記受信機バッファウィンドウが進められるまで、前記受信機バッファに格納された全てのダウンリンクＲＬＣプロトコルデータユニット（ＰＤＵ）を保持し、
（Ｂ）たとえ前記新しい送信機バッファの外側にあったとしても、前記無線アクセスネットワークによる受信が肯定的に確認応答されなかった、前記送信機バッファに格納されたアップリンクＲＬＣプロトコルデータユニット（ＰＤＵ）を保持する
方策を実施するように構成されていることを特徴とする請求項１に記載の装置。
【請求項７】
前記無線リンク制御エンティティ（５０）はさらに、上位層からのサービスデータユニット（ＳＤＵ）の受信が前記無線リンク制御（ＲＬＣ）バッファメモリ（１５０）の容量を超えるかどうかをチェックするように構成されていることを特徴とする請求項６に記載の装置。
【請求項８】
前記無線リンク制御エンティティ（５０）はさらに、確認応答モードのＲＬＣエンティティに関し、前記バッファメモリが、ＶＴ（Ａ）＜ＳＮ＜ＶＴ（Ｓ）を満足するシーケンス番号ＳＮをもつ確認応答モードのＲＬＣプロトコルデータユニット（ＡＭＤ  ＰＤＵ）を格納するのに十分であるかどうかをチェックするように構成され、
ＶＴ（Ａ）は最新の順序正しく確認応答されたＡＭＤ  ＰＤＵに続くシーケンス番号であり、
ＶＴ（Ｓ）は初めて送信されることになる次のＡＭＤ  ＰＤＵについてのシーケンス番号であることを特徴とする請求項７に記載の装置。
【請求項９】
前記無線リンク制御エンティティ（５０）はさらに、前記無線アクセスネットワークからのプロトコルデータユニット（ＰＤＵ）の受信が前記無線リンク制御（ＲＬＣ）バッファメモリ（１５０）の容量を超えるかどうかをチェックするように構成されていることを特徴とする請求項６に記載の装置。
【請求項１０】
前記無線リンク制御エンティティ（５０）はさらに、確認応答モードのＲＬＣエンティティに関し、前記バッファメモリが、ＶＲ（Ｒ）＜ＳＮ＜ＶＲ（Ｈ）を満足するシーケンス番号ＳＮをもつ確認応答モードのＲＬＣプロトコルデータユニット（ＡＭＤ  ＰＤＵ）を格納するのに十分であるかどうかをチェックするように構成され、
ＶＲ（Ｒ）は最新の順序正しく受信しされたＡＭＤ  ＰＤＵに続くシーケンス番号であり、
ＶＲ（Ｈ）は何らかの受信されたＡＭＤ  ＰＤＵの最も大きいシーケンス番号に続くシーケンス番号であることを特徴とする請求項９に記載の装置。
【請求項１１】
前記通信装置は、無線アクセスネットワークノードであり、
前記ＲＬＣ再構成ロジック手段は、
（Ａ）再構成時、全てのダウンリンクＲＬＣプロトコルデータユニット（ＰＤＵ）を保持し、
（Ｂ）再構成時、全てのアップリンクＲＬＣプロトコルデータユニット（ＰＤＵ）を保持する
方策を実施するように構成されていることを特徴とする請求項１に記載の装置。
【請求項１２】
空中インタフェース（３２）により無線アクセスネットワークとの通信を行なうユーザ機器ユニット（３０）を動作させる方法であって、前記方法は、
前記空中インタフェース（３２）による送信のためのアップリンクＲＬＣプロトコルデータユニット（ＰＤＵ）を形成し、前記空中インタフェース（３２）によりダウンリンクＲＬＣプロトコルデータユニット（ＰＤＵ）を受信するために、無線リンク制御エンティティ（５０）を用いる工程と、
前記アップリンクＲＬＣプロトコルデータユニット（ＰＤＵ）を無線リンク制御（ＲＬＣ）のバッファメモリ（１５０）の送信機バッファに格納する工程と、
前記ダウンリンクＲＬＣプロトコルデータユニット（ＰＤＵ）を前記無線リンク制御（ＲＬＣ）バッファメモリ（１５０）の受信機バッファに格納する工程と、
ＲＬＣ再構成中に、前記ユーザ機器ユニット（３０）は、（１）古い送信機バッファウィンドウよりも小さい送信機バッファウィンドウサイズをもつ新しい送信機バッファウィンドウを形成するための送信機バッファウィンドウのサイズと、（２）古い受信機バッファウィンドウよりも小さい受信機バッファウィンドウサイズをもつ新しい受信機バッファウィンドウを形成するための受信機バッファウィンドウとの内の少なくとも１つを再構成するように指示され、
前記方法は、
（Ａ）前記古い受信機バッファウィンドウ内にあるものとして受信されたが前記新しい受信機バッファウィンドウの外側にあるダウンリンクＲＬＣプロトコルデータユニット（ＰＤＵ）を破棄し、
（Ｂ）前記無線リンク制御（ＲＬＣ）バッファメモリ（１５０）に、前記無線アクセスネットワークによる受信が肯定的に確認応答されなかったアップリンクＲＬＣプロトコルデータユニット（ＰＤＵ）を保持する
ことを特徴とする方法。
【請求項１３】
さらに、前記無線リンク制御エンティティ（５０）が、前記再構成後に前記無線アクセスネットワークにより否定的に確認応答された前記アップリンクＲＬＣプロトコルデータユニット（ＰＤＵ）を再送信することを特徴とする請求項１２に記載の方法。
【請求項１４】
さらに、前記無線リンク制御エンティティ（５０）が、前記再構成後に前記無線リンク制御（ＲＬＣ）バッファメモリ（１５０）がメモリサイズの制約を経験するとき、上位層から受信されたサービスデータユニット（ＳＤＵ）の分割を要求しないことを特徴とする請求項１２に記載の方法。
【請求項１５】
さらに、前記無線リンク制御エンティティ（５０）が、前記古い受信機バッファウィンドウにおいて受信されたが前記新しい受信機バッファウィンドウの外側にあるダウンリンクＲＬＣプロトコルデータユニット（ＰＤＵ）を否定的に確認応答しないことを特徴とする請求項１２に記載の方法。
【請求項１６】
空中インタフェース（３２）により無線アクセスネットワークとの通信を行なうユーザ機器ユニット（３０）を動作させる方法であって、前記方法は、
前記空中インタフェース（３２）による送信のためのアップリンクＲＬＣプロトコルデータユニット（ＰＤＵ）を形成し、前記空中インタフェース（３２）によりダウンリンクＲＬＣプロトコルデータユニット（ＰＤＵ）を受信するために、無線リンク制御エンティティ（５０）を用いる工程と、
前記アップリンクＲＬＣプロトコルデータユニット（ＰＤＵ）を無線リンク制御（ＲＬＣ）のバッファメモリ（１５０）の送信機バッファに格納する工程と、
前記ダウンリンクＲＬＣプロトコルデータユニット（ＰＤＵ）を前記無線リンク制御（ＲＬＣ）バッファメモリ（１５０）の受信機バッファに格納する工程と、
ＲＬＣ再構成中に、前記ユーザ機器ユニット（３０）は、（１）古い送信機バッファウィンドウよりも小さい送信機バッファウィンドウサイズをもつ新しい送信機バッファウィンドウを形成するための送信機バッファウィンドウのサイズと、（２）古い受信機バッファウィンドウよりも小さい受信機バッファウィンドウサイズをもつ新しい受信機バッファウィンドウを形成するための受信機バッファウィンドウとの内の少なくとも１つを再構成するように指示され、
前記方法は、
（Ａ）たとえ前記新しい受信機バッファの外側にあったとしても、前記受信機バッファウィンドウが進められるまで、前記受信機バッファに格納された全てのダウンリンクＲＬＣプロトコルデータユニット（ＰＤＵ）を保持し、
（Ｂ）たとえ前記新しい送信機バッファの外側にあったとしても、前記無線アクセスネットワークによる受信が肯定的に確認応答されなかった、前記送信機バッファに格納されたアップリンクＲＬＣプロトコルデータユニット（ＰＤＵ）を保持する
ことを特徴とする方法。
【請求項１７】
さらに、前記無線リンク制御エンティティ（５０）が上位層からのサービスデータユニット（ＳＤＵ）の受信が前記無線リンク制御（ＲＬＣ）バッファメモリ（１５０）の容量を超えるかどうかをチェックすることを特徴とする請求項１６に記載の方法。
【請求項１８】
さらに、前記無線リンク制御エンティティ（５０）が確認応答モードのＲＬＣエンティティに関し、前記バッファメモリが、ＶＴ（Ａ）＜ＳＮ＜ＶＴ（Ｓ）を満足するシーケンス番号ＳＮをもつ確認応答モードのＲＬＣプロトコルデータユニット（ＡＭＤ  ＰＤＵ）を格納するのに十分であるかどうかをチェックし、
ＶＴ（Ａ）は最新の順序正しく確認応答されたＡＭＤ  ＰＤＵに続くシーケンス番号であり、
ＶＴ（Ｓ）は初めて送信されることになる次のＡＭＤ  ＰＤＵについてのシーケンス番号であることを特徴とする請求項１７に記載の方法。
【請求項１９】
さらに、前記無線リンク制御エンティティ（５０）が前記無線アクセスネットワークからのプロトコルデータユニット（ＰＤＵ）の受信が前記無線リンク制御（ＲＬＣ）バッファメモリ（１５０）の容量を超えるかどうかをチェックすることを特徴とする請求項１６に記載の方法。
【請求項２０】
さらに、前記無線リンク制御エンティティ（５０）が確認応答モードのＲＬＣエンティティに関し、前記バッファメモリが、ＶＲ（Ｒ）＜ＳＮ＜ＶＲ（Ｈ）を満足するシーケンス番号ＳＮをもつ確認応答モードのＲＬＣプロトコルデータユニット（ＡＭＤ  ＰＤＵ）を格納するのに十分であるかどうかをチェックし、
ＶＲ（Ｒ）は最新の順序正しく受信しされたＡＭＤ  ＰＤＵに続くシーケンス番号であり、
ＶＲ（Ｈ）は何らかの受信されたＡＭＤ  ＰＤＵの最も大きいシーケンス番号に続くシーケンス番号であることを特徴とする請求項１９に記載の方法。
【請求項２１】
空中インタフェース（３２）によりユーザ機器ユニット（３０）と通信を行なう無線アクセスネットワークの無線アクセスノード（２６）を動作させる方法であって、前記方法は、
前記空中インタフェース（３２）による送信のためのアップリンクＲＬＣプロトコルデータユニット（ＰＤＵ）を形成し、前記空中インタフェース（３２）によりダウンリンクＲＬＣプロトコルデータユニット（ＰＤＵ）を受信するために、無線リンク制御エンティティ（５０）を用いる工程と、
前記アップリンクＲＬＣプロトコルデータユニット（ＰＤＵ）を無線リンク制御（ＲＬＣ）のバッファメモリ（１５０）の送信機バッファに格納する工程と、
前記ダウンリンクＲＬＣプロトコルデータユニット（ＰＤＵ）を前記無線リンク制御（ＲＬＣ）バッファメモリ（１５０）の受信機バッファに格納する工程と、
ＲＬＣ再構成中に、
（Ａ）再構成時、全てのダウンリンクＲＬＣプロトコルデータユニット（ＰＤＵ）を保持し、
（Ｂ）再構成時、全てのアップリンクＲＬＣプロトコルデータユニット（ＰＤＵ）を保持することにより、送信機バッファウィンドウのサイズと受信機バッファウィンドウとの内の少なくとも１つを再構成する工程とを有することを特徴とする方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は無線通信に関し、特に、接続中に無線リンク制御（ＲＬＣ）のパラメータを再構成する方法及び装置に関するものである。
【背景技術】
【０００２】
典型的なセルラ無線システムにおいて、無線ユーザ機器ユニット（ＵＥ）は無線アクセスネットワーク（ＲＡＮ）を介して１つ以上のコアネットワークに通信する。そのユーザ機器ユニット（ＵＥ）は移動電話（“セルラ”電話）や移動端末を備えたラップトップのような移動局でも良く、従って、音声とデータとの内少なくともいずれかを無線アクセスネットワークと通信する、例えば、携帯型、ポケット型、手持ち型、コンピュータ内蔵型、或いは車輌積載型の移動体機器でも良い。或いは、無線機器ユニットは固定無線機器、例えば、無線ローカルループなどの一部である固定セルラ機器／端末でも良い。
【０００３】
無線アクセスネットワーク（ＲＡＮ）は複数のセル領域に分割された地理的な領域をカバーし、各セル領域は基地局によってサービスを受ける。セルは地理的な領域であり、そこには無線カバレッジが基地局のある場所の無線基地局装置によって備えられる。各セルはユニークなアイデンティティにより識別され、それがそのセルにおいて同報される。基地局は空中インタフェース（例えば、無線周波数）により基地局の範囲内でユーザ機器ユニット（ＵＥ）と通信を行なう。無線アクセスネットワークでは、いくつかの基地局は通常は無線ネットワーク制御局（ＲＮＣ）と（例えば、ランドライン或いはマイクロ波により）接続されている。また、無線ネットワーク制御局は、しばしば基地局制御局（ＢＳＣ）とも呼ばれ、そこに接続されている複数の基地局の種々のアクティビティを監視し調整する。無線ネットワーク制御局は通常は１つ以上のコアネットワークに接続されている。そのコアネットワークは種々のサービスドメインをもち、ＲＮＣはこれらのドメインに対するインタフェースを備えている。
【０００４】
無線アクセスネットワークの一例は、世界規模の移動体通信サービス（ＵＭＴＳ）の地上無線アクセス網（ＵＴＲＡＮ）である。ＵＭＴＳは、いくつかの点については、欧州で開発された汎欧州デジタル移動電話方式（ＧＳＭ）として知られる無線アクセス技術上に構築された第３世代のシステムである。ＵＴＲＡＮは本質的には、ユーザ機器ユニット（ＵＥ）に広帯域符号分割多元接続（Ｗ−ＣＤＭＡ）を提供する無線アクセスネットワークである。第３世代パートナーシッププロジェクト（３ＧＰＰ）はＵＴＲＡＮとＧＳＭを基本とする無線アクセスネットワーク技術をさらに進歩させることに着手した。
【０００５】
世界規模の移動体通信サービス（ＵＭＴＳ）の地上無線アクセス網（ＵＴＲＡＮ）は、回路交換接続とパケット交換接続の両方を収容する。ＵＴＲＡＮには、関心のあるいくつかのインタフェースがある。無線ネットワーク制御局（ＲＮＣ）とコアネットワークとの間のインタフェースは、“Ｉｕ”インタフェースと名づけられる。無線ネットワーク制御局（ＲＮＣ）とその基地局（ＢＳ）との間のインタフェースは、“Ｉｕｂ”インタフェースと名づけられる。ユーザ機器ユニット（ＵＥ）と基地局との間のインタフェースは、“空中インタフェース”或いは“無線インタフェース”或いは“Ｕｕインタフェース”として知られている。無線ネットワーク制御局間（例えば、サービングＲＮＣ（ＳＲＮＣ）とドリフトＲＮＣ（ＤＲＮＣ）との間）でのインタフェースは、“Ｉｕｒ”インタフェースと名づけられる。
【０００６】
無線ネットワーク制御局（ＲＮＣ）はＵＴＲＡＮを制御する。その制御の役割を成し遂げるときに、ＲＮＣはＵＴＲＡＮの資源を管理する。ＲＮＣによって管理されるそのような資源は、（とりわけ）基地局により送信されるダウンリンク（ＤＬ）電力、基地局により感知されるアップリンク（ＵＬ）の干渉、及び基地局に位置するハードウェアを含んでいる。
【０００７】
ＵＭＴＳの地上無線アクセス網（ＵＴＲＡＮ）は、ユーザ機器ユニット（ＵＥ）との通信をサポートするために必要な資源を割当てることにより無線アクセスサービス要求に応じている。無線アクセスベアラを確立するための手順は非特許文献１に記載されており、それはここで参照により本願に組み込まれる。無線アクセスベアラ（ＲＡＢ）は、ＵＴＲＡＮを介した、そして、無線空中インタフェースによるユーザ機器ユニット（ＵＥ）との論理的接続であり、単一のデータストリームに対応している。例えば、１つの無線アクセスベアラは音声接続をサポートしており、別のベアラはビデオ接続をサポートしており、３番目のベアラはデータパケット接続をサポートしているかもしれない。各無線アクセスベアラは、ＵＴＲＡＮがそのデータストリームをどのように扱うべきなのかを記述したサービス品質（ＱｏＳ）パラメータと関係している。“無線アクセスベアラ”という用語がしばしば次の説明のために用いられるが、本発明は如何なるタイプの“接続”にも適用でき、ＲＡＢのような論理的接続や特定のタイプの物理的な接続などに限定されるものではない。
【０００８】
無線アクセスベアラのサービスを始めるために、ユーザ機器ユニット（ＵＥ）との通信のための要求がＵＴＲＡＮに送信される。１つ以上のパラメータが無線アクセスベアラサービス要求に伴う。各ベアラを確立するとき、ＵＴＲＡＮは無線アクセスベアラを、ＵＴＲＡＮを介した物理的なトランスポートと、無線空中インタフェースによる無線チャネル資源に夫々“マップ”或いは割当てる。そのマッピングは無線アクセスベアラサービス要求に関係した１つ以上のパラメータに基づいている。
【０００９】
世界規模の移動体通信サービス（ＵＭＴＳ）において、無線リンク制御（ＲＬＣ）レイヤはそのＲＬＣプロトコルと共に、（インターネットプロトコル（ＩＰ）レイヤのような）上位レイヤと媒体アクセス制御（ＭＡＣ）レイヤとの間に置かれる。無線リンク制御（ＲＬＣ）は種々の使用法をもつプロトコルレイヤである。無線リンク制御（ＲＬＣ）はいくつかの動作モードをもち、それらにはトランスペアレントモード、非確認応答モード、及び確認応答モード（ＡＭ）が含まれる。ＡＭモードにおいて用いられるＲＬＣ  ＰＤＵは（ユーザデータを搬送するＲＬＣ  ＰＤＵに関して）ＡＭＤ  ＰＤＵと呼ばれる。上位レイヤの要求に従って、動作モードは選択される。無線リンク制御（ＲＬＣ）はデータフローとシグナリングフローとの両方のために用いられる。
【００１０】
図１は、ＲＬＣ  ＰＤＵ（プロトコルデータユニット）を媒体アクセス制御（ＭＡＣ）レイヤ１１に送信したり、またＲＬＣ  ＰＤＵをＭＡＣレイヤ１１から受信する無線リンク制御（ＲＬＣ）レイヤ１０を示している。図１の図示した例において、媒体アクセス制御（ＭＡＣ）レイヤ１１はＲＬＣレイヤに相対的に“下位レイヤ”として機能する。一方、“上位レイヤ”１２はＴＣＰ／ＩＰレイヤ（例えば、ＩＰレイヤ）のようなレイヤであって良い。媒体アクセス制御（ＭＡＣ）レイヤ１１は、例えば、論理チャネルとトランスポートチャネルとの間のマッピング、優先度処理、トランスポートチャネルにおけるデータフローのスケジューリングなどを担当する。
【００１１】
無線アクセスベアラ（ＲＡＢ）は各サービスに対して確立される。各無線アクセスベアラに関し、少なくとも１つのＲＬＣエンティティが、ユーザ機器ユニットとＵＴＲＡＮの両方において確立される。ＡＭ  ＲＬＣの場合、１つの確立されたエンティティがある。ＵＭとＴＭの場合、１つのダウンリンクと１つのアップリンクのＲＬＣエンティティ（或いは、１つの方向にただ単一のＲＬＣエンティティ）がある。
【００１２】
図１は、ＡＭモードに関して、ＲＬＣエンティティ１０−ＵＥがユーザ機器ユニット（ＵＥ）に備えられ、ＲＬＣエンティティ１０−ＲＡＮがＵＴＲＡＮに備えられることを示している。下位レイヤ（例えば、媒体アクセス制御（ＭＡＣ）レイヤ１１）に関し、各ＲＬＣエンティティには送信側と受信側とがある。ＲＬＣ  ＰＤＵがあると、無線リンク制御（ＲＬＣ）レイヤのＲＬＣプロトコルは、（図１の図示ではＴＣＰ／ＩＰ  ＩＰパケットである）上位レベルのサービスデータユニット（ＳＤＵ）の順序正しい配信をサポートする。無線リンク制御（ＲＬＣ）レイヤは非特許文献２により詳細に記載されており、これは参照によりここで本願に組み込まれる。
【００１３】
ある限定された符号タイプのエラーリカバリ能力（例えば、畳み込み符号化）は空中インタフェース（即ち、無線インタフェース）により提供される。その空中インタフェースにより、そのようなエラーリカバリは局所的にローカル再送プロトコルを用いて実行される。送信バッファの全データはそれが成功裏に配信されるまでキャッシュされる。この点に関して、例えば、無線リンク制御（ＲＬＣ）レイヤの無線リンク制御（ＲＬＣ）プロトコルはローカル再送プロトコル−自動繰返し要求（ＡＲＱ）をもっている。
【００１４】
ＵＥ参照クラス３８４ｋｂｐｓをもつユーザ機器ユニット（ＵＥ）のシナリオを考えてみる。ここで参照により本願に組み込まれる非特許文献３によれば、このＵＥクラスについての典型的なＲＬＣ能力は、５０ｋバイトのＵＥメモリと最大６つのＡＭ（確認応答モード）のＲＬＣエンティティをもつという特徴がある。従って、このユーザ機器ユニット（ＵＥ）は潜在的には、３つの並行的にパケット交換される（ＰＳ）ＲＡＢを使用できる。しかしながら、説明を簡単にするために、現在のシナリオでは、このユーザ機器ユニット（ＵＥ）は２つの同時的なＰＳ  ＲＡＢ、例えば、２つの並行的なインタラクティブＲＡＢ、或いは１つのインタラクティブＲＡＢと１つのストリーミングＲＡＢで動作するとしている。
【００１５】
ＡＭモードにおいて動作するＲＬＣエンティティについて、スライディングウィンドウのように機能する機構が用いられてＲＬＣパケットデータユニット（ＰＤＵ）のフローを制御する。第１のＰＳ  ＲＡＢがこのシナリオのユーザ機器ユニット（ＵＥ）に対してセットアップされるとき、ＵＴＲＡＮは第２の（或いは第３の）ＰＳ  ＲＡＢが将来セットアップされるかどうかをまだ知ることはできない。それで、続くＲＡＢがセットアップされるとき第１のＰＳ  ＲＡＢのＲＬＣウィンドウサイズを削減することができないなら、ＵＴＲＡＮは将来的にセットアップされる可能性のある他のＲＡＢのメモリ使用を考慮しなければならない。例えば、２つの並行的なＰＳ  ＲＡＢを許すために、ＵＴＲＡＮは最初のＰＳ  ＲＡＢについて利用可能なＵＥメモリの半分だけを割当てことができる。
【００１６】
このシナリオでは、第１のＰＳ  ＲＡＢだけがセットアップされることになるなら、ＵＴＲＡＮはおそらく、例えば、ダウンリンクで５１２そしてアップリンクで２５６のウィンドウサイズの第１のＰＳ  ＲＡＢに対して残りの全メモリを割当てるであろう。その結果、全てのメモリ使用は４２ｋバイトになる。しかしながら、ＲＬＣウィンドウサイズを再構成する能力がないと、第１のＰＳ  ＲＡＢについてのそのような十分なメモリ割当ては生じ得ない。これは、（第２のＰＳ  ＲＡＢが実際にセットアップされるかどうかに係らず）第１のＰＳ  ＲＡＢがセットアップされたとき、第２のＰＳ  ＲＡＢの潜在的なメモリ使用が最初に考慮される必要があるためである。その結果、第１のＰＳ  ＲＡＢについてのＲＬＣメモリ（そして従って第１のＰＳ  ＲＡＢに関するＲＬＣウィンドウサイズ）は、例えば、ダウンリンクで２５６、アップリンクで１２８に構成することができるだけである。当然のことながら、この結果、特に、（発生しないかもしれない）第２のＰＳ  ＲＡＢがセットアップされる前に性能低下が生じる。
【００１７】
特に、３８４ｋｂｐｓのような高速データ速度に関し、ＲＬＣウィンドウサイズは遅延／スループットの点から性能に重大な影響をもつ。２つの並行的なＰＳ  ＲＡＢがＰＳ接続の一部で用いられるだけであるかもしれないので、このことは、大量のＵＥメモリが大抵のＵＥに対して用いられず、ＰＳ接続に対するスループットが不必要に低いことを示唆している。３つの並行的なＰＳ  ＲＡＢの場合が考慮されるとき、この性能低下はもっと急激なものでありさえする。ＵＴＲＡＮは第１のＰＳ  ＲＡＢをセットアップするときに利用可能なＵＥメモリの３分の１だけを割当てることができるに過ぎない。
【００１８】
これに対して、もし、ＲＬＣウィンドウサイズが効果的に再構成で小さくすることができれば、ＵＴＲＡＮはおそらく第１のＰＳ  ＲＡＢに対して全メモリを割当てるであろう。その時、もし第２のＰＳ  ＲＡＢが後でセットアップされるなら、そのウィンドウサイズは同時ＲＡＢの数に合わせるよう再構成される。
【００１９】
結局のところ、ＲＲＣシグナリング標準は現在名目上は、例えば、ＲＡＤＩＯ  ＢＥＡＲＥＲ  ＲＥＣＯＮＦＩＧＵＲＡＴＩＯＮ  メッセージで、接続中にＲＬＣパラメータの再構成をサポートしている。ＲＬＣウィンドウサイズの再構成は、ここで参照により本願に組み込まれる非特許文献４に従って表面上はサポートされる。
【非特許文献１】３ＧＰＰ  ＴＳ２５．９３１，ｖ５．１．０，技術仕様（Technical Specification 3GPP TS 25.931, v5.1.0）
【非特許文献２】３ＧＰＰ  ＴＳ２５．３２２，Ｖ．６．０．０（２００３年１２月），第３世代パートナーシッププロジェクト、グループ無線アクセスネットワーク、ＲＬＣプロトコル仕様(リリース６）（3GPP TS 25.322, V.6.0.0 (2003-12), 3rd Generation Partnership Project; Technical Specification Group Radio Access Network; RLC Protocol Specification (Release 6)）
【非特許文献３】３ＧＰＰ  ＴＳ２５．３０６，ｖ５．７０
【非特許文献４】３ＧＰＰ  ＴＳ２５．３３１，ｖ３．１７．０，技術仕様  セクション８．２．２．３及び８．６．４．９（Technical Specification 3GPP TS 25.331, v3.17.0 section 8.2.2.3 and 8.6.4.9）
【発明の開示】
【発明が解決しようとする課題】
【００２０】
しかしながら、そのような再構成に関係した動作、特に、ＲＬＣウィンドウサイズを縮小することは明示的には記載されておらず、例えば、上述した非特許文献２にも非特許文献４にも記載されていない。さらにその上、そのウィンドウサイズが小さくなるとき、ＵＥの動作は明瞭ではなく、潜在的には問題が多い。
【００２１】
それ故に必要とされることは、つまり、本発明の目的は、ＲＬＣウィンドウサイズを小さくすることを実行する効果的な方法である。
【課題を解決するための手段】
【００２２】
通信装置は、トランシーバと、無線リンク制御エンティティと、無線リンク制御（ＲＬＣ）バッファメモリとを有する。そのトランシーバにより、前記装置が空中インタフェースにより通信が可能になる。無線リンク制御エンティティは、前記空中インタフェースによる送信のためのアップリンクＲＬＣプロトコルデータユニット（ＰＤＵ）を形成し、前記空中インタフェースによりダウンリンクＲＬＣプロトコルデータユニット（ＰＤＵ）を受信する。無線リンク制御（ＲＬＣ）バッファメモリは、そのアップリンクＲＬＣプロトコルデータユニット（ＰＤＵ）を格納する送信機バッファとそのダウンリンクＲＬＣプロトコルデータユニット（ＰＤＵ）を格納する受信機バッファとを含むように構成される。前記無線リンク制御エンティティは、送信機バッファウィンドウのサイズと受信機バッファウィンドウのサイズとの内の少なくとも１つを再構成するＲＬＣ再構成ロジック手段を有する。その再構成を実行するとき、前記ＲＬＣ再構成ロジック手段は、（１）新しい受信機バッファウィンドウの外側にあるダウンリンクＲＬＣプロトコルデータユニット（ＰＤＵ）と（２）新しい送信機バッファウィンドウの外側にあるか或いは無線アクセスネットワークによる受信が肯定的に確認応答されなかったアップリンクＲＬＣプロトコルデータユニット（ＰＤＵ）との内の少なくとも１つを処理する方策を実施する。
【００２３】
その装置がユーザ機器ユニットであるときの動作の第１の実施例と態様において、前記無線リンク制御（ＲＬＣ）エンティティは、（Ａ）古い受信機バッファウィンドウ内にあるものとして受信されたが新しい受信機バッファウィンドウの外側にあるダウンリンクＲＬＣプロトコルデータユニット（ＰＤＵ）を破棄し、（Ｂ）無線アクセスネットワークによる受信が肯定的に確認応答されなかったアップリンクＲＬＣプロトコルデータユニット（ＰＤＵ）を無線リンク制御（ＲＬＣ）バッファメモリに保持する。
【００２４】
古い受信機バッファウィンドウ内にあるものとして受信されたが新しい受信機バッファウィンドウの外側にあるダウンリンクＲＬＣプロトコルデータユニット（ＰＤＵ）を破棄することにおいて、無線リンク制御エンティティはさらに、破棄されたダウンリンクＲＬＣプロトコルデータユニットを否定的に確認応答しない。無線アクセスネットワークによる受信が肯定的に確認応答されなかったアップリンクＲＬＣプロトコルデータユニット（ＰＤＵ）を保持するという観点からすれば、無線リンク制御は（再構成後に）無線アクセスネットワークにより否定的に確認応答されたアップリンクＲＬＣプロトコルデータユニット（ＰＤＵ）を再送信できる。
【００２５】
ユーザ機器ユニットに関する第１の実施例と態様の変形例として、無線リンク制御エンティティはオプション的には、再構成後に無線リンク制御（ＲＬＣ）バッファメモリがメモリサイズの制約を経験するとき、上位層から受信されたサービスデータユニット（ＳＤＵ）の分割を要求しなくても良い。
【００２６】
その装置がユーザ機器ユニットであるときの動作の第２の実施例と態様において、前記無線リンク制御（ＲＬＣ）エンティティは、（Ａ）たとえ新しい受信機バッファの外側にあったとしても、受信機バッファウィンドウが進められるまで、受信機バッファに格納された全てのダウンリンクＲＬＣプロトコルデータユニット（ＰＤＵ）を保持し、（Ｂ）たとえ新しい送信機バッファの外側にあったとしても、送信機バッファに格納されたアップリンクＲＬＣプロトコルデータユニット（ＰＤＵ）を保持する。
【００２７】
その変形例において、第２の実施例と態様とはオプション的には、無線リンク制御（ＲＬＣ）バッファメモリのついての容量制限についてのチェックを実行する。容量制限がある場合には、ＲＬＣエンティティはオプション的には保護対策を実行できる。
【００２８】
第１のメモリ容量チェックの例として、無線リンク制御エンティティは、上位層からのサービスデータユニット（ＳＤＵ）の受信が無線リンク制御（ＲＬＣ）バッファメモリの容量を超えるかどうかをチェックし、（もしそうであれば）そのＳＤＵを処理しないように決定する。無線リンク制御エンティティにより実行された第１のメモリ容量チェックの例は、確認応答モードのＲＬＣエンティティに関し、前記バッファメモリが、ＶＴ（Ａ）＜ＳＮ＜ＶＴ（Ｓ）を満足するシーケンス番号ＳＮをもつ確認応答モードのＲＬＣプロトコルデータユニット（ＡＭＤ  ＰＤＵ）を格納するのに十分であるかどうかを判断することを含むことができる。第１のメモリ容量チェックの例において、ＶＴ（Ａ）は最新の順序正しく確認応答されたＡＭＤ  ＰＤＵに続くシーケンス番号であり、ＶＴ（Ｓ）は初めて送信されることになる次のＡＭＤ  ＰＤＵについてのシーケンス番号である。
【００２９】
第２のメモリ容量チェックの例として、無線リンク制御エンティティは、無線アクセスネットワークからのプロトコルデータユニット（ＰＤＵ）の受信が無線リンク制御（ＲＬＣ）バッファメモリの容量を超えるかどうかをチェックし、（もしそうであれば）そのＰＤＵを無視するように決定する。無線リンク制御エンティティにより実行された第２のメモリ容量チェックの例は、確認応答モードのＲＬＣエンティティに関し、バッファメモリが、ＶＲ（Ｒ）＜ＳＮ＜ＶＲ（Ｈ）を満足するシーケンス番号ＳＮをもつ確認応答モードのＲＬＣプロトコルデータユニット（ＡＭＤ  ＰＤＵ）を格納するのに十分であるかどうかを判断することを含むことができる。第２のメモリ容量チェックの例において、ＳＮはＰＤＵのシーケンス番号であり、ＶＲ（Ｒ）は最新の順序正しく受信されたＡＭＤ  ＰＤＵに続くシーケンス番号であり、ＶＲ（Ｈ）は何らかの受信されたＡＭＤ  ＰＤＵの最も大きいシーケンス番号に続くシーケンス番号である。
【００３０】
この再構成に関与する通信装置が、無線アクセスネットワークノードであるとき、前記ＲＬＣ再構成ロジックは、その再構成時、ダウンリンクにおける全てのＰＤＵを保持する。同様に、送信側でも、再構成時、アップリンクにおける全てのＰＤＵが保持される。なぜなら、ユーザ機器ユニットは再構成時にアップリンクデータを破棄するかもしれないし、或いは破棄しないかもしれないからである。
【００３１】
本発明の前述などの目的と特徴と利点とは、添付図面において図示されるように好適な実施例についての次のより具体的な記述から明らかになるであろう。その添付図面において、参照記号は種々の図面を通じて同じ部分に言及している。その図面は、必ずしもスケールをきちんを決める必要はなく、その代わりに本発明の原理を図解することに重きが置かれている。
【発明を実施するための最良の形態】
【００３２】
次の記載では、限定ではなく説明を目的として、本発明の完全な理解を提供するために特定のアーキテクチュア、インタフェース、技術などの具体的な詳細が説明される。しかしながら、本発明がこれらの詳細な説明から離れた他の実施例において実践されても良いことが当業者には明らかである。他の例では、公知の機器、回路、及び方法の詳細な説明は、不必要な詳細な説明により本発明の説明をあいまいなものとしないように省略される。さらにその上、個々の機能ブロックが図面のいくつかには示されている。当業者であれば、個々のハードウェア回路と、適切にプログラムされたデジタルマイクロプロセッサ或いは汎用コンピュータとの関連で機能するソフトウェアと、特定用途向け集積回路（ＡＳＩＣ）と、１つ以上のデジタル信号プロセッサ（ＤＳＰ）との内、少なくともいずれかを用いて、これらの機能が実現されても良いことを認識するであろう。
【００３３】
上に示唆された無線アクセスネットワークの例示的で非限定的な実施例は、図２に示される世界規模の移動体通信（ＵＭＴＳ）１３の環境下で説明される。雲形１４として示されている代表的な接続指向の外部コアネットワークは、例えば、公衆交換電話ネットワーク（ＰＳＴＮ）と統合型サービスデジタルネットワーク（ＩＳＤＮ）との内、少なくともいずれかで良い。雲形１６として示されている代表的な非接続型の外部コアネットワークは、例えば、インターネットでも良い。両方のコアネットワークはそれらが対応するサービスノードに接続される。ＰＳＴＮ／ＩＳＤＮの接続指向型ネットワーク１４は回路交換サービスを提供する移動体交換センタ（ＭＳＣ）ノード１８として示されている接続指向型のサービスノードに接続される。インターネットのような非接続指向型のネットワーク１６は、しばしば、サービングＧＰＲＳサービスノード（ＳＧＳＮ）として言及されるパケット交換型のサービスを提供するためにあつらえられた汎用パケット無線サービス（ＧＰＲＳ）ノード２０に接続される。
【００３４】
コアネットワークサービスノード１８と２０の夫々は、Ｉｕインタフェースとして言及されている無線アクセスネットワーク（ＲＡＮ）インタフェースによりＵＭＴＳの地上無線アクセス網（ＵＴＲＡＮ）２４に接続している。ＵＴＲＡＮ２４は１つ以上の無線ネットワーク制御局（ＲＮＣｓ）２６を含んでいる。説明を単純にするために、図２のＵＴＲＡＮ２４には２つだけのＲＮＣノード、特に、ＲＮＣ２６1とＲＮＣ２６2とが示されている。各ＲＮＣ２６は複数の基地局（ＢＳ）２８に接続されている。例えば、再び説明を簡単にするために、２つの基地局ノードが各ＲＮＣ２６に接続されているように示されている。この点について、ＲＮＣ２６1は基地局２８1-1と基地局２８1-2にサービスを行なう一方、ＲＮＣ２６2は基地局２８2-1と基地局２８2-2にサービスを行なう。異なる数の基地局が各ＲＮＣによりサービスを受け、ＲＮＣは同じ数の基地局にサービスを行なう必要はないことが認識される。さらにその上、図２はＲＮＣがＩｕｒインタフェースによりＵＴＲＡＮ２４において１つ以上の別のＲＮＣに接続されることを示している。さらに、当業者であれば、基地局ノードは、ある環境では、最近になって、ノードＢ、或いはＢ−ノードとして知られるようになったことを認識するであろう。
【００３５】
図示された実施例において、説明を簡単にするために、各基地局２８は１つのセルにサービスを行なうものとして示されている。各セルは各基地局を囲む円によって表現されている。しかしながら、基地局は１個以上のセルに対して空中インタフェースにより通信を行なうためにサービスを行っても良いことが当業者には認識されるであろう。例えば、２つのセルが同じ基地局のサイトに位置する資源を用いても良い。
【００３６】
図２に示されているユーザ機器ユニット（ＵＥ）３０のようなユーザ機器ユニット（ＵＥ）は、１つ以上のセル或いは１つ以上の基地局（ＢＳ）２８と無線或いは空中インタフェース３２を介して通信をする。無線インタフェース３２とＩｕインタフェースとＩｕｂインタフェースとＩｕｒインタフェースの各々は、図２において、一点鎖線で示されている。
【００３７】
無線接続は、ＣＤＭＡ拡散コードを用いて割当てられた個々の無線チャネルを備えた広帯域符号分割多元接続（ＷＣＤＭＡ）に基づくのが好ましい。もちろん、他の接続方法が採用されても良い。ＷＣＤＭＡはマルチメディアサービスと他の高速送信要求のための広帯域とダイバーシティハンドオフとＲＡＫＥ受信機のような耐性の強い特徴とを備え、高品質を保証している。各ユーザ移動局或いは機器ユニット（ＵＥ）３０にはそれ自身のスクランブルコードが割当てられ、基地局２８がその特定のユーザ機器ユニット（ＵＥ）からの送信を識別するとともに、ユーザ機器ユニット（ＵＥ）がそのユーザ機器ユニットに対して意図された基地局からの送信をその同じ領域に存在する他の送信と雑音の全てから識別する。
【００３８】
図３は、ユーザ機器ユニット（ＵＥ）３０と、無線ネットワーク制御局２６と基地局２８のような例示的なノードの選択された概要を示している。図３に示されたユーザ機器ユニット（ＵＥ）３０は、ユーザ機器ユニット（ＵＥ）により要求された種々の動作を制御するデータ処理制御ユニット３１を含んでいる。ＵＥのデータ処理制御ユニット３１は、アンテナ３５に接続された無線トランシーバ３３への制御信号とデータとを提供する。無線トランシーバ３３は物理レイヤの機能である。
【００３９】
図３に示されている無線ネットワーク制御局２６と基地局２８の例は、夫々が、ＲＮＣ２６とユーザ機器ユニット（ＵＥｓ）３０との間での通信を行うのに必要とされる数多くの無線とデータの処理動作を実行する対応するデータ処理制御ユニット３６と３７とを夫々含む無線ネットワークノードである。基地局のデータ処理制御ユニット３７によって制御される機器の一部は、１つ以上のアンテナ３９に接続される複数の無線トランシーバ３８を含む。
【００４０】
図２と図３の例において、エンティティペアの１つのＲＬＣエンティティはサービング無線ネットワーク制御局（ＳＲＮＣ）２６1（即ち、無線リンク制御（ＲＬＣ）エンティティ５０−ＲＡＮ）に置かれる一方、そのエンティティペアのもう１つのＲＬＣエンティティは移動局（ＭＳ）３０（即ち、無線リンク制御（ＲＬＣ）エンティティ５０−ＵＥ）に置かれる。無線通信アクセスネットワークノードであるＳＲＮＣ２６とユーザ機器ユニット３０の両方は、ここで、通信“デバイス”の例として考慮される。無線リンク制御（ＲＬＣ）エンティティ５０−ＵＥと無線リンク制御（ＲＬＣ）エンティティ５０−ＲＡＮとの間のＲＬＣ  ＰＤＵの送信は図２と図３において両端に矢先のある矢５２によって描かれている。
【００４１】
無線リンク制御（ＲＬＣ）エンティティ５０−ＲＡＮと無線リンク制御（ＲＬＣ）エンティティ５０−ＵＥとが図２と図３において、夫々データ処理制御ユニットにおいて具現化されたものとして示されているが、無線リンク制御（ＲＬＣ）エンティティ５０の機能性は多くの方法で提供されることを理解されたい。例えば、無線リンク制御（ＲＬＣ）エンティティ５０の機能は、個々のハードウェア回路と、適切にプログラムされたデジタルマイクロプロセッサ或いは汎用コンピュータとの関連で機能するソフトウェアと、アプリケーション専用集積回路（ＡＳＩＣ）と、１つ以上のデジタル信号プロセッサ（ＤＳＰ）との内、少なくともいずれかを用いて、実現されても良い。
【００４２】
図４は（非確認応答モードやトランスペアレントモードとは対照的に）確認応答モードについての無線リンク制御（ＲＬＣ）エンティティ５０の機能的な特徴を示している。図４に示されているように、無線リンク制御（ＲＬＣ）エンティティ５０は送信側（それは下位レベルの媒体アクセス制御（ＭＡＣ）レイヤにＲＬＣ  ＰＤＵを送信する）と受信側（それは下位レベルの媒体アクセス制御（ＭＡＣ）レイヤからＲＬＣ  ＰＤＵを受信する）の両方をもっている。送信側も受信側も両方ともＲＬＣ制御ロジック１０２により支配され管理される。
【００４３】
無線リンク制御（ＲＬＣ）エンティティ５０の送信側に関連した機能は図４の左側に示されている。線１０４は上位レイヤからサービスデータユニット（ＳＤＵ）を受信する無線リンク制御（ＲＬＣ）エンティティ５０の送信側を描いている。無線リンク制御（ＲＬＣ）エンティティ５０は上位レイヤ１０４（例えば、ＩＰレイヤ）からＳＤＵとして取得したパケットを扱う。ブロック１０６によって示唆されるように、ＳＤＵは分割されるか連結されるかの少なくともいずれかにより、固定長のプロトコルデータユニット（ＰＤＵ）を形成する。もし、いくつかのＳＤＵが１つのＰＤＵにフィットするなら、それらのＳＤＵは連結され、適切なレンクス・インディケータがそのＰＤＵの始まりに挿入される。
【００４４】
ブロック１０８により表されているように、ＲＬＣヘッダは各ＲＬＣ  ＰＤＵに対して生成される。本発明に従えば、無線リンク制御（ＲＬＣ）エンティティ５０は付加されたＲＬＣヘッダ制御１０８との関連で作用するポートマネージャ１１０をもっている。ＲＬＣ  ＰＤＵのヘッダ生成の後、ブロック１１４により示唆されるようにそれは再送バッファに置かれる。
【００４５】
無線リンク制御（ＲＬＣ）エンティティ５０の受信側はＭＡＣレイヤからの論理チャネルの適切なものを介してＲＬＣ  ＰＤＵを受信する。その受信側は、ブロック１３０により表現されたディマルチプレキシング（ＤＥＭＵＸ）／ルーティング機能を含む。ブロック１３２により復号化は実行される。ブロック１３４により示されているように、ＲＬＣヘッダは取り除かれ、ポテンシャル・ピギーバックのステータス情報が抽出される。ＰＤＵは完全なＳＤＵが受信されるまで共通受信機バッファ１３６に初期的には保持される。必要なとき、共通受信機バッファ１３６に関する制御要素が、否定確認応答を（線１４０により描かれた信号により）ピア無線リンク制御（ＲＬＣ）エンティティに送信することにより、ＡＭＤ  ＰＤＵの再送を要求する。ブロック１３４でＲＬＣ  ＰＤＵヘッダが除去され、そして、１つのＲＬＣ  ＰＤＵにより搬送されるようなＳＤＵの全てのセグメントが受信された後、完全になったＳＤＵが再組立ブロック１４２により再組立され、図４の線１６０により示されているように、上位レイヤに送信される。
【００４６】
従って、図４により表される機能は確立された各ＲＬＣエンティティに関して実行される。上述のように、複数の無線アクセスベアラ（ＲＡＢ）を用いるユーザ機器ユニットの場合には、複数のＲＬＣエンティティが確立されても良い。確立されたＲＬＣエンティティの数に係りなく、ＲＬＣエンティティは全て、ユーザ機器ユニット（ＵＥ）の同じメモリ割当てを共有しなければならない。図３はデータ処理制御ユニット３１からは分離した別個のものとしてＵＥメモリ１５０を図示しているが、メモリ１５０は、データ処理制御ユニット３１の一部となることも含めて種々の媒体と種々の方法により具体化される。ＵＥ参照クラス３８４ｋｂｐｓの場合、ＵＥは５０ｋバイトのメモリをもち、最大６個のＡＭ  ＲＬＣエンティティを受け入れる余裕がある。
【００４７】
結局のところ、受信と送信の両方についてのセットアップ時、各ＲＡＢはユーザ機器ユニット（ＵＥ）のメモリ１５０に１つの部分或いは“ウィンドウ”が与えられ、そして、各方向に関し、ある“ウィンドウサイズ”が関連するＲＡＢでもつようにされる。事実、ユーザ機器ユニット（ＵＥ）に、（１）全ＲＬＣ  ＡＭバッファサイズ、（２）ＡＭ  ＲＬＣエンティティの最大数、（３）ＲＬＣ  ＡＭの最大ウィンドウサイズを含む一定のＲＬＣ容量情報が備えられる。例えば、３ＧＰＰ  ＴＳ２５．３２２，Ｖ．６．０．０（２００３年１２月），第３世代パートナーシッププロジェクト、技術仕様、グループ無線アクセスネットワーク、ＲＬＣプロトコル仕様(リリース６）、セクション１０．３．３．３４（3GPP TS 25.322, V.6.0.0 (2003-12), 3rd Generation Partnership Project; Technical Specification Group Radio Access Network; RLC Protocol Specification (Release 6), Section 10.3.3.34）を参照されたい。例えば、各ＲＬＣエンティティに関し、ユーザ機器ユニット（ＵＥ）には、その送信側のウィンドウサイズを指定するパラメータConfigured_Tx_Window_Sizeと、その受信側のウィンドウサイズを指定するパラメータConfigured_Rx_Window_Sixeとが備えられる。
【００４８】
ＲＬＣエンティティに割当てられたユーザ機器ユニット（ＵＥ）のメモリ１５０の一部（例えば、５０ｋなど）を扱うために、各ＲＬＣエンティティについて、ＲＬＣ制御ロジックは“状態変数（state variable）”のセットを利用する。これらの状態変数は、３ＧＰＰ  ＴＳ２５．３２２，Ｖ．６．０．０（２００３年１２月），第３世代パートナーシッププロジェクト、技術仕様、グループ無線アクセスネットワーク、ＲＬＣプロトコル仕様(リリース６）、セクション９．４（3GPP TS 25.322, V.6.0.0 (2003-12), 3rd Generation Partnership Project; Technical Specification Group Radio Access Network; RLC Protocol Specification (Release 6), Section 9.4）で定義されている。フォーマットとして、これら状態変数の名称は、（１）文字“Ｖ”で始まり、（２）ＲＬＣエンティティの受信側に言及するときには２番目の文字は“Ｒ”となり、ＲＬＣエンティティの備え送信側に言及するときには２番目の文字は“Ｔ”となり、（３）括弧付の変数をもつ。便宜上、いくつかの関係のある状態変数を表１にリストする。
【００４９】
＜表１＞
ＲＬＣ状態変数
2006522560.tif 000003
【００５０】
上述のように、現在の標準は表面上、ＲＬＣエンティティについてのウィンドウサイズが再構成されるのを許してはいるが、ウィンドウサイズの再構成時に発生するある問題については言及していない。図５において、ＲＬＣウィンドウサイズの再構成の例が図示されており、そこではウィンドウサイズが１６から８に小さくされている。図５は、ＲＬＣエンティティの送信側で縮小されたＲＬＣウィンドウサイズを示すとともに、対応するピアＲＬＣエンティティの受信側におけるＲＬＣウィンドウサイズ縮小の２つの事例（事例ａと事例ｂ）とを示している。図５において、影の付けられたブロックは実際に送信された（送信機の場合）或いは受信された（受信機の場合）ＰＤＵに対応している。一方、影の付けられていないブロックはまだ送信されていない（送信機の場合）或いはまだ受信されていない（受信機の場合）ＰＤＵに対応している。
【００５１】
図５の事例（ａ）において、送信機ウィンドウと受信機ウィンドウとは同じシーケンス番号の範囲をカバーしている。これとは対照的に、図５の事例（ｂ）において受信機ウィンドウは、ＰＤＵ０とＰＤＵ１とを確認応答しているステータスメッセージがまだ送信されていないか或いは送信されたが空中インタフェースにより喪失したという事実のために、送信ウィンドウよりもさらに進んでいる。
【００５２】
図３と図４に図示されているように、ＲＬＣエンティティ５０と特にＵＥのＲＬＣエンティティ５０−ＵＥには都合よく、ＲＬＣ再構成動作中にＲＬＣウィンドウサイズを再構成する建設的で実際的な方法を提供するＲＬＣ再構成ロジック２００が備えられている。ＲＬＣ再構成ロジックにより、無線リンク制御エンティティ５０は、ＲＬＣ再構成中にそのように要求されると、（１）古い送信機バッファウィンドウよりも小さい送信機バッファウィンドウサイズをもつ新しい送信機バッファウィンドウを形成するための送信機バッファウィンドウのサイズと、（２）古い受信機バッファウィンドウよりも小さい受信機バッファウィンドウサイズをもつ新しい受信機バッファウィンドウを形成するための受信機バッファウィンドウとの内の少なくとも１つを再構成するように構成される。ＲＬＣ再構成ロジック２００は本質的に同時的に、送信機バッファウィンドウのサイズと受信機バッファウィンドウサイズの再構成を実施しても良いし、或いはこれら２つの再構成を異なる時に実施しても良い。
【００５３】
ＲＬＣ再構成ロジック２００は、ＲＬＣ制御ロジック１０２がデータ処理制御ユニットの一部か或いはそれとは別個のものであるなら、図３と図４に示された方法でＲＬＣ制御ロジック１０２の一部として実現されても良い。例えば、ＲＬＣ再構成ロジック２００はデータ処理制御ユニットを有する１つ以上のプロセッサにより実行される命令とデータの内の少なくともいずれかのセットを有することができる。或いは、ＲＬＣ再構成ロジック２００は、例えば、別個のプロセッサ、回路、コントローラ、或いはステートマシーンとして別々に実現されても良い。
【００５４】
ＵＥに関する第１の実施例／態様
第１の実施例と動作の態様において、無線リンク制御（ＲＬＣ）エンティティ５０−ＵＥはそのＲＬＣ再構成ロジック２００−ＵＥを介して、（Ａ）古い受信機バッファウィンドウ内にあるものとして受信されたが新しい受信機バッファウィンドウの外側にあるダウンリンクＲＬＣプロトコルデータユニット（ＰＤＵ）を破棄し、そして（Ｂ）無線リンク制御（ＲＬＣ）バッファメモリに無線アクセスネットワークによる受信が肯定的に確認応答されなかったアップリンクＲＬＣプロトコルデータユニット（ＰＤＵ）を保持する。
【００５５】
第１の実施例／態様に関する理論的解釈は、受信機側と送信機側の両方においてウィンドウを縮小する効果の検討に基づいている。受信機のウィンドウの縮小に関して、受信機のウィンドウが縮小されるとき、古い受信機ウィンドウにおいて受信されたＰＤＵのいくつかは最終的には新しい受信機ウィンドウの外側に置かれることになるかもしれない。第１の実施例においてメモリを解放するために、これらのＰＤＵはＵＥにおいて破棄され、受信されないものとして扱われる。このことは、ＵＴＲＡＮがこれらのＰＤＵを再構成後に再送する必要があることを意味している。しかし、これは性能にはほとんど影響を及ぼさないと考えられている。
【００５６】
送信機のウィンドウの縮小に関して、送信機のウィンドウが縮小されるとき、古い送信機ウィンドウにおいて送信されたＰＤＵのいくつかは最終的には新しい送信機ウィンドウの外側に置かれることになるかもしれない。メモリを解放するために送信機からこれらのＰＤＵを軽軽しく破棄することは、望まれない結果をもたらすことになる。
【００５７】
ＲＬＣエンティティの送信機側におけるそのような第１の結果は、永久的なデータ喪失である。もしこれらのＰＤＵが破棄されたなら、それらを再送信することができず、これは永久的なデータ喪失へとつながる。このことはもしかすると、無線ベアラ（ＲＢ)には受容可能であるかもしれないが、シグナリング無線ベアラ（ＳＲＢ）に対するウィンドウサイズを縮小することは不可能であることを意味する。無線ベアラ（ＲＢ）はユーザデータに対して用いられ、シグナリング無線ベアラ（ＳＲＢ）は制御データに対して用いられる。ＧＳＭからハンドオーバにおいて用いられるデフォルト構成に関して検討したように、デフォルト構成において用いられる値１２８からもっと小さな値へとウィンドウサイズを小さくしてメモリを解放できることは有益である。
【００５８】
送信機側におけるそのような第２の結果は、プロトコル動作における潜在的なエラーである。送信側におけるＰＤＵの破棄はプロトコルエラーにつながるかもしれない。上述した図５における事象（ｂ）を考慮する。もし、送信機が新しい送信機ウィンドウの外側にあるＰＤＵを破棄するなら、これはＰＤＵ８〜１５が破棄され、再送できないことを意味する。しかしながら、事象（ｂ）における受信機ウィンドウは送信機ウィンドウよりもさらに前に進められるために、ＳＮ＝８のＰＤＵは新しい受信機ウィンドウ内にある。もしこのＰＤＵが再送できないなら、ＲＬＣプロトコルは動かなくなる。
【００５９】
それ故に、第１の実施例では、肯定的に確認応答されない全てのＰＤＵはバッファに保持される。このことは、もし、ＵＴＲＡＮが再構成後、この例ではＰＤＵ８〜１５のいくつかを否定的に確認応答するなら、ＵＥはＰＤＵを再送するように準備されなければならないことを示唆している。
【００６０】
前に述べたことからすると、図６は特に第１の実施例と第１の態様に従うＲＬＣエンティティ５０−ＵＥとＲＬＣ再構成ロジック２００−ＵＥによりＲＬＣ再構成の動作中に実行される選択された基本的で代表的な動作を図示している。図６はＵＥのＲＬＣエンティティ５０−ＵＥの受信機側と送信機側の両方において実行される動作を示している。
【００６１】
動作６−１は、ＲＬＣ再構成の動作が必要であることの何らかの示唆が受信されたかどうかを判断するためのＲＬＣエンティティ５０−ＵＥのチェックを示している。ユーザ機器ユニット３０にとって、そのような示唆は、例えば、無線アクセスネットワークから受信されるメッセージによって提供される。もし、そのような示唆が受信されなかったなら、ＲＬＣエンティティ５０−ＵＥは（動作６−２により表されているように）以前に構成されたＲＬＣパラメータを用いて動作を続ける。しかしながら、動作６−３により表されているように、ＲＬＣ再構成動作が実行されるという示唆が受信されたなら、ＲＬＣエンティティ５０−ＵＥの受信機側と送信側の両方が再構成されたパラメータの利用を始める。
【００６２】
図６とここで説明された他の実施例と態様のＲＬＣ再構成動作において、ＲＬＣ再構成動作は、送信機バッファウィンドウの再構成（例えば、古い送信機バッファウィンドウよりも小さい送信機バッファウィンドウサイズをもつ新しい送信機バッファウィンドウを形成すること）と受信機バッファウィンドウの再構成（例えば、古い受信機バッファウィンドウよりも小さい受信機バッファウィンドウサイズをもつ新しい受信機バッファウィンドウを形成すること）とに関与すると仮定される。
【００６３】
受信機側では、動作６−Ｒ４のように、ＲＬＣ再構成ロジック２００−ＵＥは、受信したＲＬＣプロトコルデータユニット（ＰＤＵ）をチェックする。例えば、受信したＲＬＣプロトコルデータユニット（ＰＤＵ）のシーケンス番号或いは他のシーケンス／順序識別子をチェックする。動作６−Ｒ５のように、ＲＬＣ再構成ロジック２００−ＵＥは、今まで受信したＲＬＣプロトコルデータユニット（ＰＤＵ）のシリアル番号が新しい受信機バッファウィンドウの外側にあり、しかしまだ古い受信機バッファウィンドウの外側にあるかどうかを判断する。もし、動作６−Ｒ５の判断が既に受信した何らかのＰＤＵに関して肯定的なものであるなら、動作６−Ｒ６にあるように、否定的な確認応答なしに、その／それらのＰＤＵは破棄される。新しい受信機バッファウィンドウの内側にある受信ＰＤＵは必要なものとして確認応答され、動作６−Ｒ７のように処理される。動作６−Ｒ６の破棄或いは動作６−Ｒ７の処理の後、動作６−Ｒ１０のように、受信機ウィンドウは適切なものとして前に進められる。動作６−Ｒ１０におけるそのような前進には、例えば、状態変数ＶＲ（ＭＲ）とＶＲ（Ｈ）の更新に関与できる。受信機バッファウィンドウの前進に従って、受信機は、ＲＬＣプロトコルデータユニット（ＰＤＵ）はそれらが受信されたものとして処理を続行し、受信ＲＬＣプロトコルデータユニット（ＰＤＵ）を確認応答して処理し、さらにその送信が完了するまで受信機バッファウィンドウを進める。
【００６４】
送信機側では、再構成時、動作６−Ｔ４のように、状態変数ＶＴ（ＷＳ）は、ＵＥのＲＬＣエンティティ５０−ＵＥに備えられたConfigured_Tx_Window_Sizeの値にセットされる。動作６−Ｔ５のように、ＲＬＣ再構成ロジック２００は、たとえＰＤＵのシーケンス或いはシリアル番号がＶＴ（ＭＳ）より大きいものであったとしても、ＲＬＣ再構成動作のために送信機側が受信機バッファのどんなＰＤＵも破棄しないことを要求する。ＶＴ（ＭＳ）は最大送信状態変数であり、そして、そのようなものとして、ピア受信機により拒絶される第１のＡＭＤ  ＰＤＵの“シーケンス番号”、ＶＴ（ＭＳ）＝ＶＴ（Ａ）＋ＶＴ（ＭＳ）を含んでおり、従って、送信ウィンドウの上端を表していることが思い出されるであろう。その時、動作６−Ｔ６のように、送信機側はピアエンティティの受信機に新しい送信機バッファウィンドウにおけるＲＬＣプロトコルデータユニット（ＰＤＵ）を送信する。動作６−Ｔ７のように、送信機側はピア受信機エンティティから受信した確認応答を処理し、そのように処理された確認応答に従って必要であるならＰＤＵを再送し、そして、適切なものとして送信機バッファウィンドウを進める。
【００６５】
図６のＲＬＣ再構成動作の結果として、再構成されたＲＬＣエンティティに瞬間的に必要なＲＬＣバッファメモリは古いＲＬＣウィンドウが示唆するのと同じ大きさにできる。このことはもしかすると、全てのＲＬＣエンティティに関して全ての入力するＳＤＵを分割するのに十分な自由に用いられるメモリがないことを意味するかもしれない。そのような場合、図６ＡのＲＬＣの再構成動作が図６のＲＬＣ再構成動作の変形例として利用される。図６ＡのＲＬＣ再構成動作において、ユーザ機器ユニット（ＵＥ）のメモリの容量（例えば、ＵＥメモリ１５０）を超えるなら、また超えるとき、ユーザ機器ユニット（ＵＥ）は上位レイヤから受信したＳＤＵを分割する必要はない。上位レイヤから受信したＳＤＵの分割を要求しないことにより、ＵＥにおける全ての送信機バッファに必要なメモリは、如何なるときでも再構成されたＲＬＣウィンドウをサポートするのに必要とされるより多くのメモリを必要とはしない。
【００６６】
図６のＲＬＣ再構成動作のそれに類似の図６ＡにおけるＲＬＣ再構成動作の基本的な動作には同様の番号が付されている。図６ＡのＲＬＣ再構成動作は、動作６−Ｒ８のように、ＲＬＣ再構成動作が原因となる何らかのメモリ制約があるかどうかをチェックするので本質的には図６のＲＬＣ再構成動作とは異なる。もしメモリ制約が存在するなら、動作６−Ｒ９のように、ＲＬＣ再構成ロジック２００はＳＤＵ分割放棄フラグをセットしてその後に続くＲＬＣ制御ロジック１０２が上位レイヤから受信したＳＤＵ分割の実行を要求されていないことを知るようにする。図６Ａには図示されてはいないが、メモリ制約が緩和されるとき、ＳＤＵ分割放棄フラグはクリアされ、ＳＤＵ分割の継続を許可する。
【００６７】
フロー制御のいくつかの形がまた、例えば、現存する３ＧＰＰ  ＴＳ  ＵＥ実施形においても存在し、上位レイヤのアプリケーションにこれらの状態においてデータを更にＲＬＣに提出することを防止しなければならないことが理解されるので、（例えば、ＲＬＣウィンドウがフルであるか、或いはＲＬＣエンティティが保留されているなどのため）データが送信できない時のＲＬＣと上位レイヤとの間の相互作用はここでは詳細に述べていない。
【００６８】
第１の実施例と第１の態様とは概して非常に利点が多いが、もし、順序正しい配信が構成されないなら、これは十分にうまく動作しないかもしれない。例えば、もし、図５の事象（ｂ）において、ＳＤＵがＰＤＵ１１〜１２に存在するなら、このＳＤＵは、ＲＬＣウィンドウサイズの縮小が生じたときには既に上位レイヤへと配信されているかもしれない。再構成後、これらのＰＤＵはピアエンティティにより再送され、その結果、ＳＤＵの写しが上位レイヤに配信される。古い送信機ウィンドウの外側にあるシーケンス番号をもったＰＤＵの再送もまた、付加的な遅延の原因となる。以下に説明する第２の実施例と第２の態様では、このことと他の検討内容を扱う。
【００６９】
ＵＥに関する第２の実施例／態様
いくつかの点に関して、第２の実施例と動作の態様とは第１の実施例／態様と比較してより緻密である。第２の実施例と動作の態様において、無線リンク制御（ＲＬＣ）エンティティはそのＲＬＣ再構成ロジック２００−ＵＥを介して、（Ａ）たとえ新しい受信機バッファの外側にあったとしても、受信機バッファウィンドウが進められるまで、受信機バッファに格納された全てのダウンリンクＲＬＣプロトコルデータユニット（ＰＤＵ）を保持し、（Ｂ）たとえ新しい送信機バッファの外側にあったとしても、送信機バッファに格納された全てのアップリンクＲＬＣプロトコルデータユニット（ＰＤＵ）を保持する。
【００７０】
前に述べたことからすると、図７は第２の実施例と第２の態様に従うＲＬＣエンティティ５０と特にＲＬＣ再構成ロジック２００−ＵＥによりＲＬＣ再構成の動作中に実行される選択された基本的で代表的な動作を図示している。図６の前のＲＬＣ再構成動作と同じような方法で、動作７−１のように、ＵＥのＲＬＣエンティティ５０−ＵＥは、ＲＬＣ再構成の動作が必要であることの何らかの示唆が受信されたかどうかを判断するためにチェックする。もし、そのような示唆が受信されなかったなら、ＵＥのＲＬＣエンティティ５０−ＵＥは（動作７−２により表されているように）以前に構成されたＲＬＣパラメータを用いて動作を続ける。しかしながら、動作７−３により表されているように、ＲＬＣ再構成動作が実行されるという示唆が受信されたなら、ＵＥのＲＬＣエンティティ５０−ＵＥの受信機側と送信側の両方が再構成されたパラメータの利用を始める。
【００７１】
第２の実施例／態様において、（例えば、ＲＬＣ再構成動作の一部として）受信機ウィンドウが縮小されるとき、受信機バッファの全てのＰＤＵは、たとえこれらのＰＤＵが新しい受信機バッファの外側にあったとしても、保持される（動作７−Ｒ４）。動作７−Ｒ５のように、受信機バッファウィンドウは正規の規則に従って（例えば、３ＧＰＰ  ＴＳ  ２５．３２２に記載のように）進められる。
【００７２】
同様に、第２の実施例／態様は、送信機ウィンドウサイズの縮小を扱う。即ち、送信機ウィンドウが縮小されるとき、送信機バッファの全てのＰＤＵは、これらのＰＤＵがたとえ新しい送信機バッファの外側にあったとしても、保持される（動作７−Ｔ４）。動作７−Ｔ５のように、送信機バッファウィンドウは正規の規則に従って（例えば、３ＧＰＰ  ＴＳ  ２５．３２２に記載のように）進められる。
【００７３】
全てのＰＤＵは第２の実施例／態様に従えば、再構成時にはＲＬＣバッファに保持されるのであるから、新しいＲＡＢにおいて送信或いは受信の少なくともいずれかがなされたＰＤＵは一時的にＵＥのＲＬＣバッファ１５０の能力或いは容量を超えてしまう原因となることがありえる。従って、図７ＡのＲＬＣ再構成動作は図７のＲＬＣ再構成動作の変形であり、ＵＥバッファメモリは再構成後始めて全てのＡＭＤ  ＰＤＵを処理するのに十分ではないかもしれない可能性を扱うために代替的に実現される。
【００７４】
以下に扱う例の方法で説明するように、図７ＡのＲＬＣ再構成動作はオプション的には、無線リンク制御（ＲＬＣ）バッファメモリについての重い容量負担についてのチェックを実行する。重い容量負担がある場合、ＲＬＣエンティティはオプション的に保護対策を実行する。
【００７５】
図７ＡのＲＬＣ再構成動作の多くは図７のＲＬＣ再構成動作のそれと共通であり、それ故に、もう一度検討することはしない。図７ＡのＲＬＣ再構成動作は、上位レイヤから受信したＳＤＵが処理されるか、或いは受信したＡＭＤ  ＰＤＵが格納される前に、ＲＬＣバッファメモリが一定のＰＤＵを格納するのに十分かどうかをチェックするので、基本的には図７のＲＬＣ再構成動作とは異なる。
【００７６】
第１のメモリ容量チェックの例として、無線リンク制御エンティティは、上位レイヤからのサービスデータユニット（ＳＤＵ）の受信が無線リンク制御（ＲＬＣ）バッファメモリの容量を超えたかどうかをチェックでき、そして、（もしそうであるなら）ＳＤＵを処理しないことを決定する。送信側では、図７ＡのＲＬＣ再構成動作は、さらに、動作７−Ｔ６、動作７−Ｔ７、動作７−Ｔ８、動作７−Ｔ９、及び動作７−Ｔ１０を含んでいるので、基本的には図７のＲＬＣ再構成動作とは異なる。動作７−Ｔ６は上位レイヤからＳＤＵを受信する送信側を示しており、これに動作７−Ｔ７が続く。そこでは、ＲＬＣ再構成ロジック２００が動作７−Ｔ６で受信したＳＤＵの容量がＵＥメモリ１５０における過度の割当ての原因となるかどうかをチェックする。
【００７７】
特に、動作７−Ｔ７のように、ＲＬＣ再構成ロジック２００はＲＬＣバッファメモリが全てのＲＬＣ  ＡＭエンティティに関して、インターバル［ＶＴ（Ａ）＜ＳＮ＜ＶＴ（Ｓ）］という条件でＳＮをもつＡＭＤ  ＰＤＵを処理するのに十分であるかどうかをチェックする。この第１のメモリ容量チェックの例において、ＳＮはＰＤＵのシーケンス番号、ＶＴ（Ａ）は最新の順序正しく確認応答されたＡＭＤ  ＰＤＵに続くシーケンス番号、そして、ＶＴ（Ｓ）は始めて送信されることになる次のＡＭＤ  ＰＤＵについてのシーケンス番号である。
【００７８】
動作７−Ｔ７において、上位レイヤから受信されたＳＤＵの処理が、シグナリングされたＵＥ能力に従ったＵＥバッファメモリの過度の割当てに導くものであると判断されたなら、ＳＤＵは（動作７−Ｔ８によって表されているように）処理されない。さもなければ、動作７−Ｔ６において考えられたＳＤＵが、動作７−Ｔ９のように処理される。それから、動作７−Ｔ８或いは動作７−Ｔ９の後、動作７−Ｔ１０のように送信機側ではこの時点で適切であるかもしれない何らかの確認応答を処理し、ＰＤＵをそのピアＲＬＣエンティティに（例えば、ＲＡＮにおいて）再送し、送信機バッファウィンドウを適切なものとして前に進めるというようなルーティン的な事柄を実行する。
【００７９】
図７ＡのＲＬＣ再構成動作は、これによってＵＥが常に全てのＲＬＣ  ＡＭエンティティに関して、インターバル［ＶＲ（Ｒ）＜ＳＮ＜ＶＲ（Ｈ）］という条件でＳＮをもつＡＭＤ  ＰＤＵを受信することができる（即ち、再送信）機構を提供する。それは、潜在的なデッドロックの状態を防止するために必要とされる。もし、このことが保証されないなら、ＵＥは全ての受信ＰＤＵを無視することがあり得、そして、動作不能になる状態から逃れることができない。
【００８０】
図７ＡのＲＬＣ再構成動作の第２のメモリ容量チェックの例として、無線リンク制御エンティティは無線アクセスネットワークからのプロトコルデータユニット（ＰＤＵ）の受信が無線リンク制御（ＲＬＣ）バッファメモリの容量を越えているかどうかをチェックでき、（もしそうであるなら）そのＰＤＵを無視することを決定する。このことは主として受信機側で成し遂げられ、そこでは図７ＡのＲＬＣ再構成動作は、さらに、動作７−Ｒ６、動作７−Ｒ７、動作７−Ｒ８、動作７−Ｒ９、及び動作７−Ｒ１０を含んでいるので、基本的には図７のＲＬＣ再構成動作とは異なる。動作７−Ｒ６はＰＤＵを受信する受信機側を示している。動作７−Ｒ７のように、図７ＡのＲＬＣ再構成ロジック２００の実施例が動作７−Ｒ６で受信したＰＤＵの格納がＵＥメモリ１５０における過度の割当ての原因となるかどうかをチェックする。
【００８１】
特に、動作７−Ｒ７のように、ＲＬＣ再構成ロジック２００はＲＬＣバッファメモリが全てのＲＬＣ  ＡＭエンティティに関して、インターバル［ＶＲ（Ｒ）＜ＳＮ＜ＶＲ（Ｈ）］という条件でシーケンスバッファ（ＳＮ）をもつＡＭＤ  ＰＤＵを格納するのに十分であるかどうかをチェックする。このメモリ容量チェックにおいて、ＳＮはＰＤＵのシーケンス番号、ＶＲ（Ｒ）は最新の順序正しく受信されたＡＭＤ  ＰＤＵに続くシーケンス番号、そして、ＶＴ（Ｈ）は受信されたＡＭＤ  ＰＤＵの最大シーケンス番号に続くシーケンス番号である。
【００８２】
動作７−Ｒ７のようにチェックされたバッファメモリが十分ではないなら、動作７−Ｒ８のように、それらのＰＤＵは（確認応答を生成することなく）無視される。（動作７−Ｒ８のチェックは、受信されたＰＤＵのＳＮがＶＲ（Ｈ）が増加する原因となるなら、実行される必要があるだけである）。
【００８３】
さもなければ、動作７−Ｒ８が実行されないなら、動作７−Ｒ９のように、受信されたＲＬＣプロトコルデータユニット（ＰＤＵ）が処理される。それから、動作７−Ｒ９或いは動作７−Ｒ８の後、（他のＰＤＵに関してだけなら）動作７−Ｔ１０のように受信機側では何らかの必要な確認応答を生成し、受信機バッファウィンドウを適切なものとして前に進める。
【００８４】
このように、ユーザ機器ユニットに関して、構成されたＲＬＣウィンドウサイズの縮小を扱う２つの実施例／態様を説明した。第１の実施例／態様は簡単ではあるが、順序正しく配信がなされるときのみに作用する。第１の実施例／態様はまた、再構成後に新しいＲＬＣウィンドウの外側にあるＰＤＵが再送されることを必要としており、これはユーザデータについての大きな遅延を意味する。第２の実施例／態様はより進んだメモリの処理を必要とするが、順序正しく配信がなされない場合を扱い、再構成後のＰＤＵの再送を回避している。
【００８５】
ネットワークノードに関する実施例
ネットワークノードに関し、図８はＲＬＣエンティティ５０−ＲＡＮと特にＲＬＣ再構成ロジック２００−ＲＡＮにより、ＲＬＣ再構成の動作中に実行される選択された基本的で代表的な動作を図示している。図８はＲＬＣエンティティ５０−ＲＡＮの送信側と受信側の両方で実行される動作を示している。
【００８６】
動作８−１は、ＲＬＣ再構成の動作が必要であることの何らかの示唆が受信されたかどうかを判断するためのＲＬＣエンティティ５０−ＲＡＮのチェックを示している。もし、そのような示唆が受信されなかったなら、ＲＬＣエンティティ５０−ＲＡＮは（動作８−２により表されているように）以前に構成されたＲＬＣパラメータを用いて動作を続ける。しかしながら、動作８−３により表されているように、ＲＬＣ再構成動作が実行されるという示唆が受信されたなら、ＲＬＣエンティティ５０−ＲＡＮの受信機側と送信機側の両方が再構成されたパラメータの利用を始める。
【００８７】
図８とここで説明された他の実施例と態様のＲＬＣ再構成動作において、ＲＬＣ再構成動作は送信機バッファウィンドウの再構成（例えば、古い送信機バッファウィンドウよりも小さい送信機バッファウィンドウサイズをもつ新しい送信機バッファウィンドウを形成すること）と受信機バッファウィンドウの再構成（例えば、古い受信機バッファウィンドウよりも小さい受信機バッファウィンドウサイズをもつ新しい受信機バッファウィンドウを形成すること）とに関与すると仮定される。以前に示唆されたように、送信機バッファウィンドウと受信機バッファウィンドウの再構成は同時に実行されても良いし、或いは別の時間に実行されても良い。いずれにしても、図８に図示したことは例示である。
【００８８】
受信機側では、動作８−Ｒ４のように、ＲＬＣ再構成ロジック２００−ＲＡＮは再構成において、ダウンリンクにおける全てのＰＤＵを保持する。同様に、送信機側では、再構成時、動作８−Ｔ４のように、アップリンクにおける全てのＰＤＵもまた保持される。なぜなら、ユーザ機器ユニット３０は再構成時アップリンクデータを破棄するかもしれないし、そうではないかもしれないからである。
【００８９】
本発明を最も実際的で好適な実施例であると現在考えられているものに関連して説明したが、本発明は開示された実施例によって限定されるものではなく、それとは反対に添付した請求の範囲の精神と範囲の中に含まれる種々の変形例や同等の構成を含むことが意図されていることを理解すべきである。
【図面の簡単な説明】
【００９０】
【図１】通信レイヤモデルを図式的に示したものであり、特に、上位レイヤと媒体アクセスレイヤ（ＭＡＣ）との間に置かれた２つの無線リンク制御（ＲＬＣ）エンティティをもつ無線リンク制御レイヤを示す図である。
【図２】本発明が都合よく採用される移動体通信システムの例を示す図である。
【図３】ユーザ機器ユニット（ＵＥ）局、無線ネットワーク制御局、及び基地局を含むＵＭＴＳ地上無線アクセス網の一部を示す単純化された機能ブロック図である。
【図４】無線リンク制御（ＲＬＣ）エンティティの例を一部は図形的に一部は模式的に示す図である。
【図５】送信機に関するＲＬＣウィンドウサイズの再構成と受信機に対するＲＬＣウィンドウサイズの２つの場合を示す図である。
【図６】第１の実施例と第１の態様に従うＵＥ  ＲＬＣエンティティによりＲＬＣ再構成の動作中に実行される選択された基本的で代表的な動作を示すフローチャートである。
【図６Ａ】ＵＥ  ＲＬＣエンティティにより図６のＲＬＣ再構成の変形例が動作中に実行される選択された基本的で代表的な動作を示すフローチャートである。
【図７】第２の実施例と第２の態様に従うＵＥ  ＲＬＣエンティティによりＲＬＣ再構成の動作中に実行される選択された基本的で代表的な動作を示すフローチャートである。
【図７Ａ】ＵＥ  ＲＬＣエンティティにより図７のＲＬＣ再構成の変形例が動作中に実行される選択された基本的で代表的な動作を示すフローチャートである。
【図８】ネットワークノード（ＲＡＮ）のＲＬＣエンティティによりＲＬＣ再構成の動作中に実行される選択された基本的で代表的な動作を示すフローチャートである。
【図１】
2006522560.tif 000004
【図２】
2006522560.tif 000005
【図３】
2006522560.tif 000006
【図４】
2006522560.tif 000007
【図５】
2006522560.tif 000008
【図６】
2006522560.tif 000009
【図６Ａ】
2006522560.tif 000010
【図７】
2006522560.tif 000011
【図７Ａ】
2006522560.tif 000012
【図８】
2006522560.tif 000013
【国際調査報告】
2006522560.tif 000014
2006522560.tif 000015