JP4166741B2 - 通信方法 - Google Patents

Description

本発明は、無線インターフェースを有する第一の装置及び第二の装置が通信するための技術に関する。

ＩＥＥＥ８０２．１１等の無線ＬＡＮにおいては、局（ＳＴＡ）とアクセスポイント（ＡＰ）の間でリアルタイムトラフィック(以下ＲＴＴともいう)な制御及び接続情報を交換するために共通の無線媒体が用いられる。

しかしながら、無線媒体であるＡＰでは、非リアルタイムトラフィック(以下ＮＲＴＴ
ともいう)に関しても同様に同一媒体で受信を行う為に、無線媒体の競合が生ずることか
ら、ＲＴＴに対しての品質確保が困難となるという問題がある。

ＲＴＴに対しての品質確保の問題を解決するためのものとして、無線区間を時間で拘束することで、ＲＴＴとＮＲＴＴを分散させることを意図したものがある（特許文献１参照）。これは、ＱｏＳ要請を受け付けた後に、ＡＰ側で利用可能な帯域を管理しておき、競合確認を行いＳＴＡに対して応答を行う方式を用いる。応答情報を元に、ＳＴＡは時間に合わせた送信を行う。

また、ＳＴＡ側で、ＲＴＴとＮＲＴＴのアプリケーションを区分しておき、ＲＴＴに関しては、無線区間に対して毎回リソースの要請を行い、ＡＰ側でリソースの割り当てが可能であれば帯域を割り当てることを行うとともに、複数の要請が存在している場合に、単位時間が要する必要容量と全体が持つ容量との兼ね合いを調整して最適なリソースを帯域に割り当てるものも提案されている（特許文献２参照）。

しかしながら、前者では、無線区間は時間拘束方式で拘束されてしまう事に伴い、ＱｏＳ要請により確保を行った時間に対して、情報が存在しなかった場合に、それらの帯域は効率的に利用できない状況が発生してしまう。また、無線帯域では複数の端末が存在するのが一般的であり、その部分に対して時間拘束を行う方式を採用する場合には電波強度、データロス等の影響を受けてしまうことにより、タイミング合わせ等が困難となる。さらに、同期をあわさなければならない為に、時間的な一致を合わせること自体に複雑な機能を必要となる。

一方、後者では、毎回リソース数の確保を行う必要が発生するという問題がある。また利用リソースを要請する端末側に関しても要請するための、ＲＴＴに関するトラフィック発生情報をもたなければならない為、アプリケーションからの発生情報を監視した後に要請を行う事となる為に、時間的な面でも有利とはいえない。また、複数の端末からの要請がバースト的に発生する可能性があり、発生した場合には、競合処理の計算が複雑化してしまう。

さらに、両者は、ＳＴＡ側からのアクセスがＲＴＴ及び、ＮＲＴＴが同一である為に、不正なアクセスを受けてしまう事で、ＲＴＴが確保できない可能性も残ることとなる。
特開2003-209554号公報 特開2003-169363号公報

本発明の課題は、ＲＴＴ等の特定通信の品質を確保するための技術を提供することにある。

本発明は、上記課題を解決するためになされたものであり、次の構成とした。
無線インターフェースを有する第一の装置及び第二の装置が通信する方法であって、第一の装置が、所定通信パターンを含む通信要素確保要請を送信するステップと、第二の装置が、前記通信要素確保要請が含む所定通信パターンの通信を、自己に割り当てられているリソース量との関係で受け付け可能か否かを判定し、受け付け可能と判定した場合に、新たなアドレスを生成して送信するとともに、この新たなアドレスと前記所定通信パターンとの対応関係を保持するステップと、第一の装置が、所定情報を、前記新たなアドレスを利用して送信するステップと、第二の装置が、前記新たなアドレスを利用して送信された所定情報については、その新たなアドレスに対応する所定通信パターンで転送するステップと、を備える通信方法。

本発明によれば、品質を確保できると判定した場合にのみ、新たなアドレスを生成して第一の装置に送信する。そして、新たなアドレスを利用して送信された所定情報のみが転送されることになる。従って、第一の装置がＲＴＴ等の特定通信を行う場合であっても、その品質（ＱｏＳ）を確保することが可能となる。

上記通信方法においては、例えば、前記新たなアドレスを利用して送信された所定情報をメモリに保持するステップをさらに備え、前記第二の装置は、新たなアドレスに対応する所定通信パターンに従って、前記メモリから所定情報を読み出して転送する。

このようにすれば、第一の装置がＲＴＴ等の特定通信を行う場合であっても、その品質（ＱｏＳ）を確保することが可能となる。また、セキュリティを向上させることが可能となる。

上記通信方法においては、例えば、第二の装置に搭載される機能のうち、データを保持する機能、通信要素確保要請によるデータ収集機能、ネットワークに対して情報を送信する機能のうちすくなくとも１つを、１又は複数の別装置に対して割り当てる。

これは、第二の装置に搭載される機能の分散例を示したものである。
上記通信方法においては、例えば、第二の装置が、第一の装置を受け付けるための送信許容周期情報を付与して送付するステップをさらに備え、第一の装置が付与情報を元に送信許容周期情報を送信することで、第二の装置が保持した情報を送信許容周期情報に従って転送する。

上記通信方法においては、例えば、前記第一の装置は移動通信装置であり、前記第二の装置は無線基地局である、
これは、第一の装置及び第二の装置を例示したものである。従って、第一の装置及び第二の装置はこれらに限定されない。例えば、前記第一の装置は移動通信装置であり、前記第二の装置は移動支援装置（ホームエージェント）であってもよい。

上記通信方法においては、例えば、第一の装置が持つ無線インターフェースは、通常のインターフェースである。
これは第一の装置が持つ無線インターフェースの例示である。従って、第一の装置が持つ無線インターフェースはこれに限定されない。

また、本発明は装置の発明として次のように特定することもできる。
通信要素確保要請を作成する手段と、通信要素確保要請を行うアプリケーションとの関連付けを行う手段と、通信要素確保要請を送信する手段と、通信要素確保要請を受信した装置より新たなアドレスを受信した場合に、関連付けを行ったアプリケーションに関して、新たなアドレスを利用して通信する手段と、を備える通信装置。

上記通信装置においては、例えば、通信要素確保要請を行わなかったアプリケーションに関して、新たなアドレスを利用せずに通信する手段を備える。
また、本発明は装置の発明として次のように特定することもできる。

第二の装置が持つ機能を搭載する、装置が複数存在するネットワークにおいて、複数の第二の装置に対して、通信要素確保要請を行う通信装置。
上記通信装置においては、例えば、さらに通信先の端末の近隣に属する第二の装置に対して通信要素確保要請を行う。

また、上記通信装置においては、例えば、前記通信要素確保要請を送信する手段によりさらに新たな通信要素確保要請を送信することにより、新たなアドレス情報に対するリソース割り当ての変更を行う。

また、上記通信装置においては、例えば、前記通信要素確保要請を送信する手段によりさらに新たな通信要素確保要請を送信することにより、アドレス情報内の割り当て情報を分割して新たに作成したアドレスを追加情報として要請する。

本発明は装置の発明として次のように特定することもできる。
第一の装置から所定通信パターンを含む通信要素確保要請を受信する手段と、前記所定通信パターンに関連付けを行った新たなアドレスを作成する手段と、前記新たなアドレス情報を第一の装置に送信する手段と、を備える通信制御装置。

上記通信制御装置においては、例えば、前記新たなアドレスを作成する手段は、ランダムなアドレスを生成する。
また、上記通信制御装置においては、例えば、前記新たなアドレスには一定時間の制限が設定されている。

また、上記通信制御装置においては、例えば、第一の装置から前記新たなアドレスを利用して送信された所定情報を一定時間保持する手段と、その保持手段から所定通信パターンに基づき所定を収集して転送する手段と、を備える。

また、上記通信制御装置においては、例えば、前記新たなアドレスを第一の装置に送信するときに、さらに第一の装置に対して、第二の装置が収集を行う周期指示情報を付与する。

本発明は、システムの発明として次のように特定することもできる。
無線インターフェースを有する第一の装置及び第二の装置が通信するシステムであって、所定通信パターンを含む通信要素確保要請を送信する第一の装置と、前記通信要素確保要請が含む所定通信パターンの通信を、自己に割り当てられているリソース量との関係で受け付け可能か否かを判定し、受け付け可能と判定した場合に、新たなアドレスを生成して、この新たなアドレスと前記所定通信パターンとの対応関係を保持する第二の装置と、前記新たなアドレスを前記第二の装置から第一の装置に送信する手段と、を備え、前記第一の装置は、所定情報を、前記新たなアドレスを利用して送信し、前記第二の装置は、前記新たなアドレスを利用して送信された所定情報については、その新たなアドレスに対応する所定通信パターンで転送する、通信システム。

また、本発明は、通信制御装置の発明として特定することもできる。
所定情報を送信する装置との間で通信する通信装置であって、前記装置から送信された所定情報を受信する手段と、所定通信パターンを含む所定情報を受信した場合、該所定通信パターンの通信を、自己に割り当てられているリソース量との関係で受け付け可能か否かを判定する手段と、受け付け可能と判定した場合に、新たなアドレスを生成する手段と、この新たなアドレスと前記所定通信パターンとの対応関係を保持する手段と、前記新たなアドレスを前記装置に提供する手段と、前記新たなアドレスを利用して送信された所定情報を受信した場合、該所定情報を、該新たなアドレスに対応する所定通信パターンで転送する手段と、を備える通信制御装置。

また、本発明は通信装置の発明として次のように特定することもできる。
所定通信パターンを含む通信要素確保要請を、第一アドレスを利用して送信する手段と、前記通信要素確保要請が含む所定通信パターンの通信を自己に割り当てられているリソース量との関係で受け付け可能と判定した装置から送信される第二アドレスを受信する手段と、所定情報を、前記第二アドレスを利用して送信する手段と、を備える通信装置。

