JP2008022312A - ＱｏＳ制御システム - Google Patents

Abstract

【課題】通信方式に基づいてＱｏＳポリシを決定するＱｏＳ制御システムを提供する。
【解決手段】端末からアクセスネットワークを経由して、サービスを提供するコアネットワークに接続するネットワークにおける、リソースの割当を制御するＱｏＳ制御システムであって、端末が要求するサービスに対してＱｏＳポリシを決定するＱｏＳポリシ決定サーバと、アクセスネットワークとコアネットワークとを接続するアクセスゲートウェイと、を備え、ＱｏＳポリシ決定サーバは、端末がアクセスネットワークに接続する通信方式に基づいて、ＱｏＳポリシを決定する。
【選択図】図１５

Description

本発明は、複数の通信方式を収容するネットワークにおけるＱｏＳ制御システムに関する。

近年、既存の電話網をＩＰベースのネットワークに移行する動きが活発化している。ＩＰベースの電話網の実現に向けて、ＩＴＵ−Ｔ（Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎ Ｕｎｉｏｎ−Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎ Ｓｔａｎｄａｒｄｉｚａｔｉｏｎ ｓｅｃｔｏｒ）では、ＮＧＮ（Ｎｅｘｔ Ｇｅｎｅｒａｔｉｏｎ Ｎｅｔｗｏｒｋ）の標準化に取り組んでいる。ＮＧＮとは、ＩＰをベースに幅広いマルチメディアサービスを提供するためのネットワーク基盤であって、光アクセス、ＡＤＳＬ、第三世代（３Ｇ）携帯及び無線ＬＡＮなど各種の通信方式を収容し、固定網と移動網を融合することを可能とするアーキテクチャを目指している。

また、ＮＧＮでは、各種マルチメディアサービスを提供する際に、ＩＭＳ（ＩＰ Ｍｕｌｔｉｍｅｄｉａ Ｓｕｂｓｙｓｔｅｍ）によってセッションを制御する。ＩＭＳとは、ＳＩＰ（Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）をベースとした、マルチメディアサービスのセッション制御基盤である（非特許文献１参照）。ＩＭＳは、３ＧＰＰ（３ｒｄ Ｇｅｎｅｒａｔｉｏｎ Ｐａｒｔｎｅｒｓｈｉｐ Ｐｒｏｊｅｃｔ）及び３ＧＰＰ２（３ｒｄ Ｇｅｎｅｒａｔｉｏｎ Ｐａｒｔｎｅｒｓｈｉｐ Ｐｒｏｊｅｃｔ２）において標準化作業がすすめられている。

３ＧＰＰ２に規定されるＩＭＳでは、ユーザ端末（ＵＥ：Ｕｓｅｒ Ｅｑｕｉｐｍｅｎｔ）が他のＵＥとマルチメディアセッション（以下、「セッション」）を確立するとき、ＵＥが送信したＳＩＰメッセージは、ＣＳＣＦ（Ｃａｌｌ Ｓｅｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｆｕｎｃｔｉｏｎ）によって処理又は転送される（非特許文献２参照）。ＣＳＣＦとは、ＩＭＳ用に拡張されたＳＩＰサーバである。ＣＳＣＦは、Ｐ−ＣＳＣＦ（Ｐｒｏｘｙ−ＣＳＣＦ）、Ｉ−ＣＳＣＦ（Ｉｎｔｅｒｒｏｇａｔｉｎｇ−ＣＳＣＦ）及びＳ−ＣＳＣＦ（Ｓｅｒｖｉｎｇ−ＣＳＣＦ）に分類される。Ｐ−ＣＳＣＦは、ＵＥが最初にアクセスするＣＳＣＦである。Ｉ−ＣＳＣＦは、転送されたＳＩＰメッセージに対し、適切なＳ−ＣＳＣＦを選択し、ＳＩＰメッセージを転送する。Ｓ−ＣＳＣＦは、ＵＥに対するセッションを制御し、セッション状態を保持する。

さらに、３ＧＰＰ２では、マルチメディアサービスを提供する際のＱｏＳ制御のアーキテクチャも検討されている（非特許文献３参照）。このＱｏＳ制御のアーキテクチャは、ＰＣＲＦ（Ｐｏｌｉｃｙ ａｎｄ Ｃｈａｒｇｉｎｇ Ｃｏｎｔｒｏｌ Ｆｕｎｃｔｉｏｎ）とよばれる機能エンティティが規定され、ＰＣＲＦがセッションに対し、ＱｏＳポリシを決定する。ＱｏＳポリシとは、セッションが利用可能なリソース量、ＱｏＳクラス、リソース利用の許可又は不許可の決定などである。詳述すると、ＰＣＲＦは、ＡＦ（Ａｐｐｌｉｃａｔｉｏｎ Ｆｕｎｃｔｉｏｎ：ＩＭＳではＣＳＣＦが該当する）から、セッションのサービス情報（メディアタイプ、必要な帯域）を取得する。ＰＣＲＦは、サービス情報とＬＲＢＰ（Ｌｏｃａｌ Ｒｅｓｏｕｒｃｅ Ｂａｓｅｄ Ｐｏｌｉｃｙ）に基づいて、セッションに適用するＱｏＳポリシを決定する。ＬＲＢＰとは、アクセスネットワークにおいて、ＱｏＳポリシを決定するために適用される情報である。ＰＣＲＦは、ＵＥが接続するアクセスネットワークのＡＧＷ（Ａｃｃｅｓｓ ＧａｔｅＷａｙ）から、セッションに対するリソース利用の認可要求を受信すると、決定されたＱｏＳポリシに基づいて認可要求に応答する。ＡＧＷは、ＰＣＲＦからの応答に基づいて、セッションに対する適切なＱｏＳ制御を実行する。以上のアーキテクチャを適用することによって、ＩＭＳによるセッションベースのＱｏＳ制御を実行することができる。なお、このようなアーキテクチャでは、ＡＦとＰＣＲＦとの間のインターフェース及びＰＣＲＦとＡＧＷとの間のインターフェースの規定が必要となるが、それぞれ非特許文献４及び非特許文献５において議論されている。
IETF RFC3261、SIP: Session Initiation Protocol(2002/06) 3GPP2 X.S0013-002-0 v1.0(2004/02) 3GPP2 X.S0013-012-0 v1.0 Draft Version 0.18.0 3GPP2 X.S0013-013-0 v1.0 Draft Version 0.5.0 3GPP2 X.S0013-014-0 v1.0 Draft Version 0.2.0

３ＧＰＰ及び３ＧＰＰ２のＩＭＳにおけるＱｏＳ制御アーキテクチャでは、ＰＣＲＦは、ＵＥが接続するアクセスネットワークの通信方式の種別を管理していなかった。しかし、ＮＧＮでは、光アクセス、ＡＤＳＬ、第三世代（３Ｇ）携帯及び無線ＬＡＮなどの多種多様な通信方式を収容するネットワーク構成が想定されており、現行のＱｏＳ制御アーキテクチャを適用すると問題が生じるおそれがある。

例えば、現行のＱｏＳ制御アーキテクチャでは、ＵＥが低帯域無線通信方式又は広帯域無線通信方式のいずれの方式で接続している場合であっても、ＰＣＲＦは、高画質映像ストリームなどの大量のリソースを消費するサービスの利用を許可する。したがって、ＵＥが低帯域無線通信方式の基地局に接続しているときに大量のリソースを消費するサービスを利用すると、帯域を独占してしまうおそれがある。このとき、他のＵＥが同一の低帯域無線通信方式の基地局に接続しても、サービスを開始することができないおそれがある。一方、ＰＣＲＦが大量のリソースを消費するサービスの利用を禁止すると、帯域を独占することはなくなるが、ＵＥが広帯域無線通信方式で接続しているにも関わらず、サービスを利用できなくなってしまう。

したがって、ＮＧＮでは、複数の種別のアクセスネットワークを想定したＱｏＳ制御アーキテクチャが必要となる。

本発明は、ＰＣＲＦがＱｏＳポリシを決定するとき、ＵＥが接続しているアクセスネットワークの通信方式の種別に基づいて、ＱｏＳポリシを決定するＱｏＳ制御システムを提供する。また、本発明は、３ＧＰＰ／３ＧＰＰ２のいずれにおいても適用可能なＱｏＳ制御システムを提供する。

本発明の代表的な一形態では、端末からアクセスネットワークを経由して、サービスを提供するコアネットワークに接続するネットワークにおける、リソースの割当を制御するＱｏＳ制御システムであって、前記ＱｏＳ制御システムは、前記端末が要求するサービスに対してＱｏＳポリシを決定するＱｏＳポリシ決定サーバと、前記アクセスネットワークと前記コアネットワークとを接続するアクセスゲートウェイと、を備え、前記ＱｏＳポリシ決定サーバは、前記端末が前記アクセスネットワークに接続する通信方式に基づいて、前記ＱｏＳポリシを決定する。

本発明の一形態によると、前記端末と前記アクセスネットワークとを接続する通信方式に基づいて、ＱｏＳポリシを決定することができる。

以下、本発明の実施の形態を添付図面に基づいて説明する。

（第１の実施の形態）
図１は、第１の実施の形態のネットワーク構成を示す図である。第１の実施の形態では、ＵＥがＩＥＥＥ８０２．１１ａの基地局に接続し、マルチメディアサービスのセッションを構築する手順について説明する。

第１の実施の形態のネットワーク構成では、無線ＬＡＮによる接続がＷＬＡＮアクセスネットワーク５２を介して提供される。また、ＥＶ−ＤＯアクセスによる接続がＥＶ−ＤＯアクセスネットワーク５３を介して提供される。

ＷＬＡＮアクセスネットワーク５２は、ＩＥＥＥ８０２．１１ａ用アクセスポイント（以下、「ＡＰ」）５Ａと、ＩＥＥＥ８０２．１１ｂ用ＡＰ５Ｂを収容している。一方、ＥＶ−ＤＯアクセスネットワーク５３は、ＥＶ−ＤＯ用基地局（以下、「ＢＳ」）６Ａ及び６Ｂを収容している。ＷＬＡＮアクセスネットワーク５２は、ＡＧＷ３Ａを介して、コアネットワーク５１に接続する。また、ＥＶ−ＤＯアクセスネットワーク５３は、ＡＧＷ３Ｂを介して、コアネットワーク５１に接続する。

コアネットワーク５１は、ＣＳＣＦ１、ＰＣＲＦ２、及びＨＳＳ（Ｈｏｍｅ Ｓｕｂｓｃｒｉｂｅｒ Ｓｅｒｖｅｒ）８を含む。

ＣＳＣＦ１は、ＵＥ７からのＳＩＰメッセージを受信し、他のサーバに中継するＳＩＰサーバである。ＰＣＲＦ２は、提供するサービスなどに基づいて、ＱｏＳポリシを決定するポリシ決定サーバである。ＨＳＳ８は、ユーザの認証情報、課金情報及び位置情報などを管理する。

また、コアネットワーク５１と別の事業者が所有するネットワーク５５は、ＧＷ（ＧａｔｅＷａｙ）９を介して接続する。さらに、コアネットワーク５１は、ユーザに各種マルチメディアサービスを提供するためのＡＳ（Ａｐｐｌｉｃａｔｉｏｎ Ｓｅｒｖｅｒ）６１を含む。同様に、ネットワーク５５は、ＡＳ６２を含む。

ＵＥ７は、ＡＰ５Ａ又はＡＰ５Ｂを経由して、ＷＬＡＮアクセスネットワーク５２に接続する。同じく、ＵＥ７は、ＢＳ６Ａ又はＢＳ６Ｂを経由してＥＶ−ＤＯアクセスネットワーク５３に接続する。

次に、本発明の第１の実施の形態のＣＳＣＦ１の構成及び動作について説明する。

図２Ａは、第１の実施の形態のＣＳＣＦ１のハードウェア構成を示す図である。ＣＳＣＦ１は、ＣＰＵ１１、メモリ１２、ハードディスク（以下、「ＨＤＤ」）１３及びネットワークインターフェース（以下、「ＩＦ」）１４Ａ〜１４Ｎを備える。

ＣＰＵ１１は、メモリ１２に記憶されたプログラムを実行する。メモリ１２は、ＣＰＵ１１によって実行されるプログラム及び処理に必要なデータを格納する。ＨＤＤ１３は、プログラム及びデータを格納する。ＩＦ１４Ａ〜１４Ｎは、コアネットワーク５１を介して他の計算機と通信する。

図２Ｂは、第１の実施の形態のＣＳＣＦ１のメモリ１２の構成を示す図である。メモリ１２は、ＳＩＰメッセージ処理プログラム１００、セッション情報管理プログラム１２０及びセッション情報テーブル４００を格納する。

ＳＩＰメッセージ処理プログラム１００及びセッション情報管理プログラム１２０は、ＣＰＵ１１によって実行される。ＳＩＰメッセージ処理プログラム１００は、受信したＳＩＰメッセージに応じた処理を実行する。セッション情報管理プログラム１２０は、セッション情報テーブル４００の情報を更新し、ＰＣＲＦにＵＥが要求したサービス情報を通知する。セッション情報テーブル４００は、ＣＳＣＦ１が管理するＳＩＰのセッション情報を格納する。

図５は、第１の実施の形態のセッション情報テーブル４００の構成を示す図である。セッション情報テーブル４００は、セッション情報管理プログラム１２０が、図１０に後述するサービス情報通知パケットを生成するために参照される。ＣＳＣＦ１は、新しいＳＩＰセッションが確立されるたびに、セッション情報テーブル４００にエントリを追加する。

セッション情報テーブル４００は、ＳＩＰセッション識別情報４０１、Ａｃｃｅｓｓ Ｎｅｔｗｏｒｋ Ｉｎｆｏフィールド４０２、Ｕｐｌｉｎｋ ＳＤＰ情報フィールド４０３及びＤｏｗｎｌｉｎｋ ＳＤＰ情報フィールド４０４を含む。

