特許 6542866 リアルタイムライブ環境でのバッファに基づく帯域幅測定および適応的データ送信のための方法およびシステム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】6542866

(24)【登録日】2019年6月21日

(45)【発行日】2019年7月10日

(54)【発明の名称】リアルタイムライブ環境でのバッファに基づく帯域幅測定および適応的データ送信のための方法およびシステム

(51)【国際特許分類】

   H04L 12/811 20130101AFI20190628BHJP

   H04L 12/823 20130101ALI20190628BHJP

   H04N 21/24 20110101ALI20190628BHJP

   H04L 12/853 20130101ALI20190628BHJP

【ＦＩ】

   H04L12/811

   H04L12/823

   H04N21/24

   H04L12/853

【請求項の数】20

【全頁数】15

(21)【出願番号】特願2017-248043(P2017-248043)

(22)【出願日】2017年12月25日

(65)【公開番号】特開2018-110387(P2018-110387A)

(43)【公開日】2018年7月12日

【審査請求日】2017年12月25日

(31)【優先権主張番号】10-2016-0181134

(32)【優先日】2016年12月28日

(33)【優先権主張国】KR

(73)【特許権者】

【識別番号】505205812

【氏名又は名称】ネイバー コーポレーション

【氏名又は名称原語表記】ＮＡＶＥＲ Ｃｏｒｐｏｒａｔｉｏｎ

(74)【代理人】

【識別番号】100107766

【弁理士】

【氏名又は名称】伊東 忠重

(74)【代理人】

【識別番号】100070150

【弁理士】

【氏名又は名称】伊東 忠彦

(74)【代理人】

【識別番号】100091214

【弁理士】

【氏名又は名称】大貫 進介

(72)【発明者】

【氏名】チャン ジュンギ

(72)【発明者】

【氏名】キム ソンホ

(72)【発明者】

【氏名】チョウ ソンテク

(72)【発明者】

【氏名】カン インチョル

(72)【発明者】

【氏名】ア ジフン

(72)【発明者】

【氏名】キム ジョンミョン

(72)【発明者】

【氏名】イ ヨンス

【審査官】 松崎 孝大

(56)【参考文献】

【文献】 特開２００６−１１５３０６（ＪＰ，Ａ）

【文献】 特開２００６−１４０９８４（ＪＰ，Ａ）

【文献】 特開２０１０−２４５８２２（ＪＰ，Ａ）

【文献】 特開２０１４−０１１６３６（ＪＰ，Ａ）

【文献】 特開２０１４−１１２７７９（ＪＰ，Ａ）

【文献】 国際公開第２００６／０７７６２１（ＷＯ，Ａ１）

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｈ０４Ｌ １２／８１１

Ｈ０４Ｌ １２／８２３

Ｈ０４Ｌ １２／８５３

Ｈ０４Ｎ ２１／２４

(57)【特許請求の範囲】

【請求項1】

コンピュータで実現される方法であって、
前記方法は、サーバにより実施され、
前記サーバ側で、リアルタイムライブ環境でデータパケットを管理するライブ送出パブリッシャーが持っているバッファのデュレーションを確認する段階、および
前記バッファのデュレーションを基準としてネットワークの状態を推定して前記バッファのデュレーションに相応する帯域幅を推定し、前記帯域幅に適応的にデータ送信速度を制御する段階
を含む、方法。

【請求項2】

前記確認する段階は、
周期的に第１時間間隔ごとに前記バッファのデュレーションを確認する、
請求項１に記載の方法。

【請求項3】

前記制御する段階は、
前記バッファのデュレーションが第２時間以上であればビットレートを減少させる段階、および
前記バッファのデュレーションが前記第２時間未満であれば前記ビットレートを増加させる段階
を含む、請求項１に記載の方法。

【請求項4】

前記減少させる段階は、
前記バッファのデュレーションが第２時間以上である場合に推定された前記ネットワークの帯域幅を可用帯域幅として推定し、前記可用帯域幅に応じて前記ビットレートを減少させる、
請求項３に記載の方法。

【請求項5】

前記減少させる段階は、
前記データパケットに含まれるビデオパケットおよびオーディオパケットのうちの少なくとも１つをドロップさせる、
請求項３に記載の方法。

【請求項6】

前記減少させる段階は、
前記バッファのデュレーションが第３時間以下である場合、前記データパケットに含まれるビデオパケットおよびオーディオパケットのうちの前記ビデオパケットだけをドロップさせる段階、および
前記バッファのデュレーションが前記第３時間を超える場合、前記ビデオパケットおよび前記オーディオパケットの両方をドロップさせる段階
を含む、請求項３に記載の方法。

【請求項7】

前記増加させる段階は、
前記バッファのデュレーションが前記第２時間未満であれば、ステップ単位で前記ビットレートを増加させる、
請求項３に記載の方法。

【請求項8】

前記増加させる段階は、
前記バッファのデュレーションが前記第２時間未満である状態が連続的に設定回数以上持続すれば、ステップ単位で前記ビットレートを増加させる段階
を含む、請求項３に記載の方法。

【請求項9】