本発明の原理について図面を参照しながら説明する。
図１は、本発明の原理図を示す。
図１に示すように、本発明の通信方法等が実現されるネットワークシステムは、第一の装置ｍ１と、ネットワークｎ２に接続される第二の装置ｍ２、及び、第一の装置と第二の装置との間の無線通信ネットワークｎ１などを包含する。ネットワークｎ２は、インターネットやクローズドネットワーク等の一般的なネットワークである。

第一の装置ｍ１は、無線通信ネットワークｎ１を介して第二の装置ｍ２との間で通信を行う機能を有する。第一の装置ｍ１は、通信要件確保要請（本発明の所定通信パターンを含む）を第二の装置ｍ２に対して行う（Ｓ１０）。例えば、第一の装置ｍ１においてリアルタイム通信アプリケーションが起動された場合に、第一の装置ｍ１は、通信要件確保要請を第二の装置ｍ２に対して行う。

第二の装置ｍ２は、第一の装置ｍ１からの通信要件確保要請を受信した後に、その要請に基づきネットワーク内で第二の装置ｍ２に割り当てられたリソース情報をもとに、その要請のあったリソース提供の可否について判定し、提供可能であれば通信要件確保要請用のアドレスを生成する（Ｓ１１）。この生成されたアドレスと先ほど受信した通信要件確保要請（本発明の所定通信パターンを含む）との対応関係が要求パターン割当アドレス対応リストに保持される。

第二の装置ｍ２は、その生成したアドレスを第一の装置ｍ１に対して送信する（Ｓ１２）。
第一の装置ｍ１は、そのリアルタイム通信アプリケーションを、第二の装置ｍ２からのアドレスに切り替える（Ｓ１３）。

第一の装置ｍ１のリアルタイム通信アプリケーションは、所定情報を、その切り替えられた新たなアドレスを用いて第二の装置ｍ２に送信する（Ｓ１４）。第二の装置ｍ２は第一の装置ｍ１からの送信内容を受信しこれを保持する（Ｓ１５）。第二の装置ｍ２は、Ｓ１１で生成されたアドレスに対応付けられた通信要件確保要請（本発明の所定通信パターン）を元に、保持情報を収集して（Ｓ１６）、その収集した情報をネットワークに対して送信する（Ｓ１７）。すなわち、第二の装置ｍ２は、第一の装置ｍ１からその新たなアドレスを利用して送信された所定情報については、その新たなアドレスに対応する所定通信パターンで転送することになる。

以上説明したように、図１に示したシステムにおいては、所定通信パターンを含む通信要素確保要請を送信する（Ｓ１０）第一の装置ｍ１と、その通信要素確保要請が含む所定通信パターンの通信を、自己に割り当てられているリソース量との関係で受け付け可能か否かを判定し、受け付け可能と判定した場合に、新たなアドレスを生成して（Ｓ１１）、この新たなアドレスと前記所定通信パターンとの対応関係を保持する第二の装置ｍ２を備えている。新たなアドレスは第二の装置ｍ２から第一の装置ｍ１に送信される（Ｓ１２）。

第一の装置ｍ１は、所定情報を、第二の装置ｍ２からの新たなアドレスを利用して送信する（Ｓ１４）。第二の装置は、新たなアドレスを利用して送信された所定情報を保持し（Ｓ１５）、その保持された所定情報については、その新たなアドレスに対応する所定通信パターンで転送する（Ｓ１６，１７）。

従って、第一の装置ｍ１（リアルタイム通信アプリケーション）が要請した通信の品質を確保することが可能となる。また、通信要件確保要請（本発明の所定通信パターン）に基づいたアドレスで、第一の装置ｍ１を利用することが可能となる。

図２は、本発明の原理図の第二の形態を示す。図２に示すように、第二の装置ｍ２が持つ機能の一部を第三の装置ｍ３に持たせた点が図１と異なる。
第一の装置ｍ１は、通信要件確保要請（本発明の所定通信パターンを含む）を第三の装置ｍ３に対して行う（Ｓ２０）。例えば、第一の装置ｍ１においてリアルタイム通信アプリケーションが起動された場合に、第一の装置ｍ１は、通信要件確保要請を第三の装置ｍ３に対して行う。第三の装置ｍ３は、第一の装置ｍ１からの通信要件確保要請を保持する（図２中保持ａに保持している例を示す）。

第二の装置ｍ２は、第三の装置ｍ３が保持する情報（第一の装置ｍ１からの通信要件確保要請）を周期的に読み出し、その要請に基づきネットワーク内で第二の装置ｍ２に割り当てられたリソース情報をもとに、その要請のあったリソース提供の可否について判定し、提供可能であれば通信要件確保要請用のアドレスを生成する（Ｓ２１）。この生成されたアドレスと先ほど受信した通信要件確保要請（本発明の所定通信パターンを含む）との対応関係が要求パターン割当アドレス対応リストに保持される。

第二の装置ｍ２は、その生成したアドレスを第三の装置ｍ３に対して送信する（Ｓ２２）。
第三の装置ｍ３は、第二の装置ｍ２からのアドレスに対して管理情報の作成（パケット受付の許可、保持対象、保持ｂ機能の構築）を行う（Ｓ２３）。その後、第三の装置ｍ３は、第二の装置ｍ２からのアドレスを第一の装置ｍ１に対して送信する（Ｓ２４）。

第一の装置ｍ１は、そのリアルタイム通信アプリケーションを、第三の装置ｍ３からのアドレスに切り替える（Ｓ２５）。
第一の装置ｍ１のリアルタイム通信アプリケーションは、所定情報を、その切り替えられた新たなアドレスを用いて第三の装置ｍ３に送信する（Ｓ２６）。第三の装置ｍ３は第一の装置ｍ１からの送信内容を受信しこれを保持ｂに保持する（Ｓ２７）。

第二の装置ｍ２は、Ｓ２１で生成されたアドレスに対応付けられた通信要件確保要請（本発明の所定通信パターン）を元に、保持ｂからその保持情報を収集して（Ｓ２８）、その収集した情報をネットワークに対して送信する（Ｓ１９）。すなわち、第二の装置ｍ２は、第一の装置ｍ１からその新たなアドレスを利用して送信された所定情報については、その新たなアドレスに対応する所定通信パターンで転送することになる。

このように、第一の装置ｍ１から新たなアドレスを利用して送信された所定情報を第三の装置ｍ３（保持ｂ）に保持させ、これを第二の装置ｍ２が収集するように構成したことから、コア側のネットワークである、第二の装置ｍ２に対して、第一の装置ｍ１等の端末からのトラフィックの直接的な影響を抑えることが可能となる。
（変形例）
次に、本発明の原理図の第二の形態の変形例について説明する。

図２では、第三の装置ｍ３を前段に設け、第二の装置ｍ２を後段に設けているが、第三の装置ｍ３と第二の装置ｍ２の関係が、ネットワークの端点となってもよい。例えば、第三の装置ｍ３側を第一の装置ｍ１側の近隣に設け、第二の装置ｍ２側を第一の装置ｍ１との通信を行う新たな装置の近隣に設けることが想定できる。この場合、第一の装置ｍ１の近隣側の通信処理ではなく、新たな端末側との通信を行うのに適した間隔（ギャップ）サイズを確保することが容易となる。

また、第三の装置ｍ３が第二の装置ｍ２であった場合、つまり、多段構成で第二の装置ｍ２が構成されている場合には、前段ｍ２側で、ネットワークリソース面での選択フィルタリング機能を提供して、後段ｍ２側で、間隔面での品質保証を行わせることも可能となる。

また、図１のＳ１１及び図２のＳ２１で生成されるアドレスについては、例えば、図３に示すように、第二の装置ｍ２にランダムアドレス生成部を設け、これにより生成される乱数を用いてアドレスを生成する（２-ａ）とともに、管理アドレスとの関連付けを行う
ようにしてもよい。このようにすれば、変動アドレスを払い出す事が可能となることから、セキュリティ面で強固な構成を構築することが可能となる。

また、図４に示すように、図２又は図３に示した構成に加えてさらに、第一の装置ｍ１の非リアルタイムであるアプリケーション（又は通信要件確保要請を用いないアプリケーション）から（新たなアドレス以外のアドレスを利用して）送信される（Ｓ３０）所定情報を第三の装置ｍ３（保持ｃ）に保持させ（Ｓ３１）、これを第二の装置ｍ２がリソースに空きがあるときに収集し（Ｓ３２）その収集した情報をネットワークに対して送信する（Ｓ３３）ようにしてもよい。

なお、Ｓ３０〜Ｓ３３の処理は、図２又は図３に示したＳ２０〜Ｓ２９の処理と並列的に動作させることが考えられる。
図５は、本発明の原理図の第三の形態を示す。図５に示すように、第三の装置ｍ３の機能を持つ装置が１つ以上あった場合の例でかつ、第二の装置ｍ２により提供されるアドレスが、第四の装置ｍ４に分割して処理を行わせる構成となっている。

第一の装置ｍ１は、通信要件確保要請（本発明の所定通信パターンを含む）を第三の装置ｍ３に対して行う（Ｓ４０）。例えば、第一の装置ｍ１においてリアルタイム通信アプリケーションが起動された場合に、第一の装置ｍ１は、通信要件確保要請を第三の装置ｍ３に対して行う。第三の装置ｍ３は、第一の装置ｍ１からの通信要件確保要請を保持する（図５中保持ａに保持している例を示す）。

第二の装置ｍ２は、第三の装置ｍ３が保持する情報（第一の装置ｍ１からの通信要件確保要請）を周期的に読み出し、その要請に基づきネットワーク内で第二の装置ｍ２に割り当てられたリソース情報をもとに、その要請のあったリソース提供の可否について判定し、提供可能であれば通信要件確保要請用のアドレスを生成する（Ｓ４１）。この生成されたアドレスと先ほど受信した通信要件確保要請（本発明の所定通信パターンを含む）との
対応関係が要求パターン割当アドレス対応リストに保持される。

