JP2009296513A - 通信処理装置、通信処理方法及びそのプログラム - Google Patents

Abstract

【課題】 レイヤ間のデータ受け渡しの際の通信処理負荷を軽減することが可能な通信処理装置を提供する。
【解決手段】 データと、第２のレイヤにおいて該データに対する所定の通信処理に用いられる識別情報と、を含む複数の第１のフレームのうち、前記データを相互に結合する第１のフレームを、識別情報の内容に応じて判別する。結合すると判別された第１のフレームのデータを相互に結合することによって、結合データを生成する。結合データに含まれるデータに対して第２のレイヤにおいて行う通信処理の内容を示す結合データ用識別情報を生成する。結合データ用識別情報と結合データとを含む第２のフレームＦ１を生成する。第２のフレームＦ１を、第２のレイヤへ受け渡す。
【選択図】 図８

Description

本発明は、通信処理装置、通信処理方法及びそのプログラムに関する。

図１３はＷ−ＣＤＭＡ（Ｗｉｄｅｂａｎｄ Ｃｏｄｅ Ｄｉｖｉｓｉｏｎ Ｍｕｌｔｉｐｌｅ Ａｃｃｅｓｓ）のシステムで想定されている無線インターフェイスのプロトコル階層を示す図である。

図１３に示すように、Ｗ−ＣＤＭＡのシステムで想定されている無線インターフェイスのプロトコル階層は、ＰＨＹ（物理）レイヤ２０１と、ＭＡＣ（Ｍｅｄｉｕｍ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ）レイヤ２０２と、ＲＬＣ（Ｒａｄｉｏ Ｌｉｎｋ Ｃｏｎｔｒｏｌ）レイヤ２０３と、ＰＤＣＰ（Ｐａｃｋｅｔ Ｄａｔａ Ｃｏｎｖｅｒｇｅｎｃｅ Ｐｒｏｔｏｃｏｌ）レイヤ２０４と、アプリケーション・レイヤ２０５と、ＲＲＣ（Ｒａｄｉｏ Ｒｅｓｏｕｒｃｅ Ｃｏｎｔｒｏｌ）レイヤ２０６と、ＮＡＳ（Ｎｏ Ａｃｃｅｓｓ Ｓｔｒａｔｕｍ）レイヤ２０７と、を備えて構成されている。

ＰＨＹレイヤ２０１はトランスポート・チャネルによる無線伝送や無線品質などの測定を行うレイヤである。

ＭＡＣレイヤ２０２は、ＲＬＣレイヤ２０３に対し、論理チャネルの伝送や無線リソースの割り当てを行うレイヤである。

ＲＬＣレイヤ２０３は、上位レイヤであるＰＤＣＰレイヤ２０４へのデータ伝送サービスを提供するレイヤである。ＲＬＣレイヤ２０３とアプリケーション・レイヤ２０５との間のデータ転送は、ＰＤＣＰレイヤ２０４を介して行われる。

ＲＲＣレイヤ２０６は、無線リソースを制御するレイヤであり、ＮＡＳレイヤ２０７に対して接続される。

ＲＬＣレイヤ２０３とアプリケーション・レイヤ２０５との間の制御情報の転送は、ＲＲＣレイヤ２０６及びＮＡＳレイヤ２０７を介して行われる。

現状のＷ−ＣＤＭＡ（３ＧＰＰ ＵＭＴＳ）には、ＨＳＤＰＡ（Ｈｉｇｈ Ｓｐｅｅｄ Ｄｏｗｎｌｉｎｋ Ｐａｃｋｅｔ Ａｃｃｅｓｓ ： ３ＧＰＰ Ｒｅｌｅａｓｅ．５から導入）、Ｅ−ＤＣＨ（Ｅｎｈａｎｃｅｄ ＤＣＨ ： ３ＧＰＰ Ｒｅｌｅａｓｅ．６から導入）などの機能が追加されている。これらの追加に伴い、アップリンク（Ｕｐｌｉｎｋ）、ダウンリンク（Ｄｏｗｎｌｉｎｋ）共に高スループット化の実現が進んでいる。また、今後も、携帯電話機においては高スループットを実現するために処理削減の必要性が常に存在する。

ダウンリンクの無線帯域が大きくなる場合、一定時間に処理しなくてはならないデータ量が増えることとなる。すなわち、ＲＬＣ ＰＤＵ（ＰＤＵ：Ｐｒｏｔｏｃｏｌ Ｄａｔａ Ｕｎｉｔ）のサイズが固定であると仮定すると、ＲＬＣレイヤ２０３において一定時間に処理しなくてはならないＲＬＣ ＰＤＵの個数が増えることとなる。一般的に、一定時間内に処理すべきＲＬＣ ＰＤＵの個数が増えることは、ＲＬＣレイヤ２０３において一定時間内に処理すべきステップ数が増えることとなり、処理負荷の増大に繋がる。

このことをＨＳＤＰＡの環境下において具体的な数値に当てはめると以下のようになる。

図１４は、ＲＬＣレイヤ２０３において１ＴＴＩ内に受信したＨＳ−ＤＳＣＨのトランスポート・ブロックの最大ビット数と、ＲＬＣレイヤ２０３において１ＴＴＩ内に処理すべきＲＬＣ ＰＤＵの理論上の最大数との対応関係を、ＨＳＤＰＡのカテゴリ毎に示す図である。なお、１ＴＴＩ（ＴＴＩ：Ｔｒａｎｓｍｉｔ Ｔｉｍｅ Ｉｎｔｅｒｖａｌ）は２ｍｓｅｃ、ＲＬＣ ＰＤＵのデータ・サイズは４２バイトであるものとする。また、ＨＳＤＰＡのカテゴリ６の環境下ではダウンリンクのレートは最大３．６Ｍｂｐｓ、同カテゴリ８の環境下ではダウンリンクのレートは最大７．２Ｍｂｐｓ、同カテゴリ１０の環境下ではダウンリンクのレートは最大１４．４Ｍｂｐｓである。

ここで、ＭＡＣ−ｈｓ（ＨＳ−ＤＳＣＨ向けＭＡＣ）で使用するＭＡＣ−ｈｓヘッダのサイズは、通信経路が１つだけの基本的なチャネル・コンフィグレーションの場合には２１ビットとなる。

このため、図１４に示す値（最大数）は、“ＭＡＣ−ｈｓヘッダのサイズ＝２１ビット”として、次の計算式（１）に当てはめて求めた値である。

（１ＴＴＩに処理すべきＲＬＣ ＰＤＵの理論上の最大数）＝（１ＴＴＩ内に受信したＨＳ−ＤＳＣＨのトランスポート・ブロックの最大ビット数）／３３６（ビット）・・・・・・計算式（１）
図１４に示すように、帯域が広がるほど、ＲＬＣレイヤ２０３において一定時間（１ＴＴＩ）内に処理しなければならないＲＬＣ ＰＤＵの個数が増えることとなる。

図１５は、通信経路が１つだけの基本的なチャネル・コンフィグレーションの場合において、データ・フレームの名称及び形態がレイヤ毎にどのように変化するのかを示す図である。

図１５に示すように、ＲＬＣ ＰＤＵは、１６ビットのＲＬＣ ＡＭ（ＡＭ：Ａｃｋｎｏｗｌｅｄｇｅ Ｍｏｄｅ：確認モード）ヘッダと、３２０ビットのペイロード部と、からなる３３６ビットのフレームである。

また、ＭＡＣ−ｄ ＰＤＵ（個別チャネル向けＭＡＣ）も、３３６ビットのフレームである。

ＭＡＣ−ｈｓ ＳＤＵ（ＳＤＵ：Ｓｅｒｖｉｃｅ Ｄａｔａ Ｕｎｉｔ）は、２１個分のＭＡＣ−ｄＰＤＵ（２１×３３６＝７０５６ビット）に２２１ビットのパディング（Ｐａｄｄｉｎｇ）を加えてなる合計７２７７ビットのフレームである。

ＭＡＣ−ｈｓ ＰＤＵは、ＭＡＣ−ｈｓ ＳＤＵにＭＡＣ−ｈｓヘッダを加えてなるフレームである。例えば、１個のＭＡＣ−ｈｓ ＳＤＵに２１ビットのＭＡＣ−ｈｓヘッダを加えてなるＭＡＣ−ｈｓ ＰＤＵの場合は、合計７２９８ビットのフレームになる。このＭＡＣ−ｈｓ ＰＤＵがトランスポート・ブロックとなる。

次に、ＲＬＣ ＰＤＵの構造及びプロトコル規定について説明する。

図１６はＲＬＣ ＰＤＵの構造を示す図である。

ＲＬＣ ＰＤＵの構造は「３ＧＰＰ ＴＳ２５．３２２ Ｃｈａｐｔｅｒ９．２ Ｆｏｒｍａｔｓ ａｎｄ ｐａｒａｍｅｔｅｒｓ」に規定されている。

図１７はＲＬＣ ヘッダを構成している各識別情報のデータ量及び内容を示す図である。各識別情報は、一般的には、ヘッダのＩＥ（Ｉｎｆｏｒｍａｔｉｏｎ Ｅｌｅｍｅｎｔ：情報要素）と称される。

図１７に示すように、「Ｄ／Ｃ」は、コントロールＰＤＵ（Ｃｏｎｔｒｏｌ ＰＤＵ：制御用ＰＤＵ）とデータＰＤＵ（Ｄａｔａ ＰＤＵ）とを識別するための、１ビットのＤ／Ｃフィールドである。すなわち、Ｄ／Ｃフィールドの値が「０」であれば、ＲＬＣ ＰＤＵがコントロールＰＤＵであることを示し、Ｄ／Ｃフィールドの値が「１」であれば、ＲＬＣ ＰＤＵがデータＰＤＵであることを示す。

また、「シーケンス・ナンバー（Ｓｅｑｕｅｎｃｅ Ｎｕｍｂｅｒ：以下、ＳＮと略記）」は、ＰＤＵのシーケンス・ナンバーを示す１２ビットのデータである。すなわち、ＳＮは、０〜４０９５までの何れかの値となる。なお、ＰＤＵの数が４０９６個を超える場合、シーケンス・ナンバーは循環的に使用される。

「Ｐ」は、送達確認（Ｓｔａｔｕｓ Ｒｅｐｏｒｔ）の要求の有無を示すための、１ビットのポーリング・ビット（Ｐｏｌｌｉｎｇ ビット）である。「Ｐ」の値が「０」であれば送達確認が要求されていないことを示し、「Ｐ」の値が「１」であれば送達確認が要求されていることを示す。

「ＨＥ」は、後続データとしてレングス・インジケータ（Ｌｅｎｇｔｈ Ｉｎｄｉｃａｔｏｒ）が存在するか否かを識別するための２ビットのヘッダ・エクステンション・タイプ（Ｈｅａｄｅｒ Ｅｘｔｅｎｓｉｏｎ Ｔｙｐｅ）である。「ＨＥ」の値が「００」であれば、次の８ビットがデータであることを示し、「ＨＥ」の値が「０１」であれば、次の８ビットがレングス・インジケータと後述する「Ｅ（Ｅ ビット）」とを含むことを示す。

「Ｅ」は、１ビットのエクステンション・ビット（Ｅｘｔｅｎｓｉｏｎ ｂｉｔ）である。「Ｅ」の値が「０」であれば、次のフィールドが、データ、ピギーバック・ステータスＰＤＵ（ｐｉｇｇｙｂａｃｋｅｄ ＳＴＡＴＵＳ ＰＤＵ）及びパディング（ｐａｄｄｉｎｇ）のうちの何れかであることを示す。また、「Ｅ」の値が「１」であれば、次のフィールドがレングス・インジケータ及びＥ ｂｉｔであることを示す。

「レングス・インジケータ（Ｌｅｎｇｔｈ Ｉｎｄｉｃａｔｏｒ（ＬＩ））」は、バイト数が可変である。ＬＩは、ＲＬＣ ＳＤＵを構成するＰＤＵのうち最終セグメント（ｓｅｇｍｅｎｔ）を構成するＰＤＵを示すために用いられる。

例えば、ＬＩの値が［００１０１００（＝２０）］であれば、該ＬＩを有するＰＤＵにおける２０バイト目がＳＤＵの終端（データの終端）である旨を示す。

また、ＬＩの値が［１１１１１１１］であれば、残りのデータはパディングである旨を示す。

ここで、ＴＣＰ／ＩＰを使用するような一般的な環境下におけるＲＬＣ ＰＤＵの特性を考える。

図１８は、ＲＬＣ ＳＤＵのサイズ＝１５００バイト、ＲＬＣ ＰＤＵのサイズ＝４２バイトの環境下において、ＲＬＣ ＳＤＵとＲＬＣ ＰＤＵとの対応を示す図である。

図１８に示すように、ＲＬＣ ＳＤＵのサイズ＝１５００バイト、ＲＬＣ ＰＤＵのサイズ＝４２バイトであれば、１個のＲＬＣ ＳＤＵは３８個のセグメントに分割される。

そして、各セグメントにヘッダが付加されることにより、それぞれＲＬＣ ＰＤＵを構成する。

この場合、先頭セグメント（Ｎｏ．１）から３７個目（Ｎｏ．３７）までの合計３７個のセグメントについては、データ・サイズが４０バイトである。また、これら３７個のセグメントについては、付加されるヘッダ内のＰ（ポーリング・ビット）の値が「０」、ＨＥ（ヘッダ・エクステンション・タイプ）の値が「００」であり、送達確認の要求がないとともに、ＬＩ（レングス・インジケータ）が付加されない。

