JP3905501B2 - ＱｏＳ制御システムおよびＱｏＳ制御方法 - Google Patents

Description

本発明は，ネットワークリソース確保型ＱｏＳ制御方法に関し，ＶｏＩＰ，映像と音声によるコミュニケーション及びＴＶ会議システム，映像配信等，ＩＰネットワーク上でＳＩＰ(Session Initiation Protocol) 等によるセッション制御を行う通信アプリケーションにおいて，ＱｏＳ(Qualty of Service) 提供に関する技術分野に属するものである。

高速・広帯域なアプリケーションがインターネット上で普及するに伴い，ＩＰネットワーク上でＱｏＳを提供するサービスが重要になってきている。これに対し，ＳＩＰなどによるセッション制御を行う通信アプリケーションにおいても，ネットワークリソースを予約した上でセッション確立を行う必要が高まってきた。

しかしながら，従来のセッション制御においては，セッション確立前のネットワークリソース確保方法がなく，呼び出し(Ringing) 応答などの後で，セッションが確立した後にネットワークリソースが確保されていないために，ＱｏＳを提供することができなかった。

この問題点に対し，ネットワークリソースが確保されていないセッションの確立を防ぐために，ＳＩＰセッションの場合，ＲＦＣ３３１２（非特許文献１参照）においてRinging 前に通信者同士がネットワークリソース要求条件についてネゴシエーションを行い，ＲＳＶＰ(Resource reSerVation Protocol) 等のネットワークリソース予約手段を用いてリソースを確保した上でRinging を行い，ＱｏＳが確保されたセッションを確立する方式が提案された。

しかしながら，本ＲＦＣでネットワークリソース予約手段として例示されたＲＳＶＰを用いる場合（例えば，非特許文献２参照），ネットワーク内にＲＳＶＰ対応ネットワーク装置を設置する必要があること，また，リソース予約時にシグナリングによりリソースを予約していくことからネットワーク規模に対するスケーラビリティ及びリソース予約にかかる時間に関しネットワーク装置の性能及び装置数に依存するため，応答時間の観点で問題が生じる可能性がある。

図９に，従来のＲＦＣ３３１２で例示されたリソース予約方法としてＲＳＶＰを用いる方式のシーケンスを示す。ここでは，ユーザ端末３とユーザ端末４との間でセッションを開始する場合を例にとって説明する。

ユーザ端末３はセッション確立要求を行うため，ユーザ端末４にＳＩＰメッセージであるＩＮＶＩＴＥメッセージによりＳＤＰ１を送信する（Ｓ７−１）。ユーザ端末４は，１８３応答によりＳＤＰ２をユーザ端末３に送信する（Ｓ７−２）。ユーザ端末３は，ユーザ端末４にＰＲＡＣＫメッセージを送信し（Ｓ７−３），ユーザ端末４はＰＲＡＣＫメッセージに対する２００ＯＫ応答を行う（Ｓ７−４）。

次に，ユーザ端末３はユーザ端末４にＲＳＶＰ ＰＡＴＨを送信し（Ｓ７−５），ユーザ端末４はユーザ端末３にＲＳＶＰ ＲＥＳＶを送信する（Ｓ７−６）。また，ユーザ端末４はユーザ端末３にＲＳＶＰ ＰＡＴＨを送信し（Ｓ７−７），ユーザ端末３はユーザ端末４にＲＳＶＰ ＲＥＳＶを送信する（Ｓ７−８）。このＳ７−５〜Ｓ７−８の処理によってＲＳＶＰによるリソース予約が行われる。

次に，ユーザ端末３はユーザ端末４にＵＰＤＡＴＥメッセージを送信し（Ｓ７−９），ユーザ端末４は２００ＯＫ（ＵＰＤＡＴＥ）をユーザ端末３に送信する（Ｓ７−１０）。続けて，ユーザ端末４は１８０Ringing を行う（Ｓ７−１１）。ユーザ端末３はこれに対するＰＲＡＣＫメッセージを送信し（Ｓ７−１２），ユーザ端末４はＰＲＡＣＫメッセージに対する２００ＯＫを返す（Ｓ７−１３）。