第二の装置ｍ２は、Ｓ４１で生成したアドレスを第四の装置ｍ４に対して送信する（Ｓ４２）。
第四の装置ｍ４は、第二の装置ｍ２からのアドレスに対して管理情報の作成（パケット受付の許可、保持対象、保持ｄ機能の構築）を行う（Ｓ４３）。この時にアドレスの通知無しを要求してアドレスを送信する。

第二の装置ｍ２は、アドレスの生成無しで通知（指示）を第三の装置ｍ３に対して行う（Ｓ４４）。第三の装置ｍ３は、第二の装置ｍ２からのアドレスを第一の装置ｍ１に対して送信する（Ｓ４５）。

第一の装置ｍ１は、そのリアルタイムアプリケーションを、第三の装置ｍ３からのアドレスに切り替える（Ｓ４６）。
第一の装置ｍ１のリアルタイム通信アプリケーションは、所定情報を、その切り替えられた新たなアドレスを用いて第四の装置ｍ４に送信する（Ｓ４７）。第四の装置ｍ４は第一の装置ｍ１からの送信内容を受信しこれを保持ｄに保持する（Ｓ４８）。

第二の装置ｍ２は、Ｓ４１で生成されたアドレスに対応付けられた通信要件確保要請（本発明の所定通信パターン）を元に、保持ｄからその保持情報を収集して（Ｓ４９）、その収集した情報をネットワークに対して送信する（Ｓ５０）。

なお、第一の装置ｍ１の非リアルタイムであるアプリケーション（又は通信要件確保要請を用いないアプリケーション）から（新たなアドレス以外のアドレスを利用して）送信される（Ｓ５１）所定情報を第三の装置ｍ３（保持ｃ）に保持させ（Ｓ５２）、これを第二の装置ｍ２がリソースに空きがあるときに収集し（Ｓ５３）その収集した情報をネットワークに対して送信する（Ｓ５４）ようにしてもよい。

なお、Ｓ５１〜Ｓ５４の処理は、Ｓ４０〜Ｓ４９の処理と並列的に動作させることが考えられる。
以上説明したように、図５に示したシステムにおいては、明示的に空きのあるネットワーク側を用いて、通信要件要請にあった処理を分離することができるために、第三の装置ｍ３に対して不正な負荷をかけられた場合でも、第四の装置ｍ４が独立して動作するために無線品質を確保した通信が可能となる。

図６を参照しながら第一の装置ｍ１の構成例について説明する。図６は、第一の装置ｍ１の機能ブロック図である。
図６に示すように、第一の装置ｍ１は、通信を行う為の受信機能ｃ１、送信機能ｃ２、受信情報識別ｃ３、アドレス生成機能ｃ４、アプリケーション管理テーブルｃ５、タイマー機能ｃ６、リアルタイムアプリケーションｃ７、非リアルタイムアプリケーションｃ８などを備えている。

第一の装置ｍ１は、受信情報識別機能ｃ３により、制御用の信号か否かに関して識別を行う。そして、第一の装置ＭＮｍ１は、制御用の信号の場合に、アドレス生成機能ｃ４内で、ルータ広告（ＲＡ）を受信した場合にアドレス（ＣｏＡ）を生成する。このアドレス生成に関しては、ＤＨＣＰ等によりアドレスを受信する機能となっていてもよいが、ここでは、モバイルＩＰを想定しているのでルータ広告としている。

また、アプリケーション管理テーブル（図８参照）ｃ５に関しては、通信要素確保要請により送信を行った結果、情報等を受けた場合に、転送を行う。アプリケーション管理テ
ーブルｃ５は、通信要素確保要請を行ったときに、タイマー情報があった場合には、タイマー監視を行う。また、通信要素確保要請によりアドレス（ＲＣｏＡ）を受信した場合には、アドレス生成機能ｃ４に対して、該当のアドレス生成を行い、アプリケーション管理テーブルｃ５上のＲＣｏＡフィールド部分に該当アドレスを保持する。

また、通常の通信アプリケーションデータの場合には、該当のアドレス情報に関連したリアルタイムアプリケーションｃ７、非リアルタイムアプリケーションｃ８に対して中継機能を行う。

リアルタイムアプリケーションｃ７及び、非リアルタイムアプリケーションｃ８からの送信処理に関しては、アプリケーション管理テーブルｃ５上で対応付けを行ったアドレスを用いて通信を行う。

また、第二の装置ｍ２より周期送信要請処理が受信情報識別機能ｃ３経由できた場合には、その周期送信要請を保持して端末からデータを送信するときにその情報を送信する。
図７を参照しながら第二の装置ｍ２の構成例について説明する。図７は、第二の装置ｍ２の機能ブロック図である。

図７に示すように、第二の装置ｍ２は、通信を行う為の受信機能ｂ１、送信機能ｂ２、バッファ管理情報ｂ３、リソース管理機能ｂ４、タイマー機能ｂ５、アドレス管理機能ｂ６、要求パターン割り当てアドレス対応リストｂ７、フィルタリング管理機能ｂ８などを備えている。

第二の装置ｍ２は、バッファ管理情報ｂ３により、受信機能ｂ１からの情報を保持する。ここでバッファは、通信要件確保要請を保持する為の共通制御バッファと、通信要件要請を用いない情報を保持するための共通データバッファ、個別アドレス単位で動的に管理するための個別バッファの３種類からなる。

リソース管理機能ｂ４は、バッファを周期的に監視しその格納情報を収集する。
タイマー機能ｂ５は、各種時間周期や、第一の装置ｍ１からの通信要件要請の内容によって各種タイミングを取る。

アドレス管理機能ｂ６は、リソース管理機能ｂ４からの要請を受けてアドレスの生成を行い、その生成したアドレスをソース管理部ｂ４へ送信する。
要求パターン割り当てアドレス対応リストｂ７は、リソース管理機能ｂ４が第一の装置ｍ１からの要請を受けた要求パターンと、その要求パターンに対して割り当てたアドレスを管理するためのリストである。

リソース管理機能ｂ４は提供期間に制限を設けることができる。タイマー機能ｂ５を用いて有効期間を管理する。また該当アドレスに関して受付を許可して、個別バッファに格納させるために、フィルタリング管理機能ｂ８に対してアドレスの登録を行う。その後に、バッファ管理情報ｂ３に対して、個別バッファの生成要求を行い、送信機能ｂ２を用いてアドレスを送信する。

本発明によれば、ＲＴＴ等の特定通信の品質を確保することが可能となる。また、ネットワークのコア部分に関して、自在なプロトコルを用いる事が可能となること、更にネットワーク側が望むアドレスのみで制御が可能な点を設けることによる、セキュリティ面の向上と要求するポリシーが明確に分類することが可能となる。さらに、中継処理側で保持する情報を開けるゲートとして用いる事で、送信側に関して意識的な時間管理を行わせる
事が可能となる。また、無線区間に関しては無駄に無効な要求を送信させることを抑止することが可能となる。さらに、ネットワークを連携させる方法や、負荷を分散させて管理することも容易となる。また、通信に本方式を用いると通信相手側の直前で保証させるべき情報を提供することができるために、ギャップサイズに関しても他の方式と比べて優位となる。

以下、本発明の実施形態であるネットワークシステムについて図面を参照しながら説明する。図９は、本発明の実施形態であるネットワークシステムの概略構成を説明するための図である。

図９に示すように、本ネットワークシステムは、移動通信端末ｍ１、リソース管理エージェント（ＲＭＡ）ｍ２、バッファリング用フィルタ機能搭載ルータｍ３、アクセスポイント（ＡＰ）ｍ３-1、バッファｍ３−２、バッファｍ３−３、バッファｍ３−４、ネットワークｎ１〜ｎ３などを包含する。

移動通信端末（以下ＭＮともいう。）ｍ１は、Mobile Node(以降：MNという)または、Station(以降: STAという)であり、RTTとNRTTで利用アドレスを別々に利用できる機能を持つ。

リソース管理エージェント（以下ＲＭＡともいう）ｍ２は、移動通信端末ｍ１側への送信リソース量を把握する機能を持ち、各ｍ３に対して自分が管理している領域に対して情報を獲得する処理と、情報を転送するためのアドレス管理機能からなる。

バッファリング用フィルタ機能搭載ルータ（以下ＢＦＲともいう）ｍ３は、３つの機能を持つバッファ（ｍ３−２、ｍ３−３、ｍ３−４）からなる。
アクセスポイント（ＡＰ）ｍ３-1は、移動通信端末ｍ１からのデータをネットワークｎ３に対して転送する機能を持つ。以下の説明では、ＢＦＲｍ３が本機能を含むものとする。

バッファｍ３−２は、共通ＱｏＳを受け付けるバッファ（以下共通受付バッファともいう）である。バッファｍ３−３は、個別アドレスを管理して、アドレス毎に管理を行うバッファである（以下個別バッファともいう）。バッファｍ３−４は、共通データ送信バッファである（以下共通データ送信バッファともいう）。

ネットワークｎ１は、移動通信端末ｍ１がアクセスを行う時に属するネットワークである。ネットワークｎ２は、無線通信区間である。ネットワークｎ３は、ネットワークのバックボーンである。
（通信要求振り分け処理）
通信要求振り分け処理について図１０を参照しながら説明する。

以下の説明においては、ＢＦＲｍ３がＲＭＡｍ２に組み込まれて一体的に構成されているものとする（図１に対応）。
アクセスルータの機能を併せ持つＲＭＡｍ２は、所定タイミングでルータ広告を送信する（Ｓ１００）。

ＭＮｍ１は、それを用いて、気付けアドレスＣｏＡを作成する（Ｓ１０１）。ＭＮｍ１は、通信要素確保要請（リアルタイムアプリケーションの特性要件）を生成する。ＭＮｍ１は、その通信要素確保要請を、Ｓ１０１で作成したアドレスＣｏＡを用いてＲＭＡｍ２に送信する（Ｓ１０２）。

