(57)【要約】中央制御装置（ＨＣ）から通信装置（ｎｏｎ−ＡＰ  ＱＳＴＡ）へのダウンリンクストリーム通信を可能な状態とするために、中央制御装置に対して、グループＡＣＫに関するＡＣＫ情報の設定処理を要求する要求信号を通信装置が送信する。通信装置から送信される、ＡＣＫ情報の設定処理を要求する要求信号を、中央制御装置が受信する。通信装置に対して、ＡＣＫ情報の設定処理を要求する要求信号に基づく応答信号を、中央制御装置が送信する。中央制御装置から送信される応答信号を、通信装置が受信する。
2004064333.tif 000002
【特許請求の範囲】
【請求項１】
複数の通信装置が通信ネットワークを介して接続されているネットワークシステムを構成する通信装置であって、
他の通信装置との間でデータ通信を可能な状態とするために、他の通信装置との間で行われる複数の通信設定処理について、各通信設定処理にて最初に送信すべき信号を、自装置から他の通信装置に対して送信する送信手段を備えることを特徴とする通信装置。
【請求項２】
前記他の通信装置は、前記通信ネットワークの送信権を管理する中央制御装置であると共に、前記データ通信は、前記他の通信装置から自装置へのダウンリンクストリーム通信であって、
前記送信手段は、前記ダウンリンクストリーム通信を可能な状態とするために、前記信号として、グループＡＣＫに関するＡＣＫ情報の設定処理を要求する要求信号を、前記他の通信装置に対して送信することを特徴とする請求項１記載の通信装置。
【請求項３】
前記要求信号は、自装置が所望するグループＡＣＫの種別に関する情報、および、自装置におけるストリーム受信バッファサイズに関する情報を含んでいることを特徴とする請求項２記載の通信装置。
【請求項４】
複数の通信装置が通信ネットワークを介して接続されているネットワークシステムを構成する通信装置であって、
他の通信装置との間でデータ通信を可能な状態とするために、他の通信装置との間で行われる複数の通信設定処理について、各通信設定処理にて最初に送信すべき信号を、他の通信装置から受信する受信手段と、
前記最初に送信すべき信号に対する応答信号を、前記他の通信装置に送信する送信手段とを備えることを特徴とする通信装置。
【請求項５】
自装置は、前記通信ネットワークの送信権を管理する装置であると共に、前記データ通信は、前記自装置から他の通信装置へのダウンリンクストリーム通信であって、
前記受信手段は、前記ダウンリンクストリーム通信を可能な状態とするために、前記信号として、グループＡＣＫに関するＡＣＫ情報の設定処理を要求する要求信号を、前記他の通信装置から受信することを特徴とする請求項４記載の通信装置。
【請求項６】
前記応答信号は、自装置が所望するグループＡＣＫの種別に関する情報、および、自装置におけるストリーム送信バッファサイズに関する情報を含んでいることを特徴とする請求項５記載の通信装置。
【請求項７】
複数の通信装置が通信ネットワークを介して接続されているネットワークシステムを構成する通信装置であって、
他の通信装置との間でデータ通信を可能な状態とするために、前記他の通信装置から送信される、第１の通信設定処理を要求する第１要求信号を受信する受信手段と、
前記第１要求信号の要求内容を承認するか否かを判定する判定手段と、
前記他の通信装置との間でデータ通信を可能な状態とするために、前記他の通信装置に対して、第２の通信設定処理を要求する第２要求信号を送信する送信手段とを備え、
前記判定手段が前記要求内容を承認した場合に、前記送信手段が、前記第２要求信号を前記他の通信装置に送信することを特徴とする通信装置。
【請求項８】
自装置は前記通信ネットワークの送信権を管理する装置であると共に、前記データ通信は、前記他の通信装置から自装置へのダウンリンクストリーム通信であって、
前記受信手段は、第１要求信号として、帯域情報の設定処理を要求する要求信号を受信し、
前記送信手段は、第２要求信号として、グループＡＣＫに関するＡＣＫ情報の設定処理を要求する要求信号を送信することを特徴とする請求項７記載の通信装置。
【請求項９】
前記他の通信装置に対して、前記グループＡＣＫに関するＡＣＫ情報の設定を要求する要求信号を送信するＭＡＣ副層と、
前記判定手段を有すると共に、ＭＡＣ副層を管理する管理層とを備え、
前記判定手段が前記要求内容を承認した場合、前記管理層が、前記ＭＡＣ副層に対して前記グループＡＣＫに関するＡＣＫ情報の設定を要求する要求信号を送信するための指示を出すことを特徴とする請求項８記載の通信装置。
【請求項１０】
複数の通信装置が通信ネットワークを介して接続されているネットワークシステムを構成する通信装置であって、
前記他の通信装置との間でデータ通信を可能な状態とするために、前記他の通信装置に対して、所定の通信設定処理を要求する要求信号を送信する送信手段と、
前記他の通信装置から、前記要求信号に基づく応答信号を受信する受信手段と、
前記応答信号に基づいて、前記所定の通信設定処理が行われたか否かを判定する判定手段と、
前記判定手段による判定結果を、前記他の通信装置に対して通知する通知手段とを備えることを特徴とする通信装置。
【請求項１１】
前記他の通信装置は、前記通信ネットワークの送信権を管理する中央制御装置であると共に、前記データ通信は、前記他の通信装置から自装置へのダウンリンクストリーム通信であって、
前記送信手段は、前記要求信号として、帯域情報の設定処理を要求する要求信号を送信し、
前記判定手段は、前記帯域情報の設定処理が行われたか否かを判定することを特徴とする請求項１０記載の通信装置。
【請求項１２】
複数の通信装置が通信ネットワークを介して接続されているネットワークシステムを構成する通信装置であって、
他の通信装置との間でデータ通信を可能な状態とするために、前記他の通信装置から送信される、所定の情報の設定処理を含んだ通信設定処理を要求する要求信号を受信する受信手段と、
前記要求信号に基づいて、他の通信装置と自装置との優先度を比較する比較手段とを備え、
前記他の通信装置の優先度が高い場合には、他の通信装置との間でデータ通信を可能な状態とするために、他の通信装置に対して、前記所定の情報を含めた応答信号を送信することを特徴とする通信装置。
【請求項１３】
複数の通信装置が通信ネットワークを介して接続されているネットワークシステムを構成する通信装置であって、
他の通信装置との間でデータ通信を可能な状態とするために、前記他の通信装置から送信される、所定の情報の設定処理を含んだ通信設定処理を要求する要求信号を受信する受信手段と、
前記要求信号に基づいて、他の通信装置と自装置との優先度を比較する比較手段とを備え、
前記自装置の優先度が高い場合には、他の通信装置との間でデータ通信を可能な状態とするために、他の通信装置に対して自装置が設定した情報の設定処理を含んだ応答信号を送信することを特徴とする通信装置。
【請求項１４】
前記通信設定処理は、グループＡＣＫに関するＡＣＫ情報の設定処理であって、
前記要求信号には、グループＡＣＫの種別に関する情報が含まれていることを特徴とする請求項１２または１３記載の通信装置。
【請求項１５】
前記要求信号には、前記要求信号の送信元となる他の通信装置がデータ通信の送信側または受信側であるかの情報が含まれており、
前記優先度が、前記送信側または受信側であるかの情報に基づいて決定されることを特徴とする請求項１２〜１４の何れか１項に記載の通信装置。
【請求項１６】
複数の通信装置が通信ネットワークを介して接続されているネットワークシステムを構成する通信装置であって、
他の通信装置との間でデータ通信を可能な状態とするために、前記他の通信装置に対して第１要求信号を送信する送信手段、および、前記他の通信装置から第２要求信号を受信する受信手段を備え、
前記第１要求信号には、自装置がデータ通信の送信側または受信側かの情報が含まれていることを特徴とする通信装置。
【請求項１７】
請求項１記載の通信装置と、請求項４記載の通信装置とを備えることを特徴とするネットワークシステム。
【請求項１８】
請求項７記載の通信装置と、
前記通信装置と通信ネットワークを介して接続される他の通信装置とを備えることを特徴とするネットワークシステム。
【請求項１９】
請求項１０記載の通信装置と、
前記通信装置と通信ネットワークを介して接続されており、かつ、前記通信ネットワークの送信権を管理する中央制御装置とを備えることを特徴とするネットワークシステム。
【請求項２０】
１つ以上の通信装置および中央制御装置が通信ネットワークを介して接続されており、かつ、前記中央制御装置が、前記通信ネットワークの送信権を管理するネットワークシステムで用いられる通信管理方法であって、
前記中央制御装置から自装置へのダウンリンクストリーム通信を可能な状態とするために、前記中央制御装置に対して、グループＡＣＫに関するＡＣＫ情報の設定処理を要求する要求信号を前記通信装置が送信する第１のステップと、
前記通信装置から送信される、前記ＡＣＫ情報の設定処理を要求する要求信号を、前記中央制御装置が受信する第２のステップと、
前記通信装置に対して、前記ＡＣＫ情報の設定処理を要求する要求信号に基づく応答信号を、前記中央制御装置が送信する第３のステップと、
前記中央制御装置から送信される前記応答信号を、前記通信装置が受信する第４のステップとを備えることを特徴とする通信管理方法。
【請求項２１】
１つ以上の通信装置および中央制御装置が通信ネットワークを介して接続されており、かつ、前記中央制御装置が、前記通信ネットワークの送信権を管理するネットワークシステムで用いられる通信管理方法であって、
前記中央制御装置から前記通信装置へのダウンリンクストリーム通信を可能な状態とするために、前記通信装置から送信される、帯域情報の設定処理を要求する要求信号を中央制御装置が受信する第１ステップと、
前記帯域情報の設定処理を要求する要求信号の要求内容について、前記要求内容を承認するか否かを中央制御装置が判定する第２ステップと、
前記第３ステップにて中央制御装置が前記要求内容を承認した場合に、前記ダウンリンクストリーム通信を可能な状態とするために、グループＡＣＫに関する前記ＡＣＫ情報の設定処理を要求する要求信号を前記中央制御装置が通信装置に対して送信する第３ステップとを備えることを特徴とする通信管理方法。
【請求項２２】
１つ以上の通信装置および中央制御装置が通信ネットワークを介して接続されており、かつ、前記中央制御装置が、前記通信ネットワークの送信権を管理するネットワークシステムで用いられる通信管理方法であって、
前記中央制御装置から前記通信装置へのダウンリンクストリーム通信を可能な状態とするために、前記中央制御装置に対して、帯域情報の設定処理を要求する要求信号を前記通信装置が送信する第１ステップと、
前記中央制御装置から、前記要求信号に基づく応答信号を前記通信装置が受信する第２ステップと、
前記応答信号に基づいて、前記帯域情報の設定処理が行われたか否かを前記通信装置が判定する第３ステップと、
前記第３ステップでの判定結果を、前記通信装置が前記中央制御装置に対して通知する第４ステップとを備えることを特徴とする通信管理方法。
【請求項２３】
通信ネットワークを介して互いに接続された通信装置間にてデータ通信を可能な状態とするために、前記通信装置間で行われる複数の通信設定処理に関し、各通信設定処理にて最初に送信すべき要求信号を一方の通信装置が他の通信装置に対して送信する通信管理方法における要求信号であって、
前記一方の通信装置が、データ通信の送信側装置、受信側装置、または、前記ネットワークの通信権を管理する中央制御装置の何れかの装置として動作する際に必要となる、データ通信を可能な状態とするための情報を含んでいることを特徴とする要求信号。
【請求項２４】
１つ以上の通信装置および中央制御装置が通信ネットワークを介して接続されており、かつ、前記中央制御装置が前記通信ネットワークの送信権を管理するネットワークシステムを構成する通信装置が、前記中央制御装置に送信する信号であると共に、前記中央制御装置から自装置へのダウンリンクストリーム通信を可能な状態とするための要求信号であって、
ストリームデータの受信側である前記通信装置からグループＡＣＫに関するＡＣＫ情報の設定を行うために必要な情報を含んでいることを特徴とする要求信号。
【請求項２５】
通信ネットワークを介して互いに接続された通信装置間にてデータ通信を可能な状態とするために、前記通信装置間で行われる複数の通信設定処理に関し、各通信設定処理にて最初に送信すべき要求信号を一方の通信装置が他の通信装置に対して送信すると共に、他方の通信装置が前記要求信号に対する応答信号を前記一方の通信装置に送信する通信管理方法における応答信号であって、
前記他方の通信装置が、データ通信の送信側装置、受信側装置、または、前記ネットワークの通信権を管理する中央制御装置の何れかの装置として動作する際に必要となる、データ通信を可能な状態とするための情報を含んでいることを特徴とする応答信号。
【請求項２６】
１つ以上の通信装置と通信ネットワークを介して接続されると共に、前記通信ネットワークの送信権を管理する中央制御装置が、前記通信装置に対して送信する信号であると共に、前記中央制御装置から自装置へのダウンリンクストリーム通信を可能な状態とするための要求信号に対する応答信号であって、
ストリームデータの送信側である前記中央制御装置からグループＡＣＫに関するＡＣＫ情報の設定を行うための情報を含んでいることを特徴とする応答信号。
【請求項２７】
請求項１〜１６の何れか１項に記載の通信装置の各手段としてコンピュータを機能させるためのプログラム。
【請求項２８】
請求項２０〜２２の何れか１項に記載の通信管理方法をコンピュータに実行させるためのプログラム。
【請求項２９】
請求項２７または２８に記載のプログラムを記録した記録媒体。
【発明の詳細な説明】
【技術分野】  本発明は、複数の通信装置が１つのネットワーク経路を共用するネットワークにおける通信を管理する通信管理方法、通信装置、ネットワークシステム、プログラム、該プログラムを記録したコンピュータ読み取り可能な記録媒体に関するものである。
【背景技術】  近年、ＬＡＮ（Ｌｏｃａｌ  Ａｒｅａ  Ｎｅｔｗｏｒｋ）に対する重要度が増している。このようなネットワークにおいて、それに接続する複数の通信局は、パケット送信に関して１つのメディアを共有することになる。複数の送信局が同時に送信を行うとパケット同士の衝突が発生するため、この衝突を効率良く回避する仕組みが定義される必要がある。
例えば、無線ＬＡＮのための標準規格であるＩＥＥＥ８０２．１１無線通信方式（ＡＮＳＩ／ＩＥＥＥ  Ｓｔｄ  ８０２．１１，１９９９  Ｅｄｉｔｉｏｎに準拠する方式）においては、ＤＣＦ（Ｄｉｓｔｒｉｂｕｔｅｄ  Ｃｏｏｒｄｉｎａｔｉｏｎ  Ｆｕｎｃｔｉｏｎ）と呼ばれるＣＳＭＡ／ＣＡ（Ｃａｒｒｉｅｒ  Ｓｅｎｓｅ  Ｍｕｌｔｉｐｌｅ  Ａｃｃｅｓｓ／Ｃｏｌｌｉｓｉｏｎ  Ａｖｏｉｄａｎｃｅ）ベースの衝突回避方式が定義されている。
しかしこのような従来のネットワークでは全ての送信局に対して平等に送信権が与えられるため、ネットワークに流れるトラフィックの総量が増加すると１つのストリームあたりの帯域が減少するため、各データの伝送遅延時間に制限があるような動画や音声などのリアルタイムのストリームデータを流す際に問題となる。すなわち、このようなストリームデータはネットワークが混み合ってくると正常に伝送されないことになる。
そこで各ストリームデータを正常に伝送させるために、種々の帯域確保の仕組みが考案されている。図１７に示すように、帯域確保を行うための一手法として、ネットワーク上の中央制御局１２０３が送信局（通信局）１２０１の受信局（通信局）１２０２へのデータ送信に必要な帯域の一部の管理を行う手法がある。このような手法において各送信局はこれからネットワークに流そうとするストリームデータのトラフィック特性に関する情報を中央制御局に通知し、中央制御局がこのストリームの伝送の可否判定を行い、受け入れ可能と判定した場合には中央制御局から各送信局に対して送信権の付与が行われる。
上述のＩＥＥＥ８０２．１１無線通信方式の場合には、ＴＧＥと呼ばれるサブグループにおいて、無線ネットワーク上で帯域管理を行うための、ＨＣＦ（Ｈｙｂｒｉｄ  Ｃｏｏｒｄｉｎａｔｉｏｎ  Ｆｕｎｃｔｉｏｎ）と呼ばれる中央制御局の機能が議論されている。ＴＧＥが２００２年１１月会議において策定したドラフト（ＩＥＥＥ  Ｓｔｄ  Ｐ８０２．１１ｅ／Ｄ４．０，２００２に準拠する方式。以下では「現在のドラフト」と呼ぶ。）では、ＨＣ（Ｈｙｂｒｉｄ  Ｃｏｏｒｄｉｎａｔｏｒ）と呼ばれる中央制御局がネットワークに属する送信局のトラフィックの送信権の一部を管理する。ＨＣ以外の通信局はｎｏｎ−ＡＰ  ＱＳＴＡと呼ばれる。
ＴＳＰＥＣ（Ｔｒａｆｆｉｃ  Ｓｐｅｃｉｆｉｃａｔｉｏｎ）情報を各ｎｏｎ−ＡＰ  ＱＳＴＡから受信したＨＣは、各ｎｏｎ−ＡＰ  ＱＳＴＡからの要求が満たされるように各送信局に対する送信権の付与順序と付与時間に関する計算を行い（スケジューリング）、このスケジュールの結果に基づいて各ｎｏｎ−ＡＰ  ＱＳＴＡに対する送信権の付与を行う。
このように、ｎｏｎ−ＡＰ  ＱＳＴＡからＨＣに対してＴＳＰＥＣを登録する処理をＡＤＤＴＳ処理と呼ぶ。なお、ＨＣとｎｏｎ−ＡＰ  ＱＳＴＡの両方がストリームを送信可能である。以下では、ストリームを送信するｎｏｎ−ＡＰ  ＱＳＴＡまたはＨＣをストリーム送信局、ストリームを受信するｎｏｎ−ＡＰ  ＱＳＴＡまたはＨＣをストリーム受信局と呼ぶ。
またデータの送信を行う際に、受信局側から受信確認情報を得るための方法としてＮｏｒｍａｌ  ＡＣＫと呼ばれる手法と、Ｇｒｏｕｐ  ＡＣＫと呼ばれる手法の２種類が定義されている。
Ｇｒｏｕｐ  ＡＣＫの手法を用いると複数のパケットの受信確認情報を一度に送信局に通知することができるためＮｏｒｍａｌ  ＡＣＫの手法を用いる場合と比較して帯域効率が良くなっている。このため、ＨＤＴＶのストリームなどを送信する場合にはＧｒｏｕｐ  ＡＣＫを用いることが有効である。
Ｇｒｏｕｐ  ＡＣＫには、ｉｍｍｅｄｉａｔｅ  Ｇｒｏｕｐ  ＡＣＫとｄｅｌａｙｅｄ  Ｇｒｏｕｐ  ＡＣＫという二つの方法がある。
ｉｍｍｅｄｉａｔｅ  Ｇｒｏｕｐ  ＡＣＫはストリーム送信局からＧｒｏｕｐ  ＡＣＫの返送を要求されたら、ストリーム受信局はそれまで受信した複数のパケットに対するＧｒｏｕｐ  ＡＣＫを返送しなければならない方法である。ｄｅｌａｙｅｄ  Ｇｒｏｕｐ  ＡＣＫは、ストリーム送信局からＧｒｏｕｐ  ＡＣＫの返送を要求されたら、ストリーム受信局はそれまで受信した複数のパケットに対するＧｒｏｕｐ  ＡＣＫを、自局が次に送信権を得た時に返送する方法である。
（ＡＤＤＧＡ処理の概略）
Ｇｒｏｕｐ  ＡＣＫを使用するためには、予めストリームの送受信局間で所定の情報をやり取りしなければならない。やり取りする情報としては、主に以下のような３つの情報がある。
１．Ｔｒａｎｓｍｉｔ  Ｂｕｆｆｅｒ  Ｓｉｚｅ（ストリーム送信局におけるストリーム送信バッファのサイズ。ストリーム送信局がストリーム受信局に通知する。）
２．Ｒｅ−ｏｒｄｅｒｉｎｇ  Ｂｕｆｆｅｒ  Ｓｉｚｅ（ストリーム受信局におけるストリーム受信バッファのサイズ。ストリーム受信局がストリーム送信局に通知する。）
３．Ｇｒｏｕｐ  ＡＣＫ  Ｐｏｌｉｃｙ（ｉｍｍｉｄｉａｔｅ  Ｇｒｏｕｐ  ＡＣＫとｄｅｌａｙｅｄ  Ｇｒｏｕｐ  ＡＣＫのどちらを使用するかという情報。ストリーム受信局がストリーム送信局に通知する。）
これらの情報をやり取りするために、以下のような手順を踏む必要がある。
（手順１）ストリーム送信局がストリーム受信局宛にＡＤＤＧＡ  ｒｅｑｕｅｓｔフレームと呼ばれるパケットを送信する。このパケットにはＴｒａｎｓｍｉｔ  Ｂｕｆｆｅｒ  Ｓｉｚｅが含まれる。
（手順２）ストリーム受信局がストリーム送信局宛にＡＤＤＧＡ  ｒｅｓｐｏｎｓｅフレームと呼ばれるパケットを送信する。このパケットにはＧｒｏｕｐ  ＡＣＫ  Ｐｏｌｉｃｙ及びＲｅ−ｏｒｄｅｒｉｎｇ  Ｂｕｆｆｅｒ  Ｓｉｚｅが含まれる。
なお、これらの処理をＡＤＤＧＡ処理と呼ぶ。
ところで、図１４に複数のｎｏｎ−ＡＰ  ＱＳＴＡとＨＣからなる無線通信システムを示す。図１４に示す通りＩＥＥＥ８０２．１１においては、データ伝送の対象の組み合わせにより以下のような、３つの伝送方式がある。
（方式１）ダウンリンクストリーム（ＨＣ９０１からｎｏｎ−ＡＰ  ＱＳＴＡ９０２へ送信するストリーム）
（方式２）アップリンクストリーム（ｎｏｎ−ＡＰ  ＱＳＴＡ９０２からＨＣ９０１へ送信するストリーム）
（方式３）ダイレクトリンクストリーム（ｎｏｎ−ＡＰ  ＱＳＴＡ９０２から別のｎｏｎ−ＡＰ  ＱＳＴＡ９０３へ送信するストリーム）
Ｇｒｏｕｐ  ＡＣＫを用いてストリームの伝送を開始する前にはＡＤＤＴＳ処理とＡＤＤＧＡ処理の両方を完了させておかねばならない。また、現在のドラフトではこれらの処理を開始できる局は以下のように規定されている。
（方式１）ダウンリンクストリーム
ＡＤＤＴＳ処理：ｎｏｎ−ＡＰ  ＱＳＴＡ（ストリーム受信局）９０２が開始する。
ＡＤＤＧＡ処理：ストリーム送信局（ＨＣ）９０１が開始する。
（方式２）アップリンクストリーム
ＡＤＤＴＳ処理：ｎｏｎ−ＡＰ  ＱＳＴＡ（ストリーム送信局）９０２が開始する。
ＡＤＤＧＡ処理：ストリーム送信局（ｎｏｎ−ＡＰ  ＱＳＴＡ）９０２が開始する。
（方式３）ダイレクトリンクストリーム
ＡＤＤＴＳ処理：ｎｏｎ−ＡＰ  ＱＳＴＡ（ストリーム送信局）９０２が開始する。
ＡＤＤＧＡ処理：ストリーム送信局（ｎｏｎ−ＡＰ  ＱＳＴＡ）９０２が開始する。
なお、ＡＤＤＴＳ処理とＡＤＤＧＡ処理を行う順序については、ＡＤＤＴＳ処理を先に行うべきであると規定されているが、必須ではない。
（ＡＤＤＴＳ処理の詳細）
ＡＤＤＴＳ処理について、図１５を参照しながら述べる。ここでＳＭＥ（Ｓｔａｔｉｏｎ  Ｍａｎａｇｅｍｅｎｔ  Ｅｎｔｉｔｙ）とは、通信階層を問わず無線局の機能を管理するエンティティを表す。またＭＬＭＥ−で始まる用語は、ＭＡＣ層（正確にはＭＬＭＥ−ＭＡＣ  ｓｕｂＬａｙｅｒ  Ｍａｎａｇｅｍｅｎｔ  Ｅｎｔｉｔｙ）がＳＭＥに提供するサービスの要素（サービスプリミティブ）を表す。またＡＤＤＴＳ処理の説明においても後述のＡＤＤＧＡ処理の説明においても、ストリーム送信局をｎｏｎ−ＡＰ  ＱＳＴＡ１、ストリーム受信局をｎｏｎ−ＡＰ  ＱＳＴＡ２として説明する。
ダイレクトリンクストリームの場合のＡＤＤＴＳ処理は以下の手順で行われる。
（ＴＳＰＥＣ作成）
ストリーム送信局であるｎｏｎ−ＡＰ  ＱＳＴＡ１のＳＭＥでＴＳＰＥＣを作成する（Ｓ１００１）。
（ＭＬＭＥ−ＡＤＤＴＳ．ｒｅｑｕｅｓｔ）
ストリーム送信局であるｎｏｎ−ＡＰ  ＱＳＴＡ１のＳＭＥがＴＳＰＥＣ等の情報をパラメータとして、ＭＬＭＥ−ＡＤＤＴＳ．ｒｅｑｕｅｓｔを実行する（Ｓ１００２）。
（ＡＤＤＴＳ  ｒｅｑｕｅｓｔフレームの送信）
ストリーム送信局であるｎｏｎ−ＡＰ  ＱＳＴＡ１のＭＡＣではＳＭＥより通知されたＴＳＰＥＣや宛先のアドレス等の情報を含めて、ＡＤＤＴＳ  ｒｅｑｕｅｓｔフレームを作成し、ＨＣ宛に送信する（Ｓ１００３）。
（ＭＬＭＥ−ＡＤＤＴＳ．ｉｎｄｉｃａｔｉｏｎ）
ＨＣのＭＡＣは、受信したＡＤＤＴＳ  ｒｅｑｕｅｓｔフレームを解析し、ＭＬＭＥ−ＡＤＤＴＳ．ｉｎｄｉｃａｔｉｏｎを実行する。この時、ＨＣのＳＭＥにはＭＡＣで解析して得られたＴＳＰＥＣ等の情報がパラメータとして通知される（Ｓ１００４）。
（ＴＳＰＥＣ受け入れ可否判定）
ＨＣのＳＭＥはＭＡＣより通知されたＴＳＰＥＣを受信するとそのＴＳＰＥＣを受け入れ可能かどうかの判定を行う（Ｓ１００５）。判定は他のストリームの伝送との兼ね合い等で行う。例えば、他のストリームによって帯域が既に使用されており残りの帯域が要求されたＴＳＰＥＣを満たせない場合には、ＴＳＰＥＣの受け入れが不可能であるという判定を行う。ここでは、ＴＳＰＥＣが受け入れられたものとして話を進める。
（ＭＬＭＥ−ＡＤＤＴＳ．ｒｅｓｐｏｎｓｅ）
ＨＣのＳＭＥはＭＬＭＥ−ＡＤＤＴＳ．ｒｅｓｐｏｎｓｅを実行する（Ｓ１００６）。この時、Ｒｅｓｕｌｔ  Ｃｏｄｅ、ＴＳＰＥＣ等の情報がＭＡＣに通知される。Ｒｅｓｕｌｔ  ＣｏｄｅはＴＳＰＥＣが受け入れられたかどうか、また、受け入れられなかった場合にはその理由を示す値である。Ｒｅｓｕｌｔ  Ｃｏｄｅが受け入れを示している場合は、ＴＳＰＥＣにはＡＤＤＴＳ  ｒｅｑｕｅｓｔフレームで受信したものと同じものを含める。
（ＡＤＤＴＳ  ｒｅｓｐｏｎｓｅフレームの送信）
ＨＣのＭＡＣではＳＭＥより通知されたＴＳＰＥＣやＲｅｓｕｌｔ  Ｃｏｄｅ等の情報を含めてＡＤＤＴＳ  ｒｅｓｐｏｎｓｅフレームを作成し、ストリーム受信局宛に送信する（Ｓ１００７）。
（ＭＬＭＥ−ＡＤＤＴＳ．ｃｏｎｆｉｒｍ）
ストリーム送信局であるｎｏｎ−ＡＰ  ＱＳＴＡ１のＭＡＣは、受信したＡＤＤＴＳ  ｒｅｓｐｏｎｓｅフレームを解析し、ＭＬＭＥ−ＡＤＤＴＳ．ｃｏｎｆｉｒｍを実行する（Ｓ１００８）。この時、受信局のＳＭＥにはＭＡＣで解析して得られたＴＳＰＥＣやＲｅｓｕｌｔ  Ｃｏｄｅ等の情報がパラメータとして通知される。また、このときＭＡＣがストリームを識別するためのＴＩＤ（ｔｒａｆｆｉｃ  ｉｄｅｎｔｉｆｉｅｒ）と呼ばれるストリーム識別子も通知される。
以上のような手順により、ダイレクトリンクストリームに対するＡＤＤＴＳ処理が実行される。
（ＡＤＤＧＡ処理の詳細）
ＡＤＤＧＡ処理について、図１６を参照しながら述べる。
ダイレクトリンクストリームの場合のＡＤＤＧＡ処理は以下の手順で行われる。
（Ｔｒａｎｓｍｉｔ  Ｂｕｆｆｅｒ  Ｓｉｚｅ決定）
ストリーム送信局であるｎｏｎ−ＡＰ  ＱＳＴＡ１のＳＭＥはＴｒａｎｓｍｉｔ  Ｂｕｆｆｅｒ  Ｓｉｚｅを決定する（Ｓ１１０１）。
（ＭＬＭＥ−ＡＤＤＧＡ．ｒｅｑｕｅｓｔ）
ストリーム送信局であるｎｏｎ−ＡＰ  ＱＳＴＡ１のＳＭＥはＭＬＭＥ−ＡＤＤＧＡ．ｒｅｑｕｅｓｔを実行する（Ｓ１１０２）。パラメータとしてＴＩＤやＴｒａｎｓｍｉｔ  Ｂｕｆｆｅｒ  Ｓｉｚｅを指定する。
（ＡＤＤＧＡ  ｒｅｑｕｅｓｔフレームの送信）
ストリーム送信局であるｎｏｎ−ＡＰ  ＱＳＴＡ１のＭＡＣではＳＭＥより通知されたＴＩＤやＴｒａｎｓｍｉｔ  Ｂｕｆｆｅｒ  Ｓｉｚｅ等の情報を含めて、ＡＤＤＧＡ  ｒｅｑｕｅｓｔフレームを作成し、ストリーム受信局であるｎｏｎ−ＡＰ  ＱＳＴＡ２宛に送信する（Ｓ１１０３）。
（ＭＬＭＥ−ＡＤＤＧＡ．ｉｎｄｉｃａｔｉｏｎ）
ストリーム受信局であるｎｏｎ−ＡＰ  ＱＳＴＡ２のＭＡＣは、受信したＡＤＤＧＡ  ｒｅｑｕｅｓｔフレームを解析し、ＭＬＭＥ−ＡＤＤＧＡ．ｉｎｄｉｃａｔｉｏｎを実行する（Ｓ１１０４）。ＭＬＭＥ−ＡＤＤＧＡ．ｉｎｄｉｃａｔｉｏｎによってＴＩＤやＴｒａｎｓｍｉｔ  Ｂｕｆｆｅｒ  Ｓｉｚｅ等の情報が、ストリーム受信局であるｎｏｎ−ＡＰ  ＱＳＴＡ２のＳＭＥに通知される。
（Ｇｒｏｕｐ  ＡＣＫ使用判定）
ストリーム受信局であるｎｏｎ−ＡＰ  ＱＳＴＡ２のＳＭＥは、ＭＬＭＥ−ＡＤＤＧＡ．ｉｎｄｉｃａｔｉｏｎで通知された情報を元にＧｒｏｕｐ  ＡＣＫを使用するかどうかを判定する（Ｓ１１０５）。判定結果からＭＬＭＥ−ＡＤＤＧＡ．ｒｅｓｐｏｎｓｅのＲｅｓｕｌｔ  Ｃｏｄｅを決定する。Ｇｒｏｕｐ  ＡＣＫを使用するかどうか、また、使用しない場合はその理由からＲｅｓｕｌｔ  Ｃｏｄｅを決定する。Ｇｒｏｕｐ  ＡＣＫを使用すると判定した場合は、実際にＧｒｏｕｐ  ＡＣＫを送信する際に使用するために、通知されたＴＩＤやＴｒａｎｓｍｉｔ  Ｂｕｆｆｅｒ  Ｓｉｚｅ等を記憶しておく。
（Ｇｒｏｕｐ  ＡＣＫ  Ｐｏｌｉｃｙ及びＲｅ−ｏｒｄｅｒｉｎｇ  Ｂｕｆｆｅｒ  Ｓｉｚｅ決定）
ストリーム受信局であるｎｏｎ−ＡＰ  ＱＳＴＡ２のＳＭＥは、Ｇｒｏｕｐ  ＡＣＫ  Ｐｏｌｉｃｙを決定する（Ｓ１１０６）。ｉｍｍｉｄｉａｔｅ  Ｇｒｏｕｐ  ＡＣＫを使用するかｄｅｌａｙｅｄ  Ｇｒｏｕｐ  ＡＣＫを使用するかは、受信局の実装方法によって決まる。ここでは、どちらのＧｒｏｕｐ  ＡＣＫ  Ｐｏｌｉｃｙを使用するかと言う情報を、ＳＭＥが予め何らかの方法で取得しているものとする。
さらに、Ｒｅ−ｏｒｄｅｒｉｎｇ  Ｂｕｆｆｅｒ  Ｓｉｚｅを決定する（Ｓ１１０６）。
（ＭＬＭＥ−ＡＤＤＧＡ．ｒｅｓｐｏｎｓｅ）
ストリーム受信局であるｎｏｎ−ＡＰ  ＱＳＴＡ２のＳＭＥはＭＬＭＥ−ＡＤＤＧＡ．ｒｅｓｐｏｎｓｅを実行する（Ｓ１１０７）。ＴＩＤ、Ｒｅｓｕｌｔ  Ｃｏｄｅ、Ｇｒｏｕｐ  ＡＣＫ  Ｐｏｌｉｃｙ、Ｒｅ−ｏｒｄｅｒｉｎｇ  Ｂｕｆｆｅｒ  Ｓｉｚｅ等がＭＬＭＥ−ＡＤＤＧＡ．ｒｅｓｐｏｎｓｅのパラメータとしてＭＡＣに通知される。
（ＡＤＤＧＡ  ｒｅｓｐｏｎｓｅフレームの送信）
ストリーム受信局であるｎｏｎ−ＡＰ  ＱＳＴＡ２のＭＡＣではＳＭＥより通知されたＴＩＤ、Ｒｅｓｕｌｔ  Ｃｏｄｅ、Ｇｒｏｕｐ  ＡＣＫ  Ｐｏｌｉｃｙ、Ｒｅ−ｏｒｄｅｒｉｎｇ  Ｂｕｆｆｅｒ  Ｓｉｚｅ等の情報を含めて、ＡＤＤＧＡ  ｒｅｓｐｏｎｓｅフレームを作成し、ストリーム送信局であるｎｏｎ−ＡＰ  ＱＳＴＡ１宛に送信する（Ｓ１１０８）。
（ＭＬＭＥ−ＡＤＤＧＡ．ｃｏｎｆｉｒｍ）
ストリーム送信局であるｎｏｎ−ＡＰ  ＱＳＴＡ１のＭＡＣは、受信したＡＤＤＧＡ  ｒｅｓｐｏｎｓｅフレームを解析し、ＭＬＭＥ−ＡＤＤＧＡ．ｃｏｎｆｉｒｍを実行する（Ｓ１１０９）。ＭＬＭＥ−ＡＤＤＧＡ．ｃｏｎｆｉｒｍによってＴＩＤ、Ｒｅｓｕｌｔ  Ｃｏｄｅ、Ｇｒｏｕｐ  ＡＣＫ  Ｐｏｌｉｃｙ、Ｒｅ−ｏｒｄｅｒｉｎｇ  Ｂｕｆｆｅｒ  Ｓｉｚｅ等が、ＳＭＥに通知される。
以上のような手順により、ダイレクトリンクストリームに対するＡＤＤＧＡ処理が実行される。
ここで、従来技術（Ｄｒａｆｔ  Ｓｕｐｐｌｅｍｅｎｔ  ｔｏ  ＳＴＡＮＤＡＲＤ  ＦＯＲ  Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎｓ  ａｎｄ  Ｉｎｆｏｒｍａｔｉｏｎ  Ｅｘｃｈａｎｇｅ  Ｂｅｔｗｅｅｎ  Ｓｙｓｔｅｍｓ−ＬＡＮ／ＭＡＮ  Ｓｐｅｃｉｆｉｃ  Ｒｅｑｕｉｒｅｍｅｎｔｓ−Ｐａｒｔ  １１：Ｗｉｒｅｌｅｓｓ  Ｍｅｄｉｕｍ  Ａｃｃｅｓｓ  Ｃｏｎｔｒｏｌ（ＭＡＣ）ａｎｄ  Ｐｈｙｓｉｃａｌ  Ｌａｙｅｒ（ＰＨＹ）ｓｐｅｃｉｆｉｃａｔｉｏｎｓ：Ｍｅｄｉｕｍ  Ａｃｃｅｓｓ  Ｃｏｎｔｒｏｌ（ＭＡＣ）Ｅｎｈａｎｃｅｍｅｎｔｓ  ｆｏｒ  Ｑｕａｌｉｔｙ  ｏｆ  Ｓｅｒｖｉｃｅ（ＱｏＳ），ＩＥＥＥ  Ｓｔｄ  ８０２．１１ｅ／Ｄ４．０，Ｎｏｖｅｍｂｅｒ，２００２）によると、（方式２）アップリンクストリーム及び（方式３）ダイレクトリンクストリームにおいては、ＡＤＤＴＳ処理とＡＤＤＧＡ処理を開始する局が同一であるので、問題がない。
ところが、（方式１）ダウンリンクストリームにおいては、ＡＤＤＴＳ処理とＡＤＤＧＡ処理を開始する局が同一ではないため、以下のような問題ＡとＢとが発生する。
（問題Ａ）
ＡＤＤＴＳ処理とＡＤＤＧＡ処理との両方をストリーム送信局またはストリーム受信局の何れか一方のトリガで開始させることができない。つまり、一つの局がＡＤＤＴＳ処理とＡＤＤＧＡ処理を開始させる場合は、一方の処理が終了してから他方を行う事が可能だが、別の局が処理を開始するので、どのようなタイミングで双方が処理を開始すれば良いのかが不明確である。
（問題Ｂ）
ＡＤＤＴＳ処理とＡＤＤＧＡ処理との何れかの成功を確認した上で、他方の処理を行うという手順が実行できない。両方の処理が完了しなければ意味が無いので、一方が失敗したにも関わらず他方を開始させるのは効率が悪い。
ところで、上記においては、ダウンリンクストリームの通信をセットアップする際に必要なＡＤＤＴＳ処理とＡＤＤＧＡ処理とが、互いに異なる局から開始されるため、問題が生じる例を挙げた。しかしながら、これに限らず、装置間で行われる複数の処理について、各処理の開始トリガをかける局が異なるような場合であっても、同様である。
本発明は、上記の問題点に鑑みなされたものであり、その目的は、複数の処理の全てを、データ送信局または受信局の何れか一方のトリガで開始できるようにし、１つの処理が完了した後に他の処理の開始を行うようにすることで、効率よくデータ伝送の準備を完了させられる通信管理方法、通信装置、ネットワークシステム、要求信号、応答信号、プログラム、該プログラムを記録した記録媒体を提供することにある。
また、上記目的の一例として、ＡＤＤＴＳ処理とＡＤＤＧＡ処理との両方をストリーム送信局またはストリーム受信局の何れか一方のトリガで開始できるようにし、ＡＤＤＴＳ処理またはＡＤＤＧＡ処理の何れか一方が完了した後で他方の処理を開始するようにすることで、効率よくストリーム伝送の準備を完了させられる通信管理方法、通信装置、ネットワークシステム、要求信号、応答信号、プログラム、該プログラムを記録した記録媒体を提供することが挙げられる。
【発明の開示】
本発明に係る通信装置は、上記の目的を達成するために、複数の通信装置が通信ネットワークを介して接続されているネットワークシステムを構成する通信装置であって、他の通信装置との間でデータ通信を可能な状態とするために、他の通信装置との間で行われる複数の通信設定処理について、各通信設定処理にて最初に送信すべき信号を、自装置から他の通信装置に対して送信する送信手段を備えることを特徴としている。
上記の構成によれば、他の通信装置との間でデータ通信を可能な状態とするために、他の通信装置との間で行われる複数の通信設定処理について、各通信設定処理にて最初に送信すべき信号が、全て、前記通信装置から他の通信装置に送られることとなる。
それゆえ、上記最初に送信すべき信号の送信元を、全て前記通信装置とすることが可能となる。
したがって、各通信設定処理を開始するタイミング（つまりトリガのタイミング）を、通信装置のみで決定することができる。それゆえ、データ通信を可能な状態とするための処理を、効率よく行うことが可能となる。
また、本発明に係る通信装置は、複数の通信装置が通信ネットワークを介して接続されているネットワークシステムを構成する通信装置であって、他の通信装置との間でデータ通信を可能な状態とするために、他の通信装置との間で行われる複数の通信設定処理について、各通信設定処理にて最初に送信すべき信号を、他の通信装置から受信する受信手段と、前記最初に送信すべき信号に対する応答信号を、前記他の通信装置に送信する送信手段とを備えることを特徴としている。
上記の構成によれば、他の通信装置との間でデータ通信を可能な状態とするために、他の通信装置との間で行われる複数の通信設定処理について、各通信設定処理にて最初に送信すべき信号を、全て、前記他の通信装置から受信することとなる。さらに、前記最初に送信すべき信号に対して、応答信号を他の通信装置に送信する。
それゆえ、上記最初に送信すべき信号の受信元を、全て前記通信装置とすることが可能となる。つまり、上記最初に送信すべき信号の送信元が、全て前記他の通信装置とすることが可能となる。また、上記他の通信装置では、上記応答信号を受信することにより、各通信設定処理の状況を判断できる。
したがって、上記他の通信装置が各通信設定処理を開始するタイミング（つまりトリガのタイミング）を、他の通信装置のみで決定することができる。それゆえ、データ通信を可能な状態とするための処理を、効率よく行うことが可能となる。
また、本発明に係る通信装置は、上記の目的を達成するために、複数の通信装置が通信ネットワークを介して接続されているネットワークシステムを構成する通信装置であって、他の通信装置との間でデータ通信を可能な状態とするために、前記他の通信装置から送信される、第１の通信設定処理を要求する第１要求信号を受信する受信手段と、前記第１要求信号の要求内容を承認するか否かを判定する判定手段と、前記他の通信装置との間でデータ通信を可能な状態とするために、前記他の通信装置に対して、第２の通信設定処理を要求する第２要求信号を送信する送信手段とを備え、前記判定手段が前記要求内容を承認した場合に、前記送信手段が、前記第２要求信号を前記他の通信装置に送信することを特徴としている。
上記の構成によれば、判定手段が、第１要求信号の要求内容について、要求内容を承認するか否かを判定する。また、判定手段が上記要求内容を承認した場合に、送信手段が、第２要求信号を通信装置に送信する。
つまり、自装置が、上記要求内容を承認したことを条件に、前記第２要求信号を送信する。
したがって、前記第２要求信号の送信タイミングを自ら判断することが可能となる。つまり、第２の通信設定処理についても、他の通信装置による第１要求信号の送信をトリガして行うことができる。
それゆえ、データ通信を可能な状態とするための処理を、効率よく行うことが可能となる。
また、本発明に係る通信装置は、上記の目的を達成するために、複数の通信装置が通信ネットワークを介して接続されているネットワークシステムを構成する通信装置であって、前記他の通信装置との間でデータ通信を可能な状態とするために、前記他の通信装置に対して、所定の通信設定処理を要求する要求信号を送信する送信手段と、前記他の通信装置から、前記要求信号に基づく応答信号を受信する受信手段と、前記応答信号に基づいて、所定の通信設定処理が行われたか否かを判定する判定手段と、前記判定手段による判定結果を、前記他の通信装置に対して通知する通知手段とを備えることを特徴としている。
上記の構成によれば、上記通知手段により、前記判定手段による判定結果が、前記他の通信装置に対して通知される。つまり、第１の設定処理が行われたか否かが、自装置（通信装置）から他の通信装置に通知される。
したがって、他の通信装置では、上記判定結果に基づいて、前記所定の設定処理が行われたことを認識することにより、他の通信装置は、データ通信を可能な状態とするために、上記通信装置に対して行う他の通信設定処理の開始タイミングを判断できる。つまり、上記他の通信設定処理についても、上記通信装置による判定結果の通知をトリガして行うことができる。
それゆえ、データ通信を可能な状態とするための処理を、効率よく行うことが可能となる。
本発明のさらに他の目的、特徴、および優れた点は、以下に示す記載によって十分に理解されるであろう。また、本発明の利益は、添付図面を参照した次の説明で明白になるであろう。
【図面の簡単な説明】  図１は、本発明の第１の実施の形態におけるタイミング図である。
図２は、本発明の第１の実施の形態におけるパケットフォーマットの１つ目の例を示す図である。
図３は、本発明の第１の実施の形態におけるパケットフォーマットの２つ目の例を示す図である。
図４は、本発明の第２の実施の形態におけるタイミング図である。
図５は、本発明の第３の実施の形態におけるタイミング図である。
図６は、本発明の第１の実施の形態、第２の実施の形態、第３の実施の形態における機器構成を示す図である。
図７は、本発明におけるｎｏｎ−ＡＰ  ＱＳＴＡのブロック図である。
図８は、本発明におけるＨＣのブロック図である。
図９は、第１の実施の形態における他のタイミング図である。
図１０は、第１の実施の形態におけるさらに他のタイミング図である。
図１１は、第２の実施の形態における他のタイミング図である。
図１２は、第２の実施の形態におけるさらに他のタイミング図である。
図１３は、第３の実施の形態における他のタイミング図である。
図１４は、従来技術のデータ伝送方式を示す図である。
図１５は、従来技術のＡＤＤＴＳ処理のタイミング図である。
図１６は、従来技術のＡＤＤＧＡ処理のタイミング図である。
図１７は、従来技術の帯域管理の手法を示す図である。
【発明を実施するための最良の形態】  本発明の実施の各形態について図１ないし図１３に基づいて説明すれば、以下の通りである。
以下の各実施の形態はＩＥＥＥ  Ｓｔｄ  ８０２．１１ｅ／Ｄ４．０，２００２において、ダウンリンクストリームの伝送（すなわちＨＣがストリーム送信局であり、ｎｏｎ−ＡＰ  ＱＳＴＡがストリーム受信局である）を行う場合に、本発明を実施した例である。各実施の形態における機器構成は同一であり図６の通りである。また、ストリーム受信局であるｎｏｎ−ＡＰ  ＱＳＴＡ６０２のブロック図を図７に、ストリーム送信局であるＨＣ６０１のブロック図を図８に示す。
まず、ｎｏｎ−ＡＰ  ＱＳＴＡ６０２の構成について、図７を用いて説明する。
アプリケーション７０２はＡＤＤＴＳ処理やＡＤＤＧＡ処理の開始をＳＭＥ７０３に命令したり、ストリームを生成してそれをデータパケットとして伝送するように後述のＭＡＣ７０５に命令したりするものである。（このルートは図示していない。）ユーザは基本的にはアプリケーション７０２を操作してストリームの伝送を制御する。アプリケーションの例としては、コンピュータで動作している映像伝送用ソフトウェアが考えられる。
また、ＳＭＥ７０３（ｓｔａｔｉｏｎ  ｍａｎａｇｅｍｅｎｔ  ｅｎｔｉｔｙ）は、通信階層を問わず無線局の機能を管理するエンティティを表す。
ＭＬＭＥ７０４（ＭＡＣ  ｓｕｂｌａｙｅｒ  ｍａｎａｇｅｍｅｎｔ  ｅｎｔｉｔｙ）は、後述のＭＡＣ７０５の動作を管理するエンティティであり、ＳＭＥ７０３とＭＡＣ７０５の間のインターフェイスを提供する。具体的にはＭＬＭＥは機能ごとにサービスプリミティブを設け、ＳＭＥ７０３はそのサービスプリミティブを指定することによりＭＡＣ７０５の提供する機能を使用することができる。このときに、パラメータを指定することもできる。サービスプリミティブの例としてはＭＬＭＥ−ＡＤＤＴＳ．ｒｅｑｕｅｓｔ、ＭＬＭＥ−ＡＤＤＴＳ．ｒｅｓｐｏｎｓｅ、ＭＬＭＥ−ＡＤＤＴＳ．ｉｎｄｉｃａｔｉｏｎ、ＭＬＭＥ−ＡＤＤＴＳ．ｃｏｎｆｉｒｍ、ＭＬＭＥ−ＡＤＤＧＡ．ｒｅｑｕｅｓｔ、ＭＬＭＥ−ＡＤＤＧＡ．ｒｅｓｐｏｎｓｅ、ＭＬＭＥ−ＡＤＤＧＡ．ｉｎｄｉｃａｔｉｏｎ、ＭＬＭＥ−ＡＤＤＧＡ．ｃｏｎｆｉｒｍがある。
ＭＡＣ７０５はサービスプリミティブで指定された機能に応じて、パケットを生成して、無線部７１０にそのパケットを伝送するように命令する。パケットのフィールドに含まれている値によって、通信局間で情報をやり取りし、通信の制御やストリームの伝送が行われる。パケットの例としては、ＡＤＤＴＳ  ｒｅｑｕｅｓｔ、ＡＤＤＴＳ  ｒｅｓｐｏｎｓｅ、ＡＤＤＧＡ  ｒｅｑｕｅｓｔ、ＡＤＤＧＡ  ｒｅｓｐｏｎｓｅが有る。パケット生成部７０６、パケット解析部７０８、受信バッファ７０９、送信バッファ７０７はＭＡＣ７０５に含まれる。
無線部７１０では、ディジタル信号としてＭＡＣ７０５で生成されたパケットを無線信号に変換したり、送信されてきた無線信号をＭＡＣ７０５で認識できるディジタル信号に変換したりする。
次に、ＨＣ６０１の構成について、図８を用いて説明する。
ＨＣ６０１は基本的にはｎｏｎ−ＡＰ  ＱＳＴＡ６０２と同じ構成であるが、ＳＭＥ８０３に帯域管理部８１１が設けられている点が異なる。帯域管理部８１１は先に述べたような各通信局に対する送信権の付与順序と付与時間のスケジューリングを行う。
なお、通信装置が、通信局である場合には、上記ＳＭＥ７０３、ＭＬＭＥ７０４、並びに、ＭＡＣ７０５のパケット生成部７０６および送信バッファ７０７が、請求の範囲に記載の送信手段に該当する。また、上記ＳＭＥ７０３、ＭＬＭＥ７０４、並びに、ＭＡＣ７０５のパケット解析部７０８および受信バッファ７０９が、請求の範囲に記載の受信手段に該当する。
また、通信装置が、中央制御局である場合には、上記ＳＭＥ８０３、ＭＬＭＥ８０４、並びに、ＭＡＣ８０５のパケット生成部８０６および送信バッファ８０７が、請求の範囲に記載の送信手段に該当する。また、上記ＳＭＥ８０３、ＭＬＭＥ８０４、並びに、ＭＡＣ８０５のパケット解析部８０８および受信バッファ８０９が、請求の範囲に記載の受信手段に該当する。
［実施の形態１］
本実施の形態では、上記のＡＤＤＴＳ処理とＡＤＤＧＡ処理との両方をストリーム送信局またはストリーム受信局の何れか一方のトリガで開始できるようにする。この解決策としては以下の二つが考えられる。
（解決策１）ＡＤＤＴＳ処理をＨＣから開始できるようにする。
（解決策２）ＡＤＤＧＡ処理をｎｏｎ−ＡＰ  ＱＳＴＡから開始できるようにする。
ここで、上記解決策１については、他に好ましくない影響を及ぼすため、本発明では考察せず、解決策２について考察する。
上記解決策２を単純に実行すると以下の不都合が生じる。
まず、ストリーム受信局がＡＤＤＴＳ処理を実行した後、同じ局がＡＤＤＧＡ処理を開始するとする。この場合、ストリーム受信局がストリーム送信局に、Ｇｒｏｕｐ  ＡＣＫ  Ｐｏｌｉｃｙ及びＲｅ−ｏｒｄｅｒｉｎｇ  Ｂｕｆｆｅｒ  Ｓｉｚｅを通知しなければならない。しかし、現在のドラフトにおけるＡＤＤＧＡ  ｒｅｑｕｅｓｔフレームはストリーム送信局からストリーム受信局に宛てて送信する事だけが想定されているため、これらの情報を含めるためのフィールドが存在しない。
同様に、ストリーム送信局はストリーム受信局に、Ｔｒａｎｓｍｉｔ  Ｂｕｆｆｅｒ  Ｓｉｚｅを通知しなければならないが、ＡＤＤＧＡ  ｒｅｓｐｏｎｓｅフレームにはこの情報を含めるためのフィールドが存在しない。
すなわち、現在ドラフトで規定されているＡＤＤＧＡ  ｒｅｑｕｅｓｔフレームまたはＡＤＤＧＡ  ｒｅｓｐｏｎｓｅフレームを送信するだけでは、ＡＤＤＧＡ処理を完了させるために必要な情報の通知を行うことができない。
従って、本発明では、現在のドラフトの規定を変更して、ＡＤＤＧＡ  ｒｅｑｕｅｓｔフレームまたはＡＤＤＧＡ  ｒｅｓｐｏｎｓｅフレームの両方について、ストリーム送信局からストリーム受信局に対して通知する情報と、ストリーム受信局からストリーム送信局に対して通知する情報との両方を通知するためのフィールドを設けるようにする。
また、これにより、ＡＤＤＧＡ  ｒｅｑｕｅｓｔフレームとＡＤＤＧＡ  ｒｅｓｐｏｎｓｅフレームにおいて、無効なフィールドが発生することになる。本発明では、この無効なフィールドを判別するための手段も提供する。以下、具体的に説明する。
本発明の第１の実施の形態として、ストリーム送信局からストリーム受信局に対して通知する情報と、ストリーム受信局からストリーム送信局に対して通知する情報との両方をＡＤＤＧＡ  ｒｅｑｕｅｓｔ及びＡＤＤＧＡ  ｒｅｓｐｏｎｓｅの両方に含められるようにする事により、ＡＤＤＧＡ  ｒｅｑｕｅｓｔをストリーム受信局からでも送信できるようにする方法について述べる。これにより、ＡＤＤＧＡ処理の開始トリガをかけるアプリケーションとＡＤＤＴＳ処理の終了通知を受信するアプリケーションが同一となるので、ＡＤＤＴＳ処理が完了した事を確認した後でＡＤＤＧＡ処理を行う事が可能となる。
全体の大まかな流れは、ストリーム受信局６０２のアプリケーション７０２がストリーム定義要求を行い、ＡＤＤＴＳ処理が完了して、アプリケーション７０２にストリーム定義応答が返ってきた時点で、アプリケーション７０２は送受信準備要求を行い、ストリーム受信局６０２からＡＤＤＧＡ処理が行われるというものである。
ここで、処理の詳細を図１、図６、図７、図８に基づいて説明する。
（ストリーム定義要求）
ストリーム受信局であるｎｏｎ−ＡＰ  ＱＳＴＡ６０２のアプリケーション７０２はストリーム定義要求をＳＭＥ７０３に対して送信する（Ｓ１０１）。このとき、送信されるストリームのエンコード形式やビットレート等の情報を含めて通知される。
（ＡＤＤＴＳ処理）
その後ストリーム受信局であるｎｏｎ−ＡＰ  ＱＳＴＡ６０２とＨＣ６０１の間でＡＤＤＴＳ処理が行われる（Ｓ１０２〜Ｓ１０９）。この処理については、従来の技術において説明したものと同様なので、省略する。従来の技術ではダイレクトリンクストリームの例を述べたので、ストリーム送信局がＡＤＤＴＳ処理を行っていたが、本実施の形態においては、ダウンリンクストリームについて述べているので、ストリーム受信局６０２がＡＤＤＴＳ処理を行っている点が異なる。
（ストリーム定義応答）
ＡＤＤＴＳ処理が終了すると、ストリーム受信局であるｎｏｎ−ＡＰ  ＱＳＴＡ６０２のＳＭＥ７０３はストリーム定義応答をアプリケーションに対して送信する（Ｓ１１０）。このとき、アプリケーション７０２において、ストリームを特定するための情報としてＴＳＰＥＣに含まれているＴＩＤを含めて通知を行う。
このときＭＡＣ７０５より通知されたＲｅｓｕｌｔ  Ｃｏｄｅを通知してもよい。また、Ｒｅｓｕｌｔ  Ｃｏｄｅを元に別の情報に変換した上でアプリケーションに通知しても良い。例えば、ＨＣ６０１においてＴＳＰＥＣが受け入れられたかどうかという事だけを通知することが考えられる。また、Ｒｅｓｕｌｔ  Ｃｏｄｅが成功を示す値だった場合のみストリーム定義応答を送信し、Ｒｅｓｕｌｔ  Ｃｏｄｅが失敗を示す値だった場合は、ストリーム定義応答を送信しない事をも考えられる。この場合、アプリケーションはストリーム定義要求を行ってから一定時間が経過してもストリーム定義応答を受信できなかった場合にはストリーム定義要求が失敗したものと判定する事が考えられる。
ＡＤＤＴＳ処理が失敗したと判定された場合、ＳＭＥ７０３は先のストリームと同じストリームの送信設定を変更して再度ＡＤＤＴＳ処理を行っても良い。例えば、ビットレートをより低い値として要求すれば、必要帯域が少なくなるので、ＨＣ６０１の帯域管理部８１１に受け入れられる可能性がある。また、先のストリームの定義はあきらめて、別のストリームについてＡＤＤＴＳ処理を行っても良い。また、ストリームの定義に失敗した事をユーザに提示して、ユーザからの次の操作が行われるまでは何もしない事が考えられる。このとき、失敗した理由をユーザに提示しても良い。
ここでは、ストリーム定義要求が成功したとアプリケーションにおいて判定されたものとして話を進める。
（送受信準備要求）
ストリーム受信局であるｎｏｎ−ＡＰ  ＱＳＴＡ６０２のアプリケーション７０２は送受信準備要求をＳＭＥ７０３に対して送信する（Ｓ１１１）。このとき、どのストリームに対する送受信準備要求であるかをＳＭＥ７０３で判別するために、ＴＩＤを通知する。ＴＩＤはストリーム定義応答に含まれているものを指定する。本実施の形態においては、送受信準備要求によりＧｒｏｕｐ  ＡＣＫの送受信準備のみを行っているが、この時に、ストリーム送受信のための準備のための別の処理も行って良い。
ここでさらに、送受信準備要求を行うストリームにＧｒｏｕｐ  ＡＣＫを使用して欲しいかどうかという情報を通知しても良い。また、アプリケーション７０２からはＧｒｏｕｐ  ＡＣＫを使用して欲しいかどうかを通知せずに、ＳＭＥ７０３が先に定義されているＴＳＰＥＣのパラメータから推定して、Ｇｒｏｕｐ  ＡＣＫを使用するかどうかを判断しても良い。
（Ｇｒｏｕｐ  ＡＣＫ  Ｐｏｌｉｃｙ及びＲｅ−ｏｒｄｅｒｉｎｇ  Ｂｕｆｆｅｒ  Ｓｉｚｅ決定）
ストリーム受信局であるｎｏｎ−ＡＰ  ＱＳＴＡ６０２のＳＭＥ７０３は、Ｇｒｏｕｐ  ＡＣＫ  Ｐｏｌｉｃｙを決定する（Ｓ１１２）。ｉｍｍｉｄｉａｔｅ  Ｇｒｏｕｐ  ＡＣＫ  Ｐｏｌｉｃｙを使用するかｄｅｌａｙｅｄ  Ｇｒｏｕｐ  ＡＣＫ  Ｐｏｌｉｃｙを使用するかは、受信局６０２の実装方法によって決まる。ここでは、どちらのＧｒｏｕｐ  ＡＣＫ  Ｐｏｌｉｃｙを使用するかと言う情報を、ＳＭＥ７０３が予め何らかの方法で取得しているものとする。
さらに、ストリーム受信局であるｎｏｎ−ＡＰ  ＱＳＴＡ６０２のＳＭＥ７０３は、Ｒｅ−ｏｒｄｅｒｉｎｇ  Ｂｕｆｆｅｒ  Ｓｉｚｅを決定する（Ｓ１１２）。これは、ＳＭＥ７０３が予め収集しておいた自局の情報と、先に定義されているＴＳＰＥＣから決定する。例えば、受信バッファで保持できる最大のバイト数と、ＴＳＰＥＣで定義されているＭａｘｉｍｕｍ  ＭＳＤＵ  Ｓｉｚｅ（そのストリームで送信されうる最大のＭＳＤＵのバイト数を示す。）から保持できるＭＳＤＵ数の最大値を推定し、その値をＲｅ−ｏｒｄｅｒｉｎｇ  Ｂｕｆｆｅｒ  Ｓｉｚｅとして使用する事が考えられる。
なお、ＳＭＥ７０３ではなく、アプリケーション７０２でＧｒｏｕｐ  ＡＣＫ  Ｐｏｌｉｃｙ及びＲｅ−ｏｒｄｅｒｉｎｇ  Ｂｕｆｆｅｒ  Ｓｉｚｅを決定した上でＳＭＥ７０３にそれを通知する構成としても良い。
（ＭＬＭＥ−ＡＤＤＧＡ．ｒｅｑｕｅｓｔ）
ストリーム受信局であるｎｏｎ−ＡＰ  ＱＳＴＡ６０２のＳＭＥ７０３はＭＬＭＥ−ＡＤＤＧＡ．ｒｅｑｕｅｓｔを実行する（Ｓ１１３）。従来では、ＭＬＭＥ−ＡＤＤＧＡ．ｒｅｑｕｅｓｔはストリーム送信局のみが実行する事が想定されており、ＭＬＭＥ−ＡＤＤＧＡ．ｒｅｑｕｅｓｔのパラメータとして、Ｇｒｏｕｐ  ＡＣＫ  Ｐｏｌｉｃｙ及びＲｅ−ｏｒｄｅｒｉｎｇ  Ｂｕｆｆｅｒ  Ｓｉｚｅは含まれていない。しかし、本実施の形態においては、ＭＬＭＥ−ＡＤＤＧＡ．ｒｅｑｕｅｓｔをストリーム受信局６０２からも実行できるように、Ｇｒｏｕｐ  ＡＣＫ  Ｐｏｌｉｃｙ及びＲｅ−ｏｒｄｅｒｉｎｇ  Ｂｕｆｆｅｒ  Ｓｉｚｅもパラメータに含まれているものとする。ＭＬＭＥ−ＡＤＤＧＡ．ｒｅｑｕｅｓｔによってＭＡＣ７０５にＧｒｏｕｐ  ＡＣＫ  Ｐｏｌｉｃｙ及びＲｅ−ｏｒｄｅｒｉｎｇ  Ｂｕｆｆｅｒ  Ｓｉｚｅが通知される。ＭＬＭＥ−ＡＤＤＧＡ．ｒｅｑｕｅｓｔには、ＴＩＤも含めて通知する。
（ＡＤＤＧＡ  ｒｅｑｕｅｓｔフレームの送信）
ストリーム受信局であるｎｏｎ−ＡＰ  ＱＳＴＡ６０２のＭＡＣ７０５ではＳＭＥ７０３より通知されたＧｒｏｕｐ  ＡＣＫ  Ｐｏｌｉｃｙ及びＲｅ−ｏｒｄｅｒｉｎｇ  Ｂｕｆｆｅｒ  Ｓｉｚｅ等の情報を含めて、ＡＤＤＧＡ  ｒｅｑｕｅｓｔフレームを作成し、ストリーム送信局であるＨＣ６０１宛に送信する（Ｓ１１４）。従来では、ＡＤＤＧＡ  ｒｅｑｕｅｓｔフレームはストリーム送信局からのみ送信する事が想定されており、ＡＤＤＧＡ  ｒｅｑｕｅｓｔフレームには、Ｇｒｏｕｐ  ＡＣＫ  Ｐｏｌｉｃｙ及びＲｅ−ｏｒｄｅｒｉｎｇ  Ｂｕｆｆｅｒ  Ｓｉｚｅのフィールドが含まれていない。しかし、本実施の形態においては、ＡＤＤＧＡ  ｒｅｑｕｅｓｔフレームをストリーム受信局からも送信できるように、Ｇｒｏｕｐ  ＡＣＫ  Ｐｏｌｉｃｙ及びＲｅ−ｏｒｄｅｒｉｎｇ  Ｂｕｆｆｅｒ  Ｓｉｚｅのフィールドが含まれているものとする。このときのＡＤＤＧＡ  ｒｅｑｕｅｓｔフレームのフィールド構成の例を図２及び図３に示す。図２及び図３についての詳細は後ほど述べる。
（ＭＬＭＥ−ＡＤＤＧＡ．ｉｎｄｉｃａｔｉｏｎ）
ストリーム送信局であるＨＣ６０１のＭＡＣ８０５は、受信したＡＤＤＧＡ  ｒｅｑｕｅｓｔフレームを解析し、ＭＬＭＥ−ＡＤＤＧＡ．ｉｎｄｉｃａｔｉｏｎを実行する（Ｓ１１５）。ＭＬＭＥ−ＡＤＤＧＡ．ｒｅｑｕｅｓｔと同様に、従来では、ＭＬＭＥ−ＡＤＤＧＡ．ｉｎｄｉｃａｔｉｏｎのパラメータとして、Ｇｒｏｕｐ  ＡＣＫ  Ｐｏｌｉｃｙ及びＲｅ−ｏｒｄｅｒｉｎｇ  Ｂｕｆｆｅｒ  Ｓｉｚｅは含まれていない。しかし、本実施の形態においては、Ｇｒｏｕｐ  ＡＣＫ  Ｐｏｌｉｃｙ及びＲｅ−ｏｒｄｅｒｉｎｇ  Ｂｕｆｆｅｒ  Ｓｉｚｅもパラメータに含んでいるものとする。ＭＬＭＥ−ＡＤＤＧＡ．ｉｎｄｉｃａｔｉｏｎによってＴＩＤと共に、Ｇｒｏｕｐ  ＡＣＫ  Ｐｏｌｉｃｙ及びＲｅ−ｏｒｄｅｒｉｎｇ  Ｂｕｆｆｅｒ  Ｓｉｚｅが、ＨＣ６０１のＳＭＥ８０３に通知される。
（Ｇｒｏｕｐ  ＡＣＫ使用判定）
ストリーム送信局であるＨＣ６０１のＳＭＥ８０３は、ＭＬＭＥ−ＡＤＤＧＡ．ｉｎｄｉｃａｔｉｏｎで通知された情報を元にＧｒｏｕｐ  ＡＣＫを使用するかどうかを判定する（Ｓ１１６）。たとえば、ＨＣ６０１がＧｒｏｕｐ  ＡＣＫの仕組みを実装していない場合は、Ｇｒｏｕｐ  ＡＣＫを使用しない事が考えられる。判定結果からＭＬＭＥ−ＡＤＤＧＡ．ｒｅｓｐｏｎｓｅのＲｅｓｕｌｔ  Ｃｏｄｅを決定する。従来は、Ｒｅｓｕｌｔ  Ｃｏｄｅはストリーム受信局からストリーム送信局宛に通知するものであるが、本実施の形態では、ストリーム送信局６０１からストリーム受信局６０２に通知するものとしている。よって、現在仕様で規定されている値だけでは、結果を示すのに不十分である可能性があるが、その場合は、新たな値を追加しても良い。Ｇｒｏｕｐ  ＡＣＫを使用すると判定した場合は、実際にＧｒｏｕｐ  ＡＣＫを送信する際に使用するために、通知されたＧｒｏｕｐ  ＡＣＫ  ＰｏｌｉｃｙやＲｅ−ｏｒｄｅｒｉｎｇ  Ｂｕｆｆｅｒ  Ｓｉｚｅ等を記憶しておく。
（Ｔｒａｎｓｍｉｔ  Ｂｕｆｆｅｒ  Ｓｉｚｅ決定）
ストリーム送信局であるＨＣ６０１のＳＭＥ８０３はＴｒａｎｓｍｉｔ  Ｂｕｆｆｅｒ  Ｓｉｚｅを決定する（Ｓ１１７）。これは、ＳＭＥ８０３が予め収集しておいた自局の情報と、先に定義されているＴＳＰＥＣから決定する。例えば、送信バッファで保持できる最大のバイト数と、ＴＳＰＥＣで定義されているＭａｘｉｍｕｍ  ＭＳＤＵ  Ｓｉｚｅから保持できるＭＳＤＵ数の最大値を推定し、その値をＴｒａｎｓｍｉｔ  Ｂｕｆｆｅｒ  Ｓｉｚｅとして使用する事が考えられる。なお、ストリーム受信局６０２からＡＤＤＧＡ  ｒｅｑｕｅｓｔフレームによって通知された情報を元に、Ｔｒａｎｓｍｉｔ  Ｂｕｆｆｅｒ  Ｓｉｚｅの値に補正を加えても良い。
（ＭＬＭＥ−ＡＤＤＧＡ．ｒｅｓｐｏｎｓｅ）
ストリーム送信局であるＨＣ６０１のＳＭＥ８０３はＭＬＭＥ−ＡＤＤＧＡ．ｒｅｓｐｏｎｓｅを実行する（Ｓ１１８）。従来では、ＭＬＭＥ−ＡＤＤＧＡ．ｒｅｓｐｏｎｓｅはストリーム受信局のみが実行する事が想定されており、ＭＬＭＥ−ＡＤＤＧＡ．ｒｅｓｐｏｎｓｅのパラメータとして、Ｔｒａｎｓｍｉｔ  Ｂｕｆｆｅｒ  Ｓｉｚｅは含まれていない。しかし、本実施の形態においては、ＭＬＭＥ−ＡＤＤＧＡ．ｒｅｓｐｏｎｓｅをストリーム送信局からも実行できるように、Ｔｒａｎｓｍｉｔ  Ｂｕｆｆｅｒ  Ｓｉｚｅもパラメータに含んでいるものとする。Ｒｅｓｕｌｔ  ＣｏｄｅやＴｒａｎｓｍｉｔ  Ｂｕｆｆｅｒ  Ｓｉｚｅ等がＭＬＭＥ−ＡＤＤＧＡ．ｒｅｓｐｏｎｓｅのパラメータとしてＭＡＣ８０５に通知される。
（ＡＤＤＧＡ  ｒｅｓｐｏｎｓｅフレームの送信）
ストリーム送信局であるＨＣ６０１のＭＡＣ８０５ではＳＭＥ８０３より通知されたＲｅｓｕｌｔ  ＣｏｄｅやＴｒａｎｓｍｉｔ  Ｂｕｆｆｅｒ  Ｓｉｚｅ等の情報を含めて、ＡＤＤＧＡ  ｒｅｓｐｏｎｓｅフレームを作成し、ストリーム受信局であるｎｏｎ−ＡＰ  ＱＳＴＡ６０２宛に送信する（Ｓ１１９）。従来では、ＡＤＤＧＡ  ｒｅｓｐｏｎｓｅフレームはストリーム受信局からのみ送信する事が想定されており、ＡＤＤＧＡ  ｒｅｓｐｏｎｓｅフレームには、Ｔｒａｎｓｍｉｔ  Ｂｕｆｆｅｒ  Ｓｉｚｅのフィールドが含まれていない。しかし、本実施の形態においては、ＡＤＤＧＡ  ｒｅｓｐｏｎｓｅフレームをストリーム送信局６０１からも送信できるようにするために、Ｔｒａｎｓｍｉｔ  Ｂｕｆｆｅｒ  Ｓｉｚｅのフィールドが含まれているものとする。このときのＡＤＤＧＡ  ｒｅｑｕｅｓｔフレームのフィールド構成の例を図２及び図３に示す。図２及び図３についての詳細は後ほど述べる。
（ＭＬＭＥ−ＡＤＤＧＡ．ｃｏｎｆｉｒｍ）
ストリーム受信局であるｎｏｎ−ＡＰ  ＱＳＴＡ６０２のＭＡＣ７０５は、受信したＡＤＤＧＡ  ｒｅｓｐｏｎｓｅフレームを解析し、ＭＬＭＥ−ＡＤＤＧＡ．ｃｏｎｆｉｒｍを実行する（Ｓ１２０）。ＭＬＭＥ−ＡＤＤＧＡ．ｒｅｓｐｏｎｓｅと同様に、従来では、ＭＬＭＥ−ＡＤＤＧＡ．ｃｏｎｆｉｒｍのパラメータとして、Ｔｒａｎｓｍｉｔ  Ｂｕｆｆｅｒ  Ｓｉｚｅは含まれていない。しかし、本実施の形態においては、Ｔｒａｎｓｍｉｔ  Ｂｕｆｆｅｒ  Ｓｉｚｅもパラメータに含んでいるものとする。ＭＬＭＥ−ＡＤＤＧＡ．ｃｏｎｆｉｒｍによってＴＩＤと共に、Ｔｒａｎｓｍｉｔ  Ｂｕｆｆｅｒ  Ｓｉｚｅが、ｎｏｎ−ＡＰ  ＱＳＴＡ６０２のＳＭＥ７０３に通知される。
（送受信準備応答）
ストリーム受信局であるｎｏｎ−ＡＰ  ＱＳＴＡ６０２のＳＭＥ７０３は送受信準備応答をアプリケーションに対して送信する（Ｓ１２１）。このときＭＡＣ７０５より通知されたＲｅｓｕｌｔ  Ｃｏｄｅを通知してもよい。また、Ｒｅｓｕｌｔ  Ｃｏｄｅを元に別の情報に変換した上でアプリケーションに通知しても良い。例えば、このストリームについてＧｒｏｕｐ  ＡＣＫが使用されるかどうかという事だけを通知することが考えられる。また、Ｒｅｓｕｌｔ  Ｃｏｄｅが成功を示す値だった場合のみ送受信準備応答を送信し、Ｒｅｓｕｌｔ  Ｃｏｄｅが失敗を示す値だった場合は、送受信準備応答を送信しない事をも考えられる。この場合、アプリケーション７０２は送受信準備要求を行ってから一定時間が経過しても送受信準備応答を受信できなかった場合には送受信準備要求が失敗した物と判定する事が考えられる。
ＡＤＤＧＡ処理が失敗したと判定された場合、そのストリームについては、ストリーム送信局であるＨＣ６０１からはＧｒｏｕｐ  ＡＣＫを使用せず、Ｎｏｒｍａｌ  ＡＣＫやＡＣＫ無しを前提としてＱｏＳ  Ｄａｔａパケットが送信されてくることになる。この場合、ストリーム受信局であるｎｏｎ−ＡＰ  ＱＳＴＡ６０２は各パケットに入っている情報からＮｏｒｍａｌ  ＡＣＫが要求さているかどうかを判定して、然るべき応答をする。また、ＡＤＤＧＡ処理が失敗した場合、先のストリームと同じストリームの送信設定を変更して再度、送受信準備要求を行っても良い。例えば、Ｇｒｏｕｐ  ＡＣＫ  ＰｏｌｉｃｙやＲｅ−ｏｒｄｅｒｉｎｇ  Ｂｕｆｆｅｒ  Ｓｉｚｅを変更して再度、送受信準備要求を行う事が考えられる。また、ＡＤＤＧＡ処理が失敗した事をユーザに提示して、ユーザによって次の操作が行われるまでは何もしない事が考えられる。
ところで、図９に示すとおり、ｎｏｎ−ＡＰ  ＱＳＴＡにおけるＳＭＥがＭＬＭＥ−ＡＤＤＴＳ．ｃｏｎｆｉｒｍを受信したら、アプリケーションにそのことを通知せずに、自主的にＭＬＭＥ−ＡＤＤＧＡ．ｒｅｑｕｅｓｔを発行しても良い。この場合、ＳＭＥはストリーム定義応答をＭＬＭＥ−ＡＤＤＧＡ．ｃｏｎｆｉｒｍを受信した後で発行し、アプリケーションはストリーム定義終了通知を受信しても送受信準備要求を発行しないことが考えられる。このとき、ＡＤＤＴＳ処理やＡＤＤＧＡ処理の結果をストリーム定義応答に含めてアプリケーションに通知しても良い。
また、ＭＬＭＥ−ＡＤＤＴＳ．ｃｏｎｆｉｒｍのＲｅｓｕｌｔＣｏｄｅが失敗を示していた場合、ＭＬＭＥ−ＡＤＤＧＡ．ｒｅｑｕｅｓｔを省略して、ストリーム定義応答を発行しても良い。このとき、ＡＤＤＴＳ処理に失敗した旨をストリーム定義応答に含めてアプリケーションに通知しても良い。
さらに、図１０に示すとおり、ＡＤＤＴＳ  ｒｅｓｐｏｎｓｅフレームを受信したことをトリガとして、ｎｏｎ−ＡＰ  ＱＳＴＡにおけるＭＡＣが自主的にＡＤＤＧＡ  ｒｅｑｕｅｓｔフレームを送信しても良い。この場合、上記ＭＡＣはＡＤＤＧＡ  ｒｅｓｐｏｎｓｅフレームを受信し、ＡＤＤＴＳ処理とＡＤＤＧＡ処理の両方が完了したことを確認してから、ＭＬＭＥ−ＡＤＤＴＳ．ｃｏｎｆｉｒｍを実行する事が考えられる。また、ＡＤＤＧＡ  ｒｅｑｕｅｓｔフレーム送信後に所定の時間が経過してもＡＤＤＧＡ  ｒｅｓｐｏｎｓｅフレームを受信できなかった場合は、処理が失敗したことをＭＬＭＥ−ＡＤＤＴＳ．ｃｏｎｆｉｒｍでＳＭＥに対して通知することも考えられる。
上記の場合、ＡＤＤＧＡ  ｒｅｑｕｅｓｔフレームに含めるＲｅ−ｏｒｄｅｒｉｎｇ  Ｂｕｆｆｅｒ  Ｓｉｚｅ及びＧｒｏｕｐ  ＡＣＫ  Ｐｏｌｉｃｙの決定は上記ＭＡＣで行うが、そのために必要な情報は予め収集しておくか、ＳＭＥから取得することが考えられる。
なお、上記図９および１０に示したステップの番号については、図１と同様の処理内容のものについては、同一の番号を付してある。したがって、図９および１０においては、ステップ番号と処理の順番とは、一致していない。また、処理によっては、処理内容は同じであるが、処理される層が異なるものであっても、同一の番号を付してある。
また、これは、以下の実施の形態２および３で説明する、図１１、１２、および１３でも同様である。
（ＡＤＤＧＡ  ｒｅｑｕｅｓｔフレーム及びＡＤＤＧＡ  ｒｅｓｐｏｎｓｅフレームの中身の判定）
図２及び図３についての詳細を述べる。本実施の形態においては、ＡＤＤＧＡ  ｒｅｑｕｅｓｔフレーム及び、ＡＤＤＧＡ  ｒｅｓｐｏｎｓｅフレームには本来不必要なフィールドが含まれて送信される事になる。例えば、ＡＤＤＧＡ  ｒｅｑｕｅｓｔフレームをストリーム受信局から送信する場合、Ｔｒａｎｓｍｉｔ  Ｂｕｆｆｅｒ  Ｓｉｚｅは不必要であるが、フィールドは設けられる事になる。よって、これらのフレームの受信側において、必要なフィールドと不必要なフィールドを判別しなければならない。その方法としては、以下の３つの方法が考えられる。
（方法１）ＡＤＤＧＡ  ｒｅｑｕｅｓｔフレームまたはＡＤＤＧＡ  ｒｅｓｐｏｎｓｅフレームの送信側の局が、そのフレームで通知したくないフィールドには特殊な値を設定し、フレームの受信側の局ではそのような特殊な値が設定されているフィールドは無効な値であると判定する。
この方法の例としては、図２のようなフレーム構造において、フレームの送信側の局が通知したくないフィールドについては全ビットを「０」に設定し、フレームの受信側の局では全ビットが「０」に設定されているフィールドは無視する事が考えられる。
（方法２）ＡＤＤＧＡ  ｒｅｑｕｅｓｔフレームまたはＡＤＤＧＡ  ｒｅｓｐｏｎｓｅフレームの受信側の局が、自局がストリーム送信局であるかストリーム受信局であるかという情報から、無効なフィールドを判定する。
この方法については、ストリーム送信局が、図２のようなフレーム構造のＡＤＤＧＡ  ｒｅｑｕｅｓｔフレームを受信した際、Ｔｒａｎｓｍｉｔ  Ｂｕｆｆｅｒ  Ｓｉｚｅフィールドが無効である事を判定するという例が考えられる。
（方法３）ＡＤＤＧＡ  ｒｅｑｕｅｓｔフレームまたはＡＤＤＧＡ  ｒｅｓｐｏｎｓｅフレームに、そのフレームの送信元がストリーム送信局であるか、ストリーム受信局であるかを示すフィールドを設け、フレーム送信側の局がそのフィールドに然るべき値を設定する。フレーム受信側では、その値を元に無効なフィールドを判定する。
この方法については、ＡＤＤＧＡ  ｒｅｑｕｅｓｔフレームやＡＤＤＧＡ  ｒｅｓｐｏｎｓｅフレームにおいて、図３のようにＳｅｎｄｅｒ／Ｒｅｃｅｉｖｅｒフィールドを設け、ストリーム受信局がフレームを送信する場合はＳｅｎｄｅｒ／ＲｅｃｅｉｖｅｒフィールドにＲｅｃｅｉｖｅｒを示す値を設定し、ストリーム送信局がフレームを送信する場合はＳｅｎｄｅｒ／ＲｅｃｅｉｖｅｒフィールドにＳｅｎｄｅｒを示す値を設定するという例が考えられる。
フレームを受信した側では、Ｓｅｎｄｅｒ／ＲｅｃｅｉｖｅｒフィールドにＳｅｎｄｅｒを示す値が含まれている場合は、Ｇｒｏｕｐ  ＡＣＫ  ＰｏｌｉｃｙフィールドとＲｅ−ｏｒｄｅｒｉｎｇ  Ｂｕｆｆｅｒ  Ｓｉｚｅフィールドが無効な値であると判定し、Ｓｅｎｄｅｒ／ＲｅｃｅｉｖｅｒフィールドにＲｅｃｅｉｖｅｒを示す値が含まれている場合は、Ｔｒａｎｓｍｉｔ  Ｂｕｆｆｅｒ  Ｓｉｚｅフィールドが無効な値であると判定する。
なお、ＡＤＤＧＡ  ｒｅｑｕｅｓｔフレームまたはＡＤＤＧＡ  ｒｅｓｐｏｎｓｅフレームの送信元ではなく、宛先がストリーム送信局であるかストリーム受信局であるかを示すフィールドを設けても同様の事が実現可能である。
（Ｓｅｎｄｅｒ／Ｒｅｃｅｉｖｅｒフィールドとストリームの判別方法）
ところで、ＩＥＥＥ８０２．１１ｅにおいては、ＭＡＣでのストリームの識別のためにＴＩＤが用いられるが、ダイレクトリンクストリームにおいて、２つの局が相互にストリームを送信している場合、同一のＴＩＤが用いられる場合がある。この場合、従来はＡＤＤＧＡ  ｒｅｑｕｅｓｔフレームやＡＤＤＧＡ  ｒｅｓｐｏｎｓｅフレームにはＴＩＤしか含まれないため、そのフレームがどのストリームに対する指示であるのか一意に判別できない。
例えば、ＳＴＡ１からＳＴＡ２に対してＴＩＤを３としてストリームが定義されており、ＳＴＡ２からＳＴＡ１に対しても同様にＴＩＤを３としてストリームが定義されていた場合に、ＡＤＤＧＡ  ｒｅｑｕｅｓｔフレームがＳＴＡ１からＳＴＡ２宛にＴＩＤフィールドを３として送信されたとすると、そのフレームの受信側のＳＴＡ２においては、自局が受信しているストリームに対して、Ｇｒｏｕｐ  ＡＣＫをセットアップすればよいのか、自局が送信しているストリームに対してＧｒｏｕｐ  ＡＣＫをセットアップすればよいのかがわからない。
しかし、本発明では、ＡＤＤＧＡ  ｒｅｑｕｅｓｔフレームやＡＤＤＧＡ  ｒｅｓｐｏｎｓｅフレームにＳｅｎｄｅｒ／Ｒｅｃｅｉｖｅｒフィールドを設けているので、フレームの送信局がＳｅｎｄｅｒ／Ｒｅｃｅｉｖｅｒフィールドに自局がストリームの送信局であるか、受信局であるかという情報を含めて送信すれば、フレームの受信局ではその情報とＴＩＤを元に一意にストリームを決定することができる。
なお、本実施の形態においては、フレーム中にＴｒａｎｓｍｉｔ  Ｂｕｆｆｅｒ  ＳｉｚｅとＲｅ−ｏｒｄｅｒｉｎ  Ｂｕｆｆｅｒ  Ｓｉｚｅのフィールドを別々に設けているが、これらを１つのフィールドに統合し、Ｓｅｎｄｅｒ／Ｒｅｃｅｉｖｅｒフィールドの値に応じて、そのフィールドの中身がＴｒａｎｓｍｉｔ  Ｂｕｆｆｅｒ  ＳｉｚｅとＲｅ−ｏｒｄｅｒｉｎ  Ｂｕｆｆｅｒ  Ｓｉｚｅのどちらを示しているかを、フレームの受信局が判定するようにすることも考えられる。
（Ｇｒｏｕｐ  ＡＣＫ  Ｐｏｌｉｃｙの決定方法）
Ｇｒｏｕｐ  ＡＣＫ  ＰｏｌｉｃｙはＧｒｏｕｐ  ＡＣＫの種類を規定するフィールドであり、どちらの種類を使用するかということをストリーム送信局とストリーム受信局の間で合意を取る必要があるが、その決定方法は、予めストリーム送信局かストリーム受信局のどちらの意見を優先するかということを決めておくことが考えられる。
本発明においては、ストリーム送信局とストリーム受信局の両方がＡＤＤＧＡ  ｒｅｑｕｅｓｔフレームを送信する可能性があるので、ＡＤＤＧＡ  ｒｅｑｕｅｓｔフレームを受信して、Ｇｒｏｕｐ  ＡＣＫ  Ｐｏｌｉｃｙを決定する際には、自局がストリーム送信局とストリーム受信局のどちらであるかを知っておかなければならない。本発明では、Ｓｅｎｄｅｒ／Ｒｅｃｅｉｖｅｒフィールドによってそのフレームがストリーム送信局とストリーム受信局のどちらから送信されたものであるか判別する。
例としてストリーム受信局の意向を優先する場合を述べる。ＡＤＤＧＡ  ｒｅｑｕｅｓｔフレームを受信した際、Ｓｅｎｄｅｒ／ＲｅｃｅｉｖｅｒフィールドがＲｅｃｅｉｖｅｒを示していた場合、そのＡＤＤＧＡ  ｒｅｑｕｅｓｔフレームで指定されたＧｒｏｕｐ  ＡＣＫ  Ｐｏｌｉｃｙを自局がサポートしているなら、ＡＤＤＧＡ  ｒｅｓｐｏｎｓｅフレームにおいては、常に、ＡＤＤＧＡ  ｒｅｑｕｅｓｔフレームで指定されたＧｒｏｕｐ  ＡＣＫ  Ｐｏｌｉｃｙと同一の値を含める。サポートしていないなら、その旨を伝えるための情報をＡＤＤＧＡ  ｒｅｓｐｏｎｓｅフレームに含める。
また、ＡＤＤＧＡ  ｒｅｑｕｅｓｔフレームを受信した際、Ｓｅｎｄｅｒ／ＲｅｃｅｉｖｅｒフィールドがＳｅｎｄｅｒを示していた場合、ＡＤＤＧＡ  ｒｅｓｐｏｎｓｅフレームにおいては、必ずしもＡＤＤＧＡ  ｒｅｑｕｅｓｔフレームで指定されたＧｒｏｕｐ  ＡＣＫ  Ｐｏｌｉｃｙと同一である必要は無く、自局の用いたいＧｒｏｕｐ  ＡＣＫ  Ｐｏｌｉｃｙを指定する。
このとき、ＡＤＤＧＡ  ｒｅｓｐｏｎｓｅを受信した側では、そのフレームのＳｅｎｄｅｒ／ＲｅｃｅｉｖｅｒフィールドがＲｅｃｅｉｖｅｒを示しているので、そのＡＤＤＧＡ  ｒｅｓｐｏｎｓｅフレームで指定されたＧｒｏｕｐ  ＡＣＫ  Ｐｏｌｉｃｙを自局がサポートしているなら、無条件で従うようにする。サポートしていないなら、ＡＤＤＧＡ処理が失敗したと認識し、アプリケーションにその旨を通知する。このとき、パラメータを変更して再度ＡＤＤＧＡ  ｒｅｑｕｅｓｔを送信しても良い。
以上によって、ストリーム送信局とストリーム受信局のどちらからＡＤＤＧＡ  ｒｅｑｕｅｓｔフレームが送信された場合でも、そのストリーム受信局の意向が優先されることになる。
また、従来であれば、ＡＤＤＧＡ  ｒｅｑｕｅｓｔフレームを受信した局は、ＡＤＤＧＡ  ｒｅｑｕｅｓｔで指定されたＧｒｏｕｐ  ＡＣＫ  Ｐｏｌｉｃｙを受け入れるかどうかという情報だけを含めて、ＡＤＤＧＡ  ｒｅｓｐｏｎｓｅフレームを返送していたため、Ｇｒｏｕｐ  ＡＣＫ  Ｐｏｌｉｃｙを決定するためには、最悪の場合Ｇｒｏｕｐ  ＡＣＫ  Ｐｏｌｉｃｙの種類と同じ回数だけＡＤＤＧＡ  ｒｅｑｕｅｓｔフレームとＡＤＤＧＡ  ｒｅｓｐｏｎｓｅフレームの交換を行わなければならなかった。しかしながら、本発明のＧｒｏｕｐ  ＡＣＫ  Ｐｏｌｉｃｙ決定方法によれば、両方の局が全てのＧｒｏｕｐ  ＡＣＫ  Ｐｏｌｉｃｙをサポートしているという前提を置けば、１度のＡＤＤＧＡ  ｒｅｑｕｅｓｔフレームとＡＤＤＧＡ  ｒｅｓｐｏｎｓｅフレームの交換だけでＧｒｏｕｐ  ＡＣＫ  Ｐｏｌｉｃｙを決定できる。
現状ではＧｒｏｕｐ  ＡＣＫ  Ｐｏｌｉｃｙは２種類だけであるので、上記の効果は薄いが、将来的にＧｒｏｕｐ  ＡＣＫ  Ｐｏｌｉｃｙの種類が増えた場合や、別のより種類の多いパラメータを決定する場合には、より効果的になる。例えば、Ｇｒｏｕｐ  ＡＣＫ  Ｐｏｌｉｃｙが５つの種類となった場合、従来の方法であれば、最悪の場合５回のＡＤＤＧＡ  ｒｅｑｕｅｓｔフレームとＡＤＤＧＡ  ｒｅｓｐｏｎｓｅフレームの交換を行う必要があるが、本発明の方法によれば、１回のＡＤＤＧＡ  ｒｅｑｕｅｓｔフレームとＡＤＤＧＡ  ｒｅｓｐｏｎｓｅフレームの交換を行うだけで、Ｇｒｏｕｐ  ＡＣＫ  Ｐｏｌｉｃｙを決定できる。
また、決定権を優先される局が指定したＧｒｏｕｐ  ＡＣＫ  Ｐｏｌｉｃｙを相手局がサポートしていない場合は、１回では決定できないが、決定権を優先される局は希望のＧｒｏｕｐ  ＡＣＫ  Ｐｏｌｉｃｙを使えないことがわかるので、別の局にＡＤＤＧＡ処理を要求する等、次の対応にすぐに移ることができる。
なお、本実施の形態においては、ＡＤＤＴＳ処理を行ってからＡＤＤＧＡ処理を行う例について述べているが、ＡＤＤＧＡ処理を行ってからＡＤＤＴＳ処理を行う場合にも適用できる。この場合、ｎｏｎ−ＡＰ  ＱＳＴＡにおけるＳＭＥが送受信準備応答をアプリケーションに通知し、ｎｏｎ−ＡＰ  ＱＳＴＡにおけるアプリケーションがストリーム定義要求を発行することになる。
なお、上記の処理は、Ｇｒｏｕｐ  ＡＣＫ  Ｐｏｌｉｃｙに限らず、ストリーム送信局とストリーム受信局の間で合意を取る必要の有る別のパラメータを決定する際にも適用できる。
また、Ｓｅｎｄｅｒ／Ｒｅｃｅｉｖｅｒフィールドの代わりに別のパラメータを用いることにより、合意を取る際の優先度を決定する基準を変更することもできる。例えば、ＨＣの意向を優先させたい場合は、Ｓｅｎｄｅｒ／Ｒｅｃｅｉｖｅｒフィールドの代わりにＨＣとｎｏｎ−ＡＰ  ＱＳＴＡのどちらであるかという情報を示すためのフィールドを設けることが考えられる。
なお、ＡＤＤＧＡ  ｒｅｑｕｅｓｔフレームを送信する前に、Ｓｅｎｄｅｒ／Ｒｅｃｅｉｖｅｒフィールドに相当する情報を、予めフレームの送信局と受信局の間でやり取りしておき、その情報を元に優先度を判定（比較）し、Ｇｒｏｕｐ  ＡＣＫ  Ｐｏｌｉｃｙを決定しても良い。
なお、本実施の形態では、ＭＡＣ（７０５・８０５）が、上記優先度を比較する、請求の範囲に記載の比較手段に該当する。
［実施の形態２］
本発明の第２の実施の形態として、ストリーム送信局において、ＡＤＤＴＳの応答を返送するようにＭＡＣに要求する際にアプリケーションに対しても、ＡＤＤＴＳの応答を通知する事により、ストリーム送信局のアプリケーションがＡＤＤＴＳ処理の終了するタイミングを知る事が可能となるようにする方法について述べる。これにより、ＡＤＤＧＡ処理の開始トリガをかけるアプリケーションがＡＤＤＴＳ処理の完了するタイミングを知る事が可能となるので、ＡＤＤＴＳ処理が完了した事を確認した後でＡＤＤＧＡ処理を行う事が可能となる。
全体の大まかな流れは、ストリーム受信局６０２のアプリケーション７０２がストリーム定義要求を行い、ストリーム送信局６０１がそれに対する応答を返送する際に、アプリケーション８０２にもストリーム定義終了通知を行う。アプリケーション８０２はその後、送信準備要求を行い、ＡＤＤＧＡ処理がストリーム送信局６０１から行われるというものである。
なお、本実施の形態では、ＳＭＥ８０３の帯域管理部８１１（図４および図１１の場合）、または、ＭＡＣ８０５（図１２の場合）が、請求の範囲に記載の判定手段に該当する。
ここで、処理の詳細を図４、図６、図７、図８に基づいて説明する。
（ストリーム定義要求）
ストリーム受信局であるｎｏｎ−ＡＰ  ＱＳＴＡ６０２のアプリケーション７０２はストリーム定義要求をＳＭＥ７０３に対して送信する（Ｓ４０１）。このとき、送信されるストリームのエンコード形式やビットレート等の情報を含めて通知される。
（ＡＤＤＴＳ処理）
その後ストリーム受信局であるｎｏｎ−ＡＰ  ＱＳＴＡ６０２とＨＣ６０１の間でＡＤＤＴＳ処理が行われる（Ｓ４０２〜Ｓ４０６、Ｓ４０８〜Ｓ４１０）。この処理については、従来の技術において説明したものと同様なので、省略する。なお、従来の技術ではダイレクトリンクストリームの例を述べたので、ストリーム送信局がＡＤＤＴＳ処理を行っていたが、本実施の形態においては、ダウンリンクストリームについて述べているので、ストリーム受信局６０２がＡＤＤＴＳ処理を行っている点が異なる。
本実施例においては、ＨＣ６０１のＳＭＥ８０３がＴＳＰＥＣ受け入れ可否判定（Ｓ４０６）を行ってからＭＬＭＥ−ＡＤＤＴＳ．ｒｅｓｐｏｎｓｅを実行する（Ｓ４０８）までの間の処理に特徴があるので、その部分のみを説明する。
（ストリーム定義終了通知）
ＨＣ６０１のＳＭＥ８０３における帯域管理部８１１は、ＭＡＣ７０５より通知されたＴＳＰＥＣを受信するとそのＴＳＰＥＣを受け入れ可能かどうかの判定を行う（Ｓ４０６）。ＴＳＰＥＣの受け入れ可否の判定が終了すると、帯域管理部８１１は送受信準備要求を行うアプリケーション８０２に対して、ストリーム定義終了通知を行う（Ｓ４０７）。
このとき、アプリケーション８０２において、ストリームを特定するための情報としてストリーム受信局６０１のＭＡＣアドレスとＴＩＤを含めて通知を行う。ストリームを特定できれば、他の情報で置き換えても良い。
また、ＭＬＭＥ−ＡＤＤＴＳ．ｒｅｓｐｏｎｓｅでＭＡＣ８０５に通知する予定（Ｓ４０８）のＲｅｓｕｌｔ  Ｃｏｄｅをストリーム定義終了通知に含めてもよい。また、Ｒｅｓｕｌｔ  Ｃｏｄｅを元に変換した別の情報をストリーム定義終了通知に含めても良い。例えば、ＨＣ６０１においてＴＳＰＥＣが受け入れられたかどうかという事だけを含めることが考えられる。
ここで、ストリーム定義終了通知が成功を示している場合のみ、ストリーム送信局のアプリケーション８０２は送受信準備要求を行うように構成しておけば、ＡＤＤＴＳ処理が成功した時にのみＡＤＤＧＡ処理が行われる事になる。また、Ｒｅｓｕｌｔ  Ｃｏｄｅが成功を示す値だった場合のみストリーム定義応答を送信し、Ｒｅｓｕｌｔ  Ｃｏｄｅが失敗を示す値だった場合は、ストリーム定義応答を実行しない事をも考えられる。この場合、アプリケーション８０２がストリーム定義終了通知を受信した時にのみ、送受信準備要求を行うように構成しておけば、ＡＤＤＴＳ処理が成功した時にのみＡＤＤＧＡ処理が行われる事になる。
なお、ストリーム定義終了通知はＴＳＰＥＣ受け入れ可否判定（Ｓ４０７）の直後で無くても良い。例えば、ＡＤＤＴＳ処理が完全に終了する（Ｓ４１０）までの時間を予想して、その時間だけ待ってからストリーム定義終了通知を行っても良い。また、ストリーム定義終了通知（Ｓ４０７）とＭＬＭＥ−ＡＤＤＴＳ．ｒｅｓｐｏｎｓｅを実行する（Ｓ４０８）順序はどちらが先でも良い。
その後ＳＭＥ８０３はＭＡＣ８０５に対してＭＬＭＥ−ＡＤＤＴＳ．ｒｅｓｐｏｎｓｅを行い（Ｓ４０８）、そのことがストリーム送信局６０１に通知される事になるが本実施の形態では省略する。
（送受信準備要求）
ＨＣ６０１におけるアプリケーション８０２はストリーム定義終了通知を受信した後で、その内容を解析し、ＭＡＣアドレスとＴＩＤを取得し、送受信準備要求をＳＭＥ８０３に対して行う（Ｓ４１２）。
（ＡＤＤＧＡ処理）
送受信準備要求をＨＣ６０１のＳＭＥ８０３が受信した後の処理（Ｓ４１３〜Ｓ４２１）は、基本的には従来の技術において説明した処理と同様である。
なお、ＡＤＤＧＡ  ｒｅｑｕｅｓｔまたはＡＤＤＧＡ  ｒｅｓｐｏｎｓｅフレームの送信方法が従来と同様であるので、実施の形態１における図２や図３のようにストリーム送信局からストリーム受信局に対して通知する情報と、ストリーム受信局からストリーム送信局に対して通知する情報との両方をＡＤＤＧＡ  ｒｅｑｕｅｓｔ及びＡＤＤＧＡ  ｒｅｓｐｏｎｓｅの両方に含められるようにする必要はなく、従来のＡＤＤＧＡ  ｒｅｑｕｅｓｔフレームまたはＡＤＤＧＡ  ｒｅｓｐｏｎｓｅフレームのフォーマットを使用できる。
（送受信準備応答）
ＡＤＤＧＡ処理が終了すると、ＨＣ６０１のアプリケーション８０２に送受信準備応答が行われる（Ｓ４２２）。以上により、ＨＣ６０１におけるアプリケーション８０２はＡＤＤＴＳ処理とＡＤＤＧＡ処理の両方が完了した事を知る事ができる。
なお、本実施の形態においては、ＡＤＤＴＳ処理を行ってからＡＤＤＧＡ処理を行う例について述べているが、ＡＤＤＧＡ処理を行ってからＡＤＤＴＳ処理を行う場合にも適用できる。この場合、ｎｏｎ−ＡＰ  ＱＳＴＡにおけるＳＭＥがＭＬＭＥ−ＡＤＤＧＡ．ｒｅｓｐｏｎｓｅを発行した後でＭＬＭＥ−ＡＤＤＴＳ．ｒｅｑｕｅｓｔを自主的に発行することになる。
また、図１１に示すとおり、ＨＣにおけるＳＭＥが  ＭＬＭＥ−ＡＤＤＴＳ．ｉｎｄｉｃａｔｉｏｎの受信をトリガとして、自主的にＭＬＭＥ−ＡＤＤＧＡ．ｒｅｑｕｅｓｔを発行しても良い。この場合、ＳＭＥはストリーム定義終了通知をＭＬＭＥ−ＡＤＤＧＡ．ｃｏｎｆｉｒｍを受信した後で発行し、アプリケーションはストリーム定義終了通知を受信しても送受信準備要求を発行しないことが考えられる。このとき、ＡＤＤＴＳ処理やＡＤＤＧＡ処理の結果をストリーム定義終了通知に含めてアプリケーションに通知しても良い。
また、ＴＳＰＥＣ受け入れ可否判定時に、受け入れが失敗を示していた場合、ＭＬＭＥ−ＡＤＤＧＡ．ｒｅｑｕｅｓｔを省略して、ストリーム定義終了通知を発行しても良い。このとき、ＡＤＤＴＳ処理に失敗した旨をストリーム定義終了通知に含めてアプリケーションに通知しても良い。
また、ｎｏｎ−ＡＰ  ＱＳＴＡにおけるＳＭＥは、ＭＬＭＥ−ＡＤＤＴＳ．ｃｏｎｆｉｒｍを受信してもストリーム定義応答を発行せず、ＭＬＭＥ−ＡＤＤＧＡ．ｉｎｄｉｃａｔｉｏｎを受信した後でストリーム定義応答を発行する。このとき、ＡＤＤＴＳ処理やＡＤＤＧＡ処理の結果をストリーム定義応答に含めてアプリケーションに通知しても良い。
なお、ＨＣにおけるＳＭＥがＭＬＭＥ−ＡＤＤＧＡ．ｒｅｑｕｅｓｔの発行を、ＭＬＭＥ−ＡＤＤＴＳ．ｉｎｄｉｃａｔｉｏｎの受信ではなく、ＭＬＭＥ−ＡＤＤＴＳ．ｒｅｓｐｏｎｓｅ送信をトリガとして行っても良い。
さらに、図１２に示すとおり、ＳＭＥが、ストリーム定義終了通知もＭＬＭＥ−ＡＤＤＧＡ．ｒｅｑｕｅｓｔも発行せずに、ＭＡＣがＡＤＤＴＳ  ｒｅｑｕｅｓｔフレームの受信をトリガとして、自主的にＡＤＤＧＡ  ｒｅｑｕｅｓｔフレームを送信しても良い。この場合、ＭＬＭＥ−ＡＤＤＧＡ．ｃｏｎｆｉｒｍは、（１）ＡＤＤＧＡ  ｒｅｓｐｏｎｓｅフレームがｎｏｎ−ＡＰ  ＱＳＴＡによって返送されそれをＨＣが受信した直後、（２）ＡＤＤＧＡ  ｒｅｑｕｅｓｔフレームを送信してから一定期間経過してもＡＤＤＧＡ  ｒｅｓｐｏｎｓｅフレームを受信できなかったとき、（３）ＡＤＤＧＡ  ｒｅｑｕｅｓｔフレームを送信した直後等に発行することが考えられる。
この場合、ＡＤＤＧＡ  ｒｅｑｕｅｓｔフレームに含めるＴｒａｎｓｍｉｔ  Ｂｕｆｆｅｒ  Ｓｉｚｅの決定はＭＡＣで行うが、そのために必要な情報は予め収集しておくか、ＳＭＥから取得することが考えられる。
なお、ＨＣにおけるＳＭＥがＡＤＤＧＡ  ｒｅｑｕｅｓｔフレームの送信は、ＡＤＤＴＳ  ｒｅｑｕｅｓｔフレームの受信ではなく、ＡＤＤＧＡ  ｒｅｓｐｏｎｓｅフレームの送信をトリガとしても良い。ＡＤＤＴＳ  ｒｅｓｐｏｎｓｅフレームがｎｏｎ−ＡＰ  ＱＳＴＡのＭＡＣによって正しく受信された場合は、ＨＣのＭＡＣに対してＡＣＫを返送するので、そのＡＣＫの受信をトリガとしても良い。
［実施の形態３］
本発明の第３の実施の形態として、ストリーム受信局のアプリケーションが、ストリーム定義応答を受信した後で、ストリーム送信局のアプリケーションに対して、ストリーム定義終了フレームの送信を行う方法について述べる。これにより、ＡＤＤＧＡ処理の開始トリガをかけるアプリケーションがＡＤＤＴＳ処理の完了するタイミングを知る事が可能となるので、ＡＤＤＴＳ処理が完了した事を確認した後でＡＤＤＧＡ処理を行う事が可能となる。
全体の大まかな流れは、ストリーム受信局６０２のアプリケーション７０２がストリーム定義要求を行い、ＡＤＤＴＳ処理が完了して、アプリケーション７０２にストリーム定義応答が返ってきた時点で、ストリーム受信局６０２のアプリケーション７０２からストリーム送信局６０１のアプリケーション８０２に対して、ストリーム定義終了フレームの送信を行い、ストリーム受信局６０１のアプリケーション８０２は送受信準備要求を行って、ＡＤＤＧＡ処理が実行されるというものである。
なお、本実施の形態では、アプリケーション７０２（図５の場合）、または、ＳＭＥ７０３（図１３の場合）が、請求の範囲に記載の判定手段に該当する。
また、ＳＭＥ７０３、ＭＬＭＥ７０４、ＭＡＣ７０５、および、無線部７１０が、請求の範囲に記載の通知手段に該当する。
ここで、処理の詳細を図５、図６、図７、図８に沿って説明する。
（ストリーム定義要求）
ストリーム受信局であるｎｏｎ−ＡＰ  ＱＳＴＡ６０２のアプリケーション７０２はストリーム定義要求をＳＭＥ７０３に対して送信する（Ｓ５０１）。このとき、送信されるストリームのエンコード形式やビットレート等の情報を含めて通知される。
（ＡＤＤＴＳ処理）
その後ストリーム受信局であるｎｏｎ−ＡＰ  ＱＳＴＡ６０２とＨＣ６０１の間でＡＤＤＴＳ処理が行われる（Ｓ５０２〜Ｓ５０９）。この処理については、従来の技術において説明したものと同様なので、省略する。なお、従来の技術ではダイレクトリンクストリームの例を述べたので、ストリーム送信局がＡＤＤＴＳ処理を行っていたが、本実施の形態においては、ダウンリンクストリームについて述べているので、ストリーム受信局６０２がＡＤＤＴＳ処理を行っている点が異なる。
本実施の形態においては、ストリーム受信局６０１のアプリケーション７０２がストリーム定義応答を受信した（Ｓ５１０）後の処理に特徴があるので、その部分のみを説明する。
（ストリーム定義応答）
ストリーム受信局であるｎｏｎ−ＡＰ  ＱＳＴＡ６０１のＳＭＥ７０３は、ＭＡＣよりＭＬＭＥ−ＡＤＤＴＳ．ｃｏｎｆｉｒｍを受信するとストリーム定義応答をアプリケーション７０２に対して送信する（Ｓ５１０）。このとき、アプリケーションにおいて、ストリームを特定するための情報としてＴＳＰＥＣに含まれているＴＩＤを含めて通知を行う。アプリケーションにおいてストリームを特定できれば、別の情報でも良い。
（ストリーム定義終了フレーム）
ストリーム受信局であるｎｏｎ−ＡＰ  ＱＳＴＡ６０２のアプリケーション７０２は、ストリーム送信局であるＨＣ６０１のアプリケーション８０２に対して、ストリーム定義終了フレームを送信する（Ｓ５１１）。このフレームには、ストリーム送信局であるＨＣ６０１のアプリケーション８０２において、ストリームを特定するための情報としてストリーム受信局６０１のＭＡＣアドレスと、そのストリームのＴＩＤとを含める。ストリームを特定できれば、他の情報で置き換えても良い。
ここでは、ストリーム定義終了フレームはアプリケーション間で認識可能なフレームとしてやり取りしているが、これに限らず他の層でフレームをやり取りしても良い。
例えば、ＳＭＥ間で認識可能なフレームとしてやり取りする場合、ｎｏｎ−ＡＰ  ＱＳＴＡにおけるＳＭＥがＭＬＭＥ−ＡＤＤＴＳ．ｃｏｎｆｉｒｍを受信したら自主的に、ＨＣにおけるＳＭＥ宛にストリーム定義終了フレームを送信することが考えられる。
この場合、ＨＣにおけるアプリケーションは送受信準備要求を発行せず、ＳＭＥは、ストリーム定義終了フレームを受信したら、自主的にＭＬＭＥ−ＡＤＤＧＡ．ｒｅｑｕｅｓｔを発行し、ＭＬＭＥ−ＡＤＤＧＡ．ｃｏｎｆｉｒｍを受信したらストリーム定義終了通知を行うことが考えられる。さらに、ｎｏｎ−ＡＰ  ＱＳＴＡにおけるＳＭＥはＭＬＭＥ−ＡＤＤＧＡ．ｒｅｓｐｏｎｓｅを発行した後で、ストリーム定義応答を発行することが考えられる。
また、ＴＳＰＥＣ受け入れ可否判定時に、受け入れが失敗を示していた場合、ＭＬＭＥ−ＡＤＤＧＡ．ｒｅｑｕｅｓｔを省略して、ストリーム定義終了通知を発行しても良い。このとき、ＡＤＤＴＳ処理に失敗した旨をストリーム定義終了通知に含めてアプリケーションに通知しても良い。
また、ｎｏｎ−ＡＰ  ＱＳＴＡにおけるＳＭＥは、ＭＬＭＥ−ＡＤＤＴＳ．ｃｏｎｆｉｒｍにおいて、ＡＤＤＴＳ処理が失敗したことが示されていた場合、ストリーム定義終了フレームの送信を省略して、ストリーム定義応答をアプリケーションに対して発行することが考えられる。このとき、ＡＤＤＴＳ処理に失敗したことをストリーム定義応答に含めてアプリケーションに通知しても良い。
また、ストリーム定義要求や送受信準備応答と同様にＳＭＥがストリーム定義終了フレームを送信するためのサービスプリミティブを提供し、アプリケーション７０２はそのサービスプリミティブを実行して、ストリーム定義終了フレームの作成はＳＭＥ７０３に実行させても良い。
また、ＭＬＭＥ−ＡＤＤＴＳ．ｒｅｑｕｅｓｔやＭＬＭＥ−ＡＤＤＧＡ．ｒｅｑｕｓｅｔと同様に、ＭＡＣがサービスプリミティブとしてストリーム定義終了フレームを送信するためのサービスプリミティブを提供し、ＳＭＥはそのサービスプリミティブを実行して、ストリーム定義終了フレームの作成はＭＡＣに実行させても良い。
また、この信号はストリーム、ＡＤＤＴＳ  ｒｅｑｕｅｓｔ／ｒｅｓｐｏｎｓｅ、ＡＤＤＧＡ  ｒｅｑｕｅｓｔ／ｒｅｓｐｏｎｓｅ等を伝送するためのネットワークとは異なる系のネットワークを用いて伝送しても良い。
また、ＭＬＭＥ−ＡＤＤＴＳ．ｃｏｎｆｉｒｍ（Ｓ５０９）で通知されたＲｅｓｕｌｔ  Ｃｏｄｅをストリーム定義終了通知に含めてもよい。また、Ｒｅｓｕｌｔ  Ｃｏｄｅを元に変換した別の情報をストリーム定義終了フレームに含めても良い。例えば、ＡＤＤＴＳ処理が成功したかどうかとういう情報だけを含める事が考えられる。
ここで、ストリーム定義終了通知が成功を示している場合のみ、ストリーム送信局６０１のアプリケーション８０２は送受信準備要求を行うように構成しておけば、ＡＤＤＴＳ処理が成功した時にのみＡＤＤＧＡ処理が行われる事になる。
また、Ｒｅｓｕｌｔ  Ｃｏｄｅが成功を示す値だった場合のみストリーム定義応答を送信し、Ｒｅｓｕｌｔ  Ｃｏｄｅが失敗を示す値だった場合は、ストリーム定義応答を実行しない事をも考えられる。
この場合、ストリーム送信局６０１のアプリケーション８０２がストリーム定義終了フレームを受信した時にのみ、送受信準備要求を行うように構成しておけば、ＡＤＤＴＳ処理が成功した時にのみＡＤＤＧＡ処理が行われる事になる。
（送受信準備要求）
ストリーム送信局であるＨＣ６０１のアプリケーション８０２はストリーム定義終了通知を受信すると、その内容を解析し、通知されたＭＡＣアドレスとＴＩＤを取得し、これらの情報から特定されるストリームについて送受信準備要求をＳＭＥ８０３に対して行う（Ｓ５１２）。
（ＡＤＤＧＡ処理）
送受信準備要求をＨＣ６０１のＳＭＥ８０３が受信した後の処理（Ｓ５１３〜Ｓ５２１）は、基本的には従来の技術において説明した処理と同様である。また、ＡＤＤＧＡ  ｒｅｑｕｅｓｔまたはＡＤＤＧＡ  ｒｅｓｐｏｎｓｅフレームの送信方法が従来と同様であるので、実施の形態１における図２や図３のようにストリーム送信局からストリーム受信局に対して通知する情報と、ストリーム受信局からストリーム送信局に対して通知する情報との両方をＡＤＤＧＡ  ｒｅｑｕｅｓｔ及びＡＤＤＧＡ  ｒｅｓｐｏｎｓｅの両方に含められるようにする必要ない。したがって、従来のＡＤＤＧＡ  ｒｅｑｕｅｓｔフレームまたはＡＤＤＧＡ  ｒｅｓｐｏｎｓｅフレームのフォーマットを使用できる。
（送受信準備応答）
ＡＤＤＧＡ処理が終了すると、ＨＣ６０１のアプリケーション８０２に送受信準備応答が通知される（Ｓ５２２）。以上により、ＨＣ６０１におけるアプリケーション８０２はＡＤＤＴＳ処理とＡＤＤＧＡ処理の両方が完了した事を知る事ができる。
なお、本実施の形態においては、ＡＤＤＴＳ処理を行ってからＡＤＤＧＡ処理を行う例について述べているが、ＡＤＤＧＡ処理を行ってからＡＤＤＴＳ処理を行う場合にも適用できる。この場合、ＨＣにおいてＡＤＤＧＡ処理が完了した時点で、ＡＤＤＧＡ処理が完了したことを示すフレーム（ストリーム定義終了フレームに相当する）をＨＣがｎｏｎ−ＡＰ  ＱＳＴＡ宛に送信することになる。
（実施の形態についての補足）
また、本発明の各実施の形態においては、ＩＥＥＥ８０２．１１ｅにおいてＡＤＤＴＳ処理とＡＤＤＧＡ処理との開始トリガをかける局を同一にするための方法について述べているが、これは一例であり、本発明は通信プロトコルや通信媒体を問わず、複数の処理について、開始トリガをかける局を同一にする際に一般的に適用できる。
ここで、以下に本発明の一適用例を示す。ＩＥＥＥ８０２．１１ｅの現在のドラフトにおいては、ダイレクトリンクストリームの伝送を行うために、Ｄｉｒｅｃｔ  Ｌｉｎｋ  Ｐｒｏｔｏｃｏｌ（ＤＬＰ）と呼ばれる処理を行うことになっている。
また、ＩＥＥＥ８０２．１１ｅにおいては、ｎｏｎ−ＡＰ  ＱＳＴＡは省電力モード（Ｐｏｗｅｒ  Ｓａｖｅモードと称する）に移行することが可能であり、このときには、上記ｎｏｎ−ＡＰ  ＱＳＴＡは他の局からのパケットを受信することができなくなる。
ここで、ＡＰは、Ｐｏｗｅｒ  Ｓａｖｅモードのｎｏｎ−ＡＰ  ＱＳＴＡに対して通常のモードに戻るように指定できるが、ｎｏｎ−ＡＰＱＳＴＡは、別のｎｏｎ−ＡＰ  ＱＳＴＡに対して、そのような指示ができない。
それゆえ、ダイレクトリンクストリームにおいて、データを送信する相手がＰｏｗｅｒ  Ｓａｖｅモードに移行していないか否かを、ＤＬＰ処理によって確かめた上で通信を開始する。このＤＬＰ処理においてもＡＤＤＴＳ処理やＡＤＤＧＡ処理と同様に、複数のパケットをｎｏｎ−ＡＰ  ＱＳＴＡ同士で送受信する。
ここで、例えば、ＤＬＰ処理を行う前にＡＤＤＧＡ処理を行ってしまうと、相手局がＰｏｗｅｒ  Ｓａｖｅモードに移行していた場合、ＡＤＤＧＡ処理は失敗してしまうので、ＤＬＰ処理が完了したことを確認してからＡＤＤＧＡ処理を開始すべきである。したがって、このような場合にも、本発明は適用可能である。
以上の各実施の形態において説明したように、本発明の目的の一つは、複数の通信局と中央制御局からなる通信ネットワークにおいて、中央制御局から通信局へのダウンリンクストリームの伝送を行う時にストリーム送信局とストリーム受信局のどちらか一方の局のトリガで帯域割り当てと、ＡＣＫ送信方法の設定をできるようにするものである。
そして、各実施の形態では、以下の３つの通信管理方法を用いて上記目的を達成した。
まず、実施の形態１では、ＡＣＫ設定のトリガをストリーム受信局からもかけられるようにし、ＡＣＫ設定要求のフレームにＡＣＫの種類に関する情報を含めるようにして、上記目的を達成した。
また、実施の形態２では、ストリーム受信局から送信された帯域割り当て要求をトリガとして中央制御局がＡＣＫ設定要求をストリーム受信局に送信することにより、上記目的を達成した。
さらに、実施の形態３では、一方の通信局から実行された帯域割り当て要求またはＡＣＫ設定要求が、もう一方の局において完了した事を知らせるための新たなフレームを定義することにより、上記目的を達成した。
ところで、上記実施の形態１〜３におけるｎｏｎ−ＡＰ  ＱＳＴＡおよびＨＣの各ブロック、特にアプリケーション（７０２・８０２）、ＳＭＥ（７０３．８０３）、ＭＬＭＥ（７０４・８０４）、ＭＡＣ（７０５・８０５）は、ハードウェアロジックによって構成してもよいし、次のようにＣＰＵを用いてソフトウェアによって実現してもよい。
すなわち、ｎｏｎ−ＡＰ  ＱＳＴＡおよびＨＣは、各機能を実現する制御プログラムの命令を実行するＣＰＵ（ｃｅｎｔｒａｌ  ｐｒｏｃｅｓｓｉｎｇ  ｕｎｉｔ）、上記プログラムを格納したＲＯＭ（ｒｅａｄ  ｏｎｌｙ  ｍｅｍｏｒｙ）、上記プログラムを展開するＲＡＭ（ｒａｎｄｏｍ  ａｃｃｅｓｓ  ｍｅｍｏｒｙ）、上記プログラムおよび各種データを格納するメモリ等の記憶装置（記録媒体）などを備えている。そして、本発明の目的は、上述した機能を実現するソフトウェアであるｎｏｎ−ＡＰ  ＱＳＴＡおよびＨＣの制御プログラムのプログラムコード（実行形式プログラム、中間コードプログラム、ソースプログラム）をコンピュータで読み取り可能に記録した記録媒体を、上記ｎｏｎ−ＡＰ  ＱＳＴＡおよびＨＣに供給し、そのコンピュータ（またはＣＰＵやＭＰＵ）が記録媒体に記録されているプログラムコードを読み出し実行することによっても、達成可能である。
上記記録媒体としては、例えば、磁気テープやカセットテープ等のテープ系、フロッピー（登録商標）ディスク／ハードディスク等の磁気ディスクやＣＤ−ＲＯＭ／ＭＯ／ＭＤ／ＤＶＤ／ＣＤ−Ｒ等の光ディスクを含むディスク系、ＩＣカード（メモリカードを含む）／光カード等のカード系、あるいはマスクＲＯＭ／ＥＰＲＯＭ／ＥＥＰＲＯＭ／フラッシュＲＯＭ等の半導体メモリ系などを用いることができる。
また、ｎｏｎ−ＡＰ  ＱＳＴＡ、およびＨＣを通信ネットワークと接続可能に構成し、上記プログラムコードを通信ネットワークを介して供給してもよい。この通信ネットワークとしては、特に限定されず、例えば、インターネット、イントラネット、エキストラネット、ＬＡＮ、ＩＳＤＮ、ＶＡＮ、ＣＡＴＶ通信網、仮想専用網（ｖｉｒｔｕａｌ  ｐｒｉｖａｔｅ  ｎｅｔｗｏｒｋ）、電話回線網、移動体通信網、衛星通信網等が利用可能である。また、通信ネットワークを構成する伝送媒体としては、特に限定されず、例えば、ＩＥＥＥ１３９４、ＵＳＢ、電力線搬送、ケーブルＴＶ回線、電話線、ＡＤＳＬ回線等の有線でも、ＩｒＤＡやリモコンのような赤外線、Ｂｌｕｅｔｏｏｔｈ（登録商標）、８０２．１１無線、ＨＤＲ、携帯電話網、衛星回線、地上波デジタル網等の無線でも利用可能である。なお、本発明は、上記プログラムコードが電子的な伝送で具現化された搬送波あるいはデータ信号列の形態でも実現され得る。
本発明に係る通信装置は、以上のように、複数の通信装置が通信ネットワークを介して接続されているネットワークシステムを構成する通信装置であって、他の通信装置との間でデータ通信を可能な状態とするために、他の通信装置との間で行われる複数の通信設定処理について、各通信設定処理にて最初に送信すべき信号を、自装置から他の通信装置に対して送信する送信手段を備えるものである。
上記の構成によれば、他の通信装置との間でデータ通信を可能な状態とするために、他の通信装置との間で行われる複数の通信設定処理について、各通信設定処理にて最初に送信すべき信号が、全て、前記通信装置から他の通信装置に送られることとなる。
それゆえ、上記最初に送信すべき信号の送信元を、全て前記通信装置とすることが可能となる。
したがって、各通信設定処理を開始するタイミング（つまりトリガのタイミング）を、通信装置のみで決定することができる。それゆえ、データ通信を可能な状態とするための処理を、効率よく行うことが可能となる。
また、本発明に係る通信装置は、上記の通信装置において、前記他の通信装置は、前記通信ネットワークの送信権を管理する中央制御装置であると共に、前記データ通信は、前記他の通信装置から自装置へのダウンリンクストリーム通信であって、前記送信手段は、前記ダウンリンクストリーム通信を可能な状態とするために、前記信号として、グループＡＣＫに関するＡＣＫ情報の設定処理を要求する要求信号を、前記他の通信装置に対して送信するものである。
上記の構成により、上記通信装置は、上記ダウンリンクストリーム通信を可能な状態とするため、他の通信装置に対して、グループＡＣＫに関するＡＣＫ情報の設定を要求する要求信号を送信することができる。
ここで、ダウンリンクストリーム通信を可能とするためには、通信装置と他の通信装置との間において、ＡＣＫ情報の設定処理と、帯域情報の設定処理とが必要となる。また、上記帯域情報の設定処理は、通信装置から他の通信装置に対して要求信号を送信することにより開始される。
それゆえ、上記の構成では、グループＡＣＫに関するＡＣＫ情報の設定を要求する要求信号の送信元と、帯域情報の設定処理に用いられる要求信号の送信元とを、共に通信装置とすることが可能となる。
したがって、グループＡＣＫに関するＡＣＫ情報の設定処理を開始するタイミングと、帯域情報の設定処理を開始するタイミングとを、通信装置のみで決定することができる。それゆえ、ダウンリンクストリーム通信を可能な状態とするための処理を、効率よく行うことが可能となる。
また、本発明に係る通信装置は、上記の通信装置において、前記要求信号は、自装置が所望するグループＡＣＫの種別に関する情報、および、自装置におけるストリーム受信バッファサイズに関する情報を含んでいるものである。
それゆえ、自装置（通信装置）が他の通信装置（中央制御装置）に対して送信する要求信号には、自装置が所望するＡＣＫ伝送方式の種別に関する情報、および、自装置におけるストリーム受信バッファサイズに関する情報が含まれる。
したがって、通信装置から、中央制御装置に対して、グループＡＣＫに関するＡＣＫ情報の設定処理を完了させるために必要な情報の通知を行うことが可能となる。
本発明に係る通信装置は、以上のように、複数の通信装置が通信ネットワークを介して接続されているネットワークシステムを構成する通信装置であって、他の通信装置との間でデータ通信を可能な状態とするために、他の通信装置との間で行われる複数の通信設定処理について、各通信設定処理にて最初に送信すべき信号を、他の通信装置から受信する受信手段と、前記最初に送信すべき信号に対する応答信号を、前記他の通信装置に送信する送信手段とを備えるものである。
上記の構成によれば、他の通信装置との間でデータ通信を可能な状態とするために、他の通信装置との間で行われる複数の通信設定処理について、各通信設定処理にて最初に送信すべき信号を、全て、前記他の通信装置から受信することとなる。さらに、前記最初に送信すべき信号に対して、応答信号を他の通信装置に送信する。
それゆえ、上記最初に送信すべき信号の受信元を、全て前記通信装置とすることが可能となる。つまり、上記最初に送信すべき信号の送信元が、全て前記他の通信装置とすることが可能となる。また、上記他の通信装置では、上記応答信号を受信することにより、各通信設定処理の状況を判断できる。
したがって、上記他の通信装置が各通信設定処理を開始するタイミング（つまりトリガのタイミング）を、他の通信装置のみで決定することができる。それゆえ、データ通信を可能な状態とするための処理を、効率よく行うことが可能となる。
また、本発明に係る通信装置は、上記の通信装置において、自装置は、前記通信ネットワークの送信権を管理する装置であると共に、前記データ通信は、前記自装置から他の通信装置へのダウンリンクストリーム通信であって、前記受信手段は、前記ダウンリンクストリーム通信を可能な状態とするために、前記信号として、グループＡＣＫに関するＡＣＫ情報の設定処理を要求する要求信号を、前記他の通信装置から受信することを特徴としている。
上記の構成により、通信装置は、上記ダウンリンクストリーム通信を可能な状態とするために、前記他の通信装置から送信される、グループＡＣＫに関するＡＣＫ情報の設定を要求する要求信号を受信すると共に、前記他の通信装置に対して、前記グループＡＣＫに関するＡＣＫ情報の設定を要求する要求信号に基づく応答信号を送信することができる。
したがって、上記通信装置（自装置）は、上記他の通信装置に対して、上記ＡＣＫ情報の設定を要求する要求信号に基づく応答信号を送信するため、上記他の通信装置がＡＣＫ情報の設定を要求する要求信号の送信元となるような場合であってもＡＣＫ情報の設定処理を行うことができる。
また、ダウンリンクストリーム通信を可能とするためには、自装置と他の通信装置との間において、上記グループＡＣＫに関するＡＣＫ情報の設定処理と、帯域情報の設定処理とが必要となる。さらに、上記帯域情報の設定処理は、他の通信装置から自装置に対して要求信号を送信することにより開始される。
それゆえ、上記の構成では、グループＡＣＫに関するＡＣＫ情報の設定を要求する要求信号の送信元と、帯域情報の設定処理に用いられる要求信号の送信元とを、共に他の通信装置とすることが可能となる。
したがって、グループＡＣＫに関するＡＣＫ情報の設定処理を開始するタイミングと、帯域情報の設定処理を開始するタイミングとを、他の通信装置のみで決定することができる。それゆえ、ダウンリンクストリーム通信を可能な状態とするための処理を、効率よく行うことが可能となる。
また、本発明に係る通信装置は、上記の通信装置において、前記応答信号は、自装置が所望するグループＡＣＫの種別に関する情報、および、自装置におけるストリーム送信バッファサイズに関する情報を含んでいるものである。
それゆえ、自装置（つまり、中央制御装置）が他の通信装置に対して送信する応答信号には、自装置が所望するＡＣＫ伝送方式の種別に関する情報、および、自装置におけるストリーム受信バッファサイズに関する情報が含まれる。
したがって、中央制御装置側から、グループＡＣＫに関するＡＣＫ情報の設定処理を完了させるために必要な情報の通知を行うことが可能となる。
本発明に係る通信装置は、以上のように、複数の通信装置が通信ネットワークを介して接続されているネットワークシステムを構成する通信装置であって、他の通信装置との間でデータ通信を可能な状態とするために、前記他の通信装置から送信される、第１の通信設定処理を要求する第１要求信号を受信する受信手段と、前記第１要求信号の要求内容を承認するか否かを判定する判定手段と、前記他の通信装置との間でデータ通信を可能な状態とするために、前記他の通信装置に対して、第２の通信設定処理を要求する第２要求信号を送信する送信手段とを備え、前記判定手段が前記要求内容を承認した場合に、前記送信手段が、前記第２要求信号を前記他の通信装置に送信することを特徴としている。
上記の構成によれば、判定手段が、第１要求信号の要求内容について、要求内容を承認するか否かを判定する。また、判定手段が上記要求内容を承認した場合に、送信手段が、第２要求信号を通信装置に送信する。
つまり、自装置が、上記要求内容を承認したことを条件に、前記第２要求信号を送信する。
したがって、前記第２要求信号の送信タイミングを自ら判断することが可能となる。つまり、第２の通信設定処理についても、他の通信装置による第１要求信号の送信をトリガして行うことができる。
それゆえ、データ通信を可能な状態とするための処理を、効率よく行うことが可能となる。
また、本発明に係る通信装置は、上記の通信装置において、自装置は前記通信ネットワークの送信権を管理する装置であると共に、前記データ通信は、前記他の通信装置から自装置へのダウンリンクストリーム通信であって、前記受信手段は、第１要求信号として、帯域情報の設定処理を要求する要求信号を受信し、前記送信手段は、第２要求信号として、グループＡＣＫに関するＡＣＫ情報の設定処理を要求する要求信号を送信するものである。
上記の構成によれば、自装置が、上記帯域情報の設定を要求する要求信号の要求内容について、要求内容を承認するか否かを判定する。また、判定手段が上記要求内容を承認した場合に、上記送信手段が、グループＡＣＫに関するＡＣＫ情報の設定を要求する要求信号を通信装置に送信する。
つまり、自装置が、上記要求内容を承認したことを条件に、前記ＡＣＫ情報の設定を要求する要求信号を送信する。
したがって、自装置が、上記グループＡＣＫに関するＡＣＫ情報の設定を要求する要求信号の送信タイミングを自ら判断することが可能となる。それゆえ、ダウンリンクストリーム通信を可能な状態とするための処理を、効率よく行うことが可能となる。
また、本発明に係る通信装置は、上記の通信装置において、前記他の通信装置に対して、前記グループＡＣＫに関するＡＣＫ情報の設定を要求する要求信号を送信するＭＡＣ副層と、前記判定手段を有すると共に、ＭＡＣ副層を管理する管理層とを備え、前記判定手段が前記要求内容を承認した場合、前記管理層が、前記ＭＡＣ副層に対して前記グループＡＣＫに関するＡＣＫ情報の設定を要求する要求信号を送信するための指示を出すものである。
本発明に係る通信装置は、以上のように、複数の通信装置が通信ネットワークを介して接続されているネットワークシステムを構成する通信装置であって、前記他の通信装置との間でデータ通信を可能な状態とするために、前記他の通信装置に対して、所定の通信設定処理を要求する要求信号を送信する送信手段と、前記他の通信装置から、前記要求信号に基づく応答信号を受信する受信手段と、前記応答信号に基づいて、所定の通信設定処理が行われたか否かを判定する判定手段と、前記判定手段による判定結果を、前記他の通信装置に対して通知する通知手段とを備えるものである。
上記の構成によれば、上記通知手段により、前記判定手段による判定結果が、前記他の通信装置に対して通知される。つまり、第１の設定処理が行われたか否かが、自装置（通信装置）から他の通信装置に通知される。
したがって、他の通信装置では、上記判定結果に基づいて、前記所定の設定処理が行われたことを認識することにより、他の通信装置は、データ通信を可能な状態とするために、上記通信装置に対して行う他の通信設定処理の開始タイミングを判断できる。つまり、上記他の通信設定処理についても、上記通信装置による判定結果の通知をトリガして行うことができる。
それゆえ、データ通信を可能な状態とするための処理を、効率よく行うことが可能となる。
また、本発明に係る通信装置は、上記の通信装置において、前記他の通信装置は、前記通信ネットワークの送信権を管理する中央制御装置であると共に、前記データ通信は、前記他の通信装置から自装置へのダウンリンクストリーム通信であって、前記送信手段は、前記要求信号として、帯域情報の設定処理を要求する要求信号を送信し、前記判定手段は、前記帯域情報の設定処理が行われたか否かを判定することを特徴としている。
上記の構成によれば、上記通知手段により、前記判定手段による判定結果が、前記他の通信装置（中央制御装置）に対して通知される。つまり、帯域情報の設定が行われたか否かが、自装置から上記他の通信装置に通知される。
ところで、ダウンリンクストリーム通信を可能とするためには、通信装置と他の通信装置（中央制御装置）との間において、ＡＣＫ情報の設定処理と、帯域情報の設定処理とが必要となる。ここで、上記帯域情報の設定処理は、通信装置から中央制御装置に対して要求信号を送信することにより開始される。一方、上記ＡＣＫ情報の設定処理は、中央制御装置から通信装置に対して要求信号を送信することにより開始される。
したがって、他の通信装置（中央制御装置）が、上記帯域情報の設定処理が行われたことを認識することにより、他の通信装置は、上記ＡＣＫ情報の設定処理のタイミングを判断することが可能となる。それゆえ、ダウンリンクストリーム通信を可能な状態とするための処理を、効率よく行うことが可能となる。
本発明に係る通信装置は、以上のように、複数の通信装置が通信ネットワークを介して接続されているネットワークシステムを構成する通信装置であって、他の通信装置との間でデータ通信を可能な状態とするために、前記他の通信装置から送信される、所定の情報の設定処理を含んだ通信設定処理を要求する要求信号を受信する受信手段と、前記要求信号に基づいて、他の通信装置と自装置との優先度を比較する比較手段とを備え、前記他の通信装置の優先度が高い場合には、他の通信装置との間でデータ通信を可能な状態とするために、他の通信装置に対して前記所定の情報を含めた応答信号を送信するものである。
上記の構成によれば、前記他の通信装置の優先度が高い場合には、他の通信装置との間でデータ通信を可能な状態とするために、他の通信装置に対して前記所定の情報を含めた応答信号が送信される。
したがって、他の通信装置から送信される、所定の情報の設定処理に基づいた設定にて、データ通信を行うことができる。
また、優先される側となる他の通信装置がサポートしていない所定の情報については、両装置間において、要求信号および応答信号の送受信を行わなくて済む。それゆえ、データ通信を可能な状態とするための、両装置間での上記要求信号と応答信号との送受信回数を、従来よりも減らすことができる。
本発明に係る通信装置は、以上のように、複数の通信装置が通信ネットワークを介して接続されているネットワークシステムを構成する通信装置であって、他の通信装置との間でデータ通信を可能な状態とするために、前記他の通信装置から送信される、所定の情報の設定処理を含んだ通信設定処理を要求する要求信号を受信する受信手段と、前記要求信号に基づいて、他の通信装置と自装置との優先度を比較する比較手段とを備え、前記自装置の優先度が高い場合には、他の通信装置との間でデータ通信を可能な状態とするために、他の通信装置に対して自装置が設定した情報の設定処理を含んだ応答信号を送信することを特徴としている。
上記の構成によれば、前記他の通信装置の優先度が高い場合には、他の通信装置との間でデータ通信を可能な状態とするために、他の通信装置に対して自装置が設定した情報の設定処理を含んだ応答信号が送信される。
したがって、自装置から送信される、自装置が設定した情報に基づいた設定にて、データ通信を行うことができる。
また、優先される側となる自装置がサポートしていない所定の情報については、両装置間において、要求信号および応答信号の送受信を行わなくて済む。それゆえ、データ通信を可能な状態とするための、両装置間での上記要求信号と応答信号との送受信回数を、従来よりも減らすことができる。
また、本発明に係る通信装置は、上記の通信装置において、前記通信設定処理は、グループＡＣＫに関するＡＣＫ情報の設定処理であって、前記要求信号には、グループＡＣＫの種別に関する情報が含まれているものである。
上記の構成によれば、優先度の高い装置から送信される、グループＡＣＫの種別の情報に基づいた設定にてデータ通信を行うことができる。
また、本発明に係る通信装置は、上記の通信装置において、前記要求信号には、前記要求信号の送信元となる他の通信装置がデータ通信の送信側または受信側であるかの情報が含まれており、前記優先度が、前記送信側または受信側であるかの情報に基づいて決定されるものである。
上記の構成によれば、前記優先度が、要求信号の送信元となる他の通信装置がデータ通信の送信側または受信側であるかといった情報に基づいて決定される。
したがって、要求信号の送信側あるいは受信側の装置であるといったこととは関係なく、データ通信の送信側または受信側の何れの装置を優先させることが可能となる。
本発明に係る通信装置は、以上のように、複数の通信装置が通信ネットワークを介して接続されているネットワークシステムを構成する通信装置であって、他の通信装置との間でデータ通信を可能な状態とするために、前記他の通信装置に対して第１要求信号を送信する送信手段、および、前記他の通信装置から第２要求信号を受信する受信手段を備え、前記第１要求信号には、自装置がデータ通信の送信側または受信側かの情報が含まれていることを特徴としている。
上記の構成によれば、上記第１要求信号には、自装置がストリーム通信の送信側または受信側かの情報が含まれている。
ここで、上記の構成のように、他の通信装置との間でストリーム通信を可能な状態とするために、自装置が他の通信装置に対して第１要求信号を送信し、かつ、他の通信装置から第２要求信号を受信するような構成である場合、つまり、自装置および他の通信装置とも、要求信号を相手の装置に対して送信する場合には、以下の問題を生じる。
まず、従来のようにデータ通信の送信側の装置のみが要求信号を送信する場合には、データの流れの方向を、要求信号の送信元から要求信号の受信先への方向と特定できる。
しかしながら、上記のように、自装置および他の通信装置ともに要求信号の送信元となるような構成においては、データの流れの方向を、要求信号の送信元から要求信号の受信先への方向なのか、あるいは、要求信号の受信先から要求信号の受信元への方向なのかを特定できない。つまり、データの流れの方向を、一意に特定できないという問題点を生じる。
そこで、第１要求信号に、自装置がデータ通信の送信側または受信側かの情報を含めることにより、データの流れの方向を特定することが可能となる。
本発明に係るネットワークシステムは、上記通信装置と、上記通信装置とを備えるものである。
本発明に係るネットワークシステムは、上記通信装置と、前記通信装置と通信ネットワークを介して接続される他の通信装置とを備えるものである。
本発明係るネットワークシステムは、上記通信装置と、前記通信装置と通信ネットワークを介して接続されており、かつ、前記通信ネットワークの送信権を管理する中央制御装置とを備えるものである。
本発明に係る通信管理方法は、１つ以上の通信装置および中央制御装置が通信ネットワークを介して接続されており、かつ、前記中央制御装置が、前記通信ネットワークの送信権を管理するネットワークシステムで用いられる通信管理方法であって、前記中央制御装置から自装置へのダウンリンクストリーム通信を可能な状態とするために、前記中央制御装置に対して、グループＡＣＫに関するＡＣＫ情報の設定処理を要求する要求信号を前記通信装置が送信する第１のステップと、前記通信装置から送信される、前記ＡＣＫ情報の設定処理を要求する要求信号を、前記中央制御装置が受信する第２のステップと、前記通信装置に対して、前記ＡＣＫ情報の設定処理を要求する要求信号に基づく応答信号を、前記中央制御装置が送信する第３のステップと、前記中央制御装置から送信される前記応答信号を、前記通信装置が受信する第４のステップとを備える方法である。
本発明に係る通信管理方法は、１つ以上の通信装置および中央制御装置が通信ネットワークを介して接続されており、かつ、前記中央制御装置が、前記通信ネットワークの送信権を管理するネットワークシステムで用いられる通信管理方法であって、前記中央制御装置から前記通信装置へのダウンリンクストリーム通信を可能な状態とするために、前記通信装置から送信される、帯域情報の設定処理を要求する要求信号を中央制御装置が受信する第１ステップと、前記帯域情報の設定処理を要求する要求信号の要求内容について、前記要求内容を承認するか否かを中央制御装置が判定する第２ステップと、前記第３ステップにて中央制御装置が前記要求内容を承認した場合に、前記ダウンリンクストリーム通信を可能な状態とするために、グループＡＣＫに関する前記ＡＣＫ情報の設定処理を要求する要求信号を前記中央制御装置が通信装置に対して送信する第３ステップとを備える方法である。
本発明に係る通信管理方法は、１つ以上の通信装置および中央制御装置が通信ネットワークを介して接続されており、かつ、前記中央制御装置が、前記通信ネットワークの送信権を管理するネットワークシステムで用いられる通信管理方法であって、前記中央制御装置から前記通信装置へのダウンリンクストリーム通信を可能な状態とするために、前記中央制御装置に対して、帯域情報の設定処理を要求する要求信号を前記通信装置が送信する第１ステップと、前記中央制御装置から、前記要求信号に基づく応答信号を前記通信装置が受信する第２ステップと、前記応答信号に基づいて、前記帯域情報の設定処理が行われたか否かを前記通信装置が判定する第３ステップと、前記第３ステップでの判定結果を、前記通信装置が前記中央制御装置に対して通知する第４ステップとを備える方法である。
本発明に係る要求信号は、通信ネットワークを介して互いに接続された通信装置間にてデータ通信を可能な状態とするために、前記通信装置間で行われる複数の通信設定処理に関し、各通信設定処理にて最初に送信すべき要求信号を一方の通信装置が他の通信装置に対して送信する通信管理方法における要求信号であって、前記一方の通信装置が、データ通信の送信側装置、受信側装置、または、前記ネットワークの通信権を管理する中央制御装置の何れかの装置として動作する際に必要となる、データ通信を可能な状態とするための情報を含んでいる信号である。
本発明に係る要求信号は、１つ以上の通信装置および中央制御装置が通信ネットワークを介して接続されており、かつ、前記中央制御装置が前記通信ネットワークの送信権を管理するネットワークシステムを構成する通信装置が、前記中央制御装置に送信する信号であると共に、前記中央制御装置から自装置へのダウンリンクストリーム通信を可能な状態とするための要求信号であって、ストリームデータの受信側である前記通信装置からグループＡＣＫに関するＡＣＫ情報の設定を行うために必要な情報を含んでいる信号である。
本発明に係る応答信号は、通信ネットワークを介して互いに接続された通信装置間にてデータ通信を可能な状態とするために、前記通信装置間で行われる複数の通信設定処理に関し、各通信設定処理にて最初に送信すべき要求信号を一方の通信装置が他の通信装置に対して送信すると共に、他方の通信装置が前記要求信号に対する応答信号を前記一方の通信装置に送信する通信管理方法における応答信号であって、前記他方の通信装置が、データ通信の送信側装置、受信側装置、または、前記ネットワークの通信権を管理する中央制御装置の何れかの装置として動作する際に必要となる、データ通信を可能な状態とするための情報を含んでいる信号である。
本発明に係る応答信号は、１つ以上の通信装置と通信ネットワークを介して接続されると共に、前記通信ネットワークの送信権を管理する中央制御装置が、前記通信装置に対して送信する信号であると共に、前記中央制御装置から自装置へのダウンリンクストリーム通信を可能な状態とするための要求信号に対する応答信号であって、ストリームデータの送信側である前記中央制御装置からグループＡＣＫに関するＡＣＫ情報の設定を行うための情報を含んでいる信号である。
本発明に係るプログラムは、上記の課題を解決するために、上記通信装置の各手段としてコンピュータを機能させるためのプログラムである。
上記プログラムをコンピュータシステムにロードすることによって、上記通信装置をユーザに提供することが可能となるという効果を奏する。
本発明に係るプログラムは、以上のように、上記通信管理方法をコンピュータに実行させるためのプログラムである。
上記プログラムをコンピュータシステムにロードすることによって、上記通信管理方法をユーザに提供することが可能となるという効果を奏する。
本発明に係る記録媒体は、以上のように、上記プログラムを記録した記録媒体である。
上記記録媒体に記録されているプログラムをコンピュータシステムにロードすることによって、上記通信装置、中央制御装置、あるいは、通信管理方法をユーザに提供することが可能となるという効果を奏する。
また、本発明に係る通信管理方法は、１つ以上の通信局と中央制御局からなる通信システムにおける通信管理方法であって、通信局において、中央制御局から前記通信局に対してのダウンリンクストリームを送信する際のＡＣＫ情報設定要求を送信するステップを備えている方法であるとも言える。
これはすなわち、ＡＤＤＧＡ  ｒｅｑｕｅｓｔフレームとＡＤＤＧＡ  ｒｅｓｐｏｎｓｅフレームの両方に、ストリーム送信局からストリーム受信局に対して通知する情報を含めるフィールドと、ストリーム受信局からストリーム送信局に対して通知する情報を含めるフィールドの両方を設けるようにするということである。
また、本発明に係る通信管理方法は、前記ＡＣＫ情報設定要求には前記通信局が望むＡＣＫ伝送方式、前記通信局におけるパケット受信バッファのサイズ情報の内の少なくとも１つが含まれている方法であるとも言える。
これはすなわち、ストリーム受信局からストリーム送信局に対してＡＤＤＧＡ  ｒｅｑｕｅｓｔフレームを送信することでＧｒｏｕｐ  ＡＣＫ  Ｐｏｌｉｃｙ及びＲｅ−ｏｒｄｅｒｉｎｇ  Ｂｕｆｆｅｒ  Ｓｉｚｅを通知するようにするということである。
また、本発明に係る通信管理方法は、前記ダウンリンクストリームは、前記ＡＣＫ情報設定要求に含まれるＡＣＫ伝送方式と前記通信局におけるパケット受信バッファのサイズ情報に基づいて管理される方法であるとも言える。
これはすなわち、前記のＡＤＤＧＡ  ｒｅｑｕｅｓｔフレームによって通知されたＧｒｏｕｐ  ＡＣＫ  Ｐｏｌｉｃｙ及びＲｅ−ｏｒｄｅｒｉｎｇ  Ｂｕｆｆｅｒ  Ｓｉｚｅに従って、Ｇｒｏｕｐ  ＡＣＫの伝送が行われるということである。
これにより、ＡＤＤＴＳ処理をストリーム受信局からのトリガによって開始させることが可能となり、ＡＤＤＴＳ処理とＡＤＤＧＡ処理の両方を１つの局から行う事が可能となる。よって、前記の（問題Ａ）及び（問題Ｂ）を解決できる。
また、本発明に係る通信管理方法は、１つ以上の通信局と中央制御局からなる通信システムにおける通信管理方法であって、通信局において、中央制御局から前記通信局に対してのダウンリンクストリームを送信する際の帯域情報設定要求を送信するステップを備え、中央制御局において、前記帯域情報設定要求を受信するステップと、前記帯域情報設定要求受信をトリガとして前記ダウンリンクストリームを送信する際のＡＣＫ情報設定要求を、前記通信局に対して送信するステップを備える方法であるとも言える。
また、本発明に係る通信管理方法は、前記トリガはＭＡＣ層を管理する層から他の層に対して通知される方法であるとも言える。
これはすなわち、ＡＤＤＴＳ  ｒｅｑｕｅｓｔフレームを受信したＨＣにおける帯域管理部が、ＡＤＤＴＳ  ｒｅｓｐｏｎｓｅフレームをｎｏｎ−ＡＰ  ＱＳＴＡに対して返送すると共に、ＡＤＤＧＡ処理の開始トリガをかけるアプリケーションに対してＡＤＤＴＳ処理の成否を通知し、前記アプリケーションがｎｏｎ−ＡＰ  ＱＳＴＡに対するＡＤＤＧＡ処理を開始するということである。
これにより、ＡＤＤＧＡ処理の開始トリガをかけるアプリケーションは、ＡＤＤＴＳ処理の成否を確認した上で、ＡＤＤＧＡ処理を開始する事が可能となる。よって、上述した、（問題Ａ）及び（問題Ｂ）を解決できる。
また、本発明に係る通信管理方法は、１つ以上の通信局と中央制御局からなる通信システムにおける通信管理方法であって、中央制御局から通信局に対するダウンストリームを行う際に、帯域情報設定要求が成功したことを通信局から中央制御局へ通知するステップ、あるいはＡＣＫ情報設定要求が成功したことを中央制御局から通信局へ通知するステップを含む方法であるとも言える。
これはすなわち、ＡＤＤＴＳ  ｒｅｓｐｏｎｓｅフレームを受信したｎｏｎ−ＡＰ  ＱＳＴＡが、ＡＤＤＴＳ処理の成否をＨＣに対して通知するということである。
これにより、ＡＤＤＧＡ処理の開始トリガをかけるアプリケーションは、ＡＤＤＴＳ処理の成否を確認した上で、ＡＤＤＧＡ処理を開始する事が可能となる。よって、上述した、（問題Ａ）及び（問題Ｂ）を解決できる。
また、本発明に係る中央制御局は、上記のいずれかの通信管理方法により通信を管理するものであるとも言える。
また、本発明に係る通信局は、上記のいずれかの通信管理方法により通信を管理するものであるとも言える。
また、本発明に係る通信管理プログラムは、上記のいずれかの通信管理方法における手順を実行させるプログラムである。
また、本発明に係る通信管理プログラムは、上記のいずれかの通信管理方法における手順を実行させるプログラムである。
また、本発明に係る通信管理プログラムを格納したコンピュータ読み取り可能な記録媒体は、上記の通信管理プログラムを格納している記録媒体である。
また、本発明に係る通信局は、２つの通信局の間でダウンリンクストリームの通信セットアップを完了させるために、要求信号と応答信号の交換を必要とする通信方法に従う通信局であって、自局がデータ伝送における受信局となる場合に、データ伝送における送信局に対して、要求信号を送信する手段を有するものであるとも言える。
また、本発明に係る要求信号は、属性の異なる２つの通信局の間で通信セットアップを完了させるために、要求信号と応答信号の交換を必要とし、両方の通信局から要求信号を送信し得る通信方法における要求信号であって、通信局が属し得る属性について、それぞれの属性において通信セットアップを完了させるために必要となる情報を含めることができる要求信号であるとも言える。
ここで、「データ伝送」は「ストリーム伝送」という意味も含んでいる。また、属性とは、要求信号の送信元か応答信号の送信元といったこととは無関係に通信局に割り当てられる役割を意味する。例えば、ストリームの送信局か受信局か、とか、中央制御局であるかどうか等である。
また、本発明に係る通信局は、２つの通信局の間でダウンリンクストリームの通信セットアップを完了させるために、要求信号と応答信号の交換を必要とする通信方法に従う通信局であって、自局がデータ伝送における送信局となる場合に、データ伝送における送信局に対して、応答信号を送信する手段を有するものであるとも言える。
また、本発明に係る応答信号は、属性の異なる２つの通信局の間で通信セットアップを完了させるために、要求信号と応答信号の交換を必要とし、両方の通信局から要求信号を送信し得る通信方法における応答信号であって、通信局が属し得る属性について、それぞれの属性において通信セットアップを完了させるために必要となる情報を含めることができる応答信号であるとも言える。
また、本発明に係る通信局は、１つ以上の通信局と中央制御局からなる通信システムにおける通信局であって、中央制御局から通信局に対してのダウンリンクストリームの通信セットアップを行う際に、ＡＣＫ情報設定の要求信号を送信する手段を備えているものであるとも言える。
また、本発明に係る通信局は、上記の通信局において、前記ＡＣＫ情報設定の要求信号に前記通信局が望むＡＣＫ伝送方式、前記通信局におけるストリーム受信バッファのサイズ情報の内の少なくとも１つを含めて送信するものであるとも言える。
また、本発明に係る中央制御局は、１つ以上の通信局と中央制御局からなる通信システムにおける中央制御局であって、中央制御局から通信局に対してのダウンリンクストリームの通信セットアップを行う際に、ＡＣＫ情報設定の要求信号を解釈し、それに対するＡＣＫ情報設定の応答信号を送信する手段を備えているものであるとも言える。
また、本発明に係る中央制御局は、上記の中央制御局において、前記ＡＣＫ情報設定の応答信号に前記中央制御局が望むＡＣＫ伝送方式、前記中央制御局におけるストリーム送信バッファのサイズ情報の内の少なくとも１つを含めて送信するものであるとも言える。
また、本発明に係る通信局は、２つの通信局の間で合意すべき情報を含めた要求信号と合意すべき情報を含めた応答信号を交換して、合意すべき情報として２つ以上の値の中から１つの値を選択する通信方式に従う通信局であって、要求信号を受信した際に、要求信号の送信元が自局よりも優先度の高い通信局であった場合は、合意すべき情報として要求信号に含まれていた値が相手局との間で合意された値であると解釈し、合意すべき情報として要求信号に含まれていた値と同じ値を合意すべき情報として応答信号に含めて送信する手段を備えているものであるとも言える。
また、本発明に係る通信局は、２つの通信局の間で合意すべき情報を含めた要求信号と合意すべき情報を含めた応答信号を交換して、合意すべき情報として２つ以上の値の中から１つの値を選択する通信方式に従う通信局であって、要求信号を受信した際に、要求信号の送信元が自局よりも優先度の低い通信局であった場合は、自局の望む値が相手局との間で合意された値であると解釈し、自局の望む値を合意すべき情報として応答信号に含めて送信する手段を備えているものであるとも言える。
また、本発明に係る通信局は、２つの通信局の間で合意すべき情報を含めた要求信号と合意すべき情報を含めた応答信号を交換して、合意すべき情報として２つ以上の値の中から１つの値を選択する通信方式に従う通信局であって、合意すべき情報として応答信号に含まれていた値が相手局との間で合意された情報であると解釈する手段を備えているものであるとも言える。
なお、ここでは、送信してきた相手の優先度が自局より高いかどうかは関係ない。
また、本発明に係る通信局は、上記の通信局において、前記合意すべき情報がＡＣＫ伝送方式であるものであるとも言える。
また、本発明に係る通信局は、上記の通信局において、自局における前記優先度を要求信号に含めて送信する手段を備えているものである。
また、本発明に係る通信局は、上記の通信局において、前記優先度がストリーム送信局であるか、ストリーム受信局であるかによって決定されるものであるとも言える。
また、本発明に係る通信局は、２つの通信局の間で通信セットアップを完了させるために、１つの要求信号と１つの応答信号の交換を単位とする信号交換について、２単位以上の信号交換を行う必要があり、その内の第１の信号交換と第２の信号交換について、第１の信号交換における要求信号と第２の信号交換における要求信号の送信元の局が異なる通信方式に従う通信局であって、アプリケーションより下位の層が第１の信号交換における要求内容を自局が承認した事をトリガとして、アプリケーションより下位の層が第２の信号交換における要求信号の送信を開始する手段を備えているものであるとも言える。
また、本発明に係る中央制御局は、１つ以上の通信局と中央制御局からなる通信システムにおける中央制御局であって、中央制御局から通信局に対してのダウンリンクストリームの通信セットアップを行う際に、通信局からの帯域情報設定の要求信号を受信する手段と、帯域情報設定の要求信号による要求内容を自局が承認した事をトリガとしてダウンリンクストリームを送信する際のＡＣＫ情報設定の要求信号を、前記通信局に対して送信する手段を備えるものであるとも言える。
また，本発明に係る中央制御局は、上記の中央制御局において、前記トリガはＭＡＣ層を管理する層から他の層に対して通知されるものであるとも言える。
また、本発明に係る通信局は、２つの通信局の間で通信セットアップを完了させるために、１つの要求信号と１つの応答信号の交換を単位とする信号交換について、２単位以上の信号交換を所定の順序で行う必要があり、その内の連続している第１の信号交換と第２の信号交換について、第１の信号交換における要求信号と第２の信号交換における要求信号の送信元の局が異なる通信方式に従う通信局であって、第１の信号交換における応答信号の受信をトリガとして、第２の信号交換における要求信号の送信元の局に対して第２の信号交換を開始することを指示する手段を備えているものであるとも言える。
また、本発明に係る通信局は、１つ以上の通信局と中央制御局からなる通信システムにおける通信管理方法に従う通信局であって、中央制御局から通信局に対するダウンリンクストリームの通信セットアップを行う際に、帯域情報設定要求が成功したかどうかを中央制御局へ通知する手段を持つものであるとも言える。
また、本発明に係る通信局は、２つ以上の通信局からなる通信システムにおける通信局であって、２つの通信局の間でストリーム伝送のセットアップを完了させるために、要求信号と応答信号の交換を必要とし、両方の通信局から要求信号を送信する可能性があり、ストリームの送信局内で一意な識別子を持たせることにより通信システム全体におけるストリームの識別を行う通信方法に従う通信局であって、ストリーム伝送のセットアップにおける要求信号に、自局がセットアップしようとするストリームの送信局であるか受信局であるかという情報を含めて送信する手段を備えているものであるとも言える。
また、本発明に係る通信局は、２つ以上の通信局からなる通信システムにおける通信局であって、２つの通信局の間でストリーム伝送のセットアップを完了させるために、要求信号と応答信号の交換を必要とし、両方の通信局から要求信号を送信する可能性があり、ストリームの送信局内で一意な識別子を持たせることにより通信システム全体におけるストリームの識別を行う通信方法に従う通信局であって、ストリーム伝送のセットアップにおける要求信号に含まれている要求信号の送信元がセットアップしようとするストリームの送信局であるか受信局であるかという情報と、ストリーム識別子によって、要求信号の対象となるストリームを識別する手段を備えているものであるとも言える。
また、本発明に係る通信管理プログラムは、コンピュータに上記通信管理方法における手順を実行させるものである。
また、本発明に係るコンピュータ読み取り可能な記録媒体は、上記通信管理プログラムを格納したものである。
【産業上の利用の可能性】
データ通信を可能な状態とするために、通信設定処理を行う必要がある通信装置や、ネットワークシステムに適用可能である。
【図１】
2004064333.tif 000003
【図２】
2004064333.tif 000004
【図３】
2004064333.tif 000005
【図４】
2004064333.tif 000006
【図５】
2004064333.tif 000007
【図６】
2004064333.tif 000008
【図７】
2004064333.tif 000009
【図８】
2004064333.tif 000010
【図９】
2004064333.tif 000011
【図１０】
2004064333.tif 000012
【図１１】
2004064333.tif 000013
【図１２】
2004064333.tif 000014
【図１３】
2004064333.tif 000015
【図１４】
2004064333.tif 000016
【図１５】
2004064333.tif 000017
【図１６】
2004064333.tif 000018
【図１７】
2004064333.tif 000019
【国際調査報告】
2004064333.tif 000020
2004064333.tif 000021
2004064333.tif 000022