次に，ユーザ端末４は最初のＩＮＶＩＴＥメッセージに対する２００ＯＫを返し（Ｓ７−１４），ユーザ端末３はＡＣＫを返す（Ｓ７−１５）。これにより，セッションが開始される（Ｓ７−１６）。

なお，下記の非特許文献３に，ネットワークのリンク毎に帯域を一元的に管理するリソース管理機能について記載されている。
G.Camarillo,et al.,"Integration of Resource Management and Session Initiation Protocol(SIP)",RFC3312,IETF,Oct.2003. S.Sargento,et al.,"IP-Based Access Networks for Broadband Multimedia Services",IEEE Communication magazine,pp.146-154,Feb.2003. 矢口他，"大規模ＩＰ網における管理サーバを用いたリソース管理方式の一提案と具体例"，電子情報通信学会総合大会，B-6-31,Mar.2002.

従来のＩＰ技術によるＳＩＰ等を用いたセッション制御においては，ネットワークリソースの予約を行う前に通信相手に対する呼び出し（Ringing ）を行うために，呼び出しに応答したにもかかわらず通信に必要なリソースが確保されず高品質な通信品質を確保できない場合があった。

また，図９に示したような，リソース予約手段としてＲＳＶＰを用いる従来の方式を用いる場合，ＲＳＶＰによるリソース予約（Ｓ７−５〜Ｓ７−８）を行うためにはＲＳＶＰ対応のネットワーク装置をＩＰネットワーク内に導入する必要があり，さらに，リソース予約にかかる時間はＲＳＶＰ対応ネットワーク装置の性能及び装置数に依存するため，リソース確保のための時間が問題になる可能性がある。

本発明は，上記課題を解決してＩＰネットワーク上でセッション制御によるリソース確保型の高品質な通信サービスをスケーラブルかつリソース確保にかかる遅延を最小にして提供することを目的とする。

本発明は，上記課題を解決すべく，ネットワークのリンク毎に帯域を一元的に管理するリソース管理機能（例えば，非特許文献３参照）を用いることにより，スケーラブルかつ遅滞のないリソース予約を実現しつつ，リソース予約が完了するまではRinging を行わないネットワークリソース確保型のセッション制御方式により，ＱｏＳを提供するサービスの実現を可能とする。すなわち，ネットワークリソースを確保したセッション確立をスケーラブルかつリソース確保時間に関し遅滞なく実現可能とするという上記課題に対し，本発明は，リソース確保型セッション確立手順におけるリソース予約方法として，以下に述べるセッション制御手段及びリソース管理手段を用いる。

本発明では，通信端末同士が双方のリソース要求条件をネゴシエーションすると同時に，端末を中継するセッション制御手段は，双方のリソース要求条件をリソース管理手段にセッション制御プロトコルにて規定されたリソース要求に関するメッセージを用いて通知することにより，リソース予約が行われる。

リソース管理手段は，要求帯域を該リソース管理手段が一元的に管理するネットワークリソース情報と比較することによる帯域判定及びネットワークリソース情報の更新を行う。リソース管理手段は，ネットワークの各リンクにおける利用可能帯域をデータベース（ＤＢ）等を用いて一元的に管理しているため，リソース要求に対する検索時間も短い。本判定結果はセッション制御手段に通知され，セッション制御手段において判定結果に基づき，リソース要求に関するメッセージ内容を変更して端末に通知することによりネットワークリソースが確保される。

ネットワークリソースが確保されれば，Ringing とそれに引き続きネットワークリソースを確保したセッションが確立し，通信が開始される。このとき，通信端末から送信されるＩＰパケットのトラヒック流量を制御する必要がある場合には，最初のセッション確立要求メッセージに，トラヒック流量制御の要否に関する識別子を付けて送信することなどの方法により，ネットワークソースをリソース管理部において予約した後のRinging 後に，リソース管理手段から通信端末が設置された宅内において設置される装置またはエッジ装置に対して，ＩＰヘッダのＴｏＳ(Type of Service) 値などの優先パケットフラグを付け替え，また，トラヒック流量制御手段を作動させるよう通知して制御する手段と，リソース管理手段によるリソース予約と合わせて２段階のリソース確保方法により，リソースを確保した上でトラヒック流量を制御する。このように２段階でリソースを確保することで，トラヒック流量制御をリソース管理手段によるネットワークリソース予約と同時に行う場合に比べ，最初のＩＮＶＩＴＥによるリソース要求からRinging までの遅延時間を短縮することが可能となる。

