(57)【要約】第１の移動体端末とノード（例えば、固定式又は移動体端末、或いはサーバ）との間にインターネット・プロトコル通信システムを介して（例えば、インターネットを介して）接続指向の相互接続を提供するための通信プロトコルであって、第１の移動体端末とノードがインターネット・セッションの一部を形成しており、該第１の移動体端末が最初に第１の移動体コントローラ（ＭＣ）を介して該ノードに接続されており、該プロトコルは、該ノードに関するインターネット・アドレスと該インターネット・セッションを識別するレコード番号とを該第１のＭＣに提供するための手段を備える。このプロトコルはまた、第１の移動体端末とノードとの間の相互接続が、第１のＭＣ経由から第１のＭＣ経由に方向変換される際にセッションを保持させる。
2004511961.tif 000002
【特許請求の範囲】
【請求項１】
第１の移動体端末とノードとを備え、インターネット・セッションの一部を形成し且つ前記第１の移動体端末と前記ノードと間に接続指向の相互接続を支持するための通信システムであって、前記相互接続が最初に第１の移動体コントローラ（ＭＣ）を介して該第１の移動体端末と該ノードを接続しており、該ノードのインターネット・アドレス及び前記インターネット・セッションを識別するレコード番号を前記第１のＭＣに提供するための通信手段が設けられたことを特徴とする通信システム。
【請求項２】
前記ノードが固定端末を備え、前記固定端末がルータを介して前記通信システムに接続され、前記インターネット・アドレスが前記ルータを識別し、前記レコード番号が該ルータからもたらされることを特徴とする請求項１に記載の通信システム。
【請求項３】
前記ノードがサーバを備え、前記インターネット・アドレスが前記サーバを識別し、前記レコード番号が該サーバからもたらされることを特徴とする請求項１に記載の通信システム。
【請求項４】
前記ノードが更に別の移動体端末を備え、前記更に別の移動体端末が、更に別のＭＣを介して前記第１の移動体端末に接続され、前記インターネット・アドレスが前記更に別のＭＣを識別し、前記レコード番号が該更に別のＭＣからもたらされることを特徴とする請求項１に記載の通信システム。
【請求項５】
前記相互接続が前記第１のＭＣ経由から第２のＭＣ経由に方向変換される際に、前記セッションが保持されることを特徴とする請求項１から請求項３までのいずれかに記載の通信システム。
【請求項６】
前記第１のＭＣが、方向変換を要求するために、前記通信システムを介してメッセージを前記第２のＭＣに送信するための送信機を備えることを特徴とする請求項４に記載の通信システム。
【請求項７】
前記第１のＭＣを介する前記相互接続が、前記第１の移動体端末と前記ノードとの間に第１の仮想メッセージ・パスを備え、前記第２のＭＣを介して方向変換された該相互接続が、該第１の移動体端末と該ノードとの間に第２のＶＭＰを備えることを特徴とする請求項４から請求項５までのいずれかに記載の通信システム。
【請求項８】
前記第２のＭＣが、前記サーバ、前記ルータ、及び前記更に別のＭＣのうちの一つに対して前記第２のＶＭＰを開くように配置されることを特徴とする請求項４から請求項６までのいずれか一つに記載の通信システム。
【請求項９】
前記第２のＭＣが、前記ルータと前記ノードとの間を延びる前記第１のＶＭＰの一部を介して、該ルータから該ノードまで前記第２のＶＭＰを延ばすように配置されることを特徴とする請求項７に記載の通信システム。
【請求項１０】
前記第２のＶＭＰが、前記更に別のＭＣと前記更に別の移動体端末との間を延びる前記第１のＶＭＰの一部を介して、該更に別のＭＣから該更に別の移動体端末まで延びることを特徴とする請求項７に記載の通信システム。
【請求項１１】
前記方向変換が、前記第２のＭＣの制御中に実行されることを特徴とする請求項４から請求項９までのいずれか一つに記載の通信システム。
【請求項１２】
前記サーバ、前記ルータ、及び前記更に別のＭＣのうちの１つが、前記第２のＭＣの制御中に前記第１のＭＣ経由から該第２のＭＣ経由に前記相互接続を方向変換するための方向変換手段を備えることを特徴とする請求項１０に記載の通信システム。
【請求項１３】
前記相互接続の方向変換が、シームレスな方法で行われることを特徴とする請求項４から請求項１１までのいずれか一つに記載の通信システム。
【請求項１４】
前記相互接続の方向変換中、前記ルータが、前記第１のＭＣに加えて前記第２のＭＣからメッセージを受け取って該ノードに送り、同時に該ノードから受け取った全てのメッセージを該第２のＭＣを介して前記第１の移動体端末に送るように配置されることを特徴とする請求項４から請求項１２までのいずれか一つに記載の通信システム。
【請求項１５】
前記ノードが前記インターネット・セッションを開始するように配置され、前記第１の移動体端末と前記ノードとの間の通信が、該第１の移動体端末により設けられたＶＭＰにわたって行われることを特徴とする請求項１から請求項１３までのいずれか一つに記載の通信システム。
【請求項１６】
前記第１の移動体端末が前記インターネット・セッションを開始するように配置され、前記第１の移動体端末と前記ノードとの間の通信が、該第１の移動体端末により設けられたＶＭＰにわたって行われることを特徴とする請求項１から請求項１２までのいずれか一つに記載の通信システム。
【請求項１７】
第１の移動体端末とノードがインターネット・セッションの一部を形成し、前記第１の移動体端末が最初に第１の移動体コントローラ（ＭＣ）を介して前記ノードに接続されている、該第１の移動体端末と該ノードとの間にインターネット・プロトコル通信システムを介して接続指向の相互接続を提供する方法であって、該ノードのインターネット・アドレスと前記インターネット・セッションを識別するレコード番号とを前記第１のＭＣに提供する段階を含むことを特徴とする方法。
【請求項１８】
前記ノードが固定端末を備え、前記固定端末がルータを介して前記通信システムに接続され、前記インターネット・アドレスが前記ルータを識別し、前記レコード番号が該ルータからもたらされることを特徴とする請求項１７に記載の方法。
【請求項１９】
前記ノードがサーバを備え、前記インターネット・アドレスが前記サーバを識別し、前記レコード番号が該サーバから割り当てられることを特徴とする請求項１７に記載の方法。
【請求項２０】
前記ノードが更に別の移動体端末を備え、前記更に別の移動体端末が更に別のＭＣを介して前記インターネット・プロトコル通信システムに接続され、前記インターネット・アドレスが前記更に別のＭＣを識別し、前記レコード番号が該更に別のＭＣから割り当てられることを特徴とする請求項１７に記載の方法。
【請求項２１】
前記第１の移動体端末と前記ノードとの間の前記相互接続が前記第１のＭＣ経由から第２のＭＣ経由に方向変換される際に、前記セッションを保持する段階を含むことを特徴とする請求項１７から請求項２０までのいずれかに記載の方法。
【請求項２２】
前記方向変換を要求するために、前記第１のＭＣが前記インターネット・プロトコル通信システムを介してメッセージを前記第２のＭＣに送信することを特徴とする請求項２１に記載の方法。
【請求項２３】
前記第１の移動体端末と前記ノードとの間に第１の仮想メッセージ・パス（ＶＭＰ）として前記相互接続を確立し、該相互接続を前記第１のＶＭＰから第２のＶＭＰへ転送するための段階を含み、前記第１のＭＣが該第１のＶＭＰ内に含まれ、前記第２のＭＣが該第２のＶＭＰ内に含まれることを特徴とする請求項２１及び請求項２２のいずれか一つに記載の方法。
【請求項２４】
前記第２のＭＣが、前記サーバ、前記ルータ、前記更に別のＭＣのうちの一つに対して前記第２のＶＭＰを開くことを特徴とする請求項２１から請求項２３までのいずれか一つに記載の方法。
【請求項２５】
前記ルータと前記ノードとの間を延びる前記第１のＶＭＰの一部を介して、該ルータから該ノードまで前記第２のＶＭＰを延ばす段階を含むことを特徴とする請求項２３及び請求項２４のいずれか一つに記載の方法。
【請求項２６】
前記更に別のＭＣと前記更に別の移動体端末との間を延びる前記第１のＶＭＰの一部を介して、該更に別のＭＣから該更に別の移動体端末まで前記第２のＶＭＰを延ばすことを特徴とする請求項２３及び請求項２４のいずれか一つに記載の方法。
【請求項２７】
前記第２のＭＣが、前記サーバ、前記ルータ、及び前記更に別のＭＣのうちの一つに、前記第１のＭＣ経由から前記第２のＭＣ経由に方向変換するように命令することを特徴とする請求項２１から請求項２６までのいずれか一つに記載の方法。
【請求項２８】
第１の移動体端末とノードとの間にインターネット・プロトコル通信システムを介して接続指向の相互接続を提供するための通信プロトコルであって、前記第１の移動体端末と前記ノードがインターネット・セッションの一部を形成しており、前記第１の移動体端末が最初に第１の移動体コントローラ（ＭＣ）を介して前記ノードに接続されており、前記プロトコルが、該ノードのインターネット・アドレスと前記インターネット・セッションを識別するレコード番号とを前記第１のＭＣに提供するための通信手段を備えること特徴とする通信プロトコル。
【請求項２９】
前記ノードが固定端末を備え、前記固定端末がルータを介して前記インターネット・プロトコル通信システムに接続され、前記インターネット・アドレスが前記ルータを識別し、前記レコード番号が該ルータから割り当てられることを特徴とする請求項２８に記載の通信プロトコル。
【請求項３０】
前記ノードがサーバを備え、前記インターネット・アドレスが前記サーバを識別し、前記レコード番号が該サーバから割り当てられることを特徴とする請求項２８に記載の通信プロトコル。
【請求項３１】
前記ノードが更に別の移動体端末を備え、前記更に別の移動体端末が更に別のＭＣを介して前記インターネット・プロトコル通信システムに接続され、前記インターネット・アドレスが前記更に別のＭＣを識別し、前記レコード番号が該更に別のＭＣから割り当てられることを特徴とする請求項２８に記載の通信プロトコル。
【請求項３２】
前記第１の移動体端末と前記ノードとの間の前記相互接続が、前記第１のＭＣ経由から第２のＭＣ経由に方向変換される際に、前記セッションを保持することを含むことを特徴とする請求項２８から請求項３０までのいずれかに記載の通信プロトコル。
【請求項３３】
前記第１のＭＣが、方向変換を要求するために、前記インターネット・プロトコル通信システムを介してメッセージを前記第２のＭＣに送信することを特徴とする請求項３１に記載のプロトコル。
【請求項３４】
前記第１の移動体端末と前記ノードとの間に第１の仮想メッセージ・パス（ＶＭＰ）として、前記第１のＶＭＰから第２のＶＭＰへ前記相互接続を転送するための該相互接続を確立することを含み、前記第１のＭＣが該第１のＶＭＰ内に含まれ、前記第２のＭＣが該第２のＶＭＰ内に含まれることを特徴とする請求項３１及び請求項３２のいずれか一つに記載の通信プロトコル。
【請求項３５】
前記第２のＭＣが、前記サーバ、又は前記ルータ、乃至前記更に別のＭＣに対して開くことを特徴とする請求項３１から請求項３３までのいずれか一つに記載のプロトコル。
【請求項３６】
前記ルータと前記ノードとの間を延びる前記第１のＶＭＰの一部を介して、該ルータから該ノードまで前記第２のＶＭＰを延ばすことを含む請求項３４に記載のプロトコル。
【請求項３７】
前記更に別のＭＣと前記更に別の移動体端末との間を延びる前記第１のＶＭＰの一部を介して、該更に別のＭＣから該更に別の移動体端末まで前記第２のＶＭＰを延ばすことを含む請求項３４に記載のプロトコル。
【請求項３８】
前記第２のＭＣが、前記サーバ、又は前記ルータ、乃至前記更に別のＭＣに、前記第１のＭＣ経由から前記第２のＭＣ経由に前記相互接続を方向変換するよう命令することを特徴とする請求項３１から請求項３６までのいずれか一つに記載のプロトコル。
【請求項３９】
前記相互接続の方向変換が、シームレスな方法で行われることを特徴とする請求項３１から請求項３７までのいずれか一つに記載の通信プロトコル。
【請求項４０】
前記相互接続の方向変換中、前記ルータが、前記第１のＭＣに加えて前記第２のＭＣからメッセージを受け取って該ノードに送り、同時に該ノードから受け取った全てのメッセージを該第２のＭＣを介して前記第１の移動体端末に送るように配置されることを特徴とする請求項３１から請求項３８までのいずれか一つに記載の通信プロトコル。
【請求項４１】
前記インターネット・セッションが、前記ノードによって開始され、前記第１の移動体端末と該ノードとの間の通信が、該第１の移動体端末により設けられたＶＭＰにわたって行われることを特徴とする請求項２７から請求項３９までのいずれかに記載の通信プロトコル。
【請求項４２】
前記インターネット・セッションが、前記第１の移動体端末によって開始され、該第１の移動体端末と前記ノードとの間の通信が、該第１の移動体端末により設けられたＶＭＰにわたって行われることを特徴とする請求項２７から請求項３９までのいずれか一つに記載の通信プロトコル。
【発明の詳細な説明】
【０００１】
（技術分野）
本発明は、通信システム及び該通信システムのための通信プロトコルに関し、より具体的には、インターネット・プロトコル通信システムにおいて、接続指向モードで移動体端末を適合させることができるようになったシステム及びプロトコルに関する。
【０００２】
（背景技術）
１．ａ．
「接続指向モード」については、Ｍａｒｃｏｎｉ通信会社に譲渡された、公開番号ＧＢ２３１３２７１号である公開された関連英国特許出願「通信ネットワーク」に説明されており、引用によりここに組み入れる。読み手にわかりやすくするために、接続指向モードについての短い概略を以下に述べる。
【０００３】
２．ａ．
接続指向モードは、インターネット・セッションが、従来の非接続指向のセッションと同様に接続指向の方法で行われることを可能にする。このことにより、インターネット・セッションが、パスのリンク毎に一つずつ、一連の仮想チャネルから成る仮想メッセージ・パスを使用することが必要になる。いったんセッションの開始時に仮想メッセージ・パスが確立されると、パスのリンクの各々について仮想メッセージ・パスを識別する番号だけを用いていずれの方向にもメッセージを送ることができ（仮想チャネル番号（ＶＣＮ）によって）、各々のメッセージにアドレスを付加する必要性がなくなる。
【０００４】
２．ｂ．
前置きとして、関連特許出願により公知の接続指向インターネット・セッションが、図１に関連して説明される。
接続指向モードは、２つのインターネット端末の間に仮想メッセージ・パスを確立することによって働き、これらの端末があたかも直接相互連結されているように対話型でつながることが可能になる（すなわち、ネットワークは、端末Ａ、活動ｘからの全てのメッセージが、端末Ｂ、活動ｙに伝えられなければならないと命じられ、逆もまた同様である）。従来のインターネットはインターネット・プロトコル通信システムの一例であるが、「接続指向」ではなく（すなわち、端末Ａと端末Ｂとの間の関係は命令されていない）、いずれかの端末からのメッセージ・パケットの各々が、他の端末に個別にアドレス指定されることが必要である。
【０００５】
２．ｂ．
「接続指向」セッションを確立するために、ユーザは、ローカル・インターネット・ルータ（インターネット・アクセス・ポイント）に仮想チャネルを開き、遠隔の宛先端末のインターネット・アドレスを含み、仮想メッセージ・パスを使用するトランスポート層の活動に利用可能なプロトコルを識別するＯＰＥＮメッセージを送信する。記述の最後には、各々のメッセージの型に対して適切なフォーマットが与えられる。以下において、セッションを開始するインターネット・アクセス・ポイントをユーザに提供するルータは、「ソース・ルータ」と呼ばれる。同様に、宛先端末にインターネット・アクセス・ポイントを提供するルータは、以下において「宛先ルータ」と呼ばれる。
【０００６】
インターネット・セッションは、該セッションに付加されるか又は該セッションの一部を形成する既存の仮想メッセージ・パスが移される更に別の仮想メッセージ・パス上の全ての活動と共に、最初のＯＰＥＮメッセージの結果として設定された仮想メッセージ・パス上の全ての活動を含むようになる。
従来のインターネットにおいて、ユーザは、ローカル・ルータを介して、所望の宛先端末のインターネット・ネームをインターネット・ドメイン・ネーム・サーバ（ＤＮＳ）に送信し、該サーバは、該ユーザに適切なアドレスを返信する。次に、ユーザは、インターネット・アドレスを使用して、所望の宛先にアクセスすることができる。従来のインターネット・アドレスは、２つの部分、すなわち宛先端末が位置するネットワークを識別するネットワーク・アイデンティティ（ＮｅｔＩＤ）と、識別されたネットワーク内の所望の宛先端末を固有に識別するユーザ・アイデンティティ（ＵｓｅｒＩＤ）から成る。
【０００７】
宛先端末が、「特別サービス」（以下を参照のこと）でない場合には、ソース・ルータは、宛先の方向にあるルータを識別し、次のルータへのリンク上にある仮想チャネル番号（例えば、図１のＶＣＮｘ）を割り当て、ＯＰＥＮメッセージを送る。このプロセスは、ソースから遠隔の宛先端末に至る連続する仮想チャネル（ＶＣ）から成る仮想メッセージ・パスが確立されるまで、繰り返される。遠隔の宛先端末は、選択されたプロトコル、リンクの容量、及び必要とされるスイッチング優先順位を示すＯＰＥＮ−ＤＯＮＥメッセージを戻す。ここでトランスポート層の活動が始まる。
【０００８】
２．ｃ．
各々のルータは、スイッチング・テーブルにパスを記録する。
例えば、リンクＡのチャネルＭは、リンクＢのチャネルＮに切り換え、リンクＢのチャネルＮは、リンクＡのチャネルＭに切り換える。
「Ｍ」と表記されたリンクＡからルータに達するメッセージは、「Ｎ」と再表記され、リンクＢの出力バッファに入れられ、逆もまた同様である。ソース・ルータにおけるスイッチング・テーブルは、ユーザ端末へのリンクの識別と、現在のセッションを固有に識別するためにユーザにより割り当てられた任意の参照番号とを含む。宛先ルータにおけるスイッチング・テーブルは、宛先端末へのリンクの識別と、該宛先端末への現在のセッションを固有に識別するために該宛先ルータにより割り当てられた任意の参照番号とを含む。
制御メッセージ（ＯＰＥＮ、ＣＬＯＳＥなど）は、制御メッセージ・チャネル、該メッセージを適用するチャネル番号を示す制御メッセージ・ヘッダを使用しており、該ヘッダは該制御メッセージがリンクからリンクへと送られるにつれて、修正される。
【０００９】
３．ａ．
図２を参照して特別サービス・セッションについて説明する。
特別サービス・セッションは、サーバ（すなわち、「宛先」端末上の）により提供されるサービスへの接続を要求するユーザから始めるものであるが、そこでは宛先端部からのＯＰＥＮ−ＳＥＲＶＩＣＥメッセージによって、ユーザ（すなわち、「ソース」）への接続を確立するサーバ（すなわち、「宛先」）によりサービスが実際に伝えられ、制御される。
３．ｂ．，３．ｃ．
ユーザが接続指向モードを介して特別サービスにアクセスするために、該ユーザは、既に述べたように宛先のインターネット・アドレスを取得するが、ＮｅｔＩＤは、もはや特定のネットワークを識別せず、特別サービスが要求されたことを識別するだけである。これは、通常の方法でＤＮＳにより与えられたインターネット・アドレスを使用するユーザにはトランスペアレントである。
【００１０】
３．ｄ．
ソース・ルータは、ユーザのＯＰＥＮメッセージが、特別サービスである宛先アドレスを特定することを認識し、ＳＥＲＶＩＣＥ＿ＡＣＫメッセージをユーザに戻し、ＳＥＲＶＩＣＥ＿ＲＥＱＵＥＳＴメッセージをソータに送信することにより反応するように設定されている（以下を参照のこと）。ソース・ルータはまた、料金レコードがある場合には、遠隔の宛先端部に該料金レコードが準備されることも認識する。
ＳＥＶＩＣＥ＿ＡＣＫメッセージは、トランスポート層の活動を開いたり閉じたりする主導権が遠隔の宛先端部にあり、そのため、必要に応じてユーザを別のサーバに転送する前にサーバが活動を閉じることが可能であることをユーザに伝える。
ＳＥＲＶＩＣＥ＿ＲＥＱＵＥＳＴメッセージは、宛先アドレス及びＯＰＥＮメッセージからの使用可能なプロトコルを繰り返す。このメッセージはまた、ユーザのインターネット・ネーム及びソース・ルータ自身のインターネット・アドレス並びにセッションのレコード番号も含む（以下を参照のこと）。
【００１１】
接続指向サービスを用いる場合、ルータは、該ルータにより取り扱われる各々のアクティブ・セッションの記録を維持する必要がある。仮想メッセージ・パスが閉じられた場合には、関連したセッションの記録が更新される。セッションの記録は、そのルータのセッションの一部に関するだけであり、該ルータがそのスイッチング・テーブル内の関連した入力項目を消去し、そのセッションに関連した仮想チャネル番号を公表し、リンク上の確保された容量を解放することを可能にする。セッション記録を、ユーザ口座、プロバイダ相互の口座、交信の記録、及び様々な内部の管理目的に使用することもできる。
関連出願において説明されるように、ソータは、適当なルータのいずれかに取り付けられ、そのルータ上の他の端末のいずれとも同様なインターネット・アドレスを有するメッセージ再アドレス指定サービスである。ソータを更新することにより、サービスを導入し、再配置し、又は終了させることができる。
【００１２】
ソータは、所望のサーバの真のインターネット・アドレスを識別するために、ＳＥＲＶＩＣＥ＿ＲＥＱＵＥＳＴメッセージにおける「遠隔・ホスト・アドレス」宛先アドレス・フィールドを使用する。ＳＥＲＶＩＣＥ＿ＲＥＱＵＥＳＴメッセージにおけるソータのアドレスは、所望の宛先の真のインターネット・アドレスに修正される。従って、ソータは、このＳＥＲＶＩＣＥ＿ＲＥＱＵＥＳＴメッセージを必要とされるサーバへ再アドレス指定する。
ソータを介してメッセージをサーバに送る際に、該サーバから始発ルータにＲＥＱＵＥＳＴ＿ＤＯＮＥメッセージ又はＦＡＩＬＵＲＥメッセージが戻るように、メッセージ・パスが生成される。
【００１３】
３．ｅ．，３．ｆ．
ユーザのアイデンティティを認識することにより、サーバが、そのユーザに適切であると考えられるサービスだけを提供し、サービスへの承認されていないアクセスを制御することが可能になる。
サーバは、ＯＰＥＮ＿ＳＥＲＶＩＣＥメッセージを使用し、ソース・ルータ、すなわちＳＥＲＶＩＣＥ＿ＲＥＱＵＥＳＴメッセージにおいて与えられたルータ・アドレスへの仮想メッセージ・パスを開く。ＯＰＥＮ＿ＳＥＲＶＩＣＥメッセージは、ソータから受信したＳＥＲＶＩＣＥ＿ＲＥＱＵＥＳＴメッセージから複写されたセッションのレコード番号と、ソース・ルータによる確認のためのユーザのインターネット・ネームとを含む。このメッセージはまた、選択されたプロトコル及びその容量、並びにそのセッションについて必要とされるメッセージスイッチング優先順位も示すが、その情報は、ＯＰＥＮ＿ＤＯＮＥメッセージに送られるまでは使用されない。インターネット・ネームの確認に失敗した場合には、ＢＳＣは、ＯＰＥＮ＿ＤＯＮＥメッセージの代わりにＦＡＩＬＵＲＥメッセージを戻す。
【００１４】
３．ｇ．
ＯＰＥＮ＿ＳＥＲＶＩＣＥメッセージは、ソース・ルータを除く全てのルータにより通常のＯＰＥＮメッセージとして扱われる。遠隔の宛先端部からＯＰＥＮ＿ＳＥＲＶＩＣＥメッセージを受信した場合には、ソース・ルータは、セッション・レコード番号を使用し、オリジナルのＯＰＥＮメッセージによって該ソース・ルータまでユーザにより確立されたオリジナルの仮想チャネルを識別する。ソース・ルータは、オリジナルの仮想チャネルを介して宛先からユーザまで仮想メッセージ・パスを延ばす。この動作は、仮想メッセージ・パスを「ピックアップする」と言われる。仮想メッセージ・パスが、ＯＰＥＮ　ＴＲＡＮＳＦＥＲメッセージ又はＯＰＥＮ＿ＭＯＢ＿ＴＲＡＮＳＦＥＲメッセージに応答して変えられる際に、同じ動作が要求される（以下を参照のこと）。
【００１５】
３．ｈ．，３．ｉ．
サーバは、ＴＲＡＮＳＦＥＲ＿ＲＥＱＵＥＳＴメッセージ又はＡＤＤ＿ＲＥＱＵＥＳＴメッセージにおいて、ＳＥＲＶＩＣＥ＿ＲＥＱＵＥＳＴメッセージの関連内容を別のサーバに送り、別のサーバにサービスの伝達を転送できるようにするか、又は付加的なサーバを導入することによりサービスの伝達を補う。ユーザは、転送プロセスには関係せず、付加的なサーバのアドレスを取得せず、従って後に続く機会においては第１のサーバをバイパスすることはできない。また、サービスは、新しいサーバ又は付加的なサーバによって直接ユーザに伝えられ、伝えられたサービスの詳細は、サービスの伝達に関係する他のサーバにいずれにも明らかにされない。例えば、第１の特別サービスのサーバを保険仲介人とし、付加的なサーバを関連した保険会社のアクセス・ポイントとすることができる。代わりに、第１のサーバを、ビジネスの全ての構成要素内に位置する付加的なサーバにつながり、更にそれらの下請業者及び孫請業者につながる多国籍企業の本部としてもよい。
【００１６】
３．ｊ．
サーバは、トランスポート層の活動を閉じ、ＴＲＡＳＦＥＲ＿ＲＥＱＵＥＳＴメッセージを他のサーバに送信することによって、ユーザを別のサーバに移す。ＴＲＡＮＳＦＥＲ＿ＲＥＱＵＥＳＴメッセージは、オリジナルのＳＥＲＶＩＣＥ＿ＲＥＱＵＥＳＴメッセージと同じ情報を含むが、既存の仮想メッセージ・パスを迂回しなければなければならないことを示す。通常、メッセージは、他のサーバに直接アドレス指定されるが、既に述べたようにソータを介してアドレス指定することもでき、この場合には、関連出願に説明されるように、「遠隔＿ホスト＿アドレス」フィールドを更新しなければならない。
ＴＲＡＳＦＥＲ＿ＲＥＱＵＥＳＴメッセージは、セッションの早い段階の間に得られた情報を含むことができ、いずれのパーティが転送されるサービスに対して対価を払うと予想されるかを示すことができる。このような情報の全てが、インターネットに重要なのではない。ＴＲＡＮＳＦＥＲ＿ＲＥＱＵＥＳＴメッセージは、新しいサーバ、及び該新しいサーバから転送を開始するサーバへＲＥＱＵＥＳＴ＿ＤＯＮＥメッセージ又はＦＡＩＬＵＲＥメッセージを戻すために生成されたメッセージ・パスに送られる。
【００１７】
３．ｋ．
新しいサーバは、ＯＰＥＮ＿ＴＲＡＮＳＦＥＲメッセージを使用し、ソース・ルータへの仮想メッセージ・パスを生成する。このメッセージは、ＯＰＥＮ＿ＳＥＲＶＩＣＥメッセージに類似しており、ソース・ルータのセッション・レコード番号と、ＴＲＡＮＳＦＥＲ＿ＲＥＱＵＥＳＴメッセージからのユーザのインターネット・ネームとを含む。このメッセージはまた、新しい容量及び優先順位必要条件を含む仮想メッセージ・パスの新しい部分にわたって使用するための新しいサーバによって選択されたプロトコルを示すが、この情報は、ＯＰＥＮ＿ＤＯＮＥメッセージに転送されるまで使用されない。
【００１８】
３．ｌ．
ＯＰＥＮ＿ＴＲＡＮＳＦＥＲメッセージは、セッションを識別して、ユーザへのメッセージ・パスをピックアップするためにセッション・レコード番号を使用するように働くソース・ルータ以外の全てのルータによって、通常のＯＰＥＮメッセージとして扱われる。ＯＰＥＮ＿ＴＲＡＮＳＦＥＲメッセージはまた、該ＯＰＥＮ＿ＴＲＡＮＳＦＥＲメッセージにおいて示されるプロトコル及び容量並びに優先順位必要条件を含むＯＰＥＮ＿ＤＯＮＥメッセージを新しいサーバ及びユーザに戻す。メッセージのタイトルは、セッション・レコード及びスイッチング・テーブルが元のメッセージ・パスに関する入力項目を含むことをソース・ルータに伝える。これらの入力項目は更新しなければならず、ＣＬＯＳＥ＿ＲＥＱＵＥＳＴメッセージを元のメッセージ・パス上にある古いサーバに送信しなければならない。
【００１９】
３．ｍ．
ＯＰＥＮ＿ＤＯＮＥメッセージを受け取ると、新しいサーバは、ＲＥＱＵＥＳＴ＿ＤＯＮＥメッセージを、ＴＲＡＮＳＦＥＲ＿ＲＥＱＵＥＳＴによって生成されたメッセージ・パス上の古いサーバに戻す。ＲＥＱＵＥＳＴ＿ＤＯＮＥメッセージを受け取ると、古いサーバは、ＴＲＡＮＳＦＥＲ＿ＲＥＱＵＥＳＴメッセージ・パスを閉じ、ソース・ルータからＣＬＯＳＥ＿ＲＥＱＵＥＳＴメッセージを受け取ると、古いサーバは、元のメッセージ・パスを閉じる。
【００２０】
３．ｎ．，３．ｏ．
サーバは、ＴＲＡＮＳＦＥＲ＿ＲＥＱＵＥＳＴメッセージ内に含まれるものと同じ情報を含む新しいサーバにＡＤＤ＿ＲＥＱＵＥＳＴメッセージを送信することにより、別のサーバを付加することができる。新しいサーバは、ＯＰＥＮ＿ＴＲＡＮＳＦＥＲメッセージ内に含まれるものと同じ情報を含むＯＰＥＮ＿ＡＤＤメッセージを用いて、ユーザへの新しい仮想メッセージ・パスを確立する。ソース・ルータは、ＯＰＥＮ＿ＤＯＮＥメッセージを新しいルータに戻し、該新しいルータは、ＲＥＱＵＥＳＴ＿ＤＯＮＥメッセージを付加を開始したサーバに送信する。関連出願に説明されたように（第１部「ホスト／ルータのリンク」と題された節の「仮想メッセージ・パスの生成」を参照のこと）、サブ・セッション番号を割り当て、多数のサーバが同じ仮想チャネルにわたって、同じセッションの一部としてユーザと通信状態にある状況に対処することができる。従って、ソース・ルータは、新しい仮想メッセージ・パスに対してサブ・セッション番号を割り当て、該番号をユーザへのＡＤＤ＿ＤＯＮＥメッセージのヘッダ内に含む。ＡＤＤ＿ＤＯＮＥメッセージはまた、ＯＰＥＮ＿ＤＯＮＥメッセージ内に含まれるものと同様の情報も含む。サブ・セッション番号は、新しい仮想メッセージ・パスにわたるトラフィックの流れを識別し、ユーザが異なる仮想メッセージ・パスを介して送信されたトラフィックか、又は受信されたトラフィックかを区別できるようにするためのものである。
３．ｐ．
ＡＤＤ＿ＤＯＮＥメッセージを受け取ると、ユーザ端末は必要に応じて新しい活動を開き、新しいサーバとの間のトラフィックを処理する。しかしながら、従来技術の接続指向モードは、移動体端末の必要性を支持するものである。
【００２１】
（発明の開示）
本発明は、インターネット・プロトコル通信システムを介して該第１の移動体端末と該ノードとの間に接続指向相互接続を確立するための通信プロトコルを提供するものであり、このプロトコルにおいては、第１の移動体端末とノードがインターネット・セッションの一部を形成しており、該第１の移動体端末が最初に第１の移動体コントローラ（ＭＣ）を介して該ノードに接続されており、該通信プロトコルは、該ノードに関するインターネット・アドレスと該インターネット・セッションを識別するレコード番号を該第１のＭＣに提供するための手段を含む。
好ましい実施形態によると、本発明は、第１の移動体端末とノードとの間の相互接続が第１のＭＣ経由から第２のＭＣ経由へ方向変換される際に、セッションを維持する段階を含む。
本発明の好ましい実施形態が、図面に関連した例により説明される。
【００２２】
（発明を実施するための最良の形態）
４．移動体端末により終了するセッション
本発明による、移動体端末により終了するセッションが、図３に関連して説明される。
４．ａ．
移動体ネットワークは、移動体端末が常に少なくとも一つのアンテナ塔の範囲内にあるように配置されたアンテナ塔のネットワークから構成される。実際に、ネットワークの極先端部を除いて、端末は常に幾つかの塔の範囲内にある。
４．ｂ．
使用中であるか又は休止状態のいずれかの、全てのオンラインの（スイッチが入っている）移動体端末が、常に全ての範囲内の塔を監視し、且つこれに監視されている。対話式のプロセスにより、塔と端末が各々の端末について現在最も適切な塔を識別できるようになる。このように識別された塔が、端末の現在位置であると考えられる。端末があちらこちらに移動するに伴い、状況は常に更新される。
【００２３】
４．ｃ．
オンラインの移動体端末の各々の現在位置及びアイデンティティは、ネットワーク位置レジスタ（例えば、移動体ネットワークＨＱに位置する）に報告され、いつトラフィックが移動体端末に向けられることになるかを該ネットワーク位置レジスタに照会しなくてはならない。
４．ｄ．
幾つかの隣接するアンテナ塔は、これらの塔と大きなネットワークとの間のアクセス・ポイントであり、電話ネットワーク及びインターネットへのアクセスを可能にする単一の基地局コントローラ（ＢＳＣ）によって制御される。
４．ｅ．
セッション中間において、移動体端末が一つのアンテナ塔から別のアンテナ塔へと移動する際には、ネットワークが順序正しく「引き継ぎ」されるようにしなければならない。
４．ｆ．
本発明によると、各々のＢＳＣは、インターネット・ルータへのアクセスを有し、インターネット・アドレスが割り当てられるが、移動体ネットワークはインターネットの一体部分ではなく、他の通信手段（例えば、公衆向け交換機型の電話ネットワークなど）へのアクセスを有することもできる。
【００２４】
５．ａ．
図３を参照すると、本発明の好ましい実施形態によると、移動体端末のネットワーク・アイデンティティ（ＮｅｔＩＤ）が、特別サービスのＮｅｔＩＤとなる。ユーザが移動体端末へのアクセスを要求した場合には、ユーザのソース・ルータが、ＳＥＲＶＩＣＥ＿ＡＣＫメッセージをユーザに、且つＳＥＲＶＩＣＥ＿ＲＥＱＵＥＳＴメッセージをソータに送信する。ルータはまた、遠隔端部において料金レコードが（ある場合には）作成されることも識別する。
ソータは、移動体端末の現在位置及び各々の移動体端末の現在アクティブなＢＳＣのアイデンティティを保持する適切な移動体位置サービス（ＭＬＳ）に、ＳＥＲＶＩＣＥ＿ＲＥＱＵＥＳＴメッセージを再アドレス指定する。ＭＬＳは、ＳＥＲＶＩＣＥ＿ＲＥＱＵＥＳＴメッセージを移動体端末の現在アクティブなＢＳＣに再アドレス指定し、該ＢＳＣは該メッセージを移動体端末に送信する。
【００２５】
５．ｂ．
ＳＥＲＶＩＣＥ＿ＡＣＫメッセージは、遠隔の宛先端部が特別サービスか又は移動体端末のいずれであるかをユーザに知らせる。トランスポート層の活動を開いたり閉じたりする主導権は、遠隔の宛先端部にある。
５．ｃ．
ＳＥＲＶＩＣＥ＿ＲＥＱＵＥＳＴメッセージを受け取ると、移動体端末は、ソース・ルータのアドレスと、ＯＰＥＮ＿ＳＥＲＶＩＣＥメッセージ内のＳＥＲＶＩＣＥ＿ＲＥＱＵＥＳＴメッセージから得られたセッション・レコード番号とを使用し、インターネットを通りソース・ルータに至る仮想メッセージ・パスを開け、ユーザまでの該仮想メッセージ・パスをピックアップする。ＢＳＣは、ソース・ルータのアドレスと、該ＢＳＣ自体のセッション内のＯＰＥＮ＿ＳＥＲＶＩＣＥから得られたセッション・レコード番号、すなわちセッション中に移動体端末が別のＢＳＣに移動する場合に使用するためのレコードを格納する。
【００２６】
５．ｄ．
必要に応じて、セッションについての料金レコードは、移動体ネットワークにおいて発話される通話に対してＢＳＣにより現在作成されるものと同様の方法でＢＳＣにより作成される。通常、遠隔の（ソース）端部は、メッセージにおけるユーザのインターネット・ネームにより識別された通りに、ＯＰＥＮ＿ＳＥＲＶＩＣＥメッセージを用いて開けられたセッションに対して課金されるが、移動体端末がサーバとして働く場合には、該移動体端末が料金を負担するか又は補助することを望むであろう。料金レコードはまた、インターネットの使用に対して移動体ネットワーク・プロバイダに課金するために、ＢＳＣのローカル・ルータによって作成してもよい。このような詳細の全ては、事実上管理事務に関わることであり、本発明にとっては重要でない。
【００２７】
５．ｅ．
ＯＰＥＮ＿ＳＥＲＶＩＣＥメッセージはまた、選択されたプロトコル及び容量が仮想メッセージ・パスのために必要とされたが、ソース・ルータによって移動体端末及びユーザに戻されたＯＰＥＮ＿ＤＯＮＥメッセージに送られるまで情報が使用されないことも示す。ＯＰＥＮ＿ＤＯＮＥメッセージは、ユーザに選択されたプロトコルを示し、メッセージ・パスを完了する仮想メッセージ・パス（この場合には移動体端末）を設ける端部を知らせる。それらはまた、保存されるべきネットワークの容量及び仮想メッセージ・パスに必要とされるメッセージのスイッチング優先順位をメッセージ・パスに沿った全てのルータに示す。
【００２８】
６．ａ．移動体端末が新しいＢＳＣ領域に移動する。
図３Ａ及び図３Ｂに関連して、移動体の移動及び「シームレス」な引き継ぎについて説明される。セッション中間において、移動体端末が一つのＢＳＣ領域から別の領域に移動する際に、第１のＢＳＣが、インターネットを介してＭＯＢ＿ＴＲＡＮＳＦＥＲ＿ＲＥＱＵＥＳＴメッセージを新しいＢＳＣに送信する（図３Ａを参照のこと）。この目的のために、各々のＢＳＣは、隣接するＢＳＣのインターネット・アドレスを知る必要がある。このメッセージは、移動体端末を識別し、ソース・ルータのアドレス及びＯＰＥＮ＿ＳＥＲＶＩＣＥメッセージから取得されたセッション・レコード番号を繰り返す。
【００２９】
６．ｂ．
新しいＢＳＣは、新しいアンテナ塔を介して移動体端末からメッセージを受け取る準備をするが、引き継ぎを終える前にユーザから受け取ることができる、移動体端末に向けたあらゆるメッセージを格納するためにバッファを設ける。次に、新しいＢＳＣは、ＭＯＢ＿ＴＲＡＮＳＦＥＲ＿ＲＥＱＵＥＳＴメッセージからのアドレス及びレコード番号と共にＯＰＥＮ＿ＭＯＢ＿ＴＲＡＮＳＦＥＲメッセージを使用して、インターネットを介して仮想メッセージ・パスを開き、ユーザまでの該仮想メッセージ・パスをピックアップする。ＯＰＥＮ＿ＭＯＢ＿ＴＲＡＮＳＦＥＲメッセージにおける用語ＭＯＢは、「シームレス」な移動が必要とされること、すなわち、セッションを妨害することなく、該セッションが使用する仮想メッセージ・パスを変えることを示す。
従って、新しいＢＳＣは、アンテナ塔を介して移動体端末からメッセージを受け取った際に該メッセージはユーザに送信され、ユーザから受け取ったメッセージは、該新しいＢＳＣにおいてバッファに入れるように（新しいアンテナ塔に変わったときに移動体に送られるように）手配する。
【００３０】
６．ｃ．
ＯＰＥＮ＿ＭＯＢ＿ＴＲＡＮＳＦＥＲメッセージは、セッションを識別して新しい仮想メッセージ・パスを使用するようにそのスイッチング・テーブルを修正するためにセッション・レコード番号を使用するように働くソース・ルータ以外の全てのルータにより、通常のＯＰＥＮメッセージとして扱われる。しかしながら、ソース・ルータは、古い仮想メッセージ・パス上にある移動体から受け取ったメッセージを送り続ける。
従って、ＯＰＥＮ＿ＭＯＢ＿ＴＲＡＮＳＦＥＲメッセージを受け取ると、ソース・ルータは、古い仮想メッセージ・パスか又は新しい仮想メッセージ・パスのいずれかの移動体から受け取ったメッセージをユーザに送り、ユーザから移動体へのメッセージは、新しいチャネルにだけ送信されるように手配する。
【００３１】
６．ｄ．
図３Ｂを参照して、引き継ぎの完了について説明する。ＯＰＥＮ＿ＭＯＢ＿ＴＲＡＮＳＦＥＲメッセージの受信に続く次の段階は、ソース・ルータが、新しい仮想メッセージ・パスを介してＯＰＥＮ＿ＤＯＮＥメッセージを新しいＢＳＣに戻し、古い仮想メッセージ・パスを介してＣＬＯＳＥ＿ＲＥＱＵＥＳＴメッセージを古いＢＳＣに送信することである。ＯＰＥＮ＿ＤＯＮＥメッセージは、古い仮想メッセージ・パスからの容量及び優先順位の必要条件を繰り返す（「選択されたプロトコル」フィールドは使用されない）。
６．ｅ．
ＯＰＥＮ＿ＤＯＮＥメッセージを受け取ると、新しいＢＳＣは、ＲＥＱＵＥＳＴ＿ＤＯＮＥメッセージを古いＢＳＣに送り、該古いＢＳＣは、ＭＯＢ＿ＴＲＡＮＳＦＥＲ＿ＲＥＱＵＥＳＴメッセージによって生成された仮想メッセージ・パスを閉じる。
【００３２】
６．ｆ．
ＣＬＯＳＥ＿ＲＥＱＵＥＳＴメッセージは、ソース・ルータが新しいメッセージ・パスを使用し始めたことを示す。このメッセージが古いＢＳＣで受け取られるまでには、古いメッセージ・パスを介するパイプライン内のユーザから移動体への如何なるメッセージも消去される。メッセージを受け取ると、古いＢＳＣは、新しいアンテナ塔に変更するように（すなわち、新しいＢＳＣを介して通信を開始するように）移動体に命令する。移動体が変わったことを検知した際には、古いＢＳＣは、ＣＬＯＳＥメッセージを古い仮想メッセージ・パス上のソース・ルータに送信する。ＣＬＯＳＥメッセージは、古いＢＳＣが古いメッセージ・パスの使用をやめたこと、及び該メッセージがソース・ルータに達するまでには、古い仮想メッセージ・パスを介したパイプライン内の移動体からユーザへの如何なるメッセージも消去されることを示す。ソース・ルータは、ＣＬＯＳＥメッセージを受け取ったとき、そのスイッチング・テーブルを修正し、古い仮想メッセージ・パスから受け取ったメッセージをユーザに送るのをやめる。移動体が新しいアンテナ塔に移動したことを新しいＢＳＣが検知すると、該新しいＢＳＣは、その記憶装置のバッファの内容を移動体端末に送信し、空の場合には、スイッチング・テーブルを修正し、それから先のメッセージは移動体端末に直接送信する。
【００３３】
移動体端末により開始するセッション
前節では、インターネット・セッションの宛先端部において、どのように移動体端末を対応させることができるかを示した。移動体端末によってどのインターネット・セッションを始めることができるかに基づいて、図４、図５及び図５Ａに関連して本発明の更に別の好ましい実施例形態が説明される。この実施形態によると、固定端末で始められたセッションに関連して上述されたものと同様の手順を用いることができる。
【００３４】
７．ａ．固定端末に対する移動体端末
通常のセッション（すなわち、特別サービスでも、別の移動体端末でもない）を始める際の移動体端末の動作について、図４に関連して説明する。
移動体端末は、宛先端部のアドレスを含み、利用可能なプロトコルを列挙する該移動体端末のＢＳＣ（「ソース」ＢＳＣ）にＯＰＥＮ＆ＲＥＦＲＥＱメッセージを送信することによりセッションを始める。メッセージのタイトルに含まれる用語「ＲＥＦＲＥＱ」は、宛先ルータが、そのアドレスとセッション・レコード番号を始発ＢＳＣに戻さねばならないことを示す。
７．ｂ．
ＯＰＥＮ＆ＲＥＦＲＥＱメッセージをソース・ルータ（すなわち、ソースＢＳＣのインターネット・アクセス・ポイント）に送る前に、該ソースＢＳＣは、該メッセージに該ソースＢＳＣ自体のアドレスと、セッション・レコード番号と、移動体端末のインターネット・ネームとを付加する（移動体端末には、安全上の理由から該移動体端末自身の名前をつけない）。遠隔端部のアドレスが特別サービス又は別の移動体端末である場合には、この情報はＢＳＣのローカル・ルータにより使用される。
【００３５】
７．ｃ．
遠隔端部のアドレスが、特別サービスでも別の移動体端末でもない場合には、ＯＰＥＮ＆ＲＥＦＲＥＱメッセージは、宛先ルータすなわち宛先端末のインターネット・アクセス・ポイントを除く全てのルータにより通常のＯＰＥＮメッセージとして扱われる。ＯＰＥＮ＿ＤＯＮＥメッセージを戻すアドレス指定された宛先端末への仮想メッセージ・パスを完成する前に、宛先ルータは、インターネット・アドレスとレコード番号を含むＯＰＥＮ＿ＡＣＫメッセージをソースＢＳＣに戻す。
【００３６】
７．ｄ
ＯＰＥＮ＿ＡＣＫメッセージを受け取ると、ソースＢＳＣは、宛先ルータのアドレス及びセッション・レコード番号を格納する。ＯＰＥＮ＿ＡＣＫメッセージはまた、例えばアドレス指定された宛先端末が立ち上がり手続きの使用を必要とするときには、ＯＰＥＮ＿ＤＯＮＥメッセージを送信できるようになるまでに、遅れが生じ得ることも示す。
遠隔端部が料金レコードを作成することを示すＳＥＲＶＩＣＥ＿ＡＣＫメッセージが、ＢＳＣを介して移動体端末に送られなければ、ＢＳＣは、該ＢＳＣを介して接続された移動体端末がソースとして働く全てのセッションについて料金レコードを作成する。ＢＳＣは、移動体端末の請求をする移動体ネットワークのＨＱに請求書を送付する。
【００３７】
ソース移動体端末が、新しいＢＳＣに移動する（固定された遠隔端部）
セッション中に１つのアンテナ塔から別のアンテナ塔に移動した場合には、ソース移動体端末は新しいＢＳＣ領域に移動し、古いＢＳＣは、ＭＯＢ＿ＴＲＡＮＳＦＥＲ＿ＲＥＦＲＥＱメッセージをインターネットにより新しいＢＳＣに送信する。このメッセージは、移動する移動体端末を識別し、インターネット・アドレスとＯＰＥＮ＿ＡＣＫメッセージからのセッション・レコード番号とを提供する。今や移動体端末はソース端部にあり、固定端末が宛先端部にあることに留意して、図３Ａ及び図３Ｂに関連して上述された「シームレス」な引き継ぎが続けられる。
【００３８】
９．ａ．移動体から移動体又は移動体から特別サービス・セッションへ
移動体端末間において、又は移動体端末から特別サービス端末までのインターネット・セッションを確立することができる本発明の更に別の実施形態が図５及び図５Ａを参照して以下に説明される。
９．ｂ．
図５及び図５Ａを参照すると、ソースが移動体端末であり、ＯＰＥＮ＆ＲＥＦＲＥＱメッセージ内の宛先アドレスが特別サービス又は移動体端末を識別するとき、ソース・ルータは、ＢＳＣを介してＳＥＲＶＩＣＥ＿ＡＣＫメッセージをソース移動体端末に戻す。
ソースＢＳＣが、ＯＰＥＮ＿ＡＣＫメッセージにおいて参照を受け取ることを予期している。ＳＥＲＶＩＣＥ＿ＡＣＫメッセージの受信は、宛先端部が、ソース移動体端末が移動する場合に新しいソース端部参照を必要とするサーバ又はＢＳＣであることをソースＢＳＣに知らせる。宛先端部から必要とされる参照が、以下に述べられるようにＯＰＥＮ＿ＳＶＣＥ＆ＲＥＦメッセージにもたらされる。メッセージはまた、料金レコードが遠隔端部において準備されることも示す。
【００３９】
９．ｃ．
ソース・ルータはまた、サービスの伝達を実行し、ソースが移動体端末であって、そのＢＳＣ（すなわち、サーバ又は終端ＢＳＣのアドレス及びセッション・レコード番号）が参照を必要とするものであることを示すＳＶＣＥ＆ＲＥＦ＿ＲＥＱＵＥＳＴメッセージをソータに送信する。ソータは、要求されるサーバに直接、又は移動体位置サービス及び現在アクティブなＢＳＣを介して、必要とされる移動体端末にメッセージを再アドレス指定する。ＳＶＣＥ＆ＲＥＦ＿ＲＥＱＵＥＳＴメッセージにおけるインターネット・ネーム、インターネット・アドレス、及びセッション・レコード番号は、オリジナルのＯＰＥＮ＆ＲＥＦＲＥＱメッセージにおいてソースＢＳＣにより与えられることになる。
【００４０】
９．ｄ．
宛先特別サービス・サーバ又は移動体端末は、ＳＶＣＥ＆ＲＥＦ＿ＲＥＱＵＥＳＴメッセージにおいて与えられたユーザのインターネット・ネーム、ソースＢＳＣのアドレス及びセッション・レコード番号を含むＯＰＥＮ＿ＳＶＣＥ＆ＲＥＦメッセージを使用し、インターネットを介して仮想メッセージ・パスをソースＢＳＣまで開き、インターネット・ネームを確認し、セッション・レコード番号を使用し、該仮想メッセージ・パスを始発の移動体端末までピックアップする。　ＢＳＣは、該ＢＳＣにより使用されるチャネルを閉じ、オリジナルのＯＰＥＮ＆ＲＥＦ＿ＲＥＱＵＥＳＴメッセージをローカル・ルータに送る。
【００４１】
９．ｅ．
サーバは、ＯＰＥＮ＿ＳＶＣＥ＆ＲＥＦメッセージ内に該サーバ自身のアドレス及びセッション・レコード番号を含む。宛先ＢＳＣは、そのアドレス及びセッション・レコード番号をメッセージ（移動体端末により生成される）に付加し、宛先移動体端末が別のＢＳＣに移動するときに使用するために、該メッセージから、ソースＢＳＣのアドレス及びセッション・レコード番号を、セッション・レコードに複写する。ソースＢＳＣは、ソース移動体端末が別のＢＳＣに移動するときに、使用するメッセージに備えられる宛先参照を格納する。
９．ｆ．
従って、両端部が、必要に応じて、及び必要とされる時に、セッションを移すか又は引き継ぎすることを可能にする参照（遠隔端部のアドレス及びセッション・レコード番号）を持つことになる。
【００４２】
１０．ａ．遠隔端部の移動体端末を用いたサービスの転送
ユーザが移動体端末である場合において、サーバがユーザを別のサーバに移す必要がある場合には、該サーバは、ＴＲＡＮＳＦＥＲ＿ＲＥＱＵＥＳＴメッセージと同じ情報を含むＴＦＲ＆ＲＥＦ＿ＲＥＱＵＥＳＴメッセージを新しいサーバに送信することによってサービスの移送を開始するが、このメッセージに含まれている用語「＆ＲＥＦ」は、遠隔端部が新しいサーバのアドレス及びセッション・レコード番号を必要とすることを示している。新しいサーバは、ＯＰＥＮ＿ＴＦＲ＆ＲＥＦメッセージを使用し、ソースＢＳＣへのメッセージ・パスを生成し、移動体端末までの該メッセージ・パスをピックアップする。メッセージは、ＯＰＥＮ＿ＴＲＡＮＳＦＥＲメッセージと同じ情報を含むが、新しいサーバのアドレスとセッション・レコードを含む。ＢＳＣは、ＯＰＥＮ＿ＤＯＮＥメッセージを新しいサーバに戻し、前述のように古いメッセージ・パス上のＣＬＯＳＥ＿ＲＥＱＵＥＳＴメッセージを送信する。ＢＳＣはまた、ＯＰＥＮ＿ＳＶＣＥ＆ＲＥＦメッセージから取得された古いサーバの参照を、ＯＰＥＮ＿ＴＦＲ＆ＲＥＦメッセージに与えられた新しいサーバの参照と置き換える。
【００４３】
１１．ａ．移動体端末が別のＢＳＣ領域に移動する−遠隔端部におけるサーバ又は移動体端末。
遠隔端部がサーバ又は別の移動体端末である場合には、ＭＯＢ＿ＴＦＲ＆ＲＥＦ＿ＲＥＱＵＥＳＴメッセージをＢＳＣにより用いて、別のＢＳＣへの引き継ぎを開始する。このメッセージは、ＭＯＢ＿ＴＲＡＮＳＦＥＲ＿ＲＥＱＵＥＳＴメッセージと同じ情報を含むが、これに含まれる用語「＆ＲＥＦ」は、遠隔端部が新しいＢＳＣのアドレスとセッション・レコード番号を必要とすることを示す。ＭＯＢ＿ＴＦＲ＆ＲＥＦ＿ＲＥＱＵＥＳＴメッセージはまた、新しいＢＳＣが、セッションのソース端部にあるか又は宛先端部にあるかが分らないので、いずれの端部が請求レコードを作成するか（ある場合には）を示す。
【００４４】
１１．ｂ．
新しいＢＳＣは、ＯＰＥＮ＿ＭＯＢ＿ＴＲＡＮＳＦＥＲメッセージと同じ情報を含むＯＰＥＮ＿ＭＯＢ＿ＴＦＲ＆ＲＥＦメッセージを使用し、遠隔のサーバ又はＢＳＣへの仮想メッセージ・パスを生成し、前述のようにシームレスな方法でセッションをピックアップする。ＯＰＥＮ＿ＭＯＢ＿ＴＦＲ＆ＲＥＦメッセージは、新しいＢＳＣのアドレスとセッション・レコード番号を含む。遠隔端部において、サーバ又はＢＳＣは、既に格納された参照をメッセージ内に含まれるものと置き換える。
【００４５】
１１．ｃ．
ＯＰＥＮ＿ＭＯＢ＿ＴＦＲ＆ＲＥＦメッセージは、ソース、宛先及びゲートウェイ・ルータが必要な料金レコード（ある場合には）を作成できるように、いずれの端部が該料金レコード作成するかを示す。ここで、ゲートウェイ・ルータは、別のプロバイダのネットワークへのリンクを有するルータであり、プロバイダ相互の課金のために料金レコードを作成することが必要となることがある。
【００４６】
１２．
オリジナルのＳＶＣＥ＆ＲＥＦ＿ＲＥＱＵＥＳＴメッセージ（図５及び図５）は、ソースが、参照、及び宛先ＢＳＣへの必要条件を伝えた宛先移動体端末によるＯＰＥＮ＿ＳＶＣＥ＆ＲＥＦの使用を必要とすることを、宛先サーバ又は移動体端末に知らせた。初期設定中にＯＰＥＮ＿ＳＶＣＥ＆ＲＥＦメッセージを受け取ることは、宛先端部が参照を必要としていることをソースＢＳＣに知らせるものである。その後、参照を提供することの必要性は、ＲＥＱＵＥＳＴメッセージのタイトルに「＆ＲＥＦ」を用いることにより永続する。
【００４７】
１３．ａ．，１３．ｂ．
本発明の更に別の実施形態によると、ＢＳＣとＭＬＳとの間のメッセージ交換は、インターネット・アクセスを有する移動体端末のインターネット・ネームを含む。これは、ＭＬＳが、このような移動体端末のインターネット・ネームを知っていることを必要とする。ＭＬＳに報告をするメッセージの交換は、重畳する移動体ネットワークを用いるものへの代替としてインターネット上で有利に行うことができる。
本発明は、インターネットに関連した例によって説明された。しかしながら、本発明の範囲は、インターネットへの適用に限定されるものではなく、全てのインターネット・プロトコル通信システムに適用することができる。
【００４８】
制御メッセージ
この節は、移動体端末を含む通信に必要とされるものを含む、強化されたインターネットに用いられる制御メッセージのフォーマットを列挙する。使用において、以下のメッセージの各々は、例えば、
スタート
ＶＣＮ　００００（制御メッセージ・チャネル）
全体のメッセージ長さ
割り当てられたＶＣＮ
制御メッセージ（以下のとおり）
ストップ
などのメッセージが、関係する仮想チャネル番号（ＶＣＮ）を識別するリンク・ヘッダ・メッセージに先行する。
【００４９】
上記に言及された制御メッセージについての適切なフォーマットは以下のとおりである。
ＯＰＥＮメッセージ
ＩＰバージョン
メッセージの長さ
機能−ＯＰＥＮ
遠隔＿ホスト＿アドレス
ポート（１）
利用可能なプロトコル（２）
チェックサム
（１）ユーザにより特定されたプロトコル・インジケータから取り出される。
（２）サービスの伝達のために利用可能なプロトコルを列挙する。プロトコルの番号を長さのフィールド又は「より多くの」フラッグから推論することができる。
ＯＰＥＮ＆ＲＥＦＲＥＱメッセージ
（終端の端部からの参照を要求するために移動体により使用される）
ＩＰバージョン
メッセージの長さ
機能−ＯＰＥＮ＆ＲＥＦＲＥＱ
遠隔＿ホスト＿アドレス
ポート
利用可能なプロトコル
オリジナルのＢＳＣのアドレス（１）
ＢＳＣのセッション・レコード（１）
ユーザのインターネット・ネーム（１）
チェックサム
（１）遠隔ホストが特別サービス又は別の移動体端末である場合には、始発ＢＳＣが、ＳＶＣＥ＆ＲＥＦ＿ＲＥＱＵＥＳＴメッセージに使用するために、アドレス、レコード番号、及びユーザのインターネット・ネームを全てのＯＰＥＮ＆ＲＥＦＲＥＱメッセージに付加する。
ＯＰＥＮ＿ＡＣＫメッセージ（遅れたＯＰＥＮ＿ＤＯＮＥメッセージの前）
ＩＰバージョン
メッセージの長さ
機能−ＯＰＥＮ＿ＡＣＫ
遠隔ルータ・アドレス（１）
セッション＿レコード番号（１）
チェックサム
（１）基本的なＡＣＫメッセージはパラメータを含まない。ＯＰＥＮ＆ＲＥＦＲＥＱメッセージに応答して使用された場合には、宛先ルータのアドレス及びセッション・レコード番号を保持する。
ＯＰＥＮ＿ＤＯＮＥメッセージ
ＩＰバージョン
メッセージの長さ
機能−ＯＰＥＮ＿ＤＯＮＥ
選択されたプロトコル
フォワード容量及び優先順位
バックワード容量及び優先順位
チェックサム
【００５０】
ＣＬＯＳＥ＿ＲＥＱＵＥＳＴメッセージ
ＩＰバージョン
メッセージの長さ
機能−ＣＬＯＳＥ＿ＲＥＱＵＥＳＴ（パラメータなし）
チェックサム
ＣＬＯＳＥメッセージ
ＩＰバージョン
メッセージの長さ
機能−ＣＬＯＳＥ（パラメータなし）
チェックサム
ＣＬＯＳＥ＿ＡＣＫメッセージ（リンク毎、端末相互間ではない）
ＩＰバージョン
メッセージの長さ
機能−ＣＬＯＳＥ＿ＡＣＫ（パラメータなし）
チェックサム
ＳＥＲＶＩＣＥ＿ＡＣＫメッセージ（ルータにより生成される）
ＩＰバージョン
メッセージの長さ
機能−ＳＥＲＶＩＣＥ＿ＡＣＫ
チェックサム
パラメータなし。遠隔宛先端部が「特別サービス」であり、トランスポート層の活動が該遠隔宛先端部により制御されることをユーザに知らせる。
ＳＥＲＶＩＣＥ＿ＲＥＱＵＥＳＴメッセージ（ルータにより生成される）
ＩＰバージョン
メッセージの長さ
機能−ＳＥＲＶＩＣＥ＿ＲＥＱＵＥＳＴ
ソータ／サーバ・アドレス（１）
遠隔＿ホスト＿アドレス（２）
ソース・ルータ・アドレス（３）
セッション・レコード番号（３）
ユーザのインターネット・ネーム（３）
利用可能なプロトコル（２）
チェックサム
（１）メッセージはまずソータにアドレス指定され、該ソータは、遠隔＿ホスト＿アドレスにより示されたサービスに該メッセージを再アドレス指定する（ホストが移動体端末である場合には、移動体位置サービス及び現在ＢＳＣを介して）。
（２）ＯＰＥＮメッセージから取得される
（３）ソース・ルータにより与えられる
【００５１】
ＳＶＣＥ＆ＲＥＦ＿ＲＥＱＵＥＳＴメッセージ（ルータにより生成される）
ＩＰバージョン
メッセージの長さ
機能−ＳＶＣＥ＆ＲＥＦ＿ＲＥＱＵＥＳＴ
ソータ／サーバ・アドレス（１）
遠隔＿ホスト＿アドレス（２）
ソースＢＳＣアドレス（２）
セッション・レコード番号（２）
ユーザのインターネット・ネーム（２）
利用可能なプロトコル（２）
チェックサム
（１）メッセージはまずソータにアドレス指定され、該ソータは、遠隔＿ホスト＿アドレスにより示されたサービスに該メッセージを再アドレス指定する（ホストが移動体端末である場合には、移動体位置サービス及び現在ＢＳＣを介して）。
（２）ＯＰＥＮ＆ＲＥＦＲＥＱメッセージから取得される
ＲＥＱＵＥＳＴ＿ＤＯＮＥメッセージ
ＩＰバージョン
メッセージの長さ
機能−ＲＥＱＵＥＳＴ＿ＤＯＮＥ（パラメータなし）
チェックサム
ＯＰＥＮ＿ＳＥＲＶＩＣＥメッセージ（サーバ又は宛先移動体により生成される）
ＩＰバージョン
メッセージの長さ
機能−ＯＰＥＮ＿ＳＥＲＶＩＣＥ
ソース・ルータ・アドレス（１）
セッション・レコード番号（１）
ユーザのインターネット・ネーム（１）
選択されたプロトコル（２）
フォワード容量及び優先順位（２）
バックワード容量及び優先順位（２）
チェックサム
（１）ＳＥＲＶＩＣＥ＿ＲＥＱＵＥＳＴメッセージから
（２）ＯＰＥＮ＿ＤＯＮＥメッセージに転送されるまで使用されない。（ＯＰＥＮ＿ＯＬＤにより無効され得る）
ＯＰＥＮ＿ＳＶＣＥ＆ＲＥＦメッセージ（サーバ又は宛先移動体により生成される）
ＩＰバージョン
メッセージの長さ
機能−ＯＰＥＮ＿ＳＶＣＥ＆ＲＥＦ
ソースＢＳＣアドレス（１）
セッション・レコード番号（１）
ユーザのインターネット・ネーム（１）
選択されたプロトコル（２）
フォワード容量及び優先順位（２）
バックワード容量及び優先順位（２）
遠隔ＢＳＣ／サーバ・アドレス（３）
遠隔ＢＳＣ／サーバ・レコード番号（３）
チェックサム
（１）ＳＶＣＥ＆ＲＥＦ＿ＲＥＱＵＥＳＴメッセージから
（２）ＯＰＥＮ＿ＤＯＮＥメッセージに転送されるまで使用されない。（ＯＰＥＮ＿ＯＬＤにより無効とされ得る）
（３）ＢＳＣは、該ＢＳＣの移動体端末からの全てのＯＰＥＮ＿ＳＶＣＥ＆ＲＥＦメッセージに該ＢＳＣのアドレス及びセッション・レコード番号を付加する。
【００５２】
ＴＲＡＮＳＦＥＲ＿ＲＥＱＵＥＳＴ又はＡＤＤ＿ＲＥＱＵＥＳＴメッセージ（サーバにより生成される）
ＩＰバージョン
メッセージの長さ
機能−ＴＲＡＮＳＦＥＲ／ＡＤＤ＿ＲＥＱ
ソータ／新しいサーバ・アドレス（１）
ソース・ルータ・アドレス（２）
ルータのレコード番号（２）
ユーザのインターネット・ネーム（２）
利用可能なプロトコル（２）
雑情報−可変長（３）
チェックサム
（１）ソータにアドレス指定された場合には、「遠隔・ホスト・アドレス」が雑情報フィールドに入れられる。
（２）ＳＥＲＶＩＣＥ＿ＲＥＱＵＥＳＴから、又は前のＴＲＡＮＳＦＥＲ／ＡＤＤ＿ＲＥＱＵＥＳＴメッセージから
（３）サーバからサーバへの情報
ＴＦＲ＆ＲＥＦ又はＡＤＤ＆ＲＥＦ＿ＲＥＱＵＥＳＴメッセージ（サーバにより生成される）
ＩＰバージョン
メッセージの長さ
機能−ＴＦＲ＆ＲＥＦ又はＡＤＤ＆ＲＥＦ＿ＲＥＱＵＥＳＴ
ソータ／新しいサーバ・アドレス（１）
ソース・アドレス（２）
ＢＳＣのレコード番号（２）
ユーザのインターネット・ネーム（２）
利用可能なプロトコル（２）
雑情報−可変長（３）
チェックサム
（１）ソータにアドレス指定された場合には、「遠隔・ホスト・アドレス」が雑情報フィールドに入れられる。
（２）ＳＶＣＥ＆ＲＥＦ＿ＲＥＱＵＥＳＴから、又は前のＴＦＲ＆ＲＥＦ／ＡＤＤ＆ＲＥＦ＿ＲＥＱＵＥＳＴメッセージから
（３）サーバからサーバへの情報
ＭＯＢ＿ＴＲＡＮＳＦＥＲ　ＲＥＱＵＥＳＴメッセージ（ＢＳＣにより生成される−固定された遠隔端部）
ＩＰバージョン
メッセージの長さ
機能−ＭＯＢ＿ＴＲＡＮＳＦＥＲ＿ＲＥＱＵＥＳＴ
新しいＢＳＣアドレス
遠隔ルータ・アドレス（１）
ルータのレコード番号（２）
移動体端末のアイデンティティ
チェックサム
（１）ＳＥＲＶＩＣＥ＿ＲＥＱＵＥＳＴメッセージ、ＯＰＥＮ＿ＡＣＫメッセージ、又は前のＭＯＢ＿ＴＲＡＮＳＦＥＲ＿ＲＥＱＵＥＳＴメッセージから
ＭＯＢ＿ＴＦＲ＆ＲＥＦ　ＲＥＱＵＥＳＴメッセージ（ＢＳＣにより生成される−サーバ又は移動体遠隔端部）
ＩＰバージョン
メッセージの長さ
機能−ＭＯＢ＿ＴＦＲ＆ＲＥＦ＿ＲＥＱＵＥＳＴ
新しいＢＳＣアドレス
遠隔サーバ／ＢＳＣアドレス（１）
サーバ／ＢＳＣのレコード番号（１）
移動体端末のアイデンティティ
料金レコード・フラグ
チェックサム
（１）ＳＶＣＥ＆ＲＥＦ＿ＲＥＱＵＥＳＴメッセージ、ＯＰＥＮ＿ＳＶＣＥ＆ＲＥＦメッセージ、又は前のＭＯＢ＿ＴＦＲ＆ＲＥＦ＿ＲＥＱＵＥＳＴから
【００５３】
ＯＰＥＮ＿ＴＲＡＮＳＦＥＲ又はＯＰＥＮ＿ＡＤＤメッセージ（サーバにより生成される）
必要とされるＴＲＡＮＳＦＥＲ又はＡＤＤ動作を示す、機能フィールドにおける名前以外は、ＯＰＥＮ＿ＳＥＲＶＩＣＥメッセージと同じ。
ＯＰＥＮ＿ＴＦＲ＆ＴＦＲ又はＯＰＥＮ＿ＡＤＤ＆ＲＥＦメッセージ（サーバにより生成される）
必要とされるＴＲＡＮＳＦＥＲ又はＡＤＤ動作を示す、機能フィールドにおける名前以外は、ＯＰＥＮ＿ＳＶＣＥ＆ＲＥＦメッセージと同じ。
ＯＰＥＮ＿ＭＯＢ＿ＴＲＡＮＳＦＥＲメッセージ（移動する移動体−固定された遠隔端部）
ＩＰバージョン
メッセージの長さ
機能−ＯＰＥＮ＿ＭＯＢ＿ＴＦＲ
遠隔ルータ・アドレス（１）
セッション・レコード番号（１）
チェックサム
（１）ＭＯＢ＿ＴＦＲ＿ＲＥＱＵＥＳＴメッセージ
【００５４】
ＯＰＥＮ＿ＭＯＢ＿ＴＦＲ＆ＲＥＦメッセージ（移動する移動体−サーバ又は移動体の遠隔端部）
ＩＰバージョン
メッセージの長さ
機能−ＯＰＥＮ＿ＭＯＢ＿ＴＦＲ＆ＲＥＦ
サーバ／遠隔ＢＳＣアドレス（１）
セッション・レコード番号（１）
新しいＢＳＣアドレス（２）
新しいＢＳＣ・レコード番号（２）
料金レコード・フラグ
チェックサム
（１）ＭＯＢ＿ＴＦＲ＆ＲＥＦ＿ＲＥＱＵＥＳＴメッセージから
（２）ＢＳＣは、該ＢＳＣのアドレス及びセッションのレコード番号を付加する。
ＦＡＩＬＵＲＥメッセージ
ＩＰバージョン
メッセージの長さ
機能−ＦＡＩＬＵＲＥ
（必要に応じて）〔必要に応じてとは何か？〕
チェックサム
典型的なエラーメッセージ−（単に誤った番号である）
宛先アドレスが認識されない／プロテクトされている
宛先端末が非稼動中／応答しない
宛先端末の位置が不明（オフライン・モード）
十分な容量をコミットすることができない
輻輳（如何なる容量もコミットすることができない）／ネットワーク・エラー
インターネット・ネーム・チェック・エラー
【図面の簡単な説明】
【図１】
従来技術によるプロトコルの動作を示す。
【図２】
従来技術によるプロトコルの動作を示す。
【図２Ａ】
従来技術によるプロトコルの動作を示す。
【図３】
本発明によるプロトコルの動作を示す。
【図３Ａ】
本発明によるプロトコルの動作を示す。
【図３Ｂ】
本発明によるプロトコルの動作を示す。
【図４】
本発明によるプロトコルの動作を示す。
【図５】
本発明によるプロトコルの動作を示す。
【図５Ａ】
本発明によるプロトコルの動作を示す。
【図６】
本発明によるプロトコルの動作を示す。
【図１】
2004511961.tif 000003
【図２】
2004511961.tif 000004
【図２Ａ】
2004511961.tif 000005
【図３】
2004511961.tif 000006
【図３Ａ】
2004511961.tif 000007
【図３Ｂ】
2004511961.tif 000008
【図４】
2004511961.tif 000009
【図５】
2004511961.tif 000010
【図５Ａ】
2004511961.tif 000011
【図６】
2004511961.tif 000012
【国際公開パンフレット】
2004511961.tif 000013
2004511961.tif 000014
2004511961.tif 000015
2004511961.tif 000016
2004511961.tif 000017
2004511961.tif 000018
2004511961.tif 000019
2004511961.tif 000020
2004511961.tif 000021
2004511961.tif 000022
2004511961.tif 000023
2004511961.tif 000024
2004511961.tif 000025
2004511961.tif 000026
2004511961.tif 000027
2004511961.tif 000028
2004511961.tif 000029
2004511961.tif 000030
2004511961.tif 000031
2004511961.tif 000032
2004511961.tif 000033
2004511961.tif 000034
2004511961.tif 000035
2004511961.tif 000036
2004511961.tif 000037
2004511961.tif 000038
2004511961.tif 000039
2004511961.tif 000040
2004511961.tif 000041
2004511961.tif 000042
2004511961.tif 000043
2004511961.tif 000044
2004511961.tif 000045
2004511961.tif 000046
2004511961.tif 000047
2004511961.tif 000048
2004511961.tif 000049
2004511961.tif 000050
2004511961.tif 000051
2004511961.tif 000052
2004511961.tif 000053
2004511961.tif 000054
2004511961.tif 000055
2004511961.tif 000056
【国際調査報告】
2004511961.tif 000057
2004511961.tif 000058
2004511961.tif 000059