最終セグメント（Ｎｏ．３８）のみ、データ・サイズが、例えば２０バイトである（１５００−３７×４０＝２０のため）。この最終セグメントについては、付加されるヘッダ内のＰ（ポーリング・ビット）の値が「１」、ＨＥ（ヘッダ・エクステンション・タイプ）の値が「０１」であり、送達確認の要求が有るとともに、ＬＩ（レングス・インジケータ）が付加される。

なお、これら３８個のＲＬＣ ＰＤＵには、連続するＳＮ（シーケンス・ナンバー）が付与される（例えば、図１８の例では、０〜３７のＳＮを付与している）。

図１９は、ＲＬＣ ＰＤＵのサイズが４２バイト、ＲＬＣ ＳＤＵのサイズが１５００バイトの環境下における一般的なダウンリンク・データ転送の動作を示す模式図である。すなわち、図１９は、Ｗ−ＣＤＭＡの通信システムにおいて想定されている無線インターフェイスのプロトコル階層のうち、ＭＡＣレイヤ２０２からＲＬＣレイヤ２０３へのデータ転送と、ＲＬＣレイヤ２０３からＰＤＣＰレイヤ２０４への、ダウンリンク時のデータ転送の一般的な動作を示す。

ＭＡＣ−ｈｓのペイロード部にはＲＬＣヘッダが含まれているため、一般的には、図１９に示すように、ＭＡＣレイヤ２０２からＲＬＣレイヤ２０３へは、ＲＬＣ ＰＤＵをそのままの形で転送する（受け渡す）。

すなわち、図１９に示すように、ＭＡＣレイヤ２０２からＲＬＣレイヤ２０３へとＲＬＣ ＳＤＵ（＝１５００バイト）１個分のデータ転送を行うに際しては、ＳＮ＝０〜３７の合計３８個のＲＬＣ ＰＤＵをＭＡＣレイヤ２０２からＲＬＣレイヤ２０３へと受け渡す。

また、ＲＬＣレイヤ２０３からＰＤＣＰレイヤ２０４へのデータ転送においては、ＲＬＣレイヤ２０３において個々のＲＬＣ ＰＤＵのペイロード部を結合することによりＲＬＣ ＳＤＵを生成し、該生成したＲＬＣ ＳＤＵを上位レイヤであるＰＤＣＰレイヤ２０４へと受け渡す。

すなわち、図１８に示すように、ＲＬＣレイヤ２０３からＰＤＣＰレイヤ２０４へのデータ転送においては、３８個の各ＲＬＣ ＰＤＵからそれぞれヘッダを除いたペイロード部の各々を１つに結合することによりＲＬＣ ＳＤＵを生成し、該生成したＲＬＣ ＳＤＵをＲＬＣレイヤ２０３からＰＤＣＰレイヤ２０４へと受け渡す。

図２０は、図１９とは逆に、一般的なアップリンク・データ転送の動作を示す模式図である。この場合も、ＲＬＣ ＰＤＵのサイズが４２バイト、ＲＬＣ ＳＤＵのサイズが１５００バイトの環境下における動作を示す。すなわち、図２０は、ＰＤＣＰレイヤ２０４からＲＬＣレイヤ２０３へのデータ転送と、ＲＬＣレイヤ２０３からＭＡＣレイヤ２０２へのデータ転送の一般的な動作を示す。

図２０に示すように、ＰＤＣＰレイヤ２０４からＲＬＣレイヤ２０３へと１個のＲＬＣ ＳＤＵをデータ転送するに際しては、一纏まりのＲＬＣ ＳＤＵをＰＤＣＰレイヤ２０４からＲＬＣレイヤ２０３へと送信する。

また、ＲＬＣレイヤ２０３からＭＡＣレイヤ２０２へのデータ転送においては、ＲＬＣ ＳＤＵをＳＮ＝０〜３７の合計３８個のデータに分割し、各データにヘッダを付与することにより、合計３８個のＲＬＣ ＰＤＵを生成する。そして、これら３８個のＲＬＣ ＰＤＵをＲＬＣレイヤ２０３からＭＡＣレイヤ２０２へと受け渡す。

なお、本発明に関連する先行技術文献としては、特許文献１−３がある。

特許文献１−３には、複数のフレームを結合して他のレイヤへ転送する通信処理を行う技術が開示されている。
特開２０００−０５９４３５号公報 特開２００５−３１８２１１号公報 特開２００８−００５４９３号公報

上述のように、無線の帯域が増加する場合、一定時間に処理しなくてはならないデータ量が増えることとなる。すなわち、ＲＬＣ ＰＤＵのサイズが固定であると仮定すると、ＲＬＣレイヤ２０３では一定時間に処理しなくてはならないＲＬＣ ＰＤＵの個数が増えることとなる。一般的に、一定時間内に処理すべきＲＬＣ ＰＤＵの個数が増えることは、ＲＬＣレイヤ２０３において一定時間内に処理すべきステップ数が増えることとなり、処理負荷の増大に繋がる。そのため、データ量が増加しても、処理すべきＲＬＣ ＰＤＵの個数が増えないような仕組みが有効である。

特許文献１記載の通信装置では、ヘッダを含む複数のフレームの、ヘッダ以外の部分（特許文献１では「パケット」と表現）を結合する。そして、結合した「パケット」に対して１個のヘッダのみを付加する。これによって、オーバーヘッドを減少させ、パケットの効率的な伝送を可能にしている（［０００９］、［００１１］等）。

特許文献２記載の通信装置では、複数のＴＴＩ分のＰＤＵをまとめて、他のレイヤへ出力する。これによって、ヘッダなどのオーバーヘッド情報を低減している（［００９４］、［００９８］等）。

特許文献３記載の通信装置では、複数のＰＤＣＰ ＰＤＵを、ＲＬＣ ＰＤＵとして結合・連結する。これによって、ＰＤＣＰシーケンス番号が１個のみとなり、無線資源が節約される（［００１６］等）。

このように、特許文献１−３記載の通信装置では、送信、あるいは他のレイヤに受け渡されるフレームの個数が削減され、ヘッダ部によるオーバーヘッドは確かに減少する。

ところが、一般の通信装置で取り扱われるフレームに含まれるヘッダの内容は複雑であり、シーケンス・ナンバー（ＳＮ）のような単純な情報のみではない。ＳＮは、その値の連続性を利用することができるので、複数のフレームについて１個のＳＮを代表として付加することも可能である。

しかし、ＳＮ以外のヘッダ情報、例えば、各レイヤにおけるプロトコル処理の種類を識別するようなヘッダ情報の場合は、全フレームについて同一でないことが一般的である。当然ながら、このようなヘッダ情報は、他のフレームのヘッダ情報から類推することはできない。

例えば、ＭＡＣ ＰＤＵの１個目から３７個目まではＰ＝０であるが、３８個目はＰ＝１である。このような場合は、各ＭＡＣ ＰＤＵについてＰ＝０であるか否かを見極めた上で、各フレームのヘッダ情報の削除の可否を判断し、そしてフレームを統合しなければならない。

しかし、特許文献１−３記載の通信装置では、ヘッダを削除しフレームを結合する際には、各フレームのヘッダ情報の内容を判別した上で行う必要があることについて、全く考慮されていない。そのため、複数のフレームの各ヘッダ情報の内容が異なる場合に対応することができない。すなわち、特許文献１−３記載の通信装置では、ヘッダ情報が同一ではないという一般的な場合において、ヘッダの削除及びフレームの結合という方法を用いることができない。

そのため、特許文献１−３記載の通信装置には、一般的な場合に、オーバーヘッドを削減することによって、通信効率を向上させることができないという課題がある。あるいは、特許文献１−３記載の通信装置には、一般的な場合に、通信処理装置内で管理するフレームの数を減少させることによって、通信処理装置の処理負荷を低減することができないという課題がある。

本発明は、上記のような問題点を解決することが可能な通信処理装置、通信処理方法及びそのプログラムを提供することを目的とする。

上記課題を解決するため、本発明の通信処理装置は、第１のレイヤにおける通信処理を行う第１のレイヤ処理手段を備え、前記第１のレイヤ処理手段は、データと、第２のレイヤにおいて前記データに対する所定の通信処理に用いられる識別情報と、を含む複数の第１のフレームのうち、前記データを相互に結合する第１のフレームを、前記識別情報の内容に応じて判別する第１の処理と、前記データを結合すると判別された前記第１のフレームの前記データを相互に結合した結合データと、前記結合データに含まれる前記データに対して前記第２のレイヤにおいて行う通信処理の内容を示す結合データ用識別情報と、を含む第２のフレームを生成する処理と、前記第２のフレームを、前記第２のレイヤにおける通信処理を行う第２のレイヤ処理手段へ受け渡す処理と、を行うことを特徴とを特徴としている。

また、本発明の通信処理装置は、第１のレイヤにおける通信処理を行う第１のレイヤ処理手段を備える通信処理装置において、前記第１のレイヤ処理手段は、第１のデータと、第１のデータ用識別情報と、を含む第１のフレームの前記第１のデータを複数の第２のデータに分割する処理と、前記通信処理装置からのデータ送信先の通信処理装置が前記第２のデータの各々に対して第２のレイヤにおいて行う第１の通信処理に用いられる識別情報を、前記第１のデータ用識別情報に基づいて各第２のデータ毎に生成する処理と、個々の前記第２のデータと、前記第２のデータ毎に生成された識別情報と、を含む第２のフレームを生成する処理と、各第２のフレームを、前記データ送信先の通信処理装置宛に送信する処理と、を行うことを特徴としている。

また、本発明の通信処理方法は、少なくとも第１のレイヤにおける通信処理を行う通信処理方法において、前記第１のレイヤにおける通信処理は、データと、第２のレイヤにおいて前記データに対する所定の通信処理に用いられる識別情報と、を含む複数の第１のフレームのうち、前記データを相互に結合する第１のフレームを、前記識別情報の内容に応じて判別する工程と、前記データを結合すると判別された前記第１のフレームの前記データを相互に結合した結合データと、前記結合データに含まれる前記データに対して前記第２のレイヤにおいて行う通信処理の内容を示す結合データ用識別情報と、を含む第２のフレームを生成する工程と、前記第２のフレームを前記第２のレイヤへ受け渡す工程と、を備えることを特徴としている。

また、本発明の通信処理方法は、データ送信元の通信処理装置からデータ送信先の通信処理装置へのデータ送信を行う通信処理方法において、前記データ送信元の通信処理装置は、少なくとも第１のレイヤにおける通信処理を行い、前記第１のレイヤにおける通信処理は、第１のデータと、第１のデータ用識別情報と、を含む第１のフレームの前記第１のデータを複数の第２のデータに分割する工程と、前記データ送信先の通信処理装置が前記第２のデータの各々に対して第２のレイヤにおいて行う所定の通信処理、に用いられる識別情報を、前記第１のデータ用識別情報に基づいて各第２のデータ毎に生成する工程と、個々の前記第２のデータと、前記第２のデータ毎に生成された識別情報と、を含む第２のフレームを生成する工程と、各第２のフレームを、前記データ送信先の通信処理装置宛に送信する工程と、を備えることを特徴としている。

また、本発明のプログラムは、少なくとも第１のレイヤにおける通信処理をコンピュータに実行させるプログラムにおいて、前記第１のレイヤにおける通信処理は、データと、第２のレイヤにおいて前記データに対する所定の通信処理に用いられる識別情報と、を含む複数の第１のフレームのうち、前記データを相互に結合する第１のフレームを、前記識別情報の内容に応じて判別する処理と、前記データを結合すると判別された前記第１のフレームの前記データを相互に結合した結合データと、前記結合データに含まれる前記データに対して前記第２のレイヤにおいて行う通信処理の内容を示す結合データ用識別情報と、を含む第２のフレームを生成する処理と、前記第２のフレームを前記第２のレイヤへ受け渡す処理と、を含むことを特徴としている。

また、本発明のプログラムは、データ送信元の通信処理装置からデータ送信先の通信処理装置へのデータ送信に際し、少なくとも第１のレイヤにおける通信処理を、前記データ送信元の通信処理装置が備えるコンピュータに実行させるプログラムにおいて、前記第１のレイヤにおける通信処理は、第１のデータと、第１のデータ用識別情報と、を含む第１のフレームの前記第１のデータを複数の第２のデータに分割する処理と、前記データ送信先の通信処理装置が前記第２のデータの各々に対して第２のレイヤにおいて行う所定の通信処理、に用いられる識別情報を、前記第１のデータ用識別情報に基づいて各第２のデータ毎に生成する処理と、個々の前記第２のデータと、前記第２のデータ毎に生成された識別情報と、を含む第２のフレームを生成する処理と、各第２のフレームを、前記データ送信先の通信処理装置宛に送信する処理と、を含むことを特徴としている。

本発明によれば、第１のレイヤでは、データを相互に結合する第１のフレームを各第１のフレームの識別情報の内容に応じて判別し、該判別した第１のフレームのデータを相互に結合した結合データと、結合データに含まれるデータに対して第２のレイヤにおいて行う通信処理の内容を示す結合データ用識別情報と、を含む第２のフレームを生成し、該第２のフレームを第１のレイヤから第２のレイヤへ受け渡すので、第１のレイヤから第２のレイヤへ受け渡すフレームの数を低減することができる。よって、第２のレイヤにおける処理負荷を軽減することができる。しかも、第２のレイヤにおいて結合すべきデータ数を低減でき、その点でも第２のレイヤにおける処理負荷を軽減することができる。