前記増加させる段階は、
前記ビットレートを増加させた後、前記バッファのデュレーションが前記第２時間未満である状態が第４時間維持されなければ前記設定回数を増やす段階、および
前記ビットレートを増加させた後、前記バッファのデュレーションが前記第２時間未満である状態が前記第４時間維持されれば前記設定回数を減らす段階
をさらに含む、請求項８に記載の方法。

【請求項10】

前記確認する段階は、
前記第１時間内に前記バッファのデュレーションを１回確認し、前記第１時間内の前記バッファのデュレーションの全体平均値として計算する、
請求項２に記載の方法。

【請求項11】

前記確認する段階は、
前記第１時間内に一定の間隔で前記バッファのデュレーションを複数回確認し、デュレーションの増加または減少速度に応じた加重値を利用して前記バッファのデュレーションを計算する、
請求項２に記載の方法。

【請求項12】

コンピュータに請求項１ないし１１のうちのいずれか一項に記載の方法を実行させるためのコンピュータプログラム。

【請求項13】

コンピュータで実現されるシステムであって、
コンピュータが読み取り可能な命令を実行するように実現される少なくとも１つのプロセッサ
を含み、
前記少なくとも１つのプロセッサは、
前記システム側で、リアルタイムライブ環境でデータパケットを管理するライブ送出パブリッシャーが持っているバッファのデュレーションを確認するバッファ確認部、および
前記バッファのデュレーションを基準としてネットワークの状態を推定して前記バッファのデュレーションに相応する帯域幅を推定し、前記帯域幅に適応的にデータ送信速度を制御する送信速度制御部
を備える、システム。

【請求項14】

前記バッファ確認部は、
周期的に第１時間間隔ごとに前記バッファのデュレーションを確認する、
請求項１３に記載のシステム。

【請求項15】

前記送信速度制御部は、
前記バッファのデュレーションが第２時間以上であればビットレートを減少させ、
前記バッファのデュレーションが前記第２時間未満であれば前記ビットレートを増加させる、
請求項１３に記載のシステム。

【請求項16】

前記送信速度制御部は、
前記バッファのデュレーションが第２時間以上である場合に推定された前記ネットワークの帯域幅を可用帯域幅として推定し、前記可用帯域幅に応じて前記ビットレートを減少させる、
請求項１５に記載のシステム。

【請求項17】

前記送信速度制御部は、
前記ビットレートを減少させるにあたり、前記データパケットに含まれるビデオパケットおよびオーディオパケットのうちの少なくとも１つをドロップさせる、
請求項１６に記載のシステム。

【請求項18】

前記送信速度制御部は、
前記バッファのデュレーションが前記第２時間未満であればステップ単位で前記ビットレートを増加させる、
請求項１５に記載のシステム。

【請求項19】

前記送信速度制御部は、
前記バッファのデュレーションが前記第２時間未満である状態が連続的に設定回数以上持続すれば、ステップ単位で前記ビットレートを増加させる、
請求項１５に記載のシステム。

【請求項20】

前記送信速度制御部は、
前記ビットレートを増加させた後、前記バッファのデュレーションが前記第２時間未満である状態が第４時間維持されなければ前記設定回数を増やし、
前記ビットレートを増加させた後、前記バッファのデュレーションが前記第２時間未満である状態が前記第４時間維持されれば前記設定回数を減らす、
請求項１９に記載のシステム。

【発明の詳細な説明】

【技術分野】

【0001】

以下の説明は、ネットワークの帯域幅を測定し、測定された帯域幅に合わせてデータを送信する技術に関する。

【背景技術】

【0002】

インターネットは、パケット単位でデータを送受信するのが一般的であるが、通信する２つの端末間に送信帯域幅が常に保障されるのではなく、経路が選定されると、各パケット単位で動的に帯域幅を占有しながらデータが送受信されるようになる。

【0003】

最近では、動画などの大容量データの使用が一般化しているが、動画データをリアルタイムでストリーミングするサービスの場合、ネットワークの送信帯域幅に合わせて動画データを送信することで、ＱｏＳ（Ｑｕａｌｉｔｙ ｏｆ Ｓｅｒｖｉｃｅ）を満たしたサービスを提供することができる。

【0004】

この場合、ネットワークを介してデータを送信するときに実際に送信可能なデータの帯域幅を測定する技術は、極めて重要な役割を担っている。一例として、特許文献１には、モバイル送信網の帯域幅をリアルタイムで測定する技術が開示されている。

【先行技術文献】

【特許文献】

【0005】

【特許文献1】韓国登録特許第１０−１１８２５５０号公報

【発明の概要】

【発明が解決しようとする課題】

【0006】

リアルタイムライブ環境でデータパケットを管理するバッファのデュレーション（ｄｕｒａｔｉｏｎ）に基づいてネットワーク帯域幅を測定し、測定された帯域幅に適応的にデータ送信速度を変更するＡＢＰ（Ａｄａｐｔｉｖｅ Ｂｉｔｒａｔｅ Ｐｕｂｌｉｓｈ）技術を提供する。

【課題を解決するための手段】

