JP2018524887A

JP2018524887A - 多重経路メディア伝達のための方法及び装置

Info

Publication number: JP2018524887A
Application number: JP2017564824A
Authority: JP
Inventors: コラン，プラカシュ; ブアジジ，イメド
Original assignee: Samsung Electronics Co Ltd
Current assignee: Samsung Electronics Co Ltd
Priority date: 2015-06-16
Filing date: 2016-06-13
Publication date: 2018-08-30
Anticipated expiration: 2036-06-13
Also published as: EP3311534A1; CN107743698B; CN107743698A; EP3311534B1; JP6618552B2; KR20180009046A; WO2016204468A1; US20160373342A1; US10069719B2; EP3311534A4; KR102519409B1

Abstract

多重経路データパケット受信のための装置の制御方法は、メッセージをサーバに送信する過程と、２つ以上のネットワークアクセスインタフェース（ｎｅｔｗｏｒｋａｃｃｅｓｓｉｎｔｅｒｆａｃｅ）の１つ以上の特性に基づいて、多重経路伝送セッション（ｍｕｌｔｉｐａｔｈｔｒａｎｓｍｉｓｓｉｏｎｓｅｓｓｉｏｎ）の確立中に、装置の前記２つ以上のネットワークアクセスインタフェースの任意の組み合わせによってサーバから１つ以上のデータパケットを受信する過程と、を含む。前記メッセージは、多重経路伝送セッションに対応して前記装置の２つ以上のネットワークアクセスインタフェースのグループを指示する識別子（ｉｄｅｎｔｉｆｉｅｒ）を含む。

Description

本開示は、一般にマルチメディア伝送に関し、より具体的には、マルチメディア伝送ルーティング（ｒｏｕｔｉｎｇ）に関する。

ＭＰＥＧ（ｍｏｖｉｎｇｐｉｃｔｕｒｅｅｘｐｅｒｔｇｒｏｕｐ）メディア転送プロトコル（ｍｐｅｇｍｅｄｉａｔｒａｎｓｐｏｒｔｐｒｏｔｏｃｏｌ、ＭＭＴＰ）のようなマルチメディアストリーミング技術は、トランスポート層のサービスらを用いてＭＰＥＧメディア伝送（ｍｐｅｇｍｅｄｉａｔｒａｎｓｐｏｒｔ、ＭＭＴ）送信機のような送信元（ｓｏｕｒｃｅ）からＭＭＴ受信機のような宛先（ｄｅｓｔｉｎａｔｉｏｎ）にパケットをストリーミングする。選択したネットワークインタフェースに接続されたネットワークの問題によって、パケットが受信機で遅延したり損失したり多様なジッター（ｊｉｔｔｅｒ）とともに受信される場合がある。従って、受信機で明らかなＱｏＳ（ｑｕａｌｉｔｙｏｆｓｅｒｖｉｃｅ）及びＱｏＥ（ｑｕａｌｉｔｙｏｆｅｘｐｅｒｉｅｎｃｅ）問題が発生する。さらに、ネットワーク経路の予想外のパケット損失、混雑などのようなネットワーク条件の動的な変化によって品質が低下する場合がある。

本開示の技術分野では、多数のネットワークアクセスインタフェース（ｎｅｔｗｏｒｋａｃｃｅｓｓｉｎｔｅｒｆａｃｅ）の各々を介して、１つ以上のデータパケットを受信する必要がある。

多重経路データパケット受信のためのクライアント装置が提供される。クライアント装置は、プロセッサ及び２つ以上のネットワークアクセスインタフェース（ｎｅｔｗｏｒｋａｃｃｅｓｓｉｎｔｅｒｆａｃｅ）のグループを含む。プロセッサは、サーバへのメッセージ伝送を制御するように構成される。メッセージは、多重経路伝送セッション（ｍｕｌｔｉｐａｔｈｔｒａｎｓｍｉｓｓｉｏｎｓｅｓｓｉｏｎ）に対して一意であり、多重経路伝送セッションの間サーバから１つ以上のデータパケットを受信するためにクライアント装置の２つ以上のネットワークアクセスインタフェースのグループを識別する識別子（ｉｄｅｎｔｉｆｉｅｒ）を含む。また、プロセッサは、２つ以上のネットワークアクセスインタフェースの１つ以上の特性に基づいて、多重経路伝送セッションの間、クライアント装置の２つ以上のネットワークアクセスインタフェースの各々を介したサーバからの１つ以上のデータパケットの受信を制御するように構成される。

サーバが提供される。サーバは、プロセッサを含む。プロセッサは、クライアント装置からのメッセージの受信を制御するように構成される。メッセージは、多重経路伝送セッションに対して一意であり、多重経路伝送セッションの間サーバから１つ以上のデータパケットを受信するためにクライアント装置の２つ以上のネットワークアクセスインタフェースのグループを識別する識別子を含む。また、プロセッサは、２つ以上のネットワークアクセスインタフェースの１つ以上の特性に基づいて、多重経路伝送セッションの間、クライアント装置の２つ以上のネットワークアクセスインタフェースの各々を介したクライアント装置への１つ以上のデータパケットの送信を制御するように構成される。

多重経路データパケット受信のためにクライアント装置を用いて実現される方法が提供される。上記方法は、クライアント装置によってサーバにメッセージを送信する過程を含む。メッセージは、多重経路伝送セッションに対して一意であり、多重経路伝送セッションの間、サーバから１つ以上のデータパケットを受信するためにクライアント装置の２つ以上のネットワークアクセスインタフェースのグループを識別する識別子を含む。また、上記方法は、クライアント装置によって、２つ以上のネットワークアクセスインタフェースの１つ以上の特性に基づいて、多重経路伝送セッションの間、クライアント装置の２つ以上のネットワークアクセスインタフェースの各々を介して、サーバから１つ以上のデータパケットを受信する過程を含む。

多重経路データパケット受信のための装置の制御方法は、サーバにメッセージを送信する過程と、２つ以上のネットワークアクセスインタフェースの１つ以上の特性に基づいて、多重経路伝送セッションの間、前記装置の２つ以上のネットワークアクセスインタフェースの任意の組み合わせによってサーバから１つ以上のデータパケットを送信する過程と、を含む。メッセージは、多重経路伝送セッションに対応し、前記装置の２つ以上のネットワークアクセスインタフェースのグループを識別する識別子を含む。

多重経路データパケット送信のためのサーバの制御方法は、装置からメッセージを受信する過程と、多重経路伝送セッションの間、前記装置の２つ以上のネットワークアクセスインタフェースに対応する２つ以上のネットワーク経路を介して前記装置に１つ以上のデータパケットを送信する過程と、を含む。メッセージは、多重経路伝送セッションに対応し、多重経路伝送セッションの間、サーバから１つ以上のデータパケットを受信するために装置の２つ以上のネットワークアクセスインタフェースのグループを識別する識別子を含む。

本開示によれば、クライアント装置が多数のネットワークアクセスインタフェースを介して、１つ以上のデータパケットを受信することができるように装置及び方法が提供される。

本開示（ｄｉｓｃｌｏｓｕｒｅ）及びその利点をより完全に理解するために、後述する詳細な説明に対して添付図面とともに参照番号が提供される。
本開示に係る例示的な通信システムを示す図である。本開示に係る通信システム内の例示的な装置を示す図である。本開示に係る通信システム内の例示的な装置を示す図である。本開示に係るＭＰＥＧメディア伝送（ＭＭＴ）クライアントとＭＭＴサーバの間のＲＴＳＰ（ｒｅａｌｔｉｍｅｓｔｒｅａｍｉｎｇｐｒｏｔｏｃｏｌ）セッションの例示的な方法を示す図である。本開示に係るＭＭＴにおける多重経路伝達のための例示的な構造図である。本開示に係るＲＴＳＰプロトコルを用いるＭＭＴセッションセットアップの例示的な方法を示す図である。本開示に係る多数のネットワーク経路の各々に対する受信機フィードバックの例示図である。本開示に係るＨＴＴＰ（ｈｙｐｅｒｔｅｘｔｔｒａｎｓｆｅｒｐｒｏｔｏｃｏｌ）プロトコルを用いるＭＭＴセッションセットアップの例示的な方法を示す図である。本開示に係る装置による多重経路データパケット受信のための例示的な過程を示すフローチャートである。本開示に係るサーバによる多重経路データパケット送信のための例示的な過程を示すフローチャートである。

以下の詳細な説明の前に、本特許明細書全体にわたって用いられる特定の単語及び句の定義を記載することが好ましいであろう。「含む（ｉｎｃｌｕｄｅ）」及び「構成する（ｃｏｍｐｒｉｓｅ）」、並びにその派生語は制限なく含むことを意味する。用語「又は」は包括的用語で、「及び／又は」を意味する。句「連結される（ａｓｓｏｃｉａｔｅｄｗｉｔｈ）」、「関連づけられる（ａｓｓｏｃｉａｔｅｄｔｈｅｒｅｗｉｔｈ）」及びその派生は、含む（ｉｎｃｌｕｄｅ）、中に含まれる（ｂｅｉｎｃｌｕｄｅｄｗｉｔｈｉｎ）、互いに連結される（ｉｎｔｅｒｃｏｎｎｅｃｔｗｉｔｈ）、含む（ｃｏｎｔａｉｎ）、中に含まれる（ｂｅｃｏｎｔａｉｎｅｄｗｉｔｈｉｎ）、接続する（ｃｏｎｎｅｃｔｔｏｏｒｗｉｔｈ）、結合する（ｃｏｕｐｌｅｔｏｏｒｗｉｔｈ）、〜と通信できる（ｂｅｃｏｍｍｕｎｉｃａｂｌｅｗｉｔｈ）、協力する（ｃｏｏｐｅｒａｔｅｗｉｔｈ）、インターリーブする（ｉｎｔｅｒｌｅａｖｅ）、並べる（ｊｕｘｔａｐｏｓｅ）、隣接する（ｂｅｐｒｏｘｉｍａｔｅｔｏ）、縛られる（ｂｅｂｏｕｎｄｔｏｏｒｗｉｔｈ）、有する（ｈａｖｅ）、属性を持つ（ｈａｖｅａｐｒｏｐｅｒｔｙｏｆ）などを意味する場合がある。「制御部」は、少なくとも１つの動作を制御する装置、システム又はその一部を意味する場合がある。かかる装置は、ハードウェア、ファームウェア（ｆｉｒｍｗａｒｅ）、ソフトウェア、又はこれらのうち少なくとも２つの組み合わせで具現されてよい。特定の制御部と関連づけられた機能は、ローカルに遠隔的に中央集中化または分散化される場合がある。句「少なくとも１つ」は、それが項目のリストと共に用いられる場合、並べられた項目のうち１つ以上の異なる組み合わせが用いられてもよいし、リストの１つの項目のみが必要であってもよい。例えば、「Ａ、Ｂ、及びＣのうち少なくとも１つ」には、Ａ、Ｂ、Ｃ、ＡとＢ、ＡとＣ、ＢとＣ、さらには、ＡとＢとＣのうちいずれか１つが含まれる。

