JP5871668B2

JP5871668B2 - 移動局及び無線基地局

Info

Publication number: JP5871668B2
Application number: JP2012055656A
Authority: JP
Inventors: 徹内野; アニールウメシュ
Original assignee: NTT Docomo Inc
Current assignee: NTT Docomo Inc
Priority date: 2012-03-13
Filing date: 2012-03-13
Publication date: 2016-03-01
Anticipated expiration: 2032-03-13
Also published as: JP2013191965A; WO2013137306A1

Description

本発明は、移動局及び無線基地局に関する。

ＬＴＥ（ＬｏｎｇＴｅｒｍＥｖｏｌｕｔｉｏｎ）-Ａｄｖａｎｃｅｄ方式では、移動局ＵＥ及び無線基地局ｅＮＢにおいて、ＲＬＣ（ＲａｄｉｏＬｅｎｋＣｏｎｔｒｏｌ）レイヤ及びＭＡＣ（ＭｅｄｉａＡｃｃｅｓｓＣｏｎｔｒｏｌ）が設けられている。

送信側のＲＬＣレイヤ及び受信側のＲＬＣレイヤにおいて、順序制御や重複制御を提供するために、ウィンドウ（ｗｉｎｄｏｗ）制御を行っている。

図５に示すように、送信側のＲＬＣレイヤでは、送信する新規のＲＬＣ-ＰＤＵ（ＰｒｏｔｏｃｏｌＤａｔａＵｎｉｔ）に対してシーケンス番号（ＳＮ：ＳｅｑｕｅｎｃｅＮｕｍｂｅｒ）を付与し、受信側のＲＬＣレイヤからの「ＳｔａｔｕｓＲｅｐｏｒｔ（ＡＣＫ/ＮＡＣＫ）」に基づいて、「Ｔｘｗｉｎｄｏｗ（送信ウィンドウ）」を更新する。

一方、図５に示すように、受信側のＲＬＣレイヤでは、シーケンス番号順にＲＬＣ-ＰＤＵを受信できた場合に、「Ｒｘｗｉｎｄｏｗ（受信ウィンドウ）」を更新する。

また、図６に示すように、送信側のＲＬＣレイヤが、受信側のＲＬＣレイヤからの「ＳｔａｔｕｓＲｅｐｏｒｔ」を受信できない場合には、「Ｔｘｗｉｎｄｏｗ」を更新することができず、「Ｔｘｗｉｎｄｏｗｓｔａｌｌｉｎｇ」が発生し、新規のＲＬＣ-ＰＤＵを送信することができなくなるため、受信側のＲＬＣレイヤは、適切な頻度で、送信側のＲＬＣレイヤに対して、「ＳｔａｔｕｓＲｅｐｏｒｔ」を送信する必要がある。

なお、受信側のＲＬＣレイヤは、定期的に、或いは、下りデータの最後等のイベント発生時に、送信側のＲＬＣレイヤから、フィードバック要求を受信した場合に、送信側のＲＬＣレイヤに対して、「ＳｔａｔｕｓＲｅｐｏｒｔ」を送信するように構成されている。

また、受信側のＲＬＣレイヤは、受信したＲＬＣ-ＰＤＵにおいて、シーケンス番号の抜けを検出した場合に、送信側のＲＬＣレイヤに対して、「ＳｔａｔｕｓＲｅｐｏｒｔ」を送信するように構成されている。

ここで、受信側のＲＬＣレイヤは、上述のような「ＳｔａｔｕｓＲｅｐｏｒｔ」の送信トリガを検出した場合であっても、図５及び図６に示すように、「ＰｒｏｈｉｂｉｔＴｉｍｅｒ」が起動している場合には、「ＳｔａｔｕｓＲｅｐｏｒｔ」を送信しないように構成されている。図７に、かかる受信側のＲＬＣレイヤの動作の一例について示す。

かかる「ＰｒｏｈｉｂｉｔＴｉｍｅｒ」は、「ＳｔａｔｕｓＲｅｐｏｒｔ」の頻繁な送信によるオーバーヘッドを低減するために設けられているタイマである。

