(57)【要約】  マルチキャスト・サービスを求める複数のリクエストを受信するステップと、リクエストされたマルチキャスト・サービスを提供するために、マルチキャスト・ツリーにバインドするパスに関連付けられたパラメータを生成するステップと、パスをマルチキャスト・ツリーにバインドするステップと、を含む方法が記載されている。さらに、マルチキャスト・ツリー識別子を有する、マルチキャスト・サービスを求めるリクエストを受信するステップと、マルチキャスト・ツリー識別子のためのサービスレベルの品質を満たすパスにマルチキャスト・ツリー識別子をバインドするステップと、第１のメッセージをマルチホップ中継基地局に送信するステップと、を含む方法が記載されている。複数のパスによってサービスを提供されるクライアント装置からの、マルチキャスト・サービスを削除することを求めるリクエストを受信するステップと、マルチキャスト・サービスを削除するために、マルチキャスト・サービスからパスのバインドを解除することに関連付けられたパラメータを生成するステップと、マルチキャスト・ツリーからパスのバインドを解除するステップと、を含む方法が記載されている。さらに、中継局側からパスのバインドを解除する方法が記載されている。
2011518528.tif 000002
【特許請求の範囲】
【請求項１】
マルチキャスト・サービスを求める複数のリクエストを受信するステップと、
前記リクエストされたマルチキャスト・サービスを提供するために、マルチキャスト・ツリーにバインドするパスに関連付けられたパラメータを生成するステップと、
前記パスを前記マルチキャスト・ツリーにバインドするステップと、
を含む方法。
【請求項２】
前記バインドするステップは、前記生成されたパラメータを含む第１のメッセージを前記パスに沿って中継局にユニキャストすることおよびマルチキャストすることのいずれか一方をさらに含む、請求項１に記載の方法。
【請求項３】
前記パラメータは、マルチキャスト接続識別子と、前記マルチキャスト接続識別子に関するパラメータと、前記マルチキャスト接続識別子がバインドされるパスの数と、前記マルチキャスト接続識別子がバインドされるパスのリストとを含む、請求項２に記載の方法。
【請求項４】
マルチキャスト・サービスを求める前記リクエストを承諾可能であるかどうかを判定するステップと、
マルチキャスト・サービスを求める前記リクエストを承諾可能である場合に、マルチキャスト・ツリー識別子が既に割当てられているかどうかを判定するステップと、
前記マルチキャスト・ツリー識別子が既に割当てられている場合に、全てのパスがマルチキャスト・ツリー内に既に存在するかどうかを判定するステップと、
前記マルチキャスト・ツリー内に既に存在する全てのパスに関するツリー情報を更新するステップと、
前記マルチキャスト・ツリー内のパスに関するツリー情報を更新するステップと、
前記中継局から第２のメッセージを受信するステップと、をさらに含む、請求項３に記載の方法。
【請求項５】
前記中継局に第３のメッセージを送信し、マルチキャスト・サービスを求める前記リクエストを承諾する前記マルチキャスト接続識別子にバインドされている全てのパスに沿って転送するステップをさらに含む、請求項４に記載の方法。
【請求項６】
前記中継局に第３のメッセージを送信し、マルチキャスト・サービスを求める前記リクエストを拒絶する前記マルチキャスト接続識別子にバインドされていない全てのパスに沿って転送するステップをさらに含む、請求項４に記載の方法。
【請求項７】
前記マルチキャスト・サービスを承諾できない場合に、マルチキャスト・サービスを求める前記リクエストを拒絶するステップをさらに含む、請求項４に記載の方法。
【請求項８】
前記マルチキャスト・ツリー識別子が未だ割当てられていない場合に、前記マルチキャスト・ツリー識別子を割当てるステップと、
前記マルチキャスト・ツリーを構築するステップと、をさらに含む、請求項４に記載の方法。
【請求項９】
前記方法はマルチキャスト中継基地局において実施される、請求項１に記載の方法。
【請求項１０】
マルチキャスト・ツリー識別子を有する、マルチキャスト・サービスを求めるリクエストを受信するステップと、
前記マルチキャスト・ツリー識別子のためのサービスレベルの品質を満たすパスに前記マルチキャスト・ツリー識別子をバインドするステップと、
最初のメッセージをマルチホップ中継基地局に送信するステップと、
を含む方法。
【請求項１１】
前記中継局がリーフ・ノードとなるパスに前記第１のメッセージが送信される、請求項１０に記載の方法。
【請求項１２】
前記マルチキャスト・ツリー識別子のためのサービスレベルの品質を満たせないパスが存在するかどうかを判定するステップと、
前記マルチキャスト・ツリー識別子のためのサービスレベルの品質を満たせないパスに沿って、前記第１のメッセージを前記マルチキャスト中継基地局に送信するステップと、を含む、請求項１０に記載の方法。
【請求項１３】
全てのパスが同一の次の中継局を有するかどうかを判定するステップと、
全てのパスが前記同一の次の中継局を有する場合に、前記第１のメッセージを前記同一の次の中継局に転送するステップと、
マルチキャスト接続識別子と、前記マルチキャスト接続識別子に関するパラメータと、前記マルチキャスト接続識別子がバインドされるパスの数と、前記マルチキャスト接続識別子がバインドされるパスのリストとを含む情報を、相異なる中継局を有するパスに関する相異なるデータ構造に符号化するステップと、
相異なる次の中継局を有するパスに沿って、相異なる第２のメッセージを送信するステップと、をさらに含む、請求項１２に記載の方法。
【請求項１４】
前記中継局がリーフ・ノードとならないパスが存在する場合に、第２のメッセージを次の中継局にマルチキャストするステップをさらに含む、請求項１２に記載の方法。
【請求項１５】
マルチキャスト・サービスを求める前記リクエストにおいて特定されているパスのいずれかに前記中継局が存在するかどうかを判定するステップと、
マルチキャスト・サービスを求める前記リクエストにおいて特定されているパスのいずれにも前記中継局が存在しない場合に、マルチキャスト・サービスを求める前記リクエストを破棄するステップと、
マルチキャスト・サービスを求める前記リクエストにおいて特定されている前記パスのいずれにも前記中継局が存在しないすべてのパスを無視するステップと、をさらに含む、請求項１４に記載の方法。
【請求項１６】
前記方法は中継局によって実施される、請求項１０に記載の方法。
【請求項１７】
複数のパスによってサービスを提供されるクライアント装置からの、マルチキャスト・サービスを削除することを求めるリクエストを受信するステップと、
前記マルチキャスト・サービスを削除するために、前記マルチキャスト・サービスからパスのバインドを解除することに関連付けられたパラメータを生成するステップと、
前記マルチキャスト・ツリーから前記パスのバインドを解除するステップと、
を含む方法。
【請求項１８】
前記バインドを解除するステップは、前記生成されたパラメータを含む第１のメッセージを前記パスに沿って中継局にユニキャストすることおよびマルチキャストすることのいずれか一方をさらに含む、請求項１７に記載の方法。
【請求項１９】
前記パラメータは、マルチキャスト接続識別子と、前記マルチキャスト接続識別子に関するパラメータと、前記マルチキャスト接続識別子とのバインドが解除されるパスの数と、前記マルチキャスト接続識別子とのバインドが解除されるパスのリストとを含む、請求項１８に記載の方法。
【請求項２０】
マルチキャスト・ツリー内のパスに関するツリー情報を更新するステップと、
前記マルチキャスト・サービスを必要とするクライアント装置が依然として存在するパスが存在するかどうかを判定するステップと、
第２のメッセージを前記中継局に送信し、前記マルチキャスト・サービスを依然として必要とするパスに沿って転送するステップと、をさらに含む、請求項１９に記載の方法。
【請求項２１】
前記中継局から前記第２のメッセージを受信するステップと、
前記マルチキャスト・サービスを依然として必要とするクライアント装置が存在しないパスを前記マルチキャスト・ツリーから削除するステップと、
前記削除されたパスを使用していたクライアント装置に第３のメッセージを送信するステップと、をさらに含む、請求項２０に記載の方法。
【請求項２２】
前記方法はマルチキャスト中継基地局によって実施される、請求項１７に記載の方法。
【請求項２３】
複数のパスによってサービスの提供を受けるクライアント装置からの、マルチキャスト・サービスを削除することを求めるリクエストを受信するステップと、
前記中継局がリーフ・ノードとはならないパスのバインドを解除することに関連付けられたパラメータを生成するステップと、
前記マルチキャスト・ツリーから前記パスのバインドを解除するステップと、
を含む方法。
【請求項２４】
前記バインドを解除するステップは、前記生成されたパラメータを含む第１のメッセージを前記パスに沿って中継局にユニキャストすることおよびマルチキャストすることのいずれか一方をさらに含む、請求項２３に記載の方法。
【請求項２５】
前記パラメータは、マルチキャスト接続識別子と、前記マルチキャスト接続識別子に関するパラメータと、前記マルチキャスト接続識別子とのバインドが解除されるパスの数と、前記マルチキャスト接続識別子とのバインドが解除されるパスのリストとを含み、前記マルチキャスト・サービスを削除することを求める前記リクエストはマルチキャスト・ツリー識別子を含む、請求項２４に記載の方法。
【請求項２６】
マルチキャスト・サービスを削除することを求める前記リクエストにおいて特定された全てのパスから前記マルチキャスト・ツリー識別子のバインドを解除するステップと、
前記中継局がリーフ・ノードとなるパスが存在するかどうかを判定するステップと、
前記中継局がリーフ・ノードとなるマルチキャスト中継基地局に第２のメッセージを送信するステップと、をさらに含む、請求項２５に記載の方法。
【請求項２７】
前記方法は前記中継局によって実施される、請求項２３に記載の方法。
【請求項２８】
前記中継局が前記マルチキャスト・サービスを削除することを求める前記リクエストにおいて特定されたパスのいずれかに属するかどうかを判定するステップと、
マルチキャスト・サービスを削除することを求める前記リクエストにおいて特定された全てのパスから前記マルチキャスト・ツリー識別子のバインドを解除するステップと、
前記中継局がリーフ・ノードとなるパスが存在するかどうかを判定するステップと、
前記中継局がリーフ・ノードとなるマルチキャスト中継基地局に第２のメッセージを送信するステップと、をさらに含む、請求項２５に記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、無線マルチホップ中継通信システムに関し、具体的には、無線マルチホップ中継通信システムのためのマルチキャスト・ツリー管理に関する。
【背景技術】
【０００２】
（モバイル無線マルチホップ中継通信ネットワーク／システムを含む）マルチホップ無線ネットワークは、都市圏でのインターネット・アクセスに適用される有望な技術として成長している。ここで使用する「／」は、同一または同様の要素または構造に対する代替的な名称を表す。即ち、「／」は、本明細書において、「または」と同様の意味で使用されることがある。本発明においては、インフラストラクチャとしてのマルチホップ無線中継ネットワークが考慮される。インフラストラクチャとしてのマルチホップ無線中継ネットワークは、１つ以上のマルチホップ中継基地局（ＭＲ‐ＢＳ：  ｍｕｌｔｉ‐ｈｏｐ  ｒｅｌａｙ  ｂａｓｅ  ｓｔａｔｉｏｎ）と、中継ノード／局（ＲＳ：  ｒｅｌａｙ  ｓｔａｔｉｏｎ）と、移動局（ＭＳ：  ｍｏｂｉｌｅ  ｓｔａｔｉｏｎ）／末端装置とから構成される。各中継ノードは、ネットワーク・インフラストラクチャの一部であり、基地局に接続されてバックホール・マルチホップ無線ネットワークを形成する。基地局は、インターネットなどの他のネットワークに接続してもよい。移動局／末端装置は、ネットワーク・アクセスを得るために、ＭＲ‐ＢＳまたはＲＳに関連付けられている／接続されている／取り付けられている。
【０００３】
従来技術において、ＭＲ‐ＢＳとＲＳとの間のユニキャスト・パスを構築するスキームが記載されている。例示的なマルチホップ中継通信システムの概略図である図１を参照すると、ＲＳ１がネットワークに入ると、初期レンジングの後、ＭＲ‐ＢＳとＲＳ１との間にパスＰ１が構築される（Ｐ１＝｛ＭＲ‐ＢＳ，ＲＳ１｝）。図１は、従来技術がどのように動作するのか、及び、本発明がどのように動作するのかの双方を例示するために用いられる。Ｐ１にパス識別子（ＩＤ）が割当てられる。ＲＳ２がネットワークに入ると、ＭＲ‐ＢＳとＲＳ２との間にパスＰ２が構築される（Ｐ２＝｛Ｐ１，ＲＳ２｝）。パス情報は、パスに沿って全ての中継ノード（ＲＳ）に通信される。ＭＳ１がネットワークに入ると、初期レンジングの後は、ＭＲ‐ＢＳは、ＭＳ１がＲＳ２に関連付けられていることを把握しており、ＭＲ‐ＢＳは、ＭＳ１の基本プライマリ管理接続識別子（ＣＩＤ）をＰ２にバインドする。さらに、ＭＲ‐ＢＳは、ＲＳ１とＲＳ２に通知を行い、ＭＳ１の基本プライマリ管理ＣＩＤをＰ２にバインドする。ＭＳ１で開始または終了する全てのユニキャスト・トラフィック・フロー、Ｐ２にバインドされたＣＩＤを有している。システムにおける全てのＲＳについて、ＭＲ‐ＢＳから各ＲＳに至る固有のパスが存在する。システムにおける各ＭＳについて、それらの基本プライマリ管理ＣＩＤはパスにバインドされている。ＭＲ‐ＢＳに直接接続するＭＳについては、Ｐ０＝｛ＭＲ‐ＢＳ｝が規定され、それらのＣＩＤはＰ０にバインドされる。なお、ユニキャスト・スキームでは、パスを複数のＣＩＤにバインドできるが、各ＣＩＤは１つのパスのみにバインドされることに留意されたい。
【０００４】
マルチキャストおよびブロードキャスト・サービス（ＭＢＳ：  ｍｕｌｔｉｃａｓｔ  ａｎｄ  ｂｒｏａｄｃａｓｔ  ｓｅｒｖｉｃｅｓ）は、モバイル無線ネットワークにとって非常に重要である。ＩＥＥＥ８０２．１６ｅなどのシングルホップ無線通信システムにおいては、ＭＢＳがマルチキャストおよびブロードキャスト・サービス・フローに関連付けられる。マルチキャストおよびブロードキャスト・サービス・フローは、特定の末端装置／移動局／モバイル装置に専用のものではない。表記を簡略化するために、本明細書においては末端装置を移動局（ＭＳ：  ｍｏｂｉｌｅ  ｓｔａｔｉｏｎ）として示すが、末端装置にはさらに、ラップトップ、ＰＤＡ、携帯電話、モバイル端末、または他のこのようなモバイル装置が含まれることに留意されたい。マルチキャスト・サービスを受信するために１つ以上のＭＳがリクエストを基地局に送信すると、マルチキャスト・サービス・フローのためのマルチキャスト接続がインスタンス化され、接続識別子（ＣＩＤ：ｃｏｎｎｅｃｔｉｏｎ  ｉｄｅｎｔｉｆｉｃａｔｉｏｎ  ｎｕｍｂｅｒ）番号がこのマルチキャスト接続に割当てられる。次に、ＢＳは、同一のＣＩＤを使用してリクエストを行っている各ＭＳとのマルチキャスト・トラフィック接続を構築する。各マルチキャスト・サービス・データ・ユニット（ＳＤＵ：ｓｅｒｖｉｃｅ  ｄａｔａ  ｕｎｉｔ）は、ＢＳによって一度のみ送信され、マルチキャスト・サービスをリクエストしている全てのＭＳは、ＳＤＵを受信することができる。マルチキャストＳＤＵは、ＢＳから各ＭＳに直接送信され、シングルホップ無線通信システムのためにマルチキャスト配信ツリーを構築する必要はない。
【０００５】
中継局が存在しない場合、基地局と移動局との間のサービスを追加、変更、および削除するリクエストが、ＤＳｘ信号メッセージによって行われ、ＤＳｘメッセージは、ＤＳＡ、ＤＳＣ、およびＤＳＤメッセージを含む。中継局が追加される場合には、マルチホップ中継基地局（ＭＲ‐ＢＳ）と中継局との間の通信、さらに、２つの中継局（ＲＳ）間の通信のためにＤＳｘメッセージが拡張される。拡張は移動局（ＭＳ）には見えないところで実行され、そのため、ＭＳは拡張されたＤＳｘメッセージを理解することができない。明確化のため、このメッセージが拡張されたＤＳｘメッセージであることを示すために「＊（アスタリスク）」がＤＳｘメッセージの最後に追加されている。ＭＲ‐ＢＳおよびＲＳ局は、ＤＳｘメッセージと、ＤＳｘ＊によって表される拡張ＤＳｘメッセージの双方を理解／解釈できるが、移動局（ＭＳ）は、ＤＳｘメッセージしか理解できない。
【０００６】
マルチキャストは、ネットワーク・リソースを効率的に利用できるようにし、データを１つの送信元から複数の送信先のノードに伝送する。無線マルチホップ中継（ＭＲ）システムにおいては、マルチホップ中継基地局（ＭＲ‐ＢＳ）とＭＳとの間に１つ以上の中継局（ＲＳ）が存在することがある。ＲＳに関連付けられている／取り付けられている／接続されているＭＳがマルチキャスト・アプリケーションに参加すると、マルチキャストＳＤＵ／パケット／フレームは、ＭＲ‐ＢＳからＭＳが関連付けられているＲＳに転送される必要がある。なお、無線ＭＲシステムにおけるノードのサブセットのみが特定のマルチキャスト・サービス／グループに参加して、このマルチキャスト・サービスのためのマルチキャストＳＤＵを送受信することがある。マルチキャスト／サービス／グループは、マルチキャスト・サービスの各メンバー間の通信のために、自己のマルチキャスト接続ＩＤ（ＭＣＩＤ）を有する。ＭＲ‐ＢＳから１つ以上のＲＳにＳＤＵ／パケット／フレームを送信する１つの方法は、ネットワーク内の各ＲＳに、これらがパケット／フレーム／ＳＤＵの受信を必要としているか否かに関わらず、ＳＤＵ／パケット／フレームをブロードキャストすることである。ＭＲ‐ＢＳから各ＲＳにマルチキャストＳＤＵ／パケット／フレームを送信する方法に係る問題を解決するための別のアプローチは、マルチキャストＳＤＵをカプセル化し、これらを個々に、マルチキャスト・サービスをリクエストした各ＭＳに関連付けられているＲＳの各々にユニキャストすることである。しかしながら、このスキームにおいては、ＭＲ‐ＢＳまたは中間ＲＳは、同一のＳＤＵを複数回送信する必要があり、やはり、帯域幅の観点から大きなコストが発生する。
【０００７】
マルチキャスト分配ツリーを構築、維持し、マルチキャスト分配ツリーの各分岐に沿ってマルチキャストＳＤＵ／パケット／フレームを分配する方法を有することが望ましい。このように、マルチキャストＳＤＵは、ＭＲ‐ＢＳによって一度のみＲＳに送信され、そのＲＳによって一度のみ、さらに別のＲＳまたはＭＳに送信される。マルチキャストＳＤＵは、マルチキャストおよびブロードキャスト・サービスをリクエストしたＭＳに関連付けられたＲＳにのみ送信される。従って、マルチキャスト用の帯域幅利用が改善される。
【０００８】
有線および無線ネットワークにおけるマルチキャスト・グループのためのマルチキャスト・ツリーを発見および構築するためにＩＰレイヤーのマルチキャスト・ルーティング・プロトコルが使用されてきた。ＩＰレイヤーのマルチキャスト・ルーティング・プロトコルは、ＩＰアドレスに基づくものである。プロトコル独立マルチキャスト‐スパース・モード（ＰＩＭ‐ＳＭ：Ｐｒｏｔｏｃｏｌ  Ｉｎｄｅｐｅｎｄｅｎｔ  Ｍｕｌｔｉｃａｓｔ‐Ｓｐａｒｓｅ  Ｍｏｄｅ）およびプロトコル独立マルチキャスト‐デンス・モード（ＰＩＭ‐ＤＭ：Ｐｒｏｔｏｃｏｌ  Ｉｎｄｅｐｅｎｄｅｎｔ  Ｍｕｌｔｉｃａｓｔ  Ｄｅｎｓｅ  Ｍｏｄｅ）は、２つのＩＰマルチキャスト・ルーティング・プロトコルである。ＰＩＭ‐ＤＭは、フラッディング（ｆｌｏｏｄｉｎｇ）、その次に、プルニング（ｐｒｕｎｉｎｇ）手法を用い、大きなオーバーヘッドが発生する。ＰＩＭ‐ＳＭは、ジョイン／プルン（ｊｏｉｎ／ｐｒｕｎｅ）手法を用い、これは、ネットワーク・リソース利用の観点からは、より効率的である。しかしながら、これらのプロトコルは、分散型でコネクションレスのインターネット通信のために設計されたものであり、マルチキャスト・ツリー・ルーティングの構築および解体（ティアダウン：ｔｅａｒ  ｄｏｗｎ）は、マルチキャスト・グループの各メンバーによって行われる。これに対し、本発明においては、マルチキャスト配信ツリー・ルーティングは、基地局（ＭＲ‐ＢＳ）によって制御される。
【０００９】
さらに、レイヤ２媒体アクセス制御（ＭＡＣ：  ｍｅｄｉａ  ａｃｃｅｓｓ  ｃｏｎｔｒｏｌ）アドレスに基づく有線または無線のメッシュ・ネットワークのためのマルチキャスト・ルーティングが提案されている。しかしながら、これらのプロトコルにおけるマルチキャスト・ツリーの構築および解体もまた、マルチキャスト・グループの各メンバーによって分散制御される。
【００１０】
無線マルチホップ中継ネットワークのネットワーク構造は、有線のインターネットや有線または無線のメッシュ・ネットワークのものとは全く異なる。マルチホップ中継ネットワークにおいては、ＭＲ‐ＢＳは、中央制御ポイントである。マルチホップ中継ネットワークは、ルートとしてのＢＳとのツリータイプの無線接続を有する。マルチホップ中継ネットワークは、メッシュおよびコネクションレスの有線や無線のネットワークと比較すると、コネクション指向型のネットワークである。ＳＤＵ／パケット／フレームは、有線または無線メッシュ・ネットワークおよびインターネット通信におけるような送信先アドレスや送信元のアドレスではなく、接続ＩＤに基づいて送信される。接続ＩＤは、基地局によって動的に割当てられる。有線または無線のメッシュ・ネットワークやインターネット通信のために使用されるマルチキャスト・ルーティング・プロトコルは、マルチホップ中継ネットワークには適用されない。従って、無線マルチホップ中継ネットワークのためのマルチキャスト・メカニズムが、マルチキャスト接続ＩＤを使用して効率的なマルチキャスト通信を行うためのマルチキャスト配信ツリーの構築、維持、および解体に必要である。
【００１１】
マルチホップ中継無線通信ネットワークにおいては、移動局（ＭＳ）は、１つ以上の中継局（ＲＳ）を介してＭＲ‐ＢＳ（基地局）に接続することがある。ルーティングおよびデータ配信効率を向上するために、ＭＲ‐ＢＳをＭＳに接続するパスが構築される。パスは、ＭＲ‐ＢＳと、ＭＲ‐ＢＳとＭＳとの間の１つ以上の中間ＲＳとで構成される。同一のパスを使用して複数のＭＳがＭＲ‐ＢＳに接続する場合がある。各パスには、パスＩＤ（ｐａｔｈ＿ＩＤ）が割当てられる。ＭＲ‐ＢＳとＭＳとの間でサービス・フローまたは接続が確立される必要がある場合には、接続識別子（ＣＩＤ：  ｃｏｎｎｅｃｔｉｏｎ  ｉｄｅｎｔｉｆｉｅｒ）がこの接続に割当てられる。このＣＩＤは、次に、サービス・フローを有効にすることができるように、ＭＳをＭＲ‐ＢＳに接続するパスにバインドされる。ＣＩＤとパスＩＤとの間のバインドは、更新することも可能であるし、解除することも可能である。ＣＩＤとパスＩＤとの間のバインドの更新および解除は、ＭＲ‐ＢＳと対応するＭＳとを接続するパスに沿ってＤＳｘ＊信号／メッセージを送信することによって成し遂げられる。ＤＳｘ＊メッセージは、ＤＳＡ＊、ＤＳＤ＊、およびＤＳＣ＊信号／メッセージを含み、ここで、ＤＳは、ダイナミック・サービスを表し、「ｘ」はＡ、Ｄ、またはＣを表すように使用される。Ａは追加（ａｄｄｉｔｉｏｎ）を表し、Ｄは削除（ｄｅｌｅｔｉｏｎ）を表し、Ｃはメッセージの変更（ｃｈａｎｇｅ）を表す。従来技術においては、単一のＤＳｘ＊メッセージを使用して、単一の信号パスＩＤに対して複数のＣＩＤをバインドし、更新し、解除することができる。本願出願人によってｍｍｄｄｙｙに出願された先願の特許出願（ＰＵ０７０６６）では、既存のＤＳｘ＊メッセージを使用してマルチキャスト・ツリーを構築及び維持する方法および装置が教示されている。ＭＢＳサービスにおいては、マルチキャストＣＩＤ（ＭＣＩＤ）を複数のパスにバインドすることができる。既存のＤＳｘ＊メッセージは、ＭＢＳサービスにおける接続管理にとって効率的なものではない。例えば、ＭＲ‐ＢＳが複数のＭＳのためにＭＢＳを開始することを望むか、または、同時に複数のＭＳからのＭＢＳリクエストを受信し、これらのＭＳが相異なるパスを使用してＭＲ‐ＢＳに接続する場合、複数のＤＳＡ‐ＲＥＱ＊または他のＤＳｘ＊メッセージを送信してマルチキャスト・ツリーを構築する必要がある。
【発明の概要】
【００１２】
本発明は、ＩＥＥＥ８０２．１６  ＷｉＭａｘに基づくマルチホップ・ネットワークなどの、モバイル無線マルチホップ中継通信ネットワークのためのマルチキャスト配信ツリーを構築および維持する２つの態様を開示する。特に、マルチキャスト配信ツリーを構築して送信元（ＭＲ‐ＢＳ）からマルチホップ中継通信ネットワークにおけるマルチキャスト・アプリケーションに参加する全てのＭＳにマルチキャスト・データ／コンテンツを効率的に配信するために、ＭＲ‐ＢＳおよびＲＳによって維持される信号メカニズムおよびデータ構造について記載する。ユニキャスト通信は、２つのエンティティ間の１対１の通信である。ブロードキャスト通信は、通信システムにおける１つのエンティティと他の全てのエンティティとの間の通信である。マルチキャスト通信は、通信システムにおけるあるエンティティと複数の他のエンティティとの間の１対多通信であり、複数の他のエンティティには、通信システムにおける他の全てのエンティティが含まれることがある。
【００１３】
本明細書には、モバイル・マルチホップ中継通信ネットワークにおいてマルチキャスト配信ツリーを構築して維持する信号メカニズムおよびデータ構造を含む２つの選択可能な態様が記載されている。マルチホップ中継ネットワークにおける中継ホップの数およびＲＳの数は比較的に少なく、集中制御メカニズムが採用されており、集中制御メカニズムにおいて、ＭＲ−ＢＳは、マルチキャスト接続ＩＤを割当て、マルチキャスト配信ツリーの構造を決定する。マルチキャスト配信ツリーの情報は、次に、マルチキャスト配信ツリーに含まれている全てのＲＳに通信される。マルチキャスト・ルート／パスは、ＭＲ‐ＢＳによってマルチキャスト配信ツリーに沿って構築され、ＳＤＵ／パケット／フレームのデータが、マルチキャスト接続ＩＤに基づいて、１つの送信元から複数の送信先に、マルチキャスト配信ツリーの各分岐に沿って転送される。マルチキャスト配信ツリーは、複数のマルチキャスト・ルート／パスから構成されていてもよい。
【００１４】
マルチホップ無線中継通信ネットワーク、特に、無線都市圏ネットワーク（ＭＡＮ：ｍｅｔｒｏｐｏｌｉｔａｎ  ａｒｅａ  ｎｅｔｗｏｒｋ）の構成においては、リアルタイム・アプリケーションのサポートが重要である。リアルタイム・アプリケーション、特に、ビデオ配信アプリケーションは、多大な帯域幅を必要とする。ユニキャストの規模は、このようなタイプのアプリケーションに合うものではない。無線ネットワークのブロードキャストの性質上、マルチキャストが、ユーザのグループに同時にリアルタイムにコンテンツを配信するのに効率的な方法である。出願人は、先願の特許出願において、マルチホップ中継無線ネットワークにおいてマルチキャスト・ツリーを構築するメカニズムを教示している。マルチキャスト・ツリーの構築および維持に、既存のＤＳｘ＊信号メカニズムが使用されていた。しかしながら、既存のＤＳｘ＊信号メカニズムは、ツリーおよび接続管理には効率的なものではない。例えば、パスとＣＩＤとのバインド更新ＴＬＶデータ構造（ここで、ＴＬＶは、ＤＳＡ‐ＲＥＱ＊信号における、タイプ、長さ、および値を表す）においては、１つ以上のＣＩＤのみを単一のＤＳＡ‐ＲＥＱ＊メッセージ内の１つのパスにバインドさせることしかできない。マルチキャストのアプリケーションでは、各マルチキャスト・アプリケーションがマルチキャストＣＩＤに割当てられ、マルチキャストＣＩＤは、マルチキャスト・ツリーに属する複数のパスにバインドされる必要がある場合がある。既存のＲＳＡ‐ＲＥＱ＊信号を使用して、単一のＭＣＩＤを複数のパスにバインドさせるために複数のＤＳＡ‐ＲＥＱ＊信号／メッセージを送信する必要があり、これにより、帯域幅のオーバーヘッドおよび遅延時間が増大することがある。本発明は、ＤＳｘ＊信号／メッセージの新しいセットのみでなく、このＤＳｘ＊信号メッセージの新しいセットを使用する方法および装置を教示する。メッセージの新しいセット、さらに、メッセージの新しいセットを使用する対応する方法および装置は、ＭＢＳ接続管理の効率性を向上させる。
【００１５】
マルチキャスト・サービスを求める複数のリクエストを受信するステップと、リクエストされたマルチキャスト・サービスを提供するために、マルチキャスト・ツリーにバインドするパスに関連付けられたパラメータを生成するステップと、パスをマルチキャスト・ツリーにバインドするステップと、を含む方法が記載されている。さらに、マルチキャスト・ツリー識別子を有する、マルチキャスト・サービスを求めるリクエストを受信するステップと、マルチキャスト・ツリー識別子のためのサービスレベルの品質を満たすパスにマルチキャスト・ツリーをバインドするステップと、第１のメッセージをマルチホップ中継基地局に送信するステップと、を含む方法が記載されている。複数のパスによってサービスを提供されるクライアント装置からの、マルチキャスト・サービスを削除することを求めるリクエストを受信するステップと、マルチキャスト・サービスを削除するために、マルチキャスト・サービスからパスのバインドを解除することに関連付けられたパラメータを生成するステップと、マルチキャスト・ツリーからパスのバインドを解除するステップと、を含む方法が記載されている。さらに、複数のパスによってサービスの提供を受けるクライアント装置からの、マルチキャスト・サービスを削除することを求めるリクエストを受信するステップと、中継局がリーフ・ノードとはならないパスのバインドを解除することに関連付けられたパラメータを生成するステップと、マルチキャスト・ツリーからパスのバインドを解除するステップと、を含む方法が記載されている。
【００１６】
本発明は、以下の詳細な説明を添付図面と併せて読むことによって最良に理解できるであろう。各図面は、以下に簡単に説明する図を含んでおり、各図における同様の参照符号は同様の構成要素を表している。
【図面の簡単な説明】
【００１７】
【図１】例示的なマルチホップ中継通信システムの概略図である。
【図２】複数のＭＢＳリクエストが同時に受信される際にＭＲ‐ＢＳで使用される本発明の例示的な実施の形態のフローチャートである。
【図３】ＲＳが本明細書に記載されている追加フィールドを有するＤＳＡ‐ＲＥＱ＊を受信した際にＲＳで使用される本発明の例示的な実施の形態のフローチャートである。
【図４】複数のＭＢＳリクエストが同時に受信される際にＭＲ‐ＢＳで使用される本発明の代替的な実施の形態のフローチャートである。
【図５】ＲＳが本明細書に記載されている追加フィールドを有するＤＳＡ‐ＲＥＱ＊を受信した際にＲＳで使用される本発明の代替的な実施の形態のフローチャートである。
【図６】複数のＭＢＳリクエストが同時に受信される際にＭＲ‐ＢＳで使用される本発明の例示的な実施の形態のフローチャートである。
【図７】ＲＳが本明細書に記載されている追加フィールドを有するＤＳＤ‐ＲＥＱ＊を受信した際にＲＳで使用される本発明の例示的な実施の形態のフローチャートである。
【図８】複数のＭＢＳリクエストが同時に受信される際にＭＲ‐ＢＳで使用される本発明の代替的な実施の形態のフローチャートである。
【図９】ＲＳが本明細書に記載されている追加フィールドを有するＤＳＤ‐ＲＥＱ＊を受信した際にＲＳで使用される本発明の代替的な実施の形態のフローチャートである。
【図１０】マルチキャスト配信ツリーに複数のパスを追加する際に図１に示されたＭＲ‐ＢＳと様々なノード／ＲＳとの間で交換されるメッセージのシーケンスを示す「ラダー」図である。
【図１１】マルチキャスト配信ツリーから複数のパスを削除する際に図１に示されたＭＲ‐ＢＳと様々なノード／ＲＳとの間で交換されるメッセージのシーケンスを示す「ラダー」図である。
【発明を実施するための形態】
【００１８】
図１は、例示的なマルチホップ中継通信システムの概略図である。この例において、ＭＳ１およびＭＳ２は、ＲＳ１およびＲＳ２を介してＭＲ‐ＢＳに接続されており、ＭＳ３およびＭＳ４は、ＲＳ１、ＲＳ３、およびＲＳ４を介してＭＲ‐ＢＳに接続されている。1つ以上のモバイル・ノード／局／装置がＭＢＳを必要とする場合には、マルチパス配信ツリーが構築され、各ＭＳノードが関連付けられているＲＳのマルチキャストＳＤＵ／パケット／フレームがマルチキャスト配信ツリーの各分岐に沿って転送される。このＲＳは、各ＭＳへのマルチキャスト配信ツリーの分岐に沿った最後のＲＳであることもあるし、最後のＲＳでないこともある。パスに沿って複数のＲＳが存在することがある。各ＲＳは、さらに、マルチキャストＳＤＵを自己に関連付けられている各ＭＳに転送する。本明細書において、ＤＳＡ＊、ＤＳＣ＊、ＤＳＤなどの拡張されたダイナミック・サービス（ＤＳｘ＊）を使用してＭＲ‐ＢＳおよびＲＳを接続するマルチキャスト配信ツリーを構築し、維持する方法について述べる。
【００１９】
本発明の無線マルチホップ中継通信システム／ネットワークのマルチキャスト・スキームにおいては、ＭＳがユニキャスト・サービスをリクエストすると、パスに沿った基地局と中継局／ノードとの間の信号メッセージを介して、ユニキャストＣＩＤが基地局によって割当てられ、パスにバインドされる。マルチキャストの場合には、このようなことはない。マルチキャストにおいては、マルチキャストＣＩＤ（ＭＣＩＤ）が複数のパスにバインドされることがある。複数のパスがマルチキャスト配信ツリーを形成する。さらに、２つ以上のＭＳが同一のマルチキャスト・サービスをリクエストすることがある。第１のＭＳがマルチキャスト・サービスをリクエストすると、ＭＲ‐ＢＳによってＭＣＩＤが割当てられ、パスがＭＣＩＤにバインドされる。しかしながら、他のＭＳが同一のマルチキャスト・サービスをリクエストする場合には、ＭＣＩＤが割当てられる必要はない。さらに、他のＭＳがこのマルチキャスト・サービスのために同一のパスを使用する場合には、ＭＣＩＤとパスのバインドを再び生じさせる必要はない。従って、マルチキャスト・サービスの構築とユニキャスト・サービスの構築は異なる。ユニキャスト・サービスを構築する方法は、マルチキャスト・サービスを構築するために使用することはできない。本発明は、マルチキャストに関するものであり、具体的には、マルチキャスト・サービスを構築し、解体し、さらにＭＣＩＤとマルチキャスト配信ツリー内のパスとをバインドする方法に関するものである。
【００２０】
図１において、ＲＳ１、ＲＳ２、ＲＳ３、およびＲＳ４がネットワークに入った後、ＭＲ‐ＢＳは、以下のパスを構築する。
【００２１】
Ｐ０＝｛ＭＲ‐ＢＳ｝、Ｐ１＝｛Ｐ０，ＲＳ１｝、Ｐ２＝｛Ｐ１，ＲＳ２｝、Ｐ３＝｛Ｐ１，ＲＳ３｝、Ｐ４＝｛Ｐ３，ＲＳ４｝
【００２２】
ＭＲ‐ＢＳまたはＭＳがマルチキャストおよびブロードキャスト・サービス（ＭＢＳ：ｍｕｌｔｉｃａｓｔ  ａｎｄ  ｂｒｏａｄｃａｓｔ  ｓｅｒｖｉｃｅ）を開始することを望むと、ＭＢＳの開始を望むエンティティは、ＭＢＳを望んでいることを示すＤＳＡ‐ＲＥＱメッセージを送信する。次に、このＭＢＳのためにマルチキャスト配信ツリーが構築される。ここで、マルチキャスト配信ツリーを構築するための本発明に係る方法について説明する。
【００２３】
本発明は、サービス・フロー効率および接続管理を向上させる。本発明は、単一のＤＳｘ＊メッセージ／コマンド／信号を使用して、ＣＩＤが複数のパスにバインドされ、かつ複数のパスから解除されるようにするために、既存のＤＳｘ＊信号／メッセージ／コマンドに追加されるべき追加的なフィールドを教示している。ＭＲ‐ＢＳは、ＣＩＤを複数のパスにバインドするために１つのメッセージを送信してもよい。メッセージは、ＣＩＤと、ＣＩＤに関連付けられたサービス・フロー・パラメータと、このＣＩＤがバインドするパスの数と、パスＩＤのリストとを含む。ＭＲ‐ＢＳは、ＣＩＤ−パス・バインディング・メッセージ（ＣＩＤ−Ｐａｔｈ  ｂｉｎｄｉｎｇ  ｍｅｓｓａｇｅ）を、パス／マルチキャスト・ツリー上の次の／下位のＲＳに送信する。ＲＳがＣＩＤ−パス・バインディング・メッセージを受信すると、ＲＳはこのメッセージを処理し、メッセージ内でリクエストされた処理を実行し、ＲＳがそのパスに属する場合には、ＣＩＤをパスにバインドする。次に、そのＲＳがパスの最後のホップでない場合には、そのＲＳはパス上の次のＲＳにメッセージを送信する。同一のメッセージ内のＣＩＤにバインドされるべきパスがＲＳ内において分岐する場合には、ＲＳは、ＣＩＤ−パス・バインディング・コマンドを相異なるメッセージに分け、それらのメッセージをユニキャストで適切な次のホップＲＳの各々に送信する。代替的な実施の形態においては、ＲＳは、メッセージをブロードキャストまたはマルチキャストで複数の次のホップＲＳに送信してもよい。ＲＳが、受信したブロードキャスト／マルチキャスト・ＣＩＤ−パス・バインディング・メッセージ内のいずれのパスにも属さない場合には、ＲＳは、メッセージを破棄する。この処理は、メッセージ／コマンド／信号がパス上の最後のＲＳに達するまで続けられる。
【００２４】
例示的な実施の形態においては、ＤＳｘ＊メッセージ／信号／コマンドに以下のメッセージ・フィールドが追加され、（複数のパスに対するＣＩＤの）バインドの更新及び解除を行う。これらのフィールドは、ＩＥＥＥ８０２．１６ｊドラフト規格におけるセクション１１．２１に規定された既存のＤＳｘ＊符号化に追加することができる。
【００２５】
ＣＩＤ−パス・バインドの更新ＴＬＶ
このフィールドは、テーブル１に列挙されているように、マルチキャストＣＩＤまたはＭＣＩＤ、このＣＩＤに関連付けられているサービス・パラメータ、及びＣＩＤにバインドされる必要のあるパスを特定するサブ属性を有する複合属性を含んでいる。
【表１】
2011518528.tif 000003
【００２６】
テーブル１  −  ＭＩＣＤ−パス・バインドの追加サブ属性
【表２】
2011518528.tif 000004
【００２７】
ＣＩＤ−パス・バインドの解除ＴＬＶ
このフィールドは、テーブル２において列挙されているような、マルチキャストＣＩＤ、解除されるべき特定のＣＩＤにバインドされているパスＩＤを特定するサブ属性を有する複合属性を含んでいる。
【表３】
2011518528.tif 000005
【００２８】
テーブル２  −  ＭＣＩＤ−パス・バインドの解除サブ属性
【表４】
2011518528.tif 000006
【００２９】
以下は、新しいメッセージ・フィールドの使用例である。引き続き図１を参照すると、ＭＳ１およびＭＳ２は、パスＰ２を介してＭＲ‐ＢＳに接続され、Ｍ３およびＭ４は、パスＰ４を介してＭＲ‐ＢＳに接続されている。ＭＢＳサービスが一度に１つのＭＳのためにのみに開始される場合、または、ＭＢＳサービスが複数のＭＳのために開始されるが、全て同じパスを使用してＭＲ‐ＢＳに接続している場合、マルチキャストＣＩＤを、ＭＳをＭＲ‐ＢＳに接続するパスにバインドするために既存のＤＳＡ‐ＲＥＱ＊メッセージを使用することができる。しかしながら、ＭＲ‐ＢＳが複数のＭＳのためのＭＢＳサービスを同時に開始し、これらのＭＳが相異なるパスを使用してＭＲ‐ＢＳに接続されている場合には、既存の信号／コマンド／メッセージが使用されているのであれば、複数のＤＳＡ‐ＲＥＱ＊メッセージが送信される必要がある。ＭＢＳがＭＳ１およびＭＳ３のために同時に開始される場合には、ＭＣＩＤがＭＢＳサービスに割当てられた後、既存のメッセージを用いたのでは、ＭＲ‐ＢＳは、２つのＤＳＡ‐ＲＥＱ＊メッセージを送信する必要がある。一方のＤＳＡ‐ＲＥＱ＊メッセージは、Ｐ２に沿って送出され、Ｐ２に沿った各ＲＳに対してＭＣＩＤをＰ２にバインドすることをリクエストし、他方のＤＳＡ‐ＲＥＱ＊メッセージは、Ｐ４に沿って送出され、Ｐ４に沿った各ＲＳに対してＭＣＩＤをＰ４にバインドすることをリクエストする。２つのメッセージは、ＭＲ‐ＢＳとＲＳ１との間で送信される。
【００３０】
ＭＳ１とＭＳ３のために同時にＭＢＳが開始される際、Ｐ２およびＰ４の両方がマルチキャスト・ツリーに追加されていない場合には、本発明のメッセージ／信号／コマンドを使用して、ＭＲ‐ＢＳは、パスＰ２およびＰ４の双方に沿った各ＲＳに対してＭＣＩＤをＰ２およびＰ４の双方にバインドするようにリクエストするＤＳＡ‐ＲＥＱ＊メッセージを送出する。ＲＳ１がＤＳＡ‐ＲＳＱ＊を受信すると、ＲＳ１は、ＭＣＩＤをＰ２とＰ４の双方にバインドさせる。さらに、ＲＳ１は、自己のルーティング・テーブルを調べ、パスＰ２については次のホップがＲＳ２であり、パスＰ４については次のホップがＲＳ３であることを認識する。次に、ＲＳ１は、ＤＳＡ‐ＲＥＱ＊メッセージをＲＳ２に送信し、ＭＣＩＤをＰ２にバインドすることをリクエストし、かつ、ＤＳＡ‐ＲＥＱ＊メッセージをＲＳ３に送信し、ＭＣＩＤをＰ４にバインドすることをリクエストする。さらに、ＲＳ３は、ＤＳＡ‐ＲＥＱメッセージをＲ４に転送する。このようにして、ＤＳＡ‐ＲＥＱ＊は、ＭＲ‐ＢＳとＲＳ１との間で一度のみ送信される。代替的な実施の形態においては、ＲＳ１は、次に、ブロードキャスト／マルチキャストで、ＤＳＡ‐ＲＥＱ＊メッセージを、ＤＳＡ‐ＲＥＱ＊メッセージのパス・リスト内の双方のパスＰ２およびＰ４を用いてＲＳ２およびＲＳ３に送信する。ＲＳ２がブロードキャスト／マルチキャストＤＳＡ‐ＲＥＱ＊メッセージを受信すると、ＲＳ２がパス２上にあり、パスＰ４上にないことを認識する。ＲＳ２は、ＭＣＩＤをＰ２にバインドする。ＲＳ３がブロードキャスト／マルチキャストＤＳＡ‐ＲＥＱ＊メッセージを受信すると、ＲＳ３がパス４上にあり、パス２上にないことを認識する。Ｒ３は、ＭＣＩＤをＰ４にバインドする。ＲＳ３はＰ４のリーフＲＳノードではないため、ＲＳ３は、ＤＳＡ‐ＲＥＱ＊メッセージからＰ２を削除し、ＤＳＡ‐ＲＥＱ＊メッセージ内のパスの数を変更し、ＤＳＡ‐ＲＥＱ＊メッセージをＲＳ４に転送する。
【００３１】
一方で、ＭＳ１およびＭＳ３の双方のためのＭＢＳサービスが終了し、ＭＢＳサービスをリクエストするＲＳ２およびＲＳ４に他のＭＳが関連付けられていない場合には、ＭＲ‐ＢＳは、ＤＳＤ‐ＲＥＱ＊メッセージをＲＳ１に送信する。ＤＳＤ‐ＲＥＱ＊メッセージにおいて、ＣＩＤはＭＢＳのＭＣＩＤであり、パスの数は２であり、パスのリストはＰ２およびＰ４である。メッセージを受信すると、ＲＳ１は、ＭＣＩＤとＰ２との間のバインド、さらに、ＭＣＩＤとＰ４との間のバインドを解除する。ＲＳ１は、自己のルーティング・テーブルを調べ、Ｐ２については次のホップがＲＳ２であり、Ｐ４については次のホップがＲＳ３であることを認識する。次に、ＲＳ１は、ＤＳＤ‐ＲＥＱ＊メッセージをＲＳ２に送信してＰ２とＭＣＩＤとの間のバインドを解除することをリクエストし、かつ、ＤＳＤ‐ＲＥＱ＊メッセージをＲＳ３に送信してＭＣＩＤとＰ４との間のバインドを解除することをリクエストする。さらに、Ｒ３は、ＤＳＤ‐ＲＥＱ＊をＲＳ４に転送する。代替的な実施の形態においては、ＲＳ１は、次に、ＤＳＤ‐ＲＥＱ＊メッセージをブロードキャスト／マルチキャストでＲＳ２およびＲＳ３に送信し、ＲＳ２に対し、ＭＣＩＤとＰ２とのバインドを解除するようにリクエストし、ＲＳ３に対し、ＭＣＩＤとＰ４とのバインドを解除するようにリクエストする。
【００３２】
他の実施の形態においては、ユニキャスト・サービス・フロー／接続のために複数のパスが構築してもよく、これらは、多様性、移動局のハンドオフ、保護、負荷バランスなどのために使用される。本発明の方法は、ユニキャストＣＩＤを複数のパスにバインドするために使用できる。
【００３３】
図２は、複数のＭＢＳリクエストが同時に受信される際にＭＲ‐ＢＳで使用される本発明の例示的な実施の形態のフローチャートである。本明細書において使用される「同時に」は、同一のサービスを求める複数のＭＢＳリクエストが互いに所定の短期間（所定の短期間は、設定パラメータである）の間に受信されることを意味する。ステップ２０５において、ＭＲ‐ＢＳは、待機ループ、または、待機状態にあり、サービス・リクエスト（ＤＳＡ‐ＲＥＱ）の受信を待機している。ステップ２１０において、同一のＭＢＳを求める複数のリクエストが同時に受信される。即ち、複数のサービス・リクエストが、近い時間に、又は、ほぼ同時に受信され、各サービス・リクエストに対するサービスが一緒に提供される。最初のＤＳＡ‐ＲＥＱメッセージを受信した後、ＭＲ‐ＢＳは、限定された時間の間、他のＤＳＡ‐ＲＥＱメッセージが到着するのを待つ。ステップ２１５において、テストが行われ、ＭＢＳを求めるリクエストを承諾できるかどうかが判定される。ステップ２２０において、ＭＢＳが承諾されない場合には、サービスを拒絶するために、ＤＳＡ‐ＲＳＰがリクエストを行った側に対して送信される。ＭＢＳを承諾できる場合には、ステップ２２５において、テストが行われ、ＭＣＩＤが既に割当てられているどうかが判定される。ＭＣＩＤがまだ割当てられていない場合には、ステップ２３０においてＭＣＩＤが割り当てられ、配信ツリーが構築される。ＭＣＩＤが既に割当てられている場合には、ステップ２３５において、テストが行われ、配信ツリー内に全てのパスが既に表されているかどうかが判定される。全てのパスが配信ツリー内に表されていない場合には、ステップ２４０において、配信ツリー内に既に存在する全てのパスについて、ツリー情報が更新される。（ステップ２３０とステップ２４０の双方の後の）ステップ２５０において、配信ツリーは、配信ツリーにまだ表されていないパスで更新され、これらのパスのタイプ、長さ、および値が構築され、符号化される。同一の次のホップを有するパスは、同一のタイプ、長さ、および値の情報で符号化される。ステップ２５５において、タイプ、長さ、および値の情報を用いて符号化された各ＤＳＡ‐ＲＥＱ＊メッセージは、次のホップにユニキャストされる。次に、ステップ２６０において、ＭＲ‐ＢＳは、全ての配信ツリー・パスのＲＳからのＤＳＡ‐ＲＳＰ＊を待機する。次に、ステップ２６５において、ＭＲ‐ＢＳは、（次のホップ（ＲＳ）を介して、）ＭＣＩＤにバインドされているパスに自己のＤＳＡ‐ＲＳＰを送信してＭＢＳを承認し、ステップ２７０において、（次のホップ（ＲＳ）を介して、）ＭＣＩＤにバインドできなかったパスにＤＳＡ‐ＲＳＰを送信してＭＢＳを拒絶する。次に、この方法は、ステップ２０５に進む。全てのパスが既に配信ツリー内に表されている場合には、ステップ２４５において、ツリー情報が更新される。次に、この方法は、ステップ２０５に進む。
【００３４】
図３は、本明細書に記載されている追加フィールドを用いてＲＳがＤＳＡ‐ＲＥＱ＊を受信した際にＲＳで使用される本発明の例示的な実施の形態のフローチャートである。ステップ３０５において、ＲＳは、待機ループ又は待機状態にあり、サービス・リクエストの受信を待機する。ステップ３１０において、ＭＣＩＤを有するサービス・リクエスト（ＤＳＡ‐ＲＥＱ＊）が受信される。ステップ３１５においてテストが行われ、ＭＣＩＤのサービス品質（ＱｏＳ：ｑｕａｌｉｔｙ  ｏｆ  ｓｅｒｖｉｃｅ）の条件を満たしていないパスがあるかどうかが判定される。１つ以上のパスがＭＣＩＤのＱｏＳの条件を満たしていない場合には、ステップ３２０において、ＱｏＳ条件を満たさないパスに沿って、ＤＳＡ‐ＲＳＰ＊がＭＲ‐ＢＳに返信される。ステップ３２５において、ＱｏＳ条件を満たすパスにＭＣＩＤがバインドされる。ステップ３３０において、ＲＳがリーフ・ノードであるパスについて、ＤＳＡ‐ＲＳＰ＊がＭＲ‐ＢＳに送信され、ＭＢＳを了解（ＯＫ）する。ステップ３３５において、テストが行われ、全てのパスが同一の次のホップを有するかどうかが判定される。全てのパスが同一の次のホップを有する場合には、メッセージが次のホップに転送され、この方法はステップ３０５に進む。全てのパスが同一の次のホップを有していない場合には、ステップ３４５において、異なる次のホップを有するパスが、ＤＳＡ‐ＲＥＱ＊メッセージの相異なるタイプ、長さ、および値のフィールドに符号化され、ステップ３５０において、相異なるＤＳＡ‐ＲＥＱ＊メッセージが各々の次のホップに送信される。次に、この方法はステップ３０５に進む。
【００３５】
図４は、複数のＭＢＳサービス・リクエストが同時に受信される際にＭＲ‐ＢＳで使用される本発明の代替的な実施の形態のフローチャートである。本明細書において使用される「同時に」は、同一のサービスを求める複数のＭＢＳリクエストが互いに所定の短期間（所定の短期間は、設定パラメータである）の間に受信されることを意味する。このフローチャートは、図２のフローチャートと非常に似ているため、図２と同一の番号が付けられた処理およびテストについては再び説明しない。図２に対し、新しい／異なる処理のみを説明する。ステップ４０５において、タイプ、長さ、および値の情報が構築され／符号化され、配信ツリー内に存在しないパスは、同じタイプ、長さ、および値の情報を用いて符号化される。ステップ４１０において、ＤＳＡ‐ＲＥＱ＊メッセージが配信ツリー内の全てのパスに沿う全ての次のホップ（ＲＳ）に対してブロードキャストされる。
【００３６】
図５は、本明細書に記載されている追加フィールドを有するＤＳＡ‐ＲＥＱ＊をＲＳが受信した際にＲＳで使用される本発明の代替的な実施の形態のフローチャートである。このフローチャートは、図３のフローチャートと非常に似ているため、図３と同一の番号が付けられた処理およびテストについては再び説明しない。図３に対し、新しい／異なる処理のみを説明する。ステップ５０５において、テストが行われ、ノード／ＲＳがＤＳＡ‐ＲＥＱ＊メッセージにおいて特定されたタイプ、長さ、および値にあるパスのいずれかに存在するかどうかが判定される。ノード／ＲＳがＤＳＡ‐ＲＥＱ＊メッセージにおいて特定されたタイプ、長さ、値におけるパスのいずれにも存在しない場合には、ステップ５１０でメッセージが破棄され、この方法はステップ３０５に進む。ノード／ＲＳがＤＳＡ‐ＲＥＱ＊メッセージにおいて特定されたタイプ、長さ、および値にあるパスのいずれかに存在する場合には、ステップ５１５において、ノード／ＲＳは、ノード／ＲＳが属していない、ＤＳＡ‐ＲＥＱ＊メッセージのタイプ、長さ、および値のフィールドにあるパスを無視する。ステップ５２０において、ノード／ＲＳは、全ての次のホップに対してＤＳＡ‐ＲＥＱ＊をブロードキャストする。
【００３７】
図６は、複数のＭＢＳリクエストが同時に受信される際にＭＲ‐ＢＳで使用される本発明の例示的な実施の形態のフローチャートである。本明細書において使用される「同時に」は、同一のサービスを求める複数のＭＢＳリクエストが互いに所定の短期間（所定の短期間は、設定パラメータである）の間に受信されることを意味する。ステップ６０５において、ＭＲ‐ＢＳは、待機ループ又は待機状態にあり、サービス・リクエスト（ＤＳＤ‐ＲＥＱ）の受信を待機している。最初のＤＳＤ‐ＲＥＱメッセージを受信した後、ＭＲ‐ＢＳは、他のＤＳＤ‐ＲＥＱメッセージが到着するのを限定された時間の間待機する。ステップ６１０において、ＭＲ‐ＢＳは、共通のＭＣＩＤを有する複数のパスからＤＳＤ‐ＲＥＱリクエストを受信する。ステップ６２０において、ツリー情報は、配信ツリー内で更新される。ステップ６２１において、テストが行われ、ＭＢＳを必要とするＭＳを依然として有するパスが存在するかどうかが判定される。ステップ６２５において、ＭＢＳを依然として必要とするＭＳを有していないパスについて、タイプ、長さ、および値のフィールドが構築され／符号化され、同一の次のホップを有するパスが、同一のタイプ、長さ、および値のフィールドを用いて符号化される。ＭＢＳを必要とするＭＳを依然として有するパスについて、ステップ６１５において、ＤＳＤ‐ＲＳＰが（ＲＳを介して）パスに沿ってクライアントに送信される。ＤＳＤ‐ＲＥＱ＊は、パスの次のホップにユニキャストされる。ステップ６３５において、ＭＲ‐ＢＳは、パスの全てからのＤＳＤ‐ＲＳＰ＊を待機する。ステップ６４０において、ＤＳＤ‐ＤＥＱメッセージ内のパスが削除される。ＤＳＤ‐ＲＳＰメッセージは、ここで削除されたパスを使用していたＭＲ‐ＢＳと関連付けられている各クライアント（ＭＳ）に送信される。ステップ６４５において、ＤＳＤ‐ＲＳＰは、これらのパスを使用してＭＲ‐ＢＳに関連付けられている各クライアント（ＭＳ）に送信される。
【００３８】
図７は、ＲＳが本明細書に記載されている追加フィールドを有するＤＳＤ‐ＲＥＱ＊を受信した際にＲＳで使用される本発明の例示的な実施の形態のフローチャートである。ステップ７０５において、ＲＳは、待機ループ又は待機状態にあり、サービス・リクエストの受信を待機している。ステップ７１０において、ＲＳは、共通のＭＣＩＤを有する複数のパスからＤＳＤ‐ＲＥＱ＊メッセージ／リクエストを受信する。ステップ７２０において、ＲＳは、メッセージのタイプ、長さ、および値のフィールドで特定されている全てのパスからＭＣＩＤのバインドを解除する。ステップ７２１において、テストが行われ、このＲＳノードがリーフ・ノードとなるパスが存在するかどうかを判定する。ステップ７１５において、このノードがリーフ・ノードとなるパスについて、ＲＳは、ＤＳＤ‐ＲＳＰ＊メッセージをＭＲ‐ＢＳに返信する。ステップ７２５において、このＲＳノードがリーフ・ノードとならないパスについて、タイプ、長さ、および値のフィールドが構築され／符号化され、同一の次のホップを有するパスが同一のタイプ、長さ、および値の情報を用いて符号化される。ステップ７３０において、ＤＳＤ‐ＲＥＱ＊メッセージがパスに沿う次のホップ（ＲＳ）にユニキャストされる。
【００３９】
図８は、複数のＭＢＳリクエストが同時に受信された際にＭＲ‐ＢＳで使用される本発明の代替的な実施の形態のフローチャートである。本明細書において使用される「同時に」は、同一のサービスを求める複数のＭＢＳリクエストが互いに所定の短期間（所定の短期間は、設定パラメータである）の間に受信されることを意味する。このフローチャートは、図６のフローチャートと非常に似ているため、図６と同一の番号が付けられた処理およびテストについては再び説明しない。図６に対し、新しい／異なる処理のみを説明する。ステップ８０５において、ＭＢＳサービスを必要とするＭＳを有していないパスについて、タイプ、長さ、および値のフィールドが構築され／符号化され、同一のタイプ、長さ、および値のフィールドを用いて全てのパスが符号化される。
【００４０】
図９は、ＲＳが本明細書に記載される追加フィールドを有するＤＳＤ‐ＲＥＱ＊を受信した際にＲＳで使用される本発明の代替的な実施の形態のフローチャートである。このフローチャートは、図７のフローチャートと非常に似ているため、図７と同一の番号が付けられた処理およびテストについては再び説明しない。図７に対し、新しい／異なる処理のみを説明する。ステップ９０５において、テストが行われ、メッセージの各フィールド内のタイプ、長さ、および値の情報を用いて符合化されたパスのいずれかにノード／ＲＳが属するかどうかが判定される。パスのいずれもそのように符号化されたものではない場合、ステップ９１０において、ＤＳＤ‐ＲＥＱ＊メッセージが破棄される。ステップ９１５において、ＭＣＩＤは、前記のタイプ、長さ、値の各フィールドで特定された、このノード／ＲＳが属するパスからバインドが解除される。ステップ９１６において、テストが行われ、このＲＳノードがリーフ・ノードとなるパスが存在するかどうかが判定される。ステップ９２０において、ＤＳＤ‐ＲＥＱ＊メッセージがパスに沿ってブロードキャストされる。
【００４１】
図１０は、マルチキャスト配信ツリーに複数のパスを追加する際に図１に示されたＭＲ‐ＢＳと様々なノード／ＲＳとの間で交換されるメッセージのシーケンスを示す「ラダー」図である。ＭＳ１は、ＤＳＡ‐ＲＥＱをＲＳ２に送信してＭＢＳをリクエストする。ＲＳ２は、ＭＳ１のリクエストをＲＳ１に転送し、ＲＳ１は次に、ＭＳ１のリクエストをＭＲ‐ＢＳに転送する。同時に、ＭＳ３は、ＤＳＡ‐ＲＥＱをＲＳ４に送信し、ＭＢＳをリクエストする。ＲＳ４は、ＭＳ３のリクエストをＲＳ３に転送し、ＲＳ３は次に、ＭＳ３のリクエストをＲＳ１に転送する。次に、ＲＳ１は、ＭＳ３のリクエストをＭＲ‐ＢＳに転送する。ＭＲ‐ＢＳは、図２および図４に記載されているように、ＭＳ１のリクエストおよびＭＳ２のリクエストの双方を処理し、ＤＳＡ‐ＲＥＱ＊メッセージをＲＳ１に送信する。ＲＳ１は、ＤＳＡ‐ＲＥＱ＊メッセージをＲＳ２およびＲＳ３の双方にブロードキャストまたはマルチキャストする。ＲＳ２は、ＲＳ１にＤＳＡ‐ＲＳＰ＊を送信し、ＲＳ３は、ＤＳＡ‐ＲＥＱ＊をＲＳ４に送信する。ＲＳ４は、ＤＳＡ‐ＲＳＰ＊をＲＳ３に送信することにより応答し、ＲＳ３は次に、ＲＳ４からＲＳ１にＤＳＡ‐ＲＳＰ＊を転送する。次に、ＲＳ１は、ＲＳ２とＲＳ３の双方に関するＤＳＡ‐ＲＳＰ＊をＭＲ‐ＢＳに転送する。ＭＲ‐ＢＳは、図２および図４に記載されているように、ＲＳ２の応答（ＤＳＡ‐ＲＳＰ＊）およびＲＳ４の応答（ＤＳＡ‐ＲＳＰ＊）の双方を処理し、ＤＳＡ‐ＲＳＰメッセージをＲＳ１に送信する。ＲＳ１は、ＤＳＡ‐ＲＳＰメッセージをＲＳ２およびＲＳ３の双方にマルチキャストまたはブロードキャストする。ＲＳ２は、ＤＳＡ‐ＲＳＰメッセージをＭＳ１に送信し、ＲＳ３は、ＤＳＡ‐ＲＳＰメッセージをＲＳ４に送信し、ＲＳ４は次に、ＤＳＡ‐ＲＳＰメッセージをＭＳ３に送信する。
【００４２】
図１１は、マルチキャスト配信ツリーから複数のパスを削除する際に図１に示されたＭＲ‐ＢＳと様々なノード／ＲＳとの間で交換されるメッセージのシーケンスを示す「ラダー」図である。ＭＳ１は、ＭＣＩＤを有するＤＳＤ‐ＲＥＱメッセージをＲＳ２に送信し、ＲＳ２は、このメッセージをＲＳ１に転送し、ＲＳ１は次に、メッセージをＭＲ‐ＢＳに転送する。同時に、ＭＳ３は、ＭＣＩＤを有するＤＳＤ‐ＲＥＱメッセージをＲＳ４に送信し、ＲＳ４は、このメッセージをＲＳ３に転送する。次に、ＲＳ３は、メッセージをＲＳ１に転送し、ＲＳ１は次に、メッセージをＭＲ‐ＢＳに転送する。ＭＲ‐ＢＳは、図６および図８に記載されているように、ＭＳ１のリクエスト及びＭＳ３のリクエストの双方を処理し、ＤＳＤ‐ＲＥＱ＊メッセージをＲＳ１に送信する。ＲＳ１は、ＤＳＤ‐ＲＥＱ＊メッセージをＲＳ２およびＲＳ３の双方にブロードキャストまたはマルチキャストする。ＲＳ２は、ＲＳ１にＤＳＤ‐ＲＳＰ＊を送信し、ＲＳ３は、ＤＳＤ‐ＲＥＱ＊をＲＳ４に送信する。ＲＳ４は、ＤＳＤ‐ＲＳＰ＊をＲＳ３に送信することによって応答し、ＲＳ３は次に、ＲＳ４からＲＳ１にＤＳＤ‐ＲＳＰ＊を転送する。次に、ＲＳ１は、ＲＳ２とＲＳ４の双方に関するＤＳＤ‐ＲＳＰ＊をＭＲ‐ＢＳに転送する。ＭＲ‐ＢＳは、図６および図８に記載されているように、ＲＳ２の応答（ＤＳＤ‐ＲＳＰ＊）およびＲＳ４の応答（ＤＳＤ‐ＲＳＰ＊）の双方を処理し、ＤＳＤ‐ＲＳＰメッセージをＲＳ１に送信する。ＲＳ１は、ＤＳＤ‐ＲＳＰメッセージをＲＳ２およびＲＳ３の双方にマルチキャストまたはブロードキャストする。ＲＳ２は、ＤＳＤ‐ＲＳＰメッセージをＭＳ１に送信し、ＲＳ３は、ＤＳＤ‐ＲＳＰメッセージをＲＳ４に送信し、ＲＳ４は次に、ＤＳＤ‐ＲＳＰメッセージをＭＳ３に送信する。
【００４３】
本発明は、ハードウエア（例えば、ＡＳＩＣチップ）、ソフトウエア、ファームウエア、特定目的用途のプロセッサ、または、これらを組み合わせた様々な形態において、サーバー、中間装置（無線アクセスポイントまたは無線ルータ）、または、モバイル装置内で実施可能であることが理解できるであろう。好ましくは、本発明は、ハードウエアおよびソフトウエアを組み合わせて実施することができる。さらに、好ましくは、ソフトウエアは、プログラム記憶装置に実施可能に格納されるアプリケーション・プログラムとして具体的な形態で実装される。アプリケーション・プログラムは、適切なアーキテクチャからなるマシンにアップロードされ、このマシンによって実行されるようにしてもよい。好ましくは、このマシンは、一つ以上の中央処理装置（ＣＰＵ）、ランダム・アクセス・メモリ（ＲＡＭ）、入出力（Ｉ／Ｏ）インターフェースを有するコンピュータ・プラットフォーム上で実装される。また、コンピュータ・プラットフォームは、オペレーティング・システムおよびマイクロインストラクション・コードを含む。本明細書中に記載された様々な処理および機能は、オペレーティング・システムを介して実行されるマイクロインストラクション・コードの一部を構成するものでもよいし、アプリケーション・プログラムの一部を構成するものであってもよいし、これらを組み合わせたものであってもよい。さらに、追加的なデータ記憶装置や印刷機等、様々な他の周辺機器をコンピュータ・プラットフォームに接続するようにしてもよい。
【００４４】
さらに、各図面に示すシステムの構成要素および方法ステップの幾つかは、好ましくは、ソフトウエアの形態によって実施されるため、システムの構成要素間の実際の接続（または処理ステップ）は、本願の原理がプログラムされる方法によって異なる場合があることが理解できるであろう。本明細書の開示する内容に基づいて、関連する技術における当業者であれば、本発明の実施形態または構成を理解し、さらに、類似する実施形態または構成を企図できるであろう。
【図１】
2011518528.tif 000007
【図２】
2011518528.tif 000008
【図３】
2011518528.tif 000009
【図４】
2011518528.tif 000010
【図５】
2011518528.tif 000011
【図６】
2011518528.tif 000012
【図７】
2011518528.tif 000013
【図８】
2011518528.tif 000014
【図９】
2011518528.tif 000015
【図１０】
2011518528.tif 000016
【図１１】
2011518528.tif 000017
【手続補正書】
【提出日】平成22年12月27日(2010.12.27)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
無線マルチホップ中継ネットワークにおける方法であって、
マルチキャスト・サービスを求める複数のリクエストを受信するステップと、
前記リクエストされたマルチキャスト・サービスを提供するために、マルチキャスト・ツリーにバインドするパスに関連付けられたパラメータを生成するステップであって、該パラメータはマルチキャスト接続識別子を含む、前記ステップと、
前記マルチキャスト接続識別子を用いて、前記パスを前記マルチキャスト・ツリーにバインドするステップと、
を含む、前記方法。
【請求項２】
前記バインドするステップは、前記生成されたパラメータを含む第１のメッセージを前記パスに沿って中継局にユニキャストすることおよびマルチキャストすることのいずれか一方をさらに含む、請求項１に記載の方法。
【請求項３】
前記パラメータは、前記マルチキャスト接続識別子に関するパラメータと、前記マルチキャスト接続識別子がバインドされるパスの数と、前記マルチキャスト接続識別子がバインドされるパスのリストとをさらに含む、請求項２に記載の方法。
【請求項４】
マルチキャスト・サービスを求める前記リクエストを承諾可能であるかどうかを判定するステップと、
マルチキャスト・サービスを求める前記リクエストを承諾可能である場合に、マルチキャスト・ツリー識別子が既に割当てられているかどうかを判定するステップと、
前記マルチキャスト・ツリー識別子が既に割当てられている場合に、全てのパスがマルチキャスト・ツリー内に既に存在するかどうかを判定するステップと、
前記マルチキャスト・ツリー内に既に存在する全てのパスに関するツリー情報を更新するステップと、
前記マルチキャスト・ツリー内のパスに関するツリー情報を更新するステップと、
前記中継局から第２のメッセージを受信するステップと、をさらに含む、請求項３に記載の方法。
【請求項５】
前記中継局に第３のメッセージを送信し、マルチキャスト・サービスを求める前記リクエストを承諾する前記マルチキャスト接続識別子にバインドされている全てのパスに沿って転送するステップをさらに含む、請求項４に記載の方法。
【請求項６】
前記中継局に第３のメッセージを送信し、マルチキャスト・サービスを求める前記リクエストを拒絶する前記マルチキャスト接続識別子にバインドされていない全てのパスに沿って転送するステップをさらに含む、請求項４に記載の方法。
【請求項７】
前記マルチキャスト・サービスを承諾できない場合に、マルチキャスト・サービスを求める前記リクエストを拒絶するステップをさらに含む、請求項４に記載の方法。
【請求項８】
前記マルチキャスト・ツリー識別子が未だ割当てられていない場合に、前記マルチキャスト・ツリー識別子を割当てるステップと、
前記マルチキャスト・ツリーを構築するステップと、をさらに含む、請求項４に記載の方法。
【請求項９】
前記方法はマルチキャスト中継基地局において実施される、請求項１に記載の方法。
【請求項１０】
マルチキャスト・ツリー識別子を、マルチキャスト・サービスを求める前記リクエストと共に受信するステップと、
前記マルチキャスト・ツリー識別子のためのサービスレベルの品質を満たすパスに前記マルチキャスト・ツリー識別子をバインドするステップと、
最初のメッセージをマルチホップ中継基地局に送信するステップと、
を含む、請求項１に記載の方法。
【請求項１１】
前記中継局がリーフ・ノードとなるパスに前記第１のメッセージが送信される、請求項１０に記載の方法。
【請求項１２】
前記マルチキャスト・ツリー識別子のためのサービスレベルの品質を満たせないパスが存在するかどうかを判定するステップと、
前記マルチキャスト・ツリー識別子のためのサービスレベルの品質を満たせないパスに沿って、前記第１のメッセージを前記マルチキャスト中継基地局に送信するステップと、を含む、請求項１０に記載の方法。
【請求項１３】
全てのパスが同一の次の中継局を有するかどうかを判定するステップと、
全てのパスが前記同一の次の中継局を有する場合に、前記第１のメッセージを前記同一の次の中継局に転送するステップと、
マルチキャスト接続識別子と、前記マルチキャスト接続識別子に関するパラメータと、前記マルチキャスト接続識別子がバインドされるパスの数と、前記マルチキャスト接続識別子がバインドされるパスのリストとを含む情報を、相異なる中継局を有するパスに関する相異なるデータ構造に符号化するステップと、
相異なる次の中継局を有するパスに沿って、相異なる第２のメッセージを送信するステップと、をさらに含む、請求項１２に記載の方法。
【請求項１４】
前記中継局がリーフ・ノードとならないパスが存在する場合に、第２のメッセージを次の中継局にマルチキャストするステップをさらに含む、請求項１２に記載の方法。
【請求項１５】
マルチキャスト・サービスを求める前記リクエストにおいて特定されているパスのいずれかに前記中継局が存在するかどうかを判定するステップと、
マルチキャスト・サービスを求める前記リクエストにおいて特定されているパスのいずれにも前記中継局が存在しない場合に、マルチキャスト・サービスを求める前記リクエストを破棄するステップと、
マルチキャスト・サービスを求める前記リクエストにおいて特定されている前記パスのいずれにも前記中継局が存在しないすべてのパスを無視するステップと、をさらに含む、請求項１４に記載の方法。
【請求項１６】
前記方法は中継局によって実施される、請求項１０に記載の方法。
【請求項１７】
無線マルチホップ中継ネットワークにおける方法であって、
複数のパスによってサービスを提供されるクライアント装置からの、マルチキャスト・サービスを削除することを求めるリクエストを受信するステップと、
前記マルチキャスト・サービスを削除するために、前記マルチキャスト・サービスからパスのバインドを解除することに関連付けられたパラメータを生成するステップであって、該パラメータはマルチキャスト接続識別子を含む、前記ステップと、
前記マルチキャスト接続識別子を用いて、前記マルチキャスト・ツリーから前記パスのバインドを解除するステップと、
を含む、前記方法。
【請求項１８】
前記バインドを解除するステップは、前記生成されたパラメータを含む第１のメッセージを前記パスに沿って中継局にユニキャストすることおよびマルチキャストすることのいずれか一方をさらに含む、請求項１７に記載の方法。
【請求項１９】
前記パラメータは、前記マルチキャスト接続識別子に関するパラメータと、前記マルチキャスト接続識別子とのバインドが解除されるパスの数と、前記マルチキャスト接続識別子とのバインドが解除されるパスのリストとをさらに含む、請求項１８に記載の方法。
【請求項２０】
マルチキャスト・ツリー内のパスに関するツリー情報を更新するステップと、
前記マルチキャスト・サービスを必要とするクライアント装置が依然として存在するパスが存在するかどうかを判定するステップと、
第２のメッセージを前記中継局に送信し、前記マルチキャスト・サービスを依然として必要とするパスに沿って転送するステップと、をさらに含む、請求項１９に記載の方法。
【請求項２１】
前記中継局から前記第２のメッセージを受信するステップと、
前記マルチキャスト・サービスを依然として必要とするクライアント装置が存在しないパスを前記マルチキャスト・ツリーから削除するステップと、
前記削除されたパスを使用していたクライアント装置に第３のメッセージを送信するステップと、をさらに含む、請求項２０に記載の方法。
【請求項２２】
前記方法はマルチキャスト中継基地局によって実施される、請求項１７に記載の方法。
【請求項２３】
前記中継局がリーフ・ノードとはならないパスのバインドを解除することに関連付けられたパラメータを生成するステップをさらに含む、請求項１７に記載の方法。
【請求項２４】
前記バインドを解除するステップは、前記生成されたパラメータを含む第１のメッセージを前記パスに沿って中継局にユニキャストすることおよびマルチキャストすることのいずれか一方をさらに含む、請求項２３に記載の方法。
【請求項２５】
前記パラメータは、マルチキャスト接続識別子と、前記マルチキャスト接続識別子に関するパラメータと、前記マルチキャスト接続識別子とのバインドが解除されるパスの数と、前記マルチキャスト接続識別子とのバインドが解除されるパスのリストとを含み、前記マルチキャスト・サービスを削除することを求める前記リクエストはマルチキャスト・ツリー識別子を含む、請求項２４に記載の方法。
【請求項２６】
マルチキャスト・サービスを削除することを求める前記リクエストにおいて特定された全てのパスから前記マルチキャスト・ツリー識別子のバインドを解除するステップと、
前記中継局がリーフ・ノードとなるパスが存在するかどうかを判定するステップと、
前記中継局がリーフ・ノードとなるマルチキャスト中継基地局に第２のメッセージを送信するステップと、をさらに含む、請求項２５に記載の方法。
【請求項２７】
前記方法は前記中継局によって実施される、請求項２３に記載の方法。
【請求項２８】
前記中継局が前記マルチキャスト・サービスを削除することを求める前記リクエストにおいて特定されたパスのいずれかに属するかどうかを判定するステップと、
マルチキャスト・サービスを削除することを求める前記リクエストにおいて特定された全てのパスから前記マルチキャスト・ツリー識別子のバインドを解除するステップと、
前記中継局がリーフ・ノードとなるパスが存在するかどうかを判定するステップと、
前記中継局がリーフ・ノードとなるマルチキャスト中継基地局に第２のメッセージを送信するステップと、をさらに含む、請求項２５に記載の方法。
【国際調査報告】
2011518528.tif 000018
2011518528.tif 000019
2011518528.tif 000020