【0007】

コンピュータで実現される方法であって、リアルタイムライブ環境でデータパケットを管理するバッファのデュレーションを確認する段階、および前記バッファのデュレーションに基づいてネットワークの帯域幅を測定し、前記帯域幅に適応的にデータ送信速度を制御する段階を含む方法を提供する。

【0008】

一側面によると、前記確認する段階は、周期的に第１時間間隔ごとに前記バッファのデュレーションを確認してよい。

【0009】

他の側面によると、前記制御する段階は、前記バッファのデュレーションが第２時間以上であればビットレートを減少させる段階、および前記バッファのデュレーションが前記第２時間未満であれば前記ビットレートを増加させる段階を含む。

【0010】

また他の側面によると、前記減少させる段階は、前記バッファのデュレーションが第２時間以上であれば前記ネットワークの可用帯域幅を測定し、前記可用帯域幅に応じて前記ビットレートを減少させてよい。

【0011】

また他の側面によると、前記減少させる段階は、前記データパケットに含まれるビデオパケットおよびオーディオパケットのうちの少なくとも１つをドロップ（ｄｒｏｐ）させてよい。

【0012】

また他の側面によると、前記減少させる段階は、前記バッファのデュレーションが第３時間以下である場合、前記データパケットに含まれるビデオパケットおよびオーディオパケットのうちの前記ビデオパケットだけをドロップさせる段階、および前記バッファのデュレーションが前記第３時間を超える場合、前記ビデオパケットおよび前記オーディオパケットの両方をドロップさせる段階を含む。

【0013】

また他の側面によると、前記増加させる段階は、前記バッファのデュレーションが前記第２時間未満であれば、ステップ（ｓｔｅｐ）単位で前記ビットレートを増加させてよい。

【0014】

また他の側面によると、前記増加させる段階は、前記バッファのデュレーションが前記第２時間未満である状態が連続して設定回数以上持続すれば、ステップ単位で前記ビットレートを増加させる段階を含む。

【0015】

また他の側面によると、前記増加させる段階は、前記ビットレートを増加させた後、前記バッファのデュレーションが前記第２時間未満である状態が第４時間維持されなければ前記設定回数を増やす段階、および前記ビットレートを増加させた後、前記バッファのデュレーションが前記第２時間未満である状態が前記第４時間維持されれば前記設定回数を減らす段階をさらに含む。

【0016】

また他の側面によると、前記確認する段階は、前記第１時間内に前記バッファのデュレーションを１回確認し、前記第１時間内の前記バッファのデュレーションの全体平均値として計算してよい。

【0017】

また他の側面によると、前記確認する段階は、前記第１時間内に一定の間隔で前記バッファのデュレーションを複数回確認し、デュレーションの増加または減少速度に応じた加重値を利用して前記バッファのデュレーションを計算してよい。

【0018】

コンピュータに上記の方法を実行させるためのコンピュータプログラムを提供する。

【0019】

コンピュータで実現されるシステムであって、コンピュータが読み取り可能な命令を実行するように実現される少なくとも１つのプロセッサを含み、前記少なくとも１つのプロセッサは、リアルタイムライブ環境でデータパケットを管理するバッファのデュレーションを確認するバッファ確認部、および前記バッファのデュレーションに基づいてネットワークの帯域幅を測定し、前記帯域幅に適応的にデータ送信速度を制御する送信速度制御部を備えるシステムを提供する。

【発明の効果】

【0020】

本発明の実施形態によると、データパケットを管理するバッファのデュレーションに基づいてネットワーク帯域幅を測定し、測定された帯域幅に適応的にデータ送信速度を変更することにより、リアルタイムライブ環境に適した適応的データ送信技術を実現することができる。

【図面の簡単な説明】

【0021】

【図1】本発明の一実施形態における、ネットワーク環境の例を示した図である。

【図2】本発明の一実施形態における、電子機器およびサーバの内部構成を説明するためのブロック図である。

【図3】本発明の一実施形態における、サーバのプロセッサが含むことのできる構成要素の例を示した図である。

【図4】本発明の一実施形態における、サーバが実行することのできる方法の例を示したフローチャートである。

【図5】本発明の一実施形態における、適応的データ送信過程を示したフローチャートである。

【図6】本発明の一実施形態における、帯域幅に応じたビットレート変化過程を示したグラフである。

【発明を実施するための形態】

【0022】

以下、本発明の実施形態について、添付の図面を参照しながら詳細に説明する。

【0023】

本発明の実施形態は、ネットワーク帯域幅を測定して帯域幅に適応的なリアルタイムライブ環境を提供する技術に関する。

【0024】

本明細書で具体的に開示される事項などを含む実施形態は、リアルタイムライブ環境でのバッファに基づく帯域幅測定および適応的データ送信を実現することができ、これにより、サービス品質向上、効率性、コスト節減などの側面において相当な長所を達成する。

【0025】

図１は、本発明の一実施形態における、ネットワーク環境の例を示した図である。図１のネットワーク環境は、複数の電子機器１１０、１２０、１３０、１４０、複数のサーバ１５０、１６０、およびネットワーク１７０を含む例を示している。このような図１は、発明の説明のための一例に過ぎず、電子機器の数やサーバの数が図１のように限定されることはない。

