JP4903786B2 - パケット交換データ・ストリームにおけるリアルタイム連続データを制御するための方法、システムおよびその使用方法、ならびに当該方法を用いて提供されるリアルタイム連続データ・サービス - Google Patents

Description

本発明は、データ・パッケージを含むパケット交換データ・ストリーム内のリアルタイム連続データの非認可の転送を制御する方法に関する。

さらに、本発明は、上述の方法を用いてパケット交換データ・ストリーム内のリアルタイム連続データの非認可の転送を制御するためのシステムに関し、パケット交換データ・ストリームはデータ・パッケージを含み、システムはデータ・ストリームを受信するための入力およびデータ・ストリームを送信するための出力を備える。

また、本発明は、パケット交換データ網における当該システムの使用、および本発明の方法を用いて提供されるリアルタイム・データ・サービスに関する。

ＤＳＬ（Digital Subscriber Line）および他の広帯域ケーブル接続（たとえば、ケーブルモデム・ソリューション）の少なくともいずれかのような広帯域通信ソリューションが、ＩＰ接続を大衆に提供するために広く使用されている。例えばＡＤＳＬ（Asynchronous Digital Subscriber Line）は、ＰＯＴＳ(Plain Old Telephone Service)に使用する加入者線のような通常の銅線上で高速のデータ伝送を可能にするデータ通信技術である。ケーブルモデム・サービスもまた広く使用されており、家庭にいるユーザに広帯域のインターネット・アクセスを提供する。このサービスは、ケーブルテレビのインフラ上でデータ信号を変調するように設計されている。さらに、無線広帯域通信サービスが目立って増加してきている。例えば、ＬＤＭＳ(Local Multipoint Distribution Service)、ＭＭＤＳ(Multichannel Multipoint Distribution Service)、ＷｉＭＡＸ(Worldwide interoperability for Microwave Access)およびＨＩＰＥＲＭＡＮ(High Performance Radio Metropolitan Area Network)などがある。

広帯域サービスのほとんどは、高速のインターネット接続を提供するだけでなく、リアルタイム連続データ・サービスを提供するにも、十分高速である。リアルタイム連続データ・サービスの例として、ＶｏＩＰ（Voice over IP）、双方向型オンライン・ゲーム、及び、データ網を経由して遠隔制御処理を行うようなその他の双方向サービスがある。その他のサービスとしては、ストリーミング映像および音声を伴うものがある。十分なデータ量を転送でき、かつ十分な品質を維持するための速度を提供可能な信号を確立するため、これらのサービスの提供には、多くの場合、送信側と受信側との間で、連続したデータ・ストリームのフローであることが必要である。多くの場合、これらのサービスは極めて遅延の影響を受けやすい。この点において、データは送信された直後に受信されなければならないということを意味しており、それらのサービスは、リアルタイム・サービスであると言ってもよい。以下では、上記のように連続的かつリアルタイムにデータを処理する必要があるサービスを、リアルタイム連続データ・サービスと呼ぶものとする。

非特許文献１により、例えばＵＭＴＳ（Universal Mobile Telecommunications System）について定義されるように、データ通信サービスのほとんどは、会話型クラス、ストリーミング型クラス、双方向型クラスおよびバックグラウンド型クラスのような４種類のクラスに分類することができる。これらのクラスは、データ・サービスのサービス品質に対して影響を受ける度合いを規定している。

会話型クラスおよびストリーミング型クラスは、主に、上述のリアルタイム連続データ・サービスの多くを含み、リアルタイム・トラヒック・フローの伝送に使用されることを目的としている。会話型クラスとストリーミング型クラスとを分ける主な要因は、データ・トラヒックにおける遅延に対してそれらが影響を受ける度合いである。どちらのクラスのサービスもデータ・トラヒックにおける遅延に影響を受けやすいが、しかしながら、会話型クラスのサービスの場合、サービス品質の要求レベルが人間の知覚によって決められる。

例えば、会話型クラスのサービスは、ＶｏＩＰおよびテレビ会議を含む。会話型クラスは主に、リアルタイムの会話が生きた（人間の）エンドユーザのピア（またはグループ）の間で行われるという事実によって特徴付けられる。リアルタイムの会話方式は、リアルタイム方式の会話の本質により転送時間は短いものであるべきだし、そして同時にストリームの情報要素間の時間関係（変動）がそのままリアルタイム・ストリームに保たれるものであることによって特徴付けられる。許容される最大の転送遅延は、映像および音声会話における人間の知覚により与えられる。したがって、許容可能な転送遅延の上限は非常に厳しく、十分少ない転送遅延を提供できなければ、許容できないほどの品質の欠如をもたらすであろう。

ストリーミング型クラスのサービスは、たとえば、リアルタイム映像およびリアルタイム音声の内、少なくとも何れかを含む。ユーザがリアルタイム映像または音声を見たり聞いたりするときは、リアルタイム・ストリーム方式が適用される。リアルタイム・データ・フローは、常に生きた（人間）あて先が対象となる。このサービスは片方向の転送であり、したがって双方向型ではない。ストリーミング型クラスのサービスの方式はデータ通信では新顔の一つであり、電気通信およびデータ通信システムの双方において多くの新しい要件を提起している。このクラスのサービスの特徴は、フロー内の情報要素（たとえば、サンプル、パケット）間の時間関係（変動）は維持されるべきである一方、全体的な転送遅延に対してはいかなる要件を持たないことによって特徴付けられる。エンド・ツー・エンド・フローの遅延変動は、ストリームにおける情報要素間の時間関係（変動）を維持するように制限されなければならない。しかし、ストリームは、通常、ユーザ端末側の受信端末で時間調整されるので、伝送媒体上での最大の許容遅延は、アプリケーションの時間調整機能の性能により与えられる。ここで、会話型クラスと比較すると、人間の知覚の制限により与えられる会話型クラスと比較して、ストリーミング型クラスでは許容遅延変動は遥かに大きい。

双方向型クラスのサービス方式は、例えば、人間の場合もあり機械の場合もあるエンドユーザが遠隔装置（たとえば、サーバ）からのデータをオンラインで要求する場合に適用される。人間と遠隔装置との双方向サービスの例としては、ウェブ閲覧、データベース検索、サーバ・アクセス等がある。機械と遠隔装置との双方向サービスの例としては、測定記録に対するポーリングおよび自動データベース問い合わせ（テレマティックス）がある。双方向型クラスのトラヒックは、総合的なレベルでエンドユーザの要求・応答パターンによって特徴付けられるデータ通信方式である。メッセージの宛先では、一定の時間内にメッセージ（応答）を期待している構成要素がある。したがって、ラウンド・トリップ遅延時間は重要な属性のひとつである。別の特徴としては、そのパケットの内容が透過的に（低ビット誤り率で）転送されるべき点があげられる。

バックグラウンド型クラスのサービスの仕組みは、エンドユーザ（通常は、コンピュータ）がバックグラウンドでデータ・ファイルを送受信する場合に適用される。例えば、電子メールのバックグラウンド配信、ＳＭＳ(Short Message Service)、データベースのダウンロードおよび測定記録の受信がある。バックグラウンド型クラスのトラヒックは、総合的なレベルで、データが一定時間内に応答されることを宛先が期待していないということによって特徴付けられるデータ通信方式である。したがって、この方式は大体の場合、到達時間に影響されない。別の特徴としては、そのパケットの内容が透過的に（低ビット誤り率で）転送されるべき点がある。各サービス・クラス（会話型クラス、ストリーミング型クラス、双方向型クラスおよびバックグラウンド型クラス）の上記規定および説明から明らかなように、会話型クラスおよびストリーミング型クラスのサービスは、エンド・ツー・エンド間でデータが連続的に満たされることによって特徴付けられる。パケット交換網では、会話型クラスのサービスのユーザにデータ・パッケージが中断したことを気づかれることなしに、データ・パッケージを元の順序どおりユーザに提供されなければならないため、会話型クラスのサービスではこの要件は非常に厳しい。ストリーミング型クラスのサービスについては、その要件は比較的ゆるいが、それでも、ストリーミング方式では、パッケージは、ユーザに中断したことを気づかれることなく、そして望ましくはその送信後すぐに提示されなければならない。

