(57)【要約】単一のパケットストリーム内のパケットに対するＱｏＳサービスの差別化を促進する方法およびシステムを開示する。例えば、拡張ＱＣＩ値を用いて、異なる優先度に関連付けられたビデオパケットのサービスを差別化してよい。ベースＱｏＳパラメータの関数であるハイパースペースとしてＱｏＳを定義してよい、ＱｏＳ要件／パラメータのフレキシブルな表示を開示する。ＷＴＲＵは、所望のＱｏＳパラメータを明示的に指定および／または要求してよい。ＷＴＲＵは、１つまたは複数のビデオパケットの、複数のビデオパケットサブストリームへの分割、ビデオパケットサブストリームのマージ、および／または、ビデオパケットサブストリームに含まれたパケットの再順序付けを行うように構成されてよい。送信中のビデオパケット（および／または他のパケット）のタイプに関するより多くの情報をデータ送信ネットワークに公開する技術を利用してよい。
2014527771.tif 000002
【特許請求の範囲】
【請求項１】
差別化されたサービス品質（ＱｏＳ）を異なるタイプのパケットに提供する方法であって、前記方法は、
単一のパケットストリームを受信するステップであって、前記単一のパケットストリームは、第１のパケットタイプおよび第２のパケットタイプを含む、ステップと、
前記単一のパケットストリームに含まれる前記第１のパケットタイプのパケットを、第１のパケットサブストリームに関連付けるステップであって、前記第１のパケットサブストリームは、第１のＱｏＳレベルに関連付けられる、ステップと、
前記単一のパケットストリームに含まれる前記第２のパケットタイプのパケットを、第２のパケットサブストリームに関連付けるステップであって、前記第２のパケットサブストリームは、前記第１のＱｏＳレベルとは異なる第２のＱｏＳレベルに関連付けられる、ステップと、
前記第１のパケットサブストリームおよび前記第２のパケットサブストリームを、パケット送信先に送るステップと、
を備えたことを特徴とする方法。
【請求項２】
前記第１のパケットサブストリームに関連付けられたパケットと、前記第２のパケットサブストリームに関連付けられたパケットとのそれぞれにおいて、前記単一のパケットストリームに対する相対的なパケット順序を表示するステップをさらに備えたことを特徴とする請求項１に記載の方法。
【請求項３】
前記第１のパケットタイプは、第１のネットワーク抽象化層（ＮＡＬ）基準識別（ＮＲＩ）値に関連付けられたＮＡＬユニット（ＮＡＬＵ）であり、および前記第２のパケットタイプは、第２のＮＲＩ値に関連付けられたＮＡＬＵであることを特徴とする請求項２に記載の方法。
【請求項４】
明示的なＱｏＳ要求を、ポリシー制御および課金（ＰＣＣ）エンティティに送るステップをさらに備え、前記明示的なＱｏＳ要求は、前記第１のパケットタイプまたは前記第２のパケットタイプのうちの１つまたは複数に対して、ＱｏＳパラメータの所望の値を含むことを特徴とする請求項１に記載の方法。
【請求項５】
ＱｏＳ応答を前記ＰＣＣエンティティから受信するステップをさらに備え、前記ＱｏＳ応答は、前記ＱｏＳ要求が、受諾、変更、または拒絶されたことを表示することを特徴とする請求項４に記載の方法。
【請求項６】
前記明示的なＱｏＳ要求は、ＱｏＳハイパースペースにおける点または位置として、前記ＱｏＳパラメータの前記所望の値を表示することを特徴とする請求項４に記載の方法。
【請求項７】
前記ＱｏＳハイパースペースは、遅延、パケット誤り率、スループット、または遅延ジッタのうちの１つまたは複数のベースに関連付けられることを特徴とする請求項６に記載の方法。
【請求項８】
前記第１のパケットサブストリームの送信に対する第１のユーザデータグラムプロトコル（ＵＤＰ）ソケットを構築するステップと、前記第２のパケットサブストリームの送信に対する第２のＵＤＰソケットを構築するステップをさらに備えたことを特徴とする請求項１に記載の方法。
【請求項９】
複数のビデオパケットサブストリームを受信するように構成された受信機であって、前記複数のビデオパケットサブストリームは、第１の優先度のビデオパケットをカプセル化したパケットを含む第１のビデオパケットサブストリーム、および第２の優先度のビデオパケットをカプセル化したパケットを含む第２のビデオパケットサブストリームを含む、受信機と、
前記複数のビデオパケットサブストリームをビデオパケットストリームにマージし、
前記ビデオパケットストリームのパケットを、前記パケットに含まれたシーケンス番号またはタイムスタンプのうちの１つまたは複数に基づいて、再順序付けする
ように構成されたプロセッサと、
前記ビデオパケットストリームの前記再順序付けされたパケットを復号化するように構成されたビデオデコーダと
を備えたことを特徴とする無線送受信ユニット（ＷＴＲＵ）。
【請求項１０】
前記プロセッサは、リアルタイムトランスポートプロトコル（ＲＴＰ）エンティティと前記ビデオデコーダとの間に含まれたミドルウェアを介して、前記複数のビデオパケットサブストリームをマージし、前記ビデオパケットストリームの前記パケットを再順序付けするように構成されたことを特徴とする請求項９に記載のＷＴＲＵ。
【請求項１１】
前記シーケンス番号は、リアルタイムトランスポートプロトコル（ＲＴＰ）ヘッダにおけるシーケンス番号フィールドに含まれ、および前記タイムスタンプは、ＲＴＰヘッダのタイムスタンプフィールドに含まれることを特徴とする請求項９に記載のＷＴＲＵ。
【請求項１２】
前記プロセッサは、リアルタイムトランスポートプロトコル（ＲＴＰ）エンティティを介して、前記複数のビデオパケットサブストリームをマージし、および前記ビデオパケットストリームの前記パケットを再順序付けするように構成されたことを特徴とする請求項９に記載のＷＴＲＵ。
【請求項１３】
前記複数のビデオパケットサブストリームは、複数のインターネットプロトコル（ＩＰ）パケットストリームであり、および前記ＩＰパケットストリームに関連付けられた各ＩＰパケットは、前記ＩＰパケットのヘッダのフィールドにおいて、前記ＩＰパケットにカプセル化されたビデオパケットのタイプの表示を含むことを特徴とする請求項９に記載のＷＴＲＵ。
【請求項１４】
前記ＩＰパケットの前記ヘッダの前記フィールドは、差別化サービスコードポイント（ＤＳＣＰ）フィールド、トラフィッククラスフィールド、またはフロー識別フィールドのうちの１つであることを特徴とする請求項１３に記載のＷＴＲＵ。
【請求項１５】
前記第１のビデオパケットサブストリームは、第１のサービス品質（ＱｏＳ）クラス識別子（ＱＣＩ）値に対応する第１のｅｖｏｌｖｅｄパケットシステム（ＥＰＳ）ベアラに関連付けられ、および前記第２のビデオパケットサブストリームは、第２のＱＣＩ値に対応する第２のＥＰＳベアラに関連付けられることを特徴とする請求項９に記載のＷＴＲＵ。
【請求項１６】
前記第１のビデオパケットサブストリームに関連付けられたパケットは、第１のネットワーク抽象化層（ＮＡＬ）ユニットタイプに対応するＮＡＬユニット（ＮＡＬＵ）をカプセル化し、および前記第２のビデオパケットサブストリームに関連付けられたパケットは、第２のＮＡＬユニットタイプに対応するＮＡＬＵをカプセル化することを特徴とする請求項９に記載のＷＴＲＵ。
【請求項１７】
送信機をさらに備え、
前記プロセッサは、
送信されることになる第２のビデオストリームを、複数の送信ビデオサブストリームに分割し、前記複数の送信ビデオサブストリームは、第１の決定された優先度のパケットに関連付けられた第１の送信ビデオサブストリームと、第２の決定された優先度のパケットに関連付けられた第２の送信ビデオサブストリームとを含み、
前記第１の送信ビデオサブストリームに含まれるパケットおよび前記第２の送信ビデオサブストリームに含まれるパケットに、シーケンス番号またはタイムスタンプのうちの１つまたは複数を付加し、前記シーケンス番号またはタイムスタンプのうちの前記１つまたは複数は、前記第２のビデオストリームに含まれる他のパケットに対する送信パケットの相対的順序を表示する
ようにさらに構成され、
前記送信機は、前記複数の送信ビデオサブストリームを送信するように構成されたことを特徴とする請求項９に記載のＷＴＲＵ。
【請求項１８】
ポリシー課金およびルール機能（ＰＣＲＦ）であって、前記ＰＣＲＦは、
サービス品質（ＱｏＳ）要求を無線送受信ユニット（ＷＴＲＵ）から受信し、前記ＱｏＳ要求は、１つまたは複数の要求ＱｏＳパラメータを含み、
前記ＷＴＲＵに適用可能なサブスクリプション情報を決定し、
前記１つまたは複数の要求ＱｏＳパラメータと、前記ＷＴＲＵに適用可能な前記サブスクリプション情報とに基づいて、前記ＱｏＳ要求を受諾、変更、および／または拒絶するか否かを決定し、
前記ＱｏＳ要求が受諾、変更、および／または拒絶されたか否かを表示するメッセージを前記ＷＴＲＵに送る
よう構成されたプロセッサを備えたことを特徴とするＰＣＲＦ。
【請求項１９】
前記プロセッサは、パケットゲートウェイ（Ｐ−ＧＷ）またはポリシー課金および施行機能（ＰＣＥＦ）のうちの１つまたは複数に、前記１つまたは複数の要求ＱｏＳパラメータの表示を送るようにさらに構成されたことを特徴とする請求項１８に記載のＰＣＲＦ。
【請求項２０】
前記１つまたは複数の要求ＱｏＳパラメータは、前記ＷＴＲＵに対してｅｖｏｌｖｅｄパケットシステム（ＥＰＳ）ベアラを確立することを特徴とする請求項１８に記載のＰＣＲＦ。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、パケットを差別化する方法およびシステムに関する。
【背景技術】
【０００２】
ビデオを生成、表示することができるスマートフォンの導入が加速するにつれ、高速データ通信システムを介してビデオを効果的、効率的にトランスポートすることの重要性が増してきた。ビデオ送信は、ネットワークリソースの集約的使用、一定のデータの損失への耐性、他のデータの損失への不耐性、および／または、一定の状況（例えば、ビデオ会議の場合）では厳しい待ち時間要件などに特徴がある。無線通信技術は、無線帯域幅を劇的に増加させ、モバイル装置ユーザに対するサービス品質を向上させたが、高解像度（ＨＤ）ビデオコンテンツなどのビデオコンテンツに対する需要が急速に高まり、ビデオコンテンツのプロバイダ、配信元、スマートフォンメーカー、および／または、キャリアサービスプロバイダに新たな課題をもたらしている。
【発明の概要】
【０００３】
異なるタイプのパケットに対して差別化されたサービス品質（ＱｏＳ）を提供するシステム、方法を開示する。例えば、パケットストリームのＱｏＳサービスを差別化する方法は、単一のパケットストリームを受信するステップを含んでよい。単一のパケットストリームは、第１のパケットタイプと第２のパケットタイプを含んでよい。方法は、単一のパケットストリームに含まれた第１のパケットタイプのパケットを第１のパケットサブストリームに関連付けるステップを含んでよい。第１のパケットサブストリームは、第１のＱｏＳレベルに関連付けられてよい。方法は、単一のパケットストリームに含まれた第２のパケットタイプのパケットを第２のパケットサブストリームに関連付けるステップを含んでよい。第２のパケットサブストリームは、第１のＱｏＳレベルと異なる第２のＱｏＳレベルに関連付けられてよい。方法は、第１のパケットサブストリームと第２のパケットサブストリームをパケットの送信先に送るステップを含んでよい。
【０００４】
ＱｏＳサービスを差別化する方法およびシステムは、第１のパケットサブストリームに関連付けられたパケットと第２のパケットサブストリームに関連付けられたパケットのそれぞれにおいて、前記単一のパケットストリームに対する相対的なパケットの順序を示すことをさらに含んでよい。一例では、パケットは、ビデオパケットであってよい。例えば、第１のパケットタイプは、第１のネットワーク抽象化層（ＮＡＬ）の基準識別（ＮＲＩ）値に関連付けられたＮＡＬユニット（ＮＡＬＵ）であってよく、第２のパケットタイプは、第２のＮＲＩ値に関連付けられたＮＡＬＵであってよい。
【０００５】
ＷＴＲＵは、パケットを分割し、送信するように構成されてよい。例えば、ＷＴＲＵは、送信する第２のビデオストリームを複数のビデオサブストリームに分割するように構成されたプロセッサを含んでよい。該複数の送信サブストリームは、第１の優先度に決定されたパケットに関連付けられた第１のビデオサブストリームと、第２の優先度に決定されたパケットに関連付けられた第２のビデオサブストリームを含んでよい。プロセッサは、第１のビデオサブストリームに含まれたパケットと第２のビデオサブストリームに含まれたパケットに、シーケンス番号またはタイムスタンプの１つまたは複数を加えるように、さらに構成されてよい。シーケンス番号またはタイムスタンプの１つまたは複数は、第２のビデオストリームに含まれた他のパケットに対する送信パケットの相対的順序を示してよい。ＷＴＲＵは、複数のビデオサブストリームを送信するように構成された送信機を含んでよい。
【０００６】
パケット差別化の方法の例は、明示的なＱｏＳ要求をポリシー制御および課金（ＰＣＣ）エンティティ）に送信するステップをさらに含んでよい。明示的なＱｏＳ要求は、第１のパケットタイプまたは第２のパケットタイプの１つまたは複数に関して、所望の値のＱｏＳパラメータを含んでよい。ＱｏＳ応答は、ＰＣＣエンティティから受信してよい。ＱｏＳ応答は、ＱｏＳ要求が受諾、一部変更、または、拒絶されたことを示してよい。一例では、明示的なＱｏＳ要求は、ＱｏＳハイパースペースの位置として、ＱｏＳパラメータの所望の値を示してよい。ＱｏＳハイパースペースは、遅延、パケット誤り率、スループット、ジッタなどの１つまたは複数のベースと関連付けてよい。一例では、第１のパケットサブストリーム送信のための第１のユーザデータグラムプロトコル（ＵＤＰ）ソケットを構築してよく、第２のパケットサブストリーム送信のための第２のＵＤＰソケットを構築してよい。
【０００７】
無線送受信ユニット（ＷＴＲＵ）は、パケットサブストリームを送信および／または受信するように構成されてよい。例えば、ＷＴＲＵは、複数のビデオパケットサブストリームを受信してよい。複数のビデオパケットサブストリームは、第１の優先度のビデオパケットをカプセル化しているパケットを含む第１のビデオパケットサブストリームと、第２の優先度のビデオパケットをカプセル化しているパケットを含む第２のビデオパケットサブストリームとを含んでよい。ＷＴＲＵは、複数のビデオパケットサブストリームをマージしてビデオパケットストリームにするように構成されてよい。ＷＴＲＵは、パケットに含まれたシーケンス番号またはタイムスタンプの１つまたは複数に基づいて、ビデオパケットストリームのパケットを再順序付けするよう構成されてよい。ＷＴＲＵは、ビデオパケットストリームの再順序付けされたパケットを復号化するように構成されたビデオデコーダを含んでよい。一例では、シーケンス番号は、リアルタイムトランスポートプロトコル（ＲＴＰ）ヘッダのシーケンス番号フィールドに含まれてよく、タイムスタンプは、ＲＴＰヘッダのタイムスタンプフィールドに含まれてよい。
【０００８】
ＷＴＲＵは、リアルタイムトランスポートプロトコル（ＲＴＰ）エンティティとビデオデコーダの間に含まれるミドルウェアを介して、複数のビデオパケットサブストリームをマージし、ビデオパケットストリームのパケットを再順序付けするように構成されてよい。ＷＴＲＵは、ＲＴＰエンティティを介して、複数のビデオパケットサブストリームをマージし、ビデオパケットストリームのパケットを再順序付けするように構成されてよい。一例においては、複数のビデオパケットサブストリームは、複数のインターネットプロトコル（ＩＰ）パケットストリームであってよい。ＩＰパケットストリームに関連付けられた各ＩＰパケットは、該ＩＰパケットにカプセル化されたビデオパケットのタイプを示すものをＩＰパケットのヘッダのフィールドに含んでよい。例えば、ＩＰパケットのヘッダのフィールドは、差別化サービスコードポイント（ＤＳＣＰ）フィールド、トラフィッククラスフィールド、または、フロー識別フィールドの１つまたは複数であってよい。第１のビデオパケットサブストリームは、第１のＱｏＳクラス識別子（ＱＣＩ）の値に対応する第１の進化型（ｅｖｏｌｖｅｄ）パケットシステム（ＥＰＳ）ベアラに関連付けられてよく、第２のビデオパケットサブストリームは、第２のＱＣＩ値に対応する第２のＥＰＳベアラに関連付けられている。第１のビデオパケットサブストリームに関連付けられたパケットは、第１のＮＡＬユニットタイプに対応するＮＡＬＵをカプセル化し、前記第２のビデオパケットサブストリームに関連付けられたパケットは、第２のＮＡＬユニットタイプに対応するＮＡＬＵをカプセル化する。
【０００９】
ポリシー課金およびルール機能（ＰＣＲＦ）は、ＷＴＲＵからＱｏＳ要求を受信するよう構成されてよい。ＱｏＳ要求は、１つまたは複数の要求ＱｏＳパラメータを含んでよい。ＰＣＲＦは、ＷＴＲＵに適用可能なサブスクリプション情報を決定してよい。例えば、ＰＣＲＦは、加入者プロファイルリポジトリ（ＳＰＲ）にサブスクリプション情報を要求することによって、ＷＴＲＵに適用可能なサブスクリプション情報を決定してよい。ＰＣＲＦは、１つまたは複数の要求ＱｏＳパラメータ、および、ＷＴＲＵに適用可能なサブスクリプション情報に基づいて、ＱｏＳ要求の受諾、一部変更、および／または、拒絶を決定してよい。ＰＣＲＦは、ＱｏＳ要求の受諾、一部変更、および／または、拒絶を示すメッセージをＷＴＲＵに送ってよい。ＰＣＲＦは、１つまたは複数の要求ＱｏＳパラメータを示すものをポリシー課金および施行機能（ＰＣＥＦ）に送ってよい。例えば、ＰＣＥＦは、パケットデータネットワークゲートウェイ（ＰＤＮ−ＧＷまたはＰ−ＧＷ）に含まれてよい。一例においては、１つまたは複数の要求ＱｏＳパラメータを用いて、ＷＴＲＵのためにＥＰＳベアラを確立してよい。
【図面の簡単な説明】
【００１０】
図面と共に例を挙げて示した下記の記載より、より詳細な理解が得られよう。
【図１Ａ】１つまたは複数の開示の実施形態を実施可能な通信システムの例を示す系統図である。
【図１Ｂ】図１Ａに記載の通信システム内で使用可能な無線送受信ユニット（ＷＴＲＵ）の例を示す系統図である。
【図１Ｃ】図１Ａに記載の通信システム内で使用可能な無線アクセスネットワークの例とコアネットワークの例を示す系統図である。
【図１Ｄ】図１Ａに記載の通信システム内で使用可能な無線アクセスネットワークの別の例とコアネットワークの例を示す系統図である。
【図１Ｅ】図１Ａに記載の通信システム内で使用可能な無線アクセスネットワークの別の例とコアネットワークの例を示す系統図である。
【図２】複数のパケットサブストリームをトランスポートすることができるシステムを示す系統図の例である。
【図３】最大パケット誤り率、最大許容遅延、および、最小の所望スループットのアトミックＱｏＳパラメータの例に基づいたハイパースペースの例である。
【図４】ＷＴＲＵによるＱｏＳ要求を用いて、ＥＰＳベアラを確立するプロセスの例である。
【図５】ミドルウェアモジュールを用いた、ビデオパケットの分割、マージ、および／または、再順序付けのためのプロトコルスタックの例である。
【図６】ミドルウェアによるアプローチを用いた、ビデオパケットの分割、マージ、および／または、再順序付けの手順の例である。
【図７】ビデオパケットの分割、ビデオパケットのマージ、および／または、ビデオパケットの再順序付けの１つまたは複数を行うために、ＲＴＰを強化するアプローチの例である。
【図８】ＲＴＰビデオプロファイルのアプローチを用いた、ビデオトラフィックの分割、マージ、および／または、再順序付けの手順の例である。
【図９】ＩＰパケットが、ビデオパケットの分割、マージ、および／または、再順序付けの１つまたは複数に用いられる情報を含んでよいアプローチである。
【発明を実施するための形態】
【００１１】
様々な図を参照して、例示の実施形態を詳しく説明する。この説明は可能な実施例を詳しく述べるが、詳細は例示的なものであって、本出願の範囲を制限するためのものではない。
【００１２】
図１Ａは、１つまたは複数の開示の実施形態を実施することができる通信システム１００の例を示す。通信システム１００は、音声、データ、ビデオ、メッセージング、ブロードキャストなどのコンテンツを多数の無線ユーザに提供する多重アクセスシステムであってよい。通信システム１００によって、多数の無線ユーザが、無線帯域幅を含むシステムリソースを共有して、このようなコンテンツにアクセスすることができる。例えば、通信システム１００は、符号分割多重アクセス（ＣＤＭＡ）、時分割多重アクセス（ＴＤＭＡ）、周波数分割多重アクセス（ＦＤＭＡ）、直交ＦＤＭＡ（ＯＦＤＭＡ）、単一キャリアＦＤＭＡ（ＳＣ−ＦＤＭＡ）などの、１つまたは複数のチャネルアクセス方式を採用してよい。
【００１３】
図１Ａに示すように、通信システム１００は、無線送受信ユニット（ＷＴＲＵ）１０２ａ、１０２ｂ、１０２ｃおよび／または１０２ｄ（一般的にまたは総称してＷＴＲＵ１０２と呼んでよい）、無線アクセスネットワーク（ＲＡＮ）１０３／１０４／１０５、コアネットワーク１０６／１０７／１０９、公衆交換電話網（ＰＳＴＮ）１０８、インターネット１１０、および他のネットワーク１１２を含んでよい。しかしながら、開示の実施形態は、任意の数のＷＴＲＵ、基地局、ネットワーク、および／またはネットワーク要素を意図していることは理解されよう。ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄは各々、無線環境で動作および／または通信するように構成された任意の種類の装置であってよい。例として、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄは、無線信号を送信および／または受信するように構成されてよく、ユーザ装置（ＵＥ）、移動局、固定加入者ユニット、移動加入者ユニット、ポケットベル、携帯電話、パーソナルデジタルアシスタント（ＰＤＡ）、スマートフォン、ラップトップ、ネットブック、パーソナルコンピュータ、無線センサ、家庭用電化製品などを含んでよい。
【００１４】
通信システム１００は、基地局１１４ａおよび基地局１１４ｂも含んでよい。基地局１１４ａ、１１４ｂは各々、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄのうちの少なくとも１つと無線でインタフェースを取って、コアネットワーク１０６／１０７／１０９、インターネット１１０、および／または、ネットワーク１１２等の１つまたは複数の通信ネットワークへのアクセスを促進するように構成された任意の種類の装置であってよい。例として、基地局１１４ａ、１１４ｂは、ベーストランシーバステーション（ＢＴＳ）、ノードＢ（Ｎｏｄｅ−Ｂ）、ｅノードＢ（ｅＮｏｄｅ  Ｂ）、ホームノードＢ（Ｈｏｍｅ  Ｎｏｄｅ  Ｂ）、ホームｅノードＢ（Ｈｏｍｅ  ｅＮｏｄｅ  Ｂ）、サイトコントローラ、アクセスポイント（ＡＰ）、無線ルータなどであってよい。基地局１１４ａ、１１４ｂは、それぞれ単一の要素として示されているが、任意の数の相互に接続された基地局および／またはネットワーク要素を含んでよいことは理解されよう。  
【００１５】
基地局１１４ａは、ＲＡＮ１０３／１０４／１０５の一部であってよく、ＲＡＮ１０３／１０４／１０５は、他の基地局、および／または、基地局コントローラ（ＢＳＣ）、無線ネットワークコントローラ（ＲＮＣ）、リレーノードなどのネットワーク要素（図示せず）も含んでよい。基地局１１４ａおよび／または基地局１１４ｂは、セル（図示せず）と呼ばれる特定の地理的区域内で無線信号を送信および／または受信するように構成されてよい。セルは、さらにセルセクタに分かれてよい。例えば、基地局１１４ａに関連付けられたセルを３つのセクタに分けてよい。そうすると、一実施形態においては、基地局１１４ａは、３つのトランシーバ、すなわち、セルのセクタごとに１つのトランシーバを含んでよい。別の実施形態においては、基地局１１４ａは、多入力多出力（ＭＩＭＯ：ｍｕｌｔｉｐｌｅ−ｉｎｐｕｔ  ｍｕｌｔｉｐｌｅ−ｏｕｔｐｕｔ）技術を採用してよいので、セルのセクタごとに複数のトランシーバを利用してよい。
【００１６】
基地局１１４ａ、１１４ｂは、無線インタフェース１１５／１１６／１１７を介して、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄの１つまたは複数と通信してよい。無線インタフェース１１５／１１６／１１７は、任意の適切な無線通信リンク（例えば、無線周波数（ＲＦ）、マイクロ波、赤外線（ＩＲ）、紫外線（ＵＶ）、可視光線など）であってよい。無線インタフェース１１５／１１６／１１７は、任意の適切な無線アクセス技術（ＲＡＴ）を用いて構築してよい。
【００１７】
さらに詳細には、上述のように、通信システム１００は、多重アクセスシステムであってよく、ＣＤＭＡ、ＴＤＭＡ、ＦＤＭＡ、ＯＦＤＭＡ、ＳＣ−ＦＤＭＡ等の１つまたは複数のチャネルアクセス方式を採用してよい。例えば、ＲＡＮ１０３／１０４／１０５の基地局１１４ａとＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、ユニバーサルモバイルテレコミュニケーションシステム（ＵＭＴＳ）、地上波無線アクセス（ＵＴＲＡ：Ｔｅｒｒｅｓｔｒｉａｌ  Ｒａｄｉｏ  Ａｃｃｅｓｓ）等の無線技術を実施してよく、その無線技術によって、広帯域ＣＤＭＡ（ＷＣＤＭＡ（登録商標））を用いて無線インタフェース１１５／１１６／１１７を構築してよい。ＷＣＤＭＡは、高速パケットアクセス（ＨＳＰＡ）および／または進化型ＨＳＰＡ（ＨＳＰＡ＋）等の通信プロトコルを含んでよい。ＨＳＰＡは、高速ダウンリンクパケットアクセス（ＨＳＤＰＡ）および／または高速アップリンクパケットアクセス（ＨＳＵＰＡ）を含んでよい。  
【００１８】
別の実施形態においては、基地局１１４ａとＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、進化型ＵＭＴＳ地上波無線アクセス（Ｅ−ＵＴＲＡ）等の無線技術を実施してよく、その無線技術によって、ロングタームエボリューション（ＬＴＥ）および／またはＬＴＥアドバンスト（ＬＴＥ−Ａ）を用いて無線インタフェース１１５／１１６／１１７を構築してよい。
【００１９】
他の実施形態においては、基地局１１４ａおよびＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、ＩＥＥＥ８０２．１６（すなわち、ＷｉＭＡＸ（Ｗｏｒｌｄｗｉｄｅ  Ｉｎｔｅｒｏｐｅｒａｂｉｌｉｔｙ  ｆｏｒ  Ｍｉｃｒｏｗａｖｅ  Ａｃｃｅｓｓ））、ＣＤＭＡ２０００、ＣＤＭＡ２０００ＩＸ、ＣＤＭＡ２０００ＥＶ−ＤＯ、ＩＳ−２０００（Ｉｎｔｅｒｉｍ  Ｓｔａｎｄａｒｄ  ２０００）、ＩＳ−９５（Ｉｎｔｅｒｉｍ  Ｓｔａｎｄａｒｄ  ９５）、ＩＳ−８５６（Ｉｎｔｅｒｉｍ  Ｓｔａｎｄａｒｄ  ８５６）、グローバル・システム・フォー・モバイル・コミュニケーションズ（ＧＳＭ（登録商標）：Ｇｌｏｂａｌ  Ｓｙｓｔｅｍ  ｆｏｒ  Ｍｏｂｉｌｅ  Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ）、ＥＤＧＥ（Ｅｎｈａｎｃｅｄ  Ｄａｔａ  ｒａｔｅｓ  ｆｏｒ  ＧＳＭ  Ｅｖｏｌｕｔｉｏｎ）、ＧＥＲＡＮ（ＧＳＭ  ＥＤＧＥ）等の無線技術を実施してよい。
【００２０】
図１Ａの基地局１１４ｂは、例えば、無線ルータ、ホームノードＢ、ホームｅノードＢ、または、アクセスポイントであってよく、職場、自宅、車両内、学校などのローカルエリア内での無線接続を促進する任意の適切なＲＡＴを利用してよい。一実施形態においては、基地局１１４ｂおよびＷＴＲＵ１０２ｃ、１０２ｄは、ＩＥＥＥ８０２．１１等の無線技術を実施して、無線ローカルエリアネットワーク（ＷＬＡＮ）を構築してよい。別の実施形態においては、基地局１１４ｂおよびＷＴＲＵ１０２ｃ、１０２ｄは、ＩＥＥＥ８０２．１５等の無線技術を実施して、無線パーソナルエリアネットワーク（ＷＰＡＮ）を構築してよい。さらに別の実施形態においては、基地局１１４ｂおよびＷＴＲＵ１０２ｃ、１０２ｄは、セルラベースのＲＡＴ（例えば、ＷＣＤＭＡ、ＣＤＭＡ２０００、ＧＳＭ、ＬＴＥ、ＬＴＥ−Ａなど）を利用して、ピコセルまたはフェムトセルを構築してよい。図１Ａに示すように、基地局１１４ｂは、インターネット１１０に直接接続してよい。従って、基地局１１４ｂは、インターネット１１０にアクセスするのに、コアネットワーク１０６／１０７／１０９を介する必要はない。  
【００２１】
ＲＡＮ１０３／１０４／１０５は、コアネットワーク１０６／１０７／１０９と通信してよく、コアネットワーク１０６／１０７／１０９は、音声、データ、アプリケーション、および／またはボイスオーバインターネットプロトコル（ＶｏＩＰ）サービスを、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄの１つまたは複数に提供するように構成された任意の種類のネットワークであってよい。例えば、コアネットワーク１０６／１０７／１０９は、呼制御、ビリングサービス、モバイル位置情報サービス、プリペイドコール、インターネット接続、ビデオ配信などを提供してよく、および／または、ユーザ認証などの高水準のセキュリティ機能を行ってよい。図１Ａには記載していないが、ＲＡＮ１０３／１０４／１０５および／またはコアネットワーク１０６／１０７／１０９は、ＲＡＮ１０３／１０４／１０５と同じＲＡＴまたは他のＲＡＴを採用する他のＲＡＮと直接または間接に通信してよいことは理解されよう。例えば、コアネットワーク１０６／１０７／１０９は、Ｅ−ＵＴＲＡ無線技術を利用しているＲＡＮ１０３／１０４／１０５に接続しながら、ＧＳＭ無線技術を採用する別のＲＡＮ（図示せず）とも通信してよい。
【００２２】
コアネットワーク１０６／１０７／１０９は、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄがＰＳＴＮ１０８、インターネット１１０、および／または他のネットワーク１１２にアクセスするためのゲートウェイの役割もしてよい。ＰＳＴＮ１０８は、旧来のアナログ電話サービス（ＰＯＴＳ）を提供する行う回線交換電話網を含んでよい。インターネット１１０は、相互接続されたコンピュータネットワークの地球規模のシステムと、ＴＣＰ／ＩＰインターネットプロトコルスイートの、伝送制御プロトコル（ＴＣＰ）、ユーザデータグラムプロトコル（ＵＤＰ）、インターネットプロトコル（ＩＰ）などの共通通信プロトコルを用いる装置と、を含んでよい。ネットワーク１１２は、他のサービスプロバイダが所有および／または運営する有線または無線の通信ネットワークを含んでよい。例えば、ネットワーク１１２は、１つまたは複数のＲＡＮに接続される別のコアネットワークを含んでよく、該１つまたは複数のＲＡＮはＲＡＮ１０３／１０４／１０５と同じＲＡＴを採用していても、異なるＲＡＴを採用していてもよい。
【００２３】
通信システム１００内のＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄの一部または全ては、マルチモード機能を含んでよい。すなわち、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄは、異なる無線リンクを介して異なる無線ネットワークと通信する複数のトランシーバを含んでよい。例えば、図１Ａに記載のＷＴＲＵ１０２ｃは、セルラベースの無線技術を採用する基地局１１４ａ、および、ＩＥＥＥ８０２無線技術を採用する基地局１１４ｂと通信するように設定してよい。
【００２４】
図１Ｂは、ＷＴＲＵ１０２の例の系統図である。図１Ｂに示すように、ＷＴＲＵ１０２は、プロセッサ１１８、トランシーバ１２０、送信／受信素子１２２、スピーカ／マイクロフォン１２４、キーパッド１２６、ディスプレイ／タッチパッド１２８、取り外しできないメモリ１３０、取り外し可能なメモリ１３２、電源１３４、全地球測位システム（ＧＰＳ）チップセット１３６、および他の周辺機器１３８を含んでよい。ＷＴＲＵ１０２は、実施形態と矛盾しなければ、前述の要素の一部の任意の組み合わせを含んでよいことは理解されよう。また、基地局１１４ａ、１１４ｂ、および／または、ベーストランシーバステーション（ＢＴＳ）、ノードＢ、サイトコントローラ、アクセスポイント（ＡＰ）、ホームノードＢ、ｅＮｏｄｅＢ（ｅｖｏｌｖｅｄ  ｈｏｍｅ  ｎｏｄｅ−Ｂ）、ＨｅＮＢ（ｈｏｍｅ  ｅｖｏｌｖｅｄ  ｎｏｄｅ−Ｂ）、ＨｅＮＢ（ｈｏｍｅ  ｅｖｏｌｖｅｄ  ｎｏｄｅ−Ｂ）ゲートウェイ、および、プロキシノードを含むが、それらに限定されない基地局１１４ａ、１１４ｂが表すノードは、図１Ｂに示し、本明細書に記載される要素の一部または全てを含んでよいことを、実施形態は意図している。
【００２５】
プロセッサ１１８は、汎用プロセッサ、専用プロセッサ、従来型のプロセッサ、デジタル信号プロセッサ（ＤＳＰ）、複数のマイクロプロセッサ、ＤＳＰコアと関連付けられた１つまたは複数のマイクロプロセッサ、コントローラ、マイクロコントローラ、特定用途向け集積回路（ＡＳＩＣ：Ａｐｐｌｉｃａｔｉｏｎ  Ｓｐｅｃｉｆｉｃ  Ｉｎｔｅｇｒａｔｅｄ  Ｃｉｒｃｕｉｔｓ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）回路、任意の他の種類の集積回路（ＩＣ）、状態機械などであってよい。プロセッサ１１８は、信号符号化、データ処理、電力制御、入出力処理、および／または、ＷＴＲＵ１０２が無線環境で動作するのを可能にする任意の他の機能を行ってよい。プロセッサ１１８はトランシーバ１２０に接続してよく、トランシーバ１２０は送信／受信素子１２２に接続してよい。図１Ｂは、プロセッサ１１８とトランシーバ１２０を別個のコンポーネントとして表しているが、プロセッサ１１８とトランシーバ１２０は、電子パッケージまたはチップとして一体化してもよいことは理解されよう。
【００２６】
送信／受信素子１２２は、無線インタフェース１１５／１１６／１１７を介して、基地局（例えば、基地局１１４ａ）と信号を送受信するように構成されてよい。例えば、一実施形態においては、送信／受信素子１２２は、ＲＦ信号を送受信するように構成されたアンテナであってよい。別の実施形態においては、送信／受信素子１２２は、例えば、ＩＲ、ＵＶまたは可視光信号を送信および／または受信するように構成されたエミッタ／検出器であってよい。さらに別の実施形態においては、送信／受信素子１２２は、ＲＦ信号および光信号の両方を送受信するように構成されてよい。送信／受信素子１２２は、任意の組み合わせの無線信号を送信および／または受信するように構成されてよいことは理解されよう。
【００２７】
さらに、送信／受信素子１２２は、図１Ｂに単一の要素として記載されているが、ＷＴＲＵ１０２は、任意の数の送信／受信素子１２２を含んでよい。より詳細には、ＷＴＲＵ１０２は、ＭＩＭＯ技術を採用してよい。従って、一実施形態においては、ＷＴＲＵ１０２は、無線インタフェース１１５／１１６／１１７を介して無線信号を送受信する複数の送信／受信素子１２２（例えば、複数のアンテナ）を含んでよい。
【００２８】
トランシーバ１２０は、送信／受信素子１２２が送信する信号を変調し、送信／受信素子１２２が受信した信号を復調するように構成されてよい。上述のように、ＷＴＲＵ１０２は、マルチモード機能を有してよい。従って、トランシーバ１２０は、ＷＴＲＵ１０２が、例えば、ＵＴＲＡやＩＥＥＥ８０２．１１などの複数のＲＡＴを介して通信できるように、複数のトランシーバを含んでよい。
【００２９】
ＷＴＲＵ１０２のプロセッサ１１８は、スピーカ／マイクロフォン１２４、キーパッド１２６、および／または、ディスプレイ／タッチパッド１２８（例えば、液晶ディスプレイ（ＬＣＤ）ユニット、または、有機発光ダイオード（ＯＬＥＤ）ディスプレイ）に接続して、ユーザの入力データを受信してよい。プロセッサ１１８は、また、スピーカ／マイクロフォン１２４、キーパッド１２６、および／または、ディスプレイ／タッチパッド１２８にユーザデータを出力してよい。さらに、プロセッサ１１８は、取り外しできないメモリ１３０および／または取り外し可能なメモリ１３２などの任意の種類の適切なメモリの情報にアクセスしてよく、かつ、該メモリにデータを記憶してよい。取り外しできないメモリ１３０は、ランダムアクセスメモリ（ＲＡＭ）、リードオンリメモリ（ＲＯＭ）、ハードディスク、または、任意の他の種類の記憶装置を含んでよい。取り外し可能なメモリ１３２は、加入者識別モジュール（ＳＩＭ）カード、メモリスティック、セキュアデジタル（ＳＤ）メモリカードなどを含んでよい。他の実施形態においては、プロセッサ１１８は、サーバまたは家庭用コンピュータ（図示せず）など、物理的にＷＴＲＵ１０２上に位置しないメモリの情報にアクセスしてよく、該メモリにデータを記憶してよい。
【００３０】
プロセッサ１１８は、電源１３４から電力を得てよく、ＷＴＲＵ１０２内の他のコンポーネントに電力を供給、および／または、供給する電力を制御してよい。電源１３４は、ＷＴＲＵ１０２に電力を供給する任意の適切な装置であってよい。例えば、電源１３４は、１つまたは複数の乾電池（例えば、ニッケルカドミウム（ＮｉＣｄ）、ニッケル亜鉛（ＮｉＺｎ）、ニッケル水素（ＮｉＭＨ）、リチウムイオン（Ｌｉ−ｉｏｎ）など）、太陽電池、燃料電池などを含んでよい。
【００３１】
プロセッサ１１８は、また、ＧＰＳチップセット１３６に接続してよく、ＧＰＳチップセット１３６は、ＷＴＲＵ１０２の現在位置に関する位置情報（例えば、経度、緯度）を提供するよう構成されてよい。ＧＰＳチップセット１３６からの情報に加えて、または、その代わりに、ＷＴＲＵ１０２は、無線インタフェース１１５／１１６／１１７を介して基地局（例えば、基地局１１４ａ、１１４ｂ）から位置情報を受信してよく、および／または、複数の近くの基地局からの信号受信のタイミングに基づいてＷＴＲＵ１０２の位置を決定してよい。ＷＴＲＵ１０２は、実施形態と矛盾しない限り、任意の適切な位置決定方法で位置情報を取得してよいことは理解されよう。
【００３２】
プロセッサ１１８は、さらに、他の周辺機器１３８に接続してよく、他の周辺機器１３８は、追加の特徴、機能、および／または、有線または無線の接続を提供する１つまたは複数のソフトウェアモジュールおよび／またはハードウェアモジュールを含んでよい。例えば、周辺機器１３８は、加速度計、イーコンパス、衛星トランシーバ、デジタルカメラ（写真またはビデオ用）、ユニバーサルシリアルバス（ＵＳＢ）ポート、振動装置、テレビトランシーバ、ハンズフリーヘッドセット、ＢｌｕｅｔｏｏｔｈR「登録商標」モジュール、周波数変調（ＦＭ）無線ユニット、デジタル音楽プレーヤ、メディアプレーヤ、ビデオゲームプレーヤモジュール、インターネットブラウザなどを含んでよい。
【００３３】
図１Ｃは、実施形態に係るＲＡＮ１０３とコアネットワーク１０６の系統図である。上記のように、ＲＡＮ１０３は、ＵＴＲＡ無線技術を採用してＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと無線インタフェース１１５を介して通信してよい。ＲＡＮ１０３は、コアネットワーク１０６とも通信してよい。図１Ｃに示すように、ＲＡＮ１０３は、ノードＢ１４０ａ、１４０ｂ、１４０ｃを含んでよく、ノードＢ１４０ａ、１４０ｂ、１４０ｃは、それぞれ、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと無線インタフェース１１５を介して通信するための１つまたは複数のトランシーバを含んでよい。ノードＢ１４０ａ、１４０ｂ、１４０ｃは、それぞれ、ＲＡＮ１０３内の特定のセル（図示せず）に関連付けられてよい。ＲＡＮ１０３は、また、ＲＮＣ１４２ａ、１４２ｂを含んでよい。ＲＡＮ１０３は、実施形態と矛盾しない限り、任意の数のノードＢとＲＮＣを含んでよいことは理解されよう。
【００３４】
図１Ｃに示すように、ノードＢ１４０ａ、１４０ｂは、ＲＮＣ１４２ａと通信してよい。さらに、ノードＢ１４０ｃは、ＲＮＣ１４２ｂと通信してよい。ノードＢ１４０ａ、１４０ｂ、１４０ｃは、Ｉｕｂインタフェースを介してＲＮＣ１４２ａ、１４２ｂそれぞれと通信してよい。ＲＮＣ１４２ａ、１４２ｂは、Ｉｕｒインタフェースを介して互いに通信してよい。ＲＮＣ１４２ａ、１４２ｂはそれぞれ、接続先の各ノードＢ１４０ａ、１４０ｂ、１４０ｃを制御するように構成されてよい。さらに、ＲＮＣ１４２ａ、１４２ｂはそれぞれ、外部ループ電力制御、負荷制御、流入制御、パケットスケジューリング、ハンドオーバ制御、マクロダイバーシティ、セキュリティ機能、データ暗号化などの他の機能を実行またはサポートするように構成されてよい。
【００３５】
図１Ｃに示すコアネットワーク１０６は、メディアゲートウェイ（ＭＧＷ）１４４、モバイルスイッチングセンタ（ＭＳＣ）１４６、サービングＧＰＲＳサポートノード（ＳＧＳＮ）１４８、および／または、ゲートウェイＧＰＲＳサポートノード（ＧＧＳＮ）１５０を含んでよい。前述の各要素はコアネットワーク１０６の一部として表されているが、これらの要素はいずれも、コアネットワークオペレータ以外のエンティティによって所有および／または動作されてよいことは理解されよう。
【００３６】
ＲＡＮ１０３内のＲＮＣ１４２ａは、コアネットワーク１０６内のＭＳＣ１４６にＩｕＣＳインタフェースを介して接続してよい。ＭＳＣ１４６は、ＭＧＷ１４４に接続してよい。ＭＳＣ１４６およびＭＧＷ１４４は、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃにＰＳＴＮ１０８等の回線交換ネットワークへのアクセスを提供して、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと旧来の固定電話通信装置との通信を促進してよい。
【００３７】
ＲＡＮ１０３内のＲＮＣ１４２ａは、また、ＩｕＰＳインタフェースを介してコアネットワーク１０６内のＳＧＳＮ１４８に接続してよい。ＳＧＳＮ１４８は、ＧＧＳＮ１５０に接続してよい。ＳＧＳＮ１４８およびＧＧＳＮ１５０は、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃにインターネット１１０等のパケット交換ネットワークへのアクセスを提供して、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃとＩＰ対応装置との通信を促進してよい。  
【００３８】
上述のように、コアネットワーク１０６もネットワーク１１２に接続してよく、ネットワーク１１２は、他のサービスプロバイダが所有および／または運営する他の有線また無線のネットワークを含んでよい。
【００３９】
図１Ｄは、実施形態に係るＲＡＮ１０４とコアネットワーク１０７の系統図である。上述のように、ＲＡＮ１０４は、Ｅ−ＵＴＲＡ無線技術を採用して、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと無線インタフェース１１６を介して通信してよい。ＲＡＮ１０４は、また、コアネットワーク１０７と通信してよい。  
【００４０】
ＲＡＮ１０４は、ｅノードＢ１６０ａ、１６０ｂ、１６０ｃを含んでよい。ＲＡＮ１０４は、実施形態と矛盾しない限り、任意の数のｅノードＢを含んでよいことは理解されよう。ｅノードＢ１６０ａ、１６０ｂ、１６０ｃは、それぞれ、無線インタフェース１１６を介してＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと通信するための１つまたは複数のトランシーバを含んでよい。一実施形態においては、ｅノードＢ１６０ａ、１６０ｂ、１６０ｃは、ＭＩＭＯ技術を実施してよい。従って、例えば、ｅノードＢ１６０ａは、複数のアンテナを用いてＷＴＲＵ１０２ａと無線信号を送受信してよい。
【００４１】
ｅノードＢ１６０ａ、１６０ｂ、１６０ｃは、それぞれ、特定のセル（図示せず）と関連付けられてよく、無線リソース管理の決定、ハンドオーバ決定、アップリンクおよび／またはダウンリンクにおけるユーザのスケジューリングなどを扱うように構成されてよい。図１Ｄに示すように、ｅノードＢ１６０ａ、１６０ｂ、１６０ｃは、Ｘ２インタフェースを介して互いに通信してよい。
【００４２】
図１Ｄに示すコアネットワーク１０７は、モビリティ管理ゲートウェイ（ＭＭＥ）１６２、サービングゲートウェイ１６４、およびパケットデータネットワーク（ＰＤＮ）ゲートウェイ１６６を含んでよい。前述の各要素は、コアネットワーク１０７の一部として表されているが、これらの要素はいずれも、コアネットワークオペレータ以外のエンティティが所有し、および／または、動作させてよいことは理解されよう。
【００４３】
ＭＭＥ１６２は、ＳＩインタフェースを介して、ＲＡＮ１０４内のｅノードＢ１６０ａ、１６０ｂ、１６０ｃのそれぞれと接続され、制御ノードの役割をしてよい。例えば、ＭＭＥ１６２は、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃのユーザの認証、ベアラのアクティベーション／アクティベーションの解除、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃの初期アタッチ時の特定のサービングゲートウェイの選択などを行ってよい。ＭＭＥ１６２は、また、ＲＡＮ１０４と、ＧＳＭまたはＷＣＤＭＡ等の他の無線技術を採用する他のＲＡＮ（図示せず）との間の切り替えのための制御プレーン機能を提供してよい。
【００４４】
サービングゲートウェイ１６４は、ＳＩインタフェースを介して、ＲＡＮ１０４内のｅノードＢ１６０ａ、１６０ｂ、１６０ｃのそれぞれに接続してよい。サービングゲートウェイ１６４は、一般に、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃに／からユーザデータパケットをルーティング、転送してよい。サービングゲートウェイ１６４は、ｅノードＢ間のハンドオーバ中にユーザプレーンをアンカリングすること、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃのためのダウンリンクデータが利用可能な場合にページングをトリガすること、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃのコンテキストを管理、記憶することなどの他の機能を行ってもよい。
【００４５】
サービングゲートウェイ１６４は、また、ＰＤＮゲートウェイ１６６に接続してよく、ＰＤＮゲートウェイ１６６は、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃにインターネット１１０等のパケット交換ネットワークへのアクセスを提供して、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃとＩＰ対応装置との間の通信を促進してよい。
【００４６】
コアネットワーク１０７は、他のネットワークとの通信を促進してよい。例えば、コアネットワーク１０７は、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃにＰＳＴＮ１０８等の回線交換ネットワークへのアクセスを提供して、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと旧来の固定電話通信装置との通信を促進してよい。例えば、コアネットワーク１０７は、コアネットワーク１０７とＰＳＴＮ１０８間のインタフェースの役割をするＩＰゲートウェイ（例えば、ＩＰマルチメディアサブシステム（ＩＭＳ）サーバ）を含んでよい、または、該ＩＰゲートウェイと通信してよい。さらに、コアネットワーク１０７は、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃにネットワーク１１２へのアクセスを提供してよい。ネットワーク１１２は、他のサービスプロバイダが所有および／または運営する他の有線または無線のネットワークを含んでよい。
【００４７】
図１Ｅは、実施形態に係るＲＡＮ１０５とコアネットワーク１０９の系統図である。ＲＡＮ１０５は、ＩＥＥＥ８０２．１６無線技術を採用して、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと無線インタフェース１１７を介して通信するアクセスサービスネットワーク（ＡＳＮ）であってよい。下記にさらに記載するように、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、ＲＡＮ１０５およびコアネットワーク１０９の異なる機能エンティティ間の通信リンクは、基準点として定義してよい。
【００４８】
図１Ｅに示すように、ＲＡＮ１０５は、基地局１８０ａ、１８０ｂ、１８０ｃおよびＡＳＮゲートウェイ１８２を含んでよい。ＲＡＮ１０５は、実施形態に矛盾しない限り、任意の数の基地局およびＡＳＮゲートウェイを含んでよいことは理解されよう。各基地局１８０ａ、１８０ｂ、１８０ｃは、ＲＡＮ１０５内の特定のセル（図示せず）に関連付けられてよく、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと無線インタフェース１１７を介して通信するための１つまたは複数のトランシーバを含んでよい。一実施形態においては、基地局１８０ａ、１８０ｂ、１８０ｃは、ＭＩＭＯ技術を実施してよい。従って、例えば、基地局１８０ａは、複数のアンテナを用いて、ＷＴＲＵ１０２ａと無線信号を送受信してよい。基地局１８０ａ、１８０ｂ、１８０ｃは、また、ハンドオフトリガ、トンネル構築、無線リソース管理、トラフィック分類、サービスの質（ＱｏＳ）ポリシーの施行などのモビリティ管理機能を提供してよい。ＡＳＮゲートウェイ１８２は、トラフィック集約点の役割をしてよく、ページング、加入者プロファイルのキャッシング、コアネットワーク１０９へのルーティングなどを行ってよい。
【００４９】
ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃとＲＡＮ１０５間の無線インタフェース１１７は、ＩＥＥＥ８０２．１６規格を実施するＲｌ基準点として定義してよい。さらに、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、それぞれ、コアネットワーク１０９との論理インタフェース（図示せず）を構築してよい。ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃとコアネットワーク１０９との論理インタフェースは、Ｒ２基準点として定義してよい。Ｒ２基準点は、認証、許可、ＩＰホスト設定管理、および／または、モビリティ管理に使用してよい。
【００５０】
基地局１８０ａ、１８０ｂ、１８０ｃ間の通信リンクは、ＷＴＲＵのハンドオーバと基地局間のデータ転送を促進するプロトコルを含むＲ８基準点として定義してよい。基地局１８０ａ、１８０ｂ、１８０ｃとＡＳＮゲートウェイ１８２間の通信リンクは、Ｒ６基準点として定義してよい。Ｒ６基準点は、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃのそれぞれと関連付けられたモビリティイベントに基づいてモビリティ管理を促進するためのプロトコルを含んでよい。
【００５１】
図１Ｅに示すように、ＲＡＮ１０５は、コアネットワーク１０９に接続してよい。ＲＡＮ１０５とコアネットワーク１０９との通信リンクは、例えば、データ転送とモビリティ管理能力を促進するプロトコルを含むＲ３基準点として定義してよい。コアネットワーク１０９は、モバイルＩＰホームエージェント（ＭＩＰ−ＨＡ）１８４、認証・許可・アカウンティング（ＡＡＡ）サーバ１８６、および、ゲートウェイ１８８を含んでよい。前述の各要素は、コアネットワーク１０９の一部として表されているが、これらの要素はいずれも、コアネットワークオペレータ以外のエンティティによって所有および／または動作されてよいことは理解されよう。
【００５２】
ＭＩＰ−ＨＡはＩＰアドレス管理を行ってよく、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃが異なるＡＳＮおよび／または異なるコアネットワーク間でローミングするのを可能にしてよい。ＭＩＰ−ＨＡ１８４は、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃにインターネット１１０等のパケット交換ネットワークへのアクセスを提供して、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃとＩＰ対応装置との通信を促進してよい。ＡＡＡサーバ１８６は、ユーザ認証と、ユーザサービスのサポートを行ってよい。ゲートウェイ１８８は、他のネットワークとの相互作用を促進してよい。例えば、ゲートウェイ１８８は、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃにＰＳＴＮ１０８等の回線交換ネットワークへのアクセスを提供して、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと旧来の固定電話通信装置との通信を促進してよい。さらに、ゲートウェイ１８８は、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃにネットワーク１１２へのアクセスを提供してよい。ネットワーク１１２は、他のサービスプロバイダが所有および／または運営する他の有線または無線のネットワークを含んでよい。
【００５３】
図１Ｅには記載していないが、ＲＡＮ１０５は、他のＡＳＮに接続してよく、コアネットワーク１０９は、他のコアネットワークに接続してよいことは理解されよう。ＲＡＮ１０５と他のＡＳＮの通信リンクは、Ｒ４基準点として定義してよい。Ｒ４基準点は、ＲＡＮ１０５と他のＡＳＮの間でＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃのモビリティを調整するためのプロトコルを含んでよい。コアネットワーク１０９と他のコアネットワーク間の通信リンクは、Ｒ５基準点として定義してよい。Ｒ５基準点は、ホームコアネットワークと訪問先コアネットワーク間の相互作用を促進するためのプロトコルを含んでよい。
【００５４】
一般的に、高速データ通信システム内で個々のパケットの相対的重要度に従って、ビデオパケット等のパケットを差別化する様々なシステムおよび方法を本明細書に記載する。例えば、単一のビデオアプリケーションセッション中に生成されたビデオパケットを、個々のビデオパケットに関する所望のサービス品質（ＱｏＳ）に基づいて、差別化し、処理するシステムおよび方法を記載する。本明細書において、ＱｏＳ要件という語は、ＱｏＳレベルともいうが、ネットワークを介したデータ送信の所望の性能レベルに対応してよい。例えば、典型的なＱｏＳパラメータ（ＱｏＳメトリクスとも言う）は、ビットレート、遅延、ビット誤り率、ブロック誤り率、最大ブロッキング確率、アウテージ確率、サービス応答時間、損失率、ジッタ、遅延ジッタ、パケット棄却率、順序の違った配信を許可するか否か、などであってよい。１つまたは複数の所望のまたは保証されたＱｏＳパラメータレベルを用いて、所与のＱｏＳ要件を定義してよい。例えば、所与のパケットストリームに対する所与のＱｏＳ要件に関して、ネットワークは、パケットストリームがその所与のパケットストリームの最小（またはＱｏＳパラメータに応じて最大）のＱｏＳパラメータレベルを達成することを保証してよい。例としては、ＱｏＳ要件Ａ、が、最大遅延１００ｍｓ（ＱｏＳパラメータ１）と最小スループット１Ｍｂ／ｓ（ＱｏＳパラメータ２）に該当する場合、ネットワークは、ＱｏＳ要件に関連付けられたパケットは、無線アクセスおよび／またはルーティング中、最大遅延が１００ｍｓ以下であること、および、所望のスループットレベルを満たす十分なパケットがある場合、ストリームのスループットは、少なくとも１Ｍｂ／ｓであることを保証してよい。
【００５５】
ＬＴＥネットワークの一例においては、ＱｏＳパラメータは、所与の進化型パケットシステム（ＥＰＳ：Ｅｖｏｌｖｅｄ  Ｐａｃｋｅｔ  Ｓｙｓｔｅｍ）のＱｏＳプロファイルに関連付けられてよい。ＬＴＥのＱｏＳパラメータの例は、ＱｏＳクラス識別子（ＱＣＩ）（例えば、ベアラレベルのパケット配信／転送処理を制御してよいアクセスノード固有のパラメータ）、割当および保持優先度（ＡＲＰ）（例えば、ベアラ確立／一部変更の要求を受諾するか拒絶するかの指示）、保証ビットレート（ＧＢＲ）（例えば、所与のベアラに提供可能な最小ビットレート）、最大ビットレート（ＭＢＲ）（例えば、ＧＢＲベアラから期待し得る最大ビットレート）、総合ＭＢＲ（ＡＭＢＲ）（例えば、ＧＢＲでないベアラ群の全ビットレート）などを含んでよい。
【００５６】
一例においては、パケットの差別化は、ビデオ品質を向上させる、および／または、ビデオ品質にあまり悪影響を与えることなくネットワークが取り扱うビデオセッションの数を増加させるように、ネットワークリソースの割り当てを促進してよい。高速データ通信システムで異なったタイプのビデオパケットを識別するシステムおよび方法を記載する。例えば、パケットの差別化をサポートするためにＷＴＲＵおよび／またはコアネットワークが実施する機構を開示する。説明のため、本明細書に開示の例の多くは、ビデオトラフィックおよびビデオパケット差別化に関して記載する。しかしながら、本明細書に開示の方法およびシステムは、多くのタイプおよび種類のパケットフロー、例えば、相対的優先度の異なるパケットを含むパケットフローに適用可能であってよいことは理解されよう。例えば、本明細書に開示のシステムおよび方法は、リアルタイムゲームのパケットフロー、ＴＣＰパケットフロー、および／または、様々な他のパケットベースのサービスに適用可能であってよい。
【００５７】
ビデオパケットの差別化に関する例として、本明細書に開示のシステムおよび方法は、Ｈ．２６４／ＡＶＣビデオコーデック、Ｈ．２６４／ＳＶＣビデオコーデック、階層Ｐ（Ｈｉｅｒａｒｃｈｉｃａｌ  Ｐ）コーデック、および／または、他のビデオコーデックに適用してよい。このようなコーデックは、エンコーダ出力ストリームでの個々のビデオパケットの相対的な重要度および／または優先度を示してよい。一例においては、本明細書に記載のシステムおよび方法は、他のアプリケーション（例えば、ビデオまたはその他）に適用可能であってよい。例えば、本明細書に記載のシステムおよび方法は、様々なレベルの優先度および／または重要度を有するパケットのストリームに適用してよい。一例においては、パケットの差別化は、パケットの優先度および相対的重要度ではなく、または、それらに追加した様々な要因に基づいてよい。例えば、パケットの差別化は、パケットタイプ、サービスタイプ、サービスクラス（ＣｏＳ）、プロトコル優先度、仮想ローカルエリアネットワーク（ＶＬＡＮ）優先度、ネットワーク優先度、送信元優先度、送信先優先度、ポート優先度（例えば、ＴＣＰポート）、アプリケーションタイプなどに基づいてよい。
【００５８】
さらに、ＬＴＥネットワークとの関連で多くの例を記載するが、本明細書に開示のシステムおよび方法は、他のネットワーク環境にも同様に適用可能であってよい。例えば、本明細書に記載のシステムおよび方法は、広範囲の高速データ通信システムに適用してよい。高速データ通信システムの例は、ＬＴＥ／ＬＴＥ−Ａシステム（例えば、Ｅ−ＵＴＲＡおよび／または進化型パケットコア（ＥＰＣ：Ｅｖｏｌｖｅｄ  Ｐａｃｋｅｔ  Ｃｏｒｅ）ネットワーク）、ＵＭＴＳネットワーク（例えば、ＵＴＲＡＮおよび／またはＵＭＴＳコアネットワーク）、ＷｉＦｉベースのネットワーク、ＷｉＭａｘネットワークなどの、３ＧＰＰおよび／または非３ＧＰＰシステムを含んでよい。ＬＴＥネットワークの例は、ＬＴＥ用語で記載しているが、対応する機能を有する他のタイプのネットワークにも同様に適用可能であってよい。例えば、ＬＴＥネットワークにおいてＱＣＩで記載されている例は、ＵＭＴＳネットワークのＱｏＳプロファイル、またはＷｉＭＡＸネットワークのサービスフローのＱｏＳに適用可能であってよい。
【００５９】
ビデオトラフィック等の一定のタイプのトラフィックは、ネットワークリソース集約的で、時には、比較的厳しい待ち時間要件を有することがある。ビデオトラフィックに関して、所望のビデオ品質および／または体験品質（ＱｏＥ：Ｑｕａｌｉｔｙ  ｏｆ  Ｅｘｐｅｒｉｅｎｃｅ）を提供するために、本明細書に記載のシステムおよび方法を用いて、ビデオパケットとビデオ以外のパケットを差別化してよい、および／または、異なるタイプのビデオパケット、例えば、同じビデオパケットストリーム／フロー内のビデオパケットの差別化を行ってよい。一例においては、ビデオパケットが同じビデオエンコーダで生成されていても、このような差別化を行ってよい。一般に、異なるタイプのビデオパケットの差別化によって、該差別化されたビデオパケットの相対的重要度に基づいて、パケットの識別と処理を容易にしてよい。リソースに制約のある環境において、高速データ通信システムの終端でのビデオ品質を向上させるために、高速データ通信システムは、異なるタイプのビデオパケットをその相対的重要度に従って識別し、限られたネットワークリソースを、差別化に基づいて異なるタイプのビデオパケットに割り当てるように構成されてよい。
【００６０】
多くの高速データ通信システムにおいて、ビデオパケットのタイプに関する情報および／または相対的重要度または優先度に関する情報は、ビデオデータを含むプロトコルデータユニット（ＰＤＵ）として隠蔽／カプセル化可能であり、高速データ通信システムに渡される。本明細書に記載のシステムおよび方法に従って、ビデオの送信元は、ビデオパケットを、例えば、各サブストリームに含まれる各ビデオパケットのタイプの相対的重要度に従って、複数のサブストリームに分割するように構成されてよい。様々な例によると、通信ネットワークは、例えば、個々のパケットに関連付けられた対応するサブストリームを識別することによって、ビデオパケットのタイプを識別するように構成されてよい。一例においては、ビデオパケットフォーマットは、より細かい粒度での差別化を可能にするように拡張されてよい。
【００６１】
様々な方法をビデオパケット識別に利用してよい。例えば、ディープパケットインスペクション（ＤＰＩ）は、パケットタイプおよび／またはパケットに含まれる情報を識別するために高速データ通信網によって利用される技術であってよい。例えば、ＤＰＩを行ってパケットを識別すると、高速データ通信システムは、単一のストリームとしてビデオエンコーダ出力を受信し、パケット内にカプセル化された上位層のデータの検査に基づいてパケットタイプを識別してよい。しかしながら、パケットが暗号化されていると、ＤＰＩの実行は困難になる場合がある。例えば、保護リアルタイムトランスポートプロトコル（ＳＲＴＰ）、保護ソケット層（ＳＳＬ）、トランスポート層セキュリティ（ＴＬＳ）、インターネットプロトコルセキュリティ（ＩＰｓｅｃ：Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ  Ｓｅｃｕｒｉｔｙ）のカプセル化セキュリティペイロード（ＥＳＰ：ｅｎｃａｐｓｕｌａｔｉｎｇ  ｓｅｃｕｒｉｔｙ  ｐａｙｌｏａｄ）、および／または、プロトコルの組み合わせの形で、暗号化を用いてパケットを保護してよく、ＰＤＵのペイロードの検査を非常に困難にしている。従って、実際の場面では大抵、ＤＰＩは、暗号化技術を利用しているパケットの識別および／または分類には実行不可能である。
【００６２】
一例においては、検査しているパケットのタイプを決定するために、所与のアプリケーションから生成されるパケットは、例えば、高速データ通信システムで使用される何らかの種類の識別情報で各ストリームに「マーク付け」することによって、パケット送信元で異なるサブストリームに分割してよい。送信元のパケットストリームを一連のサブストリームに分割することによって、各サブストリーム内のパケットは、その相対的優先度および／または所望のＱｏＳに従って処理、ルーティングしてよい。様々なサブストリームに分割可能なパケットストリームの一例は、ビデオパケットストリームである。
【００６３】
３ＧＰＰ規格、インターネットエンジニアリングタスクフォース（ＩＥＴＦ：Ｉｎｔｅｒｎｅｔ  Ｅｎｇｉｎｅｅｒｉｎｇ  Ｔａｓｋ  Ｆｏｒｃｅ）規格、ビデオコード、および／または、ビデオ符号化／復号化規格への変更は、下記に詳述するように、ビデオパケットを処理する通信層の１つまたは複数が異なるタイプのビデオパケットを伝送するサブストリームを識別するのに十分な情報を有するように、行ってよい。例えば、次の変更の１つまたは複数をビデオパケットストリーム等のパケットストリームサブストリーム処理を容易にするために行ってよい。該変更とは、ＱＣＩフィールドをサブストリームのプロパティに関する情報を含むよう拡張すること、よりフレキシブルなＱｏＳプロパティの表示を用いて、例えば、より詳細／可変なＱｏＳ情報を伝えること、コアネットワークに対して所望のＱｏＳ要求を明示的に指定するようにＷＴＲＵを構成すること、ビデオパケットの分割、マージ、および／または、再順序付けの技術を指定すること、処理中のパケットのタイプに関して、より多くの情報を公開することである。変更は、３ＧＰＰ規格、ＩＥＴＦ規格、および／または、ビデオコーデック規格に関することは理解されよう。
【００６４】
図２は、複数のパケットサブストリームをトランスポートすることができるシステムの系統図の例を示す。図２はビデオのトランスポートを示すが、同様の技術を用いて他のデータストリームをトランスポートしてよいことは理解されよう。ビデオデータの例は、ビデオ会議データ、リアルタイムビデオストリーミング、および／または、他のタイプのビデオストリームを含んでよい。ＷＴＲＵ２０２からＷＴＲＵ２０４へのビデオ送信を図２に示すが、ビデオは、ビデオサーバからＷＴＲＵに、ＷＴＲＵからビデオサーバに、あるビデオサーバから別のビデオサーバに、および／または、任意の数の装置から／に（例えば、ポイントツーポイント、マルチキャストなど）送信されてよい。図２の例においては、ＷＴＲＵ２０２およびＷＴＲＵ２０４は、２つの異なるＬＴＥ／システムアーキテクチャエボリューション（ＳＡＥ：Ｓｙｓｔｅｍ  Ａｒｃｈｉｔｅｃｔｕｒｅ  Ｅｖｏｌｕｔｉｏｎ）ネットワークに配置されてよいが、本明細書に記載の技術は、ＷＴＲＵ２０２およびＷＴＲＵ２０４が同じＬＴＥ／ＳＡＥ内に配置されている場合にも等しく適用可能であってよい。さらに、異なるエンティティ間の論理通信を図２に示すが、１つまたは複数のエンティティおよび／またはメッセージは、分かりやすいように、および／または、説明を簡単にするために省いてよい。
【００６５】
図２の例においては、１つのビデオストリームを３つのサブストリームに分割してよい。ビデオストリームは、ビデオエンコーダからのビデオパケットを処理するため、所望のレベルの差別化を実現するように分割してよい。サブストリームの数は、パケット差別化の相対的粒度を定義してよい。ＷＴＲＵは、パケットＱｏＳの粒度という観点で、所望の差別化のレベルに基づいて、使用するサブストリームの数を選択してよい。言い換えれば、異なるタイプのビデオパケットのルーティング／処理の方法をより多く差別化するためには、より多くのサブストリームを使用すればよい。ビデオの送信元（ここでは、ＷＴＲＵ２０２）は、３つのサブストリームを生成してよい。生成された各サブストリームに対して、ベアラをアクセスネットワーク内に確立してよい。サブストリームの処理を容易にするために、ＷＴＲＵ２０２とポリシーおよび課金制御（ＰＣＣ：  Ｐｏｌｉｃｙ  ａｎｄ  Ｃｈａｒｇｉｎｇ  Ｃｏｎｔｒｏｌ）機能２０６との間のアプリケーションシグナリングは、サブストリームの１つまたは複数に関する情報を含んでよい。ＰＣＣ機能は、ポリシーおよび課金ルール機能（ＰＣＲＦ：Ｐｏｌｉｃｙ  ａｎｄ  Ｃｈａｒｇｉｎｇ  Ｒｕｌｅｓ  Ｆｕｎｃｔｉｏｎ）、および／または、ポリシーおよび課金施行機能（ＰＣＥＦ：Ｐｏｌｉｃｙ  ａｎｄ  Ｃｈａｒｇｉｎｇ  Ｅｎｆｏｒｃｅｍｅｎｔ  Ｆｕｎｃｔｉｏｎ）の１つまたは複数で実施してよい。
【００６６】
例えば、サブストリームの１つまたは複数に関する情報は、ＱＣＩ値の拡張子、サブストリームのＱｏＳプロパティの表示、ＷＴＲＵによる一定のＱｏＳの明示的な要求などのうち１つまたは複数を含んでよい。一般に、ＰＣＣ２０６（および／またはＰＣＣ２０８）は、ネットワークオペレータが、サブスクリプションサービスに関連付けられたポリシーに基づいて１つまたは複数のベアラのＱｏＳを制御し、および／または、システムが提供するサービスに対する課金と請求を制御するのを可能にするように構成されてよい。ＷＴＲＵ２０２における単一のビデオストリームから複数のサブストリームへの逆多重化は、１つまたは複数のビデオパケットの分割、および／または、一定の符号化情報の公開を含んでよく、比較的細かい粒度でパケットの差別化を可能にする。サブストリーム処理中に、ＬＴＥ／ＳＡＥネットワーク（例えば、ＷＴＲＵ２０２および／またはＷＴＲＵ２０４のアクセスネットワーク）でＱｏＳを差別化するために、この情報を利用してよい。同じビデオ送信元に属するサブストリームであっても、所望のＱｏＳレベルに基づいて、サブストリームの１つまたは複数を他のサブストリームとは別にルーティング／処理してよい。ＷＴＲＵ２０４は、サブストリームの多重化、パケットの再順序付け、ビデオパケットのマージなどを行うように構成されてよい。
【００６７】
ＬＴＥ／ＳＡＥにおいて、ＱｏＳプロビジョニングは、進化型パケットシステム（ＥＰＳ：Ｅｖｏｌｖｅｄ  Ｐａｃｋｅｔ  Ｓｙｓｔｅｍ）ベアラの使用に基づいてよい。ＥＰＳベアラは、ＥＰＳ／コアネットワーク内でトランスポートサービスに特定のＱｏＳ属性を提供する仮想接続であってよい。ＵＭＴＳネットワークにおいて、ＱｏＳプロビジョニングは、対応するパケットデータプロトコル（ＰＤＰ）コンテキストと関連付けられてよい。ＥＰＳベアラは、例えば、ＥＰＳベアラが受信するＱｏＳを指定するＱＣＩ値を割り当てられてよい。ＱＣＩ値は、ＥＰＳベアラのＱｏＳプロファイルに関連付けられたパラメータであってよい。ＱＣＩ値は、例えば、ベアラレベルのパケット転送処理（例えば、スケジューリング重み、アドミッション閾値、待ち行列管理閾値、リンク層プロトコル設定など）を制御するアクセスノード固有のパラメータを指すスカラ値であってよい。例えば、ＱＣＩ値は、パケットタイプ、および／または、パケットに関連付けられたサービスのタイプ（例えば、会話、ストリーミングビデオ、シグナリング、ベストエフォート型、など）を示してよい。ＱＣＩ値を用いて、最大遅延、見逃し誤り率、保証ビットレート（ＧＢＲ）、最大ビットレート（ＭＢＲ）などの１つまたは複数のＱｏＳ属性を決定してよい。所与のＱＣＩ値を有するＥＰＳベアラは、リソースタイプ（例えば、ＧＢＲまたは非ＧＢＲ）、優先度、パケット遅延バジェット、パケット損失率などの対応するＱＣＩ特性と関連付けられてよい。３ＧＰＰ規格である３ＧＰＰ  ＴＳ  ２３．２０３，ｖｌｌ．１．０「ポリシーおよび課金制御アーキテクチャ」（２０１１年３月）の内容は全て、援用により本明細書に組み込まれ、ＱＣＩの９つの値を定義する。表１は、該９つのＱＣＩ値に対応可能なサービスの例を示す。
【００６８】
【表１】
2014527771.tif 000003
【００６９】
表１に記載のこれら９つのＱＣＩ値のうち、ＱＣＩ＝２およびＱＣＩ＝７はリアルタイムビデオアプリケーションに適用可能であってよく、他の値は、ビデオ以外、または、リアルタイムでないビデオアプリケーション（例えば、バッファリングされたアプリケーション）に関連付けられてよい。例えば、Ｈ．２６４／ＡＶＣをビデオ会議に用いる場合、ビデオエンコーダの全ての出力ストリームは、ＱＣＩ＝２またはＱＣＩ＝７のいずれかに従って、単一のＱｏＳレベルで処理してよい。表１に定義された９つのＱＣＩレベルでは、同じ出力ストリーム内の異なるタイプのビデオパケットの差別化は可能でない場合がある。それでもなお、ビデオパケットは、全て同じビデオエンコーダからであっても、異なるレベルの相対的重要度を有してよい。結果として、所与の出力ストリーム内の個々のパケットを差別化するために追加の粒度を使わずに、表１で識別された９つのＱＣＩ値を使用すると、特に、リソースに制約のある環境ではビデオ品質の劣化につながる場合がある。従って、ビデオに対してより粒度の細かいＱｏＳレベルを使用してよい。
【００７０】
例として、Ｈ．２６４／ＡＶＣビデオパケットを考えよう。Ｈ．２６４／ＡＶＣエンコーダから出力されるビデオパケットは、ネットワーク抽象化層（ＮＡＬ）ユニット（ＮＡＬＵ）の形をとってよい。ＮＡＬＵは、ビデオ符号化層（ＶＣＬ）情報（例えば、圧縮ビット）および／または非ＶＣＬ情報（例えば、追加情報）の１つまたは複数を含むよう構成されてよい。ＶＣＬ  ＮＡＬＵは、瞬時復号リフレッシュ（ＩＤＲ：Ｉｎｓｔａｎｔａｎｅｏｕｓ  Ｄｅｃｏｄｉｎｇ  Ｒｅｆｒｅｓｈ）パケットまたは非ＩＤＲパケットであってよい。ＩＤＲ  ＮＡＬＵは、ビデオストリーム内で他のパケットの基準パケットとして働くように構成してよいので、比較的重要なパケットであってよい。さらに、データ分割を用いる場合、パーティションＡは、動き推定に関する情報などを含んでよく、パーティションＢ、パーティションＣなどに関する情報を含むパケットを復号化するのに用いてよい。従って、パーティションＡに関する情報を含むＮＡＬＵは比較的重要であってよい。というのは、パーティションＡ  ＮＡＬＵが失われると、それに従属するパーティションＢタイプとパーティションＣタイプのＮＡＬＵが役に立たなくなるからである。本明細書に記載のシステムおよび方法によって、高速データ通信システムは、異なるタイプのビデオパケットに対して（例えば、相対的重要度に基づいて）異なる扱いをすることができる。他のコーデックが、本明細書に記載のシステムおよび方法に従って処理可能な、様々なレベルの相対的重要度を有するビデオパケットを作り出してもよいことは理解されたい。
【００７１】
一例においては、ＱＣＩ値は、独自の方法でビデオコーデック（例えば、Ｈ．２６４／ＡＶＣおよび／またはＨ．２５４／ＳＶＣ）をサポートするよう拡張してよい。他の例においては、拡張されたＱＣＩ値を適用可能な規格に組み込んでもよい。表２は、パケットフロー内のパケットのＱｏＳ差別化の粒度を上げるために使用可能なＱＣＩ拡張子セットの例を示す。表２の例では、ＮＡＬ基準識別値（ＮＲＩ：ＮＡＬ  Ｒｅｆｅｒｅｎｃｅ  Ｉｄｅｎｔｉｆｉｃａｔｉｏｎ）を用いて、単一のフローおよび／またはＥＰＳベアラ内のパケットに対して追加のＱＣＩ値を定義してよい。
【００７２】
【表２】
2014527771.tif 000004
【００７３】
表２の例においては、ＮＲＩ値、１１、は、ＮＡＬＵパケットの最高の相対的優先度レベルに対応してよく、００は、ＮＡＬＵパケットの最低の相対的優先度レベルに対応してよい。例えば、ＮＲＩ値＝１１は、比較的重要なペイロード（例えば、シーケンスパラメータセットなど）を伝送するＮＡＬＵを識別してよい。ＮＲＩ＝１０は、次に高い優先度レベル、例えば、シーケンスパラメータ設定拡張子などのペイロードを伝送するＮＡＬＵを識別してよい。ＮＲＩ＝０１は、三番目に高い優先度レベル、例えば、パーティションＡなどのペイロードを含むＮＡＬＵを識別してよい。ＮＲＩ＝００は、最低の優先度レベル、例えば、非ｌＯＲ  ＶＣＬ等のペイロードを含むＮＡＬＵを識別してよい。ヘッダの他の部分（例えば、ＮＡＬユニットタイプ）を用いて、パケットがＩＤＲ  ＶＣＬ  ＮＡＬＵであるか否か、パーティション識別などの、パケットに関する追加の情報を提供してよい。
【００７４】
他の技術を用いてパケットの相対的優先度を識別してよいことは理解されよう。例えば、５つ以上の値（例えば、５つ以上のＮＲＩ値）を用いて相対的優先度を識別すると、より詳細なＱｏＳ情報を提供することができ、および／または、より粒度の細かいビデオパケットの差別化を行うことができる。例えば、ＮＡＬユニットタイプフィールドのビットは、パケットの相対的優先度を示してよい。表３は、個々のＮＡＬＵに含まれる５ビットｎａｌ＿ｕｎｉｔ＿ｔｙｐｅフィールドを用いて複数のビデオパケットの相対的優先度を差別化する例を示す。
【００７５】
【表３】
2014527771.tif 000005
【００７６】
よって、本明細書の例に従って、特定のエンコーダからのフロー内のパケットに、パケットのサブストリームの相対的優先度および／または重要度に基づいて、異なるＱｏＳリソースを提供してよい。例えば、特定のフローを、１、２、３・・・またはｎ個の関連付けられたベアラに逆多重化してよい。ここで、ｎ個は任意の正の整数であってよい。パケットは、パケットの相対的重要度または優先度に基づいて、個々のサブストリームに割り当ててよい。例えば、パケットのＮＲＩ値および／またはｎａｌ＿ｕｎｉｔ＿ｔｙｐｅフィールドを用いて、該パケットに適切なサブストリームを決定してよい。一例においては、最高の優先度を有するパケットは、第１のベアラ（例えば、最高の相対的ＱｏＳパラメータのベアラ）に関連付けてよく、次に高い優先度を有するパケットは、第２のベアラに関連付けてよい。以下同様に関連付けを行ってよい。
【００７７】
しかしながら、ＱＣＩ値に基づいてパケットの優先度を差別化するのではなく、（または、それに追加して）、パケットの相対的重要度を決定するのに使用可能なＱｏＳパラメータをフレキシブルに表示する追加の方法およびシステムを開示する。例えば、ＱＣＩは、前もって定義され、一定の数の量子化されたＱＣＩ値で設定されるものなので、ＱＣＩ値のみの使用ではフレキシビリティに限界があると思われる。新しいアプリケーションをさらにフレキシブルにし、かつ、ＱｏＳ粒度のレベルを上げるために、ＱｏＳパラメータの表示をよりフレキシブルにしてよい。例えば、最大パケット誤り率、遅延耐性、所望のスループット、最大許容ジッタ、最大パケット損失率、パケット損失間の最小距離、最大パケットサイズ、最小パケットサイズなどの多くの所望のＱｏＳパラメータを用いて、ＱｏＳ「ハイパースペース」、または、これらの相対的パラメータに基づいてパケットの所望のＱｏＳレベルを表す他の多軸の配置を定義してよい。
【００７８】
例えば、多くの所定のベース（例えば、最大パケット誤り率、遅延耐性、所望のスループット、最大許容ジッタ、最大パケット損失率、パケット損失間の最小距離、最大パケットサイズ、最小パケットサイズなどのＱｏＳパラメータ）によって定められるハイパースペースとして、割り当てられた、および／または、所望のＱｏＳの範囲を表すことによって、パケットは、該ベースの各々に割り当てられた値とアプリケーション要件に基づいて、差別化された処理を受けてよい。例えば、各ベースまたはＱｏＳパラメータは、ＱｏＳ要件の基本タイプを表してよく、アトミックＱｏＳパラメータと呼んでよい。所与のアプリケーションに用いるアトミックＱｏＳパラメータのＩＤおよび／または重みを決定することによって、ＱｏＳを、ハイパースペース内に（例えば、座標による）点として表してよい。
【００７９】
説明と例証の目的で、ビデオ符号化の例を考えてみよう。この例においては、ビデオパケットに最も関連があると思われるＱｏＳパラメータは、最大パケット誤り率、最大許容遅延、および、最小の所望スループットであろう。この３つのパラメータは、個々のパケットのＱｏＳを定義するためのアトミックＱｏＳパラメータと考えてよい。図３は、最大パケット誤り率、最大許容遅延、および、最小の所望スループットのアトミックＱｏＳパラメータの例に基づいたハイパースペースの例を示す。図３に示すように、ハイパースペースには数個の点があり、各点は、アトミックＱｏＳパラメータ（例えば、異なる所望のまたは割り当てられたＱｏＳ要件）の異なる組合せに対応してよい。従って、ＱｏＳ値を所定の値を量子化した数に限定するのではなく、ＱｏＳは、ＱｏＳハイパースペースを定義するアトミックＱｏＳパラメータの関数として表してよい。従って、第１のパケットストリームまたはサブストリームに、最大パケット誤り率の第１の値、最大許容遅延の第１の値、および／または、最小の所望のスループットの第１の値に対応するＱｏＳ値を割り当ててよく、第２のパケットストリームまたはサブストリームに、最大パケット誤り率の第２の値、最大許容遅延の第２の値、および／または、最小の所望のスループットの第２の値に対応するＱｏＳ値を割り当ててよい。
【００８０】
一例においては、ハイパースペースの各点は、指定のＱＣＩ値にマッピングしてよい。従って、図３の例においては、最大パケット誤り率の所望の値、最大許容遅延値の所望の値、最小の所望のスループットの所望の値に基づいて、所望のパケット処理に最も適合するＱＣＩを決定してよい。一例においては、アトミックＱｏＳパラメータのセットは、全てのネットワークオペレータによって同じように理解され、扱われるように、規格化してよい。こうすると、パケットが複数のＬＴＥ／ＳＡＥネットワークを通る時、これらのネットワークは、そのパケットに一貫したＱｏＳを提供することができる。
【００８１】
一例においては、ＥＰＳベアラは、ＱｏＳハイパースペースの所与の点または領域（例えば、アトミックＱｏＳパラメータの指定の値に対応する座標）に関連付けられてよく、ネットワークは、対応するＱｏＳ要件を満たすＥＰＳベアラを、そのベアラに関連付けられたハイパースペースの領域に割り当てるように構成してよい。さらに、最大パケット誤り率、最大許容遅延、および、最小の所望のスループットという３つのアトミックＱｏＳパラメータの例が本明細書に記載のビデオ符号化の例では用いられているが、他のパラメータを用いて、また、３つより多いまたは少ないアトミックＱｏＳパラメータを用いて、ハイパースペースを定義してよい。さらに、ビデオパケットに関する例を記載したが、ビデオ以外のアプリケーションも本明細書に記載のＱｏＳ要件のフレキシブルな定義を利用してよい。
【００８２】
実用のためには、ＱｏＳハイパースペースの座標を表すのに用いるビット数を減らすことが重要であると思われる。例えば、ハイパースペースのベースの役割をするアトミックＱｏＳパラメータは、使用可能な値の数を制限するために量子化してよい。例として、パケット遅延は、対応するステップサイズが５０ｍｓの３つのビットとして表してよい。このような表示例を表４に示す。本開示の範囲を逸脱することなく、他の量子化サイズを用いて遅延に関する粒度を増減してよいことは、理解されよう。例えば、より多くのビットを用いて、遅延粒度を上げて（例えば、ステップサイズを減らして）よく、より少ないビットを用いて、遅延粒度を減らして（例えば、ステップサイズを増やして）よい。
【００８３】
【表４】
2014527771.tif 000006
【００８４】
一例においては、パケット誤り率（ＰＥＲ）のアトミックＱｏＳパラメータは、例えば、指数表示を用いて３つのビットとして表してよい。そのような表示の例を表５に示す。本開示の範囲を逸脱することなく、他の量子化サイズを用いてＰＥＲに関する粒度を増減してよいことは、理解されよう。例えば、より多くのビットを用いてＰＥＲ粒度を上げて（例えば、ステップサイズを減らして）よく、より少ないビットを用いて、ＰＥＲ粒度を下げて（例えば、ステップサイズを増やして）よい。
【００８５】
【表５】
2014527771.tif 000007
【００８６】
一例においては、パケットスループットのアトミックＱｏＳパラメータは、例えば、指数表示を用いて３つのビットとして表してよい。このような表示の例を表６に示す。本開示の範囲を逸脱することなく、他の量子化サイズを用いてスループットに関する粒度を増減してよいことは理解されよう。例えば、より多くのビットを用いて、スループット粒度を上げて（例えば、ステップサイズを減らして）よく、より少ないビットを用いてスループット粒度を下げて（例えば、ステップサイズを増やして）よい。
【００８７】
【表６】
2014527771.tif 000008
【００８８】
上記の例において、ベストエフォートは、特定の要件に対応しなくてよい。例えば、ベストエフォートとしてマーク付けされたパケットに関しては、通信システムは、現在のリソースおよび／またはポリシーの元で、利用可能な最上のサービスの提供を試みてよい。言い換えれば、ネットワークは、要件がベストエフォート要件である場合、特定のＱｏＳパラメータに対して最低レベルのサービスを保証する必要はない。１つまたは複数のＱｏＳパラメータに関してベストエフォートＱｏＳ要件を利用可能なデータの例は、ウェブページ、一部のハイパーテキスト転送プロトコル（ＨＴＴＰ）要求および応答、および／または、他の遅延耐性データなどのＩＰデータを含んでよい。
【００８９】
一例においては、ＷＴＲＵは、所望のＱｏＳ要件および／または所望のＱｏＳパラメータレベルをネットワークに明示的に信号で伝えるように、または、要求するように構成されてよい。一般的に、ＷＴＲＵが実行中のアプリケーション、例えば、ビデオ会議アプリケーションは、通信ネットワークを介したアプリケーションデータの送信を有効にサポートするＱｏＳ要件および／またはＱｏＳパラメータレベルを決定または知っていてよい。典型的には、ＬＴＥ／ＳＡＥネットワークにおけるＥＰＳベアラに関するＱｏＳ要件は、該ネットワークに関してＰＣＣによって導き出されてよい。言い換えれば、ＷＴＲＵは、システムから受信するＱｏＳの決定において受動的であってよい。このようなアプローチによって、ＷＴＲＵが望むＱｏＳとは異なるＱｏＳを得る場合があり、（例えば、割り当てられたＱｏＳが所望の送信能力を達成するＱｏＳレベルより高い場合）ネットワークリソースの割り当てが良くないということになり、および／または、（例えば、割り当てられたＱｏＳが所望の送信能力を達成するＱｏＳレベルより低い場合）ＷＴＲＵから見てネットワーク性能が良くないということになる。さらに、ＷＴＲＵが所望のＱｏＳレベルを信号で伝えることができない場合、３ＧＰＰ規格の機能の更新は比較的時間のかかるプロセスなので、３ＧＰＰ通信ネットワークは、新しいビデオアプリケーションおよび／またはビデオコーデックに含まれる技術革新をサポートする最新のシステムを維持することができない場合がある。ＷＴＲＵが所望のＱｏＳレベルを信号で伝えるのを可能にすることによって、新しい技術革新をサポートするために３ＧＰＰ規格の時間のかかる変更を避けることができる。
【００９０】
一例においては、ＷＴＲＵは、ＬＴＥ／ＳＡＥネットワークに、ＷＴＲＵの所望のＱｏＳ要件を明示的に知らせてよい。そして、ＬＴＥ／ＳＡＥネットワークは、ＷＴＲＵに割り当てるのに適切（例えば、最適、可能な限りで最適なうちの１つ、最も適切）なＱｏＳパラメータ（複数可）を決定してよい。例えば、ネットワークは、ＷＴＲＵが接続を要求しているサブスクリプションサービスが許可するサービスに基づいて、ＷＴＲＵにどのＱｏＳパラメータを割り当てるかを決定してよい。ＷＴＲＵからＰＣＣアーキテクチャのＰＣＲＦへの１つまたは複数のメッセージは、所与のＱｏＳレベルを求める要求を含んでよい。ＰＣＲＦは、１つまたは複数のＷＴＲＵから受信した明示的なＱｏＳ要求を取り扱うように構成されてよい。一例においては、後方互換性を保証するために、ＷＴＲＵは、既存のシグナリングスキームを利用して、１つまたは複数のＱｏＳ要求を送ってよい。一例においては、ＷＴＲＵは、所望のＱｏＳレベルを明示的に指定することなく、既存のシグナリングの一定のパラメータを利用して、所望のＱｏＳレベルを求める要求を示してよい。
【００９１】
図４は、ＷＴＲＵによるＱｏＳ要求を用いてＥＰＳベアラを確立するプロセスの例を示す。ＷＴＲＵ４０２は、例えば、ｅＮＢ４０４を介して、ＬＴＥネットワークへの接続を試みてよい。接続プロセスの一部として、１つまたは複数のＥＰＳベアラを確立して、ＷＴＲＵ４０２への接続をサポートしてよい。ベアラ確立プロセスの一部として、４１４で、ＷＴＲＵ４０２は、アプリケーション情報、サービス情報、および／または、要求ＱｏＳパラメータ（複数可）の１つまたは複数を、接続のため、ＰＣＲＦ４０６（および／または他のＰＣＣノード）に送ってよい。例えば、ＷＴＲＵ４０２は、所望のビットレート、遅延、ビット誤り率（例えば、ＧＢＲ、ＭＢＲなど）、ブロック誤り率、ＱＣＩ値、ＱｏＳハイパースペース座標、および／または、要求されたベアラに適切であると決定された他のＱｏＳパラメータなどの、所望のＱｏＳパラメータ値を要求してよい。
【００９２】
一例においては、ＷＴＲＵ４０２は、１つまたは複数のサービスデータフロー（ＳＤＦ）に関して所望のＱｏＳパラメータを明示的に指定してよい。例えば、第１のＳＤＦに関して、ＷＴＲＵ４０２は、送信元ＩＰアドレス、送信先ＩＰアドレス、送信元ポート番号（例えば、送信元ポート３７２１）、送信先ポート番号（例えば、送信先ポート４８９２）、プロトコルタイプ（例えば、ＵＤＰは１７）、および／または、１つまたは複数のＱｏＳパラメータの１つまたは複数を示してよい。例えば、ＷＴＲＵ４０２は、第１のＳＤＦに関する所望のＱｏＳパラメータは、１００ｍｓ未満の遅延、および／または、１０−３未満のパケット損失率（ＰＬＥＲ）であることを示してよい。一例においては、第２のＳＤＦに関して、ＷＴＲＵ４０２は、送信元ＩＰアドレス、送信先ＩＰアドレス、送信元ポート番号（例えば、送信元ポート３７２２）、送信先ポート番号（例えば、送信先ポート５８９７）、プロトコルタイプ（例えば、ＵＤＰは１７）、および／または、１つまたは複数のＱｏＳパラメータの１つまたは複数を示してよい。例えば、ＷＴＲＵ４０２は、第２のＳＤＦに関する所望のＱｏＳパラメータは、２００ｍｓ未満の遅延、および／または、１０−２未満のパケット損失率（ＰＬＥＲ）であることを示してよい。第１のＳＤＦと第２のＳＤＦそれぞれに関するＱｏＳパラメータ要求は、ＷＴＲＵ４０２からの同じメッセージに含んでもよく、別々のメッセージに含んでもよい。
【００９３】
ＷＴＲＵ４０２にどのＱｏＳパラメータが適切であるかの決定を容易にするために、４１６で、ＰＣＲＦ４０６は、加入者プロファイルリポジトリ（ＳＰＲ）４０８に、ＷＴＲＵ４０２に関するサブスクリプションを要求してよい。ＳＰＲ４０８は、ＷＴＲＵ４０２に関するサブスクリプション情報を含む、サブスクリプション情報のデータベースを含んでよい。４１８で、ＳＰＲ４０８は、ＰＣＲＦ４０６に返信してよく、返信は、ＷＴＲＵ４０２のサブスクリプション情報を含んでよい。  
【００９４】
一例においては、４２０で、ＰＣＲＦ４０６は、ＷＴＲＵ４０に関する確立中のベアラ（複数可）に関して適切なＱｏＳパラメータを決定してよい。例えば、ＰＣＲＦ４０６は、アプリケーション情報、サービス情報、要求ＱｏＳパラメータ（複数可）、サブスクリプション情報、および／または、ＷＴＲＵ４０２に関する他の情報、の１つまたは複数に基づいて、適切なパラメータを決定してよい。一例においては、ＰＣＲＦ４０６は、まず、ＷＴＲＵ４０２が４１４で特定のＱｏＳパラメータを要求したか否かを決定してよい。要求していれば、ＰＣＲＦ４０６は、ＷＴＲＵ４０２のＱｏＳパラメータ要求に対応するＱｏＳパラメータ（例えば、ＱＣＩ、ＧＢＲ、ＭＢＲなど）を決定してよい。言い換えれば、ＰＣＲＦ４０６は、ＷＴＲＵ４０２が要求したＱｏＳパラメータに最も適合する、および／または、ＷＴＲＵ４０２が行った要求を満たす、ＱｏＳパラメータを識別するように試みてよい。決定されたＱｏＳパラメータが、ＷＴＲＵ４０２のサブスクリプションサービスに許可されると、対応するＱｏＳパラメータを有するベアラをＷＴＲＵ４０２に割り当ててよい。しかしながら、ＰＣＲＦ４０６は、ＷＴＲＵ４０２のサブスクリプション情報に従って、ＷＴＲＵが要求したＱｏＳパラメータはサポートされていないと決定する場合がある。その場合、ＰＣＲＦは、ＷＴＲＵ４０２が提供したアプリケーション情報、ＷＴＲＵ４０２が提供したサービス情報、および／または、ＷＴＲＵ４０２のサブスクリプション情報等の他の要素に基づいて、要求されたベアラに対して割り当てるＱｏＳパラメータを決定してよい。
【００９５】
所与のアプリケーションに適切なより多くのネットワークリソースを消費するリソースをＷＴＲＵが不適切に要求する（例えば、２００ｍｓの遅延がアプリケーション性能にほとんど影響を与えない場合に、１００ｍｓ以下の最大遅延を要求する）のを防ぐために、および／または、ＷＴＲＵが提供したサービスに対してネットワークオペレータが適切な料金を生成するのを保証するように、ＰＣＣ機能は、ＷＴＲＵ４０２が要求したＱｏＳ要件を許可、一部変更、および／または、拒絶してよい。例えば、要求を受諾、一部変更、および／または拒絶するか否かの決定は、加入者に許可されたサービスおよび／または他のポリシーに基づいてよい。
【００９６】
例えば、４２２で、ＰＣＲＦ４０６は、ＱｏＳ要求を受諾、一部変更、または拒絶するメッセージをＷＴＲＵ４０２に送ってよい。メッセージは、ＷＴＲＵのＩＤ、ＳＤＦ  ＩＤ、ＱｏＳの決定または理由（例えば、受諾、一部変更、拒絶など）、および／または、ＷＴＲＵに割り当てられたＱｏＳパラメータを示すものの１つまたは複数を含んでよい。例えば、４１４で要求したＱｏＳパラメータがＰＣＲＦ４０６で受諾された場合、受諾メッセージをＷＴＲＵ４０２に送ってよい。４１４で要求したＱｏＳパラメータがＰＣＲＦ４０６によって一部変更された場合、一部変更メッセージをＷＴＲＵ４０２に送ってよい。一部変更の場合は、決定したＱｏＳを提供してよく、および／または、それに関連した課金情報を含んでよい。一部変更メッセージは、どのパラメータが変更されたか、および／または、どのＱｏＳパラメータがＷＴＲＵに割り当てられたかを示してよい。ＷＴＲＵ４０２が要求したＱｏＳパラメータが拒絶された場合、拒絶メッセージをＷＴＲＵ４０２に送ってよい。拒絶の場合、ＱｏＳパラメータの提案が行われてよい。および／または、それに関連する課金情報を含んでよい。明示的なＱｏＳ要求が拒絶された場合、ＷＴＲＵは、元のＱｏＳ要求を訂正して、新しい要求を送ってよい。
【００９７】
ＰＣＲＦ４０６が、ＷＴＲＵ４０２が示したＳＤＦに関して（例えば、要求および／またはＳＰＲ４０８から受信したＷＴＲＵサブスクリプション情報に基づいて）適切なＱｏＳパラメータを識別すると、ＰＣＲＦ４０６は、ＷＴＲＵ４０２に関して選択されたＳＤＦ  ＩＤおよび／または関連付けられたＱｏＳパラメータに関する情報をＰＣＥＦ４１０に送ってよい。例えば、４２４で、ＰＣＲＦ４０６は、ＰＣＣルールをＰＣＥＦ４１０および／またはパケットゲートウェイ（Ｐ−ＧＷ）４１２に送ってよい。ＰＣＣルールは、ＷＴＲＵ４０２が要求したＱｏＳパラメータ、および／または、ＷＴＲＵ４０２のために作成されたベアラに対して割り当てられたＱｏＳパラメータを示すものを含んでよい。
【００９８】
ＰＣＥＦ４１０および／またはＰ−ＧＷ４１２は、次に、４２６で、ＷＴＲＵ４０２の要求に基づいて専用のＥＰＳベアラの確立を開始してよい。ＥＰＳベアラ設定の詳細は、図４には記載していないが、図示されていない１つまたは複数のエンティティ（例えば、サービングゲートウェイ（Ｓ−ＧＷ）、モビリティ管理エンティティ（ＭＭＥ：Ｍｏｂｉｌｉｔｙ  Ｍａｎａｇｅｍｅｎｔ  Ｅｎｔｉｔｙ）など）が、図４には示されていなくてもベアラ確立に関わってよい。ＥＰＳベアラが確立すると、ＳＤＦは、作成したＥＰＳベアラを介してコアネットワークを通してトランスポートされてよい。一例においては、複数のＳＤＦが類似のＱｏＳ要件に関連付けられてよく、従って、同じＥＰＳベアラに割り当てられてよい。
【００９９】
パケットは、パケットの個々の相対的優先度に基づいてフローから分割されるので、送信先のＷＴＲＵに到着する時、順序が違う場合がある。例えば、送信元および／または送信先のＷＴＲＵが、受信パケットを分割、マージ、および／または、再順序付けしてよい。パケットの分割は、パケット送信元で、異なるタイプのパケットの相対的重要度に従ってパケットストリーム（例えば、ビデオトラフィック）を複数のサブストリームに分割することを含んでよい。分割は、送信ネットワーク中も維持されてよく、ルーティングおよび／またはマージの時にパケット識別を容易にする。パケット分割に利用可能な方法の２つの例は、複数のポート番号の使用、および／または、ＩＰパケットヘッダに識別のためのフィールドを使用することを含んでよい。
【０１００】
アプリケーションストリームを複数のサブストリームに分割する、サブストリームをマージする、および／または、パケットの再順序付けをする方法は、ＬＴＥ／ＳＡＥシステムおよび／または他の高速データ通信システムによって適用されてよい。アプリケーションデータは、ビデオデータ、および／または、異なるタイプのパケットが異なる相対的重要度を有する他のアプリケーションであってよい。ビデオストリームの分割、マージ、および／または、再順序付けを適用可能なビデオコーデックの例には、Ｈ．２６４／ＡＶＣ、Ｈ．２６４／ＳＶＣ、および／または、ビデオパケットの相対的重要度に従ってアプリケーション層でビデオパケットを分割することができる他のビデオコーデックが含まれる。
【０１０１】
サブストリームの多重化／マージ、および／または、個々のパケットの再順序付けは、受信機で起こってよい。各サブストリームは、他のサブストリームとは別にネットワークによってルーティングされてよいので、送信路および／または、送信処理が異なり、パケットは送信先に違う順序で到着する場合がある。複数のサブストリームに分割する前を反映する元の順序にパケットを並べ直すために再順序付けを行ってよい。
【０１０２】
一例においては、ビデオアプリケーションが、送信のため、１つまたは複数のＮＡＬユニットをリアルタイムトランスポートプロトコル（ＲＴＰ）層に送ると、ＲＴＰパケットフォーマットを用いて送信されるＮＡＬユニットのタイプに関する情報、および／または、ビデオパケットの他の識別情報を保存してよい。例えば、ＲＴＰパケットヘッダには、ペイロードタイプ（ＰＴ：Ｐａｙｌｏａｄ  Ｔｙｐｅ）と呼ばれるフィールドがあり、その長さは７ビットであってよい。例えば、カンファレンス制御プロトコルを通して識別子の値を動的に割り当てるのに使用可能な値の範囲、例えば、９６から１２７の値がある。これらの値を用いて、ビデオコーデック（例えば、Ｈ．２６４／ＡＶＣ）に対して、異なるタイプのビデオパケットを識別してよい。例えば、第１の値（例えば、値、９６）は、優先度ＮＲＩ＝１１のＨ．２６４／ＡＶＣパケットに割り当ててよく、第２の値（例えば、値、９７）は、優先度ＮＲＩ＝１０のＨ．２６４／ＡＶＣパケットに割り当ててよく、第３の値（例えば、値、９８）は、優先度ＮＲＩ＝０１のＨ．２６４／ＡＶＣパケットに割り当ててよく、第４の値（例えば、値、９９）は、優先度ＮＲＩ＝００のＨ．２６４／ＡＶＣパケットに割り当ててよく、以下同様、となる。これらの値は、一例であり、他のＰＴ値を用いてもよい。一例においては、第１の値（例えば、値、９６）は、ｎａｌ＿ｕｎｉｔ＿ｔｙｐｅ＝５（例えば、ＩＤＲ）のＨ．２６４／ＡＶＣパケットに割り当ててよく、第２の値（例えば、値、９７）は、ｎａｌ＿ｕｎｉｔ＿ｔｙｐｅ＝２（パーティションＡ）のＨ．２６４／ＡＶＣパケットに割り当ててよく、第３の値（例えば、値、９８）は、ｎａｌ＿ｕｎｉｔ＿ｔｙｐｅ＝３（パーティションＢ）のＨ．２６４／ＡＶＣパケットに割り当ててよく、第４の値（例えば、値、９９）は、ｎａｌ＿ｕｎｉｔ＿ｔｙｐｅ＝４（パーティションＣ）のＨ．２６４／ＡＶＣパケットに割り当ててよく、以下同様、となる。
【０１０３】
このようなアプローチを用いて、パケットの識別子、および／または、パケットタイプ（例えば、ＮＡＬユニットのタイプ）をＲＴＰパケットヘッダに含めてよい。ＲＴＰパケットが送信のため下位の層に送られると、複数のＵＤＰソケットを開いてよい。開いた各ソケットは、異なるタイプのＲＴＰパケットおよび／または異なるパケット優先度に対応してよい。そうすることによって、ソケットは、それぞれ、異なるタイプのＮＡＬユニットに対応してよい。高速データ通信システムでは、各ＲＴＰパケットを全体として扱ってよいので、異なるタイプのＮＡＬユニットが単一のＲＴＰパケットに含まれるのを避けることができる。
【０１０４】
受信機側で、複数のサブストリームは、ビデオデコーダ用に単一のストリームにマージされてよい。受信側のＷＴＲＵは、マージを行うように構成されてよい。一例においては、ストリームの分割、および／または、サブストリームのマージは、ビデオコーデックとＲＴＰパケットエンコーダ間にミドルウェアを導入することによって行ってよい。一例においては、ストリームの分割、および／または、サブストリームのマージは、例えば、パケットの１つまたは複数の識別子を含むようにＲＴＰ符号化プロトコルを強化することによって行ってよい。サブストリームを受信機側でマージするとき、マージされたビデオパケットの順は違っている場合がある。従って、ビデオパケットをビデオデコーダに入力する前に、再順序付けを行ってよい。
【０１０５】
図５は、ミドルウェアモジュールを用いて、ビデオパケットの分割、マージ、および／または、再順序付けを行うためのプロトコルスタックの例を示す。例えば、ミドルウェア５０６は、ビデオアプリケーションの送信元に含まれてよく、ビデオ分割を行うように構成されてよい。ミドルウェア５１２は、ビデオアプリケーションの送信先に含まれてよく、パケットのマージおよび／または再順序付けを行うように構成されてよい。例えば、ビデオアプリケーションの送信元およびビデオアプリケーションの送信先は、ビデオセッション（例えば、ストリーミングビデオセッション）を確立してよい。セッション確立中または確立後、ミドルウェア５０２とミドルウェア５１２は、ビデオセッションのサポートに用いられる、ビデオパケットの分割、マージ、および／または、再順序付けのためのパラメータをやりとりしてよい。ビデオパケットの処理を容易にするために、ミドルウェア５０６は、ミドルウェア５１２との通信のためにポートまたはソケット（例えば、ポートＰ０）を構築してよい。例えば、該ポートは、ＴＣＰまたはＵＤＰポートであってよい。同様に、ミドルウェア５１２は、ミドルウェア５０６との通信のためにポートまたはソケット（例えば、ポートＰ４）を構築してよい。例えば、該ポートは、ＴＣＰまたはＵＤＰポートであってよい。しかしながら、ＳＳＴ（ｓｔｒｕｃｔｕｒｅｄ  ｓｔｒｅａｍ  ｔｒａｎｓｐｏｒｔ）、ストリーム制御送信プロトコル（ＳＣＴＰ：ｓｔｒｅａｍ  ｃｏｎｔｒｏｌ  ｔｒａｎｓｍｉｓｓｉｏｎ  ｐｒｏｔｏｃｏｌ）、データグラム輻輳制御プロトコル（ＤＣＣＰ：ｄａｔａｇｒａｍ  ｃｏｎｇｅｓｔｉｏｎ  ｃｏｎｔｒｏｌ  ｐｒｏｔｏｃｏｌ）、明示的な輻輳制御プロトコル（ＸＣＰ：ｅｘｐｌｉｃｉｔ  Ｃｏｎｇｅｓｔｉｏｎ  Ｃｏｎｔｒｏｌ  ｐｒｏｔｏｃｏｌ）などの他のタイプのトランスポートプロトコルを使ってよい。
【０１０６】
ミドルウェアエンティティ（例えば、ミドルウェア５０６およびミドルウェア５１２）は、ビデオエンコーダ５０２から受信したビデオパケットをトランスポートして、ビデオデコーダ５１４に送るために使用するサブストリームの数を決定してよい。一例においては、図５に示すように、ビデオパケットを送るために３つのサブストリームを構築するが、サブストリームの数は３つより多くても少なくてもよい。ビデオアプリケーションの送信元および／またはビデオアプリケーションの送信先は、各サブストリームに対してポートまたはソケットを構築してよい。例えば、ビデオアプリケーションの送信元は、ポートＰＩ、Ｐ２、Ｐ３を構築して、３つのサブストリームを介してビデオパケットを送ってよい。ＲＴＰ／ＳＲＴＰ５０８は、ビデオアプリケーションソースからサブストリームを送るように構成されたエンティティであってよい。図５に関して記載した例は、（例えば、ＵＤＰポートまたは他の何らかのトランスポートプロトコルを用いて）複数のサブストリームを送るためにＲＴＰまたはＳＲＴＰプロトコルを用いているが、他のタイプのストリーミングプロトコル（例えば、リアルタイムストリーミングプロトコル（ＲＴＳＰ）、マイクロソフトメディアサーバ（ＭＭＳ：Ｍｉｃｒｏｓｏｆｔ  Ｍｅｄｉａ  Ｓｅｒｖｅｒ）など）を用いてもよい。ビデオアプリケーションの送信元は、ポートＰ５、Ｐ６、Ｐ７を構築して、３つのサブストリームを介して、例えば、ＲＴＰ／ＳＲＴＰエンティティ５１０を介してビデオパケットを受信してよい。一例においては、ポートは、ＵＤＰポートであってよいが、他のトランスポートプロトコルも用いてよい。
【０１０７】
例えば、ビデオアプリケーションエンティティ間でやりとりされる明示的な制御パラメータがない場合に、サブストリームの数、および／または各サブストリームに関連付けられたパケットタイプを規定するためにデフォルト設定を用いてよい。一例においては、ユーザにインタフェースを与え、ユーザは所望の品質を指示してよい。要求される品質が高くなると、開かれるポート／サブストリームの数を増やして、例えば、異なるタイプのビデオパケットの処理の粒度を上げてよい。このようなアプローチは、ユーザのサブスクリプションプランに従って要求されるストリーミング機能が確実に許可されるように、ＰＣＣ機能を組み込んでよい。
【０１０８】
図６は、ミドルウェアによるアプローチを用いたビデオパケットの分割、マージ、および／または、再順序付けの手順の例を示す。例えば、６２０で、ビデオの送信元とビデオの送信先との間でビデオセッションを確立してよい。ミドルウェア６０２とミドルウェア６１２は、ビデオセッションをサポートするために使用するビデオパケットの分割、マージ、および／または、再順序付けのためのパラメータをやりとりしてよい。ビデオパケット処理を容易にするために、ミドルウェア６０６は、ミドルウェア６１２（例えば、ポートＰ０）と通信するポートまたはソケットを構築してよい。例えば、該ポートはＴＣＰまたはＵＤＰポートであってよい。同様に、ミドルウェア６１２は、ミドルウェア６０６（例えば、ポートＰ４）と通信するポートまたはソケットを構築してよい。例えば、該ポートは、ＴＣＰまたはＵＤＰポートであってよい。しかしながら、ＳＳＴ、ＳＣＴＰ、ＤＣＣＰなどの他のタイプのトランスポートプロトコルを用いてもよい。
【０１０９】
６２２で、ミドルウェア６０６および／またはミドルウェア６１２は、例えば、ユーザプリファレンスおよび／またはデフォルト設定に基づいて使用するサブストリームの数を決定してよい。例えば、ミドルウェア６０６および／またはミドルウェア６１２は、ビデオセッションに用いられる異なるタイプのＮＡＬＵの数を決定してよい。使用するストリームの数に関する決定に基づいて、個々のソケットを介してサブストリームをトランスポートするために、適切な数のポートまたはソケットを構築してよい。例えば、ビデオの送信元は、ポートＰ１、Ｐ２、Ｐ３を開いてよく、ビデオの送信先は、ポートＰ５、Ｐ６、Ｐ７を開いてよい。異なるサブストリームに対して開かれたソケット／ポートは、異なるＱｏＳパラメータに関連付けられてよく、サブストリームに含まれるパケットは、該サブストリームのソケットに関連付けられたＱｏＳパラメータに従って、送信ネットワークでルーティングされてよい。
【０１１０】
ビデオエンコーダ６０２は、ビデオデータを含むＮＡＬＵの生成を開始してよい。ビデオエンコーダ６０２からＮＡＬＵストリームを受信すると、６２４で、ミドルウェア６０６は、例えば、ＮＡＬＵストリーム内のパケットの相対的重要度および／または所望のＱｏＳに基づいて、ＮＡＬＵストリームを１つまたは複数のサブストリームに分けてよい。図６の例においては、ＮＡＬＵストリームを３つのサブストリームに分割してよい。一例においては、ミドルウェア６０６は、例えば、ＮＡＬＵストリームに含まれたパケットのＮＲＩ（例えば、２ビットであってよい）および／またはＮＡＬユニットタイプのフィールド（例えば、５ビットであってよい）を検査することによって、ＮＡＬＵのタイプに基づいて、ＮＡＬＵストリームを３つのサブストリームに分けて／分割してよい。適切なサブストリームを、ＮＡＬＵのタイプ（例えば、ＮＲＩおよび／またはＮＡＬユニットタイプ）を示すフィールドの値に基づいて決定してよい。
【０１１１】
ミドルウェア６０６は、ビデオアプリケーションの送信先で再順序付けを行うために、サブストリーム内のパケットにラベルを付けてよい、または、別の方法でパケットをどのようにサブストリームに分割したかを示してよい。例えば、ミドルウェア６０６は、ＮＡＬＵストリーム内のパケットに、シーケンス番号を含むヘッダを追加してよい。シーケンス番号は、複数のサブストリームに分割する前のパケットの相対的順序を示してよい。シーケンス番号は、ＮＡＬＵの順序を保存するように、ＲＴＰ／ＳＲＴＰパケットに割り当ててよい。ＲＴＰ／ＳＲＴＰのカプセル化中、サブストリームの一部または全ては、単一のシーケンス番号空間を共有してよく、共有されたシーケンス番号空間は、受信機側で複数のサブストリームの再順序付けに用いられてよい。一例においては、ミドルウェア６０６は、自身のヘッダを追加せずに、所与のパケットのシーケンス番号および／またはシーケンス番号を示すものをＲＴＰ／ＳＲＴＰエンティティ６０８に送ってよい。ＲＴＰ／ＳＲＴＰエンティティ６０８は、ビデオパケットに関するＲＴＰ／ＳＲＴＰヘッダにシーケンス番号を含んでよい。例えば、ＲＴＰ／ＳＲＴＰエンティティ６０８は、拡張ヘッダ（例えば、シーケンス番号）が標準的なＲＴＰヘッダとＲＴＰペイロードフィールドの間に含まれていることをＲＴＰパケットヘッダに示してよい。拡張ヘッダに示すものは、ＲＴＰヘッダにＸ（拡張子）フィールドを用いて表してよい。別の例においては、ペイロードタイプ（ＰＴ）フィールドを用いてシーケンス番号を示してよい。ＲＴＰ／ＳＲＴＰエンティティ６０８は、各サブストリームをビデオアプリケーションの送信先に送ってよい。例えば、各サブストリームは、別個のソケットまたはポート（例えば、ＵＤＰソケットまたはポート）に関連付けてよい。
【０１１２】
サブストリームは、ＲＴＰ／ＳＴＲＰ６１０を介して受信してよく、ミドルウェア６１２に送ってよい。６２６で、ミドルウェア６１２は、例えば、パケット分割中にパケットに付け加えられたシーケンス番号に基づいて、受信したパケットをマージおよび／または再順序付けしてよい。再順序付けは、これらのシーケンス番号に基づいて行ってよく、再構成されたＮＡＬＵストリームをビデオデコーダ６１４に渡す前に、シーケンス番号はパケットから取り除いてよい。一例においては、多くのビデオアプリケーションに関して、音声専用のストリームなどの他のストリームも生成してよい。これら他のストリームは、ビデオデータサブストリームと共に送信してもよい。
【０１１３】
ビデオアプリケーションの送信先で多重化プロセス中にビデオパケットの再順序付けをするときに、１つまたは複数のアプローチを用いてよい。例えば、ビデオの送信元のミドルウェアは、各ＮＡＬユニットにヘッダを追加してよい。ヘッダは、固有のシーケンス番号を含んでよく、この固有のシーケンス番号は、ビデオの送信先でパケットの再順序付けに用いてよい。一例においては、ミドルウェアは、ＲＴＰ／ＳＲＴＰサブストリームの一部または全てが同じシーケンス番号空間を共有するように、ＲＴＰパケットヘッダのシーケンス番号フィールドを利用してよい。ビデオの送信先で、ＲＴＰパケットヘッダのシーケンス番号は、再順序付けに用いられてよい。ＲＴＰ／ＳＲＴＰヘッダ情報が、各サブストリームの複数のパケットに割り当てられる固有のシーケンス番号を含むとき、異なるタイプのＮＡＬＵが同じＲＴＰ／ＳＲＴＰパケット内にカプセル化されないように、一例においては、各ＲＴＰ／ＳＲＴＰパケットは、ＮＡＬＵ１つを含むように構成される。別の例においては、固有のシーケンス番号を使用せずに、または、固有のシーケンス番号に追加して、パケットの再順序付けにタイムスタンプを用いてよい。例えば、ビデオエンコーダで各ＮＡＬＵは、タイムスタンプでマーク付けされてよく、ビデオデコーダのアプリケーションは、タイムスタンプを利用して複数のサブストリームを介して受信したパケットの再順序付けを行ってよい。
【０１１４】
後方互換性のために、送信元および／または送信先のミドルウェア（例えば、ミドルウェア６０６および／またはミドルウェア６１２）は、ビデオのピアアプリケーション／装置が、サブストリーム処理ミドルウェアの使用をサポートするか否か、および／または、インストールされたサブストリーム処理ミドルウェアを含むか否かを決定してよい。ピア装置（例えば、ビデオストリーミングセッションの相手側）が、適切なミドルウェアを含まない、および／または、サブストリームＮＡＬユニットの差別化をサポートしない場合、相手側装置にインストールされているミドルウェアは、パススルーエンティティとして機能してよい。例えば、ミドルウェアは、変更／カプセル化されていないＮＡＬＵストリームをビデオエンコーダからＲＴＰ／ＳＲＴＰエンティティ（例えば、ビデオ送信元側）に、または、変更／カプセル化されていないＮＡＬＵストリームをＲＴＰ／ＳＲＴＰエンティティからビデオデコーダ（例えば、ビデオの送信先側）に渡すだけでよい。  
【０１１５】
一例においては、ビデオパケットの分割、ビデオパケットのマージ、および／または、ビデオパケットの再順序付けなどの１つまたは複数の機能をサポート／実行するために、ＲＴＰおよび／またはＳＲＴＰ（および／または他の何らかのビデオストリーミングプロトコル）は一部変更されてよい。このような機能は、ＲＴＰビデオプロファイルと呼んでよい。
【０１１６】
図７は、ビデオパケットの分割、ビデオパケットのマージ、および／または、ビデオパケットの再順序付けのうちの１つまたは複数を行うために、ＲＴＰを強化するアプローチの例を示す。セッションコントロール７０４および／またはセッションコントロール７１０によって、ビデオアプリケーションの送信元とビデオアプリケーションの送信先間でストリーミングビデオセッションを確立してよい。セッションを確立すると、ビデオパケット（例えば、ＮＡＬユニットストリーム）は、ビデオエンコーダ７０２から出力されて、ビデオアプリケーションの送信先に送信されてよい。ビデオプロファイルデマルチプレクサ７０６は、ビデオエンコーダ７０２から出力されたＮＡＬユニットストリームに含まれるパケットを検査してよい。例えば、ビデオプロファイルデマルチプレクサ７０６は、ＮＡＬＵパケットタイプおよび／またはＮＡＬＵパケット優先度を検査するように強化されたＲＴＰ／ＳＲＴＰエンティティであってよい。一例においては、ビデオプロファイルデマルチプレクサ７０６は、ＮＡＬＵタイプ情報を（例えば、ミドルウェアに関して上述したのと類似の方法で、ＮＲＩ、ＮＡＬユニットタイプフィールドなどを検査）決定してよく、パケットの相対的優先度および／またはＮＡＬＵタイプに基づいて、ＮＡＬＵストリームを複数のサブストリームに分割／逆多重化してよい。ビデオプロファイルデマルチプレクサ７０６は、タイムスタンプおよび／またはシーケンス番号を各サブストリームのパケットに挿入してよい。例えば、ＲＴＰパケットヘッダの既存の３２ビットのタイムスタンプフィールド、および／または、１６ビットのシーケンス番号フィールドをこの目的に用いてよく、および／または、別のタイムスタンプ／シーケンス番号を生成してよい。次に、サブストリームはビデオアプリケーションの送信先に送られてよい。
【０１１７】
受信機側で、サブストリームは、ビデオプロファイルマルチプレクサ７０８によって受信されてよく、ビデオプロファイルマルチプレクサ７０８は、複数のサブストリームを、例えば、該サブストリームに含まれたパケットのタイムスタンプおよび／またはシーケンス番号に基づいて、マージおよび／または再順序付けするよう強化されたＲＴＰ／ＳＲＴＰエンティティであってよい。マージされたＮＡＬユニットストリームは、さらなる処理のため、ビデオデコーダ７１２に送られてよい。
【０１１８】
図８は、ＲＴＰビデオプロファイルアプローチを用いたビデオトラフィックの分割、マージ、および／または、再順序付けの手順の例を示す。例えば、８２０で、セッションコントロール８０４とセッションコントロール８１０間でビデオセッションを確立してよい。一例においては、セッションコントロール８０４とセッションコントロール８１０は、ビデオセッションのサポートに使用するビデオパケットの分割、マージ、および／または、再順序付けのためのパラメータのやりとりをしてよい。ビデオパケット処理を容易にするために、セッションコントロール８０４は、セッションコントロール８１０と通信するポートまたはソケット（例えば、ポートＰ０）を構築してよい。例えば、該ポートは、ＴＣＰまたはＵＤＰポートであってよい。同様に、セッションコントロール８１０は、セッションコントロール８０４と通信するポートまたはソケット（例えば、ポートＰ４）を構築してよい。例えば、該ポートは、ＴＣＰまたはＵＤＰポートであってよい。しかしながら、ＳＳＴ、ＳＣＴＰ、ＤＣＣＰ、ＸＣＰなどの他のタイプのトランスポートプロトコルを用いてもよい。
【０１１９】
８２２で、セッションコントロール８０４および／またはセッションコントロール８１０は、例えば、ユーザプリファレンスおよび／またはデフォルト設定に基づいて、使用するサブストリームの数を決定してよい。例えば、セッションコントロール８０４および／またはセッションコントロール８１０は、ビデオセッションに用いられる異なるタイプのＮＡＬＵの数を決定してよい。使用するストリームの数に関する決定に基づいて、適切な数のポートまたはソケットを、個々のソケットを介してサブストリームをトランスポートするために構築してよい。例えば、ビデオの送信元は、ポートＰ１、Ｐ２、Ｐ３を開いてよく、ビデオの送信先は、ポートＰ５、Ｐ６、Ｐ７を開いてよい。異なるサブストリームに対して開かれたソケット／ポートは、異なるＱｏＳパラメータに関連付けられてよく、サブストリームに含まれるパケットは、該サブストリームのソケットに関連付けられたＱｏＳパラメータに従って、送信ネットワークでルーティングされてよい。
【０１２０】
ビデオエンコーダ８０２は、ビデオデータを含むＮＡＬＵの生成を開始してよい。ビデオエンコーダ８０２からＮＡＬＵストリームを受信すると、８２４で、ＲＴＰ／ＳＲＴＰビデオプロファイル８０６は、例えば、ＮＡＬＵストリーム内のパケットの相対的重要度および／または所望のＱｏＳに基づいて、ＮＡＬＵストリームを１つまたは複数のサブストリームに分けてよい。図８の例においては、ＮＡＬＵストリームは、３つのサブストリームに分割してよい。一例においては、ＲＴＰ／ＳＲＴＰビデオプロファイル８０６は、例えば、ＮＡＬＵストリームに含まれるパケットのＮＲＩ（例えば、２ビットであってよい）および／またはＮＡＬユニットタイプフィールド（例えば、５ビットであってよい）を検査することによって、ＮＡＬＵタイプに基づいて、ＮＡＬＵストリームを３つのサブストリームに分けて／分割してよい。適切なサブストリームは、ＮＡＬＵタイプ（例えば、ＮＲＩおよび／またはＮＡＬユニットタイプ）を示すフィールドの値に基づいて決定してよい。
【０１２１】
ＲＴＰ／ＳＲＴＰビデオプロファイル８０６は、ビデオアプリケーションの送信先での再順序付けのために、サブストリームのパケットにラベルを付けてよい、または、他の方法で、どのようにしてパケットをサブストリームに分割したかを示してよい。例えば、ＲＴＰ／ＳＲＴＰビデオプロファイル８０６は、ＲＴＰ／ＳＲＴＰパケットのタイムスタンプフィールドおよび／またはシーケンス番号フィールドを、複数のサブストリームのパケットの相対的順序のインジケータとして用いてよい。シーケンス番号／タイムスタンプは、ＮＡＬＵの順序が保存されるようにＲＴＰ／ＳＲＴＰパケットに割り当てられてよく、受信機はシーケンス番号／タイムスタンプを用いて元のＮＡＬＵストリームを再生してよい。ＲＴＰ／ＳＲＴＰのカプセル化中、サブストリームの一部または全ては、単一のシーケンス番号空間を共有してよく、共有されたシーケンス番号空間は、受信機側で、複数のサブストリームの再順序付けに用いてよい。
【０１２２】
サブストリームは、ＲＴＰ／ＳＲＴＰビデオプロファイル８０８を介して受信されてよい。８２６で、ＲＴＰ／ＳＲＴＰビデオプロファイル８０６は、例えば、パケット分割中にパケットに追加したシーケンス番号／タイムスタンプに基づいて、受信したパケットを、マージおよび／または再順序付けしてよい。再順序付けは、これらのシーケンス番号に基づいて行ってよく、その後、シーケンス番号は、再構成したＮＡＬＵストリームをビデオデコーダ８１２に渡す前に、パケットから取り除いてよい。一例においては、多くのビデオアプリケーションに関して、音声専用ストリームなど他のストリームも生成してよい。これら他のストリームも、ビデオデータサブストリームと共に送ってよい。
【０１２３】
一例においては、（例えば、ミドルウェアおよび／またはＲＴＰ／ＳＲＴＰビデオプロファイルを用いた）上記のビデオストリームのパケットの相対的優先度を示すものを送るための技術の１つまたは複数を利用するのではなく、または、それに加えて、ビデオパケットのＩＰパケットヘッダの情報フィールドを利用してよい。例えば、ビデオパケットの相対的重要度の決定に用いた識別子もＩＰパケットヘッダに含まれる場合、送信ネットワーク内の中継ルータが、パケットの相対的重要度／タイプを示すものにアクセスし、決定することができてよい。ＮＡＬＵを含むＩＰパケットのペイロード部分の検査を避けるために、パケットの相対的重要度を示す識別子も、ＮＡＬＵヘッダではなく、または、ＮＡＬＵヘッダに追加して、ＩＰヘッダに含めてよい。このようなアプローチは、例えば、ＩＰパケットのペイロードがＩＰＳｅｃに関連付けられた共通ＥＳＰモードを用いて暗号化されている場合などのような、暗号化されたＩＰパケットのペイロードの検査の困難を軽減することになる。例えば、ポート番号がパケット識別子の一部である場合、このようなアプローチを用いてよい。
【０１２４】
ＩＰｖ４に関して、ＮＡＬユニットヘッダに含まれるＮＲＩおよび／またはＮＡＬユニットペイロードタイプフィールドは、ＮＡＬＵユニットの相対的重要度および／またはＮＡＬＵタイプを示すものを含んでよい。複数のソケット（例えば、ＵＤＰソケット）を開くのではなく、または、それに追加して、ビデオの送信元は、各サブストリームの送信に対してソケットを１つ開いてよい。ビデオの送信元は、次に、ＮＡＬＵを含むＲＴＰパケットをＵＤＰパケットにカプセル化し、（例えば、異なるタイプのＮＡＬＵを含む）異なるタイプのＵＤＰパケットを、それぞれ、異なるバッファに入れてよい。ビデオの送信元は、次に、各ＵＤＰバッファ／ＮＡＬＵタイプに対して、固有の差別化サービスコードポイント（ＤＳＣＰ）値を有するＩＰパケットにＵＤＰパケットをカプセル化してよい。
【０１２５】
図９は、ＩＰパケットが、ビデオパケットの分割、マージ、および／または、再順序付けの１つまたは複数に用いられる情報を含んでよいアプローチを示す。例えば、ビデオエンコーダ９０２は、ＮＡＬユニットビデオパケットストリームを出力してよく、その出力はＲＴＰ／ＳＲＴＰエンティティ９０４が受信してよい。ＲＴＰ／ＳＲＴＰエンティティ９０４は、ＲＴＰパケットヘッダ、例えば、ペイロードタイプフィールドに、ＮＡＬＵのタイプおよび／またはＮＡＬＵの相対的重要度を示すものを含んでよい。ＲＴＰ／ＳＲＴＰエンティティ９０４は、受信機側でパケットの再順序付けに用いてよいシーケンス番号および／またはタイムスタンプも含んでよい。ＮＡＬＵのタイプおよび／またはＮＡＬＵの相対的重要度は、ＮＡＬＵヘッダのＮＲＩフィールド、ＮＡＬユニットタイプフィールド、および／または、他の何らかのフィールドに基づいて決定してよい。ＲＴＰ／ＳＲＴＰエンティティ９０４は、ビデオ送信のためにソケット接続を開いてよい。ＵＤＰエンティティ９０６は、ＮＡＬＵを含むＲＴＰ／ＳＲＴＰストリームを、ＲＴＰ／ＳＲＴＰエンティティ９０４から受信してよい。ＵＤＰエンティティ９０６は、例えば、異なるバッファに関連付けられた異なるタイプのＵＤＰパケットにＲＴＰ／ＳＲＴパケットをカプセル化してよい。異なるタイプのＮＡＬＵを異なるＵＤＰバッファと関連付けることによって、ビデオパケットを複数のサブストリームに有効に分割してよい。
【０１２６】
ＵＤＰパケットは、次に、ＩＰエンティティ９０８に送られてよい。ＩＰエンティティ９０８は、次に、ＵＤＰパケットをＩＰパケットにカプセル化してよい。ＩＰパケットの１つまたは複数のフィールドは、ＩＰパケットにカプセル化された内在するＮＡＬＵのＮＡＬＵタイプおよび／または相対的重要度を示すものを含むように構成してよい。例えば、ＩＰｖ４に関して、ＤＳＣＰフィールドを用いて、パケットの相対的重要度および／またはＩＰパケットにカプセル化されたＮＡＬＵのタイプを示してよいが、ＩＰヘッダの他のフィールドも利用してよい。
【０１２７】
送信ネットワークを介してＩＰパケットを送るとき、送信ネットワーク内のルータは、ＩＰパケットヘッダの一部変更されたフィールド（例えば、ＤＳＣＰフィールド）に基づいて、パケットの相対的重要度、および／または、ＩＰパケットにカプセル化されたＮＡＬＵのタイプを決定してよい。ルータは、関連付けられたＮＡＬＵの所望のＱｏＳに従って、この情報を用いてパケットをルーティングしてよい。ビデオの送信先で送信ネットワークから出ると、ＩＰエンティティ９１０は、ＵＤＰエンティティ９１２にビデオパケットストリームを渡すために、カプセル化されたＵＤＰパケットを多重化するように構成されてよい。ＵＤＰエンティティ９１２は、ＲＴＰ／ＳＲＴＰパケットを非カプセル化し、ＲＴＰ／ＳＲＴＰエンティティ９１４に送ってよい。ＲＴＰ／ＳＲＴＰエンティティ９１４は、ＲＴＰ／ＳＲＴＰパケットに含まれたシーケンス番号および／またはタイムスタンプを用いて、ＮＡＬＵビデオストリームを再順序付けしてよい。再順序付けされたＮＡＬＵビデオストリームは、次に、復号化のためにビデオデコーダ９１６に送られてよい。
【０１２８】
ＮＡＬＵの相対的重要度および／またはタイプに関する情報がＩＰパケットに含まれる場合、ＬＴＥネットワークを介した送信のためのＥＰＳベアラ設定は、一部変更してよい。例えば、ＰＣＣエンティティ（例えば、ＰＲＣＦ）は、サービスデータフローのＩＤをＰ−ＧＷに知らせてよい。Ｐ−ＧＷのＰＲＥＦは、サービスデータフローを識別するために、例えば、通過する各ＩＰパケットの送信元ＩＰアドレスと送信先ＩＰアドレスを識別することによって、パケットのルーティング中にＤＳＣＰフィールドを検査してよい。ルーティング中、Ｐ−ＧＷは、サービスデータフローを既存のＥＰＳベアラにマッピングしてよい、または、新しいＥＰＳベアラの設定を開始してよい。どちらの場合も、サービスデータフローは、ＥＰＳベアラにマッピングしてよく、マッピングは、ＷＴＲＵに知らされてよい。
【０１２９】
サービスデータフローからＥＰＳベアラへのマッピングが決定すると、ＥＰＳベアラは、さらに論理チャネルにマッピングされてよく、ＭＡＣスケジューラが異なるタイプのパケットに対するサービスおよび／またはＱｏＳを差別化できるようにする。送信元のＷＴＲＵのビデオアプリケーション（例えば、ビデオエンコーダ）からの効率的な優先送信を容易にするために、Ｐ−ＧＷは、ＳＤＦ識別子（例えば、ＤＳＣＰフィールドなど）とＥＰＳベアラ間のマッピングを送信元のＷＴＲＵに送って、該ＷＴＲＵで後に（新しく）確立されたＥＰＳベアラの識別を容易にしてよい。ＷＴＲＵのＵＤＰモジュールは、ビデオ送信中に所与のパケットをどのＵＤＰバッファに割り当てるべきか決定するために、このマッピングを用いてよい。
【０１３０】
ＤＳＣＰフィールドではなく、またはＤＳＣＰフィールドに追加して、ＩＰｖ６を送信に使う場合、追加のフィールドは、内在するＮＡＬＵのタイプ、および／または、その相対的重要度に関する情報を含むように構成してよい。例えば、ＤＳＣＰ、トラフィッククラス、および／または、フローＩＤフィールドの１つまたは複数を用いて、この情報を伝えてよい。その手順は、ＩＰｖ４パケットのＤＳＣＰフィールドを用いる手順と同様であってよい。例えば、異なるバッファにあるＵＤＰパケットは、異なるトラフィッククラスの値および／または異なるフローＩＤの値と共に、ＩＰパケットにカプセル化してよい。このようにして、送信ネットワーク内のルータは、可能であれば、送信元ＩＰアドレスや送信先ＩＰアドレスなどの追加の情報と共に、ＩＰパケットのこれらのフィールドの１つまたは複数を検査することによって、異なるタイプのビデオパケットを識別してよい。
【０１３１】
ＩＰパケットヘッダフィールドから（例えば、ＬＴＥ／ＳＡＥの場合、ＱＣＩ値で示される）ＱｏＳレベルにマッピングするとき、マッピングは、動的および／または静的であってよい。静的な場合、使用されているマッピングのタイプを示すシグナリングは、省いてよい。動的な場合、ＵＥは、ネットワークに所望のマッピングを通知してよく、ネットワークは、提示されたマッピングを受諾、一部変更、および／または、拒絶して、端末（例えば、ＬＴＥ／ＳＡＥの場合はＷＴＲＵ）がネットワークリソースを乱用するのを避けてよい、および／または、ネットワークが提供するサービスに適切に課金することを保証してよい。
【０１３２】
一例においては、ビデオパケットのタイプに関する追加情報は、通信システムがビデオパケットの配信方法をよりフレキシブルにカスタマイズできるように、通信システムに公開されてよい。例えば、Ｈ．２６４／ＡＶＥビデオコーデックに関する例においては、ビデオパケット（例えば、ＮＡＬユニット）ヘッダ内に、ビデオパケットのタイプを示すのに使用可能な１つまたは複数のフィールド（例えば、２ビットのＮＲＩフィールド、５ビットのＮＡＬユニットタイプフィールドなど）があってよい。しかしながら、ビデオパケットは、ｓｌｉｃｅ＿ｔｙｐｅ情報に基づいて、さらに分類されてよい。ｓｌｉｃｅ＿ｔｙｐｅ情報は、１０の異なる潜在的値に関連付けられてよい。例えば、ｓｌｉｃｅ＿ｔｙｐｅ情報の異なる値は、Ｐスライス、Ｂスライス、Ｉスライス、ＳＰスライス、ＳＩスライスなどのタイプを表してよい。この情報は、ＮＡＬユニットのペイロードに含まれてよい。
【０１３３】
ｓｌｉｃｅ＿ｔｙｐｅによるＮＡＬＵの分類によって、一定のビデオアプリケーションおよび／または一定の通信システムに関して、より効率的なルーティング、および／または、より差別化されたＱｏＳ制御を促進してよい。例えば、このような情報の公開によって、通信システムが、異なるｓｌｉｃｅ＿ｔｙｐｅに対して、潜在的により良いと思われるＱｏＳを提供することを可能にしてよい。追加の数ビットをＮＡＬＵヘッダに加えてこの情報を示してよい、および／または、５ビットのＮＡＬユニットタイプフィールドの定義を、ｓｌｉｃｅ＿ｔｙｐｅ情報を伝えるために、一部変更してよい。この情報は、Ｈ．２６４／ＡＶＣ、Ｈ．２６４／ＳＶＣ、Ｈ．２６５などのビデオコーデック、および／または、他のビデオコーデックのＮＡＬＵヘッダに含まれてよい。
【０１３４】
本明細書に記載のように、次の方法または手順の１つまたは複数を用いて、単一のビデオストリーム内のビデオパケットに対してＱｏＳサービスの差別化を促進してよい。例えば、ＬＴＥ／ＳＡＥのＱＣＩ値を拡張してよい。ＱＣＩ値の拡張によって、現在の標準である９つの値を超えてＱＣＩ値の範囲を広げ、Ｈ．２６４／ＡＶＣや他のビデオコーデックに対応してよい。一例においては、ＱｏＳ要件／パラメータをフレキシブルに表示してよい。このようなアプローチによって、ＷＴＲＵ／ビデオの送信元および／またはビデオの送信先が、所与のアプリケーションに関わりなく、様々なパラメータまたは要素に基づいて所望のＱｏＳレベルを示すのを可能にしてよい。例えば、遅延、パケット誤り率、スループットなどのベースのセットを選択してよく、所望のＱｏＳレベルを、ベースによって定められたたハイパースペース内の点で表してよい。
【０１３５】
一例においては、ＷＴＲＵは、所望のＱｏＳパラメータを明示的に指定、および／または要求してよい。例えば、ＷＴＲＵは、ＱｏＳ割り当ての明示的な要求をＰＣＣエンティティに送ってよい。ＰＣＣエンティティは、このような明示的なＱｏＳ要件をより高い優先度で取り扱ってよく、および／または、明示的な要求を受信していない場合、ＷＴＲＵに関するＱｏＳ要件を引き出すことを続けてよい。このような手順は、１つまたは複数のベアラ確立メッセージに追加のコンテンツを含むことによって、および／または、ＰＣＣで手順を変更することによって、実施してよい。
【０１３６】
一例においては、ＷＴＲＵは、ビデオパケットを複数のビデオパケットサブストリームに分割、ビデオパケットサブストリームのマージ、および／または、ビデオパケットサブストリームに含まれたパケットの再順序付けの１つまたは複数を行うよう構成されてよい。例えば、ミドルウェアを用いて、ビデオパケットの分割、マージ、および／または、再順序付けの１つまたは複数を行ってよい。一例においては、ＲＴＰプロトコルは、ビデオパケットの分割、マージ、および／または、再順序付けの１つまたは複数を行うために、強化されてよい。例えば、ＮＡＬＵは、ＮＡＬＵヘッダ内のタイプおよび／または優先度情報に従って、複数のサブストリームに分割されてよい。該サブストリームにわたって単一のシーケンス番号空間を用いて、送信先で、マージされたサブストリームのパケットの再順序付けを容易にしてよい。一例においては、ＩＰヘッダを用いて、ビデオパケット（および／または他のパケット）のタイプに関する情報を伝えて、ＩＰ層より上位の層での情報の検査を不要にしてよい。
【０１３７】
一例においては、送信中のビデオパケット（および／または他のパケット）に関するより多くの情報をデータ送信ネットワークに公開する技術を用いてよい。例えば、より多くの情報をＮＡＬＵヘッダに付け加えて、Ｈ．２６４／ＡＶＣおよび／または他のビデオコーデックのペイロードのタイプを示してよい。
【０１３８】
特徴および要素を特定の組み合わせで上に記載したが、各特徴または要素は、単独で、または、他の特徴および要素との任意の組み合わせで使用できることを、当業者は理解されよう。さらに、本明細書に記載の方法は、コンピュータまたはプロセッサで実行されるコンピュータ可読媒体に組み込まれたコンピュータプログラム、ソフトウェア、またはファームウェアで実施してよい。コンピュータ可読媒体の例には、（有線および／または無線接続を介して送信される）電気信号、および、コンピュータ可読記憶媒体を含む。コンピュータ可読記憶媒体の例は、リードオンリメモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）、レジスタ、キャッシュメモリ、半導体メモリ装置、内蔵ハードディスクおよびリムーバブルディスク等の磁気媒体、光磁気記憶媒体、および、ＣＤ−ＲＯＭディスクおよびデジタル多用途ディスク（ＤＶＤ）などの光学媒体を含むが、それらに限定されない。プロセッサは、ソフトウェアと共に用いられて、ＷＴＲＵ、ＵＥ，端末、基地局、ＲＮＣ、または、任意のホストコンピュータで用いられる、無線周波数トランシーバを実施してよい。
【図１Ａ】
2014527771.tif 000009
【図１Ｂ】
2014527771.tif 000010
【図１Ｃ】
2014527771.tif 000011
【図１Ｄ】
2014527771.tif 000012
【図１Ｅ】
2014527771.tif 000013
【図２】
2014527771.tif 000014
【図３】
2014527771.tif 000015
【図４】
2014527771.tif 000016
【図５】
2014527771.tif 000017
【図６】
2014527771.tif 000018
【図７】
2014527771.tif 000019
【図８】
2014527771.tif 000020
【図９】
2014527771.tif 000021
【手続補正書】
【提出日】平成26年4月18日(2014.4.18)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
１または複数のネットワーク抽象化層ユニット（ＮＡＬＵ）を含むＮＡＬＵストリームを生成するステップであって、前記ＮＡＬＵのそれぞれは、ビデオストリームからのビデオ情報を含む、ステップと、
前記ＮＡＬＵを、少なくとも２つのサブストリームに分割するステップであって、各ＮＡＬＵサブストリームに関連付けられた前記ビデオ情報は、異なる重要度を持つ、ステップと、
前記サブストリームのそれぞれに関連付けられた前記ＮＡＬＵを、１または複数のパケットにカプセル化するステップと、
前記サブストリームのそれぞれに関連付けられた前記パケットを、ネットワーク上で送信するステップであって、前記サブストリームのそれぞれに関連付けられた前記パケットは、異なるポート番号を使用して送信される、ステップと、
を備えたことを特徴とするビデオパケット分割方法。
【請求項２】
前記ポート番号に基づいて前記サブストリームのそれぞれに関連付けられた前記パケットを前記ネットワークがルーティングできるようにするステップをさらに備えたことを特徴とする請求項１に記載の方法。
【請求項３】
前記ＮＡＬＵのそれぞれにミドルウェアヘッダを追加するステップをさらに備え、前記ミドルウェアヘッダはシーケンス番号を含み、および前記シーケンス番号は、前記ビデオストリームにおける前記ＮＡＬＵの順序を表示することを特徴とする請求項１に記載の方法。
【請求項４】
前記ＮＡＬＵのそれぞれに関連付けられる前記シーケンス番号は一意であることを特徴とする請求項３に記載の方法。
【請求項５】
前記サブストリームのそれぞれに関連付けられた前記パケットを受信するステップと、
前記ミドルウェアヘッダから前記シーケンス番号を決定し、および前記シーケンス番号に基づいて、前記受信したパケットからの前記ＮＡＬＵのそれぞれを、統合ＮＡＬＵストリームにマージするステップであって、前記ＮＡＬＵは、前記統合ＮＡＬＵストリームにおいて、前記ＮＡＬの前記順序を確立するようにマージされる、ステップと、
前記統合ＮＡＬＵストリームをビデオデコーダに送るステップと
をさらに備えたことを特徴とする請求項３に記載の方法。
【請求項６】
前記サブストリームのそれぞれは、異なる動的ペイロードタイプが割り当てられ、および前記動的ペイロードタイプは、前記サブストリームのそれぞれにおけるビデオ情報の重要度を表示することを特徴とする請求項１に記載の方法。
【請求項７】
前記動的ペイロードタイプは、前記サブストリームのそれぞれにおける前記ＮＡＬＵのネットワーク抽象化層基準識別（ＮＲＩ）値を表示することを特徴とする請求項６に記載の方法。
【請求項８】
前記動的ペイロードタイプは、カンファレンス制御プロトコルを使用してネゴシエートされることを特徴とする請求項６に記載の方法。
【請求項９】
１または複数のパケットを受信するステップであって、前記パケットは１または複数のポートを介して受信される、ステップと、
前記ポートを介して受信された前記パケットをストリームにマージするステップと、
前記ストリームにおける前記パケットのそれぞれに関連付けられたミドルウェアヘッダからシーケンス番号を決定するステップと、
前記ストリームの前記パケットを、前記シーケンス番号に基づいて、再順序付けするステップと
を備えたことを特徴とする方法。
【請求項１０】
前記ストリームにおける前記パケットのそれぞれから前記ミドルウェアヘッダを削除するステップと、
前記ストリームにおける前記パケットに関連付けられた１つまたは複数のネットワーク抽象化層ユニット（ＮＡＬＵ）をビデオデコーダに送るステップと
をさらに備えたことを特徴とする請求項９に記載の方法。
【請求項１１】
１つまたは複数のネットワーク抽象化層ユニット（ＮＡＬＵ）を含むＮＡＬＵストリームを生成し、前記ＮＡＬＵのそれぞれは、ビデオストリームからのビデオ情報を含み、
前記ＮＡＬＵを少なくとも２つのサブストリームに分割し、各ＮＡＬＵサブストリームに関連付けられた前記ビデオ情報は、異なる重要度を持ち、
前記サブストリームのそれぞれに関連付けられた前記ＮＡＬＵを１つまたは複数のパケットにカプセル化する
ように構成されたプロセッサと、
前記サブストリームのそれぞれに関連付けられた前記パケットをネットワーク上で送信し、前記サブストリームのそれぞれに関連付けられた前記パケットは、異なるポート番号を使用して送信される
ように構成された送信機と
を備えたことを特徴とする無線送受信ユニット（ＷＴＲＵ）。
【請求項１２】
前記ポート番号に基づいて前記サブストリームのそれぞれに関連付けられた前記パケットを前記ネットワークがルーティングできるようにするように前記プロセッサはさらに構成されたことを特徴とする請求項１１に記載のＷＴＲＵ。
【請求項１３】
前記ＮＡＬＵのそれぞれにミドルウェアヘッダを追加するように前記プロセッサはさらに構成され、前記ミドルウェアヘッダはシーケンス番号を含み、および前記シーケンス番号は、前記ビデオストリームにおける前記ＮＡＬＵの順序を表示することを特徴とする請求項１１に記載のＷＴＲＵ。
【請求項１４】
前記ＮＡＬＵのそれぞれに関連付けられる前記シーケンス番号は一意であることを特徴とする請求項１３に記載のＷＴＲＵ。
【請求項１５】
前記サブストリームのそれぞれに関連付けられた前記パケットを受信するように構成された受信機と、
前記ミドルウェアヘッダから前記シーケンス番号を決定し、および前記シーケンス番号に基づいて、前記受信したパケットからの前記ＮＡＬＵのそれぞれを、統合ＮＡＬＵストリームにマージし、前記ＮＡＬＵは、前記統合ＮＡＬＵストリームにおいて、前記ＮＡＬの前記順序を確立するようにマージされ、
前記結合ＮＡＬＵストリームをビデオデコーダに送る
ように構成された受信プロセッサと
をさらに備えたことを特徴とする請求項１３に記載のＷＴＲＵ。
【請求項１６】
前記サブストリームのそれぞれは、異なる動的ペイロードタイプが割り当てられ、および前記動的ペイロードタイプは、前記サブストリームのそれぞれにおけるビデオ情報の重要度を表示することを特徴とする請求項１１に記載のＷＴＲＵ。
【請求項１７】
前記動的ペイロードタイプは、前記サブストリームのそれぞれにおける前記ＮＡＬＵのネットワーク抽象化層基準識別（ＮＲＩ）値を表示することを特徴とする請求項１６に記載のＷＴＲＵ。
【請求項１８】
前記動的ペイロードタイプは、カンファレンス制御プロトコルを使用してネゴシエートされることを特徴とする請求項１６に記載のＷＴＲＵ。
【請求項１９】
１または複数のパケットを受信するように構成された受信機であって、前記パケットは１または複数のポートを介して受信される、受信機と、
前記ポートを介して受信された前記パケットをストリームにマージし、
前記ストリームにおける前記パケットのそれぞれに関連付けられたミドルウェアヘッダからシーケンス番号を決定し、
前記ストリームの前記パケットを、前記シーケンス番号に基づいて、再順序付けする
ように構成されたプロセッサと
を備えたことを特徴とする無線送受信ユニット（ＷＴＲＵ）。
【請求項２０】
前記ストリームにおける前記パケットのそれぞれから前記ミドルウェアヘッダを削除し、
前記ストリームにおける前記パケットに関連付けられた１つまたは複数のネットワーク抽象化層ユニット（ＮＡＬＵ）をビデオデコーダに送る
ように前記プロセッサがさらに構成されたことを特徴とする請求項１９に記載のＷＴＲＵ。
【国際調査報告】
2014527771.tif 000022
2014527771.tif 000023
2014527771.tif 000024
2014527771.tif 000025
2014527771.tif 000026