通信要請確保要請は、図８に示す周期、時間、パターン（本発明の所定通信パターンに相当）のうちの少なくとも一つを含む。例えば、図１１は、通信要素確保要請として、周期＝ＯＮ、時間＝０（直ちに）、パターン＝０１０３，０８１２，１８２１，２４２７，００００を、ＭＮｍ１からＲＭＡｍ２に送信する例を表す。このパターンは、ＭＮｍ１とＲＭＡｍ２の間のリソースとして図１２に示すように３０のリソース（図１２中の一つのボックスが一つのリソースを表す）が存在していることを表す。パターン中の０１０３は、３０のリソース中、０１番目から０３番目までの３つのリソースを、０８１２は、０８番目から１２番目までの５つのリソースを、１８２１は、１８番目から２１番目までの４つのリソースを、２４２７は、２４番目から２７番目までの４つのリソースを、それぞれ、要求していることを表す。なお、００００は、要求が終わったことを表す。なお、ここに示したパターンは利用したい位置に関して数値化した例である。また、ここに示す時間は本来の時間、又は、上記数値化した数値のカウンタ情報の何れでもよい。

ＲＭＡｍ２は、ＭＮｍ１からの通信要素確保要請（要求条件）については、ＣｏＡアドレスを含んでおり、かつ、制御信号（周期等）を含んでいることから、この通信要素確保要請を共通制御バッファに格納する（Ｓ１０３）。

ＲＭＡｍ２は、周期的に共通制御バッファから通信要素確保要請を読み出す（Ｓ１０４）。
ＲＭＡｍ２は、自己が保持するリソース管理テーブルを参照して、自己に割り当てられたリソースをもとに、受付パターン解析して受付が可能か否かを判定する。そして受付可能と判断すると、アクセスアドレスを生成して払い出す。

この動作の例を図１１及び図１２を参照しながら説明する。なお、図１１中の番号と図１２中の番号とは共通のものを使用している。(1)（図１１及び図１２中丸数字で示す。
以下も同じ。）では、ＲＭＡｍ２がネットワークに割り当てられた帯域量をさしており、この場合、３０のリソースを持つ事となる。(2)では、ＭＮｍ１からのリソース要請（所
定通信パターン）がこのパターンで要請する処理であり、ＲＭＡｍ２は割り当てが可能である為に、この要求パターンを保持して、このパターンに対応したアドレス（後述のＲＣｏＡ）をＭＮｍ１に送信する。

(3)はＲＭＡｍ２がもつリソースの残帯域を表す。(4)ではＭＮｍ１から新たなリソース要請が送信されたケースであり、ＲＭＡｍ２では該当処理をそのまま割り当てる事ができない為に、(5)時間軸をずらしてパターンが割りあたる部分を探す。この場合、１つ後ろ
へずらしたことを表す。この要求パターンを後述のように保持して、このパターンに対応したアドレス（後述のＲＣｏＡ）をＭＮｍ１に送信する。(6)はＲＭＡｍ２が持つリソー
スの残帯域を表す。

(7)ではＭＮｍ１から新たなリソース要請が送信されたケースであるが、ＲＭＡｍ２は
要求を満足する帯域がないために、アドレスを返送しないことにより、受付を拒否する。
また、図１１におけるリソース割り当て管理処理にて、該当処理をアドレスと関連つける処理を記載している。

なお、捕足ではあるが、パターンを要求するときに、ＭＮｍ１からの要求に対して要請時間の幅を持たせる事で、ＲＭＡｍ２が管理するリソース配分が行いやすくなる事となり、該当のリソースパターンが始められる迄の時間を返送する事で、リソース要請が頻発する事を防いでもよい。払いだされたアドレスはＭＮｍｎ１側で追加で作成されることとなる。ＭＮｍ１では、リアルタイムなアプリケーションに関してのアプリケーションデータを払い出されたアドレスを用いることとなる。また、払い出されたアドレスに関しては、
ＲＭＡ側にて、バッファの作成を行い内部で決めたタイミングにより、データをネットワークに対して送信する動作を行うことにより、リアルタイムな通信を実現する。また、非リアルタイムな情報に関しては、以前のアドレスを用いることで変更なしに利用することが可能となる。これらについてはいずれも後述する。

以上のようにして、受付可能か否かが判断される。
リソース管理テーブル（図１３参照）は、図１１に示すように、パターン０１３０，００００を保持する。このパターンは、図１１に示すように３０のリソースがＲＭＡｍ２に割り当てられていることを表す。

ＲＭＡｍ２は、受付可能な場合に、パターンをネットワーク側で処理させるための、一意の貸し出しアドレス（ＲＣｏＡ）を生成する（Ｓ１０５）。
なお、Ｓ１０５で生成されるアドレス（ＲＣｏＡ）については、図１５に示すように、ランダムアドレスを生成して（Ｓ１０５）、これを自己が管理しているアドレスに対して関連付けて保持する（Ｓ１０５）ようにしてもよい。これにより、常に一定のアドレス利用を行わない事となる為に、セキュリティを強固にすることが可能となる。

また、Ｓ１０５のアドレスの生成の際に、そのアドレスの有効時間を設定するようにしてもよい（図１６参照）。
ＲＭＡｍ２は、この生成されたＲＣｏＡと先ほど受信した通信要件要請（有効時間を設定した場合はこれも。図１６参照。）とを図１４に示すバッファ管理テーブルに登録する。バッファ管理テーブル（図１４参照）には、図１１に示すように、例えば、「ＯＮ／０／０１０３，０８１２，１８２１，２４２７，００００／ＲＣｏＡ−１／０」を保持する。図１４中、「ＲＣｏＡ−１」が生成されたＲＣｏＡを、「ＯＮ／０／０１０３，０８１２，１８２１，２４２７，００００」が受信した通信要件確保要請を、それぞれ表す。

また、ＲＭＡｍ２は、管理ＣｏＡ情報に対して、割り当てＲＣｏＡを保持（Ｓ１０６）した後に、該当ＲＣｏＡからの送信を受け付ける（保持する）ための個別バッファを作成し、及び、ＭＮｍ１に対してＲＣｏＡ（有効時間を設定したときはこれも。図１６参照。）を送信する（Ｓ１０７）。なお、有効時間を設定したときは、例えば、図１４に示すように個別バッファ（参照Ｂｌｋ）にその有効時間が格納されることとなり、この有効時間のみ該当アドレスからの要求を受け付けることとなる。有効時間が経過した場合、管理情報を開放する。

ＭＮｍ１は、ＲＭＡｍ２からのアドレスＲＣｏＡを受け取った後に、自己のアプリケーション管理テーブルにそのＲＣｏＡを（作成して）登録する（Ｓ１０８）。これにより、通信要件要請で用いたリアルタイムなアプリケーションとのアドレス関係がＣｏＡからＲＣｏＡへ変更される。

すなわち、以後、そのリアルタイムなアプリケーションは、データ（本発明の所定情報に相当）を、ＲＣｏＡを用いてＲＭＡｍ２に送信することになる（Ｓ１０９）。なお、有効時間もともに受信した場合には、例えば、その有効時間経過前に、図１７に示すように更新要求を行うことが可能となる。

ＲＭＡｍ２は、ＭＮｍ１（リアルタイムなアプリケーション）からのデータについては、ＲＣｏＡアドレスを含んでいることから、そのデータを、先ほどＲＣｏＡ用に個別に生成した個別バッファに一時的に格納（保持）する（Ｓ１１０）。図１３に、個別バッファの格納例を示す。ＭＮｍ１からのデータについては、ｍ１送信メッセージ１・・ｍ１送信メッセージ（ｍ１からのデータ）ｎのように保持する。

ＲＭＡｍ２は、ＲＣｏＡを生成するときの条件情報をもとに、特定周期に基づき個別バッファの情報を読み出す。例えば、図１１に示すように、バッファ管理テーブルに、ＲＣｏＡとして「ＲＣｏＡ−１」が、パターンとして「ＯＮ／０／０１０３，０８１２，１８２１，２４２７，００００」が、登録されている場合には、ＲＣｏＡ−１の個別バッファ（参照Ｂｌｋ）からｍ１送信メッセージを、その特定周期「ＯＮ／０／０１０３，０８１２，１８２１，２４２７，００００」で読み出す（Ｓ１１１）。

ＲＭＡｍ２は、その特定周期で読み出したデータをその先のネットワークへ送信する（Ｓ１１２）。
次に、非リアルタイムなアプリケーションの処理について説明する。

非リアルタイムなアプリケーションは、データを、ＲＣｏＡではなくＣｏＡを用いてＲＭＡｍ２に送信することになる（Ｓ１１３）。これは、通信要素確保要請を用いない通信処理である。

ＲＭＡｍ２は、ＭＮｍ１（非リアルタイムなアプリケーション）からのデータについては、ＣｏＡアドレスを含んでいるが、制御信号（周期等の通信要素確保要請）を含んでいないことから、共通バッファに格納する（Ｓ１１４）。

ＲＭＡｍ２は、自己が保持するリソース管理テーブルを参照して、通信リソースに空きがある場合に、共通バッファからその格納データを読み出し、その読み出したデータをその先のネットワークへ送信する（Ｓ１１５）。

なお、Ｓ１０２〜Ｓ１１２の処理とＳ１１３〜Ｓ１１５の処理とを、同時に実行することも考えられる。
以上説明したように、図９に示したシステムにおいては、所定通信パターンを含む通信要素確保要請を送信する（Ｓ１０２）ＭＮｍ１と、その通信要素確保要請が含む所定通信パターンの通信を、自己に割り当てられているリソース量との関係で受け付け可能か否かを判定し、受け付け可能と判定した場合に、新たなアドレスを生成して（Ｓ１０５）、この新たなアドレスと前記所定通信パターンとの対応関係を保持するＲＭＡｍ２を備えている。新たなアドレスはＲＭＡｍ２からＭＮｍ１に送信される（Ｓ１０７）。