他方、双方向型クラスおよびバックグラウンド型クラスのサービスにおいては、データ・パッケージの到達時間についての要件を持つ場合もあるが、しかしながら、データが連続して流れることおよび中断に気づかれないことというようなストリーミング方式で提示されなければならないことについては、何ら要件はない。

リアルタイム連続データ・サービスについての上記説明を要約すると、これらのサービスは、双方向（会話型クラス）サービスと非双方向（ストリーミング型クラス）サービスとに分けることができる。双方向サービスは、全体的に短い遅延で高速の双方向通信が行われること、および情報要素の到達時間の変動がわずかであることを必要とする。非双方向サービスは、情報要素の到達時間の変動は制限されるが、一方、一定の全体的な遅延は許容されることもある。ＶｏＩＰおよびテレビ会議、あるいはストリーミング音声／映像は、これら２種類あるリアルタイム連続データ・サービスのクラスのどちらかに、容易に分類することができよう。双方向マルチユーザのゲームは主に、人間の認識力によって伝送の要件が決定される会話型クラスのサービスであることが知られている。

上記観点から、リアルタイム連続データ・サービスについて、当然のことながら、会話型クラスのデータ・サービスを提供するためのデータ接続に対するＱｏＳの要件は、ストリーミング型クラスのデータ・サービスよりもっと厳しく、同様に、ストリーミング型クラスのデータ・サービスを提供するためのデータ接続に対するＱｏＳの要件は、（マルチユーザのゲームを含め）双方向データ・サービスに対するよりももっと厳しい。バックグラウンド型クラスのサービスは、劣ったＱｏＳに対すて影響を受ける度合いが最も少ない。

現在のところ、一部の会話型クラスおよびストリーミング型クラスのリアルタイム連続データ・サービスを利用できる。しかし、広帯域接続のＱｏＳは十分であるといえるけれども、インターネットの性能がリアルタイム連続データ・サービスに提供するには十分に信頼できるものではないという事実のため、大衆に広く使用されてはいない。しかしながら、継続的な性能の改善の結果、リアルタイム連続データ・サービスを多くの大衆に売り込むのは単に時間の問題であると期待されている。

インターネットを含めて大抵のデータ通信ネットワークは、パケット交換データ網である。パケット交換データ網経由で送信されることになるデータは、データ・パッケージに分割され、それからネットワーク上に送信される。各ネットワーク・ノードでは、パッケージはパケットの宛先により近い位置にある隣のネットワーク・ノードに転送される。最終的には、パケットは宛先に到着し、元々送信されたデータの集まり、たとえばデータ・ファイルを提供するために他の受信データ・パッケージとともに再構築される。このタイプのネットワークは、データグラム・ネットワークとも呼ばれる。

ＯＳＩ(Open System Interconnection)モデルのトランスポート層では、サービスは主にＴＣＰ(Transmission Control Protocol)かＵＤＰ(User Datagram Protocol)のどちらかを用いて提供される。会話型クラスおよびストリーミング型クラスの属するリアルタイム連続データ・サービスは、ほとんどの場合、（より効率的な）ＵＤＰプロトコルを用いて提供される。ＵＤＰは再送または順序制御メカニズムを持たない。遅延して受信されたパケットは、単に消失したものと見なされる。

リアルタイム連続データ・サービスに対しては特に、トランスポート層のプロトコルとして主にＵＤＰが使用され、セッション層およびそのセッション層の上位であるプレゼンテーション層においてＲＴＰ(Real Time Transport Protocol)が組み合わせて使用される。また、ＲＴＳＰ(Real Time Streaming Protocol)は、データ・ストリームをアプリケーション層におけるアプリケーションに提示するために用いられる。しかしながら、リアルタイム連続データ・サービスを提供するために、ＵＤＰの代わりにＴＣＰプロトコルを使用できる場合があるということが知られている。この場合の例として、マルチユーザのオンライン・ゲームの場合をあげてもよい。

ＵＤＰは、順序制御または再送メカニズムを持たないので、これらメカニズムは、ＯＳＩモデルの上位層で提供される場合もある。ＲＴＰおよびＲＴＳＰのタスクの中で、順序制御メカニズムをアプリケーションに依存する形で提供することができる。当然のことながら、そのような順序制御メカニズムはオプションであり、一部のサービスを提供するときには何ら付加的な価値を提供しない場合もある。

トランスポート層は、エンド・ツー・エンドのエラー復旧およびフロー制御に対する責任を負い、データ・パッケージのルーティングに対して責任を負うのはＯＳＩモデルにおいてトランスポート層の下位に位置するネットワーク層である。したがって、ネットワーク層では、データ・パッケージの内容は透過的であり、各パッケージは宛先に関する詳細を提供するヘッダを含む。通常の郵便システムにおいて、輸送物は宛名ラベルを含むが、それらの中身は配達人には透過的であることに類似する。

ＯＳＩモデルでネットワーク層の下位にあるデータリンク層で、データ・パッケージはビットに符号化および復号化される。論理的な観点からデータの実際の伝送を責務とするのは、データリンク層である。ＯＳＩモデルのデータリンク層の下位に、ＯＳＩモデルの最下層であるその物理層があり、ハードウェアの観点（多重化装置、ケーブル等）から通信を処理する責務がある。データの中身そのものは、物理層においてまったく考慮されない。物理層での主な要件は電気信号または光信号をそのネットワーク内で第１の地点から第２の地点および次の地点に届けることであるからである。
3GPP TS 23.107 v3.9.0（2002年9月）の"第３世代パートナーシップ・プロジェクト；技術仕様化グループサービスおよびシステム側面；サービス品質（ＱＯＳ）概念および基本構想（1999年リリース）"

ネットワーク事業者により管理されているネットワークは、主に、ＯＳＩモデルの下位の３層である物理層、データリンク層およびネットワーク層で稼動する。より複雑なタスクに対しては、ＯＳＩモデルの上位の層、たとえばトランスポート層で稼動できる場合もある。

ネットワーク事業者（ＮＯ）およびインターネット・サービス提供事業者（ＩＳＰ）にとって、広帯域接続（たとえばＡＤＳＬ接続またはケーブルモデム接続）を経由して受信されるデータは、インターネットを経由して宛先に送信しなければならない。したがって、単に、何らの意味を持たないが宛先は持っているデータ・パッケージのストリームとして受信される。各パッケージは、パッケージを宛先により近い隣のノードに転送することを可能とするヘッダを有するが、データ・パッケージの内容は物理層、データリンク層、ネットワーク層及びトランスポート層では透過的であるので、ネットワーク事業者またはインターネット・サービス提供事業者はデータ・パッケージに関連する元のデータ・サービスが何だか分からない。

このことは、インターネット・サービス提供事業者およびネットワーク事業者にとって、データ・ストリームのうち、リアルタイム連続データ・サービスの利用と他のデータ・サービス（たとえば通常のウェブ・サーフィン、電子メールあるいは他のデータ・サービス）の利用とを区別できないという不都合をもたらす。したがって、会話型クラスおよびストリーミング型クラスのサービスのうち少なくともいずれか、並びにオンライン・マルチユーザ・ゲームなどのようなリアルタイム連続特性を持つサービスを、他のインターネット・サービスから切り離して、選択的に提供することができなくなる。ＡＤＳＬ加入者線またはケーブルモデム接続を注文しているユーザは、この広帯域接続の性能の結果として、必要なソフトウェアおよび他の設備を用いれば、他のデータ・サービスを利用できるのと同様に、リアルタイム連続データ・サービスを利用することができてしまう。結果として、そのネットワーク事業者がこれらのサービスを別々に一人のユーザに提供することや、そしてこれらのサービスの利用に対してそのユーザに課金することができない。

本発明の目的は、上述した不都合を解決し、広帯域接続を有するパケット交換データ網でユーザに対して、合意されたサービス・レベルの提供を実施する手段を提供することである。

上記および他の目的を達成する本発明では、データ・パッケージを含むパケット交換データ・ストリーム内のリアルタイム連続データを制御する方法が提供され、該方法は、リアルタイム連続データを受信ユーザに提示する際の連続性を阻害するために、リアルタイム連続データ・サービスの利用に関する認可状況に依存してパケット交換データ・ストリームのデータ・パッケージを保持する工程を備えることを特徴とする。