また、図８に示すように、送信側のＭＡＣレイヤは、ＲＬＣレイヤから受信したデータ（ＲＬＣ-ＰＤＵ）を物理信号（Ｔｒａｎｓｐｏｒｔｂｌｏｃｋ）にマッピングするように構成されている。

具体的には、送信側のＭＡＣレイヤは、優先度の高いデータ（ＲＬＣ-ＰＤＵ）から送信されるように、所定の優先度に基づいて、上述のマッピングを行うように構成されている。

また、図８に示すように、送信側のＭＡＣレイヤは、マッピングすべきデータ（ＲＬＣ-ＰＤＵ）が枯渇した場合には、Ｐａｄｄｉｎｇ処理を行うように構成されている。

３ＧＰＰＴＳ３６.３２１３ＧＰＰＴＳ３６.３２２

上述のように、ＲＬＣレイヤでは、オーバーヘッドが懸念されない限り、頻繁に「ＳｔａｔｕｓＲｅｐｏｒｔ」を送受信して、送信側のＲＬＣレイヤが、「Ｔｘｗｉｎｄｏｗ」を更新することで、「Ｔｘｗｉｎｄｏｗｓｔａｌｌｉｎｇ」の発生確率を低減することが望ましい。

しかしながら、現在のＬＴＥ-Ａｄｖａｎｃｅｄ方式では、送信側のＭＡＣレイヤにおいて、Ｐａｄｄｉｎｇ処理が行われる程、リソースが余っている場合であっても、送信側のＲＬＣレイヤは、「ＳｔａｔｕｓＲｅｐｏｒｔ」の送信トリガを検出しない限り、「ＳｔａｔｕｓＲｅｐｏｒｔ」を送信することができず、リソースを有効に活用することができないという問題点があった。

また、現在のＬＴＥ-Ａｄｖａｎｃｅｄ方式では、送信側のＲＬＣレイヤは、送信側のＭＡＣレイヤにおいて、Ｐａｄｄｉｎｇ処理が行われる程、リソースが余っている場合で、かつ、「ＳｔａｔｕｓＲｅｐｏｒｔ」の送信トリガを検出した場合であっても、「ＰｒｏｈｉｂｉｔＴｉｍｅｒ」が起動している場合には、「ＳｔａｔｕｓＲｅｐｏｒｔ」を送信することができず、やはりリソースを有効に活用することができないという問題点があった。

そこで、本発明は、上述の課題に鑑みてなされたものであり、リソースを有効活用して、「Ｔｘｗｉｎｄｏｗｓｔａｌｌｉｎｇ」の発生確率を低減することができる移動局及び無線基地局を提供することを目的とする。

本発明の第１の特徴は、移動局であって、無線基地局によって送信された下りデータを受信するように構成されている受信部と、前記無線基地局に対して、所定トリガに応じて、前記受信部によって受信された前記下りデータの受信結果について示すステータスレポートを送信するように構成されている送信部とを具備しており、前記送信部は、前記ステータスレポートの送信を禁止する期間を規定するタイマが起動されている場合であっても、送信すべき上りデータを収容するトランスポートブロックにおいて該ステータスレポートを収容することができる余剰リソースが存在する場合には、該ステータスレポートを送信するように構成されていることを要旨とする。

本発明の第２の特徴は、移動局であって、無線基地局によって送信された下りデータを受信するように構成されている受信部と、前記無線基地局に対して、所定トリガに応じて、前記受信部によって受信された前記下りデータの受信結果について示すステータスレポートを送信するように構成されている送信部とを具備しており、前記送信部は、前記ステータスレポートの送信トリガを検出していない場合であっても、送信すべき上りデータを収容するトランスポートブロックにおいて該ステータスレポートを収容することができる余剰リソースが存在する場合には、該ステータスレポートを送信するように構成されていることを要旨とする。

本発明の第３の特徴は、無線基地局であって、移動局によって送信された上りデータを受信するように構成されている受信部と、前記移動局に対して、所定トリガに応じて、前記受信部によって受信された前記上りデータの受信結果について示すステータスレポートを送信するように構成されている送信部とを具備しており、前記送信部は、前記ステータスレポートの送信を禁止する期間を規定するタイマが起動されている場合であっても、送信すべき下りデータを収容するトランスポートブロックにおいて該ステータスレポートを収容することができる余剰リソースが存在する場合には、該ステータスレポートを送信するように構成されていることを要旨とする。