また、以下で説明される多様な機能は、少なくとも１つのコンピュータプログラムによって実現又はサポートでき、各々のコンピュータプログラムはコンピュータ読み取り可能なプログラムコードから形成され、コンピュータ読み取り可能な媒体で実現される。用語「アプリケーション（ａｐｐｌｉｃａｔｉｏｎ）」及び「プログラム（ｐｒｏｇｒａｍ）」は、適したコンピュータ読み取り可能なプログラムコードで実現可能に構成された少なくとも１つ以上のコンピュータプログラム、ソフトウェアコンポーネント、命令セット、手順、関数、オブジェクト、クラス（ｃｌａｓｓｅｓ）、インスタンス、関連データ、又はその一部をいう。句「コンピュータ読み取り可能なプログラムコード」は、ソースコード（ｓｏｕｒｃｅｃｏｄｅ）、オブジェクトコード（ｏｂｊｅｃｔｃｏｄｅ）、及び実行可能なコードを含むあらゆる類型のコンピュータコードを含む。句「コンピュータ読み取り可能な媒体」は、読み出し専用メモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）、ハードディスクドライブ、コンパクトディスク（ＣＤ）、デジタルビデオディスク（ＤＶＤ）、又は任意の他の類型のメモリのようなコンピュータによってアクセス可能な媒体の種類を含む。「非一時的な（ｎｏｎ−ｔｒａｎｓｉｔｏｒｙ）」コンピュータ読み取り可能な媒体は、一時的な電気的信号又は他の信号を送信する有線、無線、光学、又は他の通信リンクを除く。非一時的コンピュータ読み取り可能な媒体は、データが永続的に保存される媒体、及び再起録が可能な光ディスク又は消去可能なメモリ装置のような、データが記憶され、後に上書き可能な媒体を含む。

他の特定の単語及び句に対する定義が本特許明細書全般にわたって提供される。本開示の属する技術の分野における通常の知識を有する者であれば、大半ではないにしろ、そのような定義がそのように定義された単語及び句の従来及び将来の使用にも適用されることを理解すべきである。

以下で論議される図１乃至図１０及び本特許文書で本開示の内容の原理を説明するために用いられた多様な実施形態は単なる説明のためのものであって、本発明の範囲を制限するものと解釈されてはならない。本開示の属する技術の分野における通常の知識を有する者は、本開示の原理が任意の適切に配列されたシステム又は装置で実現されてよいことを理解するであろう。

次の文書及び標準説明は本明細書に記載のように本開示に参照として含まれる。“ＳｔｕｄｙｏｆＩＳＯ／ＩＥＣＣＤ２３００８−１ｍｏｖｉｎｇｐｉｃｔｕｒｅｅｘｐｅｒｔｇｒｏｕｐ（ＭＰＥＧ）ＭｅｄｉａＴｒａｎｓｐｏｒｔ”，ＭＰＥＧ−ＨＳｙｓｔｅｍｓ，ＩＳＯ／ＩＥＣＪＴＣ１／ＳＣ２９／ＷＧ１１，Ｏｃｔｏｂｅｒ２０１２［１］；“ＭＰＥＧＭｅｄｉａＴｒａｎｓｐｏｒｔＰｒｏｔｏｃｏｌ（ＭＭＴＰ）”，ＩＥＴＦＤｒａｆｔ，ｈｔｔｐｓ：／／ｔｏｏｌｓ．ｉｅｔｆ．ｏｒｇ／ｉｄ／ｄｒａｆｔ−ｂｏｕａｚｉｚｉ−ｍｍｔｐ−０１．ｔｘｔ，Ｓｅｐｔｅｍｂｅｒ２０１４［２］；“ＲｅａｌＴｉｍｅＳｔｒｅａｍｉｎｇＰｒｏｔｏｃｏｌ（ＲＴＳＰ）”，ＲＦＣ２３２６，ｈｔｔｐｓ：／／ｗｗｗ．ｉｅｔｆ．ｏｒｇ／ｒｆｃ／ｒｆｃ２３２６．ｔｘｔ，Ａｐｒｉｌ１９９８［３］；“ＨｙｐｅｒｔｅｘｔＴｒａｎｓｆｅｒＰｒｏｔｏｃｏｌ −− ＨＴＴＰ／１．０”，ＲＦＣ１９４５，ｈｔｔｐ：／／ｔｏｏｌｓ．ｉｅｔｆ．ｏｒｇ／ｈｔｍｌ／ｒｆｃ１９４５，Ｍａｙ１９９６［４］； “ＨｙｐｅｒｔｅｘｔＴｒａｎｓｆｅｒＰｒｏｔｏｃｏｌ −− ＨＴＴＰ／１．１”，ＲＦＣ２６１６，ｈｔｔｐ：／／ｗｗｗ．ｗ３．ｏｒｇ／Ｐｒｏｔｏｃｏｌｓ／ｒｆｃ２６１６／ｒｆｃ２６１６．ｔｘｔ，Ｊｕｎｅ１９９９［５］；“ＨｙｐｅｒｔｅｘｔＴｒａｎｓｆｅｒＰｒｏｔｏｃｏｌ（ＨＴＴＰ／１．１）：ＭｅｓｓａｇｅＳｙｎｔａｘａｎｄＲｏｕｔｉｎｇ”，ＲＦＣ７２３０，ｈｔｔｐｓ：／／ｔｏｏｌｓ．ｉｅｔｆ．ｏｒｇ／ｈｔｍｌ／ｒｆｃ７２３０，Ｊｕｎｅ２０１４［６］；“ＨｙｐｅｒｔｅｘｔＴｒａｎｓｆｅｒＰｒｏｔｏｃｏｌ（ＨＴＴＰ／１．１）：ＳｅｍａｎｔｉｃｓａｎｄＣｏｎｔｅｎｔ”，ＲＦＣ７２３１，ｈｔｔｐｓ：／／ｔｏｏｌｓ．ｉｅｔｆ．ｏｒｇ／ｈｔｍｌ／ｒｆｃ７２３１［７］；“ＳＤＰ：ＳｅｓｓｉｏｎＤｅｓｃｒｉｐｔｉｏｎＰｒｏｔｏｃｏｌ”，ＲＦＣ４５６６，ｈｔｔｐｓ：／／ｔｏｏｌｓ．ｉｅｔｆ．ｏｒｇ／ｈｔｍｌ／ｒｆｃ４５６６，Ｊｕｌｙ２００６［８］；“ＧｒｏｕｐｉｎｇｏｆＭｅｄｉａＬｉｎｅｓｉｎｔｈｅＳｅｓｓｉｏｎＤｅｓｃｒｉｐｔｉｏｎＰｒｏｔｏｃｏｌ（ＳＤＰ）”，ＲＦＣ３３８８，ｈｔｔｐｓ：／／ｔｏｏｌｓ．ｉｅｔｆ．ｏｒｇ／ｈｔｍｌ／ｒｆｃ３３８８［９］；“ＴｈｅＳｅｓｓｉｏｎＤｅｓｃｒｉｐｔｉｏｎＰｒｏｔｏｃｏｌ（ＳＤＰ）ＧｒｏｕｐｉｎｇＦｒａｍｅｗｏｒｋ”，ＲＦＣ５８８８，ｈｔｔｐｓ：／／ｔｏｏｌｓ．ｉｅｔｆ．ｏｒｇ／ｈｔｍｌ／ｒｆｃ５８８８［１０］； “ＴｈｅＷｅｂＳｏｃｋｅｔＰｒｏｔｏｃｏｌ”，ＲＦＣ６４５５，ｈｔｔｐｓ：／／ｔｏｏｌｓ．ｉｅｔｆ．ｏｒｇ／ｈｔｍｌ／ｒｆｃ６４５５［１１］；“ＳＤＰＤｅｓｃｒｉｐｔｏｒｓｆｏｒＭＭＴＰ”，ＩＥＴＦＤｒａｆｔ，ｈｔｔｐｓ：／／ｔｏｏｌｓ．ｉｅｔｆ．ｏｒｇ／ｈｔｍｌ／ｄｒａｆｔ−ｂｏｕａｚｉｚｉ−ｓｄｐ−ｄｅｓｃｒｉｐｔｏｒｓ−ｍｍｔｐ−００［１２］；Ｍ．Ｋａｚｅｍｉ，Ｓ．Ｓｈｉｒｍｏｈａｍｍａｄｉ，Ｋ．Ｈ．Ｓａｄｅｇｈｉ，“Ａｒｅｖｉｅｗｏｆｍｕｌｔｉｐｌｅｄｅｓｃｒｉｐｔｉｏｎｃｏｄｉｎｇｔｅｃｈｎｉｑｕｅｓｆｏｒｅｒｒｏｒ−ｒｅｓｉｌｉｅｎｔｖｉｄｅｏｄｅｌｉｖｅｒｙ”，ＭｕｌｔｉｍｅｄｉａＳｙｓｔｅｍｓ，Ｖｏｌｕｍｅ２０，Ｉｓｓｕｅ３，ｐｐ２８３−３０９，Ｊｕｎｅ２０１４［１３］；Ｚ．Ｌｉｕ，Ｇ．Ｃｈｅｕｎｇ，Ｊ．Ｃｈａｋａｒｅｓｋｉ，Ｙ．Ｊｉ，“ＭｕｌｔｉｐｌｅＤｅｓｃｒｉｐｔｉｏｎＣｏｄｉｎｇａｎｄＲｅｃｏｖｅｒｙｏｆＦｒｅｅＶｉｅｗｐｏｉｎｔＶｉｄｅｏｆｏｒＷｉｒｅｌｅｓｓＭｕｌｔｉ−ＰａｔｈＳｔｒｅａｍｉｎｇ”，ＩＥＥＥＪｏｕｒｎａｌＯｆＳｅｌｅｃｔｅｄＴｏｐｉｃｓＩｎＳｉｇｎａｌＰｒｏｃｅｓｓｉｎｇ，Ｖｏｌ．９，Ｎｏ．１，Ｆｅｂｒｕａｒｙ２０１５［１４］；Ｊ．Ｃｈａｋａｒｅｓｋｉ，Ｓ．Ｈａｎ，Ｂ．Ｇｉｒｏｄ，“ＬａｙｅｒｅｄＣｏｄｉｎｇｖｓ．ＭｕｌｔｉｐｌｅＤｅｓｃｒｉｐｔｉｏｎｓｆｏｒＶｉｄｅｏｓｔｒｅａｍｉｎｇｏｖｅｒＭｕｌｔｉｐｌｅＰａｔｈｓ”，Ｐｒｏｃ．ｏｆＡＣＭＭｕｌｔｉｍｅｄｉａ，ｐｐ．４２２−４３１，２００３［１５］；Ｖ．Ｓｉｎｇｈ，Ｓ．Ａｈｓａｎ，Ｊ．Ｏｔｔ，“ＭＰＲＴＰＭｕｌｔｉｐａｔｈｃｏｎｓｉｄｅｒａｔｉｏｎｓｆｏｒｒｅａｌ−ｔｉｍｅｍｅｄｉａ”，Ｐｒｏｃ．ｏｆＡＣＭＭｕｌｔｉｍｅｄｉａＳｙｓｔｅｍｓ，２０１３［１６］；Ｇ．Ｓｕｎ，Ｕ．Ｓａｍａｒａｗｉｃｋｒａｍａ，Ｊ．Ｌｉａｎｇ，Ｃ．Ｔｉａｎ，Ｃ．ＴｕａｎｄＴ．Ｄ．Ｔｒａｎ “Ｍｕｌｔｉｐｌｅｄｅｓｃｒｉｐｔｉｏｎｃｏｄｉｎｇｗｉｔｈｐｒｅｄｉｃｔｉｏｎｃｏｍｐｅｎｓａｔｉｏｎ”，ＩＥＥＥＴｒａｎｓ．ＩｍａｇｅＰｒｏｃｅｓｓ．，ｖｏｌ．１８，ｎｏ．５，ｐｐ．１０３７ −１０４７，２００９［１７］；Ｙ．Ｄｉｎｇ，Ｙ．Ｙａｎｇ，Ｌ．Ｘｉａｏ，“Ｍｕｌｔｉ−ｐａｔｈＲｏｕｔｉｎｇａｎｄＲａｔｅＡｌｌｏｃａｔｉｏｎｆｏｒＭｕｌｔｉ−ＳｏｕｒｃｅｖｉｄｅｏＯｎ−ｄｅｍａｎｄＳｔｒｅａｍｉｎｇｉｎＷｉｒｅｌｅｓｓＭｅｓｈＮｅｔｗｏｒｋｓ”，Ｐｒｏｃ．ＩＥＥＥＩＮＦＯＣＯＭ，ｐｐ．２０５１−２０５９，２０１１［１８］；Ｃ．Ｘｕ，Ｚ．Ｌｉ，Ｊ．Ｌｉ，Ｈ．Ｚｈａｎｇ，Ｇ．Ｍｕｎｔｅａｎ，“Ｃｒｏｓｓ−ｌａｙｅｒＦａｉｒｎｅｓｓ−ｄｒｉｖｅｎＣｏｎｃｕｒｒｅｎｔＭｕｌｔｉｐａｔｈＶｉｄｅｏＤｅｌｉｖｅｒｙｏｖｅｒＨｅｔｅｒｏｇｅｎｏｕｓＷｉｒｅｌｅｓｓＮｅｔｗｏｒｋ，ＩＥＥＥＴｒａｎｓａｃｔｉｏｎｓｏｎＣｉｒｃｕｉｔｓａｎｄＳｙｓｔｅｍｓｆｏｒＶｉｄｅｏＴｅｃｈｎｏｌｏｇｙ，Ｄｅｃｅｍｂｅｒ２０１４［１９］；Ｌ．Ｚｈａｎｇ，Ｍ．Ｈａｕｓｗｉｒｔｈ，Ｚ．Ｚｈｏｕ，Ｖ．Ｒｅｙｎｏｌｄｓ，Ｇ．Ｈａｎ，“Ｍｕｌｔｉ−ｐｒｉｏｒｉｔｙＭｕｌｔｉ−ＰａｔｈＳｅｌｅｃｔｉｏｎｆｏｒＶｉｄｅｏＳｔｒｅａｍｉｎｇｉｎＷｉｒｅｌｅｓｓＭｕｌｔｉｍｅｄｉａＳｅｎｓｏｒＮｅｔｗｏｒｋｓ”，ＦｉｆｔｈＩｎｔｅｒｎａｔｉｏｎａｌｃｏｎｆｅｒｅｎｃｅｏｎＵｂｉｑｕｉｔｏｕｓＩｎｔｅｌｌｉｇｅｎｃｅａｎｄＣｏｍｐｕｔｉｎｇ（ＵＩＣ２００８），Ｏｓｌｏ，Ｎｏｒｗａｙ，Ｊｕｎｅ２００８［２０］，ａｎｄＷ．Ｗｅｉ，Ａ．Ｚａｋｈｏｒ，“ＩｎｔｅｒｆｅｒｅｎｃｅＡｗａｒｅＭｕｌｔｉｐａｔｈＳｅｌｅｃｔｉｏｎｆｏｒＶｉｄｅｏＳｔｒｅａｍｉｎｇｉｎＷｉｒｅｌｅｓｓＡｄｈｏｃＮｅｔｗｏｒｋｓ”，ＩＥＥＥＴｒａｎｓａｃｔｉｏｎｓＯｎＣｉｒｃｕｉｔｓａｎｄＳｙｓｔｅｍｓｆｏｒＶｉｄｅｏＴｅｃｈｎｏｌｏｇｙ，ｖｏｌ．１９，ｎｏ．２，ｐｐ．１６５−１７８，２００９［２１］．

