JP2008278512A - Ｉｐメディア・フローのためのバインド情報 - Google Patents

Abstract

【課題】セッションの１つ以上のメディア・フローを特定し許可するバインド機構を提供する。
【解決手段】バインド情報は、許可トークンおよび１つ以上のパケット・メディア・フロー識別子を用いて、許可のためにセッションの１つ以上のパケット・メディア・フローを特定する。これによって、セッションの個々のパケット・メディア・フローに基づいてリソースの許可および配分を可能にしつつも、セッション毎の許可トークンを用いるという利点が得られる。バインド機構は種々の態様を含む。
【選択図】 図５

Description

本発明は、パケット・メディア・フローのためのバインド機構(binding mechanism)に関する。一実施形態では、このバインド機構は、許可トークンおよび１つ以上のフロー識別子を用いて、セッションの１つ以上のメディア・フローを特定し許可する。

本願は、２００１年４月１７日に出願した"Binding Information for IP Media Flows"（ＩＰメディア・フローのためのバインド情報）と題する米国仮特許出願第６０／２８４，３５８号の優先権を主張する。その内容は、ここで引用したことにより本願にも含まれることとする。

最近の１０年の間に、公衆が使用するセルラ・デバイスの数は爆発的に増大した。移動電話機は珍しくなくなり、ワイヤレス機能を備えたパーソナル・ディジタル・アシスタント（ＰＤＡ）およびラップトップ・コンピュータも普及しつつある。セルラ・デバイスは、ワールド・ワイド・ウェブの閲覧、一方向および双方向オーディオおよびビデオ通信、インスタント・メッセージ送受信、ならびにその他の形式のマルチメディア情報の送受信にも用いられている。

同じ期間に、インターネットは飛躍的に成長した。１９９０年初期には、インターネットは、電子メール、テキスト通信、またはファイル転送に用いられるのが通例であった。今日、インターネットは、これらの目的にも依然として使われているが、一方向オーディオおよびビデオ・ストリーミング(streaming)、双方向オーディオおよびビデオ通信、マルチメディア閲覧、およびメッセージ送受信にも用いられている。

インターネットは、パケット交換型ネットワークの一例である。いかなる種類の情報がインターネット上で送られても、この情報はパケット単位で送信される。一般に、パケットは、１）パケットの発信元および宛先のアドレスを含むヘッダと、２）ひとまとまり(chunk)の情報を含むデータ・ペイロード部とを有する。パケットは、インターネット内でコンピュータからコンピュータに導かれ、発信元から宛先に供給される。インターネット・プロトコル［「ＩＰ」］とは、インターネットを通じてパケットを送信するための規則集である。別のパケット・データ・プロトコルが開発されるのと同様、種々のバージョンのＩＰも開発されている。

インターネットは、電気通信ネットワークとして、様々な利点を提供する。これは地球全体に及び、機器の故障を補償する冗長性を含む。これは、種々の異なる形式のネットワークおよびユーザ機器と動作する。

一方、インターネットの特性には、ある種の用途には適さないものもくつかある。従来より、インターネットを通じたパケットの配信は、ベスト・エフォート・モデルにしたがって行われてきた。ルーティング・コンピュータ（即ち、ルータ）は、可能な限り最良の状態でパケットをルーティングするが、トラフィック量が溢れることもある。このようなときに、パケットの配信は遅れる可能性があり、あるいはパケットが欠落する可能性もある。電子メールのような用途では、これは実際には問題にならない。何故なら、配信時間はさほど重要ではなく、パケットを再送信することができるからである。しかしながら、他の用途では、遅延や不連続の問題は一層深刻となる。音声電話(audio telephony)やテレビ会議では、通信に容認可能な遅延量には限界がある。オーディオおよびビデオ・ストリーミングの限界はさほど厳しくないが、遅延や不連続の悪影響を受ける可能性はある。インターネットのベスト・エフォート・モデルは、より高いサービス品質［「ＱｏＳ］）要件を有するオーディオ、ビデオ、およびその他のＩＰマルチメディア・アプリケーションの開発を阻害する。加えて、インターネット・ユーザには、インターネットを通じてユーザがどれだけパケットを送信または受信したかには関係なく、均一のアクセス料金が課金される。したがって、電子メールのためにインターネットを用いる人には、ＩＰマルチメディア・アプリケーションのためにインターネットを用いる人と比較すると、不均衡に課金されていると考えられる。更に、一層高いＱｏＳを求めて高額の料金を支払おうとしても、その選択肢はない。

最近の開発には、ＱｏＳ要求が高い用途には適さない特性に取り組みつつ、インターネットの優れた特徴をいかに利用するかという点に照準をあてたものがある。他にも、移動電気通信やパケット交換ネットワーク双方を通じて通信するデバイスについて、移動電気通信ネットワークにおけるＱｏＳおよび端末間のＱｏＳ(end-to-end QoS)に照準を当てた開発もある。
１．セッションの開始および記述プロトコル
セッション開始プロトコル［「ＳＩＰ」］は、一人以上の参加者とのセッションを作成し、修正し、終了させるための規則集である。これらのセッションは、インターネット・マルチメディア会議、インターネット通話、およびマルチメディア配給(distribution)を含む。ＳＩＰは、主にセッションに関する情報を伝達するために用いられ、パケットのルーティングというようなことを制御する下位プロトコルの上で動作する。