【0026】

複数の電子機器１１０、１２０、１３０、１４０は、コンピュータ装置によって実現される固定端末や移動端末であってよい。複数の電子機器１１０、１２０、１３０、１４０の例としては、スマートフォン、携帯電話、ナビゲーション、コンピュータ、ノート型パソコン、デジタル放送用端末、ＰＤＡ（Ｐｅｒｓｏｎａｌ Ｄｉｇｉｔａｌ Ａｓｓｉｓｔａｎｔ）、ＰＭＰ（Ｐｏｒｔａｂｌｅ Ｍｕｌｔｉｍｅｄｉａ Ｐｌａｙｅｒ）、タブレットなどがある。一例として、電子機器１（１１０）は、無線または有線通信方式を利用し、ネットワーク１７０を介して他の電子機器１２０、１３０、１４０および／またはサーバ１５０、１６０と通信してよい。

【0027】

通信方式が限定されることはなく、ネットワーク１７０が含むことのできる通信網（一例として、移動通信網、有線インターネット、無線インターネット、放送網）を活用する通信方式だけではなく、機器間の近距離無線通信が含まれてもよい。例えば、ネットワーク１７０は、ＰＡＮ（ｐｅｒｓｏｎａｌ ａｒｅａ ｎｅｔｗｏｒｋ）、ＬＡＮ（ｌｏｃａｌ ａｒｅａ ｎｅｔｗｏｒｋ）、ＣＡＮ（ｃａｍｐｕｓ ａｒｅａ ｎｅｔｗｏｒｋ）、ＭＡＮ（ｍｅｔｒｏｐｏｌｉｔａｎ ａｒｅａ ｎｅｔｗｏｒｋ）、ＷＡＮ（ｗｉｄｅ ａｒｅａ ｎｅｔｗｏｒｋ）、ＢＢＮ（ｂｒｏａｄｂａｎｄ ｎｅｔｗｏｒｋ）、インターネットなどのネットワークのうちの１つ以上の任意のネットワークを含んでよい。さらに、ネットワーク１７０は、バスネットワーク、スターネットワーク、リングネットワーク、メッシュネットワーク、スター−バスネットワーク、ツリーまたは階層的（ｈｉｅｒａｒｃｈｉｃａｌ）ネットワークなどを含むネットワークトポロジのうちの任意の１つ以上を含んでもよいが、これらに限定されることはない。

【0028】

サーバ１５０、１６０それぞれは、複数の電子機器１１０、１２０、１３０、１４０とネットワーク１７０を介して通信して命令、コード、ファイル、コンテンツ、サービスなどを提供する１つ以上のコンピュータ装置によって実現されてよい。

【0029】

一例として、サーバ１６０は、ネットワーク１７０を介して接続した電子機器１（１１０）にアプリケーションのインストールのためのファイルを提供してよい。この場合、電子機器１（１１０）は、サーバ１６０から提供されたファイルを利用してアプリケーションをインストールしてよい。また、電子機器１（１１０）が含むオペレーティングシステム（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ：ＯＳ）や少なくとも１つのプログラム（一例として、ブラウザやインストールされたアプリケーション）の制御にしたがってサーバ１５０に接続し、サーバ１５０が提供するサービスやコンテンツの提供を受けてよい。例えば、電子機器１（１１０）がアプリケーションの制御にしたがい、ネットワーク１７０を介してサービス要求メッセージをサーバ１５０に送信すると、サーバ１５０はサービス要求メッセージに対応するコードを電子機器１（１１０）に送信してよく、電子機器１（１１０）はアプリケーションの制御にしたがってコードに基づいた画面を構成して表示することにより、ユーザにコンテンツを提供してよい。

【0030】

図２は、本発明の一実施形態における、電子機器およびサーバの内部構成を説明するためのブロック図である。図２では、１つの電子機器に対する例として電子機器１（１１０）の内部構成を、１つのサーバに対する例としてサーバ１５０の内部構成を説明する。他の電子機器１２０、１３０、１４０やサーバ１６０も、同一または類似の内部構成を有してよい。

【0031】