当然のことながら、データ・パッケージを保持することは、データ・パッケージの全体的な遅延の原因となる。リアルタイム連続データ・サービスでは、データがストリーミング方式で提供されることが必要なので、データ・パッケージを保持することに起因する遅延は、リアルタイム連続データ・サービスに関連する連続データを中断することにつながる可能性がある。これは、十分な数のパッケージが保持される場合か、十分な長時間にわたって保持される場合の少なくとも何れかの場合に起こりえる。このような中断は、配送されるリアルタイム連続データ・サービスの品質を低下させるため、ネットワーク事業者またはインターネット・サービス提供事業者は、たとえばそのパケット交換データ網のユーザがリアルタイム連続データ・サービスを利用する資格がない場合に、合意されたサービス配信レベルを実施できるようになる。

一方では、上記の方法はリアルタイム連続データ・サービスのＱｏＳを、実用上の利用が殆んどできない程度にまで劣化させる能力を提供する。しかし他方では、通常のウェブ・サーフィン、電子メールまたはファイルのダウンロード配信のような非リアルタイム・データ・サービスにおけるＱｏＳの劣化は、ユーザにはほとんど気づかれない。特に、ＱｏＳの劣化に最も影響を受けやすい会話型クラスおよびストリーミング型クラスのサービス、およびオンライン・マルチユーザ・ゲームのようなサービスは、再構築される受信信号の品質が非常に劣っているので、そのサービスの利用ができなくなる程度に影響を受ける可能性がある。

たとえば、リアルタイム連続データ・サービスにおいて、時々または定期的に１０〜１００ミリ秒その連続性を中断するような品質劣化をもたらした場合、ＶｏＩＰサービスで会話しようとしている人は強い苛立ちを感じるだろう。他方では、バックグラウンド型クラスのサービスであるファイルのダウンロード中や、あるいはリアルタイム特性のない双方型クラスのサービスであるウェブサイトにアクセス中のほんの１秒足らずの遅延が発生したとしても、ユーザにはほとんど気づかれない程度であり、結果としてユーザは苛立ちを感じない。したがって、上述した方法により、データ・ストリーム内のデータの内容がネットワーク事業者には分からないかあるいは無関係であるような環境において、合意されたサービス・レベルを実施するための、リアルタイムと非リアルタイム・サービスとの区別をする効率的な方法が提供される。

本発明の一実施形態では、データ・パッケージが一時的に保持され、その後データ・ストリームに戻される。

当然のことながら、保持した後にデータ・パッケージを戻すことにより、それらは最終的に受信ユーザにより受信されるであろう。このことは特に、ＴＣＰを用いるか、ＯＳＩモデルの上位層で再送または順序制御メカニズムが提供される場合のＵＤＰを用いて送信される非リアルタイム連続データにとって有益であろう。ＴＣＰはスライディング・ウィンドウ方式に基づく再送シーケンスを含む。パケットが受信されると予想されてから一定期間内に受信されない場合、そのパケットの再送が要求される。ウィンドウはパケットの到着予想時刻と同調してスライドする。パケットが遅延したとしても、到着予想時刻後でスライディング・ウィンドウの時間内に受信される場合には、再送は要求されない。この場合、パケットが遅延した場合でも、受信側により再送が要求される十分に前に受信される場合、パケットの再送は、要求されない。

他方では、リアルタイム連続データ・サービスに対して、大抵の場合再送は無関係である。第一に、会話型およびストリーミング型クラスのサービスは大抵、再送を含まないＵＤＰに基づいて提供される。欠損パケットは、単に消失したものと見なされる。再送はオプションとして行われることもあるが、必須ではない。第二に、リアルタイム連続データ・サービスに対して、大抵の場合、再送は選択の余地がない。データ・パッケージまたはデータ・フレームが消失し、そのデータ・パッケージが再送されるようになる場合、受信ユーザに提示するにはあまりにも遅れて受信されることになるからである。したがって、リアルタイム連続データ・サービスでは、パッケージ消失の場合にパッケージの再送はほとんど実行されず、トランスポート層以上の上位層においてさえも実行されない。

データ・パッケージが保持された後データ・ストリームに戻されない場合、リアルタイム連続データ・サービスでは、そのデータ・パッケージは単に消失したものとなり（ＵＤＰ）、一方非リアルタイムデータ・サービスでは、データ転送速度を落としながらパッケージの再送が要求される（ＴＣＰ）。データ・パッケージが保持され一定の期間だけ保持されてからデータ・ストリームに戻される場合、ＵＤＰを用いるリアルタイム連続データ・サービスでは、なおも消失と見なされ、それによってデータ・ストリームに戻されなかった場合と同程度の劣化をなおも引き起こす。他方、ＴＣＰを用いる非リアルタイムデータでは、スライディング・ウィンドウ内にちょうど間に合ってパッケージを受信できれば、再送が不要となるであろう。当然のことながら、このことは、パケット交換データ網を通して転送される非リアルタイム・データに対して性能上の利点をもたらす。たとえリアルタイム・サービスがＴＣＰ上で提供されたとしても、再送はＱｏＳを改善することはないどころか、劣化させさえする可能性があることが知られている。そのパケットが遅延を生じることなく、データ・ストリームに最早呼び出されることがもはやできないからである。

本発明の別の実施形態では、データ・パッケージを保持する工程は、データ・ストリーム内の複数の後続データ・パッケージを保持する工程を含む。当然のことながら、後続データ・パッケージ群を保持することにより、たとえバッファを使用して受信ユーザに提示する前に全てのデータ・パッケージを収集できたとしても、結果的にリアルタイム連続データの連続性は中断されることになるだろう。

バッファが使用されない場合、データの連続性が中断されることは明らかである。データ・パッケージは単に相当に遅延して受信されるからである。しかしながら、バッファや何らかの他の訂正部が使用され、十分な量の後続のデータ・パッケージが保持される場合であっても、リアルタイム連続データ・サービスでは、発生した劣化のため、連続的なストリーミング方式に間に合うように受信ユーザにデータを提示することができないだろう。したがって、バッファや何らかの他の訂正部を用いても、この実施形態における方法によれば、データの連続性が中断されるだろう。

本発明の別の実施形態では、データ・パッケージを保持する工程は、データ・ストリームから無作為に選ばれた一つ以上のデータ・パッケージを保持する工程を含む。

データ・ストリームから無作為に選ばれた一つ以上のデータ・パッケージを保持することにより、データ・ストリームには若干の中断がもたらされる。受信側で訂正部が使用されない場合、この中断により、連続データの受信中に雑音または不愉快な断絶を感じるだろう。バッファのような何らかの訂正部が受信側で使用される場合、要求されたパッケージが受信されるまでの間、あるいは訂正部がパッケージを消失したもとと見なしてその受信パッケージ抜きのデータを提示するまでの間、一定期間、リアルタイム連続データ・サービスに関連する受信データは遅延する。どちらの場合も、十分な量のデータ・パッケージが十分長い時間保持される場合には、サービスは不愉快なほどに劣化する結果となるだろう。

リアルタイム連続データ・サービスに対してサービスの劣化をもたらす別の方法を実現する本発明の一実施形態では、リアルタイム連続データは一連のデータ・パッケージを含み、データ・ストリームのデータ・パッケージは、一連のデータ・パッケージを並び替えるために保持される。

ここで、本発明では、データ・パッケージがリアルタイム連続データ・サービスに関連したものであるか、非リアルタイム連続データ・サービスに関連したものであるかに係わらず、データ・ストリーム内の全てのデータ・パッケージは保持されることが思い起こされる。その保持されたデータ・パッケージがデータ列のデータ・パッケージを含む場合には、データ・ストリームの一つ以上のデータ・パッケージを保持することにより、そのデータ列の中のデータ・パッケージでの当初の順序が乱される。この乱れが受信側で訂正されない場合にはやはり、データの雑音や断絶として感じられるだろう。しかしながら、受信側で訂正されたとしても、データの提示に遅延が発生して、データの連続性は中断される結果になるだろう。つまり、連続的なストリーミング方式で受信ユーザにデータを提示することができない。非リアルタイムデータ・サービスに対しては、受信時にパッケージが受信される順序を修正することができ、本発明の実施形態による方法が非リアルタイムデータ・サービスにとって苛立ちを感じさせることもなく、サービスの顕著な劣化を引き起こすこともないだろう。

