JP2009514486A - データ・セッションにおいて端末の存在を検知する方法と装置 - Google Patents

Abstract

データ・セッション（例えばＲＴＰセッション）において少なくとも１つの他の端末の存在を検知するために、端末ａは、各端末からの応答を要請する要求を生成し、要求用のＲＴＣＰのＡＰＰパケットを形成し、少なくとも１つのＩＰパケット中にＡＰＰパケットをカプセル化して、前記他方の端末へそのＩＰパケットを送信する。端末ａは、それから、要求が送信された各端末からの応答を監視する。端末ａは、応答がその端末から受信された場合に、そのデータ・セッションに端末が存在することを宣言する。端末ａは、応答が受信されない各端末へ１つ以上の追加の要求を送信し得る。端末ａは、所定の回数（例えば２）の要求がその端末へ送信され、そして、その端末から応答が受信されない場合には、そのデータ・セッションに端末が存在しないことを宣言する。

Description

本出願は、２００５年１０月３１日に出願され、本出願の本出願の譲受人に譲渡され、引用することによって、すべての目的のためのその全体がここに組み入れられ、"データ・セッションにおいて端末の存在を検知する方法と装置"と題された、米国におけるシリアル番号６０／７３２，４１９の仮出願の利益を主張するものである。

本開示は、一般的には通信に関し、さらに詳細には、データ・セッションにおいて端末の存在を検知するための技術に関する。

無線と有線の通信ネットワークは、音声、ビデオ、パケット・データ、メッセージ、放送、マルチメディア等のような種々の通信サービスを提供するために広く展開されている。各サービスは、異なる特性および要求を持ち得る。例えば、パケット・データ呼び出しは、本質的に突発的であるかもしれないが、変化するおよび長い遅延を許容することができてもよい。対照的に、音声呼び出しは、等間隔にデータを生成し、比較的厳格な遅延要求を有し得る。

多数の端末は、音声、ビデオなどのようなリアルタイム・データを交換するために、１つ以上のネットワークを介してデータ・セッションを確立し得る。例えば、データ・セッションは、異なるサイトに位置する多数の参加者間のテレビ会議呼び出しのためであるかもしれない。データ・セッションの間に、各端末は、送るべきデータがある時と場合に、他の端末へデータを送信し得る。端末間のデータ交換は、散発的かもしれない。さらに、データ・セッションは、長い時間続き得る、そして、端末は、そのセッションの間に何時でもデータ・セッションに加わることができ、かつ去ることができる。データ・セッションの動的な性質のために、与えられた端末がデータ・セッションにまだ存在しているかどうかを確認することは望ましいかもしれない。

様々なスキームは、与えられた端末がデータ・セッションに存在しているかどうか確認するのに利用可能である。１つのスキームでは、各端末は、送信している端末の存在を他の端末に通知するために、アイドル・パケットを周期的に送信する。このスキームは、結果として、多くのアイドル・パケットが送信されるということが生じ得る、無線資源が不足するので、それは無線ネットワークには非常に望ましくないかもしれない。さらに、アイドル・パケットは、すべてのタイプのメディア（例えば画像、テキストなど）用に定義されなくてもよい。別のスキームでは、各端末は、周期的に他の端末への報告を生成し送信する。これらの報告は、送信されたパケット、および／または報告を送る端末によって受け取られたパケット、に関する情報を伝え得る。これらの報告は、まれに（例えば５秒ごと）送られ、パケット・エラーにより失われ得る。また別のスキームでは、タイマーがデータ・セッションにおいて各端末用に維持され、周期的にリフレッシュされる。

端末のための前記タイマーが終了する場合、その時は、その端末はデータ・セッションを去ったものとみなされる。タイマーは、典型的には、リフレッシュレートを減少するために大きな値にセットされ、それから、それは、データ・セッションにおいて端末の不在を検知するために長い時間をとる。さらに、ネットワーク資源は、端末のためのタイマーを維持するために利用される。一般に、データ・セッションにおいて端末の存在を検知するための上に説明されたすべてのスキームは、ネットワーク資源を消費し、そして、あまり効率的ではない。

したがって、データ・セッションにおいて効率的に端末の存在を検知するべき技術に関してこの分野の必要がある。

発明の概要