ＳＩＰメッセージは、セッション記述を、例えば、セッション記述プロトコル［「ＳＤＰ］）にしたがって搬送することができ、これによって参加者はセッションのためのメディア・フローについて同意することができる。ＳＤＰ記述は、セッション・レベルの記述（セッションおよびメディア・ストリームに適用される詳細を含む）、および０以上のマルチ・レベル記述（単一のメディア・ストリームに適用される詳細を含む）を含む。セッション・レベル記述は、セッション名（ＳＤＰ記述において「ｓ＝」で始まるラインによって識別する）のような情報を含み、更に接続情報［「ｃ＝」］、帯域幅情報［「ｂ＝」］、およびその他の情報も含むことができる。メディア・レベル記述［「ｍ＝」］は、メディア種別（例えば、ビデオ、オーディオ）、トランスポート・プロトコル、およびフォーマット（例えば、ＭＰＥＧビデオ）のような情報を含む。また、メディア・レベル記述は、接続情報、帯域幅情報、およびその他の情報も含むことができる。

ＳＩＰは、ユーザの現在位置に対する要求を仲介(proxy)し、再送出することによって、ユーザの移動性に対応する。例えば、ユーザは、ＳＩＰプロキシを用いて彼の現在位置を登録することができ、プロキシは、ＳＩＰ通知については、ユーザの仲介者として作用する。

ＳＩＰは、ユーザ・エージェント［「ＵＡ」］およびＳＩＰプロキシを用いて、呼の許可に対応するように拡張されている。ＵＡ（例えば、ユーザのセルラ・デバイス）は、信用できないと見なされる。ＵＡが開始した呼では、ＳＩＰプロキシがＵＡへ／からのメディア・データを許可する。ＳＩＰプロキシは、メディア許可トークンをＵＡに供給する。ＵＡがメディア・データを他の終点(end point)と交換する準備ができたときに、ＵＡは、そのＳＩＰプロキシから受信したメディア許可トークンを用いて、帯域幅を要求する。

ＳＩＰおよびＳＤＰに関するこれ以上の情報については、Internet Engineering Task Force（インターネット・エンジニアリング・タスク・フォース）［「ＩＥＦＴ」］から発行されているRequest for Comment（コメントの要求）［「ＲＦＣ」］２５４３およびＲＦＣ２３２７を参照のこと。前述のＳＩＰの拡張については、"SIP Extensions for Media Authorization"（メディア許可のためのＳＩＰの拡張）第１版と題するIETF Internet Draft（ＩＥＴＦインターネット草稿）を参照のこと。
ＩＩ．次世代インターネット・アーキテクチャ
インターネット上におけるＱｏＳについての懸念に取り組むために、インターネットのこれまでのベスト・エフォート・モデルを変化させる様々なアーキテクチャが研究されている。これら次世代アーキテクチャには、Integrated Services in the Internet Architecture（インターネット・アーキテクチャにおける統合サービス）［「ＩｎｔＳｅｒｖ」］およびArchitecture for Differentiated Services（差別化サービスのためのアーキテクチャ）［「ＤｉｆｆＳｅｒｖ」］が含まれる。

ＩｎｔＳｅｒｖは、インターネットの従来からのベスト・エフォート・モデルに１組の拡張を規定する。ＩｎｔＳｅｒｖアーキテクチャでは、設定機構を用いて情報をルータに伝送し、要求されたサービスをルータが、そのサービスを要求したフローに提供できるようにしている。Resource Reservation Protocol（リソース予約プロトコル）［「ＲＳＶＰ」］は、設定機構の１つである。ホストは、ＲＳＶＰを用いて、個々のデータ・フローに対するネットワークからの特定のＱｏＳを要求する。ネットワークは、これに応じて、要求を認めるかまたは拒絶する。要求が認められると、該当するルータがＱｏＳを提供するように構成される。ＩｎｔＳｅｒｖおよびＲＳＶＰに関する追加の情報については、ＲＦＣ１６３３、ＲＦＣ２２０５、および関連する仕様書を参照のこと。

ＤｉｆｆＳｅｒｖアーキテクチャでは、パケットは、多数の集約フロー、即ち、「クラス」の１つに分類される。パケット・ヘッダは、パケットのクラスを示すＤｉｆｆＳｅｒｖコードポイントを含む。ＤｉｆｆＳｅｒｖネットワークの縁部にあるネットワーク・ノード（即ち、ＤｉｆｆＳｅｒｖエッジ・ノード）は、適切なＤＳＣＰをパケット・ヘッダ内に置くことができる。ＤＳＣＰに基づいて、ＤｉｆｆＳｅｒｖルータは、ＤｉｆｆＳｅｒｖネットワークにおける次のホップのために、異なるパケット転送処理をパケットに適用する。ＤｉｆｆＳｅｒｖに関する追加の情報については、ＲＦＣ２４７４、ＲＦＣ２４７５、および関連する仕様書を参照のこと。

