JP2018517341A - 改善されたモバイルインターネットの速度およびセキュリティのためのシステム - Google Patents

改善されたモバイルインターネットの速度およびセキュリティのためのシステム Download PDF

Info

Publication number
JP2018517341A
JP2018517341A JP2017555684A JP2017555684A JP2018517341A JP 2018517341 A JP2018517341 A JP 2018517341A JP 2017555684 A JP2017555684 A JP 2017555684A JP 2017555684 A JP2017555684 A JP 2017555684A JP 2018517341 A JP2018517341 A JP 2018517341A
Authority
JP
Japan
Prior art keywords
channel
channels
block
mobile device
cellular
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
JP2017555684A
Other languages
English (en)
Other versions
JP2018517341A5 (ja
JP7109044B2 (ja
Inventor
トーアイ アン レ,ミン
トーアイ アン レ,ミン
Original Assignee
シューレース ワイヤレス,インコーポレイテッド
シューレース ワイヤレス,インコーポレイテッド
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by シューレース ワイヤレス,インコーポレイテッド, シューレース ワイヤレス,インコーポレイテッド filed Critical シューレース ワイヤレス,インコーポレイテッド
Publication of JP2018517341A publication Critical patent/JP2018517341A/ja
Publication of JP2018517341A5 publication Critical patent/JP2018517341A5/ja
Application granted granted Critical
Publication of JP7109044B2 publication Critical patent/JP7109044B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W92/00Interfaces specially adapted for wireless communication networks
    • H04W92/02Inter-networking arrangements
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/28Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/46Interconnection of networks
    • H04L12/4641Virtual LANs, VLANs, e.g. virtual private networks [VPN]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/28Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/46Interconnection of networks
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/64Hybrid switching systems
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00Routing or path finding of packets in data switching networks
    • H04L45/22Alternate routing
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00Routing or path finding of packets in data switching networks
    • H04L45/24Multipath
    • H04L45/243Multipath using M+N parallel active paths
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00Network arrangements, protocols or services for addressing or naming
    • H04L61/45Network directories; Name-to-address mapping
    • H04L61/4505Network directories; Name-to-address mapping using standardised directories; using standardised directory access protocols
    • H04L61/4511Network directories; Name-to-address mapping using standardised directories; using standardised directory access protocols using domain name system [DNS]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/02Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
    • H04L63/0227Filtering policies
    • H04L63/0236Filtering by address, protocol, port number or service, e.g. IP-address or URL
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/02Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
    • H04L63/0272Virtual private networks
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/02Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
    • H04L63/0281Proxies
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/12Applying verification of the received information
    • H04L63/123Applying verification of the received information received data contents, e.g. message integrity
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/02Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W12/00Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/02Protecting privacy or anonymity, e.g. protecting personally identifiable information [PII]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W12/00Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/03Protecting confidentiality, e.g. by encryption
    • H04W12/033Protecting confidentiality, e.g. by encryption of the user plane, e.g. user's traffic
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W76/00Connection management
    • H04W76/10Connection setup
    • H04W76/12Setup of transport tunnels
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/08Network architectures or network communication protocols for network security for authentication of entities
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/10Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/10Protocols in which an application is distributed across nodes in the network
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W72/00Local resource management
    • H04W72/04Wireless resource allocation
    • H04W72/044Wireless resource allocation based on the type of the allocated resource

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

複数の無線ネットワークまたはデバイスを効率的に組み合わせるシステムおよび方法は、より高速で、より信頼でき、かつより安全なモバイルインターネットをもたらす。仮想プライベートネットワーク(VPN)サービスアプリケーションは、モバイルデバイスの発信および着信データパケットをルーティングするように動作する。モバイルデバイスは、(i)リモートサーバとモバイルデバイスとの間でのデータパケットの転送のためにVPNサービスアプリケーションを通じてリモートサーバに結合されるか、または(ii)モバイルデバイスとインターネット上の直接のターゲットホストとの間でのデータパケットの転送のために相互レイヤ変換を実行するかのいずれかである。複数のチャネルを同時に使用することは、複数のチャネルを通じて暗号化データパケットを送信し、単一の装置により暗号化データパケットを受信することによってデータパケット転送を保護する。データパケットは、Wi−Fiチャネルまたはセルラチャネル介して転送されるよう指定され、次いで、Wi−Fiチャネルおよびセルラチャネルの両方を使用して転送される。
【選択図】図1A

Description

関連出願
本出願は、米国特許出願であり、参照によってそれらの全体が本明細書に組み込まれる、2015年4月20日に出願された米国仮特許出願第62/150,250号および2015年7月24日に出願された米国仮特許出願第62/196,583号の利益を主張する。
本発明は、モバイルインターネットを改善し、特に、複数の無線ネットワークを組み合わせてモバイルインターネットの速度を増大させ、モバイルインターネットトラフィックを保護するシステムおよび方法に関する。
スマートフォンおよびタブレットなどのモバイルデバイスが至る所に存在するようになってきた。最近の統計によると、人々は既に従来のデスクトップコンピュータよりも自身のモバイルアプリケーションを使用してインターネット上でより多くの時間を費やしている。それらのモバイルデバイスがWi−Fiおよび3G/4G接続などの無線ネットワークを使用してインターネットに接続するので、それらは、既にはるかに遅れをとっている無線インフラストラクチャに対して無類の制約を生じさせてきた。ユーザは、コーヒーショップ、空港、列車、または会議においてなどの多くの場所で低いモバイルインターネットを経験する傾向がある。現在の無線ネットワークの速度は、需要についていけない。最近の統計によると、米国における平均的なWi−Fiおよびセルラ速度は、4.8および3.7メガビット/秒をそれぞれ下回る。この速度は、今では消費者のスマートフォンが高解像度のスクリーンを備えているため、消費者が望むフルHDの1080画素またはクアッドHDのビデオはもちろんのこと、720画素のビデオをストリーミングするのにも十分でない。さらに、セルラ無線帯域幅の需要と供給とのギャップは今後増加するだけである。例えば、世界の人口の70%がスマートフォンを有し、全てのモバイルデータトラフィックの60%が2020年までにオンラインビデオからであることが予測される。CiscoのVisual Networking Indexによる最新のモバイルデータ予測によると、2019年までには、モバイルの速度が2倍に増加する一方、モバイルデータに対する需要が10倍に増加することが推定される。
不十分な帯域幅は、低解像度のコンテンツ、ビデオが失速することなどが引き起こす不良なユーザ経験をもたらす。このことは、次いで、ユーザの関与が少なくなることに起因して何十億もの歳入の損失に変わる。例えば、Convivaは、不良な品質のビデオストリーミングに起因して、2012年には世界的なプレミアコンテンツブランドが21億6千万ドルの歳入を損失し、ビデオストリーミング品質の問題を改善しない場合、2017年のうちに、驚異的なことに、200億ドルを損失するとの予測を報告している。速度およびコストの両方の目的で帯域幅集中型アプリケーションのためにモバイルユーザによって、またそれらのトラフィックをオフロードするためにセルラオペレータによってWi−Fiがますます使用されている。しかしながら、Wi−Fi単独では、その範囲がセルラと同じくらい偏在してはいないので十分でなく、公共空間におけるほとんどのWi−Fiネットワークは一般的には混み合っている。よって、遅いモバイルインターネットの速度の問題を解決する必要性が存在する。
本明細書で説明される任意の特徴または特徴の組み合わせは、コンテキスト、本明細書、および当業者のうちの1人の知識から明らかなように任意のそのような組み合わせに含まれる特徴が相互に一致する限り、本発明の範囲内に含まれる。本発明の追加の利点および態様は、以下の詳細な説明および特許請求の範囲において明らかである。
主題の開示は、より高速なモバイルインターネットのために複数の無線ネットワークまたはデバイスを効率的に組み合わせ、ネットワークの信頼性を増加させ、インターネットのセキュリティおよびプライバシー保護を強化し、データ消費およびネットワーク性能についてのマルチネットワークの見識を提供し、サービスのクラスに基づく経験の品質を提供するシステムおよび方法を特徴とする。
本発明の実施形態は、モバイルデバイスの発信および着信データパケットをルーティングするように仮想プライベートネットワーク(VPN)サービスアプリケーションを動作させることと、リモートサーバとモバイルデバイスとの間でのデータパケットの転送のためにVPNサービスアプリケーションを通じてモバイルデバイスをリモートサーバに結合することと、を備えるモバイルインターネットの速度を増大させる方法を特徴とする。本発明の別の実施形態は、増大したモバイルインターネットの速度を有するモバイルデバイスを特徴とする。モバイルデバイスは、モバイルデバイスの発信および着信データパケットをルーティングするようにモバイルデバイスのバックグランドで動作する仮想プライベートネットワーク(VPN)サービスアプリケーション、ならびにモバイルデバイスとリモートサーバとの間でのデータパケットの転送のためにサービスアプリケーションによって確立された仮想ネットワークインタフェースを含んでもよい。
本発明のさらなる実施形態は、モバイルデバイスのインターネットの速度を増大させる仮想プライベートネットワーク(VPN)サーバを特徴とする。VPNサーバは、モバイルデバイスとVPNサーバとの間でのデータパケットの転送のための複数のネットワークソケット、および複数のネットワークソケットに結合され、モバイルデバイスによって送信されたデータパケットを送信ターゲットホストに転送し、モバイルデバイスによって要求されたデータパケットを取り出しターゲットホストから取り出すことが可能なデータパケット転送コンポーネントを含んでもよい。
また、複数のチャネルを通じて暗号化データパケットを同時に送信することと、単一の装置によって暗号化データパケットを受信することと、を含むデータパケットの転送を保護するために複数のチャネルを同時に使用する方法が本明細書で説明される。
追加の実施形態は、モバイルデバイスとリモートサーバとの間でのデータパケットの転送のための方法を含む。方法は、Wi−Fiチャネルを介して第1の複数のデータパケットが転送されるように指定することと、セルラチャネルを介して第2の複数のデータパケットが転送されるように指定することと、Wi−Fiチャネルおよびセルラチャネルの両方を使用して第1の複数のデータパケットおよび第2の複数のデータパケットを同時に転送することと、を備えてもよい。
リモートVPNサーバの支援によって複数の無線チャネルを同時に使用してモバイルデバイス上の全てのトラフィックを増大させおよび保護するシステムを特徴とする本発明の例示的な実施形態を示す。 リモートVPNサーバの支援によって複数の無線チャネルを同時に使用してモバイルデバイス上の全てのトラフィックを増大させおよび保護するシステムを特徴とする本発明の例示的な実施形態を示す。 リモートVPNサーバの支援によって複数の無線チャネルを同時に使用してモバイルデバイス上の全てのトラフィックを増大させおよび保護するシステムを特徴とする本発明の例示的な実施形態を示す。 リモートVPNサーバの支援によって複数の無線チャネルを同時に使用してモバイルデバイス上の全てのトラフィックを増大させおよび保護するシステムを特徴とする本発明の例示的な実施形態を示す。 リモートVPNサーバの支援によって複数の無線チャネルを同時に使用してモバイルデバイス上の全てのトラフィックを増大させおよび保護するシステムを特徴とする本発明の例示的な実施形態を示す。 複数の無線チャネルを同時に使用してモバイルデバイス上の全てのトラフィックを保護する方法を特徴とする本発明の例示的な実施形態を示す。 A〜E。同一のリモートサーバと通信するためにモバイルデバイス上でWi−Fiおよびセルラを同時に使用する方法を特徴とする本発明の例示的な実施形態を示す。 リモートVPNサーバの支援なしに2つの無線チャネルを同時に使用してモバイルデバイス上の全てのトラフィックをルーティングしおよび増大させるシステムを特徴とする本発明の例示的な実施形態を示す。 リモートVPNサーバの支援なしに2つの無線チャネルを同時に使用してモバイルデバイス上の全てのトラフィックをルーティングしおよび増大させるシステムを特徴とする本発明の例示的な実施形態を示す。 リモートVPNサーバの支援なしに2つの無線チャネルを同時に使用してモバイルデバイス上の全てのトラフィックをルーティングしおよび増大させるシステムを特徴とする本発明の例示的な実施形態を示す。 複数のUDPまたはTCP接続のために複数のユーザデータグラムプロトコル(UDP)または伝送制御プロトコル(TCP)接続を使用して異なるターゲットホストと通信するためにモバイルデバイス上でWi−Fiおよびセルラを同時に使用するシステムを特徴とする本発明の例示的な実施形態を示す。 単一のUDPまたはTCP接続のために複数のUDPまたはTCP接続を使用して単一のターゲットホストと通信するためにモバイルデバイス上でWi−Fiおよびセルラを同時に使用するシステムを特徴とする本発明の例示的な実施形態を示す。 複数のUDPまたはTCP接続のために複数のユーザデータグラムプロトコル(UDP)または伝送制御プロトコル(TCP)接続を使用して異なるターゲットホストと通信するためにモバイルデバイス上でWi−Fiおよびセルラを同時に使用するシステムを特徴とする本発明の例示的な実施形態を示す。 複数のUDPまたはTCP接続のために複数のユーザデータグラムプロトコル(UDP)または伝送制御プロトコル(TCP)接続を使用して異なるターゲットホストと通信するためにモバイルデバイス上でWi−Fiおよびセルラを同時に使用するシステムを特徴とする本発明の例示的な実施形態を示す。 単一のUDPまたはTCP接続のために複数のUDPまたはTCP接続を使用して単一のターゲットホストと通信するためにモバイルデバイス上でWi−Fiおよびセルラを同時に使用するシステムを特徴とする本発明の例示的な実施形態を示す。 複数のUDPまたはTCP接続のために複数のユーザデータグラムプロトコル(UDP)または伝送制御プロトコル(TCP)接続を使用して異なるターゲットホストと通信するためにモバイルデバイス上でWi−Fiおよびセルラを同時に使用するシステムを特徴とする本発明の例示的な実施形態を示す。 ダウンロードのためのソロモード(Solo Mode)の例示的な実施形態を示す。単一のデバイスは、2つの異なるCDNサーバに接続することによって、2つの異なるネットワークインタフェース、セルラおよびWiFiを通じて異なるビデオブロック(すなわち、ビデオセグメント)をダウンロードする。 2つのCDNサーバを単一のサーバと、(i)このサーバが図7bに示される2つのアドレス指定可能なIPアドレスを有し、または(ii)クライアントが送信元IP−それが有するインタフェースの各々のIPアドレスに基づいてパケットをルーティングすることができる、すなわち、図7cに示される送信元に基づくルーティングもしくはポリシに基づくルーティングの場合に、交換することができる例示的な実施形態を示す。図7bでは、クライアントが2つの異なるIPアドレスに接続する限り、IP1およびIP2が交換可能であることに留意されたい。 アップロードのためのソロモードの例示的な実施形態を示す。単一のデバイスは、WiFiおよびセルラ無線接続を通じて異なるビデオブロックを2つの異なるCDNサーバ、サーバ1およびサーバ2に送信することによってビデオをアップロードする。サーバ2は、それが受信するビデオブロックをサーバ1に送信し、サーバ1は元のビデオを再構築する。ユーザは、WiFiおよびセルラ接続の合計速度でアップロードを経験する。 2つのサーバを単一のサーバと、(i)このサーバが図8bに示される2つのアドレス指定可能なIPアドレスを有し、または(ii)クライアントが送信元IPおよびそれが有するインタフェースの各々のIPアドレスに基づいてパケットをルーティングすることができる、すなわち、図8cに示される送信元に基づくルーティングもしくはポリシに基づくルーティングの場合に、交換することができる例示的な実施形態を示す。図8bでは、各クライアントが2つの異なるIPアドレスに接続する限り、IP1およびIP2が交換可能であることに留意されたい。 BMVアーキテクチャ、およびソロモードにおけるプログレッシブビデオダウンローディング(Progressive Video Downloading)のときのビデオプレイヤとの可能な対話の実施形態を示す。BMVモジュール式アーキテクチャは、以下のメインコンポーネント:ダウンロードモジュール、統計エンジン、記憶システム、キャッシュシステムおよびhttpプロキシサーバから構成される。プログレッシブダウンローディングでは、外部ビデオプレイヤがビデオを要求し、ダウンロードモジュールによってダウンロードされたブロックがキャッシュに記憶され、それらはHTTPプロキシサーバを通じて外部ビデオプレイヤに供給される。 BMVアーキテクチャ、およびソロモードにおけるレギュラービデオダウンローディング(Regular Video Downloading)に使用されるときのビデオプレイヤとの可能な対話の実施形態を示す。レギュラーダウンローディングでは、ダウンロードされたビデオブロックが記憶システムに記憶され、要求したソフトウェア(ビデオダウンローダ)に利用可能となる。 BMVアーキテクチャ、およびプログレッシブHLSダウンローディング、ソロモードにおけるライブストリーミングのときのビデオプレイヤとのその潜在的な対話を示す。ライブストリーミング(HLSファイル)では、ダウンロードモジュールコンポーネント内部のHTTPライブストリーミングエンジンがアクティブになる。 BMVアーキテクチャ、およびレギュラーHLSダウンローディング、ソロモードのためのビデオダウンローダとのその可能な対話を示し、HLSファイルは記憶システムにダウンロードされる。 プロトコルスタックの異なるレイヤにおける該当の技術の可能な実装および対応する利点を示す。1つ目に、Android app VideoBeeで行ったのと同様に、エンドユーザがより高速なダウンロードを楽しむために直接使用することができるスタンドアロンのモバイルアプリケーションを開発することができる。2つ目に、それらのユーザへのビデオ配信を加速化するためにそれらのモバイルアプリケーション内部でコンテンツプロバイダによって使用することができるSDKを提供することができる。最後に、ユーザおよび他のアプリケーションに対して透過的な、オペレーティングシステムレベルにおけるサービスとして該当の技術を実装することができる。デバイスの製造者またはモバイルオペレーティングシステムの所有者は、それらのクライアントに競争力のある性能を提供するためにこの技術をそれらの製品に組み込むことができる。 ソロモードおよびグループモードの両方についての該当の室内実験におけるVideoBeeの性能の例をプロットする。この例について、以下の実験的なセットアップを使用しており、グループの2つのスマートフォン、(1)Galaxy Nexusバージョン4G、および(2)AT&T 3GのSamsung Captivateに接続する。WiFi接続については、無線AP 802.11ルータに接続する。全てのシナリオで同一の電話の配置を使用して同一の3分のYouTubeのビデオを5回ダウンロードし、平均的なダウンロードの速度を報告する。ソロモードでは、1回目にセルラ接続のみを使用し、2回目にWiFi接続のみを使用し、3回目に該当の技術による両方の接続を使用して(デュアルとして報告される)ビデオをダウンロードする。該当の技術によって、WiFiおよびセルラ接続の合計速度を達成することが可能になることを検証する。グループモードでは、スマートフォン(セルラ1およびセルラ2として報告される)の各々を単独で最初に使用してダウンロードしており、次いで、それらをグループで接続し、それらの接続を集約する。グループモードでは、2つのセルラ接続の合計でダウンロードしたことを検証する。 ユーザの統計から収集したデータから処理することによってそのままのVideoBeeの性能の例をプロットする。ソロモードにおけるプログレッシブビデオダウンローディングを考える。WiFiのみを使用することに対し、VideoBeeでの両方のインタフェースを使用するときに達成することができる速度比のヒストグラムをプロットし、これは、WiFiを単独で使用することに対して達成する改善をとらえる。 そのままのVideoBeeのソロモードのプログレッシブビデオダウンローディングの性能の例をプロットし、ここで、セルラ接続がWiFi接続に寄与するメガビット/秒におけるレートのヒストグラムを描く。 VideoBeeアプリケーションのスクリーンショットを示す。
図1に示されるように、本発明は、モバイルインターネットトラフィックの速度を増加させるシステムである。システムは、複数のデータチャネルを通じて相互に通信することが可能な少なくとも1つのモバイルデバイス(102)およびリモートサーバ(200)を備え、チャネルは、異なるタイプのチャネル(例えば、Wi−Fi(115)、セルラ(116)、およびBluetooth(117))である。本発明の主要な実施形態では、モバイルデバイス(102)は、仮想プライベートネットワーク(VPN)サービスアプリケーション(103)を動作させるように構成され、サービスアプリケーションは、仮想ネットワークインタフェース(108)を確立する。モバイルデバイス(102)のオペレーティングシステムは、発信パケットの(107)のセットをこのインタフェースにルーティングし、着信パケット(106)のセットをこのインタフェースから受信するように構成され、仮想ネットワークインタフェース(108)は、VPNサービスアプリケーション(103)に結合されたネットワークソケットを使用して発信データパケットをリモートサーバ(200)に送信する。典型的な実施形態では、VPNサービスアプリケーション(103)は、発信パケット(107)のセットを仮想ネットワークインタフェース(108)から読み出し、各発信パケット(107)を複数のチャネルのうちの1つに割り当て、割り当てられたチャネル(115、116、117)を介して発信パケットのセットをリモートサーバ(200)に送信する。サービスアプリケーション(109)はまた、着信データパケットのセットをリモートサーバ(200)から受信し、着信パケットは、複数のチャネルを通じて受信され、着信パケットを仮想ネットワークインタフェース(108)に書き込む。
主要な実施形態では、リモートサーバ(200)は、インターネット上で複数のターゲットホスト(300)と通信する。リモートサーバ(200)は、複数のチャネルを介して発信パケットのセットをモバイルデバイス(102)から受信し、発信パケットのセットをターゲットホスト(300)に転送し、着信パケット(207)のセットをターゲットホスト(300)から受信し、各着信パケット(207)を複数のチャネルのうちの1つに割り当て、割り当てられたチャネル(115、116、117)を介して着信パケットのセットをモバイルデバイス(102)に送信する。
好ましい実施形態では、サービスアプリケーションは、増大ポリシ(boosting policy)(119)に従ってパケットをチャネルに割り当てる。いくつかの実施形態では、増大ポリシ(119)は、パケットを生成するアプリケーション、各チャネルのスループットおよび遅延などの複数のチャネルの各々のチャネル状態、ならびに複数のチャネルの各々のチャネルタイプに少なくとも基づいてアルゴリズムによって定義される。
種々の実施形態では、チャネルタイプは、デバイスツーデバイス接続、Wi−Fi、マイクロセル、ピコセル、および標準的なセルラ基地局チャネル(117)を含んでもよい。
いくつかの実施形態では、増大ポリシ(119)は、構成可能なオプションのセットを含んでもよい。オプションは、コストを最小化し、伝送の速度を最適化し、または選択されたパケットタイプを優先付けるように増大ポリシ(119)を構成してもよい。
いくつかの実施形態では、増大ポリシ(119)は、各チャネルの発信キューサイズ、各チャネルのデータ転送レート、および/または各チャネルの遅延に基づいて、複数のチャネルを通じて送信されることになるデータパケットを選択する。
いくつかの実施形態では、リモートサーバ(200)はまた、増大ポリシ(208)を動作させるように構成され、増大ポリシ(208)は、発信パケットを優先付け、どのパケットをどのチャネルに割り当てるかを決定する。いくつかの実施形態では、増大ポリシ(208)は、パケットを生成するアプリケーション、各チャネルのスループットおよび遅延などの複数のチャネルの各々のチャネル状態、ならびに複数のチャネルの各々のチャネルタイプに少なくとも基づいてアルゴリズムによって定義される。
いくつかの実施形態では、リモートサーバ(200)は、VPNサーバ(201)であり、VPNサービスアプリケーション(103)は、モバイルデバイス(102)のバックグランドで動作する。いくつかの実施形態では、データパケットは、オープンシステムインターコネクション(OSI)レイヤ3インターネットプロトコル(IP)データグラムまたはOSIレイヤ2イーサネットフレームであってもよい。いくつかの実施形態では、仮想ネットワークインタフェースは、TUNまたはTAPインタフェース(108)のいずれかである。仮想ネットワークインタフェース(108)は、リモートサーバ(200)またはデータパケットをリモートサーバ(200)に転送するプロキシサーバ(211)として、宛先を有するデータパケットを除く発信データパケットを遮断するように構成されてもよい。いくつかの実施形態では、ネットワークソケット(105)は、レイヤ4ユーザデータグラムプロトコル(UDP)ソケット、レイヤ4伝送制御プロトコル(TCP)ソケット、またはレイヤ3ロー(raw)ソケットを含んでもよい。いくつかの実施形態では、データパケットを送出するネットワークソケット(105)は、Wi−Fi(115)またはセルラ(116)物理インタフェースなどの実物理インタフェースにバインド(bind)するように構成されてもよい。可変的な実施形態では、複数のチャネルは、少なくともWi−Fiチャネル(115)およびセルラチャネル(116)、少なくとも2つのセルラチャネル、少なくともセルラチャネル(116)およびローカルデバイスツーデバイスチャネル、または少なくともWi−Fiチャネル(115)およびローカルデバイスツーデバイスチャネル(117)を含む。ローカルデバイスツーデバイスチャネルは、Bluetoothチャネル、Wi−Fi直接チャネル、ロングタームエボリューション(LTE)直接チャネル、またはZigBeeチャネルであってもよい。
また、図1を参照して、本発明の実施形態は、増大したモバイルインターネットの速度を有するモバイルデバイス(102)を特徴とする。モバイルデバイス(102)は、モバイルデバイス(102)の発信および着信データパケットをルーティングするようにモバイルデバイス(102)のバックグランドで動作する仮想プライベートネットワーク(VPN)サービスアプリケーション(103)、ならびにモバイルデバイス(102)とリモートサーバ(200)との間でのデータパケットの転送のためにサービアプリケーションによって確立された仮想ネットワークインタフェースを含んでもよい。サービスアプリケーションは、発信データパケットを処理し、ネットワークソケット(105)を使用して処理されたデータパケットを送出してもよい。処理されたデータパケットは、複数のチャネル(115、116、117)を通じて同時に送信され、データパケットは、受信された後に組み立てられる(assembled)。
別の実施形態では、データパケットは、暗号化スキームを使用して暗号化され(110)、または符号化スキームを使用して符号化され(111)、次いで、増大ポリシ(119)に基づいて複数のチャネルを通じて送信される。データパケットは、各チャネルの発信キューサイズ、各チャネルのデータ転送レート、および各チャネルの遅延のうちの少なくとも1つに基づいて、複数のチャネルを通じて送信されてもよい。複数のチャネルを通じて送信されるデータパケットは、データパケットが送信される前に暗号化される場合に解読されてもよい(110)。また、データパケットは、データパケットが送信される前に符号化される場合に復号される。
図1を参照して、本発明の実施形態は、モバイルデバイス(102)のインターネットの速度を増大させる仮想プライベートネットワーク(VPN)サーバ(201)を特徴とする。VPNサーバは、モバイルデバイス(102)とVPNサーバ(201)との間でのデータパケットの転送のための複数のネットワークソケット、および複数のネットワークソケット(105)に結合され、モバイルデバイス(102)によって送信されたデータパケットを送信ターゲットホスト(300)に転送し、モバイルデバイス(102)によって要求されたデータパケットを取り出しターゲットホスト(300)から取り出すことが可能なデータパケット転送コンポーネントを含んでもよい。データパケットは、複数のチャネルを通じて同時に転送されてもよく、データパケットは、受信された後に組み立てられる。1つの実施形態では、データパケットは、増大ポリシ(119)に基づいて複数のチャネルを通じて送信される。別の実施形態では、データパケットは、暗号化スキームを使用して暗号化され、または符号化スキームを使用して符号化され、次いで、増大ポリシに基づいて複数のチャネルを通じて送信される。増大ポリシ(119)は、モバイルデバイス(102)のユーザまたはモバイルデバイス(102)のサービスキャリアによって構成可能であってもよい。増大ポリシ(119)は、パケットを生成するアプリケーション、複数のチャネルの各々のチャネル状態、および複数のチャネルの各々のチャネルタイプに少なくとも基づいてアルゴリズムによって定義されてもよく、チャネル状態は、各チャネルのスループットおよび遅延を含み、チャネルタイプは、デバイスツーデバイス接続、Wi−Fi、マイクロセル、ピコセル、および標準的なセルラ基地局を含む。
1つの実施形態では、複数のネットワークソケットのうちの少なくとも2つは、データパケットをモバイルデバイス(102)から受信するために同時に使用される。別の実施形態では、複数のネットワークソケットのうちの少なくとも2つは、データパケットをモバイルデバイス(102)に送信するために同時に使用される。他の実施形態では、仮想ネットワークインタフェース(204)は、ネットワーク接続経路を介して送信ターゲットホスト(300)または取り出しターゲットホスト(300)に結合してもよい。ネットワーク接続経路は、データグラムパケット内のネットワークアドレス情報を再マッピングまたは修正するネットワークアドレス変換(NAT)(214)をサポートすることができる。
図1A〜Bに示されるように、リモートVPNサーバ(201)の支援による複数の無線チャネルの同時使用は、モバイルデバイス(102)上の全てのトラフィックを増大させ、および保護することができる。要するに、この非限定的な実施形態は、システムをどのように作動させるかである。任意のインターネットトラフィック、すなわち、アプリケーションによって生成されたデータパケット(IPデータグラムまたはイーサネットフレーム)は、オペレーティングシステムによって仮想ネットワークインタフェース(204)(TUNまたはTAPインタフェース)にルーティングされる。次いで、仮想ネットワークインタフェースから読み出すために利用可能なデータパケットは、複数の無線チャネルを通じて同時に送信され、チャネルは、Wi−Fi(115)、セルラ(116)、または隣接デバイスを通じた間接(117)チャネル(例えば、隣接デバイスへのBluetooth接続によって確立され、隣接デバイスは、パケットのさらなる転送をサポートする)であってもよい。チャネルが遮断されたデータパケットを送出するために使用されるソケットは、TCP、UDP、またはRAWソケットであってもよい。それらのソケットは、対応する物理ネットワークインタフェース(例えば、Wi−Fi、セルラ)をバインドするか、または単なる通常のソケットであるが、仮想ネットワークインタフェースの構成で実行されたIPアドレスに接続する(それらの実行されたIPアドレスを宛先とする任意のトラフィックが仮想ネットワークインタフェースにルーティングされないが、ターゲットIPアドレスに直接送信されるように)ようにバインドするかのいずれかで構成される。データパケットを送出する前に、モバイルデバイス(102)は、それらを暗号化または符号化してもよい。複数のチャネルを通じたデータパケットの発信は、ユーザが構成可能であり、キャリアが構成可能である増大ポリシに従い、ポリシはまた、チャネル状態、タイプ、および速度などを入力として受ける。サーバは、データパケットを複数のソケットから受信し、それらを組み立て(再順序付け、復号し、解読するなど)、インターネット上でそれらをターゲットホストに転送する。これが行われる1つの方法は、IP転送を可能にし、サーバ上でネットワークアドレス変換(214)との仮想ネットワークインタフェース(204)を確立することによってである。インターネット上で応答データパケットをリモートホストから受信すると、VPNサーバ(204)は、他の方向と同様に、複数のチャネルを同時に使用してそれらをモバイルデバイス(102)に転送する。データパケットをサーバからの複数のソケットから受信すると、モバイルデバイス(102)は、それらを組み立て(再順序付け、復号し、解読するなど)、それらをアプリケーション(109)に転送する。
図1Cでは、本発明をさらに明瞭にするフローチャートが提示され、「1」は、ネットワークソケット(105)を使用してデータパケットをモバイルデバイス(102)からリモートサーバ(200)に送信するものとして指定される。「2」は、データパケットを受信するものとして指定され、それらのデータパケットの送信は、2つの部分に分割される。1つの実施形態では、パケットを送信することは、Wi−Fiチャネルによる「1a」およびセルラチャネル(116)による「1b」である。1つの実施形態では、ネットワークソケットは、スイッチとしての役割を果たし、それは、Wi−Fi(115)およびセルラ(116)チャネルを使用したモバイルデバイス(102)からリモートサーバ(200)へのデータパケットの転送を意味する。
いくつかの実施形態では、「2a」は、データパケットをWi−Fiチャネル(115)から受信するものとして指定され、「2b」は、データパケットをセルラチャネル(116)から受信するものとして指定される。1つの実施形態では、ネットワークソケットは、スイッチとしての役割を果たし、その主な機能は、データパケットを送信および受信するための特定のチャネルを発見することを解決することである。
図1Dを参照すると、本発明は、リモートサーバ(200)とのセルラチャネル(116)通信がない実施形態を強調する。1つの実施形態では、フローチャートのフォーマットは、ネットワークソケットを使用してデータパケットをモバイルデバイス(102)からリモートサーバ(200)に送信するものとして「1」が指定され、データパケットをインターネットホストから受信するものとして「2」が指定され、それらのデータパケットの送信および受信は、2つの部分に分割される。
いくつかの実施形態では、パケットを送信することは、セルラチャネル(116)による「1a」および間接チャネル(117)による「1b」である。同様に、「2a」は、データパケットをセルラチャネルから受信するものとして指定され、「2b」は、データパケットを間接チャネルから受信するものとして指定される。ローカルデバイスツーデバイスチャネル(間接チャネル)は、Bluetoothチャネル、Wi−Fi直接チャネル、LTE直接チャネル、またはZigBeeチャネルであってもよい。
ここで、図1Eを参照すると、本発明は、リモートサーバ(200)とのWi−Fiチャネル通信がない実施形態を強調する。1つの実施形態では、フローチャートのフォーマットは、ネットワークソケットを使用してデータパケットをモバイルデバイス(102)からリモートサーバ(200)に送信するものとして「1」が指定され、受信されたデータパケットとして「2」が指定され、それらのデータパケットの送信は、2つの部分に分割される。
いくつかの実施形態では、パケットを送信することは、Wi−Fiチャネルによる「1a」および間接チャネル(117)による「1b」である。同様に、「2a」は、データパケットをWi−Fiチャネル(115)から受信するものとして指定され、「2b」は、データパケットを間接チャネル(117)から受信するものとして指定される。ローカルデバイスツーデバイスチャネル(間接チャネル)は、Bluetoothチャネル、Wi−Fi直接チャネル、LTE直接チャネル、またはZigBeeチャネルであってもよい。
ここで、図2を参照すると、本発明はさらに、データパケットの転送を保護するために複数のチャネを同時に使用する方法を特徴とすることができる。いくつかの実施形態では、方法は、複数のチャネルを通じて暗号化データパケットを同時に送信することと、単一の装置によって暗号化データパケットを受信することと、を備えてもよい。好ましくは、受信された暗号化データパケットは、組み立てられおよび解読される。いくつかの実施形態では、複数のチャネルは、少なくともWi−Fiチャネルおよびセルラチャネル、少なくとも2つのセルラチャネル、少なくともセルラチャネルおよびローカルデバイスツーデバイスチャネル、または少なくともWi−Fiチャネルおよびローカルデバイスツーデバイスチャネルを含んでもよい。ローカルデバイスツーデバイスチャネルは、Bluetoothチャネル、Wi−Fi直接チャネル、LTE直接チャネル、またはZigBeeチャネルであってもよい。
1つの実施形態では、暗号化データパケットは、セキュアポリシに基づいて複数のチャネルを通じて送信される。別の実施形態では、暗号化データパケットは、符号化スキームを使用して符号化され、次いで、セキュアポリシに基づいて複数のチャネルを通じて送信される。暗号化データパケットは、暗号化データパケットが送信される前に符号化される場合に復号されてもよい。暗号化データパケットは、各チャネルの発信キューサイズ、各チャネルのデータ転送レート、および各チャネルの遅延から選択された要因に少なくとも基づいて送信されてもよい。
いくつかの実施形態では、セキュアポリシは、暗号化パケットを生成するアプリケーションおよび複数のチャネルの各々のチャネル状態から選択された要因に少なくとも基づいてアルゴリズムによって定義されてもよい。他の実施形態では、チャネル状態は、各チャネルのスループットおよび遅延、複数のチャネルの各々のチャネルタイプから選択されたチャネルパラメータを含んでもよい。さらなる実施形態では、複数のチャネルの各々のチャネルタイプは、デバイスツーデバイス接続、Wi−Fi、マイクロセル、ピコセル、または標準的なセルラ基地局接続である。
図2に示されるように、複数の無線チャネルの同時使用は、モバイルデバイス(102)上の全てのトラフィックを保護することができる。モバイルデバイス(102)上の仮想ネットワークインタフェースにルーティングされるデータパケット(IPデータグラムまたはイーサネットフレーム)を考える。それらのデータパケットは、暗号化および符号化され、次いで、セキュアポリシに基づいて複数のチャネルを同時に使用してリモートサーバ(200)に送信される。このセキュアポリシは、データパケットを生成したアプリケーションならびにチャネル状態、タイプ、および速度などを入力として受ける。暗号化データパケットをモバイルデバイス(102)から受信すると、リモートサーバ(200)は、それらを組み立てて(再順序付け、復号し、解読するなど)データパケットを取得する。モバイルデバイス(102)に再度送信される必要があるデータパケット(ターゲットホストからの応答)は、同様に、複数のチャネルを通じて同時に安全に送信されてもよい。
図3に示されるように、本発明の追加の実施形態は、モバイルデバイス(102)とリモートサーバ(200)との間でのデータパケットの転送のための方法を特徴とすることができる。方法は、Wi−Fiチャネルを介して第1の複数のデータパケットが転送されるように指定することと、セルラチャネルを介して第2の複数のデータパケットが転送されるように指定することと、Wi−Fiチャネルおよびセルラチャネルの両方を使用して第1の複数のデータパケットおよび第2の複数のデータパケットを同時に転送することと、を備えてもよい。1つの実施形態では、リモートサーバ(200)は、第1の複数のデータパケットを転送するための第1のインターネットプロトコル(IP)アドレスおよび第2の複数のデータパケットを転送するための第2のIPアドレスを有するように構成されてもよく、第2のIPアドレスは、第1のIPアドレスとは別個である。別の実施形態では、リモートサーバ(200)は、第1の複数のデータパケットを転送するための単一のIPアドレスを有するように構成されてもよく、第2の複数のデータパケットは、単一のIPアドレスとは異なるIPアドレスでプロキシサーバ(211)を介してリモートサーバ(200)とモバイルデバイス(102)との間で転送される。さらなる別の実施形態では、リモートサーバ(200)は、第2の複数のデータパケットを転送するための単一のIPアドレスを有するように構成されてもよく、第1の複数のデータパケットは、単一のIPアドレスとは異なるIPアドレスでプロキシサーバ(211)を介してリモートサーバ(200)とモバイルデバイス(102)との間で転送される。
いくつかの実施形態では、Wi−Fiチャネルを介して転送されることになる第1の複数のデータパケットは、Wi−Fiチャネル接続がモバイルデバイス(102)上で有効にされた後にデフォルトの構成またはアプリケーションプログラミングインタフェース(API)の構成でモバイルデバイス(102)上で指定され、セルラチャネルを介して転送されることになる第2の複数のデータパケットは、セルラチャネル接続がモバイルデバイス(102)上で有効にされた後にデフォルトの構成またはアプリケーションプログラミングインタフェース(API)の構成でモバイルデバイス(102)上で指定される。
他の実施形態では、Wi−Fiチャネルを介して転送されることになる第1の複数のデータパケットは、Wi−Fiチャネルがモバイルデバイス(102)上で有効にされた後、次いで、第1の複数のデータパケットを送信するためにそれらのソケットを使用して、既にWi−Fiチャネルにバインドされたソケットを選択することによって、またはモバイルデバイス(102)上の選択されたネットワークソケットをWi−Fiチャネルにバインドすることによって指定され、セルラチャネルを介して転送されることになる第2の複数のデータパケットは、セルラチャネルがモバイルデバイス(102)上で有効にされた後、次いで、第2の複数のデータパケットを送信するためにそれらのソケットを使用して、既にセルラチャネルにバインドされたソケットを選択することによって、またはモバイルデバイス(102)上の選択されたネットワークソケットをセルラチャネルにバインドすることによって指定される。
図3に示されるように、Wi−Fiチャネル(115)およびセルラチャネル(116)は、以下の2つのアプローチのクラス、(i)モバイルデバイス(102)がWi−Fi(115)およびセルラ(116)接続のために2つの異なるIPアドレスに接続することであって(図3A、3B、3C)、リモートサーバ(200)に直接接続するか(図3A)またはプロキシサーバ(211)を通じて接続するか(図3B、3C)のいずれかである、ことと、(ii)モバイルデバイス(102)が明確に少なくともソケットを物理インタフェースにバインドすること(図3Dにおけるセルラまたは図3EにおけるWi−Fi)と、に従ういくつかの方法で、同一のリモートサーバ(200)と通信するためにモバイルデバイス(102)上で同時に使用されてもよい。
利用可能なときに(セカンダリチャネルがデータを転送するために使用されないときでさえ)少なくとも2つのチャネルを同時にアクティブに保持することは、複数のネットワークにわたってシームレスな接続性を提供するための重要な技術である。例えば、2つの利用可能なチャネル、WiFiおよびセルラを有し、WiFiが現在プライマリインタフェースであることを仮定する。セルラインタフェースがアクティブに保持されないが、WiFiが切断されるときのみアクティブになり、次いで、OSがセルラインタフェースをアクティブにするために(使用できるまでには)数秒の遅延がある。これは、IPデータグラムまたはイーサネットフレームをモバイルデバイスとVPNサーバとの間で搬送する際に中断を生じさせることがあり、それによって、アプリケーションの現在のTCP/UDPセッションを切断する。
図4Aに示されるように、本発明は、モバイルインターネットトラフィックの速度を増加させるシステムである。システムは、データチャネルをルーティングするユーザデータグラムプロトコル(UDP)/伝送制御プロトコル(TCP)を通じてターゲットホスト(600)と通信することが可能な少なくとも1つのモバイルデバイス(502)を備えてもよく、チャネルは、異なるタイプのチャネルである(例えば、Wi−Fi(524)およびセルラ(525))。本発明の主要な実施形態では、モバイルデバイス(502)は、仮想プライベートネットワーク(VPN)サービスアプリケーション(503)を動作させるように構成され、サービスアプリケーションは、仮想ネットワークインタフェース(505)を確立する。モバイルデバイス(502)のオペレーティングシステムは、発信パケットのセットをこのインタフェースにルーティングし、着信パケットのセットをこのインタフェースから受信するように構成され、仮想ネットワークインタフェース(505)は、VPNサービスアプリケーション(503)に結合されたネットワークソケットを使用して発信データパケットをターゲットホスト(600)に送信する。典型的な実施形態では、VPNサービスアプリケーション(503)は、発信パケットのセットを仮想ネットワークインタフェース(505)から読み出し、各発信パケットをチャネルのルーティングのうちの1つに割り当て、割り当てられたチャネルを介して発信パケットのセットをターゲットホストに送信する。サービスアプリケーションはまた、着信データパケットのセットをホストから受信し、着信パケットは、チャネルのUDP/TCPを通じて受信され、着信パケットを仮想ネットワークインタフェース(505)に書き込む。
いくつかの実施形態では、サービスアプリケーションは、増大ポリシ(514)に従ってパケットをチャネルに割り当てる。いくつかの実施形態では、増大ポリシ(514)は、パケットを生成するアプリケーション、各チャネルのスループットおよび遅延などのルーティング処理の各々のチャネル状態、ならびに転送チャネルの各々のチャネルタイプに少なくとも基づいてアルゴリズムによって定義される。
いくつかの実施形態では、増大ポリシ(514)は、構成可能なオプションのセットを含む。オプションは、コストを最小化し、伝送の速度を最適化し、またはパケットタイプを送信および受信するためのルーティング処理を選択するように増大ポリシ(514)を構成してもよい。
いくつかの実施形態では、増大ポリシ(514)は、各チャネルの発信キューサイズ、各チャネルのデータ転送レート、および/または各チャネルの遅延に基づいて、チャネルの異なるルーティングを通じて送信されることになるデータパケットを選択する。
また、図4Aを参照して、本発明の実施形態は、増大した(514)モバイルインターネットの速度を有するモバイルデバイス(502)を特徴とする。モバイルデバイス(502)は、モバイルデバイス(502)の発信および着信データパケットをルーティングするためにモバイルデバイス(502)のバックグランドで動作する仮想プライベートネットワーク(VPN)サービスアプリケーション(503)、ならびにモバイルデバイス(502)とターゲットホスト(600)との間でのデータパケットの転送のためにサービスアプリケーションによって確立された仮想ネットワークインタフェース(505)を備えてもよい。サービスアプリケーションは、発信データパケットを処理し、ネットワークソケットを使用して処理されたデータパケットを送出してもよい。処理されたデータパケットは、複数のチャネル(524、525)を通じて同時に送信され、データパケットは、受信された後に組み立てられる。
いくつかの実施形態では、データパケットは、ユーザデータグラムプロトコル(UDP)/伝送制御プロトコル(TCP)によって提供されるルーティング処理ならびに増大ポリシ(514)に基づいて複数のチャネル(524、525)を通じて送信される。データパケットは、各チャネルの発信キューサイズ、各チャネルのデータ転送レート、および/または各チャネルの遅延のうちの少なくとも1つに基づいて複数のチャネルを通じて送信されてもよい。
要するに、この非限定的な実施形態は、システムの作動方法である。パケットからのデータは、レイヤ3データグラム(またはレイヤ2フレーム)とレイヤ4パケットとの間で変換を実行することによってそれらのターゲットホストに送信され、それによって、通常のUDP/TCPソケットを使用してデータをインターネットに送出することができる。特に、発信トラフィックについて、IPデータグラム(またはイーサネットフレーム)のデータは、抽出され、UDP/TCPソケットを通じてターゲットホストに直接送信される必要がある。ターゲットホストが応答するとき、その応答データは、UDP/TCPソケットから読み出され、IPデータグラム(およびイーサネットフレーム)で包み込まれる必要があり、それらは次いで、TUN(またはTAP)インタフェースに書き込まれる。
また、この非限定的な実施形態は、システムによる、異なるトラフィックタイプに対するインターネットの速度の増大の達成方法である。増大は、UDPまたはTCPトラフィックのいずれかを加速化するために複数のレイヤ4UDP/TCPソケットを同時に使用することによって達成される。それらのソケットは、Wi−Fiまたはセルラのいずれかの適切なインタフェースにバインドするように構成され、また、仮想ネットワークインタフェース(例えば、保護されたソケット)にループバックしないように構成される。4つの増大の例示的なケース:(1)異なるターゲットホストへの複数のTCP接続:ホストAをターゲットとするTCP接続をTCP Wi−Fiに割り当てることができ、ホストBをターゲットとする別のTCP接続をTCPセルラに割り当てることができる。(2)同一のターゲットホストへの単一のTCP接続:アプリケーションレイヤプロトコルに応じて、単一のTCP接続が複数のTCP接続に分解されることが可能となることがあり、例えば、各接続がHTTP範囲要求においてデータの範囲の部分的な範囲をフェッチする。次いで、それらの接続をWi−Fiおよびセルラに同時に割り当てることができる。元の範囲の部分的な範囲がフェッチされるとき、それらは、パケットデータの順序を保証するために仮想ネットワークインタフェースに送信される前に再組み立てされる。(3)異なるターゲットホストへの複数のUDP接続:ホストAをターゲットとするUDP接続をUDP Wi−Fiに割り当てることができ、ホストBをターゲットとする別のUDP接続をUDPセルラに割り当てることができる。(4)同一のターゲットホストへの単一のUDP接続:アプリケーションレイヤプロトコルに応じて、単一のUDP接続が複数のUDP接続に分解されることが可能となることがあり、例えば、各接続がTCPのためのHTTP範囲要求においてデータの部分などをフェッチする。次いで、それらの接続を上記のようにWi−Fiおよびセルラに同時に割り当てることができる。
図4B〜Cでは、本発明をさらに明瞭にするフローチャートが提示され、「1」は、保護されたソケット(515)を使用してデータパケットをモバイルデバイス(502)からターゲットホスト(600)に送信するものとして指定され、「2」は、データパケットを受信するものとして指定され、それらのデータパケットの送信は、2つの部分に分割される。1つの実施形態では、パケットを送信することは、Wi−Fiチャネル(524)による「1a」およびセルラチャネル(525)による「1b」である。
いくつかの実施形態では、「2a」は、データパケットをWi−Fiチャネル(524)から受信するものとして指定され、「2b」は、データパケットをセルラチャネル(525)から受信するものとして指定される。
ここで、図4Cを参照すると、本発明は、UDP(510)のルーティング処理との通信がない実施形態を強調する。1つの実施形態では、フローチャートにおける「1」は、ネットワークソケットを使用してデータパケットをモバイルデバイス(502)からターゲットホスト(600)に送信するものとして指定され、「2」は、受信されたデータパケットとして指定され、それらのデータパケットの送信は、2つの部分に分割される。1つの実施形態では、パケットを送信することは、Wi−Fiチャネル(524)による1aおよびセルラチャネル(525)による1bである。
図5〜6に示されるように、Wi−Fiチャネル(524)およびセルラチャネル(525)は、以下の2つのアプローチのクラス:(i)モバイルデバイス(502)がWi−Fi(524)およびセルラ(525)接続のために同一のターゲットホスト(600)の2つの異なるターゲットIP(601、602)または2つの異なるターゲットホストに接続すること(図5A、6A、5C、6C)と、(ii)モバイルデバイス(502)がWi−Fi(524)およびセルラ(525)接続のために同一のターゲットホスト(600)の単一のターゲットIPに接続すること(図5B、6B)と、に従ういくつかの方法で、ターゲットホスト(600)と通信するためにモバイルデバイス(502)上で同時に使用されてもよい。
SDKの増大
ソフトウェア専用の解決策を使用して、同一のコンテンツ(例えば、同一のビデオ)をダウンロードまたはアップロードするために同一のデバイスまたはプロキシデバイスのグループのいずれかに属するいくつかのネットワーク接続の帯域幅。以下では、ソフトウェアシステムの1つの実施形態を参照するためにBMV(ブースティングモバイルビデオ(Boosting Mobile Video)を使用する。単一のデバイスのネットワーク接続を集約するケースを説明するためにソロモードに言及する。
ソロモードでは、Androidスマートフォン、タブレット、およびビデオプレイヤなど、複数のネットワークインタフェースを有するデバイスによって該当の技術を使用することができる。例えば、ビデオをダウンロードすることを試みる空港内のユーザは、WiFiおよびセルラ接続を同時に使用することによってビデオをダウンロードするように空港のWiFi接続を自身のセルラ接続に集約するために該当の技術を使用することができる。
この技術の実装方法の例を説明する。図13における分類に示されるプロトコルスタックのいくつかのレイヤにおいて該当のソフトウェアを配置することができる。まず、アプリケーションレイヤでは、Android app VideoBeeで行ったのと同様に、スタンドアロンのモバイルアプリケーションを開発することができる。エンドユーザは、特定のアプリケーションのプレイヤの内部でビデオを見るためにVideoBeeを使用する(ビデオが多くの異なるプロバイダからストリーミングされる場合でさえ)。次に、Netflixモバイルアプリケーションなど、サーバへの複数の経路を使用することによってそれらのモバイル配信を加速化するために他のモバイルアプリケーションによって使用することができるSDKを提供することができる。このケースでは、エンドユーザは、ビデオをいつものように見るためにNetflixモバイルアプリケーションを使用し、該当の技術は、帯域幅を増加させるためにユーザに対して透過的にまたは明確なパーミッションでバックグランドで使用される(例えば、通知および増大ボタンを通じて)。さらに、オペレーティングシステムレベルにおけるサービスとして該当の技術をユーザおよび他のアプリケーションに対して透過的に実装することができる。そのシナリオでは、サービスは、複数の経路を使用することによってデバイスに着信される全てのHTTPトラフィックを増大させることができる。
いくつかの実施形態では、ビデオのストリーミングは、BMVおよびAPIインタフェースを使用する。この実施形態では、ビデオプレイヤ、例えば、Androidシステムの内蔵プレイヤまたはMX−Playerプレイヤなどの第三者ビデオプレイヤは、図9に示されるように、下記のように進行する。それは、例えば、要求されたネットワークを提供するためにsetNetworks(ネットワーク)を呼び出すことによって、ビデオをダウンロードためにどのネットワークインタフェースを使用することを望むかを最初に指定する。次いで、それは、例えば、プログレッシブダウンロード(ビデオurl)と呼ばれる関数を呼び出すことによってダウンロードを開始し、再生することを望むビデオのビデオurl(ユニフォームリソースロケータ)は、例えば、http://remoteserver.com/video.mp4である。BMVは、ビデオパーツ(video parts)をダウンロードし、それらをキャッシュに一時的に記憶し、ローカルHTTPプロキシサーバを通じてそれらを供給することによってそれらをローカルに利用可能にする。いくつかの実施形態では、ダウンロードされたパーツは、ローカルURLである、例えば、http://localhost/video.mp4から利用可能となる。ビデオプレイヤは最後に、例えば、setDataSource(「http://localhost/video.mp4」)と呼ばれる関数を呼び出すことによってビデオデータをこのローカルURLにフェッチするべき位置を設定する必要があり、次いで、このローカルURLから直接再生するためにビデオパーツをフェッチする。ダウンロードが進行中の間は、ビデオプレイヤはまた、異なるネットワークインタフェースからダウンロードされたデータ、ネットワークインタフェースの速度などを含む、BMVシステムからの種々の統計を要求することができる。
ダウンロードモジュールは、ビデオパーツをダウンロードすることを担う主なソフトウェアである。いくつかの実施形態では、それは、URLリゾルバの支援により複数のネットワーク接続を確立し、それらを同時に使用し、それは、スケジューリングアルゴリズムを使用して各々の接続を通じてどのビデオ範囲をダウンロードするかを管理し、それは、キャッシュ(プログレッシブダウンローディング)または記憶システム(レギュラーダウンローディング)のいずれかを使用してダウンロードされたパーツを記憶する。
図9を参照すると、URLリゾルバは、BMVにおいて重要な役割を果たす。今日のAndroidデバイス上では、2つのインタフェースの各々が異なるIPアドレスに接続している限り、セルラインタフェースおよびWiFiインタフェースを同時に利用することができる(デバイスをルート化(root)することなく)。よって、課題は、それらのインタフェースの各々を通じて同一のコンテンツのパーツをなおダウンロードする間にどのようにこれを達成することができるかである。該当の新規の見解は、今日の人気のあるコンテンツが、異なるIPアドレスを有するいくつかのコンテンツ配信ネットワーク(CDN)サーバ(これは、例えば、YouTube、Amazon、NetFlixなどについてのケースである)に記憶されるという事実を利用することによってそれを行うことができることである。よって、例えば、セルラインタフェースおよびWiFiインタフェースを、異なるIPアドレスを有するが同一のコンテンツを供給する2つの異なるCDNサーバに接続することができる。それを行うことができるように、BMVがCDNの異なるサーバのURLアドレスを高速かつ信頼して取得することを可能にする必要がある。これは正確には、URLリゾルバが行うことである。1つの実施形態では、URLリゾルバは、提供されたURL(例えば、http://remote‐server.com/video.mp4)から開始し、異なるIPアドレスに接続する追加のURLを識別する。これを達成するために、使用することができる技術は、次に説明する2つを含むことができ、どの技術を使用できるかは、アクセスしようとするコンテンツホストに依存することがある。
DNSリゾルバ:BMVは、ビデオのホスト名(該当の例では、remote−server.comの)のN個の(Nは無線インタフェースの数)異なるIPアドレスを発見するために明確なドメイン名解決(DNS解決)を実行することができる。次いで、そのたびにホスト名remote−server.comをN個の異なるIPアドレスのうちの1つに置き換えることによってN個の異なるURLアドレスを作成することができる。この技術をDNSリゾルバと呼ぶ。該当の例を続けて、BMVがIPアドレス192.168.1.1および192.168.1.2を発見すると仮定して、次いで、異なるサーバ上の同一のコンテンツにアクセスする2つのURLであるhttp://192.168.1.1/video.mp4およびhttp://192.168.1.2/video.mp4を作成することができる。要求された数のIPアドレスを高速かつ信頼して取得することを保証するために、BMVは、以下を含むクエリを実行する。
−ドメイン名の信頼すべき(Authoritative)DNSサーバへのクエリ。
−ドメイン名の信頼すべきでないDNSサーバへのクエリ、それらのサーバは、ローカルネットワークDNSサーバとともにGoogle DNSサーバ、オープンDNSサーバなどの一般のパブリックDNSサーバを含む。
−ホストの潜在的に記憶された(かつ期限切れでない)IPアドレスを発見するためのそのローカルデータベースへのクエリ。このデータベースは、ローカルに利用可能であり、人気のあるビデオプロバイダ、例えば、Daily motionの特定のセットのために頻繁に更新される。
1つの実施形態では、クエリは、連続して実行され、プログラムは、十分な数のIPアドレスを収集すると停止する。それらのクエリが実行される順序は、アプリケーションおよびユーザの振る舞いに依存することがある。例えば、同一のホストに度々アクセスするユーザには、最も効率的なのは、複数のIPアドレスをローカルに記憶し、それらを最初にチェックすることである。
解決ブラウザ(Resolution Browser):いくつかのホストでは、単純にホスト名をIPアドレスに置き換えることでは有効なURLが得られず、よって、DNSリゾルバ技術は機能しない。これについての理由は、以下を含む。
−1つ目に、ホストは、その特定のURLについて計算する署名をURLの内部に組み込むことができる。署名を更新することなくホスト名を異なるIPアドレスに置き換えることは、無効なURLにつながる。しかしながら、ホストによってのみ署名を計算することができる。例として、署名を含むYouTubeビデオのURLは、http://m.youtube.com/watch?v=videold&signature=AAAの形式である。
−2つ目に、いくつかのケースでは、ホストはまた、ブラウザの送信元IPアドレスをURLに挿入し、ブラウザのIPアドレスを通じて署名を計算し、それによって、異なるIPアドレスを有するクライアントによってURLが使用されることを防止する。例えば、このフォーマットのYouTubeのビデオのURLは、http://m.youtube.com/watch?v=videold&source_ip=1.2.3.4&signature=AAAである。
異なるインタフェースが異なるIPアドレスを有するので、セルラインタフェースを通じてビデオをダウンロードするために、WiFiインタフェースを通じてブラウザによって発見されたURLを使用することはできない。このケースに対処するために、BMVの1つの実施形態は、解決ブラウザと呼ばれる内蔵ウェブブラウザを特徴とする。解決ブラウザは、同一のビデオの異なるURLを直接取得するためにページを複数回見ることが可能である(ビデオサーバは、負荷分散を理由に異なるURLを生成する)。また、それは、異なるネットワークインタフェースを通じてブラウザインスタンスをインスタンス化することができ、よって、そのインタフェースを通じて使用されることになるURLを直接取得する(例えば、それは、セルラインタフェースで使用されることになるURLを直接取得するためにセルラインタフェースを使用してウェブページを見る)。例えば、携帯電話上で稼働し、WiFiを通じてブラウザを使用するBMVは、URL、http://proxy1.remote−server.com/video.mp4?sourcelP=7.7.7.1&sign=AAAAを取得することができ、セルラを通じてブラウザを使用するBMVは、URLである、http://proxy2.remote−server.com/video.mp4?sourcelP=7.7.7.2&sign=BBBBを取得することができ、7.7.7.1は、WiFiのIPアドレスであり、7.7.7.2は、携帯電話のセルラIPアドレスである。BMVはまた、proxy1.remote−server.comおよびproxy2.remote−server.comが2つの異なるIPアドレス(WiFiおよびセルラを同時に使用することが必要な)に対して解決することをチェックすることができる。それらがたまたま同一のIPアドレスに対して解決する場合、BMVは、1つの実施形態では、それが異なるIPアドレスを取得するまでインタフェースのうちの1つを通じて見ることを続ける。
URLリゾルバ障害:リゾルバが全てのインタフェースのURLについてあらかじめ定められた制限時間内に発見することができない場合、1つの実施形態では、BMVは、それが既に有する(BMVが少なくとも1つのURLを有する任意のケースにおいてであることに留意)URLを利用してダウンロードを開始し、それによって、起動時間が影響されない。いくつかのトリガにおいて、例えば、システムが定常状態に到達するとき(後に説明するように、これは、緊急のブロックが必要とされないことを意味する)、または予め定められた時間ウインドウが経過した場合、BMVは、インタフェースを維持するためのURLを取得するためにURLリゾルバ技術を再開することができる。
URLリゾルバが必要とされないとき:クライアントが複数のルーティングテーブルを使用してパケットをルーティングすることができるケースでは、すなわち、送信元に基づくルーティング(異なる送信元IPアドレス、すなわち、異なるネットワークインタフェースのIPアドレスに基づく)、またはポリシに基づくルーティングを使用することによって、図7cおよび8cに示されるように、クライアントが両方のインタフェースを使用して単一のIPに直接接続することができるので、URLリゾルバが必要とされない。このケースでは、URLリゾルバは、各インタフェースを通じて送信されるパケットが適切にサーバにルーティングされることを保証するために、2つのルーティングテーブル(送信元に基づくルーティング)またはルーティングポリシ(ポリシに基づくルーティング)の維持を実行する。
スケジューリングアルゴリズム
該当のスケジューリングアルゴリズムは、1つの実施形態では、コンテンツのどのパーツが各インタフェースを通じてダウンロードされるかを決定し、いくつかの所望の特性を特徴とする。特に、この実施形態では、それは、
−待機および起動時間を最小化する円滑なストリーミングを提供し、
−接続の合計速度に近い速度を達成し、
−チャネル変動および損失の多い接続に対してロバストであり、明確にチャネル統計を記録する必要なく、各インタフェースを通じてコンテンツのどのパーツをダウンロードするかを調節し、
−再生時間に十分に近くない限りコンテンツをダウンロードせず、それによって、ユーザが探索するとき(ユーザが見ようとするビデオのパーツを前または後に変更する)、高速に適合させることができ、
−制限された記憶空間でデバイス上で動作させることができる。
バッファマップは、全てのビデオブロックについての状態を維持する。それは、ビデオブロックの各々が1)ダウンロードされ、および利用可能であるか、2)現在ダウンロード中であるか、または3)消失しているかを記録する。BMVは、ビデオのいくつかのブロックがキャッシュにおいて利用可能であるかをチェックする。そうである場合、それらをダウンロードされたものとしてマーク付けする。全ての残りのビデオブロックが消失しているものとしてマーク付けされる(ケース3)。
ブロックプールは、ダウンロードしようとしているスライドウインドウで、すなわち、再生時間からの時間W内で重複する(部分的にでも)ブロックのサブセットをバッファマップに維持する。これは、ダウンロードのためにスレッドに利用可能なブロックのセットである。最初に、それは、全てのブロックを時間ゼロ(ビデオの開始時間)から時間W内に含む。ブロックプールは、順序付けられたセットであり、再生時間により近いブロックを最初に供給する。
緊急プールは、次のアルゴリズムで説明するように、緊急に必要とされ、2つ以上のスレッドが並列にダウンロードを試みることを可能にするブロックのセットの維持するブロックプールのサブセットである。緊急プールはまた、最初に供給される再生時間により近いブロックを有する順序付けられたセットである。緊急プールは、空であることがあり、この望ましい状態を「定常状態」と呼ぶ。最初に、緊急プールは、ビデオを再生することを開始するために必要な最初のS個のブロックを含み、Sは、指定されたパラメータである。緊急プールのサイズは、セーフティパディング時間と呼び、また、スケジューリングアルゴリズムへの入力として指定されるパラメータΔの関数である。SおよびΔは、BMVまたはユーザによって指定されることがあり、デバイス、コンテンツおよび無線状態の関数であることができる。
1つの実施形態では、クエリが連続して実行され、プログラムは、十分な数のIPアドレスを収集すると停止する。それらのクエリが実行される順序は、アプリケーション、およびユーザの振る舞いに依存することがある。例えば、ユーザが同一のホストに度々アクセスするために、最も効率的なのは、複数のIPアドレスをローカルに記憶し、それらを最初にチェックすることである。
アルゴリズム
入力:パラメータS、Δ、W、T1、T2、T3。初期状態:バッファマップにおける全てのブロックが消失しているとしてタグ付けされる。ブロックプールは、開始時間からのW内である全てのブロックを含む。緊急プールは、開始時間からの最初のS個のブロックを含む。
キャッシュからの取り出し:
−BMVは、キャッシュがブロックのいくつかをバッファマップに既に有しているかをチェックし、そのようなブロックを発見した場合、バッファマップにおいてそれらをダウンロードされたものとしてタグ付けする。
スレッドダウンローディング
−各々のアクティブなスレッドは、緊急プールを最初にチェックし、それが空である場合、次いで、ブロックプールをチェックし、それが空である場合、それはスリープする。緊急プールまたはブロックプールに追加される新たなブロックがある場合、全てのスレッドが通知される(スリープから起動し、再度チェックする)。
−緊急プールが空でない場合、スレッドは、最初のブロックをとり、それをダウンロードすることを試み、それがダウンロードされると、それはブロックをキャッシュシステムに渡し、バッファマップにおいてブロックをダウンロードされたものとしてタグ付けする。BMVは、ブロックを緊急プールから削除する。複数のスレッドがダウンロードする最初の緊急ブロックを同時に選択することができることに留意されたい。同一のブロックをダウンロードすることを試みるスレッドの数を、インタフェースごとに最大で1つに制限する。
−緊急プールが空であるが、ブロックプールが空でない場合、スレッドは、ブロックプールにおいて最初のブロックをとる。スレッドは、バッファマップ上で、ブロックが消失しているか、またはダウンロード中であるかをチェックし、消失している場合、それをダウンロード中であるとしてマーク付けし、それをサーバから要求することを進行させ、それがダウンロード中である場合、ブロックプールに戻り、第2のブロックをチェックする。それが消失しているブロックを発見するまでこの方式で継続する。それがブロックをダウンロードすると、それをキャッシュシステムに渡し、バッファマップにおいてそれをダウンロードされたものとしてマーク付けする。BMVは、それをブロックプールから削除する。
プール更新:T1秒ごとに、BMVは、現在の再生時間をチェックし、再生時間が進行している場合にプール更新を実行する。プール更新の実行は代わりに、BMVによる新たな再生時間の受信(ビデオプレイヤからの)によってトリガされてもよい。プール更新は以下のように行われる:
−緊急プールまたはブロックプールにおけるブロックが現在の再生時間よりも前である場合、それを削除する。同様に、ブロックが再生時間の後のW内でない場合、それも削除する。そのようなケースは、ユーザが再生時間を探索し、前または後に変更するときに発生することがある。
−それは、バッファマップにおいてダウンロードされたものとしてマーク付けされておらず、再生時間からのW内である(部分的にでも)全てのブロックをブロックプールに追加する。
−それは、再生時間のΔ内である全ての消失しているブロックを緊急プールに追加する。
−それは、バッファマップにおいてスレッドによってダウンロード中であるとしてタグ付けされた各ブロックをチェックし、それを緊急プールに移動させるかを決定するために以下のテストを使用する。Pは、ブロックが再生されるまでのビデオの経過時間を表す。BMVは、推定されるネットワークインタフェースの速度を、このインタフェースのアクティブなスレッドの数およびブロックサイズの積で乗算することによって、スレッドがブロックをダウンロードするための推定時間Dを計算する。D+Δ<Pの場合、BMVは、ブロックを緊急プールに移動させ、バッファマップ上でそれを消失しているものとしてマーク付けする(それによって他のスレッドがそれを選択することができる)。
統計エンジン
−BMVは、T2秒ごとに、最後のT4秒の間にインタフェースを通じてダウンロードされるデータの量を合計することによって、インタフェースごとの推定されるネットワークインタフェースの速度を含む統計を計算し、T4についての典型的な値は、1、10、20、30秒である。それを可能にするために、図の[プログレッシブダウンローディングAPI]に示されるように、どのスレッドが統計エンジンにおいてどのブロックをダウンロードしたかを記録する。
スレッド失敗:ビデオをダウンロードしている間に、スレッドのうちの1つまたは複数が接続を損失する可能性があり、例えば、セルラおよびコーヒーショップから出るStarbucksのWiFiに接続されたユーザを考える。そのポイントでは、StarbucksのWiFiネットワークを損失することがあるが、セルラネットワーク(なお、屋外である)はより強くなることがある。1つの実施形態では、BMVは、1つまたは複数のスレッドが失敗するときにビデオをダウンロードすることを停止せず、残りのブロックを選択する他のスレッドを通じてダウンロードを継続する。よって部分的なネットワーク損失は、ユーザ経験を中断しない。
他のユーザは、スケジューリングについて選択し、接続の合計速度を達成する代わりに、他のユーザ定義基準を達成するようにアルゴリズムを容易に修正することができ、例えば:
−データプランの上限設定:ユーザは、データプラン(セルラ接続)を制限までのみ使用することを望み、次いで、通知されることを指定することができる。BMVは、統計エンジンにおいて各スレッドによってダウンロードされたデータの量を記録し、上限に達すると、それは、ユーザに通知し、セルラスレッドを停止する。
−データプランの節約:BMVはまた、緊急ウインドウ内、または再生時間からの時間W1<W内のいずれかであるブロックのみをセルラスレッドがダウンロードすることを可能にすることによって、データプランの節約を実現することができ、すなわち、BMVは、Wi−Fi接続からのセグメントを優先的にダウンロードし、Wi−Fi接続がW1内で必要なセグメントをダウンロードすることを管理しなくなった場合のみセグメントをセルラ接続に割り当てる。
−バッテリ。同様に、BMVは、バッテリレベルを入力として受け、バッテリが特定の閾値を上回る限り、制限された数のインタフェース上でのみスレッドのダウンロードをアクティブにする(ユーザに通知する)。
−通常ダウンロード:緊急プールをこれ以上維持しない。全てのブロックは、ブロックプールに配置され、連続して選択され、スレッドによってダウンロードされる。全てのブロックがダウンロードされ、またはダウンロード中である場合、失敗したスレッドに起因して不完全なダウンロードを回避するために、ダウンロードしているスレッドの推定されるダウンロード時間Dを上回ってダウンロードしていたブロックをスレッドが選択することを可能にする。
−スレッドは、ダウンロードされたブロックをキャッシュシステムの代わりに記憶システムに提供する。
BMVのキャッシュシステムは、1つの実施形態では、カスタムデータベースおよびファイルシステムを組み合わせることによって、複数のスレッドによって同時にダウンロードされたブロックを効率的に記憶およびクエリすることをサポートするように設計される。小さいファイルの記憶。この実施形態では、基本的な着想は、同一のファイルの内部にビデオの全てのブロックを収集する代わりに、各ブロックがファイルシステムにおける異なる小さいファイルに記憶されることである。結果として、複数のスレッドは、相互に妨害することなくファイルシステムに同時に書き込む(またはそれから読み出す)ことができる(それらが同一のファイルへの書き込みを試みる場合に行うように)。各スレッドは、ブロックに関するメタデータを保持するカスタムデータベーステーブルに行、例えば、ビデオ識別子、開始バイト、終了バイト、長さ、アクセス時間とともにブロックのデータを含む小さいファイルへのポインタを最初に挿入し、それは次いで、ブロックをファイルシステムに記憶することを進行させる。このアプローチは、ビデオについての単一のファイルを保持する従来のアプローチと比較してより高速な書き込み時間を提供する。これは、後者のアプローチでは、ブロックを書き込むことは、ファイルへのランダムな書き込みを伴い、それは、探索が含まれることになるので著しく長い時間を要するからである。プログレッシブモードをサポートするために、キャッシュシステムはまた、図の[プログレッシブダウンローディングAPI]に示されるように、キャッシュにおいて利用可能なメタデータおよびビデオのデータ範囲をHTTPプロキシサーバによって取り出すことができるクエリインタフェースを提供する。
退去(eviction)ポリシ:制約された記憶空間を有するデバイスをサポートするために、キャッシュシステムは、構成可能な最大サイズ、例えば、50メガバイト、所与の時に記憶することができるデータの最大量を有してもよい。スレッドが新たなブロックをキャッシュに書き込むことになり、キャッシュの空きが不足しているとき、新たな1つのための空きを作るためにいくつかの記憶されたデータを退去させる必要がある。キャッシュシステムの重要な設計選択は、その退去ポリシである。BMVキャッシュシステムは、その目標が円滑な再生をサポートするためにほとんどの関連するデータを常に保持することである新規なキャッシュ退去ポリシを含む。特に、キャッシュがデータを退去させる必要があるとき、1つの実施形態では、それは最初に:
−直近にアクセスされたビデオから始まって、現在再生しているビデオ以外のビデオの記憶されたブロックを退去させる(現在再生しているビデオは直近にアクセスされたものである)。
−そのようなデータが存在しない場合、それは、現在の再生時間の前に再生しているビデオのデータを退去させる。ダウンロードしているときの該当のスライドウインドウのサイズは、キャッシュが記憶することができるよりも多くのデータをダウンロードしないことを保証する。しかしながら、ユーザが探索の間にジャンプする場合、該当のポリシがわずかに変化する。現在の再生時間とは別に、ジャンプの前に最後に再生された時間をも記録する。ジャンプの前の最後に再生された時間の前である最初のブロックを退去させ、それらが消耗しているとき、現在の再生時間の前に、かつ最後に再生された時間からできるだけ離れたブロックを退去させる。このようにして、ユーザが戻ることを決めるケースについて、ユーザが見ることを停止したものに近いできるだけ長いブロックについて維持する。
記憶システム:レギュラーダウンローディングをサポートするために、BMVは、ダウンロードされたビデオデータをファイルシステムに永続的に記憶することを担う記憶システムを有する。1つの実施形態では、記憶システムの設計および実装は、記憶システムが退去ポリシを有さないこと除いてキャッシュシステムと同様である。記憶システムの主なカスタム機能は、複数のスレッドからの効率的な書き込みをサポートすることである。ビデオが完全にダウンロードされる場合、記憶システムは、ビデオの全てのデータを内蔵型再生可能ビデオファイルにエクスポートすることを可能にする。
HTTPプロキシサーバ:プログレッシブダウンローディングをサポートするために、BMVは、BMVの支援を要求したビデオプレイヤにダウンロードモジュールによってダウンロードされたビデオブロックを供給する、HTTPプロキシサーバを提供する。1つの実施形態では、サーバは、HTTP1.1プロトコルに従って、ビデオプレイヤのHTTP範囲要求に応答する。1つの実施形態では、サーバは、複数の要求に同時に対処することが可能である。1つの実施形態では、HTTPプロキシサーバは、現在の再生時間を推測し、ダウンロードモジュールに通知するためにビデオプレイヤのHTTP範囲要求を使用する。
BMVのコンポーネントはともに作動し、プログレッシブダウンローディングインスタンスの例を考えると、ビデオプレイヤはAPIと通信し、プログレッシブモードでBMVを起動させ、HTTPプロキシサーバは、起動し、ローカルアドレス、例えば、http://localhost/またはhttp://127.0.0.1をビデオプレイヤに提供する。ダウンロードモジュールは、ブロックをダウンロードし、それらをキャッシュシステムに記憶する。ビデオプレイヤが再生のためにメタデータまたはビデオの範囲をフェッチするためにローカルアドレスを示すとき、HTTPプロキシサーバは、要求されたデータについてキャッシュシステムをクエリし、ビデオプレイヤに応答する。この実施形態はまた、図9に示される。
BMVは、HLSビデオのダウンロード(ライブストリーミング)をサポートする。HLSビデオは、単一のファイルではないが、代わりに、.m3u8インデックスファイルおよび.tsセグメントファイルを含む、ファイルの集合から構成される。プログレッシブダウンローディング(ライブストリーミングイベントのケースにおける)およびレギュラーダウンローディング(HLSフォーマットに記憶された事前に記録されたイベントのケースにおける)の両方においてHLSビデオをダウンロードするためにBMVを使用することができる。1つの実施形態では、ステップは、通常のビデオについてのステップと非常に類似している(図11も参照)。主な差異は、インデックス(.m3u8)ファイルを最初に取得し、次いで、HLSビデオに追加される最後のセグメントを学習するためにインデックスファイルをサーバからリフレッシュすることである。特に、この実施形態では:
−ビデオプレイヤは、(i)setNetworks(ネットワーク)などの関数を呼び出すことによってダウンロードするためにどのネットワークを使用するかをBMVに通知し、(ii)プログレッシブダウンロード(videoUrl)と命名する関数を呼び出すことによってダウンロードを開始することをBMVに通知し、(iii)setDataSource()と命名する関数を呼び出すことによってプレイヤのデータの送信元をHTTPプロキシサーバに示す。
−最初に、videoURLは、インデックス(.m3u8)ファイルへのURLである。インデックスファイルは、セグメントについてのURLへのポインタを含む。ライブストリーミングでは、インデックスファイルは、より多くのビデオセグメントがオンラインで追加されるにつれて更新され、したがって、BMVは、最新のバージョンのインデックスファイルを定期的にダウンロードする。BMVは、インデックスファイルをダウンロードおよびリフレッシュするためにWiFiインタフェースを一貫して使用する(デバイスがセルラ専用モードで動作していない限り)。
−インデックスファイルをダウンロードするために使用されるURLは、それらが典型的にはインデックスファイルと同一のサーバに記憶されるので、セグメントをダウンロードするために度々再使用されてもよい。BMVは、解決されたURLのリソース部分を置き換えることによって、すなわち、インデックスファイル名を適切なセグメントファイル名と置き換え、次いで、結果として生じるURLが有効であるかをチェックすることによって、セグメントURLを作成するためにこれを利用する。BMVは、残りの必要とされるURLを識別するためにURIリゾルバを採用する。
−各セグメントは、以前のビデオと同一の方法で取り扱われる。特に、セグメントは、バッファマップ、ブロックプールおよび緊急プールに追加されるブロックに分割される。スレッドは、異なるインタフェースを通じてセグメントブロックをダウンロードする。セグメントがキャッシュに完全にダウンロードされると、それは、要求されるといつでも、HTTPプロキシサーバに、次いで、ビデオプレイヤにフェッチされる準備がされる。
−セグメントは、現在の再生時間により近い1つから始まって(前の方向での)、1つずつダウンロードされる。インデックスファイルをリフレッシュするとき、BMVは新たなセグメントを認識するので、それは、それらのダウンロードを連続してスケジュールする。
BMVはまた、適応的(品質)ストリーミングをサポートする。このケースでは、HLSビデオの複数のストリームを有し、その各々が異なる品質のビデオに対応する。各ストリームはそれ自身のセグメントを有する。HTTPプロキシサーバがビデオデータをどの程度高速に供給するかに応じて、ビデオプレイヤはその選択された品質を適合させることができ、すなわち、供給するためのより高いまたはより低い品質のビデオを選択することができる。BMVは、1つの実施形態では、HTTPプロキシサーバに、ビデオプレイヤの現在選択されているストリームをHLSエンジンに通知させることによって適応的ストリーミングをサポートする。通知は、黙示的に行うことができ、例えば、ビデオプレイヤは、HTTPプロキシからの特定の品質のセグメントを要求し、プロキシは、これを学習し、次いで、要求された品質のセグメントを取得することをHLSエンジンに通知する。実施形態では、HLSエンジンは、対応するストリームからの要求された品質のセグメントのダウンロードを開始する。レギュラーダウンローディングについて、BMVは、1つの実施形態では、前のと同様の手順を使用して、HLSビデオを取得するためにHLSエンジンを使用することができる。差異は以下を含む:1つ目に、HLSエンジンは、インデックスファイル(.m3u8)を、このファイルがなおも静的であり、1回のみフェッチされる必要があるので定期的にフェッチする必要がなく、2つ目に、ストリームの品質は、それがダウンロードを開始するとき、すなわち、図12に示されるように、通常のダウンロード(videoUrl、ストリーム品質)を呼び出すことによって指定される必要がある。
VideoBee:BMVプログレッシブおよびレギュラーダウンローディングは、VideoBee[11]と呼ばれる、androidアプリケーションに実装およびテストされている。VideoBeeからのスクリーンショットが図13に提示される。VideoBeeは、学術界および産業の両方によって非常に受け入れられている[15〜20]。単一の電話のみが利用可能であるとき、VideoBeeは、セルラのみ、WiFiのみ、またはセルラおよびWiFiの両方(ソロモード)を使用してビデオをダウンロードすることができる。第2の電話が近くにある場合、VideoBeeは、Bluetoothを通じて2つのデバイスを接続し(グループモード)、第1の電話のダウンロードレートを増大させるために第2の電話のインターネット接続(セルラ、WiFi、またはデュアル)を使用する(ベータテストの目的で、グループサイズを現在2に制限している)。両方のケースでは、主要なデバイスは、全ての接続の合計まで加速化したダウンロードを享受する。図9は、実験室においてVideoBeeのテストされた性能を示す。VideoBeeは、単一のデバイスがそのWiFiおよびセルラ接続の合計速度においてダウンロードすることを可能にし、2つのデバイスのグループがそれらの2つのセルラ接続の合計速度においてダウンロードすることを可能にしている。
ベータテスタのフィードバック:VideoBeeは、アクセスコードが与えられるときのみユーザがVideoBeeを実行するときに、非常に成功したクローズドベータテスト期間を得ている。それは3000のユーザを魅了し、それらは該当の技術の早くからの適合者であり、肯定的なフィードバックを与えることを非常に熱望している。
実性能:2013年12月の下旬、クローズドベータ期間を完了し、それをGoogle Play store[11]からダウンロードすることによって誰もがVideoBeeを試すことができるオープンベータを開始している。これまでに、一意なアプリケーションユーザは15000に達し、1週間ごとに平均すると3000の新規ユーザである。また、何千ものユーザによって使用されるときにVideoBee性能をそのままで収集するために、モニタモジュールを開発し、それを業界最高レベルFlurry分析エンジン[21]に統合している。図10〜12は、ソロモード(WiFiおよびセルラの両方による)ならびにグループモードをそれぞれ使用するときにユーザがどの程度高速にダウンロードすることができるかを示す。特に、該当の収集された統計から、ソロモードは、ダウンロードの速度を1.5倍の平均増大率および0.5メガビット/秒の平均増大率(グラフには示されない)を有する最大で2.6倍に増大させることができ、グループモードは、ダウンロードの速度を1.4倍の平均増大率および0.5メガビット/秒の平均増大率(グラフには示されない)を有する最大で6.1倍に増大させることができる。それらの実性能は、該当の技術を使用することによって得られる性能を立証する。正確な規模は、利用可能な接続の帯域幅に依存するが、VideoBeeの増大効果は、実際には付加的なものである。
アップロード:1つの実施形態におけるアップロードのために使用される技術は、ダウンロードのために使用される技術と対称的である。方法の同様のステップを繰り返すことなく、主な差異は、以下を含む。
サーバ:1つの実施形態では、BMVサーバ(それらのいくつかを維持することができる)または第三者サーバ(例えば、Facebookサーバ)にアップロードすることができる。サーバは、アップロードされたブロックを単純に収集し、それらを範囲の順序で単一のファイルに結合するBMVソフトウェアを実行する。1つの実施形態では、それを行うために、ブロックがアップロードされると、サーバは、指定されたメインサーバ上の単一のファイルにおける全てのアップロードされたブロックを収集するために相互に通信する。ファイルが結合されると、BMVサーバを使用している場合、1つの実施形態では、メインBMVサーバは次いで、ユーザがアップロードされることを要求した位置(例えば、Youtubeまたはパーソナルコンピュータ)にビデオを転送する。別の実施形態として、サーバは、それらが消失した全てのブロックを交換し、よって、それらは、アップロードされたビデオを全て再構築する。
ソロモード:1つの実施形態では、ソロモードにおいて、BMVは、複数のインタフェースおよびスレッドを確立し、ここで各インタフェースは、BMVサーバ(検索なしでアプリケーションの内部で直接提供される)または第三者サーバ(協働する第三者によって再度提供しており、または前と同一の技術で取得される)のうちの1つのURLに接続される。アップロードでは、レギュラーアップローディングモードをサポートする。1つの実施形態では、BMVは、ビデオをブロックに分割し、スレッドは、ブロックを選択し、それをサーバに1つずつアップロードし、バッファマップは、どのブロックがアップロードされたか、どのブロックが消失しているかを記録する。
本明細書で使用されるように、用語「約(about)」は、言及した数のプラスまたはマイナス10%を指す。
本明細書で説明されたものに加え、発明の種々の変更例が上述した説明から当業者にとって明らかである。そのような変更例はまた、添付の特許請求の範囲内にあることが意図される。本出願で示された各参考文献は、その全体を参照することによって本明細書に組み込まれる。
本発明の好ましい実施形態が示され、および説明されてきたが、添付の特許請求の範囲を逸脱せずに修正例がそれらになされてもよいことが当業者にとって容易に明らかである。したがって、本発明の範囲は、以下の特許請求の範囲によってのみ限定される。特許請求の範囲に記載される参照符号は例示的であり、特許庁による検討を容易にするためのみのものであり、決して限定するものではない。いくつかの実施形態では、本特許出願で提示された図面は、角度、大きさの比率などを含む、縮尺通りに描かれている。いくつかの実施形態では、図面は単なる表現であり、特許請求の範囲が図面の大きさによって限定されない。いくつかの実施形態では、フレーズ「備える(comprising)」を使用して本明細書で説明された発明の説明は、「から構成される(consisting of)」として説明されてよいも実施形態を含み、それによって、フレーズ「から構成される」を使用した本発明の1つまたは複数の実施形態を特許請求する記載要件が満たされる。
参考文献
[1]Cisco,「Cisco Virtual Networking Index:Global Mobile Data Traffic Forecast Update,2012−2017,」http://www.cisco.com/en/US/solutions/collateral/ ns341/ns525/ns537/ns705/ns827/white_paper_c11−520862.html(2014年1月30日に参照)。
[2]CNet News,「Can Apple’s App Store maintain its lead over Google Play?,」http://news.cnet.com/8301−1035_3−57521252−94/can−apples−app−store−maintain−its−lead−over−google−play(2014年1月30日に参照)。
[3]AT&T News Release,「AT&T to Invest $14 Billion to Significantly Expand Wireless and Wireline Broadband Networks,Support Future IP Data Growth and New Services」,http://www.att.com/gen/press−room?pid=23506&cdvn=news&newsarticleid=35661(2014年1月30日に参照)。
[4]Netflix,「Internet Connection Speed Recommendations,」https://support.netflix.com/en/node/306(2014年1月30日に参照)。
[5]YouTube,「Advanced encoding settings,」https://support.google.com/youtube/answer/1722171?hl=en(2014年1月30日に参照)。
[6]Akamai,「The state of the internet,」volume 4,No.4,4th quarter 2012 report。
[7]L.Keller,A.Le,B.Cici,H.Seferoglu,C.Fragouli,A.Markopoulou,「Microcast:Cooperative Video Streaming on Smartphones,」in ACM MobiSys 2012,Lake Wood,UK,June 2012。
First place in AMASE(mobile apps) competition,UCI,June 2012。
Top 5 papers in ACM Mobisys 2012,June 2012。
Microcast research project:http://microcast.calit2.uci.edu
[8]National Science Foundation l−Corps Award 1258866,「MicroCast:Cooperative Networking of Mobile Devices,」September 2012。
[9]AMASE Competition(「A Mobile Application Showcase Event」),School of ICS,UC Irvine,June 2012,http://www.ics.uci.edu/community/events/amase/index.php(2014年1月30日に参照)。
[10]National Science Foundation SBIR Phase I Award 1315106,「Microcast:Cooperative Video Delivery to Mobile Devices,」June 2013。
[11]Android App VideoBeehttps://play.google.com/store/apps/details?id=com.shoelacewireless.app.videobee(2014年1月30日に参照)。
[12]Business Insider,「Here’s What People Are Actually Watching On Their Smartphones And Tablets,As TV Goes Mobile,」http://www.businessinsider.com/mobile−video−report−2013−12(2014年1月30日に参照)
[13]Conviva,「Viewer Experience Report,2012」Feb 2013。
[14]Engadget,「YouTube Android app update brings HD video streaming to capable 2.2+ devices,」http://www.engadget.com/2012/03/02/youtube−android−app−update−brings−hd−video−streaming−to−capable/(2014年1月30日に参照)。
[15]CTIA,「CTIA Announces Startup Throw Down Winners at CTIA 2013,」http://www.ctia.org/resource−library/press−releases/archive/ctia−startup−throw−down−winners−ctia−2013(2014年1月30日に参照)。
[16]VideoBee−Second Best Mobile App Award,ACM Mobicom Mobile App Competition,2013 http://www.sigmobile.org/mobicom/2013/app_winners.html(2014年1月30日に参照)。
[17]XDA Developers,「Get Your Videos Faster with VideoBee for Android,」http://www.xda−developers.com/android/get−your−videos−faster−with−videobee−for−android/(2014年1月30日に参照)。
[18]Mobile Time,「VideoBee:app cria streaming 「cooperativo」entre celulares,」http://www.mobiletime.com.br/19/12/2013/videobee−app−cria−streaming−cooperativo−entre−celulares/364820/news.aspx(2014年1月30日に参照)。
[19]Android Ayuda,「Descarga y comparte videos rapidamente gracias a VideoBee para Android,」http://androidayuda.com/2013/1 1/09/descarga−y−comparte−videos−rapidamente−gracias−videobee−para−android/(2014年1月30日に参照)。
[20]Android Pipe,「Video Streaming at Its Best with VideoBee for Android,」http://www.androidpipe om/video−streaming−at−its−best−with−videobee−for−a(2014年1月30日に参照)。
[21]Flurry Analytics http://www.flurry.com/flurry−analytics.html(2014年1月30日に参照).
[22]IETF Internet Draft,「HTTP Live Streaming,」http://tools.ietf.org/html/ draft−pantos−http−live−streaming−12(2014年1月30日に参照)。
[23]Apple iOS,「Using HTTP Live Streaming,」https://developer.apple.com/library/mac/documentation/networkinginternet/onceptual/streamingmediaguide/UsingHTTP LiveStreaming/UsingHTTPLiveStreaming.html(2014年1月30日に参照)。
[24]Google Android,「Supported Media Format,」http://developer.android.com /guide/appendix/media−formats.html(2014年1月30日に参照)。
[25]Marketing Charts,「Top 10 Mobile−Phone Websites,by US Market Share of Visits,August 2013,」http://www.marketingcharts.com/wp/interactive/top−10−mobile−phone−websites−august−2013−36523/(2014年1月30日に参照)。
[26]Anh Le and Andrew Swerdlow,「Browser Extension Control Flow Graph Construction For Determining Sensitive Paths,」米国特許第8,286,250号,2012年10月9日に許可。
[27]Anh Le and Andrew Swerdlow,「Browser Extension Control Flow Graph Based Taint Tracking,」米国特許第8,365,291号,2013年1月29日に許可。
[28]BGR,「AT&T’s 4G LTE network found to be the fastest in the U.S,」http://bgr.com/2013/06/17/4g−lte−speeds−att−verizon−sprint−t−mobile(2014年1月30日に参照)。
[29]Arstechnica,「Multipath TCP lets Siri seamlessly switch between Wi−Fi and 3G/LTE,」http://goo.gl/iWcTdT(2014年1月30日に参照)。
[30]Google,Vpn−Service documentation,http://developer.android.com/reference/android/net/VpnService.html(2014年1月30日に参照)。
[31]Google Android,「Android 2.2 Platform Highlights,」May 2010 http://developer.android.com/about/versions/android−2.2−highlights.html
[32]Samsung,「What is S Beam,and how do I use it?」,http://www.samsung.com/us/support/supportOwnersHowToGuidePopup.do7how to_guide_seq=7042&prd_ia_cd=N0000003&map_seq=48157
[33]J.Kim,R.Khalili,A.Feldmann,Y−C.Chen,D.Towsley,「Multi−Source Multi−Path HTTP(mHTTP):A Proposal,」arXiv.1310.2748 http://arxiv−web3.library.cornell.edu/abs/1310.2748v3(2014年1月30日に参照)。
[34]MultiPath TCP http://www.multipath−tcp.org/(2014年1月30日に参照)。
[35]C.Tsao and R.Sivakumar,「On effectively exploiting multiple wireless interfaces in mobile hosts,」In Proceedings of the 5thlnternational Conference on Emerging Networking Experiments and Technologies(CoNEXT),pages 337−348,2009。
[36]H.Soroush,P.Gilbert,N.Banerjee,M.D.Corner,B.N.Levine,and L.Cox,「Spider:Improving mobile networking with concurrent wi−fi connections,」in SIG−COMM Computer Communication Review,41(4):402−403,Aug.2011。
[37]P.Rodriguez,R.Chakravorty,J.Chesterfield,I.Pratt,and S.Banerjee,「MAR:a commuter router infrastructure for the mobile internet,」in Proceedings of the 2nd International Conference on Mobile Systems,Applications,and Services(MobiSys),pages217−230,2004。
[38]J.Chesterfield,R.Chakravorty,I.Pratt,S.Banerjee,and P.Rodriguez,「Exploiting diversity to enhance multimedia streaming over cellular links,」in Proceedings of the 2005 IEEE INFOCOM,pages 2020−2031,Mar.2005。
[39]B.Han,P.Hui,V.A.Kumar,M.V.Marathe,G.Pei,and A.Srinivasan,「Cellular traffic offloading through opportunistic communications:a case study,」in Proceedings of the 5th ACM Workshop on Challenged Networks(CHANTS),pages 31−38,2010。
[40]S.loannidis,A.Chaintreau,and L.Massoulie.「Optimal and scalable distribution of content updates over a mobile social network,」in Proceedings of the 2009 IEEE INFOCOM,pages 1422−1430,Apr.2009。
[41]J.Whitbeck,M.Amorim,Y.Lopez,J.Leguay,and V.Conan.「Relieving the wireless infrastructure:When opportunistic networks meet guaranteed delays,」in Proceedings of the 2011 IEEE International Symposium on a World of Wireless,Mobileand Multimedia Networks(WoWMoM),pages 1−10,June 2011。
[42]C.Boldrini,M.Conti,and A.Passarella,「Exploiting users’ social relations to forward data in opportunistic networks:The HiBOp solution,」in Pervasive and Mobile Computing,4(5):633−657,Oct.2008。
[43]P.Hui,J.Crowcroft,and E.Yoneki.「Bubble rap:social−based forwarding in delay tolerant networks,」in Proceedings of the 9th ACM International Symposium on Mobile Ad Hoc Networking and Computing(Mobi−Hoc),pages 241−250,2008。
[44]G.Ananthanarayanan,V.N.Padmanabhan,L.Ravindranath,and C.A.Thekkath,「COMBINE:leveraging the power of wireless peers through collaborative downloading,」in Proceedings of the 5th International Conference on Mobile Systems,Applications and Services(MobiSys),pages 286−298,2007。
[45]M.Stiemerling and S.Kiesel,「A system for peer−to−peer video streaming in resource constrained mobile environments,」in Proceedings of the 1 st ACM Workshop on User−provided Networking:Challenges and Opportunities(U−NET),pages 25−30,2009。
[46]Verizon Share−Everything Plan,http://www.verizonwireless.com/wcms/consumer/shop/share−everything.html(2014年1月30日に参照)。
[47]AT&T Mobile Share Value Plans,http://www.att.com/shop/wireless/data−plans.html#fbid=10ndEspv7BW(2014年1月30日に参照)。
[48]T−Mobile,「Smartphone Mobile Hotspot,」http://offers.t−mobile.com/tethering/admin/faq.jsp(2014年1月30日に参照)。
[49]L.Keller,A.Le,B.Cici,H.Seferoglu,C.Fragouli,A.Markopoulou,「System and Method for Cooperative Data Streaming,」2013年3月にUC IrvineおよびEPFLによって共同で出願された米国特許出願(米国特許出願第13/841,500号)。
[50]A.Le,L.Keller,C.Fragouli,A.Markopoulou,「System and Method for Local Multiplayer Gaming,」2013年3月にUC IrvineおよびEPFLによって共同で出願された米国特許出願(米国特許出願第13/841,956号)。

Claims (69)

  1. モバイルインターネットトラフィックの速度を増加させるシステム(100)であって、
    a.複数のデータチャネルを通じてリモートサーバ(200)と通信することが可能な少なくとも1つのモバイルデバイス(102)であって、前記チャネルは、異なるタイプのチャネル(115、116)であり、前記モバイルデバイス(102)は、仮想プライベートネットワーク(VPN)サービスアプリケーション(103)を動作させるように構成され、前記サービスアプリケーションは、
    i.仮想ネットワークインタフェース(108)を確立することであって、前記モバイルデバイス(102)のオペレーティングシステムは、発信パケット(107)のセットをこのインタフェース(108)にルーティングするように構成され、前記VPNサービスアプリケーション(103)は次いで、ネットワークソケット(105)を使用して前記発信データパケット(114)を前記リモートサーバ(200)に送信する、確立することと、
    ii.発信パケット(107)の前記セットを前記仮想ネットワークインタフェース(108)から読み出すことと、
    iii.各発信パケット(107)を前記複数のチャネルのうちの1つに割り当てることと、
    iv.前記割り当てられたチャネルを介して発信パケット(114)の前記セットを前記リモートサーバ(200)に送信することであって、前記割り当てられたチャネルは同時に、Wi−Fiチャネルおよびセルラチャネル(115、116)である、送信することと、
    v.着信データパケット(113)の前記セットを前記リモートサーバ(200)から受信することであって、前記着信パケット(113)は、前記複数のチャネルを通じて同時に受信され、前記チャネルは、前記Wi−Fiチャネルおよび前記セルラチャネルである、受信することと、
    vi.前記着信パケット(106)を前記仮想ネットワークインタフェース(108)に書き込むことと、
    を含む動作を実行する、少なくとも1つのモバイルデバイス(102)と、
    b.前記複数のチャネルを通じて前記モバイルデバイス(102)と通信することが可能な前記リモートサーバ(200)であって、前記チャネルは、異なるタイプのチャネル(115、116)であり、前記リモートサーバ(200)は、インターネット上で複数のターゲットホスト(300)と通信することが可能であり、前記リモートサーバ(200)は、
    i.前記複数のチャネルを介して発信パケット(114)の前記セットを前記モバイルデバイス(102)から同時に受信することであって、前記チャネルは、前記Wi−Fiチャネルおよび前記モバイルデバイスの前記セルラチャネル(115、116)である、受信することと、
    ii.発信パケット(206)の前記セットを前記ターゲットホスト(300)に転送することと、
    iii.着信パケット(207)の前記セットを前記ターゲットホスト(300)から受信することと、
    iv.各着信パケット(207)を前記複数のチャネルのうちの1つに割り当てることであって、前記チャネルは、前記Wi−Fiチャネルおよび前記モバイルデバイスの前記セルラチャネル(115、116)である、割り当てることと、
    v.前記割り当てられたチャネル(115、116)を介して着信パケット(113)前記セットを前記モバイルデバイス(102)に送信することと、
    を含む動作を実行するように構成される、前記リモートサーバ(200)と、
    を備える、システム。
  2. モバイルインターネットトラフィックの速度を増加させるシステム(100)であって、
    a.複数のデータチャネルを通じてリモートサーバ(200)と通信することが可能な少なくとも1つのモバイルデバイス(102)であって、前記チャネルは、異なるタイプのチャネル(115、116、117)であり、前記モバイルデバイス(102)は、仮想プライベートネットワーク(VPN)サービスアプリケーション(103)を動作させるように構成され、前記サービスアプリケーションは、
    i.仮想ネットワークインタフェース(108)を確立することであって、前記モバイルデバイス(102)のオペレーティングシステムは、発信パケット(107)の前記セットをこのインタフェース(108)にルーティングするように構成され、前記VPNサービスアプリケーション(103)は次いで、ネットワークソケット(105)を使用して前記発信データパケットl(114)を前記リモートサーバ(200)に送信する、確立することと、
    ii.発信パケットの(107)前記セットを前記仮想ネットワークインタフェース(108)から読み出すことと、
    iii.各発信パケット(107)を前記複数のチャネルのうちの1つに割り当てることと、
    iv.前記割り当てられたチャネル(115、116、117)を介して発信パケット(114)の前記セットを前記リモートサーバ(200)に送信することと、
    v.着信データパケット(113)の前記セットを前記リモートサーバ(200)から受信することであって、前記着信パケット(113)は、前記複数のチャネルを通じて受信される、受信することと、
    vi.前記着信パケット(106)を前記仮想ネットワークインタフェース(108)に書き込むことと、
    を含む動作を実行する、少なくとも1つのモバイルデバイス(102)と、
    b.前記複数のチャネルを通じて前記モバイルデバイス(102)と通信することが可能な前記リモートサーバ(200)であって、前記チャネルは、異なるタイプのチャネル(115、116、117)であり、前記リモートサーバ(200)は、インターネット上で複数のターゲットホスト(300)と通信することが可能であり、前記リモートサーバ(200)は、
    i.前記複数のチャネル(115、116、117)を介して発信パケット(114)の前記セットを前記モバイルデバイス(102)から受信することと、
    ii.発信パケット(206)の前記セットを前記ターゲットホスト(300)に転送することと、
    iii.着信パケット(207)の前記セットを前記ターゲットホスト(300)から受信することと、
    iv.各着信パケット(207)を前記複数のチャネルのうちの1つに割り当てることと、
    v.前記割り当てられたチャネル(115、116、117)を介して着信パケット(113)の前記セットを前記モバイルデバイス(102)に送信することと、
    を含む動作を実行するように構成される、前記リモートサーバ(200)と、
    を備える、システム。
  3. 前記リモートサーバ(200)は、VPNサーバ(201)である、請求項2に記載のシステム。
  4. 前記サービスアプリケーション(109)は、増大ポリシ(116)を含み、前記増大ポリシ(119)は、前記発信パケット(114)を優先付け、どのパケットをどのチャネル(115、116、117)に割り当てるかを決定する、請求項2に記載のシステム。
  5. 前記増大ポリシ(119)は、前記パケットを生成するアプリケーション、前記複数のチャネル(115、116、117)の各々のチャネル状態に少なくとも基づいてアルゴリズムによって定義され、前記チャネル状態は、各チャネルのスループットおよび遅延、ならびに前記複数のチャネルの各々のチャネルタイプを含み、前記チャネルタイプは、デバイスツーデバイス接続(117)、Wi−Fi(115)、マイクロセル、ピコセル、および標準的なセルラ基地局(116)を含む、請求項4に記載のシステム。
  6. 前記増大ポリシ(119)は、構成可能なオプションのセットを含み、前記オプションは、コストを最小化し、伝送の速度を最適化し、または選択されたパケットタイプを優先付けるように前記増大ポリシ(119)を構成する、請求項4に記載のシステム。
  7. 発信パケット(114)の前記セットは、各チャネルの発信キューサイズ、各チャネルのデータ転送レート、および各チャネルの遅延のうちの少なくとも1つに基づいて、前記複数のチャネルを通じて送信される、請求項4に記載のシステム。
  8. 前記リモートサーバ(200)は、増大ポリシ(208)を動作させるように構成され、前記増大ポリシ(208)は、前記発信パケットの前記セットを優先付け、どのパケットをどのチャネルに割り当てるかを決定する、請求項2に記載のシステム。
  9. 前記増大ポリシ(208)は、前記パケットを生成するアプリケーション、前記複数のチャネルの各々のチャネル状態に少なくとも基づいてアルゴリズムによって定義され、前記チャネル状態は、各チャネルのスループットおよび遅延、ならびに前記複数のチャネルの各々のチャネルタイプを含み、前記チャネルタイプは、デバイスツーデバイス接続(117)、Wi−Fi(115)、マイクロセル、ピコセル、および標準的なセルラ基地局(116)を含む、請求項8に記載のシステム。
  10. 着信パケットの前記セットは、各チャネルの発信キューサイズ、各チャネルのデータ転送レート、および各チャネルの遅延のうちの少なくとも1つに基づいて、前記複数のチャネルを通じて送信される、請求項8に記載のシステム。
  11. 前記VPNサービスアプリケーション(103)は、前記モバイルデバイス(102)のバックグランドで動作する、請求項2に記載のシステム。
  12. 前記データパケット(120)は、オープンシステムインターコネクション(OSI)レイヤ3インターネットプロトコル(IP)データグラムまたはOSIレイヤ2イーサネットフレームのいずれかである、請求項2に記載のシステム。
  13. 前記仮想ネットワークインタフェースは、TUNまたはTAPインタフェース(108)のいずれかである、請求項2に記載のシステム。
  14. 前記ネットワークソケット(105)は、レイヤ4ユーザデータグラムプロトコル(UDP)ソケット、レイヤ4伝送制御プロトコル(TCP)ソケット、およびレイヤ3ローソケットのうちの少なくとも1つを含む、請求項2に記載のシステム。
  15. データパケットを送信する前記ネットワークソケット(105)は、実物理ネットワークインタフェースにバインドするように構成される、請求項2に記載のシステム。
  16. 前記実物理ネットワークインタフェースは、Wi−Fi(115)またはセルラ(116)物理インタフェースである、請求項15に記載のシステム。
  17. 前記複数のチャネルは、少なくともWi−Fiチャネル(115)およびセルラチャネル(116)を含む、請求項2に記載のシステム。
  18. 前記複数のチャネルは、少なくとも2つのセルラチャネル(116)を含む、請求項2に記載のシステム。
  19. 前記複数のチャネルは、少なくとも2つのWi−Fiチャネル(115)を含む、請求項2に記載のシステム。
  20. 前記複数のチャネルのうちの1つは、ローカルデバイスツーデバイスチャネル(117)である、請求項2に記載のシステム。
  21. 前記ローカルデバイスツーデバイスチャネル(117)は、Bluetoothチャネル、Wi−Fi直接チャネル、ロングタームエボリューション(LTE)直接チャネル、またはZigBeeチャネルである、請求項20に記載のシステム。
  22. 前記サーバは、前記複数のチャネルを介して受信された前記発信パケット(114)を、それらを前記インターネット上でターゲットホスト(300)に転送する前に再順序付けする、請求項2に記載のシステム。
  23. 前記サーバは、有効とされたIP転送で構成され、前記サーバは、ネットワークアドレス変換(214)との仮想ネットワークインタフェース(204)を確立し、前記インターネット上で着信パケット(207)を前記ターゲットホスト(300)から受信すると、前記サーバ(200)は、前記複数のチャネル(115、116、117)を同時に使用してそれらを前記モバイルデバイス(102)に転送する、請求項2に記載のシステム。
  24. 前記モバイルデバイス(102)は、着信パケット(113)の前記セットを再順序付け、それらをモバイルデバイスアプリケーション(109)にルーティングする、請求項2に記載のシステム。
  25. 前記モバイルデバイス(102)からの前記発信データパケット(114)および前記リモートサーバ(200)からの前記着信データパケット(113)は、暗号化スキームを使用して暗号化され(110)、前記着信データパケットは、前記モバイルデバイス(102)によって解読され(110)、前記発信パケットは、前記リモートサーバ(200)によって解読される(209)、請求項2に記載のシステム。
  26. 前記パケットの暗号化(110)は、セキュリティポリシ(212)によって制御され、前記セキュリティポリシ(212)は、前記パケットを生成する前記アプリケーション、前記複数のチャネルの各々のチャネルスループット、チャネル遅延、およびチャネルタイプを入力として受ける、請求項25に記載のシステム。
  27. 前記モバイルデバイス(102)からの前記発信データパケット(114)および前記リモートサーバ(200)からの前記着信データパケット(113)は、前記複数のチャネル(115、116、117)を通じて送信される前に符号化スキームを使用して符号化され(111)、前記着信データパケット(113)は、前記モバイルデバイス(102)によって復号され(111)、前記発信パケット(114)は、前記リモートサーバ(200)によって復号される(210)、請求項2に記載のシステム。
  28. 前記パケットの暗号化(209)は、セキュリティポリシ(212)によって制御され、前記セキュリティポリシ(212)は、前記パケットを生成する前記アプリケーション、前記複数のチャネルの各々のチャネルスループット、チャネル遅延、およびチャネルタイプのうちの少なくとも1つを入力として受ける、請求項27に記載のシステム。
  29. 前記リモートサーバ(200)は、前記複数のチャネルの全ての上で同一のインターネットプロトコル(IP)アドレスを有するように構成される、請求項2に記載のシステム。
  30. 前記リモートサーバ(200)は、前記複数のチャネルのうちの少なくとも1つの上で異なるインターネットプロトコル(IP)アドレスを有するように構成され、各チャネル上の前記発信パケット(206)は、それぞれの各チャネル上で前記サーバの前記IPアドレスにアドレス指定される、請求項2に記載のシステム。
  31. 前記モバイルデバイス(102)は、前記複数のチャネルのうちの少なくとも1つの上でプロキシサーバ(211)を介して前記リモートサーバ(200)と通信し、前記プロキシサーバ(211)は、発信パケット(114)の前記セットを前記モバイルデバイス(102)から受信し、それらを前記リモートサーバ(200)に転送し、前記プロキシサーバ(211)は、着信パケットの前記セットを前記リモートサーバ(200)から受信し、それらを前記モバイルデバイス(102)に転送する、請求項2に記載のシステム。
  32. 前記チャネルのうちの1つがWi−Fi(115)である場合、前記Wi−Fiチャネル(115)は、前記Wi−Fiチャネル(115)が前記モバイルデバイス(102)上で有効にされた後、既に前記Wi−Fiチャネル(115)にバインドされたソケットを選択することによって、または前記モバイルデバイス(102)上の選択されたネットワークソケットを前記Wi−Fiチャネル(115)にバインドすることによって指定される、請求項2に記載のシステム。
  33. 前記チャネルのうちの1つがセルラである場合、前記セルラチャネル(116)は、前記セルラチャネル(116)が前記モバイルデバイス(102)上で有効にされた後、既に前記セルラチャネル(116)にバインドされたソケットを選択することによって、または前記モバイルデバイス(102)上の選択されたネットワークソケットを前記セルラチャネル(116)にバインドすることによって指定される、請求項2に記載のシステム。
  34. 前記リモートサーバ(200)は、Wi−Fi接続性を提供し、またはWi−Fiアクセスポイントとしての役割を果たす、請求項2に記載のシステム。
  35. 前記リモートサーバ(200)は、セルラ接続性を提供し、またはセルラアクセスポイントとしての役割を果たし、前記セルラアクセスポイントは、スモールセル、マイクロセル、およびピコセルを含む、請求項2に記載のシステム。
  36. 利用可能な前記チャネル(115、116、117)のうちの1つのみがアクティブに使用され、使用されていない前記チャネルのうちの少なくとも1つが、このチャネルが障害を起こす場合には、使用されている前記チャネルのトラフィックを即時に搬送するためにアクティブに保持される、請求項2に記載のシステム。
  37. リモートサーバを使用することなくルーティング処理(504)を管理し、モバイルインターネットトラフィック(512、513)上のデータ転送についてのインターネットの速度(514)を増大させるシステムであって、前記システムは、異なる割り当てられたルーティングチャネル(510、511)を通じてターゲットインターネットホスト(600)と通信することが可能なクライアントの少なくとも1つのモバイルデバイス(502)を備え、前記チャネルは、異なるタイプのチャネル(524、525)であり、前記モバイルデバイス(502)は、仮想プライベートネットワーク(VPN)サービスアプリケーション(503)を動作させるように構成され、前記サービスアプリケーションは、
    a.仮想ネットワークインタフェース(505)を確立することであって、モバイルデバイス(502)のオペレーティングシステムは、発信パケット(508)のセットをこのインタフェースにルーティングするように構成され、前記VPNサービスアプリケーション(503)は、ユーザデータグラムプロトコル/インターネットプロトコル(UDP/IP)(513)または伝送制御プロトコル/インターネットプロトコルTCP/IP(512)トラフィックネットワークソケットを使用して、前記発信データパケット(508)から抽出されたデータを前記インターネットホスト(600)に送信する、確立することと、
    b.発信パケット(508)の前記セットを前記仮想ネットワークインタフェース(505)から読み出すことと、
    c.各発信パケット(508)を異なるトランスレータに割り当てることと、
    d.前記発信パケット(508)のデータを抽出することと、
    e.前記割り当てられたルーティングチャネル(524、525)のUDPまたはTCPソケットを介して前記抽出されたデータを前記インターネットホストに送信することと、
    f.着信データの前記セットを前記ターゲットホスト(600)で生成されたUDPまたはTCPソケット(516、518、520、522)から受信することと、
    g.データパケット(509)を前記受信されたデータから構築することと、
    h.前記データパケット(509)を前記仮想ネットワークインタフェース(505)に書き込むことと、
    を含む動作を実行する、システム。
  38. 前記VPNサービスアプリケーション(503)は、前記モバイルデバイス(502)のバックグランドで動作する、請求項37に記載のシステム。
  39. 前記データパケット(508、509)は、オープンシステムインターコネクション(OSI)レイヤ3インターネットプロトコル(IP)データグラムまたはOSIレイヤ2イーサネットフレームである、請求項37に記載のシステム。
  40. 前記仮想ネットワークインタフェース(505)は、TUNまたはTAPインタフェースのいずれかである、請求項37に記載のシステム。
  41. 保護された前記ソケット(515)は、レイヤ4ユーザデータグラムプロトコル(UDP)ソケットおよびレイヤ4伝送制御プロトコル(TCP)ソケットのうちの少なくとも1つを含む、請求項37に記載のシステム。
  42. ルーティングモジュールは、UDPトランスレータおよびTCPトランスレータを使用してUDPおよびTCPトラフィック(512、513)をルーティングするように構成される、請求項37に記載のシステム。
  43. 前記UDPトランスレータは、異なるチャネル(524、525)を通じて複数の別個のターゲットホストに接続する、請求項42に記載のシステム。
  44. 前記異なるチャネルは、WiFiチャネルおよびセルラチャネルである、請求項43に記載のシステム。
  45. 前記UDPトランスレータは、異なるチャネル(524、525)を通じて単一のターゲットホスト(600)に接続する、請求項42に記載のシステム。
  46. 前記異なるチャネルは、WiFiチャネルおよびセルラチャネルである、請求項45に記載のシステム。
  47. 前記TCPトランスレータは、異なるチャネル(524、525)を通じて複数の別個のターゲットホストに接続する、請求項42に記載のシステム。
  48. 前記異なるチャネルは、WiFiチャネルおよびセルラチャネルである、請求項47に記載のシステム。
  49. 前記TCPトランスレータは、異なるチャネル(524、525)を通じて単一のターゲットホストに接続する、請求項42に記載のシステム。
  50. 前記異なるチャネルは、WiFiチャネルおよびセルラチャネルである、請求項49に記載のシステム。
  51. データパケットを送出する保護された前記ソケット(515)は、実物理ネットワークインタフェースにバインドするように構成される、請求項37に記載のシステム。
  52. 前記実物理ネットワークインタフェースは、Wi−Fi(524)またはセルラ(525)物理インタフェースである、請求項51に記載のシステム。
  53. 前記VPNサービスアプリケーション(503)は、前記異なるチャネル(524、525)から受信されたデータを再組み立ておよび再順序付けし、データパケット(509)を前記受信されたデータから構築し、それらをモバイルデバイスアプリケーション(507)にルーティングするためにそれらを前記仮想ネットワークインタフェースに書き込むように構成される、請求項37に記載のシステム。
  54. 保護された前記ソケット(515)は、前記ターゲットホストに直接接続する、請求項37に記載のシステム。
  55. 前記サービスアプリケーションは、増大ポリシ(514)を含み、前記増大ポリシ(514)は、前記発信データをルーティングし、どのデータをどのチャネルに割り当てるかを決定する、請求項37に記載のシステム。
  56. 前記増大ポリシは、構成可能なオプションのセットを含み、前記オプションは、コストを最小化し、伝送の速度を最適化し、または選択されたパケットタイプをルーティングするように前記増大ポリシ(514)を構成し、パケットタイプは、前記アプリケーション(507)ならびにパケットサイズ、パケット遅延要件、およびパケットのターゲットホストを含む他の要因に依存する、請求項55に記載のシステム。
  57. 発信パケットの前記セットは、各チャネルの発信キューサイズ、各チャネルのデータ転送レート、および各チャネルの遅延のうちの少なくとも1つに基づいて、前記UDP/TCPソケットを通じて送信される、請求項55に記載のシステム。
  58. モバイルデバイス上でハイパーテキスト転送プロトコル(HTTP)を通じてファイルのダウンロードの速度を増加させる方法であって、前記モバイルデバイスは、複数の無線チャネルを通じて通信することが可能であり、前記方法は、
    a.ダウンロードされることになるファイルのURLを取得することと、
    b.それから前記ファイルをダウンロードすることができる前記URLを使用して複数のIPアドレスを取得することであって、各IPアドレスは、異なる無線チャネルに割り当てられる、取得することと、
    c.各無線チャネルに割り当てられた前記IPアドレスとの通信リンクを確立することと、
    d.前記URLを使用して、ダウンロードされることになる前記ファイルのメタデータを取得することと、
    e.前記メタデータを使用して前記ファイルを複数のブロックに分割することと、
    f.前記ファイルの前記ブロックのバッファマップを記憶することであって、前記バッファマップは、ブロックごとのダウンロード状態を含み、前記ダウンロード状態は、前記ブロックがダウンロードされたか、ダウンロードの処理中であるか、または消失しているかを識別する、記憶することと、
    g.次にダウンロードされることになる複数のブロックを含むブロックプールを記憶することと、
    h.前記ブロックプールをダウンロードされる必要がある新たなブロックで更新することと、
    i.複数のフェッチャスレッドを実行することであって、各フェッチャスレッドは、
    i.ダウンロードされたブロックについての前記ブロックプールをチェックすることと、
    ii.前記ブロックプールが空である場合にスリープすることと、
    iii.前記ブロックプールが空でない場合に、ブロックを前記ブロックプールから取得し、前記ブロックを前記ブロックプールから削除することと、
    iv.前記ブロックを前記スレッドに割り当てることと、
    v.前記ブロックについての前記バッファマップのエントリを更新して、それをダウンロードしているとして識別することと、
    vi.前記スレッドに割り当てられた前記ブロックをダウンロードすることと、
    vii.前記ブロックを記憶システムに記憶することであって、前記記憶システムは、データベースおよびメモリを含み、前記データベースは、各ブロックおよび各ブロックが記憶されたメモリ位置についてのメタデータを含む、記憶することと、
    viii.前記ブロックについての前記バッファマップのエントリを更新して、それをダウンロードされたものとして識別することと、
    を含むコードを実行する、実行することと、
    j.各フェッチャスレッドを無線チャネルに割り当てることであって、前記無線チャネルは、Wi−Fiチャネルまたはセルラチャネルであり、前記フェッチャスレッドは、その割り当てられたブロックをダウンロードするときに前記割り当てられた無線チャネルを利用し、それによって、Wi−Fiまたはセルラチャネルを通じてコンテンツを特定のIPアドレスからダウンロードするために各スレッドを割り当てる、割り当てることと、
    k.HTTPプロキシサーバを実行することであって、前記HTTPプロキシサーバは、
    i.ファイルの範囲に関するメタデータについてキャッシュシステムをクエリし、
    ii.ファイルデータの範囲を前記キャッシュシステムからフェッチし、
    iii.ローカルアドレスを前記キャッシュシステムに記憶されたファイルデータの範囲に提供する、
    ためのコードを含む、実行することと、
    を備える、方法。
  59. 前記記憶システムは、前記キャッシュシステムを含み、前記キャッシュシステムは、ファイルブロックを一時的に記憶し、前記キャッシュシステムは、退避ポリシを含み、十分なメモリがある場合に、より古いファイルブロックを削除または上書きすることができる、請求項58に記載の方法。
  60. 前記ブロックプールは、緊急プールをさらに含み、前記緊急プールは、緊急に必要とされるブロックのリストを含み、前記フェッチャスレッドは、緊急に必要とされる任意のブロックがあるかを決定するために前記緊急プールを最初にチェックし、緊急に必要とされる任意のブロックがある場合、前記フェッチャスレッドは、ブロックを前記緊急プールから選択し、前記ブロックは、それがダウンロードされることに成功した後までは前記緊急プールから削除されない、請求項58に記載の方法。
  61. ブロックは、前記ブロックの消費時間の前に時間のスライドウインドウに基づいて前記ブロックプールに割り当てられ、各ブロックは、それが消費されるべきときを指定するメタデータを有し、ブロックごとに、前記ファイルの現在の消費時間が前記ブロックの消費時間の前の前記スライドウインドウ内である場合、前記ブロックが前記ブロックプールに割り当てられる、請求項58に記載の方法。
  62. 前記ファイルをダウンロードすることができる複数のIPアドレスを取得することは、DNSリゾルバを実行することを含み、前記DNSリゾルバは、
    a.ドメイン名の信頼すべきDNSサーバをクエリすることと、
    b.前記ドメイン名の信頼すべきでないDNSサーバをクエリすることと、
    c.前記ホストの潜在的に記憶されたIPアドレスを発見するためにローカルデータベースをクエリすることと、
    を含む、請求項58に記載の方法。
  63. 前記ファイルをダウンロードすることができる複数のIPアドレスを取得することは、解決ブラウザを実行することを含み、前記解決ブラウザを実行することは、同一のファイルの異なるURLを直接取得するためにページを複数回見ることを含む、請求項58に記載の方法。
  64. 各フェッチャは、物理ネットワークインタフェースにバインドされたソケットを少なくとも使用する、請求項58に記載の方法。
  65. 前記物理ネットワークインタフェースは、Wi−Fiおよびセルラインタフェースを含む、請求項64に記載の方法。
  66. 少なくとも2つのフェッチャがあり、同一のファイルのブロックを単一のIPアドレスからフェッチするために、1つのフェッチャは、前記Wi−Fiインタフェースにバインドされたソケットを使用し、もう一方のフェッチャは、前記セルラインタフェースにバインドされたソケットを使用する、請求項65に記載の方法。
  67. 前記方法は、構成可能な数の前の秒の間にダウンロードされたデータの量を合計することによってインタフェースごとの前記ネットワークの速度を推定することをさらに備える、請求項58に記載の方法。
  68. 前記方法は、前記ファイルをローカル位置から前記HTTPサーバにアップロードするために使用され、前記フェッチャスレッドは、前記複数の無線チャネルを介して前記ローカルファイルのブロックを前記複数のIPアドレスまたは単一のIPアドレスにアップロードするために割り当てられ、前記複数のIPアドレスまたは前記単一のIPアドレスと関連付けられた前記サーバは、前記アップロードされたブロックを収集し、それらをもとのファイルに組み立てまたは再順序付けするソフトウェアを実行する、請求項58に記載の方法。
  69. モバイルデバイス上でハイパーテキスト転送プロトコル(HTTP)を通じてファイルのダウンロードの速度を増加させるシステムであって、前記モバイルデバイスは、複数の無線チャネルを通じて通信することが可能であり、前記システムは、
    a.ダウンロードされることになるファイルのURLを受信することが可能なダウンロードモジュールであって、前記ダウンロードモジュールは、
    i.複数のIPアドレスを、前記複数の無線チャネルを介して前記ファイルをダウンロードするために使用することができる前記URLから識別することが可能なユニフォームリソースロケータ(URL)リゾルバであって、
    1.ドメイン名サーバ(DNS)リゾルバであって、前記DNSリゾルバは、
    A.前記ファイルの前記ホスト名の第1のIPアドレスを前記URLから識別する手段と、
    B.複数の代替IPアドレスを探索するクエリを実行する手段と、
    を含む、DNSリゾルバと、
    2.複数のインスタンスが追加のIPアドレスを識別するために前記URLによって識別されたページを見る手段を含む解決ブラウザと、
    を含む、URLリゾルバと、
    ii.ダウンロードスケジューリングアルゴリズムであって、
    1.前記ファイルの前記メタデータをフェッチする手段と、
    2.ダウンロードされることになる前記ファイルを複数のブロックに分割する手段と、
    3.所望の消費時間の前の時間のスライドウインドウ内でダウンロードされることになる複数のブロックを識別する手段と、
    4.バッファマップを記憶する手段であって、前記バッファマップは、ブロックごとのダウンロード状態を記憶し、前記ダウンロード状態は、前記ブロックがダウンロードされたか、ダウンロードされるか、または消失しているかを識別する、記憶する手段と、
    5.ブロックプールを記憶する手段であって、前記ブロックプールは、前記スライドウインドウ内の前記複数のブロックを含む、記憶する手段と、
    6.緊急プールを記憶する手段であって、前記緊急プールは、緊急に必要とされる複数のブロックを含む、記憶する手段と、
    7.複数のフェッチャスレッドを実行する手段であって、各フェッチャスレッドは、
    A.前記緊急プールをチェックする手段と、
    B.前記ブロックプールをチェックする手段と、
    C.スリープする手段と、
    D.ブロックを前記スレッドに割り当てる手段と、
    E.前記スレッドに割り当てられた前記ブロックをダウンロードする手段と、
    F.前記バッファマップをチェックする手段と、
    G.前記バッファマップを更新する手段と、
    H.前記ブロックを前記キャッシュシステムに記憶する手段と、
    を含み、
    前記フェッチャスレッドは、前記緊急プールを最初にチェックし、前記緊急プールが空である場合、前記フェッチャスレッドは、前記ブロックプールをチェックし、前記ブロックプールが空である場合、前記フェッチャスレッドはスリープし、
    前記緊急プールが空でない場合、前記フェッチャスレッドは、前記第1のブロックをとり、それをダウンロードすることを試み、前記フェッチャスレッドが前記第1のブロックをダウンロードすることを終了すると、前記フェッチャスレッドは、前記第1のブロックを前記キャッシュシステムに記憶し、前記バッファマップにおいて前記第1のブロックをダウンロードされたものとしてタグ付けし、前記緊急プールが空であるが、前記ブロックプールが空でない場合、前記フェッチャスレッドは、前記ブロックプールにおいて前記第1のブロックをとり、前記第1のブロックが消失しているかまたはダウンロードしているかを決定するために前記バッファマップをチェックし、前記第1のブロックがダウンロード中である場合、前記フェッチャスレッドは、前記フェッチャスレッドが消失しているブロックを発見するまで、ブロックをとることを繰り返し、そのブロックが消失しているか、またはダウンロード中であるかを決定するために前記バッファマップをチェックし、前記フェッチャスレッドが消失しているブロックを発見するとき、前記フェッチャスレッドは、その消失しているブロックを前記スレッドに割り当て、前記フェッチャスレッドがその消失しているブロックをダウンロードすると、前記フェッチャスレッドは、前記バッファマップにおいてそのブロックをダウンロードされたものとしてマーク付けし、そのブロックを前記ブロックプールから削除する、
    実行する手段と、
    8.前記複数のフェッチャスレッドの各々を前記複数の無線チャネルのうちの1つに割り当てる手段であって、
    A.フェッチャスレッドごとに、データブロックを、そのルーティングが特定の無線チャネルを通るように構成されるIPアドレスからフェッチする手段であって、前記無線チャネルは、Wi−Fiチャネルまたはセルラチャネルである、フェッチする手段と、
    B.フェッチャスレッドごとに、物理ネットワークインタフェースにバインドされたソケットを使用する手段であって、前記ネットワークインタフェースは、Wi−Fiまたはセルラインタフェースを含む、使用する手段と、
    を含む、ダウンロードスケジューリングアルゴリズムと、
    を含む、ダウンロードモジュールと、
    b.プログレッシブダウンローディングにおいて使用するために一時的にダウンロードされたファイルブロックを記憶するように構成されたキャッシュシステムであって、
    i.前記ファイルの識別子、前記ファイルの開始バイト、前記ファイルの終了バイト、長さ、アクセス時間、および前記ブロックの前記データへのポインタを含む、ダウンロードされたブロックに関するメタデータを記憶するように構成されたデータベースと、
    ii.前記ファイルブロックを記憶するように構成されたメモリと、
    を含む、キャッシュシステムと、
    c.レギュラーダウンローディングにおいて使用するために永続的にダウンロードされたファイルブロックを記憶するように構成された記憶システムと、
    d.構成可能な量の秒の間にダウンロードされたデータの量を合計することによって各ネットワークインタフェースの速度を計算する手段を含む統計エンジンと、
    e.HTTPプロキシサーバであって、前記HTTPサーバは、ダウンロードされたファイルブロックの前記ローカルアドレスを供給するように構成される、HTTPプロキシサーバと、
    f.アプリケーションプログラミングインタフェース(API)であって、前記APIは、
    i.所望のネットワークチャネルを指定する手段と、
    ii.ダウンロードされることになるファイルのURLを指定する手段と、
    iii.前記複数の無線チャネルの前記速度に関する統計を要求し、前記システムから受信する手段と、
    iv.ファイルデータのブロックを要求し、前記システムから受信する手段と、
    を含む、APIと、
    を備える、システム。
JP2017555684A 2015-04-20 2016-04-20 改善されたモバイルインターネットの速度およびセキュリティのためのシステム Active JP7109044B2 (ja)

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
US201562150250P 2015-04-20 2015-04-20
US62/150,250 2015-04-20
US201562196583P 2015-07-24 2015-07-24
US62/196,583 2015-07-24
PCT/US2016/028499 WO2016172252A1 (en) 2015-04-20 2016-04-20 Systems for improved mobile internet speed and security

Publications (3)

Publication Number Publication Date
JP2018517341A true JP2018517341A (ja) 2018-06-28
JP2018517341A5 JP2018517341A5 (ja) 2019-05-30
JP7109044B2 JP7109044B2 (ja) 2022-07-29

Family

ID=57129485

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2017555684A Active JP7109044B2 (ja) 2015-04-20 2016-04-20 改善されたモバイルインターネットの速度およびセキュリティのためのシステム

Country Status (4)

Country Link
US (3) US9749293B2 (ja)
EP (1) EP3318102A4 (ja)
JP (1) JP7109044B2 (ja)
WO (1) WO2016172252A1 (ja)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11240862B2 (en) 2019-03-27 2022-02-01 Honda Motor Co., Ltd. Communication device, computer-readable storage medium, communication system, and communication method
JP2023506491A (ja) * 2019-12-11 2023-02-16 グーグル エルエルシー ユーザ仲介接続およびキャリア仲介接続の区分

Families Citing this family (36)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP4535163B2 (ja) 2008-04-08 2010-09-01 ソニー株式会社 情報処理システム、通信端末、情報処理装置、およびプログラム
US10057333B2 (en) 2009-12-10 2018-08-21 Royal Bank Of Canada Coordinated processing of data by networked computing resources
US10454726B2 (en) * 2014-12-29 2019-10-22 Watchy Technology Private Limited System for increasing bandwidth available for data communication
US9934020B2 (en) * 2015-03-10 2018-04-03 International Business Machines Corporation Intelligent mobile application update
US9952851B2 (en) * 2015-03-10 2018-04-24 International Business Machines Corporation Intelligent mobile application update
CN105898535A (zh) * 2015-12-30 2016-08-24 乐视致新电子科技(天津)有限公司 提高起播速度的方法、视频播放器及电子装置
US10116806B2 (en) * 2016-05-26 2018-10-30 Qualcomm Innovation Center, Inc. Bandwidth aware network statistics collection
US10305935B2 (en) 2016-06-09 2019-05-28 LGS Innovations LLC Methods and systems for enhancing cyber security in networks
US10637890B2 (en) 2016-06-09 2020-04-28 LGS Innovations LLC Methods and systems for establishment of VPN security policy by SDN application
US10594732B2 (en) * 2016-11-08 2020-03-17 Ca, Inc. Selective traffic blockage
WO2018203336A1 (en) * 2017-05-04 2018-11-08 Liveu Ltd. Device, system, and method of pre-processing and data delivery for multi-link communications and for media content
JP2020537457A (ja) * 2017-10-16 2020-12-17 アントン・エル・カペラ 通信システムにおけるデータ・ルーティング
US10581962B2 (en) * 2017-11-01 2020-03-03 Alibaba Group Holding Limited Direct communication between physical server and storage service
EP3718010B1 (en) * 2017-11-28 2023-04-26 Hewlett-Packard Development Company, L.P. Operating system repairs via electronic devices
CN108200588A (zh) * 2017-12-27 2018-06-22 南昌黑鲨科技有限公司 一种网络优化方法、装置、计算机可读存储介质及移动终端
CN108154468B (zh) * 2018-01-12 2022-03-01 平安科技(深圳)有限公司 肺结节探测方法、应用服务器及计算机可读存储介质
CN109754402B (zh) * 2018-03-15 2021-11-19 京东方科技集团股份有限公司 图像处理方法、图像处理装置以及存储介质
EP3769489A4 (en) * 2018-03-22 2021-12-15 Akamai Technologies, Inc. TRAFFIC FORWARDING AND DISAMBIGUATION USING LOCAL PROXYS AND ADDRESSES
US11328826B2 (en) 2018-06-12 2022-05-10 Clarius Mobile Health Corp. System architecture for improved storage of electronic health information, and related methods
US11509747B2 (en) * 2018-06-21 2022-11-22 British Telecommunications Public Limited Company Path selection for content delivery network
CN109040190B (zh) * 2018-07-02 2022-03-22 咪咕文化科技有限公司 一种调度方法、装置及计算机可读存储介质
EP3614627B1 (en) * 2018-08-20 2021-09-15 EXFO Inc. Telecommunications network and services qoe assessment
CN109362017B (zh) * 2018-10-18 2021-08-17 科大讯飞股份有限公司 智能终端的测试方法及测试系统
CN109543433B (zh) * 2018-11-27 2022-06-24 杭州网易智企科技有限公司 软件开发工具包加密方法、装置、计算机和存储介质
EP3882779A4 (en) 2018-12-10 2022-08-03 Freebit Co., Ltd. INTERNET CONNECTION MANAGEMENT SYSTEM FOR INFORMATION COMMUNICATION DEVICE, ASSOCIATED METHOD AND INTERNET CONNECTION MANAGEMENT PROGRAM INSTALLED IN AN INFORMATION COMMUNICATION DEVICE
TWI686064B (zh) * 2019-03-14 2020-02-21 就肆電競股份有限公司 點對點網路加速系統
CN110099403B (zh) * 2019-05-17 2022-07-19 腾讯科技(深圳)有限公司 一种数据传输方法、装置、设备及存储介质
CN110768886B (zh) * 2019-09-17 2021-11-02 广东电网有限责任公司广州供电局 应用程序自动连接vpn方法、装置、计算机设备和介质
EP4046337A1 (en) * 2019-11-03 2022-08-24 Cognyte Technologies Israel Ltd System and method for identifying exchanges of encrypted communication traffic
US10958758B1 (en) * 2019-11-22 2021-03-23 International Business Machines Corporation Using data analytics for consumer-focused autonomous data delivery in telecommunications networks
CN111083009B (zh) * 2019-11-29 2021-08-24 北京云测信息技术有限公司 一种抓包方法、装置和移动终端
TWI713362B (zh) * 2019-12-17 2020-12-11 瑞昱半導體股份有限公司 多媒體內容播放裝置與多媒體內容播放方法
WO2022094448A1 (en) * 2020-11-02 2022-05-05 Google Llc Virtual carrier network
US11178198B1 (en) * 2020-11-04 2021-11-16 Disney Enterprises, Inc. Buffering data on high bandwidth networks
US11489808B1 (en) * 2021-08-03 2022-11-01 Oversec, Uab Providing a split-configuration virtual private network
US11729148B1 (en) * 2022-09-04 2023-08-15 Uab 360 It Optimized utilization of internet protocol addresses in a virtual private network

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2005033808A (ja) * 2003-07-11 2005-02-03 Samsung Electronics Co Ltd 異種端末のアドホックネットワークを構築する装置及び方法
JP2007538422A (ja) * 2004-04-30 2007-12-27 パッドコム ホールディングズ,インコーポレイテッド 複数の無線ネットワーク上における、データの同時ルーティング
JP2008136123A (ja) * 2006-11-29 2008-06-12 Kyocera Corp 通信制御装置、無線通信装置、通信制御方法及び無線通信方法
JP2009094880A (ja) * 2007-10-10 2009-04-30 Kddi Corp ネットワーク装置およびプログラム
JP2013528984A (ja) * 2010-04-06 2013-07-11 クゥアルコム・インコーポレイテッド マルチパストランスポートを使用した協調帯域幅アグリゲーション
JP2014127890A (ja) * 2012-12-27 2014-07-07 Hitachi Ltd 無線端末、管理サーバ及びそれらを用いた無線通信システム

Family Cites Families (51)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6061796A (en) * 1997-08-26 2000-05-09 V-One Corporation Multi-access virtual private network
US7155646B2 (en) 1999-02-10 2006-12-26 Texas Instruments Incorporated Tap and test controller with separate enable inputs
US6775548B1 (en) 1998-06-22 2004-08-10 Nokia Mobile Phones Ltd. Access channel for reduced access delay in a telecommunications system
US6862622B2 (en) * 1998-07-10 2005-03-01 Van Drebbel Mariner Llc Transmission control protocol/internet protocol (TCP/IP) packet-centric wireless point to multi-point (PTMP) transmission system architecture
US6542508B1 (en) * 1998-12-17 2003-04-01 Watchguard Technologies, Inc. Policy engine using stream classifier and policy binding database to associate data packet with appropriate action processor for processing without involvement of a host processor
US7882247B2 (en) * 1999-06-11 2011-02-01 Netmotion Wireless, Inc. Method and apparatus for providing secure connectivity in mobile and other intermittent computing environments
US7219158B2 (en) * 2000-07-21 2007-05-15 Hughes Network Systems Llc Method and system for improving network performance using a performance enhancing proxy
US7069336B2 (en) * 2002-02-01 2006-06-27 Time Warner Cable Policy based routing system and method for caching and VPN tunneling
US7440573B2 (en) * 2002-10-08 2008-10-21 Broadcom Corporation Enterprise wireless local area network switching system
AU2003288948A1 (en) * 2002-10-28 2004-06-03 Jason R. Cooner Wireless access to emulate operation of a remote computer
US7457626B2 (en) * 2004-03-19 2008-11-25 Microsoft Corporation Virtual private network structure reuse for mobile computing devices
US8060875B1 (en) 2006-05-26 2011-11-15 Vmware, Inc. System and method for multiple virtual teams
US20080076425A1 (en) * 2006-09-22 2008-03-27 Amit Khetawat Method and apparatus for resource management
US8095786B1 (en) * 2006-11-09 2012-01-10 Juniper Networks, Inc. Application-specific network-layer virtual private network connections
JP4425298B2 (ja) * 2007-08-01 2010-03-03 富士通株式会社 パケットルーティング制御方法、パケットルーティング制御プログラム、端末装置、およびvpnサーバ
US8272046B2 (en) 2007-11-13 2012-09-18 Cisco Technology, Inc. Network mobility over a multi-path virtual private network
US7852849B2 (en) * 2008-03-04 2010-12-14 Bridgewater Systems Corp. Providing dynamic quality of service for virtual private networks
US8875152B2 (en) * 2010-04-22 2014-10-28 Salesforce.Com, Inc. System, method and computer program product for dynamically increasing resources utilized for processing tasks
US20110265288A1 (en) 2010-04-29 2011-11-03 Yung-Chang Chiang Two-stage dual-pintle hinge
US8474009B2 (en) * 2010-05-26 2013-06-25 Novell, Inc. Dynamic service access
WO2011153618A2 (en) 2010-06-09 2011-12-15 Pravala Inc. Transmitting data over a plurality of different networks
US10142292B2 (en) * 2010-06-30 2018-11-27 Pulse Secure Llc Dual-mode multi-service VPN network client for mobile device
US8549617B2 (en) * 2010-06-30 2013-10-01 Juniper Networks, Inc. Multi-service VPN network client for mobile device having integrated acceleration
US8127350B2 (en) * 2010-06-30 2012-02-28 Juniper Networks, Inc. Multi-service VPN network client for mobile device
US9253015B2 (en) * 2010-07-09 2016-02-02 Attila Technologies, Llc Transparent proxy architecture for multi-path data connections
US8990380B2 (en) * 2010-08-12 2015-03-24 Citrix Systems, Inc. Systems and methods for quality of service of ICA published applications
CN103262506B (zh) * 2010-10-22 2017-11-17 瑞典爱立信有限公司 用于允许区分处置移动网络数据业务的方法和装置
US8910300B2 (en) * 2010-12-30 2014-12-09 Fon Wireless Limited Secure tunneling platform system and method
US20120188949A1 (en) 2011-01-20 2012-07-26 Motorola-Mobility, Inc. Wireless communication device, wireless communication system, and method of routing data in a wireless communication system
US9716659B2 (en) * 2011-03-23 2017-07-25 Hughes Network Systems, Llc System and method for providing improved quality of service over broadband networks
US20120331160A1 (en) 2011-06-22 2012-12-27 Telefonaktiebolaget L M Ericsson (Publ) Multi-path transmission control protocol proxy service
US9491686B2 (en) * 2011-07-28 2016-11-08 Pulse Secure, Llc Virtual private networking with mobile communication continuity
US20130064198A1 (en) * 2011-09-14 2013-03-14 Qualcomm Incorporated Multipath transport tunnel over multiple air interfaces connecting wireless stations
US8897753B2 (en) * 2011-10-12 2014-11-25 Motorola Mobility Llc Method for retrieving content by a wireless communication device having first and second radio access interfaces, wireless communication device and communication system
US8365291B1 (en) 2011-11-16 2013-01-29 Google Inc. Browser extension control flow graph based taint tracking
US8286250B1 (en) 2011-11-16 2012-10-09 Google Inc. Browser extension control flow graph construction for determining sensitive paths
US8817797B2 (en) 2012-01-31 2014-08-26 Alcatel Lucent Method and apparatus for multipath protocol packet relay
US8891450B2 (en) * 2012-02-06 2014-11-18 Juniper Networks, Inc. Mobile node host route installation and withdrawal
US9621458B2 (en) * 2012-02-21 2017-04-11 Qualcomm Incorporated Internet routing over a service-oriented architecture bus
US20130332621A1 (en) 2012-06-08 2013-12-12 Ecole Polytechnique Federale De Lausanne (Epfl) System and method for cooperative data streaming
US9446306B2 (en) 2012-07-19 2016-09-20 The Regents Of The University Of California System and method for local multiplayer gaming
WO2014056528A1 (en) * 2012-10-10 2014-04-17 Nokia Solutions And Networks Oy Peer revival detection
US9130829B2 (en) * 2012-10-19 2015-09-08 Alcatel Lucent Methods and systems for obtaining load information in networks
WO2014124881A1 (en) * 2013-02-15 2014-08-21 Telefonaktiebolaget L M Ericsson (Publ) Systems, methods and computer program products for enabling a communication device to provide session improvement requests to a server of a network operator's access network
US9231918B2 (en) * 2013-02-19 2016-01-05 Cisco Technology, Inc. Use of virtual network interfaces and a websocket based transport mechanism to realize secure node-to-site and site-to-site virtual private network solutions
TWI528767B (zh) * 2013-03-05 2016-04-01 神乎科技股份有限公司 資訊服務方法及系統
US9755973B2 (en) * 2013-08-07 2017-09-05 Citrix Systems, Inc. Performing QoS on unknown bandwidths through rate estimating TCP congestion handlers
US20150120428A1 (en) * 2013-10-28 2015-04-30 U.S. Bank, National Association Mobile-enabled commerce service aggregation
US10037554B2 (en) * 2013-10-30 2018-07-31 Vigo Software Ltd Aggregated billing for application-based network access and content consumption
US9974115B2 (en) * 2013-12-30 2018-05-15 Google Technology Holdings LLC Method and device for policy-based routing
US20170325113A1 (en) 2016-05-04 2017-11-09 The Regents Of The University Of California Antmonitor: a system for mobile network monitoring and its applications

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2005033808A (ja) * 2003-07-11 2005-02-03 Samsung Electronics Co Ltd 異種端末のアドホックネットワークを構築する装置及び方法
JP2007538422A (ja) * 2004-04-30 2007-12-27 パッドコム ホールディングズ,インコーポレイテッド 複数の無線ネットワーク上における、データの同時ルーティング
JP2008136123A (ja) * 2006-11-29 2008-06-12 Kyocera Corp 通信制御装置、無線通信装置、通信制御方法及び無線通信方法
JP2009094880A (ja) * 2007-10-10 2009-04-30 Kddi Corp ネットワーク装置およびプログラム
JP2013528984A (ja) * 2010-04-06 2013-07-11 クゥアルコム・インコーポレイテッド マルチパストランスポートを使用した協調帯域幅アグリゲーション
JP2014127890A (ja) * 2012-12-27 2014-07-07 Hitachi Ltd 無線端末、管理サーバ及びそれらを用いた無線通信システム

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11240862B2 (en) 2019-03-27 2022-02-01 Honda Motor Co., Ltd. Communication device, computer-readable storage medium, communication system, and communication method
JP2023506491A (ja) * 2019-12-11 2023-02-16 グーグル エルエルシー ユーザ仲介接続およびキャリア仲介接続の区分
JP7326625B2 (ja) 2019-12-11 2023-08-15 グーグル エルエルシー ユーザ仲介接続およびキャリア仲介接続の区分

Also Published As

Publication number Publication date
WO2016172252A1 (en) 2016-10-27
EP3318102A1 (en) 2018-05-09
EP3318102A4 (en) 2019-03-20
US20170325286A1 (en) 2017-11-09
US10708978B2 (en) 2020-07-07
US9749293B2 (en) 2017-08-29
US20160308907A1 (en) 2016-10-20
US10212761B2 (en) 2019-02-19
US20190182903A1 (en) 2019-06-13
JP7109044B2 (ja) 2022-07-29

Similar Documents

Publication Publication Date Title
US10708978B2 (en) Systems for improved multi-channel network connectivity performance and security
Paschos et al. The role of caching in future communication systems and networks
Anjum et al. Survey on peer-assisted content delivery networks
US10986387B1 (en) Content management for a distributed cache of a wireless mesh network
CN103597876B (zh) 蜂窝网络中的连续高速缓存服务
US20170302724A1 (en) Virtual Channel Joining
EP2088719B1 (en) Method and device for distributing file data
US9390200B2 (en) Local caching device, system and method for providing content caching service
US10148721B2 (en) Video stream network coding in information centric networks
CN103597471A (zh) 用于对计算机网络上的数据通信进行缓存的方法和系统
CN103634692A (zh) 基于cdn和p2p的混合流媒体视频点播系统
US20150195764A1 (en) Network service system and method for providing network service in multiple mobile network environment
US11089103B1 (en) Content management in a distributed cache of a wireless mesh network
US10742706B1 (en) Server-side rate control for adaptive bitrate streaming protocols
CN115669075A (zh) 专用网络装置和专用局域网连接、内容发现、数据传输和控制方法
Malabocchia et al. Using information centric networking for mobile devices cooperation at the network edge
CN103621045B (zh) 内容分发
KR20220004670A (ko) 가변 연결성을 갖는 모바일 환경을 위한 마이크로 캐시 방법 및 장치
KR101402923B1 (ko) 캐시 장치에 사전 배포하는 콘텐츠를 관리하는 서버 및 방법, 그리고 캐시 장치
Neishaboori Implementation and evaluation of mobile-edge computing cooperative caching
Baydeti et al. Scalable Models for Redundant Data Flow Analysis in Online Social Networks
Moon et al. Cedos: A network architecture and programming abstraction for delay-tolerant mobile apps
Bai et al. End-System Approaches to Energy Consumption Efficiency for Content Distribution Service in Information-Centric Networking
KR20130134911A (ko) 적응형 컨텐츠 제공을 위한 컨텐츠 캐싱 서비스 제공 방법 및 이를 위한 로컬 캐싱 장치
EP2575323B1 (en) Delivering content from a server to a client

Legal Events

Date Code Title Description
A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20190419

A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20190419

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20200219

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20200317

A601 Written request for extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A601

Effective date: 20200610

A601 Written request for extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A601

Effective date: 20200813

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20200917

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20210202

A601 Written request for extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A601

Effective date: 20210430

A601 Written request for extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A601

Effective date: 20210630

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20210802

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20211130

A601 Written request for extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A601

Effective date: 20220225

A601 Written request for extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A601

Effective date: 20220425

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20220530

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20220621

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20220711

R150 Certificate of patent or registration of utility model

Ref document number: 7109044

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150