データ・セッションにおいて効率的に端末の存在を検知するための技術が、ここに説明される。典型的な実施態様において、与えられた端末ａは、１つの、データ・セッション（例えばリアル・タイム・トランスポート・プロトコル（ＲＴＰ）セッション）において少なくとも１つの他の端末の存在を検知することを要望する。この要望は、例えば、端末ａが、所定時間内に他の端末からデータを受け取らなかった場合、あるいは、端末ａが、その接続状態は悪くなったと疑う場合に発生し得る。一実施態様において、端末ａは、他の端末の各々からの応答を求める要求を生成し、その要求のためにＲＴＰ制御プロトコル（ＲＴＣＰ）においてＡＰＰパケットを形成し、少なくとも１つのインターネット・プロトコル（ＩＰ）パケットの中にＡＰＰパケットをカプセル化し、そのＩＰパケットを他の端末へ送信する。それから、端末ａは、要求が送信される各端末からの応答について監視する。端末ａは、レスポンスがその端末から受信される場合には、そのデータ・セッションに端末が存在することを宣言する。端末ａは、レスポンスが受信されない各端末へ１つ以上の追加の要求を送信し得る。端末ａは、その端末へ所定の数（例えば２）の要求が送信されて、そして、その端末から応答が受信されない場合には、そのデータ・セッションに端末が不在であることを宣言する。

ここに説明された技術は、（１）その端末の存在についての知識が望まれる時と場合に、要求が直ちに送信され得る、および（２）その要求と応答は少量のネットワーク資源を使用して送信され得る、ので、端末の存在を効率的に検知する。本発明の種々の態様と実施態様は、さらに下記に詳細に説明される。

本発明の特徴および性質は、同様の参照文字が対応するものを全て識別する図面に関連して理解されると、下に示された詳細な説明から、より明らかになるであろう。

詳細な説明

「典型的である（exemplary」という単語は、ここでは、例（example）、事例（instance）、または例示（illustration）として供されることを意味するものとして使用される。「典型的である」として、ここに説明されたすべての実施態様あるいは設計は、必ずしも、他の実施態様あるいは設計よりも好ましい、あるいは有利なものとして、解釈されるべきではない。

図１は、一緒に相互運用するが、しかしそうでなければ互いから独立し得る多数のコミュニケーション・ネットワークで構成された通信システム１００を示す。図１では、無線の広域ネットワーク（ＷＷＡＮ）１１０、無線ローカル・エリア・ネットワーク（ＷＬＡＮ）１２０および電話網１３０は、インターネット１４０および／または他のいくつかのデータ網を介してデータを交換する。

ＷＷＡＮ１１０は、大きな地理的なエリアに通信サービス区域を提供し、符号分割多元接続（ＣＤＭＡ）ネットワーク、時分割多元接続（ＴＤＭＡ）ネットワーク、周波数分割多元接続（ＦＤＭＡ）ネットワーク、直交周波数分割多元接続（ＯＦＤＭＡ）ネットワーク、あるいは他のあるネットワークかもしれない。ＣＤＭＡネットワークは、ｃｄｍａ２０００、広帯域ＣＤＭＡ（Ｗ−ＣＤＭＡ）などのような１つ以上の無線アクセス技術（ＲＡＴ）を実装し得る。ｃｄｍａ２０００は、ＩＳ−２０００、ＩＳ−９５およびＩＳ−８５６標準をカバーする。ＷＷＡＮ１１０は、このようにＩＳ−２０００、ＩＳ−９５およびＩＳ−８５６を利用するｃｄｍａ２０００ネットワーク、あるいはＷ−ＣＤＭＡを利用するユニバーサル・モービル・テレコミュニケーション・システム（ＵＭＴＳ）ネットワークかもしれない。ＴＤＭＡネットワークは、グローバル移動体通信システム（ＧＳＭ）、ディジタル・アドバンスト移動電話サービス（Ｄ−ＡＭＰＳ）などのような１つ以上のＲＡＴを実装し得る。これらの様々なＲＡＴおよび標準は、当該技術分野で知られている。