通信端末間の通信が終了する時に，セッション終了に関するセッション制御信号をセッション制御手段が受信して，リソース管理手段に通知することにより，リソース管理手段における当該セッションに関する帯域が開放され，ネットワークリソース情報が更新される。

ネットワークリソースの不足により，リソース管理手段によって帯域が予約されない場合，セッション要求は中断し，リソースを確保しないセッションに対するRinginｇが行われることはなく，リソースが確保されていない応答が行われることはない。

さらに，本発明によれば，リソースの確保を必要としないセッションとリソース確保を必要とするセッションとを区別するために，最初のセッション確立要求メッセージにリソース確保の要否に関する識別子をつけることにより，セッション制御手段において該識別子をもとに，リソース確保を必要としないセッションに関してはリソース管理手段に通知しないことにより，リソースを確保するセッションと区別して処理することが可能である。

本発明によれば，ＳＩＰなどセッション制御方式を用いてネットワークリソースを確保して通信を行う場合，リソースが確保されない状態でRinging が行われることはなく，かつ，ネットワークリソースのＲＳＶＰを用いたリソース予約方式に比ベスケーラブルで短時間で確保可能なリソース確保型の通信サービスを適用することが可能になる。

本発明の実施の形態について，図面を用いて説明する。図１に，本発明の構成例を示す。同図は，ユーザ端末装置同士がＳＩＰによるセッション確立に引き続いて通信を行う場合の形態を示す。

図１に示す本発明の実施の形態は，Ｑｏｓの制御を行うＱｏｓ制御システム１，コアネットワーク装置２０とエッジネットワーク装置２１とユーザ宅内装置２２などから構成されるＩＰネットワーク２，通信を行うユーザ端末３，４から構成される。

Ｑｏｓ制御システム１は，セッション制御機能を有するセッション制御部１１，及びＩＰネットワーク上を流れるＩＰパケットの使用帯域をリンク毎に一元的に管理するリソース管理機能を有するリソース管理部１２とから構成される。リソース管理部１２は，ネットワークの各リンクにおける利用可能帯域情報が格納されるリソース管理ＤＢ１３を持つ。

セッション制御部１１は，１台または複数台のワークステーション，サーバ装置，ＰＣサーバ，ＰＣなどのコンピュータとソフトウェア・プログラムとによって実現される。また，リソース管理部１２も，１台または複数台のワークステーション，サーバ装置，ＰＣサーバ，ＰＣなどのコンピュータとソフトウェア・プログラムとによって実現される。セッション制御部１１とリソース管理部１２とは，別筐体に実装することも，同一筐体に実装して実現することも可能である。

ユーザ端末３がユーザ端末４とＩＰネットワーク上のリソースが確保された通信を行う場合，ユーザ端末３は，Ｑｏｓ制御システム１のセッション制御部１１に対し，自端末のＩＰアドレス等の端末識別子，及び通信に必要となる帯域幅，及びリソースを確保したセッションを要求する旨の識別子，トラヒック流量制御の要否に関する識別子などを，ＳＩＰメッセージであるＩＮＶＩＴＥメッセージのＳＤＰとして記述し，通信を行おうとするユーザ端末４に対してはＳＩＰアドレス等により指定し，セッション制御部１１に対し通信開始要求を送信する（Ｓ１−１）。

このとき，セッション制御部１１はユーザ端末４にＩＮＶＩＴＥ要求を転送する（Ｓ１−２）。このとき，ユーザ端末３からのＳＤＰの内容を参照し，リソース確保型のセッション要求であること及びリソース確保型通信を要求するユーザであることを確認する。

ユーザ端末４は，ＩＮＶＩＴＥメッセージのＳＤＰの内容からユーザ端末３がリソース確保型の通信を要求していることを確認し，通信を許可する場合にはユーザ端末３方向のリソース確保要求をＳＤＰに記載して，セッション制御部１１に１８３応答として送信する（Ｓ１−３）。

