JP2010539784A - ヘッダインジケータを利用した効率的なデータブロック送信方法 - Google Patents

Abstract

本発明は、無線通信サービスを提供する無線通信システム及び端末に関し、特に、ＵＭＴＳ（Universal Mobile Telecommunications System）から進化したＥ−ＵＭＴＳ（Evolved Universal Mobile Telecommunications System）又はＬＴＥシステム（Long Term Evolution System）において基地局と端末間にデータブロック又はデータユニットを交換する方法に関し、無線リソースの効率を向上させるためのデータブロックを生成する方法に関する。
【選択図】図９

Description

本発明は、無線通信サービスを提供する無線通信システム及び端末に関し、特に、ＵＭＴＳ（Universal Mobile Telecommunications System）から進化したＥ−ＵＭＴＳ（Evolved Universal Mobile Telecommunications System）又はＬＴＥ（Long Term Evolution）システムにおいて基地局と端末がデータブロックを交換する方法に関し、無線リソースの効率を向上させるためのデータブロックの生成方法に関する。

図１は、従来技術及び本発明が適用される移動通信システムであるＥ−ＵＭＴＳのネットワーク構造を示す。前記Ｅ−ＵＭＴＳシステムは、前記ＵＭＴＳシステムから進化したシステムであり、前記Ｅ−ＵＭＴＳの標準化は、現在３ＧＰＰで行われている。前記Ｅ−ＵＭＴＳは、長期的発展（Long Term Evolution：ＬＴＥ）システムともいわれる。

前記Ｅ−ＵＭＴＳネットワークは、Ｅ−ＵＴＲＡＮとコアネットワーク（Core Network：ＣＮ）とに分けられる。前記Ｅ−ＵＴＲＡＮは、一般に端末（すなわち、ユーザ装置（User Equipment：ＵＥ））、基地局（すなわち、ｅＮｏｄｅ Ｂ）、Ｅ−ＵＭＴＳネットワークの端部に位置して少なくとも１つの外部ネットワークと接続されるサービングゲートウェイ（Serving Gateway：Ｓ−ＧＷ）、及び端末の移動性を管理する移動管理エンティティ（Mobility Management Entity：ＭＭＥ）から構成される。１つのｅＮｏｄｅ Ｂには１つ以上のセルが存在する。

図２は、３ＧＰＰ無線アクセスネットワーク規格に基づいた端末とＥ−ＵＴＲＡＮ間の無線インタフェースプロトコルの構造を示す。図２に示す無線インタフェースプロトコルは、水平的に物理層（Physical Layer）、データリンク層（Data Link Layer）、及びネットワーク層（Network Layer）からなり、垂直的にデータ情報送信のためのユーザプレーン（User Plane）及び制御信号伝達のための制御プレーン（Control Plane）からなる。図２に示すプロトコル層は、通信システム分野で周知の開放型システム間相互接続（Open System Interconnection：ＯＳＩ）基準モデルの下位３層に基づいてＬ１（第１層）、Ｌ２（第２層）、Ｌ３（第３層）に区分される。

以下、図２の無線プロトコル制御プレーンと図３の無線プロトコルユーザプレーンの各層を説明する。

物理層（第１層）は、物理チャネルを利用して上位層に情報送信サービスを提供する。前記物理層は、トランスポートチャネルで上位に位置するメディア・アクセス制御（Medium Access Control：ＭＡＣ）層に接続される。データは、トランスポートチャネルを介して前記ＭＡＣ層と前記物理層間で送信される。また、データは、相異なる物理層間、すなわち、送信側（送信器）の物理層と受信側（受信器）の物理層間で物理チャネルを介して送信される。

前記第２層のＭＡＣ層は、論理チャネルで上位層である無線リンク制御（Radio Link Control：ＲＬＣ）層にサービスを提供する。前記第２層の前記ＲＬＣ層は、信頼性のあるデータ送信をサポートする。前記ＲＬＣ層の機能が前記ＭＡＣ層内に組み込まれ、及びＭＡＣ層により実行される場合、前記ＲＬＣ層は存在しなくてもよい。前記第２層のＰＤＣＰ層は、ＩＰｖ４やＩＰｖ６などのＩＰパケットを利用して相対的に帯域幅が小さい無線インタフェース上でデータを効率的に送信するために、不要な制御情報を低減するヘッダ圧縮機能を行う。

