JP2008507208A - パケットデータフィルタリング - Google Patents

Abstract

【解決手段】通信しているノードが、異なる通信モードであると仮定し、データトラフィック制御のためのモニタリング中継点を通じてパケットデータが送られるパケットデータ通信システムにおいて、データ制御及びモニタリング機能を実行するためのデータフィルタを、モニタリング中継点が単純にセットアップできるようにするために、異なる通信モードがモニタリング中継点に直接送られる。
【選択図】 図３

Description

本発明は、一般に、パケットデータ通信に関し、特に、パケットデータ通信中におけるパケットデータのモニタリング及び制御に関する。

ネットワークによるグローバルな相互接続によって、情報が地理的な距離に関係なく速やかにアクセスされるようになる。図１は、参照番号２０によって一般に単にインターネットと称しているネットワークのグローバルな接続の簡略系統図を示している。インターネット２０は、本質的に、互いに接続された異なるレベルの階層を持つ多くのネットワークである。インターネット２０は、ＩＥＴＦ（インターネット技術特別調査委員会）によって発布されたＩＰ（インターネットプロトコル）の下で機能する。ＩＰの詳細は、ＩＥＴＦによって公開されたＲＦＣ（Request For Comments：コメント要求）７９１で見うけられる。

インターネット２０には、ネットワークサイズに依存してＬＡＮ（ローカルエリアネットワーク）又はＷＡＮ（ワイドエリアネットワーク）と呼ばれる様々な個々のネットワークが接続されている。そのようなネットワーク２２，２４，２６のうちのいくつかが図１に示される。

ネットワーク２２，２４，２６の各々では、それに接続された、及び互いに通信している様々な設備の部分が存在しうる。その一例の名称を幾つか挙げると、コンピュータ、プリンタ、及びサーバである。設備部分はそれぞれ、一般にＭＡＣ（媒体アクセス制御）と呼ばれるユニークなハードウェアアドレスを持っている。ＭＡＣアドレスを備えた設備部分はしばしばノードと呼ばれる。ノードがインターネット２０によって、それ自身のネットワークを越えて通信する場合、そのノードにＩＰアドレスを割り当てる必要がある。

ＩＰアドレスの割り当ては手動でも自動でもなされうる。例えば、ネットワークアドミニストレータは、ＩＰアドレスを手動で割り当てることができる。しかし、多くの場合、ＩＰアドレスは自動的に割り当てられる。例えば、ＬＡＮでは、ＩＰアドレスは、ノードのＬＡＮの内部に存在するＤＨＣＰ（Dynamic Host Control Protocol：動的ホスト制御プロトコル）サーバ（図示せず）と呼ばれるサーバによって割り当てることができる。更に、無線技術をサポートするＷＡＮでは、ＩＰアドレスは、自動かつ遠隔から割り当てることができる。

図１に戻って、一例として、ネットワーク２２内のノード３０が、ネットワーク２４内の別のノード３４へデータパケットを送ることを試みると仮定する。ＩＰの下では、各データパケットは、ソースアドレスと宛先アドレスとを持つ必要がある。この場合、ソースアドレスは、ネットワーク２２内のノード３０のアドレスである。宛先アドレスは、ネットワーク２４内のノード３４のアドレスである。そのような方式で機能するので、ノード３０，３４は、単純ＩＰ通信モードの下で通信していると言われる。ここでは、ノード３０とノード３４との両方が、データパケットの交換に際して自己のＩＰアドレスを用い、ＩＰに従う。

無線技術の到来によって、ノードは、オリジナルに登録したネットワークから、別のネットワークに移動することが可能となる。例えば、再び図１を参照すると、ノード３０は、恒久的にネットワーク２２に接続されているのではなく、例えばＰＤＡ（パーソナルデバイスアシスタント）、セルラ電話、又はモバイルコンピュータのような無線デバイスでありえる。無線ノード３０は、そのホームネットワーク２２の境界を越えて移動することができる。したがって、ノード３０は、そのホームネットワーク２２から、外のネットワーク２６へローミングするかもしれない。そのようなシナリオの下では、ノード３０に割り当てられたオリジナルのアドレスは、ノード３０にもはや適用可能ではないだろう。そのため、ノード３０のそのアドレスに向けられたデータパケットは、ノード３０に到達できないかもしれない。

ＩＥＴＦによって明記されたモバイルＩＰ（モバイルインターネットプロトコル）セットは、ノード移動問題に取り組むように意図されている。ＩＥＴＦによって公表されたＲＦＣ ２００２に従うと、ホームネットワーク２２から離れ、別のネットワークにローミングした場合にはいつでも、ノード３０は、ＣｏＡ（Care-of Address）と略される「気付アドレス」（care-of address）が割り当てられる。

ＲＦＣ ２００２の下では、２つのタイプのＣｏＡ、すなわちＦＡ ＣｏＡ（Foreign Agent Care-of Address：外部エージェント気付アドレス）と、ＣＣｏＡ（Co-located Care of Address：コローケート気付アドレス）とがある。

ＦＡ ＣｏＡは本質的に、ノード３０が位置する外部ノード内の指定のサーバであるＦＡ（外部エージェント）のアドレスである。ＦＡ ＣｏＡの使用は、ＩＰｖ４において適用可能である。