ＷＷＡＮ１１０は、特別の地理的なエリアに通信サービス区域を提供する各基地局と共に、多数の基地局１１４を含んでいる。基地局は、一般的には、端末と通信し、アクセス・ポイント、ノードＢあるいは他のいくつかの用語と呼ばれるかもしれない固定局である。システム・コントローラ１１６は、基地局１１４へ結合されて、これらの基地局に調整と制御をあたえる。システム・コントローラ１１６は、単一のネットワーク実体（entity）あるいはネットワーク実体の集まりかもしれない。例えば、システム・コントローラ１１６は、ｃｄｍａ２０００ネットワーク用のパケット・データ供給ノード（ＰＤＳＮ）およびパケット制御機能（ＰＣＦ）含み得る。システム・コントローラ１１６は、ＵＭＴＳネットワーク用のゲートウエイＧＰＲＳサポート・ノード（ＧＧＳＮ）およびサービングＧＰＲＳサポート・ノード（ＳＧＳＮ）を含み得る。

端末１１２は、基地局１１４と通信する。

端末もまた、移動局、アクセス端末、ユーザ装置あるいは他のいくつか用語で呼ばれ得る。

端末は、無線装置、携帯電話、無線モデム、携帯情報端末など（ＰＤＡ）かもしれない。端末は、任意の与えられた瞬間において、フォワードリンクおよび／またはリバースリンク上で、ゼロ、１、または多数の基地局１１４と通信することができる。

ＷＬＡＮ１２０は、限られた地理的なエリアに通信サービス区域を提供する。

ＷＬＡＮ１２０は、ＩＥＥＥ８０２．１１ネットワーク、ブルーツース・ネットワークあるいは他のいくつかのタイプのネットワークかもしれない。ＷＬＡＮ１２０は、端末１２２と通信し、および、さらにインターネット１４０とパケット・データを交換する、１つ以上のアクセス・ポイント１２４を含んでいる。電話網１３０は、公衆電話交換網（ＰＳＴＮ）１３４および構内電話交換器（ＰＢＸ）１３６を含んでいる。ＰＳＴＮ１３４は、従来の平易な古い電話システム（ＰＯＴＳ）のための音声通信をサポートする。ＰＢＸ１３６は、インバウンドの音声およびデータ呼を適切な宛先へ送り、そして、電話１３２と他の実体の間の電話通信およびデータの交換を容易にする。他の実体および装置は、さらにホーム・パソコン（ＰＣ）１４２のように、インターネット１４０を介してデータを交換し得る。

図２は、２つの端末（例えばＷＷＡＮ１１０の端末１１２とＷＬＡＮ１２０の端末１２２）の間のリアルタイム・データ・セッションに使用され得る、典型的なプロトコル・スタック２００を示す。プロトコル・スタック２００は、トランスポート層、ネットワーク層、リンク層および物理層を含んでいる。

端末１１２と１２２は、トランスポート層においてユーザ・データグラム・プロトコル（ＵＤＰ）あるいは他のいくつかのプロトコルと共に動作するリアル・タイム・トランスポート・プロトコル（ＲＴＰ）を使用して通信することができる。ＵＤＰは、典型的にはネットワーク層でインターネット・プロトコル（ＩＰ）の上で動作する。端末１１２および１２２は、ＩＰパケット中にトランスポート層データ（例えばＵＤＰのための）をカプセル化することができ、これらのＩＰパケットを、ＷＷＡＮ１１０、インターネット１４０およびＷＬＡＮ１２０を介して交換することができる。

端末１１２とＷＷＡＮ１１０の間のリンク層および物理層は、典型的には、無線技術に依存する。ｃｄｍａ２０００ネットワークについては、リンク層は、無線リンクプロトコル（ＲＬＰ）上でポイント・ツー・ポイント・プロトコル（ＰＰＰ）で実装される。

ＲＬＰは、エアーリンク・インターフェース（例えばＩＳ−２０００、ＩＳ−９５、ＩＳ−８５６）の上で動作する。端末１２２とＷＬＡＮ１２０の間のリンク層および物理層もまた、無線技術（例えばＩＥＥＥ８０２．１１、またはブルーツース）に依存する。ＷＷＡＮ１１０およびＷＬＡＮ１２０は、リンク層と物理層を介してＩＰパケットを交換する。

プロトコル・スタック２００あるいは他のいくつかのプロトコル・スタックは、図１における２つ以上の端末間の通信に使用され得る。

データ・セッションは、図１における端末１１２、１２２、１３２および１４２の任意の組み合わせ、および任意の数の端末、について確立され得る。データ・セッションは、ボイス・オーバーＩＰ（ＶｏＩＰ）、遠隔会議、テレビ会議などのようなリアルタイムサービス向けかもしれない。端末は、データ・セッションの間に、音声、ビデオなどのようなリアルタイムデータを交換し得る。