前記第３層の最下部に位置する無線リソース制御（Radio Resource Control：ＲＲＣ）層は、制御プレーンにおいてのみ定義され、無線ベアラ（Radio Bearer：ＲＢ）の設定、再設定、及び解除のために論理チャネル、トランスポートチャネル及び物理チャネルの制御を担当する。ここで、無線ベアラ（ＲＢ）は、前記移動端末と前記ＵＴＲＡＮ間のデータ送信のために前記第２層により提供されるサービスである。

以下、ＭＡＣエンティティにおいて使用されるＭＡＣプロトコルデータユニット（Protocol Data Unit：ＰＤＵ）の構成について詳細に説明する。図４は、ＭＡＣエンティティにおいて使用される一般のＰＤＵのフォーマットを示す。図４を参照すると、論理チャネルＩＤ（Ｌｏｇｉｃａｌ Ｃｈａｎｎｅｌ ＩＤ：ＬＣＩＤ）フィールドは、該当するＭＡＣサービスデータユニット（Service Data Unit：ＳＤＵ）の論理チャネル・インスタンスを識別し、Ｌｅｎｇｔｈ（Ｌ）フィールドは、該当するＭＡＣ ＳＤＵのバイト（byte）長を示す。さらに、Ｅｘｔｅｎｓｉｏｎ（Ｅ）フィールドは、ＭＡＣヘッダに追加フィールドが存在するか否かを示す。前記ＭＡＣ ＰＤＵを生成する過程で、図５に示すように、該当するＭＡＣ ＳＤＵ又はＭＡＣ制御要素（Control Element）のサイズが１２７以下の場合、７ビットのＬフィールドが使用され、そうでない場合は、１５ビットのＬフィールドを含むＭＡＣサブヘッダが使用される。また、ＭＡＣ ＰＤＵに含まれるＭＡＣ ＳＤＵ又は固定サイズのＭＡＣ制御要素のＭＡＣサブヘッダに対しては、図６に示されるＭＡＣサブヘッダが使用される。

次に、図４、図５、及び図６において使用される各フィールドについて詳細に説明する。まず、ＬＣＩＤフィールドは、該当するＭＡＣ ＳＤＵの論理チャネルデータのタイプ、又は、該当するＭＡＣ制御要素（MAC CE）に含まれるデータのタイプを示す。Ｅフィールドは、今回のＭＡＣサブヘッダ後に他のＭＡＣサブヘッダがあるかを示す。Ｆｏｒｍａｔ（Ｆ）フィールドは、後続のＬフィールドの長さを示す。Ｒｅｓｅｒｖｅｄ（Ｒ）フィールドは、リザーブビットであり、使用されないビットである。

一般に、ＭＡＣ ＰＤＵが伝送される度に、基地局は、物理層の制御チャネルであるＰＤＣＣＨで前記ＭＡＣ ＰＤＵのサイズを端末に通知する。すなわち、前記ＰＤＣＣＨで伝送されるＭＡＣ ＰＤＵのサイズが通知されるため、前記ＭＡＣ ＰＤＵには前記ＭＡＣ ＰＤＵのトータルサイズを通知する情報を含む必要がない。

しかしながら、ＰＤＣＣＨで伝送される情報の量には制限がある。すなわち、前記ＰＤＣＣＨで伝送される情報のうち、前記ＭＡＣ ＰＤＵのサイズ、すなわちトランスポートブロック（Transport Block：ＴＢ）のサイズを通知する情報のビット数は、制限されている。例えば、前記ＭＡＣ ＰＤＵの最大サイズが２０００バイトに設定される場合、前記ＭＡＣ ＰＤＵのサイズを１バイト単位で通知するためには１１ビット必要である。この場合、実際に使用できるビット数が６である場合、前記ＭＡＣ ＰＤＵのサイズは３２バイト単位で表現される。

一方、上位層、特に、前記ＲＬＣは、前記ＭＡＣエンティティが要求するサイズでＭＡＣ ＳＤＵを生成して伝送する。しかしながら、実際にＲＬＣに保存されているデータの量が少ないため、ＭＡＣが要求する量より小さいサイズのＭＡＣ ＳＤＵが生成された場合、前記ＭＡＣエンティティは、前記ＭＡＣ ＰＤＵにパディングビットを加えてＭＡＣ ＰＤＵを生成する。