マルチメディアストリーミング技術及びアプリケーションは、ネットワークからは独立しており、宛先にデータをストリーミングするための下位層サービス（例：トランスポート層及びネットワーク層）に依存する。上位層（例：アプリケーション層）は、ルーティング決定及びデータ伝送に、追加的に又は代替的に関与できる。アプリケーションは、情報を交換してＱｏＳ（ｑｕａｌｉｔｙｏｆｓｅｒｖｉｃｅ）及びＱｏＥ（ｑｕａｌｉｔｙｏｆｅｘｐｅｒｉｅｎｃｅ）を報告できる。対話中の２の当事者がデータ伝達を向上させるために品質情報を用いるように改善できる。

例えば、マルチメディアストリーミングアプリケーションは、データを伝達する単一伝送経路を用いる代わりに、送信元から宛先にデータを伝達するために多重接続（例：多重経路を介した接続）を用いることができる（「多重経路伝達」）。スマートフォン及びタブレットといったモバイル装置は、３ＧＰＰ（ｔｈｉｒｄｇｅｎｅｒａｔｉｏｎｐａｒｔｎｅｒｓｈｉｐｐｒｏｊｅｃｔ）無線アクセス及びＷｉＦｉ（ｗｉｒｅｌｅｓｓｆｉｄｅｌｉｔｙ）インタフェースのような多重ネットワークアクセスインタフェースを備えている。代替的なネットワークアクセスチャネルの再使用により、ネットワーク過負荷の問題を緩和し、移動通信事業者がサービスできる加入者の数を増大できる。

他の例として、マルチメディア受信機アプリケーションは、他のパケットフロー（ネットワーク経路が異なる場合）の品質情報を検出して送信機アプリケーションに報告できる。送信機アプリケーションは、品質情報を用いて後続のパケット伝達のネットワーク経路を変更（例：他のネットワークインタフェースを用いる）して、誤った経路を回避できる。この場合、ネットワーク経路のネットワーク状態が不良なことによる受信機でのＱｏＳ及びＱｏＥ問題が緩和される。パケットレベル、フローレベル、接続レベルなどのような多様なレベルの細分性（ｇｒａｎｕｌａｒｉｔｙ）のために上位層で決定が下されるので、送信機アプリケーションの可視性（ｖｉｓｉｂｉｌｉｔｙ）が高くなり、情報に基づくより正確な決定を下すことができる。

図１は、本開示に係る例示的な通信システム１００を示す。図１に示す通信システム１００の実施形態は、単なる説明のためのものである。通信システム１００の他の実施形態は、本開示の範囲から逸脱することなく用いられることができる。

図１に示すように、システム１００は、ネットワーク１０２を含み、ネットワーク１０２は、システム１００内の多様な構成要素間の通信を容易にする。例えば、ネットワーク１０２は、インターネットプロトコル（ＩＰ）パケット、フレームリレーフレーム（ｆｒａｍｅｒｅｌａｙｆｒａｍｅｓ）、非同期転送モード（ａｓｙｎｃｈｒｏｎｏｕｓｔｒａｎｓｆｅｒｍｏｄｅ、ＡＴＭ）セル、又は、ネットワークアドレス間の他の情報を通信できる。ネットワーク１０２は、少なくとも１つのローカルエリアネットワーク（ＬＡＮ）、メトロポリタンエリアネットワーク（ｍｅｔｒｏｐｏｌｉｔａｎａｒｅａｎｅｔｗｏｒｋ、ＭＡＮ）、ワイドエリアネットワーク（ｗｉｄｅａｒｅａｎｅｔｗｏｒｋ、ＷＡＮ）、インターネットのようなグローバルネットワークの全部又は一部、又は少なくとも１つの位置のおける任意の他の通信システム又はシステムを含むことができる。

ネットワーク１０２は、少なくとも１つのサーバ１０４と多様なクライアント装置１０６−１１４との間の通信を容易にする。各々のサーバ１０４は、少なくとも１つのクライアント装置に、コンピューティングサービスを提供できる任意の適切なコンピューティング又は処理装置を含む。例えば、各サーバ１０４は、少なくとも１つの処理装置、命令及びデータを記憶する少なくとも１つのメモリ、及び、ネットワーク１０２に基づく通信を容易にする少なくとも１つのネットワークインタフェースを含むことができる。

各々のクライアント装置１０６，１０８，１１０，１１２，１１３，及び１１４は、少なくとも１つのサーバ又は他のコンピューティング装置とネットワーク１０２を介して相互作用する任意の適切なコンピューティング又は処理装置である。この実施例で、クライアント装置１０６，１０８，１１０，１１２，１１３，及び１１４は、デスクトップコンピュータ１０６、携帯電話又はスマートフォン１０８、ＰＤＡ（ｐｅｒｓｏｎａｌｄｉｇｉｔａｌａｓｓｉｓｔａｎｔ）１１０、ラップトップコンピュータ１１２，１１３及びタブレットコンピュータ１１４を含む。しかし、任意の他の又は追加のクライアント装置を、通信システム１００において用いることができる。