電子機器１（１１０）およびサーバ１５０は、メモリ２１１、２２１、プロセッサ２１２、２２２、通信モジュール２１３、２２３、および入力／出力インタフェース２１４、２２４を含んでよい。メモリ２１１、２２１は、コンピュータで読み取り可能な記録媒体であって、ＲＡＭ（ｒａｎｄｏｍ ａｃｃｅｓｓ ｍｅｍｏｒｙ）、ＲＯＭ（ｒｅａｄ ｏｎｌｙ ｍｅｍｏｒｙ）、およびディスクドライブのような永続的大容量記憶装置を含んでよい。また、メモリ２１１、２２１には、オペレーティングシステムと、少なくとも１つのプログラムコード（一例として、電子機器１（１１０）にインストールされ駆動するアプリケーションなどのためのコード）が格納されてよい。このようなソフトウェア構成要素は、メモリ２１１、２２１とは別のコンピュータで読み取り可能な記録媒体からロードされてよい。このような別のコンピュータで読み取り可能な記録媒体は、フロッピー（登録商標）ドライブ、ディスク、テープ、ＤＶＤ／ＣＤ−ＲＯＭドライブ、メモリカードなどのコンピュータで読み取り可能な記録媒体を含んでよい。他の実施形態において、ソフトウェア構成要素は、コンピュータで読み取り可能な記録媒体ではない通信モジュール２１３、２２３を通じてメモリ２１１、２２１にロードされてもよい。例えば、少なくとも１つのプログラムは、開発者またはアプリケーションのインストールファイルを配布するファイル配布システム（一例として、上述したサーバ１６０）がネットワーク１７０を介して提供するファイルによってインストールされるプログラム（一例として、上述したアプリケーション）に基づいてメモリ２１１、２２１にロードされてよい。

【0032】

プロセッサ２１２、２２２は、基本的な算術、ロジック、および入出力演算を実行することにより、コンピュータプログラムの命令を処理するように構成されてよい。命令は、メモリ２１１、２２１または通信モジュール２１３、２２３によって、プロセッサ２１２、２２２に提供されてよい。例えば、プロセッサ２１２、２２２は、メモリ２１１、２２１のような記録装置に格納されたプログラムコードにしたがって受信される命令を実行するように構成されてよい。

【0033】

通信モジュール２１３、２２３は、ネットワーク１７０を介して電子機器１（１１０）とサーバ１５０とが互いに通信するための機能を提供してもよいし、他の電子機器（一例として、電子機器２（１２０））または他のサーバ（一例として、サーバ１６０）と通信するための機能を提供してもよい。一例として、電子機器１（１１０）のプロセッサ２１２がメモリ２１１のような記録装置に格納されたプログラムコードにしたがって生成した要求（一例として、検索要求）が、通信モジュール２１３の制御にしたがってネットワーク１７０を介してサーバ１５０に伝達されてよい。これとは逆に、サーバ１５０のプロセッサ２２２の制御にしたがって提供される制御信号や命令、コンテンツ、ファイルなどが、通信モジュール２２３およびネットワーク１７０を経て電子機器１（１１０）の通信モジュール２１３を通じて電子機器１（１１０）に受信されてもよい。例えば、通信モジュール２１３を通じて受信したサーバ１５０の制御信号や命令などは、プロセッサ２１２やメモリ２１１に伝達されてよく、コンテンツやファイルなどは、電子機器１（１１０）がさらに含むことのできる格納媒体に格納されてよい。

【0034】

入力／出力インタフェース２１４は、入力／出力装置２１５とのインタフェースのための手段であってよい。例えば、入力装置は、キーボードまたはマウスなどの装置を、出力装置は、アプリケーションの通信セッションを表示するためのディスプレイのような装置を含んでよい。他の例として、入力／出力インタフェース２１４は、タッチスクリーンのように入力および出力のための機能が１つに統合された装置とのインタフェースのための手段であってもよい。より具体的な例として、電子機器１（１１０）のプロセッサ２１２は、メモリ２１１にロードされたコンピュータプログラムの命令を処理するにあたり、サーバ１５０や電子機器２（１２０）が提供するデータを利用して構成されるサービス画面やコンテンツが入力／出力インタフェース２１４を通じてディスプレイに表示されてよい。

【0035】

また、他の実施形態において、電子機器１（１１０）およびサーバ１５０は、図２の構成要素よりも多くの構成要素を含んでもよい。しかし、大部分の従来技術的構成要素を明確に図に示す必要はない。例えば、電子機器１（１１０）は、上述した入力／出力装置２１５のうちの少なくとも一部を含むように実現されてもよいし、トランシーバ、ＧＰＳ（Ｇｌｏｂａｌ Ｐｏｓｉｔｉｏｎｉｎｇ Ｓｙｓｔｅｍ）モジュール、カメラ、各種センサ、データベースなどのような他の構成要素をさらに含んでもよい。より具体的な例として、電子機器１（１１０）がスマートフォンである場合、一般的にスマートフォンが含んでいる加速度センサやジャイロセンサ、カメラ、各種の物理的なボタン、タッチパネルを利用したボタン、入力／出力ポート、振動のための振動器などのような多様な構成要素が電子機器１（１１０）にさらに含まれるように実現されてよいことが分かる。

【0036】

以下では、リアルタイムライブ環境でのバッファに基づく帯域幅測定および適応的データ送信のための方法およびシステムの具体的な実施形態について説明する。

【0037】

ネットワークのＲＴＴ（ｒｏｕｎｄ ｔｒｉｐ ｔｉｍｅ）に基づいてデータ送信速度を測定する方法は、データのサイズが小さかったり連続的でなかったりする場合に誤差が大きく発生することから、リアルタイムライブプロトコル（例えば、ＲＴＭＰ（ｒｅａｌ ｔｉｍｅ ｍｅｓｓａｇｉｎｇ ｐｒｏｔｏｃｏｌ）など）には適さない。

【0038】