一般に、データ・セッションは、データとシグナリングを送信するために様々な層の様々なプロトコルを利用することができる。以下で詳細に説明される実施態様では、データ・セッションはＲＴＰとＲＴＣＰを利用する。ＲＴＰは、端末間のネットワーク・トランスポート機能を提供し、リアルタイムデータを送信するアプリケーションに適している。ＲＴＣＰは、ＲＴＰによるデータ配信のモニタリングを可能にする。本質的には、データはＲＴＰを使用して送信され得る、また、シグナリングはＲＴＣＰを使用して送信され得る。ＲＴＰとＲＴＣＰは「ＲＴＰ：リアルタイムアプリケーション用のトランスポート・プロトコル ２００３年７月（RTP: A Transport Protocol for Real-Time Applications, July 2003）」とタイトルを付けられたＲＦＣ３５５０に説明されており、それは公に利用可能である。ＲＴＰとＲＴＣＰは、典型的にはＵＤＰと共に動作する。それは図２に示されるように、典型的にはＩＰの上で動作する。

端末は、何時でもデータ・セッションに加わり、そして去ってもよい。ある場合では、与えられた端末は、別の端末がデータ・セッションに存在するかどうか知ることを望み得る。これは上に説明されたスキームを使用して達成され得る。しかしながら、これらのスキームは、この検出機能を達成するために必要な程度より多くネットワーク資源を消費する、このゆえにネットワーク資源を浪費する。

与えられた端末がデータ・セッションに存在するかどうかを効率的に決定する技術が、ここに説明される。それらの技術は、２つを超える端末を持ったマルチキャスト・データ・セッションにも、２つの端末を持ったユニキャスト・データ・セッションにも使用され得る。それらの技術は、リンク層、ネットワーク層、トランスポート層などのような様々な層に使用され得る。明瞭さために、それらの技術は、ＲＴＰ/ＲＴＣＰによるデータ・セッションについて下記に説明される。

図３は、２つの端末ａとｂを持つユニキャスト・データ・セッションにおいて端末の存在を確認するプロセス３００の実施態様を示す。データ・セッションの間に、端末ａとｂは、データが利用可能になるように、データを交換し得る。時刻Ｔ１で、端末ａは、端末ｂが、そのデータ・セッションにまだ存在しているかどうか知ることを要望する。端末ａは、そのとき、時刻Ｔ１において端末ｂにＲＴＣＰエコー要求を直ちに送信し得る（図３に示されたように）、あるいは、資源が利用可能になるとすぐに送信し得る。ＲＴＣＰエコー要求（それはピング要求とも呼ばれる）は、受取り端末からの応答を要請する。端末のｂは、ＲＴＣＰエコー要求を受け取り、時刻Ｔ２でＲＴＣＰエコー応答（それはピング応答とも呼ばれる）を端末ａへ逆戻りに送信することにより応答する。端末ａは、ＲＴＣＰエコー応答を受信し、端末ｂがデータ・セッションにまだ存在することを認識する。

図３に示されなかったが、端末ａは、時刻Ｔ１で送信されたＲＴＣＰエコー要求について端末ｂからのＲＴＣＰエコー応答を受信しないかもしれない。このことは、悪い接続状態によりＲＴＣＰエコー要求が端末のｂに達しない、端末のｂが存在しない、悪い接続状態によりＲＴＣＰエコー応答が端末ａに到着しない、等のような、様々な理由によるかもしれない。端末ａが、所定時間内にＲＴＣＰエコー応答を受信しない場合、そのとき、端末ａは、端末ｂに別のＲＴＣＰエコー要求を送信することができる。一般に、端末ａは、任意の数のＲＴＣＰエコー要求を端末ｂに送信することができ、そしてＲＴＣＰエコー要求を送信する間に任意の時間、待つことができる。端末ａが、所定の回数（例えば２）ＲＴＣＰエコー要求を送信した後、端末ｂからのＲＴＣＰエコー応答を受信しない場合、そのとき、端末ａは、端末ｂがそのデータ・セッションに存在していないと推測することができ、そして適切な是正処置を行ない得る。

