(57)【要約】【課題】非常コールのような高プライオリティコールに関連した有用なデータを与える方法及び装置を提供する。【解決手段】一実施形態において、このデータは、非常コールの（例えば、ＲＴＰパケットで運ばれる）ボイス又はユーザデータストリーム内で散在されるＲＴＰ制御プロトコル（ＲＴＣＰ）パケットのような１つ以上のリアルタイムプロトコルパケット内に埋め込まれるデータ（例えば、ＭＳＤ又はＦＳＤ）を含む。ユーザデータと同じ搬送接続を使用することにより開始ターミナル（例えば、インビヒクルシステム）から公共安全応答点（ＰＳＡＰ）へデータ部分を確実に送信するための装置及び方法について説明する。【選択図】図２
2015173482.tif 000002
【特許請求の範囲】
【請求項１】
実質的にリアルタイムのパケット交換動作のためのネットワーク内で非常コールを与える方法であって、非常コールは、第１ストリーム及び１つ以上の第２ストリームを有する複合ストリームを含むものである方法において、
第１ストリームを実質的に連続的な仕方で与える段階と、
１つ以上の第２ストリームを与える段階と、
少なくとも第１ストリーム及び１つ以上の第２ストリームを使用して複合ストリームを形成する段階と、
セッションを確立する段階であって、セッションは、更に、複合ストリームをルーティングするものである段階と、
そのセッションを経て複合ストリームを送信する段階と、
を備えた方法。
【請求項２】
前記セッションは、セッションイニシエーションプロトコルを使用して確立されたリアルタイムセッションを含む、請求項１に記載の方法。
【請求項３】
前記第１ストリームは、複数のボイスパケットより成り、前記１つ以上の第２ストリームは、複数のデータパケットより成る、請求項１に記載の方法。
【請求項４】
前記実質的に連続的な仕方は、ボイス信号を実質的に連続的にエンコードしてボイスパケットを発生することより成る、請求項３に記載の方法。
【請求項５】
前記１つ以上の第２ストリームを与えることは、実質的に不連続な又は非一定の仕方で行われる、請求項１に記載の方法。
【請求項６】
前記実質的に不連続な仕方は、少なくとも１つのソースからデータを周期的に又は間欠的にのみ与えることを含む、請求項５に記載の方法。
【請求項７】
前記データは、位置データを含み、前記少なくとも１つのソースは、ＧＰＳ受信器を含む、請求項６に記載の方法。
【請求項８】
前記複合ストリーム、第１ストリーム及び１つ以上の第２ストリームがパケット化される、請求項１に記載の方法。
【請求項９】
前記形成することは、前記第１ストリームの１つ以上のパケットを前記第２ストリームの１つ以上のパケットと散在させることによって前記複合ストリームを形成することを含む、請求項８に記載の方法。
【請求項１０】
前記散在させることは、マルチプレクスアルゴリズムを使用して遂行される、請求項９に記載の方法。
【請求項１１】
少なくとも第１ストリーム及び１つ以上の第２ストリームを使用して複合ストリームを形成することは、
第１ストリームの少なくとも一部分を複数のＲＴＰパケットに配置すること、
１つ以上の第２ストリームの少なくとも一部分を複数のＲＴＣＰパケットに配置すること、及び
ＲＴＰパケットをＲＴＣＰパケットと散在させること、
を含む請求項１に記載の方法。
【請求項１２】
前記ネットワークは、３ＧＰＰ  ＩＭＳ適合のセルラーネットワークを含み、前記セッションは、セッションイニシエーションプロトコル（ＳＩＰ）を使用して確立される、請求項１に記載の方法。
【請求項１３】
前記第１ストリームの少なくとも一部分を第１のパケット化されたプロトコル構造内に配置する段階と、
前記１つ以上の第２ストリームを第２のパケット化されたプロトコル構造内に配置する段階と、
前記第１及び第２のプロトコル構造を散在させて、前記送信する動作の前に前記複合ストリームの少なくとも一部分を形成する段階と、
を更に備え、前記第１ストリームは、実質的に連続的なユーザデータストリームを含み、  前記１つ以上の第２ストリームの少なくとも一部分は、高プライオリティ事象に関係している、請求項１に記載の方法。
【請求項１４】
高プライオリティ事象に関係したデータは、最小セットのデータ（ＭＳＤ）を含む、請求項１３に記載の方法。
【請求項１５】
前記ネットワークは、３Ｇセルラーネットワークを備え、前記送信は、セッション確立プロトコルを経て少なくとも１つのセッションを最初に確立することを含む、請求項１３に記載の方法。
【請求項１６】
前記第１のパケット化されたプロトコルは、リアルタイム搬送プロトコルを含み、前記第２のパケット化されたプロトコルは、リアルタイム制御プロトコルを含む、請求項１５に記載の方法。
【請求項１７】
前記方法は、事象に従って実質的に地上乗物内に配置された送信装置により実質的に自動的に開始される、請求項１３に記載の方法。
【請求項１８】
前記事象は、（ｉ）衝突、（ii）乗物の転倒及び（iii）乗物の火事より成るグループから選択される、請求項１７に記載の方法。
【請求項１９】
前記ユーザデータは、ビデオ及びボイスの両データを含む、請求項１３に記載の方法。
【請求項２０】
高プライオリティ事象に関係したデータは、コールの時間における第１エンティティに対する実質的に正確な位置データを含む、請求項１３に記載の方法。
【請求項２１】
前記正確な位置データは、ネットワークアドレスのみに基づくものではない、請求項２０に記載の方法。
【請求項２２】
パケット交換動作を行えるネットワーク内で非常コールを発信する装置において、
ボイスを連続的に捕獲して複数の第１パケットへとデジタル分析するマイクロホンと、  装置又は装置が支持されたプラットホームに関連した１つ以上のパラメータを１つ以上の第２パケットへとエンコードするための１つ以上のセンサと、
複数のパケットをワイヤレスネットワークにわたって送信するための無線送信器と、
前記送信器とデータ通信するプロセッサと、
複数のインストラクションを有するコンピュータプログラムを収容するためのメディアを含むコンピュータ読み取り可能な装置と、
を備え、前記複数のインストラクションは、プロセッサにより実行されたときに、
少なくとも一部分は前記複数の第１パケットを前記１つ以上の第２パケットと散在させることから送信するための複数のパケットを発生し、
前記散在した複数の第１パケット及び１つ以上の第２パケットをルーティングさせるセッションを確立し、そして
前記散在した複数のパケットを前記無線送信器により送信する、
ものである装置。
【請求項２３】
送信のための複数のパケットの前記発生は、複数の第３パケットを発生することを含み、この第３パケットは、前記散在した複数の第１パケット及び１つ以上の第２パケットから導出される、請求項２２に記載の装置。
【請求項２４】
前記装置は、更に、
ワイヤレスネットワークから複数のパケットを受け取るための無線受信器と、
その受け取った複数のパケットからのボイスをデジタル合成するためのスピーカと、
を備えた請求項２２に記載の装置。
【請求項２５】
前記装置は、更に、スピーカサブシステムと、ワイヤレスネットワークから複数のパケットを受け取るための受信装置と、ネットワークから受け取った複数のパケットをボイス成分及びデータ成分へと分離するための分離装置とを備え、この分離装置は、
（ｉ）ボイス成分をスピーカサブシステムに与え、
（ii）データ成分から１つ以上の第２パケットの受信状態を決定する、
請求項２２に記載の装置。
【請求項２６】
前記装置は、１人以上の乗員を搬送するための乗物内に実質的に収容される、請求項２２に記載の装置。
【請求項２７】
前記装置は、衛星ベースの位置決定受信器を備え、１つ以上のセンサは、
（ｉ）衝突を検出するための加速度計、
（ii）乗物の転覆を検出するための加速度計、及び
（iii）乗物の占有率を決定するためのセンサ、
より成るグループの１つ以上を含む、請求項２６に記載の装置。
【請求項２８】
前記ワイヤレスネットワークは、３ＧＰＰ  ＩＰマルチメディアコアネットワークサブシステム（ＩＭＳ）要件に適合するセルラーネットワークを含み、前記セッションは、セッションイニシエーションプロトコル（ＳＩＰ）を使用して確立される、請求項２２に記載の装置。
【請求項２９】
前記複数の第１パケットと前記１つ以上の第２パケットとを散在させることは、複数のＲＴＰパケットと１つ以上のＲＴＣＰパケットとを散在させることを含み、前記１つ以上のＲＴＣＰパケットは、最小セットのデータ（ＭＳＤ）を含む、請求項２２に記載の装置。
【請求項３０】
パケット交換ネットワーク内で非常コールを受け取るよう構成されたネットワーク装置において、
この装置とデータ通信するインターネットプロトコル（ＩＰ）ネットワークを経て第１及び第２の複数のパケットを受け取るためのネットワークインターフェイスと、
前記インターフェイスとデータ通信するプロセッサと、
複数のインストラクションを有するコンピュータプログラムを収容するためのメディアを含むコンピュータ読み取り可能な装置と、
を備え、前記複数のインストラクションは、プロセッサにより実行されたときに、
通信セッションの要求を受け取り、セッションは、前記第１及び第２の複数のパケットの転送を容易にするものであり、
前記セッションを確立し、
前記セッションを経て第１及び第２の複数のパケットを受け取り、
前記第１の複数のパケットから実質的にリアルタイムのユーザデータを抽出し、
前記第２の複数のパケットから非常関連のデータを抽出する、
ものであるネットワーク装置。
【請求項３１】
スピーカを有しそしてスピーカを経てオーディオを再生するためのオーディオモジュールを更に備え、オーディオは、抽出された実質的にリアルタイムのユーザデータから導出される、請求項３０に記載のネットワーク装置。
【請求項３２】
前記パケット交換ネットワークは、３ＧＰＰ  ＩＰマルチメディアコアネットワークサブシステム（ＩＭＳ）を含み、前記セッションは、少なくともセッションイニシエーションプロトコル（ＳＩＰ）を使用して確立される、請求項３０に記載のネットワーク装置。
【請求項３３】
前記第１及び第２の複数のパケットは、各々、散在されたＲＴＰ及びＲＴＣＰパケットである、請求項３０に記載のネットワーク装置。
【請求項３４】
前記ＲＴＣＰパケットの少なくとも一部分は、最小セットのデータ（ＭＳＤ）を含む、請求項２４に記載のネットワーク装置。
【請求項３５】
前記非常関連データは、最小セットのデータ（ＭＳＤ）を含む、請求項３０に記載のネットワーク装置。
【請求項３６】
前記ネットワーク装置は、公共安全応答点（ＰＳＡＰ）を含む、請求項３０に記載のネットワーク装置。
【請求項３７】
信頼できるパケット化されたプロトコル搬送を使用して、ネットワークからパケット化されたデータを受け取ってそのデータを処理するためのエンティティへ非常コールを伝達するためのテレコミュニケーション装置において、
無線送信器と、
前記送信器と通信し且つネットワークを経てパケット化されたデータを送信させる装置と、
を備え、そのパケット化されたデータは、実質的にリアルタイムのユーザデータを運ぶ第１パケットと、この第１パケットと散在されて非常関連データを運ぶ第２のパケットとを含むものであり、
前記第１及び第２のパケットは、異なるプロトコルに基づいてフォーマットされ、
前記異なるプロトコルの各々は、信頼性を与えるためのサービスクオリティ要件をサポートするものである、テレコミュニケーション装置。
【請求項３８】
前記非常関連データは、コール時のテレコミュニケーション装置の正確な位置データを含む、請求項３７に記載のテレコミュニケーション装置。
【請求項３９】
前記正確な位置データは、ネットワークアドレスのみに基づくものではない、請求項３８に記載のテレコミュニケーション装置。
【請求項４０】
ソースから行先へ非常コールをルーティングする方法において、
回路交換及びパケット交換の両ネットワークルートがコールのルーティングに利用できるかどうか決定する段階と、
両ルートが利用できる場合には、
（ｉ）前記ルートの少なくとも一方を、少なくとも１つの選択基準に対して評価し、    （ii）少なくとも一部分はその評価に基づいてルートの１つを選択し、
（iii）その選択されたルートを経てコールをルーティングする、
という段階と、
パケット交換ルートしか利用できない場合には、そのパケット交換ルートを経てコールをルーティングする段階と、
を備えた方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、一般に、ワイヤレス通信システムの分野に係る。より詳細には、本発明は、１つの態様において、ワイヤレスネットワーク内での非常又は同様のコールデータの送信に関する。
【０００２】
優先権：本出願は、２００９年２月１０日に出願された同じ名称の米国特許出願第１２／３６８，９４７号の優先権を主張するもので、当該特許出願は、参考としてここにそのまま援用する。
【０００３】
著作権：本特許文書の開示の一部分は、著作権保護を受ける資料を含む。著作権所有者は、特許商標庁の特許ファイル又は記録に現れるように特許開示を誰かが複写再現することに異議を唱えるものではなく、著作権の全ての権利は何であれ保存されるものとする。
【背景技術】
【０００４】
例えば、セルラー移動通信システムのようなデジタルワイヤレスシステムは、リアルタイム及び非リアルタイムの両方のサービスをユーザに提供する。リアルタイムサービスの例として、例えば、ボイス電話コール及びビデオ電話コールが含まれ、一方、非リアルタイムサービスには、種々のタイプのメッセージングサービス（例えば、ＳＭＳ、ＭＭＳ、ｅ−メール）又はプレゼンスサービス（例えば、チャット）が含まれる。デジタルセルラー移動通信は、回路交換ネットワークアーキテクチャー（ＣＳドメイン）又はパケット交換ネットワークアーキテクチャー（ＰＳドメイン）のいずれにおいても実現可能である。そのＣＳドメインコールは、例えば、デジタルボイスデータを交換するためにユーザデータ交換が行われる前に「回路」又は連続的接続を生成することが必要である。回路交換ネットワークは、あるターミナルを、移動セルラーネットワーク及びＣＳドメインコア（バックボーン）ネットワークを通して、別のターミナルに接続する。関連ネットワークエレメント間で種々の既知の制御プロトコルを経て接続確立が行われる。接続が確立されると、一方のターミナルによってセルラー移動ネットワークへ送信されるデジタルユーザデータは、接続ルートに沿ってネットワークを通して他方のターミナルへ搬送される。回路交換経路は、接続の期間中不変のままであり、コールのルートを変更するための修正をコール中に行うことができない。
【０００５】
ＰＳドメインコール（例えば、ＶｏＩＰコール）は、ＣＳドメインコールのような「ハード接続」を有していない。むしろ、ＰＳドメインコールは、ネットワークレベルに基づいて柔軟にルーティングされ、即ち基礎的な搬送ルートが事前に定義されておらず、動的に変化し得る。ＰＳドメインコールは、パケット化されて、ネットワークエレメントの「クラウド」を通して断片的に転送され、それ故、各データパケットは、ソース及び行先の両ターミナルのルート可能なネットワークアドレス（例えば、インターネットプロトコル即ちＩＰアドレス）を含む。パケット交換ネットワークの典型的な具現化では、インターネットプロトコル（ＩＰ）ルーティング情報が各送信データパケット内に埋め込まれる。このルーティングは、通常、ＩＰルーティングと称される。ネットワークレベルから、ＩＰルーティングは、無接続であるが、ＰＳドメインコールは、種々のパラメータ、例えば、交換されるデータのタイプ、クオリティ、フォーマット、コード、及び／又は基礎的搬送ストリームのクオリティ、帯域巾及びその他のパラメータをネゴシエーションするためのデータ転送の前に、アプリケーション／セッションレイヤにおける接続確立を必要とする（そして典型的にそれを遂行する）。
【０００６】
ＣＳ及びＰＳドメインは、それらの構造及び動作方法に直接関係した多数の個別の相違を有する。上述したように、ＣＳドメインコールは、動作を通じて「固定」回路を維持し、それ故、ＣＳコールは、データ送信のための適度に一貫したタイミングをある公差内で有する（データ送信は、固定の送信パラメータで同じルートをたどるので）。更に、ＣＳコールは、本来、線形であり、各送信は、その先駆体を順次にたどる。ＰＳドメインコールは、行先へのパケットのルーティングが柔軟であり、帯域巾又は容量が不規則であり、データがルーティングされるところのホップのセットの遅延が変化するために、ＣＳドメインモデルとは著しく相違する。従って、データパケットに関連したタイミング及び遅延は、ＰＳコールに対して広範囲に変化する。従って、ボイス又はビデオデータのようなリアルタイムデータを搬送するデータパケットは、通常、タイミング情報の抽出を可能にするプロトコルに埋め込まれる。
【０００７】
例えば、通常使用されるリアルタイムトランスポートプロトコル（ＲＴＰ）は、特に、そのようなタイミング情報を含み、そして通常、セルラー移動ネットワークのＰＳドメイン内のリアルタイムボイス及びビデオデータ送信に使用される。ＲＴＰ及びＲＴＣＰは、両方とも、アドレッシング、エラー検出、及び／又はエラー修正メカニズムのような広い搬送レイヤ要件を取り扱うシステム内で使用することが意図される。ＲＴＰ及びＲＴＣＰパケットが埋め込まれるところの最も通常に使用されるプロトコルは、ユーザデータグラムプロトコル（ＵＤＰ）及びトランスポートコントロールプロトコル（ＴＣＰ）である。他の相違の中で、ＴＣＰは、エラー修正メカニズムを伴う信頼できる搬送及びＱｏＳ（サービスクオリティ）を与えるが、ＵＤＰは、そのような保証を与えない。ＴＣＰの付加的な機能は、より多くのメッセージングオーバーヘッドと、ネットワークコンポーネント内の「状態メモリ」とを要求する。ＵＤＰは、より簡単で且つ効率的であるが、そのベアラに基づいてロッシーで且つ不規則でもある。ＵＤＰは、セグメントを送信又は受信するのにハンドシェークを必要とせず、従って、ＵＤＰは、一般的に、「無接続」とも分類される。ＲＴＰは、典型的に、ＵＤＰと組み合わせて使用される。というのは、２つのプロトコルが相補的な特徴を有するからである。ほとんどの使用の場合には、ＴＣＰの付加的な信頼性がＲＴＰにおいて浪費され、正確な配信を保証するために要求される付加的な時間がエラー修正の利益を否定することになる（ほとんどのＲＴＰシステムでは、遅いパケットが破棄される）。
【０００８】
非常及び他の高プライオリティコール
セルラー移動ネットワークにおける通常のサービス（ボイスコールのような）は、幾つかの受け容れ前提条件のもとでのみ確立される。これらの前提条件は、ユーザの（アイデンティティに関する）認証、特定のサービスに対するユーザの許可、ユーザのアカウント状態のチェック、及びユーザに対して必要なリソースを許可するためのオペレータの能力又は意志を含む。ネットワーク内に存在する条件、及び前提条件（例えば、認証、許可、及びアカウンティング）に関する移動ターミナルの状態に基づいて、コール確立時間が遅れたり、又はコールが全く拒絶されたりする。高プライオリティコール（例えば、火事、医療救急又は警察のような非常サービス支援を要求するために発信される非常コール）の場合には、遅延又は妨害を防止するための高プライオリティ取り扱いが非常コールに与えられる。
【０００９】
非常コールが要求されるか又は検出され、即ち、ターミナルがコール設定要求において非常コールを確立したい旨の指示をするか、或いは行先アドレスが非常サービスの要求であること（例えば、ユーザが９１１をダイヤルする、等）をネットワークが決定する。いずれの状態でも、非常コールを設定する要求を受け取った後、ネットワークは、その要求を高いプライオリティで処理し、そして処理を手早く片付ける。非常コールを確立するのに加えて、ネットワークは、非常コールの発信者に関する付加的な情報（地理的位置、等の）を着信点に与えるために他の手順を開始することができる。多くのセルラーネットワークは、最小セットの前提条件（例えば、ユーザを認証する、等の必要性を排除することによる）で確立できる「非常コール」を定義している。
【００１０】
ｅＣａｌｌ及びエンハンスト９１１（Ｅ９１１）
関連規格団体及び政府当局からの種々の手引きによれば、非常通信の別のクラスは、いわゆる“ｅＣａｌｌ”（ヨーロッパ）又はエンハンスト９１１（北アメリカ）を含み、後者は、更に、ワイヤレスＥ９１１及びＶｏＩＰ  Ｅ９１１を含む。例えば、ヨーロッパのｅＣａｌｌシステムについて述べた、参考としてここにそのまま援用する２００４年５月２８日付のeSafety Forum and eCall Driving Groupの“Memorandum of Understanding for Realization of Interoperable In-Vehicle eCall”と題するEuropean Commission Memorandum of Understanding及びそれに関連した実施規格を参照されたい。
【００１１】
例えば、上述したヨーロッパシステムのもとでは、ｅＣａｌｌは、自動車事故のような事象が検出された後、乗物の乗員により手動で又はインビヒクル（乗物内）システム（ＩＶＳ）により自動的に発生されるＩＶＳからの非常コールである。ｅＣａｌｌは、ＩＶＳから第２世代（２Ｇ）又は第３世代（３Ｇ）移動ネットワークを横切って公共安全応答点（ＰＳＡＰ）へ送信される。非常コールと一緒に、最小セットのデータ（ＭＳＤ）がＰＳＡＰへ送信され、これは、関連状態、例えば、自動車により自動的に発生されるか又は自動車から導出される情報を記述するものである。ＭＳＤで与えられる情報は、（典型的に内蔵のグローバルナビゲーション衛星システム（ＧＮＳＳ）トランシーバで測定された）車の高精度位置、乗員の数、事故により車が転倒したかどうか、等を含む。初期のｅＣａｌｌ又はＥ９１１サービスの従来の実施は、ＣＳドメインにおいて動作することに注意されたい。
【００１２】
例示的なＭＳＤのフォーマットが、図１に示されている。明らかなように、ＭＳＤ内の情報エレメントの一部分が任意であるので、ＭＳＤ１００のサイズは、変化し得る。より詳細には、任意のデータフィールド１０２のコンテンツは、拡張可能なマークアップ言語（ＸＭＬ）コードであることが要求されるだけであり、フィールドの長さは、既定の範囲内で変化することが許される。しかしながら、ＭＳＤ１００の最大データサイズは、１４０バイトである。
【００１３】
ＭＳＤに取って代わるものは、基礎となる搬送メカニズムがより大きなサイズのｅＣａｌｌデータの送信を許す場合に送信できるフルセットのデータ（ＦＳＤ）である。従って、ここで使用する「ｅＣａｌｌデータ」とは、ｅＣａｌｌ接続内で（ボイスデータと一斉に）送信されるＭＳＤ、ＦＳＤ又は他のデータを指す。
【発明の概要】
【発明が解決しようとする課題】
【００１４】
データ（例えば、ＭＳＤ又はＦＳＤのような）の送信については、多数の潜在的な選択肢が存在する。これらの選択肢は、（ｉ）ショートメッセージサービス；（ii）ユーザ対ユーザシグナリング（ＵＵＳ）；（iii）非構造化補足的サービスデータ（ＵＳＳＤ）；（iv）移動通信用グローバルシステム（ＧＳＭ（登録商標））ＣＳデータ；（ｖ）デュアルトーンマルチ周波数（ＤＴＭＦ）；及び（vi）インバンドモデム／シグナリングアプリケーション、を含む。しかしながら、これらの解決策は、非常コールとの組み合わせにおいて、適時の形態で、しかも、パケット交換ネットワークに再指令又は再ルーティングせずに、最小データのセットを搬送するに充分な能力を発揮することができない。従って、これらの欠点に対処する改良された装置及び方法が要望される。
【課題を解決するための手段】
【００１５】
本発明は、ワイヤレス（例えば、セルラー）通信ネットワーク内で非常又は同様のコールデータを送信するための改良された装置及び方法を提供することにより前記要望を満足する。
【００１６】
本発明の第１の態様において、パケット交換動作のためのネットワーク内に非常コールを与える方法が開示される。一実施形態において、このネットワークは、実質的にリアルタイムのパケット交換動作を与え、そして非常コールは、第１ストリーム及び１つ以上の第２ストリームを有する複合ストリームを含む。第１ストリームは、実質的に連続的に与えられ、そして複合ストリームは、少なくとも第１ストリーム及び１つ以上の第２ストリームを使用して形成される。セッションが確立され、セッションは、複合ストリームをルーティングするようにされ、複合ストリームは、セッションを経て送信される。
【００１７】
１つの変形例において、セッションは、セッションイニシエーションプロトコルを使用して確立されたリアルタイムセッションを含む。
【００１８】
別の変形例において、第１ストリームは、複数のボイスパケットを含み、又、１つ以上の第２ストリームは、複数のデータパケットを含む。ボイス信号を実質的に連続的にエンコードしてボイスパケットを発生することにより実質的に連続的なストリームが与えられる。
【００１９】
更に別の変形例において、１つ以上の第２ストリームを与えることは、実質的に不連続な又は非一定の仕方で行われ、この実質的に不連続な仕方は、少なくとも１つのソースからデータを周期的に又は間欠的にのみ与える。
【００２０】
更に別の変形例において、複合ストリーム、即ち第１ストリーム及び１つ以上の第２ストリームがパケット化され、そして複合ストリームは、第１ストリームの１つ以上のパケットを第２ストリームの１つ以上のパケットと散在させることにより形成される。
【００２１】
更に別の変形例において、前記散在させることは、マルチプレクスアルゴリズムを使用して遂行される。
【００２２】
更に別の変形例において、少なくとも第１ストリーム及び１つ以上の第２ストリームを使用して複合ストリームを形成することは、第１ストリームの少なくとも一部分を複数のＲＴＰパケットに配置し、１つ以上の第２ストリームの少なくとも一部分を複数のＲＴＣＰパケットに配置し、そしてＲＴＰパケットをＲＴＣＰパケットと散在させることにより遂行される。
【００２３】
更に別の変形例において、ネットワークは、３ＧＰＰ  ＩＭＳ適合のセルラーネットワークを含み、そしてセッションは、セッションイニシエーションプロトコル（ＳＩＰ）を使用して確立される。
【００２４】
本発明の第２の態様において、パケット交換動作を行えるネットワーク内で非常コールを発信する装置が開示される。一実施形態において、この装置は、（ボイスを連続的に捕獲して複数の第１パケットへとデジタル分析する）マイクロホンと、装置又は装置が支持されたプラットホームに関連した１つ以上のパラメータを１つ以上の第２パケットへとエンコードするための１つ以上のセンサと、複数のパケットをワイヤレスネットワークにわたって送信するための無線送信器と、この送信器とデータ通信するプロセッサと、複数のインストラクションを有するコンピュータプログラムを収容するための媒体を含むコンピュータ読み取り可能な装置とを備えている。複数のインストラクションは、プロセッサにより実行されたときに、少なくとも一部分は複数の第１パケットを１つ以上の第２パケットと散在させることから送信するための複数のパケットを発生する。又、インストラクションは、散在した複数の第１パケット及び１つ以上の第２パケットを記憶せずにルーティングするためのセッションを確立すると共に、散在した複数のパケットを無線送信器により送信する。
【００２５】
１つの変形例において、送信のための複数のパケットの発生は、複数の第３パケットを発生することを含み、この第３パケットは、散在した複数の第１パケット及び１つ以上の第２パケットから導出される。
【００２６】
別の変形例において、装置は、更に、ワイヤレスネットワークから複数のパケットを受け取るための無線受信器と、その受け取った複数のパケットからのボイスをデジタル合成するためのスピーカとを備えている。
【００２７】
更に別の変形例において、装置は、更に、スピーカサブシステムと、ワイヤレスネットワークから複数のパケットを受け取るための受信装置と、ネットワークから受け取った複数のパケットをボイス成分及びデータ成分へと分離するための分離装置とを備えている。この分離装置は、ボイス成分をスピーカサブシステムに与え、データ成分から１つ以上の第２パケットの受信状態を決定する。
【００２８】
更に別の変形例において、装置は、１人以上の乗員を搬送するための乗物内に実質的に収容される。
【００２９】
更に別の変形例において、装置は、衛星ベースの位置決定受信器（例えば、ＧＰＳ受信機）を備えている。１つ以上のセンサは、（ｉ）衝突を検出するための加速度計、（ii）乗物の転覆を検出するための加速度計、及び／又は（iii）乗物の占有率を決定するためのセンサを含む。
【００３０】
更に別の変形例において、ワイヤレスネットワークは、３ＧＰＰ  ＩＰマルチメディアコアネットワークサブシステム（ＩＭＳ）要件に適合するセルラーネットワークであり、又、セッションは、セッションイニシエーションプロトコル（ＳＩＰ）を使用して確立される。
【００３１】
更に別の変形例において、複数の第１パケットと１つ以上の第２パケットとを散在させることは、複数のＲＴＰパケットと１つ以上のＲＴＣＰパケットとを散在させることを含み、１つ以上のＲＴＣＰパケットは、最小セットのデータ（ＭＳＤ）を含む。
【００３２】
本発明の第３の態様において、パケット交換ネットワーク内で非常コールを受け取るように構成されたネットワーク装置が開示される。一実施形態において、この装置は、この装置とデータ通信するインターネットプロトコル（ＩＰ）ネットワークを経て第１及び第２の複数のパケットを受け取るためのネットワークインターフェイスと、このインターフェイスとデータ通信するプロセッサと、複数のインストラクションを有するコンピュータプログラムを収容するための媒体を含むコンピュータ読み取り可能な装置と、を備えている。これらインストラクションは、プロセッサにより実行されたとき、通信セッションの要求を受け取り（セッションは、第１及び第２の複数のパケットの転送を容易にする）、セッションを確立し、セッションを経て第１及び第２の複数のパケットを受け取り、第１の複数のパケットから実質的にリアルタイムのユーザデータを抽出し、そして第２の複数のパケットから非常関連のデータを抽出する。
【００３３】
１つの変形例において、ネットワーク装置は、更に、スピーカを有しそしてスピーカを経てオーディオを再生するオーディオモジュールを備え、オーディオは、抽出された実質的にリアルタイムのユーザデータから導出される。
【００３４】
別の変形例において、パケット交換ネットワークは、３ＧＰＰ  ＩＰマルチメディアコアネットワークサブシステム（ＩＭＳ）を含み、又、セッションは、少なくともセッションイニシエーションプロトコル（ＳＩＰ）を使用して確立される。
【００３５】
別の変形例において、第１及び第２の複数のパケットは、各々、散在されたＲＴＰ及びＲＴＣＰパケットである。
【００３６】
更に別の変形例において、ＲＴＣＰパケットの少なくとも一部分は、最小セットのデータ（ＭＳＤ）を含む。更に別の変形例において、非常関連データは、最小セットのデータ（ＭＳＤ）を含む。
【００３７】
更に別の変形例において、ネットワーク装置は、公共安全応答点（ＰＳＡＰ）の一部分である。
【００３８】
本発明の第４の態様において、パケット交換動作を行えるネットワーク内に高プライオリティコールを発信する方法が開示される。一実施形態において、この方法は、実質的に連続的なユーザデータストリーム、及び高プライオリティ事象に関連した複数のデータを与えることを含む。ユーザデータストリームの少なくとも一部分は、第１のパケット化されたプロトコル構造内に配置され、高プライオリティ事象に関連したデータの少なくとも一部分は、第２のパケット化されたプロトコル構造内に配置される。第１及び第２のプロトコル構造が散在され、そして複合ストリームがネットワークにわたり通信セッションを経て送信される。
【００３９】
１つの変形例において、高プライオリティコールは、非常コールであり、そして高プライオリティ事象に関連したデータは、最小セットのデータ（ＭＳＤ）を含む。
【００４０】
別の変形例において、ネットワークは、３Ｇセルラーネットワークであり、送信は、セッション確立プロトコルを経て少なくとも１つのセッションを最初に確立することにより遂行される。
【００４１】
別の変形例において、第１のパケット化されたプロトコルは、リアルタイム搬送プロトコルを含み、そして第２のパケット化されたプロトコルは、リアルタイム制御プロトコルを含む。
【００４２】
更に別の変形例において、前記方法は、事象に従って実質的に地上乗物内に配置された送信装置により実質的に自動的に開始される。この事象は、例えば、（ｉ）乗物の衝突、（ii）乗物の転倒及び／又は（iii）乗物の火事を含む。
【００４３】
更に別の変形例において、ユーザデータは、ビデオ及びボイスの両データを含む。
【００４４】
更に別の変形例において、高プライオリティ事象に関係したデータは、コールの時間における第１エンティティに対する実質的に正確な位置データを含み、その正確な位置データは、ネットワークアドレスのみに基づくものではない。
【００４５】
本発明の第５の態様において、非常コールを伝達するためのテレコミュニケーション装置が開示される。一実施形態において、この伝達は、信頼できるパケット化されたプロトコル搬送を使用し、そして１つ以上の非常コールが、ネットワークからパケット化されたデータを受け取ってそのデータを処理するためのエンティティへ送られる。この装置は、無線送信器と、この送信器と通信してネットワークを経てパケット化されたデータを送信させるよう構成された装置とを備えている。パケット化されたデータは、実質的にリアルタイムのユーザデータを運ぶ第１パケットと、この第１パケットと散在されて非常関連データを運ぶ第２のパケットとを含み、これら第１及び第２のパケットは、異なるプロトコルに基づいてフォーマットされる。これらの異なるプロトコルの各々は、上述した信頼できる搬送を与えるためのサービスクオリティ要件をサポートする。
【００４６】
１つの変形例において、非常関連データは、コール時のテレコミュニケーション装置の正確な位置データ（ネットワークアドレスに基づいてもよいし、そうでなくてもよい）を含む。
【００４７】
本発明の第６の態様において、ソースから行先へ非常コールをルーティングする方法が開示される。一実施形態において、この方法は、回路交換及びパケット交換の両ネットワークルートがコールのルーティングに利用できるかどうか決定し、両ルートが利用できる場合には、それらルートの少なくとも一方を、少なくとも１つの選択基準に対して評価する。少なくとも一部分はこの評価に基づいてルートの１つが選択され、その選択されたルートを経てコールがルーティングされる。パケット交換ルートしか利用できない場合には、パケット交換ルートを経てコールがルーティングされる。
【００４８】
本発明の別の態様において、マルチモード（例えば、ＣＳ及びＰＳが可能な）ワイヤレスネットワークを経て非常データをルーティングするためのネットワークコントローラ及び関連方法が開示される。一実施形態において、ネットワークコントローラは、２つの選択肢（ＣＳ又はＰＳ）のどちらが最適であるかを１つ以上の基準に基づいて評価し、次いで、そのドメインを経てデータをルーティングするためのロジックを備えている。例えば、ＣＳドメインは、技術的又は他の理由で利用できないことがあり、従って、ＰＳドメインｅＣａｌｌが選択される。
【００４９】
本発明の更に別の態様において、記憶媒体を有するコンピュータ読み取り可能な装置が開示される。ある変形例では、この装置は、ハードディスクドライブ（ＨＤＤ）、ＣＤ−ＲＯＭ又はプログラム或いはデータメモリ集積回路（ＩＣ）の形態をとり、そしてここに述べる機能の種々の態様を具現化する１つ以上のコンピュータプログラムを記憶する。
【００５０】
本発明の他の特徴及び効果は、当業者であれば、添付図面及び以下に述べる例示的実施形態の詳細な説明を参照すれば、直ちに認識されるであろう。
【図面の簡単な説明】
【００５１】
【図１】従来の最小セットのデータ（ＭＳＤ）パケットに関連したパケット構造のグラフ表示である。
【図２】本発明によりリアルタイムのボイスコール内に非常コールデータを埋め込むための一般化された非常コールプロセスの一実施形態を示す論理フローチャートである。
【図２Ａ】本発明により非常コールデータをルーティングするためのドメイン裁定／選択プロセスの一実施形態を示す論理的フローチャートである。
【図３】従来技術による一般的なリアルタイムプロトコル（ＲＴＰ）アプリケーションパケットを示す。
【図３Ａ】本発明によりインビヒクルシステム（ＩＶＳ）の非常コールサービスを提供するためのリアルタイムプロトコル（ＲＴＰ）アプリケーションパケットのパケットフォーマットの１つの例示的実施形態を示す。
【図３Ｂ】インビヒクルシステム（ＩＶＳ）の非常コールサービスを提供するためのリアルタイムプロトコル（ＲＴＰ）アプリケーションパケットのパケットフォーマットの別の例示的実施形態を示すもので、既定値を有する複数の例示的な設定可能なフィールドを示す。
【図３Ｃ】インビヒクルシステム（ＩＶＳ）の非常コールサービスを提供するためのリアルタイムプロトコル（ＲＴＰ）アプリケーションパケットのパケットフォーマットの更に別の例示的実施形態を示すもので、パケット順序を確立するフィールドを示す。
【図３Ｄ】インビヒクルシステム（ＩＶＳ）の非常コールサービスを提供するためのリアルタイムプロトコル（ＲＴＰ）アプリケーションパケットの拡張可能なパケットフォーマットの一実施形態を示す。
【図４】インビヒクルシステム（ＩＶＳ）の非常コールサービスを提供するための本発明によるセッションイニシエーションプロトコル（ＳＩＰ）ベースのコール設定プロセスの１つの例示的実施形態のグラフィック表示である。
【図５】本発明の一実施形態による方法及び装置を使用してＩＶＳと通信する例示的なセルラーＰＳＡＰシステムのグラフィック表示である。
【図６Ａ】本発明によるＰＳＡＰ装置の一実施形態を示すブロック図である。
【図６Ｂ】本発明による地上乗物（自動車）内に配置されるＩＶＳ装置の一実施形態を示すブロック図である。
【発明を実施するための形態】
【００５２】
全体を通じて同じ部分が同じ番号で示された添付図面を参照する。
【００５３】
概略
本発明は、特に、高プライオリティコールに関連した有用なデータを与えるための方法及び装置を開示する。一実施形態において、データは、非常コール（ｅＣａｌｌ）のボイスデータストリームを含むＲＴＰ制御プロトコル（ＲＴＣＰ）内に埋め込まれた最小セットのデータ（ＭＳＤ）である。ボイスデータと同じ搬送接続を使用することによりターミナル（ＩＶＳ）から公共安全応答点（ＰＳＡＰ）へＭＳＤデータ部分を高い信頼性で送信するための装置及び方法について説明する。更に、ＭＳＤデータパケットは、必要に応じて修正又は変更してもよいが、ボイスデータパケットは、そのままとすることができる。
【００５４】
又、本発明は、ある点において、好都合にも、非常サービスインフラストラクチャーをサポートするために著しい変更を必要とせずに、現在のセルラーネットワーク配備が回路交換（ＣＳ）サービスからパケット交換（ＰＳ）サービスへと自然に進化できるようにする。更に、このような具現化は、ＣＳ及びＰＳドメインに及ぶシステムの種々の段階的変化に適している。
【００５５】
一実施形態において、タイミング、パッケージング及び他の目的のためにＲＴＰを既に使用しているパケット交換ボイス（又は他のリアルタイムデータ）接続がレバレッジされる。より詳細には、ＲＴＰパケットストリームがＲＴＰ制御プロトコル（ＲＴＣＰ）のパケット内に周期的に埋め込まれ、このようなＲＴＣＰパケットは、各関係者に、受信クオリティ及びソース記述のようなパラメータを含む他の関係者に関する関連情報を与える。
【００５６】
別の変形例では、データの信頼できる送信、エラー修正、再送信及び／又はデータ回復のようなパケット交換データ搬送の利点が、ＭＳＤデータパケットとの使用についてレバレッジされる。典型的にデータストリームをボイスデータストリームの前又は後に連結してデータ送信をボイスでパッケージングする他の方法とは異なり、ＲＴＣＰプロトコルの環境では「散在(interspersing)」解決策が利用され、即ちデータストリームがボイスストリームと散在され、従って、ＭＳＤの一定の更新、ＭＳＤの複数の再送信、等の特徴を実現できるようにする。
【００５７】
別の態様において、ここに開示する装置及び方法は、特に、セルラーネットワークの既存のフレーム内で動作するようにされる。セルラーネットワークにより課せられる制限に鑑み、標準化されたｅＣａｌｌデータ送信のためのタイミング制約を順守しなければならない。好都合にも、種々のボイスコーダデータ及び／又はテクノロジーをサポートするのに現存のプロトコルスタックへの変更は必要とされない。ここに開示する本発明は、ネットワークコンポーネントにより非ボイスデータを変更できるが、このような変更は、システムの正しい動作にとって必要でない。しかしながら、より重要なことに、ボイスデータは、パケット化されたままであり、変更せずに送信されて、トランスコーディング又は他のそのようなプロセスに伴う又はそれにより引き起こされるエラーを防止することができる。
【００５８】
更に別の効果的な態様において、当該エンティティ（例えば、ｅＣａｌｌの環境では、インビヒクルシステム（ＩＶＳ）及びＰＳＡＰ）間でエンドツーエンドのベースでデータのルーティングが行われ、即ちデータルーティングのために付加的なネットワークコンポーネント又は記憶装置が必要とされない。（一般的に、上述した「記憶及び転送」動作モードに入る）データの送信に使用される他の方法とは異なり、ｅＣａｌｌを補足するために送信されるデータは、タイミング要件に従うことができ、（例えば、ユーザのホームネットワークに）不必要にリルートされずに直ちに送信することができる。
【００５９】
例示的実施形態の詳細な説明
本発明の例示的な実施形態を以下に詳細に述べる。これら実施形態は、主として、例示的なインビヒクルシステム（ＩＶＳ）と公共安全応答点（ＰＳＡＰ）との間の通信に関して説明するが、本発明の原理は、例示的なＩＶＳ及びＰＳＡＰを越えたシステムにも適用できることが認められる。例えば、３Ｇセルラー電話のような現世代のユーザ装置（ＵＥ）は、ｅＣａｌｌデータを受信装置（Ｅ９１１オペレータのような）に効率的に通信するのに必要な情報を発生することができる。
【００６０】
更に、本発明は、管轄又はシステム（例えば、ｅＣａｌｌ対Ｅ９１１、等）に何ら限定されず、文字通りこのような環境に使用することができる。
【００６１】
更に、リアルタイムトランスポートプロトコル（ＴＲＰ）及びＲＴＰ制御プロトコル（ＲＴＣＰ）に関して主として述べるが（参考としてここにそのまま援用する２００３年７月付の“RTP: A Transport Protocol for Real-Time Applications”と題するＲＦＣ３５５０を参照）、本発明の種々の実施形態では、他のプロトコルに容易に置き換えることができると共に、当業者であれば、本開示の内容が与えられれば、他のプロトコルが明らかとなることが認められる。例えば、これらに限定されないが、ＲＴＳＰ（参考としてここにそのまま援用する１９９８年３月付の“Real Time Streaming Protocol (RTSP)”と題するＲＦＣ２３２６を参照）、ＳＲＴＰ（参考としてここにそのまま援用する２００４年３月付の“The Secure Real-time Transport Protocol (SRTP)”と題するＲＦＣ３７１１を参照）、ＳＣＴＰ（参考としてここにそのまま援用する２００７年９月付の“Stream Control Transmission Protocol”と題するＲＦＣ４９６０を参照）、及び／又はＺＲＴＰ（参考としてここにそのまま援用する２００８年１０月２５日付の“ZRTP: Media Path Key Agreement for Secure RTP-draft-zimmermann-avt-zrtp-10”を参照）プロトコルを、本発明と矛盾なく使用することができる。
【００６２】
更に、本発明の幾つかの実施形態は、自動車又はトラックのような地上乗物に関して説明するが、それらに何ら限定されず、レール（列車）、航空機、船舶及びオートバイを含む（これに限定されないが）他の乗物又は非乗物パラダイムにも容易に適用することができる。
【００６３】
方法
図２を参照すれば、高プライオリティコール（以下に定義する“ｅＣａｌｌ”のような）をパケット交換ネットワークでサポートできるようにボイスパケットストリームと散在されたデータ（例えば、最小セットのデータ又はＭＳＤ)を搬送するための一般化されたプロセス２００の第１の実施形態が示されている。ここで使用する「高プライオリティ」という語は、一般に、緊急性又はプライオリティが他のトラフィックより高いコール又は他の送信を指すが、これに限定されない。高プライオリティコールの一例は、警察、火事、医療、等の支援のための非常コールである。高プライオリティコールの別の例は、法律執行、消防署、軍事、政府団体、等の要員、或いは通信媒体にアクセスする高い優位性又は必要性を有する他の個人又はグループ間のコール（日常のコールも）に関連したものである。
【００６４】
ここで使用する“ｅＣａｌｌ”という語は、これに限定されないが、特に、参考としてここにそのまま援用する“Technical Specification  3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; IP Multimedia Subsystem (IMS) emergency sessions (Release 8)”と題する３ＧＰＰ  ＴＳ  ２３．１６７  Ｖ８．１．０（２００８年９月付け）に記載された非常コール及びサービスを指し、これは、ＩＰマルチメディア（ＩＭ）非常サービスをサポートするのに必要なエレメントを含むＩＰマルチメディアコアネットワークサブシステム（ＩＭＳ）における非常サービスのための「段階２」サービス記述について述べたものである。又、参考としてここにそのまま援用するＩＴＵ−Ｔ推奨勧告Ｉ．１３０は、テレコミュニケーションサービスを特徴付ける３段階方法について述べており、更に、参考としてここにそのまま援用するＩＴＵ−Ｔ推奨勧告Ｑ．６５は、その方法の段階２を定義するものである。又、ＴＳ２３．１６７  Ｖ８．１．０は、ＩＭＳ非常サービスをプロビジョニングするのに重要なアクセスネットワーク観点もカバーする。ＩＭＳ非常サービスに関連した他の３ＧＰＰ仕様は、参考として各々ここにそのまま援用するＴＳ  ２３．２２８（一般的にＩＭＳ）、ＴＳ  ２３．２３４（３ＧＰＰ／ＷＬＡＮインターワーキングについて述べた）、及びＴＳ  ２３．２７１（位置サービス）を含む。又、参考としてここにそのまま援用するＴＳ  ２５．３０１は、ＵＭＴＳ地上無線アクセスネットワークの全体的な説明も含む。
【００６５】
ＩＭＳ非常サービスに関連した他の非３ＧＰＰ仕様は、各々参考としてここにそのまま援用する３ＧＰＰ２  Ｃ．Ｓ００２４−Ａ及び３ＧＰＰ２  Ｘ．Ｓ００１１に指定された３ＧＰＰ２  ｃｄｍａ２０００  ＨＲＰＤ  ＩＰ−ＣＡＮを含む。
【００６６】
プロセス２００のステップ２０２では、高プライオリティコールが発信される。１つの例示的実施形態では、コールは、クライアント又はユーザ装置により自動的に開始され、事故検出の場合に乗物が非常コールを自動的にトリガーするような非常コール状態が指定される。ここで使用する「クライアント装置」及び「ユーザ装置」という語は、セルラー電話、スマートホン（例えば、ｉＰｈｏｎｅTM）、パーソナルコンピュータ、例えば、ｉＭａｃTM、Ｍａｃ  ＰｒｏTM、Ｍａｃ  ＭｉｎｉTM、又はＭａｃＢｏｏｋTM、及びデスクトップであるかラップトップであるかその他であるかに関わらずミニコンピュータ、並びに移動装置、例えば、ハンドヘルドコンピュータ、ＰＤＡ、ビデオカメラ、セットトップボックス、パーソナルメディア装置（ＰＭＤ）、インビヒクルシステム、或いはそれらの組み合わせを含むが、これに限定されない。
【００６７】
更に別の変形例では、ユーザが非常コールをダイヤルして支援を要求するようにユーザによりコールが発せられる。
【００６８】
コールに非常状態が指定される点（及びメカニズム）は、コールを発信する方法、又はコールが発せられるネットワークに基づいて変化する。１つの変形例において、非常コール状態は、例えば、そのような状態を指示するデータ（例えば、データフィールドが既定値を有する、フラグをセットする、等）をメッセージヘッダ、等に含ませることにより、発信者により直ちにフラグが立てられる。別のケースでは、コールが特殊なコールとして発信されてもよい。例えば、ＣＳ非常コール（参考としてここにそのまま援用する３ＧＰＰ  ＴＳ２４．００８に基づく）において、コール制御エンティティは、（通常のコールの場合にＳＥＴＵＰメッセージを送信するのに対して）コールを確立するためにＥＭＥＲＧＥＮＣＹ  ＳＥＴＵＰメッセージを送信する。別の例、即ちＩＭＳ非常コール（参考としてここにそのまま援用する３ＧＰＰ  ＴＳ２４．２２９に基づく）では、ＵＥは、“ＳＯＳ”のトップレベルサービス形式（参考としてここにそのまま援用するＲＦＣ５０３１に特定された）でユニフォームリソースネーム（ＵＲＮ）サービスを使用する。更に別の実施形態では、接続のルート情報の１つ以上のコンポーネントを使用して、非常コール状態を決定する。１つのそのような変形例では、非常コール状態がネットワークエンティティによって指定され、例えば、ここでは、パケットがインターセプトされて、そのルート情報（例えば、ユーザ又はＵＥが９１１のような指定の番号をダイヤルするようなソース又は行先）により非常コールとして処理される。
【００６９】
プロセス２００のステップ２０４において、ネットワークアクセスが開始される。１つの例示的実施形態において、セルラーサービスのために通常使用される認証及び許可手順は、バイパスされるか又は手早く片付けられる。ネットワークは、コールに非常状態を与えるべきという指示をＩＶＳから受け取るか、又はネットワークは、ルート情報に基づいて、コールを非常プライオリティで発信すべきと決定する。加えて、このようなアクセスは、「接続ベース」でも又は「無接続」でもよい。このようなネットワークアクセスは、通常の搬送テクノロジーのいずれかを使用して開始される。ここで使用する「搬送(transport)」という語は、例えば、トランスポート制御プロトコル（ＴＣＰ）、ユーザデータグラムプロトコル（ＵＤＰ）、データグラム混雑制御プロトコル（ＤＣＣＰ）、リアルタイムトランスポートプロトコル／リアルタイムトランスポート制御プロトコル（ＲＴＰ／ＲＴＣＰ）、及びストリーム制御送信プロトコル（ＳＣＴＰ）のような物理的インターフェイス（ＰＨＹ）を経てデータを送信できる搬送プロトコルを指すが、これらに限定されない。このようなネットワークアクセスは、以下、搬送ストリームと称され、最低限、ローカルソース、ローカル行先、チェック和フィールド及びデータフィールドのようなデータより成る１つ以上のパケットを含む。ローカルソースは、例示的な実施形態では、ＩＶＳネットワークアドレスであり、そしてローカル行先は、ＰＳＡＰ（必ずしもルーティングセンターではない）のアドレスである。
【００７０】
ステップ２０６において、搬送ストリームの上にリアルタイムプロトコル（例えば、ＲＴＰ、ＲＴＳＰ、等の）が確立されるか又は積層される。以下に詳細に述べるように、このようなリアルタイムプロトコルは、最低限、解釈されたときに、特定の時間及び／又は一連の調時された事象（例えば、各時間値又はインデックスを伴うパケット）を識別する情報を含む。
【００７１】
プロセスのステップ２０８において、２つ以上の「ストリーム」が発生され、その少なくとも１つは、マシン読み取り可能なデータストリームであり、又、その少なくとも１つは、ボイス又は他のそのようなペイロード（ユーザ）データのデジタル化された（例えば、圧縮された）表現である。ここで使用する「ストリーム」という語は、実質的に連続的な及び非連続的な（例えば、周期的又は断続的な）データフローを指すのに使用される。
【００７２】
前記プロセスの１つの具現化では、コード励振線形予想（ＣＥＬＰ）ベースのボイスコーダ（ｖｏｃｏｄｅｒ）、例えば、ＡＣＥＬＰ、ＱＣＥＬＰ、ＲＣＥＬＰ、ＬＤ−ＣＥＬＰ（例えば、Ｇ．７２８）、等の１つを使用して、アナログマイクロホンを経て受け取ったユーザのボイスをデジタル化する。マシン読み取り可能なデータストリームは、他のネットワークコンポーネントにより読み取り可能で且つ書き込み可能のままとされ、一方、ボイスのデジタル表現は、他のネットワークコンポーネントによる変更から保護される。
【００７３】
プロセスのステップ２１０では、２つのストリームは、リアルタイムプロトコルを使用してネットワークを経て送信するために散在される。より詳細には、１つの変形例において、マシン読み取り可能なデータストリームからのデータは、１つ以上のＲＴＣＰパケット内に埋め込まれ、それらパケットは、次いで、ユーザデータパケットストリーム（例えば、上述したデジタル化されたボイスを運ぶＲＴＰパケット）へ挿入されるか又は散在される。この散在は、デジタル技術で一般的な多数の解決策を使用して達成され、それらの解決策は、（例えば、マルチプレクサ又はインターリーバーを使用して１つのデータストリームを１つ以上の他のデータストリーム内に分布させる）データマルチプレクシング、及び／又は（例えば、データを現存のストリームに添付するか、さもなければ、アタッチする）便乗のような方法を含む。
【００７４】
ステップ２１２では、マシン読み取り可能なデータ及びデジタルボイス表現の組み合わせより成る散在ストリームを運搬するセッションが開始される。このセッションを確立するのに、例えば、ＳＩＰ（以下に述べる）のようなセッションベースのプロトコルを含む種々のメカニズムを使用することができる。このセッションは、ネットワーク経路がソースエンドポイント（ＩＶＳ）及び行先エンドポイント（ＰＳＡＰ）により特徴付けられる単一のネットワーク接続において行われる。ネットワーク内の経路は、複数の搬送レイヤ接続部間の「ホップ」を使用して構成されるが、この経路は、マシン読み取り可能なデータ及びデジタルボイス表現の両方に対して同一である。即ち、エンドポイント間の経路は変化し得るが、マシン読み取り可能なデータ及びデジタル化されたボイス又は他の「ペイロード」に対して常に同一である。
【００７５】
更に、マルチストリームセッションがリアルタイムで行われ、ボイス及びデータの両方に非常コール状態取り扱いの利益が与えられる。
【００７６】
ＰＳＡＰにおいて受信されると、２つ以上のデータストリームは、例えば、デマルチプレクシング、そのヘッダに存在して、アイデンティティ（例えば、ＲＴＣＰパケット対ＲＴＰパケット）、ひいては、各パケットがどちらのストリームに属するか指示するデータに基づくパケットのルーティング、又は更に別の良く知られたメカニズムを経て分離される。マシン読み取り可能なデータストリームは、少なくとも一部分は、ＩＶＳに関連した１つ以上のパラメータを決定するように処理される。ボイスのデジタル表現は、オペレータ又はスピーチ認識システムへの配布、記憶及び／又は再生のための可聴信号へと再構成される。
【００７７】
ここに例示する実施形態は、マシン読み取り可能なデータストリームを、デジタル化されたボイスに関連して使用するが、本発明は、ストリームの二次成分がデジタル化されたボイスではなく、他のタイプのデジタル化されたコンテンツ（例えば、ビデオ、ファイルデータ、等の別のメディア）である場合も等しい成功性で実施することができ、本発明は、ボイスデータのみに限定されないことが明らかであろう。例えば、ＩＶＳシステム装置又はセンサ（以下に詳細に述べる）の１つは、必要に応じてＰＳＡＰへ送信できる画像又はビデオデータのパケットストリームを発生できるカメラを備えてもよい。
【００７８】
又、ボイス及び／又はビデオは、受動的に得られ、又は乗物が盗難にあった場合のようにユーザが知らないうちに得られ、搭載のマイクロホン及び／又はカメラを使用して、ボイス／ビデオデータを、泥棒の知らないうちにＰＳＡＰ又は他のエンティティへストリーミングできることにも注意されたい。
【００７９】
更に、本発明のある実施形態では、ＲＴＰコンテンツなしでも、ＲＴＣＰの使用を実行することができる。このような実施形態は、「ペイロード」それ自体なしに実施されてもよく、例えば、コールは、自動的に開始され、事象に関する既定のデータしか転送しないように設計される（例えば、ＡＧＰＳ、等により確認されたＶＩＮ、乗物位置を送信する窃盗検出及び報告システム）。
【００８０】
更に、「ペイロード」の通信は、Ｍ２Ｍ（マシン対マシン）多様性のものであり、例えば、ワイヤレス（例えば、セルラー）システム内の１つの例示的なＭ２Ｍ具現化については、参考としてここにそのまま援用する、２００８年８月２９日出願の“Methods and Apparatus for Machine-to-Machine Based Communications Service Classes”と題する共通所有の同時係争中の米国特許出願第１２／２３１，０９５号を参照されたい。更に、Ｍ２Ｍデータ通信は、本発明における「ペイロード」の基礎を与えるが、「非常」（又はより一般的には高プライオリティ）及び「Ｍ２Ｍ」の両方としての所与のコールの分類は、以上の開示で述べたタイプの異なるコール取り扱い及びルーティング判断のための基礎として使用できることも明らかである。例えば、性質上Ｍ２Ｍ及び「非常」の両方であるコールには、人間に基づくコールより低いプライオリティが与えられてもよい。というのは、マシン（コールの開始者）に関連した非常は、人命救助よりプライオリティが低いからである。しかしながら、常にそうではなく、例えば、コールを開始するＭ２Ｍ「マシン」が人命に悪影響を及ぼし得るインフラストラクチャーの重要な断片に関連したもの、例えば、大都市エリア又は病院に関連した配電ステーションの変圧器、差し迫った崩壊等を指示する橋の応力／歪センサ、等のこともある。従って、本発明は、ＲＴＣＰ又は同様のパケットに埋め込まれたデータ部分だけではなく、Ｍ２Ｍデータ（即ち、その親装置に関連した開始マシンによって発生されて、ＲＴＰ又は「ペイロード」パケットに埋め込まれた）も、コールの取り扱い、プライオリティ決め、及び／又はルーティングを区別するための基礎として使用することができる。
【００８１】
図２Ａを参照し、ＣＳ及びＰＳドメインネットワーク間を裁定し選択する方法の一実施形態を説明する。本発明は、特に、パケット交換ネットワークドメイン上で動作するようにされるが、ＣＳドメインサービスを利用できる場合もある。従って、常に、ＰＳドメイン搬送へ単純にデフォールトするのではなく、本発明の別の変形例は、一方のドメインを使用する非常コールを他方のドメインへ発信する判断をする前に選択又は裁定ロジックを使用する。このロジックは、例えば、ネットワーク装置（例えば、コールルーティングコントローラ）上で具現化されるか、又はクライアント装置（例えば、ＩＶＳ）それ自体の中で具現化されるか、或いはその両方でよい。
【００８２】
図２Ａに示すように、方法２５０の第１ステップ２５２は、コールをルーティングするために、回路交換及びパケット交換の両ネットワークルートが利用できるかどうか決定する。このデータは、ハードコード化されてもよいし（例えば、ネットワークインフラストラクチャー、ひいては、不変に基づき）、或いは１つ以上の状態インジケータに基づいてもよい。例えば、回路交換搬送は、ネットワークインフラストラクチャーの一部分として含まれるが、その搬送は、ここでは利用されないことがある（例えば、保守、装置故障、又は非常に高い負荷／混雑のために）。
【００８３】
ステップ２５４については、ＣＳドメイン及びＰＳドメインの両ルートが利用できる場合には、選択ロジックは、次いで、少なくとも１つの選択基準に対して少なくとも一方のルートを評価する（ステップ２５６）。例えば、１つの変形例では、両ルートが混雑に対して評価される（混雑は、ＰＳドメインでは後で到着するパケットのようなパケット搬送に関連した待ち時間、又はＣＳドメインでは端−端回路を確立するときの長い遅延で指示される）。或いは又、評価は、ハイアラーキー解決策を使用することを含んでもよく、例えば、混雑についてＰＳドメインのみを評価し、満足であれば、ＰＳドメインを使用し、さもなければ、ＣＳドメインを使用してもよい。又、２つ以上の評価基準、例えば、混雑／待ち時間、信頼性、利用可能なデータ能力／ペイロード、等を使用してもよい。当業者であれば、本開示が与えられれば、多数の異なる評価スキーム及び基準が認識されよう。
【００８４】
ステップ２５８では、ステップ２５６の前記評価に基づいて２つのルートの一方が選択され（又はコールのプライオリティ及び潜在的信頼性／待ち時間の問題によっては両方が選択され）、そしてステップ２６０では、その選択されたドメインを経てコールがルーティングされる。
【００８５】
図２及び２Ａの上述した例示的な方法は、先に述べたデータ送信のための既存の解決策（即ち、ショートメッセージサービス（ＳＭＳ）；ユーザ対ユーザシグナリング（ＵＵＳ）；非構造化補足サービスデータ（ＵＳＳＤ）；移動通信用のグローバルシステム（ＧＳＭ）ＣＳデータ；デュアルトーンマルチ周波数（ＤＴＭＦ）；及びインバンドモデム／シグナリングアプリケーション）に勝る本発明の多数の効果を強調するものである。より詳細には、ＳＭＳは、セルラーネットワークを通してあるターミナルから別のターミナルへの１４０バイトメッセージの低信頼性転送を使用するものである。ＳＭＳメッセージは、ネットワークリソースの良好な管理を容易にするために記憶及び転送システムを使用するネットワークにおいて処理されるが、ＳＭＳの１つの主たる欠点は、ショートメッセージはユーザのホームネットワークのＳＭＳセンターへルーティングされるが、ｅＣａｌｌは、好ましくは、（加入者がローミングできるように）訪問先ネットワーク内で処理されねばならないことである。ｅＣａｌｌを現在開始するローミングユーザは、それらのＳＭＳを、転送の前に、記憶のためにそのホームネットワークへルーティングさせる。ＳＭＳルーティングの間接的な取り扱いは、他のｅＣａｌｌメカニズムとの統合のために著しい変更を必要とする。ＳＭＳの別の欠点は、それが比較的信頼性の低いサービスで、ＳＭＳは、配信の保証もしないし、配信時間の指定もせず、又、受信者から送信者へのフィードバックは任意であって、適時でもなく、信頼性もないことである。更に、ＳＭＳは、認証のために移動装置内に存在する加入者アイデンティティモジュール（ＳＩＭ）に依存する。これらの欠点は、各々、ここに開示する技術によって好都合に克服される。
【００８６】
同様に、ＵＵＳは、コール設定中又はその直後のデータの小部分のユーザ対ユーザシグナリングを許す別のサービスである。ＵＵＳは、転送されるデータの量を制限する。あるＵＵＳタイプでは、ＭＳＤを、非常に限定的な３２バイトに減少する必要がある。更に、オペレータは、ＵＵＳを広範囲に配備しておらず、現在のネットワーク装置をアップグレードすることは、経費がかかり、困難である。ＵＵＳは、コール制御プロトコルの一部分として具現化されるサービスであり、サービス総合デジタル網（ＩＳＤＮ）のような固定線プロトコル又はＣＳドメインでしか利用できない。これは、ＰＳドメインでは、現在利用できず、そして現在ネットワークオペレータは、非常コールに対してＵＵＳを明らかに許さない。
【００８７】
ＵＳＳＤは、ＵＵＳと同様の規格であり、幾つかの同様の特徴を有する。ＵＳＳＤは、１８０バイト以上の情報の送信を許す。ＵＳＳＤは、進行中のコールを補足するために独立して又はいつでも動作することができる。ＵＵＳ及びＳＭＳと非常に良く似ていて、ＵＳＳＤ送信は、ホームネットワークへルーティングされ、従って、ローミング中のｅＣａｌｌの取り扱いに対するＵＳＳＤの変更は、ｅＣａｌｌを訪問先ネットワークへリルートしなければならない。ＵＳＳＤは、ＵＵＳと同様に、非常コールに使用するのは現在禁止されている。又、ＵＳＳＤは、ＣＳドメインプロトコルの一部分としても実施され、セルラーネットワークのＣＳドメインコールにしか利用されない（ＰＳドメインには使用されない）。
【００８８】
ｅＣａｌｌ動作に適さない他のレガシー回路交換データ送信技術は、ＧＳＭ  ＣＳデータ、及びデュアルトーンマルチ周波数（ＤＴＭＦ）を含む。ＧＳＭ  ＣＳデータは、ＣＳドメインにおいて９．６ｋｂｐｓデータ転送レートで動作することができる。不都合なことに、ＧＳＭ  ＣＳデータの設定時間は、ｅＣａｌｌサービスの要求を越え、そしてＧＳＭ  ＣＳデータは、ＣＳドメイン内でしか動作できない（ＧＳＭは、ＣＳベースのネットワークである）。ＤＴＭＦは、ＭＳＤを非常にゆっくりと運搬するのに便利に使用できるが、１８０バイトを送信するのに３６秒以上を要する。更に、ＤＴＭＦは、信頼性がなく、エラー修正を与えない。
【００８９】
インバンドモデムシグナリングは、現在使用される方法であり、米国内で使用されるＯｎＳｔａｒTRシステムにおいてある程度の商業的な成功を収めている。ＭＳＤは、設定ボイス接続を使用してコールの始めにインバンドで送信される。従って、ルーティング及びアドレッシングは、ネットワークの問題ではなく、ＭＳＤは、公共安全応答点（ＰＳＡＰ）により常に受け取られる。不都合にも、ボイスストリームからＭＳＤデータをデコードするために、ＩＶＳターミナル及びＰＳＡＰの両方によりある程度の努力が払われねばならない。加えて、あるネットワークでは、ＩＶＳとＰＳＡＰとの間のサポートされるボイスコーデックの潜在的な不一致のために、ボイスデータをあるボイスコーデックから別のボイスコーデックへトランスコード化しなければならない。このトランスコード化プロセスは、ｅＣａｌｌ  ＭＳＤデータ部分にエラーを導入することがあり、或いはトランスコード化でボイスストリーム内に埋め込まれる未確認のデータ送信アーティファクトを生じる場合には完全にフェイルすることもある。
【００９０】
以上の説明に基づき、レガシー及び従来の解決策に勝るここに開示する技術の多数の効果が容易に明らかである。
【００９１】
１つの例示的な具現化において、本発明は、送信されるべきデータ（例えば、最小セットのデータ（ＭＳＤ））を、ｅＣａｌｌボイス接続内で送信されるＲＴＰ制御プロトコル（ＲＴＣＰ）パケットへと入れることを意図する。ＲＴＣＰパケットのタイミング及び周波数は、特に、参考としてここにそのまま援用する“RTP, Audio and Video for the Internet”Colin Perkins; Addison-Wesley、２００３年、ＩＳＢＮ  ０−６７２−３２２４９−８、及び先に述べたＲＦＣ３５５０に説明されている。
【００９２】
ほとんどのＲＴＰ具現化は、ある程度の僅かなオーバーヘッドしか要求しない。より詳細には、送信者がリアルタイムで効率良く送信するために、受信器の受信クオリティに関するある情報を使用することができる。加えて、受信者は、セッションの他の参加者に関する情報を必要とし、このような情報は、例えば、他の参加者が送信者であるか、受信者であるか、又はその両方であるかに関する詳細を含む。又、制御データは、周期的に通信され、それに関連するＲＴＰ制御プロトコル（ＲＴＣＰ）は、この付加的な制御情報を、ＲＴＰ埋設ユーザデータパケットのストリーム内の埋設データとしてどのように及びいつ注入するか定義し規定する。従って、ＲＴＣＰは、他の代替え手段と比較したときに、パケットの数及び送信データ量を増加する。しかしながら、ＲＴＣＰシグナリングは、通常、リアルタイムストリームの全データ帯域巾の５％未満しか消費しない。
【００９３】
ＩＶＳとＰＳＡＰとの間で１２．８ｋｂｐｓで動作する両方向性ボイス接続では、ＲＴＣＰパケットがほぼ毎秒一度送信されることが予想される。接続の開始部では、このインターバルの半分（０．５秒）の後に最初のＲＴＣＰパケットが送信される。
【００９４】
ＲＴＣＰは、（１）受信者レポート；（２）送信者レポート；（３）ソース記述；（４）メンバーシップマネージメント；及び（５）アプリケーション定義（ＡＰＰ）パケットタイプ、を含む５つのパケットタイプを定義する。最初の４つのパケットタイプは、定義された構造を有し、パケット構造の拡張を許さないが、ＡＰＰパケットタイプは、特定アプリケーション情報を受け容れるように柔軟に定義される。従って、本発明の１つの例示的な実施形態では、ＲＴＣＰ  ＡＰＰパケットタイプを使用して、インビヒクルシステム（ＩＶＳ）から公共安全応答点（ＰＳＡＰ）へＭＳＤを搬送する。
【００９５】
図３を参照すれば、従来のＲＴＰ  ＡＰＰパケット３００フォーマットは、多数の情報エレメントより成る。より詳細には、第１の情報エレメント３０２は、プロトコルのバージョン［Ｖ］を識別し、ＲＴＰ及びＲＴＣＰプロトコルの現在バージョンにおいて、この値は、典型的に、２（バイナリーでは１０＃ｂとして表される）にセットされる。第２の情報エレメント３０４は、パッディングビット［Ｐ］であり、これは、この個々のＲＴＣＰパケットが、制御情報の一部分ではないが長さフィールドに含まれる幾つかの付加的なパッディングオクテットを終了時に含むかどうか識別する。パッディングの最後のオクテットは、どれほど多くのパッディングオクテットを無視しなければならないかのカウントである。例えば、ＲＴＰ  ＡＰＰパケット３００が８オクテットである場合には、最後のオクテットは、ビット５６ないし６３を含む。別の例では、長さが１２オクテットである場合には、最後のオクテットは、ビット８８ないし９５を含む。
【００９６】
第３の情報エレメント３０６は、ＡＰＰパケットのセットを１つの独特の名前のもとで又はアプリケーション依存データに対して定義できるようにするサブタイプとして使用されるｓｕｂｔｙｐｅ［ｓｕｂｔｙｐｅ］である。
【００９７】
第４の情報エレメント３０８は、この例では値［２０４］（バイナリーでは１１００１１００＃ｂとして表される）で表されたＲＴＣＰ  ＡＰＰパケットを指示するパケットタイプ［ＰＴ］である。
【００９８】
第５の情報エレメント３１０は、３２ビットワードのＲＴＣＰパケット−１の長さフィールド［ｌｅｎｇｔｈ］であり、これは、ヘッダ及びパッディングを含む。
【００９９】
第６の情報エレメント３１２は、同じ個人により定義され及び／又は同じ目的で使用されるＲＴＣＰ  ＡＰＰパケットのセットを定義する名前フィールド［ｎａｍｅ］である。
【０１００】
第７の情報フィールド３１４は、アプリケーションによって使用される（即ち、ＲＴＣＰ  ＡＰＰ処理では使用されない）オープンエンドフィールドであるアプリケーション依存データ［ａｐｐｌｉｃａｔｉｏｎ−ｄｅｐｅｎｄａｎｔ  ｄａｔａ］である。アプリケーション依存データ長さの１つの特定の要求は、３２ビットワード境界に正しく適合するように３２ビットの倍数であることである。
【０１０１】
図３Ａ−Ｄを参照すれば、本発明によりｅＣａｌｌデータを埋め込むのに使用される例示的なＲＴＰ  ＡＰＰパケット３５０フォーマットの種々の実施形態が示されている。図３の従来パケットと同様に、第１の情報エレメント３５２は、プロトコルのバージョン［Ｖ］を識別し、ＲＴＰ及びＲＴＣＰプロトコルの現在バージョンでは、この値は、典型的に、２（バイナリーでは１０＃ｂとして表される）にセットされる。
【０１０２】
同様に、第２の情報エレメント３５４は、パッディングビット［Ｐ］であり、これは、この個々のＲＴＣＰパケットが、制御情報の一部分ではないが長さフィールドに含まれる幾つかの付加的なパッディングオクテットを終了時に含むかどうか識別する。
【０１０３】
第３のエレメントは、サブタイプフィールド（以下に詳細に述べる）である。
【０１０４】
第４の情報エレメント３５８は、この例では値［２０４］（バイナリーでは１１００１１００＃ｂとして表される）で表されたＲＴＣＰ  ＡＰＰパケットを指示するパケットタイプ［ＰＴ］である。
【０１０５】
第５の情報エレメント３６０は、３２ビットワードのＲＴＣＰパケット−１の長さフィールド［ｌｅｎｇｔｈ］であり、これは、ヘッダ及びパッディングを含む。
【０１０６】
図３Ａ及び図３Ｂは、ＲＴＣＰ  ＡＰＰパケットタイプの例示的実施形態を示す。既存のＲＴＣＰ  ＡＰＰパケットフォーマット３５０を最適に使用するために、全てのｅＣａｌｌ定義パケットは、共通ストリング値（例えば、“ｅＣａｌ”）を名前フィールド３６２（図３Ａ）内に維持する。更に、ｅＣａｌｌサービスに対して定義されたサブタイプフィールド３５６の値は、最小セットのデータ（ＭＳＤ）、フルセットのデータ（ＦＳＤ）、等の異なるデータタイプを区別することができる。或いは又、他の具現化では、名前フィールド３６２において、ｅＣａｌｌ特有であるパケット、及びパケットに収容されるデータのタイプの両方を指示することができる。サブタイプフィールド３５６は、次いで、例えば、ＭＳＤ又はＦＳＤの最初の５ビットのように他の目的に使用することができる（図３Ｂに示すように）。
【０１０７】
ＲＴＰ及びＲＴＣＰは、ここに示す実施形態では、ＵＤＰ搬送プロトコルを経て送信され、これは、上述したように、（ＴＣＰとは異なり）送られたパケットが正しく受け取られることについて送信者を保証するものではない。ある状況において、（ｉ）パケットがそのまま適時に受け取られたか、又は（ii）失敗モードにあるか（例えば、パケットが崩壊され、遅れ又は紛失されたか）という確認（ＡＣＫ）を受信者により与えることが望まれる。１つの例示的な実施形態では、ＲＴＣＰ  ＡＰＰパケットは、受信者による首尾よい受け取りを確認するのに使用される。いずれのＲＴＣＰ  ＡＰＰパケットでも（図３Ａ−Ｄに示すように）、ＲＴＣＰフォーマットは、サブタイプフィールド値３５６又は適当な名前フィールド値３６２を定義することにより確認を容易に運搬する。
【０１０８】
図３Ｃ及び図３Ｄを参照すれば、更に別の実施形態において、ｅＣａｌｌデータの受信者（例えば、ＰＳＡＰ）は、２つ以上のメッセージが送信者（例えば、ＩＶＳ）によって送信された場合に特定のｅＣａｌｌデータメッセージを確認することができる。従って、サブタイプフィールド３５６のパケット番号と、そのパケット番号を適当な確認メッセージに相関させるリファレンスとを追加することで、適切な順序正しい受け取り及び複数メッセージの区別を行うことができる。パケット番号の搬送は、例えば、ｅＣａｌｌデータパケット又はそれに対応する確認パケットのいずれかに対して図３Ｃに示すサブタイプフィールド３５６を経て達成することができる。或いは又、図３Ｄに示す特定アプリケーションデータフィールド３６４にパケット番号を含ませることができる。
【０１０９】
付加的な実施形態では、ＰＳＡＰは、ＩＶＳからのｅＣａｌｌデータの更新を要求する能力を所有している。更新メッセージは、確認パケットと同様のフォーマット（又はＰＳＡＰからＩＶＳへの送信に適応される任意のパケットフォーマット）で構成することができる。又、更新要求は、更新されるべき情報を特定する指示も含み、このような更新は、例えば、特定の動的条件をポーリングするのに使用される。１つのこのような変形例では、オーバーヘッドを減少するために、要求された情報（或いは最後の更新以来変更された情報）のみが送信される。更に、この情報は、特定アプリケーションデータフィールド３６４又は必要に応じて他の位置内にカプセル化されてもよい。
【０１１０】
更に別の具現化では、ｅＣａｌｌデータの特定部分に対する高速送信要求は、データの１４０バイトを、第１のＲＴＣＰパケットで送信される第１部分と、この第１部分とは個別の１つ以上のＲＴＣＰパケットで送信される第２部分とに分割することにより受け容れることができる。第１及び第２のデータ長さを組み合わせて使用することができる。このような１つの例では、第１パケットは、一緒になっても３８バイト以下であるＭＳＤの最初の５つの情報エレメントを含むことができ、そして第２の部分は、１０６バイトサイズまでの残りの部分を含むことができる。より小さな第１パケットは、非常に素早く送信され、そして第２の残りのパケットは、ＩＶＳによりスケジュールされる次のＲＴＣＰ送信において送信される。
【０１１１】
更に、先に述べた実施形態に加えて、２つ以上のｅＣａｌｌメカニズムをサポートするセルラー移動ネットワークは、どのｅＣａｌｌメカニズムを使用すべきかを指示するための種々のメッセージフォーマットもサポートする。このような指示は、特定のｅＣａｌｌセッションに対してどのメカニズムが適用できるか識別するために、コール確立中に生じる。
【０１１２】
或いは又、コール設定中にメカニズムのネゴシエーションを行うこともできる。セッション情報を記述しそして初期化するのに使用される１つの普及したプロトコルは、良く知られたセッションイニシエーションプロトコル（ＳＩＰ）である。ＩＰベースのマルチメディアコアネットワークサブシステム（ＩＭＳ）は、ＳＩＰに基づくネットワークアーキテクチャーであり、ＩＭＳは、移動セルラーネットワークにおけるセッション確立、操作及び終了の方法を定義する。より詳細には、ＰＳドメインコールは、典型的に、実際のデータを転送する前にＳＩＰを使用してＩＭＳフレームワーク内でネゴシエーションされ、設定される。特に、参考としてここにそのまま援用する“Technical Specification  3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; IP Multimedia Subsystem (IMS); Stage 2 (Release 8)”と題する３ＧＰＰ  ＴＳ２３．２２８  Ｖ８．６．０（２００８−０９）を参照されたい。ＳＩＰ内で、所与のセッションに関連したパラメータを定義するために、セッション記述プロトコル（ＳＤＰ）が使用される。
【０１１３】
ＳＩＰフレームワーク内で、どのｅＣａｌｌデータシグナリングメカニズムが使用されるか指示するために、セッション記述に“ａ−ｌｉｎｅ”（属性ライン）を追加することができる。例えば、利用可能な２つのサポートされるフォーマット（例えば、ＲＴＣＰに対するインバンドシグナリング、及びボイスコーデック）があるシステムでは、２つの個別のストリームタイプを適当なａ−ｌｉｎｅ記述子で表すことができる。
ａ＝ｅＣａｌｌＤａｔａＴｘＭｅｃｈａｎｉｓｍ：ＩｎＢａｎｄＲＴＣＰ
ａ＝ｅＣａｌｌＤａｔａＴｘＭｅｃｈａｎｉｓｍ：ＩｎＢａｎｄＶＣｏｄｅｃ
適当な応答が、例えば、ネットワーク内に存在する選択ロジックに基づいて２つのストリームオプションの一方を選択する。この選択は、例えば、発呼装置の固有の能力、ネットワーク最適化又は動作基準、待ち時間、等に基づいて行われる。
【０１１４】
しかしながら、ＳＩＰの特定の状況において、一次ＳＩＰ  ＲＦＣ（ＲＦＣ  ３２６１）は、リソースプライオリティ決めをサポートしないが、コールプライオリティ決めに関してＳＩＰの能力を拡張するように設計された補足的ＲＦＣ（参考としてここにそのまま援用する２００６年２月付けの“Communications Resource Priority for the Session Initiation Protocol (SIP)”と題するＲＦＣ４４１２）があることに注意されたい。より詳細には、ＲＦＣ４４１２は、コールが下流のエレメントにより「高いプライオリティ」として処理されることを装置が要求できるようにする２つの新規のＳＩＰヘッダフィールドを定義する。
【０１１５】
実施例
以下の実施例は、ボイス及びインバンドシグナリングデータの両ストリームを使用してｅＣａｌｌを開始及び処理するのに使用される上述したＲＴＣＰ  ＡＰＰプロトコルのパケット構造及びメッセージフォーマットの１つの例示的な具現化を更に例示する。
【０１１６】
一実施形態によれば、パケット交換コールを開始するために、インビヒクルシステム（ＩＶＳ）は、ベースステーションとの通信を確立する。あるマルチモードシステムでは、ＩＶＳは、それ自身をパケット交換装置として識別することが要求される（例えば、ＣＳ及びＰＳの両ネットワークが重畳するか、又は両能力が利用できる場合に）。ベースステーションは、専用の物理的トラフィックリソース（例えば、タイムスロット、周波数帯域、コードドメイン、等）、及び論理的チャンネルをＩＶＳに与える。論理的チャンネルの指定により、ＩＶＳは、論理的チャンネルを経てＩＰベースのマルチメディアコアネットワークサブシステム（ＩＭＳ）と通信することができ、そのチャンネルは、指定の専用の物理的トラフィックリソースにおいて送信される。
【０１１７】
ＩＶＳは、セッションイニシエーションプロトコル（ＳＩＰ）を使用してＰＳＡＰとのコールを開始する。図４に示すタイプのメッセージ交換は、確立されたセッションを経てボイス又はｅＣａｌｌデータを交換できる前に行わねばならない。図４に示すメッセージングでは、明瞭化のために、ＳＩＰメッセージの全てのコンテンツが詳細に示されていない。
【０１１８】
図４の例示的な交換に示すように、ＩＶＳは、ＩＰパケットでカプセル化された初期ＳＩＰ  ＩＮＶＩＴＥ要求４０２をそれに関連したＩＰ及びＵＤＰヘッダと共に送信する。ＳＩＰ  ＩＮＶＩＴＥ要求は、コールされるターミナル（例えば、ＰＳＡＰ）の行先アドレスを含み、そしてそのコールされたターミナルがコールセッション（例えば、ｅＣａｌｌ）に参加するように招待されることを指示する。又、図４は、上述したＳＩＰ  ＩＮＶＩＴＥメッセージのセッション記述内に使用される慣習的“ａ−ｌｉｎｅ”も示す。図４の例示的なＳＩＰ  ＩＮＶＩＴＥは、本発明の原理により、非常関連データを送信するための上述したａ−ｌｉｎｅの両方をインバンドボイスコーデックシグナリング又はインバンドＲＴＣＰとして含む。
【０１１９】
典型的に、ベースステーションは、アクセス制御、許可及びアカウンティングのために種々のネットワークエンティティにＩＮＶＩＴＥ要求を送信する。ｅＣａｌｌ状況では、ネットワークエンティティは、アクセス、許可及びアカウンティング段階の幾つか又は全部を選択的にスキップ又は無効にする。この選択は、コールのタイプ又はプライオリティに基づいて動的に変化してもよく、例えば、「非常」コールは、上述した全ての段階をスキップしてもよく、一方、プライオリティは高いが非常ではないコールは、それら段階の幾つかを使用して、特定の目標を達成してもよい（例えば、高プライオリティの相互法律執行送信は、「スプーフィング」又は同様の攻撃が生じないように保証するために認証を利用してもよい）。
【０１２０】
ＳＩＰ  ＲＩＮＧＩＮＧ応答４０３は、ＰＳＡＰがＩＮＶＩＴＥ要求を探索して受信すると、そこから任意に返送される。
【０１２１】
ｅＣａｌｌがＰＳＡＰによって受け容れられると、ＳＩＰ  ２００  ＯＫ応答４０４を返送する。２００  ＯＫ応答４０４を受信すると、ＩＶＳは、ＯＫ応答を確認するためにＳＩＰ  ＡＣＫメッセージ４０６を送信する。２００  ＯＫ４０４は、ＰＳＡＰが選択した２つのオプションからの選択を含む。図示されたように、ＰＳＡＰは、ＲＴＣＰシグナリングを選択している。この点において、コールが設定され、散在したボイス及び他のリアルタイムデータの通信を進めることができる。
【０１２２】
ＭＳＤデータの送信
図５を参照すれば、セッション設定が完了した（例えば、図４のＳＩＰ交換が、ボイス及びデータ成分を有するセッションを首尾良く裁定した）後に、ＩＶＳとＰＳＡＰとの間の例示的なメッセージングフロー５００が遂行される。ボイスデータの交換は、５０２ａ、５０２ｂにおいてコード化ボイスフレームを含むＲＴＰパケットを送信することによりスタートされる。スケジュールされた時間（Ｔ1）の後に、ステップ５０４において第１のＲＴＣＰパケットが送信される。このパケットは、一実施形態では、図３Ａ−３Ｄを参照して上述したＲＴＣＰ  ＡＰＰパケット３５０を含む。
【０１２３】
本発明の１つの例示的実施形態では、ステップ５０４において送信される第１のＲＴＣＰ  ＡＰＰ（２）パケットには次の情報エレメントがセットされる。（ｉ）Ｎａｍｅ３６２＝ｅＣａｌ、（ii）Ｓｕｂｔｙｐｅ３５６＝ＭＳＤデータ、及び（iii）ＰａｃｋｅｔＮｕｍｂｅｒ（特定アプリケーションフィールド３６４の最初の８ビット）＝０（ゼロ）。特定アプリケーションフィールド３６４の残りは、残りのＭＳＤを含む。
【０１２４】
第１のＲＴＣＰ  ＡＰＰ（２）パケットが発生された後、更に別のＲＴＣＰパケットがその後のインターバルで発生される。これらインターバルは、１つの具現化では、周期的な性質であるが、パケットが必ずそうであるという特定の要件はない。時間（Ｔ2）の規則的なインターバルを使用すると、ＩＶＳとＰＳＡＰとの間のＲＴＣＰパケットの処理が簡単になる。周期的なＲＴＣＰパケット送信の間に、ステップ５０２ｃ、５０２ｄ、５０２ｅ、等に示すように、ＲＴＰボイスパケットを送信し続けることができる。
【０１２５】
ここに例示する実施形態では、発生されるＲＴＣＰパケットは、ＰＳＡＰから首尾良い受信の確認が受け取られる時点まで、ｅＣａｌｌデータのためのＡＰＰパケットを含む。図５に示すように、ＰＳＡＰは、ステップ５０４において第１のＲＴＣＰ  ＡＰＰ（２）パケットを受け取り、ＰＳＡＰは、第１のＲＴＣＰ  ＡＰＰ（２）パケットの受信に応答して、ステップ５０６において、ＲＴＣＰ  ＡＰＰ（３）パケットを発生して、首尾良い受信を確認する。このＲＴＣＰ  ＡＰＰ（３）パケット（ＡＣＫ）は、次のような本発明の情報エレメントセットと共に送信され、即ち、Ｎａｍｅ３６２＝“ｅＣａｌ”；Ｓｕｂｔｙｐｅ３５６＝ＡＣＫ；ＰａｃｋｅｔＮｕｍｂｅｒ（特定アプリケーションフィールド３６４の最初の８ビット）＝パケット０を確認するための０（ゼロ）；特定アプリケーションフィールドの残りは、空である。
【０１２６】
図５の仮説的実施例では、ステップ５０６において送信されるＡＣＫ（３）は、エアインターフェイスにおける故障又は干渉（ステップ５０６の“Ｘ”を参照）のために失われる。ＩＶＳは、その後の確認を予想し、従って、ＩＶＳは、確認が正しく及び／又は適時に受け取られなかったことを検出する。それ故、予めスケジュールされた時間（Ｔ2）の後に、ステップ５０８において第２のＲＴＣＰ  ＡＰＰ（４）パケットが送信され、これは、次のような情報エレメントより成り、即ち、Ｎａｍｅ３６２＝“ｅＣａｌ”；(2)Ｓｕｂｔｙｐｅ３５６＝ＭＳＤデータ；ＰａｃｋｅｔＮｕｍｂｅｒ（特定アプリケーションフィールド３６４の最初の８ビット）＝“１”；特定アプリケーションフィールドの残りは、ＭＳＤを含む。このパケットは、次のものを含むＲＴＣＰ  ＡＰＰパケット（５）と共にステップ５１０においてＰＳＡＰにより受け取られて確認され、即ち、Ｎａｍｅ３６２＝“ｅＣａｌ”；Ｓｕｂｔｙｐｅ３５６＝ＡＣＫ；ＰａｃｋｅｔＮｕｍｂｅｒ（特定アプリケーションフィールド３６４の最初の８ビット）＝パケット１を確認するための“１”；特定アプリケーションフィールドは、空のままである。ＩＶＳによる確認の首尾良い受信の後に、ｅＣａｌｌデータの送信が停止され、ボイスパケットは、ステップ５０２ｅにおいて交換され続ける。
【０１２７】
要求された更新手順
又、図５には、任意の更新要求手順も示されている。特に、ステップ５１２において、ＰＳＡＰは、ＭＳＤの更新を要求し、ある状況において、ＰＳＡＰは、ＭＳＤの情報が動的に変化するために更新を要求する。従って、ステップ５１２においてＲＴＣＰ  ＡＰＰ（６）パケットが送信され、これは、次のような情報エレメントより成る。即ち、Ｎａｍｅ３６２＝“ｅＣａｌ”；Ｓｕｂｔｙｐｅ３５６＝ＵＰＤＴ；ＰａｃｋｅｔＮｕｍｂｅｒ（特定アプリケーションフィールド３６４の最初の８ビット）。特定アプリケーションフィールドの残りは、空のままである。
【０１２８】
ＩＶＳは、次のフィールドエントリを含む更新されたＲＴＣＰ  ＡＰＰパケット（７）と共にステップ５１４において要求に応答する。即ち、Ｎａｍｅ３６２＝“ｅＣａｌ”；Ｓｕｂｔｙｐｅ３５６＝ＭＳＤデータ；ＰａｃｋｅｔＮｕｍｂｅｒ＝２。特定アプリケーションフィールドの残りは、更新されたＭＳＤを含む。
【０１２９】
別の実施形態において、ステップ５１２で送信される更新要求ＲＴＣＰ  ＡＰＰパケット（６）は、ＦＳＤが利用できるかどうか調べるための要求を開始し、もしそうであれば、５１４で送信されるＲＴＣＰ  ＡＰＰパケット（７）は、ＳｕｂｔｙｐｅにおいてＦＳＤデータも指示する（及び特定アプリケーションフィールドにＦＳＤを含む）。又、最も最近計算されたＭＳＤの情報が、最後に送信されたＭＳＤと異なる限り、ＩＶＳは、ステップ５０４及び５０８で送信されたものと同様のＭＳＤパケットを送信し続けるが、他のロジック又は基準を適用してもよいことが意図される（例えば、ｎ個の次々のパケット又はインターバル中に変化なし、等）。
【０１３０】
セグメント化されたパケット
別の具現化において、ｅＣａｌｌデータは、２つ以上のＲＴＣＰパケットへセグメント化することができる。例えば、５０４において送信されるＲＴＣＰパケット（２）の情報エレメントは、次の情報より成る第１パケットが構成されるように変化する。即ち、Ｎａｍｅ３６２＝“ｅＣａｌ”；Ｓｕｂｔｙｐｅ３５６＝ＭＳＤデータ−セグメント化；ＰａｃｋｅｔＮｕｍｂｅｒ＝０（ゼロ）；ＳｅｇｍｅｎｔＮｕｍｂｅｒのフィールド＝０（ゼロ）；特定アプリケーションフィールドの残りは、ＭＳＤの最初の３８バイトを含む。
【０１３１】
その後、ある時間後に、次のものを含む第２のセグメント化されたパケットが発生される。即ち、(1)Ｎａｍｅ３６２＝“ｅＣａｌ”；Ｓｕｂｔｙｐｅ３５６＝ＭＳＤデータ−セグメント化；ＰａｃｋｅｔＮｕｍｂｅｒ＝０（ゼロ）；ＳｅｇｍｅｎｔＮｕｍｂｅｒ＝１；特定アプリケーションフィールドの残りは、ＭＳＤの残り部分を含む。ステップ５０６において、ＰＳＡＰに両セグメントが受け取られた後にのみ、確認メッセージが完全なパケット０（即ち、両セグメント）を確認する。ＡＣＫは、パケット及び／又はセグメントが確認されることを特定しなければならない。従って、１つの変形例では、ＡＣＫは、パケット番号及びセグメント番号の両方を含む。ＩＶＳにより確認が受け取られない場合には、ＩＶＳが新たなＭＳＤ（両セグメントを含む）を発生する。
【０１３２】
例示的なネットワーク装置
図６ａを参照すれば、本発明の方法を具現化するのに有用な例示的なネットワーク装置（例えば、公共安全応答点（ＰＳＡＰ）サブシステム）６００が示されている。
【０１３３】
装置６００のここに示す実施形態は、中央データベース６０４に接続された１つ以上のサーバーユニットであって、プロセッサ６０６、動作メモリ６０８、電源６１０及び外部ネットワークインターフェイス６１２で構成されたサーバーユニットを備えている。ここで使用する「ネットワークインターフェイス」又は「インターフェイス」という語は、典型的に、コンポーネント、ネットワーク又はプロセスを伴う信号、データ又はソフトウェアインターフェイスを指し、それらは、ＦｉｒｅＷｉｒｅ（例えば、ＦＷ４００、ＦＷ８００、等）、ＵＳＢ（例えば、ＵＳＢ２）、イーサネット（登録商標）（例えば、１０／１００，１０／１００／１０００（ギガビットイーサネット）、１０−Ｇｉｇ−Ｅ、等）、ＭｏＣＡ、シリアルＡＴＡ（例えば、ＳＡＴＡ、ｅ−ＳＡＴＡ、ＳＡＴＡII）、ウルトラ−ＡＴＡ／ＤＭＡ、Ｃｏａｘｓｙｓ（例えば、ＴＶｎｅｔTM）、高周波数チューナ（例えば、インバンド又はＯＯＢ、ケーブルモデム、等）、ＷｉＦｉ（８０２．１１ａ、ｂ、ｇ、ｎ）、ＷｉＭＡＸ（８０２．１６）、ＰＡＮ（８０２．１５）、ＩｒＤＡ、又は他のワイヤレスファミリーを含むが、これらに限定されない。
【０１３４】
図６ａのサーバーユニットは、１つの構成では、外部バス６１４により接続される。
【０１３５】
図示されたように、中央データベース６０４は、多数の個々のマシン間で分割されるが、１つの論理的にコヒレントなデータベースとして機能する。中央データベースは、独特な識別子のリストを含み、それに対応する現在及び履歴データ（例えば、最小セットのデータ又はＭＳＤ）は、コンピュータ読み取り可能な媒体（例えば、ハードディスクドライブ／ＲＡＩＤアレイ、フラッシュメモリ、等）に記憶されている。
【０１３６】
プロセッササブシステム６０６は、マイクロプロセッサ（ＣＰＵ）、デジタル信号プロセッサ、ＲＩＳＣコア、フィールドプログラマブルゲートアレイ、及び／又は複数の処理コンポーネントを備えている。ここで使用する「マイクロプロセッサ」及び「デジタルプロセッサ」という語は、一般的に、これに限定されないが、デジタル信号プロセッサ（ＤＳＰ）、縮小命令セットコンピュータ（ＲＩＳＣ）、汎用（ＣＩＳＣ）プロセッサ、マイクロプロセッサ、ゲートアレイ（例えば、ＦＰＧＡ）、ＰＬＤ、再構成可能なコンピュータファブリック（ＲＣＦ）、アレイプロセッサ、セキュアなマイクロプロセッサ、及び特定用途向け集積回路（ＡＳＩＣ）を含む全ての形式のデジタル処理装置を包含することを意味する。このようなデジタルプロセッサは、単一の一体的ＩＣダイに収容されてもよいし、又は複数のコンポーネントにわたって分散されてもよい。
【０１３７】
又、処理サブシステムは、内部キャッシュメモリ６０６Ａも備えている。処理サブシステムは、論理的中央データベース６０４、ローカルメモリサブシステム６０８、及び外部ネットワークインターフェイス６１２に接続され、これは、例えば、ネットワーキング又はデータバスプロトコルを経て他のローカルまたはリモートエンティティと通信する。
【０１３８】
メモリサブシステム６０８は、例えば、不揮発性コンポーネント（例えば、ＲＯＭ、フラッシュ、等）及び揮発性コンポーネント（例えば、ＲＡＭ、ＤＤＲ−ＲＡＭ、ＱＤＲ−ＲＡＭ、等）を含む１つ以上のメモリコンポーネントを備えている。「メモリ」という語は、デジタルデータを記憶するための任意の形式の集積回路又は他の記憶装置を包含するもので、ＲＯＭ、ＰＲＯＭ、ＥＥＰＲＯＭ、ＤＲＡＭ、ＳＤＲＡＭ、ＤＤＲ／２  ＳＤＲＡＭ、ＥＤＯ／ＦＰＭＳ、ＲＬＤＲＡＭ、ＳＲＡＭ、「フラッシュ」メモリ（例えば、ＮＡＮＤ／ＮＯＲ）、及びＰＳＲＡＭを含むが、これらに限定されないことが明らかであろう。又、メモリサブシステムは、コンピュータ分野で良く知られた形式のＤＭＡタイプハードウェア６０８Ａも備え、高速データアクセスを促進することができる。
【０１３９】
ここに示す電源管理サブシステム（ＰＭＳ）６１０は、サーバーユニットに電力を供給するもので、集積回路及び／又は複数の個別電気コンポーネントを備えている。又、ここで使用する「集積回路（ＩＣ）」という語は、プロセス又は基礎材料（これに限定されないが、Ｓｉ、ＳｉＧｅ、ＣＭＯＳ及びＧａＡｓを含む）に関わらず、任意の集積レベル（これに限定されないが、ＵＬＳＩ、ＶＬＳＩ及びＬＳＩ）を含む）を有する任意の形式の装置を指す。ＩＣは、例えば、メモリ装置（例えば、ＤＲＡＭ、ＳＲＡＭ、ＤＤＲＡＭ、ＥＥＰＲＯＭ／フラッシュ、及びＲＯＭ）、デジタルプロセッサ、ＳｏＣ装置、ＦＰＧＡ、ＡＳＩＣ、ＡＤＣ、ＤＡＣ、トランシーバ、メモリコントローラ、及び他の装置、並びにその組み合わせを含む。
【０１４０】
装置を中断なく利用できるようにするという目的を果たすため、必要に応じて、バックアップのために、フェイルオーバー又は冗長システム（図示されていない無停電電源又はＵＰＳを含む）を使用することもできる。
【０１４１】
又、ここに示す装置は、非常状態に関する情報を、ネットワーク全体を横切って、及び必要に応じて他の形式のネットワークへ容易に伝播できるように、他の装置（例えば、ネットワークオペレータの他の非常業務装置、ネットワークブリッジ、ゲートウェイ、等）と直接的又は間接的にデータ通信させることもできる。
【０１４２】
例示的なＩＶＳ装置
図６Ｂを参照し、本発明による例示的なクライアント装置６５０について説明する。ここに示す実施形態では、クライアント装置は、インビヒクルシステム（ＩＶＳ）６５０を含むが、他の形式の装置を同じ成功性で使用できることが明らかであろう。
【０１４３】
ここに示すＩＶＳ装置６５０は、特に、ハウジングと、セルラーネットワークを経て少なくともデータを送信及び受信することのできる無線部６５２と、乗物の乗員からのボイス通信を受信すると共に、下流又は逆方向通信を再生するためのマイクロホン及びスピーカアッセンブリ６５４と、乗物状態に関するデータを収集するための１つ以上のセンサ６５６と、無線部を経てセルラーネットワークへの接続を開始すると共に、上述した方法及びプロトコルに基づいてボイス及びデータストリームを送信することのできる処理装置６５８とを備えている。
【０１４４】
又、装置６５０は、画像データを収集しそしてそのデータを処理サブシステム６５８へ供給して、パケット化すると共に、上述したボイス送信と同様に別の「リアルタイム」ストリームとしてネットワークを経て送信することのできるビデオ又はカメラサブシステム（図示せず）も備えている。更に、ボイスストリームとビデオストリームは、パケット化データネットワーク分野の当業者に良く知られたＩＴＵ規格Ｈ．３２３又は同様のプロトコルにより整合形態で再生されるように時間的に関係付けることができ、これは、ボイスとビデオの同期を与える。
【０１４５】
上述した制御プロトコル及びボイスデータインターリーブ機能は、必要に応じてクライアント内で色々な程度に遂行される（或いは又、専用装置又は多機能装置がクライアントと通信する）。このような機能は、ここに示す実施形態では、ソフトウェアで遂行されるが、ファームウェア／ハードウェアの実施形態も考えられる。ここで使用する「ソフトウェア」及び「コンピュータプログラム」という語は、機能を遂行する一連のステップ或いは人間又は機械が認識できるステップを含むが、これに限定されない。このようなプログラムは、実質上、例えば、Ｃ／Ｃ＋＋、フォートラン、ＣＯＢＯＬ、ＰＡＳＣＡＬ、アッセンブリ言語、マークアップ言語（例えば、ＨＴＭＬ、ＳＧＭＬ、ＸＭＬ、ＶｏＸＭＬ）、等を含むプログラミング言語又は環境、並びにコモンオブジェクトリクエストブローカーアーキテクチャー（ＣＯＲＢＡ）、ＪａｖａTM（Ｊ２ＭＥ、Ｊａｖａ  Ｂｅａｎｓ、等を含む）、バイナリーランタイムエンビロンメント（ＢＲＥＷ）、等のオブジェクト指向環境においてレンダリングすることができる。
【０１４６】
装置６５０の一実施形態では、乗物状態に関するデータを収集するための１つ以上のセンサは、更に、（ｉ）グローバルポジショニングサービス（ＧＰＳ）受信器６５６Ａと、（ii）衝突及び／又はシャーシ位置を決定するためにシャーシ内に位置された１つ以上の加速度計６５６Ｂと、（iii）乗物の乗員を決定するためのセンサ６５６Ｃとを備えている。ＧＰＳ受信器は、所与の時間における乗物の比較的正確な位置を与え、一方、加速度計は、衝撃又は他の事象（例えば、転覆事故）が生じたかどうか決定する。乗員データを使用して、特に、事故のときに乗物に乗員がいたかどうか決定し（もし乗員がいなければ、プライオリティを変更することができる）、又、乗員の人数も決定する（例えば、適当な数の非常用車両又は修理要員を派遣することができる）。例えば、乗物の種々のコンポーネントの変形を検出するための応力／歪センサ、乗物環境の状態（例えば、水没、火事、等）を検出するための温度及び他の環境センサ、等を含む他のセンサも、必要に応じて使用することができ、これらの付加的なセンサは、出て行くデータ送信に対して入力又はペイロードデータを与えることもできる。
【０１４７】
無線／モデム６５６Ａサブシステムは、デジタル基本帯域、アナログ基本帯域、ＲＸフロントエンド及びＴＸフロントエンドを含む。装置は、更に、アンテナアッセンブリ及びデュープレックスコンポーネントを備え、デュープレックスコンポーネントは、アンテナ動作とアンテナ動作との間を切り換えるための簡単なスイッチを含む。又、このスイッチは、個別コンポーネントを含んでもよい。特定のアーキテクチャーについて説明するが、ある実施形態では、本開示が与えられると、当業者に明らかなように、幾つかのコンポーネントを除去することもできるし、又は互いに合体することもできる（例えば、３ＧデジタルＲＦに使用される形式の、合成されたＲＦ  ＲＸ及びＲＦ  ＴＸ）。
【０１４８】
ユーザインターフェイスシステム６５４は、任意に設けられるもので、これに限定されないが、タッチスクリーン、ＬＣＤディスプレイ、バックライト、等を含む多数の良く知られたＩ／Ｏを含む。ＩＶＳシステムの場合、このシステムは、一般的に、最小限、通信を容易にするために、乗物からボイスストリーム又は他のサウンドサンプルを発生するための手段（即ち、マイクロホン）と、可聴メッセージを合成するための手段（即ち、スピーカ）とを備えることが認められる。又、あるケースでは、Ｉ／Ｏサブシステムは、単に、乗物の乗員が意識を失って話すことができない場合の監視や、ネットワークオペレータ又は法律執行者による受動的な監視（例えば、乗物に「サイレントアラーム」が装備されていて、車が乗っ取られ、拉致され、等のときに乗員がそれをトリガーできる場合）にも使用できることが明らかである。
【０１４９】
この装置のここに示す実施形態は、１つ以上のプロセッサ、例えば、デジタル信号プロセッサ、マイクロプロセッサ／ＣＰＵ、ＲＩＳＣコア、フィールドプログラマブルゲートアレイ、或いは１つ以上の基板に装着された複数の処理コンポーネントを伴うアプリケーションマイクロプロセッササブシステム６５８を備えている。又、処理サブシステムは、内部キャッシュメモリも備えている。処理サブシステムは、例えば、ＳＲＡＭ、フラッシュ及びＳＤＲＡＭコンポーネントを含むメモリを備えたメモリサブシステムとデータ通信する。メモリサブシステムは、この分野で良く知られたように、データアクセスを容易にするために、１つ以上のＤＭＡタイプのハードウェアを具現化する。
【０１５０】
１つの例示的な装置において、ＩＶＳは、（例えば、プログラムメモリに記憶されたアルゴリズムを経て）内部ロジックを使用して、ＰＳＡＰとのｅＣａｌｌを開始する。ｅＣａｌｌが確立されると、ＩＶＳは、乗物全体に分散された前記センサから読み取られたデータと散在された連続的ボイス又は他のペイロードトラフィックを与える。ボイス（又はペイロード）に対する制御及びセンサデータが処理サブシステムにより与えられる。
【０１５１】
１つのこのような実施形態では、ｅＣａｌｌは、衝突を検出する乗物の１つ以上のセンサ６５６により自動的に開始され、加速度計は、既定のスレッシュホールドより高い加速度値（衝突を表す）を検出する。例えば、周囲温度の急速な低下（水没を示す）、乗物の反転（転覆事故）、ボンネットの下又は室内の温度の急速な上昇（おそらくエンジン又は他の火災、或いは非常に暑い日にウインドウを締め切っている窒息状態）、エンジン運転中に乗物が動かない状態（例えば、医療上又は他の症状のために運転者が意識を失ったことを潜在的に示す）、等を含む多数の他のシナリオを使用して、そのようなコールをトリガーすることができる。別の実施形態では、例えば、乗物が牽引支援を必要とする場合に乗物内の１人の乗員によりｅＣａｌｌが開始される。
【０１５２】
無線モデムサブシステムは、セルラーコールを開始し、そしてネットワークメッセージを与える搬送レイヤ、及びリアルタイム通信リンクを確立する。コール取り扱いに対する制御は、無線モデムサブシステム又は処理サブシステムにおいて遂行される。無線モデムサブシステムがセルラーコールを開始するのに応答して、ネットワークエンティティは、上述した優先的で且つ迅速な取り扱い手順を与えねばならない。
【０１５３】
ｅＣａｌｌの確立に続いて、２つ以上のストリームが発生される。これらストリームの少なくとも１つは、ユーザインターフェイスマイクロホンアッセンブリにより発生されるボイスコールストリームであり、残りのストリーム（１つ又は複数）は、例えば、まれに及び／又は散発的にデータストリームとして送信するために各監視センサにより発生される。処理サブシステムは、上述したように、無線／モデムサブシステムへの２つのストリームを裁定する。
【０１５４】
クライアント装置６５０の例示的な実施形態は、位置決めするためのＧＰＳ（又はＡＧＰＳ）受信器を有するものとして説明したが、上述したＧＰＳ受信器に代わって又はそれに関連して他の技術も使用できることが更に明らかであろう。例えば、参考としてここにそのまま援用する２００８年９月３０日に出願された“Methods and Apparatus for Resolving Wireless Signal Components”と題する共通所有の同時係争中の米国特許出願第１２／２８６，６４６号に説明された、例えば、ＷｉＭＡＸネットワークのような単一周波数ネットワーク（ＳＦＮ）において位置決めする方法及び装置を、本発明と矛盾なく使用して、移動クライアント位置データを与えることができる。より詳細には、前記特許出願は、ワイヤレスネットワークがデータを発生し、このデータを受信器（例えば、ＵＥ）が使用して個々の送信器の貢献を解析し、ＧＰＳ衛星のような外部装置に頼らずにその位置を決定できるようにする方法及び装置を開示している。一実施形態では、ワイヤレスネットワークは、単一周波数ネットワーク（ＳＦＮ）を備え、独特のベースステーション識別子がデータ内に埋め込まれてエンコードされ、ＵＥが経路特性（経路のレイテンシ、及び到着方向）を計算してその位置を三角測量できるようにする。
【０１５５】
更に、ＧＰＳは、時々、受信器が屋内にあるとき又はトンネルや高架道路等の構造物で隠され又は覆われたときに動作できないので、セルラーベースの位置決め技術をＧＰＳの「バックアップ」として使用することもできるし（その逆も可）、或いは２つの技術を互いに確認形態で使用して、非常サービス等が正しい位置へ送られることを保証することもできる（乗物のオペレータが口頭で応答できないか、又はどこにいるか厳密に分からないと仮定して）。
【０１５６】
現存のセルラー技術は、上述したＧＰＳ又はＳＦＮベースの技術がなくても、少なくともネットワーク内のどのセルに移動ユニット又はＵＥが現在関連しているか解析することができる。従って、この情報は、位置の決定、或いは別のシステムにより与えられる別の「固定」又は推定位置の確認にも使用することができる。例えば、ＩＶＳに「水没」センサが装備され、そしてＩＶＳが通信を続けていたセルサイト又はベースステーションしか分からない場合には、この情報をＰＳＡＰ／非常オペレータによって使用して、乗物がどこにあるかのおおよそのアイデアを得ることができる（即ち、その特定のセルサイトのカバレージ内の水域を探す）。このような情報（例えば、セルサイトＩＤ、等）は、ここに述べる技術を使用してＰＳＡＰへ送られるデータ（例えば、「サイト関連」フィールド、等）内に容易に含ませることができる。
【０１５７】
業務方法
本発明の別の態様において、パケット交換ネットワーク内で前記非常コールサービスに関連した業務を行う方法を開示する。
【０１５８】
一実施形態において、本発明により可能となる無線／モデム能力は、ネットワークオペレータ及び／又は第三者の利益のために市場に出してレバレッジを得ることができる。例えば、装置の製造者又はサービスプロバイダーは、ＰＳタイプ及びＣＳ／ＰＳタイプのいずれか又は両方のネットワーク内に非常コールサービスを提供する能力に基づいて自分の製品又はサービスを他のものと差別化することができる。又、上述したＩＶＳシステム能力は、乗物が、事故の場合に、位置及び／又はサービスプランに関わらず、非常コールを開始できるという保証を顧客に与えることにより、差別化の基礎として又はより高い価格をサポートするために使用することができる。加入者は、そのような能力に対する初期価格又は進行中の契約に関して、表向きは、より多くを支払おうとする。
【０１５９】
別の態様において、本発明により可能となるＩＶＳ内の非常コールのためのリアルタイムパケット化データサービスの補足的特性は、加入者の使用において大きな融通性を与えることができる。種々のサービスを分割する機会としては、非常ドアの解錠、サイレント送信器（例えば、“ロージャック(lo-jack)”）の追跡、非常座標／方向、及び加入者の便宜のために提供される他の種々の準非常サービスのような任意のサービスを含む。
【０１６０】
本発明の幾つかの態様を、特定の一連の方法ステップに関して説明したが、これらの説明は、本発明の広範囲の方法を例示するものに過ぎず、特定の用途により要求されるように変更できることが認められる。あるステップは、ある環境のもとでは不要となるか又は任意となる。更に、ここに開示する実施形態にあるステップ又は機能を追加することもできるし、２つ以上のステップの実行順序を入れ替えることもできる。このような変更は、全て、ここに開示し請求する本発明の範囲内に包含されるとみなす。
【０１６１】
以上、種々の実施形態に適用される本発明の新規な特徴を図示して詳細に述べたが、当業者であれば、本発明の範囲から逸脱せずに、上述した装置又はプロセスの形態及び細部に種々の省略、置き換え及び変更がなされ得ることを理解されたい。以上の説明は、本発明を実施するために現在意図される最良の態様である。この説明は、何ら限定を意図するものではなく、本発明の一般的な原理を例示するに過ぎない。本発明の範囲は、特許請求の範囲により決定される。
【符号の説明】
【０１６２】
３００：従来のＲＴＰ  ＡＰＰパケット
３５０：既存のＲＴＣＰ  ＡＰＰパケットフォーマット
３５２：第１の情報エレメント
３５４：第２の情報エレメント
３５６：サブタイプフィールド
３５８：第４の情報エレメント
３６０：第５の情報エレメント
３６２：名前フィールド
４０２：初期ＳＩＰ  ＩＮＶＩＴＥ要求
４０３：ＳＩＰ  ＲＩＮＧＩＮＧ応答
４０４：ＳＩＰ  ２００  ＯＫ応答
４０６：ＳＩＰ  ＡＣＫメッセージ
５００：メッセージングフロー
６０４：中央データベース
６０６：プロセッサ
６０６Ａ：キャッシュ
６０８：メモリサブシステム
６０８Ａ：ＤＭＡ
６１０：電源
６１２：インターフェイス
６５０：ＩＶＳ装置
【図１】
2015173482.tif 000003
【図２】
2015173482.tif 000004
【図２Ａ】
2015173482.tif 000005
【図３】
2015173482.tif 000006
【図３Ａ】
2015173482.tif 000007
【図３Ｂ】
2015173482.tif 000008
【図３Ｃ】
2015173482.tif 000009
【図３Ｄ】
2015173482.tif 000010
【図４】
2015173482.tif 000011
【図５】
2015173482.tif 000012
【図６Ａ】
2015173482.tif 000013
【図６Ｂ】
2015173482.tif 000014
【手続補正書】
【提出日】平成27年6月8日(2015.6.8)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
ソースから行先へ非常コールをルーティングする方法であって、
回路交換及びパケット交換の両ネットワークルートがコールのルーティングに利用できるか否かを判定するステップと、
前記両ネットワークルートが利用できる場合に、
（i）前記ルートの少なくとも一方を、少なくとも１つの選択基準に対して評価し、
（ii）その評価の少なくとも一部に基づいてルートの１つを選択し、
（iii）その選択されたルートを経てコールをルーティングする、ステップと、
パケット交換ルートしか利用できない場合に、そのパケット交換ルートを経てコールをルーティングするステップと、を有する方法。
【請求項２】
回路交換ルートしか利用できない場合に、その回路交換ルートを経てコールをルーティングするステップをさらに有する請求項１に記載の方法。
【請求項３】
前記選択基準は、混雑、待ち時間、遅延、階層、信頼性、利用可能性及びそれらの組み合わせを含む、請求項１に記載の方法。
【請求項４】
前記階層の選択基準は、前記コールの前記ルーティングで最初の試みのために前記ルートの１つを選択し、選択されたものが失敗の場合、続いて前記ルートの他の１つを選択することを含む、請求項３に記載の方法。
【請求項５】
前記パケット交換ネットワークルートが選択された場合、第１のストリームと、１つ以上の第２のストリームとを有する複合ストリームを生成するステップをさらに有し、
前記第１のストリームは、実質的に連続的な方法で符号化された音声パケットを含み、
前記１つ以上の第２のストリームは、データパケットを含み、
前記データパケットは、前記音声パケットを修正することなく前記第１のストリーム内に挿入される、請求項１に記載の方法。
【請求項６】
前記複合ストリームは、前記第１のストリームの１つ以上のパケットに前記第２のストリームの１つ以上のパケットを散在させることによって生成される、請求項５に記載の方法。
【請求項７】
前記散在させることは、マルチプレクスアルゴリズムを使用して行われる、請求項６に記載の方法。
【請求項８】
前記１つ以上の第２のストリームのデータパケットは、実質的に不連続な又は非一定なものである、請求項５に記載の方法。
【請求項９】
前記評価することは、両方のルートが前記コールのために選択されるように、前記信頼性が所定の閾値を超え、前記待ち時間が所定の閾値より短いことを示す、請求項３に記載の方法。
【請求項１０】
前記コールが非常コールであることを判定するステップと、
前記コールが非常コールであるという指示を含ませるステップと、をさらに有する、請求項１に記載の方法。
【請求項１１】
他の装置とデータを交換するように構成されたトランシーバと、プロセッサとを備える装置であって、
前記トランシーバ及び前記プロセッサは、
回路交換及びパケット交換の両ネットワークルートがコールのルーティングに利用できるか否かを判定し、
前記両ネットワークルートが利用できる場合に、
（i）前記ルートの少なくとも一方を、少なくとも１つの選択基準に対して評価し、
（ii）その評価の少なくとも一部に基づいてルートの１つを選択し、
（iii）その選択されたルートを経てコールをルーティングし、
パケット交換ルートしか利用できない場合に、そのパケット交換ルートを経てコールをルーティングすることにより、前記他の装置へ非常コールをルーティングするように構成される、装置。
【請求項１２】
前記トランシーバ及び前記プロセッサは、さらに、
回路交換ルートしか利用できない場合に、その回路交換ルートを経てコールをルーティングすることにより、前記他の装置へ非常コールをルーティングするように構成される、請求項１１に記載の装置。
【請求項１３】
前記選択基準は、混雑、待ち時間、遅延、階層、信頼性、利用可能性及びそれらの組み合わせを含む、請求項１１に記載の装置。
【請求項１４】
前記階層の選択基準は、前記コールの前記ルーティングで最初の試みのために前記ルートの１つを選択し、選択されたものが失敗の場合、続いて前記ルートの他の１つを選択することを含む、請求項１３に記載の装置。
【請求項１５】
前記トランシーバ及び前記プロセッサは、さらに、
前記パケット交換ネットワークルートが選択された場合、第１のストリームと、１つ以上の第２のストリームとを有する複合ストリームを生成することにより、前記他の装置へ非常コールをルーティングするように構成され、
前記第１のストリームは、実質的に連続的な方法で符号化された音声パケットを含み、
前記１つ以上の第２のストリームは、データパケットを含み、
前記データパケットは、前記音声パケットを修正することなく前記第１のストリーム内に挿入される、請求項１１に記載の装置。
【請求項１６】
前記複合ストリームは、前記第１のストリームの１つ以上のパケットに前記第２のストリームの１つ以上のパケットを散在させることによって生成される、請求項１５に記載の装置。
【請求項１７】
前記散在させることは、マルチプレクスアルゴリズムを使用して行われる、請求項１６に記載の装置。
【請求項１８】
前記１つ以上の第２のストリームのデータパケットは、実質的に不連続な又は非一定なものである、請求項１５に記載の装置。
【請求項１９】
前記評価することは、両方のルートが前記コールのために選択されるように、前記信頼性が所定の閾値を超え、前記待ち時間が所定の閾値より短いことを示す、請求項１３に記載の装置。
【請求項２０】
他の装置とデータを交換する送受信手段と、処理手段とを備える装置であって、
前記処理手段は、
回路交換及びパケット交換の両ネットワークルートがコールのルーティングに利用できるか否かを判定し、
前記両ネットワークルートが利用できる場合に、
（i）前記ルートの少なくとも一方を、少なくとも１つの選択基準に対して評価し、
（ii）その評価の少なくとも一部に基づいてルートの１つを選択し、
（iii）その選択されたルートを経てコールをルーティングし、
パケット交換ルートしか利用できない場合に、そのパケット交換ルートを経てコールをルーティングすることにより、前記他の装置へ非常コールをルーティングする、装置。