移動通信システムにおけるＰＤＣＰ層の状態報告の送信方法及び受信装置
本発明は、ＬＴＥシステムのＰＤＣＰ層でＰＤＣＰ ＳＤＵの受信状態を相手に報告するＰＤＣＰ状態報告を構成するとき、一連のＰＤＣＰ ＳＤＵの受信成功又は受信失敗をビットマップ形式で送信することにより、無線リソースを低減できるＰＤＣＰ状態報告のためのＰＤＣＰ層の状態報告の送信に関する。好ましくは、前記ＰＤＣＰ ＳＤＵに関する受信状態報告は、ＰＤＣＰ Ｃｏｎｔｒｏｌ ＰＤＵ形態で前記受信側ＰＤＣＰ層から前記送信側ＰＤＣＰ層に送信される。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ＬＴＥ（Long Term Evolution）システムのＰＤＣＰ層においてＰＤＣＰ ＳＤＵの受信状態を相手に報告するＰＤＣＰ状態報告の送信方法に関する。
【背景技術】
【０００２】
図１は、従来の移動通信システムであるＬＴＥシステムのネットワーク構造である。ＬＴＥシステムは、従来のＵＭＴＳシステムから進化したシステムであり、現在３ＧＰＰで基礎的な標準化作業が行われている。
【０００３】
ＬＴＥネットワークは、Ｅ−ＵＴＲＡＮ（Evolved UMTS Terrestrial Radio Access Network）とコアネットワーク（Core Network：ＣＮ）とに分けられる。前記Ｅ−ＵＴＲＡＮは、端末（すなわち、User Equipment：ＵＥ）、基地局（すなわち、eNode B）、及びネットワークのエンドに位置して外部ネットワークに接続される接続ゲートウェイ（Access Gateway：ａＧＷ）から構成される。前記ａＧＷは、ユーザトラフィックを処理する部分と、制御用トラフィックを処理する部分とに分けられる。ここで、新しいユーザトラフィック処理のためのａＧＷと制御用トラフィックを処理するａＧＷは、新しいインタフェースを介して通信できる。１つのｅＮＢには１つ以上のセルが存在する。前記ｅＮＢ間には、ユーザトラフィック又は制御用トラフィックの伝送のためのインタフェースが使用される。前記コアネットワーク（ＣＮ）は、前記ＵＥのユーザ登録のために使用されるノードなどと前記ａＧＷとから構成される。また、前記Ｅ−ＵＴＲＡＮと前記ＣＮを区別するためのインタフェースが使用される。
【０００４】
図２は、３ＧＰＰ無線接続ネットワーク標準に準拠した端末とＥ−ＵＴＲＡＮ間の無線インタフェースプロトコル（Radio Interface Protocol）の制御プレーン構造である。図３は、３ＧＰＰ無線接続ネットワーク標準に準拠した端末とＥ−ＵＴＲＡＮ間の無線インタフェースプロトコルのユーザプレーン構造である。
【０００５】
以下、図２及び図３を参照して端末とＥ−ＵＴＲＡＮ間の無線インタフェースプロトコルの構造を説明する。
【０００６】
無線インタフェースプロトコルは、水平的には物理層、データリンク層、及びネットワーク層からなり、垂直的にはデータ情報送信のためのユーザプレーンと制御信号伝達のための制御プレーンに区分される。図２及び図３のプロトコル層は、通信システム分野において公知の開放型システム間相互接続（ＯＳＩ）基準モデルの下位３層に基づいてＬ１（第１層）、Ｌ２（第２層）、及びＬ３（第３層）に区分される。このような無線プロトコル層は、端末とＥ−ＵＴＲＡＮにペアで存在し、無線区間のデータ送信を担当する。
【０００７】
以下、図２の無線プロトコル制御プレーンと図３の無線プロトコルユーザプレーンの各層を説明する。
【０００８】
第１層である物理層は、物理チャネルを利用して上位層に情報伝送サービスを提供する。物理層は上位の媒体アクセス制御（Medium Access Control：ＭＡＣ）層とトランスポートチャネルで接続され、このトランスポートチャネルを介してＭＡＣ層と物理層間でデータが移動する。ここで、トランスポートチャネルは、チャネルが共有されているか否かによって専用トランスポートチャネルと共用トランスポートチャネルに大別される。さらに、異なる物理層間、すなわち、送信側（送信機）と受信側（受信機）の物理層間では、無線リソースを利用した物理チャネルを介してデータが移動する。
【０００９】
第２層には様々な層が存在する。まず、ＭＡＣ層は、多様な論理チャネルを多様なトランスポートチャネルにマッピングする役割を果たし、また、複数の論理チャネルを１つのトランスポートチャネルにマッピングする論理チャネル多重化の役割を果たす。ＭＡＣ層は、上位層の無線リンク制御（Radio Link Control：ＲＬＣ）層とは論理チャネルで接続され、論理チャネルは、伝送される情報の種類によって制御プレーンの情報を伝送する制御チャネルとユーザプレーンの情報を伝送するトラフィックチャネルに大別される。
【００１０】
第２層のＲＬＣ層は、上位層から受信したデータを分割及び連結して下位層が無線区間のデータ送信に適するようにデータサイズを調節する役割を果たす。また、それぞれの無線ベアラ（Radio Bearer：ＲＢ）が要求する多様なＱｏＳを保証するためにトランスペアレントモード（Transparent Mode：ＴＭ）、無応答モード（Un-acknowledged Mode：ＵＭ）、及び応答モード（Acknowledged Mode：ＡＭ）の３つの動作モードを提供する。特に、ＡＭモードで動作するＲＬＣ層（以下、ＡＭ ＲＬＣ層という）は、信頼性のあるデータ送信のために自動再送要求（Automatic Repeat Request：ＡＲＱ）機能により再送機能を行う。
【００１１】
第２層のパケットデータコンバージェンスプロトコル（Packet Data Convergence Protocol：ＰＤＣＰ）層は、ＩＰｖ４やＩＰｖ６などのＩＰパケットを相対的に帯域幅が小さい無線区間で効率的に伝送するために、相対的に大きくて不要な制御情報を含むＩＰパケットヘッダサイズを小さくするヘッダ圧縮（Header Compression）機能を行う。これは、データのヘッダ部分で必要不可欠な情報のみを伝送するようにして無線区間の伝送効率を増加させる役割を果たす。
【００１２】
第３層の最上部に位置する無線リソース制御（Radio Resource Control：ＲＲＣ）層は、制御プレーンにおいてのみ定義され、無線ベアラ（ＲＢ）の設定、再設定、及び解除に関連して論理チャネル、トランスポートチャネル、及び物理チャネルの制御を担当する。ここで、ＲＢは、端末とＵＴＲＡＮ間のデータ送信のために無線プロトコルの第１及び第２層により提供される論理パスを意味し、一般に、ＲＢの設定とは、特定サービスを提供するために必要なプロトコル層及びチャネルの特性を規定し、それぞれの具体的なパラメータ及び動作方法を設定する過程を意味する。
【００１３】
図４は、ＰＤＣＰエンティティの構造である。以下、前記ＰＤＣＰエンティティについて具体的に説明する。ただし、図４のブロックは、機能ブロックであり、実際とは異なることもある。
【００１４】
前記ＰＤＣＰエンティティは、上向きにはＲＲＣ層又はユーザアプリケーションに接続され、下向きにはＲＬＣ層に接続される。以下、その詳細な構造について説明する。
【００１５】
図４に示す１つのＰＤＣＰエンティティは、送信側及び受信側からなる。左側の送信側は、上位層から受信したＳＤＵをＰＤＵとして構成するか、又は、ＰＤＣＰエンティティ自身が生成した制御情報をＰＤＵとして構成して、受信側のピアＰＤＣＰエンティティに送信する。右側の受信側であるピアＰＤＣＰエンティティは、送信側から受信した前記ＰＤＣＰ ＰＤＵからＰＤＣＰ ＳＤＵ又は制御情報を抽出する。
【００１６】
前述したように、前記ＰＤＣＰエンティティの送信側により生成されたＰＤＵは、Ｄａｔａ ＰＤＵ及びＣｏｎｔｒｏｌ ＰＤＵの２つのタイプがある。まず、ＰＤＣＰ Ｄａｔａ ＰＤＵは、前記上位層から受信した前記ＳＤＵを前記ＰＤＣＰエンティティが加工して形成するデータブロックであり、前記ＰＤＣＰ Ｃｏｎｔｒｏｌ ＰＤＵは、ＰＤＣＰエンティティがピアエンティティに制御情報を送信するためにＰＤＣＰエンティティが独自に生成するデータブロックである。
【００１７】
前記ＰＤＣＰ Ｄａｔａ ＰＤＵは、ユーザプレーン（Ｕ−ｐｌａｎｅ）と制御プレーン（Ｃ−ｐｌａｎｅ）のＲＢにおいて生成され、ＰＤＣＰエンティティの一部機能は、使用するプレーンにより選択的に適用される。すなわち、ヘッダ圧縮機能は、Ｕ−ｐｌａｎｅデータにのみ適用され、セキュリティ機能のうち完全性保護（Integrity Protection）機能は、Ｃ−ｐｌａｎｅデータにのみ適用される。セキュリティ機能には前記完全性保護機能の他にもデータのセキュリティを維持するための暗号化（Ciphering）機能も含まれ、前記暗号化機能は、Ｕ−ｐｌａｎｅデータにもＣ−ｐｌａｎｅデータにも適用される。
【００１８】
前記ＰＤＣＰ Ｃｏｎｔｒｏｌ ＰＤＵは、Ｕ−ｐｌａｎｅ ＲＢにおいてのみ生成され、以下の２つのタイプに大別される。ＰＤＣＰエンティティ受信バッファ状況を前記送信側に通知するための「ＰＤＣＰ状態報告（Status Report）」、及び受信側ヘッダ復元機（Header Decompressor）の状況を送信側ヘッダ圧縮機（Header Compressor）に通知するための「ＨＣ（Header Compression）フィードバックパケット」である。
【００１９】
図５は、ＰＤＣＰエンティティ内における各ＰＤＣＰ ＰＤＵの処理過程を示すブロック図である。
【００２０】
特に、図５は、ＰＤＣＰエンティティにおいて３つのＰＤＣＰ ＰＤＵ（すなわち、ＰＤＣＰ Ｄａｔａ ＰＤＵ、ＰＤＣＰ状態報告のためのＰＤＣＰ Ｃｏｎｔｒｏｌ ＰＤＵ、及びヘッダ圧縮フィードバックのためのＰＤＣＰ Ｃｏｎｔｒｏｌ ＰＤＵ）が経路（１）〜経路（８）を介して処理する過程を示す。以下、各タイプのＰＤＵに対してＰＤＣＰエンティティの処理経路について説明する。
【００２１】
１．ＰＤＣＰエンティティにおいてＰＤＣＰ Ｄａｔａ ＰＤＵの処理過程は、経路（１）、（８）、（３）、及び（７）に関連する。以下、各経路について説明する。
【００２２】
経路（１）：前記送信側ＰＤＣＰは、上位層から受信したＳＤＵに対してヘッダ圧縮及びセキュリティを行った後、ＰＤＣＰシーケンスナンバー（ＳＮ）及びＤａｔａ ＰＤＵであるかＣｏｎｔｒｏｌ ＰＤＵであるかを示すＤ／Ｃフィールドなどをヘッダに加えてＰＤＣＰ Ｄａｔａ ＰＤＵを構成した後、前記受信側ＰＤＣＰエンティティ（すなわち、ピアＰＤＣＰエンティティ）に送信する。ここで、前記ヘッダ圧縮は、ヘッダ圧縮機により行われる。
【００２３】
経路（８）：前記受信側ＰＤＣＰエンティティは、下位層から伝送されたＰＤＣＰ Ｄａｔａ ＰＤＵからヘッダを除去し、セキュリティチェック及びヘッダ復元（Header Decompression）を行ってＰＤＣＰ ＳＤＵを復元して前記上位層に伝送する。前記上位層にＰＤＣＰ ＳＤＵを伝送するときは順に伝送する。前記ＰＤＣＰ ＳＤＵが順序を外れて受信されると、受信バッファにおいて並び替えられた後、上位層に伝送される。ここで、ヘッダ復元は、ヘッダ復元機により行われる。
【００２４】
経路（３）：前記送信側ＰＤＣＰエンティティは、ＨＣフィードバックパケットをＰＤＣＰ Ｄａｔａ ＰＤＵにピギーバックする（例えば、前記ＨＣフィードバックパケットは、前記ＰＤＣＰ Ｄａｔａ ＰＤＵに付加されるか又は含まれて伝送される）。ここで、前記ＨＣフィードバックパケットは、前記送信側ＰＤＣＰエンティティと同位置（co-located）の受信側ＰＤＣＰエンティティのヘッダ復元から情報を受信し、前記上位層から受信した前記ＰＤＣＰ ＳＤＵにヘッダ圧縮を行うときにこの情報を前記ＰＤＣＰ ＳＤＵにピギーバックしてパケットを生成する。その後、ＰＤＣＰ ＳＤＵ及びピギーバックされたＨＣフィードバックパケットに対してセキュリティが行われ、前記ＰＤＣＰ ＳＮやＤ／Ｃフィールドなどがヘッダに付加されてＰＤＣＰ Ｄａｔａ ＰＤＵが生成され、前記送信側ＰＤＣＰエンティティから前記受信側ＰＤＣＰエンティティに送信される。
【００２５】
経路（７）：前記受信側ＰＤＣＰエンティティは、ＰＤＣＰ Ｄａｔａ ＰＤＵを受信すると、まず前記ヘッダを除去し、前記セキュリティチェック及び前記ヘッダ復元を行って前記ＰＤＣＰ ＳＤＵを復元する。ここで、前記ピギーバックされたＨＣフィードバックパケットが存在する場合、これを抽出して同位置の送信側ＰＤＣＰエンティティのヘッダ圧縮に伝送する。前記ＨＣフィードバックパケットを受信すると、前記送信側ＰＤＣＰエンティティのヘッダ圧縮は、前記フィードバック情報により次のパケットをフルヘッダ（full header）に伝送するか圧縮ヘッダに伝送するかを決定することができる。
【００２６】
２．前記ＰＤＣＰエンティティ内におけるＰＤＣＰ状態報告のためのＰＤＣＰ Ｃｏｎｔｒｏｌ ＰＤＵの処理過程は、経路（２）及び（５）に関連する。以下、各経路について説明する。
【００２７】
経路（２）：前記受信側ＰＤＣＰエンティティは、前記受信バッファをチェックして受信されていないＰＤＣＰ ＳＤＵの再送信を送信側ＰＤＣＰエンティティに要求する。ここで、前記受信バッファ状態は、ＰＤＣＰ状態報告として構成され、前記構成されたＰＤＣＰ状態報告は、同位置の送信側ＰＤＣＰエンティティにＣｏｎｔｒｏｌ ＰＤＵの形態で送信される。一方、前記ＰＤＣＰ Ｃｏｎｔｒｏｌ ＰＤＵのヘッダは、ＰＤＵがＤａｔａ ＰＤＵであるかＣｏｎｔｒｏｌ ＰＤＵであるかを示すＤ／Ｃフィールド、及びＣｏｎｔｒｏｌ ＰＤＵがＰＤＣＰ状態報告を含むかＨＣフィードバックパケットを含むかを示すＣＰＴ ＰＤＵ Ｔｙｐｅフィールドなどを含む。
【００２８】
経路（５）：前記受信側ＰＤＣＰエンティティは、前記ＰＤＣＰ状態報告（Status Report）を含むＰＤＣＰ Ｃｏｎｔｒｏｌ ＰＤＵを受信すると、前記受信したＰＤＣＰ状態報告を同位置の送信側ＰＤＣＰエンティティに伝送する。前記同位置の送信側ＰＤＣＰエンティティは、前記ＰＤＣＰ状態報告に基づいて前記受信側ＰＤＣＰエンティティにより受信されていない前記ＰＤＣＰ ＳＤＵを再送信する。
【００２９】
３．前記ＰＤＣＰエンティティ内におけるＨＣフィードバックのためのＰＤＣＰ Ｃｏｎｔｒｏｌ ＰＤＵの処理過程は、経路（４）及び（６）に関連する。以下、各経路について説明する。
【００３０】
経路（４）：前記送信側ＰＤＣＰエンティティは、前記ＨＣフィードバックパケットを前記ＰＤＣＰ Ｄａｔａ ＰＤＵにピギーバックせずに、前記ＰＤＣＰ Ｃｏｎｔｒｏｌ ＰＤＵに含めて独立して送信することができる。ここで、前記ＨＣフィードバックパケットは、前記送信側ＰＤＣＰと同位置の受信側ＰＤＣＰエンティティのヘッダ復元から情報を受信する。前記ＨＣフィードバックパケットは、Ｄ／Ｃフィールド及びＣＰＴフィールドなどが前記ヘッダに加えられて前記ＰＤＣＰ Ｃｏｎｔｒｏｌ ＰＤＵとして構成された後、ピアエンティティとしての受信側ＰＤＣＰエンティティに送信される。
【００３１】
経路（６）：前記受信側ＰＤＣＰエンティティは、前記ＨＣフィードバックを含むＰＤＣＰ Ｃｏｎｔｒｏｌ ＰＤＵを受信すると、これを同位置の送信側ＰＤＣＰエンティティのヘッダ圧縮に送信する。前記ＰＤＣＰ Ｃｏｎｔｒｏｌ ＰＤＵを受信すると、前記送信側ＰＤＣＰエンティティのヘッダ圧縮は、フィードバック情報によって次のパケットをフルヘッダに伝送するか圧縮ヘッダに伝送するかを決定することができる。
【発明の概要】
【課題を解決するための手段】
【００３２】
前述したように、受信側ＰＤＣＰエンティティは、ＰＤＣＰ状態報告を利用して、受信していないＰＤＣＰ ＳＤＵの再送信を送信側ＰＤＣＰエンティティに要求することができる。このために、ＰＤＣＰエンティティは、適切な形態のＰＤＣＰ Ｃｏｎｔｒｏｌ ＰＤＵを構成して相手に送信しなければならないが、送信のために用いられるフォーマットのタイプは、まだ決定されていない。
【００３３】
本発明の目的は、受信側ＰＤＣＰエンティティがＰＤＣＰ状態報告をピアエンティティとしての送信側ＰＤＣＰエンティティに送信するために使用するＰＤＣＰ Ｃｏｎｔｒｏｌ ＰＤＵの形態を定義することにある。このために、本発明においては、ＰＤＣＰエンティティが受信バッファの状況をビットマップ形式で通知する方法を提案する。
【００３４】
このような目的を達成するために、本発明による移動通信システムにおけるＰＤＣＰ層の状態報告の送信方法は、受信側ＰＤＣＰ層が送信側ＰＤＣＰ層に一連のデータに関する状態報告を送信する方法であって、前記受信側ＰＤＣＰ層がＰＤＣＰ ＳＤＵである一連のデータの受信状態を判断する段階と、前記受信側ＰＤＣＰ層が前記送信側ＰＤＣＰ層に前記ＰＤＣＰ ＳＤＵに関する受信状態報告を送信する段階とを含み、前記受信状態報告は、前記ＰＤＣＰ ＳＤＵが正常に受信されたか否かを、前記ＰＤＣＰ ＳＤＵのシーケンスナンバー（ＳＮ）情報を含むビットマップ形式で送信する。
【００３５】
好ましくは、前記ＰＤＣＰ ＳＤＵに関する受信状態報告は、ＰＤＣＰ Ｃｏｎｔｒｏｌ ＰＤＵ形態で前記受信側ＰＤＣＰ層から前記送信側ＰＤＣＰ層に送信される。
【００３６】
好ましくは、前記ＰＤＣＰ Ｃｏｎｔｒｏｌ ＰＤＵは、ＢＩＴＭＡＰフィールドを含む。
【００３７】
好ましくは、前記ＰＤＣＰ Ｃｏｎｔｒｏｌ ＰＤＵは、ＬＳＮ（Last Sequence Number）フィールド又はＦＳＮ（First Sequence Number）フィールドを含む。
【００３８】
好ましくは、前記ＬＳＮフィールドは、前記ＢＩＴＭＡＰフィールドの最後のビットに対応するＰＤＣＰ ＳＤＵのシーケンスナンバー（ＳＮ）を示す。
【００３９】
好ましくは、前記ＦＳＮフィールドは、前記ＢＩＴＭＡＰフィールドの最初のビットに対応するＰＤＣＰ ＳＤＵのシーケンスナンバー（ＳＮ）を示す。
【００４０】
好ましくは、前記ＰＤＣＰ Ｃｏｎｔｒｏｌ ＰＤＵは、長さ（ＬＥＮＧＴＨ）フィールドを含み、前記ＬＥＮＧＴＨフィールドは、前記ビットマップの長さを示す情報を含む。
【００４１】
好ましくは、前記ＢＩＴＭＡＰフィールドは、それぞれの前記ＰＤＣＰ ＳＤＵが正常に受信されているか否かを示すインジケータから構成される。
【００４２】
好ましくは、それぞれの前記インジケータは、１ビットで構成され、前記１ビットが「０」又は「１」に設定されることにより該当ＰＤＣＰ ＳＤＵが正常に受信されているか否かを示す。
【００４３】
また、このような目的を達成するために、本発明による移動通信システムにおける受信装置は、ＰＤＣＰ層を介して受信したＰＤＣＰ ＳＤＵが正常に受信されているか否かを判断し、前記判断した前記ＰＤＣＰ ＳＤＵの受信成功又は受信失敗に関する情報をビットマップ形式で生成し、前記生成したビットマップ形式の情報をＰＤＣＰ Ｃｏｎｔｒｏｌ ＰＤＵに含めて送信する通信モジュールを含む。
【００４４】
好ましくは、前記ＰＤＣＰ Ｃｏｎｔｒｏｌ ＰＤＵは、ＬＳＮフィールド又はＦＳＮフィールドを含み、ここで、前記ＬＳＮフィールドは、前記ＢＩＴＭＡＰフィールドの最後のビットに対応するＰＤＣＰ ＳＤＵのシーケンスナンバー（ＳＮ）を示し、前記ＦＳＮフィールドは、前記ＢＩＴＭＡＰフィールドの最初のビットに対応するＰＤＣＰ ＳＤＵのシーケンスナンバー（ＳＮ）を示す。
【００４５】
好ましくは、前記ＰＤＣＰ Ｃｏｎｔｒｏｌ ＰＤＵは、長さ（ＬＥＮＧＴＨ）フィールドを含み、前記ＬＥＮＧＴＨフィールドは、前記ビットマップの長さを示す情報を含む。
【発明の効果】
【００４６】
本発明は、ＰＤＣＰ層で受信されていないＰＤＣＰ ＳＤＵを再送信できるようにＰＤＣＰ状態報告を送信するとき、効果的に状態報告を構成することによりヘッダのサイズを縮小し、無線リソースの浪費を防止することができるという効果がある。
【図面の簡単な説明】
【００４７】
【図１】従来の移動通信システムであるＬＴＥシステムのネットワーク構造を示す図である。
【図２】３ＧＰＰ無線アクセスネットワーク標準に準拠した端末とＥ−ＵＴＲＡＮ間の無線インタフェースプロトコルの制御プレーン構造を示す図である。
【図３】３ＧＰＰ無線アクセスネットワーク標準に準拠した端末とＥ−ＵＴＲＡＮ間の無線インタフェースプロトコルのユーザプレーン構造を示す図である。
【図４】本発明の一実施形態により、タイマーが満了して受信側が送信側に状態報告を送信する方法を示すブロック図である。
【図５】本発明の一実施形態により、タイマーが駆動されたＰＤＵが受信されると駆動中のタイマーを停止する方法を示すブロック図である。
【図６】Ｌ２プロトコル構造と送信側によるデータの処理順序を示す図である。
【図７】本発明の第１実施形態によるＰＤＣＰ状態報告のためのＰＤＣＰ Ｃｏｎｔｒｏｌ ＰＤＵのフォーマットを示す図である。
【図８】本発明の第２実施形態によるＰＤＣＰ状態報告のためのＰＤＣＰ Ｃｏｎｔｒｏｌ ＰＤＵのフォーマットを示す図である。
【発明を実施するための形態】
【００４８】
本発明は、移動通信システムのＬＴＥシステムに適用され、特に、ＵＭＴＳから進化したＥ−ＵＭＴＳ（Evolved Universal Mobile Telecommunications System）に適用される。しかしながら、本発明は、これに限定されるものではなく、本発明の技術的思想が適用できる全ての通信システム及び通信プロトコルに適用できる。
【００４９】
本発明は、多様な形態で実現することができ、多様な実施形態を有することができ、好ましい実施形態を添付図面に示して詳細に説明する。
【００５０】
本発明は特定実施形態によって限定されるのではなく、むしろ請求の範囲に記載の本発明の思想や範囲内で広く解釈されるべきであり、本発明の請求の範囲内で行われるあらゆる変更及び変形、並びに請求の範囲の均等物は本発明の請求の範囲に含まれる。。
【００５１】
第１、第２などの序数を含む用語は、様々な構成要素を説明するために使用できるが、前記構成要素は、前記用語により限定されるものではない。
【００５２】
前記用語は、１つの構成要素を他の構成要素と区別するために使用されるだけである。例えば、本発明の権利範囲から外れない限り、第１構成要素を第２構成要素ということができ、同様に第２構成要素を第１構成要素ということもできる。「及び／又は」という用語は、複数の関連した記載項目の組み合わせ又は複数の関連した記載項目のいずれかの項目を含む。
【００５３】
ある構成要素が他の構成要素に「連結」又は「接続」されていると言及されたときは、他の構成要素に直接連結又は接続されている可能性もあるが、その構成要素間にさらに他の構成要素が介在することもある。それに対して、ある構成要素が他の構成要素に「直接連結」されているか、「直接接続」されていると言及されたときには、その構成要素間にさらに他の構成要素が存在しないと理解すべきである。
【００５４】
本出願において使用した用語は、単に特定の実施形態を説明するために使用されたものであり、本発明を限定するものではない。単数の表現は文脈上明らかに異なる表現を使用しない限り、複数の表現を含む。本出願において、「含む」又は「有する」などの用語は、明細書に記載された特徴、数字、段階、動作、構成要素、部品又はそれらの組み合わせが存在することを示すものであり、１つ又はそれ以上の他の特徴、数字、段階、動作、構成要素、部品又はそれらの組み合わせの存在又は付加の可能性を予め排除するものではないと理解されるべきである。
【００５５】
他の定義がない限り、技術的又は科学的な用語を含めてここで使用される全ての用語は、本発明の属する技術分野における通常の知識を有する者により一般的に理解されるものと同様の意味を有する。一般に使用される辞書に定義されている用語は、関連技術の文脈上持つ意味と同じ意味を持つものと解釈されるべきであり、本出願において明らかに定義しない限り、過度に形式的な意味には解釈されない。
【００５６】
本発明は、受信側ＰＤＣＰエンティティがＰＤＣＰ状態報告を利用してピアエンティティとしての送信側ＰＤＣＰエンティティから受信されていないＰＤＣＰ ＳＤＵの再送信を要求するとき、ＰＤＣＰ Ｃｏｎｔｒｏｌ ＰＤＵの適したフォーマットが存在しないと認識している。
【００５７】
このような点を考慮して、本発明の基本概念は、１）ＰＤＣＰエンティティが受信バッファの状況をビットマップ形式で通知し、かつ２）前記ビットマップ形式でピアエンティティとしての送信側ＰＤＣＰエンティティに通知するＰＤＣＰ Ｃｏｎｔｒｏｌ ＰＤＵ構造を定義するというものである。３）すなわち、前記受信側ＰＤＣＰエンティティは、それぞれのＰＤＣＰ ＳＤＵの受信状態を１ビットで表現し、受信の成功は１に設定し、受信の失敗は０に設定する。４）特に、受信が成功したか否かは、ＰＤＣＰ ＰＤＵが正常に受信されているか否かにより判断するのではなく、ＰＤＣＰ ＳＤＵが受信されているか否かにより、すなわち、受信されたＰＤＣＰ ＰＤＵに対して復号化（deciphering）及びヘッダ復元を行って得られたＰＤＣＰ ＳＤＵがエラーを有していない場合に受信が成功したと判断する。
【００５８】
本発明において使用される用語のうち、ＰＤＣＰ ＰＤＵのシーケンスナンバー（ＳＮ）とＰＤＣＰ ＳＤＵのＳＮは区別される。以下、図６を参照してＰＤＣＰ ＰＤＵとＰＤＣＰ ＳＤＵの相違点、及び前記ＰＤＣＰ ＰＤＵのＳＮと前記ＰＤＣＰ ＳＤＵのＳＮの相違点について説明する。ただし、図６の内容は、本発明と同一出願人により出願された「大韓民国特許出願番号１０−２００８−００２１１１２（２００８年３月６日出願）（米国仮出願番号６０／８９５７２０（２００７年３月１９日））」の明細書の図５に関する内容を引用したものである。一方、本発明の説明のために、前記出願における他の部分を引用することもできる。
【００５９】
図６は、Ｌ２プロトコル構造及び送信側によるデータの処理順序を示す図である。
【００６０】
図６は、ＬＴＥにおけるＲＬＣ及びＰＤＣＰ層の送信側により上位層から受信されたデータを処理して送信する順序を示す。前記順序は次の通りである。
【００６１】
本発明において使用される用語のうち、ＳＤＵとは、上位層から受信したデータをいい、ＰＤＵとは、上位層から受信されて処理された後に下位層に送信されるデータをいう。
【００６２】
以下、図６を参照して、本発明の説明のために必要な用語、すなわち、前記ＰＤＣＰ ＰＤＵと前記ＰＤＣＰ ＳＤＵの相違点、及び前記ＰＤＣＰ ＰＤＵのＳＮと前記ＰＤＣＰ ＳＤＵのＳＮの相違点について説明する。
【００６３】
Ｓ１１：図６に示すように、前記ＰＤＣＰ層は、下位層に送信されるデータ（ＰＤＣＰ ＳＤＵ）を上位層から受信する。また、前記ＰＤＣＰ層は、それぞれのＰＤＣＰ ＳＤＵに仮想のＳＮを設定する。この場合、前記ＰＤＣＰ ＳＤＵ ＳＮは、前記それぞれのＰＤＣＰ ＳＤＵを区別するために順に設定される。前記過程Ｓ１１は、第１設定モジュールにより行われる。図６のＳ１１で、前記ＳＮが前記ＰＤＣＰ ＳＤＵに実際に付加されるのではなく、異なるＳＮにより区別される一種のポインタ（図示せず）によりそれぞれのＰＤＣＰ ＳＤＵが管理される。このような理由で、過程Ｓ１１における前記ＳＮは仮想のＳＮと表される。さらに、図６のＳ１１で、前記ＰＤＣＰ ＳＤＵの各ＳＮ（すなわち、仮想のＳＮ）を点線で示した。
【００６４】
Ｓ１２：前記ＰＤＣＰ層は、前記それぞれのＰＤＣＰ ＳＤＵをＰＤＣＰ ＳＤＵバッファに保存する。これは、ハンドオーバー中にソース基地局（Source NodeB）がターゲット基地局（Target NodeB）に端末により受信が確認されていないＰＤＣＰ ＳＤＵを送信するためである。
【００６５】
ハンドオーバー中に前記ＰＤＣＰ ＳＤＵが送信又は再送信されるとき、前記ＲＬＣ層又は前記ＰＤＣＰ層の状態報告により、受信側が正常に受信していないＰＤＣＰ ＳＤＵのみが送信又は再送信される。これを選択的送信／再送信（Selective forwarding／retransmission）という。前記過程Ｓ１２は、前記ＰＤＣＰ ＳＤＵバッファにより行われる。２回の仮想ＳＮ設定過程及び３回のＳＤＵバッファリングは、同時に行われてもよい。前記ＰＤＣＰ層が選択的送信／再送信をサポートしない場合、前記ＰＤＣＰ ＳＤＵバッファは提供されないこともある。
【００６６】
Ｓ１３：ヘッダ圧縮機（又は、ヘッダ圧縮モジュールという）は、前記ＰＤＣＰ ＳＤＵに対してヘッダ圧縮を順に行う。この場合、前記ヘッダ圧縮機は、前記ＰＤＣＰ ＳＤＵとは関係のないヘッダ圧縮フィードバックパケットやＰＤＣＰ ＳＴＡＴＵＳ ＰＤＵなどを自ら生成することができる。
【００６７】
Ｓ１４：前記ＰＤＣＰ層は、ヘッダ圧縮されたＰＤＣＰ ＳＤＵを順に暗号化（Ciphering）する。この場合、前記ＰＤＣＰ層は、前記ＰＤＣＰ ＳＤＵをバッファに保存するときに設定された仮想のＰＤＣＰ ＳＮを利用して暗号化を行う。すなわち、前記ＰＤＣＰ ＳＮは、暗号化アルゴリズムにおいて入力パラメータとして作用して各ＳＤＵに異なる暗号化マスクが生成されるようにする役割を果たす。前記過程Ｓ１４は、前記暗号化モジュールにより行われる。前記ＰＤＣＰ層は、前記暗号化動作以外にも、完全性保護（Integrity Protection）機能を含むセキュリティ機能を行う。さらに、前記完全性保護の場合、前記ＰＤＣＰ ＳＤＵは、仮想のＰＤＣＰ ＳＮを利用して完全性が保護される。前記ＰＤＣＰ層は、前記ＰＤＣＰ層により独自に生成されるパケットを含み、前記パケットは、ヘッダ圧縮機により独自に生成されたフィードバックパケットや前記ＰＤＣＰ層により独自に生成されたＰＤＣＰ ＳＴＡＴＵＳ ＰＤＵなどである。前記フィードバックパケット又は、前記ＰＤＣＰ ＳＴＡＴＵＳ ＰＤＵなどは、それらに対応するＰＤＣＰ ＳＤＵ又は設定された仮想のＰＤＣＰ ＳＮがないため、暗号化されない。
【００６８】
Ｓ１５：前記過程（Ｓ１３及びＳ１４）によりヘッダ圧縮されて暗号化されたそれぞれのＰＤＣＰ ＳＤＵに対応する仮想のＰＤＣＰ ＳＮ（すなわち、Ｓ１１で設定されたＳＮ）をＰＤＣＰ ＰＤＵヘッダに付加することによりＰＤＣＰ ＰＤＵを構成する。すなわち、前記ＰＤＣＰ ＰＤＵが前記ＲＬＣ層に送信されるとき、過程Ｓ１１で設定された前記仮想のＰＤＣＰ ＳＮが実際にＰＤＣＰ ＳＮとしてそれぞれのＳＤＵに付加される。前記過程Ｓ１５は、第２設定モジュールにより行われる。
【００６９】
この場合、前記ヘッダ圧縮機により独自に生成されたフィードバックパケット又は前記ＰＤＣＰ層により独自に生成されたＰＤＣＰ ＳＴＡＴＵＳ ＰＤＵなどに対して設定された仮想のＰＤＣＰ ＳＮがないので、前記フィードバックパケット又は前記ＰＤＣＰ ＳＴＡＴＵＳ ＰＤＵは、前記ＰＤＣＰ ＳＮなしに単独でＰＤＣＰ ＰＤＵを構成する。また、前記ＰＤＣＰ層は、前記構成されたＰＤＣＰ ＰＤＵを下位のＲＬＣ層に伝送する。
【００７０】
Ｓ１６：前記ＲＬＣ層は、前記ＰＤＣＰ層から前記ＲＬＣ ＳＤＵ、すなわち、前記ＰＤＣＰ ＰＤＵを受信すると、これを前記ＲＬＣ ＳＤＵバッファに保存する。これは、前記ＲＬＣ層のＰＤＵサイズを柔軟にサポートするためである。
【００７１】
Ｓ１７：前記ＲＬＣ層は、前記ＲＬＣ ＳＤＵを前記ＳＤＵバッファに保存し、前記下位のＭＡＣ層が毎送信時に送信を要求すると、前記ＲＬＣ層は前記要求されたサイズに合わせて必要なだけの前記ＲＬＣ ＳＤＵを分割及び／又は連結する。前記過程Ｓ１７は、分割／連結モジュールにより行われる。
【００７２】
Ｓ１８：前記ＲＬＣ層は、分割及び／又は連結されたデータブロックに順にＲＬＣ ＳＮを付加する。この場合、前記ＲＬＣ層は、前記ＲＬＣ ＳＤＵに関係なくＲＬＣ制御ＰＤＵを独自に生成することができる。前記ＲＬＣ ＳＮが付加されたデータブロック又は前記ＲＬＣ ＳＮのないＲＬＣ制御ＰＤＵは、ＲＬＣ ＰＤＵを構成する。前記過程Ｓ１８は、第３設定モジュールにより行われる。
【００７３】
Ｓ１９：前記ＡＭ ＲＬＣ層は、再送信をサポートするため、前記構成されたＲＬＣ ＰＤＵを前記ＲＬＣ ＰＤＵバッファに保存する。これは、後に必要になる可能性のある再送信のためである。
【００７４】
過程Ｓ１１及びＳ１５における前記ＰＤＣＤ ＳＮと過程Ｓ１８における前記ＲＬＣ ＳＮは、前述したように、その性質が異なる。すなわち、前記ＰＤＣＳ ＳＮは、前記ＰＤＣＰ層において暗号化のために使用され、究極的に前記受信側により受信が確認されていない前記ＰＤＣＰデータのみの送信又は再送信のために使用される。それに対して、前記ＲＬＣ ＳＮは、前記ＲＮＣ層で使用され、前記ＰＤＣＰ ＳＮとは用途が異なる。すなわち、本発明において、前記ＳＤＵが前記上位層から前記ＰＤＣＰ層により受信されるとき、前記ＰＤＣＰ ＳＮは前記ＳＤＵに付けられ、前記ＰＤＣＰ ＳＮが付けられたＳＤＵが前記ＲＬＣ層に伝送されるとき、前記ＲＬＣ ＳＮがさらに付けられる。
【００７５】
以下、添付図面を参照して本発明の好ましい実施形態を詳細に説明する。添付図面において同一又は類似する構成要素には同一の参照番号を付し、これについての同じ説明は省略する。
【００７６】
本発明は、前記受信側ＰＤＣＰエンティティが前記ＰＤＣＰ状態報告をピアエンティティとしての送信側ＰＤＣＰエンティティに送信するために使用するＰＤＣＰ Ｃｏｎｔｒｏｌ ＰＤＵのフォーマットを定義する。このために、本発明は、前記ＰＤＣＰエンティティが受信バッファの状態をビットマップ形式で通知する方法を提案する。
【００７７】
以下、ＰＤＣＰ状態報告に対応するＰＤＣＰ Ｃｏｎｔｒｏｌ ＰＤＵにおけるビットマップのフォーマット（又は、構成）について説明する。前記ビットマップは、少なくとも１ビットで構成される。また、前記ビットマップのそれぞれのビットは、前記ＰＤＣＰ ＳＤＵが正常に受信されているか否か、すなわち、受信状態報告に関する情報を含む。
【００７８】
すなわち、前記受信側ＰＤＣＰエンティティは、それぞれのＰＤＣＰ ＳＤＵの受信状態を１ビットで表現し、受信成功は「１」に設定し、受信失敗は「０」に設定する。ここで、受信が成功したか否かは、前記ＰＤＣＰ ＰＤＵが正常に受信されているか否かにより判断されるのではなく、前記ＰＤＣＰ ＳＤＵが正常に受信されているか否かにより、すなわち、前記受信されたＰＤＣＰ ＰＤＵに復号化及びヘッダ復元を行って得られた前記ＰＤＣＰ ＳＤＵがエラーを有していない場合にＰＤＣＰ ＳＤＵの受信が成功したと判断する。すなわち、前記ＰＤＣＰ状態報告のビットマップの各ビットは、１つのＰＤＣＰ ＳＤＵの受信成功を通知する一種のインジケータの役割を果たす。
【００７９】
ビットマップで特定ビット（これは、前記特定ＳＮを有する前記ＰＤＣＰ ＳＤＵの受信が成功したか否かを示す）を基準に隣接するビットは、隣接するシーケンスナンバーを有する前記ＰＤＣＰ ＳＤＵが正常に受信されているか否かに関する情報を含む。従って、全てのビットマップは、特定範囲内のシーケンスナンバーを有する全てのＰＤＣＰ ＳＤＵの受信状態（すなわち、受信成功又は受信失敗）を示す状態報告である。
【００８０】
しかしながら、各ＰＤＣＰ ＳＤＵの正確なシーケンスナンバーは、ビットマップのみでは認知できない。この正確なシーケンスナンバーを通知するために、前記ビットマップの最初又は最後のＳＤＵに対応するシーケンスナンバーをＰＤＣＰ Ｃｏｎｔｒｏｌ ＰＤＵに付加して送信する。すなわち、前記受信側ＰＤＣＰエンティティが前記ＰＤＣＰ Ｃｏｎｔｒｏｌ ＰＤＵによりＰＤＣＰ ＳＤＵの受信状態をビットマップ形式で前記送信側ＰＤＣＰエンティティに送信する場合、ピアエンティティとしての前記送信側ＰＤＣＰエンティティは、ビットマップのみでは前記受信されたＰＤＣＰ Ｃｏｎｔｒｏｌ ＰＤＵから前記ＰＤＣＰ ＳＤＵが正常に受信されているか否かを判断することができない。従って、前記ビットマップの各ビットが前記ＰＤＣＰ ＳＤＵを示しているか否かを通知する情報が必要である。これを通知するために、前記ビットマップの最初又は最後のビットにより示される前記ＰＤＣＰ ＳＤＵのＳＮ情報が前記ＰＤＣＰ Ｃｏｎｔｒｏｌ ＰＤＵに含まれなければならない。このような前記ＰＤＣＰ ＳＤＵのＳＮ情報は、前記ビットマップの最初のビットに対応するＰＤＣＰ ＳＤＵのＳＮ（図８の「ＦＳＮ」）又は最後のビットに対応するＰＤＣＰ ＳＤＵのＳＮである（図７の「ＬＳＮ」）。
【００８１】
さらに、前記ビットマップの長さを通知する必要がある場合、前記長さを示すＬｅｎｇｔｈフィールドも必要である。
【００８２】
以下、本発明によるＰＤＣＰ状態報告のためのＰＤＣＰ Ｃｏｎｔｒｏｌ ＰＤＵのフォーマットについて図７及び図８を参照して説明する。
【００８３】
図７は、本発明の第１実施形態によるＰＤＣＰ状態報告のためのＰＤＣＰ Ｃｏｎｔｒｏｌ ＰＤＵのフォーマットを示す図である。ここで、図７は、「ＬＳＮ」フィールドを含む実施形態を示す。
【００８４】
図７のＰＤＣＰ Ｃｏｎｔｒｏｌ ＰＤＵのフォーマットは、Ｄ／Ｃフィールド及びＣｏｎｔｒｏｌ ＰＤＵ Ｔｙｐｅフィールド以外にも、ＬＥＮＧＴＨフィールド、ＬＳＮフィールド、及びＢＩＴＭＡＰフィールドを含む。ここで、前記ＬＥＮＧＴＨフィールドは、オプションフィールドであり、前記ＰＤＣＰ Ｃｏｎｔｒｏｌ ＰＤＵに含まれることもあり、含まれないこともある。
【００８５】
前記ＬＥＮＧＴＨフィールドは、前記ビットマップの長さが通知されるべきときに前記ＰＤＣＰ Ｃｏｎｔｒｏｌ ＰＤＵに付加される。前記ビットマップの長さが固定されている場合、又は、前記ＰＤＣＰ Ｃｏｎｔｒｏｌ ＰＤＵの長さから前記ビットマップの長さが得られる場合のように、前記ビットマップの長さを通知する必要がなければ、前記ＬＥＮＧＴＨフィールドは必要ない。
【００８６】
前記ＢＩＴＭＡＰフィールドは、前記受信側ＰＤＣＰエンティティにより前記送信側ＰＤＣＰから受信されて処理されたＰＤＣＰ ＳＤＵがエラーなしに正常に受信されているか否かを示す各ＰＤＣＰ ＳＤＵの受信状態情報を含む。ここで、各ビットマップに対応するそれぞれのＰＤＣＰ ＳＤＵのシーケンスナンバーを正確に通知するために前記ビットマップの最初又は最後のＰＤＣＰ ＳＤＵのＳＮを追加しなければならない。図７においては、前記最後のＰＤＣＰ ＳＤＵのＳＮ（すなわち、ＬＳＮ）が付加される。また、図７は、前記ビットマップの長さを通知する必要がある場合のＰＤＣＰ Ｃｏｎｔｒｏｌ ＰＤＵのフォーマットを示す。
【００８７】
以下、図７における前記ＬＳＮ及び前記ビットマップの設定方法について説明する。
【００８８】
− Ｄ／Ｃ：該当ＰＤＣＰ ＰＤＵがＤａｔａ ＰＤＵであるかＣｏｎｔｒｏｌ ＰＤＵであるかを示すフィールドである。
【００８９】
− Ｃｏｎｔｒｏｌ ＰＤＵ Ｔｙｐｅ：該当制御情報のタイプを示すフィールド、例えば、前記該当制御情報が状態報告であるかＨＣフィードバック情報であるかを示す。
【００９０】
− ＬＳＮフィールド：前記ＢＩＴＭＡＰフィールドの最後のビットに対応するＰＤＣＰ ＳＤＵのＳＮの値を含む。前記受信側ＰＤＣＰエンティティにより最後に受信されたか、又は、受信に失敗したＰＤＣＰ ＳＤＵのＳＮ値である。すなわち、最後のビットに対応する前記ＰＤＣＰ ＳＤＵのＳＮを用いて前記ＢＩＴＭＡＰフィールドの各ビットが示すＰＤＣＰ ＳＤＵのＳＮを把握することができる。これは、前記ビットマップの各ビットが一連のＰＤＣＰ ＳＤＵの受信状態を示すためである。従って、前記最後のビット、すなわち、前記ＬＳＮは、前記ビットマップの最後のビット（最下位ビット）が示す前記ＰＤＣＰ ＳＤＵのＳＮであるので、前記最後のビットの下位ビットが示す該当ＰＤＣＰ ＳＤＵの各ＳＮを認知することができる。このビットマップフォーマットを用いると、前記ＰＤＣＰ状態報告のためのＰＤＣＰ Ｃｏｎｔｒｏｌ ＰＤＵのサイズを小さくすることができ、さらに、無線リソースの効率を向上させることができる。
【００９１】
− ＢＩＴＭＡＰフィールド：ピアエンティティとしての前記送信側ＰＤＣＰエンティティから受信された前記ＰＤＣＰ ＳＤＵの受信状態報告（情報）を含む。前記ＰＤＣＰ ＳＤＵの各受信状態を含むＢＩＴＭＡＰフィールドにおいて、ターゲットＰＤＣＰ ＳＤＵのＳＮは、「ＬＳＮ−ＬＥＮＧＴＨ＊８＋１」と「ＬＳＮ」間の［ＬＳＮ−ＬＥＮＧＴＨ＊８＋１，ＬＳＮ］である。各ビットマップの各ビットは、各ビットが示す前記ＰＤＣＰ ＳＤＵが正常に受信されているか否かに関する受信状態情報（すなわち、ＰＤＣＰ状態報告）を有する。例えば、ＬＳＮ値が「１００」であり、ＬＥＮＧＴＨ値が「５」である場合、前記受信状態報告のターゲットであるＰＤＣＰ ＳＤＵのＳＮの範囲は「６１」〜「１００」である。
【００９２】
前記ビットマップにあるそれぞれのｂｉｔ＿ｐｏｓｉｔｉｏｎは１〜ＬＥＮＧＴＨ＊８であり、例えば、前記ＬＥＮＧＴＨが「５」である場合、各ｂｉｔ＿ｐｏｓｉｔｉｏｎは「１」〜「４０」になる。すなわち、ビットマップにあるビットの数は４０個である。言い換えると、該当ＰＤＣＰ ＳＤＵの受信状態報告（受信成功又は受信失敗）のターゲットになるＰＤＣＰ ＳＤＵの数が４０個である。各ｂｉｔ＿ｐｏｓｉｔｉｏｎの解析方法は、次の通りである。
【００９３】
◆ １：ＰＤＣＰ Ｓｅｑｕｅｎｃｅ Ｎｕｍｂｅｒ＝（ＬＳＮ−ＬＥＮＧＴＨ＊８＋ｂｉｔ＿ｐｏｓｉｔｉｏｎ）であるＰＤＣＰ ＳＤＵの受信成功。
【００９４】
◆ ０：ＰＤＣＰ Ｓｅｑｕｅｎｃｅ Ｎｕｍｂｅｒ＝（ＬＳＮ−ＬＥＮＧＴＨ＊８＋ｂｉｔ＿ｐｏｓｉｔｉｏｎ）であるＰＤＣＰ ＳＤＵの受信失敗。
【００９５】
一方、前記ＬＥＮＧＴＨが「０」である場合は、前記ＢＩＴＭＡＰフィールドは存在しない。この場合、全てのＰＤＣＰ ＳＤＵが正常に受信されていることを考慮すると、前記ＬＳＮのみが含まれる。
【００９６】
図８は、本発明の第２実施形態によるＰＤＣＰ状態報告のためのＰＤＣＰ Ｃｏｎｔｒｏｌ ＰＤＵのフォーマットを示す。ここで、図８は、「ＦＳＮ」フィールドを含む実施形態を示す。以下、図８の実施形態については、図７の実施形態と異なる部分のみを説明する。
【００９７】
図７と比較すると、図８の実施形態は、ＰＤＣＰ ＳＤＵの正確なシーケンスナンバーを通知するために前記ＬＳＮの代わりにＦＳＮを使用する。このＦＳＮは、ビットマップの最初のビットが示すターゲットＰＤＣＰ ＳＤＵのＳＮに対応する。すなわち、前記ビットマップの最初のビットは、前記ＦＳＮが示す前記ＰＤＣＰ ＳＤＵの受信状態報告に関する情報を有する。
【００９８】
さらに、図７と同様に、前記ビットマップの長さが固定されている場合、又は、前記ビットマップの長さが前記ＰＤＣＰ Ｃｏｎｔｒｏｌ ＰＤＵの長さから得られる場合のように、前記ビットマップの長さを通知する必要がなければ、前記ＬＥＮＧＴＨフィールドは必要ない。
【００９９】
前記ＬＳＮの代わりに前記ＦＳＮを使用して前記ＦＳＮ及びビットマップを設定する方法は、図７とは少し異なる点がある。
【０１００】
− ＦＳＮフィールド：
前記ＦＳＮフィールドの値は、前記ＢＩＴＭＡＰフィールドの最初のビットに対応するＰＤＣＰ ＳＤＵのＳＮを示す。
【０１０１】
前記ＦＳＮフィールドの値は、前記受信側ＰＤＣＰエンティティが前記送信側ＰＤＣＰエンティティから受信したＰＤＣＰ ＳＤＵのうち受信していない最初のＰＤＣＰ ＳＤＵのＳＮに対応する。
【０１０２】
− ＢＩＴＭＡＰ：
ピアエンティティとしての送信側ＰＤＣＰエンティティから受信した前記ＰＤＣＰ ＳＤＵの受信状態報告（情報）を含む。
【０１０３】
前記ＢＩＴＭＡＰの範囲は、ＰＤＣＰ ＳＤＵのＳＮが[ＦＳＮ，ＦＳＮ＋ＬＥＮＧＴＨ＊８−１]間にあることを示し、受信の成功又は失敗に関する情報を含む。
【０１０４】
前記ＰＤＣＰ ＳＤＵの各受信状態を有する前記ＢＩＴＭＡＰフィールドにおいて、ターゲットＰＤＣＰ ＳＤＵのＳＮは、「ＦＳＮ」と「ＦＳＮ＋ＬＥＮＧＴＨ＊８−１」間のものである。前記ビットマップの各ビットは、その各ビットが示すＰＤＣＰ ＳＤＵが正常に受信されているか否かに関する受信状態情報（すなわち、ＰＤＣＰ状態報告）を有する。例えば、ＦＳＮ値が「１００」であり、ＬＥＮＧＴＨ値が「５」である場合、受信状態報告のターゲットになるＰＤＣＰ ＳＤＵのＳＮの範囲は「１００」〜「１３９」になる。
【０１０５】
前記ビットマップにおけるそれぞれのｂｉｔ＿ｐｏｓｉｔｉｏｎは、１〜ＬＥＮＧＴＨ＊８であり、例えば、ＬＥＮＧＴＨが「５」である場合、ｂｉｔ＿ｐｏｓｉｔｉｏｎは「１」〜「４０」になる。すなわち、前記ビットマップにおけるビットの数は４０個である。言い換えると、該当ＰＤＣＰ ＳＤＵの受信状態報告（受信成功又は受信失敗）のターゲットになるＰＤＣＰ ＳＤＵの数が４０個である。
【０１０６】
各ｂｉｔ＿ｐｏｓｉｔｉｏｎの解析方法は、次の通りである。
【０１０７】
◆ １：ＰＤＣＰ Ｓｅｑｕｅｎｃｅ Ｎｕｍｂｅｒ＝（ＦＳＮ＋ｂｉｔ＿ｐｏｓｉｔｉｏｎ−１）であるＰＤＣＰ ＳＤＵの受信成功。
【０１０８】
◆ ０：ＰＤＣＰ Ｓｅｑｕｅｎｃｅ Ｎｕｍｂｅｒ＝（ＦＳＮ＋ｂｉｔ＿ｐｏｓｉｔｉｏｎ−１）であるＰＤＣＰ ＳＤＵの受信失敗。
【０１０９】
前記ＬＥＮＧＴＨが「０」である場合、前記ＢＩＴＭＡＰフィールドは存在しない。この場合、全てのＰＤＣＰ ＳＤＵが正常に受信されていることを考慮すると、前記ＦＳＮのみが含まれる。
【０１１０】
図７及び図８の実施形態は、前記受信側ＰＤＣＰエンティティがピアエンティティとしての前記送信側ＰＤＣＰエンティティから受信した一連のデータ（すなわち、ＰＤＣＰ ＳＤＵ）に関する受信状態情報（すなわち、ＰＤＣＰ状態報告）のＰＤＣＰ Ｃｏｎｔｒｏｌ ＰＤＵのフォーマットについて説明している。
【０１１１】
以下、このような一連のデータ（すなわち、ＰＤＣＰ ＳＤＵ）に関する受信状態情報（すなわち、ＰＤＣＰ状態報告）のＰＤＣＰ Ｃｏｎｔｒｏｌ ＰＤＵを送信する方法を整理する。
【０１１２】
前記受信側ＰＤＣＰエンティティは、前記送信側ＰＤＣＰエンティティから受信したＰＤＣＰ ＰＤＵを復号化及びヘッダ復元してＰＤＣＰ ＳＤＵを取得した後、それぞれの前記ＰＤＣＰ ＳＤＵがエラーを有しているか否かを確認して各ＰＤＣＰ ＳＤＵの受信成功又は受信失敗を判断する。
【０１１３】
前記受信側ＰＤＣＰエンティティは、各ＰＤＣＰ ＳＤＵの受信状態（すなわち、受信成功又は受信失敗）を示す各インジケータ（ビットマップの各ビット）を前記ＢＩＴＭＡＰフィールドに加える。
【０１１４】
前記受信側ＰＤＣＰエンティティは、前記ＢＩＴＭＡＰフィールドを含むＰＤＣＰ Ｃｏｎｔｒｏｌ ＰＤＵを構成し、前記構成されたＰＤＣＰ Ｃｏｎｔｒｏｌ ＰＤＵを前記送信側ＰＤＣＰエンティティに送信する。
【０１１５】
一方、前記ＰＤＣＰ Ｃｏｎｔｒｏｌ ＰＤＵは、前記ＢＩＴＭＡＰフィールドのサイズを示すＬＥＮＧＴＨフィールドを含む。
【０１１６】
さらに、前記ＰＤＣＰ Ｃｏｎｔｒｏｌ ＰＤＵは、ＬＳＮフィールド又はＦＳＮフィールドを含む。ここで、前記ＬＳＮフィールドは、前記ＢＩＴＭＡＰフィールドの最後のビットに対応するＰＤＣＰ ＳＤＵのＳＮ情報を有する。前記ＦＳＮフィールドは、前記ＢＩＴＭＡＰフィールドの最初のビット（最上位ビット）に対応するＰＤＣＰ ＳＤＵのＳＮ情報を有する。このように、本発明は、前記ＬＳＮフィールド及び前記ＦＳＮフィールドを利用するため、前記ＢＩＴＭＡＰフィールドの全てのｂｉｔ＿ｐｏｓｉｔｉｏｎに対する該当ＰＤＣＰ ＳＤＵのＳＮを有する必要がなく、前記ＰＤＣＰ Ｃｏｎｔｒｏｌ ＰＤＵのサイズを小さくすると共に、リソースの効率を向上させる。
【０１１７】
以下、本発明による送信機（送信装置）及び受信機（受信装置）について説明する。
【０１１８】
本発明による受信機（受信装置）は、図７及び図８の実施形態を実現できるハードウェア、ソフトウェア、ソフトウェアを含むモジュールなどから構成された装置である。
【０１１９】
本発明による前記装置は、エンティティと言え、本発明による前記装置は、端末とも言える。
【０１２０】
本発明による受信機は、図７及び図８で説明した機能を実行できる通信モジュールを含む。
【０１２１】
すなわち、ＰＤＣＰ層を介して受信した順次的なＰＤＣＰ ＳＤＵのそれぞれに対して受信成功又は受信失敗を判断し、前記判断された結果に関する状態報告をビットマップ形式で生成し、前記生成したビットマップ形式の状態報告を含むＰＤＣＰ Ｃｏｎｔｒｏｌ ＰＤＵを送信する通信モジュールが提供される。
【０１２２】
前記ＰＤＣＰ Ｃｏｎｔｒｏｌ ＰＤＵは、前記ＬＳＮフィールド又は前記ＦＳＮフィールドを含む。ここで、前記ＬＳＮフィールドは、前記ＢＩＴＭＡＰフィールドの最後のビットに対応するＰＤＣＰ ＳＤＵのシーケンスナンバー（ＳＮ）を示し、前記ＦＳＮフィールドは、前記ＢＩＴＭＡＰフィールドの最初のビットに対応するＰＤＣＰ ＳＤＵのシーケンスナンバー（ＳＮ）を示す。
【０１２３】
本発明による送信機（送信装置）は、図７及び図８で説明した機能を実行できる通信モジュールを含む。ここで、この通信モジュールの機能は、図７及び図８で既に説明したので、その詳細な説明を省略する。
【０１２４】
前述したように、本発明による受信機及び送信機は、前述した構成要素以外に本発明の技術的思想を実現するために必要なソフトウェア及びハードウェア、例えば、出力装置（ディスプレイ、スピーカなど）、入力装置（キーパッド、マイクなど）、メモリ、マイクロプロセッサ、送受信部（ＲＦモジュール、アンテナなど）を基本的に含む。このような構成要素に関する詳細な説明は、本発明の技術分野における通常の知識を有する者にとって明らかであるため、省略する。
【０１２５】
前述した方法は、ソフトウェア、ハードウェア、又はそれらの組み合わせで実現することができる。例えば、前述した本発明による方法は、記憶媒体（例えば、端末機の内部メモリ、フラッシュメモリ、ハードディスクなど）に格納することができ、プロセッサ（例えば、移動端末機内部のマイクロプロセッサ）により実行することができるソフトウェアプログラム内のコード又はコマンドで実現することもできる。
【０１２６】
本発明の思想や範囲から外れない限り、当該技術分野における通常の知識を有する者であれば多様な代案、変更、変形が可能であることを理解できるであろう。従って、本発明の請求の範囲及びその均等物の範囲内で行われる変更及び変形は本発明の請求の範囲に含まれる。
【技術分野】
【０００１】
本発明は、ＬＴＥ（Long Term Evolution）システムのＰＤＣＰ層においてＰＤＣＰ ＳＤＵの受信状態を相手に報告するＰＤＣＰ状態報告の送信方法に関する。
【背景技術】
【０００２】
図１は、従来の移動通信システムであるＬＴＥシステムのネットワーク構造である。ＬＴＥシステムは、従来のＵＭＴＳシステムから進化したシステムであり、現在３ＧＰＰで基礎的な標準化作業が行われている。
【０００３】
ＬＴＥネットワークは、Ｅ−ＵＴＲＡＮ（Evolved UMTS Terrestrial Radio Access Network）とコアネットワーク（Core Network：ＣＮ）とに分けられる。前記Ｅ−ＵＴＲＡＮは、端末（すなわち、User Equipment：ＵＥ）、基地局（すなわち、eNode B）、及びネットワークのエンドに位置して外部ネットワークに接続される接続ゲートウェイ（Access Gateway：ａＧＷ）から構成される。前記ａＧＷは、ユーザトラフィックを処理する部分と、制御用トラフィックを処理する部分とに分けられる。ここで、新しいユーザトラフィック処理のためのａＧＷと制御用トラフィックを処理するａＧＷは、新しいインタフェースを介して通信できる。１つのｅＮＢには１つ以上のセルが存在する。前記ｅＮＢ間には、ユーザトラフィック又は制御用トラフィックの伝送のためのインタフェースが使用される。前記コアネットワーク（ＣＮ）は、前記ＵＥのユーザ登録のために使用されるノードなどと前記ａＧＷとから構成される。また、前記Ｅ−ＵＴＲＡＮと前記ＣＮを区別するためのインタフェースが使用される。
【０００４】
図２は、３ＧＰＰ無線接続ネットワーク標準に準拠した端末とＥ−ＵＴＲＡＮ間の無線インタフェースプロトコル（Radio Interface Protocol）の制御プレーン構造である。図３は、３ＧＰＰ無線接続ネットワーク標準に準拠した端末とＥ−ＵＴＲＡＮ間の無線インタフェースプロトコルのユーザプレーン構造である。
【０００５】
以下、図２及び図３を参照して端末とＥ−ＵＴＲＡＮ間の無線インタフェースプロトコルの構造を説明する。
【０００６】
無線インタフェースプロトコルは、水平的には物理層、データリンク層、及びネットワーク層からなり、垂直的にはデータ情報送信のためのユーザプレーンと制御信号伝達のための制御プレーンに区分される。図２及び図３のプロトコル層は、通信システム分野において公知の開放型システム間相互接続（ＯＳＩ）基準モデルの下位３層に基づいてＬ１（第１層）、Ｌ２（第２層）、及びＬ３（第３層）に区分される。このような無線プロトコル層は、端末とＥ−ＵＴＲＡＮにペアで存在し、無線区間のデータ送信を担当する。
【０００７】
以下、図２の無線プロトコル制御プレーンと図３の無線プロトコルユーザプレーンの各層を説明する。
【０００８】
第１層である物理層は、物理チャネルを利用して上位層に情報伝送サービスを提供する。物理層は上位の媒体アクセス制御（Medium Access Control：ＭＡＣ）層とトランスポートチャネルで接続され、このトランスポートチャネルを介してＭＡＣ層と物理層間でデータが移動する。ここで、トランスポートチャネルは、チャネルが共有されているか否かによって専用トランスポートチャネルと共用トランスポートチャネルに大別される。さらに、異なる物理層間、すなわち、送信側（送信機）と受信側（受信機）の物理層間では、無線リソースを利用した物理チャネルを介してデータが移動する。
【０００９】
第２層には様々な層が存在する。まず、ＭＡＣ層は、多様な論理チャネルを多様なトランスポートチャネルにマッピングする役割を果たし、また、複数の論理チャネルを１つのトランスポートチャネルにマッピングする論理チャネル多重化の役割を果たす。ＭＡＣ層は、上位層の無線リンク制御（Radio Link Control：ＲＬＣ）層とは論理チャネルで接続され、論理チャネルは、伝送される情報の種類によって制御プレーンの情報を伝送する制御チャネルとユーザプレーンの情報を伝送するトラフィックチャネルに大別される。
【００１０】
第２層のＲＬＣ層は、上位層から受信したデータを分割及び連結して下位層が無線区間のデータ送信に適するようにデータサイズを調節する役割を果たす。また、それぞれの無線ベアラ（Radio Bearer：ＲＢ）が要求する多様なＱｏＳを保証するためにトランスペアレントモード（Transparent Mode：ＴＭ）、無応答モード（Un-acknowledged Mode：ＵＭ）、及び応答モード（Acknowledged Mode：ＡＭ）の３つの動作モードを提供する。特に、ＡＭモードで動作するＲＬＣ層（以下、ＡＭ ＲＬＣ層という）は、信頼性のあるデータ送信のために自動再送要求（Automatic Repeat Request：ＡＲＱ）機能により再送機能を行う。
【００１１】
第２層のパケットデータコンバージェンスプロトコル（Packet Data Convergence Protocol：ＰＤＣＰ）層は、ＩＰｖ４やＩＰｖ６などのＩＰパケットを相対的に帯域幅が小さい無線区間で効率的に伝送するために、相対的に大きくて不要な制御情報を含むＩＰパケットヘッダサイズを小さくするヘッダ圧縮（Header Compression）機能を行う。これは、データのヘッダ部分で必要不可欠な情報のみを伝送するようにして無線区間の伝送効率を増加させる役割を果たす。
【００１２】
第３層の最上部に位置する無線リソース制御（Radio Resource Control：ＲＲＣ）層は、制御プレーンにおいてのみ定義され、無線ベアラ（ＲＢ）の設定、再設定、及び解除に関連して論理チャネル、トランスポートチャネル、及び物理チャネルの制御を担当する。ここで、ＲＢは、端末とＵＴＲＡＮ間のデータ送信のために無線プロトコルの第１及び第２層により提供される論理パスを意味し、一般に、ＲＢの設定とは、特定サービスを提供するために必要なプロトコル層及びチャネルの特性を規定し、それぞれの具体的なパラメータ及び動作方法を設定する過程を意味する。
【００１３】
図４は、ＰＤＣＰエンティティの構造である。以下、前記ＰＤＣＰエンティティについて具体的に説明する。ただし、図４のブロックは、機能ブロックであり、実際とは異なることもある。
【００１４】
前記ＰＤＣＰエンティティは、上向きにはＲＲＣ層又はユーザアプリケーションに接続され、下向きにはＲＬＣ層に接続される。以下、その詳細な構造について説明する。
【００１５】
図４に示す１つのＰＤＣＰエンティティは、送信側及び受信側からなる。左側の送信側は、上位層から受信したＳＤＵをＰＤＵとして構成するか、又は、ＰＤＣＰエンティティ自身が生成した制御情報をＰＤＵとして構成して、受信側のピアＰＤＣＰエンティティに送信する。右側の受信側であるピアＰＤＣＰエンティティは、送信側から受信した前記ＰＤＣＰ ＰＤＵからＰＤＣＰ ＳＤＵ又は制御情報を抽出する。
【００１６】
前述したように、前記ＰＤＣＰエンティティの送信側により生成されたＰＤＵは、Ｄａｔａ ＰＤＵ及びＣｏｎｔｒｏｌ ＰＤＵの２つのタイプがある。まず、ＰＤＣＰ Ｄａｔａ ＰＤＵは、前記上位層から受信した前記ＳＤＵを前記ＰＤＣＰエンティティが加工して形成するデータブロックであり、前記ＰＤＣＰ Ｃｏｎｔｒｏｌ ＰＤＵは、ＰＤＣＰエンティティがピアエンティティに制御情報を送信するためにＰＤＣＰエンティティが独自に生成するデータブロックである。
【００１７】
前記ＰＤＣＰ Ｄａｔａ ＰＤＵは、ユーザプレーン（Ｕ−ｐｌａｎｅ）と制御プレーン（Ｃ−ｐｌａｎｅ）のＲＢにおいて生成され、ＰＤＣＰエンティティの一部機能は、使用するプレーンにより選択的に適用される。すなわち、ヘッダ圧縮機能は、Ｕ−ｐｌａｎｅデータにのみ適用され、セキュリティ機能のうち完全性保護（Integrity Protection）機能は、Ｃ−ｐｌａｎｅデータにのみ適用される。セキュリティ機能には前記完全性保護機能の他にもデータのセキュリティを維持するための暗号化（Ciphering）機能も含まれ、前記暗号化機能は、Ｕ−ｐｌａｎｅデータにもＣ−ｐｌａｎｅデータにも適用される。
【００１８】
前記ＰＤＣＰ Ｃｏｎｔｒｏｌ ＰＤＵは、Ｕ−ｐｌａｎｅ ＲＢにおいてのみ生成され、以下の２つのタイプに大別される。ＰＤＣＰエンティティ受信バッファ状況を前記送信側に通知するための「ＰＤＣＰ状態報告（Status Report）」、及び受信側ヘッダ復元機（Header Decompressor）の状況を送信側ヘッダ圧縮機（Header Compressor）に通知するための「ＨＣ（Header Compression）フィードバックパケット」である。
【００１９】
図５は、ＰＤＣＰエンティティ内における各ＰＤＣＰ ＰＤＵの処理過程を示すブロック図である。
【００２０】
特に、図５は、ＰＤＣＰエンティティにおいて３つのＰＤＣＰ ＰＤＵ（すなわち、ＰＤＣＰ Ｄａｔａ ＰＤＵ、ＰＤＣＰ状態報告のためのＰＤＣＰ Ｃｏｎｔｒｏｌ ＰＤＵ、及びヘッダ圧縮フィードバックのためのＰＤＣＰ Ｃｏｎｔｒｏｌ ＰＤＵ）が経路（１）〜経路（８）を介して処理する過程を示す。以下、各タイプのＰＤＵに対してＰＤＣＰエンティティの処理経路について説明する。
【００２１】
１．ＰＤＣＰエンティティにおいてＰＤＣＰ Ｄａｔａ ＰＤＵの処理過程は、経路（１）、（８）、（３）、及び（７）に関連する。以下、各経路について説明する。
【００２２】
経路（１）：前記送信側ＰＤＣＰは、上位層から受信したＳＤＵに対してヘッダ圧縮及びセキュリティを行った後、ＰＤＣＰシーケンスナンバー（ＳＮ）及びＤａｔａ ＰＤＵであるかＣｏｎｔｒｏｌ ＰＤＵであるかを示すＤ／Ｃフィールドなどをヘッダに加えてＰＤＣＰ Ｄａｔａ ＰＤＵを構成した後、前記受信側ＰＤＣＰエンティティ（すなわち、ピアＰＤＣＰエンティティ）に送信する。ここで、前記ヘッダ圧縮は、ヘッダ圧縮機により行われる。
【００２３】
経路（８）：前記受信側ＰＤＣＰエンティティは、下位層から伝送されたＰＤＣＰ Ｄａｔａ ＰＤＵからヘッダを除去し、セキュリティチェック及びヘッダ復元（Header Decompression）を行ってＰＤＣＰ ＳＤＵを復元して前記上位層に伝送する。前記上位層にＰＤＣＰ ＳＤＵを伝送するときは順に伝送する。前記ＰＤＣＰ ＳＤＵが順序を外れて受信されると、受信バッファにおいて並び替えられた後、上位層に伝送される。ここで、ヘッダ復元は、ヘッダ復元機により行われる。
【００２４】
経路（３）：前記送信側ＰＤＣＰエンティティは、ＨＣフィードバックパケットをＰＤＣＰ Ｄａｔａ ＰＤＵにピギーバックする（例えば、前記ＨＣフィードバックパケットは、前記ＰＤＣＰ Ｄａｔａ ＰＤＵに付加されるか又は含まれて伝送される）。ここで、前記ＨＣフィードバックパケットは、前記送信側ＰＤＣＰエンティティと同位置（co-located）の受信側ＰＤＣＰエンティティのヘッダ復元から情報を受信し、前記上位層から受信した前記ＰＤＣＰ ＳＤＵにヘッダ圧縮を行うときにこの情報を前記ＰＤＣＰ ＳＤＵにピギーバックしてパケットを生成する。その後、ＰＤＣＰ ＳＤＵ及びピギーバックされたＨＣフィードバックパケットに対してセキュリティが行われ、前記ＰＤＣＰ ＳＮやＤ／Ｃフィールドなどがヘッダに付加されてＰＤＣＰ Ｄａｔａ ＰＤＵが生成され、前記送信側ＰＤＣＰエンティティから前記受信側ＰＤＣＰエンティティに送信される。
【００２５】
経路（７）：前記受信側ＰＤＣＰエンティティは、ＰＤＣＰ Ｄａｔａ ＰＤＵを受信すると、まず前記ヘッダを除去し、前記セキュリティチェック及び前記ヘッダ復元を行って前記ＰＤＣＰ ＳＤＵを復元する。ここで、前記ピギーバックされたＨＣフィードバックパケットが存在する場合、これを抽出して同位置の送信側ＰＤＣＰエンティティのヘッダ圧縮に伝送する。前記ＨＣフィードバックパケットを受信すると、前記送信側ＰＤＣＰエンティティのヘッダ圧縮は、前記フィードバック情報により次のパケットをフルヘッダ（full header）に伝送するか圧縮ヘッダに伝送するかを決定することができる。
【００２６】
２．前記ＰＤＣＰエンティティ内におけるＰＤＣＰ状態報告のためのＰＤＣＰ Ｃｏｎｔｒｏｌ ＰＤＵの処理過程は、経路（２）及び（５）に関連する。以下、各経路について説明する。
【００２７】
経路（２）：前記受信側ＰＤＣＰエンティティは、前記受信バッファをチェックして受信されていないＰＤＣＰ ＳＤＵの再送信を送信側ＰＤＣＰエンティティに要求する。ここで、前記受信バッファ状態は、ＰＤＣＰ状態報告として構成され、前記構成されたＰＤＣＰ状態報告は、同位置の送信側ＰＤＣＰエンティティにＣｏｎｔｒｏｌ ＰＤＵの形態で送信される。一方、前記ＰＤＣＰ Ｃｏｎｔｒｏｌ ＰＤＵのヘッダは、ＰＤＵがＤａｔａ ＰＤＵであるかＣｏｎｔｒｏｌ ＰＤＵであるかを示すＤ／Ｃフィールド、及びＣｏｎｔｒｏｌ ＰＤＵがＰＤＣＰ状態報告を含むかＨＣフィードバックパケットを含むかを示すＣＰＴ ＰＤＵ Ｔｙｐｅフィールドなどを含む。
【００２８】
経路（５）：前記受信側ＰＤＣＰエンティティは、前記ＰＤＣＰ状態報告（Status Report）を含むＰＤＣＰ Ｃｏｎｔｒｏｌ ＰＤＵを受信すると、前記受信したＰＤＣＰ状態報告を同位置の送信側ＰＤＣＰエンティティに伝送する。前記同位置の送信側ＰＤＣＰエンティティは、前記ＰＤＣＰ状態報告に基づいて前記受信側ＰＤＣＰエンティティにより受信されていない前記ＰＤＣＰ ＳＤＵを再送信する。
【００２９】
３．前記ＰＤＣＰエンティティ内におけるＨＣフィードバックのためのＰＤＣＰ Ｃｏｎｔｒｏｌ ＰＤＵの処理過程は、経路（４）及び（６）に関連する。以下、各経路について説明する。
【００３０】
経路（４）：前記送信側ＰＤＣＰエンティティは、前記ＨＣフィードバックパケットを前記ＰＤＣＰ Ｄａｔａ ＰＤＵにピギーバックせずに、前記ＰＤＣＰ Ｃｏｎｔｒｏｌ ＰＤＵに含めて独立して送信することができる。ここで、前記ＨＣフィードバックパケットは、前記送信側ＰＤＣＰと同位置の受信側ＰＤＣＰエンティティのヘッダ復元から情報を受信する。前記ＨＣフィードバックパケットは、Ｄ／Ｃフィールド及びＣＰＴフィールドなどが前記ヘッダに加えられて前記ＰＤＣＰ Ｃｏｎｔｒｏｌ ＰＤＵとして構成された後、ピアエンティティとしての受信側ＰＤＣＰエンティティに送信される。
【００３１】
経路（６）：前記受信側ＰＤＣＰエンティティは、前記ＨＣフィードバックを含むＰＤＣＰ Ｃｏｎｔｒｏｌ ＰＤＵを受信すると、これを同位置の送信側ＰＤＣＰエンティティのヘッダ圧縮に送信する。前記ＰＤＣＰ Ｃｏｎｔｒｏｌ ＰＤＵを受信すると、前記送信側ＰＤＣＰエンティティのヘッダ圧縮は、フィードバック情報によって次のパケットをフルヘッダに伝送するか圧縮ヘッダに伝送するかを決定することができる。
【発明の概要】
【課題を解決するための手段】
【００３２】
前述したように、受信側ＰＤＣＰエンティティは、ＰＤＣＰ状態報告を利用して、受信していないＰＤＣＰ ＳＤＵの再送信を送信側ＰＤＣＰエンティティに要求することができる。このために、ＰＤＣＰエンティティは、適切な形態のＰＤＣＰ Ｃｏｎｔｒｏｌ ＰＤＵを構成して相手に送信しなければならないが、送信のために用いられるフォーマットのタイプは、まだ決定されていない。
【００３３】
本発明の目的は、受信側ＰＤＣＰエンティティがＰＤＣＰ状態報告をピアエンティティとしての送信側ＰＤＣＰエンティティに送信するために使用するＰＤＣＰ Ｃｏｎｔｒｏｌ ＰＤＵの形態を定義することにある。このために、本発明においては、ＰＤＣＰエンティティが受信バッファの状況をビットマップ形式で通知する方法を提案する。
【００３４】
このような目的を達成するために、本発明による移動通信システムにおけるＰＤＣＰ層の状態報告の送信方法は、受信側ＰＤＣＰ層が送信側ＰＤＣＰ層に一連のデータに関する状態報告を送信する方法であって、前記受信側ＰＤＣＰ層がＰＤＣＰ ＳＤＵである一連のデータの受信状態を判断する段階と、前記受信側ＰＤＣＰ層が前記送信側ＰＤＣＰ層に前記ＰＤＣＰ ＳＤＵに関する受信状態報告を送信する段階とを含み、前記受信状態報告は、前記ＰＤＣＰ ＳＤＵが正常に受信されたか否かを、前記ＰＤＣＰ ＳＤＵのシーケンスナンバー（ＳＮ）情報を含むビットマップ形式で送信する。
【００３５】
好ましくは、前記ＰＤＣＰ ＳＤＵに関する受信状態報告は、ＰＤＣＰ Ｃｏｎｔｒｏｌ ＰＤＵ形態で前記受信側ＰＤＣＰ層から前記送信側ＰＤＣＰ層に送信される。
【００３６】
好ましくは、前記ＰＤＣＰ Ｃｏｎｔｒｏｌ ＰＤＵは、ＢＩＴＭＡＰフィールドを含む。
【００３７】
好ましくは、前記ＰＤＣＰ Ｃｏｎｔｒｏｌ ＰＤＵは、ＬＳＮ（Last Sequence Number）フィールド又はＦＳＮ（First Sequence Number）フィールドを含む。
【００３８】
好ましくは、前記ＬＳＮフィールドは、前記ＢＩＴＭＡＰフィールドの最後のビットに対応するＰＤＣＰ ＳＤＵのシーケンスナンバー（ＳＮ）を示す。
【００３９】
好ましくは、前記ＦＳＮフィールドは、前記ＢＩＴＭＡＰフィールドの最初のビットに対応するＰＤＣＰ ＳＤＵのシーケンスナンバー（ＳＮ）を示す。
【００４０】
好ましくは、前記ＰＤＣＰ Ｃｏｎｔｒｏｌ ＰＤＵは、長さ（ＬＥＮＧＴＨ）フィールドを含み、前記ＬＥＮＧＴＨフィールドは、前記ビットマップの長さを示す情報を含む。
【００４１】
好ましくは、前記ＢＩＴＭＡＰフィールドは、それぞれの前記ＰＤＣＰ ＳＤＵが正常に受信されているか否かを示すインジケータから構成される。
【００４２】
好ましくは、それぞれの前記インジケータは、１ビットで構成され、前記１ビットが「０」又は「１」に設定されることにより該当ＰＤＣＰ ＳＤＵが正常に受信されているか否かを示す。
【００４３】
また、このような目的を達成するために、本発明による移動通信システムにおける受信装置は、ＰＤＣＰ層を介して受信したＰＤＣＰ ＳＤＵが正常に受信されているか否かを判断し、前記判断した前記ＰＤＣＰ ＳＤＵの受信成功又は受信失敗に関する情報をビットマップ形式で生成し、前記生成したビットマップ形式の情報をＰＤＣＰ Ｃｏｎｔｒｏｌ ＰＤＵに含めて送信する通信モジュールを含む。
【００４４】
好ましくは、前記ＰＤＣＰ Ｃｏｎｔｒｏｌ ＰＤＵは、ＬＳＮフィールド又はＦＳＮフィールドを含み、ここで、前記ＬＳＮフィールドは、前記ＢＩＴＭＡＰフィールドの最後のビットに対応するＰＤＣＰ ＳＤＵのシーケンスナンバー（ＳＮ）を示し、前記ＦＳＮフィールドは、前記ＢＩＴＭＡＰフィールドの最初のビットに対応するＰＤＣＰ ＳＤＵのシーケンスナンバー（ＳＮ）を示す。
【００４５】
好ましくは、前記ＰＤＣＰ Ｃｏｎｔｒｏｌ ＰＤＵは、長さ（ＬＥＮＧＴＨ）フィールドを含み、前記ＬＥＮＧＴＨフィールドは、前記ビットマップの長さを示す情報を含む。
【発明の効果】
【００４６】
本発明は、ＰＤＣＰ層で受信されていないＰＤＣＰ ＳＤＵを再送信できるようにＰＤＣＰ状態報告を送信するとき、効果的に状態報告を構成することによりヘッダのサイズを縮小し、無線リソースの浪費を防止することができるという効果がある。
【図面の簡単な説明】
【００４７】
【図１】従来の移動通信システムであるＬＴＥシステムのネットワーク構造を示す図である。
【図２】３ＧＰＰ無線アクセスネットワーク標準に準拠した端末とＥ−ＵＴＲＡＮ間の無線インタフェースプロトコルの制御プレーン構造を示す図である。
【図３】３ＧＰＰ無線アクセスネットワーク標準に準拠した端末とＥ−ＵＴＲＡＮ間の無線インタフェースプロトコルのユーザプレーン構造を示す図である。
【図４】本発明の一実施形態により、タイマーが満了して受信側が送信側に状態報告を送信する方法を示すブロック図である。
【図５】本発明の一実施形態により、タイマーが駆動されたＰＤＵが受信されると駆動中のタイマーを停止する方法を示すブロック図である。
【図６】Ｌ２プロトコル構造と送信側によるデータの処理順序を示す図である。
【図７】本発明の第１実施形態によるＰＤＣＰ状態報告のためのＰＤＣＰ Ｃｏｎｔｒｏｌ ＰＤＵのフォーマットを示す図である。
【図８】本発明の第２実施形態によるＰＤＣＰ状態報告のためのＰＤＣＰ Ｃｏｎｔｒｏｌ ＰＤＵのフォーマットを示す図である。
【発明を実施するための形態】
【００４８】
本発明は、移動通信システムのＬＴＥシステムに適用され、特に、ＵＭＴＳから進化したＥ−ＵＭＴＳ（Evolved Universal Mobile Telecommunications System）に適用される。しかしながら、本発明は、これに限定されるものではなく、本発明の技術的思想が適用できる全ての通信システム及び通信プロトコルに適用できる。
【００４９】
本発明は、多様な形態で実現することができ、多様な実施形態を有することができ、好ましい実施形態を添付図面に示して詳細に説明する。
【００５０】
本発明は特定実施形態によって限定されるのではなく、むしろ請求の範囲に記載の本発明の思想や範囲内で広く解釈されるべきであり、本発明の請求の範囲内で行われるあらゆる変更及び変形、並びに請求の範囲の均等物は本発明の請求の範囲に含まれる。。
【００５１】
第１、第２などの序数を含む用語は、様々な構成要素を説明するために使用できるが、前記構成要素は、前記用語により限定されるものではない。
【００５２】
前記用語は、１つの構成要素を他の構成要素と区別するために使用されるだけである。例えば、本発明の権利範囲から外れない限り、第１構成要素を第２構成要素ということができ、同様に第２構成要素を第１構成要素ということもできる。「及び／又は」という用語は、複数の関連した記載項目の組み合わせ又は複数の関連した記載項目のいずれかの項目を含む。
【００５３】
ある構成要素が他の構成要素に「連結」又は「接続」されていると言及されたときは、他の構成要素に直接連結又は接続されている可能性もあるが、その構成要素間にさらに他の構成要素が介在することもある。それに対して、ある構成要素が他の構成要素に「直接連結」されているか、「直接接続」されていると言及されたときには、その構成要素間にさらに他の構成要素が存在しないと理解すべきである。
【００５４】
本出願において使用した用語は、単に特定の実施形態を説明するために使用されたものであり、本発明を限定するものではない。単数の表現は文脈上明らかに異なる表現を使用しない限り、複数の表現を含む。本出願において、「含む」又は「有する」などの用語は、明細書に記載された特徴、数字、段階、動作、構成要素、部品又はそれらの組み合わせが存在することを示すものであり、１つ又はそれ以上の他の特徴、数字、段階、動作、構成要素、部品又はそれらの組み合わせの存在又は付加の可能性を予め排除するものではないと理解されるべきである。
【００５５】
他の定義がない限り、技術的又は科学的な用語を含めてここで使用される全ての用語は、本発明の属する技術分野における通常の知識を有する者により一般的に理解されるものと同様の意味を有する。一般に使用される辞書に定義されている用語は、関連技術の文脈上持つ意味と同じ意味を持つものと解釈されるべきであり、本出願において明らかに定義しない限り、過度に形式的な意味には解釈されない。
【００５６】
本発明は、受信側ＰＤＣＰエンティティがＰＤＣＰ状態報告を利用してピアエンティティとしての送信側ＰＤＣＰエンティティから受信されていないＰＤＣＰ ＳＤＵの再送信を要求するとき、ＰＤＣＰ Ｃｏｎｔｒｏｌ ＰＤＵの適したフォーマットが存在しないと認識している。
【００５７】
このような点を考慮して、本発明の基本概念は、１）ＰＤＣＰエンティティが受信バッファの状況をビットマップ形式で通知し、かつ２）前記ビットマップ形式でピアエンティティとしての送信側ＰＤＣＰエンティティに通知するＰＤＣＰ Ｃｏｎｔｒｏｌ ＰＤＵ構造を定義するというものである。３）すなわち、前記受信側ＰＤＣＰエンティティは、それぞれのＰＤＣＰ ＳＤＵの受信状態を１ビットで表現し、受信の成功は１に設定し、受信の失敗は０に設定する。４）特に、受信が成功したか否かは、ＰＤＣＰ ＰＤＵが正常に受信されているか否かにより判断するのではなく、ＰＤＣＰ ＳＤＵが受信されているか否かにより、すなわち、受信されたＰＤＣＰ ＰＤＵに対して復号化（deciphering）及びヘッダ復元を行って得られたＰＤＣＰ ＳＤＵがエラーを有していない場合に受信が成功したと判断する。
【００５８】
本発明において使用される用語のうち、ＰＤＣＰ ＰＤＵのシーケンスナンバー（ＳＮ）とＰＤＣＰ ＳＤＵのＳＮは区別される。以下、図６を参照してＰＤＣＰ ＰＤＵとＰＤＣＰ ＳＤＵの相違点、及び前記ＰＤＣＰ ＰＤＵのＳＮと前記ＰＤＣＰ ＳＤＵのＳＮの相違点について説明する。ただし、図６の内容は、本発明と同一出願人により出願された「大韓民国特許出願番号１０−２００８−００２１１１２（２００８年３月６日出願）（米国仮出願番号６０／８９５７２０（２００７年３月１９日））」の明細書の図５に関する内容を引用したものである。一方、本発明の説明のために、前記出願における他の部分を引用することもできる。
【００５９】
図６は、Ｌ２プロトコル構造及び送信側によるデータの処理順序を示す図である。
【００６０】
図６は、ＬＴＥにおけるＲＬＣ及びＰＤＣＰ層の送信側により上位層から受信されたデータを処理して送信する順序を示す。前記順序は次の通りである。
【００６１】
本発明において使用される用語のうち、ＳＤＵとは、上位層から受信したデータをいい、ＰＤＵとは、上位層から受信されて処理された後に下位層に送信されるデータをいう。
【００６２】
以下、図６を参照して、本発明の説明のために必要な用語、すなわち、前記ＰＤＣＰ ＰＤＵと前記ＰＤＣＰ ＳＤＵの相違点、及び前記ＰＤＣＰ ＰＤＵのＳＮと前記ＰＤＣＰ ＳＤＵのＳＮの相違点について説明する。
【００６３】
Ｓ１１：図６に示すように、前記ＰＤＣＰ層は、下位層に送信されるデータ（ＰＤＣＰ ＳＤＵ）を上位層から受信する。また、前記ＰＤＣＰ層は、それぞれのＰＤＣＰ ＳＤＵに仮想のＳＮを設定する。この場合、前記ＰＤＣＰ ＳＤＵ ＳＮは、前記それぞれのＰＤＣＰ ＳＤＵを区別するために順に設定される。前記過程Ｓ１１は、第１設定モジュールにより行われる。図６のＳ１１で、前記ＳＮが前記ＰＤＣＰ ＳＤＵに実際に付加されるのではなく、異なるＳＮにより区別される一種のポインタ（図示せず）によりそれぞれのＰＤＣＰ ＳＤＵが管理される。このような理由で、過程Ｓ１１における前記ＳＮは仮想のＳＮと表される。さらに、図６のＳ１１で、前記ＰＤＣＰ ＳＤＵの各ＳＮ（すなわち、仮想のＳＮ）を点線で示した。
【００６４】
Ｓ１２：前記ＰＤＣＰ層は、前記それぞれのＰＤＣＰ ＳＤＵをＰＤＣＰ ＳＤＵバッファに保存する。これは、ハンドオーバー中にソース基地局（Source NodeB）がターゲット基地局（Target NodeB）に端末により受信が確認されていないＰＤＣＰ ＳＤＵを送信するためである。
【００６５】
ハンドオーバー中に前記ＰＤＣＰ ＳＤＵが送信又は再送信されるとき、前記ＲＬＣ層又は前記ＰＤＣＰ層の状態報告により、受信側が正常に受信していないＰＤＣＰ ＳＤＵのみが送信又は再送信される。これを選択的送信／再送信（Selective forwarding／retransmission）という。前記過程Ｓ１２は、前記ＰＤＣＰ ＳＤＵバッファにより行われる。２回の仮想ＳＮ設定過程及び３回のＳＤＵバッファリングは、同時に行われてもよい。前記ＰＤＣＰ層が選択的送信／再送信をサポートしない場合、前記ＰＤＣＰ ＳＤＵバッファは提供されないこともある。
【００６６】
Ｓ１３：ヘッダ圧縮機（又は、ヘッダ圧縮モジュールという）は、前記ＰＤＣＰ ＳＤＵに対してヘッダ圧縮を順に行う。この場合、前記ヘッダ圧縮機は、前記ＰＤＣＰ ＳＤＵとは関係のないヘッダ圧縮フィードバックパケットやＰＤＣＰ ＳＴＡＴＵＳ ＰＤＵなどを自ら生成することができる。
【００６７】
Ｓ１４：前記ＰＤＣＰ層は、ヘッダ圧縮されたＰＤＣＰ ＳＤＵを順に暗号化（Ciphering）する。この場合、前記ＰＤＣＰ層は、前記ＰＤＣＰ ＳＤＵをバッファに保存するときに設定された仮想のＰＤＣＰ ＳＮを利用して暗号化を行う。すなわち、前記ＰＤＣＰ ＳＮは、暗号化アルゴリズムにおいて入力パラメータとして作用して各ＳＤＵに異なる暗号化マスクが生成されるようにする役割を果たす。前記過程Ｓ１４は、前記暗号化モジュールにより行われる。前記ＰＤＣＰ層は、前記暗号化動作以外にも、完全性保護（Integrity Protection）機能を含むセキュリティ機能を行う。さらに、前記完全性保護の場合、前記ＰＤＣＰ ＳＤＵは、仮想のＰＤＣＰ ＳＮを利用して完全性が保護される。前記ＰＤＣＰ層は、前記ＰＤＣＰ層により独自に生成されるパケットを含み、前記パケットは、ヘッダ圧縮機により独自に生成されたフィードバックパケットや前記ＰＤＣＰ層により独自に生成されたＰＤＣＰ ＳＴＡＴＵＳ ＰＤＵなどである。前記フィードバックパケット又は、前記ＰＤＣＰ ＳＴＡＴＵＳ ＰＤＵなどは、それらに対応するＰＤＣＰ ＳＤＵ又は設定された仮想のＰＤＣＰ ＳＮがないため、暗号化されない。
【００６８】
Ｓ１５：前記過程（Ｓ１３及びＳ１４）によりヘッダ圧縮されて暗号化されたそれぞれのＰＤＣＰ ＳＤＵに対応する仮想のＰＤＣＰ ＳＮ（すなわち、Ｓ１１で設定されたＳＮ）をＰＤＣＰ ＰＤＵヘッダに付加することによりＰＤＣＰ ＰＤＵを構成する。すなわち、前記ＰＤＣＰ ＰＤＵが前記ＲＬＣ層に送信されるとき、過程Ｓ１１で設定された前記仮想のＰＤＣＰ ＳＮが実際にＰＤＣＰ ＳＮとしてそれぞれのＳＤＵに付加される。前記過程Ｓ１５は、第２設定モジュールにより行われる。
【００６９】
この場合、前記ヘッダ圧縮機により独自に生成されたフィードバックパケット又は前記ＰＤＣＰ層により独自に生成されたＰＤＣＰ ＳＴＡＴＵＳ ＰＤＵなどに対して設定された仮想のＰＤＣＰ ＳＮがないので、前記フィードバックパケット又は前記ＰＤＣＰ ＳＴＡＴＵＳ ＰＤＵは、前記ＰＤＣＰ ＳＮなしに単独でＰＤＣＰ ＰＤＵを構成する。また、前記ＰＤＣＰ層は、前記構成されたＰＤＣＰ ＰＤＵを下位のＲＬＣ層に伝送する。
【００７０】
Ｓ１６：前記ＲＬＣ層は、前記ＰＤＣＰ層から前記ＲＬＣ ＳＤＵ、すなわち、前記ＰＤＣＰ ＰＤＵを受信すると、これを前記ＲＬＣ ＳＤＵバッファに保存する。これは、前記ＲＬＣ層のＰＤＵサイズを柔軟にサポートするためである。
【００７１】
Ｓ１７：前記ＲＬＣ層は、前記ＲＬＣ ＳＤＵを前記ＳＤＵバッファに保存し、前記下位のＭＡＣ層が毎送信時に送信を要求すると、前記ＲＬＣ層は前記要求されたサイズに合わせて必要なだけの前記ＲＬＣ ＳＤＵを分割及び／又は連結する。前記過程Ｓ１７は、分割／連結モジュールにより行われる。
【００７２】
Ｓ１８：前記ＲＬＣ層は、分割及び／又は連結されたデータブロックに順にＲＬＣ ＳＮを付加する。この場合、前記ＲＬＣ層は、前記ＲＬＣ ＳＤＵに関係なくＲＬＣ制御ＰＤＵを独自に生成することができる。前記ＲＬＣ ＳＮが付加されたデータブロック又は前記ＲＬＣ ＳＮのないＲＬＣ制御ＰＤＵは、ＲＬＣ ＰＤＵを構成する。前記過程Ｓ１８は、第３設定モジュールにより行われる。
【００７３】
Ｓ１９：前記ＡＭ ＲＬＣ層は、再送信をサポートするため、前記構成されたＲＬＣ ＰＤＵを前記ＲＬＣ ＰＤＵバッファに保存する。これは、後に必要になる可能性のある再送信のためである。
【００７４】
過程Ｓ１１及びＳ１５における前記ＰＤＣＤ ＳＮと過程Ｓ１８における前記ＲＬＣ ＳＮは、前述したように、その性質が異なる。すなわち、前記ＰＤＣＳ ＳＮは、前記ＰＤＣＰ層において暗号化のために使用され、究極的に前記受信側により受信が確認されていない前記ＰＤＣＰデータのみの送信又は再送信のために使用される。それに対して、前記ＲＬＣ ＳＮは、前記ＲＮＣ層で使用され、前記ＰＤＣＰ ＳＮとは用途が異なる。すなわち、本発明において、前記ＳＤＵが前記上位層から前記ＰＤＣＰ層により受信されるとき、前記ＰＤＣＰ ＳＮは前記ＳＤＵに付けられ、前記ＰＤＣＰ ＳＮが付けられたＳＤＵが前記ＲＬＣ層に伝送されるとき、前記ＲＬＣ ＳＮがさらに付けられる。
【００７５】
以下、添付図面を参照して本発明の好ましい実施形態を詳細に説明する。添付図面において同一又は類似する構成要素には同一の参照番号を付し、これについての同じ説明は省略する。
【００７６】
本発明は、前記受信側ＰＤＣＰエンティティが前記ＰＤＣＰ状態報告をピアエンティティとしての送信側ＰＤＣＰエンティティに送信するために使用するＰＤＣＰ Ｃｏｎｔｒｏｌ ＰＤＵのフォーマットを定義する。このために、本発明は、前記ＰＤＣＰエンティティが受信バッファの状態をビットマップ形式で通知する方法を提案する。
【００７７】
以下、ＰＤＣＰ状態報告に対応するＰＤＣＰ Ｃｏｎｔｒｏｌ ＰＤＵにおけるビットマップのフォーマット（又は、構成）について説明する。前記ビットマップは、少なくとも１ビットで構成される。また、前記ビットマップのそれぞれのビットは、前記ＰＤＣＰ ＳＤＵが正常に受信されているか否か、すなわち、受信状態報告に関する情報を含む。
【００７８】
すなわち、前記受信側ＰＤＣＰエンティティは、それぞれのＰＤＣＰ ＳＤＵの受信状態を１ビットで表現し、受信成功は「１」に設定し、受信失敗は「０」に設定する。ここで、受信が成功したか否かは、前記ＰＤＣＰ ＰＤＵが正常に受信されているか否かにより判断されるのではなく、前記ＰＤＣＰ ＳＤＵが正常に受信されているか否かにより、すなわち、前記受信されたＰＤＣＰ ＰＤＵに復号化及びヘッダ復元を行って得られた前記ＰＤＣＰ ＳＤＵがエラーを有していない場合にＰＤＣＰ ＳＤＵの受信が成功したと判断する。すなわち、前記ＰＤＣＰ状態報告のビットマップの各ビットは、１つのＰＤＣＰ ＳＤＵの受信成功を通知する一種のインジケータの役割を果たす。
【００７９】
ビットマップで特定ビット（これは、前記特定ＳＮを有する前記ＰＤＣＰ ＳＤＵの受信が成功したか否かを示す）を基準に隣接するビットは、隣接するシーケンスナンバーを有する前記ＰＤＣＰ ＳＤＵが正常に受信されているか否かに関する情報を含む。従って、全てのビットマップは、特定範囲内のシーケンスナンバーを有する全てのＰＤＣＰ ＳＤＵの受信状態（すなわち、受信成功又は受信失敗）を示す状態報告である。
【００８０】
しかしながら、各ＰＤＣＰ ＳＤＵの正確なシーケンスナンバーは、ビットマップのみでは認知できない。この正確なシーケンスナンバーを通知するために、前記ビットマップの最初又は最後のＳＤＵに対応するシーケンスナンバーをＰＤＣＰ Ｃｏｎｔｒｏｌ ＰＤＵに付加して送信する。すなわち、前記受信側ＰＤＣＰエンティティが前記ＰＤＣＰ Ｃｏｎｔｒｏｌ ＰＤＵによりＰＤＣＰ ＳＤＵの受信状態をビットマップ形式で前記送信側ＰＤＣＰエンティティに送信する場合、ピアエンティティとしての前記送信側ＰＤＣＰエンティティは、ビットマップのみでは前記受信されたＰＤＣＰ Ｃｏｎｔｒｏｌ ＰＤＵから前記ＰＤＣＰ ＳＤＵが正常に受信されているか否かを判断することができない。従って、前記ビットマップの各ビットが前記ＰＤＣＰ ＳＤＵを示しているか否かを通知する情報が必要である。これを通知するために、前記ビットマップの最初又は最後のビットにより示される前記ＰＤＣＰ ＳＤＵのＳＮ情報が前記ＰＤＣＰ Ｃｏｎｔｒｏｌ ＰＤＵに含まれなければならない。このような前記ＰＤＣＰ ＳＤＵのＳＮ情報は、前記ビットマップの最初のビットに対応するＰＤＣＰ ＳＤＵのＳＮ（図８の「ＦＳＮ」）又は最後のビットに対応するＰＤＣＰ ＳＤＵのＳＮである（図７の「ＬＳＮ」）。
【００８１】
さらに、前記ビットマップの長さを通知する必要がある場合、前記長さを示すＬｅｎｇｔｈフィールドも必要である。
【００８２】
以下、本発明によるＰＤＣＰ状態報告のためのＰＤＣＰ Ｃｏｎｔｒｏｌ ＰＤＵのフォーマットについて図７及び図８を参照して説明する。
【００８３】
図７は、本発明の第１実施形態によるＰＤＣＰ状態報告のためのＰＤＣＰ Ｃｏｎｔｒｏｌ ＰＤＵのフォーマットを示す図である。ここで、図７は、「ＬＳＮ」フィールドを含む実施形態を示す。
【００８４】
図７のＰＤＣＰ Ｃｏｎｔｒｏｌ ＰＤＵのフォーマットは、Ｄ／Ｃフィールド及びＣｏｎｔｒｏｌ ＰＤＵ Ｔｙｐｅフィールド以外にも、ＬＥＮＧＴＨフィールド、ＬＳＮフィールド、及びＢＩＴＭＡＰフィールドを含む。ここで、前記ＬＥＮＧＴＨフィールドは、オプションフィールドであり、前記ＰＤＣＰ Ｃｏｎｔｒｏｌ ＰＤＵに含まれることもあり、含まれないこともある。
【００８５】
前記ＬＥＮＧＴＨフィールドは、前記ビットマップの長さが通知されるべきときに前記ＰＤＣＰ Ｃｏｎｔｒｏｌ ＰＤＵに付加される。前記ビットマップの長さが固定されている場合、又は、前記ＰＤＣＰ Ｃｏｎｔｒｏｌ ＰＤＵの長さから前記ビットマップの長さが得られる場合のように、前記ビットマップの長さを通知する必要がなければ、前記ＬＥＮＧＴＨフィールドは必要ない。
【００８６】
前記ＢＩＴＭＡＰフィールドは、前記受信側ＰＤＣＰエンティティにより前記送信側ＰＤＣＰから受信されて処理されたＰＤＣＰ ＳＤＵがエラーなしに正常に受信されているか否かを示す各ＰＤＣＰ ＳＤＵの受信状態情報を含む。ここで、各ビットマップに対応するそれぞれのＰＤＣＰ ＳＤＵのシーケンスナンバーを正確に通知するために前記ビットマップの最初又は最後のＰＤＣＰ ＳＤＵのＳＮを追加しなければならない。図７においては、前記最後のＰＤＣＰ ＳＤＵのＳＮ（すなわち、ＬＳＮ）が付加される。また、図７は、前記ビットマップの長さを通知する必要がある場合のＰＤＣＰ Ｃｏｎｔｒｏｌ ＰＤＵのフォーマットを示す。
【００８７】
以下、図７における前記ＬＳＮ及び前記ビットマップの設定方法について説明する。
【００８８】
− Ｄ／Ｃ：該当ＰＤＣＰ ＰＤＵがＤａｔａ ＰＤＵであるかＣｏｎｔｒｏｌ ＰＤＵであるかを示すフィールドである。
【００８９】
− Ｃｏｎｔｒｏｌ ＰＤＵ Ｔｙｐｅ：該当制御情報のタイプを示すフィールド、例えば、前記該当制御情報が状態報告であるかＨＣフィードバック情報であるかを示す。
【００９０】
− ＬＳＮフィールド：前記ＢＩＴＭＡＰフィールドの最後のビットに対応するＰＤＣＰ ＳＤＵのＳＮの値を含む。前記受信側ＰＤＣＰエンティティにより最後に受信されたか、又は、受信に失敗したＰＤＣＰ ＳＤＵのＳＮ値である。すなわち、最後のビットに対応する前記ＰＤＣＰ ＳＤＵのＳＮを用いて前記ＢＩＴＭＡＰフィールドの各ビットが示すＰＤＣＰ ＳＤＵのＳＮを把握することができる。これは、前記ビットマップの各ビットが一連のＰＤＣＰ ＳＤＵの受信状態を示すためである。従って、前記最後のビット、すなわち、前記ＬＳＮは、前記ビットマップの最後のビット（最下位ビット）が示す前記ＰＤＣＰ ＳＤＵのＳＮであるので、前記最後のビットの下位ビットが示す該当ＰＤＣＰ ＳＤＵの各ＳＮを認知することができる。このビットマップフォーマットを用いると、前記ＰＤＣＰ状態報告のためのＰＤＣＰ Ｃｏｎｔｒｏｌ ＰＤＵのサイズを小さくすることができ、さらに、無線リソースの効率を向上させることができる。
【００９１】
− ＢＩＴＭＡＰフィールド：ピアエンティティとしての前記送信側ＰＤＣＰエンティティから受信された前記ＰＤＣＰ ＳＤＵの受信状態報告（情報）を含む。前記ＰＤＣＰ ＳＤＵの各受信状態を含むＢＩＴＭＡＰフィールドにおいて、ターゲットＰＤＣＰ ＳＤＵのＳＮは、「ＬＳＮ−ＬＥＮＧＴＨ＊８＋１」と「ＬＳＮ」間の［ＬＳＮ−ＬＥＮＧＴＨ＊８＋１，ＬＳＮ］である。各ビットマップの各ビットは、各ビットが示す前記ＰＤＣＰ ＳＤＵが正常に受信されているか否かに関する受信状態情報（すなわち、ＰＤＣＰ状態報告）を有する。例えば、ＬＳＮ値が「１００」であり、ＬＥＮＧＴＨ値が「５」である場合、前記受信状態報告のターゲットであるＰＤＣＰ ＳＤＵのＳＮの範囲は「６１」〜「１００」である。
【００９２】
前記ビットマップにあるそれぞれのｂｉｔ＿ｐｏｓｉｔｉｏｎは１〜ＬＥＮＧＴＨ＊８であり、例えば、前記ＬＥＮＧＴＨが「５」である場合、各ｂｉｔ＿ｐｏｓｉｔｉｏｎは「１」〜「４０」になる。すなわち、ビットマップにあるビットの数は４０個である。言い換えると、該当ＰＤＣＰ ＳＤＵの受信状態報告（受信成功又は受信失敗）のターゲットになるＰＤＣＰ ＳＤＵの数が４０個である。各ｂｉｔ＿ｐｏｓｉｔｉｏｎの解析方法は、次の通りである。
【００９３】
◆ １：ＰＤＣＰ Ｓｅｑｕｅｎｃｅ Ｎｕｍｂｅｒ＝（ＬＳＮ−ＬＥＮＧＴＨ＊８＋ｂｉｔ＿ｐｏｓｉｔｉｏｎ）であるＰＤＣＰ ＳＤＵの受信成功。
【００９４】
◆ ０：ＰＤＣＰ Ｓｅｑｕｅｎｃｅ Ｎｕｍｂｅｒ＝（ＬＳＮ−ＬＥＮＧＴＨ＊８＋ｂｉｔ＿ｐｏｓｉｔｉｏｎ）であるＰＤＣＰ ＳＤＵの受信失敗。
【００９５】
一方、前記ＬＥＮＧＴＨが「０」である場合は、前記ＢＩＴＭＡＰフィールドは存在しない。この場合、全てのＰＤＣＰ ＳＤＵが正常に受信されていることを考慮すると、前記ＬＳＮのみが含まれる。
【００９６】
図８は、本発明の第２実施形態によるＰＤＣＰ状態報告のためのＰＤＣＰ Ｃｏｎｔｒｏｌ ＰＤＵのフォーマットを示す。ここで、図８は、「ＦＳＮ」フィールドを含む実施形態を示す。以下、図８の実施形態については、図７の実施形態と異なる部分のみを説明する。
【００９７】
図７と比較すると、図８の実施形態は、ＰＤＣＰ ＳＤＵの正確なシーケンスナンバーを通知するために前記ＬＳＮの代わりにＦＳＮを使用する。このＦＳＮは、ビットマップの最初のビットが示すターゲットＰＤＣＰ ＳＤＵのＳＮに対応する。すなわち、前記ビットマップの最初のビットは、前記ＦＳＮが示す前記ＰＤＣＰ ＳＤＵの受信状態報告に関する情報を有する。
【００９８】
さらに、図７と同様に、前記ビットマップの長さが固定されている場合、又は、前記ビットマップの長さが前記ＰＤＣＰ Ｃｏｎｔｒｏｌ ＰＤＵの長さから得られる場合のように、前記ビットマップの長さを通知する必要がなければ、前記ＬＥＮＧＴＨフィールドは必要ない。
【００９９】
前記ＬＳＮの代わりに前記ＦＳＮを使用して前記ＦＳＮ及びビットマップを設定する方法は、図７とは少し異なる点がある。
【０１００】
− ＦＳＮフィールド：
前記ＦＳＮフィールドの値は、前記ＢＩＴＭＡＰフィールドの最初のビットに対応するＰＤＣＰ ＳＤＵのＳＮを示す。
【０１０１】
前記ＦＳＮフィールドの値は、前記受信側ＰＤＣＰエンティティが前記送信側ＰＤＣＰエンティティから受信したＰＤＣＰ ＳＤＵのうち受信していない最初のＰＤＣＰ ＳＤＵのＳＮに対応する。
【０１０２】
− ＢＩＴＭＡＰ：
ピアエンティティとしての送信側ＰＤＣＰエンティティから受信した前記ＰＤＣＰ ＳＤＵの受信状態報告（情報）を含む。
【０１０３】
前記ＢＩＴＭＡＰの範囲は、ＰＤＣＰ ＳＤＵのＳＮが[ＦＳＮ，ＦＳＮ＋ＬＥＮＧＴＨ＊８−１]間にあることを示し、受信の成功又は失敗に関する情報を含む。
【０１０４】
前記ＰＤＣＰ ＳＤＵの各受信状態を有する前記ＢＩＴＭＡＰフィールドにおいて、ターゲットＰＤＣＰ ＳＤＵのＳＮは、「ＦＳＮ」と「ＦＳＮ＋ＬＥＮＧＴＨ＊８−１」間のものである。前記ビットマップの各ビットは、その各ビットが示すＰＤＣＰ ＳＤＵが正常に受信されているか否かに関する受信状態情報（すなわち、ＰＤＣＰ状態報告）を有する。例えば、ＦＳＮ値が「１００」であり、ＬＥＮＧＴＨ値が「５」である場合、受信状態報告のターゲットになるＰＤＣＰ ＳＤＵのＳＮの範囲は「１００」〜「１３９」になる。
【０１０５】
前記ビットマップにおけるそれぞれのｂｉｔ＿ｐｏｓｉｔｉｏｎは、１〜ＬＥＮＧＴＨ＊８であり、例えば、ＬＥＮＧＴＨが「５」である場合、ｂｉｔ＿ｐｏｓｉｔｉｏｎは「１」〜「４０」になる。すなわち、前記ビットマップにおけるビットの数は４０個である。言い換えると、該当ＰＤＣＰ ＳＤＵの受信状態報告（受信成功又は受信失敗）のターゲットになるＰＤＣＰ ＳＤＵの数が４０個である。
【０１０６】
各ｂｉｔ＿ｐｏｓｉｔｉｏｎの解析方法は、次の通りである。
【０１０７】
◆ １：ＰＤＣＰ Ｓｅｑｕｅｎｃｅ Ｎｕｍｂｅｒ＝（ＦＳＮ＋ｂｉｔ＿ｐｏｓｉｔｉｏｎ−１）であるＰＤＣＰ ＳＤＵの受信成功。
【０１０８】
◆ ０：ＰＤＣＰ Ｓｅｑｕｅｎｃｅ Ｎｕｍｂｅｒ＝（ＦＳＮ＋ｂｉｔ＿ｐｏｓｉｔｉｏｎ−１）であるＰＤＣＰ ＳＤＵの受信失敗。
【０１０９】
前記ＬＥＮＧＴＨが「０」である場合、前記ＢＩＴＭＡＰフィールドは存在しない。この場合、全てのＰＤＣＰ ＳＤＵが正常に受信されていることを考慮すると、前記ＦＳＮのみが含まれる。
【０１１０】
図７及び図８の実施形態は、前記受信側ＰＤＣＰエンティティがピアエンティティとしての前記送信側ＰＤＣＰエンティティから受信した一連のデータ（すなわち、ＰＤＣＰ ＳＤＵ）に関する受信状態情報（すなわち、ＰＤＣＰ状態報告）のＰＤＣＰ Ｃｏｎｔｒｏｌ ＰＤＵのフォーマットについて説明している。
【０１１１】
以下、このような一連のデータ（すなわち、ＰＤＣＰ ＳＤＵ）に関する受信状態情報（すなわち、ＰＤＣＰ状態報告）のＰＤＣＰ Ｃｏｎｔｒｏｌ ＰＤＵを送信する方法を整理する。
【０１１２】
前記受信側ＰＤＣＰエンティティは、前記送信側ＰＤＣＰエンティティから受信したＰＤＣＰ ＰＤＵを復号化及びヘッダ復元してＰＤＣＰ ＳＤＵを取得した後、それぞれの前記ＰＤＣＰ ＳＤＵがエラーを有しているか否かを確認して各ＰＤＣＰ ＳＤＵの受信成功又は受信失敗を判断する。
【０１１３】
前記受信側ＰＤＣＰエンティティは、各ＰＤＣＰ ＳＤＵの受信状態（すなわち、受信成功又は受信失敗）を示す各インジケータ（ビットマップの各ビット）を前記ＢＩＴＭＡＰフィールドに加える。
【０１１４】
前記受信側ＰＤＣＰエンティティは、前記ＢＩＴＭＡＰフィールドを含むＰＤＣＰ Ｃｏｎｔｒｏｌ ＰＤＵを構成し、前記構成されたＰＤＣＰ Ｃｏｎｔｒｏｌ ＰＤＵを前記送信側ＰＤＣＰエンティティに送信する。
【０１１５】
一方、前記ＰＤＣＰ Ｃｏｎｔｒｏｌ ＰＤＵは、前記ＢＩＴＭＡＰフィールドのサイズを示すＬＥＮＧＴＨフィールドを含む。
【０１１６】
さらに、前記ＰＤＣＰ Ｃｏｎｔｒｏｌ ＰＤＵは、ＬＳＮフィールド又はＦＳＮフィールドを含む。ここで、前記ＬＳＮフィールドは、前記ＢＩＴＭＡＰフィールドの最後のビットに対応するＰＤＣＰ ＳＤＵのＳＮ情報を有する。前記ＦＳＮフィールドは、前記ＢＩＴＭＡＰフィールドの最初のビット（最上位ビット）に対応するＰＤＣＰ ＳＤＵのＳＮ情報を有する。このように、本発明は、前記ＬＳＮフィールド及び前記ＦＳＮフィールドを利用するため、前記ＢＩＴＭＡＰフィールドの全てのｂｉｔ＿ｐｏｓｉｔｉｏｎに対する該当ＰＤＣＰ ＳＤＵのＳＮを有する必要がなく、前記ＰＤＣＰ Ｃｏｎｔｒｏｌ ＰＤＵのサイズを小さくすると共に、リソースの効率を向上させる。
【０１１７】
以下、本発明による送信機（送信装置）及び受信機（受信装置）について説明する。
【０１１８】
本発明による受信機（受信装置）は、図７及び図８の実施形態を実現できるハードウェア、ソフトウェア、ソフトウェアを含むモジュールなどから構成された装置である。
【０１１９】
本発明による前記装置は、エンティティと言え、本発明による前記装置は、端末とも言える。
【０１２０】
本発明による受信機は、図７及び図８で説明した機能を実行できる通信モジュールを含む。
【０１２１】
すなわち、ＰＤＣＰ層を介して受信した順次的なＰＤＣＰ ＳＤＵのそれぞれに対して受信成功又は受信失敗を判断し、前記判断された結果に関する状態報告をビットマップ形式で生成し、前記生成したビットマップ形式の状態報告を含むＰＤＣＰ Ｃｏｎｔｒｏｌ ＰＤＵを送信する通信モジュールが提供される。
【０１２２】
前記ＰＤＣＰ Ｃｏｎｔｒｏｌ ＰＤＵは、前記ＬＳＮフィールド又は前記ＦＳＮフィールドを含む。ここで、前記ＬＳＮフィールドは、前記ＢＩＴＭＡＰフィールドの最後のビットに対応するＰＤＣＰ ＳＤＵのシーケンスナンバー（ＳＮ）を示し、前記ＦＳＮフィールドは、前記ＢＩＴＭＡＰフィールドの最初のビットに対応するＰＤＣＰ ＳＤＵのシーケンスナンバー（ＳＮ）を示す。
【０１２３】
本発明による送信機（送信装置）は、図７及び図８で説明した機能を実行できる通信モジュールを含む。ここで、この通信モジュールの機能は、図７及び図８で既に説明したので、その詳細な説明を省略する。
【０１２４】
前述したように、本発明による受信機及び送信機は、前述した構成要素以外に本発明の技術的思想を実現するために必要なソフトウェア及びハードウェア、例えば、出力装置（ディスプレイ、スピーカなど）、入力装置（キーパッド、マイクなど）、メモリ、マイクロプロセッサ、送受信部（ＲＦモジュール、アンテナなど）を基本的に含む。このような構成要素に関する詳細な説明は、本発明の技術分野における通常の知識を有する者にとって明らかであるため、省略する。
【０１２５】
前述した方法は、ソフトウェア、ハードウェア、又はそれらの組み合わせで実現することができる。例えば、前述した本発明による方法は、記憶媒体（例えば、端末機の内部メモリ、フラッシュメモリ、ハードディスクなど）に格納することができ、プロセッサ（例えば、移動端末機内部のマイクロプロセッサ）により実行することができるソフトウェアプログラム内のコード又はコマンドで実現することもできる。
【０１２６】
本発明の思想や範囲から外れない限り、当該技術分野における通常の知識を有する者であれば多様な代案、変更、変形が可能であることを理解できるであろう。従って、本発明の請求の範囲及びその均等物の範囲内で行われる変更及び変形は本発明の請求の範囲に含まれる。
【特許請求の範囲】
【請求項１】
受信側パケットデータコンバージェンスプロトコル（ＰＤＣＰ：Packet Data Convergence Protocol）層が送信側ＰＤＣＰ層に一連のデータに関する状態報告を送信する方法であって、
前記受信側ＰＤＣＰ層がＰＤＣＰ ＳＤＵ（Service Data Unit）である一連のデータの受信状態を判断する段階と、
前記受信側ＰＤＣＰ層が前記送信側ＰＤＣＰ層に前記ＰＤＣＰ ＳＤＵに関する受信状態報告を送信する段階とを含み、
前記受信状態報告は、前記ＰＤＣＰ ＳＤＵが正常に受信されたか否かを、前記ＰＤＣＰ ＳＤＵのシーケンスナンバー（ＳＮ）情報を含むビットマップ形式で送信することを特徴とする移動通信システムにおけるＰＤＣＰ層の状態報告の送信方法。
【請求項２】
前記一連のデータの受信状態報告は、
ＰＤＣＰ Ｃｏｎｔｒｏｌ ＰＤＵ（Protocol Data Unit）形態で前記受信側ＰＤＣＰ層から前記送信側ＰＤＣＰ層に送信されることを特徴とする請求項１に記載の移動通信システムにおけるＰＤＣＰ層の状態報告の送信方法。
【請求項３】
前記ＰＤＣＰ Ｃｏｎｔｒｏｌ ＰＤＵは、
ＢＩＴＭＡＰフィールドを含むことを特徴とする請求項２に記載の移動通信システムにおけるＰＤＣＰ層の状態報告の送信方法。
【請求項４】
前記ＰＤＣＰ Ｃｏｎｔｒｏｌ ＰＤＵは、
ＬＳＮ（Last Sequence Number）フィールド又はＦＳＮ（First Sequence Number）フィールドを含むことを特徴とする請求項２に記載の移動通信システムにおけるＰＤＣＰ層の状態報告の送信方法。
【請求項５】
前記ＬＳＮフィールドは、
前記ＢＩＴＭＡＰフィールドの最後のビットに対応するＰＤＣＰ ＳＤＵのシーケンスナンバー（ＳＮ）を示すことを特徴とする請求項４に記載の移動通信システムにおけるＰＤＣＰ層の状態報告の送信方法。
【請求項６】
前記ＦＳＮフィールドは、
前記ＢＩＴＭＡＰフィールドの最初のビットに対応するＰＤＣＰ ＳＤＵのシーケンスナンバー（ＳＮ）を示すことを特徴とする請求項４に記載の移動通信システムにおけるＰＤＣＰ層の状態報告の送信方法。
【請求項７】
前記ＰＤＣＰ Ｃｏｎｔｒｏｌ ＰＤＵは、長さ（ＬＥＮＧＴＨ）フィールドを含み、前記ＬＥＮＧＴＨフィールドは、前記ビットマップの長さを示す情報を含むことを特徴とする請求項２に記載の移動通信システムにおけるＰＤＣＰ層の状態報告の送信方法。
【請求項８】
前記ＢＩＴＭＡＰフィールドは、
それぞれの前記ＰＤＣＰ ＳＤＵが正常に受信されているか否かを示すインジケータから構成されることを特徴とする請求項３に記載の移動通信システムにおけるＰＤＣＰ層の状態報告の送信方法。
【請求項９】
それぞれの前記インジケータは、１ビットで構成され、前記１ビットが「０」又は「１」に設定されることにより該当ＰＤＣＰ ＳＤＵが正常に受信されているか否かを示すことを特徴とする請求項８に記載の移動通信システムにおけるＰＤＣＰ層の状態報告の送信方法。
【請求項１０】
パケットデータコンバージェンスプロトコル（Packet Data Convergence Protocol：ＰＤＣＰ）層を介して受信したＰＤＣＰ ＳＤＵが正常に受信されているか否かを判断し、前記判断した前記ＰＤＣＰ ＳＤＵの受信成功又は受信失敗に関する情報をビットマップ形式で生成し、前記生成したビットマップ形式の情報をＰＤＣＰ Ｃｏｎｔｒｏｌ ＰＤＵに含めて送信する通信モジュールを含むことを特徴とする移動通信システムにおける受信装置。
【請求項１１】
前記ＰＤＣＰ Ｃｏｎｔｒｏｌ ＰＤＵは、
ＬＳＮ（Last Sequence Number）フィールド又はＦＳＮ（First Sequence Number）フィールドを含み、
ここで、前記ＬＳＮフィールドは、前記ＢＩＴＭＡＰフィールドの最後のビットに対応するＰＤＣＰ ＳＤＵのシーケンスナンバー（ＳＮ）を示し、前記ＦＳＮフィールドは、前記ＢＩＴＭＡＰフィールドの最初のビットに対応するＰＤＣＰ ＳＤＵのシーケンスナンバー（ＳＮ）を示すことを特徴とする請求項１０に記載の移動通信システムにおける受信装置。
【請求項１２】
前記ＰＤＣＰ Ｃｏｎｔｒｏｌ ＰＤＵは、長さ（ＬＥＮＧＴＨ）フィールドを含み、前記ＬＥＮＧＴＨフィールドは、前記ビットマップの長さを示す情報を含むことを特徴とする請求項１１に記載の移動通信システムにおける受信装置。
【請求項１】
受信側パケットデータコンバージェンスプロトコル（ＰＤＣＰ：Packet Data Convergence Protocol）層が送信側ＰＤＣＰ層に一連のデータに関する状態報告を送信する方法であって、
前記受信側ＰＤＣＰ層がＰＤＣＰ ＳＤＵ（Service Data Unit）である一連のデータの受信状態を判断する段階と、
前記受信側ＰＤＣＰ層が前記送信側ＰＤＣＰ層に前記ＰＤＣＰ ＳＤＵに関する受信状態報告を送信する段階とを含み、
前記受信状態報告は、前記ＰＤＣＰ ＳＤＵが正常に受信されたか否かを、前記ＰＤＣＰ ＳＤＵのシーケンスナンバー（ＳＮ）情報を含むビットマップ形式で送信することを特徴とする移動通信システムにおけるＰＤＣＰ層の状態報告の送信方法。
【請求項２】
前記一連のデータの受信状態報告は、
ＰＤＣＰ Ｃｏｎｔｒｏｌ ＰＤＵ（Protocol Data Unit）形態で前記受信側ＰＤＣＰ層から前記送信側ＰＤＣＰ層に送信されることを特徴とする請求項１に記載の移動通信システムにおけるＰＤＣＰ層の状態報告の送信方法。
【請求項３】
前記ＰＤＣＰ Ｃｏｎｔｒｏｌ ＰＤＵは、
ＢＩＴＭＡＰフィールドを含むことを特徴とする請求項２に記載の移動通信システムにおけるＰＤＣＰ層の状態報告の送信方法。
【請求項４】
前記ＰＤＣＰ Ｃｏｎｔｒｏｌ ＰＤＵは、
ＬＳＮ（Last Sequence Number）フィールド又はＦＳＮ（First Sequence Number）フィールドを含むことを特徴とする請求項２に記載の移動通信システムにおけるＰＤＣＰ層の状態報告の送信方法。
【請求項５】
前記ＬＳＮフィールドは、
前記ＢＩＴＭＡＰフィールドの最後のビットに対応するＰＤＣＰ ＳＤＵのシーケンスナンバー（ＳＮ）を示すことを特徴とする請求項４に記載の移動通信システムにおけるＰＤＣＰ層の状態報告の送信方法。
【請求項６】
前記ＦＳＮフィールドは、
前記ＢＩＴＭＡＰフィールドの最初のビットに対応するＰＤＣＰ ＳＤＵのシーケンスナンバー（ＳＮ）を示すことを特徴とする請求項４に記載の移動通信システムにおけるＰＤＣＰ層の状態報告の送信方法。
【請求項７】
前記ＰＤＣＰ Ｃｏｎｔｒｏｌ ＰＤＵは、長さ（ＬＥＮＧＴＨ）フィールドを含み、前記ＬＥＮＧＴＨフィールドは、前記ビットマップの長さを示す情報を含むことを特徴とする請求項２に記載の移動通信システムにおけるＰＤＣＰ層の状態報告の送信方法。
【請求項８】
前記ＢＩＴＭＡＰフィールドは、
それぞれの前記ＰＤＣＰ ＳＤＵが正常に受信されているか否かを示すインジケータから構成されることを特徴とする請求項３に記載の移動通信システムにおけるＰＤＣＰ層の状態報告の送信方法。
【請求項９】
それぞれの前記インジケータは、１ビットで構成され、前記１ビットが「０」又は「１」に設定されることにより該当ＰＤＣＰ ＳＤＵが正常に受信されているか否かを示すことを特徴とする請求項８に記載の移動通信システムにおけるＰＤＣＰ層の状態報告の送信方法。
【請求項１０】
パケットデータコンバージェンスプロトコル（Packet Data Convergence Protocol：ＰＤＣＰ）層を介して受信したＰＤＣＰ ＳＤＵが正常に受信されているか否かを判断し、前記判断した前記ＰＤＣＰ ＳＤＵの受信成功又は受信失敗に関する情報をビットマップ形式で生成し、前記生成したビットマップ形式の情報をＰＤＣＰ Ｃｏｎｔｒｏｌ ＰＤＵに含めて送信する通信モジュールを含むことを特徴とする移動通信システムにおける受信装置。
【請求項１１】
前記ＰＤＣＰ Ｃｏｎｔｒｏｌ ＰＤＵは、
ＬＳＮ（Last Sequence Number）フィールド又はＦＳＮ（First Sequence Number）フィールドを含み、
ここで、前記ＬＳＮフィールドは、前記ＢＩＴＭＡＰフィールドの最後のビットに対応するＰＤＣＰ ＳＤＵのシーケンスナンバー（ＳＮ）を示し、前記ＦＳＮフィールドは、前記ＢＩＴＭＡＰフィールドの最初のビットに対応するＰＤＣＰ ＳＤＵのシーケンスナンバー（ＳＮ）を示すことを特徴とする請求項１０に記載の移動通信システムにおける受信装置。
【請求項１２】
前記ＰＤＣＰ Ｃｏｎｔｒｏｌ ＰＤＵは、長さ（ＬＥＮＧＴＨ）フィールドを含み、前記ＬＥＮＧＴＨフィールドは、前記ビットマップの長さを示す情報を含むことを特徴とする請求項１１に記載の移動通信システムにおける受信装置。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【公表番号】特表２０１０−５１９８８０（Ｐ２０１０−５１９８８０Ａ）
【公表日】平成２２年６月３日（２０１０．６．３）
【国際特許分類】
【出願番号】特願２００９−５５１９５９（Ｐ２００９−５５１９５９）
【出願日】平成２０年９月１０日（２００８．９．１０）
【国際出願番号】ＰＣＴ／ＫＲ２００８／００５３４５
【国際公開番号】ＷＯ２００９／０３５２６２
【国際公開日】平成２１年３月１９日（２００９．３．１９）
【出願人】（５０２０３２１０５）エルジー エレクトロニクス インコーポレイティド (2,269)
【Ｆターム（参考）】
【公表日】平成２２年６月３日（２０１０．６．３）
【国際特許分類】
【出願日】平成２０年９月１０日（２００８．９．１０）
【国際出願番号】ＰＣＴ／ＫＲ２００８／００５３４５
【国際公開番号】ＷＯ２００９／０３５２６２
【国際公開日】平成２１年３月１９日（２００９．３．１９）
【出願人】（５０２０３２１０５）エルジー エレクトロニクス インコーポレイティド (2,269)
【Ｆターム（参考）】
[ Back to top ]