しかしながら、従来の技術は以下のような問題がある。

図７は、従来技術によるＭＡＣ ＰＤＵの構造の例を示す。図７を参照すると、前記ＭＡＣ ＰＤＵのサイズ、すなわち、トランスポートブロックのサイズがＮ＋Ｍ＋１オクテットであると仮定する。従来技術において、最後のＭＡＣ ＳＤＵのためにはＬフィールドを有しないＭＡＣサブヘッダが使用される。ここで、前記最後のＭＡＣ ＳＤＵのサイズによっては、１オクテットの存在が曖昧になることがある。

例えば、図７の（ａ）、（ｂ）においてＲＬＣ ＰＤＵ １からＲＬＣ ＰＤＵ Ｎ−１のサイズは同一であり、図７（ｂ）の最後のＲＬＣ ＰＤＵ（すなわち、ＲＬＣ ＰＤＵ Ｎ）のサイズが図７（ａ）の最後のＲＬＣ ＰＤＵより１小さいと仮定する。また、図７（ｂ）において、ＭＡＣサブヘッダ及びそれに関連するＭＡＣ ＳＤＵ（ＲＬＣ ＰＤＵ）又はＭＡＣ制御要素のトータルサイズとトランスポートブロックのサイズとが同一であると仮定する。この場合、ＲＬＣ ＰＤＵ Ｎのサイズが１小さくなると、これは、ＭＡＣ ＰＤＵに１バイトの空間が発生することを意味する。送信側のＭＡＣエンティティが前記ＭＡＣ ＰＤＵの最後に１バイトのパディングが入っていることを通知しない場合、受信側のＭＡＣエンティティは、図７（ａ）と図７（ｂ）の２つのケースを区分することができない。さらに、前記受信側のＭＡＣエンティティは、前記２つのケースを同一のＲＬＣ ＰＤＵに復元することになる。

さらに、図７において、ＭＡＣ ＰＤＵの最後にパディングがあることを通知するために、追加ヘッダが加えられる場合、図８に示すような問題が発生する。すなわち、図７（ｂ）において、パディングのためのＭＡＣサブヘッダを含むためには、前記ＭＡＣサブヘッダのすぐ前に含まれるＭＡＣサブヘッダがＬフィールドを含まなければならない。これは、図８（ｂ）に示すように、最後に含まれるＭＡＣ ＳＤＵ、すなわち、ＲＬＣ ＰＤＵ Ｎのサイズが小さくなる必要があることを前提とする。また、この場合、パディングは必要なくなる。すなわち、従来技術によれば、ＭＡＣ ＰＤＵに１バイト又は２バイトの空間がある場合、ＭＡＣ ＰＤＵ生成過程で問題が生じる。

従って、本発明の目的は、基地局と端末がＭＡＣ ＰＤＵを生成して伝送するとき、ＭＡＣ ＰＤＵに存在するパディングデータを効果的に通知する方法を提供することにある。より詳しくは、本発明は、前記ＭＡＣ ＰＤＵに１バイト又は２バイトの空間がある場合、これを効果的に処理する方法を提供する。

このような本発明の課題を解決するために、上位層から少なくとも１つのサービスデータユニットを受信する段階と、前記プロトコルデータユニットの生成のために前記少なくとも１つの受信されたサービスデータユニットにヘッダを加える段階と、前記プロトコルデータユニットの生成の完成のために１つ又は２つのパディングバイト（padding byte）が必要であるか否かを判断する段階と、前記１つ又は２つのパディングバイトが必要であると判断された場合、前記１つ又は２つのパディングバイトを示すために少なくとも１つのパディングインジケータを前記プロトコルデータユニットに挿入する段階とを含む無線通信システムにおけるプロトコルデータユニットの生成方法を提供する。