ＳＩＰセッション識別情報４０１は、ＣＳＣＦ１が管理するＳＩＰのセッションを特定する識別子である。ＳＩＰセッション識別情報４０１は、Ｃａｌｌ−ＩＤフィールド４０１Ａ、Ｔｏ Ｔａｇフィールド４０１Ｂ及びＦｒｏｍ Ｔａｇフィールド４０１Ｃを含む。Ｃａｌｌ−ＩＤフィールド４０１Ａは、クライアントを一意に識別する識別子を格納する。Ｔｏ Ｔａｇフィールド４０１Ｂは、受信者を識別するタグを格納する。Ｆｒｏｍ Ｔａｇフィールド４０１Ｃには、送信者を識別するタグを格納する。

Ａｃｃｅｓｓ Ｎｅｔｗｏｒｋ Ｉｎｆｏフィールド４０２は、ＵＥ７が現在接続しているネットワークの通信方式の種別を格納する。

Ｕｐｌｉｎｋ ＳＤＰ情報フィールド４０３は、Ｕｐｌｉｎｋ（ＵＥ７→ＡＧＷ３Ａ方向）のフローのＳＤＰ（Ｓｅｓｓｉｏｎ Ｄｅｓｃｒｉｐｔｉｏｎ Ｐｒｏｔｏｃｏｌ）情報である。ＳＤＰとは、接続時間及びエンコードのタイプなどのマルチメディアセッション情報を記述するためのテキスト形式の書式を規定するプロトコルである。Ｕｐｌｉｎｋ ＳＤＰ情報フィールド４０３は、ｃ−ｌｉｎｅフィールド４０３Ａ、ｍ−ｌｉｎｅフィールド４０３Ｂ、ａ−ｌｉｎｅフィールド４０３Ｃ及びｂ−ｌｉｎｅフィールド４０３Ｄを含む。ｃ−ｌｉｎｅフィールド４０３Ａは、接続情報を格納する。ｍ−ｌｉｎｅフィールド４０３Ｂは、メディア情報を格納する。ａ−ｌｉｎｅフィールド４０３Ｃは、属性情報を格納する。ｂ−ｌｉｎｅフィールド４０３Ｄは、帯域情報を格納する。

Ｄｏｗｎｌｉｎｋ ＳＤＰ情報フィールド４０４は、Ｄｏｗｎｌｉｎｋ（ＵＥ７←ＡＧＷ３Ａ方向）のフローのＳＤＰ情報である。Ｄｏｗｎｌｉｎｋ ＳＤＰ情報フィールド４０４は、ｃ−ｌｉｎｅフィールド４０４Ａ、ｍ−ｌｉｎｅフィールド４０４Ｂ、ａ−ｌｉｎｅフィールド４０４Ｃ及びｂ−ｌｉｎｅフィールド４０４Ｄを含む。ｃ−ｌｉｎｅフィールド４０４Ａは、接続情報を格納する。ｍ−ｌｉｎｅフィールド４０４Ｂは、メディア情報を格納する。ａ−ｌｉｎｅフィールド４０４Ｃは、属性情報を格納する。ｂ−ｌｉｎｅフィールド４０４Ｄは、帯域情報を格納する。

図８は、第１の実施の形態のＳＩＰ ＩＮＶＩＴＥメッセージ７００のパケットフォーマットである。ＳＩＰ ＩＮＶＩＴＥメッセージ７００のパケットは、マルチメディアセッションを開始するとき、ＵＥ７からＣＳＣＦ１に送信される。ＣＳＣＦ１は、受信したパケットを相手側の端末に転送する。

ＳＩＰ ＩＮＶＩＴＥメッセージ７００は、相手側の端末と接続するために送信されるメッセージである。ＳＩＰ ＩＮＶＩＴＥメッセージ７００には、ＳＤＰが含まれる。セッション情報テーブル４００にエントリを追加するために必要となる情報は、Ｐ−Ａｃｃｅｓｓ−Ｎｅｔｗｏｒｋ−Ｉｎｆｏヘッダ７０９、ＳＤＰに含まれるｃ−ｌｉｎｅ７０２、ｍ−ｌｉｎｅ７０３、ｂ−ｌｉｎｅ７０４及びａ−ｌｉｎｅのメディアフローの方向を示す情報７０５である。

Ｐ−Ａｃｃｅｓｓ−Ｎｅｔｗｏｒｋ−Ｉｎｆｏヘッダ７０９は、アクセスネットワークにＵＥ７が接続する形態を格納する。第１の実施の形態では、図８に示すように、Ｐ−Ａｃｃｅｓｓ−Ｎｅｔｗｏｒｋ−Ｉｎｆｏヘッダ７０９には、「ＩＥＥＥ８０２．１１ａ」が格納されている。接続形態に応じて、例えば、「ＦＴＴＨ」、「ＢｌｕｅＴｏｏｔｈ」又は「ＷｉＦｉ（無線ＬＡＮ）」などの値が格納される。

図９は、第１の実施の形態のＳＩＰ １８３応答メッセージ７１０のパケットフォーマットである。ＳＩＰ １８３応答メッセージ７１０は、相手側の端末が送信するＳＩＰ ＩＮＶＩＴＥメッセージ７００に対する応答メッセージである。ＳＩＰ １８３応答メッセージ７１０のパケットは、相手先の端末から送信され、ＣＳＣＦ１によってＵＥ７に転送される。ＳＩＰ １８３応答メッセージ７１０には、ＳＤＰが含まれる。セッション情報テーブル４００にエントリを追加するために必要となる情報は、ＳＤＰに含まれるｃ−ｌｉｎｅ７１２、ｍ−ｌｉｎｅ７１３、ｂ−ｌｉｎｅ７１４及びａ−ｌｉｎｅのメディアフローの方向を示す情報７１５である。

図１０は、第１の実施の形態のサービス情報通知パケットの構成を示す図である。７２０は、サービス情報通知パケットのフォーマットを示し、７２０Ａは、サービス情報通知パケットに格納されるデータの一例を示す。サービス情報通知パケットは、ＣＳＣＦ１で新たに構築されるマルチメディアサービスの情報をＣＳＣＦ１がＰＣＲＦ２に通知するために用いられる。第１の実施の形態では、ＣＳＣＦ１とＰＣＲＦ１との間で、Ｄｉａｍｅｔｅｒプロトコルによってパケットを交換する。

サービス情報通知パケットは、Ｄｉａｍｅｔｅｒヘッダ７２１及びＳｅｓｓｉｏｎ ＩＤフィールド７２２を含み、Ｄｉａｍｅｔｅｒセッションの管理などに使用される。Ｓｕｂｓｃｒｉｐｔｉｏｎ−ＩＤフィールド７２３は、ＵＥ７のユーザ情報を示すＳＩＰ ＵＲＩなどを格納する。Ａｃｃｅｓｓ−Ｎｅｔｗｏｒｋ−Ｉｎｆｏフィールド７２４は、ＵＥ７が接続しているアクセスネットワークの通信方式の種別を格納する。

フィールド７２５〜７３７は、メディア情報を示す部分（メディア部）である。なお、１つのサービス情報通知パケットに複数のメディア部が含まれてもよい。Ｍｅｄｉａ−Ｔｙｐｅフィールド７２５は、メディアタイプの種別を格納する。Ｆｌｏｗ−Ｓｔａｔｕｓフィールド７２６は、フローの状態を格納する。フィールド７２７〜７３０は、利用するマルチメディアサービスに必要な帯域情報を格納する。

Ｍａｘ−Ｒｅｑｕｅｓｔｅｄ−ＢＷ−ＵＬフィールド７２７及びＭａｘ−Ｒｅｑｕｅｓｔｅｄ−ＢＷ−ＤＬフィールド７２８は、それぞれＵｐｌｉｎｋとＤｏｗｎｌｉｎｋの要求帯域量に関する情報を格納する。ＲＳ−Ｂａｎｄｗｉｄｔｈフィールド７２９及びＲＲ−Ｂａｎｄｗｉｄｔｈフィールド７３０は、ＲＴＣＰを利用するときに使用される。

フィールド７３１〜７３７は、サブメディア情報を示す部分（サブメディア部）である。なお、１つのメディア部に複数のサブメディア部を含んでもよい。Ｆｌｏｗ−Ｕｓａｇｅフィールド７３１は、フローがＲＴＣＰフローか否かを示す値を格納する。

フィールド７３２〜７３７は、フロー情報を示す部分（フロー部）であり、１つのサブメディア部に複数のフロー部を含んでもよい。フロー部は、Ｄｉｒｅｃｔｉｏｎフィールド７３２、ＳＲＣアドレスフィールド７３３、ＤＳＴアドレスフィールド７３４、ＳＲＣポート番号フィールド７３５、ＤＳＴポート番号フィールド７３６及びプロトコルフィールド７３７を含む。

Ｄｉｒｅｃｔｉｏｎフィールド７３２は、フローの方向を格納する。ＳＲＣアドレスフィールド７３３は、送信元ＩＰアドレスを格納する。ＤＳＴアドレスフィールド７３４は、宛先ＩＰアドレスを格納する。ＳＲＣポート番号フィールド７３５は、送信元ポート番号を格納する。ＤＳＴポート番号フィールド７３６は、宛先ポート番号を格納する。プロトコルフィールド７３７は、プロトコル番号又はプロトコル名を格納する。

図１２Ａは、第１の実施の形態のＳＩＰメッセージ処理プログラム１００の処理手順を示すフローチャートである。ＳＩＰメッセージ処理プログラム１００は、ＵＥ７からＳＩＰメッセージを受信するたびに起動される。

ＣＳＣＦ１は、受信したＳＩＰメッセージに応じて処理を実行する（１０１）。具体的には、ＳＩＰメッセージに含まれるリクエストに従って、受信したＳＩＰメッセージの転送又はセッション情報の更新などを実行する。

続いて、ＣＳＣＦ１は、受信したＳＩＰメッセージにＳＤＰが含まれるか否かを判定する（１０２）。ＳＤＰは、発信者からのＩＮＶＩＴＥリクエストメッセージ又はＩＮＶＩＴＥに対する応答メッセージ（図９参照）に含まれている。したがって、ＣＳＣＦ１は、受信したＳＩＰメッセージがＩＮＶＩＴＥリクエストメッセージ又はＩＮＶＩＴＥリクエストメッセージの応答であるとき（１０２の結果が「ＹＥＳ」）、セッション情報管理プログラム１２０を起動する（１０３）。ＳＩＰメッセージ処理プログラム１００は、その後、終了する。

図１２Ｂは、第１の実施の形態のセッション情報管理プログラム１２０の処理手順を示すフローチャートである。セッション情報管理プログラム１２０は、ＣＳＣＦ１によって実行される。

ＣＳＣＦ１は、まず、セッション情報テーブル４００を参照する（１２１）。次に、ＣＳＣＦ１は、受信したＳＩＰメッセージに該当するセッションのエントリが存在するか否かを、ＳＩＰセッション識別情報４０１に基づいて判定する（１２２）。

ＣＳＣＦ１は、セッション情報テーブル４００に該当するセッションが存在しない場合には（１２２の結果が「ＮＯ」）、新たにエントリを追加し（１２３）、追加したエントリのＳＩＰセッション識別情報４０１を更新する（１２４）。一方、セッション情報テーブル４００に該当するセッションが存在する場合には（１２２の結果が「ＹＥＳ」）、該当エントリを参照する（１２５）。

ＣＳＣＦ１は、次に、ＳＩＰメッセージの方向がＵｐｌｉｎｋかＤｏｗｎｌｉｎｋかを判定する（１２６）。ＳＩＰメッセージの方向がＵｐｌｉｎｋの場合には（１２６の結果が「ＹＥＳ」）、セッション情報テーブル４００のＡｃｃｅｓｓ Ｎｅｔｗｏｒｋ Ｉｎｆｏフィールド４０２に、ＳＩＰメッセージ７００のＰ−Ａｃｃｅｓｓ−Ｎｅｔｗｏｒｋ−Ｉｎｆｏヘッダ７０９の値を格納する（１２７）。なお、Ａｃｃｅｓｓ Ｎｅｔｗｏｒｋ Ｉｎｆｏフィールド４０２に格納する値は、Ｐ−Ａｃｃｅｓｓ−Ｎｅｔｗｏｒｋ−Ｉｎｆｏヘッダ７０９に基づいて、接続するネットワークのレイヤ、例えば、物理層又はデータリンク層に応じて値を定めてもよい。さらに、ＣＳＣＦ１は、ＳＩＰメッセージ７００のＳＤＰ情報を、セッション情報テーブル４００のＵｐｌｉｎｋ ＳＤＰ情報フィールド４０３に格納する（１２８）。具体的には、図８のＳＩＰメッセージに含まれる７０２、７０３、７０４及び７０５の値を、図５のセッション情報テーブル４００の対応するフィールド４０３Ａ、４０３Ｂ、４０３Ｄ及び４０３Ｃにそれぞれ格納する。

一方、ＣＳＣＦ１は、ＳＩＰメッセージの方向がＤｏｗｎｌｉｎｋの場合には（１２６の結果が「ＮＯ」）、ＳＩＰメッセージに含まれるＳＤＰ情報を、セッション情報テーブル４００のＤｏｗｎｌｉｎｋ ＳＤＰ情報フィールド４０４に格納する（１２９）。具体的には、図９のＳＩＰメッセージ７１０に含まれる７１２、７１３、７１４及び７１５の値を、図５のセッション情報テーブル４００の対応する４０４Ａ、４０４Ｂ、４０４Ｄ及び４０４Ｃにそれぞれ格納する。

その後、ＣＳＣＦ１は、セッションに対応するエントリのＵｐｌｉｎｋ ＳＤＰ情報フィールド４０３及びＤｏｗｎｌｉｎｋ ＳＤＰ情報フィールド４０４がともに設定されているか否かを判定する（１３０）。フィールド４０３及び４０４は、ＵＥ７から送信されたＳＩＰ ＩＮＶＩＴＥメッセージを相手側のＵＥが受信し、相手側のＵＥが応答するＳＩＰメッセージを送信したときにともに設定される。ＣＳＣＦ１は、フィールド４０３及び４０４の一方のみが設定されている場合には（１３０の結果が「ＮＯ」）、処理を終了する。

ＣＳＣＦ１は、セッションに対応するエントリのＵｐｌｉｎｋ ＳＤＰ情報フィールド４０３及びＤｏｗｎｌｉｎｋ ＳＤＰ情報フィールド４０４に値がともに設定されると（１３０の結果が「ＹＥＳ」）、情報通知パケット７２０を生成する（１３１）。