この実施例で、一部のクライアント装置１０８，１１０，１１２，１１３，及び１１４は、ネットワーク１０２と間接的に通信する。例えば、クライアント装置１０８及び１１０は、セルラー（ｃｅｌｌｕｌａｒ）基地局又はイーノードビー（ｅＮｏｄｅＢ）のような少なくとも１つの基地局１１６を介して通信する。また、クライアント装置１１２及び１１４は、ＩＥＥＥ８０２．１１無線アクセスポイントのような少なくとも１つの無線アクセスポイント１１８を介して通信する。他の例として、クライアント装置１０８は、多数のネットワークアクセスインタフェースを有することができる。他の例として、クライアント装置１０８は、多数のネットワークアクセスインタフェースを有することができる。多数のネットワークアクセスインタフェースを用いて、クライアント装置１０８は、ネットワーク通信経路１０９Ａを経て１つ以上の基地局１１６のうち少なくとも１つを介して、又はネットワーク通信経路１０９Ｂを経て１つ以上の無線アクセスポイント１１８を介してネットワーク１０２と通信するか、又は、ネットワーク通信経路１０９Ｃを経て他のクライアント装置１１２と通信できる。

また、この実施例で、サーバ１０４は、多数のネットワークアクセスインタフェースを有することができる。多数のネットワークアクセスインタフェースを用いて、サーバ１０４は、ネットワーク通信経路１０５Ａを経て１つ以上の基地局１１７のうち少なくとも１つを介して、ネットワーク通信経路１０５Ｂを経て１つ以上の無線アクセスポイント１１９を介して、又はネットワーク通信経路１０５Ｃを経て１つ以上の装置１１３を介してネットワーク１０２と通信できる。これらは単なる例示のためのものであって、各々のクライアント装置は、ネットワーク１０２と直接的に又は任意の適した中間装置又はネットワークを介してネットワーク１０２と間接的に通信できることを留意すべきである。

以下でより詳細に説明されるように、受信機（例：クライアント装置１０８）は、送信機からネットワーク通信経路を経て、複数の指定されたネットワークアクセスインタフェースを介して、データパケットを受信することができる。また、送信機（例：サーバ１０４）は、１つ以上の指定されたネットワークアクセスインタフェースを介して、そして、１つ以上のネットワーク通信経路を介して、受信機にデータパケットを送信できる。ネットワークアクセスインタフェース及びネットワーク通信経路は、受信機又は送信機のうち少なくとも１つによって開始された多重経路伝送セッション（ｍｕｌｔｉｐａｔｈｔｒａｎｓｍｉｓｓｉｏｎｓｅｓｓｉｏｎ）の間にのみデータパケット通信のために特定されることができる。また、受信機又は送信機は、データパケットのタイプが受信機の特定ネットワークアクセスインタフェースを介して受信されるべきであるかを決定できる。また、受信機及び送信機は、ＱｏＳパラメータ、ＱｏＥパラメータ、又は他のチャネル品質パラメータのうち少なくとも１つに基づいて、データパケット通信に適合したデータ通信経路の優先順位（ｐｒｉｏｒｉｔｙ）又は順位（ｒａｎｋｉｎｇ）を決定できる。

図１は、通信システム１００の一例を示すが、多様な変更が図１に対して行われてもよい。例えば、システム１００は、任意の適切な構成において任意の数の各構成要素を含むことができる。一般に、コンピューティング及び通信システムは、多様な構成を有し、図１は、本開示の範囲をいかなる特定構成にも限定しない。図１は、本特許文書に開示された多様な特徴を用いることができる１つの動作環境を示すが、これらの特徴は、任意の他の適したシステムにおいても用いることができる。

図２及び図３は、本開示に係る通信システム内の例示的な装置を示す。特に、図２は、例示的なサーバ２００を示し、図３は、例示的なクライアント装置３００を示す。サーバ２００は、図１のサーバ１０４であり、クライアント装置３００は、図１の少なくとも１つのクライアント装置１０６，１０８，１１０，１１２，又は１１４である。

図２に示すように、サーバ２００は、少なくとも１つのプロセッサ２１０、少なくとも１つの記憶装置２１５、少なくとも１つの通信部２２０及び少なくとも１つの入出力部（Ｉ／Ｏｕｎｉｔ）２２５の間の通信をサポートするバスシステム２０５を含む。

プロセッサ２１０は、メモリ２３０に読み込むことができる命令を実行する。プロセッサ２１０は、任意の適切な構成で任意の適切な数及び類型のプロセッサ又は他の装置を含むことができる。例示的な類型のプロセッサ２１０は、マイクロプロセッサ、マイクロコントローラ、デジタル信号プロセッサ、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、特定用途向け集積回路、及び、ディスクリート回路（ｄｉｓｃｒｅｔｅｃｉｒｃｕｉｔｒｙ）を含む。

メモリ２３０及び永久記憶装置（ｐｅｒｓｉｓｔｅｎｔｓｔｏｒａｇｅ）２３５は、情報（例：データ、プログラムコード及び／又は一時的又は永久的基本の他の適切な情報）の検索を記憶して容易にできる任意の構造を示す記憶装置２１５の例である。メモリ２３０は、ランダムアクセスメモリ（ＲＡＭ）又は任意の他の適切な揮発性又は不揮発性記憶装置である。永久記憶装置２３５は、読み出し専用メモリ（ＲＯＭ）、ハードドライブ、フラッシュメモリ、又は、光学ディスクのようにデータの長期記憶をサポートする少なくとも１つの構成要素又は装置を含むことができる。

通信部２２０は、他のシステム又は装置との通信をサポートする。例えば、通信部２２０は、ネットワーク１０２を介した通信を容易にするネットワークインタフェースカード又は無線送受信部を含むことができる。通信部２２０は、任意の適切な物理的又は無線通信リンクを介した通信をサポートする。

入出力部２２５は、データの入力及び出力を許可する。例えば、入出力部２２５は、キーボード、マウス、キーパッド、タッチスクリーン、又は他の適切な入力装置を介したユーザ入力のための接続を提供できる。また、入出力部２２５は、出力をディスプレイ、プリンタ又は他の適切な出力装置に送信できる。

図２が図１のサーバ１０４であると説明したが、同じ又は類似の構造を少なくとも１つのクライアント装置１０６−１１４において用いることができることに注目すべきである。例えば、ラップトップ又はデスクトップコンピュータは、図２に示したものと同じ又は類似の構造を有することができる。

以下でより詳しく説明するように、クライアント装置３００及びサーバ２００は、多重経路データパケット伝送のために用いられることができる。例えば、クライアント装置３００は、サーバ２００に要求を送信する。前記要求は、多重経路伝送セッションに対して一意であり、多重経路伝送セッションの間、サーバ２００から１つ以上のデータパケットを受信するためにクライアント装置３００の２つ以上のネットワークアクセスインタフェースを識別する識別子を含む。また、クライアント装置３００は、多重経路伝送セッションの間、クライアント装置３００の２つ以上のネットワークアクセスインタフェースの各々を介してサーバ２００から１つ以上のデータパケットを受信することができる。

図３に示すように、クライアント装置３００は、アンテナ３０５、無線周波数（ＲＦ）送受信部３１０、送信（ＴＸ）処理回路３１５、マイクロホン３２０及び受信（ＲＸ）処理回路３２５を含む。また、クライアント装置３００は、スピーカ３３０、メインプロセッサ３４０、入／出力（Ｉ／Ｏ）インタフェース３４５、キーパッド３５０、ディスプレイ３５５及びメモリ３６０を含む。メモリ３６０は、オペレーティングシステム（ＯＳ）プログラム３６１、及び、少なくとも１つのアプリケーション３６２を含む。

ＲＦ送受信部３１０は、アンテナ３０５から、システムの他の構成要素によって送信された受信ＲＦ信号を受信する。ＲＦ送受信部３１０は、受信ＲＦ信号をダウンコンバートして中間周波数（ＩＦ）又は基底帯域信号を生成する。ＩＦ又は基底帯域信号は、基底帯域又はＩＦ信号をフィルタリング、デコーディング及び／又はデジタル化することによって処理された基底帯域信号を生成する受信処理回路３２５に送信される。受信処理回路３２５は、処理された基底帯域信号（音声データ等）をスピーカ３３０又は追加処理（ウェブブラウジングデータ等）のためにプロセッサ３４０に送信する。

送信処理回路３１５は、マイクロホン３２０からアナログ又はデジタル音声データを受信し、プロセッサ３４０から他の発信基底帯域データ（ウェブデータ、電子メール、又は両方向ビデオゲームデータ）を受信する。送信処理回路３１５は、発信基底帯域データをエンコーディング、多重化、及び／又はデジタル化して、処理された基底帯域又はＩＦ信号を生成する。ＲＦ送受信部３１０は、発信処理された基底帯域又はＩＦ信号を送信処理回路３１５から受信し、基底帯域又はＩＦ信号を、前記アンテナ３０５を介して送信されるＲＦ信号にアップコンバートする。一実施形態で、２つ以上のネットワークアクセスインタフェースは、１つ以上の入出力インタフェース３４５、１つ以上のＲＦ送受信部３１０などを含むことができる。入出力インタフェース３４５は、イーサネット（登録商標）接続のためのネットワークインタフェースカード、又は、セットトップボックスのためのケーブルインタフェースのような有線接続を介して通信できる。ＲＦ送受信部３１０は、無線アクセスポイント（例：無線アクセスポイント１１８又は１１９）、基地局（例：基地局１１６又は１１７）などと通信できる。

プロセッサ３４０は、少なくとも１つのプロセッサ又は他の処理装置を含むことができ、クライアント装置３００の全体動作を制御するために、メモリ３６０に記憶されたＯＳプログラム３６１を実行できる。例えば、プロセッサ３４０は、周知の原理に従って、ＲＦ送受信部３１０、受信処理回路３２５及び送信処理回路３１５による順方向チャネル信号の受信及び逆方向チャネル信号らの送信を制御できる。一部の実施形態で、プロセッサ３４０は、少なくとも１つのマイクロプロセッサ又はマイクロコントローラを含む。

また、プロセッサ３４０は、他のプロセッサ及びメモリ３６０に常駐するプログラムを実行できる。プロセッサ３４０は、実行中のプロセスの要求に従って、データをメモリ３６０の内外に移動できる。一部の実施形態で、プロセッサ３４０は、ＯＳプログラム３６１に基づいて、又は、外部装置又はオペレータから受信した信号に応じて、アプリケーション３６２を実行するように構成される。また、プロセッサ３４０は、クライアント装置３００に、ノートブック及び携帯用コンピュータのような他の装置と接続されるようにする能力を提供するＩ／Ｏインタフェース３４５に結合されている。Ｉ／Ｏインタフェース３４５は、かかるアクセサリ及びプロセッサ３４０の間の通信経路である。

