(57)【特許請求の範囲】
【請求項１】
第１のレイヤにおける通信処理を行う第１のレイヤ処理手段と、
第２のレイヤにおける通信処理を行う第２のレイヤ処理手段と、
を備え、
前記第１のレイヤ処理手段は、
データと、前記第２のレイヤにおいて前記データに対する所定の通信処理に用いられる識別情報と、を含む複数の第１のフレームのうち、前記データを相互に結合する第１のフレームを、前記識別情報の内容に応じて判別する第１の処理と、
前記データを結合すると判別された前記第１のフレームの前記データを相互に結合した結合データと、前記結合データに含まれる前記データに対して前記第２のレイヤにおいて行う通信処理の内容を示す結合データ用識別情報と、を含む第２のフレームを生成する処理と、
前記第２のフレームを、前記第２のレイヤ処理手段へ受け渡す処理と、
を行うことを特徴とする通信処理装置。
【請求項２】
前記第１のレイヤ処理手段は、
前記第１のフレームのうち、前記データを結合すると判別されなかった第１のフレームに含まれる前記データと、前記データに対して前記第２のレイヤにおいて行う第１の通信処理の内容を示す単体データ用識別情報と、を含む第３のフレームを生成する処理と、
前記第３のフレームを前記第２のレイヤ処理手段へ受け渡す処理と、
を更に行うことを特徴とする請求項１に記載の通信処理装置。
【請求項３】
前記第３のフレームは、更に、前記データを結合すると判別されなかった第１のフレームに含まれる前記データ以外の追加データを含むことを特徴とする請求項２に記載の通信処理装置。
【請求項４】
前記追加データは、前記第２のフレームを構成しない前記結合データであることを特徴とする請求項３に記載の通信処理装置。
【請求項５】
前記第２のレイヤ処理手段は、前記第２のフレームに含まれるデータと、前記第３のフレームに含まれるデータと、を結合し、第３のレイヤ処理手段に受け渡すことを特徴とする請求項１乃至４の何れか一項に記載の通信処理装置。
【請求項６】
各第１のフレームの識別情報は、第１及び第２の識別情報を含み、
前記第１の処理では、前記第１の識別情報が互いに同一である複数の第１のフレームを、前記データを結合する第１のフレームであると判別することを特徴とする請求項１乃至５の何れか一項に記載の通信処理装置。
【請求項７】
各第１のフレームの識別情報は、第１及び第２の識別情報を含み、
前記第１の処理では、前記第１の識別情報が互いに同一である複数の第１のフレームを、前記データを結合する第１のフレームであると判別し、
前記第３のフレームは、前記互いに同一の第１の識別情報とは異なる前記第１の識別情報を含む前記第１のフレームに含まれる前記データ、前記異なる第１の識別情報及び前記第２の識別情報を含むことを特徴とする請求項２乃至５の何れか一項に記載の通信処理装置。
【請求項８】
前記第１の処理では、前記第２のレイヤにおける所定の通信処理の要否を、前記第１の識別情報の内容に基づいて判別し、前記所定の通信処理の要否に応じて、前記データを結合する第１のフレームを判別することを特徴とする請求項６又は７に記載の通信処理装置。
【請求項９】
前記第１の処理では、前記所定の通信処理が不要である旨を示す前記第１の識別情報を含む第１のフレームを、前記データを結合する第１のフレームであると判別することを特徴とする請求項８に記載の通信処理装置。
【請求項１０】
前記第１の処理では、
前記第２のレイヤにおける所定の通信処理の要否を、前記第１の識別情報の内容に基づいて判別し、前記所定の通信処理の要否に応じて、前記データを結合し、
前記第１の処理では、前記所定の通信処理が不要である旨を示す前記第１の識別情報を含む第１のフレームを、前記データを結合する第１のフレームであると判別し、
前記第３のフレームは、前記所定の通信処理が必要である旨を示す前記第１の識別情報を含む第１のフレームに含まれる前記データを含むことを特徴とする請求項７に記載の通信処理装置。
【請求項１１】
前記結合データ用識別情報は、前記データを結合すると判別された複数の前記第１のフレームのうち、何れか１つの第１のフレームの前記第２の識別情報を含むことを特徴とする請求項６乃至１０の何れか一項に記載の通信処理装置。
【請求項１２】
前記第２の識別情報は、前記データの順序を示す番号を含むことを特徴とする請求項１１に記載の通信処理装置。
【請求項１３】
個々の結合データには、前記番号が連続する前記データのみが含まれることを特徴とする請求項１２に記載の通信処理装置。
【請求項１４】
前記結合データ用識別情報に含まれる前記第２の識別情報は、当該結合データ用識別情報に対応する結合データに含まれるデータのうち、前記順序が先頭のデータの前記番号を含むことを特徴とする請求項１２又は１３に記載の通信処理装置。
【請求項１５】
前記結合データは、前記データを前記番号順にならべて結合してなることを特徴とする請求項１２乃至１４の何れか一項に記載の通信処理装置。
【請求項１６】
第１のレイヤにおける通信処理を行う第１のレイヤ処理手段と、第２のレイヤにおける通信処理を行う第２のレイヤ処理手段と、を備える通信処理装置において、少なくとも前記第１のレイヤにおける通信処理を行う通信処理方法であって、
前記第１のレイヤにおける通信処理は、
データと、前記第２のレイヤにおいて前記データに対する所定の通信処理に用いられる識別情報と、を含む複数の第１のフレームのうち、前記データを相互に結合する第１のフレームを、前記識別情報の内容に応じて判別する工程と、
前記データを結合すると判別された前記第１のフレームの前記データを相互に結合した結合データと、前記結合データに含まれる前記データに対して前記第２のレイヤにおいて行う通信処理の内容を示す結合データ用識別情報と、を含む第２のフレームを生成する工程と、
前記第２のフレームを前記第２のレイヤへ受け渡す工程と、
を備えることを特徴とする通信処理方法。
【請求項１７】
前記第１のレイヤにおける通信処理は、
前記第１のフレームのうち、前記データを結合すると判別されなかった第１のフレームに含まれる前記データと、前記データに対して前記第２のレイヤにおいて行う通信処理の内容を示す単体データ用識別情報と、を含む第３のフレームを生成する工程と、
前記第３のフレームを前記第２のレイヤへ受け渡す工程と、
を更に備えることを特徴とする請求項１６に記載の通信処理方法。
【請求項１８】
第１のレイヤにおける通信処理を行う第１のレイヤ処理手段と、第２のレイヤにおける通信処理を行う第２のレイヤ処理手段と、を備える通信処理装置において、少なくとも前記第１のレイヤにおける通信処理をコンピュータに実行させるプログラムであって、
前記第１のレイヤにおける通信処理は、
データと、前記第２のレイヤにおいて前記データに対する所定の通信処理に用いられる識別情報と、を含む複数の第１のフレームのうち、前記データを相互に結合する第１のフレームを、前記識別情報の内容に応じて判別する処理と、
前記データを結合すると判別された前記第１のフレームの前記データを相互に結合した結合データと、前記結合データに含まれる前記データに対して前記第２のレイヤにおいて行う通信処理の内容を示す結合データ用識別情報と、を含む第２のフレームを生成する処理と、
前記第２のフレームを前記第２のレイヤへ受け渡す処理と、
を含むことを特徴とするプログラム。
【請求項１９】
前記第１のレイヤにおける通信処理は、
前記第１のフレームのうち、前記データを結合すると判別されなかった第１のフレームに含まれる前記データと、前記データに対して前記第２のレイヤにおいて行う通信処理の内容を示す単体データ用識別情報と、を含む第３のフレームを生成する処理と、
前記第３のフレームを前記第２のレイヤへ受け渡す処理と、
を更に含むことを特徴とする請求項１８に記載のプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、通信処理装置、通信処理方法及びそのプログラムに関する。
【背景技術】
【０００２】
図１３はＷ−ＣＤＭＡ（Ｗｉｄｅｂａｎｄ  Ｃｏｄｅ  Ｄｉｖｉｓｉｏｎ  Ｍｕｌｔｉｐｌｅ  Ａｃｃｅｓｓ）のシステムで想定されている無線インターフェイスのプロトコル階層を示す図である。
【０００３】
図１３に示すように、Ｗ−ＣＤＭＡのシステムで想定されている無線インターフェイスのプロトコル階層は、ＰＨＹ（物理）レイヤ２０１と、ＭＡＣ（Ｍｅｄｉｕｍ  Ａｃｃｅｓｓ  Ｃｏｎｔｒｏｌ）レイヤ２０２と、ＲＬＣ（Ｒａｄｉｏ  Ｌｉｎｋ  Ｃｏｎｔｒｏｌ）レイヤ２０３と、ＰＤＣＰ（Ｐａｃｋｅｔ  Ｄａｔａ  Ｃｏｎｖｅｒｇｅｎｃｅ  Ｐｒｏｔｏｃｏｌ）レイヤ２０４と、アプリケーション・レイヤ２０５と、ＲＲＣ（Ｒａｄｉｏ  Ｒｅｓｏｕｒｃｅ  Ｃｏｎｔｒｏｌ）レイヤ２０６と、ＮＡＳ（Ｎｏ  Ａｃｃｅｓｓ  Ｓｔｒａｔｕｍ）レイヤ２０７と、を備えて構成されている。
【０００４】
ＰＨＹレイヤ２０１はトランスポート・チャネルによる無線伝送や無線品質などの測定を行うレイヤである。
【０００５】
ＭＡＣレイヤ２０２は、ＲＬＣレイヤ２０３に対し、論理チャネルの伝送や無線リソースの割り当てを行うレイヤである。
【０００６】
ＲＬＣレイヤ２０３は、上位レイヤであるＰＤＣＰレイヤ２０４へのデータ伝送サービスを提供するレイヤである。ＲＬＣレイヤ２０３とアプリケーション・レイヤ２０５との間のデータ転送は、ＰＤＣＰレイヤ２０４を介して行われる。
【０００７】
ＲＲＣレイヤ２０６は、無線リソースを制御するレイヤであり、ＮＡＳレイヤ２０７に対して接続される。
【０００８】
ＲＬＣレイヤ２０３とアプリケーション・レイヤ２０５との間の制御情報の転送は、ＲＲＣレイヤ２０６及びＮＡＳレイヤ２０７を介して行われる。
【０００９】
現状のＷ−ＣＤＭＡ（３ＧＰＰ  ＵＭＴＳ）には、ＨＳＤＰＡ（Ｈｉｇｈ  Ｓｐｅｅｄ  Ｄｏｗｎｌｉｎｋ  Ｐａｃｋｅｔ  Ａｃｃｅｓｓ  ：  ３ＧＰＰ  Ｒｅｌｅａｓｅ．５から導入）、Ｅ−ＤＣＨ（Ｅｎｈａｎｃｅｄ  ＤＣＨ  ：  ３ＧＰＰ  Ｒｅｌｅａｓｅ．６から導入）などの機能が追加されている。これらの追加に伴い、アップリンク（Ｕｐｌｉｎｋ）、ダウンリンク（Ｄｏｗｎｌｉｎｋ）共に高スループット化の実現が進んでいる。また、今後も、携帯電話機においては高スループットを実現するために処理削減の必要性が常に存在する。
【００１０】
ダウンリンクの無線帯域が大きくなる場合、一定時間に処理しなくてはならないデータ量が増えることとなる。すなわち、ＲＬＣ  ＰＤＵ（ＰＤＵ：Ｐｒｏｔｏｃｏｌ  Ｄａｔａ  Ｕｎｉｔ）のサイズが固定であると仮定すると、ＲＬＣレイヤ２０３において一定時間に処理しなくてはならないＲＬＣ  ＰＤＵの個数が増えることとなる。一般的に、一定時間内に処理すべきＲＬＣ  ＰＤＵの個数が増えることは、ＲＬＣレイヤ２０３において一定時間内に処理すべきステップ数が増えることとなり、処理負荷の増大に繋がる。
【００１１】
このことをＨＳＤＰＡの環境下において具体的な数値に当てはめると以下のようになる。
【００１２】
図１４は、ＲＬＣレイヤ２０３において１ＴＴＩ内に受信したＨＳ−ＤＳＣＨのトランスポート・ブロックの最大ビット数と、ＲＬＣレイヤ２０３において１ＴＴＩ内に処理すべきＲＬＣ  ＰＤＵの理論上の最大数との対応関係を、ＨＳＤＰＡのカテゴリ毎に示す図である。なお、１ＴＴＩ（ＴＴＩ：Ｔｒａｎｓｍｉｔ  Ｔｉｍｅ  Ｉｎｔｅｒｖａｌ）は２ｍｓｅｃ、ＲＬＣ  ＰＤＵのデータ・サイズは４２バイトであるものとする。また、ＨＳＤＰＡのカテゴリ６の環境下ではダウンリンクのレートは最大３．６Ｍｂｐｓ、同カテゴリ８の環境下ではダウンリンクのレートは最大７．２Ｍｂｐｓ、同カテゴリ１０の環境下ではダウンリンクのレートは最大１４．４Ｍｂｐｓである。
【００１３】
ここで、ＭＡＣ−ｈｓ（ＨＳ−ＤＳＣＨ向けＭＡＣ）で使用するＭＡＣ−ｈｓヘッダのサイズは、通信経路が１つだけの基本的なチャネル・コンフィグレーションの場合には２１ビットとなる。
【００１４】
このため、図１４に示す値（最大数）は、“ＭＡＣ−ｈｓヘッダのサイズ＝２１ビット”として、次の計算式（１）に当てはめて求めた値である。
【００１５】
（１ＴＴＩに処理すべきＲＬＣ  ＰＤＵの理論上の最大数）＝（１ＴＴＩ内に受信したＨＳ−ＤＳＣＨのトランスポート・ブロックの最大ビット数）／３３６（ビット）・・・・・・計算式（１）
図１４に示すように、帯域が広がるほど、ＲＬＣレイヤ２０３において一定時間（１ＴＴＩ）内に処理しなければならないＲＬＣ  ＰＤＵの個数が増えることとなる。
【００１６】
図１５は、通信経路が１つだけの基本的なチャネル・コンフィグレーションの場合において、データ・フレームの名称及び形態がレイヤ毎にどのように変化するのかを示す図である。
【００１７】
図１５に示すように、ＲＬＣ  ＰＤＵは、１６ビットのＲＬＣ  ＡＭ（ＡＭ：Ａｃｋｎｏｗｌｅｄｇｅ  Ｍｏｄｅ：確認モード）ヘッダと、３２０ビットのペイロード部と、からなる３３６ビットのフレームである。
【００１８】
また、ＭＡＣ−ｄ  ＰＤＵ（個別チャネル向けＭＡＣ）も、３３６ビットのフレームである。
【００１９】
ＭＡＣ−ｈｓ  ＳＤＵ（ＳＤＵ：Ｓｅｒｖｉｃｅ  Ｄａｔａ  Ｕｎｉｔ）は、２１個分のＭＡＣ−ｄＰＤＵ（２１×３３６＝７０５６ビット）に２２１ビットのパディング（Ｐａｄｄｉｎｇ）を加えてなる合計７２７７ビットのフレームである。
【００２０】
ＭＡＣ−ｈｓ  ＰＤＵは、ＭＡＣ−ｈｓ  ＳＤＵにＭＡＣ−ｈｓヘッダを加えてなるフレームである。例えば、１個のＭＡＣ−ｈｓ  ＳＤＵに２１ビットのＭＡＣ−ｈｓヘッダを加えてなるＭＡＣ−ｈｓ  ＰＤＵの場合は、合計７２９８ビットのフレームになる。このＭＡＣ−ｈｓ  ＰＤＵがトランスポート・ブロックとなる。
【００２１】
次に、ＲＬＣ  ＰＤＵの構造及びプロトコル規定について説明する。
【００２２】
図１６はＲＬＣ  ＰＤＵの構造を示す図である。
【００２３】
ＲＬＣ  ＰＤＵの構造は「３ＧＰＰ  ＴＳ２５．３２２  Ｃｈａｐｔｅｒ９．２  Ｆｏｒｍａｔｓ  ａｎｄ  ｐａｒａｍｅｔｅｒｓ」に規定されている。
【００２４】
図１７はＲＬＣ  ヘッダを構成している各識別情報のデータ量及び内容を示す図である。各識別情報は、一般的には、ヘッダのＩＥ（Ｉｎｆｏｒｍａｔｉｏｎ  Ｅｌｅｍｅｎｔ：情報要素）と称される。
【００２５】
図１７に示すように、「Ｄ／Ｃ」は、コントロールＰＤＵ（Ｃｏｎｔｒｏｌ  ＰＤＵ：制御用ＰＤＵ）とデータＰＤＵ（Ｄａｔａ  ＰＤＵ）とを識別するための、１ビットのＤ／Ｃフィールドである。すなわち、Ｄ／Ｃフィールドの値が「０」であれば、ＲＬＣ  ＰＤＵがコントロールＰＤＵであることを示し、Ｄ／Ｃフィールドの値が「１」であれば、ＲＬＣ  ＰＤＵがデータＰＤＵであることを示す。
【００２６】
また、「シーケンス・ナンバー（Ｓｅｑｕｅｎｃｅ  Ｎｕｍｂｅｒ：以下、ＳＮと略記）」は、ＰＤＵのシーケンス・ナンバーを示す１２ビットのデータである。すなわち、ＳＮは、０〜４０９５までの何れかの値となる。なお、ＰＤＵの数が４０９６個を超える場合、シーケンス・ナンバーは循環的に使用される。
【００２７】
「Ｐ」は、送達確認（Ｓｔａｔｕｓ  Ｒｅｐｏｒｔ）の要求の有無を示すための、１ビットのポーリング・ビット（Ｐｏｌｌｉｎｇ  ビット）である。「Ｐ」の値が「０」であれば送達確認が要求されていないことを示し、「Ｐ」の値が「１」であれば送達確認が要求されていることを示す。
【００２８】
「ＨＥ」は、後続データとしてレングス・インジケータ（Ｌｅｎｇｔｈ  Ｉｎｄｉｃａｔｏｒ）が存在するか否かを識別するための２ビットのヘッダ・エクステンション・タイプ（Ｈｅａｄｅｒ  Ｅｘｔｅｎｓｉｏｎ  Ｔｙｐｅ）である。「ＨＥ」の値が「００」であれば、次の８ビットがデータであることを示し、「ＨＥ」の値が「０１」であれば、次の８ビットがレングス・インジケータと後述する「Ｅ（Ｅ  ビット）」とを含むことを示す。
【００２９】
「Ｅ」は、１ビットのエクステンション・ビット（Ｅｘｔｅｎｓｉｏｎ  ｂｉｔ）である。「Ｅ」の値が「０」であれば、次のフィールドが、データ、ピギーバック・ステータスＰＤＵ（ｐｉｇｇｙｂａｃｋｅｄ  ＳＴＡＴＵＳ  ＰＤＵ）及びパディング（ｐａｄｄｉｎｇ）のうちの何れかであることを示す。また、「Ｅ」の値が「１」であれば、次のフィールドがレングス・インジケータ及びＥ  ｂｉｔであることを示す。
【００３０】
「レングス・インジケータ（Ｌｅｎｇｔｈ  Ｉｎｄｉｃａｔｏｒ（ＬＩ））」は、バイト数が可変である。ＬＩは、ＲＬＣ  ＳＤＵを構成するＰＤＵのうち最終セグメント（ｓｅｇｍｅｎｔ）を構成するＰＤＵを示すために用いられる。
【００３１】
例えば、ＬＩの値が［００１０１００（＝２０）］であれば、該ＬＩを有するＰＤＵにおける２０バイト目がＳＤＵの終端（データの終端）である旨を示す。
【００３２】
また、ＬＩの値が［１１１１１１１］であれば、残りのデータはパディングである旨を示す。
【００３３】
ここで、ＴＣＰ／ＩＰを使用するような一般的な環境下におけるＲＬＣ  ＰＤＵの特性を考える。
【００３４】
図１８は、ＲＬＣ  ＳＤＵのサイズ＝１５００バイト、ＲＬＣ  ＰＤＵのサイズ＝４２バイトの環境下において、ＲＬＣ  ＳＤＵとＲＬＣ  ＰＤＵとの対応を示す図である。
【００３５】
図１８に示すように、ＲＬＣ  ＳＤＵのサイズ＝１５００バイト、ＲＬＣ  ＰＤＵのサイズ＝４２バイトであれば、１個のＲＬＣ  ＳＤＵは３８個のセグメントに分割される。
【００３６】
そして、各セグメントにヘッダが付加されることにより、それぞれＲＬＣ  ＰＤＵを構成する。
【００３７】
この場合、先頭セグメント（Ｎｏ．１）から３７個目（Ｎｏ．３７）までの合計３７個のセグメントについては、データ・サイズが４０バイトである。また、これら３７個のセグメントについては、付加されるヘッダ内のＰ（ポーリング・ビット）の値が「０」、ＨＥ（ヘッダ・エクステンション・タイプ）の値が「００」であり、送達確認の要求がないとともに、ＬＩ（レングス・インジケータ）が付加されない。
【００３８】
最終セグメント（Ｎｏ．３８）のみ、データ・サイズが、例えば２０バイトである（１５００−３７×４０＝２０のため）。この最終セグメントについては、付加されるヘッダ内のＰ（ポーリング・ビット）の値が「１」、ＨＥ（ヘッダ・エクステンション・タイプ）の値が「０１」であり、送達確認の要求が有るとともに、ＬＩ（レングス・インジケータ）が付加される。
【００３９】
なお、これら３８個のＲＬＣ  ＰＤＵには、連続するＳＮ（シーケンス・ナンバー）が付与される（例えば、図１８の例では、０〜３７のＳＮを付与している）。
【００４０】
図１９は、ＲＬＣ  ＰＤＵのサイズが４２バイト、ＲＬＣ  ＳＤＵのサイズが１５００バイトの環境下における一般的なダウンリンク・データ転送の動作を示す模式図である。すなわち、図１９は、Ｗ−ＣＤＭＡの通信システムにおいて想定されている無線インターフェイスのプロトコル階層のうち、ＭＡＣレイヤ２０２からＲＬＣレイヤ２０３へのデータ転送と、ＲＬＣレイヤ２０３からＰＤＣＰレイヤ２０４への、ダウンリンク時のデータ転送の一般的な動作を示す。
【００４１】
ＭＡＣ−ｈｓのペイロード部にはＲＬＣヘッダが含まれているため、一般的には、図１９に示すように、ＭＡＣレイヤ２０２からＲＬＣレイヤ２０３へは、ＲＬＣ  ＰＤＵをそのままの形で転送する（受け渡す）。
【００４２】
すなわち、図１９に示すように、ＭＡＣレイヤ２０２からＲＬＣレイヤ２０３へとＲＬＣ  ＳＤＵ（＝１５００バイト）１個分のデータ転送を行うに際しては、ＳＮ＝０〜３７の合計３８個のＲＬＣ  ＰＤＵをＭＡＣレイヤ２０２からＲＬＣレイヤ２０３へと受け渡す。
【００４３】
また、ＲＬＣレイヤ２０３からＰＤＣＰレイヤ２０４へのデータ転送においては、ＲＬＣレイヤ２０３において個々のＲＬＣ  ＰＤＵのペイロード部を結合することによりＲＬＣ  ＳＤＵを生成し、該生成したＲＬＣ  ＳＤＵを上位レイヤであるＰＤＣＰレイヤ２０４へと受け渡す。
【００４４】
すなわち、図１８に示すように、ＲＬＣレイヤ２０３からＰＤＣＰレイヤ２０４へのデータ転送においては、３８個の各ＲＬＣ  ＰＤＵからそれぞれヘッダを除いたペイロード部の各々を１つに結合することによりＲＬＣ  ＳＤＵを生成し、該生成したＲＬＣ  ＳＤＵをＲＬＣレイヤ２０３からＰＤＣＰレイヤ２０４へと受け渡す。
【００４５】
図２０は、図１９とは逆に、一般的なアップリンク・データ転送の動作を示す模式図である。この場合も、ＲＬＣ  ＰＤＵのサイズが４２バイト、ＲＬＣ  ＳＤＵのサイズが１５００バイトの環境下における動作を示す。すなわち、図２０は、ＰＤＣＰレイヤ２０４からＲＬＣレイヤ２０３へのデータ転送と、ＲＬＣレイヤ２０３からＭＡＣレイヤ２０２へのデータ転送の一般的な動作を示す。
【００４６】
図２０に示すように、ＰＤＣＰレイヤ２０４からＲＬＣレイヤ２０３へと１個のＲＬＣ  ＳＤＵをデータ転送するに際しては、一纏まりのＲＬＣ  ＳＤＵをＰＤＣＰレイヤ２０４からＲＬＣレイヤ２０３へと送信する。
【００４７】
また、ＲＬＣレイヤ２０３からＭＡＣレイヤ２０２へのデータ転送においては、ＲＬＣ  ＳＤＵをＳＮ＝０〜３７の合計３８個のデータに分割し、各データにヘッダを付与することにより、合計３８個のＲＬＣ  ＰＤＵを生成する。そして、これら３８個のＲＬＣ  ＰＤＵをＲＬＣレイヤ２０３からＭＡＣレイヤ２０２へと受け渡す。
【００４８】
なお、本発明に関連する先行技術文献としては、特許文献１−３がある。
【００４９】
特許文献１−３には、複数のフレームを結合して他のレイヤへ転送する通信処理を行う技術が開示されている。
【特許文献１】特開２０００−０５９４３５号公報
【特許文献２】特開２００５−３１８２１１号公報
【特許文献３】特開２００８−００５４９３号公報
【発明の開示】
【発明が解決しようとする課題】
【００５０】
上述のように、無線の帯域が増加する場合、一定時間に処理しなくてはならないデータ量が増えることとなる。すなわち、ＲＬＣ  ＰＤＵのサイズが固定であると仮定すると、ＲＬＣレイヤ２０３では一定時間に処理しなくてはならないＲＬＣ  ＰＤＵの個数が増えることとなる。一般的に、一定時間内に処理すべきＲＬＣ  ＰＤＵの個数が増えることは、ＲＬＣレイヤ２０３において一定時間内に処理すべきステップ数が増えることとなり、処理負荷の増大に繋がる。そのため、データ量が増加しても、処理すべきＲＬＣ  ＰＤＵの個数が増えないような仕組みが有効である。
【００５１】
特許文献１記載の通信装置では、ヘッダを含む複数のフレームの、ヘッダ以外の部分（特許文献１では「パケット」と表現）を結合する。そして、結合した「パケット」に対して１個のヘッダのみを付加する。これによって、オーバーヘッドを減少させ、パケットの効率的な伝送を可能にしている（［０００９］、［００１１］等）。
【００５２】
特許文献２記載の通信装置では、複数のＴＴＩ分のＰＤＵをまとめて、他のレイヤへ出力する。これによって、ヘッダなどのオーバーヘッド情報を低減している（［００９４］、［００９８］等）。
【００５３】
特許文献３記載の通信装置では、複数のＰＤＣＰ  ＰＤＵを、ＲＬＣ  ＰＤＵとして結合・連結する。これによって、ＰＤＣＰシーケンス番号が１個のみとなり、無線資源が節約される（［００１６］等）。
【００５４】
このように、特許文献１−３記載の通信装置では、送信、あるいは他のレイヤに受け渡されるフレームの個数が削減され、ヘッダ部によるオーバーヘッドは確かに減少する。
【００５５】
ところが、一般の通信装置で取り扱われるフレームに含まれるヘッダの内容は複雑であり、シーケンス・ナンバー（ＳＮ）のような単純な情報のみではない。ＳＮは、その値の連続性を利用することができるので、複数のフレームについて１個のＳＮを代表として付加することも可能である。
【００５６】
しかし、ＳＮ以外のヘッダ情報、例えば、各レイヤにおけるプロトコル処理の種類を識別するようなヘッダ情報の場合は、全フレームについて同一でないことが一般的である。当然ながら、このようなヘッダ情報は、他のフレームのヘッダ情報から類推することはできない。
【００５７】
例えば、ＭＡＣ  ＰＤＵの１個目から３７個目まではＰ＝０であるが、３８個目はＰ＝１である。このような場合は、各ＭＡＣ  ＰＤＵについてＰ＝０であるか否かを見極めた上で、各フレームのヘッダ情報の削除の可否を判断し、そしてフレームを統合しなければならない。
【００５８】
しかし、特許文献１−３記載の通信装置では、ヘッダを削除しフレームを結合する際には、各フレームのヘッダ情報の内容を判別した上で行う必要があることについて、全く考慮されていない。そのため、複数のフレームの各ヘッダ情報の内容が異なる場合に対応することができない。すなわち、特許文献１−３記載の通信装置では、ヘッダ情報が同一ではないという一般的な場合において、ヘッダの削除及びフレームの結合という方法を用いることができない。
【００５９】
そのため、特許文献１−３記載の通信装置には、一般的な場合に、オーバーヘッドを削減することによって、通信効率を向上させることができないという課題がある。あるいは、特許文献１−３記載の通信装置には、一般的な場合に、通信処理装置内で管理するフレームの数を減少させることによって、通信処理装置の処理負荷を低減することができないという課題がある。
【００６０】
本発明は、上記のような問題点を解決することが可能な通信処理装置、通信処理方法及びそのプログラムを提供することを目的とする。
【課題を解決するための手段】
【００６１】
上記課題を解決するため、本発明の通信処理装置は、第１のレイヤにおける通信処理を行う第１のレイヤ処理手段と、第２のレイヤにおける通信処理を行う第２のレイヤ処理手段と、を備え、前記第１のレイヤ処理手段は、データと、前記第２のレイヤにおいて前記データに対する所定の通信処理に用いられる識別情報と、を含む複数の第１のフレームのうち、前記データを相互に結合する第１のフレームを、前記識別情報の内容に応じて判別する第１の処理と、前記データを結合すると判別された前記第１のフレームの前記データを相互に結合した結合データと、前記結合データに含まれる前記データに対して前記第２のレイヤにおいて行う通信処理の内容を示す結合データ用識別情報と、を含む第２のフレームを生成する処理と、前記第２のフレームを、前記第２のレイヤ処理手段へ受け渡す処理と、を行うことを特徴としている。
【００６３】
また、本発明の通信処理方法は、第１のレイヤにおける通信処理を行う第１のレイヤ処理手段と、第２のレイヤにおける通信処理を行う第２のレイヤ処理手段と、を備える通信処理装置において、少なくとも前記第１のレイヤにおける通信処理を行う通信処理方法であって、前記第１のレイヤにおける通信処理は、データと、前記第２のレイヤにおいて前記データに対する所定の通信処理に用いられる識別情報と、を含む複数の第１のフレームのうち、前記データを相互に結合する第１のフレームを、前記識別情報の内容に応じて判別する工程と、前記データを結合すると判別された前記第１のフレームの前記データを相互に結合した結合データと、前記結合データに含まれる前記データに対して前記第２のレイヤにおいて行う通信処理の内容を示す結合データ用識別情報と、を含む第２のフレームを生成する工程と、前記第２のフレームを前記第２のレイヤへ受け渡す工程と、を備えることを特徴としている。
【００６５】
また、本発明のプログラムは、第１のレイヤにおける通信処理を行う第１のレイヤ処理手段と、第２のレイヤにおける通信処理を行う第２のレイヤ処理手段と、を備える通信処理装置において、少なくとも前記第１のレイヤにおける通信処理をコンピュータに実行させるプログラムであって、前記第１のレイヤにおける通信処理は、データと、前記第２のレイヤにおいて前記データに対する所定の通信処理に用いられる識別情報と、を含む複数の第１のフレームのうち、前記データを相互に結合する第１のフレームを、前記識別情報の内容に応じて判別する処理と、前記データを結合すると判別された前記第１のフレームの前記データを相互に結合した結合データと、前記結合データに含まれる前記データに対して前記第２のレイヤにおいて行う通信処理の内容を示す結合データ用識別情報と、を含む第２のフレームを生成する処理と、前記第２のフレームを前記第２のレイヤへ受け渡す処理と、を含むことを特徴としている。
【発明の効果】
【００６７】
本発明によれば、第１のレイヤでは、データを相互に結合する第１のフレームを各第１のフレームの識別情報の内容に応じて判別し、該判別した第１のフレームのデータを相互に結合した結合データと、結合データに含まれるデータに対して第２のレイヤにおいて行う通信処理の内容を示す結合データ用識別情報と、を含む第２のフレームを生成し、該第２のフレームを第１のレイヤから第２のレイヤへ受け渡すので、第１のレイヤから第２のレイヤへ受け渡すフレームの数を低減することができる。よって、第２のレイヤにおける処理負荷を軽減することができる。しかも、第２のレイヤにおいて結合すべきデータ数を低減でき、その点でも第２のレイヤにおける処理負荷を軽減することができる。
【００６８】
或いは、本発明によれば、第１のレイヤでは、第１のデータを複数の第２のデータに分割し、「データ送信先の通信処理装置が第２のデータの各々に対して第２のレイヤにおいて行う所定の通信処理」に用いられる識別情報を各第２のデータ毎に生成し、個々の第２のデータと当該第２のデータに対応して生成された識別情報とを含む第２のフレームを生成し、各第２のフレームを送信先の通信処理装置宛に送信するので、送信元において第２のレイヤから第１のレイヤへ受け渡すフレームの数を低減することができる。よって、第２のレイヤにおける処理負荷を軽減することができる。しかも、送信元の第２のレイヤにおけるデータの分割数を低減でき、その点でも該第２のレイヤにおける処理負荷を軽減することができる。
【発明を実施するための最良の形態】
【００６９】
以下、図面を参照して、本発明の実施形態に係る通信処理装置、通信処理方法及びそのプログラムについて説明する。
【００７０】
〔第１の実施形態〕
図１は第１の実施形態に係る通信処理装置１００の構成を示すブロック図である。
【００７１】
図１に示すように、本実施形態に係る通信処理装置１００は、制御部１０１と、送受信部１０２と、を備えている。
【００７２】
制御部１０１は、例えば、第１のレイヤにおける通信処理（以下、第１の通信処理）を行う第１のレイヤ処理手段１０３と、第２のレイヤにおける通信処理（以下、第２の通信処理）を行う第２のレイヤ処理手段１０４と、第３のレイヤにおける通信処理を行う第３のレイヤ処理手段１０５と、を備えている。
【００７３】
第１のレイヤ処理手段１０３は、所定の規格に従って第１のレイヤにおける第１の通信処理を行う。
【００７４】
同様に、第２のレイヤ処理手段１０４は所定の規格に従って第２のレイヤにおける第２の通信処理を行い、第３のレイヤ処理手段１０５は所定の規格に従って第３のレイヤにおける第３の通信処理を行う。
【００７５】
なお、本実施形態では、第１〜第３のレイヤは、第１、第２、第３レイヤの順に階層構造をなしている。第１のレイヤと第２のレイヤ、第２のレイヤと第３のレイヤの相互間における上位・下位の関係は特に限定されない。すなわち、上位のレイヤから順に第１、第２、第３レイヤであっても、あるいはその逆であってもよい。
【００７６】
送受信部１０２は、通信処理装置１００の外部（例えば、ネットワーク、或いは外部の通信処理装置）からフレームを受信する処理と、制御部１０１の制御下でフレームを通信処理装置１００の外部（例えば、ネットワーク、或いは外部の通信処理装置）に送信する処理と、を行う。
【００７７】
図２は第１の実施形態に係る通信処理方法の動作を示す図である。
【００７８】
図２に示すように、第１のレイヤ処理手段１０３は、通信処理装置１００の外部より送受信部１０２を介して複数の第１のフレームを受信する。
【００７９】
なお、第１のレイヤ処理手段１０３が一度に処理する第１のフレームの数は任意であるが、ここでは、簡単のため、一度に処理する第１のフレームが第１のフレーム３１、３２、３３の３つである例を説明する。
【００８０】
各第１のフレーム３１、３２、３３は、それぞれのデータ１、２、３と、各データ１、２、３に対して第２のレイヤにおいて行われる所定の通信処理（第２の通信処理）に用いられる識別情報と、を含む構成とされている。
【００８１】
第１のフレーム３１，３２は、互いに同一の識別情報１１を含む。
【００８２】
また、第１のフレーム３３は、識別情報１１とは異なる識別情報１２を含む。
【００８３】
第１のレイヤ処理手段１０３は、受信した第１のフレーム３１〜３３のうち、データを相互に結合して１つにまとめる第１のフレームを、各第１のフレームの識別情報の内容に応じて判別する。
【００８４】
第２のレイヤでは、識別情報１１，１２の内容に応じて、各データ１〜３に対し第２の通信処理を行う。
【００８５】
第２の通信処理の例としては、データ内のエラー検出、エラーを検出した場合におけるデータ送信元へのデータ再送要求（以下、単に再送要求）、データ送信元に対するデータを受信した旨の通知（以下、受信応答）、などがある。これらの処理を行うか否か、行う場合にどのような処理内容で行うか（モードの選択）などは、識別情報の内容によって指定される。また、第２のレイヤでは、識別情報が互いに同一のフレームのデータに対しては、同一の第２の通信処理を行う。
【００８６】
そこで、第１の実施形態では、第１のレイヤ処理手段１０３は、第２のレイヤ処理手段１０４にフレームを受け渡す際に、互いに等しい識別情報を有する第１のフレームのデータを相互に結合し、１つにまとめてから受け渡す。
【００８７】
具体的には、例えば、図２に示すように、第１のレイヤ処理手段１０３は、同一の識別情報１１を有する第１のフレーム３１、３２のデータ１，２を、相互に結合するデータであると判別する。そして、相互に結合すると判別したデータ１，２を結合することによって、結合データ２０を生成する。
【００８８】
結合データ２０に含まれるデータ１，２に対しては、第２のレイヤにおいて互いに同一の第２の通信処理を行う。このため、第１のレイヤ処理手段１０３は、結合データ２０に対しては１つの識別情報を代表識別情報（結合データ用識別情報）１３として付加する。すなわち、代表識別情報１３と結合データ２０とを含む第２のフレーム３４を生成する。なお、代表識別情報１３は、例えば、識別情報１１と同じ内容である。
【００８９】
そして、第１のレイヤ処理手段１０３は、第２のフレーム３４を第２のレイヤ処理手段１０４へ受け渡す。
【００９０】
また、第１のレイヤ処理手段１０３は、データ３を結合するとは判別されなかった第１のフレーム３３は、そのまま第３のフレーム３５として第２のレイヤ処理手段１０４へ受け渡す。
【００９１】
第２のレイヤ処理手段１０４は、結合データ２０に含まれる各データ１，２に対しては、識別情報１１の内容に従って、同一の第２の通信処理を行う。
【００９２】
また、第２のレイヤ処理手段１０４は、第３のフレーム３５のデータ３に対しては、識別情報１２の内容に従って、第２の通信処理を行う。
【００９３】
このように各データ１，２，３に対して第２の通信処理を行った後で、第２のレイヤ処理手段１０４は、各データ１，２，３を組み合わせて１つのフレーム、すなわち、図２に示すように第４のフレーム３６を生成し、該第４のフレーム３６を第３のレイヤ処理手段１０５へ受け渡す。
【００９４】
ここで、図１において、制御部１０１の第１〜第３のレイヤ処理手段１０３〜１０５は、制御部１０１の機能的構成である。
【００９５】
図３は制御部１０１のハードウェア構成の例を示すブロック図である。
【００９６】
制御部１０１は、具体的には、例えば、図３に示すように、制御動作を実行するＣＰＵ（Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ）１１１と、このＣＰＵ１１１の動作用プログラムを記憶保持したＲＯＭ（Ｒｅａｄ  Ｏｎｌｙ  Ｍｅｍｏｒｙ）１１２と、ＣＰＵ１１１の作業領域などとして機能するＲＡＭ（Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙ）１１３と、を備えて構成されている。
【００９７】
そして、制御部１０１は、これらＣＰＵ１１１、ＲＯＭ１１２、ＲＡＭ１１３の協働により、第１〜第３のレイヤ処理手段１０３〜１０５として機能する。
【００９８】
以上のような第１の実施形態によれば、第１のレイヤでは、データを相互に結合する第１のフレーム３１，３２を各第１のフレーム３１〜３３の識別情報１１，１２の内容に応じて判別し、該判別した第１のフレーム３１，３２のデータ１，２を相互に結合して結合データ２０を生成し、代表識別情報１３（結合データ用識別情報）と結合データ２０とを含む第２のフレーム３４を生成し、該第２のフレーム３４を第２のレイヤへ受け渡すので、第１のレイヤから第２のレイヤへ受け渡すフレームの数を低減することができる。よって、第２のレイヤにおける処理負荷を軽減することができる。加えて、第２のレイヤにおいて第４のフレーム３６を生成する処理は、結合データ２０とデータ３とを組み合わせることによって行うことができるため、第２のレイヤにおける処理負荷を軽減することができる。すなわち、第２のレイヤでは、予めデータ１，２が結合されてなる結合データ２０と、データ３とを結合すればよいため、データ１，２を結合しなくて良い分、処理負荷を軽減できる。
【００９９】
なお、上記の第１の実施形態において、第２の通信処理の際には、結合データ２０を１つのデータとして扱い、一括して処理（受信応答の送信、再送要求の送信など）を行っても良い。ただし、このように結合データ２０に対し一括して第２の通信処理を行う場合には、通信相手の同じレイヤとの事前の取り決めが必要である。
【０１００】
或いは、第２の通信処理の際には、結合データ２０を結合前のデータ１，２に分割し、個々のデータ１，２に対してそれぞれ個別に、同一の処理（受信応答の送信、再送要求の送信など）を行なってもよい。
【０１０１】
何れの場合にも、結合データ２０に付加された識別情報の内容のチェック、及びその内容に応じた第２の通信処理の種類の判別は、１つの結合データ２０に対して１回だけで済む。すなわち、結合データ２０を生成せずに、各データ１，２にそれぞれ識別情報を付加した状態で第１のレイヤから第２のレイヤへ各データ１，２を受け渡す場合と比べ、第２のレイヤ処理手段１０５の処理負荷を軽減できる。
【０１０２】
また、受信したフレームが結合データ２０を含むフレーム（第２のフレーム）であるか、結合データ２０ではなく単体のデータを含むフレーム（第３のフレーム）であるかを第２のレイヤ処理手段１０４が判別する方法としては、次のような方法が挙げられる。
【０１０３】
例えば、第３のフレームの長さ（データ量）を予め規定しておき、それよりも長いフレームを第２のフレームであると判別することが挙げられる。或いは、フレームの種類を識別できるような情報を、第２のフレームに含ませるか、或いは第２及び第３のフレームの双方に含ませてもよい。
【０１０４】
或いは、結合データ２０のサイズ、或いは結合数を識別できるような情報を第２のフレームに含ませても良い。
【０１０５】
或いは、ソフトウェアの実装による対応方法もある。例えば、あるフレームの内容が、通信処理装置内のＲＡＭのある領域に記憶されているならば、その領域を示す情報を、各レイヤ処理手段１０４、１０５の間で、パラメータとして受け渡すという方法がある。
【０１０６】
また、上記の第１の実施形態では、通信処理装置１００が第１〜第３のレイヤ処理手段１０３〜１０５を備える例を説明したが、通信処理装置１００は、このうち第１のレイヤ処理手段１０３を少なくとも備えていれば良く、第２及び第３のレイヤ処理手段１０４、１０５は備えていなくても良い。すなわち、第２及び第３のレイヤ処理手段１０４、１０５のうちの少なくとも一方に相当する構成は、通信処理装置１００の外部の構成であっても良い。
【０１０７】
また、上記の第１の実施形態では、第３のレイヤが存在する例を説明したが、第３のレイヤは存在しなくても良い。例えば、第２のレイヤがアプリケーション・レイヤであってもよい。この場合、第４のフレーム３６を生成する処理、及び、第２のレイヤから第３のレイヤへ第４のフレーム３６を受け渡す処理は不要であり、第３のレイヤ処理手段１０５も不要である。
【０１０８】
＜第１の実施形態の変形例＞
上記の第１の実施形態では、第１のフレームの識別情報の全体の内容に応じて（具体的には、識別情報の全体が同一であるか否かに応じて）、データを相互に結合する第１のフレームを判別する例を説明した。
【０１０９】
これに対し、本変形例では、識別情報の一部分の内容に応じて（例えば、識別情報の一部分が同一であるか否かに応じて）、データを相互に結合する第１のフレームを判別する例を説明する。
【０１１０】
なお、本変形例の場合も、通信処理装置１００の構成は、上記の第１の実施形態（図１、図３）と同様である。
【０１１１】
図４は本変形例に係る通信処理方法の動作を示す図である。  
【０１１２】
本変形例の場合、各第１のフレームは、第１の識別情報と第２の識別情報とを含む点でのみ上記の第１の実施形態と相違する。
【０１１３】
すなわち、図４に示すように、第１のフレーム３１は、第１の識別情報としての識別情報１１と、第２の識別情報としての識別情報２１と、を含む。同様に、第１のフレーム３２は第１の識別情報としての識別情報１１と第２の識別情報としての識別情報２２とを含み、第１のフレーム３３は第１の識別情報としての識別情報１２と第２の識別情報としての識別情報２３とを含む。
【０１１４】
このうち、第１の識別情報としての識別情報１１、１２は、上記の第１の実施形態と同様である。本変形例でも、第１のレイヤ処理手段１０３は、識別情報１１、１２の内容に応じて、データを結合する第１のフレームを判別する。
【０１１５】
一方、第２の識別情報としての識別情報２１〜２３は、各第１のフレーム３１〜３３に固有の情報（例えば、フレームの順序を示す情報など）である。この第２の識別情報は、再送要求などに用いられる。
【０１１６】
上記の第１の実施形態で説明したように、結合データ２０に対する第２の通信処理は、第１の識別情報１１によって指定される、データ１、データ２に共通の処理である。すなわち、第２のレイヤでは、結合データ２０に対しては、第１の識別情報１１を参照することなしに、処理の内容を判断できる。従って、第１の識別情報１１を第２のフレーム３４に含ませる必要はない。
【０１１７】
このため、変形例の場合において結合データ２０に付加する結合データ用識別情報としては、何れか１つの第１のフレームの第２の識別情報（例えば、図４に示すように、識別情報２１）のみを用いることができる。このように、第２のフレーム３４に、第２の識別情報のみを含ませることによって、さらにヘッダ部によるオーバーヘッドを削減することができる。
【０１１８】
なお、第２のレイヤでは、結合データ２０に含まれる各データ１，２に対しては、共通の第２の通信処理を行ってもよい。或いは、結合データ２０に対して一括して第２の通信処理を行い、さらに必要に応じて、個々のデータ１，２の第２の識別情報を結合データ用識別情報に基づいて生成し、その個別データへの所定の処理を行うこともできる。
【０１１９】
〔第２の実施形態〕
本実施形態では、データ送信元の通信処理装置（送信装置）からデータ送信先の通信処理装置（受信装置）へフレームを送信する場合を想定する。また、本実施形態では、第１のレイヤは第２のレイヤの下位のレイヤであり、第２のレイヤは第３のレイヤの下位のレイヤであるものとする。そして、送信装置の第１のレイヤ、又はさらにそれよりも下位のレイヤから、ネットワーク、あるいは他の受信装置へフレームを送信する。
【０１２０】
送信装置と受信装置では、第１の実施形態と同様に、第１のレイヤ、第２のレイヤの各々において、所定の規格に基づく通信処理（第１の通信処理、第２の通信処理）を行う。
【０１２１】
なお、本実施形態の場合も、通信処理装置１００の構成は、上記の第１の実施形態（図１、図３）と同様である。
【０１２２】
図５は第２の実施形態に係る通信処理方法の動作を示す図である。
【０１２３】
図５に示すように、第２のレイヤ処理手段１０４（第２のレイヤ）から第１のレイヤ処理手段１０３（第１のレイヤ）へ受け渡すフレーム（第１のフレーム６１、第３のフレーム６４）は、データ（データ５１、３）と、該データに対して受信装置が第２のレイヤにおいて行う所定の通信処理に用いられる識別情報（識別情報１１、１２）と、を含む。
【０１２４】
受信装置の第２のレイヤにおいては、識別情報が同一のフレームのデータに対しては、同じ第２の通信処理を行う。
【０１２５】
そこで、第２の実施形態では、送信装置の第２のレイヤは、その上位の第３のレイヤから受け取った第４のフレーム６０のデータ５０を第１のレイヤに受け渡す際、第１のレイヤにおいて複数に分割されるデータ（第１のデータ）５１と、それ以外の（第１のレイヤにおいて分割されない）データ（第３のデータ）３と、に分割して受け渡す。
【０１２６】
データ５１には１つの識別情報を代表識別情報（第１のデータ用識別情報）１４として付加することにより第１のフレーム６１を生成し、この第１のフレーム６１を第１のレイヤへ受け渡す。
【０１２７】
すなわち、第４のフレーム６０のデータ５０のうち、第１のレイヤにおいて分割された際に、代表識別情報１４を元に生成できる識別情報１１が付加されるデータ１，２のかたまりであるデータ５１には、代表識別情報１４を付加してから第１のレイヤへ受け渡す。
【０１２８】
つまり、第２のレイヤ処理手段１０４は、データ５１と代表識別情報１４とを含む第１のフレーム６１を生成し、該第１のフレーム６１を第１のレイヤ処理手段１０３へ受け渡す。
【０１２９】
また、その他のデータ３、すなわち代表識別情報１４を元に生成できない識別情報１２が付加されるデータ３には、第２のレイヤにおいて識別情報１２を付加してから第１のレイヤへ受け渡す。
【０１３０】
つまり、第２のレイヤ処理手段１０４は、データ３と識別情報１２とを含む第３のフレーム６４を生成し、この第３のフレーム６４を第１のレイヤ処理手段１０３へ受け渡す。
【０１３１】
ここで、データ５０をデータ５１とデータ３とに分割する方法としては、例えば、規定のサイズの整数倍のデータ５１と、その端数のサイズ（＝規定のサイズ未満）のデータであってデータ５０からデータ５１を除いた残りのデータ３と、に分割する方法が挙げられる。
【０１３２】
或いは、データ５０が規定のサイズの整数倍である場合には、データ５０の終端部のデータのみを規定のサイズに切り取ってデータ３とし、残りの全体をデータ５１（規定のサイズの整数倍となる）としても良い。
【０１３３】
第１のレイヤ処理手段１０３は、第１のフレーム６１を受けると、該第１のフレーム６１のデータ５１を複数のデータ１，２に分割する。そして、分割した各データ１，２に対しては、代表識別情報１４に基づいて個別の識別情報１１を生成し、該識別情報１１を付加する。これにより、第２のフレーム６２、６３をそれぞれ生成する。なお、識別情報１１の内容は、代表識別情報１４と同一であっても良い。
【０１３４】
更に、第１のレイヤ処理手段１０３は、生成した第２のフレーム６２，６３を受信装置宛に送信する。
【０１３５】
また、第１のレイヤ処理手段１０３は、第３のフレーム６４を受けると、該第３のフレーム６４をそのまま受信装置宛に転送する。
【０１３６】
以上のような第２の実施形態によれば、第１のレイヤでは、データ５１を複数のデータ１、２に分割し、「データ送信先の通信処理装置がデータ１、２の各々に対して第２のレイヤにおいて行う所定の通信処理」に用いられる識別情報１１をデータ１、２毎に生成し、個々のデータ１、２と各データ１、２に対応して生成された識別情報１１とを含む第２のフレーム６２、６３を生成し、各第２のフレーム６２、６３を送信先の通信処理装置宛に送信するので、送信元において第２のレイヤから第１のレイヤへ受け渡すフレームの数を低減することができる。すなわち、第１のレイヤにおいて複数に分割されるデータ５１を第１のフレーム６１の形態でまとめて第２のレイヤから第１のレイヤへ受け渡すので、第４のフレーム６０のデータ５０を規定のサイズの多数のデータに分割して第２のレイヤから第１のレイヤへ受け渡す場合と比べて、第２のレイヤから第１のレイヤへ受け渡すフレームの個数を削減できる。よって、第２のレイヤにおける処理負荷を軽減することができる。しかも、送信元の第２のレイヤにおけるデータ５０の分割数を低減でき、その点でも該第２のレイヤにおける処理負荷を軽減することができる。
【０１３７】
また、第１のレイヤでは、各々の通常フレームへの通信処理、例えば識別情報の追加といった処理の回数が削減できる。すなわち、データ５１を分割することにより生成した個々のデータ１，２に対する処理が、条件判断などが不要な、共通の処理の繰り返しとなる。従って、第１のレイヤにおける処理負荷も軽減できる。
【０１３８】
第１のレイヤにおいて複数に分割されるデータ５１を含むフレーム（第１のフレーム６１）であるか、分割されないデータ３を含むフレーム（第３のフレーム６４）であるかの判別、すなわちフレームの種類の判別は、第１の実施形態で説明したのと同様の方法によって行うことが可能である。
【０１３９】
＜第２の実施形態の変形例＞
第２の実施形態においても、上記の第１の実施形態の変形例と同様に、識別情報に第１の識別情報と第２の識別情報とを含ませても良い。
【０１４０】
本変形例の場合も、通信処理装置１００の構成は、上記の第１の実施形態（図１、図３）と同様である。
【０１４１】
図６は本変形例に係る通信処理方法の動作を示す図である。
【０１４２】
この場合、データ５１を分割することにより生成されるデータ１，２に対する第１のレイヤでの通信処理が共通なので（第１の識別情報が共通の識別情報１１）、第１のフレーム６１には第１の識別情報を含ませる必要がない。そして、データ１，２の何れかの第２の識別情報（識別情報２１又は２２）のみを代表識別情報として第１のフレーム６１に使用することができる。第１のレイヤでは、データ５１を分割することにより生成されるデータ１，２に対しては、予め第１の識別情報が判明しているので、それを識別情報１１として追加し、さらに必要に応じて、代表識別情報に基づいて、個別データの第２の識別情報を生成して追加し、第２のフレームを構成することもできる。
【０１４３】
〔第３の実施形態〕
次に、第３の実施形態を説明する。
【０１４４】
本実施形態では、背景技術の項において詳述したようなＷ−ＣＤＭＡの規定に従ったダウンリンク・データ転送について説明する。
【０１４５】
図７は本実施形態に係る通信処理装置１００の構成を示すブロック図である。
【０１４６】
本実施形態の場合、制御部１０１は、図１３に示す各レイヤにおける通信処理を行うように構成されている。
【０１４７】
すなわち、制御部１０１は、ＰＨＹ（物理）レイヤ２０１における通信処理を行うＰＨＹ（物理）レイヤ処理手段３０１と、第１のレイヤとしてのＭＡＣレイヤ２０２における通信処理を行うＭＡＣレイヤ処理手段（第１のレイヤ処理手段）３０２と、第２のレイヤとしてのＲＬＣレイヤ２０３における通信処理を行うＲＬＣレイヤ処理手段（第２のレイヤ処理手段）３０３と、第３のレイヤとしてのＰＤＣＰレイヤ２０４における通信処理を行うＰＤＣＰレイヤ処理手段（第３のレイヤ処理手段）３０４と、アプリケーション・レイヤ２０５における通信処理を行うアプリケーション・レイヤ処理手段３０５と、ＲＲＣレイヤ２０６における通信処理を行うＲＲＣレイヤ処理手段３０６と、ＮＡＳレイヤ２０７における通信処理を行うＮＡＳレイヤ処理手段２０８と、を備えて構成されている。
【０１４８】
なお、本実施形態の場合も、制御部１０１のハードウェア構成は、上記の第１の実施形態（図３）と同様である。
【０１４９】
本実施形態では、以下に説明するように、主としてＭＡＣレイヤ（第１のレイヤ）２０２からＲＬＣレイヤ（第２のレイヤ）２０３へのデータ転送処理を改善する。すなわち、ダウンリンク・データ転送におけるＲＬＣレイヤ２０３の処理削減を実現する。
【０１５０】
例えば、インターネット上のＷＥＢサイトを閲覧したり、大容量のファイルをダウンロードしたり、或いは、アップロードを実施するようなノンリアルタイム（ｎｏｎ−ｒｅａｌ  ｔｉｍｅ）サービスを使用する場合、セッション（Ｓｅｓｓｉｏｎ）確立時のチャネル・コンフィグレーションの際、ＲＬＣのモードとしては、データの送達確認が行われるＲＬＣ  ＡＭ（ＡＭ：Ａｃｋｎｏｗｌｅｄｇｅ  Ｍｏｄｅ）がネットワークから設定される。よって、本実施形態では、ＲＬＣ  ＡＭを使用した場合の動作を説明する。
【０１５１】
ＲＬＣ  ＡＭの場合、上位２バイトのＲＬＣ  ＡＭ  ヘッダ（図１５参照）は、Ｄ／Ｃ、ＳＮ（シーケンス・ナンバー）、送達確認を要求するＰ（ポーリングビット）、及び、後続データとしてレングス・インジケータが存在するか否かを識別するＨＥ（ヘッダ・エクステンション・タイプ）で構成される（図１６参照）。
【０１５２】
これらＤ／Ｃ、ＳＮ、Ｐ、及びＨＥは、第２のレイヤとしてのＲＬＣレイヤ２０３において、第２のフレームとしてのＲＬＣ  ＰＤＵに含まれるデータ（通信経路が一つしかない、典型的なパターンの場合、第１のフレームとしてのＭＡＣ−ｄ  ＰＤＵに含まれるデータに等しい）対して行われる所定の通信処理に用いられる識別情報である。
【０１５３】
ここで、ＲＬＣ  ＡＭヘッダ内の各情報は、各ＲＬＣ  ＰＤＵに共通の値が設定されることが多い第１の識別情報と、ＲＬＣ  ＰＤＵ毎に異なる第２の識別情報に分類することができる。例えば、Ｄ／Ｃ、Ｐ、及びＨＥは第１の識別情報に、ＳＮは第２の識別情報に分類することができる。
【０１５４】
本実施形態の場合、ＭＡＣレイヤ処理手段３０２は、ＭＡＣ−ｄ  ＰＤＵ（第１のフレーム）を送受信部１０２及びＰＨＹレイヤ処理手段３０１を介してネットワークより受信する。
【０１５５】
ＭＡＣレイヤ処理手段３０２は、ＭＡＣ−ｄ  ＰＤＵを受信すると、各ＭＡＣ−ｄ  ＰＤＵの先頭２バイト（ＲＬＣ  ＡＭ  ヘッダに相当する）を構成する識別情報（Ｄ／Ｃ、ＳＮ、Ｐ、及びＨＥ）の内容に応じて、複数のＭＡＣ−ｄ  ＰＤＵのうち、それに含まれるデータを相互に結合するＭＡＣ−ｄ  ＰＤＵを判別する。
【０１５６】
ここで、ＲＬＣレイヤ２０３では、受信したフレームにＤ／Ｃ＝１が設定され、且つ、Ｐ＝１が設定されているという「第１の条件」を満たす場合には、ネットワークに対し送達確認を送信する。
【０１５７】
また、受信したフレームにＤ／Ｃ＝１が設定され、且つ、ＨＥ＝０１が設定されている（すなわちフレームがＬＩを含む）という「第２の条件」を満たす場合には、ＲＬＣレイヤ２０３では、当該フレームのペイロード部がＲＬＣ  ＳＤＵの最後のセグメントを構成するデータであると判断（認識）する。
【０１５８】
ＭＡＣレイヤ処理手段３０２は、これら第１及び第２の条件のうちの少なくとも何れか一方を満たすフレームに対しては、「ＲＬＣレイヤ２０３における所定のプロトコル処理が必要である」と判定する。
【０１５９】
ＭＡＣレイヤ処理手段３０２は、逆に、第１及び第２の条件の何れも満たさないフレームに対しては、「ＲＬＣレイヤ２０３における所定のプロトコル処理が不要である」と判定する。すなわち、Ｄ／Ｃ＝１が設定されているフレームであっても、ＨＥ＝００（ＨＥ＝０１でない。すなわち、ＬＩが存在しない）、且つ、Ｐ＝０（送達確認が不要）が設定されているフレームに対しては、「ＲＬＣレイヤ２０３における所定のプロトコル処理が不要である」と判定する。
【０１６０】
なお、Ｄ／Ｃ＝１が設定されているフレーム（すなわちデータＰＤＵ）のデータは、ＲＬＣレイヤ２０３からＰＤＣＰレイヤ２０４を介してアプリケーション・レイヤ２０５へと受け渡される。
【０１６１】
対して、Ｄ／Ｃ＝０が設定されているフレーム（すなわちコントロールＰＤＵ）は、ＲＬＣレイヤ２０３からＲＲＣレイヤ２０６及びＮＡＳレイヤ２０７を介してアプリケーション・レイヤ２０５へと受け渡される。
【０１６２】
本実施形態では、以下、データＰＤＵ（Ｄ／Ｃ＝１）の流れについてのみ説明し、コントロールＰＤＵ（Ｄ／Ｃ＝０）の流れについては説明を省略する。
【０１６３】
図１８にて説明したように、ＲＬＣ  ＰＤＵのサイズが４２バイト、ＲＬＣ  ＳＤＵのサイズが１５００バイトの環境下においては、１個のＲＬＣ  ＳＤＵから３８個のＲＬＣ  ＰＤＵが生成される。
【０１６４】
また、一般的には、これら３８個のＲＬＣ  ＰＤＵのうち、先頭セグメント（Ｎｏ．１）を含むＲＬＣ  ＰＤＵから３７個目のセグメント（Ｎｏ．３７）を含むＲＬＣ  ＰＤＵまでについては、ぞれぞれＰ＝０、ＨＥ＝００が設定され、最終セグメント（Ｎｏ．３８）を含むＲＬＣ  ＰＤＵについてのみ、Ｐ＝１、ＨＥ＝０１が設定されている。
【０１６５】
つまり、実環境下においては殆どのＲＬＣ  ＰＤＵは所定のプロトコル処理が不要なＲＬＣ  ＰＤＵである。
【０１６６】
なお、ＳＮがどの値であるＲＬＣ  ＰＤＵにＰを付加するかは、ネットワークのコンフィグレーションに応じて異なる。図１８には、ＲＬＣ  ＳＤＵの最終セグメントを含むＲＬＣ  ＰＤＵにＰが付加されるケースを図示したが、ネットワークからの設定によっては、Ｐが付加されないＲＬＣ  ＰＤＵを受信した場合でも、ＳＮ欠損を検出したときに、送達確認を送信することがある。
【０１６７】
本実施形態では、ＲＬＣ  ＳＤＵから複数のＰＤＵを生成した際に、実運用環境下においては、殆どのＲＬＣ  ＰＤＵはＲＬＣレイヤ２０３における所定のプロトコル処理が不要なＰＤＵとなるという特性を利用する。
【０１６８】
すなわち、ＭＡＣレイヤ２０２においては、ＲＬＣレイヤ２０３における所定のプロトコル処理が不要であり、且つ、連続したＳＮを持つＲＬＣ  ＰＤＵについては、個々のＲＬＣ  ＰＤＵの形でＲＬＣレイヤ２０３にデータを受け渡すのではなく、それらを結合したフレームの形で転送する。これにより、あたかもＲＬＣレイヤ２０３において処理しなければならないＲＬＣ  ＰＤＵの個数を減らすかのような動作とする。
【０１６９】
ＭＡＣレイヤ２０２においては、上記所定のプロトコル処理が不要であり、且つ、ＳＮが連続したＲＬＣ  ＰＤＵについては、それらのペイロード部を結合することにより生成されるフレームを、あたかもサイズが大きい１つのＲＬＣ  ＰＤＵであるかのように扱って、ＲＬＣレイヤ２０３へ転送する。
【０１７０】
ＲＬＣレイヤ２０３においては、例えば、規定のサイズ（具体的には、例えば、４２バイト）とは異なるフレームをＭＡＣレイヤ２０２から受けた場合、ＳＮが連続した複数のＲＬＣ  ＰＤＵのペイロード部が結合されて転送されてきたと認識し、処理する。
【０１７１】
なお、この規定のサイズは、セッション確立時にネットワークから通知され、制御部１０１のＲＡＭ１１３に記憶保持される。
【０１７２】
図８は、本実施形態に係る通信処理方法によるダウンリンク・データ転送の動作を示す模式図である。すなわち、図８は、ＲＬＣ  ＰＤＵのサイズ＝４２バイト、ＲＬＣ  ＳＤＵのサイズ＝１５００バイトの環境下において、ＭＡＣレイヤ処理手段３０２が（ＭＡＣレイヤ２０２が）ＭＡＣ−ｄ  ＰＤＵを受信した後の動作を示す。なお、図８に示すのは、１個のＲＬＣ  ＳＤＵに相当するデータを転送する動作である。
【０１７３】
本実施形態の場合、図８に示すように、ＭＡＣレイヤ２０２においては、ＰＨＹレイヤ２０１から受信した複数のＭＡＣ−ｄ  ＰＤＵ（＝ＲＬＣ  ＰＤＵ）のうち、ＲＬＣレイヤ２０３における所定のプロトコル処理が不要であり、且つ、ＳＮ（シーケンス・ナンバー）が連続するＭＡＣ−ｄ  ＰＤＵを相互に結合する。
【０１７４】
これにより、ＲＬＣ  ＰＤＵよりもサイズが大きいフレームＦ１を生成する。
【０１７５】
フレームＦ１の生成に際しては、先頭のＭＡＣ−ｄ  ＰＤＵのＲＬＣ  ヘッダ以外は、ＲＬＣ  ヘッダを省いてＲＬＣ  ペイロード部のみを相互に結合する。
【０１７６】
そして、生成したフレームＦ１を、ＭＡＣレイヤ２０２からＲＬＣレイヤ２０３へ受け渡す。
【０１７７】
また、ＲＬＣレイヤ２０３における所定のプロトコル処理が必要なＲＬＣ  ＰＤＵについては、結合せずにそのままの形でフレームＦ２としてＭＡＣレイヤ２０２からＲＬＣレイヤ２０３へ転送する。
【０１７８】
具体的には、本実施形態の場合、図８に示すように、例えば、ＳＮ＝０のＲＬＣ  ＰＤＵと、ＳＮ＝１〜３６の各ＲＬＣ  ＰＤＵからヘッダを省いた残りであるペイロード部と、をＳＮの順に並べて相互に結合することによりフレームＦ１を生成し、該フレームＦ１をＭＡＣレイヤ２０２からＲＬＣレイヤ２０３へ受け渡す。
【０１７９】
すなわち、ＳＮ＝０〜ＳＮ＝３６の合計３７個のＲＬＣ  ＰＤＵを、不要なヘッダを省略して結合することによりフレームＦ１を生成し、受け渡す。
【０１８０】
なお、本実施形態では、フレームＦ１から先頭のＲＬＣ  ＰＤＵのＲＬＣヘッダを除いたものが、結合データである。また、フレームＦ１の先頭のＲＬＣ  ＰＤＵのＲＬＣヘッダが、結合データ用識別情報である。
【０１８１】
また、ＳＮ＝３７のＲＬＣ  ＰＤＵは、Ｐ＝１であり、且つ、ＨＥ＝０１であるため、ＲＬＣレイヤ２０３における所定のプロトコル処理が必要なＰＤＵである。よって、結合せずにそのままの形でフレームＦ２としてＭＡＣレイヤ２０２からＲＬＣレイヤ２０３へ受け渡す。
【０１８２】
このように、ＭＡＣレイヤ２０２は、１個のＲＬＣ  ＳＤＵに相当するデータをＲＬＣレイヤ２０３へ受け渡す場合には、図８に示すように、２つのフレームＦ１、Ｆ２をＲＬＣレイヤ２０３に受け渡す。つまり、ＭＡＣレイヤ２０２は、あたかも２個のＲＬＣ  ＰＤＵをＲＬＣレイヤ２０３に受け渡すかのような動作を行う。
【０１８３】
次に、ＲＬＣレイヤ２０３においては、例えば、受け渡されたフレームのサイズが規定のサイズ（例えば、４２バイト）であるか否かを判別する。規定のサイズとは異なるデータ量のフレームを受けた場合、該フレームをフレームＦ１であると判別する。
【０１８４】
ここで、ＲＬＣレイヤ２０３においては、規定のサイズよりも大きいサイズのフレームを受けた場合に、フレームＦ１を受けたと判別するようにしても良いのは勿論であるが、規定のサイズよりも小さいフレームの受け渡しは実際的には発生しないため、受け渡されたフレームがフレームＦ１かフレームＦ２であるかを認識するためには、規定のサイズであるか否かの判別で良い。
【０１８５】
ＲＬＣレイヤ２０３は、規定のサイズとは異なるフレームＦ１を受けると、該フレームＦ１を、ＳＮが連続した複数のＲＬＣ  ＰＤＵのペイロード部がＳＮの順に結合されてなるフレームであると認識する。
【０１８６】
また、ＲＬＣレイヤ２０３において、規定のサイズのデータ量のフレーム、すなわちフレームＦ２を受信すると、ＲＬＣレイヤ２０３では、該フレームＦ２を、該ＲＬＣレイヤ２０３における所定のプロトコル処理が必要なＲＬＣ  ＰＤＵであると認識する。
【０１８７】
ＲＬＣレイヤ２０３では、フレームＦ２を構成するＲＬＣ  ＰＤＵについては、以下のようにプロトコル処理を行う。
【０１８８】
すなわち、フレームＦ２を構成するＲＬＣ  ＰＤＵには、Ｐ＝１が設定されているので、ＲＬＣレイヤ２０３は、ネットワークに対し送達確認を送信する。
【０１８９】
また、フレームＦ２を構成するＲＬＣ  ＰＤＵには、ＬＩが含まれている（ＨＥ＝０１）ので、ＲＬＣレイヤ２０３は、該ＲＬＣ  ＰＤＵをＲＬＣ  ＳＤＵの最後のセグメントを構成するデータであると認識する。
【０１９０】
一方、フレームＦ１は、ＳＮが連続した複数のＲＬＣ  ＰＤＵを結合してなるフレームであり、ヘッダはＳＮ＝０の先頭のセグメントのヘッダのみが含まれている。
【０１９１】
このため、ＲＬＣレイヤ２０３では、フレームＦ１から先頭のヘッダを除くとともに、該フレームＦ１の最後尾にフレームＦ２のペイロード部を結合することにより、ＲＬＣ  ＳＤＵを生成することができる。
【０１９２】
ＲＬＣレイヤ２０３は、このように生成したＲＬＣ  ＳＤＵをＰＤＣＰレイヤ２０４へ受け渡す。
【０１９３】
次に、図９は、第３の本実施形態の場合において、２個のＲＬＣ  ＳＤＵに相当するデータを転送する動作を示す模式図である。
【０１９４】
この場合、図９に示すように、ＳＮ＝０のＲＬＣ  ＰＤＵと、ＳＮ＝１〜３６の各ＲＬＣ  ＰＤＵからヘッダを省いた残りであるペイロード部と、を結合することにより、図８の場合と同様にフレームＦ１を生成し、該フレームＦ１をＭＡＣレイヤ２０２からＲＬＣレイヤ２０３へ転送する。
【０１９５】
また、ＳＮ＝３７のＲＬＣ  ＰＤＵは、ＲＬＣレイヤ２０３における処理のプロトコル処理が必要なＰＤＵ（Ｐ＝１、ＬＩ有）であるので、図８の場合と同様に、結合せずにそのままの形でフレームＦ２としてＭＡＣレイヤ２０２からＲＬＣレイヤ２０３へ転送する。
【０１９６】
また、ＳＮ＝３８のＲＬＣ  ＰＤＵと、ＳＮ＝３９〜７４の各ＲＬＣ  ＰＤＵからヘッダを省いた残りであるペイロード部と、を結合することにより、フレームＦ３を生成し、該フレームＦ３をＭＡＣレイヤ２０２からＲＬＣレイヤ２０３へ転送する。
【０１９７】
また、ＳＮ＝７５のＲＬＣ  ＰＤＵは、プロトコル処理が必要なＰＤＵ（Ｐ＝１、ＬＩ有）であるので、結合せずにそのままの形でフレームＦ４としてＭＡＣレイヤ２０２からＲＬＣレイヤ２０３へ転送する。
【０１９８】
このように、ＭＡＣレイヤ２０２は、２個のＲＬＣ  ＳＤＵに相当するデータを転送する場合には、図９に示すように、４つのフレームＦ１、Ｆ２、Ｆ３、Ｆ４をＲＬＣレイヤ２０３に転送する。つまり、ＭＡＣレイヤ２０２は、あたかも４個のＲＬＣ  ＰＤＵをＲＬＣレイヤ２０３に送信するかのような動作を行う。
【０１９９】
次に、ＲＬＣレイヤ２０３においては、規定のサイズとは異なるデータ量のフレーム、すなわちフレームＦ１、Ｆ３を受信すると、これらフレームＦ１、Ｆ３を、ＳＮが連続した複数のＲＬＣ  ＰＤＵ（のペイロード部）が結合されてなるフレームであると認識する。
【０２００】
また、ＲＬＣレイヤ２０３では、規定のサイズのデータ量のフレーム、すなわちフレームＦ２、Ｆ４を受信すると、該フレームＦ２、Ｆ４に対して、従来通りのＲＬＣ  ＰＤＵに対する受信処理を行う。従って、結果的に所定のプロトコル処理が発生する。
【０２０１】
ＲＬＣレイヤ２０３では、フレームＦ２、Ｆ４を構成するＲＬＣ  ＰＤＵについては、以下のようにプロトコル処理を行う。
【０２０２】
すなわち、フレームＦ２、Ｆ４を構成するＲＬＣ  ＰＤＵには、Ｐ＝１が設定されているので、ＲＬＣレイヤ２０３は、ネットワークに対し送達確認をそれぞれ送信する。
【０２０３】
また、フレームＦ２、Ｆ４を構成するＲＬＣ  ＰＤＵには、ＬＩが含まれている（ＨＥ＝０１）ので、ＲＬＣレイヤ２０３は、該ＲＬＣ  ＰＤＵをＲＬＣ  ＳＤＵの最後のセグメントを構成するデータであると認識する。
【０２０４】
一方、フレームＦ１は、ＳＮが連続した複数のＲＬＣ  ＰＤＵを結合してなるフレームであり、ヘッダはＳＮ＝０の先頭のセグメントのヘッダのみが含まれている。
【０２０５】
同様に、フレームＦ３は、ＳＮが連続した複数のＲＬＣ  ＰＤＵを結合してなるフレームであり、ヘッダはＳＮ＝３８の先頭のセグメントのヘッダのみが含まれている。
【０２０６】
このため、ＲＬＣレイヤ２０３では、フレームＦ１から先頭のヘッダを除くとともに、該フレームＦ１の最後尾にフレームＦ２のペイロード部を結合することにより、１つ目のＲＬＣ  ＳＤＵ（図９に示すＲＬＣ  ＳＤＵ（Ｎｏ．１））を生成することができる。
【０２０７】
同様に、フレームＦ３から先頭のヘッダを除くとともに、該フレームＦ３の最後尾にフレームＦ４のペイロード部を結合することにより、２つ目のＲＬＣ  ＳＤＵ（図９に示すＲＬＣ  ＳＤＵ（Ｎｏ．２））を生成することができる。
【０２０８】
よって、図８の動作の場合と同様に、従来と比べてＲＬＣレイヤ２０３の処理負担を軽減することができる。
【０２０９】
ここで、ＲＬＣレイヤ２０３においては、このようにＲＬＣ  ＳＤＵ（Ｎｏ．１）、ＲＬＣ  ＳＤＵ（Ｎｏ．２）をそれぞれ生成するに際し、各フレームＦ１〜Ｆ４のヘッダに含まれるＳＮの値とＬＩの値に基づき、以下に説明するようにして、相互に結合するフレームを判別する。
【０２１０】
先ず、フレームＦ１のＳＮの値は「０」であることから、該フレームＦ１内の結合されたペイロード部（結合データ）は、ＲＬＣ  ＳＤＵの先頭を構成することが分かる。
【０２１１】
また、フレームＦ３のＳＮの値は「３８」であり、ＳＮの値がフレームＦ２の続き番号であることが分かる。しかし、フレームＦ３には、ＬＩが含まれていないため、フレームＦ３は、ＳＤＵの先頭を構成することが分かる。
【０２１２】
また、フレームＦ２、Ｆ４には、ＳＤＵの終端である旨を示すＬ１が含まれていることから、フレームＦ２、Ｆ４のペイロード部をフレームＦ１、Ｆ３のペイロード部の終端に結合させれば良いことが分かる。
【０２１３】
このうちフレームＦ２のＳＮの値は「３７」であるため、フレームＦ２のペイロード部はフレームＦ３ではなく、フレームＦ１内のペイロード部の終端に結合させれば良いと分かる。
【０２１４】
また、フレームＦ４のＳＮの値は「７５」であるため、フレームＦ４のペイロード部は、フレームＦ３のペイロード部の終端に結合させれば良いと分かる。
【０２１５】
フレームＦ２のペイロード部をフレームＦ１内のペイロード部の終端に結合させる際、並びに、フレームＦ４のペイロード部をフレームＦ３のペイロード部の終端に結合させる際には、各々のＬＩにより示されているデータの終端位置に基づいて、パディングを削除する。
【０２１６】
なお、ＬＩの値が、パディングがない旨を示す［０００００００］である場合、このＲＬＣ  ＰＤＵは、フレームの先頭に結合される。この場合、パディングがない旨を示すＬＩを有するＲＬＣ  ＰＤＵの前のＲＬＣ  ＰＤＵのペイロード部がＳＤＵの終端を構成する。
【０２１７】
以上のような第３の実施形態によれば、ＭＡＣレイヤ２０２では、ペイロード部を相互に結合するＲＬＣ  ＰＤＵを各ＲＬＣ  ＰＤＵのヘッダに含まれる識別情報の内容に応じて判別し、該判別したＲＬＣ  ＰＤＵのペイロード部を相互に結合し、該結合したペイロード部と、先頭のＲＬＣ  ＰＤＵのＲＬＣヘッダ（識別情報を含む）と、を含むフレームＦ１を生成し、該フレームＦ１をＭＡＣレイヤ２０２からＲＬＣレイヤ２０３へ受け渡す。よって、ＭＡＣレイヤ２０２からＲＬＣレイヤ２０３へ受け渡すフレームの数を低減することができる。よって、ＲＬＣレイヤ２０３における処理負荷を軽減することができる。しかも、ＲＬＣレイヤ２０３において結合すべきデータ数を低減でき、その点でもＲＬＣレイヤ２０３における処理負荷を軽減することができる。
【０２１８】
すなわち、ＳＮ＝０〜３７の合計３８個のＲＬＣ  ＰＤＵの各々からヘッダを除いた上で、それらＰＤＵのペイロード部を結合することによりＲＬＣ  ＳＤＵを生成する必要がある従来の動作と比べて、ＲＬＣレイヤ２０３の処理負荷を軽減できる。
【０２１９】
また、ＲＬＣレイヤ２０３は、再送制御をするので、再送制御が終わるまでは、ＭＡＣレイヤ２０２から受け渡されたフレームのうち、ＰＤＣＰレイヤ２０４へ受け渡しが終わっていないフレームは全て保持しておく必要がある。このため、フレーム（ＲＬＣ  ＰＤＵ）の数が多ければ、管理のために多大な処理負荷を要するという事情がある。しかし、本実施形態では、管理すべきフレームの数が大幅に低減されるので、フレーム数の増加に起因する諸問題の発生を防止することができる。
【０２２０】
なお、上記の第３の実施形態では、ＲＬＣ  ＡＭを使用した場合の動作を説明したが、第３の実施形態は、データの送達確認が行われないＲＬＣ  ＵＭ（ＵＭ：Ｕｎａｃｋｎｏｗｌｅｄｇｅ  Ｍｏｄｅ：非確認モード）が設定された場合も同様に使用することが可能である。
【０２２１】
ＲＬＣ  ＵＭの場合、ＲＬＣ  ヘッダが１バイトであり、ＨＥ及びＤ／Ｃは何れも使用しないため、これらの識別情報の判別は行う必要がない。ＲＬＣ  ＵＭの場合、Ｅ（エクステンション・ビット）＝１であればＬＩも有るので、Ｅ＝０であり、且つ、ＳＮが連続するＲＬＣ  ＰＤＵを相互に結合することにより、フレームＦ１、Ｆ３を生成する。
【０２２２】
〔第４の実施形態〕
次に、第４の実施形態を説明する。
【０２２３】
図１０は、本実施形態に係る通信処理方法によるダウンリンク・データ転送の動作を示す模式図である。すなわち、図１０は、ＲＬＣ  ＰＤＵのサイズ＝４２バイト、ＲＬＣ  ＳＤＵのサイズ＝１５００バイトの環境下において、ＭＡＣレイヤ処理手段３０２が（ＭＡＣレイヤ２０２が）ＭＡＣ−ｄ  ＰＤＵを受信した後の動作を示す。なお、図１０に示すのは、２個のＲＬＣ  ＳＤＵに相当するデータを転送する動作である。
【０２２４】
第４の実施形態に係る通信処理装置の構成は、上記の第３の実施形態（図７）と同様である。
【０２２５】
第４の実施形態の場合、図１０のフレームＦ６のように、Ｐ＝１であるか、又は、ＨＥ＝０１（ＬＩ有）のＲＬＣ  ＰＤＵ（例えば、ＳＮ＝３７のＲＬＣ  ＰＤＵ）を、フレームの先頭のセグメントに結合することができる。
【０２２６】
これにより、第４の実施形態では、上記の第３の実施形態の場合よりも、更に処理の効率化を図ることができる。
【０２２７】
本実施形態の場合、具体的には、例えば、図１０に示すように、２つのＲＬＣ  ＳＤＵに相当するデータを、３つのフレームＦ５、Ｆ６、Ｆ７に分けて、ＭＡＣレイヤ２０２からＲＬＣレイヤ２０３へと受け渡すことができる。
【０２２８】
このうちフレームＦ５は、ＳＮ＝０〜３６の３７個分のＲＬＣ  ＰＤＵのペイロード部と、ＲＬＣヘッダと、からなる。
【０２２９】
また、フレームＦ６は、ＳＮ＝３７〜７４の３８個分のＲＬＣ  ＰＤＵのペイロード部と、ＳＮ＝３７のＲＬＣ  ＰＤＵのＲＬＣヘッダと、からなる。
【０２３０】
フレームＦ６におけるＳＮ＝３７のＲＬＣ  ＰＤＵは、ＲＬＣレイヤ２０３における所定のプロトコル処理が必要なＰＤＵであるため、そのペイロード部は結合データを構成しない。しかし、フレームＦ６は、ＳＮ＝３８以降のＲＬＣ  ＰＤＵのペイロード部の結合データを含む。
【０２３１】
また、フレームＦ７は、ＳＮ＝７５のＲＬＣ  ＰＤＵからなる。
【０２３２】
ＲＬＣレイヤ２０３では、ＭＡＣレイヤ２０２からフレームＦ５、Ｆ６、Ｆ７を受信すると、フレームＦ５の各ペイロード部と、フレームＦ６の先頭セグメント（ＳＮ＝３７）のペイロード部と、を結合することにより１つ目のＲＬＣ  ＳＤＵ（図１０のＲＬＣ  ＳＤＵ（Ｎｏ．１））を生成する。また、フレームＦ６の２番目以降の各セグメント（ＳＮ＝３８〜７４）を構成する各ペイロード部と、フレームＦ７のペイロード部と、を結合することにより２つ目のＲＬＣ  ＳＤＵ（図１０のＲＬＣ  ＳＤＵ（Ｎｏ．１））を生成する。
【０２３３】
そして、これら生成した２つのＲＬＣ  ＳＤＵをＲＬＣレイヤ２０３からＰＤＣＰレイヤ２０４へと受け渡す。
【０２３４】
以上のような第４の実施形態によれば、ＲＬＣレイヤ２０３における所定のプロトコル処理が必要なＲＬＣ  ＰＤＵのペイロード部は結合データを構成することはできない。しかし、結合データを構成することができないペイロード部であっても、予め取り決めを行っておくことにより、結合データを構成することができる。例えば、フレームの先頭を構成するＲＬＣ  ＰＤＵに対しては、所定のプロトコル処理を適用するように、予め取り決めておくことによって、結合データを構成することが可能となる。そして、その結合データはフレームの先頭に結合することができる。従って、上記の第３の実施形態よりもフレームの数を低減できる。
【０２３５】
なお、上記の第４の実施形態では、フレームＦ６が結合データを含む例を説明したが、フレームＦ６は、（例えばＳＮ＝３７の）ＲＬＣ  ＰＤＵの他には、１つのＲＬＣ  ＰＤＵのペイロード部のみを含んでいても良い。
【０２３６】
〔第５の実施形態〕
第５の実施形態では、背景技術の項において詳述したようなＷ−ＣＤＭＡの規定に従ったアップリンク・データ転送について説明する。
【０２３７】
図１１は、本実施形態に係る通信処理方法におけるアップリンク・データ転送の動作を示す模式図である。すなわち、図１１は、ＲＬＣ  ＰＤＵのサイズ＝４２バイト、ＲＬＣ  ＳＤＵのサイズ＝１５００バイトの環境下において、ＰＤＣＰレイヤ２０４からＲＬＣレイヤ２０３へのデータ転送と、ＲＬＣレイヤ２０３からＭＡＣレイヤ２０２へのデータ転送の動作を示す。なお、図１１に示すのは、１個のＲＬＣ  ＳＤＵのデータを転送する動作である。
【０２３８】
この場合、図１１に示すように、先ず、ＰＤＣＰレイヤ２０４からＲＬＣレイヤ２０３へとＲＬＣ  ＳＤＵを受け渡す。
【０２３９】
ＲＬＣレイヤ２０３では、ＲＬＣ  ＳＤＵを受けると、このＲＬＣ  ＳＤＵの先頭から、ＲＬＣペイロード部の規定のサイズ（＝４０バイト）の整数倍で、且つ最大の大きさのデータ（整数倍データ）を切り取る。
【０２４０】
言い換えると、ＲＬＣ  ＳＤＵを、ＲＬＣペイロード部の規定のサイズの整数倍の整数倍データ（第１のデータ）と、規定サイズ未満の端数データ（第３のデータ）と、に分割する。
【０２４１】
ＲＬＣレイヤ２０３では、続いて、整数倍データと、端数データのそれぞれに対し、ＲＬＣヘッダを付加し、それぞれフレームＦ８，９を生成する。
【０２４２】
すなわち、整数倍データには、ＳＮ＝０と設定したＲＬＣヘッダを付加することにより、フレームＦ８とする。
【０２４３】
なお、ＲＬＣペイロード部の規定のサイズの整数倍のデータは、該整数で等分割することにより、プロトコル処理が不要でＳＮが連続したＲＬＣ  ＰＤＵの各ペイロード部を構成する。
【０２４４】
このため、フレームＦ８は、プロトコル処理が不要でＳＮが連続したＲＬＣ  ＰＤＵを、先頭のＲＬＣ  ＰＤＵにのみＲＬＣ  ヘッダを付加し、その他のＲＬＣ  ＰＤＵにはＲＬＣ  ヘッダを省略した形で、各々のＲＬＣ  ペイロード部を結合したものであると言い換えることができる。
【０２４５】
また、ＲＬＣ  ＳＤＵから切り取ることができた整数倍データの大きさが、規定のサイズの何倍であるかに応じて、端数データに付加するＲＬＣヘッダのＳＮの値を設定する。例えば、整数倍データの大きさが、規定サイズの３７倍である場合には、ＳＮ＝３７（３８番目）のＳＮ値とする。
【０２４６】
端数データには、終端にパディングを付加することにより、合計で規定のサイズとなるように調節する。
【０２４７】
端数データに付加するＲＬＣヘッダは、上記のように設定したＳＮ値とする他、ＨＥ＝０１とし、ＲＬＣ  ＳＤＵの終端である旨のＬＩを付加し、Ｐ＝１とする。また、ＬＩの値は、データの終端位置を示す値に設定する。これにより、フレームＦ９を生成する。
【０２４８】
続いて、ＲＬＣレイヤ２０３は、このように生成したフレームＦ８，Ｆ９をＭＡＣレイヤ２０２へ受け渡す。
【０２４９】
ＲＬＣレイヤ２０３は、１個のＲＬＣ  ＳＤＵに相当するデータを転送する場合には、図１１に示すように、あたかも２個のＲＬＣ  ＰＤＵをＭＡＣレイヤ２０２へ受け渡すかのような動作を行う。
【０２５０】
次に、ＭＡＣレイヤ２０２においては、規定のサイズとは異なるデータ量のフレーム、すなわちフレームＦ８を受信すると、該フレームＦ８を、ＳＮが連続した複数のＲＬＣ  ＰＤＵ（のペイロード部）が結合されてなるフレームであると認識する。
【０２５１】
ＭＡＣレイヤ２０２では、フレームＦ８のペイロード部（ＲＬＣヘッダを除く部分）を、個々のＲＬＣ  ＰＤＵのペイロード部のサイズ（４０バイト）で先頭から等分に切り分けて複数のデータに分割し、これら各データに対し、ＲＬＣヘッダを生成及び付加することにより、ＲＬＣ  ＰＤＵを生成する。
【０２５２】
ここで、先頭のＲＬＣ  ＰＤＵについては、ＲＬＣレイヤ２０３から受け渡されたＲＬＣ  ヘッダ（ＳＮ＝０）をそのまま用い、２番目のＲＬＣ  ＰＤＵからは、先頭のＲＬＣ  ＰＤＵのヘッダに格納されているＳＮを１つずつインクリメントする形で、全てのＲＬＣ  ヘッダを生成する。
【０２５３】
そして、これら生成したＲＬＣ  ＰＤＵをネットワークへ転送する。
【０２５４】
また、ＭＡＣレイヤ２０２は、フレームＦ９については、１個のＲＬＣ  ＰＤＵであると認識し、そのままネットワークへ転送する。
【０２５５】
以上のような第５の実施形態によれば、ＭＡＣレイヤ２０２では、規定のサイズの整数倍のデータと、このデータの識別情報としてのＲＬＣヘッダと、を含むフレームＦ８のデータを規定のサイズの複数のデータに分割する。これら分割したデータの各々に対して、「データ送信先の第２のレイヤにおいて行う所定の通信処理」に用いられる識別情報としてのＲＬＣヘッダを、ＳＮ＝０のＲＬＣヘッダに基づいて生成する。そして、分割した個々のデータと、当該データに対応して生成されたＲＬＣヘッダと、を含むＲＬＣ  ＰＤＵを生成し、これらＲＬＣ  ＰＤＵをデータ送信先の通信処理装置宛に送信する。
【０２５６】
従って、ＲＬＣレイヤ２０３からＭＡＣレイヤ２０２へ受け渡すフレームの数を低減することができる。よって、ＲＬＣレイヤ２０３における処理負荷を軽減することができる。しかも、ＲＬＣレイヤにおけるデータの分割数を低減でき、その点でも該ＲＬＣレイヤにおける処理負荷を軽減することができる。
【０２５７】
以上のように、本実施形態においては、ＲＬＣレイヤ２０３からＭＡＣレイヤ２０２へ受け渡すフレームの数を削減できる。そのため、ＲＬＣが管理しなければならないＲＬＣ  ＰＤＵの個数を劇的に削減することができる。
【０２５８】
ところで、一般的に通信処理装置がＡＲＱ  （Ａｕｔｏｍａｔｉｃ  Ｒｅｐｅａｔ  Ｒｅｑｕｅｓｔ）機能を保有している場合、ＰＤＵの再送制御が必要となる。再送制御を行うためには、ＰＤＵを下位のレイヤに転送しても、その転送済みのＰＤＵを即座に削除することはできず、送信先の通信装置からの受信応答（ＡＣＫ）を受信して初めて削除することができる。このことは、本実施形態におけるＲＬＣレイヤ２０３についても同様である。具体的に説明すると、本実施形態では、ＲＬＣレイヤ２０３からＭＡＣレイヤ２０２へＰＤＵを転送した後も、送信先からのＡＣＫを受信するまでは、送信したＰＤＵを保持している必要がある。このように、ＰＤＵの送信後もＰＤＵの管理が必要となるため、ＰＤＵの個数を削減することができれば、ＰＤＵ管理の処理を削減することができる。従って、管理のために要するソフトウェア処理量を削減することが可能になる。
【０２５９】
〔第６の実施形態〕
図１２は、第６の実施形態に係る通信処理方法におけるアップリンク・データ転送の動作を示す模式図である。すなわち、図１２は、ＲＬＣ  ＰＤＵのサイズ＝４２バイト、ＲＬＣ  ＳＤＵのサイズ＝１５００バイトの環境下において、ＰＤＣＰレイヤ２０４からＲＬＣレイヤ２０３へのデータ転送と、ＲＬＣレイヤ２０３からＭＡＣレイヤ２０２へのデータ転送の動作を示す。なお、図１２に示すのは、２個のＲＬＣ  ＳＤＵに相当するデータを転送する動作である。
【０２６０】
本実施形態の場合、図１２に示すように、先ず、ＰＤＣＰレイヤ２０４からＲＬＣレイヤ２０３へと２個のＲＬＣ  ＳＤＵを受け渡す。
【０２６１】
ＲＬＣレイヤ２０３では、２個のＲＬＣ  ＳＤＵを受けると、このうち先に受けたＲＬＣ  ＰＤＵ（Ｎｏ．１）の先頭から、上記の第５の実施形態と同様に、規定のサイズ（＝４０バイト）の整数倍で、且つ最大の大きさのデータ（整数倍データ）を切り取る。
【０２６２】
すなわち、ＲＬＣ  ＳＤＵ（Ｎｏ．１）を、規定のサイズの整数倍の整数倍データ（第１のデータ）と、規定サイズ未満の端数データ（第３のデータ）と、に分割する。
【０２６３】
ＲＬＣレイヤ２０３では、続いて、整数倍データに対し、ＳＮ＝０のＲＬＣヘッダを付加し、フレームＦ１０を生成する。このフレームＦ１０は、上記の第５の実施形態のフレームＦ８に相当する。
【０２６４】
すなわち、フレームＦ１０は、プロトコル処理が不要でＳＮが連続したＲＬＣ  ＰＤＵを、先頭のＲＬＣ  ＰＤＵにのみＲＬＣ  ヘッダを付加し、その他のＲＬＣ  ＰＤＵにはＲＬＣ  ヘッダを省略した形で、各々のＲＬＣ  ペイロード部を結合したものであると言い換えることができる。
【０２６５】
また、端数データに対し、ＲＬＣヘッダを付加する。
【０２６６】
端数データに付加するＲＬＣヘッダは、上記の第５の実施形態と同様に設定したＳＮ値（例えば、ＳＮ＝３７）とする他、ＨＥ＝０１とし、ＲＬＣ  ＳＤＵの終端である旨のＬＩを付加し、さらにＰ＝１とする。また、ＬＩの値は、データの終端位置を示す値に設定する。
【０２６７】
更に、端数データの終端にパディングを付加することにより、端数データとパディングとの合計が規定のサイズとなるように調節する。
【０２６８】
一方、ＲＬＣ  ＳＤＵ（Ｎｏ．２）も、ＲＬＣ  ＳＤＵ（Ｎｏ．２）と同様に、整数倍データ（第１のデータ）と、端数データ（第３のデータ）と、に分割する。
【０２６９】
このうち整数倍データは、ＲＬＣ  ＳＤＵ（Ｎｏ．１）を元に生成した端数データ（ＲＬＣヘッダを有する）の終端に結合する。これにより、フレーム（第３のフレーム）Ｆ１１を生成する。
【０２７０】
このように、フレームＦ１１は、上記端数データの分割元のＲＬＣ  ＳＤＵ（Ｎｏ．１）とは別のＲＬＣ  ＳＤＵ（Ｎｏ．２）から分割された、整数倍データを含む。
【０２７１】
言い換えるとフレームＦ１１は、プロトコル処理が必要なＲＬＣ  ＰＤＵ（ＳＮ＝３７）のペイロード部にＲＬＣ  ヘッダを付加したものと、プロトコル処理が不要でＳＮが連続したＲＬＣ  ＰＤＵ（ＳＮ＝３８〜７４）におけるＲＬＣ  ヘッダを省略した各ペイロード部と、を結合したものである。
【０２７２】
また、ＲＬＣ  ＳＤＵ（Ｎｏ．２）を元に生成した端数データ、すなわちプロトコル処理が必要なＲＬＣ  ＰＤＵ（ＳＮ＝７５）のペイロード部には、ＲＬＣ  ヘッダを付加するとともに、その終端にパディングを付加する。これにより、端数データとパディングとの合計を規定のサイズとし、ＲＬＣヘッダ、端数データ、及びパディングからなるフレームＦ１２を生成する。
【０２７３】
そして、これら生成したフレームＦ１０、Ｆ１１、Ｆ１２をＲＬＣレイヤ２０３からＭＡＣレイヤ２０２へ受け渡す。
【０２７４】
このように、ＲＬＣレイヤ２０３は、２個のＲＬＣ  ＳＤＵに相当するデータをＭＡＣレイヤ２０２へ受け渡す場合には、図１２に示すように、あたかも３個のＲＬＣ  ＰＤＵをＲＬＣレイヤ２０３に受け渡すかのような動作を行う。
【０２７５】
次に、ＭＡＣレイヤ２０２においては、規定のサイズ（４２バイト）とは異なるデータ量のフレーム、すなわちフレームＦ１０、Ｆ１１を受けると、該フレームＦ１０、Ｆ１１を、ＳＮが連続した複数のＲＬＣ  ＰＤＵ（のペイロード部）が結合されてなる部分を有するフレームであると認識する。
【０２７６】
ＭＡＣレイヤ２０２では、フレームＦ１０のペイロード部（ＲＬＣヘッダを除く部分）を、規定のサイズ、すなわち、個々のＲＬＣ  ＰＤＵのペイロード部のサイズ（４０バイト）で先頭から等分に切り分けて複数のデータに分割し、これら各データに対し、ＲＬＣヘッダを生成及び付加することにより、ＲＬＣ  ＰＤＵを生成する。
【０２７７】
ここで、第５の実施形態と同様に、先頭のＲＬＣ  ＰＤＵについては、ＲＬＣレイヤ２０３から受け渡されたＲＬＣ  ヘッダ（ＳＮ＝０）をそのまま用い、２番目のＲＬＣ  ＰＤＵからは、先頭のＲＬＣ  ＰＤＵのヘッダに格納されているＳＮを１つずつインクリメントする形で、全てのＲＬＣ  ヘッダを生成する。
【０２７８】
そして、これら生成したＲＬＣ  ＰＤＵをネットワークへ転送する。
【０２７９】
また、フレームＦ１１は、その先頭が、所定のプロトコル処理が必要なＲＬＣ  ＰＤＵであるため、ＭＡＣレイヤ２０２は、フレームＦ１１の先頭は、ＲＬＣ  ＰＤＵの規定のサイズ（４２バイト）で切り取り、残りのペイロード部は、個々のＲＬＣ  ＰＤＵのペイロード部のサイズ（４０バイト）で先頭から等分に切り分けて複数のデータに分割し、これら各データに対し、ＲＬＣヘッダを生成及び付加することにより、ＲＬＣ  ＰＤＵを生成する。また、この際、所定のプロトコル処理が必要な先頭のＲＬＣ  ＰＤＵのヘッダに格納されているＳＮを１つずつインクリメントする形で、全てのＲＬＣ  ヘッダを生成する。
【０２８０】
そして、これら生成したＲＬＣ  ＰＤＵをネットワークへ転送する。
【０２８１】
また、ＭＡＣレイヤ２０２は、規定のサイズのデータ量のフレームＦ１２については、１個のＲＬＣ  ＰＤＵであると認識し、そのままネットワークへ転送する。
【０２８２】
以上のような第６の実施形態によれば、フレームＦ１１は、規定のサイズの端数データを含むＲＬＣ  ＰＤＵ（例えば、ＳＮ＝３７）と、このＲＬＣ  ＰＤＵの分割元であるＲＬＣ  ＳＤＵ（Ｎｏ．１）とは別のＲＬＣ  ＳＤＵ（Ｎｏ．２）から分割された、規定のサイズ（４０バイト）の整数倍のデータと、を含む構成である。このため、上記の第５の実施形態よりも、フレームの数を低減でき、ＲＬＣレイヤ２０３における処理負荷を更に軽減できる。
【０２８３】
なお、上記の各実施形態では、高レートのデータ転送であるＨＳＤＰＡのＨＳＰＡ（Ｈｉｇｈ  Ｓｐｅｅｄ  Ｐａｃｋｅｔ  Ａｃｃｅｓｓ）動作を例示したが、３Ｇで使われる他の全てのチャネル（ＤＣＨ（Ｄｅｄｉｃａｔｅｄ  Ｃｈａｎｎｅｌ）、ＦＡＣＨ（Ｆｏｒｗａｒｄ  Ａｃｃｅｓｓ  Ｃｈａｎｎｅｌ）、ＲＡＣＨ（Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｃｈａｎｎｅｌ）、Ｅ−ＤＣＨ（Ｅｎｈａｎｃｅｄ  Ｄｅｄｉｃａｔｅｄ  Ｃｈａｎｎｅｌ））にも同様に適用可能である。
【図面の簡単な説明】
【０２８４】
【図１】第１の実施形態に係る通信処理装置の構成を示すブロック図である。
【図２】第１の実施形態に係る通信処理方法の動作を示す模式図である。
【図３】通信処理装置の制御部のハードウェア構成を示すブロック図である。
【図４】第１の実施形態の変形例に係る通信処理方法の動作を示す模式図である。
【図５】第２の実施形態に係る通信処理方法の動作を示す模式図である。
【図６】第２の実施形態の変形例に係る通信処理方法の動作を示す模式図である。
【図７】第３の実施形態に係る通信処理装置の構成を示すブロック図である。
【図８】第３の実施形態に係る通信処理方法の動作（ＲＬＣ  ＳＤＵ１個分のデータ転送時）を示す模式図である。
【図９】第３の実施形態に係る通信処理方法の動作（ＲＬＣ  ＳＤＵ２個分のデータ転送時）を示す模式図である。
【図１０】第４の実施形態に係る通信処理方法の動作を示す模式図である。
【図１１】第５の実施形態に係る通信処理方法の動作を示す模式図である。
【図１２】第６の実施形態に係る通信処理方法の動作を示す模式図である。
【図１３】Ｗ−ＣＤＭＡのシステムで想定されている無線インターフェイスのプロトコル階層を示す図である。
【図１４】ＨＳＤＰＡのカテゴリ毎の、１ＴＴＩ内にＲＬＣレイヤにおいて処理すべきトランスポート・ブロックの最大ビット数、及びＲＬＣ  ＰＤＵの理論上の最大個数を示す図である。
【図１５】基本的なチャネル・コンフィグレーションの場合における、レイヤ毎の、データ・フレームの名称及び形態の対応を示す図である。
【図１６】ＲＬＣ  ＰＤＵの構造を示す図である。
【図１７】ＲＬＣ  ヘッダを構成している各識別情報のデータ量及び内容を示す図である。
【図１８】代表的なフレーム・サイズ（ＲＬＣ  ＳＤＵ：１５００バイト、ＲＬＣ  ＰＤＵ：４２バイト）の場合の、ＲＬＣ  ＳＤＵとＲＬＣ  ＰＤＵとの対応を示す図である。
【図１９】代表的なフレーム・サイズ（ＲＬＣ  ＳＤＵ：１５００バイト、ＲＬＣ  ＰＤＵ：４２バイト）の場合の、一般的なダウンリンク・データ転送の動作を示す模式図である。
【図２０】代表的なフレーム・サイズ（ＲＬＣ  ＳＤＵ：１５００バイト、ＲＬＣ  ＰＤＵ：４２バイト）の場合の、一般的なアップリンク・データ転送の動作を示す模式図である。
【符号の説明】
【０２８５】
１、２、３  データ
１１  識別情報（第１の識別情報）
１２  識別情報（単体データ用識別情報、第１の識別情報）
１３、１４  代表識別情報（結合データ用識別情報）
２０  結合データ
３１、３２、３３  第１のフレーム
３４  第２のフレーム
３５  第３のフレーム
２１、２２、２３  識別情報（第２の識別情報）
５０  データ
５１  データ
６１  第１のフレーム
６２、６３  第２のフレーム
６４  第３のフレーム
１００  通信処理装置
１０３  第１のレイヤ処理手段
１０４  第２のレイヤ処理手段
１０５  第３のレイヤ処理手段
３０２  ＭＡＣレイヤ処理手段（第１のレイヤ処理手段）
３０３  ＲＬＣレイヤ処理手段（第２のレイヤ処理手段）
３０４  ＰＤＣＰレイヤ処理手段（第３のレイヤ処理手段）
Ｆ１、Ｆ３、Ｆ５  第２のフレーム
Ｆ２、Ｆ４、Ｆ７  第３のフレーム
Ｆ６  第３のフレーム
Ｆ８、Ｆ１０  第１のフレーム
Ｆ９、Ｆ１２  第３のフレーム
Ｆ１１  第３のフレーム
【図１】
0004780482.tif 000002
【図２】
0004780482.tif 000003
【図３】
0004780482.tif 000004
【図４】
0004780482.tif 000005
【図５】
0004780482.tif 000006
【図６】
0004780482.tif 000007
【図７】
0004780482.tif 000008
【図８】
0004780482.tif 000009
【図９】
0004780482.tif 000010
【図１０】
0004780482.tif 000011
【図１１】
0004780482.tif 000012
【図１２】
0004780482.tif 000013
【図１３】
0004780482.tif 000014
【図１４】
0004780482.tif 000015
【図１５】
0004780482.tif 000016
【図１６】
0004780482.tif 000017
【図１７】
0004780482.tif 000018
【図１８】
0004780482.tif 000019
【図１９】
0004780482.tif 000020
【図２０】
0004780482.tif 000021