サービス情報通知パケット７２０は、セッション情報テーブル４００に格納された情報に基づいて生成される。具体的には、サービス情報通知パケット７２０のＡｃｃｅｓｓ−Ｎｅｔｗｏｒｋ−Ｉｎｆｏフィールド７２４には、セッション情報テーブル４００のＡｃｃｅｓｓ Ｎｅｔｗｏｒｋ Ｉｎｆｏフィールド４０２の値を格納する。Ｍｅｄｉａ−Ｔｙｐｅフィールド７２５に格納する値は、ｍ−ｌｉｎｅフィールド４０３Ｂ及び４０４Ｂに格納された値に基づいて生成する。Ｆｌｏｗ−Ｓｔａｔｕｓフィールド７２６に格納する値は、ａ−ｌｉｎｅフィールド４０３Ｃ及び４０４Ｃに格納された値に基づいて生成する。

帯域情報を格納するフィールド７２７〜７３０の値は、ｂ−ｌｉｎｅフィールド４０３Ｄ及び４０４Ｄに格納された値に基づいて生成する。なお、Ｆｌｏｗ−Ｕｓａｇｅフィールド７３１は、サブメディアがＲＴＣＰでなければ不要である。

Ｄｉｒｅｃｔｉｏｎフィールド７３２に格納する値は、ａ−ｌｉｎｅフィールド４０３Ｃ及び４０４Ｃに格納された値に基づいて生成する。ＳＲＣアドレスフィールド７３３に格納する値は、ｃ−ｌｉｎｅフィールド４０３Ａに格納された値に基づいて生成する。ＤＳＴアドレスフィールド７３４に格納する値は、ｃ−ｌｉｎｅフィールド４０４Ａに格納された値に基づいて生成する。ＳＲＣポート番号フィールド７３５に格納する値は、ｍ−ｌｉｎｅフィールド４０３Ｂに格納された値に基づいて生成する。ＤＳＴポート番号フィールド７３６に格納する値は、ｍ−ｌｉｎｅフィールド４０４Ｂに格納された値に基づいて生成する。プロトコルフィールド７３７に格納する値は、ｍ−ｌｉｎｅフィールド４０３Ｂ及び４０４Ｂに格納された値に基づいて生成する。ＣＳＣＦ１は、サービス情報通知パケット７２０を生成すると、ＰＣＲＦ１に送信する（１３１）。

その後、ＣＳＣＦ１は、サービス情報通知パケット７２０の応答であるサービス情報応答パケットを受信する（１３２）。ＣＳＣＦ１は、サービス情報応答パケットが正常応答か否かを判定する（１３３）。ＣＳＣＦ１は、サービス情報応答パケットが正常応答であれば（１３３の結果が「ＹＥＳ」）、セッション情報管理プログラム１２０を終了する。サービス情報応答パケットが正常応答でなければ（１３３の結果が「Ｎｏ」）、エラー処理の実行後（１３４）、セッション情報管理プログラム１２０を終了する。

続いて、第１の実施の形態のＰＣＲＦ２の構成及び処理について説明する。

図３Ａは、第１の実施の形態のＰＣＲＦ２のハードウェア構成を示す図である。ＰＣＲＦ２は、ＣＰＵ２１、メモリ２２、ＨＤＤ２３及びＩＦ２４Ａ〜２４Ｎを備える。

ＣＰＵ２１は、メモリ２２に記憶されたプログラムを実行する。メモリ２２は、ＣＰＵ２１によって実行されるプログラム及び処理に必要なデータを格納する。ＨＤＤ２３は、プログラム及データを格納する。ＩＦ２４Ａ〜２４Ｎは、コアネットワーク５１を介して他の計算機と通信する。

図３Ｂは、第１の実施の形態のＰＣＲＦ２のメモリ２２の構成を示す図である。メモリ２２は、サービス情報管理プログラム２００、ＱｏＳポリシ決定プログラム２２０、サービス情報テーブル５００及び通信方式ＱｏＳ情報テーブル５５０を格納する。

サービス情報管理プログラム２００及びＱｏＳポリシ決定プログラム２２０は、ＣＰＵ２１によって実行される。サービス情報管理プログラム２００は、ＣＳＣＦ１から送信されたサービス情報通知パケット７２０に基づいてサービス情報テーブル５００にエントリを追加する。ＱｏＳポリシ決定プログラム２２０は、サービス情報テーブル５００を参照して、ＱｏＳポリシを決定する。

サービス情報テーブル５００は、ＣＳＣＦ１によって送信されたサービス情報通知パケット７２０の内容を格納する。通信方式ＱｏＳ情報テーブル５５０は、ＱｏＳポリシ決定プログラム２２０によってＱｏＳポリシを決定する際に参照される。

図６Ａは、第１の実施の形態のサービス情報テーブル５００の構成を示す図である。サービス情報テーブル５００は、Ｄｉａｍｅｔｅｒ Ｓｅｓｓｉｏｎ ＩＤフィールド５０１、Ｒａｄｉｕｓ Ｓｅｓｓｉｏｎ ＩＤフィールド５０２、Ｓｕｂｓｃｒｉｐｔｉｏｎ−ＩＤフィールド５０３、Ａｃｃｅｓｓ−Ｎｅｔｗｏｒｋ−Ｉｎｆｏフィールド５０４、Ｍｅｄｉａ−Ｔｙｐｅフィールド５０５及びＦｌｏｗ−Ｓｔａｔｕｓフィールド５０６を含む。サービス情報テーブル５００は、さらに、帯域情報を格納するフィールド５０７〜５１０、Ｆｌｏｗ−Ｕｓａｇｅフィールド５１１及びフロー情報を格納するフィールド５１２を含む。

Ｄｉａｍｅｔｅｒ Ｓｅｓｓｉｏｎ ＩＤフィールド５０１は、ＣＳＣＦ１とＰＣＲＦ２との間でサービス情報通知パケット７２０を交換するセッションの識別子を格納する。Ｒａｄｉｕｓ Ｓｅｓｓｉｏｎ ＩＤフィールド５０２は、ＰＣＲＦ２とＡＧＷ３Ａとの間で図１１Ａにて後述するリソース認可要求パケット７４０及び図１１Ｂにて後述するリソース認可応答パケットを交換するセッションの識別子である。Ｓｕｂｓｃｒｉｐｔｉｏｎ−ＩＤフィールド５０３は、ＵＥ７のユーザ情報を示すＳＩＰ ＵＲＩなどを格納する。Ａｃｃｅｓｓ−Ｎｅｔｗｏｒｋ−Ｉｎｆｏフィールド５０４は、ＵＥ７が接続しているアクセスネットワークの通信方式の種別を格納する。Ｍｅｄｉａ−Ｔｙｐｅフィールド５０５は、メディアタイプの種別を格納する。Ｆｌｏｗ−Ｓｔａｔｕｓフィールド５０６は、フローの状態を格納する。

必要な帯域情報を格納するフィールド５０７〜５１０は、Ｍａｘ−Ｒｅｑｕｅｓｔｅｄ−ＢＷ−ＵＬフィールド５０７、Ｍａｘ−Ｒｅｑｕｅｓｔｅｄ−ＢＷ−ＤＬフィールド５０８、ＲＳ−Ｂａｎｄｗｉｄｔｈフィールド５０９及びＲＲ−Ｂａｎｄｗｉｄｔｈフィールド５１０を含む。Ｍａｘ−Ｒｅｑｕｅｓｔｅｄ−ＢＷ−ＵＬフィールド５０７及びＭａｘ−Ｒｅｑｕｅｓｔｅｄ−ＢＷ−ＤＬフィールド５０８は、それぞれＵｐｌｉｎｋとＤｏｗｎｌｉｎｋの要求帯域量に関する情報を格納する。ＲＳ−Ｂａｎｄｗｉｄｔｈフィールド５０９及びＲＲ−Ｂａｎｄｗｉｄｔｈフィールド５１０は、ＲＴＣＰを利用するときに使用される。

Ｆｌｏｗ−Ｕｓａｇｅフィールド５１１は、フローがＲＴＣＰフローであるか否かを示す値を格納する。フロー情報フィールド５１２は、具体的には、Ｄｉｒｅｃｔｉｏｎフィールド５１２Ａ、ＳＲＣアドレスフィールド５１２Ｂ、ＤＳＴアドレスフィールド５１２Ｃ、ＳＲＣポート番号フィールド５１２Ｄ、ＤＳＴポート番号フィールド５１２Ｅ及びプロトコルフィールド５１２Ｆを含む。

Ｄｉｒｅｃｔｉｏｎフィールド５１２Ａは、フローの方向を格納する。ＳＲＣアドレスフィールド５１２Ｂは、送信元ＩＰアドレスを格納する。ＤＳＴアドレスフィールド５１２Ｃは、宛先ＩＰアドレスを格納する。ＳＲＣポート番号フィールド５１２Ｄは、送信元ポート番号を格納する。ＤＳＴポート番号フィールド５１２Ｅは、宛先ポート番号を格納する。プロトコルフィールド５１２Ｆは、フローのプロトコル名を格納する。

図６Ｂは、第１の実施の形態の通信方式ＱｏＳ情報テーブル５５０の構成を示す図である。通信方式ＱｏＳ情報テーブル５５０は、アクセスネットワークを提供する事業者によって、予め設定される。通信方式ＱｏＳ情報テーブル５５０は、ＬＲＢＰの一部として設定されてもよい。

通信方式ＱｏＳ情報テーブル５５０は、Ａｃｃｅｓｓ−Ｎｅｔｗｏｒｋ−Ｉｎｆｏフィールド５５１、Ｍｅｄｉａ−Ｔｙｐｅフィールド５５２、ＵＬ＿ＢＷフィールド５５３及びＤＬ＿ＢＷフィールド５５４を含む。

Ａｃｃｅｓｓ−Ｎｅｔｗｏｒｋ−Ｉｎｆｏフィールド５５１は、対象となるアクセスネットワークの種別を格納する。Ｍｅｄｉａ−Ｔｙｐｅフィールド５５２は、対象となるメディアタイプの種別を格納する。ＵＬ＿ＢＷフィールド５５３は、Ｕｐｌｉｎｋのフローに対して利用が許可される帯域量の上限を格納する。ＤＬ＿ＢＷフィールド５５４は、Ｄｏｗｎｌｉｎｋのフローに対して利用が許可される帯域量の上限を格納する。

また、第１の実施の形態では、通信方式ＱｏＳ情報テーブル５５０には、３ＧＰＰ２−１Ｘ−ＨＲＰＤ（ＥＶ−ＤＯ）用のエントリ５５０Ａ、ＩＥＥＥ８０２．１１ａ用のエントリ５５０Ｂ及びＩＥＥＥ８０２．１１ｂ用のエントリ５５０Ｃが設定されている。例えば、ＵＥ７がＥＶ−ＤＯをアクセスの通信方式として利用するとき、ストリーミングサービスに対し、最大Ｕｐｌｉｎｋに３００ｋｂｐｓ、Ｄｏｗｎｌｉｎｋに６００ｋｂｐｓの帯域が確保される。

図１１Ａは、第１の実施の形態のリソース認可要求パケット７４０のフォーマットを示す図である。リソース認可要求パケット７４０は、ＵＥ７が新たに開始しようとするマルチメディアサービスに対し、ＡＧＷ３Ａ又はＡＧＷ３ＢがＰＣＲＦ２にリソース利用の認可を要求するためのパケットである。なお、第１の実施の形態では、ＡＧＷ３ＡとＰＣＲＦ２との間でＲａｄｉｕｓプロトコルを用いてリソース認可要求パケット７４０を交換する。

リソース認可要求パケット７４０は、Ｕｓｅｒ−Ｎａｍｅフィールド７４１、フロー情報を示すフィールド７４２〜７４８（フロー部）及びＲｅｑｕｅｓｔｅｄ ＱｏＳ情報フィールド７４９を含む。

Ｕｓｅｒ−Ｎａｍｅフィールド７４１は、ＵＥ７のユーザ情報を示すＮＡＩ（Ｎｅｔｗｏｒｋ Ａｃｃｅｓｓ Ｉｄｅｎｔｉｆｉｅｒ）を格納する。

フロー部を構成するフィールド７４２〜７４８は、１つのリソース認可要求パケット７４０に複数のフロー部を含む場合がある。フロー部は、フローＩＤフィールド７４２、Ｄｉｒｅｃｔｉｏｎフィールド７４３、ＳＲＣアドレスフィールド７４４、ＤＳＴアドレスフィールド７４５、ＳＲＣポート番号フィールド７４６、ＤＳＴポート番号フィールド７４７及びプロトコルフィールド７４８を含む。

フローＩＤフィールド７４２は、フローを識別するための識別子を格納する。Ｄｉｒｅｃｔｉｏｎフィールド７４３は、フローの方向を格納する。ＳＲＣアドレスフィールド７４４は、送信元ＩＰアドレスを格納する。ＤＳＴアドレスフィールド７４５は、宛先ＩＰアドレスを格納する。ＳＲＣポート番号フィールド７４６は、送信元ポート番号を格納する。ＤＳＴポート番号フィールド７４７は、宛先ポート番号を格納する。プロトコルフィールド７４８は、通信に用いられるプロトコルの名前又は番号を格納する。

Ｒｅｑｕｅｓｔｅｄ ＱｏＳ情報フィールド７４９は、ＡＧＷ３ＡがＰＣＲＦ２にマルチメディアセッションを開始するために必要となるＱｏＳ情報を通知する際に用いられる。なお、Ｒｅｑｕｅｓｔｅｄ ＱｏＳ情報フィールド７４９はオプションであり、リソース認可要求パケット７４０にＲｅｑｕｅｓｔｅｄ ＱｏＳ情報フィールド７４９を含まない場合もある。

図１１Ｂは、第１の実施の形態のリソース認可応答パケット及びリソース認可拒絶パケットのフォーマット７５０を示す図である。リソース認可応答パケットは、リソース認可要求パケット７４０の応答として、ＰＣＲＦ２がＡＧＷ３Ａ又はＡＧＷ３Ｂに送信するパケットである。リソース認可応答パケットは、ＵＥ７が新たに開始しようとしているマルチメディアサービスに対して割当可能なリソース情報を通知するためのパケットである。一方、リソース認可拒絶パケットは、ＵＥ７が新たに開始しようとしているマルチメディアサービスに対して、リソースの割当を拒絶することを、ＰＣＲＦ２がＡＧＷ３Ａ又はＡＧＷ３Ｂに通知するためのパケットである。