また、プロセッサ３４０は、キーパッド３５０及びディスプレイユニット３５５に結合されている。クライアント装置３００のオペレータは、クライアント装置３００にデータを入力するためにキーパッド３５０を用いることができる。ディスプレイ３５５は、液晶ディスプレイ又はウェブサイトからの文字及び／又は少なくとも制限されたグラフィックをレンダリングできるディスプレイであってよい。

メモリ３６０は、プロセッサ３４０に結合されている。メモリ３６０の一部はＲＡＭを含むことができ、メモリ３６０の他の部分はフラッシュメモリ又はＲＯＭを含むことができる。

図２及び図３は、通信システム内の装置の例を示すが、図２及び図３に多様な変更が行われてよい。例えば、図２及び図３の多様な構成は組み合わせ、細分化、又は省略されてもよく、追加的な構成が特定の必要に応じて追加されてもよい。特定例として、プロセッサ３４０は、少なくとも１つの中央処理ユニット（ＣＰＵ）及び少なくとも１つのグラフィック処理ユニット（ＧＰＵ）のような多重プロセッサに分けられてもよい。また、図３は、携帯電話及びスマートフォンで構成されたクライアント装置３００を示すが、クライアント装置は、他の類型の移動又は固定式装置によっても構成できる。また、コンピューティング及び通信ネットワークと同様に、クライアント装置及びサーバは、多様な構成を有することができ、図２及び図３は、いかなる特定のクライアント装置又はサーバに本開示を限定しない。

ＭＭＴＰプロトコル［［２］］は、ＭＭＴ送信機とＭＭＴ受信機との間で、時間（ｔｉｍｅｄ）及び非時間（ｎｏｎ−ｔｉｍｅｄ）マルチメディアデータを伝達するために用いられるアプリケーション層プロトコルである。ＭＭＴＰプロトコルは、マルチメディアデータ伝達のためのペイロードパケットフォーマットの他にも、シグナリングメッセージのセット及びメッセージフォーマットを記述する。ＭＭＴＰプロトコルは、実際のデータ伝達のためにトランスポート層サービスに依存する。マルチメディアデータを交換するために、ＭＭＴ送信機とＭＭＴ受信機の間に伝送接続（例：ＴＣＰ（ｔｒａｎｓｍｉｓｓｉｏｎｃｏｎｔｒｏｌｐｒｏｔｏｃｏｌ）伝送を用いるＴＣＰ接続、及び、ＵＤＰ（ｕｓｅｒｄａｔａｇｒａｍｐｒｏｔｏｃｏｌ）伝送を用いるＵＤＰフロー）がセットアップされる。ＭＭＴＰプロトコルは、ＭＭＴ送信機とＭＭＴ受信機の間にＭＭＴＰセッションをセットアップするためにＲＴＳＰ又はＨＴＴＰのような信号プロトコルを用いる。

図４は、本開示に係るＭＭＴクライアント（例：ＭＭＴ受信機）とＭＭＴサーバ（例：ＭＭＴ送信機）の間のＲＴＳＰセッションの例示的な方法４００を示す。過程４０５にて、クライアント装置３００は、サーバ２００にデータ伝達のためのＵＲＬ（ｕｎｉｆｏｒｍｒｅｓｏｕｒｃｅｌｏｃａｔｏｒ）を記述することを要求する。過程４１０にて、サーバ２００は、データ伝達のためのＵＲＬを記述するためにクライアント装置３００から要求を受信したことに応じて、セッション記述プロトコル（ＳＤＰ）プロトコルを用いてボディーディスクリプション（ｂｏｄｙｄｅｓｃｒｉｐｔｉｏｎ）を送信する。過程４１５にて、クライアント装置３００は、ＲＴＳＰＳＥＴＵＰメッセージを用いてセットアップ要求を送信する。クライアント装置３００は、クライアント装置３００がストリームを受信しようとする１つ以上の経路を指定する伝送ヘッダ内の伝送プロファイル（基本（ｕｎｄｅｒｌｙｉｎｇ）伝送を含む）、宛先アドレス及びクライアントポートのような伝送パラメータをＳＥＴＵＰメッセージに含めることができる。過程４２０にて、サーバ２００は、伝送ヘッダ内のサーバポート及び宛先アドレスのようなサーバ２００自身の伝送パラメータセットを用いて、セットアップ要求に対する応答（例：２００ＯＫ）で応答する。過程４２５にて、クライアント装置３００は、セットアップされた伝送接続を用いて、マルチメディアデータを再生するようにサーバ２００に要求する。過程４３０にて、サーバ２００は、セットアップ及び対応する応答メッセージを用いてセットアップされた伝送接続により、マルチメディアデータをクライアント装置３００に送信する。以下で説明されるように、サーバ２００からクライアント３００への例示的なＳＤＰは、[［１２］]で規定されたセッションセットアップの実行中に用いられることができる。

上述のように、クライアント装置（例：ＭＭＴクライアント）３００及びサーバ（例：ＭＭＴサーバ）２００は、メディアアセットのタイプ、及び、アセットを交換することができる伝送パラメータに同意できる。

シグナリングプロトコルは、サーバ２００とクライアント装置３００との間で交換されるマルチメディアデータを用いて、伝送接続（ＴＣＰ又はＵＤＰ）をセットアップするために用いられる。図４に示すように、伝送接続はクライアント装置３００とサーバ２００との間の一対一接続である。伝送接続を介して伝送できるマルチメディアデータの量は、伝送接続で用いられるネットワークインタフェースの容量とネットワークインタフェースに接続されたネットワークの使用可能な帯域幅に制限される。結果として、受信機でのエンドユーザエクスペリエンス（ｅｎｄｕｓｅｒｅｘｐｅｒｉｅｎｃｅ）は、伝送接続がセットアップされたネットワーク経路の品質に依存する。（高いパケット損失、混雑などを原因として）ネットワーク経路が適切に動作しないと、エンドユーザエクスペリエンスは、例えば、メディアバッファリング、ピクシレーション（ｐｉｘｉｌａｔｉｏｎ）などと関連した問題に直接的に影響を受けうる。

不良なネットワーク経路によってこのような問題が発生しないように、ＭＭＴＰプロトコルは、多重経路機能により拡張できる。送信機と受信機の間に多重ネットワークインタフェースを用いる多重伝送接続を設定でき、これを介してデータを宛先に迅速かつ安定的に送信できる。また、ＭＭＴ送信機は、ＭＭＴ受信機のフィードバックに基づいて、ＭＭＴ送信機が１つ以上の可能なネットワーク経路が不調であると確認した場合、ネットワーク経路を動的に変更できる。

図５は、本開示に係るＭＭＴにおける多重経路伝達のための例示的な構造図５００を示す。複数の伝送接続５０５，５１０，５１５，及び５２０を、サーバ２００及びクライアント３００で利用可能な異なるネットワークインタフェースを用いて、サーバ（例：ＭＭＴ送信機）２００とクライアント装置（例：ＭＭＴ受信機）３００との間にセットアップできる。マルチメディアデータストリームの異なるパケットフロー（例：他のタイプのデータパケット）５２５，５３０，５３５，及び５４０を、データ伝送に使用できる様々なネットワークインタフェース（例：経路）を用いて、異なる伝送接続ら５０５，５１０，５１５，及び５２０にて伝送できる。１つのネットワーク接続（例：１つの経路）５０５がセッション実行中に適切に動作しないと、他のネットワーク接続（例：他の経路）５１０を、後続のパケット伝達のために選択できる。結果として、１つのネットワーク経路の性能低下が全般的なメディア伝送品質に影響を及ぼさないので、エンドユーザエクスペリエンスに悪影響を及ぼさない。

多重経路伝達によって、サーバ２００からクライアント装置３００に又はその反対にマルチメディアデータを送信するために多重ネットワーク経路を用いることができる。多重ネットワーク経路が利用可能となることによって、より多くのマルチメディアデータを同じ時間内に宛先に転送できる。結果として、データ伝送に使用できる最終（ｎｅｔ）帯域幅は、個別ネットワーク経路の帯域幅に比べて高い。上記のように、多重経路に対するセッション管理にはＲＴＳＰシグナリングプロトコルを用いることができる。例えば、クライアント装置３００及びサーバ２００は、ＯＰＴＩＯＮＳ要求を互いに送信することによって、多重経路機能をサポートしているかを互いに発見できる。サーバ２００及びクライアント装置３００の両方がＯＰＴＩＯＮＳ要求を生成できるため、ＯＰＴＩＯＮＳ要求は、多重経路機能をサポートしているか否かについて問い合わせするための良い候補モードとなる。“ｍｕｌｔｉｐａｔｈ”という新たなオプションタグは、ＩＡＮＡ（ｉｎｔｅｒｎｅｔａｓｓｉｇｎｅｄｎｕｍｂｅｒａｕｔｈｏｒｉｔｙ）に登録でき、ＯＰＴＩＯＮＳ要求の“ｒｅｑｕｉｒｅ”ヘッダにて適用できる。以下は、多重経路のサポートについて問い合わせるクライアント装置３００からサーバ２００への簡単なＯＰＴＩＯＮＳ要求の例である。

ＯＰＴＩＯＮＳ要求に対するサーバ２００の応答は、［［３］］に提示されたように標準応答メカニズムに従う。

サーバ２００は、上記のＯＰＴＩＯＮＳ要求を、クライアント装置３００からの多重経路のサポートについて問い合わせるために生成でき、クライアント装置３００は、適切な応答により応答できる。要求と応答は、上記にて言及された新しく提案されたオプションタグである“ｍｕｌｔｉｐａｔｈ”をサポートする［［３］］に規定された標準ＯＰＴＩＯＮＳ要求応答メカニズムに従う。クライアント装置３００及びサーバ２００は、上記のようにして、多重経路機能を有するセッションのセットアップを開始できる。しかし、サーバ２００及びクライアント装置３００のいずれもが多重経路を用いないことに決定すると、［［３］］で提示されたように標準セッションのセットアップ手順を続けることができる。

実施形態において、セッションは、クライアント装置（例：ＭＭＴクライアント装置）３００とサーバ（例：ＭＭＴサーバ）２００の間に多重経路機能を用いて確立できる。図６は、本開示に係るＲＴＳＰを用いるＭＭＴセッションのセットアップの例示的な方法６００を示す。過程６０５にて、クライアント装置３００は、サーバ２００からＵＲＬ記述を要求する。クライアント装置３００は、セッションレベル固有識別子を示す“ＭｕｌｔｉｐａｔｈＩｄ”という新たなヘッダを含ませ、サーバがクライアント装置３００からの同じ多重経路セッションに属する全ての接続を識別できるようにする。ＤＥＳＣＲＩＢＥの例は下記の通りである。

