ＰＣＭＭアプリケーションマネージャ
ネットワークエンドポイント(100と200)間でネットワークリソースを割り当てる方法では、セッション開始要求をアプリケーションマネージャに供給する。このアプリケーションマネージャは論理的かつ物理的に、ネットワークエンドポイントに関連するアプリケーションサーバから分離されている。この要求は、ネットワークエンドポイント間の通信をネットワークリソースのセットを通して開始させる。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は一般的に、ポリシー指向のネットワークリソース管理に関する。
【背景技術】
【０００２】
［技術背景］
一般的にポリシーサーバは、ルールの集合、すなわちポリシーに従いネットワークリソースを管理する。いくつかのポリシーサーバは単純に、ネットワークリソースを未分化データに対してネットワークルーティングエレメント間で、またはスイッチングエレメント間（例えばルータAからルータBへ）で切り分けるが、本明細書のポリシーサーバはネットワークリソースをアプリケーションの必要性を満たすために管理する。例えばボイス・オーバー・アイピー（VoIP)アプリケーションでは、2つのネットワークエンドポイントが他方とネットワークを介してVoIPコールを確立しようと希望する。ネットワークエンドポイントはネットワークリソースをポリシーサーバからVoIPコールのために要求する。
【０００３】
図1はこのVoIPの1つの実現例を示す。第1ネットワークエンドポイント10は、第2ネットワークエンドポイント12へのVoIPコールを、アクセスネットワーク14を介して確立しようと希望する。第1エンドポイント10はセッション属性を、アプリケーションサーバへのそのセッションセットアップ要求の中で識別する。アプリケーションサーバ18はVoIPアプリケーションを含んでおり、これがエンドポイント間のセッションまたはコールの整合およびセットアップを行う。アプリケーションサーバ18は、VoIPセッションに関連するリソースに対する要求をポリシーサーバ20に、パケットケーブルマルチメディア（PCMM）プロトコルを使用して中継する(PKT-TR-MM-ARCH-V01-030627, V01,2003年6月27日;そして,PKT-SP-MM-I01-030627,2003年6月27日)。アプリケーションサーバ18はアプリケーションマネージャ22と同意語であり、このアプリケーションマネージャはこのセッションに対するQoSの予約および管理に必要な機能性をポリシーサーバを介して提供する。ポリシーサーバは反対にネットワークリソースをコントロールし、適切な処置がこのコールまたはセッションに関連するすべてのメディアストリームに適用されることを保証する。
【０００４】
アプリケーションサーバ18に配置されたアプリケーションマネージャ22が機能性を有することはアプリケーションサーバ18の構成を複雑にする。なぜならいくつかのアプリケーションサーバはアプリケーションマネージャを必要としないから、アプリケーションマネージャは不要なコストと、それらの設置のための複雑性の原因となる。
【発明の開示】
【課題を解決するための手段】
【０００５】
［発明の概要］
1つの側面は、複数のネットワークリソースをネットワークエンドポイント間でアプリケーションマネージャに対するセッション開始要求を使用して、ネットワークエンドポイント間でリソースを予約するために割り当てる方法である。アプリケーションマネージャは論理的かつ物理的に（または論理的にだけ）、ネットワークエンドポイントに関連するアプリケーションサーバから分離されている。この方法はさらに、アプリケーションマネージャからのPCMMメッセージをポリシーサーバに、セッション開始要求の結果として提供することを含む。ここにおいてPCMMメッセージは少なくともセッション開始要求に埋め込まれたいくつかの情報を含む。PCMM以外の適切なプロトコルも、アプリケーションマネージャとポリシーサーバとの間でこの情報を伝送するのに使用することができる。この方法はさらに、ポリシーサーバを介して、ネットワークエンドポイントを接続する経路を形成するために複数のネットワークリソースを選択することを含む。ここにおいてポリシーサーバは複数のネットワークリソースをPCMMメッセージに基づいて選択する。
【０００６】
セッション開始要求はセッション開始プロトコル(SIP、J.Rosenberg,et.al.,"SIP:Session Initiation Protocol",RFC3261,2002年6月を参照)を介して、SIPメッセージにあるセッション記述プロトコル(SDP、Handley,M.andV.Jacobson,"SDP:Session Description Protocol",RFC2327,1998年4月を参照)フィールドを使用し、ネットワークでのリソースの必要なQoS予約を実行するために通信することができる。QoS情報はセッション開始要求内のセッション記述プロトコルフィールドに含むことができる。アプリケーションマネージャはネットワークエンドポイントの1つとアプリケーションサーバとの間に挿入配置することができる。アプリケーションマネージャは、セッション開始要求をネットワークエンドポイントとアプリケーションサーバとの間で透明に中継し、その際にネットワークエンドポイントまたはアプリケーションサーバの機能的変形を必要としない。
【０００７】
1つの実施例でこの方法は、セッション開始要求からのハイレベルQoS情報を基礎となるネットワーク技術の理解と結び付け、PCMMメッセージで使用するために詳細なQoS情報を形成する。別の実施例でこの方法はQoS情報を、SDPまたはRSVPフロースペック(IETFドキュメント、Wroclawski,J.,"The Use of RSVP with IETF Integrated Services",RFC2210,1997年9月.Wroclawski,J.,"Specificationof the Controlled-Load Network Element Service",RFC2211,1997年9月. Shenker,S.,Partridge,C.,Guerin,R., "Specification of Guaranteed Qualityof Service", RFC2212,1997年9月に定義されているように)を介してXMLメッセージに埋め込み、XMLメッセージを使用して、セッション開始要求をアプリケーションサーバと通信する。このアプリケーションサーバは引き続き、QoS情報をアプリケーションマネージャにXMLメッセージで伝送する。この方法は択一的にHTTPを使用してXMLメッセージをアプリケーションサーバと通信し、このアプリケーションサーバは引き続きQoS情報をアプリケーションマネージャに伝送する。
【０００８】
実施例でアプリケーションサーバは、アプリケーションマネージャと通信するためにユニークなセッション識別子を使用することによりステートレスな状態に留まる。そしてセッションとリソースとの関連は、分離されたアプリケーションマネージャで維持される。セッション識別子は、エンドポイントとアプリケーションサーバとの間のSIPシグナリングメッセージから形成される。
【０００９】
実施例でこの方法は、SDPメディア属性に基づくRSVPフロースペックパラメータの選択を含み、フロースペックパラメータ選択動作を、PCMMフレームワークでのリソース予約のために実行する能力を提供する。この方法はさらに、CMTSでのDOCSISサービスフローQoSパラメータとのインタオペラビリティを保証し、種々異なるCMTSベンダー実現にわたる、選択されたフロースペックパラメータの正規化によりQoSを提供する。この方法はまた、SDPメディア属性の種々のオプションフィーチャを実現するネットワークエンドポイント間のインタオペラビリティも保証する。
【００１０】
実施例でこの方法は、各設定に対するデフォルト値に加えて、方向（アップストリームとダウンストリーム）毎にコンフィギュラブルな設定を提供し、フロースペックパラメータ選択でこの設定を、各設定に対するデフォルト値に従って使用する。コンフィギュラブルな設定および関連のデフォルト値は次のものを含む：
遅延、100ms（ダウンストリームとアップストリーム）
バンド幅調整、1.125（ダウンストリーム）
バンド幅調整、1.0（アップストリーム）
レートファクタ、4.0（ダウンストリームとアップストリーム）
最小パケットサイズ、640（ダウンストリームとアップストリーム）
最大パケットサイズ、1500（ダウンストリームとアップストリーム）
スラックターム、800（ダウンストリームとアップストリーム）
レートリミット、96000（アップストリーム）
レートリミット、0（ダウンストリーム）
ポールインターバル限界、6000μs（アップストリーム）
ポールインターバルセット、空（アップストリーム）
"ptime"メディア属性（パケット化時間）がSDPに設定されていなければ、この方法は、パケットケーブルオーディオ/ビデオコーデック仕様により指定される全てのパケット化時間に対して十分なリソースがリザーブされるようにRSVPフロースペックパラメータを選択する。
【００１１】
マルチプルコーデックがSDPフィールドで取り決められていれば、この方法は、パケットケーブルオーディオ/ビデオコーデック仕様により指定される全てのパケット化時間に対して十分なリソースが予約されるようにRSVPフロースペックパラメータを選択する。
【００１２】
実施例でこの方法は、ptimeメディア属性が未知の場合、正確にptime（パケット化時間）を決定するためにDOCSIS QoS MIBを使用し、引き続きptimeメディア属性が決定されると、予約されたリソースを変更する。別の実施例でこの方法は、使用中の特定のコーデックの決定のためにマルチプロコーデックが取り決められる場合、正確にptime（パケット化時間）を決定するためにDOCSIS QoS MIBを使用し、引き続き特定のコーデックが決定されると、予約されたリソースを変更する。
【００１３】
実施例ではアプリケーションマネージャが、（レジスタ）REGISTERメッセージから、一方または両方のエンドポイントのコンタクトIPアドレスとポート番号を学習し、これによりアプリケーションマネージャは招待（INVITE）メッセージをエンドポイントに転送することができる。別の実施例でアプリケーションマネージャはアプリケーションサーバを問い合わせ、一方または両方のエンドポイントのコンタクトIPアドレスおよびポート番号を獲得し、これによりアプリケーションマネージャはINVITEメッセージをエンドポイントに転送することができる。
【００１４】
別の側面では、複数のネットワークリソースをネットワークエンドポイント間で割り当てるためのシステムがアプリケーションマネージャを有し、このアプリケーションマネージャは、(i)ネットワークエンドポイント間での通信を、ネットワークリソースのセットを通して開始するセッション開始要求を受信し、(ii)セッション開始要求に埋め込まれた少なくとも複数の情報を含むPCMMメッセージを発生する。ネットワークエンドポイント間の通信はアプリケーションサーバに常駐するアプリケーションを使用する。このシステムはさらに、PCMMメッセージを受信し、ネットワークエンドポイントを接続する経路を形成するために複数のネットワークリソースを選択するポリシーサーバを有する。ここにおいてポリシーサーバは複数のネットワークリソースをPCMMメッセージに基づいて選択する。
【発明を実施するための最良の形態】
【００１５】
［詳細な説明］
説明される実施例はネットワークアーキテクチャであり、このネットワークアーキテクチャはアプリケーションサーバ、アプリケーションマネージャ、およびアプリケーション特有のポリシーをネットワークリソース割り当てのために実現するポリソーサーバを使用する。この実施例はアプリケーションマネージャをアプリケーションサーバから抽出し、従ってアプリケーションサーバは複雑なネットワーク固有の信号インタフェース、例えばPCMMを、ネットワークを介する入場コントロールまたはリソース要求を実行するために有する必要がない。この実施例は、高品質ビデオ遠隔会議セッションを実施する2つのエンドポイントを記述するが、この概念はまた他のアプリケーション、例えばビデオストリーミング、ボイスオーバインターネットプロトコル(VoIP)通信、およびネットワークゲームにも適用することができる。アプリケーションマネージャをアプリケーションサーバから抽出することは、アプリケーションマネージャとアプリケーションサーバとの間に新たな信号インタフェースを指定する。このインタフェースはPCMMよりも格段に単純なインタフェースであり、SIPシグナリングまたは別のプロトコル、例えばeXtensibMarkupLanguage(XML)、リアルタイムストリーミングプロトコル(RTSP)またはハイパーテキスト伝送プロトコル(HTTP)を、アプリケーションサーバとアプリケーションマネージャとの間の通信に使用することができる。抽出されたアプリケーションマネージャはこのような格段に単純な言語を解釈し、より複雑でネットワーク固有の言語に翻訳することができ、これによりネットワークリソースの予約と管理のためにポリシーサーバと通信することができる。
【００１６】
CableLabsパケットケーブルマルチメディア(PCMM)プロトコル仕様(PKT-TR-MM-ARCH-V01-030627,V01,2003年6月27日)は、アプリケーションサーバに埋め込まれたアプリケーションマネージャ機能を定義する。アプリケーションマネージャ機能はポリシーサーバとの通信を行い、ポリシー決定、例えば入場コントロールおよびサービス品質(QoS)を、PCMMシグナリングインタフェースにより実現する。アプリケーションマネージャをアプリケーション自体から(すなわちアプリケーションサーバから)抽出することにより、この実施例ではアプリケーションサーバがPCMMアーキテクチャおよびその関連のプロトコルについて知る必要がなくなる。従ってこの実施例では、アプリケーションサーバはPCMM環境に、より一般的に(すなわち抽出されたアプリケーションマネージャを介して)インタフェースすることができ、また(ゲートトークンに関する)状態を維持するためのタスクをアプリケーションマネージャに任せる。そしてアプリケーションマネージャはスタンドアローンとすることも、またはポリシーサーバに埋め込むこともでき、このことはサービスの引き渡しに関連するネットワークエレメントの数を最小にする。
【００１７】
図2は、ネットワークアーキテクチャの1つの実施例を示す。ここには、第1ネットワークエンドポイント100，第2ネットワークエンドポイント102，アクセスネットワーク104，アプリケーションサーバ106，ポリシーサーバ108およびアプリケーションマネージャ110が含まれる。この実施例は、ポリシーサーバ108とアプリケーションマネージャ110の周囲に破線ブロックを有しており、このことはこれら2つのコンポーネントの機能性が同じ物理的プラットフォームに存在することを意味する。しかし後で説明するように、アプリケーションマネージャ110は、ポリシーサーバ108とは空間的に別個の物理的プラットフォームに存在することもできる(すなわちスタンドアローン構成)。この実施例で第1ネットワークエンドポイント102はSIP交換を使用して、アクセスネットワーク106を介する第2ネットワークエンドポイント104へのビデオ遠隔会議セッションを要求する。このビデオ遠隔会議セッションは、アプリケーションサーバ106に常駐するビデオ遠隔会議アプリケーションを使用する。
【００１８】
アプリケーションマネージャ110はSIP信号経路112に配置されている。エンドポイント100，102間のSIP接続112とアプリケーションサーバ106が直接接続されて図2に示されているが、これは簡単にするためであり、エンドポイントからの全ての接続はアクセスネットワーク104を通ることを理解されたい。
【００１９】
各SIPセッションは2つのSIPエンドポイント間で3ウェイハンドシェークを以て開始する。セッションを開始するエンドポイント(発呼者)はまずINVITEメッセージを受信エンドポイント(被呼者)に送信する。被呼者は、発呼者へのOKメッセージを以て応答する。次に発呼者は、ACKメッセージを以て応答する。図2では、2つのSIPエンドポイントが第1ネットワークエンドポイント100と第2ネットワークエンドポイント102であり、ここで第1ネットワークエンドポイント100が発呼者、第2ネットワークエンドポイント102が被呼者である。アプリケーションサーバ106はこの実施例ではSIPプロクシサーバとして機能し、SIPメッセージを2つのエンドポイント100および102とやりとりする。
【００２０】
アプリケーションマネージャ110はSIP信号経路に配置されているが、アプリケーションマネージャ110はSIPハンドシェーク交換を透明に通過させる。従ってSIPエンドポイントまたはプロクシサーバ(アプリケーションマネージャ106)はSIP信号経路のアプリケーションマネージャ110を知覚しない。アプリケーションマネージャ110が、第1ネットワークエンドポイント100からの第1 SIP INVITEメッセージをアプリケーションサーバ106にパスすると、アプリケーションマネージャ110はセッション記述プロトコル(SDP)フィールドをINVITEメッセージから、第1ネットワークエンドポイント100についての情報のために抽出する。アプリケーションマネージャ110がOKメッセージをアプリケーションサーバ106から受信すると、アプリケーションマネージャはSDPフィールドをOKメッセージから、アプリケーションサーバについての情報のために抽出する。OKメッセージを第1ネットワークエンドポイント100に送信する前に、アプリケーションマネージャ110は、サービス品質（QoS）を第1ネットワークエンドポイント100に対してだけ動的に形成するか、または第1ネットワークエンドポイント100と第2ネットワークエンドポイント102の両方に対して動的に形成するかを決定する。この決定に基づき、アプリケーションマネージャはGateStメッセージを、PCMMリンク114を介してポリシーサーバ108に送信する。アプリケーションマネージャが、SIP交換中のSDPフィールドをセットゲートメッセージに対するパラメータにどのように翻訳するかについては、後でボイス通信およびビデオ通信の両者に対して説明する。
【００２１】
SDPにリストアップされた各メディア形式に対して、アプリケーションマネージャ110は2つのゲートをポリシーサーバで形成する。1つはアップストリーム方向にあり、もう1つはダウンストリーム方向にある。従ってこの実施例でのビデオ遠隔通信セッションに対しては、アプリケーションマネージャ110は4つのゲートをエンドポイント毎に形成する。1つのゲートはアップストリームオーディオに対するものであり、1つのゲートはアップストリームビデオに対するものであり、1つのゲートはダウンストリームオーディオに対するものであり、1つのゲートはダウンストリームビデオに対するものである。
【００２２】
アプリケーションマネージャ110は、QoSを形成すべきか否かを、INVITEメッセージまたはOKメッセージのViaヘッダを検査することにより決定する。Viaヘッダにあるエントリー数に基づいて、アプリケーションマネージャ110は第1ネットワークエンドポイント100と第2ネットワークエンドポイント102が共に同じアプルケーションマネージャを第1ホップとして使用しているか否かを決定することができる。マルチドメイン環境では、発呼者が1つのアプリケーションマネージャを第1ホップとして使用しており、被呼者が別のアプリケーションマネージャをその第1ホップとして使用していることがあり得る。このようなマルチドメインの場合、各アプリケーションマネージャは、当該のアプリケーションマネージャをその第1ホップのために使用するネットワークエンドポイントに対してだけQoSを形成する。INVITEメッセージおよびOKメッセージを相応するPCMMメッセージおよび関連するゲートに関連付けるために、アプリケーションマネージャはSIPメッセージ中のCallIDを使用する。この技術を使用することにより、分離されたアプリケーションマネージャはネットワークに透明に存在することができ、エンドポイントまたはアプリケーションサーバ機能への変更を必要としない（すなわち現在の構成またはこれらコンポーネントの機能実現に変化はない）。
【００２３】
いったんアプリケーションマネージャ110がエンドポイント間でダイアローグをセットアップし、QoSがこのエンドポイントに対して確立されると、エンドポイントの1つが、そのQoS要求を変更する別のINVITEメッセージを送信する。アプリケーションマネージャ110はこのような再INVITEメッセージを、前記ダイアローグに対して以前に形成されたゲートを変更することによって処理する。
【００２４】
ダイアローグを取り去るべき場合、取り下げを開始するエンドポイントはBYEメッセージを送信する。BYEメッセージが転送された後、アプリケーションマネージャ110は、このダイアローグに対して形成されたQoSを、PCMMゲート削除メッセージをポリシーサーバ108に送信することによってクリアする。アプリケーションマネージャ110は、どのゲートがダイアローグに対して形成されたかに関する情報を格納するためのデータベースを維持する。従ってアプリケーションマネージャは、ダイアローグが取り去られる場合にどのゲートを削除すべきかを識別することができる。
【００２５】
図3は、同じネットワークドメインにある2つのネットワークエンドポイントに対する単純なコールフローを示す図であり、図4は、異なるネットワークドメインにある2つのネットワークエンドポイントに対する単純なコールフローを示す図である。各図に対するコールフローは、2つのドメインにあるエンドポイント間でのSIP信号とPCMMメッセージに対するフローを示す。図4については、各ドメインは固有のアプリケーションマネージャ110とポリシーサーバ108を有し、中央プロクシサーバが2つのドメインを接続する。
【００２６】
別の実施例では、アプリケーションマネージャがQoSを、2フェーズアプローチを介して要求する。アプリケーションマネージャがINVITEメッセージを発呼者から受信すると、このアプリケーションマネージャは発呼者の要求を学習するだけでなく、GateStメッセージをポリシーサーバに送信する。このGateStメッセージはQoSを発呼者および/または被呼者に対して予約だけする。すなわち必要なゲートの委託はまだ行わない。コールのセットアップが進行し、アプリケーションマネージャが相応するOKメッセージを被呼者から受信すると、アプリケーションマネージャは（必要であれば）GateStメッセージを被呼者に対し、およびGateStメッセージを発呼者に対して送信する。この時にアプリケーションマネージャは発呼者と被呼者のゲートを、単に予約するというよりむしろ委託する。
【００２７】
この実施例はポリシーサーバでのゲートの良好なコントロールを提供する。言い替えると、ゲートの最初の予約まで、アプリケーションマネージャはPEP（ポリシーエンフォースメントポイント）上で貴重なリソースを消費しない。アプリケーションマネージャは、このアプリケーションマネージャがOKメッセージを受信し、この時点でセッション確立を完了するために被呼者を使用できる場合だけ、これらのリソースを委託する。
【００２８】
別の実施例では、アプリケーションマネージャは、エンドポイントから到来するREGISTRメッセージからコンタクト情報を学習する。このフィーチャにより、アプリケーションマネージャはエンドポイントのIPアドレスとポート番号を学習することができ、INVITEメッセージをエンドポイントに転送することができる。登録サーバがエンドポイントとのマルチホップを処理できない場合、この登録サーバはINVITEメッセージだけをアプリケーションマネージャに転送することになる。次にこのアプリケーションマネージャはこの情報を使用してINVITEメッセージを正しいエンドポイントに送出する。
【００２９】
別の実施例では、アプリケーションマネージャがコンタクト情報をアプリケーションサーバから、空のコンタクトヘッダを含むREGISTRメッセージにより問い合わせすることによって獲得する。このフィーチャにより、アプリケーションマネージャはエンドポイントのIPアドレスとポート番号を学習することができ、INVITEメッセージをエンドポイントに転送することができる。登録サーバがエンドポイントとのマルチホップを処理できない場合、この登録サーバはINVITEメッセージだけをアプリケーションマネージャに転送することになる。次にアプリケ―ションマネージャはアプリケーションサーバに問い合わせしてコンタクト情報を獲得し、INVITEメッセージを正しいエンドポイントに送出する。
【００３０】
前記の実施例は、エンドポイントと、SIPであるアプリケーションサーバとの間でセッションを開始することができるが、より簡単でよりフレキシブルなプロトコルをエンドポイントとアプリケーションサーバとの間の通信に使用することもできる。例えば1つの実施例では、XMLをエンドポイントに対するSIPの代わりに使用し、QoS情報と共に埋め込まれたセッションセットアップをアプリケーションサーバと通信する。別の実施例では、リアルタイムストリーミングプロトコル（RTSP)またはHTTPがセッション開始およびリソース要求のために使用される。QoS情報は埋め込むことができ、またはSDPまたはIETFRSVPフロースペックの形態とすることができる。
【００３１】
前記の実施例はSIPによりセッションを開始することができるが、アプリケーションサーバとアプリケーションマネージャとの間のインタフェースはSIPであり、他のより簡単なプロトコルもアプリケーションサーバとアプリケーションマネージャとの間の通信に対して使用することができる。例えば1つの実施例ではXMLをアプリケーションサーバに対して使用し、アプリケーションマネージャへのリソース要求を通信する。別の実施例では、リアルタイムストリーミングプロトコル（RTSP）またはHTTPがセッション開始およびリソース要求のために使用される。QoS情報は埋め込むことができ、またはSDPまたはIETFRSVPフロースペックの形態とすることができる。（IETFドキュメント、Wroclawski,J.,"The Use of RSVP with IETF Integrated Services",RFC2210,1997年9月.Wroclawski,J.,"Specificationof the Controlled-Load Network Element Service", RFC2211,1997年9月. Shenker,S., Partridge,C., Guerin,R., "Specification of Guaranteed Quality of Service", RFC2212,1997年9月に定義されているように）。
【００３２】
XMLを使用する場合、アプリケーションサーバはSDPフィールドをXMLメッセージに挿入してアプリケーションマネージャに送信する。このアプリケーションサーバは、SDPフィールドを、エンドポイントとの通信に使用されるSIPメッセージから抽出し、これをXMLメッセージに挿入してアプリケーションマネージャに送信する。次にアプリケーションマネージャは適切なPCMMメッセージへの必要な翻訳を実行する。さらにアプリケーションサーバはアプリケーションマネージャと、このセッションに対する文脈を、ユニークなセッション識別子によって通信する。このセッション識別子は、エンドポイントとアプリケーションサーバとの間のSIPシグナリングメッセージから形成することができる。エンドポイントとアプリケーションサーバとの間のメッセージ活動の結果として、アプリケーションサーバはアプリケーションマネージャとだけ通信すればよいから、アプリケーションサーバはこのプロセスの間にセッションIDを作成し、アプリケーションマネージャにメッセージを発行することができる。このことによりアプリケーションサーバは「ステートレス」状態に留まる。このアプリケーションサーバは、アプリケーションセッションおよびリソースマッピングの状態を維持する必要がなく、従ってアプリケーションサーバの実現と機能性が簡素化される。リソースを放棄すべき場合、アプリケーションサーバは、SIPシグナリングメッセージから作成されたセッション識別子を使用して、アプリケーションマネージャと通信する。このアプリケーションマネージャはセッションの状態とリソースの関連性を維持する。すなわち「ステートフル」状態である。
【００３３】
上記の実施例では、アプリケーションマネージャをポリシーサーバに埋め込むことができ、またはアプリケーションマネージャはスタンドアローンのプラットフォームに常駐することができる。両方の場合とも、アプリケーションマネージャは、SDPにあるQoS情報をより詳細なQoSに、SDPをアクセスネットワークの知識と結合することにより変換し、より詳細なQoS情報をポリシーサーバにPCMMメッセージを介して転送する。
【００３４】
［ビデオSDP翻訳］
以下のパラグラフは、SDPフィールドからPCMMデータへの、デジタルビデオトラフィックのための翻訳の詳細を示す。PCMMアーキテクチャはIETFRSVPフロースペックパラメータを使用して、ポリシーサーバとケーブルモデム端末システム（CMTS)との間でサービス品質（QoS)要求を通信する。以下のパラグラフは、PCMMで使用するのに適切にフロースペックパラメータを選択し、SDPパラメータに基づきSIPユーザエージェント（すなわちネットワークエンドポイント）に対して高品質ビデオ遠隔会議セッションを可能にするやり方を示す。
【００３５】
フロースペックパラメータを選択する際の3つの問題には次のものが含まれる：
１．SDP仕様は発展し続けており、多くのパラメータ（例えばメディア属性）がまだ確立されておらず、ほとんどがオプションである。全てのオプションメディア属性を含んでおらず、フロースペックパラメータ選択もオプションとなるSIP/SDP実現が存在する。
２．圧縮されたデジタルビデオトラフィックは可変ビットレート（VBR)であり、このことはパケットサイズが変化し、ランダムな間隔で到着することを意味する。
３．.DOCSISにより規定され、CMTSにより提供されるようなQoSは多くのオプションと、CMTS実現に依存するフィーチャを有する。DOCSISはデータオーバーケーブルサービスインターフェース仕様のセットを参照し、この仕様はどのようにデータをケーブルネットワークを介して標準仕様で伝送するかを規定する。例えばDOCSISRFIMACプロトコルは、どのようにケーブルモデムを、アクセスネットワークを介して接続するかを規定している。RFIは、DOCSISラジオ周波数インタフェース仕様であり、CMTSとCMネットワークエレメントとの間の物理層インタフェースおよびMACを規定する。このことは、１つのCMTSベンダーが特定のフィーチャを決定するが、他のベンダーは決定しないこと、またはフィーチャの実現を異なって決定することができることを意味する。CMTS、ケーブルモデム、および他の装置との間のインタオペラビリティの問題は、QoSを保証するためのオプションパラメータの選択プロセスをさらに複雑にする。
【００３６】
以下のパラグラフで記述の実施例がどのようにこれらの問題を克服するかを示す。
【００３７】
＜VBRビデオトラフィック特性＞−デジタルネットワークを介するリアルタイムビデオ伝送のためにQoSを設けることは、圧縮されたデジタルビデオトラフィックのVBR特性のためとりわけ困難である。ビデオ圧縮コーデック（例えばMPEG,H.263,H.261）は一時的圧縮技術を使用する。この圧縮技術では圧縮率がフレーム毎に変化し、またこの圧縮率はシーンの周期的スナップショットからの連続フレームにわたる変化または運動に依存する。そのため、高ピークバーストレートと、一般的に高い、しかし可変のピーク・ツー・平均レシオが生じる。この特性は、リソース利用率を効率的にすることをさらに困難にし、音声の場合のような固定ビットレートの場合よりも予約を厳密にする。
【００３８】
所要のリソース予約を正確に評価しないと、過度に多くのリソースが予約されることとなり、このことは利用率を低下させ、サービスのコストを上昇させる。あるいはリソースの予約が不十分であると、このことは損失と遅延を増大させる。両方の場合ともサービス品質を低下させる。高品質のマルチメディアサービスを最小可能コストで提供することは、セッションベースでのビデオ伝送に対して必要なリソースを正確かつ効率的に予測する方法を必要とする。
【００３９】
＜DOCSISサービスフロースペックパラメータ＞−以下のパラグラフはDOCSIS QoSパラメータと、デジタルビデオを伝送するためのIETFフロースペックパラメータとの関係を示す。フロースペックをDOCSISパラメータにマッピングすることはパケットケーブルマルチメディア仕様(PKT-SP-MM-I01-030627,2003年6月27日)に規定されている。DOCSISサービスフローQoSパラメータはビデオ伝送に適用可能であり、DOCSISリアルタイムポーリングサービス（rtPS)をアップストリームで使用し、最小リザーブレートと最大持続レートの組み合わせをアップストリームとダウンストリームの両方で使用する。リアルタイムポーリングサービスは、デジタルビデオのようなバースト状のVBRトラフィックに対して良好に動作する。なぜならこのサービスはケーブルモデムに競合のないことと、適時の要求機会を提供し、モデム（ここではネットワークエンドポイントを意味する）がデータを伝送しなければならなくなるまでアップストリームバンド幅をアロケートする必要がないからである。
【００４０】
最初の2つのQoSパラメータ、すなわち定格ポーリングインターバルと許容ポーリングジッタはアップストリームでだけ使用される。最後のパラメータ、すなわち最大ダウンストリーム待ち時間はダウンストリームでだけ使用される。残りのパラメータはアップストリームとダウンストリームの両方で使用される。
＜定格ポーリングインターバル＞−DOCSIS定格ポーリングインターバルは、タイムインターバルをμs単位で規定し、このインターバルでケーブルモデムは周期的ユニキャスト（競合なし）要求機会を受信する。VBRビデオトラフィックに対しては、定格ポーリングインターバルが十分に短く、モデムが要求機会を受信し、引き続きこれをバースト期間の間にそのピーク速度で伝送できることを承諾することが重要である。モデムが要求機会をピークバーストの間に十分に受信することを保証する唯一の手段は、フローがトラフィックをそのピーク速度で連続的に送信するかのようにポーリングインターバルを設定することである。ポーリングインターバルが平均レートしか許容しなければ、パケットが欠落するか、またはバースト期間の間に遅延が生じる。
【００４１】
例えば平均速度が256Kbps（32000バイト/秒）であり、平均パケットサイズが640バイト（平均で50パケット/秒）であるビデオソースを考察する。またバースト期間の間に、ピーク速度が768Kbps（150パケット/秒）になるとする。モデムがバースト期間の間に、毎秒50の要求機会しか許容しなければ、モデムは要求機会を十分に高速には受信しないこととなり、パケット損失が発生する。ピークバースト中のパケット損失を最小にするために、モデムは毎秒150の要求機会を受信しなければならない。
【００４２】
サービスフローがデータを比較的に低い速度で送信する非バースト期間中に、未使用の要求機会が浪費されることは事実である。しかしスケジューリングと、CMTSによる要求機会の伝送にダウンストリームで使用されるリソースの総量は、アップストリームで伝送されるデータの総量に比べれば僅かのものであり、競合要求を使用するためにモデムが必要とする総時間もさほどでない（指数的バックオフとコリージョンの可能性のため）。DOCSISリアルタイムポーリングサービスはこのことを勘案して設計されており、ビデオのようなバースト状のVBRリアルタイムトラフィックに対して理想的である理由である。
【００４３】
ポーリングインターバルは、rtPSに対するRSpecの予約レートRから導出され、予約レートRは典型的にはピーク速度pに等しいから、Rとｐの両者はバケットレートｒより大きい。このことは、サービス保証のためのこれらパラメータのIETF使用法と一致する。
【００４４】
＜許容ポーリングジッタ＞−DOCSIS許容ポーリングジッタパラメータは総時間をμsで規定し、リアルタイムポーリングに対するユニキャスト要求機会は遅延される。リアルタイムビデオセッションに対してこの値は比較的小さくなければならない。PCMMはデフォルトで800μsを規定し、CMTSにIETFRSPECのスラックタームSパラメータによって伝達される。
【００４５】
＜最大持続トラフィックレート＞−DOCSIS最大持続トラフィックパラメータは時間についての最大持続可能速度（すなわち平均速度）を、DOCSISMAC層データグラムの毎秒ビットで規定し、全てのMAC層ヘッダとCRCオーバヘッドを含む。DOCSISではアップストリームオーバヘッドが僅かに大きくなる。これはヘッダがアップストリームで拡張されるためである。VBRビデオトラフィックに対しては最大維持トラフィックレートを、MAC層オーバヘッドを考慮した後のビデオ最大維持レートに等しくすべきである。
【００４６】
＜最大トラフィックバースト＞−DOCSIS最大トラフィックバーストパラメータは、MAC層での最大バーストサイズをバイトで規定し、フローはそのピーク速度で伝送することができる。VBRビデオトラフィックに対して最大トラフィックバーストは、フローがそのピーク速度でバーストできるように設定されることが重要である。最大トラフィックバーストは、MAC層オーバヘッドを考慮した後のIETFトークンバケット深さbに等しい。トラフィックバーストがDOCSISで規定された1522バイトの最小値を下回ってはならないという付加的要求が存在する。
【００４７】
＜最小予約トラフィックレート＞−DOCSIS最小予約トラフィックレートは、フローの受信を保証する最小速度を規定し、MAC層オーバヘッドを考慮した後のIETFRSPECの予約レートRに非常に近似する。しかしPCMMの目的のために、RSVPフロースペックからDOCSISへの変換は、TSpecバケットレートrパラメータの使用を特定する。この変換はVBRビデオトラフィックに対して良好に動作する。なぜならRSpec予約率レートRは典型的にはTSpecバケットレートrと同じ（またはそれより大きい）だからである。このことはいわば、DOCSISMAC層では、予約がビデオセッションの平均速度を使用して行われることを意味する。試験の結果、SDPメディア属性で公示されたようなバンド幅を使用する最小予約トラフィックレートは、アップストリームでは良好に動作するが、ダウンストリームがかなりのパケット損失を受け、いくつかのビットレートではビデオ品質にかなり影響することが示された。前記の実施例はある程度の選択可能なパーセンテージの増加をバンド幅にもたらし、このパケット損失を克服する。
【００４８】
＜仮定的最小予約レートパケットサイズ＞−DOCSIS仮定的最小予約レートパケットサイズはIETF TSpec最小ポリシードユニット（PolicedUnit）mに非常に近似する。IETFパラメータと同様に、これはパケット毎のオーバヘッドを評価するのに使用される。サービスフローがこのサイズより小さいパケットを送信する場合、このパケットは予約レートを維持する目的のために、このサイズであるとしてカウントされる。パケットサイズに大きな変化が存在するVBRビデオトラフィックに対して、我々の実現は設定された固定のパケットサイズパラメータを使用する。DOCSISはこのパラメータをアップストリームサービスフローとダウンストリームサービスフローの両方に対して規定するが、PCMMはこれをダウンストリームに対してだけ規定することに注意されたい。このパラメータに対してDOCSISのデフォルトは規定されておらず、これはCMTS実現に依存する。
【００４９】
＜最大ダウンストリームレイテンシー＞−DOCSIS最大ダウンストリームレイテンシーパラメータは、パケットがCMTSネットワークインタフェースで受信され、HFCでのダウンストリームで伝送されるまでに受ける最大待ち時間を規定する（μsで）。このパラメータは、ダウンストリーム最小予約レートを有するフローにだけ適用され、このフローはこのレートを超過しない。PCMMに対してこのパラメータは、RSpecスラックタームSから設定される。
【００５０】
＜SDPビデオバンド幅のRSVPフロースペックへのマッピング＞−SDPがバンド幅メディア属性パラメータを含んでいなければ、全てのフロースペックパラメータが予め形成されたデフォルトを使用して選択される。そうでなければ、アプリケーションマネージャ110がSDPバンド幅メディア属性を入力として使用して、SDPをフロースペックパラメータにマッピングする。RSVPフロースペックパラメータの選択に影響する他のセッティングがこのセッションで構成され、記述される。一般的に、アプリケーションマネージャが使用する以下のパラメータのほとんどは、各方向（すなわちダウンストリームとアップストリーム）に対して形成される。
【００５１】
遅延（ms）−これはビデオに対する最大の最悪待ち行列遅延であり、最大バーストサイズに相当する（フローがそのピーク速度でバーストする総時間）。100msの初期デフォルト値が提案されている。
【００５２】
＜バンド幅調整（浮動小数点乗数）＞−これは補正係数であり、ビデオバンド幅を過小評価したクライアントに対してより大きなバンド幅を予約するために、または他のインタオペラビリティの問題を解決するために要求されるバンド幅を得るため、オリジナルのSDPと乗算される。アップストリームに対して1.0の初期デフォルト値が、ダウンストリームに対しては1.125が提案されている。初期検査の際に、すべての速度において512Kbpsを下回り、許容可能なビデオ品質を得るためにはダウンストリームで付加的なバンド幅が必要であることが観察された。これは大部分が過度のパケット損失とパケット遅延のためである。
【００５３】
＜レートファクタ（浮動小数点乗数）＞−これは最大持続スループット（バンド幅）を前提にしてピークと予約レートを計算するのに使用される。レートファクタに対する初期デフォルト値は4.0である。
【００５４】
＜最小パケットサイズ（バイト）＞−これは最小ポリシードユニット、およびパケットサイズを必要とする他の計算に使用される評価IPパケットサイズである。最小パケットサイズに対する（控えめな）初期デフォルト値は640である。
【００５５】
＜最大パケットサイズ（バイト）＞−これはIETF TSpecに適合するのに予想される最大IPパケットサイズである。最大パケットサイズに対する初期デフォルト値は1500である。
【００５６】
＜スラックターム（マイクロセカンド）＞−これはIETF RSpecのスラックタームSに使用される値である。PCMMに対してこれは、アップストリームではDOCSISアップストリーム許容ポーリングジッタに、ダウンストリームではDOCSISダウンストリームレイテンシーに相当する。スラックタームに対する初期デフォルト値は800μsであり、これはPCMMでのデフォルト値である。
【００５７】
＜レートリミット（毎秒バイト）＞−これは予約レートRとピークレートpでの上限であり、このパラメータは毎秒バイトで特定される。レートリミットに対する初期デフォルト値はアップストリームに対して96000、ダウンストリームに対して0である（値0は制限のないことを意味する）。
【００５８】
以下のパラメータはアップストリームに対してだけ規定される。
【００５９】
＜ポールインターバルリミット（μs）＞−これはCMTSからの要求に対する最小ポーリングインターバルである。ポーリングインターバルリミットに対する初期デフォルト値は6000μsである（値0は制限のないことを意味する）。
【００６０】
＜ポールインターバルセット＞は、CMTSで許容可能なポーリングインターバルのリストである。以下の記述を参照。提案された初期デフォルトセットは空である。
【００６１】
以下は、PCMM仕様からの関連するTSpecパラメータである。
【００６２】
＜バケット深さ（ｂ）＞−TSpecトークンバケットレートと組み合わされたTSpecトークンバケット深さは、フローの（ピークレートでの）最大バーストサイズを制限し、同様に、フローが被る最大の最悪待ち行列遅延を制限する。このようにして最大の最悪待ち行列遅延とフローのピークレートを考慮しなければならない。
【００６３】
TSpecバケット深さbは次式によりバイトで得られる：
b=(遅延*p)/1000
ここで遅延は構成された最大待ち行列遅延(ms)であり、pはTSpecピークレート（毎秒バイト）である。
例:
遅延＝100ms
p=32000
b=(100*32000)/1000=3200
【００６４】
＜バケットレート(r)＞−TSpecトークンバケットレートは、IPフローが適合する、時間についての平均レートを規定する。毎秒バイトにおけるTSpecバケットレートrは：
r=(バンド幅*バンド幅調整)/8
ここでバンド幅は、SDPからの公示バンド幅（毎秒バイト）であり、バンド幅調整は設定された調整乗数である。
例:
バンド幅=512000
バンド幅調整=1.0
r=512000*1.0/8=64000
【００６５】
＜最大データグラムサイズ(M)＞−TSpec最大データグラムサイズM(バイト）は、形成された最大パケットサイズに対して設定される。
【００６６】
＜最小ポリシードユニット(m)＞−TSpec最小ポリシードユニットm(バイト）は、形成された最小パケットサイズに対して設定される。
【００６７】
＜ピークレート(p)＞−TSpecピークレートは、フローがネットワークへデータをバーストするのに予想される最大レートである。TSpecピークレート（毎秒バイト）は常にRSpec予約レートに等しい。このステートメントは、DOSISrtPSポーリングインターバルに対して使用する予約レートRの間接的結果である。ポーリングインターバルはピークレートを使用して設定しなければならず、このことは事実上、ピークレートは予約レートに等しくなければならないことを意味する。
【００６８】
以下は、PCMM仕様からの関連するRSpecパラメータである。
【００６９】
＜予約レート(R)＞−RSpec予約レートは、フローのトラフィックがTSpecに準拠する場合に、このフローに与えられた保証レートである。PCMMでは、予約レートがDOCSIS定格ポーリングインターバルを決定するのに使用される。この実施例では、予約レートの微分が構成された制限によりコントロールされる。このことは、CMTSとポリシーサーバ/アプリケーションマネージャとの間の相互運用性問題を解決するのに必要である。具体的に言えば、予約レートRパラメータに対する最大値は厳しく制限され（レートリミット）、導出されたDOCSISアップストリーム定格ポーリングインターバルも同様に制限される（ポールインターバルリミット）。
【００７０】
毎秒バイトでのRSpec予約レートRは：
R=r*レートファクタ レートリミット=0
R=min(r*レートファクタ、レートリミット) レートリミット>0
ここでrは、TSpecトークンバケットレート、レートファクタは設定されたレート乗数、レートリミットは予約レートパラメータに設定された上限である。レートリミットがゼロであれば、予約レートに上限はない。
【００７１】
アップストリームでは、予約レートから導出される定格ポーリングインターバルを設定するのに2つのやり方がある：すなわち、ポールインターバルリミットの設定を使用してポールインターバルにリミットを設定するか、またはインターバルの所定のセットにおいて、ポールインターバルセットの設定によりポーリングインターバルを許容するのである。ポールインターバルセットは、CMTSでサポートされる許容可能な定格ポーリングインターバルのリストである。このリストが空でなければ、第2の方法が使用され、それ以外の場合第1の方法が使用される。
【００７２】
＜第1の方法：ポールインターバルリミットを使用＞−アップストリームには、予約レートR（バイト/秒）により割られた最小ポリシードユニットm（バイト）が、設定されたポールインターバルリミット(μs)より小さくてなってはならないとう付加的要求が存在する。言い替えると以下の不等式は、設定されたポールインターバルリミット>0である場合、常に真でなければならない。
【００７３】
m/R*106≧ポールインターバルリミット
アップストリームに対して、毎秒バイトでの予約レートRは：
R=Rに対する上記等式と同じ ポールインターバルリミット=0
R=min(r*レートファクタ、m*106/ポールインターバルリミット)
ポールインターバルリミット>0
例（レートおよびポールインターバルでのリミット）：
r=64000
m=640
レートファクタ=4.0
レートリミット=96000
ポールインターバルリミット=10000
R=min(64000*4,0,96000) ポールインターバルリミット=0
=min(256000,96000)
R=min(96000,640*106/10000) ポールインターバルリミット>0=10000
=min(96000,80000)
=80000
【００７４】
＜第2の方法：ポールインターバルセットを使用＞−ポールインターバルセットが空でなければ、導出された定格ポーリングインターバルを、設定値(μs)のセットから選択しなければならない。この方法を使用する場合、レートリミットとポールインターバルリミットに意味はない。
【００７５】
Rを選択のためのアルゴリズム：
１．R(R1....Rn)の可能値を、mと設定されたポーリングインターバルのセットI1〜Inとに基づいて計算する。
一般的には、R=(m*106)/定格ポーリングインターバル
Ri=(m*106)/Ii すべてのi「1....n」に対して
【００７６】
２．上記(R1....Rn)のRに対する値から、r*レートファクタに最も近く、これを上回らない値を1つ選択する。
例（ポールインターンバルセット）：
r=12000
m=640
レートファクタ=4.0
ポールインターバルセット={10000,20000,30000}
R1=(640*106)/10000=64000
R2=(640*106)/20000=32000
R3=(640*106)/30000=21333.3333....
r*レートファクタ=48000
R=32000
【００７７】
＜スラックターム(S)＞−スラックターム(μs)は、形成されたスラックタームパラメータから設定される。
【００７８】
［オーディオSDP翻訳］
以下のパラグラフは、SDPフィールドからPCMMデータへの、デジタルオーディオトラフィックのための翻訳の詳細を示す。この記述はビデオトラフィックに対する記述を補足するものである。ネットワークエンドポイントにあるオーディオコーデックは、インターパケット到着時間と同じように、オーディオデータに対してフロースペックパラメータを決定する。パケットケーブルコーデック仕様は3つのインターパケット到着時間(10,20,30ms)を規定する。PCMMオーディオ/ビデオコーデック仕様(PKT-SP-CODEC-105-040113)はまた、各フロースペックパラメータをすべてのオーディオコーデックに対し、各3つのパケット時間毎に規定する。サポートされるオーディオコーデックは次のものを含む：
−G.729E
−G.729A
−G.728
−G.726.40
−G.726.32
−G.726.24
−G.726.14
−G.711（PCMエンコーディング）a規則
−G.711（PCMエンコーディング）μ規則
【００７９】
SIP交換にあるネットワークエンドポイントがオーディオコーデックをSDP(セッション記述プロトコル)を使用して特定するならば、オプションのp時間パケット化タイムメディア属性も使用しなければならない。
【００８０】
SIP/SDPセッションによるオーディオコーデックの使用のために正しいフロースペックパラメータを検出するに際し、2つの問題が存在する。第1の問題は、パケット時間（すなわちp時間）SDPメディア属性が最適であり、従ってすべてのネットワークエンドポイントにより使用されないことである。パケット時間が未知であれば、システムは3つのパケット時間10,20,または30msのすべてで動作するフロースペックパラメータを選択することができる。この方法は常に動作するが、常に効率的なリソース予約を提供するものではない。最大パケットサイズと組み合わされた最小パケットインターバルがパケットサイズとパケットレートのすべての組み合わせに適応するため使用される。パケット時間が未知の場合、システムは設定されたデフォルトパケット時間を使用することもできる。パケットケーブルデフォルトパケット時間は20msに規定されている。このデフォルト値または設定されたいずれのデフォルト値も、ネットワークエンドポイントの動作が使用時に既知であれば、使用することができる。
【００８１】
正しいフロースペックパラメータを検出する際の第2の問題は、一般的に、マルチプルコーデックが使用される場合、どのコーデックがSIPネットワークエンドポイントを使用しようとするかを知ることができないことである。
【００８２】
SIPネットワークエンドポイントがマルチプルオーディオコーデックを有しており、同じメディア形式（この場合はオーディオ）に対するマルチプルコーデックを含む場合、2つのネットワークエンドポイント間で取り決められた使用可能なコーデックのうちのいずれかが使用される。両方のエンドポイントは取り決めたコーデックのいずれかの受信を準備しなければならず、他方のエンドポイントに、RTP（リアルタイムプロトコル）メディアストリームがスタートするまで、どのコーデックが使用されているかを知らせるシグナリングは存在しない。
【００８３】
この実施例は、以下の3つの技術の組み合わせを使用し、複数の特定コーデックのうち、どのコーデックに基づいてリソース予約決定が行われるかを検出する。
【００８４】
＜第1の技術＞−SDPフィールドが同じメディア形式に対してマルチプルコーデックを規定する場合、アプリケーションマネージャは最初に、ネットワークリソースの最大量を使用するコーデックに基づいてリソース予約決定する。このことにより、十分なリソースが予約され、取り決められたいずれのコーデックも適切に動作することが保証される。
【００８５】
＜第2の技術＞−この技術は、各メディア形式に対するSDPでのコーデック順序を、特定のコーデックの選択のために使用する。SDP仕様は、SDPでのコーデック順序がネットワークエンドポイントのコーデック優先度を決定すべきであるとアナウンスしている。ほとんどの場合、リストの第1コーデックがネットワークエンドポイントにより使用される。ネットワークエンドポイントがこの標準規格に準拠することが既知であれば、この構成によりQoS予約はより厳密となり、その結果、サービスのコストが低下する。
【００８６】
＜第3の技術＞−この技術は、DOCSIS QoS MIB(Patrick,M., Murwin,W. ,"Data Over Cable System InterfaceSpecificationQuality of Service Management Information Base(DOCSIS-QOSMIB)",Internet-Draft(2004年4月満了), http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-qos-mib-09.txt,2003年10月27日)をCMTSで使用し、ネットワークエンドポイントが送信しているオーディオデータパケットサイズを決定する。オーディオトラフィックはCBR（固定ビットレート）であるから、同じパケットサイズがすべてのパケットに対して使用される。DOCS-QOS MIBを検査することで、DOCSISサービスフローによりオーディオデータの搬送に使用されるパケット数およびバイト、並びにこのフローがアクティブである総時間が得られる。総バイト数を、このバイトを送信するのに使用されるパケット数により割り算すると、パケットサイズが得られる。速度は、転送される総バイト数を、フローがアクティブである総時間により割り算すると得られる。
【００８７】
この実施例は、第1の技術または第2の技術を使用して初期リソース予約を行う。データ伝送の数秒後に、アプリケーションマネージャは正確なパケットサイズと速度を決定し、第3の技術を使用してリソース予約を調整し、これによりオーディオコーデックが必要とするものをより正確に表す。ダイナミックコーデック切り替えが既知の実現性であれば、この実施例は、使用可能なコーデックのいずれかに対して常に動作する第1の技術だけを使用する。
【００８８】
さらなる側面、変形、および実施例は請求項の範囲内にある。
【図面の簡単な説明】
【００８９】
【図１】図1は、2つのネットワークエンドポイント間でVoIPリンクを確立するための従来のアーキテクチャを示す図である。
【図２】図2は、実施例のネットワークアーキテクチャを示す図である。
【図３】図3は、同じネットワークドメインでの2つのネットワークエンドポイントに対する単純なコール手続きを示す図である。
【図４】図4は、異なるネットワークドメインでの2つのネットワークエンドポイントに対する単純なコール手続きを示す図である。
【技術分野】
【０００１】
本発明は一般的に、ポリシー指向のネットワークリソース管理に関する。
【背景技術】
【０００２】
［技術背景］
一般的にポリシーサーバは、ルールの集合、すなわちポリシーに従いネットワークリソースを管理する。いくつかのポリシーサーバは単純に、ネットワークリソースを未分化データに対してネットワークルーティングエレメント間で、またはスイッチングエレメント間（例えばルータAからルータBへ）で切り分けるが、本明細書のポリシーサーバはネットワークリソースをアプリケーションの必要性を満たすために管理する。例えばボイス・オーバー・アイピー（VoIP)アプリケーションでは、2つのネットワークエンドポイントが他方とネットワークを介してVoIPコールを確立しようと希望する。ネットワークエンドポイントはネットワークリソースをポリシーサーバからVoIPコールのために要求する。
【０００３】
図1はこのVoIPの1つの実現例を示す。第1ネットワークエンドポイント10は、第2ネットワークエンドポイント12へのVoIPコールを、アクセスネットワーク14を介して確立しようと希望する。第1エンドポイント10はセッション属性を、アプリケーションサーバへのそのセッションセットアップ要求の中で識別する。アプリケーションサーバ18はVoIPアプリケーションを含んでおり、これがエンドポイント間のセッションまたはコールの整合およびセットアップを行う。アプリケーションサーバ18は、VoIPセッションに関連するリソースに対する要求をポリシーサーバ20に、パケットケーブルマルチメディア（PCMM）プロトコルを使用して中継する(PKT-TR-MM-ARCH-V01-030627, V01,2003年6月27日;そして,PKT-SP-MM-I01-030627,2003年6月27日)。アプリケーションサーバ18はアプリケーションマネージャ22と同意語であり、このアプリケーションマネージャはこのセッションに対するQoSの予約および管理に必要な機能性をポリシーサーバを介して提供する。ポリシーサーバは反対にネットワークリソースをコントロールし、適切な処置がこのコールまたはセッションに関連するすべてのメディアストリームに適用されることを保証する。
【０００４】
アプリケーションサーバ18に配置されたアプリケーションマネージャ22が機能性を有することはアプリケーションサーバ18の構成を複雑にする。なぜならいくつかのアプリケーションサーバはアプリケーションマネージャを必要としないから、アプリケーションマネージャは不要なコストと、それらの設置のための複雑性の原因となる。
【発明の開示】
【課題を解決するための手段】
【０００５】
［発明の概要］
1つの側面は、複数のネットワークリソースをネットワークエンドポイント間でアプリケーションマネージャに対するセッション開始要求を使用して、ネットワークエンドポイント間でリソースを予約するために割り当てる方法である。アプリケーションマネージャは論理的かつ物理的に（または論理的にだけ）、ネットワークエンドポイントに関連するアプリケーションサーバから分離されている。この方法はさらに、アプリケーションマネージャからのPCMMメッセージをポリシーサーバに、セッション開始要求の結果として提供することを含む。ここにおいてPCMMメッセージは少なくともセッション開始要求に埋め込まれたいくつかの情報を含む。PCMM以外の適切なプロトコルも、アプリケーションマネージャとポリシーサーバとの間でこの情報を伝送するのに使用することができる。この方法はさらに、ポリシーサーバを介して、ネットワークエンドポイントを接続する経路を形成するために複数のネットワークリソースを選択することを含む。ここにおいてポリシーサーバは複数のネットワークリソースをPCMMメッセージに基づいて選択する。
【０００６】
セッション開始要求はセッション開始プロトコル(SIP、J.Rosenberg,et.al.,"SIP:Session Initiation Protocol",RFC3261,2002年6月を参照)を介して、SIPメッセージにあるセッション記述プロトコル(SDP、Handley,M.andV.Jacobson,"SDP:Session Description Protocol",RFC2327,1998年4月を参照)フィールドを使用し、ネットワークでのリソースの必要なQoS予約を実行するために通信することができる。QoS情報はセッション開始要求内のセッション記述プロトコルフィールドに含むことができる。アプリケーションマネージャはネットワークエンドポイントの1つとアプリケーションサーバとの間に挿入配置することができる。アプリケーションマネージャは、セッション開始要求をネットワークエンドポイントとアプリケーションサーバとの間で透明に中継し、その際にネットワークエンドポイントまたはアプリケーションサーバの機能的変形を必要としない。
【０００７】
1つの実施例でこの方法は、セッション開始要求からのハイレベルQoS情報を基礎となるネットワーク技術の理解と結び付け、PCMMメッセージで使用するために詳細なQoS情報を形成する。別の実施例でこの方法はQoS情報を、SDPまたはRSVPフロースペック(IETFドキュメント、Wroclawski,J.,"The Use of RSVP with IETF Integrated Services",RFC2210,1997年9月.Wroclawski,J.,"Specificationof the Controlled-Load Network Element Service",RFC2211,1997年9月. Shenker,S.,Partridge,C.,Guerin,R., "Specification of Guaranteed Qualityof Service", RFC2212,1997年9月に定義されているように)を介してXMLメッセージに埋め込み、XMLメッセージを使用して、セッション開始要求をアプリケーションサーバと通信する。このアプリケーションサーバは引き続き、QoS情報をアプリケーションマネージャにXMLメッセージで伝送する。この方法は択一的にHTTPを使用してXMLメッセージをアプリケーションサーバと通信し、このアプリケーションサーバは引き続きQoS情報をアプリケーションマネージャに伝送する。
【０００８】
実施例でアプリケーションサーバは、アプリケーションマネージャと通信するためにユニークなセッション識別子を使用することによりステートレスな状態に留まる。そしてセッションとリソースとの関連は、分離されたアプリケーションマネージャで維持される。セッション識別子は、エンドポイントとアプリケーションサーバとの間のSIPシグナリングメッセージから形成される。
【０００９】
実施例でこの方法は、SDPメディア属性に基づくRSVPフロースペックパラメータの選択を含み、フロースペックパラメータ選択動作を、PCMMフレームワークでのリソース予約のために実行する能力を提供する。この方法はさらに、CMTSでのDOCSISサービスフローQoSパラメータとのインタオペラビリティを保証し、種々異なるCMTSベンダー実現にわたる、選択されたフロースペックパラメータの正規化によりQoSを提供する。この方法はまた、SDPメディア属性の種々のオプションフィーチャを実現するネットワークエンドポイント間のインタオペラビリティも保証する。
【００１０】
実施例でこの方法は、各設定に対するデフォルト値に加えて、方向（アップストリームとダウンストリーム）毎にコンフィギュラブルな設定を提供し、フロースペックパラメータ選択でこの設定を、各設定に対するデフォルト値に従って使用する。コンフィギュラブルな設定および関連のデフォルト値は次のものを含む：
遅延、100ms（ダウンストリームとアップストリーム）
バンド幅調整、1.125（ダウンストリーム）
バンド幅調整、1.0（アップストリーム）
レートファクタ、4.0（ダウンストリームとアップストリーム）
最小パケットサイズ、640（ダウンストリームとアップストリーム）
最大パケットサイズ、1500（ダウンストリームとアップストリーム）
スラックターム、800（ダウンストリームとアップストリーム）
レートリミット、96000（アップストリーム）
レートリミット、0（ダウンストリーム）
ポールインターバル限界、6000μs（アップストリーム）
ポールインターバルセット、空（アップストリーム）
"ptime"メディア属性（パケット化時間）がSDPに設定されていなければ、この方法は、パケットケーブルオーディオ/ビデオコーデック仕様により指定される全てのパケット化時間に対して十分なリソースがリザーブされるようにRSVPフロースペックパラメータを選択する。
【００１１】
マルチプルコーデックがSDPフィールドで取り決められていれば、この方法は、パケットケーブルオーディオ/ビデオコーデック仕様により指定される全てのパケット化時間に対して十分なリソースが予約されるようにRSVPフロースペックパラメータを選択する。
【００１２】
実施例でこの方法は、ptimeメディア属性が未知の場合、正確にptime（パケット化時間）を決定するためにDOCSIS QoS MIBを使用し、引き続きptimeメディア属性が決定されると、予約されたリソースを変更する。別の実施例でこの方法は、使用中の特定のコーデックの決定のためにマルチプロコーデックが取り決められる場合、正確にptime（パケット化時間）を決定するためにDOCSIS QoS MIBを使用し、引き続き特定のコーデックが決定されると、予約されたリソースを変更する。
【００１３】
実施例ではアプリケーションマネージャが、（レジスタ）REGISTERメッセージから、一方または両方のエンドポイントのコンタクトIPアドレスとポート番号を学習し、これによりアプリケーションマネージャは招待（INVITE）メッセージをエンドポイントに転送することができる。別の実施例でアプリケーションマネージャはアプリケーションサーバを問い合わせ、一方または両方のエンドポイントのコンタクトIPアドレスおよびポート番号を獲得し、これによりアプリケーションマネージャはINVITEメッセージをエンドポイントに転送することができる。
【００１４】
別の側面では、複数のネットワークリソースをネットワークエンドポイント間で割り当てるためのシステムがアプリケーションマネージャを有し、このアプリケーションマネージャは、(i)ネットワークエンドポイント間での通信を、ネットワークリソースのセットを通して開始するセッション開始要求を受信し、(ii)セッション開始要求に埋め込まれた少なくとも複数の情報を含むPCMMメッセージを発生する。ネットワークエンドポイント間の通信はアプリケーションサーバに常駐するアプリケーションを使用する。このシステムはさらに、PCMMメッセージを受信し、ネットワークエンドポイントを接続する経路を形成するために複数のネットワークリソースを選択するポリシーサーバを有する。ここにおいてポリシーサーバは複数のネットワークリソースをPCMMメッセージに基づいて選択する。
【発明を実施するための最良の形態】
【００１５】
［詳細な説明］
説明される実施例はネットワークアーキテクチャであり、このネットワークアーキテクチャはアプリケーションサーバ、アプリケーションマネージャ、およびアプリケーション特有のポリシーをネットワークリソース割り当てのために実現するポリソーサーバを使用する。この実施例はアプリケーションマネージャをアプリケーションサーバから抽出し、従ってアプリケーションサーバは複雑なネットワーク固有の信号インタフェース、例えばPCMMを、ネットワークを介する入場コントロールまたはリソース要求を実行するために有する必要がない。この実施例は、高品質ビデオ遠隔会議セッションを実施する2つのエンドポイントを記述するが、この概念はまた他のアプリケーション、例えばビデオストリーミング、ボイスオーバインターネットプロトコル(VoIP)通信、およびネットワークゲームにも適用することができる。アプリケーションマネージャをアプリケーションサーバから抽出することは、アプリケーションマネージャとアプリケーションサーバとの間に新たな信号インタフェースを指定する。このインタフェースはPCMMよりも格段に単純なインタフェースであり、SIPシグナリングまたは別のプロトコル、例えばeXtensibMarkupLanguage(XML)、リアルタイムストリーミングプロトコル(RTSP)またはハイパーテキスト伝送プロトコル(HTTP)を、アプリケーションサーバとアプリケーションマネージャとの間の通信に使用することができる。抽出されたアプリケーションマネージャはこのような格段に単純な言語を解釈し、より複雑でネットワーク固有の言語に翻訳することができ、これによりネットワークリソースの予約と管理のためにポリシーサーバと通信することができる。
【００１６】
CableLabsパケットケーブルマルチメディア(PCMM)プロトコル仕様(PKT-TR-MM-ARCH-V01-030627,V01,2003年6月27日)は、アプリケーションサーバに埋め込まれたアプリケーションマネージャ機能を定義する。アプリケーションマネージャ機能はポリシーサーバとの通信を行い、ポリシー決定、例えば入場コントロールおよびサービス品質(QoS)を、PCMMシグナリングインタフェースにより実現する。アプリケーションマネージャをアプリケーション自体から(すなわちアプリケーションサーバから)抽出することにより、この実施例ではアプリケーションサーバがPCMMアーキテクチャおよびその関連のプロトコルについて知る必要がなくなる。従ってこの実施例では、アプリケーションサーバはPCMM環境に、より一般的に(すなわち抽出されたアプリケーションマネージャを介して)インタフェースすることができ、また(ゲートトークンに関する)状態を維持するためのタスクをアプリケーションマネージャに任せる。そしてアプリケーションマネージャはスタンドアローンとすることも、またはポリシーサーバに埋め込むこともでき、このことはサービスの引き渡しに関連するネットワークエレメントの数を最小にする。
【００１７】
図2は、ネットワークアーキテクチャの1つの実施例を示す。ここには、第1ネットワークエンドポイント100，第2ネットワークエンドポイント102，アクセスネットワーク104，アプリケーションサーバ106，ポリシーサーバ108およびアプリケーションマネージャ110が含まれる。この実施例は、ポリシーサーバ108とアプリケーションマネージャ110の周囲に破線ブロックを有しており、このことはこれら2つのコンポーネントの機能性が同じ物理的プラットフォームに存在することを意味する。しかし後で説明するように、アプリケーションマネージャ110は、ポリシーサーバ108とは空間的に別個の物理的プラットフォームに存在することもできる(すなわちスタンドアローン構成)。この実施例で第1ネットワークエンドポイント102はSIP交換を使用して、アクセスネットワーク106を介する第2ネットワークエンドポイント104へのビデオ遠隔会議セッションを要求する。このビデオ遠隔会議セッションは、アプリケーションサーバ106に常駐するビデオ遠隔会議アプリケーションを使用する。
【００１８】
アプリケーションマネージャ110はSIP信号経路112に配置されている。エンドポイント100，102間のSIP接続112とアプリケーションサーバ106が直接接続されて図2に示されているが、これは簡単にするためであり、エンドポイントからの全ての接続はアクセスネットワーク104を通ることを理解されたい。
【００１９】
各SIPセッションは2つのSIPエンドポイント間で3ウェイハンドシェークを以て開始する。セッションを開始するエンドポイント(発呼者)はまずINVITEメッセージを受信エンドポイント(被呼者)に送信する。被呼者は、発呼者へのOKメッセージを以て応答する。次に発呼者は、ACKメッセージを以て応答する。図2では、2つのSIPエンドポイントが第1ネットワークエンドポイント100と第2ネットワークエンドポイント102であり、ここで第1ネットワークエンドポイント100が発呼者、第2ネットワークエンドポイント102が被呼者である。アプリケーションサーバ106はこの実施例ではSIPプロクシサーバとして機能し、SIPメッセージを2つのエンドポイント100および102とやりとりする。
【００２０】
アプリケーションマネージャ110はSIP信号経路に配置されているが、アプリケーションマネージャ110はSIPハンドシェーク交換を透明に通過させる。従ってSIPエンドポイントまたはプロクシサーバ(アプリケーションマネージャ106)はSIP信号経路のアプリケーションマネージャ110を知覚しない。アプリケーションマネージャ110が、第1ネットワークエンドポイント100からの第1 SIP INVITEメッセージをアプリケーションサーバ106にパスすると、アプリケーションマネージャ110はセッション記述プロトコル(SDP)フィールドをINVITEメッセージから、第1ネットワークエンドポイント100についての情報のために抽出する。アプリケーションマネージャ110がOKメッセージをアプリケーションサーバ106から受信すると、アプリケーションマネージャはSDPフィールドをOKメッセージから、アプリケーションサーバについての情報のために抽出する。OKメッセージを第1ネットワークエンドポイント100に送信する前に、アプリケーションマネージャ110は、サービス品質（QoS）を第1ネットワークエンドポイント100に対してだけ動的に形成するか、または第1ネットワークエンドポイント100と第2ネットワークエンドポイント102の両方に対して動的に形成するかを決定する。この決定に基づき、アプリケーションマネージャはGateStメッセージを、PCMMリンク114を介してポリシーサーバ108に送信する。アプリケーションマネージャが、SIP交換中のSDPフィールドをセットゲートメッセージに対するパラメータにどのように翻訳するかについては、後でボイス通信およびビデオ通信の両者に対して説明する。
【００２１】
SDPにリストアップされた各メディア形式に対して、アプリケーションマネージャ110は2つのゲートをポリシーサーバで形成する。1つはアップストリーム方向にあり、もう1つはダウンストリーム方向にある。従ってこの実施例でのビデオ遠隔通信セッションに対しては、アプリケーションマネージャ110は4つのゲートをエンドポイント毎に形成する。1つのゲートはアップストリームオーディオに対するものであり、1つのゲートはアップストリームビデオに対するものであり、1つのゲートはダウンストリームオーディオに対するものであり、1つのゲートはダウンストリームビデオに対するものである。
【００２２】
アプリケーションマネージャ110は、QoSを形成すべきか否かを、INVITEメッセージまたはOKメッセージのViaヘッダを検査することにより決定する。Viaヘッダにあるエントリー数に基づいて、アプリケーションマネージャ110は第1ネットワークエンドポイント100と第2ネットワークエンドポイント102が共に同じアプルケーションマネージャを第1ホップとして使用しているか否かを決定することができる。マルチドメイン環境では、発呼者が1つのアプリケーションマネージャを第1ホップとして使用しており、被呼者が別のアプリケーションマネージャをその第1ホップとして使用していることがあり得る。このようなマルチドメインの場合、各アプリケーションマネージャは、当該のアプリケーションマネージャをその第1ホップのために使用するネットワークエンドポイントに対してだけQoSを形成する。INVITEメッセージおよびOKメッセージを相応するPCMMメッセージおよび関連するゲートに関連付けるために、アプリケーションマネージャはSIPメッセージ中のCallIDを使用する。この技術を使用することにより、分離されたアプリケーションマネージャはネットワークに透明に存在することができ、エンドポイントまたはアプリケーションサーバ機能への変更を必要としない（すなわち現在の構成またはこれらコンポーネントの機能実現に変化はない）。
【００２３】
いったんアプリケーションマネージャ110がエンドポイント間でダイアローグをセットアップし、QoSがこのエンドポイントに対して確立されると、エンドポイントの1つが、そのQoS要求を変更する別のINVITEメッセージを送信する。アプリケーションマネージャ110はこのような再INVITEメッセージを、前記ダイアローグに対して以前に形成されたゲートを変更することによって処理する。
【００２４】
ダイアローグを取り去るべき場合、取り下げを開始するエンドポイントはBYEメッセージを送信する。BYEメッセージが転送された後、アプリケーションマネージャ110は、このダイアローグに対して形成されたQoSを、PCMMゲート削除メッセージをポリシーサーバ108に送信することによってクリアする。アプリケーションマネージャ110は、どのゲートがダイアローグに対して形成されたかに関する情報を格納するためのデータベースを維持する。従ってアプリケーションマネージャは、ダイアローグが取り去られる場合にどのゲートを削除すべきかを識別することができる。
【００２５】
図3は、同じネットワークドメインにある2つのネットワークエンドポイントに対する単純なコールフローを示す図であり、図4は、異なるネットワークドメインにある2つのネットワークエンドポイントに対する単純なコールフローを示す図である。各図に対するコールフローは、2つのドメインにあるエンドポイント間でのSIP信号とPCMMメッセージに対するフローを示す。図4については、各ドメインは固有のアプリケーションマネージャ110とポリシーサーバ108を有し、中央プロクシサーバが2つのドメインを接続する。
【００２６】
別の実施例では、アプリケーションマネージャがQoSを、2フェーズアプローチを介して要求する。アプリケーションマネージャがINVITEメッセージを発呼者から受信すると、このアプリケーションマネージャは発呼者の要求を学習するだけでなく、GateStメッセージをポリシーサーバに送信する。このGateStメッセージはQoSを発呼者および/または被呼者に対して予約だけする。すなわち必要なゲートの委託はまだ行わない。コールのセットアップが進行し、アプリケーションマネージャが相応するOKメッセージを被呼者から受信すると、アプリケーションマネージャは（必要であれば）GateStメッセージを被呼者に対し、およびGateStメッセージを発呼者に対して送信する。この時にアプリケーションマネージャは発呼者と被呼者のゲートを、単に予約するというよりむしろ委託する。
【００２７】
この実施例はポリシーサーバでのゲートの良好なコントロールを提供する。言い替えると、ゲートの最初の予約まで、アプリケーションマネージャはPEP（ポリシーエンフォースメントポイント）上で貴重なリソースを消費しない。アプリケーションマネージャは、このアプリケーションマネージャがOKメッセージを受信し、この時点でセッション確立を完了するために被呼者を使用できる場合だけ、これらのリソースを委託する。
【００２８】
別の実施例では、アプリケーションマネージャは、エンドポイントから到来するREGISTRメッセージからコンタクト情報を学習する。このフィーチャにより、アプリケーションマネージャはエンドポイントのIPアドレスとポート番号を学習することができ、INVITEメッセージをエンドポイントに転送することができる。登録サーバがエンドポイントとのマルチホップを処理できない場合、この登録サーバはINVITEメッセージだけをアプリケーションマネージャに転送することになる。次にこのアプリケーションマネージャはこの情報を使用してINVITEメッセージを正しいエンドポイントに送出する。
【００２９】
別の実施例では、アプリケーションマネージャがコンタクト情報をアプリケーションサーバから、空のコンタクトヘッダを含むREGISTRメッセージにより問い合わせすることによって獲得する。このフィーチャにより、アプリケーションマネージャはエンドポイントのIPアドレスとポート番号を学習することができ、INVITEメッセージをエンドポイントに転送することができる。登録サーバがエンドポイントとのマルチホップを処理できない場合、この登録サーバはINVITEメッセージだけをアプリケーションマネージャに転送することになる。次にアプリケ―ションマネージャはアプリケーションサーバに問い合わせしてコンタクト情報を獲得し、INVITEメッセージを正しいエンドポイントに送出する。
【００３０】
前記の実施例は、エンドポイントと、SIPであるアプリケーションサーバとの間でセッションを開始することができるが、より簡単でよりフレキシブルなプロトコルをエンドポイントとアプリケーションサーバとの間の通信に使用することもできる。例えば1つの実施例では、XMLをエンドポイントに対するSIPの代わりに使用し、QoS情報と共に埋め込まれたセッションセットアップをアプリケーションサーバと通信する。別の実施例では、リアルタイムストリーミングプロトコル（RTSP)またはHTTPがセッション開始およびリソース要求のために使用される。QoS情報は埋め込むことができ、またはSDPまたはIETFRSVPフロースペックの形態とすることができる。
【００３１】
前記の実施例はSIPによりセッションを開始することができるが、アプリケーションサーバとアプリケーションマネージャとの間のインタフェースはSIPであり、他のより簡単なプロトコルもアプリケーションサーバとアプリケーションマネージャとの間の通信に対して使用することができる。例えば1つの実施例ではXMLをアプリケーションサーバに対して使用し、アプリケーションマネージャへのリソース要求を通信する。別の実施例では、リアルタイムストリーミングプロトコル（RTSP）またはHTTPがセッション開始およびリソース要求のために使用される。QoS情報は埋め込むことができ、またはSDPまたはIETFRSVPフロースペックの形態とすることができる。（IETFドキュメント、Wroclawski,J.,"The Use of RSVP with IETF Integrated Services",RFC2210,1997年9月.Wroclawski,J.,"Specificationof the Controlled-Load Network Element Service", RFC2211,1997年9月. Shenker,S., Partridge,C., Guerin,R., "Specification of Guaranteed Quality of Service", RFC2212,1997年9月に定義されているように）。
【００３２】
XMLを使用する場合、アプリケーションサーバはSDPフィールドをXMLメッセージに挿入してアプリケーションマネージャに送信する。このアプリケーションサーバは、SDPフィールドを、エンドポイントとの通信に使用されるSIPメッセージから抽出し、これをXMLメッセージに挿入してアプリケーションマネージャに送信する。次にアプリケーションマネージャは適切なPCMMメッセージへの必要な翻訳を実行する。さらにアプリケーションサーバはアプリケーションマネージャと、このセッションに対する文脈を、ユニークなセッション識別子によって通信する。このセッション識別子は、エンドポイントとアプリケーションサーバとの間のSIPシグナリングメッセージから形成することができる。エンドポイントとアプリケーションサーバとの間のメッセージ活動の結果として、アプリケーションサーバはアプリケーションマネージャとだけ通信すればよいから、アプリケーションサーバはこのプロセスの間にセッションIDを作成し、アプリケーションマネージャにメッセージを発行することができる。このことによりアプリケーションサーバは「ステートレス」状態に留まる。このアプリケーションサーバは、アプリケーションセッションおよびリソースマッピングの状態を維持する必要がなく、従ってアプリケーションサーバの実現と機能性が簡素化される。リソースを放棄すべき場合、アプリケーションサーバは、SIPシグナリングメッセージから作成されたセッション識別子を使用して、アプリケーションマネージャと通信する。このアプリケーションマネージャはセッションの状態とリソースの関連性を維持する。すなわち「ステートフル」状態である。
【００３３】
上記の実施例では、アプリケーションマネージャをポリシーサーバに埋め込むことができ、またはアプリケーションマネージャはスタンドアローンのプラットフォームに常駐することができる。両方の場合とも、アプリケーションマネージャは、SDPにあるQoS情報をより詳細なQoSに、SDPをアクセスネットワークの知識と結合することにより変換し、より詳細なQoS情報をポリシーサーバにPCMMメッセージを介して転送する。
【００３４】
［ビデオSDP翻訳］
以下のパラグラフは、SDPフィールドからPCMMデータへの、デジタルビデオトラフィックのための翻訳の詳細を示す。PCMMアーキテクチャはIETFRSVPフロースペックパラメータを使用して、ポリシーサーバとケーブルモデム端末システム（CMTS)との間でサービス品質（QoS)要求を通信する。以下のパラグラフは、PCMMで使用するのに適切にフロースペックパラメータを選択し、SDPパラメータに基づきSIPユーザエージェント（すなわちネットワークエンドポイント）に対して高品質ビデオ遠隔会議セッションを可能にするやり方を示す。
【００３５】
フロースペックパラメータを選択する際の3つの問題には次のものが含まれる：
１．SDP仕様は発展し続けており、多くのパラメータ（例えばメディア属性）がまだ確立されておらず、ほとんどがオプションである。全てのオプションメディア属性を含んでおらず、フロースペックパラメータ選択もオプションとなるSIP/SDP実現が存在する。
２．圧縮されたデジタルビデオトラフィックは可変ビットレート（VBR)であり、このことはパケットサイズが変化し、ランダムな間隔で到着することを意味する。
３．.DOCSISにより規定され、CMTSにより提供されるようなQoSは多くのオプションと、CMTS実現に依存するフィーチャを有する。DOCSISはデータオーバーケーブルサービスインターフェース仕様のセットを参照し、この仕様はどのようにデータをケーブルネットワークを介して標準仕様で伝送するかを規定する。例えばDOCSISRFIMACプロトコルは、どのようにケーブルモデムを、アクセスネットワークを介して接続するかを規定している。RFIは、DOCSISラジオ周波数インタフェース仕様であり、CMTSとCMネットワークエレメントとの間の物理層インタフェースおよびMACを規定する。このことは、１つのCMTSベンダーが特定のフィーチャを決定するが、他のベンダーは決定しないこと、またはフィーチャの実現を異なって決定することができることを意味する。CMTS、ケーブルモデム、および他の装置との間のインタオペラビリティの問題は、QoSを保証するためのオプションパラメータの選択プロセスをさらに複雑にする。
【００３６】
以下のパラグラフで記述の実施例がどのようにこれらの問題を克服するかを示す。
【００３７】
＜VBRビデオトラフィック特性＞−デジタルネットワークを介するリアルタイムビデオ伝送のためにQoSを設けることは、圧縮されたデジタルビデオトラフィックのVBR特性のためとりわけ困難である。ビデオ圧縮コーデック（例えばMPEG,H.263,H.261）は一時的圧縮技術を使用する。この圧縮技術では圧縮率がフレーム毎に変化し、またこの圧縮率はシーンの周期的スナップショットからの連続フレームにわたる変化または運動に依存する。そのため、高ピークバーストレートと、一般的に高い、しかし可変のピーク・ツー・平均レシオが生じる。この特性は、リソース利用率を効率的にすることをさらに困難にし、音声の場合のような固定ビットレートの場合よりも予約を厳密にする。
【００３８】
所要のリソース予約を正確に評価しないと、過度に多くのリソースが予約されることとなり、このことは利用率を低下させ、サービスのコストを上昇させる。あるいはリソースの予約が不十分であると、このことは損失と遅延を増大させる。両方の場合ともサービス品質を低下させる。高品質のマルチメディアサービスを最小可能コストで提供することは、セッションベースでのビデオ伝送に対して必要なリソースを正確かつ効率的に予測する方法を必要とする。
【００３９】
＜DOCSISサービスフロースペックパラメータ＞−以下のパラグラフはDOCSIS QoSパラメータと、デジタルビデオを伝送するためのIETFフロースペックパラメータとの関係を示す。フロースペックをDOCSISパラメータにマッピングすることはパケットケーブルマルチメディア仕様(PKT-SP-MM-I01-030627,2003年6月27日)に規定されている。DOCSISサービスフローQoSパラメータはビデオ伝送に適用可能であり、DOCSISリアルタイムポーリングサービス（rtPS)をアップストリームで使用し、最小リザーブレートと最大持続レートの組み合わせをアップストリームとダウンストリームの両方で使用する。リアルタイムポーリングサービスは、デジタルビデオのようなバースト状のVBRトラフィックに対して良好に動作する。なぜならこのサービスはケーブルモデムに競合のないことと、適時の要求機会を提供し、モデム（ここではネットワークエンドポイントを意味する）がデータを伝送しなければならなくなるまでアップストリームバンド幅をアロケートする必要がないからである。
【００４０】
最初の2つのQoSパラメータ、すなわち定格ポーリングインターバルと許容ポーリングジッタはアップストリームでだけ使用される。最後のパラメータ、すなわち最大ダウンストリーム待ち時間はダウンストリームでだけ使用される。残りのパラメータはアップストリームとダウンストリームの両方で使用される。
＜定格ポーリングインターバル＞−DOCSIS定格ポーリングインターバルは、タイムインターバルをμs単位で規定し、このインターバルでケーブルモデムは周期的ユニキャスト（競合なし）要求機会を受信する。VBRビデオトラフィックに対しては、定格ポーリングインターバルが十分に短く、モデムが要求機会を受信し、引き続きこれをバースト期間の間にそのピーク速度で伝送できることを承諾することが重要である。モデムが要求機会をピークバーストの間に十分に受信することを保証する唯一の手段は、フローがトラフィックをそのピーク速度で連続的に送信するかのようにポーリングインターバルを設定することである。ポーリングインターバルが平均レートしか許容しなければ、パケットが欠落するか、またはバースト期間の間に遅延が生じる。
【００４１】
例えば平均速度が256Kbps（32000バイト/秒）であり、平均パケットサイズが640バイト（平均で50パケット/秒）であるビデオソースを考察する。またバースト期間の間に、ピーク速度が768Kbps（150パケット/秒）になるとする。モデムがバースト期間の間に、毎秒50の要求機会しか許容しなければ、モデムは要求機会を十分に高速には受信しないこととなり、パケット損失が発生する。ピークバースト中のパケット損失を最小にするために、モデムは毎秒150の要求機会を受信しなければならない。
【００４２】
サービスフローがデータを比較的に低い速度で送信する非バースト期間中に、未使用の要求機会が浪費されることは事実である。しかしスケジューリングと、CMTSによる要求機会の伝送にダウンストリームで使用されるリソースの総量は、アップストリームで伝送されるデータの総量に比べれば僅かのものであり、競合要求を使用するためにモデムが必要とする総時間もさほどでない（指数的バックオフとコリージョンの可能性のため）。DOCSISリアルタイムポーリングサービスはこのことを勘案して設計されており、ビデオのようなバースト状のVBRリアルタイムトラフィックに対して理想的である理由である。
【００４３】
ポーリングインターバルは、rtPSに対するRSpecの予約レートRから導出され、予約レートRは典型的にはピーク速度pに等しいから、Rとｐの両者はバケットレートｒより大きい。このことは、サービス保証のためのこれらパラメータのIETF使用法と一致する。
【００４４】
＜許容ポーリングジッタ＞−DOCSIS許容ポーリングジッタパラメータは総時間をμsで規定し、リアルタイムポーリングに対するユニキャスト要求機会は遅延される。リアルタイムビデオセッションに対してこの値は比較的小さくなければならない。PCMMはデフォルトで800μsを規定し、CMTSにIETFRSPECのスラックタームSパラメータによって伝達される。
【００４５】
＜最大持続トラフィックレート＞−DOCSIS最大持続トラフィックパラメータは時間についての最大持続可能速度（すなわち平均速度）を、DOCSISMAC層データグラムの毎秒ビットで規定し、全てのMAC層ヘッダとCRCオーバヘッドを含む。DOCSISではアップストリームオーバヘッドが僅かに大きくなる。これはヘッダがアップストリームで拡張されるためである。VBRビデオトラフィックに対しては最大維持トラフィックレートを、MAC層オーバヘッドを考慮した後のビデオ最大維持レートに等しくすべきである。
【００４６】
＜最大トラフィックバースト＞−DOCSIS最大トラフィックバーストパラメータは、MAC層での最大バーストサイズをバイトで規定し、フローはそのピーク速度で伝送することができる。VBRビデオトラフィックに対して最大トラフィックバーストは、フローがそのピーク速度でバーストできるように設定されることが重要である。最大トラフィックバーストは、MAC層オーバヘッドを考慮した後のIETFトークンバケット深さbに等しい。トラフィックバーストがDOCSISで規定された1522バイトの最小値を下回ってはならないという付加的要求が存在する。
【００４７】
＜最小予約トラフィックレート＞−DOCSIS最小予約トラフィックレートは、フローの受信を保証する最小速度を規定し、MAC層オーバヘッドを考慮した後のIETFRSPECの予約レートRに非常に近似する。しかしPCMMの目的のために、RSVPフロースペックからDOCSISへの変換は、TSpecバケットレートrパラメータの使用を特定する。この変換はVBRビデオトラフィックに対して良好に動作する。なぜならRSpec予約率レートRは典型的にはTSpecバケットレートrと同じ（またはそれより大きい）だからである。このことはいわば、DOCSISMAC層では、予約がビデオセッションの平均速度を使用して行われることを意味する。試験の結果、SDPメディア属性で公示されたようなバンド幅を使用する最小予約トラフィックレートは、アップストリームでは良好に動作するが、ダウンストリームがかなりのパケット損失を受け、いくつかのビットレートではビデオ品質にかなり影響することが示された。前記の実施例はある程度の選択可能なパーセンテージの増加をバンド幅にもたらし、このパケット損失を克服する。
【００４８】
＜仮定的最小予約レートパケットサイズ＞−DOCSIS仮定的最小予約レートパケットサイズはIETF TSpec最小ポリシードユニット（PolicedUnit）mに非常に近似する。IETFパラメータと同様に、これはパケット毎のオーバヘッドを評価するのに使用される。サービスフローがこのサイズより小さいパケットを送信する場合、このパケットは予約レートを維持する目的のために、このサイズであるとしてカウントされる。パケットサイズに大きな変化が存在するVBRビデオトラフィックに対して、我々の実現は設定された固定のパケットサイズパラメータを使用する。DOCSISはこのパラメータをアップストリームサービスフローとダウンストリームサービスフローの両方に対して規定するが、PCMMはこれをダウンストリームに対してだけ規定することに注意されたい。このパラメータに対してDOCSISのデフォルトは規定されておらず、これはCMTS実現に依存する。
【００４９】
＜最大ダウンストリームレイテンシー＞−DOCSIS最大ダウンストリームレイテンシーパラメータは、パケットがCMTSネットワークインタフェースで受信され、HFCでのダウンストリームで伝送されるまでに受ける最大待ち時間を規定する（μsで）。このパラメータは、ダウンストリーム最小予約レートを有するフローにだけ適用され、このフローはこのレートを超過しない。PCMMに対してこのパラメータは、RSpecスラックタームSから設定される。
【００５０】
＜SDPビデオバンド幅のRSVPフロースペックへのマッピング＞−SDPがバンド幅メディア属性パラメータを含んでいなければ、全てのフロースペックパラメータが予め形成されたデフォルトを使用して選択される。そうでなければ、アプリケーションマネージャ110がSDPバンド幅メディア属性を入力として使用して、SDPをフロースペックパラメータにマッピングする。RSVPフロースペックパラメータの選択に影響する他のセッティングがこのセッションで構成され、記述される。一般的に、アプリケーションマネージャが使用する以下のパラメータのほとんどは、各方向（すなわちダウンストリームとアップストリーム）に対して形成される。
【００５１】
遅延（ms）−これはビデオに対する最大の最悪待ち行列遅延であり、最大バーストサイズに相当する（フローがそのピーク速度でバーストする総時間）。100msの初期デフォルト値が提案されている。
【００５２】
＜バンド幅調整（浮動小数点乗数）＞−これは補正係数であり、ビデオバンド幅を過小評価したクライアントに対してより大きなバンド幅を予約するために、または他のインタオペラビリティの問題を解決するために要求されるバンド幅を得るため、オリジナルのSDPと乗算される。アップストリームに対して1.0の初期デフォルト値が、ダウンストリームに対しては1.125が提案されている。初期検査の際に、すべての速度において512Kbpsを下回り、許容可能なビデオ品質を得るためにはダウンストリームで付加的なバンド幅が必要であることが観察された。これは大部分が過度のパケット損失とパケット遅延のためである。
【００５３】
＜レートファクタ（浮動小数点乗数）＞−これは最大持続スループット（バンド幅）を前提にしてピークと予約レートを計算するのに使用される。レートファクタに対する初期デフォルト値は4.0である。
【００５４】
＜最小パケットサイズ（バイト）＞−これは最小ポリシードユニット、およびパケットサイズを必要とする他の計算に使用される評価IPパケットサイズである。最小パケットサイズに対する（控えめな）初期デフォルト値は640である。
【００５５】
＜最大パケットサイズ（バイト）＞−これはIETF TSpecに適合するのに予想される最大IPパケットサイズである。最大パケットサイズに対する初期デフォルト値は1500である。
【００５６】
＜スラックターム（マイクロセカンド）＞−これはIETF RSpecのスラックタームSに使用される値である。PCMMに対してこれは、アップストリームではDOCSISアップストリーム許容ポーリングジッタに、ダウンストリームではDOCSISダウンストリームレイテンシーに相当する。スラックタームに対する初期デフォルト値は800μsであり、これはPCMMでのデフォルト値である。
【００５７】
＜レートリミット（毎秒バイト）＞−これは予約レートRとピークレートpでの上限であり、このパラメータは毎秒バイトで特定される。レートリミットに対する初期デフォルト値はアップストリームに対して96000、ダウンストリームに対して0である（値0は制限のないことを意味する）。
【００５８】
以下のパラメータはアップストリームに対してだけ規定される。
【００５９】
＜ポールインターバルリミット（μs）＞−これはCMTSからの要求に対する最小ポーリングインターバルである。ポーリングインターバルリミットに対する初期デフォルト値は6000μsである（値0は制限のないことを意味する）。
【００６０】
＜ポールインターバルセット＞は、CMTSで許容可能なポーリングインターバルのリストである。以下の記述を参照。提案された初期デフォルトセットは空である。
【００６１】
以下は、PCMM仕様からの関連するTSpecパラメータである。
【００６２】
＜バケット深さ（ｂ）＞−TSpecトークンバケットレートと組み合わされたTSpecトークンバケット深さは、フローの（ピークレートでの）最大バーストサイズを制限し、同様に、フローが被る最大の最悪待ち行列遅延を制限する。このようにして最大の最悪待ち行列遅延とフローのピークレートを考慮しなければならない。
【００６３】
TSpecバケット深さbは次式によりバイトで得られる：
b=(遅延*p)/1000
ここで遅延は構成された最大待ち行列遅延(ms)であり、pはTSpecピークレート（毎秒バイト）である。
例:
遅延＝100ms
p=32000
b=(100*32000)/1000=3200
【００６４】
＜バケットレート(r)＞−TSpecトークンバケットレートは、IPフローが適合する、時間についての平均レートを規定する。毎秒バイトにおけるTSpecバケットレートrは：
r=(バンド幅*バンド幅調整)/8
ここでバンド幅は、SDPからの公示バンド幅（毎秒バイト）であり、バンド幅調整は設定された調整乗数である。
例:
バンド幅=512000
バンド幅調整=1.0
r=512000*1.0/8=64000
【００６５】
＜最大データグラムサイズ(M)＞−TSpec最大データグラムサイズM(バイト）は、形成された最大パケットサイズに対して設定される。
【００６６】
＜最小ポリシードユニット(m)＞−TSpec最小ポリシードユニットm(バイト）は、形成された最小パケットサイズに対して設定される。
【００６７】
＜ピークレート(p)＞−TSpecピークレートは、フローがネットワークへデータをバーストするのに予想される最大レートである。TSpecピークレート（毎秒バイト）は常にRSpec予約レートに等しい。このステートメントは、DOSISrtPSポーリングインターバルに対して使用する予約レートRの間接的結果である。ポーリングインターバルはピークレートを使用して設定しなければならず、このことは事実上、ピークレートは予約レートに等しくなければならないことを意味する。
【００６８】
以下は、PCMM仕様からの関連するRSpecパラメータである。
【００６９】
＜予約レート(R)＞−RSpec予約レートは、フローのトラフィックがTSpecに準拠する場合に、このフローに与えられた保証レートである。PCMMでは、予約レートがDOCSIS定格ポーリングインターバルを決定するのに使用される。この実施例では、予約レートの微分が構成された制限によりコントロールされる。このことは、CMTSとポリシーサーバ/アプリケーションマネージャとの間の相互運用性問題を解決するのに必要である。具体的に言えば、予約レートRパラメータに対する最大値は厳しく制限され（レートリミット）、導出されたDOCSISアップストリーム定格ポーリングインターバルも同様に制限される（ポールインターバルリミット）。
【００７０】
毎秒バイトでのRSpec予約レートRは：
R=r*レートファクタ レートリミット=0
R=min(r*レートファクタ、レートリミット) レートリミット>0
ここでrは、TSpecトークンバケットレート、レートファクタは設定されたレート乗数、レートリミットは予約レートパラメータに設定された上限である。レートリミットがゼロであれば、予約レートに上限はない。
【００７１】
アップストリームでは、予約レートから導出される定格ポーリングインターバルを設定するのに2つのやり方がある：すなわち、ポールインターバルリミットの設定を使用してポールインターバルにリミットを設定するか、またはインターバルの所定のセットにおいて、ポールインターバルセットの設定によりポーリングインターバルを許容するのである。ポールインターバルセットは、CMTSでサポートされる許容可能な定格ポーリングインターバルのリストである。このリストが空でなければ、第2の方法が使用され、それ以外の場合第1の方法が使用される。
【００７２】
＜第1の方法：ポールインターバルリミットを使用＞−アップストリームには、予約レートR（バイト/秒）により割られた最小ポリシードユニットm（バイト）が、設定されたポールインターバルリミット(μs)より小さくてなってはならないとう付加的要求が存在する。言い替えると以下の不等式は、設定されたポールインターバルリミット>0である場合、常に真でなければならない。
【００７３】
m/R*106≧ポールインターバルリミット
アップストリームに対して、毎秒バイトでの予約レートRは：
R=Rに対する上記等式と同じ ポールインターバルリミット=0
R=min(r*レートファクタ、m*106/ポールインターバルリミット)
ポールインターバルリミット>0
例（レートおよびポールインターバルでのリミット）：
r=64000
m=640
レートファクタ=4.0
レートリミット=96000
ポールインターバルリミット=10000
R=min(64000*4,0,96000) ポールインターバルリミット=0
=min(256000,96000)
R=min(96000,640*106/10000) ポールインターバルリミット>0=10000
=min(96000,80000)
=80000
【００７４】
＜第2の方法：ポールインターバルセットを使用＞−ポールインターバルセットが空でなければ、導出された定格ポーリングインターバルを、設定値(μs)のセットから選択しなければならない。この方法を使用する場合、レートリミットとポールインターバルリミットに意味はない。
【００７５】
Rを選択のためのアルゴリズム：
１．R(R1....Rn)の可能値を、mと設定されたポーリングインターバルのセットI1〜Inとに基づいて計算する。
一般的には、R=(m*106)/定格ポーリングインターバル
Ri=(m*106)/Ii すべてのi「1....n」に対して
【００７６】
２．上記(R1....Rn)のRに対する値から、r*レートファクタに最も近く、これを上回らない値を1つ選択する。
例（ポールインターンバルセット）：
r=12000
m=640
レートファクタ=4.0
ポールインターバルセット={10000,20000,30000}
R1=(640*106)/10000=64000
R2=(640*106)/20000=32000
R3=(640*106)/30000=21333.3333....
r*レートファクタ=48000
R=32000
【００７７】
＜スラックターム(S)＞−スラックターム(μs)は、形成されたスラックタームパラメータから設定される。
【００７８】
［オーディオSDP翻訳］
以下のパラグラフは、SDPフィールドからPCMMデータへの、デジタルオーディオトラフィックのための翻訳の詳細を示す。この記述はビデオトラフィックに対する記述を補足するものである。ネットワークエンドポイントにあるオーディオコーデックは、インターパケット到着時間と同じように、オーディオデータに対してフロースペックパラメータを決定する。パケットケーブルコーデック仕様は3つのインターパケット到着時間(10,20,30ms)を規定する。PCMMオーディオ/ビデオコーデック仕様(PKT-SP-CODEC-105-040113)はまた、各フロースペックパラメータをすべてのオーディオコーデックに対し、各3つのパケット時間毎に規定する。サポートされるオーディオコーデックは次のものを含む：
−G.729E
−G.729A
−G.728
−G.726.40
−G.726.32
−G.726.24
−G.726.14
−G.711（PCMエンコーディング）a規則
−G.711（PCMエンコーディング）μ規則
【００７９】
SIP交換にあるネットワークエンドポイントがオーディオコーデックをSDP(セッション記述プロトコル)を使用して特定するならば、オプションのp時間パケット化タイムメディア属性も使用しなければならない。
【００８０】
SIP/SDPセッションによるオーディオコーデックの使用のために正しいフロースペックパラメータを検出するに際し、2つの問題が存在する。第1の問題は、パケット時間（すなわちp時間）SDPメディア属性が最適であり、従ってすべてのネットワークエンドポイントにより使用されないことである。パケット時間が未知であれば、システムは3つのパケット時間10,20,または30msのすべてで動作するフロースペックパラメータを選択することができる。この方法は常に動作するが、常に効率的なリソース予約を提供するものではない。最大パケットサイズと組み合わされた最小パケットインターバルがパケットサイズとパケットレートのすべての組み合わせに適応するため使用される。パケット時間が未知の場合、システムは設定されたデフォルトパケット時間を使用することもできる。パケットケーブルデフォルトパケット時間は20msに規定されている。このデフォルト値または設定されたいずれのデフォルト値も、ネットワークエンドポイントの動作が使用時に既知であれば、使用することができる。
【００８１】
正しいフロースペックパラメータを検出する際の第2の問題は、一般的に、マルチプルコーデックが使用される場合、どのコーデックがSIPネットワークエンドポイントを使用しようとするかを知ることができないことである。
【００８２】
SIPネットワークエンドポイントがマルチプルオーディオコーデックを有しており、同じメディア形式（この場合はオーディオ）に対するマルチプルコーデックを含む場合、2つのネットワークエンドポイント間で取り決められた使用可能なコーデックのうちのいずれかが使用される。両方のエンドポイントは取り決めたコーデックのいずれかの受信を準備しなければならず、他方のエンドポイントに、RTP（リアルタイムプロトコル）メディアストリームがスタートするまで、どのコーデックが使用されているかを知らせるシグナリングは存在しない。
【００８３】
この実施例は、以下の3つの技術の組み合わせを使用し、複数の特定コーデックのうち、どのコーデックに基づいてリソース予約決定が行われるかを検出する。
【００８４】
＜第1の技術＞−SDPフィールドが同じメディア形式に対してマルチプルコーデックを規定する場合、アプリケーションマネージャは最初に、ネットワークリソースの最大量を使用するコーデックに基づいてリソース予約決定する。このことにより、十分なリソースが予約され、取り決められたいずれのコーデックも適切に動作することが保証される。
【００８５】
＜第2の技術＞−この技術は、各メディア形式に対するSDPでのコーデック順序を、特定のコーデックの選択のために使用する。SDP仕様は、SDPでのコーデック順序がネットワークエンドポイントのコーデック優先度を決定すべきであるとアナウンスしている。ほとんどの場合、リストの第1コーデックがネットワークエンドポイントにより使用される。ネットワークエンドポイントがこの標準規格に準拠することが既知であれば、この構成によりQoS予約はより厳密となり、その結果、サービスのコストが低下する。
【００８６】
＜第3の技術＞−この技術は、DOCSIS QoS MIB(Patrick,M., Murwin,W. ,"Data Over Cable System InterfaceSpecificationQuality of Service Management Information Base(DOCSIS-QOSMIB)",Internet-Draft(2004年4月満了), http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-qos-mib-09.txt,2003年10月27日)をCMTSで使用し、ネットワークエンドポイントが送信しているオーディオデータパケットサイズを決定する。オーディオトラフィックはCBR（固定ビットレート）であるから、同じパケットサイズがすべてのパケットに対して使用される。DOCS-QOS MIBを検査することで、DOCSISサービスフローによりオーディオデータの搬送に使用されるパケット数およびバイト、並びにこのフローがアクティブである総時間が得られる。総バイト数を、このバイトを送信するのに使用されるパケット数により割り算すると、パケットサイズが得られる。速度は、転送される総バイト数を、フローがアクティブである総時間により割り算すると得られる。
【００８７】
この実施例は、第1の技術または第2の技術を使用して初期リソース予約を行う。データ伝送の数秒後に、アプリケーションマネージャは正確なパケットサイズと速度を決定し、第3の技術を使用してリソース予約を調整し、これによりオーディオコーデックが必要とするものをより正確に表す。ダイナミックコーデック切り替えが既知の実現性であれば、この実施例は、使用可能なコーデックのいずれかに対して常に動作する第1の技術だけを使用する。
【００８８】
さらなる側面、変形、および実施例は請求項の範囲内にある。
【図面の簡単な説明】
【００８９】
【図１】図1は、2つのネットワークエンドポイント間でVoIPリンクを確立するための従来のアーキテクチャを示す図である。
【図２】図2は、実施例のネットワークアーキテクチャを示す図である。
【図３】図3は、同じネットワークドメインでの2つのネットワークエンドポイントに対する単純なコール手続きを示す図である。
【図４】図4は、異なるネットワークドメインでの2つのネットワークエンドポイントに対する単純なコール手続きを示す図である。
【特許請求の範囲】
【請求項１】
ネットワークエンドポイント間でネットワークリソースのセットを割り当てる方法であって、
アプリケーションマネージャに対してセッション開始要求を使用して、ネットワークエンドポイント間でリソースを予約し、
前記アプリケーションマネージャは論理的かつ物理的に、ネットワークエンドポイントに関連するアプリケーションサーバから分離されており、
アプリケーションマネージャからのPCMMメッセージをポリシーサーバに、セッション開始要求の結果として供給し、
PCMMメッセージは、セッション開始要求に埋め込まれた少なくとも複数の情報を含んでおり、
ポリシーサーバによりネットワークリソースのセットを選択し、ネットワークエンドポイントを接続する経路を形成し、
前記ポリシーサーバはネットワークリソースのセットを、PCMMメッセージに基づいて選択する方法。
【請求項２】
請求項１記載の方法において、セッション開始要求を、セッション開始プロトコルを介して通信する方法。
【請求項３】
請求項２記載の方法において、アプリケーションマネージャをネットワークエンドポイントの1つとアプリケーションサーバとの間に挿入配置し、
前記アプリケーションマネージャは、セッション開始要求をネットワークエンドポイントとアプリケーションサーバとの間で透明に中継し、その際にネットワークエンドポイントまたはアプリケーションサーバの機能的変形を必要としない方法。
【請求項４】
請求項１記載の方法において、SIPメッセージ中にSDPを使用して、リソースの所要のQoS予約をネットワークで実行する方法。
【請求項５】
請求項４記載の方法において、QoS情報を、セッション開始要求中のセッション記述プロトコルフィールドに設ける方法。
【請求項６】
請求項1記載の方法において、セッション開始要求からのハイレベルQoS情報を、基礎となるネットワーク技術の理解と結び付け、PCMMメッセージで使用するために詳細なQoS情報を形成する方法。
【請求項７】
請求項1記載の方法において、QoS情報をSDPまたはRSVPフロースペックを介してXMLメッセージに埋め込み、
該XMLメッセージを使用してセッション開始要求をアプリケーションサーバと通信し、
該アプリケーションサーバは引き続き、QoS情報をアプリケーションマネージャにXMLメッセージで伝送する方法。
【請求項８】
請求項7記載の方法において、HTTPを使用してXMLメッセージをアプリケーションサーバと通信し、
該アプリケーションサーバは引き続きQoS情報をアプリケーションマネージャに伝送する方法。
【請求項９】
請求項1記載の方法において、アプリケーションサーバは、アプリケーションマネージャと通信するためにユニークなセッション識別子を使用することによりステートレス状態に留まり、
セッションとリソースとの関連は、分離されたアプリケーションマネージャで維持され、
セッション識別子は、エンドポイントとアプリケーションサーバとの間のSIPシグナリングメッセージから形成される方法。
【請求項１０】
請求項４記載の方法において、RSVPフロースペックパラメータを、SDPメディア属性に基づいて選択する方法。
【請求項１１】
請求項１０記載の方法において、PCMMフレームワークにリソースを予約するために、RSVPフロースペックパラメータを選択し、フロースペックパラメータ選択動作を実行する能力を提供し、
CMTSでのDOCSISサービスフローQoSパラメータとのインタオペラビリティを保証し、以て種々異なるCMTSベンダー実現にわたる、選択されたフロースペックパラメータの正規化によりQoSを提供し、
SDPメディア属性の種々異なるオプションフィーチャを実現するネットワークエンドポイント間でのインタオペラビリティを保証する方法。
【請求項１２】
請求項１１記載の方法において、エンドポイント間のセッションのアップストリーム方向とダウンストリーム方向に対してコンフィギュラブルな設定を提供し、
該設定をフロースペックパラメータ選択で、各設定に対するデフォルト値に従って使用し、
コンフィギュラブルな設定および関連のデフォルト値は次のものを含む：
遅延、100ms（ダウンストリームとアップストリーム）
バンド幅調整、1.125（ダウンストリーム）
バンド幅調整、1.0（アップストリーム）
レートファクタ、4.0（ダウンストリームとアップストリーム）
最小パケットサイズ、640（ダウンストリームとアップストリーム）
最大パケットサイズ、1500（ダウンストリームとアップストリーム）
スラックターム、800（ダウンストリームとアップストリーム）
レートリミット、96000（アップストリーム）
レートリミット、0（ダウンストリーム）
ポールインターバル限界、6000μs（アップストリーム）
ポールインターバルセット、空（アップストリーム）：
方法。
【請求項１３】
請求項１１記載の方法において、"ptime"メディア属性（パケット化時間）がSDPに設定されていなければ、パケットケーブルオーディオ/ビデオコーデック仕様により指定される全てのパケット化時間に対して十分なリソースが予約されるようにRSVPフロースペックパラメータを選択する方法。
【請求項１４】
請求項１１記載の方法において、マルチプルコーデックがSDPフィールドで取り決められている場合、パケットケーブルオーディオ/ビデオコーデック仕様により指定される全てのパケット化時間に対して十分なリソースが予約されるようにRSVPフロースペックパラメータを選択する方法。
【請求項１５】
請求項１１記載の方法において、ptimeメディア属性が未知の場合、正確にptime（パケット化時間）を決定するためにDOCSIS QoS MIBを使用し、引き続きptimeメディア属性が決定されると、予約されたリソースを変更する方法。
【請求項１６】
請求項１１記載の方法において、使用中の特定のコーデックの決定のためにマルチプロコーデックが取り決められる場合、正確にptime（パケット化時間）を決定するためにDOCSIS QoS MIBを使用し、引き続き特定のコーデックが決定されると、予約されたリソースを変更する方法。
【請求項１７】
請求項３記載の方法において、アプリケーションマネージャは、REGISTERメッセージから、一方または両方のエンドポイントのコンタクトIPアドレスとポート番号を学習し、これによりアプリケーションマネージャはINVITEメッセージをエンドポイントに転送することができる方法。
【請求項１８】
請求項３記載の方法において、アプリケーションマネージャはアプリケーションサーバを問い合わせ、一方または両方のエンドポイントのコンタクトIPアドレスおよびポート番号を獲得し、これによりアプリケーションマネージャはINVITEメッセージをエンドポイントに転送することができる方法。
【請求項１９】
ネットワークエンドポイント間でネットワークリソースのセットを割り当てる方法であって、
アプリケーションマネージャに対してセッション開始要求を使用して、ネットワークエンドポイント間でリソースを予約し、
前記アプリケーションマネージャは論理的に、ネットワークエンドポイントに関連するアプリケーションサーバから分離されており、
アプリケーションマネージャからのPCMMメッセージをポリシーサーバに、セッション開始要求の結果として供給し、
PCMMメッセージは、セッション開始要求に埋め込まれた少なくとも複数の情報を含んでおり、
ポリシーサーバによりネットワークリソースのセットを選択し、ネットワークエンドポイントを接続する経路を形成し、
前記ポリシーサーバはネットワークリソースのセットを、PCMMメッセージに基づいて選択する方法。
【請求項２０】
ネットワークエンドポイント間でネットワークリソースのセットを割り当てるシステムであって、
アプリケーションマネージャを有し、該アプリケーションマネージャは、
(i)ネットワークエンドポイント間での通信を、ネットワークリソースのセットを通して開始するためのセッション開始要求を受信し、
(ii)該セッション開始要求に埋め込まれた少なくとも複数の情報を含むPCMMメッセージを発生し、
前記通信は、アプリケーションサーバに常駐するアプリケーションを使用し、
さらにポリシーサーバを有し、
該ポリシーサーバは、PCMMメッセージを受信し、ネットワークエンドポイントを接続する経路を形成するためのネットワークリソースのセットを選択し、
前記ポリシーサーバはネットワークリソースのセットを、PCMMメッセージに基づいて選択するシステム。
【請求項２１】
請求項２０記載のシステムにおいて、セッション開始要求はセッション開始プロトコル（SIP)で伝送されるシステム。
【請求項２２】
請求項２１記載のシステムにおいて、アプリケーションマネージャは、ネットワークエンドポイントの1つとアプリケーションサーバとの間に配置されており、
該アプリケーションマネージャはセッション開始要求を前記ネットワークエンドポイントとアプリケーションサーバとの間で透明に中継するシステム。
【請求項２３】
請求項２２記載のシステムにおいて、アプリケーションマネージャは、システムのスタンドアローンコンポーネントであるシステム。
【請求項２４】
請求項２２記載のシステムにおいて、アプリケーションマネージャは、ポリシーサーバに組み込まれているシステム。
【請求項２５】
請求項２０記載のシステムにおいて、ネットワークエンドポイントの少なくとも1つは、QoS情報をアプリケーションマネージャに、セッション開始要求を介して提供するシステム。
【請求項２６】
請求項２５記載のシステムにおいて、セッション開始要求は、QoS情報を含むセッション記述プロトコルフィールドを有するシステム。
【請求項２７】
請求項２０記載のシステムにおいて、アプリケーションマネージャは、セッション開始要求からのハイレベルQoS情報をネットワーク資産についての情報と結合し、PCMMメッセージで使用するための詳細なQoS情報を形成するシステム。
【請求項２８】
請求項２０記載のシステムにおいて、アプリケーションサーバまたはアプリケーションマネージャは、QoS情報をXMLメッセージに埋め込み、かつ当該XMLメッセージを使用して、セッションの必要リソースをアプリケーションマネージャまたはアプリケーションサーバとそれぞれ通信するシステム。
【請求項２９】
請求項２０記載のシステムにおいて、アプリケーションサーバは、QoS情報をXMLメッセージに埋め込み、かつ当該XMLメッセージを使用して、ネットワークリソースのセットをアプリケーションマネージャと通信し、
該アプリケーションマネージャは引き続き、QoS情報を詳細なQoSメッセージに翻訳し、ポリシーサーバと通信するシステム。
【請求項１】
ネットワークエンドポイント間でネットワークリソースのセットを割り当てる方法であって、
アプリケーションマネージャに対してセッション開始要求を使用して、ネットワークエンドポイント間でリソースを予約し、
前記アプリケーションマネージャは論理的かつ物理的に、ネットワークエンドポイントに関連するアプリケーションサーバから分離されており、
アプリケーションマネージャからのPCMMメッセージをポリシーサーバに、セッション開始要求の結果として供給し、
PCMMメッセージは、セッション開始要求に埋め込まれた少なくとも複数の情報を含んでおり、
ポリシーサーバによりネットワークリソースのセットを選択し、ネットワークエンドポイントを接続する経路を形成し、
前記ポリシーサーバはネットワークリソースのセットを、PCMMメッセージに基づいて選択する方法。
【請求項２】
請求項１記載の方法において、セッション開始要求を、セッション開始プロトコルを介して通信する方法。
【請求項３】
請求項２記載の方法において、アプリケーションマネージャをネットワークエンドポイントの1つとアプリケーションサーバとの間に挿入配置し、
前記アプリケーションマネージャは、セッション開始要求をネットワークエンドポイントとアプリケーションサーバとの間で透明に中継し、その際にネットワークエンドポイントまたはアプリケーションサーバの機能的変形を必要としない方法。
【請求項４】
請求項１記載の方法において、SIPメッセージ中にSDPを使用して、リソースの所要のQoS予約をネットワークで実行する方法。
【請求項５】
請求項４記載の方法において、QoS情報を、セッション開始要求中のセッション記述プロトコルフィールドに設ける方法。
【請求項６】
請求項1記載の方法において、セッション開始要求からのハイレベルQoS情報を、基礎となるネットワーク技術の理解と結び付け、PCMMメッセージで使用するために詳細なQoS情報を形成する方法。
【請求項７】
請求項1記載の方法において、QoS情報をSDPまたはRSVPフロースペックを介してXMLメッセージに埋め込み、
該XMLメッセージを使用してセッション開始要求をアプリケーションサーバと通信し、
該アプリケーションサーバは引き続き、QoS情報をアプリケーションマネージャにXMLメッセージで伝送する方法。
【請求項８】
請求項7記載の方法において、HTTPを使用してXMLメッセージをアプリケーションサーバと通信し、
該アプリケーションサーバは引き続きQoS情報をアプリケーションマネージャに伝送する方法。
【請求項９】
請求項1記載の方法において、アプリケーションサーバは、アプリケーションマネージャと通信するためにユニークなセッション識別子を使用することによりステートレス状態に留まり、
セッションとリソースとの関連は、分離されたアプリケーションマネージャで維持され、
セッション識別子は、エンドポイントとアプリケーションサーバとの間のSIPシグナリングメッセージから形成される方法。
【請求項１０】
請求項４記載の方法において、RSVPフロースペックパラメータを、SDPメディア属性に基づいて選択する方法。
【請求項１１】
請求項１０記載の方法において、PCMMフレームワークにリソースを予約するために、RSVPフロースペックパラメータを選択し、フロースペックパラメータ選択動作を実行する能力を提供し、
CMTSでのDOCSISサービスフローQoSパラメータとのインタオペラビリティを保証し、以て種々異なるCMTSベンダー実現にわたる、選択されたフロースペックパラメータの正規化によりQoSを提供し、
SDPメディア属性の種々異なるオプションフィーチャを実現するネットワークエンドポイント間でのインタオペラビリティを保証する方法。
【請求項１２】
請求項１１記載の方法において、エンドポイント間のセッションのアップストリーム方向とダウンストリーム方向に対してコンフィギュラブルな設定を提供し、
該設定をフロースペックパラメータ選択で、各設定に対するデフォルト値に従って使用し、
コンフィギュラブルな設定および関連のデフォルト値は次のものを含む：
遅延、100ms（ダウンストリームとアップストリーム）
バンド幅調整、1.125（ダウンストリーム）
バンド幅調整、1.0（アップストリーム）
レートファクタ、4.0（ダウンストリームとアップストリーム）
最小パケットサイズ、640（ダウンストリームとアップストリーム）
最大パケットサイズ、1500（ダウンストリームとアップストリーム）
スラックターム、800（ダウンストリームとアップストリーム）
レートリミット、96000（アップストリーム）
レートリミット、0（ダウンストリーム）
ポールインターバル限界、6000μs（アップストリーム）
ポールインターバルセット、空（アップストリーム）：
方法。
【請求項１３】
請求項１１記載の方法において、"ptime"メディア属性（パケット化時間）がSDPに設定されていなければ、パケットケーブルオーディオ/ビデオコーデック仕様により指定される全てのパケット化時間に対して十分なリソースが予約されるようにRSVPフロースペックパラメータを選択する方法。
【請求項１４】
請求項１１記載の方法において、マルチプルコーデックがSDPフィールドで取り決められている場合、パケットケーブルオーディオ/ビデオコーデック仕様により指定される全てのパケット化時間に対して十分なリソースが予約されるようにRSVPフロースペックパラメータを選択する方法。
【請求項１５】
請求項１１記載の方法において、ptimeメディア属性が未知の場合、正確にptime（パケット化時間）を決定するためにDOCSIS QoS MIBを使用し、引き続きptimeメディア属性が決定されると、予約されたリソースを変更する方法。
【請求項１６】
請求項１１記載の方法において、使用中の特定のコーデックの決定のためにマルチプロコーデックが取り決められる場合、正確にptime（パケット化時間）を決定するためにDOCSIS QoS MIBを使用し、引き続き特定のコーデックが決定されると、予約されたリソースを変更する方法。
【請求項１７】
請求項３記載の方法において、アプリケーションマネージャは、REGISTERメッセージから、一方または両方のエンドポイントのコンタクトIPアドレスとポート番号を学習し、これによりアプリケーションマネージャはINVITEメッセージをエンドポイントに転送することができる方法。
【請求項１８】
請求項３記載の方法において、アプリケーションマネージャはアプリケーションサーバを問い合わせ、一方または両方のエンドポイントのコンタクトIPアドレスおよびポート番号を獲得し、これによりアプリケーションマネージャはINVITEメッセージをエンドポイントに転送することができる方法。
【請求項１９】
ネットワークエンドポイント間でネットワークリソースのセットを割り当てる方法であって、
アプリケーションマネージャに対してセッション開始要求を使用して、ネットワークエンドポイント間でリソースを予約し、
前記アプリケーションマネージャは論理的に、ネットワークエンドポイントに関連するアプリケーションサーバから分離されており、
アプリケーションマネージャからのPCMMメッセージをポリシーサーバに、セッション開始要求の結果として供給し、
PCMMメッセージは、セッション開始要求に埋め込まれた少なくとも複数の情報を含んでおり、
ポリシーサーバによりネットワークリソースのセットを選択し、ネットワークエンドポイントを接続する経路を形成し、
前記ポリシーサーバはネットワークリソースのセットを、PCMMメッセージに基づいて選択する方法。
【請求項２０】
ネットワークエンドポイント間でネットワークリソースのセットを割り当てるシステムであって、
アプリケーションマネージャを有し、該アプリケーションマネージャは、
(i)ネットワークエンドポイント間での通信を、ネットワークリソースのセットを通して開始するためのセッション開始要求を受信し、
(ii)該セッション開始要求に埋め込まれた少なくとも複数の情報を含むPCMMメッセージを発生し、
前記通信は、アプリケーションサーバに常駐するアプリケーションを使用し、
さらにポリシーサーバを有し、
該ポリシーサーバは、PCMMメッセージを受信し、ネットワークエンドポイントを接続する経路を形成するためのネットワークリソースのセットを選択し、
前記ポリシーサーバはネットワークリソースのセットを、PCMMメッセージに基づいて選択するシステム。
【請求項２１】
請求項２０記載のシステムにおいて、セッション開始要求はセッション開始プロトコル（SIP)で伝送されるシステム。
【請求項２２】
請求項２１記載のシステムにおいて、アプリケーションマネージャは、ネットワークエンドポイントの1つとアプリケーションサーバとの間に配置されており、
該アプリケーションマネージャはセッション開始要求を前記ネットワークエンドポイントとアプリケーションサーバとの間で透明に中継するシステム。
【請求項２３】
請求項２２記載のシステムにおいて、アプリケーションマネージャは、システムのスタンドアローンコンポーネントであるシステム。
【請求項２４】
請求項２２記載のシステムにおいて、アプリケーションマネージャは、ポリシーサーバに組み込まれているシステム。
【請求項２５】
請求項２０記載のシステムにおいて、ネットワークエンドポイントの少なくとも1つは、QoS情報をアプリケーションマネージャに、セッション開始要求を介して提供するシステム。
【請求項２６】
請求項２５記載のシステムにおいて、セッション開始要求は、QoS情報を含むセッション記述プロトコルフィールドを有するシステム。
【請求項２７】
請求項２０記載のシステムにおいて、アプリケーションマネージャは、セッション開始要求からのハイレベルQoS情報をネットワーク資産についての情報と結合し、PCMMメッセージで使用するための詳細なQoS情報を形成するシステム。
【請求項２８】
請求項２０記載のシステムにおいて、アプリケーションサーバまたはアプリケーションマネージャは、QoS情報をXMLメッセージに埋め込み、かつ当該XMLメッセージを使用して、セッションの必要リソースをアプリケーションマネージャまたはアプリケーションサーバとそれぞれ通信するシステム。
【請求項２９】
請求項２０記載のシステムにおいて、アプリケーションサーバは、QoS情報をXMLメッセージに埋め込み、かつ当該XMLメッセージを使用して、ネットワークリソースのセットをアプリケーションマネージャと通信し、
該アプリケーションマネージャは引き続き、QoS情報を詳細なQoSメッセージに翻訳し、ポリシーサーバと通信するシステム。
【図１】
【図２】
【図３】
【図４】
【図２】
【図３】
【図４】
【公表番号】特表２００７−５０３１８８（Ｐ２００７−５０３１８８Ａ）
【公表日】平成１９年２月１５日（２００７．２．１５）
【国際特許分類】
【出願番号】特願２００６−５３３７６９（Ｐ２００６−５３３７６９）
【出願日】平成１６年６月１４日（２００４．６．１４）
【国際出願番号】ＰＣＴ／ＵＳ２００４／０１８７８４
【国際公開番号】ＷＯ２００４／１１２３３５
【国際公開日】平成１６年１２月２３日（２００４．１２．２３）
【出願人】（５０５４５４３８４）キャミアント，インク． (9)
【Ｆターム（参考）】
【公表日】平成１９年２月１５日（２００７．２．１５）
【国際特許分類】
【出願日】平成１６年６月１４日（２００４．６．１４）
【国際出願番号】ＰＣＴ／ＵＳ２００４／０１８７８４
【国際公開番号】ＷＯ２００４／１１２３３５
【国際公開日】平成１６年１２月２３日（２００４．１２．２３）
【出願人】（５０５４５４３８４）キャミアント，インク． (9)
【Ｆターム（参考）】
[ Back to top ]