本発明の第４の特徴は、無線基地局であって、移動局によって送信された上りデータを受信するように構成されている受信部と、前記移動局に対して、所定トリガに応じて、前記受信部によって受信された前記上りデータの受信結果について示すステータスレポートを送信するように構成されている送信部とを具備しており、前記送信部は、前記ステータスレポートの送信トリガを検出していない場合であっても、送信すべき下りデータを収容するトランスポートブロックにおいて該ステータスレポートを収容することができる余剰リソースが存在する場合には、該ステータスレポートを送信するように構成されていることを要旨とする。

以上説明したように、本発明によれば、リソースを有効活用して、「Ｔｘｗｉｎｄｏｗｓｔａｌｌｉｎｇ」の発生確率を低減することができる移動局及び無線基地局を提供することができる。

本発明の第１の実施形態に係る移動通信システムを構成する移動局及び無線基地局のプロトコルスタックを示す図である。本発明の第１の実施形態に係る移動局の機能ブロック図である。本発明の第１の実施形態に係る移動通信システムの動作を説明するための図である。本発明の第１の実施形態に係る移動局の動作を示すフローチャートである。従来の移動通信システムについて説明するための図である。従来の移動通信システムについて説明するための図である。従来の移動通信システムについて説明するための図である。従来の移動通信システムについて説明するための図である。

（本発明の第１の実施形態に係る移動通信システム）
図１乃至図４を参照して、本発明の第１の実施形態に係る移動通信システムについて説明する。

本実施形態に係る移動通信システムとして、ＬＴＥ-Ａｄｖａｎｃｅｄ方式の移動通信システムを例に挙げて説明するが、本発明は、かかる移動通信システムに限定されず、他の方式の移動通信システムにも適用可能である。

図１に示すように、本実施形態に係る移動局ＵＥ及び無線基地局ｅＮＢには、物理（ＰＨＹ）レイヤや、ＭＡＣレイヤや、ＰＬＣレイヤや、ＰＤＣＰ（ＰａｃｋｅｔＤａｔａＣｏｎｖｅｒｇｅｎｃｅＰｒｏｔｏｃｏｌ）レイヤや、ＲＲＣ（ＲａｄｉｏＲｅｓｏｕｒｃｅＣｏｎｔｒｏｌ）レイヤが設けられている。

図２に示すように、本実施形態に係る移動局ＵＥは、受信部１１と、管理部１２と、送信部１３とを具備している。

受信部１１は、ＲＬＣレイヤにおいて、無線基地局ｅＮＢによって送信されたＲＬＣ-ＰＤＵ（下りデータ）を受信するように構成されている。

管理部１２は、「ＰｒｏｈｉｂｉｔＴｉｍｅｒ」が起動しているか否かについて管理するように構成されている。

送信部１３は、ＲＬＣレイヤにおいて、無線基地局ｅＮＢに対して、ＲＬＣ-ＰＤＵ（上りデータ）を送信するように構成されている。

原則として、送信部１３は、ＲＬＣレイヤにおいて、「ＳｔａｔｕｓＲｅｐｏｒｔ」の送信トリガに応じて、すなわち、「ＳｔａｔｕｓＲｅｐｏｒｔ」の送信トリガを検出した場合に、無線基地局ｅＮＢに対して、受信部１１によって受信されたＲＬＣ-ＰＤＵの受信結果（ＡＣＫ/ＮＡＣＫ）について示す「ＳｔａｔｕｓＲｅｐｏｒｔ」を送信するように構成されている。

そして、送信部１３は、「ＰｒｏｈｉｂｉｔＴｉｍｅｒ」が起動されている場合には、「ＳｔａｔｕｓＲｅｐｏｒｔ」の送信トリガを検出した場合であっても、無線基地局ｅＮＢに対して、かかる「ＳｔａｔｕｓＲｅｐｏｒｔ」を送信しないように構成されている。