セッション制御部１１において，ユーザ端末３からのＩＮＶＩＴＥメッセージに含まれるユーザ端末４方向のリソース確保要求，及び１８３応答に含まれるユーザ端末３方向のリソース確保要求を参照し，ユーザ端末３，４のＩＰアドレス及び双方向の要求帯域をリソース管理部１２に送信する（Ｓ１−４）。

リソース管理部１２において，上記ＩＰアドレスから保有するＩＰネットワークのトポロジテーブルをもとに通過経路を算出し，通過するリンク毎に必要な帯域を積み上げる。積み上げた結果がリンク毎の最大リソース量を超えなければ，セッション制御部１１にリソース予約を通知し，そうでない場合にはリソース予約不可を通知する（Ｓ１−５）。

セッション制御部１１は，ユーザ端末３に対する１８３応答のＳＤＰを書き換え，リソース予約が行われた場合には，ＲＦＣ３３１２で規定されるカレント(current) 値等を利用してリソース予約が行われた旨を通知する（Ｓ１−６）。そうでない場合には，エラーメッセージを返却する等により，リソース予約に失敗した旨を通知する。

次いで，ＲＦＣ３３１２に基づいた後述する図２に示す端末間のシグナリングにより，ユーザ端末３，４間のリソース要求に対する前提条件（Precondition）が確定し，Ringing を行うアプリケーションにおいてはRinging を行い，ユーザ端末３，４間でセッションが確立する。以上の手順は，図１では一括して手順Ｓ１−７として示している。

トラヒック流量制御を行う場合には，最初のＩＮＶＩＴＥに対するユーザ端末４からの２００ＯＫメッセージ（Ｓ１−８）を，セッション制御部１１において受け取ると，セッション制御部１１は，リソース管理部１２にトラヒック流量制御を行う旨を通知し（Ｓ１−９），リソース管理部１２は，通信端末が設置されたユーザ宅内装置２２またはエッジネットワーク装置２１に対して，ＩＰヘッダのＴｏＳ(Type of Service) 値などの優先パケットフラグを付け替え，また，トラヒックシェーピングやポリシングといったトラヒック流量制御手段を作動させるよう通知する（Ｓ１−１０）。ユーザ宅内装置２２やエッジネットワーク装置２１などの制御対象装置からリソース管理部１２に対する動作完了通知（Ｓ１−１１）及びリソース管理部１２からセッション制御部１１に対する動作完了通知（Ｓ１−１２）後，セッション制御部１１からユーザ端末３に２００ＯＫメッセージが転送される（Ｓ１−１３）。その後，ユーザ端末３，４間でネットワークリソースが確保された通信が開始される（Ｓ１−１４）。

図２は，本発明の実施の形態におけるセッション開始時におけるシーケンス図である。本図を用いて処理の流れを説明する。ユーザ端末３は，セッション確立要求を行うためＩＮＶＩＴＥメッセージを送信する（Ｓ２−１）。このとき，ＩＮＶＩＴＥメッセージのＳＤＰ（ＳＤＰ１）のリソース確保に関する記述は，図３（Ａ）のようになっている。以下，ＲＦＣ３３１２に記載された表記法に従い，図３（Ａ）に示すＳＤＰ１情報の設定例を説明する。

本例の場合，品質確保の区間は，ユーザ端末３からユーザ端末４までのエンド−エンド区間であり品質確保を行われていない（none）である。さらに，品質予約はエンド−エンド（ｅ２ｅ）で双方向（sendrecv）に要求（mandatory ）している。また，必要帯域はＸであり，リソース予約要求である識別子はＺである。

セッション制御部１１では，上記の情報を調べて識別子にＺが入っていれば，ＩＮＶＩＴＥメッセージをユーザ端末４に転送する（Ｓ２−２）。さらに，ユーザ端末４はＩＮＶＩＴＥメッセージを確認し，１８３応答にてＳＤＰ（ＳＤＰ３）をセッション制御部１１に送信する（Ｓ２−３）。セッション制御部１１では，ＳＤＰ１及びＳＤＰ３より取得したユーザ端末３，４のＩＰアドレス（Ａ，Ｂ），双方向の要求帯域をリソース管理部１２に送信する（Ｓ２−４）。