リソース認可要求パケット７４０は、Ｕｓｅｒ−Ｎａｍｅフィールド７５１、Ｒｅｊｅｃｔ？フィールド７５２及びＱｏＳ情報を示すフィールド７５３〜７５６（ＱｏＳ情報部）を含む。

Ｕｓｅｒ−Ｎａｍｅフィールド７５１には、ＵＥ７のユーザ情報を示すＮＡＩなどを格納する。

Ｒｅｊｅｃｔ？フィールド７５２は、リソース認可拒否パケット７５０にのみ含まれる。すなわち、リソース認可応答パケット及びリソース認可拒絶パケットの区別は、Ｒｅｊｅｃｔ？フィールド７５２の有無によって判定される。

ＱｏＳ情報部は、Ｆｌｏｗ＿ＩＤフィールド７５３、ＭａｘＤＲ＿ＵＬフィールド７５４、ＭａｘＤＲ＿ＤＬフィールド７５５及びＭａｘ＿ＱｏＳ＿Ｃｌａｓｓフィールド７５６を含む。ＱｏＳ情報部は、１つのリソース認可応答パケットに複数含まれる場合がある。

なお、リソース認可拒絶パケットは、Ｒｅｊｅｃｔ？フィールド７５２を含むことを除いて、リソース認可応答パケットと同一である。リソース認可拒絶パケットは、必ずしもＱｏＳ情報部を含む必要はない。

Ｆｌｏｗ＿ＩＤフィールド７５３は、フローを識別するための識別子を格納する。ＭａｘＤＲ＿ＵＬフィールド７５４は、フローのＵｐｌｉｎｋに対して認可されたデータレートの値を格納する。ＭａｘＤＲ＿ＤＬフィールド７５５には、フローのＤｏｗｎｌｉｎｋに対して認可されたデータレートの値を格納する。Ｍａｘ＿ＱｏＳ＿Ｃｌａｓｓフィールド７５６は、フローに対して認可されたＱｏＳクラスを格納する。

図１３Ａは、第１の実施の形態のサービス情報管理プログラム２００の処理手順を示すフローチャートである。サービス情報管理プログラム２００は、サービス情報通知パケット７２０を受信したときに、ＰＣＲＦ２によって実行される。

ＰＣＲＦ２は、受信したサービス情報通知パケット７２０に基づいて、サービス情報テーブル５００に新規エントリを追加し、Ｒａｄｉｕｓ Ｓｅｓｓｉｏｎ ＩＤフィールド５０２を除くフィールドを更新する（２０１）。

具体的には、サービス情報テーブル５００のＤｉａｍｅｔｅｒ Ｓｅｓｓｉｏｎ ＩＤフィールド５０１には、サービス情報通知パケット７２０のＳｅｓｓｉｏｎ ＩＤフィールド７２２の値を格納する。同様に、Ｓｕｂｓｃｒｉｐｔｉｏｎ−ＩＤフィールド５０３には、Ｓｕｂｓｃｒｉｐｔｉｏｎ−ＩＤフィールド７２３の値を格納する。Ａｃｃｅｓｓ−Ｎｅｔｗｏｒｋ−Ｉｎｆｏフィールド５０４には、Ａｃｃｅｓｓ−Ｎｅｔｗｏｒｋ−Ｉｎｆｏフィールド７２４の値を格納する。Ｍｅｄｉａ−Ｔｙｐｅフィールド５０５には、Ｍｅｄｉａ−Ｔｙｐｅフィールド７２５の値を格納する。Ｆｌｏｗ−Ｓｔａｔｕｓフィールド５０６には、Ｆｌｏｗ−Ｓｔａｔｕｓフィールド７２６の値を格納する。Ｍａｘ−Ｒｅｑｕｅｓｔｅｄ−ＢＷ−ＵＬフィールド５０７には、Ｍａｘ−Ｒｅｑｕｅｓｔｅｄ−ＢＷ−ＵＬフィールド７２７の値を格納する。Ｍａｘ−Ｒｅｑｕｅｓｔｅｄ−ＢＷ−ＤＬフィールド５０８には、Ｍａｘ−Ｒｅｑｕｅｓｔｅｄ−ＢＷ−ＤＬフィールド７２８の値を格納する。ＲＳ−ＢＷフィールド５０９には、ＲＳ−Ｂａｎｄｗｉｄｔｈフィールド７２９の値を格納する。ＲＲ−ＢＷフィールド５１０には、ＲＲ−Ｂａｎｄｗｉｄｔｈフィールド７３０の値を格納する。Ｆｌｏｗ−Ｕｓａｇｅフィールド５１１には、Ｆｌｏｗ−Ｕｓａｇｅフィールド７３１の値を格納する。フロー情報フィールド５１２（５１２Ａ〜５１２Ｆ）には、サービス情報通知パケット７２０のフロー部（７３２〜７３７）の値を格納する。

その後、ＰＣＲＦ２は、サービス情報通知パケット７２０に対する応答として、サービス情報応答パケット７４０をＣＳＣＦ１に送信し（２０２）、処理を終了する。

図１３Ｂは、第１の実施の形態のＱｏＳポリシ決定プログラム２２０の処理手順を示すフローチャートである。ＱｏＳポリシ決定プログラム２２０は、リソース認可要求パケット７４０を受信したときに、ＰＣＲＦ２によって実行される。

ＰＣＲＦ２は、リソース認可要求パケット７４０を受信すると、まず、サービス情報テーブル５００を参照する。そして、Ｓｕｂｓｃｒｉｐｔｉｏｎ−ＩＤフィールド５０３又はリソース認可要求パケット７４０のＵｓｅｒ−Ｎａｍｅフィールド７４１のユーザ情報、及びフロー情報５１２又はリソース認可要求パケット７４０のフロー部の情報に基づいて、該当するエントリを検索する（２２１）。

次に、ＰＣＲＦ２は、Ｒａｄｉｕｓ Ｓｅｓｓｉｏｎ ＩＤフィールド５０２を更新する（２２２）。さらに、ＰＣＲＦ２は、Ａｃｃｅｓｓ−Ｎｅｔｗｏｒｋ−Ｉｎｆｏフィールド５０４の値に基づいて、通信方式ＱｏＳ情報テーブル５５０からセッションに対応するエントリを取得する（２２３）。

ＰＣＲＦ２は、取得した通信方式ＱｏＳ情報テーブル５５０のエントリに基づいて、Ｍｅｄｉａ−Ｔｙｐｅフィールド５０５に格納された値が許可されているか否かを判定する（２２４）。ＰＣＲＦ２は、メディアタイプが許可されている場合には（２２４の結果が「ＹＥＳ」）、ＵＬ＿ＢＷフィールド５５３に値が設定されているか否かを判定する（２２５）。ＰＣＲＦ２は、ＵＬ＿ＢＷフィールド５５３に値が設定されている場合には（２２５の結果が「ＹＥＳ」）、Ｍａｘ−Ｒｅｑｕｅｓｔｅｄ−ＢＷ−ＵＬフィールド５０７の値が、ＵＬ＿ＢＷフィールド５５３の値以下であるか否かを判定する（２２６）。さらに、ＰＣＲＦ２は、ＤＬ＿ＢＷフィールド５５４に値が設定されているか否かを判定する（２２７）。そして、値が設定されていた場合には（２２７の結果が「ＹＥＳ」）、Ｍａｘ−Ｒｅｑｕｅｓｔｅｄ−ＢＷ−ＤＬフィールド５０８の値がＤＬ＿ＢＷフィールド５５４の値以下であるか否かを判定する（２２８）。

以上の条件を満足していた場合には、ＰＣＲＦ２は、サービス情報テーブル５００に格納されたエントリに基づいて、リソース認可応答パケットを生成し、ＡＧＷ３Ａに送信し（２２９）、処理を終了する。一方、２２４、２２６及び２２８の条件のいずれか一つでも満足しない場合には、リソース認可拒絶パケットを生成し、ＡＧＷ３Ａに送信し（２３０）、処理を終了する。

次に、第１の実施の形態のＡＧＷ３Ａの構成及び処理について説明する。なお、ＡＧＷ３Ｂの構成は、ＡＧＷ３Ａと同じ構成である。

図４Ａは、第１の実施の形態のＡＧＷ３Ａのハードウェア構成を示す図である。ＡＧＷ３Ａは、ＣＰＵ３１、メモリ３２、ＨＤＤ３３及びＩＦ３４Ａ〜３４Ｎを備える。

ＣＰＵ３１は、メモリ３２に記憶されたプログラムを実行する。メモリ３２は、ＣＰＵ３１によって実行されるプログラム及び処理に必要なデータを格納する。ＨＤＤ３３は、プログラム及データを格納する。ＩＦ３４Ａ〜３４Ｎは、コアネットワーク５１又はアクセスネットワーク５２を介して他の計算機と通信する。

図４Ｂは、第１の実施の形態のＡＧＷ３Ａのメモリ３２の構成を示す図である。メモリ３２は、ＱｏＳ情報管理プログラム３００、ＱｏＳ施行プログラム３４０、Ａｕｔｈｏｒｉｚｅｄ ＱｏＳ情報テーブル６００及びＲｅｑｕｅｓｔｅｄ Ａｃｃｅｓｓ Ｎｅｔｗｏｒｋ ＱｏＳ情報テーブル６５０を格納する。

ＱｏＳ情報管理プログラム３００及びＱｏＳ施行プログラム３４０は、ＣＰＵ３１によって実行される。ＱｏＳ情報管理プログラム３００は、Ａｕｔｈｏｒｉｚｅｄ ＱｏＳ情報テーブル６００及びＲｅｑｕｅｓｔｅｄ Ａｃｃｅｓｓ Ｎｅｔｗｏｒｋ ＱｏＳ情報テーブル６５０を更新し、リソース認可要求パケットをＰＣＲＦ２に送信する。ＱｏＳ施行プログラム３４０は、認可されたＱｏＳポリシに基づいてＱｏＳ制御を実行する。

Ａｕｔｈｏｒｉｚｅｄ ＱｏＳ情報テーブル６００は、ＰＣＲＦ２から受信したリソース認可応答パケットの内容を格納する。Ｒｅｑｕｅｓｔｅｄ Ａｃｃｅｓｓ Ｎｅｔｗｏｒｋ ＱｏＳ情報テーブル６５０は、ＵＥ７とＡＧＷ３Ａ間のベアラ確立開始の過程において要求されたＱｏＳ情報を格納する。

図７Ａは、第１の実施の形態のＡｕｔｈｏｒｉｚｅｄ ＱｏＳ情報テーブル６００の構成を示す図である。Ａｕｔｈｏｒｉｚｅｄ ＱｏＳ情報テーブル６００は、ＵＥ７とＡＧＷ３Ａとの間でベアラ確立が開始されるたびにエントリが追加される。

Ａｕｔｈｏｒｉｚｅｄ ＱｏＳ情報テーブル６００は、ＮＡＩフィールド６０１、Ｆｌｏｗ＿ＩＤフィールド６０２、Ｒａｄｉｕｓ Ｓｅｓｓｉｏｎ ＩＤフィールド６０３、Ａｕｔｈｏｒｉｚｅｄ ＩＰ ＱｏＳ情報フィールド６０４及びＡｕｔｈｏｒｉｚｅｄ Ａｃｃｅｓｓ Ｎｅｔｗｏｒｋ ＱｏＳ情報フィールド６０５を含む。

ＮＡＩフィールド６０１は、ＵＥ７のユーザ情報を示すＮＡＩを格納する。Ｆｌｏｗ＿ＩＤフィールド６０２は、フローを識別するための識別子を格納する。Ｒａｄｉｕｓ Ｓｅｓｓｉｏｎ ＩＤフィールド６０３は、ＡＧＷ３ＡがＰＣＲＦ２にリソース認可要求パケット７４０を送信するセッションを識別する識別子を格納する。Ａｕｔｈｏｒｉｚｅｄ ＩＰ ＱｏＳ情報フィールド６０４は、ＰＣＲＦ２から受信したリソース認可応答パケットのＱｏＳ情報部（７５４〜７５６）の値を格納する。

Ａｕｔｈｏｒｉｚｅｄ Ａｃｃｅｓｓ Ｎｅｔｗｏｒｋ ＱｏＳ情報フィールド６０５は、後述するＲｅｑｕｅｓｔｅｄ Ａｃｃｅｓｓ Ｎｅｔｗｏｒｋ ＱｏＳ情報６５４と比較するための情報を格納する。Ａｕｔｈｏｒｉｚｅｄ Ａｃｃｅｓｓ Ｎｅｔｗｏｒｋ ＱｏＳ情報フィールド６０５は、ＭａｘＢＷ＿ＵＬフィールド６０５Ａ、ＭａｘＢＷ＿ＤＬフィールド６０５Ｂ及びＭａｘＴｒａｆｆｉｃ＿Ｃｌａｓｓフィールド６０５Ｃを含む。Ａｕｔｈｏｒｉｚｅｄ Ａｃｃｅｓｓ Ｎｅｔｗｏｒｋ ＱｏＳ情報フィールド６０５に格納される値は、Ａｕｔｈｏｒｉｚｅｄ ＩＰ ＱｏＳ情報フィールド６０４の情報に基づいて生成される。

図７Ｂは、第１の実施の形態のＲｅｑｕｅｓｔｅｄ Ａｃｃｅｓｓ Ｎｅｔｗｏｒｋ ＱｏＳ情報テーブル６５０の構成を示す図である。ＵＥ７とＡＧＷ３Ａとの間でベアラ確立が開始されるたびに、Ｒｅｑｕｅｓｔｅｄ Ａｃｃｅｓｓ Ｎｅｔｗｏｒｋ ＱｏＳ情報テーブル６５０には、エントリが追加される。

Ｒｅｑｕｅｓｔｅｄ Ａｃｃｅｓｓ Ｎｅｔｗｏｒｋ ＱｏＳ情報テーブル６５０は、ＮＡＩフィールド６５１、Ｆｌｏｗ＿ＩＤフィールド６５２、フロー情報フィールド６５３及びＲｅｑｕｅｓｔｅｄ Ａｃｃｅｓｓ Ｎｅｔｗｏｒｋ ＱｏＳ情報フィールド６５４を含む。