端末ａは、上に説明されているように、端末ｂの存在を確認するためにプロセス３００を使用し得る。端末ａは、また、その接続の条件をチェックするためにプロセス３００を使用することもできる。例えば、端末ａは、所定の時間（例えば２００ミリ秒（ｍｓ）、５００ｍｓ、または１秒）、パケットを少しも受信しないかもしれない。別の例として、端末ａは、他の端末へ送信されたパケットのための肯定応答（acknowledgment）を受信しないかもしれない。活動および／または肯定応答の欠如は、端末ａの接続状態が、端末ａについての知識がないことで悪化したことに起因しているかもしれない。一般に、端末ａは、その接続状態が悪化してしまったかどうか決定するために様々な基準を使用することができる。端末ａは、そのとき、別の端末へＲＴＣＰエコー要求を送信することにより接続をチェックしてもよい。端末ａは、ＲＴＣＰエコー応答が別の端末から受信される場合には、接続状態は良好であると宣言し得る。あるいは、端末ａは、所定の数のＲＴＣＰエコー要求が送信され、そして、ＲＴＣＰエコー応答が受信されない場合には、接続状態が悪化していることを宣言し得る。

図４は、Ｎ端末ａからｎを持ったマルチキャスト・データ・セッションにおいて１つ以上の端末の存在を確認するためのプロセス４００の一実施態様を示す、ここで、Ｎ＞２ 。データ・セッションの間に、端末ａからｎは、データが利用可能になるようにデータを交換し得る。時刻Ｔ１において、端末ａは、端末ｂからｎが、まだデータ・セッションに存在しているどうか知ることを要望する。端末ａは、そのとき、時刻Ｔ１において端末ｂからｎに向けてＲＴＣＰエコー要求を直ちに送信し得る（図４に示されたように）、あるいは、資源が利用可能になるとすぐに送信し得る。下記に説明されているように、単一のＲＴＣＰエコー要求は、そのＲＴＣＰエコー要求において適切なフィールドをセットし、および／または適切な宛先アドレスを含めることにより、そのデータ・セッションにおいて１の、多数の、あるいは全ての端末に向けて、送信され得る。

端末ｂは、ＲＴＣＰエコー要求を受信し、そして時刻Ｔ２で、端末ａへ逆戻りするようにＲＴＣＰエコー応答を送信することにより応答する。各端末ｃからｎもまた、ＲＴＣＰエコー要求を受信し得る、そして、端末ａ逆戻りするようにＲＴＣＰエコー応答を送信することにより応答し得る。一般に、端末ａは、端末ｂからｎの、すべて、またはいくらかのＲＴＣＰエコー応答を受信し得る、あるいはいずれからもＲＴＣＰエコー応答を受信しない。端末ａは、各ＲＴＣＰエコー応答が端末ａによって受信された出所端末が、そのデータ・セッションにおいて存在すると宣言する。

図４に示されていないが、端末ａは、時刻Ｔ１において送信されたＲＴＣＰエコー要求について、１つ以上の端末からのＲＴＣＰエコー応答を受信しないかもしれない。端末ａは、そのとき、応答しなかった各端末へ別のＲＴＣＰエコー要求を送信し得る。一般に、端末ａは、他の端末へ任意の数のＲＴＣＰエコー要求を送信することができる。端末ａは、端末へ所定の数（例えば２）のＲＴＣＰエコー要求を送信した後、その端末からＲＴＣＰエコー応答が受信されない場合には、そのデータ・セッションに端末が存在しないと推定することができる。

図３および４に示される実施態様については、任意の端末が、単純なＲＴＣＰエコー要求の送信により、その対等端末（peer terminal）の存在を検知し得る。少量のネットワーク資源が、ＲＴＣＰエコー要求およびＲＴＣＰエコー応答の送信により消費される。さらに、任意の端末は、この情報が望まれる時および場合には、データ・セッションの間において、対等端末の存在を、いつでも検知することができる。端末は、任意のタイマーが期間満了になることを待つ必要なしに、直ちに、またはネットワーク資源が利用可能なときに、ＲＴＣＰエコー要求を送信し得る。