或いは、本発明によれば、第１のレイヤでは、第１のデータを複数の第２のデータに分割し、「データ送信先の通信処理装置が第２のデータの各々に対して第２のレイヤにおいて行う所定の通信処理」に用いられる識別情報を各第２のデータ毎に生成し、個々の第２のデータと当該第２のデータに対応して生成された識別情報とを含む第２のフレームを生成し、各第２のフレームを送信先の通信処理装置宛に送信するので、送信元において第２のレイヤから第１のレイヤへ受け渡すフレームの数を低減することができる。よって、第２のレイヤにおける処理負荷を軽減することができる。しかも、送信元の第２のレイヤにおけるデータの分割数を低減でき、その点でも該第２のレイヤにおける処理負荷を軽減することができる。

以下、図面を参照して、本発明の実施形態に係る通信処理装置、通信処理方法及びそのプログラムについて説明する。

〔第１の実施形態〕
図１は第１の実施形態に係る通信処理装置１００の構成を示すブロック図である。

図１に示すように、本実施形態に係る通信処理装置１００は、制御部１０１と、送受信部１０２と、を備えている。

制御部１０１は、例えば、第１のレイヤにおける通信処理（以下、第１の通信処理）を行う第１のレイヤ処理手段１０３と、第２のレイヤにおける通信処理（以下、第２の通信処理）を行う第２のレイヤ処理手段１０４と、第３のレイヤにおける通信処理を行う第３のレイヤ処理手段１０５と、を備えている。

第１のレイヤ処理手段１０３は、所定の規格に従って第１のレイヤにおける第１の通信処理を行う。

同様に、第２のレイヤ処理手段１０４は所定の規格に従って第２のレイヤにおける第２の通信処理を行い、第３のレイヤ処理手段１０５は所定の規格に従って第３のレイヤにおける第３の通信処理を行う。

なお、本実施形態では、第１〜第３のレイヤは、第１、第２、第３レイヤの順に階層構造をなしている。第１のレイヤと第２のレイヤ、第２のレイヤと第３のレイヤの相互間における上位・下位の関係は特に限定されない。すなわち、上位のレイヤから順に第１、第２、第３レイヤであっても、あるいはその逆であってもよい。

送受信部１０２は、通信処理装置１００の外部（例えば、ネットワーク、或いは外部の通信処理装置）からフレームを受信する処理と、制御部１０１の制御下でフレームを通信処理装置１００の外部（例えば、ネットワーク、或いは外部の通信処理装置）に送信する処理と、を行う。

図２は第１の実施形態に係る通信処理方法の動作を示す図である。

図２に示すように、第１のレイヤ処理手段１０３は、通信処理装置１００の外部より送受信部１０２を介して複数の第１のフレームを受信する。

なお、第１のレイヤ処理手段１０３が一度に処理する第１のフレームの数は任意であるが、ここでは、簡単のため、一度に処理する第１のフレームが第１のフレーム３１、３２、３３の３つである例を説明する。

各第１のフレーム３１、３２、３３は、それぞれのデータ１、２、３と、各データ１、２、３に対して第２のレイヤにおいて行われる所定の通信処理（第２の通信処理）に用いられる識別情報と、を含む構成とされている。

第１のフレーム３１，３２は、互いに同一の識別情報１１を含む。

また、第１のフレーム３３は、識別情報１１とは異なる識別情報１２を含む。

第１のレイヤ処理手段１０３は、受信した第１のフレーム３１〜３３のうち、データを相互に結合して１つにまとめる第１のフレームを、各第１のフレームの識別情報の内容に応じて判別する。

第２のレイヤでは、識別情報１１，１２の内容に応じて、各データ１〜３に対し第２の通信処理を行う。

第２の通信処理の例としては、データ内のエラー検出、エラーを検出した場合におけるデータ送信元へのデータ再送要求（以下、単に再送要求）、データ送信元に対するデータを受信した旨の通知（以下、受信応答）、などがある。これらの処理を行うか否か、行う場合にどのような処理内容で行うか（モードの選択）などは、識別情報の内容によって指定される。また、第２のレイヤでは、識別情報が互いに同一のフレームのデータに対しては、同一の第２の通信処理を行う。

そこで、第１の実施形態では、第１のレイヤ処理手段１０３は、第２のレイヤ処理手段１０４にフレームを受け渡す際に、互いに等しい識別情報を有する第１のフレームのデータを相互に結合し、１つにまとめてから受け渡す。

具体的には、例えば、図２に示すように、第１のレイヤ処理手段１０３は、同一の識別情報１１を有する第１のフレーム３１、３２のデータ１，２を、相互に結合するデータであると判別する。そして、相互に結合すると判別したデータ１，２を結合することによって、結合データ２０を生成する。

結合データ２０に含まれるデータ１，２に対しては、第２のレイヤにおいて互いに同一の第２の通信処理を行う。このため、第１のレイヤ処理手段１０３は、結合データ２０に対しては１つの識別情報を代表識別情報（結合データ用識別情報）１３として付加する。すなわち、代表識別情報１３と結合データ２０とを含む第２のフレーム３４を生成する。なお、代表識別情報１３は、例えば、識別情報１１と同じ内容である。

そして、第１のレイヤ処理手段１０３は、第２のフレーム３４を第２のレイヤ処理手段１０４へ受け渡す。

また、第１のレイヤ処理手段１０３は、データ３を結合するとは判別されなかった第１のフレーム３３は、そのまま第３のフレーム３５として第２のレイヤ処理手段１０４へ受け渡す。

第２のレイヤ処理手段１０４は、結合データ２０に含まれる各データ１，２に対しては、識別情報１１の内容に従って、同一の第２の通信処理を行う。

また、第２のレイヤ処理手段１０４は、第３のフレーム３５のデータ３に対しては、識別情報１２の内容に従って、第２の通信処理を行う。

このように各データ１，２，３に対して第２の通信処理を行った後で、第２のレイヤ処理手段１０４は、各データ１，２，３を組み合わせて１つのフレーム、すなわち、図２に示すように第４のフレーム３６を生成し、該第４のフレーム３６を第３のレイヤ処理手段１０５へ受け渡す。

ここで、図１において、制御部１０１の第１〜第３のレイヤ処理手段１０３〜１０５は、制御部１０１の機能的構成である。

図３は制御部１０１のハードウェア構成の例を示すブロック図である。

制御部１０１は、具体的には、例えば、図３に示すように、制御動作を実行するＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）１１１と、このＣＰＵ１１１の動作用プログラムを記憶保持したＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）１１２と、ＣＰＵ１１１の作業領域などとして機能するＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）１１３と、を備えて構成されている。

そして、制御部１０１は、これらＣＰＵ１１１、ＲＯＭ１１２、ＲＡＭ１１３の協働により、第１〜第３のレイヤ処理手段１０３〜１０５として機能する。

以上のような第１の実施形態によれば、第１のレイヤでは、データを相互に結合する第１のフレーム３１，３２を各第１のフレーム３１〜３３の識別情報１１，１２の内容に応じて判別し、該判別した第１のフレーム３１，３２のデータ１，２を相互に結合して結合データ２０を生成し、代表識別情報１３（結合データ用識別情報）と結合データ２０とを含む第２のフレーム３４を生成し、該第２のフレーム３４を第２のレイヤへ受け渡すので、第１のレイヤから第２のレイヤへ受け渡すフレームの数を低減することができる。よって、第２のレイヤにおける処理負荷を軽減することができる。加えて、第２のレイヤにおいて第４のフレーム３６を生成する処理は、結合データ２０とデータ３とを組み合わせることによって行うことができるため、第２のレイヤにおける処理負荷を軽減することができる。すなわち、第２のレイヤでは、予めデータ１，２が結合されてなる結合データ２０と、データ３とを結合すればよいため、データ１，２を結合しなくて良い分、処理負荷を軽減できる。

なお、上記の第１の実施形態において、第２の通信処理の際には、結合データ２０を１つのデータとして扱い、一括して処理（受信応答の送信、再送要求の送信など）を行っても良い。ただし、このように結合データ２０に対し一括して第２の通信処理を行う場合には、通信相手の同じレイヤとの事前の取り決めが必要である。

或いは、第２の通信処理の際には、結合データ２０を結合前のデータ１，２に分割し、個々のデータ１，２に対してそれぞれ個別に、同一の処理（受信応答の送信、再送要求の送信など）を行なってもよい。

何れの場合にも、結合データ２０に付加された識別情報の内容のチェック、及びその内容に応じた第２の通信処理の種類の判別は、１つの結合データ２０に対して１回だけで済む。すなわち、結合データ２０を生成せずに、各データ１，２にそれぞれ識別情報を付加した状態で第１のレイヤから第２のレイヤへ各データ１，２を受け渡す場合と比べ、第２のレイヤ処理手段１０５の処理負荷を軽減できる。

また、受信したフレームが結合データ２０を含むフレーム（第２のフレーム）であるか、結合データ２０ではなく単体のデータを含むフレーム（第３のフレーム）であるかを第２のレイヤ処理手段１０４が判別する方法としては、次のような方法が挙げられる。

例えば、第３のフレームの長さ（データ量）を予め規定しておき、それよりも長いフレームを第２のフレームであると判別することが挙げられる。或いは、フレームの種類を識別できるような情報を、第２のフレームに含ませるか、或いは第２及び第３のフレームの双方に含ませてもよい。

或いは、結合データ２０のサイズ、或いは結合数を識別できるような情報を第２のフレームに含ませても良い。

或いは、ソフトウェアの実装による対応方法もある。例えば、あるフレームの内容が、通信処理装置内のＲＡＭのある領域に記憶されているならば、その領域を示す情報を、各レイヤ処理手段１０４、１０５の間で、パラメータとして受け渡すという方法がある。

また、上記の第１の実施形態では、通信処理装置１００が第１〜第３のレイヤ処理手段１０３〜１０５を備える例を説明したが、通信処理装置１００は、このうち第１のレイヤ処理手段１０３を少なくとも備えていれば良く、第２及び第３のレイヤ処理手段１０４、１０５は備えていなくても良い。すなわち、第２及び第３のレイヤ処理手段１０４、１０５のうちの少なくとも一方に相当する構成は、通信処理装置１００の外部の構成であっても良い。

また、上記の第１の実施形態では、第３のレイヤが存在する例を説明したが、第３のレイヤは存在しなくても良い。例えば、第２のレイヤがアプリケーション・レイヤであってもよい。この場合、第４のフレーム３６を生成する処理、及び、第２のレイヤから第３のレイヤへ第４のフレーム３６を受け渡す処理は不要であり、第３のレイヤ処理手段１０５も不要である。

＜第１の実施形態の変形例＞
上記の第１の実施形態では、第１のフレームの識別情報の全体の内容に応じて（具体的には、識別情報の全体が同一であるか否かに応じて）、データを相互に結合する第１のフレームを判別する例を説明した。

これに対し、本変形例では、識別情報の一部分の内容に応じて（例えば、識別情報の一部分が同一であるか否かに応じて）、データを相互に結合する第１のフレームを判別する例を説明する。

なお、本変形例の場合も、通信処理装置１００の構成は、上記の第１の実施形態（図１、図３）と同様である。

図４は本変形例に係る通信処理方法の動作を示す図である。

本変形例の場合、各第１のフレームは、第１の識別情報と第２の識別情報とを含む点でのみ上記の第１の実施形態と相違する。

すなわち、図４に示すように、第１のフレーム３１は、第１の識別情報としての識別情報１１と、第２の識別情報としての識別情報２１と、を含む。同様に、第１のフレーム３２は第１の識別情報としての識別情報１１と第２の識別情報としての識別情報２２とを含み、第１のフレーム３３は第１の識別情報としての識別情報１２と第２の識別情報としての識別情報２３とを含む。

このうち、第１の識別情報としての識別情報１１、１２は、上記の第１の実施形態と同様である。本変形例でも、第１のレイヤ処理手段１０３は、識別情報１１、１２の内容に応じて、データを結合する第１のフレームを判別する。

一方、第２の識別情報としての識別情報２１〜２３は、各第１のフレーム３１〜３３に固有の情報（例えば、フレームの順序を示す情報など）である。この第２の識別情報は、再送要求などに用いられる。

上記の第１の実施形態で説明したように、結合データ２０に対する第２の通信処理は、第１の識別情報１１によって指定される、データ１、データ２に共通の処理である。すなわち、第２のレイヤでは、結合データ２０に対しては、第１の識別情報１１を参照することなしに、処理の内容を判断できる。従って、第１の識別情報１１を第２のフレーム３４に含ませる必要はない。

このため、変形例の場合において結合データ２０に付加する結合データ用識別情報としては、何れか１つの第１のフレームの第２の識別情報（例えば、図４に示すように、識別情報２１）のみを用いることができる。このように、第２のフレーム３４に、第２の識別情報のみを含ませることによって、さらにヘッダ部によるオーバーヘッドを削減することができる。

なお、第２のレイヤでは、結合データ２０に含まれる各データ１，２に対しては、共通の第２の通信処理を行ってもよい。或いは、結合データ２０に対して一括して第２の通信処理を行い、さらに必要に応じて、個々のデータ１，２の第２の識別情報を結合データ用識別情報に基づいて生成し、その個別データへの所定の処理を行うこともできる。

〔第２の実施形態〕
本実施形態では、データ送信元の通信処理装置（送信装置）からデータ送信先の通信処理装置（受信装置）へフレームを送信する場合を想定する。また、本実施形態では、第１のレイヤは第２のレイヤの下位のレイヤであり、第２のレイヤは第３のレイヤの下位のレイヤであるものとする。そして、送信装置の第１のレイヤ、又はさらにそれよりも下位のレイヤから、ネットワーク、あるいは他の受信装置へフレームを送信する。

送信装置と受信装置では、第１の実施形態と同様に、第１のレイヤ、第２のレイヤの各々において、所定の規格に基づく通信処理（第１の通信処理、第２の通信処理）を行う。