しかしながら、送信部１３は、「ＰｒｏｈｉｂｉｔＴｉｍｅｒ」が起動されている場合であっても、送信すべきＲＬＣ-ＰＤＵを収容する物理信号（Ｔｒａｎｓｐｏｒｔｂｌｏｃｋ）において「ＳｔａｔｕｓＲｅｐｏｒｔ」を収容することができる余剰リソースが存在する場合には、図３に示すように、ＲＬＣレイヤにおいて、無線基地局ｅＮＢに対して、「ＳｔａｔｕｓＲｅｐｏｒｔ」を送信するように構成されていてもよい。

或いは、送信部１３は、「ＳｔａｔｕｓＲｅｐｏｒｔ」の送信トリガを検出していない場合であっても、送信すべきＲＬＣ-ＰＤＵを収容する物理信号（Ｔｒａｎｓｐｏｒｔｂｌｏｃｋ）において「ＳｔａｔｕｓＲｅｐｏｒｔ」を収容することができる余剰リソースが存在する場合には（「ＰｒｏｈｉｂｉｔＴｉｍｅｒ」が起動されているか否かに関わらず）、図３に示すように、ＲＬＣレイヤにおいて、無線基地局ｅＮＢに対して、「ＳｔａｔｕｓＲｅｐｏｒｔ」を送信するように構成されていてもよい。

ここで、ＭＡＣレイヤにおいて、「ＳｔａｔｕｓＲｅｐｏｒｔ」は、物理信号（Ｔｒａｎｓｐｏｒｔｂｌｏｃｋ）における余剰リソース（Ｐａｄｄｉｎｇデータを収容する予定であったリソース）に収容されることになる。

また、「ＳｔａｔｕｓＲｅｐｏｒｔ」の送信トリガの１つとして、ＲＬＣレイヤの順序補正タイマの満了が存在するが、「ＳｔａｔｕｓＲｅｐｏｒｔ」が送信された際には、かかる順序補正タイマを停止してもよい。

以下、図４を参照して、本実施形態に係る移動局ＵＥのＲＬＣレイヤの動作について説明する。

図４に示すように、移動局ＵＥのＲＬＣレイヤは、ステップＳ１０１において、「ＳｔａｔｕｓＲｅｐｏｒｔ」の送信トリガを検出したか否かについて判定する。

「ＹＥＳ」の場合、本動作は、ステップＳ１０２に進み、「ＮＯ」の場合、本動作は、ステップＳ１０３に進む。

ステップＳ１０２において、移動局ＵＥのＲＬＣレイヤは、「ＰｒｏｈｉｂｉｔＴｉｍｅｒ」が起動しているか否かについて判定する。

「ＮＯ」の場合、本動作は、ステップＳ１０４に進み、「ＹＥＳ」の場合、本動作は、ステップＳ１０３に進む。

ステップＳ１０３において、移動局ＵＥのＲＬＣレイヤは、ＭＡＣレイヤにおいて行われるＰａｄｄｉｎｇ処理で用いられるＰａｄｄｉｎｇデータのサイズが「ＳｔａｔｕｓＲｅｐｏｒｔ」のサイズよりも大きいか否かについて判定する。

「ＮＯ」の場合、本動作は、終了し、「ＹＥＳ」の場合、本動作は、ステップＳ１０４に進む。

ステップＳ１０４において、移動局ＵＥのＲＬＣレイヤは、無線基地局ｅＮＢのＲＬＣレイヤに対して、「ＳｔａｔｕｓＲｅｐｏｒｔ」を送信する。

ステップＳ１０５において、移動局ＵＥのＲＬＣレイヤは、「ＰｒｏｈｉｂｉｔＴｉｍｅｒ」を再起動する。なお、ステップＳ１０５の処理は、省略されてもよい。