本発明では、リアルタイムライブ環境に適したデータ送信環境を実現するために、サーバ１５０側で（一例として、ライブ送信モジュールで）管理しているデータ（オーディオ／ビデオ）パケットバッファのデュレーションに基づいてネットワーク帯域幅を測定し、測定された帯域幅に適応的にビットレートおよびｆｐｓ（ｆｒａｍｅ ｐｅｒ ｓｅｃｏｎｄ）を即時（ｏｎ ｔｈｅ ｆｌｙ）変更する適応的データ送信技術を提供する。

【0039】

言い換えれば、ＲＴＭＰのようなパブリッシャが持っているバッファのデュレーションに基づいてネットワーク状態を推定し、これによって適応的にデータ送信速度を高めたり低めたりする機能を提供する。

【0040】

図３は、本発明の一実施形態における、サーバのプロセッサが含むことのできる構成要素の例を示した図であり、図４は、本発明の一実施形態における、サーバが実行することのできる方法の例を示したフローチャートである。

【0041】

図３に示すように、サーバ１５０のプロセッサ２２２は、構成要素として、バッファ確認部３１０および送信速度制御部３２０を備えてよい。このようなプロセッサ２２２およびプロセッサ２２２の構成要素は、図４の方法が含む段階４１０〜４２０を実行するようにサーバ１５０を制御してよい。ここで、プロセッサ２２２およびプロセッサ２２２の構成要素は、メモリ２２１が含むオペレーティングシステムのコードおよび少なくとも１つのプログラムのコードによる命令を実行するように実現されてよい。また、プロセッサ２２２の構成要素は、オペレーティングシステムや少なくとも１つのプログラムが提供する制御命令にしたがってプロセッサ２２２によって実行される互いに異なる機能の表現であってよい。例えば、プロセッサ２２２が上述した制御命令にしたがってバッファのデュレーションを確認する機能的表現としてバッファ確認部３１０が使用されてよい。

【0042】

段階４１０で、バッファ確認部３１０は、電子機器１（１１０）に動画などのデータをリアルタイムで送信するリアルタイムライブ環境でデータ（オーディオ／ビデオ）パケットを一時格納するために利用されるバッファのデュレーションを確認してよい。このとき、バッファ確認部３１０は、周期的に第１時間（例えば、２秒）間隔ごとにデータパケットを管理するバッファの待ち行列であるキューのデュレーションを確認してよい。一例として、バッファ確認部３１０は、Ａ秒（第１時間）を周期としてＡ秒間に１回またはａ秒間隔ごとにＮ回（ａ秒×Ｎ回＝Ａ秒）バッファのデュレーションを確認してよい。Ａ秒間に１回の測定をする場合、バッファデュレーションの全体平均値としてデュレーションを計算してよい。ａ秒間隔ごとにＡ秒間でＮ回の測定をする場合、バッファデュレーションの増加または減少速度をみながらｉ回ごとに加重値をおいてデュレーションを計算してよい。

【0043】

段階４２０で、送信速度制御部３２０は、段階４１０で確認されたバッファのデュレーションに基づいて電子機器１（１１０）に接続するネットワーク１７０の帯域幅を測定し、ネットワーク１７０の帯域幅に適応的にデータ送信速度を制御してよい。これにより、送信速度制御部３２０は、データパケットを管理するバッファのデュレーションに基づいてデータ送信速度を変更する適応的データ送信環境を実現することができる。

【0044】

送信速度制御部３２０の適応的データ送信過程は、図５を参照しながらより具体的に説明される。

【0045】

本発明に係る適応的データ送信技術の基本動作条件は、次のとおりとなる。

【0046】

（１）ビットレート減少方策：ビットレートを低めること（例えば、動画画質を低めること）は、敏感に動作しなければならない。

【0047】

（２）ビットレート増加方策：ビットレートを高めること（例えば、動画画質を高めること）は、保守的に動作しなければならない。

【0048】

図５を参照すると、段階５０１で、送信速度制御部３２０は、バッファのデュレーションが第２時間（例えば、１秒）以上であれば、ビットレート減少方策を適用し、バッファのデュレーションに基づいてネットワーク１７０の可用帯域幅を測定してビットレートを減少させてよい。第２時間は、ビットレート減少方策またはビットレート増加方策のどちらを適用するかを決める基準となってよい。

【0049】

送信速度制御部３２０は、バッファデュレーションが第２時間を超える場合、ビットレート減少方策にしたがって帯域幅を測定してビットレート（以下のｎｅｗ ｂｉｔｒａｔｅ）を変更してよいが、このとき、ビットレート（ｎｅｗ ｂｉｔｒａｔｅ）は、以下の式（１）のように定義されてよい。

【0050】

ｎｅｗ ｂｉｔｒａｔｅ＝（１．０−（Ｂ／Ａ））×ｃｕｒｒｅｎｔ ｂｉｔｒａｔｅ×加重値・・・（１）

【0051】

ここで、Ａは第１時間を、Ｂは第２時間を、ｃｕｒｒｅｎｔ ｂｉｔｒａｔｅは現在のビットレートを意味する。