上述のように、多重経路識別子を有するＤＥＳＣＲＩＢＥ要求に対して、過程６１０にて、サーバ２００は、“ｍｕｌｔｉｐａｔｈ”と呼ばれる新たな属性を有するＳＤＰでサーバ２００が多重経路伝達をサポートすることをクライアント装置３００に知らせることができる。ｍｕｌｔｉｐａｔｈ属性のシンタックス（ｓｙｎｔａｘ）は下記の通りである。

上記ＳＤＰに示すように、メディアディスクリプション（ｍｅｄｉａｄｅｓｃｒｉｐｔｉｏｎ）には、各ネットワークインタフェースに対する接続情報だけでなく、各ネットワークインタフェースに対する当事者が受信しようとするデータタイプも含まれる。また、各メディアディスクリプションに対するＳＤＰ“ｃｏｎｔｒｏｌ”属性は、“ｓｔｒｅａｍｉｄ”パラメータで表示されるストリームｉｄを、メディアラインに指定されたメディアフォーマット（例：ペイロードタイプ）にバインドする。クライアント装置３００が情報を判読する時、クライアント装置３００は、対応する“ｃｏｎｔｒｏｌ”属性で識別された各々のストリームｉｄにどのアセットタイプ（ペイロードタイプのようなメディアフォーマット技術によって指定されたアセットタイプ）が提供できるかを決定する。結果として、クライアント装置３００は、与えられたアセットタイプに対してどのストリームｉｄを要求するかを決定し、当該ストリームｉｄをＳＥＴＵＰ要求の要求ＵＲＬに用いる。多重経路伝達によって、クライアント装置３００は、クライアント装置３００選択のネットワークインタフェースからＳＥＴＵＰ要求を生成しなければならない。ＳＥＴＵＰ要求は、どのネットワークインタフェースによりどのアセットタイプが送信されるべきであるかを選択するポリシーによって管理される。結果として、ＵＲＬと結びつけられた選択されたネットワークインタフェース（特定のアセットタイプに対応する上記説明されたストリームｉｄ情報を含む）は、特定のネットワークインタフェースでの特定のアセットタイプに対する要求を生成するために、クライアント装置３００によって用いられる。これは、特定タイプのデータ（例：高画質ビデオ）とともに、特定の種類のネットワークインタフェース（例：より高い帯域幅のＷｉＦｉ接続）を用いる追加的な長所を提供する。

クライアント装置３００は、サーバ２００から受信された多重経路ＳＤＰに基づいて、他のネットワークインタフェースを用いてサーバ（例：ＭＭＴサーバ）２００に対する多重接続（例：ネットワーク経路）をセットアップできる。例えば、過程６１５、６２５及び６３５にて、クライアント装置３００は、ＳＥＴＵＰメッセージを用いて各々のネットワーク経路をセットアップする。各々のＳＥＴＵＰ要求で、クライアント装置３００は、クライアント装置３００がメディアを受信することを望む経路を指定する伝送パラメータ（例：プロファイル、宛先アドレス、クライアントポート）を含む。また、クライアント装置３００は、サーバ２００に対する各々のＳＥＴＵＰ要求に後に“ＭｕｌｔｉｐａｔｈＩｄ”という新たなヘッダを含む。以後、この“ＭｕｌｔｉｐａｔｈＩｄ”を“クライアント多重経路識別子”と呼ぶことにする。このヘッダフィールドの値は、上記に説明されたＤＥＳＣＲＩＢＥ要求に用いられた“ＭｕｌｔｉｐａｔｈＩｄ”ヘッダフィールドの値と同じである。同じ値を用いることにより、クライアント装置３００からのＳＥＴＵＰ要求が初期のＤＥＳＣＲＩＢＥ要求と同じセッションに属するということをサーバ２００に知らせる。また、クライアント装置３００からのクライアント多重経路識別子は、ネットワーク及び伝送パラメータと結びつけられ、クライアント装置３００が後に他のネットワーク経路からのパケットフローをグループ化するために用いることができる。クライアント装置３００及びサーバ２００が多重経路伝達を用いることを望む場合、全てのＳＥＴＵＰ要求は、“ＭｕｌｔｉｐａｔｈＩｄ”ヘッダフィールドを含む。

サーバ２００が各々のＳＥＴＵＰメッセージを受信すると、過程６２０、６３０及び６４０にて、サーバ２００は、自らの伝送パラメータを用いて応答メッセージにより応答して、サーバ２００がメディアを受信しようとする場所を指定する。また、サーバ２００は、サーバ２００によって選択された一意な値である“ＭｕｌｔｉｐａｔｈＩｄ”という新たなヘッダを含む。以後、この“ＭｕｌｔｉｐａｔｈＩｄ”を“サーバ多重経路識別子”と呼ぶことにする。この値は、同じサーバ多重経路識別子を有するサーバ２００からの全ての接続が同じセッションに属することをクライアント装置３００に知らせる。また、サーバ多重経路識別子は、ネットワーク及び伝送パラメータと結びつけられているので、後にサーバ多重経路識別子を用いて他のネットワーク経路のパケットフローをグループ化できる。ＳＥＴＵＰ要求の終わりで、同じクライアント多重経路識別子を有する全てのクライアントＳＥＴＵＰ要求及び同じサーバ多重経路識別子を有するサーバ応答との間で応答を交換し、クライアント装置３００及びサーバ２００は、どのネットワーク経路が同じセッションに属するかを知る。

全てのＳＥＴＵＰ要求応答メッセージが完了すると、過程６４５にて、クライアント装置３００は、ストリームを再生するように要求し、サーバ２００は、他のネットワーク経路を用いてネゴシエーションされた伝送接続上でストリームを再生する。伝送接続パラメータが対応するクライアント多重経路識別子及びサーバ多重経路識別子と結びつけられたので、過程６５０、６５５及び６６０にて、クライアント装置３００及びサーバ２００は、他のネットワーク経路にてパケットフローを受信することができ、他のネットワーク経路のフローをグループ化し相関させることができる。

実施形態で、クライアント装置（例：ＭＭＴクライアント装置）３００及びサーバ２００は、セッションの確立中に、多重経路に対するサポートを可能又は不可能にすることができる。また、クライアント装置３００又はサーバ２００は、既に多重経路を用いている場合、セッションの確立中に、ネットワーク経路を追加又は削除できる。クライアント装置３００又はサーバ２００は、セッションの確立中に、多重経路サポートを開始することを望む場合、多重経路機能を使用せず、ＲＴＳＰシグナリングプロトコルを用いて、パケットデータ交換のための伝送接続（ＴＣＰ又はＵＤＰ）を開くことができる。クライアント装置３００が多重経路を開始するために、クライアント装置３００は、上記で論議されたように、サーバの多重経路機能を検査するためにＯＰＴＩＯＮＳ要求を発行できる。多重経路機能についてサーバからの肯定応答を受信すると、クライアント装置３００は、上記したように、多重経路を可能にするために変更された伝送パラメータにて新たなＳＥＴＵＰ要求を発行できる（現存するストリームを終了する必要がなく、ストリームの伝送パラメータを変更するために明示的に再度開放される必要がない［［３］］）。しかし、新たなインタフェースを用いようとする場合、“ＭｕｌｔｉｐａｔｈＩｄ”ヘッダとともに、当該新たなインタフェースから新たなＳＥＴＵＰ要求が送信される。このヘッダの値は、他の接続で用いられるクライアント多重経路識別子と同じである。

サーバ２００が多重経路を開始するために、サーバ２００は、ＯＰＴＩＯＮＳ要求をクライアント装置に送信することによって、多重経路機能を検査できる。サーバ２００は、ＡＮＮＯＵＮＣＥメッセージを送信して、ｍｕｌｔｉｐａｔｈ属性を有するＳＤＰを用いて多重経路機能を特定するためのメディア記述を修正する。クライアント装置３００が多重経路を用いることを選択した場合、クライアント装置３００は、上記のように、多重経路伝達を可能にするために複数のＳＥＴＵＰ要求を送信できる。

実施形態で、クライアント装置３００又はサーバ２００のいずれかが既に多重経路サポートを用いている場合、クライアント装置３００及びサーバ２００はネットワーク経路を追加又は削除できる。例えば、クライアント装置３００は、伝送パラメータを有する新たなＳＥＴＵＰ要求を送信し、ヘッダフィールド“Ｍｕｌｔｉｐａｔｈ”に対して同じ値を用いて現存する多重経路接続に新たなネットワーク経路を追加する。また、クライアント装置３００は、［［３］］で規定された対応するＳＥＴＵＰ要求に対するＴＥＡＲＤＯＷＮ要求を発行することによって、ネットワーク経路を削除できる。クライアント装置３００がまもなく終了するネットワーク経路のパケットフローを他のネットワーク経路にて伝送しようとする場合、クライアント装置３００は、他のネットワーク経路に対する変更されたＳＥＴＵＰ要求を用いてこれを実行できる。他の例として、サーバ２００は、新たなＳＤＰを通知し、その後、変更されたＳＤＰに基づいて接続を設定するようにクライアント装置３００に要求することによって、ネットワーク経路を追加又は削除できる。

クライアント装置３００及びサーバ２００は、セッションの確立中に多重経路サポートを中断させることができる。クライアント装置３００は、現存する全てのネットワーク経路を切断し（ｔｅａｒｉｎｇｄｏｗｎ）、［［３］］で規定されたように新たなＳＥＴＵＰ要求を発行することによって、多重経路サポートを中断させることができる。クライアント装置３００は、１つの接続を除く全ての接続を終了し変更されたＳＥＴＵＰ要求を用いて残りの接続を変更してもよい。サーバ２００は、ＡＮＮＯＵＮＣＥメッセージにて（“ｍｕｌｔｉｐａｔｈ”属性を有さない）変更されたＳＤＰを用いて、多重経路サポートを中断できる。多重経路サポートを用いて設定された多重ネットワーク経路は、［［３］］に記述された単一セッション終了メカニズムに従って１つずつ切らなければならない。

多重経路に対するサポートは、クライアント装置３００とサーバ２００との間で相互に排他的である。換言すれば、クライアント装置３００及びサーバ２００は、他の装置が多重経路伝達を用いるのが好ましいか否かに関係なく、多重経路を実現できる。クライアント装置３００又はサーバ２００のいずれかが、多重インタフェースを有さないか、又は、多重経路伝達機能を用いることを望まない場合、クライアント装置３００及びサーバ２００は、送信メッセージに“ＭｕｌｔｉｐａｔｈＩｄ”ヘッダフィールドを含める必要がない。しかし、他の装置が“ＭｕｌｔｉｐａｔｈＩｄ”ヘッダを含めた場合、多重経路を用いない装置は、他の装置が多重経路サポートを要求することを識別できなければならないので、他の装置の多重インタフェースにパケットデータをストリーミング可能でなければならない。