本実施形態に係る発明によれば、移動局ＵＥのＲＬＣレイヤは、「ＳｔａｔｕｓＲｅｐｏｒｔ」の送信トリガを検出した場合に、「ＰｒｏｈｉｂｉｔＴｉｍｅｒ」が起動されている場合であっても、送信すべきＲＬＣ-ＰＤＵを収容する物理信号（Ｔｒａｎｓｐｏｒｔｂｌｏｃｋ）において「ＳｔａｔｕｓＲｅｐｏｒｔ」を収容することができる余剰リソースが存在する場合には、「ＳｔａｔｕｓＲｅｐｏｒｔ」を送信するように構成されているため、リソースを有効活用して、「ＳｔａｔｕｓＲｅｐｏｒｔ」の送受信を頻繁に行うことができ、「Ｔｘｗｉｎｄｏｗｓｔａｌｌｉｎｇ」の発生確率を低減することができる。

或いは、移動局ＵＥのＲＬＣレイヤは、「ＳｔａｔｕｓＲｅｐｏｒｔ」の送信トリガを検出していない場合であっても、送信すべきＲＬＣ-ＰＤＵを収容する物理信号（Ｔｒａｎｓｐｏｒｔｂｌｏｃｋ）において「ＳｔａｔｕｓＲｅｐｏｒｔ」を収容することができる余剰リソースが存在する場合には（「ＰｒｏｈｉｂｉｔＴｉｍｅｒ」が起動されているか否かに関わらず）、「ＳｔａｔｕｓＲｅｐｏｒｔ」を送信するように構成されているため、リソースを有効活用して、「ＳｔａｔｕｓＲｅｐｏｒｔ」の送受信を頻繁に行うことができ、「Ｔｘｗｉｎｄｏｗｓｔａｌｌｉｎｇ」の発生確率を低減することができる。

（変更例１）
なお、上述の第１の実施形態における移動局ＵＥの機能と同一の機能は、無線基地局ｅＮＢにおいて具備されていてもよい。

具体的には、本変更例１では、図２に示すように、本実施形態に係る無線基地局ｅＮＢは、受信部１１と、管理部１２と、送信部１３とを具備している。

受信部１１は、ＲＬＣレイヤにおいて、移動局ＵＥによって送信されたＲＬＣ-ＰＤＵ（上りデータ）を受信するように構成されている。

送信部１３は、ＲＬＣレイヤにおいて、移動局ＵＥに対して、ＲＬＣ-ＰＤＵ（下りデータ）を送信するように構成されている。

原則として、送信部１３は、ＲＬＣレイヤにおいて、「ＳｔａｔｕｓＲｅｐｏｒｔ」の送信トリガに応じて、すなわち、「ＳｔａｔｕｓＲｅｐｏｒｔ」の送信トリガを検出した場合に、移動局ＵＥに対して、受信部１１によって受信されたＲＬＣ-ＰＤＵの受信結果（ＡＣＫ/ＮＡＣＫ）について示す「ＳｔａｔｕｓＲｅｐｏｒｔ」を送信するように構成されている。

そして、送信部１３は、「ＰｒｏｈｉｂｉｔＴｉｍｅｒ」が起動されている場合には、「ＳｔａｔｕｓＲｅｐｏｒｔ」の送信トリガを検出した場合であっても、移動局ＵＥに対して、かかる「ＳｔａｔｕｓＲｅｐｏｒｔ」を送信しないように構成されている。

しかしながら、送信部１３は、「ＰｒｏｈｉｂｉｔＴｉｍｅｒ」が起動されている場合であっても、送信すべきＲＬＣ-ＰＤＵを収容する物理信号（Ｔｒａｎｓｐｏｒｔｂｌｏｃｋ）において「ＳｔａｔｕｓＲｅｐｏｒｔ」を収容することができる余剰リソースが存在する場合には、図３に示すように、ＲＬＣレイヤにおいて、移動局ＵＥに対して、「ＳｔａｔｕｓＲｅｐｏｒｔ」を送信するように構成されていてもよい。

或いは、送信部１３は、「ＳｔａｔｕｓＲｅｐｏｒｔ」の送信トリガを検出していない場合であっても、送信すべきＲＬＣ-ＰＤＵを収容する物理信号（Ｔｒａｎｓｐｏｒｔｂｌｏｃｋ）において「ＳｔａｔｕｓＲｅｐｏｒｔ」を収容することができる余剰リソースが存在する場合には（「ＰｒｏｈｉｂｉｔＴｉｍｅｒ」が起動されているか否かに関わらず）、図３に示すように、ＲＬＣレイヤにおいて、移動局ＵＥに対して、「ＳｔａｔｕｓＲｅｐｏｒｔ」を送信するように構成されていてもよい。