リソース管理部１２では，本情報をもとにリソース管理ＤＢ１３を検索してリソース判定結果（帯域判定結果）をセッション制御部１１に返す（Ｓ２−５）。セッション制御部１１では，ネットワークリソースがリソース管理部１２により予約されたと判定された場合，ＳＤＰのカレント値をリソース確保なし（none）からリソースを確保した方向（本例の場合，双方向を表すsendrecv）に書き換えてユーザ端末３に送信する（Ｓ２−６）。

書き換えたＳＤＰ情報（ＳＤＰ４）の例を図３（Ｂ）に示す。ユーザ端末３は本メッセージを受信すると，ユーザ端末４に対しＰＲＡＣＫメッセージを送信する（Ｓ２−７，Ｓ２−８）。これに対し，ユーザ端末４はＰＲＡＣＫメッセージに対する２００ＯＫ応答を行う（Ｓ２−９，Ｓ２−１０）。

次にユーザ端末３は，ＵＰＤＡＴＥメッセージをユーザ端末４に送信し（Ｓ２−１１，Ｓ２−１２），ユーザ端末４は，ＵＰＤＡＴＥメッセージ中のＳＤＰ（ＳＤＰ６）を参照して，ユーザ端末４の保有するＳＤＰ２の内容を同期させ，２００ＯＫ（ＵＰＤＡＴＥ）をユーザ３に送信する（Ｓ２−１３，Ｓ２−１４）。続けて，ユーザ端末４は，１８０Ringing を行う（Ｓ２−１５，Ｓ２−１６）。

ユーザ端末３は，これに対するＰＲＡＣＫメッセージを送信し（Ｓ２−１７，Ｓ２−１８），ユーザ端末４は，ＰＲＡＣＫメッセージに対する２００ＯＫを返す（Ｓ２−１９，Ｓ２−２０）。続いて，最初のＩＮＶＩＴＥメッセージに対する２００ＯＫを返し（Ｓ２−２１，Ｓ２−２２），ユーザ端末３よりＡＣＫを返す（Ｓ２−２３，Ｓ２−２４）。これにより，ネットワークリソースが確保された状態でセッションが開始される（Ｓ２−２５）。

図４は，本発明の実施の形態におけるシーケンスにおいて，トラヒック流量制御を行う場合についての図である。ＩＮＶＩＴＥメッセージのＳＤＰのリソース確保に関する記述に関して，品質予約区間及び品質予約の方向は，図２の場合と同じであるとする。トラヒック流量制御を行うリソース予約要求である識別子をＹとすると，トラヒック流量制御に関する識別の一例として，ＳＤＰ１の情報の設定による場合の一例としては図５（Ａ）で示される。本図による処理の流れは，Ｓ８−１からＳ８−２１までは，図２におけるＳ２−１からＳ２−２１までと同じである。ＳＤＰ２の設定例を図５（Ｂ）に示す。

セッション制御部１１は，Ｓ８−２１によりＩＮＶＩＴＥに対する２００ＯＫメッセージをユーザ端末４から受信すると，本セッションはトラヒック流量制御対象であることをセッション制御部１１は最初のＩＮＶＩＴＥを受信した時点から記憶しているため，リソース管理部１２に対しトラヒック流量を制御する旨の通知を行う（Ｓ８−２２）。リソース管理部１２は，これを受けて通信端末が設置された宅内において設置される装置またはエッジ装置といったトラヒック流量を制御する装置に対し，ＩＰヘッダのＴｏＳ(Type of Service) 値などの優先パケットフラグを付け替え，また，トラヒック流量制御手段を作動させるよう通知する（Ｓ８−２３）。本動作が完了した通知を受けて（Ｓ８−２４），リソース管理部１２は，セッション制御部１１に対し動作完了通知を行い（Ｓ８−２５），セッション制御部１１は，ユーザ端末３に対し２００ＯＫメッセージを転送する（Ｓ８−２６）。次いで，ユーザ端末３からのＡＣＫをユーザ端末４で受信して（Ｓ８−２７，Ｓ８−２８），これにより，ネットワークリソースが確保された状態でセッションが開始される（Ｓ８−２９）。