従来技術及び本発明が適用される移動通信システムであるＥ−ＵＴＲＡＮのネットワーク構造を示す図である。 従来技術による端末とＥ−ＵＴＲＡＮ間の無線インタフェースプロトコルの制御プレーン構造を示す図である。 従来技術による端末とＥ−ＵＴＲＡＮ間の無線インタフェースプロトコルのユーザプレーン構造を示す図である。 ＭＡＣエンティティにおいて使用されるＰＤＵのフォーマットを示す図である。 ＭＡＣエンティティにおいて使用されるＭＡＣサブヘッダフォーマットを示す図である。 ＭＡＣエンティティにおいて使用される他のＭＡＣサブヘッダフォーマットを示す図である。 （ａ）及び（ｂ）は従来技術によるＭＡＣ ＰＤＵの構造を示す図である。 （ａ）及び（ｂ）は従来技術によるＭＡＣ ＰＤＵの他の構造を示す図である。 本発明の第１実施形態によるＭＡＣ ＰＤＵの生成方法を示す図である。 本発明の第２実施形態によるＭＡＣ ＰＤＵの生成方法を示す図である。 本発明の第３実施形態によるＭＡＣ ＰＤＵの生成方法を示す図である。 本発明の第３実施形態によるＭＡＣ ＰＤＵの生成方法を示す図である。 本発明の第４実施形態によるＭＡＣ ＰＤＵの生成方法を示す図である。

本発明の一態様は、前述した従来技術の問題及び欠点に対する本発明者らによる認識であり、以下に詳細に説明する。このような認識に基づいて、本発明の特徴が改善されている。

本発明は、３ＧＰＰ通信技術、特に、ＵＭＴＳシステム、通信装置及び通信方法に適用される。しかしながら、本発明は、これに限定されるものではなく、本発明の技術的特徴が適用される全ての有線／無線通信に適用できる。

本発明は、基地局と端末がＭＡＣ ＰＤＵを生成して伝送するとき、ＭＡＣ ＰＤＵに存在するパディングデータを効果的に通知する方法を提供する。このために、本発明は、パディングインジケータの使用を提案する。より詳しくは、前記パディングインジケータは、パディングデータのサイズ、すなわち、ＭＡＣ ＰＤＵに含まれるパディングのバイト数を通知する。ここで、あるパディングデータが前記ＭＡＣ ＰＤＵに存在する場合、送信側ＭＡＣエンティティは、「パディング拡張（Padding Extension：ＰＥ）」フィールドといわれるフィールドをＭＡＣ ＰＤＵに含める。ここで、前記ＰＥは、ＭＡＣ ＰＤＵの最後のヘッダに含まれる。前記ＰＥフィールドは、すぐ次のフィールドが他のＰＥフィールドであるか否かを通知するか、前記ＰＥフィールドが前記ＭＡＣ ＰＤＵに含まれる最後のＰＥフィールドであるか否かを通知する。また、前記ＰＥフィールドを使用して前記ＭＡＣ ＰＤＵに含まれるＰＥフィールドの数から１を引いた値が前記ＭＡＣ ＰＤＵに含まれるパディングバイトであってもよい。前記ＭＡＣ ＰＤＵに含まれるＰＥフィールドのうち、次のフィールドがＰＥフィールドであると設定されたＰＥフィールドの数に応じてパディングがＭＡＣ ＰＤＵに含まれる。

以下、添付図面を参照して本発明の好ましい実施形態の構造及び動作について説明する。

図９は、本発明の第１実施形態によるＭＡＣ ＰＤＵの生成方法を示す図である。図９において、ＭＡＣサブヘッダのＲフィールドは省略されている。図９（ａ）は、ＭＡＣ ＰＤＵにパディングが含まれない場合であり、図９（ｂ）は、１バイトのパディングが含まれる場合である。図９（ａ）において、第１のＰＥフィールドは０に設定され、これは、次のフィールドがＰＥフィールドではないことを意味し、従って、前記ＭＡＣ ＰＤＵにはパディングバイトが含まれない。それに対して、図９（ｂ）において、第１のＰＥフィールドは１に設定され、これは、次のフィールドがＰＥフィールドであることを意味する。また、第２のＰＥフィールドが０に設定され、前記第２のＰＥフィールドが前記ＭＡＣ ＰＤＵの最後のＰＥフィールドであることを意味し、従って、第３のＰＥフィールドは前記ＭＡＣ ＰＤＵには含まれないことを通知する。従って、図９（ｂ）の前記ＭＡＣ ＰＤＵには１バイトのパディングが存在する。