インターネット使用料金に関する懸念に取り組むために、様々な許可および課金アーキテクチャが開発されている。アーキテクチャが異なると、課金はインターネットの使用（例えば、トラフィックおよび／または接続時間）、移動電気通信ネットワークの使用、セッション、またはメディア・フローによって行われる。様々な用途において、セッションおよびフローに基づく課金は、簡略性という利点をエンド・ユーザに提供し、異なるネットワークに対する価格一括契約(pricing package)に柔軟性を提供する。追加の情報については、IETFおよび3rd Generation Partnership Project［「３ＧＰＰ」］による関連仕様書を参照のこと。
ＩＩＩ．端末間ＱｏＳ
インターネット上において２つのセルラ・デバイス間で情報が流れる場合、端末間ＱｏＳは、インターネットおよびセルラ・デバイス間のインターネットのＱｏＳおよび移動電気通信ネットワーク（例えば、Global System for Mobile Communication（汎ヨーロッパ・ディジタル移動通信システム）［「ＧＳＭ」］またはUniversal Mobile Telecommunications System（万国移動電気通信システム）［「ＵＭＴＳ」］ネットワーク）のＱｏＳに左右される可能性がある。

３ＧＰＰは、移動電気通信ネットワークＱｏＳおよび端末間ＱｏＳに関する数多くの仕様書を編成している。3rd Generation Technical Specification（第３世代技術仕様書）［「３ＧＴＳ」］23.060 v3.6.0は、移動電気通信ネットワーク上での、ＩＰのようなPacket Data Protocol（パケット・データ・プロトコル）［「ＰＤＰ」］を用いるパケット・サービスについて記載している。３ＧＴＳ２３．１０７ｖ４．０．０は、ＵＭＴＳネットワークに対するＱｏＳフレームワークを記述している。３ＧＴＳ２３．２０７ｖ１．２．０は、端末間ＱｏＳのフレームワークについて記載しており、異なるネットワーク間でＱｏＳ要件をどのようにマップする(map)かについて取り組んでいる。
Ａ．ベアラ・サービス
一般に、ネットワーク上において所要のＱｏＳを実現するためには、規定の特性および機能性を有するベアラ・サービス［「ＢＳ」、「ベアラ」または「サービス」］を、ネットワーク上においてサービスの提供元から宛先まで設定する。ベアラ・サービスは、契約したＱｏＲの提供、例えば、制御シグナリング、ユーザ・プレーン・トランスポート、およびＱｏＳ管理機能性を可能にする態様を含む。図１は、従来技術による、ベアラ・サービス層状アーキテクチャ（１００）を示す。特定のレイヤ上におけるベアラ・サービスは、下位のベアラが提供するサービスを用いて、上位のレイヤにサービスを提供する。他のアーキテクチャでは、図１に示すサービスの内１つ以上が欠けていたり、異なるサービス構成を用いたり、または異なるサービスを用いる場合がある。図１およびその中で照会しているサービスおよび構成要素に関する追加の情報については、３ＧＴＳ２３．２０７ｖ１．２．０、３ＧＴＳ２３．１０７ｖ４．０．０、および関連する仕様書を参照のこと。
Ｂ．ネットワーク・アーキテクチャの例
図２は、従来技術によるネットワーク・アーキテクチャ（２００）の簡略化した例を示す。他のネットワーク・アーキテクチャも可能である。アーキテクチャ（２００）は、一般的なパケット無線サービス［「ＧＰＲＳ」］、およびバックボーンＩＰネットワーク（２４０）（例えば、インターネット）を用いたＵＭＴＳネットワークを含む。

図２では、ローカル・ユーザ機器［「ＵＥ」］（２１０）は、例えば、移動電話機のようなセルラ・デバイス、またはワイヤレス伝送機能を有するコンピュータである。サービスを提供するＧＰＲＳ対応ノード［「ＳＧＳＮ」］（２２０）およびゲートウェイＧＰＲＳ対応ノード［「ＧＧＳＮ」］（２３０）は、移動電気通信ネットワーク用ＧＰＲＳに対応する機能性を備えており、同一または異なるネットワーク・ノード内に位置することができる。ＳＧＳＮ（２２０）は、例えば、ワイヤレス・チャネルによって、基地局と通信し、一方基地局は、無線伝送によって、ＵＥ（２１０）と通信する。ＧＧＳＮ（２３０）は、ＵＭＴＳネットワークおよびバックボーンＩＰネットワーク（２４０）間でパケットをルーティングする（例えば、ＤｉｆｆＳｅｒｖ Ｅｄｇｅ、ＩｎｔＳｅｒｖ／ＲＳＶＰシグナリング、またはその他の機能を提供する）。

ＩＰベアラ・レイヤ（２７０）は、ＩＰベアラ・サービス（２７２）を含み、ＵＭＴＳネットワークおよびバックボーンＩＰネットワーク（２４０）にわたって、契約したＱｏＳをＵＥ（２１０）からリモート・ホスト（２６０）に提供する。アクセス・ベアラ・レイヤ（２８０）は、ＩＰベアラ・レイヤ（２７０）の下位にあたるベアラ・サービスを含み、例えば、契約したＱｏＳをＵＥ（２１０）とＧＧＳＮ（２３０）との間で提供するＵＭＴＳベアラ・サービスがある。図２は、リモート・アクセス・ポイント（２５０）や、バックボーンＩＰネットワーク（２４０）とリモート・ホスト（２６０）との間のアクセス・ベアラ・サービスの詳細を省いて抽象化している。リモート・ホスト（２６０）は、ＵＥ（２１０）側と同一であることも、異なることも可能である。