図６は，セッション終了時におけるシーケンス図である。セッション終了時には，どちらかのユーザ端末からのＢＹＥ要求（Ｓ４−１）などを契機に，セッション制御部１１でリソース開放をリソース管理部１２に通知し（Ｓ４−２），リソース管理部１２では，当該セッションのために予約していたリソースを開放し，トラヒック流量制御を行っていた場合には，制御対象のネットワーク装置の設定を解除し（Ｓ４−３），これらが完了した旨をセッション制御部１１に通知し（Ｓ４−４），セッション制御部１１は，ＢＹＥを転送する（Ｓ４−５）。ＢＹＥを受け取ったユーザ端末３は，ＢＹＥを送信したユーザ端末４に２００ＯＫを送信して（Ｓ４−６，Ｓ４−７），セッションを終了する。

図７及び図８に，本発明によるリソース確保型セッションのフローチャート例を示す。図７は，セッション開始時における処理フローを示す図である。ユーザ端末３からのセッション要求（Ｓ５−１）に対し，セッション制御部１１でＩＮＶＩＴＥメッセージ中のＳＤＰを確認し（Ｓ５−２），セッション確立対象ユーザであるか否か（Ｓ５−３），及びリソース確保の必要の有無，及びトラヒック流量制御の有無を判断する（Ｓ５−４）。

セッション確立対象ユーザでない場合には，ユーザ端末３にエラーメッセージを送付して（Ｓ５−２３），処理を終了する。また，セッション確立対象ユーザではあるが，リソース確保型要求でなければ，ユーザ端末４にＩＮＶＩＴＥメッセージを転送し（Ｓ５−２４），ユーザ端末４よりユーザ端末３に２００ＯＫ（ＩＮＶＩＴＥ）が送信され（Ｓ５−２５），リソース非確保型セッションが開始される（Ｓ５−２６）。

セッション確立対象ユーザであり，かつリソース確保が必要なリソース確保型要求であれば，ＩＮＶＩＴＥメッセージをユーザ端末４に転送する（Ｓ５−５）。ユーザ端末４は，転送されたＩＮＶＩＴＥメッセージに対し，ＳＤＰ確認後，１８３応答を返す（Ｓ５−６）。セッション制御部１１は，この１８３応答中のＩＰアドレスや帯域情報等のＳＤＰ情報のうちリソース判定に必要な情報をリソース管理部１２に通知し（Ｓ５−７），リソース管理部１２では，該情報をもとに帯域判定を行う（Ｓ５−８）。

帯域判定結果がＮＧで，リソース予約ができない場合には（Ｓ５−９），リソース管理部１２は，セッション制御部１１にその旨を通知し，セッション制御部１１は，エラーメッセージをユーザ端末３に返して（Ｓ５−２７）セッションは終了する。帯域判定結果がＯＫでリソース予約が可能であれば，セッション制御部１１は，１８３応答中のＳＤＰを書き換えてユーザ端末３に送信する（Ｓ５−１０）。

ユーザ端末３は，ユーザ端末４にＰＲＡＣＫメッセージを送信し，ユーザ端末４は，これに対する２００ＯＫを返す（Ｓ５−１１）。ユーザ端末３は，ＳＤＰ情報の更新をユーザ端末４に要求するＵＰＤＡＴＥメッセージを送信し，ユーザ端末４は，２００ＯＫ（ＵＰＤＡＴＥ）を返す（Ｓ５−１２）。この処理により，Preconditionが確立する。さらに，ユーザ端末４より１８０Ringing を送信する（Ｓ５−１３）。

次にユーザ端末３は，ユーザ端末４にＰＲＡＣＫメッセージを送信し，ユーザ端末４は，２００ＯＫを返す（Ｓ５−１４）。そして，ユーザ端末４は，セッション確立のために最初のＩＮＶＩＴＥメッセージに対する２００ＯＫを返し（Ｓ５−１５），これに対し，トラヒック流量制御が不要な場合には，セッション制御部１１において２００ＯＫをユーザ端末３に転送し（Ｓ５−２０），ユーザ端末３はＡＣＫをユーザ端末４に送信し，ユーザ端末４がこれを受信して（Ｓ５−２１）ネットワークリソースが確保された状態でセッションが開始さされる（Ｓ５−２２）。