前記過程で、前記ＭＡＣヘッダのバイト整列のために使用されたＭＡＣヘッダパディングは、パディングとみなされない。さらに、前記過程で、前記ＭＡＣサブヘッダのトータルサイズと、前記ＭＡＣサブヘッダが示すＭＡＣサービスデータユニット（ＳＤＵ）又はＭＡＣ制御要素（ＣＥ）のトータルサイズとがトランスポートブロックのサイズと同一である場合、前記ＰＥフィールドは含まれなくてもよい。

本発明は、パディングの存在を効果的に通知する他の方法を提示する。特に、ＭＡＣ ＰＤＵが生成される過程で、ほとんどの場合は、パディングＬＣＩＤを使用することができ、パディングバイトが０、１又は２バイトであるときに問題が発生することを考慮して、２ビットのパディングインジケータを使用することを提案する。すなわち、ＭＡＣ ＰＤＵのヘッダの最後のフィールドは、２ビットのパディングインジケータ（2-bit PI）を使って設定され、これは、実際に含まれるパディングバイトを示す。

図１０は、本発明の第２実施形態によるＭＡＣ ＰＤＵの生成方法を示す図である。図１０を参照すると、前記ＰＩは、ＭＡＣヘッダの最後のフィールドとして含まれ、前記ＰＩの値は、前記ＭＡＣ ＰＤＵの最後に含まれるパディングバイトの数を示す。図１０（ａ）において、前記ＰＩが０である場合、前記ＭＡＣ ＰＤＵには０バイトのパディングが存在することが分かる。図１０（ｂ）において、前記ＰＩが１である場合、前記ＭＡＣ ＰＤＵには１バイトのパディングが存在することが分かる。また、図１０（ｃ）において、前記ＰＩが２である場合、前記ＭＡＣ ＰＤＵには２バイトのパディングが存在することが分かる。図１０においては、２ビットのＰＩを仮定しているが、１ビットのＰＩを使用することもできる。この場合、１ビットのＰＩは、１バイトのパディングが存在するか否かを通知するか、又は、パディングの有無のみを通知する。

本発明によるさらに他の方式について説明する。図１１及び図１２を参照すると、各ＭＡＣサブヘッダに存在するＲフィールドの１つは、前記ＭＡＣ ＰＤＵの最後の部分における１バイトパディングの存在を通知するために利用される。図１１において、前記Ｐフィールドは、パディングインジケータビットであり、前記ＭＡＣサブヘッダは、前記ＭＡＣ ＰＤＵに含まれる最後のＭＡＣサブヘッダにおいてのみ使用される。

図１２は、図１１のＭＡＣサブヘッダの構造の例を示す図である。好ましくは、図１１及び図１２において、最後のＬＣＩＤフィールドの値がパディングを示す場合、前記Ｐフィールドは使用しない。また、最後のサブヘッダに使用されるＬＣＩＤは、前記ＭＡＣ ＰＤＵ内に存在するパディングが１バイトであることを示す特別なＬＣＩＤ値であってもよい。

本発明によるさらに他の方式は他のパディングＬＣＩＤを割り当てるものである。すなわち、パディングを示すための従来のＬＣＩＤとは別途に、さらに他のパディングＬＣＩＤを定義するものである。この場合、第１のパディングＬＣＩＤは、前記ＭＡＣ ＰＤＵ内のパディングが２バイト未満であるときに使用され、他のパディングＬＣＩＤは、前記ＭＡＣ ＰＤＵ内のパディングが２バイト以上であるときに使用される。

図１３は、本発明によるＭＡＣ ＰＤＵの生成方法を示す図である。各ＭＡＣサブヘッダに含まれるＲビットの１つは、パディングインジケータビット（ＰＩＢ）として使用される。好ましくは、前記Ｅフィールドが０に設定されたＭＡＣサブヘッダ内に含まれる前記パディングインジケータビットは、前記Ｅフィールドが０に設定されていないＭＡＣサブヘッダ内においては使用されない。ここで、前記パディングインジケータビットが使用される場合、すなわち、前記Ｅフィールドが０に設定された場合、前記Ｌフィールドは含まれず、前記パディングインジケータビットフィールドは、前記パディングインジケータビットが使用されたＭＡＣサブヘッダのすぐ次にパディングＬＣＩＤを有するＭＡＣサブヘッダが存在するか否かを通知する。