ＭＮｍ１は、所定情報を、ＲＭＡｍ２からの新たなアドレスを利用して送信する（Ｓ１０９）。ＲＭＡｍ２は、新たなアドレスを利用して送信された所定情報を保持し（Ｓ１１０）、その保持された所定情報については、その新たなアドレスに対応する所定通信パターンで転送する（Ｓ１１１、Ｓ１１２）。

従って、ＭＮｍ１（リアルタイム通信アプリケーション）が要請した通信の品質を確保することが可能となる。また、通信要件確保要請（本発明の所定通信パターン）に基づいたアドレスで、ＭＮｍ１を利用することが可能となる。

また、ネットワーク側でＲＴＴに関するリソース制御を行うものに関して明示的に指定を与えるとともに、それらに対してバッファリング機能とさらにバッファリング機能により蓄えられた情報に関して、ゲート機能用いて単位時間の獲得を行うことで、ＮＲＴＴと、ＲＴＴの処理を明示的に分離するとともに、ネットワーク側での管理となる。従って、単一ユーザーが独占状態に陥るのを避けること、品質を確保するときにユーザーが送信処理を行う情報や、その情報をネットワークへ対して送信する制御をＭＮｍ１が主導的な動作でネットワーク側に送り込めないこととなる。

また、ネットワーク側でＭＮｍ１のＲＴＴをサポートすることが可能となる。すなわち
、ネットワーク側で特定のアドレス（図１０中ＲＣｏＡ）を払い出すときに、制御要求とは別のＡＰ（図１０中ＲＭＡｍ２）が持つアドレスプレフィックスのデータを送信する（Ｓ１０７）ことにより、制御処理でＲＴＴ処理を明確に別ネットワークに分離することが可能となる。また、複数のＭＮｍ１が存在する場合でもこれらを効率的に管理することが可能となる。
（リソース更新要請）
Ｓ１０８でＭＮｍ１がＲＣｏＡを作成している場合に、さらにそのＲＣｏＡに関して新たな通信要素確保要請（または、継続）を行うと、再度Ｓ１０２〜Ｓ１０７と同様のルートを用いてアドレスの獲得を行うこととなる。この処理について図１７を参照しながら説明する。

ＭＮｍ１は、通信要素確保要請（リアルタイムアプリケーションの特性要件）を生成する。ＭＮｍ１は、その通信要素確保要請（図１７中通信要素確保要請-2で表す）を、Ｓ１０１で作成したアドレスＣｏＡを用いてＲＭＡｍ２に送信する（Ｓ１０２−１）。

ＲＭＡｍ２は、ＭＮｍ１からの通信要素確保要請（要求条件）については、ＣｏＡアドレスを含んでおり、かつ、制御信号（周期等）を含んでいることから、この通信要素確保要請を共通制御バッファに格納する（Ｓ１０３−１）。

ＲＭＡｍ２は、周期的に共通制御バッファから通信要素確保要請を読み出す（Ｓ１０４−１）。
ＲＭＡｍ２は、自己が保持するリソース管理テーブルを参照して、自己に割り当てられたリソースをもとに、受付パターン解析して受付が可能か否かを判定する。

ＲＭＡｍ２は、受付可能な場合に、パターンをネットワーク側で処理させるための、一意の貸し出しアドレス（同一のＲＣｏＡ）を生成する（Ｓ１０５―１）。
ＲＭＡｍ２は、この生成されたＲＣｏＡと先ほど受信した通信要素確保要請（有効時間を設定した場合はこれも。図１６参照。）とを図１４に示すバッファ管理テーブルに登録する。

また、ＲＭＡｍ２は、管理ＣｏＡ情報に対して、割り当てＲＣｏＡを保持（Ｓ１０６−１）した後に、該当ＲＣｏＡからの送信を受け付ける（保持する）ための個別バッファを作成し、及び、ＭＮｍ１に対してＲＣｏＡ（有効時間を設定したときはこれも。図１６参照。）を送信する（Ｓ１０７−１）。

ＭＮｍ１は、ＲＭＡｍ２からのＲＣｏＡを受け取った後に、自己のアプリケーション管理テーブルにそのＲＣｏＡを（作成して）登録する（Ｓ１０８−１）。これにより、通信要件要請で用いたリアルタイムなアプリケーションとのアドレス関係がＣｏＡからＲＣｏＡへ変更（上書き）される。

すなわち、以後、そのリアルタイムなアプリケーションは、データを、ＲＣｏＡを用いてＲＭＡｍ２に送信することになる（Ｓ１０９−１）。
（複数通信要素確保処理）
上述のように、貸出アドレスとして１つのＲＣｏＡを生成する（Ｓ１０５）例について説明したが、これに限定されることなく、次のようにしてもよい。例えば、図１８に示すように、複数（図１８では２つを例示）の貸出アドレスＲＣｏＡ、ＲＣｏＡ−２を生成して（Ｓ１０５）、これらをバッファ管理テーブルに登録し、管理ＣｏＡ情報に対して、割り当てＲＣｏＡを保持（Ｓ１０６）した後に、該当ＲＣｏＡからの送信を受け付ける（保持する）ための個別バッファを作成し、及び、ＭＮｍ１に対してＲＣｏＡ（有効時間を設定したときはこれも。図１６参照。）を送信するようにしてもよい（Ｓ１０７）。

このように、ネットワークを中継して別の端末とのリアルタイムな通信を行う場合に複数のアドレスと帯域をネットワークに対して要請を行う通信が可能な条件が通信先の端末とのネゴシエーションにより整った場合に該当アドレスを払い出すことが可能となっている。 この機能により、通信相手との保証された通信をネットワーク側が提供することが
可能となる。
（バッファ管理装置中継処理）
次に、バッファ管理装置中継処理について図１９を参照しながら説明する。

以下の説明においては、ＢＦＲｍ３とＲＭＡｍ２とが別体で構成されているものとする（図２に対応）。
ＢＦＲｍ３は、所定タイミングでルータ広告を送信する（Ｓ２００）。ＭＮｍ１は、それを用いて、気付けアドレスＣｏＡを作成する（Ｓ２０１）。

ＭＮｍ１は、通信要素確保要請（リアルタイムアプリケーションの特性要件）を生成する。ＭＮｍ１は、その通信要素確保要請を、Ｓ２０１で作成したアドレスＣｏＡを用いてＢＦＲｍ３に送信する（Ｓ２０２）。

ＢＦＲｍ３は、ＭＮｍ１からの通信要素確保要請（要求条件）については、ＣｏＡアドレスを含んでおり、かつ、制御信号（周期等）を含んでいることから、この通信要素確保要請を共通制御バッファに格納する（Ｓ２０３）。

ＲＭＡｍ２は、周期的に共通制御バッファから通信要素確保要請を読み出す（Ｓ２０４）。
ＲＭＡｍ２は、リソース管理テーブルを参照して、該当ｍ３に割り当てられたリソースをもとに、受付パターンを解析して受付が可能か否かを判定する。

ＲＭＡｍ２は、受付可能な場合に、パターンをネットワーク側で処理させるための、一意の貸し出しアドレス（ＲＣｏＡ）を生成する（Ｓ２０５）。ＲＭＡｍ２は、この生成されたＲＣｏＡと先ほど受信した通信要件要請とを図１４に示すバッファ管理テーブルに登録する。また、ＲＭＡｍ２は、管理ＣｏＡ情報に対して、割り当てＲＣｏＡを保持（Ｓ２０６）した後に、ＢＦＲｍ３にアドレス通知を行う（Ｓ２０７）。

ＢＦＲｍ３は、該当ＲＣｏＡアドレスからの送信を受け付ける（保持する）ための個別バッファを作成し、ＭＮｍ１に対してＲＣｏＡを送信する（Ｓ２０８）。
ＭＮｍ１は、ＲＭＡｍ２からのアドレスＲＣｏＡを受け取った後に、自己のアプリケーション管理テーブルにそのＲＣｏＡを登録する（Ｓ２０９）。これにより、通信要件要請で用いたリアルタイムなアプリケーションとのアドレス関係がＣｏＡからＲＣｏＡへ変更される。

すなわち、以後、そのリアルタイムなアプリケーションは、データ（本発明の所定データに相当）を、ＲＣｏＡを用いてＲＭＡｍ２に送信することになる（Ｓ２１０）。
ＲＭＡｍ２は、ＭＮｍ１（リアルタイムなアプリケーション）からのデータについては、ＲＣｏＡアドレスを含んでいることから、そのデータをＲＣｏＡ用に個別に生成した個別バッファに一時的に格納（保持）する（Ｓ２１１）。図１３に、個別バッファの格納例を示す。ＭＮｍ１からのデータについては、ｍ１送信メッセージ１・・ｍ１送信メッセージ（ｍ１からのデータ）ｎのように保持する。

ＲＭＡｍ２は、ＲＣｏＡを生成するときの条件情報をもとに、特定周期に基づきＢＦＲｍ３の個別バッファの情報を読み出す。例えば、図１１に示すように、バッファ管理テー
ブルに、ＲＣｏＡとして「ＲＣｏＡ−１」が、パターンとして「ＯＮ／０／０１０３，０８１２，１８２１，２４２７，００００」が、登録されている場合には、ＲＣｏＡ−１の個別バッファ（参照Ｂｌｋ）からｍ１送信メッセージを、その特定周期「ＯＮ／０／０１０３，０８１２，１８２１，２４２７，００００」で読み出す（Ｓ２１２）。

ＲＭＡｍ２は、その特定周期で読み出したデータをその先のネットワークへと送信する（Ｓ２１３）。
次に、非リアルタイムなアプリケーションの処理について説明する。

非リアルタイムなアプリケーションは、データを、ＲＣｏＡではなくＣｏＡを用いてＢＦＲｍ３に送信することになる（Ｓ２１４）。これは、通信要素確保要請を用いない通信処理である。

ＢＦＲｍ３は、ＭＮｍ１（非リアルタイムなアプリケーション）からのデータについては、ＣｏＡアドレスを含んでいるが、制御信号（周期等の通信要素確保要請）を含んでいないことから、共通バッファに格納する（Ｓ２１５）。