上述の実施形態の変形では、データ・パッケージが保持され、保持されたデータ・パッケージあるいはデータ・パッケージ群は、それぞれ異なる保持時間を経過後に、データ・ストリームに戻される。

これにより、データ・ストリーム内のデータの全てを並べ替える効果的な方法が提供されるであろう。保持時間の長さは、例えば別の実施形態にしたがって、無作為に決めることができる。

本発明の別の実施形態では、パケット交換データ・ストリームはデータ送信機からの送信データ・ストリームであり、一方、本発明のさらに別の実施形態では、パケット交換データ・ストリームはデータ受信機への受信データ・ストリームである。どちらもオプションであり、両方を同時に適用することもできる。

当然のことながらどちらの実施形態も、本発明の方法を使用することに対して利点をもたらすものである。合意されたサービス・レベルの実現はパケット交換データ網のユーザからの送信トラヒックだけでなく、ユーザへの受信トラヒックについても行われうるからである。

本発明の別の実施形態では、受信ユーザによりデータ・パッケージが受信された後に、受信データ・パッケージを再構築する工程を備える。今までにある程度説明していることであるが、受信側での訂正部によっては、本発明の方法により与えられるサービスの劣化を克服できない。大抵の場合、サービスの劣化はさらに増大するであろう。たとえば、受信時間の遅延を許さないデータやリアルタイム連続データを訂正するためにバッファが使用された場合、受信側で何ら訂正が行われない場合と比べて、提示する際にデータの連続性の中断をいっそう拡大する結果になる可能性があることが知られている。これは、欠損データを受信するまでの間、あるいは欠損データが受信されない場合はその損失データが受信されるのを待ち続けた後に遅延したデータを提示するまでの間、バッファはすべてのデータを保持し続けるという事実による。

上述の実施形態の変形では、再構築する工程は受信データ・パッケージをバッファリングする工程を備える。これについては既に説明した。

上記実施形態のさらに別の変形では、再構築する工程は、さらに、受信データ・パッケージを、そのデータ・パッケージが元々送信された順序に再配置する工程を備える。

本発明の方法は、ＯＳＩ（Open System Interconnection）モデルのどの所望の層でも実行できるが、本発明の実施形態では、本発明の方法がデータリンク層、ネットワーク層またはトランスポート層を含むグループの中のパケット交換データ網において実行されることが好ましい。当然のことながら、これらの層では、データ・ストリーム内のデータはネットワーク・トポロジーには透過的であり、データ・パッケージの形式としての構造のみが認識される。

本発明をデータリンク層で適用することにより、ネットワークの下位層で実施されるため、パッケージの解析あるいは解釈をまったく行わずに適用できるという利点が得られる。この場合、本発明の方法は比較的容易に実装することができ、非常に高速に実行することができる。

本発明をネットワーク層で適用することにより、経路情報が利用できるという利点が得られる。したがって、パッケージをそれらの宛先や送信元に基づいて選択的に保持すること可能となる。

本発明をトランスポート層で適用することにより、一定のプロトコル（ＵＤＰまたはＴＣＰ）を用いて送信されるパッケージを選択的に保持することができる利点や、特定のＴＣＰ／ＵＤＰポート番号を有するパッケージを選択的に保持することができる利点が得られる。特定のポート番号を有するパッケージを保持することにより、ポート番号に関連する特定のサービスだけを対象とすることができる。

本発明の別の実施形態では、電話やストリーミング・マルチユーザ・ゲームなどのリアルタイム連続データ・サービスを提供するためにリアルタイム連続データが用いられる。

本発明の別の実施形態では、既に説明したようなリアルタイム連続データ・サービスを利用するための認可状況に依存してデータを保持する工程が実行される。これにより、たとえば、合意されたレベルやユーザに適用できる他の基準に依存するように本発明の方法を実行できるであろう。それだけでなく、この方法は、全てのユーザに対してリアルタイム連続データ・サービスの利用を全面的に故意に阻止するために使用することができるということが知られている。

上述の実施形態の変形では、リアルタイム連続データ・サービスのユーザにより提供される識別情報を評価することにより認可状況が規定される。

当然のことながら、識別シーケンス、すなわちリアルタイム連続データ・サービスへのアクセス認可と同様な処理を実行し、識別シーケンスの結果から認可状況を決めることができるであろう。ユーザは、たとえば自身がリアルタイム連続データ・サービスを利用する資格があるユーザであることを識別させるために、ユーザ名およびパスワードの入力を要求される場合がある。

識別情報の評価結果に基づいて、リアルタイム連続データ・サービスのサービス配信を、一時的にユーザに認可することができる。

本発明の別の実施形態では、サービス・レベルはデータ・ストリーム全体に対して登録され、登録されたサービス・レベルにより認可状況が決められる。当然のことながら、たとえば、リアルタイム連続データ・サービスを利用する資格がないと判明しているユーザから来る全てのデータについて本発明の方法を実行できる。ほかの例では、データ・パッケージを保持する工程は、ユーザにより使用される広帯域接続またはＡＤＳＬ接続で転送される全てのデータについて実行できる。

別の実施形態では、パケット交換データ・ストリームは、電気通信網の加入者線を用いて転送される。加入者線を用いて、認可状況は加入条件により決定して、決定したように登録することができるし、登録してもよい。加入者線のソリューションは、ＡＤＳＬ（Asymmetric Digital Subscriber Line）、ＳＤＳＬ（Symmetric Digital Subscriber Line）、ＲＡＤＳＬ（Rate Adaptive Digital Subscriber Line）、ＨＤＳＬ（High Bit-rate Digital Subscriber Line）、或いは、ＶＤＳＬ（Very High Bit-rate Digital Subscriber Line）を含むＤＳＬ(Digital Subscriber Line：デジタル加入者線)、ケーブルモデム・ソリューション、衛星インターネット、フレーム・リレー、ギガビット・イーサネット（登録商標）、任意の無線広帯域加入者ソリューション、たとえばＬＭＤＳ（Local Multipoint Distribution Service）、ＭＭＤＳ（Multichannel Multipoint Distribution Service）、ＷｉＭＡＸ（Worldwide Interoperability for Microwave Access）、ＨＩＰＥＲＭＡＮ（High Performance Radio Metropolitan Area Network）、あるいは別の広帯域加入者線ソリューションのうち、少なくともいずれかを含めることができる。

本発明の別の実施形態では、リアルタイム連続データ・サービスは、ＶｏＩＰのような電話、ストリーミング・マルチユーザ・ゲーム、ストリーミング映像およびストリーミング音声を含むグループの中の少なくとも一つを含む。しかし、本発明による方法の使用は、これらのサービスに限定されるものでないということが知られている。

本発明の第２の態様では、パケット交換データ・ストリーム内のリアルタイム連続データを制御するためのシステムが提供され、パケット交換データ・ストリームはデータ・パッケージを含み、システムはデータ・ストリームを捕捉し転送する手段と、リアルタイム連続データを受信ユーザに提示する際の該データの連続性を阻害するために、リアルタイム連続データ・サービスの利用に関する認可状況に依存してパケット交換データ・ストリームのデータ・パッケージを保持する手段とを備えることを特徴とする。

本発明のこの第２の態様の実施形態が、請求項２３から請求項３２に規定されている。

本発明の好適な実施形態では、システムがユーザの認可状況を判断するための手段を備えるということに留意されたい。認可状況を判断するの手段は、この実施形態とは別の実施形態により、外部情報源からその認可状況を受け取る手段を備えてもよい。認可状況を判断する手段は、ユーザにより提供された識別情報を受信し評価する手段を備えることもできる。

本発明の第３の態様では、本発明は、パケット交換データ網において、既に説明しているように、リアルタイム連続データ・サービスを提供するためにネットワークでリアルタイム連続データ・トラヒックを制御するシステムを使用することに関する。この態様の実施形態にしたがって、そのシステムが、受信者への、送信機からの、あるいは送受信機相互間のリアルタイム連続データ・トラヒックについて、それぞれ受信、送信あるいは両方を制御するために使用できる。

上記で規定された使用で提供されるサービスは、電話、ストリーミング・マルチユーザ・ゲーム、ストリーミング映像またはストリーミング音声あるいは任意の他のリアルタイム連続データ・サービスを含むことができる。