トラヒック流量制御が必要な場合には（Ｓ５−１６），セッション制御部１１よりリソース管理部１２に対し，トラヒック流量制御を行う旨を通知し（Ｓ５−１７），リソース管理部１２よりトラヒック流量制御を実施する制御対象のネットワーク装置に対し制御メッセージを通知する（Ｓ５−１８）。トラヒック流量制御のための動作が完了すると，セッション制御部１１は，その旨の通知をリソース管理部１２経由で受信し（Ｓ５−１９），２００ＯＫをユーザ端末３に転送する（Ｓ５−２０）。次いで，ユーザ端末３からのＡＣＫをユーザ端末４で受信して（Ｓ５−２１），セッションが確立する（Ｓ５−２２）。これにより，ネットワークリソースが確保された状態でセッションが開始される。

図８に示す手順（Ｓ６−１〜Ｓ６−７）は，セッション終了時のフローチャート例である。本フローチャートでは，セッション終了時に，ユーザ端末４からのＢＹＥ要求（Ｓ６−１，Ｓ６−２）をセッション制御部１１で受信するなどの契機に，セッション制御部１１でリソース（帯域）開放をリソース管理部１２に要求する（Ｓ６−３）。リソース管理部１２では，当該セッションのために予約していたリソース（帯域）を開放し，トラヒック流量制御を行っていた場合には，制御対象のネットワーク装置の設定を解除し，これらが完了した旨をセッション制御部１１に通知し（Ｓ６−４），セッション制御部１１はＢＹＥをユーザ端末３に転送する（Ｓ６−５）。ユーザ端末３は，２００ＯＫをユーザ端末４に送付し（Ｓ６−６），セッションを終了する（Ｓ６−７）。

本発明の構成例を示す図である。 セッション開始時におけるシーケンス図である。 ＳＤＰ情報の設定例を示す図である。 トラヒック流量制御を行う場合のセッション開始時におけるシーケンス図である。 トラヒック流量制御を行う場合のＳＤＰ情報の設定例を示す図である。 セッション終了時におけるシーケンス図である。 セッション開始時における処理フローを示す図である。 セッション終了時における処理フローを示す図である。 従来のセッション確立方式を示す図である。

符号の説明

１ Ｑｏｓ制御システム
２ ＩＰネットワーク
３，４ ユーザ端末
１１ セッション制御部
１２ リソース管理部
１３ リソース管理ＤＢ
２０ コアネットワーク装置
２１ エッジネットワーク装置
２２ ユーザ宅内装置

Claims (6)

1. ネットワークを介して接続された通信端末間のセッション確立前にネットワークリソースを確保するＱｏＳ制御システムであって，
   前記通信端末間のセッションを制御するセッション制御手段と，
   前記ネットワーク上で，ネットワークリンク毎のネットワークリソースを一元的に管理するリソース管理手段とを備え，
   前記セッション制御手段は，
   前記通信端末のうち第１の通信端末からのセッション確立要求メッセージと，第２の通信端末からのセッション確立応答メッセージとを受信して，前記第１の通信端末及び前記第２の通信端末のアドレス情報と確保するネットワークリソース情報とを前記リソース管理手段に通知する処理手段を備え，
   前記リソース管理手段は，
   前記セッション制御手段から通知された情報に基づいてネットワークリソース予約の可否を判定して，判定結果を該セッション制御手段に通知する処理手段を備え，
   前記セッション制御手段は，更に，
   前記リソース管理手段から通知された判定結果がネットワークリソース予約可の場合には，前記第１の通信端末にネットワークリソース予約が行われた旨の通知を行い，かつ，セッションの確立を行い，前記判定結果がネットワークリソース予約不可の場合には，前記第１の通信端末にネットワークリソース予約が行われなかった旨の通知を行い，かつ，セッション確立を中断する処理手段を備える
   ことを特徴とするＱｏＳ制御システム。