ＲＭＡｍ２は、自己が保持するリソース管理テーブルを参照して、通信リソースに空きがある場合に、共通バッファからその格納データを読み出し、その読み出したデータをその先のネットワークへ送信する。
（周期ルックインイネーブル予約処理）
次に、周期ルックインイネーブル要請処理について図２０を参照しながら説明する。本処理は、図１９のＳ２００〜Ｓ２０７の後に行われる処理であって、図２０ではＳ３００以降の処理である。

ＲＭＡｍ２は、ＲＣｏＡを返送するとともに、ＭＮｍ１側から送信データに対しての制御情報であるlook-in-Cycle情報を送信する（Ｓ３００）。このlook-in-Cycle情報は、例えば、ＭＮｍ２が、リソース管理テーブルを参照して、データが送信可能なリソース位置に１、それ以外の位置に０、を設定することで作成する（図２０に示すビット列参照）。

ＭＮｍ１は、ＲＭＡｍ２からのＲＣｏＡを受け取った後に、自己のアプリケーション管理テーブルにそのＲＣｏＡを登録する（Ｓ３０１）。これにより、通信要件要請で用いたリアルタイムなアプリケーションとのアドレス関係がＣｏＡからＲＣｏＡへ変更される。

すなわち、以後、そのリアルタイムなアプリケーションは、データを、ＲＣｏＡを用いてＲＭＡｍ２に送信することになる（Ｓ３０２）。
ＲＭＡｍ２は、ＭＮｍ１（リアルタイムなアプリケーション）からのデータについては、ＲＣｏＡアドレスを含んでいることから、そのデータをＲＣｏＡ用に個別に生成した個別バッファに一時的に格納（保持）する（Ｓ３０３）。図１３に、個別バッファの格納例を示す。ＭＮｍ１からのデータについては、ｍ１送信メッセージ１・・ｍ１送信メッセージ（ｍ１からのデータ）ｎのように保持する。

ＭＮｍ１は、Look-in-cycle情報をＢＦＲｍ３に送信することで、データの送信タイミ
ングをＢＦＲｍ３に対して要請する（Ｓ３０４）。ＢＦＲｍ３は、個別バッファからその格納データを Look-in-cycle情報のタイミングで読み出し、ＲＭＡｍ２に送信する（Ｓ３０５）。ＲＭＡｍ２は、ＢＦＲｍ３からのデータをその先のネットワークへと送信する（Ｓ３０６）。

次に、非リアルタイムなアプリケーションの処理について説明する。
非リアルタイムなアプリケーションは、データを、ＲＣｏＡではなくＣｏＡを用いてＲ
ＭＡｍ２に送信することになる（Ｓ３０６）。これは、通信要素確保要請を用いない通信処理である。

ＲＭＡｍ２は、ＭＮｍ１（非リアルタイムなアプリケーション）からのデータについては、ＣｏＡアドレスを含んでいるが、制御信号（周期等の通信要素確保要請）を含んでいないことから、共通バッファに格納する（Ｓ３０７）。

ＲＭＡｍ２は、自己が保持するリソース管理テーブルを参照して、通信リソースに空きがある場合に、共通バッファからその格納データを読み出し、その読み出したデータをその先のネットワークへ送信する（Ｓ３０８）。

なお、Ｓ３００〜Ｓ３０５の処理とＳ３０６〜Ｓ３０８の処理とを、同時に実行することも考えられる。
この例では、既にデータを送信しており、格納されている情報を搬出するパターンを送信する事で、そのパターンに基づいた送信を行う事となる。

また、ＲＭＡｍ２の前に対してバッファリングが可能なバッファリング用フィルタ機能搭載ルータｍ３（もしくはＡＰ）を置くことにより、一定時間の情報保持がされることとなり、これを用いてＲＴＴ情報に対して、シーケンス番号を持たせると、電波が不安定で届きにくい場合に、ＲＴＴ情報を複数回送信する事で、格納情報をより確実にならべることが可能となる。
（周期ルックインイネーブル予約処理）
次に、周期ルックインイネーブル予約処理について図２１を参照しながら説明する。本処理は、図１９のＳ２００〜２０７及び図２０のＳ３００〜３０３の後に行われる処理であって、図２１ではＳ３０９以降の処理である。

ＭＮｍ１は、look-in-Cycle情報を送信する（Ｓ３０９）が、ＢＦＲｍ３は、そのサイ
クル情報を一定時間保持して定期的にゲートを空ける動作を行う（Ｓ３１０）。
図２１に示すように、先にＳ３１０の処理を行ってその後に、Ｓ３０３の処理を実行することが可能な点が図２０とは異なる。

Ｓ３１１〜３１４の処理は、図２０のＳ３０５〜３０８の処理と同様であるので、その説明を省略する。
この例では、周期的にゲートを起動させておき、データをその周期で送信する事で目的の時間と一致したデータをネットワークに流しこむ事となる。また、データが来た事をトリガーとして、そのパターンでのタイミング送信を行う方法についても可能となる。
（動作詳細）
（ＭＮｍ１における通信要素確保要請）
ＭＮｍ１における通信要素確保要請について図２２を参照しながら説明する。

ＭＮｍ１は、受信したデータがルータ広告であり（Ｓ４００：Ｙｅｓ）、かつ、そのルータ広告のプレフィクスに変化があれば（Ｓ４０１：Ｙｅｓ）、そのルータ広告より、通信アドレスを更新（気付けアドレスＣｏＡを作成）する（Ｓ４０２）。これは公知のモバイルＩＰの機能である。

そして、ＭＮｍ１は、図８に示す自己のアプリケーション管理テーブルを参照して、通信を保証するアプリケーションが登録されていれば（Ｓ４０３：Ｙｅｓ）、通信要素確保要請情報（リアルタイムアプリケーションの特性要件）を生成する（Ｓ４０４）。ＭＮｍ１は、先ほどＳ４０２で生成したＣｏＡを用いて、その通信要素確保要請をメッセージとしてＲＭＡｍ２に送信する（Ｓ４０５）。

一方、ルータ広告のプレフィクスに変化がなく（Ｓ４０１：Ｎｏ）、かつ、通信を保証するアプリケーションが登録されている（Ｓ４０６：Ｙｅｓ）場合には、その通信を保証するアプリケーション用にＲＣｏＡが確保されていなければ（Ｓ４０７：Ｎｏ）、上記と同様に、通信要素確保要請情報の生成（Ｓ４０４）、その通信要素確保要請をメッセージとしてＲＭＡｍ２に送信（Ｓ４０５）する。

以上のように、ＭＮｍ１は、通信を保証するアプリケーションが登録されている場合に、通信要素確保要請を行うようになっている。
（ＲＭＡｍ２における通信要素確保要請に対する処理）
ＲＭＡｍ２は、ＭＮｍ１からの通信要素確保要請（要求条件）については、ＣｏＡアドレスを含んでおり、かつ、制御信号（周期等）を含んでいることから、この通信要素確保要請を共通制御バッファに格納する（Ｓ１０３）。この動作については既に説明した（図１０参照）。

図２３は、ＲＭＡｍ２のタイマーにより（周期的な）読み取りタイミングが到来するごとに、実行される。
ＲＭＡｍ２は、そのタイマーが読み取りタイミングを発行すると、通信要素確保要請（図２３中受付メッセージと記載）が格納されていれば共通制御バッファからその通信要素確保要請を読み出す（Ｓ５００：Ｙｅｓ）。その読み出した通信要素確保要請に対応するＣｏＡが既に管理しているＣｏＡでなければ（Ｓ５０１：Ｎｏ）、ＲＭＡｍ２は、通信要素確保要請情報は管理リソース上で提供可能か否かを判定する（Ｓ５０２）。すなわち、ＲＭＡｍ２は、自己が保持するリソース管理テーブルを参照して、自己に割り当てられたリソースをもとに、受付パターン解析して受付が可能か否かを判定する。そして、ＲＭＡｍ２は、提供可能（受付可能）な場合（Ｓ５０２：Ｙｅｓ）に、アドレス割り当てリソース管理テーブルを更新する（Ｓ５０３）。すなわち、パターンをネットワーク側で処理させるための、一意の貸し出しアドレス（ＲＣｏＡ）を生成し（Ｓ１０５）、この生成されたＲＣｏＡと先ほど受信した通信要件要請（有効時間を設定した場合はこれも。図１６参照。）とを図１３に示すリソース管理テーブルに登録する。ＲＭＡｍ２は、受付メッセージを１つずらし、再度、Ｓ５００以降の処理を繰り返す。

一方、Ｓ５００で読み出した通信要素確保要請に対応するＣｏＡが既に管理しているＣｏＡであれば（Ｓ５０１：Ｙｅｓ）、ＲＭＡｍ２は、通信要素確保要請情報は現在と差異があるか否かを判定する（Ｓ５０５）。そして、ＲＭＡｍ２は、差異がなければ（Ｓ５０５：Ｎｏ）、有効時間を更新し（Ｓ５０６）、アドレス情報とタイマー情報を返送する（ＳＳ５０７）。この動作については既に説明した（図ｓ８参照）。

一方、差異があれば（Ｓ５０５：Ｙｅｓ）、ＲＭＡｍ２は、さらに通信要素確保要請は分割要請か否かを判定する（Ｓ５０８）。そして、ＲＭＡｍ２は、分割要請であり（Ｓ５０８：Ｙｅｓ）、かつ、分割が正しく行えるのであれば（Ｓ５０９：Ｙｅｓ）、分割を実施して新たなアドレスを作成し（Ｓ５１０）、バッファアドレスの情報管理を更新し（Ｓ５１１）、アドレス情報を返送する（Ｓ５１２）。この動作については既に説明した（図１０参照）。なお、分割が正しく行えるか否かの判断（Ｓ５０９）は、例えば、ＲＭＡｍ２が、自己のリソース管理テーブルを参照することで判断することが考えられる。