本発明の第４の実施形態では、本発明は、電話、ストリーミング・マルチユーザ・ゲーム、ストリーミング映像またはストリーミング音声のようなリアルタイム連続データ・サービスに関し、サービスが上記に規定された方法を用いて提供され、リアルタイム連続データ・サービスは上記で規定したリアルタイム連続データを用いて提供される。

ここで、好適な実施形態を参照する明細書と図面とを用いて、本発明はさらに明らかにされるであろう。しかし、本発明は開示されている実施形態に限定されるものではなく、実施形態は単に説明の目的のために提供されているだけにすぎない。本発明の保護範囲は、特許請求の範囲で明確に規定されている。

図１では、さまざまなデータ・ソースまたは送信部、たとえば、ユーザＩのインターネット電話６およびパーソナル・コンピュータ５、ユーザＩＩのパーソナル・コンピュータ７、ならびにユーザＩＩＩのパーソナル・コンピュータ８を使用してパケット交換網１に複数のユーザが接続している。パケット交換データ網は、雲形１および複数の相互接続されたネットワーク・ノード２により概略的に図示されている。ユーザＩ、ＩＩおよびＩＩＩはそれぞれ、パケット交換データ網１に含まれるノード２の一つに接続している。パケット交換データ網１は、たとえば、インターネットを含んでもよい。さまざまなデータ・サービスが、パケット交換データ網１経由でユーザＩ、ＩＩおよびＩＩＩのユーザ端末５、６、７および８にアクセス可能である。これらのデータ・サービスは、電子メール、ウェブ・サーフィン、ファイル転送およびＶｏＩＰ、テレビ会議、双方向マルチユーザ・ゲーム、デジタルテレビ、インターネット・ラジオ、ストリーミング映像およびストリーム音声リアルタイムのような連続データ・サービスを含んでもよい。

デジタルテレビ番組もまたパケット交換データ網１に接続されているサーバ２０を用いて放送されることがある。デジタルテレビ放送は、潜在的にはユーザのいずれによっても、たとえばパーソナル・コンピュータ５、７および８を経由して受信される可能性がある。別の可能性として、ユーザＩが自身のデジタル・インターネット電話６を用いて、ユーザＩＩＩのパーソナル・コンピュータ８を経由して、ユーザＩＩＩとの通話を設定したいという場合がある。

図１で概略的に図式されているパケット交換データ網では、ユーザＩ、ＩＩおよびＩＩＩはそれぞれ、（とりわけ）本発明によるシステムを通してネットワークに接続されている。以下、本発明によるシステムをリアルタイム連続データ・サービス・ディスエイブラという。たとえば、ユーザＩは、ネットワーク・ノード２に接続されているサービス・ディスエイブラ１０に接続されている。同様に、ユーザＩＩおよびＩＩＩは、それぞれサービス・ディスエイブラ１２および１４を通じてネットワーク・ノード２に接続されている。リアルタイム連続データ・サービス・ディスエイブラ１０、１２および１４はそれぞれ、矢印１８で概略的に図式されているように、ネットワーク事業者またはインターネット・サービス提供事業者が自由に管理する中央制御サーバ１７を経由して制御され得る。

ユーザＩは、ＤＳＬ（Digital Subscriber Line Connection）のような広帯域接続を通してパケット交換データ網に接続していて、インターネット・サービス提供事業者により最高のサービス・レベルに相当する加入資格を有するとする。したがって、ユーザＩは、ウェブ・サーフィン、電子メールなどの通常のデータ・サービスを利用する資格があるだけでなく、ＶｏＩＰやテレビ会議のようなリアルタイム連続データ・サービスを利用する資格もある。さらに、ユーザＩＩＩは、ＤＳＬ加入者線を介してパケット交換データ網にしていて、ユーザＩと同じ加入資格であるとする。同時に、ユーザＩＩは、電子メールおよびウェブ・サーフィンに関心があるだけなので、広帯域接続を通じてパケット交換データ網に接続しているが、利用できる最低のサービス・レベルに相当する加入資格を有する。

上記で説明した各加入資格をもとに、ネットワーク事業者やインターネット・サービス提供事業者は、制御サーバ１７を介して、リアルタイム連続データ・サービス・ディスエイブラのプログラムを組むことができる。例えば、サービス・ディスエイブラ１０および１４のスイッチを切ることにより、ネットワーク事業者は、ユーザＩおよびＩＩＩが全てのサービスを利用できるようにすることができる。同時に、ネットワーク事業者は、制御サーバ１７を介して、リアルタイム連続データ・サービスを一切許可しないようにサービス・ディスエイブラ１２のプログラムを組むことができる。

ユーザＩが、自身のインターネット電話を用いて、ユーザＩＩＩとのＶｏＩＰ通話を設定したい場合、ユーザＩの音声はインターネット電話６を起点とする一連のデータ・パッケージに置換され、データ・ストリームとしてサービス・ディスエイブラ１０に向かう。サービス・ディスエイブラ１０はスイッチが切られているので、そのデータ・ストリームは何も処理されることなしに、ネットワーク・ノード２に転送され、そこからユーザＩＩＩのパーソナル・コンピュータ８に転送される。パーソナル・コンピュータ８への途中でユーザＩＩＩに向かうことになっている一連のデータ・パッケージはサービス・ディスエイブラ１４を経由するが、これもスイッチが切られているので、サービス・ディスエイブラ１４は何も行わない。ユーザＩＩＩにはユーザＩの着信呼が通知され、着信呼に応答するであろう。その後、会話が行われる。

ユーザＩＩに対しては、リアルタイム連続データ・サービスを利用できないほど送受信データ・トラヒックに関するサービスが劣化するようにサービス・ディスエイブラ１２は設定される。ユーザＩＩがユーザＩまたはユーザＩＩＩとＶｏＩＰ通話を設定したい場合、ユーザＩＩの音声に対応する一連のデータ・パッケージがサービス・ディスエイブラ１２に転送される。しかし、サービス・ディスエイブラ１２は、受信側（たとえば、ユーザＩやユーザＩＩＩ）で連続データ信号の中断が定期的に発生するように十分多い数のパッケージを十分長い時間にわたって保持するため、通常の訂正部では中断せずに訂正することができない。逆もまた同様で、サービス・ディスエイブラ１２によって、ユーザＩＩが受信するリアルタイム連続データ・サービスも同様に影響を受ける。同時に、受け入れがたいほどにサービスが劣化することなしに、ユーザＩＩがサーバ２０から放送されるテレビ番組を受信することはできない。

ユーザＩがユーザＩＩを訪問し、さらにユーザＩＩの顧客端末（パーソナル・コンピュータ７）を用いて、ユーザＩとユーザＩＩとがユーザＩＩＩに対してインターネット電話通話を設定したいと想定する。既に説明しているように、サービス・ディスエイブラ１２は、ネットワーク事業者またはインターネット・サービス提供事業者により、パーソナル・コンピュータ７がパケット交換データ網との広帯域接続を用いてリアルタイム連続データ・サービスを受けられないように設定されている。しかし、制御サーバ１７はパケット交換データ網に接続されていることが知られている。そのため、以下で説明するように、サービス・ディスエイブラ１２を通じて一時的にリアルタイム連続データ・サービスをパーソナル・コンピュータ７に提供することも可能である。

パーソナル・コンピュータ７を用いてインターネット電話通話を設定するために、ユーザＩは、たとえばウェブサイトにアクセスすることにより制御サーバ１７に接続すると、認証手続きを求められる。たとえば、ユーザＩは自身のユーザ名およびパスワードを入力する場合がある。評価処理で、制御サーバ１７は、このユーザ名および対応するパスワードが存在するかどうかを調べ、この調査の結果によって、データベース１９に接続する。データベース１９は、上述したインターネット・サービス提供事業者を介してパケット交換データ網に接続されている全てのユーザに対する全ての接続の詳細を備える。ネットワーク制御サーバは、ユーザＩが加入条件に基づいてインターネット電話を利用する資格を有することを確認する。それに応じて、制御サーバ１７はここで一時的にサービス・ディスエイブラ１２のスイッチを切る。それにより今度は、ユーザＩとＩＩとが、パーソナル・コンピュータ７を使用して、ユーザＩＩＩとのインターネット電話通話を行うことができる。そのインターネット電話通話が終わるとすぐに、そのインターネット・サービス提供事業者は、ユーザＩＩが資格を有する元のサービス・レベルに再設定してもよい。

