JP5037633B2 - 移動通信システムにおけるｒｌｃｐｄｕ送信方法、無線リソース割当方法、及び移動通信システムのｒｌｃエンティティ - Google Patents

Description

本発明は、移動通信システムの無線プロトコルに関し、特に、長期的高度化（Long Term Evolution；ＬＴＥ）システムのＭＡＣ層及びＲＬＣ層が限られた無線リソースを使用してＲＬＣ状態ＰＤＵを優先的に送信する方法に関する。

図１は、従来の移動通信システムであるＬＴＥシステムのネットワーク構造を示す図である。ＬＴＥシステムは、既存のＵＭＴＳシステムから進化したシステムであり、基礎的な標準化作業が３ＧＰＰにより行われている。

ＬＴＥネットワークは、大きくＥ−ＵＴＲＡＮ（Evolved UMTS Terrestrial Radio Access Network）とコアネットワーク(Core Network；ＣＮ）とに区分される。Ｅ−ＵＴＲＡＮは、端末（User Equipment；UE）と、基地局（Evolved NodeB；eNB）と、ネットワークの端部に位置して外部ネットワークに接続されるアクセスゲートウェイ（Access Gateway；aGW）とを含む。ａＧＷは、ユーザトラフィックを処理する部分と制御トラフィックを処理する部分とに分けられる。この場合、ユーザトラフィック処理のためのａＧＷと制御トラフィック処理のためのａＧＷとの間では、新しいインタフェースを使用して通信することもできる。１つのｅＮＢには１つ以上のセルが存在する。ｅＮＢ間ではユーザトラフィック又は制御トラフィックの送信のためにインタフェースを使用してもよい。ＣＮは、ａＧＷ及びその他のＵＥのユーザ登録のためのノードなどを含んでいてもよい。Ｅ−ＵＴＲＡＮとＣＮとを識別するためにインタフェースを使用してもよい。

図２は、３ＧＰＰ無線アクセスネットワーク規格に準拠した端末とＥ−ＵＴＲＡＮとの間の無線インタフェースプロトコルの制御プレーンの構造を示す図である。図３は、３ＧＰＰ無線アクセスネットワーク規格に準拠した端末とＥ−ＵＴＲＡＮ間の無線インタフェースプロトコルのユーザプレーンの構造を示す図である。

以下、図２及び図３を参照して、端末とＥ−ＵＴＲＡＮとの間の無線インタフェースプロトコルの構造を説明する。

無線インタフェースプロトコルは、物理層、データリンク層、及びネットワーク層を含む水平層と、データ情報の送信のためのユーザプレーン、及び制御信号の送信のための制御プレーンを含む垂直プレーンとを有する。プロトコル層は、通信システムで広く知られている開放型システム間相互接続（Open System Interconnection；OSI）参照モデルの下位３層に基づいて、第１層（Ｌ１）、第２層（Ｌ２）、第３層（Ｌ３）に分けることができる。このような無線インタフェースプロトコルは、端末及びＥ−ＵＴＲＡＮに対で存在し、無線区間のデータ送信を管理する。

以下、図２の無線プロトコルの制御プレーン及び図３の無線プロトコルのユーザプレーンの各層について説明する。

第１層である物理（Physical;ＰＨＹ）層は、物理チャネルを利用して上位層に情報送信サービスを提供する。物理層は、上位の媒体アクセス制御（Medium Access Control；ＭＡＣ）層とトランスポートチャネルを介して接続されている。このトランスポートチャネルを介してＭＡＣ層及び物理層はデータをやり取りする。ここで、トランスポートチャネルは、チャネルが共有されるか否かによって、大きく専用トランスポートチャネルと共通トランスポートチャネルとに分けられる。また、異なる物理層間、すなわち送信側物理層と受信側物理層間では、物理チャネルを介してデータの移動が行われる。

第２層には様々な層が存在する。まず、媒体アクセス制御（ＭＡＣ）層は、様々な論理チャネルを様々なトランスポートチャネルにマッピングする役割を果たし、様々な論理チャネルを１つのトランスポートチャネルにマッピングする論理チャネル多重化も実行する。ＭＡＣ層は、上位の無線リンク制御（radio link control;ＲＬＣ)層と論理チャネルとを介して接続されている。この論理チャネルは、送信される情報の種類によって、制御プレーン情報を送信するための制御チャネルと、ユーザプレーン情報を送信するためのトラフィックチャネルとに分けられる。

第２層のＲＬＣ層は、上位層から受信したデータを分割及び結合して、下位層における無線区間のデータ送信ができるようにデータサイズを適切に調節する。また、ＲＬＣ層は、各無線ベアラ（Radio Bearer；RB）が要求する様々なサービス品質（ＱｏＳ）を保証するために、透過モード（Transparent Mode；TM）、非応答モード（Un-acknowledged Mode；UM）、及び応答モード（Acknowledged Mode；AM）の３つの動作モードを提供する。特に、ＡＭモードで動作するＲＬＣ層（以下、ＡＭ ＲＬＣ層という）は、信頼性が高いデータ送信のために、自動再送要求（Automatic Repeat Request；ARQ）機能を利用した再送機能を実行する。

第２層のパケットデータコンバージェンスプロトコル（Packet Data Convergence Protocol；PDCP）層は、ＩＰｖ４やＩＰｖ６などのＩＰパケットを帯域幅が比較的狭い無線区間で効率的に送信する。そのために、ＰＤＣＰ層は、相対的にサイズが大きく、不要な制御情報を含むＩＰパケットのヘッダのサイズを小さくする、即ちヘッダ圧縮と呼ばれる機能を実行する。従って、無線区間の送信効率を向上させるために、送信データのヘッダ部分に必要な情報のみを含ませることができる。

