JP5443449B2 - マルチベアラサービスを介したマルチキャストサービス／ブロードキャストサービスのための適応型かつスケーラブルなＱｏＳアーキテクチャ - Google Patents

Description

本発明は、コアネットワークまたは移動体通信システムの無線アクセスネットワークのネットワークエンティティにおいて、単一ユーザサービスに属するストリームをフィルタリングする方法に関する。それぞれが個別のベアラサービスにより伝送されるパケットストリームは、マルチキャストユーザサービスまたはブロードキャストユーザサービスを提供し、ネットワークエンティティを介して、サービスセンターから移動端末に配送される。さらに、ネットワークエンティティは、サービス品質管理機能を提供するサービス管理を含む。本発明はさらに、フィルタリング能力を備えたネットワークエンティティと、このネットワークエンティティを含む通信システムとに関する。

符号化技術における最近の進歩により、ブロードキャスト／マルチキャストサービスのデータを、例えば代替的（サイマルキャスト）または選択的（階層化マルチキャスト）に、複数のストリーム上に伝送することが可能となった。このような手法は、マルチキャスト通信において、きめの粗い（ｃｏａｒｓｅ−ｇｒａｉｎｅｄ）品質の適応を可能にするインターネット社会の注目を集め、複数の研究がこの手法に基礎を置いている。例えば、ＤｉｆｆＳｅｒｖｅ（Ｄｉｆｆｅｒｅｎｔｉａｔｅｄ Ｓｅｒｖｉｃｅｓ：非特許文献１、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) MBMS Session Start procedure in section 8.3 of 3GPP TS 23.246 Section 6.2 of 3GPP TS 23.107 "Video Transcoding Architectures and Techniques: An Overview" by A. Vetro et al., (IEEE Signal Processing Magazine, March 2003 Yong et al., "VBR transport of CBR-encoded video over ATM networks," in Proc. 6th Int. Workshop Packet Video, Portland, OR, Sept. 1994 Lin et al., "Efficient FGS-to-single layer transcoding," in Proc. IEEE Int. Conf. Consumer Electronics, Los Angeles, CA, June 2002, pp. 134-135

本発明の目的は、多数のユーザに対しスケーラブルな、適応型のマルチメディアブロードキャスト／マルチキャストサービスＱｏＳアーキテクチャを提供することである。別の目的は、異種の端末に対処することができるブロードキャスト／マルチキャストサービスＱｏＳアーキテクチャを提供することである。さらに別の目的は、変化するネットワーク状態への適応を可能にするアーキテクチャを設計することである。

この目的は、独立請求項の主題により解決される。本発明の有利な実施態様は従属請求項の主題である。

本発明の一実施態様によると、少なくとも１つのネットワークエンティティを介してサービスセンターから移動端末にマルチキャストサービスまたはブロードキャストサービスを提供する方法が提供される。ここでは、マルチキャストサービスまたはブロードキャストサービスは、それぞれが単一ベアラサービスを介して伝送される複数のパケットストリームの形式で提供される。ネットワークエンティティは、サービス品質管理機能を提供するサービスマネージャを含むことができる。

ネットワークエンティティは、マルチキャストサービスまたはブロードキャストサービスに属するベアラサービスと、ベアラサービスにより伝送されたパケットストリームおよび／またはそのパケットストリームの組合せにより必要とされるサービス品質属性とを示す情報を受信して、受信した情報を含むサービスコンテキストを設定することができる。

さらに、ネットワークエンティティは、サービス品質管理機能から、ネットワークエンティティの下流側のインターフェース毎における下流側データ伝送のために利用可能なサービス品質を示すサービス品質制約を取得することができる。サービスコンテキスト内に格納されたサービス品質属性に基づいて、ネットワークエンティティは、取得したサービス品質制約内でそのストリームを伝送可能なベアラサービスを、マルチキャストサービスまたはブロードキャストサービスに属するベアラサービスから選択することができる。

さらに、ネットワークエンティティは、選択したベアラサービスの少なくとも一部を、ベアラサービス毎にネットワークエンティティと上流側ネットワークエンティティとの間のリンクが確立されるように設定することができる。ネットワークエンティティは、設定した各ベアラサービスのパケットストリームを、それぞれのリンクを介して移動端末へ転送することができる。

別の実施態様では、選択したベアラサービスの少なくとも一部を設定するステップは、選択したベアラサービスを登録するための登録要求を、上流側ネットワークエンティティまたはサービスセンターに送信するステップと、ネットワークエンティティまたはサービスセンターから、登録が成功したベアラサービスを示す登録応答メッセージを受信するステップとを含むことができる。さらに、選択したベアラサービスの少なくとも一部を設定するステップは、登録が成功したベアラサービス毎に、ネットワークエンティティと上流側ネットワークエンティティとの間のリンクを設定するステップと、設定した各リンクを介して、それぞれ登録済みのベアラサービスのパケットストリームを受信するステップとを含むことができる。

ここで、本発明のこの実施態様によれば、例えばリンクを設定することによる実際のリソース割り当ては、ネットワーク資源がサービスの特定のストリームの提供を許容した場合にだけ実行することができることに注意することは重要である。したがって、ストリームの提供に介在するベアラサービスのコンテキスト情報はネットワークエンティティに存在し得るが、ストリーム／ベアラサービスに属する実際のデータパケットを提供するための資源は、ネットワーク状態が許容する場合のみ予約され割り当てられる。本発明の一実施態様によれば、ベアラサービスは、そのベアラサービスに対応するストリームがサービスセンターにより送信される限り、「設定された」と見なされる。これは、このようなストリームが、下流ノード、すなわちベアラサービスのためのリンクが設定されたノードのすべてまたはサブセットに到達したことを意味すると考えられる。

別の実施態様は、下流側インターフェース毎に、マルチキャストサービスまたはブロードキャストサービスに属するベアラサービスのそれぞれの転送状態を、サービスコンテキスト内に格納するステップを包む。これにより、例えば、ネットワークエンティティは、ベアラサービスのストリームを受信したインターフェースと受信しなかったインターフェースのそれぞれにおける下流側ネットワークエンティティを追跡することができる。

本発明の別の実施態様は、サービスレベルがアップグレードされる、すなわちサービス品質制約が緩和する状況に関する。ネットワークエンティティは、下流側ネットワークエンティティからベアラサービスの登録要求を受信することができる。このサービスコンテキストに基づいて、ネットワークエンティティは、要求されたベアラサービスのパケットストリームがネットワークエンティティにより受信されたか否かを判定することができる。受信されたならば、ネットワークエンティティは、要求元である下流側ネットワークエンティティに、要求されたベアラサービスの登録が成功したことを示す登録応答メッセージを送信することができる。

この実施態様の変形では、登録応答メッセージが登録の成功を示す場合、ネットワークエンティティは、ネットワークエンティティと要求元である下流側ネットワークエンティティとの間に、要求されたベアラサービスのパケットストリームを転送するためのリンクを設定することができる。

要求されたベアラサービスのパケットストリームがネットワークエンティティにより受信されていないとネットワークエンティティが判定した場合、ネットワークエンティティは、上流側ネットワークエンティティまたはサービスセンターに、ベアラサービスの登録要求を送信することができる。それに応答して、ネットワークエンティティは、上流側ネットワークエンティティまたはサービスセンターから、要求された少なくとも１つのベアラサービスの登録が成功したか否かを示す登録応答メッセージを受信することができる。

この実施態様の別の変形では、登録応答メッセージが登録の成功を示す場合、ネットワークエンティティは、ネットワークエンティティと上流側ネットワークまたはサービスセンターとの間に、要求されたベアラサービスのパケットストリームを転送するためのリンクを設定することができ、要求元である下流側ネットワークエンティティに、要求されたベアラサービスの登録が成功したことを示す登録応答メッセージを送信することができる。

本発明の別の実施態様は、下流のサービス品質制約の変化を検知するネットワークエンティティに関する。ネットワークは、上流側ネットワークエンティティまたはサービスセンターに、ベアラサービスの登録要求を送信し、上流側ネットワークエンティティまたはサービスセンターから、要求されたベアラサービスの登録が成功したか否かを示す登録応答メッセージを受信することができる。

この実施態様の変形では、登録応答メッセージが登録の成功を示す場合、ネットワークは、ネットワークエンティティと要求元である上流側ネットワークエンティティまたはサービスセンターとの間に、要求されたベアラサービスのパケットストリームを転送するためのリンクを設定することができる。

本発明の別の実施態様では、ネットワークエンティティに保持されたサービスコンテキストを、受信した登録応答メッセージに基づいて更新することができる。

本発明の別の実施態様は、サービス品質管理機能からレポートされるサービス品質制約の変化への適応を可能にする。この実施態様によると、ネットワークエンティティは、下流側ネットワークエンティティからベアラサービスの登録解除要求を受信することができる。ネットワークエンティティは、要求元である下流側ネットワークエンティティとネットワークエンティティとの間のベアラサービスのために設定されたリンクを解除することができ、ベアラサービスのストリームが要求元である下流側ネットワークエンティティにもはや転送されないということを示すために、サービスコンテキストを更新することができる。

この実施態様の変形では、ネットワークエンティティは、さらに要求元である下流側ネットワークエンティティ以外の別の下流側ネットワークエンティティがネットワークエンティティへのベアラサービスのためのリンクを保持するか否かを判定することができ、保持しなければ、上流側ネットワークエンティティまたはサービスセンターにベアラサービスの登録解除要求を送信することができる。これにより、未使用リンクによる不要な資源予約を回避することができる。

別の実施態様では、ネットワークエンティティは、上流側ネットワークエンティティまたはサービスセンターにベアラサービスの登録解除要求を送信することができ、サービスコンテキストを更新してベアラサービスのストリームが下流側ネットワークエンティティまたは移動端末の下流側にもはや転送されないことを示すことができる。これは、例えば、ネットワークエンティティが下流側のサービス品質制約の変化を検出する状況において適用可能であろう。

別の実施態様では、ネットワークエンティティは、サービス品質管理機能を有する無線アクセスネットワークのエンティティ、またはサービス品質管理機能を有するコアネットワークのエンティティとすることができる。

さらに、本発明の別の実施態様では、ネットワークエンティティが、選択された少なくとも１つのストリームを、サービス品質管理機能から取得されたサービス品質制約内で伝送可能なストリームに変換することができる。この変換は、例えば、ストリームのビットレートを変換すること、コーデックタイプを変換すること、空間的分解能または時間的分解能を変換すること、複数層ストリームから単一層ストリームに変換すること、一定ビットレートストリームから可変ビットレートストリームに変換すること、および可変ビットレートストリームから一定ビットレートストリームに変換することのうち、少なくとも１つを含む。

本発明の別の実施態様によると、マルチキャストサービスまたはブロードキャストサービスがサービスセンターから移動端末へ提供されるネットワークエンティティが開示される。マルチキャストサービスまたはブロードキャストサービスは、それぞれが単一ベアラサービスを介して伝送される複数のパケットストリームの形式で提供することができる。ネットワークエンティティは、サービス品質管理機能を提供するサービスマネージャと、マルチキャストサービスまたはブロードキャストサービスに属するベアラサービスと、ベアラサービスにより伝送されるパケットストリームおよび／またはそのパケットストリームの組合せにより必要とされるサービス品質属性とを示す情報を受信する受信手段とを含むことができる。

さらに、ネットワークエンティティは、受信した情報を含むサービスコンテキストを設定する手段と、サービス品質管理機能から、ネットワークエンティティの下流側のインターフェース毎における下流側データ伝送のために利用可能なサービス品質を示すサービス品質制約を取得する手段と、サービスコンテキスト内に格納されたサービス品質属性に基づいて、マルチキャストサービスまたはブロードキャストサービスに属するベアラサービスから、取得したサービス品質制約内でそのストリームを伝送可能なベアラサービスを選択する手段とを含むことができる。

ネットワークエンティティはさらに、選択したベアラサービスの少なくとも一部を、ベアラサービス毎にネットワークエンティティと上流側ネットワークエンティティとの間のリンクが確立されるように設定する手段と、設定した各ベアラサービスのパケットストリームを、それぞれのリンクを介して移動端末へ転送する送信手段とを含むことができる。

この実施態様の変形では、ネットワークエンティティはさらに、上記様々な実施態様による方法のステップを実行するように適合された手段を含むことができる。

本発明の別の実施態様は移動通信システムに関する。この通信システムは、サービスセンターと、マルチキャストサービスまたはブロードキャストサービスを受信する少なくとも１つの移動端末と、上述した少なくとも１つのネットワークエンティティとを含むことができる。

さらに、一実施態様は、プロセッサにより実行されると、このプロセッサに、少なくとも１つのネットワークエンティティを介してサービスセンターから移動端末にマルチキャストサービスまたはブロードキャストサービスを提供させる命令を格納するためのコンピュータ読み取り可能な媒体を提供する。この媒体では、マルチキャストサービスまたはブロードキャストサービスは、それぞれが単一ベアラサービスを介して伝送される複数のパケットストリームの形式で提供され、ネットワークエンティティは、マルチキャストサービスまたはブロードキャストサービスに属するベアラサービスと、ベアラサービスにより伝送されるパケットストリームおよび／またはそのパケットストリームの組合せにより必要とされるサービス品質属性とを示す情報を受信して、受信した情報を含むサービスコンテキストを設定し、サービス品質管理機能から、ネットワークエンティティの下流側のインターフェース毎における下流側データ伝送のために利用可能なサービス品質を示すサービス品質制約を取得し、サービスコンテキスト内に格納されたサービス品質属性に基づいて、マルチキャストサービスまたはブロードキャストサービスに属するベアラサービスから、取得したサービス品質制約内でそのストリームを伝送可能なベアラサービスを選択し、選択したベアラサービスの少なくとも一部を、ベアラサービス毎にネットワークエンティティと上流側ネットワークエンティティとの間のリンクが確立されるように設定し、設定した各ベアラサービスのパケットストリームを、それぞれのリンクを介して移動端末へ転送することによりサービス品質管理機能を提供するサービスマネージャを含む。

一変形では、上記コンピュータ読取り可能な媒体は、プロセッサにより実行されると、上記様々な実施態様のいずれか１つによる方法のステップをこのプロセッサに実行させる命令をさらに格納することができる。

以下、添付図面を参照して本発明をさらに詳細に説明する。各図面における同様なまたは対応する詳細部には同じ参照符号が付与される。

ＵＭＴＳのＱｏＳアーキテクチャの概観を示す図 ３ＧＰＰ ＭＢＭＳアーキテクチャのユーザプレーンプロトコルスタックを示す図 ３ＧＰＰ ＭＢＭＳアーキテクチャの制御プレーンプロトコルスタックを示す図 ＧＴＰ−Ｃ ＭＢＭＳセッション開始要求メッセージを示す図 ＧＴＰ−Ｃ ＭＢＭＳ登録要求メッセージを示す図 変化するネットワーク資源への適応を実行する前における本発明の一実施の形態によるマルチベアラＱｏＳアーキテクチャの分散ツリーを示す図 変化するネットワーク資源への適応を実行した後における本発明の一実施の形態によるマルチベアラＱｏＳアーキテクチャの分散ツリーを示す図 本発明の一実施の形態による複数ベアラＱｏＳアーキテクチャを示す図 制御プレーンにおけるＵＭＴＳベアラサービスのためのＱｏＳ管理機能を示す図 ＭＢＭＳ標準によるＭＢＭＳ登録手順を示す図

以下の段落では、本発明の様々な実施形態が説明される。例示的な目的のみのため、大部分の実施形態はＵＭＴＳ通信システムに関連して概説され、以降の節で使用される用語は主にＵＭＴＳ用語に関連する。但し、使用される用語と、ＵＭＴＳアーキテクチャに関する実施形態の説明は、本発明の原理と概念をこれらのシステムに限定するように意図するものではない。

また、上述の背景技術に記載の詳細説明は、以下に説明される主としてＵＭＴＳ特有の例示的な実施形態をよりよく理解することのみを意図しており、本発明を、説明する移動通信ネットワークにおける処理と機能の特定の実施形態に限定するものとして理解すべきではない。

本発明は、主に帯域幅要件とそれぞれのＱｏＳ適応に関して説明されることにさらに留意されたい。しかし、ＱｏＳの識別および適応もまた、他の任意のＱｏＳパラメータ、例えば損失率やパラメータの組合せに適用することができる。

拡張マルチキャスト／ブロードキャストサービスアーキテクチャの設計面
本発明の上記目的を解決するマルチキャスト／ブロードキャストサービスアーキテクチャを設計する際、次の側面を考慮することができる。

http://www.3gpp.orgで入手可能な非特許文献１０および非特許文献１１に規定されるＭＢＭＳアーキテクチャは実用化が近い。速やかにかつ広範囲に配置することを考えると、拡張マルチキャスト／ブロードキャストサービスアーキテクチャは、そのアーキテクチャ仕様に従って、合理的な範囲に限りこの仕様と異なるとよい。したがって、ネットワークノード間のＱｏＳのネゴシエーションは回避され、シグナリングとフィルタリングに関して生成されるオーバーヘッドはできるだけ小さく保たれる。

さらに、拡張マルチキャスト／ブロードキャストサービスアーキテクチャを設計する際の別の態様は、コンテンツの適応化に対する広範な可能性を網羅することである。例えば、入手可能な適応型メディアコーデックを取り扱ってもよく、将来の拡張のためのフレームワークを設けてもよい。

現在のＭＢＭＳアーキテクチャの限界を克服するためにとり得る手法の一つは、適応型メディアコーデックを使用することであろう。適応型メディアコーデックの例は、ＭＰＥＧ２またはＭＰＥＧ４のような階層型コーデックである。これらのコーデックは、通常、最下位層が最も重要な層となる（少なくとも）２つ以上の層におけるメディア情報を符号化する。続く（上位）層は前の（下位）層に依存する。

コンテンツはまた、例えば、様々な帯域幅要件または様々なエラー強度を有する代替ストリームを提供することができるＭＰＥＧ−１符号器を使用することにより、複数の独立した表現で符号化することができる。

適応型メディアコーデックの別の例は、複数記述コーデック（ＭＤＣ）の類である。このタイプの符号化では、コンテンツはいくつかの捕捉的な層において符号化される。すなわち、基本層および前の層への依存の概念は消える。特に、受信されるＭＤＣ符号化パケットの数が多いほど、得られる品質は高くなる。

別の設計留意点はＲＡＮ（無線アクセスネットワーク）資源の有用性であろう。先に概説したように、一般性を失わずに、ＲＡＮは通常、トランスポートベアラの設定が乏しい無線リソースによるボトルネックを意味し得る基幹システム（ｃｒｉｔｉｃａｌ ｓｙｓｔｅｍ）と見なすことができる。したがって、拡張マルチキャスト／ブロードキャストサービスアーキテクチャは、無線ネットワーク制御装置において適応機能を考慮することができる。

エンドノードの移動性のために、分散ツリーはセッション継続中に変化し得る。最終的に、拡張マルチキャスト／ブロードキャストサービスアーキテクチャは、セッション開始時と、例えばハンドオーバでのセッション中との双方における適応を可能にする。

拡張マルチキャスト／ブロードキャストサービスアーキテクチャの別の可能な設計態様は、ネットワークおよび無線構成要素において変化する状況に対する適応性を提供することである。ＭＢＭＳデータは、多くのＲＮＣと多くのＳＧＳＮを通過することができるＭＢＭＳ分散ツリーを介して、複数のユーザに配布することができる。

これにより、ユーザの観点からは、単一のＭＢＭＳサービスを含む様々なメディア構成要素が、構成要素毎のＱｏＳ識別を可能にする別々のＧＴＰ（ＧＰＲＳトンネリングプロトコル）トンネル（ＧＧＳＮ＜−＞ＳＧＳＮ，ＳＧＳＮ＜−＞ＲＮＣ、図２参照）および無線ベアラ（ＲＮＣ＜−＞ＵＥ）を通じて提供することができる。したがって、拡張マルチキャスト／ブロードキャストサービスアーキテクチャは、無線アクセスネットワークとコアネットワークの双方においてＱｏＳ問題に取り組むことができる。

特定のネットワークのＱｏＳを実現するために、明確に定義された特性と機能を有するベアラサービス（例えば、ＵＭＴＳ／ＭＢＭＳベアラ）を、ソースからユーザサービス（例えば、マルチキャストサービスまたはブロードキャストサービス）の宛先まで設定することができる。ベアラサービスは、縮められたＱｏＳの提供を可能にするすべての態様を含む。これらの態様は、制御シグナリング、ユーザプレーントランスポート、およびＱｏＳ管理機能である。図１に、ＵＭＴＳベアラサービス階層化ＱｏＳアーキテクチャを示す。特定層の各ベアラサービスは、下位層により提供されるサービスを利用して、個々のサービスを提供する。

特定のＱｏＳを有するＵＭＴＳベアラサービスを特定し、設定し、変更し、保持するために必要なノード（ＧＧＳＮ、ＳＧＳＮ、ＲＮＣ等）間における機能の特定の関係は、実施形態に固有であってよい。このことは、ＤｉｆｆＳｅｒｖ、ＩｎｔＳｅｒｖ(非特許文献１２を参照）、ＲＳＶＰ、またはＭＰＬＳ等のいくつかの技術を使用できるということを意味する。

ＵＭＴＳの例を考えると、これらの機能のＵＭＴＳエンティティへの割り当ては、これらのエンティティが、ＵＭＴＳベアラサービスに対してネゴシエーションされたＱｏＳコミットメントを実施できることを意味する。これらの機能の具体的な実現は実施形態に依存するが、特定されたＱｏＳ特性を維持さえできればよい。すべてのＵＭＴＳエンティティのＱｏＳ管理機能は、連携して、ＵＭＴＳベアラサービスのアクセスポイント間でネゴシエーションされたサービスの提供を保証することができる。

新しい拡張マルチキャスト／ブロードキャストサービスアーキテクチャを設定することについては、非特許文献１３に記載されるサービスマネージャの機能は特に興味深い。サービスマネージャは、責任を負うサービスを設定し、変更し、保持するための制御プレーン（例えば、ＭＢＭＳベアラコンテキスト）の機能を調整する（図９を参照）。サービスマネージャはさらに、関連する属性（例えば、保証ビットレート、最大ビットレート、最大パケットサイズ、損失率等）をすべてのユーザプレーンＱｏＳ管理機能に提供する。

サービスマネージャはさらに、他のインスタンス（例えば、ＭＢＭＳベアラコンテキスト管理機能）にサービスを提供し、ピアサービスマネージャによりシグナリングし、他のインスタンスによって提供されるサービスを利用することができる。サービスマネージャはさらに、より下位の層のサービスを要求するために、属性変換（例えば、アプリケーションパケット損失率からＲＬＣ ＳＤＵ損失率へ、ＳＤＵ損失率から層１／層２ブロック誤り率へ）を実行することができる。さらに、サービス提供の許可を受信するために他の制御機能に問い合わせることができる。

したがって、このようなインフラが提供されることと、ＭＢＭＳベアラとＱｏＳ管理機能との間の相互作用が付与されることを仮定してよい。これにより、どのようにしてユーザが利用可能な資源を利用するか、および他の予知できない事象に関する不確実性のために本質的に異なり得るネットワーク（ＣＮ）状態と無線アクセスネットワーク状態の双方を、ＭＢＭＳサービスのコンテキスト管理機能に知らせることが可能となる。

例えば、後者の具体例は典型的なフラッシュクラウド現象であり、ここでは特定のサーバおよび関連するネットワークセグメントがユーザ要求により混み過ぎてしまう（ｏｖｅｒｌｏａｄｅｄ）。別の例は、経路上の一部ノードの故障、あるいはどれだけのユーザが３ＧＰＰ ＰＳＳのようなユニキャストサービスに加わるかに関する不確実性であろう。

さらに、拡張マルチキャスト／ブロードキャストサービスアーキテクチャを設計する際の別の態様は、マルチキャスト／ブロードキャストサービスのネットワーク駆動型適応（ｎｅｔｗｏｒｋ−ｄｒｉｖｅｎ ａｄａｐｔａｔｉｏｎ）を可能にすることである。現在のＭＢＭＳアーキテクチャでは、ＭＢＭＳユーザは通常、セッション配送の詳細をサーバ（例えば、ＢＭ−ＳＣ）とネゴシエーションする機会はほとんどないか全くないであろう。ここが、ネットワーク駆動型適応が重要になる点である。

拡張マルチキャスト／ブロードキャストサービスアーキテクチャ
本発明の一実施形態によれば、ＭＢＭＳ伝送サービスとＭＢＭＳユーザサービスの概念が拡張される。マルチキャストサービスまたはブロードキャストサービス（例えば、ＭＢＭＳサービス）を提供するためのマルチベアラサービス（例えば、ＭＢＭＳベアラ）を利用する手法を検討する。ＱｏＳアーキテクチャは、ユーザサービスのストリーム／ベアラの識別がネットワークノード（ネットワークエンティティ）において可能になるように拡張される。このようにして、変化する資源、異種の端末、および様々なネットワーク構成要素へのネットワーク駆動型適応は、この情報を用いることにより可能となる。

この手法によれば、ＭＢＭＳユーザサービスコンテキスト形式の追加の状態情報が導入される。ＭＢＭＳユーザサービスコンテキストは、サービスを含むベアラに対する参照子を格納する。さらに、適応ノードがダウンリンク能力、例えば下流側のＱｏＳ制約に従ってベアラの活性化／不活性化を実行できるように、ベアラ間の関係を規定するベアラ関連情報を格納することができる。

例示的な目的のためだけに以下で検討するＭＢＭＳサービスの時系列（ｔｉｍｅｌｉｎｅ）は、次のようになるであろう。データプレーンにおいては、要求されたマルチメディアブロードキャストまたはマルチキャストサービスのための選択的／代替的／補捉的ストリームは、ＱｏＳ要件（制約）が中間ネットワークエンティティのいずれか１つにより満たされる限り、下流側に転送される（各ストリームは単一ベアラサービスを介して伝送される）。中間ノードがユーザサービスに属するすべてのパケットストリームを転送できない場合、中間ノードは、全体のセッションストリームを利用可能なＱｏＳに適応させるために、利用可能なベアラサービスのサブセットを選択することによりストリームをフィルタで除去する。中継されるコンテキスト情報（例えば、ＭＢＭＳベアラコンテキストとＭＢＭＳユーザサービスコンテキスト内）により、ネットワークノードはこのフィルタリングを実行できるようになる。

このノードは利用可能であろう残りの選択肢を知っているので、コンテキスト情報によってさらに、ネットワークは突然の能力変化（アップグレード／ダウングレード）に応答できるようになる。中継されたコンテキスト情報は、サービス構成（すなわち、サービスセマンティクス（ｓｅｒｖｉｃｅ ｓｅｍａｎｔｉｃｓ））の選択肢を記述しており、そしてこのコンテキスト情報は、例えば、ＭＢＭＳユーザサービスコンテキスト内に格納することができる。サービスセマンティクスは、例えば、ユーザサービスに属するベアラ、それらの相互関係（階層的、代替的、捕捉的）、代替ストリームの場合のストリームの可能な組合せについての情報等を含むことができる。別の設計可能性は、下流にドロップされたストリームとドロップされなかったストリームの状態に関する情報を転送することであろう。その詳細を以下の段落に示す。さらに、突然の能力変化への適応を可能にするために、ストリームのＱｏＳプロファイルを考慮できることに留意されたい。この情報は、設定されたベアラ毎のＱｏＳプロファイルを含む適応ノードに存在するＭＢＭＳベアラコンテキストから容易に入手できる。代替的には、サービスセマンティクス内のこの情報をシグナリングし、ユーザサービスコンテキスト内にそれらを格納することも考えられる。

一般性を失うことなく、無線アクセスネットワークは３ＧＰＰアーキテクチャのボトルネックと考えられ、コアネットワークは過剰供給（ｏｖｅｒ−ｐｒｏｖｉｓｉｏｎｅｄ）されていると考えられる。本発明はこの仮定の元でのみ適用可能であると限定すべきでないことに留意されたい。したがって、ＲＮＣは自身の無線ドメインにおける利用可能な資源についての知識を持つので、フィルタエンティティ（すなわち、「適応ノード」）をＲＮＣ内に例示することができる。これにより、フィルタエンティティをこの機能に適切なものにする。このようにして、ＲＮＣは「適応ノード」として動作する。

一般的には、ＲＡＮまたはＣＮにおけるあらゆるネットワークエンティティは、フィルタエンティティとして動作することができる。しかし、これらのエンティティを、要求されたサービスを受信する移動端末に向かう下流側リンク上の資源を知るフィルタリングエンティティとして選択することは可能である。

適応するネットワークエンティティにおけるフィルタの初期化は、制御メッセージを使用することによりトリガすることができる。したがって、以下に説明するＭＢＭＳ手順を用いることにより、サービスセマンティクスを、対応するＲＮＣに向けて下流側にシグナリングすることができる。サービスセマンティクスは、ユーザサービスと、それらの相互関係と、それらのＱｏＳプロファイルとを伝送するストリームに関する情報を参照するためのものと理解することができる。

本発明の一実施形態によれば、サービスセマンティクスを反映するこれらの情報要素は、特定されたＭＢＭＳシグナリングメッセージの選択的な領域内に与えられる。さらに、ＧＧＳＮおよびＳＧＳＮのような中間ノードは、メッセージ拡張の値を理解しない場合、それらを解析および処理する必要はなく、それらを下流側に転送するだけでよい。

本発明の別の実施形態によれば、上に概説した適応型ＱｏＳの概念はさらに、与えられたコンテンツ、例えば階層的コンテンツ、代替的コンテンツ、および捕捉的コンテンツを符号化するための様々なパラダイムをサポートするサービスを可能にすることを目的とする。これは、ＭＢＭＳサービスを提供するための新規な手法であるので、現在のアーキテクチャにはまだ反映されていない。現在、必要なＭＢＭＳコンテキスト情報のシグナリングおよび管理用のプレースホルダ（ｐｌａｃｅｈｏｌｄｅｒ）のみが定義されるが、様々な可能性をどのように実現するかについては定義されていない。したがって、サービスセマンティクス（例えば、サービス、それらの相互関係、それらのＱｏＳプロファイル等に属するベアラに関する情報）を格納するＭＢＭＳユーザサービスコンテキストの使用は、現在のＭＢＭＳアーキテクチャと互換性がある。

ＭＢＭＳユーザサービスコンテキスト
以下では、適応ノードに保持される、本発明の一実施形態による新規なＭＢＭＳユーザサービスコンテキストについて説明する。このコンテキストはセッション動作（ｓｅｓｓｉｏｎ ｓｅｍａｎｔｉｃｓ）を反映する。すなわち、このコンテキストは、ベアラに関する情報を提供し、適応ノードにおいて転送の判断を行なうために必要な追加のベアラ特性について説明する。ＭＢＭＳベアラコンテキストは不変のままで現在の３ＧＰＰ仕様に準拠することができる。

各ベアラ情報要素は、ストリームの相互関係に依存した異なる領域を含むことができる。例示された各タイプ（階層的、代替的、捕捉的）について、その情報要素を以下に説明する。

マルチベアラ手法
本発明の実施形態によるマルチベアラ手法は、ユーザサービスが複数のトランスポートチャネル（すなわちＭＢＭＳベアラ）を利用することができるというアーキテクチャの可能性を活用する。この手法の機能的要素は、表を参照して上に説明したＭＢＭＳユーザサービスコンテキストの新しい定義と、ベアラをネットワーク状態とユーザの環境設定に適応させるために適切なサービスのベアラを活性化および非活性化するいわゆる「適応ノード」の導入である。適応ノードの動作のために必要な追加情報を、上記サービスコンテキストに格納することができる。さらに、サービスの分散ツリー内には２つ以上の適応ノードが存在してもよいことに留意されたい。

この実施態様によると、マルチキャストサービスまたはブロードキャストサービスは、複数の代替的ストリーム、階層的ストリーム、または選択的ストリームを含む。適応ノードにより転送されたストリーム毎に、個別のベアラサービスが設定される。この目的のために、図８に示すように、唯一のサービスＩＰアドレスをストリーム毎に割り当てることができる。

本発明の一実施形態によると、適応ノードは、ＭＢＭＳユーザサービスを含むベアラについての情報を備える。その情報の保管のために、ＭＢＭＳユーザサービスコンテキスト（上の表１、２．１、２．２、３．１、３．２、４．２を参照）を使用することができる。このコンテキストは、ＭＢＭＳユーザサービス識別子と、ベアラの関係を規定するベアラＩＥを含む。他のベアラ依存性を規定するために、追加のベアラＩＥを定義してもよい。ベアラＩＥは、関連するＭＢＭＳベアラの識別子、およびこれらについての情報、例えばＭＢＭＳベアラＩＤ、優先順位、転送状態のリストを含む。また、各ベアラには、対応するＭＢＭＳベアラコンテキストに格納される唯一のＩＰマルチキャストアドレスを割り当てることができるので、このＩＰアドレスは、適切なＭＢＭＳベアラＩＤとして機能することが好ましい。代替的ベアラタイプについては、デフォルトの選択肢と、重要なベアラ組合せの明示的なリストとが含まれなければならない。

適応ノードにおいてＭＢＭＳユーザサービスコンテキストを設定するために、ＭＢＭＳ手順、例えばＭＢＭＳ登録手順で既に規定されたメッセージを、ＭＢＭＳユーザサービスコンテキストを設定するために必要な情報を伝送するための拡張された形式で再利用することができる。これらの手順（の１つ）は、ＭＢＭＳサービスに関与するネットワークノードの登録をトリガすることができる。すなわち、ＭＢＭＳベアラコンテキストとＭＢＭＳユーザサービスコンテキストが例示される。

ＱｏＳ属性はＭＢＭＳユーザサービスコンテキスト内に規定しなくてよいので、ＭＢＭＳ登録手順（図１０を参照）は、上記ＭＢＭＳユーザサービスコンテキストを設定するのに十分と考えられる。サービスに属する個々のベアラサービスのＱｏＳ属性は、対応するＭＢＭＳベアラコンテキストの一部として既に存在していてもよい。

この目的のために、適応ノードは、ＭＢＭＳユーザサービスコンテキスト情報を持つことへの関心を示さなければならない。代替的には、サービスセンターが、登録手順においてデフォルトで交換されるメッセージ内に関連情報を含むということであろう。

この目的のために、図５に示すＭＢＭＳ登録要求のプライベート拡張ＩＥを使用することができる。代替的には、このメッセージ内の必須の領域を規定してもよい。さらには、ＭＢＭＳユーザサービスコンテキストを設定するための新しいＭＢＭＳ手順とメッセージを規定してもよい。

登録手順によるＭＢＭＳユーザサービスコンテキストの設定に続いて、ＭＢＭＳセッション開始手順を使用して、ＭＢＭＳベアラコンテキストのＱｏＳプロファイルに規定される実際のベアラプレーンＱｏＳ属性を伝送し、予約することができる（詳細については、非特許文献１４を参照）。

このように、適応を実行するノードのみが、これらＭＢＭＳメッセージで伝送される情報を使用できるようになる。互換性のない他のノードはそれらを無視し、次の下流側ノードへそれらを転送してもよい。

上記実施例は、コアネットワーク（ＣＮ）メッセージ（ＧＧＳＮ＜−＞ＳＧＳＮ）に限定された。ＣＮにおいて、図５に示すＭＢＭＳ登録要求メッセージは、ＧＴＰ−Ｃプロトコルの一部である（図３の制御プレーンプロトコルスタックも参照）。このことは、一般的には、あらゆるＭＢＭＳ制御メッセージに対してあてはまる。しかし、ＣＮとＲＡＮとの間で、ＲＡＮＡＰ（無線アクセスネットワークアプリケーション部）プロトコルを使用することによりシグナリングを実現することができる。

ＲＡＮＡＰプロトコルは現在、ＭＢＭＳ専用メッセージフォーマットを明示的に規定していない。そこで、ＣＮメッセージに対して規定される属性が、ＲＡＮＡＰプロトコルによってＵＴＲＡＮにおいて交換されるメッセージにおいて、選択的なＩＥまたは新たに規定される必須のＩＥ内に等価なマッピングを見出すことを提案する。当業者は通常、メッセージの機能およびコンテンツと手順に対する、拡張、変更または置換のいずれかにより、上記機能を同じように実現できることを理解するであろう。

適応ノードがＭＢＭＳユーザサービスコンテキストを一旦設定すると、適応ノードは、ＭＢＭＳベアラコンテキストが存在する登録済みベアラ毎にＭＢＭＳセッション開始要求を受信できる状態になる。

それぞれのＭＢＭＳセッション開始要求が独立して処理される標準のメカニズムとは対照的に、これらのベアラは相互に関連するので、適応ノードは、すべてのＭＢＭＳセッション開始要求メッセージを同時に考慮することができる。上に説明したように、ベアラの相互関係は、ＭＢＭＳユーザサービスコンテキストに保持される情報の一部である。

本発明の一実施形態によると、登録されたベアラのいずれかのＭＢＭＳセッション開始メッセージを受信すると、適応ノードは、ＭＢＭＳベアラコンテキストを更新するとともに、関連する他のすべてのベアラのセッション開始要求メッセージを待つことができる。適応ノードは、ＭＢＭＳユーザサービスコンテキストからのベアラの関係およびベアラ優先順位（または、重要なベアラ代替）と、そのＭＢＭＳベアラコンテキストによる各ベアラのＱｏＳ要件とを解決する。それにより、そのＭＢＭＳサービスについて予約された資源によりマッチするベアラの組を決定することができる。上に説明したように、適応ノードの下流側のインターフェース上でそれぞれ入手可能な利用可能資源は、例えば、サービスマネージャ、すなわちそのＱｏＳ管理機能から得ることができる。

代替的には、登録されたベアラのいずれかのＭＢＭＳセッション開始メッセージを受信すると、適応ノードは、これらがそうすることを許容していれば、サービスを提供し始めることができる。この場合、それぞれのＭＢＭＳベアラコンテキストは、登録されたベアラ毎に、セッション開始メッセージが受信されたか否か、すなわちベアラ状態が「アクティブ」なのか「スタンバイ」なのかを示すことができる。

したがって、適応ノードの下流側インターフェースにおける下流側ＱｏＳ制約に最も良くマッチするベアラを、ＭＢＭＳユーザサービスコンテキストからのベアラ関係およびベアラ優先順位（または重要なベアラ代替）と、そのＭＢＭＳベアラコンテキストによる各ベアラのＱｏＳ要件およびステータス情報とに基づいて選択することができる。

登録されたすべてのベアラのＭＢＭＳセッション開始メッセージを適応ノードが待つ例示的な実施形態に戻る。すべてのセッション開始要求が一旦受信され、あるいはタイマが終了すると、適応ノードは、提供されたベアラまたはベアラの組合せのＱｏＳレベルのＱｏＳ要件を検査することができる。現在のネットワーク状態下でサポートすることができる最良のＱｏＳレベルのために、肯定的なＭＢＭＳセッション開始応答は、対応するベアラまたはベアラ群に対して送信され、一方、その他すべてに対しては、否定的な応答が送信される。例えば、下流側インターフェース上で利用可能なビットレートに適応するベアラの組合せに属するベアラは、応答メッセージで肯定確認応答され得る。

なお、下流側ノードによりサポートされていないストリームは、適応ノードに到達しない。なぜなら、これらのベアラは、ＭＢＭＳセッション開始手順中またはサービス中のいずれかにおいて、例えば、適応ノードが、「利用可能資源無し」を示すことによりＭＢＭＳセッション開始応答で拒否されるからである。これにより、資源の効率的な利用に寄与することができる。

ＭＢＭＳユーザサービスの動的適応
上記実施形態から明らかとなるように、適応ノードにおいてＭＢＭＳユーザサービスコンテキストを設定することにより、マルチキャストサービスまたはブロードキャストサービスの動的適応のための基本が確立された。すなわち、下流側ノードのいずれかを（ＱｏＳに関して）アップグレードまたはダウングレードする場合に、適応ノードはこれを管理することができる。

ＭＢＭＳユーザサービスコンテキストを利用することにより、適応ノードは、どのベアラが特定のノードに対して活性化／非活性化されるかを判定し、対応する手順を開始することができる。ここでは、ベアラサービスは、そのストリームがサービスセンターにより提供される限り設定され続けるということに留意されたい。本発明の実施形態によると、マルチキャストサービスまたはブロードキャストサービスの各ベアラサービスの分散ツリーは、ネットワーク状態に依存してネットワークノード間にリンクを追加／解除することにより、ネットワーク状態に動的に適応される。例えば、ある適応ノードが上流側の適応ノードにおいてサービスのアップグレード、例えばサービスベアラの追加を要求した場合、要求側適応ノードに対して、分散ツリー内の上流側のインターフェース上のネットワーク資源がそれを許容すれば、要求されたベアラの分散ツリーにおける新たなブランチが設定される。この処理については、以下の図６と図７を参照してさらに詳細に説明する。

ＭＢＭＳユーザサービスの適応は、ＭＢＭＳユーザサービスコンテキストのパラメータをアップグレード、ダウングレード、あるいは多少なりとも変更する処理として規定することができる。適応は、例えば、ＵＥがＲＮＣがホストする１つのセルから異なるＲＮＣがホストする別のＲＮＣへ移動する場合、ＵＥが継続ＭＢＭＳサービスの途中でサービスを受信することを要求した場合、または適応ノードが良かれ悪しかれ利用可能資源が変化したということを理解した場合などのいくつかの場合に実行可能である。

２つのタイプの適応を規定することができる。上述のように、動的適応はサービス中に実行され、静的適応はサービスの初めに実行され得る。

更に、通常、適応は、ネットワーク内に１つまたは複数の適応ノードが存在する場合に実行することができる。本発明の例示的な実施形態によると、動的適応は、２つ以上の適応ノードが存在する。例えばＲＮＣとＳＧＳＮが利用可能なシステムにおいて実行することができる。

例えば、ＭＢＭＳユーザサービスの適応を実行するために、適応ノードは、各適応ノードで提供されるＱｏＳ管理機能、すなわち上述のようなサービスマネージャとインターフェースすることができる。ＱｏＳ管理機能は、無線アクセスネットワークまたはコアネットワークの一部であるネットワークにおいて利用可能な資源を制御し、割り当て、監視する責任を負う。非特許文献１５には、このようなフレームワークの動作に関する詳細が記載されている。

各適応ノードがＱｏＳ管理機能にアクセスすると仮定すると、各適応ノードは、そのネットワークインターフェースの能力または有用性の変化を知ることができる。これらの変化の例は、ＭＢＭＳサービスを提供する下流側ノードまたは上流側ノードに設定されるトンネルの数または能力の増加または減少であろう。

なお、上記では、ＭＢＭＳセッション開始手順中の適応を取り扱った。以下、本発明の例示的な実施形態では、追加ベアラが要求された場合について図６と図７を参照して説明する。ベアラサービスをドロップするための動作は類似していることに留意されたい。

下流側ノードが追加ベアラを必要としていることを適応ノードが知っており、適応ノードが下流側ノードへのインターフェース上に十分な能力を有する場合、適応ノードは次の上流側の適応ノードに、追加ベアラのためのＭＢＭＳ登録要求（図６「要求ＩＤ４」参照）を発行することができる。ＭＢＭＳユーザサービスコンテキストを適応ノードにおいて利用可能にすることにより、適応ノードは、ユーザサービスに属するベアラを識別することができる。ＲＮＣ１のＭＢＭＳユーザサービスコンテキストからわかるように、ベアラＩＤ１のストリームのみがＢＳ２に提供されるので、ベアラＩＤ１の転送状態は「転送」のみに設定される。これらのベアラサービスのそれぞれのＱｏＳプロファイルは、ＭＢＭＳベアラコンテキスト内に容易に存在させることができる。なお、ベアラのデータは現在ＲＮＣ１により受信されていないので、要求されたＩＤ４を有するベアラは「スタンバイ」モードにある。したがって、各適応ノードにおいて利用可能なコンテキスト情報内の情報を使用することにより、適応ノードは、現在のネットワーク資源に基づいて、サービスを提供するための適切なベアラ（組合せ）を選択することができる。

追加のベアラサービスを要求する際のこの新しいＭＢＭＳ登録要求の機能は、利用可能な資源に対する上流側の適応ノードのポーリングに限定してよい。ポーリングされるノードが次のいずれかの利用可能な十分な資源を有する場合、以下のようになる。

１．ポーリングされるノードもまた、利用可能な要求ベアラを有する。図６では、それはＲＮＣ２へ転送されるので、ＳＧＳＮ１は利用可能なベアラＩＤ４を有する（ベアラコンテキスト内の「ベアラＩＤ４：ＱｏＳ４、アクティブ」参照）。この場合、これらは、インターフェース毎に、このベアラの転送状態を、ＲＮＣ１へのインターフェース毎のサービスコンテキスト内で「ドロップ」から「転送」に設定することにより要求ベアラを転送し、さらに肯定的なＭＢＭＳ登録応答を下流に伝播することができる。

適応ノードは、転送されるベアラとＭＢＭＳ登録応答に加えて、新たなＭＢＭＳセッション開始要求を下流側に発行することができる。しかし、ＱｏＳプロファイルは下流側ノードにおいて既に設定されているかもしれないので、これは厳密には必要ではない。さらに、要求元である下流側ノードは、それに従ってそのコンテキストを更新することができる（図７を参照）。ＲＮＣ１のベアラコンテキストでは、ＲＮＣ１は今やこのベアラサービスを介してデータを受信するので、ベアラＩＤ４の状態は「アクティブ」に設定される。さらに、ユーザサービスコンテキストにおいて、ＲＮＣ１は要求されたベアラのデータをＢＳ２へ伝播するので、ＲＮＣ１はＢＳ２へのインターフェースについての転送状態を「転送」に設定する。

２．ポーリングされるノードはベアラを有しないが、それを下流側に提供する能力を有する。これは、それぞれのコンテキストに次のように反映されるであろう（図６と図７を参照）。ＲＮＣ１のユーザサービスコンテキストは、すべてのインターフェースに対しエントリ「ベアラＩＤ４→ドロップ」を、そしてベアラコンテキスト内にエントリ「ベアラＩＤ４：ＱｏＳ４、スタンバイ」を有することになる。この場合、適応ノードは、要求されたベアラまたはＢＭ−ＳＣの登録に成功した適応ノードに到達するまで、ＭＢＭＳ登録要求を上流側に伝播することができる。双方の場合において、上記項目１で説明した手順を実行することができる。

３．第３の可能性は、どの適応ノードもベアラの登録に成功せず、あるいはベアラを下流に提供する能力が利用できる場合である。この場合、適応ノードは否定的なＭＢＭＳ登録要求応答を送信することができる。

肯定的なＭＢＭＳ登録要求が要求元への下流側への経路における適応ノードに到達すると、対応するＭＢＭＳベアラコンテキストは「アクティブ」に設定され、データは下流側ノードへ転送することができる。この処理は、影響を受けるそれぞれのインターフェース毎に、すべてのＭＢＭＳベアラコンテキストとＭＢＭＳユーザサービスコンテキストがそれに応じて転送状態の領域を「転送」に更新するまで繰り返すことができる。

どの適応ノードもベアラの登録に成功しなかった場合、あるいはベアラを下流側に提供する能力が得られない場合は、上流側ノードを連続的にポーリングすることができ、故障ネットワークの動作をもたらすかもしれない。これを回避するために、本発明の別の実施形態は、上流側ノードが最初のＭＢＭＳ登録要求に肯定的に応答するまで、後のポーリングを禁止することを提案する。これは、このようなアップグレードを拒否した上流側ノードもまた、その後のアップグレードが可能かどうかを監視するということを意味する。したがって、上流ノードが今やこのような要求に対処するであろうことが理解される。

ベアラが、分散ツリーの枝路におけるネットワークノード間に設定されたリンクをドロップ（ダウングレード）する場合、それぞれのベアラは、可能な限り遠い上流側までのリンクを解除することができる。本発明の一実施形態によると、適応ノードが選択されたベアラをドロップした後、すなわちベアラのストリームを下流側に伝播するために設定されたリンクを解除した後に、適応ノードはＭＢＭＳ登録要求を上流側に送ることができる。

肯定的なＭＢＭＳ登録応答を応答として受信することができる。このことは上流側の他のすべての適応ノードがベアラをドロップすることを選択したことを意味する。したがって、発信元以外は他のどの適応ノードも実際にはベアラに関するストリームを必要としないので、帯域幅を節約することができる。否定的な応答は、別のノードがローカルにドロップされたベアラを実際に必要としているということを示すことができる。上記様々な実施形態において概説されたマルチベアラ手法は、適応ノードがトランスポートベアラを活性化／不活性化することによりストリームをフィルタリングするので、簡単な決定論理を使用することにより実施することができる。したがって、ＲＡＮおよびＣＮノードにおける実施は、単純な決定論理により容易に実現することができる。

さらに、ユーザの環境設定および能力への適応は、ユーザにより（すなわち、ネットワーク内において）適切な一組のベアラを選択することにより可能となる。また、利用されるベアラの資源のみが予約される、すなわちネットワークノード間の必要なリンクが必要なときにのみ設定されるので、この手法は資源的に効率的である。

進化したＵＴＲＡＮにおけるスケーラブルで適応型ＱｏＳアーキテクチャ
将来のＵＴＲＡＮアーキテクチャは、さらに多くのインテリジェンス（拡張制御および管理機能）の提供がネットワークの端まで、例えばノードＢ（基地局）までさらに押し進められることを想定する。これを行う１つの理由は、ＲＮＣが現在影響を及ぼしている単一点（ｓｉｎｇｌｅ ｐｏｉｎｔ）障害を取り除くことである。この将来のＵＴＲＡＮアーキテクチャは、上記様々な実施形態による適応型ＱｏＳアーキテクチャを完全に取り込むことができるということに留意すべきである。

上に概説した原理を利用するために、ＭＢＭＳベアラコンテキストは、新しいノード、および適応ノード、例えば新しいＵＴＲＡＮアーキテクチャのノードＢ＋として動作するノード内のＭＢＭＳユーザサービスコンテキストにおいて、それに応じて複製することができる。提案するＭＢＭＳ手順は、それに応じて拡張することができる。他の機能と要件は、上の章において概説したものと同様である。

ストリーム変換
本発明の別の実施形態では、適応ノードが、例えば、サービスの１つまたは複数のストリームを下流側ＱｏＳ制約に整合させるためにパケットストリームの変換を可能にする手段をさらに具備することを提案する。これは、例えば、ノードの下流側インターフェース毎のＱｏＳ検査が、関連するベアラを介してサービスにより提供されるストリームのそれぞれについて失敗した状況において適用可能である。

可能なストリーム（または、ストリームの組合せ）変換の概要は、非特許文献１６に提案されている。コード変換技術は、例えば、以下のように様々な要求に対応することができる。

●様々なコーデック間を切り替えるためのコーデック変換
●時間分解能またはフレーム率の低減
●空間分解能の低減
●一定ビットレートから可変ビットレートへの変換
●複数階層ストリームから単一層ストリームへの変換

コーデック変換の適用は、相異なるアーキテクチャ同士または専用ネットワーク同士がインターフェースする場合、例えばＭＰＥＧファイルからウインドウズ専用ＷＭＡコーデックへの変換に適切であろう。フレーム率低減は、符号化された画像の品質を保持し、処理ニーズを低減しつつ、ビットレートを低減するために有用であろう。フレーム率低減の典型的な使用例は、画像分解能を保持する低減率が記憶装置能力の点から許容される妥協点である監視アプリケーションである。

空間分解能の低減は、移動端末のような小型装置に媒体を適応させる場合に有用であろう。典型的な変換は、ＭＰＥＧ２画像（５．３Ｍｂｐｓ、３０ｆｐｓ、７２０ｘ４８０）からＭＰＥＧ４単一プロファイルレベル２（１２８Ｋｂｐｓ、１０ｆｐｓ、３５２ｘ２４０）への変換である。

一定ビットレートストリームから可変ビットレートストリームへの変換は、非特許文献１７に例示される。その目的は、可変ビットレートサービスネットワークにおいて一定ビットレートストリームに対処することである。

さらに、複数階層ストリーム、例えばＭＰＥＧ−４ ＦＧＳの単一層ストリームへの変換は、適応ノードが実行できる変換の別の例である。これは、非特許文献１８に例示される。

ハードウェアおよびソフトウェアの実現
本発明の別の実施形態は、ハードウェアとソフトウェアを使用することにより上述の様々な実施形態を実施することに関する。上記様々な方法および上記様々な論理ブロック、モジュール、回路は、例えば、汎用プロセッサ、デジタル信号プロセッサ（ＤＳＰ）、特定用途向けＩＣ（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、または他のプログラマブルロジックデバイス等の演算装置を使用することにより、実施または実行することができるということが理解される。本発明の様々な実施形態はまた、これら装置の組み合わせにより実行または具現化することができる。

さらに、本発明の様々な実施形態は、また、プロセッサにより、またはハードウェアで直接実行されるソフトウェアモジュールによって実施することができる。また、ソフトウェアモジュールとハードウェア実装とを組み合わせることが可能である。上記ソフトウェアモジュールは、例えば、ＲＡＭ、ＥＰＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリ、レジスタ、ハードディスク、ＣＤ−ＲＯＭ、ＤＶＤ等の任意のタイプのコンピュータ読取り可能な記憶媒体に格納することができる。

Claims (20)

1. サービス品質管理機能を提供するサービスマネージャを有するネットワークエンティティの少なくとも１つを介して、サービスセンターから移動端末に、それぞれが単一ベアラサービスを介して伝送される複数のパケットストリームの形式でマルチキャストサービスまたはブロードキャストサービスを提供する方法であって、
   前記マルチキャストサービスまたはブロードキャストサービスに属するベアラサービスと、前記ベアラサービスにより伝送されるパケットストリームまたはそのパケットストリームの組合せにより必要とされるサービス品質属性とを示す情報を受信して、受信した前記情報を含むサービスコンテキストを設定するステップと、
   前記サービス品質管理機能から、前記ネットワークエンティティの下流側のインターフェース毎における下流側データ伝送のために利用可能なサービス品質を示すサービス品質制約を取得するステップと、
   前記サービスコンテキスト内に格納される前記サービス品質属性に基づいて、前記マルチキャストサービスまたはブロードキャストサービスに属する前記ベアラサービスから、取得した前記サービス品質制約内でそのストリームを伝送可能なベアラサービスを選択するステップと、
   選択した前記ベアラサービスを登録するための登録要求を、上流側ネットワークエンティティまたは前記サービスセンターに送信するステップと、
   前記上流側ネットワークエンティティまたは前記サービスセンターから、登録が成功したベアラサービスを示す登録応答メッセージを受信するステップと、
   登録が成功したベアラサービス毎に、前記ネットワークエンティティと前記上流側ネットワークエンティティとの間のリンクを設定するステップと、
   設定した各リンクを介して、それぞれ登録済みのベアラサービスのパケットストリームを受信するステップと、
   設定した各ベアラサービスのパケットストリームを、前記下流側のインターフェースを介して前記移動端末へ転送するステップと、
   前記下流側のネットワークインタフェースのネットワーク状態を監視するステップと、
   前記下流側のネットワークインタフェースのネットワーク状態の変化に適応して、ベアラサービスを動的に追加またはドロップするための登録要求を、前記上流側ネットワークエンティティまたは前記サービスセンターに送信するステップと、
   ベアラサービスを動的に追加またはドロップするためのするための登録要求に対する応答を、前記上流側ネットワークエンティティまたは前記サービスセンターから受信するステップと、
   を実行し、
   ベアラサービスを動的に追加するための登録要求に対する肯定的な応答を受信するまで、ベアラサービスを動的に追加するためのさらなる登録要求の送信を禁止する、
   方法。
2. 下流側インターフェース毎に、前記マルチキャストサービスまたはブロードキャストサービスに属する前記ベアラサービスのそれぞれの転送状態を、前記サービスコンテキスト内に格納するステップをさらに含む、請求項１記載の方法。
3. 下流側ネットワークエンティティからベアラサービスの登録要求を受信するステップと、
   前記サービスコンテキストに基づいて、要求される前記ベアラサービスのパケットストリームが前記ネットワークエンティティにより受信されたか否かを判定するステップと、
   受信されたと判定する場合、要求元である前記下流側のネットワークエンティティに、要求される前記ベアラサービスの登録が成功したことを示す登録応答メッセージを送信するステップとをさらに含む、請求項１乃至請求項２のいずれかに記載の方法。
4. 前記登録応答メッセージが登録の成功を示す場合、前記ネットワークエンティティと要求元である前記下流側ネットワークエンティティとの間に、要求される前記ベアラサービスのパケットストリームを転送するためのリンクを設定するステップをさらに含む、請求項３記載の方法。
5. 要求される前記ベアラサービスのパケットストリームが前記ネットワークエンティティにより受信されていないと判定した場合、前記要求される少なくとも１つのベアラサービスの登録要求を、上流側ネットワークエンティティまたは前記サービスセンターへ送信するステップと、
   前記上流側ネットワークエンティティまたは前記サービスセンターから、前記要求される少なくとも１つのベアラサービスの登録が成功したか否かを示す登録応答メッセージを受信するステップとをさらに含む、請求項３または請求項４記載の方法。
6. 前記登録応答メッセージが登録の成功を示す場合、前記ネットワークエンティティと前記上流側ネットワークまたは前記サービスセンターとの間に、要求される前記ベアラサービスのパケットストリームを転送するためのリンクを設定するステップと、
   要求元である前記下流側ネットワークエンティティに、要求される前記ベアラサービスの登録が成功したことを示す登録応答メッセージを送信するステップとをさらに含む、請求項５記載の方法。
7. 前記上流側ネットワークエンティティまたは前記サービスセンターにベアラサービスの登録要求を送信するステップと、
   前記上流側ネットワークエンティティまたは前記サービスセンターから、要求される前記ベアラサービスの登録が成功したか否かを示す登録応答メッセージを受信するステップとをさらに含む、請求項１乃至請求項６のいずれかに記載の方法。
8. 前記登録応答メッセージが登録の成功を示す場合、前記ネットワークエンティティと、要求元である前記上流側ネットワークエンティティまたは前記サービスセンターとの間に、要求される前記ベアラサービスのパケットストリームを転送するためのリンクを設定するステップをさらに含む、請求項７記載の方法。
9. 前記ネットワークエンティティで保持されるサービスコンテキストを、受信した前記登録応答メッセージに基づいて更新するステップをさらに含む、請求項５乃至請求項８のいずれかに記載の方法。
10. 下流側ネットワークエンティティからベアラサービスの登録解除要求を受信するステップと、
    要求元である前記下流側ネットワークエンティティと前記ネットワークエンティティとの間に前記ベアラサービスのために設定される前記リンクを解除するステップと、
    前記ベアラサービスのストリームが要求元である前記下流側ネットワークエンティティへもはや転送されないことを示すために、前記サービスコンテキストを更新するステップとをさらに含む、請求項１乃至請求項８のいずれかに記載の方法。
11. 要求元である前記下流側ネットワークエンティティ以外の別の下流側ネットワークエンティティが前記ネットワークエンティティへのベアラサービスのためのリンクを保持するか否かを判定するステップと、
    保持しないと判定する場合、前記上流側ネットワークエンティティまたは前記サービスセンターに前記ベアラサービスの登録解除要求を送信するステップとをさらに含む、請求項１０記載の方法。
12. 前記上流側ネットワークエンティティまたは前記サービスセンターにベアラサービスの登録解除要求を送信するステップと、
    前記ベアラサービスのストリームが下流側ネットワークエンティティまたは移動端末への下流側にもはや転送されないことを示すために、前記サービスコンテキストを更新するステップとをさらに含む、請求項１乃至請求項１１のいずれかに記載の方法。
13. 前記サービス品質属性を示す受信情報は、前記複数のパケットストリーム毎のサービス品質属性と、前記パケットストリームの組合せのサービス品質属性とを示す、請求項１乃至請求項１２のいずれかに記載の方法。
14. 前記ネットワークエンティティは、サービス品質管理機能を有する無線アクセスネットワークのエンティティ、またはサービス品質管理機能を有するコアネットワークのエンティティである、請求項１乃至請求項１３のいずれかに記載の方法。
15. 選択される少なくとも１つのストリームを、前記サービス品質管理機能から取得される前記サービス品質制約内で伝送可能なストリームに変換するステップをさらに含む、請求項１乃至請求項１４のいずれかに記載の方法。
16. 前記変換は、前記ストリームのビットレートを変換すること、コーデックタイプを変換すること、空間的分解能または時間的分解能を変換すること、複数層ストリームから単一層ストリームに変換すること、一定ビットレートストリームから可変ビットレートストリームに変換すること、および可変ビットレートストリームから一定ビットレートストリームに変換することのうち少なくとも１つを含む、請求項１５記載の方法。
17. 前記ネットワークエンティティは、サービス品質管理機能を有する無線アクセスネットワークのエンティティ、またはサービス品質管理機能を有するコアネットワークのエンティティである、請求項１乃至請求項１６のいずれかに記載の方法。
18. それぞれが単一ベアラサービスを介して伝送される複数のパケットストリームの形式でのマルチキャストサービスまたはブロードキャストサービスが、サービスセンターから移動端末へ提供されるネットワークエンティティであって、
    サービス品質管理機能を提供するサービスマネージャと、
    前記マルチキャストサービスまたはブロードキャストサービスに属するベアラサービスと、前記ベアラサービスにより伝送されるパケットストリームまたはそのパケットストリームの組合せにより必要とされるサービス品質属性とを示す情報を受信する手段と、
    受信した前記情報を含むサービスコンテキストを設定する手段と、
    前記サービス品質管理機能から、前記ネットワークエンティティの下流側のインターフェース毎における下流側データ伝送のために利用可能なサービス品質を示すサービス品質制約を取得する手段と、
    前記サービスコンテキスト内に格納される前記サービス品質属性に基づいて、前記マルチキャストサービスまたはブロードキャストサービスに属する前記ベアラサービスから、取得した前記サービス品質制約内でそのストリームを伝送可能なベアラサービスを選択する手段と、
    選択した前記ベアラサービスを登録するための登録要求を、上流側ネットワークエンティティまたは前記サービスセンターに送信する手段と、
    前記上流側ネットワークエンティティまたは前記サービスセンターから、登録が成功したベアラサービスを示す登録応答メッセージを受信する手段と、
    登録が成功したベアラサービス毎に、前記ネットワークエンティティと前記上流側ネットワークエンティティとの間のリンクを設定する手段と、
    設定した各リンクを介して、それぞれ登録済みのベアラサービスのパケットストリームを受信する手段と、
    設定した各ベアラサービスのパケットストリームを、前記下流側のインターフェースを介して前記移動端末へ転送する送信手段と、
    前記下流側のネットワークインタフェースのネットワーク状態を監視する手段と、
    前記下流側のネットワークインタフェースのネットワーク状態の変化に適応して、ベアラサービスを動的に追加またはドロップするための登録要求を、前記上流側ネットワークエンティティまたは前記サービスセンターに送信する動的適応手段と、
    ベアラサービスを動的に追加またはドロップするためのするための登録要求に対する応答を、前記上流側ネットワークエンティティまたは前記サービスセンターから受信する応答受信手段と、
    を含み、
    前記応答受信手段が、ベアラサービスを動的に追加するための登録要求に対する肯定的な応答を受信するまで、前記動的適応手段は、ベアラサービスを動的に追加するためのさらなる登録要求の送信を禁止する、
    ネットワークエンティティ。
19. 請求項２乃至請求項１７のいずれかに記載の方法のステップを実行するように適合される手段をさらに含む、請求項１８記載のネットワークエンティティ。
20. サービスセンターと、マルチキャストサービスまたはブロードキャストサービスを受信する少なくとも１つの移動端末と、請求項１８または請求項１９記載の少なくとも１つのネットワークエンティティとを含む移動通信システム。
    

Images