共通ＩＰアドレス及びＭＡＣアドレスを有するＶｏＩＰカードを備えるアクセス・ノード
本発明は、進行中のＶｏＩＰ呼に関連するダウンストリームおよびアップストリームＲＴＰパケットを処理するためのＶｏＩＰアクセス・ノードにおける方法と装置に関する。本発明により、従来のアクセス・ノードにおけるようなＶｏＩＰカード毎に一つのＩＰアドレスを割当てる代わりに、アクセス・ノードの全体のＲＴＰトラヒックに一つの共通ＩＰアドレスを割当てうｒこと（３１０）が可能となる。このことは、受信した（３２０）ＲＴＰパケットの宛先ＵＤＰポート番号に基づき、宛先ＶｏＩＰカードを識別する（３３０）ことにより可能となる。その目的は、アクセス・ノードのコストを増加させること無しに、ＶｏＩＰサービスに必要なパブリックＩＰアドレスの数を最小にすることである。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ボイス・オーバＩＰ（ＶｏＩＰ）の分野、特に、アクセス・ノードにおけるリアルタイム・トランスポート・プロトコル（ＲＴＰ）トラヒックの処理に関する。より具体的には、本発明はアップストリームおよびダウンストリームＲＴＰパケットを処理する方法およびアクセス・ノードに関する
【背景技術】
【０００２】
ＶｏＩＰは、インターネット上での音声情報の配信を管理するために使用する一組の設備のためのインターネット・プロトコル（ＩＰ）電話技術用語である。ＶｏＩＰは、公衆電話交換網（ＰＳＴＮ）の伝統的な回路用プロトコルを使用するのではなく、ＩＰを使用して、個別パケットにおけるデジタル形式で音声情報を送ることを含む。ＩＰに加えて、ＶｏＩＰは、時宜を得たやり方でパケットの確実な配信を支援するため、ＲＴＰを使用する。ＲＴＰは、インターネット上で音声と画像を配信するため、標準パケット・フォーマットを定める。
【０００３】
ＶｏＩＰは時間依存のアプリケーションであるため、インターネットでのネットワーク・プロトコルとしてユーザ・データグラム・プロトコル（ＵＤＰ）を使用する。ＶｏＩＰにとっては、パケットの脱落は遅延パケットを使用するより望ましいことであり、ＵＤＰを用いると、コンピュータ・アプリケーションは、特別な送信チャネルまたはデータ・パスを設定するために事前の通信を必要とせずに、データグラムとしても知られるメッセージをＩＰネットワーク上のその他のホストに送ることができる。ＵＤＰは、信頼性、順序付けまたはデータの完全性を保証するための潜在的なハンド・シェイクの対話が無い、単純な送信モデルを使用する。それ故、ＵＤＰは信頼性のないサービスを提供し、データグラムはばらばらの順序で到着し、重複して現われ、または通知無しに欠落する可能性がある。ＵＤＰは、誤り検出と訂正が必ずしも必要でないか、またはアプリケーションで実行されることを仮定し、ネットワーク・インタフェース・レベルでのそのような処理のオーバヘッドを避けている。
【０００４】
ＵＤＰはＩＰレイヤが提供しない一つのサービス、即ち、異なるユーザ要求を識別する一助となるポート番号を提供する。ポート番号は、メッセージ・ユニットに添付するヘッダに置く１６ビットの整数であり、このポート番号はトランスポート・レイヤとＩＰレイヤとの間を物理的に通過し、転送される。ＩＰアドレスとポート番号との組合せはソケットと称される。ソケットは、データ送信のエンドポイントとして機能するサービス・ポートにアプリケーションを結び付け、ＶｏＩＰのようなＵＤＰアプリケーションは、ホスト対ホスト通信を確立するためデータグラム・ソケットを使用する。
【０００５】
ＶｏＩＰシステムは、伝統的なＰＳＴＮとインタフェースすることができ、透過的な電話通信が世界中あまねく可能となる。アクセス・ネットワーク内の機器、すなわちアクセス・ノードは、エンド・ユーザ・アクセスを提供し、アナログ音声信号からＩＰパケットへのメディア変換でＶｏＩＰをサポートできる。
【０００６】
ＶｏＩＰアクセス・ノード・アーキテクチャの一つの例を図１に示す。市場で利用可能なチップセットにより、メディア変換に限定したモジュール方式が可能である。従って、アクセス・ノード１０１が複数のユーザにサービスするため、幾つかのチップセットまたはＶｏＩＰカード１０２でアクセス・ノード１０１を用いて設計しなければならないが、ここで、各ＶｏＩＰカード１０２は、限られた数のユーザ、通常は２４、３２、４８または６４ユーザに対してメディア変換を実行する。メディア変換は、デジタル信号プロセッサ（ＤＳＰ）１０３を通じてＶｏＩＰカード１０２で実行され、旧来の電話サービス（ＰＯＴＳ）線１０９のアナログ音声信号をデジタル化されたパルス符号変調サンプルに変換する。次に、音声トラヒックはＩＰ上のＲＴＰパケットで送信される。これ以降、ＩＰ上の音声トラヒックをＲＴＰトラヒックと称する。
【０００７】
また、ＶｏＩＰカード１０２は、例えばセッション開始プロトコル（ＳＩＰ）またはＨ．２４８シグナリング・プロトコルを使用して、ＶｏＩＰシグナリング・フロー（呼設定、呼終端）を処理する、アクセス・ゲートウエイ（ＡＧＷ）アプリケーション１０４を実施する。その結果、ＶｏＩＰシグナリング・トラヒック１０５およびＲＴＰトラヒック１０６は、トラヒック転送のためのイーサネット（登録商標）・スイッチ１０８に基づき、制御器カード１０７により統合される。メディア変換およびＡＧＷアプリケーションは両方とも各々のＶｏＩＰカードに実装されるので、このアーキテクチャは分散型と定義することができる。
【０００８】
図１のような分散型アーキテクチャでは、ＲＴＰトラヒック１０６およびＶｏＩＰシグナリング・トラヒック１０５の両方とも各ＶｏＩＰカード１０２で生成され、終端する。これは、アップストリーム方向、即ちＶｏＩＰカード１０２からＩＰネットワーク１１０へ向かう方向では、ＲＴＰおよびシグナリング・パケットは各々のＶｏＩＰカードで生成されることを意味する。このパケットは、送信元ＩＰアドレスとして、それらが生成されたＶｏＩＰカードのＩＰアドレスを、そして送信元メディア・アクセス制御（ＭＡＣ）アドレスとしてその同じＶｏＩＰカードのＭＡＣアドレスを持つ。それらのＩＰアドレスおよびＭＡＣアドレスは、ダウンストリーム方向、即ちＩＰネットワーク１１０からＶｏＩＰカード１０２へ向かう方向で使用され、その同じＶｏＩＰカードに到達するであろう。両方の方向に対して、制御器カード１０７はＭＡＣアドレスに基づいてパケットをブリッジする。即ちパケット内容を変更せずにパケットを転送する。
【０００９】
分散型アーキテクチャの主な問題点は、それが複数のパブリックＩＰアドレス（各ＶｏＩＰカードに一つ）を必要とする、ということである。パブリックＩＰアドレスは乏しいリソースなので、このことは、ＶｏＩＰサービスが更に広がるにつれて受け入れがたい。
【００１０】
図２は、制御器カード１０７に集中化したＡＧＷアプリケーション１０４を有するアーキテクチャを示すが、ＶｏＩＰカード１０２に分散化したＤＳＰ１０３は保持している。このアーキテクチャでは、シグナリング・トラヒック１０５のＩＰアドレス数は自動的に一つに削減されている。しかしながら、ＲＴＰトラヒック１０６のために、ＶｏＩＰカード毎に一つのＩＰアドレスの必要性がまだあるだろうから、これは、大量のＩＰアドレスという問題を解決していない。
【００１１】
ＩＰアドレスの多さという問題への一つの解決策は、制御器カードにネットワーク アドレス変換（ＮＡＴ）を実装することである。コンピュータ・ネットワークでは、ＮＡＴは、所定のアドレス空間をもう一つのアドレス空間に再マッピングする目的のため、トラヒック・ルーティング・デバイスを超えて通過する時、データグラム・パケット・ヘッダのネットワーク・アドレス情報を変更するプロセスである。ＮＡＴは、送信元ＩＰアドレスおよび宛先ＩＰアドレスまたはそのいずれか一方と、通常はまたＩＰパケットのポート番号とを再書き込みすることを含む。また、変更を考慮してチェックサムを再書き込みしなければならない。ＮＡＴの実装はＩＰパケットの変更を必要とするので、制御器カードに更に強力なプロセッサを必要とし、これは制御器カード自身のコストをより高くすることにつながる。
【発明の概要】
【発明が解決しようとする課題】
【００１２】
それ故、削減された数のＩＰアドレスを必要とする、コスト効率のよいＶｏＩＰアクセス・ノードを提供する必要性がある。
【課題を解決するための手段】
【００１３】
本発明の目的は上記で概観した問題点に対処することであり、添付の独立クレームによる方法と装置によって、および従属クレームによる実施形態によって、この目的およびその他を実現する。
【００１４】
本発明は、ＶｏＩＰアクセス・ノードのＩＰアドレス数を最大２個、すなわちシグナリング・トラヒックに対して一つのＩＰアドレスおよびＲＴＰトラヒックに対して一つのＩＰアドレスに削減することを可能とする方法と装置に関する。制御器カードのＡＧＷアプリケーションを集中化して、シグナリング・トラヒックのＩＰアドレスを一つに削減する。アクセス・ノードのＶｏＩＰカードの全てに、一つの共通ＭＡＣアドレスを与え、これによりＲＴＰトラヒックに対して一つのＩＰアドレスを割当ることが可能となる。このことは、ダウンストリームＲＴＰパケットを転送するための正しい宛先ＶｏＩＰカードの識別は、本パケットに備わる宛先ＵＤＰポート番号に基づくだろう、ということを意味する。
【００１５】
それ故、本発明の第一の側面によれば、進行中のＶｏＩＰ呼に関連するダウンストリームＲＴＰパケットを処理するよう適応したアクセス・ノードが提供される。本アクセス・ノードには、ＩＰネットワークに接続可能な制御器カードと、本制御器カードに接続可能な第一で少なくとも一つの追加ＶｏＩＰカードとを備える。第一のＶｏＩＰカードは、ＲＴＰパケットの宛先であり、少なくとも一つのＵＤＰポート番号が設定される。ＶｏＩＰカードには、ＲＴＰパケットのために共通ＩＰアドレスと共通ＭＡＣアドレスを割当てられ、アクセス・ノードには、ＩＰネットワークからパケットを受信する手段を備える。ＲＴＰパケットには、宛先ＩＰアドレスとしての共通ＩＰアドレスと、宛先ＭＡＣアドレスとしての共通ＭＡＣアドレスと、宛先ＵＤＰポート番号とを含む。また、アクセス・ノードには、宛先ＵＤＰポート番号のみに基づいて宛先ＶｏＩＰカードを識別する手段を備える。
【００１６】
本発明の第二の側面によれば、進行中のＶｏＩＰカードに関連するダウンストリームＲＴＰパケットを処理するためのアクセス・ノードにおける方法が提供される。本アクセス・ノードには、ＩＰネットワークに接続可能な制御器カードと、本制御器カードに接続可能な第一で少なくとも一つの追加ＶｏＩＰカードとを備える。第一のＶｏＩＰカードは、ＲＴＰパケットの宛先であり、少なくとも一つのＵＤＰポート番号が設定される。本方法には、ＲＴＰパケットのための共通ＩＰアドレスと共通ＭＡＣアドレスとを前記ＶｏＩＰカードに割当てるステップと、ＩＰネットワークからパケットを受信するステップとを備える。本パケットには、宛先ＩＰアドレスとしての共通ＩＰアドレスと、宛先ＭＡＣアドレスとしての共通ＭＡＣアドレスと、宛先ＵＤＰポート番号とを含む。また本方法には、宛先ＵＤＰポート番号にのみ基づいて宛先ＶｏＩＰカードを識別するステップを備える。
【００１７】
本発明の第三の側面によれば、進行中のＶｏＩＰカードに関連するアップストリームＲＴＰパケットを処理するためのアクセス・ノードにおける方法が提供される。本アクセス・ノードには、ＩＰネットワークに接続可能な制御器カードと、本制御器カードに接続可能な第一で少なくとも一つの追加ＶｏＩＰカードとを備える。第一のＶｏＩＰカードはＲＴＰパケットの源であり、本ＶｏＩＰカードには、ＲＴＰパケットのための共通ＩＰアドレスと共通ＭＡＣアドレスとを割当てられている。本方法には、送信元ＩＰアドレスとしての共通ＩＰアドレスと送信元ＭＡＣアドレスとしての共通ＭＡＣアドレスとを有するパケットを生成するステップと、生成したパケットをＩＰネットワークに転送するステップとを備える。本ステップは第一のＶｏＩＰカードによって実行される。
【００１８】
本発明の実施形態の利点は、アクセス・ネットワーク内のＶｏＩＰサービスに必要なパブリックＩＰアドレスの数が削減され、一方、分散型ＤＳＰアーキテクチャを通してシステム拡張性を保持している、ということである。
【００１９】
本発明の実施形態のもう一つの利点はコスト効率がよいことであり、その理由は、ＲＴＰトラヒックを転送するため、制御器カードに低コストの商用イーサネット・スイッチを使用することが可能であり、制御器カードに強力で高価なプロセッサを必要としないからである。
【００２０】
本発明の実施形態の更なるもう一つの利点は、ハードウエアの性能向上が全く必要としないで、従来の分散型アーキテクチャから本発明の集中型アーキテクチャに性能向上を図れることができる、ということである。
【図面の簡単な説明】
【００２１】
【図１】従来技術による分散型アーキテクチャを有するアクセス・ノードを概略的に示す。
【図２】本発明が実装される可能性のある集中型アーキテクチャを有するアクセス・ノードを概略的に示す。
【図３ａ】、
【図３ｂ】、
【図３ｃ】、
【図３ｄ】本発明の実施形態によるアクセス・ノードの方法のフローチャートである。
【図４ａ】、
【図４ｂ】本発明の実施形態によるアクセス・ノードを概略的に示す。
【発明を実施するための形態】
【００２２】
以下に、幾つかの実施形態と添付の図面を参照して、本発明について更に詳細に説明する。説明のためであり制限を目的にせず、本発明の完全な理解を提供するため、特定のシナリオ、技術等のような特定の詳細について説明する。しかしながら、当業者には明らかなことであるが、本発明は、これらの特定の詳細から外れたその他の実施形態において実施されてもよい。
【００２３】
更に、当業者には当然のことであるが、プログラムしたマイクロプロセッサまたは汎用コンピュータと連動するソフトウエア機能を使用して、および特定用途向け集積回路（ＡＳＩＣ）を使用して、またはそのいずれかを使用して、以下に説明する機能および手段を実装してもよい。また当然のことであるが、現在の発明について、主として方法およびデバイスの形式で説明するが、本発明をまた、コンピュータ・プログラムに、同じくコンピュータ・プロセッサおよびプロセッサと連結するメモリを備えるシステムに実装してもよく、本メモリは、本申請書で開示する機能を実行する可能性のある一つ以上のプログラムでコーディングされている。
【００２４】
本発明は、従来のアクセス・ノードにおけるようにＶｏＩＰ毎に一つのＩＰアドレスを割当てる代わりに、アクセス・ノードの全体のＲＴＰトラヒックに一つの共通のＩＰアドレスの割当を可能とする方法と装置に関する。これは、ＶｏＩＰカードに共通ＭＡＣアドレスを与えることにより、そして宛先ＶｏＩＰカードを識別するため、ダウンストリームＲＴＰパケットの宛先ＵＤＰポート番号を使用することにより、実現される、即ち、ＶｏＩＰカードはＲＴＰパケットを終端し、デジタル信号をアナログ音声信号に戻す変換をする。目的は、アクセス・ノードのコストを増加させずにＶｏＩＰサービスに必要なパブリックＩＰアドレスの数を最小化することである。
【００２５】
それ故、本発明の基本的な概念は、アクセス・ノードの全てのＶｏＩＰカードに一つの共通のＩＰアドレスを割当てることである。このＩＰアドレスはパブリックＩＰアドレスの中で選択され、以降ＩＰ［ＲＴＰ］と称する。今日では、大部分のＩＰアドレスは、インターネット上のパケットで送られる情報の各々の送信者または受信者を識別する、３２ビットの数である。インターネットは多くの個別のネットワークの相互接続であり、ＩＰアドレスは二つの部分、すなわちインターネット上の特定のネットワークの識別子および特定のデバイスまたはネットワーク内のいわゆるホストの識別子を持つ。それ故、ＩＰアドレスには、ユニークなネットワーク番号と、ネットワーク内でユニークであるホスト番号とを含む。
【００２６】
ネットワーク内で使用されるマシンアドレスまたは物理アドレスは、インターネットのＩＰアドレスとは異なる可能性がある。構内通信網（ＬＡＮ）またはその他のネットワークでは、ＭＡＣアドレスはデバイスの（またはＩＰホストの）ユニークなハードウエア番号である。イーサネットＬＡＮ上では、これはイーサネット・アドレスと同じである。イーサネット・ネットワークのホストは、それがそのホストのＭＡＣアドレスを知っている場合のみ、もう一つのホストと通信できる。ホストがインターネットに接続されている場合、キャッシュ・テーブルともいわれる対応表はＩＰアドレスをホストの物理ＭＡＣアドレスに関係付ける。
【００２７】
アドレス解決プロトコル（ＡＲＰ）は、ＩＰアドレスを対応するＭＡＣアドレス／イーサネット・アドレスに変換するために使用するネットワーク・プロトコルである。ホストが所定のＩＰアドレスをＭＡＣアドレスに変換する必要がある場合、ＡＲＰリクエスト・パケットをブロードキャストする。ＡＲＰリクエスト・パケットには、送信元ＭＡＣアドレス、送信元ＩＰアドレスおよび宛先ＩＰアドレスを含む。ローカル・ネットワークの各ホストはこのパケットを受信する。指定された宛先ＩＰアドレスを有するホストは、そのＭＡＣアドレスとＩＰアドレスとともに、ＡＲＰリプライ・パケットを発信元ホストに対して送る。上記で説明したように、ＡＲＰは、メモリにあるＡＲＰキャッシュ・テーブルのＩＰアドレスとＭＡＣアドレスとの間のマッピングを維持する。このテーブルのエンティティは動的に加えられたり、取り除かれたりする。
【００２８】
本発明では、アクセス・ノードのＶｏＩＰカードには、ダウンストリームＲＴＰパケットにおける宛先ＭＡＣアドレス、およびアップストリーム・パケットにおける送信元ＭＡＣアドレスである共通ＭＡＣアドレスを与えられる。これにより、アクセス・ノードの全てのＶｏＩＰカードに、一つのＩＰアドレス、すなわちＩＰ［ＲＴＰ］の割当を可能となる。ＩＰ［ＲＴＰ］はダウンストリーム・パケットでは宛先ＩＰアドレスであり、アップストリーム・パケットでは送信元ＩＰアドレスとなるであろう。
【００２９】
本発明のアクセス・ノードにおける制御器カードは、イーサネット・ヘッダの宛先ＭＡＣアドレスのみに基づいて、受信したダウンストリームＲＴＰパケットの宛先を識別することはできないが、その理由は、それが全てのＲＴＰパケットについて同じものだからである。代わりに、ＵＤＰポートはアクティブな呼の各々にユニークに割当てられているので、ＵＤＰポート番号を使用してＲＴＰストリームは区別されるであろう。ＵＤＰポート番号は、関連するＶｏＩＰカード上での呼設定時に（即ち、シグナリング・フェーズの間に）設定される。これは、内部のアプリケーション・プログラミング・インターフェース（ＡＰＩ）を使用してＡＧＷアプリケーションが行う。制御器カードがパケットを受信すると、そのパケットには、そのパケットの宛先ＶｏＩＰカードを識別するためにその時使用することができる、宛先ＵＤＰポート番号を含む。また、その宛先ＶｏＩＰカードは、ＲＴＰパケットを終端し、パルス符号変調サンプルをアナログ音声信号に戻す変換をするＶｏＩＰカードである。
【００３０】
本発明によれば、ダウンストリームＲＴＰパケットの宛先ＶｏＩＰカードの識別は、以下の二つのメカニズムのうちの一つに基づく。
【００３１】
１．第一の実施形態では、制御器カードは、ＲＴＰパケットの受信後、アクセス・ノードの全てのＶｏＩＰカードにそのパケットを転送する。従って、ＶｏＩＰカードの各々でパケットの宛先の実際の識別を行う。ＶｏＩＰカードの各々は、受信したパケットの宛先ＵＤＰポート番号を、ＶｏＩＰカードに設定したＵＤＰポート番号と比較し、これらのＵＤＰポート番号間で全く一致するものが無い場合には受信したパケットを廃棄するだろう。
【００３２】
２．別の第二の実施形態では、各ＶｏＩＰカードに対してＵＤＰポート番号範囲の割当が要求される。ＶｏＩＰカードとＵＤＰポート番号範囲との間の関連は、管理システムが制御器カードに設定するか、または、例えば装置内のＶｏＩＰカードの物理位置に基づくアルゴリズムを使用して、制御器カードにハードコーディングするかのどちらかである。異なるＶｏＩＰカードに対するＵＤＰポート番号範囲は重なってはならない。ＲＴＰパケットを受信後、受信したパケットの宛先ＵＤＰポート番号を、設定したポート番号範囲と比較して、パケットの宛先ＶｏＩＰカードを識別し、宛先ＵＤＰポート番号を含む範囲に対応するＶｏＩＰカードにのみパケットを転送するであろう。
【００３３】
第一の実施形態の利点は、第二の実施形態におけるように、制御器カードのＶｏＩＰカードにいかなるＵＤＰポート範囲も設定する必要が全く無い、ということである。他方、パケットが関連のＶｏＩＰカードに転送されるのみであるので、第二の実施形態は、各ＶｏＩＰカードに削減したトラヒックを可能とする。二つの実施形態のいずれによっても、本発明の利点は、実装するためにいかなるハードウエア変更も意味していない、ということである。
【００３４】
ＶｏＩＰカードに与える共通ＭＡＣアドレスを選択する別の方法がある。本発明の一つの実施形態では、制御器カードのＭＡＣアドレスであるように、ＶｏＩＰカードの共通ＭＡＣアドレスを選択する。この実施形態では、シグナリング・トラヒックのＩＰアドレスとＲＴＰトラヒックのＩＰアドレスとは一致してもよく、もし望むなら、アクセス・ノードは、シグナリングおよびＲＴＰトラヒックの両方に一個の単一のパブリックＩＰアドレスのみを要求してもよく、このようにしてＩＰアドレスの数を最小限に削減する。
【００３５】
本発明の別の実施形態では、ＶｏＩＰカードの共通ＭＡＣアドレスは、制御器カードのＭＡＣアドレスでない、ユニークなＭＡＣアドレスである。例えば、米国特許出願公開ＵＳ２００４／０１４１４６８ Ａ１で説明される仮想ＭＡＣアドレスと同じフォーマットを使用して、このＭＡＣアドレスを生成してもよい。これは、仮想ＭＡＣアドレスはネットワーク内でユニークであり、それ故、二つのアクセス・ノードが同じＭＡＣアドレスを有することを回避するであろう、ということを保証している。また、本ＭＡＣアドレスはパブリック・ユニークＭＡＣアドレスでもある可能性がある。この別の実施形態では、シグナリング・トラヒックのＩＰアドレスとＲＴＰトラヒックのＩＰアドレスすなわちＩＰ［ＲＴＰ］とは異なっているが、その理由は、一つのＩＰアドレスが異なるＭＡＣアドレスに対応することはできないからである。
【００３６】
前に説明したように、対応するＭＡＣアドレスにＩＰアドレスを変換するためにＡＲＰを使用する。このことは、ＩＰネットワークのホストは、時々、ＡＲＰリクエスト・メッセージをブロードキャストするであろう、ということを意味する。これらのＡＲＰリクエスト・メッセージ・パケットは、とりわけアクセス・ノードにより、ダウンストリーム・パケットとして受信されるであろう。アクセス・ノードの制御器カードは、このようなリクエスト・メッセージを処理するであろう。もしＡＲＰリクエスト・メッセージ・パケットの宛先ＩＰアドレスがＩＰ［ＲＴＰ］に対応するなら、ＡＲＰリプライが生成され、送信元アドレスとして共通ＩＰアドレスＩＰ［ＲＴＰ］とＶｏＩＰカードの共通ＭＡＣアドレスとが、ＩＰネットワークの関連のホストに転送されるであろう。例えば要求されたサービスは利用できないということを示すメッセージのようなエラーメッセージを送るために使用されるインターネット制御通知プロトコル（ＩＣＭＰ）メッセージは、アナログ的な方法で制御器カードにより処理される。
【００３７】
また、アクセス・ノードはアップストリームＲＴＰパケットを処理するであろう。アップストリームでは、送信元ＩＰアドレスをＩＰ［ＲＴＰ］に、送信元ＭＡＣアドレスをＶｏＩＰカードの共通ＭＡＣアドレスにして、ＶｏＩＰ呼のローカル側に対応するＶｏＩＰカード上でＲＴＰパケットを生成する。アップストリーム方向では、同じアクセス・ノードに接続された二つのユーザ間で呼が発生する場合でも、ＲＴＰトラヒックはＩＰネットワークのデフォルト・ゲートウエイに常に転送される。生成したパケットの宛先ＩＰアドレスは、呼のリモート側のＩＰアドレスである。
【００３８】
従来、制御器カードのイーサネット・スイッチは、ＶｏＩＰカードへのダウンストリームおよびＩＰネットワークへのアップストリームの両方のパケットをブリッジする。これらパケットはスイッチの全てのポートに送り出され、意図した宛先ノードによってのみ受け取られるであろう。しかしながら、後続のメッセージを宛先ポートにのみ転送するため、スイッチが各ポートのＭＡＣアドレスを学習し、学習テーブルを作り上げることを可能にする、"学習"と呼ぶイーサネット・スイッチの機能がある。本発明では、異なるＶｏＩＰ呼に対応して、異なるＶｏＩＰカードに生成されるアップストリームＲＴＰパケットを制御器カードのイーサネット・スイッチに転送するであろう。それらは全て同じ送信元ＭＡＣアドレスを持つであろうが、それは学習機能を有するスイッチでは許されなく、従って、学習はＶｏＩＰカードに対するポートでは無効にされなければならない。
【００３９】
従来のＶｏＩＰ呼設定フェーズの間では、制御器カードのＡＧＷアプリケーションは、ＡＰＩ経由で、ＩＰアドレスのローカルＶｏＩＰカードおよびリモートＶｏＩＰカードのＵＤＰポート番号を通知する。本発明の一つの実施形態では、シグナリング・フェーズはまた、以前に説明したことに加えて、リモート側のＭＡＣアドレスを決定するため、ＡＲＰリクエストをＩＰネットワークに送ることを含むであろう。このことで、ローカルＶｏＩＰカードへのＡＰＩメッセージに、ＩＰアドレスおよびリモートＶｏＩＰカードのＵＤＰポート番号とともに本ＭＡＣアドレスを含めることが可能になる。この実施形態では、制御器カードは、必要であれば（必ずしもシグナリング・フェーズの間である必要はない）、ＩＰネットワークに向けてＩＣＭＰメッセージを送る。
【００４０】
別の実施形態では、ＶｏＩＰカードが、会話フェーズのまさに始めの呼の第一のＲＴＰパケットを生成する前に、ＶｏＩＰカードは制御器カードにＡＲＰリクエスト・メッセージを送信するであろう。制御器カードはＡＲＰリクエストを転送しないが、自分自身のリクエストを生成し、それをＩＰネットワークに送るであろう。制御器カードが対応するＡＲＰリプライ・メッセージを受信すると、制御器カードは、ＡＰＩメッセージを介して、ローカルＶｏＩＰカードにリモート側のＭＡＣアドレスを送信できる。ＶｏＩＰカードから到来するＩＣＭＰメッセージ全てを処理するため、制御器カードに同様なメカニズムを実装する。
【００４１】
以下に、図３ａ−ｄおよび４ａ−ｂを参照して、上記の実施形態について更に説明する。
【００４２】
図３ａは、本発明の進行中のＶｏＩＰ呼に関連するダウンストリームＲＴＰパケットを処理する、アクセス・ノードにおける本方法のフローチャートである。このＶｏＩＰ呼のダウンストリーム・パケットの宛先であるＶｏＩＰカードは、呼設定のシグナリング・フェーズにおいて、この呼に使用される予定のＵＤＰポート番号が設定されている。本カードは同様にその他のＶｏＩＰ呼を処理する可能性があるので、この同じＶｏＩＰカードにその他のＵＤＰポートを設定してもよい。ステップ３１０で、共通ＩＰアドレスと、同じくＲＴＰパケットのための共通ＭＡＣアドレスとを、アクセス・ノードのＶｏＩＰカードに割当てる。ステップ３２０で、アクセス・ノードはＩＰネットワークからパケットを受信する。本パケットには、宛先ＩＰアドレスとしての共通ＩＰアドレスと、宛先ＭＡＣアドレスとしての共通ＭＡＣアドレスと、宛先ＵＤＰポート番号とを備える。全てのＶｏＩＰカードは、ＲＴＰパケットのために同じＩＰアドレスとＭＡＣアドレスとを割当てられるため、このパケットの宛先ＶｏＩＰカードを識別するためにこれらのアドレスを使用することはできない。従って、ステップ３３０で、パケットの宛先であるＶｏＩＰカードを識別するため、宛先ＵＤＰポート番号を使用し、このようにしてＶｏＩＰカードはパケットを終端し、サンプルをアナログ音声信号に変換する。
【００４３】
図３ｂは、上記で説明した本発明の第一の実施形態により、進行中のＶｏＩＰ呼に関連するダウンストリームＲＴＰパケットを処理する、アクセス・ノードにおける本方法のフローチャートである。ステップ３１０は上記で説明したものと同じである。アクセス・ノードのＶｏＩＰカードは、ＲＴＰパケットのための、共通ＩＰアドレスと共通ＭＡＣアドレスを割当てられる。ステップ３２０で、本パケットは受信され、次にステップ３２１で、アクセス・ノードのＶｏＩＰカード全てに転送される。その結果、パケットが転送されたＶｏＩＰカードの一つ一つは、宛先ＶｏＩＰカードを識別するステップを実行し、ステップ３３１で、本パケットの宛先ＵＤＰポート番号が、ＶｏＩＰカードに設定したＵＤＰポート番号のいずれにも対応しない場合は、受信パケットを廃棄する。
【００４４】
図３ｃは、上記で説明した本発明の第二の実施形態により、進行中のＶｏＩＰ呼に関連するダウンストリームＲＴＰパケットを処理する、アクセス・ノードにおける本方法のフローチャートである。ここでまた、ステップ３１０は上記で説明したものと同じである。アクセス・ノードのＶｏＩＰカードは、ＲＴＰパケットのための、共通ＩＰアドレスと共通ＭＡＣアドレスを割当てられる。この第二の実施形態では、制御器カードは、接続されたＶｏＩＰカードの各々に妥当なＵＤＰポート番号の範囲が設定されている。ステップ３２０で、本パケットはアクセス・ノードの制御器カードによって受信され、次にステップ３３２で、制御器カードは、パケットの宛先ＵＤＰポート番号を含むＵＤＰポート番号範囲を持つＶｏＩＰカードに本パケットを転送して、宛先ＶｏＩＰカードを識別することができる。
【００４５】
ＶｏＩＰ呼に関連するアップストリームＲＴＰパケットを処理する、アクセス・ノードにおける方法を図３ｄに示す。アクセス・ノードのＶｏＩＰカードには、ＲＴＰパケットのための共通ＩＰアドレスと共通ＭＡＣアドレスとを割当てたが、これは、ステップ３４０で、ＶｏＩＰ呼の発信元のＶｏＩＰカードは、送信元ＩＰアドレスとしてＩＰアドレスを、送信元ＭＡＣアドレスとしてＭＡＣアドレスを有するＲＴＰパケットを生成するであろうということを意味する。次に、ステップ３５０で、この生成したパケットはＩＰネットワークに転送されるであろう。
【００４６】
図４ａに概略的に示し、上記で説明した第一の実施形態によれば、アクセス・ノード４００には、ＩＰネットワークに接続した制御器カード４１０と、ＲＴＰパケットに使用する予定の共通ＩＰアドレスと共通ＭＡＣアドレスを割当てられる多くのＶｏＩＰカード４２０とを備える。アクセス・ノードのＶｏＩＰカード４２０の一つは、進行中の呼の宛先ＶｏＩＰカード、即ちパルス符号変調シンボルをアナログ音声信号に戻す変換をするＶｏＩＰカードである。呼設定時に、ＡＧＷアプリケーションによりＵＤＰポート番号をこの宛先ＶｏＩＰカードに設定する。制御器カードにはＩＰネットワークからパケットを受信する手段４１１を備える。パケットには、宛先ＩＰアドレスとして共通ＩＰアドレスと、宛先ＭＡＣアドレスとして共通ＭＡＣアドレスと、宛先ＵＤＰポートとを含む。受信する手段４１１は、パケットをＶｏＩＰカードの全てに転送するよう構成される。各ＶｏＩＰカード４２０には、宛先ＵＤＰポート番号がＶｏＩＰカードに設定されたＵＤＰポート番号に対応しない場合、パケットを廃棄することにより、宛先ＶｏＩＰカードを識別する手段４１２を備える。このようにして、パケットを保持し、内容をアナログ音声信号に変換するのは、関連のＶｏＩＰカードのみである。
【００４７】
図４ｂに概略的に示し、上記で説明した第二の実施形態によれば、アクセス・ノード４００には、ＩＰネットワーク１１０に接続された制御器カード４１０と、ＲＴＰパケットのために共通ＩＰアドレスと共通ＭＡＣアドレスとを割当てられた多数のＶｏＩＰカード４２０とを備える。ＶｏＩＰカードの一つは、進行中の呼の宛先ＶｏＩＰカードであり、呼設定時にＡＧＷアプリケーション４４０によってＵＤＰポート番号が設定される。制御器カードは、例えば管理システムにより、ＶｏＩＰカードの各々に対して非オーバラップのポート番号の範囲が設定されている。制御器カードにはＩＰネットワークからパケットを受信する手段４１１を備え、本パケットには、宛先ＩＰアドレスとしての共通ＩＰアドレスと、宛先ＭＡＣアドレスとしての共通ＭＡＣアドレスと、宛先ＵＤＰポートとを含む。また、制御器カードには、宛先ＵＤＰポート番号を含むＵＤＰポート番号の範囲に対応するＶｏＩＰカードに受信したパケットを転送することにより、宛先ＶｏＩＰカードを識別する手段４１２を備える。このようにして、パケットの内容をアナログ音声信号に変換する一つの関連のＶｏＩＰカードにのみ、パケットを転送する。
【００４８】
注意すべきことであるが、図４ａ−４ｂに示した手段は、プログラムしたマイクロプロセッサまたは汎用コンピュータと連動して機能するソフトウエアを使用して、および／または特定用途向け集積回路（ＡＳＩＣ）を使用して、物理または論理エンティティにより実装されてもよい。
【００４９】
上記で述べて説明した実施形態は、単に例として与えたものであり、本発明に制限を与えるべきではない。添付の特許請求項で請求する本発明の範囲内にある、その他の解決策、使用法、目的および機能は、当業者には明らかなはずである。
【００５０】
略語
ＡＧＷ アクセス・ゲートウエイ
ＡＰＩ アプリケーション・プログラミング・インターフェース
ＡＲＰ アドレス解決プロトコル
ＡＳＩＣ 特定用途向け集積回路
ＤＳＰ デジタル信号プロセッサ
ＩＣＭＰ インターネット制御通知プロトコル
ＩＰ インターネット・プロトコル
ＬＡＮ 構内通信網
ＭＡＣ メディア・アクセス制御
ＮＡＴ ネットワーク アドレス変換
ＰＯＴＳ 旧来の電話サービス
ＰＳＴＮ 公衆電話交換網
ＲＴＰ リアルタイム・トランスポート・プロトコル
ＳＩＰ セッション開始プロトコル
ＵＤＰ ユーザ・データグラム・プロトコル
ＶｏＩＰ ボイス・オーバＩＰ
【技術分野】
【０００１】
本発明は、ボイス・オーバＩＰ（ＶｏＩＰ）の分野、特に、アクセス・ノードにおけるリアルタイム・トランスポート・プロトコル（ＲＴＰ）トラヒックの処理に関する。より具体的には、本発明はアップストリームおよびダウンストリームＲＴＰパケットを処理する方法およびアクセス・ノードに関する
【背景技術】
【０００２】
ＶｏＩＰは、インターネット上での音声情報の配信を管理するために使用する一組の設備のためのインターネット・プロトコル（ＩＰ）電話技術用語である。ＶｏＩＰは、公衆電話交換網（ＰＳＴＮ）の伝統的な回路用プロトコルを使用するのではなく、ＩＰを使用して、個別パケットにおけるデジタル形式で音声情報を送ることを含む。ＩＰに加えて、ＶｏＩＰは、時宜を得たやり方でパケットの確実な配信を支援するため、ＲＴＰを使用する。ＲＴＰは、インターネット上で音声と画像を配信するため、標準パケット・フォーマットを定める。
【０００３】
ＶｏＩＰは時間依存のアプリケーションであるため、インターネットでのネットワーク・プロトコルとしてユーザ・データグラム・プロトコル（ＵＤＰ）を使用する。ＶｏＩＰにとっては、パケットの脱落は遅延パケットを使用するより望ましいことであり、ＵＤＰを用いると、コンピュータ・アプリケーションは、特別な送信チャネルまたはデータ・パスを設定するために事前の通信を必要とせずに、データグラムとしても知られるメッセージをＩＰネットワーク上のその他のホストに送ることができる。ＵＤＰは、信頼性、順序付けまたはデータの完全性を保証するための潜在的なハンド・シェイクの対話が無い、単純な送信モデルを使用する。それ故、ＵＤＰは信頼性のないサービスを提供し、データグラムはばらばらの順序で到着し、重複して現われ、または通知無しに欠落する可能性がある。ＵＤＰは、誤り検出と訂正が必ずしも必要でないか、またはアプリケーションで実行されることを仮定し、ネットワーク・インタフェース・レベルでのそのような処理のオーバヘッドを避けている。
【０００４】
ＵＤＰはＩＰレイヤが提供しない一つのサービス、即ち、異なるユーザ要求を識別する一助となるポート番号を提供する。ポート番号は、メッセージ・ユニットに添付するヘッダに置く１６ビットの整数であり、このポート番号はトランスポート・レイヤとＩＰレイヤとの間を物理的に通過し、転送される。ＩＰアドレスとポート番号との組合せはソケットと称される。ソケットは、データ送信のエンドポイントとして機能するサービス・ポートにアプリケーションを結び付け、ＶｏＩＰのようなＵＤＰアプリケーションは、ホスト対ホスト通信を確立するためデータグラム・ソケットを使用する。
【０００５】
ＶｏＩＰシステムは、伝統的なＰＳＴＮとインタフェースすることができ、透過的な電話通信が世界中あまねく可能となる。アクセス・ネットワーク内の機器、すなわちアクセス・ノードは、エンド・ユーザ・アクセスを提供し、アナログ音声信号からＩＰパケットへのメディア変換でＶｏＩＰをサポートできる。
【０００６】
ＶｏＩＰアクセス・ノード・アーキテクチャの一つの例を図１に示す。市場で利用可能なチップセットにより、メディア変換に限定したモジュール方式が可能である。従って、アクセス・ノード１０１が複数のユーザにサービスするため、幾つかのチップセットまたはＶｏＩＰカード１０２でアクセス・ノード１０１を用いて設計しなければならないが、ここで、各ＶｏＩＰカード１０２は、限られた数のユーザ、通常は２４、３２、４８または６４ユーザに対してメディア変換を実行する。メディア変換は、デジタル信号プロセッサ（ＤＳＰ）１０３を通じてＶｏＩＰカード１０２で実行され、旧来の電話サービス（ＰＯＴＳ）線１０９のアナログ音声信号をデジタル化されたパルス符号変調サンプルに変換する。次に、音声トラヒックはＩＰ上のＲＴＰパケットで送信される。これ以降、ＩＰ上の音声トラヒックをＲＴＰトラヒックと称する。
【０００７】
また、ＶｏＩＰカード１０２は、例えばセッション開始プロトコル（ＳＩＰ）またはＨ．２４８シグナリング・プロトコルを使用して、ＶｏＩＰシグナリング・フロー（呼設定、呼終端）を処理する、アクセス・ゲートウエイ（ＡＧＷ）アプリケーション１０４を実施する。その結果、ＶｏＩＰシグナリング・トラヒック１０５およびＲＴＰトラヒック１０６は、トラヒック転送のためのイーサネット（登録商標）・スイッチ１０８に基づき、制御器カード１０７により統合される。メディア変換およびＡＧＷアプリケーションは両方とも各々のＶｏＩＰカードに実装されるので、このアーキテクチャは分散型と定義することができる。
【０００８】
図１のような分散型アーキテクチャでは、ＲＴＰトラヒック１０６およびＶｏＩＰシグナリング・トラヒック１０５の両方とも各ＶｏＩＰカード１０２で生成され、終端する。これは、アップストリーム方向、即ちＶｏＩＰカード１０２からＩＰネットワーク１１０へ向かう方向では、ＲＴＰおよびシグナリング・パケットは各々のＶｏＩＰカードで生成されることを意味する。このパケットは、送信元ＩＰアドレスとして、それらが生成されたＶｏＩＰカードのＩＰアドレスを、そして送信元メディア・アクセス制御（ＭＡＣ）アドレスとしてその同じＶｏＩＰカードのＭＡＣアドレスを持つ。それらのＩＰアドレスおよびＭＡＣアドレスは、ダウンストリーム方向、即ちＩＰネットワーク１１０からＶｏＩＰカード１０２へ向かう方向で使用され、その同じＶｏＩＰカードに到達するであろう。両方の方向に対して、制御器カード１０７はＭＡＣアドレスに基づいてパケットをブリッジする。即ちパケット内容を変更せずにパケットを転送する。
【０００９】
分散型アーキテクチャの主な問題点は、それが複数のパブリックＩＰアドレス（各ＶｏＩＰカードに一つ）を必要とする、ということである。パブリックＩＰアドレスは乏しいリソースなので、このことは、ＶｏＩＰサービスが更に広がるにつれて受け入れがたい。
【００１０】
図２は、制御器カード１０７に集中化したＡＧＷアプリケーション１０４を有するアーキテクチャを示すが、ＶｏＩＰカード１０２に分散化したＤＳＰ１０３は保持している。このアーキテクチャでは、シグナリング・トラヒック１０５のＩＰアドレス数は自動的に一つに削減されている。しかしながら、ＲＴＰトラヒック１０６のために、ＶｏＩＰカード毎に一つのＩＰアドレスの必要性がまだあるだろうから、これは、大量のＩＰアドレスという問題を解決していない。
【００１１】
ＩＰアドレスの多さという問題への一つの解決策は、制御器カードにネットワーク アドレス変換（ＮＡＴ）を実装することである。コンピュータ・ネットワークでは、ＮＡＴは、所定のアドレス空間をもう一つのアドレス空間に再マッピングする目的のため、トラヒック・ルーティング・デバイスを超えて通過する時、データグラム・パケット・ヘッダのネットワーク・アドレス情報を変更するプロセスである。ＮＡＴは、送信元ＩＰアドレスおよび宛先ＩＰアドレスまたはそのいずれか一方と、通常はまたＩＰパケットのポート番号とを再書き込みすることを含む。また、変更を考慮してチェックサムを再書き込みしなければならない。ＮＡＴの実装はＩＰパケットの変更を必要とするので、制御器カードに更に強力なプロセッサを必要とし、これは制御器カード自身のコストをより高くすることにつながる。
【発明の概要】
【発明が解決しようとする課題】
【００１２】
それ故、削減された数のＩＰアドレスを必要とする、コスト効率のよいＶｏＩＰアクセス・ノードを提供する必要性がある。
【課題を解決するための手段】
【００１３】
本発明の目的は上記で概観した問題点に対処することであり、添付の独立クレームによる方法と装置によって、および従属クレームによる実施形態によって、この目的およびその他を実現する。
【００１４】
本発明は、ＶｏＩＰアクセス・ノードのＩＰアドレス数を最大２個、すなわちシグナリング・トラヒックに対して一つのＩＰアドレスおよびＲＴＰトラヒックに対して一つのＩＰアドレスに削減することを可能とする方法と装置に関する。制御器カードのＡＧＷアプリケーションを集中化して、シグナリング・トラヒックのＩＰアドレスを一つに削減する。アクセス・ノードのＶｏＩＰカードの全てに、一つの共通ＭＡＣアドレスを与え、これによりＲＴＰトラヒックに対して一つのＩＰアドレスを割当ることが可能となる。このことは、ダウンストリームＲＴＰパケットを転送するための正しい宛先ＶｏＩＰカードの識別は、本パケットに備わる宛先ＵＤＰポート番号に基づくだろう、ということを意味する。
【００１５】
それ故、本発明の第一の側面によれば、進行中のＶｏＩＰ呼に関連するダウンストリームＲＴＰパケットを処理するよう適応したアクセス・ノードが提供される。本アクセス・ノードには、ＩＰネットワークに接続可能な制御器カードと、本制御器カードに接続可能な第一で少なくとも一つの追加ＶｏＩＰカードとを備える。第一のＶｏＩＰカードは、ＲＴＰパケットの宛先であり、少なくとも一つのＵＤＰポート番号が設定される。ＶｏＩＰカードには、ＲＴＰパケットのために共通ＩＰアドレスと共通ＭＡＣアドレスを割当てられ、アクセス・ノードには、ＩＰネットワークからパケットを受信する手段を備える。ＲＴＰパケットには、宛先ＩＰアドレスとしての共通ＩＰアドレスと、宛先ＭＡＣアドレスとしての共通ＭＡＣアドレスと、宛先ＵＤＰポート番号とを含む。また、アクセス・ノードには、宛先ＵＤＰポート番号のみに基づいて宛先ＶｏＩＰカードを識別する手段を備える。
【００１６】
本発明の第二の側面によれば、進行中のＶｏＩＰカードに関連するダウンストリームＲＴＰパケットを処理するためのアクセス・ノードにおける方法が提供される。本アクセス・ノードには、ＩＰネットワークに接続可能な制御器カードと、本制御器カードに接続可能な第一で少なくとも一つの追加ＶｏＩＰカードとを備える。第一のＶｏＩＰカードは、ＲＴＰパケットの宛先であり、少なくとも一つのＵＤＰポート番号が設定される。本方法には、ＲＴＰパケットのための共通ＩＰアドレスと共通ＭＡＣアドレスとを前記ＶｏＩＰカードに割当てるステップと、ＩＰネットワークからパケットを受信するステップとを備える。本パケットには、宛先ＩＰアドレスとしての共通ＩＰアドレスと、宛先ＭＡＣアドレスとしての共通ＭＡＣアドレスと、宛先ＵＤＰポート番号とを含む。また本方法には、宛先ＵＤＰポート番号にのみ基づいて宛先ＶｏＩＰカードを識別するステップを備える。
【００１７】
本発明の第三の側面によれば、進行中のＶｏＩＰカードに関連するアップストリームＲＴＰパケットを処理するためのアクセス・ノードにおける方法が提供される。本アクセス・ノードには、ＩＰネットワークに接続可能な制御器カードと、本制御器カードに接続可能な第一で少なくとも一つの追加ＶｏＩＰカードとを備える。第一のＶｏＩＰカードはＲＴＰパケットの源であり、本ＶｏＩＰカードには、ＲＴＰパケットのための共通ＩＰアドレスと共通ＭＡＣアドレスとを割当てられている。本方法には、送信元ＩＰアドレスとしての共通ＩＰアドレスと送信元ＭＡＣアドレスとしての共通ＭＡＣアドレスとを有するパケットを生成するステップと、生成したパケットをＩＰネットワークに転送するステップとを備える。本ステップは第一のＶｏＩＰカードによって実行される。
【００１８】
本発明の実施形態の利点は、アクセス・ネットワーク内のＶｏＩＰサービスに必要なパブリックＩＰアドレスの数が削減され、一方、分散型ＤＳＰアーキテクチャを通してシステム拡張性を保持している、ということである。
【００１９】
本発明の実施形態のもう一つの利点はコスト効率がよいことであり、その理由は、ＲＴＰトラヒックを転送するため、制御器カードに低コストの商用イーサネット・スイッチを使用することが可能であり、制御器カードに強力で高価なプロセッサを必要としないからである。
【００２０】
本発明の実施形態の更なるもう一つの利点は、ハードウエアの性能向上が全く必要としないで、従来の分散型アーキテクチャから本発明の集中型アーキテクチャに性能向上を図れることができる、ということである。
【図面の簡単な説明】
【００２１】
【図１】従来技術による分散型アーキテクチャを有するアクセス・ノードを概略的に示す。
【図２】本発明が実装される可能性のある集中型アーキテクチャを有するアクセス・ノードを概略的に示す。
【図３ａ】、
【図３ｂ】、
【図３ｃ】、
【図３ｄ】本発明の実施形態によるアクセス・ノードの方法のフローチャートである。
【図４ａ】、
【図４ｂ】本発明の実施形態によるアクセス・ノードを概略的に示す。
【発明を実施するための形態】
【００２２】
以下に、幾つかの実施形態と添付の図面を参照して、本発明について更に詳細に説明する。説明のためであり制限を目的にせず、本発明の完全な理解を提供するため、特定のシナリオ、技術等のような特定の詳細について説明する。しかしながら、当業者には明らかなことであるが、本発明は、これらの特定の詳細から外れたその他の実施形態において実施されてもよい。
【００２３】
更に、当業者には当然のことであるが、プログラムしたマイクロプロセッサまたは汎用コンピュータと連動するソフトウエア機能を使用して、および特定用途向け集積回路（ＡＳＩＣ）を使用して、またはそのいずれかを使用して、以下に説明する機能および手段を実装してもよい。また当然のことであるが、現在の発明について、主として方法およびデバイスの形式で説明するが、本発明をまた、コンピュータ・プログラムに、同じくコンピュータ・プロセッサおよびプロセッサと連結するメモリを備えるシステムに実装してもよく、本メモリは、本申請書で開示する機能を実行する可能性のある一つ以上のプログラムでコーディングされている。
【００２４】
本発明は、従来のアクセス・ノードにおけるようにＶｏＩＰ毎に一つのＩＰアドレスを割当てる代わりに、アクセス・ノードの全体のＲＴＰトラヒックに一つの共通のＩＰアドレスの割当を可能とする方法と装置に関する。これは、ＶｏＩＰカードに共通ＭＡＣアドレスを与えることにより、そして宛先ＶｏＩＰカードを識別するため、ダウンストリームＲＴＰパケットの宛先ＵＤＰポート番号を使用することにより、実現される、即ち、ＶｏＩＰカードはＲＴＰパケットを終端し、デジタル信号をアナログ音声信号に戻す変換をする。目的は、アクセス・ノードのコストを増加させずにＶｏＩＰサービスに必要なパブリックＩＰアドレスの数を最小化することである。
【００２５】
それ故、本発明の基本的な概念は、アクセス・ノードの全てのＶｏＩＰカードに一つの共通のＩＰアドレスを割当てることである。このＩＰアドレスはパブリックＩＰアドレスの中で選択され、以降ＩＰ［ＲＴＰ］と称する。今日では、大部分のＩＰアドレスは、インターネット上のパケットで送られる情報の各々の送信者または受信者を識別する、３２ビットの数である。インターネットは多くの個別のネットワークの相互接続であり、ＩＰアドレスは二つの部分、すなわちインターネット上の特定のネットワークの識別子および特定のデバイスまたはネットワーク内のいわゆるホストの識別子を持つ。それ故、ＩＰアドレスには、ユニークなネットワーク番号と、ネットワーク内でユニークであるホスト番号とを含む。
【００２６】
ネットワーク内で使用されるマシンアドレスまたは物理アドレスは、インターネットのＩＰアドレスとは異なる可能性がある。構内通信網（ＬＡＮ）またはその他のネットワークでは、ＭＡＣアドレスはデバイスの（またはＩＰホストの）ユニークなハードウエア番号である。イーサネットＬＡＮ上では、これはイーサネット・アドレスと同じである。イーサネット・ネットワークのホストは、それがそのホストのＭＡＣアドレスを知っている場合のみ、もう一つのホストと通信できる。ホストがインターネットに接続されている場合、キャッシュ・テーブルともいわれる対応表はＩＰアドレスをホストの物理ＭＡＣアドレスに関係付ける。
【００２７】
アドレス解決プロトコル（ＡＲＰ）は、ＩＰアドレスを対応するＭＡＣアドレス／イーサネット・アドレスに変換するために使用するネットワーク・プロトコルである。ホストが所定のＩＰアドレスをＭＡＣアドレスに変換する必要がある場合、ＡＲＰリクエスト・パケットをブロードキャストする。ＡＲＰリクエスト・パケットには、送信元ＭＡＣアドレス、送信元ＩＰアドレスおよび宛先ＩＰアドレスを含む。ローカル・ネットワークの各ホストはこのパケットを受信する。指定された宛先ＩＰアドレスを有するホストは、そのＭＡＣアドレスとＩＰアドレスとともに、ＡＲＰリプライ・パケットを発信元ホストに対して送る。上記で説明したように、ＡＲＰは、メモリにあるＡＲＰキャッシュ・テーブルのＩＰアドレスとＭＡＣアドレスとの間のマッピングを維持する。このテーブルのエンティティは動的に加えられたり、取り除かれたりする。
【００２８】
本発明では、アクセス・ノードのＶｏＩＰカードには、ダウンストリームＲＴＰパケットにおける宛先ＭＡＣアドレス、およびアップストリーム・パケットにおける送信元ＭＡＣアドレスである共通ＭＡＣアドレスを与えられる。これにより、アクセス・ノードの全てのＶｏＩＰカードに、一つのＩＰアドレス、すなわちＩＰ［ＲＴＰ］の割当を可能となる。ＩＰ［ＲＴＰ］はダウンストリーム・パケットでは宛先ＩＰアドレスであり、アップストリーム・パケットでは送信元ＩＰアドレスとなるであろう。
【００２９】
本発明のアクセス・ノードにおける制御器カードは、イーサネット・ヘッダの宛先ＭＡＣアドレスのみに基づいて、受信したダウンストリームＲＴＰパケットの宛先を識別することはできないが、その理由は、それが全てのＲＴＰパケットについて同じものだからである。代わりに、ＵＤＰポートはアクティブな呼の各々にユニークに割当てられているので、ＵＤＰポート番号を使用してＲＴＰストリームは区別されるであろう。ＵＤＰポート番号は、関連するＶｏＩＰカード上での呼設定時に（即ち、シグナリング・フェーズの間に）設定される。これは、内部のアプリケーション・プログラミング・インターフェース（ＡＰＩ）を使用してＡＧＷアプリケーションが行う。制御器カードがパケットを受信すると、そのパケットには、そのパケットの宛先ＶｏＩＰカードを識別するためにその時使用することができる、宛先ＵＤＰポート番号を含む。また、その宛先ＶｏＩＰカードは、ＲＴＰパケットを終端し、パルス符号変調サンプルをアナログ音声信号に戻す変換をするＶｏＩＰカードである。
【００３０】
本発明によれば、ダウンストリームＲＴＰパケットの宛先ＶｏＩＰカードの識別は、以下の二つのメカニズムのうちの一つに基づく。
【００３１】
１．第一の実施形態では、制御器カードは、ＲＴＰパケットの受信後、アクセス・ノードの全てのＶｏＩＰカードにそのパケットを転送する。従って、ＶｏＩＰカードの各々でパケットの宛先の実際の識別を行う。ＶｏＩＰカードの各々は、受信したパケットの宛先ＵＤＰポート番号を、ＶｏＩＰカードに設定したＵＤＰポート番号と比較し、これらのＵＤＰポート番号間で全く一致するものが無い場合には受信したパケットを廃棄するだろう。
【００３２】
２．別の第二の実施形態では、各ＶｏＩＰカードに対してＵＤＰポート番号範囲の割当が要求される。ＶｏＩＰカードとＵＤＰポート番号範囲との間の関連は、管理システムが制御器カードに設定するか、または、例えば装置内のＶｏＩＰカードの物理位置に基づくアルゴリズムを使用して、制御器カードにハードコーディングするかのどちらかである。異なるＶｏＩＰカードに対するＵＤＰポート番号範囲は重なってはならない。ＲＴＰパケットを受信後、受信したパケットの宛先ＵＤＰポート番号を、設定したポート番号範囲と比較して、パケットの宛先ＶｏＩＰカードを識別し、宛先ＵＤＰポート番号を含む範囲に対応するＶｏＩＰカードにのみパケットを転送するであろう。
【００３３】
第一の実施形態の利点は、第二の実施形態におけるように、制御器カードのＶｏＩＰカードにいかなるＵＤＰポート範囲も設定する必要が全く無い、ということである。他方、パケットが関連のＶｏＩＰカードに転送されるのみであるので、第二の実施形態は、各ＶｏＩＰカードに削減したトラヒックを可能とする。二つの実施形態のいずれによっても、本発明の利点は、実装するためにいかなるハードウエア変更も意味していない、ということである。
【００３４】
ＶｏＩＰカードに与える共通ＭＡＣアドレスを選択する別の方法がある。本発明の一つの実施形態では、制御器カードのＭＡＣアドレスであるように、ＶｏＩＰカードの共通ＭＡＣアドレスを選択する。この実施形態では、シグナリング・トラヒックのＩＰアドレスとＲＴＰトラヒックのＩＰアドレスとは一致してもよく、もし望むなら、アクセス・ノードは、シグナリングおよびＲＴＰトラヒックの両方に一個の単一のパブリックＩＰアドレスのみを要求してもよく、このようにしてＩＰアドレスの数を最小限に削減する。
【００３５】
本発明の別の実施形態では、ＶｏＩＰカードの共通ＭＡＣアドレスは、制御器カードのＭＡＣアドレスでない、ユニークなＭＡＣアドレスである。例えば、米国特許出願公開ＵＳ２００４／０１４１４６８ Ａ１で説明される仮想ＭＡＣアドレスと同じフォーマットを使用して、このＭＡＣアドレスを生成してもよい。これは、仮想ＭＡＣアドレスはネットワーク内でユニークであり、それ故、二つのアクセス・ノードが同じＭＡＣアドレスを有することを回避するであろう、ということを保証している。また、本ＭＡＣアドレスはパブリック・ユニークＭＡＣアドレスでもある可能性がある。この別の実施形態では、シグナリング・トラヒックのＩＰアドレスとＲＴＰトラヒックのＩＰアドレスすなわちＩＰ［ＲＴＰ］とは異なっているが、その理由は、一つのＩＰアドレスが異なるＭＡＣアドレスに対応することはできないからである。
【００３６】
前に説明したように、対応するＭＡＣアドレスにＩＰアドレスを変換するためにＡＲＰを使用する。このことは、ＩＰネットワークのホストは、時々、ＡＲＰリクエスト・メッセージをブロードキャストするであろう、ということを意味する。これらのＡＲＰリクエスト・メッセージ・パケットは、とりわけアクセス・ノードにより、ダウンストリーム・パケットとして受信されるであろう。アクセス・ノードの制御器カードは、このようなリクエスト・メッセージを処理するであろう。もしＡＲＰリクエスト・メッセージ・パケットの宛先ＩＰアドレスがＩＰ［ＲＴＰ］に対応するなら、ＡＲＰリプライが生成され、送信元アドレスとして共通ＩＰアドレスＩＰ［ＲＴＰ］とＶｏＩＰカードの共通ＭＡＣアドレスとが、ＩＰネットワークの関連のホストに転送されるであろう。例えば要求されたサービスは利用できないということを示すメッセージのようなエラーメッセージを送るために使用されるインターネット制御通知プロトコル（ＩＣＭＰ）メッセージは、アナログ的な方法で制御器カードにより処理される。
【００３７】
また、アクセス・ノードはアップストリームＲＴＰパケットを処理するであろう。アップストリームでは、送信元ＩＰアドレスをＩＰ［ＲＴＰ］に、送信元ＭＡＣアドレスをＶｏＩＰカードの共通ＭＡＣアドレスにして、ＶｏＩＰ呼のローカル側に対応するＶｏＩＰカード上でＲＴＰパケットを生成する。アップストリーム方向では、同じアクセス・ノードに接続された二つのユーザ間で呼が発生する場合でも、ＲＴＰトラヒックはＩＰネットワークのデフォルト・ゲートウエイに常に転送される。生成したパケットの宛先ＩＰアドレスは、呼のリモート側のＩＰアドレスである。
【００３８】
従来、制御器カードのイーサネット・スイッチは、ＶｏＩＰカードへのダウンストリームおよびＩＰネットワークへのアップストリームの両方のパケットをブリッジする。これらパケットはスイッチの全てのポートに送り出され、意図した宛先ノードによってのみ受け取られるであろう。しかしながら、後続のメッセージを宛先ポートにのみ転送するため、スイッチが各ポートのＭＡＣアドレスを学習し、学習テーブルを作り上げることを可能にする、"学習"と呼ぶイーサネット・スイッチの機能がある。本発明では、異なるＶｏＩＰ呼に対応して、異なるＶｏＩＰカードに生成されるアップストリームＲＴＰパケットを制御器カードのイーサネット・スイッチに転送するであろう。それらは全て同じ送信元ＭＡＣアドレスを持つであろうが、それは学習機能を有するスイッチでは許されなく、従って、学習はＶｏＩＰカードに対するポートでは無効にされなければならない。
【００３９】
従来のＶｏＩＰ呼設定フェーズの間では、制御器カードのＡＧＷアプリケーションは、ＡＰＩ経由で、ＩＰアドレスのローカルＶｏＩＰカードおよびリモートＶｏＩＰカードのＵＤＰポート番号を通知する。本発明の一つの実施形態では、シグナリング・フェーズはまた、以前に説明したことに加えて、リモート側のＭＡＣアドレスを決定するため、ＡＲＰリクエストをＩＰネットワークに送ることを含むであろう。このことで、ローカルＶｏＩＰカードへのＡＰＩメッセージに、ＩＰアドレスおよびリモートＶｏＩＰカードのＵＤＰポート番号とともに本ＭＡＣアドレスを含めることが可能になる。この実施形態では、制御器カードは、必要であれば（必ずしもシグナリング・フェーズの間である必要はない）、ＩＰネットワークに向けてＩＣＭＰメッセージを送る。
【００４０】
別の実施形態では、ＶｏＩＰカードが、会話フェーズのまさに始めの呼の第一のＲＴＰパケットを生成する前に、ＶｏＩＰカードは制御器カードにＡＲＰリクエスト・メッセージを送信するであろう。制御器カードはＡＲＰリクエストを転送しないが、自分自身のリクエストを生成し、それをＩＰネットワークに送るであろう。制御器カードが対応するＡＲＰリプライ・メッセージを受信すると、制御器カードは、ＡＰＩメッセージを介して、ローカルＶｏＩＰカードにリモート側のＭＡＣアドレスを送信できる。ＶｏＩＰカードから到来するＩＣＭＰメッセージ全てを処理するため、制御器カードに同様なメカニズムを実装する。
【００４１】
以下に、図３ａ−ｄおよび４ａ−ｂを参照して、上記の実施形態について更に説明する。
【００４２】
図３ａは、本発明の進行中のＶｏＩＰ呼に関連するダウンストリームＲＴＰパケットを処理する、アクセス・ノードにおける本方法のフローチャートである。このＶｏＩＰ呼のダウンストリーム・パケットの宛先であるＶｏＩＰカードは、呼設定のシグナリング・フェーズにおいて、この呼に使用される予定のＵＤＰポート番号が設定されている。本カードは同様にその他のＶｏＩＰ呼を処理する可能性があるので、この同じＶｏＩＰカードにその他のＵＤＰポートを設定してもよい。ステップ３１０で、共通ＩＰアドレスと、同じくＲＴＰパケットのための共通ＭＡＣアドレスとを、アクセス・ノードのＶｏＩＰカードに割当てる。ステップ３２０で、アクセス・ノードはＩＰネットワークからパケットを受信する。本パケットには、宛先ＩＰアドレスとしての共通ＩＰアドレスと、宛先ＭＡＣアドレスとしての共通ＭＡＣアドレスと、宛先ＵＤＰポート番号とを備える。全てのＶｏＩＰカードは、ＲＴＰパケットのために同じＩＰアドレスとＭＡＣアドレスとを割当てられるため、このパケットの宛先ＶｏＩＰカードを識別するためにこれらのアドレスを使用することはできない。従って、ステップ３３０で、パケットの宛先であるＶｏＩＰカードを識別するため、宛先ＵＤＰポート番号を使用し、このようにしてＶｏＩＰカードはパケットを終端し、サンプルをアナログ音声信号に変換する。
【００４３】
図３ｂは、上記で説明した本発明の第一の実施形態により、進行中のＶｏＩＰ呼に関連するダウンストリームＲＴＰパケットを処理する、アクセス・ノードにおける本方法のフローチャートである。ステップ３１０は上記で説明したものと同じである。アクセス・ノードのＶｏＩＰカードは、ＲＴＰパケットのための、共通ＩＰアドレスと共通ＭＡＣアドレスを割当てられる。ステップ３２０で、本パケットは受信され、次にステップ３２１で、アクセス・ノードのＶｏＩＰカード全てに転送される。その結果、パケットが転送されたＶｏＩＰカードの一つ一つは、宛先ＶｏＩＰカードを識別するステップを実行し、ステップ３３１で、本パケットの宛先ＵＤＰポート番号が、ＶｏＩＰカードに設定したＵＤＰポート番号のいずれにも対応しない場合は、受信パケットを廃棄する。
【００４４】
図３ｃは、上記で説明した本発明の第二の実施形態により、進行中のＶｏＩＰ呼に関連するダウンストリームＲＴＰパケットを処理する、アクセス・ノードにおける本方法のフローチャートである。ここでまた、ステップ３１０は上記で説明したものと同じである。アクセス・ノードのＶｏＩＰカードは、ＲＴＰパケットのための、共通ＩＰアドレスと共通ＭＡＣアドレスを割当てられる。この第二の実施形態では、制御器カードは、接続されたＶｏＩＰカードの各々に妥当なＵＤＰポート番号の範囲が設定されている。ステップ３２０で、本パケットはアクセス・ノードの制御器カードによって受信され、次にステップ３３２で、制御器カードは、パケットの宛先ＵＤＰポート番号を含むＵＤＰポート番号範囲を持つＶｏＩＰカードに本パケットを転送して、宛先ＶｏＩＰカードを識別することができる。
【００４５】
ＶｏＩＰ呼に関連するアップストリームＲＴＰパケットを処理する、アクセス・ノードにおける方法を図３ｄに示す。アクセス・ノードのＶｏＩＰカードには、ＲＴＰパケットのための共通ＩＰアドレスと共通ＭＡＣアドレスとを割当てたが、これは、ステップ３４０で、ＶｏＩＰ呼の発信元のＶｏＩＰカードは、送信元ＩＰアドレスとしてＩＰアドレスを、送信元ＭＡＣアドレスとしてＭＡＣアドレスを有するＲＴＰパケットを生成するであろうということを意味する。次に、ステップ３５０で、この生成したパケットはＩＰネットワークに転送されるであろう。
【００４６】
図４ａに概略的に示し、上記で説明した第一の実施形態によれば、アクセス・ノード４００には、ＩＰネットワークに接続した制御器カード４１０と、ＲＴＰパケットに使用する予定の共通ＩＰアドレスと共通ＭＡＣアドレスを割当てられる多くのＶｏＩＰカード４２０とを備える。アクセス・ノードのＶｏＩＰカード４２０の一つは、進行中の呼の宛先ＶｏＩＰカード、即ちパルス符号変調シンボルをアナログ音声信号に戻す変換をするＶｏＩＰカードである。呼設定時に、ＡＧＷアプリケーションによりＵＤＰポート番号をこの宛先ＶｏＩＰカードに設定する。制御器カードにはＩＰネットワークからパケットを受信する手段４１１を備える。パケットには、宛先ＩＰアドレスとして共通ＩＰアドレスと、宛先ＭＡＣアドレスとして共通ＭＡＣアドレスと、宛先ＵＤＰポートとを含む。受信する手段４１１は、パケットをＶｏＩＰカードの全てに転送するよう構成される。各ＶｏＩＰカード４２０には、宛先ＵＤＰポート番号がＶｏＩＰカードに設定されたＵＤＰポート番号に対応しない場合、パケットを廃棄することにより、宛先ＶｏＩＰカードを識別する手段４１２を備える。このようにして、パケットを保持し、内容をアナログ音声信号に変換するのは、関連のＶｏＩＰカードのみである。
【００４７】
図４ｂに概略的に示し、上記で説明した第二の実施形態によれば、アクセス・ノード４００には、ＩＰネットワーク１１０に接続された制御器カード４１０と、ＲＴＰパケットのために共通ＩＰアドレスと共通ＭＡＣアドレスとを割当てられた多数のＶｏＩＰカード４２０とを備える。ＶｏＩＰカードの一つは、進行中の呼の宛先ＶｏＩＰカードであり、呼設定時にＡＧＷアプリケーション４４０によってＵＤＰポート番号が設定される。制御器カードは、例えば管理システムにより、ＶｏＩＰカードの各々に対して非オーバラップのポート番号の範囲が設定されている。制御器カードにはＩＰネットワークからパケットを受信する手段４１１を備え、本パケットには、宛先ＩＰアドレスとしての共通ＩＰアドレスと、宛先ＭＡＣアドレスとしての共通ＭＡＣアドレスと、宛先ＵＤＰポートとを含む。また、制御器カードには、宛先ＵＤＰポート番号を含むＵＤＰポート番号の範囲に対応するＶｏＩＰカードに受信したパケットを転送することにより、宛先ＶｏＩＰカードを識別する手段４１２を備える。このようにして、パケットの内容をアナログ音声信号に変換する一つの関連のＶｏＩＰカードにのみ、パケットを転送する。
【００４８】
注意すべきことであるが、図４ａ−４ｂに示した手段は、プログラムしたマイクロプロセッサまたは汎用コンピュータと連動して機能するソフトウエアを使用して、および／または特定用途向け集積回路（ＡＳＩＣ）を使用して、物理または論理エンティティにより実装されてもよい。
【００４９】
上記で述べて説明した実施形態は、単に例として与えたものであり、本発明に制限を与えるべきではない。添付の特許請求項で請求する本発明の範囲内にある、その他の解決策、使用法、目的および機能は、当業者には明らかなはずである。
【００５０】
略語
ＡＧＷ アクセス・ゲートウエイ
ＡＰＩ アプリケーション・プログラミング・インターフェース
ＡＲＰ アドレス解決プロトコル
ＡＳＩＣ 特定用途向け集積回路
ＤＳＰ デジタル信号プロセッサ
ＩＣＭＰ インターネット制御通知プロトコル
ＩＰ インターネット・プロトコル
ＬＡＮ 構内通信網
ＭＡＣ メディア・アクセス制御
ＮＡＴ ネットワーク アドレス変換
ＰＯＴＳ 旧来の電話サービス
ＰＳＴＮ 公衆電話交換網
ＲＴＰ リアルタイム・トランスポート・プロトコル
ＳＩＰ セッション開始プロトコル
ＵＤＰ ユーザ・データグラム・プロトコル
ＶｏＩＰ ボイス・オーバＩＰ
【特許請求の範囲】
【請求項１】
進行中のＶｏＩＰ呼に関連するダウンストリームＲＴＰパケットを処理するよう適合したアクセス・ノード（４００）であって、ＩＰネットワーク（１１０）に接続可能な制御器カード（４１０）と、制御器カード（４１０）に接続可能な第一の少なくとも一つの追加ＶｏＩＰカード（４２０）とを備え、前記第一のＶｏＩＰカードはＲＴＰパケットの宛先であり、少なくとも一つのＵＤＰポート番号が設定され、前記ＶｏＩＰカード（４２０）はＲＴＰパケットのために共通ＩＰアドレスと共通ＭＡＣアドレスとを割当られており、
宛先ＩＰアドレスとして共通ＩＰアドレスと、宛先ＭＡＣアドレスとして共通ＭＡＣアドレスと、宛先ＵＤＰポート番号とを有するＲＴＰパケットをＩＰネットワーク（１１０）から受信する手段（４１１）と、
宛先ＵＤＰポート番号にのみ基づいて宛先ＶｏＩＰカードを識別する手段（４１２）と
を備えることを特徴とするアクセス・ノード（４００）。
【請求項２】
前記制御器カード（４１０）は、ＶｏＩＰ呼の設定の間に宛先ＵＤＰポート番号を前記第一のＶｏＩＰカードに設定するよう構成したアクセス・ゲートウエイ・アプリケーション（４４０）を備えることを特徴とする請求項１に記載のアクセス・ノード（４００）。
【請求項３】
前記受信する手段（４１１）は、受信したＲＴＰパケットを前記ＶｏＩＰカード（４２０）の全てにまた転送するよう構成され、
前記識別する手段（４１２）は、前記ＶｏＩＰカード（４２０）の各々に置かれ、ＲＴＰパケットの宛先ＵＤＰポート番号が、ＶｏＩＰカードに設定されたＵＤＰポート番号に対応しない場合は、受信したＲＴＰパケットを廃棄するよう更に構成したことを特徴とする請求項１または２に記載のアクセス・ノード（４００）。
【請求項４】
前記制御器カード（４１０）には、前記ＶｏＩＰカード（４２０）の各々に対する重複していないＵＤＰポート番号の範囲が設定され、
前記識別する手段（４１２）は制御器カード（４１０）に置かれ、ＲＴＰパケットの宛先ＵＤＰポート番号を含む、重複していないＵＤＰポート番号の範囲に対応するＶｏＩＰカードに、受信したパケットを転送するよう更に構成したことを特徴とする請求項１乃至３のいずれか一項に記載のアクセス・ノード（４００）。
【請求項５】
前記共通ＭＡＣアドレスは前記制御器カードのＭＡＣアドレスであることを特徴とする請求項1乃至４のいずれか一項に記載のアクセス・ノード。
【請求項６】
前記共通ＭＡＣアドレスはユニークなＭＡＣアドレスであることを特徴とする請求項1乃至５のいずれか一項に記載のアクセス・ノード。
【請求項７】
全てのＡＲＰリクエスト・メッセージまたはＩＰネットワークから受信したＩＣＭＰメッセージに応答するよう制御器カードを更に構成したことを特徴とする請求項１乃至６のいずれか一項に記載のアクセス・ノード。
【請求項８】
進行中のＶｏＩＰ呼に関連するアップストリームＲＴＰパケットを処理するよう更に適合され、
送信元ＩＰアドレスとして共通ＩＰアドレスと、送信元ＭＡＣアドレスとして共通ＭＡＣアドレスとを有するＲＴＰパケットを生成し、生成したＲＴＰパケットをＩＰネットワークに転送するよう、第一のＶｏＩＰカードを構成したことを特徴とする請求項１乃至７のいずれか一項に記載のアクセス・ノード。
【請求項９】
生成したＲＴＰパケットは、ＶｏＩＰ呼の設定の間に前記第一のＶｏＩＰカードに設定した宛先ＭＡＣアドレスを更に含むことを特徴とする請求項８に記載のアクセス・ノード。
【請求項１０】
生成したＲＴＰパケットは、ＡＲＰを使用して前記制御器カードが提供する宛先ＭＡＣアドレスを更に含むことを特徴とする請求項８に記載のアクセス・ノード。
【請求項１１】
ＩＰネットワークに向けたＩＣＭＰメッセージを処理するよう、前記制御器カードを更に構成したことを特徴とする請求項１乃至１０のいずれか一項に記載のアクセス・ノード。
【請求項１２】
アクセス・ノードにおいて、進行中のＶｏＩＰ呼に関連するダウンストリームＲＴＰパケットを処理する方法であって、前記アクセス・ノードはＩＰネットワークに接続される制御器カードと、該制御器カードに接続される第一の少なくとも一つの追加ＶｏＩＰカードとを備え、前記第一のＶｏＩＰカードはＲＴＰパケットの宛先であり、少なくとも一つのＵＤＰポート番号が設定されており、前記方法は、
ＲＴＰパケットのための共通のＩＰアドレスと共通のＭＡＣアドレスとを前記ＶｏＩＰカードに割当てる（３１０）ステップと、
宛先ＩＰアドレスとして共通のＩＰアドレスと、宛先ＭＡＣアドレスとして共通のＭＡＣアドレスと、宛先ＵＤＰポート番号とを含むＲＴＰパケットをＩＰネットワークから受信する（３１０）ステップと、
宛先ＵＤＰポート番号にのみ基づいて宛先ＶｏＩＰカードを識別する（３３０）ステップと
を有することを特徴とする方法。
【請求項１３】
前記制御器カードのアクセス・ゲートウエイ・アプリケーションによりＶｏＩＰカードの設定の間に宛先ＵＤＰポート番号を前記第一のＶｏＩＰカードに設定することを特徴とする請求項１２に記載の方法。
【請求項１４】
前記受信するステップ（３２０）にはまた、受信したＲＴＰパケットを前記ＶｏＩＰカードの全てに転送するステップ（３２１）を含み、
前記識別するステップ（３３０）は、受信したＲＴＰパケットの宛先ＵＤＰポート番号がＶｏＩＰカードに設定されたＵＤＰポート番号に対応しない場合は受信したＲＴＰパケットを廃棄するステップ（３３１）により、前記ＶｏＩＰカードの各々が実行することを特徴とする請求項１２または１３に記載の方法。
【請求項１５】
前記制御器カードには、前記ＶｏＩＰカードの各々に対する重複していないＵＤＰポート番号の範囲が設定され、
前記識別するステップ（３３０）は、受信したＲＴＰパケットを、該ＲＴＰパケットの宛先ＵＤＰポート番号を含む重複していないＵＤＰポート番号の範囲に対応するＶｏＩＰカードに転送する（３３２）ステップにより、制御器カードが実行することを特徴とする請求項１２または１３に記載の方法。
【請求項１６】
前記共通ＭＡＣアドレスが前記制御器カードのＭＡＣアドレスであることを特徴とする請求項１２乃至１５のいずれか一項に記載の方法。
【請求項１７】
前記共通ＭＡＣアドレスがユニークなＭＡＣアドレスであることを特徴とする請求項１２乃至１５のいずれか一項に記載の方法。
【請求項１８】
全てのＡＲＰリクエスト・メッセージまたはＩＰネットワークから受信したＩＣＭＰメッセージに応答するよう制御器カードを構成したことを特徴とする請求項１２乃至１７のいずれか一項に記載の方法。
【請求項１９】
アクセス・ノードにおいて、進行中のＶｏＩＰ呼に関連するアップストリームＲＴＰパケットを処理する方法であって、前記アクセス・ノードにはＩＰネットワークに接続する制御器カードと、該制御器カードに接続する第一の少なくとも一つの追加ＶｏＩＰカードとを備え、前記第一のＶｏＩＰカードはＲＴＰパケットの送信元であり、前記ＶｏＩＰカードは、ＲＴＰパケットのための共通ＩＰアドレスと共通ＭＡＣアドレスを割当てられており、前記方法は、前記第一のＶｏＩＰカードにより遂行される、
送信元ＩＰアドレスとして共通ＩＰアドレスと送信元ＭＡＣアドレスとして共通ＭＡＣアドレスとを含むＲＴＰパケットを生成する（３４０）ステップと、
ＩＰネットワークに生成したＲＴＰパケットを転送する（３５０）ステップと
の、第一のＶｏＩＰカードが実行するステップと
を有することを特徴とする方法。
【請求項２０】
前記共通ＭＡＣアドレスは前記制御器カードのＭＡＣアドレスであることを特徴とする請求項１９に記載の方法。
【請求項２１】
前記共通ＭＡＣアドレスはユニークなＭＡＣアドレスであることを特徴とする請求項１９に記載の方法。
【請求項２２】
生成した前記ＲＴＰパケットは、ＶｏＩＰ呼の設定に間に前記第一のＶｏＩＰカードに設定された宛先ＭＡＣアドレスを更に含むことを特徴とする請求項１９乃至２１のいずれか一項に記載の方法。
【請求項２３】
生成した前記ＲＴＰパケットは、ＡＲＰを使用して制御器カードが提供する宛先ＭＡＣアドレスを更に含むことを特徴とする請求項１９乃至２１のいずれか一項に記載の方法。
【請求項２４】
ＩＰネットワークに向けた全てのＩＣＭＰメッセージを処理するよう前記制御器カードを構成したことを特徴とする請求項１９乃至２３のいずれか一項に記載の方法。
【請求項１】
進行中のＶｏＩＰ呼に関連するダウンストリームＲＴＰパケットを処理するよう適合したアクセス・ノード（４００）であって、ＩＰネットワーク（１１０）に接続可能な制御器カード（４１０）と、制御器カード（４１０）に接続可能な第一の少なくとも一つの追加ＶｏＩＰカード（４２０）とを備え、前記第一のＶｏＩＰカードはＲＴＰパケットの宛先であり、少なくとも一つのＵＤＰポート番号が設定され、前記ＶｏＩＰカード（４２０）はＲＴＰパケットのために共通ＩＰアドレスと共通ＭＡＣアドレスとを割当られており、
宛先ＩＰアドレスとして共通ＩＰアドレスと、宛先ＭＡＣアドレスとして共通ＭＡＣアドレスと、宛先ＵＤＰポート番号とを有するＲＴＰパケットをＩＰネットワーク（１１０）から受信する手段（４１１）と、
宛先ＵＤＰポート番号にのみ基づいて宛先ＶｏＩＰカードを識別する手段（４１２）と
を備えることを特徴とするアクセス・ノード（４００）。
【請求項２】
前記制御器カード（４１０）は、ＶｏＩＰ呼の設定の間に宛先ＵＤＰポート番号を前記第一のＶｏＩＰカードに設定するよう構成したアクセス・ゲートウエイ・アプリケーション（４４０）を備えることを特徴とする請求項１に記載のアクセス・ノード（４００）。
【請求項３】
前記受信する手段（４１１）は、受信したＲＴＰパケットを前記ＶｏＩＰカード（４２０）の全てにまた転送するよう構成され、
前記識別する手段（４１２）は、前記ＶｏＩＰカード（４２０）の各々に置かれ、ＲＴＰパケットの宛先ＵＤＰポート番号が、ＶｏＩＰカードに設定されたＵＤＰポート番号に対応しない場合は、受信したＲＴＰパケットを廃棄するよう更に構成したことを特徴とする請求項１または２に記載のアクセス・ノード（４００）。
【請求項４】
前記制御器カード（４１０）には、前記ＶｏＩＰカード（４２０）の各々に対する重複していないＵＤＰポート番号の範囲が設定され、
前記識別する手段（４１２）は制御器カード（４１０）に置かれ、ＲＴＰパケットの宛先ＵＤＰポート番号を含む、重複していないＵＤＰポート番号の範囲に対応するＶｏＩＰカードに、受信したパケットを転送するよう更に構成したことを特徴とする請求項１乃至３のいずれか一項に記載のアクセス・ノード（４００）。
【請求項５】
前記共通ＭＡＣアドレスは前記制御器カードのＭＡＣアドレスであることを特徴とする請求項1乃至４のいずれか一項に記載のアクセス・ノード。
【請求項６】
前記共通ＭＡＣアドレスはユニークなＭＡＣアドレスであることを特徴とする請求項1乃至５のいずれか一項に記載のアクセス・ノード。
【請求項７】
全てのＡＲＰリクエスト・メッセージまたはＩＰネットワークから受信したＩＣＭＰメッセージに応答するよう制御器カードを更に構成したことを特徴とする請求項１乃至６のいずれか一項に記載のアクセス・ノード。
【請求項８】
進行中のＶｏＩＰ呼に関連するアップストリームＲＴＰパケットを処理するよう更に適合され、
送信元ＩＰアドレスとして共通ＩＰアドレスと、送信元ＭＡＣアドレスとして共通ＭＡＣアドレスとを有するＲＴＰパケットを生成し、生成したＲＴＰパケットをＩＰネットワークに転送するよう、第一のＶｏＩＰカードを構成したことを特徴とする請求項１乃至７のいずれか一項に記載のアクセス・ノード。
【請求項９】
生成したＲＴＰパケットは、ＶｏＩＰ呼の設定の間に前記第一のＶｏＩＰカードに設定した宛先ＭＡＣアドレスを更に含むことを特徴とする請求項８に記載のアクセス・ノード。
【請求項１０】
生成したＲＴＰパケットは、ＡＲＰを使用して前記制御器カードが提供する宛先ＭＡＣアドレスを更に含むことを特徴とする請求項８に記載のアクセス・ノード。
【請求項１１】
ＩＰネットワークに向けたＩＣＭＰメッセージを処理するよう、前記制御器カードを更に構成したことを特徴とする請求項１乃至１０のいずれか一項に記載のアクセス・ノード。
【請求項１２】
アクセス・ノードにおいて、進行中のＶｏＩＰ呼に関連するダウンストリームＲＴＰパケットを処理する方法であって、前記アクセス・ノードはＩＰネットワークに接続される制御器カードと、該制御器カードに接続される第一の少なくとも一つの追加ＶｏＩＰカードとを備え、前記第一のＶｏＩＰカードはＲＴＰパケットの宛先であり、少なくとも一つのＵＤＰポート番号が設定されており、前記方法は、
ＲＴＰパケットのための共通のＩＰアドレスと共通のＭＡＣアドレスとを前記ＶｏＩＰカードに割当てる（３１０）ステップと、
宛先ＩＰアドレスとして共通のＩＰアドレスと、宛先ＭＡＣアドレスとして共通のＭＡＣアドレスと、宛先ＵＤＰポート番号とを含むＲＴＰパケットをＩＰネットワークから受信する（３１０）ステップと、
宛先ＵＤＰポート番号にのみ基づいて宛先ＶｏＩＰカードを識別する（３３０）ステップと
を有することを特徴とする方法。
【請求項１３】
前記制御器カードのアクセス・ゲートウエイ・アプリケーションによりＶｏＩＰカードの設定の間に宛先ＵＤＰポート番号を前記第一のＶｏＩＰカードに設定することを特徴とする請求項１２に記載の方法。
【請求項１４】
前記受信するステップ（３２０）にはまた、受信したＲＴＰパケットを前記ＶｏＩＰカードの全てに転送するステップ（３２１）を含み、
前記識別するステップ（３３０）は、受信したＲＴＰパケットの宛先ＵＤＰポート番号がＶｏＩＰカードに設定されたＵＤＰポート番号に対応しない場合は受信したＲＴＰパケットを廃棄するステップ（３３１）により、前記ＶｏＩＰカードの各々が実行することを特徴とする請求項１２または１３に記載の方法。
【請求項１５】
前記制御器カードには、前記ＶｏＩＰカードの各々に対する重複していないＵＤＰポート番号の範囲が設定され、
前記識別するステップ（３３０）は、受信したＲＴＰパケットを、該ＲＴＰパケットの宛先ＵＤＰポート番号を含む重複していないＵＤＰポート番号の範囲に対応するＶｏＩＰカードに転送する（３３２）ステップにより、制御器カードが実行することを特徴とする請求項１２または１３に記載の方法。
【請求項１６】
前記共通ＭＡＣアドレスが前記制御器カードのＭＡＣアドレスであることを特徴とする請求項１２乃至１５のいずれか一項に記載の方法。
【請求項１７】
前記共通ＭＡＣアドレスがユニークなＭＡＣアドレスであることを特徴とする請求項１２乃至１５のいずれか一項に記載の方法。
【請求項１８】
全てのＡＲＰリクエスト・メッセージまたはＩＰネットワークから受信したＩＣＭＰメッセージに応答するよう制御器カードを構成したことを特徴とする請求項１２乃至１７のいずれか一項に記載の方法。
【請求項１９】
アクセス・ノードにおいて、進行中のＶｏＩＰ呼に関連するアップストリームＲＴＰパケットを処理する方法であって、前記アクセス・ノードにはＩＰネットワークに接続する制御器カードと、該制御器カードに接続する第一の少なくとも一つの追加ＶｏＩＰカードとを備え、前記第一のＶｏＩＰカードはＲＴＰパケットの送信元であり、前記ＶｏＩＰカードは、ＲＴＰパケットのための共通ＩＰアドレスと共通ＭＡＣアドレスを割当てられており、前記方法は、前記第一のＶｏＩＰカードにより遂行される、
送信元ＩＰアドレスとして共通ＩＰアドレスと送信元ＭＡＣアドレスとして共通ＭＡＣアドレスとを含むＲＴＰパケットを生成する（３４０）ステップと、
ＩＰネットワークに生成したＲＴＰパケットを転送する（３５０）ステップと
の、第一のＶｏＩＰカードが実行するステップと
を有することを特徴とする方法。
【請求項２０】
前記共通ＭＡＣアドレスは前記制御器カードのＭＡＣアドレスであることを特徴とする請求項１９に記載の方法。
【請求項２１】
前記共通ＭＡＣアドレスはユニークなＭＡＣアドレスであることを特徴とする請求項１９に記載の方法。
【請求項２２】
生成した前記ＲＴＰパケットは、ＶｏＩＰ呼の設定に間に前記第一のＶｏＩＰカードに設定された宛先ＭＡＣアドレスを更に含むことを特徴とする請求項１９乃至２１のいずれか一項に記載の方法。
【請求項２３】
生成した前記ＲＴＰパケットは、ＡＲＰを使用して制御器カードが提供する宛先ＭＡＣアドレスを更に含むことを特徴とする請求項１９乃至２１のいずれか一項に記載の方法。
【請求項２４】
ＩＰネットワークに向けた全てのＩＣＭＰメッセージを処理するよう前記制御器カードを構成したことを特徴とする請求項１９乃至２３のいずれか一項に記載の方法。
【図１】
【図２】
【図３ａ】
【図３ｂ】
【図３ｃ】
【図３ｄ】
【図４ａ】
【図４ｂ】
【図２】
【図３ａ】
【図３ｂ】
【図３ｃ】
【図３ｄ】
【図４ａ】
【図４ｂ】
【公表番号】特表２０１２−５２１１４７（Ｐ２０１２−５２１１４７Ａ）
【公表日】平成２４年９月１０日（２０１２．９．１０）
【国際特許分類】
【出願番号】特願２０１２−５００７３４（Ｐ２０１２−５００７３４）
【出願日】平成２１年３月１８日（２００９．３．１８）
【国際出願番号】ＰＣＴ／ＳＥ２００９／０５０２７５
【国際公開番号】ＷＯ２０１０／１０７３４６
【国際公開日】平成２２年９月２３日（２０１０．９．２３）
【出願人】（５９８０３６３００）テレフオンアクチーボラゲット エル エム エリクソン（パブル） (2,266)
【Ｆターム（参考）】
【公表日】平成２４年９月１０日（２０１２．９．１０）
【国際特許分類】
【出願日】平成２１年３月１８日（２００９．３．１８）
【国際出願番号】ＰＣＴ／ＳＥ２００９／０５０２７５
【国際公開番号】ＷＯ２０１０／１０７３４６
【国際公開日】平成２２年９月２３日（２０１０．９．２３）
【出願人】（５９８０３６３００）テレフオンアクチーボラゲット エル エム エリクソン（パブル） (2,266)
【Ｆターム（参考）】
[ Back to top ]