以下、図４を参照して、本実施形態に係る無線基地局ｅＮＢのＲＬＣレイヤの動作について説明する。

図４に示すように、無線基地局ｅＮＢのＲＬＣレイヤは、ステップＳ１０１において、「ＳｔａｔｕｓＲｅｐｏｒｔ」の送信トリガを検出したか否かについて判定する。

ステップＳ１０２において、無線基地局ｅＮＢのＲＬＣレイヤは、「ＰｒｏｈｉｂｉｔＴｉｍｅｒ」が起動しているか否かについて判定する。

ステップＳ１０３において、無線基地局ｅＮＢのＲＬＣレイヤは、ＭＡＣレイヤにおいて行われるＰａｄｄｉｎｇ処理で用いられるＰａｄｄｉｎｇデータのサイズが「ＳｔａｔｕｓＲｅｐｏｒｔ」のサイズよりも大きいか否かについて判定する。

ステップＳ１０４において、無線基地局ｅＮＢのＲＬＣレイヤは、移動局ＵＥのＲＬＣレイヤに対して、「ＳｔａｔｕｓＲｅｐｏｒｔ」を送信する。

ステップＳ１０５において、無線基地局ｅＮＢのＲＬＣレイヤは、「ＰｒｏｈｉｂｉｔＴｉｍｅｒ」を再起動する。なお、ステップＳ１０５の処理は、省略されてもよい。

本実施形態に係る発明によれば、無線基地局ｅＮＢのＲＬＣレイヤは、「ＳｔａｔｕｓＲｅｐｏｒｔ」の送信トリガを検出した場合に、「ＰｒｏｈｉｂｉｔＴｉｍｅｒ」が起動されている場合であっても、送信すべきＲＬＣ-ＰＤＵを収容する物理信号（Ｔｒａｎｓｐｏｒｔｂｌｏｃｋ）において「ＳｔａｔｕｓＲｅｐｏｒｔ」を収容することができる余剰リソースが存在する場合には、「ＳｔａｔｕｓＲｅｐｏｒｔ」を送信するように構成されているため、リソースを有効活用して、「ＳｔａｔｕｓＲｅｐｏｒｔ」の送受信を頻繁に行うことができ、「Ｔｘｗｉｎｄｏｗｓｔａｌｌｉｎｇ」の発生確率を低減することができる。

或いは、無線基地局のＲＬＣレイヤは、「ＳｔａｔｕｓＲｅｐｏｒｔ」の送信トリガを検出していない場合であっても、送信すべきＲＬＣ-ＰＤＵを収容する物理信号（Ｔｒａｎｓｐｏｒｔｂｌｏｃｋ）において「ＳｔａｔｕｓＲｅｐｏｒｔ」を収容することができる余剰リソースが存在する場合には（「ＰｒｏｈｉｂｉｔＴｉｍｅｒ」が起動されているか否かに関わらず）、「ＳｔａｔｕｓＲｅｐｏｒｔ」を送信するように構成されているため、リソースを有効活用して、「ＳｔａｔｕｓＲｅｐｏｒｔ」の送受信を頻繁に行うことができ、「Ｔｘｗｉｎｄｏｗｓｔａｌｌｉｎｇ」の発生確率を低減することができる。

以上に述べた本実施形態の特徴は、以下のように表現されていてもよい。

