[go: up one dir, main page]

JP2005527133A - マルチストリーム及びマルチメディアアプリケーションのためのＱｏＳサポートを目的としたエンドツーエンド交渉プロトコルの様々なフェーズを実行するモデル - Google Patents

マルチストリーム及びマルチメディアアプリケーションのためのＱｏＳサポートを目的としたエンドツーエンド交渉プロトコルの様々なフェーズを実行するモデル Download PDF

Info

Publication number
JP2005527133A
JP2005527133A JP2003563172A JP2003563172A JP2005527133A JP 2005527133 A JP2005527133 A JP 2005527133A JP 2003563172 A JP2003563172 A JP 2003563172A JP 2003563172 A JP2003563172 A JP 2003563172A JP 2005527133 A JP2005527133 A JP 2005527133A
Authority
JP
Japan
Prior art keywords
qos
e2enp
negotiation
session
concept
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.)
Granted
Application number
JP2003563172A
Other languages
English (en)
Other versions
JP4342948B2 (ja
Inventor
マンダトー、ダフィテ
カッスラー、アンドレアス
グエンコバールイ、テオドラ
Original Assignee
ソニー インターナショナル （ヨーロッパ） ゲゼルシャフト ミット ベシュレンクテル ハフツング
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by ソニー インターナショナル （ヨーロッパ） ゲゼルシャフト ミット ベシュレンクテル ハフツング filed Critical ソニー インターナショナル （ヨーロッパ） ゲゼルシャフト ミット ベシュレンクテル ハフツング
Publication of JP2005527133A publication Critical patent/JP2005527133A/ja
Application granted granted Critical
Publication of JP4342948B2 publication Critical patent/JP4342948B2/ja
Anticipated expiration legal-status Critical
Expired - Fee Related legal-status Critical Current

Links

Images

Classifications

    • 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
    • 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/18—End to end
    • 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/20—Traffic policing
    • 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/24—Traffic characterised by specific attributes, e.g. priority or QoS
    • H04L47/2416—Real-time 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/72—Admission control; Resource allocation using reservation actions during connection setup
    • H04L47/724—Admission control; Resource allocation using reservation actions during connection setup at intermediate nodes, e.g. resource reservation protocol [RSVP]
    • 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/76—Admission control; Resource allocation using dynamic resource allocation, e.g. in-call renegotiation requested by the user or requested by the network in response to changing network conditions
    • H04L47/762—Admission control; Resource allocation using dynamic resource allocation, e.g. in-call renegotiation requested by the user or requested by the network in response to changing network conditions triggered by the network
    • 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/76—Admission control; Resource allocation using dynamic resource allocation, e.g. in-call renegotiation requested by the user or requested by the network in response to changing network conditions
    • H04L47/765—Admission control; Resource allocation using dynamic resource allocation, e.g. in-call renegotiation requested by the user or requested by the network in response to changing network conditions triggered by the end-points
    • 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/76—Admission control; Resource allocation using dynamic resource allocation, e.g. in-call renegotiation requested by the user or requested by the network in response to changing network conditions
    • H04L47/765—Admission control; Resource allocation using dynamic resource allocation, e.g. in-call renegotiation requested by the user or requested by the network in response to changing network conditions triggered by the end-points
    • H04L47/767—Admission control; Resource allocation using dynamic resource allocation, e.g. in-call renegotiation requested by the user or requested by the network in response to changing network conditions triggered by the end-points after changing the attachment point, e.g. after hand-off
    • 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/801—Real time 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
    • 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/80—Actions related to the user profile or the type of traffic
    • H04L47/808—User-type 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/822—Collecting or measuring resource availability data
    • 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/1066—Session management
    • H04L65/1069—Session establishment or de-establishment
    • 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/1066—Session management
    • H04L65/1101—Session protocols
    • 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/1066—Session management
    • H04L65/1101—Session protocols
    • H04L65/1104—Session initiation protocol [SIP]
    • 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/40—Support for services or applications
    • H04L65/403—Arrangements for multi-party communication, e.g. for conferences
    • H04L65/4038—Arrangements for multi-party communication, e.g. for conferences with floor control
    • 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/60—Network streaming of media packets
    • H04L65/61—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
    • H04L65/612—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for unicast
    • 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/60—Network streaming of media packets
    • H04L65/65—Network streaming protocols, e.g. real-time transport protocol [RTP] or real-time control protocol [RTCP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/2866—Architectures; Arrangements
    • H04L67/30—Profiles
    • H04L67/303—Terminal profiles
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/2866—Architectures; Arrangements
    • H04L67/30—Profiles
    • H04L67/306—User profiles
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/24—Negotiation of communication capabilities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/329—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the application layer [OSI layer 7]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/40—Network security protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/16—Central resource management; Negotiation of resources or communication parameters, e.g. negotiating bandwidth or QoS [Quality of Service]
    • H04W28/18—Negotiating wireless communication parameters
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W8/00—Network data management
    • H04W8/02—Processing of mobility data, e.g. registration information at HLR [Home Location Register] or VLR [Visitor Location Register]; Transfer of mobility data, e.g. between HLR, VLR or external networks
    • H04W8/04—Registration at HLR or HSS [Home Subscriber Server]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/16—Central resource management; Negotiation of resources or communication parameters, e.g. negotiating bandwidth or QoS [Quality of Service]
    • H04W28/24—Negotiating SLA [Service Level Agreement]; Negotiating QoS [Quality of Service]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W36/00—Hand-off or reselection arrangements
    • H04W36/08—Reselecting an access point
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W36/00—Hand-off or reselection arrangements
    • H04W36/14—Reselecting a network or an air interface
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W56/00—Synchronisation arrangements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W76/00—Connection management
    • H04W76/10—Connection setup
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W80/00—Wireless network protocols or protocol adaptations to wireless operation

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Multimedia (AREA)
  • Computer Security & Cryptography (AREA)
  • Business, Economics & Management (AREA)
  • General Business, Economics & Management (AREA)
  • Quality & Reliability (AREA)
  • Databases & Information Systems (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
  • Communication Control (AREA)

Abstract

マルチストリーム及びマルチメディアアプリケーションのＱｏＳサポートを目的とした、エンドツーエンド交渉プロトコルの様々なフェーズを実行するモデル
基本的な本発明は、概して、マルチメディアアプリケーション及び技術を配布した、ネットワーク環境におけるモバイルコンピューティングの分野に関する。より詳細には、ＱｏＳ違反に対して効果的且つタイムリーに応答するべくモバイルユーザのアプリケーションに対して使用可能にすることにより、２つ又は多数のエンドピア及び中間コンポーネントを、整合的な、信頼性が高い且つ追加的な方法で多重構築するために、エンドツーエンド品質及び電気通信セッション（１０２）の能力の前交渉（８０２、８０４、８０５）、高速交渉（８０６）、高速且つ動的再交渉を可能にする、エンドツーエンド交渉プロトコル（Ｅ２ＥＮＰ）フェーズの概念に関する。
これに関連して、本発明は、階層ＱｏＳ契約規格（１１０８）、例えば、関連するメディアストリーム（２０６）のＱｏＳ契約（１１０８）の様々なセットに亘る強い関連（８０４）を、交渉可能な情報を導出するために強制及び使用できる方法で、ユーザプロファイル及び端末能力情報を定義するモデルを提供する。この考え方の基準として、本発明は、エンドツーエンドＱｏＳ交渉プロトコル（Ｅ２ＥＮＰ、９０８）の概念を実現するために、インターネット技術標準化委員会（ＩＥＴＦ）によって規定されたセッション開始プロトコル（ＳＩＰ、９１０）と、拡張可能なマークアップ言語（ＸＭＬ）に基づくセッション記述プロトコル次世代（ＳＤＰｎｇ、９１２）仕様の拡張とを組み合わせた新規な使用方法を提案する。

Description

基本的な本発明は、概して、分散マルチメディアアプリケーション及び技術を有する無線モバイルネットワーク環境におけるモバイルコンピューティングの分野に関する。より詳細には、本発明は、動的無線インターネットプロトコル（ＩＰ）のネットワーク内で異なるアクセス技術をサポートするモバイル装置上で実行される適応リアルタイムサービスのためのサービス品質（Quality-of-Service：ＱｏＳ）管理の分野に関し、これにより、特にマルチメディアミドルウェア及びリソース予約メカニズムに関連した研究開発の結果が含まれる。これに関連して、本発明は、階層ＱｏＳ契約規格（例えば、関連するメディアストリームに対するＱｏＳ契約の様々なセットに亘る強い関連）に準拠し、交渉可能な情報の導出に使用できる方法によって、ユーザプロファイル及び端末能力情報を定義するモデルを提案する。
この考え方の基準となるものとして、本発明は、エンドツーエンドＱｏＳ交渉プロトコル（End-to-End QoS Negotiation Protocol：Ｅ２ＥＮＰ）の概念を実現するために、インターネット技術標準化委員会（Internet Engineering Task Force：ＩＥＴＦ）によって規定されたセッション開始プロトコル（Session Initiation Protocol：ＳＩＰ）を、拡張可能なマークアップ言語（Extensible Markup Language：ＸＭＬ）に基づくセッション記述プロトコル次世代（Session Description Protocol Next Generation：ＳＤＰｎｇ、９１２）の拡張とともに用いる新規な使用方法を提案する。基本的な本発明に係る提案した解決手法の概念は、特定の基準アーキテクチャに加えて、「移動可能なネットワーク上でのサービス適合、拡張性及びＱｏＳ取扱いのための概念」（ＩＳＴ−１９９９−１００５０ブレイン（BRAIN）デリバラブル１．２、２００１年３月３１日、http://www.ist-brain.org/）（以下、[BRAIN]という。）において元々開示されている提案に基づいている。これに関連して、１組の基本的な要件が導出される。これにより、この１組の要件と、この要件に関連した最適な解決手法の選択に関する説明を行う。
インターネットは、家や会社に居るユーザだけではなく、外で活動するユーザにとっても、電子サービスの幅広いセット（特に、電話通信、電子メッセージ通信、オーディオ／ビデオサービス）を配信する成功したアーキテクチャであると証明されている。実際、マイクロ及びマクロＩＰの移動性、無線ＩＰ技術は、インターネットと、第２及び第３世代の移動電話システムとを完全に統合することを可能にしている。この目的を達成するためには、次世代のＩＰネットワーク及びアプリケーションは、益々重要となる無線アクセス、移動性管理、サービス品質（ＱｏＳ）、マルチメディアサービスの難題を解決しなければならない。
この状況においてモバイルユーザが恐らく直面する最大の問題は、端末装置（end system）及びネットワーク内の限られたリソースと、不安定な環境条件とに如何に対応するかというものである。実際、モバイルユーザは、例えば無線リンクの品質低下、水平及び／又は垂直ハンドオーバ（handover）、モバイル端末の限られたリソースといった様々な理由から、ＱｏＳ契約がネットワークインフラストラクチャによってサポートされなくなってしまうという不幸なケースに、より頻繁に陥ることが予想される。以下、明細書では、これらの不幸なケースを「ＱｏＳ違反（QoS violation）」と呼ぶ。特有のリソースがバックボーンにおいて規定以上（over provision）となることがあるとすると、ＱｏＳ違反は、アクセスネットワーク内、特にその無線部分において最も発生することが予想される。
更に、複数のピアによって同時に交換されている複数の情報のメディアストリームを処理するモバイルマルチメディアアプリケーションには、特に、上述した不安定な環境条件の前では、ＱｏＳ要件を取り扱う有効且つ効果的な方法が必要である。
不安定な環境条件に対応できる方法は、障害となるもの（counteraction）を予測することによって、モバイルユーザのアプリケーションがＱｏＳ違反に対して効果的且つタイムリーに反応できるようにすることである。実際、ピアは、様々な抽象化レベルで、様々な代のＱｏＳ契約をオフラインで交渉することができ、接続確立時間及びＱｏＳ違反が発生したときには何時でも、ピア間で、突然変化した条件にどのように最も効果的に適合させるべきかの合意に達することができる。
更に、関与する全てのピアにおけるローカルリースが決定され、その予約がなされる前に、任意のネットワークリソース予約の要求を回避することによって、ピアは、前交渉したＱｏＳ契約を効果的に実行する特定の手続に従うことができる。この手続については更に「経済原理（Economy Principle）」として説明する。
上述した２つの計画メカニズムを組み合わせた総体的な解決手法を、以下、「エンドツーエンド交渉プロトコル」（Ｅ２ＥＮＰ）という。
なお、これにより、特に、能力（例えばコーデック）の交渉が、ユーザのＱｏＳ嗜好及びプロファイル情報の交渉とは別問題であり、相補的なものと見なされる。したがって、高能力且つ適合性のあるアプリケーション及び／又はミドルウェアは、[BRAIN]に記載された所定のＱｏＳ違反に対処する最高の適合戦略を選択するために、ピアによってエンドツーエンド交渉されたこのような如何なる情報も効果的に使用することができる。
現在における最新技術の簡単な説明
最新技術によれば、モバイル環境におけるＱｏＳ管理の問題に関連した様々な方法及び技術が現在利用可能であり、これらは、基本的な本発明のトピック（topic）に密接に関連している。本発明の内容理解するために、これらの技術に関係した主な特徴について簡単に説明する。
欧州特許出願第ＥＰ０１１２２３６６．６号明細書には、Ｅ２ＥＮＰプロトコルが紹介され、詳細に説明されている。この発明では、動的エンドツーエンドＱｏＳ交渉と、分散マルチメディアアプリケーションの制御調整とを達成するフレームワークが提案されている。このフレームワークは、ユーザ嗜好に基づいて、動的能力交渉と、適応経路の仕様と、（代替的）ＱｏＳ契約とを構築する。特に、ＳＩＰ、ＲＴＳＰ及び／又はＳＤＰのようなＩＰベースのプロトコルの拡張に基づいて、代のＱｏＳ、能力、嗜好及び／又は構成のエンドツーエンド交渉を、ネットワークリソース予約（例えばＲＳＶＰ）、ローカル端末リソース予約（例えばＣＰＵ、メモリ、電力、補助装置）及び適応メカニズム等のメカニズムと協働して提供するプロトコルが提案されている。２つ以上位までのピアに対して、６つのフェーズが識別されており、これらのフェーズにより、ピアは、マルチパーティ、マルチストリーム及び／又はマルチメディア通信を確立することができる。詳細には、これらのフェーズは、プロトコルディスカバリ、前交渉、マルチストリームの時間同期及びＱｏＳ関連（QoS correlation）、高速交渉（経済原理に従う）、再交渉（経済原理に従う）、リソース予約及び／又は解放である。これら６つのフェーズは、全て連結され、又は異なる時間に実行することができる。
「移動可能なネットワーク上でのサービス適合、拡張性、ＱｏＳ取扱いの概念（Concepts for Service Adaptation, Scalability and QoS Handling on Mobility-Enabled Networks）（[BRAIN]）」では、Ｅ２ＥＮＰの基本概念が示されている。
シー・パーキンス（C. Perkins）他著「冗長オーディオデータのＲＴＰペイロード（RTP Payload for Redundant Audio Data）」（ＲＦＣ ２１９８、ネットワーク分科会（Network Working Group）１９９７年９月）（以下、[RFC2198]という。）、エイチ・シュルツリン（H. Schulzrinne）他著「最少の制御によるオーディオ及びテレビ会議のＲＴＦプロファイル（RTP Profile for Audio and Video Conferences with Minimal Control）」（コロンビア大学、未完成（Columbia University, work in progress）、<draft-ieft-avt-profile-new-09.txt>）（以下、[RTP-Profile]という。）では、帯域内シグナリング（signaling）を介した迅速な交渉の可能性について説明している。しかしながら、この種のシグナリングは、コーデックの変更、及び異なってコーディングされたメディアの冗長サポートのみを考慮したものであり、ＱｏＳがサポートされる際の関連したそれぞれの影響について考慮していない。
ダブリュ・マーシャル（W. Marshall）他著「リソース管理とＳＩＰの統合−リソース管理のＳＩＰ拡張（Integration of Resource Manageent and SIP - SIP Extensions for Resource Management）」（ＩＥＴＦ ＳＩＰ分科会、未完成（IEF SIP Working Group, work in progress）、<draft-ietf-sip-manyfolks-resource-01.txt>）（以下、[SIPRES01]という。）、ダブリュ・マーシャル（W. Marshall）他著「リソース管理におけるＳＩＰ拡張（SIP Extensions for Resource Management）」（ＩＥＴＦ草案（IETF Draft）、２０００年１１月、<draft-ietf-sip-many-folks-resource-00>）（以下、[Marsh00]という。）において、著者らは、マルチフェーズの呼設定メカニズムを提案し、このメカニズムにより、ネットワークＱｏＳ及びセキュリティの確立は、セッション開始プロトコル（Session Initiation Protocol：ＳＩＰ）によって開始され、セッション記述プロトコル（Session Description Protocol：ＳＤＰ）によって記述されるセッションの必要条件となる。ネットワークリソースは、セッションが開始する前に、既存のネットワークリソース予約メカニズム（例えばＲＳＶＰ）を使用して予約される。リソース管理プロトコルは、呼シグナリングの２つのフェーズ間でインタリーブされ、参加者は、ネットワークにおいてリソースが使用可能になった後に招待される。必要条件の確認は、明示的に知らされる。リソース管理は、ネットワークリソースに対してのみ行われる。必要条件が満たされているか否かを判定するために、ＳＤＰへの拡張が導入される。しかしながら、[SIPRES01]及び[Marsh00]では、Ｑｏｓの前交渉、及びローカルとピアのリソース管理の統合については考慮されていない。
ジー・カマリロ（G. Camarillo）著「ＳＤＰの必要条件の確認（Confirmation of SDP Preconditions）」（ＩＥＴＦインターネット草案、未完成（IETF Internet-Draft, Work-in-progress）、<draft-camarillo-manyfolks-com-firm-02.txt>）（以下、[Cama00]という。）においては、どのパーティが必要条件の確認を送るかを示す追加的な方向属性が導入されている。最終的に、[Cama00]は、ＳＤＰの必要条件を使用する際に、ＳＩＰにおいて第三者呼制御（third party call control）を実行するメカニズムを提供している。しかしながら、[Cama00]は、ＱｏＳの前交渉と、ローカル及びピアのリソース管理の統合を考慮していない。
ジー・クライン（G. Klyne）著「メディア特徴セットを記述する構文（A Syntax for Describing Media Feature Sets）」（ＲＦＣ２５３３、５ＧＭ／コンテンツ技術（RFC 2533, 5GM/Content Technologies）、１９９９年３月）（以下、[RFC2533]という。）において、その著者らは、メディア処理能力を表すメディア特徴セットを表現するフォーマットを提案している。更に、特徴セットに適合するアルゴリズムも提案されている。このアルゴリズムは、送信側（sender）と受信側（receiver）の能力が互換性を有するか否かを判定するためにも使用することができる。このマッチングアルゴリズムは、ジー・クライン（G. Klyne）編「改訂メディア特徴セットマッチングアルゴリズム（A revided media feature set matching algorithm）」（ＩＥＴＦメディア特徴登録分科会、未完成（IETF media feature registration WG, Work-in-progress）、＜draft-klyne-conneg-feature-match-02.txt＞）（以下、[Conneg00]という。）において改善されている。更に、ジー・クライン（G. Klyne）編「複合メディアの特徴の識別（Identifying composite media features）」（ＩＥＴＦｃｏｎｎｅｇ分科会、未完成（IETF conneg working group, Work-in-progress）、＜draft-ietf-conneg-feature-hash-05.txt＞）（以下、[Conneg00a]という。）では、特徴表現のハッシュを用いて複合メディア特徴セットを記述する複合メディア特徴セットのための省略フォーマットが提案されている。これは、間接参照を行う如何なる特定のメカニズムからも独立して、任意の特徴セット表現を参照する省略された形式を提供するために使用できる。[RFC2533]は、[Conneg00]、[Conneg00a]、又は、エフ・アンドリーセン（F. Andreasen）著「ＳＤＰ単純能力交渉要件（SDP Simple Capability Negotiation Requirements）」（ＩＥＴＦのＭＭＵＳＩＣ分科会、未完成（IETF MMUSIC working group, Work-in-progress）、＜draft-andreasen-mmusic-sdp-simcap-00.txt＞）（以下、[SDPCN01]という。）と共に、既存のインターネットプロトコルと統合せず、前交渉した代のＱｏＳ契約の概念を含まず、ローカル、ネットワーク及びピアのリソース予約メカニズムと統合しない。
エフ・アンドリーセン（F. Andreasen）著「ＳＤＰ単純能力交渉（SDP Simple Capability Negotiation）」（ＩＥＴＦのＭＭＵＳＩＣ分科会、未完成（IETF MMUSIC working group, Work-in-progress）、＜draft-andreasen-mmusic-sdp-simcap-00.txt＞）（以下、[SDPCN00]という。）において、その著者らは、能力セット（capability set）を容易に参照できるようにするために、能力セットがハンドル（上述したハッシュに類似する）を含む必要があるとの要件について記述している。
ジー・クライン（G. Klyne）著「プロトコル独立コンテンツ交渉フレームワーク（Protocol-independent Content Negotiation Framework）」（ＲＦＣ２７０３、５ＧＭ／コンテンツ技術（5GM/Content Technologies）、１９９９年９月）（以下、[RFC2703]という。）において、その著者らは、インタラクトするリソースに対する、プロトコルから独立したコンテンツ交渉のための抽象化されたフレームワークを提案している。しかしながら、このフレームワークは、コンテンツ交渉処理を提供するものではない。このフレームワークは、送信側の能力と、伝送すべきデータリソースと、受信機の能力と、これらの能力を交換するプロトコルとに対する要求を識別する。交渉は、一連の交渉メタデータの交換によって実行される。伝送される特定のデータファイルが見つかると直ちに、交渉は中止される。送信側がそのファイルを決定した場合、送信側はデータを転送し、それ以外の場合は、受信側は送信側に知らせる。この提案しているフレームワークは、構成ＱｏＳ契約及び能力の前交渉の取扱いではなく、コンテンツ交渉に関する。[RFC2703]に提案された解決手法は、ネットワークのリソース予約だけではなく、ローカルのリソース予約、ピアのリソース予約とも統合しない。
ジェイ・ローゼンバーグ（J. Rosenberg）、エイチ・シュルツリン（H. Schulzrinne）著「ＳＤＰによる申込／応答モデル（An Offer/Answer Model with SDP）」（ＩＥＴＦインターネット草案、未完成（IETF Internet-Draft, Work-in-progress）、<draft-rosenberg-mmusic-sdp-offer-answer-00.txt>）（以下、[SDPOA00]という。）において、ＳＤＰによる１対１能力交渉のための完全なモデルが説明されている。しかしながら、このモデルには、ＳＤＰの平坦な階層構造に起因した、相互に参照し合う情報と、グループ化メディアストリーム（grouping media stream）上の情報との定義における問題がある。更に、このモデルは、能力交渉のみを考慮し、ＱｏＳサポートを考慮していない。
ディー・クッチャー（D. Kutscher）他著「セッション記述及び能力交渉のための要件（Requirements for Session Description and Capability Negotiation）」（ＩＥＴＦインターネット草案、未完成（IETF Internet-Draft, Work-in-progress）、＜draft-kutscher--mmusic-sdpng-req-01.txt＞）（以下、[SDPNG01]という。）は、マルチパーティによるマルチメディア会議シナリオにおけるセッション記述及びエンドポイント能力を取り扱うフレームワークの要件を開示している。したがって、上記文書は、マルチパーティマルチメディア会議シナリオにおけるセッション記述及びエンドポイント能力交渉のためのフレームワークに関連した要件のセットを提供する。ユーザ嗜好、システム能力又は他の制約に基づいて、会議に様々な構成を選択することができる。可能な構成の共通のセットを決定し、情報交換のためにこれらの共通の構成の１つを選択するために、ピア間の交渉処理の要件が確認されるが、記載はされていない。この能力交渉を用いて、潜在的な参加者の端末装置の能力に互換性を有する有効なセッション記述及びユーザの嗜好が得られる。異なる種類の会議に対応して、異なる交渉ポリシ（policy）を用いることができる。また、セッション設定に関連するネットワークリソース予約に関する要件も開示されている。最後に、能力を記述し、交渉言語を提供する手法が提案されているが、プロトコルについては説明されていない。しかしながら、[SDPNG01]で提案されている解決手法は、ＱｏＳ構成の共通のセットを決定する交渉プロトコルを考慮しておらず、更に、ローカル、ピア及びネットワークのリソース予約の統合も行われていない。これに加えて、ハンドルによって構成を参照する処理を統合しておらず、また、ＱｏＳ契約概念に基づいてもいない。更に、上記解決手法は、端末能力及びネットワークリソース予約メカニズムを考慮しておらず、コーデック交渉のみを取り扱うものである。
ＩＥＴＦ草案の最新版の、ディー・クッチャー（D. Kutscher）他著「セッション記述及び能力交渉（Session Description and Capability Negotiation）」（ＩＥＴＦインターネット草案、未完成、（IETF Internet Draft, work in progress）、<draft-ietf-mmusic-sdpng-03.txt>）（以下、[SDPNG03]という。）では、詳細なＸＭＬスキーマ仕様と、オーディオコーデック及びＲＴＦプロファイルのプロトタイプとを提供している。ＩＥＴＦ提案のこのような最新の、より完全なバージョンと比較して、Ｅ２ＥＮＰは、以下の特徴を有する（その提案の拡張として）。
−Ｅ２ＥＮＰフェーズの概念
−様々なＥ２ＥＮＰフェーズに関連したＰＤＵのフォーマットに基づく、新たなＳＤＰｎｇセクション及びその様々な構成
−<conf>セクションにおける<owner>エレメントの代わりに（残りはするが、その目的は異なる）、新たな<puopose>セクションにおける明確な<session>エレメントの使用
−Ｅ２ＥＮＰ ＰＤＵのサイズを制限するために、<session>から（例えばハッシュにより）導出したセッション識別子の交渉及び使用、この場合、<session>は（算出したハッシュと共に）、如何なる所定のＥ２ＥＮＰフェーズ又はそれらの連結の第１のＰＤＵ内で使用される
−交渉した情報のリース
−交渉した情報の連結
−元の<def>は、現在、新たな<gosdef>セクションによって代わられる
−<cfg>セクションにおける任意の種類のネットワーク及び／又はプロトコルバージョンのサポート
−オーディオコーデック及びＲＴＰプロファイルに対する拡張
−所定の端末装置の局所的な実行（enforcement）のために、又はこれを第三者コンポーネント（例えば会議ブリッジ）に委託する（delegating）ために、任意の抽象化レベルのＱｏＳ関連及び時間同期の制約をモデリングする可能性
−第三者支援交渉シナリオの取扱い
−ビデオコーデック情報の取扱い
２つの文書、ディー・ヨン（D. Yon）著「ＳＤＰにおける接続指向のメディアトランスポート（Connection-Oriented Media Transport in SDP）」（ＩＥＴＦ ＭＭＵＳＩＣ分科会、未完成（IETF MMUSIC Workign Group, work in progress）、<draft-ietf-mmusic-sdp-comedia-01.txt>）（以下、[SDPCO01]という。）、及び[SDPNG03]は、接続モードに関して、どの通信パーティが送信側（sender）、受信側（receiver）又は送信側／受信側（sender-receiver）であるかの定義の必要性を記載している。更に、[SDPCO01]は、同一のコンテンツを有し、異なって符号化されたメディアを送信又は受信するために、単一のポートを使用できることを示す必要性を記載している。ＳＤＰによるそれぞれの定義は、プロトコルの平坦な構造のために問題が多いが、その一方で、[SDPNG03]に記載されているＸＭＬスキーマによるＳＤＰｎｇは、それぞれの記述の相互参照を行うことができる。ＱｏＳ交渉の必要性に対して、送信側及び／又は受信側のパーティの識別が、最も適切な交渉モード（プッシュ、プル、又は、プッシュ／プル）を選択することによって、交渉の高速化に役立つことができる。
[SDPCN00]の著者は、最少及び下位互換能力の交渉メカニズムを提供するＳＤＰ拡張のセットを提案している。[SDPCN00]は、能力交渉のためのＳＤＰ拡張を追加しているだけである。
ビー・ベザー（B. Beser）著「ＳＤＰのコーデック能力属性（Codec Capabilities Attribute for SDP）」（ＩＥＴＦインターネット草案、未完成（IETF Internet-Draft, Work-in-progress）、＜draft-beser-mmusic-capabilities-00.txt＞）（以下、[Beser00]という。）の著者は、エンドポイントがコーデックの選択肢を知り、共通のセットに同意できるようにＳＤＰを拡張している。これにより、通信相手は、発信者（originator）の能力及び嗜好に関する情報を得ることができる。しかしながら、[Beser00]に提案されている解決手法は、エンドポイントがコーデックの交渉に必要なＳＤＰ拡張を提供するだけである。
ジェイ・オット（J. Ott）他著「グループ協働のための能力記述（Capability description for group cooperation）」（ＩＥＴＦインターネット草案、未完成（IETF Internet-Draft, Work-in-progress）、＜draft-ott-mmusic-cap-00.txt＞）（以下、[Ott99]という。）においては、マルチパーティ共同セッションにおける端末装置の可能な且つ特定の構成を記述する表記法が提案されている。これにより、システム能力を定義し、共通の能力のセットを算出し、セッション記述において用いられる選択されたメディア記述を表現するメカニズムが実現される。この文献には、能力交換のためのプロトコルは示されていない。しかしながら、[Ott99]に提案されている解決手法は、構成記述のための表記法を提供するだけである。
シー・ボーマン（C. Bormann）他著「単純な会議制御プロトコル（Simple Conference Control Protocol）」（ＩＥＴＦインターネット草案、未完成（IETF Internet-Draft, Work-in-progress）、＜draft-ietf-mmusic-sccp-01.txt＞）（以下、[Bor00]という。）の著者らは、密結合会議（tightly coupled conferences）のための単純な会議制御プロトコル（simple conference control protocol：ＳＣＣＰ）のサービスを定義している。ここでは、分散アプリケーションリソースに関するメンバー管理、アプリケーション／セッション管理及びアクセス制御規則が定義されている。例えばＳＩＰを用いて確立することもできる会議の状態は、ＳＣＣＰを用いて、その継続期間の間管理される。この処理は、適切な構成、構成に関する交渉及び構成の変更の検出を含む。しかしながら、ここでは、ローカル及びネットワークのリソース管理との対話は行われない。更に、ＳＣＣＰは、ＱｏＳ契約の取扱いと、その構成の前交渉の方法を網羅していない。
ケー・ナーステッド（K. Nahrstedt）、ジェイ・スミス（J. M. Smith）著「ＱｏＳブローカ（The QoS Broker）」（ＩＥＥＥマルチメディアマガジン（IEEE Multimedia Magazine）、１９９５年春（２）１、５３〜６７頁）（以下、[Nahr95]という。）において、その著者らは、エンドポイントにおけるリソースを組織化し、複数の層に亘るリソース管理を調整する機能エンティティであるＱｏＳブローカに基づくエンドポイントアーキテクチャのためのモデルを提案している。システムを適切に構成するために、ＱｏＳブローカは、許可制御（admission control）及び交渉を用いる。ピアエンティティ間の交渉により、通信システムの必要な全てのコンポーネントを含む有効な構成がえられる。しかしながら、[Nahr95]に記述されたモデルは、既存のインターネットプロトコルと統合せず、更に、電池電力や無線サブネットワークの利用可能性といった他のリソースを考慮していない。
オー・レビン（O. Levin）著「マルチメディア及びビデオのサポートのためのＳＩＰ要件（SIP Requirements for support of Multimedia and Video）」（ＩＥＴＦインターネット草案、未完成（IETF Internet-Draft, Work-in-progress）、＜draft-levin-sip-for-video-00.txt＞）（以下、[Levin01]という。）には、ＩＰ上におけるリアルタイムマルチメディアサポートの呼制御プロトコルのための要件のセットが提案されている。ここでは、能力を表現する必要があり、必要なリソースの量を指定するために能力を知らせる必要があり、能力及び確保されたリソースに基づく範囲内で、メディアストリームを開き／閉じ／変更するために、呼制御メカニズムが必要である。また、この著者らは、セッション中に、（使用可能であれば）新たな能力を告知することを提案している。更に、ピアは、使用されるコーデックの共通のセットに同意する必要がある。ストリームを開始／終了するセッション制御メカニズムは、必要条件として位置づけられる。
しかしながら、[Levin01]は、ローカル、リモート及びネットワークのリソース管理を整合的なフレームワークに統合することは、考慮しておらず、むしろ、[Levin01]は、要件を提供するだけである。この要件を実現するプロトコル及びメカニズムも提案されていない。
次の文書において、ローカル、ピア及びネットワークのリソース予約を、エンドツーエンドＱｏＳ管理のためのフレームワーク内に統合する端末装置のアーキテクチャが提案されており、このアーキテクチャでは、ＱｏＳをアプリケーションレベルで交渉するために、ユーザ嗜好及び適応経路をＱｏＳ状態と共に使用している。ローカルリソース管理による相互作用が導入されている。階層アーキテクチャによって、異なる種類のアプリケーションがサポートされている。
−「移動可能なネットワーク上でのサービス適合、拡張性、ＱｏＳ取扱いのための概念（Concepts for Service Adaptation, Scalability and QoS Handling on Mobility-Enabled Networks）」[BRAIN]
−ティ・ロブレス（T. Robles）、エイ・カデルカ（A. Kadelk）、エイチ・ベライオス（H. Velayos）、エイ・ラペトライネン（A. Lappetelainen）、エイ・カスラー（A. Kassler）、エイチ・リー（H. Li）、ディー・マンダト（D. Mandato）、ジェイ・オジェラ（J. Ojala）、ビー・ウェグマン（B. Wegmann）著「３Ｇを越える全てのＩＰシステムのためのＱｏＳサポート（Qos Support for an All-IP System Beyond 3G）」（ＩＥＥＥ通信マガジン、２００１年８月、Ｖｏｌ．３９、Ｎｏ．８）（以下、[Roble01]という。）
−エー・カスラー（A. Kassler）他著「ＢＲＥＮＴＡ−適応可能なマルチメディア通信のための移動性及びサービス品質のサポート（BRENTA-Supporting Mobility and Quality of Service for Adaptable Multimedia Communication）」（ＩＳＴ移動通信サミット２０００会議（Proceedings of the IST Mobile Communications Summit 2000）、アイルランド、ゲールウェイ（Galway）、２０００年１０月、４０３〜４０８頁）（以下、[Kassl00]という。）
−エー・カスラー（A. Kassler）他著「ＱｏＳサポートによる適応可能なマルチメディアサービスのためのオープンエンドシステムアーキテクチャ（An Open Endsystem Architecture for Adaptable Multimedia Services with QoS Support）」（ＢＲＡＩＮワークシップ会議（Proceedings of the BRAIN workshop）、ロンドン、２０００年）（以下、[Kassl00a]という。）
以下の３つの文書は、メディアストリームのグループ化の可能性について説明しているが、グループ化の基準と、再帰的なグループ（多数のグループのグループ）の構築の可能性と、同じくグループ化が可能なリアルタイム、擬似リアルタイム及び非リアルタイムの情報メディアストリームの取扱いとについては考慮していない。
−ディ・マンダト（D. Mandato）、エー・カスラー（A. Kassler）、ティ・ロブレス（T. Robles）、ジー・ヌレイター（G. Neureiter）著「移動可能なネットワーク上でのサービス適合、拡張性、ＱｏＳ取扱いのための概念（Concepts for Service Adaptation, Scalability and QoS Handling on Mobility-Enabled Networks）」（ＩＳＴグローバルサミット２００１（IST Global Summit 2001）、バルセロナ、２００１年９月、２８５〜２９３頁）（以下、[Manda00]という。）
−ディ・マンダト（D. Mandato）、エー・カスラー（A. Kassler）、ティ・ロブレス（T. Robles）、ジー・ヌレイター（G. Neureiter）著「移動混在ネットワーク環境におけるエンドツーエンドＱｏＳの取扱い（Handling End-to-End QoS in Mobile Heterogeneous Networking Environments）」（ＰＩＭＲＣ２００１、サンディエゴ、２００１年９月３０日〜２００１年１０月３日、Ｃ−４９〜Ｃ−５４頁）（以下、[Manda00a]という。）
−ジー・カマリロ（G. Camarillo）他著「ＳＤＰにおけるメディアラインのグループ化（Grouping of Media Lines in SDP）」（ＩＥＴＦインターネット草案、未完成（IETF Internet Draft, work in progress）、<draft-ietf-mmusic-fid-04.txt>）（以下、[Cama01]という。）
また、[Manda00]及び[Manda00a]は、１回で実行できる又は実行できない交渉ステップを定義しているが、独立したフェーズは定義しておらず、また、交渉フェーズ中及び交渉フェーズ後に、交渉したＱｏＳ情報の整合性を要求していない。それに関して、[Manda00]では、Ｅ２ＥＮＰの中心的な概念が開示されている。矛盾した「経済原理」アプリケーションの取扱いについても考慮されていない。更に、[Manda00]、[Manda00a]は、第三者コンポーネント（ＱｏＳブローカ）によって制御される、ＱｏＳ適合のための適応経路の設定と管理の可能性についても記述している。エンドパーティが、単独で交渉を実行し、制御する可能性については考慮されていない。
エル・ボス（L. Bos）他著「エンドツーエンドユーザが感知するサービス品質交渉のためのフレームワーク（A Framework for End-to-End user Perceived Quality of Service negotiation）」（ＩＥＴＦインターネット草案、未完成（IETF Internet Draft, work in progress）、<draft-bos-mmusic-sdpqos-framework-00.txt>）（以下、[Bos01]という。）では、幾つかの中間コンポーネントとサービスが、エンドピアの交渉したＱｏＳ情報に関するエンド決定に大きく関与しているという仮定により、エンドツーエンドユーザが感知する（perceived）ＱｏＳ交渉について記載している。この決定は、幾つかの標準的な「契約タイプ」に対して実施できると記載されている。シグナリング経路とデータ経路はネットワーク上で異なっていてもよいことが述べられており、一般的にデータ経路とは無関係であるが、交渉経路の途中に設けた幾つか中間コンポーネントは、交渉に影響を及ぶ可能性があると指摘されている。このプロトコルモデルのために、ネットワークはトランスペアレントではなくなる。[Bos01]に基づいた交渉処理が、１回のインタリーブで、更に何らかの非ＱｏＳ情報（例えばセキュリティ、ネットワーク許可等）と共に実施され、ＱｏＳに関するプロトコルのモジュラ性（modularity）及び情報の整合性は考慮されていない。[Bos01]のモデルでは、交渉にプッシュモードしか使用できず、アプリケーション及びサービスによっては制限されてしまう可能性がある。経路の適応化は下がり（「非適応経路（Degradation Path）」）、固定されるだけである（合意されたＱｏＳ契約間での異なるトランジションを実施する可能性はない。）。[Bos01]では、グループやメディアストリームハイアラーキ等のメディアストリームの依存性を全く考慮せずに、メディアストリームレベルのみでのＱｏＳの交渉が提案されている。
エー・バーグステン（A. Bergsten）、ケー・ネメス（K. Nemeth）、アイ・セレニー（I. Scelenyi）、ジー・フェアー（G. Feher）「エンドツーエンドＱｏＳに関する基本的な問題（Fundamental Questions Regarding End-to-End QoS）」（未完成（work in progress）、<draft-bergsten-e2eqos-questions-00.txt>）（以下、[Berg01]という。）では、重要な質問のリスト（実際には、実際の要件）が提案されている。より具体的には、「１）ＱｏＳ関連情報の交換、２）ＱｏＳ関連の決定の実行」が、「予想可能なエンドツーエンドＱｏＳを提供するために要求される拡張」として記載されている。以下の通りである限り、Ｅ２ＥＮＰはこれら両方の要件を満たす。
−第１の要件を取り扱うアプリケーションレベルのプロトコルを定義する。
−経済原理に基づいてリソース管理を実行する。
より詳細には、第２の要件に対して、Ｅ２ＥＮＰは、[BRAIN]及び[Roble01]に記載されている拡張ソケットインタフェース（Extended Socket Interface：ＥＳＩ）が存在すると見なして、ネットワークリソース管理の詳細をアプリケーションに隠している。これは、ＥＳＩが、ＱｏＳアウェアミドルウェア及びアプリケーションを構築することができる抽象化レベルを提供することを意味している。しかしながら、ＥＳＩが利用不可能な場合には、Ｅ２ＥＮＰは、アプリケーション及び／又はミドルウェアが、アプリケーション及び／又はミドルウェアのＱｏＳ適応メカニズムを起動する低レベルの監視された情報を用いると同様に、高レベルのＱｏＳ契約からネットワークレベルのＱｏＳ契約を導出できると見なしている。
より詳細には、[Berg01]において、以下の５つのポイントが述べられている。
１．「アクロスネットワーク：輻輳の可能性は、アクセスネットワークにおいて最も高く、したがって、ここでは、ＱｏＳ情報をサポートする何らかのメカニズムが必要とされる」。これは、[BRAIN]及び[Roble01]（Ｅ２ＥＮＰの元の概念はこれらに由来している）でなされている仮定であり、ＥＳＩ抽象化により、アプリケーション及び／又はミドルウェア（Ｅ２ＥＮＰに影響を及ぼす）は、利用可能なあらゆる種類のネットワークアーキテクチャを使用できるだけでなく、（より詳細には）アクセスネットワークに関する類似した仮定を行うことができる。
２．「アプリケーション間のエンドツーエンドシグナリング：幾つかのケースにおいて、高レベルの情報交換は、第１のＱｏＳセッションの開始で実行しなければならないと見なされる」。これは、正確に、Ｅ２ＥＮＰが目標とする要件のうちの１つである。更に、Ｅ２ＥＮＰは、他のＱｏＳ契約及びより高レベルのＱｏＳ契約の先を見越した（proactive）前交渉を取り扱う。更に、Ｅ２ＥＮＰは、それに加えて、再交渉を取り扱うための手順の本格的な（full-blown）セットを提供する。
３．「特にピアリングリンク上でのドメイン間通信：ＱｏＳ拡張によってではなく、ＢＧＰのような自動サービス通知（announcement）が必要である。これに加え、これらのリソースのドメイン間の条件（provisioning）を提供するメカニズムを設けることが考えられる」。Ｅ２ＥＮＰは、ピアのみ（及び、最終的には会議ブリッジ又はトランスコーダ等の幾つかの中間コンポーネント）が直接関与する純粋なエンドツーエンドアプリケーションレベルのプロトコルである。ＥＳＩ又は同等の抽象化により、ドメイン内及び／又はドメイン間のネットワークリソース管理及びルーティングを取り扱うより低レベルの機能は、Ｅ２ＥＮＰに隠される。このことは、Ｅ２ＥＮＰが、ピアが如何なるネットワークアーキテクチャ上での通信に使用できるアプリケーションレベルのプロトコルであることを意味する。
４．「ネットワークが輻輳した場合に、どの顧客にペナルティを課すかを確認する：サーバの輻輳が起こり、契約を破棄しなければならない場合、ペナルティは、ネットワークの制御下に行う必要がある」。Ｅ２ＥＮＰは、ＱｏＳ違反の検出が基本的なネットワークアーキテクチャにより実行されると仮定するので、Ｅ２ＥＮＰは、この要件に適合する。
５．「顧客の要求情報の提供：顧客は、現在及び予定されるネットワーク利用を、例えば予想される宛先及びトラフィック量を指定して、サービスプロバイダに知らせることができる。そして、オペレータは、この知識を用いてそのネットワークをより十分な大きさとし、また、隣接したオペレータから購入するサービス量を計算することができる」。これは、[Brain]及び[Roble01]でなされた前提条件と全く同じであり、Ｅ２ＥＮＰの元の概念は、これに由来している。より詳細には、ユーザは、（以下に説明する処理中に）、ネットワークプロバイダと前交渉したアプリケーションレベルのＱｏＳ契約に関して「例えば予想される宛先及びトラフィック量を指定して、現在及び予定されるネットワーク利用」を提供するだけでなく、メディアストリーム間の関係（同様にＡＰとの関係）を考慮するために、ピアとの他のＱｏＳ契約（ＡＰ）のセットを、様々な抽象化レベルで交換することができる。
最後に、[Berg01]には、あらゆるセッションの確立の前に、ピアが、サービス品質の種類及び価格情報について、そのネットワークプロバイダと合意する必要性について記載されている。これは、上述した処理と類似しており、ユーザは、アプリケーションレベルのＱｏＳ情報を指定し、このアプリケーションレベルのＱｏＳ情報は、ネットワークプロバイダとの前合意に対して、又は後のネットワークプロバイダとの直接通信によって確認されるネットワークレベルＱｏＳ契約に最終的にマッピングされる。Ｅ２ＥＮＰの範囲内でこれらの低レベルの処理がどのように達成されるかは、ＥＳＩ抽象化（又は、類似の機能）による。
次の３つの文書は、１対多接続、多対多接続等のシナリオを考慮したマルチパーティ会議のためのモデルを紹介している。
−エイチ・カータビル（H. Khartabil）著「ＳＩＰを使用した会議（Conferencing Using SIP）」（ＩＥＴＦインターネット草案、未完成（IETF Internet Draft, work in progress）、<draft-khartabil-sip-conferencing-00.txt>）（以下、[Khart01]という。）
−ジェイ・ローゼンバーグ（J. Rosenberg）、エイチ・シュルツリン（H. Schulzrinne）著「ＳＩＰにおけるマルチパーティ会議のためのモデル（Models for Multi-party Conferencing in SIP）」（ＩＥＴＦ ＳＩＰＰＩＮＧ分科会、未完成（IETF SIPPING Working Group, work in progress）、<draft-rosenberg-sip-conferencing-models-01.txt>）（以下、[Rosen01]という。）
−ジェイ・ローゼンバーグ（J. Rosenberg）、エイチ・シュルツリン（H. Schulzrinne）著、「ＳＩＰにおけるマルチパーティ会議のためのモデル（Models for Multi-party Conferencing in SIP）」（ＩＥＴＦ ＳＩＰＰＩＮＧ分科会、未完成（IETF SIPPING Working Group, work in progress）、<draft-ietf-sipping-conferencing-models-00.txt>）（以下、[Rosen00a]という。）
記述されているモデルは、会議サーバを用いた重心アーキテクチャを利用する。この場合、エンドピア間に直接的なエンドツーエンド通信は存在せず、また、Ｅ２ＥＮＰのアプリケーションは、次に示す幾つかの異なる方法で実行することができる。
−エンドピア間の直接シグナリング、会議サーバ上のデータ経路
−会議サーバを介したエンドピア間の間接シグナリング、エンドピア間の直接データ接続
−会議サーバと、データ経路を介したエンドピア間の直接シグナリング
このようなＥ２ＥＮＰアプリケーションは、異なるシナリオ毎に、異なるメッセージシーケンスと、Ｅ２ＥＮＰ構造を必要とすることができる。[Khart01]、[Rosen01]、[Rosen00a]のモデルは、主に、重心コンポーネントを使用した会議シナリオによる、メッセージシーケンスの記述に関係している。必要な能力交渉及び／又はＱｏＳ交渉、更に各々の予約によって、このようなシナリオに更にＥ２ＥＮＰが適用される場合には、これらのシーケンスが変更される。何らかの重心コンポーネントを含んだシナリオにおけるＥ２ＥＮＰアプリケーションの利点は、通信モデルを１対多シナリオに縮小できることである。
以下、請求項の定義、及び、基本的な本発明の説明に必要な多数の用語について説明する。
−適応経路（Adaptation Path）：アプリケーション及び／又はミドルウェアが事前に計画した方法で適応的な戦略を実施できるように使用できる、ユーザの特定の嗜好及び要望を示すＱｏＳ契約の順序付けられたセット。一般に、最も重要なＱｏＳ契約（すなわち、システムがデフォルトにより実行しようと試みるもの）は、経路の最初に設けられている。更に、ＡＰは、システムが様々なＱｏＳ契約を、その所定のセットから実行する環境を定義する規則の仕様を含むことができる。
−アソシエーション（Association）：所定のピアに関連したメディアストリームのグループ。メディアストリームのグループ化のサブケースとして、アソシエーションが、所定のユーザの端末装置から延びている、及び／又は端末装置で終端している、及び所定のセッション内の所定のピアに接続されている全てのメディアストリームをグループ化する。したがって、アソシエーションの仕様は、ピアの識別子（例えばＵＲＬ、電話番号又はＩＰアドレスとポート番号の対）を含む。
−回答者（Answerer）：回答者は、申込者（下記参照）の提案されたマルチメディアセッション記述への応答を生成する、ＳＩＰセッションの参加者である。この応答には、申込者の提案されたセッション記述がサポートされる条件の記述が含まれる[SDPOA00]。
−アソシエーション又はグループ適応経路（Association or Groups Adaptation Paths）：適応経路としてモデリングされ、また、代のアソシエーション又はグループの構成を、そのＱｏＳコンテキスト、ステムレベルＱｏＳ契約と共に使用することによって、アプリケーション及び／又はミドルウェアが、事前に計画された方法で適応戦略を実施できる。
−能力（Capability）：端末装置のハードウェア及び／又はソフトウェアプロファイルに関連し、また、能力は、この装置の、特定のタスクを実行する、及び／又は、特定の情報タイプを取り扱う可能性を示す。１つの能力は、特定量のハードウェア及び／又はソフトウェアリソース（各々が所定の情報タイプを取り扱う）に関連付けられている。所定の単一タイプの情報に関連した能力を使用して、この情報を１つ又は多数のＱｏＳレベルを表すことができる。その一方で、所定のＱｏＳレベルを、異なる能力のセットと関連付けることも可能である（例えば、異なるコーデックが、アプリケーションで見られる同じ１つのＱｏＳレベルを生成することができる）。
−接続モード（Connection Mode）：接続モードは、ピアによって交換される実際のデータメディアストリームを参照する。この情報は、エンドユーザが直接感知できるメディア（オーディオ、ビデオ等）である。接続モードは、メディアストリームの誰が送信側パーティで、誰が受信側パーティを示す。
−データ経路（Data Path）：メディアデータ（オーティオ、ビデオ、テキスト等）が流れるネットワーク経路である。
−経済原理（Economy Principle）：経済原理は、リソース予約の順序を表す。ネットワークリソースが共用されることによって、端末リソースとしてより高価となるため、まず、全ての端末上でリソースを予約し、次に、ネットワークリソース予約に進む方がよい。
−エンドツーエンドＱｏＳ前交渉（End-to-End QoS Pre-Negotiation）：ＱｏＳプロファイルから演繹したＱｏＳ仕様の構成に関する情報を、非義務的な方法で交換するために、セッションを実際に開始する前に、セッション自体とは無関係に、エンドピアが実施できる処理である。これらの構成は適応経路を含んでいるため、エンドピアが、使用可能なＱｏＳ変更又はＱｏＳ違反に反応する方法に、効果的且つ有効な方法で、事前に合意することができる。前交渉メッセージ交換は、前交渉メッセージ交換は、エンドピアのための情報的特徴を含んでおり、また、所定のピアの組が使用できる能力及びパフォーマンスの可能性に関して、お互いに事前に通知しておくためだけにでなく、更に、幾つかの構成の再定義に合意に達するためにも使用される。この方法によれば、ピアは、任意の特定のビジネスに優先して、共通の用語を確立できるようになる。この処理の結果は早々にスコーピングされ、その有効性インターバル内において複数回使用することができる。
−エンドツーエンドＱｏＳコンパクト交渉（End-to-End QoS Compact Negotiation）：以前に適用したエンドツーエンドＱｏＳ前交渉処理の結果に基づいて（これらの結果の有効性を、この処理を実行する時間に依然として適用すると仮定した場合）、所定のセッション及びメディアストリームについて実行する所定のＱｏＳレベルに合意するために、実際の開始の前、又は開始時のいずれかに、エンドピアが実行できる処理である。前交渉した情報の唯一の参照が実際にピア間で交換されるため、この処理は、エンドツーエンドＱｏＳフル交渉の場合と比較して非常に高速である。エンドツーエンドＱｏＳコンパクト交渉処理の完了時に、エンドピアが、通信に使用するＱｏＳプロファイルに合意した。
−エンドツーエンドＱｏＳフル交渉（End-to-End QoS Full Negotiation）：元々提案されたＱｏＳ仕様の構成の幾つかを後に再定義することにより、所定のセッション及びメディアストリームについて実行する所定のＱｏＳレベルに合意するために、セッションの実際の開始前、又は開始時にエンドピアが実行できる処理である。エンドツーエンドＱｏＳコンパクト交渉処理の完了時に、エンドピアが、通信に使用するＱｏＳプロファイルに合意した。
−エンドツーエンドＱｏＳコンパクト再交渉（End-to-End QoS Compact Re-Negotiation）：以前に適用したエンドツーエンドＱｏＳ前交渉処理の結果に基づいて（これらの結果の有効性が、この処理の実行時にも依然として適用すると仮定した場合）、所定のセッションについて実行する所定のＱｏＳレベルに合意するために、ＱｏＳ変更又はＱｏＳ違反を検出した際に、エンドピアが起動できる処理である。前交渉した情報の唯一の参照が実際にピア間で交換されるため、この処理は、エンドツーエンドＱｏＳフル交渉の場合と比較して非常に高速である。エンドツーエンドＱｏＳコンパクト再交渉処理の完了時に、エンドピアが、通信に使用するＱｏＳプロファイルに合意した。
−エンドツーエンドＱｏＳフル再交渉（End-to-End QoS Full Re-Negotiation）：元々提案されたＱｏＳ仕様の構成の幾つかを再定義することによって、所定のセッション及びメディアストリームについて実行する所定のＱｏＳレベルに合意するために、ＱｏＳ変更又はＱｏＳ違反を検出した際に、エンドピアが起動できる処理である。エンドツーエンドＱｏＳフル再交渉処理の完了時に、エンドピアが、通信に使用する新たなＱｏＳプロファイルに合意した。
−フロー（Flow）：フローは、特定の時間インターバル中に、ネットワーク内の観察地点を通過するパケットの組である。特定のフローに属する全てのパケットは、共通の特性のセットを備えており、この共通の特性のセットは、パケット内に含まれるデータから導出したものであり、更に、ジェイ・クイテック（J. Quittek）他著「ＩＰフロー情報エクスポートのための要件（Requirements for IP Flow Information Export）」（<draft-ietf-ipfix-reqs-00.txt>を参照）（以下、[Quit00]という。）に記述されているように、観察地点におけるパケット処理から導出したものである。一具体例として、所定のフローのための全てのパケットは、同一の５個のタプル（プロトコルＩＤ、ソースネットワークアドレス、目的ポート番号、ソースポート番号、目的ポート番号）を備えていなければならない。単純なメディアストリーム（すなわち、多重化層を備えていない）と層が、トランスポート層のフローにマッピングされ、その場所で予約にしようされる。１つのフローは、所定のメディアストリームの１層、又は、ひとまとまりの所定の単純なメディアストリームを伝送することができる。
−メディアストリームのグループ（Group of Media Streams）：様々な基準に基づき、メディアストリームを論理的にグループ化することによって、割当を実施するために、幾つかの制約を実行することができ、例えば、トランスレーションを実行する全てのオーディオメディアストリームをグループ化する、又は、マルチユーザ端末上で所定のユーザが開いた全てのメディアストリームをグループ化する。グループは、複数の同等のバンドル間、及び所定のＱｏＳコンテキスト内で、リソース使用可能性の質を交換する際に、ＱｏＳアウェアアプリケーションが一括して扱えるメディアストリームのバンドルを再表示するために有用である。各グループは、１つのＱｏＳコンテキストに関連する。
−中間コンポーネント（Intermediate Components）：中間コンポーネントは、シグナリング上に配置された任意のネットワークコンポーネントであるか、及び／又は、エンドデバイスが少なくともネットワークレベルで使用するスルーカミングプロトコルを理解できる２つのエンドデバイス（端末）間のデータ経路である。中間コンポーネントはルータ、プロキシ、独立したサービス、ブローカの各部分であってよい。中間コンポーネントは、エンドピア間にネットワークを構築する。
−層（Layer）：メディアストリームは複数の層にコーディングすることができ、各層は、所定のベース情報（所謂「ベース層」により伝送される）に関連した詳細のレベルを順次拡張する。すなわち、層を追加することによって、ベース情報の詳細のレベルを段階的に増加できる。各層を所定のフローにマッピングすることが可能である。
−交渉モード（Negotiation Mode）：交渉モードは、データメディアストリームの管理及び制御上の情報を交換するためにピアが使用するシグナリング経路と交渉情報を参照する。交渉モードは、誰が申込者パーティで、誰が回答者パーティであるかを交渉によって示す。
−仲介者（Mediator）：仲介者は、着呼を、１つ以上の他のピアに再方向付けるためのピアの機能であり、この再方向付けは、このような機能を備えた各ピアのユーザ及び又はサービスプロバイダの幾つかのプロファイル事前設定に基づいて行われる。
−申込者（Offerer）：申込者は、申込者がマルチメディアセッションを開始することで使用を希望するマルチメディアセッション記述を生成したＳＩＰセッションの参加者である。この記述が回答者に伝送される（上述を参照）[SDPOA00]。
−ピア（Peer）：エンドユーザに関連したサービス又はエンドデバイス。
−サービス品質（Quality of Service：ＱｏＳ）：サービスパフォーマンスの総合的な効果であり、これによって、ＩＴＵ−Ｔ（前ＣＣＩＴＴ）推奨Ｅ．８００（ITU-T Recommendation E.800）からの定義に基づいたサービスユーザの満足の度合いが決まる。そのため、各サービスについて、ＱｏＳを、サービスを特徴付けるパラメータのセットで記述することができる。一具体例を示すと、テレビ会議（videoconference）サービスでは、ＱｏＳを、エンドユーザが観察した通りの全体的なエンドツーエンドＱｏＳとして定義することができ、これを、フレームレート、ビジュアル品質、遅延等のパラメータによって測定することができる。
−ＱｏＳ変更（QoS Change）：サービスユーザによって開始されたＱｏＳ契約の変更。
−ＱｏＳコンテキスト（QoS Context）：ＱｏＳコンテキストは、所定のメディアパラメータのセット全体に亘って実施されるＱｏＳパラメータの配置を識別する。ＱｏＳコンテキストは、ＱｏＳ契約概念の仕様としてモデリングされた論理エンティティである。
−ＱｏＳ契約（QoS Contract）：サービスの全てのフェーズにおいて、ＱｏＳ追跡を維持するために必要なＱｏＳ要件及び制約、更にポリシを特定する、ユーザと所定のサービスプロバイダの間の合意である。ＱｏＳ契約は、メディアストリームレベルＱｏＳ契約と、より高レベルの契約、所謂ＱｏＳコンテキストとの概念を一般化する。すなわち、ＱｏＳ契約は、階層構造に組織化することができる。
−ＱｏＳ契約タイプ（QoS Contract Type）：個々のＱｏＳ契約が、どのようにＱｏＳ属性をＱｏＳパラメータタイプの所定のセットに対して指定するかを識別することにより、あるクラスのＱｏＳ契約の構造を捕捉する。ＱｏＳ属性は、エス・フロルド（S. Frolund）、ジェイ・コイスチニエン（J. Koistinien）著「ＱＭＬ：サービス品質仕様のための言語（QML: A Language for Quality of Service Specification）」（ＨＰ−Ｌａｂ技術レポート（HP-Lab Technical Reports）、HPL-98-10,980210）（以下、[Frolu98]という。）において、ディメンションとしても知られている。各パラメータタイプは、名前と、値の範囲からなる。ＱｏＳ仕様は、単純に、１つのパラメータタイプにつき１つ割り当てられる上記範囲に亘る制約のセットとすることも可能である。
−ＱｏＳレベル（QoS Level）：サービスを特徴付けるパラメータのマルチディメンショナルＱｏＳスペースを、複数の離散サブスペースに仕切ることができる。所定のサブスペースは、ＱｏＳレベルとして示されるため、サービスユーザは他のＱｏＳレベルと区別することができる。ＱｏＳ契約は、特定のＱｏＳレベルを記述しており、また、再交渉が実行される場合に、このようなレベルを実行するために使用される。換言すれば、ユーザは、ＱｏＳレベルを、所定のサービスに特定のＱｏＳ契約を適用した結果として理解する。しかしながら、幾つかの自然な、アプリケーション指定、又はビジネス指定の、事前定義されたＱｏＳスペースのパーティションが存在する可能性があり、この場合には、ユーザは、自己のＱｏＳ契約をＱｏＳレベル（所定のパーティションに属する）に、様々な範囲で（１対１、セクション間、様々な塊等）マッピングすることができる。
−ＱｏＳパラメータ（QoS Parameter）：ＱｏＳパラメータは、所定のサービスの１つの特徴を表す機能的な記述である（一具体例として、相対的なエンドツーエンド遅延がある）。
−「情報技術−サービス品質：フレームワーク（Information Technology - Quality of Service : Framework）」（ＩＴＵ勧告Ｘ．６４１、１２／９７、ＩＳＯ／ＩＥＣ１３２３６：１９９８）（以下、[ISOX641]という。）で述べられている定義に続いて、ＱｏＳパラメータ（ＩＳＯ用語では、ＱｏＳ特徴）は、測定可能なＱｏＳに関する量を識別し、また、これを、以下に示すように、総称、専門化されたもの、導出されたものとして更に分類することができる。
・総称ＱｏＳパラメータは、任意の特定状態に適用可能であるが、適用先が何であるかに関わらず、共通の、基本的なＱｏＳパラメータの捕捉を試みる。
・専門化されたＱｏＳパラメータは、総称ＱｏＳ特徴の具体例である（後に、総称ＱｏＳ特徴を、それ自体として使用するように十分に具体化することができるが、多くの場合、専門化は、システム専用又はネットワーク専用の特異性を捕捉する必要がある）。例えば、総称時間遅延ＱｏＳ特徴を、システム実現に特化した問題を解決するために、さらに専門化することができる。専門化アプローチは、ＱｏＳ特徴を抽象化の適切なレベルでマッピングすることにより、複雑に分散システムを指定する上で非常に適している。
・導出されたＱｏＳパラメータは、数学的関係に基づいて、ＱｏＳ特徴間で依存性を捕捉する。導出されたＱｏＳ特徴の幾つかは、統計的性質のものであってよい（例えば最大値、最小値、範囲、平均値、分散及び標準偏差、ｎ百分位数、統計モーメント等）。導出したＱｏＳパラメータを、総称ＱｏＳパラメータと同様に専門化することができる。したがって、専門化及び導出を、ＱｏＳ特徴の直交変換と考えることができる。しかしながら、導出には、２つ以上の総称的／導出した／専門化したＱｏＳ特徴が関与できると述べなければならない（例えば、可能性は、信頼性と維持性の関数である）。
−ＱｏＳプロファイル（QoS Profile）：所定のサービスの仕様を考慮して、ＱｏＳに関連するエンドユーザ嗜好を特定するデータの集合。ＱｏＳプロファイルは、ユーザの端末装置、又は特定のデータベースに記憶することができる。
−ＱｏＳスペシフィケーション（QoS Specification）：ユーザが所定のサービスについて特定したＱｏＳパラメータ及び制約のセットを識別する一般用語である。
−ＱｏＳ違反（QoS Violation）：サービスプロバイダによって発生したＱｏＳ契約の違反。
−セッション（Session）：２つ以上のピア（ユーザエンドデバイス、又はサービス）間で長続きする接続のセットであり、通常、ピア間での、「関連する情報」（セッションの情報は特定のトピックと共に考慮される）の多数のパケットの交換が関与している。エム・ハンドレイ（M. Handley）、ブイ・ヤコブソン（V. Jacobson）著「ＳＤＰ：セッション記述プロトコル（SDP : Session Description Protocol）」（ＩＥＴＦ標準勧告文書（IETF Request for Comments）：２３２７、１９９８年４月）（以下、[Handl98]という。）によれば、マルチメディアセッションは、「マルチメディア送信側、受信側、送信側から受信側へ流れるデータメディアストリームのセットである。マルチメディア会議は、マルチメディアセッションの一例である」。ここでは、そのコンテキストに関連した２つのタイプのセッションについて確認する。
◇メディアセッション（Media Session）−メディアセッションは、ユーザが理解可能なデータのピア間での転送のコンテキストを含んでいる。
◇シグナリングセッション（Signaling Session）−シグナリングセッションは、メディアセッション設定の交渉のコンテキストであり、一般に、エンドユーザに対して不可視なままである。ＳＩＰ、ＳＣＣＰ他を使用して、シグナリングセッションを実行できる。シグナリングセッションは、アプリケーションに対して可視であり、更に、ユーザのインリベンション又はユーザのイベント生成が必要な場合にのみ、ユーザに対しても可視となることができる（例えば、１つ又は複数の他の仮想ボタンを押す要求を受けて、ＧＵＩウィンドウのポップアップさせる）。
幾つかのプロトコル（例えば、リアルタイム転送プロトコル（Real-Time Transfer Protocol：ＲＴＰ））は、メディアデータとメディア記述の両方を伝送することができるため、メディア送信とシグナリングが平行して実行される。
−シグナリング経路（Singaling Path）：ＳＩＰメッセージが通るネットワーク経路。
−メディアストリーム（Media Stream）：アプリケーションレベルにおける、２つのピア間での情報の連続非指向性交換である。異なるタイプのメディアストリームには、オーディオ、ビデオ、データ、テキスト、又はこれらの組合せが存在する。所定のパーティは、純粋なストリームソース（情報を排他的に送信する）として、純粋なメディアストリームシンク（ビデオオンデマンドサービス等の他のパーティから、メディアストリームを介して送信された情報を収集する）として、又は、メディアストリームソース及びメディアストリームシンクの両方（これは、テレビ会議サービス等の対話モードの典型である）として機能できる。１つのメディアストリームを、１又は複数のフローにマッピングすることが可能である。
以下のセクションにおいて、マルチメディア環境において発生し、エンドツーエンドＱｏＳ交渉プロトコル（Ｅ２ＥＮＰ）の使用から利益を得る、使用可能な異なる通信シナリオについて説明する。
このセクションでは、最初に、通信に考慮されるパーティ及びコンポーネントと、及び、通信アーキテクチャを形成するために構築する構造との重要な定義を紹介する。
記述されたアーキテクチャは、何らかの特定サービスに関連している。参加者がＱｏＳの交渉に使用する異なる通信モードが考慮される。使用するケースを定義するために、以下のアスペクトを考慮する。
・通信相手のパーティが誰であるか
・接続の起動側が誰であるか
・特定の通信シナリオに参加している通信相手のパーティが何人いるか
・上記通信相手のパーティがどのタイプの構造を構築したか
・どのタイプの接続モード（ユニキャスト又はマルチキャスト）が適用されているか
最後に、シナリオの作業概念の幾つかの具体例を説明する。
端末装置通信パーティ（申込者及び回答者）は、任意のエンドツーエンド交渉のアクティブコンポーネントである。上述した定義によれば、申込者と回答者はピアである。申込者は、接続交渉処理を開始するパーティである。回答者は、回答者との接続の確立を希望している申込者によって接触されるパーティである。多数のパーティが、実際の通信において、送信側（すなわち、メディアストリームを送信、あるいは送受信する）として動的な役割を果たすことができ、又は、受信側（すなわち、メディアストリームを受信する）として静的な役割を果たすことができる。
別タイプの通信パーティに、中間コンポーネントがある。これらのコンポーネントは、様々な程度の複雑性に関連して異なっており、また、異なるレベルのネットワーク接続に使用することができる。中間コンポーネントは全ての装置（プロキシ、ルータ等）、及び、サービス（例えばネーミング、割当、プレゼンス等）であってよい。この場合、中間コンポーネントは、単に静的な動作者でしかなく、エンドピア間における接続の構築をサポートするのみで、エンドピア間で行われる交渉処理には干渉しない。Ｅ２ＥＮＰの推測は、中間コンポーネントは交渉処理に全く関与せず、むしろ、交渉実施の前後において、交渉された情報に影響する。そのため、交渉された情報に対するその機能及び影響に関連して、中間コンポーネントを考慮する必要がある。
接続を確立することにより、以下について述べることが重要である。
１．交渉モードは、交換能力、及びＱｏＳ契約情報のシーケンス、また、どのパーティがその契約を最初に送信するかを記述する。
ａ．申込者が、回答者に対して、どのように接続設定を行うべきかを提案し、その能力及びＱｏＳの要件を事前に報知する際に、プッシュモードが使用される。プッシュモードは、１対１の電話式ボイスオーバＩＰ（ＶｏＩＰ）通信と共に使用される。
ｂ．プルモードは、申込者が、接続設定についての要件を報知せずに、回答者を呼び出す際に使用される。申込者は、回答者からこの情報を検索し、その要求を、受信したプロファイルに適合させる。このモードは、中央ピア（「VoD server」又は講師（lecturer））が使用するプロファイルを事前定義する際に、「ビデオオンデマンド」といった異なるサービスのために、又は「仮想講義（virtual lecturing）」によって使用することができる。
ｃ．申込者が、接続設定についての提案を回答者に対して行うだけでなく、更に、同時に回答者の設定を検索する場合にも、プッシュ／プルモードを使用することが必要な場合もある。
２．接続モード：どのピアが送信側で、どのピアが受信側であるかの知識は、交渉の開始に、どの交渉モード（プッシュ／プル）を使用することがより妥当であるかを確立するように機能する。
３．接続は（１人よりも多い参加者がいる場合には特に）、
ａ．受信側パーティのグループにとってのマルチキャストとして、
ｂ．各々の受信パーティにとってのユニキャストとして、機能する。
４．通信パーティの数は、どの交渉モード（プッシュ／プル）を使用することがより妥当であるか、また、どのシーケンスにおいて交渉サブ処理が実施されるかを決定するために必要な情報である。通信パーティは、以下の接続構造を形成することができる。
ａ．１対１−これは、２つのパーティ間における電話通信ケースであってよい。ここでの典型的なサービスの具体例としては、ＶｏＩＰがある（下記参照）。
ｂ．１対多−ＶｏＤサービス又はオンライン講義の場合である（書き参照）。
ｃ．多対多−ここでの典型的な具体例としては仮想会議がある（下記参照）。
以下のセクションにおいて、交渉プロトコルの要件を更に認識するために、幾つかの具体的な通信シナリオについて説明する。非常に単純なピアツーピア（１対１）通信については、文献[SDPOA00]において既に完全に説明されているため、以降に示すシナリオは、より複雑な通信パターンを考慮している。これらのシナリオは、動的通信及びマルチパーティ接続によって起こり得る典型的な状態について説明している。ネットワークに関連した装置と人物の移動性の影響を示す。発生し得る情報依存性の幾つかの概念、及び、これを記述する方法を紹介する。提案している具体例は、中間コンポーネントの静的通信パーティとしての使用の関与が可能なマルチパーティ通信の幾つかの態様を示している。
図１は、将来の電話型通信（phone-like communication）がどのように実行されるかを示す１対１通信シナリオ１００の電気通信セッション１０２の交換状態（switch situation）における呼再配置（call relocation）１０８の具体例を示す図である。この具体例のシナリオに含まれる２人のユーザ１０４ａ、１０４ｂは、メアリー（Mary）とケイト（Kate）である。
メアリーが、自分のインターネット対応腕時計１０６ａ１で、新しいボーイフレンドについて話したい友人ケイトからの呼（call）を受信する。この呼は、「誰が電話をしているか」（発信者の識別）、「通話の内容」（用件情報）を示すメッセージを伝えている。メアリーの腕時計１０６ａ１は、モニタが非常に小さく、モノクロであるため、受信した高解像度の画像１１２を表示することができないので、この腕時計１０６ａ１は、受信した画像を表示できる端末装置１０６ａ２の検索を自動的に開始する。腕時計１０６ａ１は、家庭用中央サーバと接続し、メアリーが自分の部屋で使用することを許可されているスマート端末装置１０６ａ２を示すメアリーのプロファイルを検出する。腕時計１０６ａ１は、「room」装置１０６ａ２と交信して、セッション１０３を再配置し、メアリーに、彼女への呼出が彼女の「room」装置１０６ａ２で待機している旨を知らせる。これにより、メアリーは自室へ移動して、呼出１１０に応答する。一方、ケイトは、メアリーが呼出１１０を受け取ったが、呼再配置１０８の手順に多少時間がかかる旨を知る。次に、適切なプロトコルによってこの情報が転送される。ケイトは、更に、メアリーがビデオ対応端末装置１０６ａ２上でこの呼出１１０を受け取ることができることも知り、彼女らは、画像を交換することができるようになる。メアリーは、自室に入れば、スマート端末装置１０６ａ２にアクセスして、友人と話すことができる。
メアリー：「ハーイ、ケイト、新しいボーイフレンドができたんですって？」
ケイト：「ハーイ、彼の素敵な写真もあるのよ。」
（最終的に、ケイトは、数枚のデジタル高解像度画像１１２と、更には、自分が好きなロックバンドの数枚の短いビデオクリップをメアリーに送信することができる。）
このシナリオは、パーソナルエリアネットワーク（ＰＡＮ）６０４のケースに関するものであり、能力及びＱｏＳの第三者支援（third-party-assisted）交渉８０６を、エンドツーエンドベースで実行する必要がある。これは、メアリーの腕時計１０６ａ１が、新たに検出されたスマート端末装置１０６ａ２の代わりに交渉を行うことができることを意味している（プロキシメカニズム）。
あるいは、メアリーの「room」装置１０６ａ２によって、ケイトの端末装置１０６ｂとの交渉８０６を直接実行することができる。この場合、呼再配置１０８のメカニズムは、全ての接続確立処理を他の装置１０６ａ２に完全に渡す（リディレクトメカニズム）。
このシナリオ１００のサブケースとして、当然ながら、呼再配置１０８を全く必要とせずに、ケイトの端末装置１０６ｂとの交渉８０６処理を、メアリーの腕時計１０６ａ１によって直接実行することもできる。このようなサブケースは、[SDPOA00]に記載されている非常に単純な１対１通信に対応している。このケースを、シグナリングプロトコルの交渉フェーズと共に、図８に示す。
図２に示す具体例は、１対多通信シナリオ２００の状態における仮想講義（virtual lecturing）を示しており、この場合、１人の講師２０２（ティー・マーチン教授（Prof. T. Martine）と３人の生徒２０４ａ〜２０４ｃ（Ａ、Ｂ、Ｃ）が関与している。これに関して、ティー・マーティン教授は、ローマでの会議に出席する一方で、同時に、ベルリン大学で通常の講義スケジュールを行わなければならない。ティー・マーティン教授は、会議スケジュールの空いた時間を利用して、オンラインで講義を行う旨、自分の生徒Ａ、Ｂ、Ｃに手配し、これに伴い、セッション１０２を午後２時から開始すると通知した。これに関連して、ティー・マーチン教授は、ホテルの自室にあるコンピュータを、生徒の装置に対応させて、異なる幾つか送信プロファイルをサポートするよう設定した。午後１時、教授は、最初の生徒が、ホテルの教授の部屋にあるコンピュータとの接続セッション１０２を開く交渉８０６（又は８０９）を開始した旨の通知を教授のＰＤＡより受けた。ティー・マーチン教授は、自室へ行き、午後１時５５分に、講義セッション１０２を最終的に開始する前に、参加者Ａ、Ｂ、Ｃが席に着いているかチェックする（round table check）。講義接続は、学業上重要なものとして識別情報を伝え、このセッションは無料に、又は大学の口座に請求される。
この具体例は、１対多通信シナリオのケースを説明している。このような種類の通信は、「ビデオオンデマンド（video-on-demand：ＶｏＤ）」サービスの場合と同等のものであるが、上述の具体例は、ＶｏＤの場合では事前に録画されたものを伝送するのと比べて、生で伝送が行われる点が大きく異なる。したがって、この具体例において、各受信側Ａ、Ｂ、Ｃは、（名目上）同時に同じ情報しか受信できない。
次の、図３に示す具体例は、４人のユーザ３０２ａ〜３０２ｄ（キャロライン（Caroline）、マーサ（Martha）、ミランダ（Miranda）、秘書）が関与している多対多通信シナリオ３００におけるテレビ会議１２０４ａ／ｂの単純な形態と形式として見なすことができる。
キャロライン及びマーサは、ロサンジェルスにあるファッションデザイン会社の社員であると仮定する。２人は、フランス人の同僚ミランダと共に、新しいコレクションに関する共同プロジェクトに取り組んでいる。女性社員３０２ａ〜３０２ｃは、コレクションの準備についての最新の状況を交換するために、毎週、テレビ会議１２０４ａ／ｂを行っている。キャロライン及びマーサは、自分達のデザインを、チェック及び承認してもらうためにミランダに送信する。ミランダは出張が非常に多く、上司に提出する適当な報告書を書く時間を十分とることができないので、上司へのプレゼンテーションを準備するために、モデルの再審査を手配するように自分の秘書に頼んだ。会議が始まると、ミランダ、キャロライン及びマーサは、画像及びテキストメッセージと同様に、オーディオ及びビデオコンテンツの交換を開始することができる。一方で、秘書３０２ｄは、オンラインでこの会議を聞きながら、会議及びミランダの意見の議事録をとっている。
このシナリオ３００は、異なるソースから発生する情報の場合に関係している。これは、関連する情報メディアストリーム２０６のグループの具体例であり、この場合、ユーザは、交換されるメディアストリームの中でＱｏｓ関連フェーズ８０４を要求することができる（例えば、秘書エンドポイントにおいて）。
次の図４の具体例は、４人のユーザ４０２ａ〜４０２ｄ（スーザン・ジョーンズ（Susanne Jones）、２人の審査員、ジョーンズ氏（Mr. Jones））が関与しているテレビ会議１２０４ａ／ｂの複合シナリオを示す、多対多通信シナリオ４００に関する。
これにより、スーザン・ジョーンズは、公開博士号の事前試験を行っており、更に、父親に、試験セッション１０２に聴講者４０４ｄとして参加するセッション接続キーを与えることによって、父親を自分のオンライン試験セッション１０２に招待し、受動的に参加させている。スーザンはオンラインプレゼンテーションを行っており、これが、彼女の試験官４０４ｂ、４０４ｃ及び聴講生のグループにマルチキャストされる。試験官４０２ｂ、４０２ｃは、スーザンを実際の試験へと案内できるように、更に、このプレゼンテーションの良い面と悪い面を指摘できるようにするために、オンラインノートの交換を行うので、スーザンの端末４０４ａと試験官の端末４０４ｂ、４０４ｃの間で、このセッション１０２の最初の設定が行われた。意見は、プレゼンテーションのページ、又は共通のホワイトボードに直接書き込まれる。この意見は、実行中のプレゼンテーションと結合され、また、初期手配がこの通信を定義する（関連８０４）。
初期手配が満たされると直ちに、試験が開始する。聴講生４０２ｄと他の聴講生は、実行中の試験を動的な参加者として妨害しないため、後に参加することができる。セッション１０２に参加しているいずれの聴講生も、プレゼンテーションの現在時点での採点に関する情報を入手することができる。スーザンの父親の端末４０４ｄは、セッション自体と、スーザンの博士号試験官４０２ｂ、４０２ｃによる採点とを入手するために署名して、セッション１０２に参加する。端末４０４ｄは、スーザンの父親の要請に関連する事前設定のプロファイルに基づいて、スーザンの端末４０４ａ、及び試験官４０２ｂ、４０２ｃの端末４０４ｂ、４０４ｃとの関連の手配を行うため、スーザンの父親は、プレゼンテーションのマルチキャストに参加し、採点をユニキャストとして入手することができる。
上記シナリオ４００の適切に進行するためには、どのように単一のメディアストリーム２０６をグループ化するか、及び実行中のメディアストリーム２０６に関心を持っているパーティは誰であるかについての知識を持つことが必要である。このようなシナリオでは、セッション１０２において、参加者のグループと、メディアストリーム２０６のグループを定義することが重要である。更に、通信のための階層グループ化構造が形成される。
また、このシナリオ４００は、リアルタイムトラフィックのみでなく、非リアルタイムトラフィックも高い優先順位のトラフィックとして取り扱うべきであることを示しており、例えば、外国人参加者のための試験の生放送通訳を含んだサブタイトルのメディアストリーム２０６は、これがコンテンツと同時に進まない場合に（また、全く伝送されない場合に）、無用となるため、これは擬似リアルタイムとして考慮されるべきである。この場合、非リアルタイムトラフィック（サブタイトル）は、リアルタイムトラフィックと所定の度合いで関連している。
上記シナリオ４００は、更に、数人の作業グループとのネットワーク６０４ゲーム、オンライン会議にも適用できる。このようなシナリオ４００の複雑性を考慮すると、マルチパーティ接続の特定の事前手配及び計画が必要、又は不要であるかもしれない。
図５の具体例は、やはり、通信パーティ及びサービスの検出と、交渉８０６（又は８０９）の検出とをサポートする幾つかのサービスの使用を考慮した、マルチパーティ通信の幾つかの追加的な態様を示している。したがって、モバイルユーザ５０８ａ、５０８ｂ（アール・ハリス医師（Dr. R. Harris）、そのアシスタントであるエー・フランク氏（A. Frank））が上記シナリオに関与する。
この具体例では、ハリス医師がフランクフルトからパリへ移動しながら、フランスにいる患者の脳手術に関するテレビ会議１２０４ａ／ｂに、フランス人の同僚と共に参加しなくてはならない。同僚達が、患者に関する最新のモニタ情報をハリス医師にオンラインで送信している。更に、彼等は、ハリス医師がパリ市内の病院に到着し次第、手術を開始できるように、その遂行に関して討論を行う。ハリス医師は、列車５０２に乗車すると、端末を列車ＬＡＮに無線プラギングする。すると、列車サーバは、ハリス医師が列車ＬＡＮ内に存在している旨を通知される。フランク氏がストラスブルグで列車５０２に乗車する。フランク氏も、列車５０２に乗車すると、端末を列車ＬＡＮに無線プラギングし、自分の上司が上記列車５０２の他のワゴンに既に乗車している旨を知る。（この列車は完全に全席予約済みであったため、フランク氏はハリス医師の近くの座席を予約することができなかった。）フランク氏は、実行中の会議に参加するために、呼出を発行する。これにより、ハリス医師とフランク氏の端末が、「アドホック」ネットワーク６０４を構築し、更に、ハリス医師の端末を、会議メディアストリーム２０６をフランク氏の端末へ再送信する「外界」への接続として使用する。
このシナリオ５００は、列車サーバをディスカバリサービスとして使用する仮想出席の一例である。更に、ネーミング及び／又は割当サービス等といった中間サービス、あるいはプロキシやレジストラーを設けることが可能である。この場合、中間コンポーネントは、エンドピアが実施する交渉８０８、８０９に活発に参加することなく、エンドピア間の接続の構築をサポートするだけ。
以下のセクションでは、複数タイプ、及び同時発生するメディアストリーム２０６を取り扱うマルチメディアアプリケーションにおいて、ＱｏＳを取り扱う方法に関する問題について説明する。次に、所謂「経済原理」を適用した、基本的な本発明に基づいて提案された解決手法の重要な面、アプリケーションレベルのＱｏＳｎｏ前交渉８０２、分散リソース管理の調整について詳細に説明する。このセクションで識別される要件は、要件リストに収集されるが、この要件リストには、更に、識別された要件間の依存性についての情報が含まれている。
モバイルユーザが次世代ＩＰネットワーク６０４及びアプリケーションのコンテキスト内で最も直面する主要な問題は、端末装置における、また、ネットワーク６０４内での制限された量のリソースと、不安定な環境条件とに如何して対処するかである。したがって、以下の要件を仮定することができる。
要件１：モバイル端末及び／又は固定端末の開発者とユーザは、ＱｏＳを実現する場合には特に、不安定な環境条件に対処できなければならない。
マルチメディアセッション１０２は、基本タイプのメディアストリーム２０６（すなわち、オーディオ、ビデオ、データ）を数本含んでいる。一具体例として、特定のユーザの観点から、１つのセッション１０２は、異なるピアから（また、更には、サラウンドシナリオ内の１つのピアから）生成された、２本のビデオメディアストリーム２０６と、４本のオーディオメディアストリーム２０６で構成することができる。そこで、所定のユーザは、各々の単一のメディアストリーム２０６について入手したいＱｏＳ及び内部メディアストリーム２０６の動作を決定する任意のパラメータの特定を要求する。一般に、テレビ会議１２０４ａ／ｂアプリケーションは、エンド端末において同期されなければならない音声及びビデオメディアストリーム２０６を取り扱う。シナリオによっては、非同期されたテレビ会議１２０４ａ／ｂｓが十分でない場合もある。
更に、上述したメディアストリーム２０６の数本又は全ての間に、時間及び／又はＱｏＳベースの、あるレベルの関連８０４が必要である。この関連８０４は、時間同期８０５問題の一般化を構成する。例えば、電子ゲームアプリケーション、及び／又は、メディアリッチな対話式アプリケーションは、ユーザに提示されたオブジェクトに関連したオーディオ及びビデオメディアストリーム２６のバンドルを特徴とする。例えば、移動及び／又は回転する立方体をモニタ上に表示する場合、この立方体の各側面を、ビデオメディアストリーム２０６、異なるオーディオメディアストリーム２０６からの画像で各々テキスチャリングし、また、これと関連付けることによって、立方体のある側面が特定の方向を向く際には常に、この側面に関連したメディアストリームからの画像が再生されるようにすることができる。
これに関連して、アプリケーションは、関連したメディアストリーム２０６が所定の一時的関係（シアー時間同期）において再生されるだけでなく、更に、所定のメディアストリーム２０６バンドルを組み合わせたＱｏＳが所定の制約（ＱｏＳ関連８０４）内に含まれる。例えば、ゲームアプリケーションの具体例について続けると、立方体の幾つかの側面を白黒ビデオで表示し、これ以外の側面を、高品質のカラービデオで、より高いフレームレートで表示することは、これらの画像がシアー且つ一時的な観点から見て完全に同期している場合でも、意味がないかもしれない。むしろ、可能な限り最高のフレームレートで白黒映画を表示している全ての側面を表示することによって、カラー画像によって、カラー画像を表示するフレームレートに不利を来す、無駄なリソースの消費を回避した方が意味があるだろう。
当然ながら、どのレベルの関連８０４を、メディアストリーム２０６のセットの中のＱｏＳレベルで実行すべきかについての決定は開発者、更にはユーザの思慮に任される。
したがって、マルチストリームアプリケーションは、メディアストリーム２０６のグループ中のタイミング関係の仕様に加えて、ＱｏＳ関連８０４の仕様を必要とすることができる。実際、時間同期は、ＱｏＳ関連８０４の特殊なケースと考慮できるため、この区別は、２つの直交するアスペクトを完全に識別しない。所定のメディアストリーム２０６が、多数の明確なトランスポート層フロー（例えば、多層化したコーデックによって生成されたもの）で構成されている場合には、これらの問題はより明白である。
要件２：複数のメディアストリーム２０６を扱っているマルチメディアアプリケーションの開発者及びユーザは、ＱｏＳ関連８０４アスペクトと時間同期アスペクトを含めることによって、そのＱｏＳ仕様を増加することができる。
メディアストリーム２０６の処理は、アプリケーション又はユーザ依存であるだけでなく、更には、階層スキームに基づいて構築することが可能である。
例えば、テレビ会議１２０４ａ／ｂアプリケーションにおいて、メディアストリーム２０６の異なるグループを区別する（更に、これにより別々に扱う）ことによって、複数の同時発生するテレビ会議１２０４ａ／ｂの場合を識別できるようにし、更に、各々のテレビ会議１２０４ａ／ｂセッション１０２内で、所定のユーザの複数のピアとの様々な関連を識別できる（各々の関連は、関連されたメディアストリーム２０６のバンドルである）ようにすることは意味がある。
したがって、この提案は、マルチストリームの時間同期８０５制約と、ＱｏＳ関連８０４制約を、影響を受けたメディアストリーム２０６のリストに関連付けて、高レベルのＱｏＳ制約１１０８としてをモデリングする。更に、これにより、このような高レベルのＱｏＳ制約１１０８をその中で再帰的に処理し、階層ＱｏＳ規格スキーム、すなわちツリーの同等物へと導く。このようなリーフの各々は、メディアストリーム２０６を表し、また、関連するＱｏＳ契約１１０８を備える。親ノードは、マルチストリームに関連したその子ＱｏＳレベルについて、時間同期８０５制約とＱｏＳ関連８０４制約を特定する、高レベルのＱｏＳ契約１１０８と関連している。
更に、ユーザは、量の異なるリソースに優先順位を付け、これを様々な（マルチメディア）アプリケーションに許可することができる。これは、[BRAIN]に記載されているように、メモリ、電池電力等のリソースが限られているハンドヘルド型デバイスにとっては特に重要である。このアプローチにより、端末装置によって局所的に実行される、更に高レベルの時間同期制約８０５、ＱｏＳ関連８０４制約が得られる。関連する高レベルのＱｏｓ制約１１０８は、ツリーデータモデルを根本において拡張する。しかしながら、このような追加的な高レベルＱｏＳ制約１１０８は、ピアとの交渉向けのものではない。むしろ、各ピアが、高レベルＱｏＳ制約１１０８を独立的に実施することができる。あるいは、高レベルＱｏＳ制約１１０８は、コーディネータが選択されると、所定の終了したピアのセット全体に亘ってグローバルに実施することができる。
要件３：マルチメディアストリーム２０６を扱うマルチメディアアプリケーションの開発者とユーザは、そのＱｏＳ仕様を階層的方法で構築しなければならない。
ＱｏＳ違反及びＱｏＳ変更に対処するために使用可能な方法は、モバイルユーザのアプリケーションが、事前に制約を計画しておくことによって、これらのイベントに対して効果的且つタイムリーに反応できるようにするというものである。
このように、ＱｏＳ違反が発生した場合には常に、変化した条件にどのように最も効果的に適合させるべきかの合意に、ピア同士がタイムリーに達することができる。
これにより、これら２つの計画メカニズムを組み合わせる総合的な解決手法を、エンドツーエンド交渉プロトコル９０８（Ｅ２ＥＮＰ）（Ｅ２ＥＮＰ ９０８）と呼ぶ。
要件４：Ｅ２ＥＮＰ ９０８には、ＱｏＳ違反（例えばハンドオーバ）又はＱｏＳ変更（例えば、ローミング時のユーザ変更プロファイル情報）により発生した予想不能なイベントに対処するための、適切な対処法を事前に計画するメカニズム及び手段が含まれる。
階層ＱｏＳ規格は、ユーザの要求に従うべく、オーバロード状態中における反応方法を決定するアプリケーションを援助するように拡張することが可能である。
ネットワークプロバイダは、実行時のみにおいて、第三者支援交渉８０６に関与できるため（[ISOX641]によれば、この場合、動作者は、起動側、プロバイダ、１又は複数のレスポンダである）、実際、単一のＱｏＳレベルのシアー交渉８０６は実行時のみに意味を為す。ＩＥＴＦコミュニティで使用の最新の用語と一致させるために、以下のネーミングコンベンションを、基本的な本発明の範囲内で使用する。起動側の代わりに申込者９１４、レスポンダの代わりに回答者９１１。これは、より密接なＱｏＳ保証を提供するネットワークリソースを明確に予約しなければならない場合に必要である。
しかしながら、ＱｏＳの観点から、モバイルマルチメディアサービス（対話及び会議サービスだけでなく、更に、情報の検索も含む）の最も重要なフェーズ、すなわち、接続確立とハンドオーバを高速化することの必要性が確認されている。これは、基本的なトラフィックが一般に遅延感知型であり、また、異種及びモバイル式のネットワーク６０４の使用は、制限された帯域幅とネットワーク６０４容量、更に周波数ハンドオーバを意味するためである。
そこで、現在及び将来のリソース量に対処するために、ＱｏＳレベルのセットを事前に正確に計画する解決手法を提案する。
これに加えて、セット内の各エレメントを一意の識別子と関連つけることにより、ＱｏＳ（再）交渉時間において、各セットを迅速且つ一意に参照することが可能となる。
更に、エンドアプリケーション及びエンドサービスの特別の特徴は、異なる交渉８０６モードと、異なる順序でのメッセージの交換を要する。
最後に、任意のＱｏＳ情報は使用可能なリソースの知識から導出されることを述べなければならない。如何なる所定のユーザが感知可能な質は、異なるリソース（例えばコーデック）を使用して得ることができるので、これに応じてＱｏＳ契約（１又は複数）１１０８を作成できるようにするために、リソースに関する情報を収集する必要がある。更に、リソースに関する情報は、リソース予約を実行する際にも使用される。
要件５：Ｅ２ＥＮＰ９０８は、ＱｏＳ交渉８０６、ＱｏＳ再交渉８０８を迅速且つ効果的に実行するメカニズム及び手段を含む。
要件６：異なるアプリケーション及びサービスを用いれば異なる交渉８０６スキームが必要となる可能性があるため、Ｅ２ＥＮＰ９０８は情報交換モード（プッシュ、プル、プッシュ／プル）を定義するメカニズム及び手段を含む。
要件７：Ｅ２ＥＮＰ９０８は、使用可能なリソース（例えばコーデック）に関する知識から導出したＱｏＳ情報を取り扱う。
要件８：Ｅ２ＥＮＰ９０８は、複数の代替レベルのＱｏＳを特定し、前交渉するメカニズム及び手段を含む。
要件９：各ＱｏＳレベルは、特定のＱｏＳ契約１１０８により示される。
要件１０：Ｅ２ＥＮＰ９０８は、シグナリングを最少に維持するために、ＱｏＳ交渉８０６、交渉再交渉８０８中に、前交渉したＱｏＳレベルの各々を一意に参照するメカニズム及び手段を含む。
モバイルユーザは、３タイプのイベント（ハンドオーバ）が発生する場合に、古いネットワーク６０４アドレスを保持し、任意のアクティブな電気通信セッション１０２を維持しながら、ネットワーク６０４に接続するモバイル端末ポイントを変更する能力を必要とする。
一般に、ユーザが特定のネットワークプロバイダとの間にビジネス上の関係があると仮定した場合（例えば、ＩＳＰ加入、又はテレコム（Telecom）オペレータとのプリペイドカードでのやり取り）、使用可能な３つのタイプのハンドオーバが発生する可能性がある。
−水平ハンドオーバ：ネットワークプロバイダの所定の管理ドメイン内、及び、同タイプのアクセスネットワーク６０４内でハンドオーバが発生する。
−垂直ハンドオーバ：２つの異なる種類のアクセスネットワーク６０４間及び／又は２つのネットワーク間の管理境界を横切ってハンドオーバが発生する。
ハンドオーバを扱う場合、ユーザは、アクセスしているアクセスネットワーク６０４の種類によってのみでなく、更に、ユーザが、アクセスしている様々なネットワーク６０４のオペレータとの間のビジネス関係によっても、ネットワークリソースの利用可能性における変更に直面する準備ができていなければならない。幾つかの極端な場合では、ユーザは、実際に、ビジネスに全く関係ない、あるいはユーザのアクセスを制限あるいはユーザに割り当てるリソース量を制限するネットワーク６０４オペレータが所有するネットワーク６０４にアクセスを試みるかもしれない。料金面も重要である。
これら全ては、ユーザは、ハンドオーバ発生時には常に、劇的なＱｏＳ違反を経験する準備をしておかなければならないだけでなく、更に、このようなハンドオーバ中に、ユーザが、より多くのリソース及び／又はより少ない規制で、ネットワーク６０４にアクセスする際には常に、任意の潜在的な改善に有利な影響を与える準備をしておく必要があることを意味する。
要件１１：Ｅ２ＥＮＰ９０８は、ユーザが、好ましい代替的レベルのＱｏＳを、好ましいネットワークプロバイダが何をサポートできるかに対して、回避的に検証を行ったと推測する。
上の段落で述べた論理によれば、ピアは、所定のＱｏＳ契約１１０８にのみでなく、ネットワーク６０４、及び／又は、端末リソース能力が時間と共に変更する際には常に使用できる他の契約にも合意できるようでなければならない。
このような方法では、ピアは、重要なＱｏＳ変更に対処するため、又は、最も新たに使用可能となったＱｏＳ契約１１０８に関連した任意のＱｏＳ違反に対処するために、どの代のＱｏＳ契約１１０８が（及び、如何なる条件下で）実施されるかを正確に知ることができる。
適応経路の概念は、どの代のＱｏＳ契約１１０８が、どの状態において実施されるべきかを示す規則のセットを指示すると共に、更に、公称のＱｏＳ契約の仕様に加えて代のＱｏＳ契約１１０８の仕様を指示する。一般に、代のＱｏＳ１１０８は、公称的ＱｏＳ契約１１０８によって特定されたものと比較して、より低レベルのＱｏＳを記述する。より詳細には、適用ポリシは、上手く定義されたＱｏＳ変更及び／又は違反のセットと一致する、代の劣格化したＱｏＳ仕様（すなわち、より低レベルのＱｏＳ）のセットへの、公称ＱｏＳ契約１１０８の上手く定義された適応を、ジェイ・ピー・ロイヤル他著「ＱｏＳアスペクト言語及びリアルタイムインテグレーション（QoS Aspect Languages and their Runtime Integration）」（コンピュータ科学における講義ノート（Lecture Notes in Computer Science）、Ｖｏｌ．１５１１、スプリンガー・バーラグ（Springer-Verlag））（以下、[Loyal]という。）に記載されているように、相対的なミドルウェアによって監視された通りに識別する。
基本的な本発明の範囲内で、[BRAIN]に記載されている用語を適用しているが、この場合、後に、より多くのリソースが使用可能になった際に、適応を所定の品質を向上させるためにも使用できるようになることを強調するために、劣格化経路の代わりに適応経路（ＡＰ）を使用している。
要件１２：Ｅ２ＥＮＰ９０８によって、ユーザは、適応経路を事前定義することが可能になる。
要件１３：適応経路の各々のエレメントは、ＱｏＳ契約１１０８である。
要件１４：各々の所定のセッション１０２における各単一のメディアストリーム２０６は、所定のＱｏＳ契約１１０８に関連付けされなければならない。
要件１５：各々のＱｏＳ契約１１０８は、一意の識別子と関連付けされる。
要件１６：Ｅ２ＥＮＰ９０８は、如何なる所定の適応経路から選択したＱｏＳ契約１１０８の特定及び前交渉を、アプリケーション（１又は複数）がメディアストリームを開示する際に使用するデフォルトのＱｏＳ契約１１０８として実行する。
要件１７：更に、適応経路は、アプリケーション及び／ミドルウェアが、その所定のセットから、様々なＱｏＳ契約１１０８を共生すべきである状態を定義する規則の仕様を含むことができる。
要件１８：Ｅ２ＥＮＰ９０８は、メディアストリーム２０６レベルでＡＰを特定するメカニズム及び手段を含む。
上述の階層ＱｏＳ規格の任意のレベルでＡＰを適用することにより、時間同期仕様及びＱｏＳ関連８０４仕様の両方を含め、適応処理を更に向上させることができる。
このモデルでは、各々の代の時間同期及びＱｏＳ関連８０４仕様は、特定のＱｏＳ契約１１０８に関連している。
様々な関連８０４のアスペクトを捕捉できるようにするための、階層フォーマットに構築された代のＱｏＳ契約１１０８の使用により、実際、ピアは、前交渉８０２処理中にネットワークプロバイダの介入なしに、共通の、構築された「ＱｏＳ語彙」に優先的に（前交渉８０２時において）合意できるようになる。
これに関連して、ピアは、エンドツーエンド前交渉８０２に参加する際には常に、処理記述時間にネットワークプロバイダと前交渉したプロファイル情報を有利に使用できる。ローミングの場合にはネットワークプロバイダが、ユーザが新たなネットワークドメインを訪れる際に、ユーザのプロファイル情報が依然として有効である（全体的、又は部分的に）という規定を（サービスレベル合意（Service Level Agreements）を介して）作成することができる。
ＱｏＳ関連８０４及び／又は時間同期８０５制約の実現は、様々な基準に基づいたメディアストリーム２０６の論理グループを意味する。例えば、
・同期したトランスレーションを実行するための、全ての擬似オーディオメディアストリーム２０６のグループ化
・割当を実施するために、マルチユーザ端末上で所定のユーザによって開かれた全てのメディアストリーム２０６のグループ化
最終的に、メディアストリーム２０６のグループはメディアストリーム２０６を１つのみ含むことができ。このような場合、基本的なメディアストリーム２０６ＱｏＳ契約１１０８が、単純に、より高レベル（例えば、アプリケーションスペシフィック）ＱｏＳ制約と共に増大する。
グループは、主に、リソースの使用可能性の質を交換する際に、環境条件の所定のセットの中で複数の同等のバンドルのうちで、ＱｏＳａウェアアプリケーションが総体的に扱うことができるメディアストリーム２０６のバンドルを表すために有用である。
これに関連して、ピアは、各々の独立したメディアストリーム２０６のＡＰのみでなく、所定の全体のバンドルの代替的構成、及び、これにより得られる各構成のための、特定のＱｏＳ関連制約８０４及び／又は時間同期制約８０５にも事前に合意できる。その結果、アプリケーション（及び／又はミドルウェア）は、どのメディアストリーム２０６に適応すべきか（ストリームの停止又は再開等の動作を含む）、また、新たな状態において、どの新たなＱｏＳ関連制約８０４及び／又は時間同期制約８０５を実行すべきかを示す、事前定義した規則に基づいて、所定のＱｏＳ変更及び／又は違反に適応することができる。
要件１９：Ｅ２ＥＮＰ９０８は、メディアストリーム２０６のグループについて、適応経路を、更に、関連するＱｏＳ関連制約８０４及び時間同期制約８０５を特定するメカニズム及び手段を含む。
更に、重要な状態においては、グループのうち数本のメディアストリーム２０６がもはやサポートされていない可能性があるため、適応処理中に、ＮＵＬＬストリームＱｏＳ契約１１０８を定義することが妥当である。このようにすることによって、メディアストリーム２０６のグループ全体のＱｏＳ設定の完全な再交渉８０８を防止することができるため、グループ内の、境界条件が未だ有効であるメディアストリーム２０６を実行したまま残すことができる。
ＮＵＬＬストリームの背後にある概念は、エンドピアに、検出されたＱｏＳ違反／変更による「ストリーム一時停止（PAUSE-STREAM）」命令を明確に起動できるようにさせるというものである。一時停止の前に、交渉したＱｏＳレベルに関する情報を保存することによって、ＱｏＳ違反／変更条件がそれ以上存在しない場合には、このような情報を、後に再交渉ＱｏＳを正確で迅速に交渉するために使用することができる。例えば、メアリーが、自分のモバイル装置１０６ａ１上でビデオクリップを見ているが、万が一接続の品質が低下した場合には、ビデオストリーミングを一時停止して、ミュージックスコアを聴くためにリソースを保存することを望む旨を自分のユーザプロファイル表示したと仮定する。ハンドオーバ中にＱｏＳ違反が発生し、その結果、装置がＶｏＤサーバに、ビデオストリームを一時停止するようシグナリングする。ＶｏＤサーバは、ビデオストリーミングを一時停止し、前交渉したＱｏＳ情報を保存することにより、ハンドオーバが完了すると直ちに、前交渉したＱｏＳ（オーディオストリームに関連した時間同期の問題を含む）に基づいてストリームを再開できるようにする。メアリーの装置１０６ａ１は、更に、ＱｏＳを再開する際に、更新のための完全な再交渉を行わないようにするために、ビデオストリームの存在を覚えておく。
境界条件の定義は、アプリケーション巣ペシフィックであり、セッション１０２のコンテキストに依存する。概して、１つのグループ内にあるＮＵＬＬストリームのアプリケーションは、セッション１０２のコンテキストに影響すべきではない。すなわち、セッション１０２におけるストリームグループの、未だに実行中のメディアストリーム２０６は、エンドパーティにとって、ストリームグループを直立に維持し、新たに取り消し及び再交渉しないようにする上で、十分に重要である。したがって、ＮＵＬＬストリームのアプリケーションは、単純に、完全な再交渉８０８を回避するツールであり、ストリームグループの重要な適応に役立つ。
例えば、オーディオ及びビデオメディアストリーム２０６を含んだメディアストリーム２０６のグループの場合を考える。すると、関連するグループＡＰは、帯域幅の所定の閾値未満への低下といった重要な状態の発生を説明するために、ビデオメディアストリーム２０６がＮＵＬＬストリームＱｏＳ契約１１０８と関連しているオプションを含んでいる。このような場合には、ビデオメディアストリーム２０６を停止するが、オーディオのメディアストリームは継続される。
要件２０：Ｅ２ＥＮＰ９０８は、グループ適応経路においてＮＵＬＬストリームＱｏＳ制約１１０８を特定するメカニズム及び手段を含む。
要件２１：ＮＵＬＬストリームのアプリケーションは、実行中のセッション１０２のコンテキストに影響してはいけない。
アソシエーションは、所定のユーザと所定のピア間の、全てのメディアストリーム２０６に関連している、特定タイプのメディアストリーム２０６のグループ化である。このタイプのグループ化は、最も直観的なものであり、非常に頻繁にしようされることが予想される。
要件２２：Ｅ２ＥＮＰ９０８は、メディアストリーム２０６のアソシエーションに、ＡＰと、任意の関連するＱｏＳ関連制約８０４及び時間同期制約８０５とを特定するメカニズム及び手段を含む。
ＱｏＳコンテキストは、所定のメディアストリーム２０６のグループ全体にかけて、実行されるＱｏＳパラメータの配置を識別する。ＱｏＳコンテキストは、ＱｏＳ契約概念の仕様としてモデリングされた論理エンティティである。
すなわち、各々のメディアストリーム２０６のＱｏＳ仕様が何であるかに関係なく、ＱｏＳコンテキストは、ＱｏＳ制約のセットを、所定のグループに属している全てのメディアストリーム２０６に適用するように実行する。
更に、ＱｏＳコンテキストは、所定のＱｏＳコンテキストに関連したグループに属する各々のメディアストリーム２０６のＱｏＳ契約１１０８から導出されたこれらのＱｏＳパラメータを捕捉することができる[ISOX641]。この具体例として、所定のマルチメディア２０６のセットが使用するメモリ又は平均帯域幅の総量がある。
要約すると、ＱｏＳコンテキストは、以下に示す仕様により忠実に注目しながら、メディアストリーム２０６のグループ化、ＱｏＳ関連８０４、時間同期問題を扱う。
・メディアストリーム２０６のグループのための共通のＱｏＳレベル
・導出したＱｏＳパラメータ
・処理されたメディアストリーム２０６のＱｏＳ仕様に間接的に影響するＱｏＳパラメータ
当然ながら、メディアストリーム２０６のグループ間で、どのレベルのＱｏＳ関連８０４及び／又は時間同期８０５の決定を実行するかの決定は、開発者のみでなく、ユーザも行うことができる。
要件２３：Ｅ２ＥＮＰ９０８は、所定のメディアストリーム２０６のグループに関連したＱｏＳコンテキストを特定及び前交渉するメカニズム及び手段を含む。
要件２４：各ＱｏＳコンテキストは、一意の識別子に関連している。
要件２５：Ｅ２ＥＮＰ９０８は、如何なる所定の適応経路から選択したＱｏＳ契約１１０８の特定及び前交渉を、アプリケーション（１又は複数）がメディアストリームを開示する際に使用するデフォルトのＱｏＳ契約として実行する。
上述の階層モデルによれば、ＱｏＳコンテキストのツリーベースの階層を定義することができる。任意のこのようなツリーデータ構造のリーブは、所定のメディアストリーム２０６のグループに属する個々のメディアストリーム２０６に関連したＱｏＳ契約１１０８によって表される。
このようなツリーデータ構造の任意の内部ノードが、代わりにＱｏＳコンテキストで表され、これにより、所定の内部ノードからのサブツリールーティング内に含まれている、全てのメディアストリーム２０６のＱｏＳ仕様が、ＱｏＳ契約１１０８によって直接影響される。すなわち、ＱｏＳコンテキストが、全ての基本的メディアストリーム２０６に間接的に影響する特定のＱｏＳパラメータを指定することができる（例えば、システムレベル信頼性の問題）。
更に、任意のこのようなツリーデータ構造におけるより高いレベルで、ＱｏＳコンテンツが、他のより低レベルのものの中から選択され、再帰的に定義される。
このようにすることによって、任意のこのようなツリーデータ構造は、ＱｏＳ関連８０４、時間同期基準に基づいて、個々のメディアストリーム２０６のみでなく、既に定義されているメディアストリーム２０６の複数のグループも集合させるために使用することができる。
要件２６：Ｅ２ＥＮＰ９０８は、所定のメディアストリーム２０６のグループの集合に関連したＱｏＳコンテキストのツリーベースの階層を特定及び前交渉するメカニズム及び手段を含む。
ＱｏＳアウェアアプリケーションが、シブリングＱｏＳコンテキストの重要性を決定するために使用できる各ＱｏＳコンテキストに、優先順位を指定することができる。
要件２７：Ｅ２ＥＮＰ９０８は、ＱｏＳコンテキストの所定のツリーベースの階層内でシブリングである、ＱｏＳコンテキスト間において、関連する優先順位を特定及び前交渉するメカニズム及び手段を含む。
ＱｏＳコンテキスト及び階層ＱｏＳ規格の概念をレベレージングすることによって、ピアが、上述のグループＡＰ（ＧＡＰ）の概念を実現できる。
当然ながら、ＱｏＳ関連制約８０４と時間同期制約の実施は、交渉８０６処理に関与しているピアが、所定のビジネス（どのアプリケーションを使用するか、誰に接触するか、どの他のセッション１０２を開くか、等）に先験的に合意する場合にのみ実行できる。
実際には、多くの場合、ユーザはこれらの制約を局所的に実施し、この情報を自分のピアに開示することはない。これらの制約を、所定のピアのセット全体に亘って実施できる唯一のケースは、第三者制御ユニット、会議制御ユニット（Conference Control Unit）が提供される際のみである（一般には、オンライン会議シナリオの場合）。
要件２８：Ｅ２ＥＮＰ９０８は、代替的な意見としてのＱｏＳコンテキストに関連して示されたグループ適用経路（Group adaptation path）（ＧＡＰ）を特定及び前交渉するメカニズム及び手段を含む。
要件２９：所定のＧＡＰ内の各ＱｏＳコンテキストは、ＱｏＳ関連制約８０４及び／又は時間同期制約８０５に関連したメディアストリーム２０６のグループを示す。
要件３０：Ｅ２ＥＮＰ９０８により、ＱｏＳコンテキスト内での如何なる所定のＧＡＰのラッピングが可能になるため、上記ＧＡＰの全ての構成エレメントにかけて、交渉ＱｏＳ関連制約８０４及び／又は時間動機制約８０５の交渉が可能になる。
要件３１：Ｅ２ＥＮＰ９０８により、用件２８、２９の再帰的な使用が可能になる。
一般に、再交渉処理８０８には、申込者９１４、１又は複数人の回答者１０６ａ２が関与し、また、１回ベース又は反復ベースで実行することができる[Loyal]。
申込者９１４は、回答者１０６ａ２にビッドを提供し、回答者１０２ａ２がこれを検証し、カウンターオファーを申込者９１４へ戻す。申込者は、カウンターオファーを収集し、関与する全てのパーティの要件を満たすものを決定する。このような最適なカウンターオファーが取り出されると、申込者９１４が、これを新たなビッドとして各回答者９１１へ送信する。
反復スキームにおいて、回答者９１１の１人が新たなビットを未だ受け取っていない場合には、この処理を、この時点で再開することができる。しかしながら、反復アプローチは、反復の上限により制約されなけらればならず、また、いずれの場合においても相当に複雑且つ非効率的である。
１つの通信パーティによる変更の発生は、関与している他のパーティの接続に影響しないかもしれないため、マルチパーティ接続シナリオによる再交渉８０８は、１対１再交渉８０８によるもの等のシングルベースの可能性によって為され、すなわち、あるピアがその接続による問題を検出しても、他のピアにも接続上の問題があるわけではない。したがって、メディアストリーム接続によって、個々のメディアストリーム２０６をシングルベースで再交渉し、必要なシグナリングの量を最小化することがよい。更に、この再交渉８０８がグループのコンテキストに影響しない場合には、あるグループのメディアストリーム２０６（依存性メディアストリーム２０６）も、シングルベースで再交渉することができる。
要件３２：Ｅ２ＥＮＰ９０８は、基本的な、非反復的な前交渉８０２、交渉８０６、再交渉８０８スキームを実行する。
要件３３：Ｅ２ＥＮＰ９０８は、第三者制御ユニット（例えば会議制御ユニット）を使用することによってのみ、より複雑な交渉８０６スキームを許可することができる。
要件３４：一般に、Ｅ２ＥＮＰ９０８は、セッション１０３に関与するエンドピア間のみにおいて、前交渉８０２、交渉８０６、再交渉８０８を実行するために使用されるべきである。サービスに特化した理由からこの要件が適切でない場合には、要件３１が優先する。
要件３５：複雑な交渉８０６シナリオ（例えば会議）により、Ｅ２ＥＮＰ９０８処理に携わっているエンドピアは、既に前交渉したＱｏＳ契約１１０８と、幾つかの登録サービス内のユーザプロファイル情報を発行し、これにより、後に参加するパーティに、短い交渉８０６処理を許可することができる。
要件３６：グループの単一のメディアストリーム２０６がグループのコンテキストと矛盾しない場合には、これを再交渉し、再交渉８０８のためのシグナリングを最少にできなければならない。
要件３７：メディアストリーム２０６が他のメディアストリーム２０６と関連する場合には、関連するパーティが、影響を受けた全てのパーティとの再交渉８０８に責任を負わなければならない。
そこで、受信側が受信を希望するＱｏＳレベルを特定できるようにする交渉８０６の原理（rationale）が提案される。この提案と最新の傾向（例えばＳＤＰ／ＳＤＰｎｇ９１２）との間の相違点は、後者が、主に、ＱｏＳ交渉８０６ではなく、能力交渉８０６に注目していることである。例えば、ＳＤＰとＳＤＰｎｇ９１２の両方により、送信側は、送信側が送信のために使用しようとしているフォーマットに関する情報及びトランスポート情報を受信側（１又は複数）に送信することができる。
Ｅ２ＥＮＰ９０８をこの周知のアプローチと一致させようとすることにより、上述の原理を以下の通り緩和することができる。送信側と受信側の両方が、メディアストリーム２０６レベルで送信／受信したいＱｏＳレベルを特定することができるが、受信のために実行したいＡＰｓ／高レベルＱｏＳレベルを特定できるのは受信側のみである。これは、受信側が、複数の受信したメディアストリーム２０６間におけるＱｏＳ関連８０４及び時間同期８０５制約に留意する傾向にあり、その一方で、これは、送信側にとっては概して重要でないためである。
要件３８：Ｅ２ＥＮＰ９０８は、送信側と受信側の両方、及び送信側／受信側に、どのＱｏＳレベルをメディアストリーム２０６レベルで送信／受信したいかを特定することを許可する。
要件３９：Ｅ２ＥＮＰ９０８は、受信側、送信側／受信側のみに、受信したいＡＰ／高レベルＱｏＳレベル（すなわち、ＱｏＳ関連８０４、時間同期８０５制約）特定することを許可する。
しかしながら、メディアストリーム２０６間で、ＱｏＳ関連８０４と時間同期８０５制約を送信側に特定させるこの提案の拡張には、更なる研究を要する。
ピアは、接続確立時においてだけでなく、ＱｏＳ違反が発生した場合には常に、交渉したＱｏＳ仕様を効果的に実行する特定の手順を追うことができる。
これに関連して、[BRAIN]は、全てのエンドポイントにおいてリソースが予約されるまでネットワークリソース予約を待つという状態を避けるために、ローカルリソース及びネットワークリソースの実際の予約を調整する。より正確には、本願明細書中では、経済原理という用語を、ケー・ナーステッド（K. Nahrstedt）、ジェイ・スミス（J.M. Smith）著「ＱｏＳブローカ（The QoS Broker）」（ＩＥＥＥマルチメディアマガジン（IEEE Multimedia Magazine）、１９９５年春（２）１、５３〜６７頁）（以下、[Nahr95]という。）に記載の予約の順序を記述するために使用している。
したがって、最終ステップにおいてより高価なリソースを予約するための経済原理により、上述したＱｏＳ前交渉８０２、ＱｏＳ交渉８０６、ＱｏＳ再交渉８０８処理の質問が提案される。ネットワークリソースは数人の顧客間で共用されており、また、一般には、１人が他の顧客の分の支払いをしなければならないため、最初に、全ての端末装置上でリソースを予約し、その後、最終ステップとして、リソースネットワークをリソースする方がよい。
したがって、動作のシーケンスは以下のようになる。
１．最初に、ローカルリソースを予約する。
２．次に、ピアエンティティとの交渉８０６により、ピアのリソース要件にマッピングできる構成が得られ、その後、これが予約される。
３．最後に、ネットワークリソースは高額であり、複数のユーザ間で共用されるため、最終ステップにおいて、ネットワークリソースの予約が行われる。
要件４０：Ｅ２ＥＮＰ９０８は、分散リソース管理の調整を実行するメカニズム及び手段を提供する。
要件４１：「経済原理」によれば、ピアにおけるリモートリソースは、ローカルリソースの予約が成功した後のみに予約される。
要件４２：「経済原理」によれば、ネットワークリソースは、全てのピアにおいてローカルリソースの予約が成功した後のみに予約される。
３つ以上のピア間で、上述の「経済原理」に基づいて、ローカル、ピア及びネットワークのリソース予約を正確に調整するためには、特別な注意を払いながら、整合性を提供し（これにより、より有利にリソースを使用できるようになる）、デッドロックを回避し、関連するプロトコルの特定を行う必要がある。整合性により、より有利にリソースを使用することが可能になる。
このセクションの残り部分では、これらの要件を動機付ける２つの具体的なシナリオを説明する。まず、この具体例に適用される一般的な必要条件を説明する。これらの必要条件は、問題範囲を説明するものである。しかしながら、シナリオの適用性を制限するものではない。
次に、各々が同一のビデオコーデックを装備した３つの同等な端末装置を仮定する。端末装置は、各々が、送信又は受信のいずれかのために毎秒２５個のフレームを管理できる処理パワーを備えている。
すなわち、ＣＰＵパワーにより、送信モード（捕捉、圧縮、パケット化、送信）、又は、受信モード（パケットの受信、リアセンブル、解凍、レンダー）のいずれかにおいて２５Ｆｒ／ｓの処理が可能になる。しかしながら、端末は、送信と受信を同時に行う十分なリソースは備えていない。
更に、リソース消費は、毎秒毎のフレームの個数と共に直線的に位取りされる。その一具体例として、端末装置は、メディアストリーム２０６を１０Ｆｒ／ｓで送信すると同時に、他のメディアストリーム２０６を１５Ｆｒ／ｓで受信するため、合計２５Ｆｒ／ｓでの処理が可能である。
図６に示す、３つのピア６０２ａ〜６０２ｃ（Ａ、Ｂ、Ｃ）との交渉８０６シナリオのための対話ダイアグラムは、整合性の提供が必要な理由を示している。これにより、１５Ｆｒ／ｓのフレームレートでメディアストリーム２０６をピアＢに送信するピアＡを管理するために、ピアＡが、時間ｔ０において、ピアＢとの交渉８０６を開始すると仮定される。
ピアＡが、１５Ｆｒ／ｓの処理のために、ローカルリソースの予約に成功し、２０Ｆｒ／ｓを消費する、既に継続中である、他のピアとの類似のセッション１０２を備えるピアＢに交渉８０６要件を送信する。これにより、ピアＢが、入力されるメディアストリーム２０６を処理するために、５Ｆｒ／ｓのリソースを予約するが、これは、これがサポートできる限度だからである。この情報がピアＡへ搬送されて戻ると、ピアＡは、交渉した５Ｆｒ／ｓのフレームレート値を維持するために、予約しておいたリソースを解放し、その後、時間ｔ１において、５Ｆｒ／ｓと同等のネットワークリソースの予約を開始する。
ネットワーク６０４が制限因子ではなく、最終的に、ピアＡ、ピアＢ、ネットワーク６０４が、所定のセッション１０２について５Ｆｒ／ｓを維持できると仮定する。ｔ０とｔ１の間の任意のポイントにおいて、ピアＣがピアＡとのセッション１０２を作成したいと要求したと仮定した場合、ピアＡは、ピアＣに、局所的な１０Ｆｒ／ｓ（＝２５Ｆｒ／ｓ〜１５Ｆｒ／ｓ）を許可させることしかできない。
しかしながら、ピアＡは、ｔ１後の時間の任意の時点において、ピアＣから要件を受信すると、ピアＢに課した制約のために第１のセッション１０２のリソース要件が低下する理由から、少なくとも２０Ｆｒ／ｓ（＝２５Ｆｒ／ｓ〜５Ｆｒ／ｓ）で、ピアＣとの新たなセッション１０２を許可できるようになる。
このシナリオから、２つのピア間でローカル、リモート、ネットワークリソースを管理する任意のこのようなプロトコルが、継続中の電気通信セッション１０２の確立に成功するまで、他のピアからのリソース要件のための要請を扱わないという要件を導出することができる。この要件が、整合性と呼ばれる。
要件４３：Ｅ２ＥＮＰ９０８は、複数のピア間で、「経済原理」の整合性アプリケーションを実行する。
図７に示した通りの、２つのピア６０２ａ、６０２ｂ（Ａ、Ｂ）間の交渉８０６シナリオのための対話ダイアグラムは、デッドロックの回避が如何に必要であるか、すなわち、なぜＥ２ＥＮＰ９０８がホールドアンドウェイトのない状態を確保しなければならないか、又は、このような状態が限られた時間にのみ発生するようにしなければならないかを示している。ピアＡが、ビデオメディアストリーム２０６を、２５Ｆｒ／ｓでピアＢに送信したいと仮定する。
時間ｔ０において、ピアＡが、ローカルリソースを予約し、交渉８０６要件をピアＢへ送信し、ピアＢが時間ｔ２においてこの要件を受信する。その一方で、ピアＢは、メディアストリーム２０６をピアＡに送信するために、時間ｔ１においてリソースを予約する。ピアＡが、時間ｔ３において、この要件を受信する。
これにより、ピアＡは、時間ｔ０において開始するピアＢからの応答を待ち、一方、ピアＢは、時間ｔ１において開始するピアＡからの応答を待つ。その結果、両方のピアが、時間ｔ２（ピアＢ）、時間ｔ３（ピアＡ）において、それぞれのローカルリソースの予約を試みた場合、両方とも失敗する。
このシナリオから、２つのピア間で、ローカル、リモート、ネットワークリソースを管理する任意のプロトコルは、デッドロック状態を回避するか、又は、少なくとも、これらを限られた時間だけ発生させ、その後、いずれの場合でも、プロトコルを復元できるようにするという要件が導出される。
要件４４：Ｅ２ＥＮＰ９０８は、如何なる所定の時間に、「経済原理」のアプリケーションによってデッドロック状態が起こらないようにする。
要件４５：Ｅ２ＥＮＰ９０８は、復元メカニズムが、「経済原理」の発生し得る衝突アプリケーションに対処するために、適所に配置される。
一般に、エンドピアは、相互接続したネットワーク６０４の１つ又は複数にかけて接続されており、更に、その間に中間コンポーネントを設けている。
要件４６：Ｅ２ＥＮＰ９０８は、基本的なネットワーク６０４の抽象化に基づいて動作しなければならない。
中間コンポーネントは、後にピアがＥ２ＥＮＰ９０８を介して交渉する情報に影響を与えるだけでなく、Ｅ２ＥＮＰ９０８処理の結果を実現するサービスを提供する。
中間コンポーネントは、エンドピアが行った決定について知らされなければならない。中間コンポーネントに通知する方法は、Ｅ２ＥＮＰ９０８の開始前に何らかの標準プロファイル情報により該コンポーネントをサポートする、及び／又は、何らかの登録サービス上で合意したＱｏＳ契約１１０８を発行することによるものである。
要件４７：Ｅ２ＥＮＰ９０８は、中間コンポーネントと組み合わせて（しかしながら、中間コンポネントからは独立して）使用することができなくてはならず、これにより、エンドピアが合意したＱｏＳ契約１１０８を準備及び／又は保障する上で効果的な結果が得られる。
要件４８：Ｅ２ＥＮＰ処理に直接影響することはなく、むしろ、これから更新する情報に影響する情報（例えば、プロファイル、セキュリティ、承認、プロバイダポリシ等）の交換が、Ｅ２ＥＮＰ９０８の開始前に実行されるべきである。
要件４９：Ｅ２ＥＮＰ９０８の開始前に実施される任意の交渉８０６は、整合性を確保し、デッドロックを回避するために、モジュラー及び制御された方式で実行されなければならない。
一般に、フローは、Ｅ２ＥＮＰ９０８を伝送するＥ２ＥＮＰ９０８（シグナリング経路）と、実メディアストリーム２０６を伝送するフロー（データ経路）は、ネットワーク関連の問題のみでなく、アプリケーション／サービスに特化した理由に依存し、別個にルーティングすることができる。
要件５０：任意の２つの所定のエンドピア間におけるＥ２ＥＮＰシグナリング経路と関連するデータ経路は、概して、別個の物として考慮される。
シグナリング経路及び／又はデータ経路が構築される度に、中間コンポーネント（ルータ、プロキシ等）が経路に沿って配置されるが、これらの使用はアプリケーションスペシフィックであり、エンドピアが使用するプロトコルを部分的に理解することができる。これらのエンティティは、Ｅ２ＥＮＰ９０８とも「干渉」する立場にあり（例えば、ＳＩＰ９１０がこれを可能にする）、これにより、Ｅ２ＥＮＰ９０８の非常に「エンドツーエンドな」性質が妨害される。
この危険を回避するために、次の要件が、中間コンポーネントを、Ｅ２ＥＮＰ９０８に関連して常に静的であるように強制する。
要件５１：Ｅ２ＥＮＰ９０８に関連し、中間コンポーネントは、アプリケーションスペシフィックなタスクを実行するために、ピアによって（直接又は間接的に）提供された情報に基づいて動作する。
例えば、これは、Ｅ２ＥＮＰ９０８メッセージ内に、Ｅ２ＥＮＰ９０８処理中に中間コンポーネントがＥ２ＥＮＰ９０８のコンテンツを絶対に変更すべきでない旨を示す明確な注釈を追加することで達成できる。又は、登録サービスに先行して、幾つかのＥ２ＥＮＰ関連の情報を発行し、後に、中間コンポーネントが、動作の計画のためにこの情報に質問することでも達成できる。
ユーザにより定義されたオーディオの品質を、エイチ・シュルツリン他著「最少の制御での、オーディオ及びテレビ会議のためのＲＴＰプロファイル（RTP Profile for Audio and Video Conferences with Minimal Control）」（コロンビア大学、未完成（Columbia University, work in progress）、<draft-ietf-avt-profile-new-09.txt>）（以下、[RTP-Profile]という。）に記載されているコーデックの標準のペイロードタイプ定義に基づいてコーデックに適用しなければならない場合、１つの特定的な品質を、この品質を表している１つのペイロードタイプのみにマッピングできる。
オーディオの品質と能力（ペイロードタイプ）の間には一意の１対１マッピングが存在する。
その一方で、単一のビデオコーデックは、複数の品質を生成することができる。圧縮したビデオの品質は、エンコーダ（コーデック）に送信された通りの品質を示す。これは、単一のフレームの全体的なビジュアル品質を表す。すなわち、ユーザによって定義された何らかの品質をビデオに適用することによって、この品質を、ビデオコーデックの性能の圧縮割合として定義することが可能である。更に、ジー・フランクハウザー（G. Frankhauser）、エム・ダーセン（M. Dasen）、エヌ・ウィーラー（N. Weiler）、ビー・プラットナー（B.Plattner）、Ｂ．スティラー（B. Stiller）著「適応無線ビデオへの統合アプローチ（An Integrated Approach to Adaptive Wireless Video）」（ＡＣＭ Ｍｏｎｅｔ、適応性モバイルネットワーキング及びコンピューティングの特別版（ACM Monet, Special Issue on Adaptive Mobile Networking and Computing）、１９９８年）（以下、[WAVI]という。）に記載されているように、幾つかのコーデックについて（例えば、ＷａｖｅＶｉｄｅｏ、フォーマット名称−「WAVI」）が、単一のフレームのクロミナンス平面の全体的なビジュアル品質を特定することが可能になり、これにより、全体輝度品質と色品質を区別することが可能になる。更に、色品質は、割合としても表すことができる。異なるビデオコーデックは、異なる数の圧縮レベルを有する。ユーザが視覚的に感知可能な品質を特定する場合、この品質は、ビデオコーデックの圧縮レベルを表す数に一意にマッピングされなければならない。ユーザが、感知可能な品質を数、又は数の範囲として特定する場合、この設定は、コーデックの特定の圧縮レベルに一意にマッピングするのに十分な解像度であるはずである。そのため、ビデオ品質設定に関連した２つの要件を定義することができる。
要件５２：ユーザによる感知可能な品質（色品質が使用可能である場合、全体的なビジュアル品質、色品質）の特定のためのナンバリング範囲は、ビデオ品質を所定のコーデックに一意にマッピングできるようにするために、アプリケーション及びＥ２ＥＮＰ９０８にとって一意に理解可能でなければならない。
要件５３：ユーザによる感知可能な品質（色品質が使用可能である場合、全体的なビジュアル品質、色品質）の特定のためのナンバリング範囲は、所定のコーデックの圧縮レベルに一意にマッピングするのに十分な解像度を有していなければならない。
ピアは、ＱｏＳ再交渉８０８を扱う際には常に、リソース管理ポリシを再交渉することによって、リアルタイム時における不安定性を回避する必要がある。
あるいは、例えばテレビ会議１２０４ａ／ｂに参加している２又は複数のピアが、同一の所有権リソース管理ポリシに違反するリソースの使用を検出する場合には、各ピアが独立して行る決定が、他のピアが共同して試みる決定と矛盾する形で、残りのピアに影響を与える可能性がある。これにより、リソース構成スペース内に「震動」が生じることによって、システム全体性能とユーザが感知したＱｏＳに衝撃が生じる。
同じ理由から、送信側のみが、再交渉８０８処理を起動する決定を行うことができる。しかしながら、これに併発して、受信側が、リソース能力の低下を検出した場合には、受信側は、再交渉８０８を起動することができ、更に、この処理を継続する権利を送信側のみに許可することによって、他のピア（送信側を含む）との任意の偶発的な衝突が解決する。
これに関連して、交渉８０６が合意できる、上手く定義されたリソース管理ポリシのセットの定義が提案される。このようにすることによって、ピアは、依然として、リアルタイムに、調整された方法で自体のリソースを独立して管理することができる。
このようなポリシは、少なくとも、以下に示す態様の任意の論理的組合せを網羅しなければならない。
・メモリリソースの最適化
・処理パワーの最適化
・ネットワークリソース性能の最適化
・電力消費の最適化
より詳細には、電力消費の最適化は、これ以外の全てのリソースタイプ、例えばメモリスワップドメインパワーの管理と関連する。
あるポリシが、電力消費の使用の明確な最適化を特定しない場合には、このポリシは、電力にそれ程注意を払うことなく、他のリソースタイプの仕様を最適化する（これは、電力以外の任意タイプのリソースを最適化する十分な電力が得られる、例えば、主電源に永久的に接続したデスクトップＰＣの場合に意味を為す）。
あるポリシが電力消費を明確に特定しない場合には、このポリシの規準が他の全ての最適化規準に影響する。
交渉したＱｏＳ契約１１０８により課された条件とリソース管理ポリシが一致する限り、ポリシを使用することによって、アプリケーション及び／又はミドルウェアが、独自の適応決定を柔軟に行うことができる。したがって、ＱｏＳ契約１１０８の優先順位の定義と交渉８０６は不要である。更に、コーデック／能力の優先順位の定義と交渉８０６も不要である。このような優先順位付けを行う理由は、実際、コーデック等の能力がそれぞれ異なったリソース消費を行うためである。更に、他よりも概して性能が低いコーデックであっても、特定の構成と共に使用する場合には、リソース使用を有利に最適化することができる。
要件５４：Ｅ２ＥＮＰ９０８は、リソース管理ポリシを特定及び前交渉するメカニズム及び手段を提供する。
要件５５：リソース管理ポリシは、メモリリソースの最適化、処理パワーの最適化、ネットワークリソース性能の最適化、電力消費の最適化の任意の論理的組合せを含むが、これに限定されるものではない。
要件５６：Ｅ２ＥＮＰ９０８を使用するアプリケーション及び／又はミドルウェアは、前交渉したリソース管理ポリシ及びカレントリソース能力に基づいて、コーデック／能力のリストに独立的に優先順位を付ける。
動的な通信環境には、データ接続の確立及び管理による適応性だけでなく、更に、交渉８０８、８０９の実行による適応性が必要である。図１は、ピアツーピアデータ接続が「第三者によって支援」されている、交渉１対１通信シナリオ１００の交渉８０８、８０９の特別なケースを示す。このタイプの交渉８０６は、登録、割当、プレゼンス等のサービスの使用を利用することができ、これにより、ユーザのＱｏＳへの要件と、ユーザの付近にある複数の装置の検出及び使用する可能性とをより完全に満たすことが可能になる。
交渉８０６を開始することによって、呼出側装置は、その呼出を取り扱うことが不可能であることを検出する。この装置が適応できないため、その呼出は単純に実現しない。ピアの能力を変更することなく、このケースに適用できるあるタイプの適応は、ユーザのプロファイル定義に基づいて、呼出を他のピアに委譲するというものである。ここでは、このような機能を仲介者１０６ａ１と呼び、他のピアの代わりに交渉するピアの能力を事前設定したユーザプロファイル定義に記述する。このタイプの交渉８０９は、「第三者援助交渉」と呼ぶ。仲介者１０６ａ１は、２つのピア間の実際に交渉８０９に参加するが、データの接続には役割を担わない。仲介者１０６ａ１は、データ接続に活発に参加しなければならない場合には、ブリッジ機能が更に必要であり、このブリッジ機能は、場合によっては、変換（transcoding）が必要となり、マルチパーティ接続に達し、その交渉８０９が必要となる。データ経路上に配置された仲介者１０６ａ１の更なる問題は、装置に欠点が生じ、これにより、必要なＱｏＳをサポートする可能性に悪影響が及ぶことである。これらの問題を考慮すると、このようなタイプの適応性は、全てのピア（仲介者１０６ａ１を含む）が、その能力プロファイル（例えばデバイスビットレートスループット）に関する情報を交換する場合のみに実行することができ、すなわち、マルチパーティ接続を交渉しなければならないということであり、これについては後述する。したがって、交渉８０９のケースについては、仲介者１０６ａ１がデータメディアストリーミングに参加しない方法での仲介が考えられる。
申込者１０６ｂが、装置が扱えない呼出を発行する際に、仲介者１０６ａ１の促進機能が起動される。この場合、仲介者１０６ａ１は、更に、ユーザに通知し、委譲状態の受理について質問することにより、適切な回答者１０６ａ２を探し、その呼出を委譲する。その結果、申込者１０６ｂと回答者１０６ａ２が、お互いに関するプロファイル情報を仲介者１０６ａ１上で受信し、これにより、後の、申込者１０６ｂと回答者１０６ａ２間における検出と、直接交渉８０６処理とが高速化される。
仲介者１０６ａ１の機能は、その機能能力をサポートする追加のサービスを使用できなければならない。このようなサービスの特定のアプリケーションは、本願明細書の範囲外であるため、ここでは、その使用の利点と、Ｅ２ＥＮＰ９０８がどのように影響から保護されるかについてのみ確認する。
仲介者１０６ａ１は、仲介が行われている、１つ（申込者１０６ｂ）又は他の（将来の回答者１０６ａ２）パーティに未知であるセッション情報１１２を参照しないよう注意する必要がある。複数のセッション１０３に関する情報がミディエタ１０６ａ１を呼び出すことでのみ参照されるが、メッセージ内に明確に含まれない場合に、仲介者１０６ａ１が、ピアから入力されるセッション情報１１２を後に再構築することによって、促進化を図る。これにより、仲介者１０６ａ１が、促進課が実行されているパーティによる、セッション１０２に関する情報のセット１１２を完成する注意を払う。仲介者１０６ａ１は、セッション情報１１２のコンテンツを変更することはしないが、その呼出に完全な記述部分を追加して、他の交渉パーティ１０６ｂ、１０６ａ２による情報のセットをまとめる。
要件５７：第三者支援交渉８０６により、純粋な仲介者１０６ａ１は、接続の委譲を、これに活発に貢献することなく、促進するだけでなければならない。
要件５８：仲介者１０６ａ１は、登録、割当、プレゼンス等のサービスの使用を利用することができ、また、その情報は、Ｅ２ＥＮＰ確認メッセージの形成のみに使用できるが、Ｅ２ＥＮＰ９０８の構造及び性能には影響しない。
要件５９：仲介者１０６ａ１は、情報のコンテンツを変更することなく、しかしながら、これを促進化の必要性に合わせて再構築することによって、古い、リフレッシュされたものから新たなセッション記述１１２を生成できなければならない。仲介者１０６a１は、未知の参照を含まない完全なセッション記述１１２の送信を取り扱えなければならない。
欧州特許出願第ＥＰ０１１２２３６６．６号明細書では、総体的なＥ２ＥＮＰ概念、その要件、その可能な実現が開示されているが、最新の技術に関する実現の詳細については何ら開示されていない。時間内での前交渉した情報の達成は全くない。
最新型のＳＤＰｎｇ[SDPNG03]はモジュラー方式で構築されているが、Ｅ２ＥＮＰアスペクトを考慮しておらず、また、異なるＳＩＰ（又は他のプロトコル）メッセージにかけて、モジュラー方式で使用することができない。ＳＤＰｎｇはＳＤＰ提供／応答モデルに基づいており、Ｅ２ＥＮＰの範囲において提案されているもの等の、複雑なマルチフェーズ交渉処理は明確に考慮されていない。
欧州特許出願第ＥＰ０１１２２３６６．６号明細書、ＳＤＰｎｇのいずれにも、ユーザプロファイル情報を、全体的なＱｏＳ交渉処理の入力として考慮できる処理は提示されていない。
基本的な本発明の目的
上述した説明を考慮すると、基本的な本発明の目的は、基本的なモバイル無線チャンネルの時間依存性のリンク特徴に動的に適応する無線ネットワークに接続した、モバイル端末上で実行されている適応的なリアルタイムサービスとマルチメディアアプリケーションのために、ＱｏＳ管理とリソース予約メカニズムをサポートする方法を提案することである。したがって、上記端末の保証されたエンドツーエンド品質を提供するために、実際の通信が実施される前に、ピアが、能力、量、適応メカニズムの共通のセットを前交渉することを可能にする、ローカル、ピア及びネットワークのリソース管理の統合性及び調整に基づく概念が実現される。
この目的は、独立請求項の特徴の手段により達成される。利点的特徴は従属請求項に定義される。本発明のさらなる目的及び利点は、以下の詳細な説明において明白になる。
基本的な本発明は、基本的に、階層ＱｏＳ契約規格（例えば、関連するメディアストリームに対するＱｏＳ契約の様々なセットに亘る強い関連）を、交渉情報を導出するために実行及び使用できる方法で、ユーザプロファイルと端末能力情報を定義するモデルに関する。この概念の実現の参照として、本発明は、エンドツーエンドＱｏＳ交渉プロトコル（Ｅ２ＥＮＰ）概念を実現するために、拡張可能マークアップ言語（ＸＭＬ）に基づいたセッション記述プロトコル次世代（ＳＤＰｎｇ）仕様と共に、インターネット技術標準化委員会（ＩＥＴＦ）によって規定されたセッション開始プロトコル（ＳＩＰ）の新規な使用方法について説明する。
より詳細には、ここでは、以下を可能にすることによって、ＳＤＰｎｇ交渉メカニズムを拡張するモデルを提案する。
−補助情報の異なる部分を含んだＳＤＰｎｇのセクションは、Ｅ２ＥＮＰの様々なフェーズにおいて送信され、交渉フェーズを完成することにより、フル交渉画像の形成を可能にし、この場合、ＳＤＰｎｇ記述内で各フェーズが明確に記述されている。
−前交渉フェーズに使用される上記セクションのいくつかについて、時間フレームを実現することによって、古い情報が後に間違って実行されることを回避する。
請求項の簡単な説明
独立請求項１と、従属請求項２乃至１２は、電気通信セッションに保証されたエンドツーエンド品質を提供する、エンドツーエンド交渉プロトコル（Ｅ２ＥＮＰ）の範囲において必要とされる概念を実現するセッション記述プロトコル次世代の拡張を参照しており、上記拡張では、基本的なモバイル無線チャンネルの時間変化的なリンク特徴に動的に適応するために、無線ネットワークに接続したモバイル端末上で実行中のマルチメディアアプリケーションが関与している。これに関連して、上記概念は、ピアが、実際通信の実施前に、能力、品質、適応メカニズムの共通のセットを前交渉することを可能にする、ローカル、ピア及びネットワークのリソース管理の統合及び調整に基づいている。
次に、従属請求項１３乃至４９は、保証されたエンドツーエンド品質を電気通信セッションに提供する、エンドツーエンド交渉プロトコル（Ｅ２ＥＮＰ）の範囲において必要とされる概念を実現する方法に関する。これにより、上記ＳＤＰｎｇを、Ｅ２ＥＮＰについて入力を導出するために使用されるユーザプロファイル情報を定義するために適用することが可能になる。
これに加え、独立請求項５０はエンドツーエンド交渉プロトコル（Ｅ２ＥＮＰ）に関連しており、この場合、共通レベルの代のＱｏＳと能力を前もって確立するために、代のＱｏＳアスペクトと能力をエンドツーエンドベースで前交渉することにより、ＱｏＳ使用可能な電気通信セッションが確立され、この使用には、電気通信セッションの全てのピアが合意することができる。
更に、従属請求項５１は、保証されたエンドツーエンド品質を電気通信セッションに提供する、エンドツーエンド交渉のためのブローカに関連する。これにより、上記ブローカは、前交渉フェーズと、任意で、請求項３５によるマルチストリームの時間同期フェーズ及びＱｏＳ関連フェーズを実行することから、ネットワークのピアを解放できるようになる。
次に、従属請求項５２は、コンピュータによって実行する際に、請求項１３乃至４９のいずれか１項による方法を実現するソフトウェアルーチンを参照する。
更に、従属請求項５３乃至６１は、請求項１３乃至４９のいずれか１項による方法を実現するために構成されたピアに関し、このピアは、分散リソース管理処理の、交渉処理の様々なフェーズを調整する調整ユニットを備えている。
最後に、従属請求項６２は、代のＱｏＳ及び能力の共通レベルを予め確立する代のＱｏＳアスペクト及び能力をエンドツーエンドベースで前交渉することによって確立した電気通信セッションに保証されたエンドツーエンド品質を提供するプロトコルに関し、その使用には、電気通信セッションの全てのピアが合意することができる。また更に、能力の交渉と再交渉には、選択したコーデック及びその構成のシグナリングが含まれる。
基本的な本発明の更なる利点及び可能な使用は、従属請求項、及び、以下に示す、図面に示した上記発明のある実施形態の説明から明白になる。
以下、図１〜図１３を参照して、基本的な本発明の好ましい実施例を詳細に説明する。図１〜図１３における指示符号の意味を、表３に示す。
１．Ｅ２ＥＮＰ９０８の概念と、これにより提案されるその拡張の概念とを実現するＳＤＰｎｇ９１２の拡張は、特に、以下の通りである。
−ＳＤＰｎｇ（９１２）コンテンツは、ユーザプロフィール情報から導出することができ、これはＥ２ＥＮＰ（９０８）の入力として使用される。
−ＳＤＰｎｇ（９１２）コンテンツは、端末能力情報から導出することができ、これはＥ２ＥＮＰ（９０８）の入力として使用される。
−単一の又はグループのメディアストリームのＱｏＳアスペクトを詳述する新たな２つのＳＤＰｎｇセクションを導入する。
−セクションのモジュール使用：異なるＳＤＰｎｇ（実際のＳＤＰｎｇ９１２草案及び新たに提案されている）セクションを、Ｅ２ＥＮＰ９０８プロトコルの様々なフェーズにおいて交換することができる。
−Ｅ２ＥＮＰ９０８の各フェーズにおいて、各ＳＤＰｎｇコンテンツを明確に識別するタグ（tag）を追加し、ＳＤｐｎｇコンテンツが、実際に、ＳＩＰ９１０又は類似のプロトコル（例えばＳＣＣＰ）上でピギーバッグされるＥ２ＥＮＰ９０８のプロトコルデータユニットとなる。
−有効性をタイムリーに制限するために、Ｅ２ＥＮＰ９０８がリースによってＳＤＰｎｇ情報を前交渉する。
−ＩＰｖ４の完全なサポートを越えて、異なる種類のネットワーク６０４アドレスを指定するために、ＳＤＰｎｇ９１２サポートを拡張する。
２．Ｅ２ＥＮＰ９０８の拡張は、以下の通りである。
−Ｅ２ＥＮＰ９０８の入力として使用されるユーザプロファイル情報を定義するためにＳＤＰｎｇ９１２を使用する。
−Ｅ２ＥＮＰ９０８の入力として使用される端末能力情報を定義するためにＳＤＰｎｇ９１２を使用する。
−ピギーバックによって、Ｅ２ＥＮＰ９０８をＳＩＰ９１０プロトコル上に詳細にマッピングする。
前章において述べた要件を満たすために、エンドツーエンドＱｏＳ交渉プロトコル（Ｅ２ＥＮＰ９０８）と呼ばれる新たなプロトコルを提案する。
Ｅ２ＥＮＰ９０８の概念を説明する前に、上述したアクタ（actor）及びシナリオ（scenario）の総称的な説明を完了する重要な前提条件（assumption）ついて説明する。
単純な１対１の通信シナリオ８００
通信モード（プッシュ（push）、プル（pull）、及びプッシュ／プル（push-pull））は、送信側（sender）及び受信側（receiver）に関する状態及びアプリケーションに依存して用いることができる。以下、モードの標準的な使用について説明する。
・申込者８１０に、回答者８１１のプロファイルの外見についての知識がない場合には、申込者８１０は「プル」モードを使用して、まず、回答者８１１の設定を検索し、次に、申込者８１０の独自の設定に適合させる。
・申込者８１０に適合する可能性がない場合には（又は、これ以外の理由がある場合）、申込者８１０は自分の設定を回答者８１１に「プッシュ」することができ、これによって、「プッシュ」モードを使用して自己を強制的に適合させることができる。
・両者側における適合が必要な場合には、「プッシュ／プル」モードを使用して、申込者８１０の提案の３方向交換を使用可能にすることができる。このモードは、双方向通信に合意するために使用できる。
「受信側」が所定の「送信側」にチューニングしなければならないという仮定から、「送信側」は適合者ということになる。「送信側」が所定の「受信側」と一致する場合には、適合は「送信側」によって実施される。
単純な１対１通信シナリオ８００の場合には、どちら側が申込者８１０で、どちら側が回答者８１１であるか、また、どちら側が送信側又は受信側であるか、両者が送受信の両方を実施できるかについて考慮する３つのシナリオが存在する。
・送信側（申込者８１０）−受信側（回答者８１１）
一般に、このシナリオには、適合の可能性と、送信側及び／又は受信側の規則に基づいて、「プッシュ」モード及び「プル」モードの両方を使用することができる。申込者８１０が適合者の場合には、申込者は「プル」モードをするか、あるいは「プッシュ」モードが使用されるべきである。「プッシュ／プル」モードの使用も適合するが、予想される１方向データメディアストリーム２０６により、シグナリングプロトコルが複雑化し、Ｅ２ＥＮＰを簡略化する必要性と矛盾してしまうだけである。
・受信側（申込者８１０）−送信側（回答者８１１）
この場合にも、適合の可能性と、送信側及び／又は受信側の規則に基づいて、「プッシュ」モードと「プル」モードの両方を使用することができる。申込者８１０が適合する側である場合には、申込者１０６ｂが、「プル」モードを使用するか、あるいは「プッシュ」が使用されるべきである。ここでも、「プッシュ／プル」の使用は、上述したシナリオと同じ理由から推奨できない。
・送信側−受信側（申込者８１０）又は送信側−受信側（回答者８１１）
全員がメディアストリーム２０６を送信及び受信しようとした場合には、申込者８１０が所定の回答者８１１に招待を発行する前に、申込者８１０が、回答者８１１の受信能力及びＱｏＳの希望に関する情報を収集する。
この場合、招待時間によって、申込者８１０が、以下を含む提案を回答者８１１に送信することができる。
−申込者８１０の、メディアストリーム２０６を送受信する能力に関する情報
−回答者８１１の好みに合わせた、申込者８１０が所望する、メディアストリーム２０６を受信する独自のＱｏＳ品質仕様
−回答者８１１の好みに合わせた、メディアストリームを送信するＱｏＳ提案。
次に、回答者８１１が申込者８１０に対して、申込者８１０の申し出のサブセットと共に返答する。
双方向通信を確立しなければならないため、このシナリオは、殆どの場合において「プッシュ／プル」モードを使用する。
１対多通信シナリオ２００
１対多通信シナリオ２００によって、接続モードと交渉モード８０６の全ての組合せが可能になり、妥当である。例えば、「単一の受信側と多数の送信側」シナリオによって、受信側側においてオーバロードが生じるが、その理由は、このケースが、「送信側（申込者８１０）−受信側（回答者８１１）」シナリオの場合と同様に、受信側に、複数の交渉８０８、８０９を、各送信側について別個の基準に基づいて強制的に実行させるように扱われるべきであるためである。
１対多シナリオに関連した、よく知られている接続シナリオの幾つかを以下に示す。
−純粋なマルチキャスト通信：受信側が、（例えばＳＡＰを介して）事前に配布された情報に基づいて、所定のマルチキャスト通信グループを選択することによって、所定の送信側に「チューニング」する。
−このシナリオは、「受信側（申込者８１０）−送信側（回答者８１１）」シナリオと同様に機能する。これにより、セッション１０２のフレキシブルな参加及び離脱が可能になる。応答８１１は、全ての加入者について単一の基準に基づいて、しかしながら、既存のセッション１０２が使用しているリソースも考慮して、セッション１０２を適合することができる。送信側が申込者８１０の能力を果たす場合には、受信側の中にはこのような要求に対応できないものもある。
いずれの場合においても、申込者８１０（送信側又は受信側）は、前交渉した情報をオフラインで有利に使用して、リアルタイムにおける通信設定をスピードアップすることができる。最終的に、ＦＩＰＡ（the Foundation for Intelligent Physical Agents）（http: www.fipa.org/）（以下、[FIPA]という。）に記載されているようなユーザエージェントを介して、又はブローカを介して（この場合には本願品質仕様の範囲外となる）実施することができる。
提供されるメディアストリームの２０６の各々についての別個のリソース管理が必要であるため、単一側が受信側である全てのシナリオは、１対１交渉として考慮されるべきである。
多対多通信シナリオ３００、４００、５００
最初に会議の代表者が行った選択に全員が同意した場合、このケースは、複数の交渉の重ね合わせ８０９と同様に取り扱うことができるが、この代表者は、セッション１０２の参加／離脱について交渉８０９を組織した人物、及びその実行を取り扱う人物である。ピアは、実際の接続を交渉する以前に、通信環境を構成する方法についての先験的な変更を加えることができる。交渉する側のピア間で実行される平行及び／又は連続した交渉８０６が、アプリケーション依存、及び、基本的な本発明に基づいて提案された解決手法の範囲から逸脱したものである。
Ｅ２ＥＮＰ９０８には、以下に示す４つの重要なフェーズがある。
１．エンドツーエンドＱｏＳ前交渉フェーズ８０２
２．マルチストリームＱｏＳ関連８０４、及び時間同期８０５の実行フェーズ
３．エンドツーエンドＱｏＳコンパクト交渉フェーズ（経済原理を有する）フェーズ、すなわちより短い「高速交渉」８０６
４．エンドツーエンドＱｏＳコンパクト再交渉（経済原理を有する）フェーズ、すなわちより短い「高速再交渉」８０８
所定のメディアセッション１０２の生存期間内でこれら４つのフェーズの全てを連結することができる。あるいは、まず、前半の２つのフェーズを、後半の２つのフェーズとは別に、異なる時間において、所定の順序を厳守して実行することができる。これにより、様々なＥ２ＥＮＰ９０８のフェーズの結果が制限された時間内で有効である場合には、関連する有効性のタイムスケールがフェーズ毎に異なることができる。
より詳細には、エンドツーエンドＱｏＳ前交渉フェーズ８０２を先験的に実行し、その結果を、後に、複数の連続電気通信セッション１０２の残りのフェーズに適合することが可能である。このフェーズは、受信側のピアが、メディアセッション１０２の実際の開始前に、また、セッション１０２自体とは別に実行できる処理によって、特長づけることができる。このフェーズの目的は、ＱｏＳプロファイルから演繹した通りに、能力の構成、ＱｏＳ契約１１０８を考慮して、「非義務的方法で」ピア間で情報の交換を可能にすることである。
これらの構成は適応経路を含むため、受信側のピアは、使用可能なＱｏＳ変化又はＱｏＳ違反に有効且つ効果的な方法で反応する方法に事前に合意することができる。また任意で、このフェーズは、参加者の各セットが、グループ適応経路をアソシエーションのレベルで交渉する、すなわち、所定のピアのセット間に確立された全てのメディアストリーム２０６にかけて、ＱｏＳ補正８０４と時間同期８０５を実行する。
この情報交換は関連するピアに関する情報的特長を備えており、この情報的特徴は、所定のピアのセットが使用可能な能力及び性能の可能性について相互間で通知し合うためだけでなく、更に、構成の幾つかを再定義する際に合意に達するためにも使用される。この方法により、ピアは、任意の特定のビジネスに先行して、共通の語彙を確立することができる。
会員が、関連及び同期を必要として、複数のマルチストリーム２０６の確立を計画している場合のみに要求される限り、マルチストリームＱｏＳ関連８０４及び時間同期８０５実行フェーズは任意である。１つの例外として、様々なピアが、ピア間で複雑な交渉８０６を実行するべく任命した場合には、別個のエンティティ（例えば会議電話ブリッジ等の中間コンポーネント）が更にこのフェーズを使用することが可能である。中間コンポーネントはこの書き込みの範囲外であり、また、中間コンポーネントについては、完璧性のみの理由で記述している。Ｅ２ＥＮＰ９０８のフェーズ及び動作者は、図８に示した反復線図から理解できる。
第３のフェーズは、先に適合させたエンドツーエンドＱｏＳ前交渉８０２の結果に基づいて、所定のセッション１０２とメディアストリーム２０６に実施される所定のＱｏＳレベルに合意するために、実際のメディアセッション１０２の開始の前又は後に受信側のピアが実行できる処理によって特長づけられる。この処理は、ピア間で前交渉された情報の参照しか実際に交換されないため、エンドツーエンドＱｏＳフル交渉８０６の場合と比較して相当に高速である。エンドツーエンドＱｏＳフル交渉８０６は、受信側のピアが、所定のセッションとストリームを実行するべく所定のＱｏＳレベルに合意するために、セッションの実際の開始前、又は開始時に、元々提案されているＱｏＳ品質仕様の構成を最終的に再定義することにより実行できる処理である。エンドツーエンドＱｏＳコンパクト交渉処理の終了時において、受信側のピアは、通信に使用するＱｏＳプロファイルに合意した。
第４のフェーズは、先に適合されたエンドツーエンドＱｏＳ前交渉処理に基づいて、所定のメディアセッション１０２について実行する所定のＱｏＳレベルに合意するために、受信側のピアが、ＱｏＳ変化又はＱｏＳ違反のいずれかを検出後に起動できる処理によって特長づけられる。
この処理は、ピア間で前交渉された情報の参照しか実際に交換されないため、エンドツーエンドＱｏＳ完全な再交渉処理８０８の場合と比較して相当に高速である。エンドツーエンドＱｏＳ前交渉８０２は、受信側のピアが、所定のセッションとストリームを実行するべく所定のＱｏＳレベルに合意するために、セッションの実際の開始前、又は開始時に、元々提案されているＱｏＳ品質仕様の構成を最終的に再定義することにより実行できる処理である。エンドツーエンドＱｏＳコンパクト交渉処理の終了時において、受信側のピアは、通信に使用するＱｏＳプロファイルに合意した。
エンドツーエンドＱｏＳコンパクト再交渉８０８において、受信側側のピアは、通信に使用する新たなＱｏＳプロファイルに合意した。
エンドツーエンドＱｏＳコンパクト再交渉フェーズ８０８は、あらゆる所定のメディアセッションの生存期間中に、数回適合することができる。
上述した要求に基づいて、ピアは、再交渉８０８に繋がる条件が満たされる際には常に、不安定性を回避する目的で、共通リソース管理ポリシを事前に事前交渉することができる。
これに関連して、ピアは、以下に示す２つの異なるレベルにおいて、再交渉８０８を実行することができる。
・第１の帯域内信号処理（例えば、ＲＴＰパケットヘッダ内のリアルタイムにおいて、現在実行中のアプリケーションレベルのＱｏＳ契約１１０８に影響することなく、ＲＴＰペイロードタイプを変更して行う）、
・エンドツーエンドＱｏＳ再交渉フェーズ８０８に基づいた、より構造化した処理（上記の処理が、所定のＱｏＳ違反／変更との協働に十分でない場合に常に使用される）。
より詳細には、後述するように、ピアは、所定のユーザレベルのＱｏＳ契約１１０８に適用可能な任意のペイロードタイプを、動的に選択して使用することが可能である。この選択は、非常に高速な再交渉８０８の形式としての、通常のＲＴＰ帯域内信号の場合に影響する。これに対して、ＱｏＳ違反又はＱｏＳ変化が生じ、新規ユーザレベルのＱｏＳ契約１１０８の実行が必要な場合には、エンドツーエンドＱｏＳ再交渉フェーズ８０８が実施される。
送信側は、他の（交渉済みの）コーデックを使用する決定を受信側に帯域内シグナリングするために、ＲＴＰヘッダ内に含まれているＲＴＰペイロードタイプ領域を使用することができる。これは、再交渉８０８の形式であり、Ｅ２ＥＮＰ９０８にとっては本質的にトランスペアレントである。しかしながら、この帯域内シグナリングを使用する使用者は、ＱｏＳ違反／変更に有効且つ効果的に反映するために、やはりＥ２ＥＮＰ９０８を使用することができ有利である。これに関連し、ピアに、新たに提案されたコーデックを任意の前交渉した情報に対して認可させることによって、能力に関してのみでなく、ＱｏＳ契約１１０８に関しても、インバウンドＲＴＰシグナリングの使用を容易に一致させることができる。
これはつまり、送信側は、まず第一に、新たな能力、及び新たなＱｏＳ契約１１０８（該能力の使用を最適化する）を、前交渉した情報に関連して認可する（更に、これに基づいてリソースを事前予約し）ということである。その一方で、各受信側は、送信が帯域内シグナリングしたこの新たな能力を、前交渉した情報に対して認可する。
受信側が、所定のコーデックを起動するために使用できるリソース十分ないことを検出し、一方、送信側が既にコーデックを切り換え、これと共に暗号化したパケットを送信してしまった場合が生じる可能性がある。そのため、受信側は、これらのパケットを復号しないか、若しくは、より低いＱｏＳレベル（例えば低速／低フレームレート）で復号する。この問題に注目するために、受信側は後者（より低いＱｏＳレベルでの復号）を選択するが、送信側へと明確にシグナリングして、より低いＱｏＳレベル（Ｅ２ＥＮＰ９０８コンパクト再交渉８０８）、例えば、中間のもの（前交渉した情報が使用可能であると仮定した場合）を介して選択すると推測できる。これに関連して、人間のユーザの観点からすると、１つのビデオフレームの損失は簡単に気付くものではないため、送信側と受信側の間のＱｏＳ切換時に、１つのビデオパケットを損失するか、又は解読しないことはそれ程重要ではないということに触れておく必要がある。そのため、ユーザが感知するビデオＱｏＳが、このような小規模のビデオ妨害によって激しく影響されるとは考慮すべきでない。一方、１つのオーディオパケットの損失、又は未復号は、ユーザの観点から違反と考えられるべき可聴クラックを生じる可能性がある。この問題に適用可能な解決手法は、シー・パーキンズ（C. Perkins）他著「冗長オーディオデータ用のＲＴＰペイロード（RTP Payload for Redundant Audio Data）」（ＲＦＣ２１９８、ネットワーク６０４分科会（RFC 2198, Network604 Working Group）、１９９７年９月）（以下、[RFC2198]という。）に記載の、同一のオーディオパケット内の同一又は異なる品質を有する冗長オーディオデータの送信であってよい。したがって、パケットはオーディオデータを２回搬送し、１つのオーディオパケットが損失した場合、次の１つが損失したデータを冗長的に補足する。
ユーザが感知したオーディオＱｏＳをサポートするために、合意された能力とＱｏＳ契約１１０８とに関連するこのような２重の情報をピア間で伝送することによって、送信側が、異なる形に暗号化したオーディオデータを平行伝送できるようにする必要がある。人間は、装置の全てのオーディオボックス上でモノラル信号を同時に再生した場合に、より低い品質の信号オーディオパケットの受信等の変化を、例えばモノラルとステレオの間の特異的な切換であるとは殆ど感知しないため、ユーザの観点から、こうしたオーディオパケットの受信を違反と考えるべきではない。一般に、オーディオ及びビデオの特異的な妨害の蓄積は違反と考えるべきであり、実行再交渉８０８の時間のみに許可されるべきである。発生するメディア特異性の扱いは、リソース管理、許容範囲及び機構等の実現上の問題であり、また、アプリケーション依存性及びヒューリスティック依存性であってよい。
上述したメカニズムを実現する重要な事項を以下に示す。
１．帯域内シグナリングは、ＱｏＳ契約１１０８に合意したピアが実行するには不十分であり、実際のところ、完全な再交渉８０８メカニズムは、より構造的なアプローチ、例えばＥ２ＥＮＰ９０８を使用することで達成可能である。しかしながら、Ｅ２ＥＮＰ９０８を使用する代わりに、受信側は、レベレージングＲＴＣＰモニタによってカレントＱｏＳレベルを監視し、これにより、前交渉したＱｏＳ契約１１０８のいずれを送信側が現在実行しているかを識別することができる。
２．両ピアがどのコーデック及びどの契約１１０８を実行するかに合意するまで、ネットワークリソースの保留がコミットされるべきではない。
ハンドオーバシナリオとの協働に必要な要求に基づいて、所定のユーザが選択したネットワークプロバイダによってサポートされていない全てのＱｏＳ契約１１０８は、予備として有利に考慮されるべきである。申込者８１０と回答者８１１が類似の契約１１０８に先駆的に合意できる限り、これらの契約１１０８を交渉して、他のピア間、及び彼等が現在使用しているネットワークプロバイダ間の合意を考慮できるようにする必要がある。
素直ハンドオーバが発生した場合には、いずれのピアも、予備を含む自分の全ての契約の検証を試みることができ、これにより、最終的に、新たなネットワークプロバイダ及び／又は新たな種類のアクセスネットワーク６０４に対して適用可能となる。これはつまり、ＱｏＳ違反又は変更を検出しているピアが、幾つかの予備契約１１０８が現在有効となったことが検出されたときに、新たなＱｏＳ契約１１０８の実施を示すためだけでなく、前交渉した予備契約１１０８を「除去（unblock）」するために、エンドツーエンドＱｏＳコンパクト再交渉フェーズ８０８を開始することができる。
更に、垂直ハンドオーバ後には、先に許可された契約１１０８の幾つかは既に使用可能でない可能性がある点に留意すべきである。これはつまり、エンドツーエンドＱｏＳコンパクト再交渉フェーズ８０８中に、このような契約１１０８の「阻止（block）」も考慮されるべきであるということを意味する。
４つ全てのフェーズ中に、Ｅ２ＥＮＰ９０８はローカルリソース管理能力と対話を行う。より詳細には、基づいたエンドツーエンドＱｏＳコンパクト交渉フェーズ８０６中に、エンドツーエンドＱｏＳコンパクト再交渉フェーズ８０８ Ｅ２ＥＮＰ９０８が、「経済原理」に従い、更に、エンドツーエンドＱｏＳ前交渉フェーズ中に前交渉されたリソース管理に基づいて、ローカル及びネットワークリソース管理能力との対話を行う。
要件によって規定されたＱｏＳ品質仕様の階層構造を得た上で、これらの要求を上手く満たすモデルは、ジー・ブーチ（G. Booch）、ジェイ・ランボウ（J. Rmbaugh）、アイ・ジェイコブソン（I. Jacobson）著「統一モデリング言語ユーザガイド（The Unified Modeling Language User Guide）」（アディソン・ウェズリー・ロングマン（Addison Wesley Longman）、１９９９年）（以下、[Booch99]という。）に記載されているような階層有限状態マシーン（ＦＳＭ）の概念に基づいたものであると予想することができる。このようなモデルにおいて、各々のＱｏＳ契約１１０８は階層ＦＳＭの状態に関連する。この階層構造の最下レベルにおいて、状態は、個々のメディアストリーム２０６のＱｏＳ契約１１０８にマッピングする。
公称ＱｏＳ契約１１０８（すなわち、ユーザがデフォルトで使用可能にしたいと希望するもの）は、所定の適応経路に関連したＦＳＭの初期状態と関連する。各々の適応経路はエレメンタルＦＳＭに関連し、この場合、状態は相互に排他的である。状態及び／又は完全なエレメンタルＦＳＭは、より高いレベルの状態にネスティングすることができ、これにより、上述したようにＱｏＳ契約１１０８と関連する。これはＱｏＳコンテキストの概念を表す。所定のより高いレベルの状態内では、共にネスティングしているＦＳＭは同時発生することができる。これは、適応経路のグループが所定のＱｏＳコンテキストによって関連されていることを表す。
このような階層ＦＳＭの各々の遷移は、例えばＱｏＳ違反等の所定のイベントに反応したＱｏＳ契約１１０８の特定の変更を表す。これらの遷移は、特定の述語が真であると評価される場合には常に起動される。これは、我々のモデル内では、監視された特定のＱｏＳパラメータの値を、所定のＱｏＳ契約１１０８内に記述された関連する値との比較と解釈される。
最終的に、遷移は、高レベルの動作（例えば、既存のメディアストリーム２０６の除外、又は新たなメディアストリーム２０６の開始）と関連する。これらの動作によって、例えば、ハンドオーバの発生が原因の、一時的な故障状態をユーザに示すイベントが発生する。
[Loyal]に記述されているＱｏＳ記述言語（ＱＤＬ）とは異なり、ＱｏＳ契約１１０８の（及び、制限された範囲で、ＱｏＳコンテキストの）、及び、階層ＦＳＭの品質仕様が相互に対してデカップリングされる。これにより、設計に、モジュール方式更に柔軟性が導入され、所定のＱｏＳコントラスト１１０８を異なる適合ポリシと組み合わせることができ、適合ポリシは、異なる構成ＦＳＭから構成することが可能である。
Ｅ２ＥＮＰ９０８が採用した交渉８０６処理は、基本的に、接続確立時における非反復的交渉８０６処理の実行により構成されており、この接続確立時には、所定の前交渉した適応経路を表す階層ＦＳＭに関連して、ピア同士が単純に１組の状態識別子を交換する。
申込者８１０はビッドを提案し、また、各回答者８１１が、そのビッドを自己の適合ポリシに対して許可し、カウンターオファーに応答する。このモデルは、カウンターオファーの範囲を、元のビッドのサブセットの定義に制限する（これは、問題の複雑性を制限するためである）。応答レベルにおいて、これが以下のように変換される。
・ビッド内の各アイテムに適用された[Frolu98]に基づいて、前交渉されたＱｏＳ契約タイプ及びＱｏＳ契約１１０８に関連して、ＱｏＳ契約適合許可に変換され、契約１１０８がＸＭＬ文書中に記述される場合には、例えば事前定義した特定のＸＭＬ文書タイプ定義（ＤＴＤ）によって実行することによって、適合許可を行うことができる。
・元の前交渉した階層ＦＳＭの構造に適用する、プルーニングオペレーションの任意のセットに変換される。
既に通信中のピアのグループに新たなピアが参加する度に、新規ピアは、上述したメカニズムが追従しながら、新たなＥ２ＥＮＰフェーズの申込者８１０として動作することができる旨に留意すべきである（ピアが、通信ピアと既に事前交渉した情報を有する場合には、新たなＥ２ＥＮＰフェーズは、エンドツーエンドＱｏＳコンパクト交渉フェーズから開始する）。更に、交渉８０９フェーズが首尾良く完了した後（交渉した適応経路内のＱｏＳ変化として未だ考慮されていない際）に、ＱｏＳコンテキスト及び／又はメディアストリーム２０６の任意のアドホック作成、変更又は除去が、交渉処理８０８、８０９の新たなフェーズを起動する。より詳細には、例えば、ＱｏＳの全体レベル、又はその一部分を上昇又は低下させるために、ユーザが、既に実行中のマルチメディアアプリケーション上でＱｏＳ変化を故意に発生させる可能性がある点に留意すべきである。この交渉８０８、８０９は、適応経路に関連したＱｏＳ契約１１０８における変更に反映され、更に、適応経路自体の構造にも反映される。交渉処理８０８、８０９は相当に高額であるため、Ｅ２ＥＮＰ９０８の任意の連続した増分の再使用、又はその複数部分によって、非効率性が生じる可能性がある。これに関連して、以下に留意すべきである。
・ビデオオンデマンドシナリオにおいて、ＱｏＳ違反又はＱｏＳ変化に対応するために、所定のメディアストリーム２０６のセットについて、両者側が単純に、適応経路に先駆的に合意する。したがって、この場合には、上述したアドホック変更の可変性は適用されない。
・申込者８１０は、ビッドする適応経路内のＱｏＳコンテキスト及び／又はメディアストリーム２０６の作成、変更、除去等のイベントを既に考慮している可能性がある。
・最初の交渉８０９後には、全てのピアが、最初の交渉８０９の場合と比較して、交渉８０６合意により迅速に集中することが可能になるが、これは、ピアの多くが既に交渉した階層ＦＳＭを使用しているためである。
しかしながら、これらの場合を取り扱うための規則は、所定の電気通信セッション１０２に使用される管理のタイプに大きく依存する。例えば、会議サービスの場合には、これが、特定の会議制御ポリシ及びプロトコルの選択に変わる。そのため、完全なＥ２ＥＮＰ９０８の能力が、これらの高レベルセッション１０２管理タスクを外部のマシーン及びプロトコルに権限譲渡する方法で考案されるが、これは基本的な本発明の範囲外となる。
Ｅ２ＥＮＰ９０８フェーズドアプローチを拡張することにより、細分が、マイクロフェーズの導入として予想される。これはつまり、例えば、垂直ハンドオーバの際に、事前交渉した情報を調整するために、ピアが、前交渉した情報を順次更新することができることを意味し、この場合、新たなアクセスネットワーク６０４技術／能力、及び／又は新たなネットワークハンドオーバが、事前にネゴシエー田したものと比較して様々なＱｏＳレベルを提供できる。この範囲で、変更に影響されないものが有効な状態に維持されるようにするために、交渉可能なアイテムのモジュール記述が必要である。これは、幾つかのアイテムについては、完全な再交渉８０８が不要となり、更に、ＱｏＳ変化／違反の取扱いに関する性能の観点から明白な利点が得られる。
この概念については更なる研究が必要である。より詳細には、前交渉したＡＰを記述する既存の状態マシーンへの衝撃等の態様について詳細に考慮しなければならない。
次の数章において、提案された解決手法を、ＳＩＰ９１０及びＳＤＰｎｇ９１２等の既存のプロトコルでレベレージングして実現する場合に使用可能な方法について説明する。
この範囲で、ＳＩＰ９１０は新規モードで使用されるが、実質的に不変のまま維持され、その一方で、上述した要求を満たすために、ＳＤＰｎｇ品質仕様の拡張及び幾つかの変更が提案される。図９に、ＳＤＰｎｇ９１２及びＳＩＰ９１０を使用するＥ２ＥＮＰ９０８の能力を示す。
この概念は、最少且つモジュラーな変更で、ＳＩＰ９１０の使用を拡張し、ＳＤＰｎｇ品質仕様（現在、ＩＥＴＦ ＭＭＵＳＩＣ Ｗｏｒｋｉｎｇ Ｇｒｏｕｐにおいて研究中）を、Ｅ２ＥＮＰ要求を含むよう拡張するというものである。これは、未完成の品質仕様であり、むしろ、これにより提案された概念の詳細な説明であり、技術コミュニティにおいて関心を増加させ、討論を活発化することを目的としたものである。
説明を進める前に、アプリケーションレベルのＱｏＳ品質仕様の発行を提案する。
一般に、ユーザは、自分の要求が、端末装置及びネットワーク６０４によって実際にどのように実施されるかとは別に、どの情報をピアと交換したいかについて、及びその品質（ユーザが、コンテンツのみでなく、ＱｏＳについても支払いをしなければ成らない場合には特に）について定義することに関心を持つ。したがって、ユーザが自分の要求を、詳細なコンテンツ記述及びＱｏＳ契約１１０８によって表現することが予想される。このタイプのＱｏＳ品質仕様は、ユーザレベルＱｏＳ品質仕様と呼ばれる。
更に、ユーザは、１組のＱｏＳ契約１１０８を、複数の異なるコンテンツ及び／又はサービスのセットとして定義することを希望すると予想される。これに関連して、ユーザが、これらのＱｏＳ契約１１０８をオンザフライで明記するか、又は、より有利に、該ＱｏＳ契約１１０８を事前定義し、更に、所謂ユーザプロファイル情報データベースに記憶したがることが予想される。
アプリケーション又はミドルウェアが、ユーザレベルのＱｏＳ品質仕様をアプリケーションレベルのＱｏＳ品質仕様に変換し、これが、Ｅ２ＥＮＰ９０８への入力と考慮される。
基本的な本発明の範囲において、実際のところ、我々は、エル・ボス（L. Bos）他著「サービス交渉８０６のエンドツーエンドのユーザ感知品質フレームワーク（A Framework for End-to-End User-Preceived Quality of Service Negotiation 806）」（ＩＥＴＦインターネット草案、未完成（IETF Internet Draft, work-in-progress）、<draft-bos-mmusic-sdpQos-framework-00.txt>）（以下、[Bos01]という。）に記述されているようにユーザが感知する通りにＱｏＳを指定することに関心を寄せている。しかしながら、ユーザがこれをどのように表すかについては関心がない。
明らかに、エンドツーエンド送信処理の品質を定義する、１組のＱｏＳパラメータに対するユーザの要望及び嗜好によるマッピングが必要である。このパラメータのセットはアプリケーションレベのルＱｏＳと呼ばれる。このマッピングは、アプリケーション特定であるため、本発明の範囲外である。
以下のＸＭＬ文書は、アプリケーションレベルのＱｏＳ契約１１０８を指定する具体例である。この具体例では、オーディオ及びビデオメディアストリーム２０６用のＱｏＳ契約１１０８のみを示しているが、別タイプのメディアストリーム２０６（データ又は制御メディアストリーム２０６）を含む拡張も容易である。メディアストリーム２０６の各タイプについて、公称値、公称セット、又は動作範囲に関連して、１組のアプリケーションレベルのＱｏＳパラメータが指定される。
オーディオメディアストリーム２０６用のＱｏＳ契約１１０８に表示されたパラメータは、ユーザプロファイル情報が、これらパラメータの固定の構成ではなく、範囲を記述する旨を除いて、[RTP-Profile]に表示されたオーディオコーデックパラメータを反映している。その一方で、オーディオメディアストリーム２０６用のＱｏＳ契約１１０８に記述されているパラメータは、[RTP-Profile]記述を反映せず、[BRAIN]に指示されているＱｏＳパラメータを使用する。
Figure 2005527133
Figure 2005527133
ユーザプロファイルにおいて、ユーザは、ＱｏＳに、異なるレベルの塊、特定の目標値、又は特定の目標値、又は動作範囲を、離散セット又は連続インターバルとして指定することができる。frame-size-setは、提示されたフレームのサイズを示す。これは、画素（例えば３５２×２８８）内の標準フレームサイズ（ＦＩＦ、ＱＣＩＦ、ＳＩＦ等）又は幅−高さ解像度の両方として指定することができる。
frame-rate-setは、ピアの目標フレームレートを指定するインターバルを表す。例えば、フレームレートを２０Ｆｒ／ｓに設定した場合、送信側が、毎秒２０個のフレームの圧縮、パケット化、送信を行う。受信側は、２０Ｆｒ／ｓで復号及びレンダリングを実行できなければならない。フレームサイズに関連するビデオコーデックマッピングについての追加の情報を、「ファイル転送及び必要メモリの要件（IP/TV CODECs, File Transfer and Storage Requirement Considerations）」（白書、２０００年７月、http://www.cisco.com/warp/public/cc/pd/mxsv/iptv3400/tech/ipcod_wp.htm）（以下、[WP-CISCO]という。）内に見つけることができる。
color-quality-range及びoverall-quality-rangeは、所定のコーデックに使用可能である単一のフレームの使用可能な圧縮レベルの範囲を示す。ビデオデータの圧縮度が高いほど、その品質は低下する。[Handl98]内で、品質が０（最低品質）〜１０（最高品質）の数字で表示するように指示されており、これが単一のフレームの品質でなければならない旨が示されている。しかしながら、既存のコーデック及び将来開発されるコーデックとには１０よりも多い圧縮レベルが存在することを考慮すると、この解像度は非常に低い。[Handl98]に記述されているように定義された範囲では上述した要求を満たすことはできないので、０〜１００００といったより幅広い品質範囲の提案がなされ、この場合、０は最低品質であり、１００００は最高品質である。この範囲は、color-quality-range及びoverall-quality-rangeの両方に適用されるべきである。単一のフレームの色差平面の品質は、各コーデック毎に関連性のあるものではないため、color-quality-rangeは任意であると考慮されるべきである。
以下の部分では、上述の必要性を考慮したＳＤＰｎｇ拡張の提案について説明している（簡素化及び読解容易化のために、この文書中で、我々は、ＸＭＬ基準によって指定されたエスケープバージョン（つまり、「&」を「&amp;」と示す）の代わりに、「&」等の記号をその通りに表示する取り決めに基づいている）。これに関連して、目的は、ＳＤＰｎｇ９１２にモジュラーな拡張を定義することである。これは、新たな名称スペース「e2enp」内に１組の新規セクションを導入することで達成できる。この新規セクションは、新規バージョンのＳＤＰｎｇ９１２の一部として定義するか、又は、「XML Schema:Primer」、「XML Schema:Structures」、「XML Schema:Daytypes」（Ｗ３Ｃ，２００１）（以下、[XMLSC]という。）に関連したＸＭＬスキーマを含む、Ｅ２ＥＮＰ９０８と名称づけられた他のＳＤＰｎｇ９１２プロファイル内に定義するか、のいずれかが可能である。したがって、このような新規Ｅ２ＥＮＰ９０８プロファイルは、次のようなヘッダを特徴とする。
Figure 2005527133
いずれの場合にも、現在のＳＤＰｎｇ提案への変更（オーディオコーデック及びＲＴＰ能力交渉を含む）は、ディー・クッチャー（D. Kutscher）他著「セッション記述及び能力交渉のための要件（Requirements for Session Description and Capability Negotiation）」（ＩＥＴＦインターネット草案、未完成（IETF Internet-Draft, Work-in-progress）,<draft-kutscher-mmusic-sdpng-03.txt>）（以下、[SDPNG03]という。）を提案している。受領された場合、これらの変更により、元のＳＤＰｎｇ９１２（及びオーディオコーデック、ＲＴＰプロファイル）ＸＭＬスキーマが影響を受ける。
新たなバージョンのＳＤＰｎｇ９１２を移動するか、又はその拡張を定義するかの決定が討論の対象として残る。
ＳＤＰｎｇ文書のルートエレメント（すなわち、<desc>エレメント）に、新たな名称空間「e2enp」が表示される。
まず第一に、この提案は、上述の要求に基づいて、ＳＤＰｎｇコンテンツを、特定Ｅ２ＥＮＰ９０８フェーズとして独特に識別する、新たなＳＤＰｎｇセクション<e2enp:purpose>の使用を紹介する。ＳＤＰｎｇ情報は、ＳＩＰ９１０標準方法によりピギーバックされるものであり、このアプローチを用いて、ＳＩＰ９１０の意味及び文法を変更することなく、Ｅ２ＥＮＰ９０８ＳＤＰｎｇに基づくメタプロトコルを定義することによって、ＳＩＰ９１０の能力の使用の拡張が可能である。
更に、Ｅ２ＥＮＰ９０８特長を実現するために、この提案は、（ｉ）他の２つの新しいＳＤＰｎｇセクション、<e2enp:quodef>及び<e2enp:quoscfg>を定義し、（ｉｉ）その結果生じた、異なる時間及び方法にて、様々なＥ２ＥＮＰ９０８フェーズに従い、ＳＩＰ９１０（又は、他のシグナリングセッション１０３プロトコル）により、ピギーバックを介して独立伝送中であるＳＤＰｎｇ９１２の様々なセクションを許可する。
この提案は、ＳＤＰｎｇ９１２<cfg>セクションに小さな変更を生じ、更に、このセクション内に含まれる情報を他の新たなセクションとどのようにリンクすべきであるかについて詳細なガイドラインを提供する。
更に、ＱｏＳ関連８０４及び時間同期８０５制約の特定を許可し、関連する特徴の殆どを既に網羅しているため、この提案は、<e2enp:qoscfg>セクション、ＳＤＰｎｇ９１２<constraints>セクションの意味を改訂する。
したがって、この提案は、ＳＤＰｎｇ９１２の可能な限りの使用可能なモジュラー拡張の定義を試み、これにより、上記拡張をサポートしていないアプリケーションとの容易な共同使用可能性を可能にする。
ＳＩＰ９１０は、ピア間の通信を確立するシグナリングセッション１０３プロトコルとして定義される。一般に、接続の開始のみを考慮し、使用特徴及び／又は特定用途特徴は除外される。これらの特徴が、ＳＤＰ又はＳＤＰｎｇ９１２の手段により記述される。
特に、アプリケーションの観点から、プロトコルがモジュラー方法と同様に実行することを考慮すると、ＳＩＰ９１０にかけて配信されたＳＤＰ／ＳＤＰｎｇ情報の取扱い方法に関する何らかの追加的情報をアプリケーションに持たせることが必要な場合もある。
「モジュラー方法」はＡＣＩＤ（原子性、整合性、保護、耐久性）トランザクション特徴を常に満たすものではいため、このＳＩＰ手順は一般にトランザクションとして考慮されるべきでない。
Ｅ２ＥＮＰ９０８は、ピア間の３つの異なる情報交換（すなわち、エンドツーエンドＱｏＳ前交渉８０２フェーズ、エンドツーエンドＱｏＳ交渉８０６フェーズ、エンドツーエンドＱｏＳ再交渉８０８フェーズ）を要求するので、プロトコル内で、関連する積を区別することが必要である。
ＳＤＰｎｇ９１２は、フェーズのタイプ、所定フェーズの開始／停止、及び／又はリソース予約状態に関連したシグナリングを、ＳＩＰ９１０から独立して明示的に伝送することができる（又は、あらゆるシグナリングセッション１０３プロトコルが、ＳＤＰｎｇ情報のピギーバックに使用される）。これに関連して、全てのＥ２ＥＮＰ関連のＳＤＰｎｇ情報内の、ＳＤＰｎｇコンテンツの最初に、新たなＳＤＰｎｇセクションをＰＤＵヘッダのフォームで導入することによって、ＳＤＰｎｇに基づくメタプロトコルが定義される。
次の具体例は、<e2enp:purpose>セクションの使用可能な例を示す。
Figure 2005527133
<session>エレメントは、ＳＤＰｎｇコンテンツの残り部分に記述された所定のＥ２ＥＮＰ９０８フェーズを一意的に識別する。<session>エレメントは、[SDPNG03]で提案された<owner>エレメントに基づいている。Ｅ２ＥＮＰ ＰＤＵのサイズを制限するために、コンパクトセッション識別子の前交渉及び使用が<session>から導出される（例えばハッシュにより）。任意で所定のＥ２ＥＮＰフェーズ又はその連結の第１のＰＤＵに、<session>（算出したハッシュを含む）を使用できる。
<expires>子エレメントは、所定の<session>エレメントに関連するＳＤＰｎｇ情報が有効であると考慮される期間を表す。申込者８１０に応答して、各回答者８１１が、タイマを開始し、<expires>エレメント中に指定された値に設定する。このタイマが切れると、回答者８１１が、関連するＳＤＰｎｇ情報を「ゾンビ」状態に移動しなければならない。これにより申込者８１０は、該タイマが切れる前に、所定のＳＤＰｎｇ情報をリフレッシュできる。
そのＳＤＰｎｇ情報に照会するメディアセッション１０２又はシグナリングセッション１０３がもはや存在しない場合に限り、申込者８１０及び／又は回答者８１１が「ゾンビ」情報を密かに破棄することができる。この原理は、所定の古いＳＤＰｎｇ情報（次の段落を参照）を参照する他のＳＤＰｎｇ情報にも使用され、所定の「ゾンビ」のものを参照する任意の有効な（すなわち、「ゾンビ」状態にない）ＳＤＰｎｇ情報が存在する限り、申込者８１０及び／又は回答者８１１は、上記「ゾンビ」ＳＤＰｎｇ情報を静かに破棄することができない。
ＳＤＰｎｇコンテンツの他の具体例において、参照したＳＤＰｎｇコンテンツ内に定義されたアイテムを参照するために、<session>エレメントが参照するＳＤＰｎｇ情報を使用することができる。このメカニズムは<use>エレメントを介して提供し、これにより、<session>エレメントの既存の具体例への参照の作成が可能になる。
例えば、所定のペアのセットのエンドツーエンドＱｏＳ交渉フェーズ８０６の具体例を記述するＳＤＰｎｇコンテンツが、予め前交渉しておいた情報を参照するが、これは、<e2enp:purpose>セクションの<use>構造内に、該前交渉した情報の一意の<session>エレメントを表示する。２つのフェーズに関連したＳＤＰｎｇコンテンツは、１つのＳＩＰメッセージに結合的にピギーバッグされる場合には（すなわち、フェーズが連続的に調子を合わせて実施される場合には）、当然ながら、この参照は不要である（更に、<use>エレメントは表示されない）。
<use>セクション内に列挙した<session>エレメント中への<expires>子エレメントの表示は強制ではない。しかしながら、表示されている場合には、その意味は<expires>子エレメントの通常の使用とは若干異なり、実際、その存在は、これを参照している<session>エレメントの観点から、参照した所定の<session>エレメントが有効と考慮される期間（すなわち、Ｅ２ＥＮＰセッションの残り時間）を示す。当然ながら、所定の<session>エレメントは、参照したセッション１０３の<express>子エレメント時間に特定の時間の元の値を超えない時間ウィンドウについて他を参照してもよい。
<description>エレメントはＳＤＰｎｇ情報の性質を表示し、これを所定の<e2enp:purpose>セクションが参照する。<description>エレメントの「type」、「name」、「mode」属性は以下に定義する通りである。
Figure 2005527133
「タイプ」属性は、所定のＥ２ＥＮＰ９０８フェーズの誰が申込者８１０で、誰が回答者８１１であるかを識別する。
Figure 2005527133
「name」属性は、Ｅ２ＥＮＰ９０８フェーズのタイプを定義し、その記述はＳＤＰｎｇコンテンツの残りの部分に含まれる。
「Standard」：「SIP910:Session Initiation Protocol」に基づいてこのＥ２ＥＮＰ９０８のコンテンツをピギーバックするＳＩＰメッセージの標準使用であり、エム・ハンドレイ（M. Handley）他著「ＳＩＰ９１０：セッション開始プロトコル（SIP 910: Session Initiation Protocol）」（ＩＥＴＦ ＳＩＰ９１０分科会（IETF SIP 910 Working Group）、ＡＣＩＲＩ，１９９９年３月、未完成、<draft-ieft-sip-rfc2543bis-04.txt>）（以下、[SIPBIS04]という。）に記述されている。
・「Pre-negotiation」８０２：このＥ２ＥＮＰ９０８のコンテンツをピギーバックするＳＩＰメッセージが、エンドツーエンドＱｏＳ交渉フェーズ８０６の実施に使用される。
・「Negotiation」８０６：このＥ２ＥＮＰ９０８をピギーバックするＳＩＰメッセージが、エンドツーエンドＱｏＳ交渉フェーズ８０６の実施に使用される。
・「Re-negotiation」８０８：このＥ２ＥＮＰ９０８のコンテンツをピギーバックするＳＩＰメッセージが、エンドツーエンドＱｏＳ再交渉フェーズ８０８の実施に使用される。
・「Start-Reservation」：このＥ２ＥＮＰ９０８のコンテンツをピギーバックするＳＩＰメッセージは、予約処理の開始をシグナリングするために使用される（エンドツーエンドＱｏＳ交渉８０６フェーズ中に、又はエンドツーエンドＱｏＳ再交渉フェーズ８０８中に）。
・「Ready-Reservation」：このＥ２ＥＮＰ９０８のコンテンツをピギーバックするＳＩＰメッセージは、予約処理の完了をシグナリングするために使用される（エンドツーエンドＱｏＳ交渉８０６フェーズ中に、又はエンドツーエンドＱｏＳ再交渉フェーズ８０８中に）。
・「Cancel-Reservation」：このＥ２ＥＮＰ９０８のコンテンツをピギーバックするＳＩＰメッセージは、先に予約したリソースを開放するために使用される。
・「Canceled-Reservation」：このＥ２ＥＮＰ９０８のコンテンツをピギーバックするＳＩＰメッセージは、先に予約したリソースの開放を確認するために使用される。
・「Expire」：このＳＤＰｎｇ９１２をピギーバックするＳＩＰメッセージは、所定の<session>エレメントにより識別されるＳＤＰｎｇ情報を期限切れとするために使用される。前後関係から見て、所定の<session>エレメントの<expires>子エレメントの属性時間をゼロに設定することができる。この命令を使用する場合、所定の<session>エレメントを参照するＥ２ＥＮＰ９０８のコンテンツが、原理に基づいて解放されるべく実行される。
・「Taken-Over」：この命令は、第三者支援交渉８０６内の仲介者１０６a１によって使用され、また、リダイレクションを実施するために、交渉８０６はこれにリダイレクトされている。
フェーズを連結する場合には、「name」属性は最新フェーズのみを示す。「name」エレメントの他の定義は将来考慮される可能性がある。
Figure 2005527133
「mode」属性は交渉８０９モードを示す。この属性は、属性「name」は「pre-negotiationmode」又は「negotiationmode」に設定される場合のみに適用される。「type」、「name」、「mode」エレメントのデフォルト値は、それぞれ「requesttype」、「standard」、「push」である。
<mediation>パラメータは任意であり、以下の値のいずれを使用することも可能である。
Figure 2005527133
これを使用しない場合、交渉８０６のタイプは単純にピアツーピアとなる。このパラメータは、ピアが、他の誰かのために交渉している旨を示すべく使用される。更に、これは、ＳＩＰメッセージのヘッダ「From」と、<purpose>セクションのエレメント<session>とにかけて暗に表示される。一般に、他の誰か代理で交渉しているピアは、ブローカの仲介部分のようなサービス、会議サービス等と考慮される。仲介者１０６ａ１はパラメータ仲介を使用して、交渉パーティに、これは送信及び／又は受信を行うパーティではなく、単に、交渉８０６を仲介するパーティであることを告知する。この場合、仲介者１０６ａ１は、「third-party-assisted」をその能力の表示として使用しなければならない。
ネットワークオペレータにログインする場合には常に（スイッチオン時、及び垂直ハンドオーバが生じる際には常に）、ネットワークオペレータが、ユーザのＱｏＳ嗜好（端末能力と既に一致したもの）をネットワーク能力に対して確認する。
しかしながら、この時点ではまだ、２つの受信側ピアがＱｏｓ契約の共通セットに合意する機会を全く得ない場合が生じるか否か、又はいつ生じるかを予測することは不可能である。このような場合、一般に採用される解決手法は、変換ユニットをデータ経路に沿って挿入するものである。
申込者に特定のトランスコーダ、又はそのチェーンを強制するために、このようなユニットをＳＩＰプロキシ及びディレクトリサービスと結合する可能性が予想される。
２つの受信側ピア間のＥ２ＥＮＰセッションが失敗した場合には常に、申込者は、ネットワークオペレータ又は他のあらゆるサービスプロバイダからのサポートの要求を試み、変換サービスを提供することができる。
これはつまり、ディレクトリサービスを介して、申込者の所定の要求と回答者の能力を満たしながら、使用可能なトランスコーダユニット（１又は複数）を検出し、申込者、様々なトランスコーダ、回答者の間で第三者支援交渉を取り扱う。そのため、変換サービスは、現在のＭＥＧＡＣＯ（メディアゲートウェイ制御（Media Gateway Control（MEGACO）、http://www.ietf.org/html.charters/megaco-charter.html）（以下、[MEGACO]という。）のものと類似したＥ２ＥＮＰを使用する。変換サービスは、ピアのチューンにおけるノードの組合せを組織化し、また、Ｅ２ＥＮＰ経済原理（リソース解放と類似の考察）によってリソースが適切に予約されるようにする。
２つの受信側ユーザ間の接続が、複数のアドミニストレーションドメイン及び／又は技術に亘る場合には、異なるプロバイダの共同体により、第三者支援交渉を実施するＥ２ＥＮＰを使用して、変換サービスが提供される。
これに関連して、「外部交渉」は、２つのピアにその間でＥ２ＥＮＰを実施するよう強制させようと試みるエンティティの代わりに、仲介者１０６ａ１が外部第三者として機能する場合を記述する。上述の変換サービスは、１又は複数のこうした「外部仲介者」を連携して制御する。
複数の処理ユニット間の経路の確立を制御する外部能力の概念は、文献（例えば、ジー・エム・マオ（Z. M. Mao）、アール・カッツ（R. Katz）著「ＩＣＥＢＥＲＧにおけるサービスポータビリティの達成（Achieving Service Protability in ICEBERG）」、ＩＥＥＥ′００クローブコムワークショップの予稿集（Proc. Of IEEE '00 Clobecomm workshop）「２０００ ＩＥＥＥサービスポータビリティ及び仮想顧客環境（2000 IEEE Service Portability and Virtual Customer Environments）」、ＩＥＥＥ、２０００年１２月）においてよく知られている。そのため、これに提案されている解決手法の目的は、Ｅ２ＥＮＰプロトコルの範囲を複雑なケースへと拡張することであるため、トランスポンダ等の中間コンポーネントが必要となる。これに関連して、トランスポンディングサービスコアによって制御されるＥ２ＥＮＰ外部仲介者の多様性の概念は、本発明によって新たに提案されたものとして考慮される。
<mediation>エレメントについては、上述したものとは異なる追加の価値に関連した開発が将来行われる可能性がある。データメディアストリーミングへの仲介者１０６ａ１の積極的な使用が考慮される場合、又は、例えば会議制御ユニット、ＱｏＳブローカ等が関与する交渉８０６に２つ以上のミディエーションコンポーネントが実施される場合には、これが<mediation>エレメントを介して知らされる。
次に、Ｅ２ＥＮＰセッション内の、仲介者１０６ａ１と将来の回答者１０６ａ２の間におけるＳＩＰセッションの開始メッセージに関連した具体例を示す。
Figure 2005527133
この具体例に基づき、ピア「mary fix@195.37.78.173」は、ピア「mary_moby@3ffe:1200:3012: c006: 290:27ff:fe7d:d024」がオーナが「Kate」であるピア「43.196.180.1」の実際に仲介者１０６ａ１であると認識する。
ＳＩＰは、[SIPBIS04]に記述されている「３８０の他のサービス（380 Alternative Service）」を、現在通話ができないサービスに冗長サービスを知らせるだけでなく、呼ばれたピアがその通話を取り扱う能力がない場合に、他の装置へ接続をリダイレクトするが、何らかの割当と、その通話を取り扱える他のビアをその付近において検出する現存のサービスとを利用するためにも使用できる。装置及びサービスを割り当てる処理は基本的な本発明の範囲外であるが、一般に、
ブルートゥースシステム１．１（Bluetooth System Version 1.1）、（htto://www.Bluetooth.com/files/Bluetooth_11_Specific-actions_Book.pdf）、（以下、[BLUE]という。）の仕様書に記載されているBluetooth等の既存の技術、及び、ジェイ・ローゼンバーグ（J. Rosenberg）他著「実存のためのＳＩＰ９１０拡張（SIP 910 Extensions for Presence）」（ＳＩＭＰＬＥ分科会（SIMPLE Working Group）、未完成）、<draft-resenberg-impp-presence-01.txt>）（以下、[SIPPRE01]という。）に記述されている、実在のためのＳＩＰ９１０サポートを考えに入れてもよい。
[SIPBIS04]によれば、「応答のメッセージ本体内に」他のサービスが記述されている。アドレス、及び他のサービスのプロファイル設定への参照を記述した使用可能なＳＤＰｎｇ９１２構造を下に示す。
Figure 2005527133
この場合、
TYPE TYPE = "standard" | "mediation"であり、
−「standard」−[SIPBIS04]に定義されている通りの標準的使用であり、
−「mediation」−仲介目的のものである。
SIP_ADDRESS [SIPBIS04]に定義されているSIP-conformアドレスの形式に対応し、
SIP_VERSION [SIPBIS04]に定義されているSIP910のSIP-conformバージョンシンタクスに対応する。
セクション<service>は、他のサービスを記述するために使用され、既知のＥ２ＥＮＰメッセージセッション記述１１２を参照するか、その中に含まれる。これらの多くは、<purpose>セクションと共に開始する記述を含んでいる。そのため、セクション<section>を繰り返すことができる。
仲介の場合、複数の<service>セクションは同じ<service-id>を有することができるが、仲介者１０６ａ１は、申込者１０６ｂと将来の回答者１０６ａ２の両者に、仲介者１０６ａ１が、仲介者への要求に記述されている通りの未知の情報を指定することなく、一方で申込者１０６ｂと共に、他方で将来の回答者１０６ａ２と共に実行する、関連した交渉について通知しなければならないため、異なるセッション記述を指定する。
[SIPBIS04]に基づいた標準的な使用である場合には、複数の<service>セクションが複数の別サービスを記述する。
セクション<alternative-service>の現在の記述はＥ２ＥＮＰ及び仲介された交渉の意味においてのみなされている。[SIPBIS04]によって定義されている意味における<alternative-service>の使用の追加の記述については、将来、ＳＩＰを使用可能にするサービスを考えに入れた際に考慮される。
Figure 2005527133
仲介者１０６ａ１の要求によれば、未知のセッションへの参照の使用は許可されない。これが、上述の具体例と同様に、仲介者を実現することによって、<service>セクションから参照したセッション内の<purpose>セクションの<use>エレメントを省略しなければならない理由である。その後、仲介者は、参照した全ての情報を収集し、現在の記述（１又は複数）内に（参照なし（no reference））と明確に表示しなければならない。
図１０は、<e2enp:alternative-service>セクションの使用を示す具体例を示している。
第３のメッセージの、<service-id>エレメント内へのアドレス及びバージョンの表示を、申込者１０６ｂ（ケートの装置）が、新たな回答者１０６ａ２（メアリー（Mary））の家庭用端末）への新たなＳＩＰ９１０通話を作成するために使用できる。この情報は、申込者１０６ｂが、通話がリダイレクトされているモバイルデバイスについて知らない場合に特に必要である。
これにより、既存のＳＤＰｎｇ提案[SDPNG03]と比較して、コーデック定義を、ＲＴＰペイロードタイプの定義及びコーデックパラメタリゼーションと区別することが提案された。そこで我々は、コーデックパラメタリゼーションについて、所定のコーデックの定義に付随するパラメータのリスト、例えば、オーディオコーデックの場合には、サンプリング速度とチャンネル数のリストを作成することにした。これにより、新たなＲＴＰセクションの定義と、オーディオコーデック、ＲＴＰプロファイルの再定義が得られる。
この予想と共に、交渉パーティは、まず全てのピアによってサポートされていない全てのコードをプルーニングすることによって、迅速に合意に集中することが可能になる。共通合意したコーデックのセットの識別が完了すると、交渉パーティは、更なるステップとして、ペイロードタイプ及びコーデックパラメタリゼーションの交渉８０６を取り扱う。ペイロードタイプの定義は[RTP-Profile]に記述されており、また、ＲＴＰプロファイルは[SDPNG03]に定義されている。
オーディオコーデックに関して、静的ペイロードタイプは、[RTP-Profile]に定義されている通りの固定コーデックパラメタリゼーションに関連している。そのため、動的ペイロードタイプについてのみ、コーデックパラメタリゼーションの詳細な仕様が必要である。
そのため、我々は、[SDPNG03]に記述されているインラインフォーマットの使用を提案する。
ビデオコーデックに関して述べると、[RTP-Proifle]に示されているパラメタリゼーションは、所定のコーデックをＱｏＳの観点から完全に特徴づけるには不十分である。次の２つの可能な解決手法が考えられる。
１．ユーザ特定前交渉の前に、コーデックの名称、ペイロードタイプ、及び（部分的な）パラメタリゼーションを前交渉する。これは、エンドツーエンドＱｏＳ前交渉８０２フェーズを、２つの顕著なサブフェーズに分割し、初期フェーズでは、端末関連の情報の前交渉８０２が実施され、このサブフェーズの次に、後にユーザプロファイル情報をレベレージングする、１つの（又は多数の）ユーザ特定前交渉８０２サブフェーズが実施され、このサブフェーズでは、これら後のサブフェーズがユーザプロファイル情報を選考のサブフェーズの結果にマッピングする。端末関連の前交渉８０２サブフェーズステムにおける前交渉、更にコーデックパラメタリゼーションの理由は、交渉パーティが使用可能なビデオコーデックの構成を狭小化することによって、所定のピアのハードウェア／ソフトウェアリソースの実容量に関連して、実現可能性の要求を満たしたいかもしれないという事実から生じる。
２．あるいは、どのユーザプロフィールのサブセットが所定の能力、及びローカルリソースの（潜在的な）容量と一致するかを決定し、ピア、更にコーデック名称とペイロードタイプを含むサブセットのみを交渉する。
図１１の線図によって、両方の代替案を例証している。コーデックのみを交渉する場合には、「ユーザレベルＱｏＳ（User Level QoS）」は存在せず、「ＱｏＳ契約スケッチ（QoS Contracts Sketch）」は「システム構成ファイル（System Configuration File）」と等しい。別々に、このような場合については、システム能力のみが確認される。
この原理に基づいて、アプリケーションを、より単純な方法で設計することができる。すなわち、早いサブフェーズにおいてコーデックパラメタリゼーション交渉８０６を扱うか、又は、単純にユーザ特定ＱｏＳ品質使用の交渉８０６を扱う。
コーデック記述は、ピア同士がオフラインで前交渉できる汎用能力記述と一致する。更に、前交渉した情報は、参照、及び／又は、[SDPNG03]に記述されているように、ＳＤＰｎｇ９１２プロファイル内への採用が可能である。
更に、交渉するアイテムの数を減らすために、元のＳＤＰｎｇ９１２コーデックパラメタリゼーションにインターバルを導入してもよい。また、このアプローチにより、直観的方法による適応経路の定義、及び、特にビデオメディアストリーム２０６特徴に関連した不明確性の回避も可能になる。
新たなＳＤＰｎｇ９１２<e2enp:qosdef>セクションは、下記の両能力と、ストリームレベルＱｏＳ契約１１０８とを表す手段を、モジュール方法で提供する。
−「capabilityies」に設定された属性「name」に適した<e2enp:qosdef>セクションが、能力に関する端末関連の情報のみを記述する場合、
−「contracts」に設定した属性「name」に適した<e2enp:quodef>セクションが、ストリーム‐レベルＱｏＳ契約１１０８の所定のユーザプロファイル情報と一致する能力の様々なパラメタリゼーションを記述する場合。
アプリケーション及び／又はミドルウェアが、前交渉した<e2enp:qosdef name="capabilities">から最良のコーデックを選択し、所定のユーザプロファイル情報からＱｏＳ契約１１０８のサブセットを選択する。次に、その結果得られる情報（<e2enp:quodef name="capabilities">のクロスプロダクトと、ユーザプロファイル情報とのサブセット）が、アプリケーションレベルでストリームレベルＱｏｓ契約１１０８を取り扱う<e2enp:qosdef name="contracts">セクションを形成する。特定の暗号化属性が現在特定されている限り、この新たなセクションは、ユーザプロファイル情報に含まれた元の情報とは異なる。次に、前交渉８０２フェーズ中に、ピア同士の間で、この<e2enp:qosdef name="contracts">セクションが交換される。図１１は、ユーザプロファイル及びシステム構成情報からＱｏＳ契約１１０８を導出するシナリオ１１００を示している。
その後、これらの確認が実施される。
２つの種類の<e2enp:qosdef>セクションの前交渉８０２は、ピア間で、異なる時間において、後の実際の使用に関係なく実施することができ、更に、所定の<e2enp:qosdef>セクションに関連した目的セクションの<expires>エレメントを使用して、異なる時間スケールと調子を合わせてスコーピングすることができる。後に古い情報を使用してしまうことを回避するために、Ｅ２ＥＮｐ９０８情報の有効性の時間を制限することが必要である。
<e2enp:qosdef name="capabilities">セクションによって、後のメディアセッション１０２中に使用する能力の共通のサブセットにピアが合意することが可能になる。このセクションは、各タイプのメディア（オーディオ、ビデオ等）に適用された、２つのエレメントのクラスのコンテナ、コーデック定義、ペイロードタイプ定義として機能する。
[SDPNG03]に指定されている元のＡｕｄｉｏ Ｃｏｄｅｃプロファイル、ＲＴＰプロファイル、Ｖｉｄｅｏ Ｃｏｄｅｃプロファイルからの定義の使用が、以下に示す幾つかの拡張と共に予想される。
Figure 2005527133
Figure 2005527133
この具体例は、簡素化の目的から、コーデックパラメタリゼーションを含む、及び含まないビデオコーデックの定義を示す。あるいは、<e2enp:qosdef name="capabilities">セクションは、コーデックパラメタリゼーションを含む、又はこれらを全く含まない、のいずれかである。
このセクションで述べる情報は、ユーザの端末装置の構成ファイルの種類と同等であり、したがって、ユーザプロファイル情報に記述されたユーザプロファイル情報のコンテンツ、更に、ストリームレベルＱｏＳ契約１１０８を取り扱う<e2enp:qosdef>セクションのコンテンツへの補助であることに容易に気付くことができる。
属性「scope」は、要求（交渉ビッド）の中に、関連するＳＤＰｎｇ９１２エレメントが必要とされたオプションと考慮されるのか（「applicable」）、又は希望されたオプションと考慮されるのか（「possible」）を示し、一方で、該属性は、応答（交渉カウンターオファー）の中に、関連するＳＤＰｎｇ９１２エレメントが確認されたか（適用可能）、又は拒絶されたか（適用不能）を示す。
Figure 2005527133
更に、回答者８１１は、カウンターオファーの中に、サポートできる能力と、その範囲とを示すことができる。所定の能力が「その通りに」サポートされる場合には、関連する識別子のみが、「applicable」に設定したスコープ属性と共に表示される。
所定の能力がサポートされない場合には、関連する識別子を単純に省略する。
回答者８１１が、カウンターオファーの中で、<e2enp:qosdef name="capabilities">セクション（元のビッドのサブセットとして）内の所定の能力パラメタリゼーションの改善バージョンを提案している場合には、更新された全体の記述が、両タイプの<e2enp:qosdef>セクションにおいて戻される。いずれの場合でも、ストリームレベルＱｏＳ契約１１０８を取り扱う<e2enp:qosdef>セクションは、応答の中に、更新されたコーデックパラメタリゼーションのみを含んでいる。
これに加えて、回答者８１１は、新たなオプション（前交渉８０２の時点では申込者８１０には未知）を表示することができ、これは「possible」と示される。そのため、この概念は、後に使用できる潜在的オプションを申込者８１０に知らせることができるというものであるが、これは、申込者８１０が該オプションと一致する新たな能力を更新する場合に限られる。
例えば、回答者８１１は、申込者８１０が現在サポートしていないコーデックのサポートを表示することができる。申込者８１０が、その所定のコーデックを取得する（例えば、ソフトウェアコンポーネントをダウンロードすることで）場合には、申込者８１０は、この新たな能力を考慮して、そのポリシを更新することができる。
更に、値「possible」は、回答者８１１の状態を、申込者８１０によって提案されたコーデックに関連して部分的にビジーであると表示することもできる。このように、回答者８１１は、その現在のワークロードを考慮してもよい。これを、例えば、回答者８１１が高い容量を有するが、現在のところ、その一部分のみしか使用できない旨を知らせる、申込者８１０への返答の中に移すことができる。次に、申込者８１０は、この情報を保存しておき、後に、様々なＱｏＳレベルに対応するべく接続の更新を試みる際に、再交渉８０８を行うために使用できる。
能力を排除する、又は後に再構築する必要がある場合には、関連する<e2enp:qosdef name="capabilities">前交渉８０２処理の新たなケースをピア間で実施することによって、所定の変更に関する情報を事前に且つタイムリーに配布し、ピアが適切な適合戦略を採用できるようにする。
回答者８１１は、能力を「possible」として追加し、関連するパラメタリゼーションが、上記新たな能力に関連したエレメント内の<e2enp:qosdef name="capabilities">セクションに直接戻される。この場合、パラメタリゼーションは、単純に、その能力に関連した構成情報を表示する。申込者８１０が後にこの追加の能力を更新する場合には、申込者８１０は、新たな回の前交渉８０２処理を実行するために、構成情報から幾つかの契約１１０８を引き出すことができる。
更に、ピア同士は、能力の使用可能性におけるあらゆる変更に関して知らせ合うために、上述の処理に基づいて、何時でも、再交渉を行うことができる。
上述の具体例を信頼し、次のコードフラグメントが、新たな<e2enp:qosdef name="contracts">セクション内にコーデックパラメタリゼーションの具体例を、上述のパラグラフに記述のマッピング処理から導出したものとして示す。このセクションは、一般に、識別されたタイプのメディアのあらゆるメディアストリーム２０６に使用可能であるアプリケーションレベルのＱｏＳ契約１１０８を取り扱う。
この新たなセクションは、多数の復号ＸＭＬエレメントを含んでいる。
・強制するリソース管理ポリシの交渉に使用する、命令された<policy>エレメント
・以下に示す要素のうち、最大１つの任意の具体例
−<audio>：オーディオメディアストリーム２０６についての全てのＱｏＳ契約１１０８を記述する。
−<video>：ビデオメディアストリーム２０６についての全てのＱｏＳ契約１１０８を記述する。
−<data>：データメディアストリーム２０６についての全てのＱｏＳ契約１１０８を記述する。
−<control>：制御メディアストリーム２０６についての全てのＱｏＳ契約１１０８を記述する。
この場合、このようなＱｏＳ契約１１０８は、ユーザプロファイル情報の能力へのマッピングから導出される。これらエレメントの少なくとも１つが表示される。
Figure 2005527133
Figure 2005527133
Figure 2005527133
Figure 2005527133
Figure 2005527133
color-quality-range及びoverall-quality-rangeについては上述している。この場合、frame-rate-set＝「１０、１５」は、受信側が、最大で１５Ｆｒ／ｓ、最少で１０Ｆｒ／ｓ復号できることを意味している。１０Ｆｒ／ｓ未満で得られた任意の復号は、契約１１０８の違反と考慮される。送信側は、例えば、受信側側でより多くのリソースが検出され、契約変更の要求がなされることで契約が変更しない限り、１５Ｆｒ／ｓより大きい値を提供する必要はない。
<policy>エレメントは、契約のために、ポリシのタイプを伝える。「name」属性は人間が読むことができるポリシの記述を提供する。オプションの<predicate>子エレメントにより、以下のセットから引き出した２つの語彙を含むブール述語の表示が可能になる。
・「optMemoryUsage」−メモリ使用最適化ポリシを表す。
・「optPowerConsumption」−ネットワーク６０４性能最適化ポリシを表す。
・「optPowerConsumption」−電力消費最適化ポリシを表す。
・「optCpuLoad」−ＣＰＵ負荷最適化ポリシを表す。
後に、他のポリシに関連した更なる値を追加することが可能である。
あるいは、他のインスタンスの<predicate>エレメントのセットから述語語彙の値を引き出すことができる。ブール機能のタイプは、「and」、「or」のセットから任意の値を取ることができる「function」属性によって表される。そのようなポリシが使用されない旨を明白に表すポリシが不在であるため、「not」機能は使用されない。そのため、<predicate>子エレメントにより、上述の列挙したエレメントポリシの組合せを指定することが可能になる。
<criterion>子エレメントは、上述したセットから任意の値を取ることができる「type」属性によって、所定のポリシを識別する。更に、このエレメントのインスタンスは、ストリング「expression」を属性「type」の値として指定することによって、また、所定の<predicate>エレメントのインスタンスを識別する追加の属性「idref」を使用することによって、<predicate>エレメントのインスタンスを強制することができる。<criterion>子エレメントは必須であり、その１つのインスタンスのみが、<policy>エレメントの所定のインスタンス内に現れることができる。
<contract>エレメントは、クロスプロダクト処理の結果を表す。これにより、これらユーザ１１０１の、使用可能な能力と一致するアプリケーションレベルのＱｏＳ要求が、ユーザ１１０１のユーザプロファイル情報からコピーされ、ピア間で交渉される。これにより、交渉８０６処理の最後において、ユーザ１１０１の元のアプリケーションレベルのＱｏＳ要求が、そのサブセットに狭小化されるという結果を生じる可能性がある。
上述の要求及び予備契約の概念に関連して、<contract>エレメントの<spare>子エレメントが導入され、所定のユーザ嗜好をネットワークプロバイダがサポートしていないこれらの契約を示す。
したがって、<spare>子エレメントはオプションエレメントであり、その存在は、所定の契約１１０８が、申込者８１０の好ましいネットワーク６０４オペレータによってサポートされない旨を表す。回答者８１１も、同様に、好ましいネットワーク６０４オペレータとの自分の合意に基づいて、予備でないと表示されていないものをフィルタリングする。
垂直ハンドオーバが発生した場合、いずれのパーティも、新たなネットワークプロバイダに関連して後に使用可能となるかもしれない、予備を含む自分の契約１１０８の全ての確認を試みることができる。
所定のアプリケーションレベルのＱｏＳ契約１１０８と特定フォーマットの関連を表すために、<rtp:map>エレメントがＳＤＰｎｇ９１２ＲＴＰプロファイル[SDPNG03]の拡張として提案される。ペイロードタイプは、<rtp:pt>エレメントの「name」属性のインスタンスを参照する「format」属性によって指定される。
属性「contract」は、<contract>エレメントの「name」属性のインスタンスを参照することによって、関連するアプリケーションレベルのＱｏＳを識別する。
属性「role」は、所定のアソシエーションアプリケーションレベルのＱｏＳ契約／ストリームフォーマットが、上述した要求に基づいて、受信側、送信側、又は送信側／受信側によって提案されるか否かを示す。このようにすることによって、受信側のみでなく送信側も、再交渉８０８をＡＰに基づいてどのように取り扱うかを決定するために後に使用される情報を事前に配布することができる。
ＱｏＳコンテキスト及びメディアストリーム２０６のグループ化（また、より詳細には、アソシエーション）の概念を、新たなセクション<e2enp:qoscfg>を追加の<cfg>セクションとして導入することにより、モデリングできる。より詳細には、<e2enp:qoscfg>セクションは、所定のメディアストリーム２０６のための適応経路（ＡＰ）記述と、そのアソシエーション（又は、より一般的にはグループ化）定義とを含んでいる。様々なメディアストリーム２０６のグループ間でＱｏＳ関連８０４と、時間同期８０５制約を捕捉するより高レベルのＱｏＳ契約１１０８、及びその（より高レベルの）ＡＰを、この新たなセクションに指定することもできる。
<e2enp:qoscfg>セクションに含まれる情報は、ピア間で、後の実際の使用に関係なく、前交渉するか、又は接続設定時間において交渉することが可能である。
Ｅ２ＥＮＰ９０８概念の文脈内で、ＳＰＤｎｇの元の<cfg>セクションの範囲を明確にする必要があり、<cfg>セクションは、単純にフォーマット（例えばＲＴＰペイロードタイプ）のマッピングを、トランスポート関連の情報と共に定義し、一方で、ＡＰの完全な定義（<e2enp:qosdef>セクションに定義されたＱｏＳ契約１１０８の能力に関連する）が、新たな<e2enp:qoscfg>セクションによって完全にサポートされる。
この提案と[SDPNG03]との間の唯一の相違点は、使用するネットワーク６０４のタイプ及びそのバージョン（各々、「nettype」属性及び「addrtype」属性）指定するために、<rtp:session>エレメント内に属性を追加的に導入することである。この変更により、ＳＤＰｎｇ９１２ＲＴＰプロファイル[SDPNG03]も影響を受ける。更に、エス・オルソン（S. Olson）、ジー・カマリロ（G. Camarillo）、エイ・ローチ（A. Roach）編、ＳＤＰ内のＩＰｖ６のためのサポート（Support for Ipv6 in SDP）（ＩＥＴＦインターネット草案（IETF Internet Draft）、未完成、<draft-olson-sdp-ipv6-02.txt>）（[01son01]）に、ＳＤＰについて提案されている構文を使用することによって、アドレスが表示される。提案された、<cfg>セクションのためのＳＤＰｎｇ９１２拡張を、以下の具体例にボールド体フォントで示す。
Figure 2005527133
Figure 2005527133
Figure 2005527133
所定のアドレス／ポートの対を、ＡＰ規則と、<e2enp:qosdef name="contracts">セクションの<rtp:map>エレメントに記述されたマッピングとに基づいて、その選択は、（<e2enp:qoscfg>セクションの内の）どのＱｏＳ契約１１０８が実施されるかに依存する、２つの異なるペイロードタイプに関連するものとして指定する<cfg>セッションの使用に留意する。
この提案と、レガシーＳＤＰ及びＳＤＰｎｇ９１２との間の相違は、後者が主にＱｏＳ交渉８０６ではなく、むしろ能力交渉８０６に注目することにより構成される。すなわち、ＳＤＰ／ＳＤＰｎｇ９１２により、送信側は、送信側が送信に使用しようとしているフォーマット及びトランスポート情報に関する情報を、受信側（１又は複数）に対して配布することができる。
Ｅ２ＥＮＰ９０８をこの周知のアプローチと一致させようとすることによって、完全な能力交渉８０６が、既にエンドツーエンドＱｏＳ前交渉フェーズ８０２を考慮していることに気付くべきである。実際、前交渉８０２フェーズは、ピアが、送受信の両方において使用したいと希望するストリームレベルのみのＱｏｓ契約１１０８を表示するために十分に汎用であると考えることができる。より詳細には、これは、<e2enp:qosdef name="contracts">セクションの<rtp:map>エレメントの属性「role」により可能になる。
しかしながら、これら２つの同名の属性は２つの異なるアスペクトを取り扱い、<e2enp:qosdef name="contracts">セクションで使用の「role」属性により、受信側は、更に送信側が流布した情報／嗜好に基づいて、ＡＰと、高レベルのＱｏＳ契約／ＡＰを明確に表すことが可能になる。その一方で、<cfg>セクションの「role」属性では、単に、アプリケーション／ミドルウェアが、上述したように、メディアストリーム２０６を正確に（能力アスペクト及びトランスポートアスペクトに関連して）使用するように自体を構築する。
<e2enp:qoscfg>セクションにより、ストリームレベルＱｏＳ契約１１０８から開始し、様々な抽象レベルにおいて、ＡＰ及びＱｏＳ関連８０４と、時間同期８０５制約の定義が可能になる。各々の抽象レベルは、このセクションの属性「name」によって識別される。
ストリームレベルにおけるこのセクションの一具体例は、次のＸＭＬ文書フラグメントで表される。
Figure 2005527133
Figure 2005527133
Figure 2005527133
以下のサブパラグラフにおいて、このセクションに現れる各エレメントについて詳細に説明する。
上述した具体例の<adapath>エレメントの最初の２つのインスタンスにより、<qosdef name="capabilities">セクションの<contract>エレメントのセットから引き出し、レジーバのみに関連した（上述した要求に基づいて）、１組の相互に対して一意のストリームレベルＱｏＳ契約１１０８を収集することによって、２つの明確な適応経路を定義することが可能になる。各々の<adapath>エレメントは、「ref_component」属性を介して、<cfg>セクションの特定の<component>に関連している。この属性は、ストリームレベルＡＰを記述する<adapath>エレメントについてのみ必須である。
各ＱｏＳ契約１１０８は、ＡＰにおける代のオプションであり、したがって、これらを定義する<alt>構造の使用である（ａｌｔは、代替（alternative）を示す）。上述した階層ＦＳＭモデルを予想することにより、各々のＡＰは、初期状態が所定の<adapath>構造のエレメント<default>によって明確に表示される、明確なＦＳＭを表す。
上述した階層ＦＳＭモデルを予想することにより、例えばファジー論理を使用して、監視されたＱｏＳレベルを、所定のＡＰに定義されたＱｏＳ契約１１０８のセットと一致させることによって、所定のＡＰ内でのＱｏＳ契約１１０８から他への切換の選択を動的に決定することができ、該ファジー論理は、エス・バッティ（S. Bhatti）、ジー・ナイト（g. Knight）編、インターネットアプリケーションのためのＱｏＳ適応化判断の実現（Enabling QoS adaptation decisions for Internet applications）、１９９９年、英国、ロンドン（[Bhatt99]、[BRAIN]）に記載されている。あるいは、<adapath>構造は、事前定義した、ＱｏＳ契約１１０８間の状態変化のセットを含んでいてよく、この場合、<event>構造は、上述の具体例にあるように、frame-rate-increase又はframe-rate-decreaseの所定のイベントの検出時に、どの変化を起動するかを表示する。これらのイベントは、アプリケーション及び／又はミドルウェアを考慮するべく設計できる、よく知られているモニタ通知を示す。これに関連して、イベントの名称及び意味論の両方が標準化作業に課される。所定の<event>は、その起動される１つを決定する、複数の経路と関連することができる。
個々の変化は、起動条件（保護パラメータとして表示）と、トランジション（ソース属性及び目標属性と共に表示）とに関連したＱｏＳ契約１１０８を記述する<path>構造に記述されている。<path>構造内のソース属性は、その属性の仕様を故意に省略できる場合が生じる可能性がある限り、オプションである。このような場合では、実際、関連するトランジションは、所定の階層ＦＳＭが、現在、一体どの状態に設定されているかに起因する。これにより、任意のＱｏＳ契約１１０８の変更を、所定のセット内で、関連するトランジション（デフォルトメカニズムの類）が起動される場合に定義されたものへとモデリングすることができる。上述の具体例では、イベントが供給された時点でどの契約１１０８が強制されたかに関係なく、より低いフレームレート（<reason>属性を参照）の検出によって起動されたイベント<video1-e-2>が、video1と名づけられた<adapath>構造により記述されたＦＳＭに、video-contract-1を強制させる。相互使用可能性を達成するためには、ピアが、理由属性の意味論に合意しなければならない点に留意すべきである。そのため、上述の具体例に出てくる「より高いフレームレート（higher-frame-rate）」又は「より低いフレームレート（lower-frame-rate）」といった用語は、その意味と共に標準化されなければならない。トランジションのセットのこの事前定義はオプションである。
属性「scope」は、関連するＳＤＰｎｇ９１２エレメントが必要とされたオプションと考慮されるのか（「applicable」）、又は希望されたオプションと考慮されるのか（「possible」）を示し、一方で、該属性は、返答（交渉カウンターオファー）の中に、関連するＳＤＰｎｇ９１２エレメントが確認されたか（適用可能）、又は拒絶されたか（適用不能）を示す。
Figure 2005527133
更に、回答者８１１は、カウンターオファーの中に、サポートできる能力と、その範囲とを示すことができる。所定の能力が「その通りに」サポートされる場合には、関連する識別子のみが、ａｐｐｌｉｃａｂｌｅに設定したスコープ属性と共に表示される。所定の能力がサポートされない場合には、関連する識別子を単純に省略する。
回答者８１１が、カウンターオファーの中で、<e2enp:qosdef>セクション（元のビッドのサブセットとして）内の所定の能力パラメタリゼーションの改善バージョンを提案している場合には、更新された全体の記述が、<e2en:qosdef name="capabilities">セクション及び<e2eup:qosdef name="contracts">セクションの両方において戻される。いずれの場合でも、ストリームレベルＱｏＳ契約１１０８を取り扱う<e2enp:qosdef name="contracts">セクションは、応答の中に、更新されたコーデックパラメタリゼーションのみを含んでいる。
これに加えて、回答者８１１は、新たなオプション（前交渉８０２の時点では申込者８１０には未知）を表示することができ、これは「possible」と示される。そのため、この概念は、後に使用できる潜在的オプションを申込者８１０に知らせることができるというものであるが、これは、申込者８１０が該オプションと一致する新たな能力を更新する場合に限られる。
<context>エレメントは、所定のメディアストリーム２０６の使用可能なアソシエーションを定義し、これにより、時間同期及び／又はＱｏＳ関連８０４制約の定義が可能になる。<context>エレメントは、それ自体が、基本的に高レベルなＱｏＳ契約１１０８を記述する。
上述の具体例において、ビデオメディアストリーム２０６及びオーディオメディアストリーム２０６は、所定のコンテキスト（「associational-1」）において関連しているとして、定義された時間同期、ＱｏＳ関連８０４制約と共に定義される。あるいは、オーディオメディアストリーム２０６（「associational-2」）のみを含むコンテキストを使用することもできる。
上述の具体例に示した<adapath>エレメントの第２の具体例には、いずれかのコンテキストを何時、及びどのように強制するかがが記述されている。この場合、<default>エレメントの使用は明白であり、オーディオメディアストリームの（「associational-1」）とビデオメディアストリームの組合せは、好ましいものとして表示される。オーディオメディアストリームのみが使用される場合には、（「associational-2」）が、例えば、ＱｏＳ違反に対処するために強制可能なバックアップケースとして考慮される。<adapath>エレメントの個々の子エレメントは、「ref_context」属性を介して、上述した<context>エレメントのインスタンスを参照する。
したがって、一般的な規則として、<adapath>エレメント及び<context>エレメントの反復発生が、参照の非巡回チェーンにおいて相互を参照し合う点に気付くことができる。代替の<context>構造は、ＦＳＭを定義する<adapath>構造内にグループ化される。
次に、このＡＰ、及び他の任意のもの（コンカレント）が、制約をより高レベルに設定する<context>構造内にラップされることが可能である。更に、このような<context>構造を定義する代替も存在するが、これはより高レベルなＡＰ内に収集される。この処理は再帰的に適用できる。
所定のユーザは、異なるピアと共に確立された所定のメディアストリーム２０６のセットにかけてリソース使用（及び、したがってＱｏＳ）を組織化するために、高レベルのＱｏＳ関連８０４と時間同期８０５制約を、格調したユーザプロファイル情報の形式として強制する。これに関連して、所定のユーザは、ピアとこの情報を交渉する必要はない。
しかしながら、所定のユーザが、後に、何らかの新たなコンストレイトの強制を要求する場合、又は、後の、現在開いている電気通信セッション１０２に対する幾つかのピア参加／離脱によって、既存の制約がもはや十分なものでないと知った場合には、所定の会議ポリシに基づいて、新たなＥ２ＥＮＰ９０８の回が必要かもしれない（これは基本的な本発明の範囲外である）。
最終的には、ピアは、更に、前交渉８０２、交渉８０６、再交渉８０８（「完全な」もの）を管理し、ＱｏＳ関連８０４アスペクトと時間同期アスペクト８０５に関連したより高レベルの仕様を含む、第三者エンティティ上に再分類される。このエンティティは、ティ・ロブルス（T. Robles）、エイ・カデルカ（A. Kadelka）、エイチ・ベライオス（H. Velayos）、エイ・ラペテライネン（A. Lappetelainen）、エイ・カスラー（A. Kassler）、エイチ・リー（H.Li）、ディ・マンダト（D.Mandato）、ジェイ・オジャラ（J. Ojala）、ビー・ウェグマン（B. Wegmann）編、３Ｇを超える全てのＩＰシステムのＱｏＳサポート（QoS Support for an All-IP System Beyond 3G）、（ＩＥＥＥ通信マガジン（IEEE Communication Magazine）、２００１年８月、Ｖｏｌ．３９、Ｎｏ．８）（[Roble01]、[BRAIN]。これらは基本的な本発明の範囲外である）に記載されたＱｏＳブローカの類と同様に機能する。
メディアストリームには、様々な方法で関連することができる。以下に示す具体例では、例えば、テレビ会議１２０４ａ／ｂの場合として意図したセッション１０２の概念を提案している。これに関連して、所定のテレビ会議１２０４ａ／ｂセッション１０２のコンテキスト内における、所定のユーザ（ユーザＡ）とそのピア（Ｂ、Ｃ、Ｄ）の間のメディアストリーム２０６の関係は、様々な方法でクラスタ化される。その結果得られたクラスタが、上述の<context>構造を使用して、Ｑｏｓコンテンツと関連する。
これに関連して、各クラスタは、所定のクラスタに属するメディアストリーム２０６の様々なアソシエーション間で、特定レベルの関連８０４／８０５を命令する制約のセットと関連する。これは、制約が、所定のアソシエーションに属する個々のメディアストリーム２０６のＱｏＳ仕様とは無関係に、各アソシエーションに属する全てのメディアストリーム２０６に影響することを意味する。そのため、<context>構造が、メディアストリーム２０６のコンカレントのバンドルについて、ＱｏＳ関連８０４／８０５を指定する。その後、他のコンテキストが、<adapath>構造（テレビ会議の１つのピア・インスタンス）に記述の通りに使用可能となる。
したがって、これらの<adapath>構造をＦＳＭの記述と比較することができ、このＦＳＭの記述の状態は、各々が、所定のユーザと所定のピアの間にメディアストリーム２０６の処理を記述する他のコンカレント<adapath>構造を含んでいる。この再帰的モデルにより、[Booch99]に記載の状態チャートを使用することが可能になる。
Figure 2005527133
Figure 2005527133
上述した再帰的アプローチについて続けると、更に高レベルの原理に基づいて、メディアストリーム２０６を更に統合することができる。例えば、所定のアプリケーションの全てのインスタンスによって管理された全てのメディアストリーム２０６を関連付けし、その結果得られたＱｏｓコンテキストを他のアプリケーションと区別し、更に、より高レベルのＱｏＳ関連８０４仕様を強制する。
Figure 2005527133
この具体例は、再び、上述した情報を表すための<e2enp:qosfcg>セクションの使用を示す。更に、この具体例では、この高レベルの仕様により、[Roble01]、[BRAIN]に記述のＢＲＥＮＴＡ概念と一致する、ローカルリソース消費上の制約を容易に表すことが可能になる様を見ることができる。
エンドツーエンドＱｏＳコンパクト再交渉フェーズ８０８の背後の概念は、例えばハンドオーバによるＱｏＳ違反からの復元といった時間クリティカルなタスク中に、完全な再交渉８０８の実施を回避するというものである。この目的は、ピアが、相互に対して、強制する新たな（前交渉した）ＱｏＳ契約１１０８をシグナリングできるようにし、及び／又は、（新たなアクセスネットワーク６０４及び／又はネットワークプロバイダにハンドオーバすると）その結果使用可能となる、及び／又は、もはや使用可能でなくなった、これら（前交渉した）ＱｏＳ契約１１０８をシグナリングできるようにすることで達成される。これに関連し、Ｅ２ＥＮＰ９０８のための特定のＳＤＰｎｇベースのサポートが必要となる。
<e2enp:enforce>新規ＳＤＰｎｇセクションにより、ピアの１つ（一般には、最初にＱｏＳ変更又は違反を検出したもの）が、他のピアに対して、前交渉したＡＰの中からどのＱｏＳ契約１１０８を強制すべきかをシグナリングできるようになる。
この概念は、前交渉したＱｏＳ仕様の階層構造に基づいて、シグナリング情報を伝達するというものである。すなわち、各ＱｏＳ契約名を正確にスコーピングする。少なくとも２つの異なる実現が可能であり、これは、ＱｏＳ契約１１０８の名称スペースを使用するか、又はＸＭＬ経路言語の推奨（XML Path Language Recommendation）（Ｗ３Ｃ、ＸＭＬ経路言語推奨バージョン１（W3C, XML Path Language Recommendation Version 1）、htt://www.w3.org/TR/xpath、１９９９年１１月）に記載されている、文書のある部分を参照するＸＰａｔｈ標準等の言語を使用するか、あるいは、未だ標準化されていない「ＸＰｏｉｎｔｅｒ推奨（Xpointer Recommendation）」（Ｗ３Ｃ、２０００、未完成、http://www.w3.org/TR/xptr）に記載のXpointer技術（[XPOINT]）を使用する。
上述の解決手法は、例えばドットキャラクタ等のセパレータキャラクタとして使用し、所定のツリーベースのＱｏＳ仕様内で所定のＱｏＳ契約１１０８から依存する、任意のより高レベルのＱｏＳ契約１１０８の名称を事前ペンディングすることによって、完全に指定された名称をＱｏＳ契約１１０８へ指定することに基づいている。しかしながら、この解決手法は、Ｅ２ＥＮＰ９０８セクションの、及び複数のＥ２ＥＮＰ ＰＤＵにかけて、（しばしば、非常に複雑で長い）名称の一貫した使用を必要とする。
更に、この解決手法は、アプリケーションに、所定の名称スペースを正確にパースできるよう強制する。
例えば、ビデオＡＰ内の、association-1-1ＱｏＳコンテキスト内、association-A-B ＡＰ外における、完全に指定したvideo-contract-2の名称は以下の通りになる。
Figure 2005527133
他の解決手法は、代わりに、ＸＰａｔｈ又はＸＰｏｉｎｔｅｒ技術（すなわち、基本的な本発明は、未だ標準化状態に到達していない）に基づいており、これらの両方とも、様々なＸＭＬ文書にかけて曖昧でない明白な要素のポインティングを考慮した現在の傾向を示している。
基本的な本発明の範囲において、我々は、概念に関連して、上述した他の解決手法（又は、これ以外の任意の同等物）と比較しても普遍性を全く損失することがない、この後者の解決手法の使用を決定した。選択した解決手法について説明するために、上述の具体例で使用のものと同一の情報を記述する、以下のＸＭＬ文書フラグメントを導入する。
Figure 2005527133
強制するＱｏＳ契約１１０８はエレメント<target>で表される。
このＸＭＬ文書フラグメントにおいて、所定のツリーブランチのルートエレメントの名称属性（association-A-B）の使用を容易に認識することができ、その一方で、同ブランチ内の他のエレメントは、対応する親の参照属性（ref_context、ref_adapath、ref_contract）を介して名づけられる。すなわち、<contract>エレメント、<context>エレメント、<adapath>エレメントの名称のみが複数のセクション／フェーズにかけて一意に使用されるべきであり、その一方で、上述したエレメントのＸＭＬ子エレメントの名称を任意で選択することができる。この方法論を用いれば、上述の仕様を所定のＱｏＳコンテキストに端末することによって、上述の具体例にあるように、メディアストリーム２０６レベルＱｏＳ契約１１０８のシグナリングのみでなく、高レベルのＱｏＳ契約１１０８のシグナリングも強制できるようになる。例えば、次のＸＭＬ文書フラグメントのようになる。
Figure 2005527133
このフラグメントは、他のピアに、現在強制されているストリームレベルＱｏＳコントラクト１１０８に関係なく、高レベルのassociation1-1が強制されるべきである旨をシグナリングするために使用できる（この場合には、デフォルト状態が、新たなＱＯＳコンテキスト内で、どのメディアストリーム２０６レベルのＱｏＳ契約１１０８を強制すべきかを表す）。更に、強制する特定のＡＰを他のピアにシグナリングするために、<e2enp:enforce>セクションを使用することもでき、この場合には、デフォルト状態を使用して、残りのより低レベルの情報を解決する。例えば、以下の<e2enp:enforce>セクションは、
Figure 2005527133
「video1」メディアストリーム２０６について「video-contract-1」を使用するために、ピアＡを強制するが、これは、この契約１１０８が、前交渉した<e2enp:enforce>セクション内にデフォルトとして指定されているためである。
上述のＸＰａｔｈ（また、更にはＸＰｏｉｎｔｅｒ）技術は、上述の原理に基づいて、ピアが、どのＱｏＳ契約１１０８を阻止するかを他のピアにシグナリングするこを可能にするためにも使用することできる。
これに関連して、新たなＳＤＰｎｇセクションである<e2enp:block>セクションが提案される。以下の具体例は、このような新たなセクションの例を示す。
Figure 2005527133
阻止するＱｏＳ契約１１０８は、エレメント<target>によって示される。
あるピアに、上述した原理に基づいて、どのＱｏＳ契約１１０８を阻止しないかについて、他のピアへシグナリングすることを可能にするために、上述のＸＰａｔｈ（また、更には、ＸＰｏｉｎｔｅｒ）技術も使用できる。
これに関連して、新たなＳＤＰｎｇセクションである<e2enp:unblock>セクションが提案される。以下の具体例は、このような新たなせくションの使用を示す。
Figure 2005527133
阻止しないＱｏＳ契約１１０８は、エレメント<target>によって示される。
この章で提示した解決手法の文脈において、ディー・クッチャー（D.Kutscher）他、「セッション記述及び能力交渉のための要件（Requirements for Session Description and Capability Negotiation）」、（ＩＥＴＦインターネット草案、未完成（IETF Internet-Draft, Work-in-progress）、<draft-kutscher-mmusic-sdpng-req-01.txt>）（[SDPNG01]）に記述された通りの、元のＳＤＰｎｇ９１２<constraints>セクションの意味論は、上述の新たなＳＤＰｎｇセクションにおいて記述のＱｏＳ仕様に適用した、ＱｏＳ関連８０４及び／又は時間同期８０５制約仕様の形式と解釈することがきる。上記文書は、マルチパーティによるマルチメディア会議シナリオにおけるセッション１０２記述及びエンドポイント能力交渉のためのフレームワークに関連した１組の要件を提供する。
ＳＩＰ９１０及びＳＤＰｎｇ９１２を、Ｅ２ＥＮＰ９０８がマッピングされるべきプロトコルとして考慮することによって、ＳＩＰ９１０が非対称プロトコルであると指摘ことが必要である。ＳＩＰ申込者９１４−回答者９１１モデルは、申込者９２４の側において、シグナリングエラー、障害状態又は例外（状態変更）の可能性が全く無い。Ｅ２ＥＮＰ９０８は、そのフェーズ内における数回のＳＩＰメッセージのラウンドトリップを必要とし、ラウントリップの全ての一方向メッセージは、Ｅ２ＥＮＰシグナリング内の関与する全てのピアにおいて、その正確性及び許容性の両方が証明されなければならない。更に、Ｅ２ＥＮＰフェーズの実行時におけるエンドピアの状態変更を考慮しなければならない。これらの変更は、関与したピアを考慮することができる。
−より高い優先順位の交渉（１又は複数）
−リソース管理及びＥ２ＥＮＰ９０８プロファイル設定に影響するピアのより高い優先順位の内部処理の開始
−リソースのドロップアウトを招くハードウェア及び／又はソフトウェアのクラッシュ
これに関連して、ＳＩＰ９１０を使用するＥ２ＥＮＰ９０８は、そのＳＤＰｎｇ９１２本体内で、申込者９１４によって生じた障害と、障害の理由とを示すエラーコード、又は申込者９１４と回答者９１１の両方についてのＳＩＰ９１０エラーコードを伝えなければならない。Ｅ２ＥＮＰ及びその構造に関する使用可能なＳＤＰｎｇエラーコードの研究を徹底的に考慮する必要がある。この問題を解決するために、Ｅ２ＥＮＰエラーコード及びシグナリングエラーを記述するそれぞれの新しいＳＤＰｎｇ ＸＭＬフラグメントは、可能な解決手法として考えられるが、簡素化の理由から具体例には示していない。Ｅ２ＥＮＰ９０８は、ピギーバックによってＳＩＰ９１０に適用されるため、ＳＤＰｎｇ９１２内のピギーバックされた各エラーコード及びメッセージを、Ｅ２ＥＮＰ９０８の開始によって考慮しなければならない。一般に、申込者９１４は、メッセージのＳＤＰｎｇ９１２部分内の理由／通知と共に通話を繰り返すことを考慮しなければならなず、また、回答者９１１は、更に、ＳＤＰｎｇ９１２メッセージ部分内に理由を記述することによって、ＳＩＰ９１０「ステータスコード（Status Code）」の使用を上手く生かすべきである。
Ｅ２ＥＮＰは、Ｅ２ＥＮＰシグナリングに関与する任意のピアにおいて生じている内外両方の障害状態、例外、エラーをシグナリングするために、同一の可能性を伝送できなければならない。これに関連して、Ｅ２ＥＮＰは、Ｅ２ＥＮＰによって影響を受けたピアにおいて、エラーコードを適用することにより、対称的でなければならない。
ジェイ・ローゼンバーグ（J. Rosenberg）、エイチ・シュルツリン（H. Schulzrinne）、ＳＤＰを伴うオファー／アンサーモデル（An Offer/Answer Model with SDP）、（ＩＥＴＦインターネット草案、未完成（IETF Internet-Draft, Work-in-progress）、<draft-rosenberg-mmusic-sdp-offer-answer-00.txt>）、（[SDPOA00]）によれば、「オファーは、オファーによって記述されたメディアを、一旦申込者９１４によって送信されたなら、これを受信する準備ができていなければならない」と述べることができる。このアプローチは、交渉したデータが、実行中の交渉８０６の時間内に、あるいはメディアストリーミングの開始前に無効になると、障害及び更新の両方の場合において、ピアの使用可能な動的な再構築を考慮しなければならないため、Ｅ２ＥＮＰ９０８及び適応メカニズムに対して耐障害性ではない。
更に、エンドピアと対話している幾つかの中間コンポーネント、及びシグナリング経路がプロトコルを理解しない場合に、これらによってプロトコルに妨害が生じる可能性がある。この場合、このような妨害を検出及び復元するメカニズムを設けるべきである。
以下は、使用可能なエラーの場合についての説明であり、この場合、変更状態と、生じた妨害を示すために、申込者９１４と回答者９１１間における何らかのフォームでの通知が必要である。矢印（→）は、可能な解決手法を示す。「Ａ」は回答者９１１を示し、「Ｏ」は申込者９１４を示す。
１．プッシュモード
・回答者９１１は、申込者９１４の提案がその能力にいずれにも一致しないことを検出する。
●回答者９１１はコーデックをダウンロードする能力を有する。
§回答者９１１は、自己のプロファイルデータのダウンロード及び調整に時間が必要であるため、トランザクションがもう少し長続きできる旨を申込者９１４に通知しなければならない。
→Ａ->Ｏ、「100 Trying」又は「183 Session Progress」を伴う応答。
●回答者９１１は、コーデックをダウンロードする能力を備えていない。
§回答者９１１がサービスである場合、→Ａ->Ｏ、回答者９１１がこのようなサービスを知っている場合には、「380 Alternative Service」で応答する。これにより、申込者９１４は、他のサービスと新たな前交渉８０２を開始することができる。
§→回答者９１１が、<e2enp:qosdef name="capabilities">から全ての申込者１０６の能力を除去し、該能力のためのカウンターオファー、契約１１０８（<e2enp:qosdef name="capabilities">及び<e2enp:qosdef name="contracts">）を作成する。
・申込者９１４がコーデックをダウンロードできる場合、→申込者９１４は、コーデックをダウンロードし、その後プロファイルを再組織化し、その後新たな前交渉８０２を開始する。
・申込者９１４がコーデックをダウンロードできない場合、→申込者９１４は、トランスコーダサービスの使用を考慮すべきである。
§→申込者９１４が、現在使用不能である能力サポートを要求する場合、回答者９１１は、更に、「606 Not Acceptable」を発行できる。
・回答者９１１は、申込者９１４の提案が回答者９１１の能力と一致するが、提供された契約１１０８がサポートされないと知る。
●回答者９１１が、自己のプロファイルをそれぞれトリミングする。
§回答者９１１は、プロファイル調整のために、トランザクションがもう少し長続きできる旨を申込者９１４に知らせなければならない。
→Ａ->Ｏ、「100 Trying」又は「183 Session Progress」で応答する。
§→申込者９１４が、現在は使用不能であるＱｏｓサポートを要求した場合には、回答者９１１は、更に、「606 Not Acceptable」を発行できる。
●回答者９１１が、自己のプロファイルを調整する能力を備えていない。
§回答者９１１がサービスである場合、→Ａ->Ｏ、回答者９１１がこのようなサービスを知っている場合には、「380 Alternative Servce」で応答する。これにより、申込者９１４は、他のサービスと新たな前交渉８０２を開始できる。
§回答者９１１が、申込者９１４の契約１１０８の範囲をトリミングすることによって、又は、全く新しい範囲を提案すことによって、（<e2enp:qosdef name="contracts">）についてカウンターオファーを作成する。→自己のプロファイルを調整し、その後、新たな前交渉８０２を開始することは、申込者９１４に依存する。
２．プルモード
・申込者９１４は、回答者９１１の返答が自己の能力のいずれにも一致しないことを知る。
●申込者９１４が、コーデックをダウンロードする能力を備えている。
§→申込者９１４は、コーデックをダウンロードし、自己のプロファイルをそれぞれ調整し、新たな前交渉８０２を開始する。
●申込者９１４は、コーデックをダウンロードする能力を備えていない。
§→申込者９１４は、トランスコーダサービスの使用を考慮すべきである。
・申込者９１４は、回答者９１１の提案が、自己の「contract」プロファイルのいずれとも一致しないことを知る。
●→申込者９１４は、回答者９１１へのカウンターオファーを作成する前に、自己のプロファイルを調整する。
●→申込者９１４は、回答者９１１の適合を強制するために、プッシュモードでの新たな前交渉８０２を開始する。
３．プッシュ／プルモード
この場合は、上述した２つの場合の組合せとして取り扱わなければならない。
申込者９１４及び／又は回答者９１１において前交渉及び保存したデータに幾つかが、以下に示すプロファイル情報の変化の理由から変更することがあり得る。
・異なるユーザが、自己のパフォーマンスポリシを装置（申込者９１４及び／又は回答者９１１）上にインポーズする。
・幾つかのより優先順位の高い（内部及び／又は外部）処理が、前交渉したプロフィールがそれ以降無効にするために、リソースを使用する。
・次に示すような幾つかのシステム構成の変更が実施される。
●占領又はリソースの故障で生じたローカルリソース予約による障害
●例えば、ネットワーク６０４が、より低いネットワークＱｏＳレベルに関連して、「ベストエフォート（best effort）」のみしかサポートしない場合には、ネットワークリソース予約による障害
●新たなコーデック及び／又はハードウェアサブデバイスがインストールされていることにより、能力とＱｏＳプロファイルに影響している。
申込者９１４及び／又は回答者９１１は、追加の前交渉８０２又は交渉８０６の開始を試みるまでには、このような未満了（premature expiry）を検出することができる。このような場合には、ピアは、その通信相手側において、前交渉したデータを消滅させる、したがって早期に「ゾンビ」状態にしなければならない。
→未満了の必要な表示は、次の新たな前交渉８０２によって表示される。これに関連して、<expires>エレメントがゼロに設定され、また、追加の命令「expire」を使用することもできる。
メディアストリーミングのリアルタイム内にプロファイル変更が生じた場合、→違反を検出した側が、新たな完全な再交渉８０８Ｅ２ＥＮＰ９０８処理を開始できるべきである。
呼ばれた側のピアが、サポートしていない交渉８０６モードについての表示を含んだメッセージを受信すると、そのピア側で障害が生じる。→このような場合、回答者８１１は申込者８１０に対して、回答者８１１が支持している交渉８０６モードをメッセージ本体内において表示する、「606 Not Acceptable」を送信する。申込者８１０は、交渉８０６フェーズを新規に開始しなければならない。
サービスは、複数のクライアントを平行してサポートできなければならず、したがって、交渉８０６モードについての嗜好を有することができる、これは、サービスを使用している場合である。
ピア及び／又はネットワーク６０４の障害により、ＳＩＰメッセージ（ＳＤＰｎｇ９１２）の本体、又はＳＩＰメッセージ全体を変形する可能性がある。回答者９１１がこのようなメッセージを受信した場合、可能な応答は、
・→「400 Bad Request」−ＳＩＰメッセージ全体が変形した場合
・→「420 Bad Extension」−ＳＤＰｎｇ９１２メッセージのみが変形した場合
申込者９１４が、変形したメッセージを受信するか、又は、「malformed-message」通知を受信した場合、→申込者９１４はＳＩＰ９１０要件を繰り返す必要がある。
第三者が、交渉８０６の開始を希望して交渉８０６と対話する場合、以下のステップが実行される。
・その通話が同じ優先権を有する場合
→ピアが後にその通話を取り扱えると決定した場合、ピアは「182 Queued」を発行する。
→他のピアの方が呼出が早く、また、応答側ピアの使用可能な能力を全て占領している場合、ピアは「600Busy」を発行する。これは、後に完全な再交渉８０８が要求される可能性がある場合には、既に実行中のメディアストリーム２０６によって、特に正となる。
→他のピアの方が呼出が早く、また、応答側ピアの使用可能な能力の全てを占領しているが、応答側ピアが、呼出がどのくらい長く続くか知っている場合には、ピアは「603Decline」を発行する。これは、優先順位に関連した類似のトランザクションが現在処理中であり、呼出者が待たなければならない場合でもある。
→ピアがサービスであり、共通の代替サービスに関する情報を有する場合には、ピアは「380 Alternative Service」を発行する。
・通話がより高い優先順位を有する場合、
●申込者９１４側において、
→申込者９１４は、回答者９１１に対して、交渉８０６の妨害（何らかのＳＤＰｎｇ９１２エラーコード）について通知できなければならない。
●回答者９１１側において、
→回答者９１１は、「600 Busy」又は「603 Decline」を、妨害を示す何らかの理由と共に発行できる。
→通話の優先順位、及び、既に実行中のメディアストリームが現在使用できるリソースとに基づいて、ピアは、迅速又は完全な再交渉８０８を実行するか、あるいは、そのメディアストリームを完全に取り消すことができる。
[SIPBIS04]によれば、「一般に、プロキシはセッション１０２記述を変更しないが、例えば、ネットワーク６０４アドレストランスレータについて、また、セッション１０２記述が暗号整合性メカニズムによって保護されていない場合には、これを行うことができる」と述べている。すなわち、プロキシが、メッセージのＳＤＰｎｇ９１２本体を理解し、また、これを変更できる。Ｅ２ＥＮＰ９０８メッセージがコンポーネントから変化して、プロトコルを理解しなくなってしまうことを防止するために、→デジタル署名及びダイジェストがＥ２ＥＮＰメッセージに適用されるべきである。更に、ピア同士が、Ｅ２ＥＮＰメッセージが、Ｅ２ＥＮＰ９０８内で考慮されていないネットワーク６０４コンポーネントによって変更されている旨を知らせ合えるようにするために、Ｅ２ＥＮＰ９０８のＳＤＰｎｇ９１２に幾つかの追加のシグナリングメカニズムが使用されるべきである。
メッセージ整合性は、将来的な研究のテーマであるセキュリティの問題と考慮しなければならない。一般に、回答者９１１がＥ２ＥＮＰ９０８を理解するが、そのバージョンを理解しない場合、→回答者９１１が、Ｅ２ＥＮＰ９０８バージョンがサポートされていないが、他のＥ２ＥＮＰ９０８バージョンはサポートされている旨を示すＳＤＰｎｇ９１２記述と共に、「606 Not Acceptable」メッセージを発行する。これは、更に、Ｅ２ＥＮＰ９０８バージョンの下位互換性を保証するためにも必要である。
スクリーニングされたネットワーク６０４の考慮（すなわち、プロキシ、ファイアウォールの使用）は、将来的な研究のテーマであるセキュリティの問題である。以下は、単に、セキュリティがどのようにＥ２ＥＮＰ９０８エラーメッセージングに影響を及ぼすかについての短い説明である。
１．スクリーニングコンポーネントは、Ｅ２ＥＮＰ９０８を理解しないが、ＳＩＰ９１０及び／又はＳＤＰｎｇ９１２を理解する。この場合、これを以降のＥ２ＥＮＰプロトコルに対してトランスペアレントにするために、スクリーニングコンポーネントを備えたＥ２ＥＮＰ９０８でない前交渉８０２が必要である。
２．スクリーニングコンポーネントがＥ２ＥＮＰ９０８を理解する。この場合、Ｅ２ＥＮＰは、後に非Ｅ２ＥＮＰ９０８情報（認証、セキュリティ等）に対する参照のフォームの非トランスペアレントなコンポーネントに関した情報を含むことができるため、非トランスペアレントなコンポーネントが、Ｅ２ＥＮＰメッセージを密かにチェックし、送信することが可能になる。この情報に関心のない申込者１０６ｂと回答者１０６ａ２は、単純にこれを破棄する。このアプローチにより、非トランスペアレントな（Ｅ２ＥＮＰ９０８に対して）コンポーネントを密かに取り扱うことによって、ネットワーク６０４を明確にトランスペアレントにし、幾つかのＳＩＰ９１０「Request Failures 4xx」メッセージを作成することが可能になるが、これによりＥ２ＥＮＰ９０８が悪影響を受ける。
Ｅ２ＥＮＰ９０８を考慮したＳＩＰ９１０の使用に伴う特別な問題は以下の通り要約することができる。
１．Ｅ２ＥＮＰ９０８がレイヤパラダイムを追従しない限り、Ｅ２ＥＮＰ９０８は、ＳＩＰ９１０上でのメタプロトコルである。
２．Ｅ２ＥＮＰセッション１０３における中間コンポーネントの妨害を回避するために、ＳＩＰメッセージ内でＥ２ＥＮＰメタプロトコルを明確に名称づけされなければならない。[SIPBIS04]内のＳＩＰ９１０定義によれば、「subject」ヘッダフィールドは、「セッション１０２記述をパーすすることなく、通話フィルタリングを可能にするために、要約を提供するか、又は、通話の性質を表示する」ため、したがって、次の表示
Figure 2005527133
を、Ｅ２ＥＮＰ９０８の開始要求内に使用して、Ｅ２ＥＮＰ９０８セッション１０３の開始を定義することができる。次に、Ｅ２ＥＮＰ９０８を理解する中間コンポーネントが、単純に、Ｅ２ＥＮＰ９０８通話のメッセージを、ＳＩＰ９１０定義に表示されている通りに転送する。
シグナリング経路に沿ってＥ２ＥＮＰ９０８メッセージを追跡するために、また、エンドツーエンド交渉８０６のための通話が確実に間違いなく理解されるようにするために、下に示すように、追加のメタプロトコル表示を、「Content-Type」ヘッダ内に含める必要がある。
Figure 2005527133
これにより、ＳＩＰ９１０を理解する全ての中間コンポーネントに対して、Ｅ２ＥＮＰ９０８のメッセージ本体が変更されない旨を知らせることができる。定義による「Subject」ヘッダが要求通話と共のみ使用され、これは、応答通話の不可侵性に関して不十分であるため、この追加的表示が必要となる。コンテンツタイプ名「application/e2enp/sdpng」の構造において、Ｅ２ＥＮＰ９０８の表示は真中にあるため、ＳＩＰ９１０、ＳＤＰｎｇ９１２を理解するが、Ｅ２ＥＮＰ９０８を理解しないコンポーネントが、メッセージ本体を誤使用することが回避される。
３．注意：第三者交渉を実施することによって、状態通話応答「380 Alternative Service」の追加的使用を考慮する必要がある。申込者／仲介者／回答者の構造モデルにおいて、回答者８１１は、仲介者１０６ａｌの観点から見て「代替サービス」である。
次のセクションでは、実際のケースにおいて、解決手法がどのように使用されるかについての幾つかの具体例を説明する。第１の具体例は、１対１、１対多のシナリオを使用するテレビ会議１２０４ａ／ｂサービスを取り扱う。第２の具体例は、第三者関連の交渉８０６シナリオを取り扱う。第３の具体例は、多対多シナリオのケースを示している。
より詳細には、図１２に示すように、２つの異なるテレビ会議セッション１２０４ａ／ｂに同時に参加する所定のユーザＡのケースを考慮する。ユーザＡは、他のピアのためのミキサとして機能するのではなく、むしろ、２つの異なるテレビ会議１２０４ａ／ｂに単に参加しているだけである。我々の専門用語において、テレビ会議アプリケーションの各々のインスタンスは「テレビ会議セッション」１２０４ａ／ｂと名づけられている。次に、ユーザＡ１２０２ａは、ユーザＢ１２０２ｂ、ユーザＣ１２０２ｃとのテレビ会議セッション＃１と、ユーザＤ１２０２ｄとのテレビ会議セッション＃２を開く。
この具体例において、我々は、単純に、ユーザＡ１２０２ａによって要求／確認されたＱｏＳのレベルに注目する。したがって、我々は、この具体例を、ユーザＡが、自分のピア１２０２ｂ／ｃ／ｄから入力されるメディアストリーム２０６について得たいと希望するＱｏＳのレベルの交渉８０６に限定し、更に、ユーザＡ１２０２ａが、テレビ会議セッション１２０４ａ／ｂ内に含まれる全てのメディアストリーム２０６上で、ＱｏＳ関連８０４と時間同期８０５を強制するのに十分な情報を得ていると仮定している。
このセクションの残りの部分では、以下のコンベンションを適用する。
１．まず、適用するプロトコル手順を詳細に示したメッセージシーケンスチャートを提示する。キーワードによってＳＤＰｎｇコンテンツが参照され、キーワード「bid-x」でビッドが参照され、キーワード「answer-y」で応答が参照され、両方の場合において、ｘとｙは増分整数正値を示す。
２．次に、別個のサブパラグラフにおいて、ＳＤＰｎｇコンテンツの詳細な記述が収集される。
以下の図式は、１対１通信シナリオ１００における前交渉を参照している。
・プッシュモード
Figure 2005527133
・プルモード
Figure 2005527133
注（１）：申込者９１４は回答者９１１に対し、第２のＯＰＴＩＯＮＳ方法で、返答を通知できる、又は通知できない。
例えば、ビデオオンデマンドシナリオの場合、申込者９１４は、ＲＴＳＰ ＤＥＳＣＲＩＢＥ方法を同等に使用して、所定のメディアに関連したＱｏＳ契約１１０８についての情報を収集してもよい。この場合、回答者９１１（例えばＶｏＤサーバ）には、実際のメディアストリーミングが開始するまで、申込者９１４（すなわちクライアント）の選択を通知する必要がない。しかしながら、この文書中で、我々は、ＳＩＰに基づく会議シナリオに注目しており、このシナリオでは、全てのピアが実質的に等しいフッテージ上にあると考慮され、各ピアは、後の通信のために、他のピアについて知らさせるつもりでいる。例えば、ピアＢがＱｏＳ関連８０４と時間同期８０５を実行しようとしている場合には、これは特に当てはまる。したがって、上述したシナリオは、これによって検討された具体例に適用される。
・プッシュ／プルモード
Figure 2005527133
注（２）：回答者９１１は、申込者９１４からビッドを受信すると、まず、経済原理のサブケースに基づいて（まずローカルリソースにコミットし、次に、リモートピアのリソースにコミットする）、自己のビッドを検査し（例えば、ユーザプロファイル情報に基づき）、次に、申込者９１１のビッドを検査する。
次のセクションでは、上述の具体例において、キーボードで入力したＳＩＰメッセージ本体、bid-x、answer-yを記述する。
Bid-1.1
Figure 2005527133
Figure 2005527133
Figure 2005527133
Figure 2005527133
answer-1.1
カウンターオファーは、回答者９１１がサポートする能力、及びその範囲を示す。所定の能力が「その通りに」サポートされる場合には、関連する識別子のみが、適用するスコープ属性のセットと共に表示される。
所定の能力がサポートされない場合は、関連する識別子（この具体例では、Ｇ．７２９オーディオコーデック、ＷＡＶＩビデオコーデック）が単純に省略される。所定の能力が、<e2enp:qosdef name="contracts">セクションにおいて更新される場合には、更新された記述全体が戻される。いずれの場合でも、<e2enp:qosdef name="contracts">は、更新されたコーデックパラメタリゼーションのみを返答内に含んでいる。この具体例では、ＰＣＭＵオーディオコーデックとＨ．２６１ビデオコーデックが、回答者９１１によってリパラメタライズされる。
その後、カウンターオファーは、申込者９１４がサポートしていない幾つかの能力を列挙することができる。この具体例では、Ｌ１６オーディオコーデックと、ＭＰＥＧ−２ビデオコーデックとが挙げられている。
回答者９１１は、<e2enp:qosdef="capabilities">セクション内の関連するラインとは無関係に、ビッドの<e2enp:qosdef name="contracts">部分へのカウンターオファーを提案することができ、更にこの反対も可能である。この具体例では、Ｇ．７２２オーディオコーデックの範囲が、<epenp:qosdef name="capabilities">セクション内に適合するとしてカウンターオファーされるが、これに関連する、<e2enp:qosdef name="contracts">セクション内のコントラクト１１０８はそのまま維持される。
上述したように、ＰＣＭＵオーディオコーデックに関連した契約１１０８へのカウンターオファーが、<e2enp:qosdef name="contracts">セクション内に提案され、その一方で、これに関連する、<e2enp:qosdef name="capabilities">セクション内のビッドはそのまま維持される。この柔軟性は、様々な方法のモジュラー式定義によってもたらされる。
元のビッドに関した変更はボールド体フォントで表示されている。この具体例では、回答者９１１は、以下の通り表示することによって、申込者に返答する。
−Ｇ７２９オーディオコーデックをサポートできない（関連するラインは除去されている）。
−Ｌ１６オーディオコーデックをサポートできる（構成で「possible」と表示される）。
−ＷＡＶＩビデオコーデックをサポートできない（関連するラインは除去されている）。
−ＭＰＥＧ−２ビデオコーデックをサポートできる（構成で「possible」と表示される）。
−ネットワークリソース最適化ポリシのみを使用できる。
−Audio-contract-1：提案されたサンプリング範囲のサブセットのみを適用できる。
−Video-contract-2：提案されたframe-rate-rangeのサブセットのみを適用できる。
Figure 2005527133
Figure 2005527133
Bid-1.2及びAnswer-1.2
上記ビッドと返答は、<e2enp:purpose>セクションが、この場合にはプルモードを表示している限り、上述の段落で説明した他のものとは異なる。
「OPTIONS」について：
Figure 2005527133
「Bid-1.2」について：
Figure 2005527133
「Answer-1.2」について：
Figure 2005527133
更に、ピアＢからの最終返答は次の通りである。
Figure 2005527133
上記ビッドと返答は、<e2enp:purpose>セクションが、この場合にはプッシュ／プルモードを表示している限り、上述の段落で説明した他のものとは異なる。「Bid-1.3」は、以下を<e2enp:purpose>として含む。
Figure 2005527133
より詳細には、「Answer-1.3＋Bid-1.4」は、Ｅ２ＥＮＰ９０８ ＳＤＰｎｇコンテンツが、回答者９１１のビッドと返答の両方を含んでいる場合を説明している。ビッドと返答を区別するために、その各々が、異なる<e2enp:purpose>セクションを特徴としている。すなわち、プッシュ／プル前交渉８０２のため、各々が独自の識別子を含んだ２つの前交渉８０２セッション１０３がインタリーブされる。
Figure 2005527133
申込者９１１が、そのビッドを、回答者９１１の嗜好（例えば、ユーザプロファイル情報から）に基づいて、更に申込者９１４のビッド（及び、最終的には、ＱｏＳ関連８０４制約及び／又は時間同期８０５制約）にも基づいて、定式化されている限り、回答者９１１のビッドは、<use>構造を介して、申込者９１４のビッドを参照する。
当然ながら、上述の具体例に従うことによって、「Answer-1.4」は、以下のような<e2enp:purpose>を含む。
Figure 2005527133
次のセクションでは、交渉及びリソース予約について記述する。
・プッシュモード
Figure 2005527133
Figure 2005527133
注（１）：「Bid-2.1」に関連してローカルリソースを前予約したら、任意の過剰リソースを開放するために、ピアＡが、交渉したサブセット「Answer-2.1」を最終的に予約する。
・プルモード
Figure 2005527133
Figure 2005527133
注（２）：「Bid-2.2」に関連してローカルリソースを前予約したら、任意の過剰リソースを開放するために、ピアＢが、交渉したサブセット「Answer-2.2」を最終的に予約する。
注（３）：「Bid-2.2」及び「Answer-2.1」は、「Answer-2.2」の場合の、「pull」に設定された属性「mode」と、「start-reservation」に設定された「type」とを特徴とする<e2enp:purpose>セクションを除き、実質的に、「Bid-2.1」、「Answer-2.1」と同等である（関連する）。
・プッシュ／プルモード
Figure 2005527133
Figure 2005527133
注（４）：「Bid-2.3」に関連してローカルリソースを前予約したら、任意の過剰リソースを開放するために、ピアＡが、交渉したサブセット「Answer-2.3」を最終的に予約する。
注（５）：「Bid-2.4」に関連してローカルリソースを前予約したら、任意の過剰リソースを開放するために、ピアＢが、交渉したサブセット「Answer-2.4」を最終的に予約する。
注（６）：「Bid-2.3」／「Bid-2.4」と、「Answer-2.3」／「Answer」は、「Answer-2.4」の場合に、プッシュ／プルに設定された「mode」エレメントと、「start reservation」に設定した属性「type」を特徴とする<e2enp:purpose>セクションを除いて、「Bid-2.1」、「Answer-2.1」と実質的に同等である（関連する）。
注（７）：「Answer-2.3」は受信用のＴｓｐｅｃであり、「Answer-2.4」は送信用のＴＳｐｅｃである。
注（８）：「Answer-2.3」は送信用のＴｓｐｅｃであり、「Answer-2.4」は受信用のＴＳｐｅｃである。
次のセクションでは、上述の具体例において、キーボードbid-x、answer-yで表示されたＳＩＰメッセージ本体について説明する。
Bid-2.1
このビッドは、<e2enp:purpose>セクション内の<use>構造を介して、前交渉した情報を一意に示すセッション１０３識別子を表示することによって、該前交渉した情報を参照する。この具体例において、参照した情報は、前交渉する能力、及びストリームレベルＱｏＳ契約１１０８のために使用された「Bid-1.1」である。あるいは、ピアは、直接「Bid-1.1」内で、この段落に含まれるＡＰ情報を前交渉することにより、交渉８−６フェーズを高速化することができた。
Figure 2005527133
Figure 2005527133
Figure 2005527133
Figure 2005527133
Answer-2.1
ＳＤＰｎｇ９１２<cfg>セクションを考慮すると、この具体例では、回答者９１１は、合意に達したトランスポート情報のみをリストすることによって、申込者９１４に返答する。元のビッドに関連した変更をボールド体フォント示す。この具体例では、回答者９１１は、以下を表示することで申込者に返答する。
・例えば、回答者９１１がＩＰｖ６をサポートしていないため、「AVP-video-3」オプションはサポートされない（関連するラインは除去）。
・「association1-1」：提案された「lipsync-delay」のサブセットを適用することができる。
・「association1-1」：提案された「aggregated-bw」のサブセットのみを適用することができる。
・「association1-2」：適用可能と確認された。
このフェーズでは、ピアは、<e2enp:qoscfg>セクションを介して、メディアストリーム２０６ＡＰ、アソシエーションＡＰを交渉し、この具体例では、回答者９１１が、ビッドＱｏＳ関連８０４、時間関連８０５制約のサブセットで応答する（変更されたエレメントのみが詳細に示され、変更はボールド体フォントで示される）。
Figure 2005527133
Figure 2005527133
リソースの受信を開始する命令をピアにシグナリングするために、ＳＤＰｎｇコンテンツは、以下の具体例に示すように、単純に、属性「name」を「start-reservation」に設定した<e2enp:purpose>セクションを特徴とする。
Figure 2005527133
予約が達成された旨をピアにシグナリングするために、ＳＤＰｎｇコンテンツは、以下の具体例に示すように、単に、属性「name」を「ready-reservation」に設定した<e2enp:purpose>セクションを特徴とする。
Figure 2005527133
上述で予想したように、交渉８０６フェーズを高速化するために、ピアは、この段落の残りの部分に記述したＡＰ情報を、「Bid-1.1」内で直接前交渉することができた。以下は、前交渉８０２ビッドと返答情報（プッシュモード前交渉８０２の単純な場合について）、更に、交渉８０６ビッドと返答（ここでもやはりプッシュモード）の具体例である。以下の具体例は、上述した関連するものに基づいている。
・Bid-1.1−メディアストリーム２０６ＡＰ、グループＡＰを伴う（ストリームアソシエーションに関連して）。
Figure 2005527133
Figure 2005527133
Figure 2005527133
Figure 2005527133
Figure 2005527133
Figure 2005527133
・Answer-1.1−メディアストリーム２０６ＡＰ、グループＡＰを伴う（ストリームアソシエーションに関して）。
Figure 2005527133
Figure 2005527133
Figure 2005527133
Figure 2005527133
・Bid-2.1−メディアストリーム２０６ＡＰ、グループＡＰのみを参照する（ストリームアソシエーションに関して）。
Figure 2005527133
Figure 2005527133
Figure 2005527133
・Answer-2.2−メディアストリーム２０６ＡＰ、グループＡＰのみを参照する（ストリームアソシエーションに関し）。
Figure 2005527133
Figure 2005527133
この場合には、申込者９１４と回答者９１１の両方が、<default>構造で示された契約１１０８でメディアストリーミングを開始することにより、前交渉ＡＰの強制に明確に合意する。
あるいは、交渉８０６の時点で適用されている何らかの条件により（及び、交渉８０６の直後に適用されるメディアストリーミングの開始により）、両方のピアが他の決定をした場合には、新たなデフォルト契約１１０８（１又は複数）を示す、<e2enp:qoscfg>の縮小バージョンを含めることができる。
階層ＦＳＭモデルにおいて、デフォルト状態は、所定の（後にネスティングされる）ＦＳＭの初期状態に関連することに留意すること。
再契約８０８の場合には、<e2enp:purpose>セクションの「mode」属性は使用されない。
Figure 2005527133
注（１）：両ピアは、以前に予約したリソースの量に関連して、任意の要求されたリソースを追加することにより、及び／又は、任意の過剰リソースを解放することにより、再交渉したＱｏＳレベルに関連してリソースの予約を行う。
注（２）：「Command-start-reservation」及び「Command-stop-reservation」の記述については、上述の記述を参照されたし。
注（３）：ＤＯ法は、ＢＹＥ法の単純で信頼性の高い承認メカニズムを使用するものである。これ以外の方法も可能である。例えば、再招待の使用は、ピアが、調整された安全な方法で、新たなＱｏＳレベルを有するメディアストリーミングを開始することを保証する、３方向を強制する。ピアに、他の端末の使用、及び、エンドツーエンドＱｏＳ完全再交渉８０８の実施を強制させることは有利である。正しい方法の選択には論議の余地がある。
注（４）：このメッセージ内の「Answer-3.1」は、「start-reservation」に設定された属性「type」を特徴とする。
以降のセクションでは、上述の具体例のキーボードbid-x、answer-yで示したＳＩＰ本体について説明する。
Bid-3.1
この具体例では、前のフェーズ中に（その内の最後のフェーズは、<e2enp:purpose>セクションの<use>エレメントでラップされた<session>エレメントにより識別されている）既に交渉された情報に関連し、ピアＢがピアＡに対して、他のＱｏＳ契約の強制を要求する。より詳細には、ピアＢがピアＡに対して、デフォルトである「video-contract-1」の代わりに、現在アクティブなアソシエーションである「association1-1」のビデオメディアストリーム２０６「video1」に関連し、ストリームレベルＱｏＳ契約１１０８「video-contract-2」の強制を要求する。この命令は、<enforce>セクションで示される。このＸＭＬフラグメントにおいて、ＸＰａｔｈは、<enforce>セクションの概念を把握するために、簡素化した方法で示されている。これにより提案されるＳＤＰｎｇ拡張の、厳正に形式的な全体的な記述は後に示す。
更に、ピアＡは、そのvideo-contract-1が、新たな種類のアクセスネットワーク６０４／ネットワークプロバイダにもはや適用されないことを知り、そのため、ピアＡは、その契約１１０８について「block」をシグナリングする。予備契約１１０８が使用可能であり、現在有効である場合には、このビッド内に、更に「unblock」信号を含めることができる。
Figure 2005527133
Figure 2005527133
Figure 2005527133
あるいは、更に、ピアＢがピアＡに対して、幾らかより高いレベルの情報を単純に表示することも可能であり、この場合、ピアＡは、より低いレベルの情報の残り部分を、デフォルト値に再分類することで解決する。例えば、次の<e2enp:enforce>セクションが、ピアＡに対して、「video1」メディアストリーム２０６について「video-contract-1」の使用を強制するが、これは、前交渉した<e2enp:qoscfg>セクションにおいて契約１１０８がデフォルトとして指定されているたである。
Figure 2005527133
更に、ピアＢはピアＡに対して、前交渉した交渉情報から選択した、全く他のグループのメディアストリーム２０６に切り換えるよう要求することができる。例えば、ピアＡとピアＢ間において、メディアストリーム２０６の現在アクティブなアソシエーションが、「association1-1」であると仮定すると、ピアＢはピアＡに対して、次の<e2enp:enforce>セクションの具体例に示すように、「association1-2」を選択するよう要求することができる。
Figure 2005527133
Answer-3.1
要件３１によれば、回答者９１１は、申込者９１４のビッドの許可、又は、より低いＱｏＳレベルの単純な選択に対するその応答を、前交渉した情報から選択したものに制限しなければならない。上述の段落において示した具体例に従えば、これにより、ピアＡは、提案をその通りに受領するか、又は、前交渉した情報から他のオプションを選択することができ、この場合でも、申込者９１４の元のビッドは満たされる。
前出の場合では、「Answer-3.1」は次のようになる。
Figure 2005527133
回答者９１１の返答内に<e2enp:enforce>セクションが存在しない場合、回答者９１１が申込者９１４のビッドに合意したことを示す。
回答者９１１（この具体例ではピアＡ）がより低いＱｏＳレベルを好む場合には、「Answer-3.1」は次のようになる。
Figure 2005527133
Figure 2005527133
この具体例では、提案されたvideo-contract-1により定義されたものと比較して、より低レベルのＱｏＳを定義するvideo-contract-3が、２つのピア（上述の具体例には示していない）間で既に交渉されていると仮定する。あるいは、ピアＡが、例えば上述の段落で説明した他のアソシエーションを指定することによって、より低レベルのＱｏＳを指定することができる。
Figure 2005527133
次のセクションでは、１対多通信シナリオ２００における前交渉８０２について説明する。
・プッシュモード
Figure 2005527133
注（１）：様々な応答「Answer-1.1.Bj」同士は、一致、部分的に相違、完全に相違することができる。これらの応答は、上述した「Answer-1.1」に実質的に相当する。
注（２）：ピアＡは、ピアＢｊからの全ての応答を受信した後に、ＱｏＳ関連８０４制約、時間同期８０５制約を強制することによって、ピアＢｊと、新たなより低いＱｏＳレベルを再交渉することができる。
・プルモード
Figure 2005527133
注（３）：様々な応答「Answer-1.2.Aｊ」同士は、一致、部分的に相違、完全に相違することができる。「Answer-1.2.Aj」は、実質的に、上述した「Answer-1.2」に相当する。「Bid-1.2」も、実質的に、上述したものに相当する。
注（４）：ピアＢは、局所的な許可制御中の、各ピアＡｊへ返答する前に、ＱｏＳ関連８０４制約、時間同期８０５制約を強制することができるが、一般に、様々なＡｊは、このＥ２ＥＮＰ９０８フェーズを、相互とは関係なく実施する。
したがって、一般には、ＯＰＴＩＯＮＳへの応答を、関連するＳＩＰタイマ継続時間を超えて保留することは不可能である。あるいは、ピアＢは、特定の時間ウィンドウ内で、要件を受諾する決定をすることができ、その後、ピアＢはＱｏＳ関連８０４制約、時間同期８０５制約を強制し、これにより、各ピアＡｊと新たな前交渉８０２を実施することができる。
この場合、ピアＢは申込者９１４の役割を果たすことになる。これにより、具体例に示すように、ピアＢは、講義シナリオにあるように送信側であることができるようになるが、この講義シナリオは、まず各受信側とＱｏＳを個々に前交渉し、その後、ＱｏＳ関連８０４制約、時間同期制約を強制するべく、最終的に幾つかの前交渉８０２を戻すというものである。
１対多のための双方向接続の前交渉によって、実際の多対多接続が可能になるため、ここではこのケースを取り扱うことはしない。
双方向交渉８０６は、多対多シナリオのケースと同様になる可能性があり、また、特に同期問題に注目すべきであるため、双方向交渉についての提示は省く。したがって、次に示すシナリオは、１対多関係の「１つの」ピアが送信側（受信側）であり、このような関係の「多数の」ピアが受信側（送信側）である場合については有効である。
・プッシュモード
Figure 2005527133
Figure 2005527133
注（１）：「Bid-2.1」は、実質的に、上述の具体例で説明したものに相当する。
注（２）：任意の過剰リソースを解放するＢｊの応答上のリソースのバランスをとる。
注（３）：command-start-reservationシグナリングを使用することによって、ピアＡは、ネットワークリソース予約を、全ての｛「Answer-2.1.Bj」｝に基づいて、あるいは、そのサブセットのどれが現在使用可能であるかのみに基づいて実施すべきであるか、又はいつ実施すべきであるかを決定することができるようになる。
注（４）：Ｂｊの「answer-2.1.Bj」に基づく。
・プルモード
Figure 2005527133
Figure 2005527133
注（５）：様々な応答「Answer-2.2.Aj」同士は、一致、部分相違、又は完全に相違することができる。
注（６）：「Bid-2.2」、「Answer-2.2.Aj」は、「pull」に設定した属性「mode」と、更に、「Answer-2.2.Aj」の場合には、「start-reservation」に設定した属性「name」とを特徴とする<e2enp:purpose>セクションを除いて、実質的に、「Bid-2.1」、「Answer-2.1」に（関連的に）相当する。
注（７）：Ｂｊの「Answer-2.2.Aj」に基づく。
注（８）：command-start-reservationシグナリングを使用することによって、ピアＡは、ネットワークリソース予約を、全ての｛「Answer-2.2.Aj」｝に基づいて、あるいは、そのサブセットのどれが現在使用可能であるかのみに基づいて実施すべきであるか、又はいつ実施すべきであるかを決定することができるようになる。
１対多のための双方向接続の前交渉によって、実際の多対多接続が可能になるため、ここではこのケースを取り扱うことはしない。
一般に、マルチパーティ接続の再交渉８０８は（１対多接続がそうであるように）、１対１接続のケースと同等であると考慮されるべきである。１つよりも多いメディアストリーム２０６を同時に再交渉すべき場合には、要件３７により、２つの特別なケースのみが得られる。これら２つのケースは、以下の状態によって決定される。
・中央コンポーネント（「１」）は違反を検出すると、影響を受けたメディアストリーム２０６が、グループのメディアストリーム２０６であるを調べる必要があり、また、それがグループに属する場合には、それは、影響を受けたＱｏＳの意味において、グループのコンテキストである。単一のメディアストリーム２０６により、更に、グループのコンテキストが中央コンポーネントによって影響を受けてないことを知ることにより、対応する各ピアとの１対１交渉８０６を実行し、あるいは、次に示す第１のケースに記述しているように、中央コンポーネントが１対多再交渉８０８を実行する。
・「多数」の内の１つが違反を検出すると、その旨を中央コンポーネントに１対１形式でシグナリングするが、これは、「多数」が、中央コンポーネントが後に実行するメディアストリーム２０６のグループ化について知らないためである。中央コンポーネントのチェック以下にして進めるかを決定するために、中央コンポーネントが、影響を受けたメディアストリーム２０６の依存性を検査する。
○メディアストリーム２０６がグループに属していない、又は、グループのコンテキストが影響されていない場合には、中央コンポーネントは、１対１形式での交渉８０６を継続する。
○中央コンポーネントは、依存性が単一メディアストリーム２０６以外にも影響していることを検出すると、これ以降、自己が再交渉８０８に対して応答可能になる旨を、待ち状態の申込者９１４（以下のケース２に示す通り）に対してシグナリングする。申込者９１４は、その通話を取り消し、中央コンポーネントからの申込者を待たなければならない。
次に、１対多再交渉８０８のケースの２つの具体例を示す。
１．所定の１対多接続の中央パーティが、その所定のグループの単一メディアストリーム２０６に影響する違反を検出し、更に、このグループのプロファイル設定（すなわち、前交渉した高レベルＡＰ）に基づいて、全体メディアストリーム２０６グループの必要な適合を実行する。１対多接続の場合には、実際、１つのみのピアが、メディアストリーム２０６のグループ化を取り扱う「１」として機能している。
Figure 2005527133
Figure 2005527133
２．「many」のピアの１つが違反を検出する。
Figure 2005527133
次に、第三者支援交渉がどのようにＥ２ＥＮＰ９０８を使用するかについて記述する。
交渉パーティは次の通りである。
Ａ−仲介が行われたピア
Ｂ−仲介者ピア１０６ａ１、
Ｃ−仲介者１０６ａ１を指定する申込者ピア９１４
第三者支援交渉は、申込者９１４が仲介装置を呼び出し、この各々のピアが、自己のみでは呼出を取り扱えないと知るが、そのを呼出を他の回答者９１１へ委託する能力がある場合に起動される。検出された回答者９１１は、呼出側の申込者９１４が、仲介者１０６ａ１の代わりに、また、装置が仲介者１０６ａ１である、各々のユーザの認可によって使用する、仲介者１０６ａ１の観点からして代の装置である。
仲介者１０６ａ１との前交渉８０２の目的は、仲介者１０６ａ１が、この先起こり得るリディレクションに関与するピアに関する情報を収集できるようにすることである。仲介者１０６ａ１はこれを、何らかのサービス検出メカニズム、例えば，ジニ（商標）ネットワーク６０４技術（JINITM Network 604 Technology）（http://www.sun.com/jini/を参照）（[JINI]）、[BLUE]に記載の通りのブルートゥースＳＤＰ（Bluetooth SDP）等を使用して、又は、ファシリテーションが実施された、影響を受けたピアを直接呼び出すことによって、実行する。後者のケースでは、前交渉８０２を、１対１前交渉８０２のケースと同様に実行することが可能であり、この場合、仲介者１０６ａ１は申込者９１４として機能し、また、仲介が実施されたピアは回答者９１１として機能する。これに関連して、申込者９１４が仲介者１０６ａ１である（<mediation mode="third-party-assisted"/>）旨を示すために、<e2enp:purpose>セクション内に特別に表示されている。
仲介が実施されたパーティが、ミディエー他１０６ａ１との前交渉８０２を開始する場合には、ＳＩＰスキームは以下の通りになる。
Figure 2005527133
仲介者１０６ａ１は、単純に、Ａ（回答者）の設定をピックアップし、これを使用して仲介を実施する。仲介側ピアと申込者９１４の間の前交渉８０２は、１対１前交渉８０２によるものと非常に類似しており、回答者９１１が仲介者１０６ａ１である（<mediation mode="thied-party-assisted"/>）旨を目的セクション内に表示する。申込者ｓ９１４は、プッシュモード、又は、プッシュ／プルモードを使用して、仲介者１０６ａ１のファシリテーティング機能を起動する。仲介者１０６ａ１は、ＯＰＴＩＯＮＳへの応答として「200 OK」の代わりに「380 Alternative Service」を使用することにより、これから通信するピアではないことを示す。申込者９１４は、このフェーズで、他のピアの存在について既に通知されており、また、呼び出されたユーザが情報通知され、他のピアの使用に合意している場合には、申込者９１４が、１対１交渉８０６スキームを適用することにより、その他のピアとの交渉８０６を直接開始する。
第三者支援交渉は、仲介ピアがビットをサポートできない場合にそのファシリテーション機能を起動するために、常に、仲介者１０６ａ１とのプッシュモード、プッシュ／プルモードで実行されなければならない。
Figure 2005527133
Figure 2005527133
この交渉の結果、ピアＣは、どれがピアＡであるか、また、その設定について知り、更に、ピアＡとの通常の１対１交渉を開始することが可能になる（１対１交渉８０６の具体例を参照）。
仲介者１０６ａ１にかけて再交渉８０８を実行することは、通信相手に新たな装置を選択する際における完全な再交渉８０８の場合のみに意味を為し、これ以外の場合には、再交渉８０８が非常に複雑化してしまうだけである。申込者９１４は、交渉８０６フェーズから、その回答者９１１がどれであるのかを正確に知っているため、実際のところ、これはＥ２ＥＮＰ９０８の簡素化の必要性とは矛盾し、どのような場合においても真に論理的ではない。再交渉８０８が仲介者１０６ａ１を調べることにより、仲介者１０６ａ１がプロキシとして機能する。完全な再交渉８０８の場合には、この処理は、上述した前交渉８０２及び交渉８０６と同様である。再交渉８０８により、仲介者１０６ａ１は、更に、交渉したデータの完全性の必要性も満たさなければならない。
多対多通信シナリオ３００、４００、５００の構造及び交渉８０６は、考慮されたシナリオ、例えば会議、ゲーム等に関連したコンテキスト依存である。このケースには一般的な解決手法は使用不能であるが、ジェイ・ローゼンバーグ（J. Rosenberg）、エイチ・シュルツリン（H. Schulzrinne）、ＳＩＰ９１０におけるマルチパーティ会議のためのモデル（Models for Multi-party Conferencing in SIP 910）、ＩＥＴＦ ＳＩＰ ９１０ＰＩＮＧ 分科会、未完成（IETF SIP 910PING Working Group, work in progress, <draft-resenberg-sip-conferencing-models-01.txt>）、（[Rosen01]）、また、ジェイ・ローゼンバーグ（J. Rosenberg）、エイチ・シュルツリン（H. Schulzrinne）、ＳＩＰにおけるマルチパーティ会議のためのモデル（Models for Multi-party Conferencing in SIP）（ＩＥＴＦシッピング分科会、未完成（IETF SIPPING Working Group, work in progress, <draft-ietf-sippingconferencing-models-00.txt>）、（[Rosen00a]）に記載の何らかの、簡単な、トピック依存性のシナリオを用い、更に、これらを、Ｅ２ＥＮＰ９０８に関連して開始することは、マルチパーティ接続を適用した際に、Ｅ２ＥＮＰ９０８がどのように機能するかを理解する助けとなるだろう。次に示す、[Rosen00a]を、Ｅ２ＥＮＰに関連して、更に拡張させた具体例では、アドホックネットワーキングに接続している。
図１３中の符号を考慮することによって、次に示す、Ｅ２ＥＮＰ９０８を適用するステップが考慮される。
・符号１ −ＡがＢにＱｏｓビューを供給する。
・符号４ −Ｂが会議サーバに、Ａ及びＢのＱｏＳビューを供給する。
・符号４〜符号１４ −ｃｏｎｆ．サーバが、自己の会議ビュー（符号５）をＢに伝送し、Ｂが、自己のための予約をサーバに対して行う。
・符号１５ −Ａが、会議上の会議サーバビューについて、Ｂより知る。
・符号１７ −Ａが、Ｂから伝送されたサーバビューをＱｏＳ上に有する会議サーバを招待する。Ａ側と、会議サーバ側の両方が既にこの共通ビューについて知っているため、これは、単にサーバＱｏＳビューへの参照でしかない。
・符号１７〜２７ −Ａが、自己のための予約をサーバに対して行う。
・符号３２ −Ｂが、会議でのサーバビューをＣに供給する。
・符号３４ −Ｃが、Ｂからの情報によって規制された自己の会議でのビューをサーバに供給する。
・符号３４〜４４ −Ｃが、自己のための予約をサーバに対して行う。
・符号４５ −Ｃが、自己の準備が整った旨をＢに知らせる。
・符号４９〜５２ −Ｂが、全ての相手の準備が整い、サーバは全ての相手に開始命令を伝送しなければならない旨を会議サーバに追加的に知らせる。
この具体例から、更に、予約を考慮した１対１シナリオからの幾つかの概念を、ユーザと会議サーバの間のピアツーピア通信に適用できることは明白である。上述した１対１交渉の具体例の全てにおいて、ビッド及び応答は共通である。この具体例は、ＳＩＰメッセージでの予約手順を、１対１シナリオと同様の方法で示すが、ＳＤＰｎｇオーバヘッドとして使用するメッセージの種類が唯一異なる。上述の具体例によれば、エンドピアは、次の３つの異なる役割を演じる。
・アドホック会議の起動側−Ｂと同様
・既に参加している会議参加者−Ａと同様
・新たな会議参加者−Ｃと同様
これら３つの役割は、交換されたＳＤＰｎｇメッセージに関連する、異なる３種類の、会議サーバとの通信パターンと関連している。
最大の通信オーバヘッドはＢ（アドホック会議の起動側）を有するが、これは、該オーバヘッドが、既に参会している会議参加者の全てのＳＤＰｎｇメッセージを含んでいるためである。Ｂのこの能力は一種の仲介能力であり、影響を受けたピアに、会議サーバとの交渉を強制させることによって、更に、該制御をサーバに転送するべく交渉を終了することによって、会議を初期化する。
最少の通信オーバヘッドは、Ａ等の既に参加している会議参加者を有するが、これは、会議サーバが、Ｂを介してＡのプロファイルを既に知っており、Ａは、単に、どのプロファイルがこれに属するかを、サーバに対して知らせればよいためである（図１３、メッセージ１７を参照）。
新たな会議参加者Ｃは、既に参加している会議参加者の会議サーバプロファイルから確認されたものと知り合い、これにより、その決定設定を最小化し、会議サーバとより迅速な合意に達することができるようになる。したがって、Ｃの通信オーバヘッドは、自己のみでサーバとの合意を満たさなければならないため、１対１通信による通信オーバヘッドとほぼ同一である。
次の具体例は、上述の失敗したケースの幾つかを示す。
１対１通信シナリオ１００
・前交渉８０２
Figure 2005527133
注（１）：回答者９１１は、その時点で、如何なる呼出も扱う能力が無い場合には、「600 Busy」で応答する。あるいは、回答者９１１は、後の何時に、如何なる呼出が発生するかについてを、この時点でわかっている場合に示す「603 Decline」で応答してもよい。これは、プッシュモード、プルモードの両方にも使用できるが、プルモードでは、「OPTIONS」呼出はビッドを含んでいない。
・交渉８０６
Figure 2005527133
注（２）：他の申込者９１４の方が呼出の発行が早く、回答者９１１の使用可能な能力の全てを占領した場合には、回答者９１１は「600 Busy」を発行する。他の申込者９１４のほうが呼出の発行が早く、回答者９１１の使用可能な能力の全てを占領したが、回答者９１１が、呼出があとどの程度続くかを知っている場合には、回答者９１１は「603 Decline」を発行する。これは、優先順位に関連して類似のトランザクションが現在処理中であり、呼出側が待たなければならない場合にも同様である。
申込者９１４が、現在の使用可能でないＱｏｓサポートを要求した場合、回答者９１１は、「606 Not Acceptable」を発行する。回答者９１１にとって申込者９１４の条件が許容不可能であるが、これらの条件をサポートできる他のサービスを知っている場合、回答者９１１は、「380 Alternative Service」を発行する。この呼出は、ＶｏＤ等の自動サービスと共に使用しなければならない。上述したいずれの場合においても、前交渉した条件はもはや無効であるか可能性があるため、申込者９１４は、「OPTIONS」で新たな呼出を開始してよい。このスキームは、全ての通信モード（プッシュ、プル、プッシュ／プル）に適用可能である。これらのモード間の唯一の違いは、「INVITE」を伴う初期ビッドの送信、又は、後におけるその送信（プルモード）である。
・再交渉８０８：再交渉８０８による失敗のケースは、交渉８０６による失敗のケースと同様である。各々のエラー表示は、申込者９１４の「DO」呼出への返答として戻される。
１対多シナリオによる交渉８０６フェーズの構造は、１対１シナリオのものと非常に類似するため、この場合、１対１シナリオに記載したＥ２ＥＮＰ９０８エラーケースもやはり妥当である。１対多シナリオは、「多数の」ピアにより生じる複数の失敗の可能性と繋がるため、中央コンポーネント（「１」）は、このような失敗に対処する能力を備えていなくてはならない。これらの失敗に対処するための提案を、以下の幾つかの具体例に示す。
−「１」として機能するピアと、「多数」として機能する各ピアとの間における各交渉８０６の接続は、ＳＩＰ９１０シグナリングに関連した単一のスタンドアロン型接続として考慮すべきである。このように、交渉８０６フェーズに関与した「多数」として機能するピアは、同グループの他のピアが犯す失敗について知る必要はない。障害への対応は中央コンポーネントにおいてのみ実施される。
−幾つかの交渉８０６接続が制限時間内に成功しない場合には、これらは、後に繰り返す交渉８０６において呼び出される。中央コンポーネントが、ＳＩＰ９１０呼出の時間切れにより、又は、受信側からのＳＩＰ−エラーメッセージを受信することにより検出する。Ｅ２ＥＮＰ９０８は、整合性を要するが、隔離の必要はないため、成功しなかった呼出のカレントデータを保存しておくだけで、失敗前に、その呼出を反復することでカレント状態を参照するのには十分である。すなわち、「アンドゥ」が不要なため、Ｅ２ＥＮＰ９０８実行の完全な状態での保存が必要ない。
−中央パーティは、メディアストリーム２０６をオンライン上で再構築できなければならない。制限時間内で、幾つかのメディアストリーム２０６の再交渉が成功しない場合には、中央コンポーネントが、成功したもののみを再構築し、後に、成功しなかったものについて再交渉を試みる。ここでも、成功した交渉８０６は、他の幾つかが失敗したことについて知る必要はない。
−中央コンポーネントは、交渉８０６が成功しなかったパーティを、例えば３回のように限られた回数で、数回の呼出を試みる。３回目の呼び出で交渉８０６フェーズが成功しないパーティがある場合には、そのパーティはグループから排除され、また、例えば、データ接続上でもＲＴＰシグナリングが存在しない場合には、後に該パーティのメディアストリームが取り消される。このアプローチにより、不成功であった「多数」に復元の機会が与えられ、これにより、後に自己が交渉８０６呼出を実行できるようになる。
−交渉８０６呼出を並列実行することによって、交渉８０６の迅速な実行が可能になる。これに関連して、中央コンポーネントは、そのリソースを柔軟に再構築する可能性を得るはずである。中央コンポーネントが幾つのパーティを並列してサービスできるか、また、中央コンポーネントが「486 Busy Here」又は「380 Alternative Service」を発行した場合に（中央コンポーネントがサービスであり、代替のものについて知識がある場合）、この限度を超過するか否かを知る必要がある。
次のセクションでは、リロケーション１０８検索が失敗した、第三者支援Ｅ２ＥＮＰのケースを参照する。
Figure 2005527133
仲介者１０６ａ１は、代替が見つからないので、申込者９１４は、仲介者１０６ａｌの設定に適合させながら、プルモードで再度呼出を行うべきである、という旨をシグナリングする。
ユーザが呼出リロケーション１０８を断った場合、考えられる交渉８０６の結果は次のようになる。
Figure 2005527133
Figure 2005527133
仲介者１０６ａ１は次の通り返答する。
・「480 Temporarly Unavailable」、ユーザが信号又はポップアップしたウィンドウに対して特定の時間反応しない場合には、そのユーザは使用不能であると考慮される。
・「603 Decline」、ユーザが呼出を明確に断る場合
・「606 Not Acceptable」、ユーザが、通話の委託を断る場合
予想される回答者９１１（Ｃパーティ）との交渉８０６が成功しなかった場合、又は、呼出を受けないパーティへ委託される場合
Figure 2005527133
Figure 2005527133
これらの応答の意味は、
・「480 Temporarly Unavailable」、ユーザが信号又はポップアップしたウィンドウに対して特定の時間反応しない場合には、そのユーザは使用不能であると考慮される
・「603 Decline」、ユーザが呼出を明確に断る場合
・「606 Not Acceptable」、ユーザが通信を希望するが、呼出の委託が間違ってしまった場合。この応答により、回答者９１１としての仲介者１０６ａ１との新たな交渉８０６を開始することが可能になる。申込者１４は、容易化の機能を開始することなく、自己を仲介者１０６ａ１のプロファイルに適合させるために、プルモードでの新たな交渉８０６の実行を取り扱わなければならない。
結論として、基本的な本発明と最新技術との間における主要な利点的相違は、以下の通り簡略的に要約することができる。
−Ｅ２ＥＮＰ９０８概念を実現するＳＤＰｎｇを使用することによって、ＸＭＬベースの文書構造によって提供された柔軟性を利用する。
−所定のＳＤＰｎｇ９１２記述をＥ２ＥＮＰ９０８処理の所定のフェーズに一意にマッピングする明確な識別子を使用することによって、Ｅ２ＥＮＰ９０８とアプリケーションの間に明白なインタフェースを定義する。
−数本のマルチメディアストリーム２０６について、ＱｏＳコンテキストの階層を同時記述することが可能である。
−数本のマルチメディアストリーム２０６について、ＱｏＳコンテキストの階層を同時交渉することがが可能である。
−セッション及びフェーズの概念を使用することによって、幾つかのマルチメディアストリーム２０６に対して、ＱｏＳコンテキストの階層を順次交渉することが可能である。
−変換のコアによって制御されたＥ２ＥＮＰの複数の外部仲介者の概念は、本発明による新規の提案として考慮される。
Figure 2005527133
将来の電話式通信の配置概念を表す、電気通信セッションの切換状態における呼再配置を示す１対１「第三者支援」通信シナリオ１００を示す。 仮想講義を示す１対多通信シナリオ２００を示す。 テレビ会議の単純な形式を示す多対多通信シナリオを概略する。 テレビ会議の複雑な形式を示す多対多通信シナリオを概略する。 通信パーティとサービスの検出をサポートする何らかのサービスと、交渉の開始との使用を考慮したマルチパーティ通信の幾つかの追加的アスペクトを示す具体例を提示する。 整合性が必要である理由を示すシナリオを概略する。 デッドロックの回避が必要である理由を示す、すなわち、なぜＥ２ＥＮＰが、ホールドアンドウェイト条件が存在しないようにしなければならないか、あるいは、このような条件が、限られた時間にのみ現れるようにできることを示すシナリオを概略する。 単純な１対１通信を確立する単純な１対１交渉シナリオによって、Ｅ２ＥＮＰフェーズと動作者を示す対話ダイアグラムを表す。 ＳＤＰｎｇとＳＩＰを使用するＥ２ＥＮＰの機能を示す。 所謂<e2enp:alternative-service>セクションを示す具体例を表す。 ユーザプロファイルとシステム構成情報より導出した交渉の有効性が検査されたシナリオを示す。 ２つの異なるテレビ会議セッションに同時に参加するユーザの具体例を示す。 「アドホックへの遷移」と呼ばれる多対多シナリオの具体例を示す。 「アドホックへの遷移」と呼ばれる多対多シナリオの具体例を示す。 「アドホックへの遷移」と呼ばれる多対多シナリオの具体例を示す。

Claims (62)

  1. ２つ又は多数のエンドピア及び／又は中間コンポーネントの複数の構成に対し、連続したＥ２ＥＮＰフェーズの概念を使用して、整合的な、信頼性が高い且つ追加的な方法で、エンドツーエンド品質及び電気通信セッション（１０２）の能力の前交渉（８０２、８０４、８０５）、高速交渉（８０６）、高速で動的再交渉（８０８）を可能にするエンドツーエンド交渉プロトコル（Ｅ２ＥＮＰ、９０８）の拡張方法。
  2. Ｅ２ＥＮＰセッションを、個々のフェーズ（マイクロフェーズ）又は連続したフェーズ（マクロフェーズ）の集合に関連付けることを特徴とする請求項１記載のエンドツーエンド交渉プロトコル（Ｅ２ＥＮＰ、９０８）の拡張方法。
  3. アプリケーションレベルのシグナリングプロトコルとしての請求項１又は２記載のエンドツーエンド交渉プロトコルの拡張方法に基づいて、上記Ｅ２ＥＮＰ概念及びその拡張を実現するセッション記述プロトコル次世代（ＳＤＰｎｇ、９１２）の拡張方法。
  4. 請求項１又は２記載のエンドツーエンド交渉プロトコルの拡張方法に基づいて、上記Ｅ２ＥＮＰ（９０８）概念及びその拡張を実現するために、上記拡張したＳＤＰｎｇ（９１２）のコンテンツをピギーバックするセッション開始プロトコル（ＳＩＰ、９１０）の新規な使用方法。
  5. 上記セッション開始プロトコル（ＳＩＰ、９１０）又は任意の同等のセッションレベルのプロトコルによってピギーバックされる上記アプリケーションレベルのプロトコルのＰＤＵヘッダとして使用するヘッダＳＤＰｎｇセクションを導入することを特徴とする請求項３記載のセッション記述プロトコル次世代（ＳＤＰｎｇ、９１２）の拡張方法。
  6. 単一のＳＩＰメッセージは、各々がそのヘッダ部により識別される複数のＥ２ＥＮＰ ＰＤＵを搬送することができることを特徴とする請求項４記載のセッション開始プロトコル（ＳＩＰ、９１０）の拡張方法。
  7. 交渉のために、上記Ｅ２ＥＮＰ（９０８）によって入力として使用される端末能力情報を定義する新たなＳＤＰｎｇ（９１２）セクションを導入することを特徴とする請求項３又は５記載のセッション記述プロトコル次世代（ＳＤＰｎｇ、９１２）の拡張方法。
  8. 単一のメディアストリーム（２０６）又はそのグループのＱｏＳアスペクトを、異なる抽象化レベルで詳述する新たな２つのＳＤＰｎｇセクションを導入することを特徴とする請求項３、５、７のいずれか１項記載のセッション記述プロトコル次世代（ＳＤＰｎｇ、９１２）の拡張方法。
  9. 他のサービス構成Ｅ２ＥＮＰの通知のための新たなＳＤＰｎｇセクションを導入することを特徴とする請求項３、５、７、８のいずれか１項記載のセッション記述プロトコル次世代（ＳＤＰｎｇ、９１２）の拡張方法。
  10. 再交渉中に、前に交渉した適応経路からどのＱｏｓ契約（１１０８）を実行するかをシグナリングする新たなＳＤＰｎｇセクションを導入することを特徴とする請求項３、５、７乃至９のいずれか１項記載のセッション記述プロトコル次世代（ＳＤＰｎｇ、９１２）の拡張方法。
  11. ハンドオーバ状態が常に発生する技術の変更及び／又はそれぞれのネットワークプロバイダの変更によって生じた再交渉（８０８）中に、阻止又は除去を行うＱｏＳ契約（１１０８）をシグナリングする新たな２つのＳＤＰｎｇセクションを導入することを特徴とする請求項３、５、７乃至１０のいずれか１項記載のセッション記述プロトコル次世代（ＳＤＰｎｇ、９１２）の拡張方法。
  12. 異なるＳＤＰｎｇセクションをＥ２ＥＮＰ（９０８）の様々なフェーズにおいて交換できるセクションのモジュールを使用することを特徴とする請求項３、５、７乃至１１のいずれか１項記載のセッション記述プロトコル次世代（ＳＤＰｎｇ、９１２）の拡張方法。
  13. それぞれがＥ２ＥＮＰ（９０８）の特定のフェーズにおいて特定のＥ２ＥＮＰ ＰＤＵを目標とする古い及び新しいＳＤＰｎｇセクションの特定の構成の定義することを特徴とする請求項１２記載のセッション記述プロトコル次世代（ＳＤＰｎｇ、９１２）の拡張方法。
  14. 上記ＳＤＰｎｇ情報の有効性をタイムリーに制限するために、Ｅ２ＥＮＰ（９０８）のＳＤＰｎｇ情報をリースと関連付けることを特徴とする請求項３、５、７乃至１３のいずれか１項記載のセッション記述プロトコル次世代（ＳＤＰｎｇ、９１２）の拡張方法。
  15. エンドツーエンド品質の交渉及び電気通信セッション（１０２）の能力を可能にするエンドツーエンド交渉プロトコル（Ｅ２ＥＮＰ、９０８）の範囲において必要とされる概念を実現する概念実現方法において、
    任意の種類のネットワーク（６０４）に接続された端末上で実行されるマルチストリームマルチメディアアプリケーションは、請求項１乃至１４のいずれか１項記載の方法に基づくセッション記述プロトコル次世代（ＳＤＰｎｇ、９１２）の拡張を動的に適用することによって、伝送品質の変更に動的に適応し、
    上記ＳＤＰｎｇ（９１２）のコンテンツは、ユーザプロファイル情報から導出することができ、上記Ｅ２ＥＮＰ（９０８）の入力として使用されることを特徴とする概念実現方法。
  16. 上記ＳＤＰｎｇ（９１２）は、上記Ｅ２ＥＮＰ（９０８）の入力として使用される端末能力情報を定義することを特徴とする請求項１５記載の概念実現方法。
  17. 異なるピア間でのリソース管理ポリシを交渉（８０６）することを特徴とする請求項１５又は１６記載の概念実現方法。
  18. 現在のネットワークプロバイダの許可の下に、基本的な契約記述（１１０８）内における予備マークの有無に基づいて、予備契約（１１０８）の概念、状態の阻止又は除去の概念を導入することを特徴とする請求項１５乃至１７のいずれか１項記載の概念実現方法。
  19. 上記予備契約（１１０８）は、発生するハンドオーバ状態において使用できるとともに、該予備契約（１１０８）の少なくとも１つが使用可能になるように、事前に交渉されることを特徴とする請求項１５乃至１８のいずれか１項記載の概念実現方法。
  20. ハンドオーバ状態によって起こる技術の変更及び／又はそれぞれのネットワークプロバイダの変更があった場合には常に、再交渉（８０８）中において状態阻止又は状態除去をシグナリングすることを特徴とする請求項１５乃至１９のいずれか１項記載の概念実現方法。
  21. ピギーバックによって、Ｅ２ＥＮＰ（９０８）をＳＩＰ（９１０）上に詳細にマッピングすることを特徴とする請求項１５乃至２０のいずれか１項記載の概念実現方法。
  22. 第三者支援交渉のシグナリングをサポートすることを特徴とする請求項１５乃至２１のいずれか１項記載の概念実現方法。
  23. １対多通信シナリオ（２００）及び多対多通信シナリオ（３００、４００、５００）のシグナリングをサポートすることを特徴とする請求項１５乃至２２のいずれか１項記載の概念実現方法。
  24. それぞれが様々なＥ２ＥＮＰフェーズ（８０２、８０４、８０５、８０６、８０８）の１つに対応するＥ２ＥＮＰシグナリングセッションを、前のＥ２ＥＮＰシグナリングセッションのあらゆる交渉結果を順次利用して、開始することを特徴とする請求項１５乃至２３のいずれか１項記載の概念実現方法。
  25. 幾つかの参照チェーン手段によって構築されたツリー状構造に論理的に配置されたＥ２ＥＮＰフェーズ（マイクロ及び／又はマクロ）を開始することを特徴とする請求項２４記載の概念実現方法。
  26. 上記ツリー状構造に配置された様々なＥ２ＥＮＰフェーズ（マイクロ及び／又はマクロ）のサブツリーをリースすることを特徴とする請求項２４又は２５項記載の概念実現方法。
  27. 上記Ｅ２ＥＮＰフェーズ（マイクロ及び／又はマクロ）の期限切れサブツリーの解放を遅延させるためにゾンビ状態を開始し、その後、該サブツリーを、全ての保留された接続が終了すると直ちに、解放することを特徴とする請求項２４乃至２６のいずれか１項記載の概念実現方法。
  28. 上記マイクロフェーズの交渉を順次行うことを特徴とする請求項２４乃至２７のいずれか１項記載の概念実現方法。
  29. ＲＴＰを適用し、該ＲＴＰにおいて、再交渉（８０８）が、前交渉したサービス品質契約（１１０８）及び前交渉した能力のセットを参照する前交渉状態に基づいたピア（６０２ａ／ｂ／ｃ）のメディアストリーミング中に実行され、
    −送信側ピア（６０２ａ／ｂ／ｃ）は、他の交渉したコーデック及び信号を採用することによって、メディアストリーム（２０６）のフォーマットを変更し、更に、ＲＴＰヘッダ内のＲＴＰペイロードタイプを、合意したＱｏＳ契約（１１０８）内に残っているときには常に、新たなコーデックに対応したペイロードタイプで置換し、該変更を、周知の帯域内を用いて、１つ以上の受信側に知らせることを決定することができ、
    −又は、上記送信側ピア（６０２ａ／ｂ／ｃ）は、ＱｏＳ違反及び／又はＱｏＳ変更が生じたときには、Ｅ２ＥＮＰシグナリングを明示的に使用することができ、及び／又はＱｏＳ関連（８０４）及び時間同期（８０５）の制約を、複数のメディアストリーム（２０６）に亘って実施しなければならないことを特徴とする請求項２４乃至２８のいずれか１項記載の概念実現方法。
  30. 電気通信セッション（１０２）の柔軟性を維持するために、帯域幅の低下が生じた場合は、上記メディアストリーム（２０６）を明示的に停止するＮＵＬＬストリームの概念を導入することを特徴する請求項２４乃至２９のいずれか１項記載の概念実現方法。
  31. 前交渉ステップ（８０２）中に、上記ピア（６０２ａ／ｂ／ｃ）が、最も細かい解像度レベルにおいて、ストリーム毎に及び／又はストリームアソシエーション毎に、上記サービス品質契約（１１０８）のセットを交渉し、この場合、該メディアストリームアソシエーションは、１つの送信側ピア（６０２ａ／ｂ／ｃ）から受信側ピア（６０２ａ／ｂ／ｃ）への上記メディアストリーム（２０６）のバンドルであることを特徴とする請求項２４乃至３０のいずれか１項に記載の概念実現方法。
  32. 上記ピア（６０２ａ／ｂ／ｃ）は、上記Ｅ２ＥＮＰシグナリングを介して、上記サービス品質及び／又は機能構成の変更を通知されることを特徴とする請求項１５乃至３１のいずれか１項記載の概念実現方法。
  33. 所定の種類のメディアストリーム（２０６）の、前交渉した他の品質及び構成は、サーバにおいてクライアントが選択するために既に利用可能になっていることを特徴とする請求項３２記載の概念実現方法。
  34. プロトコルディスカバリ、上記前交渉（８０２）、オプションのマルチメディアストリームのＱｏＳ同期及びＱｏＳ関連（８０４）、経済原理を展開する高速交渉、該経済原理を展開する再交渉（８０８）及びリソース予約の解放のステップを有することを特徴する請求項１５乃至３３のいずれか１項記載の概念実現方法。
  35. 上記６つのフェーズは、オプションで数回適用され、連結されて、連続又は異なる時間において実行され、請求項３２に示す命令に従うことを特徴する請求項３４記載の概念実現方法。
  36. 上記マルチメディアストリームの時間同期及びＱｏＳ関連のフェーズ（８０４）は、オプションであり、また、起動側のみにおいて実行されるユーザポリシに基づいて関連及び同期する必要のある複数のメディアストリーム（２０６）を用いて、起動側が複数のピア（６０２ａ／ｂ／ｃ）と通信する場合にのみ必要とされることを特徴とする請求項３５記載の概念実現方法。
  37. 上記プロトコルディスカバリフェーズ及び前交渉（８０２）フェーズは、先験的に実行され、その結果は、特定且つ任意のマルチメディアストリームの時間同期及びＱｏＳ関連のフェーズ（８０４）で開始される複数の連続的な電気通信セッション（１０２）を確立するために、適用することができることを特徴する請求項３６記載の概念実現方法。
  38. 上記マルチメディアストリームの時間同期フェーズ（８０５）及びＱｏＳ関連フェーズ（８０４）の結果を、複数の連続的な電気通信セッション（１０２）に適用できるときは、これらのフェーズを特定の高速交渉フェーズ（８０６）によって開始することができることを特徴とする請求項３７記載の概念実現方法。
  39. 上記前交渉（８０２）、マルチストリームの時間同期（８０５）及びＱｏＳ関連（８０４）、高速交渉（８０６）、再交渉（８０８）及びリソース解放のフェーズ中に、上記プロトコルは、ローカルリソース管理ユニットと相互作用することを特徴とする請求項３４乃至３８のいずれか１項記載の概念実現方法。
  40. 上記確立したマルチメディアセッション（１０２）の実行中に、任意の時間に、任意のピア（６０２ａ／ｂ／ｃ）の任意のコンポーネントは、適用を要求することができ、最終的に、再交渉フェーズ（８０８）を起動することを特徴とする請求項３４乃至３９のいずれか１項記載の概念実現方法。
  41. 上記ピアに、ＳＩＰレジスタとして実行できるディレクトリサーバに問い合わせさ、又はピアにこのような情報を報知させることによって、上記プロトコルディスカバリフェーズ中に、上記Ｅ２ＥＮＰ（９０８）の種類を前交渉（８０２）することを特徴とする請求項３４乃至４０のいずれか１項記載の概念実現方法。
  42. 上記前交渉フェーズ（８０２）中に、様々な能力を前交渉（８０２）することを特徴とする請求項４１記載の概念実現方法。
  43. 上記前交渉フェーズ（８０２）中に、完全なコーデックリストを前交渉（８０２）することを特徴とする請求項３４乃至４２のいずれか１項記載の概念実現方法。
  44. 上記前交渉フェーズ（８０２）中に、適応経路をメディアストリームレベルで前交渉（８０２）することを特徴とする請求項３４乃至４３のいずれか１項記載の概念実現方法。
  45. 上記マルチストリームの時間同期（８０５）フェーズ及びＱｏＳ関連フェーズ（８０４）中に、適応経路をメディアストリーム集合のレベルで前交渉（８０２）することを特徴とする請求項３４乃至４４のいずれか１項記載の概念実現方法。
  46. −上記前交渉したＱｏＳ契約（１１０８）及び能力に、上記高速交渉フェーズ（８０６）を高速化する指標を付けるステップと、
    −上記前交渉したＱｏＳ契約（１１０８）及び能力に、上記高速交渉フェーズ（８０６）を高速化する指標を付けるステップとを有することを特徴とする請求項３４乃至４５のいずれか１項記載の概念実現方法。
  47. 上記ピア（６０２ａ／ｂ／ｃ）間で非同期メッセージを交換することによって、上記能力のインストール及びアンインストールを実行時においてでも行い、このようなイベントを通知することを特徴とする請求項３４乃至４６のいずれか１項記載の概念実現方法。
  48. 電気通信セッション（１０２）のエンドツーエンド品質を交渉するメカニズムを提供するエンドツーエンド交渉プロトコル（Ｅ２ＥＮＰ）において、
    任意の種類のネットワーク（６０４）に接続されたモバイル端末上で実行されるマルチメディアアプリケーションは、接続の時間依存性又はローカルリソースの利用可能性に動的に適応するように関与しており、
    代のＱｏＳ及び能力の共通レベルを予め確立するために、代のＱｏＳアスペクト及び能力を、エンドツーエンドベースで前交渉することにより、ＱｏＳ対応電気通信セッション（１０２）が確立され、その使用には、電気通信セッション（１０２）の全てのピアが合意することができることを特徴とするエンドツーエンド交渉プロトコル（Ｅ２ＥＮＰ）。
  49. 請求項４８記載のエンドツーエンド交渉プロトコル（Ｅ２ＥＮＰ）のサービスを用いて、電気通信セッション（１０２）のエンドツーエンド品質を組織化するブローカにおいて、
    無線ネットワーク上で実行されているマルチストリームマルチメディアアプリケーション（６０４）は、基本的なチャンネルの時間依存性に動的に適応するように関与しており、
    当該ブローカは、ネットワーク（６０４）のピア（６０２ａ／ｂ／ｃ）を、前交渉フェーズ（８０２）の実行から解放し、またオプションとして、請求項３５に基づくマルチストリームの時間同期（８０５）フェーズ及びＱｏＳ関連フェーズ（８０４）の実行から解放することができることを特徴とするブローカ。
  50. コンピュータによって実行される場合に、請求項１５乃至４７のいずれか１項記載の方法を実行するソフトウェアルーチン。
  51. 請求項１５乃至４７のいずれか１項記載の方法を実行するように構成されたピアにおいて、
    エンドツーエンド交渉プロトコル（Ｅ２ＥＮＰ）及び分散リソース管理処理の様々なフェーズを調整する調整ユニットを備え、
    上記調整ユニットは、プロトコルディスカバリを命令し、前交渉（８０２）を起動及び調整し、オプションとして、マルチストリームの時間同期（８０５）及びＱｏＳ関連（８０４）、経済原理による高速交渉、経済交渉による再交渉（８０８）及びリソース予約解放のフェーズを起動及び調整することを特徴とするピア。
  52. 上記調整ユニットがエンドツーエンド交渉プロトコル（Ｅ２ＥＮＰ）の様々なフェーズを実行することを可能にするセッションプロトコルユニットを備えることを特徴する請求項５１記載のピア。
  53. 電気通信セッション（１０２）のエンドツーエンド品質の交渉を可能にするプロトコルにおいて、
    ネットワーク（６０４）に接続されているモバイル端末上で実行されるマルチストリームマルチディアアプリケーションは、基本的なチャンネルの時間依存性に動的に適応するように関与しており、
    −代のＱｏＳ及び能力の共通レベルを予め確立するために、他のＱｏＳアスペクト及び能力をエンドツーエンドベースで前交渉することにより、ＱｏＳ対応電気通信セッション（１０２）が確立され、その使用に、電気通信（１０２）の全てのピアが合意することができ、
    −ＱｏＳレベル及び／又は能力の交渉（８０６）及び再交渉（８０８）は、選択されたＱｏＳ契約のシグナリング、コーデック及びその構成を含むことを特徴とするプロトコル。
  54. Ｅ２ＥＮＰ ＰＤＵのサイズを制限するために、セッション識別子の交渉及び使用は、ハッシュによってセッション識別子のタプルから導出され、各々が少なくとも１つの計算されたハッシュを有する完全なセッション識別子のタプルは、あらゆる所定のＥ２ＥＮＰフェーズの第１のＰＤＵ又はその連結において使用されることを特徴とする請求項１５乃至４７のいずれか１項記載の概念実現方法。
  55. 上記Ｅ２ＥＮＰ（９０８）は、仲介者（１０６ａ１）手段によって、第三者支援交渉を含むことを特徴とする請求項１５乃至請求項４７及び請求項５４のいずれか１項記載の概念実現方法。
  56. 整合性を実現し、デッドロックを回避するＥ２ＥＮＰメカニズムを特徴とする請求項１５乃至４７、５４、５５のいずれか１項記載の概念実現方法。
  57. 上記Ｅ２ＥＮＰ（９０８）は、１対１通信シナリオ（１００）、１対多通信シナリオ（２００）、多対多通信シナリオ（３００、４００）を取り扱うことができることを特徴とする請求項１５乃至４７、５４乃至５６のいずれか１項記載の概念実現方法。
  58. 変換ユニットをＳＩＰプロキシと結合するために使用される変換サービスと、必要時に申込者（９１４）が特定の変換ユニット又はそのチェーンを使用できるようにするためのディレクトリサービスとを有することを特徴する請求項１５乃至４７、５４乃至５７のいずれか１項記載の概念実現方法。
  59. 上記申込者（９１４）、中間にある様々な変換器、回答者（９１１）の間で第三者交渉を管理することにより、合意に達しなかった場合で、これらのエンドピア（９１４、９１１）間のＥ２ＥＮＰセッションが失敗する際には常に、変換サービスを提供するために、該申込者（９１４）は、ネットワークオペレータ又は他の任意のサービスプロバイダからのサポートを求める能力を有することを特徴とする請求項５８記載の概念実現方法。
  60. 上記変換サービスは、上記ピア（９１１、９１４）のチェーンにおけるノードの組合せを組織化し、リソースがＥ２ＥＮＰ経済原理によって適切に予約されるようにすることを特徴とする請求項５８又は５９記載の概念実現方法。
  61. 様々なプロバイダによって提供された変換サービスを、第三者交渉を実行するＥ２ＥＮＰ（９０８）を用いることによって、協同させることを特徴する請求項５８乃至６０のいずれか１項に記載の概念実現方法。
  62. Ｅ２ＥＮＰ（９０８）によって影響されるＥ２ＥＮＰシグナリングに関与している任意のピア（９１１、９１４）において発生する内外両方の障害状態、例外及びエラーを通知するエラーコードを使用することによって、上記Ｅ２ＥＮＰ（９０８）のエラー処理は、対称的であることを特徴とする請求項５４乃至６１のいずれか１項記載の概念実現方法。
JP2003563172A 2002-01-23 2003-01-14 マルチストリーム及びマルチメディアアプリケーションのためのＱｏＳサポートを目的としたエンドツーエンド交渉プロトコルの様々なフェーズを実行するモデル Expired - Fee Related JP4342948B2 (ja)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
EP02001600 2002-01-23
EP02001900A EP1331785B1 (en) 2002-01-23 2002-01-28 A method for enabling the negotiation of end-to-end QoS by using the end-to-end negotiation protocol (E2ENP)
PCT/EP2003/000309 WO2003063439A2 (en) 2002-01-23 2003-01-14 A method for enforcing different phases of the end-to-end negotiation protocol (e2enp) aiming qos support for multi-stream and multimedia applications

Publications (2)

Publication Number Publication Date
JP2005527133A true JP2005527133A (ja) 2005-09-08
JP4342948B2 JP4342948B2 (ja) 2009-10-14

Family

ID=27614615

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2003563172A Expired - Fee Related JP4342948B2 (ja) 2002-01-23 2003-01-14 マルチストリーム及びマルチメディアアプリケーションのためのＱｏＳサポートを目的としたエンドツーエンド交渉プロトコルの様々なフェーズを実行するモデル

Country Status (8)

Country Link
US (1) US7602723B2 (ja)
EP (1) EP1331785B1 (ja)
JP (1) JP4342948B2 (ja)
CN (1) CN1623308B (ja)
AT (1) ATE293863T1 (ja)
DE (1) DE60203779T2 (ja)
ES (1) ES2236370T3 (ja)
WO (1) WO2003063439A2 (ja)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20210149888A (ko) * 2017-05-08 2021-12-09 후아웨이 테크놀러지 컴퍼니 리미티드 통신 시스템 간 이동 방법 및 장치
KR20220068021A (ko) * 2020-11-18 2022-05-25 주식회사 케이티 동적인 QoS 제공 방법

Families Citing this family (200)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE60036295T2 (de) * 2000-12-08 2008-05-29 Sony Deutschland Gmbh Schnittstelle auf hoher Ebene für dienstqualitätbasierte mobile Multimedia-Anwendungen
US8037188B2 (en) * 2003-02-12 2011-10-11 Qualcomm Incorporated Soft handoff across different networks assisted by an end-to-end application protocol
US7912902B2 (en) * 2003-02-13 2011-03-22 Telcordia Licensing Company, Llc Application service peering and aggregation
US7284054B2 (en) * 2003-04-11 2007-10-16 Sun Microsystems, Inc. Systems, methods, and articles of manufacture for aligning service containers
US20050021840A1 (en) * 2003-07-11 2005-01-27 Nokia Corporation Method and an apparatus for enhancing messaging
GB2406464B (en) 2003-09-29 2006-07-05 Siemens Ag Network entity
US7644182B2 (en) * 2004-03-11 2010-01-05 Hewlett-Packard Development Company, L.P. Reconfiguring a multicast tree
EP1610492B1 (en) * 2004-06-21 2007-04-11 Matsushita Electric Industrial Co., Ltd. Adaptive and scalable qos architecture for multiple-bearer multicast/broadcast services
US7574510B2 (en) 2004-07-30 2009-08-11 Nokia Corporation Systems, nodes, and methods for dynamic end-to-end session-enhancing services for transport-level-based connections
US20060072541A1 (en) * 2004-09-28 2006-04-06 Vivian Pecus Network management system & method
US20060083242A1 (en) * 2004-10-20 2006-04-20 Nokia Corporation Address modification in application servers
KR100561686B1 (ko) * 2004-10-22 2006-03-15 에스케이 텔레콤주식회사 이동통신망에서의 화상통화 서비스 제공 방법
US7369502B2 (en) * 2004-12-02 2008-05-06 Cisco Technology, Inc. Intelligent provisioning of DSP channels for codec changes
KR100599174B1 (ko) * 2004-12-16 2006-07-12 삼성전자주식회사 프로파일 정보를 이용한 서비스 제공방법 및 서비스제공시스템
KR100688079B1 (ko) 2004-12-17 2007-03-02 한국전자통신연구원 개인화 서비스를 위한 프로파일 정보 분류 및 처리 방법그리고 이를 이용한 개인화 서비스 제공 시스템
DE102004063298B4 (de) * 2004-12-29 2006-11-16 Infineon Technologies Ag Verfahren zum rechnergestützten Verwalten von Kommunikationsrechten zum Kommunizieren mittels mehrerer unterschiedlicher Kommunikationsmedien in einer Telekommunikations-Konferenz mit mehreren Telekommunikations-Einrichtungen
US8159999B2 (en) 2005-01-25 2012-04-17 Interdigital Technology Corporation Peer-to-peer wireless communication system
US8077635B2 (en) 2005-01-28 2011-12-13 Cisco Technology, Inc. Method and system for reserving facility resources for a conference
US20060218353A1 (en) * 2005-03-11 2006-09-28 Interdigital Technology Corporation Method and apparatus for implementing path-based traffic stream admission control in a wireless mesh network
US7583662B1 (en) * 2005-04-12 2009-09-01 Tp Lab, Inc. Voice virtual private network
WO2006117644A1 (en) * 2005-05-03 2006-11-09 Nokia Corporation Signaling quality of service (qos) parameters for a multimedia session
EP1724984A1 (en) * 2005-05-20 2006-11-22 Alcatel A terminal comprising a transceiver
CN100544388C (zh) * 2005-07-01 2009-09-23 华为技术有限公司 一种控制业务多次前转套打的方法
US7796589B2 (en) * 2005-08-01 2010-09-14 American Power Conversion Corporation Communication protocol
US9660808B2 (en) * 2005-08-01 2017-05-23 Schneider Electric It Corporation Communication protocol and method for authenticating a system
EP1758334A1 (en) * 2005-08-26 2007-02-28 Matsushita Electric Industrial Co., Ltd. Establishment of media sessions with media adaptation
US7788698B2 (en) 2005-08-31 2010-08-31 Microsoft Corporation Pre-negotiation and pre-caching media policy
US20070110034A1 (en) * 2005-11-14 2007-05-17 Broadcom Corporation, A California Corporation Pathways analysis and control in packet and circuit switched communication networks
US8077707B2 (en) * 2005-11-18 2011-12-13 Sri International Systems and methods for digital stream denting
US20070121532A1 (en) * 2005-11-28 2007-05-31 Nokia Corporation Application specific encoding of content
EP1989854B1 (fr) * 2005-12-27 2015-07-22 Orange Procede de determination d'un mode d'encodage spatial de donnees audio
US8811369B2 (en) 2006-01-11 2014-08-19 Qualcomm Incorporated Methods and apparatus for supporting multiple communications modes of operation
HUE036741T2 (hu) 2006-01-11 2018-07-30 Qualcomm Inc Vezeték nélküli kommunikációs eljárások és berendezés szinkronizálás támogatására
CN101026812B (zh) * 2006-02-24 2010-04-14 华为技术有限公司 在多方通信系统中获得会话参与用户会话能力的方法
ES2382387T3 (es) 2006-04-28 2012-06-07 Motorola Mobility, Inc. Actualización de capacidades durante una llamada
US7756134B2 (en) 2006-05-02 2010-07-13 Harris Corporation Systems and methods for close queuing to support quality of service
WO2007133697A2 (en) 2006-05-11 2007-11-22 Cfph, Llc Methods and apparatus for electronic file use and management
US7894509B2 (en) 2006-05-18 2011-02-22 Harris Corporation Method and system for functional redundancy based quality of service
EP1858210A1 (en) * 2006-05-19 2007-11-21 Whitestein Information Technology Group AG Method and system for adaptive communication service access
US8705558B2 (en) 2006-06-01 2014-04-22 Cisco Technology, Inc. Swapping bandwidth reservations
US9112872B2 (en) * 2006-06-07 2015-08-18 Broadcom Corporation Method and system for communication of information by a handheld communication device in an ad-hoc network
US8516153B2 (en) 2006-06-16 2013-08-20 Harris Corporation Method and system for network-independent QoS
US8064464B2 (en) 2006-06-16 2011-11-22 Harris Corporation Method and system for inbound content-based QoS
US7856012B2 (en) * 2006-06-16 2010-12-21 Harris Corporation System and methods for generic data transparent rules to support quality of service
US7990860B2 (en) * 2006-06-16 2011-08-02 Harris Corporation Method and system for rule-based sequencing for QoS
US8730981B2 (en) 2006-06-20 2014-05-20 Harris Corporation Method and system for compression based quality of service
EP1871050B1 (en) * 2006-06-20 2012-01-25 Alcatel Lucent Wimax network, Wimax network element and method of handling QoS
US7769028B2 (en) 2006-06-21 2010-08-03 Harris Corporation Systems and methods for adaptive throughput management for event-driven message-based data
US8077626B2 (en) * 2006-07-14 2011-12-13 Qualcomm Incorporated Quality of service (QoS) aware establishment of communication sessions
CN101110972B (zh) * 2006-07-18 2010-05-12 华为技术有限公司 分布式架构中sip消息分发和处理方法及其系统
GB2440381B (en) * 2006-07-27 2008-11-05 Motorola Inc An internet protocol multimedia subsystem network element and method of operation therefor
US8300653B2 (en) 2006-07-31 2012-10-30 Harris Corporation Systems and methods for assured communications with quality of service
US7817557B2 (en) * 2006-08-29 2010-10-19 Telesector Resources Group, Inc. Method and system for buffering audio/video data
US7940653B2 (en) * 2006-08-29 2011-05-10 Verizon Data Services Llc Audiovisual data transport protocol
EP2060119B1 (en) * 2006-09-05 2010-06-09 TELEFONAKTIEBOLAGET LM ERICSSON (publ) IP unicast streaming service delivery
CN101087301B (zh) * 2006-09-07 2010-05-12 华为技术有限公司 用户接入网络的方法和系统
PL2064855T3 (pl) * 2006-09-20 2016-08-31 Orange Sposób komunikacji między kilkoma terminalami
KR20080030899A (ko) * 2006-10-02 2008-04-07 엘지전자 주식회사 맞춤형 방송 신호 수신기 및 방송 수신 방법
US7840686B2 (en) * 2006-10-25 2010-11-23 Research In Motion Limited Method and system for conducting communications over a network
CN101175293B (zh) * 2006-10-30 2010-09-08 华为技术有限公司 采用push模式的呼叫方法
GB2444096B (en) * 2006-11-22 2009-10-14 Adam Hill Audio communications system using networking protocols
US8218458B2 (en) * 2006-11-30 2012-07-10 Cisco Systems, Inc. Method and apparatus for voice conference monitoring
US8019326B2 (en) * 2006-11-30 2011-09-13 Motorola Mobility, Inc. System and method for adaptive contextual communications
US8737349B2 (en) * 2006-12-01 2014-05-27 Sigram Schindler Beteiligungsgesellschaft Mbh Handover process and information support for communication transfer between telecommunication networks
FR2909822B1 (fr) * 2006-12-06 2010-04-30 Radiotelephone Sfr Procede et systeme de controle de l'etablissement de canaux de communication pour permettre une transmission d'informations multimedia.
JP2008153896A (ja) * 2006-12-15 2008-07-03 Nec Corp コンテンツ配信システム、コンテンツ配信側ユーザー端末、コンテンツ被配信側ユーザー端末、コンテンツ配信システムの認証方法
US8959239B2 (en) * 2006-12-29 2015-02-17 Telefonaktiebolaget L M Ericsson (Publ) Method and apparatus for reporting streaming media quality
US7971132B2 (en) * 2007-01-05 2011-06-28 Dialogic Corporation Universal multimedia engine and method for producing the same
CN101005511B (zh) * 2007-01-17 2010-06-16 华为技术有限公司 QoS资源预留方法、系统及会话建立和修改媒体的方法
US20100053300A1 (en) * 2007-02-02 2010-03-04 Einarsson Torbjoern Method And Arrangement For Video Telephony Quality Assessment
ATE513441T1 (de) * 2007-02-12 2011-07-15 Sigram Schindler Beteiligungs Gmbh ßNETSURFINGß IN VOIP-ANRUFEN MITTELS MANAGED HANDOVERS (MHOS)
US9998956B2 (en) 2007-02-12 2018-06-12 Sigram Schindler Beteiligungsgesellschaft Mbh Managed handover process
US8761009B2 (en) 2007-02-12 2014-06-24 Sigram Schindler Beteiligungsgesellschaft Mbh Managed handover process
US9019830B2 (en) 2007-05-15 2015-04-28 Imagine Communications Corp. Content-based routing of information content
EP2009892B1 (fr) * 2007-06-29 2019-03-06 Orange Positionnement de locuteurs en conférence audio 3D
US8151005B2 (en) * 2007-08-04 2012-04-03 Broadcom Corporation System and method for adjusting a level of compression for computing clients
US7929553B2 (en) * 2007-08-10 2011-04-19 Broadcom Corporation System and method for adjusting compression for computing clients based on a latency level
US8856206B2 (en) * 2007-08-28 2014-10-07 International Business Machines Corporation Maintaining message versions at nodes in a network
US8554865B2 (en) * 2007-09-21 2013-10-08 Honeywell International Inc. System and method for remotely administering and synchronizing a clustered group of access control panels
CA2701122A1 (en) * 2007-09-29 2009-04-09 Research In Motion Limited Schema indication system and method in a network environment including ims
CN101919222B (zh) 2007-10-27 2014-02-05 黑莓有限公司 在分布式环境中处理消息内容的内容部署系统和方法
EP3534606A1 (en) 2007-11-30 2019-09-04 Samsung Electronics Co., Ltd. Method and apparatus for searching for iptv service relay devices and method and apparatus for interacting with devices
US8614996B1 (en) * 2007-12-12 2013-12-24 Sprint Spectrum L.P. Predictive personality negotiation during session negotiation
EP2073467A1 (en) * 2007-12-21 2009-06-24 Nokia Siemens Networks Oy Messaging mechanism
US7877453B2 (en) * 2008-01-02 2011-01-25 International Business Machines Corporation System and method for optimizing data traffic in signaling stream of IP multimedia subsystem service
US9705935B2 (en) * 2008-01-14 2017-07-11 Qualcomm Incorporated Efficient interworking between circuit-switched and packet-switched multimedia services
CN101222502B (zh) * 2008-01-25 2012-08-22 华为技术有限公司 媒体能力重协商的方法及装置
MX2010008642A (es) * 2008-02-05 2010-12-14 Samsung Electronics Co Ltd Metodo y aparato de transmision y recepcion de metadatos para aplicacion que proporciona servicio de television de protocolo de internet.
US20090207988A1 (en) * 2008-02-15 2009-08-20 Ericsson, Inc. Method and system for telecommunication sessions using only initial signal messages
US8144187B2 (en) 2008-03-14 2012-03-27 Microsoft Corporation Multiple video stream capability negotiation
KR101582092B1 (ko) 2008-03-28 2016-01-04 삼성전자주식회사 Ｉｐｔｖ 통신 서비스를 제공하는 응용에 대한 정보 수신 방법 및 장치
US8595501B2 (en) 2008-05-09 2013-11-26 Qualcomm Incorporated Network helper for authentication between a token and verifiers
CN101282339B (zh) * 2008-05-16 2012-12-12 华为技术有限公司 流媒体系统的能力协商方法、数据传输方法及相关设备
US8902821B2 (en) * 2008-06-12 2014-12-02 Motorola Mobility Llc Method and system for intermediate node quality of service negotiations
BRPI0916441A2 (pt) * 2008-07-17 2018-09-11 Hercules Incorporated processo para adaptar composições de revestimento à base de água
GB0813203D0 (en) * 2008-07-18 2008-08-27 Eldon Technology Ltd Dynamic QoS in a network distributing audio visual content
KR101661210B1 (ko) 2008-07-24 2016-09-29 삼성전자주식회사 Ｉｐｔｖ 통신 서비스 수행 방법 및 장치
US8005015B2 (en) * 2008-07-28 2011-08-23 Telefonaktiebolaget L M Ericsson (Publ) Signaling framework for negotiating and executing composition of registries
US8700033B2 (en) * 2008-08-22 2014-04-15 International Business Machines Corporation Dynamic access to radio networks
US8059615B1 (en) 2008-09-08 2011-11-15 Sprint Spectrum L.P. Selective personality negotiation during session negotiation
US9015599B2 (en) * 2008-10-16 2015-04-21 At&T Intellectual Property I, L.P. Devices, methods and computer-readable media for providing control of switching between media presentation screens
US8346233B2 (en) * 2008-10-16 2013-01-01 At&T Intellectual Property I, L.P. Devices, methods, and computer-readable media for providing sevices based upon identification of decision makers and owners associated with communication services
US8185489B2 (en) * 2008-10-16 2012-05-22 At&T Intellectual Property, I, L.P. Devices, methods, and computer-readable media for providing calendar-based communication system services
US8615575B2 (en) * 2008-10-16 2013-12-24 At&T Intellectual Property I, L.P. Devices, methods, and computer-readable media for providing quality of service optimization via policy-based rearrangements
US8320927B2 (en) * 2008-10-16 2012-11-27 At&T Intellectual Property I, L.P. Devices, methods, and computer-readable media for providing broad quality of service optimization using policy-based selective quality degradation
US8391882B2 (en) * 2008-10-22 2013-03-05 Qualcomm Incorporated Method and system for interference management in a spectrum shared by WAN and femto cells
US8904276B2 (en) * 2008-11-17 2014-12-02 At&T Intellectual Property I, L.P. Partitioning of markup language documents
US8549198B2 (en) * 2009-03-27 2013-10-01 Schneider Electric It Corporation Communication protocol
US9626681B2 (en) * 2009-04-02 2017-04-18 International Business Machiines Corporation Negotiable information access in electronic social networks
US8972596B2 (en) * 2009-04-28 2015-03-03 The Boeing Company System and method for effecting communications among devices in different domains employing different operating protocols
US9369510B2 (en) * 2009-07-16 2016-06-14 International Business Machines Corporation Cost and resource utilization optimization in multiple data source transcoding
US8953038B2 (en) * 2009-08-31 2015-02-10 International Business Machines Corporation Distributed video surveillance storage cost reduction using statistical multiplexing principle
FR2951898B1 (fr) * 2009-10-27 2015-10-02 Sagem Comm Procede d'etablissement d'une session applicative, dispositif et notification correspondante
US8578020B2 (en) * 2009-12-24 2013-11-05 Empire Technology Development Llc Dynamic mobile application quality-of-service monitoring and reporting
CN102195959B (zh) * 2010-03-11 2015-08-12 中兴通讯股份有限公司 Sip信令的xml数据的解析方法及装置
US20110302287A1 (en) * 2010-06-04 2011-12-08 Muppirala Kishore Kumar Quality of service control
US8943451B2 (en) * 2010-06-23 2015-01-27 Mentor Graphics Corporation Hierarchical finite state machine generation for power state behavior in an electronic design
US20120005351A1 (en) * 2010-07-02 2012-01-05 Cisco Technology, Inc. Method and apparatus for transmitting an application identifier across application elements
WO2012006310A1 (en) * 2010-07-06 2012-01-12 Interdigital Patent Holdings, Inc. Ip multimedia subsystem (ims)-based pre-negotiation of video codec for video single radio video call continuity
US10250678B2 (en) * 2010-07-07 2019-04-02 Qualcomm Incorporated Hybrid modes for peer discovery
FR2959088A1 (fr) * 2010-09-14 2011-10-21 France Telecom Procede de traitement d'une demande d'etablissement d'une communication, systeme, equipement et programme d'ordinateur correspondants
US8805970B2 (en) * 2010-10-25 2014-08-12 International Business Machines Corporation Automatic management of configuration parameters and parameter management engine
US9043797B2 (en) 2010-10-26 2015-05-26 Qualcomm Incorporated Using pause on an electronic device to manage resources
US9191284B2 (en) 2010-10-28 2015-11-17 Avvasi Inc. Methods and apparatus for providing a media stream quality signal
US10531516B2 (en) 2010-11-05 2020-01-07 Mark Cummings Self organizing system to implement emerging topologies
US9311108B2 (en) 2010-11-05 2016-04-12 Mark Cummings Orchestrating wireless network operations
US10694402B2 (en) 2010-11-05 2020-06-23 Mark Cummings Security orchestration and network immune system deployment framework
US10285094B2 (en) 2010-11-05 2019-05-07 Mark Cummings Mobile base station network
US10687250B2 (en) 2010-11-05 2020-06-16 Mark Cummings Mobile base station network
US9531774B2 (en) * 2010-12-13 2016-12-27 At&T Intellectual Property I, L.P. Multicast distribution of incrementally enhanced content
KR20120083033A (ko) * 2011-01-17 2012-07-25 삼성전자주식회사 무선통신시스템에서 응용 프로그램의 서비스 품질 서비스를 지원하기 위한 시스템 및 방법
US8929561B2 (en) * 2011-03-16 2015-01-06 Apple Inc. System and method for automated audio mix equalization and mix visualization
US8694587B2 (en) * 2011-05-17 2014-04-08 Damaka, Inc. System and method for transferring a call bridge between communication devices
DE102012013336B4 (de) * 2011-07-08 2015-04-09 Avaya Inc. Aushandeln einer kontinuierlichen multi-stream-präsenz
US20140181266A1 (en) * 2011-09-29 2014-06-26 Avvasi Inc. System, streaming media optimizer and methods for use therewith
US9118738B2 (en) 2011-09-29 2015-08-25 Avvasi Inc. Systems and methods for controlling access to a media stream
US9042449B2 (en) 2011-09-29 2015-05-26 Avvasi Inc. Systems and methods for dynamic transcoding of indexed media file formats
US20130304934A1 (en) * 2011-09-29 2013-11-14 Avvasi Inc. Methods and systems for controlling quality of a media session
US20130086279A1 (en) * 2011-09-29 2013-04-04 Avvasi Inc. Systems and methods for media service delivery
US20130124708A1 (en) * 2011-11-10 2013-05-16 Electronics And Telecommunications Research Institute Method and system for adaptive composite service path management
CN103368935B (zh) * 2012-03-11 2018-08-07 三星电子株式会社 在Wi-Fi显示网络中提供增强Wi-Fi显示会话的方法和装置
US20140095695A1 (en) * 2012-09-28 2014-04-03 Ren Wang Cloud aware computing distribution to improve performance and energy for mobile devices
US9021091B2 (en) * 2012-10-15 2015-04-28 International Business Machines Corporation Transaction middleware based application level transaction instance tracking across a composite application
WO2014066975A1 (en) * 2012-10-30 2014-05-08 Avvasi Inc. Methods and systems for controlling quality of a media session
JP2014090387A (ja) * 2012-10-31 2014-05-15 Ricoh Co Ltd 情報処理装置、会議システムおよびプログラム
US9621480B2 (en) 2013-03-04 2017-04-11 Vigo Software Ltd Data acquisition pertaining to connectivity of client applications of a service provider network
US9391749B2 (en) * 2013-03-14 2016-07-12 Ashwin Amanna, III System and method for distributed data management in wireless networks
US9299049B2 (en) * 2013-03-15 2016-03-29 Sap Se Contract-based process integration
US9591514B2 (en) * 2013-04-19 2017-03-07 Microsoft Technology Licensing, Llc Optimization of over-the-top (OTT) services on carrier networks
WO2014169331A1 (en) 2013-04-19 2014-10-23 National Ict Australia Limited Checking undoability of an api-controlled computing system
US9563907B2 (en) 2013-06-13 2017-02-07 Vigo Software Ltd Offer based provision of fee based network access
FR3007604A1 (fr) * 2013-06-21 2014-12-26 France Telecom Procede d'acquisition d'un module de codage/decodage dans un reseau de telecommunications
US9197529B2 (en) 2013-07-12 2015-11-24 Nicira, Inc. Tracing network packets through logical and physical networks
US9282019B2 (en) 2013-07-12 2016-03-08 Nicira, Inc. Tracing logical network packets through physical network
FR3011704A1 (fr) * 2013-10-07 2015-04-10 Orange Procede de mise en œuvre d'une session de communication entre une pluralite de terminaux
US9894117B2 (en) * 2013-10-09 2018-02-13 Cisco Technology, Inc. File transfers for virtual conferences
US9986044B2 (en) * 2013-10-21 2018-05-29 Huawei Technologies Co., Ltd. Multi-screen interaction method, devices, and system
JP6466850B2 (ja) * 2013-10-28 2019-02-06 サターン ライセンシング エルエルシーＳａｔｕｒｎ Ｌｉｃｅｎｓｉｎｇ ＬＬＣ コンテンツ供給装置、コンテンツ供給方法、プログラム、端末装置、およびコンテンツ供給システム
US10037554B2 (en) 2013-10-30 2018-07-31 Vigo Software Ltd Aggregated billing for application-based network access and content consumption
CN103634299B (zh) * 2013-11-14 2016-09-14 北京邮电大学 基于多连接的实时流媒体传输终端与方法
US9173133B2 (en) * 2013-12-26 2015-10-27 Cellco Partnership Mobile device with guaranteed QoS
US9462618B2 (en) * 2014-03-06 2016-10-04 Mediatek Inc. Method of call setup time reduction for voice over LTE
DE102014006038A1 (de) 2014-04-25 2015-10-29 Unify Gmbh & Co. Kg Verfahren und Vorrichtung zur Übermittlung und Adaption von Daten, Computerprogramm, Softwareprodukt und Digitales Speichermedium
FR3026595A1 (fr) * 2014-09-25 2016-04-01 Orange Procede de negociation de codecs dans les reseaux ip
US10469342B2 (en) 2014-10-10 2019-11-05 Nicira, Inc. Logical network traffic analysis
WO2016069009A1 (en) 2014-10-31 2016-05-06 Hewlett Packard Enterprise Development Lp End to end quality of service in storage area networks
EP3225071B1 (en) * 2014-11-27 2021-07-21 Koninklijke KPN N.V. Infrastructure-based d2d connection setup using ott services
DE102015001622A1 (de) 2015-02-09 2016-08-11 Unify Gmbh & Co. Kg Verfahren zur Übertragung von Daten in einem Multimedia-System, sowie Softwareprodukt und Vorrichtung zur Steuerung der Übertragung von Daten in einem Multimedia-System
US20160269493A1 (en) * 2015-03-10 2016-09-15 Qualcomm Incorporated Methods and devices to establish services between service and connectivity strata
FR3034608A1 (fr) * 2015-03-31 2016-10-07 Orange Procede de priorisation de flux medias dans un reseau de communications
EP3286952A4 (en) * 2015-04-22 2018-09-12 Qualcomm Incorporated Correlating and combining of mdt and qoe metrics
KR102401477B1 (ko) * 2015-11-24 2022-05-25 삼성전자주식회사 사용자 단말 장치 및 그 제어 방법
KR102540459B1 (ko) 2016-12-22 2023-06-05 한화비전 주식회사 Rtp/rtsp 표준을 따르는 서버와 클라이언트에서 실시간 영상 스트리밍 방법
US10200914B2 (en) 2017-01-20 2019-02-05 Microsoft Technology Licensing, Llc Responsive quality of service management
US10805239B2 (en) 2017-03-07 2020-10-13 Nicira, Inc. Visualization of path between logical network endpoints
US10608887B2 (en) 2017-10-06 2020-03-31 Nicira, Inc. Using packet tracing tool to automatically execute packet capture operations
US10673962B2 (en) * 2017-11-28 2020-06-02 Sap Se Service cross-consumption based on an open service broker application programming interface
US11477667B2 (en) 2018-06-14 2022-10-18 Mark Cummings Using orchestrators for false positive detection and root cause analysis
CN112313991B (zh) * 2018-06-26 2024-03-22 诺基亚技术有限公司 用于通信系统中的增强型数据分组流处理的方法和装置
KR102436246B1 (ko) 2018-07-05 2022-08-25 삼성전자 주식회사 전자 장치에서 멀티미디어 서비스 제공 방법 및 장치
WO2020062000A1 (en) * 2018-09-28 2020-04-02 Nokia Shanghai Bell Co., Ltd. Proactive resource reservation for communications
CN111107589B (zh) * 2018-11-12 2021-12-24 维沃移动通信有限公司 配置参数协商方法、终端设备、系统和存储介质
US11689583B2 (en) 2018-12-10 2023-06-27 Telefonaktiebolaget Lm Ericsson (Publ) Network node, entity and methods performed therein for handling a communication session in a communication network
CN111290983B (zh) 2018-12-10 2023-05-16 澜至电子科技（成都）有限公司 Usb传输设备及传输方法
CN111277972B (zh) * 2019-01-25 2022-12-23 维沃移动通信有限公司 一种直接通信接口QoS参数确定方法及相关设备
US11109394B2 (en) * 2019-07-30 2021-08-31 Cypress Semiconductor Corporation Methods, systems and devices for providing differentiated quality of service for wireless communication devices
US11283699B2 (en) 2020-01-17 2022-03-22 Vmware, Inc. Practical overlay network latency measurement in datacenter
US11196628B1 (en) 2020-07-29 2021-12-07 Vmware, Inc. Monitoring container clusters
US11570090B2 (en) 2020-07-29 2023-01-31 Vmware, Inc. Flow tracing operation in container cluster
US11558426B2 (en) 2020-07-29 2023-01-17 Vmware, Inc. Connection tracking for container cluster
US11777863B2 (en) * 2020-12-21 2023-10-03 Landis+ Gyr Innovations Optimized route for time-critical traffic in mesh network
US11736436B2 (en) 2020-12-31 2023-08-22 Vmware, Inc. Identifying routes with indirect addressing in a datacenter
US11336533B1 (en) 2021-01-08 2022-05-17 Vmware, Inc. Network visualization of correlations between logical elements and associated physical elements
CN113301055A (zh) * 2021-06-22 2021-08-24 展讯通信（上海）有限公司 提高ims会话系统兼容性的方法及装置、网络设备及移动设备
US11687210B2 (en) 2021-07-05 2023-06-27 Vmware, Inc. Criteria-based expansion of group nodes in a network topology visualization
US11711278B2 (en) 2021-07-24 2023-07-25 Vmware, Inc. Visualization of flow trace operation across multiple sites
US11706109B2 (en) 2021-09-17 2023-07-18 Vmware, Inc. Performance of traffic monitoring actions
CN114866300B (zh) * 2022-04-22 2024-06-18 中国人民解放军国防科技大学 一种基于重放分析的网络协议软件状态变量识别方法
WO2024011019A2 (en) * 2022-07-08 2024-01-11 Qualcomm Incorporated Contextual quality of service for mobile devices
CN115767484B (zh) * 2022-11-07 2024-07-09 中国联合网络通信集团有限公司 客服场景下的通话处理方法、装置、服务器、系统及介质

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5574934A (en) * 1993-11-24 1996-11-12 Intel Corporation Preemptive priority-based transmission of signals using virtual channels
US6678264B1 (en) * 1999-06-30 2004-01-13 Nortel Networks Limited Establishing connections with a pre-specified quality of service across a communication network
US6707820B1 (en) * 1999-12-16 2004-03-16 Intervoice Limited Partnership Virtual circuit network dynamic channel management
US7058973B1 (en) * 2000-03-03 2006-06-06 Symantec Corporation Network address translation gateway for local area networks using local IP addresses and non-translatable port addresses
DE60042965D1 (de) * 2000-05-24 2009-10-29 Sony Deutschland Gmbh Dienstqualitätsunterhandlung
DE60036295T2 (de) 2000-12-08 2008-05-29 Sony Deutschland Gmbh Schnittstelle auf hoher Ebene für dienstqualitätbasierte mobile Multimedia-Anwendungen
EP1248431B1 (en) * 2001-03-27 2007-10-31 Sony Deutschland GmbH Method for achieving end-to-end quality of service negotiation for distributed multimedia applications
US6957071B1 (en) * 2001-07-18 2005-10-18 Cisco Technology, Inc. Method and system for managing wireless bandwidth resources

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20210149888A (ko) * 2017-05-08 2021-12-09 후아웨이 테크놀러지 컴퍼니 리미티드 통신 시스템 간 이동 방법 및 장치
KR102500723B1 (ko) 2017-05-08 2023-02-16 후아웨이 테크놀러지 컴퍼니 리미티드 통신 시스템 간 이동 방법 및 장치
US12114219B2 (en) 2017-05-08 2024-10-08 Huawei Technologies Co., Ltd. Method for moving between communications systems and apparatus
KR20220068021A (ko) * 2020-11-18 2022-05-25 주식회사 케이티 동적인 QoS 제공 방법
KR102752421B1 (ko) 2020-11-18 2025-01-08 주식회사 케이티 동적인 QoS 제공 방법

Also Published As

Publication number Publication date
JP4342948B2 (ja) 2009-10-14
DE60203779D1 (de) 2005-05-25
EP1331785B1 (en) 2005-04-20
CN1623308A (zh) 2005-06-01
US20050157660A1 (en) 2005-07-21
ES2236370T3 (es) 2005-07-16
DE60203779T2 (de) 2006-03-09
EP1331785A1 (en) 2003-07-30
CN1623308B (zh) 2011-11-16
WO2003063439A2 (en) 2003-07-31
WO2003063439A3 (en) 2003-12-24
ATE293863T1 (de) 2005-05-15
US7602723B2 (en) 2009-10-13

Similar Documents

Publication Publication Date Title
JP4342948B2 (ja) マルチストリーム及びマルチメディアアプリケーションのためのＱｏＳサポートを目的としたエンドツーエンド交渉プロトコルの様々なフェーズを実行するモデル
EP1248431B1 (en) Method for achieving end-to-end quality of service negotiation for distributed multimedia applications
Guenkova-Luy et al. End-to-end quality-of-service coordination for mobile multimedia applications
CN1729672B (zh) 用于分布式多媒体应用的能力和服务质量协商和会话建立的软件体系结构
CN102365850B (zh) 用于提供相关服务级别的方法和装置
US8127011B2 (en) Network resource negotiation between a service provider network and an access network
Steinmetz et al. Quality of Service: Where are we?
TW200417195A (en) Communication system and its terminal
WO2009076840A1 (zh) 一种实现媒体协商的方法、系统和装置
US7512118B1 (en) CODEC negotiation considering quality and costs
Hakiri et al. Supporting SIP-based end-to-end data distribution service QoS in WANs
Delgrossi Design of reservation protocols for multimedia communication
US20010034784A1 (en) Method, gateway system and arrangement in a communication network
Kanter Adaptive Personal Mobile Communication, Service Architecture and Protocols.
Papageorgiou A comparison of H. 323 vs SIP
Kahmann et al. A proxy architecture for collaborative media streaming
Kanter Adaptive Personal Mobile Communication
Krishnakumar et al. Constraint based network adaptation for ubiquitous applications
Hesselman et al. Middleware support for media streaming establishment driven by user-oriented QoS requirements
Van INTERNET-OF-THINGS STREAMING OVER REALTIME TRANSPORT PROTOCOL
Chou et al. Web service for tele-communication
Kassinen et al. Top-down connectivity policy framework for mobile peer-to-peer applications
Kellerer Intelligence on top of the networks: SIP based service control layer signaling
Karmouch Dynamic composition and management of virtual devices for ad hoc multimedia service delivery
Mortada et al. Internet telephony signaling

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20060112

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20080708

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A821

Effective date: 20081006

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20081006

RD02 Notification of acceptance of power of attorney

Free format text: JAPANESE INTERMEDIATE CODE: A7422

Effective date: 20081006

A02 Decision of refusal

Free format text: JAPANESE INTERMEDIATE CODE: A02

Effective date: 20090203

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20090428

A911 Transfer to examiner for re-examination before appeal (zenchi)

Free format text: JAPANESE INTERMEDIATE CODE: A911

Effective date: 20090608

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: 20090623

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: 20090708

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20120717

Year of fee payment: 3

R150 Certificate of patent or registration of utility model

Ref document number: 4342948

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

Free format text: JAPANESE INTERMEDIATE CODE: R150

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20120717

Year of fee payment: 3

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20130717

Year of fee payment: 4

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

LAPS Cancellation because of no payment of annual fees