ＣＣｏＡは、外部ネットワークによってノード３０に割り当てられる個別であるが一時的なアドレスである。ＣＣｏＡの使用は、ＩＰｖ４とＩＰｖ６との両方において適用可能である。

何れの場合も、ノード３０は外部領域にある場合にはいつでも、ノード３０はＣｏＡを、ＦＡ ＣｏＡ又はＣＣｏＡに登録しなければならない。これによって、ホームネットワーク２２は常に、ノード３０の行方を知ることができる。登録後、ＣｏＡは、ホームネットワーク２２のＨＡ（ホームエージェント）２５と呼ばれる指定のサーバによって維持されたルーティングテーブルに格納される。

例示のために２、３の例を挙げる。

ＦＡ ＣｏＡの場合、ノード３０が外部ネットワーク２６へローミングすると仮定する。外部ネットワーク２６の領域に到着すると、ノード３０は、外部ネットワーク２６から、ノード３０がこの外部領域に存在していることをノード３０に通知する広告メッセージを受信する。この広告メッセージから、ノード３０は、外部ネットワーク２６のＦＡ ３６のアドレスを知る。そして、ノード３０は、ホームネットワーク２２内のＨＡ ２５にＦＡ ＣｏＡを登録する。

例えば、外部ネットワーク２６内のノード３０が、ネットワーク２４内のノード３４のアドレスを知っており、ノード３４にデータパケットを送る場合、このデータパケットは、直接送られる。すなわち、データパケットでは、ＩＰに従って、ソースアドレスが、ノード３０のＨｏＡに設定され、宛先アドレスが、ネットワーク２４内のノード３４のアドレスに設定される。データパケットの方向は、図１中に示されるデータ経路３８として示される。

逆方向のデータトラフィックに関しては、そのように簡単ではない。逆方向のデータ経路では、ネットワーク２４内のノード３４が、ＩＰに従って、上述したように外部ネットワーク２６内のノード３０にデータパケットを送ることを試みる場合、ソースアドレスと宛先アドレスとの両方がデータパケット内で特定されねばならない。この場合、ソースアドレスは、ネットワーク２４内のノード３４のＩＰアドレスである。宛先アドレスに関しては、ノード３０からの更新通知が無いと、ノード３４は、ノード３０のＨｏＡのみしか知らず、ノード３０のＦＡ ＣｏＡは分からない。したがって、宛先アドレスは、ノード３０のＨｏＡに設定されるだろう。しかしながら、データパケットがホームネットワーク２２に達した時、ノード３０のＦＡ ＣｏＡが、ホームネットワーク２２内のＨＡ ２５のルーティングテーブルに格納されるので、ネットワーク２２のＨＡ ２５は、受信したデータパケットを、格納されたＦＡ ＣｏＡとともにカプセル化し、それを外部ネットワーク２６内のノード３０に送る。すなわち、カプセル化されたデータパケットは、宛先アドレスとしてＦＡ ＣｏＡを利用する。外部ネットワーク２６が、このカプセル化されたデータパケット一旦受信すると、ＦＡ ３６は、カプセル化されたＦＡ ＣｏＡを取り除き、オリジナルのパケットを、モバイルノード３０に配信する。このデータパケットの経路は、図１のデータ経路４０として示される。

例えば経路３８，４０のようなデータ経路は、実際には、インターネット２０を何度も通過しうることにも留意されるべきである。図１を不明瞭にせずに明確にするために、これら経路は単に、例えばＨＡ ２５及びＦＡ ３６のような関連サーバを通過するものとして示されている。すなわち、データ経路３８，４０は、図１に示すような論理的な経路として示される。

上述のような方式で動作するので、モバイルノード３０は、ＦＡ ＣｏＡを使用して、モバイルＩＰトンネルモードの下で、対応するノード３４と通信していると言われている。

ＣＣｏＡの場合に関しては、ノード３０がホームネットワーク２２から離れてローミングする場合、ノード３０は、ＦＡ ＣｏＡを要求する代わりに、外部ネットワークからＣＣｏＡを要求することができる。ネットワーク２６が、ＴＩＡ／ＥＩＡ（米国電気通信工業会／電子工業企業体協会）によって発布されたｃｄｍａ２０００規格のような無線技術をサポートするＷＡＮである場合、ＣＣｏＡは、例えば、ＰＤＳＮ（Packet Data Serving Node）４１とモバイルノード３０との間のＰＰＰ（ポイントトゥポイントプロトコル）を経由して外部ネットワーク２６によって遠隔から要求され、割り当てることが可能である。ＰＤＳＮ ４４は、基本的には、ネットワーク２６の無線部分のデータトラフィックを取り扱い、処理するネットワーク２６内サーバである。更に、ＰＤＳＮ ４１及びＦＡ ３６は、個別である代わりに、１つのエンティティとして統合することも可能であることが注目されるべきである。しかしながら、外部ネットワーク２６によるＣＣｏＡの割当以外にも、ノード３０は、上述したように、ＦＡ ３６のような外部エージェントの全ての機能を実施する。更に、モバイルノード３０は、ホームネットワーク２２にＣＣｏＡを登録する必要がある。