ＵＥ（２１０）は、１つ以上のＰＤＰ（例えば、ＩＰ）アドレスを有し、これらは静的または動的に割り当てることができる。ＰＤＰコンテキスト・ベアラ（例えば、ＵＭＴＳネットワークＵＥのＧＰＲＳ）を通じて１つ以上のＰＤＰコンテキストを設定する。例えば、ＰＤＰコンテキスト活性化要求の場合、ＵＥ（２１０）は指定したＱｏＳのパケット・サービスを、ＰＤＰアドレスに対して、アクセス・ポイント名［「ＡＰＮ」］から要求する。ＡＰＮは、外部パケット・データ・ネットワークおよび／またはサービスを参照し、要求をＧＧＳＮにマップする際に用いることができる。要求ＱｏＳは、ＱｏＳプロファイルによって指定することができる。

ＱｏＳプロファイルとは、ＵＭＴＳネットワークのようなネットワークのサービスを指定する１組の属性である。３ＧＴＳ２３．１０７Ｖ４．０．０は、４つの異なるＵＭＴＳ ＱｏＳトラフィック・クラスについて記載しており、これらは主にトラフィックの遅延に対する感度が異なる。トラフィック・クラスに加えて、ベアラのユーザは、ネットワークが提供するサービスに対して他の属性も指定することができ、最大ビットレート、保証ビットレート、および転送遅延が含まれる。

ＳＧＳＮ（２２０）およびＧＧＳＮ（２３０）は、加入者のプロファイル、現在のリソース、またはその他の判断基準に応じて、要求ＱｏＳを変更することができる。ＵＥ（２１０）は、ＰＤＰコンテキスト・ベアラを通じて、同じまたは異なるＱｏＳで追加のＰＤＰコンテキストを要求することができる。また、ＵＥ（２１０）は、既存のコンテキストの所要の属性も修正することができる（例えば、ＰＤＰコンテキスト修正要求によって）。状況によっては、ＧＧＳＮまたはその他のネットワーク・エンティティがコンテキストの活性化または修正を行うことができる。

図２に関する追加の情報、その中で照会されているサービスおよび構成要素、その他のネットワーク・アーキテクチャ、ＰＤＰ、ＱｏＳプロファイル、ならびにＵＭＴＳネットワークに対するＱｏＳについては、３ＧＴＳ２３．２０７ｖ１．２．０、３ＧＴＳ２３．１０７ｖ４．０．０、３ＧＴＳ２３．０６０ｖ３．６．０、および関連する仕様書を参照のこと。
Ｃ．ポリシーの施行およびＱｏＳ相互作用
図３は、従来技術による端末間ＩＰ ＱｏＳのためのＱｏＳ管理機能を有するフレームワーク（３００）を示す。高レベルでは、図３は、ＵＥ（３１０）、セルラ基地局のネットワークのようなＵＴＲＡＮ（３２０）、ＳＧＳＮのようなＣＮ ＥＤＧＥ（３３０）、ＧＧＳＮのようなゲートウェイ（３４０）、プロキシ−呼セッション制御機能［「Ｐ−ＣＳＣＦ」］（３５０）、および外部ネットワーク（３６）を示す。簡略化のために、図３は、下位のベアラ・サービス機能を示していない。

図３では、ゲートウェイ（３４０）は、ＩＰ ＢＳマネージャ（３４２）、変換（３４６）機能、およびＵＭＴＳ ＢＳマネージャ（３４８）を含む。ＩＰ ＢＳマネージャ（３４２）は、ＤｉｆｆＳｅｒｖ Ｅｄｇｅ、ＲＳＶＰ／ＩｎｔＳｅｒｖシグナリング、ポリシー制御、またはサービス同意機能のような機構を用いて、外部ネットワーク（３６０）との相互作用を管理する。ＩＰ ＢＳマネージャ（３４２）は、変換（３４６）機能を通じて、ＵＭＴＳ ＢＳマネージャ（３４８）と通信する。変換（３４６）機能は、ＵＭＴＳベアラ・サービスの機構およびパラメータ（例えば、ＱｏＳパラメータ）とＩＰベアラ・サービスのそれらとの間の相互作用を用意する(provide)。他のフレームワークも可能であり、例えば、ＵＥ（３１０）におけるＩＰ ＢＳマネージャおよび変換機能を含むもの、またはネットワーク間の相互作用のためのその他の機構を用いるものがある。

フレームワーク（３００）は、ポリシーに基づく承認(admission)制御に用いることができ、その場合、ポリシー制御機能［「ＰＣＦ」］（３５３）が、ポリシー情報および規則を用いて、ネットワークに基づくＩＰポリシーに関する決定を行う。ポリシー情報要素は、例えば、アドレスや、セッションのＩＰフローに対して許可されたＱｏＳを含む。ＰＣＦ（３５３）は、ポリシー情報を、ゲートウェイ（３４）内のＩＰ ＢＳマネージャ（３４２）に、インターフェースを通じて伝達する。ＩＰマルチメディアおよびその他のサービスに対して、サービスに基づく個別ポリシー［「ＳＢＬＰ」］判断をベアラに適用することができる。ＳＢＬＰ判断は、ＵＥ（３１０）、ゲートウェイ（３４０）、およびＰ−ＣＳＣＦ（３５０）間の交流(interaction)を伴う。