ＲＴＣＰエコー要求およびＲＴＣＰエコー応答は、様々なタイプのパケットを使用して送信され得る。一実施態様では、ＲＴＣＰエコー要求およびＲＴＣＰエコー応答は、各々、ＡＰＰパケットを使用して送信され得る、それはＲＴＣＰのアプリケーションに定義されたＲＴＣＰパケットである。ＡＰＰパケットは、独占の使用に向けられ、新しいアプリケーションおよび新しい特徴に関して定義され得る。

図５は、ＲＴＣＰエコー要求用のＡＰＰパケット５００の実施態様を示す。

ＡＰＰパケット５００は、データ・セッションにおける端末の存在を検知するために使用され得る。表１は、ＡＰＰパケット５００のフィールド、各フィールドの長さ（ビットの数において）、および各フィールドの短い説明をリストする。

データ・セッションは、１つ以上のＲＴＰセッションからなるマルチメディア・セッションかもしれない。例えば、テレビ会議のようなマルチメディア・セッションは、オーディオＲＴＰセッションおよびビデオＲＴＰセッションからなり得る。各ＲＴＰセッションは、ＲＴＰで通信する端末のグループの結合である。各ＲＴＰセッションは、そのＲＴＰセッションに参加する端末の同期出所（synchronization source ）（ＳＳＲＣ）識別子の個別のセットを維持する。与えられたＲＴＰセッションの各端末は、そのＲＴＰセッションにおいてすべての端末中でユニークなＳＳＲＣ識別子によって識別される。各ＲＴＰセッションの個々の端末は、それらのＳＳＲＣ識別子によってユニークに識別され得る。与えられた端末は、多数のＲＴＰセッションに同時に参加し得る。

ＲＴＣＰエコー要求用のＡＰＰパケットは、ブロードキャスト（Ｂ）フィールドに真（true）（‘１’）をセットすることによって、与えられたＲＴＰセッションにおけるすべての端末へ送信され得る。この場合、Ｎｕｍ＿Ｄｅｓｔ＿ＳＳＲＣフィールドは、０にセットされ得る、そして宛先_ＳＳＲＣフィールドが省略され得る。ＲＴＣＰエコー要求用のＡＰＰパケットは、また、ブロードキャスト（Ｂ）フィールドに偽（false）（‘０’）をセットし、Ｎｕｍ＿Ｄｅｓｔ＿ＳＳＲＣフィールドに、ＲＴＣＰエコー要求が送信される端末の数をセットし、そして宛先_ＳＳＲＣフィールドの一例として各受取人端末のＳＳＲＣ識別子を含ませることにより、与えられたＲＴＰセッションにおける１つ以上の特定の端末へも送信され得る。新しいＲＴＣＰエコー要求が送られるごとに、ピング_シーケンスには、新しい値（例えば最終値のインクリメントによって）がセットされる。ピング_シーケンスの値は、対応するＲＴＣＰエコー応答にＲＴＣＰエコー要求を関連させるために使用される。データ・フィールドは、任意のデータ（例えば接続の状態をチェックするために使用されるデータ）を運び得る。

ＡＰＰパケット５００は、また、ＲＴＣＰエコー応答にも使用され得る。しかしながら、異なるユニークな名前が名前フィールドのために定義され得る、および／または、異なる値がＲＴＣＰエコー応答用のＡＰＰパケットのサブタイプ・フィールドのために使用され得る。ＲＴＣＰエコー応答用のＡＰＰパケットは、ブロードキャスト・フィールドに偽（false）をセットし、かつ宛先_ＳＳＲＣフィールドに要求する端末のＳＳＲＣ識別子を含ませることにより、ＲＴＣＰエコー要求を送った端末（つまり要求している端末）へ送信され得る。ＲＴＣＰエコー応答用のＡＰＰパケットは、また（１）ブロードキャスト・フィールドに真（true）をセットすることによってデータ・セッションにおける全ての端末へ、あるいは（２）宛先_ＳＳＲＣフィールドに各端末のＳＳＲＣ識別子を含ませることによって１つ以上の他の特定の端末へ、送信され得る。

ＲＴＣＰエコー要求およびＲＴＣＰエコー応答の両方に適当なＡＰＰパケットの具体的な設計は、上に説明された。様々な他の設計が、また、ＲＴＣＰエコー要求およびＲＴＣＰエコー応答用のＡＰＰパケットに使用され得る。ＲＴＣＰエコー要求およびＲＴＣＰエコー応答は、また、ＡＰＰパケットに加えて他のタイプのパケットで送信され得る。