なお、本実施形態の場合も、通信処理装置１００の構成は、上記の第１の実施形態（図１、図３）と同様である。

図５は第２の実施形態に係る通信処理方法の動作を示す図である。

図５に示すように、第２のレイヤ処理手段１０４（第２のレイヤ）から第１のレイヤ処理手段１０３（第１のレイヤ）へ受け渡すフレーム（第１のフレーム６１、第３のフレーム６４）は、データ（データ５１、３）と、該データに対して受信装置が第２のレイヤにおいて行う所定の通信処理に用いられる識別情報（識別情報１１、１２）と、を含む。

受信装置の第２のレイヤにおいては、識別情報が同一のフレームのデータに対しては、同じ第２の通信処理を行う。

そこで、第２の実施形態では、送信装置の第２のレイヤは、その上位の第３のレイヤから受け取った第４のフレーム６０のデータ５０を第１のレイヤに受け渡す際、第１のレイヤにおいて複数に分割されるデータ（第１のデータ）５１と、それ以外の（第１のレイヤにおいて分割されない）データ（第３のデータ）３と、に分割して受け渡す。

データ５１には１つの識別情報を代表識別情報（第１のデータ用識別情報）１４として付加することにより第１のフレーム６１を生成し、この第１のフレーム６１を第１のレイヤへ受け渡す。

すなわち、第４のフレーム６０のデータ５０のうち、第１のレイヤにおいて分割された際に、代表識別情報１４を元に生成できる識別情報１１が付加されるデータ１，２のかたまりであるデータ５１には、代表識別情報１４を付加してから第１のレイヤへ受け渡す。

つまり、第２のレイヤ処理手段１０４は、データ５１と代表識別情報１４とを含む第１のフレーム６１を生成し、該第１のフレーム６１を第１のレイヤ処理手段１０３へ受け渡す。

また、その他のデータ３、すなわち代表識別情報１４を元に生成できない識別情報１２が付加されるデータ３には、第２のレイヤにおいて識別情報１２を付加してから第１のレイヤへ受け渡す。

つまり、第２のレイヤ処理手段１０４は、データ３と識別情報１２とを含む第３のフレーム６４を生成し、この第３のフレーム６４を第１のレイヤ処理手段１０３へ受け渡す。

ここで、データ５０をデータ５１とデータ３とに分割する方法としては、例えば、規定のサイズの整数倍のデータ５１と、その端数のサイズ（＝規定のサイズ未満）のデータであってデータ５０からデータ５１を除いた残りのデータ３と、に分割する方法が挙げられる。

或いは、データ５０が規定のサイズの整数倍である場合には、データ５０の終端部のデータのみを規定のサイズに切り取ってデータ３とし、残りの全体をデータ５１（規定のサイズの整数倍となる）としても良い。

第１のレイヤ処理手段１０３は、第１のフレーム６１を受けると、該第１のフレーム６１のデータ５１を複数のデータ１，２に分割する。そして、分割した各データ１，２に対しては、代表識別情報１４に基づいて個別の識別情報１１を生成し、該識別情報１１を付加する。これにより、第２のフレーム６２、６３をそれぞれ生成する。なお、識別情報１１の内容は、代表識別情報１４と同一であっても良い。

更に、第１のレイヤ処理手段１０３は、生成した第２のフレーム６２，６３を受信装置宛に送信する。

また、第１のレイヤ処理手段１０３は、第３のフレーム６４を受けると、該第３のフレーム６４をそのまま受信装置宛に転送する。

以上のような第２の実施形態によれば、第１のレイヤでは、データ５１を複数のデータ１、２に分割し、「データ送信先の通信処理装置がデータ１、２の各々に対して第２のレイヤにおいて行う所定の通信処理」に用いられる識別情報１１をデータ１、２毎に生成し、個々のデータ１、２と各データ１、２に対応して生成された識別情報１１とを含む第２のフレーム６２、６３を生成し、各第２のフレーム６２、６３を送信先の通信処理装置宛に送信するので、送信元において第２のレイヤから第１のレイヤへ受け渡すフレームの数を低減することができる。すなわち、第１のレイヤにおいて複数に分割されるデータ５１を第１のフレーム６１の形態でまとめて第２のレイヤから第１のレイヤへ受け渡すので、第４のフレーム６０のデータ５０を規定のサイズの多数のデータに分割して第２のレイヤから第１のレイヤへ受け渡す場合と比べて、第２のレイヤから第１のレイヤへ受け渡すフレームの個数を削減できる。よって、第２のレイヤにおける処理負荷を軽減することができる。しかも、送信元の第２のレイヤにおけるデータ５０の分割数を低減でき、その点でも該第２のレイヤにおける処理負荷を軽減することができる。

また、第１のレイヤでは、各々の通常フレームへの通信処理、例えば識別情報の追加といった処理の回数が削減できる。すなわち、データ５１を分割することにより生成した個々のデータ１，２に対する処理が、条件判断などが不要な、共通の処理の繰り返しとなる。従って、第１のレイヤにおける処理負荷も軽減できる。

第１のレイヤにおいて複数に分割されるデータ５１を含むフレーム（第１のフレーム６１）であるか、分割されないデータ３を含むフレーム（第３のフレーム６４）であるかの判別、すなわちフレームの種類の判別は、第１の実施形態で説明したのと同様の方法によって行うことが可能である。

＜第２の実施形態の変形例＞
第２の実施形態においても、上記の第１の実施形態の変形例と同様に、識別情報に第１の識別情報と第２の識別情報とを含ませても良い。

本変形例の場合も、通信処理装置１００の構成は、上記の第１の実施形態（図１、図３）と同様である。

図６は本変形例に係る通信処理方法の動作を示す図である。

この場合、データ５１を分割することにより生成されるデータ１，２に対する第１のレイヤでの通信処理が共通なので（第１の識別情報が共通の識別情報１１）、第１のフレーム６１には第１の識別情報を含ませる必要がない。そして、データ１，２の何れかの第２の識別情報（識別情報２１又は２２）のみを代表識別情報として第１のフレーム６１に使用することができる。第１のレイヤでは、データ５１を分割することにより生成されるデータ１，２に対しては、予め第１の識別情報が判明しているので、それを識別情報１１として追加し、さらに必要に応じて、代表識別情報に基づいて、個別データの第２の識別情報を生成して追加し、第２のフレームを構成することもできる。

〔第３の実施形態〕
次に、第３の実施形態を説明する。

本実施形態では、背景技術の項において詳述したようなＷ−ＣＤＭＡの規定に従ったダウンリンク・データ転送について説明する。

図７は本実施形態に係る通信処理装置１００の構成を示すブロック図である。

本実施形態の場合、制御部１０１は、図１３に示す各レイヤにおける通信処理を行うように構成されている。

すなわち、制御部１０１は、ＰＨＹ（物理）レイヤ２０１における通信処理を行うＰＨＹ（物理）レイヤ処理手段３０１と、第１のレイヤとしてのＭＡＣレイヤ２０２における通信処理を行うＭＡＣレイヤ処理手段（第１のレイヤ処理手段）３０２と、第２のレイヤとしてのＲＬＣレイヤ２０３における通信処理を行うＲＬＣレイヤ処理手段（第２のレイヤ処理手段）３０３と、第３のレイヤとしてのＰＤＣＰレイヤ２０４における通信処理を行うＰＤＣＰレイヤ処理手段（第３のレイヤ処理手段）３０４と、アプリケーション・レイヤ２０５における通信処理を行うアプリケーション・レイヤ処理手段３０５と、ＲＲＣレイヤ２０６における通信処理を行うＲＲＣレイヤ処理手段３０６と、ＮＡＳレイヤ２０７における通信処理を行うＮＡＳレイヤ処理手段２０８と、を備えて構成されている。

なお、本実施形態の場合も、制御部１０１のハードウェア構成は、上記の第１の実施形態（図３）と同様である。

本実施形態では、以下に説明するように、主としてＭＡＣレイヤ（第１のレイヤ）２０２からＲＬＣレイヤ（第２のレイヤ）２０３へのデータ転送処理を改善する。すなわち、ダウンリンク・データ転送におけるＲＬＣレイヤ２０３の処理削減を実現する。

例えば、インターネット上のＷＥＢサイトを閲覧したり、大容量のファイルをダウンロードしたり、或いは、アップロードを実施するようなノンリアルタイム（ｎｏｎ−ｒｅａｌ ｔｉｍｅ）サービスを使用する場合、セッション（Ｓｅｓｓｉｏｎ）確立時のチャネル・コンフィグレーションの際、ＲＬＣのモードとしては、データの送達確認が行われるＲＬＣ ＡＭ（ＡＭ：Ａｃｋｎｏｗｌｅｄｇｅ Ｍｏｄｅ）がネットワークから設定される。よって、本実施形態では、ＲＬＣ ＡＭを使用した場合の動作を説明する。

ＲＬＣ ＡＭの場合、上位２バイトのＲＬＣ ＡＭ ヘッダ（図１５参照）は、Ｄ／Ｃ、ＳＮ（シーケンス・ナンバー）、送達確認を要求するＰ（ポーリングビット）、及び、後続データとしてレングス・インジケータが存在するか否かを識別するＨＥ（ヘッダ・エクステンション・タイプ）で構成される（図１６参照）。

これらＤ／Ｃ、ＳＮ、Ｐ、及びＨＥは、第２のレイヤとしてのＲＬＣレイヤ２０３において、第２のフレームとしてのＲＬＣ ＰＤＵに含まれるデータ（通信経路が一つしかない、典型的なパターンの場合、第１のフレームとしてのＭＡＣ−ｄ ＰＤＵに含まれるデータに等しい）対して行われる所定の通信処理に用いられる識別情報である。

ここで、ＲＬＣ ＡＭヘッダ内の各情報は、各ＲＬＣ ＰＤＵに共通の値が設定されることが多い第１の識別情報と、ＲＬＣ ＰＤＵ毎に異なる第２の識別情報に分類することができる。例えば、Ｄ／Ｃ、Ｐ、及びＨＥは第１の識別情報に、ＳＮは第２の識別情報に分類することができる。

本実施形態の場合、ＭＡＣレイヤ処理手段３０２は、ＭＡＣ−ｄ ＰＤＵ（第１のフレーム）を送受信部１０２及びＰＨＹレイヤ処理手段３０１を介してネットワークより受信する。

ＭＡＣレイヤ処理手段３０２は、ＭＡＣ−ｄ ＰＤＵを受信すると、各ＭＡＣ−ｄ ＰＤＵの先頭２バイト（ＲＬＣ ＡＭ ヘッダに相当する）を構成する識別情報（Ｄ／Ｃ、ＳＮ、Ｐ、及びＨＥ）の内容に応じて、複数のＭＡＣ−ｄ ＰＤＵのうち、それに含まれるデータを相互に結合するＭＡＣ−ｄ ＰＤＵを判別する。

ここで、ＲＬＣレイヤ２０３では、受信したフレームにＤ／Ｃ＝１が設定され、且つ、Ｐ＝１が設定されているという「第１の条件」を満たす場合には、ネットワークに対し送達確認を送信する。

また、受信したフレームにＤ／Ｃ＝１が設定され、且つ、ＨＥ＝０１が設定されている（すなわちフレームがＬＩを含む）という「第２の条件」を満たす場合には、ＲＬＣレイヤ２０３では、当該フレームのペイロード部がＲＬＣ ＳＤＵの最後のセグメントを構成するデータであると判断（認識）する。

ＭＡＣレイヤ処理手段３０２は、これら第１及び第２の条件のうちの少なくとも何れか一方を満たすフレームに対しては、「ＲＬＣレイヤ２０３における所定のプロトコル処理が必要である」と判定する。

ＭＡＣレイヤ処理手段３０２は、逆に、第１及び第２の条件の何れも満たさないフレームに対しては、「ＲＬＣレイヤ２０３における所定のプロトコル処理が不要である」と判定する。すなわち、Ｄ／Ｃ＝１が設定されているフレームであっても、ＨＥ＝００（ＨＥ＝０１でない。すなわち、ＬＩが存在しない）、且つ、Ｐ＝０（送達確認が不要）が設定されているフレームに対しては、「ＲＬＣレイヤ２０３における所定のプロトコル処理が不要である」と判定する。

なお、Ｄ／Ｃ＝１が設定されているフレーム（すなわちデータＰＤＵ）のデータは、ＲＬＣレイヤ２０３からＰＤＣＰレイヤ２０４を介してアプリケーション・レイヤ２０５へと受け渡される。

対して、Ｄ／Ｃ＝０が設定されているフレーム（すなわちコントロールＰＤＵ）は、ＲＬＣレイヤ２０３からＲＲＣレイヤ２０６及びＮＡＳレイヤ２０７を介してアプリケーション・レイヤ２０５へと受け渡される。

本実施形態では、以下、データＰＤＵ（Ｄ／Ｃ＝１）の流れについてのみ説明し、コントロールＰＤＵ（Ｄ／Ｃ＝０）の流れについては説明を省略する。

図１８にて説明したように、ＲＬＣ ＰＤＵのサイズが４２バイト、ＲＬＣ ＳＤＵのサイズが１５００バイトの環境下においては、１個のＲＬＣ ＳＤＵから３８個のＲＬＣ ＰＤＵが生成される。

また、一般的には、これら３８個のＲＬＣ ＰＤＵのうち、先頭セグメント（Ｎｏ．１）を含むＲＬＣ ＰＤＵから３７個目のセグメント（Ｎｏ．３７）を含むＲＬＣ ＰＤＵまでについては、ぞれぞれＰ＝０、ＨＥ＝００が設定され、最終セグメント（Ｎｏ．３８）を含むＲＬＣ ＰＤＵについてのみ、Ｐ＝１、ＨＥ＝０１が設定されている。