一方、分割要請でなければ（Ｓ５０８：Ｎｏ）、ＲＭＡｍ２は、さらに通信要素変更要請か否かを判定する（Ｓ５１３）。そして、ＲＭＡｍ２は、通信要素変更要請であれば（Ｓ５１３：Ｙｅｓ）、上記Ｓ５０２〜Ｓ５０４の処理を実行する。
（ＭＮｍ１におけるアドレス取得後の処理）
図２４に示すように、ＭＮｍ１は、受信したアドレス（ＲＣｏＡ）が新しくもなく複数
アドレスでもなければ（Ｓ６００：Ｎｏ）、通信要素確保要請に伴う情報の更新を行う（Ｓ６０１）。この動作については既に説明した（図１７参照）。

一方、受信したアドレスが新しいか又は複数アドレスであれば（Ｓ６００：Ｙｅｓ）ｍＭＮｍ１は、さらに要求は分割か否かを判定する（Ｓ６０２）。そして、要求が分割でなければ（Ｓ６０２：Ｎｏ）、ＭＮｍ１は、通信要素確保要請に関連するアプリケーションに関して、利用アドレスを変更する（Ｓ６０３）。この動作については既に説明した（図１０等参照）。

一方、要求が分割で有れば（Ｓ６０２：Ｙｅｓ）、ＭＮｍ１は、旧アドレスの通信要素確保要請に伴う情報の更新（Ｓ６０４）、新アドレスの管理情報テーブルに対して登録更新（Ｓ６０５）を行う。この動作については既に説明した（図１０参照）。
（ＲＭＡｍ２における個別バッファからの読み出し処理）
ＲＭＡｍ２は、ＭＮｍ１（リアルタイムなアプリケーション）からのデータについては、ＲＣｏＡアドレスを含んでいることから、そのデータをＲＣｏＡ用に個別に生成した個別バッファに一時的に格納（保持）する（Ｓ１１０）。この動作については既に説明した（図１０参照）。

図２５は、ＲＭＡｍ２のタイマーにより（周期的な）読み取りタイミングが到来するごとに、実行される。
ＲＭＡｍ２は、そのタイマーが読み取りタイミングを発行すると、個別バッファの登録数が空きの状態でなければ（Ｓ７００：Ｎｏ）、登録に関して処理（図１４に示すブロックの個別バッファ情報に関する処理）、例えば登録数を見て登録数分、参照Ｂｌｋを監視する処理を行う（Ｓ７０１）。そして、読み出し用のｂｌｋ情報のデータが存在すれば（Ｓ７０２：Ｙｅｓ）、該当バッファから情報を収集し（Ｓ７０３）、メッセージ送信処理を実行する（Ｓ７０４）。この動作については既に説明した（図１０参照）。
（ＲＭＡｍ２における送信可能周期情報登録処理）
ＲＭＡｍ２は、ＭＮｍ１（リアルタイムなアプリケーション）からのデータについては、ＲＣｏＡアドレスを含んでいることから、そのデータをＲＣｏＡ用に個別に生成した個別バッファに一時的に格納（保持）する（Ｓ１１０）。この動作については既に説明した（図１０参照）。

図２６は、ＲＭＡｍ２のタイマーにより（周期的な）読み取りタイミングが到来するごとに、実行される。
ＲＭＡｍ２は、そのタイマーが読み取りタイミングを発行すると、個別バッファの登録数が空きの状態でなければ（Ｓ８００：Ｎｏ）、登録に関して処理（図１４に示すブロックの個別バッファ情報に関する処理）、例えば登録数を見て登録数分、参照Ｂｌｋを監視する処理を行う（Ｓ８０１）。そして、個別バッファの登録数は全て終了していなければ（Ｓ８０２：Ｎｏ）、該当ｂｌｋへの送信可能周期情報（図１４中割り当てパターン情報、すなわちLook-in-cycleに相当）の登録（Ｓ８０３）、次回ｂｌｋへ移動（Ｓ８０４）
する。以上のＳ８０２〜Ｓ８０４の処理を登録されている個別バッファの全てに対して行う。この動作については既に説明した（図２１参照）。

このようにして個別バッファごとに送信可能周期情報が登録されると、図２７に示すように、ＲＭＡｍ２は、送信すべき情報が存在していれば（Ｓ８０５：Ｙｅｓ）、メッセージ送信処理を実行する（Ｓ８０６）。
（ＲＭＡｍ２における共通バッファからの読み出し処理）
ＲＭＡｍ２は、ＭＮｍ１（非リアルタイムなアプリケーション）からのデータについては、ＣｏＡアドレスを含んでいるが、制御信号（周期等の通信要素確保要請）を含んでいないことから、共通バッファに格納する（Ｓ１１４）。この動作については既に説明した
（図１０参照）。

図２８は、ＲＭＡｍ２のタイマーにより（周期的な）読み取りタイミングが到来するごとに、実行される。
ＲＭＡｍ２は、そのタイマーが読み取りタイミングを発行すると、自己のリソース管理テーブルを参照して管理リソースに空きが存在すれば（Ｓ９００：Ｙｅｓ）、さらに共通バッファに受け付けメッセージの残りが有るか否かを判定する（Ｓ９０１）。そして、残りがあれば（Ｓ９０１：Ｙｅｓ）、共通バッファから残りの受付メッセージを読み出して、管理リソースが空き容量までメッセージ送信処理を行う（Ｓ９０１：Ｙｅｓ、Ｓ９０２、Ｓ９０３：Ｎｏ）。

一方、管理リソースに空きが存在しないか（Ｓ９０１：Ｎｏ）、又は管理リソースの空き容量迄送信した（Ｓ９０３：Ｙｅｓ）場合には、さらにＲＭＡｍ２は、受付メッセージ残りがあり、かつ、受付メッセージは保持有効時間を超過しているか否かを判定する（Ｓ９０４）。そして、その判定がＮｏであれば（Ｓ９０４：Ｎｏ）、Ｓ９００に戻って再度上記の処理を繰り返す。一方、その判定がＹｅｓであれば（Ｓ９０４：Ｙｅｓ）、該当受付メッセージの廃棄（Ｓ９０５）、次回メッセージの判定（Ｓ９０６）を行い、Ｓ９０４以後の処理を実行する。

本発明は、その精神または主要な特徴から逸脱することなく、他の様々な形で実施することができる。このため、上記の実施形態はあらゆる点で単なる例示にすぎない。これらの記載によって本発明が限定的に解釈されるものではない。

本発明は次のように特定することもできる。
（付記１）
無線インターフェースを有する第一の装置及び第二の装置が通信する方法であって、第一の装置が、所定通信パターンを含む通信要素確保要請を送信するステップと、第二の装置が、前記通信要素確保要請が含む所定通信パターンの通信を、自己に割り当てられているリソース量との関係で受け付け可能か否かを判定し、受け付け可能と判定した場合に、新たなアドレスを生成して送信するとともに、この新たなアドレスと前記所定通信パターンとの対応関係を保持するステップと、第一の装置が、所定情報を、前記新たなアドレスを利用して送信するステップと、第二の装置が、前記新たなアドレスを利用して送信された所定情報については、その新たなアドレスに対応する所定通信パターンで転送するステップと、を備える通信方法。（１）
（付記２）
前記新たなアドレスを利用して送信された所定情報をメモリに保持するステップをさらに備え、前記第二の装置は、新たなアドレスに対応する所定通信パターンに従って、前記メモリから所定情報を読み出して転送する、付記１に記載の通信方法。（２）
（付記３）
第二の装置に搭載される機能のうち、データを保持する機能、通信要素確保要請によるデータ収集機能、ネットワークに対して情報を送信する機能のうちすくなくとも１つを、１又は複数の別装置に対して割り当てる付記１に記載の通信方法。
（付記４）
第二の装置が、第一の装置を受け付けるための送信許容周期情報を付与して送付するステップをさらに備え、第一の装置が付与情報を元に送信許容周期情報を送信することで、第二の装置が保持した情報を送信許容周期情報に従って転送する付記１から付記３のいずれかに記載の通信方法。
（付記５）
前記第一の装置は移動通信装置であり、前記第二の装置は無線基地局である、付記１から付記４のいずれかに記載の通信方法。
（付記６）
前記第一の装置は移動通信装置であり、前記第二の装置は移動支援装置（ホームエージェント）である、付記１から付記４のいずれかに記載の通信方法。
（付記７）
第一の装置が持つ無線インターフェースは、通常のインターフェースである、付記１から付記４のいずれかに記載の通信方法。
（付記８）
通信要素確保要請を作成する手段と、通信要素確保要請を行うアプリケーションとの関連付けを行う手段と、通信要素確保要請を送信する手段と、通信要素確保要請を受信した装置より新たなアドレスを受信した場合に、関連付けを行ったアプリケーションに関して、新たなアドレスを利用して通信する手段と、を備える通信装置。
（付記９）
通信要素確保要請を行わなかったアプリケーションに関して、新たなアドレスを利用せずに通信する手段を備える付記８に記載の通信装置。
（付記１０）
相手装置（本実施形態では第二の装置）が持つ機能を搭載する、装置が複数存在するネットワークにおいて、複数の前記装置に対して、通信要素確保要請を行う通信装置。
（付記１１）
さらに通信先の端末の近隣に属する第二の装置に対して通信要素確保要請を行う付記１０に記載の通信装置。
（付記１２）
前記通信要素確保要請を送信する手段によりさらに新たな通信要素確保要請を送信することにより、新たなアドレス情報に対するリソース割り当ての変更を行う付記８に記載の通信装置。
（付記１３）
前記通信要素確保要請を送信する手段によりさらに新たな通信要素確保要請を送信することにより、アドレス情報内の割り当て情報を分割して新たに作成したアドレスを追加情報として要請する付記８に記載の通信装置。
（付記１４）
第一の装置から所定通信パターンを含む通信要素確保要請を受信する手段と、前記所定通信パターンに関連付けを行った新たなアドレスを作成する手段と、前記新たなアドレス情報を第一の装置に送信する手段と、を備える通信制御装置。
（付記１５）
前記新たなアドレスを作成する手段は、ランダムなアドレスを生成する付記１４に記載の通信制御装置。
（付記１６）
前記新たなアドレスには一定時間の制限が設定されている付記１４又は１５に記載の通信制御装置。
（付記１７）
第一の装置から前記新たなアドレスを利用して送信された所定情報を一定時間保持する手段と、その保持手段から所定通信パターンに基づき所定を収集して転送する手段と、を備える付記１４から付記１６のいずれかに記載の通信装置。
（付記１８）
前記新たなアドレスを第一の装置に送信するときに、さらに第一の装置に対して、第二の装置が収集を行う周期指示情報を付与する付記１７に記載の通信装置。
（付記１９）
無線インターフェースを有する第一の装置及び第二の装置が通信するシステムであって、所定通信パターンを含む通信要素確保要請を送信する第一の装置と、前記通信要素確保要請が含む所定通信パターンの通信を、自己に割り当てられているリソース量との関係で受け付け可能か否かを判定し、受け付け可能と判定した場合に、新たなアドレスを生成し
て、この新たなアドレスと前記所定通信パターンとの対応関係を保持する第二の装置と、前記新たなアドレスを前記第二の装置から第一の装置に送信する手段と、を備え、前記第一の装置は、所定情報を、前記新たなアドレスを利用して送信し、前記第二の装置は、前記新たなアドレスを利用して送信された所定情報については、その新たなアドレスに対応する所定通信パターンで転送する、通信システム。（３）
（付記２０）
所定情報を送信する装置との間で通信する通信制御装置であって、前記装置から送信された所定情報を受信する手段と、所定通信パターンを含む所定情報を受信した場合、該所定通信パターンの通信を、自己に割り当てられているリソース量との関係で受け付け可能か否かを判定する手段と、受け付け可能と判定した場合に、新たなアドレスを生成する手段と、この新たなアドレスと前記所定通信パターンとの対応関係を保持する手段と、前記新たなアドレスを前記装置に提供する手段と、前記新たなアドレスを利用して送信された所定情報を受信した場合、該所定情報を、該新たなアドレスに対応する所定通信パターンで転送する手段と、を備える通信制御装置。（４）
（付記２１）所定通信パターンを含む通信要素確保要請を、第一アドレスを利用して送信する手段と、前記通信要素確保要請が含む所定通信パターンの通信を自己に割り当てられているリソース量との関係で受け付け可能と判定した装置から送信される第二アドレスを受信する手段と、所定情報を、前記第二アドレスを利用して送信する手段と、を備える通信装置。（５）
（付記２２）
所定情報を送信する装置との間で通信する通信制御装置を、前記装置から送信された所定情報を受信する手段、所定通信パターンを含む所定情報を受信した場合、該所定通信パターンの通信を、自己に割り当てられているリソース量との関係で受け付け可能か否かを判定する手段、受け付け可能と判定した場合に、新たなアドレスを生成する手段、この新たなアドレスと前記所定通信パターンとの対応関係を保持する手段、前記新たなアドレスを前記装置に提供する手段、前記新たなアドレスを利用して送信された所定情報を受信した場合、該所定情報を、該新たなアドレスに対応する所定通信パターンで転送する手段、として機能させるためのプログラム。
（付記２３）
通信装置を、所定通信パターンを含む通信要素確保要請を、第一アドレスを利用して送信する手段、前記通信要素確保要請が含む所定通信パターンの通信を自己に割り当てられているリソース量との関係で受け付け可能と判定した装置から送信される第二アドレスを受信する手段、所定情報を、前記第二アドレスを利用して送信する手段、として機能させるためのプログラム。