データ・セッションは、多数のＲＴＰセッションを含み得る。一実施態様において、端末ａは、両方の端末が参加者である各ＲＴＰセッションの別の端末ｂへＲＴＣＰエコー要求を送信する。この実施態様については、端末ａは、端末ｂが各ＲＴＰセッションに存在するかどうか確認することができる。別の実施態様においては、端末ａは、１つのＲＴＰセッションの端末ｂへＲＴＣＰエコー要求を送信する。この実施態様については、端末ａは、ＲＴＣＰエコー要求がそのために送られたＲＴＰセッションにおける端末ｂの存在を確認することができ、そして、他のすべてのＲＴＰセッションに、端末ｂが同様に存在するか、あるいは不在であるかを推定し得る。

図６は、データ・セッションに他の端末の存在を決定するために与えられた端末ａによって実行されるプロセス６００を示す。端末ａは、データ・セッション（例えばＲＴＰセッション）において少なくとも１つの他の端末の存在を検知することを要望し、そして各端末からの応答を要請するための要求を生成する（ブロック６１０）。 例えば、この要望は、端末ａが所定時間内に他の端末からデータを受信しなかった場合、端末ａが、その接続状態が悪化してしまったことに気づいた場合などに発生し得る。端末ａは、要求のために少なくとも１つのＩＰパケットを形成する（ブロック６１２）。ブロック６１２については、端末ａは、要求用のＡＰＰパケットを形成し、そのＡＰＰパケットを、（１）そのＡＰＰパケットのブロードキャスト・フィールドに真（true）をセットすることによって、そのデータ・セッションにおける全ての端末へ、あるいは（２）そのＡＰＰパケットに各端末のＳＳＲＣ識別子を含めることによってそのデータ・セッションにおける特定の端末へ、送信し得る。端末ａは、それから、ＡＰＰパケットを少なくとも１つのＩＰパケット中にカプセル化することができる。

端末ａは、他方の端末がそのデータ・セッションに存在するかどうかを確認するために他方の端末へ、その要求用のＩＰパケットを送信する（ブロック６１４）。 端末ａは、それから、要求が送信される各端末からの応答を監視する（ブロック６１６）。 端末ａは、その端末から応答が受信された場合には、そのデータ・セッションに端末が存在することを宣言する（ブロック６１８）。 端末ａは、応答が受信されない各端末へ１つ以上の追加の要求を送信し得る（ブロック６２０）。 端末ａは、所定回数（例えば２）の要求がその端末へ送信されており、そして応答がその端末から受信されない場合には、そのデータ・セッションに端末は不在であることを宣言することができる（ブロック６２２）。

図７は、図１における端末１１２の一実施態様のブロックダイヤグラムを示す。端末１１２は、ＷＷＡＮ１１０との通信のための無線モデムを含んでいる。無線モデムの送信パスにおいては、端末１１２によって送信されるデータおよびシグナリング（例えば、エコー要求あるいはエコー応答のための）が、エンコーダ７２２によって処理（例えば、フォーマット、エンコード、インターリーブ）され、さらに、データ・チップを得るために変調器（Ｍｏｄ）７２４によって処理（例えば、変調、チャンネル化、そしてスペクトル拡散）される。送信機（ＴＭＴＲ）７３２は、それから、アップリンク信号を生成するためにデータ・チップを調整（例えば、アナログ信号に変換、フィルタ、増幅、および周波数アップコンバート）し、それはアンテナ７３６を介して送信される。受理パスにおいては、ＷＷＡＮ１１０の中の基地局によって送信されたダウンリンク信号が、アンテナ７３６によって受信され、受信機（ＲＣＶＲ）７３８に供給される。受信機７３８は、受信信号を調整（例えば、フィルタ、増幅、周波数ダウンコンバート、およびディジタル化）し、そしてデータ・サンプルを供給する。復調器（Ｄｅｍｏｄ）７２６は、そのサンプルを処理（例えば、逆拡散、チャンネル化、復調）し、シンボル評価を得る。デコーダ７２８は、さらにシンボル評価を処理（例えば、デインターリーブ、およびデコード）し、デコードされたデータを得る。エンコーダ７２２、変調器７２４、復調器７２６、およびデコーダ７２８は、モデム・プロセッサ７２０によって実装され得る。これらのユニットは、ＷＷＡＮ１１０によって使用される無線技術（例えばｃｄｍａ２０００あるいはＷ−ＣＤＭＡ）に従って処理を行なう。