ユーザＩＩＩは最早ＶｏＩＰを受信することに関心をなくしたので、今度は自身の広帯域の加入資格を変更するものとする。ユーザＩＩＩは、ストリーミング映像で毎週配信されるお気に入りのインターネットＴＶ番組を見逃したくないので、ストリーミング映像は可能であるが、テレビ会議またはＶｏＩＰのような会話型クラスの連続データ・サービスはできないという今までよりも低いサービス・レベルに切り替える。ネットワーク・事業者（ＮＯ）またはネットワーク・サービス提供事業者（ＩＳＰ）は、サービス・ディスエイブラ１４のスイッチを入れ、送信データ・ストリーム内の無作為に選択されたデータ・パケット列が、無作為に選ばれた時間だけ遅延するように設定するだろう。

今度はユーザＩがユーザＩＩＩとのテレビ会議通話を設定したい場合を想定する。しかし今度は再び自身のパーソナル・コンピュータ５、マイクロフォン（図中になし）およびウェブ・カメラ（図中になし）を使用して、ユーザＩの音声および映像は、サービス・ディスエイブラ１０に転送される一連のデータ・パッケージに変換されるであろう。サービス・ディスエイブラ１０はスイッチが切られているため、一連のデータ・パッケージはネットワーク・ノード２に転送され、そこからユーザＩＩＩの広帯域接続上のサービス・ディスエイブラ１４に転送される。サービス・ディスエイブラ１４は受信トラヒックを無視するため、ユーザＩのデータ信号は何も処理がされずに、ユーザＩＩＩのパーソナル・コンピュータ８に送信される。

ユーザＩからの発言への応答において、ユーザＩＩＩの音声および映像を載せているデータ・ストリームがパーソナル・コンピュータ８から送信され、サービス・ディスエイブラ１４により捕捉される。サービス・ディスエイブラ１４は、時々であるが定期的に、パーソナル・コンピュータ８から到達するデータ・ストリームのデータ・パッケージを保持する。パーソナル・コンピュータ６でデータを受信するユーザＩは、定期的にデータ・パッケージを受信し損なう。テレビ会議では高度な基準のＱｏＳが要求されるので、サービス・ディスエイブラ１４によりもたらされるサービス劣化により、パーソナル・コンピュータ６でユーザＩが受信するデータの連続性は中断される。引き起こされたサービス劣化により、バッファのような訂正部を用いたとしても、データの連続性は定期的に中断するため、ユーザＩとユーザＩＩＩとの間での会話は実用上不可能である。ユーザＩＩＩはテレビ会議を使用できないし、同じ理由でＶｏＩＰも利用することはできない。

さらに、しばらくしてから、ストリーミング映像を放送するために、ユーザＩＩＩは自身の加入資格を再度変更するものとする。ＩＳＰは、時々であるが定期的に送信データ・ストリーム全体から一つ以上のパッケージを保持するようにサービス・ディスエイブラ１４を設定することができる。この設定は、会話型クラスのサービスがその使用ができなくなるほどに影響を受ける程度までＱｏＳを劣化させるが、ストリーミング型クラスのサービスを利用するにはＱｏＳはなおも十分である。

今度は、ユーザＩＩＩが自身のコンピュータ８を使用してユーザＩを呼び出そうとする場合、送信データ・トラヒックはサービス・ディスエイブラ１４により途中で捕捉される。サービス・ディスエイブラ１４はスイッチが入っており、ネットワーク事業者により、たとえば、時々であるが定期的に送信データ・ストリーム全体から一つ以上のパッケージがサービス・ディスエイブラ１４により保持されるように設定されている。パッケージが保持されるため、ユーザＩＩＩから送信される一連のデータ・パッケージ内のデータ・パケットは避けがたい影響を受けるであろう。一定時間保持されてから、パッケージはネットワーク・ノード２に転送され、そこからユーザＩのインターネット電話６に転送される。インターネット電話６は、受信データ・パッケージをバッファリングする機能を備えることもできる。一定の期間にわたってバッファされてから、データ・パッケージは元のシーケンス順に再構築されユーザＩに提示されるが、そのデータをユーザＩＩＩからの音声として認識するには非常に乱れたものや絶えず断絶したものになってしまう。きちんとした会話は不可能であり、会話は直ぐに終わってしまうだろう。データ・パッケージを訂正し再構築できるようにするためには、ＶｏＩＰによる通話中に、ユーザＩに気づかれないかあるいは苛立ちを感じさせない程度の短い遅延ですむように、保持されるパッケージの数を十分に少なくするか保持される時間を短くしなければならないことが知られている。サービス・ディスエイブラ１４を正しく設定すれば、十分な数の送信パケットを十分長く遅延させることができ、音声信号を効果的にスクランブリングすることができるだろう。

ストリーミング映像は同様の影響を受けるものの、正しいデータの並び順を再設定する回復手順と一緒にバッファを使用することにより、全体的な短い遅延であれば回復することができる。

当然のことながら、ユーザがＡＤＳＬ接続を有する場合には、本発明は、ユーザから到来する全てのデータを受け入れる最初のネットワーク・ノードで適用してもよい。図１でこのノードは、ノード２内または近辺にある。サービス・ディスエイブラ１０、１２および１４は、図１ではネットワーク内の別々の要素であるように示されているが、たとえばＤＳＬ接続の場合、ネットワーク・ノード２と統合することができる。

図１に関連して説明された実施形態は、ＤＳＬ（Digital Subscriber Line）ソリューションに関連して説明されてきており、各ユーザは、個別にネットワーク・ノード２に接続している。本発明がケーブルモデム・ソリューションのような数多くのユーザが一つの加入回線内のネットワーク・ノードへの単一の接続を共有している場合に適用されると、厄介な問題が生じる。このことは、図４Ａおよび４Ｂに描かれており、以下に説明する。

本発明をケーブルモデム・ソリューションと組み合わせて適用する場合には、当然のことながら、図４Ａの各々のユーザ５２、５３、５４は、他のユーザとの共有接続５０を経由してネットワーク・ノード６５に接続することになる。たとえば、お互いの近隣、たとえば同じ通り内に住んでいる多くのユーザ５２、５３、５４は、それぞれケーブルモデム５６、５７および５８を使用して単一の接続５０を経由してネットワーク・ノード６５に接続される場合がある。ネットワーク・ノード６５は、接続６８を経由して他のノード（図中になし）に接続しているＷＡＮ（Wide Area Network）の一部である。それぞれのユーザ５２、５３および５４は、それぞれ固有の接続６０、６１および６２を経由して共有接続５０に接続されている。

図１に示されている実施形態に関連して既に説明したように、共有ネットワーク接続５０上のデータ・ストリーム内に含まれているデータ・パッケージを単純に保持してしまうと、ネットワーク接続５０に接続するすべてのユーザに影響を与えることになり、ユーザに依存して施策の実施することや、サービス提供を行うことには適さないであろう。この問題に対して、ケーブルモデム・ソリューションでは、数多くの解決策がある。データリンク層では、ＭＡＣ（Media Access Control）アドレスにより各ケーブルモデム（５６、５７、５８）を識別できる。したがって、データ・パッケージを送信または受信ＭＡＣアドレスにより識別する工程を含めることができる。一旦どのＭＡＣアドレスにデータ・パッケージが属するかを識別されると、その宛先や送信ユーザが分かるので、対象のユーザのＭＡＣアドレスが付いたデータ・パッケージを、他のユーザのデータ・パッケージに影響を及ぼすことなく保持することができる。図４Ａでは、データリンク層において、サービス・ディスエイブラ６９により、各パッケージに対するＭＡＣアドレス検出の工程が実行される。ひとたび保持されるべきデータ・パッケージが特定されると、サービス・ディスエイブラ６９は、図１のサービス・ディスエイブラ１０、１２および１４に関連して既に説明されているような適切な保持方法を実行することになるだろう。