本実施形態の第１の特徴は、移動局ＵＥであって、無線基地局ｅＮＢによって送信されたＲＬＣ-ＰＤＵ（下りデータ）を受信するように構成されている受信部１１と、無線基地局ｅＮＢに対して、「ＳｔａｔｕｓＲｅｐｏｒｔ」の送信トリガ（所定トリガ）に応じて、受信部１１によって受信されたＲＬＣ-ＰＤＵの受信結果について示す「ＳｔａｔｕｓＲｅｐｏｒｔ（ステータスレポート）」を送信するように構成されている送信部１３とを具備しており、送信部１３は、「ＳｔａｔｕｓＲｅｐｏｒｔ」の送信を禁止する期間を規定する「ＰｒｏｈｉｂｉｔＴｉｍｅｒ（タイマ）」が起動されている場合であっても、送信すべきＲＬＣ-ＰＤＵ（上りデータ）を収容するトランスポートブロックにおいて「ＳｔａｔｕｓＲｅｐｏｒｔ」を収容することができる余剰リソースが存在する場合には、「ＳｔａｔｕｓＲｅｐｏｒｔ」を送信するように構成されていることを要旨とする。

本実施形態の第２の特徴は、移動局ＵＥであって、無線基地局ｅＮＢによって送信されたＲＬＣ-ＰＤＵを受信するように構成されている受信部１１と、無線基地局ｅＮＢに対して、「ＳｔａｔｕｓＲｅｐｏｒｔ」の送信トリガ（所定トリガ）に応じて、受信部１１によって受信されたＲＬＣ-ＰＤＵの受信結果について示す「ＳｔａｔｕｓＲｅｐｏｒｔ」を送信するように構成されている送信部１３とを具備しており、送信部１３は、「ＳｔａｔｕｓＲｅｐｏｒｔ」の送信トリガを検出していない場合であっても、送信すべきＲＬＣ-ＰＤＵを収容するトランスポートブロックにおいて「ＳｔａｔｕｓＲｅｐｏｒｔ」を収容することができる余剰リソースが存在する場合には、「ＳｔａｔｕｓＲｅｐｏｒｔ」を送信するように構成されていることを要旨とする。

本実施形態の第３の特徴は、無線基地局ｅＮＢであって、移動局ＵＥによって送信されたＲＬＣ-ＰＤＵを受信するように構成されている受信部１１と、移動局ＵＥに対して、「ＳｔａｔｕｓＲｅｐｏｒｔ」の送信トリガ（所定トリガ）に応じて、受信部１１によって受信されたＲＬＣ-ＰＤＵの受信結果について示す「ＳｔａｔｕｓＲｅｐｏｒｔ」を送信するように構成されている送信部１３とを具備しており、送信部１３は、「ＳｔａｔｕｓＲｅｐｏｒｔ」の送信を禁止する期間を規定する「ＰｒｏｈｉｂｉｔＴｉｍｅｒ」が起動されている場合であっても、送信すべきＲＬＣ-ＰＤＵを収容するトランスポートブロックにおいて「ＳｔａｔｕｓＲｅｐｏｒｔ」を収容することができる余剰リソースが存在する場合には、「ＳｔａｔｕｓＲｅｐｏｒｔ」を送信するように構成されていることを要旨とする。

本実施形態の第４の特徴は、無線基地局ｅＮＢであって、移動局ＵＥによって送信されたＲＬＣ-ＰＤＵを受信するように構成されている受信部１１と、移動局ＵＥに対して、「ＳｔａｔｕｓＲｅｐｏｒｔ」の送信トリガ（所定トリガ）に応じて、受信部１１によって受信されたＲＬＣ-ＰＤＵの受信結果について示す「ＳｔａｔｕｓＲｅｐｏｒｔ」を送信するように構成されている送信部１３とを具備しており、送信部１３は、「ＳｔａｔｕｓＲｅｐｏｒｔ」の送信トリガを検出していない場合であっても、送信すべきＲＬＣ-ＰＤＵを収容するトランスポートブロックにおいて「ＳｔａｔｕｓＲｅｐｏｒｔ」を収容することができる余剰リソースが存在する場合には、「ＳｔａｔｕｓＲｅｐｏｒｔ」を送信するように構成されていることを要旨とする。

なお、上述の移動局ＵＥや無線基地局ｅＮＢの動作は、ハードウェアによって実施されてもよいし、プロセッサによって実行されるソフトウェアモジュールによって実施されてもよいし、両者の組み合わせによって実施されてもよい。