コントローラ／プロセッサ７４０は、端末１１２内の様々なユニットの動作を指示する。コントローラ／プロセッサ７４０は、図３、４および／または６に示されているプロセス３００、４００および／または６００を実行し得る。メモリ７４２は、端末１１２のためのプログラム・コードおよびデータを格納する。通信（Ｃｏｍｍ）ユニット７４４は、外部装置および／または有線ネットワークとの通信のためのインターフェースを提供する。

ここに説明された技術は、パケット交換のセッションにおける個々の端末の活動状態を検知するために有利に使用され得る。パケット交換のセッションについては、専用の接続は、そのセッションにおいて端末間でセット・アップされない、そして、パケットは適切なルートで送られる、また、端末のための回線が断たれたことを検知する容易な方法はない。対照的に、回線交換セッションについては、専用の接続が、セッションにおいて端末間でセット・アップされる、そして、各端末は、接続が壊れたことを検知することが可能であり得る。ここに説明された技術は、専用の接続を持っていない端末の存在の検知を可能にする。

ここに説明された技術は、アイドル・パケットやタイマーなどのようなキープ・アライブ（keep-alive）メカニズムを使用せずに、端末の検知を可能にする。これらの技術は、要望された時と場合に、エコー要求およびエコー応答のために送られるパケットはごく少数なので、無線ネットワークには特に有利である。これらの技術は、またタイマーの使用を回避する。それは、タイマーを維持するために必要とされるネットワーク資源を浪費しない。

ここに説明された技術は、様々な手段によって実装され得る。例えば、これらの技術は、ハードウェア、ファームウェア、ソフトウェアあるいはそれらの組み合わせで実装され得る。ハードウェアによる実装については、エコー要求およびエコー応答を送信するために使用される処理ユニットは、１つ以上の特定用途向けＩＣ（ＡＳＩＣ）、ディジタル信号プロセッサ（ＤＳＰ）、ディジタル信号処理装置（ＤＳＰＤ）、プログラム可能論理回路（ＰＬＤ）、フィールドプログラム可能なゲート・アレイ（ＦＰＧＡ）、プロセッサ、コントローラ、マイクロ・コントローラ、マイクロプロセッサ、電子デバイス、ここに説明した機能を実行することを目指した他の電子ユニット、あるいはそれらの組み合わせの内に実装され得る。

ファームウェアおよび／またはソフトウェアにより実装については、前記技術は、ここに説明された機能を実行するモジュール（例えば、手続き、関数など）で実装され得る。ソフトウェア・コードは、メモリ（例えば図７の中のメモリ７４２）に格納され、プロセッサ（例えばプロセッサ７４０）によって実装され得る。前記メモリは、プロセッサ内に実装されるか、あるいはプロセッサの外部に実装され得る。

開示された実施態様の前記説明は、任意の当業者が本発明を製作するか、あるいは使用することを可能にするために提供される。これらの実施態様への様々な修正は、当業者に容易に明らかになるであろう。また、ここに定義された一般的な法則は、発明の趣旨または範囲から外れずに、他の実施態様に適用され得る。したがって、本発明は、ここに示された実施態様に限定されることは意図されず、ここに開示された法則と新規な特徴と一致する最も広い範囲を与えられるべきである。

一緒に相互運用する多数のコミュニケーション・ネットワークを示す。 ２つの端末間のデータ・セッションのプロトコル・スタックを示す。 ２つの端末を持ったユニキャスト・データ・セッションにおいて端末の存在を確認するプロセスを示す。 Ｎ端末を持ったマルチキャスト・データ・セッションにおいて端末の存在を確認するプロセスを示す。 ＲＴＣＰエコー要求用のＡＰＰパケットを示す。 データ・セッションにおいて他の端末の存在を決定するために端末によって実行されるプロセスを示す。 端末のブロックダイヤグラムを示す。

Claims (27)

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. 前記少なくとも１つのプロセッサは、リアル・タイム・トランスポート・プロトコル（ＲＴＰ）を使用して、データを送信するように、かつ、ＲＴＰコントロール・プロトコル（ＲＴＣＰ）を使用してシグナリングを送信するように、構成される、請求項２５に記載の装置。

Images