(57)【特許請求の範囲】
【請求項１】
無線基地局によって送信された下りデータを受信するように構成されている受信部と、
前記無線基地局に対して、所定トリガに応じて、前記受信部によって受信された前記下りデータの受信結果について示すステータスレポートを送信するように構成されている送信部とを具備しており、
前記送信部は、前記ステータスレポートの送信を禁止する期間を規定するタイマが起動されている場合であっても、送信すべき上りデータを収容するトランスポートブロックにおいて該ステータスレポートを収容することができる余剰リソースが存在する場合には、該ステータスレポートを送信するように構成されていることを特徴とする移動局。
【請求項２】
無線基地局によって送信された下りデータを受信するように構成されている受信部と、
前記無線基地局に対して、所定トリガに応じて、または所定条件に応じて、前記受信部によって受信された前記下りデータの受信結果について示すステータスレポートを送信するように構成されている送信部とを具備しており、
前記送信部は、前記所定条件として、前記ステータスレポートの送信トリガを検出していない場合であっても、送信すべき上りデータを収容するトランスポートブロックにおいて該ステータスレポートを収容することができる余剰リソースが存在する場合には、該ステータスレポートを送信するように構成されていることを特徴とする移動局。
【請求項３】
移動局によって送信された上りデータを受信するように構成されている受信部と、
前記移動局に対して、所定トリガに応じて、前記受信部によって受信された前記上りデータの受信結果について示すステータスレポートを送信するように構成されている送信部とを具備しており、
前記送信部は、前記ステータスレポートの送信を禁止する期間を規定するタイマが起動されている場合であっても、送信すべき下りデータを収容するトランスポートブロックにおいて該ステータスレポートを収容することができる余剰リソースが存在する場合には、該ステータスレポートを送信するように構成されていることを特徴とする無線基地局。
【請求項４】
移動局によって送信された上りデータを受信するように構成されている受信部と、
前記移動局に対して、所定トリガに応じて、または所定条件に応じて、前記受信部によって受信された前記上りデータの受信結果について示すステータスレポートを送信するように構成されている送信部とを具備しており、
前記送信部は、前記所定条件として、前記ステータスレポートの送信トリガを検出していない場合であっても、送信すべき下りデータを収容するトランスポートブロックにおいて該ステータスレポートを収容することができる余剰リソースが存在する場合には、該ステータスレポートを送信するように構成されていることを特徴とする無線基地局。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、移動局及び無線基地局に関する。
【背景技術】
【０００２】
ＬＴＥ（Ｌｏｎｇ  Ｔｅｒｍ  Ｅｖｏｌｕｔｉｏｎ）-Ａｄｖａｎｃｅｄ方式では、移動局ＵＥ及び無線基地局ｅＮＢにおいて、ＲＬＣ（Ｒａｄｉｏ  Ｌｅｎｋ  Ｃｏｎｔｒｏｌ）レイヤ及びＭＡＣ（Ｍｅｄｉａ  Ａｃｃｅｓｓ  Ｃｏｎｔｒｏｌ）が設けられている。
【０００３】
送信側のＲＬＣレイヤ及び受信側のＲＬＣレイヤにおいて、順序制御や重複制御を提供するために、ウィンドウ（ｗｉｎｄｏｗ）制御を行っている。
【０００４】
図５に示すように、送信側のＲＬＣレイヤでは、送信する新規のＲＬＣ-ＰＤＵ（Ｐｒｏｔｏｃｏｌ  Ｄａｔａ  Ｕｎｉｔ）に対してシーケンス番号（ＳＮ：Ｓｅｑｕｅｎｃｅ  Ｎｕｍｂｅｒ）を付与し、受信側のＲＬＣレイヤからの「Ｓｔａｔｕｓ  Ｒｅｐｏｒｔ（ＡＣＫ/ＮＡＣＫ）」に基づいて、「Ｔｘ  ｗｉｎｄｏｗ（送信ウィンドウ）」を更新する。
【０００５】
一方、図５に示すように、受信側のＲＬＣレイヤでは、シーケンス番号順にＲＬＣ-ＰＤＵを受信できた場合に、「Ｒｘ  ｗｉｎｄｏｗ（受信ウィンドウ）」を更新する。
【０００６】
また、図６に示すように、送信側のＲＬＣレイヤが、受信側のＲＬＣレイヤからの「Ｓｔａｔｕｓ  Ｒｅｐｏｒｔ」を受信できない場合には、「Ｔｘ  ｗｉｎｄｏｗ」を更新することができず、「Ｔｘ  ｗｉｎｄｏｗ  ｓｔａｌｌｉｎｇ」が発生し、新規のＲＬＣ-ＰＤＵを送信することができなくなるため、受信側のＲＬＣレイヤは、適切な頻度で、送信側のＲＬＣレイヤに対して、「Ｓｔａｔｕｓ  Ｒｅｐｏｒｔ」を送信する必要がある。
【０００７】
なお、受信側のＲＬＣレイヤは、定期的に、或いは、下りデータの最後等のイベント発生時に、送信側のＲＬＣレイヤから、フィードバック要求を受信した場合に、送信側のＲＬＣレイヤに対して、「Ｓｔａｔｕｓ  Ｒｅｐｏｒｔ」を送信するように構成されている。
【０００８】
また、受信側のＲＬＣレイヤは、受信したＲＬＣ-ＰＤＵにおいて、シーケンス番号の抜けを検出した場合に、送信側のＲＬＣレイヤに対して、「Ｓｔａｔｕｓ  Ｒｅｐｏｒｔ」を送信するように構成されている。
【０００９】
ここで、受信側のＲＬＣレイヤは、上述のような「Ｓｔａｔｕｓ  Ｒｅｐｏｒｔ」の送信トリガを検出した場合であっても、図５及び図６に示すように、「ＰｒｏｈｉｂｉｔＴｉｍｅｒ」が起動している場合には、「Ｓｔａｔｕｓ  Ｒｅｐｏｒｔ」を送信しないように構成されている。図７に、かかる受信側のＲＬＣレイヤの動作の一例について示す。
【００１０】
かかる「ＰｒｏｈｉｂｉｔＴｉｍｅｒ」は、「Ｓｔａｔｕｓ  Ｒｅｐｏｒｔ」の頻繁な送信によるオーバーヘッドを低減するために設けられているタイマである。
【００１１】
また、図８に示すように、送信側のＭＡＣレイヤは、ＲＬＣレイヤから受信したデータ（ＲＬＣ-ＰＤＵ）を物理信号（Ｔｒａｎｓｐｏｒｔ  ｂｌｏｃｋ）にマッピングするように構成されている。
【００１２】
具体的には、送信側のＭＡＣレイヤは、優先度の高いデータ（ＲＬＣ-ＰＤＵ）から送信されるように、所定の優先度に基づいて、上述のマッピングを行うように構成されている。
【００１３】
また、図８に示すように、送信側のＭＡＣレイヤは、マッピングすべきデータ（ＲＬＣ-ＰＤＵ）が枯渇した場合には、Ｐａｄｄｉｎｇ処理を行うように構成されている。
【先行技術文献】
【非特許文献】
【００１４】
【非特許文献１】３ＧＰＰ  ＴＳ３６.３２１
【非特許文献２】３ＧＰＰ  ＴＳ３６.３２２
【発明の概要】
【発明が解決しようとする課題】
【００１５】
上述のように、ＲＬＣレイヤでは、オーバーヘッドが懸念されない限り、頻繁に「Ｓｔａｔｕｓ  Ｒｅｐｏｒｔ」を送受信して、送信側のＲＬＣレイヤが、「Ｔｘ  ｗｉｎｄｏｗ」を更新することで、「Ｔｘ  ｗｉｎｄｏｗ  ｓｔａｌｌｉｎｇ」の発生確率を低減することが望ましい。
【００１６】
しかしながら、現在のＬＴＥ-Ａｄｖａｎｃｅｄ方式では、送信側のＭＡＣレイヤにおいて、Ｐａｄｄｉｎｇ処理が行われる程、リソースが余っている場合であっても、送信側のＲＬＣレイヤは、「Ｓｔａｔｕｓ  Ｒｅｐｏｒｔ」の送信トリガを検出しない限り、「Ｓｔａｔｕｓ  Ｒｅｐｏｒｔ」を送信することができず、リソースを有効に活用することができないという問題点があった。
【００１７】
また、現在のＬＴＥ-Ａｄｖａｎｃｅｄ方式では、送信側のＲＬＣレイヤは、送信側のＭＡＣレイヤにおいて、Ｐａｄｄｉｎｇ処理が行われる程、リソースが余っている場合で、かつ、「Ｓｔａｔｕｓ  Ｒｅｐｏｒｔ」の送信トリガを検出した場合であっても、「ＰｒｏｈｉｂｉｔＴｉｍｅｒ」が起動している場合には、「Ｓｔａｔｕｓ  Ｒｅｐｏｒｔ」を送信することができず、やはりリソースを有効に活用することができないという問題点があった。
【００１８】
そこで、本発明は、上述の課題に鑑みてなされたものであり、リソースを有効活用して、「Ｔｘ  ｗｉｎｄｏｗ  ｓｔａｌｌｉｎｇ」の発生確率を低減することができる移動局及び無線基地局を提供することを目的とする。
【課題を解決するための手段】
【００１９】
本発明の第１の特徴は、移動局であって、無線基地局によって送信された下りデータを受信するように構成されている受信部と、前記無線基地局に対して、所定トリガに応じて、前記受信部によって受信された前記下りデータの受信結果について示すステータスレポートを送信するように構成されている送信部とを具備しており、前記送信部は、前記ステータスレポートの送信を禁止する期間を規定するタイマが起動されている場合であっても、送信すべき上りデータを収容するトランスポートブロックにおいて該ステータスレポートを収容することができる余剰リソースが存在する場合には、該ステータスレポートを送信するように構成されていることを要旨とする。
【００２０】
本発明の第２の特徴は、移動局であって、無線基地局によって送信された下りデータを受信するように構成されている受信部と、前記無線基地局に対して、所定トリガに応じて、前記受信部によって受信された前記下りデータの受信結果について示すステータスレポートを送信するように構成されている送信部とを具備しており、前記送信部は、前記ステータスレポートの送信トリガを検出していない場合であっても、送信すべき上りデータを収容するトランスポートブロックにおいて該ステータスレポートを収容することができる余剰リソースが存在する場合には、該ステータスレポートを送信するように構成されていることを要旨とする。
【００２１】
本発明の第３の特徴は、無線基地局であって、移動局によって送信された上りデータを受信するように構成されている受信部と、前記移動局に対して、所定トリガに応じて、前記受信部によって受信された前記上りデータの受信結果について示すステータスレポートを送信するように構成されている送信部とを具備しており、前記送信部は、前記ステータスレポートの送信を禁止する期間を規定するタイマが起動されている場合であっても、送信すべき下りデータを収容するトランスポートブロックにおいて該ステータスレポートを収容することができる余剰リソースが存在する場合には、該ステータスレポートを送信するように構成されていることを要旨とする。
【００２２】
本発明の第４の特徴は、無線基地局であって、移動局によって送信された上りデータを受信するように構成されている受信部と、前記移動局に対して、所定トリガに応じて、前記受信部によって受信された前記上りデータの受信結果について示すステータスレポートを送信するように構成されている送信部とを具備しており、前記送信部は、前記ステータスレポートの送信トリガを検出していない場合であっても、送信すべき下りデータを収容するトランスポートブロックにおいて該ステータスレポートを収容することができる余剰リソースが存在する場合には、該ステータスレポートを送信するように構成されていることを要旨とする。
【発明の効果】
【００２３】
以上説明したように、本発明によれば、リソースを有効活用して、「Ｔｘ  ｗｉｎｄｏｗ  ｓｔａｌｌｉｎｇ」の発生確率を低減することができる移動局及び無線基地局を提供することができる。
【図面の簡単な説明】
【００２４】
【図１】本発明の第１の実施形態に係る移動通信システムを構成する移動局及び無線基地局のプロトコルスタックを示す図である。
【図２】本発明の第１の実施形態に係る移動局の機能ブロック図である。
【図３】本発明の第１の実施形態に係る移動通信システムの動作を説明するための図である。
【図４】本発明の第１の実施形態に係る移動局の動作を示すフローチャートである。
【図５】従来の移動通信システムについて説明するための図である。
【図６】従来の移動通信システムについて説明するための図である。
【図７】従来の移動通信システムについて説明するための図である。
【図８】従来の移動通信システムについて説明するための図である。
【発明を実施するための形態】
【００２５】
（本発明の第１の実施形態に係る移動通信システム）
図１乃至図４を参照して、本発明の第１の実施形態に係る移動通信システムについて説明する。
【００２６】
本実施形態に係る移動通信システムとして、ＬＴＥ-Ａｄｖａｎｃｅｄ方式の移動通信システムを例に挙げて説明するが、本発明は、かかる移動通信システムに限定されず、他の方式の移動通信システムにも適用可能である。
【００２７】
図１に示すように、本実施形態に係る移動局ＵＥ及び無線基地局ｅＮＢには、物理（ＰＨＹ）レイヤや、ＭＡＣレイヤや、ＰＬＣレイヤや、ＰＤＣＰ（Ｐａｃｋｅｔ  Ｄａｔａ  Ｃｏｎｖｅｒｇｅｎｃｅ  Ｐｒｏｔｏｃｏｌ）レイヤや、ＲＲＣ（Ｒａｄｉｏ  Ｒｅｓｏｕｒｃｅ  Ｃｏｎｔｒｏｌ）レイヤが設けられている。
【００２８】
図２に示すように、本実施形態に係る移動局ＵＥは、受信部１１と、管理部１２と、送信部１３とを具備している。
【００２９】
受信部１１は、ＲＬＣレイヤにおいて、無線基地局ｅＮＢによって送信されたＲＬＣ-ＰＤＵ（下りデータ）を受信するように構成されている。
【００３０】
管理部１２は、「ＰｒｏｈｉｂｉｔＴｉｍｅｒ」が起動しているか否かについて管理するように構成されている。
【００３１】
送信部１３は、ＲＬＣレイヤにおいて、無線基地局ｅＮＢに対して、ＲＬＣ-ＰＤＵ（上りデータ）を送信するように構成されている。
【００３２】
原則として、送信部１３は、ＲＬＣレイヤにおいて、「Ｓｔａｔｕｓ  Ｒｅｐｏｒｔ」の送信トリガに応じて、すなわち、「Ｓｔａｔｕｓ  Ｒｅｐｏｒｔ」の送信トリガを検出した場合に、無線基地局ｅＮＢに対して、受信部１１によって受信されたＲＬＣ-ＰＤＵの受信結果（ＡＣＫ/ＮＡＣＫ）について示す「Ｓｔａｔｕｓ  Ｒｅｐｏｒｔ」を送信するように構成されている。
【００３３】
そして、送信部１３は、「ＰｒｏｈｉｂｉｔＴｉｍｅｒ」が起動されている場合には、「Ｓｔａｔｕｓ  Ｒｅｐｏｒｔ」の送信トリガを検出した場合であっても、無線基地局ｅＮＢに対して、かかる「Ｓｔａｔｕｓ  Ｒｅｐｏｒｔ」を送信しないように構成されている。
【００３４】
しかしながら、送信部１３は、「ＰｒｏｈｉｂｉｔＴｉｍｅｒ」が起動されている場合であっても、送信すべきＲＬＣ-ＰＤＵを収容する物理信号（Ｔｒａｎｓｐｏｒｔ  ｂｌｏｃｋ）において「Ｓｔａｔｕｓ  Ｒｅｐｏｒｔ」を収容することができる余剰リソースが存在する場合には、図３に示すように、ＲＬＣレイヤにおいて、無線基地局ｅＮＢに対して、「Ｓｔａｔｕｓ  Ｒｅｐｏｒｔ」を送信するように構成されていてもよい。
【００３５】
或いは、送信部１３は、「Ｓｔａｔｕｓ  Ｒｅｐｏｒｔ」の送信トリガを検出していない場合であっても、送信すべきＲＬＣ-ＰＤＵを収容する物理信号（Ｔｒａｎｓｐｏｒｔ  ｂｌｏｃｋ）において「Ｓｔａｔｕｓ  Ｒｅｐｏｒｔ」を収容することができる余剰リソースが存在する場合には（「ＰｒｏｈｉｂｉｔＴｉｍｅｒ」が起動されているか否かに関わらず）、図３に示すように、ＲＬＣレイヤにおいて、無線基地局ｅＮＢに対して、「Ｓｔａｔｕｓ  Ｒｅｐｏｒｔ」を送信するように構成されていてもよい。
【００３６】
ここで、ＭＡＣレイヤにおいて、「Ｓｔａｔｕｓ  Ｒｅｐｏｒｔ」は、物理信号（Ｔｒａｎｓｐｏｒｔ  ｂｌｏｃｋ）における余剰リソース（Ｐａｄｄｉｎｇデータを収容する予定であったリソース）に収容されることになる。
【００３７】
また、「Ｓｔａｔｕｓ  Ｒｅｐｏｒｔ」の送信トリガの１つとして、ＲＬＣレイヤの順序補正タイマの満了が存在するが、「Ｓｔａｔｕｓ  Ｒｅｐｏｒｔ」が送信された際には、かかる順序補正タイマを停止してもよい。
【００３８】
以下、図４を参照して、本実施形態に係る移動局ＵＥのＲＬＣレイヤの動作について説明する。
【００３９】
図４に示すように、移動局ＵＥのＲＬＣレイヤは、ステップＳ１０１において、「Ｓｔａｔｕｓ  Ｒｅｐｏｒｔ」の送信トリガを検出したか否かについて判定する。
【００４０】
「ＹＥＳ」の場合、本動作は、ステップＳ１０２に進み、「ＮＯ」の場合、本動作は、ステップＳ１０３に進む。
【００４１】
ステップＳ１０２において、移動局ＵＥのＲＬＣレイヤは、「ＰｒｏｈｉｂｉｔＴｉｍｅｒ」が起動しているか否かについて判定する。
【００４２】
「ＮＯ」の場合、本動作は、ステップＳ１０４に進み、「ＹＥＳ」の場合、本動作は、ステップＳ１０３に進む。
【００４３】
ステップＳ１０３において、移動局ＵＥのＲＬＣレイヤは、ＭＡＣレイヤにおいて行われるＰａｄｄｉｎｇ処理で用いられるＰａｄｄｉｎｇデータのサイズが「Ｓｔａｔｕｓ  Ｒｅｐｏｒｔ」のサイズよりも大きいか否かについて判定する。
【００４４】
「ＮＯ」の場合、本動作は、終了し、「ＹＥＳ」の場合、本動作は、ステップＳ１０４に進む。
【００４５】
ステップＳ１０４において、移動局ＵＥのＲＬＣレイヤは、無線基地局ｅＮＢのＲＬＣレイヤに対して、「Ｓｔａｔｕｓ  Ｒｅｐｏｒｔ」を送信する。
【００４６】
ステップＳ１０５において、移動局ＵＥのＲＬＣレイヤは、「ＰｒｏｈｉｂｉｔＴｉｍｅｒ」を再起動する。なお、ステップＳ１０５の処理は、省略されてもよい。
【００４７】
本実施形態に係る発明によれば、移動局ＵＥのＲＬＣレイヤは、「Ｓｔａｔｕｓ  Ｒｅｐｏｒｔ」の送信トリガを検出した場合に、「ＰｒｏｈｉｂｉｔＴｉｍｅｒ」が起動されている場合であっても、送信すべきＲＬＣ-ＰＤＵを収容する物理信号（Ｔｒａｎｓｐｏｒｔ  ｂｌｏｃｋ）において「Ｓｔａｔｕｓ  Ｒｅｐｏｒｔ」を収容することができる余剰リソースが存在する場合には、「Ｓｔａｔｕｓ  Ｒｅｐｏｒｔ」を送信するように構成されているため、リソースを有効活用して、「Ｓｔａｔｕｓ  Ｒｅｐｏｒｔ」の送受信を頻繁に行うことができ、「Ｔｘ  ｗｉｎｄｏｗ  ｓｔａｌｌｉｎｇ」の発生確率を低減することができる。
【００４８】
或いは、移動局ＵＥのＲＬＣレイヤは、「Ｓｔａｔｕｓ  Ｒｅｐｏｒｔ」の送信トリガを検出していない場合であっても、送信すべきＲＬＣ-ＰＤＵを収容する物理信号（Ｔｒａｎｓｐｏｒｔ  ｂｌｏｃｋ）において「Ｓｔａｔｕｓ  Ｒｅｐｏｒｔ」を収容することができる余剰リソースが存在する場合には（「ＰｒｏｈｉｂｉｔＴｉｍｅｒ」が起動されているか否かに関わらず）、「Ｓｔａｔｕｓ  Ｒｅｐｏｒｔ」を送信するように構成されているため、リソースを有効活用して、「Ｓｔａｔｕｓ  Ｒｅｐｏｒｔ」の送受信を頻繁に行うことができ、「Ｔｘ  ｗｉｎｄｏｗ  ｓｔａｌｌｉｎｇ」の発生確率を低減することができる。
【００４９】
（変更例１）
なお、上述の第１の実施形態における移動局ＵＥの機能と同一の機能は、無線基地局ｅＮＢにおいて具備されていてもよい。
【００５０】
具体的には、本変更例１では、図２に示すように、本実施形態に係る無線基地局ｅＮＢは、受信部１１と、管理部１２と、送信部１３とを具備している。
【００５１】
受信部１１は、ＲＬＣレイヤにおいて、移動局ＵＥによって送信されたＲＬＣ-ＰＤＵ（上りデータ）を受信するように構成されている。
【００５２】
管理部１２は、「ＰｒｏｈｉｂｉｔＴｉｍｅｒ」が起動しているか否かについて管理するように構成されている。
【００５３】
送信部１３は、ＲＬＣレイヤにおいて、移動局ＵＥに対して、ＲＬＣ-ＰＤＵ（下りデータ）を送信するように構成されている。
【００５４】
原則として、送信部１３は、ＲＬＣレイヤにおいて、「Ｓｔａｔｕｓ  Ｒｅｐｏｒｔ」の送信トリガに応じて、すなわち、「Ｓｔａｔｕｓ  Ｒｅｐｏｒｔ」の送信トリガを検出した場合に、移動局ＵＥに対して、受信部１１によって受信されたＲＬＣ-ＰＤＵの受信結果（ＡＣＫ/ＮＡＣＫ）について示す「Ｓｔａｔｕｓ  Ｒｅｐｏｒｔ」を送信するように構成されている。
【００５５】
そして、送信部１３は、「ＰｒｏｈｉｂｉｔＴｉｍｅｒ」が起動されている場合には、「Ｓｔａｔｕｓ  Ｒｅｐｏｒｔ」の送信トリガを検出した場合であっても、移動局ＵＥに対して、かかる「Ｓｔａｔｕｓ  Ｒｅｐｏｒｔ」を送信しないように構成されている。
【００５６】
しかしながら、送信部１３は、「ＰｒｏｈｉｂｉｔＴｉｍｅｒ」が起動されている場合であっても、送信すべきＲＬＣ-ＰＤＵを収容する物理信号（Ｔｒａｎｓｐｏｒｔ  ｂｌｏｃｋ）において「Ｓｔａｔｕｓ  Ｒｅｐｏｒｔ」を収容することができる余剰リソースが存在する場合には、図３に示すように、ＲＬＣレイヤにおいて、移動局ＵＥに対して、「Ｓｔａｔｕｓ  Ｒｅｐｏｒｔ」を送信するように構成されていてもよい。
【００５７】
或いは、送信部１３は、「Ｓｔａｔｕｓ  Ｒｅｐｏｒｔ」の送信トリガを検出していない場合であっても、送信すべきＲＬＣ-ＰＤＵを収容する物理信号（Ｔｒａｎｓｐｏｒｔ  ｂｌｏｃｋ）において「Ｓｔａｔｕｓ  Ｒｅｐｏｒｔ」を収容することができる余剰リソースが存在する場合には（「ＰｒｏｈｉｂｉｔＴｉｍｅｒ」が起動されているか否かに関わらず）、図３に示すように、ＲＬＣレイヤにおいて、移動局ＵＥに対して、「Ｓｔａｔｕｓ  Ｒｅｐｏｒｔ」を送信するように構成されていてもよい。
【００５８】
ここで、ＭＡＣレイヤにおいて、「Ｓｔａｔｕｓ  Ｒｅｐｏｒｔ」は、物理信号（Ｔｒａｎｓｐｏｒｔ  ｂｌｏｃｋ）における余剰リソース（Ｐａｄｄｉｎｇデータを収容する予定であったリソース）に収容されることになる。
【００５９】
また、「Ｓｔａｔｕｓ  Ｒｅｐｏｒｔ」の送信トリガの１つとして、ＲＬＣレイヤの順序補正タイマの満了が存在するが、「Ｓｔａｔｕｓ  Ｒｅｐｏｒｔ」が送信された際には、かかる順序補正タイマを停止してもよい。
【００６０】
以下、図４を参照して、本実施形態に係る無線基地局ｅＮＢのＲＬＣレイヤの動作について説明する。
【００６１】
図４に示すように、無線基地局ｅＮＢのＲＬＣレイヤは、ステップＳ１０１において、「Ｓｔａｔｕｓ  Ｒｅｐｏｒｔ」の送信トリガを検出したか否かについて判定する。
【００６２】
「ＹＥＳ」の場合、本動作は、ステップＳ１０２に進み、「ＮＯ」の場合、本動作は、ステップＳ１０３に進む。
【００６３】
ステップＳ１０２において、無線基地局ｅＮＢのＲＬＣレイヤは、「ＰｒｏｈｉｂｉｔＴｉｍｅｒ」が起動しているか否かについて判定する。
【００６４】
「ＮＯ」の場合、本動作は、ステップＳ１０４に進み、「ＹＥＳ」の場合、本動作は、ステップＳ１０３に進む。
【００６５】
ステップＳ１０３において、無線基地局ｅＮＢのＲＬＣレイヤは、ＭＡＣレイヤにおいて行われるＰａｄｄｉｎｇ処理で用いられるＰａｄｄｉｎｇデータのサイズが「Ｓｔａｔｕｓ  Ｒｅｐｏｒｔ」のサイズよりも大きいか否かについて判定する。
【００６６】
「ＮＯ」の場合、本動作は、終了し、「ＹＥＳ」の場合、本動作は、ステップＳ１０４に進む。
【００６７】
ステップＳ１０４において、無線基地局ｅＮＢのＲＬＣレイヤは、移動局ＵＥのＲＬＣレイヤに対して、「Ｓｔａｔｕｓ  Ｒｅｐｏｒｔ」を送信する。
【００６８】
ステップＳ１０５において、無線基地局ｅＮＢのＲＬＣレイヤは、「ＰｒｏｈｉｂｉｔＴｉｍｅｒ」を再起動する。なお、ステップＳ１０５の処理は、省略されてもよい。
【００６９】
本実施形態に係る発明によれば、無線基地局ｅＮＢのＲＬＣレイヤは、「Ｓｔａｔｕｓ  Ｒｅｐｏｒｔ」の送信トリガを検出した場合に、「ＰｒｏｈｉｂｉｔＴｉｍｅｒ」が起動されている場合であっても、送信すべきＲＬＣ-ＰＤＵを収容する物理信号（Ｔｒａｎｓｐｏｒｔ  ｂｌｏｃｋ）において「Ｓｔａｔｕｓ  Ｒｅｐｏｒｔ」を収容することができる余剰リソースが存在する場合には、「Ｓｔａｔｕｓ  Ｒｅｐｏｒｔ」を送信するように構成されているため、リソースを有効活用して、「Ｓｔａｔｕｓ  Ｒｅｐｏｒｔ」の送受信を頻繁に行うことができ、「Ｔｘ  ｗｉｎｄｏｗ  ｓｔａｌｌｉｎｇ」の発生確率を低減することができる。
【００７０】
或いは、無線基地局のＲＬＣレイヤは、「Ｓｔａｔｕｓ  Ｒｅｐｏｒｔ」の送信トリガを検出していない場合であっても、送信すべきＲＬＣ-ＰＤＵを収容する物理信号（Ｔｒａｎｓｐｏｒｔ  ｂｌｏｃｋ）において「Ｓｔａｔｕｓ  Ｒｅｐｏｒｔ」を収容することができる余剰リソースが存在する場合には（「ＰｒｏｈｉｂｉｔＴｉｍｅｒ」が起動されているか否かに関わらず）、「Ｓｔａｔｕｓ  Ｒｅｐｏｒｔ」を送信するように構成されているため、リソースを有効活用して、「Ｓｔａｔｕｓ  Ｒｅｐｏｒｔ」の送受信を頻繁に行うことができ、「Ｔｘ  ｗｉｎｄｏｗ  ｓｔａｌｌｉｎｇ」の発生確率を低減することができる。
【００７１】
以上に述べた本実施形態の特徴は、以下のように表現されていてもよい。
【００７２】
本実施形態の第１の特徴は、移動局ＵＥであって、無線基地局ｅＮＢによって送信されたＲＬＣ-ＰＤＵ（下りデータ）を受信するように構成されている受信部１１と、無線基地局ｅＮＢに対して、「Ｓｔａｔｕｓ  Ｒｅｐｏｒｔ」の送信トリガ（所定トリガ）に応じて、受信部１１によって受信されたＲＬＣ-ＰＤＵの受信結果について示す「Ｓｔａｔｕｓ  Ｒｅｐｏｒｔ（ステータスレポート）」を送信するように構成されている送信部１３とを具備しており、送信部１３は、「Ｓｔａｔｕｓ  Ｒｅｐｏｒｔ」の送信を禁止する期間を規定する「ＰｒｏｈｉｂｉｔＴｉｍｅｒ（タイマ）」が起動されている場合であっても、送信すべきＲＬＣ-ＰＤＵ（上りデータ）を収容するトランスポートブロックにおいて「Ｓｔａｔｕｓ  Ｒｅｐｏｒｔ」を収容することができる余剰リソースが存在する場合には、「Ｓｔａｔｕｓ  Ｒｅｐｏｒｔ」を送信するように構成されていることを要旨とする。
【００７３】
本実施形態の第２の特徴は、移動局ＵＥであって、無線基地局ｅＮＢによって送信されたＲＬＣ-ＰＤＵを受信するように構成されている受信部１１と、無線基地局ｅＮＢに対して、「Ｓｔａｔｕｓ  Ｒｅｐｏｒｔ」の送信トリガ（所定トリガ）に応じて、受信部１１によって受信されたＲＬＣ-ＰＤＵの受信結果について示す「Ｓｔａｔｕｓ  Ｒｅｐｏｒｔ」を送信するように構成されている送信部１３とを具備しており、送信部１３は、「Ｓｔａｔｕｓ  Ｒｅｐｏｒｔ」の送信トリガを検出していない場合であっても、送信すべきＲＬＣ-ＰＤＵを収容するトランスポートブロックにおいて「Ｓｔａｔｕｓ  Ｒｅｐｏｒｔ」を収容することができる余剰リソースが存在する場合には、「Ｓｔａｔｕｓ  Ｒｅｐｏｒｔ」を送信するように構成されていることを要旨とする。
【００７４】
本実施形態の第３の特徴は、無線基地局ｅＮＢであって、移動局ＵＥによって送信されたＲＬＣ-ＰＤＵを受信するように構成されている受信部１１と、移動局ＵＥに対して、「Ｓｔａｔｕｓ  Ｒｅｐｏｒｔ」の送信トリガ（所定トリガ）に応じて、受信部１１によって受信されたＲＬＣ-ＰＤＵの受信結果について示す「Ｓｔａｔｕｓ  Ｒｅｐｏｒｔ」を送信するように構成されている送信部１３とを具備しており、送信部１３は、「Ｓｔａｔｕｓ  Ｒｅｐｏｒｔ」の送信を禁止する期間を規定する「ＰｒｏｈｉｂｉｔＴｉｍｅｒ」が起動されている場合であっても、送信すべきＲＬＣ-ＰＤＵを収容するトランスポートブロックにおいて「Ｓｔａｔｕｓ  Ｒｅｐｏｒｔ」を収容することができる余剰リソースが存在する場合には、「Ｓｔａｔｕｓ  Ｒｅｐｏｒｔ」を送信するように構成されていることを要旨とする。
【００７５】
本実施形態の第４の特徴は、無線基地局ｅＮＢであって、移動局ＵＥによって送信されたＲＬＣ-ＰＤＵを受信するように構成されている受信部１１と、移動局ＵＥに対して、「Ｓｔａｔｕｓ  Ｒｅｐｏｒｔ」の送信トリガ（所定トリガ）に応じて、受信部１１によって受信されたＲＬＣ-ＰＤＵの受信結果について示す「Ｓｔａｔｕｓ  Ｒｅｐｏｒｔ」を送信するように構成されている送信部１３とを具備しており、送信部１３は、「Ｓｔａｔｕｓ  Ｒｅｐｏｒｔ」の送信トリガを検出していない場合であっても、送信すべきＲＬＣ-ＰＤＵを収容するトランスポートブロックにおいて「Ｓｔａｔｕｓ  Ｒｅｐｏｒｔ」を収容することができる余剰リソースが存在する場合には、「Ｓｔａｔｕｓ  Ｒｅｐｏｒｔ」を送信するように構成されていることを要旨とする。
【００７６】
なお、上述の移動局ＵＥや無線基地局ｅＮＢの動作は、ハードウェアによって実施されてもよいし、プロセッサによって実行されるソフトウェアモジュールによって実施されてもよいし、両者の組み合わせによって実施されてもよい。
【００７７】
ソフトウェアモジュールは、ＲＡＭ（Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙ）や、フラッシュメモリや、ＲＯＭ（Ｒｅａｄ  Ｏｎｌｙ  Ｍｅｍｏｒｙ）や、ＥＰＲＯＭ（Ｅｒａｓａｂｌｅ  Ｐｒｏｇｒａｍｍａｂｌｅ  ＲＯＭ）や、ＥＥＰＲＯＭ（Ｅｌｅｃｔｒｏｎｉｃａｌｌｙ  Ｅｒａｓａｂｌｅ  ａｎｄ  Ｐｒｏｇｒａｍｍａｂｌｅ  ＲＯＭ）や、レジスタや、ハードディスクや、リムーバブルディスクや、ＣＤ-ＲＯＭといった任意形式の記憶媒体内に設けられていてもよい。
【００７８】
かかる記憶媒体は、プロセッサが当該記憶媒体に情報を読み書きできるように、当該プロセッサに接続されている。また、かかる記憶媒体は、プロセッサに集積されていてもよい。また、かかる記憶媒体及びプロセッサは、ＡＳＩＣ内に設けられていてもよい。かかるＡＳＩＣは、移動局ＵＥや無線基地局ｅＮＢ内に設けられていてもよい。また、かかる記憶媒体及びプロセッサは、ディスクリートコンポーネントとして移動局ＵＥや無線基地局ｅＮＢ内に設けられていてもよい。
【００７９】
以上、上述の実施形態を用いて本発明について詳細に説明したが、当業者にとっては、本発明が本明細書中に説明した実施形態に限定されるものではないということは明らかである。本発明は、特許請求の範囲の記載により定まる本発明の趣旨及び範囲を逸脱することなく修正及び変更態様として実施することができる。従って、本明細書の記載は、例示説明を目的とするものであり、本発明に対して何ら制限的な意味を有するものではない。
【符号の説明】
【００８０】
ＵＥ…移動局
ｅＮＢ…無線基地局
１１…受信部
１２…管理部
１３…送信部
【図１】
0005871668.tif 000002
【図２】
0005871668.tif 000003
【図３】
0005871668.tif 000004
【図４】
0005871668.tif 000005
【図５】
0005871668.tif 000006
【図６】
0005871668.tif 000007
【図７】
0005871668.tif 000008
【図８】
0005871668.tif 000009