(57)【特許請求の範囲】
【請求項１】
無線ネットワークにおけるメディアアクセス制御（ＭＡＣ）レイヤーで、マルチキャスト伝送を行う方法であって、
送信側が、マルチキャストグループメンバーのチャネル条件によって、マルチキャストグループメンバーをサブグループに分け、各サブグループの代表ノードを指示するステップと、
送信側が、マルチキャストグループへ送信しようとするデータパケットがあるかを示すマルチキャスト送信要求パケットをマルチキャストグループメンバーにマルチキャストし、各サブグループ代表ノードからのマルチキャスト受信準備完了パケットを待つステップと、
送信側が、各サブグループの代表ノードからのマルチキャスト受信準備完了パケットを受信した後、マルチキャストグループメンバーに少なくとも一つのデータパケットをマルチキャストし、現時点に送信したデータパケットの番号を記録するステップと、
各サブグループにおける代表ノードがマルチキャストされた少なくとも一つのデータパケットを受信した後、各自のマルチキャスト受信準備完了パケットのビットマップフィールドに、今回送信されたデータパケットを成功に受信したかを示す値を記録し、確認応答パケット（ＡＣＫ）を送信しなく、予定時間周期後送信側にマルチキャスト受信準備完了パケットを送信するステップと、
送信側が、各代表ノードからのマルチキャスト受信準備完了パケットのビットマップフィールドに記録された値によって、データパケットロスがあったかを判断し、データパケットロスがあった場合、次回データパケットを送信する時にロスしたデータパケットを、送信しようとする新しいデータパケットとともにマルチキャストするステップと
を含むことを特徴とする方法。
【請求項２】
送信側が、マルチキャスト送信要求パケットを送信する前に、先ず、ＩＰレイヤーのマルチキャストアドレスを、メディアアクセス制御レイヤーのグループアドレスに翻訳するステップを更に含む
ことを特徴とする請求項１に記載の方法。
【請求項３】
送信側が、受信信号の強度であるチャネル条件が所定範囲内となるマルチキャストグループメンバーを、一つのサブグループに分ける
ことを特徴とする請求項１に記載の方法。
【請求項４】
前記送信側が、各マルチキャストグループメンバーからの信号強さを測定することによって、マルチキャストグループメンバーについてグルーピングする
ことを特徴とする請求項３に記載の方法。
【請求項５】
前記送信側が、マルチキャストデータパケットにノードＩＤを設定することによって、各サブグループの代表ノードを指示する
ことを特徴とする請求項１に記載の方法。
【請求項６】
前記送信側が、データパケットのノードＩＤフィールドに各サブグループ代表ノードのノードＩＤ位置を入れて、前記代表ノードの優先度を指示する
ことを特徴とする請求項５に記載の方法。
【請求項７】
前記マルチキャストデータパケットには、三つノードＩＤフィールドを含む
ことを特徴とする請求項６に記載の方法。
【請求項８】
前記マルチキャストグループメンバーは、多くても三つのサブグループに分けられる
ことを特徴とする請求項１に記載の方法。
【請求項９】
前記受信準備完了パケットのビットマップフィールドには、代表ノードが送信側に一回に送信した前記少なくとも一つのデータパケットを、正しく受信したかを指示する各ビットが複数含まれる
ことを特徴とする請求項１に記載の方法。
【請求項１０】
代表ノードが一つ或いは一つ以上のデータパケットを成功に受信できなかった場合、前記代表ノードが前記ビットマップフィールド中の成功に受信できなかったデータパケットの番号と対応するビットを「０」に設定するステップを更に含む
ことを特徴とする請求項９に記載の方法。
【請求項１１】
代表ノードがデータパケットを成功に受信した場合、前記代表ノードが前記ビットマップフィールド中の成功に受信したデータパケットの番号と対応するビットを「１」に設定するステップを更に含む
ことを特徴とする請求項９に記載の方法。
【請求項１２】
前記送信側は、各代表ノードが送信側にフィードバックした受信準備完了パケットのビットマップフィールドに含まれたビット中の対応するビットについて、それぞれ「論理積」演算を行って、マルチキャストグループメンバーの成功に受信できなかったデータパケットの確認標識を確定し、マルチキャストグループメンバーの成功に受信できなったデータパケットを再送するステップを更に含む
ことを特徴とする請求項１０或いは１１に記載の方法。
【請求項１３】
「論理積」演算を介したビットの値が０の場合、前記送信側は、番号の当該ビットと対応するデータパケットを成功に受信できなかったと確定する
ことを特徴とする請求項１２に記載の方法。
【請求項１４】
「論理積」演算を介したビットの値が１の場合、前記送信側は、番号の当該ビットと対応するデータパケットを成功に受信できたと確定する
ことを特徴とする請求項１２に記載の方法。
【請求項１５】
前記送信側が、マルチキャスト送信要求パケットにおけるフレーム制御領域ｓｕｂｔｙｐｅフィールドによって、マルチキャストグループメンバーに送信しようとするデータパケットがあるかを指示する
ことを特徴とする請求項１に記載の方法。
【請求項１６】
前記送信側には、マルチキャストグループメンバーに送信しようとするデータパケットがない場合、送信側はｓｕｂｔｙｐｅフィールドを０００１に設定する
ことを特徴とする請求項１５に記載の方法。
【請求項１７】
前記送信側には、マルチキャストグループメンバーに送信しようとするデータパケットがある場合、送信側はｓｕｂｔｙｐｅフィールドを００００に設定する
ことを特徴とする請求項１５に記載の方法。
【請求項１８】
各代表ノードは、各自の優先度によって、自身がマルチキャスト受信準備完了パケット応答を送信する前に待つべき時間周期を計算し、順番に送信側へマルチキャスト受信準備完了パケットを送信するステップを更に含む
ことを特徴とする請求項１に記載の方法。
【請求項１９】
送信側が送信しようとするデータパケットがないと指示した場合、代表ノードは、最後に送信したデータパケットを受信した後、送信側に確認応答パケットをフィードバックするステップを更に含む
ことを特徴とする請求項１に記載の方法。
【請求項２０】
前記送信側が以下の数式によって、マルチキャスト速度について、自己適応速度調整を行い、
【数１】
0005325605.tif 000007
その限定条件は、ｓｕｂ  ＰＤＲ＞Ｐｔｈｒであり、
ここで、Ｔｈｒａｖｅはマルチキャストメンバーの平均スループットを示し、Ｒは一定のＡＣＭ変調方式での送信速度を示し、ＢＥＲは一定の信号対雑音比の情況で特定ＡＣＭ方式を採用して得られたビット誤り率を示し、ＳＮＲはチャネルの信号対雑音比を示し、Ｎはマルチキャストメンバーの数で、ＰＤＲ（Ｐａｃｋｅｔ  Ｄｅｌｉｖｅｒｙ  Ｒａｔｉｏ）はデータパケットが成功に受信される比率を示し、Ｐｔｈｒは予め設定されたＰＤＲの閾値を示し、以下の数式によって表示され、
successfully_received_packetは成功に受信されたデータパケット数を示し、need_received_packetは受信が必要なデータパケット数を示し、packet_sizeはデータパケットのサイズを示す
ことを特徴とする請求項１に記載の方法。
【数２】
0005325605.tif 000008
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、無線ネットワークにおけるマルチキャスト方法に関連し、特に、無線ＬＡＮにおける信頼性高くマルチキャスト伝送を行う方法に関連し、当該方法は受信メンバーに対してグルーピングを行って、各グループの代表だけが送信側にフィードバック情報を送信することによって、遅延を減少し、マルチキャストプロトコルの効率を高めて、制御パケットのオーバヘッドを減少している。
【背景技術】
【０００２】
無線ブロードバンドアクセス技術において、ＩＥＥＥ  ８０２．１１は既に非常に普及された選択となっている。現在、無線ＬＡＮ上の多くの重要アプリケーションは全てマルチキャスト伝送に基づいている。これらのアプリケーションには、マルチメディア会議、共有ホワイトボード、遠距離教育、マルチユーザゲームと分散型計算等が含まれ、これらに限られてない。
【０００３】
マルチキャストは、データパケットを一つのソース側から複数の宛先側に送信することを示し、情報のコピーを１グループのアドレスに送信し、これらの情報を希望している全ての受信者に届ける。ユニキャストに比べて、マルチキャストの効率は非常に高い。これは、あらゆる与えられたリンクは多くても一回だけ使用されるため、ネットワークの帯域幅と資源を節約できる。マルチキャスト伝送の資源利用率面でのメリットによって、現在多くの注目を受けている。
【０００４】
無線ブロードバンドアクセスにおいて、無線ＬＡＮは非常に流行される選択になっている。家庭か会社かに関係なく、ＷＬＡＮはいずれも広い範囲に適用されている。この点から考慮すると、インターネットにおけるマルチキャストパケットの最後の１ホップは無線ＬＡＮである可能性が高い。
【０００５】
しかし、現在のインターネットのマルチキャスト設計において、通常、全てバックボーンネットで研究され、マルチキャストルート設計とグループメンバーのマネジメントに集中されている。ＷＬＡＮにおいて、ＭＡＣレイヤーのマルチキャスト伝送をサポートできない。アクセスポイントが、送信する必要の有る送信マルチキャストパケットを見つけた場合は、ただブロードキャストパケットとして処理する。通常、メディアアクセス制御（ＭＡＣ）レイヤーでは、マルチキャストパケットであるかどうかを考慮しない。そのため、ＭＡＣレイヤーではマルチキャスト設計を提供しなく、データパケットをブロードキャストとして処理する。この場合、ＩＰレイヤーのマルチキャストパケットがＷＬＡＮで伝送される時に、以下のような問題が生じる。一方、余分のＩＰ処理オーバヘッドが増える。これは、現在のＭＡＣレイヤーがマルチキャストパケットをサポートしないため、ＷＬＡＮにおけるノード（ｓｔａｔｉｏｎ）がＭＡＣレイヤーで受信したのがマルチキャストパケットかブロードキャストパケットかを区分しなくて、又サポートしないマルチキャストパケットも遮蔽できなく、当該パケットを一律にＩＰレイヤーに転送した後、受信側でマルチキャストアドレスによって当該パケットを受信するかしないかを判断する。これはＩＰレイヤーの必要ない処理オーバヘッドを増加することになる。一方、マルチキャストパケットがＷＬＡＮで伝送される時に、チャネルを保留するＲＴＳ（送信要求パケット）／ＣＴＳ（受信準備完了パケット）ハンドシェーク交互仕組みがなく、又誤り改正の再送仕組みもないため、伝送の信頼性がより低い。このように、マルチキャストパケットがリンク誤り或いは衝突によって失われることがある。
【０００６】
ＭＡＣレイヤーのマルチキャスト伝送をサポートするために、以下三つの問題を解決するべきである。
【０００７】
１．どのように情報衝突をさけるか。再送をサポートするために、グループメンバー（ｇｒｏｕｐ  ｒｅｃｅｉｖｅｒｓ）はフィードバック情報を送信ノード（通常はアクセスポイント（ＡＰ）である）に送信することで情報パケットが正しく受信されたかを通知する。複数のノードが同時にフィードバック情報を送信すると、ＡＰで衝突が生じ易い。
【０００８】
２．どのように制御パケットオーバヘッドを減少するか。信頼性の高い伝送をサポートするために、マルチキャストプロトコルは、ＲＴＳ（送信要求パケット）、 ＣＴＳ（受信準備完了パケット）、ＡＣＫ（確認応答）等の制御パケットを使用する必要がある。ユニキャストの場合、制御パケットのオーバヘッドはあまり高くないが、マルチキャストの場合、グループメンバーの全てがＲＴＳ、ＣＴＳとＡＣＫを送信すると、制御パケットのオーバヘッドは非常に大きい。
【０００９】
３．どのように送信速度を調整するか。ＷＬＡＮにおけるユニキャスト伝送は、送信側の自己適応速度調整をサポートする。チャネル条件がよい場合、送信側は送信速度を高め、逆の場合、送信速度を低減する。マルチキャスト伝送において、複数の受信ノードがあるため、それらのチャネル条件の変化は完全に異なる可能性があり、自己適応速度の調整を行う時に、ＡＰと複数の受信ノード間のチャネル条件を総合的に考慮するべきである。
【００１０】
又、ＷＬＡＮには、例えば、ノートパソコン、携帯電話、ＰＤＡ等の多種類の端末が存在する。これらの端末間は異種性が存在する。また、異なる端末の異なるアプリケーションに対して異なるＱｏＳ（サービス質）が要求される。そのため、現在のＩＰレイヤーのマルチキャストパケットが直接ＷＬＡＮで伝送されると上述問題がある。これらの問題から、ＭＡＣレイヤーの信頼性の高いマルチキャストプロトコルを設計するのは非常に必要がある。
【００１１】
従来技術では、信頼性の高いマルチキャスト伝送を実現するために既に複数の方法が提案されている。例えば、Ｊ．ＫｕｒｉとＳ．Ｋ．Ｋａｓｅｒａの発表した「Ｒｅｌｉａｂｌｅ  ｍｕｌｔｉｃａｓｔ  ｉｎ  Ｍｕｌｔｉ‐Ａｃｃｅｓｓ  Ｗｉｒｅｌｅｓｓ  ＬＡＮｓ」の文章（ＡＣＭ／Ｋｌｕｗｅｒ  Ｗｉｒｅｌｅｓｓ  Ｎｅｔｗｏｒｋｓ  Ｊｏｕｒｎａｌ，  ｖｏｌ．  ７，  ｎｏ．４，  ｐｐ．  ３５９‐３６９，  Ａｕｇｕｓｔ  ２００１を参照）;  Ｓ．Ｋ．Ｓ．Ｇｕｐｔａ，  Ｖ．Ｓｈａｎｋａｒの発表した「Ｒｅｌｉａｂｌｅ  ｍｕｌｔｉｃａｓｔ  ＭＡＣ  Ｐｒｏｔｏｃｏｌ  ｆｏｒ  Ｗｉｒｅｌｅｓｓ  ＬＡＮｓ」の文章（ＩＣＣ  ２００３，  ｐｐ９３‐ｐｐ９７，  ２００３を参照）；  Ｋ．ＴａｎｇとＭ．Ｇｅｒｌａの発表した「ＭＡＣ  Ｒｅｌｉａｂｌｅ  Ｂｒｏａｄｃａｓｔ  ｉｎ  ＡｄＨｏｃ  Ｎｅｔｗｏｒｋｓ」の文章（Ｐｒｏｃ．  ＩＥＥＥ  ＭＩＬＣＯＭ  ２００１，  ｐｐ．  １００８‐１０１３，  Ｏｃｔ．  ２００１を参照）；  Ｍ．Ｔ．Ｓｕｍ，  Ｌ．Ｈｕａｎｇの発表した「Ｒｅｌｉａｂｌｅ  ＭＡＣ  ｌａｙｅｒ  ｍｕｌｔｉｃａｓｔ  ｉｎ  ＩＥＥＥ  ８０２．１１  ｗｉｒｅｌｅｓｓ  ｎｅｔｗｏｒｋｓ」の文章（Ｐｒｏｃ．  ｏｆ  ＩＣＰＰ，  ｐｐ．  ５２７‐５３６，  Ａｕｇ．  ２００２を参照）；  及びＨｒｉｓｈｉｋｅｓｈ  Ｇｏｓｓａｉｎ，  Ｎａｇｅｓｈ  Ｎａｎｄｉｒａｊｕの発表した「Ｓｕｐｐｏｒｔｉｎｇ  ＭＡＣ  ｌａｙｅｒ  Ｍｕｌｔｉｃａｓｔ  ｉｎ  ＩＥＥＥ  ８０２．１１  Ｂａｓｅｄ  ＭＡＮＥＴｓ：  Ｉｓｓｕｅｓ  ａｎｄ  Ｓｏｌｕｔｉｏｎｓ」の文章（ＬＣＮ‘０４，  ２００４を参照）。
【００１２】
上述の従来技術において提出された方法は、以下の二種類に分けられる。第一類は否定フィードバックベースの（ＮＣＴＳ／ＮＡＣＫ）仕組み、もう一類は肯定フィードバックベースの（ＣＴＳ／ＡＣＫ）仕組みである。通常、否定フィードバックベースによるマルチキャストプロトコルの効率が高いが、その信頼性が劣れる。通常に採用する方法には、負フィードバックベースのマルチキャストプロトコル、例えば、ＬＢＰ（Ｌｅａｄｅｒ‐ｂａｓｅｄ  ｐｒｏｔｏｃｏｌ），ＤＢＰ（Ｄｅｌａｙｅｄ  ｆｅｅｄｂａｃｋ‐ｂａｓｅｄ  ｐｒｏｔｏｃｏｌ）とＰＢＰ（Ｐｒｏｂａｂｉｌｉｓｔｉｃ  ｆｅｅｄｂａｃｋ‐ｂａｓｅｄ  ｐｒｏｔｏｃｏｌ），及び正フィードバックによるマルチキャストプロトコル、例えば、ＢＭＷ（ブロードキャストメディアウィンドウプロトコル）とＢＭＭＭ（一括処理マルチキャストプロトコル）が含まれる。
【００１３】
ＬＢＰ（代表ベースのプロトコル：ｌｅａｄｅｒ  ｂａｓｅｄ  ｐｒｏｔｏｃｏｌ）は、ＩＥＥＥ  ８０２．１１のもとで、ＲＴＳ／ＣＴＳハンドシェーク仕組みと応答ＡＣＫの誤り訂正仕組みを拡張し、これによってマルチキャスト伝送を信頼性高くサポートする。このような方法において、予め１グループの受信者の中で、一つの代表（ｌｅａｄｅｒ）を指定する必要がある。ソース側（送信元）はマルチキャストデータパケットを送信する前に、先ず一つのマルチキャストＲＴＳパケット（ＭＲＴＳ）を全てのグループメンバーに送信する。受信グループ中の代表について、既にデータ受信の準備が出来ていれば、ＭＣＴＳ（マルチキャスト受信準備完了パケット）を応答し、逆の場合は、応答しない。受信グループ中のその他のメンバーに対して、データ受信の準備ができていなければ、ＮＣＴＳ（ｎｅｇａｔｉｖｅ  ＣＴＳ）を応答し、逆の場合は応答しない。このハンドシェークプロセスにおいて、受信グループの代表が受信の準備が出来てＣＴＳパケットを送信し、一方、あるメンバーが受信の準備が出来なくて、ＮＣＴＳパケットを応答するとしたら、このＮＣＴＳパケットは、受信グループの代表が送信したＣＴＳパケットとを衝突することになる。ソース側はＣＴＳパケットをセンシングしたら、チャネルを成功に取得したと認定し、マルチキャストデータの送信を始める。データパケットを受信した後、受信グループ中の代表に対して、データパケットが正しく受信されたら、ＡＣＫを応答し、逆の場合はＮＡＣＫを送信する；受信グループのその他のメンバーに対して、成功に受信されたら、応答しなく、逆の場合はＮＡＣＫを応答する。
【００１４】
そのため、ＬＢＰ方法をＩＥＥＥ  ８０２．１１に適用する場合には、受信側がどのようにフィードバックすればよいか判断しにくくなる。この問題は全ての負フィードバックベースのプロトコルに存在する。ＩＥＥＥ  ８０２．１１において、衝突或いはリンク誤りが発生すると、受信側は受信パケットを正しく受信できなく、当然ながら、パケットに携帯されている、例えば、パケットタイプ、パケットのソースアドレス、宛先アドレス等のヘッド情報がピックアップできない。そのため、受信側は正しくデータパケットを受信できなかった場合に、負フィードバックをするかしないか、又どのような負フィードバックをするかを決定しにくくなる。例えば、ＮＡＣＫをフィードバックするかＮＣＴＳをフィードバックするかを決定し難い。この問題を解決するためにＩＥＥＥ  ８０２．１１プロトコルを修正する余分の仕事が必要である。
【００１５】
又、ＬＢＰ方法をＩＥＥＥ  ８０２．１１に適用する場合、ソース側がマルチキャストデータを送信した後、非受信グループの代表メンバーとして、誤りパケットを受信した後、ＮＡＣＫパケットを送信し、これは受信グループ中の代表が送信したＡＣＫパケットとぶつかる。この衝突によって、ソース側は受信グループ中の代表がフィードバックしたＡＣＫパケットをセンシングできなくなり、当該データパケットを再送する。そのため、送信側は必要のない再送を行ってしまうことになる。データパケットの伝送があるメンバーのところで誤りが発生した時に、当該メンバーはデータパケットのシリアルナンバーを取得できないため、当該データパケットが再送データパケットであるかどうかを判断することができない。従って、当該メンバーは前に成功に当該データパケットを受信したかどうかに関わらず、一律にソース側にＮＡＣＫパケットをフィードバックする。それで、ソース側は必要のない再送を行うことになる。
【００１６】
また、ＬＢＰ方法をＩＥＥＥ  ８０２．１１に適用する場合には、さらにキャプチャ効果も生じる。キャプチャ効果とは、一つのノードが同時に二つのパケットを受信した時に、受信電力の強いデータパケットが正しくキャプチャされるということである。ある環境で、受信グループ中の代表はアクセスポイント（ＡＰ）に非常に近く、もう一つのノードはＡＰと離れると想定する。ＡＰがＣＴＳを応答し、もう一つのノードがＮＣＴＳを応答する場合に、このＮＣＴＳはＣＴＳと衝突するべきであるが、キャプチャ効果によって、ＡＰが送信したＣＴＳはソース側に正しく受信され、ＡＰに離れたノードが送信したＮＣＴＳ応答を正しく受信することができない。これによって、ソース側は自分がデータを送信してもよいと間違って判断してしまう。
【００１７】
ＤＢＰ方法とＬＢＰ方法の異なるところは、１）ＣＴＳだけでチャネル予約を行う。２）ランダムタイマーで複数ＣＴＳの衝突を避ける。
【００１８】
以下ＤＢＰ方法のプロセスについて説明する。先ず、ソース側は一つのタイムオーバータイマー（周期はＴ）を起動し、そして、ＭＲＴＳ（マルチキャスト送信要求パケット）を送信してチャネルを予約する。仮に、タイマーの周期がＴとする。全ての受信側のメンバーはＭＲＴＳをセンシングした後、一つのタイマー（タイマーの周期は｛１，２，・・・，Ｌ｝の中からランダムに選択することができる）を起動する。タイマーの時間になる前に、ノードＡがその他のノードが送信したＣＴＳパケットをセンシングしたら、自分のタイマーをキャンセルし、ＣＴＳパケットを送信しない。ノードＡがＣＴＳパケットをセンシングできなかったら、タイマーの時間になった時に、ＣＴＳ応答を送信する。ソース側はＴ時間を待って、ＣＴＳパケットを受信したら、データの送信を始める。受信側のメンバーらがデータを正しく受信した後、応答しない。受信したデータに誤りがあった場合、ＮＡＣＫパケットを送信して応答する。ＰＢＰ方法とＤＢＰ方法は非常に似ており、唯一の区別はＰＢＰ方法が確率によってＣＴＳ衝突を避けることである。
【００１９】
ＬＢＰ方法と比べて、ＰＢＰとＤＢＰ方法はチャネルを保留するのに更に多くの時間を必要とする。一方、最適のＰＢＰ応答の確率とＤＢＰのランダムタイマー周期を選択するには、このマルチキャストグループの大きさを知る必要があるが、この段階でマルチキャストグループの大きさを取得することが出来ない。そのため、最適な確率或はランダムタイマー周期等のパラメータを取得するためには、余分の情報を取得する必要がある。これはＰＢＰとＤＢＰ方法に存在する欠点でもある。
【００２０】
又、従来技術で提出された正フィードバックベースによる方法については、通常、ＢＭＷ（ブロードキャストメディアウィンドウプロトコル）とＢＭＭＭ（一括処理マルチキャストプロトコル）方法を採用する。これらの正フィードバックベースの方法は、上述の負フィードバック方法における欠点を克服しているが、その他の問題が起こっている。例えば、ＢＭＷ方法は、簡単に一つのマルチキャストプロセスを複数のユニキャストと見なしているため、効率が低い。効率を高めるために、ＢＭＭＭ方法が提出された。ＢＭＭＭ方法において、受信側のメンバーのＡＣＫ応答を協調するために、一つの新しいパケットタイプ（ＲＡＫ：請求肯定確認）を導入した。ＲＡＫパケットはＡＣＫパケット前に設定され、受信側のメンバーが順番でＡＣＫ応答を送信することを指示する。
【００２１】
図１ではＢＭＭＭ方法の基本プロセスを示している。ＢＭＭＭ方法において、有る送信側とｎ個の受信側がマルチキャスト通信を行うとしたら、前期にｎ個ＲＴＳ／ＣＴＳの交互を経過した後、送信側はデータパケット（ＤＡＴＡ）を送信し始めた。ＤＡＴＡ送信を完了した後、送信者はポーリングでＲＡＫパケットを各受信側へ送信する。受信者はＲＡＫパケットを受信した後、送信者にＡＣＫ応答を送信する。ＢＭＭＭ方法がＢＭＷ方法より信頼性が高いが、伝送中にｎ対ＲＴＳ／ＣＴＳ交互とｎ対ＲＡＫ／ＡＣＫ交互の必要があり、その制御パケットのオーバヘッド（ＲＴＳ、ＣＴＳ、ＲＡＫとＡＣＫ）が非常に大きい。以下表１で物理レイヤー制御パケットのオーバヘッドとデータパケットのオーバヘッドを示している。
【表１】
0005325605.tif 000002
【００２２】
表１で物理レイヤー制御パケットのオーバヘッドとデータパケットのオーバヘッドとを比較し、ここで伝送しようとするデータパケットが５１２バイトとする。表１からわかるように、伝送データパケットは１５タイムスロットを使用しているが、ＲＴＳ、ＣＴＳとＡＣＫは１２０タイムスロットを使用し、伝送データパケットのリソースは全体リソースの１０％も届かない。
【００２３】
前の説明からわかるように、既に提出されたマルチキャスト方法はある程度フィードバック衝突問題と制御パケットオーバヘッドの問題を解決したが、依然としてその他の問題が存在する。例えば、単に適用範囲からいうと、これらのマルチキャスト伝送方法は全てＩＥＥＥ  ８０２．１１ａ／ｂ／ｇに基づいて設計されたもので、ＩＥＥＥ  ８０２．１１ｎにはうまく適用できない。ＷＬＡＮの発展から見ると、新興する８０２．１１ｎ規格は最高６００  Ｍｂｐｓの伝送速度を有し、次世代無線ネットワーク技術だと公認されている。ＷＬＡＮのスループットを高めるために、ＩＥＥＥ  ８０２．１１ｎでは一部の新しい特徴を導入し、例えば、物理レイヤーのＭＩＭＯ（マルチ入力マルチ出力）、ＭＡＣレイヤーのデータ集合（ｄａｔａ  ａｇｇｒｅｇａｔｉｏｎ）（即ち、ネットワークアクセスポイントは一回に複数のデータパケットを送信する）、５７６種に達するオプション速度配置等等。前に記述された幾つかのマルチキャストプロトコルは、これらの新しい特徴を考慮してないため、更に高速のマルチキャスト伝送をサポートすることができない。
【００２４】
信頼性の高いマルチキャスト方法で解決すべきの上述三番目の問題（どのようにマルチキャスト送信速度を調整するか）について、従来技術で既に一部の適応速度調整アルゴリズムを提出している。ユニキャストにおける自己適応速度調整と比べて、マルチキャストにおける自己適応速度調整は、以下の二つの特殊の問題を解決しなければならない。（１）どのように複数のメンバーからのフィードバックによってチャネル条件を取得するか。ユニキャストの場合、通常では、受信ノードが送信したＣＴＳパケットの信号強さによってチャネル条件を判断する。しかし、マルチキャストの場合には、複数の受信ノードが同時にＣＴＳパケットを送信すれば、衝突が生じる。（２）どのように多種類が異なるチャネル条件によって送信速度を調整するか。
【００２５】
例えば、Ｊ．Ｖｉｌｌａｌｏ´ｎ等が発表した「ＲＳＭ：  ａ  ｃｒｏｓｓ‐ｌａｙｅｒ  ａｕｔｏ  ｒａｔｅ  ｓｅｌｅｃｔｉｏｎ  ｍｕｌｔｉｃａｓｔ  ｍｅｃｈａｎｉｓｍ  ｆｏｒ  ｍｕｌｔｉ‐ｒａｔｅ  ｗｉｒｅｌｅｓｓ  ＬＡＮｓ」の文章（ＩＥＥＥ  Ｃｏｍｍｕｎ．，  ２００７を参照、以下比較文献１と呼ぶ）ではＡＲＳＭ（自動速度選択マルチキャスト）アルゴリズムを提案している。当該方法は、各ノードがＣＴＳパケットを送信する前に、ある時間をバックする。このバック時間はノード自分のチャネル条件によって決められる。チャネル条件がよいと、対応するノードバック時間は長く、チャネル条件が劣れると、対応するノードのバック時間が短い。このように、チャネル条件の最も劣れるノードが優先的にチャネルを使用する。ＡＰは第一個目にフィードバックされたＣＴＳを受信すると、このＣＴＳの信号強さによって送信速度を調整する。
【００２６】
Ｍｉａｏ  Ｚｈａｏ等の提出した「Ｃｏｎｔｅｎｔｉｏｎ‐Ｂａｓｅｄ  Ｐｒｉｏｒｉｔｉｚｅｄ  Ｏｐｐｏｒｔｕｎｉｓｔｉｃ  Ｍｅｄｉｕｍ  Ａｃｃｅｓｓ  Ｃｏｎｔｒｏｌ  ｉｎ  Ｗｉｒｅｌｅｓｓ  ＬＡＮｓ」の文章（ＩＥＥＥ  ＩＣＣ，  ２００６参照、以下比較文献２と呼ぶ）で一種のＣＴＳ衝突検出方法を提案している。当該方法は、全ての受信ノードが同時にＣＴＳパケットを送信すると定義されているが、各ノードが送信するＣＴＳパケットの長さは異なる。チャネル条件がよければ、送信するＣＴＳパケットの長さは長くしてもよく、チャネル条件が悪ければ、ＣＴＳパケットの長さは短くしてもよい。こうすると、ＡＰで複数のＣＴＳパケットの衝突が生じるが、衝突した後、最も長いＣＴＳパケットは依然としてＡＰによって検出される。当該方法によって、ＡＰはチャネル条件の最もよいノードが送信したＣＴＳパケットを検出できることが理解できる。その後、ＡＰはこのＣＴＳの長さによって送信速度を調整する。
【００２７】
又、Ａｎａｓ  Ｂａｓａｌａｍａｈ等の発表した「Ｒａｔｅ  Ａｄａｐｔｉｖｅ  Ｒｅｌｉａｂｌｅ  Ｍｕｌｔｉｃａｓｔ  ＭＡＣ  Ｐｒｏｔｏｃｏｌ  ｆｏｒ  ＷＬＡＮｓ」の文章（ＩＥＥＥ  ＶＴＣ，  ２００６参照、以下比較文献３と呼ぶ）では、優先度に基づく競争方法を提案している。当該方法では一種のブラック衝突（Ｂｌａｃｋ  Ｂｕｒｓｔ：ＢＢ）パケットを導入している。全ての受信ノードがＣＴＳパケットを送信する前に、先ずＢＢパケットを送信してチャネルを占用する。チャネル条件がよければ、ＢＢパケットの長さが長くしてもよく、チャネル条件が悪ければＢＢパケットの長さが短くしてもよい。受信ノードがＢＢパケットを送信した後、チャネルセンシングが始まる。ＢＢが同時に送信されたため、ＢＢパケット間は衝突が発生する。しかし、衝突した後、ＡＰは依然として最も長いＢＢパケットをセンシングすることができる。このように、チャネル条件の最もよい受信ノードは最も長いＢＢパケットを通じてチャネルを占用し、成功にＣＴＳパケットを送信する。ＡＰはＣＴＳパケットを受信した後、信号強さによって送信速度を調整する。
【００２８】
上述の三つの方法について、ＡＣＭ（適応符号化変調）の配置が比較的に少ない時にはよく動ける。例えば、Ｍｉａｏ  Ｚｈａｏ等が提出した方法で、ＣＴＳの長さの変化には４種類の値が規定され、それぞれＩＥＥＥ  ８０２．１１ｂの四種類のＡＣＭ配置に対応する。しかし、規格でサポートするＡＣＭ配置が多い時に、この方法は動けなくなる。例えばＩＥＥＥ  ８０２．１１ｎで、多くて５７６種の速度配置をサポートできるため、それに対応して、ＣＴＳの長さの変化を５７６種類に定義すると非常に大きい資源の浪費を持ってくる。これと類似的に、その他の二種類アルゴリズムもこの問題が存在する。
【発明の概要】
【発明が解決しようとする課題】
【００２９】
以上に鑑みて、本発明は信頼性の高いＭＡＣレイヤーのマルチキャスト伝送方法が必要で、当該方法はＡＣＭ配置に適用することができる。本出願の同一出願人が２００７年１１月１９日に提出した中国特許出願Ｎｏ．２００７１０１８６０２１．７では本発明の一部の具体的な方法を提出しており、ここで当該出願を参考として導入する。
【課題を解決するための手段】
【００３０】
本発明は無線ネットワークのＭＡＣレイヤーでマルチキャスト伝送を行う方法を提供し、当該方法は受信グループメンバーをグルーピングし、各サブグループの代表ノードだけがＭＣＴＳパケットを送信側にフィードバックし、ＡＣＫ情報をＭＣＴＳパケットに搭載して、マルチキャストプロトコルの効率を高め、制御パケットのオーバヘッドを減少し、複数ＭＲＴＳの衝突を避け、かつ複数の受信ノードが送信ノードにＭＣＴＳをフィードバックする遅延を低減することができる。
【００３１】
本発明は、マルチキャストグループメンバーに対してグルーピングする方法をさらに提供し、無線ネットワークで行われるマルチキャスト伝送プロセスで、各マルチキャストメンバーともにフィードバック情報を送信することなく、各サブグループ中に一つのノードだけが情報をフィードバックすることによって、複数のノードが送信ノードにＣＴＳをフィードバックする遅延を低減した。
【００３２】
無線ネットワークにおけるメディアアクセス制御（ＭＡＣ）レイヤーで、マルチキャスト伝送を行う方法であって、送信側が、マルチキャストグループメンバーのチャネル条件によって、マルチキャストグループメンバーをサブグループに分け、各サブグループの代表ノードを指示するステップと、送信側が、マルチキャストグループへ送信しようとするデータパケットがあるかを示すマルチキャスト送信要求パケットをマルチキャストグループメンバーにマルチキャストし、各サブグループ代表ノードからのマルチキャスト受信準備完了パケットを待つステップと、送信側が、各サブグループの代表ノードからのマルチキャスト受信準備完了パケットを受信した後、マルチキャストグループメンバーに少なくとも一つのデータパケットをマルチキャストし、現時点に送信したデータパケットの番号を記録するステップと、各サブグループにおける代表ノードがマルチキャストされた少なくとも一つのデータパケットを受信した後、各自のマルチキャスト受信準備完了パケットのビットマップフィールドに今回送信されたデータパケットを成功に受信したかを示す値を記録し、確認応答パケット（ＡＣＫ）を送信しなく、予定時間周期後送信側にマルチキャスト受信準備完了パケットを送信するステップと、送信側が、各代表ノードからのマルチキャスト受信準備完了パケットのビットマップフィールドに記録された値によって、データパケットロスがあったかを判断し、データパケットロスがあった場合、次回データパケットを送信する時にロスしたデータパケットを、送信しようとする新しいデータパケットとともにマルチキャストするステップとを含む。
【発明の効果】
【００３３】
本発明は信頼性の高いＭＡＣレイヤーマルチキャスト伝送方法を提供している。当該方法では拡張可能な暗黙型確認（ＥＩＡ）方法を採用している。当該方法を利用して、ＭＣＴＳパケットにおいて、確認情報を搭載する方法を通じて、ＡＣＫパケットの送信を無くした。又、ＡＣＫパケット送信のキャンセルによって、ＡＣＫ／ＮＡＣＫパケットロスと衝突の確率を避け、一方、ＭＣＴＳにて最近成功に受信したかを指示するデータパケットの番号を搭載することによって、其の他のプロトコルに存在する必要のない再送問題を解決した。
【００３４】
本発明によれば、マルチキャストグループメンバーをサブグループ（ｓｕｂ‐ｇｒｏｕｐ）に分けて、各サブグループの一つの代表ノードが送信側にフィードバック情報を送信し、各マルチキャストグループメンバーがそれぞれ送信側にフィードバック情報を送信する必要がない。そのため、本発明の方法は複数の受信ノードが送信者にＭＣＴＳをフィードバックする遅延を低減することができる。
【００３５】
また、本発明は８０２．１１ｎのＭＡＣレイヤーにおける、例えば、データパケット集合（ｄａｔａ  ａｇｇｒｅｇａｔｉｏｎ）、即ち送信側が一回に受信グループメンバーに複数のデータパケットを送信する等の新特性と複数の送信速度配置を考慮して、マルチキャスト伝送に適応するデータ集合と適応速度調整アルゴリズムを提出した。
【図面の簡単な説明】
【００３６】
【図１】従来技術ＢＭＭＭ方法の基本動作プロセスを示す図である。
【図２】従来技術中のＲＴＳフレームフォーマットを示す図である。
【図３】本発明の実施例によってマルチキャスト伝送を行うＭＲＴＳのフレームフォーマットを示す図である。
【図４】本発明の実施例によってマルチキャスト伝送中のＭＲＴＳのフレームフォーマットを示す図である。
【図５】図４で示すＭＣＴＳフレームフォーマット中のビットマップ（Ｂｉｔｍａｐ）の一実例を示す図である。
【図６】マルチキャストデータパケットのフレームフォーマットを示す図である。
【図７】ＷＬＡＮにおいてマルチキャストを実行する一実例を示す図である。
【図８】インターネットグループマネジメントプロトコルパケットを利用してチャネル情報を取得するフローチャートである。
【図９】本発明によるサブグループ中の代表ノードのフィードバックしたＭＣＴＳパケットに付けられたビットマップの一実例を示す図である。
【図１０】本発明によってＡＰとかかる受信サブグループの代表ノード間で行われる伝送プロセスを示す図である。
【図１１】本発明実施例によってマルチキャスト伝送方法を実行するフローチャートを示す図である。
【図１２】従来技術に比べて本発明の方法によって得られた性能改善のグラフである。
【図１３】従来技術に比べて本発明の方法によって得られた性能改善のグラフである。
【図１４】従来技術に比べて本発明の方法によって得られた性能改善のグラフである。
【発明を実施するための形態】
【００３７】
以下図面を参照して、本発明の実施例について詳細に説明し、説明の中で、本発明に対して必要のない詳細と機能を省略して、本発明の理解を混乱させることを防止している。
【００３８】
図２で従来技術におけるＲＴＳのフレームフォーマットを示す図である。図２で示すように、８０２．１１で定義する従来技術のＲＴＳフレームには、フレーム制御（ｆｒａｍｅ  ｃｏｎｔｒｏｌ）領域、持続時間（ｄｕｒａｔｉｏｎ）領域、ＤＡ（宛先アドレス）領域、ＴＡ（送信側アドレス）領域、とＣＲＣ（巡回冗長検査）が含まれる。その中に、フレーム制御領域はフレームタイプの指定に使用され、持続時間領域はチャネル予約に使用され、ＣＲＣ領域は受信されたフレームが正しいかどうかを判断するのに使用される。
【００３９】
図３では本発明の実施例によってＭＡＣレイヤーでマルチキャスト伝送を行うＭＲＴＳのフレームフォーマットを示している。図３で示すように、本実施例によるＭＲＴＳのフレームフォーマットと図２で示す従来技術のＲＴＳフレームフォーマットの唯一の区別は、宛先アドレスを指示するＤＡ領域を受信グループアドレスを示すＲＡ領域に変更したことである。このような変更はフレームの構成フォーマットを変える必要がない。明示すべきことは，このグループアドレスはＩＰマルチキャストアドレスから転換されたのである。当該分野では、ＩＰアドレスが３２ビットで、ＭＡＣアドレスは４８ビットであることが知られている。ＩＰグループアドレスは、全てＤ類ＩＰアドレスで、その高位の４ビットは全て１１１０であり、残りの２８ビットはＭＡＣレイヤーのマルチキャストアドレスのマッピングに使用すればいい。実例として、２８ビットを１０進数と見なして、それを１６進数に転換し、結果は必要のＭＡＣアドレスである。
【００４０】
図４では本発明実施例によるマルチキャスト伝送におけるＭＣＴＳのフレームフォーマットを示している。図４で示すように、ＭＣＴＳフレームには、フレーム制御（ｆｒａｍｅ  ｃｏｎｔｒｏｌ）領域、持続時間（ｄｕｒａｔｉｏｎ）領域、ＧＡ（グループアドレス）領域、ＴＡ（送信側アドレス）領域、ビットマップ（Ｂｉｔｍａｐ）フィールドとＣＲＣ（巡回冗長検査）が含まれる。その内ＧＡ（グループアドレス：Ｇｒｏｕｐ  Ａｄｄｒｅｓｓ）はＩＰマルチキャストアドレスから転換されたのであり、それと図３におけるＲＡ領域の生成方法は同じである。Ｂｉｔｍａｐフィールドを追加したのはＩＥＥＥ  ８０２．１１ｎにおけるデータ集合の特徴を考慮したためである。即ち、ノードがチャネルを一回占用すると、複数のデータパケットを送信することができる。Ｂｉｔｍａｐが８ビット（ｂｉｔ）を占用する。あるデータパケットの受信に誤りが発生した時に、Ｂｉｔｍａｐフィールドにおける該当するビットを０に設定し、逆に、データパケットが正しく受信されたら、Ｂｉｔｍａｐフィールドにおける該当するビットを１に設定する。上述実施例において、ＡＰは一回に多くて８個のデータパケットしか送信できない。しかし、本発明はこれに限られなく、異なるビットを設定することで８個より多く或いは少ないデータパケットを送信することが出来る。
【００４１】
図５ではビットマップ（Ｂｉｔｍａｐ）フィールドの一実例を示している。例えば、仮に、ネットワークＡＰが一回に５つのデータパケットＤａｔａ（１）、Ｄａｔａ（２）、Ｄａｔａ（３）、Ｄａｔａ（４）とＤａｔａ（５）を送信したとする。データパケットＤａｔａ（２）とＤａｔａ（４）を受信する時に誤りが発生したら、図５で示すように、Ｂｉｔｍａｐの第二ビットと第四ビットを「０」に設定し、その他のビットを「１」に設定したＭＣＴＳをＡＰにフィードバックする。ＡＰが受信ノードのフィードバックしたＭＣＴＳを受信した後、そのなかのＢｉｔｍａｐフィールドの各ビット値を検出することで、その前に送信したデータパケットの正確性情況を判断することができる。
【００４２】
図６では本発明によるマルチキャストデータパケットのフレームフォーマットを説明している。図６で深い色で示す区域に規格で定義している元の１つのＡｄｄｒｅｓｓ  ４（６ビット）を三つのＳｔａｔｉｏｎ  ＩＤ（それぞれ２ビット）に変更した以外に、その他の図６で示すデータパケットのフォーマットはＩＥＥＥ  ８０２．１１で定義したのと同様である。Ｓｔａｔｉｏｎ  ＩＤはノードとＡＰの初期ネゴシエーションプロセスでＡＰによって割り当てられたのであり、このプロセスの詳細はＩＥＥＥ  ８０２．１１規格で見れる。つまり、一つのノードとネットワークＡＰが初期ネゴシエーションプロセスを完成すると、当該ノードは一つの２ビットのＳｔａｔｉｏｎ  ＩＤを割り当てられる。ＩＥＥＥ  ８０２．１１において、Ａｄｄｒｅｓｓ  ４このフィールドはあまり利用されていない。データがＡＰからＡＰ送信される時のみに、Ａｄｄｒｅｓｓ  ４フィールドを使用する。そのため、本発明によると、このアイドルのフィールドを利用して、各サブグループの代表ノード（ｓｕｂ‐ｇｒｏｕｐ  ｌｅａｄｅｒ）のＳｔａｔｉｏｎ  ＩＤを通知する。図６では、Ｓｔａｔｉｏｎ  ＩＤ  １、Ｓｔａｔｉｏｎ  ＩＤ  ２、及びＳｔａｔｉｏｎ  ＩＤ三つのフィールドを示している。
【００４３】
図７はＷＬＡＮでマルチキャストを行う一つの実例を示している。図７に示すように、セル１中のソースノードは、セル２中のマルチキャストグループにデータを送信する。ソースノードの生成したマルチキャストデータパケットは、セル１中のアクセスポイントＡＰ１とセル２中のアクセスポイントＡＰ２を介して、最後にセル２中のマルチキャストグループＧに送信される。
【００４４】
ここで、セル２中のアクセスポイントＡＰ２は、本発明のマルチキャスト方法を利用して受信グループに伝送を行う。説明し易いために、以下表２には、説明中に使用する一部の数値の意味を羅列している。
【表２】
0005325605.tif 000003
【００４５】
セル２中のネットワークＡＰ２のＭＡＣレイヤーが上位からのマルチキャストパケットを受信した場合、ＡＰ２は先ずＩＰレイヤーのマルチキャストアドレスをＭＡＣレイヤーのアドレスに翻訳する。その後、ＭＲＴＳ／ＭＣＴＳハンドシェーク仕組みを起動してチャネルを保留する。ＭＲＴＳを送信する前に、ＡＰ２は、先ず自分の出力キューにマルチキャストグループＧへ送信すべきのデータパケットがあるかどうかを判断する。あれば、ＡＰ２はＭＲＴＳパケットにおけるフレーム制御領域のｓｕｂｔｙｐｅ値を００００（当該値はＩＥＥＥ  ８０２．１１で保留されている）に設定し、マルチキャストグループＧに送信すべきデータパケットが有ることを示す。逆に、マルチキャストグループＧに送信すべきデータパケットがない場合、ＡＰ２はＭＲＴＳパケットにおけるフレーム制御領域のｓｕｂｔｙｐｅ値を０００１（この値はＩＥＥＥ  ８０２．１１で保留されている）に設定し、マルチキャストグループＧに送信すべきデータパケットがないことを示す。衝突回避プロセスを通じて、チャネルがアイドルの時に、ＡＰ２はＭＲＴＳのマルチキャストを始める。
【００４６】
ＡＰ２からのＭＲＴＳパケットを受信した後、各グループメンバーはＭＲＴＳ中のＳｕｂｔｙｐｅ値を記録し、受信したＭＲＴＳパケットに対して応答し、ＡＰにＭＣＴＳパケットをフィードバックする。複数のグループＧに複数のメンバーがあるため、各メンバーが、全てＡＰ２が送信したＭＲＴＳパケットに対して応答し、ＭＣＴＳパケットをフィードバックすると、ＡＰ２は複数の衝突したＭＣＴＳパケットを受信する。これらのパケットの衝突を避け、同時に制御パケットのオーバヘッドと遅延を減少するために、本発明の実施例によって、一つの大きいマルチキャストグループを若干のサブグループ（ｓｕｂ‐ｇｒｏｕｐ）に分ける。大きいマルチキャストグループをグルーピングした後は、各ノードがＡＰ２にＭＣＴＳパケットをフィードバックする必要なく、各サブグループのグループメンバー中の一つの代表（ｌｅａｄｅｒ）が順番にＡＰ２へＭＣＴＳパケットをフィードバックすればよい。
【００４７】
以下、どのように大きいマルチキャストグループについてグルーピングを行うか、どのようにグルーピングしたサブグループ中の代表ノードを選択するか、及びどのように各ノードにどのノードが代表ノードであるかを通知するかについて説明する。
【００４８】
マルチグループのグループメンバーについてグルーピングする目的は、チャネル条件の接近するノードを一つのサブグループに分けることである。グループ内の一つのメンバーが成功にデータパケットを受信すれば、同じサブグループのその他のメンバーも成功にデータパケットを受信したと見なしてよい。このような前提で、サブグループの全てのノードがＡＰ２にＭＣＴＳ情報をフィードバックする必要はない。チャネル条件の接近するノードを一つのサブグループに分けるためには、ＡＰ２と複数の受信ノード間のチャネル条件を知っておく必要がある。本実施例によって、実例として、インターネットグループマネジメントプロトコル（ＩＧＭＰ:Ｉｎｔｅｒｎｅｔ  Ｇｒｏｕｐ  Ｍａｎａｇｅｍｅｎｔ  Ｐｒｏｔｏｃｏｌ）パケットを採用してチャネル条件を取得する。ＩＧＭＰは一つのグループマネジメントプロトコルであり、インターネットでマルチキャストをサポートしようとすると、先ずＩＧＭＰプロトコルをサポートする必要がある。
【００４９】
図８はインターネットグループマネジメントプロトコルパケットを利用してチャネル情報を取得するフローチャートを示している。図８で示すように、ノードがマルチキャストグループに加入しようとする場合、先ず、ステップＳ８０１で、ネットワーク中のノードは、自分の接続するルータにマルチキャストグループ加入情報（ＩＧＭＰ  ｈｏｓｔ  Ｍｅｍｂｅｒｓｈｉｐ  ｒｅｐｏｒｔ：ＩＧＭＰホストメンバー報告）を送信してＡＰ或いはルータに登録を行う。ノードが成功にマルチキャストグループに加入した後、ステップＳ８０２で、ルータは１秒ごとに加入したノードにクエリ（ＩＧＭＰ  ｈｏｓｔ  Ｍｅｍｂｅｒｓｈｉｐ  ｑｕｅｒｙ：ＩＧＭＰホストメンバークエリ）情報を送信して、加入したノードがグループ内にあるかを確認する。クエリ情報を受信した後、ステップＳ８０３で、ノードはＡＰ或いはルータに応答情報（ＩＧＭＰ  ｈｏｓｔ  Ｍｅｍｂｅｒｓｈｉｐ  ｒｅｓｐｏｎｓｅ：ＩＧＭＰホストメンバー応答）を送信する必要がある。最後に、ステップＳ８０４で、加入したノードがマルチキャストグループを離れることを希望する場合、ＡＰ或いはルータに離れ情報（Ｌｅａｖｅ  ｍｅｓｓａｇｅ）を送信する。
【００５０】
上述プロセスを通じてわかるように、ノードが初期にマルチキャストグループに加入する時及びその後の一秒ごとに、ノードはＡＰ或いはルータにＩＧＭＰ情報を送信する。ＡＰを通じてＩＧＭＰ情報を観測することによって、ＡＰが各グループメンバーからＩＧＭＰパケットを受信した後、ＡＰは各グループメンバーからの受信信号強さ（ＲＳＳ）を測定することができる。その後、ＡＰは受信したノードのＲＳＳ値によって、これらのノードについてグルーピングする。マルチキャストデータパケットフォーマットの制限のため、現在サポートできるサブグループの数は３である。注意すべきことは、本発明がサポートするサブグループの数は３に限られなく、本発明の考え方によって、マルチキャストデータパケットのフォーマットを変えることで、更に多いサブグループの数をサポートすることができる。ネットワークにアクセスする各グループメンバーについてグルーピングした後、各サブグループから一つのノードを代表として選択する。実例として、ポーリング方式を採用して各サブグループの代表を選択することができる。即ち、各サブグループのグループメンバーが順番に本サブグループの代表ノードとし、このように各ノードは全て代表ノードになる機会がある。注意すべきことは、本発明はこれに限られなく、その他の方法を採用して各サブグループの代表ノードを選択してもよく、例えば、かかるサブグループ中の信号強さの最も弱いノードを代表とし、ＡＰが当該サブグループの代表のフィードバックしたＭＣＴＳ情報を受信した後、当該サブグループの各ノードがかかるデータパケットを成功に受信することを確保することができる。
【００５１】
各サブグループの代表ノードを選択した後、サブグループ中のグループメンバーにあるノードが本サブグループの代表に選択されたことを通知する必要がある。前記のマルチキャストデータパケットフォーマットに対する説明からわかるように、マルチキャストデータパケット（Ｍｕｌｔｉｃａｓｔ  Ｄａｔａ）には３つのＳｔａｔｉｏｎ  ＩＤフィールドがある。ＡＰは各サブグループの代表ノードのＩＤ情報をそれぞれこの三つのフィールドに入れることが出来る。マルチキャストメンバーがデータパケットを受信した場合、先ず、データパケットに携帯されたＳｔａｔｉｏｎ  ＩＤフィールドが自分のＩＤと同じであるかどうかをチェックする。同じであれば、当該マルチキャストメンバーは自分が所属するサブグループの代表として選択されたことがわかる。それで、当該ノードはＭＣＴＳパケットをＡＰにフィードバックする必要がある。代表ノードが順番にＭＣＴＳ情報をＡＰに送信し、ＭＣＴＳパケット間の衝突を避けるためには、各代表ノードのＭＣＴＳパケットをフィードバックする優先度と、そのＩＤのマルチキャストデータパケット中の位置とを関連付けて設定すればよい。例えば、ある代表ノードのＩＤがＳｔａｔｉｏｎ  ＩＤフィールド中の第２位に入れられたら、当該ノードがＭＲＴＳパケットを受信した後、早速ＣＴＳパケットをフィードバックしてはいけなく、ＴＭＣＴＳを待ってからＭＣＴＳパケットを送信することを意味する。つまり、ＡＰは、データパケットのノードＩＤフィールドに、各サブグループの代表ノードのノードＩＤの位置をいれて、前記代表ノードの優先度を指示する。マルチキャストメンバーが、チェックによって、ＤＡＴＡパケット中の３つのＳｔａｔｉｏｎ  ＩＤともに自分のＩＤと異なると、当該ノードは沈黙し、何のフィードバック情報も送信しない。
【００５２】
ＡＰ２は全てのサブグループの代表ノードのフィードバックしたＭＣＴＳパケットを成功に受信した後、マルチキャストデータの送信を始める。その後、全てのマルチキャストグループメンバーは、マルチキャストデータを受信する。マルチキャストグループメンバーは、ＭＲＴＳパケット中のフレーム制御領域中に、その前に記録したｓｕｂｔｙｐｅ値によって、ＡＣＫを応答する必要があるかどうかを決定する。Ｓｕｂｔｙｐｅ値が０００１であり、ＡＰに送信しようとするマルチキャストグループのデータがないことを指示する時だけに、グループメンバーはＡＰにＡＣＫを応答する。逆に、ｓｕｂｔｙｐｅ値が００００であって、ＡＰにまだマルチキャストグループに送信するデータがあることを示すれば、このような情況では、グループメンバーはＡＰにＡＣＫを応答しなくて、当該データパケットが成功に受信されたかどうかだけを記録すればよい。
【００５３】
仮に、ＡＰ２にマルチキャストグループＧに送信すべきデータパケットが複数であるとする。この場合、ＡＰはＭＲＴＳパケットにおけるｓｕｂｔｙｐｅフィールドを００００に設定する。受信グループメンバーは当該設定を検出したら、ＡＣＫを応答する必要がないことがわかる。
【００５４】
一つのセッションプロセス（ＭＲＴＳ／ＭＣＴＳ／ＤＡＴＡ）後、ＡＰ２は送信したデータパケットが全てのノードに成功に受信されたかどうかがわからない。続いて、ＡＰ２は、チャネルを保留するように、次のデータパケットのＭＲＴＳハンドシェークプロセスを起動する。このＭＲＴＳパケットを受信した後、サブグループの代表ノードは、その前に記録したＡＰの一回に送信した複数のデータパケットの受信情況を、ＡＰにフィードバックするＭＣＴＳパケットのＢｉｔｍａｐフィールド（Ｂｉｔｍａｐフィールドに対する詳細な説明は図５に示すＢｉｔｍａｐ設定実例を参考）に追加する。その後、サブグループ代表ノードはＭＣＴＳパケットをＡＰ２に送信する。ＡＰ２は全てのサブグループ代表ノードの送信したＭＣＴＳパケットを受信した後、ＭＣＴＳパケットに付けられたＢｉｔｍａｐフィールド中の各ビット値に対して「ビット論理積」演算を行って、一つの確認標識ｃｏｎｆｉｒｍ＿ｆｌａｇ値を取得する。ＡＰは取得したｃｏｎｆｉｒｍ＿ｆｌａｇ値によって、どのように成功に受信できなかったデータパケットを再送するかを判断する。
【００５５】
以下、図９の説明を合わせてＡＰが、どのようにマルチキャストグループメンバーが成功に受信できなかったデータパケットを判断するかを説明する。図９は本発明によるサブグループにおける代表ノードのフィードバックしたＭＣＴＳパケットに付けられたビットマップの一実施例を示す図である。仮に、ＡＰ２が一回にマルチキャストグループメンバーに８個のデータパケットＤａｔａ（１）、Ｄａｔａ（２）、Ｄａｔａ（３）、Ｄａｔａ（４）、Ｄａｔａ（５）、Ｄａｔａ（６）、Ｄａｔａ（７）とＤａｔａ（８）を送信したとする。図９に示すように、３つのサブグループの代表ノードが、ＡＰ２にフィードバックしたＭＣＴＳパケットの中に、それぞれ以下のビットマップ（Ｂｉｔｍａｐ）情報が付けられている。仮に、サブグループ１の代表ノード１が、データパケットＤａｔａ（１）、Ｄａｔａ（３）、Ｄａｔａ（５）、Ｄａｔａ（６）、Ｄａｔａ（７）とＤａｔａ（８）を成功に受信し、データパケットＤａｔａ（２）とＤａｔａ（４）は成功に受信できなかったとする。この場合、代表ノード１はＭＣＴＳパケット中のビットマップフィールドの第１、３、５、６、７番目と８番目のビットを「１」に設定し、成功にデータパケットＤａｔａ（１）、Ｄａｔａ（３）、Ｄａｔａ（５）、Ｄａｔａ（６）、Ｄａｔａ（７）とＤａｔａ（８）を受信したことを示す。又、代表ノード１はＭＣＴＳパケット中のビットマップフィールドの第２番目と４番目のビットを「０」に設定し、データパケットＤａｔａ（２）とＤａｔａ（４）を成功に受信できなかったことを示す。同様に、サブグループ２の代表ノード２は、データパケットＤａｔａ（１）、Ｄａｔａ（２）、Ｄａｔａ（５）、Ｄａｔａ（６）、Ｄａｔａ（７）とＤａｔａ（８）を成功に受信し、データパケットＤａｔａ（３）とＤａｔａ（４）は成功に受信できなかった。それで、代表ノード２はＭＣＴＳパケット中のビットマップフィールドの第１、２、５、６、７番目と８番目のビットを「１」に設定し、Ｄａｔａ（１）、Ｄａｔａ（２）、Ｄａｔａ（５）、Ｄａｔａ（６）、Ｄａｔａ（７）とＤａｔａ（８）を成功に受信したことを示し、また、代表ノード２はＭＣＴＳパケット中のビットマップフィールドの第３番目と４番目のビットを「０」に設定し、データパケットＤａｔａ（３）とＤａｔａ（４）を成功に受信できなかったことを示す。これと類似的に、サブグループ３の代表ノード３がデータパケットＤａｔａ（１）、Ｄａｔａ（３）、Ｄａｔａ（５）、Ｄａｔａ（６）とＤａｔａ（８）を成功に受信し、データパケットＤａｔａ（２）、Ｄａｔａ（４）とＤａｔａ（７）を成功に受信できなかった。それで、代表ノード３はＭＣＴＳパケット中のビットマップフィールドの第１、３、５、６番目と８番目のビットを「１」に設定し、データパケットＤａｔａ（１）、Ｄａｔａ（３）、Ｄａｔａ（５）、Ｄａｔａ（６）とＤａｔａ（８）を成功に受信したことを示す。また、代表ノード３はＭＣＴＳパケット中のビットマップフィールドの第２、４番目と７番目のビットを「０」に設定し、データパケットＤａｔａ（２）、Ｄａｔａ（４）とＤａｔａ（７）を成功に受信できなかったことを示す。その後、ＡＰは代表ノード１〜３のフィードバックしたＭＣＴＳパケット中のビットマップフィールドに対応するビットに対して「論理積」演算を行い、確認標識ｃｏｎｆｉｒｍ＿ｆｌａｇ値を取得する。図９中のｃｏｎｆｉｒｍ＿ｆｌａｇに対応する値が示すように、各代表ノードのフィードバックしたビットマップフィールドに対応するビットに対して「論理積」を行うことによって、第１、５、６番目と８番目のビットは「１」であり、第２、３、４番目と７番目のビットは「０」である。それで、ＡＰはデータパケットＤａｔａ（２）、Ｄａｔａ（３）、Ｄａｔａ（４）、Ｄａｔａ（７）の伝送に誤りが発生したことを確認し、これらのデータパケットＤａｔａ（２）、Ｄａｔａ（３）、Ｄａｔａ（４）、Ｄａｔａ（７）を再送する。
【００５６】
以下、図１０を参照して本発明実施例によるＡＰとグループメンバーの間で行われる伝送プロセスを説明する。図１０で示すように、仮に、マルチキャストグループには、一つの送信側（ＡＰ）と三つの受信サブグループがあるとする。まず、ＡＰはＩＧＭＰ情報によってマルチキャストグループについてグルーピングを行い、各サブグループの代表ノードを指定する。送信側（ＡＰ）がデータを送信する時に、普通複数のデータパケットを外に送信しようとする。前記のように、データパケットの集合特性に基づいて、送信側は一回に複数のデータパケットを送信できる。第一回にデータパケットを送信する前に、送信側は第一セッションで先ずＭＲＴＳを送信し、受信サブグループ中の代表ノード（ＧＨ１からＧＨ３）はＭＣＴＳを送信して交互を行う。図１０では受信サブグループの代表ノードが優先順位によってＭＣＴＳパケットを送信してＭＣＴＳパケットの衝突を避けることを示している。ＭＲＴＳ／ＭＣＴ交互が終わった後、送信側は第一回データパケット送信を始める（図１０中にシャドーラインのパケット）。ここまで、第一番目のセッションプロセスは終わる。
【００５７】
其の他のプロトコルにおいて、信頼性の高い伝送を確保するために、受信側は毎回送信されたデータパケットを受信した後ＡＣＫパケットを送信して、送信されたパケットを受信したことを確認する。其の他のプロトコルと異なり、本発明において、データパケット送信が終わる前に、即ち、ＭＲＴＳパケット中のフレーム制御領域のｓｕｂｔｙｐｅフィールドが００００である時に、受信サブグループの代表ノードは各データパケットに対して送信したＡＣＫパケットを除去した。その後、第二回セッションプロセスで、第二回データパケットを送信するために、送信側と受信サブグループの代表ノード間は同様にＭＲＴＳ／ＭＣＴＳ交互を行って初期化を実行する。送信側が第二回目セッションプロセスでＭＲＴＳパケットを送信した後、受信サブグループの代表ノードはＭＣＴＳパケットをフィードバックする必要がある。前記のように、この時フィードバックされたＭＣＴＳは既に変更されたのであり、ここには最近一回成功に受信した最新データパケットの番号を示すＢｉｔｍａｐフィールドが含まれている。仮に、送信者が第一回に送信した複数のデータパケットが全ての受信サブグループの代表ノードによって正しく受信され、第二セッションプロセスで各受信サブグループの代表がフィードバックしたＭＣＴＳパケットのＢｉｔｍａｐフィールドにおける各データパケット番号と対応するビットの値が「１」に設定されたとする。送信側が全ての受信サブグループの代表ノードからフィードバックされたＭＣＴＳパケットにおけるＢｉｔｍａｐフィールドのデータパケット番号に対応するビット値が全て「１」であることを見つけたら、全ての受信側が第一回に送信された全てのデータパケットを正しく受信したと判断し、第二回伝送データの送信を始めることができる。注意すべきことは、送信側が第一回データパケットを送信した後、ポーリング等のルールによって新しい代表ノードを指示してもよい。むろん、依然として元に指示された代表ノードを使ってもよい。
【００５８】
第二回の複数のデータパケットを送信した後、送信側が第三セッションプロセスで第三回データパケット送信を用意する。同様に、第三回データパケットを送信する前に、送信側と受信側の間でＭＲＴＳ／ＭＣＴＳ交互を行う。第二回目に送信したデータパケットが伝送中のある代表ノードで失われる可能性があり、送信側がＭＲＴＳパケット送信を終わった後、受信サブグループの代表ノードはＭＣＴＳパケットをフィードバックする。この時、ある代表ノードらが第二回に送信したデータパケットにおけるあるデータパケットらを失うことがあるため、そのフィードバックされたＭＣＴＳパケットのＢｉｔｍａｐフィールド中の失われたデータパケット番号とを対応するビットの値は、当該データパケットの紛失によって「０」に設定されることがあり、第二回に送信したデータパケットを成功に受信した受信サブグループの代表ノードがフィードバックしたＭＣＴＳパケットのＢｉｔｍａｐフィールドに対応するビット値は「１」である。送信側は受信側がフィードバックしたＭＣＴＳパケットに対応する位のビットに対して「論理積」演算を行った後で得られた対応する標識が０である場合、受信側が紛失した第二回に送信したデータパケットを判断できる。この場合、送信側は第三セッションプロセスで先ず第二回の送信で紛失されたデータパケットを送信し、その後第三回目に送信しようとするデータパケットを送信する。従って、第四セッションプロセス中で全てのデータパケットを送信し終わるまで、以上のように類推する。
【００５９】
本発明によって、次回データパケットに対して応答するＭＣＴＳパケットを利用して受信側が前回に送信されたデータパケットを正しく受信したかを確認し、ＡＣＫパケットのオーバヘッドを省く。又、受信側のグループメンバーを受信信号の強さ等の要素によってグルーピングし、かかるサブグループの代表ノードだけがＭＣＴＳパケットをフィードバックすることによって、複数の受信ノードが送信ノードにＭＣＴＳをフィードバックする遅延を減少することができる。また、送信しようとする新しいデータパケットと前に送信したデータパケットとを一つのセッションプロセスで送信することによって、一部の交互オーバヘッドを省く。
【００６０】
以下、図１０を参照して本発明によるＡＰとサブグループの代表ノードとの間で行われる伝送プロセスを説明する。先ず、ステップＳ１１０１で、送信側（ＡＰ）が起動し、ＡＰがＩＧＭＰ情報によってマルチキャストグループに対してグルーピングし、各サブグループの代表ノードを指定する。そして、ＡＰが無線ネットワークにＭＲＴＳパケットをブロードキャストする。送信側がステップＳ１１０２で送信者のタイマーを起動し、タイマーの周期をＴ１＝ＴＭＣＴＳ＋ＳＩＦＳ（表２に各パラメータの具体的な意味を羅列している）に設定して、受信側がフィードバックするＭＣＴＳを待つ。受信側はＭＲＴＳパケットを受信した後、ステップＳ１１０３で、各サブグループの代表ノードは自分の優先度によって、自分がＭＣＴＳに対して応答する前に待つべき時間を計算する。各代表ノードの待ち時間の計算は以下のようである。Ｔ２＝ｍ×ＳＩＦＳ＋（ｍ‐１）×ＴＭＣＴＳ（ここで、ｍは各代表ノードの優先度）。各代表ノードは自分が計算した待ち時間によって、自分のタイマーの周期をＴに設定する。その後、ステップＳ１１０４で、各代表ノードはＭＣＴＳパケットのＢｉｔｍａｐフィールドにおいて受信した複数のデータパケット番号に対応するビットに今回送信したかかるデータパケットを成功に受信したかを指示する値を搭載する。かかるデータパケットを成功に受信できなかったら、対応するビットを０に設定する。かかるデータパケットを成功に受信したら、対応するビットを１（前記のように）に設定する。当該代表ノードのタイマーが時間になって、即ちＴ２時間後、送信側にＭＣＴＳパケットを送信する。
【００６１】
次に、ステップＳ１１０５で、送信側は、自分のタイマーの周期Ｔ１になる前に、受信側からＭＣＴＳパケットを受信したかを判断する。ステップＳ１１０５で、周期Ｔ１の前にＭＣＴＳパケットを受信していないと判断すると、送信側はステップＳ１１０１に戻る。周期Ｔ１の前にフィードバックされたＭＣＴＳパケットを受信すると、ステップＳ１１０６に進み、現在のタイマーをキャンセルし、受信したＭＣＴＳパケットのＢｉｔｍａｐフィールドから対応する各ビットの値をピックアップして、各ビットの値を記録する。その後、ステップＳ１１０７で、送信側は全ての代表ノードがフィードバックしたＭＣＴＳパケットを受信したかを判断する。ステップＳ１１０７で全ての代表ノードがフィードバックしたＭＣＴＳパケットを受信していないと判断すると、ステップＳ１１０２に戻って、其の他のＭＣＴＳパケットを待つ。ステップＳ１１０７で全ての代表ノードがフィードバックしたＭＣＴＳパケットを受信したと判断すると、ステップＳ１１０８に進む。ステップＳ１１０８で、送信側が各代表ノードにフィードバックしたＭＣＴＳパケットのビットマップフィールド中の対応するビット分布に対して「論理積」演算を行って、確認標識ｃｏｎｆｉｒｍ＿ｆｌａｇ値を取得する。その後、ステップＳ１１０９で、全ての取得されたｃｏｎｆｉｒｍ＿ｆｌａｇに対応する各ビットの値が「０」か「１」かを判断する。取得したかかるビットに対応する値が「１」の場合、代表ノードが送信側の前回送信した複数のデータパケット値に対応するデータパケットを成功に受信し、取得したかかるビットに対応する値が「０」の場合、代表ノードは送信側が前回送信した複数のデータパケット値に対応するデータパケットを成功に受信できなかったことを表明する。
【００６２】
次に、ステップＳ１１０９の判断結果が否定の場合、フローはステップＳ１１１０に進み、送信側は成功に受信できなかったデータパケットの数によって、今回送信しようとする複数のデータパケットに、成功に受信できなかったデータパケットを追加し、再送するデータパケットの数と対応する新しいデータパケットを除去する。又、ステップＳ１１０９の判断結果が肯定である場合は、代表ノードが、既に今回送信した全てのデータパケットを成功に受信したことを表明する。この場合、ステップＳ１１１１に進み、送信側は受信者に新しいデータパケットを送信する。ステップＳ１１１０とＳ１１１１の後、送信側は、ステップＳ１１１２で、受信者に送信しようとする複数のデータパケット（再送のデータパケットを含む可能性がある）を順番に送信する。その後、ステップＳ１１１３で、受信サブグループの代表ノードは成功に受信できなかったデータパケットがないかを検出する。かかるデータパケットを成功に受信できなかったら、対応するビットを０に設定する。かかるデータパケットを成功に受信したら、対応するビットを１（前記のように）に設定し、ＭＣＴＳパケットを構成する。ステップＳ１１１３はステップＳ１１０４の後に手配されても良く、当該代表ノードのタイマーの時間になった時に、即ちＴ２時間後、送信側にＭＣＴＳパケットを送信する。
【００６３】
又、上記の従来技術の説明で、既に従来技術のＷＬＡＮにおけるマルチキャストの自己適応速度調整アルゴリズム（上記比較文献１〜３を参考）について記述している。マルチキャストの自己適応速度調整について、二つの問題を解決しなければならない。（１）どのように複数のフィードバック情報の衝突問題を解決するか（２）どのように複数の受信ノードのチャネル情況によって送信速度を調整するか。問題（１）に対して、本発明の提出した方法でＭＣＴＳパケットは順番によってフィードバックされたので、フィードバック情報の衝突問題が容易に解決される。上述問題（２）に対して、比較文献１と２ともに最も劣れる受信ノードによって送信速度を調整しており、このようは方法は信頼性を高めることができるが、システム効率を低減させる。比較文献３で提出した方法は、最もよい受信ノードによって速度を調整しており、このような調整方法は極端な考えである。比較文献３の提出した方法によると、よりよいシステムスループットが得られるが、ユーザの信頼性を保証できない。データパケット受信の信頼性とシステムスループット二つの要求を満足させるために、本発明では新しい自己適応速度調整アルゴリズムを提案し、この方法はある程度の信頼性を満足させるだけではなく、同時にシステム平均スループットの最大化を実現できる。
【００６４】
本発明によって、自己適応速度調整を一つの限定がある最適化問題と見なして、その最適化関数は以下の数式（１）で示すようである。
【数１】
0005325605.tif 000004
【００６５】
その限定条件は以下の数式（２）によって定義される。  
ｓｕｂ  ＰＤＲ＞Ｐｔｈｒ                          ……（２）
【００６６】
ここで、Ｔｈｒａｖｅはマルチキャストメンバーの平均スループットを表示し、Ｒは一定のＡＣＭ変調方式での送信速度を示し、ＢＥＲは一定の信号対雑音比の情況で特定されたＡＣＭ方式を採用して得られたビット誤り率を示し、ＳＮＲはチャネルの信号対雑音比を示し、Ｎはマルチキャストメンバーの数で、ＰＤＲ（Ｐａｃｋｅｔ  Ｄｅｌｉｖｅｒｙ  Ｒａｔｉｏ）はデータパケットが成功に受信される比率を示す。ＩＥＥＥ  ８０２．１１で、ＢＰＳＫ変調方式を採用すると仮定すると、Ｒ＝１Ｍｂｐｓである。以上の数式の中で、データパケットが成功に受信された比率を示すパラメータＰＤＲは一つの信頼性指標であり、以下の数式（３）によって、具体的に定義される。
【数２】
0005325605.tif 000005
【００６７】
ここで、ＰＬＲ（Ｐａｃｋｅｔ  Ｌｏｓｓ  Ｒａｔｅ）はデータパケットのパケットロス確率を示し、ＢＥＲ（Ｂｉｔ  Ｅｒｒｏｒ  Ｒａｔｅ）はデータパケット中のビット誤り確率を示す。
【００６８】
以上の説明から分かるように、このアルゴリズムの最適化目標は平均スループットの最大化であり、限定条件は一定のパケット成功率を満足することである。
【００６９】
図１２から１４は従来技術に比べて本発明の方法によって得られた性能改善のグラフである。
【００７０】
本発明はＯＰＮＥＴ  １１．５を利用してＥＩＡ、ＬＢＰ、ＤＢＰ、ＢＭＷとＩＥＥＥ  ８０２．１１アルゴリズムを実現している。本発明方法の性能を測定するために、以下の指標を使用している。
【００７１】
（１）データパケット成功に受信される比率（ＰＤＲ）：成功に受信されたデータパケットの数／受信すべきデータパケットの数
（２）平均パケット遅延：この遅延は、データパケットがＡＰのＭＡＣレイヤーキューに入った時点から計算し、それがマルチキャストグループグループメンバーに成功に受信されるまでである。
【００７２】
（３）遅延ジッタ
本発明の方法に対する比較で、以下の表３に羅列したパラメータを採用している。
【表３】
0005325605.tif 000006
【００７３】
図１２では、ＰＤＲがマルチキャストグループメンバーの数によって変化するカーブを示している。図１２から分かるように、ＥＩＡは最良のＰＤＲを取得している。これは主に二つの理由がある：（１）グループメンバーの順番的なフィードバックによって、ＡＰは各サブグループの情報を取得できる。しかし、其の他の負フィードバックに基づくプロトコルにとって、衝突、タイムオバー等原因で、ＡＰは全てのサブグループメンバーの情報を取得できない。（２）ＭＣＴＳに確認情報が搭載されており、ＡＣＫパケットロスと衝突による再送を減少する。
【００７４】
図１３では遅延がマルチキャストグループメンバーの数によって変化するグラフを示している。当該図では遅延マルチキャストのグループメンバの数によって変化するトレンドを比較している。ＩＥＥＥ  ８０２．１１にいかなるハンドシェーク仕組みと再送仕組みがないため、その遅延が最も小さい。ＥＩＡの遅延はＩＥＥＥ  ８０２．１１の遅延だけより大きい、其の他のアルゴリズムの遅延より小さい。
【００７５】
図１４では遅延ジッタの比較図を示している。図１４で示すように、複数のプロトコルが持ってくる異なる遅延ジッタを比較している。図１４からわかるように、ＥＩＡの遅延ジッタが最も小さい。これは、ＬＢＰとＤＢＰについて、一つのセッションにおいて、マルチキャストグループメンバーが二つの制御パケット（ＣＴＳ／ＮＣＴＳ  和  ＡＣＫ／ＮＡＣＫ）を応答する必要がある。ＡＣＫ／ＮＡＣＫを応答する時に、ロス或は衝突の可能性があり、次の必要のない伝送を発起する。しかし、本発明はこの問題が存在しない。
【００７６】
ここまで、本発明について好ましい実施例を合わせて説明した。当業者であれば本発明の精神及び範囲から逸脱しない限り、様々な変更、交換及び追加を行ってもよいことが理解されるはずである。そこで、本発明の範囲は前記特定の実施例に限られるものと理解してはならず、添付した請求項の範囲によって限定されるものである。
【図１】
0005325605.tif 000009
【図２】
0005325605.tif 000010
【図３】
0005325605.tif 000011
【図４】
0005325605.tif 000012
【図５】
0005325605.tif 000013
【図６】
0005325605.tif 000014
【図７】
0005325605.tif 000015
【図８】
0005325605.tif 000016
【図９】
0005325605.tif 000017
【図１０】
0005325605.tif 000018
【図１１】
0005325605.tif 000019
【図１２】
0005325605.tif 000020
【図１３】
0005325605.tif 000021
【図１４】
0005325605.tif 000022