図４Ｂは２番目のソリューションを示している。この実施態様で、図４Ａで示した要素と変更されていないか、同じ機能を有するかの少なくともいずれかの要素は、同じ参照番号をつけている。図４Ａと図４Ｂとの違いは、各ユーザ５２、５３および５４に特化したケーブルモデム７２、７３および７４を使用していることである。特化したケーブルモデム７２、７３および７４は、ネットワーク事業者またはインターネット・サービス提供事業者により、たとえば制御装置７０を使用して遠隔でプログラム制御される。特化したケーブルモデム７２、７３および７４によりサービスを無効にする工程あるいはデータ・パッケージを保持する工程は、たとえば、関連するユーザに向けた、あるいはユーザから発する、受信または送信データ・パッケージを保持する工程を含む。ケーブルモデムをプログラム制御することで、図４Ａのサービス・ディスエイブラ６９のようなサービス・ディスエイブラを設置する必要がなくなる。

図２は、インターネットのようなパケット交換網を通して配信される一連のデータ・パッケージに対するパケット配信パターンを示している。一連のデータ・パッケージは、パケット送信元２１から発生し、インターネット２２上で送信され、受信相手による受信時に、バッファまたは訂正部２３がその受信されたパッケージを再構築し、そしてそれらを元の順に並び替える。その後、そのデータは、パケット受信部２４により示されるユーザに提示される。図２では、パケットのトラヒック・パターンが、その位置Ａ、ＢおよびＣの各々において解析されており、それぞれ、パケット送信元２１によりインターネット２２に供給されるデータ・パッケージの列（状況Ａ）、その列がインターネット２２を移動してきた後バッファ２３により受信されたときの列（状況Ｂ）、およびパケット受信部２４で概略的に図式されているユーザに対して訂正部またはバッファにより提示される列（状況Ｃ）に対応している。

パケット送信元は、Ａで示しているように、一定時間間隔でＰ１、Ｐ２、Ｐ３、Ｐ４、．．．のような順序で一連のパッケージを送信する。インターネットのようなパケット交換データ網の本質を考えると、同じ列に含まれていたとしても、異なるパッケージは、異なるネットワーク・ノードを経由してある場所から別の場所に移動していき、パッケージ順序が一時的にある程度入れ替わる可能性がある。一般に、第１と第２の場所間のインターネット・チャネルは統計的に特徴付けることができる。インターネット・チャネルを経由するパケットの最小および最大の到達時間に関して言及することは、おおよそ可能である。図２のパケットＰ１のように、早ければ、パケットは直接または送信された直後に受信される。その最小の到達時間が軸３４上で両方向矢印２７により示されている。統計的には、一部のパッケージは、状況Ｂにおける軸３５の真上の両方向矢印２９で示すパッケージＰ２のように、最大の到達時間を有する場合がある。両方向矢印３１により示されているように、一定時間、パケットをバッファリングすることにより、受信者は一連のデータ・パッケージを訂正し、一定間隔の出力を得ることが可能である。その後、状況Ｃで示されているように、ほんのわずかな遅延を伴うものの、そのパケットは通常のストリーム方式でユーザに提示される。バッファリングの継続期間が十分短ければ、パケット受信部２４の受信者は、その遅延に殆んど気づかず、その結果、提示されるデータを、たとえば音声として感じることができる。図３では、図２とほとんど同じネットワーク実装が図示されているが、パケット送信元２１とインターネット２２間の接続の間にリアルタイム連続データ・サービス・ディスエイブラ４０が使われている。図３において、図２と同様の機能を有するものは同じ参照番号で示していることがわかる。軸４２上に、送信元２１により供給されるようにデータ・パッケージ２５のような一連のデータ・パッケージが図示されている。サービス・ディスエイブラ４０は、各送信パッケージを保持し、パケットをデータ・ストリームに戻す場合にはパケットごとに異なる時間を保持してもよい。結果的に、たとえば、番号Ｐ４のパッケージがパッケージＰ１よりもかなり短く保持されるため、その列の元の順序はサービス・ディスエイブラ４０によって完全に乱される。これが、インターネット２２により既に引き起こされている乱れに付け加わり、軸４３上の場所Ｂに対して示されているようなパッケージの受信パターンを生成する。バッファ２３がその受信パッケージを適切な方法で並べようとすると、両方向矢印４５で示されているように、非常に長い遅延を取り入れなければならない。そのような長い遅延が生じると、受信ユーザはデータの連続性が中断されたと感じ、そしてこれらの中断は定期的に起こりうるので、ユーザは苛立ちを感じる。したがって、実用上の観点から、そのユーザがそのリアルタイム連続データ・サービスを利用することは難しいであろう。したがって、リアルタイム連続データ・サービスへのアクセスを効率的に拒否することができる。特に、各々のデータ・パケットに対してサービス・ディスエイブラ４０が引き起こした遅延は、受信パケットをすべて無作為に入れ替えた結果でありえることが知られている。データ・ストリーム内でのパケットの元の順序を損なうように、その各パッケージを、たとえば、−３、−２．−１、０、１、２または３だけ位置を移動することができる。

一連のデータ・パッケージは音声を表わすので、パケットはバッファされ、元の順序に再構築されなければならない。これにより、両方向矢印４５により示すような遅延を引き起こす。軸４２上の状況Ａに対して示されているデータ・パッケージがウェブ・ページを構成する場合には、どのパッケージが最初に配信されるか、そしてどれが最後に配信されるかは、実際には関係ないであろう。ウェブ・ページの異なる部分が、そのウェブ・ページの他の部分とは関係なく、既にローディングを始めている場合もあり、データ・パッケージの再配置により、苛立ちはまったくまたはほとんど感じられない。

同じような効果は、ファイルのダウンロードの例についても当てはまる。連続したストリーミング方式で提示されなくてもよいので、ファイルを受信している最中にデータ・パッケージの再構築による少しの遅延が発生したとしても、ファイルをダウンロードしているユーザにとっては苛立ちを感じられないだろう。遅延して受信したパッケージは、受信済みのパッケージの間に、支障なく挿入されるだろう。ひとたびファイルをダウンロードすれば手元に残るが、音声の場合には、連続性が中断されると、会話の解釈は非常に困難にあるいは不可能にさえなる。

本発明の方法がスライディング・ウィンドウを有するＴＣＰプロトコルに基づくトラヒックに対して行われる場合、発生した遅延の量に等しいだけスループットが低下することが知られている。リアルタイムプロトコル（会話、ビデオ）は、いっそう、スライディング・ウィンドウを有しないＵＤＰ（ユーザ・データグラム・プロトコル）に基づくようになることが予想される。ＵＤＰに基づくサービスでは、送信の中断はパッケージが受信されなくなる直後に生じるため、本発明の方法は特に有効であるだろう。ＵＤＰは、ＴＣＰと比較して遥かにＱｏＳに依存することが知られている。

ここで、理解のために言及すると、上記の教示を考慮することで、本発明の数多くの変更および派生を実施できるようになる。したがって、当然のことながら、添付の特許請求の範囲内で、本発明は、本明細書で具体的に説明されているものと別の方法で実施することができる。

本発明においてリアルタイム連続データ・サービス・ディスエイブラが使用されているパケット交換データ網の一例の説明図である。 パケット交換網を通して送信される一連のデータ・パケットに対するトラヒック配信パターンの一例を示す図である。 本発明においてリアルタイム連続データ・サービス・ディスエイブラを備えるパケット交換データ網上での一連のデータ・パッケージの送信に対するトラヒック配信パターンの一例を示す図である。 、 ケーブルモデム・ソリューションで実装された本発明の実施形態のうち、二つの例を表す概略図である。

Claims (37)

1. データ・パッケージを含むパケット交換データ・ストリーム内のリアルタイム連続データを制御する方法であって、
   受信ユーザへの提示の際に前記リアルタイム連続データの連続性を阻害するために、リアルタイム連続データ・サービスの利用を前記受信ユーザが許可されているか否かに関する認可状況に依存して前記パケット交換データ・ストリームのデータ・パッケージを保持する工程を有し、
   前記保持する工程において、前記受信ユーザが前記リアルタイム連続データ・サービスを許可されず且つリアルタイム性を要求されない非リアルタイム連続データ・サービスを許可される場合に、前記データ・パッケージは前記リアルタイム連続データ・サービスが許可されず且つ前記非リアルタイム連続データ・サービスが許可されるように保持される
   ことを特徴とする方法。