上記のように、データ伝達のための多重経路をセットアップすると、ＭＭＴ送信機は、多重経路を用いてデータをＭＭＴ受信機に送信できる。受信機が多重経路からデータを受信する時、受信機は、ネットワーク経路レベルでＱｏＳ及びＱｏＥ測定値（パケット損失、遅延、ジッタ等）を計算できる。これを可能にするために、パケットが受信機に到達する前、（ＭＭＴ送信機又は経路中の中間ノードにおいて）パケットに対してノード又は経路の情報をスタンプする（ｓｔａｍｐ）処理を実行できる。ＭＭＴ受信機は、予め決定された間隔で、フローごと又はネットワークごとに経路ＱｏＳ及びＱｏＥ測定値（経路品質情報）を計算でき、経路品質情報を任意のチャネル品質情報（例：ＬＴＥリンク上のリンク無線品質）とともにＭＭＴ送信機に送信できる。

図７は、本開示に係る複数のネットワーク経路の各々に対する受信機フィードバックのダイヤグラム７００の例を示す。図７は、各ネットワーク経路に対する３つのメトリック（損失、遅延及びジッタ）を示す。しかし、受信機フィードバックは、各ネットワーク経路に対してより多くのＱｏＳ及びＱｏＥメトリックを含むように拡張できる。ＭＭＴ規格は、受信機フィードバックに対するサポートを含むことができる。一実施形態で、受信機フィードバックは、ネットワーク経路レベルで実行できる。受信機フィードバックの結果として、ＭＭＴ送信機は、他のネットワーク経路の状態を認識するようになる。

ＭＭＴ受信機フィードバックによって、ＭＭＴ送信機は、両当事者間の互いに異なるネットワーク経路の状態を完全に把握できる。送信機は、フローごと（ネットワーク経路ごと）のＱｏＳ及びＱｏＥ測定値を用いてネットワーク経路を動的に変更できるため、よりパフォーマンスのよい他のネットワーク経路を介してパケットフローをルーティングできる。特定のメディアタイプに対するネットワーク経路の決定は、パケットが未処理（ｒａｗ）データから生成される時リアルタイムに発生する。結果として、パケットは、より良い特性を有するネットワーク経路上の宛先に伝達され、受信機への最適又は改善された伝達を実現できる。アプリケーションが要求する場合、受信機フィードバック及びこのフィードバックに基づく動的経路アップデートが、非常に細分化されたレベル（例：パケット単位）にて実行できることに留意すべきである。

セッションの確立中にパケットフローに対するネットワーク経路を変更できるため、ＳＤＰがネットワーク経路に結びつけられたメディアタイプを有することを原因として、ＳＤＰと同期されなくなる。この問題を解決するために、ＭＭＴ送信機及びＭＭＴ受信機は、パケットフローが新たなネットワーク経路上に実際に送信される前に、上記のように、伝送パラメータ及びネットワーク経路を変更するために中間セッション（ｍｉｄ−ｓｅｓｓｉｏｎ）の変更を開始できる。一実施形態で、ネットワーク経路に対する変更は、ネットワーク経路に対する頻繁な変更をできうる限り抑制するために、適切なしきい値を用いて実行できる。

多重経路は、反復ＤＥＳＣＲＩＢＥメッセージを用いてセットアップできる。上記のように、“ＭｕｌｔｉｐａｔｈＩｄ”ヘッダフィールドを、ＤＥＳＣＲＩＢＥメッセージに含めることができる。クライアント装置３００がＤＥＳＣＲＩＢＥ要求を送る前にＯＰＴＩＯＮＳ要求を用いてサーバ２００の多重経路機能について問い合わせなかった場合であっても、クライアント装置３００及びサーバ２００は、初期のＤＥＳＣＲＩＢＥ要求後に、多重経路にアップグレードできる。例えば、クライアント装置３００は、［［３］］で規定されたように、標準ＲＴＳＰセッションを設定するために、“ＭｕｌｔｉｐａｔｈＩｄ”ヘッダを有しないＤＥＳＣＲＩＢＥ要求を用いて、メディアディスクリプションをサーバ２００に要求できる。サーバ２００は、ボディーディスクリプション（“ｍｕｌｔｉｐａｔｈ”属性を有さないＳＤＰ）を有する標準応答で応答する。その後、クライアント装置３００は、多重経路を使用しようとする。クライアント装置３００は、上記のように、ＯＰＴＩＯＮＳ要求を用いて多重経路機能についてサーバ２００に問い合わせできる。多重経路機能についての肯定応答を受信すると、クライアント装置３００は“ＭｕｌｔｉｐａｔｈＩｄ”ヘッダフィールドを有する新たなＤＥＳＣＲＩＢＥ要求を送信できる。この結果、クライアント装置３００及びサーバ２００は、上記のように、多重経路伝達を続けることができる。

また、多重経路をサーバ通知に基づいてセットアップできる。上記のように、“ＭｕｌｔｉｐａｔｈＩｄ”ヘッダフィールドは、ＤＥＳＣＲＩＢＥメッセージに含めることができる。クライアント装置３００がＤＥＳＣＲＩＢＥ要求を送る前にＯＰＴＩＯＮＳ要求を用いてサーバ２００の多重経路機能について問い合わせなかった場合であっても、クライアント装置３００及びサーバ２００は、初期のＤＥＳＣＲＩＢＥ要求後に多重経路にアップグレードできる。例えば、クライアント装置３００は、［［３］］で規定されたように、標準ＲＴＳＰセッションを設定するための“ＭｕｌｔｉｐａｔｈＩｄ”ヘッダを有しないＤＥＳＣＲＩＢＥ要求を用いてメディアディスクリプションをサーバ２００に要求する。サーバ３００は、ボディーディスクリプション（“ｍｕｌｔｉｐａｔｈ”属性を有さないＳＤＰ）を有する標準応答で応答する。その後、クライアント装置３００は、多重経路を使用しようとする。クライアント装置３００は、上記のように、ＯＰＴＩＯＮＳ要求を用いて多重経路機能についてサーバ２００に問い合わせることができる。サーバ２００は、ＡＮＮＯＵＮＣＥメッセージを用いて新たなＳＤＰを通知できる。多重経路機能及び新たなＳＤＰについて肯定応答を受信すると、クライアント装置３００は、各々のＳＥＴＵＰ要求に“ＭｕｌｔｉｐａｔｈＩｄ”ヘッダフィールドを含めて、複数のＳＥＴＵＰ要求の送信を開始できる。クライアント装置３００及びサーバ２００は、上記のように、多重経路伝達を進める。

サーバ２００は、多重経路を開始できる。上記のように、“ＭｕｌｔｉｐａｔｈＩｄ”ヘッダフィールドを、ＤＥＳＣＲＩＢＥメッセージに含めることができる。クライアント装置３００は、ＤＥＳＣＲＩＢＥ要求を送る前に、ＯＰＴＩＯＮＳ要求を用いてサーバ２００の多重経路機能について問い合わせなかった場合であっても、初期ＤＥＳＣＲＩＢＥ要求がサーバ２００に送信されサーバ２００が多重経路セットアップを開始した後であっても、クライアント装置３００及びサーバ２００は、多重経路伝達に関与できる。例えば、クライアント装置３００は、［［３］］に規定された標準ＲＴＳＰセッションを設定するために、“ＭｕｌｔｉｐａｔｈＩｄ”を有しないＤＥＳＣＲＩＢＥ要求を用いてメディアディスクリプションをサーバ２００に要求する。クライアント装置３００が“ＭｕｌｔｉｐａｔｈＩｄ”ヘッダを特定していないことを知った場合でも、サーバ２００は、“ｍｕｌｔｉｐａｔｈ”ＳＤＰ属性を含むＳＤＰにより応答できる。また、サーバ２００は、ＤＥＳＣＲＩＢＥ要求に応じてサーバ多重経路識別子の値を送信できる。クライアント装置３００は、サーバ２００が特定された多重経路機能を有することを確認する。クライアント装置３００は、上記のように、多重接続の設定を開始することができる。第１ＳＥＴＵＰメッセージから開始することにより、クライアント装置３００は、“ＭｕｌｔｉｐａｔｈＩｄ”ヘッダフィールドにクライアント多重経路識別子値を含めることを開始でき、上記のように多重経路の使用へと進むことができる。

ＨＴＴＰは、多重経路セッションを設定するためのシグナリング（ｓｉｇｎａｌｉｎｇ）プロトコルとして用いることができる。上記のように、ＲＴＳＰは、多重経路セッションを設定するためのシグナリングプロトコルとして用いられる。その他、ＨＴＴＰを、多重経路セッションを設定するためのシグナリングプロトコルとして用いることができる。図８は、本開示に係るＨＴＴＰプロトコルを用いるＭＭＴセッションセットアップの例示的な方法８００を示す。過程８０５にて、クライアント装置３００は、［［１１］］に規定されたように、ウェブソケット（ＷｅｂＳｏｃｋｅｔ）接続へのＨＴＴＰアップグレードを用いて、サーバ２００からＭＭＴパッケージをダウンロードする。アップグレード要求の一部として、クライアント装置３００は、クライアント装置３００が多重経路伝達機能を使用しようとすることをサーバ２００に知らせるために、“ＭｕｌｔｉｐａｔｈＩｄ”ヘッダを含ませる。このヘッダフィールドの値は、クライアント装置３００が全ての後続パケット要求にわたって使用されるクライアント多重経路識別子である。過程８１０にて、サーバ２００は、ウェブソケットへのＨＴＴＰアップグレード受信に応じて、サーバ多重経路識別子値が含まれる“ＭｕｌｔｉｐａｔｈＩｄ”ヘッダを有する応答“２００ＯＫ”をクライアント装置３００に送信する。過程８１５及び８２５に示すように、クライアント装置３００は、多重経路伝達のためにクライアント装置３００が用いる各々のインタフェースに対してウェブソケット接続を用いる。過程８２０及び８３０にて、サーバ２００は、多重経路伝達のためにクライアント３００が用いる各々のインタフェースに対するウェブソケットへのＨＴＴＰアップグレード受信に応じて、サーバ多重経路識別子値を含む“ＭｕｌｔｉｐａｔｈＩｄ”ヘッダを有する応答“２００ＯＫ”をクライアント装置３００に送信する。各々のＧＥＴ要求は“Ｍｕｌｔｉｐａｔｈ”ヘッダフィールドを含むので、サーバ２００は多数の着信ＧＥＴ要求がＭＭＴパケットデータに対する同じセッションの一部であることを知ることができる。ウェブソケットメッセージは、多重経路機能、指定されたネットワークインタフェースに対するアセットタイプのネゴシエーションなどのようなオプションディスカバリ（ｏｐｔｉｏｎｄｉｓｃｏｖｅｒｙ）に用いられる。過程８３５、８４０、及び８４５にて、データは、サーバ２００からクライアント装置３００に各々の経路を介して送信される。