例えば、ネットワーク２４内のノード３４に対応するために、ノード３０は、２つのレイヤのアドレスを有するデータパケットを送り出す。外部レイヤでは、ソースアドレスはＣＣｏＡに設定され、宛先アドレスはＨＡ ２５に設定される。内部レイヤでは、ソースアドレスはノード３０のＨｏＡであり、宛先アドレスは、外部ネットワーク２４内のノード３４のアドレスである。ローミングしているノード３０からのデータパケットを受信すると、ＨＡ ２５は、外部アドレスレイヤを取り除き、内部アドレスレイヤとともにデータパケットをノード３４に送る。このデータパケットの論理的経路は、図１のデータ経路４２として示される。

逆方向のデータ経路、すなわち、ノード３４がノード３０にデータパケットを送る場合には、データパケットは、ノード３４に設定されたソースアドレスと、ノード３０のＨｏＡに設定された宛先アドレスとを有する１つのアドレスレイヤのみを持つ。データパケットを受信すると、ＨＡ ２５は、宛先アドレスであるＣＣｏＡと、ソースアドレスであるＨＡ ２５のアドレスとともにデータパケットをカプセル化し、このカプセル化されたデータパケットをノード３０に送る。ノード３０は、ＦＡ ３６を通過することなく、独力でカプセルの解除（de-encapsulating）を行う。このデータパケットの方向は、図１中のデータ経路４４として示される。

上述のような方法で動作するので、ローミングノード３０は、ＣＣｏＡを使用して、モバイルＩＰトンネルモードの下で、対応するノード３４と通信していると言われている。

例えば、モバイルノード３０が、更に別のネットワークへ移動する場合、ＣＣｏＡを使用して、モバイルＩＰトンネルモード経由で通信することの利点は、モバイルノード３０は、対応するノード３４に対して何ら更新通知を送る必要がないことである。モバイルノード３０は、ホームネットワーク２２を用いて行先を常に更新するので、対応するノード３４によって送られたデータパケットは、常にＨＡ２５に経路付けられる。一方、ＨＡ２５は、このデータパケットを、モバイルノード３０の最も現在の位置に再ルーティングする。

ＣＣｏＡを使用してモバイルＩＰトンネルモードによって動作することは、図１の曲がりくねった論理的データ経路４２から分かるように、相当な規模のデータトラフィック迂回路を含む。

遠隔ネットワーク２４に地理的に近いモバイルノード３０が、ホームネットワーク２２から遠く離れている外部ネットワーク２６へローミングすると仮定する。外部ネットワーク２６内のモバイルノード３０が、対応するネットワーク３４と通信する場合、近くの対応するノード３４に到着する前に、遠いホームネットワーク２２を通ってデータトラフィックがループすることはリソースの非能率的な使用であろう。

そうではなくて、モバイルＩＰの下では、別の通信モードを利用することが可能である。このモードを実行するために、モバイルノード３０が新たな外部領域に達した場合、ホームネットワーク２２を用いてその行方を更新することに加えて、モバイルノード３０は、例えば対応するノード３４のような任意の対応するノードを用いて、新しい場所を更新する必要がある。

この通信モードの下で動作するので、モバイルノード３０と、対応するノード３４との間のデータトラフィックは、直接交換される。特に、データパケットが、モバイルノード３０によって、対応するノード３４に送られる場合、ソースアドレスは、モバイルノード３０のＣＣｏＡに設定され、宛先アドレスは、外部ネットワーク２４のノード３４のアドレスに設定される。逆方向のデータトラフィックに関しては、各データパケットについては、対応するノード３４が、そのアドレスをソースアドレスとして、モバイルノード３０のＣＣｏＡを宛先アドレスとして使用する。データパケットの論理的経路は、図１のデータ経路４６，４８として示される。上述したような方式で動作するので、モバイルノード３０は、ＣＣｏＡを用いたモバイルＩＰ経路最適モードの下で、対応するノード３４と通信していると言われている。

様々な理由により、非常に頻繁に、ノードの異なる通信モードを確認しモニタリングする必要がある。例えば、モバイルノード３０及び対応するノード３４がＶｏＩＰ（ボイスオーバＩＰ）セッションである場合、この場合、モバイルノード３０と対応するノード３４である参加パーティが許可されることが確かである必要がある。ＶｏＩＰセッションが料金ベースであれば、パーティ間のデータトラフィックが、課金処理の目的でモニタリングされる必要がある。無許可のデータトラフィックは、単純に阻まれるか拒絶される。データパケットフォーマットは、異なる通信モードの下で異なる。これまで、データトラフィックのモニタリングは、先ず、各データパケットの検査がなされ、次にその通信モードが決定され、関連する情報が抽出され、その後、データパケットの通過を許可又は拒否する適切な基準を設定することによりなされている。そのような実行は、データトラフィックに追加される付加的なレイテンシのみならず、リソースを浪費する。

従って、パケットデータ通信のためのよりよいデータトラフィックモニタリングを提供する必要がある。
米国特許出願、代理人整理番号０４０７２７「Bearer Control of Encrypted Data Flows in Packet Data Communications」 "3GPP2 MMD Service Based Bearer Control Document, Work in Progress," 3GPP2 X.S0013-012 "IP Multimedia Call Control Protocol Based on SIP and SDP), Stage 3: 3GPP2-X.S0013-0004