すなわち、前記Ｅフィールドは、あるＭＡＣサブヘッダにおけるＬフィールドの存在を通知する。従来においては、最後のＭＡＣサブヘッダ内にＬフィールドが存在しない場合、前記ＭＡＣ ＰＤＵに１バイト残って問題が発生した。この問題を解決するために、本発明においては、Ｅフィールドが０に設定されたＭＡＣサブヘッダ内にパディングインジケータビットを含め、前記ＭＡＣヘッダ内に他の１バイトのＭＡＣサブヘッダを含めることにより、前記ＭＡＣ ＰＤＵに残っていた１バイトを使用して完全なＭＡＣ ＰＤＵを生成できる。すなわち、パディングＬＣＩＤを有するＭＡＣサブヘッダがパディングの代わりに含まれる。パディングインジケータビットは、次のフィールド又はサブヘッダがパディングを示すためのサブヘッダであるか否かを通知する。

前記過程で、前記ＭＡＣ ＰＤＵ内に１バイトのパディングのみが存在することを示すために使用されるＬＣＩＤ値は、一般の場合にパディングを示すために使用されるＬＣＩＤ値と異なってもよい。また、前記ＭＡＣ ＰＤＵ内に１バイトのパディングのみが存在することを示すために使用されるＬＣＩＤ値は、一般の場合のパディングを示すために使用されるＬＣＩＤ値と同一であってもよい。すなわち、特定値に設定されたＬＣＩＤは、１バイトのパディングを示すために使用される。

本発明によれば、ＭＡＣ ＰＤＵは、ＭＡＣヘッダ、１つ又はそれ以上のＭＡＣ ＳＤＵ、１つ又はそれ以上のＭＡＣ制御要素、及び任意のパディングから構成されてもよい。ここで、前記ＭＡＣヘッダ及び前記ＭＡＣ ＳＤＵは、可変サイズを有する。前記ＭＡＣ ＰＤＵヘッダは、１つ又はそれ以上のＭＡＣ ＰＤＵサブヘッダから構成されてもよく、それぞれのサブヘッダは、前記ＭＡＣ ＳＤＵ、ＭＡＣ制御要素、又はパディングに対応する。前記ＭＡＣ ＰＤＵ内の最後のサブヘッダと固定サイズのＭＡＣ制御要素のためのサブヘッダを除いて、前記ＭＡＣ ＰＤＵサブヘッダはＲ／Ｒ／Ｅ／ＬＣＩＤ／Ｆ／Ｌの６つのヘッダフィールドから構成されてもよい。前記ＭＡＣ ＰＤＵ内の最後のサブヘッダと固定サイズＭＡＣ制御要素のためのサブヘッダは、Ｒ／Ｒ／Ｅ／ＬＣＩＤの４つのフィールドのみから構成されてもよい。前記４つのＲ／Ｒ／Ｅ／ＬＣＩＤヘッダフィールドから構成されたパディングに対応するＭＡＣ ＰＤＵサブヘッダが後続してもよい。前記ＭＡＣ ＰＤＵサブヘッダは、前記対応するＭＡＣ ＳＤＵ、ＭＡＣ制御要素、及びパディングと同一順序である。パディング・バッファ状態レポート（buffer status report：ＢＳＲ）を除いて、前記ＭＡＣ制御要素は、常にＭＡＣ ＳＤＵより前に位置する。前記パディングＢＳＲは、前記ＭＡＣ ＰＤＵの最後に発生してもよい。１つ又は２つのバイトパディングが必要であるが、前記ＭＡＣ ＰＤＵの最後へのパディングにより達成できない場合を除いて、前記パディングは、前記ＭＡＣ ＰＤＵの最後に発生してもよい。前記１つ又は２つのバイトパディングが必要であるが、前記ＭＡＣ ＰＤＵの最後へのパディングにより達成できない場合は、パディングに対応する１つ又は２つのＭＡＣ ＰＤＵサブヘッダが、ＭＡＣ ＳＤＵに対応する第１のＭＡＣ ＰＤＵサブヘッダの前に挿入される。このようなサブヘッダが存在しない場合、パディングに対応する１つ又は２つのＭＡＣ ＰＤＵサブヘッダが、ＭＡＣ制御要素に対応する最後のＭＡＣ ＰＤＵサブヘッダの前に挿入される。