【0052】

式（１）の加重値ファクタにより、ネットワーク１７０の可用帯域幅をもう少し肯定的にまたは保守的に処理してよい。例えば、１．０よりも大きい加重値を適用することによって帯域幅を肯定的に処理してよく、１．０よりも小さい加重値を適用することによって帯域幅を保守的に処理してよい。

【0053】

送信速度制御部３２０は、ビットレート減少方策にしたがい、変更しようとするビットレート（ｎｅｗ ｂｉｔｒａｔｅ）が事前に定められた最小ビットレートよりも低ければ、最小ビットレートとして設定および変更してよい。

【0054】

ビットレートを減らすためには、ビデオパケットおよびオーディオパケットのうちの少なくとも１つをドロップさせてよい。

【0055】

ビデオパケットをドロップさせる場合には、ユーザ端でｆｐｓが離れている感じがするといった程度であるが、オーディオパケットをドロップさせる場合には、音が切れて連続的な感じが失われるため、ユーザのサービス利用に不快感を与えるようになる。

【0056】

したがって、ビットレート減少方策では、オーディオパケットをビデオパケットよりも優先的に最大限送信するように例外処理してよい。一例として、送信速度制御部３２０は、バッファデュレーションが第３時間以下である場合にはビデオパケットだけをドロップさせ、バッファデュレーションが第３時間を超える場合にはビデオパケットおよびオーディオパケットの両方をドロップさせてよい。ただし、送信速度制御部３２０は、バッファデュレーションが第２時間を超える状況でターゲットビットレートが事前に定められた最小ビットレートである場合、ビデオパケットおよびオーディオパケットの両方をドロップさせてよい。

【0057】

再び図５において、段階５０２で、送信速度制御部３２０は、バッファのデュレーションが第２時間未満であれば、ビットレート増加方策を適用し、ビットレートを段階的に増加させてよい。例えば、第２時間が１秒である場合、バッファのデュレーションが１秒以上であればビットレート減少方策を適用し、バッファのデュレーションが１秒未満であればビットレート増加方策を適用してよい。

【0058】

バッファ確認部３１０は、周期的に第１時間ごとにバッファのデュレーションを確認するようになるが、このとき、送信速度制御部３２０は、第１時間ごとに確認されたバッファのデュレーションが第２時間未満である状態が連続的に設定回数（Ｎ回）以上持続すれば、ビットレートを一段階高めてよい。

【0059】

バッファデュレーションに基づいて帯域幅を測定するとき、現在送信中であるビットレート以上での速度測定は不可能であるため、ビットレート増加方策の場合、ステップ単位でビットレートを段階的に高めてよい。この場合、ビットレートを増加させるとき、ステップサイズは、特定の定数値または基本ビットレートの１／Ｎ値であってよい。

【0060】

ビットレート増加を決定する１つの基準となる設定回数は、他のファクタに基づいて変更されてよい。一例として、ビットレートを高めた後、バッファのデュレーションが第２時間未満である状態が第４時間（例えば、３０秒）以上持続せずにビットレート減少条件を満たすようになれば、設定回数に該当するＦファクタに一定の定数（Ｋ）を掛ける。例えば、Ｆファクタの初期値が５、最大値が３０、一定の定数が２である場合に、上述した条件が繰り返し満たされる場合、設定回数は５→１０→２０→３０に変更されてよい。言い換えれば、送信速度制御部３２０は、ビットレートを高めた後、バッファのデュレーションが第２時間未満である状態が第４時間維持されないときには設定回数を増やし、以後からはもう少し保守的にビットレートを高めてよい。一方、以前にビットレートを高めた状態でビットレート増加方策の条件を満たし、ビットレートをまた高めるようになる場合、Ｆファクタを一定の定数（Ｋ）で割ってよい。Ｆファクタの初期値が３０、最小値が５、一定の定数が２である場合に、上述した条件が繰り返し満たされる場合、設定回数は３０→１５→７→５に変更されてよい。すなわち、送信速度制御部３２０は、ビットレートを高めてバッファのデュレーションが第２時間未満である状態が第４時間維持されるときには設定回数を減らし、以後からはもう少し積極的にビットレートを高めてよい。

【0061】

送信速度制御部３２０は、ビットレート減少／増加方策を適用する前にｆｐｓを変更し、バッファリング状態の復旧または画質向上が可能であると判断されれば、ビットレートに比べてｆｐｓを優先的に変更処理してよい。例えば、３０ｆｐｓで送信中の状態と測定された帯域幅が現在はビットレートの１／２である場合、１５ｆｐｓに変更してよい。

【0062】

図６は、本発明の一実施形態における、帯域幅制限によるビットレート変化過程を示したグラフである。

【0063】