ＰＣＦ（３５３）に加えて、Ｐ−ＣＳＣＦ（３５０）は、ローカルＳＩＰプロキシ（３５１）を含み、ＳＩＰシグナリング、およびセッションのＳＤＰ記述の取得に用いる。Ｐ−ＣＳＣＦ（３５０）およびＰＣＦ（３５３）にはいくつかの役割があり、ＳＤＰ記述に記述されているセッションに対してＱｏＳリソースを許可することを含む。Ｐ−ＣＳＣＦ（３５０）／ＰＣＦ（３５３）は、ＳＩＰセッションに対して許可トークンを生成し、許可トークンをＵＥ（３１０）にＳＩＰメッセージによって送ることができる。例えば、許可トークンは、メディア許可のためのＳＩＰ拡張に関するＩＥＴＦ仕様書に準拠する。

ＵＥ（３１０）は、リソース予約要求を行い、ゲートウェイ（３４０）はこれをＰＣＦ（３５３）からの許可と照合する。例えば、ＵＥ（３１０）は、ＰＤＰコンテキスト活性化または修正要求内に、ＵＭＴＳ ＱｏＳパラメータと共に、許可トークンを含む。次いで、許可トークンは、要求をＰＣＦ（３５３）からの許可と相関付けるために用いることができる。

ゲートウェイ（３４０）は、ＩＰポリシー施行地点であり、いくつかの役割を有する。これは、ＩＰパケットの１つまたは複数のＱｏＳフローに対するアクセスを制御する。ポリシー情報は、ＰＣＦ（３５３）によってゲートウェイ（３４０）に「押し出される」(push)か、またはゲートウェイ（３４０）によってＰＣＦ（３５３）から要求されるかのいずれかである。また、ゲートウェイ（３４０）は、フロー／ゲーティング制御機能性も備えており、あるフローのＩＰパケットが許可を超過した場合処置を講ずる。

図３ならびにその中で照会したサービスおよび構成要素に関する追加の情報については、３ＧＴＳ２３．２０７ｖ１．２．０、および関連する仕様を参照のこと。
Request for Comment［「ＲＦＣ」］２５４３ ＲＦＣ２３２７ "SIP Extensions for Media Authorization"第１版 ＲＦＣ１６３３ ＲＦＣ２２０５ ＲＦＣ２４７４ ＲＦＣ２４７５ ３ＧＴＳ２３．２０７ｖ１．２．０ ３ＧＴＳ２３．１０７ｖ４．０．０ ３ＧＴＳ２３．０６０ｖ３．６．０

一般に、フロー毎の許可では、セッション毎の許可よりも、許可、ＱｏＳ管理、および課金に関して、一層精細な制御が行われる。しかしながら、ＳＩＰシグナリング中に生成される許可トークンは、セッションの多数の異なるフローを個々に特定し許可を与えるには適していない。

本発明は、パケット・メディア・フローのためのバインド機構に関する。バインド機構は、許可トークンおよびパケット・メディア・フロー識別子を用いて、セッションのパケット・メディア・フローを特定し許可を与える。これによって、セッション毎の許可トークンを用いつつ、セッションの個々のパケット・メディア・フローに基づくリソースの許可および配分を可能にするという利点が得られる。バインド機構は種々の態様を含む。

第１の形態によれば、装置は、セッションの１つ以上のパケット・メディア・フローを許可するためにバインド情報を含む１つ以上のメッセージを送信する。バインド情報は、許可トークンを含み、パケット・メディア・フロー識別子と組み合わせると、セッションのパケット・メディア・フローを特定するのに十分となる。例えば、ＵＥが、バインド情報を含む１つ以上のＰＤＰコンテキスト要求を送信する。バインド情報は、ＳＩＰメディア許可トークンと、１つ以上のＩＰメディア・フロー識別子とを含む。

第２の形態によれば、ネットワーク・ノードが、セッションの１つ以上のパケット・メディア・フローを許可するために、バインド情報を処理する。バインド情報は、許可トークンを含む。ネットワーク・ノードは、許可トークンに関して、１つ以上のパケット・メディア・フロー識別子の各々を解釈し、セッションのパケット・メディア・フローを特定する。例えば、バインド情報は、ＳＩＰメディア許可トークンと、１つ以上のＩＰメディア・フロー識別子とを含む。

本発明の更に別の特徴および利点は、添付図面を参照しながら進める、以下の実施形態の詳細な説明から明白となろう。

記載する本発明の実施形態は、セッションの１つ以上のＩＰメディア・フローに対して要求されたＱｏＳを許可するバインド機構を対象とする。ＵＥからＧＧＳＮに送信されるバインド情報は、ＳＩＰメディア許可トークンを含む。ＧＧＳＮは、１つ以上のＩＰメディア・フロー識別子を、ＳＩＰメディア許可トークンに関して解釈し、セッションの１つ以上のＩＰメディア・フローを特定する。伝送帯域幅、計算上の複雑さ、およびシグナリングの複雑さに関して、セッション毎の許可トークンの仕様は、セッションのＩＰメディア・フロー毎に異なる許可トークンを用いるよりも一層効率的である。同時に、セッション毎の許可トークンと共に多数のＩＰメディア・フロー識別子を用いることによって、セッションの個々のＩＰメディア・フローに基づく、リソース許可および配分のための簡単な機構が設けられる。