つまり、実環境下においては殆どのＲＬＣ ＰＤＵは所定のプロトコル処理が不要なＲＬＣ ＰＤＵである。

なお、ＳＮがどの値であるＲＬＣ ＰＤＵにＰを付加するかは、ネットワークのコンフィグレーションに応じて異なる。図１８には、ＲＬＣ ＳＤＵの最終セグメントを含むＲＬＣ ＰＤＵにＰが付加されるケースを図示したが、ネットワークからの設定によっては、Ｐが付加されないＲＬＣ ＰＤＵを受信した場合でも、ＳＮ欠損を検出したときに、送達確認を送信することがある。

本実施形態では、ＲＬＣ ＳＤＵから複数のＰＤＵを生成した際に、実運用環境下においては、殆どのＲＬＣ ＰＤＵはＲＬＣレイヤ２０３における所定のプロトコル処理が不要なＰＤＵとなるという特性を利用する。

すなわち、ＭＡＣレイヤ２０２においては、ＲＬＣレイヤ２０３における所定のプロトコル処理が不要であり、且つ、連続したＳＮを持つＲＬＣ ＰＤＵについては、個々のＲＬＣ ＰＤＵの形でＲＬＣレイヤ２０３にデータを受け渡すのではなく、それらを結合したフレームの形で転送する。これにより、あたかもＲＬＣレイヤ２０３において処理しなければならないＲＬＣ ＰＤＵの個数を減らすかのような動作とする。

ＭＡＣレイヤ２０２においては、上記所定のプロトコル処理が不要であり、且つ、ＳＮが連続したＲＬＣ ＰＤＵについては、それらのペイロード部を結合することにより生成されるフレームを、あたかもサイズが大きい１つのＲＬＣ ＰＤＵであるかのように扱って、ＲＬＣレイヤ２０３へ転送する。

ＲＬＣレイヤ２０３においては、例えば、規定のサイズ（具体的には、例えば、４２バイト）とは異なるフレームをＭＡＣレイヤ２０２から受けた場合、ＳＮが連続した複数のＲＬＣ ＰＤＵのペイロード部が結合されて転送されてきたと認識し、処理する。

なお、この規定のサイズは、セッション確立時にネットワークから通知され、制御部１０１のＲＡＭ１１３に記憶保持される。

図８は、本実施形態に係る通信処理方法によるダウンリンク・データ転送の動作を示す模式図である。すなわち、図８は、ＲＬＣ ＰＤＵのサイズ＝４２バイト、ＲＬＣ ＳＤＵのサイズ＝１５００バイトの環境下において、ＭＡＣレイヤ処理手段３０２が（ＭＡＣレイヤ２０２が）ＭＡＣ−ｄ ＰＤＵを受信した後の動作を示す。なお、図８に示すのは、１個のＲＬＣ ＳＤＵに相当するデータを転送する動作である。

本実施形態の場合、図８に示すように、ＭＡＣレイヤ２０２においては、ＰＨＹレイヤ２０１から受信した複数のＭＡＣ−ｄ ＰＤＵ（＝ＲＬＣ ＰＤＵ）のうち、ＲＬＣレイヤ２０３における所定のプロトコル処理が不要であり、且つ、ＳＮ（シーケンス・ナンバー）が連続するＭＡＣ−ｄ ＰＤＵを相互に結合する。

これにより、ＲＬＣ ＰＤＵよりもサイズが大きいフレームＦ１を生成する。

フレームＦ１の生成に際しては、先頭のＭＡＣ−ｄ ＰＤＵのＲＬＣ ヘッダ以外は、ＲＬＣ ヘッダを省いてＲＬＣ ペイロード部のみを相互に結合する。

そして、生成したフレームＦ１を、ＭＡＣレイヤ２０２からＲＬＣレイヤ２０３へ受け渡す。

また、ＲＬＣレイヤ２０３における所定のプロトコル処理が必要なＲＬＣ ＰＤＵについては、結合せずにそのままの形でフレームＦ２としてＭＡＣレイヤ２０２からＲＬＣレイヤ２０３へ転送する。

具体的には、本実施形態の場合、図８に示すように、例えば、ＳＮ＝０のＲＬＣ ＰＤＵと、ＳＮ＝１〜３６の各ＲＬＣ ＰＤＵからヘッダを省いた残りであるペイロード部と、をＳＮの順に並べて相互に結合することによりフレームＦ１を生成し、該フレームＦ１をＭＡＣレイヤ２０２からＲＬＣレイヤ２０３へ受け渡す。

すなわち、ＳＮ＝０〜ＳＮ＝３６の合計３７個のＲＬＣ ＰＤＵを、不要なヘッダを省略して結合することによりフレームＦ１を生成し、受け渡す。

なお、本実施形態では、フレームＦ１から先頭のＲＬＣ ＰＤＵのＲＬＣヘッダを除いたものが、結合データである。また、フレームＦ１の先頭のＲＬＣ ＰＤＵのＲＬＣヘッダが、結合データ用識別情報である。

また、ＳＮ＝３７のＲＬＣ ＰＤＵは、Ｐ＝１であり、且つ、ＨＥ＝０１であるため、ＲＬＣレイヤ２０３における所定のプロトコル処理が必要なＰＤＵである。よって、結合せずにそのままの形でフレームＦ２としてＭＡＣレイヤ２０２からＲＬＣレイヤ２０３へ受け渡す。

このように、ＭＡＣレイヤ２０２は、１個のＲＬＣ ＳＤＵに相当するデータをＲＬＣレイヤ２０３へ受け渡す場合には、図８に示すように、２つのフレームＦ１、Ｆ２をＲＬＣレイヤ２０３に受け渡す。つまり、ＭＡＣレイヤ２０２は、あたかも２個のＲＬＣ ＰＤＵをＲＬＣレイヤ２０３に受け渡すかのような動作を行う。

次に、ＲＬＣレイヤ２０３においては、例えば、受け渡されたフレームのサイズが規定のサイズ（例えば、４２バイト）であるか否かを判別する。規定のサイズとは異なるデータ量のフレームを受けた場合、該フレームをフレームＦ１であると判別する。

ここで、ＲＬＣレイヤ２０３においては、規定のサイズよりも大きいサイズのフレームを受けた場合に、フレームＦ１を受けたと判別するようにしても良いのは勿論であるが、規定のサイズよりも小さいフレームの受け渡しは実際的には発生しないため、受け渡されたフレームがフレームＦ１かフレームＦ２であるかを認識するためには、規定のサイズであるか否かの判別で良い。

ＲＬＣレイヤ２０３は、規定のサイズとは異なるフレームＦ１を受けると、該フレームＦ１を、ＳＮが連続した複数のＲＬＣ ＰＤＵのペイロード部がＳＮの順に結合されてなるフレームであると認識する。

また、ＲＬＣレイヤ２０３において、規定のサイズのデータ量のフレーム、すなわちフレームＦ２を受信すると、ＲＬＣレイヤ２０３では、該フレームＦ２を、該ＲＬＣレイヤ２０３における所定のプロトコル処理が必要なＲＬＣ ＰＤＵであると認識する。

ＲＬＣレイヤ２０３では、フレームＦ２を構成するＲＬＣ ＰＤＵについては、以下のようにプロトコル処理を行う。

すなわち、フレームＦ２を構成するＲＬＣ ＰＤＵには、Ｐ＝１が設定されているので、ＲＬＣレイヤ２０３は、ネットワークに対し送達確認を送信する。

また、フレームＦ２を構成するＲＬＣ ＰＤＵには、ＬＩが含まれている（ＨＥ＝０１）ので、ＲＬＣレイヤ２０３は、該ＲＬＣ ＰＤＵをＲＬＣ ＳＤＵの最後のセグメントを構成するデータであると認識する。

一方、フレームＦ１は、ＳＮが連続した複数のＲＬＣ ＰＤＵを結合してなるフレームであり、ヘッダはＳＮ＝０の先頭のセグメントのヘッダのみが含まれている。

このため、ＲＬＣレイヤ２０３では、フレームＦ１から先頭のヘッダを除くとともに、該フレームＦ１の最後尾にフレームＦ２のペイロード部を結合することにより、ＲＬＣ ＳＤＵを生成することができる。

ＲＬＣレイヤ２０３は、このように生成したＲＬＣ ＳＤＵをＰＤＣＰレイヤ２０４へ受け渡す。

次に、図９は、第３の本実施形態の場合において、２個のＲＬＣ ＳＤＵに相当するデータを転送する動作を示す模式図である。

この場合、図９に示すように、ＳＮ＝０のＲＬＣ ＰＤＵと、ＳＮ＝１〜３６の各ＲＬＣ ＰＤＵからヘッダを省いた残りであるペイロード部と、を結合することにより、図８の場合と同様にフレームＦ１を生成し、該フレームＦ１をＭＡＣレイヤ２０２からＲＬＣレイヤ２０３へ転送する。

また、ＳＮ＝３７のＲＬＣ ＰＤＵは、ＲＬＣレイヤ２０３における処理のプロトコル処理が必要なＰＤＵ（Ｐ＝１、ＬＩ有）であるので、図８の場合と同様に、結合せずにそのままの形でフレームＦ２としてＭＡＣレイヤ２０２からＲＬＣレイヤ２０３へ転送する。

また、ＳＮ＝３８のＲＬＣ ＰＤＵと、ＳＮ＝３９〜７４の各ＲＬＣ ＰＤＵからヘッダを省いた残りであるペイロード部と、を結合することにより、フレームＦ３を生成し、該フレームＦ３をＭＡＣレイヤ２０２からＲＬＣレイヤ２０３へ転送する。

また、ＳＮ＝７５のＲＬＣ ＰＤＵは、プロトコル処理が必要なＰＤＵ（Ｐ＝１、ＬＩ有）であるので、結合せずにそのままの形でフレームＦ４としてＭＡＣレイヤ２０２からＲＬＣレイヤ２０３へ転送する。

このように、ＭＡＣレイヤ２０２は、２個のＲＬＣ ＳＤＵに相当するデータを転送する場合には、図９に示すように、４つのフレームＦ１、Ｆ２、Ｆ３、Ｆ４をＲＬＣレイヤ２０３に転送する。つまり、ＭＡＣレイヤ２０２は、あたかも４個のＲＬＣ ＰＤＵをＲＬＣレイヤ２０３に送信するかのような動作を行う。

次に、ＲＬＣレイヤ２０３においては、規定のサイズとは異なるデータ量のフレーム、すなわちフレームＦ１、Ｆ３を受信すると、これらフレームＦ１、Ｆ３を、ＳＮが連続した複数のＲＬＣ ＰＤＵ（のペイロード部）が結合されてなるフレームであると認識する。

また、ＲＬＣレイヤ２０３では、規定のサイズのデータ量のフレーム、すなわちフレームＦ２、Ｆ４を受信すると、該フレームＦ２、Ｆ４に対して、従来通りのＲＬＣ ＰＤＵに対する受信処理を行う。従って、結果的に所定のプロトコル処理が発生する。

ＲＬＣレイヤ２０３では、フレームＦ２、Ｆ４を構成するＲＬＣ ＰＤＵについては、以下のようにプロトコル処理を行う。

すなわち、フレームＦ２、Ｆ４を構成するＲＬＣ ＰＤＵには、Ｐ＝１が設定されているので、ＲＬＣレイヤ２０３は、ネットワークに対し送達確認をそれぞれ送信する。

また、フレームＦ２、Ｆ４を構成するＲＬＣ ＰＤＵには、ＬＩが含まれている（ＨＥ＝０１）ので、ＲＬＣレイヤ２０３は、該ＲＬＣ ＰＤＵをＲＬＣ ＳＤＵの最後のセグメントを構成するデータであると認識する。

一方、フレームＦ１は、ＳＮが連続した複数のＲＬＣ ＰＤＵを結合してなるフレームであり、ヘッダはＳＮ＝０の先頭のセグメントのヘッダのみが含まれている。

同様に、フレームＦ３は、ＳＮが連続した複数のＲＬＣ ＰＤＵを結合してなるフレームであり、ヘッダはＳＮ＝３８の先頭のセグメントのヘッダのみが含まれている。

このため、ＲＬＣレイヤ２０３では、フレームＦ１から先頭のヘッダを除くとともに、該フレームＦ１の最後尾にフレームＦ２のペイロード部を結合することにより、１つ目のＲＬＣ ＳＤＵ（図９に示すＲＬＣ ＳＤＵ（Ｎｏ．１））を生成することができる。

同様に、フレームＦ３から先頭のヘッダを除くとともに、該フレームＦ３の最後尾にフレームＦ４のペイロード部を結合することにより、２つ目のＲＬＣ ＳＤＵ（図９に示すＲＬＣ ＳＤＵ（Ｎｏ．２））を生成することができる。

よって、図８の動作の場合と同様に、従来と比べてＲＬＣレイヤ２０３の処理負担を軽減することができる。

ここで、ＲＬＣレイヤ２０３においては、このようにＲＬＣ ＳＤＵ（Ｎｏ．１）、ＲＬＣ ＳＤＵ（Ｎｏ．２）をそれぞれ生成するに際し、各フレームＦ１〜Ｆ４のヘッダに含まれるＳＮの値とＬＩの値に基づき、以下に説明するようにして、相互に結合するフレームを判別する。

先ず、フレームＦ１のＳＮの値は「０」であることから、該フレームＦ１内の結合されたペイロード部（結合データ）は、ＲＬＣ ＳＤＵの先頭を構成することが分かる。