ＮＡＩフィールド６５１は、ＵＥ７のユーザ情報を示すＮＡＩを格納する。Ｆｌｏｗ＿ＩＤフィールド６５２は、フローを識別するための識別子を格納する。

フロー情報フィールド６５３は、フロー情報を格納する。フロー情報フィールド６５３は、Ｄｉｒｅｃｔｉｏｎフィールド６５３Ａ、ＳＲＣアドレスフィールド６５３Ｂ、ＤＳＴアドレスフィールド６５３Ｃ、ＳＲＣポート番号フィールド６５３Ｄ、ＤＳＴポート番号フィールド６５３Ｅ及びプロトコルフィールド６５３Ｆを含む。Ｄｉｒｅｃｔｉｏｎフィールド６５３Ａは、フローの方向を格納する。ＳＲＣフィールド６５３Ｂは、送信元ＩＰアドレスを格納する。ＤＳＴアドレスフィールド６５３Ｃは、宛先ＩＰアドレスを格納する。ＳＲＣポート番号フィールド６５３Ｄは、送信元ポート番号を格納する。ＤＳＴポート番号フィールド６５３Ｅは、宛先ポート番号を格納する。プロトコルフィールド６５３Ｆは、プロトコルの名前又は番号を格納する。

Ｒｅｑｕｅｓｔｅｄ Ａｃｃｅｓｓ Ｎｅｔｗｏｒｋ ＱｏＳ情報フィールド６５４は、ベアラ確立を開始するときに要求されたＱｏＳ情報を格納する。Ｒｅｑｕｅｓｔｅｄ Ａｃｃｅｓｓ Ｎｅｔｗｏｒｋ ＱｏＳ情報フィールド６５４は、Ａｕｔｈｏｒｉｚｅｄ ＱｏＳ情報テーブル６００のＡｕｔｈｏｒｉｚｅｄ Ａｃｃｅｓｓ Ｎｅｔｗｏｒｋ ＱｏＳ情報フィールド６０５と比較することによって、ベアラ確立の可否を判定する材料となる。

Ｒｅｑｕｅｓｔｅｄ Ａｃｃｅｓｓ Ｎｅｔｗｏｒｋ ＱｏＳ情報フィールド６５４は、Ｒ＿ＧｕａｒａｎｔｅｅｄＢＲ＿ＵＬフィールド６５４Ａ、Ｒ＿ＧｕａｒａｎｔｅｅｄＢＲ＿ＤＬフィールド６５４Ｂ、Ｒ＿ＭａｘＢＲ＿ＵＬフィールド６５４Ｃ、Ｒ＿ＭａｘＢＲ＿ＤＬフィールド６５４Ｄ及びＲ＿Ｔｒａｆｆｉｃ＿Ｃｌａｓｓフィールド６５４Ｅを含む。

Ｒ＿ＧｕａｒａｎｔｅｅｄＢＲ＿ＵＬフィールド６５４Ａは、データを送信するために保証される帯域を格納する。Ｒ＿ＧｕａｒａｎｔｅｅｄＢＲ＿ＤＬフィールド６５４Ｂは、データを受信するために保証される帯域を格納する。Ｒ＿ＭａｘＢＲ＿ＵＬフィールド６５４Ｃは、データを送信するための帯域の最大値を格納する。Ｒ＿ＭａｘＢＲ＿ＤＬフィールド６５４Ｄは、データを受信するための帯域の最大値を格納する。Ｒ＿Ｔｒａｆｆｉｃ＿Ｃｌａｓｓフィールド６５４Ｅは、要求されたメディアの種類を格納する。

図１４Ａは、第１の実施の形態のＱｏＳ情報管理プログラム３００のベアラ確立時の処理手順を示すフローチャートである。

ＡＧＷ３Ａは、ＵＥ７が確立しようとしているベアラに対する要求に基づいて、Ｒｅｑｕｅｓｔｅｄ Ａｃｃｅｓｓ Ｎｅｔｗｏｒｋ ＱｏＳ情報テーブル６５０にエントリを追加する（３０１）。

次に、ＡＧＷ３Ａは、リソース認可要求パケット７４０を生成し、ＰＣＲＦ２に送信する（３０２）。なお、図１１Ａに示したリソース認可要求パケット７４０のＵｓｅｒ−Ｎａｍｅフィールド７４１には、図７Ｂに示したＲｅｑｕｅｓｔｅｄ Ａｃｃｅｓｓ Ｎｅｔｗｏｒｋ ＱｏＳ情報テーブル６５０のＮＡＩフィールド６５１の値を格納する。同様に、リソース認可要求パケット７４０のＦｌｏｗ＿ＩＤフィールド７４２には、Ｒｅｑｕｅｓｔｅｄ Ａｃｃｅｓｓ Ｎｅｔｗｏｒｋ ＱｏＳ情報テーブル６５０のＦｌｏｗ＿ＩＤフィールド６５２の値を格納する。リソース認可要求パケット７４０のフィールド７４３〜７４８には、Ｒｅｑｕｅｓｔｅｄ Ａｃｃｅｓｓ Ｎｅｔｗｏｒｋ ＱｏＳ情報テーブル６５０のフロー情報フィールド６５３（６５３Ａ〜６５３Ｆ）の値を格納する。

ＡＧＷ３Ａは、Ａｕｔｈｏｒｉｚｅｄ ＱｏＳ情報テーブル６００に新たにエントリを追加する。そして、ＡＧＷ３Ａは、ＰＣＲＦ２から送信されたリソース認可応答パケットの内容に基づいて、ＮＡＩフィールド６０１、Ｆｌｏｗ＿ＩＤフィールド６０２及びＲａｄｉｕｓ Ｓｅｓｓｉｏｎ ＩＤフィールド６０３の値を設定する（３０３）。

図１４Ｂは、第１の実施の形態のＱｏＳ情報管理プログラム３００がリソース認可応答パケット又は、リソース認可拒絶パケットを受信したときに実行される処理を示すフローチャートである。

ＡＧＷ３Ａは、まず、受信したパケットがリソース認可拒絶パケットであるか否かを判定する（３２１）。具体的には、受信したパケットにＲｅｊｅｃｔ？フィールド７５２が含まれるか否かを判定する。受信したパケットがＲｅｊｅｃｔ？フィールド７５２を含まない場合には（３２１の結果が「ＮＯ」）、リソース認可応答パケットを受信したこととなり、Ａｕｔｈｏｒｉｚｅｄ ＱｏＳ情報テーブル６００から該当するエントリを検索し、取得する（３２２）。

次に、ＡＧＷ３Ａは、取得したエントリに対し、Ａｕｔｈｏｒｉｚｅｄ ＩＰ ＱｏＳ情報エントリ６０４の値を設定する（３２３）。具体的には、ＡＧＷ３Ａは、リソース認可応答パケットのＭａｘＤＲ＿ＵＬフィールド−７５４の値をＭａｘＤＲ＿ＵＬフィールド６０４Ａに格納する。同様に、ＭａｘＤＲ＿ＤＬフィールド７５５の値をＭａｘＤＲ＿ＤＬフィールド６０４Ｂに、Ｍａｘ＿ＱｏＳ＿Ｃｌａｓｓフィールド７５６の値をＭａｘ＿ＱｏＳ＿Ｃｌａｓｓフィールド６０４Ｃに格納する。

続いて、ＡＧＷ３Ａは、Ａｕｔｈｏｒｉｚｅｄ ＩＰ ＱｏＳ情報フィールド６０４の値に基づいて、Ａｕｔｈｏｒｉｚｅｄ Ａｃｃｅｓｓ Ｎｅｔｗｏｒｋ ＱｏＳ情報フィールド６０５の値を設定する（３２４）。ＭａｘＢＷ＿ＵＬフィールド６０５Ａには、ＭａｘＤＲ＿ＵＬフィールド６０４Ａの値を格納する。同様に、ＭａｘＢＷ＿ＤＬフィールド６０５Ｂには、ＭａｘＤＲ＿ＤＬフィールド６０４Ｂの値を格納する。ＭａｘＴｒａｆｆｉｃ＿Ｃｌａｓｓフィールド６０５Ｃは、Ｍａｘ＿ＱｏＳ＿Ｃｌａｓｓフィールド６０４Ｃの値に基づいて設定される。例えば、“Ａ”又は“Ｂ”などの符号で表現されたＱｏＳクラスを、“Ｓｔｒｅａｍｉｎｇ”又は“Ｃｏｎｖｅｒｓａｔｉｏｎａｌ”などの形式に変換する。

次に、ＡＧＷ３Ａは、ＮＡＩフィールド６０１及びＦｌｏｗ＿ＩＤフィールド６０２の値に基づいて、Ｒｅｑｕｅｓｔｅｄ Ａｃｃｅｓｓ Ｎｅｔｗｏｒｋ ＱｏＳ情報テーブル６５０から該当するエントリを検索し、取得する（３２５）。

ＡＧＷ３Ａは、要求されたリソースが承認されたリソースを超過していないか否かを判定する（３２６〜３２９）。なお、要求されたリソースは、Ｒｅｑｕｅｓｔｅｄ Ａｃｃｅｓｓ Ｎｅｔｗｏｒｋ ＱｏＳ情報フィールド６５４に格納されている。また、承認されたリソースは、Ａｕｔｈｏｒｉｚｅｄ Ａｃｃｅｓｓ Ｎｅｔｗｏｒｋ ＱｏＳ情報フィールド６０５に格納されている。

ＡＧＷ３Ａは、まず、ＭａｘＴｒａｆｆｉｃ＿Ｃｌａｓｓフィールド６０５Ｃの値が”Ｃｏｎｖｅｒｓａｔｉｏｎａｌ”又は”Ｓｔｒｅａｍｉｎｇ”のいずれかと一致するか否かを判定する（３２６）。一致する場合には（３２６の結果が「ＹＥＳ」）、Ｒ＿ＧｕａｒａｎｔｅｅｄＢＲ＿ＵＬフィールド６５４Ａの値がＭａｘＢＷ＿ＵＬフィールド６０５Ａの値以下であり、かつ、Ｒ＿ＧｕａｒａｎｔｅｅｄＢＲ＿ＤＬフィールド６５４Ｂの値がＭａｘＢＷ＿ＤＬフィールド６０５Ｂの値以下であるか否かを判定する（３２７）。一方、一致しない場合には（３２６の結果が「ＮＯ」）、Ｒ＿ＭａｘＢＲ＿ＵＬフィールド６５４Ｃの値がＭａｘＢＷ＿ＵＬフィールド６０５Ａの値以下であり、かつ、Ｒ＿ＭａｘＢＲ＿ＤＬフィールド６５４Ｄの値がＭａｘＢＷ＿ＤＬフィールド６０５Ｂの値以下であるか否かを判定する（３２８）。

ＡＧＷ３Ａは、３２７又は３２８の処理の結果が「ＹＥＳ」の場合には、Ｒ＿Ｔｒａｆｆｉｃ＿Ｃｌａｓｓフィールド６５４Ｅの値がＭａｘＴｒａｆｆｉｃ＿Ｃｌａｓｓフィールド６０５Ｃの値を超過していないか否かを判定する（３２９）。超過していなければ（３２９の結果が「ＹＥＳ」）、ベアラ確立は成功となり、その旨をＵＥ７に通知する（３３０）。

一方、要求されたリソースが承認されたリソースを超過した場合には（３２７〜３２９）、ベアラ確立は失敗となり、その旨をＵＥ７に通知し、必要ならば適切なエラー処理を実行する（３３１）。また、受信したパケットがリソース拒絶パケットであった場合（３２１の結果が「ＹＥＳ」）にもベアラ確立は失敗となり、ＵＥ７に通知し、必要ならば適切なエラー処理を実行する（３３１）。

図１５は、第１の実施の形態のＵＥ７がＡＰ５Ａに接続した状態で、Ｄｏｗｎｌｉｎｋ方向の映像ストリームメディアのセッションを確立する処理のシーケンスを示す図である。なお、図６Ｂで示した通信方式ＱｏＳ情報テーブル５５０を用いることによって、本セッションの確立は成功する。

ＵＥ７は、まず、セッションを確立するために、ＳＩＰ ＩＮＶＩＴＥメッセージをＣＳＣＦ１に送信する（８００Ａ）。なお、ＵＥ７は、ＩＥＥＥ８０２．１１ａのＡＰ５Ａに接続しているため、ＳＩＰ ＩＮＶＩＴＥメッセージ７００のＰ−Ａｃｃｅｓｓ−Ｎｅｔｗｏｒｋ−Ｉｎｆｏヘッダ７０９には、「ＩＥＥＥ８０２．１１ａ」と設定される。

ＣＳＣＦ１は、ＳＩＰ ＩＮＶＩＴＥメッセージ７００を受信すると（図１２Ａの１０２の結果が「ＹＥＳ」）、セッション情報管理プログラム１２０を起動する（図１２Ａの１０３）。そして、ＣＳＣＦ１は、自身が持つセッション情報テーブル４００に新たなエントリ４００Ａを追加する（図１２Ｂの１２３）。このとき、ＣＳＣＦ１は、Ａｃｃｅｓｓ−Ｎｅｔｗｏｒｋ−Ｉｎｆｏフィールド４０２に、Ｐ−Ａｃｃｅｓｓ−Ｎｅｔｗｏｒｋ−Ｉｎｆｏヘッダ７０９に格納されている値を複写する（図１２Ｂの１２７）。また、ＳＩＰ ＩＮＶＩＴＥメッセージ７００に含まれるｃ−ｌｉｎｅ７０２、ｍ−ｌｉｎｅ７０３、ｂ−ｌｉｎｅ７０４及びａ−ｌｉｎｅ７０５の値に基づいて、Ｕｐｌｉｎｋ ＳＤＰ情報フィールド４０３を設定する（図１２Ｂの１２８）。

また、ＣＳＣＦ１は、ＳＩＰ ＩＮＶＩＴＥメッセージ７００を適切な転送先に転送し（８００Ｂ；図１２Ａの１０１）、ＵＥ７に対してＳＩＰ １００応答メッセージを返信する（８０１Ａ）。

