リソース割り当てのための方法およびデバイス
本発明は、クライアントとサーバの間で通信セッションを確立するための方法に関する。この方法は、− 前記サーバにおいて、クライアント−サーバ通信セッションを確立するためのネットワークリソースのための要求を受信するステップであって、前記要求は、クライアントの識別を少なくとも含むステップ、− サーバにおいて、クライアント−サーバ通信セッションのための使用可能なネットワークリソースについての情報を収集するステップ、および、− 使用可能なネットワークリソースについての情報を考慮に入れて、クライアントとの通信セッションを確立するステップを含む。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、一般にデータストリームのトラフィック管理の分野に関する。
【背景技術】
【０００２】
今日のＩＰネットワークは、異なるサービス品質（ＱｏＳ）を必要とする通信にかなりよく対処している。ネットワークが過剰供給されているか、または、ＩｎｔＳｅｒｖおよびＤｉｆｆＳｅｒｖのように、トラフィック管理技術が適用されている。ＩｎｔＳｅｒｖおよびＤｉｆｆＳｅｒｖは、当技術分野でよく知られている技術である。
【０００３】
ＩｎｔＳｅｒｖ（Ｉｎｔｅｇｒａｔｅｄ Ｓｅｒｖｉｃｅｓ）は、ネットワーク上でサービス品質（ＱｏＳ）を保証するために要素を特定する、きめの細かいシステムである。ＩｎｔＳｅｒｖは、例えば、ビデオおよび音声が途切れることなく受信機に達することを可能にするために、使用されることが可能である。ＩｎｔＳｅｒｖの考えは、システム内のあらゆるルータはＩｎｔＳｅｒｖを実装し、ある種の保証を必要とするあらゆるアプリケーションは、個別の予約をしなければならないというものである。いわゆる「ｆｌｏｗ ｓｐｅｃｓ」は、予約が何のためのものであるかを記述している。ＩｎｔＳｅｒｖは、フローベースであると言われている。フロー毎の精度のため、ＩｎｔＳｅｒｖアーキテクチャは、サービスプロバイダネットワークにおいて必要とされる規模に合わせてスケーリングすることに、重大な困難さを有する。スケーリングの問題はまた、このアーキテクチャが幅広い配置を享受していないことについての、主な理由の１つにもなっている。
【０００４】
ＤｉｆｆＳｅｒｖ（Ｄｉｆｆｅｒｅｎｔｉａｔｅｄ Ｓｅｒｖｉｃｅｓ）は、ネットワークトラフィックを分類、管理し、現代のＩＰネットワーク上でサービス品質（ＱｏＳ）保証を提供するための、単純で、スケーラブルな、クラスベースの、きめの粗い機構を特定する、コンピュータネットワーキングアーキテクチャである。ＤｉｆｆＳｅｒｖは、例えば、単純なベストエフォートトラフィック保証を、ウェブトラフィックまたはファイル転送など、重大ではないサービスに提供しながら、低レイテンシの、保証されたサービスを、音声またはビデオなど、重大なネットワークトラフィックに提供するために、使用されることが可能である。ＤｉｆｆＳｅｒｖは特に、（あらゆるトラフィックフローが個別のハンドリングを必要とするようになる、ＩｎｔＳｅｒｖとは対照的に）すべてのトラフィックが限定されたクラスのセットにグループ化され、所与のクラスのすべてのトラフィックが等しいものとして扱われるので、多くのトラフィックフローがバックボーンネットワークを介して集約または移送されるところで、うまくいく。ＤｉｆｆＳｅｒｖは、スケーラブルで実装可能なアーキテクチャとして広く見なされており、世界中で、サービスプロバイダＩＰバックボーンネットワークの大部分において見られることが可能である。
【０００５】
いくつかのクライアント−サーバアプリケーションセッションでは、必要とされたネットワークリソースは、適切なサービス保証のための使用可能なネットワークリソースと比較される必要があるので、フローベースの割り当ては唯一の選択肢である。ＱｏＳに対してパケットをどのように扱うかの決定は、パケット毎およびクラス毎のベースで行われるので、クラスベースの機構はそのような比較を包含しないことに留意されたい。そのようなアプリケーションのために、ネットワーク制限（例えば、ブロードバンドアクセスのためのファーストマイル帯域幅制約）のせいで、オーバーブッキングが選択肢でない場合、今日では、ＩｎｔＳｅｒｖトラフィック管理しか選ぶことができない。その複雑さのため、ＩｎｔＳｅｒｖソリューションは、すでに上述したように、容易にはスケーリングしない。ＩｎｔＳｅｒｖのさらなる問題は、リソース割り当て段階が必要とされることであり、このことは、クライアント−サーバの双方向性、および、よって、リソース割り当て機構のレートに影響を及ぼす。ＩｎｔＳｅｒｖは、クライアント要求にサービスするためにどのくらいのリソースが使用可能であるかの知識を、サーバが利用することも可能にしない。
【０００６】
Ｃｉｓｃｏは、同社のＶｉｓｕａｌ Ｑｕａｌｉｔｙ Ｅｘｐｅｒｉｅｎｃｅコンセプトについての公開ホワイトペーパー（ｈｔｔｐ：／／ｗｗｗ．ｃｉｓｃｏ．ｃｏｍ／ｅｎ／ＵＳ／ｓｏｌｕｔｉｏｎｓ／ｃｏｌｌａｔｅｒａｌ／ｎｓ３４１／ｎｓ５２４／ｎｓ６１０／ｎｅｔ＿ｉｍｐｌｅｍｅｎｔａｔｉｏｎ＿ｗｈｉｔｅ＿ｐａｐｅｒ０９００ａｅｃｄ８０５７ｆ２９０．ｈｔｍｌを参照）において、コールアドミッション制御（ＣＡＣ）のためのオンパスプロシージャを記載している。それは、ＲＳＰＶ（リソース予約プロトコル）という、ＩｎｔＳｅｒｖをサポートするＩＥＴＦ（ＲＦＣ ２２０５）によって特定されたプロトコルに基づいている。この提案はまた、顧客要求に対する応答性にも取り組んでいる。しかし、提案されたソリューションは、ハンドシェーキングに基づいたままであるので、リソース割り当て機構のレートが落とされるという、重要な欠点を有しており、このことは応答性に悪影響を及ぼす。提案されたソリューションのさらなる欠点は、
− サーバを最適化するためのリソースの可用性（すなわち、スケーラビリティ）についての情報を使用することを可能にしない、
− コアネットワーク内の使用のために意図されており、アクセス／ファーストマイル向けではない、
− ＭＰＬＳ（マルチプロトコルラベルスイッチング）または一般ルーティングカプセル化トンネルを介さず、かつ、階層−ＶＰＬＳ／ＶＰＬＳ（仮想プライベートＬＡＮサービス）または他のレイヤ２アグリゲーション技術など、レイヤ２構造を介さず、レイヤ３で経路指定された環境内でのみ使用されることが可能であることである。
【０００７】
動的ホスト構成プロトコル（ＤＨＣＰ）およびポイントツーポイントプロトコルオーバーイーサネット（ＰＰＰｏＥ）オプション８２は、ファーストマイルアクセス（回線）についての帯域幅情報を挿入することを可能にする。この情報は、リンクの物理容量に制限され、したがって、サーバが使用可能な帯域幅について知り、適切に反応するためには、不十分である。
【０００８】
高速チャネル変更（ＦＣＣ）ソリューションは、市場に存在している（例えば、ＭｉｃｒｏｓｏｆｔのＩｎｓｔａｎｔ Ｃｈａｎｎｅｌ Ｃｈａｎｇｅ（ＩＣＣ）、ＣｉｓｃｏのＲａｐｉｄ Ｃｈａｎｎｅｌ Ｃｈａｎｇｅ（ＲＣＣ））。これらのソリューションのいずれも、スケーリングの目的で最適化するために、ファーストマイルにおける使用可能な帯域幅を考慮に入れていない。
【０００９】
ＥＴＳＩ ＴＩＳＰＡＮは、ＶｏＤおよびＬＰＴＶの両方の混合サポートにおける、ファーストマイルビデオ帯域幅割り当てのために解決するために、集中型ＲＡＣＦ（リソース受け入れ制御機能）を説明している。記載されたソリューションは、しかし、比較的遅く、かなり複雑である（例えば、顧客毎に維持されるべき構成データ、および、中央サーバの必要性のため）。
【先行技術文献】
【非特許文献】
【００１０】
【非特許文献１】Ｖｉｓｕａｌ Ｑｕａｌｉｔｙ Ｅｘｐｅｒｉｅｎｃｅコンセプト、ｈｔｔｐ：／／ｗｗｗ．ｃｉｓｃｏ．ｃｏｍ／ｅｎ／ＵＳ／ｓｏｌｕｔｉｏｎｓ／ｃｏｌｌａｔｅｒａｌ／ｎｓ３４１／ｎｓ５２４／ｎｓ６１０／ｎｅｔ＿ｉｍｐｌｅｍｅｎｔａｔｉｏｎ＿ｗｈｉｔｅ＿ｐａｐｅｒ０９００ａｅｃｄ８０５７ｆ２９０．ｈｔｍｌ
【発明の概要】
【発明が解決しようとする課題】
【００１１】
本発明は、従来技術のソリューションの上述の欠点を回避または克服しながら、通信セッションがクライアントとサーバの間で確立される、データトラフィック管理のための方法およびデバイスを提供することを目的とする。
【課題を解決するための手段】
【００１２】
本発明は、クライアントとサーバの間で通信セッションを確立するための方法を提供する。この方法は、
− 前記サーバが、クライアント−サーバ通信セッションを確立するためのネットワークリソースのための要求を受信するステップであって、前記要求は、クライアントの識別を少なくとも含むステップ、
− サーバにおいて、クライアント−サーバ通信セッションのための使用可能なネットワークリソースについての情報を収集するステップ、および
− 前記使用可能なネットワークリソースについての情報を考慮に入れて、クライアントとの通信セッションを確立するステップを含む。
【００１３】
有利な実施形態では、使用可能なリソースについての情報の少なくとも一部が、前記ネットワークリソースのための要求内に含まれる。好ましくは、前記情報の少なくとも一部が、前記クライアントによって前記要求に追加される。有利には、情報の少なくとも一部が、クライアントとサーバの間の伝送路に沿って、要求に追加されてもよい。
【００１４】
一実施形態では、情報の少なくとも一部が、サーバによって提供される。
【００１５】
有利には、情報の少なくとも一部が、通信管理を行うことができる外部デバイスによって提供される。
【００１６】
好ましい実施形態では、通信セッションがビデオオンデマンドである。有利には、通信セッションが次いで、サーバからクライアントへのユニキャストストリームを介して確立される。
【００１７】
別の好ましい実施形態では、通信セッションがリニアプログラミングＴＶサービスである。
【００１８】
別の実施形態では、通信セッションが、少なくとも部分的にはバーストモードにおいて行われる。
【００１９】
別の態様では、本発明は、クライアント−サーバ通信セッションにおいて、サーバとして動作するために構成されたデバイスに関する。このデバイスは、クライアントからネットワークリソースのための要求を受信するための手段を含み、クライアント−サーバ通信セッションのための使用可能なネットワークリソースについての情報を受信するため、および、使用可能なネットワークリソースについての情報を考慮に入れて、通信セッションを確立するためにさらに構成されることを特徴とする。
【００２０】
さらなる実施形態では、本発明は、クライアントとサーバの間の通信セッションにおける使用のためのデバイスに関する。このデバイスは、使用可能なネットワークリソースについての情報を、サーバに対するネットワークリソースのための要求に追加するために構成されることを特徴とする。有利には、このデバイスは、前記ネットワークリソースのための要求を生成するためにさらに構成される。
【図面の簡単な説明】
【００２１】
【図１】本発明の一実施形態による、サーバに対する要求への、使用可能な（帯域幅）リソースの情報の追加を表す図である。
【発明を実施するための形態】
【００２２】
本発明では、一般的なフローベースのトラフィック管理機構が提案され、好ましい実施形態によれば、使用可能なネットワークリソースについての情報は、クライアント−サーバセッション要求自体の一部となり、サーバは、いかなるハンドシェークまたは往復のメッセージングをも必要とせずに、それに反応することができる。
【００２３】
ＴＣＰ／ＩＰプロトコルスイートを使用し、そのために（ＩＰ）ネットワークリソースが保証される必要のある、クライアント−サーバアプリケーションのための非常に高速な双方向性を保証するために、本発明は、一実施形態において、使用可能なリソースについて通知する情報要素を、クライアント要求に追加することを提案する（情報をエクスポートする）。これらの情報要素は、始点において（すなわち、クライアントにおいて）追加されるか、または、サーバへのパスに沿って（場合によっては、複数のポイントにおいて）挿入されることが可能である。場合によっては、サーバ自体において知られている制限をも考慮に入れながら、すなわち、上記クライアント−サーバアプリケーションのための使用可能なリソースまたはその一部を採用することによって、受信において、サーバはそれに応じて直ちに応答することができる。
【００２４】
使用可能なリソースについての情報を挿入するクライアントまたはいずれかのネットワークデバイスは、使用可能なリソースを承知しているか、または、クライアント−サーバセッションに関係するインタフェース（複数可）のための外部リソース管理エンティティ（または、複数のエンティティ）によって通知される。全体の反応性を高くする（高速な要求の発行および後続のサーバアクション）ために、リソース使用更新のためのレイテンシは、特定のサービスのためのソリューションの適用性を制限するために重要である。
【００２５】
クライアント−サーバセッションに関係する使用可能なリソースの一部が（しばしば）変化しないとき、特定の状況が存在し、その場合、（使用可能なリソースのその部分についての情報をエクスポートするために）追加のレイテンシがその部分のために適用されることはない。このような静的状況はまた、使用可能なリソースが遅いレートでのみ変化する場合（すなわち、安定期間中に多数のクライアント−サーバ要求が発生するとき）にも存在するが、そこで、クライアントは、非リアルタイムまたは準リアルタイムのシステムによって（例えば、電気通信管理プラットフォームの仲介によって）、通知され続ける。
【００２６】
もう１つの特定の場合は、サーバ自体が、例えば、外部リソース管理エンティティによって、所与のクライアント要求に関連する使用可能なリソースについて通知されるときである。このような場合、クライアント要求が、そのサーバにおいて知られている情報に関連付けられることが可能であるクライアント識別を示すならば、サーバは自律的に動作することができる。
【００２７】
ＩＰＴＶに関連した本発明のいくつかの具体的な実施形態が、後述される。
【００２８】
今日のＩＰＴＶアプリケーションでは、ケーブルまたは地上波において知られているような放送ＴＶによく似ている、ビデオオンデマンドおよびＬＰＴＶ（リニアプログラミングＴＶ）が共に、典型的にサポートされる。今日の（例えば、ＶＤＳＬにおける）制限されたアクセス帯域幅と共に、エンドユーザが有する、これらのサービスに対するリアルタイムの期待のために、本発明の以下の実施形態は、この環境において適用される。
【００２９】
高速チャネル変更
エンドユーザがＬＰＴＶサービスにおいて、あるプログラムから別のものへと変更するとき、エンドユーザは、自分のリモートコントロール上で選択されたチャネルを押した直後に新しいイメージを見ることを期待する（ザッピング）。いずれかの特別な配置がなければ、クライアントから（ＬＰＴＶ放送）サーバ自体へのシグナリングにおける遅延のため、しかし、また、クライアントにおいて新しい画像を構築するための遅延のためにも、遅延はすぐに増加する。実際には、高度に圧縮されたデジタルビデオ信号は、デコーダにおいて新しい画像を速く構築するために、いわゆるアンカーフレームを必要とし、クライアントは（ザッピングの後）、画面上に新しい画像を適切に構築するために、次のアンカーフレーム上で待機しなければならない。
【００３０】
高速チャネル変更は、高速チャネル変更（ＦＣＣ）サーバの使用によって実装されることが可能である。このようなサーバは、関係している（選択された）ＬＰＴＶチャネルから得られたユニキャストストリームを送信することができる。ユニキャストストリームは通常、マルチキャストにおいて、このチャネルを要求したすべてのクライアントへ送信される。特定のクライアント（すなわち、セットトップボックス（ＳＴＢ）上で実行するソフトウェア）がそのチャネルに変更するとき、特定のクライアントは、即時の画像の構築を可能にし、よって、選択されたチャネルへ高速で変更するために、過去からのアンカーフレームで開始するユニキャストストリームを最初に受信する。ユニキャストは、過去からのすべてのパケットがクライアント／ＳＴＢへ送信されるとすぐに、すなわち、マルチキャストストリームに追いつくことが実現されたとき、停止することができる。
【００３１】
スケーリングの目的で、ＦＣＣサーバからの同時ユニキャストストリームの数は、最小にされる必要がある。これを達成するために取ることができる１つの手段は、ユニキャストサーバが送信する帯域幅を最大にする（バーストする）ことによるものであり、実際には、バーストが高いほど、バースト期間が短くなり、このことはおそらく、バーストのための（他の）同時要求の数を減らす。
【００３２】
サーバのスケーリングもまた、短いセッション（すなわち、ＦＣＣバースト期間）によって良い影響を受ける場合があり、これは（セッションをオープンに保つために）より少ないサーバ処理能力を必要とするからである。
【００３３】
ＦＣＣアプリケーションは、よって、クライアントとサーバの間のパスに沿った使用可能な帯域幅を考慮に入れることによって、最適化されることが可能である。実用化において、使用可能な帯域幅の制約は、サーバ側で容易に知られることが可能である（図１を参照）。以下の場合が関連する場合がある（このリストは網羅的ではない）：
− 使用可能な帯域幅はクライアント毎に静的であり、中央マネージャを介してＦＣＣサーバで使用可能にされる
− 使用可能な帯域幅は、アクセスマルチプレクサにおいて知られており、プロトコル（例えば、ＤＳＬ同期レートをエクスポートすることを可能にする、ＩＥＴＦによる定義下の、アクセスノード制御プロトコル（ＡＮＣＰ）であって、同期レートは、ＦＣＣのための使用可能な帯域幅を知るための部分情報のみである）を介して、ＦＣＣサーバへエクスポートされる
− 使用可能な帯域幅は、アクセスマルチプレクサにおいて知られており、（モデムがこの情報をＦＣＣ要求に挿入するようになるか、クライアントがこの情報をＦＣＣ要求に挿入するようになるかに応じて）モデムまたはＦＣＣクライアントへエクスポートされる。
− 使用可能な帯域幅は、モデムにおいて知られており、ＦＣＣクライアントへエクスポートされる
− 使用可能な帯域幅は、モデムまたはアクセスマルチプレクサにおいて知られており、ＦＣＣ要求に挿入される、
− 使用可能な帯域幅は、アクセスマルチプレクサとＦＣＣサーバの間のアグリゲーションエンティティにおいて知られており、ＦＣＣ要求に挿入される。
【００３４】
使用可能な帯域幅情報をＦＣＣ要求の内部に挿入することによって、ＦＣＣサーバはそれ自体で、どのくらいの量をバーストすることができるかを決定することができる。リソース自体のための要求は、スケーリング最適化の利点を生かすには高すぎる遅延（ハンドシェーキングによる）を導入するようになるので、ＩｎｔＳｅｒｖを使用する従来技術の機構は次善となる。
【００３５】
特定の実装として、クライアントを、いつ何時でもファーストマイルにおける最小の使用可能な帯域幅を識別するいくつかのカテゴリに分類することができる。各カテゴリは次いで、ＦＣＣ要求において、容易に、暗示的に符号化されることが可能である（例えば、すべてが同じＦＣＣサーバへ向けて経路指定する、異なる宛先ＩＰアドレスのセットを、カテゴリ毎に１つずつ使用することによる）。これは、要求に追加される明示的情報要素に代わるものである。例えば、常に約８Ｍｂｐｓで同期し、そのために１Ｍｂｐｓのベストエフォートトラフィックが予約されるＤＳＬアクセスは、なお３Ｍｂｐｓの帯域幅を使用可能に保ちながら、２つの２Ｍｂｐｓのビデオチャネルを並行して搬送することができる。すなわち、各ビデオチャネルは、１．５Ｍｂｐｓの超過レートを追加するか、または、３．５Ｍｂｐｓでバーストを可能にすることができる。
【００３６】
ＩＰＴＶのためのファーストマイルリソース割り当て
ファーストマイルアクセス（例えば、ＶＤＳＬ）の制限された帯域幅により、エンドユーザのための同時ビデオセッションの数は制限される。エンドユーザが新しいビデオセッションを要求するとき、ファーストマイル上の空きリソースに基づいて、この要求がａ．ｏ．を与えられることが可能であるかどうかを検証することは、典型的にはネットワークの責任である。
【００３７】
ＩＰＴＶ配置において、ビデオストリームが可能であるかどうかを確かめるために、ファーストマイル帯域幅リソースをチェックするだけで十分である場合がある。ファーストマイルの使用可能な帯域幅がビデオオンデマンド要求において符号化される場合（本発明のように）、関連付けられたＶＯＤ−サーバは、サービスが可能であるかどうかを直ちにチェックし、要求されたコンテンツを流すか、または、リソースが使用可能でないことをエンドユーザに信号で伝えることができる。これは、（中央）リソースブローカによる代替方式よりはるかに高速かつ容易である。このような方式では、リソースブローカは、実際の帯域幅使用について知るために、すべてのユーザプロファイルを維持し、１つまたは複数のネットワークノードとのインタフェースを取る必要がある。
【００３８】
本発明は、事前のリソース割り当て段階を回避することによって、クライアント−サーバセッションが非常に高速にインタラクトすることを可能にする。これは、使用可能なリソースについての情報要素を、クライアント−サーバ要求に挿入する（明示的に、暗示的に、または、固有のクライアント識別子を参照することにより、この識別子は、リソースについての情報がどのようにサーバにとって使用可能にされるかの代替方法とのリンクを作成する）ための能力によって実現される。本発明は、クライアント要求時に最初にネットワークリソースをチェックする必要なしに、高速なサーバ応答を可能にする。本発明はさらに、（使用可能な）リソース調整されたサービス配信によって、サーバ、すなわち、そのスケーラビリティを最適化することを可能にする。エンドユーザおよびネットワークデータ（例えば、ユーザプロファイル）の中央維持は、回避されることが可能である。
【００３９】
本発明が、具体的な実施形態を参照することによって例示されたが、本発明が前述の例示的実施形態の詳細に限定されないこと、および、本発明が、その精神および範囲から逸脱することなく、様々な変更および修正と共に実施される場合があることは、当業者には明らかになるであろう。本実施形態は、したがって、あらゆる点において、例示的であり、限定的ではないとして見なされるべきであり、本発明の範囲は、前述の記載によってではなく、むしろ添付の特許請求の範囲によって示され、特許請求の範囲と均等の意味および範囲内に入るすべての変更は、したがって、その中に包含されることが意図される。すなわち、基礎的、基本的な原理の精神および範囲内に入り、その本質的な属性が本特許出願において特許請求の範囲に記載される、あらゆる修正、変形形態または均等物を包含することが企図される。「含む（ｃｏｍｐｒｉｓｉｎｇ）」または「含む（ｃｏｍｐｒｉｓｅ）」という語は、他の要素またはステップを除くものではないこと、「１つの（ａ）」または「１つの（ａｎ）」という語は、複数を除くものではないこと、および、コンピュータシステム、プロセッサ、または別の統合ユニットなど、単一の要素は、特許請求の範囲に列挙されたいくつかの手段の機能を実行する場合があることは、本特許出願の読者によってさらに理解されよう。特許請求の範囲におけるいかなる参照符号も、関係している各請求項を限定するように解釈されてはならない。「第１」、「第２」、「第３」、「ａ」、「ｂ」、「ｃ」などの語は、説明において、または特許請求の範囲において使用されるとき、類似の要素またはステップの間で区別するために導入され、必ずしも連続的または時系列の順序を記載していない。同様に、「上部（ｔｏｐ）」、「底部（ｂｏｔｔｏｍ）」、「上に（ｏｖｅｒ）」、「下に（ｕｎｄｅｒ）」などの語は、説明の目的で導入され、必ずしも相対的位置を示すものではない。そのように使用される語は、適切な状況下で交換可能であり、本発明の実施形態は、本発明によれば、他の順序で、または、上記で記載もしくは例示された（１つまたは複数の）ものとは異なる方向において、動作することができることを理解されたい。
【技術分野】
【０００１】
本発明は、一般にデータストリームのトラフィック管理の分野に関する。
【背景技術】
【０００２】
今日のＩＰネットワークは、異なるサービス品質（ＱｏＳ）を必要とする通信にかなりよく対処している。ネットワークが過剰供給されているか、または、ＩｎｔＳｅｒｖおよびＤｉｆｆＳｅｒｖのように、トラフィック管理技術が適用されている。ＩｎｔＳｅｒｖおよびＤｉｆｆＳｅｒｖは、当技術分野でよく知られている技術である。
【０００３】
ＩｎｔＳｅｒｖ（Ｉｎｔｅｇｒａｔｅｄ Ｓｅｒｖｉｃｅｓ）は、ネットワーク上でサービス品質（ＱｏＳ）を保証するために要素を特定する、きめの細かいシステムである。ＩｎｔＳｅｒｖは、例えば、ビデオおよび音声が途切れることなく受信機に達することを可能にするために、使用されることが可能である。ＩｎｔＳｅｒｖの考えは、システム内のあらゆるルータはＩｎｔＳｅｒｖを実装し、ある種の保証を必要とするあらゆるアプリケーションは、個別の予約をしなければならないというものである。いわゆる「ｆｌｏｗ ｓｐｅｃｓ」は、予約が何のためのものであるかを記述している。ＩｎｔＳｅｒｖは、フローベースであると言われている。フロー毎の精度のため、ＩｎｔＳｅｒｖアーキテクチャは、サービスプロバイダネットワークにおいて必要とされる規模に合わせてスケーリングすることに、重大な困難さを有する。スケーリングの問題はまた、このアーキテクチャが幅広い配置を享受していないことについての、主な理由の１つにもなっている。
【０００４】
ＤｉｆｆＳｅｒｖ（Ｄｉｆｆｅｒｅｎｔｉａｔｅｄ Ｓｅｒｖｉｃｅｓ）は、ネットワークトラフィックを分類、管理し、現代のＩＰネットワーク上でサービス品質（ＱｏＳ）保証を提供するための、単純で、スケーラブルな、クラスベースの、きめの粗い機構を特定する、コンピュータネットワーキングアーキテクチャである。ＤｉｆｆＳｅｒｖは、例えば、単純なベストエフォートトラフィック保証を、ウェブトラフィックまたはファイル転送など、重大ではないサービスに提供しながら、低レイテンシの、保証されたサービスを、音声またはビデオなど、重大なネットワークトラフィックに提供するために、使用されることが可能である。ＤｉｆｆＳｅｒｖは特に、（あらゆるトラフィックフローが個別のハンドリングを必要とするようになる、ＩｎｔＳｅｒｖとは対照的に）すべてのトラフィックが限定されたクラスのセットにグループ化され、所与のクラスのすべてのトラフィックが等しいものとして扱われるので、多くのトラフィックフローがバックボーンネットワークを介して集約または移送されるところで、うまくいく。ＤｉｆｆＳｅｒｖは、スケーラブルで実装可能なアーキテクチャとして広く見なされており、世界中で、サービスプロバイダＩＰバックボーンネットワークの大部分において見られることが可能である。
【０００５】
いくつかのクライアント−サーバアプリケーションセッションでは、必要とされたネットワークリソースは、適切なサービス保証のための使用可能なネットワークリソースと比較される必要があるので、フローベースの割り当ては唯一の選択肢である。ＱｏＳに対してパケットをどのように扱うかの決定は、パケット毎およびクラス毎のベースで行われるので、クラスベースの機構はそのような比較を包含しないことに留意されたい。そのようなアプリケーションのために、ネットワーク制限（例えば、ブロードバンドアクセスのためのファーストマイル帯域幅制約）のせいで、オーバーブッキングが選択肢でない場合、今日では、ＩｎｔＳｅｒｖトラフィック管理しか選ぶことができない。その複雑さのため、ＩｎｔＳｅｒｖソリューションは、すでに上述したように、容易にはスケーリングしない。ＩｎｔＳｅｒｖのさらなる問題は、リソース割り当て段階が必要とされることであり、このことは、クライアント−サーバの双方向性、および、よって、リソース割り当て機構のレートに影響を及ぼす。ＩｎｔＳｅｒｖは、クライアント要求にサービスするためにどのくらいのリソースが使用可能であるかの知識を、サーバが利用することも可能にしない。
【０００６】
Ｃｉｓｃｏは、同社のＶｉｓｕａｌ Ｑｕａｌｉｔｙ Ｅｘｐｅｒｉｅｎｃｅコンセプトについての公開ホワイトペーパー（ｈｔｔｐ：／／ｗｗｗ．ｃｉｓｃｏ．ｃｏｍ／ｅｎ／ＵＳ／ｓｏｌｕｔｉｏｎｓ／ｃｏｌｌａｔｅｒａｌ／ｎｓ３４１／ｎｓ５２４／ｎｓ６１０／ｎｅｔ＿ｉｍｐｌｅｍｅｎｔａｔｉｏｎ＿ｗｈｉｔｅ＿ｐａｐｅｒ０９００ａｅｃｄ８０５７ｆ２９０．ｈｔｍｌを参照）において、コールアドミッション制御（ＣＡＣ）のためのオンパスプロシージャを記載している。それは、ＲＳＰＶ（リソース予約プロトコル）という、ＩｎｔＳｅｒｖをサポートするＩＥＴＦ（ＲＦＣ ２２０５）によって特定されたプロトコルに基づいている。この提案はまた、顧客要求に対する応答性にも取り組んでいる。しかし、提案されたソリューションは、ハンドシェーキングに基づいたままであるので、リソース割り当て機構のレートが落とされるという、重要な欠点を有しており、このことは応答性に悪影響を及ぼす。提案されたソリューションのさらなる欠点は、
− サーバを最適化するためのリソースの可用性（すなわち、スケーラビリティ）についての情報を使用することを可能にしない、
− コアネットワーク内の使用のために意図されており、アクセス／ファーストマイル向けではない、
− ＭＰＬＳ（マルチプロトコルラベルスイッチング）または一般ルーティングカプセル化トンネルを介さず、かつ、階層−ＶＰＬＳ／ＶＰＬＳ（仮想プライベートＬＡＮサービス）または他のレイヤ２アグリゲーション技術など、レイヤ２構造を介さず、レイヤ３で経路指定された環境内でのみ使用されることが可能であることである。
【０００７】
動的ホスト構成プロトコル（ＤＨＣＰ）およびポイントツーポイントプロトコルオーバーイーサネット（ＰＰＰｏＥ）オプション８２は、ファーストマイルアクセス（回線）についての帯域幅情報を挿入することを可能にする。この情報は、リンクの物理容量に制限され、したがって、サーバが使用可能な帯域幅について知り、適切に反応するためには、不十分である。
【０００８】
高速チャネル変更（ＦＣＣ）ソリューションは、市場に存在している（例えば、ＭｉｃｒｏｓｏｆｔのＩｎｓｔａｎｔ Ｃｈａｎｎｅｌ Ｃｈａｎｇｅ（ＩＣＣ）、ＣｉｓｃｏのＲａｐｉｄ Ｃｈａｎｎｅｌ Ｃｈａｎｇｅ（ＲＣＣ））。これらのソリューションのいずれも、スケーリングの目的で最適化するために、ファーストマイルにおける使用可能な帯域幅を考慮に入れていない。
【０００９】
ＥＴＳＩ ＴＩＳＰＡＮは、ＶｏＤおよびＬＰＴＶの両方の混合サポートにおける、ファーストマイルビデオ帯域幅割り当てのために解決するために、集中型ＲＡＣＦ（リソース受け入れ制御機能）を説明している。記載されたソリューションは、しかし、比較的遅く、かなり複雑である（例えば、顧客毎に維持されるべき構成データ、および、中央サーバの必要性のため）。
【先行技術文献】
【非特許文献】
【００１０】
【非特許文献１】Ｖｉｓｕａｌ Ｑｕａｌｉｔｙ Ｅｘｐｅｒｉｅｎｃｅコンセプト、ｈｔｔｐ：／／ｗｗｗ．ｃｉｓｃｏ．ｃｏｍ／ｅｎ／ＵＳ／ｓｏｌｕｔｉｏｎｓ／ｃｏｌｌａｔｅｒａｌ／ｎｓ３４１／ｎｓ５２４／ｎｓ６１０／ｎｅｔ＿ｉｍｐｌｅｍｅｎｔａｔｉｏｎ＿ｗｈｉｔｅ＿ｐａｐｅｒ０９００ａｅｃｄ８０５７ｆ２９０．ｈｔｍｌ
【発明の概要】
【発明が解決しようとする課題】
【００１１】
本発明は、従来技術のソリューションの上述の欠点を回避または克服しながら、通信セッションがクライアントとサーバの間で確立される、データトラフィック管理のための方法およびデバイスを提供することを目的とする。
【課題を解決するための手段】
【００１２】
本発明は、クライアントとサーバの間で通信セッションを確立するための方法を提供する。この方法は、
− 前記サーバが、クライアント−サーバ通信セッションを確立するためのネットワークリソースのための要求を受信するステップであって、前記要求は、クライアントの識別を少なくとも含むステップ、
− サーバにおいて、クライアント−サーバ通信セッションのための使用可能なネットワークリソースについての情報を収集するステップ、および
− 前記使用可能なネットワークリソースについての情報を考慮に入れて、クライアントとの通信セッションを確立するステップを含む。
【００１３】
有利な実施形態では、使用可能なリソースについての情報の少なくとも一部が、前記ネットワークリソースのための要求内に含まれる。好ましくは、前記情報の少なくとも一部が、前記クライアントによって前記要求に追加される。有利には、情報の少なくとも一部が、クライアントとサーバの間の伝送路に沿って、要求に追加されてもよい。
【００１４】
一実施形態では、情報の少なくとも一部が、サーバによって提供される。
【００１５】
有利には、情報の少なくとも一部が、通信管理を行うことができる外部デバイスによって提供される。
【００１６】
好ましい実施形態では、通信セッションがビデオオンデマンドである。有利には、通信セッションが次いで、サーバからクライアントへのユニキャストストリームを介して確立される。
【００１７】
別の好ましい実施形態では、通信セッションがリニアプログラミングＴＶサービスである。
【００１８】
別の実施形態では、通信セッションが、少なくとも部分的にはバーストモードにおいて行われる。
【００１９】
別の態様では、本発明は、クライアント−サーバ通信セッションにおいて、サーバとして動作するために構成されたデバイスに関する。このデバイスは、クライアントからネットワークリソースのための要求を受信するための手段を含み、クライアント−サーバ通信セッションのための使用可能なネットワークリソースについての情報を受信するため、および、使用可能なネットワークリソースについての情報を考慮に入れて、通信セッションを確立するためにさらに構成されることを特徴とする。
【００２０】
さらなる実施形態では、本発明は、クライアントとサーバの間の通信セッションにおける使用のためのデバイスに関する。このデバイスは、使用可能なネットワークリソースについての情報を、サーバに対するネットワークリソースのための要求に追加するために構成されることを特徴とする。有利には、このデバイスは、前記ネットワークリソースのための要求を生成するためにさらに構成される。
【図面の簡単な説明】
【００２１】
【図１】本発明の一実施形態による、サーバに対する要求への、使用可能な（帯域幅）リソースの情報の追加を表す図である。
【発明を実施するための形態】
【００２２】
本発明では、一般的なフローベースのトラフィック管理機構が提案され、好ましい実施形態によれば、使用可能なネットワークリソースについての情報は、クライアント−サーバセッション要求自体の一部となり、サーバは、いかなるハンドシェークまたは往復のメッセージングをも必要とせずに、それに反応することができる。
【００２３】
ＴＣＰ／ＩＰプロトコルスイートを使用し、そのために（ＩＰ）ネットワークリソースが保証される必要のある、クライアント−サーバアプリケーションのための非常に高速な双方向性を保証するために、本発明は、一実施形態において、使用可能なリソースについて通知する情報要素を、クライアント要求に追加することを提案する（情報をエクスポートする）。これらの情報要素は、始点において（すなわち、クライアントにおいて）追加されるか、または、サーバへのパスに沿って（場合によっては、複数のポイントにおいて）挿入されることが可能である。場合によっては、サーバ自体において知られている制限をも考慮に入れながら、すなわち、上記クライアント−サーバアプリケーションのための使用可能なリソースまたはその一部を採用することによって、受信において、サーバはそれに応じて直ちに応答することができる。
【００２４】
使用可能なリソースについての情報を挿入するクライアントまたはいずれかのネットワークデバイスは、使用可能なリソースを承知しているか、または、クライアント−サーバセッションに関係するインタフェース（複数可）のための外部リソース管理エンティティ（または、複数のエンティティ）によって通知される。全体の反応性を高くする（高速な要求の発行および後続のサーバアクション）ために、リソース使用更新のためのレイテンシは、特定のサービスのためのソリューションの適用性を制限するために重要である。
【００２５】
クライアント−サーバセッションに関係する使用可能なリソースの一部が（しばしば）変化しないとき、特定の状況が存在し、その場合、（使用可能なリソースのその部分についての情報をエクスポートするために）追加のレイテンシがその部分のために適用されることはない。このような静的状況はまた、使用可能なリソースが遅いレートでのみ変化する場合（すなわち、安定期間中に多数のクライアント−サーバ要求が発生するとき）にも存在するが、そこで、クライアントは、非リアルタイムまたは準リアルタイムのシステムによって（例えば、電気通信管理プラットフォームの仲介によって）、通知され続ける。
【００２６】
もう１つの特定の場合は、サーバ自体が、例えば、外部リソース管理エンティティによって、所与のクライアント要求に関連する使用可能なリソースについて通知されるときである。このような場合、クライアント要求が、そのサーバにおいて知られている情報に関連付けられることが可能であるクライアント識別を示すならば、サーバは自律的に動作することができる。
【００２７】
ＩＰＴＶに関連した本発明のいくつかの具体的な実施形態が、後述される。
【００２８】
今日のＩＰＴＶアプリケーションでは、ケーブルまたは地上波において知られているような放送ＴＶによく似ている、ビデオオンデマンドおよびＬＰＴＶ（リニアプログラミングＴＶ）が共に、典型的にサポートされる。今日の（例えば、ＶＤＳＬにおける）制限されたアクセス帯域幅と共に、エンドユーザが有する、これらのサービスに対するリアルタイムの期待のために、本発明の以下の実施形態は、この環境において適用される。
【００２９】
高速チャネル変更
エンドユーザがＬＰＴＶサービスにおいて、あるプログラムから別のものへと変更するとき、エンドユーザは、自分のリモートコントロール上で選択されたチャネルを押した直後に新しいイメージを見ることを期待する（ザッピング）。いずれかの特別な配置がなければ、クライアントから（ＬＰＴＶ放送）サーバ自体へのシグナリングにおける遅延のため、しかし、また、クライアントにおいて新しい画像を構築するための遅延のためにも、遅延はすぐに増加する。実際には、高度に圧縮されたデジタルビデオ信号は、デコーダにおいて新しい画像を速く構築するために、いわゆるアンカーフレームを必要とし、クライアントは（ザッピングの後）、画面上に新しい画像を適切に構築するために、次のアンカーフレーム上で待機しなければならない。
【００３０】
高速チャネル変更は、高速チャネル変更（ＦＣＣ）サーバの使用によって実装されることが可能である。このようなサーバは、関係している（選択された）ＬＰＴＶチャネルから得られたユニキャストストリームを送信することができる。ユニキャストストリームは通常、マルチキャストにおいて、このチャネルを要求したすべてのクライアントへ送信される。特定のクライアント（すなわち、セットトップボックス（ＳＴＢ）上で実行するソフトウェア）がそのチャネルに変更するとき、特定のクライアントは、即時の画像の構築を可能にし、よって、選択されたチャネルへ高速で変更するために、過去からのアンカーフレームで開始するユニキャストストリームを最初に受信する。ユニキャストは、過去からのすべてのパケットがクライアント／ＳＴＢへ送信されるとすぐに、すなわち、マルチキャストストリームに追いつくことが実現されたとき、停止することができる。
【００３１】
スケーリングの目的で、ＦＣＣサーバからの同時ユニキャストストリームの数は、最小にされる必要がある。これを達成するために取ることができる１つの手段は、ユニキャストサーバが送信する帯域幅を最大にする（バーストする）ことによるものであり、実際には、バーストが高いほど、バースト期間が短くなり、このことはおそらく、バーストのための（他の）同時要求の数を減らす。
【００３２】
サーバのスケーリングもまた、短いセッション（すなわち、ＦＣＣバースト期間）によって良い影響を受ける場合があり、これは（セッションをオープンに保つために）より少ないサーバ処理能力を必要とするからである。
【００３３】
ＦＣＣアプリケーションは、よって、クライアントとサーバの間のパスに沿った使用可能な帯域幅を考慮に入れることによって、最適化されることが可能である。実用化において、使用可能な帯域幅の制約は、サーバ側で容易に知られることが可能である（図１を参照）。以下の場合が関連する場合がある（このリストは網羅的ではない）：
− 使用可能な帯域幅はクライアント毎に静的であり、中央マネージャを介してＦＣＣサーバで使用可能にされる
− 使用可能な帯域幅は、アクセスマルチプレクサにおいて知られており、プロトコル（例えば、ＤＳＬ同期レートをエクスポートすることを可能にする、ＩＥＴＦによる定義下の、アクセスノード制御プロトコル（ＡＮＣＰ）であって、同期レートは、ＦＣＣのための使用可能な帯域幅を知るための部分情報のみである）を介して、ＦＣＣサーバへエクスポートされる
− 使用可能な帯域幅は、アクセスマルチプレクサにおいて知られており、（モデムがこの情報をＦＣＣ要求に挿入するようになるか、クライアントがこの情報をＦＣＣ要求に挿入するようになるかに応じて）モデムまたはＦＣＣクライアントへエクスポートされる。
− 使用可能な帯域幅は、モデムにおいて知られており、ＦＣＣクライアントへエクスポートされる
− 使用可能な帯域幅は、モデムまたはアクセスマルチプレクサにおいて知られており、ＦＣＣ要求に挿入される、
− 使用可能な帯域幅は、アクセスマルチプレクサとＦＣＣサーバの間のアグリゲーションエンティティにおいて知られており、ＦＣＣ要求に挿入される。
【００３４】
使用可能な帯域幅情報をＦＣＣ要求の内部に挿入することによって、ＦＣＣサーバはそれ自体で、どのくらいの量をバーストすることができるかを決定することができる。リソース自体のための要求は、スケーリング最適化の利点を生かすには高すぎる遅延（ハンドシェーキングによる）を導入するようになるので、ＩｎｔＳｅｒｖを使用する従来技術の機構は次善となる。
【００３５】
特定の実装として、クライアントを、いつ何時でもファーストマイルにおける最小の使用可能な帯域幅を識別するいくつかのカテゴリに分類することができる。各カテゴリは次いで、ＦＣＣ要求において、容易に、暗示的に符号化されることが可能である（例えば、すべてが同じＦＣＣサーバへ向けて経路指定する、異なる宛先ＩＰアドレスのセットを、カテゴリ毎に１つずつ使用することによる）。これは、要求に追加される明示的情報要素に代わるものである。例えば、常に約８Ｍｂｐｓで同期し、そのために１Ｍｂｐｓのベストエフォートトラフィックが予約されるＤＳＬアクセスは、なお３Ｍｂｐｓの帯域幅を使用可能に保ちながら、２つの２Ｍｂｐｓのビデオチャネルを並行して搬送することができる。すなわち、各ビデオチャネルは、１．５Ｍｂｐｓの超過レートを追加するか、または、３．５Ｍｂｐｓでバーストを可能にすることができる。
【００３６】
ＩＰＴＶのためのファーストマイルリソース割り当て
ファーストマイルアクセス（例えば、ＶＤＳＬ）の制限された帯域幅により、エンドユーザのための同時ビデオセッションの数は制限される。エンドユーザが新しいビデオセッションを要求するとき、ファーストマイル上の空きリソースに基づいて、この要求がａ．ｏ．を与えられることが可能であるかどうかを検証することは、典型的にはネットワークの責任である。
【００３７】
ＩＰＴＶ配置において、ビデオストリームが可能であるかどうかを確かめるために、ファーストマイル帯域幅リソースをチェックするだけで十分である場合がある。ファーストマイルの使用可能な帯域幅がビデオオンデマンド要求において符号化される場合（本発明のように）、関連付けられたＶＯＤ−サーバは、サービスが可能であるかどうかを直ちにチェックし、要求されたコンテンツを流すか、または、リソースが使用可能でないことをエンドユーザに信号で伝えることができる。これは、（中央）リソースブローカによる代替方式よりはるかに高速かつ容易である。このような方式では、リソースブローカは、実際の帯域幅使用について知るために、すべてのユーザプロファイルを維持し、１つまたは複数のネットワークノードとのインタフェースを取る必要がある。
【００３８】
本発明は、事前のリソース割り当て段階を回避することによって、クライアント−サーバセッションが非常に高速にインタラクトすることを可能にする。これは、使用可能なリソースについての情報要素を、クライアント−サーバ要求に挿入する（明示的に、暗示的に、または、固有のクライアント識別子を参照することにより、この識別子は、リソースについての情報がどのようにサーバにとって使用可能にされるかの代替方法とのリンクを作成する）ための能力によって実現される。本発明は、クライアント要求時に最初にネットワークリソースをチェックする必要なしに、高速なサーバ応答を可能にする。本発明はさらに、（使用可能な）リソース調整されたサービス配信によって、サーバ、すなわち、そのスケーラビリティを最適化することを可能にする。エンドユーザおよびネットワークデータ（例えば、ユーザプロファイル）の中央維持は、回避されることが可能である。
【００３９】
本発明が、具体的な実施形態を参照することによって例示されたが、本発明が前述の例示的実施形態の詳細に限定されないこと、および、本発明が、その精神および範囲から逸脱することなく、様々な変更および修正と共に実施される場合があることは、当業者には明らかになるであろう。本実施形態は、したがって、あらゆる点において、例示的であり、限定的ではないとして見なされるべきであり、本発明の範囲は、前述の記載によってではなく、むしろ添付の特許請求の範囲によって示され、特許請求の範囲と均等の意味および範囲内に入るすべての変更は、したがって、その中に包含されることが意図される。すなわち、基礎的、基本的な原理の精神および範囲内に入り、その本質的な属性が本特許出願において特許請求の範囲に記載される、あらゆる修正、変形形態または均等物を包含することが企図される。「含む（ｃｏｍｐｒｉｓｉｎｇ）」または「含む（ｃｏｍｐｒｉｓｅ）」という語は、他の要素またはステップを除くものではないこと、「１つの（ａ）」または「１つの（ａｎ）」という語は、複数を除くものではないこと、および、コンピュータシステム、プロセッサ、または別の統合ユニットなど、単一の要素は、特許請求の範囲に列挙されたいくつかの手段の機能を実行する場合があることは、本特許出願の読者によってさらに理解されよう。特許請求の範囲におけるいかなる参照符号も、関係している各請求項を限定するように解釈されてはならない。「第１」、「第２」、「第３」、「ａ」、「ｂ」、「ｃ」などの語は、説明において、または特許請求の範囲において使用されるとき、類似の要素またはステップの間で区別するために導入され、必ずしも連続的または時系列の順序を記載していない。同様に、「上部（ｔｏｐ）」、「底部（ｂｏｔｔｏｍ）」、「上に（ｏｖｅｒ）」、「下に（ｕｎｄｅｒ）」などの語は、説明の目的で導入され、必ずしも相対的位置を示すものではない。そのように使用される語は、適切な状況下で交換可能であり、本発明の実施形態は、本発明によれば、他の順序で、または、上記で記載もしくは例示された（１つまたは複数の）ものとは異なる方向において、動作することができることを理解されたい。
【特許請求の範囲】
【請求項１】
クライアントとサーバの間で通信セッションを確立するための方法であって、前記方法は、
前記サーバにおいて、前記クライアント−サーバ通信セッションを確立するためのネットワークリソースのための要求を受信するステップであって、前記要求は、前記クライアントの識別を少なくとも含むステップ、
前記サーバにおいて、前記クライアント−サーバ通信セッションのための使用可能なネットワークリソースについての情報を収集するステップ、および
前記使用可能なネットワークリソースについての情報を考慮に入れて、前記クライアントとの前記通信セッションを確立するステップを含む、通信セッションを確立するための方法。
【請求項２】
前記使用可能なリソースについての情報の少なくとも一部が、前記ネットワークリソースのための要求内に含まれる、請求項１に記載の通信セッションを確立するための方法。
【請求項３】
前記情報の少なくとも一部が、前記クライアントによって前記要求に追加される、請求項２に記載の通信セッションを確立するための方法。
【請求項４】
前記情報の少なくとも一部が、前記クライアントと前記サーバの間の伝送路に沿って、前記要求に追加される、請求項２または３に記載の通信セッションを確立するための方法。
【請求項５】
前記情報の少なくとも一部が、前記サーバによって提供される、請求項１から４のいずれか一項に記載の通信セッションを確立するための方法。
【請求項６】
前記情報の少なくとも一部が、通信管理を行うことができる外部デバイスによって提供される、請求項１から５のいずれか一項に記載の通信セッションを確立するための方法。
【請求項７】
前記通信セッションが、ビデオオンデマンドまたはリニアプログラミングＴＶサービスである、請求項１から６のいずれか一項に記載の通信セッションを確立するための方法。
【請求項８】
前記通信セッションが、前記サーバから前記クライアントへのユニキャストストリームを介して確立される、請求項１から７のいずれか一項に記載の通信セッションを確立するための方法。
【請求項９】
前記通信セッションが、少なくとも部分的にはバーストモードにおいて行われる、請求項１から８のいずれか一項に記載の通信セッションを確立するための方法。
【請求項１０】
リニアプログラミングＴＶサービスにおいて、クライアントによって要求された高速チャネル変更を実装するための方法であって、請求項８に記載の方法が適用され、サーバは、高速画像構築を可能にするために、ユニキャストにおいて、アンカーフレームを前記クライアントへ送信する、方法。
【請求項１１】
クライアント−サーバ通信セッションにおいて、サーバとして動作するために構成され、クライアントからネットワークリソースのための要求を受信するための手段を含むデバイスであって、前記デバイスはさらに、前記クライアント−サーバ通信セッションのための使用可能なネットワークリソースについての情報を受信するため、および、前記使用可能なネットワークリソースについての情報を考慮に入れて、前記通信セッションを確立するために構成されることを特徴とする、デバイス。
【請求項１２】
クライアントとサーバの間の通信セッションにおける使用のためのデバイスであって、前記デバイスは、使用可能なネットワークリソースについての情報を、前記サーバに対するネットワークリソースのための要求に追加するために構成されることを特徴とする、デバイス。
【請求項１３】
前記ネットワークリソースのための要求を生成するためにさらに構成される、請求項１２に記載のデバイス。
【請求項１４】
モデムまたはアクセスマルチプレクサである、請求項１２に記載のデバイス。
【請求項１】
クライアントとサーバの間で通信セッションを確立するための方法であって、前記方法は、
前記サーバにおいて、前記クライアント−サーバ通信セッションを確立するためのネットワークリソースのための要求を受信するステップであって、前記要求は、前記クライアントの識別を少なくとも含むステップ、
前記サーバにおいて、前記クライアント−サーバ通信セッションのための使用可能なネットワークリソースについての情報を収集するステップ、および
前記使用可能なネットワークリソースについての情報を考慮に入れて、前記クライアントとの前記通信セッションを確立するステップを含む、通信セッションを確立するための方法。
【請求項２】
前記使用可能なリソースについての情報の少なくとも一部が、前記ネットワークリソースのための要求内に含まれる、請求項１に記載の通信セッションを確立するための方法。
【請求項３】
前記情報の少なくとも一部が、前記クライアントによって前記要求に追加される、請求項２に記載の通信セッションを確立するための方法。
【請求項４】
前記情報の少なくとも一部が、前記クライアントと前記サーバの間の伝送路に沿って、前記要求に追加される、請求項２または３に記載の通信セッションを確立するための方法。
【請求項５】
前記情報の少なくとも一部が、前記サーバによって提供される、請求項１から４のいずれか一項に記載の通信セッションを確立するための方法。
【請求項６】
前記情報の少なくとも一部が、通信管理を行うことができる外部デバイスによって提供される、請求項１から５のいずれか一項に記載の通信セッションを確立するための方法。
【請求項７】
前記通信セッションが、ビデオオンデマンドまたはリニアプログラミングＴＶサービスである、請求項１から６のいずれか一項に記載の通信セッションを確立するための方法。
【請求項８】
前記通信セッションが、前記サーバから前記クライアントへのユニキャストストリームを介して確立される、請求項１から７のいずれか一項に記載の通信セッションを確立するための方法。
【請求項９】
前記通信セッションが、少なくとも部分的にはバーストモードにおいて行われる、請求項１から８のいずれか一項に記載の通信セッションを確立するための方法。
【請求項１０】
リニアプログラミングＴＶサービスにおいて、クライアントによって要求された高速チャネル変更を実装するための方法であって、請求項８に記載の方法が適用され、サーバは、高速画像構築を可能にするために、ユニキャストにおいて、アンカーフレームを前記クライアントへ送信する、方法。
【請求項１１】
クライアント−サーバ通信セッションにおいて、サーバとして動作するために構成され、クライアントからネットワークリソースのための要求を受信するための手段を含むデバイスであって、前記デバイスはさらに、前記クライアント−サーバ通信セッションのための使用可能なネットワークリソースについての情報を受信するため、および、前記使用可能なネットワークリソースについての情報を考慮に入れて、前記通信セッションを確立するために構成されることを特徴とする、デバイス。
【請求項１２】
クライアントとサーバの間の通信セッションにおける使用のためのデバイスであって、前記デバイスは、使用可能なネットワークリソースについての情報を、前記サーバに対するネットワークリソースのための要求に追加するために構成されることを特徴とする、デバイス。
【請求項１３】
前記ネットワークリソースのための要求を生成するためにさらに構成される、請求項１２に記載のデバイス。
【請求項１４】
モデムまたはアクセスマルチプレクサである、請求項１２に記載のデバイス。
【図１】
【公表番号】特表２０１１−５２７１６９（Ｐ２０１１−５２７１６９Ａ）
【公表日】平成２３年１０月２０日（２０１１．１０．２０）
【国際特許分類】
【出願番号】特願２０１１−５１７０１３（Ｐ２０１１−５１７０１３）
【出願日】平成２１年７月６日（２００９．７．６）
【国際出願番号】ＰＣＴ／ＥＰ２００９／００４８７２
【国際公開番号】ＷＯ２０１０／００３６１６
【国際公開日】平成２２年１月１４日（２０１０．１．１４）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．イーサネット
【出願人】（３９１０３０３３２）アルカテル−ルーセント (1,149)
【Ｆターム（参考）】
【公表日】平成２３年１０月２０日（２０１１．１０．２０）
【国際特許分類】
【出願日】平成２１年７月６日（２００９．７．６）
【国際出願番号】ＰＣＴ／ＥＰ２００９／００４８７２
【国際公開番号】ＷＯ２０１０／００３６１６
【国際公開日】平成２２年１月１４日（２０１０．１．１４）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．イーサネット
【出願人】（３９１０３０３３２）アルカテル−ルーセント (1,149)
【Ｆターム（参考）】
[ Back to top ]