本特許出願は、２００４年７月１５日に出願され、本明細書の譲受人に譲渡され、本明細書に参照によって明確に組み込まれる「Service Based Bearer Control for Mobile IP Co-located Care of Address」と題された米国仮出願６０／５８８，６６４号の優先権を主張する。

本出願は、代理人整理番号０４０７２７を有し、それをもって出願され、本明細書の譲受人に譲渡され、本明細書に参照によって明確に組み込まれる「Bearer Control of Encrypted Data Flows in Packet Data Communications」と題された米国特許出願（特許文献１）に関連する。

通信ノードが異なる通信モードを仮定するパケットデータ通信システムにおいて、トラフィックパケットデータの効率的で正確なモニタリングが必要とされる。データトラフィックモニタリングのための基準のセットに到達するための必要な情報を導出するため、各データパケットを検査する代わりに、本発明の典型的な実施形態に従って、必要な情報が、データ制御及びモニタリング機能を実行するためのデータフィルタを設定するために、モニタリング中継点に直接送られる。

典型的な実施形態では、モバイルノードは、モバイルノードが、最初のシグナリング処理の間、各データパケット内で必要なその他の情報とともに、選択された通信モードを、モニタリング中継点に送る。対応するノードは、同様の情報を有する応答シグナリング処理で応答する。設定したように動作するので、モニタリング中継点は、比較的迅速かつ効率的にデータフィルタを設定し、データ制御及びモニタリング機能を実行することができる。

これら及び別の特徴や利点は、同一符号が同一部分を参照する添付図面と一緒に用いられた場合、以下の詳細記述から当業者に明らかになるであろう。

次の記載は、いかなる当業者であっても、本発明の活用及び利用を可能にするために示される。以下の記載では、説明の目的のために、詳細が述べられる。当業者であれば、本発明は、これら具体的な詳細を用いずとも実現されうることが理解されるべきである。他の例では、本発明の記述を、不要な詳細で不明瞭にしないために、周知の構造及び処理が詳述される。したがって、本発明は、示された実施形態に限定されるのではなく、本明細書に開示の原理及び特徴に一致した最も広い範囲が与えられるべきであることが意図されている。

以下に述べる実施形態は、第３世代パートナシッププロジェクト（３ＧＰＰ：the 3rd Generation Partnership Project）及び第３世代パートナシッププロジェクト２（３ＧＰＰ２：the 3rd Generation Partnership Project 2）によって発布されたＩＭＳ／ＭＭＤ（IP Multimedia Subsystem/Multimedia Domain）規格に従って動作可能である。ＩＭＳ／ＭＭＤの総括論議は、「3r Generation Partnership Project: Technical Specification Group Services and System Aspects, IP Multimedia Subsystem (IMS), Stage 2」、３ＧＰＰ ＴＳ ２３．２２８；「3rd Generation Partnership Project: Technical Specification Group Core Network, End-to-End Quality of Service (QoS) Signaling Flows」、３ＧＰＰ ＴＳ ２９．２０８；「IP Multimedia System, Stage 2」、Ｘ．Ｓ００１３−００２及び３ＧＰＰ２ Ｘ．Ｐ００１３−０１２とそれぞれ題された公開文書で見ることができる。

ＩＭＳは、ｃｄｍａ２０００、ＷＣＤＭＡ（広帯域符号分割多元接続）、ＧＰＲＳ（汎用パケット無線システム）、および様々な他のＷＡＮのような種々様々の規格において適用可能である。

本発明の典型的な実施形態を概略的に示す図２を参照されたい。全体システムは、一般に、イントラネット又はインターネットのようなバックボーンネットワーク５２を含む参照符号５０によって一般に示される。

一例として、図２に示すように、このバックボーンネットワーク５２には、他のネットワークの中でも、ＨＮ（ホームネットワーク）５４、ＦＮ（外部ネットワーク）５６、及びＲＮ（遠隔ネットワーク）５８が接続されている。

ＨＮ ５４には、ＨＡ（ホームエージェント）６２が存在する。ＨＡ ６２は、上り及び下り（inbound and outbound）経路について、ＨＮ ５４内のデータトラフィックを管理し、ＨＮ ５４のデータトラフィックを制御する義務を負う。ＨＮ ５４が無線技術をサポートする場合、インストールされＰＤＳＮ（Packet Data Serving Node）６４に接続されたＲＡＮ（Radio Access Network）５５が通常存在する。例えば、ＲＡＮ ５５がｃｄｍａ２０００規格の下で機能する場合、ＲＡＮ ５５は一般に少なくとも１つのＢＳＣ（基地局コントローラ）と複数のＢＳ（基地局）とを含む。ＰＤＳＮ ６４は、本質的に、バックボーンネットワーク５２とＲＡＮ ５５との間のアクセスゲートウェイである。

様々なＩＭＳ／ＭＭＤ機能及び特徴を実行するために、サービスプロバイダは、ＨＮ ５４に異なるサーバをインストールした。そのようなサーバの例は、Ｐ−ＣＳＣＦ（Proxy Call State Session Function：プロキシコール状態セッション機能）７０、およびＳ−ＣＳＣＦ（Serving Call State Session Function：サービングコール状態セッション機能）７２を含んでいる。これらの機能の機能的な記載は、システム５０の運用上の記載と共に後述する。