ＭＡＣエンティティがＭＡＣ ＰＤＵを生成する場合、本発明は、実際に有用な情報又は無用な情報をオーバーヘッドを最小限に抑えて通知して、無線リソースの効率を向上させる効果を奏する。

本発明は、上位層から少なくとも１つのサービスデータユニットを受信する段階と、前記プロトコルデータユニットの生成のために前記少なくとも１つの受信されたサービスデータユニットにヘッダを加える段階と、前記プロトコルデータユニットの生成の完成のために１つ又は２つのパディングバイト（padding byte）が必要であるか否かを判断する段階と、前記１つ又は２つのパディングバイトが必要であると判断された場合、前記１つ又は２つのパディングバイトを示すために少なくとも１つのパディングインジケータを前記プロトコルデータユニットに挿入する段階とを含む無線通信システムにおけるプロトコルデータユニットの生成方法を提供する。ここで、前記少なくとも１つのパディングインジケータは、前記プロトコルデータユニットのヘッダに挿入され、前記ヘッダは、前記上位層を識別するためのＬＣＩＤフィールド又は前記受信されたサービスデータユニットのサイズを示すためのＬフィールドの少なくとも１つを含み、前記少なくとも１つのパディングインジケータは、前記ＬＣＩＤフィールドにおいて特定値に設定され、前記生成されたプロトコルデータユニットを下位層に伝送する段階をさらに含み、前記判断する段階は、前記下位層が要求するＰＤＵのトータルサイズと前記受信されたＳＤＵに前記ヘッダを含めたトータルサイズとを比較して行われ、前記ヘッダは、１つ又はそれ以上のサブヘッダを含み、前記少なくとも１つのパディングインジケータは、前記サービスデータユニットに対応する第１のサブヘッダの前に挿入され、前記少なくとも１つのパディングインジケータが制御要素（ＣＥ）に対応する最後のサブヘッダの前に挿入され、前記プロトコルデータユニットは、ＭＡＣ ＰＤＵであり、前記少なくとも１つのパディングインジケータは、パディングバイトが存在するか否かを示すために使用され、前記少なくとも１つのパディングインジケータは、パディングバイトのサイズを示すために使用される。

本発明は、移動通信に関連して説明されたが、無線通信特性（すなわち、インタフェース）を備えたＰＤＡ及びラップトップコンピュータのような移動装置を使用する他の無線通信システムにも適用できる。また、本発明を説明するために使用された特定用語は本発明の権利範囲を特定無線通信システムに限定するものではない。本発明は、さらに、ＴＤＭＡ、ＣＤＭＡ、ＦＤＭＡ、ＷＣＤＭＡ、ＯＦＤＭ、ＥＶ−ＤＯ、Ｗｉ−Ｍａｘ、Ｗｉ−Ｂｒｏなどの他の無線インターフェース及び／又は他の物理層を使用する他の無線通信システムにも適用できる。

本実施形態は、ソフトウェア、ファームウェア、ハードウェア、又はこれらの組み合わせを生産するための標準プログラミング及び／又はエンジニアリング技術を利用して製造方法、装置、又は製造物として実行できる。ここで、「製造物」という用語は、ハードウェアロジック(例えば、集積回路チップ、ＦＰＧＡ(Field Programmable Gate Array)、ＡＳＩＣ(Application Specific Integrated Circuit)など)、コンピュータ可読媒体(例えば、ハードディスクドライブ、フロッピー（登録商標）ディスク、テープなどの磁気記録媒体)、光記録装置(ＣＤ−ＲＯＭ、光ディスクなど)、又は揮発性／不揮発性メモリ装置(例えば、ＥＥＰＲＯＭ、ＲＯＭ、ＰＲＯＭ、ＲＡＭ、ＤＲＡＭ、ＳＲＡＭ、ファームウェア、プログラムロジックなど)において実行されるコードやロジックを意味する。

コンピュータ可読媒体内のコードはプロセッサにより接続及び実行される。本実施形態を実行するコードは送信媒体を通じて、又はネットワーク上のファイルサーバから接続することもできる。その場合、前記コードが実行される製造物は、ネットワーク送信ライン、無線送信媒体、空中を伝播する信号、無線波、赤外線信号などの送信媒体を含む。もちろん、当該技術分野における通常の知識を有する者であれば、本発明の要旨を逸脱しない範囲においてこのような形態の多様な変形が可能であり、前記製造物が公知の情報伝達媒体（information bearing medium）も含むことができるという点を理解すると思われる。