また、フレームＦ３のＳＮの値は「３８」であり、ＳＮの値がフレームＦ２の続き番号であることが分かる。しかし、フレームＦ３には、ＬＩが含まれていないため、フレームＦ３は、ＳＤＵの先頭を構成することが分かる。

また、フレームＦ２、Ｆ４には、ＳＤＵの終端である旨を示すＬ１が含まれていることから、フレームＦ２、Ｆ４のペイロード部をフレームＦ１、Ｆ３のペイロード部の終端に結合させれば良いことが分かる。

このうちフレームＦ２のＳＮの値は「３７」であるため、フレームＦ２のペイロード部はフレームＦ３ではなく、フレームＦ１内のペイロード部の終端に結合させれば良いと分かる。

また、フレームＦ４のＳＮの値は「７５」であるため、フレームＦ４のペイロード部は、フレームＦ３のペイロード部の終端に結合させれば良いと分かる。

フレームＦ２のペイロード部をフレームＦ１内のペイロード部の終端に結合させる際、並びに、フレームＦ４のペイロード部をフレームＦ３のペイロード部の終端に結合させる際には、各々のＬＩにより示されているデータの終端位置に基づいて、パディングを削除する。

なお、ＬＩの値が、パディングがない旨を示す［０００００００］である場合、このＲＬＣ ＰＤＵは、フレームの先頭に結合される。この場合、パディングがない旨を示すＬＩを有するＲＬＣ ＰＤＵの前のＲＬＣ ＰＤＵのペイロード部がＳＤＵの終端を構成する。

以上のような第３の実施形態によれば、ＭＡＣレイヤ２０２では、ペイロード部を相互に結合するＲＬＣ ＰＤＵを各ＲＬＣ ＰＤＵのヘッダに含まれる識別情報の内容に応じて判別し、該判別したＲＬＣ ＰＤＵのペイロード部を相互に結合し、該結合したペイロード部と、先頭のＲＬＣ ＰＤＵのＲＬＣヘッダ（識別情報を含む）と、を含むフレームＦ１を生成し、該フレームＦ１をＭＡＣレイヤ２０２からＲＬＣレイヤ２０３へ受け渡す。よって、ＭＡＣレイヤ２０２からＲＬＣレイヤ２０３へ受け渡すフレームの数を低減することができる。よって、ＲＬＣレイヤ２０３における処理負荷を軽減することができる。しかも、ＲＬＣレイヤ２０３において結合すべきデータ数を低減でき、その点でもＲＬＣレイヤ２０３における処理負荷を軽減することができる。

すなわち、ＳＮ＝０〜３７の合計３８個のＲＬＣ ＰＤＵの各々からヘッダを除いた上で、それらＰＤＵのペイロード部を結合することによりＲＬＣ ＳＤＵを生成する必要がある従来の動作と比べて、ＲＬＣレイヤ２０３の処理負荷を軽減できる。

また、ＲＬＣレイヤ２０３は、再送制御をするので、再送制御が終わるまでは、ＭＡＣレイヤ２０２から受け渡されたフレームのうち、ＰＤＣＰレイヤ２０４へ受け渡しが終わっていないフレームは全て保持しておく必要がある。このため、フレーム（ＲＬＣ ＰＤＵ）の数が多ければ、管理のために多大な処理負荷を要するという事情がある。しかし、本実施形態では、管理すべきフレームの数が大幅に低減されるので、フレーム数の増加に起因する諸問題の発生を防止することができる。

なお、上記の第３の実施形態では、ＲＬＣ ＡＭを使用した場合の動作を説明したが、第３の実施形態は、データの送達確認が行われないＲＬＣ ＵＭ（ＵＭ：Ｕｎａｃｋｎｏｗｌｅｄｇｅ Ｍｏｄｅ：非確認モード）が設定された場合も同様に使用することが可能である。

ＲＬＣ ＵＭの場合、ＲＬＣ ヘッダが１バイトであり、ＨＥ及びＤ／Ｃは何れも使用しないため、これらの識別情報の判別は行う必要がない。ＲＬＣ ＵＭの場合、Ｅ（エクステンション・ビット）＝１であればＬＩも有るので、Ｅ＝０であり、且つ、ＳＮが連続するＲＬＣ ＰＤＵを相互に結合することにより、フレームＦ１、Ｆ３を生成する。

〔第４の実施形態〕
次に、第４の実施形態を説明する。

図１０は、本実施形態に係る通信処理方法によるダウンリンク・データ転送の動作を示す模式図である。すなわち、図１０は、ＲＬＣ ＰＤＵのサイズ＝４２バイト、ＲＬＣ ＳＤＵのサイズ＝１５００バイトの環境下において、ＭＡＣレイヤ処理手段３０２が（ＭＡＣレイヤ２０２が）ＭＡＣ−ｄ ＰＤＵを受信した後の動作を示す。なお、図１０に示すのは、２個のＲＬＣ ＳＤＵに相当するデータを転送する動作である。

第４の実施形態に係る通信処理装置の構成は、上記の第３の実施形態（図７）と同様である。

第４の実施形態の場合、図１０のフレームＦ６のように、Ｐ＝１であるか、又は、ＨＥ＝０１（ＬＩ有）のＲＬＣ ＰＤＵ（例えば、ＳＮ＝３７のＲＬＣ ＰＤＵ）を、フレームの先頭のセグメントに結合することができる。

これにより、第４の実施形態では、上記の第３の実施形態の場合よりも、更に処理の効率化を図ることができる。

本実施形態の場合、具体的には、例えば、図１０に示すように、２つのＲＬＣ ＳＤＵに相当するデータを、３つのフレームＦ５、Ｆ６、Ｆ７に分けて、ＭＡＣレイヤ２０２からＲＬＣレイヤ２０３へと受け渡すことができる。

このうちフレームＦ５は、ＳＮ＝０〜３６の３７個分のＲＬＣ ＰＤＵのペイロード部と、ＲＬＣヘッダと、からなる。

また、フレームＦ６は、ＳＮ＝３７〜７４の３８個分のＲＬＣ ＰＤＵのペイロード部と、ＳＮ＝３７のＲＬＣ ＰＤＵのＲＬＣヘッダと、からなる。

フレームＦ６におけるＳＮ＝３７のＲＬＣ ＰＤＵは、ＲＬＣレイヤ２０３における所定のプロトコル処理が必要なＰＤＵであるため、そのペイロード部は結合データを構成しない。しかし、フレームＦ６は、ＳＮ＝３８以降のＲＬＣ ＰＤＵのペイロード部の結合データを含む。

また、フレームＦ７は、ＳＮ＝７５のＲＬＣ ＰＤＵからなる。

ＲＬＣレイヤ２０３では、ＭＡＣレイヤ２０２からフレームＦ５、Ｆ６、Ｆ７を受信すると、フレームＦ５の各ペイロード部と、フレームＦ６の先頭セグメント（ＳＮ＝３７）のペイロード部と、を結合することにより１つ目のＲＬＣ ＳＤＵ（図１０のＲＬＣ ＳＤＵ（Ｎｏ．１））を生成する。また、フレームＦ６の２番目以降の各セグメント（ＳＮ＝３８〜７４）を構成する各ペイロード部と、フレームＦ７のペイロード部と、を結合することにより２つ目のＲＬＣ ＳＤＵ（図１０のＲＬＣ ＳＤＵ（Ｎｏ．１））を生成する。

そして、これら生成した２つのＲＬＣ ＳＤＵをＲＬＣレイヤ２０３からＰＤＣＰレイヤ２０４へと受け渡す。

以上のような第４の実施形態によれば、ＲＬＣレイヤ２０３における所定のプロトコル処理が必要なＲＬＣ ＰＤＵのペイロード部は結合データを構成することはできない。しかし、結合データを構成することができないペイロード部であっても、予め取り決めを行っておくことにより、結合データを構成することができる。例えば、フレームの先頭を構成するＲＬＣ ＰＤＵに対しては、所定のプロトコル処理を適用するように、予め取り決めておくことによって、結合データを構成することが可能となる。そして、その結合データはフレームの先頭に結合することができる。従って、上記の第３の実施形態よりもフレームの数を低減できる。

なお、上記の第４の実施形態では、フレームＦ６が結合データを含む例を説明したが、フレームＦ６は、（例えばＳＮ＝３７の）ＲＬＣ ＰＤＵの他には、１つのＲＬＣ ＰＤＵのペイロード部のみを含んでいても良い。

〔第５の実施形態〕
第５の実施形態では、背景技術の項において詳述したようなＷ−ＣＤＭＡの規定に従ったアップリンク・データ転送について説明する。

図１１は、本実施形態に係る通信処理方法におけるアップリンク・データ転送の動作を示す模式図である。すなわち、図１１は、ＲＬＣ ＰＤＵのサイズ＝４２バイト、ＲＬＣ ＳＤＵのサイズ＝１５００バイトの環境下において、ＰＤＣＰレイヤ２０４からＲＬＣレイヤ２０３へのデータ転送と、ＲＬＣレイヤ２０３からＭＡＣレイヤ２０２へのデータ転送の動作を示す。なお、図１１に示すのは、１個のＲＬＣ ＳＤＵのデータを転送する動作である。

この場合、図１１に示すように、先ず、ＰＤＣＰレイヤ２０４からＲＬＣレイヤ２０３へとＲＬＣ ＳＤＵを受け渡す。

ＲＬＣレイヤ２０３では、ＲＬＣ ＳＤＵを受けると、このＲＬＣ ＳＤＵの先頭から、ＲＬＣペイロード部の規定のサイズ（＝４０バイト）の整数倍で、且つ最大の大きさのデータ（整数倍データ）を切り取る。

言い換えると、ＲＬＣ ＳＤＵを、ＲＬＣペイロード部の規定のサイズの整数倍の整数倍データ（第１のデータ）と、規定サイズ未満の端数データ（第３のデータ）と、に分割する。

ＲＬＣレイヤ２０３では、続いて、整数倍データと、端数データのそれぞれに対し、ＲＬＣヘッダを付加し、それぞれフレームＦ８，９を生成する。

すなわち、整数倍データには、ＳＮ＝０と設定したＲＬＣヘッダを付加することにより、フレームＦ８とする。

なお、ＲＬＣペイロード部の規定のサイズの整数倍のデータは、該整数で等分割することにより、プロトコル処理が不要でＳＮが連続したＲＬＣ ＰＤＵの各ペイロード部を構成する。

このため、フレームＦ８は、プロトコル処理が不要でＳＮが連続したＲＬＣ ＰＤＵを、先頭のＲＬＣ ＰＤＵにのみＲＬＣ ヘッダを付加し、その他のＲＬＣ ＰＤＵにはＲＬＣ ヘッダを省略した形で、各々のＲＬＣ ペイロード部を結合したものであると言い換えることができる。

また、ＲＬＣ ＳＤＵから切り取ることができた整数倍データの大きさが、規定のサイズの何倍であるかに応じて、端数データに付加するＲＬＣヘッダのＳＮの値を設定する。例えば、整数倍データの大きさが、規定サイズの３７倍である場合には、ＳＮ＝３７（３８番目）のＳＮ値とする。

端数データには、終端にパディングを付加することにより、合計で規定のサイズとなるように調節する。

端数データに付加するＲＬＣヘッダは、上記のように設定したＳＮ値とする他、ＨＥ＝０１とし、ＲＬＣ ＳＤＵの終端である旨のＬＩを付加し、Ｐ＝１とする。また、ＬＩの値は、データの終端位置を示す値に設定する。これにより、フレームＦ９を生成する。

続いて、ＲＬＣレイヤ２０３は、このように生成したフレームＦ８，Ｆ９をＭＡＣレイヤ２０２へ受け渡す。

ＲＬＣレイヤ２０３は、１個のＲＬＣ ＳＤＵに相当するデータを転送する場合には、図１１に示すように、あたかも２個のＲＬＣ ＰＤＵをＭＡＣレイヤ２０２へ受け渡すかのような動作を行う。

次に、ＭＡＣレイヤ２０２においては、規定のサイズとは異なるデータ量のフレーム、すなわちフレームＦ８を受信すると、該フレームＦ８を、ＳＮが連続した複数のＲＬＣ ＰＤＵ（のペイロード部）が結合されてなるフレームであると認識する。

ＭＡＣレイヤ２０２では、フレームＦ８のペイロード部（ＲＬＣヘッダを除く部分）を、個々のＲＬＣ ＰＤＵのペイロード部のサイズ（４０バイト）で先頭から等分に切り分けて複数のデータに分割し、これら各データに対し、ＲＬＣヘッダを生成及び付加することにより、ＲＬＣ ＰＤＵを生成する。

ここで、先頭のＲＬＣ ＰＤＵについては、ＲＬＣレイヤ２０３から受け渡されたＲＬＣ ヘッダ（ＳＮ＝０）をそのまま用い、２番目のＲＬＣ ＰＤＵからは、先頭のＲＬＣ ＰＤＵのヘッダに格納されているＳＮを１つずつインクリメントする形で、全てのＲＬＣ ヘッダを生成する。

そして、これら生成したＲＬＣ ＰＤＵをネットワークへ転送する。

また、ＭＡＣレイヤ２０２は、フレームＦ９については、１個のＲＬＣ ＰＤＵであると認識し、そのままネットワークへ転送する。

