(57)【要約】【課題】既存のアプリケーションや端末に変更や改造を加えることなく容易にＱｏＳ制御を実現できる方法及び装置を提供する。【解決手段】連携機能部１４は、発側端末１からＤＮＳサーバ５に発せられた着側端末２のホスト名に係る名前解決要求及び該名前解決要求に応じてＤＮＳサーバ５が発側端末１に送信した応答の何れか一方又は双方に基づき発側端末１及び着側端末２を特定し、該発側端末１と着側端末２間のデータストリームに適用するＱｏＳ制御内容を特定し、ＱｏＳ管理機能部１３に対してＱｏＳ制御の対象となるデータストリーム及びＱｏＳの制御内容を指示する。【選択図】図１
2014158078.tif 000002
【特許請求の範囲】
【請求項１】
ホスト名からアドレスを解決する名前解決サーバと、端末間のデータストリームのＱｏＳ制御を行うＱｏＳ制御実施手段と、ＱｏＳ制御手段によるＱｏＳ制御を管理するＱｏＳ制御管理手段とを有するネットワークにおけるＱｏＳ制御方法であって、
ネットワーク内に配置した連携機能手段が、発側端末から名前解決サーバに発せられた着側端末のホスト名に係る名前解決要求及び該名前解決要求に応じて名前解決サーバが発側端末に送信した応答の何れか一方又は双方に基づき発側端末及び着側端末を特定し、該発側端末と着側端末との間のデータストリームに適用するＱｏＳ制御内容を特定し、ＱｏＳ制御管理手段に対してＱｏＳ制御の対象となるデータストリーム及びＱｏＳの制御内容を指示する
ことを特徴とするＱｏＳ制御方法。
【請求項２】
前記連係機能手段は、名前解決要求に応じて名前解決サーバが発側端末に送信した応答に含まれる該応答メッセージの生存期間を小さくなるよう書き換える
ことを特徴とする請求項１記載のＱｏＳ制御方法。
【請求項３】
前記名前解決サーバはＤＮＳサーバである
ことを特徴とする請求項１記載のＱｏＳ制御方法。
【請求項４】
ホスト名からアドレスを解決する名前解決サーバと、端末間のデータストリームのＱｏＳ制御を行うＱｏＳ制御実施手段と、ＱｏＳ制御手段によるＱｏＳ制御を管理するＱｏＳ制御管理手段とを有するネットワークに配置されたＱｏＳ制御装置であって、
発側端末から名前解決サーバに発せられた着側端末のホスト名に係る名前解決要求及び該名前解決要求に応じて名前解決サーバが発側端末に送信した応答の何れか一方又は双方に基づき発側端末及び着側端末を特定し、該発側端末と着側端末間のデータストリームに適用するＱｏＳ制御内容を特定し、ＱｏＳ制御管理手段に対してＱｏＳ制御の対象となるデータストリーム及びＱｏＳの制御内容を指示する連携機能手段を備えた
ことを特徴とするＱｏＳ制御装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ネットワークにおける端末間のデータストリームのＱｏＳ制御を行う技術に関する。
【背景技術】
【０００２】
通信事業者が提供するＩＰ網においてＱｏＳ（Quality of Service）制御を実現するために、呼制御プロトコルであるＳＩＰ（Session Initiation Protocol）／ＳＤＰ（Session Description Protocol）を用いる方式が標準化され、広く利用されている。ＳＩＰメッセージ内のＳＤＰ部には、ＩＰアドレス、ポート番号等の情報が含まれる。端末からのＳＩＰメッセージを受け取った網内の呼制御機能部であるＣＳＣＦ（Call Session Control Function）は、これらの情報をもとに、ＱｏＳ制御をＱｏＳ管理機能部に指示し、ＱｏＳ実施機能部が実際にＱｏＳ制御や課金情報の生成を行う（非特許文献１〜４）。
【先行技術文献】
【非特許文献】
【０００３】
【非特許文献１】"Resource and Admission Control Sub-System (RACS): Functional Architecture", ETSI ES 282 003, [online], [平成25年1月15日検索], インターネット<URL:http://www.etsi.org/deliver/etsi#es/282000#282099/282003/03.05.01#60/es#282003v030501p.pdf>
【非特許文献２】"Policy and charging control architecture", 3GPP TS 23.203, [online], [平成25年1月15日検索], インターネット<URL:http://www.3gpp.org/ftp/Specs/archive/23#series/23.203/>
【非特許文献３】"SIP: Session Initiation Protocol", RFC3261, [online], [平成25年1月15日検索], インターネット<URL:http://www.ietf.org/rfc/rfc3261.txt>
【非特許文献４】"SDP: Session Description Protocol", RFC4566, [online], [平成25年1月15日検索], インターネット<URL:http://www.ietf.org/rfc/rfc4566.txt>
【発明の概要】
【発明が解決しようとする課題】
【０００４】
従来技術であるＳＩＰの場合、通信事業者が提供するＱｏＳ機能の提供を受けるために、アプリケーションがＳＩＰをサポートする必要がある。したがって、アプリケーション毎にＳＩＰに関連する機能を追加開発する必要があるが、この開発負担が非常に大きいため、利用が困難である。
【０００５】
本発明は、上記事情に鑑みてなされたものであり、その目的とするところは、既存のアプリケーションや端末に変更や改造を加えることなく容易にＱｏＳ制御を実現できる方法及び装置を提供することにある。
【課題を解決するための手段】
【０００６】
上記目的を達成するために、本願発明は、ホスト名からアドレスを解決する名前解決サーバと、端末間のデータストリームのＱｏＳ制御を行うＱｏＳ制御実施手段と、ＱｏＳ制御手段によるＱｏＳ制御を管理するＱｏＳ制御管理手段とを有するネットワークにおけるＱｏＳ制御方法及び装置であって、ネットワーク内に配置した連携機能手段が、発側端末から名前解決サーバに発せられた着側端末のホスト名に係る名前解決要求及び該名前解決要求に応じて名前解決サーバが発側端末に送信した応答の何れか一方又は双方に基づき発側端末及び着側端末を特定し、該発側端末と着側端末との間のデータストリームに適用するＱｏＳ制御内容を特定し、ＱｏＳ制御管理手段に対してＱｏＳ制御の対象となるデータストリーム及びＱｏＳの制御内容を指示することを特徴とする。
【発明の効果】
【０００７】
本発明によれば、通信において汎用的に用いられている名前解決の技術を利用するので、既存のアプリケーションや端末への変更・改造が不要となり、これにより容易にＱｏＳ制御を実現できる。
【図面の簡単な説明】
【０００８】
【図１】本発明に係るＱｏＳ制御を説明するネットワーク構成図
【図２】実施例１に係るＱｏＳ制御を説明するシーケンスチャート
【図３】実施例２に係るＱｏＳ制御を説明するシーケンスチャート
【図４】実施例２に係るＱｏＳ制御を説明するシーケンスチャート
【発明を実施するための形態】
【０００９】
本発明の一実施の形態に係るＱｏＳ制御について図１を参照して説明する。図１は本発明に係るＱｏＳ制御を説明するネットワーク構成図である。
【００１０】
通信事業者網１０には、図１に示すように、通信事業者網１０に接続した端末１，２間のデータストリームのＱｏＳ制御を実施するＱｏＳ実施機能部１１，１２と、各ＱｏＳ実施機能部１１，１２によるＱｏＳ制御を管理するＱｏＳ管理機能部１３と、端末１，２と既存のＤＮＳ（Domain Name System）サーバ５との通信に基づきＱｏＳ管理機能部１３と連携してＱｏＳ制御を行う連携機能部１４，１５とが配置されている。なお、現実の実装においては、連携機能部１４，１５はＤＮＳサーバ５あるいはＱｏＳ管理機能部１３と同一の装置に集約される場合もある。また、連携機能部１４，１５は、それぞれ端末１，２が発側端末となった場合に機能するものである。
【００１１】
連携機能部１４は、発側端末１とＤＮＳサーバ５の間でプロキシとして動作し、ＤＮＳメッセージを中継する。あるいは、発側端末１からは透過的に動作し、ＤＮＳメッセージをスヌープ（監視）する。
【００１２】
発側端末１は着側端末２に通信する際、従来の通信と同様に、ＤＮＳサーバ５に対して、着側端末２のホスト名をキーとして、着側端末２のＩＰアドレスを問い合わせる。ＤＮＳサーバ５は、発側端末１に対して着側端末２のＩＰアドレスを応答メッセージに含めて通知する。
【００１３】
連携機能部１４は、問い合わせメッセージのＩＰヘッダ内の送信元ＩＰアドレスフィールドから発側端末１の物理アドレスを取得する。また、応答メッセージのリソースレコード内のＲＤＡＴＡフィールド（Ａレコード）から着側端末２のＩＰアドレスを取得する。このほかにも、リソースレコードのＮＡＭＥフィールドから着側端末２のホスト名、ＴＹＰＥフィールドからＤＮＳレコードの種類を取得し、ＱｏＳ制御に利用する場合もある。連携機能部１４はこれらの情報をもとに、ＱｏＳ制御を行うかどうか判断する。当該判断には、着側端末２のＩＰアドレスが特定のＩＰアドレス帯に含まれているか、着側端末２のホスト名が特定のサブドメイン名を持つか否か、ＤＮＳレコード（ＮＡＰＴＲレコード）中のサービス種別などの例がある。
【００１４】
ＱｏＳ制御を行う場合、連携機能部１４はＱｏＳ管理機能部１３に対して、制御対象のデータストリームを識別する情報（発側端末１・着側端末２のＩＰアドレス等）と、ＱｏＳ制御の内容（ＩＰヘッダ内のＤＳＣＰ（Differentiated Services Code Point）値の書き換え等）を指示する。
【００１５】
ＱｏＳ制御内容は、ＩＰアドレス帯やサブドメイン等、特定の範囲と紐づけて決定される場合や、単一の対象（ホスト名に含まれる電話番号等、加入者を識別可能な情報等）と紐づけて決定される場合がある。前者の場合、例えばＤＮＳサーバ５への問い合わせホスト名に特定のサブドメインが含まれる場合には高優先、それ以外の場合には低優先にする方法や、例えばＤＮＳサーバ５により解決されたＩＰアドレスが特定のＩＰアドレス帯に含まれる場合には高優先、それ以外の場合には低優先にする方法などが挙げられる。後者の場合、例えば、通信事業者が保持する加入者情報データベース（図示省略）に、加入者毎に実施するＱｏＳ制御内容を予め設定しておき、連携機能部１４が問い合わせを行うことでＱｏＳ制御内容を決定する等が考えられる。このように、ＱｏＳ制御内容を決定するにあたって、どのような識別単位や情報に基づきＱｏＳ制御内容を決定するか、またＱｏＳ制御内容の決定に必要な対応情報等をどこに保存しておくかなど、その具体的な実装について種々の方法を適宜選択することができる。
【００１６】
ＱｏＳ管理機能部１３は指示された内容をもとに、内部のリソース確保状態等からＱｏＳ実施機能部１１，１２に対して具体的な指示を行い、ＱｏＳ制御を実現する。このとき、リソース確保に失敗すると、ＱｏＳ管理機能部１３は連携機能部１４に対してＱｏＳ制御の実施に失敗したことを通知する。通知を受けた連携機能部１４は、応答メッセージのＡ／ＡＡＡＡレコードを書き換え、名前解決に失敗した事を示すＮｏ Ｒｅｃｏｒｄ等のメッセージを発側端末１に送信する場合もある。なお、ＱｏＳ管理機能部１３とＱｏＳ実施機能部１１，１２とは、１つの装置として集約される場合もある。
【００１７】
また、このとき連携機能部１４は、応答メッセージ内に含まれるＤＮＳレコードの有効期限を表すＴＴＬ（Time To Live）フィールドを短く書き換えることで、端末１内のＤＮＳキャッシュ保持時間を短縮する場合もある。これにより、改めて通信を行う際にも再度発側端末１からＤＮＳサーバ５への問い合わせを行わせ、ＱｏＳ機能を提供可能となる。
【００１８】
ＱｏＳ実施機能部１１，１２は、予め定められた時間、あるいは転送量やパケット数を超えるまでの間、もしくは一定時間以上の通信途絶が発生するまでの間、ＱｏＳ制御を継続する。また、ＱｏＳ実施機能部１１，１２またはＱｏＳ管理機能部１３において、ＱｏＳ機能の提供回数、あるいは転送量、パケット数、通信時間などをもとに課金情報を生成する。
【実施例１】
【００１９】
本発明の実施例１について図２のシーケンスチャートを参照して説明する。本実施例１はＴＩＳＰＡＮ（Telecommunications and Internet converged Services and Protocols for Advanced Networking）モデルのＮＧＮ（Next Generation Networks ）において本発明を実施する例である。
【００２０】
固定網のアーキテクチャの１つであるＴＩＳＰＡＮモデルのＮＧＮの場合、連携機能部１４０が、ＱｏＳ管理機能部１３に相当するＲＡＣＳ（Resource and Admission Control Subsystem）１３０との間でインタフェースを持ち、ＲＡＣＳ１３０にＱｏＳ制御を指示する。ＲＡＣＳ１３０は、ＱｏＳ実施機能部１１，１２に相当するＣ−ＢＧＦ（Core - Border Gateway Function）やＲＣＥＦ（Resource Control Enforcement Function）１１０に対して指示を行うことで、発側端末１０１−着側端末１０２間のデータストリームに対してＱｏＳ制御を行う（図２）。
【００２１】
本実施例１では、特定のＩＰアドレス宛の通信に対して、ＱｏＳ機能を提供する場合を示す。
【００２２】
発側端末１０１は、図２に示すように、着側端末１０２のホスト名をもとに、ＤＮＳサーバ５０へ着側端末１０２のＩＰアドレスを問い合わせる（ステップＳ１０１）。
【００２３】
連携機能部１４０はＤＮＳプロキシとして動作し、端末１０１とＤＮＳサーバの間でメッセージを中継する（ステップＳ１０１〜Ｓ１０４）。連携機能部１４０は、問い合わせメッセージのＩＰヘッダ内の送信元アドレスフィールド、応答メッセージのＤＮＳメッセージ内のＡＮＳＷＥＲフィールドから発側端末１０１、着側端末１０２双方のＩＰアドレスを取得し、着側端末１０２のＩＰアドレスが、ＱｏＳ制御を行うＩＰアドレス帯に含まれているか判断を行う（ステップＳ１０５）。
【００２４】
もし含まれている場合、連携機能部１４０はＲＡＣＳ１３０に対して発側端末１０１、着側端末１０２双方のＩＰアドレスを通知し（ステップＳ１０６）、ＲＡＣＳ１３０がＣ−ＢＧＦ／ＲＣＥＦ１１０に対してＩＰヘッダ内のＤＳＣＰ値の書き換えを指示することで（ステップＳ１０７）、発側端末１０１−着側端末１０２間のデータストリームを優先的に扱う（ステップＳ１０８〜Ｓ１１０）。
【００２５】
ＱｏＳ制御を行う時間は予め定められた時間（本実施例では５分）とし、ＱｏＳ機能提供の度に、課金情報を生成する（ステップＳ１１１）。
【実施例２】
【００２６】
本発明の実施例２について図３及び図４のシーケンスチャートを参照して説明する。本実施例２は移動体網において本発明を実施する例である。
【００２７】
移動体網のアーキテクチャの１つである３ＧＰＰ（3rd Generation Partnership Project）のＥＰＣ（Evolved Packet Core）アーキテクチャでは、ＱｏＳ管理機能部１３がＰＣＲＦ（Policy and Charging Rules Function）２３０、ＱｏＳ実施機能部１１，１２がＰＣＥＦ（Policy and Charging Enforcement Function）２１０となる。連携機能部２４０は、ＤＮＳサーバ５０及びＰＣＲＦ２３０と連携する。
【００２８】
本実施例２では、サービス毎に異なる複数のホスト名を着側端末１０２に付与することで、サービスに応じて異なるＱｏＳ提供を行う。
【００２９】
まず、着側端末１０２には、予め２つのホスト名が付与される。ここでは、「abc.phone.example.com」と「abc.message.example.com」が付与されているとする。
【００３０】
第１の発側端末１０１ａは、図２に示すように、着側端末１０２のホスト名「abc.phone.example.com」をキーとしてＤＮＳサーバ５０に問い合わせる（ステップＳ２０１）。連携機能部２４０は、最優先のＱｏＳを提供するサービスであることを示すサブドメインである「phone.example.com」であることから第１の発側端末１０１ａ−着側端末１０２間のデータストリームを最優先データストリームとして取り扱うよう判断し（ステップＳ２０５）、ＰＣＲＦ２３０に対してＱｏＳ制御を指示する（ステップＳ２０６）。以降の処理は実施例１と同様である。
【００３１】
一方、第２の発側端末１０１ｂの場合、図３に示すように、「abc.message.example.com」をキーとしてＤＮＳサーバ５０に問い合わせる（ステップＳ２５１）。連携機能部２４０は低優先のＱｏＳを提供するサービスであることを示すサブドメインである「message.example.com」であることから、第２の発側端末１０１ｂ−着側端末１０２間のデータストリームは逆に低優先データストリームとして扱うよう判断し（ステップＳ２５５）、ＰＣＲＦ２３０に対してＱｏＳ制御を指示する（ステップＳ２５６）。以降の処理は実施例１と同様である。このように、同じ着側端末１０２でも、ホスト名を使い分けることにより異なるＱｏＳ機能を提供することができる。
【実施例３】
【００３２】
本発明の実施例３について説明する。本実施例３では、ＱｏＳ制御の実施要否判断にホスト名ではなく、ＤＮＳレコードの一種であるＮＡＰＴＲレコードを利用する場合について示す。
【００３３】
ＥＮＵＭ（E.164 NUmber Mapping）サーバ等で用いられるＮＡＰＴＲレコードには、ホスト名に対応するＵＲＩ・サービスの種類についての情報が含まれている。そのため、ＮＡＰＴＲレコードを利用することで、ホスト名からサービスの種類を解決し、サービスに応じたＱｏＳ制御の要否を判断できる。
【実施例４】
【００３４】
本発明の実施例４について説明する。本実施例４では、前記実施例２において、ＱｏＳ管理機能部にセッション監視機能を追加する場合を示す。
【００３５】
セッション監視機能により端末間の通信を監視することで、実施例１〜３のように、予め定められた時間でＱｏＳ制御を終了するのではなく、３０秒間当該フローのデータストリームがないことをもって通信終了と判断することによって、通信開始から通信終了までの不定の時間に対してＱｏＳ制御を継続することができる。また、ＱｏＳ制御開始から終了までの時間に基づいて課金情報を生成することもできる。
【実施例５】
【００３６】
本発明の実施例５について説明する。本実施例５では、前記実施例２において、ＱｏＳ管理機能部にパケットカウンタ機能を追加する場合を示す。
【００３７】
パケットカウンタ機能の導入により、端末間を流れるパケット数や転送量を取得できるようになる。これらの情報は、ＱｏＳ制御の終了トリガとして、あるいは、課金情報の生成時に利用することができる。
【符号の説明】
【００３８】
１，１０１，２，１０２…端末、１１，１２…ＱｏＳ実施機能部、１３…ＱｏＳ管理機能部、１４，１５，１４０，２４０…連係機能部、５，５０…ＤＮＳサーバ、１１０…Ｃ−ＢＧＦ／ＲＣＥＦ、１３０…ＲＡＣＳ、２１０…ＰＣＥＦ、２３０…ＰＣＲＦ
【図１】
2014158078.tif 000003
【図２】
2014158078.tif 000004
【図３】
2014158078.tif 000005
【図４】
2014158078.tif 000006