本明細書での「一実施形態（one embodiment）」、「１つの実施形態（an embodiment）」又は「実施形態（example embodiment）」などに関する言及は、前記実施形態に関連して説明された特性、構造又は特徴が本発明の少なくとも一実施形態に含まれることを意味する。本明細書の様々な部分におけるその語句が必ずしも同一の実施形態を言及するわけではない。また、構造又は特徴がいずれかの実施形態に関連して説明された場合、当業者であれば本実施形態の他の実施形態に関連してそのような構造又は特徴が達成できることは理解できるであろう。

本発明は複数の例示的な実施形態に基づいて説明されたが、様々な他の変形及び実施形態が本発明の精神及び範囲内で当業者により案出できることは理解できるであろう。特に、発明の詳細な説明、図面、及び添付された請求の範囲において、多様な変形及び変更が可能である。構成要素及び／又は課題の構成に対する変形及び変更以外に、代案的利用も当業者に明らかなことである。

本発明の思想や重要な特性から外れない限り、本発明は多様な形態で実現することができ、前述した実施形態は前述した詳細な記載内容によって限定されるのではなく、添付された請求の範囲に定義された本発明の精神や範囲内で広く解釈されるべきであり、本発明の請求の範囲内で行われるあらゆる変更及び変形、並びに請求の範囲の均等物は本発明の請求の範囲に含まれる。

Claims (12)

1. 無線通信システムにおいてプロトコルデータユニット（ＰＤＵ）を生成する方法であって、
   上位層から少なくとも１つのサービスデータユニット（ＳＤＵ）を受信するステップと、
   前記プロトコルデータユニットの生成のために前記少なくとも１つの受信されたサービスデータユニットにヘッダを加えるステップと、
   前記プロトコルデータユニットの生成の完成のために１つ又は２つのパディングバイトが必要であるか否かを判断するステップと、
   前記１つ又は２つのパディングバイトが必要であると判断された場合、前記１つ又は２つのパディングバイトを示すために少なくとも１つのパディングインジケータを前記プロトコルデータユニットに挿入するステップと、
   を有する、プロトコルデータユニットの生成方法。
2. 前記少なくとも１つのパディングインジケータは、前記プロトコルデータユニットのヘッダに挿入される、請求項１に記載のプロトコルデータユニットの生成方法。
3. 前記ヘッダは、前記上位層を識別するためのＬＣＩＤフィールド及び前記受信されたサービスデータユニットのサイズを示すためのＬフィールドの少なくとも１つを有する、請求項２に記載のプロトコルデータユニットの生成方法。
4. 前記少なくとも１つのパディングインジケータは、前記ＬＣＩＤフィールドにおいて特定値に設定される、請求項３に記載のプロトコルデータユニットの生成方法。
5. 前記生成されたプロトコルデータユニットを下位層に伝送するステップをさらに有する、請求項１に記載のプロトコルデータユニットの生成方法。
6. 前記判断するステップは、前記下位層が要求するＰＤＵのトータルサイズと前記受信されたＳＤＵに前記ヘッダを含めたトータルサイズとを比較して行われる、請求項５に記載のプロトコルデータユニットの生成方法。
7. 前記ヘッダが１つ又はそれ以上のサブヘッダを有する、請求項１に記載のプロトコルデータユニットの生成方法。
8. 前記少なくとも１つのパディングインジケータが、前記サービスデータユニットに対応する第１のサブヘッダの前に挿入される、請求項７に記載のプロトコルデータユニットの生成方法。
9. 前記少なくとも１つのパディングインジケータが、制御要素に対応する最後のサブヘッダの前に挿入される、請求項７に記載のプロトコルデータユニットの生成方法。
10. 前記プロトコルデータユニットはＭＡＣ ＰＤＵである、請求項１に記載のプロトコルデータユニットの生成方法。
11. 前記少なくとも１つのパディングインジケータは、パディングバイトの存在を示すために使用される、請求項１に記載のプロトコルデータユニットの生成方法。
12. 前記少なくとも１つのパディングインジケータは、パディングバイトのサイズを示すために使用される、請求項１に記載のプロトコルデータユニットの生成方法。

Images