(57)【要約】【課題】  メッセージデータの保持に必要なメモリの使用効率を向上させると共に拡張されたメッセージデータを受信する場合でも装置構成の変更が不要な通信装置及びデータ受信方法を提供する。【解決手段】  バッファサイズが異なる複数種類の受信バッファをそれぞれ複数用意しておき、メッセージデータを受信すると、該メッセージデータのデータサイズに合わせて複数の受信バッファの組み合わせを決定し、組み合わせが決定した複数の受信バッファにメッセージデータを分割してそれぞれ格納する。【選択図】  図１
2007043580.tif 000002
【特許請求の範囲】
【請求項１】
様々なデータサイズを持つメッセージデータを受信する通信装置であって、
バッファサイズが異なる複数の種類毎にそれぞれ複数備える、前記メッセージデータが格納される受信バッファと、
受信したメッセージデータのデータサイズに合わせて、複数の受信バッファの組み合わせを決定する受信バッファ組み合わせ処理部と、
前記組み合わせの決定した複数の受信バッファに、該メッセージデータを分割してそれぞれ格納するメッセージ設定処理部と、
を有する通信装置。
【請求項２】
前記受信バッファは、
前記受信バッファの組み合わせに応じて連結される、同一のバッファサイズにおける後続する受信バッファの番号を示す受信バッファサイズキュー用次バッファポインタを格納するための領域を有する請求項１記載の通信装置。
【請求項３】
前記受信バッファは、
該受信バッファに格納されたメッセージデータの分割前のメッセージデータにおける位置を示すＲＲＣメッセージ状態を格納するための領域、及び該受信バッファと組み合わされる残りの受信バッファの数である残受信バッファ数を格納するための領域を有する請求項１または２記載の通信装置。
【請求項４】
様々なデータサイズを持つメッセージデータを通信装置で受信するためのデータ受信方法であって、
バッファサイズが異なる複数種類の受信バッファをそれぞれ複数用意しておき、
前記メッセージデータを受信すると、該メッセージデータのデータサイズに合わせて複数の受信バッファの組み合わせを決定し、
前記組み合わせが決定した複数の受信バッファに、前記メッセージデータを分割してそれぞれ格納するデータ受信方法。
【請求項５】
前記受信バッファに、
前記受信バッファの組み合わせに応じて連結される、同一のバッファサイズにおける後続する受信バッファの番号を示す受信バッファサイズキュー用次バッファポインタを格納する請求項４記載のデータ受信方法。
【請求項６】
前記受信バッファに、
該受信バッファに格納されたメッセージデータの分割前のメッセージデータにおける位置を示すＲＲＣメッセージ状態、及び該受信バッファと組み合わされる残りの受信バッファの数である残受信バッファ数を格納する請求項４または５記載のデータ受信方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、Ｗ−ＣＤＭＡ（Wideband Code Division Multiple Access）方式の移動通信システム等で用いられる、様々なデータサイズを持つメッセージデータを受信するための受信バッファを備えた通信装置に関する。
【背景技術】
【０００２】
Ｗ−ＣＤＭＡ方式の移動通信システムでは、ＲＲＣ（Radio Resource Control）と呼ばれる無線インタフェースのレイヤ３プロトコルが規定されている。基地局装置を制御するＲＮＣ装置は、このＲＲＣにしたがって、携帯端末との間で、報知情報の通知、特定の携帯端末の呼び出し、コネクションの設定／変更／開放、信号の転送等の各種処理で必要な様々なメッセージデータ(以下、ＲＲＣメッセージと称す)を送受信する。ＲＲＣメッセージのデータサイズは、数バイト（byte）から数千バイトまで様々であり、収容ユーザ数や報知情報の種類によって変化する。
【０００３】
従来、このような様々なデータサイズを持つＲＲＣメッセージを受信する場合、その最大長のＲＲＣメッセージを格納できる受信バッファを用意しなければならないため、メモリを無駄に使用することがあった。近年、ＲＲＣメッセージは、ユーザ数の増加や１ユーザ当たりの情報量の増大に伴って巨大化する傾向にある。
【０００４】
また、上記ＲＲＣメッセージを含むフレームの送信間隔や多重数には、ＴＦＣＳ（Transport Format Combination Set）による制限があり、巨大なＲＲＣメッセージであっても一度に送受信できるのはそのうちのわずか数十バイトに制限される。そのため、ＲＲＣメッセージは、その送受信が完了するまで、全てのデータを保持しておかなければならず、あと数バイトでＲＲＣメッセージの送受信が完了する場合でも数千バイトのバッファを解放することなく使用することになり、メモリを無駄に使用してしまう。
【０００５】
なお、基地局装置とＲＮＣ装置との間で制御信号を送受信する際に、その制御信号を分割して送信することは、例えば特許文献１に記載されている。特許文献１では、制御信号を基地局装置のコンテキストに応じて分割し、各コンテキストを識別するための識別子、分割した制御メッセージのタイプ及び分割した制御信号の何番目の信号かを示すシーケンス番号を付与して送信し、受信装置側はそれらの情報を用いて送信された制御信号を再構築することが記載されている。
【特許文献１】特開２００２−３７４５６５号公報
【発明の開示】
【発明が解決しようとする課題】
【０００６】
上述したように、ＲＮＣ装置では、数回しか送受信しないＲＲＣメッセージを保持するためにその最大長の受信バッファを用意しておかなければならず、メモリの使用効率が非常に悪いという問題がある。ＲＲＣメッセージは、上述したように携帯端末に対する報知情報の通知、特定の携帯端末の呼び出し、コネクションの設定／変更／解放、及び信号転送等で利用されるため、使用日時や場所に応じて多数のＲＲＣメッセージがほぼ同時に送受信される可能性がある。そのようなバースト的な通信に対処するために、最大長のＲＲＣメッセージを格納できる受信バッファをシステムが単位時間当たり許容する最大受信数分だけ常に用意しておく必要がある。
【０００７】
また、ＲＲＣメッセージは、その拡張がプロトコル上で認められているため、ＲＲＣメッセージを拡張した結果、ＲＲＣメッセージの受信のために用意していたバッファサイズを越えてしまった場合は、受信側の装置構成を変更しなければならないという問題もあった。
【０００８】
なお、Ｗ−ＣＤＭＡ方式の移動通信システムでは、全体の処理時間に対する制約があるために、リソースの捕捉や解放あるいはＲＲＣメッセージの処理をスケジューリングする必要があり、少しでも速い処理時間が望まれている。
【０００９】
一方、ＲＮＣ装置は、通信プロトコルを実現するために複数のレイヤが設けられており、これらのレイヤ間でデータを交換するためには、各レイヤ間で定義されているチャネルを適宜マッピングする必要がある。例えば、ＲＲＣ（Radio Resource Control）とＲＬＣ（Radio Link Control）間には論理チャネルがあり、ＲＬＣとＭＡＣ間にはトランスポートチャネルがあり、ＭＡＣ（Medium Access Control）とＦＰ(Framing Protocol)間には物理チャネルがある。
【００１０】
Ｗ−ＣＤＭＡ方式の移動通信システムでは、通常、使用が終了したリソース（メモリ）を物理チャネル単位で解放するため、リソースの解放対象となる物理チャネルにマッピングされたトランスポートチャネルや論理チャネルもそれぞれ解放しなければならず、リソースの解放のための手順が複雑になって処理時間が長くなる。そのため、受信バッファを管理する際には、リソースを容易に解放できるようにすることが望ましい。
【００１１】
本発明は上記したような従来の技術が有する問題点を解決するためになされたものであり、メッセージデータの保持に必要なメモリの使用効率を向上させると共に拡張されたメッセージデータを受信する場合でも装置構成の変更が不要な通信装置及びデータ受信方法を提供することを目的とする。
【課題を解決するための手段】
【００１２】
上記目的を達成するため本発明の通信装置は、データサイズの変化が大きいメッセージデータを受信する通信装置であって、
バッファサイズが異なる複数の種類毎にそれぞれ複数備える、前記メッセージデータが格納される受信バッファと、
受信したメッセージデータのデータサイズに合わせて、複数の受信バッファの組み合わせを決定する受信バッファ組み合わせ処理部と、
前記組み合わせの決定した複数の受信バッファに、該メッセージデータを分割してそれぞれ格納するメッセージ設定処理部と、
を有する構成である。
【００１３】
一方、本発明のデータ受信方法は、データサイズの変化が大きいメッセージデータを通信装置で受信するためのデータ受信方法であって、
バッファサイズが異なる複数種類の受信バッファをそれぞれ複数用意しておき、
前記メッセージデータを受信すると、該メッセージデータのデータサイズに合わせて複数の受信バッファの組み合わせを決定し、
前記組み合わせが決定した複数の受信バッファに、前記メッセージデータを分割してそれぞれ格納する方法である。
【００１４】
上記のような通信装置及びデータ受信方法では、バッファサイズが異なる複数種類の受信バッファをそれぞれ複数用意しておき、メッセージデータを受信すると、該メッセージデータのデータサイズに合わせて複数の受信バッファの組み合わせを決定し、組み合わせが決定した複数の受信バッファにメッセージデータを分割してそれぞれ格納することで、様々なデータサイズを持つメッセージデータを格納するために最大長のメモリ領域を余分に確保する必要がなくなる。
【発明の効果】
【００１５】
本発明によれば、バッファサイズが異なる複数種類の受信バッファをそれぞれ複数用意しておき、メッセージデータを受信すると、該メッセージデータのデータサイズに合わせて複数の受信バッファの組み合わせを決定し、組み合わせが決定した複数の受信バッファにメッセージデータを分割してそれぞれ格納することで、様々なデータサイズを持つメッセージデータを格納するために最大長のメモリ領域を余分に確保する必要がなくなり、メモリを効率的に使用できる。
【００１６】
また、データサイズに合わせて組み合わせた複数の受信バッファにメッセージデータを分割して格納するため、メッセージデータが拡張されている場合でも装置構成を変更することなく該メッセージデータを受信できる。
【発明を実施するための最良の形態】
【００１７】
次に本発明について図面を参照して説明する。
【００１８】
本発明の通信装置は、バッファサイズが異なる複数種類の受信バッファをそれぞれ複数用意し、上述した数バイトから数千バイトまで様々なデータサイズを持つメッセージデータ（ＲＲＣメッセージ）を、そのデータサイズに合うように組み合わせた複数の受信バッファに分割して格納する。また、ＲＲＣメッセージのデータサイズに合わせて複数の受信バッファを最適に組み合わせることで、ＲＲＣメッセージが拡張されている場合でも装置構成を変更することなく該ＲＲＣメッセージの受信を可能にする。
【００１９】
図１に示すように、移動通信システムは、ネットワークにおける情報の管理や他のＲＮＣ装置２の管理を行うＣＮ(Core Network)装置１と、携帯端末４と基地局装置３間の無線通信を統括し、複数の基地局装置３をそれぞれ制御するＲＮＣ装置２と、携帯端末４と無線通信を行う基地局装置３とを有し、携帯端末４による他の携帯端末や固定電話機との通話、あるいはネットワークに接続されたサーバ装置等とのデータ送受信を可能にする構成である。
【００２０】
ＣＮ装置１は、管理対象となるエリア内の全携帯端末４に対して、報知情報の通知、特定の携帯端末の呼び出し、コネクションの設定／変更／解放、信号の転送等をＲＮＣ（Radio Network Controller）装置２を利用して行う。
【００２１】
ＲＮＣ装置２は、ＲＲＣ装置２１、ＲＭＳＣ（RRC Message Segmentation Controller）装置２２、ＲＬＣ装置２３、ＭＡＣ装置２４及びＦＰ装置２５を備えた構成である。
【００２２】
ＲＲＣ装置２１は、ＣＮ装置１からの指示にしたがってＲＲＣメッセージを生成し、該ＲＲＣメッセージを下位プロトコル装置であるＲＭＳＣ装置２２、ＲＬＣ装置２３、ＭＡＣ装置２４及びＦＰ装置２５を介して基地局装置３へ送信する。また、ＲＲＣ装置２１は、ＲＭＳＣ装置２２、ＲＬＣ装置２３、ＭＡＣ装置２４及びＦＰ装置２５に対して、それらの装置で実行するリソースの捕捉や解放処理等を制御するための処理を行う。
【００２３】
ＲＭＳＣ装置２２は、ＲＲＣメッセージ受信部２２１、受信バッファ送信部２２２、物理チャネルリソース処理部２２３、ＲＲＣメッセージ共通受信バッファ２２４、ＲＲＣメッセージ設定処理部２２５、受信バッファ組み合わせ処理部２２６、デキュー処理部２２７、エンキュー処理部２２８、物理チャネルキュー管理部２２９、受信バッファ２２Ａ及び空きキュー管理部２２Ｂを備えている。
【００２４】
ＲＲＣメッセージ受信部２２１は、ＲＲＣ装置２１から送信されたＲＲＣメッセージを受信し、それに付与された各種パラメータのチェック及び該ＲＲＣメッセージの送信に用いる物理チャネルが捕捉済みであるか否かの判定を行う。
【００２５】
受信バッファ送信部２２２は、捕捉された物理チャネルの物理チャネルキューから所定の周期毎に受信バッファ内のデータを取り出してＲＬＣ装置２３へ送信し、使用が終了した受信バッファを解放する。
【００２６】
物理チャネルリソース処理部２２３は、物理チャネル単位でリソースの捕捉と解放を行う。
【００２７】
ＲＲＣメッセージ共通受信バッファ２２４は、ＲＲＣ装置２１から送信されたＲＲＣメッセージを一時的に保持するバッファである。
【００２８】
ＲＲＣメッセージ設定処理部２２５は、空きキューからの受信バッファの取得、受信バッファに対するＲＲＣメッセージの格納、ＲＲＣメッセージの分割及びそれに関連する各種パラメータの設定、並びに物理チャネルキューへの受信バッファの連結処理を行う。
【００２９】
受信バッファ組み合わせ処理部２２６は、ＲＲＣメッセージのデータサイズ及び受信バッファに割り当て可能な空きキューの情報に基づき受信バッファの組み合わせを決定する。
【００３０】
デキュー処理部２２７は、空きキュー及び物理チャネルキューから受信バッファ内のデータをデキューする。また、エンキュー処理部２２８は、空きキュー及び物理チャネルキューに対して受信バッファ内のデータをエンキューする。
【００３１】
物理チャネルキュー管理部２２９は、物理チャネルキュー管理テーブル及び受信バッファサイズ別物理チャネルキュー管理テーブルを備えた構成である。
【００３２】
図２に示すように、物理チャネルキュー管理テーブルは、捕捉済みフラグ、リンク数、先頭受信バッファポインタ、最終受信バッファポインタの各要素を備えている。これらの要素を設定することで、各物理チャネルに割り当てたリソースの管理及び物理チャネルキューを管理する。
【００３３】
捕捉済みフラグは、物理チャネルのリソースが捕捉されているか否かを示すビットである。また、リンク数は、物理チャネルキューに連結されている受信バッファの数を示している。先頭受信バッファポインタは、物理チャネルキューに入っている先頭の受信バッファの受信バッファ番号を示している。物理チャネルキューに受信バッファが入っていない場合、先頭受信バッファポインタにはリンクなしを示す「０ｘＦＦＦＦ」が設定される。
【００３４】
最終受信バッファポインタは、物理チャネルキューに入っている最終の受信バッファの受信バッファ番号を示している。物理チャネルキューに受信バッファが入っていない場合、最終受信バッファポインタにはリンクなしを示す「０ｘＦＦＦＦ」が設定される。受信バッファが１つだけ物理チャネルキューに入っている場合、最終受信バッファポインタには先頭受信バッファポインタと同じ番号が設定される。
【００３５】
また、図３に示すように、受信バッファサイズ別物理チャネルキュー管理テーブルは、リンク数、先頭受信バッファポインタ、及び最終受信バッファポインタの各要素を備えている。これらの要素を設定することで、各物理チャネルに割り当てた受信バッファをバッファサイズ毎にそれぞれ管理する。
【００３６】
リンク数は、物理チャネルキューに連結されているバッファサイズ毎の受信バッファの数を示している。先頭受信バッファポインタは、バッファサイズ毎の物理チャネルキューに入っている先頭の受信バッファの受信バッファ番号を示している。物理チャネルキューに受信バッファが入っていない場合、先頭受信バッファポインタにはリンクなしを示す「０ｘＦＦＦＦ」が設定される。最終受信バッファポインタは、バッファサイズ毎の物理チャネルキューに入っている最終の受信バッファの受信バッファ番号を示している。物理チャネルキューに受信バッファが入っていない場合、最終受信バッファポインタにはリンクなしを示す「０ｘＦＦＦＦ」が設定される。物理チャネルキューに受信バッファが１つだけ入っている場合、最終受信バッファポインタには先頭受信バッファポインタと同じ番号が設定される。
【００３７】
図４に示すように、受信バッファ２２Ａは、上述したように異なるバッファサイズ毎にそれぞれ複数備え、分割したＲＲＣメッセージを格納する複数の受信バッファ２２Ａを連結する（リンクする）ための情報、ＲＲＣメッセージが分割されていることを示す情報、及びＲＲＣメッセージを格納するためのデータ部を備えた構成である。具体的には、受信バッファ２２Ａは、受信バッファ番号、ＲＲＣメッセージ状態、ＲＲＣメッセージ固有パラメータ、物理チャネルキュー用次バッファポインタ、受信バッファサイズキュー用次バッファポインタ、格納データサイズ、残受信バッファ数、及びＲＲＣメッセージのデータを格納するデータ部の各要素によって構成される。
【００３８】
ＲＲＣメッセージ状態は、分割されたＲＲＣメッセージの位置（分割前のＲＲＣメッセージにおける位置）を示し、「先頭かつ最終」、「先頭」、「途中」または「最終」の４つの状態がある。ＲＲＣメッセージ固有パラメータは分割されたＲＲＣメッセージの固有情報を格納する領域であり、格納データサイズは受信バッファに格納されたＲＲＣメッセージのデータサイズが格納される領域である。残受信バッファ数は、１つのＲＲＣメッセージを格納するために組み合わされる残りの受信バッファの数を示している。
【００３９】
受信バッファサイズキュー用次バッファポインタは、複数の受信バッファの組み合わせに応じて連結される、同一のバッファサイズにおける後続する受信バッファの番号を示している。連結する同一のバッファサイズの受信バッファが無い場合、受信バッファサイズキュー用次バッファポインタはリンクなし（０ｘＦＦＦＦ）に設定される。
【００４０】
空きキュー管理部２２Ｂは、複数の受信バッファに割り当てる空きキューをサイズ別に管理するための空きキュー管理テーブルを備えている。空きキュー管理テーブルは、図５に示すように、リンク数、先頭受信バッファポインタ、最終受信バッファポインタの各要素を備えている。これらの要素を設定することにより、空きキュー管理部２２Ｂは空きキューに割り当てた受信バッファをバッファサイズ別に管理する。
【００４１】
リンク数は、空きキューに連結されているバッファサイズ毎の受信バッファの数を示している。先頭受信バッファポインタは、バッファサイズ毎の空きキューに入っている先頭の受信バッファの受信バッファ番号を示している。空きキューに受信バッファが入っていない場合、先頭受信バッファポインタにはリンクなしを示す「０ｘＦＦＦＦ」が設定される。最終受信バッファポインタは、バッファサイズ毎の空きキューに入っている最終の受信バッファの受信バッファ番号を示している。空きキューに受信バッファが入っていない場合、最終受信バッファポインタにはリンクなしを示す「０ｘＦＦＦＦ」が設定される。空きキューに受信バッファが１つだけ入っている場合、最終受信バッファポインタには先頭受信バッファポインタと同じ番号が設定される。
【００４２】
ＲＬＣ装置２３は、受信したＲＲＣメッセージからＲＬＣ ＰＤＵ（Protocol Data Unit）を生成し、ＭＡＣ装置２４へ送信する。ＭＡＣ装置２４は、ＲＬＣ装置２３から受信したＲＬＣ ＰＤＵを基にＭＡＣ ＰＤＵを生成し、ＦＰ装置２５へ送信する。ＦＰ装置２５は、ＴＦＣＳにしたがってＭＡＣ ＰＤＵを多重し、ＦＰフレームを生成して基地局装置３へ送信する。
【００４３】
基地局装置３は、ＲＮＣ装置２から受信したＲＲＣメッセージを含むＦＰフレームを無線周波数信号により携帯端末４へ送信する。携帯端末４は、基地局装置３と無線周波数信号によりデータを送受信することで、他の携帯端末４や固定電話機との通話やネットワークに接続されたサーバ装置とのデータの送受信を可能にする。
【００４４】
次に、本発明のＲＭＳＣ装置２２の動作について、図２〜図５を参照しつつ、図６〜図８を用いて説明する。
＜初期化＞
ＲＭＳＣ装置２２は、ＲＮＣ装置２の起動時に１度だけ初期化処理を行う。初期化処理には、物理チャネルキュー管理部２２９が備える物理チャネルキュー管理テーブル及び受信バッファサイズ別物理チャネルキュー管理テーブルの初期化処理と、空きキューに受信バッファを割り当てるための初期化処理とがある。
【００４５】
まず、物理チャネルキュー管理部２２９の初期化処理について説明する。
【００４６】
物理チャネルキュー管理部２２９は、上述したように物理チャネルキュー管理テーブル（図２参照）及び受信バッファサイズ別物理チャネルキュー管理テーブル（図３参照）を備えている。物理チャネルキュー管理テーブルは、物理チャネルのリソース管理、受信バッファの送信順及び分割したＲＲＣメッセージのリンクを制御するために用いられ、物理チャネル毎に、捕捉済みフラグ、リンク数、先頭受信バッファポインタ及び最終バッファポインタの各要素を備えている。また、受信バッファサイズ別物理チャネルキュー管理テーブルは、受信バッファのバッファサイズ毎に、リンク数、先頭受信バッファポインタ及び最終バッファポインタの各要素を備えている。
【００４７】
物理チャネルキュー管理部２２９は、初期化処理時に各管理テーブルを以下に記載する値に設定する。
【００４８】
まず、全ての物理チャネルキュー管理テーブルの捕捉済みフラグを「未捕捉」を示す値に設定する。また、全ての受信バッファサイズ別物理チャネルキュー管理テーブルのリンク数を０、先頭受信バッファポインタをリンクなし(０ｘＦＦＦＦ)、最終受信バッファポインタをリンクなし(０ｘＦＦＦＦ)にそれぞれ設定する。
【００４９】
次に、空きキューに受信バッファを割り当てるための初期化処理について説明する。
【００５０】
図６に示すように、空きキューは物理チャネルキューと同様にサイズ毎に用意され、各空きキューに受信バッファが割り当てられる。これらの空きキューを管理するために、本発明では図５に示した空きキュー管理テーブルを利用する。空きキュー管理テーブルは、空きキューのサイズ毎に、リンク数、先頭受信バッファポインタ及び最終バッファポインタの各要素を備えている。
【００５１】
ここでは、空きキューの初期化処理で用いるパラメータについてのみ説明する。
【００５２】
空きキューの初期化処理では、まず、空きキュー管理テーブルのリンク数を０、先頭受信バッファポインタをリンクなし(０ｘＦＦＦＦ)、最終受信バッファポインタをリンクなし(０ｘＦＦＦＦ)に設定する。そして、エンキュー処理部２２８にて空きキューと同一サイズの受信バッファを１つずつエンキューし、同一サイズの受信バッファがなくなるまで繰り返す。この処理を、全てのサイズの受信バッファに対して行う。なお、エンキューの処理については後述する＜エンキュー処理＞にて説明する。
＜物理チャネル単位のリソースの捕捉方法＞
ＣＮ装置１からＲＲＣコネクションの確立が要求されると、ＲＲＣ装置２１は、下位プロトコル装置であるＲＭＳＣ装置２２、ＲＬＣ装置２３、ＭＡＣ装置２４及びＦＰ装置２５へリソースの捕捉を要求する。各下位プロトコル装置は、ＲＲＣ装置２１からの要求にしたがってそれぞれリソースの捕捉を行う。ここでは、ＲＭＳＣ装置２２のリソース捕捉処理についてのみ説明する。
【００５３】
ＲＭＳＣ装置２２は、ＲＲＣ装置２１からリソースの捕捉要求を受信すると、物理チャネルリソース処理部２２３により物理チャネルキュー管理部２２９にリソースの捕捉を要求する。
【００５４】
物理チャネルキュー管理部２２９は、指定された物理チャネルに対応する物理チャネルキュー管理テーブルの捕捉済みフラグを「捕捉済み」に設定し、ＲＲＣメッセージを受信可能な状態にする。また、受信バッファのリンク数を０、先頭受信バッファポインタをリンクなし(０ｘＦＦＦＦ)、最終受信バッファポインタをリンクなし(０ｘＦＦＦＦ)にそれぞれ設定する。
＜ＲＲＣメッセージの受信と分割方法＞
まず、各処理部に対するデータの流れと動作を説明する。
【００５５】
ＲＲＣ装置２１は、エリア内の全携帯端末４に対する報知情報の通知、特定の携帯端末の呼び出し、コネクションの設定／変更／解放、または信号転送等の要求をＣＮ装置１から受信すると、その要求に対応するＲＲＣメッセージを作成してＲＭＳＣ装置２２へ送信する。
【００５６】
ＲＭＳＣ装置２２は、ＲＲＣメッセージ受信部２２１にてＲＲＣメッセージを受信すると、受信したＲＲＣメッセージをＲＲＣメッセージ共通受信バッファ２２４へ一時的に格納する。また、ＲＲＣメッセージ受信部２２１にてＲＲＣメッセージ固有パラメータをチェックし、該当する物理チャネルを取得すると共にＲＲＣメッセージのデータサイズを取得する。ＲＲＣメッセージ固有パラメータをチェックした結果、正常と判定した場合、ＲＭＳＣ装置２２は、どの物理チャネルを用いるＲＲＣメッセージであるかを判定するために、物理チャネルキュー管理部２２９に該当する物理チャネルが捕捉済みであるか否かを問い合わせる。
【００５７】
物理チャネルキュー管理部２２９は、該当する物理チャネルキュー管理テーブルの捕捉済みフラグの内容をＲＲＣメッセージ受信部２２１へ通知する。受信したＲＲＣメッセージが捕捉済みの物理チャネルを利用するもので無い場合はそのＲＲＣメッセージを廃棄する。また、受信したＲＲＣメッセージが捕捉済みの物理チャネルを利用する場合はＲＲＣメッセージ設定処理部２２５による処理へ移行する。
【００５８】
ＲＲＣメッセージ設定処理部２２５は、受信したＲＲＣメッセージを受信バッファへ格納するために、そのデータサイズを基に受信バッファの組み合わせを知る必要がある。そのため、受信バッファ組み合わせ処理部２２６へＲＲＣメッセージのデータサイズを通知し、受信バッファの組み合わせを決定するよう要求する。
【００５９】
受信バッファ組み合わせ処理部２２６は、ＲＲＣメッセージのデータサイズと空きキュー管理部から取得した空きキューの情報とを基に、受信バッファの最適な組み合わせを決定する。
【００６０】
ＲＲＣメッセージ設定処理部２２５は、受信バッファ組み合わせ処理部２２６で決定した受信バッファの組み合わせ結果を基に、デキュー処理２２７にて空きキューからバッファサイズの大きい順に受信バッファを取得する。そして、取得した受信バッファに、ＲＲＣメッセージ状態、ＲＲＣメッセージ固有パラメータ、格納データサイズ、残受信バッファ数及びデータ部の各領域をそれぞれ設定する。
【００６１】
ＲＲＣメッセージ状態、ＲＲＣメッセージ固有パラメータ、格納データサイズ、残受信バッファ数及びデータ部の設定が完了すると、ＲＲＣメッセージ設定処理部２２５は、エンキュー処理２２８を用いて、物理チャネルキュー管理部２２９及び受信バッファ２２Ａを操作し、物理チャネルキューへ受信バッファをエンキューする。以上の処理を、受信バッファ組み合わせ処理部２２６で決定した組み合わせ対象となる全ての受信バッファに対して実行する。
【００６２】
次に、図７を用いて各キューに対するデータの流れ、及び各キューの管理テーブルと受信バッファの設定方法について説明する。なお、以下では、４１０６バイトのＲＲＣメッセージを受信し、該ＲＲＣメッセージを格納する受信バッファとして、バッファサイズが４０９６バイトの受信バッファ１つと、バッファサイズが３２バイトの受信バッファ１つの組み合わせを決定した場合を例にして説明する。
【００６３】
図７に示すように、ＲＭＳＣ装置２２は、ＲＲＣ装置２１からＲＲＣメッセージを受信すると、ＲＲＣメッセージ設定処理部２２５から受信バッファ組み合わせ処理部２２６に該ＲＲＣメッセージのデータサイズの情報を送信し、受信バッファの組み合わせの決定を要求する。ここでは、上述したように、受信バッファ組み合わせ処理部２２６にてバッファサイズが４０９６バイトの受信バッファ１つと、バッファサイズが３２バイトの受信バッファ１つの組み合わせが決定する。
【００６４】
受信バッファの組み合わせが決定すると、ＲＲＣメッセージ設定処理部２２５は、空きキューから４０９６バイトの受信バッファ１つをデキューするようにデキュー処理部２２７へ要求する。
【００６５】
デキュー処理部２２７は、バッファサイズが４０９６バイトの空きキューに対応する空きキュー(４０９６バイト)管理テーブルの先頭受信バッファポインタの値により使用する受信バッファの受信バッファ番号(０ｘ８０００)を特定する。
【００６６】
空きキュー管理部２２Ｂは、空きキュー(４０９６バイト)管理テーブルの先頭受信バッファポインタの値を、デキュー処理部２２７で特定した受信バッファの受信バッファサイズキュー用次バッファポインタの値に書き換え、該受信バッファの物理チャネルキュー用受信バッファポインタと受信バッファサイズキュー用次バッファポインタとをリンクなし(０ｘＦＦＦＦ)にそれぞれ書き換える。
【００６７】
続いて、デキューした受信バッファのＲＲＣメッセージ状態に、格納対象が分割したＲＲＣメッセージであり、かつ該分割したＲＲＣメッセージがＲＲＣメッセージ中の「先頭」であることを示す情報を格納する。また、格納データサイズには、ここではデータ部が満杯になるまでデータを格納するため、４０９６バイトに設定する。さらに、残受信バッファ数には、ＲＲＣメッセージの全てのデータを格納するのに要する残りの受信バッファが１つ在るため「１」を設定し、データ部に先頭から４０９６バイト分のデータを格納する。
【００６８】
ＲＲＣメッセージ状態、ＲＲＣ固有パラメータ、格納データサイズ、残受信バッファ数及びデータ部がそれぞれ設定された受信バッファは、エンキュー処理部２２８にて物理チャネルキューにエンキューされる。
【００６９】
エンキュー処理部２２８は、該当する物理チャネル（ここでは＃１）の物理チャネルキュー管理テーブルの最終受信バッファポインタの値から最終の受信バッファを特定し、その物理チャネルキュー用次バッファポインタの値を、エンキューする受信バッファの受信バッファ番号に書き換える。
【００７０】
次に、受信バッファサイズ別物理チャネルキュー管理テーブルの、エンキューする受信バッファと同一サイズの最終受信バッファポインタの値により、受信バッファサイズ毎に物理チャネルキューの最終の受信バッファを特定する。
【００７１】
また、その受信バッファサイズキュー用次バッファポインタの値を、エンキューする受信バッファの受信バッファ番号に書き換える。そして、物理チャネルキュー管理テーブルのリンク数を＋１し、最終受信バッファポインタの値をエンキューする受信バッファの受信バッファ番号に書き換える。また、受信バッファサイズ別物理チャネルキュー管理テーブルのリンク数を＋１し、最終受信バッファポインタの値をエンキューする受信バッファの受信バッファ番号に書き換える。
【００７２】
残りの３２バイトの受信バッファについても、４０９６バイトの受信バッファに対する処理と同様に、まずＲＲＣメッセージ設定処理部２２５からデキュー処理部２２７にて空きキューから３２バイトの受信バッファ１つをデキューするように要求する。
【００７３】
デキュー処理部２２７は、バッファサイズが３２バイトの空きキューに対応する空きキュー(３２バイト)管理テーブルの先頭受信バッファポインタの値により使用する受信バッファの受信バッファ番号(０ｘ１００１)を特定する。
【００７４】
空きキュー管理部２２Ｂは、空きキュー(３２バイト)管理テーブルの先頭受信バッファポインタの値を、デキュー処理部２２７で特定した受信バッファの受信バッファサイズキュー用次バッファポインタの値に書き換え、該受信バッファの物理チャネルキュー用受信バッファポインタと受信バッファサイズキュー用次バッファポインタとをリンクなし(０ｘＦＦＦＦ)にそれぞれ書き換える。
【００７５】
また、デキューしたこの受信バッファのＲＲＣメッセージ状態には、格納対象が分割したＲＲＣメッセージであり、かつ該分割したＲＲＣメッセージがＲＲＣメッセージ中の「最終」であることを示す情報を格納する。
【００７６】
格納データサイズは、ここでは残りのデータサイズが１０バイトであるため、１０バイトに設定する。残受信バッファ数は、分割したＲＲＣメッセージが格納される残りの受信バッファが無いため「０」を設定し、データ部に残りの１０バイト分のデータを格納する。
【００７７】
ＲＲＣメッセージ状態、ＲＲＣ固有パラメータ、格納データサイズ、残受信バッファ数及びデータ部がそれぞれ設定された受信バッファは、エンキュー処理部２２８にて物理チャネルキューにエンキューされる。
【００７８】
エンキュー処理部２２８は、該当する物理チャネルの物理チャネルキュー管理テーブルの最終受信バッファポインタの値から最終の受信バッファを特定し、その物理チャネルキュー用次バッファポインタの値をエンキューする受信バッファの受信バッファ番号に書き換える。
【００７９】
次に、受信バッファサイズ別物理チャネルキュー管理テーブルの、エンキューする受信バッファと同一サイズの最終受信バッファポインタの値により、受信バッファサイズ毎に物理チャネルキューの最終の受信バッファを特定する。
【００８０】
また、その受信バッファサイズキュー用次バッファポインタの値を、エンキューする受信バッファの受信バッファ番号に書き換える。そして、物理チャネルキュー管理テーブルの最終受信バッファポインタの値をエンキューする受信バッファの受信バッファ番号に書き換える。また、受信バッファサイズ別物理チャネルキュー管理テーブルの最終受信バッファポインタをエンキューする受信バッファの受信バッファ番号に書き換える。
【００８１】
なお、エンキューの処理の詳細については後述する＜エンキュー処理＞にて説明する。また、デキューの処理の詳細については後述する＜デキュー処理＞にて説明する。
＜受信バッファ送信＞
受信バッファ送信部２２２は、所定の周期（例えば１０ｍｓｅｃ）毎に捕捉済みの物理チャネルキューに受信バッファが搭載されているか否かを問い合わせる。搭載されていない場合はなにも実行しない。物理チャネルキューに受信バッファが搭載されている場合は、デキュー処理部２２７にて物理チャネルキューから受信バッファを取得し、ＲＬＣ装置２３へ送信した後、エンキュー処理部２２８にて空きキューに受信バッファをエンキューして解放する。
＜物理チャネル単位のリソース解放の場合＞
ＲＲＣ装置２１は、ＣＮ装置１からＲＲＣコネクションの解放が要求されると、下位プロトコル装置(ＲＭＳＣ置２２、ＲＬＣ装置２３、ＭＡＣ装置２４、ＦＰ装置２５)に対して物理チャネル単位でリソースの解放を要求する。リソースの解放を要求された各下位プロトコル装置はそれぞれが使用しているリソースの解放処理を実行する。ここでは、ＲＭＳＣ装置２２のリソース解放処理について図８を用いて説明する。
【００８２】
ＲＭＳＣ装置２２は、ＲＲＣ装置２１からリソース解放要求を受信すると、物理チャネルリソース処理部２２３により指定された物理チャネルが捕捉済みであるか否かを物理チャネルキュー管理部２２９へ問い合わせる。物理チャネルリソース処理部２２３は、物理チャネルキュー管理部２２９の該当する物理チャネルに対応する物理チャネルキュー管理テーブルの捕捉済みフラグを参照することで、指定された物理チャネルが捕捉済みか否かを判定する。指定された物理チャネルが未捕捉であれば何もしない。
【００８３】
一方、指定された物理チャネルが捕捉済みの場合、物理チャネルリソース処理部２２３は、受信バッファのバッファサイズを指定し、物理チャネルキューより受信バッファサイズ毎の連結を維持したまま受信バッファをデキューするようにデキュー処理部２２７へ要求する。
【００８４】
デキュー処理部２２７は、該当する物理チャネルの受信バッファサイズに対応する受信バッファサイズ別物理チャネルキュー管理テーブルを用いて、先頭受信バッファポインタの値から受信バッファ番号を特定する。
【００８５】
このとき、本発明では、図８に示すように、バッファサイズ毎に連結を維持したまま受信バッファをデキューする。そのため、受信バッファサイズキュー用次バッファポインタの値はそのままにする。さらに、該当する物理チャネルのバッファサイズに対応する受信バッファサイズ別物理チャネルキュー管理テーブルのリンク数を「０」に設定し、先頭受信バッファポインタ及び最終受信バッファポインタをそれぞれリンクなし(０ｘＦＦＦＦ)に設定する。このとき、該当する物理チャネルのバッファサイズに対応する受信バッファサイズ別物理チャネルキュー管理テーブルのリンク数、先頭受信バッファポインタ及び最終受信バッファポインタの値をそれぞれ保持しておく。
【００８６】
デキュー処理部２２７は、デキューした受信バッファを空きキューにエンキューするようにエンキュー処理部２２８へ要求する。
【００８７】
エンキュー処理部２２８は、エンキューが要求された受信バッファに対応するバッファサイズの空きキュー管理テーブルを参照し、その最終受信バッファポインタの値から受信バッファを特定する。また、特定した受信バッファの受信バッファサイズキュー用次バッファポインタの値を先に保持した先頭受信バッファの値に書き換える。そして、該当するバッファサイズの空きキュー管理テーブルのリンク数に、先に保持したリンク数を加算し、最終受信バッファポインタを、先に保持した最終受信バッファポインタの値に書き換える。
【００８８】
最後に、物理チャネルキュー管理テーブルの捕捉済みフラグを未捕捉にしてリソースを解放する。
＜エンキュー処理＞
エンキュー処理には、１つの受信バッファを物理チャネルキューにエンキューする処理と、１つの受信バッファを空きキューにエンキューする処理と、複数の受信バッファをそのリンクを維持したまま空きキューにエンキューする処理の３種類がある。
【００８９】
１つの受信バッファを物理チャネルキューにエンキューする場合、エンキュー処理部２２８は、まず該当する物理チャネルの物理チャネルキュー管理テーブルのリンク数を判定する。この値が０である場合は先頭受信バッファポインタと最終受信バッファポインタとに受信バッファの受信バッファ番号を設定し、０でない場合は物理チャネルキュー管理テーブルの最終受信バッファポインタをエンキューする受信バッファの受信バッファ番号に設定する。いずれの場合もリンク数の値を＋１する。さらに、該当する受信バッファのバッファサイズに対応する受信バッファサイズ別物理チャネルキュー管理テーブルのリンク数を判定する。この値が０である場合は先頭受信バッファポインタ及び最終受信バッファポインタをエンキューする受信バッファの受信バッファ番号に設定する。この値が０でない場合は該当するバッファサイズの受信バッファサイズ別物理チャネルキュー管理テーブルの最終受信バッファポインタをエンキューする受信バッファの受信バッファ番号に設定する。いずれの場合もリンク数の値を＋１する。
【００９０】
また、１つの受信バッファを空きキューにエンキューする場合、エンキュー処理部２２８は、該当するバッファサイズの空きキュー管理テーブルのリンク数を判定する。この値が０である場合は先頭受信バッファポインタ及び最終受信バッファポインタをエンキューする受信バッファの受信バッファ番号に設定し、０でない場合は該当するバッファサイズの空きキュー管理テーブルの最終受信バッファポインタをエンキューする受信バッファの受信バッファ番号に設定する。いずれの場合もリンク数の値を＋１する。
【００９１】
複数の受信バッファのリンクを維持したまま空きキューにエンキューする場合、予めエンキューする受信バッファのリンク数、先頭受信バッファポインタ及び最終受信バッファポインタの情報をエンキュー処理部２２８へ渡しておく必要がある。
【００９２】
エンキュー処理部２２８は、これらの情報を基に空きキューに受信バッファをエンキューする。また、該当するバッファサイズのリンク数を判定する。この値が０である場合は先頭受信バッファポインタと最終受信バッファポインタをエンキューする受信バッファの先頭受信バッファポインタ及び最終受信バッファポインタの値に設定し、０でない場合は最終受信バッファポインタをエンキューする受信バッファの最終受信バッファポインタの値に設定する。いずれの場合もリンク数の値はエンキューする受信バッファのリンク数分だけ加算する。
＜デキュー処理＞
デキュー処理には、１つの受信バッファを物理チャネルキューからデキューする処理、１つの受信バッファを空きキューからデキューする処理、複数の受信バッファのリンクを維持したまま受信バッファ別物理チャネルキューからデキューする処理の３種類がある。
【００９３】
１つの受信バッファを物理チャネルキューからデキューする場合、デキュー処理部２２７は、まず該当する物理チャネルの物理チャネルキュー管理テーブルのリンク数を判定する。この値が０である場合は何も実行せず、０でない場合は物理チャネルキュー管理テーブルの先頭受信バッファポインタの値から受信バッファを特定する。そして、デキューする受信バッファの物理チャネルキュー用次バッファポインタの値で、該当する物理チャネルの物理チャネルキュー管理テーブルの先頭受信バッファポインタを書きかえ、リンク数の値を−１する。さらに、デキューする受信バッファの受信バッファサイズキュー用次バッファポインタの値で、該当するバッファサイズの受信バッファサイズ別物理チャネルキュー管理テーブルの先頭受信バッファポインタの値を書きかえ、リンク数の値を−１する。
【００９４】
また、１つの受信バッファを空きキューからデキューする場合、取得する受信バッファサイズを指定する必要がある。デキュー処理部２２７は、指定されたバッファサイズの空きキュー管理テーブルの先頭受信バッファポインタの値から受信バッファを特定する。デキューする受信バッファの受信バッファサイズキュー用次バッファポインタの値で対応するバッファサイズの空きキュー管理テーブルの先頭受信バッファポインタの値を書きかえ、リンク数の値を−１する。そして、受信バッファの物理チャネルキュー用次バッファポインタと受信バッファサイズキュー用次バッファポインタをリンクなし(０ｘＦＦＦＦ)に書き換え、受信バッファのそのほかの要素をクリアする。
【００９５】
また、複数の受信バッファのリンクを維持したまま受信バッファサイズ別物理チャネルキューからデキューする場合、取得する受信バッファサイズを指定する必要がある。また、デキューする受信バッファのリンク数、先頭受信バッファポインタ、最終受信バッファポインタの情報を呼び出し元へ返す必要がある。デキュー処理部２２７は、該当する受信バッファサイズの受信バッファサイズ別物理チャネルキュー管理テーブルのリンク数、先頭受信バッファポインタ、最終受信バッファポインタを取得してそれぞれ保持する。そして、該当する物理チャネルの受信バッファサイズに対応する受信バッファサイズ別物理チャネルキュー管理テーブルのリンク数を０に設定し、先頭受信バッファポインタ及び最終受信バッファポインタの値をリンクなし(０ｘＦＦＦＦ)に設定し、保持した情報を呼び出し元へ返送する。
【００９６】
本発明によれば、様々なバッファサイズを持つ複数種類の受信バッファを用意し、受信したＲＲＣメッセージのデータサイズに合わせて複数種類の受信バッファを組み合わせ、ＲＲＣメッセージを組み合わせた受信バッファに分割して格納するため、様々なデータサイズを持つＲＲＣメッセージを格納するために最大長のメモリ領域を余分に確保する必要がなくなり、メモリを効率的に使用できる。
【００９７】
また、データサイズに合わせて組み合わせた複数の受信バッファにＲＲＣメッセージを分割して格納するため、ＲＲＣメッセージが拡張されている場合でも装置構成を変更することなく該ＲＲＣメッセージを受信できる。
【００９８】
また、受信バッファに、受信バッファサイズキュー用次バッファポインタを設けることで、空きキューをバッファサイズ別に管理し、さらに物理チャネルキュー側では物理チャネル単位、ＲＲＣメッセージ単位だけでなく、受信バッファのバッファサイズ毎に管理しているため、受信バッファをバッファサイズ毎に解放できる。そのため、リソースを容易に一括しで解放できる。したがって、複数の受信バッファへＲＲＣメッセージを格納しているにもかかわらず、物理チャネル単位で一度にリソースを解放でき、処理の高速化が可能になる。
【００９９】
また、受信バッファに、ＲＲＣメッセージ状態及びＲＲＣメッセージの残受信バッファ数の情報を持たせることで、分割したＲＲＣメッセージからＲＬＣ ＰＤＵ（Radio Link Control - Protocol Data Unit）を順次生成できる。そのため、ＲＲＣメッセージから一度にＲＬＣ ＰＤＵを生成する場合に比べて処理時間を短縮できる。
【０１００】
さらに、受信バッファに、物理チャネルキュー用次バッファポインタ及び残受信バッファ数の情報を備えることで、受信バッファどうしの連結を維持したままＲＲＣメッセージ毎に管理できるため、１つのＲＲＣメッセージを複数の受信バッファに分割して格納しても、ＲＬＣ装置におけるＲＬＣ ＰＤＵの生成が可能である。
【０１０１】
なお、上記説明では、ＲＲＣメッセージがＵＭ（Unacknowledge Mode）である場合を想定していたが、本発明はＲＲＣメッセージがＡＭ（Acknowledge Mode）の場合にも適用可能である。また、本発明は、ＲＲＣメッセージ等のメッセージデータに限らず、ＵＤＰ（User Datagram Protocol）データやＩＰ（Internet Protocol）データ等のように、データサイズの変化が大きいＰＤＵを送受信する場合にも適用可能である。
【図面の簡単な説明】
【０１０２】
【図１】本発明のＲＭＳＣ装置を備えた移動通信システムの一構成例を示すブロック図である。
【図２】図１に示した物理チャネルキュー管理部が備える物理チャネルキュー管理テーブルの一構成例を示すテーブル図である。
【図３】図１に示した物理チャネルキュー管理部が備える受信バッファサイズ別物理チャネルキュー管理テーブルの一構成例を示すテーブル図である。
【図４】図１に示した受信バッファに含まれる情報を示すテーブル図である。
【図５】図１に示した空きキュー管理部が備える空きキュー管理テーブルの一構成例を示すテーブル図である。
【図６】図１に示した受信バッファが割り当てられる空きキュー及び物理チャネルキューの関係を示す模式図である。
【図７】図１に示したＲＭＳＣ装置で実行する各キューに対する受信バッファの設定手順を示す模式図である。
【図８】図１に示したＲＭＳＣ装置で実行するリソースの解放時の様子を示す模式図である。
【符号の説明】
【０１０３】
１    ＣＮ装置
２    ＲＮＣ装置
３    基地局装置
４    携帯端末
２１    ＲＲＣ装置
２２    ＲＭＳＣ装置
２３    ＲＬＣ装置
２４    ＭＡＣ装置
２５    ＦＰ装置
２２１    ＲＲＣメッセージ受信部
２２２    受信バッファ送信部
２２３    物理チャネルリソース処理部
２２４    ＲＲＣメッセージ共通受信バッファ
２２５    ＲＲＣメッセージ設定処理部
２２６    受信バッファ組み合わせ処理部
２２７    デキュー処理部
２２８    エンキュー処理部
２２９    物理チャネルキュー管理部
２２Ａ    受信バッファ
２２Ｂ    空きキュー管理部
【図１】
2007043580.tif 000003
【図２】
2007043580.tif 000004
【図３】
2007043580.tif 000005
【図４】
2007043580.tif 000006
【図５】
2007043580.tif 000007
【図６】
2007043580.tif 000008
【図７】
2007043580.tif 000009
【図８】
2007043580.tif 000010