記載する実施形態では、バインド機構は、いくつかの技法およびシステムを含む。これらの技法およびシステムは、ここでは、単一の統合化フレームワークの一部として説明するのが通例であるが、これらの技法およびシステムは、別個に、潜在的には他の技法およびシステムと組み合わせて適用することができる。

記載する実施形態では、バインド機構は、種々の技術的仕様書に準拠したシステムの一部であり、仕様書には、最も特筆すべきものとして３ＧＴＳ２３．２０７が含まれるが、３ＧＴＳ２３．１０７、３ＧＴＳ２３．０６０、および"SIP Extensions for Media Authorization"（メディア許可のためのＳＩＰ拡張）と題するＩＥＴＦインターネット草稿も含まれる。代替の実施形態では、バインド機構は、他のシステムにおいて、および／または他のプロトコルと動作する。

表２は、本願において用いられる頭字語および略語の一部を纏めたものである。

１．計算機環境
図４は、ここに記載する実施形態を実現可能な、相応しい計算機環境（４００）の一般化した例を示す。計算機環境（４００）は、本発明の使用または機能性の範囲に関してはいずれの限定をも示唆することを意図していない。本発明は、セルラ・デバイスまたはその他のユーザ機器、あるいはＧＧＳＮまたはその他のネットワーク・ノードというような、多様な汎用または特殊目的計算機環境において実現することができる。

図４を参照すると、計算機環境（４００）は、少なくとも１つの処理ユニット（４１０）とメモリ（４２０）とを含む。図４では、この最も基本的な構成（４３０）は、破線の中に含まれている。処理ユニット（４１０）は、コンピュータ実行可能命令を実行し、実プロセッサまたは仮想プロセッサでもよい。マルチ処理システムでは、多数の処理ユニットがコンピュータ実行可能命令を実行して処理能力を高める。メモリ（４２０）は、揮発性メモリ（例えば、レジスタ、キャッシュ、ＲＡＭ）、不揮発性メモリ（例えば、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュ・メモリなど）、またはこれら２つの何らかの組み合わせとすればよい。メモリ（４２０）は、許可トークンおよび１つ以上のフロー識別子によってバインド機構を実現するソフトウエア（４８０）を格納する。

計算機環境は、追加の構成を有することもできる。例えば、計算機環境（４００）は、ストレージ（４４０）、１つ以上の入力デバイス（４５０）、１つ以上の出力デバイス（２６０）、および１つ以上の通信接続部（４７０）を含む。バス、コントローラ、またはネットワークのような相互接続機構（図示せず）が、計算機環境（４００）の構成要素を相互接続する。通例では、オペレーティング・システム・ソフトウエア（図示せず）が、計算機環境（４００）内で実行するその他の動作環境を設け、計算機環境（４００）の構成要素のアクティビティを調整する。

ストレージ（４４０）は、着脱可能または固定のいずれでもよく、磁気ディスク、磁気テープまたはカセット、ＣＤ−ＲＯＭ、ＣＤ−ＲＷ、ＤＶＤ、あるいは情報を格納するために使用でき、計算機環境（４００）内部でアクセス可能な媒体であれば他のいずれでもよい。ストレージ（４４０）は、許可トークンおよび１つ以上のフロー識別子によってバインド機構を実現するソフトウエア（４８０）のコンピュータ実行可能命令を格納することができる。

１つ以上の入力デバイス（４５０）は、数値キーパッドのような接触式入力デバイス、キーボード、マウス、ペン、トラックボール、音声入力デバイス、走査デバイス、または計算機環境（４００）に入力を供給するその他のデバイスとすることができる。１つ以上の出力デバイス（４６０）は、ディスプレイ、プリンタ、スピーカ、ＣＤ−ライタ、または計算機環境（４００）からの出力を供給するその他のデバイスとすることができる。

１つ以上の通信接続部（４７０）は、通信媒体を通じて別の計算機エンティティへの通信を可能にする。通信媒体は、コンピュータ実行可能命令、オーディオまたはビデオ情報、あるいは変調データ信号におけるその他データといような情報を伝達する。変調データ信号とは、その特徴の１つ以上が、当該信号の中に情報をエンコードするように設定または変化されている信号のことを言う。限定ではなく、一例として、通信媒体は、無線周波数と共に用いられる有線またはワイヤレス媒体、電気的、光学的、赤外線、音響、またはその他のキャリアを含む。

本発明の説明は、一般的なコンピュータ読み取り可能媒体との関連で行うことができる。コンピュータ読み取り可能媒体は、計算機環境内部においてアクセス可能で、入手可能なあらゆる媒体のことである。限定ではなく、一例として、計算機環境（４００）では、コンピュータ読み取り可能媒体は、メモリ（４２０）、ストレージ（４４０）、通信媒体、およびこれらのいずれの組み合わせをも含む。