上述したノードに加えて、ＨＮ ５４内には他のノードもあるが、明瞭さの目的のために示していない。そのようなノードは、様々な規模のコンピュータ、プリンタ、及びモバイル又は非モバイルでありうるその他任意のデバイスでありうる。

図２には、バックボーンネットワーク５２に接続されたＦＮ ５６及びＲＮ ５８が示される。更に説明を簡潔かつ容易にするために、ＦＮ ５６及びＲＮ ５８は、ＨＮ ５４と幾分類似するように例示されている。ＦＮ ５６及びＲＮ ５８は、用途に応じて大幅に異なって構成されうることが認識されるべきである。したがって、この場合、ＦＮ ５６は、とりわけ、ＦＡ（外部エージェント）６６、ＲＡＮ ７６、ＰＤＳＮ ６８、Ｐ−ＣＳＣＦ ７１、及びＰＣＲＦ（Policy and Charging Rules Function：ポリシー及び課金ルール機能）７５をも含んでいる。同様に、ＲＮ ５８は、ＰＤＳＮ ７８、Ｐ−ＣＳＣＦ ８０、Ｓ−ＣＳＣＦ ８２、及びＰＣＲＦ ８４を含んでいる。

図２では、ＦＮ ５６内のＦＡ ６６及びＰＤＳＮ ６８は、個別のエンティティとして示されていることに留意されたい。しばしば、ＦＡ ６６及びＰＤＳＮ ６８は、１つのユニットとして統合される。

システム５０内には、ＭＮ（モバイルノード）６０が存在する。ＭＮ６０は、ＨｏＡ（ホームアドレス）を用いて、ＨＮ ５４内のＨＡ ６２に元々登録されている。ＭＮ ６０は、例えばＦＮ ５６のような他の外部ネットワークに移動することができ、ＦＮ ５６又はモバイルＩＰ下の他のネットワークを経由してバックボーンネットワーク５２へのアクセスを得ることができる。例えば、ＭＮ ６０は、実際には、ＰＤＡ（パーソナルデジタルアシスタント）、ラップトップコンピュータ、又はモバイル電話の形態とすることができる。

ＭＮ ６０がＦＮ ５６内にローミングしていると仮定する。この具体的な例では、ＭＮ ６０のユーザが、ＲＮ ５８内のＣＮ（Correspondent Node：対応ノード）９０を操作する別のユーザとのビデオ会議セッションを持ちたいと仮定する。ノード９０は、モバイル又は非モバイルになりえる。

ＦＮ ５６の領域に到着すると、ＭＮ ６０は、ＦＮ ５６による広告によって、ＦＡ ６６のアドレスを獲得しうる。そして、ＨＡ ６２がＭＮ ６０の場所を追跡できるように、ＭＮ ６０は、ＨＮ ５４内のＨＡ ６２にＦＡ ＣｏＡを登録する。あるいは代案として、ＭＮ ６０は、ＦＡ ６６からＣＣｏＡを要求するかもしれない。そして、ＨＡ ６２がＭＮ ６０とのコンタクトの維持を可能にするために、ＭＮ ６０は、同じ理由で、ＨＡ ６２にＣＣｏＡを登録する。

何れの通信トラヒックをも確立する前に、ＭＮ ６０は、シグナリング処理を経る必要がある。この目的を達成するために、ＭＮ ６０は、後述するように、中継点を経由してＣＮ ９０に案内メッセージを送る。同様に、ＣＮ ９０は、応答シグナリング処理を通じて、この案内メッセージをアクノレッジする必要がある。

この例では、ＭＮ ６０は、ＨＮ ５４内のＳ−ＣＳＣＦ７２を含むＳＩＰ（Session Initiation Protocol：セッション開始プロトコル）ネットワークへのアクセスのために、ＨＮ ５４内のＨＡ ６２によってもともと割り当てられたＨｏＡを使用して、ＨＮ ５４内のＳ−ＣＳＣＦ ７２に登録する。

ＭＮ ６０は、その後、ＨＮ ５４内のＰ−ＣＳＣＦ ７０へＳＩＰ案内メッセージを送信する。実際の動作においては、その他全てのデータトラフィックでもよくあるように、ＳＩＰ案内メッセージは、Ｐ−ＣＳＣＦ ７０に到着する前に、先ずＲＡＮ ７６、ＰＤＳＮ ６８、ＦＡ ６６、バックボーンネットワーク５２、及びＨＡ ６２を通ることが注目されるべきである。更に、当該技術で良く知られているように、データトラフィックは、システム５０内を移動する搬送波による電気信号の形態をとる。上述同様な方式で明確化を図るために、データトラフィックは、単純に論理的な経路として例示される。すなわち、以下の記載では、特に強調されないのであれば、データトラフィックの論理的な経路のみが記載される。

会議セッションを始めるために、代案として、ＭＮ ６０が、ＦＮ ５６内のＰ−ＣＳＣＦ ７１へＳＩＰ案内メッセージを送信することができることもまた注目されるべきである。すなわち、シグナリングのためにＨＮ ５４内のＰ−ＣＳＣＦ ７０を用いる代わりに、代替案として、ＭＮ ６０は、ＦＮ ５６内のＰ−ＣＳＣＦ ７１を用いることができる。説明における一貫性および明瞭さのために、以下の記載では、ＨＮ ５４内のＳＩＰネットワークは、シグナリング処理用に使用される。