図６を参照すると、初期帯域幅（ＢＷ）２Ｍｂｐｓから帯域幅を５００Ｋｂｐｓに制限する場合、ビットレート減少方策によって比較的短い時間内にビットレートが急激に下がるようになる。この後、帯域幅が５００Ｋｂｐｓから１２００Ｋｂｐｓに増加するようになれば、ビットレート増加方策が適用されながらビットレートが段階的に高くなる。再び、帯域幅が１２００Ｋｂｐｓから５００Ｋｂｐｓに減少するようになれば、ビットレート減少方策により、ビットレートが減少した後は一定の水準を維持するようになる。図６に示すように、ビットレート減少方策では、敏感な動作条件によって早い時間内にターゲットビットレートに到達するのに対し、ビットレート増加方策では、保守的な動作条件により、ビットレート減少方策に比べてターゲットビットレートまでの到達時間が比較的長い。

【0064】

このように、本発明の実施形態によると、データパケットを管理するバッファのデュレーションに基づいてネットワーク帯域幅を測定し、測定された帯域幅に適応的にデータ送信速度を変更することにより、リアルタイムライブ環境に適した適応的データ送信技術を実現することができる。

【0065】

上述した装置は、ハードウェア構成要素、ソフトウェア構成要素、および／またはハードウェア構成要素とソフトウェア構成要素との組み合わせによって実現されてよい。例えば、実施形態で説明された装置および構成要素は、プロセッサ、コントローラ、ＡＬＵ（ａｒｉｔｈｍｅｔｉｃ ｌｏｇｉｃ ｕｎｉｔ）、デジタル信号プロセッサ、マイクロコンピュータ、ＦＰＧＡ（ｆｉｅｌｄ ｐｒｏｇｒａｍｍａｂｌｅ ｇａｔｅ ａｒｒａｙ）、ＰＬＵ（ｐｒｏｇｒａｍｍａｂｌｅ ｌｏｇｉｃ ｕｎｉｔ）、マイクロプロセッサ、または命令を実行して応答することができる様々な装置のように、１つ以上の汎用コンピュータまたは特殊目的コンピュータを利用して実現されてよい。処理装置は、オペレーティングシステム（ＯＳ）およびＯＳ上で実行される１つ以上のソフトウェアアプリケーションを実行してよい。また、処理装置は、ソフトウェアの実行に応答し、データにアクセスし、データを格納、操作、処理、および生成してもよい。理解の便宜のために、１つの処理装置が使用されるとして説明される場合もあるが、当業者は、処理装置が複数個の処理要素および／または複数種類の処理要素を含んでもよいことが理解できるであろう。例えば、処理装置は、複数個のプロセッサまたは１つのプロセッサおよび１つのコントローラを含んでよい。また、並列プロセッサのような、他の処理構成も可能である。

【0066】

ソフトウェアは、コンピュータプログラム、コード、命令、またはこれらのうちの１つ以上の組み合わせを含んでもよく、思うままに動作するように処理装置を構成したり、独立的または集合的に処理装置に命令したりしてよい。ソフトウェアおよび／またはデータは、処理装置に基づいて解釈されたり、処理装置に命令またはデータを提供したりするために、いかなる種類の機械、コンポーネント、物理装置、仮想装置、コンピュータ格納媒体または装置に具現化されてよい。ソフトウェアは、ネットワークによって接続されたコンピュータシステム上に分散され、分散された状態で格納されても実行されてもよい。ソフトウェアおよびデータは、１つ以上のコンピュータで読み取り可能な記録媒体に格納されてよい。

【0067】

実施形態に係る方法は、多様なコンピュータ手段によって実行可能なプログラム命令の形態で実現されてコンピュータで読み取り可能な媒体に記録されてよい。このとき、媒体は、コンピュータによって実行可能なプログラムを継続格納してもよいし、実行またはダウンロードのために一時格納してもよい。また、媒体は、単一または複数のハードウェアが結合した状態の多様な記録手段または格納手段であってよいが、あるコンピュータシステムに直接接続する媒体に限定されるのではなく、ネットワーク上に分散存在するものであってもよい。媒体の例としては、ハードディスク、フロッピー（登録商標）ディスク、および磁気テープのような磁気媒体、ＣＤ−ＲＯＭ、ＤＶＤのような光媒体、フロプティカルディスク（ｆｌｏｐｔｉｃａｌ ｄｉｓｋ）のような光磁気媒体、およびＲＯＭ、ＲＡＭ、フラッシュメモリなどを含んでプログラム命令が格納されるように構成されたものであってよい。また、他の媒体の例として、アプリケーションを配布するアプリケーションストアやその他の多様なソフトウェアを供給または配布するサイト、サーバなどで管理する記録媒体または格納媒体が挙げられる。

【0068】

以上のように、実施形態を、限定された実施形態と図面に基づいて説明したが、当業者であれば、上述した記載から多様な修正および変形が可能であろう。例えば、説明された技術が、説明された方法とは異なる順序で実行されたり、かつ／あるいは、説明されたシステム、構造、装置、回路などの構成要素が、説明された方法とは異なる形態で結合されたりまたは組み合わされたり、他の構成要素または均等物によって対置されたり置換されたとしても、適切な結果を達成することができる。

【0069】

したがって、異なる実施形態であっても、特許請求の範囲と均等なものであれば、添付される特許請求の範囲に属する。

【符号の説明】

【0070】

３１０：バッファ確認部
３２０：送信速度制御部

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】