そして、ＣＳＣＦ１は、転送先からＳＩＰ １００応答メッセージを受信し（８０１Ｂ）、さらにその後、転送先からＳＩＰ １８３応答メッセージ７１０を受信する（８０２Ｂ）。また、ＵＥ７から送信されたＳＩＰ ＩＮＶＩＴＥメッセージ７００は、要求したサービスに対応するメディアの候補が含まれる。ＳＩＰ ＩＮＶＩＴＥメッセージ７００を受信した相手側の端末は、メディアの候補の中から使用可能なメディアを選択し、ＳＩＰ １８３応答メッセージ７１０に格納して送信する（８０２Ｂ）。したがって、要求されたサービスに必要なリソースは、ＳＩＰ １８３応答メッセージ７１０を受信した後に決定される。

ＣＳＣＦ１は、ＳＩＰ １８３応答メッセージ７１０を受信すると、セッション情報テーブル４００から該当するエントリ４００ＡをＳＩＰセッション識別情報４０１に基づいて検索する（図１２Ｂの１２１及び１２５）。そして、ＣＳＣＦ１は、ＳＩＰ １８３応答メッセージ７１０に含まれるｃ−ｌｉｎｅ７１２、ｍ−ｌｉｎｅ７１３、ｂ−ｌｉｎｅ７１４及びａ−ｌｉｎｅ７１５の値に基づいて、Ｄｏｗｎｌｉｎｋ ＳＤＰ情報フィールド４０４を設定する（図１２Ｂの１２９）。さらに、ＣＳＣＦ１は、受信したＳＩＰ １８３応答メッセージ７１０をＵＥ７に転送する（８０２Ａ；図１２Ａの１０１）。

さらに、ＣＳＣＦ１は、セッション情報テーブル４００の該当エントリ４００Ａに基づいて、サービス情報通知パケット７２０Ａを生成し、ＰＣＲＦ２に送信する（８０３；図１２Ｂの１３１）。サービス情報通知パケット７２０ＡのＡｃｃｅｓｓ−Ｎｅｔｗｏｒｋ−Ｉｎｆｏフィールド７２４には、セッション情報テーブル４００の該当エントリ４００ＡのＡｃｃｅｓｓ−Ｎｅｔｗｏｒｋ−Ｉｎｆｏフィールド４０２に基づいて、「ＩＥＥＥ８０２．１１ａ」が格納される。

ＰＣＲＦ２は、サービス情報通知パケット７２０Ａを受信すると（８０３）、サービス情報テーブル５００に新たなエントリ５００Ａを生成し、サービス情報通知パケット７２０Ａに設定された値に従って、該当エントリ５００Ａの各フィールドの値を設定する（図１３Ａの２０１）。サービス情報テーブル５００のエントリ５００ＡのＡｃｃｅｓｓ−Ｎｅｔｗｏｒｋ−Ｉｎｆｏフィールド５０４には、「ＩＥＥＥ８０２．１１ａ」が格納される。続いて、ＰＣＲＦ２は、サービス情報通知パケット７２０Ａに対する応答として、サービス情報応答パケットをＣＳＣＦ１に返信する（８０４；図１３Ａの２０２）。

一方、ＵＥ７は、ＳＩＰ １８３応答メッセージ７１０を受信すると（８０２Ａ）、その受信確認を通知するために、ＣＳＣＦ１にＳＩＰ ＰＲＡＣＫメッセージを送信する（８０５Ａ）。

ＣＳＣＦ１は、受信したＳＩＰ ＰＲＡＣＫメッセージを適切な転送先に転送する（８０５Ｂ；図１２Ａの１０１）。ＣＳＣＦ１は、ＳＩＰ ＰＲＡＣＫメッセージの応答としてＳＩＰ ２００応答メッセージを受信し（８０６Ｂ）、ＵＥ７に転送する（８０６Ａ；図１２Ａの１０１）。

また、ＵＥ７は、ＳＩＰ ＰＲＡＣＫメッセージの送信（８０５Ａ）と並行して、ＡＧＷ３Ａとの間で、従来どおり、ベアラ確立を開始する（８０７）。

ＡＧＷ３Ａは、ベアラ確立の過程において、Ｒｅｑｕｅｓｔｅｄ Ａｃｃｅｓｓ Ｎｅｔｗｏｒｋ ＱｏＳ情報テーブル６５０に、新しいエントリ６５０Ａを追加し、各フィールドの値を設定する（図１４Ａの３０１）。そして、ＡＧＷ３Ａは、エントリ６５０Ａに基づいて、リソース認可要求パケット７４０Ａを生成し、ＰＣＲＦ２に送信する（８０８；図１４Ａの３０２）。さらに、ＡＧＷ３Ａは、Ａｕｔｈｏｒｉｚｅｄ ＱｏＳ情報テーブル６００に、新たにエントリ６００Ａを追加し、ＮＡＩフィールド６０１、Ｆｌｏｗ＿ＩＤフィールド６０２及びＲａｄｉｕｓ Ｓｅｓｓｉｏｎ ＩＤフィールド６０３の値を設定する（図１４Ａの３０３）。

ＰＣＲＦ２は、リソース認可要求パケット７４０Ａを受信すると（８０８）、サービス情報テーブル５００から該当するエントリ５００Ａを検索する（図１３Ｂの２２１）。そして、ＰＣＲＦ２は、Ａｃｃｅｓｓ−Ｎｅｔｗｏｒｋ−Ｉｎｆｏフィールド５０４に格納された値「ＩＥＥＥ８０２．１１ａ」に基づいて、通信方式ＱｏＳ情報テーブル５５０から該当するエントリ５５０Ｂを検索する（図１３Ｂの２２３）。次に、ＰＣＲＦ２は、受信したリソース認可要求パケット７４０Ａに格納された値に基づいて、セッションの確立を許可するか否かを決定する（図１３Ｂの２２４〜２２８）。なお、第１の実施の形態では、前述のようにセッションの確立は許可される。そして、ＰＣＲＦ２は、リソース認可応答パケットを生成し、ＡＧＷ３Ａに送信する（８０９；図１３Ｂの２２９）。

ＡＧＷ３Ａは、リソース認可応答パケットを受信すると、格納された情報に基づいて、Ａｕｔｈｏｒｉｚｅｄ ＱｏＳ情報テーブル６００の該当エントリ６００ＡのＡｕｔｈｏｒｉｚｅｄ ＩＰ ＱｏＳ情報フィールド６０４を更新する（図１４Ｂの３２３）。そして、Ａｕｔｈｏｒｉｚｅｄ ＩＰ ＱｏＳ情報フィールド６０４の値からＡｕｔｈｏｒｉｚｅｄ Ａｃｃｅｓｓ Ｎｅｔｗｏｒｋ ＱｏＳ情報フィールド６０５に格納する値を導出し、Ａｕｔｈｏｒｉｚｅｄ Ａｃｃｅｓｓ Ｎｅｔｗｏｒｋ ＱｏＳ情報フィールド６０５に格納する（図１４Ｂの３２４）。ＡＧＷ３Ａは、要求したリソースが使用可能であるか否かを判定する（図１４Ｂの３２６〜３２９）。第１の実施の形態では、ベアラ確立が許可され、ＡＧＷ３Ａは、その旨をＵＥ７に通知する（８１０）。

その後、ＵＥ７は、セッションの確立を完了させるために、ＳＩＰ ＵＰＤＡＴＥメッセージをＣＳＣＦ１に送信する（８１１Ａ）。ＣＳＣＦ１は、受信したＳＩＰ ＵＰＤＡＴＥメッセージを適切な転送先に転送する（８１１Ｂ）。続いて、ＣＳＣＦ１は、ＳＩＰ ＵＰＤＡＴＥメッセージの応答としてＳＩＰ ２００応答メッセージを受信し（８１２Ｂ）、ＵＥ７に転送する（８１２Ａ）。この後、着呼側の端末が呼び出し音を鳴らし始めると、ＣＳＣＦ１は、ＳＩＰ １８０応答を受信するので（８１３Ｂ）、ＵＥ７に転送する（８１３Ａ）。ＵＥ７は、ＳＩＰ １８０応答メッセージ（８１３Ａ）を受信し、受信確認を通知するためにＣＳＣＦ１に対し、ＳＩＰ ＰＲＡＣＫメッセージを送信する（８１４Ａ）。ＣＳＣＦ１は、受信したＳＩＰ ＰＲＡＣＫメッセージを適切な転送先に転送する（８１４Ｂ）。

続いて、ＣＳＣＦ１は、ＳＩＰ ＰＲＡＣＫメッセージ（８１４Ｂ）の応答としてＳＩＰ ２００応答メッセージを受信し（８１５Ｂ）、ＵＥ７に転送する（８１５Ａ）。この後、ＣＳＣＦ１は、着呼側のユーザが応答すると、ＳＩＰ ２００応答メッセージを受信する（８１６Ｂ）。ＣＳＣＦ１は、着呼側からＳＩＰ ２００応答メッセージを受信すると、ＡＧＷ３Ａに対してメディアパケットの通過許可を通知するために、ＰＣＲＦ２にＧａｔｅオープン要求パケットを送信する（８１７）。

ＰＣＲＦ２は、Ｇａｔｅオープン要求パケットを受信すると、ＡＧＷ３ＡにＧａｔｅオープン要求パケットを送信する（８１８）。

ＡＧＷ３Ａは、メディアパケットの通過を許可し、さらに、Ｇａｔｅオープン要求パケットに対する応答として、Ｇａｔｅオープン応答パケットをＰＣＲＦ２に送信する（８１９）。さらに、ＰＣＲＦ２は、Ｇａｔｅオープン応答パケットをＣＳＣＦ１に送信する（８２０）。

ＣＳＣＦ１は、Ｇａｔｅオープン応答パケットを受信すると、着呼側から受信したＳＩＰ ２００応答メッセージをＵＥ７に転送する（８１６Ａ）。ＵＥ７は、ＳＩＰ ２００応答メッセージを受信すると、ＣＳＣＦ１にＳＩＰ ＡＣＫメッセージを送信する（８２１Ａ）。ＣＳＣＦ１は、受信したＳＩＰ ＡＣＫメッセージを適切な転送先に転送する（８２１Ｂ）。そして、ＳＩＰ ＡＣＫメッセージが着呼側の端末に到達すれば、セッションの確立が完了し、メディアパケットの交換が開始される（８２２）。

第１の実施の形態によれば、ＵＥ７が接続するアクセスネットワークの通信方式の種別をＰＣＲＦ２に認識させることによって、アクセスネットワークの通信方式に応じたＱｏＳポリシを決定することができる。例えば、広帯域な通信方式を利用している端末に対してのみ、映像ストリームなどの多くのリソースを消費するサービスの利用を許可することが可能となる。したがって、ある利用者が低帯域のアクセスポイントに接続して多くのリソースを消費するサービスを利用することによって、他の利用者がサービスを利用することができなくなることを防止することができる。また、サービスを提供する事業者及びアクセスネットワークを提供する事業者にとっても、安定したサービスを利用者に提供することができる。

（第２の実施の形態）
第２の実施の形態では、ＵＥ７がＩＥＥＥ８０２．１１ｂのＡＰ５Ｂに接続して、Ｄｏｗｎｌｉｎｋ方向の映像ストリームメディアのセッションを確立する場合について説明する。なお、第１の実施の形態と同様の機能を果たす構成には同一の符号を付して重複する説明を適宜省略する。第２の実施の形態では、ＵＥ７がＡＰ５Ｂに接続すること以外は、第１の実施の形態と同じ構成となる。

図１６は、第２の実施の形態のＵＥ７からＤｏｗｎｌｉｎｋ方向の映像ストリームメディアのセッションを確立する処理のシーケンスを示す図である。なお、図６Ｂで示した通信方式ＱｏＳ情報テーブル５５０によると、本セッションの確立は失敗する。

ＵＥ７は、まず、第１の実施の形態と同様に、ＳＩＰ ＩＮＶＩＴＥメッセージをＣＳＣＦ１に送信する（８００Ａ）。ただし、第２の実施の形態では、ＵＥ７は、ＩＥＥＥ８０２．１１ｂのＡＰ５Ｂに接続しているため、ＳＩＰ ＩＮＶＩＴＥメッセージ７００に含まれるＰ−Ａｃｃｅｓｓ−Ｎｅｔｗｏｒｋ−Ｉｎｆｏヘッダ７０９は、「ＩＥＥＥ８０２．１１ｂ」と設定される。したがって、セッション情報テーブル４００のＡｃｃｅｓｓ−Ｎｅｔｗｏｒｋ−Ｉｎｆｏフィールド４０２には、「ＩＥＥＥ８０２．１１ｂ」が格納される。

次に、ＵＥ７は、ＳＩＰ ＩＮＶＩＴＥメッセージに対する応答としてＳＩＰ １８３応答メッセージを受信する（８０２Ａ）。また、ＣＳＣＦ１は、セッション情報テーブル４００の該当するエントリに基づいて、サービス情報通知パケット７２０を生成し、ＰＣＲＦ２に送信する（８０３）。サービス情報通知パケット７２０のＡｃｃｅｓｓ−Ｎｅｔｗｏｒｋ−Ｉｎｆｏフィールド７２４には、セッション情報テーブル４００の該当エントリのＡｃｃｅｓｓ−Ｎｅｔｗｏｒｋ−Ｉｎｆｏフィールド４０２の「ＩＥＥＥ８０２．１１ｂ」が格納される。

ＰＣＲＦ２は、サービス情報通知パケット７２０Ａを受信すると（８０３）、サービス情報テーブル５００に新たなエントリを追加する。第２の実施の形態では、該当エントリのＡｃｃｅｓｓ−Ｎｅｔｗｏｒｋ−Ｉｎｆｏフィールド５０４には、「ＩＥＥＥ８０２．１１ｂ」が格納される。そして、ＰＣＲＦ２は、第１の実施の形態と同様に、サービス情報通知パケットへの応答として、サービス情報応答パケットをＣＳＣＦ１に送信し（８０４）する。その後、ＵＥ７は、ＣＳＣＦ１にＳＩＰ ＰＲＡＣＫメッセージを送信し（８０５Ａ）、ＳＩＰ ＰＲＡＣＫメッセージの応答としてＳＩＰ ２００応答メッセージを受信する（８０６Ａ）。