本発明の説明は、目的の実プロセッサまたは仮想プロセッサ上の計算機環境において実行するプログラム・モジュールに含まれるような、一般的なコンピュータ実行可能命令との関連で行うことができる。一般に、プログラム・モジュールは、ルーチン、プログラム、ライブラリ、オブジェクト、クラス、コンポーネント、データ構造等を含み、個々のタスクを実行するか、あるいは個々の抽象的データ形式を実現する。プログラム・モジュールの機能性は、必要に応じて、種々の実施形態においてプログラム・モジュール間で組み合わせたり、あるいは分割することもできる。プログラム・モジュールのコンピュータ実行可能命令は、ローカルまたは分散計算機環境内でも実行可能である。

念のため断っておくが、詳細な説明では、「要求」、「発生する」、および「変更する」といような用語を用いて、計算機環境におけるコンピュータの動作を説明する。これらの用語は、コンピュータが実行する動作についての上位抽象概念であり、人が行う活動と混同してはならない。これらの用語に対応する実際のコンピュータの動作は、実現例に応じて異なる。
ＩＩ．バインド機構
ここに記載するバインド機構は、ＧＧＳＮにおいてＰＤＰコンテキスト・ベアラをポリシー情報と関連付け、ＳＢＬＰの施行およびＱｏＳ相互作用を支援するものである。ＧＧＳＮにおけるポリシー情報は、ＩＰメディア・フローに基づく。バインド機構は、ＰＤＰコンテキスト・ベアラと関連がある１つ以上のＩＰメディア・フローを特定し、適用するポリシー情報を選択する際に、この特定情報を用いる。

バインド機構には、ＵＥが提供するバインド情報（例えば、許可トークンおよび１つ以上のフロー識別子）で、ＰＤＰコンテキスト上で搬送される１つ以上のＩＰメディア・フローを特定するには十分である。バインド機構は、ＳＩＰシグナリングおよびＰＤＰコンテキスト活性化／変更メッセージに１つの許可トークンを保持しつつ、ＩＰメディア・フローに基づいてリソースの許可および配分を可能にする。これによって、セッション毎に１つの許可トークンを用いればよいという利点、およびフロー毎にリソースの許可および配分ができるという利点が得られる。

ポリシー情報としては、例えば、Ｐ−ＣＳＣＦ／ＰＣＦは、セッションのＳＤＰ記述を用いて、当該セッションの許可を判断し、ポリシー情報は、ＩＰリソースに対する制約、ＩＰパケット・フロー、および（潜在的に）ＩＰ宛先を含む。許可されたセッションは、１つ以上のフロー許可を含むことができ、各フロー許可は、フローに対するＩＰフロー５タプル（即ち、ソース・アドレスおよびポート、宛先アドレスおよびポート、プロトコル）、フローに対して許可されたリソースの仕様、およびフローのホップ挙動毎に割り当てられるＤｉｆｆＳｅｒｖを識別するＤＳＣＰを保持する。

ＩＰポリシー施行は、ＩＰメディア・フローに基づくが、一方ＵＭＴＳベアラは、ＵＥからＧＧＳＮへのＰＤＰコンテキストに基づく。ＰＤＰコンテキストが活性化または変更され、ＳＢＬＰが有効である場合、ＧＧＳＮは、ＩＰメディア・フローに伴うポリシー情報を用いて、ベアラを許可する。ＵＥは、ＩＰメディア・フローのＰＤＰコンテキストへのマッピングを制御し、ＵＥは、ＧＧＳＮにバインド情報を提供して、ＰＤＰコンテキスト活性化／変更要求メッセージのためにポリシー情報を正しく特定できるようにする。そうでないと、ＧＧＳＮは、ベアラを許可するために必要なポリシー情報を特定する十分な情報を有することができない。

これまで、ＩＥＴＦ ＳＩＰワーキング・グループは、ＳＤＰ記述におけるＩＰメディア毎の許可トークンを用いて、ＵＥがＧＧＳＮにバインド情報として与えることができるのはどれか検討していた。アーキテクチャに関しては正しいが、この手法では、ＳＤＰを変更し、ＰＣＦ、ＧＧＳＮ、およびＵＥ間でより多くの情報を送る必要がある。

対照的に、ここに記載するバインド機構では、ＩＰメディア・フローを特定するには、ＳＤＰ記述におけるこれらの順序を用いる。例えば、最初のメディア・フロー（ＳＤＰ記述において「ｍ＝」で始まるラインによって特定する）はフロー１であり、２番目のフローはフロー２等とする。Ｐ−ＣＳＣＦ／ＰＣＦおよびＵＥ双方ともＳＤＰ記述を有するので、これらは一貫した方法でフローを特定する。Ｐ−ＣＳＣＦ／ＰＣＦからの許可情報、およびＵＥからのバインド情報は、双方とも１つ以上のメディア・フローを特定することができる。

図５および図６は、許可トークンおよび１つ以上のＩＰメディア・フロー識別子を用いたバインド機構の技法（５００、６００）を示す。図５および図６は、概略的に、バインド機構のタイミングを示し、実際のタイミングは基礎をなすプロトコル（例えば、ＳＩＰおよびＰＤＰ）、ネットワーク等に左右される。

図５および図６を参照すると、ＳＩＰシグナリングの間、Ｐ−ＣＳＣＦ／ＰＣＦは許可トークンおよびＳＤＰ記述をＵＥに送信する（６１０）。ＵＥは、許可トークンおよびＳＤＰ記述を受信する（５１０）。

