(57)【要約】  ネットワーク装置は、第１のネットワークセグメント（18）を第２のネットワークセグメント（17）に結合するように構成され、第１及び第２のネットワークセグメントの間でデータパケットを転送する転送手段（23）を有する。この装置は、第２のネットワークセグメントでのサービス要件に適合させるために、受信データパケットのサービス要件を決定する決定手段（24）を有する。第１のネットワークセグメントでの受信データパケットのソースが検出される。優先度の基準及びコンテンツタイプの基準に基づいて、サービスタイプは、ソースに応じたデータパケットにタグ付けされる。転送ユニットは、第２のネットワークセグメントでのサービスタイプに適合させるように構成される。有利には、サービス品質を認識しないデータパケットを、サービス品質要件に従って動作するネットワークセグメントに転送するブリッジが形成される。
2010504018.tif 000002
【特許請求の範囲】
【請求項１】
−第１のネットワークセグメントに結合する第１のインタフェースユニットと；
−第２のネットワークセグメントに結合する第２のインタフェースユニットと；
−前記第１及び第２のネットワークセグメントの間でデータパケットを転送する転送手段と；
−前記第２のネットワークセグメントでのサービス要件に適合させるために、前記第１のネットワークから前記第２のネットワークセグメントに転送される受信データパケットのサービス要件を決定する決定手段と；
を有し、
前記決定手段は、前記第１のネットワークセグメントでの前記受信データパケットのソースを検出し、前記ソースに応じてサービスタイプを前記受信データパケットに割り当てることにより、前記サービス要件を決定ように構成され、
−前記転送手段は、前記受信データパケットについて前記第２のネットワークセグメントでの前記サービスタイプに適合させるように構成されるネットワーク装置。
【請求項２】
前記決定手段は、
−ネットワークアドレスインジケータと；
−ネットワークポートインジケータと；
−媒体アクセスインジケータ又は媒体アクセスプロトコルアドレスと；
−前記第１のネットワークセグメントがインターネットに結合されている場合には；
−インターネットプロトコルアドレスと；
−ユニフォームリソースロケータと；
のうち少なくとも１つに基づいて前記受信データパケットの前記ソースを検出するように構成される、請求項１に記載のネットワーク装置。
【請求項３】
前記決定手段は、所定の基準を適用することにより前記サービスタイプを割り当てるように構成され、
前記基準は、
−ソースへのコンテンツタイプのマッピングと；
−ソースの優先度の基準と；
のうち少なくとも１つを含む、請求項１に記載のネットワーク装置。
【請求項４】
前記決定手段は、特に前記制御インタフェースがユーザインタフェース又はアプリケーションプログラミングインタフェースである場合に、前記所定の基準を設定する制御インタフェースを有する、請求項３に記載のネットワーク装置。
【請求項５】
前記決定手段は、特に制御部分がHTTP（hypertext  transfer  protocol）プロトコルに従ったMMIE（Multipurpose  Internet  Mail  Extension）タイプ、RTP（real  time  protocol）に従ったAV（audio  video）プロファイル、又は前記データパケットの前記コンテンツを符号化するために使用されるエンコーダを示すコードを有する場合に、所定のプロトコルに従って前記受信データパケットの制御部分を分析することに基づいて、前記サービスタイプを割り当てるように構成される、請求項１に記載のネットワーク装置。
【請求項６】
前記転送手段は、所定のプロトコルに従って前記受信データの制御部分を適応させることにより、前記サービスタイプに適合させるように構成される、請求項１に記載のネットワーク装置。
【請求項７】
前記適応は、サービスタイプのフィールドを設定することによりヘッダを適応させることを有する、請求項６に記載のネットワーク装置。
【請求項８】
前記第２のネットワークインタフェースは、無線の第２のネットワークセグメントにインタフェース接続する異なるサービスタイプのパケットについて異なるバッファキューを有し、
前記転送手段は、前記サービスタイプに基づいて前記バッファキューの選択されたものを介して前記受信パケットを転送することにより、前記サービスタイプに適合させるように構成される、請求項１に記載のネットワーク装置。
【請求項９】
前記転送手段は、前記第１のネットワークセグメントから受信したデータパケットを格納し、前記第２のネットワークセグメントに送信されるデータパケットを取得する大容量記憶装置を有し、
前記決定手段は、前記格納前又は前記取得後に前記サービスタイプを割り当てるように構成される、請求項１に記載のネットワーク装置。
【請求項１０】
第１のネットワークセグメントと第２のネットワークセグメントとの間でデータパケットを転送する間にサービス要件を決定する方法であって：
前記第２のネットワークセグメントでのサービス要件に適合させるために、前記第１のネットワークから前記第２のネットワークセグメントに転送される受信データパケットのサービス要件を決定するステップを有し；
前記決定することは：
−前記第１のネットワークセグメントでの前記受信データパケットのソースを検出し；
−前記ソースに応じてサービスタイプを前記受信データパケットに割り当てることを有し；
前記転送することは：
−前記受信データパケットについて前記第２のネットワークセグメントでの前記サービスタイプに適合させることを有する方法。
【請求項１１】
第１のネットワークセグメントと第２のネットワークセグメントとの間でデータパケットを転送する間にサービス要件を決定するコンピュータプログラムであって、
請求項１０に記載の方法をプロセッサに実行させるように動作可能なコンピュータプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、第１のネットワークセグメントに結合する第１のインタフェースユニットと、第２のネットワークセグメントに結合する第２のインタフェースユニットと、第１及び第２のネットワークセグメントの間でデータパケットを転送する転送手段と、第２のネットワークセグメントでのサービス要件に適合させるために、第１のネットワークから第２のネットワークセグメントに転送される受信データパケットのサービス要件を決定する決定手段とを有するネットワーク装置に関する。
【０００２】
本発明は、第１のネットワークセグメントと第２のネットワークセグメントとの間でデータパケットを転送する間にサービス要件を決定する方法に更に関し、この方法は、第２のネットワークセグメントでのサービス要件に適合させるために、第１のネットワークから第２のネットワークセグメントに転送される受信データパケットのサービス要件を決定するステップを有する。
【０００３】
本発明は、セグメント化されたネットワークにおけるネットワーク通信の分野に関する。ネットワークは、無線部分と有線部分とを含んでもよい。ネットワーク装置（例えば、スイッチ、ルータ、ゲートウェイ、又は無線ネットワークセグメントのアクセスポイント）は、セグメント間のブリッジを構成する。アクセスポイントは、無線装置と通信し、有線セグメントと無線セグメントとの間でメッセージを転送する。
【背景技術】
【０００４】
文献US2006/0013129は、ネットワークでのリソース利用について記載している。重複スケジューラ（overlapping  scheduler）と呼ばれるネットワーク装置は、様々なアプリケーションからデータパケットを受信する。データパケットは、ネットワークに送信される。或るアプリケーションは、ネットワークを介して送信するためにサービス品質（QoS：Quality  of  Service）パラメータを提供するが、或るもの（特に旧式のもの）は、このようなパラメータを提供することができない。QoSパラメータが利用可能でないサービスについては、スケジューラは、例えば帯域測定に基づいてQoSパラメータを決定してもよい。更なるQoSパラメータは、到来パケットのコンテンツを分析することから決定されてもよい。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】US2006/0013129
【発明の概要】
【発明が解決しようとする課題】
【０００６】
文献US2006/0013129は、アプリケーションからデータパケットを受信し、データパケットをネットワークセグメントに送信する方法の一例を提供する。或るデータパケットは既知のQoSパラメータを有するが、或るものはこのようなパラメータを有さない。QoSパラメータが提供されない場合、この方法は、データパケットのコンテンツに基づいてQoSパラメータを決定する。出力では、QoSパラメータに従ってデータパケットを送信することにより、ネットワーク性能が改善される。しかし、既知の方法の問題は、多数のパケットが更なるネットワークセグメント（例えば、インターネット）から到達したときに生じる。通常ではQoSパラメータが存在しないネットワークセグメントからサービスパラメータが性能を改善するために制御及び使用され得るセグメントにパケットを転送する必要性が存在する。しかし、パケットのコンテンツから直接にQoSパラメータを検出すること、又はこの目的で帯域測定を実行することは、実行不可能である。
【０００７】
ネットワークの第１及び第２のセグメントの間のギャップを埋めるネットワークの対策を提供することが本発明の目的であり、第１のセグメントのサービスパラメータは制御されないが、第２のセグメントでデータパケットがサービスパラメータに基づいて適合され得る。
【課題を解決するための手段】
【０００８】
この目的のため、本発明の第１の態様によれば、冒頭の段落に記載のネットワーク装置において、決定手段は、第１のネットワークセグメントでの受信データパケットのソースを検出し、ソースに応じてサービスタイプを受信データパケットに割り当てることによりサービス要件を決定するように構成され、転送手段は、受信データパケットについて第２でのネットワークセグメントでのサービスタイプに適合させるように構成される。
【０００９】
この目的のため、本発明の第２の態様によれば、冒頭の段落に記載の方法において、決定するステップは、第１のネットワークセグメントでの受信データパケットのソースを検出し、ソースに応じてサービスタイプを受信データパケットに割り当てることを有し、転送することは、受信データパケットについて第２のネットワークセグメントでのサービスタイプに適合させることを有する。
【００１０】
この手段は、サービスタイプ又はサービス品質の要件を認識しない第１のネットワークセグメントから到達したデータパケットが、自動的にサービスタイプを割り当てられる（すなわち、各優先度が、各データパケットに適切に選択された第２のネットワークセグメントで適用される）という効果を有する。割り当ては、第１のネットワークセグメントでデータパケットのソースを検出することに基づく。有利には、装置は、２つのネットワークセグメントの間のブリッジを構成し、第１のセグメントは、サービスタイプを認識せず、第２のセグメントは、改善した性能のため及びネットワークリソースの効率的な使用のため、サービスタイプに従って動作する。
【００１１】
本発明はまた、以下の認識に基づく。１つのネットワーキングプロトコルから他のプロトコルにサービス品質（QoS）基準を変換する他のシステムが存在することが知られている。例えば、US6,859,438は、真のサービス品質を実現するために、ネットワーク内でトラヒックを監視して優先付け、帯域を割り当てるポリシー型機構を記載している。この装置は、QoSポリシー情報（例えば、一式のトラヒックグループ及び関連するQoS設定を示す情報、IEEE802.1pの優先度インジケータ若しくはIEEE802.1qのフレームタグ、又はネットワークのトポロジに基づくQoSについての情報）を受信する。入力パラメータとして受信したQoS情報に基づいて、データパケットは、パケットが関連する特定のトラヒックグループのQoSポリシーに従って出力されるためにスケジューリングされる。発明者は、このような装置が更なるネットワークセグメントで使用される１つのプロトコルに従って受信した入力QoS情報を変換するが、既知の装置は、QoS情報が利用可能でないときに対策を提供しないことを見出した。本発明は、QoSを認識しないトラヒックをQoSを認識するネットワークセグメントに結合する真のブリッジを提供する。QoS情報が利用可能でないときに、データパケットのソースが検出され、例えば検出されたソースをコンテンツタイプにマッピングすることにより、第２のネットワークセグメントで使用されるサービスタイプを設定するために使用される。
【００１２】
ネットワーク装置の実施例では、決定手段は、ネットワークアドレスインジケータと、ネットワークポートインジケータと、媒体アクセスインジケータと、第１のネットワークセグメントがインターネットの一部である場合にはインターネットプロトコル（IP：Internet  Protocol）アドレスと、ユニフォームリソースロケータ（URL：Uniform  Resource  Locator）とのうち少なくとも１つに基づいて受信データパケットのソースを検出するように構成される。これは、装置を介したリンクの設定中に、及び／又はデータパケットに関連する制御データ（パケットヘッダ等）から、ソースが容易に検出され得るという利点を有する。
【００１３】
ネットワーク装置の実施例において、決定手段は、所定の基準を適用することによりサービスタイプを割り当てるように構成され、基準は、ソースへのコンテンツタイプのマッピングと、ソースの優先度の基準とのうち少なくとも１つを含む。これは、データ通信分野の専門家である必要のないユーザにより、又は外部ソースによるこのような基準の設定により、このような基準が容易に提供され得るという利点を有する。
【００１４】
ネットワーク装置の実施例において、転送手段は、所定のプロトコルに従って受信データの制御部分を適応させることにより、サービスタイプに適合させるように構成される。制御部分は、第２のネットワークセグメントのプロトコル要件に従って設定される。これは、第２のネットワークセグメントで標準的なQoS機構が適合可能であるという利点を有する。特に、この適応は、サービスタイプのフィールドを設定することによりヘッダを適応させることを有してもよい。有利には、データパケットは、次に、適応されたヘッダに従って第２のネットワークセグメントを介して送信される。本発明による装置及び方法の更に好ましい実施例は、特許請求の範囲に与えられ、特許請求の範囲の開示が参照として組み込まれる。
【図面の簡単な説明】
【００１５】
【図１】ネットワークにおけるネットワーク装置
【図２】サービスタイプを決定するネットワークセグメント間のネットワーク装置
【図３】サービスタイプを割り当てるネットワーク装置
【図４】適応前後のパケット
【図５】入来パケット及びWiFiの適応
【図６】Ethernetフレームの適応
【図７】IPパケット構造
【図８】優先度のマッピング
【発明を実施するための形態】
【００１６】
本発明の前記及び他の態様は、以下の説明に一例として記載されている実施例及び添付図面を参照して更に明らかになる。
【００１７】
図面において、既に記載された要素に対応する要素は、同じ参照符号を有する。
【００１８】
図１は、ネットワークにおけるネットワーク装置を示している。ネットワークは、少なくとも１つのソース30に結合された第１のネットワークセグメント18（例えば、インターネットのような広域ネットワーク（WAN：wide  area  network））と、少なくとも１つの宛先に結合された第２のネットワークセグメント17（例えば、ローカルエリアネットワーク（LAN：local  area  network））とを有し、ネットワーク装置20は、双方のネットワークセグメントに結合される。データパケットは、ネットワークを介してソースと宛先との間で交換されてもよい。ソース（例えば、インターネットへのウェブサイトを提供するサーバ）は、ネットワークインタフェース31と、ネットワークを介してデータを交換することにより宛先に通信可能な１つ以上のアプリケーション又はサービス32とを有する。宛先10（例えば、インターネットにアクセスするホームコンピュータ）は、少なくとも１つのアプリケーション12と、制御ユニット13と、無線ネットワークセグメントにアクセスするアンテナ14に結合されたインタフェースユニット11とを有する。
【００１９】
優先度に基づくサービス品質（QoS：Quality  of  Service）のデータ通信は、アクセスポイント、ゲートウェイ、ブリッジ及びネットワークカードを通じてホームネットワークで展開され始めている。効果的に動作するために、QoSは、ストリームのサーバ／ソースとネットワーキングインタフェース（無線アクセスポイント、ゲートウェイ）が‘QoSを認識する（QoS-aware）’ことを必要とする。しかし、多くの場合に、このようにならず、消費者は、QoSを認識しない装置を‘アップグレード’することができない。例えば、この理由は、ソース装置が実際にインターネット上のサーバであるからである。QoSを認識しない配信チェーンの部分からQoSを認識するネットワークセグメントへのブリッジを構成する対策がネットワーク装置により提供される。
【００２０】
ネットワーク装置20は、第１のネットワークセグメント18に結合する第１のインタフェースユニット22と、第２のネットワークセグメントに結合する第２のインタフェースユニット21と、第１及び第２のネットワークセグメントの間でデータパケットを転送する転送ユニット23と、第１のネットワークから第２のネットワークセグメントに転送される受信データパケットのサービス要件を決定する決定ユニット24とを有する。決定ユニット24は、制御インタフェース25（例えば、ユーザインタフェース）に結合されてもよい。第２のインタフェースユニット21は、図示のように無線ネットワークセグメント17にアクセスするアンテナ26を有してもよい。代替として、第２のインタフェースユニット21は、更に有線インタフェースでもよい（例えば、ローカルエリアネットワーク（LAN）に結合されてもよい）。決定ユニット24は、第１及び第２のインタフェースユニットに結合され、第２のネットワークセグメントでサービス要件に適合させるために転送ユニット23に結合される。更に、決定ユニットは、第１のネットワークセグメントの受信データパケットのソースを検出し、ソースに応じてサービスタイプを受信データパケットに割り当てることによりサービス要件を決定するように構成される。更に、転送ユニットは、受信データパケットについて決定されたサービスタイプを第２のネットワークセグメントで適合させるように構成される。
【００２１】
データパケットのストリーム（例えば、ビデオ又はオーディオストリーム）は、ソースから宛先（シンクとも呼ばれる）に転送される。複数のストリームが様々なソースと１つの宛先との間で同時にネットワークで適合されてもよく、その逆も同様である点に留意すべきである。ストリームは、２つのネットワークセグメント間でブリッジを構成するネットワーク装置20を介して通過する。例えば、ネットワーク装置は、無線アクセスポイント（WAP：wireless  access  point）、無線ブリッジ、ゲートウェイ、ルータ若しくはスイッチ、又はメディアサーバでもよい。
【００２２】
決定ユニットは、第１のネットワークセグメントから到達するときに、このサービスタイプを有さないネットワークパケットのサービスタイプ要件を決定するように構成される。次に、これらのパケットが処理され、サービスタイプが存在するかのように、第２のネットワークセグメントに転送される。これは、パケットがしばしば異なるネットワークセグメントを（例えば、WANからLANへ）移動するときに、ストリームのソースとシンクとの間でのエンド・ツー・エンドの通信を改善する。
【００２３】
装置は、入来パケットを自動的に検査し、パケットのソースを決定することにより、パケットがネットワークで使用される優先度のカテゴリに入るか否かを決定する。分類の精度を改善するために、１つ以上の特定のソースから入来する全てのトラヒックについてコンテンツタイプを規定する更なる‘コンテンツタイプ規則（content  type  rule）’が規定されてもよい。特定されないソースについて、装置は、自動分析に戻ってもよい。第２のネットワークセグメントでサービスタイプに適合させるために、以下に詳細に説明するように、装置はレイヤ2及び／又はレイヤ3の優先度タグを割り当ててもよい。
【００２４】
図２は、サービスタイプを決定するネットワークセグメント間のネットワーク装置を示している。ネットワーク装置20は、第１のネットワークセグメント（例えば、インターネット）からサービスタイプ又はQoS優先度のないデータパケットを受信する第１のインタフェースを有する。装置は、データパケットを第２のネットワークセグメント17に転送する（例えば、WMM  QoS優先度に従って、ホームWiFi無線ネットワークセグメントに転送する）。WMM（WiFi  MultiMedia）の標準は、４つのカテゴリ（優先度の増加と共に、BG（background）、BE（best  effort）、VI（video）、VO（voice））で無線パケットの優先度を規定する（http://en.wikipedia.org/wiki/WMM参照）。矢印201は、サービスタイプ又はQoS要件を認識しないネットワークの第１の部分を示す。矢印202は、サービスタイプ又はQoS要件を認識するネットワークの第２の部分を示す。ネットワーク装置20は、２つの部分のブリッジを構成する。
【００２５】
代替として又は更に、ネットワーク装置は、更なるネットワークセグメント19（例えば、有線ホームEthernet）にインタフェース接続されてもよい。更なるネットワークセグメント19は、IEEE802.1qに従ったQoS優先度で装置によりタグ付けされたパケットを受信する。
【００２６】
図２の上部は、図１に示す決定ユニット24の機能を表すサービスタイプを決定する機構を示している。最も左のユニット203は、特定のソースについての直接の優先度の基準を示している（例えばユーザの嗜好に基づいて、例えば優先度VO（符号0x48）をphilips.comのURLに割り当てる）。次のユニット204は、サービスタイプへの（インターネットURLに基づく）ソースのマッピング（いわゆるコンテンツタイプ規則）を示している。マッピングは、予め設定されてもよく、ユーザにより入力又は編集されてもよく、サービスとしてインターネットを介して（例えば（自動ダウンロード）を介して）提供されてもよい。次のユニット（図８を参照して更に説明するテーブル80）は、優先度へのコンテンツタイプのマッピングを提供する。最も右のユニット205は、パケット分析のコンテンツ基準を提供する。特に、数個のプロトコルが記載されており、サービスタイプを決定するために検出される各制御フィールドが示されている。適切なプロトコルを決定した後に、フィールドのそれぞれの分析は、データパケットにサービスタイプを割り当てるための入力としてコンテンツタイプを提供する。
【００２７】
実施例では、特定のソースのデータパケットの分類は、パケットを分析することによりサポートされる。更に、決定ユニットは、所定のプロトコルに従って受信データパケットの制御部分を分析することに基づいて、サービスタイプを割り当てるように構成される。例えば、異なるプロトコルレイヤを目的とするが、パケットのヘッダは、サービスタイプを表してもよい。例えば、データパケットの制御部分は、HTTP（hypertext  transfer  protocol）プロトコルに従ったMIME（Multipurpose  Internet  Mail  Extension）タイプ、RTP（real  time  protocol）に従ったAV（audio  video）プロファイル、又はデータパケットのコンテンツを符号化するために使用されるエンコーダを示すコードを有してもよい。プロファイル又はメディアフォーマットがパケットで示されてもよい（例えば、AVI  FourCCコード）。FOURCC（文字通り４文字コード）は、データフォーマットを一意に特定するために使用される４バイトの系列である。元々はAmiga  IFFファイルフォーマットで使用されており、この概念は、AppleのAIFFフォーマット及びMicrosoftのRIFFフォーマットで、後にQuickTime及びDirectShowでデータタイプを特定するために再利用されている。FourCCの最も周知の用法の１つは、AVIファイルで使用されるビデオコーデックを特定することである。一般的な識別子は、DIVX、XVID及びH264を含む。オーディオコーデックでは、AVI及びWAVファイルは、通常では１６進法で記述される２バイトの識別子（MP3では0055等）を使用する。
【００２８】
分析のための基準を追加するために使用され得るプロトコル（更なる情報の参照）の更なる例は、以下の通りである。
−RTSP（Real-Time  Streaming  Protocol）：インターネットでオーディオ又はビデオをストリーミングするために使用されるプロトコル（RFC2326参照）
−SIP（Session  Initiation  Protocol）：インターネットでの音声又はビデオ電話に使用されるプロトコル（http://www.cs.columbia.edu/sip/drafts.html参照）
−H323：インターネットでのテレビ会議を規定する標準（http://www.packetizer.com/voip/h323/参照）
−SDP（Session  Description  Protocol）：インターネットストリームの設定パラメータを記述するフォーマット、ほとんどはRTSPセッション又はSIPセッションの一部として使用される（RFC2327参照）
−MPV（MPEG  Video）：ビデオストリームがMPEGビデオフォーマットを使用することを示すためにSDPで使用される略記
RFC（Request  For  Comments）の参考文献は、www.ietf.orgで入手可能である点に留意すべきである。
【００２９】
ネットワーク装置の実施例では、決定手段は、前述の基準を設定する（例えば、ソースとコンテンツタイプとのマッピングを入力、適応又は除去する）制御インタフェースを有する。例えば、制御インタフェースは、ユーザインタフェース又はアプリケーションプログラミングインタフェース（API：application  programming  interface）でもよい。特性、選択肢及び基準を決定するこのようなインタフェースは、それ自体で周知である。制御インタフェースは、消費者又は他のコンピュータプログラムが（一式の）特定のソースから生じた全てのトラヒックについて（例えば、IPアドレス、ポート、URL、又は媒体アクセスプロトコル（MAC：Media  Access  Protocol）アドレスに基づいて）コンテンツタイプを規定する‘コンテンツタイプ規則’を規定することを可能にすることにより、分類の精度を改善する。また、消費者又は他のコンピュータプログラムは、‘優先度規則’を使用して特定のソースから生じた全てのトラヒックについて優先度を明示的に規定することにより、自動のコンテンツ分類を‘上書き’することを許容されてもよい。
【００３０】
制御インタフェースを介して、規則の構成は、完全に手動（全ての情報のユーザによるタイプ入力）でもよく、‘ブックマーク／お気に入りのインポート’の機構に基づいてもよい。‘周知’のURL（人気のビデオ店等）では、装置は、コンテンツカテゴリを自動的に示唆してもよい。例えば、download.comは、常にバックグラウンド（優先度0）であり、Itunes.comは常にオーディオ／AV（優先度2）である。
【００３１】
図３は、サービスタイプを割り当てるネットワーク装置を示している。ネットワーク装置20は、以下の要素を有する。第１のインタフェース300では、データパケットは、QoSを認識しないネットワークセグメントと交換される。入来パケットは、WLANから受信される。パケットは、ソース決定ユニット301で分析され、ソース決定ユニット301は、ソースを特定する。決定ユニットは、直接の優先度の規則に対してソースを照合する直接優先度規則ユニット304（例えば、データベース）に結合される。照合が見つかった場合、新しい優先度が転送ユニット303に渡される。照合が見つからなかった場合、データパケットは、コンテンツ規則ユニット309で更に検査される。コンテンツ規則ユニット309はコンテンツ規則データベースユニット310に結合される。照合が見つかった場合、コンテンツタイプは、優先度ユニット302に渡される。優先度ユニット302は、コンテンツタイプと優先度とのマッピングを有する記憶ユニット305に基づいて、優先度を導く。例えば、レイヤ２（L2）及び／又はレイヤ３（L3）プロトコルで特定の値に設定されてもよい導かれた優先度は、転送ユニット303に結合される。転送ユニット303は、更なるネットワークインタフェース（例えば、更なるネットワークLANインタフェース307、308の範囲の１つ）を介して更なるネットワークセグメントにデータパケットを転送するために、優先度を適用する。装置は、分析ユニット306を有してもよい。特に直接の優先度がユニット301で割り当て不可能であり、コンテンツタイプがソースに基づいて決定できない場合（すなわち、ユニット309によるコンテンツタイプで照合が見つからなかった場合）、分析ユニット306は、更なる検査のために入来パケットを受信する。分析ユニット306は、パケットヘッダとパケットのコンテンツとを検査し、コンテンツタイプを決定する。コンテンツタイプが検出可能である場合、コンテンツタイプは、優先度ユニット302に渡される。コンテンツタイプが決定不可能である場合、このユニットは、パケットを“ベストエフォート”として分類する。これは、転送ユニット303に渡される。実際には、前述のユニットは、専用ハードウェア回路として、及び／又は共有ハードウェア（例えばプロセッサ及びメモリ）と適切なソフトウェアとを使用して実装されてもよい。更に、より基本的な実装は、別々の照合ユニット301、302、309及びデータベース304、305、310の代わりに、唯一の照合ユニット及びデータベースを必要としてもよく、例えば、サービスタイプ及び対応する優先度に対するソースの直接のマッピングを適用してもよい。様々な規則データベースは、ユーザにより構成可能でもよく、専門知識を必要としてもよい。
【００３２】
ネットワーク装置の実施例では、ソース決定ユニット301は、以下のように受信データパケットのソースを検出するように構成される。入来データパケットは、ソースを決定するために分析される。分析は、（第１のネットワークインタフェースに結合された）ソースと（第２のネットワークインタフェースに結合された）宛先との間に特定のリンクが確立されたとき、及び／又は個々のパケットが到達したときに生じてもよい。特に、ソースは、ネットワークアドレスインジケータ、ネットワークポートインジケータ、通常ではMACアドレスと呼ばれるメディアアクセスインジケータのうち少なくとも１つに基づいて検出されてもよい。更に、データパケットがインターネットから受信されると、以下の要素：インターネットプロトコル（IP）アドレス、URL（Uniform  Resource  Locator）のうち１つが使用されてもよい。
【００３３】
ネットワーク装置の実施例では、決定ユニット301は、所定の基準を適用することによりサービスタイプを割り当てるように構成されてもよく、基準は、ソースへのコンテンツタイプのマッピングを含む。マッピングは、（例えばURLに基づく）特定のソースを特定のコンテンツ形式（例えば、ビデオ、音声、オーディオ）にマッピングするテーブルを含んでもよい。代替として、マッピングは、選択された優先度へのソースの直接のマッピングを含んでもよい。
【００３４】
実施例では、転送ユニット303は、所定のプロトコルに従って受信データパケットの制御部分を適応させることにより得られた優先度に従って、サービスタイプに適合させるように構成される。例えば、パケットのヘッダ又は他の制御フィールドは、通常ではL3プロトコルで適応される。特に、この適応は、サービスタイプのフィールドを設定することによりヘッダを適応させることを有してもよい。更に、L3タグが挿入されてもよく、特定の値を与えられてもよい。IPプロトコルでは、適切なフィールドが、サービスタイプを示すDSCP（Differentiated  Services  Code  Point）フィールドに設定される。（64の可能な値を有する）DSCPは、パケット優先度を示すパケット分類目的のためのIPパケットのヘッダにおけるフィールドである（WMMに類似する）。ヘッダがIPレベルで使用されると、有線又は無線ネットワークセグメントで使用可能になる。
【００３５】
装置の実施例では、ネットワークインタフェース307、308は、無線の第２のネットワークセグメントにインタフェース接続するため、異なるサービスタイプのパケットについて異なるバッファキューを有する。異なるバッファキューは、好ましい順序で無線ネットワークセグメントを介してパケットを転送するために、L2の優先度に基づいて選択される。転送ユニット303は、サービスタイプに基づいてバッファキューの選択されたものを介して受信パケットを転送することにより、導かれた優先度に従ってサービスタイプに適合させるように構成される。
【００３６】
ネットワーク装置の実施例では、転送手段は、例えばメディアサーバを構成するために、第１のネットワークセグメントから受信したデータパケットを受信し、第２のネットワークセグメントに送信されるデータパケットを取得する大容量記憶ユニットに結合される。QoSを認識しないデータパケットの入来ストリームが格納されてもよく、QoSを認識するデータパケットの出力ストリームが取得されてユーザに送信されてもよい。実施例では、決定手段は、この格納の前又はこの取得の後に、サービスタイプを割り当てるように構成される。格納前にサービスタイプを決定することは、検出されたサービスタイプが格納され、また、データパケットの各ストリームを取得する間に使用されることを必要とする。各データパケットは、格納又は検出されたサービスタイプに従って取得された後に適応されてもよい。
【００３７】
図４は、適応前及び後のパケットを示している。図面の左部分には、元の入来パケット41の要素が示されており、特に、HTTPヘッダ、TCPヘッダ、IPヘッダ、Ethernetヘッダ、及びコンテンツ（音声データ）が示されている。図面の右部分には、Ethernetで出力される出力適応パケット42の要素が示されており、特に、HTTPヘッダ、TCPヘッダ、IPヘッダ、Ethernetヘッダ、及びコンテンツ（オーディオMP3ファイルデータ）が示されている。ポインタ43により模式的に示されているように、フィールド（この例では、追加の優先度の値0x38を有するDSCPフィールド）が追加され、音声の優先度を示している。更に、第２のポインタ44により模式的に示されているように、フィールド（例えば、101（=ビデオを示す5）に設定された優先度のフィールドを有する802.1q  VLANタグ）がEthernetフレームに追加される。
【００３８】
図５は、WiFiの入来パケット及び適応を示している。図４と同様に、図面の左部分には、元の入来パケット41の要素が示されている。図５の右部分には、WiFiで出力される出力パケット51の要素が示されており、特に、HTTPヘッダ、TCPヘッダ、IPヘッダ、WiFiヘッダ、及びコンテンツ（MPEG2ファイルデータ）が示されている。ポインタ52により模式的に示されているように、L3フィールド（この例では、追加の優先度の値0x28を有するDSCPフィールド）が追加され、ビデオの優先度を示してもよい。L3において、ヘッダの前述と同じ適応が用いられてもよい点に留意すべきである。すなわち、ネットワークのタイプに依存しない。更に、第２のポインタ53により模式的に示されているように、L2では、WMMに従ってパケットはビデオパケット用のVIキューに入れられ、無線ネットワークセグメントでの送信を待機する。無線ネットワークセグメントでL2の優先度に適合させることは、ヘッダフィールドに値を設定することではなく、無線送信機又はアクセスポイントの異なる送信バッファに対応するいわゆる‘アクセスカテゴリ’を割り当てることである点に留意すべきである。従って、各カテゴリ（BK（バックグラウンド）、BE（ベストエフォート）、VI（ビデオ）、VO（音声））に数値を付与する必要はない。
【００３９】
図６は、Ethernetフレームの適応を示している。図面は、IEEE802.1Qに従って32ビットのVLANタグ64を有するEthernetフレーム61を示している。タグが詳細に示されており62、3ビットの優先度のフィールド（PRIO）を有する。IEEE802.pによれば、優先度のフィールドは、IEE802.1d  Annex  Gに基づくテーブル65に示されたサービスタイプに対応した値として割り当てられる。
【００４０】
図７は、IPパケット構造を示している。図面は、レイヤ3におけるIPデータパケットの構造71の一部を示している。この構造は、32ビットの行でのヘッダを示しており、ヘッダは複数のフィールド（ソースIPアドレス及び宛先IPアドレス等）を有する。特に、ヘッダは、8ビットのサービスタイプのフィールド72を含み、このフィールドは、IP優先値又はDSCP値を示す。サービスタイプのフィールド72は、前述のようにネットワーク装置により適応される。
【００４１】
実際には、レイヤ3で最も使用される機構はDSCPであり、DSCPは、6ビット（64の値；最低の優先度が0であり、最高が63である）を使用する。DSCPの値は、しばしばグループで解釈され、0〜7、8〜15等が同じものとして扱われる（詳細はhttp://www.techworld.com/features/index.cfm?fuseaction=displayfeature&featureid=394参照）
図８は、優先度のマッピングを示している。図面は、複数のコンテンツタイプを示す第１列81を有するテーブル80を示している。複数のコンテンツタイプは、優先度の増加に従って、ソフトウェアダウンロード、印刷ジョブ等のための0（最低）、1（未知）、2（オーディオ又はビデオ）及び3（音声）という順になる。対応する優先度の値が、DSCP  IPレイヤの優先度について第２列82に示されており、有線Ethernetの優先度（IEEE802.1q）について第３列83に示されており、無線の優先度（WMMアクセスカテゴリ）について第４列84に示されている。802.1qでは、‘0’の値は特別な意味（旧式又は未定義）を有しており、‘1’（バックグラウンド、タイミングに依存しないものとして明示的に特定されたトラヒック）より高い優先度で扱われる点に留意すべきである。例えば、優先度のマッピングは、図３の優先度ユニット302に結合された記憶ユニット305で使用されてもよい。どのように特定のレイヤ3の優先度の値が特定のレイヤ2の優先度の値に対応するかについて単一の標準は存在しない点に留意すべきである。図面は、4つの優先度の初期設定のマッピングを示しており、これは、（専門家）ユーザにより異なって構成されてもよい。
【００４２】
本発明は、プログラム可能構成要素を使用して、ハードウェア及び／又はソフトウェアで実施されてもよい点に留意すべきである。本発明を実施する方法は、以下のステップを有する。まず、この方法は、入来パケットを検査する。パケットが受信されると、まず、パケットのソースが、例えばIPアドレス／ポート又はMACアドレスに基づいて決定される。ソースが検出されて‘優先度’規則に照合する場合、規則で指定された優先度がこのパケットに使用される。そうでない場合、ソースが‘コンテンツタイプ’規則を有する場合、規則で指定されたパケットのコンテンツタイプを特定する。そうでない場合（規則が存在しない場合）、以下のようにプロトコルヘッダとファイルフォーマットヘッダとコンテンツフォーマットヘッダとを分析することによりコンテンツタイプを決定する。HTTPではMIMEタイプヘッダを検査し、RTPでは（RTSP、SIP、H323等による）セッション設定で使用されるAVプロファイルを検査し、AVIファイルではFourCCコードを検査し、未知のファイルでは一般的な圧縮フォーマット（MPEG、WMV、MP3、JPEG等）に照合することを試みる。次に、特定されたコンテンツタイプをQoSの優先度にマッピングし、例えば、‘video／mpeg’を‘ビデオ’のQoS優先レベルにマッピングする。出力では、決定されたQoS優先度で受信されたかのように処理する。（装置が適切な出力ネットワークインタフェースを有する場合）マッピングは、レイヤ2パケット及びレイヤ3パケットの双方で適用されてもよい。
【００４３】
優先度及びコンテンツ規則の実際の例は以下の通りである。
−優先度規則：www.philips.comから生じたストリームは、常にWMM優先度の‘VO’（最高を意味する）として分類される。
−コンテンツタイプ規則：mp3.comから生じたストリームは常にオーディオとして分類される。
−自動HTTP分析：入来HTTPストリームがMIMEタイプヘッダの‘video／mpeg’を有する。この方法は、このHTTPストリームに属するパケットをIP  DSCPの優先度のフィールドでタグ付けする。そのWiFi出力では、パケットは、WMMの優先レベル‘VF’（ビデオ）に従ってキューに入れられる。そのEthernet出力では、優先レベル‘5’が802.1qレイヤ2のタグの802.1pの優先度のフィールドで使用される。
−自動RTP分析：RTP及びSDPを使用したRTS/H323/SIPセッション設定では、SDPファイルの‘m’フィールドは、特定のTCP/UDP接続のコンテンツタイプを特定する。MPEG2ビデオでは、RTP  AVプロファイルのコンテンツタイプ‘MPV’が使用される。この場合、この方法は、前の例のようにパケットをタグ付けする。
【００４４】
主にインターネットホームネットワークセグメントを使用した実施例により本発明を説明したが、本発明はまた、QoSを認識しないデータストリームを転送するネットワークセグメントとQoSを認識する他のネットワークセグメントとの間の如何なるブリッジにも適する。様々なネットワークセグメントは、同じリソースを物理的に共有してもよい。
【００４５】
この文献では、‘有する’という用語は、記載のもの以外の要素又はステップの存在を除外せず、単数の要素は、このような要素の複数の存在を除外せず、如何なる参照符号も特許請求の範囲を限定せず、本発明は、ハードウェアとソフトウェアとの双方を用いて実施されてもよく、複数の‘手段’又は‘ユニット’は、同じハードウェア又はソフトウェアのアイテムにより表されてもよく、プロセッサは、場合によってはハードウェア要素と協力して１つ以上のユニットの機能を実現してもよい点に留意すべきである。更に、本発明は、実施例に限定されず、本発明は、前述の特徴のそれぞれの新規な特徴又は組み合わせにある。
【図１】
2010504018.tif 000003
【図２】
2010504018.tif 000004
【図３】
2010504018.tif 000005
【図４】
2010504018.tif 000006
【図５】
2010504018.tif 000007
【図６】
2010504018.tif 000008
【図７】
2010504018.tif 000009
【図８】
2010504018.tif 000010
【手続補正書】
【提出日】平成21年3月23日(2009.3.23)
【手続補正１】
【補正対象書類名】明細書
【補正対象項目名】０００１
【補正方法】変更
【補正の内容】
【０００１】
本発明は、第１のネットワークセグメントに結合する第１のインタフェースユニットと、第２のネットワークセグメントに結合する第２のインタフェースユニットと、第１及び第２のネットワークセグメントの間でデータパケットを転送する転送手段と、第２のネットワークセグメントでのサービス要件に適合させるために、第１のネットワークセグメントから第２のネットワークセグメントに転送される受信データパケットのサービス要件を決定する決定手段とを有するネットワーク装置に関する。
【手続補正２】
【補正対象書類名】明細書
【補正対象項目名】０００２
【補正方法】変更
【補正の内容】
【０００２】
本発明は、第１のネットワークセグメントと第２のネットワークセグメントとの間でデータパケットを転送する間にサービス要件を決定する方法に更に関し、この方法は、第２のネットワークセグメントでのサービス要件に適合させるために、第１のネットワークセグメントから第２のネットワークセグメントに転送される受信データパケットのサービス要件を決定するステップを有する。
【手続補正３】
【補正対象書類名】明細書
【補正対象項目名】０００６
【補正方法】変更
【補正の内容】
【０００６】
文献US2006/0013129は、アプリケーションからデータパケットを受信し、データパケットをネットワークセグメントに送信する方法の一例を提供する。或るデータパケットは既知のQoSパラメータを有するが、或るものはこのようなパラメータを有さない。QoSパラメータが提供されない場合、この方法は、データパケットのコンテンツに基づいてQoSパラメータを決定する。出力では、QoSパラメータに従ってデータパケットを送信することにより、ネットワーク性能が改善される。しかし、既知の方法の問題は、多数のパケットが更なるネットワークセグメント（例えば、インターネット）から到達したときに生じる。通常ではQoSパラメータが存在しないネットワークセグメントからサービスパラメータが性能を改善するために制御及び使用され得るセグメントにパケットを転送する必要性が存在する。しかし、パケットのコンテンツから直接にQoSパラメータを検出すること、又はこの目的で帯域測定を実行することは、実行不可能である。
文献US2006/0033467は、ネットワークルータ及びスイッチでのリソース割り当て方法及び装置を開示する。
【手続補正４】
【補正対象書類名】明細書
【補正対象項目名】０００８
【補正方法】変更
【補正の内容】
【０００８】
この目的のため、本発明の第１の態様によれば、冒頭の段落に記載のネットワーク装置において、決定手段は、第１のネットワークセグメントでの受信データパケットのソースを検出し、ソースに応じてサービスタイプを受信データパケットに割り当てることによりサービス要件を決定するように構成され、この割り当ては、所定のプロトコルに従って受信データパケットの制御部分を分析することに基づき、転送手段は、受信データパケットについて第２でのネットワークセグメントでのサービスタイプに適合させるように構成される。
【手続補正５】
【補正対象書類名】明細書
【補正対象項目名】０００９
【補正方法】変更
【補正の内容】
【０００９】
この目的のため、本発明の第２の態様によれば、冒頭の段落に記載の方法において、決定するステップは、第１のネットワークセグメントでの受信データパケットのソースを検出し、ソースに応じてサービスタイプを受信データパケットに割り当てることを有し、この割り当ては、所定のプロトコルに従って受信データパケットの制御部分を分析することに基づき、転送することは、受信データパケットについて第２のネットワークセグメントでのサービスタイプに適合させることを有する。
【手続補正６】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
−第１のネットワークセグメントに結合する第１のインタフェースユニットと；
−第２のネットワークセグメントに結合する第２のインタフェースユニットと；
−前記第１及び第２のネットワークセグメントの間でデータパケットを転送する転送手段と；
−前記第２のネットワークセグメントでのサービス要件に適合させるために、前記第１のネットワークから前記第２のネットワークセグメントに転送される受信データパケットのサービス要件を決定する決定手段と；
を有し、
前記決定手段は、前記第１のネットワークセグメントでの前記受信データパケットのソースを検出し、前記ソースに応じてサービスタイプを前記受信データパケットに割り当てることにより、前記サービス要件を決定ように構成され、前記割り当ては、所定のプロトコルに従って前記受信データパケットの制御部分を分析することに基づき、
−前記転送手段は、前記受信データパケットについて前記第２のネットワークセグメントでの前記サービスタイプに適合させるように構成されるネットワーク装置。
【請求項２】
前記決定手段は、
−ネットワークアドレスインジケータと；
−ネットワークポートインジケータと；
−媒体アクセスインジケータ又は媒体アクセスプロトコルアドレスと；
−前記第１のネットワークセグメントがインターネットに結合されている場合には；
−インターネットプロトコルアドレスと；
−ユニフォームリソースロケータと；
のうち少なくとも１つに基づいて前記受信データパケットの前記ソースを検出するように構成される、請求項１に記載のネットワーク装置。
【請求項３】
前記決定手段は、所定の基準を適用することにより前記サービスタイプを割り当てるように構成され、
前記基準は、
−ソースへのコンテンツタイプのマッピングと；
−ソースの優先度の基準と；
のうち少なくとも１つを含む、請求項１に記載のネットワーク装置。
【請求項４】
前記決定手段は、特に前記制御インタフェースがユーザインタフェース又はアプリケーションプログラミングインタフェースである場合に、前記所定の基準を設定する制御インタフェースを有する、請求項３に記載のネットワーク装置。
【請求項５】
特に前記制御部分がHTTP（hypertext  transfer  protocol）プロトコルに従ったMMIE（Multipurpose  Internet  Mail  Extension）タイプ、RTP（real  time  protocol）に従ったAV（audio  video）プロファイル、又は前記データパケットの前記コンテンツを符号化するために使用されるエンコーダを示すコード、リアルタイムストリーミングプロトコル、セッションイニシエーションプロトコル、H323プロトコル、セッション記述プロトコル又はMPEGビデオプロトコルである他のプロトコルである、請求項１に記載のネットワーク装置。
【請求項６】
前記転送手段は、前記所定のプロトコルに従って前記受信データの前記制御部分を適応させることにより、前記サービスタイプに適合させるように構成される、請求項１に記載のネットワーク装置。
【請求項７】
前記適応は、サービスタイプのフィールドを設定することによりヘッダを適応させることを有する、請求項６に記載のネットワーク装置。
【請求項８】
前記第２のインタフェースユニットは、無線の第２のネットワークセグメントにインタフェース接続する異なるサービスタイプのパケットについて異なるバッファキューを有し、
前記転送手段は、前記サービスタイプに基づいて前記バッファキューの選択されたものを介して前記受信パケットを転送することにより、前記サービスタイプに適合させるように構成される、請求項１に記載のネットワーク装置。
【請求項９】
前記転送手段は、前記第１のネットワークセグメントから受信したデータパケットを格納し、前記第２のネットワークセグメントに送信されるデータパケットを取得する大容量記憶装置を有し、
前記決定手段は、前記格納前又は前記取得後に前記サービスタイプを割り当てるように構成される、請求項１に記載のネットワーク装置。
【請求項１０】
第１のネットワークセグメントと第２のネットワークセグメントとの間でデータパケットを転送する間にサービス要件を決定する方法であって：
前記第２のネットワークセグメントでのサービス要件に適合させるために、前記第１のネットワークから前記第２のネットワークセグメントに転送される受信データパケットのサービス要件を決定するステップを有し；
前記決定することは：
−前記第１のネットワークセグメントでの前記受信データパケットのソースを検出し；
−前記ソースに応じてサービスタイプを前記受信データパケットに割り当てることを有し、前記割り当ては、所定のプロトコルに従って受信データパケットの制御部分を分析することに基づき；
前記転送することは：
−前記受信データパケットについて前記第２のネットワークセグメントでの前記サービスタイプに適合させることを有する方法。
【請求項１１】
第１のネットワークセグメントと第２のネットワークセグメントとの間でデータパケットを転送する間にサービス要件を決定するコンピュータプログラムであって、
請求項１０に記載の方法をプロセッサに実行させるように動作可能なコンピュータプログラム。
【国際調査報告】
2010504018.tif 000011
2010504018.tif 000012