図９は、本開示に係る装置による多重経路データパケット受信のための例示的な過程のフローチャートを示す。

過程９０５にて、装置はサーバにメッセージを送信する。前記メッセージは、多重経路伝送セッションに対応して前記装置の２つ以上のネットワークアクセスインタフェースのグループを示す識別子を含む。装置は、装置の２つ以上のネットワークアクセスインタフェースうち第１ネットワークアクセスインタフェースによってアクセスされる第１ネットワーク経路の１つ以上の第１特性を決定する。装置は、装置の２つ以上のネットワークアクセスインタフェースのうち第２ネットワークアクセスインタフェースによってアクセスされる第２ネットワーク経路の１つ以上の第２特性を決定する。装置は、多重経路伝送セッションの間、装置の２つ以上のネットワークアクセスインタフェースのネットワークアクセスインタフェースがアクセスするネットワーク経路を示す識別子を生成する。

過程９１０にて、装置は、２つ以上のネットワークアクセスインタフェースの１つ以上の特性に基づく多重経路伝送セッションの間、装置の２つ以上のネットワークアクセスインタフェースの任意の組み合わせによってサーバから１つ以上のデータパケットを受信する。装置は後続メッセージをサーバに送信する。後続メッセージは、多重接続伝送セッションに対応して装置の２つ以上のネットワークアクセスインタフェースの後続グループを示す他の識別子を含む。装置の２つ以上のネットワークアクセスインタフェースの後続グループは、前記装置の２つ以上のネットワークアクセスインタフェースのグループと異なる。装置は、多重経路伝送セッションの間、装置の２つ以上のネットワークアクセスインタフェースを介して、サーバから１つ以上の後続データパケットを受信する。装置は、多重経路伝送セッションの確立中に、サーバから１つ以上のデータパケットを受信するための要求を送信することに応じて、多重伝送セッションの確立中に、装置の２つ以上のネットワークアクセスインタフェースの各々を介して、サーバから１つ以上のデータパケットを受信する。

図１０は、本開示に係るサーバによる多重経路データパケット送信のための例示的な過程のフローチャートを示す。

過程１００５にて、サーバは、装置からメッセージを受信する。メッセージは、多重経路伝送セッションに対応し、多重経路伝送セッションの確立中にサーバから１つ以上のデータパケットを受信する装置の２つ以上のネットワークアクセスインタフェースのグループを示す識別子を含む。サーバは、多重経路伝送セッションの確立中、装置からの要求に基づいて１つ以上のデータパケットを送信するために、２つ以上のネットワーク経路の経路選択を制御する。サーバは、装置の２つ以上のネットワークアクセスインタフェースのうち第１ネットワークアクセスインタフェースによってアクセスされる第１ネットワーク経路の１つ以上の第１特性を決定する。サーバは、装置の２つ以上のネットワークアクセスインタフェースのうち第２ネットワークアクセスインタフェースによってアクセスされる第２ネットワーク経路の１つ以上の第２特性を決定する。サーバは、多重経路伝送セッションの確立中、装置の２つ以上のネットワークアクセスインタフェースのネットワークアクセスインタフェースによってアクセスされる２つ以上のネットワーク経路を示す識別子を生成する。

過程１０１０にて、サーバは、多重経路伝送セッションの確立中、装置の２つ以上のネットワークアクセスインタフェースに対応する２つ以上のネットワーク経路を介して、装置に１つ以上のデータパケットを送信する。サーバは、２つ以上のネットワーク経路の受信された特性に基づいて、２つ以上のネットワーク経路の各々を介して、装置に１つ以上のデータパケットを送信する。サーバは、他のメッセージを装置に送信する。他のメッセージは、サーバが２つ以上のネットワーク経路を介して１つ以上のデータパケットの伝送をサポートすることを示す。サーバは、多重経路伝送セッションに対する要求を受信する。サーバは、多重経路伝送セッションの確立中、サーバの２つ以上のネットワークアクセスインタフェース及び装置の２つ以上のネットワークアクセスインタフェースの各々を介して、１つ以上のデータパケットを装置に送信する。サーバは、サーバに対する後続メッセージを受信する。後続メッセージは、多重経路伝送セッションに対応して装置の２つ以上のネットワークアクセスインタフェースの後続グループを示す他の識別子を含む。２つ以上のネットワークアクセスインタフェースの後続グループは、前記２つ以上のネットワークアクセスインタフェースのグループと異なる。サーバは、多重経路伝送セッションの確立中、装置の２つ以上のネットワークアクセスインタフェースの各々を介して、１つ以上の後続データパケットを装置に送信する。

本開示は、例示的な実施形態で説明されたが、多様な変更例及び修正例が当業者に提案されることができる。本開示は、添付された請求範囲の範囲内に属するかかる変更及び修正例らを含むことが意図される。

Claims

多重経路データパケット受信のための装置の制御方法であって、
多重経路伝送セッションに対応して前記装置の２つ以上のネットワークアクセスインタフェースのグループを指示する識別子を含むメッセージをサーバに送信する過程と、
前記２つ以上のネットワークアクセスインタフェースの少なくとも１つの特性に基づいて、前記多重経路伝送セッションの確立中に、前記装置の前記２つ以上のネットワークアクセスインタフェースの組み合わせによって前記サーバから少なくとも１つのデータパケットを受信する過程と、を含む方法。
前記装置の前記２つ以上のネットワークアクセスインタフェースのうち、第１ネットワークアクセスインタフェースによってアクセスされる第１ネットワーク経路の少なくとも１つの第１特性を決定する過程と、
前記装置の前記２つ以上のネットワークアクセスインタフェースのうち、第２ネットワークアクセスインタフェースによってアクセスされる第２ネットワーク経路の少なくとも１つの第２特性を決定する過程と、をさらに含む請求項１に記載の方法。
前記多重経路伝送セッションの確立中に、前記装置の前記２つ以上のネットワークアクセスインタフェースのネットワークアクセスインタフェースによってアクセスされるネットワーク経路を指示する識別子を生成する過程をさらに含む請求項１に記載の方法。
後続メッセージをサーバに送信する過程と、
前記多重経路伝送セッションの確立中に、前記装置の前記２つ以上のネットワークアクセスインタフェースの各々を介して前記サーバから少なくとも１つの後続データパケットを受信する過程をさらに含み、
前記後続メッセージは、前記多重経路伝送セッションに対応して前記装置の前記２つ以上のネットワークアクセスインタフェースの前記グループとは異なる前記装置の前記２つ以上のネットワークアクセスインタフェースの後続グループを指示する他の識別子を含む請求項１に記載の方法。
前記多重経路伝送セッションの確立中に、前記サーバから前記少なくとも１つのデータパケットを受信することを命じる要求に応じて、前記多重経路伝送セッションの確立中に、前記装置の前記２つ以上のネットワークアクセスインタフェースの各々を介して前記少なくとも１つのデータパケットを前記サーバから受信する過程をさらに含む請求項１に記載の方法。
多重経路データパケット送信のためのサーバの制御方法であって、
多重経路伝送セッションに対応して前記多重経路伝送セッションの間、前記サーバから少なくとも１つのデータパケットを受信する装置の２つ以上のネットワークアクセスインタフェースのグループを指示する識別子を含むメッセージを前記装置から受信する過程と、
前記多重経路送信セッションの確立中に、前記装置の前記２つ以上のネットワークアクセスインタフェースに対応する２つ以上のネットワーク経路を介して前記少なくとも１つのデータパケットを前記装置に送信する過程と、を含む方法。
前記２つ以上のネットワーク経路の受信された特性に基づいて、前記２つ以上のネットワーク経路の各々を介して前記少なくとも１つのデータパケットを前記装置に送信する過程をさらに含む請求項６に記載の方法。
前記多重経路伝送セッションの確立中に、前記装置からの要求に基づいて、前記少なくとも１つのデータパケットを送信するために前記２つ以上のネットワーク経路の経路選択を制御する過程をさらに含む請求項６に記載の方法。
前記装置に他のメッセージを送信する過程と、
前記多重経路伝送セッションに対する要求を受信する過程と、
前記多重経路伝送セッションの確立中に、前記サーバの前記２つ以上のネットワークアクセスインタフェース及び前記装置の前記２つ以上のネットワークアクセスインタフェースの各々を介して、前記少なくとも１つのデータパケットを前記装置に送信する過程と、をさらに含み、
前記他のメッセージは、前記サーバが前記２つ以上のネットワーク経路を介して前記少なくとも１つのデータパケットの送信をサポートすることを指示する請求項６に記載の方法。
前記装置の前記２つ以上のネットワークアクセスインタフェースのうち第１ネットワークアクセスインタフェースによってアクセスされる第１ネットワーク経路の少なくとも１つの第１特性を決定する過程と、
前記装置の前記２つ以上のネットワークアクセスインタフェースのうち第２ネットワークアクセスインタフェースによってアクセスされる第２ネットワーク経路の少なくとも１つの第２特性を決定する過程と、をさらに含む請求項６に記載の方法。
前記多重経路送信セッションの確立中に、前記装置の前記２つ以上のネットワークアクセスインタフェースのネットワークアクセスインタフェースによってアクセスされる前記２つ以上のネットワーク経路を指示する識別子を生成する過程をさらに含む請求項１０に記載の方法。
後続メッセージを受信する過程と、
前記多重経路送信セッションの確立中に、前記装置の前記２つ以上のネットワークアクセスインタフェースの各々を介して少なくとも１つの後続データパケットを前記装置に送信する過程と、をさらに含み、
前記後続メッセージは、前記多重経路伝送セッションに対応して前記装置の前記２つ以上のネットワークアクセスインタフェースの前記グループとは異なる前記装置の前記２つ以上のネットワークアクセスインタフェースの後続グループを指示する他の識別子を含む請求項６に記載の方法。
多重経路データパケット受信装置であって、前記装置は、請求項１乃至５のいずれか一項に記載の方法を実施するように構成される装置。
多重経路データパケット送信装置であって、前記装置は、請求項６乃至１２のいずれか一項に記載の方法を実施するように構成される装置。