(57)【特許請求の範囲】
【請求項１】
通信ネットワーク（Ｎ）を介する別のデバイスとのパケットフロー（Ｆ）を確立するための手段と、前記パケットフローのタイプに基づいてプライオリティインジケータ（ｐ）の第１の値（ｖ１）を決定するための手段と、前記パケットフローの確立を可能にするために、前記別のデバイスとシグナリングメッセージ（ｓ１、ｓ２、ｓ３）を交換するための手段とを備え、前記第１の値を前記シグナリングメッセージのうちの第１のシグナリングメッセージ（ｓ１）に挿入するための手段と、前記プライオリティインジケータの受信値を含む第２のシグナリングメッセージ（ｓ２）を受信したとき、確立されたパケットフローのプライオリティインジケータの決定値として、前記受信値を含む第３のシグナリングメッセージ（ｓ３）を送信するための手段とをさらに有する、ネットワークデバイス（Ａ）。
【請求項２】
前記受信値が、前記第１の値と前記パケットフローのタイプに基づいて前記別のデバイスが決定する値のうちの大きい方の値である、請求項１に記載のネットワークデバイス。
【請求項３】
前記プライオリティインジケータが、ＤｉｆｆＳｅｒｖメカニズムに準拠し、前記ネットワークデバイスが、前記決定値を前記パケットフローのパケットのフィールド「ＤＳフィールド」に挿入するように構成される、請求項１および２のいずれか１項に記載のネットワークデバイス。
【請求項４】
前記第１の値を、前記第１のシグナリングメッセージ内のＳＤＰプロトコルに準拠したアトリビュートに挿入するように構成された、請求項１から３のいずれか１項に記載のネットワークデバイス。
【請求項５】
前記シグナリングメッセージが、ＳＩＰプロトコルに従ったメッセージである、請求項１から４のいずれか１項に記載のネットワークデバイス。
【請求項６】
通信ネットワーク（Ｎ）を介する別のデバイスとのパケットフロー（Ｆ）を確立するための方法であって、前記パケットフローのタイプに基づいてプライオリティインジケータ（ｐ）の第１の値（ｖ１）を決定するステップと、前記パケットフローの確立を可能にするために、前記別のデバイスとシグナリングメッセージ（ｓ１、ｓ２、ｓ３）を交換するステップとを含み、前記第１の値が、前記シグナリングメッセージのうちの第１のシグナリングメッセージ（ｓ１）に挿入され、前記プライオリティインジケータの受信値を含むシグナリングメッセージ（ｓ２）を受信すると、確立されたパケットフローのプライオリティインジケータの決定値として、前記受信値（ｖ３）を含む第３のシグナリングメッセージ（ｓ３）が送信される、方法。
【請求項７】
前記受信値が、前記第１の値と前記パケットフローのタイプに基づいて前記別のデバイスが決定する値のうちの大きい方の値である、請求項６に記載の方法。
【請求項８】
前記プライオリティインジケータが、ＤｉｆｆＳｅｒｖメカニズムに準拠し、前記決定値を前記パケットフローのパケットのフィールド「ＤＳフィールド」に挿入するように構成される、請求項６および７のいずれか１項に記載の方法。
【請求項９】
前記第１の値が、前記第１のシグナリングメッセージ内のＳＤＰプロトコルに準拠したアトリビュートに挿入される、請求項６から８のいずれか１項に記載の方法。
【請求項１０】
前記シグナリングメッセージは、ＳＩＰプロトコルに従ったメッセージである、請求項６から９のいずれか１項に記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、マルチメディア通信ネットワークに関する。これらのネットワークは、様々なアプリケーション：電話、テレビ電話、ウェブブラウジング、ファイルダウンロード、（「インスタントメッセージング」または「チャット」としても知られる）リアルタイムテキストディスカッションなどに対応する、（音声、ビデオ、データなど）異なるタイプのトラフィックを送信することができる。
【背景技術】
【０００２】
これらの種類のトラフィックは、従来、パケットフローの形式で、（「インターネットプロトコル」の場合は）特にＩＰパケットの形式で送信される。同じアプリケーションメッセージは、複数のＩＰパケットで送信することができるが、アプリケーションに送り届ける前に、受信時に再構成しなければならない。
【０００３】
これらのアプリケーションおよびトラフィックタイプは、異なるサービス品質基準に関連付けられるが、ネットワーク送信容量には限りがあるので、あるアプリケーション／トラフィックペアには他のペアよりも高いプライオリティを与える必要が生じる。
【０００４】
例えば、音声通話では、いくつかのパケットに遅延が生じると、音声品質の低下を招くことがある。最悪のシナリオでは、オーディオメッセージが聞こえない、または理解できないことがある。
【０００５】
ウェブブラウジングの場合、いくつかのパケットに生じた遅延によって、システムが遅くなったと感じることもないわけではないが、ほとんどの場合、影響は認知できない。
【０００６】
したがって、データトラフィックと比べた場合、音声トラフィックにより大きな重要度を与えるのが自然であろう。
【０００７】
ネットワークによって送信される異なるデータフローにプライオリティを割り当てることを可能にする、技術的ソリューションが存在する。それらのソリューションの１つは、特にＩＥＴＦのＲＦＣ２４７４「ＩＰｖ４およびＩＰｖ６ヘッダにおける差別化サービスフィールド（ＤＳフィールド）の定義（Ｄｅｆｉｎｉｔｉｏｎ  ｏｆ  ｔｈｅ  Ｄｉｆｆｅｒｅｎｔｉａｔｅｄ  Ｓｅｒｖｉｃｅｓ  Ｆｉｅｌｄ  （ＤＳ  Ｆｉｅｌｄ）  ｉｎ  ｔｈｅ  ＩＰｖ４  ａｎｄ  ＩＰｖ６  Ｈｅａｄｅｒｓ）」において説明されているような、ＤｉｆｆＳｅｒｖメカニズムである。
【０００８】
このＤｉｆｆＳｅｒｖメカニズムの原理は、その値がサービスクラス（またはコードポイント（ｃｏｄｅ  ｐｏｉｎｔ））を決定するＤＳフィールドと呼ばれるフィールドを、フローのパケットに挿入するというものである。パケットフローの経路上に存在するネットワークデバイス（ルータ、ゲートウェイなど）は、ＤＳフィールドを読み、その値に基づいて、最高サービスクラスパケットがトッププライオリティパケットになるように、パケットの再送を処理しなければならない。
【０００９】
このように、高いサービス品質を必要とするフローには、そうでないフローよりも高い優先権を、通信ネットワークによって与えることができる。
【００１０】
しかし、サービスクラスをどのように決定しなければならないかを規定できるメカニズムは存在しない。サービスクラスをパケットフローに挿入する各デバイスが、独自のメカニズムに基づいて、および管理が必要になる可能性がある様々なフローに基づいて、値を決定する。これらのメカニズムは、機器の供給業者によって決まることがある。
【００１１】
その結果、双方向通信の場面では、両方の端末（または対応するアクセスデバイス）が、サービスクラスを決定するのに異なるポリシーを使用するという事態がしばしば起こり得る。各方向のフローは、異なるサービスクラスに属するので、それらに対する通信ネットワークの挙動が異なり、サービス品質が２つの方向で異なって感じられるようになる。
【００１２】
例えば、双方向音声通話の場合、エコーセンシティブ（ｅｃｈｏ−ｓｅｎｓｉｔｉｖｅ）なネットワークに接続されたデバイスのフローは、時間遅延の短縮を必要とすることがある。これが行われない場合、ユーザは、エコー問題に悩まされることがある（時間遅延パラメータはエコー認知を高める）。
【先行技術文献】
【非特許文献】
【００１３】
【非特許文献１】ＲＦＣ  ２４７４  ｏｆ  ｔｈｅ  ＩＥＴＦ、「Ｄｅｆｉｎｉｔｉｏｎ  ｏｆ  ｔｈｅ  Ｄｉｆｆｅｒｅｎｔｉａｔｅｄ  Ｓｅｒｖｉｃｅｓ  Ｆｉｅｌｄ  （ＤＳ  Ｆｉｅｌｄ）  ｉｎ  ｔｈｅ  ＩＰｖ４  ａｎｄ  ＩＰｖ６  Ｈｅａｄｅｒｓ」
【非特許文献２】ＲＦＣ  ３２６１  ｏｆ  ｔｈｅ  ＩＥＴＦ、「Ｓｅｓｓｉｏｎ  Ｉｎｖｉｔａｔｉｏｎ  Ｐｒｏｔｏｃｏｌ」
【非特許文献３】ＲＦＣ  ４５６６  ｏｆ  ｔｈｅ  ＩＥＴＦ
【発明の概要】
【発明が解決しようとする課題】
【００１４】
本発明の目的は、認知されるサービス品質が通信セッションのすべての方向で同じになることを保証するメカニズムを提供することによって、この問題を改善することである。
【課題を解決するための手段】
【００１５】
これを行うために、本発明が対象とするのは、通信ネットワークを介する別のデバイスとのパケットフローを確立するための手段と、そのデータフローのタイプに基づいて、プライオリティインジケータ（ｐｒｉｏｒｉｔｙ  ｉｎｄｉｃａｔｏｒ）の第１の値を決定するための手段と、データフローの確立を可能にするために、その別のデバイスとシグナリングメッセージを交換するための手段とを備える、ネットワークデバイスである。本発明のデバイスは、その第１の値をシグナリングメッセージのうちの第１のシグナリングメッセージに挿入するための手段と、プライオリティインジケータの受信値（ｒｅｃｅｉｖｅｄ  ｖａｌｕｅ）を含むシグナリングメッセージ（ｓ１、ｓ２）を受信した場合は常に、受信値に基づいて送信値（ｓｅｎｔ  ｖａｌｕｅ）を決定し、その送信値をパケットフローのパケットに挿入するための手段とをさらに有する。
【００１６】
本発明のさらなる対象は、通信ネットワークを介する別のデバイスとのパケットフローを確立するための方法であり、方法は、データフローのタイプに基づいて、プライオリティインジケータの第１の値を決定するステップと、データフローの確立を可能にするために、その別のデバイスとシグナリングメッセージを交換するステップとを含む。第１の値は、それらのシグナリングメッセージのうちの第１のシグナリングメッセージに挿入される。そのプライオリティインジケータの受信値を含むシグナリングメッセージを受信すると、送信値が、その受信値に基づいて決定され、パケットフローのパケットに挿入される。
【００１７】
本発明の一実施形態によれば、送信値は、受信値とパケットフロータイプに基づいてデバイスが決定する値のうちの大きい方の値である。
【００１８】
プライオリティインジケータは、ＤｉｆｆＳｅｒｖメカニズムに準拠することができ、デバイスは、そのような場合、第３の値をパケットフローの「ＤＳフィールド」のフィールドに挿入するように構成することができる。
【００１９】
送信値は、シグナリングメッセージ内のＳＤＰプロトコルに従ってアトリビュートに挿入することができる。
【００２０】
送信値は、パケットフローのパケットの「ＤＳフィールド」のフィールドに挿入することができる。
【００２１】
本発明は、添付の図面を参照する以下の説明において、より明瞭に明らかとなろう。
【図面の簡単な説明】
【００２２】
【図１】通信ネットワークによって接続された、本発明を実施する２つのデバイスの間で交換されるメッセージを示す図である。
【発明を実施するための形態】
【００２３】
通信ネットワーク、特に「インターネット」データネットワーク上でのセッションの実施は、一般に、２つのフェーズ：セッションの当事者がシグナリングメッセージを交換する間の確立フェーズと、当事者がデータ：音声、ビデオ、テキストなどを交換する間の通信フェーズとを含む。
【００２４】
図１に示される実施では、２つのデバイスＡとＢは、通信ネットワークＮを介して接続される。しかし、本発明は、当事者がより多くても、すなわち、音声会議通話またはビデオ会議通話の場合にも適用することができる。２つのデバイスは、通信端末：固定電話またはモバイル電話、コンピュータ、携帯情報端末（またはＰＤＡ）などとすることができる。
【００２５】
デバイスは、サーバなど、サービスプロバイダによってホストされるデバイスとすることもできる。例えば、通信は、端末のユーザがオーディオコンテンツ、ビデオコンテンツなどにアクセスすることを可能にする、コンテンツサーバと通信端末の間の通信とすることができる。デバイスは、仮想デバイスとすることもできる。
【００２６】
図１の例では、デバイスＡが通信セッションの生成を開始すると仮定される。デバイスＡは、デバイスＢに第１のシグナリングメッセージＳ１を送信する。一般に、そのメッセージは、ＩＥＴＦのＲＦＣ３２６１「セッション招待プロトコル（Ｓｅｓｓｉｏｎ  Ｉｎｖｉｔａｔｉｏｎ  Ｐｒｏｔｏｃｏｌ）」において定義されているような、ＳＩＰプロトコルに従ったｉｎｖｉｔｅメッセージとすることができる。
【００２７】
「Ｉｎｖｉｔｅ」メッセージは、通信ネットワークＮ内の、「ＳＩＰプロキシ」などの、異なる装置によって中継することができる。それらの装置は、本発明そのものには影響しないので、図１に示されておらず、さらなる説明は行わない。
【００２８】
デバイスＡは、通信セッションを構成しなければならないデータフローのタイプに基づいて、プライオリティインジケータｐの値を決定するための手段を有する。ここで言う「タイプ」とは、送信されるデータの種類：ビデオ、オーディオ、オーディオビデオ、リアルタイムの「メッセージング」テキストまたは「チャット」テキストなどのことである。タイプは、より具体的にもでき、「ビデオ」などの汎用タイプを複数のタイプに分割することが可能なことがある。
【００２９】
一般に、デバイスＡの供給業者は、それらの異なるデータフローのタイプとプライオリティインジケータの値のマッチングを行うルックアップテーブルを設定する。
【００３０】
そのプライオリティインジケータは、好ましくは、ＲＦＣ２４７４「ＩＰｖ４およびＩＰｖ６ヘッダにおける差別化サービスフィールド（ＤＳフィールド）の定義」によって規定されているような、ＤｉｆｆＳｅｒｖメカニズムに準拠する。デバイスＡは、データフロータイプと「コードポイント」のマッチングを行うルックアップテーブルに直接的にアクセスするように動作することができる。
【００３１】
本発明によれば、デバイスは、その値ｖｌを、第１のシグナリングメッセージＳ１、すなわち、ｉｎｖｉｔｅメッセージに挿入するための手段を有する。その値は、ＩＥＴＦのＲＦＣ４５６６によって定義されているような、ＳＤＰ（セッション記述プロトコル（Ｓｅｓｓｉｏｎ  Ｄｅｓｃｒｉｐｔｉｏｎ  Ｐｒｏｔｏｃｏｌ））プロトコルの適切なアトリビュートに挿入することができる。
【００３２】
このアトリビュートは、８ビット長とすることができる。このアトリビュートは、例えば、「トラフィッククラス（Ｔｒａｆｆｉｃ−ｃｌａｓｓ）」と名付けることができる。
【００３３】
ＡＢＮＦ（拡張バッカス−ナウア記法（Ａｕｇｍｅｎｔｅｄ  Ｂａｃｋｕｓ−Ｎａｕｒ  Ｆｏｒｍ））文法によれば、このアトリビュートは、以下の形式：
Ｔｒａｆｆｉｃ−ｃｌａｓｓ＝“ａ＝ｔｒａｆｆｉｃ−ｃｌａｓｓ：”  Ｔｒａｆｆｉｃ−ｃｌａｓｓ−ｖａｌｕｅ
Ｔｒａｆｆｉｃ−ｃｌａｓｓ−ｖａｌｕｅ＝＊ＤＩＧＩＴ
を取ることができる。
【００３４】
このアトリビュートが取ることのできる値は、０から２５５までの整数である。
【００３５】
図の例では、タイプ：ａ＝ｔｒａｆｆｉｃ−ｃｌａｓｓ：ｖ１を有するＳＤＰを、ＳＩＰ「Ｉｎｖｉｔｅ」メッセージＳ１内に見出すことができる。
【００３６】
シグナリングメッセージＳ１を受信すると、デバイスＢは、プライオリティインジケータｐのその受信値ｖ１を読まなければならない。
【００３７】
デバイスＢは、そのシグナリングメッセージＳ２内に、プライオリティインジケータｐの「送信」値を挿入するための手段も有する。その送信値は、受信値ｖ１に基づいて決定される。
【００３８】
本発明の一実施形態によれば、その送信値（ｖ３）は、受信値に等しい。
【００３９】
本発明の別の実施形態によれば、その送信値は、受信値ｖ１とデータフローのタイプに基づいて決定された値のうちの大きい方に等しい。これが可能なのは、デバイスＡのように、デバイスＢも、データフローのタイプに関連付けられたプライオリティインジケータｐの値ｖ２を決定するための手段を有するからである。デバイスＢは、シグナリングメッセージＳ１の他のフィールドおよびアトリビュートを使用して、データフローのタイプを決定することができる。特に、その値ｖ２を決定するために、ＳＤＰのメディア記述のアトリビュート「ｍ」を使用することができる。
【００４０】
したがって、メッセージＳ２に挿入される値は、値ｖ３＝ｍａｘ（ｖ１，ｖ２）である。
【００４１】
メッセージＳ２は、アトリビュートａ＝ｔｒａｆｆｉｃ−ｃｌａｓｓ：ｖ３を含む。
【００４２】
メッセージＳ２を受信すると、デバイスＡは、そのアトリビュートを読み、その値がｖ３であることを知る。
【００４３】
状況によっては、デバイスＡは、後続のシグナリングメッセージＳ３を返送することができる。これは、ＳＩＰ「ＡＣＫ」メッセージとすることができる。
【００４４】
その時点では、両方のデバイスは、すでに［不完全な文］であるので、プライオリティインジケータをＳＩＰ「ＡＣＫ」メッセージに挿入する必要はない。しかし、本発明は、明らかに、そのインジケータが潜在的な他のシグナリングメッセージＳ３に挿入されるケースに適用される。
【００４５】
デバイスＡおよびＢは、シグナリングメッセージの間にネゴシエートされた項目およびパラメータ（ＣＯＤＥＣなど）に基づいて、通信ネットワークＮを介するパケットフローＦを確立するための手段も有する。
【００４６】
デバイスＡおよびＢは、先に決定されたプライオリティインジケータの値、すなわち、その値ｖ３を、それらのパケット内に挿入することができる。
【００４７】
先に述べたように、その値は、ＤｉｆｆＳｅｒｖ仕様に準拠することができる。特に、その値は、ＩＥＴＦのＲＦＣ２４７４のセクション３において規定されているように、６ビットのＤＳＣＰフィールド（差別化サービスコードポイント（Ｄｉｆｆｅｒｅｎｔｉａｔｅｄ  Ｓｅｒｖｉｃｅｓ  ＣｏｄｅＰｏｉｎｔ））を有する、８ビット長とすることができる。
【００４８】
したがって、プライオリティインジケータの値は、発信パケットの「ＤＳフィールド」のフィールドに直接的に挿入することができる。
【００４９】
パケットのＤＳフィールドへの挿入は、それ自体が知られた方法で行われる。対照的に、挿入される値を決定する方法は、新規なものであり：したがって、本発明によれば、本発明に従うデバイスは、パケットフローのために使用するＤｉｆｆＳｅｒｖインジケータとして、そのフローに関して最後に受信したシグナリングメッセージにおいて受け取った値を選択しなければならない。
【００５０】
このように、パケットフローは、両方の方向において同じＤｉｆｆＳｅｒｖ値を有する。したがって、パケットの送信は対称的であり、２つのデバイスＡおよびＢによって認知されるサービス品質は同じである。
【００５１】
上で説明された実施形態は、ＤｉｆｆＳｅｒｖメカニズムを使用するが、本発明は、そのタイプのメカニズムに限定されず、むしろ、本発明は、データパケットのプライオリティインジケータまたはサービス品質インジケータを定めることが可能な任意のプロトコルに適用することができる。
【図１】
0005941914.tif 000002