(57)【特許請求の範囲】
【請求項１】
TCP/IPプロトコルに準拠した２つのソケットに結びつけられたアプリケーションの通信方法であり、前記２つのアプリケーションのソケットは、同じIPアドレス及びポートに結びつけられる通信方法であって、
いずれかのアプリケーションのレベルで、そのソケットで受信したユニキャストパケットを検出すると、前記ユニキャストパケットの宛先IPアドレスをローカルホストアドレスに置換し、前記ユニキャストパケットを転送するステップを有する通信方法。
【請求項２】
前記２つのソケットに結びつけられたアプリケーションは、メディア再生アプリケーションと、前記メディア再生アプリケーションのサービス品質をスニファリング及び評価する監視アプリケーションとを有する、請求項１に記載の通信方法。
【請求項３】
メディアプレイヤのサービス品質モニタであり、前記サービス品質モニタのソケットは、前記メディアプレイヤに送信されるメディアパケットを取得するために、前記メディアプレイヤのソケットに結びつけられるサービス品質モニタであって、
取得されたメディアパケットがユニキャストのものであるか否かを検出する手段と、
前記取得されたユニキャストメディアパケットの宛先IPアドレスをローカルホストアドレスに置換し、前記パケットを転送する手段と
を有するサービス品質モニタ。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ネットワークのサービス品質（QoS：quality  of  service）を監視する方法及び装置に関する。
【背景技術】
【０００２】
TCP/IP通信ネットワークでは、異なるホストにおける２つの装置の間のセッションは、その間の通信のために確立される必要がある。通常では、これは、送信元IPアドレス及びポートと、宛先IPアドレス及びポートとから構成される。ホストが特定のセッションについて生成された場合（ホストは、アプリケーションがアプリケーション間通信を実施するためにTCP/IPプロトコルスタックにアクセスできる一種のアプリケーションプログラミングインタフェースである）、セッションのパケットは、それを通じて受信又は送信されることが可能になる。
【０００３】
アプリケーションレベルでのTCP/IPネットワークQoSモニタでは、モニタのスニファリングプリケーション（sniffing  application）のソケットを、監視されるアプリケーションのものと同じ宛先アドレス及びポートに結びつけることが一般的な概念である。
【発明の概要】
【発明が解決しようとする課題】
【０００４】
SO_REUSEADDRは、完全に重複した結びつき（binding）を可能にする一般的なソケットの選択肢の１つである。IPアドレス及びポートの対が１つのソケットに既に結びつけられている場合、トランスポートプロトコルがこの機能をサポートする場合には同じ対が他のソケットに結びつけられることが可能になる。通常では、この機能は、UDP（User  Datagram  Protocol）ソケットについてのみサポートされる。
【０００５】
この機能は、１つ以上のアプリケーションが同じホストで同時に複数回実行することを可能にするために、マルチキャストで使用される。ブロードキャストIPアドレス又はマルチキャストIPアドレス宛のUDPデータグラムが到達した場合、複数のアプリケーションの全ての結びつけられたソケットは、データグラムのコピーを受信することができる。しかし、ユニキャストアドレス宛のデータグラムは、１つのソケットのみに配信され得る。ユニキャストデータグラムに一致する複数のソケットが存在する場合、どのソケットがデータグラムを受信するかの結果は、実装依存である。すなわち、ユニキャストセッションにおける結びつけられたソケットの中で、１つのみの不定のソケットがユニキャストパケットを受信することができる。これは、ユニキャストの重複した結びつきの問題（UDBP：unicast  duplicate  binding  problem）と呼ばれる。
【課題を解決するための手段】
【０００６】
本発明の一態様によれば、TCP/IPプロトコルに準拠した２つのソケットに結びつけられたアプリケーション（socket-bound  application）の通信方法が提供される。２つのアプリケーションのソケットは、同じIPアドレス及びポートに結びつけられる。この方法は、いずれかのアプリケーションのレベルで、そのソケットで受信したユニキャストパケットを検出すると、ユニキャストパケットの宛先IPアドレスをローカルホストアドレス（127.0.0.1）に置換し、ユニキャストパケットを転送するステップを有する。
【０００７】
本発明の他の態様によれば、メディアプレイヤのサービス品質モニタが提供される。サービス品質モニタのソケットは、メディアプレイヤに送信されるメディアパケットを取得するために、メディアプレイヤのものに結びつけられる。モニタは、取得されたメディアパケットがユニキャストのものであるか否かを検出する手段と、取得されたユニキャストメディアパケットの宛先IPアドレスをローカルホストアドレス（127.0.0.1）に置換し、パケットを転送する手段とを有する。
【図面の簡単な説明】
【０００８】
【図１】従来技術によるQoSモニタとメディアプレイヤとのマルチキャストの重複した結びつきの内部動作機構を示す例示的な図
【図２】従来技術によるQoSモニタとメディアプレイヤとのユニキャストの重複した結びつきの内部動作機構を示す例示的な図
【図３】本発明の実施例によるQoS監視処理を示す例示的な図
【図４】QoSモニタについて重複した結びつきのソケットを生成する処理を示すフローチャート
【図５】オーディオ及びビデオパケットの別々の処理を示す例示的な図
【図６】本発明の実施例に従ってQoSモニタによりメディアプレイヤのビデオQoSを監視する処理を示すフローチャート
【発明を実施するための形態】
【０００９】
本発明の前記及び他の態様、特徴及び利点は、添付図面と共に以下の説明から明らかになる。
【００１０】
以下の説明では、本発明の実施例の様々な態様について説明する。説明の目的で、完全な理解を提供するために、特定の構成及び詳細が示されている。しかし、本発明は、ここに提示する特定の詳細なしに実施されてもよいことが、当業者に明らかである。
【００１１】
メディアアプリケーション又はサービスの経験品質（QoE：Quality  of  Experience）評価の精度を向上させるため、通信ネットワークのサービス品質（QoS：Quality  of  Service）が監視又は測定される必要がある。いくつかの既知のネットワークQoS測定方法が存在し、これらの全ては、関心のあるパケットをスニファリング（sniff）する必要がある。取得されたパケットは、PLR（Packet  Loss  Rate）、PLF（Packet  Burst  Loss  Frequency）等のようなリアルタイムのQoSメトリックを得るために追跡及び分析されてもよい。
【００１２】
メディアパケットは、TCP/IPプロトコルスタックの異なるレイヤで取得されてもよい。例えば、生のパケットがBPF（BSD（Berkeley  Software  Distribution）  Packet  Filter）によりデータリンクレイヤで取得されてもよい。しかし、アプリケーションが自分のニーズをより良く理解しているという概念に基づくALF（Application  Level  Framing）として知られるアーキテクチャ原理によれば、アプリケーションレベルでメディアパケットをスニファリングすることが好ましい。
【００１３】
QoS監視の目的のためにアプリケーションレベルでパケットを取得する場合、QoSモニタは、メディアプレイヤのものと同じIPアドレス及びポートに結びつけられる必要がある。この場合、結びつけられたQoSモニタは、メディアプレイヤの動作と干渉しないことが重要である。
【００１４】
しかし、前述のUDBPのため、メディアプレイヤは、QoSモニタがスニファリングしている場合、通常ではマルチキャストセッションを再生することができるが、ユニキャストセッションではできない。これは、それぞれ図１及び２に示されている。図１は、QoSモニタとメディアプレイヤとのマルチキャストの重複した結びつき（multicast  duplicate  binding）の内部動作機構を示す例示的な図である。図１に示すように、パケットが到達した場合、メディアプレイヤ及びQoSモニタは、別々にパケットのコピーを取得する。図２は、QoSモニタとメディアプレイヤとのユニキャストの重複した結びつき（unicast  duplicate  binding）の内部動作機構を示す例示的な図である。図２に示すように、結びつけられたデバイスの一方のみ（QoSモニタ（図２（ａ））又はメディアプレイヤ（図２（ｂ）））がユニキャストパケットを受信することができる。すなわち、QoSモニタにより取得されたユニキャストパケットは、メディアプレイヤにより受信されず、このことは、QoSモニタがメディアプレイヤの動作に影響を与えていることを意味する。
【００１５】
前述の問題を鑑みて、ユニキャストパケットを受信したときに、QoSモニタに対してパケットをメディアプレイヤのソケットに転送させる対策が提供される。図３は、本発明の実施例によるQoS監視処理を示す例示的な図である。図３に示すように、ユニキャストパケットがそのソケット（マスター）により受信されたことをQoSモニタが検出すると301、QoSモニタは、このユニキャストパケットをメディアプレイヤの結びつけられたソケット（スレーブ）に転送する302。転送されたパケットがメディアプレイヤのソケットにより受信され得ることを保証するために、QoSモニタは、ポートを変更せずに、パケットの宛先IPアドレスをローカルホストアドレス（127.0.0.1）に置換する必要がある。その宛先IPアドレスが使用された場合、転送されたパケットはメディアプレイヤのソケットではなく、QoSモニタ自体により再び受信される。
【００１６】
次に、本発明の実施例に従ってアプリケーションレベルでメディアプレイヤをスニファリングするQoSモニタの処理について詳細に説明する。
【００１７】
メディアプレイヤのメディアパケットを監視するために、QoSモニタは、そのソケットをメディアプレイヤと同じ宛先IPアドレス及びポートに結びつける必要がある。図４は、QoSモニタについて重複した結びつきのソケットを生成する処理を示すフローチャートである。
【００１８】
図４に示すように、ステップS401において、QoSモニタは、socket(AF_INET,SOCK_DGRAM,IPPROTO_UDP)を呼び出すことにより、データグラムソケットを生成する。これは、参照する他のソケット機能のソケットIDを戻す。
【００１９】
次に、それぞれ引数SO_RCVBUF及びSO_REUSEADDRを用いたsetsocketopt()の呼び出しにより、ステップS403において、QoSモニタは、受信バッファサイズを設定し、ステップS405において、セッションIP及びポートの再利用を可能にする。
【００２０】
次にステップS407において、QoSモニタは、bind()の呼び出しにより、そのソケットをメディアプレイヤと同じ宛先IPアドレス及びポートに結びつける。
【００２１】
現在のマルチメディア通信では、通常では、オーディオ及びビデオパケットは、異なるポートを用いて異なるセッションで送信される。従って、QoSモニタは、その異なるマスターソケットによりそれぞれオーディオ及びビデオパケットを受信し、（必要に応じて）オーディオ及びビデオパケットをメディアプレイヤのそれぞれのスレーブソケットに転送する。この処理が図５に示されている。
【００２２】
図６は、本発明の実施例に従ってQoSモニタによりメディアプレイヤのビデオQoSを監視する処理を示すフローチャートである。
【００２３】
図６に示すように、まずステップS601において、QoSモニタは、リアルタイムトランスポートプロトコル（RTP：Real-time  Transport  Protocol）ヘッダログファイル及び全QoSメトリックログファイルを生成する。
【００２４】
ステップS603において、QoSモニタは、select()の呼び出しを使用してこのソケットを監視することにより、ユニキャストパケットが到達したか否かを判定する。結果が“Yes”である場合、ステップS605において、QoSモニタは、このパケットが到達したソケットの種類を介してビデオパケットが受信されたか否かを判定する。結果が“No”である場合（これはマルチキャスト又はブロードキャストパケットが受信されたことを意味する）、本発明の実施例の方法の代わりに通常の処理が適用されることが、当業者により分かる。
【００２５】
ステップS605の結果が“Yes”である場合、ステップS607において、モニタは、ユニキャストビデオパケットの宛先IPアドレスをローカルホストアドレス（127.0.0.1）に置換し、パケットをメディアプレイヤのビデオソケットに転送する。ステップS605の結果が“No”である場合（これはオーディオパケットが受信されたことを意味する）、ステップS609において、QoSモニタは、ユニキャストオーディオパケットの宛先IPアドレスをローカルホストアドレス（127.0.0.1）に置換し、パケットをメディアプレイヤのオーディオソケットに転送する。
【００２６】
実施例のQoSモニタは、メディアプレイヤのビデオQoSを評価するために使用されるため、取得されたビデオパケットについてQoSモニタは、パケットを分析し、QoSメトリックの統計データを更新する。具体的には、ステップS611において、モニタは、RTPヘッダ及び到達タイムスタンプをログファイルに記録し、ステップS613において、RTPヘッダのシーケンス番号を使用して、パケットの損失を判定し、統計データを例えばstatDataに蓄積する。statDataは、PLR、PLL、PLF及びPDRを含む統計データを蓄積するデータ構造である。
【００２７】
この実施例では、QoSモニタは、受信したユニキャストオーディオパケットをオーディオスレーブソケットに直接転送する。しかし、オーディオパケットも必要に応じて分析されてもよいことが当業者に分かる。
【００２８】
図６に示すように、ステップS601、S605、S607及びS607のいずれか１つにエラーが存在する場合、ステップS615において、RTPヘッダログファイルは閉じられる。
【００２９】
本発明の原理について、メディアプレイヤのQoSモニタを参照して説明した。しかし、本発明は、前述のようなユニキャストの重複した結びつきの問題を克服する目的で、全ての２つの結びつけられたアプリケーションに適用可能であることが、当業者により分かる。
【００３０】
複数の変更が例示の実施例に行われてもよく、特許請求の範囲に記載の本発明の要旨及び範囲を逸脱することなく、他の構成が考えられ得ることが分かる。
【図１】
0005628408.tif 000002
【図２】
0005628408.tif 000003
【図３】
0005628408.tif 000004
【図４】
0005628408.tif 000005
【図５】
0005628408.tif 000006
【図６】
0005628408.tif 000007