ＵＥ７は、ＡＧＷ３Ａとの間でベアラ確立を開始する（８０７）。ＡＧＷ３Ａは、リソース認可要求パケット７４０をＰＣＲＦ２に送信する（８０８）。

ＰＣＲＦ２は、リソース認可要求パケット７４０Ａを受信すると（８０８）、サービス情報テーブル５００から該当するエントリ５００Ａを検索する（図１３Ｂの２２１）。そして、ＰＣＲＦ２は、Ａｃｃｅｓｓ−Ｎｅｔｗｏｒｋ−Ｉｎｆｏフィールド５０４に格納された値「ＩＥＥＥ８０２．１１ｂ」に基づいて、通信方式ＱｏＳ情報テーブル５５０から該当するエントリ５５０Ｂを検索する（図１３Ｂの２２３）。続いて、ＰＣＲＦ２は、受信したリソース認可要求パケット７４０Ａに格納された値に基づいて、セッションの確立を許可するか否かを決定する（図１３Ｂの２２４〜２２８）。なお、アクセス方式が「ＩＥＥＥ８０２．１１ｂ」の場合には、ストリーミングは許可されていないため、セッションの確立は拒絶される。ＰＣＲＦ２は、リソース認可拒絶パケットを生成し、ＡＧＷ３Ａに送信する（８３０；図１３Ｂの２３０）。

ＵＥ７は、ベアラ確立の不許可の通知を受信し（８３１）、継続中のセッションを確立する処理を中止させるために、ＳＩＰ ＣＡＮＣＥＬメッセージをＣＳＣＦ１に送信する（８３２）。

ＣＳＣＦ１は、受信したＳＩＰ ＣＡＮＣＥＬメッセージを適切な転送先に転送する（８３３）。さらに、ＣＳＣＦ１は、受信したＳＩＰ ＣＡＮＣＥＬメッセージに対する応答として、ＵＥ７にＳＩＰ ２００応答メッセージを送信する（８３４）。ＣＳＣＦ１は、転送先からのＳＩＰ ＣＡＮＣＥＬメッセージに対する応答として、ＳＩＰ ２００応答メッセージを受信する（８３５）。そして、ＣＳＣＦ１は、ＳＩＰ ＩＮＶＩＴＥメッセージに対する応答として、ＳＩＰ ４８７応答メッセージを受信し（８３６Ｂ）、ＵＥ７に転送する（８３６Ａ）。また、ＣＳＣＦ１は、ＳＩＰ ＡＣＫメッセージを転送先に転送する（８３７）。さらに、ＵＥ７は、ＳＩＰ ４８７応答メッセージを受信すると、ＳＩＰ ＡＣＫメッセージをＣＳＣＦ１に送信する（８３８）。

第２の実施の形態によれば、ＵＥ７が低帯域な通信方式に接続している場合に、高いリソースを必要とするマルチメディアサービスの利用を制限することができる。この結果、一ユーザが帯域を独占し、他のユーザがサービスを利用できなくなることを回避できる。また、サービス提供事業者にとっても、公平かつ安定したサービスを利用者に提供することができる。

（第３の実施の形態）
第３の実施の形態では、第２の実施の形態と同様にＵＥ７がＩＥＥＥ８０２．１１ｂのＡＰ５Ｂに接続して、Ｄｏｗｎｌｉｎｋ方向の映像ストリームメディアのセッションを確立する場合について説明する。

図１７は、第３の実施の形態のＵＥ７からＤｏｗｎｌｉｎｋ方向の映像ストリームメディアのセッションを確立する処理のシーケンスを示す図である。なお、図６Ｂで示した通信方式ＱｏＳ情報テーブル５５０を用いると、本セッションの確立は失敗するが、第２の実施の形態と異なるシーケンスとなる。

第３の実施の形態では、ＵＥ７がＳＩＰ ＩＮＶＩＴＥメッセージをＣＳＣＦ１に送信してから（８００Ａ）。ＣＳＣＦ１がＰＣＲＦ２にサービス情報通知パケットを送信するまで（８０３）のシーケンスは、第２の実施の形態と同じである。

ＰＣＲＦ２は、サービス情報通知パケット７２０Ａに対する応答として、サービス情報応答パケットをＣＳＣＦ１に送信する（８４０；図１３Ａの２０２）。第３の実施の形態では、サービス情報テーブル５００の追加処理が完了すると（図１３Ａの２０１）、ＰＣＲＦ２は、通信方式ＱｏＳ情報テーブル５５０の該当エントリ５５０Ｃを参照し、セッションの許可又は拒絶を決定する。通信方式ＱｏＳ情報テーブル５５０の該当エントリ５５０Ｃを参照すると、ストリーミング許可されていないため、セッションは拒絶される。ＰＣＲＦ２は、セッション確立が拒絶された旨をＣＳＣＦ１に通知する（８４０）。そして、ＣＳＣＦ１は、セッションの確立を中止するための処理を実行する。

第３の実施の形態では、ＣＳＣＦ１は、Ｂ２ＢＵＡ（Ｂａｃｋ−Ｔｏ−Ｂａｃｋ Ｕｓｅｒ Ａｇｅｎｔ）として動作する。ＣＳＣＦ１は、ＵＥ７からのＳＩＰ ＩＮＶＩＴＥメッセージに対する応答として、ＳＩＰ ５０３応答メッセージを送信する（８４１）。ＵＥ７は、ＳＩＰ ５０３応答メッセージを受信した後、ＳＩＰ ＡＣＫメッセージをＣＳＣＦ１に送信する（８４２）。

続いて、ＣＳＣＦ１は、ＳＩＰ ＣＡＮＣＥＬメッセージを送信する（８４３）。そして、ＣＳＣＦ１は、ＳＩＰ ＣＡＮＣＥＬメッセージに対する応答としてＳＩＰ ２００ＯＫ応答メッセージを受信し（８４４）、さらに、ＳＩＰ ＩＮＶＩＴＥメッセージに対する応答としてＳＩＰ ４８７応答メッセージを受信する（８４５）。その後、ＣＳＣＦ１は、ＳＩＰ ＡＣＫメッセージを転送先に転送する（８４６）。

第３の実施の形態によれば、第２の実施の形態と同様に、ＵＥ７が低帯域な通信方式に接続しているとき、多くのリソースを必要とするマルチメディアサービスの利用を制限することができる。この結果、一ユーザが帯域を独占し、他のユーザがサービスを利用できなくなることを回避できる。また、サービス提供事業者にとっても、公平かつ安定したサービスを利用者に提供することができる。

また、第３の実施の形態によれば、機器間のメッセージの送受信を単純化することができ、セッションを迅速に確立することができる。

（第４の実施の形態）
第４の実施の形態では、ＰＣＲＦ２は、アクセスネットワークの通信方式種別に加えて、ＵＥ７のユーザＩＤに基づいてＱｏＳポリシを決定する。

図１８Ａは、第４の実施の形態の通信方式ＱｏＳ情報テーブル５５０を示す図である。図１８Ａの通信方式ＱｏＳ情報テーブル５５０は、図６Ｂの通信方式ＱｏＳ情報テーブル５５０と、Ｏ＿Ｕｓｅｒ＿ＩＤフィールド５５５を含む点で相違する。第４の実施の形態では、ＱｏＳポリシ決定プログラム２２０は、通信方式ＱｏＳ情報テーブル５５０を検索するとき（図１３Ｂ−２２３）、Ａｃｃｅｓｓ−Ｎｅｔｗｏｒｋ−Ｉｎｆｏフィールド５５１に加え、Ｏ＿Ｕｓｅｒ＿ＩＤフィールド５５５に基づいて検索する。したがって、利用者ごとに異なるＱｏＳポリシを適用することができる。

例えば、通信方式ＱｏＳ情報テーブル５５０には、ユーザ＜ｓｉｐ：ＵＥ＿Ｏ１＠ｏ−ｈｏｍｅ．ｃｏｍ＞用のエントリ５５０Ｄと、ユーザ＜ｓｉｐ：ＵＥ＿Ｏ２＠ｏ−ｈｏｍｅ．ｃｏｍ＞用のエントリ５５０Ｅが設定されている。したがって、ＩＥＥＥ８０２．１１ｂの環境では、ユーザ＜ｓｉｐ：ＵＥ＿Ｏ１＠ｏ−ｈｏｍｅ．ｃｏｍ＞は映像ストリームサービスを利用できないが、ユーザ＜ｓｉｐ：ＵＥ＿Ｏ２＠ｏ−ｈｏｍｅ．ｃｏｍ＞は映像ストリームサービスを利用できる。

第４の実施の形態によれば、利用者ごとにサービスの差別化を図ることができる。例えば、利用者の契約状況をＨＳＳ８から取得し、契約状況に基づいてサービスを差別化することも可能である。また、利用者が通信事業者自身の契約者か、又はローミング契約を結んでいる事業者の契約者かに応じて、サービスを差別することも可能である。

（第５の実施の形態）
第５の実施の形態では、ＰＣＲＦ２は、アクセスネットワークの通信方式種別に加え、ＵＥ７が通信する相手のドメイン又はユーザＩＤに基づいてＱｏＳポリシを決定する。

図１８Ｂは、第５の実施の形態の通信方式ＱｏＳ情報テーブル５５０を示す図である。図１８Ｂの通信方式ＱｏＳ情報テーブル５５０は、図６Ｂの通信方式ＱｏＳ情報テーブル５５０と、Ｔ＿Ｕｓｅｒ＿Ｄｏｍａｉｎフィールド５５６を含む点で相違する。第５の実施の形態では、ＱｏＳポリシ決定プログラム２２０は、通信方式ＱｏＳ情報テーブル５５０を検索するとき（図１３Ｂ−２２３）、Ａｃｃｅｓｓ−Ｎｅｔｗｏｒｋ−Ｉｎｆｏフィールド５５１に加え、Ｔ＿Ｕｓｅｒ＿Ｄｏｍａｉｎフィールド５５６に基づいて検索する。したがって、通信の相手先ごとに異なるＱｏＳポリシを適用することができる。

例えば、通信方式ＱｏＳ情報テーブル５５０には、通信事業者自身のドメイン＜ｓｉｐ：ｏ−ｈｏｍｅ．ｃｏｍ＞用のエントリ５５０Ｆと、それ以外（ｏｔｈｅｒｓ）用のエントリ５５０Ｇが設定されている。したがって、ＩＥＥＥ８０２．１１ｂの環境下では、ＡＳ６１（ＳＩＰ ＵＲＩ＜ｓｉｐ：ＡＳ１＠ｏ−ｈｏｍｅ．ｃｏｍ＞）からの映像ストリームサービスは利用可能であるが、ＡＳ６２（ＳＩＰ ＵＲＩ＜ｓｉｐ：ＡＳ２＠ｔ−ｈｏｍｅ．ｃｏｍ＞）からの映像ストリームサービスの利用は禁止される。なお、ＱｏＳポリシを決定するためにＵＥ７の通信相手のドメインをＰＣＲＦ２に通知する必要があるが、ＣＳＣＦ１送信するサービス情報通知パケット７２０に含まれるＳｕｂｓｃｒｉｐｔｉｏｎ−ＩＤフィールド７２３を参照すればよい。

第５の実施の形態によれば、他社が提供するマルチメディアサービスの利用によって、自社のリソースが大量に消費されることを防止するように、ＱｏＳポリシを決定することができる。また、自社が提供するマルチメディアサービスのみが利用可能となるように、ＱｏＳポリシを決定することができる。

（第６の実施の形態）
第１の実施の形態から第５の実施の形態では、３ＧＰＰ２ネットワークに対する本発明の実施の形態を説明したが、第６の実施の形態では、３ＧＰＰネットワークに対して本発明を適用する。

図１８Ｃは、第６の実施の形態の通信方式ＱｏＳ情報テーブル５５０を示す図である。第６の実施の形態の通信方式ＱｏＳ情報テーブル５５０は、３ＧＰＰ用の無線アクセス方式用のエントリ５５０Ｈを含む。ＰＣＲＦ２は、エントリ５５０Ｈに基づいて、ＱｏＳポリシを決定することができる。

第６の実施の形態によれば、３ＧＰＰ２ネットワークに限らず３ＧＰＰネットワークに対しても本発明を適用することができる。

（第７の実施の形態）
第７の実施の形態では、基地局ごとに異なるＱｏＳポリシを決定する。

図１９Ａは、第７の実施の形態のサービス情報テーブル５００の構成を示す図である。図１９Ａのサービス情報テーブル５００は、図６Ａのサービス情報テーブル５００と、ＢＳ＿ＩＤフィールド５１３を含む点で相違する。ＢＳ＿ＩＤフィールド５１３は、基地局を一意に特定するための識別子（基地局ＩＤ）を格納する。

図１９Ｂは、第７の実施の形態の基地局ＱｏＳ情報テーブル５６０の構成を示す図である。基地局ＱｏＳ情報テーブル５６０は、ＰＣＲＦ２のメモリ２２に格納される。基地局ＱｏＳ情報テーブル５６０は、ＱｏＳポリシ決定プログラム２２０がＱｏＳポリシを決定する際に参照するテーブルである。基地局ＱｏＳ情報テーブル５６０は、アクセスネットワークを提供する事業者によって予め設定される。

基地局ＱｏＳ情報テーブル５６０は、ＢＳ−ＩＤフィールド５６１、Ｍｅｄｉａ−Ｔｙｐｅフィールド５６２、ＵＬ＿ＢＷフィールド５６３及びＤＬ＿ＢＷフィールド５６４を含む。ＢＳ−ＩＤフィールド５６１は、基地局の識別子である基地局ＩＤを格納する。Ｍｅｄｉａ−Ｔｙｐｅフィールド５６２は、通信方式ＱｏＳ情報テーブル５５０のＭｅｄｉａ−Ｔｙｐｅフィールド５５２と同じである。また、ＵＬ＿ＢＷフィールド５６３及びＤＬ＿ＢＷフィールド５６４も、通信方式ＱｏＳ情報テーブル５５０のＵＬ＿ＢＷフィールド５５３及びＤＬ＿ＢＷフィールド５５４とそれぞれ同じである。なお、図１９Ｂには、基地局ＱｏＳ情報テーブル５６０には、ＢＳ６Ａ（基地局ＩＤ＝ｂｓｉｄ１）用のエントリ５６０Ａ，ＢＳ６Ｂ（基地局ＩＤ＝ｂｓｉｄ２）用のエントリ５６０Ｂが設定されている。