次に、ＵＥはＰＤＰコンテキスト要求を送信する（５２０）。ＰＤＰコンテキストを活性化／変更する場合、ＵＥは許可トークンをバインド情報として要求に含ませる。メディア・フローを正しくＰＤＰコンテキストにマップするためには、ＵＥは、ＳＤＰ記述にしたがって、１つ以上のフロー識別子も含ませなければならない。（許可トークンは、ＳＩＰシグナリングの間にＰ−ＣＳＣＦ／ＰＣＦによってＵＥに送られ（６１０）、フロー識別子は、ＳＤＰ内の一連のメディア・フローにしたがってＵＥによって導き出されている。）フロー識別子は、少数のビットだけで済むので、エアリンクの挙動に及ぼす影響は最少である。即ち、バインド情報は、ＰＤＰコンテキスト活性化／変更メッセージに含まれ、ＰＤＰコンテキスト・ベアラをポリシー情報と関連付ける。ＰＤＰ構成オプション・パラメータ（ＰＤＰコンテキスト活性化／変更要求において通知されるオプションのパラメータ）が、この目的のために用いられる。あるいは、ＰＤＰコンテキストのトラフィック・フロー・テンプレート・パラメータのような、別のパラメータを用いる。

許可トークンは、ＡＰＮに関連するＰＤＰコンテキスト全体にわたって一意であり、メディア許可のＳＩＰ拡張に関するＩＥＴＦ仕様に準拠する。
フロー識別子は、ＳＩＰセッションに伴うＩＰメディア・フローを特定する。前述のように、フロー識別子は、ＳＤＰ記述におけるメディア・フローの順序に基づくことができる。この場合、フロー識別子を許可トークンと組み合わせれば、ＩＰメディア・フローを一意に特定するには十分である。何故なら、フロー識別子は、許可トークンに関して解釈されるからである。

ＱｏＳおよびポリシー情報をＰＣＦから「引き出す」ためには、ＧＧＳＮが、用いるＰＣＦのアドレスも許可トークンによって決定できるようにするとよい。
ＧＧＳＮは、ＰＤＰコンテキスト要求を受信し（６２０）、ＰＤＰコンテキスト要求を処理する。例えば、ＧＧＳＮは、含まれるバインド情報を用いて、ＰＤＰコンテキスト・ベアラと関連がある１つ以上のＩＰメディア・フローを特定し（６３０）、ＰＣＦにポリシー情報を問い合わせ（６４０）、バインド情報によって特定された１つ以上のＩＰメディア・フローに適用し、１つ以上のＩＰメディア・フローと関連がある、受信したポリシー情報を用いて、ポリシー情報に関して適切であれば、ベアラを許可する（６５０）。

ＳＩＰセッション変更の結果、メディア・フローの追加または削除のような変化をＳＤＰ記述に生ずる可能性がある。（例えば、一実現例では、メディア・フローを削除すると、対応する「ｍ」ラインはなおもＳＤＰ記述の中にあるが、「ｍ＝０」に設定される。対応して、この削除されたフローに対して許可されたＱｏＳリソースもＰＣＦにおいて０に設定される。新たなメディア・フローが追加されると、これは既存のＳＤＰ記述の終端に追加される。）Ｐ−ＣＳＣＦ／ＰＣＦは、ＳＤＰ記述が変化した場合、新たな許可トークンを発行することができる。ＳＩＰセッション変更の結果として、ＰＤＰコンテキストに関連するリソースが増大した場合、ＵＥは古い（または新しい）許可トークンおよびフロー識別子と共に、ＰＤＰコンテキストの変更を送る。

以上、記載した所要の実施形態を参照しながら、本発明の原理について説明し例示したが、記載した実施形態は、このような原理から逸脱することなく、その構成および詳細において変更が可能であることは認められよう。尚、ここに記載したプログラム、プロセス、または方法は、特に指示がない限り、いずれの特定的な形式の計算機環境にも関係付けられたり、限定されたりはしないことは言うまでもない。ここに記載した教示にしたがって、種々の形式の汎用計算機環境または特殊計算機環境を用い、それに応じた動作を行うこともできる。記載した実施形態において、ソフトウエアとして示した要素は、ハードウエアでも実現可能であり、その逆も可能である。

本発明の原理は多くの実施形態にも適用可能であることに鑑み、特許請求の範囲およびその均等物の範囲および精神に該当し得るあらゆる実施形態を、本発明として主張する。

図１は、従来技術によるベアラ・サービス層状アーキテクチャの図である。 図２は、従来技術によるネットワーク・アーキテクチャの簡略化した例の図である。 図３は、従来技術による端末間ＩＰ ＱｏＳのためのＱｏＳ管理機能を示す図である。 図４は、記載する実施形態を実現可能な、相応しい計算機環境のブロック図である。 図５は、許可トークンおよび１つまたは複数のＩＰメディア・フロー識別子を用いたバインド機構のための技法のフロー・チャートである。 図５は、許可トークンおよび１つまたは複数のＩＰメディア・フロー識別子を用いたバインド機構のための技法のフロー・チャートである。

Claims (28)

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. 請求項２３記載のコンピュータ読み取り可能媒体において、前記方法が、更に、
    前記許可トークンが示すポリシー情報を要求するステップを含む、コンピュータ読み取り可能媒体。

Images