JP4643712B2 - 回線ごとにＱｏＳを制御する通信制御装置、通信システム及びその制御方法 - Google Patents
回線ごとにＱｏＳを制御する通信制御装置、通信システム及びその制御方法 Download PDFInfo
- Publication number
- JP4643712B2 JP4643712B2 JP2008527677A JP2008527677A JP4643712B2 JP 4643712 B2 JP4643712 B2 JP 4643712B2 JP 2008527677 A JP2008527677 A JP 2008527677A JP 2008527677 A JP2008527677 A JP 2008527677A JP 4643712 B2 JP4643712 B2 JP 4643712B2
- Authority
- JP
- Japan
- Prior art keywords
- terminal
- session
- qos
- control signal
- access line
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
- 238000000034 method Methods 0.000 title claims description 58
- 238000004891 communication Methods 0.000 title claims description 43
- 230000004044 response Effects 0.000 claims description 66
- 230000008569 process Effects 0.000 claims description 39
- 238000012545 processing Methods 0.000 description 69
- 238000010586 diagram Methods 0.000 description 50
- 238000013475 authorization Methods 0.000 description 29
- 238000012217 deletion Methods 0.000 description 12
- 230000037430 deletion Effects 0.000 description 12
- 238000012546 transfer Methods 0.000 description 10
- 230000005540 biological transmission Effects 0.000 description 6
- 230000006870 function Effects 0.000 description 4
- 230000003287 optical effect Effects 0.000 description 3
- 239000000969 carrier Substances 0.000 description 2
- 238000012790 confirmation Methods 0.000 description 2
- 230000001960 triggered effect Effects 0.000 description 2
- 239000003795 chemical substances by application Substances 0.000 description 1
- 238000005516 engineering process Methods 0.000 description 1
- 239000000284 extract Substances 0.000 description 1
- 230000000977 initiatory effect Effects 0.000 description 1
- 230000006855 networking Effects 0.000 description 1
- 230000008520 organization Effects 0.000 description 1
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/10—Flow control; Congestion control
- H04L47/24—Traffic characterised by specific attributes, e.g. priority or QoS
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/10—Flow control; Congestion control
- H04L47/15—Flow control; Congestion control in relation to multipoint traffic
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/70—Admission control; Resource allocation
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/70—Admission control; Resource allocation
- H04L47/80—Actions related to the user profile or the type of traffic
- H04L47/805—QOS or priority aware
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/70—Admission control; Resource allocation
- H04L47/82—Miscellaneous aspects
- H04L47/824—Applicable to portable or mobile terminals
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/80—Responding to QoS
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Multimedia (AREA)
- Telephonic Communication Services (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Description
本願明細書で開示される技術は、サービス制御と連動してアクセス網のＱｏＳを制御する通信システムに関する。
近年、通信事業者の間でＮＧＮ（Ｎｅｘｔ Ｇｅｎｅｒａｔｉｏｎ Ｎｅｔｗｏｒｋ）と呼ばれる次世代基幹ＩＰ網を構築する動きが活発化している。従来、通信事業者は、移動／固定などのアクセス種別や、電話／放送／インターネットなどのサービス種別に応じて個別に網を構築していたが、ＮＧＮではこれらが全て共通のＩＰ網上に統合される。
ＮＧＮの標準化は、欧州の標準化団体ＥＴＳＩ（Ｅｕｒｏｐｅａｎ Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎｓ Ｓｔａｎｄａｒｄｓ Ｉｎｓｔｉｔｕｔｅ）のプロジェクトＴＩＳＰＡＮ（Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎｓ ａｎｄ Ｉｎｔｅｒｎｅｔ ｃｏｎｖｅｒｇｅｄ Ｓｅｒｖｉｃｅｓ ａｎｄ Ｐｒｏｔｏｃｏｌｓ Ｆｏｒ Ａｄｖａｎｃｅｄ Ｎｅｔｗｏｒｋｉｎｇ）、及び、ＩＴＵ−Ｔ（Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎ Ｕｎｉｏｎ−Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎ Ｓｔａｎｄａｒｄｉｚａｔｉｏｎ）のプロジェクトＦＧＮＧＮ（Ｆｏｃｕｓ Ｇｒｏｕｐ Ｎｅｘｔ Ｇｅｎｅｒａｔｉｏｎ Ｎｅｔｗｏｒｋ）で行われている。両機関は、パケット転送機能と、サービス制御機能とを分離して検討している。サービス制御に関しては、現在はＩＰ電話及びＴＶ会議等が主な検討対象になっており、プロトコルとしてＳＩＰ（Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）（ＩＥＴＦ ＲＦＣ３２６１）／ＳＤＰ（Ｓｅｓｓｉｏｎ Ｄｅｓｃｒｉｐｔｉｏｎ Ｐｒｏｔｏｃｏｌ）（ＩＥＴＦ ＲＦＣ２３２７）を採用することが決定している。
ＳＩＰによるサービス網の構成は、第三世代移動体通信の標準化団体である３ＧＰＰ（３ｒｄ Ｇｅｎｅｒａｔｉｏｎ Ｐａｒｔｎｅｒｓｈｉｐ Ｐｒｏｊｅｃｔ）／３ＧＰＰ２（３ｒｄ Ｇｅｎｅｒａｔｉｏｎ Ｐａｒｔｎｅｒｓｈｉｐ Ｐｒｏｊｅｃｔ２）が策定したＩＭＳ（ＩＰ Ｍｕｌｔｉｍｅｄｉａ Ｓｕｂｓｙｓｔｅｍ）／ＭＭＤ（Ｍｕｌｔｉｍｅｄｉａ Ｄｏｍａｉｎ）に準拠する方向で検討が進められている。
ＩＭＳ／ＭＭＤは、通常のセッション制御手順に加えて、セッション制御と連動したアクセス網ＱｏＳ制御手順（ＳＢＢＣ：Ｓｅｒｖｉｃｅ Ｂａｓｅｄ Ｂｅａｒｅｒ Ｃｏｎｔｒｏｌ）を規定している。ＳＢＢＣでは、ＳＩＰ ＳｅｒｖｅｒとＡＧＷ（Ａｃｃｅｓｓ Ｇａｔｅｗａｙ）の間にＱｏＳ Ｐｏｌｉｃｙ Ｓｅｒｖｅｒが設置される。ＱｏＳ Ｐｏｌｉｃｙ Ｓｅｒｖｅｒは、ＳＩＰ Ｓｅｒｖｅｒから通知されたサービス情報に基づいてＡＧＷのＱｏＳ設定を制御する。
ＳＢＢＣを実施する際のセッション確立手順を以下に示す。発信端末ｘは、まずＳＩＰ／ＳＤＰを使用して、着信端末ｙとメディア通信情報（ＩＰ Ａｄｄｒｅｓｓ、Ｐｏｒｔ、ＣＯＤＥＣ、使用帯域等）を交換する。ＳＩＰ Ｓｅｒｖｅｒは、中継したＳＩＰ／ＳＤＰメッセージから、メディアフローを識別するためのフィルタ（ＩＰ Ａｄｄｒｅｓｓ、Ｐｒｏｔｏｃｏｌ、Ｐｏｒｔ）、使用帯域、端末ＩＤを抽出し、ＱｏＳ Ｐｏｌｉｃｙ Ｓｅｒｖｅｒに通知する（以下、これらの情報をサービス情報と呼ぶ）。
次に端末ｘは、ＲＳＶＰを使用してＡＧＷにＱｏＳ設定を要求する。ＱｏＳ設定要求には、フローフィルタ（ＩＰ Ａｄｄｒｅｓｓ、Ｐｒｏｔｏｃｏｌ、Ｐｏｒｔ）、要求帯域及び端末ＩＤが含まれる。ＡＧＷは、これを受けてＱｏＳ認可要求をＱｏＳ Ｐｏｌｉｃｙ Ｓｅｒｖｅｒに送信する。ＱｏＳ Ｐｏｌｉｃｙ Ｓｅｒｖｅｒは、フローフィルタと端末ＩＤを比較キーとして、対応するサービス情報を検索する。サービス情報の帯域が、端末から要求された帯域よりも大きい場合、ＱｏＳ設定を認可し、その旨をＡＧＷに通知する。ＡＧＷは、これを受けてローカルのＱｏＳパラメータテーブルにフローフィルタと帯域を設定し、端末ｘに確認応答を返信する。端末ｘは、ＳＩＰ／ＳＤＰを使用して端末ｙにＱｏＳ設定の成功を通知し、セッション確立を完了する。
ＮＧＮの標準化は、欧州の標準化団体ＥＴＳＩ（Ｅｕｒｏｐｅａｎ Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎｓ Ｓｔａｎｄａｒｄｓ Ｉｎｓｔｉｔｕｔｅ）のプロジェクトＴＩＳＰＡＮ（Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎｓ ａｎｄ Ｉｎｔｅｒｎｅｔ ｃｏｎｖｅｒｇｅｄ Ｓｅｒｖｉｃｅｓ ａｎｄ Ｐｒｏｔｏｃｏｌｓ Ｆｏｒ Ａｄｖａｎｃｅｄ Ｎｅｔｗｏｒｋｉｎｇ）、及び、ＩＴＵ−Ｔ（Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎ Ｕｎｉｏｎ−Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎ Ｓｔａｎｄａｒｄｉｚａｔｉｏｎ）のプロジェクトＦＧＮＧＮ（Ｆｏｃｕｓ Ｇｒｏｕｐ Ｎｅｘｔ Ｇｅｎｅｒａｔｉｏｎ Ｎｅｔｗｏｒｋ）で行われている。両機関は、パケット転送機能と、サービス制御機能とを分離して検討している。サービス制御に関しては、現在はＩＰ電話及びＴＶ会議等が主な検討対象になっており、プロトコルとしてＳＩＰ（Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）（ＩＥＴＦ ＲＦＣ３２６１）／ＳＤＰ（Ｓｅｓｓｉｏｎ Ｄｅｓｃｒｉｐｔｉｏｎ Ｐｒｏｔｏｃｏｌ）（ＩＥＴＦ ＲＦＣ２３２７）を採用することが決定している。
ＳＩＰによるサービス網の構成は、第三世代移動体通信の標準化団体である３ＧＰＰ（３ｒｄ Ｇｅｎｅｒａｔｉｏｎ Ｐａｒｔｎｅｒｓｈｉｐ Ｐｒｏｊｅｃｔ）／３ＧＰＰ２（３ｒｄ Ｇｅｎｅｒａｔｉｏｎ Ｐａｒｔｎｅｒｓｈｉｐ Ｐｒｏｊｅｃｔ２）が策定したＩＭＳ（ＩＰ Ｍｕｌｔｉｍｅｄｉａ Ｓｕｂｓｙｓｔｅｍ）／ＭＭＤ（Ｍｕｌｔｉｍｅｄｉａ Ｄｏｍａｉｎ）に準拠する方向で検討が進められている。
ＩＭＳ／ＭＭＤは、通常のセッション制御手順に加えて、セッション制御と連動したアクセス網ＱｏＳ制御手順（ＳＢＢＣ：Ｓｅｒｖｉｃｅ Ｂａｓｅｄ Ｂｅａｒｅｒ Ｃｏｎｔｒｏｌ）を規定している。ＳＢＢＣでは、ＳＩＰ ＳｅｒｖｅｒとＡＧＷ（Ａｃｃｅｓｓ Ｇａｔｅｗａｙ）の間にＱｏＳ Ｐｏｌｉｃｙ Ｓｅｒｖｅｒが設置される。ＱｏＳ Ｐｏｌｉｃｙ Ｓｅｒｖｅｒは、ＳＩＰ Ｓｅｒｖｅｒから通知されたサービス情報に基づいてＡＧＷのＱｏＳ設定を制御する。
ＳＢＢＣを実施する際のセッション確立手順を以下に示す。発信端末ｘは、まずＳＩＰ／ＳＤＰを使用して、着信端末ｙとメディア通信情報（ＩＰ Ａｄｄｒｅｓｓ、Ｐｏｒｔ、ＣＯＤＥＣ、使用帯域等）を交換する。ＳＩＰ Ｓｅｒｖｅｒは、中継したＳＩＰ／ＳＤＰメッセージから、メディアフローを識別するためのフィルタ（ＩＰ Ａｄｄｒｅｓｓ、Ｐｒｏｔｏｃｏｌ、Ｐｏｒｔ）、使用帯域、端末ＩＤを抽出し、ＱｏＳ Ｐｏｌｉｃｙ Ｓｅｒｖｅｒに通知する（以下、これらの情報をサービス情報と呼ぶ）。
次に端末ｘは、ＲＳＶＰを使用してＡＧＷにＱｏＳ設定を要求する。ＱｏＳ設定要求には、フローフィルタ（ＩＰ Ａｄｄｒｅｓｓ、Ｐｒｏｔｏｃｏｌ、Ｐｏｒｔ）、要求帯域及び端末ＩＤが含まれる。ＡＧＷは、これを受けてＱｏＳ認可要求をＱｏＳ Ｐｏｌｉｃｙ Ｓｅｒｖｅｒに送信する。ＱｏＳ Ｐｏｌｉｃｙ Ｓｅｒｖｅｒは、フローフィルタと端末ＩＤを比較キーとして、対応するサービス情報を検索する。サービス情報の帯域が、端末から要求された帯域よりも大きい場合、ＱｏＳ設定を認可し、その旨をＡＧＷに通知する。ＡＧＷは、これを受けてローカルのＱｏＳパラメータテーブルにフローフィルタと帯域を設定し、端末ｘに確認応答を返信する。端末ｘは、ＳＩＰ／ＳＤＰを使用して端末ｙにＱｏＳ設定の成功を通知し、セッション確立を完了する。
上記のＱｏＳ制御手順は、主に移動網を想定して標準化が行われている。しかしながら、ＮＧＮでは、アクセス非依存のサービス網を構築するため、将来は固定網においても同様のアーキテクチャが導入されると予想される。
移動アクセス網では、ＱｏＳリソースを端末ごとに確保する。これに対し、固定アクセス網では、ＱｏＳリソースを回線（家庭）ごとに確保し、回線リソースを複数の端末が共有する。そのためＱｏＳ Ｐｏｌｉｃｙ Ｓｅｒｖｅｒは、回線ごとに使用する帯域と、回線に対して課せられた制約条件（回線の保証帯域等）とを考慮してＱｏＳ認可を実行する必要がある。ところが、上記で説明したＱｏＳ制御手順では、回線を識別するための情報が、ＳＩＰ／ＱｏＳ設定要求のいずれにも含まれない。従って、ＱｏＳ Ｐｏｌｉｃｙ Ｓｅｒｖｅｒは、回線ごとに使用する帯域の合計を計算できないという課題がある（第一の課題）。
また、移動アクセス網では、端末がアクセス網に接続する際に端末認証が実行される。そのため、通信事業者と信頼関係のある端末のみが、ＱｏＳ設定要求をＡＧＷに送信することができる。一方、固定アクセス網では、端末はホーム網に収容され、ＨＧＷ（Ｈｏｍｅ Ｇａｔｅｗａｙ）等の通信機器を介して通信事業者のアクセス網に接続する。通信事業者は、ＨＧＷの認証は実行するが、端末の認証は実行しない。そのため、移動アクセス網と同様に端末からＱｏＳ設定要求を送信するアーキテクチャを採用した場合、通信事業者と信頼関係のない端末がＡＧＷのＱｏＳ設定を制御することになり、セキュリティ上問題がある（第二の課題）。
本願で開示する代表的な発明は、アクセス回線を介して通信網に接続される複数の端末と、前記端末から送信されたセッション制御信号を処理するセッション制御サーバと、前記アクセス回線のＱｏＳを制御するＱｏＳ制御サーバと、を備える通信システムにおいて、前記端末は、少なくとも、前記端末がセッションにおいて要求する帯域を示す情報を含む前記セッション制御信号を前記セッション制御サーバに送信し、前記端末は、さらに、前記アクセス回線の識別子を前記セッション制御サーバに送信し、前記セッション制御サーバは、受信した前記アクセス回線の識別子と、前記端末がセッションにおいて要求する帯域を示す情報とを前記ＱｏＳ制御サーバに送信し、前記ＱｏＳ制御サーバは、同一の前記アクセス回線の識別子と関連付けられたセッションにおいて要求される帯域に基づいてＱｏＳを制御することを特徴とする。
本発明の一実施形態によれば、回線ごとにＱｏＳを制御することができる。
また、本発明の一実施形態によれば、通信事業者と信頼関係のある機器のみがＡＧＷのＱｏＳ設定を制御するシステムを構成することができる。
移動アクセス網では、ＱｏＳリソースを端末ごとに確保する。これに対し、固定アクセス網では、ＱｏＳリソースを回線（家庭）ごとに確保し、回線リソースを複数の端末が共有する。そのためＱｏＳ Ｐｏｌｉｃｙ Ｓｅｒｖｅｒは、回線ごとに使用する帯域と、回線に対して課せられた制約条件（回線の保証帯域等）とを考慮してＱｏＳ認可を実行する必要がある。ところが、上記で説明したＱｏＳ制御手順では、回線を識別するための情報が、ＳＩＰ／ＱｏＳ設定要求のいずれにも含まれない。従って、ＱｏＳ Ｐｏｌｉｃｙ Ｓｅｒｖｅｒは、回線ごとに使用する帯域の合計を計算できないという課題がある（第一の課題）。
また、移動アクセス網では、端末がアクセス網に接続する際に端末認証が実行される。そのため、通信事業者と信頼関係のある端末のみが、ＱｏＳ設定要求をＡＧＷに送信することができる。一方、固定アクセス網では、端末はホーム網に収容され、ＨＧＷ（Ｈｏｍｅ Ｇａｔｅｗａｙ）等の通信機器を介して通信事業者のアクセス網に接続する。通信事業者は、ＨＧＷの認証は実行するが、端末の認証は実行しない。そのため、移動アクセス網と同様に端末からＱｏＳ設定要求を送信するアーキテクチャを採用した場合、通信事業者と信頼関係のない端末がＡＧＷのＱｏＳ設定を制御することになり、セキュリティ上問題がある（第二の課題）。
本願で開示する代表的な発明は、アクセス回線を介して通信網に接続される複数の端末と、前記端末から送信されたセッション制御信号を処理するセッション制御サーバと、前記アクセス回線のＱｏＳを制御するＱｏＳ制御サーバと、を備える通信システムにおいて、前記端末は、少なくとも、前記端末がセッションにおいて要求する帯域を示す情報を含む前記セッション制御信号を前記セッション制御サーバに送信し、前記端末は、さらに、前記アクセス回線の識別子を前記セッション制御サーバに送信し、前記セッション制御サーバは、受信した前記アクセス回線の識別子と、前記端末がセッションにおいて要求する帯域を示す情報とを前記ＱｏＳ制御サーバに送信し、前記ＱｏＳ制御サーバは、同一の前記アクセス回線の識別子と関連付けられたセッションにおいて要求される帯域に基づいてＱｏＳを制御することを特徴とする。
本発明の一実施形態によれば、回線ごとにＱｏＳを制御することができる。
また、本発明の一実施形態によれば、通信事業者と信頼関係のある機器のみがＡＧＷのＱｏＳ設定を制御するシステムを構成することができる。
第１図は、本発明の第１の実施の形態における通信網の構成例を示す説明図である。
第２図Ａは、本発明の第１の実施の形態のＳＩＰ Ｓｅｒｖｅｒの装置構成を示すブロック図である。
第２図Ｂは、本発明の第１の実施の形態のＳＩＰ Ｓｅｒｖｅｒが保持するＳＩＰ Ｓｅｓｓｉｏｎ Ｔａｂｌｅの説明図である。
第３図Ａは、本発明の第１の実施の形態のＱｏＳ Ｐｏｌｉｃｙ Ｓｅｒｖｅｒの装置構成を示すブロック図である。
第３図Ｂは、本発明の第１の実施の形態のＱｏＳ Ｐｏｌｉｃｙ Ｓｅｒｖｅｒが保持するＳｅｒｖｉｃｅ Ｉｎｆｏｒｍａｔｉｏｎ Ｔａｂｌｅの説明図である。
第３図Ｃは、本発明の第１の実施の形態のＱｏＳ Ｐｏｌｉｃｙ Ｓｅｒｖｅｒが保持するＦｌｏｗ Ｔａｂｌｅの説明図である。
第３図Ｄは、本発明の第１の実施の形態のＱｏＳ Ｐｏｌｉｃｙ Ｓｅｒｖｅｒが保持するＬｉｎｅ Ｔａｂｌｅの説明図である。
第４図Ａは、本発明の第１の実施の形態のＨＧＷの装置構成を示すブロック図である。
第４図Ｂは、本発明の第１の実施の形態のＨＧＷが保持するＳＩＰ Ｓｅｓｓｉｏｎ Ｔａｂｌｅの説明図である。
第４図Ｃは、本発明の第１の実施の形態のＨＧＷが保持するＦｌｏｗ Ｔａｂｌｅの説明図である。
第４図Ｄは、本発明の第１の実施の形態のＨＧＷが保持するＲＳＶＰ Ｓｅｓｓｉｏｎ Ｔａｂｌｅの説明図である。
第５図は、本発明の第１の実施の形態におけるセッション確立のための処理を示すシーケンス図である。
第６図は、本発明の第１の実施の形態のＨＧＷによってＬｉｎｅ−ＩＤを追加されたＳＩＰ ＩＮＶＩＴＥの例を示す説明図である。
第７図Ａは、本発明の第１の実施の形態において送信されるＲＳＶＰ Ｒｅｓｖのパケットフォーマットの説明図である。
第７図Ｂは、本発明の第１の実施の形態において送信されるＲＳＶＰ Ｒｅｓｖのパケットフォーマットの説明図である。
第８図は、本発明の第１の実施の形態のＨＧＷが実行するＬｉｎｅ−ＩＤ追加判定処理を示すフローチャートである。
第９図は、本発明の第１の実施の形態のＳＩＰ Ｓｅｒｖｅｒが実行するサービス情報通知処理を示すフローチャートである。
第１０図は、本発明の第１の実施の形態のＨＧＷが実行するＦｌｏｗ登録／ＲＳＶＰ Ｒｅｓｖ送信処理を示すフローチャートである。
第１１図は、本発明の第１の実施の形態のＨＧＷが実行するＲＳＶＰ Ｒｅｓｖ受信処理を示すフローチャートである。
第１２図は、本発明の第１の実施の形態のＱｏＳ Ｐｏｌｉｃｙ Ｓｅｒｖｅｒが実行するＦｌｏｗ認可処理を示すフローチャートである。
第１３図は、本発明の第１の実施の形態のＨＧＷが実行するＲＳＶＰ ＲｅｓｖＣｏｎｆ受信処理を示すフローチャートである。
第１４図は、本発明の第１の実施の形態におけるセッション切断のための処理を示すシーケンス図である。
第１５図は、本発明の第１の実施の形態のＱｏＳ Ｐｏｌｉｃｙ Ｓｅｒｖｅｒが実行するサービス情報／Ｆｌｏｗ認可削除処理を示すフローチャートである。
第１６図Ａは、本発明の第２の実施の形態のＳＩＰ Ｓｅｒｖｅｒが保持するＲｅｇｉｓｔｒａｔｉｏｎ Ｔａｂｌｅの説明図である。
第１６図Ｂは、本発明の第２の実施の形態のＳＩＰ Ｓｅｒｖｅｒが保持するＳＩＰ Ｓｅｓｓｉｏｎ Ｔａｂｌｅの説明図である。
第１７図は、本発明の第２の実施の形態におけるセッション確立のための処理を示すシーケンス図である。
第１８図は、本発明の第２の実施の形態のＨＧＷが実行するＬｉｎｅ−ＩＤ追加判定処理を示すフローチャートである。
第１９図は、本発明の第２の実施の形態のＳＩＰ Ｓｅｒｖｅｒが実行するサービス情報通知処理を示すフローチャートである。
第２０図は、本発明の第３の実施の形態における通信網の構成例を示す説明図である。
第２１図Ａは、本発明の第３の実施の形態のＱｏＳ Ｐｏｌｉｃｙ Ｓｅｒｖｅｒの装置構成を示すブロック図である。
第２１図Ｂは、本発明の第３の実施の形態のＱｏＳ Ｐｏｌｉｃｙ Ｓｅｒｖｅｒが保持するＳｅｒｖｉｃｅ Ｉｎｆｏｒｍａｔｉｏｎ Ｔａｂｌｅの説明図である。
第２１図Ｃは、本発明の第３の実施の形態のＱｏＳ Ｐｏｌｉｃｙ Ｓｅｒｖｅｒが保持するＬｉｎｅ Ｔａｂｌｅの説明図である。
第２２図Ａは、本発明の第３の実施の形態におけるセッション確立のための処理を示すシーケンス図である。
第２２図Ｂは、本発明の第３の実施の形態におけるセッション確立のための処理を示すシーケンス図である。
第２３図は、本発明の第３の実施の形態のＱｏＳ Ｐｏｌｉｃｙ Ｓｅｒｖｅｒが実行するサービス認可処理を説明するフローチャートである。
第２４図は、本発明の第３の実施の形態におけるセッション切断のために実行される処理を示すシーケンス図である。
第２５図は、本発明の第３の実施の形態のＱｏＳ Ｐｏｌｉｃｙ Ｓｅｒｖｅｒが実行するサービス認可削除処理を説明するフローチャートである。
第２図Ａは、本発明の第１の実施の形態のＳＩＰ Ｓｅｒｖｅｒの装置構成を示すブロック図である。
第２図Ｂは、本発明の第１の実施の形態のＳＩＰ Ｓｅｒｖｅｒが保持するＳＩＰ Ｓｅｓｓｉｏｎ Ｔａｂｌｅの説明図である。
第３図Ａは、本発明の第１の実施の形態のＱｏＳ Ｐｏｌｉｃｙ Ｓｅｒｖｅｒの装置構成を示すブロック図である。
第３図Ｂは、本発明の第１の実施の形態のＱｏＳ Ｐｏｌｉｃｙ Ｓｅｒｖｅｒが保持するＳｅｒｖｉｃｅ Ｉｎｆｏｒｍａｔｉｏｎ Ｔａｂｌｅの説明図である。
第３図Ｃは、本発明の第１の実施の形態のＱｏＳ Ｐｏｌｉｃｙ Ｓｅｒｖｅｒが保持するＦｌｏｗ Ｔａｂｌｅの説明図である。
第３図Ｄは、本発明の第１の実施の形態のＱｏＳ Ｐｏｌｉｃｙ Ｓｅｒｖｅｒが保持するＬｉｎｅ Ｔａｂｌｅの説明図である。
第４図Ａは、本発明の第１の実施の形態のＨＧＷの装置構成を示すブロック図である。
第４図Ｂは、本発明の第１の実施の形態のＨＧＷが保持するＳＩＰ Ｓｅｓｓｉｏｎ Ｔａｂｌｅの説明図である。
第４図Ｃは、本発明の第１の実施の形態のＨＧＷが保持するＦｌｏｗ Ｔａｂｌｅの説明図である。
第４図Ｄは、本発明の第１の実施の形態のＨＧＷが保持するＲＳＶＰ Ｓｅｓｓｉｏｎ Ｔａｂｌｅの説明図である。
第５図は、本発明の第１の実施の形態におけるセッション確立のための処理を示すシーケンス図である。
第６図は、本発明の第１の実施の形態のＨＧＷによってＬｉｎｅ−ＩＤを追加されたＳＩＰ ＩＮＶＩＴＥの例を示す説明図である。
第７図Ａは、本発明の第１の実施の形態において送信されるＲＳＶＰ Ｒｅｓｖのパケットフォーマットの説明図である。
第７図Ｂは、本発明の第１の実施の形態において送信されるＲＳＶＰ Ｒｅｓｖのパケットフォーマットの説明図である。
第８図は、本発明の第１の実施の形態のＨＧＷが実行するＬｉｎｅ−ＩＤ追加判定処理を示すフローチャートである。
第９図は、本発明の第１の実施の形態のＳＩＰ Ｓｅｒｖｅｒが実行するサービス情報通知処理を示すフローチャートである。
第１０図は、本発明の第１の実施の形態のＨＧＷが実行するＦｌｏｗ登録／ＲＳＶＰ Ｒｅｓｖ送信処理を示すフローチャートである。
第１１図は、本発明の第１の実施の形態のＨＧＷが実行するＲＳＶＰ Ｒｅｓｖ受信処理を示すフローチャートである。
第１２図は、本発明の第１の実施の形態のＱｏＳ Ｐｏｌｉｃｙ Ｓｅｒｖｅｒが実行するＦｌｏｗ認可処理を示すフローチャートである。
第１３図は、本発明の第１の実施の形態のＨＧＷが実行するＲＳＶＰ ＲｅｓｖＣｏｎｆ受信処理を示すフローチャートである。
第１４図は、本発明の第１の実施の形態におけるセッション切断のための処理を示すシーケンス図である。
第１５図は、本発明の第１の実施の形態のＱｏＳ Ｐｏｌｉｃｙ Ｓｅｒｖｅｒが実行するサービス情報／Ｆｌｏｗ認可削除処理を示すフローチャートである。
第１６図Ａは、本発明の第２の実施の形態のＳＩＰ Ｓｅｒｖｅｒが保持するＲｅｇｉｓｔｒａｔｉｏｎ Ｔａｂｌｅの説明図である。
第１６図Ｂは、本発明の第２の実施の形態のＳＩＰ Ｓｅｒｖｅｒが保持するＳＩＰ Ｓｅｓｓｉｏｎ Ｔａｂｌｅの説明図である。
第１７図は、本発明の第２の実施の形態におけるセッション確立のための処理を示すシーケンス図である。
第１８図は、本発明の第２の実施の形態のＨＧＷが実行するＬｉｎｅ−ＩＤ追加判定処理を示すフローチャートである。
第１９図は、本発明の第２の実施の形態のＳＩＰ Ｓｅｒｖｅｒが実行するサービス情報通知処理を示すフローチャートである。
第２０図は、本発明の第３の実施の形態における通信網の構成例を示す説明図である。
第２１図Ａは、本発明の第３の実施の形態のＱｏＳ Ｐｏｌｉｃｙ Ｓｅｒｖｅｒの装置構成を示すブロック図である。
第２１図Ｂは、本発明の第３の実施の形態のＱｏＳ Ｐｏｌｉｃｙ Ｓｅｒｖｅｒが保持するＳｅｒｖｉｃｅ Ｉｎｆｏｒｍａｔｉｏｎ Ｔａｂｌｅの説明図である。
第２１図Ｃは、本発明の第３の実施の形態のＱｏＳ Ｐｏｌｉｃｙ Ｓｅｒｖｅｒが保持するＬｉｎｅ Ｔａｂｌｅの説明図である。
第２２図Ａは、本発明の第３の実施の形態におけるセッション確立のための処理を示すシーケンス図である。
第２２図Ｂは、本発明の第３の実施の形態におけるセッション確立のための処理を示すシーケンス図である。
第２３図は、本発明の第３の実施の形態のＱｏＳ Ｐｏｌｉｃｙ Ｓｅｒｖｅｒが実行するサービス認可処理を説明するフローチャートである。
第２４図は、本発明の第３の実施の形態におけるセッション切断のために実行される処理を示すシーケンス図である。
第２５図は、本発明の第３の実施の形態のＱｏＳ Ｐｏｌｉｃｙ Ｓｅｒｖｅｒが実行するサービス認可削除処理を説明するフローチャートである。
第１図は、本発明の第１の実施の形態における通信網の構成例を示す説明図である。
第１図の通信網は、アクセス非依存のサービス網１４、移動アクセス網１５、固定アクセス網１６及びホーム網１７によって構成される。ホーム網１７は、固定アクセス網１６に接続されている。
サービス網１４は、ＳＩＰ Ｓｅｒｖｅｒ（１、２及び３）、ＱｏＳ Ｐｏｌｉｃｙ Ｓｅｒｖｅｒ（４及び５）及びＡＧＷ（６及び７）を備える。ＳＩＰ Ｓｅｒｖｅｒ１は、ＳＩＰ ＲｅｇｉｓｔｒａｒおよびＰｒｏｘｙとして動作し、端末のロケーション管理とサービス制御を行う。ＳＩＰ Ｓｅｒｖｅｒ２及び３は、ＳＩＰ Ｐｒｏｘｙとして動作し、それぞれ、移動アクセス網１５及び固定アクセス網１６の端末を収容する。ＩＭＳ／ＭＭＤでは、ＳＩＰ Ｓｅｒｖｅｒ１をＳ−ＣＳＣＦ（Ｓｅｒｖｉｎｇ Ｃａｌｌ Ｓｅｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｆｕｎｃｔｉｏｎ）、ＳＩＰ Ｓｅｒｖｅｒ（２及び３）をＰ−ＣＳＣＦ（Ｐｒｏｘｙ Ｃａｌｌ Ｓｅｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｆｕｎｃｔｉｏｎ）と呼ぶ。
ＱｏＳ Ｐｏｌｉｃｙ Ｓｅｒｖｅｒ（４及び５）は、ＳＩＰ Ｓｅｒｖｅｒ（２及び３）から通知されたサービス情報に基づいて、ＡＧＷ（６及び７）のＱｏＳ（サービス品質）設定を制御する。
ＡＧＷ（６及び７）は、それぞれ、移動アクセス網１５とサービス網１４との境界、及び、固定アクセス網１６とサービス網１４との境界に設置され、各アクセス網の端末を収容する。
移動アクセス網１５は、ＵＡ（Ｕｓｅｒ Ａｇｅｎｔ）８を収容する。ＵＡ８には、ＳＩＰ ＵＲＩ（ｓｉｐ：ｕａ８＠ｈｉｔａｃｈｉ．ｃｏｍ）が設定されている。
固定アクセス網１６は、アクセス設備としてＰＯＮ（Ｐａｓｓｉｖｅ Ｏｐｔｉｃａｌ Ｎｅｔｗｏｒｋ）を使用しており、ＯＬＴ（Ｏｐｔｉｃａｌ Ｌｉｎｅ Ｔｅｒｍｉｎａｌ）９及びＯＮＵ（Ｏｐｔｉｃａｌ Ｎｅｔｗｏｒｋ Ｕｎｉｔ）１０を備える。
ホーム網１７は、ＨＧＷ１１、ＵＡ（１２及び１３）を備える。ＨＧＷ１１には、回線を識別するためのＩＤ（Ｌｉｎｅ−ＩＤ：１２３４５６）が設定されている。ＵＡ（１２及び１３）には、ＳＩＰ ＵＲＩ（それぞれ、ｓｉｐ：ｕａ１２＠ｈｉｔａｃｈｉ．ｃｏｍ、及び、ｓｉｐ：ｕａ１３＠ｈｉｔａｃｈｉ．ｃｏｍ）が設定されている。
固定アクセス網１６では、次のようなＱｏＳ処理を行う。ＡＧＷ７及びＨＧＷ１１は、Ｌａｙｅｒ３以上でフロー単位の帯域保証を行う。また、ＡＧＷ７及びＨＧＷ１１は、優先フローを識別し、ＩＰｖ４ヘッダのＴＯＳ（Ｔｙｐｅ ｏｆ Ｓｅｒｖｉｃｅ）フィールド又はＩＰｖ６ヘッダのＴｒａｆｆｉｃ Ｃｌａｓｓフィールドにマーキングを行う。フローを識別するためのフィルタ情報及び保証帯域は、セッション確立時に動的に設定される。
ＯＬＴ９及びＯＮＵ１０は、Ｌａｙｅｒ２レベルで優先フローの帯域保証を行う。優先フローの識別は、ＡＧＷ７及びＨＧＷ１１によるマーキングの結果に従う。保証帯域は、必要に応じて、ＱｏＳ Ｐｏｌｉｃｙ Ｓｅｒｖｅｒ５が制御する。
第２図Ａは、本発明の第１の実施の形態のＳＩＰ Ｓｅｒｖｅｒ３の装置構成を示すブロック図である。
ＳＩＰ Ｓｅｒｖｅｒ３は、Ｈａｒｄ Ｄｉｓｋ３１、ＣＰＵ３２、Ｍｅｍｏｒｙ３３、ＩＦ（３４ａ、３４ｂ及び３４ｃ）及びバス３５を備える。ＳＩＰ Ｓｅｒｖｅｒ３の処理手順は、Ｍｅｍｏｒｙ ３３に格納されており、ＣＰＵ３２が順次それを読み出して実行する。
ＳＩＰ Ｓｅｒｖｅｒ３は、ＳＩＰ Ｓｅｓｓｉｏｎを管理するために、第２図Ｂに示すＳＩＰ Ｓｅｓｓｉｏｎ Ｔａｂｌｅを保持する。ＳＩＰ Ｓｅｓｓｉｏｎ Ｔａｂｌｅは、Ｈａｒｄ Ｄｉｓｋ３１又はＭｅｍｏｒｙ３３に格納される。
第２図Ｂは、本発明の第１の実施の形態のＳＩＰ Ｓｅｒｖｅｒ３が保持するＳＩＰ Ｓｅｓｓｉｏｎ Ｔａｂｌｅの説明図である。
ＳＩＰ Ｓｅｓｓｉｏｎ Ｔａｂｌｅ（第２図Ｂ）は、ＳＩＰ Ｓｅｓｓｉｏｎを一意に識別するＳＩＰ Ｄｉａｌｏｇ ＩＤ７１、発信端末情報（すなわち、発信側の端末を識別する情報）を示すＣａｌｌｅｒ’ｓ ＩＤ７２、着信端末情報（すなわち、着信側の端末を識別する情報）を示すＣａｌｌｅｅ’ｓ ＩＤ７３、セッション状態を示すＳｔａｔｅ７４、ＳＤＰ Ｏｆｆｅｒ７５、及び、ＳＤＰ Ａｎｓｗｅｒ７６から構成される。
ＳＩＰ Ｄｉａｌｏｇ７１は、Ｃａｌｌ−ＩＤ７１ａ、Ｆｒｏｍ ｔａｇ７１ｂ及びＴｏ ｔａｇ７１ｃから構成される。Ｃａｌｌｅｒ’ｓ ＩＤ７２は、Ｆｒｏｍ ＵＲＩ７２ａ及びＬｉｎｅ−ＩＤ７２ｂから構成される。Ｃａｌｌｅｅ’ｓ ＩＤ７３は、Ｔｏ ＵＲＩ７３ａ及びＬｉｎｅ−ＩＤ７３ｂから構成される。ＳＩＰ Ｓｅｒｖｅｒ３は、ＳＩＰ Ｍｅｓｓａｇｅ転送時にこれらのパラメータを取得し、取得したパラメータをＳＩＰ Ｓｅｓｓｉｏｎ Ｔａｂｌｅに設定する。
第３図Ａは、本発明の第１の実施の形態のＱｏＳ Ｐｏｌｉｃｙ Ｓｅｒｖｅｒ５の装置構成を示すブロック図である。
ＱｏＳ Ｐｏｌｉｃｙ Ｓｅｒｖｅｒ５は、Ｈａｒｄ Ｄｉｓｋ４１、ＣＰＵ４２、Ｍｅｍｏｒｙ４３、ＩＦ（４４ａ、４４ｂ及び４４ｃ）及びバス４５を備える。ＱｏＳ Ｐｏｌｉｃｙ Ｓｅｒｖｅｒ５の処理手順は、Ｍｅｍｏｒｙ ４３に格納されており、ＣＰＵ４２が順次それを読み出して実行する。
ＱｏＳ Ｐｏｌｉｃｙ Ｓｅｒｖｅｒ５は、第３図Ｂに示すＳｅｒｖｉｃｅ Ｉｎｆｏｒｍａｔｉｏｎ Ｔａｂｌｅ、第３図Ｃに示すＦｌｏｗ Ｔａｂｌｅ、及び、第３図Ｄに示すＬｉｎｅ Ｔａｂｌｅを保持する。これらのテーブルは、Ｈａｒｄ Ｄｉｓｋ４１又はＭｅｍｏｒｙ ４３に格納される。
第３図Ｂは、本発明の第１の実施の形態のＱｏＳ Ｐｏｌｉｃｙ Ｓｅｒｖｅｒ５が保持するＳｅｒｖｉｃｅ Ｉｎｆｏｒｍａｔｉｏｎ Ｔａｂｌｅの説明図である。
Ｓｅｒｖｉｃｅ Ｉｎｆｏｒｍａｔｉｏｎ Ｔａｂｌｅ（第３図Ｂ）は、ＳＩＰ Ｓｅｒｖｅｒ３から通知されたサービス情報を管理するためのテーブルである。Ｓｅｒｖｉｃｅ Ｉｎｆｏｒｍａｔｉｏｎ Ｔａｂｌｅ（第３図Ｂ）は、ＳＩＰ Ｓｅｓｓｉｏｎを識別するＳｅｓｓｉｏｎ ＩＤ９１、回線を識別するＬｉｎｅ−ＩＤ９２、端末を識別するＴｅｒｍｉｎａｌ−ＩＤ９３、フローを識別するＦｌｏｗ Ｆｉｌｔｅｒ９４、フローの使用帯域を示すＢａｎｄｗｉｄｔｈ９５、及び、サービス情報に関連付けられたフロー（第３図Ｃに示すＦｌｏｗ Ｔａｂｌｅ）へのポインタＰｏｉｎｔｅｒ ｔｏ Ｆｌｏｗ Ｔａｂｌｅ９６から構成される。
Ｆｌｏｗ Ｆｉｌｔｅｒ９４は、Ｓｒｃ ＩＰ９４ａ、Ｄｓｔ ＩＰ９４ｂ、ｐｒｏｔｏ９４ｃ、Ｓｒｃ Ｐｏｒｔ９４ｄ、及び、Ｄｓｔ Ｐｏｒｔ９４ｅから構成される。 第３図Ｃは、本発明の第１の実施の形態のＱｏＳ Ｐｏｌｉｃｙ Ｓｅｒｖｅｒ５が保持するＦｌｏｗ Ｔａｂｌｅの説明図である。
Ｆｌｏｗ Ｔａｂｌｅ（第３図Ｃ）は、ＡＧＷ７に認可したフローを管理するためのテーブルである。Ｆｌｏｗ Ｔａｂｌｅ（第３図Ｃ）は、回線を識別するＬｉｎｅ−ＩＤ１１１、端末を識別するＴｅｒｍｉｎａｌ−ＩＤ１１２、フローを識別するＦｌｏｗ Ｆｉｌｔｅｒ１１３、要求帯域を示すＢａｎｄｗｉｄｔｈ１１４、及び、フローに関連付けられたサービス情報（第３図Ｂに示すＳｅｒｖｉｃｅ Ｉｎｆｏｒｍａｔｉｏｎ Ｔａｂｌｅ）へのポインタＰｏｉｎｔｅｒ ｔｏ Ｓｅｒｖｉｃｅ Ｉｎｆｏ． Ｔａｂｌｅ１１５から構成される。
Ｆｌｏｗ Ｆｉｌｔｅｒ１１３は、Ｓｒｃ ＩＰ１１３ａ、Ｄｓｔ ＩＰ１１３ｂ、ｐｒｏｔｏ１１３ｃ、Ｓｒｃ Ｐｏｒｔ１１３ｄ、及び、Ｄｓｔ Ｐｏｒｔ１１３ｅから構成される。
第３図Ｄは、本発明の第１の実施の形態のＱｏＳ Ｐｏｌｉｃｙ Ｓｅｒｖｅｒ５が保持するＬｉｎｅ Ｔａｂｌｅの説明図である。
Ｌｉｎｅ Ｔａｂｌｅ（第３図Ｄ）は、各回線の帯域を管理するためのテーブルである。Ｌｉｎｅ Ｔａｂｌｅ（第３図Ｄ）は、回線を識別するＬｉｎｅ−ＩＤ１３１、ＯＮＵを識別するＯＮＵ−ＩＤ１３２、ＯＬＴを識別するＯＬＴ−ＩＤ１３３、回線の最低保証帯域Ｍｉｎ Ｂａｎｄｗｉｄｔｈ１３４、最大保証帯域Ｍａｘ Ｂａｎｄｗｉｄｔｈ１３５、現在帯域Ｃｕｒｒｅｎｔ Ｂａｎｄｗｉｄｔｈ１３６、及び、回線を使用するフロー（第３図Ｃに示すＦｌｏｗ Ｔａｂｌｅ）へのポインタＰｏｉｎｔｅｒ ｔｏ Ｆｌｏｗ Ｔａｂｌｅ１３７から構成される。回線を使用するフローが複数存在する場合、Ｐｏｉｎｔｅｒ ｔｏ Ｆｌｏｗ Ｔａｂｌｅ１３７には複数のポインタが設定される。
第４図Ａは、本発明の第１の実施の形態のＨＧＷ１１の装置構成を示すブロック図である。
ＨＧＷ１１は、ＦＲＯＭ（Ｆｌｕｓｈ ＲＯＭ）５１、ＣＰＵ５２、Ｍｅｍｏｒｙ５３、ＩＦ（５４ａ、５４ｂ及び５４ｃ）及びバス５５を備える。ＨＧＷ１１の処理手順は、Ｍｅｍｏｒｙ ５３に格納されており、ＣＰＵ５２が順次それを読み出して実行する。
ＨＧＷ１１は、第４図Ｂに示すＳＩＰ Ｓｅｓｓｉｏｎ Ｔａｂｌｅ、第４図Ｃに示すＦｌｏｗ Ｔａｂｌｅ、第４図Ｄに示すＲＳＶＰ Ｓｅｓｓｉｏｎ Ｔａｂｌｅを保持する。これらのテーブルは、ＦＲＯＭ５１又はＭｅｍｏｒｙ５３に格納される。
第４図Ｂは、本発明の第１の実施の形態のＨＧＷ１１が保持するＳＩＰ Ｓｅｓｓｉｏｎ Ｔａｂｌｅの説明図である。
ＳＩＰ Ｓｅｓｓｉｏｎ Ｔａｂｌｅ（第４図Ｂ）は、ＳＩＰ Ｓｅｓｓｉｏｎを管理するためのテーブルである。ＳＩＰ Ｓｅｓｓｉｏｎ Ｔａｂｌｅ（第４図Ｂ）は、ＳＩＰ Ｓｅｓｓｉｏｎを識別するＳＩＰ Ｄｉａｌｏｇ ＩＤ１５１、発信端末を識別するＦｒｏｍ ＵＲＩ１５２、着信端末を識別するＴｏ ＵＲＩ１５３、セッション状態を示すＳｔａｔｅ１５４、ＳＤＰ Ｏｆｆｅｒ１５５、ＳＤＰ Ａｎｓｗｅｒ１５６、及び、ＳＩＰ Ｓｅｓｓｉｏｎに関連するフロー（第４図Ｃに示すＦｌｏｗ Ｔａｂｌｅ）へのポインタＰｏｉｎｔｅｒ ｔｏ Ｆｌｏｗ Ｔａｂｌｅ１５７から構成される。ＳＩＰ Ｄｉａｌｏｇ１５１は、Ｃａｌｌ−ＩＤ１５１ａ、Ｆｒｏｍ ｔａｇ１５１ｂ、及び、Ｔｏ ｔａｇ１５１ｃから構成される。
第４図Ｃは、本発明の第１の実施の形態のＨＧＷ１１が保持するＦｌｏｗ Ｔａｂｌｅの説明図である。
Ｆｌｏｗ Ｔａｂｌｅ（第４図Ｃ）は、ＳＩＰ Ｓｅｓｓｉｏｎに関連するフローを管理するためのテーブルである。Ｆｌｏｗ Ｔａｂｌｅ（第４図Ｃ）は、端末を識別するＴｅｒｍｉｎａｌ−ＩＤ１７１、フローを識別するＦｌｏｗ Ｆｉｌｔｅｒ１７２、フローの帯域を示すＢａｎｄｗｉｄｔｈ１７３、フローの状態を示すＳｔａｔｅ１７４、及び、フローに関連するＲＳＶＰ Ｓｅｓｓｉｏｎ（第４図Ｄに示すＲＳＶＰ Ｓｅｓｓｉｏｎ Ｔａｂｌｅ）へのポインタＰｏｉｎｔｅｒ ｔｏ ＲＳＶＰ Ｓｅｓｓｉｏｎ Ｔａｂｌｅ１７５から構成される。
Ｆｌｏｗ Ｆｉｌｔｅｒ１７２は、Ｓｒｃ ＩＰ１７２ａ、Ｄｓｔ ＩＰ１７２ｂ、ｐｒｏｔｏ１７２ｃ、Ｓｒｃ Ｐｏｒｔ１７２ｄ、及び、Ｄｓｔ Ｐｏｒｔ１７２ｅから構成される。また、Ｐｏｉｎｔｅｒ ｔｏ ＲＳＶＰ Ｓｅｓｓｉｏｎ Ｔａｂｌｅ１７５は、２種類のフィールド（すなわち、Ｔｏ ＡＧＷ１７５ａ及びＦｒｏｍ Ｔｅｒｍｉｎａｌ１７５ｂ）から構成される。これらは、それぞれ「ＨＧＷ１１がＡＧＷ７に対して送信したＱｏＳ設定要求」及び「端末から受信したＱｏＳ設定要求」をフローに対応付けるために使用される。
第４図Ｄは、本発明の第１の実施の形態のＨＧＷ１１が保持するＲＳＶＰ Ｓｅｓｓｉｏｎ Ｔａｂｌｅの説明図である。
ＲＳＶＰ Ｓｅｓｓｉｏｎ Ｔａｂｌｅ（第４図Ｄ）は、ＲＳＶＰ Ｓｅｓｓｉｏｎを管理するためのテーブルである。ＲＳＶＰ Ｓｅｓｓｉｏｎ Ｔａｂｌｅ（第４図Ｄ）は、ＲＳＶＰ Ｓｅｓｓｉｏｎを識別するＲＳＶＰ Ｓｅｓｓｉｏｎ ＩＤ１９１、予約スタイルを示すＳｔｙｌｅ１９２、フローの識別情報を示すＦｉｌｔｅｒＳｐｅｃ１９３、フロー特性を示すＦｌｏｗＳｐｅｃ１９４、ＱｏＳ設定の可否判断に使用するＰｏｌｉｃｙ Ｄａｔａ１９５、ＲＳＶＰ Ｓｅｓｓｉｏｎ状態を示すＳｔａｔｅ１９６、及び、ＲＳＶＰ Ｓｅｓｓｉｏｎに関連するフロー（第４図Ｃに示すＦｌｏｗ Ｔａｂｌｅ）へのポインタＰｏｉｎｔｅｒ ｔｏ Ｆｌｏｗ Ｔａｂｌｅ１９７から構成される。
ＲＳＶＰ Ｓｅｓｓｉｏｎ ＩＤ１９１は、Ｄｓｔ ＩＰ１９１ａ、Ｄｓｔ Ｐｏｒｔ１９１ｂ、及び、Ｐｒｏｔｏ１９１ｃから構成される。ＦｉｌｔｅｒＳｐｅｃ１９３は、Ｓｒｃ ＩＰ１９３ａ及びＳｒｃ Ｐｏｒｔ１９３ｂから構成される。ＦｉｌｔｅｒＳｐｅｃ１９４は、Ｂａｎｄｗｉｄｔｈ１９４ａから構成される。Ｐｏｌｉｃｙ Ｄａｔａ１９５には、要求者ＩＤなどが設定される。
第５図は、本発明の第１の実施の形態におけるセッション確立のための処理を示すシーケンス図である。
第５図は、例として、ホーム網１７に接続された端末（ＵＡ１２）が、移動アクセス網に接続された端末（ＵＡ８）との間にセッションを確立するためのシーケンスを示す。端末（ＵＡ１２及びＵＡ８）は、ＩＥＴＦ ＲＦＣ３３１２に規定されるｐｒｅｃｏｎｄｉｔｉｏｎオプションに対応しており、着信側ユーザを呼び出す前にアクセス網のＱｏＳリソース予約を完了する。以下、このシーケンスの詳細を説明する。
最初に、端末（ＵＡ１２）は、ＳＤＰ Ｏｆｆｅｒを含むＳＩＰ ＩＮＶＩＴＥ２１１をＨＧＷ１１に送信する。
ＳＩＰ ＩＮＶＩＴＥ２１１には、これから確立しようとするセッションにおいて端末（ＵＡ１２）が要求する帯域を示す情報が含まれる。
ＨＧＷ１１は、Ｓｅｓｓｉｏｎ情報をＳＩＰ Ｓｅｓｓｉｏｎ Ｔａｂｌｅ（第４図Ｂ）に記録する。さらに、ＨＧＷ１１は、ＩＮＶＩＴＥ２１１にＬｉｎｅ−ＩＤを追加し、ＳＩＰ Ｓｅｒｖｅｒ３に転送する（Ｆ１）。Ｆ１において実行される処理については、後で詳細に説明する（第８図参照）。
第６図は、本発明の第１の実施の形態のＨＧＷ１１によってＬｉｎｅ−ＩＤを追加されたＳＩＰ ＩＮＶＩＴＥ２１１の例を示す説明図である。
ＳＩＰ ＩＮＶＩＴＥは、ＩＰ Ｈｅａｄｅｒ、ＵＤＰ Ｈｅａｄｅｒ及びＳＩＰ Ｍｅｓｓａｇｅから構成される。ＳＩＰ Ｍｅｓｓａｇｅは、Ｓｔａｒｔ−Ｌｉｎｅ、ＳＩＰ Ｈｅａｄｅｒ及びＭｅｓｓａｇｅ−Ｂｏｄｙ（ＳＤＰ）から構成される。第６図の例では、Ｌｉｎｅ−ＩＤ「１２３４５６」が拡張ＳＩＰ Ｈｅａｄｅｒ（Ｘ−Ｌｉｎｅ−ＩＤ Ｈｅａｄｅｒ）に設定されている。
なお、Ｌｉｎｅ−ＩＤ「１２３４５６」は、ＳＤＰ属性行に設定されてもよい（図示省略）。
再び第５図を参照して、シーケンスの説明を続ける。
ＳＩＰ Ｓｅｒｖｅｒ３は、ＨＧＷ１１からＩＮＶＩＴＥ２１１を受信すると、Ｘ−Ｌｉｎｅ−ＩＤ ＨｅａｄｅｒからＬｉｎｅ−ＩＤを削除し、そのＬｉｎｅ−ＩＤを、Ｓｅｓｓｉｏｎ情報と共にＳＩＰ Ｓｅｓｓｉｏｎ Ｔａｂｌｅ（第２図Ｂ）に記録する。本シーケンスでは、Ｌｉｎｅ−ＩＤは７２ｂに設定される。さらに、ＳＩＰ Ｓｅｒｖｅｒ３は、ＩＮＶＩＴＥ２１１をＳＩＰ Ｓｅｒｖｅｒ１に転送する。ＩＮＶＩＴＥ２１１は、ＳＩＰ Ｓｅｒｖｅｒ１及びＳＩＰ Ｓｅｒｖｅｒ２を経由して、端末（ＵＡ８）に到達する。なお、第５図では、ＳＩＰ Ｓｅｒｖｅｒ１及び２を省略している。
端末（ＵＡ８）は、ＳＤＰ Ａｎｓｗｅｒを含む暫定応答（１８３応答）２１２を返信する。１８３応答２１２は、ＩＮＶＩＴＥ２１１と逆の経路を辿り、端末（ＵＡ１２）に到達する。端末（ＵＡ１２）は、１８３応答２１２に対するＰＲＡＣＫ（Ｐｒｏｖｉｓｉｏｎａｌ Ｒｅｓｐｏｎｓｅ Ａｃｋｎｏｗｌｅｄｇｍｅｎｔ）２１３を送信する。端末（ＵＡ８）は、ＰＲＡＣＫ２１３に対する２００応答２１４を返信する。
ＳＩＰ Ｓｅｒｖｅｒ３は、ＳＤＰ Ａｎｓｗｅｒを含む１８３応答２１２を転送したことを契機に、ＱｏＳ Ｐｏｌｉｃｙ Ｓｅｒｖｅｒ５に対してサービス情報２１５を通知する（Ｆ２）。この通知は、ＰＲＡＣＫ２１３又は２００応答２１４より早く送信されてもよい。Ｆ２において実行される処理については、後で詳細に説明する（第９図参照）。
サービス情報２１５には、ＳＩＰ Ｓｅｓｓｉｏｎを識別するＳｅｓｓｉｏｎ−ＩＤ、回線を識別するＬｉｎｅ−ＩＤ、端末を識別するＴｅｒｍｉｎａｌ−ＩＤ、Ｆｌｏｗを識別するフィルタ情報、及び、帯域が含まれる。これらの情報は、ＩＮＶＩＴＥ２１１及び１８３応答２１２に含まれる情報に基づく。サービス情報２１５に含まれる帯域は、Ｔｅｒｍｉｎａｌ−ＩＤによって識別される端末がセッションにおいて要求する帯域である。ＱｏＳ Ｐｏｌｉｃｙ Ｓｅｒｖｅｒ３は、通知された情報をＳｅｒｖｉｃｅ Ｉｎｆｏｒｍａｔｉｏｎ Ｔａｂｌｅ（第３図Ｂ）に記録する。
ＨＧＷ１１は、ＳＤＰ Ａｎｓｗｅｒを含む１８３応答２１２を転送したことを契機に、Ｓｅｓｓｉｏｎに関連するフローをＦｌｏｗ Ｔａｂｌｅ（第４図Ｃ）に登録する。さらに、ＨＧＷ１１は、ＡＧＷ７に対してＲＳＶＰ Ｒｅｓｖ２１６を送信し、固定アクセス網１６のＱｏＳ設定を要求する（Ｆ３）。この要求は、ＰＲＡＣＫ２１３又は２００応答２１４より早く送信されてもよい。Ｆ３において実行される処理については、後で詳細に説明する（第１０図参照）。ＲＳＶＰ Ｒｅｓｖ２１６には、Ｌｉｎｅ−ＩＤ、Ｔｅｒｍｉｎａｌ−ＩＤ、Ｆｌｏｗのフィルタ情報、及び、要求帯域が含まれる。
第７図Ａ及び第７図Ｂは、本発明の第１の実施の形態において送信されるＲＳＶＰ Ｒｅｓｖ２１６のパケットフォーマットの説明図である。
第７図Ａに示す例では、ＳＥＳＳＩＯＮオブジェクト及びｆｌｏｗｄｅｓｃｒｉｐｔｏｒｌｉｓｔオブジェクトに、それぞれ、フィルタ情報及び帯域が設定される。さらに、ＰＯＬＩＣＹ＿ＤＡＴＡオブジェクトにＬｉｎｅ−ＩＤ及びＴｅｒｍｉｎａｌ−ＩＤが設定される。
第７図Ｂに示す例では、ベンダ拡張（ｖｅｎｄｏｒ＿ｓｐｅｃｉｆｉｃ）領域にＬｉｎｅ−ＩＤ及びＴｅｒｍｉｎａｌ−ＩＤが設定される。
本実施の形態では、第７図Ａ及び第７図Ｂのどちらのフォーマットが適用されてもよい。
再び第５図を参照して、シーケンスの説明を続ける。
端末（ＵＡ１２）は、ＰＲＡＣＫに対する２００応答２１４を受信したことを契機に、ＲＳＶＰ Ｒｅｓｖ２１７を送信し、ホーム網１７のＱｏＳ設定を要求する。ＲＳＶＰ Ｒｅｓｖ２１７には、Ｔｅｒｍｉｎａｌ−ＩＤ、Ｆｌｏｗのフィルタ情報、及び、要求帯域が含まれる。ＨＧＷ１１は、Ｔｅｒｍｉｎａｌ−ＩＤ及びフィルタ情報を比較キーとして使用し、ＲＳＶＰ Ｒｅｓｖ２１６とＲＳＶＰ Ｒｅｓｖ２１７とを対応付けて管理する（Ｆ４）。Ｆ４において実行される処理については、後で詳細に説明する（第１１図参照）。
ＡＧＷ７は、ＨＧＷ１１からＲＳＶＰ Ｒｅｓｖ２１６を受信したことを契機に、ＱｏＳ認可要求２１８をＱｏＳ Ｐｏｌｉｃｙ Ｓｅｒｖｅｒ５に送信する。ＱｏＳ認可要求２１８は、ＲＳＶＰ Ｒｅｓｖ２１６に含まれていたＬｉｎｅ−ＩＤ、Ｔｅｒｍｉｎａｌ−ＩＤ、フィルタ情報、及び、帯域を指定する。言い換えると、ＨＧＷ１１から送信されたＱｏＳ制御信号（ＲＳＶＰ Ｒｅｓｖ２１６）に含まれるＬｉｎｅ−ＩＤ及び帯域等の情報は、最終的に、ＱｏＳ Ｐｏｌｉｃｙ Ｓｅｒｖｅｒ５に到達する。
ＱｏＳ Ｐｏｌｉｃｙ Ｓｅｒｖｅｒ５は、ＳＩＰ Ｓｅｒｖｅｒ３から通知されたサービス情報２１５と回線帯域を考慮してＱｏＳ設定を認可する。さらに、ＱｏＳ Ｐｏｌｉｃｙ Ｓｅｒｖｅｒ５は、必要に応じてＰＯＮの回線保証帯域を制御し、ＡＧＷ７に成功応答２１９を返信する（Ｆ５）。Ｆ５において実行される処理については、後で詳細に説明する（第１２図参照）。
ＡＧＷ７は、応答２１９を受信すると、ＲＳＶＰ Ｒｅｓｖ２１６で指定されたＱｏＳパラメータをローカルのテーブル（図示省略）に設定し、ＲＳＶＰ ＲｅｓｖＣｏｎｆ２２０を送信する。
ＨＧＷ１１は、ＲＳＶＰ ＲｅｓｖＣｏｎｆ２２０を受信すると、ＲＳＶＰ Ｒｅｓｖ２１７に対するＲＳＶＰ ＲｅｓｖＣｏｎｆ２２１を端末（ＵＡ１２）に送信する（Ｆ６）。Ｆ６において実行される処理については、後で詳細に説明する（第１３図参照）。
以上の手順によって、固定アクセス網１６及びホーム網１７のＱｏＳ設定が完了する。
その後、端末（ＵＡ１２）は、ＳＤＰ Ｏｆｆｅｒを含むＳＩＰ ＵＰＤＡＴＥ２２２を送信し、ＱｏＳ設定の完了を端末（ＵＡ８）に通知する。端末（ＵＡ８）は、ＳＤＰ Ａｎｓｗｅｒ を含む２００応答２２３を返信する。さらに、端末（ＵＡ８）は、ユーザの呼び出しを開始し、１８０応答２２４を送信する。端末（ＵＡ１２）は、１８０応答２２４に対するＰＲＡＣＫ２２５を送信する。端末（ＵＡ８）は、ＰＲＡＣＫ２２５に対する２００応答２２６を送信する。
着信ユーザがオフフックしたことを契機に、端末（ＵＡ８）は、ＩＮＶＩＴＥ２１１に対する２００応答２２７を送信する。端末（ＵＡ１２）は、ＡＣＫ２２８を返信する。以上の手順によって、セッション確立が完了し、Ｍｅｄｉａ Ｆｌｏｗ２２９の送受信が開始する。
以下、第５図のシーケンスに関連して、本発明に特徴的な処理（具体的には、第５図のＦ１からＦ６において実行される処理）を説明する。
第８図は、本発明の第１の実施の形態のＨＧＷ１１が実行するＬｉｎｅ−ＩＤ追加判定処理（第５図のＦ１）を示すフローチャートである。
ＨＧＷ１１は、処理効率化のため、ＳＩＰメッセージ種別及びメッセージボディの内容に応じて、選択的にＬｉｎｅ−ＩＤを追加する。
ＨＧＷ１１は、まず、ＳＩＰ ＭｅｓｓａｇｅにＳＤＰ Ｏｆｆｅｒ又はＳＤＰ Ａｎｓｗｅｒが含まれるか否かを判定する（２５１）。
ＳＩＰ ＭｅｓｓａｇｅにＳＤＰ Ｏｆｆｅｒ又はＳＤＰ Ａｎｓｗｅｒのいずれも含まれない場合、ＨＧＷ１１は、ＳＩＰ ＭｅｓｓａｇｅにＬｉｎｅ−ＩＤを追加せずに処理を終了する。一方、ＳＩＰ ＭｅｓｓａｇｅにＳＤＰ Ｏｆｆｅｒ又はＳＤＰ Ａｎｓｗｅｒのいずれかが含まれる場合、ＨＧＷ１１は、ＳＩＰ ＭｅｓｓａｇｅにＬｉｎｅ−ＩＤを追加し（２５２）、処理を終了する。
第８図に示す処理を実行することによって、所定の種類のＳＩＰ ＭｅｓｓａｇｅのみにＬｉｎｅ−ＩＤが追加され、Ｌｉｎｅ−ＩＤを追加する必要がないＳＩＰ Ｍｅｓｓａｇｅに対しては、Ｌｉｎｅ−ＩＤを追加する処理が省略される。このため、処理が効率化される。
第９図は、本発明の第１の実施の形態のＳＩＰ Ｓｅｒｖｅｒ３が実行するサービス情報通知処理（第５図のＦ２）を示すフローチャートである。
ＳＩＰ Ｓｅｒｖｅｒ３は、ＳＤＰ Ａｎｓｗｅｒの転送を契機に、以下の処理を実行する。
まず、ＳＩＰ Ｓｅｒｖｅｒ３は、転送したＳＤＰ Ｏｆｆｅｒ（７５）及びＡｎｓｗｅｒ（７６）が既存のＭｅｄｉａ Ｆｌｏｗを更新するか否かを判定する（２７１）。例えば、新規にセッションを確立する場合、転送したＳＤＰ Ｏｆｆｅｒ等が既存のＭｅｄｉａ Ｆｌｏｗを更新すると判定される。
ステップ２７１において、転送したＳＤＰ Ｏｆｆｅｒ等が既存のＭｅｄｉａ Ｆｌｏｗを更新しないと判定された場合、ＳＩＰ Ｓｅｒｖｅｒ３は、処理を終了する。
一方、ステップ２７１において、転送したＳＤＰ Ｏｆｆｅｒ等が既存のＭｅｄｉａ Ｆｌｏｗを更新すると判定された場合、ＳＩＰ Ｓｅｒｖｅｒ３は、ＳＩＰ Ｓｅｓｓｉｏｎ Ｔａｂｌｅ（第２図Ｂ）から、Ｓｅｓｓｉｏｎに関連する端末のＩＤ（Ｔｅｒｍｉｎａｌ−ＩＤ）を抽出する（２７２）。本実施の形態では、Ｔｅｒｍｉｎａｌ−ＩＤとして、第２図Ｂに示すＦｒｏｍ ＵＲＩ（７２ａ）及びＴｏ ＵＲＩ（７３ａ）が抽出される。あるいは、Ｆｒｏｍ ＵＲＩ（７２ａ）及びＴｏ ＵＲＩ（７３ａ）に関連付けられた別のＩＤが使用されてもよい。
次に、ＳＩＰ Ｓｅｒｖｅｒ３は、ステップ２７２で抽出された各Ｔｅｒｍｉｎａｌ−ＩＤ（具体的には、発信側と着信側のＴｅｒｍｉｎａｌ−ＩＤ）に関して、ループ（２７３−２７９）の処理を行う。
最初に、ＳＩＰ Ｓｅｒｖｅｒ３は、Ｔｅｒｍｉｎａｌ−ＩＤが、固定アクセス網１６に収容されている端末のものであるか否かを判定する（２７４）。本実施の形態では、例えば、ＳＩＰ Ｓｅｓｓｉｏｎ Ｔａｂｌｅ（第２図Ｂ）のＬｉｎｅ−ＩＤ（７２ｂ又は７３ｂ）が存在する場合、判定の対象であるＴｅｒｍｉｎａｌ−ＩＤが、固定アクセス網１６に収容されている端末のものであると判定される。ただし、別の方法によってステップ２７４の判定が実行されてもよい。
ステップ２７４において、Ｌｉｎｅ−ＩＤが存在しないと判定された場合、ＳＩＰ Ｓｅｒｖｅｒ３は、２７５−２７８の処理をスキップする。
一方、ステップ２７４において、Ｌｉｎｅ−ＩＤが存在すると判定された場合、ＳＩＰ Ｓｅｒｖｅｒ３は、Ｌｉｎｅ−ＩＤ（７２ｂ又は７３ｂ）の値を取得する（２７５）。
次に、ＳＩＰ Ｓｅｒｖｅｒ３は、ＳＩＰ Ｓｅｓｓｉｏｎを一意に識別するためのＳｅｓｓｉｏｎ−ＩＤを生成する（２７６）。本実施の形態では、Ｓｅｓｓｉｏｎ−ＩＤとしてＳＩＰ Ｓｅｓｓｉｏｎ Ｔａｂｌｅ（第２図Ｂ）のＳＩＰ Ｄｉａｌｏｇ ＩＤ７１が使用される。
次に、ＳＩＰ Ｓｅｒｖｅｒ３は、第２図ＢのＳＤＰ Ｏｆｆｅｒ（７５）及びＳＤＰ Ａｎｓｗｅｒ（７６）から、Ｓｅｓｓｉｏｎに関連するＦｌｏｗ Ｆｉｌｔｅｒ（具体的には、Ｓｒｃ ＩＰ、Ｄｓｔ ＩＰ、Ｐｒｏｔｏｃｏｌ、Ｓｒｃ Ｐｏｒｔ及びＤｓｔ Ｐｏｒｔ）及び帯域を抽出する（２７７）。
最後に、ＳＩＰ Ｓｅｒｖｅｒ３は、ＱｏＳ Ｐｏｌｉｃｙ Ｓｅｒｖｅｒ５に対して、サービス情報を通知する（２７８）。サービス情報には、Ｔｅｒｍｉｎａｌ−ＩＤ、ステップ２７５において取得されたＬｉｎｅ−ＩＤ、ステップ２７６において生成されたＳｅｓｓｉｏｎ−ＩＤ、及び、ステップ２７７において抽出されたＦｌｏｗ Ｆｉｌｔｅｒ及び帯域が含まれる。
第１０図は、本発明の第１の実施の形態のＨＧＷ１１が実行するＦｌｏｗ登録／ＲＳＶＰ Ｒｅｓｖ送信処理（第５図のＦ３）を示すフローチャートである。
ＨＧＷ１１は、ＳＤＰ Ａｎｓｗｅｒの転送を契機に以下の処理を実行する。
まず、ＨＧＷ１１は、転送したＳＤＰ Ｏｆｆｅｒ（１５５）及びＡｎｓｗｅｒ（１５６）が既存のＭｅｄｉａ Ｆｌｏｗを更新するか否かを判定する（２９１）。
ステップ２９１において、転送したＳＤＰ Ｏｆｆｅｒ等が既存のＭｅｄｉａ Ｆｌｏｗを更新しないと判定された場合、ＨＧＷ１１は、処理を終了する。
一方、ステップ２９１において、転送したＳＤＰ Ｏｆｆｅｒ等が既存のＭｅｄｉａ Ｆｌｏｗを更新すると判定された場合、ＨＧＷ１１は、ＳＩＰ Ｓｅｓｓｉｏｎ Ｔａｂｌｅ（第４図Ｂ）から、Ｓｅｓｓｉｏｎに関連する端末のＩＤ（Ｔｅｒｍｉｎａｌ−ＩＤ）を抽出する（２９２）。本実施の形態では、Ｔｅｒｍｉｎａｌ−ＩＤとして、第４図ＢのＦｒｏｍ ＵＲＩ（１５２）及びＴｏ ＵＲＩ（１５３）が抽出される。あるいは、Ｆｒｏｍ ＵＲＩ（１５２）及びＴｏ ＵＲＩ（１５３）に関連付けられた別のＩＤが使用さてもよい。
次に、ＨＧＷ１１は、ステップ２９２で抽出した各Ｔｅｒｍｉｎａｌ−ＩＤに関して、ループ１（２９３−３００）の処理を行う。まず、ＨＧＷ１１は、Ｔｅｒｍｉｎａｌ−ＩＤが示す端末が、ホーム網１７に接続されているか否かを判定する（２９４）。この判定は、ＳＩＰ Ｍｅｓｓａｇｅの受信ポート、及び、端末ＩＰ Ａｄｄｒｅｓｓ等に基づいて実行される。
ステップ２９４において、端末がホーム網１７に接続されていないと判定された場合、ＨＧＷ１１は、ステップ２９５−２９９の処理をスキップする。
一方、端末がホーム網１７に接続されていると判定された場合、ＨＧＷ１１は、ＳＤＰ Ｏｆｆｅｒ（１５５）及びＡｎｓｗｅｒ（１５６）によって確立されるフローをＦｌｏｗ Ｔａｂｌｅ（第４図Ｃ）に設定する（２９５）。
次に、ＨＧＷ１１は、ステップ２９５において設定された各Ｆｌｏｗに関して、ループ２（２９６−２９９）の処理を行う。最初に、ＨＧＷ１１は、Ｆｌｏｗが固定アクセス網１６を経由するか否かを判定する（２９７）。この判定は、Ｆｌｏｗの送信元／宛先ＩＰアドレス（第４図Ｃの１７２ａ、１７２ｂ）等に基づいて実行される。
ステップ２９７において、Ｆｌｏｗが固定アクセス網１６を経由しないと判定された場合、このＦｌｏｗは、ホーム網１７の中で閉じている。この場合、ＡＧＷ７に対してＱｏＳ設定要求を送信する必要がないため、ＨＧＷ１１は、ステップ２９８の処理をスキップする。
一方、ステップ２９７において、Ｆｌｏｗが固定アクセス網１６を経由すると判定された場合、ＨＧＷ１１は、ＡＧＷ７にＱｏＳ設定要求（ＲＳＶＰ Ｒｅｓｖ）を送信するとともに、送信した要求に対応するエントリをＲＳＶＰ Ｓｅｓｓｉｏｎ Ｔａｂｌｅ（第４図Ｄ）に設定する（２９８）。
第１１図は、本発明の第１の実施の形態のＨＧＷ１１が実行するＲＳＶＰ Ｒｅｓｖ受信処理（第５図のＦ４）を示すフローチャートである。
第１１図に示す処理は、ＨＧＷ１１がＡＧＷ７に送信したＲＳＶＰ Ｒｅｓｖ（２１６）と、ＨＧＷ１１がＵＡ１２から受信したＲＳＶＰ Ｒｅｓｖ（２１７）とを対応付けるために実行される。
ＨＧＷ１１は、まず、ＵＡ１２から受信したＲＳＶＰ Ｒｅｓｖに対応するエントリをＲＳＶＰ Ｓｅｓｓｉｏｎ Ｔａｂｌｅ（第４図Ｄ）に設定する（３１１）。
次に、ＨＧＷ１１は、ステップ３１１において設定されたエントリに対応するＦｌｏｗをＦｌｏｗ Ｔａｂｌｅ（第４図Ｃ）から検索する（３１２）。この検索は、Ｆｌｏｗ Ｔａｂｌｅ（第４図Ｃ）の各エントリのフィルタ情報及び端末ＩＤと、ステップ３１１において設定されたエントリのフィルタ情報及び端末ＩＤとが一致するか否かを判定することによって実行される。Ｆｌｏｗ Ｔａｂｌｅ（第４図Ｃ）において、フィルタ情報は、Ｆｌｏｗ Ｆｉｌｔｅｒ１７２に設定されている。端末ＩＤは、Ｔｅｒｍｉｎａｌ−ＩＤ１７１に設定されている。ＲＳＶＰ Ｓｅｓｓｉｏｎ Ｔａｂｌｅ（第４図Ｄ）において、フィルタ情報はＲＳＶＰ Ｓｅｓｓｉｏｎ ＩＤ１９１及びＦｉｌｔｅｒＳｐｅｃ１９３に設定されている。端末ＩＤは、Ｐｏｌｉｃｙ Ｄａｔａ１９５に設定されている。
ステップ３１２において、検索の条件に合うＦｌｏｗがＦｌｏｗ Ｔａｂｌｅ（第４図Ｃ）に存在しない場合、ＲＳＶＰ Ｒｅｓｖを送信したＵＡ１２は、第５図のステップ２１１から２１２に示す手順を実行していない。このようなＵＡ１２は、悪意のある端末である可能性がある。この場合、ＨＧＷ１１は、ステップ３１１において設定されたエントリを削除し、エラー応答（ＲＳＶＰ ＲｅｓｖＥｒｒ）を送信して処理を終了する（３１３）。
一方、ステップ３１２において、検索の条件に合うＦｌｏｗが存在する場合、ＨＧＷ１１は、第４図Ｃの１７５ｂ及び第４図Ｄの１９７を設定することによって、ステップ３１１において設定されたＲＳＶＰ Ｓｅｓｓｉｏｎと、ステップ３１２において検索されたＦｌｏｗに相互リンクを作成する（３１４）。ステップ３１４によって、同一のフロー（又は同一のセッション）のために送信されたＲＳＶＰ Ｒｅｓｖ２１６とＲＳＶＰ Ｒｅｓｖ２１７とが間接的に対応付けられる。
次に、ＨＧＷ１１は、ステップ３１２において検索されたＦｌｏｗに関連してＡＧＷ７に送信した設定要求（第４図Ｃの１７５ａ）に対する成功応答（すなわち、第５図のＲＳＶＰ ＲｅｓｖＣｏｎｆ２２０）を受信済みであるか否かを判定する（３１５）。
ステップ３１５において、成功応答を受信していないと判定された場合、固定アクセス網１６におけるＱｏＳの設定（帯域予約）が終了していない。この場合、ＨＧＷ１１は、そのまま処理を終了する。
一方、成功応答を受信済みであると判定された場合、固定アクセス網１６におけるＱｏＳの設定（帯域予約）が終了している。この場合、ＨＧＷ１１は、ＵＡ１２から受信したＲＳＶＰ Ｒｅｓｖ２１７に対する成功応答（ＲＳＶＰ ＲｅｓｖＣｏｎｆ２２１）をＵＡ１２に返信し、さらに、ステップ３１１において設定されたエントリの状態を「成功応答送信済み」に設定して、処理を終了する（３１６）。
なお、ＨＧＷ１１は、ステップ３１２から３１５までのいずれかの時点で、ＲＳＶＰ Ｒｅｓｖ２１７に応じて、ＵＡ１２とＨＧＷ１１の間の帯域予約を実行してもよい。
第５図のＲＳＶＰ Ｒｅｓｖ２１６は、固定アクセス網１６におけるＨＧＷ１１とＡＧＷ７の間の帯域を予約するための要求である。ＲＳＶＰ ＲｅｓｖＣｏｎｆ２２０は、ＲＳＶＰ Ｒｅｓｖ２１６に対する成功応答である。一方、ＲＳＶＰ Ｒｅｓｖ２１７は、ＵＡ１２とＨＧＷ１１の間の帯域を予約するための要求である。ＲＳＶＰ ＲｅｓｖＣｏｎｆ２２１は、ＲＳＶＰ Ｒｅｓｖ２１７に対する成功応答である。これらの二つの要求（２１６及び２１７）に応じた帯域予約の処理は、どちらが先に実行されてもよい。このため、本来、ＨＧＷ１１は、ステップ３１４の処理が終了した後であれば、ＲＳＶＰ ＲｅｓｖＣｏｎｆ２２０を受信していなくても、ＲＳＶＰ ＲｅｓｖＣｏｎｆ２２１をＵＡ１２に送信することができる。
しかし、ＵＡ１２は、ＲＳＶＰ ＲｅｓｖＣｏｎｆ２２１を受信すると、第５図のステップ２２２以降の処理を実行する。ステップ２２２以降の処理は、ＨＧＷ１１とＡＧＷ７の間の帯域予約が終了した後で（すなわち、Ｆ５の処理が終了した後で）実行される必要がある。このため、本実施の形態のＨＧＷ１１は、ＲＳＶＰ ＲｅｓｖＣｏｎｆ２２０を受信した後に限ってＲＳＶＰ ＲｅｓｖＣｏｎｆ２２１を送信する（３１５、３１６）。その結果、ＨＧＷ１１とＡＧＷ７の間の帯域予約が終了する前にＵＡ１２がステップ２２２以降の処理を実行することが防止される。
第１２図は、本発明の第１の実施の形態のＱｏＳ Ｐｏｌｉｃｙ Ｓｅｒｖｅｒ５が実行するＦｌｏｗ認可処理（第５図のＦ５）を示すフローチャートである。
ＱｏＳ Ｐｏｌｉｃｙ Ｓｅｒｖｅｒ５は、ＡＧＷ７からＱｏＳ認可要求を受信したとき、以下の処理を実行する（第５図のＦ５参照）。
まず、ＱｏＳ Ｐｏｌｉｃｙ Ｓｅｒｖｅｒ５は、受信したＱｏＳ認可要求に対応するエントリを、Ｆｌｏｗ Ｔａｂｌｅ（第３図Ｃ）に設定する（３３１）。
次に、ＱｏＳ Ｐｏｌｉｃｙ Ｓｅｒｖｅｒ５は、ステップ３３１において設定されたエントリに対応するサービス情報をＳｅｒｖｉｃｅ Ｉｎｆｏｒｍａｔｉｏｎ Ｔａｂｌｅ（第３図Ｂ）から検索する（３３２）。サービス情報の検索は、Ｓｅｒｖｉｃｅ Ｉｎｆｏｒｍａｔｉｏｎ Ｔａｂｌｅ（第３図Ｂ）の各エントリに設定されたＦｌｏｗのフィルタ情報、回線ＩＤ及び端末ＩＤと、ステップ３３１において設定されたエントリのフィルタ情報、回線ＩＤ及び端末ＩＤとが一致するか否かを判定することによって実行される。
Ｓｅｒｖｉｃｅ Ｉｎｆｏｒｍａｔｉｏｎ Ｔａｂｌｅ（第３図Ｂ）において、フィルタ情報はＦｌｏｗＦｉｌｔｅｒ９４に設定されている。回線ＩＤは、Ｌｉｎｅ−ＩＤ９２に設定されている。端末ＩＤは、Ｔｅｒｍｉｎａｌ−ＩＤ９３に設定されている。Ｆｌｏｗ Ｔａｂｌｅ（第３図Ｃ）において、フィルタ情報はＦｌｏｗＦｉｌｔｅｒ１１３に設定されている。回線ＩＤは、Ｌｉｎｅ−ＩＤ１１１に設定されている。端末ＩＤは、Ｔｅｒｍｉｎａｌ−ＩＤ１１２に設定されている。
ステップ３３２において、検索の条件に合うサービス情報が存在しない場合、ＱｏＳ Ｐｏｌｉｃｙ Ｓｅｒｖｅｒ５は、ステップ３３１において設定されたエントリを削除し、ＡＧＷ７にエラー応答を送信して（３３３）、処理を終了する。
一方、ステップ３３２において、検索の条件に合うサービス情報が存在する場合、ＱｏＳ Ｐｏｌｉｃｙ Ｓｅｒｖｅｒ５は、要求帯域（１１４）がステップ３３２において検索されたサービス情報（すなわち検索の条件に合うサービス情報）の帯域（９５）を越えるか否かを判定する（３３４）。
ステップ３３４において、要求帯域（１１４）がサービス情報の帯域（９５）を超える場合、ＱｏＳ Ｐｏｌｉｃｙ Ｓｅｒｖｅｒ５は、ステップ３３３のエラー処理を実行して、処理を終了する。
一方、ステップ３３４において、要求帯域（１１４）がサービス情報の帯域（９５）を超えない場合、ＱｏＳ Ｐｏｌｉｃｙ Ｓｅｒｖｅｒ５は、ＱｏＳ認可要求に含まれるＬｉｎｅ−ＩＤ（１１１）に基づいて、Ｌｉｎｅ Ｔａｂｌｅ（第３図Ｄ）から回線情報を検索する（３３５）。具体的には、受信したＱｏＳ認可要求に含まれるＬｉｎｅ−ＩＤ（１１１）と同一の値がＬｉｎｅ−ＩＤ（１３１）として登録されているエントリをＬｉｎｅ Ｔａｂｌｅ（第３図Ｄ）から検索する。
次に、ＱｏＳ Ｐｏｌｉｃｙ Ｓｅｒｖｅｒ５は、ステップ３３５において検索されたエントリの現在帯域（１３６）と要求帯域（１１４）の和が、最大保証帯域（１３５）を超えるか否かを判定する（３３６）。
ステップ３３６において、現在帯域（１３６）と要求帯域（１１４）の和が最大保証帯域（１３５）を超えると判定された場合、ＱｏＳ Ｐｏｌｉｃｙ Ｓｅｒｖｅｒ５は、ステップ３３３のエラー処理を実行して、処理を終了する。
一方、ステップ３３６において、現在帯域（１３６）と要求帯域（１１４）の和が最大保証帯域（１３５）を超えないと判定された場合、ＱｏＳ Ｐｏｌｉｃｙ Ｓｅｒｖｅｒ５は、ステップ３３５において検索されたエントリの現在帯域（１３６）と要求帯域（１１４）の和が、最低保証帯域（１３４）を超えるか否かを判定する（３３７）。
ステップ３３７において、現在帯域（１３６）と要求帯域（１１４）の和が最低保証帯域（１３４）を超えないと判定された場合、ＱｏＳ Ｐｏｌｉｃｙ Ｓｅｒｖｅｒ５は、ステップ３３８の処理をスキップする。
一方、ステップ３３７において、現在帯域（１３６）と要求帯域（１１４）の和が最低保証帯域（１３４）を超えると判定された場合、ＱｏＳ Ｐｏｌｉｃｙ Ｓｅｒｖｅｒ５は、ＰＯＮの保証帯域を、ステップ３３５において検索されたエントリの現在帯域（１３６）と要求帯域（１１４）の和まで増加させる（３３８）。
最後に、ＱｏＳ Ｐｏｌｉｃｙ Ｓｅｒｖｅｒ５は、ステップ３３５において検索されたエントリの現在帯域（１３６）に要求帯域（１１４）を加算し、ＡＧＷ７に成功応答を送信して処理を終了する（３３９）。
上記の第１２図の処理によって、同一のＬｉｎｅ−ＩＤと関連付けられたセッションにおいて要求される帯域に基づいて、ＱｏＳが制御される。同一のＬｉｎｅ−ＩＤと関連付けられたセッションとは、同一のＨＧＷ１１を経由するセッション（すなわち、固定アクセス網１６において同一の回線を使用するセッション）である。
すなわち、同一の回線を使用する複数のＦｌｏｗが存在する場合、それらの全てのＦｌｏｗにおいて要求される帯域の合計値が算出される（３３６、３３７）。そして、算出された合計値が、固定アクセス網１６における保証帯域として設定される（３３９）。ただし、算出された合計値が最大保証帯域を超える場合、固定アクセス網１６における保証帯域は変更されずに、エラーが応答される（３３３）。算出された合計値が最低保証帯域を超えない場合、最低保証帯域が、固定アクセス網１６における保証帯域として設定される。
第１３図は、本発明の第１の実施の形態のＨＧＷ１１が実行するＲＳＶＰ ＲｅｓｖＣｏｎｆ受信処理（第５図のＦ６）を示すフローチャートである。
まず、ＨＧＷ１１は、受信したＲｅｓｖＣｏｎｆ２２０に対応するエントリをＲＳＶＰ Ｓｅｓｓｉｏｎ Ｔａｂｌｅ（第４図Ｄ）から検索する（３５１）。
ステップ３５１において、検索の条件に合うエントリが存在しない場合、ＨＧＷ１１は、処理を終了する。
一方、ステップ３５１において、検索の条件に合うエントリが存在する場合、ＨＧＷ１１は、検索されたエントリの状態（１９６）を、「成功応答受信済み」に更新する（３５２）。
次に、ＨＧＷ１１は、ステップ３５１において検索されたエントリに関連付けられたＦｌｏｗ（１９７）が、端末（ＵＡ１２）からＲＳＶＰ Ｒｅｓｖ２１７を受信済みであるか否かを判定する（３５３）。具体的には、Ｆｌｏｗ Ｔａｂｌｅ（第４図Ｃ）のＦｒｏｍ Ｔｅｒｍｉｎａｌ１７５ｂが設定されている場合、ＲＳＶＰ Ｒｅｓｖ２１７を受信済みであると判定される。
ステップ３５３において、ＲＳＶＰ Ｒｅｓｖ２１７をまだ受信していないと判定された場合、ＨＧＷ１１は、ステップ処理を終了する。
一方、ステップ３５３において、ＲＳＶＰ Ｒｅｓｖ２１７を受信済みであると判定された場合、ＨＧＷ１１は、ＲＳＶＰ Ｒｅｓｖ２１７に対する応答２２１が既に送信されている否かを判定する（３５４）。
第１１図を参照して説明したように、ＨＧＷ１１は、第１１図のステップ３１４の処理の実行が終了し、かつ、ＲＳＶＰ ＲｅｓｖＣｏｎｆ２２０を受信した後であれば、第１３図に示す処理を実行する前にＲＳＶＰ ＲｅｓｖＣｏｎｆ２２１を送信してもよい。このため、ステップ３５４が実行される前に、既にＲＳＶＰ ＲｅｓｖＣｏｎｆ２２１が送信されている場合がある。
ステップ３５４において、応答が既に送信されていると判定された場合、ＨＧＷ１１は、処理を終了する。
一方、ステップ３５４において、応答がまだ送信されていないと判定された場合、ＨＧＷ１１は、端末に成功応答（ＲＳＶＰ ＲｅｓｖＣｏｎｆ２２１）を送信し、さらに、ステップ３５３において設定された状態（１９６）を「成功応答送信済み」に更新して、処理を終了する（３５５）。
第１４図は、本発明の第１の実施の形態におけるセッション切断のための処理を示すシーケンス図である。
第１４図は、例として、第５図に示す処理によって確立されたセッションを切断するためのシーケンスを示す。
最初に、端末（ＵＡ１２）が端末（ＵＡ８）に対してＳＩＰ ＢＹＥ４０１を送信する。ＢＹＥ４０１は、ＨＧＷ１１、ＳＩＰ Ｓｅｒｖｅｒ３、ＳＩＰ Ｓｅｒｖｅｒ１及びＳＩＰ Ｓｅｒｖｅｒ２を経由して端末（ＵＡ８）に到達する。
端末（ＵＡ８）は、ＢＹＥ４０１に対する２００応答４０２を送信する。２００応答４０２は、ＢＹＥと逆の経路を辿り、端末（ＵＡ１２）に到達する。
ＨＧＷ１１は、ＢＹＥ４０１の転送を契機に、ＳＩＰ Ｓｅｓｓｉｏｎ Ｔａｂｌｅ（第４図Ｂ）、Ｆｌｏｗ Ｔａｂｌｅ（第４図Ｃ）及びＲＳＶＰ Ｓｅｓｓｉｏｎ Ｔａｂｌｅ（第４図Ｄ）から、切断されるセッションに対応するエントリを削除する。
ＳＩＰ Ｓｅｒｖｅｒ３は、ＢＹＥ４０１の転送を契機に、サービス情報削除要求４０３をＱｏＳ Ｐｏｌｉｃｙ Ｓｅｒｖｅｒ５に送信する。サービス情報削除要求４０３には、ＳＩＰ Ｓｅｓｓｉｏｎを識別するＳｅｓｓｉｏｎ−ＩＤが含まれる。
ＱｏＳ Ｐｏｌｉｃｙ Ｓｅｒｖｅｒ５は、サービス情報削除要求４０３を受けてＳｅｓｓｉｏｎに属するＦｌｏｗを検索し、Ｆｌｏｗ削除要求４０４をＡＧＷ７に送信する。Ｆｌｏｗ削除要求４０４は、Ｌｉｎｅ−ＩＤ、Ｔｅｒｍｉｎａｌ−ＩＤ及びＦｌｏｗ Ｆｉｌｔｅｒを指定する。
ＡＧＷ７は、Ｆｌｏｗ削除要求４０４によって指定されたＦｌｏｗをローカルのテーブル（図示省略）から削除し、確認応答４０５を返信する。
ＱｏＳ Ｐｏｌｉｃｙ Ｓｅｒｖｅｒ５は、サービス情報及びＦｌｏｗ認可情報を、Ｓｅｒｖｉｃｅ Ｉｎｆｏｒｍａｔｉｏｎ Ｔａｂｌｅ（第３図Ｂ）及びＦｌｏｗ Ｔａｌｂｅ（第３図Ｃ）から削除する。さらに、ＱｏＳ Ｐｏｌｉｃｙ Ｓｅｒｖｅｒ５は、ＳＩＰ Ｓｅｒｖｅｒ３に確認応答４０６を送信する（Ｆ７）。Ｆ７において、ＱｏＳ Ｐｏｌｉｃｙ Ｓｅｒｖｅｒ５は、必要に応じてＰＯＮの回線保証帯域を制御する。
第１５図は、本発明の第１の実施の形態のＱｏＳ Ｐｏｌｉｃｙ Ｓｅｒｖｅｒ５が実行するサービス情報／Ｆｌｏｗ認可削除処理（第１４図のＦ７）を示すフローチャートである。
まず、ＱｏＳ Ｐｏｌｉｃｙ Ｓｅｒｖｅｒ５は、削除するＦｌｏｗの回線情報をＬｉｎｅ Ｔａｂｌｅ（第３図Ｄ）から検索する（４２１）。
次に、ＱｏＳ Ｐｏｌｉｃｙ Ｓｅｒｖｅｒ５は、ステップ４２１において検索された回線情報に含まれる現在帯域（１３６）が最低保証帯域（１３４）を超えるか否かを判定する（４２２）。
ステップ４２２において、現在帯域（１３６）が最低保証帯域（１３４）を超えないと判定された場合、ＱｏＳ Ｐｏｌｉｃｙ Ｓｅｒｖｅｒ５は、ステップ４２３から４２５の処理をスキップする。
一方、ステップ４２２において、現在帯域（１３６）が最低保証帯域（１３４）を超えると判定された場合、ステップ４２１において検索された現在帯域（１３６）と、削除するＦｌｏｗの帯域（１１４）との差が、最低保証帯域（１３４）より大きいか否かを判定する（４２３）。
ステップ４２３において、算出された差が最低保証帯域（１３４）より大きいと判定された場合、ＱｏＳ Ｐｏｌｉｃｙ Ｓｅｒｖｅｒ５は、ＰＯＮの保証帯域を、現在帯域（１３６）とＦｌｏｗ帯域（１１４）との差まで減少させる（４２４）。
一方、ステップ４２３において、算出された差が最低保証帯域（１３４）より小さいと判定された場合、ＱｏＳ Ｐｏｌｉｃｙ Ｓｅｒｖｅｒ５は、ＰＯＮの保証帯域を、最低保証帯域（１３４）まで減少させる（４２５）。
次に、ＱｏＳ Ｐｏｌｉｃｙ Ｓｅｒｖｅｒ５は、ステップ４２１において検索された現在帯域（１３６）からＦｌｏｗ帯域（１１４）を差し引く（４２６）。
次に、ＱｏＳ Ｐｏｌｉｃｙ Ｓｅｒｖｅｒ５は、Ｆｌｏｗ認可情報を、Ｆｌｏｗ Ｔａｂｌｅ（第３図Ｃ）から削除する（４２７）。
次に、ＱｏＳ Ｐｏｌｉｃｙ Ｓｅｒｖｅｒ５は、サービス情報を、Ｓｅｒｖｉｃｅ Ｉｎｆｏｒｍａｔｉｏｎ Ｔａｂｌｅ（第３図Ｄ）から削除する（４２８）。
最後に、ＱｏＳ Ｐｏｌｉｃｙ Ｓｅｒｖｅｒ５は、ＳＩＰ Ｓｅｒｖｅｒに確認応答を送信して（４２９）、処理を終了する。
以上、本発明の第１の実施の形態によれば、ＨＧＷ１１がＳＩＰメッセージに回線の識別子（Ｌｉｎｅ−ＩＤ）を含めてサービス網１４に送信する。その結果、回線単位でＱｏＳを制御することが可能になる。さらに、第１の実施の形態によれば、ＨＧＷ１１が端末の代わりにＱｏＳ設定要求をＡＧＷ７に送信する。その結果、通信事業者との間に信頼関係のある機器のみが、ＱｏＳ設定を制御することが可能になる。
次に、第１６図から第１８図を参照して、本発明の第２の実施の形態を説明する。第２の実施の形態の通信網の構成は、第１の実施の形態と共通である（第１図）。第１の実施の形態では、ＨＧＷ１１がＳＤＰ Ｏｆｆｅｒ／Ａｎｓｗｅｒを含むＳＩＰメッセージに回線ＩＤを追加していた。一方、第２の実施の形態は、端末の位置登録をするためのメッセージであるＳＩＰ ＲＥＧＩＳＴＥＲに回線ＩＤが追加される点で、第１の実施の形態と異なる。このため、第２の実施の形態によれば、回線ＩＤを最初の位置登録時に一回登録すれば、以後その情報を継続して使用することができる。
第２の実施の形態では、ＳＩＰ Ｓｅｒｖｅｒ３が、第１６図Ａに示すＲｅｇｉｓｔｒａｔｉｏｎ Ｔａｂｌｅと、第１６図Ｂに示すＳＩＰ Ｓｅｓｓｉｏｎ Ｔａｂｌｅを備える。
第１６図Ａは、本発明の第２の実施の形態のＳＩＰ Ｓｅｒｖｅｒ３が保持するＲｅｇｉｓｔｒａｔｉｏｎ Ｔａｂｌｅの説明図である。
Ｒｅｇｉｓｔｒａｔｉｏｎ Ｔａｂｌｅ（第１６図Ａ）は、端末の登録情報を管理するために使用される。Ｒｅｇｉｓｔｒａｔｉｏｎ Ｔａｂｌｅ（第１６図Ａ）は、端末の公開アドレスを示すＡｏＲ（Ａｄｄｒｅｓｓ ｏｆ Ｒｅｃｏｒｄ）５０１、端末の通信アドレスを示すＣｏｎｔａｃｔ Ａｄｄｒｅｓｓ５０２、回線を識別するＬｉｎｅ−ＩＤ５０３、及び、登録の有効期限を示すＥｘｐｉｒｅｓ５０４から構成される。
第１６図Ｂは、本発明の第２の実施の形態のＳＩＰ Ｓｅｒｖｅｒ３が保持するＳＩＰ Ｓｅｓｓｉｏｎ Ｔａｂｌｅの説明図である。
ＳＩＰ Ｓｅｓｓｉｏｎ Ｔａｂｌｅ（第１６図Ｂ）は、ＳＩＰ Ｓｅｓｓｉｏｎ状態を管理するために使用される。ＳＩＰ Ｓｅｓｓｉｏｎ Ｔａｂｌｅ（第１６図Ｂ）は、 ＳＩＰ Ｓｅｓｓｉｏｎを一意に識別するＳＩＰ Ｄｉａｌｏｇ ＩＤ５１１、発信端末を識別するＣａｌｌｅｒ’ｓ ＩＤ５１２、着信端末を識別するＣａｌｌｅｅ’ｓ ＩＤ５１３、Ｓｅｓｓｉｏｎ状態を示すＳｔａｔｅ５１４、ＳＤＰ Ｏｆｆｅｒ５１５、及び、ＳＤＰ Ａｎｓｗｅｒ５１６から搆成される。
ＳＩＰ Ｄｉａｌｏｇ ＩＤ５１１は、Ｃａｌｌ−ＩＤ５１１ａ、Ｆｒｏｍ ｔａｇ５１１ｂ及びＴｏ ｔａｇ５１１ｃから構成される。
Ｃａｌｌｅｒ’ｓ ＩＤ５１２は、Ｆｒｏｍ ＵＲＩ５１２ａから構成される。
Ｃａｌｌｅｅ’ｓ ＩＤ５１３は、Ｔｏ ＵＲＩ５１３ａから構成される。
第１の実施の形態のＳＩＰ Ｓｅｓｓｉｏｎ Ｔａｂｌｅ（第２図Ｂ）と異なり、Ｃａｌｌｅｒ’ｓ ＩＤ５１２及びＣａｌｌｅｅ’ｓ ＩＤ５１３はＬｉｎｅ−ＩＤを含まない。
第１７図は、本発明の第２の実施の形態におけるセッション確立のための処理を示すシーケンス図である。
第１７図では、ホーム網１７に接続された端末（ＵＡ１２）が、ＳＩＰ Ｓｅｒｖｅｒ（１、３）に対して位置登録を行う。そして、端末（ＵＡ１２）と端末（ＵＡ８）の間でセッションが確立される。以下、第１７図のシーケンスの詳細を説明する。
まず、端末（ＵＡ１２）は、ＳＩＰ ＲＥＧＩＳＴＥＲ５３１を送信する。
ＨＧＷ１１は、ＲＥＧＩＳＴＥＲ５３１にＬｉｎｅ−ＩＤを追加してＳＩＰ Ｓｅｒｖｅｒ３に転送する（Ｆ１１）。
ＳＩＰ Ｓｅｒｖｅｒ３は、ＲＥＧＩＳＴＥＲ５３１からＬｉｎｅ−ＩＤを削除し、削除したＬｉｎｅ−ＩＤを、端末のＡｏＲと共にＲｅｇｉｓｔｒａｔｉｏｎ Ｔａｂｌｅ（第１６図Ａ）に記録する。そして、ＳＩＰ Ｓｅｒｖｅｒ３は、ＲＥＧＩＳＴＥＲ５３１をＳＩＰ Ｓｅｒｖｅｒ１に転送する。
ＳＩＰ Ｓｅｒｖｅｒ１は、ＲＥＧＩＳＴＥＲ５３１に対する２００応答５３２を返信する。２００応答５３２は、ＲＥＧＩＳＴＥＲ５３１と逆の経路を辿り、端末（ＵＡ１２）に到達する。
次に、端末（ＵＡ１２）は、ＳＤＰ Ｏｆｆｅｒを含むＳＩＰ ＩＮＶＩＴＥ５３３を送信する。ＩＮＶＩＴＥ５３３は、ＨＧＷ１１、ＳＩＰ Ｓｅｒｖｅｒ３、ＳＩＰ Ｓｅｒｖｅｒ１及びＳＩＰ Ｓｅｒｖｅｒ２を経由して端末（ＵＡ８）に到達する。
端末（ＵＡ８）は、ＳＤＰ Ａｎｓｗｅｒを含む１８３応答５３４を返信する。
端末（ＵＡ１２）は、１８３応答５３４に対するＰＲＡＣＫ５３５を返信する。
端末（ＵＡ８）は、ＰＲＡＣＫ５３５に対する２００応答５３６を返信する。
ＳＩＰ Ｓｅｒｖｅｒ３は、ＳＤＰ Ａｎｓｗｅｒの転送を契機として、サービス情報５３７をＱｏＳ Ｐｏｌｉｃｙ Ｓｅｒｖｅｒ５に通知する（Ｆ１２）。このサービス情報通知５３７の通知は、ＰＲＡＣＫ５３５の送信の前又は後のいずれに実行されてもよいし、２００応答５３６の送信の前又は後のいずれに実行されてもよい。
サービス情報通知５３７は、Ｓｅｓｓｉｏｎ−ＩＤ、Ｌｉｎｅ−ＩＤ、Ｔｅｒｍｉｎａｌ−ＩＤ、ＦｌｏｗＦｉｌｔｅｒ及び帯域を含む。
以降のシーケンスは、第５図の２１６〜２２９と同様であるため省略する。
次に、第１８図及び第１９図を参照して、第１７図のシーケンスに特徴的な処理を説明する。
第１８図は、本発明の第２の実施の形態のＨＧＷ１１が実行するＬｉｎｅ−ＩＤ追加判定処理（第１７図のＦ１１）を示すフローチャートである。
最初に、ＨＧＷ１１は、転送するＳＩＰ ＭｅｓｓａｇｅがＲＥＧＩＳＴＥＲであるか否かを判定する（５５１）。
ステップ５５１において、転送するＳＩＰ ＭｅｓｓａｇｅがＲＥＧＩＳＴＥＲでないと判定された場合、ＨＧＷ１１は処理を終了する。
一方、ステップ５５１において、転送するＳＩＰ ＭｅｓｓａｇｅがＲＥＧＩＳＴＥＲであると判定された場合、ＨＧＷ１１は、ＲＥＧＩＳＴＥＲにＬｉｎｅ−ＩＤを追加し（５５２）、処理を終了する。
第１８図の処理を実行することによって、所定の種類の信号（第１８図の例では、ＲＥＧＩＳＴＥＲ）のみに回線ＩＤが追加されるため、処理を効率化することができる。
第１９図は、本発明の第２の実施の形態のＳＩＰ Ｓｅｒｖｅｒ３が実行するサービス情報通知処理（第１７図のＦ１２）を示すフローチャートである。
第１９図に示す処理は、第１の実施の形態のサービス情報通知処理（第９図）と以下の点で異なる。
まず、第９図のステップ２７４では、端末が固定アクセス網１６に接続されているか否かを、ＳＩＰ Ｓｅｓｓｉｏｎ Ｔａｂｌｅ（第２図Ｂ）のＬｉｎｅ−ＩＤフィールド（７２ｂ又は７３ｂ）が設定されているか否かに基づいて判定していた。これに対し、第１９図のステップ５７４では、ＳＩＰ Ｒｅｇｉｓｔｒａｔｉｏｎ Ｔａｂｌｅ（第１６図Ａ）に端末が登録されているか否かに基づいて、同様の判定が実行される。
また、第９図のステップ２７５では、Ｌｉｎｅ−ＩＤをＳＩＰ Ｓｅｓｓｉｏｎ Ｔａｂｌｅ（第２図Ｂ）のＬｉｎｅ−ＩＤフィールド（７２ｂ又は７３ｂ）から取得していた。これに対し、第１９図のステップ５７５では、ＳＩＰ Ｒｅｇｉｓｔｒａｔｉｏｎ Ｔａｂｌｅ（第１６図Ａ）のＬｉｎｅ−ＩＤフィールド（５０３）からＬｉｎｅ−ＩＤが取得される。
上記の相違点を除いて、第１９図のステップ５７１から５７９は、それぞれ、第９図のステップ２７１から２７９と同様である。
次に、第２０図から第２５図を参照して、本発明の第３の実施の形態を説明する。
第２０図は、本発明の第３の実施の形態における通信網の構成例を示す説明図である。
第１及び第２の実施の形態では、固定アクセス網１６のＡＧＷ７とＨＧＷ１１の間で、ＩｎｔＳｅｒｖ（Ｉｎｔｅｇｒａｔｅｄ Ｓｅｒｖｉｃｅｓ）モデルに基づくフロー単位の帯域保証が実行されていた。一方、第３の実施の形態では、第１及び第２の実施の形態と異なり、ＤｉｆｆＳｅｒｖ（Ｄｉｆｆｅｒｅｎｔｉａｔｅｄ Ｓｅｒｖｉｃｅｓ）モデルに基づく優先制御が実行される。
第２０図に示す通信網は、アクセス非依存のサービス網７１４、移動アクセス網７１５、固定アクセス網７１６及びホーム網７１７から構成される。以下に説明するように、第３の実施の形態によれば、ＤｉｆｆＳｅｒｖモデルに基づく優先制御を行う場合にも、セッション制御信号に含まれる情報を用いて回線単位の帯域制御を行うことができる。
サービス網７１４は、ＳＩＰ Ｓｅｒｖｅｒ（７０１、７０２及び７０３）、ＱｏＳ Ｐｏｌｉｃｙ Ｓｅｒｖｅｒ（７０４及び７０５）、及び、ＡＧＷ（７０６及び７０７）
を備える。
移動アクセス網７１５は、ＵＡ７０８を備える。
固定アクセス網７１６は、ＯＬＴ７０９及びＯＮＵ７１０を備える。
ホーム網７１７は、ＨＧＷ７１１及びＵＡ（７１２及び７１３）を備える。ＨＧＷ７１１には、回線ＩＤ（Ｌｉｎｅ−ＩＤ：５６７８９）が設定されている。
固定アクセス網７１６では、次のようなＱｏＳ処理が実行される。
ＡＧＷ７０７及びＨＧＷ７１１は、Ｌａｙｅｒ３以上で優先フローを識別し、ＩＰｖ４ヘッダのＴＯＳフィールド又はＩＰｖ６ヘッダのＴｒａｆｆｉｃ Ｃｌａｓｓフィールドにマーキングを行う。さらに、ＡＧＷ７０７及びＨＧＷ７１１は、マーキング結果に従い優先制御を行う。第１及び第２の実施の形態と異なり、優先フローを識別するためのフィルタ情報は静的に設定される。
ＯＬＴ７０９及びＯＮＵ７１０は、Ｌａｙｅｒ２レベルで優先フローの帯域保証を行う。優先フローの識別は、ＡＧＷ７０７及びＨＧＷ７１１によるマーキング結果に従う。保証帯域は、必要に応じてＱｏＳ Ｐｏｌｉｃｙ Ｓｅｒｖｅｒ７０５によって制御される。
第２１図Ａは、本発明の第３の実施の形態のＱｏＳ Ｐｏｌｉｃｙ Ｓｅｒｖｅｒ７０５の装置構成を示すブロック図である。
ＱｏＳ Ｐｏｌｉｃｙ Ｓｅｒｖｅｒ７０５は、Ｈａｒｄ Ｄｉｓｋ７３１、ＣＰＵ７３２、Ｍｅｍｏｒｙ７３３、ＩＦ（７３４ａ、７３４ｂ及び７３４ｃ）、及び、バス７３５を備える。ＱｏＳ Ｐｏｌｉｃｙ Ｓｅｒｖｅｒ７０５の処理手順は、Ｍｅｍｏｒｙ７３３に格納されており、ＣＰＵ７３２が順次それを読み出して実行する。
ＱｏＳ Ｐｏｌｉｃｙ Ｓｅｒｖｅｒ７０５は、第２１図Ｂに示すＳｅｒｖｉｃｅ Ｉｎｆｏｒｍａｔｉｏｎ Ｔａｂｌｅ、及び、第２１図Ｃに示すＬｉｎｅ Ｔａｂｌｅを保持する。
第２１図Ｂは、本発明の第３の実施の形態のＱｏＳ Ｐｏｌｉｃｙ Ｓｅｒｖｅｒ７０５が保持するＳｅｒｖｉｃｅ Ｉｎｆｏｒｍａｔｉｏｎ Ｔａｂｌｅの説明図である。
Ｓｅｒｖｉｃｅ Ｉｎｆｏｒｍａｔｉｏｎ Ｔａｂｌｅ（第２１図Ｂ）は、ＳＩＰ Ｓｅｒｖｅｒ７０３に認可したサービス情報を管理するためのテーブルである。Ｓｅｒｖｉｃｅ Ｉｎｆｏｒｍａｔｉｏｎ Ｔａｂｌｅ（第２１図Ｂ）は、ＳＩＰ Ｓｅｓｓｉｏｎを識別するＳｅｓｓｉｏｎ ＩＤ７５１、回線を識別するＬｉｎｅ−ＩＤ７５２、端末を識別するＴｅｒｍｉｎａｌ−ＩＤ７５３、フローを識別するＦｌｏｗ Ｆｉｌｔｅｒ７５４、及び、使用帯域を示すＢａｎｄｗｉｄｔｈ７５５から構成される。Ｆｌｏｗ Ｆｉｌｔｅｒ７５４は、Ｓｒｃ ＩＰ７５４ａ、Ｄｓｔ ＩＰ７５４ｂ、ｐｒｏｔｏ７５４ｃ、Ｓｒｃ Ｐｏｒｔ７５４ｄ及びＤｓｔ Ｐｏｒｔ７５４ｅから構成される。
第２１図Ｃは、本発明の第３の実施の形態のＱｏＳ Ｐｏｌｉｃｙ Ｓｅｒｖｅｒ７０５が保持するＬｉｎｅ Ｔａｂｌｅの説明図である。
Ｌｉｎｅ Ｔａｂｌｅ（第２１図Ｃ）は、回線の帯域を管理するためのテーブルである。Ｌｉｎｅ Ｔａｂｌｅ（第２１図Ｃ）は、回線を識別するＬｉｎｅ−ＩＤ７７１、ＯＮＵを識別するＯＮＵ−ＩＤ７７２、ＯＬＴを識別するＯＬＴ−ＩＤ７７３、回線の最低保証帯域Ｍｉｎ Ｂａｎｄｗｉｄｔｈ７７４、最大保証帯域Ｍａｘ Ｂａｎｄｗｉｄｔｈ７７５、現在帯域Ｃｕｒｒｅｎｔ Ｂａｎｄｗｉｄｔｈ７７６、及び、回線を使用するサービス情報（第２１図Ｂ Ｓｅｒｖｉｃｅ Ｉｎｆｏｒｍａｔｉｏｎ Ｔａｂｌｅ）へのポインタＰｏｉｎｔｅｒ ｔｏ Ｓｅｒｖｉｃｅ Ｉｎｆｏ． Ｔａｂｌｅ７７７から構成される。回線を使用するフローが複数存在する場合、Ｐｏｉｎｔｅｒ ｔｏ Ｓｅｒｖｉｃｅ Ｉｎｆｏ． Ｔａｂｌｅ７７７には複数のポインタが設定される。
第２２図Ａ及び第２２図Ｂは、本発明の第３の実施の形態におけるセッション確立のための処理を示すシーケンス図である。
第２２図Ａ及び第２２図Ｂでは、端末（ＵＡ７１２）がＤＨＣＰｖ６を使用してＨＧＷ７１１から回線ＩＤを取得する。そして、端末（ＵＡ７１２）自身がＳＩＰ ＩＮＶＩＴＥに回線ＩＤを含めて送信し、端末（ＵＡ７０８）との間にセッションを確立する。第１及び第２の実施の形態と異なり、本シーケンスでは、ＳＩＰ Ｓｅｒｖｅｒ７０３からのサービス情報通知と同時にＱｏＳ認可が実行される。
以下、第２２図Ａ及び第２２図Ｂの詳細を説明する。
第２２図Ａにおいて、端末（ＵＡ７１２）は、まずＤＨＣＰｖ６ Ｉｎｆｏｒｍａｔｉｏｎ−Ｒｅｑｕｅｓｔ７９１をＨＧＷ７１１に送信して、Ｌｉｎｅ−ＩＤを要求する。ＨＧＷ７１１は、ＤＨＣＰｖ６ Ｉｎｆｏｒｍａｔｉｏｎ−Ｒｅｐｌｙ７９２を返信して、Ｌｉｎｅ−ＩＤを通知する。
次に、端末（ＵＡ７１２）は、ＳＩＰ ＩＮＶＩＴＥ７９３ａをＳＩＰ Ｓｅｒｖｅｒ７０３に送信する。ＳＩＰ ＩＮＶＩＴＥ７９３ａは、ＳＤＰ Ｏｆｆｅｒ及びＬｉｎｅ−ＩＤを含む。
ＳＩＰ ＩＮＶＩＴＥ７９３ａには、これから確立しようとするセッションにおいて端末（ＵＡ７１２）が要求する帯域を示す情報が含まれる。
ＳＩＰ Ｓｅｒｖｅｒ７０３は、ＩＮＶＩＴＥ７９３ａからＬｉｎｅ−ＩＤを削除し、そのＬｉｎｅ−ＩＤをＳｅｓｓｉｏｎ情報と共に記録する。さらに、ＳＩＰ Ｓｅｒｖｅｒ７０３は、サービス認可要求７９４をＱｏＳ Ｐｏｌｉｃｙ Ｓｅｒｖｅｒ７０５に送信する。サービス認可要求７９４には、ＳＩＰ／ＳＤＰ Ｍｅｓｓａｇｅから抽出されたＳｅｓｓｉｏｎ−ＩＤ、Ｌｉｎｅ−ＩＤ、Ｔｅｒｍｉｎａｌ−ＩＤ、Ｆｌｏｗ Ｆｉｌｔｅｒ及び帯域が含まれる。サービス認可要求７９４に含まれる帯域は、Ｔｅｒｍｉｎａｌ−ＩＤによって識別される端末がセッションにおいて要求する帯域である。
ＱｏＳ Ｐｏｌｉｃｙ Ｓｅｒｖｅｒ７０５は、回線帯域を考慮して、サービス認可及びＰＯＮの帯域制御を行う（Ｆ２１）。
Ｆ２１に示すサービス認可に失敗した場合、ＱｏＳ Ｐｏｌｉｃｙ Ｓｅｒｖｅｒ７０５は、第２２図Ｂに示すエラー応答８１１を返信する。エラー応答８１１を受けたＳＩＰ Ｓｅｒｖｅｒ７０３は、端末（ＵＡ７１２）に４８８応答８１２を返信し、セッション確立が失敗する。
一方、Ｆ２１に示すサービス認可に成功した場合、ＱｏＳ Ｐｏｌｉｃｙ Ｓｅｒｖｅｒ７０５は、第２２図Ａに示す成功応答７９５を返信する。成功応答７９５を受けたＳＩＰ Ｓｅｒｖｅｒ７０３は、ＩＮＶＩＴＥ７９３ｂを端末（ＵＡ７０８）に転送する。
端末（ＵＡ７０８）は、ユーザの呼び出しを開始し、１８０応答７９６を返信する。さらに、端末（ＵＡ７０８）は、ユーザがオフフックしたことを契機に、ＳＤＰ Ａｎｓｗｅｒを含む２００応答７９７を送信する。
端末（ＵＡ７１２）は、ＡＣＫ７９８を返信する。その結果、Ｍｅｄｉａ Ｆｌｏｗ７９９の送受信が開始する。
なお、第３の実施の形態では、ＵＡ７１２がＨＧＷ７１１からＬｉｎｅ−ＩＤを取得し（７９１、７９２）、そのＬｉｎｅ−ＩＤを含むＳＩＰ ＩＮＶＩＴＥ７９３ａをＳＩＰ Ｓｅｒｖｅｒ７０３に送信する。しかし、第１の実施の形態と同様に、ＨＧＷ７１１が、ＵＡ７１２から受信したＳＩＰ ＩＮＶＩＴＥ（第５図のＳＩＰ ＩＮＶＩＴＥ２１１参照）にＬｉｎｅ−ＩＤを追加し（第５図のＦ１参照）、そのＳＩＰ ＩＮＶＩＴＥをＳＩＰ Ｓｅｒｖｅｒ７０３に送信してもよい。
逆に、第１の実施の形態において、ＵＡ１２が、第３の実施の形態と同様、ＨＧＷ１１からＬｉｎｅ−ＩＤを取得し、そのＬｉｎｅ−ＩＤを含むＳＩＰ ＩＮＶＩＴＥをＳＩＰ Ｓｅｒｖｅｒ３に送信してもよい。
第２３図は、本発明の第３の実施の形態のＱｏＳ Ｐｏｌｉｃｙ Ｓｅｒｖｅｒ７０５が実行するサービス認可処理（第２２図ＡのＦ２１）を説明するフローチャートである。
ＱｏＳ Ｐｏｌｉｃｙ Ｓｅｒｖｅｒ７０５は、まず、受信したサービス認可要求に対応するエントリをＳｅｒｖｉｃｅ Ｉｎｆｏｒｍａｔｉｏｎ Ｔａｂｌｅ（第２１図Ｂ）に設定する（８３１）。
次に、ＱｏＳ Ｐｏｌｉｃｙ Ｓｅｒｖｅｒ７０５は、サービス情報のＬｉｎｅ−ＩＤ（７５２）に基づいて、Ｌｉｎｅ Ｔａｂｌｅ（第２１図Ｃ）から回線情報を検索する（８３２）。具体的には、受信したＱｏＳ認可要求に含まれるＬｉｎｅ−ＩＤ（７５２）と同一の値がＬｉｎｅ−ＩＤ（７７１）として登録されているエントリをＬｉｎｅ Ｔａｂｌｅ（第２１図Ｃ）から検索する。
次に、ＱｏＳ Ｐｏｌｉｃｙ Ｓｅｒｖｅｒ７０５は、ステップ８３２において検索された現在帯域（７７６）と、サービス情報の帯域（７５５）との和が、ステップ８３２において検索された最大保証帯域（７７５）を超えるか否かを判定する（８３３）。
ステップ８３３において、現在帯域（７７６）とサービス情報の帯域（７５５）との和が最大保証帯域（７７５）を超えると判定された場合、ＱｏＳ Ｐｏｌｉｃｙ Ｓｅｒｖｅｒ７０５は、ステップ８３１において設定されたエントリを削除し、さらに、ＳＩＰ Ｓｅｒｖｅｒにエラー応答８１１（第２２図Ｂ参照）を送信して、処理を終了する（８３４）。
一方、ステップ８３３において、現在帯域（７７６）とサービス情報の帯域（７５５）との和が最大保証帯域（７７５）を超えないと判定された場合、ＱｏＳ Ｐｏｌｉｃｙ Ｓｅｒｖｅｒ７０５は、ステップ８３２において検索された現在帯域（７７６）とサービス情報の帯域（７５５）との和が、ステップ８３２において検索された最低保証帯域（７７４）を超えるか否かを判定する（８３５）。
ステップ８３３において、現在帯域（７７６）とサービス情報の帯域（７５５）との和が最低保証帯域（７７４）を超えると判定された場合、ＱｏＳ Ｐｏｌｉｃｙ Ｓｅｒｖｅｒ７０５は、ＰＯＮの保証帯域を、ステップ８３２において検索された現在帯域（７７６）とサービス情報の帯域（７５５）との和まで増加させる（８３６）。
一方、ステップ８３３において、現在帯域（７７６）とサービス情報の帯域（７５５）との和が最低保証帯域（７７４）を超えないと判定された場合、ＱｏＳ Ｐｏｌｉｃｙ Ｓｅｒｖｅｒ７０５は、ステップ８３６の処理をスキップする。
最後に、ＱｏＳ Ｐｏｌｉｃｙ Ｓｅｒｖｅｒ７０５は、ステップ８３２において検索された現在帯域（７７６）にサービス情報の帯域（７５５）を加算し、ＳＩＰ Ｓｅｒｖｅｒに成功応答７９５（第２２図Ａ参照）を送信して、処理を終了する。
第１の実施の形態における第１２図の処理と同様、上記の第２３図の処理によって、同一のＬｉｎｅ−ＩＤと関連付けられたセッションにおいて要求される帯域に基づいて、ＱｏＳが制御される。同一のＬｉｎｅ−ＩＤと関連付けられたセッションとは、同一のＨＧＷ７１１を経由するセッション（すなわち、固定アクセス網７１６において同一の回線を使用するセッション）である。
すなわち、同一の回線を使用する複数のＦｌｏｗが存在する場合、それらの全てのＦｌｏｗにおいて要求される帯域の合計値が算出される（８３３、８３５）。そして、算出された合計値が、固定アクセス網１６における保証帯域として設定される（８３６）。ただし、算出された合計値が最大保証帯域を超える場合、固定アクセス網７１６における保証帯域は変更されずに、エラーが応答される（８３４）。算出された合計値が最低保証帯域を超えない場合、最低保証帯域が、固定アクセス網１６における保証帯域として設定される。
第２４図は、本発明の第３の実施の形態におけるセッション切断のために実行される処理を示すシーケンス図である。
本シーケンスでは、まず、端末（ＵＡ７１２）がＢＹＥ８５１を送信する。ＢＹＥ８５１を受けた端末（ＵＡ７０８）は、２００応答８５２を返信する。
ＳＩＰ Ｓｅｒｖｅｒ７０３は、ＢＹＥ８５１の転送を契機に、サービス認可削除要求８５３をＱｏＳ Ｐｏｌｉｃｙ Ｓｅｒｖｅｒ７０５に送信する。この要求は、２００応答８５２より早く送信されてもよい。サービス認可削除要求８５３は、Ｓｅｓｓｉｏｎを識別するＳｅｓｓｉｏｎ−ＩＤを含む。
ＱｏＳ Ｐｏｌｉｃｙ Ｓｅｒｖｅｒ７０５は、Ｓｅｓｓｉｏｎ−ＩＤに対応するサービス情報を削除し、ＰＯＮの保証帯域を制御する（Ｆ２２）。
第２５図は、本発明の第３の実施の形態のＱｏＳ Ｐｏｌｉｃｙ Ｓｅｒｖｅｒ７０５が実行するサービス認可削除処理（第２４図のＦ２２）を説明するフローチャートである。
ＱｏＳ Ｐｏｌｉｃｙ Ｓｅｒｖｅｒ７０５は、まず、指定されたＳｅｓｓｉｏｎ−ＩＤに関連するサービス情報をＳｅｒｖｉｃｅ Ｉｎｆｏｒｍａｔｉｏｎ Ｔａｂｌｅ（第２１図Ｂ）から検索する（８７１）。
次に、ＱｏＳ Ｐｏｌｉｃｙ Ｓｅｒｖｅｒ７０５は、ステップ８７１において検索された全てのサービス情報に関して、ループ（８７２−８８０）の処理を実行する。
まず、ＱｏＳ Ｐｏｌｉｃｙ Ｓｅｒｖｅｒ７０５は、Ｓｅｒｖｉｃｅ Ｉｎｆｏｒｍａｔｉｏｎ Ｔａｂｌｅ（第２１図Ｂ）のＬｉｎｅ−ＩＤ（７５２）を使用して、Ｌｉｎｅ Ｔａｂｌｅ（第２１図Ｃ）から回線情報を検索する（８７３）。
次に、ＱｏＳ Ｐｏｌｉｃｙ Ｓｅｒｖｅｒ７０５は、ステップ８７３において検索された現在帯域（７７６）が最低保証帯域（７７４）を超えるか否かを判定する（８７４）。
ステップ８７４において、現在帯域（７７６）が最低保証帯域（７７４）を超えないと判定された場合、ＱｏＳ Ｐｏｌｉｃｙ Ｓｅｒｖｅｒ７０５は、ステップ８７５から８７７までの処理をスキップする。
一方、ステップ８７４において、現在帯域（７７６）が最低保証帯域（７７４）を超えると判定された場合、ＱｏＳ Ｐｏｌｉｃｙ Ｓｅｒｖｅｒ７０５は、ステップ８７３において検索された現在帯域（７７６）とサービス情報の帯域（７５５）の差が、最低保証帯域（７７４）よりも大きいか否かを判定する（８７５）。
ステップ８７５において、現在帯域（７７６）とサービス情報の帯域（７５５）の差が最低保証帯域（７７４）よりも大きいと判定された場合、ＱｏＳ Ｐｏｌｉｃｙ Ｓｅｒｖｅｒ７０５は、ＰＯＮの保証帯域を、現在帯域（７７６）とサービス情報の帯域（７５５）の差まで減少させる（８７６）。
一方、現在帯域（７７６）とサービス情報の帯域（７５５）の差が最低保証帯域（７７４）以下であると判定された場合、ＱｏＳ Ｐｏｌｉｃｙ Ｓｅｒｖｅｒ７０５は、ＰＯＮの保証帯域を、最低保証帯域（７７４）まで減少させる（８７７）。
次に、ＱｏＳ Ｐｏｌｉｃｙ Ｓｅｒｖｅｒ７０５は、ステップ８７３において検索された現在帯域（７７６）からサービス情報の帯域（７５５）を差し引く（８７８）。
次に、ＱｏＳ Ｐｏｌｉｃｙ Ｓｅｒｖｅｒ７０５は、サービス情報を、Ｓｅｒｖｉｃｅ Ｉｎｆｏｒｍａｔｉｏｎ Ｔａｂｌｅ（第２１図Ｂ）から削除する（８７９）。
以上で、ＱｏＳ Ｐｏｌｉｃｙ Ｓｅｒｖｅｒ７０５は、第２５図に示す処理を終了する。
第１図の通信網は、アクセス非依存のサービス網１４、移動アクセス網１５、固定アクセス網１６及びホーム網１７によって構成される。ホーム網１７は、固定アクセス網１６に接続されている。
サービス網１４は、ＳＩＰ Ｓｅｒｖｅｒ（１、２及び３）、ＱｏＳ Ｐｏｌｉｃｙ Ｓｅｒｖｅｒ（４及び５）及びＡＧＷ（６及び７）を備える。ＳＩＰ Ｓｅｒｖｅｒ１は、ＳＩＰ ＲｅｇｉｓｔｒａｒおよびＰｒｏｘｙとして動作し、端末のロケーション管理とサービス制御を行う。ＳＩＰ Ｓｅｒｖｅｒ２及び３は、ＳＩＰ Ｐｒｏｘｙとして動作し、それぞれ、移動アクセス網１５及び固定アクセス網１６の端末を収容する。ＩＭＳ／ＭＭＤでは、ＳＩＰ Ｓｅｒｖｅｒ１をＳ−ＣＳＣＦ（Ｓｅｒｖｉｎｇ Ｃａｌｌ Ｓｅｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｆｕｎｃｔｉｏｎ）、ＳＩＰ Ｓｅｒｖｅｒ（２及び３）をＰ−ＣＳＣＦ（Ｐｒｏｘｙ Ｃａｌｌ Ｓｅｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｆｕｎｃｔｉｏｎ）と呼ぶ。
ＱｏＳ Ｐｏｌｉｃｙ Ｓｅｒｖｅｒ（４及び５）は、ＳＩＰ Ｓｅｒｖｅｒ（２及び３）から通知されたサービス情報に基づいて、ＡＧＷ（６及び７）のＱｏＳ（サービス品質）設定を制御する。
ＡＧＷ（６及び７）は、それぞれ、移動アクセス網１５とサービス網１４との境界、及び、固定アクセス網１６とサービス網１４との境界に設置され、各アクセス網の端末を収容する。
移動アクセス網１５は、ＵＡ（Ｕｓｅｒ Ａｇｅｎｔ）８を収容する。ＵＡ８には、ＳＩＰ ＵＲＩ（ｓｉｐ：ｕａ８＠ｈｉｔａｃｈｉ．ｃｏｍ）が設定されている。
固定アクセス網１６は、アクセス設備としてＰＯＮ（Ｐａｓｓｉｖｅ Ｏｐｔｉｃａｌ Ｎｅｔｗｏｒｋ）を使用しており、ＯＬＴ（Ｏｐｔｉｃａｌ Ｌｉｎｅ Ｔｅｒｍｉｎａｌ）９及びＯＮＵ（Ｏｐｔｉｃａｌ Ｎｅｔｗｏｒｋ Ｕｎｉｔ）１０を備える。
ホーム網１７は、ＨＧＷ１１、ＵＡ（１２及び１３）を備える。ＨＧＷ１１には、回線を識別するためのＩＤ（Ｌｉｎｅ−ＩＤ：１２３４５６）が設定されている。ＵＡ（１２及び１３）には、ＳＩＰ ＵＲＩ（それぞれ、ｓｉｐ：ｕａ１２＠ｈｉｔａｃｈｉ．ｃｏｍ、及び、ｓｉｐ：ｕａ１３＠ｈｉｔａｃｈｉ．ｃｏｍ）が設定されている。
固定アクセス網１６では、次のようなＱｏＳ処理を行う。ＡＧＷ７及びＨＧＷ１１は、Ｌａｙｅｒ３以上でフロー単位の帯域保証を行う。また、ＡＧＷ７及びＨＧＷ１１は、優先フローを識別し、ＩＰｖ４ヘッダのＴＯＳ（Ｔｙｐｅ ｏｆ Ｓｅｒｖｉｃｅ）フィールド又はＩＰｖ６ヘッダのＴｒａｆｆｉｃ Ｃｌａｓｓフィールドにマーキングを行う。フローを識別するためのフィルタ情報及び保証帯域は、セッション確立時に動的に設定される。
ＯＬＴ９及びＯＮＵ１０は、Ｌａｙｅｒ２レベルで優先フローの帯域保証を行う。優先フローの識別は、ＡＧＷ７及びＨＧＷ１１によるマーキングの結果に従う。保証帯域は、必要に応じて、ＱｏＳ Ｐｏｌｉｃｙ Ｓｅｒｖｅｒ５が制御する。
第２図Ａは、本発明の第１の実施の形態のＳＩＰ Ｓｅｒｖｅｒ３の装置構成を示すブロック図である。
ＳＩＰ Ｓｅｒｖｅｒ３は、Ｈａｒｄ Ｄｉｓｋ３１、ＣＰＵ３２、Ｍｅｍｏｒｙ３３、ＩＦ（３４ａ、３４ｂ及び３４ｃ）及びバス３５を備える。ＳＩＰ Ｓｅｒｖｅｒ３の処理手順は、Ｍｅｍｏｒｙ ３３に格納されており、ＣＰＵ３２が順次それを読み出して実行する。
ＳＩＰ Ｓｅｒｖｅｒ３は、ＳＩＰ Ｓｅｓｓｉｏｎを管理するために、第２図Ｂに示すＳＩＰ Ｓｅｓｓｉｏｎ Ｔａｂｌｅを保持する。ＳＩＰ Ｓｅｓｓｉｏｎ Ｔａｂｌｅは、Ｈａｒｄ Ｄｉｓｋ３１又はＭｅｍｏｒｙ３３に格納される。
第２図Ｂは、本発明の第１の実施の形態のＳＩＰ Ｓｅｒｖｅｒ３が保持するＳＩＰ Ｓｅｓｓｉｏｎ Ｔａｂｌｅの説明図である。
ＳＩＰ Ｓｅｓｓｉｏｎ Ｔａｂｌｅ（第２図Ｂ）は、ＳＩＰ Ｓｅｓｓｉｏｎを一意に識別するＳＩＰ Ｄｉａｌｏｇ ＩＤ７１、発信端末情報（すなわち、発信側の端末を識別する情報）を示すＣａｌｌｅｒ’ｓ ＩＤ７２、着信端末情報（すなわち、着信側の端末を識別する情報）を示すＣａｌｌｅｅ’ｓ ＩＤ７３、セッション状態を示すＳｔａｔｅ７４、ＳＤＰ Ｏｆｆｅｒ７５、及び、ＳＤＰ Ａｎｓｗｅｒ７６から構成される。
ＳＩＰ Ｄｉａｌｏｇ７１は、Ｃａｌｌ−ＩＤ７１ａ、Ｆｒｏｍ ｔａｇ７１ｂ及びＴｏ ｔａｇ７１ｃから構成される。Ｃａｌｌｅｒ’ｓ ＩＤ７２は、Ｆｒｏｍ ＵＲＩ７２ａ及びＬｉｎｅ−ＩＤ７２ｂから構成される。Ｃａｌｌｅｅ’ｓ ＩＤ７３は、Ｔｏ ＵＲＩ７３ａ及びＬｉｎｅ−ＩＤ７３ｂから構成される。ＳＩＰ Ｓｅｒｖｅｒ３は、ＳＩＰ Ｍｅｓｓａｇｅ転送時にこれらのパラメータを取得し、取得したパラメータをＳＩＰ Ｓｅｓｓｉｏｎ Ｔａｂｌｅに設定する。
第３図Ａは、本発明の第１の実施の形態のＱｏＳ Ｐｏｌｉｃｙ Ｓｅｒｖｅｒ５の装置構成を示すブロック図である。
ＱｏＳ Ｐｏｌｉｃｙ Ｓｅｒｖｅｒ５は、Ｈａｒｄ Ｄｉｓｋ４１、ＣＰＵ４２、Ｍｅｍｏｒｙ４３、ＩＦ（４４ａ、４４ｂ及び４４ｃ）及びバス４５を備える。ＱｏＳ Ｐｏｌｉｃｙ Ｓｅｒｖｅｒ５の処理手順は、Ｍｅｍｏｒｙ ４３に格納されており、ＣＰＵ４２が順次それを読み出して実行する。
ＱｏＳ Ｐｏｌｉｃｙ Ｓｅｒｖｅｒ５は、第３図Ｂに示すＳｅｒｖｉｃｅ Ｉｎｆｏｒｍａｔｉｏｎ Ｔａｂｌｅ、第３図Ｃに示すＦｌｏｗ Ｔａｂｌｅ、及び、第３図Ｄに示すＬｉｎｅ Ｔａｂｌｅを保持する。これらのテーブルは、Ｈａｒｄ Ｄｉｓｋ４１又はＭｅｍｏｒｙ ４３に格納される。
第３図Ｂは、本発明の第１の実施の形態のＱｏＳ Ｐｏｌｉｃｙ Ｓｅｒｖｅｒ５が保持するＳｅｒｖｉｃｅ Ｉｎｆｏｒｍａｔｉｏｎ Ｔａｂｌｅの説明図である。
Ｓｅｒｖｉｃｅ Ｉｎｆｏｒｍａｔｉｏｎ Ｔａｂｌｅ（第３図Ｂ）は、ＳＩＰ Ｓｅｒｖｅｒ３から通知されたサービス情報を管理するためのテーブルである。Ｓｅｒｖｉｃｅ Ｉｎｆｏｒｍａｔｉｏｎ Ｔａｂｌｅ（第３図Ｂ）は、ＳＩＰ Ｓｅｓｓｉｏｎを識別するＳｅｓｓｉｏｎ ＩＤ９１、回線を識別するＬｉｎｅ−ＩＤ９２、端末を識別するＴｅｒｍｉｎａｌ−ＩＤ９３、フローを識別するＦｌｏｗ Ｆｉｌｔｅｒ９４、フローの使用帯域を示すＢａｎｄｗｉｄｔｈ９５、及び、サービス情報に関連付けられたフロー（第３図Ｃに示すＦｌｏｗ Ｔａｂｌｅ）へのポインタＰｏｉｎｔｅｒ ｔｏ Ｆｌｏｗ Ｔａｂｌｅ９６から構成される。
Ｆｌｏｗ Ｆｉｌｔｅｒ９４は、Ｓｒｃ ＩＰ９４ａ、Ｄｓｔ ＩＰ９４ｂ、ｐｒｏｔｏ９４ｃ、Ｓｒｃ Ｐｏｒｔ９４ｄ、及び、Ｄｓｔ Ｐｏｒｔ９４ｅから構成される。 第３図Ｃは、本発明の第１の実施の形態のＱｏＳ Ｐｏｌｉｃｙ Ｓｅｒｖｅｒ５が保持するＦｌｏｗ Ｔａｂｌｅの説明図である。
Ｆｌｏｗ Ｔａｂｌｅ（第３図Ｃ）は、ＡＧＷ７に認可したフローを管理するためのテーブルである。Ｆｌｏｗ Ｔａｂｌｅ（第３図Ｃ）は、回線を識別するＬｉｎｅ−ＩＤ１１１、端末を識別するＴｅｒｍｉｎａｌ−ＩＤ１１２、フローを識別するＦｌｏｗ Ｆｉｌｔｅｒ１１３、要求帯域を示すＢａｎｄｗｉｄｔｈ１１４、及び、フローに関連付けられたサービス情報（第３図Ｂに示すＳｅｒｖｉｃｅ Ｉｎｆｏｒｍａｔｉｏｎ Ｔａｂｌｅ）へのポインタＰｏｉｎｔｅｒ ｔｏ Ｓｅｒｖｉｃｅ Ｉｎｆｏ． Ｔａｂｌｅ１１５から構成される。
Ｆｌｏｗ Ｆｉｌｔｅｒ１１３は、Ｓｒｃ ＩＰ１１３ａ、Ｄｓｔ ＩＰ１１３ｂ、ｐｒｏｔｏ１１３ｃ、Ｓｒｃ Ｐｏｒｔ１１３ｄ、及び、Ｄｓｔ Ｐｏｒｔ１１３ｅから構成される。
第３図Ｄは、本発明の第１の実施の形態のＱｏＳ Ｐｏｌｉｃｙ Ｓｅｒｖｅｒ５が保持するＬｉｎｅ Ｔａｂｌｅの説明図である。
Ｌｉｎｅ Ｔａｂｌｅ（第３図Ｄ）は、各回線の帯域を管理するためのテーブルである。Ｌｉｎｅ Ｔａｂｌｅ（第３図Ｄ）は、回線を識別するＬｉｎｅ−ＩＤ１３１、ＯＮＵを識別するＯＮＵ−ＩＤ１３２、ＯＬＴを識別するＯＬＴ−ＩＤ１３３、回線の最低保証帯域Ｍｉｎ Ｂａｎｄｗｉｄｔｈ１３４、最大保証帯域Ｍａｘ Ｂａｎｄｗｉｄｔｈ１３５、現在帯域Ｃｕｒｒｅｎｔ Ｂａｎｄｗｉｄｔｈ１３６、及び、回線を使用するフロー（第３図Ｃに示すＦｌｏｗ Ｔａｂｌｅ）へのポインタＰｏｉｎｔｅｒ ｔｏ Ｆｌｏｗ Ｔａｂｌｅ１３７から構成される。回線を使用するフローが複数存在する場合、Ｐｏｉｎｔｅｒ ｔｏ Ｆｌｏｗ Ｔａｂｌｅ１３７には複数のポインタが設定される。
第４図Ａは、本発明の第１の実施の形態のＨＧＷ１１の装置構成を示すブロック図である。
ＨＧＷ１１は、ＦＲＯＭ（Ｆｌｕｓｈ ＲＯＭ）５１、ＣＰＵ５２、Ｍｅｍｏｒｙ５３、ＩＦ（５４ａ、５４ｂ及び５４ｃ）及びバス５５を備える。ＨＧＷ１１の処理手順は、Ｍｅｍｏｒｙ ５３に格納されており、ＣＰＵ５２が順次それを読み出して実行する。
ＨＧＷ１１は、第４図Ｂに示すＳＩＰ Ｓｅｓｓｉｏｎ Ｔａｂｌｅ、第４図Ｃに示すＦｌｏｗ Ｔａｂｌｅ、第４図Ｄに示すＲＳＶＰ Ｓｅｓｓｉｏｎ Ｔａｂｌｅを保持する。これらのテーブルは、ＦＲＯＭ５１又はＭｅｍｏｒｙ５３に格納される。
第４図Ｂは、本発明の第１の実施の形態のＨＧＷ１１が保持するＳＩＰ Ｓｅｓｓｉｏｎ Ｔａｂｌｅの説明図である。
ＳＩＰ Ｓｅｓｓｉｏｎ Ｔａｂｌｅ（第４図Ｂ）は、ＳＩＰ Ｓｅｓｓｉｏｎを管理するためのテーブルである。ＳＩＰ Ｓｅｓｓｉｏｎ Ｔａｂｌｅ（第４図Ｂ）は、ＳＩＰ Ｓｅｓｓｉｏｎを識別するＳＩＰ Ｄｉａｌｏｇ ＩＤ１５１、発信端末を識別するＦｒｏｍ ＵＲＩ１５２、着信端末を識別するＴｏ ＵＲＩ１５３、セッション状態を示すＳｔａｔｅ１５４、ＳＤＰ Ｏｆｆｅｒ１５５、ＳＤＰ Ａｎｓｗｅｒ１５６、及び、ＳＩＰ Ｓｅｓｓｉｏｎに関連するフロー（第４図Ｃに示すＦｌｏｗ Ｔａｂｌｅ）へのポインタＰｏｉｎｔｅｒ ｔｏ Ｆｌｏｗ Ｔａｂｌｅ１５７から構成される。ＳＩＰ Ｄｉａｌｏｇ１５１は、Ｃａｌｌ−ＩＤ１５１ａ、Ｆｒｏｍ ｔａｇ１５１ｂ、及び、Ｔｏ ｔａｇ１５１ｃから構成される。
第４図Ｃは、本発明の第１の実施の形態のＨＧＷ１１が保持するＦｌｏｗ Ｔａｂｌｅの説明図である。
Ｆｌｏｗ Ｔａｂｌｅ（第４図Ｃ）は、ＳＩＰ Ｓｅｓｓｉｏｎに関連するフローを管理するためのテーブルである。Ｆｌｏｗ Ｔａｂｌｅ（第４図Ｃ）は、端末を識別するＴｅｒｍｉｎａｌ−ＩＤ１７１、フローを識別するＦｌｏｗ Ｆｉｌｔｅｒ１７２、フローの帯域を示すＢａｎｄｗｉｄｔｈ１７３、フローの状態を示すＳｔａｔｅ１７４、及び、フローに関連するＲＳＶＰ Ｓｅｓｓｉｏｎ（第４図Ｄに示すＲＳＶＰ Ｓｅｓｓｉｏｎ Ｔａｂｌｅ）へのポインタＰｏｉｎｔｅｒ ｔｏ ＲＳＶＰ Ｓｅｓｓｉｏｎ Ｔａｂｌｅ１７５から構成される。
Ｆｌｏｗ Ｆｉｌｔｅｒ１７２は、Ｓｒｃ ＩＰ１７２ａ、Ｄｓｔ ＩＰ１７２ｂ、ｐｒｏｔｏ１７２ｃ、Ｓｒｃ Ｐｏｒｔ１７２ｄ、及び、Ｄｓｔ Ｐｏｒｔ１７２ｅから構成される。また、Ｐｏｉｎｔｅｒ ｔｏ ＲＳＶＰ Ｓｅｓｓｉｏｎ Ｔａｂｌｅ１７５は、２種類のフィールド（すなわち、Ｔｏ ＡＧＷ１７５ａ及びＦｒｏｍ Ｔｅｒｍｉｎａｌ１７５ｂ）から構成される。これらは、それぞれ「ＨＧＷ１１がＡＧＷ７に対して送信したＱｏＳ設定要求」及び「端末から受信したＱｏＳ設定要求」をフローに対応付けるために使用される。
第４図Ｄは、本発明の第１の実施の形態のＨＧＷ１１が保持するＲＳＶＰ Ｓｅｓｓｉｏｎ Ｔａｂｌｅの説明図である。
ＲＳＶＰ Ｓｅｓｓｉｏｎ Ｔａｂｌｅ（第４図Ｄ）は、ＲＳＶＰ Ｓｅｓｓｉｏｎを管理するためのテーブルである。ＲＳＶＰ Ｓｅｓｓｉｏｎ Ｔａｂｌｅ（第４図Ｄ）は、ＲＳＶＰ Ｓｅｓｓｉｏｎを識別するＲＳＶＰ Ｓｅｓｓｉｏｎ ＩＤ１９１、予約スタイルを示すＳｔｙｌｅ１９２、フローの識別情報を示すＦｉｌｔｅｒＳｐｅｃ１９３、フロー特性を示すＦｌｏｗＳｐｅｃ１９４、ＱｏＳ設定の可否判断に使用するＰｏｌｉｃｙ Ｄａｔａ１９５、ＲＳＶＰ Ｓｅｓｓｉｏｎ状態を示すＳｔａｔｅ１９６、及び、ＲＳＶＰ Ｓｅｓｓｉｏｎに関連するフロー（第４図Ｃに示すＦｌｏｗ Ｔａｂｌｅ）へのポインタＰｏｉｎｔｅｒ ｔｏ Ｆｌｏｗ Ｔａｂｌｅ１９７から構成される。
ＲＳＶＰ Ｓｅｓｓｉｏｎ ＩＤ１９１は、Ｄｓｔ ＩＰ１９１ａ、Ｄｓｔ Ｐｏｒｔ１９１ｂ、及び、Ｐｒｏｔｏ１９１ｃから構成される。ＦｉｌｔｅｒＳｐｅｃ１９３は、Ｓｒｃ ＩＰ１９３ａ及びＳｒｃ Ｐｏｒｔ１９３ｂから構成される。ＦｉｌｔｅｒＳｐｅｃ１９４は、Ｂａｎｄｗｉｄｔｈ１９４ａから構成される。Ｐｏｌｉｃｙ Ｄａｔａ１９５には、要求者ＩＤなどが設定される。
第５図は、本発明の第１の実施の形態におけるセッション確立のための処理を示すシーケンス図である。
第５図は、例として、ホーム網１７に接続された端末（ＵＡ１２）が、移動アクセス網に接続された端末（ＵＡ８）との間にセッションを確立するためのシーケンスを示す。端末（ＵＡ１２及びＵＡ８）は、ＩＥＴＦ ＲＦＣ３３１２に規定されるｐｒｅｃｏｎｄｉｔｉｏｎオプションに対応しており、着信側ユーザを呼び出す前にアクセス網のＱｏＳリソース予約を完了する。以下、このシーケンスの詳細を説明する。
最初に、端末（ＵＡ１２）は、ＳＤＰ Ｏｆｆｅｒを含むＳＩＰ ＩＮＶＩＴＥ２１１をＨＧＷ１１に送信する。
ＳＩＰ ＩＮＶＩＴＥ２１１には、これから確立しようとするセッションにおいて端末（ＵＡ１２）が要求する帯域を示す情報が含まれる。
ＨＧＷ１１は、Ｓｅｓｓｉｏｎ情報をＳＩＰ Ｓｅｓｓｉｏｎ Ｔａｂｌｅ（第４図Ｂ）に記録する。さらに、ＨＧＷ１１は、ＩＮＶＩＴＥ２１１にＬｉｎｅ−ＩＤを追加し、ＳＩＰ Ｓｅｒｖｅｒ３に転送する（Ｆ１）。Ｆ１において実行される処理については、後で詳細に説明する（第８図参照）。
第６図は、本発明の第１の実施の形態のＨＧＷ１１によってＬｉｎｅ−ＩＤを追加されたＳＩＰ ＩＮＶＩＴＥ２１１の例を示す説明図である。
ＳＩＰ ＩＮＶＩＴＥは、ＩＰ Ｈｅａｄｅｒ、ＵＤＰ Ｈｅａｄｅｒ及びＳＩＰ Ｍｅｓｓａｇｅから構成される。ＳＩＰ Ｍｅｓｓａｇｅは、Ｓｔａｒｔ−Ｌｉｎｅ、ＳＩＰ Ｈｅａｄｅｒ及びＭｅｓｓａｇｅ−Ｂｏｄｙ（ＳＤＰ）から構成される。第６図の例では、Ｌｉｎｅ−ＩＤ「１２３４５６」が拡張ＳＩＰ Ｈｅａｄｅｒ（Ｘ−Ｌｉｎｅ−ＩＤ Ｈｅａｄｅｒ）に設定されている。
なお、Ｌｉｎｅ−ＩＤ「１２３４５６」は、ＳＤＰ属性行に設定されてもよい（図示省略）。
再び第５図を参照して、シーケンスの説明を続ける。
ＳＩＰ Ｓｅｒｖｅｒ３は、ＨＧＷ１１からＩＮＶＩＴＥ２１１を受信すると、Ｘ−Ｌｉｎｅ−ＩＤ ＨｅａｄｅｒからＬｉｎｅ−ＩＤを削除し、そのＬｉｎｅ−ＩＤを、Ｓｅｓｓｉｏｎ情報と共にＳＩＰ Ｓｅｓｓｉｏｎ Ｔａｂｌｅ（第２図Ｂ）に記録する。本シーケンスでは、Ｌｉｎｅ−ＩＤは７２ｂに設定される。さらに、ＳＩＰ Ｓｅｒｖｅｒ３は、ＩＮＶＩＴＥ２１１をＳＩＰ Ｓｅｒｖｅｒ１に転送する。ＩＮＶＩＴＥ２１１は、ＳＩＰ Ｓｅｒｖｅｒ１及びＳＩＰ Ｓｅｒｖｅｒ２を経由して、端末（ＵＡ８）に到達する。なお、第５図では、ＳＩＰ Ｓｅｒｖｅｒ１及び２を省略している。
端末（ＵＡ８）は、ＳＤＰ Ａｎｓｗｅｒを含む暫定応答（１８３応答）２１２を返信する。１８３応答２１２は、ＩＮＶＩＴＥ２１１と逆の経路を辿り、端末（ＵＡ１２）に到達する。端末（ＵＡ１２）は、１８３応答２１２に対するＰＲＡＣＫ（Ｐｒｏｖｉｓｉｏｎａｌ Ｒｅｓｐｏｎｓｅ Ａｃｋｎｏｗｌｅｄｇｍｅｎｔ）２１３を送信する。端末（ＵＡ８）は、ＰＲＡＣＫ２１３に対する２００応答２１４を返信する。
ＳＩＰ Ｓｅｒｖｅｒ３は、ＳＤＰ Ａｎｓｗｅｒを含む１８３応答２１２を転送したことを契機に、ＱｏＳ Ｐｏｌｉｃｙ Ｓｅｒｖｅｒ５に対してサービス情報２１５を通知する（Ｆ２）。この通知は、ＰＲＡＣＫ２１３又は２００応答２１４より早く送信されてもよい。Ｆ２において実行される処理については、後で詳細に説明する（第９図参照）。
サービス情報２１５には、ＳＩＰ Ｓｅｓｓｉｏｎを識別するＳｅｓｓｉｏｎ−ＩＤ、回線を識別するＬｉｎｅ−ＩＤ、端末を識別するＴｅｒｍｉｎａｌ−ＩＤ、Ｆｌｏｗを識別するフィルタ情報、及び、帯域が含まれる。これらの情報は、ＩＮＶＩＴＥ２１１及び１８３応答２１２に含まれる情報に基づく。サービス情報２１５に含まれる帯域は、Ｔｅｒｍｉｎａｌ−ＩＤによって識別される端末がセッションにおいて要求する帯域である。ＱｏＳ Ｐｏｌｉｃｙ Ｓｅｒｖｅｒ３は、通知された情報をＳｅｒｖｉｃｅ Ｉｎｆｏｒｍａｔｉｏｎ Ｔａｂｌｅ（第３図Ｂ）に記録する。
ＨＧＷ１１は、ＳＤＰ Ａｎｓｗｅｒを含む１８３応答２１２を転送したことを契機に、Ｓｅｓｓｉｏｎに関連するフローをＦｌｏｗ Ｔａｂｌｅ（第４図Ｃ）に登録する。さらに、ＨＧＷ１１は、ＡＧＷ７に対してＲＳＶＰ Ｒｅｓｖ２１６を送信し、固定アクセス網１６のＱｏＳ設定を要求する（Ｆ３）。この要求は、ＰＲＡＣＫ２１３又は２００応答２１４より早く送信されてもよい。Ｆ３において実行される処理については、後で詳細に説明する（第１０図参照）。ＲＳＶＰ Ｒｅｓｖ２１６には、Ｌｉｎｅ−ＩＤ、Ｔｅｒｍｉｎａｌ−ＩＤ、Ｆｌｏｗのフィルタ情報、及び、要求帯域が含まれる。
第７図Ａ及び第７図Ｂは、本発明の第１の実施の形態において送信されるＲＳＶＰ Ｒｅｓｖ２１６のパケットフォーマットの説明図である。
第７図Ａに示す例では、ＳＥＳＳＩＯＮオブジェクト及びｆｌｏｗｄｅｓｃｒｉｐｔｏｒｌｉｓｔオブジェクトに、それぞれ、フィルタ情報及び帯域が設定される。さらに、ＰＯＬＩＣＹ＿ＤＡＴＡオブジェクトにＬｉｎｅ−ＩＤ及びＴｅｒｍｉｎａｌ−ＩＤが設定される。
第７図Ｂに示す例では、ベンダ拡張（ｖｅｎｄｏｒ＿ｓｐｅｃｉｆｉｃ）領域にＬｉｎｅ−ＩＤ及びＴｅｒｍｉｎａｌ−ＩＤが設定される。
本実施の形態では、第７図Ａ及び第７図Ｂのどちらのフォーマットが適用されてもよい。
再び第５図を参照して、シーケンスの説明を続ける。
端末（ＵＡ１２）は、ＰＲＡＣＫに対する２００応答２１４を受信したことを契機に、ＲＳＶＰ Ｒｅｓｖ２１７を送信し、ホーム網１７のＱｏＳ設定を要求する。ＲＳＶＰ Ｒｅｓｖ２１７には、Ｔｅｒｍｉｎａｌ−ＩＤ、Ｆｌｏｗのフィルタ情報、及び、要求帯域が含まれる。ＨＧＷ１１は、Ｔｅｒｍｉｎａｌ−ＩＤ及びフィルタ情報を比較キーとして使用し、ＲＳＶＰ Ｒｅｓｖ２１６とＲＳＶＰ Ｒｅｓｖ２１７とを対応付けて管理する（Ｆ４）。Ｆ４において実行される処理については、後で詳細に説明する（第１１図参照）。
ＡＧＷ７は、ＨＧＷ１１からＲＳＶＰ Ｒｅｓｖ２１６を受信したことを契機に、ＱｏＳ認可要求２１８をＱｏＳ Ｐｏｌｉｃｙ Ｓｅｒｖｅｒ５に送信する。ＱｏＳ認可要求２１８は、ＲＳＶＰ Ｒｅｓｖ２１６に含まれていたＬｉｎｅ−ＩＤ、Ｔｅｒｍｉｎａｌ−ＩＤ、フィルタ情報、及び、帯域を指定する。言い換えると、ＨＧＷ１１から送信されたＱｏＳ制御信号（ＲＳＶＰ Ｒｅｓｖ２１６）に含まれるＬｉｎｅ−ＩＤ及び帯域等の情報は、最終的に、ＱｏＳ Ｐｏｌｉｃｙ Ｓｅｒｖｅｒ５に到達する。
ＱｏＳ Ｐｏｌｉｃｙ Ｓｅｒｖｅｒ５は、ＳＩＰ Ｓｅｒｖｅｒ３から通知されたサービス情報２１５と回線帯域を考慮してＱｏＳ設定を認可する。さらに、ＱｏＳ Ｐｏｌｉｃｙ Ｓｅｒｖｅｒ５は、必要に応じてＰＯＮの回線保証帯域を制御し、ＡＧＷ７に成功応答２１９を返信する（Ｆ５）。Ｆ５において実行される処理については、後で詳細に説明する（第１２図参照）。
ＡＧＷ７は、応答２１９を受信すると、ＲＳＶＰ Ｒｅｓｖ２１６で指定されたＱｏＳパラメータをローカルのテーブル（図示省略）に設定し、ＲＳＶＰ ＲｅｓｖＣｏｎｆ２２０を送信する。
ＨＧＷ１１は、ＲＳＶＰ ＲｅｓｖＣｏｎｆ２２０を受信すると、ＲＳＶＰ Ｒｅｓｖ２１７に対するＲＳＶＰ ＲｅｓｖＣｏｎｆ２２１を端末（ＵＡ１２）に送信する（Ｆ６）。Ｆ６において実行される処理については、後で詳細に説明する（第１３図参照）。
以上の手順によって、固定アクセス網１６及びホーム網１７のＱｏＳ設定が完了する。
その後、端末（ＵＡ１２）は、ＳＤＰ Ｏｆｆｅｒを含むＳＩＰ ＵＰＤＡＴＥ２２２を送信し、ＱｏＳ設定の完了を端末（ＵＡ８）に通知する。端末（ＵＡ８）は、ＳＤＰ Ａｎｓｗｅｒ を含む２００応答２２３を返信する。さらに、端末（ＵＡ８）は、ユーザの呼び出しを開始し、１８０応答２２４を送信する。端末（ＵＡ１２）は、１８０応答２２４に対するＰＲＡＣＫ２２５を送信する。端末（ＵＡ８）は、ＰＲＡＣＫ２２５に対する２００応答２２６を送信する。
着信ユーザがオフフックしたことを契機に、端末（ＵＡ８）は、ＩＮＶＩＴＥ２１１に対する２００応答２２７を送信する。端末（ＵＡ１２）は、ＡＣＫ２２８を返信する。以上の手順によって、セッション確立が完了し、Ｍｅｄｉａ Ｆｌｏｗ２２９の送受信が開始する。
以下、第５図のシーケンスに関連して、本発明に特徴的な処理（具体的には、第５図のＦ１からＦ６において実行される処理）を説明する。
第８図は、本発明の第１の実施の形態のＨＧＷ１１が実行するＬｉｎｅ−ＩＤ追加判定処理（第５図のＦ１）を示すフローチャートである。
ＨＧＷ１１は、処理効率化のため、ＳＩＰメッセージ種別及びメッセージボディの内容に応じて、選択的にＬｉｎｅ−ＩＤを追加する。
ＨＧＷ１１は、まず、ＳＩＰ ＭｅｓｓａｇｅにＳＤＰ Ｏｆｆｅｒ又はＳＤＰ Ａｎｓｗｅｒが含まれるか否かを判定する（２５１）。
ＳＩＰ ＭｅｓｓａｇｅにＳＤＰ Ｏｆｆｅｒ又はＳＤＰ Ａｎｓｗｅｒのいずれも含まれない場合、ＨＧＷ１１は、ＳＩＰ ＭｅｓｓａｇｅにＬｉｎｅ−ＩＤを追加せずに処理を終了する。一方、ＳＩＰ ＭｅｓｓａｇｅにＳＤＰ Ｏｆｆｅｒ又はＳＤＰ Ａｎｓｗｅｒのいずれかが含まれる場合、ＨＧＷ１１は、ＳＩＰ ＭｅｓｓａｇｅにＬｉｎｅ−ＩＤを追加し（２５２）、処理を終了する。
第８図に示す処理を実行することによって、所定の種類のＳＩＰ ＭｅｓｓａｇｅのみにＬｉｎｅ−ＩＤが追加され、Ｌｉｎｅ−ＩＤを追加する必要がないＳＩＰ Ｍｅｓｓａｇｅに対しては、Ｌｉｎｅ−ＩＤを追加する処理が省略される。このため、処理が効率化される。
第９図は、本発明の第１の実施の形態のＳＩＰ Ｓｅｒｖｅｒ３が実行するサービス情報通知処理（第５図のＦ２）を示すフローチャートである。
ＳＩＰ Ｓｅｒｖｅｒ３は、ＳＤＰ Ａｎｓｗｅｒの転送を契機に、以下の処理を実行する。
まず、ＳＩＰ Ｓｅｒｖｅｒ３は、転送したＳＤＰ Ｏｆｆｅｒ（７５）及びＡｎｓｗｅｒ（７６）が既存のＭｅｄｉａ Ｆｌｏｗを更新するか否かを判定する（２７１）。例えば、新規にセッションを確立する場合、転送したＳＤＰ Ｏｆｆｅｒ等が既存のＭｅｄｉａ Ｆｌｏｗを更新すると判定される。
ステップ２７１において、転送したＳＤＰ Ｏｆｆｅｒ等が既存のＭｅｄｉａ Ｆｌｏｗを更新しないと判定された場合、ＳＩＰ Ｓｅｒｖｅｒ３は、処理を終了する。
一方、ステップ２７１において、転送したＳＤＰ Ｏｆｆｅｒ等が既存のＭｅｄｉａ Ｆｌｏｗを更新すると判定された場合、ＳＩＰ Ｓｅｒｖｅｒ３は、ＳＩＰ Ｓｅｓｓｉｏｎ Ｔａｂｌｅ（第２図Ｂ）から、Ｓｅｓｓｉｏｎに関連する端末のＩＤ（Ｔｅｒｍｉｎａｌ−ＩＤ）を抽出する（２７２）。本実施の形態では、Ｔｅｒｍｉｎａｌ−ＩＤとして、第２図Ｂに示すＦｒｏｍ ＵＲＩ（７２ａ）及びＴｏ ＵＲＩ（７３ａ）が抽出される。あるいは、Ｆｒｏｍ ＵＲＩ（７２ａ）及びＴｏ ＵＲＩ（７３ａ）に関連付けられた別のＩＤが使用されてもよい。
次に、ＳＩＰ Ｓｅｒｖｅｒ３は、ステップ２７２で抽出された各Ｔｅｒｍｉｎａｌ−ＩＤ（具体的には、発信側と着信側のＴｅｒｍｉｎａｌ−ＩＤ）に関して、ループ（２７３−２７９）の処理を行う。
最初に、ＳＩＰ Ｓｅｒｖｅｒ３は、Ｔｅｒｍｉｎａｌ−ＩＤが、固定アクセス網１６に収容されている端末のものであるか否かを判定する（２７４）。本実施の形態では、例えば、ＳＩＰ Ｓｅｓｓｉｏｎ Ｔａｂｌｅ（第２図Ｂ）のＬｉｎｅ−ＩＤ（７２ｂ又は７３ｂ）が存在する場合、判定の対象であるＴｅｒｍｉｎａｌ−ＩＤが、固定アクセス網１６に収容されている端末のものであると判定される。ただし、別の方法によってステップ２７４の判定が実行されてもよい。
ステップ２７４において、Ｌｉｎｅ−ＩＤが存在しないと判定された場合、ＳＩＰ Ｓｅｒｖｅｒ３は、２７５−２７８の処理をスキップする。
一方、ステップ２７４において、Ｌｉｎｅ−ＩＤが存在すると判定された場合、ＳＩＰ Ｓｅｒｖｅｒ３は、Ｌｉｎｅ−ＩＤ（７２ｂ又は７３ｂ）の値を取得する（２７５）。
次に、ＳＩＰ Ｓｅｒｖｅｒ３は、ＳＩＰ Ｓｅｓｓｉｏｎを一意に識別するためのＳｅｓｓｉｏｎ−ＩＤを生成する（２７６）。本実施の形態では、Ｓｅｓｓｉｏｎ−ＩＤとしてＳＩＰ Ｓｅｓｓｉｏｎ Ｔａｂｌｅ（第２図Ｂ）のＳＩＰ Ｄｉａｌｏｇ ＩＤ７１が使用される。
次に、ＳＩＰ Ｓｅｒｖｅｒ３は、第２図ＢのＳＤＰ Ｏｆｆｅｒ（７５）及びＳＤＰ Ａｎｓｗｅｒ（７６）から、Ｓｅｓｓｉｏｎに関連するＦｌｏｗ Ｆｉｌｔｅｒ（具体的には、Ｓｒｃ ＩＰ、Ｄｓｔ ＩＰ、Ｐｒｏｔｏｃｏｌ、Ｓｒｃ Ｐｏｒｔ及びＤｓｔ Ｐｏｒｔ）及び帯域を抽出する（２７７）。
最後に、ＳＩＰ Ｓｅｒｖｅｒ３は、ＱｏＳ Ｐｏｌｉｃｙ Ｓｅｒｖｅｒ５に対して、サービス情報を通知する（２７８）。サービス情報には、Ｔｅｒｍｉｎａｌ−ＩＤ、ステップ２７５において取得されたＬｉｎｅ−ＩＤ、ステップ２７６において生成されたＳｅｓｓｉｏｎ−ＩＤ、及び、ステップ２７７において抽出されたＦｌｏｗ Ｆｉｌｔｅｒ及び帯域が含まれる。
第１０図は、本発明の第１の実施の形態のＨＧＷ１１が実行するＦｌｏｗ登録／ＲＳＶＰ Ｒｅｓｖ送信処理（第５図のＦ３）を示すフローチャートである。
ＨＧＷ１１は、ＳＤＰ Ａｎｓｗｅｒの転送を契機に以下の処理を実行する。
まず、ＨＧＷ１１は、転送したＳＤＰ Ｏｆｆｅｒ（１５５）及びＡｎｓｗｅｒ（１５６）が既存のＭｅｄｉａ Ｆｌｏｗを更新するか否かを判定する（２９１）。
ステップ２９１において、転送したＳＤＰ Ｏｆｆｅｒ等が既存のＭｅｄｉａ Ｆｌｏｗを更新しないと判定された場合、ＨＧＷ１１は、処理を終了する。
一方、ステップ２９１において、転送したＳＤＰ Ｏｆｆｅｒ等が既存のＭｅｄｉａ Ｆｌｏｗを更新すると判定された場合、ＨＧＷ１１は、ＳＩＰ Ｓｅｓｓｉｏｎ Ｔａｂｌｅ（第４図Ｂ）から、Ｓｅｓｓｉｏｎに関連する端末のＩＤ（Ｔｅｒｍｉｎａｌ−ＩＤ）を抽出する（２９２）。本実施の形態では、Ｔｅｒｍｉｎａｌ−ＩＤとして、第４図ＢのＦｒｏｍ ＵＲＩ（１５２）及びＴｏ ＵＲＩ（１５３）が抽出される。あるいは、Ｆｒｏｍ ＵＲＩ（１５２）及びＴｏ ＵＲＩ（１５３）に関連付けられた別のＩＤが使用さてもよい。
次に、ＨＧＷ１１は、ステップ２９２で抽出した各Ｔｅｒｍｉｎａｌ−ＩＤに関して、ループ１（２９３−３００）の処理を行う。まず、ＨＧＷ１１は、Ｔｅｒｍｉｎａｌ−ＩＤが示す端末が、ホーム網１７に接続されているか否かを判定する（２９４）。この判定は、ＳＩＰ Ｍｅｓｓａｇｅの受信ポート、及び、端末ＩＰ Ａｄｄｒｅｓｓ等に基づいて実行される。
ステップ２９４において、端末がホーム網１７に接続されていないと判定された場合、ＨＧＷ１１は、ステップ２９５−２９９の処理をスキップする。
一方、端末がホーム網１７に接続されていると判定された場合、ＨＧＷ１１は、ＳＤＰ Ｏｆｆｅｒ（１５５）及びＡｎｓｗｅｒ（１５６）によって確立されるフローをＦｌｏｗ Ｔａｂｌｅ（第４図Ｃ）に設定する（２９５）。
次に、ＨＧＷ１１は、ステップ２９５において設定された各Ｆｌｏｗに関して、ループ２（２９６−２９９）の処理を行う。最初に、ＨＧＷ１１は、Ｆｌｏｗが固定アクセス網１６を経由するか否かを判定する（２９７）。この判定は、Ｆｌｏｗの送信元／宛先ＩＰアドレス（第４図Ｃの１７２ａ、１７２ｂ）等に基づいて実行される。
ステップ２９７において、Ｆｌｏｗが固定アクセス網１６を経由しないと判定された場合、このＦｌｏｗは、ホーム網１７の中で閉じている。この場合、ＡＧＷ７に対してＱｏＳ設定要求を送信する必要がないため、ＨＧＷ１１は、ステップ２９８の処理をスキップする。
一方、ステップ２９７において、Ｆｌｏｗが固定アクセス網１６を経由すると判定された場合、ＨＧＷ１１は、ＡＧＷ７にＱｏＳ設定要求（ＲＳＶＰ Ｒｅｓｖ）を送信するとともに、送信した要求に対応するエントリをＲＳＶＰ Ｓｅｓｓｉｏｎ Ｔａｂｌｅ（第４図Ｄ）に設定する（２９８）。
第１１図は、本発明の第１の実施の形態のＨＧＷ１１が実行するＲＳＶＰ Ｒｅｓｖ受信処理（第５図のＦ４）を示すフローチャートである。
第１１図に示す処理は、ＨＧＷ１１がＡＧＷ７に送信したＲＳＶＰ Ｒｅｓｖ（２１６）と、ＨＧＷ１１がＵＡ１２から受信したＲＳＶＰ Ｒｅｓｖ（２１７）とを対応付けるために実行される。
ＨＧＷ１１は、まず、ＵＡ１２から受信したＲＳＶＰ Ｒｅｓｖに対応するエントリをＲＳＶＰ Ｓｅｓｓｉｏｎ Ｔａｂｌｅ（第４図Ｄ）に設定する（３１１）。
次に、ＨＧＷ１１は、ステップ３１１において設定されたエントリに対応するＦｌｏｗをＦｌｏｗ Ｔａｂｌｅ（第４図Ｃ）から検索する（３１２）。この検索は、Ｆｌｏｗ Ｔａｂｌｅ（第４図Ｃ）の各エントリのフィルタ情報及び端末ＩＤと、ステップ３１１において設定されたエントリのフィルタ情報及び端末ＩＤとが一致するか否かを判定することによって実行される。Ｆｌｏｗ Ｔａｂｌｅ（第４図Ｃ）において、フィルタ情報は、Ｆｌｏｗ Ｆｉｌｔｅｒ１７２に設定されている。端末ＩＤは、Ｔｅｒｍｉｎａｌ−ＩＤ１７１に設定されている。ＲＳＶＰ Ｓｅｓｓｉｏｎ Ｔａｂｌｅ（第４図Ｄ）において、フィルタ情報はＲＳＶＰ Ｓｅｓｓｉｏｎ ＩＤ１９１及びＦｉｌｔｅｒＳｐｅｃ１９３に設定されている。端末ＩＤは、Ｐｏｌｉｃｙ Ｄａｔａ１９５に設定されている。
ステップ３１２において、検索の条件に合うＦｌｏｗがＦｌｏｗ Ｔａｂｌｅ（第４図Ｃ）に存在しない場合、ＲＳＶＰ Ｒｅｓｖを送信したＵＡ１２は、第５図のステップ２１１から２１２に示す手順を実行していない。このようなＵＡ１２は、悪意のある端末である可能性がある。この場合、ＨＧＷ１１は、ステップ３１１において設定されたエントリを削除し、エラー応答（ＲＳＶＰ ＲｅｓｖＥｒｒ）を送信して処理を終了する（３１３）。
一方、ステップ３１２において、検索の条件に合うＦｌｏｗが存在する場合、ＨＧＷ１１は、第４図Ｃの１７５ｂ及び第４図Ｄの１９７を設定することによって、ステップ３１１において設定されたＲＳＶＰ Ｓｅｓｓｉｏｎと、ステップ３１２において検索されたＦｌｏｗに相互リンクを作成する（３１４）。ステップ３１４によって、同一のフロー（又は同一のセッション）のために送信されたＲＳＶＰ Ｒｅｓｖ２１６とＲＳＶＰ Ｒｅｓｖ２１７とが間接的に対応付けられる。
次に、ＨＧＷ１１は、ステップ３１２において検索されたＦｌｏｗに関連してＡＧＷ７に送信した設定要求（第４図Ｃの１７５ａ）に対する成功応答（すなわち、第５図のＲＳＶＰ ＲｅｓｖＣｏｎｆ２２０）を受信済みであるか否かを判定する（３１５）。
ステップ３１５において、成功応答を受信していないと判定された場合、固定アクセス網１６におけるＱｏＳの設定（帯域予約）が終了していない。この場合、ＨＧＷ１１は、そのまま処理を終了する。
一方、成功応答を受信済みであると判定された場合、固定アクセス網１６におけるＱｏＳの設定（帯域予約）が終了している。この場合、ＨＧＷ１１は、ＵＡ１２から受信したＲＳＶＰ Ｒｅｓｖ２１７に対する成功応答（ＲＳＶＰ ＲｅｓｖＣｏｎｆ２２１）をＵＡ１２に返信し、さらに、ステップ３１１において設定されたエントリの状態を「成功応答送信済み」に設定して、処理を終了する（３１６）。
なお、ＨＧＷ１１は、ステップ３１２から３１５までのいずれかの時点で、ＲＳＶＰ Ｒｅｓｖ２１７に応じて、ＵＡ１２とＨＧＷ１１の間の帯域予約を実行してもよい。
第５図のＲＳＶＰ Ｒｅｓｖ２１６は、固定アクセス網１６におけるＨＧＷ１１とＡＧＷ７の間の帯域を予約するための要求である。ＲＳＶＰ ＲｅｓｖＣｏｎｆ２２０は、ＲＳＶＰ Ｒｅｓｖ２１６に対する成功応答である。一方、ＲＳＶＰ Ｒｅｓｖ２１７は、ＵＡ１２とＨＧＷ１１の間の帯域を予約するための要求である。ＲＳＶＰ ＲｅｓｖＣｏｎｆ２２１は、ＲＳＶＰ Ｒｅｓｖ２１７に対する成功応答である。これらの二つの要求（２１６及び２１７）に応じた帯域予約の処理は、どちらが先に実行されてもよい。このため、本来、ＨＧＷ１１は、ステップ３１４の処理が終了した後であれば、ＲＳＶＰ ＲｅｓｖＣｏｎｆ２２０を受信していなくても、ＲＳＶＰ ＲｅｓｖＣｏｎｆ２２１をＵＡ１２に送信することができる。
しかし、ＵＡ１２は、ＲＳＶＰ ＲｅｓｖＣｏｎｆ２２１を受信すると、第５図のステップ２２２以降の処理を実行する。ステップ２２２以降の処理は、ＨＧＷ１１とＡＧＷ７の間の帯域予約が終了した後で（すなわち、Ｆ５の処理が終了した後で）実行される必要がある。このため、本実施の形態のＨＧＷ１１は、ＲＳＶＰ ＲｅｓｖＣｏｎｆ２２０を受信した後に限ってＲＳＶＰ ＲｅｓｖＣｏｎｆ２２１を送信する（３１５、３１６）。その結果、ＨＧＷ１１とＡＧＷ７の間の帯域予約が終了する前にＵＡ１２がステップ２２２以降の処理を実行することが防止される。
第１２図は、本発明の第１の実施の形態のＱｏＳ Ｐｏｌｉｃｙ Ｓｅｒｖｅｒ５が実行するＦｌｏｗ認可処理（第５図のＦ５）を示すフローチャートである。
ＱｏＳ Ｐｏｌｉｃｙ Ｓｅｒｖｅｒ５は、ＡＧＷ７からＱｏＳ認可要求を受信したとき、以下の処理を実行する（第５図のＦ５参照）。
まず、ＱｏＳ Ｐｏｌｉｃｙ Ｓｅｒｖｅｒ５は、受信したＱｏＳ認可要求に対応するエントリを、Ｆｌｏｗ Ｔａｂｌｅ（第３図Ｃ）に設定する（３３１）。
次に、ＱｏＳ Ｐｏｌｉｃｙ Ｓｅｒｖｅｒ５は、ステップ３３１において設定されたエントリに対応するサービス情報をＳｅｒｖｉｃｅ Ｉｎｆｏｒｍａｔｉｏｎ Ｔａｂｌｅ（第３図Ｂ）から検索する（３３２）。サービス情報の検索は、Ｓｅｒｖｉｃｅ Ｉｎｆｏｒｍａｔｉｏｎ Ｔａｂｌｅ（第３図Ｂ）の各エントリに設定されたＦｌｏｗのフィルタ情報、回線ＩＤ及び端末ＩＤと、ステップ３３１において設定されたエントリのフィルタ情報、回線ＩＤ及び端末ＩＤとが一致するか否かを判定することによって実行される。
Ｓｅｒｖｉｃｅ Ｉｎｆｏｒｍａｔｉｏｎ Ｔａｂｌｅ（第３図Ｂ）において、フィルタ情報はＦｌｏｗＦｉｌｔｅｒ９４に設定されている。回線ＩＤは、Ｌｉｎｅ−ＩＤ９２に設定されている。端末ＩＤは、Ｔｅｒｍｉｎａｌ−ＩＤ９３に設定されている。Ｆｌｏｗ Ｔａｂｌｅ（第３図Ｃ）において、フィルタ情報はＦｌｏｗＦｉｌｔｅｒ１１３に設定されている。回線ＩＤは、Ｌｉｎｅ−ＩＤ１１１に設定されている。端末ＩＤは、Ｔｅｒｍｉｎａｌ−ＩＤ１１２に設定されている。
ステップ３３２において、検索の条件に合うサービス情報が存在しない場合、ＱｏＳ Ｐｏｌｉｃｙ Ｓｅｒｖｅｒ５は、ステップ３３１において設定されたエントリを削除し、ＡＧＷ７にエラー応答を送信して（３３３）、処理を終了する。
一方、ステップ３３２において、検索の条件に合うサービス情報が存在する場合、ＱｏＳ Ｐｏｌｉｃｙ Ｓｅｒｖｅｒ５は、要求帯域（１１４）がステップ３３２において検索されたサービス情報（すなわち検索の条件に合うサービス情報）の帯域（９５）を越えるか否かを判定する（３３４）。
ステップ３３４において、要求帯域（１１４）がサービス情報の帯域（９５）を超える場合、ＱｏＳ Ｐｏｌｉｃｙ Ｓｅｒｖｅｒ５は、ステップ３３３のエラー処理を実行して、処理を終了する。
一方、ステップ３３４において、要求帯域（１１４）がサービス情報の帯域（９５）を超えない場合、ＱｏＳ Ｐｏｌｉｃｙ Ｓｅｒｖｅｒ５は、ＱｏＳ認可要求に含まれるＬｉｎｅ−ＩＤ（１１１）に基づいて、Ｌｉｎｅ Ｔａｂｌｅ（第３図Ｄ）から回線情報を検索する（３３５）。具体的には、受信したＱｏＳ認可要求に含まれるＬｉｎｅ−ＩＤ（１１１）と同一の値がＬｉｎｅ−ＩＤ（１３１）として登録されているエントリをＬｉｎｅ Ｔａｂｌｅ（第３図Ｄ）から検索する。
次に、ＱｏＳ Ｐｏｌｉｃｙ Ｓｅｒｖｅｒ５は、ステップ３３５において検索されたエントリの現在帯域（１３６）と要求帯域（１１４）の和が、最大保証帯域（１３５）を超えるか否かを判定する（３３６）。
ステップ３３６において、現在帯域（１３６）と要求帯域（１１４）の和が最大保証帯域（１３５）を超えると判定された場合、ＱｏＳ Ｐｏｌｉｃｙ Ｓｅｒｖｅｒ５は、ステップ３３３のエラー処理を実行して、処理を終了する。
一方、ステップ３３６において、現在帯域（１３６）と要求帯域（１１４）の和が最大保証帯域（１３５）を超えないと判定された場合、ＱｏＳ Ｐｏｌｉｃｙ Ｓｅｒｖｅｒ５は、ステップ３３５において検索されたエントリの現在帯域（１３６）と要求帯域（１１４）の和が、最低保証帯域（１３４）を超えるか否かを判定する（３３７）。
ステップ３３７において、現在帯域（１３６）と要求帯域（１１４）の和が最低保証帯域（１３４）を超えないと判定された場合、ＱｏＳ Ｐｏｌｉｃｙ Ｓｅｒｖｅｒ５は、ステップ３３８の処理をスキップする。
一方、ステップ３３７において、現在帯域（１３６）と要求帯域（１１４）の和が最低保証帯域（１３４）を超えると判定された場合、ＱｏＳ Ｐｏｌｉｃｙ Ｓｅｒｖｅｒ５は、ＰＯＮの保証帯域を、ステップ３３５において検索されたエントリの現在帯域（１３６）と要求帯域（１１４）の和まで増加させる（３３８）。
最後に、ＱｏＳ Ｐｏｌｉｃｙ Ｓｅｒｖｅｒ５は、ステップ３３５において検索されたエントリの現在帯域（１３６）に要求帯域（１１４）を加算し、ＡＧＷ７に成功応答を送信して処理を終了する（３３９）。
上記の第１２図の処理によって、同一のＬｉｎｅ−ＩＤと関連付けられたセッションにおいて要求される帯域に基づいて、ＱｏＳが制御される。同一のＬｉｎｅ−ＩＤと関連付けられたセッションとは、同一のＨＧＷ１１を経由するセッション（すなわち、固定アクセス網１６において同一の回線を使用するセッション）である。
すなわち、同一の回線を使用する複数のＦｌｏｗが存在する場合、それらの全てのＦｌｏｗにおいて要求される帯域の合計値が算出される（３３６、３３７）。そして、算出された合計値が、固定アクセス網１６における保証帯域として設定される（３３９）。ただし、算出された合計値が最大保証帯域を超える場合、固定アクセス網１６における保証帯域は変更されずに、エラーが応答される（３３３）。算出された合計値が最低保証帯域を超えない場合、最低保証帯域が、固定アクセス網１６における保証帯域として設定される。
第１３図は、本発明の第１の実施の形態のＨＧＷ１１が実行するＲＳＶＰ ＲｅｓｖＣｏｎｆ受信処理（第５図のＦ６）を示すフローチャートである。
まず、ＨＧＷ１１は、受信したＲｅｓｖＣｏｎｆ２２０に対応するエントリをＲＳＶＰ Ｓｅｓｓｉｏｎ Ｔａｂｌｅ（第４図Ｄ）から検索する（３５１）。
ステップ３５１において、検索の条件に合うエントリが存在しない場合、ＨＧＷ１１は、処理を終了する。
一方、ステップ３５１において、検索の条件に合うエントリが存在する場合、ＨＧＷ１１は、検索されたエントリの状態（１９６）を、「成功応答受信済み」に更新する（３５２）。
次に、ＨＧＷ１１は、ステップ３５１において検索されたエントリに関連付けられたＦｌｏｗ（１９７）が、端末（ＵＡ１２）からＲＳＶＰ Ｒｅｓｖ２１７を受信済みであるか否かを判定する（３５３）。具体的には、Ｆｌｏｗ Ｔａｂｌｅ（第４図Ｃ）のＦｒｏｍ Ｔｅｒｍｉｎａｌ１７５ｂが設定されている場合、ＲＳＶＰ Ｒｅｓｖ２１７を受信済みであると判定される。
ステップ３５３において、ＲＳＶＰ Ｒｅｓｖ２１７をまだ受信していないと判定された場合、ＨＧＷ１１は、ステップ処理を終了する。
一方、ステップ３５３において、ＲＳＶＰ Ｒｅｓｖ２１７を受信済みであると判定された場合、ＨＧＷ１１は、ＲＳＶＰ Ｒｅｓｖ２１７に対する応答２２１が既に送信されている否かを判定する（３５４）。
第１１図を参照して説明したように、ＨＧＷ１１は、第１１図のステップ３１４の処理の実行が終了し、かつ、ＲＳＶＰ ＲｅｓｖＣｏｎｆ２２０を受信した後であれば、第１３図に示す処理を実行する前にＲＳＶＰ ＲｅｓｖＣｏｎｆ２２１を送信してもよい。このため、ステップ３５４が実行される前に、既にＲＳＶＰ ＲｅｓｖＣｏｎｆ２２１が送信されている場合がある。
ステップ３５４において、応答が既に送信されていると判定された場合、ＨＧＷ１１は、処理を終了する。
一方、ステップ３５４において、応答がまだ送信されていないと判定された場合、ＨＧＷ１１は、端末に成功応答（ＲＳＶＰ ＲｅｓｖＣｏｎｆ２２１）を送信し、さらに、ステップ３５３において設定された状態（１９６）を「成功応答送信済み」に更新して、処理を終了する（３５５）。
第１４図は、本発明の第１の実施の形態におけるセッション切断のための処理を示すシーケンス図である。
第１４図は、例として、第５図に示す処理によって確立されたセッションを切断するためのシーケンスを示す。
最初に、端末（ＵＡ１２）が端末（ＵＡ８）に対してＳＩＰ ＢＹＥ４０１を送信する。ＢＹＥ４０１は、ＨＧＷ１１、ＳＩＰ Ｓｅｒｖｅｒ３、ＳＩＰ Ｓｅｒｖｅｒ１及びＳＩＰ Ｓｅｒｖｅｒ２を経由して端末（ＵＡ８）に到達する。
端末（ＵＡ８）は、ＢＹＥ４０１に対する２００応答４０２を送信する。２００応答４０２は、ＢＹＥと逆の経路を辿り、端末（ＵＡ１２）に到達する。
ＨＧＷ１１は、ＢＹＥ４０１の転送を契機に、ＳＩＰ Ｓｅｓｓｉｏｎ Ｔａｂｌｅ（第４図Ｂ）、Ｆｌｏｗ Ｔａｂｌｅ（第４図Ｃ）及びＲＳＶＰ Ｓｅｓｓｉｏｎ Ｔａｂｌｅ（第４図Ｄ）から、切断されるセッションに対応するエントリを削除する。
ＳＩＰ Ｓｅｒｖｅｒ３は、ＢＹＥ４０１の転送を契機に、サービス情報削除要求４０３をＱｏＳ Ｐｏｌｉｃｙ Ｓｅｒｖｅｒ５に送信する。サービス情報削除要求４０３には、ＳＩＰ Ｓｅｓｓｉｏｎを識別するＳｅｓｓｉｏｎ−ＩＤが含まれる。
ＱｏＳ Ｐｏｌｉｃｙ Ｓｅｒｖｅｒ５は、サービス情報削除要求４０３を受けてＳｅｓｓｉｏｎに属するＦｌｏｗを検索し、Ｆｌｏｗ削除要求４０４をＡＧＷ７に送信する。Ｆｌｏｗ削除要求４０４は、Ｌｉｎｅ−ＩＤ、Ｔｅｒｍｉｎａｌ−ＩＤ及びＦｌｏｗ Ｆｉｌｔｅｒを指定する。
ＡＧＷ７は、Ｆｌｏｗ削除要求４０４によって指定されたＦｌｏｗをローカルのテーブル（図示省略）から削除し、確認応答４０５を返信する。
ＱｏＳ Ｐｏｌｉｃｙ Ｓｅｒｖｅｒ５は、サービス情報及びＦｌｏｗ認可情報を、Ｓｅｒｖｉｃｅ Ｉｎｆｏｒｍａｔｉｏｎ Ｔａｂｌｅ（第３図Ｂ）及びＦｌｏｗ Ｔａｌｂｅ（第３図Ｃ）から削除する。さらに、ＱｏＳ Ｐｏｌｉｃｙ Ｓｅｒｖｅｒ５は、ＳＩＰ Ｓｅｒｖｅｒ３に確認応答４０６を送信する（Ｆ７）。Ｆ７において、ＱｏＳ Ｐｏｌｉｃｙ Ｓｅｒｖｅｒ５は、必要に応じてＰＯＮの回線保証帯域を制御する。
第１５図は、本発明の第１の実施の形態のＱｏＳ Ｐｏｌｉｃｙ Ｓｅｒｖｅｒ５が実行するサービス情報／Ｆｌｏｗ認可削除処理（第１４図のＦ７）を示すフローチャートである。
まず、ＱｏＳ Ｐｏｌｉｃｙ Ｓｅｒｖｅｒ５は、削除するＦｌｏｗの回線情報をＬｉｎｅ Ｔａｂｌｅ（第３図Ｄ）から検索する（４２１）。
次に、ＱｏＳ Ｐｏｌｉｃｙ Ｓｅｒｖｅｒ５は、ステップ４２１において検索された回線情報に含まれる現在帯域（１３６）が最低保証帯域（１３４）を超えるか否かを判定する（４２２）。
ステップ４２２において、現在帯域（１３６）が最低保証帯域（１３４）を超えないと判定された場合、ＱｏＳ Ｐｏｌｉｃｙ Ｓｅｒｖｅｒ５は、ステップ４２３から４２５の処理をスキップする。
一方、ステップ４２２において、現在帯域（１３６）が最低保証帯域（１３４）を超えると判定された場合、ステップ４２１において検索された現在帯域（１３６）と、削除するＦｌｏｗの帯域（１１４）との差が、最低保証帯域（１３４）より大きいか否かを判定する（４２３）。
ステップ４２３において、算出された差が最低保証帯域（１３４）より大きいと判定された場合、ＱｏＳ Ｐｏｌｉｃｙ Ｓｅｒｖｅｒ５は、ＰＯＮの保証帯域を、現在帯域（１３６）とＦｌｏｗ帯域（１１４）との差まで減少させる（４２４）。
一方、ステップ４２３において、算出された差が最低保証帯域（１３４）より小さいと判定された場合、ＱｏＳ Ｐｏｌｉｃｙ Ｓｅｒｖｅｒ５は、ＰＯＮの保証帯域を、最低保証帯域（１３４）まで減少させる（４２５）。
次に、ＱｏＳ Ｐｏｌｉｃｙ Ｓｅｒｖｅｒ５は、ステップ４２１において検索された現在帯域（１３６）からＦｌｏｗ帯域（１１４）を差し引く（４２６）。
次に、ＱｏＳ Ｐｏｌｉｃｙ Ｓｅｒｖｅｒ５は、Ｆｌｏｗ認可情報を、Ｆｌｏｗ Ｔａｂｌｅ（第３図Ｃ）から削除する（４２７）。
次に、ＱｏＳ Ｐｏｌｉｃｙ Ｓｅｒｖｅｒ５は、サービス情報を、Ｓｅｒｖｉｃｅ Ｉｎｆｏｒｍａｔｉｏｎ Ｔａｂｌｅ（第３図Ｄ）から削除する（４２８）。
最後に、ＱｏＳ Ｐｏｌｉｃｙ Ｓｅｒｖｅｒ５は、ＳＩＰ Ｓｅｒｖｅｒに確認応答を送信して（４２９）、処理を終了する。
以上、本発明の第１の実施の形態によれば、ＨＧＷ１１がＳＩＰメッセージに回線の識別子（Ｌｉｎｅ−ＩＤ）を含めてサービス網１４に送信する。その結果、回線単位でＱｏＳを制御することが可能になる。さらに、第１の実施の形態によれば、ＨＧＷ１１が端末の代わりにＱｏＳ設定要求をＡＧＷ７に送信する。その結果、通信事業者との間に信頼関係のある機器のみが、ＱｏＳ設定を制御することが可能になる。
次に、第１６図から第１８図を参照して、本発明の第２の実施の形態を説明する。第２の実施の形態の通信網の構成は、第１の実施の形態と共通である（第１図）。第１の実施の形態では、ＨＧＷ１１がＳＤＰ Ｏｆｆｅｒ／Ａｎｓｗｅｒを含むＳＩＰメッセージに回線ＩＤを追加していた。一方、第２の実施の形態は、端末の位置登録をするためのメッセージであるＳＩＰ ＲＥＧＩＳＴＥＲに回線ＩＤが追加される点で、第１の実施の形態と異なる。このため、第２の実施の形態によれば、回線ＩＤを最初の位置登録時に一回登録すれば、以後その情報を継続して使用することができる。
第２の実施の形態では、ＳＩＰ Ｓｅｒｖｅｒ３が、第１６図Ａに示すＲｅｇｉｓｔｒａｔｉｏｎ Ｔａｂｌｅと、第１６図Ｂに示すＳＩＰ Ｓｅｓｓｉｏｎ Ｔａｂｌｅを備える。
第１６図Ａは、本発明の第２の実施の形態のＳＩＰ Ｓｅｒｖｅｒ３が保持するＲｅｇｉｓｔｒａｔｉｏｎ Ｔａｂｌｅの説明図である。
Ｒｅｇｉｓｔｒａｔｉｏｎ Ｔａｂｌｅ（第１６図Ａ）は、端末の登録情報を管理するために使用される。Ｒｅｇｉｓｔｒａｔｉｏｎ Ｔａｂｌｅ（第１６図Ａ）は、端末の公開アドレスを示すＡｏＲ（Ａｄｄｒｅｓｓ ｏｆ Ｒｅｃｏｒｄ）５０１、端末の通信アドレスを示すＣｏｎｔａｃｔ Ａｄｄｒｅｓｓ５０２、回線を識別するＬｉｎｅ−ＩＤ５０３、及び、登録の有効期限を示すＥｘｐｉｒｅｓ５０４から構成される。
第１６図Ｂは、本発明の第２の実施の形態のＳＩＰ Ｓｅｒｖｅｒ３が保持するＳＩＰ Ｓｅｓｓｉｏｎ Ｔａｂｌｅの説明図である。
ＳＩＰ Ｓｅｓｓｉｏｎ Ｔａｂｌｅ（第１６図Ｂ）は、ＳＩＰ Ｓｅｓｓｉｏｎ状態を管理するために使用される。ＳＩＰ Ｓｅｓｓｉｏｎ Ｔａｂｌｅ（第１６図Ｂ）は、 ＳＩＰ Ｓｅｓｓｉｏｎを一意に識別するＳＩＰ Ｄｉａｌｏｇ ＩＤ５１１、発信端末を識別するＣａｌｌｅｒ’ｓ ＩＤ５１２、着信端末を識別するＣａｌｌｅｅ’ｓ ＩＤ５１３、Ｓｅｓｓｉｏｎ状態を示すＳｔａｔｅ５１４、ＳＤＰ Ｏｆｆｅｒ５１５、及び、ＳＤＰ Ａｎｓｗｅｒ５１６から搆成される。
ＳＩＰ Ｄｉａｌｏｇ ＩＤ５１１は、Ｃａｌｌ−ＩＤ５１１ａ、Ｆｒｏｍ ｔａｇ５１１ｂ及びＴｏ ｔａｇ５１１ｃから構成される。
Ｃａｌｌｅｒ’ｓ ＩＤ５１２は、Ｆｒｏｍ ＵＲＩ５１２ａから構成される。
Ｃａｌｌｅｅ’ｓ ＩＤ５１３は、Ｔｏ ＵＲＩ５１３ａから構成される。
第１の実施の形態のＳＩＰ Ｓｅｓｓｉｏｎ Ｔａｂｌｅ（第２図Ｂ）と異なり、Ｃａｌｌｅｒ’ｓ ＩＤ５１２及びＣａｌｌｅｅ’ｓ ＩＤ５１３はＬｉｎｅ−ＩＤを含まない。
第１７図は、本発明の第２の実施の形態におけるセッション確立のための処理を示すシーケンス図である。
第１７図では、ホーム網１７に接続された端末（ＵＡ１２）が、ＳＩＰ Ｓｅｒｖｅｒ（１、３）に対して位置登録を行う。そして、端末（ＵＡ１２）と端末（ＵＡ８）の間でセッションが確立される。以下、第１７図のシーケンスの詳細を説明する。
まず、端末（ＵＡ１２）は、ＳＩＰ ＲＥＧＩＳＴＥＲ５３１を送信する。
ＨＧＷ１１は、ＲＥＧＩＳＴＥＲ５３１にＬｉｎｅ−ＩＤを追加してＳＩＰ Ｓｅｒｖｅｒ３に転送する（Ｆ１１）。
ＳＩＰ Ｓｅｒｖｅｒ３は、ＲＥＧＩＳＴＥＲ５３１からＬｉｎｅ−ＩＤを削除し、削除したＬｉｎｅ−ＩＤを、端末のＡｏＲと共にＲｅｇｉｓｔｒａｔｉｏｎ Ｔａｂｌｅ（第１６図Ａ）に記録する。そして、ＳＩＰ Ｓｅｒｖｅｒ３は、ＲＥＧＩＳＴＥＲ５３１をＳＩＰ Ｓｅｒｖｅｒ１に転送する。
ＳＩＰ Ｓｅｒｖｅｒ１は、ＲＥＧＩＳＴＥＲ５３１に対する２００応答５３２を返信する。２００応答５３２は、ＲＥＧＩＳＴＥＲ５３１と逆の経路を辿り、端末（ＵＡ１２）に到達する。
次に、端末（ＵＡ１２）は、ＳＤＰ Ｏｆｆｅｒを含むＳＩＰ ＩＮＶＩＴＥ５３３を送信する。ＩＮＶＩＴＥ５３３は、ＨＧＷ１１、ＳＩＰ Ｓｅｒｖｅｒ３、ＳＩＰ Ｓｅｒｖｅｒ１及びＳＩＰ Ｓｅｒｖｅｒ２を経由して端末（ＵＡ８）に到達する。
端末（ＵＡ８）は、ＳＤＰ Ａｎｓｗｅｒを含む１８３応答５３４を返信する。
端末（ＵＡ１２）は、１８３応答５３４に対するＰＲＡＣＫ５３５を返信する。
端末（ＵＡ８）は、ＰＲＡＣＫ５３５に対する２００応答５３６を返信する。
ＳＩＰ Ｓｅｒｖｅｒ３は、ＳＤＰ Ａｎｓｗｅｒの転送を契機として、サービス情報５３７をＱｏＳ Ｐｏｌｉｃｙ Ｓｅｒｖｅｒ５に通知する（Ｆ１２）。このサービス情報通知５３７の通知は、ＰＲＡＣＫ５３５の送信の前又は後のいずれに実行されてもよいし、２００応答５３６の送信の前又は後のいずれに実行されてもよい。
サービス情報通知５３７は、Ｓｅｓｓｉｏｎ−ＩＤ、Ｌｉｎｅ−ＩＤ、Ｔｅｒｍｉｎａｌ−ＩＤ、ＦｌｏｗＦｉｌｔｅｒ及び帯域を含む。
以降のシーケンスは、第５図の２１６〜２２９と同様であるため省略する。
次に、第１８図及び第１９図を参照して、第１７図のシーケンスに特徴的な処理を説明する。
第１８図は、本発明の第２の実施の形態のＨＧＷ１１が実行するＬｉｎｅ−ＩＤ追加判定処理（第１７図のＦ１１）を示すフローチャートである。
最初に、ＨＧＷ１１は、転送するＳＩＰ ＭｅｓｓａｇｅがＲＥＧＩＳＴＥＲであるか否かを判定する（５５１）。
ステップ５５１において、転送するＳＩＰ ＭｅｓｓａｇｅがＲＥＧＩＳＴＥＲでないと判定された場合、ＨＧＷ１１は処理を終了する。
一方、ステップ５５１において、転送するＳＩＰ ＭｅｓｓａｇｅがＲＥＧＩＳＴＥＲであると判定された場合、ＨＧＷ１１は、ＲＥＧＩＳＴＥＲにＬｉｎｅ−ＩＤを追加し（５５２）、処理を終了する。
第１８図の処理を実行することによって、所定の種類の信号（第１８図の例では、ＲＥＧＩＳＴＥＲ）のみに回線ＩＤが追加されるため、処理を効率化することができる。
第１９図は、本発明の第２の実施の形態のＳＩＰ Ｓｅｒｖｅｒ３が実行するサービス情報通知処理（第１７図のＦ１２）を示すフローチャートである。
第１９図に示す処理は、第１の実施の形態のサービス情報通知処理（第９図）と以下の点で異なる。
まず、第９図のステップ２７４では、端末が固定アクセス網１６に接続されているか否かを、ＳＩＰ Ｓｅｓｓｉｏｎ Ｔａｂｌｅ（第２図Ｂ）のＬｉｎｅ−ＩＤフィールド（７２ｂ又は７３ｂ）が設定されているか否かに基づいて判定していた。これに対し、第１９図のステップ５７４では、ＳＩＰ Ｒｅｇｉｓｔｒａｔｉｏｎ Ｔａｂｌｅ（第１６図Ａ）に端末が登録されているか否かに基づいて、同様の判定が実行される。
また、第９図のステップ２７５では、Ｌｉｎｅ−ＩＤをＳＩＰ Ｓｅｓｓｉｏｎ Ｔａｂｌｅ（第２図Ｂ）のＬｉｎｅ−ＩＤフィールド（７２ｂ又は７３ｂ）から取得していた。これに対し、第１９図のステップ５７５では、ＳＩＰ Ｒｅｇｉｓｔｒａｔｉｏｎ Ｔａｂｌｅ（第１６図Ａ）のＬｉｎｅ−ＩＤフィールド（５０３）からＬｉｎｅ−ＩＤが取得される。
上記の相違点を除いて、第１９図のステップ５７１から５７９は、それぞれ、第９図のステップ２７１から２７９と同様である。
次に、第２０図から第２５図を参照して、本発明の第３の実施の形態を説明する。
第２０図は、本発明の第３の実施の形態における通信網の構成例を示す説明図である。
第１及び第２の実施の形態では、固定アクセス網１６のＡＧＷ７とＨＧＷ１１の間で、ＩｎｔＳｅｒｖ（Ｉｎｔｅｇｒａｔｅｄ Ｓｅｒｖｉｃｅｓ）モデルに基づくフロー単位の帯域保証が実行されていた。一方、第３の実施の形態では、第１及び第２の実施の形態と異なり、ＤｉｆｆＳｅｒｖ（Ｄｉｆｆｅｒｅｎｔｉａｔｅｄ Ｓｅｒｖｉｃｅｓ）モデルに基づく優先制御が実行される。
第２０図に示す通信網は、アクセス非依存のサービス網７１４、移動アクセス網７１５、固定アクセス網７１６及びホーム網７１７から構成される。以下に説明するように、第３の実施の形態によれば、ＤｉｆｆＳｅｒｖモデルに基づく優先制御を行う場合にも、セッション制御信号に含まれる情報を用いて回線単位の帯域制御を行うことができる。
サービス網７１４は、ＳＩＰ Ｓｅｒｖｅｒ（７０１、７０２及び７０３）、ＱｏＳ Ｐｏｌｉｃｙ Ｓｅｒｖｅｒ（７０４及び７０５）、及び、ＡＧＷ（７０６及び７０７）
を備える。
移動アクセス網７１５は、ＵＡ７０８を備える。
固定アクセス網７１６は、ＯＬＴ７０９及びＯＮＵ７１０を備える。
ホーム網７１７は、ＨＧＷ７１１及びＵＡ（７１２及び７１３）を備える。ＨＧＷ７１１には、回線ＩＤ（Ｌｉｎｅ−ＩＤ：５６７８９）が設定されている。
固定アクセス網７１６では、次のようなＱｏＳ処理が実行される。
ＡＧＷ７０７及びＨＧＷ７１１は、Ｌａｙｅｒ３以上で優先フローを識別し、ＩＰｖ４ヘッダのＴＯＳフィールド又はＩＰｖ６ヘッダのＴｒａｆｆｉｃ Ｃｌａｓｓフィールドにマーキングを行う。さらに、ＡＧＷ７０７及びＨＧＷ７１１は、マーキング結果に従い優先制御を行う。第１及び第２の実施の形態と異なり、優先フローを識別するためのフィルタ情報は静的に設定される。
ＯＬＴ７０９及びＯＮＵ７１０は、Ｌａｙｅｒ２レベルで優先フローの帯域保証を行う。優先フローの識別は、ＡＧＷ７０７及びＨＧＷ７１１によるマーキング結果に従う。保証帯域は、必要に応じてＱｏＳ Ｐｏｌｉｃｙ Ｓｅｒｖｅｒ７０５によって制御される。
第２１図Ａは、本発明の第３の実施の形態のＱｏＳ Ｐｏｌｉｃｙ Ｓｅｒｖｅｒ７０５の装置構成を示すブロック図である。
ＱｏＳ Ｐｏｌｉｃｙ Ｓｅｒｖｅｒ７０５は、Ｈａｒｄ Ｄｉｓｋ７３１、ＣＰＵ７３２、Ｍｅｍｏｒｙ７３３、ＩＦ（７３４ａ、７３４ｂ及び７３４ｃ）、及び、バス７３５を備える。ＱｏＳ Ｐｏｌｉｃｙ Ｓｅｒｖｅｒ７０５の処理手順は、Ｍｅｍｏｒｙ７３３に格納されており、ＣＰＵ７３２が順次それを読み出して実行する。
ＱｏＳ Ｐｏｌｉｃｙ Ｓｅｒｖｅｒ７０５は、第２１図Ｂに示すＳｅｒｖｉｃｅ Ｉｎｆｏｒｍａｔｉｏｎ Ｔａｂｌｅ、及び、第２１図Ｃに示すＬｉｎｅ Ｔａｂｌｅを保持する。
第２１図Ｂは、本発明の第３の実施の形態のＱｏＳ Ｐｏｌｉｃｙ Ｓｅｒｖｅｒ７０５が保持するＳｅｒｖｉｃｅ Ｉｎｆｏｒｍａｔｉｏｎ Ｔａｂｌｅの説明図である。
Ｓｅｒｖｉｃｅ Ｉｎｆｏｒｍａｔｉｏｎ Ｔａｂｌｅ（第２１図Ｂ）は、ＳＩＰ Ｓｅｒｖｅｒ７０３に認可したサービス情報を管理するためのテーブルである。Ｓｅｒｖｉｃｅ Ｉｎｆｏｒｍａｔｉｏｎ Ｔａｂｌｅ（第２１図Ｂ）は、ＳＩＰ Ｓｅｓｓｉｏｎを識別するＳｅｓｓｉｏｎ ＩＤ７５１、回線を識別するＬｉｎｅ−ＩＤ７５２、端末を識別するＴｅｒｍｉｎａｌ−ＩＤ７５３、フローを識別するＦｌｏｗ Ｆｉｌｔｅｒ７５４、及び、使用帯域を示すＢａｎｄｗｉｄｔｈ７５５から構成される。Ｆｌｏｗ Ｆｉｌｔｅｒ７５４は、Ｓｒｃ ＩＰ７５４ａ、Ｄｓｔ ＩＰ７５４ｂ、ｐｒｏｔｏ７５４ｃ、Ｓｒｃ Ｐｏｒｔ７５４ｄ及びＤｓｔ Ｐｏｒｔ７５４ｅから構成される。
第２１図Ｃは、本発明の第３の実施の形態のＱｏＳ Ｐｏｌｉｃｙ Ｓｅｒｖｅｒ７０５が保持するＬｉｎｅ Ｔａｂｌｅの説明図である。
Ｌｉｎｅ Ｔａｂｌｅ（第２１図Ｃ）は、回線の帯域を管理するためのテーブルである。Ｌｉｎｅ Ｔａｂｌｅ（第２１図Ｃ）は、回線を識別するＬｉｎｅ−ＩＤ７７１、ＯＮＵを識別するＯＮＵ−ＩＤ７７２、ＯＬＴを識別するＯＬＴ−ＩＤ７７３、回線の最低保証帯域Ｍｉｎ Ｂａｎｄｗｉｄｔｈ７７４、最大保証帯域Ｍａｘ Ｂａｎｄｗｉｄｔｈ７７５、現在帯域Ｃｕｒｒｅｎｔ Ｂａｎｄｗｉｄｔｈ７７６、及び、回線を使用するサービス情報（第２１図Ｂ Ｓｅｒｖｉｃｅ Ｉｎｆｏｒｍａｔｉｏｎ Ｔａｂｌｅ）へのポインタＰｏｉｎｔｅｒ ｔｏ Ｓｅｒｖｉｃｅ Ｉｎｆｏ． Ｔａｂｌｅ７７７から構成される。回線を使用するフローが複数存在する場合、Ｐｏｉｎｔｅｒ ｔｏ Ｓｅｒｖｉｃｅ Ｉｎｆｏ． Ｔａｂｌｅ７７７には複数のポインタが設定される。
第２２図Ａ及び第２２図Ｂは、本発明の第３の実施の形態におけるセッション確立のための処理を示すシーケンス図である。
第２２図Ａ及び第２２図Ｂでは、端末（ＵＡ７１２）がＤＨＣＰｖ６を使用してＨＧＷ７１１から回線ＩＤを取得する。そして、端末（ＵＡ７１２）自身がＳＩＰ ＩＮＶＩＴＥに回線ＩＤを含めて送信し、端末（ＵＡ７０８）との間にセッションを確立する。第１及び第２の実施の形態と異なり、本シーケンスでは、ＳＩＰ Ｓｅｒｖｅｒ７０３からのサービス情報通知と同時にＱｏＳ認可が実行される。
以下、第２２図Ａ及び第２２図Ｂの詳細を説明する。
第２２図Ａにおいて、端末（ＵＡ７１２）は、まずＤＨＣＰｖ６ Ｉｎｆｏｒｍａｔｉｏｎ−Ｒｅｑｕｅｓｔ７９１をＨＧＷ７１１に送信して、Ｌｉｎｅ−ＩＤを要求する。ＨＧＷ７１１は、ＤＨＣＰｖ６ Ｉｎｆｏｒｍａｔｉｏｎ−Ｒｅｐｌｙ７９２を返信して、Ｌｉｎｅ−ＩＤを通知する。
次に、端末（ＵＡ７１２）は、ＳＩＰ ＩＮＶＩＴＥ７９３ａをＳＩＰ Ｓｅｒｖｅｒ７０３に送信する。ＳＩＰ ＩＮＶＩＴＥ７９３ａは、ＳＤＰ Ｏｆｆｅｒ及びＬｉｎｅ−ＩＤを含む。
ＳＩＰ ＩＮＶＩＴＥ７９３ａには、これから確立しようとするセッションにおいて端末（ＵＡ７１２）が要求する帯域を示す情報が含まれる。
ＳＩＰ Ｓｅｒｖｅｒ７０３は、ＩＮＶＩＴＥ７９３ａからＬｉｎｅ−ＩＤを削除し、そのＬｉｎｅ−ＩＤをＳｅｓｓｉｏｎ情報と共に記録する。さらに、ＳＩＰ Ｓｅｒｖｅｒ７０３は、サービス認可要求７９４をＱｏＳ Ｐｏｌｉｃｙ Ｓｅｒｖｅｒ７０５に送信する。サービス認可要求７９４には、ＳＩＰ／ＳＤＰ Ｍｅｓｓａｇｅから抽出されたＳｅｓｓｉｏｎ−ＩＤ、Ｌｉｎｅ−ＩＤ、Ｔｅｒｍｉｎａｌ−ＩＤ、Ｆｌｏｗ Ｆｉｌｔｅｒ及び帯域が含まれる。サービス認可要求７９４に含まれる帯域は、Ｔｅｒｍｉｎａｌ−ＩＤによって識別される端末がセッションにおいて要求する帯域である。
ＱｏＳ Ｐｏｌｉｃｙ Ｓｅｒｖｅｒ７０５は、回線帯域を考慮して、サービス認可及びＰＯＮの帯域制御を行う（Ｆ２１）。
Ｆ２１に示すサービス認可に失敗した場合、ＱｏＳ Ｐｏｌｉｃｙ Ｓｅｒｖｅｒ７０５は、第２２図Ｂに示すエラー応答８１１を返信する。エラー応答８１１を受けたＳＩＰ Ｓｅｒｖｅｒ７０３は、端末（ＵＡ７１２）に４８８応答８１２を返信し、セッション確立が失敗する。
一方、Ｆ２１に示すサービス認可に成功した場合、ＱｏＳ Ｐｏｌｉｃｙ Ｓｅｒｖｅｒ７０５は、第２２図Ａに示す成功応答７９５を返信する。成功応答７９５を受けたＳＩＰ Ｓｅｒｖｅｒ７０３は、ＩＮＶＩＴＥ７９３ｂを端末（ＵＡ７０８）に転送する。
端末（ＵＡ７０８）は、ユーザの呼び出しを開始し、１８０応答７９６を返信する。さらに、端末（ＵＡ７０８）は、ユーザがオフフックしたことを契機に、ＳＤＰ Ａｎｓｗｅｒを含む２００応答７９７を送信する。
端末（ＵＡ７１２）は、ＡＣＫ７９８を返信する。その結果、Ｍｅｄｉａ Ｆｌｏｗ７９９の送受信が開始する。
なお、第３の実施の形態では、ＵＡ７１２がＨＧＷ７１１からＬｉｎｅ−ＩＤを取得し（７９１、７９２）、そのＬｉｎｅ−ＩＤを含むＳＩＰ ＩＮＶＩＴＥ７９３ａをＳＩＰ Ｓｅｒｖｅｒ７０３に送信する。しかし、第１の実施の形態と同様に、ＨＧＷ７１１が、ＵＡ７１２から受信したＳＩＰ ＩＮＶＩＴＥ（第５図のＳＩＰ ＩＮＶＩＴＥ２１１参照）にＬｉｎｅ−ＩＤを追加し（第５図のＦ１参照）、そのＳＩＰ ＩＮＶＩＴＥをＳＩＰ Ｓｅｒｖｅｒ７０３に送信してもよい。
逆に、第１の実施の形態において、ＵＡ１２が、第３の実施の形態と同様、ＨＧＷ１１からＬｉｎｅ−ＩＤを取得し、そのＬｉｎｅ−ＩＤを含むＳＩＰ ＩＮＶＩＴＥをＳＩＰ Ｓｅｒｖｅｒ３に送信してもよい。
第２３図は、本発明の第３の実施の形態のＱｏＳ Ｐｏｌｉｃｙ Ｓｅｒｖｅｒ７０５が実行するサービス認可処理（第２２図ＡのＦ２１）を説明するフローチャートである。
ＱｏＳ Ｐｏｌｉｃｙ Ｓｅｒｖｅｒ７０５は、まず、受信したサービス認可要求に対応するエントリをＳｅｒｖｉｃｅ Ｉｎｆｏｒｍａｔｉｏｎ Ｔａｂｌｅ（第２１図Ｂ）に設定する（８３１）。
次に、ＱｏＳ Ｐｏｌｉｃｙ Ｓｅｒｖｅｒ７０５は、サービス情報のＬｉｎｅ−ＩＤ（７５２）に基づいて、Ｌｉｎｅ Ｔａｂｌｅ（第２１図Ｃ）から回線情報を検索する（８３２）。具体的には、受信したＱｏＳ認可要求に含まれるＬｉｎｅ−ＩＤ（７５２）と同一の値がＬｉｎｅ−ＩＤ（７７１）として登録されているエントリをＬｉｎｅ Ｔａｂｌｅ（第２１図Ｃ）から検索する。
次に、ＱｏＳ Ｐｏｌｉｃｙ Ｓｅｒｖｅｒ７０５は、ステップ８３２において検索された現在帯域（７７６）と、サービス情報の帯域（７５５）との和が、ステップ８３２において検索された最大保証帯域（７７５）を超えるか否かを判定する（８３３）。
ステップ８３３において、現在帯域（７７６）とサービス情報の帯域（７５５）との和が最大保証帯域（７７５）を超えると判定された場合、ＱｏＳ Ｐｏｌｉｃｙ Ｓｅｒｖｅｒ７０５は、ステップ８３１において設定されたエントリを削除し、さらに、ＳＩＰ Ｓｅｒｖｅｒにエラー応答８１１（第２２図Ｂ参照）を送信して、処理を終了する（８３４）。
一方、ステップ８３３において、現在帯域（７７６）とサービス情報の帯域（７５５）との和が最大保証帯域（７７５）を超えないと判定された場合、ＱｏＳ Ｐｏｌｉｃｙ Ｓｅｒｖｅｒ７０５は、ステップ８３２において検索された現在帯域（７７６）とサービス情報の帯域（７５５）との和が、ステップ８３２において検索された最低保証帯域（７７４）を超えるか否かを判定する（８３５）。
ステップ８３３において、現在帯域（７７６）とサービス情報の帯域（７５５）との和が最低保証帯域（７７４）を超えると判定された場合、ＱｏＳ Ｐｏｌｉｃｙ Ｓｅｒｖｅｒ７０５は、ＰＯＮの保証帯域を、ステップ８３２において検索された現在帯域（７７６）とサービス情報の帯域（７５５）との和まで増加させる（８３６）。
一方、ステップ８３３において、現在帯域（７７６）とサービス情報の帯域（７５５）との和が最低保証帯域（７７４）を超えないと判定された場合、ＱｏＳ Ｐｏｌｉｃｙ Ｓｅｒｖｅｒ７０５は、ステップ８３６の処理をスキップする。
最後に、ＱｏＳ Ｐｏｌｉｃｙ Ｓｅｒｖｅｒ７０５は、ステップ８３２において検索された現在帯域（７７６）にサービス情報の帯域（７５５）を加算し、ＳＩＰ Ｓｅｒｖｅｒに成功応答７９５（第２２図Ａ参照）を送信して、処理を終了する。
第１の実施の形態における第１２図の処理と同様、上記の第２３図の処理によって、同一のＬｉｎｅ−ＩＤと関連付けられたセッションにおいて要求される帯域に基づいて、ＱｏＳが制御される。同一のＬｉｎｅ−ＩＤと関連付けられたセッションとは、同一のＨＧＷ７１１を経由するセッション（すなわち、固定アクセス網７１６において同一の回線を使用するセッション）である。
すなわち、同一の回線を使用する複数のＦｌｏｗが存在する場合、それらの全てのＦｌｏｗにおいて要求される帯域の合計値が算出される（８３３、８３５）。そして、算出された合計値が、固定アクセス網１６における保証帯域として設定される（８３６）。ただし、算出された合計値が最大保証帯域を超える場合、固定アクセス網７１６における保証帯域は変更されずに、エラーが応答される（８３４）。算出された合計値が最低保証帯域を超えない場合、最低保証帯域が、固定アクセス網１６における保証帯域として設定される。
第２４図は、本発明の第３の実施の形態におけるセッション切断のために実行される処理を示すシーケンス図である。
本シーケンスでは、まず、端末（ＵＡ７１２）がＢＹＥ８５１を送信する。ＢＹＥ８５１を受けた端末（ＵＡ７０８）は、２００応答８５２を返信する。
ＳＩＰ Ｓｅｒｖｅｒ７０３は、ＢＹＥ８５１の転送を契機に、サービス認可削除要求８５３をＱｏＳ Ｐｏｌｉｃｙ Ｓｅｒｖｅｒ７０５に送信する。この要求は、２００応答８５２より早く送信されてもよい。サービス認可削除要求８５３は、Ｓｅｓｓｉｏｎを識別するＳｅｓｓｉｏｎ−ＩＤを含む。
ＱｏＳ Ｐｏｌｉｃｙ Ｓｅｒｖｅｒ７０５は、Ｓｅｓｓｉｏｎ−ＩＤに対応するサービス情報を削除し、ＰＯＮの保証帯域を制御する（Ｆ２２）。
第２５図は、本発明の第３の実施の形態のＱｏＳ Ｐｏｌｉｃｙ Ｓｅｒｖｅｒ７０５が実行するサービス認可削除処理（第２４図のＦ２２）を説明するフローチャートである。
ＱｏＳ Ｐｏｌｉｃｙ Ｓｅｒｖｅｒ７０５は、まず、指定されたＳｅｓｓｉｏｎ−ＩＤに関連するサービス情報をＳｅｒｖｉｃｅ Ｉｎｆｏｒｍａｔｉｏｎ Ｔａｂｌｅ（第２１図Ｂ）から検索する（８７１）。
次に、ＱｏＳ Ｐｏｌｉｃｙ Ｓｅｒｖｅｒ７０５は、ステップ８７１において検索された全てのサービス情報に関して、ループ（８７２−８８０）の処理を実行する。
まず、ＱｏＳ Ｐｏｌｉｃｙ Ｓｅｒｖｅｒ７０５は、Ｓｅｒｖｉｃｅ Ｉｎｆｏｒｍａｔｉｏｎ Ｔａｂｌｅ（第２１図Ｂ）のＬｉｎｅ−ＩＤ（７５２）を使用して、Ｌｉｎｅ Ｔａｂｌｅ（第２１図Ｃ）から回線情報を検索する（８７３）。
次に、ＱｏＳ Ｐｏｌｉｃｙ Ｓｅｒｖｅｒ７０５は、ステップ８７３において検索された現在帯域（７７６）が最低保証帯域（７７４）を超えるか否かを判定する（８７４）。
ステップ８７４において、現在帯域（７７６）が最低保証帯域（７７４）を超えないと判定された場合、ＱｏＳ Ｐｏｌｉｃｙ Ｓｅｒｖｅｒ７０５は、ステップ８７５から８７７までの処理をスキップする。
一方、ステップ８７４において、現在帯域（７７６）が最低保証帯域（７７４）を超えると判定された場合、ＱｏＳ Ｐｏｌｉｃｙ Ｓｅｒｖｅｒ７０５は、ステップ８７３において検索された現在帯域（７７６）とサービス情報の帯域（７５５）の差が、最低保証帯域（７７４）よりも大きいか否かを判定する（８７５）。
ステップ８７５において、現在帯域（７７６）とサービス情報の帯域（７５５）の差が最低保証帯域（７７４）よりも大きいと判定された場合、ＱｏＳ Ｐｏｌｉｃｙ Ｓｅｒｖｅｒ７０５は、ＰＯＮの保証帯域を、現在帯域（７７６）とサービス情報の帯域（７５５）の差まで減少させる（８７６）。
一方、現在帯域（７７６）とサービス情報の帯域（７５５）の差が最低保証帯域（７７４）以下であると判定された場合、ＱｏＳ Ｐｏｌｉｃｙ Ｓｅｒｖｅｒ７０５は、ＰＯＮの保証帯域を、最低保証帯域（７７４）まで減少させる（８７７）。
次に、ＱｏＳ Ｐｏｌｉｃｙ Ｓｅｒｖｅｒ７０５は、ステップ８７３において検索された現在帯域（７７６）からサービス情報の帯域（７５５）を差し引く（８７８）。
次に、ＱｏＳ Ｐｏｌｉｃｙ Ｓｅｒｖｅｒ７０５は、サービス情報を、Ｓｅｒｖｉｃｅ Ｉｎｆｏｒｍａｔｉｏｎ Ｔａｂｌｅ（第２１図Ｂ）から削除する（８７９）。
以上で、ＱｏＳ Ｐｏｌｉｃｙ Ｓｅｒｖｅｒ７０５は、第２５図に示す処理を終了する。
Claims (11)
- アクセス回線を介して通信網に接続される複数の端末と、前記端末から送信されたセッション制御信号を処理するセッション制御サーバと、前記アクセス回線のＱｏＳを制御するＱｏＳ制御サーバと、前記端末を前記アクセス回線に接続する端末収容装置と、を備える通信システムにおいて、
前記端末は、少なくとも、前記端末がセッションにおいて要求する帯域を示す情報を含む前記セッション制御信号を前記端末収容装置に送信し、
前記端末収容装置は、前記アクセス回線の識別子を前記セッション制御信号に追加して前記セッション制御サーバに送信し、
前記セッション制御サーバは、受信した前記アクセス回線の識別子と、前記端末がセッションにおいて要求する帯域を示す情報とを前記ＱｏＳ制御サーバに送信し、
前記ＱｏＳ制御サーバは、同一の前記アクセス回線の識別子と関連付けられたセッションにおいて要求される帯域に基づいてＱｏＳを制御することを特徴とする通信システム。 - 前記アクセス回線の識別子は、前記セッション制御信号に含まれることを特徴とする請求項１に記載の通信システム。
- 前記セッション制御信号は、ＳＩＰに準拠する信号であり、
前記アクセス回線の識別子は、ＳＩＰヘッダに設定されることを特徴とする請求項１に記載の通信システム。 - 前記セッション制御信号は、ＳＩＰに準拠する信号及びＳＤＰに準拠する信号を含み、
前記アクセス回線の識別子は、ＳＤＰ属性行に設定されることを特徴とする請求項１に記載の通信システム。 - 前記セッション制御信号が所定の種類の信号である場合、前記アクセス回線の識別子が前記セッション制御信号に追加されることを特徴とする請求項１に記載の通信システム。
- 前記端末収容装置は、前記受信したセッション制御信号及び前記アクセス回線の識別子に基づいて生成された第１のＱｏＳ制御信号を前記ＱｏＳ制御サーバに送信し、
前記ＱｏＳ制御サーバは、前記第１のＱｏＳ制御信号を受信すると、受信した前記第１のＱｏＳ制御信号に基づいて、前記アクセス回線のＱｏＳを制御することを特徴とする請求項１に記載の通信システム。 - 前記端末収容装置は、
前記セッション制御信号に基づいて、前記第１のＱｏＳ制御信号と、前記端末と前記端末収容装置との間のＱｏＳを制御するための第２のＱｏＳ制御信号と、を対応付け、
前記第１のＱｏＳ制御信号に対する応答を受信した後で、前記受信した第１のＱｏＳ制御信号に対応する前記第２のＱｏＳ制御信号に対する応答を、前記端末に送信することを特徴とする請求項６に記載の通信システム。 - 通信システムにおける通信を制御する通信制御装置において、
前記通信システムは、アクセス回線を介して通信網に接続される複数の端末と、少なくとも一つの前記端末を前記アクセス回線に接続する前記通信制御装置と、前記端末から送信されたセッション制御信号を処理するセッション制御サーバと、前記アクセス回線のＱｏＳを制御するＱｏＳ制御サーバと、を備え、
前記通信制御装置は、
前記セッション制御信号を前記端末から受信し、
前記アクセス回線の識別子を前記受信したセッション制御信号に追加し、
前記アクセス回線の識別子が追加されたセッション制御信号を前記前記セッション制御サーバに送信し、
前記ＱｏＳ制御サーバに前記アクセス回線のＱｏＳを制御させるための第１のＱｏＳ制御信号を、前記端末がセッションにおいて要求する帯域、及び、前記アクセス回線の識別子に基づいて生成し、
前記生成された第１のＱｏＳ制御信号を前記ＱｏＳ制御サーバに送信することを特徴とする通信制御装置。 - 前記通信制御装置は、
前記セッション制御信号に基づいて、前記第１のＱｏＳ制御信号と、前記端末と前記通信制御装置との間のＱｏＳを制御するための第２のＱｏＳ制御信号と、を対応付け、
前記第１のＱｏＳ制御信号に対する応答を受信した後で、前記受信した第１のＱｏＳ制御信号に対応する前記第２のＱｏＳ制御信号に対する応答を、前記端末に送信することを特徴とする請求項８に記載の通信制御装置。 - アクセス回線を介して通信網に接続される複数の端末と、前記端末から送信されたセッション制御信号を処理するセッション制御サーバと、前記アクセス回線のＱｏＳを制御するＱｏＳ制御サーバと、前記端末を前記アクセス回線に接続する端末収容装置と、を備える通信システムの制御方法であって、
前記制御方法は、
前記端末が、少なくとも、セッションにおいて前記端末が要求する帯域を示す情報を含む前記セッション制御信号を前記端末収容装置に送信し、
前記端末収容装置が、前記アクセス回線の識別子を前記セッション制御信号に追加して前記セッション制御サーバに送信し、
前記セッション制御サーバが、受信した前記アクセス回線の識別子と、セッションにおいて前記端末が要求する帯域を示す情報とを前記ＱｏＳ制御サーバに送信し、
前記ＱｏＳ制御サーバが、同一の前記アクセス回線の識別子と関連付けられたセッションにおいて要求される帯域に基づいてＱｏＳを制御することを特徴とする方法。 - 前記アクセス回線の識別子は、前記セッション制御信号に含まれることを特徴とする請求項１０に記載の方法。
Applications Claiming Priority (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2006209570 | 2006-08-01 | ||
| JP2006209570 | 2006-08-01 | ||
| PCT/JP2007/059128 WO2008015832A1 (fr) | 2006-08-01 | 2007-04-20 | Qualité de service pour chaque ligne commandant un appareil de commande de communication, système de communication et procédé de commande à cet effet |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JPWO2008015832A1 JPWO2008015832A1 (ja) | 2009-12-17 |
| JP4643712B2 true JP4643712B2 (ja) | 2011-03-02 |
Family
ID=38997016
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2008527677A Expired - Fee Related JP4643712B2 (ja) | 2006-08-01 | 2007-04-20 | 回線ごとにＱｏＳを制御する通信制御装置、通信システム及びその制御方法 |
Country Status (3)
| Country | Link |
|---|---|
| US (1) | US20090313366A1 (ja) |
| JP (1) | JP4643712B2 (ja) |
| WO (1) | WO2008015832A1 (ja) |
Families Citing this family (10)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101595695B (zh) * | 2007-01-26 | 2012-11-14 | 日本电气株式会社 | 视频分发系统和视频分发方法 |
| JP5091569B2 (ja) * | 2007-07-11 | 2012-12-05 | 株式会社日立製作所 | サービス毎通信制御装置、システム及び方法 |
| JP5006266B2 (ja) * | 2008-06-10 | 2012-08-22 | 日本電信電話株式会社 | 通信ネットワークにおける帯域制御方法及び該方法を実行するための通信装置 |
| WO2010014997A2 (en) * | 2008-08-01 | 2010-02-04 | Tekelec | Methods, systems, and computer readable media for session initiation protocol (sip) dialog identification |
| US8418228B2 (en) * | 2008-12-03 | 2013-04-09 | Electronics And Telecommunications Research Institute | Converged access control method using network access device at penetration node of IP network of convergence ALL-IP network |
| JP5247534B2 (ja) * | 2009-02-26 | 2013-07-24 | 株式会社Ｋｄｄｉ研究所 | ホームゲートウェイによって異なる経路の複数のセッションを確立する方法及びシステム |
| JP5123239B2 (ja) * | 2009-03-24 | 2013-01-23 | Ｋｄｄｉ株式会社 | 通信システム、サーバ装置、端末装置およびノード |
| JP5335712B2 (ja) * | 2010-02-12 | 2013-11-06 | 日本電信電話株式会社 | ＱｏＳ制御装置、及びＱｏＳ制御方法 |
| JP5511709B2 (ja) * | 2011-02-18 | 2014-06-04 | 日本電信電話株式会社 | ＱｏＳ制御システム、ＱｏＳ制御管理装置、及びＱｏＳ制御方法 |
| JP6170781B2 (ja) * | 2013-08-26 | 2017-07-26 | 株式会社Ｎｔｔドコモ | 通信制御装置および通信制御方法 |
Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| EP0848560A2 (en) * | 1996-12-13 | 1998-06-17 | Siemens Business Communication Systems, Inc. | Method and system for increasing quality of service at or below a treshold cost |
| JP2000253053A (ja) * | 1999-02-25 | 2000-09-14 | Hitachi Ltd | ネットワークシステム |
| JP2001230819A (ja) * | 1999-12-30 | 2001-08-24 | At & T Corp | Ｉｐ専用回線 |
Family Cites Families (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP3721880B2 (ja) * | 1998-10-05 | 2005-11-30 | 株式会社日立製作所 | パケット中継装置 |
| US7684432B2 (en) * | 2003-05-15 | 2010-03-23 | At&T Intellectual Property I, L.P. | Methods of providing data services over data networks and related data networks, data service providers, routing gateways and computer program products |
| JP4673369B2 (ja) * | 2004-07-30 | 2011-04-20 | テレフオンアクチーボラゲット エル エム エリクソン（パブル） | ハイブリッド通信ネットワークにおいて相関手段を提供する方法および装置 |
| US7626950B2 (en) * | 2004-08-18 | 2009-12-01 | At&T Intellectual Property, I,L.P. | SIP-based session control among a plurality of multimedia devices |
| KR20060038296A (ko) * | 2004-10-29 | 2006-05-03 | 삼성전자주식회사 | 이동통신 네트워크에서의 멀티플렉싱 장치 및 방법 |
-
2007
- 2007-04-20 WO PCT/JP2007/059128 patent/WO2008015832A1/ja active Application Filing
- 2007-04-20 JP JP2008527677A patent/JP4643712B2/ja not_active Expired - Fee Related
- 2007-04-20 US US12/375,595 patent/US20090313366A1/en not_active Abandoned
Patent Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| EP0848560A2 (en) * | 1996-12-13 | 1998-06-17 | Siemens Business Communication Systems, Inc. | Method and system for increasing quality of service at or below a treshold cost |
| JP2000253053A (ja) * | 1999-02-25 | 2000-09-14 | Hitachi Ltd | ネットワークシステム |
| JP2001230819A (ja) * | 1999-12-30 | 2001-08-24 | At & T Corp | Ｉｐ専用回線 |
Also Published As
| Publication number | Publication date |
|---|---|
| JPWO2008015832A1 (ja) | 2009-12-17 |
| US20090313366A1 (en) | 2009-12-17 |
| WO2008015832A1 (fr) | 2008-02-07 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP4643712B2 (ja) | 回線ごとにＱｏＳを制御する通信制御装置、通信システム及びその制御方法 | |
| US8159941B2 (en) | In-band DPI media reservation modifications to RFC 3313 | |
| EP1788764B1 (en) | The process system for the packet domain service signal and the method using the same | |
| US8547962B2 (en) | Methods and apparatus for forwarding IP calls through a proxy interface | |
| US8000233B2 (en) | Method and apparatus for real-time application-driven resource management in next generation networks | |
| US8068469B2 (en) | Surrogate registration in internet protocol multimedia subsystem for users indirectly coupled via an end point | |
| US8108526B2 (en) | Communication method and device for preventing media stream circuitry | |
| US20050259679A1 (en) | Radio link loss management in multimedia domain (MMD) | |
| US20110194554A1 (en) | Systems and methods for implementing call pick up using gruu an ims network | |
| US8625581B2 (en) | Methods and apparatus for enhancing the scalability of IMS in VoIP service deployment | |
| US7571238B1 (en) | Authorizing communication services | |
| KR20090074932A (ko) | 무선 네트워크와 유선 네트워크의 연동을 위한 장치 및방법 | |
| EP2200226B1 (en) | Method, system and device for bearer resource reservation | |
| US10313400B2 (en) | Method of selecting a network resource | |
| WO2010075721A1 (zh) | 一种基于签约数据的ims用户级控制方法及系统 | |
| KR101064758B1 (ko) | 서비스 품질을 보장하는 음성 패킷망 서비스 제공을 위한 호 연결 방법 및 장치 | |
| CN101222454B (zh) | 一种拒绝非法业务流的方法 | |
| WO2007085199A1 (fr) | Procédé, application et appareil permettant d'identifier l'état utilisateur dans des réseaux | |
| JP5112491B2 (ja) | Ｉｐ基盤の有線無線統合ネットワークのための統合信号処理装置およびその方法 | |
| Giordano et al. | Managing multimedia traffic in IP integrated over differentiated services: SIP dynamic signalling inter-working | |
| Kiani et al. | A Proposed Model For QoS guarantee In IMS-based Video Conference services | |
| KR20070076556A (ko) | 인터넷 멀티미디어 서브시스템기반의 차세대 네트워크에서인터넷 프로토콜 옵션 헤더를 이용한 자원예약 기법 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A711 | Notification of change in applicant |
Free format text: JAPANESE INTERMEDIATE CODE: A712 Effective date: 20100119 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20100406 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20100603 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20101109 |
|
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20101202 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20131210 Year of fee payment: 3 |
|
| LAPS | Cancellation because of no payment of annual fees |