続いて、第７の実施の形態において、ＵＥ７がＢＳ６Ａに接続し、映像ストリームのセッションを確立する処理を説明する。ＵＥ７が送信するＳＩＰ ＩＮＶＩＴＥメッセージのＰ−Ａｃｃｅｓｓ−Ｎｅｔｗｏｒｋ−Ｉｎｆｏヘッダ７０９には、アクセスネットワーク種別の他に、基地局ＩＤも格納される。具体的には、ＢＳ６Ａの基地局ＩＤであるｂｓｉｄ１が格納される。さらに、ＣＳＣＦ１がＰＣＲＦ２にサービス情報通知パケット７２０を送信するときには、Ａｃｃｅｓｓ−Ｎｅｔｗｏｒｋ−Ｉｎｆｏフィールド７２４に基地局ＩＤ（この例ではｂｓｉｄ１）も含めて送信する。

ＰＣＲＦ２は、サービス情報通知パケット７２０を受信すると、サービス情報テーブルに新規エントリ５００Ｄを追加する。第７の実施の形態では、Ａｃｃｅｓｓ−Ｎｅｔｗｏｒｋ−Ｉｎｆｏフィールド７２４に含まれる基地局ＩＤをＢＳ−ＩＤフィールド５１３に格納する。そして、ＱｏＳポリシ決定プログラム２２０は、ＢＳ−ＩＤフィールド５６１の値に基づいて、基地局ＱｏＳ情報テーブル５６０を検索する。図１９Ｂを参照すると、基地局がＢＳ６Ａ（ＢＳ−ＩＤ＝ｂｓｉｄ１）であるとき、映像ストリーミングサービスが許可されているため、セッションの確立に成功する。

一方、ＵＥ７が接続している基地局がＢＳ６Ｂ（基地局ＩＤ＝ｂｓｉｄ２）であるときには、図１９Ｂの基地局ＱｏＳ情報テーブル５６０を参照すると、映像ストリーミングサービスが許可されないため、セッションの確立に失敗する。

第７の実施の形態によれば、同一通信方式の基地局であっても、端末が接続している基地局ごとに異なるＱｏＳポリシを適用することができる。例えば、企業内に設置された基地局と公衆用の基地局で、異なるＱｏＳポリシを適用することによって、サービスを差別化することが可能となる。

（第８の実施の形態）
第８の実施の形態では、各基地局の利用状況（実際にどの位の量のトラフィックが利用されているかなど）の情報に基づいて、ＱｏＳポリシを決定する。ＰＣＲＦ２は、第７の実施の形態の構成に加え、基地局利用状況テーブル５７０を備える。基地局利用状況テーブル５７０は、各基地局にて利用されているトラフィック量を見積もるために参照される。また、基地局利用状況テーブル５７０は、サービス情報管理プログラム２００によって、動的にエントリが追加される。

図２０は、第８の実施の形態の基地局利用状況テーブル５７０の構成を示す図である。基地局利用状況テーブル５７０は、ＢＳ＿ＩＤフィールド５７１、Ａｃｃｅｓｓ−Ｎｅｔｗｏｒｋ−Ｉｎｆｏフィールド５７２及び利用状況フィールド５７３を含む。利用状況フィールド５７３は、Ｓｕｂｓｃｒｉｐｔｉｏｎ−ＩＤフィールド５７３Ａ及びリソース量フィールド５７３Ｂを含む。ＢＳ＿ＩＤフィールド５７１は、基地局ＩＤを格納する。Ａｃｃｅｓｓ−Ｎｅｔｗｏｒｋ−Ｉｎｆｏフィールド５７２は、基地局のアクセス方式の種別を格納する。利用状況フィールド５７３は、基地局の利用状況を格納する。Ｓｕｂｓｃｒｉｐｔｉｏｎ−ＩＤフィールド５７３Ａは、ユーザＩＤを格納する。リソース量フィールド５７３Ｂは、利用者が使用中のリソース量を格納する。

ＰＣＲＦ２は、サービス情報管理プログラム２００によってサービス情報テーブル５００にエントリを更新するとき（図１３Ａの２０１）、サービス情報テーブル５００に格納された情報に基づいて、基地局利用状況テーブル５７０のエントリも追加する。ＱｏＳポリシ決定プログラム２２０がＱｏＳポリシを決定するとき、基地局利用状況テーブル５７０を参照してＱｏＳポリシを決定する。

第８の実施の形態によれば、基地局の利用状況に応じて異なるＱｏＳポリシを決定することができる。例えば、基地局が混雑しているときには、映像ストリーミングなどの大量のリソースを消費するサービスの利用を禁止し、混雑していないときには、サービスの利用を許可することができ、より柔軟にＱｏＳポリシを決定することができる。

第１の実施の形態のネットワーク構成を示す図である。 第１の実施の形態のＣＳＣＦのハードウェア構成を示す図である。 第１の実施の形態のＣＳＣＦのソフトウェア構成を示す図である。 第１の実施の形態のＰＣＲＦのハードウェア構成を示す図である。 第１の実施の形態のＰＣＲＦのソフトウェア構成を示す図である。 第１の実施の形態のＡＧＷのハードウェア構成を示す図である。 第１の実施の形態のＡＧＷのソフトウェア構成を示す図である。 第１の実施の形態のセッション情報テーブルの構成を示す図である。 第１の実施の形態のサービス情報テーブルの構成を示す図である。 第１の実施の形態の通信方式ＱｏＳ情報テーブルの構成を示す図である。 第１の実施の形態のＡｕｔｈｏｒｉｚｅｄ ＱｏＳ情報テーブルの構成を示す図である。 第１の実施の形態のＲｅｑｕｅｓｔｅｄ Ａｃｃｅｓｓ Ｎｅｔｗｏｒｋ ＱｏＳ情報テーブルの構成を示す図である。 第１の実施の形態のＳＩＰ ＩＮＶＩＴＥメッセージパケットの一例を示す図である。 第１の実施の形態のＳＩＰ １８３応答メッセージパケットの一例を示す図である。 第１の実施の形態のサービス情報通知パケットを示す図である。 第１の実施の形態のリソース認可要求パケットを示す図である。 第１の実施の形態のリソース認可応答又は拒絶パケットフォーマットを示す図である。 第１の実施の形態のＳＩＰメッセージプログラムのフローチャートである。 第１の実施の形態のセッション情報管理プログラムのフローチャートである。 第１の実施の形態のサービス情報管理プログラムのフローチャートである。 第１の実施の形態のＱｏＳポリシ決定プログラムのフローチャートである。 第１の実施の形態のベアラ確立開始時のＱｏＳ情報管理プログラムのフローチャートである。 第１の実施の形態のリソース認可応答パケット又はリソース認可拒絶パケットを受信したときのＱｏＳ情報管理プログラムのフローチャートである。 第１の実施の形態のセッション確立成功のシーケンス例を示す図である。 第２の実施の形態のセッション確立失敗のシーケンス例を示す図である。 第３の実施の形態のセッション確立失敗のシーケンス例を示す図である。 第４の実施の形態の通信方式ＱｏＳ情報テーブルの構成を示す図である。 第５の実施の形態の通信方式ＱｏＳ情報テーブルの構成を示す図である。 第６の実施の形態のサービス情報テーブルの構成を示す図である。 第７の実施の形態のサービス情報テーブルの構成を示す図である。 第７の実施の形態の基地局ＱｏＳ情報テーブルの構成を示す図である。 第８の実施の形態の基地局利用状況テーブルの構成を示す図である。

符号の説明

１ ＣＳＣＦ（呼制御サーバ）
２ ＰＣＲＦ（ＱｏＳポリシ決定サーバ）
３Ａ、３Ｂ ＡＧＷ（アクセスゲートウェイ）
５Ａ、５Ｂ ＡＰ（無線ＬＡＮ基地局）
６Ａ、６Ｂ ＢＳ（ＥＶ−ＤＯ基地局）
７ ＵＥ（ユーザ端末）
８ ＨＳＳ
６１、６２ ＡＳ（アプリケーションサーバ）
５１ コアネットワーク
５２、５３ アクセスネットワーク

Claims (20)

1. 端末からアクセスネットワークを経由して、サービスを提供するコアネットワークに接続するネットワークにおける、リソースの割当を制御するＱｏＳ制御システムであって、
   前記ＱｏＳ制御システムは、
   前記端末が要求するサービスに対してＱｏＳポリシを決定するＱｏＳポリシ決定サーバと、
   前記アクセスネットワークと前記コアネットワークとを接続するアクセスゲートウェイと、を備え、
   前記ＱｏＳポリシ決定サーバは、前記端末と前記アクセスネットワークとを接続する通信方式に基づいて、前記ＱｏＳポリシを決定することを特徴とするＱｏＳ制御システム。
2. 前記ＱｏＳポリシ決定サーバは、少なくとも前記アクセスネットワークに含まれる経路又は前記アクセスネットワークに含まれる経路と隣接する経路に適用するＱｏＳポリシを決定することを特徴とする請求項１に記載のＱｏＳ制御システム。
3. 前記ＱｏＳポリシ決定サーバは、前記端末が接続している通信方式の種別とＱｏＳポリシとの対応関係を保持し、前記対応関係を参照して前記ＱｏＳポリシを決定することを特徴とする請求項１に記載のＱｏＳ制御システム。
4. 前記ＱｏＳポリシ決定サーバは、前記端末に提供されるサービスのメディアタイプ及び前記端末へのサービスの提供に必要な帯域の少なくとも一方に基づいて、前記ＱｏＳポリシを決定することを特徴とする請求項１に記載のＱｏＳ制御システム。
5. 前記ＱｏＳ制御システムは、前記端末に使用されるセッションを管理する呼制御サーバを、さらに備え、
   前記ＱｏＳポリシ決定サーバは、セッションごとに前記ＱｏＳポリシを決定することを特徴とする請求項１に記載のＱｏＳ制御システム。
6. 前記呼制御サーバは、前記ＱｏＳポリシ決定サーバに前記通信方式の種別をセッションごとに通知することを特徴とする請求項５に記載のＱｏＳ制御システム。
7. 前記ＱｏＳポリシ決定サーバは、前記端末のユーザ識別子及び所属ドメインの少なくとも一方に基づいて、前記ＱｏＳポリシを決定することを特徴とする請求項１に記載のＱｏＳ制御システム。
8. 前記ＱｏＳポリシ決定サーバは、前記端末が通信する相手端末のユーザ識別子及び相手端末の所属ドメインの少なくとも一方に基づいて、前記ＱｏＳポリシを決定することを特徴とする請求項１に記載のＱｏＳ制御システム。
9. 前記ＱｏＳポリシ決定サーバは、前記端末が通信する通信方式の利用状態に基づいて、前記ＱｏＳポリシを決定することを特徴とする請求項１に記載のＱｏＳ制御システム。
10. 前記ＱｏＳポリシ決定サーバは、前記端末のＩＰアドレス及びポート番号が同一であっても、前記端末が通信している通信方式の種別ごとに前記ＱｏＳポリシを決定することを特徴とする請求項１に記載のＱｏＳ制御システム。
11. 端末からアクセスネットワークを経由して、サービスを提供するコアネットワークに接続するネットワークにおける、リソースの割当を制御するＱｏＳ制御システムであって、
    前記ＱｏＳ制御システムは、
    前記端末が要求するサービスに対してＱｏＳポリシを決定するＱｏＳポリシ決定サーバと、
    前記アクセスネットワークと前記コアネットワークとを接続するアクセスゲートウェイと、を備え、
    前記ＱｏＳポリシ決定サーバは、前記端末が接続する基地局の識別子に基づいて、前記ＱｏＳポリシを決定することを特徴とするＱｏＳ制御システム。
12. 前記ＱｏＳポリシ決定サーバは、少なくとも前記アクセスネットワークに含まれる経路又は前記アクセスネットワークに含まれる経路と隣接する経路に適用するＱｏＳポリシを決定することを特徴とする請求項１１に記載のＱｏＳ制御システム。
13. 前記ＱｏＳポリシ決定サーバは、前記基地局の識別子とＱｏＳポリシとの対応関係を保持し、前記対応関係を参照して前記ＱｏＳポリシを決定することを特徴とする請求項１１に記載のＱｏＳ制御システム。
14. 前記ＱｏＳポリシ決定サーバは、前記端末に提供されるサービスのメディアタイプ及び前記端末へのサービスの提供に必要な帯域の少なくとも一方に基づいて、前記ＱｏＳポリシを決定することを特徴とする請求項１１に記載のＱｏＳ制御システム。
15. 前記ＱｏＳ制御システムは、前記端末に使用されるセッションを管理する呼制御サーバを、さらに備え、
    前記ＱｏＳポリシ決定サーバは、セッションごとに前記ＱｏＳポリシを決定することを特徴とする請求項１１に記載のＱｏＳ制御システム。
16. 前記呼制御サーバは、前記ＱｏＳポリシ決定サーバに前記基地局の識別子をセッションごとに通知することを特徴とする請求項１５に記載のＱｏＳ制御システム。
17. 前記ＱｏＳポリシ決定サーバは、前記端末のユーザ識別子及び前記端末の所属ドメインの少なくとも一方に基づいて、前記ＱｏＳポリシを決定することを特徴とする請求項１１に記載のＱｏＳ制御システム。
18. 前記ＱｏＳポリシ決定サーバは、前記端末が通信する相手端末のユーザ識別子及び相手端末の所属ドメインの少なくとも一方に基づいて、前記ＱｏＳポリシを決定することを特徴とする請求項１１に記載のＱｏＳ制御システム。
19. 前記ＱｏＳポリシ決定サーバは、前記基地局の利用状態に基づいて、前記ＱｏＳポリシを決定することを特徴とする請求項１１に記載のＱｏＳ制御システム。
20. 前記ＱｏＳポリシ決定サーバは、前記端末のＩＰアドレス及びポート番号が同一であっても、前記端末が接続している基地局の識別子ごとに前記ＱｏＳポリシを決定することを特徴とする請求項１１に記載のＱｏＳ制御システム。

Images