図２に戻り、ＳＩＰ案内メッセージは、本質的に、要求されたビデオ会議セッションの適切な実行のための基本的要件を記述するＳＤＰ（Session Description Protocol：セッション記述プロトコル）と呼ばれる記述部分を含む。例えば、ＳＤＰには、ＭＮ ６０のＩＰアドレスとポート番号、及びセッションのコデック仕様が含まれる。より重要なことは、この実施形態では、ＳＤＰが、ベアラトラフィックのためのＭＮ ６０によって仮定される通信のモードを含んでいる。ベアラトラフィックは、会議セッションのオーディオ信号及びビデオ信号のコンテンツフローである。

ＨＮ ５４内のＰ−ＣＳＣＦ ７０は、コールセッション管理の義務を負うノードである。ＳＩＰ案内メッセージを受信すると、Ｐ−ＣＳＣＦ ７０は、ＨＮ ５４内のＳ−ＣＳＣＦ ７２へＳＩＰ案内メッセージを転送する。Ｓ−ＣＳＣＦ ７２は、受諾を要求するためにＲＮ ５８にＳＩＰ案内メッセージを送信する。

Ｓ−ＣＳＣＦ ７２によるセッションの承認、およびＲＮ ５８内のＣＮ ９０による会議セッションの受諾があると、Ｐ−ＣＳＣＦ ７０は、例えば課金規則、許可されたＱｏＳ（Quality of Service：サービス品質）、及びフロー識別子のようなポリシー関連情報をＨＮ ５４内のＰＤＳＮ６８に送る。

同時に、すなわち、ＣＮ ９０による受諾の後に、ＭＮ ６０は、ベアラトラフィックを設定するために、ＴＦＴ（Traffic Flow Template：トラフィックフローテンプレート）を、要求されたＱｏＳとともにＦＮ ５６内のＰＤＳＮ ６８に送る。

その後、ＰＤＳＮ ６８は、前述したポリシー関連情報、すなわち、ＦＮ ５６内のＰＣＲＦ７５からの会議セッションのための許可されたＱｏＳ、課金規則、及びフレー識別子を要求する。その後、ＰＣＲＦ ７５は、ＨＮ ５４内のＰＣＲＦ ７４への要求を中継する。ＰＣＲＦ ７５によって許可されたどんなパラメータも、ある命じられたポリシーに適合していなければならない。そのようなポリシーは、ＩＭＳ／ＭＭＤ規格の下で決定された規則、ベアラトラフィックの取り扱いに関連するＨＮ ５４とＦＮ ５６との間の合意のようなネットワーク間の具体的な合意、ＦＮ ５６にのみユニークなポリシーのようにネットワーク特有のポリシーを含む。要求された会議セッションが料金ベースの場合、ポリシーは、会計処理のためのある追跡手順を含む。結局、無許可のトラフィックは、詳しく後述するパケットデータフィルタリングと呼ばれる処理によってブロックされる。これらポリシーの施行は、ＩＭＳ／ＭＭＤ規格の下で、ＳＢＢＣ（Service Based Bearer Control：サービスベースベアラ制御）と呼ばれる。

ＳＢＢＣの運用上の詳細は、「3GPP2 MMD Service Based Bearer Control Document, Work in Progress」と題された文献3GPP2 X.S0013-012で見つけることができる。ＳＤＰの説明は、「IP Multimedia Call Control Protocol Based on SIP and SDP), Stage 3」と題された文献3GPP2-X.S0013-0004で見つけることができる。

ＦＮ ５６のＰＣＲＦ ７５は、課された全てのポリシーの決定のためにインストールされる。この決定プロセスでは、ＰＣＲＦ ７５は、ＨＮ ５４内のＰＣＲＦ ７４と、ＦＮ ５６内のＰＤＳＮ ６８との間にある。更に、ＰＤＳＮ ６８とＰＣＲＦ ７５との間には、Ｔｙインタフェース９２がある。図２に示すように、ＨＮ ６４のＰＣＲＦ ７４とＰ−ＣＳＣＦ ７０との間に配置されたＴｘインタフェース９４もある。前述のＴｙインタフェース及びＴｘインタフェースは、会議セッションとベアラトラフィックとの間のポリシー制御に使用される。ＴｙインタフェースとＴｘインタフェースとの詳細は、３ＧＰＰによって公開されている3GPP TS 23.107と、３ＧＰＰＳによって公開されている3GPP2 X.P0013-012で見ることができる。

図２に戻って、もしも許可されれば、ＳＩＰ案内メッセージ内で述べられた要求されたセッションパラメータは、ＨＮ ５４内のＰＣＲＦ ７４と、ＦＮ ５６内のＰＣＲＦ ７５とを経由して、Ｐ−ＣＳＣＦ ７０からＰＤＳＮ ６８へ渡される。

