(57)【要約】本発明は、コアネットワークまたは移動通信システムの無線アクセスネットワークのネットワークエンティティにおいて多重化パケットストリームをフィルタリングする方法に関する。多重化パケットストリームは、マルチキャストサービスまたはブロードキャストサービスを提供し、ネットワークエンティティを介して、サービスセンターから移動端末に配信される。さらに、ネットワークエンティティは、サービス品質管理機能を提供するサービスマネージャを含む。本発明はさらに、ネットワークエンティティを含む通信システムだけでなく、フィルタリング能力を備えるネットワークエンティティにも関する。多くのユーザに対してスケーラブルな適応性型のマルチメディアブロードキャスト／マルチキャストサービスＱｏＳアーキテクチャを提供するために、本発明は、単一のベアラサービスを介した多重化パケットストリーム形式のサービスを提供すること、およびサービスマネージャから取得されたダウンリンクサービス品質制約に基づいた多重化ストリームのフィルタリングを可能にするフィルタリング能力をサービスの分散ツリー内のノードに備えさせることを提案する。
2008503945.tif 000002
【特許請求の範囲】
【請求項１】
コアネットワークまたは移動通信システムの無線アクセスネットワークの、サービス品質管理機能を提供するサービスマネージャを有するネットワークエンティティにおいて、マルチキャストサービスまたはブロードキャストサービスを提供し、かつ前記ネットワークエンティティを介してサービスセンターから移動端末に配信される多重化パケットストリームをフィルタリングする方法であって、
単一ベアラサービスを介して、ブロードキャストサービスまたはマルチキャストサービスを、それぞれがサービス品質属性に関連する複数のパケットストリームを含む多重化パケットストリームの形式で受信するステップと、
前記複数のパケットストリーム、または前記多重化パケットストリームの組合せの、それぞれのサービス品質属性を示す情報を受信するステップと、
前記サービス品質管理機能から、下流側データ伝送のために利用可能なサービス品質を示すサービス品質制約を取得するステップと、
取得した前記サービス品質制約内で、受信した前記多重化パケットストリームのサービス品質の属性に基づいて、前記複数のパケットストリームから、前記移動端末に送信可能なパケットストリームを選択するステップと、
前記移動端末に、前記マルチキャストサービスまたは前記ブロードキャストサービスを提供する前記多重化パケットストリームの選択した前記パケットストリームを転送するステップと、を実行する方法。
【請求項２】
サービス品質属性を示す受信情報は、前記複数のパケットストリーム、および前記多重化パケットストリームの組合せの、それぞれのサービス品質属性を示す、請求項１記載の方法。
【請求項３】
前記ネットワークエンティティは、サービス品質管理機能を有する無線アクセスネットワークのエンティティ、またはサービス品質管理機能を有するコアネットワークのエンティティである、請求項１または請求項２記載の方法。
【請求項４】
前記多重化データストリームから前記個々のパケットストリームを逆多重化するためのトランスポート識別子を示す情報を受信するステップをさらに含む、請求項１乃至請求項３のいずれかに記載の方法。
【請求項５】
前記トランスポート識別子に基づいて、受信した前記多重化データストリームの個々のパケットストリームを認識するステップをさらに含む、請求項４記載の方法。
【請求項６】
前記トランスポート識別子は、前記パケットストリームのＵＤＰパケットに含まれるＵＤＰポート番号、前記パケットストリームを配信するＩＰパケットに含まれるＩＰヘッダのサービス領域の形式において設定される値、前記パケットストリームを配信するＩＰパケットに含まれる前記ＩＰヘッダにおいて設定されるＤｉｆｆＳｅｒｖ  ＣｏｄｅＰｏｉｎｔ値、または前記多重化パケットストリームの前記パケットストリームを伝送する前記データパケットの前記ヘッダに割り当てられるＭＰＬＳラベルである、請求項５記載の方法。
【請求項７】
選択した前記パケットストリームを転送するステップは、選択した前記パケットストリームを新しい多重化パケットストリームに多重化するステップを含む、請求項４乃至請求項６のいずれかに記載の方法。
【請求項８】
前記多重化パケットストリームのパケットストリームと、前記多重化パケットストリームと転送のために選択されるパケットストリームの組合せとに必要なサービス品質属性を示す情報を含む、マルチキャストサービスまたはブロードキャストサービスに関連するコンテキストを形成するステップをさらに含む、請求項１乃至請求項７のいずれかに記載の方法。
【請求項９】
下流側に転送するための前記パケットストリームの選択は、前記コンテキストに基づく、請求項８記載の方法。
【請求項１０】
前記ネットワークエンティティの前記サービス品質管理機能を使用することにより、前記ネットワークエンティティのインターフェースで利用可能な下流側資源を監視するステップと、
監視した前記利用可能な下流側資源により明示される制約内で、前記複数のパケットストリームから、前記移動端末に提供することができるパケットストリームを選択し、前記監視結果における変化が観察される場合に、前記選択に基づいて前記コンテキスト内の情報を更新することにより、前記コンテキストを更新するステップと、
前記ネットワークエンティティのコンテキストが更新される場合に、前記ネットワークエンティティのコンテキストを示す情報を、上流側のネットワークエンティティの少なくとも１つに送信するステップとをさらに含む、請求項８または請求項９記載の方法。
【請求項１１】
提供可能なそれぞれの下流側のサービス品質を示す下流側ネットワークエンティティから、少なくとも１つのコンテキストを示す情報を受信するステップと、前記少なくとも１つのコンテキストを示す前記受信情報に基づいて、前記ネットワークエンティティのコンテキストを更新するステップとをさらに含む、請求項８乃至請求項１０のいずれかに記載の方法。
【請求項１２】
前記マルチキャストサービスまたはブロードキャストサービスを伝送する前記多重化パケットストリームのために提供されるサービス品質レベルをアップグレードまたはダウングレードする要求を、下流側エンティティから受信するステップと、
前記サービス品質を提供できるか否かを示すメッセージを、要求元である前記下流側ネットワークエンティティに送信するステップとをさらに含む、請求項１乃至請求項１１のいずれかに記載の方法。
【請求項１３】
前記メッセージが要求される前記サービス品質を提供できないことを示す場合に、前記サービス品質管理機能から取得されるサービス品質制約が、要求される前記サービス品質を提供することができることを示すとすぐに、要求される前記サービス品質を提供することができることを示すメッセージを、要求元である前記下流側ネットワークエンティティに送信するステップをさらに含む、請求項１２記載の方法。
【請求項１４】
要求元である前記下流側ネットワークエンティティは、要求される前記サービス品質を提供することができないことを示すメッセージに対する要求に対応するサービス品質をアップグレードまたはダウングレードする要求を送信することが許可されない、請求項１３記載の方法。
【請求項１５】
前記多重化パケットストリームを形成する前記パケットストリームが、階層的パケットストリームか、代替的パケットストリームか、または捕捉的パケットストリームかを示すストリームタイプに関する情報を受信するステップと、
前記ストリームタイプ情報を前記コンテキストに格納するステップとをさらに含む、請求項８記載の方法。
【請求項１６】
各パケットストリームが前記ネットワークエンティティにより転送されるか否かを示す前記多重化パケットストリームのそれぞれに関するステータス情報を保持するステップをさらに含む、請求項８、請求項９または請求項１３記載の方法。
【請求項１７】
前記多重化パケットストリームを形成する前記複数のパケットストリームは、個々の優先順位を有する階層的パケットストリームであり、
前記多重化パケットストリームは、基本的なサービス品質を提供する基本パケットストリーム、および前記基本パケットストリームにより提供されるサービス品質を拡張する少なくとも１つの拡張パケットストリームを含む、請求項８、請求項９、請求項１５または請求項１６記載の方法。
【請求項１８】
前記多重化パケットストリームを形成する前記複数のパケットストリームのパケットストリームは、同じ優先順位と個々のサービス品質属性を有する代替的パケットストリームである、請求項８、請求項９、請求項１５または請求項１６記載の方法。
【請求項１９】
デフォルトのパケットストリーム、または前記複数のパケットストリームのデフォルトのパケットストリームの組合せに関する情報を受信し、この情報を前記コンテキストに格納するステップをさらに含む、請求項１８記載の方法。
【請求項２０】
前記複数のパケットストリームの代替的組合せに関する情報を受信し、この情報を前記コンテキストに格納するステップをさらに含む、請求項１８または請求項１９記載の方法。
【請求項２１】
前記多重化パケットストリームを形成する前記複数のパケットストリームのパケットストリームは、同じ優先順位を有し１つのメディアタイプに属する捕捉的パケットストリームである、請求項８、請求項９、請求項１５または請求項１６記載の方法。
【請求項２２】
前記サービス品質管理機能は前記ネットワークエンティティのインターフェース毎にサービス品質制約を提供し、転送のためのパケットストリームの個々の選択はインターフェース毎に行なわれる、請求項１乃至請求項２１のいずれかに記載の方法。
【請求項２３】
選択される少なくとも１つのストリームを、前記サービス品質管理機能から取得される前記サービス品質制約内で伝送可能なストリームに変換するステップをさらに含む、請求項１乃至請求項２２のいずれかに記載の方法。
【請求項２４】
前記変換は、前記ストリームのビットレートを変換すること、コーデックタイプを変換すること、空間的分解能または時間的分解能を変換すること、複数層ストリームから単一層ストリームに変換すること、一定ビットレートストリームから可変ビットレートストリームに変換すること、および可変ビットストリームから一定ビットストリームに変換することのうち少なくとも１つを含む、請求項２３記載の方法。
【請求項２５】
多重化される前記パケットストリームに必要なサービス品質属性に関する受信情報は、各パケットストリームの最大帯域幅および保証帯域幅、サービスデータユニットの配送順番、サービスデータユニットの最大サイズ、サービスデータユニットのフォーマット、サービスデータユニットの誤り率、残留ビットの誤り率、誤ったサービスデータユニットを配信すべきか廃棄すべきかの指示、転送遅延パラメータ、ベアラサービスのトラフィック処理優先順位、および無線ベアラサービスの割り当て／保持優先順位のうちの少なくとも１つを示す、請求項１乃至請求項２３のいずれかに記載の方法。
【請求項２６】
コアネットワークまたは移動通信システムの無線アクセスネットワークの一部であり、マルチキャストサービスまたはブロードキャストサービスを提供し、ネットワークエンティティを介してサービスセンターから移動端末に配信される多重化パケットストリームをフィルタリングするためのネットワークエンティティであって、
サービス品質機能を提供するサービスマネージャと、
単一ベアラサービスを介して、ブロードキャストサービスまたはマルチキャストサービスを、それぞれがサービス品質属性に関連する複数のパケットストリームを含む多重化パケットストリームの形式で受信するための受信手段と、
前記複数のパケットストリーム、または前記多重化パケットストリームの組合せの、それぞれのサービス品質属性を示す情報を受信するように適合される受信手段と、
前記サービスマネージャの前記サービス品質機能から、下流側データ伝送のために利用可能なサービス品質を示すサービス品質制約を取得するための通信手段と、
取得した前記サービス品質制約内で、受信した前記多重化パケットストリームのサービス品質の属性に基づいて、前記パケットストリームから、前記移動端末に提供することができるパケットストリームを選択するように適合される処理手段と、
前記移動端末に、前記マルチキャストサービスまたは前記ブロードキャストサービスを提供する前記多重化パケットストリームの選択した前記パケットストリームを転送する送信手段とを有する、ネットワークエンティティ。
【請求項２７】
請求項２乃至請求項２５のいずれかに記載の方法のステップを実行するように適合される手段をさらに含む、請求項２６記載のネットワークエンティティ。
【請求項２８】
サービスセンターと、マルチキャストサービスまたはブロードキャストサービスを多重化データストリームの形式で受信する少なくとも１つの移動端末と、請求項２６または２７記載の少なくとも１つのネットワークエンティティとを含む移動通信システム。
【請求項２９】
プロセッサにより実行されると、前記プロセッサに、コアネットワークまたは移動通信システムの無線アクセスネットワークのネットワークエンティティにおいて、マルチキャストサービスまたはブロードキャストサービスを提供し、かつ前記ネットワークエンティティを介してサービスセンターから移動端末に配信される多重化パケットストリームをフィルタリングさせる命令を格納するためのコンピュータ読み取り可能な媒体であって、
単一ベアラサービスを介して、ブロードキャストサービスまたはマルチキャストサービスを、それぞれがサービス品質属性に関連する複数のパケットストリームを含む多重化パケットストリームの形式で受信し、
前記複数のパケットストリーム、または前記多重化パケットストリームの組合せの、それぞれのサービス品質属性を示す情報を受信し、
前記サービス品質管理機能から、下流側データ伝送のために利用可能なサービス品質を示すサービス品質制約を取得し、
取得した前記サービス品質制約内で、受信した前記多重化パケットストリームのサービス品質の属性に基づいて、前記複数のパケットストリームから、前記移動端末に提供することができるパケットストリームを選択し、
前記移動端末に、前記マルチキャストサービスまたは前記ブロードキャストサービスを提供する前記多重化パケットストリームの選択した前記パケットストリームを転送することによりサービス品質管理機能を提供するサービスマネージャを有する、
コンピュータ読み取り可能な媒体。
【請求項３０】
プロセッサ上で実行されると、前記プロセッサに、請求項２乃至請求項２５のいずれかに記載の方法のステップを実効させる命令をさらに格納する、請求項２９記載のコンピュータ読み取り可能な媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、コアネットワークまたは移動通信システムの無線アクセスネットワークのネットワークエンティティにおいて、多重化パケットストリームをフィルタリングする方法に関する。多重化パケットストリームはマルチキャストサービスまたはブロードキャストサービスを提供し、ネットワークエンティティを介して、サービスセンターから移動端末に配送される。さらに、ネットワークエンティティは、サービス品質管理機能を提供するサービスマネージャを含む。本発明はさらに、フィルタリング能力を備えたネットワークエンティティと、このネットワークエンティティを含む通信システムとに関する。
【背景技術】
【０００２】
符号化技術における最近の進歩により、ブロードキャスト／マルチキャストサービスのデータを、例えば代替的（サイマルキャスト）または選択的（階層化マルチキャスト）に、複数のストリーム上に伝送することが可能となった。このような手法は、マルチキャスト通信において、きめの粗い（ｃｏａｒｓｅ−ｇｒａｉｎｅｄ）品質の適応を可能にするインターネット社会の注目を集め、複数の研究がこの研究に基礎を置いている。例えば、ＤｉｆｆＳｅｒｖｅ（Ｄｉｆｆｅｒｅｎｔｉａｔｅｄ  Ｓｅｒｖｉｃｅｓ：非特許文献１、http://www.ietf.orgで入手可能な非特許文献２参照）、ＲＳＶＰ（非特許文献３参照）またはＮＳＩＳ（非特許文献４参照）である。しかし、例えば３ＧＰＰネットワークのような３Ｇ通信ネットワークのアーキテクチャはインターネットのものとは異なるので、異なる解決策または追加的な解決策を必要とする。
【０００３】
帯域幅集約型（ｂａｎｄｗｉｄｔｈ−ｉｎｔｅｎｓｉｖｅ）マルチメディアアプリケーションの普及が異種の（ｈｅｔｅｒｏｇｅｎｅｏｕｓ）ユーザグループに広がることにより、インターネットにおけるマルチキャスト速度および輻輳制御の領域における集中的な研究がなされるようになった。ＭｃＣａｎｎｅらの先駆的研究（非特許文献５参照）以来、マルチレートマルチキャストは、ストリーミングシナリオにおける速度整合のために極めて有望な手法と考えられている。累積層型データ構成（階層符号化）またはストリーム複製（単一ストリームと代替ストリーム）に基づき、相異なる品質水準にマッピングする複数のマルチキャストグループを使用することにより同一のコンテンツを送信するための技術が提案された。さらに、両手法の組合せ、例えば、様々なデータ速度または様々な損失率に対して強固な標準符号化体系により符号化された単一の音声ストリームおよび複数の代替的な映像ストリームのセッションもまた可能である。
【０００４】
一般的には、インターネットマルチキャストモデルは、様々なＱｏＳパラメータを有するデータをマルチキャスト配信ツリーのサブセットへ配布するための基本的なメカニズムを提供する。インターネットグループ管理プロトコル（ＩＧＭＰ：http://www.ietf.orgで入手可能な非特許文献６参照）を使用してマルチキャストルータと通信するホストは、原理的には、マルチキャストグループに加わり、マルチキャストグループから離れることにより、サブツリーにおいてＱｏＳに能動的に適合することができる。
【０００５】
しかし、すべての通信ネットワーク、例えば移動体通信ネットワークがインターネットのエンドツーエンドのパラダイム（ｅｎｄ−ｔｏ−ｅｎｄ  ｐａｒａｄｉｇｍ）に従うとは限らない。この点に関し、エンドツーエンドの原理に従うことは、末端ホストが潜在的なネットワークシグナリング、すなわちパケットのドロップや遅延変動のみに基づいてネットワーク状態に適応する責任を負うことを意味する。
【０００６】
一方、移動体通信ネットワークは、通常、ＱｏＳ提供のためのネットワーク中枢的な（ｎｅｔｗｏｒｋ−ｃｅｎｔｒｉｃ）手法に従い、結果的に、異なるブロードキャスト／マルチキャストサービスモデルとなる。加入者ユーザは、個別ネットワークノードへのＩＧＭＰまたは同様なシグナリングにより、マルチキャストセッションについての関心を示すことができる。しかし、サービスデータが提供されるデータ分散ツリーは自律的に構築され、必要な場合に、例えばハンドオーバに応答してネットワークにより変更される。無線ネットワーク制御装置は利用可能な資源の知識を持つ（例えば、リソース制御機能を提供する）ので、この手法は特に有利であり、多かれ少なかれエンドユーザにシームレスサービスを提供することができる。
【０００７】
インターネットにおいて異種の通信サービスを提供するためのネットワーク中枢的な手法もまた開発された。非特許文献７、非特許文献８に提案されるように、ネットワーク内の拡張機能を配置するよく知られた方法は、トランスポートレベルもしくはアプリケーションレベルのゲートウエイを設定すること、または能動的なネットワークノードを導入することである。
【０００８】
前者の手法は、コード変換操作のためにかなりのオーバーヘッドを課すが、後者の手法は、ネットワーク特有の機能およびメカニズムを提供するそれぞれの場合において適応されなければならないフレームワークを提供する。
【０００９】
ＭＢＭＳアーキテクチャにおける異種のＱｏＳの最初の概念は、http://www.3gpp.orgで入手可能な非特許文献９のオプションＧとして提案された。それぞれが単一のＲＴＰインスタンスにマッピングされる複数のストリーム（選択的または代替的）を含むことができるＭＢＭＳベアラサービスが定義される。各ストリームは、ＭＢＭＳサービス持続期間中保持されるＧＧＳＮ（ゲートウエイＧＰＲＳサポートノード）とＲＮＣ（無線ネットワーク制御装置）との間の固有のトンネルを通じて伝送される。
【００１０】
したがって、ＲＮＣが、セッション中にストリームを変更／追加するだけでなく、セッション開始時にＭＢＭＳサービスのストリームを選択することは原理的に可能である。しかし、この機能を可能にするためには、適切なメカニズムを無線アクセスネットワーク（ＲＡＮ）において実現しなければならない。必要な前提条件は、ストリームの状態と関係の伝達と管理であり、これにより、ＲＡＮノードは、セルまたは下流側ノードの現在の状態に従って適切なストリーム（セット）を選択できるようになる。
【００１１】
３ＧＰＰマルチメディアブロードキャスト／マルチキャストサービス（ＭＢＭＳ）アーキテクチャは今日、極めて単純なＱｏＳモデルを支援するのみである。それは、基本的には、ＭＢＭＳ配送ツリーのすべての枝が同じＱｏＳで設定されるか、あるいは全体のサービスが取り消されるかのいずれかである非スケーラブルな適応性の無いサービスを提供する。ネットワークノード間でのＱｏＳ値のネゴシエーションは存在しなく、このことは、ＱｏＳ要件がネットワークノードにより満たされない場合、一部の枝が確立され得ないことを意味する。これは、配送ツリーの新しい枝を生成し／取り壊す必要がある場合におけるセッションの初めとセッション中の双方、例えば各ハンドオーバ時に当てはまる。
【００１２】
一方、移動端末は、具備する能力、すなわち処理電力や表示サイズ等については極めて異種である。現在のＭＢＭＳアーキテクチャは、この異種性に対処できず、あるいは、すべての端末（高い能力を備えたものと低い能力を備えたもの）を最低品質に適合させるといった最悪のシナリオに従わせることにより対処することができる。
【非特許文献１】Blake et al., "An Architecture for Differentiated Services", RFC 2475, 1998
【非特許文献２】all RFCs and Internet Drafts by the IETF
【非特許文献３】Braden et al., "Resource ReSerVation Protocol (RSVP) - Version 1 Message Processing Rules", RFC 2209, 1997
【非特許文献４】Hancock, "Next Steps in Signaling: Framework", Internet Draft (draft-ietf-nsis-fw-05.txt), 2003
【非特許文献５】McCanne et al., "Receiver-driven Layered Multicast", Proceedings of ACM SIGCOMM '96, p. 117 to 130, 1996
【非特許文献６】Fenner, "Internet Group Management Protocol, Version 2", RFC 2236
【非特許文献７】Amir et al., "An application level video gateway", Proceeding of ACM Multimedia '95, SanFrancisco, CA, USA, November 1995
【非特許文献８】Metzler et al., "AMnet: Heterogeneous Multicast Services based on Active Networking", Proceedings of the 2nd Workshop on Open Architectures and Network Programming (OPENARCH99), New York, NY, USA, March 1999
【非特許文献９】3GPP TR 23.846: "Multimedia Broadcast/Multicast (MBMS); Architecture and functional description (Release 6)", V6.1.0, December 2002
【非特許文献１０】3GPP TS 22.246: "Multimedia Broadcast/Multicast (MBMS) user service; stage 1 (Release 6)" (version 6.4.0, March 2004)
【非特許文献１１】3GPP TS 23.246: "Multimedia Broadcast/Multicast (MBMS); Architecture and functional description (Release 6)" (version 6.1.0, December 2003)
【非特許文献１２】Braden et al., "Integrated Services in the Internet Architecture: an Overview", RFC1633, 1994
【非特許文献１３】section 6.2.1.1 of 3GPP TS 23.107: "Technical Specification Group Services and System Aspects; Quality of Service (QoS) concept and architecture (Release 6)" (version 6.1.0, March 2004)
【非特許文献１４】3GPP TS 29.060: "General Packet Radio Service (GPRS); GPRS Tunneling Protocol (GTP) across the Gn and Gpinterface (Release 6)", version 6.4.0, March 2004
【非特許文献１５】Video Transcoding Architectures and Techniques: An Overview" by A. Vetro et al., (IEEE Signal Processing Magazine, March 2003
【非特許文献１６】M. Yong, Q. F. Zhu, and V. Eyuboglu, "VBR transport of CBR-encoded video over ATM networks," in Proc. 6th Int. Workshop Packet Video, Portland, OR, Sept. 1994
【非特許文献１７】Y.C. Lin, CN. Wang, T. Chiang, A. Vetro, and H. Sun, "Efficient FGS-to-single layer transcoding," in Proc. IEEE Int. Conf. Consumer Electronics, Los Angeles, CA, June 2002, pp. 134-135
【非特許文献１８】Section 6.2 of 3GPP TS 23.107
【発明の開示】
【００１３】
本発明の目的は、多数のユーザに対しスケーラブルな、適応型のマルチメディアブロードキャスト／マルチキャストサービスＱｏＳアーキテクチャを提供することである。別の目的は、異種の端末に対処することができるブロードキャスト／マルチキャストサービスＱｏＳアーキテクチャを提供することである。さらに別の目的は、変化するネットワーク状態への適応を可能にするアーキテクチャを設計することである。
【００１４】
この目的は、独立請求項の主題により解決される。本発明の有利な実施態様は従属請求項の主題である。
【００１５】
本発明の実施態様によると、コアネットワークまたは移動通信システムの無線アクセスネットワークのネットワークエンティティにおいて、多重化パケットストリームをフィルタリングする方法が提供される。多重化パケットストリームは、マルチキャストサービスまたはブロードキャストサービスを提供し、かつネットワークエンティティを介してサービスセンターから移動端末に配信される。さらに、ネットワークエンティティは、サービス品質管理機能を提供するサービスマネージャを有する。
【００１６】
本方法は、ネットワークエンティティが、単一ベアラサービスを介して、ブロードキャストサービスまたはマルチキャストサービスを、それぞれがサービス品質属性に関連する複数のパケットストリームを含む多重化パケットストリームの形式で受信するステップと、ネットワークエンティティが、複数のパケットストリームおよび／または多重化パケットストリームの組合せの、それぞれのサービス品質属性を示す情報を受信するステップとを含む。
【００１７】
さらに、ネットワークエンティティは、下流側データ伝送のために利用可能なサービス品質を示すサービス品質制約を、サービス品質管理機能から取得することができる。一般的には、サービス品質管理機能は、ネットワークエンティティの下流側インターフェース毎にサービス品質制約を提供することができる。別のステップでは、ネットワークエンティティは、サービス品質管理機能から取得したサービス品質制約内で、受信した多重化パケットストリームのサービス品質の属性に基づいて、複数のパケットストリームから、移動端末に送信することができるパケットストリームを選択することができる。マルチキャストサービスまたはブロードキャストサービスを提供する多重化パケットストリームのパケットストリームを選択すると、それらは移動端末に送信される。
【００１８】
この実施態様によると、ネットワークエンティティはフィルタリング能力を具備する。この能力により、ネットワークエンティティは、サービス品質機能から取得されたサービス品質制約内で移動端末に向かって下流側に送信することができるストリームまたはその組合せを選択することにより、複数の個別ストリームを含む合成パケットストリームをフィルタリングできる。複数のサービスのストリームのうち、どのストリーム（または、どの組合せのストリーム）が下流側に中継され得るかを判定するために、ネットワークエンティティにより受信されたサービス品質属性を用いて、ストリームのサービス品質要件と利用可能な下流側資源とを整合させる。これにより、無線ベアラ（より正確にはそのトランスポートチャネル）に多重化された代替的、階層的または捕捉的ストリームを使用することによりマルチキャストサービスまたはブロードキャストサービスを提供することができる。
【００１９】
この実施態様の変形によると、組合せについてのサービス品質属性は、可能なストリーム組合せの属性を明示的に示すこと、あるいは複数のパケットストリームのそれぞれの個々の属性とそれらの相互関係、例えばどのストリームが組み合わせ可能で、どのストリームが代替的ストリームかなどを暗黙的に示すこと、のいずれかで示すことができることにさらに留意されたい。
【００２０】
別の実施態様では、ネットワークエンティティは、サービス品質管理機能を有する無線アクセスネットワークの任意のエンティティ、あるいはサービス品質管理機能を有するコアネットワークの任意のエンティティとすることができる。さらに、マルチキャストサービスまたはブロードキャストサービスが移動端末に提供される分散ツリーに沿って提供される多重化パケットストリームをフィルタリングする２つ以上のネットワークエンティティが存在し得ることに留意されたい。
【００２１】
別の実施態様によれば、ネットワークエンティティはさらに、多重化データストリームから個々のパケットストリームを逆多重化するためのトランスポート識別子を示す情報を受信することができる。個別ストリームは多重化形式で提供されるので、ネットワークエンティティは、サービス品質管理機能から取得されたサービス品質制約内で下流側に送信することができるベアラサービスのトランスポートチャネルからパケットストリームを選択し逆多重化するために、トランスポート識別子を使用することができる。したがって、このトランスポート識別子により、ネットワークエンティティは、受信された多重化データストリームの個々のパケットストリームを認識することができる。
【００２２】
この実施態様の変形では、パケットストリームのＵＤＰパケットに含まれるＵＤＰポート番号、パケットストリームを配信するＩＰパケットに含まれるＩＰヘッダのサービス領域の形式において設定された値、パケットストリームを配信するＩＰパケットに含まれるＩＰヘッダにおいて設定されたＤｉｆｆＳｅｒｖ  ＣｏｄｅＰｏｉｎｔ値、あるいは多重化パケットストリームのパケットストリームを伝送するデータパケットのヘッダに割り当てられたＭＰＬＳラベルを、トランスポート識別子として使用することができる。
【００２３】
別の実施態様によれば、ネットワークエンティティは、下流側に転送する前に、選択されたパケットストリームを新しい多重化パケットストリームに多重化する。
【００２４】
別の実施態様では、ネットワークエンティティは、多重化パケットストリームのフィルタリングに関連する情報を含むコンテキストを設定することができる。この点に関し、コンテキストは、各ストリームの状態、すなわちストリームがネットワークエンティティにより転送されるかドロップされるかどうかを示すことができる。したがって、本方法は、多重化パケットストリームと、および／または多重化パケットストリームと転送のために選択されたパケットストリームの組合せとに、必要なサービス品質属性を示す情報を含むマルチキャストサービスまたはブロードキャストサービスに関連するコンテキストを形成するステップをさらに含むことができる。別の実施態様では、パケットを下流側に転送するためのパケットストリームの選択は上記コンテキストに基づく。
【００２５】
本発明の別の実施態様は、例えば、ダウンリンクサービス品質制約の変更またはフィルタリング能力を備えた他のダウンリンクネットワークエンティティにより保持されたコンテキストの変更などのダウンリンク能力を変更するフィルタリング手順の適応化に関する。
【００２６】
この点に関し、ネットワークエンティティは、ネットワークエンティティのサービス品質管理機能を用いて、ネットワークエンティティのインターフェースで利用可能な下流側資源を監視することができ、それにしたがってコンテキストを更新することができる。この更新は、例えば、監視された利用可能な下流側資源により明示される制約内で複数のパケットストリームから、移動端末に提供することができるパケットストリームを選択し、監視結果において変化が観察された場合に、上記選択に基づいてコンテキスト内の情報を更新することにより実施することができる。
【００２７】
さらに、ネットワークエンティティは、ネットワークエンティティのコンテキストが更新された場合、ネットワークエンティティのコンテキストを示す情報を、上流側ネットワークエンティティの少なくとも１つに送信することができる。さらに詳細に説明されるように、受信する上流側ネットワークエンティティは、必要に応じて、保持された自身のコンテキストを更新し、それにしたがって、この情報を使用してフィルタリング手順を適合させることができる。
【００２８】
この実施態様の変形では、ネットワークエンティティは、提供可能なそれぞれの下流側のサービス品質を示す下流側ネットワークエンティティから、少なくとも１つのコンテキストを示す情報を受信することができる。少なくとも１つのコンテキストを示すこの情報に基づいて、ネットワークエンティティは、必要に応じてそのコンテキストを更新することができる。
【００２９】
ネットワークエンティティのコンテキストの更新、フィルタリング手順をコンテキストに保持された情報に基づかせること、およびフィルタリング手順の適応、すなわちストリームの選択とそれらの転送は、変化するダウンリンク能力への適応を可能にするために実行することができる。例えば、次の下流側ネットワークエンティティ向けのダウンリンク資源は音声ストリームと映像ストリームを転送するのに十分であるが、保持されたコンテキストが、映像ストリームをさらに下流側には転送できないということを示す場合でも、ネットワークは音声ストリームだけを転送することができる。
【００３０】
本発明の別の実施態様は、変化するダウンリンク能力に対するフィルタリング手順の適応を可能にするために採用されるシグナリングに関する。この実施態様によれば、ネットワークエンティティは、下流側エンティティから、マルチキャストサービスまたはブロードキャストサービスを伝送する多重化パケットストリームのために提供されるサービス品質レベルをアップグレードまたはダウングレードする要求を受信することができ、それに応答して、サービス品質を、要求元である下流側エンティティに提供することができるか否かを示すメッセージを送信することができる。
【００３１】
後者のメッセージが、要求されたサービス品質を提供することができないことを示した場合は、サービス品質管理機能から取得されたサービス品質制約が、要求されたサービス品質を提供することができることを示すとすぐに、ネットワークエンティティは、要求されたサービス品質を提供することができることを示すメッセージを、要求元である下流側ネットワークエンティティに送信することができる。
【００３２】
この実施態様の変形では、要求元である下流側ネットワークエンティティは、要求されたサービス品質を提供できないことを示すメッセージ対する要求に対応するサービス品質をアップグレードまたはダウングレードする要求を送信することが許可されない。これにより、アップグレード／ダウングレード要求を繰り返し送信すること、および要求を繰り返し拒否することによる揺らぎ（ｏｓｃｉｌｌａｔｉｏｎ）を回避することができる。例えば、これらの揺らぎは、複数のユーザがセル内のサービスに相次いで参加しようとする場合に発生し得る。１番目のユーザについては、ＲＮＣは、要求元ユーザにサービスを提供する要求に関して否定応答を受信できたと仮定する。提案するメカニズムによると、最初に拒否されたサービス要求がようやく許可されたということを上流側ノードからの「通知」が示すまで、ＲＮＣは、セル内の他のユーザからの同じサービスに対するいかなる要求も転送しない。この変形により提案された解決策は、上流側ノードと下流側ノードは何を最後に行ったかを記憶できるので、処理状態を把握することができる（ｓｔａｔｅｆｕｌ）。
【００３３】
したがって、本発明の実施態様によれば、上述の処理状態を把握することができる解決策、および処理状態を把握することができない（ｓｔａｔｅｌｅｓｓ）解決策、すなわち各ユーザに対して要求を送信するものがサポートされる。
【００３４】
サービスの様々な符号化をサポートするために、本発明の別の実施態様では、多重化パケットストリームを形成するパケットストリームがネットワークエンティティにおいて階層的パケットストリームか、代替的パケットストリームか、または捕捉的パケットストリームかを示すストリームタイプに関する情報を受信すること、およびこのストリームタイプ情報をコンテキスト内に格納することができる。
【００３５】
既に上に示したように、それぞれのパケットストリームがネットワークエンティティにより転送されるか否かを示す多重化パケットストリームのそれぞれに関するステータス情報は、ネットワークエンティティにより保持することができる。この情報を保持するための１つの可能性は、ネットワークエンティティのコンテキスト内にこれを格納することであろう。
【００３６】
本発明の別の実施態様によると、多重化パケットストリームを形成する複数のパケットストリームは、個々の優先順位を有するパケットストリームに階層化され、多重化パケットストリームは、基本的なサービス品質を提供する基本パケットストリームと、この基本パケットストリームにより提供されるサービス品質を拡張する少なくとも１つの拡張パケットストリームとを含む。
【００３７】
本発明の別の実施態様では、多重化パケットストリームを形成する複数のパケットストリームのパケットストリームは、同じ優先順位と個々のサービス品質属性を有する代替的パケットストリームである。
【００３８】
この実施形態の変形によると、ネットワークエンティティは、デフォルトのパケットストリーム関する情報、または複数のパケットストリームのデフォルトのパケットストリームの組合せに関する情報を受信し、この情報をコンテキストに格納することができる。
【００３９】
別の変形では、ネットワークエンティティは、複数のパケットストリーム代替的組合せに関する情報を受信し、この情報をコンテキストに格納することができる。
【００４０】
本発明の別の実施態様によれば、多重化パケットストリームを形成する複数のパケットストリームのパケットストリームは、同じ優先順位を有するとともに１つのメディアタイプに属する捕捉的パケットストリームである。
【００４１】
別の実施態様では、サービス品質管理機能はネットワークエンティティのインターフェース毎にサービス品質制約を提供し、ネットワークエンティティは、インターフェース毎に転送用パケットストリームの個々の選択を行う。
【００４２】
別の実施態様では、ネットワークエンティティは、選択された少なくとも１つのストリームを、サービス品質管理機能から取得されたサービス品質制約内で伝送可能なストリームに変換することができる。したがって、例えば、ネットワークエンティティにより受信されたストリームのいずれもがサービス品質制約内で下流側に送信できない状態では、ネットワークエンティティは、選択されたストリームの１つまたは複数を、下流側のサービス品質制約に整合するように適応させることができる。この変換は、コーデックタイプの変換、空間的分解能または時間的分解能の変換、複数層ストリームから単一層ストリームへの変換、一定ビットレートから可変ビットレートストリームへの変換、および可変ビットレートから一定ビットレートへの変換のうち、少なくとも１つを含むことができる。
【００４３】
本発明の別の実施態様によると、多重化パケットストリームに必要なサービス品質属性に関する受信情報は、各パケットストリームの最大帯域幅および保証帯域幅、サービスデータユニットの配送順番、サービスデータユニットの最大サイズ、サービスデータユニットのフォーマット、サービスデータユニットの誤り率、残留ビットの誤り率、誤ったサービスデータユニットを配信すべきか廃棄すべきかの指示、転送遅延パラメータ、ベアラサービスのトラフィック処理優先順位、および無線ベアラサービスの割り当て／保持優先順位のうちの少なくとも１つを示す。
【００４４】
さらに、本発明の実施態様は、多重化パケットストリームをフィルタリングするためのネットワークエンティティを提供する。このネットワークエンティティは、コアネットワークあるいは移動通信システムの無線アクセスネットワークの一部とすることができる。多重化パケットストリームは、マルチキャストサービスまたはブロードキャストサービスを提供し、ネットワークエンティティを介してサービスセンターから移動端末に配信される。ネットワークエンティティは、サービス品質機能を提供するサービスマネージャと、単一ベアラサービスを介して、ブロードキャストサービスまたはマルチキャストサービスを、それぞれがサービス品質属性に関連する複数のパケットストリームを含む多重化パケットストリームの形式で受信するための受信手段とを含むことができる。
【００４５】
受信手段は、複数のパケットストリーム、または多重化パケットストリームの組合せの、それぞれのサービス品質属性を示す情報を受信するようにさらに適合される。さらに、ネットワークエンティティは、下流側データ伝送のために利用可能なサービス品質を示すサービス品質制約をサービスマネージャのサービス品質機能から取得するための通信手段と、取得されたサービス品質制約内で、受信した多重化パケットストリームのサービス品質の属性に基づいて、パケットストリームから、移動端末に提供可能なパケットストリームを選択するように適合された処理手段と、移動端末に、マルチキャストサービスまたはブロードキャストサービスを提供する多重化パケットストリームの選択されたパケットストリームを送信する手段とを含む。
【００４６】
この実施態様の変形では、ネットワークエンティティは、上に概要を述べた様々な実施態様によるフィルタ方法を実行するように適合された手段をさらに含むことができる。例えば、ネットワークエンティティは、多重化ストリームからの個別ストリームを逆多重化するためのデマルチプレクサと、選択されたストリームに基づいて下流側に転送される新しい多重化ストリームを形成するマルチプレクサとをさらに含むことができる。
【００４７】
さらに、別の実施態様による本発明は、サービスセンターと、マルチキャストサービスまたはブロードキャストサービスを多重化されたデータストリームの形式で受信する少なくとも１つの移動端末と、上述した少なくとも１つのネットワークエンティティとを含む移動通信システムを提供する。
【００４８】
さらに、本発明の別の実施態様は、プロセッサにより実行されると、このプロセッサに、コアネットワークまたは移動通信システムの無線アクセスネットワークのネットワークエンティティにおいて多重化パケットストリームをフィルタリングさせる命令を格納するためのコンピュータ読み取り可能な媒体を提供する。この多重化パケットストリームは、マルチキャストサービスまたはブロードキャストサービスを提供することができ、サービス品質管理機能を提供するサービス管理プログラムを有するネットワークエンティティを介して、サービスセンターから移動端末に配信することができる。プロセッサは、単一ベアラサービスを介して、ブロードキャストサービスまたはマルチキャストサービスを、それぞれがサービス品質属性に関連する複数のパケットストリームを含む多重化パケットストリームの形式で受信し、複数のパケットストリーム、または多重化パケットストリームの組合せの、それぞれのサービス品質属性を示す情報を受信し、サービス品質管理機能から、下流側データ伝送のために利用可能なサービス品質を示すサービス品質制約を取得し、取得されたサービス品質制約内で、受信した多重化パケットストリームのサービス品質の属性に基づいて、複数のパケットストリームから、移動端末に提供可能なパケットストリームを選択し、そして移動端末に、マルチキャストサービスまたはブロードキャストサービスを提供する多重化パケットストリームの選択されたパケットストリームを転送することにより、多重化パケットストリームがフィルタリングされる。
【００４９】
さらにこの実施態様の変形では、コンピュータ読み取り可能な媒体は、プロセッサ上で実行されると、このプロセッサに、上述の様々な実施態様のいずれか１つに記載のフィルタ方法のステップを実行させる命令を格納するステップをさらに含む。
【００５０】
以下、添付図面を参照して本発明をさらに詳細に説明する。各図面における同様な、または対応する詳細部には同じ参照符号が付与される。
【発明を実施するための最良の形態】
【００５１】
以下の段落では、本発明の様々な実施形態が説明される。例示的な目的のみのため、大部分の実施形態はＵＭＴＳ通信システムに関連して概説され、以降の節で使用される用語は主にＵＭＴＳ用語に関連する。但し、使用される用語と、ＵＭＴＳアーキテクチャに関する実施形態の説明は、本発明の原理と概念をこれらのシステムに限定するように意図するものではない。
【００５２】
また、上述の背景技術に記載の詳細説明は、以下に説明される主としてＵＭＴＳ特有の例示的な実施形態をよりよく理解することのみを意図しており、本発明を、説明する移動通信ネットワークにおける処理と機能の特定の実施形態に限定するものとして理解すべきではない。
【００５３】
本発明は、主に帯域幅要件とそれぞれのＱｏＳ適応に関して説明されることにさらに留意されたい。しかし、ＱｏＳの識別および適応もまた、他の任意のＱｏＳパラメータ、例えば損失率やパラメータの組合せに適用することができる。
【００５４】
拡張マルチキャスト／ブロードキャストサービスアーキテクチャの設計面
本発明の上記目的を解決するマルチキャスト／ブロードキャストサービスアーキテクチャを設計する際、次の側面を考慮することができる。
【００５５】
http://www.3gpp.orgで入手可能な非特許文献１０および非特許文献１１に規定されるＭＢＭＳアーキテクチャは実用化が近い。速やかにかつ広範囲に配置することを考えると、拡張マルチキャスト／ブロードキャストサービスアーキテクチャは、そのアーキテクチャ仕様に従って、合理的な範囲に限りこの仕様と異なるとよい。したがって、ネットワークノード間のＱｏＳのネゴシエーションは回避され、シグナリングとフィルタリングに関し生成されるオーバーヘッドはできるだけ小さく保たれる。
【００５６】
さらに、拡張マルチキャスト／ブロードキャストサービスアーキテクチャを設計する際の別の態様は、コンテンツの適応化に対する広範な可能性を網羅することである。例えば、入手可能な適応型メディアコーデックを取り扱ってもよく、将来の拡張のためのフレームワークを設けてもよい。
【００５７】
現在のＭＢＭＳアーキテクチャの限界を克服するためにとり得る手法の１つは、適応型メディアコーデックを使用することであろう。適応型メディアコーデックの例は、ＭＰＥＧ２またはＭＰＥＧ４のような階層型コーデックである。これらのコーデックは、通常、最下位層が最も重要な層となる（少なくとも）２つ以上の層におけるメディア情報を符号化する。続く（上位）層は前の（下位）層に依存する。
【００５８】
コンテンツはまた、例えば、様々な帯域幅要件または様々なエラー強度を有する代替ストリームを提供することができるＭＰＥＧ−１符号器を使用することにより、複数の独立した表現で符号化することができる。
【００５９】
適応型メディアコーデックの別の例は、複数記述コーデック（ＭＤＣ）の類である。このタイプの符号化では、コンテンツはいくつかの捕捉的な層において符号化される。すなわち、基本層および前の層への依存性の概念は消える。特に、受信されるＭＤＣ符号化パケットの数が多いほど、得られる品質は高くなる。
【００６０】
別の設計留意点は無線アクセスネットワーク資源の有用であろう。先に概説したように、一般性を失わずに、無線アクセスネットワークは通常、トランスポートベアラの設定が乏しい無線リソースによるボトルネックを意味し得る基幹システム（ｃｒｉｔｉｃａｌ  ｓｙｓｔｅｍ）と見なすことができる。したがって、拡張マルチキャスト／ブロードキャストサービスアーキテクチャは、無線ネットワーク制御装置において適応機能を考慮することができる。
【００６１】
エンドノードの移動性のために、分散ツリーは継続セッション中に変化し得る。最終的に、拡張マルチキャスト／ブロードキャストサービスアーキテクチャは、セッション開始時と、例えばハンドオーバでのセッション中との双方における適応を可能にする。
【００６２】
拡張マルチキャスト／ブロードキャストサービスアーキテクチャの別の可能な設計態様は、ネットワークおよび無線構成要素において変化する状況に対する適応性を提供することである。ＭＢＭＳデータは、多くのＲＮＣと多くのＳＧＳＮを通過することができるＭＢＭＳ分散ツリーを介して、複数のユーザに配布することができる。
【００６３】
これにより、ユーザの観点からは、単一のＭＢＭＳサービスを含む様々なメディア構成要素が、構成要素毎のＱｏＳ識別を可能にする別々のＧＴＰ（ＧＰＲＳトンネリングプロトコル）トンネル（ＧＧＳＮ＜−＞ＳＧＳＮ，ＳＧＳＮ＜−＞ＲＮＣ、図５参照）および無線ベアラ（ＲＮＣ＜−＞ＵＥ）を通じ、提供することができる。したがって、拡張マルチキャスト／ブロードキャストサービスアーキテクチャは、無線アクセスとコアネットワークの双方においてＱｏＳ問題に取り組むことができる。
【００６４】
特定のネットワークのＱｏＳを実現するために、明確に定義された特性と機能を有するベアラサービス（例えば、ＭＢＭＳベアラ）を、ソースからユーザサービス（例えば、マルチキャストサービスまたはブロードキャストサービス）の宛先まで設定することができる。ベアラサービスは、縮められたＱｏＳの提供を可能にするすべての態様を含む。これらの態様は、制御シグナリング、ユーザプレーントランスポート、およびＱｏＳ管理機能である。図１に、ＵＭＴＳベアラサービス階層化ＱｏＳアーキテクチャを示す。特定層の各ベアラサービスは、下位層により提供されるサービスを利用して、個々のサービスを提供する。
【００６５】
特定のＱｏＳを有するＵＭＴＳベアラサービスを特定し、設定し、変更し、保持するために必要なノード（ＧＧＳＮ、ＳＧＳＮ、ＲＮＣ等）間における機能の特定の関係は、実施形態に固有であってよい。このことは、ＤｉｆｆＳｅｒｖ、ＩｎｔＳｅｒｖ(非特許文献１２を参照）、ＲＳＶＰ、またはＭＰＬＳ等のいくつかの技術を使用できるということを意味する。
【００６６】
ＵＭＴＳの例を考えると、これらの機能のＵＭＴＳエンティティへの割り当ては、これらのエンティティが、ＵＭＴＳベアラサービスに対してネゴシエーションされたＱｏＳコミットメントを実施できることを意味する。これらの機能の具体的な実現は実施形態に依存するが、特定されたＱｏＳ特性を維持さえできればよい。すべてのＵＭＴＳエンティティのＱｏＳ管理機能は、連携して、ＵＭＴＳベアラサービスのアクセスポイント間でネゴシエーションされたサービスの提供を保証することができる。
【００６７】
新しい拡張マルチキャスト／ブロードキャストサービスアーキテクチャを確立することについては、非特許文献１３に記載されるサービスマネージャの機能は特に興味深い。サービスマネージャは、責任を負うサービスを設定し、変更し、保持するための制御プレーン（例えば、ＭＢＭＳベアラコンテキスト、ＭＢＭＳユーザサービスコンテキスト）の機能を調整する（図１５を参照）。サービスマネージャはさらに、関連する属性（例えば、保証ビットレート、最大ビットレート、最大パケットサイズ、損失率等）をすべてのユーザプレーンＱｏＳ管理機能に提供する。
【００６８】
サービスマネージャはさらに、他のインスタンス（例えば、ＭＢＭＳベアラコンテキスト管理機能）にサービスを提供し、ピアサービスマネージャによりシグナリングし、他のインスタンスによって提供されるサービスを利用することができる。サービスマネージャはさらに、より下位の層のサービスを要求するために、属性変換（例えば、アプリケーションパケット損失率からＲＬＣ  ＳＤＵ損失率へ、ＳＤＵ損失率から層１／層２ブロック誤り率へ）を実行することができる。さらに、サービス提供の許可を受信するために他の制御機能に問い合わせることができる。
【００６９】
したがって、このようなインフラが提供されることと、ＭＢＭＳベアラとＱｏＳ管理機能との間の相互作用が付与されることを仮定してよい。これにより、どのようにしてユーザが利用可能な資源を利用するか、および他の予知できない事象に関する不確実性のために本質的に異なり得るネットワーク（ＣＮ）状態と無線アクセスネットワーク状態の双方を、ＭＢＭＳサービスのコンテキスト管理機能に知らせることが可能となる。
【００７０】
例えば、後者の具体例は典型的なフラッシュクラウド現象であり、ここでは特定のサーバおよび関連するネットワークセグメントがユーザ要求により混み過ぎてしまう（ｏｖｅｒｌｏａｄｅｄ）。別の例は、経路上の一部ノードの故障、あるいはどれだけのユーザが３ＧＰＰ  ＰＳＳのようなユニキャストサービスに加わるかに関する不確実性であろう。
【００７１】
拡張マルチキャスト／ブロードキャストサービスアーキテクチャを設計する際の別の態様は、ネットワーク資源の効率的な利用であろう。共通ノードを持つ可能性がある異なるＱｏＳ値を有する並列分散ツリーを設定する代わりに、このＱｏＳアーキテクチャは、可能な限り多くの共通データを可能な限り遠くの下流側に中継することにより、ネットワーク帯域幅とネットワーク資源を再利用できるようにする。典型的なシナリオは、様々な利用可能な資源、例えば様々なビットレートを有する様々な基地局をサポートするＲＮＣの場合と考えられる。この場合、サポートされるすべてのメディア符号化率をＲＮＣまで１つの（または複数の）ベアラで転送し、どのコンテンツがどの基地局に転送されるかをＲＮＣに判断させるほうが合理的である。
【００７２】
さらに、拡張マルチキャスト／ブロードキャストサービスアーキテクチャを設計する際の別の態様は、マルチキャスト／ブロードキャストサービスのネットワーク駆動型適応（ｎｅｔｗｏｒｋ−ｄｒｉｖｅｎ  ａｄａｐｔａｔｉｏｎ）を可能にすることである。現在のＭＢＭＳアーキテクチャでは、ＭＢＭＳユーザは通常、セッション配送の詳細をサーバ（例えば、ＢＭ−ＳＣ）とネゴシエーションする機会はほとんどないか全くないであろう。ここが、ネットワーク駆動型適応が重要になる点である。
【００７３】
拡張マルチキャスト／ブロードキャストサービスアーキテクチャ
本発明の一実施形態によれば、ＭＢＭＳ伝送サービスとＭＢＭＳユーザサービスの概念が拡張される。マルチキャストサービスまたはブロードキャストサービス（例えば、ＭＢＭＳサービス）を提供するための単一ベアラサービス（例えば、ＭＢＭＳベアラ）を利用する手法を検討する。ＱｏＳアーキテクチャは、ユーザサービスのストリーム／ベアラの識別がネットワークノード（ネットワークエンティティ）において可能になるように拡張される。このようにして、変化する資源、異種の端末、および様々なネットワーク構成要素へのネットワーク駆動型適応は、この情報を用いることにより可能となる。
【００７４】
例示的な目的のためだけに以下で検討するＭＢＭＳサービスの時系列（ｔｉｍｅｌｉｎｅ）は、次のようになるであろう。データプレーンにおいては、要求されたマルチメディアブロードキャストまたはマルチキャストサービスのための選択的／代替的／捕捉的ストリームは、ＱｏＳ要件（制約）が中間ネットワークエンティティのいずれか１つにより満たされる限り、多重化パケットストリームの形式で下流側に転送される。中間ノードがユーザサービスに属するすべてのパケットストリームを転送できない場合、その中間ノードは、全体のセッションストリームを利用可能なＱｏＳに適合させるために、ストリームをフィルタにかけることによって除去する。中継されたコンテキスト情報（すなわち、拡張ＭＢＭＳベアラコンテキスト内の情報）により、ネットワークノードはこのフィルタリングを実行できるようになる。
【００７５】
このノードは利用可能であろう残りの選択肢を知っているので、コンテキスト情報によってさらに、ネットワークは突然の能力変化（アップグレード／ダウングレード）に応答できるようになる。中継されたコンテキスト情報は、サービス構成（すなわち、サービスセマンティクス（ｓｅｒｖｉｃｅ  ｓｅｍａｎｔｉｃｓ））の選択肢を記述しており、そしてこのコンテキスト情報は、例えば、ＭＢＭＳベアラコンテキスト内に格納することができる。別の設計可能性は、下流側にドロップされたストリームとドロップされなかったストリームの状態に関する情報を転送することであろう。その詳細は以下の段落に示す。
【００７６】
一般性を失うことなく、無線アクセスネットワークは３ＧＰＰアーキテクチャのボトルネックと考えられ、コアネットワークは過剰供給（ｏｖｅｒ−ｐｒｏｖｉｓｉｏｎｅｄ）されていると考えられる。本発明はこの仮定の元でのみ適用可能であると限定すべきでないことに留意されたい。したがって、ＲＮＣは自身の無線ドメインにおける利用可能な資源についての知識を持つので、フィルタエンティティ（すなわち、「適応ノード」）を、図２、３、４に示すように、ＲＮＣ内に例示することができる。これにより、フィルタエンティティをこの機能に適切なものにする。このようにして、ＲＮＣは「適応ノード」として動作する。
【００７７】
一般的には、ＲＡＮまたはＣＮにおけるあらゆるネットワークエンティティは、フィルタエンティティとして動作することができる。しかし、これらのエンティティを、要求されたサービスを受信する移動端末に向かう下流側リンク上の資源を知るフィルタリングエンティティとして選択することは可能である。
【００７８】
適応するネットワークエンティティにおけるフィルタの初期化は、制御メッセージを使用することによりトリガすることができる。したがって、以下に説明するＭＢＭＳ手順を用いることにより、サービスセマンティクスを、対応するＲＮＣに向けて下流側にシグナリングすることができる。サービスセマンティクスは、ユーザサービスと、それらの相互関係と、それらのＱｏＳプロファイルとを伝送するストリームに関する情報を参照するためのものと理解することができる。
【００７９】
本発明の一実施形態によれば、サービスセマンティクスを反映するこれらの情報要素は、特定されたＭＢＭＳシグナリングメッセージの選択的な領域内に与えられる。さらに、ＧＧＳＮおよびＳＧＳＮのような中間ノードは、メッセージ拡張の値を理解しない場合、それらを解析および処理する必要はなく、それらを下流側に転送するだけでよい。
【００８０】
本発明の別の実施形態によれば、上に概説した適応型ＱｏＳの概念はさらに、与えられたコンテンツ、例えば階層的コンテンツ、代替的コンテンツ、および捕捉的コンテンツを符号化するための様々なパラダイムをサポートするサービスを可能にすることを目的とする。これは、ＭＢＭＳサービスを提供するための新規な手法であるので、現在のアーキテクチャにはまだ反映されていない。現在、必要なＭＢＭＳコンテキスト情報のシグナリングおよび管理用のプレースホルダ（ｐｌａｃｅｈｏｌｄｅｒ）のみが定義されるが、様々な可能性をどのように実現するかについては定義されていない。したがって、サービスセマンティクス（例えば、サービス、それらの相互関係、それらのＱｏＳプロファイル等に属するストリームに関する情報）を格納する拡張ＭＢＭＳベアラコンテキストの使用は、現在のＭＢＭＳアーキテクチャと互換性がある。
【００８１】
さらに、現在のＭＢＭＳアーキテクチャでは、ストリームの概念が明確ではない、つまり、ＱｏＳレベル毎に別々のＭＢＭＳベアラを設定するか、あるいは同じＭＢＭＳベアラに対して別々のトンネルを設定するかどうかは規定されていないということに留意すべきである。しかしこの問題は、次には、サービス通知、サービス起動、およびサービスコンテキスト仕様に厳しい影響を及ぼす。
【００８２】
拡張ＭＢＭＳベアラコンテキスト
以下では、適応ノードに保持される、本発明の一実施形態による拡張ＭＢＭＳベアラコンテキストについて説明する。提案するコンテキストはストリームの関係についての追加情報を含み、それらのプロファイルのリストは、その情報を理解するＲＡＮおよびＣＮのネットワークエンティティ、いわゆる「適応ノード」において保持される。そうでなければ、ネットワークノードは、後方互換性（ｂａｃｋｗａｒｄｓ−ｃｏｍｐａｔｉｂｉｌｉｔｙ）を保証するために上記拡張を無視することができる。
【００８３】
【表１】
2008503945.tif 000003
【００８４】
各ストリーム情報要素は、ストリームの相互関係に依存する相異なる領域を含み得る。例示された各タイプ（階層的、代替的、捕捉的）についてその情報要素を次に説明する。
【００８５】
【表２】
2008503945.tif 000004
【００８６】
【表３】
2008503945.tif 000005
【００８７】
【表４】
2008503945.tif 000006
【００８８】
ＭＢＭＳベアラコンテキスト拡張のシグナリング
サービスのストリームがユーザに提供される分散ツリー内の中間ノードは、「（複数の）適応ノード」を対象としたＭＢＭＳメッセージにおけるストリーム情報を中継することができる。
【００８９】
例えば、ＧＰＲＳに基づいたトンネリングプロトコル（ＧＴＰ−Ｃ）とＲＡＮアプリケーション部（ＲＡＮＡＰ）のような標準シグナリングプロトコルは、ストリーム／ベアラ関係とＭＢＭＳサービスの特性とを反映する情報構造を伝送するために使用することができる。ＭＢＭＳベアラコンテキストの拡張を伝送するために他のプロトコルも使用し得るということに留意されたい。
【００９０】
本発明の別の実施形態によると、情報構成を伝送するために、ＧＴＰ−Ｃメッセージフォーマットのプライベート拡張情報要素（Ｐｒｉｖａｔｅ  Ｅｘｔｅｎｓｉｏｎ  Ｉｎｆｏｒｍａｔｉｏｎ  Ｅｌｅｍｅｎｔｓ）を使用することができる。図１０に、これらの追加情報部分を伝送することができるプライベート拡張領域を示すＧＴＰ−Ｃ  ＭＢＭＳセッション開始要求を例示的に図示する。プライベート拡張情報要素は選択的であり、通常、プライベート情報を求めるオペレータまたはベンダにより使用される。代替的には、必須領域もまた、ＭＢＭＳベアラコンテキスト拡張を伝送するために、プロトコルメッセージ内に規定することができる。
【００９１】
さらに、ＭＢＭＳベアラを設定し、ＭＢＭＳセッション開始またはＭＢＭＳセッション登録のようなＭＢＭＳ手順を実行するために、ＲＡＮＡＰ制御メッセージに、これらの情報の要素の対応するマッピングを規定することができる（例えば、上記非特許文献１１を参照）。
【００９２】
単一ベアラ手法
本発明の一実施形態によれば、ユーザサービスは、単一ベアラ、すなわち単一トランスポートチャネルを用いて提供される。例えば、ユーザサービスは、単一のＭＢＭＳベアラサービスを用いて提供することができる。
【００９３】
この実施形態によれば、以下の機能エンティティがブロードキャスト／マルチキャストサービスのアーキテクチャに導入される。この新しいアーキテクチャは、パケットフィルタエンティティを実現できる少なくとも１つの「適応ノード」を含む。ＲＡＮまたはＣＮのこのネットワークエンティティは、ユーザサービスを提供するパケットストリームを、関連する無線ベアラのトランスポートチャネルを介して、ネットワーク制約に適応させることができる。本発明の別の実施形態によると、２つ以上の適応ノードがユーザサービスの分散ツリー内に提供される。
【００９４】
ユーザサービスの分散ツリー内の適応ノードは、ストリーム情報とストリーム相互関係を含むコンテキスト情報を提供することができる。このコンテキスト情報は、例えば、上述のように拡張ＭＢＭＳベアラコンテキストの形式で格納することができる。
【００９５】
提案する単一ベアラ手法は、異種のＱｏＳを有する分散ツリーの枝、例えばユーザサービスが異なるＱｏＳを受信する異なる基地局を有することを許容する。また、非適応ノードにいかなる機能を実装する必要はない。適応ノードにパケットレベルのフィルタを実装し、適応ノードに追加のＭＢＭＳベアラコンテキスト情報を導入することにより、公知のアーキテクチャに優る上述の利点を有する新しいサービスアーキテクチャを提供することができる。
【００９６】
異なるストリームに属するデータパケットは、唯一のマルチキャストグループアドレスが割り当てられる単一トランスポートチャネル上に多重化される。このようにして、多重化パケットストリームは、ユーザサービスを提供するために、複数の個別ストリームを含む。サービスセンター、例えばブロードキャスト／マルチキャストサービスセンター（ＢＭ−ＳＣ）は、異なる手段により、例えば（第三者の）コンテンツプロバイダから符号化生データ（例えば、ＭＰＥＧ２）として、あるいはインターネット上の複数のＩＰマルチキャストチャネルを通じて、ストリームを受信することができる。
【００９７】
サービスセンターは、内在するサービスアーキテクチャに依存して、データ多重化を実行するためにいくつかの方法を選択することができる。例えば、符号化ストリームを、異なるＵＤＰポート番号を使用することにより、ＲＴＰ／ＵＤＰパケットにカプセル化することができる。次に、ＵＤＰデータパケットは、通知されたサービスに対応するＩＰマルチキャストグループアドレス上に多重化される（図７を参照）。ユーザサービスを記述するサービスセマンティクスは、トランスポートチャネルを介して提供される個別ストリームのポート番号を示すことができる。
【００９８】
この情報は、ユーザサービスの記述を含むコンテキストの形式で各適応ノードに格納することができ、サービスセマンティクス、例えば上述の拡張ＭＢＭＳベアラコンテキストを含む。個別ストリームのポート番号に関する情報は、トランスポートチャネルを使用して提供される多重化データストリームからの個別ストリームを逆多重化するために、適応ノードにより使用することができる。
【００９９】
代替的には、ＩＰヘッダのＩＰ  ＴＯＳ（サービスのタイプ）領域は、個別ストリームを識別するために使用することができる。サービスセンターは、通知されたサービスに対応するマルチキャストグループアドレス上にデータパケットを多重化し、それによって、元のストリームのそれぞれをサービスタイプ領域の唯一のＴＯＳ領域値にマッピングすることができる。したがって、この手法は、サービス識別のための手段、すなわち適応ノードがユーザサービスを提供する様々なストリームを検出できるようにするラベルを提供するためにＴＯＳ領域を使用する（図８を参照）。
【０１００】
さらに、ＤｉｆｆＳｅｒｖ  ＤＳＣＰ（ＤｉｆｆＳｅｒｖ  Ｃｏｄｅ  Ｐｏｉｎｔ）またはＭＰＬＳラベル（マルチプロトコルラベルスイッチング）のような他のラベルもまた、多重化領域として、すなわち単一ベアラを介してユーザサービスの個別ストリームを提供する際にそれらを識別するために使用することができることにも留意されたい。
【０１０１】
上に概説したように、データパケットは、採用された多重化方式に従って、すなわちポート番号、ＴＯＳ領域等に基づいて、「適応ノード」において識別することができる。
【０１０２】
サービスが代替的（互いに排他的な）ストリーム／ストリームのグループを提供する場合、「適応ノード」は、現在のネットワーク状態に従って、かつサービスセンターから受信した逆多重化情報に従って、コンテキスト情報内に含まれ得る代替的ストリームのうちの１つのストリーム／１つのストリームグループだけを転送することができる。このコンテキスト情報は、上に概説した拡張ＭＢＭＳベアラコンテキストを設定するために使用することができる。この状態は、各適応ノードのサービスマネージャにより検出することができる。
【０１０３】
サービスが階層化ストリーム形式で提供される場合、「適応ノード」は、生成される複合ストリームが現在のネットワーク状態を浸食せず、かつコンテキスト情報内に表現されるストリーム依存性に従うように、ストリームをフィルタリングすることができる。ストリームタイプと逆多重化に関して必要なコンテキスト情報は、サービスセンターから「適応ノード」に提供され、ローカルＭＢＭＳベアラコンテキスト内に格納することができる（上記表のストリームＩＥを参照）。
【０１０４】
動作
以下では、ＭＢＭＳサービスの提供の例示的な動作について、現在のＭＢＭＳ標準（非特許文献１１を参照）を参照して概説する一方、本発明の一実施の形態による手順またはそれぞれのシグナリング情報に対する変更を説明する。ＭＢＭＳセッション起動およびＭＢＭＳ登録手順後、標準ＭＢＭＳベアラコンテキストは、分散ツリーの一部である各中間ノードに設定される。現在のＭＢＭＳベアラコンテキストは、ベアラパラメータだけでなく、伝送されるデータの一部の特性も反映する。しかしそれは、上に概説したようにネットワークノードがＭＢＭＳサービス適応を実行できるのに十分な情報を提供しない。
【０１０５】
したがって、本発明の一実施形態によると、分散ツリー内の各適応ノードに格納されたＭＢＭＳベアラコンテキストは、上記表１に記載した新しい追加のエントリを導入することにより拡張される。
【０１０６】
ストリーム情報要素（ＩＥ）は、「適応ノード」におけるストリームの逆多重化およびフィルタエンティティの初期化のための情報を提供する。ストリーム情報要素（ＩＥ）はさらに、ストリームのタイプ、例えば、階層的、選択的または捕捉的、ストリームの優先順位または適用可能ならばその組合せ、割り当てられたトランスポート識別子、ＱｏＳプロファイル、および下流ノード側への各下流側インターフェースの転送状態を含むことができる。さらに、ストリーム間の様々な関係により必要なＱｏＳ属性も規定することができる。
【０１０７】
各ストリームについては、別々のＱｏＳプロファイル、下流側インターフェース毎の転送状態識別子、およびトランスポート識別子がコンテキスト内に格納されることに留意されたい。この実施形態の変形によれば、各ストリームが単一ベアラを使用して伝送される場合、拡張コンテキストのストリームＩＥ内のストリーム毎のＱｏＳプロファイルに規定されたパラメータは、ＭＢＭＳベアラコンテキストのパラメータに対応する。
【０１０８】
さらに、上記表１に示す拡張ＭＢＭＳベアラコンテキストの「ＱｏＳ」領域は、ＭＢＭＳベアラサービスのために必要なサービス品質を含むことに留意されたい。ベアラが複数のストリームを含む場合、「ＱｏＳ」領域のパラメータは、アクティブであるすべてのストリームにより必要とされる累積的（ｃｕｍｕｌａｔｉｖｅ）サービス品質を反映することができる。したがって、提案する解決策は、現在のアーキテクチャに対して後方互換性を有する。
【０１０９】
非特許文献１１に規定されるＭＢＭＳアーキテクチャによれば、ＭＢＭＳ  ＵＥコンテキストは、ＭＢＭＳサービス起動メッセージの結果として、ＵＥと中間ノードにおいて生成される。さらに、ＭＢＭＳベアラコンテキストは、ＭＢＭＳ登録手順の結果として、中間ノードにおいて生成される。次に、ＭＢＭＳ登録メッセージは、サービスに対して第１番目のＭＢＭＳ  ＵＥコンテキストが生成されたとき、そして、例えば、継続セッションへの新しい参加者または現在関与する端末のハンドオーバのために新しい下流側ノードが継続セッション中にＭＢＭＳベアラコンテキスト設定を要求しているときは常に、セッションの最初にトリガすることができる。
【０１１０】
本発明の一実施形態によれば、「適応ノード」は、それぞれの適応ノードにおいて拡張ＭＢＭＳベアラコンテキストを設定することを可能にするサービスセマンティクスを受信することへの関心をシグナリングすることができる。「適応ノード」は、図１１に示すＭＢＭＳ登録要求のプライベート拡張ＩＥを使用することにより、このような情報への関心を表すことができ、それ以外は標準登録手順と違わない処理である。ＭＢＭＳ登録要求メッセージのプライベート拡張ＩＥを使用する代わりに、このメッセージ内の追加の必須領域を規定してもよい。他の代替案は、サービスセマンティクスの要求およびトランスポートについての新メッセージ／新手順を規定することであろう。単純化のため、プライベート拡張ＩＥの使用についてここでは例示する。
【０１１１】
本実施形態の変形によると、サービスセンターが、デフォルトで分散ツリーのすべてのノードに対する拡張ＭＢＭＳベアラコンテキストの設定を可能にする追加サービスセマンティクスをシグナリングできるということにも留意されたい。この場合、サービスセマンティクスを理解しないノードは、追加サービスセマンティクスを単に無視すればよい。
【０１１２】
ＭＢＭＳ標準による登録手順を図１６に示す。点線は、ＭＢＭＳベアラコンテキストがアクティブに設定された場合に、ＭＢＭＳセッション開始が登録手順後にトリガされることを例示するように意図している。なお、別の実施形態によれば、上の表２．１、２．２、３．１、３．２、４．１、４．２のストリームＩＥは、ＭＢＭＳ登録手順中にＭＢＭＳ登録応答のプライベート拡張で送信することができる。
【０１１３】
代替的には、別の実施形態は、表２．１、２．２、３．１、３．２、４．１、４．２のストリームＩＥもまた、ＭＢＭＳセッション開始手順を実行する際に伝送することができるということを予測する。ＭＢＭＳベアラコンテキスト設定に従って、ＭＢＭＳセッション開始手順はＢＭ−ＳＣによりトリガされる。本実施形態のこの実施形態によれば、ＭＢＭＳセッション開始要求は、ＭＢＭＳサービスのための実際のＱｏＳパラメータ、すなわち表１の「ＱｏＳ」領域と、ＭＢＭＳ登録手順中に既に完了していなければ、上記表２．１、２．２、３．１、３．２、４．１、４．２に示すサービスセマンティックスとを伝送するために使用することができる。
【０１１４】
一般的には、ＭＢＭＳ開始手順（要求メッセージおよび応答メッセージ）もまた、サービスのための実際の資源（ベアラプレーン）を設定するために使用することができる。すなわち、ＭＢＭＳセッション開始手順がトリガされるまでの実際の資源の予約は無い。
【０１１５】
標準のＭＢＭＳセッション開始要求と他のＭＢＭＳ制御メッセージはＧＴＰ−Ｃプロトコル規定(http://www.3gpp.orgで入手可能な非特許文献１４参照）に規定される。これらのメッセージの規定では、サービスエンドユーザアドレス、アクセスポイント名およびＱｏＳプロファイルに対する必須エントリが規定される。さらに、オペレータがネットワークノードに追加制御情報をシグナリングできるようにするプライベート拡張ＩＥを、選択的に提供することができる。
【０１１６】
本発明の一実施形態によると、拡張コンテキスト情報−ストリームＩＥコンテンツ（表２．１、２．２、３．１、３．２、４．１、４．２を参照）の全てまたは一部のいずれか−は、図１０に示すように、プライベート拡張ＩＥ領域にカプセル化される。代替的には、これらのメッセージに対する必須の拡張を規定し、あるいはこれらの情報を伝送するために既存のＩＥを再利用してもよい。他の代替案は、これらの情報要素を伝送するための新しいメッセージおよび手順を規定することであろう。
【０１１７】
上に概説したように、分散ツリーに沿った中間ノードは、提供される選択的情報を理解しなくてもよい。この場合、これらのノードは、その目的地、すなわち「適応ノード」に到達するようにこの情報を中継すればよい。
【０１１８】
さらに、本発明の一実施形態によると、ＭＢＭＳセッション開始要求は、ＲＡＮのＲＮＣまで中継することができることに留意されたい。コアネットワークにおけるＧＧＳＮとＳＧＳＮとの間のＧＴＰ−Ｃ（図６を参照）にＭＢＭＳセッション開始要求を中継するために使用されるものと同様のメッセージを、ＳＧＳＮとＵＴＲＡＮ（例えば、ＲＮＣ）との間の通信のために使用することができる。これらの新しいメッセージは，拡張ＲＡＮＡＰプロトコルを使用してＵＴＲＡＮに送信することができる。
【０１１９】
「適応ノード」がＭＢＭＳセッション開始要求を受信したと仮定すると、「適応ノード」はメッセージを解析し、その中に含まれる情報を拡張ＭＢＭＳベアラコンテキスト内に格納することができる。本発明の実施態様によれば、適応ノードは、各ストリームおよび／またはストリームの可能な組合せのＱｏＳプロファイルを検査する。
【０１２０】
ユーザサービスが代替的ストリームの形式で提供され、かつ下流側のＱｏＳ制約により、ストリームの少なくとも１つが、与えられた下流側制約内で転送することができるＱｏＳ要件と関連付けられると規定された場合、適応ノードはＭＢＭＳセッション開始応答「要求受容」により返答することができる。
【０１２１】
ユーザサービスを提供するために階層的ストリームが使用される場合は、下流側ＱｏＳ制約が基本層を運ぶストリームの提供を少なくとも許容すれば、等価な応答を送信することができる。
【０１２２】
捕捉的ストリームの場合、各ノードにおけるＱｏＳ制約がそれを許可する限り各ストリームは転送される。肯定応答は、ストリームの少なくとも１つが下流側に転送される限り、通知される。
【０１２３】
したがって、上記の場合、適応ノードは、サポートすることができる最良のＱｏＳレベルを有する下流側ベアラを設定し、ベアラ状態を「アクティブ」に更新し、そしてストリームの状態を、適切に、例えば転送かドロップに設定することができる。
【０１２４】
一方、ノードの下流側インターフェース毎のＱｏＳ検査が、ベアラ内に提供されるストリーム毎に失敗した場合、ＭＢＭＳベアラは設定されない。
【０１２５】
本発明の別の実施形態では、適応ノードが、例えば、サービスの１つまたは複数のストリームを下流側ＱｏＳ制約に整合させるためにパケットストリームの変換を可能にする手段をさらに具備することを提案する。これは、例えば、ノードの下流側インターフェース毎のＱｏＳ検査が、ベアラ内に提供されるストリーム毎に失敗した状況において適用可能である。
【０１２６】
可能なストリーム（または、ストリームの組合せ）の変換の概要は、非特許文献１５に提案されている。コード変換技術は、例えば、以下のように様々な要求に対応することができる。
【０１２７】
１．様々なコーデック間を切り替えるためのコーデック変換
２．時間分解能またはフレーム率の低減
３．空間分解能の低減
４．一定ビットレートから可変ビットレートへの変換
５．複数層ストリームから単一層ストリームへの変換
【０１２８】
コーデック変換の適用は、相異なるアーキテクチャ同士または専用ネットワーク同士がインターフェースする場合、例えばＭＰＥＧファイルからウインドウズ専用ＷＭＡコーデックへの変換に適切であろう。フレーム率低減は、符号化された画像の品質を保持し、処理ニーズを低減しつつ、ビットレートを低減するために有用であろう。フレーム率低減の典型的な使用例は、画像分解能を保持する低減率が記憶装置能力の点から許容される妥協点である監視アプリケーションである。
【０１２９】
空間分解能の低減は、移動端末のような小型装置に媒体を適応させる場合に有用であろう。典型的な変換は、ＭＰＥＧ２画像（５．３Ｍｂｐｓ、３０ｆｐｓ、７２０ｘ４８０）からＭＰＥＧ４単一プロファイルレベル２（１２８Ｋｂｐｓ、１０ｆｐｓ、３５２ｘ２４０）への変換である。
【０１３０】
一定ビットレートストリームから可変ビットレートストリームへの変換は、非特許文献１６に例示される。その目的は、可変ビットレートサービスネットワークにおいて一定ビットレートストリームに対処することである。
【０１３１】
さらに、複数階層ストリーム、例えばＭＰＥＧ−４  ＦＧＳの単一層ストリームへの変換は、適応ノードが実行できる変換の別の例である。これは、非特許文献１７に例示される。
【０１３２】
本発明の先の実施形態によれば、ＲＮＣが分散ツリー内の唯一の「適応ノード」であったとしても、ＲＮＣは、サービス受信側ＵＥに向かってストリームの一部を単に転送するだけでよいにもかかわらず、サービスに属するすべてのストリーム（図１２を参照）を受信する。
【０１３３】
これと対照的に、本発明による別の実施形態では、ＲＮＣは、ストリームのサブセットのみ、すなわちその下流側ノード（例えば、基地局）によりサポートされたストリームを受信することが想定される。これは、次の上流側ノード、例えばＳＧＳＮもまた、不要なストリームをＲＮＣの前にドロップするために、「適応ノード」として動作することを意味する。
【０１３４】
本発明の別の実施形態によるブロードキャスト／マルチキャストサービスアーキテクチャの別の拡張例を、図１３と図１４に例示する。図１３と図１４において、ＲＮＣとＳＧＳＮの双方は「適応ノード」である。この例では、１つの基地局だけがより高いＱｏＳをサポートし、この情報はそれに応じて上流側ノードであるＳＧＳＮとＧＧＳＮのそれぞれに伝送される。上流側ノードであるＳＧＳＮとＧＧＳＮは、サポートされたストリームだけを下流側エンティティへ転送するという点で、下流側ネットワーク制約を適合させることができる。
【０１３５】
正常なＭＢＭＳセッション開始手順の終りに、必要な資源（ＱｏＳパラメータ）を含むデータ配布ツリーを設定することができる。要求されたユーザサービスを提供するための個別ストリームを含む多重化パケットストリームは、内在するアーキテクチャのユーザプレーンプロトコル、例えばＧＰＲＳベースのネットワークの場合のＧＴＰ−Ｕを利用することにより、下流側の「適応ノード」に透過的に伝送することができる。
【０１３６】
データパケットが「適応ノード」に一旦到達すると、そのパケットは、用いられたトランスポート識別子に基づいて逆多重化される。
【０１３７】
本発明の一実施形態によると、適応ノードは、無線リソース、例えばＲＮＣを制御するノードに設置される。３ＧＰＰアーキテクチャのＲＮＣは、無線リソースをより効率的に使用するために、ＩＰパケットのヘッダ圧縮を実行することができる。ヘッダ圧縮は、パケットデータ変換プロトコル（ＰＤＣＰ）によって、ＲＮＣとＵＥとの間で実行することができる。
【０１３８】
本発明の一実施形態によると、ユーザサービスを提供するパケットストリームをフィルタリングするネットワークエンティティは、図７と図８に示すように、ＧＴＰ−Ｕ終端エンドポイントとＰＤＣＰインスタンスとの間に設置されたＲＮＣとすることができる。したがって、ＲＮＣはＰＤＣＰを実行することができるので、ＲＮＣは、ＩＰデータパケットを処理して、ヘッダ圧縮のようなそれらのヘッダに関する操作を実行する機能を備えることができる。したがって、ＲＮＣもまた、サービスを提供するトランスポートチャネルからのデータパケットを、例えば上に概説したＵＤＰポート番号、ＩＰヘッダのＴＯＳ領域値等に基づいて逆多重化するように適合させることができる。
【０１３９】
サービスデータの伝送中に、適応ノードは、対応するトランスポートベアラの各データパケットのヘッダを照合し、拡張ＭＢＭＳベアラコンテキスト内に格納された状態情報に従って、パケットの転送とドロップを実行することができる。
【０１４０】
単一ベアラを介したサービス配送の手法を要約するために、本発明の別の例示的な実施形態による、２つの階層ストリームを含むＭＢＭＳサービスの提供について、以下に説明する。階層的ストリームは、低い帯域幅要件（例えば、８ｋｂｐｓ）を有する音声ストリームと、適度な帯域幅要件（５６ｋｂｐｓ）を有する映像ストリームとを含む。音声ストリームは、より高い優先順位を有し、通常、その低い資源要件のためにすべてのユーザに提供することができる。映像ストリームは、選択的であって、ネットワーク状態が全体の要件と整合しない場合はフィルタリングすることができる。ユーザは、例えばＭＢＭＳサービス加入手順により、ユーザサービスに加入する。
【０１４１】
ステップ１：セッション通知
ユーザは、例えば、ＳＭＳメッセージ内のセッション通知プロトコル（ＳＡＰ）にカプセル化された、あるいはウェブサイトに掲示された、セッション記述プロトコル（ＳＤＰ）で符号化されたセッション記述を受信し、または検索する。
【０１４２】
以下に、ユーザ端末により受信されたセッション通知の例示的な抜粋を示す。各コードラインに続くコメントは、各コードラインの意味を説明する。
【０１４３】
C=IN IP4 232.255.255.112    //トランスポートチャネルに割り当てられたＩＰマルチキャストアドレス
m=audio 64000 RTP/AVP XY    //音声ストリームのポート番号とアプリケーションプロトコル
b=AS:8    //音声ストリームに必要な帯域幅
m=video 64002 RTP/AVP YZ    //映像ストリームのポート番号とアプリケーションプロトコル
b=AS:56    //映像ストリームに必要な帯域幅
【０１４４】
ステップ２：サービス起動
ユーザはセッション通知で提供されたＩＰマルチキャストアドレスを使用して、サービス起動を実行する。図９に示すように、ＵＥコンテキストの生成は、ＵＥおよびネットワークノードにおいてトリガされ、必要に応じて、ＭＢＭＳ登録手順は、必要な拡張ＭＢＭＳベアラコンテキストを分散ツリーに沿った中間ノードに与えるためにトリガされる。
【０１４５】
ステップ３：セッション開始
セッション開始時、または新しいノードがＭＢＭＳ登録手順をトリガして拡張ＭＢＭＳベアラコンテキストが継続セッション中にアクティブである場合は常に、ＭＢＭＳセッション開始要求を下流側に送信することができる。このメッセージは、ノードが分散ツリーを設定するとともに必要な資源を割り当てることができるように、ノードにＱｏＳ要件を与える。
【０１４６】
この実施形態によると、ＭＢＭＳセッション開始要求メッセージにおいて通常は伝送されるＭＢＭＳベアラコンテキストパラメータは、適応ノードを対象とした追加のストリーム情報を含む。本例では、この情報は次の通りである。ストリーム関係＝選択的；音声ストリーム（８ｋｂｐｓ等）のＱｏＳプロファイル、優先順位＝１、トランスポート識別子ＴＯＳ＝１；映像ストリーム（５６ｋｂｐｓ等）のＱｏＳプロファイル、優先順位＝２、トランスポート識別子ＴＯＳ＝２。
【０１４７】
この情報またはその一部は、図１０に示すように、ＭＢＭＳセッション開始要求メッセージのプライベート拡張領域で伝送することができる。さらに、ベアラプレーン（実際の資源）は予約される。
【０１４８】
なお、上に説明したように、各ストリームのＱｏＳプロファイル、それらの相互関係等を含むストリームＩＥはまた、ＭＢＭＳ登録応答におけるＭＢＭＳ登録手順中に伝送することができる。この場合、ＭＢＭＳベアラＱｏＳプロファイルの伝送、および実際の資源の予約は、ＭＢＭＳセッション開始手順中に今までどおり実行することができる。
【０１４９】
さらに、「適応ノード」は、生成された２つのＱｏＳレベル（音声、音声および映像）を検査することができ、少なくとも音声ストリームを転送することができるということを考えると、「適応ノード」は、次の上流側ノードに肯定的なＭＢＭＳセッション開始応答を送信することができる。さらに、この適応ノードは、追加ベアラ情報をその拡張ＭＢＭＳベアラコンテキスト内に格納し、ＭＢＭＳベアラ状態を「アクティブ」に設定する。
【０１５０】
この例では、第２のＱｏＳレベル（音声および映像）を適応ノードの下流側に提供できないので、拡張ＭＢＭＳベアラコンテキストにおける音声ストリームおよび映像ストリームの状態は、「転送」と「ドロップ」にそれぞれ設定されるものとさらに想定される。
【０１５１】
さらに、下流側のＱｏＳ制約がその転送を許可しない限り、適応ノードはストリームの転送状態に従ってパケットフィルタを設定し、そしてトランスポート識別子を使用して、（ＩＰヘッダのＴＯＳ領域値に基づき）映像ストリームのデータパケットをフィルタにかけることによって除去する。
【０１５２】
ステップ４：データ伝送
肯定的なセッション開始応答メッセージがＢＭ−ＳＣに一旦到達すると、必要に応じて、データを生成し、音声データパケットおよび映像データパケットを、割り当てられたＩＰマルチキャストチャネル（232.255.255.112）上に多重化する。この手順は、例えば、各音声パケットおよび映像パケットに対して、ＴＯＳ領域を「１」と「２」にそれぞれ適切に設定することを含む。この実施形態の変形では、ＴＯＳ領域値はストリームの優先順位に従って設定され、例えば、ＴＯＳ値が低いほど、パケットが属するストリームの優先順位は高くなる。
【０１５３】
これら２つのパケットストリーム（音声および映像）は、「適応ノード」に到達するまで分散ツリーに沿って転送される。「適応ノード」は、ストリームを運ぶＩＰパケットを、そのフィルタリングエンティティまで転送し、このフィルタリングエンティティは、映像ストリームの拡張コンテキストの状態領域の値によって示される「２」（例えば、「ドロップ」）に設定されたＴＯＳ領域を有するパケットをすべて廃棄する。音声ストリームに属する他のパケットは、下流側ノードに転送される。
【０１５４】
ＭＢＭＳサービス中の動的適応−利用可能な資源のハンドオーバと変更
上記から理解されるように、動的適応の基本部分が確立された。すなわち、下流側ノードのいずれか１つに提供することができるＱｏＳをアップグレードまたはダウングレードする場合に、「適応ノード」はこのような要求を処理することができる。ＭＢＭＳユーザサービスコンテキストを利用し、「適応ノード」は、どのストリームまたはどのストリームグループが特定の下流側ノードに対して活性化／非活性化されるかを判定し、対応する手順を開始することができる。適応ノードが、サービスマネージャから、そのインターフェース上の能力が変化した（例えば、増加した）という情報を受信し、そして適応ノードから、下流側の資源をアップグレードする要求を受信した場合、適応ノードは、要求されたストリームを、利用可能にアップグレードされた能力に整合させ、要求元である下流側の適応ノードにそれを中継することができる。
【０１５５】
アップグレードされた能力に整合するストリームが適応ノードにおいて利用可能ではない場合（例えば、別の上流側の適応ノードによってフィルタリングされた場合）、適応ノードは要求を上流側に転送し、上流側の適応ノードのそれぞれにおける処理を繰り返すことができる（存在すれば）。これについては以下の章で説明する。
【０１５６】
ＭＢＭＳベアラの適応は、ＭＢＭＳユーザサービスコンテキストのパラメータをアップグレード、ダウングレード、あるいは多少なりとも変更する処理として規定することができる。適応は、いくつかの場合、例えば、移動端末（ＵＥ）が、ＲＮＣがホストする１つのセルから異なるＲＮＣがホストする別のものへ移動する場合、移動端末が継続ＭＢＭＳサービスの途中でサービスを受信することを要求した場合、または適応ノードが良かれ悪しかれ利用可能資源が変化したということを理解した場合に必要であろう。
【０１５７】
上述のように、２つのタイプの適応、すなわち第１に、サービスの初めの静的な適応（ＭＢＭＳセッション開始手順中の）と、サービス中に発生する動的適応とが考えられる。さらに、通常、適応は、ネットワーク内に１つまたは複数の適応ノードが存在する場合に実行することができる。
【０１５８】
図１２に、本発明の一実施形態によるＱｏＳアーキテクチャを示す。ネットワーク構成のＲＮＣとＳＧＳＮは適応ノードとして動作する。サービスは、ＱｏＳ１、ＱｏＳ２、ＱｏＳ３、ＱｏＳ４の各ＱｏＳ要件を有する４つの相異なるストリームを含む単一ベアラを介して提供される。ストリームの相互関係、すなわち４つのストリームが表す選択的ストリームの情報だけでなく、サービスの個別ストリームについてのこれらのＱｏＳ要件が、ＳＧＳＮおよびＲＮＣにおけるサービスセンターから下流側の適応ノードに提供される。すべての適応ノードは、下流側ノードに向かうインターフェースのＱｏＳ制約を提供するＱｏＳ管理機能であるサービスマネージャを含む。例えば、ＳＧＳＮ１のＱｏＳ管理機能は、ＲＮＣ１とＲＮＣ２へのリンクのＱｏＳ制約を示すことができる。
【０１５９】
ＱｏＳ管理機能によって提供されるこのＱｏＳ制約を使用することにより、適応ノードは、これらのＱｏＳ制約内で、下流側インターフェースのそれぞれを介して次の下流側ノードへ提供することができるストリームを選択することができる。
【０１６０】
例えば、ＳＧＳＮ１を再び考えると、ＱｏＳ管理機能は、例えば、ＲＮＣ１へのインターフェース上で、資源が、ＱｏＳ１とＱｏＳ３を有するストリーム１とストリーム３をそれぞれ転送するためだけには十分であるということを示すことができる。ＲＮＣ２へのインターフェース上で、資源は、ストリーム２、３、４（ＱｏＳ２、ＱｏＳ３、ＱｏＳ４をそれぞれ有する）の転送を許容する。したがって、ＳＧＳＮ１は、選択されたストリームを取得するためにＧＳＧＮからの多重化ストリームをフィルタリングし、次の下流側ノード、ここではＲＮＣ１とＲＮＣ２にそれらを転送する。
【０１６１】
以下では、２つ以上の適応ノード、例えばＲＮＣとＳＧＳＮが存在する一般的な場合の動的適応について説明する。
【０１６２】
例えば、ＭＢＭＳユーザサービスの適応を実行するために、適応ノードは、各適応ノードで提供されるＱｏＳ管理機能、すなわち上述のようなサービスマネージャとインターフェースすることができる。ＱｏＳ管理機能は、無線アクセスネットワークまたはコアネットワークの一部であるネットワークにおいて利用可能な資源を制御し、割り当て、監視する責任を負う。非特許文献１８には、このようなフレームワークの動作に関する詳細が記載されている。
【０１６３】
各適応ノードがＱｏＳ管理機能にアクセスすると仮定すると、各適応ノードは、そのネットワークインターフェースの能力または有用性の変化を知ることができる。これらの変化の例は、ＭＢＭＳサービスを提供する下流側ノードまたは上流側ノードに設定されるトンネルの数または能力の増加または減少であろう。この仮定の元に、継続セッション中に適応を実行するためにとり得るステップを、以下に紹介する。
【０１６４】
ハンドオーバの場合、すなわち移動端末が新しいセルの方へ移動している場合、そのＭＢＭＳ  ＵＥコンテキストは、このコンテキストが未だ存在していなければ、ハンドオーバの結果としての分散ツリーにおける新しいノード／枝において生成することができる。したがって、新しいセルの上流側ノードが分散ツリーの一部でない場合、ＵＥコンテキスト転送は、上記ステップ２において説明したようにＭＢＭＳ登録とコンテキスト生成をトリガすることができる。こうして、続くステップ３とステップ４で、新しい枝へのデータ伝送が行われる。
【０１６５】
１つまたは複数の下流側ノードがその能力を増加し、追加のユーザサービスのストリームを受信したいということを、（例えば、シグナリングによって）適応ノードが検出した場合、適応ノードは、拡張ＭＢＭＳベアラコンテキスト内のストリームの現在の状態を変更し、この更新された状態情報によりＭＢＭＳ登録要求を生成し、これを上流側の次のノードへ転送することができる。こうして、ローカル拡張ＭＢＭＳベアラコンテキストにおける変化は、受信する上流側の適応ノードがそのコンテキストと、必要ならばそれに応じてフィルタの設定を更新できるように、それぞれの適応ノードによって上流側に伝播される。
【０１６６】
必要な追加のストリームが、増加した有用性を検出した適応ノードに存在しないが、必要な追加のストリームが、増加した有用性を検出した適応ノードの上流側のノードに存在する場合、後者の適応ノードは、下流側ノードから受信した増加された資源を示すＭＢＭＳ登録要求を中継することができる。このメッセージは、要求された追加のストリームを転送することができる上流側ノードが見つかるまで上流側に中継される。そうでなければ、ストリームが利用可能ではないことを意味する否定のメッセージを、適応ノードにより送信することができる。
【０１６７】
同様の考察はサービスのダウングレードにも当てはまる。適応ノードは常に、ストリームをまずドロップし、それからその拡張ＭＢＭＳベアラコンテキストを更新し、例えばＭＢＭＳ登録要求を用いて、更新情報を上流側に伝播することができる。その要求に応答して受信された肯定的なＭＢＭＳ登録応答は、ストリームがすべての上流側ノードによりドロップされたということを示すものと考えられる。
【０１６８】
この要求を受信する上流側ノードのいずれか１つが、現在の転送状態においてストリームを保持すると判断した場合、否定応答メッセージをその要求に対して返すことができる。この場合、ストリームは、分散ツリーに沿ったそのノードの下流側の中間ノードにおいてのみドロップされる。この中間ノードは、ＭＢＭＳ登録要求の発信者を含む。
【０１６９】
本発明の別の実施形態によると、変化を下流側のネットワーク資源に伝送するために、以下のメッセージが適応ノードによって使用され得る（すなわち、上記ＭＢＭＳ登録およびセッション開始手順の過負荷バージョンまたは変更バージョンの代わりに）。ＭＢＭＳベアラアップグレード（ダウングレード）要求および応答メッセージが規定される。
【０１７０】
これらのメッセージは、適応ノードと上流側の適応ノードによって交換することができる。ＭＢＭＳベアラアップグレード（ダウングレード）要求は、上流側の適応ノードがその下流側の能力のアップグレード（ダウングレード）のいずれかを検出した場合に、上流側の適応ノードにより送信することができる。次に、この適応ノードは、現在の拡張ＭＢＭＳベアラコンテキストを考慮して、新たに提案する活性（非活性）ストリームの組を構成することができる。
【０１７１】
１．下流側からのＭＢＭＳベアラアップグレード（ダウングレード）要求を受信すると、メッセージを受信した各適応ノードは、その下流側の能力を変更して要求において示されたストリームを転送（ドロップ）できるかどうかを検査する。適応ノードが下流側の能力を増加して、要求されたストリームを転送することができる場合、肯定ＭＢＭＳベアラアップグレード応答を送信し、そして要求されたストリームを、下流側の要求元である適応ノードに提供することができる。
【０１７２】
２．上流側の適応ノードが要求されたストリームを有しないが、下流側の能力を割り当てる能力を有する場合、要求されたストリームを提供することができる適応ノード（この適応ノードは、ＢＭ−ＳＣとすることができるということに留意されたい）に到達するまで、ＭＢＭＳベアラアップグレード要求をさらに上流側に転送することができる。この場合、上記項目１における動作が繰り返される。
【０１７３】
３．上流側の適応ノードが要求されたストリームを有さず、および／または下流側の能力を割り当てる能力を有しない場合、この状況を示すＭＢＭＳユーザサービスアップグレード応答、例えば「不許可」が下流側に送信される。
【０１７４】
本発明の一実施形態による、リンク上で変化する資源に対する例示的な適応について、図１３と図１４を参照して説明する。単純化のために、ＲＮＣ１とＳＧＳＮ１の拡張ＭＢＭＳベアラコンテキストのみが示される。図１３に示す初期状態では、ＲＮＣ１は、ＱｏＳ管理機能から取得されたＱｏＳ制約内で、ＱｏＳ１を有するストリーム１のみを下流側のＢＳ１とＢＳ２に転送できると判断している。
【０１７５】
この情報はまた、ＳＧＳＮ１に伝送される。ストリーム２〜４はＲＮＣ１によりさらに下流側には配布されないので、ＳＧＳＮ１は、結果として、既にストリーム２〜４をドロップしている。この例では、ＲＮＣ１におけるＱｏＳ管理機能が、ＢＳ２へのインターフェース上の資源が著しく増加したことを示すものと仮定しているので、ＲＮＣ１は、ストリーム１と４（ＱｏＳ１とＱｏＳ４を含む）を、ＢＳ２に転送することができる。
【０１７６】
サービスを提供する多重化パケットストリーム内において、ストリーム４はＳＧＳＮ１から受信されないので、ストリーム４はＳＧＳＮ１において既に上流側でドロップされていると、ＲＮＣ１は判断する。したがって、ストリーム４（ＱｏＳ４を有する）をＲＮＣ１に転送することを要求するためのアップグレード要求が、ＲＮＣ１からＳＧＳＮ１に送信される。
【０１７７】
この要求を受信すると、ＳＧＳＮ１は、ＲＮＣ１にストリーム１と４を転送するのに十分な資源が利用可能か否かを判断するために、ＲＮＣ１へのインターフェースに関するＱｏＳ制約をそのＱｏＳ管理機能から取得する。資源が利用可能であれば、ＳＧＳＮ１はそのようにし、図１４に示すようにその拡張ＭＢＭＳベアラコンテキストを更新することができる。さらに、この要求が許可されたという通知を受信し、あるいはＳＧＳＮ１から受信された多重化パケットストリーム内に（新しい）ストリーム４が存在することを検出すると、ＲＮＣ１はまた、その拡張ＭＢＭＳベアラコンテキストを更新し、ストリーム１と４をＢＳ２へ転送することができる。この最終状態を図１４に示す。
【０１７８】
本発明の別の実施形態によると、要求を拒否した上流側の適応ノードが肯定的なＭＢＭＳベアラアップグレード応答を同じ元々の要求に対して送信する場合、ＭＢＭＳベアラアップグレード要求の発信者は、新しい要求を１回だけ発行することができる。この動作は、要求送信と否定応答送信との揺らぎを回避するのに利用可能である。要求を初めに拒否した上流側ノードに後でその更新を許可する応答メッセージを送信することを許容するために、その上流側ノードはその要求を格納し、利用可能な資源の変化によりアップグレードが可能になったか否かを監視することができる。
【０１７９】
ストリームまたは複数のストリームをドロップする、すなわちダウングレードを実行することについて、原理は上記概説したアップグレードの場合と同様であり、適応ノードは選択されたストリームをまずドロップし、次に、上流側にＭＢＭＳベアラダウングレード要求を送信することができる。肯定的な応答は、すべての上流側ノードがストリームをドロップしたことを示し、否定的な応答は、少なくとも１つの上流側ノードがそうしないことを決定したことを示す。
【０１８０】
ＭＢＭＳブロードキャストサービスのための適応型かつスケーラブルなＱｏＳアーキテクチャ
上術のこれまでの実施形態では、マルチキャストサービスのためのＱｏＳアーキテクチャについて説明してきた。以下の節では、ブロードキャストサービス配送に関する課題に対処するために、このアーキテクチャの適応性について説明する。ブロードキャストモードは、ブロードキャストサービス領域における単一ソースエンティティからすべてのユーザへのマルチメディアデータ（例えば、テキスト、音声、画像、映像）の単方向性のポイントツーマルチポイントの伝送として規定することができる。ブロードキャストモードは、無線／ネットワーク資源を効率的に使用することを目的とし、例えば、データは共通の無線チャネルを通じて送信される。データは、ネットワーク（家庭環境）により規定されるブロードキャストサービス領域において送信される。
【０１８１】
マルチキャスト／ブロードキャストサービスでは、データ伝送は、例えばＭＢＭＳデータのビットレートを低減することにより、様々なＲＡＮ能力または様々な無線リソースの有用性に適応することができる。
【０１８２】
移動端末により受信されるブロードキャストサービスは、１つまたは複数の連続ブロードキャストセッションを含むことができる。ブロードキャストサービスは、例えば、単一の継続セッション（例えば、メディアストリーム）から構成されてもよいし、あるいは長期間にわたるいくつかの断続的なセッション（例えば、メッセージ）を含んでもよい。
【０１８３】
ブロードキャストサービスがどのようにして、変化するネットワーク状態および無線状態に適応することができるかが明らかになる。適応を可能にするために、上記マルチキャストサービスについて説明した我々の提案のアーキテクチャが拡張される。
【０１８４】
しかし、マルチキャストＭＢＭＳサービスとブロードキャストＭＢＭＳサービスとの間には根本的な差異がある。ＭＢＭＳブロードキャストサービスにおいては、移動端末の予約も加入もない。ブロードキャストセッション開始手順は、移動端末のサービスの起動とは独立に開始される。すなわち、セッションの開始は、ＢＭ−ＳＣがデータ送信の準備ができた時点でよい。セッション開始は、ユーザによるサービス起動とは独立して発生することができる。すなわち、与えられたユーザは、セッションの開始の前または後にサービスを起動することができる。セッション開始は、実際には、ベアラ資源ブロードキャスト／マルチキャストデータ転送の設定および予約をトリガする。
【０１８５】
ユーザは、ブロードキャストサービス受信の起動を判断する。例えば、移動端末（ＵＥ）によるＭＢＭＳブロードキャストサービスの非活性化は、移動端末に独特なものであり、ＵＴＲＡＮとの相互作用なしで実行することができる。端末におけるサービスの起動について必要とされるネットワークとの相互作用はないので、ＭＢＭＳブロードキャストのＭＢＭＳ起動手順もなく、したがってＭＢＭＳ登録手順はない。
【０１８６】
ＭＢＭＳブロードキャストサービスのＭＢＭＳベアラコンテキストは、ＭＢＭＳブロードキャストセッション開始手順によって直接生成される。したがって、このアーキテクチャをブロードキャストの場合に拡張するために、本発明のこの実施形態によると、ＭＢＭＳブロードキャストセッション開始メッセージは、上記拡張ＭＢＭＳベアラコンテキスト（表１、２．１、２．２、３．１、３．２、４．１、４．２を参照）を生成するために必要な情報が、変更されたＭＢＭＳブロードキャストセッション開始メッセージに含まれるという点において拡張される。
【０１８７】
上記から明らかになったように、ＭＢＭＳブロードキャストを考慮する際にＭＢＭＳ登録手順は存在しないため、適応ノードにおいて拡張コンテキストを設定するためにこの手順を用いる可能性はない。拡張ＭＢＭＳブロードキャストセッション開始メッセージを使用する代わりに、追加のメッセージまたは追加の手順もまた、適応ノードにおいて拡張ＭＢＭＳベアラコンテキストを設定するために必要な情報を伝送するために規定されなければならないであろう。
【０１８８】
それ以外は、マルチキャストサービスを参照して上に概説したのと同じ適応能力がブロードキャストサービスに適用される。したがって、本発明のこの実施形態によると、適応ノード内で拡張ＭＢＭＳベアラコンテキストを使用すること、および単一無線ベアラのトランスポートチャネルを介して提供される多重化パケットストリームをフィルタにかけることにより除去するのに必要なフィルタリング能力を適応ノードに備えることについての原理を、ブロードキャストサービスにも適用する。
【０１８９】
進化したＵＴＲＡＮにおけるスケーラブルで適応型のＱｏＳアーキテクチャ
将来のＵＴＲＡＮアーキテクチャは、さらに多くのインテリジェンス（拡張制御および管理機能）の提供がネットワークの端まで、例えばノードＢ（基地局）までさらに押し進められることを想定する。これを行う１つの理由は、ＲＮＣが現在影響を及ぼしている単一点（ｓｉｎｇｌｅ  ｐｏｉｎｔ）障害を取り除くことである。この将来のＵＴＲＡＮアーキテクチャは、上記様々な実施形態による適応型ＱｏＳアーキテクチャを完全に取り込むことができるということに留意すべきである。
【０１９０】
上に概説した原理を利用するために、ＭＢＭＳベアラコンテキストは、新しいノードに、そおよび適応ノード、例えば新しいＵＴＲＡＮアーキテクチャのノードＢ＋として動作するノード内のＭＢＭＳユーザサービスコンテキストにおいて、それに応じて複製することができる。他の機能と要件は、上の章において概説したものと同様である。
【０１９１】
本発明の別の実施形態は、ハードウェアとソフトウェアを使用することにより上述の様々な実施形態を実施することに関する。上記様々な論理ブロック、モジュール、回路および上記様々な方法は、例えば、汎用プロセッサ、デジタル信号プロセッサ（ＤＳＰ）、特定用途向けＩＣ（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、または他のプログラマブルロジックデバイス等の演算装置を使用することにより、実施または実行することができるということが理解される。本発明の様々な実施形態は、また、これらの装置の組み合わせにより実行または具現化することができる。
【０１９２】
さらに、本発明の様々な実施形態はまた、プロセッサにより、またはハードウェアで直接実行されるソフトウェアモジュールによって実施することができる。また、ソフトウェアモジュールとハードウェア実装とを組み合わせることが可能である。上記ソフトウェアモジュールは、例えば、ＲＡＭ、ＥＰＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリ、レジスタ、ハードディスク、ＣＤ−ＲＯＭ、ＤＶＤ等の任意のタイプのコンピュータ読取り可能な記憶媒体上に格納することができる。
【図面の簡単な説明】
【０１９３】
【図１】ＵＭＴＳのＱｏＳアーキテクチャの概要を示す図
【図２】本発明の様々な実施形態による代替的なパケットストリームをフィルタリングする適応ノード（例えばＲＮＣ）を示す図
【図３】本発明の様々な実施形態による選択的なパケットストリームをフィルタリングする適応ノード（例えばＲＮＣ）を示す図
【図４】本発明の様々な実施形態による階層的なパケットストリームをフィルタリングする適応ノード（例えばＲＮＣ）を示す図
【図５】３ＧＰＰ  ＭＢＭＳアーキテクチャのユーザプレーンプロトコルスタックを示す図
【図６】３ＧＰＰ  ＭＢＭＳアーキテクチャの制御プレーンプロトコルスタックを示す図
【図７】本発明の様々な実施形態によるＩＰヘッダのＵＤＰポート番号に基づいてパケットストリームをフィルタリングする適応ノード（例えばＲＮＣ）を示す図
【図８】本発明の様々な実施形態によるＩＰヘッダのＴＯＳ領域に基づいてパケットストリームをフィルタリングする適応ノード（例えばＲＮＣ）を示す図
【図９】ＭＢＭＳの起動手順のメッセージシーケンスを示す図
【図１０】ＧＴＰ−Ｃ  ＭＢＭＳセッション開始要求メッセージを示す図
【図１１】ＧＴＰ−Ｃ  ＭＢＭＳ登録要求メッセージを示す図
【図１２】本発明の一実施形態による単一ベアラのＱｏＳアーキテクチャを示す図
【図１３】変化するネットワーク資源への適応を実行する前における本発明の一実施形態による単一ベアラのＱｏＳアーキテクチャの分散ツリーを示す図
【図１４】変化するネットワーク資源への適応を実行した後における本発明の一実施形態による単一ベアラのＱｏＳアーキテクチャの分散ツリーを示す図
【図１５】制御プレーンにおけるＵＭＴＳベアラサービスのＱｏＳ管理機能を示す図
【図１６】ＭＢＭＳ標準によるＭＢＭＳ登録手順を示す図
【図１】
2008503945.tif 000007
【図２】
2008503945.tif 000008
【図３】
2008503945.tif 000009
【図４】
2008503945.tif 000010
【図５】
2008503945.tif 000011
【図６】
2008503945.tif 000012
【図７】
2008503945.tif 000013
【図８】
2008503945.tif 000014
【図９】
2008503945.tif 000015
【図１０】
2008503945.tif 000016
【図１１】
2008503945.tif 000017
【図１２】
2008503945.tif 000018
【図１３】
2008503945.tif 000019
【図１４】
2008503945.tif 000020
【図１５】
2008503945.tif 000021
【図１６】
2008503945.tif 000022
【国際調査報告】
2008503945.tif 000023
2008503945.tif 000024
2008503945.tif 000025
2008503945.tif 000026