以上のような第５の実施形態によれば、ＭＡＣレイヤ２０２では、規定のサイズの整数倍のデータと、このデータの識別情報としてのＲＬＣヘッダと、を含むフレームＦ８のデータを規定のサイズの複数のデータに分割する。これら分割したデータの各々に対して、「データ送信先の第２のレイヤにおいて行う所定の通信処理」に用いられる識別情報としてのＲＬＣヘッダを、ＳＮ＝０のＲＬＣヘッダに基づいて生成する。そして、分割した個々のデータと、当該データに対応して生成されたＲＬＣヘッダと、を含むＲＬＣ ＰＤＵを生成し、これらＲＬＣ ＰＤＵをデータ送信先の通信処理装置宛に送信する。

従って、ＲＬＣレイヤ２０３からＭＡＣレイヤ２０２へ受け渡すフレームの数を低減することができる。よって、ＲＬＣレイヤ２０３における処理負荷を軽減することができる。しかも、ＲＬＣレイヤにおけるデータの分割数を低減でき、その点でも該ＲＬＣレイヤにおける処理負荷を軽減することができる。

以上のように、本実施形態においては、ＲＬＣレイヤ２０３からＭＡＣレイヤ２０２へ受け渡すフレームの数を削減できる。そのため、ＲＬＣが管理しなければならないＲＬＣ ＰＤＵの個数を劇的に削減することができる。

ところで、一般的に通信処理装置がＡＲＱ （Ａｕｔｏｍａｔｉｃ Ｒｅｐｅａｔ Ｒｅｑｕｅｓｔ）機能を保有している場合、ＰＤＵの再送制御が必要となる。再送制御を行うためには、ＰＤＵを下位のレイヤに転送しても、その転送済みのＰＤＵを即座に削除することはできず、送信先の通信装置からの受信応答（ＡＣＫ）を受信して初めて削除することができる。このことは、本実施形態におけるＲＬＣレイヤ２０３についても同様である。具体的に説明すると、本実施形態では、ＲＬＣレイヤ２０３からＭＡＣレイヤ２０２へＰＤＵを転送した後も、送信先からのＡＣＫを受信するまでは、送信したＰＤＵを保持している必要がある。このように、ＰＤＵの送信後もＰＤＵの管理が必要となるため、ＰＤＵの個数を削減することができれば、ＰＤＵ管理の処理を削減することができる。従って、管理のために要するソフトウェア処理量を削減することが可能になる。

〔第６の実施形態〕
図１２は、第６の実施形態に係る通信処理方法におけるアップリンク・データ転送の動作を示す模式図である。すなわち、図１２は、ＲＬＣ ＰＤＵのサイズ＝４２バイト、ＲＬＣ ＳＤＵのサイズ＝１５００バイトの環境下において、ＰＤＣＰレイヤ２０４からＲＬＣレイヤ２０３へのデータ転送と、ＲＬＣレイヤ２０３からＭＡＣレイヤ２０２へのデータ転送の動作を示す。なお、図１２に示すのは、２個のＲＬＣ ＳＤＵに相当するデータを転送する動作である。

本実施形態の場合、図１２に示すように、先ず、ＰＤＣＰレイヤ２０４からＲＬＣレイヤ２０３へと２個のＲＬＣ ＳＤＵを受け渡す。

ＲＬＣレイヤ２０３では、２個のＲＬＣ ＳＤＵを受けると、このうち先に受けたＲＬＣ ＰＤＵ（Ｎｏ．１）の先頭から、上記の第５の実施形態と同様に、規定のサイズ（＝４０バイト）の整数倍で、且つ最大の大きさのデータ（整数倍データ）を切り取る。

すなわち、ＲＬＣ ＳＤＵ（Ｎｏ．１）を、規定のサイズの整数倍の整数倍データ（第１のデータ）と、規定サイズ未満の端数データ（第３のデータ）と、に分割する。

ＲＬＣレイヤ２０３では、続いて、整数倍データに対し、ＳＮ＝０のＲＬＣヘッダを付加し、フレームＦ１０を生成する。このフレームＦ１０は、上記の第５の実施形態のフレームＦ８に相当する。

すなわち、フレームＦ１０は、プロトコル処理が不要でＳＮが連続したＲＬＣ ＰＤＵを、先頭のＲＬＣ ＰＤＵにのみＲＬＣ ヘッダを付加し、その他のＲＬＣ ＰＤＵにはＲＬＣ ヘッダを省略した形で、各々のＲＬＣ ペイロード部を結合したものであると言い換えることができる。

また、端数データに対し、ＲＬＣヘッダを付加する。

端数データに付加するＲＬＣヘッダは、上記の第５の実施形態と同様に設定したＳＮ値（例えば、ＳＮ＝３７）とする他、ＨＥ＝０１とし、ＲＬＣ ＳＤＵの終端である旨のＬＩを付加し、さらにＰ＝１とする。また、ＬＩの値は、データの終端位置を示す値に設定する。

更に、端数データの終端にパディングを付加することにより、端数データとパディングとの合計が規定のサイズとなるように調節する。

一方、ＲＬＣ ＳＤＵ（Ｎｏ．２）も、ＲＬＣ ＳＤＵ（Ｎｏ．２）と同様に、整数倍データ（第１のデータ）と、端数データ（第３のデータ）と、に分割する。

このうち整数倍データは、ＲＬＣ ＳＤＵ（Ｎｏ．１）を元に生成した端数データ（ＲＬＣヘッダを有する）の終端に結合する。これにより、フレーム（第３のフレーム）Ｆ１１を生成する。

このように、フレームＦ１１は、上記端数データの分割元のＲＬＣ ＳＤＵ（Ｎｏ．１）とは別のＲＬＣ ＳＤＵ（Ｎｏ．２）から分割された、整数倍データを含む。

言い換えるとフレームＦ１１は、プロトコル処理が必要なＲＬＣ ＰＤＵ（ＳＮ＝３７）のペイロード部にＲＬＣ ヘッダを付加したものと、プロトコル処理が不要でＳＮが連続したＲＬＣ ＰＤＵ（ＳＮ＝３８〜７４）におけるＲＬＣ ヘッダを省略した各ペイロード部と、を結合したものである。

また、ＲＬＣ ＳＤＵ（Ｎｏ．２）を元に生成した端数データ、すなわちプロトコル処理が必要なＲＬＣ ＰＤＵ（ＳＮ＝７５）のペイロード部には、ＲＬＣ ヘッダを付加するとともに、その終端にパディングを付加する。これにより、端数データとパディングとの合計を規定のサイズとし、ＲＬＣヘッダ、端数データ、及びパディングからなるフレームＦ１２を生成する。

そして、これら生成したフレームＦ１０、Ｆ１１、Ｆ１２をＲＬＣレイヤ２０３からＭＡＣレイヤ２０２へ受け渡す。

このように、ＲＬＣレイヤ２０３は、２個のＲＬＣ ＳＤＵに相当するデータをＭＡＣレイヤ２０２へ受け渡す場合には、図１２に示すように、あたかも３個のＲＬＣ ＰＤＵをＲＬＣレイヤ２０３に受け渡すかのような動作を行う。

次に、ＭＡＣレイヤ２０２においては、規定のサイズ（４２バイト）とは異なるデータ量のフレーム、すなわちフレームＦ１０、Ｆ１１を受けると、該フレームＦ１０、Ｆ１１を、ＳＮが連続した複数のＲＬＣ ＰＤＵ（のペイロード部）が結合されてなる部分を有するフレームであると認識する。

ＭＡＣレイヤ２０２では、フレームＦ１０のペイロード部（ＲＬＣヘッダを除く部分）を、規定のサイズ、すなわち、個々のＲＬＣ ＰＤＵのペイロード部のサイズ（４０バイト）で先頭から等分に切り分けて複数のデータに分割し、これら各データに対し、ＲＬＣヘッダを生成及び付加することにより、ＲＬＣ ＰＤＵを生成する。

ここで、第５の実施形態と同様に、先頭のＲＬＣ ＰＤＵについては、ＲＬＣレイヤ２０３から受け渡されたＲＬＣ ヘッダ（ＳＮ＝０）をそのまま用い、２番目のＲＬＣ ＰＤＵからは、先頭のＲＬＣ ＰＤＵのヘッダに格納されているＳＮを１つずつインクリメントする形で、全てのＲＬＣ ヘッダを生成する。

そして、これら生成したＲＬＣ ＰＤＵをネットワークへ転送する。

また、フレームＦ１１は、その先頭が、所定のプロトコル処理が必要なＲＬＣ ＰＤＵであるため、ＭＡＣレイヤ２０２は、フレームＦ１１の先頭は、ＲＬＣ ＰＤＵの規定のサイズ（４２バイト）で切り取り、残りのペイロード部は、個々のＲＬＣ ＰＤＵのペイロード部のサイズ（４０バイト）で先頭から等分に切り分けて複数のデータに分割し、これら各データに対し、ＲＬＣヘッダを生成及び付加することにより、ＲＬＣ ＰＤＵを生成する。また、この際、所定のプロトコル処理が必要な先頭のＲＬＣ ＰＤＵのヘッダに格納されているＳＮを１つずつインクリメントする形で、全てのＲＬＣ ヘッダを生成する。

そして、これら生成したＲＬＣ ＰＤＵをネットワークへ転送する。

また、ＭＡＣレイヤ２０２は、規定のサイズのデータ量のフレームＦ１２については、１個のＲＬＣ ＰＤＵであると認識し、そのままネットワークへ転送する。

以上のような第６の実施形態によれば、フレームＦ１１は、規定のサイズの端数データを含むＲＬＣ ＰＤＵ（例えば、ＳＮ＝３７）と、このＲＬＣ ＰＤＵの分割元であるＲＬＣ ＳＤＵ（Ｎｏ．１）とは別のＲＬＣ ＳＤＵ（Ｎｏ．２）から分割された、規定のサイズ（４０バイト）の整数倍のデータと、を含む構成である。このため、上記の第５の実施形態よりも、フレームの数を低減でき、ＲＬＣレイヤ２０３における処理負荷を更に軽減できる。

なお、上記の各実施形態では、高レートのデータ転送であるＨＳＤＰＡのＨＳＰＡ（Ｈｉｇｈ Ｓｐｅｅｄ Ｐａｃｋｅｔ Ａｃｃｅｓｓ）動作を例示したが、３Ｇで使われる他の全てのチャネル（ＤＣＨ（Ｄｅｄｉｃａｔｅｄ Ｃｈａｎｎｅｌ）、ＦＡＣＨ（Ｆｏｒｗａｒｄ Ａｃｃｅｓｓ Ｃｈａｎｎｅｌ）、ＲＡＣＨ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｃｈａｎｎｅｌ）、Ｅ−ＤＣＨ（Ｅｎｈａｎｃｅｄ Ｄｅｄｉｃａｔｅｄ Ｃｈａｎｎｅｌ））にも同様に適用可能である。

第１の実施形態に係る通信処理装置の構成を示すブロック図である。 第１の実施形態に係る通信処理方法の動作を示す模式図である。 通信処理装置の制御部のハードウェア構成を示すブロック図である。 第１の実施形態の変形例に係る通信処理方法の動作を示す模式図である。 第２の実施形態に係る通信処理方法の動作を示す模式図である。 第２の実施形態の変形例に係る通信処理方法の動作を示す模式図である。 第３の実施形態に係る通信処理装置の構成を示すブロック図である。 第３の実施形態に係る通信処理方法の動作（ＲＬＣ ＳＤＵ１個分のデータ転送時）を示す模式図である。 第３の実施形態に係る通信処理方法の動作（ＲＬＣ ＳＤＵ２個分のデータ転送時）を示す模式図である。 第４の実施形態に係る通信処理方法の動作を示す模式図である。 第５の実施形態に係る通信処理方法の動作を示す模式図である。 第６の実施形態に係る通信処理方法の動作を示す模式図である。 Ｗ−ＣＤＭＡのシステムで想定されている無線インターフェイスのプロトコル階層を示す図である。 ＨＳＤＰＡのカテゴリ毎の、１ＴＴＩ内にＲＬＣレイヤにおいて処理すべきトランスポート・ブロックの最大ビット数、及びＲＬＣ ＰＤＵの理論上の最大個数を示す図である。 基本的なチャネル・コンフィグレーションの場合における、レイヤ毎の、データ・フレームの名称及び形態の対応を示す図である。 ＲＬＣ ＰＤＵの構造を示す図である。 ＲＬＣ ヘッダを構成している各識別情報のデータ量及び内容を示す図である。 代表的なフレーム・サイズ（ＲＬＣ ＳＤＵ：１５００バイト、ＲＬＣ ＰＤＵ：４２バイト）の場合の、ＲＬＣ ＳＤＵとＲＬＣ ＰＤＵとの対応を示す図である。 代表的なフレーム・サイズ（ＲＬＣ ＳＤＵ：１５００バイト、ＲＬＣ ＰＤＵ：４２バイト）の場合の、一般的なダウンリンク・データ転送の動作を示す模式図である。 代表的なフレーム・サイズ（ＲＬＣ ＳＤＵ：１５００バイト、ＲＬＣ ＰＤＵ：４２バイト）の場合の、一般的なアップリンク・データ転送の動作を示す模式図である。

符号の説明

１、２、３ データ
１１ 識別情報（第１の識別情報）
１２ 識別情報（単体データ用識別情報、第１の識別情報）
１３、１４ 代表識別情報（結合データ用識別情報）
２０ 結合データ
３１、３２、３３ 第１のフレーム
３４ 第２のフレーム
３５ 第３のフレーム
２１、２２、２３ 識別情報（第２の識別情報）
５０ データ
５１ データ
６１ 第１のフレーム
６２、６３ 第２のフレーム
６４ 第３のフレーム
１００ 通信処理装置
１０３ 第１のレイヤ処理手段
１０４ 第２のレイヤ処理手段
１０５ 第３のレイヤ処理手段
３０２ ＭＡＣレイヤ処理手段（第１のレイヤ処理手段）
３０３ ＲＬＣレイヤ処理手段（第２のレイヤ処理手段）
３０４ ＰＤＣＰレイヤ処理手段（第３のレイヤ処理手段）
Ｆ１、Ｆ３、Ｆ５ 第２のフレーム
Ｆ２、Ｆ４、Ｆ７ 第３のフレーム
Ｆ６ 第３のフレーム
Ｆ８、Ｆ１０ 第１のフレーム
Ｆ９、Ｆ１２ 第３のフレーム
Ｆ１１ 第３のフレーム