2. 請求項１に記載のＱｏＳ制御システムにおいて，
   前記セッション制御手段は，
   前記受信したセッション確立要求メッセージ中の，ネットワークリソースを確保したセッションを要求するか否かを示す識別情報を識別して，セッション確立前にネットワークリソースの確保が必要なセッションが要求されたか否かを判断する処理手段と，
   ネットワークリソースの確保が必要なセッションが要求されたと判断した場合に，前記第１の通信端末及び前記第２の通信端末のアドレス情報と確保するネットワークリソース情報とを前記リソース管理手段に通知し，ネットワークリソース予約可の場合にのみセッションの確立を行い，ネットワーク予約不可の場合にはセッション確立を中断する処理手段と，
   セッション確立前のネットワークリソースの確保が不要なセッションが要求されたと判断した場合には，セッションの確立を行う処理手段とを備える
   ことを特徴とするＱｏＳ制御システム。
3. 請求項１に記載のＱｏＳ制御システムにおいて，
   前記セッション制御手段は，
   通信端末から送信される通信トラヒック流量制御の要否を識別する手段を備え，
   前記リソース管理手段は，
   前記セッション制御手段からの通知により，通信端末からの通信トラヒック流量を制御する旨を通信端末が設置された宅内において設置されるネットワーク装置またはエッジ装置に対し通知を行う手段を備え，
   前記宅内において設置されるネットワーク装置またはエッジ装置においては，前記リソース管理手段からの通知により，優先パケットフラグを付け替え，トラヒック流量制御手段を作動させることにより，前記リソース管理手段によるネットワークリソース予約と合わせて２段階でネットワークリソースを確保するようにした
   ことを特徴とするＱｏＳ制御システム。
4. ネットワークを介して接続された通信端末間のセッションを制御するセッション制御手段と，ネットワークリンク毎のネットワークリソースを一元的に管理するリソース管理手段とを備える通信システムにおけるＱｏＳ制御方法であって，
   前記セッション制御手段が，前記通信端末のうち第１の通信端末からのセッション確立要求メッセージと，第２の通信端末からのセッション確立応答メッセージとを受信して，前記第１の通信端末及び前記第２の通信端末のアドレス情報と確保するネットワークリソース情報とを前記リソース管理手段に通知するステップと，
   前記リソース管理手段が，前記セッション制御手段から通知された情報に基づいてネットワークリソース予約の可否を判定して，判定結果を該セッション制御手段に通知するステップと，
   前記セッション制御手段が，前記リソース管理手段から通知された判定結果がネットワークリソース予約可の場合には，前記第１の通信端末にネットワークリソース予約が行われた旨の通知を行い，かつ，セッションの確立を行い，前記判定結果がネットワークリソース予約不可の場合には，前記第１の通信端末にネットワークリソース予約が行われなかった旨の通知を行い，かつ，セッション確立を中断するステップとを有する
   ことを特徴とするＱｏＳ制御方法。
5. 請求項４に記載のＱｏＳ制御方法において，
   前記セッション制御手段が，前記受信したセッション確立要求メッセージ中の，ネットワークリソースを確保したセッションを要求するか否かを示す識別情報を識別して，セッション確立前にネットワークリソースの確保が必要なセッションが要求されたか否かを判断するステップと，
   前記セッション制御手段が，ネットワークリソースの確保が必要なセッションが要求されたと判断した場合に，前記第１の通信端末及び前記第２の通信端末のアドレス情報と確保するネットワークリソース情報とを前記リソース管理手段に通知し，ネットワークリソース予約可の場合にのみセッションの確立を行い，ネットワーク予約不可の場合にはセッション確立を中断するステップと，
   セッション確立前のネットワークリソースの確保が不要なセッションが要求されたと判断した場合には，セッションの確立を行うステップとを有する
   ことを特徴とするＱｏＳ制御方法。
6. 請求項４に記載のＱｏＳ制御方法において，
   前記セッション制御手段が，通信端末から送信される通信トラヒック流量制御の要否を識別するステップと，
   前記リソース管理手段が，前記セッション制御手段からの通知により，通信端末からの通信トラヒック流量を制御する旨を通信端末が設置された宅内において設置されるネットワーク装置またはエッジ装置に対し通知を行うステップと，
   前記宅内において設置されるネットワーク装置またはエッジ装置においては，前記リソース管理手段からの通知により，優先パケットフラグを付け替え，トラヒック流量制御手段を作動させることにより，前記リソース管理手段によるネットワークリソース予約と合わせて２段階でネットワークリソースを確保するステップとを有する
   ことを特徴とするＱｏＳ制御方法。

Images