この実施形態では、ＣＮ ９０は、ＲＮ ５８によって割り当てられるＣＣｏＡを持つと仮定される。したがって、ＳＩＰ案内メッセージを受信すると、ＣＮ ９０は、ＳＩＰ ２００ ＯＫメッセージによって応答する。ＳＩＰ ２００ ＯＫメッセージは、基本的に、オリジナルのＳＩＰ案内メッセージのパラメータを再確認する。更に、この実施形態では、ＣＮ ９０は、ＳＩＰ ２００ ＯＫメッセージのＳＤＰ内に、ベアラトラフィックのためにＣＮ ９０によって試みられる通信モードを含んでいる。ＳＩＰ ２００ ＯＫメッセージは、ＳＩＰ案内メッセージと逆方向であるが同じデータ経路に従う。

その後、ＭＮ ６０は、オリジナルのＳＩＰ案内メッセージと同じデータ経路に沿ってアクノレッジメッセージ（ＡＣＫ）を送り戻すことによって、ＳＩＰ ２００ ＯＫメッセージの受信を確認する。

その後、ベアラトラフィックは、ＳＩＰ案内メッセージに記載されたような許可されたパラメータに従って、ＦＮ ５６内のＰＤＳＮ ６８によって確立される準備ができる。

ＩＭＳ／ＭＭＤ規格の下では、ベアラトラフィックは、ネットワークによって、ＳＢＢＣによってモニタリング及び制御される必要がある。この例では、以前に言及されたように、ＦＮ ５６内のＰＣＲＦ ７５によって指示されるＰＤＳＮ ６８は、ＳＢＢＣに対して、前述したようなポリシーに一致するように順応させる。

ＳＢＢＣ実施中に、各データパケットは、通過することを許可される前にスクリーンされねばならない。その処理は、パケットデータフィルタリングと呼ばれる。フィルタリング処理を実行する実装されるメカニズムは、フィルタと呼ばれる。パケットデータフィルタリングの詳細は、前述した「3GPP2 MMD Service Based Bearer Control Document, Work in Progress」と題された文献で見つけることができる。

特に、フィルタに基準を組み込む必要がある。とりわけ、各データパケットのソースアドレスおよび宛先アドレスを確認する必要がある。前述したように、各データパケットでは、アドレスのフォーマット及び構成は、異なる通信モードで異なる。例えば、モバイルＩＰトンネルモードの下の通信モードでは、各データパケットは、２つのレイヤアドレスを持っている。ＰＤＳＮ ６８は、フィルタを設定するために、各データパケットを検査して、異なるフォーマット及びアドレス構成を決定することができる。そのような検査及び決定プロセスは、かなりのリソースを含む。更に、それは比較的複雑な作業である。例えば、ＭＮ ３０が選択するのに利用可能な３つの通信モードがある。つまり、前述したように、単純ＩＰモード、モバイルＩＰトンネルモード、及びモバイルＩＰ経路最適モードがある。同じことは、ＣＮ ９０にも当てはまる。すなわち、ＣＮ ９０も、３つの通信モードのうちの１つを考えることができる。結果的に、ＰＤＳＮ ６８が決定し、取り扱う少なくとも全部で９セットのフィルタが存在すべきである。

この実施形態に従って、正しいセットのフィルタを見つけ出すために、ＰＤＳＮ ６８に対してデータパケットを検査する代わりに、ＰＤＳＮ ６８は、通信しているノードの通信モードが直接通知される。

したがって、前述したように、ＳＩＰ案内メッセージのＳＤＰ部分では、例えばソースアドレス及び宛先アドレス、及び宛先ポート等のような必要な情報の他に、ＭＮ ６０が、要求された通信セッションの間ＭＮ ６０によって行なわれる通信モードでＳＤＰを中に含んでいる。

同様に、ＳＩＰ ２００ ＯＫメッセージには、例えばソースアドレスと宛先アドレス、及び宛先ポート等のような必要な情報の他に、ＣＮ ９０が、ＣＮ ９０によって展開される通信モードでＳＤＰを中に含んでいる。

その後、ＰＤＳＮ ６８は、ＳＩＰ 案内メッセージ及びＳＩＰ ２００ ＯＫメッセージのそれぞれから、事前に、通信しているノードＭＮ ６０及びＣＮ ９０の通信モードを良好に知る。その後、ＦＮ ５６内のＲＣＲＦ ７５によって許可されると、適切なフィルタが設定される。その後、フィルタによってベアラトラッフィックが確立される。フィルタの基準を満たすデータパケットだけが、ＰＤＳＮ ６８を通過することが許される。一方、従わないデータパケットは、単に、振り落とされる。

上述したような方法で動作するので、ＳＤＰ内に直接的に含まれる通信モードの下、ＰＤＳＮは、要求されたビデオ会議セッションの間、ＳＢＢＣを実施するために、フィルタを速やかに設定することができる。ＳＢＢＣの実施は、ＭＮ ６０とＣＮ ９０との間のセッションが終了するまで連続的である。

上述したようなプロセスは、上図３のフローチャートに示される。

図４は、本発明に従って参照番号１２０で示されるモバイルノード装置のハードウェア実装の一部を概略的に示す。装置１２０は、例えば、ラップトップコンピュータ、ＰＤＡ、又はセルラ電話のような様々なデバイスに搭載あるいは組み込むことができる。

この装置１２０は、幾つかの回路を共にリンクする中央データバス１２２を備える。これら回路は、ＣＰＵ（中央処理装置）又はコントローラ１２４、受信回路１２６、送信回路１２８、及びメモリユニット１３０を含む。