第３層の最下位に位置する無線リソース制御（Radio Resource Control；RRC）層は、制御プレーンでのみ定義される。ＲＲＣ層は、無線ベアラ（ＲＢ）の設定、再設定、及び解除に関連して論理チャネル、トランスポートチャネル、及び物理チャネルを制御する。ここで、ＲＢとは、端末とＵＴＲＡＮ間のデータ送信のためにＬ２層が提供する論理パスを意味する。一般に、ＲＢの確立とは、特定のサービスを提供するために要求されるプロトコル層及びチャネルの特性の規定と、それぞれの詳細なパラメータ及び動作方法の設定を意味する。ＲＢは、シグナリングＲＢ(ＳＲＢ）とデータＲＢ（ＤＲＢ）とに分けられる。ＳＲＢは制御プレーンでＲＲＣメッセージを送信するパスとして使用され、ＤＲＢはユーザプレーンでユーザデータを送信するパスとして使用される。

以下、ＲＬＣ層についてより具体的に説明する。前述のように、ＲＬＣ層は、ＴＭ、ＵＭ、及びＡＭの３つのモードを備える。ＲＬＣ層は、ＴＭにおいて機能を実行することがほとんどないため、ここではＵＭ及びＡＭについてのみ説明する。

ＵＭ ＲＬＣは、送信する各ＰＤＵにシーケンス番号（Sequence Number；ＳＮ）を含むプロトコルデータ単位（ＰＤＵ）ヘッダを付加することにより、どのＰＤＵが送信中に消失したか受信側が分かるようにする。この機能により、ＵＭ ＲＬＣは、ユーザプレーンでは、マルチメディアデータの送信や、パケットサービスドメイン（Packet Service domain；ＰＳドメイン）の音声（例えば、ＶｏＩＰ）やストリーミングなどのリアルタイムパケットデータの送信を管理し、一方、制御プレーンでは、セル内の特定の端末又は特定の端末グループに送信されるＲＲＣメッセージのうち、受信確認応答を必要としないＲＲＣメッセージの送信を管理する。

同様に、ＡＭ ＲＬＣは、ＰＤＵの構成時、ＳＮを含むＰＤＵヘッダを付加してＰＤＵを構成する。ＵＭ ＲＬＣとは異なり、受信側が、送信側によって送信されたＰＤＵの受信を確認する。受信側は、送信側から受信していないＰＤＵの再送を要求するために、受信の確認を行う。この再送機能がＡＭ ＲＬＣの最も重要な特徴である。つまり、ＡＭ ＲＬＣは、再送によりエラーのないデータ送信を保証することを目的としている。この目的のために、ＡＭ ＲＬＣは、主に、ユーザプレーンでは、ＰＳドメインのＴＣＰ／ＩＰなどの非リアルタイムパケットデータの送信を管理し、一方、制御プレーンでは、セル内の特定の端末に送信されるＲＲＣメッセージのうち、受信確認応答の受信を必要とするＲＲＣメッセージの送信を管理する。

方向性の観点から見ると、ＵＭ ＲＬＣは、単方向通信に使用されるのに対して、ＡＭ ＲＬＣは、受信側からのフィードバックがあるため、双方向通信に使用される。構造的な観点から差があり、即ち、ＵＭ ＲＬＣは、１つのＲＬＣエンティティが送信又は受信のどちらかを実行するように構成されているのに対して、ＡＭ ＲＬＣは、１つのＲＬＣエンティティ内に送信側及び受信側の両方が存在するように構成されている。

ＡＭ ＲＬＣの複雑な構成は再送に起因する。再送管理のために、ＡＭ ＲＬＣは、送受信バッファの他に再送を管理するための再送バッファを備えている。フロー制御のための送受信ウィンドウの使用、送信側がＲＬＣエンティティの受信側に状態情報を要求するポーリング、受信側がピアＲＬＣエンティティの送信側に受信側のバッファ状態を報告する状態報告の送信、状態情報を送信するための状態ＰＤＵの構築などの様々な機能を実行する。また、これらの機能をサポートするために、ＡＭ ＲＬＣは、状態変数やタイマーなどの様々なプロトコルパラメータを必要とする。これらの状態報告や状態ＰＤＵなどのようにＡＭ ＲＬＣでデータ送信の制御のために使用されるＰＤＵを制御ＰＤＵといい、ユーザデータの送信のために使用されるＰＤＵをデータＰＤＵという。

ＡＭ ＲＬＣにおいてＲＬＣデータＰＤＵは、詳細にはＡＭＤ ＰＤＵとＡＭＤ ＰＤＵセグメントとに分けられる。ＡＭＤ ＰＤＵセグメントは、ＡＭＤ ＰＤＵに含まれるデータの一部を有する。ＬＴＥシステムにおいては、毎回端末がデータブロックを送信するたびに、データブロックの最大サイズが可変となっている。よって、送信側ＡＭ ＲＬＣエンティティは、ある時点で２００ｂｙｔｅのＡＭＤ ＰＤＵを構成して送信した後、送信側ＡＭ ＲＬＣエンティティが受信側ＡＭ ＲＬＣからＮＡＣＫを受信して前記ＡＭＤ ＰＤＵを再送しようとするとき、実際に送信できるデータブロックの最大サイズが１００ｂｙｔｅであれば、前記ＡＭＤ ＰＤＵをそのまま再送することはできない。この場合に、ＡＭＤ ＰＤＵセグメントが使用される。ＡＭＤ ＰＤＵ セグメントとは、対応するＡＭＤ ＰＤＵが小さい単位に分けられたものを意味する。前記処理で、送信側ＡＭ ＲＬＣエンティティは、前記ＡＭＤ ＰＤＵをＡＭＤ ＰＤＵセグメントに分けていくつかの時間間隔で送信する。受信側ＡＭ ＲＬＣエンティティは、受信した前記ＡＭＤ ＰＤＵセグメントからＡＭＤ ＰＤＵを復元する。

受信側ＡＭ ＲＬＣは、受信に失敗した（不完全または不正確な）データがある場合、このようなデータの送信側ＡＭ ＲＬＣからの再送を要求し、これを状態報告という。状態報告は制御ＰＤＵの１つである状態ＰＤＵを使用して送信される。

図４は、現在ＬＴＥシステムで使用されている状態ＰＤＵの形式を示す図である。図４における横軸は、ＲＬＣ状態ＰＤＵの長さであって、８ビット、すなわち１オクテットである。

以下、ＲＬＣ状態ＰＤＵの各フィールドについて説明する。

１．データ／制御（Ｄ／Ｃ）フィールド：１ビット
このフィールドは、対応するＲＬＣ ＰＤＵがＲＬＣデータＰＤＵであるかＲＬＣ制御ＰＤＵであるかを示す。

２．制御ＰＤＵタイプ（ＣＰＴ）フィールド：３ビット
このフィールドは、対応する制御ＰＤＵがどのタイプであるかを示す。現在、ＲＬＣ制御ＰＤＵには状態ＰＤＵのみ定義されている。

３．確認応答シーケンス番号（ＡＣＫ＿ＳＮ）
２つのタイプのＡＣＫ＿ＳＮが以下のように定義される。
１−１）ＡＣＫ＿ＳＮの１つのタイプは、状態ＰＤＵには情報が含まれない最初のＰＤＵのＲＬＣ ＳＮである。
１−２）この状態ＰＤＵを受信すると、送信側は、ＡＣＫ＿ＳＮ−１を有するＰＤＵまでのＰＤＵのうち、状態ＰＤＵにおいてＮＡＣＫ＿ＳＮが表示されたＰＤＵ、又は状態ＰＤＵにおいてＮＡＣＫ＿ＳＮ、ＳＯｓｔａｒｔ、ＳＯｅｎｄが表示されたＰＤＵの一部を除いて受信側で全て正常に受信されたと判断する。

本発明によれば、このようなＡＣＫ＿ＳＮは、図６及び図８の実施例に適用されている。
２−１）ＡＣＫ＿ＳＮの他の１つタイプは、情報が状態ＰＤＵに含まれている最初のＰＤＵのＲＬＣ ＳＮである。
２−２）この状態ＰＤＵを受信すると、送信側は、ＡＣＫ＿ＳＮを有するＰＤＵまでのＰＤＵのうち、状態ＰＤＵにおいてＮＡＣＫ＿ＳＮが表示されたＰＤＵ、又は状態ＰＤＵにおいてＮＡＣＫ＿ＳＮ、ＳＯｓｔａｒｔ、ＳＯｅｎｄが表示されたＰＤＵの一部を除いて受信側で全て正常に受信されたと判断する。

本発明に従って、このようなＡＣＫ＿ＳＮは、図７及び図９の実施例に適用されている。

４．エクステンション１（Ｅ１）：１ビット
これは、現在のＮＡＣＫ＿ＳＮエレメント（すなわち、ＮＡＣＫ＿ＳＮ、又はＮＡＣＫ＿ＳＮ、ＳＯｓｔａｒｔ、ＳＯｅｎｄが示されている）の次に他のＮＡＣＫ＿ＳＮエレメントがあるか否かを示す。

５．非確認応答シーケンス番号（ＮＡＣＫ＿ＳＮ）
これは、受信に失敗したＡＭＤ ＰＤＵ又はＡＭＤ ＰＤＵセグメントのＲＬＣ ＳＮである。

６．エクステンション２（Ｅ２）：１ビット
これは、現在のＮＡＣＫ＿ＳＮに対応するＳＯｓｔａｒｔ及びＳＯｅｎｄフィールドがあるか否かを示す。

７．セグメントオフセットスタート(ＳＯｓｔａｒｔ）及びセグメントオフセットエンド(ＳＯｅｎｄ）
これらは、ＮＡＣＫ＿ＳＮを有するＰＤＵの一部分（セグメント）のみがＮＡＣＫの場合に使用する。前記一部分のうち、最初のバイトはＳＯｓｔａｒｔに対応し、最後のバイトはＳＯｅｎｄに対応する。

一方、受信側ＡＭ ＲＬＣは、いつでも状態報告を行うことができるのではなく、特定の条件を満たす場合にのみ状態報告を行うことができる。そのような条件を状態報告トリガといい、現在、ＬＴＥシステムでは次のような２つの条件を使用する。

第１の条件は、送信側のポーリングである。
つまり、送信側ＡＭ ＲＬＣは、受信側から状態報告を受けようとする場合、送信のためにＲＬＣデータＰＤＵにポールビットをセットする。受信側ＡＭ ＲＬＣは、ポールビットがセットされたＲＬＣデータＰＤＵを受信すると、状態報告をトリガする。

第２の条件は、ＲＬＣデータＰＤＵの受信失敗の検出である。
つまり、受信側ＡＭ ＲＬＣは、ＨＡＲＱ再指示（reordering)が完了した後、受信に失敗したＲＬＣデータＰＤＵ（すなわち、ＡＭＤ ＰＤＵ又はＡＭＤ ＰＤＵセグメント）を検出すると、状態報告をトリガする。

さらに、状態報告がトリガされると、受信側ＡＭ ＲＬＣは、状態ＰＤＵを用いて受信バッファの状況を送信側に送信する。このとき、状態ＰＤＵは、受信ウィンドウの開始点を有するＰＤＵ（＝ＶＲ（Ｒ））からＨＡＲＱ再指示が完了したＰＤＵのうち、最後のＰＤＵ（＝ＶＲ（ＭＳ））までの情報を含めて送信する。ここで、ＶＲ（Ｒ）、ＶＲ（ＭＳ）は状態変数であり、受信側ＡＭ ＲＬＣによって管理され、受信ウィンドウや状態報告などのために使用される。とりわけ、受信側ＡＭ ＲＬＣは、他の状態変数も管理する。

受信側ＡＭ ＲＬＣのこのような状態変数について以下に説明する。

ＶＲ（Ｒ）：受信状態変数
順次受信したＡＭＤ ＰＤＵのうちの最後のＡＭＤ ＰＤＵに次ぐＡＭＤ ＰＤＵのシーケンス番号（ＳＮ）の値を有する。
受信側ＡＭ ＲＬＣが受信していないＡＭＤ ＰＤＵのうち、最初のＡＭＤ ＰＤＵである。
受信ウィンドウの開始点となる。
初期値は０に設定されている。ＳＮ＝ＶＲ（Ｒ）を有するＡＭＤ ＰＤＵを完全に受信すると、そのＡＭＤ ＰＤＵの次の完全には受信していない最初のＡＭＤ ＰＤＵのＳＮ値にアップデートされる。

ＶＲ（ＭＲ）：最大許容受信状態変数
受信ウィンドウの外にあるＡＭＤ ＰＤＵのうち、最初のＡＭＤ ＰＤＵのＳＮの値を有する。
受信ウィンドウの終了点（higher edge）となる。
ＶＲ（Ｒ）がアップデートされると、例えばＶＲ（ＭＲ）＝ＶＲ（Ｒ）＋ＡＭ＿Ｗｉｎｄｏｗ＿Ｓｉｚｅのようにアップデートされる。

ＶＲ（Ｘ）：T_reordering 状態変数
ＨＡＲＱ再指示を管理するタイマーであるＴ＿ｒｅｏｒｄｅｒｉｎｇを駆動させたＲＬＣデータＰＤＵの次のＲＬＣデータＰＤＵのＳＮ値である。
駆動中のＴ＿ｒｅｏｒｄｅｒｉｎｇがない状況で受信側ＡＭ ＲＬＣが非順次のＲＬＣデータＰＤＵを受信すると、Ｔ＿ｒｅｏｒｄｅｒｉｎｇを駆動し、ＶＲ（Ｘ）を前記ＲＬＣデータＰＤＵの次のＲＬＣデータＰＤＵのＳＮ値に設定する。

ＶＲ（ＭＳ）：最大状態伝送状態変数
状態ＰＤＵにＨＡＲＱ再指示が完了したＲＬＣデータＰＤＵに関する情報のみを含めるために使用する状態変数である。
初期値は０であり、ＳＮ＝ＶＲ（ＭＳ）に該当するＡＭＤ ＰＤＵを完全に受信すると、その次の受信していない最初のＡＭＤ ＰＤＵのＳＮ値にアップデートされる。
Ｔ＿ｒｅｏｒｄｅｒｉｎｇを過ぎると、ＶＲ（Ｘ）より大きいＡＭＤ ＰＤＵのうち受信していない最初のＡＭＤ ＰＤＵのＳＮ値にアップデートされる。ＡＣＫ＿ＳＮはＶＲ（ＭＳ）に設定され状態ＰＤＵを構成する。

ＶＲ（Ｈ）：最高受信状態変数
受信側ＡＭ ＲＬＣが受信したＲＬＣデータＰＤＵのうち最も高いＳＮ値のすぐ次のＳＮ値、すなわち受信側ＡＭ ＲＬＣが受信していない最初のＲＬＣデータＰＤＵのＳＮ値である。
初期値は０であり、ＶＲ（Ｈ）より大きいＲＬＣデータＰＤＵを受信すると、前記ＲＬＣデータＰＤＵの次のＲＬＣデータＰＤＵのＳＮ値にアップデートされる。

以下、ＭＡＣ層により行われる論理チャネル優先順位付け（ＬＣＰ）について説明する。

様々なＲＢが１つのトランスポートチャネルに多重化されて送信される場合、ＬＴＥ端末は、ＭＡＣ層で送信毎に与えられる無線リソースに対して次のような規則に従って各ＲＢの送信データ量を決定する。

１．まず、多重化されたＲＢに対して、それぞれの論理チャネルの優先順位（Logical Channel Priority；LCP）の降順に送信データ量を決定し、各ＲＢにおいて最大の優先ビットレート（Priority Bit Rate；PBR）に基づいてデータ送信量を決定する。

２．余った無線リソースがある場合、多重化されたＲＢに対して、再びそれぞれのＬＣＰの降順に送信データ量を決定する。
ここで、ＬＣＰは、現在１〜８が議論されており、１が最高、８が最低を意味する。ＰＢＲは、該当ＲＢに対して保証する最小のビットレートであって、無線環境が非常に悪い場合でもＬＴＥシステムがその程度のビットレートを提供できることを意味する。ＰＢＲの範囲は最小の０から無限大まで設定可能である。

一方、各ＲＢのＬＣＰ及びＰＢＲは、ＲＢが初期設定される際、ＲＢ設定メッセージによりネットワークのＲＲＣから端末のＲＲＣに送信される。ＲＢ設定メッセージを受信した端末のＲＲＣは、必要なＲＢを設定し、各ＲＢのＬＣＰ及びＰＢＲに関する情報を端末のＭＡＣに送信する。この情報を受信したＭＡＣは、ＴＴＩ毎に与えられる無線リソースに対して、前記規則に従って各ＲＢの送信量を決定する。

ＭＡＣは、論理チャネル優先順位付け（ＬＣＰ）を行う際、ＬＣＰ及びＰＢＲのみを考慮する。従って、ある論理チャネルにおいては、割り当てられた無線リソースが対応する論理チャネルで送信すべきＲＬＣ状態ＰＤＵに比べて小さいことがある。しかし、受信側ＡＭ ＲＬＣは、状態報告がトリガされると、定められた範囲にあるＡＭＤ ＰＤＵに関する情報を全て状態ＰＤＵに含めて送信することが許される。そのため、状態ＰＤＵを送信する無線リソースが状態ＰＤＵよりも小さい場合、構成された状態ＰＤＵを送信することができない。従来技術においては、このような状況を考慮していなかった。その結果、このような状況が発生した場合、構成したＲＬＣ状態ＰＤＵを送信することができず、こう着状態（deadlock situation）を引き起こす。

そこで、本発明は、論理チャネルに無線リソースを割り当てるためのＭＡＣ層の論理チャネル優先順位付けにおいて、ＭＡＣ層（ＭＡＣエンティティ）が、ＲＬＣ層が送信すべきＲＬＣ状態ＰＤＵのサイズに基づいて無線リソースを割り当てるようにし、かつＲＬＣ層が、割り当てられた無線リソースの使用において、状態ＰＤＵをＲＬＣデータＰＤＵより優先的に使用することにより、ＲＬＣプロトコルが状態ＰＤＵを送信できなくなってこう着状態に陥るのを防止することを目的する。このために、本発明においては、ＭＡＣでの動作とＲＬＣでの動作をそれぞれ次のように提案する。

上記のような従来技術の課題を解決するために、本発明は、ＲＬＣエンティティがＭＡＣエンティティから使用可能なリソースの表示を受信し、前記ＲＬＣエンティティが前記使用可能なリソースの表示を使用して、ＲＬＣデータＰＤＵに対する制御ＰＤＵの送信の優先順位付けを行い、受信した使用可能なリソースを用いて、前記優先順位付けを行ったＲＬＣ ＰＤＵを送信することを特徴とする移動通信システムにおけるＲＬＣ ＰＤＵ送信方法を提供する。

前記ＲＬＣ ＰＤＵ送信方法は、さらに、前記ＲＬＣ制御ＰＤＵに前記使用可能なリソースを優先的に割り当て、前記使用可能なリソースが余った場合、前記ＲＬＣデータＰＤＵに前記余った使用可能なリソースを割り当てることが好ましい。

前記ＲＬＣ ＰＤＵ送信方法は、さらに、前記ＲＬＣ制御ＰＤＵがＲＬＣ状態ＰＤＵであり、前記ＭＡＣエンティティから指示を受けた使用可能なリソースが１つの状態ＰＤＵのサイズよりも小さい場合、前記送信ＲＬＣエンティティがこの送信機会に関して前記状態ＰＤＵの送信をスキップすることが好ましい。

前記ＲＬＣ ＰＤＵ送信方法は、送信時間間隔（Transmission Time Interval；TTI）毎に前記使用可能なリソース及び前記１つの状態ＰＤＵを検査することが好ましい。

前記ＲＬＣ ＰＤＵ送信方法は、さらに、前記ＲＬＣ制御ＰＤＵがＲＬＣ状態ＰＤＵであり、前記ＲＬＣエンティティが、送信時間間隔（ＴＴＩ）毎に送信すべき状態ＰＤＵがあるか否かを検査して、状態ＰＤＵがある場合、前記状態ＰＤＵのサイズを前記ＭＡＣエンティティに通知することが好ましい。

本発明の１つの側面においては、ＲＬＣエンティティが送信する各ＲＬＣ状態ＰＤＵのサイズを考慮して、ＭＡＣエンティティが各論理チャネルに対して前記各ＲＬＣ状態ＰＤＵに優先順位の降順に無線リソースを割り当て、前記各ＲＬＣ状態ＰＤＵに割り当てて余った無線リソースがある場合、前記ＭＡＣエンティティが優先ビットレート（ＰＢＲ）を考慮して優先順位の降順に前記余った無線リソースを割り当て、前記ＭＡＣエンティティがＲＬＣデータＰＤＵに前記余った無線リソースを前記優先順位の降順に割り当てる、移動通信システムにおけるリソース割当方法を提供する。

前記リソース割当方法は、さらに、前記ＲＬＣエンティティがＴＴＩ毎に送信すべき状態ＰＤＵがあるか否かを検査し、状態ＰＤＵがある場合、前記ＭＡＣエンティティが前記状態ＰＤＵのサイズ情報を受信することが好ましい。

本発明の他の側面においては、ＲＬＣエンティティが送信する各ＲＬＣ状態ＰＤＵのサイズ及び論理チャネルの優先ビットレート（ＰＢＲ）を考慮して、ＭＡＣエンティティが各論理チャネルに対して前記各ＲＬＣ状態ＰＤＵに優先順位の降順に無線リソースを割り当て、リソースが余った場合には、前記ＭＡＣエンティティがＲＬＣデータＰＤＵに前記優先順位の降順に余った無線リソースを割り当てる、移動通信システムにおけるリソース割当方法を提供する。

前記リソース割当方法は、さらに、前記ＲＬＣエンティティがＴＴＩ毎に送信すべき状態ＰＤＵがあるか否かを検査し、状態ＰＤＵがある場合、前記ＭＡＣエンティティが前記状態ＰＤＵのサイズ情報を受信することが好ましい。

本発明の１つの側面において、ＭＡＣエンティティからリソースの指示を受信し、ピアＲＬＣエンティティに送信する状態ＰＤＵがあるか否かを確認し、前記受信したリソースのサイズと前記送信する状態ＰＤＵのサイズとを比較し、前記比較の結果、前記リソースが前記状態ＰＤＵより大きいか等しい場合、前記リソースを前記状態ＰＤＵに優先的に割り当てて前記割り当てた状態ＰＤＵを前記ピアＲＬＣエンティティに送信し、前記比較の結果、前記リソースが前記状態ＰＤＵよりも小さい場合、前記状態ＰＤＵの送信をスキップする、モジュールを含むことを特徴とする移動通信システムにおけるＲＬＣエンティティを提供する。

従来技術においては、無線リソースが送信すべき状態ＰＤＵに比べて小さい場合における受信側ＡＭ ＲＬＣの動作方法が定義されておらず、プロトコルのこう着状態をもたらすことがあった。本発明においては、ＭＡＣ層がリソースを割り当てる際、ＲＬＣ状態ＰＤＵのサイズを考慮して割り当て、かつＲＬＣ層がリソースを割り当てる際、ＲＬＣ状態ＰＤＵに優先的に割り当てるようにして、無線状況に関係なくプロトコルを安定して動作させることができる。

従来の移動通信システムであるＬＴＥシステムのネットワーク構造を示す図である。 ３ＧＰＰ無線アクセスネットワーク規格に準拠した端末とＥ−ＵＴＲＡＮ間の無線インタフェースプロトコルの制御プレーンの構造を示す図である。 ３ＧＰＰ無線アクセスネットワーク規格に準拠した端末とＥ−ＵＴＲＡＮ間の無線インタフェースプロトコルのユーザプレーンの構造を示す図である。 現在ＬＴＥシステムで使用されている状態ＰＤＵの構造を示す図である。 本発明の第１実施形態によるＭＡＣ層の論理チャネル優先順位付け処理を示すフローチャートである。 本発明の第２実施形態によるＭＡＣ層の論理チャネル優先順位付け処理を示すフローチャートである。 本発明の第３実施形態によるＲＬＣ層の状態ＰＤＵのサイズを考慮した無線リソース割当方法を示すフローチャートである。

本発明は、移動通信システム、とりわけＬＴＥシステム及びＥ−ＵＭＴＳ（Evolved Universal Mobile Telecommunications System）に適用することができる。しかし、本発明は、これに限定されるものではなく、本発明の技術的思想を適用できる全ての通信システム及び通信プロトコルに適用することができる。本発明は、米国仮出願（６１／０２５，３１１（２００８年２月１日出願）及び６１／０２６，１１９（２００８年２月４日出願））に基づいて優先権を主張するもので、本発明の詳細な説明に上記米国仮出願の内容を援用することがあることを明らかにする。

本発明は、様々な変更が可能であり、様々な実施形態を有するが、特定の実施形態を図面に示して詳細な説明で詳細に説明する。しかし、これは本発明を特定の実施形態に限定するものではなく、本発明の思想及び技術範囲に含まれる全ての変更、均等物乃至代替物を含むものと理解されるべきである。

第１、第２などのように序数を含む用語は様々な構成要素を説明するために使用されるが、前記構成要素は前記用語により限定されるものではない。前記用語は１つの構成要素を他の構成要素と区別する目的でのみ使用される。例えば、本発明の権利範囲から外れない限り、第１構成要素は第２構成要素と命名してもよく、同様に、第２構成要素は第１構成要素と命名してもよい。及び／又はという用語は、複数の関連記載項目の組み合わせ又は複数の関連記載項目のいずれか１つの項目を含む。

ある構成要素が他の構成要素に「連結」又は「接続」されているという場合は、前記他の構成要素に直接的に連結又は接続されていることもあり、中間にさらに他の構成要素が存在することもある。これに対して、ある構成要素が他の構成要素に「直接連結」又は「直接接続」されているという場合は、中間にさらに他の構成要素が存在しないと考えることもできる。

本出願で使用された用語は、単に特定の実施形態を説明するために使用されたもので、本発明を限定するものではない。単数の表現は、文脈上明らかに他の意味を表すものでない限り、複数の表現を含む。本出願において、「含む」や「有する」などの用語は、明細書上に記載された特徴、数字、段階、動作、構成要素、部品、又はこれらの組み合わせが存在することを指定しようとするもので、１つ又はそれ以上の他の特徴、数字、段階、動作、構成要素、部品、又はこれらの組み合わせの存在や付加可能性を予め排除するものであると理解すべきではない。

別途定義されていない限り、技術的な用語や科学的な用語を含めてここで使用される全ての用語は、本発明の属する技術の分野における通常の知識を有する者に一般的に理解される意味と同一の意味を有する。一般的に使用される辞書に定義されているような用語は、関連技術の文脈上の意味と一致する意味を有するものと解釈すべきであり、本出願で明確に定義しない限り、理想的な又は過度に形式的な意味に解釈すべきではない。

以下、添付図面を参照して本発明の好ましい実施形態を詳細に説明する。図面を参照した説明を簡略化するために、図面番号に関係なく、同一の又は対応する構成要素には同一の参照番号を付し、これに関する重複説明は省略する。

本発明は、ある論理チャネルにおいては、割り当てられた無線リソースが対応する論理チャネルで送信すべきＲＬＣ状態ＰＤＵに比べて小さい場合、状態ＰＤＵを生成することができないという点に着目したものである。

このような点に着目した本発明の基本概念は、１）論理チャネルに無線リソースを割り当てるためのＭＡＣ層（ＭＡＣエンティティ）の論理チャネル優先順位付けにおいて、２）ＲＬＣ層が送信すべきＲＬＣ状態ＰＤＵのサイズに基づいて無線リソースを割り当てるようにし、かつ３）ＲＬＣ層の割り当てられた無線リソースの使用において、状態ＰＤＵをＲＬＣデータＰＤＵより優先的に使用するようにすることにより、４）ＲＬＣプロトコルが状態ＰＤＵを送信できなくなってこう着状態に陥ることを防止するというものである。

本発明の第１実施形態及び第２実施形態はＭＡＣ層での動作方法であり、本発明の第３実施形態はＲＬＣ層での動作方法である。一方、本発明の実施形態における無線リソースは、略してリソースといってもよく、状態ＰＤＵを送信するためのリソースであるので送信リソースといってもよい。

また、本発明の第１〜第３実施形態において、状態ＰＤＵは、ＲＬＣエンティティからピアＲＬＣエンティティに送信される。よって、状態ＰＤＵはＲＬＣ状態ＰＤＵであり、本発明の説明においては２つの名称、状態ＰＤＵ及びＲＬＣ状態ＰＤＵを混用する。

以下、本発明の第１実施形態について説明する。
ＭＡＣ層が論理チャネル優先順位付け（ＬＣＰ）処理を行う際、各論理チャネルに対してＲＬＣが生成する状態ＰＤＵのサイズを優先的に考慮する方法である。すなわち、ＬＣＰ処理が行われるとき、最初に各論理チャネルのＲＬＣ状態ＰＤＵのサイズを考慮して各論理チャネルの優先順位の降順に無線リソースを割り当て、その後に従来のＬＣＰ処理を行う。

このような処理の第１実施形態について図５を参照して説明する。
図５は、本発明の第１実施形態によるＭＡＣ層の論理チャネル優先順位付け（ＬＣＰ）処理を示すフローチャートである。図５のＬＣＰ処理はＴＴＩ毎に行われる。

図５を参照すると、ＭＡＣ層（又は、ＭＡＣエンティティ）は、各ＲＬＣエンティティからＲＬＣ状態ＰＤＵのサイズに関する情報（ＲＬＣ状態ＰＤＵサイズ情報）を受信する（Ｓ１）。ＭＡＣ層は、各ＲＬＣエンティティから受信したＲＬＣ状態ＰＤＵサイズ情報を考慮して、各論理チャネルに各論理チャネルの優先順位の降順に無線リソースを割り当てる（Ｓ２）。

前記ステップＳ２で各論理チャネルに無線リソースを割り当てて余った無線リソースがあると（Ｓ３）、構成された各ＰＢＲを考慮して、各論理チャネルに優先順位の降順にその余った無線リソースを割り当てる（Ｓ４）。前記ステップＳ４後に余ったリソースがあると（Ｓ５）、優先順位の降順でデータに余ったリソースを割り当てる（Ｓ６）。

図６は、本発明の第２実施形態によるＭＡＣ層の論理チャネル優先順位付け（ＬＣＰ）処理を示すフローチャートである。図６の実施形態はＭＡＣ層のＬＣＰ処理の他の実施形態である。図６のＬＣＰ処理はＴＴＩ毎に行われる。図５の第１実施形態と比較すると、図６の実施形態は、ＭＡＣ層が論理チャネルを割り当てる際、各状態ＰＤＵのサイズと各ＰＢＲを共に考慮して、ＬＣＰ処理を行う。すなわち、全ての論理チャネルを各ＰＢＲ及び各ＲＬＣ状態ＰＤＵに基づいて論理チャネルの優先順位の降順に割り当てる。

以下、図６を参照して本発明の第２実施形態のＬＣＰ処理について、より詳細に説明する。
ＭＡＣ層（又は、ＭＡＣエンティティ）は、各ＲＬＣエンティティからＲＬＣ状態ＰＤＵのサイズに関する情報（ＲＬＣ状態ＰＤＵサイズ情報）を受信する（Ｓ１１）。ＭＡＣ層は、各ＲＬＣエンティティから受信したＲＬＣ状態ＰＤＵのサイズ情報及び各ＰＢＲに基づいて、各論理チャネルに優先順位の降順に無線リソースを割り当てる（Ｓ１２）。

前記ステップＳ１２後に余ったリソースがあると（Ｓ１３）、優先順位の降順でデータに余ったリソースをさらに割り当てることができる（Ｓ１４）。

一方、本発明の第１及び第２実施形態の場合、各ＴＴＩにおいてＬＣＰ処理中に各論理チャネルのＲＬＣ状態ＰＤＵのサイズを考慮するためには、ＲＬＣエンティティが送信する状態ＰＤＵのサイズをＭＡＣに通知しなければならない。

以上のように、本発明の第１及び第２実施形態においては、ＲＬＣエンティティ及びＭＡＣ層間の相互交信（interaction）により、ＲＬＣ状態ＰＤＵサイズ情報に基づいて各論理チャネルに無線リソースを割り当てる。従って、本発明においては、状態ＰＤＵにデータＰＤＵより優先的に無線リソースを割り当てることができ、状態ＰＤＵをデータＰＤＵより優先的に送信することができる。

以下、本発明の第３実施形態を説明する。
図７は、本発明の第３実施形態による、ＲＬＣ層によって実行される、状態ＰＤＵのサイズに基づいた無線リソース割当方法を示すフローチャートである。

ＭＡＣでの動作をサポートするためには、本発明の第１及び第２実施形態で説明したように、ＲＬＣは、ＴＴＩ毎に送信すべき状態ＰＤＵがあるか否かを検査しなければならず、状態ＰＤＵがあると、前記状態ＰＤＵのサイズをＭＡＣに通知しなければならない。このようなＲＬＣ−ＭＡＣ相互交信は前記ＭＡＣの動作方法を行うために必要である。

一方、これとは別に、ＲＬＣ独自でＲＬＣこう着状態を回避することができる。
つまり、ＲＬＣエンティティがＭＡＣ層から使用可能なリソースに関する情報（表示）を受信し、その使用可能なリソースが状態ＰＤＵのサイズより大きいか等しいと、ＲＬＣエンティティは、状態ＰＤＵをＲＬＣデータＰＤＵより優先的に送信するように、優先順位付けを行う。すなわち、使用可能なリソースを先にＲＬＣ状態ＰＤＵに割り当て、余ったリソースがあると、そのリソースをＲＬＣデータＰＤＵに割り当てる。

また、ＭＡＣから示された使用可能なリソースが状態ＰＤＵよりも小さいと、ＲＬＣエンティティは、この送信機会に状態ＰＤＵの送信を行わない（即ち、状態ＰＤＵの送信をスキップする）。つまり、ＲＬＣエンティティは、最も早い送信機会に、すなわち使用可能なリソースが状態ＰＤＵのサイズより大きいか等しくなったとき、状態ＰＤＵを送信する。

図７を参照すると、ＲＬＣエンティティは、ＭＡＣ層から使用可能なリソースの表示を受信する（Ｓ２１）。前記受信した使用可能なリソースのサイズが、状態ＰＤＵのサイズより大きいか等しいと（Ｓ２２）、ＲＬＣエンティティは、前記無線リソースをＲＬＣ状態ＰＤＵに優先的に割り当てる（Ｓ２３）。そして、ＲＬＣエンティティは、前記状態ＰＤＵに割り当てて余ったリソースがあると、ＲＬＣデータＰＤＵに割り当てる（Ｓ２４）。しかし、無線リソースのサイズが状態ＰＤＵのサイズよりも小さいと（Ｓ２２）、その送信機会においてはＲＬＣ状態ＰＤＵの送信をスキップする。その後、ＲＬＣエンティティは、ＴＴＩ毎に無線リソースのサイズを検査して、無線リソースのサイズが状態ＰＤＵよりも大きいと、状態ＰＤＵを送信する（Ｓ２５）。

以下、本発明によるＲＬＣエンティティについて説明する。
本発明によるＲＬＣエンティティは、ＭＡＣ層から無線リソースの表示を受信し、ピアＲＬＣエンティティに送信する状態ＰＤＵがあるか否かを確認し、前記受信した無線リソースのサイズと前記送信する状態ＰＤＵのサイズとを比較し、前記比較の結果、前記無線リソースが前記状態ＰＤＵより大きいか等しい場合、前記無線リソースを前記状態ＰＤＵに優先的に割り当てて前記割り当てた状態ＰＤＵを前記ピアＲＬＣエンティティに送信し、前記比較の結果、前記無線リソースが前記状態ＰＤＵよりも小さい場合、前記状態ＰＤＵの送信をスキップするモジュールを含む装置である。一方、前記モジュールは、その機能に応じて複数の構成要素を含んでもよい。つまり、前記モジュールは、無線リソースを受信する受信部と、前記無線リソースのサイズと前記送信する状態ＰＤＵのサイズとを比較する比較部と、前記状態ＰＤＵを送信する送信部などを含んでもよい。よって、前記モジュールは、その機能を実行する様々な形態の構成要素で実現できるであろう。

本発明によるＲＬＣエンティティは、前述した構成要素の他に、本発明の技術的思想の実現に必要なソフトウェア及びハードウェア、例えば出力装置（ディスプレイ、スピーカなど）、入力装置（キーパッド、マイクなど）、メモリ、送受信部（ＲＦモジュール、アンテナなど）を基本的に含む。これらの構成要素については、本発明の属する技術の分野における通常の知識を有する者にとって自明な事項であるので、その詳細な説明は省略する。

一方、以上説明した本発明による方法は、ソフトウェア、ハードウェア、又はこれらの組み合わせで実現することができる。例えば、本発明による方法は、記憶媒体（例えば、移動端末機の内部メモリ、フラッシュメモリ、ハードディスクなど）に保存することができ、プロセッサ（例えば、移動端末機内部のマイクロプロセッサ）により実行されるソフトウェアプログラム内にコード又はコマンドで実現することができる。

以上、本発明について、実施形態を参照して説明したが、これは単なる例示にすぎず、当該技術分野における通常の知識を有する者であれば、これらから様々な変形及び均等な他の実施形態が本発明の精神及び範囲を逸脱せずに本発明において実施可能であるという点を理解するであろう。よって、本発明は、添付の特許請求の範囲及びその均等物の範囲内において、本発明の変更や変形を含むものである。

Claims (9)

1. 移動通信システムにおける、無線リンク制御（ＲＬＣ）制御プロトコルデータ単位（ＰＤＵ）とＲＬＣデータＰＤＵとを含むＲＬＣ ＰＤＵ送信方法であって、
   ＲＬＣエンティティが、媒体アクセス制御（ＭＡＣ）エンティティから使用可能なリソースの表示を受信し、
   前記ＲＬＣエンティティが、前記使用可能なリソースの表示を利用して、前記ＲＬＣデータＰＤＵに対する前記ＲＬＣ制御ＰＤＵの送信の優先順位付けを行い、
   前記ＲＬＣエンティティが、前記ＲＬＣデータＰＤＵよりも優先させて前記の優先順位付けを行った前記ＲＬＣ制御ＰＤＵを送信し、
   前記ＲＬＣ制御ＰＤＵは、ＲＬＣ状態ＰＤＵであり、
   さらに、前記ＲＬＣエンティティが、全ての送信時間間隔（ＴＴＩ）毎に、状態ＰＤＵは送信が予定されているか否かを調べ、送信が予定されている場合は、前記ＭＡＣエンティティに前記状態ＰＤＵのサイズを通知し、前記ＭＡＣエンティティに前記状態ＰＤＵのサイズを通知することは、前記ＭＡＣエンティティから使用可能なリソースの表示を受信する前に実行される、
   ことを特徴とする移動通信システムにおけるＲＬＣ ＰＤＵ送信方法。
2. 前記ＲＬＣ制御ＰＤＵに前記使用可能なリソースを割り当て、前記使用可能なリソースが残っている場合、さらに、前記ＲＬＣデータＰＤＵに前記の残っている使用可能なリソースを割り当てる、請求項１に記載の移動通信システムにおけるＲＬＣ ＰＤＵ送信方法。
3. 前記ＭＡＣエンティティから示された使用可能なリソースが１つの状態ＰＤＵのサイズよりも小さい場合、さらに、前記ＲＬＣエンティティは、この送信機会において前記１つの状態ＰＤＵの送信をスキップする、請求項１に記載の移動通信システムにおけるＲＬＣ ＰＤＵ送信方法。
4. 送信時間間隔（ＴＴＩ）毎に前記使用可能なリソース及び前記１つの状態ＰＤＵを検査する、請求項３に記載の移動通信システムにおけるＲＬＣ ＰＤＵ送信方法。
5. 前記ＲＬＣ状態ＰＤＵは、応答モードデータ（ＡＭＤ）ＰＤＵまたはＡＭＤ ＰＤＵの一部の受信成功及び／又は受信失敗の確認を行うために利用される、請求項１に記載の移動通信システムにおけるＲＬＣ ＰＤＵ送信方法。
6. ＭＡＣエンティティから使用可能なリソースの表示を受信し、
   前記使用可能なリソースの表示を利用して、ＲＬＣデータＰＤＵに対するＲＬＣ制御ＰＤＵの送信の優先順位付けを行い、
   前記の優先順位付けを行った前記ＲＬＣ制御ＰＤＵを送信し、
   前記ＲＬＣ制御ＰＤＵは、ＲＬＣ状態ＰＤＵであり、
   さらに、全ての送信時間間隔（ＴＴＩ）毎に、状態ＰＤＵは送信が予定されているか否かを調べ、送信が予定されている場合は、前記ＭＡＣエンティティに前記状態ＰＤＵのサイズを通知し、前記ＭＡＣエンティティに前記状態ＰＤＵのサイズを通知することは、前記ＭＡＣエンティティから使用可能なリソースの表示を受信する前に実行される、
   ように構成されていることを特徴とする移動通信システムにおけるＲＬＣエンティティ。
7. 前記ＲＬＣ制御ＰＤＵに前記使用可能なリソースを割り当て、前記使用可能なリソースが残っている場合、さらに、前記ＲＬＣデータＰＤＵに前記の残っている使用可能なリソースを割り当てるように構成されている、請求項６に記載の移動通信システムにおけるＲＬＣエンティティ。
8. 前記ＭＡＣエンティティから示された使用可能なリソースが１つの状態ＰＤＵのサイズよりも小さい場合、さらに、この送信機会において前記１つの状態ＰＤＵの送信をスキップするように構成されている、請求項７に記載の移動通信システムにおけるＲＬＣエンティティ。
9. 送信時間間隔（ＴＴＩ）毎に前記使用可能なリソース及び前記１つの状態ＰＤＵを検査するように構成されている、請求項８に記載の移動通信システムにおけるＲＬＣエンティティ。

Images