Claims (31)

1. 第１のレイヤにおける通信処理を行う第１のレイヤ処理手段を備え、
   前記第１のレイヤ処理手段は、
   データと、第２のレイヤにおいて前記データに対する所定の通信処理に用いられる識別情報と、を含む複数の第１のフレームのうち、前記データを相互に結合する第１のフレームを、前記識別情報の内容に応じて判別する第１の処理と、
   前記データを結合すると判別された前記第１のフレームの前記データを相互に結合した結合データと、前記結合データに含まれる前記データに対して前記第２のレイヤにおいて行う通信処理の内容を示す結合データ用識別情報と、を含む第２のフレームを生成する処理と、
   前記第２のフレームを、前記第２のレイヤにおける通信処理を行う第２のレイヤ処理手段へ受け渡す処理と、
   を行うことを特徴とする通信処理装置。
2. 前記第１のレイヤ処理手段は、
   前記第１のフレームのうち、前記データを結合すると判別されなかった第１のフレームに含まれる前記データと、前記データに対して前記第２のレイヤにおいて行う第１の通信処理の内容を示す単体データ用識別情報と、を含む第３のフレームを生成する処理と、
   前記第３のフレームを前記第２のレイヤ処理手段へ受け渡す処理と、
   を更に行うことを特徴とする請求項１に記載の通信処理装置。
3. 前記第３のフレームは、更に、前記データを結合すると判別されなかった第１のフレームに含まれる前記データ以外の追加データを含むことを特徴とする請求項２に記載の通信処理装置。
4. 前記追加データは、前記第２のフレームを構成しない前記結合データであることを特徴とする請求項３に記載の通信処理装置。
5. 前記第２のレイヤ処理手段を更に備えることを特徴とする請求項１乃至４の何れか一項に記載の通信処理装置。
6. 前記第２のレイヤ処理手段を更に備え、
   前記第２のレイヤ処理手段は、前記第２のフレームに含まれるデータと、前記第３のフレームに含まれるデータと、を結合し、第３のレイヤ処理手段に受け渡すことを特徴とする請求項２乃至４の何れか一項に記載の通信処理装置。
7. 各第１のフレームの識別情報は、第１及び第２の識別情報を含み、
   前記第１の処理では、前記第１の識別情報が互いに同一である複数の第１のフレームを、前記データを結合する第１のフレームであると判別することを特徴とする請求項１乃至６の何れか一項に記載の通信処理装置。
8. 各第１のフレームの識別情報は、第１及び第２の識別情報を含み、
   前記第１の処理では、前記第１の識別情報が互いに同一である複数の第１のフレームを、前記データを結合する第１のフレームであると判別し、
   前記第３のフレームは、前記互いに同一の第１の識別情報とは異なる前記第１の識別情報を含む前記第１のフレームに含まれる前記データ、前記異なる第１の識別情報及び前記第２の識別情報を含むことを特徴とする請求項２乃至４又は６の何れか一項に記載の通信処理装置。
9. 前記第１の処理では、前記第２のレイヤにおける所定の通信処理の要否を、前記第１の識別情報の内容に基づいて判別し、前記所定の通信処理の要否に応じて、前記データを結合する第１のフレームを判別することを特徴とする請求項７又は８に記載の通信処理装置。
10. 前記第１の処理では、前記所定の通信処理が不要である旨を示す前記第１の識別情報を含む第１のフレームを、前記データを結合する第１のフレームであると判別することを特徴とする請求項９に記載の通信処理装置。
11. 前記第１の処理では、
    前記第２のレイヤにおける所定の通信処理の要否を、前記第１の識別情報の内容に基づいて判別し、前記所定の通信処理の要否に応じて、前記データを結合し、
    前記第１の処理では、前記所定の通信処理が不要である旨を示す前記第１の識別情報を含む第１のフレームを、前記データを結合する第１のフレームであると判別し、
    前記第３のフレームは、前記所定の通信処理が必要である旨を示す前記第１の識別情報を含む第１のフレームに含まれる前記データを含むことを特徴とする請求項８に記載の通信処理装置。
12. 前記結合データ用識別情報は、前記データを結合すると判別された複数の前記第１のフレームのうち、何れか１つの第１のフレームの前記第２の識別情報を含むことを特徴とする請求項７乃至１１の何れか一項に記載の通信処理装置。
13. 前記第２の識別情報は、前記データの順序を示す番号を含むことを特徴とする請求項１２に記載の通信処理装置。
14. 個々の結合データには、前記番号が連続する前記データのみが含まれることを特徴とする請求項１３に記載の通信処理装置。
15. 前記結合データ用識別情報に含まれる前記第２の識別情報は、当該結合データ用識別情報に対応する結合データに含まれるデータのうち、前記順序が先頭のデータの前記番号を含むことを特徴とする請求項１３又は１４に記載の通信処理装置。
16. 前記結合データは、前記データを前記番号順にならべて結合してなることを特徴とする請求項１３乃至１５の何れか一項に記載の通信処理装置。
17. 第１のレイヤにおける通信処理を行う第１のレイヤ処理手段を備える通信処理装置において、
    前記第１のレイヤ処理手段は、
    第１のデータと、第１のデータ用識別情報と、を含む第１のフレームの前記第１のデータを複数の第２のデータに分割する処理と、
    前記通信処理装置からのデータ送信先の通信処理装置が前記第２のデータの各々に対して第２のレイヤにおいて行う第１の通信処理に用いられる識別情報を、前記第１のデータ用識別情報に基づいて各第２のデータ毎に生成する処理と、
    個々の前記第２のデータと、前記第２のデータ毎に生成された識別情報と、を含む第２のフレームを生成する処理と、
    各第２のフレームを、前記データ送信先の通信処理装置宛に送信する処理と、
    を行うことを特徴とする通信処理装置。
18. 前記第２のレイヤにおける通信処理を行う第２のレイヤ処理手段を更に備え、
    前記第２のレイヤ処理手段は、
    送信データを前記第１のデータと第３のデータとに分割する処理と、
    前記分割した第１のデータと、前記第１のデータ用識別情報と、を含む前記第１のフレームを生成する処理と、
    前記第３のデータと、前記データ送信先の通信処理装置が前記第３のデータに対して第２のレイヤにおいて行う第２の通信処理に用いられる識別情報と、を含む第３のフレームを生成する処理と、
    前記第１及び第３のフレームを前記第１のレイヤ処理手段に受け渡す処理と、
    を行うことを特徴とする請求項１７に記載の通信処理装置。
19. 前記第３のフレームは、前記第３のデータの分割元の送信データとは異なる、別の送信データを更に含むことを特徴とする請求項１８に記載の通信処理装置。
20. 各第２のフレームの前記識別情報は、第１及び第２の識別情報を含み、
    各第２のフレームの前記第１の識別情報は互いに同一であり、
    前記第２の識別情報は、各第２のフレーム毎に固有であることを特徴とする請求項１７乃至１９の何れか一項に記載の通信処理装置。
21. 前記第１のデータ用識別情報は、何れかの第２のフレームの前記第２の識別情報を含むことを特徴とする請求項２０に記載の通信処理装置。
22. 各第２のフレームの前記第２の識別情報は、前記第２のデータの順序を示す番号を含むことを特徴とする請求項２０又は２１に記載の通信処理装置。
23. 前記第１のデータ用識別情報は、各第２のデータのうち、前記順序が先頭のデータの前記番号を含むことを特徴とする請求項２２に記載の通信処理装置。
24. 少なくとも第１のレイヤにおける通信処理を行う通信処理方法において、
    前記第１のレイヤにおける通信処理は、
    データと、第２のレイヤにおいて前記データに対する所定の通信処理に用いられる識別情報と、を含む複数の第１のフレームのうち、前記データを相互に結合する第１のフレームを、前記識別情報の内容に応じて判別する工程と、
    前記データを結合すると判別された前記第１のフレームの前記データを相互に結合した結合データと、前記結合データに含まれる前記データに対して前記第２のレイヤにおいて行う通信処理の内容を示す結合データ用識別情報と、を含む第２のフレームを生成する工程と、
    前記第２のフレームを前記第２のレイヤへ受け渡す工程と、
    を備えることを特徴とする通信処理方法。
25. 前記第１のレイヤにおける通信処理は、
    前記第１のフレームのうち、前記データを結合すると判別されなかった第１のフレームに含まれる前記データと、前記データに対して前記第２のレイヤにおいて行う通信処理の内容を示す単体データ用識別情報と、を含む第３のフレームを生成する工程と、
    前記第３のフレームを前記第２のレイヤへ受け渡す工程と、
    を更に備えることを特徴とする請求項２４に記載の通信処理方法。
26. データ送信元の通信処理装置からデータ送信先の通信処理装置へのデータ送信を行う通信処理方法において、
    前記データ送信元の通信処理装置は、少なくとも第１のレイヤにおける通信処理を行い、
    前記第１のレイヤにおける通信処理は、
    第１のデータと、第１のデータ用識別情報と、を含む第１のフレームの前記第１のデータを複数の第２のデータに分割する工程と、
    前記データ送信先の通信処理装置が前記第２のデータの各々に対して第２のレイヤにおいて行う所定の通信処理、に用いられる識別情報を、前記第１のデータ用識別情報に基づいて各第２のデータ毎に生成する工程と、
    個々の前記第２のデータと、前記第２のデータ毎に生成された識別情報と、を含む第２のフレームを生成する工程と、
    各第２のフレームを、前記データ送信先の通信処理装置宛に送信する工程と、
    を備えることを特徴とする通信処理方法。
27. 前記データ送信元の通信処理装置は、更に、前記第２のレイヤにおける通信処理を行い、
    前記第２のレイヤにおける通信処理は、
    送信データを前記第１のデータと第３のデータとに分割する工程と、
    前記分割した第１のデータと、前記第１のデータ用識別情報と、を含む前記第１のフレームを生成する工程と、
    前記第３のデータと、前記データ送信先の通信処理装置が前記第３のデータに対して第２のレイヤにおいて行う所定の通信処理に用いられる識別情報と、を含む第３のフレームを生成する工程と、
    前記第１及び第３のフレームを前記第１のレイヤに受け渡す工程と、
    備えることを特徴とする請求項２６に記載の通信処理方法。
28. 少なくとも第１のレイヤにおける通信処理をコンピュータに実行させるプログラムにおいて、
    前記第１のレイヤにおける通信処理は、
    データと、第２のレイヤにおいて前記データに対する所定の通信処理に用いられる識別情報と、を含む複数の第１のフレームのうち、前記データを相互に結合する第１のフレームを、前記識別情報の内容に応じて判別する処理と、
    前記データを結合すると判別された前記第１のフレームの前記データを相互に結合した結合データと、前記結合データに含まれる前記データに対して前記第２のレイヤにおいて行う通信処理の内容を示す結合データ用識別情報と、を含む第２のフレームを生成する処理と、
    前記第２のフレームを前記第２のレイヤへ受け渡す処理と、
    を含むことを特徴とするプログラム。
29. 前記第１のレイヤにおける通信処理は、
    前記第１のフレームのうち、前記データを結合すると判別されなかった第１のフレームに含まれる前記データと、前記データに対して前記第２のレイヤにおいて行う通信処理の内容を示す単体データ用識別情報と、を含む第３のフレームを生成する処理と、
    前記第３のフレームを前記第２のレイヤへ受け渡す処理と、
    を更に含むことを特徴とする請求項２８に記載のプログラム。
30. データ送信元の通信処理装置からデータ送信先の通信処理装置へのデータ送信に際し、少なくとも第１のレイヤにおける通信処理を、前記データ送信元の通信処理装置が備えるコンピュータに実行させるプログラムにおいて、
    前記第１のレイヤにおける通信処理は、
    第１のデータと、第１のデータ用識別情報と、を含む第１のフレームの前記第１のデータを複数の第２のデータに分割する処理と、
    前記データ送信先の通信処理装置が前記第２のデータの各々に対して第２のレイヤにおいて行う所定の通信処理、に用いられる識別情報を、前記第１のデータ用識別情報に基づいて各第２のデータ毎に生成する処理と、
    個々の前記第２のデータと、前記第２のデータ毎に生成された識別情報と、を含む第２のフレームを生成する処理と、
    各第２のフレームを、前記データ送信先の通信処理装置宛に送信する処理と、
    を含むことを特徴とするプログラム。
31. 前記プログラムは、更に、前記第２のレイヤにおける通信処理を前記コンピュータに実行させるものであり、
    前記第２のレイヤにおける通信処理は、
    送信データを前記第１のデータと第３のデータとに分割する処理と、
    前記分割した第１のデータと、前記第１のデータ用識別情報と、を含む前記第１のフレームを生成する処理と、
    前記第３のデータと、前記データ送信先の通信処理装置が前記第３のデータに対して第２のレイヤにおいて行う所定の通信処理に用いられる識別情報と、を含む第３のフレームを生成する処理と、
    前記第１及び第３のフレームを前記第１のレイヤに受け渡す処理と、
    を含むことを特徴とする請求項３０に記載のプログラム。

Images