受信回路１２６及び送信回路１２８は、図示されていないが、ＲＦ（無線周波数）回路に接続することができる。受信回線１２６は、受信した信号を、データバス１２２に出力する前に処理及びバッファする。一方、送信回路１２８は、データバス１２２からのデータを、デバイス１２０に出力する前に処理及びバッファする。ＣＰＵ／コントローラ１２４は、データバス１２２のデータ管理機能を実行し、更に、メモリユニット１３０の指示コンテンツの実行を含む一般的なデータ処理の機能を実行する。

メモリユニット１３０は、参照番号１３１によって一般に示される１セットの指示を含んでいる。この実施形態では、これら指示は、モバイルＩＰクライアント１３２及びＳＩＰクライアント１３４のような部分を含む。ＳＩＰクライアント１３４は、前述したように、本発明に従う指示セットを含む。モバイルＩＰクライアント１３２は、この装置１２０が、ＩＰ及びモバイルＩＰの下で、上述したように、例えば、様々な通信モードのために様々なタイプのアドレスを取得するように動作することを可能にする指示セットを含む。

この実施形態では、メモリユニット１３０はＲＡＭ（ランダムアクセスメモリ）回路である。典型的な指示部１３２，１３４は、ソフトウェアルーチン又はモジュールである。メモリユニット１３０は、揮発性又は不揮発性何れかのタイプである別のメモリ回路（図示せず）に接続することができる。代替例として、メモリユニット１３０は、例えばＥＥＰＲＯＭ（Electrically Erasable Programmable Read Only Memory）、ＥＰＲＯＭ（Electrical Programmable Read Only Memory）、ＲＯＭ（読み取り専用メモリ）、磁気ディスク、光ディスク、及び当該技術で周知のその他のような別の回路で構成することができる。

図５は、本発明に従ったＰＤＳＮ装置のハードウェア実装部分を示し、参照番号１４０によって示される。ＰＤＳＮ装置１４０は、いくつかの回路をともにリンクする中央データバス１４２を含む。この回路は、ＣＰＵ（中央処理装置）又はコントローラ１４４、受信回路１４６、送信回路１４８、及びメモリユニット１５０を含む。

受信回路１４６及び送信回路１４８は、ＰＤＳＮ装置１４０がリンクされるネットワークデータバス（図示せず）に接続することができる。受信回路１４６は、ネットワークデータバス（図示せず）からの受信信号を、内部データバス１４２にルーティングする前に処理及びバッファする。送信回路１４８は、データバス１４２からのデータを、装置１４０から送り出す前に、処理及びバッファする。ＣＰＵ／コントローラ１４４は、データバス１４２のデータ管理、及びメモリユニット１５０の指示コンテンツの実行を含む一般的なデータ処理の機能のためのデータ管理の義務を実行する。

メモリ回路１５０は、参照番号１５４によって一般に示される１セットの指示を含む。この実施形態では、これら指示は、ＰＤＳＮ機能部１５６及びＳＢＢＣ機能部１５８を含む。メモリ回路は、上述するようなタイプのメモリ回路からなるので、重複説明を避ける。

最後に、本実施形態において説明するのは、ＣＣｏＡを使用して、モバイルＩＰの下で動作するＭＮ ６０である。上述したように、ＭＮ ６０は、別の通信モードの下で良好に動作することができ、他のタイプのアドレスとみなすことができる。例えば、ＭＮ ６０は、モバイルＩＰ経路最適モードの下、確実にＣＣｏＡを使用することができる。多くの代替例からの別の例として、ＭＮ ６０は、モバイルＩＰトンネルモードの下、ＦＡ ＣｏＡを使用し、ＣＮ ９０と通信することができる。更に、実施形態に記載したように、フィルタは双方向である必要がない。一方向フィルタを持っていると考えられる。例えば、ＭＮ６０は、同じことを逆に行うために、ＣＮ ９０を必要とすることなく一方向フィルタを設定するために、ＳＤＰ内にその通信モードを含むことができる。更に、上述するように、ノード６０は、外部ネットワークへローミングするモバイルデバイスとして示される。ノード６０は、固定式として良好であることが理解されるべきである。更に、実施形態に関連して記載された何れの論理ブロック、回路、及びアルゴリズムステップも、ハードウェア、ソフトウェア、ファームウェア、又はこれらの組み合わせとして実現されうる。これら及びその他の形式上の変形と詳細とは、本発明の範囲及び精神から逸脱することなくなされうることが当業者によって理解されよう。

図１は、ネットワークのグローバルな接続の概略図である。 図２は、本発明の実施形態を示す概略図である。 図３は、本発明の実施形態に従って、シグナリングを開始し、コンテンツトラフィックを確立するステップを示すフローチャートである。 図４は、本発明に従って構成されたモバイルノードの回路の概略図である。 図５は、本発明に従ったモニタリング中継点の回路の概略図である。

Claims (26)

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. 通信システムにおいて搬送波によって送信される電気信号であって、
    パケットデータの通信セッションのシグナリングメッセージから通信モードを受信し、前記パケットデータの通信セッションに関する前記通信モードによって提供される情報を必要とする１セットのポリシーを実施するコンピュータ読取可能命令を備える電気信号。

Images