2. 前記データ・パッケージが一定の期間保持され、前記保持後に前記パケット交換データ・ストリームに戻されることを特徴とする請求項１に記載の方法。
3. 前記データ・パッケージを保持する工程が前記パケット交換データ・ストリーム内の複数の後続データ・パッケージを保持する工程を含むことを特徴とする請求項１又は２に記載の方法。
4. 前記データ・パッケージを保持する工程が前記パケット交換データ・ストリームの無作為に選ばれた一つ以上のデータ・パッケージを保持する工程を含むことを特徴とする請求項１又は２に記載の方法。
5. 前記リアルタイム連続データが一連のデータ・パッケージを含み、前記パケット交換データ・ストリームの前記データ・パッケージが前記一連のデータ・パッケージを並べ替えるために保持されることを特徴とする請求項１乃至４のいずれか１項に記載の方法。
6. 前記データ・パッケージが保持され、各々の保持されたデータ・パッケージまたは保持されたデータ・パッケージ群が、異なる保持時間で前記パケット交換データ・ストリームに戻されることを特徴とする請求項５に記載の方法。
7. 前記保持の長さが無作為に決められることを特徴とする請求項５に記載の方法。
8. 前記パケット交換データ・ストリームがデータ送信機からの送信データ・ストリームであることを特徴とする請求項１乃至７のいずれか１項に記載の方法。
9. 前記パケット交換データ・ストリームが、データ受信者への受信データ・ストリームであることを特徴とする請求項１乃至７のいずれか１項に記載の方法。
10. 前記データ・パッケージが前記受信ユーザにより受信された後に該データ・パッケージを再構築する工程をさらに有することを特徴とする請求項１乃至９のいずれか１項に記載の方法。
11. 前記再構築する工程が、トランスポート層、セッション層、プレゼンテーション層またはアプリケーション層を含むグループのある層上で実行されることを特徴とする請求項１０に記載の方法。
12. 前記再構築する工程が、前記受信されたデータ・パッケージをバッファリングする工程を含むことを特徴とする請求項１０又は１１に記載の方法。
13. 前記再構築する工程が、前記データ・パッケージの元々の送信順序に、前記受信されたデータ・パッケージを再配置する工程をさらに含むことを特徴とする請求項１０乃至１２のいずれか１項に記載の方法。
14. 前記データ・パッケージを保持する工程が、パケット交換データ網においてデータリンク層、ネットワーク層およびトランスポート層を含むグループのある層上で実行されることを特徴とする請求項１乃至１３のいずれか１項に記載の方法。
15. 前記リアルタイム連続データが、電話またはストリーミング・マルチユーザ・ゲームを含む前記リアルタイム連続データ・サービスを提供するために使用されることを特徴とする請求項１乃至１４のいずれか１項に記載の方法。
16. 前記認可状況が、前記リアルタイム連続データ・サービスのユーザにより提供される識別データを評価することによって設定されることを特徴とする請求項１乃至１５のいずれか１項に記載の方法。
17. サービス・レベルが前記パケット交換データ・ストリームに対して登録され、そして前記認可状況が登録された前記サービス・レベルにより決定されることを特徴とする請求項１乃至１６のいずれか１項に記載の方法。
18. 前記パケット交換データ・ストリームが通信ネットワークの加入者線上で転送されることを特徴とする請求項１乃至１７のいずれか１項に記載の方法。
19. 前記認可状況は、前記加入者線の加入条件により決定されることを特徴とする請求項１８に記載の方法。
20. 前記加入者線が、ＡＤＳＬ、ＳＤＳＬ、ＲＡＤＳＬ、ＨＤＳＬ、または、ＶＤＳＬを含むデジタル加入者線（ＤＳＬ）、ケーブルモデム・ソリューション、衛星インターネット、フレーム・リレー、ギガビット・イーサネット（登録商標）、或いは、ＬＭＤＳ、ＭＭＤＳ、ＷｉＭＡＸ、および、ＨＩＰＥＲＭＡＮを含むあらゆる無線ブロードバンド加入者ソリューション、を含むグループの中の少なくとも一つであることを特徴とする請求項１８又は１９に記載の方法。
21. 前記リアルタイム連続データ・サービスが、電話、ストリーミング・マルチユーザ・ゲーム、ストリーミング映像、ストリーミング音声を含むグループの中の少なくとも一つを含むことを特徴とする請求項１５乃至１９のいずれか１項に記載の方法。
22. パケット交換データ・ストリーム内のリアルタイム連続データを制御するためのシステムであって、前記パケット交換データ・ストリームがデータ・パッケージを含み、前記システムが、
    前記パケット交換データ・ストリームを途中で捕捉し、転送する手段と、
    前記リアルタイム連続データを受信ユーザに提示する際の該リアルタイム連続データの連続性を阻害するために、リアルタイム連続データ・サービスの利用を前記受信ユーザが許可されているか否かに関する認可状況に依存して前記パケット交換データ・ストリームのデータ・パッケージを保持する手段と
    を備え、
    データ・パッケージを前記保持する手段は、前記受信ユーザが前記リアルタイム連続データ・サービスを許可されず且つリアルタイム性を要求されない非リアルタイム連続データ・サービスを許可される場合に、前記リアルタイム連続データ・サービスが許可されず且つ前記非リアルタイム連続データ・サービスが許可されるように前記データ・パッケージを保持する
    ことを特徴とする、システム。
23. データ・パッケージを保持する前記手段が、一定の期間前記データ・パッケージを保持するように構成され、
    前記システムが、前記保持されたデータ・パッケージを前記パケット交換データ・ストリームに戻す手段をさらに備えることを特徴とする請求項２２に記載のシステム。
24. データ・パッケージを保持する前記手段が、前記データ・パッケージの各々またはデータ・パッケージの各々のグループを異なる保持時間で保持するように構成されていることを特徴とする請求項２３に記載のシステム。
25. 前記保持されたデータ・パッケージを遅延させるための前記手段が、前記保持されたデータ・パッケージまたは前記保持されたデータ・パッケージのグループの各々に対して無作為の継続保持時間を使用するように構成されていることを特徴とする請求項２４に記載のシステム。
26. データ・パッケージを保持する前記手段が、複数の後続データ・パッケージを保持するように構成されていることを特徴とする請求項２２乃至２５のいずれか１項に記載のシステム。
27. データ・パッケージを保持する前記手段が、一つ以上のデータ・パッケージを無作為に保持するようにさらに構成されていることを特徴とする請求項２２乃至２６のいずれか１項に記載のシステム。
28. 前記リアルタイム連続データ・サービスが前記リアルタイム連続データに関連していることを特徴とする請求項２２乃至２７のいずれか１項に記載のシステム。
29. 前記認可状況を決定する手段をさらに備えることを特徴とする請求項２２乃至２８のいずれか１項に記載のシステム。
30. 前記認可状況を決定する前記手段が、外部情報源から前記認可状況を受信する手段を備えることを特徴とする請求項２９に記載のシステム。
31. 前記認可状況を決定する前記手段が、ユーザにより提供される識別情報を受信し、評価する手段を備えることを特徴とする請求項２９に記載のシステム。
32. 前記認可状況を決定する前記手段が、前記パケット交換データ・ストリームに対して規定されるサービス・レベルから前記認可状況を決定するように構成されていることを特徴とする請求項２９又は３０に記載のシステム。
33. リアルタイム連続データ・サービスを提供するために、パケット交換データ網におけるリアルタイム連続データ・トラヒックを制御するための、請求項２２乃至３２のいずれか１項に記載のシステムの前記パケット交換データ網における使用方法。
34. 前記システムが、データ送信機からの送信リアルタイム連続データ・トラヒックを制御するように構成されていることを特徴とする請求項３３に記載の使用方法。
35. 前記システムが、データ受信機宛の受信リアルタイム連続データ・トラヒックを制御するように構成されていることを特徴とする請求項３３又は３４に記載の使用方法。
36. 電話、ストリーミング・マルチユーザ・ゲーム、ストリーミング映像またはストリーミング音声を含むリアルタイム連続データ・サービスを提供するための、請求項３３乃至３５のいずれか１項に記載の使用方法。
37. 電話、ストリーミング・マルチユーザ・ゲーム、ストリーミング映像またはストリーミング音声を含むリアルタイム連続データ・サービスであって、請求項１乃至２１のいずれか１項に記載の方法を使用して提供され、前記リアルタイム連続データ・サービスが前記リアルタイム連続データを使用して提供されることを特徴とする、リアルタイム連続データ・サービスの提供方法。

Images