本発明によれば、ＲＴＴ等の特定通信の品質を確保することが可能となる。また、ネットワークのコア部分に関して、自在なプロトコルを用いる事が可能となること、更にネットワーク側が望むアドレスのみで制御が可能な点を設けることによる、セキュリティ面の向上と要求するポリシーが明確に分類することが可能となる。さらに、中継処理側で保持する情報を開けるゲートとして用いる事で、送信側に関して意識的な時間管理を行わせる事が可能となる。また、無線区間に関しては無駄に無効な要求を送信させることを抑止することが可能となる。さらに、ネットワークを連携させる方法や、負荷を分散させて管理することも容易となる。また、通信に本方式を用いると通信相手側の直前で保証させるべき情報を提供することができるために、ギャップサイズに関しても他の方式と比べて優位となる。

本発明の原理図（第一の形態）である。 本発明の原理図（第二の形態）である。 本発明の変形例を説明するための図である。 本発明の変形例を説明するための図である。 本発明の原理図（第三の形態）である。 第一の装置ｍ１の機能ブロック図である。 第二の装置ｍ２の機能ブロック図である。 アプリケーション管理テーブル例である。 本発明の実施形態であるネットワークシステムの概略構成を説明するための図である。 通信要求振り分け処理を説明するための図である。 リソースをもとに、受付パターン解析して受付が可能か否かを判定する処理について説明するための図である。 リソースをもとに、受付パターン解析して受付が可能か否かを判定する処理について説明するための図である。 リソース管理テーブルの例である。 バッファ管理テーブル。 ランダムアドレスの生成について説明するための図である。 有効時間の設定について説明するための図である。 リソース更新要請処理について説明するための図である。 複数通信要素確保処理について説明するための図である。 バッファ管理装置中継処理について説明するための図である。 周期ルックインイネーブル処理（周期ルックインゲートイネーブル要請処理）について説明するための図である。 周期ルックインイネーブル処理（周期ルックインゲートイネーブル要請処理）について説明するための図である。 ＭＮｍ１における通信要素確保要請について説明するためのフローチャートである。 ＲＭＡｍ２における通信要素確保要請に対する処理について説明するためのフローチャートである。 ＭＮｍ１におけるアドレス取得後の処理について説明するためのフローチャートである。 ＲＭＡｍ２における個別バッファからの読み出し処理について説明するためのフローチャートである。 ＲＭＡｍ２における送信可能周期情報登録処理について説明するためのフローチャートである。 ＲＭＡｍ２における送信可能周期情報登録処理について説明するためのフローチャートである。 ＲＭＡｍ２における共通バッファからの読み出し処理について説明するためのフローチャートである。

符号の説明

ｍ１ ＭＮ（移動通信端末）
ｍ２ ＲＭＡ（リソース管理エージェント）
ｍ３ ＢＦＲ（バッファリング用フィルタ機能搭載ルータ）

Claims (5)

1. 無線インターフェースを有する第一の装置及び第二の装置が通信する方法であって、
   第一の装置が、リアルタイム通信の希望の複数の時間位置を指定するための所定通信パターンを含み、前記希望の複数の時間位置は連続の時間位置を含む、通信要素確保要請を送信するステップと、
   第二の装置が、前記通信要素確保要請が含む前記所定通信パターンの通信を、自己に割り当てられているリソース量との関係で受け付け可能か否かを判定し、受け付け可能と判定した場合に、新たなアドレスを生成して送信するとともに、この新たなアドレスと前記所定通信パターンとの対応関係を保持するステップと、
   第一の装置が、所定情報を、前記新たなアドレスを利用して送信するステップと、
   第二の装置が、前記新たなアドレスを利用して送信された前記所定情報については、その新たなアドレスに対応する前記所定通信パターンで転送するステップと、
   を備える通信方法。
2. 前記新たなアドレスを利用して送信された前記所定情報をメモリに保持するステップをさらに備え、
   前記第二の装置は、前記新たなアドレスに対応する前記所定通信パターンに従って、前記メモリから前記所定情報を読み出して転送する、
   請求項１に記載の通信方法。
3. 無線インターフェースを有する第一の装置及び第二の装置が通信するシステムであって、
   リアルタイム通信の希望の複数の時間位置を指定するための所定通信パターンを含み、前記希望の複数の時間位置は連続の時間位置を含む、通信要素確保要請を送信する第一の装置と、
   前記通信要素確保要請が含む前記所定通信パターンの通信を、自己に割り当てられているリソース量との関係で受け付け可能か否かを判定し、受け付け可能と判定した場合に、新たなアドレスを生成して、この新たなアドレスと前記所定通信パターンとの対応関係を保持する第二の装置と、
   前記第二の装置からの前記新たなアドレスを前記第一の装置に送信する手段と、
   を備え、
   前記第一の装置は、所定情報を、前記新たなアドレスを利用して送信し、
   前記第二の装置は、前記新たなアドレスを利用して送信された前記所定情報については、その新たなアドレスに対応する前記所定通信パターンで転送する、通信システム。
4. 所定情報を送信する装置との間で通信する通信制御装置であって、
   前記装置から送信された前記所定情報を受信し、前記所定情報は、リアルタイム通信の希望の複数の時間位置を指定するための所定通信パターンを含み、前記希望の複数の時間位置は連続の時間位置を含む、通信要素確保要請である、手段と、
   前記所定通信パターンを含む前記所定情報を受信した場合、該所定通信パターンの通信を、自己に割り当てられているリソース量との関係で受け付け可能か否かを判定する手段と、
   受け付け可能と判定した場合に、新たなアドレスを生成する手段と、
   この新たなアドレスと前記所定通信パターンとの対応関係を保持する手段と、
   前記新たなアドレスを前記装置に提供する手段と、
   前記新たなアドレスを利用して送信された前記所定情報を受信した場合、該所定情報を、該新たなアドレスに対応する前記所定通信パターンで転送する手段と、
   を備える通信制御装置。
5. リアルタイム通信の希望の複数の時間位置を指定するための所定通信パターンを含み、前記希望の複数の時間位置は連続の時間位置を含む、通信要素確保要請を、第一アドレスを利用して送信する手段と、
   前記通信要素確保要請が含む前記所定通信パターンの通信を自己に割り当てられているリソース量との関係で受け付け可能と判定した装置から送信される第二アドレスを受信する手段と、
   所定情報を、前記第二アドレスを利用して送信する手段と、
   を備える通信装置。

Images