ソフトウェアモジュールは、ＲＡＭ（ＲａｎｄｏｍＡｃｃｅｓｓＭｅｍｏｒｙ）や、フラッシュメモリや、ＲＯＭ（ＲｅａｄＯｎｌｙＭｅｍｏｒｙ）や、ＥＰＲＯＭ（ＥｒａｓａｂｌｅＰｒｏｇｒａｍｍａｂｌｅＲＯＭ）や、ＥＥＰＲＯＭ（ＥｌｅｃｔｒｏｎｉｃａｌｌｙＥｒａｓａｂｌｅａｎｄＰｒｏｇｒａｍｍａｂｌｅＲＯＭ）や、レジスタや、ハードディスクや、リムーバブルディスクや、ＣＤ-ＲＯＭといった任意形式の記憶媒体内に設けられていてもよい。

かかる記憶媒体は、プロセッサが当該記憶媒体に情報を読み書きできるように、当該プロセッサに接続されている。また、かかる記憶媒体は、プロセッサに集積されていてもよい。また、かかる記憶媒体及びプロセッサは、ＡＳＩＣ内に設けられていてもよい。かかるＡＳＩＣは、移動局ＵＥや無線基地局ｅＮＢ内に設けられていてもよい。また、かかる記憶媒体及びプロセッサは、ディスクリートコンポーネントとして移動局ＵＥや無線基地局ｅＮＢ内に設けられていてもよい。

以上、上述の実施形態を用いて本発明について詳細に説明したが、当業者にとっては、本発明が本明細書中に説明した実施形態に限定されるものではないということは明らかである。本発明は、特許請求の範囲の記載により定まる本発明の趣旨及び範囲を逸脱することなく修正及び変更態様として実施することができる。従って、本明細書の記載は、例示説明を目的とするものであり、本発明に対して何ら制限的な意味を有するものではない。

ＵＥ…移動局
ｅＮＢ…無線基地局
１１…受信部
１２…管理部
１３…送信部

Claims

無線基地局によって送信された下りデータを受信するように構成されている受信部と、
前記無線基地局に対して、所定トリガに応じて、前記受信部によって受信された前記下りデータの受信結果について示すステータスレポートを送信するように構成されている送信部とを具備しており、
前記送信部は、前記ステータスレポートの送信を禁止する期間を規定するタイマが起動されている場合であっても、送信すべき上りデータを収容するトランスポートブロックにおいて該ステータスレポートを収容することができる余剰リソースが存在する場合には、該ステータスレポートを送信するように構成されていることを特徴とする移動局。
無線基地局によって送信された下りデータを受信するように構成されている受信部と、
前記無線基地局に対して、所定トリガに応じて、または所定条件に応じて、前記受信部によって受信された前記下りデータの受信結果について示すステータスレポートを送信するように構成されている送信部とを具備しており、
前記送信部は、前記所定条件として、前記ステータスレポートの送信トリガを検出していない場合であっても、送信すべき上りデータを収容するトランスポートブロックにおいて該ステータスレポートを収容することができる余剰リソースが存在する場合には、該ステータスレポートを送信するように構成されていることを特徴とする移動局。
移動局によって送信された上りデータを受信するように構成されている受信部と、
前記移動局に対して、所定トリガに応じて、前記受信部によって受信された前記上りデータの受信結果について示すステータスレポートを送信するように構成されている送信部とを具備しており、
前記送信部は、前記ステータスレポートの送信を禁止する期間を規定するタイマが起動されている場合であっても、送信すべき下りデータを収容するトランスポートブロックにおいて該ステータスレポートを収容することができる余剰リソースが存在する場合には、該ステータスレポートを送信するように構成されていることを特徴とする無線基地局。
移動局によって送信された上りデータを受信するように構成されている受信部と、
前記移動局に対して、所定トリガに応じて、または所定条件に応じて、前記受信部によって受信された前記上りデータの受信結果について示すステータスレポートを送信するように構成されている送信部とを具備しており、
前記送信部は、前記所定条件として、前記ステータスレポートの送信トリガを検出していない場合であっても、送信すべき下りデータを収容するトランスポートブロックにおいて該ステータスレポートを収容することができる余剰リソースが存在する場合には、該ステータスレポートを送信するように構成されていることを特徴とする無線基地局。