特許 7009509 ネットワーク装置の管理

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2022-01-14

(45)【発行日】2022-01-25

(54)【発明の名称】ネットワーク装置の管理

(51)【国際特許分類】

   H04M 3/00 20060101AFI20220118BHJP

   H04M 3/42 20060101ALI20220118BHJP

【ＦＩ】

H04M3/00 B

H04M3/42 Z

【請求項の数】 14

(21)【出願番号】P 2019563364

(86)(22)【出願日】2018-05-17

(65)【公表番号】

(43)【公表日】2020-07-16

(86)【国際出願番号】 EP2018063019

(87)【国際公開番号】W WO2018211050

(87)【国際公開日】2018-11-22

【審査請求日】2020-01-09

(31)【優先権主張番号】17171843.0

(32)【優先日】2017-05-18

(33)【優先権主張国・地域又は機関】EP

(73)【特許権者】

【識別番号】500341779

【氏名又は名称】フラウンホーファー－ゲゼルシャフト・ツール・フェルデルング・デル・アンゲヴァンテン・フォルシュング・アインゲトラーゲネル・フェライン

(74)【代理人】

【識別番号】100085660

【弁理士】

【氏名又は名称】鈴木 均

(72)【発明者】

【氏名】ルツキー，マンフレート

(72)【発明者】

【氏名】デーラ，シュテファン

(72)【発明者】

【氏名】ディーツ，マルティン

【審査官】山岸 登

(56)【参考文献】

【文献】特開２０１１－１６６４５３（ＪＰ，Ａ）

【文献】中国特許出願公開第１０５１０００４６（ＣＮ，Ａ）

【文献】国際公開第２０１５／１２９１８１（ＷＯ，Ａ１）

【文献】米国特許出願公開第２０１６／０３０８９１９（ＵＳ，Ａ１）

【文献】特開２００７－０４９４１５（ＪＰ，Ａ）

【文献】特開２０１６－１４９６７１（ＪＰ，Ａ）

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｇ１０Ｌ１３／００－１３／１０

１９／００－９９／００

Ｈ０３Ｊ９／００－９／０６

Ｈ０４Ｂ７／２４－７／２６

１４／００－１４／０８

Ｈ０４Ｍ１／００

１／２４－３／００

３／１６－３／２０

３／３８－３／５８

７／００－７／１６

１１／００－１１／１０

９９／００

Ｈ０４Ｑ３／５８－３／６２

９／００－９／１６

Ｈ０４Ｗ４／００－９９／００

(57)【特許請求の範囲】

【請求項13】

ユーザ端末間の呼を管理するネットワーク装置（１１０）であって、
第１のユーザ端末（１２０）が前記呼の第１の音声符号化モードの使用をサポートし、第２のユーザ端末（１３０）が前記呼の第２の音声符号化モードを使用することを意図するかどうかを確認（４００）し、
前記第１のユーザ端末（１２０）が前記呼の前記第１の音声符号化モードの前記使用をサポートし、前記第２のユーザ端末（１３０）が前記呼の前記第２の音声符号化モードを使用することを意図する場合、
前記第１のユーザ端末（１２０）から前記第２のユーザ端末（１３０）に送信され、前記第１の音声符号化モードを参照する第１のパケットにパケット化された前記呼の第１のデータを、前記第２の音声符号化モードを参照する第２のパケットに再パッキング（４０２ａ）し、
前記第２のユーザ端末（１３０）から前記第１のユーザ端末（１２０）に送信され、前記第２の音声符号化モードを参照する第３のパケットにパケット化された前記呼の第２のデータを、前記第１の音声符号化モードを参照する第４のパケットに再パッキング（４０２ｂ）するように構成され、
ネットワーク装置（１１０）が、
発信ユーザ端末から着信ユーザ端末に送信される第１の初期呼依頼（２１０）が前記呼の前記第２の音声符号化モードの使用を示すかどうかを確認（４００ａ）し、
前記第１の初期呼依頼（２１０）が前記呼の前記第２の音声符号化モードの前記使用を示す場合、
前記第１の初期呼依頼（２１０）をインターセプトし、前記第１の初期呼依頼（２１０）の代わりに、第２の初期呼依頼（２２０）を前記着信ユーザ端末に転送し、ここで前記第２の初期呼依頼（２２０）は前記呼の前記第１の音声符号化モードの使用を示し、
前記着信ユーザ端末から前記発信ユーザ端末に送信される前記第２の初期呼依頼（２２０）に対する第１の回答（２３０）が前記呼の前記第１の音声符号化モードの前記使用を示すかどうかを確認（４００ｂ）し、
前記第１の回答（２３０）が前記呼の前記第１の音声符号化モードの前記使用を示す場合、
前記第１の回答（２３０）をインターセプトし、前記第１の回答（２３０）の代わりに前記発信ユーザ端末に第２の回答（２４０）を転送し、ここで前記第２の回答（２４０）は前記呼の前記第２の音声符号化モードの前記使用を示し、
前記着信ユーザ端末が前記呼の前記第１の音声符号化モードの前記使用をサポートし、前記発信ユーザ端末が前記呼の前記第２の音声符号化モードを使用することを意図し、前記着信ユーザ端末が前記第１のユーザ端末（１２０）であり、前記発信ユーザ端末が前記第２のユーザ端末（１３０）であるように表明し、
前記第２の音声符号化モードは、ＡＭＲ ＷＢ用のＲＴＰフォーマットを使用する前記 ＡＭＲ－ＷＢであり、前記第１の音声符号化モードはＥＶＳ用のＲＴＰフォーマットを使 用するＥＶＳの前記ＡＭＲ－ＷＢ相互運用モードである、ネットワーク装置（１１０）。

【請求項14】

ネットワーク装置（１１０）のための方法であって、
発信ユーザ端末から着信ユーザ端末に送信される第１の初期呼依頼（２１０）が前記呼の第２の音声符号化モードの使用を示すかどうかを確認（４００ａ）し、
前記第１の初期呼依頼（２１０）が前記呼の前記第２の音声符号化モードの前記使用を示す場合、
前記第１の初期呼依頼（２１０）をインターセプトし、前記第１の初期呼依頼（２１０）の代わりに、第２の初期呼依頼（２２０）を前記着信ユーザ端末に転送し、ここで前記第２の初期呼依頼（２２０）は前記呼の第１の音声符号化モードの使用を示し、
前記着信ユーザ端末から前記発信ユーザ端末に送信される前記第２の初期呼依頼（２２０）に対する第１の回答（２３０）が前記呼の前記第１の音声符号化モードの前記使用を示すかどうかを確認（４００ｂ）し、
前記第１の回答（２３０）が前記呼の前記第１の音声符号化モードの前記使用を示す場合、
前記第１の回答（２３０）をインターセプトし、前記第１の回答（２３０）の代わりに前記発信ユーザ端末に第２の回答（２４０）を転送し、ここで前記第２の回答（２４０）は前記呼の前記第２の音声符号化モードの前記使用を示し、
前記着信ユーザ端末が前記呼の前記第１の音声符号化モードの前記使用をサポートし、前記発信ユーザ端末が前記呼の前記第２の音声符号化モードを使用することを意図し、
前記着信ユーザ端末（１２０）から前記発信ユーザ端末（１３０）に送信され、前記第 １の音声符号化モードを参照する第１のパケットにパケット化された前記呼の第１のデー タを、前記第２の音声符号化モードを参照する第２のパケットに再パッキング（４０２ａ ）し、さらに、
前記発信ユーザ端末（１３０）から前記着信ユーザ端末（１２０）に送信され、前記第 ２の音声符号化モードを参照する第３のパケットにパケット化された前記呼の第２のデー タを、前記第１の音声符号化モードを参照する第４のパケットに再パッキング（４０２ｂ ）する、ことを含む方法。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、ネットワーク装置に関し、特に、ユーザ端末間の呼を管理するネットワーク装置に関する。

【背景技術】

【0002】

通信システムは、ネットワーク装置に接続された多数のユーザ端末を備えてもよい。
ネットワーク装置は、個々のユーザ端末間の呼を管理できる。
以下では、「ネットワーク装置の管理」と「ネットワーク装置」という用語は同じ意味で使用される。

【0003】

ユーザ端末間の通信を実装するために実装される種々のコーデックが存在する。
コーデックごとに異なる符号化品質が提供され、計算処理能力も異なる。
コーデックの１つは、音声サービスの拡張（Ｅｎｈａｎｃｅｄ Ｖｏｉｃｅ Ｓｅｒｖｉｃｅｓ（ＥＶＳ））コーデックである。
ＥＶＳは、ＧＳＭＡの「音声およびＳＭＳのＩＭＳプロファイル」ＩＲ．９２で説明されているスーパーワイドバンドおよびフルバンドＶｏＬＴＥサービスに使用できる。

【0004】

ＥＶＳの利点は、適応マルチレートワイドバンド（Ａｄａｐｔｉｖｅ Ｍｕｌｔｉ－Ｒａｔｅ Ｗｉｄｅｂａｎｄ）（ＡＭＲ－ＷＢ）と比較して、通話品質および音質が向上し、音声帯域幅が拡張され、パケット損失に対して大幅に高い堅牢性が備えられていることである。
ＥＶＳには、プライマリモードとＡＭＲ－ＷＢ相互運用モードが含まれる。
以下では、ＡＭＲ－ＷＢ ＩＯは、ＡＭＲ－ＷＢ相互運用モードの同義語とし、ＲＦＣ４８６７をペイロード形式として使用する代替実装では、ＥＶＳ ＩＯは、ＥＶＳ リアルタイム転送プロトコル（ＲＴＰ）ペイロード形式を使用するＡＭＲ－ＷＢ相互運用モードの同義語として使用される。

【0005】

ＥＶＳプライマリモードは、ＥＶＳの完全な通話品質および音質、ならびにパケット損失に対する堅牢性を提供するため、両方のユーザ端末／ＵＥ（ユーザ機器）がＥＶＳをサポートする場合はこれを選択する必要がある。
国際出願第２０１６／１８４２８１号明細書は媒体の相互運用方法およびその装置に関し、方法は、コントロールパネルによって、第１のユーザ端末が第１の媒体フォーマットを使用し、第１のユーザ端末と通信する第２のユーザ端末が第２の媒体フォーマットを使用すると決定するステップであって、第２のフォーマットはＥＶＳメインモードであるステップと、第１のユーザ端末によって送信された第１の媒体フォーマットの媒体パケットをＥＶＳ互換モードの媒体パケットに変換し、第２のユーザ端末によって送信されたＥＶＳ互換モードの媒体パケットを第１の媒体フォーマットの媒体パケットに変換することをユーザプレーンデバイスに通知するステップと、を含む。説明した技術は、ＥＶＳ互換モードに基づいて、第１のユーザの媒体フォーマットと第２のユーザの媒体データとの間の相互運用性を実現する。
米国公開特許第２００８／３２０１４８号明細書はＳＩＰアダプタがセッション開始プロトコル、つまりＳＩＰメッセージのフォーマットを変更する技術について説明している。第１のフォーマットのＳＩＰメッセージは、第１のメッセージフォーマットに基づく第１のＳＩＰサーバからＳＩＰアダプタによって受信される。ＳＩＰアダプタは、ＳＩＰメッセージを第２のフォーマットに変更し、変更したＳＩＰメッセージを第２のメッセージフォーマットに基づく第２のＳＩＰサーバに転送する。ＳＩＰアダプタは、ＳＩＰメッセージを変更することにより、異なるＳＩＰメッセージフォーマットを使用するＳＩＰサーバのクライアント間の通信セッションの確立を可能にする。

【0006】

ただし、ネットワーク内のすべての端末またはＵＥがＥＶＳモードをサポートすることは保証されない。
そのため、参加端末の可能な限り最高の音質と堅牢性を維持しながら、異種ネットワークの条件を満たす必要がある。

【発明の概要】

【発明が解決しようとする課題】

【0007】

これらの考慮事項に基づくと、本発明の目的は、より高い堅牢性ならびに改善された通話品質および音質を有するユーザ端末間の改善された通信技術を可能にする新しい管理概念を提供することにある。

【課題を解決するための手段】

【0008】

この目的は、独立請求項の主題によって解決される。好ましい実施形態は、従属請求項に定義されている。

【0009】

一実施形態によれば、ユーザ端末間の呼を管理するネットワーク装置は、第１のユーザ端末が呼の第１の音声符号化モードの使用をサポートし、第２のユーザ端末が呼の第２の音声符号化モードを使用することを意図（intends to）するかどうかを確認し、第１のユーザ端末が呼の第１の音声符号化モードの使用をサポートし、第２のユーザ端末が呼の第２の音声符号化モードを使用することを意図する場合、第１のユーザ端末から第２のユーザ端末に送信され、第２の音声符号化モードを参照する第１のパケットにパケット化された呼の第１のデータを、第１の音声符号化モードを参照する第２のパケットに再パッキングし、第２のユーザ端末から第１のユーザ端末に送信され、第２の音声符号化モードを参照する第３のパケットにパケット化された呼の第２のデータを、第１の音声符号化モードを参照する第４のパケットに再パッキングする。
これは、例えば、ＥＶＳおよびＡＭＲ－ＷＢ端末を備えた混在モード環境においてＥＶＳの機能を最大限に利用できるという利点がある。

【0010】

さらなる実施形態では、ネットワーク装置は、第１のユーザ端末と第２のユーザ端末との間の呼のセットアップ中に確認を実行することができる。

【0011】

さらなる実施形態では、ネットワーク装置は、発信ユーザ端末から着信ユーザ端末に送信された第１の初期呼依頼（offer）が呼の第２の音声符号化モードの使用を示すかどうかを確認してもよく、第１の初期呼依頼が呼の第２の音声符号化モードの使用を示す場合、第１の初期呼依頼をインターセプト（途中で捕獲する）し、第１の初期呼依頼の代わりに、第２の初期呼依頼を着信ユーザ端末に転送し、ここで第２の初期呼依頼は呼の第１の音声符号化モードの使用を示し、そして着信ユーザ端末から発信ユーザ端末に送信された第２の初期呼依頼に対する第１の回答が呼の第１の音声符号化モードの使用を示すかどうかを確認し、第１の回答が呼の第１の音声符号化モードの使用を示す場合、第１の回答をインターセプトし、第１の回答の代わりに発信ユーザ端末に第２の回答を転送し、ここで第２の回答は呼の第２の音声符号化モードの使用を示し、さらに、着信ユーザ端末が呼の第１の音声符号化モードの使用をサポートし、発信ユーザ端末が呼の第２の音声符号化モードを使用することを意図し、着信ユーザ端末が第１のユーザ端末であり、発信ユーザ端末が第２のユーザ端末であるように表明（assert）する。

【0012】

さらなる実施形態では、発信ユーザ端末から着信ユーザ端末に送信された第１の初期呼依頼は、呼の第１の音声符号化モードの使用を従属的に示してもよい。

【0013】

さらなる実施形態では、ネットワーク装置は、第１の回答が呼の第２の音声符号化モードの使用を示す場合、第１の回答を発信ユーザ端末に転送してもよく、第１の回答は呼の第２の音声符号化モードの使用を示し、そして第１のユーザ端末も第２ユーザ端末も呼の第１の音声符号化モードの使用をサポートしていないことを表明する。

【0014】

さらなる実施形態では、ネットワーク装置は、発信ユーザ端末から着信ユーザ端末に送信された第１の初期呼依頼に応答して着信ユーザ端末から発信ユーザ端末に送信され、第１の音声符号化モードが属する呼の１つ以上の音声符号化モードのグループのうちのいずれかの使用を示す第１の回答が第２の音声符号化モードの使用を示すかどうかを確認してもよく、第１の回答が呼の第２の音声符号化モードの使用を示す場合、第１の回答をインターセプトし、第１の回答の代わりに発信ユーザ端末に第２の回答を転送してもよく、ここで第２の回答は呼の第１の音声符号化モードの使用を示し、さらに、発信ユーザ端末が呼の第１の音声符号化モードの使用をサポートし、着信ユーザ端末が呼の第２の音声符号化モードを使用することを意図し、発信ユーザ端末が第１のユーザ端末であり、着信ユーザ端末が第２のユーザ端末であるように表明する。

【0015】

さらなる実施形態では、発信ユーザ端末から着信ユーザ端末に送信された第１の初期呼依頼は、第１の音声符号化モードの使用を少なくとも従属的に示してもよい。

【0016】

さらに別の実施形態では、ネットワーク装置は、第１の初期呼依頼が第１の音声符号化モードの使用を示すかどうかを確認し、そうである場合、第１の初期呼依頼（３１０）をインターセプトし、第１の初期呼依頼（３１０）の代わりに第２の初期呼依頼（３２０）を転送し、第２の初期呼依頼（３２０）は、第１の音声符号化モードおよび第２の音声符号化モードを含む複数の音声符号化モードの使用を示す。

【0017】

さらなる実施形態では、第２の音声符号化モードはＡＭＲ－ＷＢであってもよく、第１の音声符号化モードはＥＶＳのＡＭＲ－ＷＢ相互運用可能モードであってもよい。

【0018】

さらなる実施形態では、第２の音声符号化モードは、ＡＭＲ ＷＢ用のＲＴＰフォーマットを使用するＡＭＲ－ＷＢであってもよく、第１の音声符号化モードは、ＥＶＳ用のＲＴＰフォーマットを使用するＥＶＳのＡＭＲ－ＷＢ相互運用可能モードであってもよい。

【0019】

さらなる実施形態では、第１および第２の音声符号化モードは、等しい符号化構文を使用して、または等しく解析可能なペイロードを使用して、またはトランスコーディングなしで相互に転送可能な音声コンテンツを表してもよい。
例えば、トランスコーディングなしというのは、再量子化を必要とせずに相互に転送可能であることを指してもよい。

【0020】

さらなる実施形態において、第１および第２のパケットは、それらのペイロードセクションの内容が一致してもよく、第３および第４のパケットは、オプションの非トランスコーディング動作を除いて、それらのペイロードセクションの内容が一致してもよい。

【0021】

さらなる実施形態では、ネットワーク装置は、再パッキングにおけるオプションの非トランスコーディング動作を除いて、再パッキングにおいて第１および第３のパケットのペイロードセクションを未修正の状態にしておくことができる。

【0022】

以下において、本発明は、添付の図面に示される実施形態に関連して説明される。

【図面の簡単な説明】

【0023】

【図1】本発明の一実施形態による、ユーザ端末に接続された概念的なネットワーク装置を示す図である。

【図2】本発明の一実施形態による、ユーザ機器間のシグナリングシーケンスを示す図である。

【図3】本発明の別の実施形態による、ユーザ機器間の別のシグナリングシーケンスを示す図である。

【0024】

前述のように、音質と堅牢性が向上するため、ＥＶＳモードを使用するのが有利である。
呼に参加しているすべての端末、いわゆる「呼レッグ」がＥＶＳを使用できる場合、ＥＶＳは予測どおりに使用される。

【0025】

１つの呼レッグ、例えばＵＥのみがＥＶＳをサポートしており、おそらくそれが接続されているネットワークもＥＶＳをサポートし、他のＵＥまたはそれが接続されているネットワークはＥＶＳをサポートできず、ＡＭＲ－ＷＢのみをサポートしている場合、ＥＶＳのエラーに対する堅牢性は、ＥＶＳがサポートされている呼レッグにおけるＥＶＳの使用によって依然として利用され得る。

【0026】

このアプリケーションの概念によれば、異種デバイス機能を備えたネットワークで、または異なるコーデック機能を備えたネットワークが相互接続されている場合、ＥＶＳの使用が強制される。
この手法は、ＩＭＳのＣＳＣＦまたはＡＴＣＦネットワークノードなどであり得るＳＩＰネットワークノードにおけるＳＤＰの変更に依存している。

【0027】

この手法では、最初にＥＶＳをサポートするデバイスの不足によりエンドツーエンドのＥＶＳ呼が不可能な場合でも、ＥＶＳ対応端末におけるＥＶＳ実装をすでに実行できるため、高品質のＥＶＳ呼への移行が高速化されると想定される。

【0028】

この概念は、ＥＶＳ呼レッグでＥＶＳプライマリモードを使用し、ネットワーク内のＡＭＲ－ＷＢへのトランスコーディングを実行することで促進できる。
ＥＶＳ呼レッグは、アップリンクとダウンリンクの両方で優れたエラー堅牢性の恩恵を受ける。
特にチャネル認識モードで改善されたＥＶＳエラーの堅牢性により、呼レッグのＢＬＥＲターゲットを緩和でき、これは、シグナル・ノイズ比（ＳＮＲ）および屋内／屋外のセルカバレッジ（通信範囲）の改善に対応する。

【0029】

また、ＥＶＳ ＩＯモードを使用して、ネットワーク内での再パッケージ化を実行できる。
この再パッケージ化手順は、ＥＶＳ ＶｏＬＴＥからＶｏＬＴＥへの通話中に、単一無線音声通話継続（ＳＲＶＣＣ）中にすでに実行され、１つのＵＥがＣＳネットワークに切り替わるので、ＡＭＲ－ＷＢに切り替える必要がある。
この場合、ネットワークを切り替える前後でＥＶＳコーデックを継続的に使用できる。
コーデックをプライマリモードからＥＶＳ ＩＯモードに切り替えて、両方のネットワークとの相互運用性を実現できる。
これにより、呼のセットアップ中にＥＶＳ ＩＯモードが直接ネゴシエートされるユースケースも有効になる。
従来のＡＭＲ－ＷＢの代わりにＥＶＳ ＩＯを使用することは、エラーの堅牢性と音質に関して有利である可能性がある。

【0030】

以下では、データパケットを分析し、それらを変更できるコントロールおよびユーザプレーンのアクティブネットワークノードを想定している。
頭字語ＩＭＳ（ＩＰ Ｍｕｔｉｍｅｄｉａ Ｓｕｂｓｙｓｔｅｍ）は、呼のセットアップに関係するＥｖｏｌｖｅｄ Ｐａｃｋｅｔ Ｃｏｒｅ、ＥＰＣ、およびＩＭＳにおけるすべてのネットワークノードの同義語として使用される。

【0031】

前述のように、ｏＵＥとｔＵＥは直接通信することはできないが、通信を管理できるＩＭＳを介して通信する。
ＡＭＲ－ＷＢ（適応型マルチレートワイドバンド）コーデックがネゴシエートされる場合、ＵＥ（例えば、ｏＵＥおよびｔＵＥ）は、送信側および／または受信側のＡＭＲ－ＷＢの代替実装としてＡＭＲ－ＷＢ ＩＯモードを使用できる。
この動作は、従来のＡＭＲ－ＷＢに対して有益な場合がある。
ＡＭＲ－ＷＢ ＩＯを使用してＡＭＲ－ＷＢを実装するかどうかはＵＥ提供会社に独自の裁量であるため、オペレータまたはＩＭＳネットワークはＵＥにそのように強制することはできない。

【0032】

以下では、オペレータまたはＩＭＳネットワークが、ＥＶＳ対応ＵＥに、非ＥＶＳ対応ＵＥへの呼に対して、例えば従来のＡＭＲ－ＷＢの代わりにＥＶＳ ＩＯモードを介して組み込みＡＭＲ－ＷＢ相互運用モードを使用するように強制する場合の手法について説明する。
これは、呼の確立中に次のＳＤＰ変更によって実装できる。

【0033】

変更の第１のカテゴリでは、ｏＵＥはＥＶＳ－ＩＯを含むＥＶＳをサポートし、ｔＵＥはＡＭＲ－ＷＢのみをサポートする。

【0034】

この第１のカテゴリでは、変更１ａによって、ｏＵＥの初期依頼に対するｔＵＥの回答を受信すると、ＩＭＳは、ｏＵＥがＥＶＳ－ＩＯモードをサポートし、ｔＵＥがＡＭＲ－ＷＢのみをサポートしていることを認識する。
変更１ｂによると、ＩＭＳは、ｉ）この回答および後続の回答でＡＭＲ－ＷＢを「ＥＶＳ ＩＯモードで開始するＥＶＳ」に置き換え、ｉｉ）後続の依頼で「ＥＶＳ ＩＯモードで開始するＥＶＳ」をＡＭＲ－ＷＢに置き換える。

【0035】

変更の第２のカテゴリでは、ｏＵＥはＡＭＲ－ＷＢのみをサポートし、ｔＵＥはＥＶＳ－ＩＯを含むＥＶＳをサポートする。

【0036】

この第２のカテゴリでは、変更２ａによって、ｏＵＥ（ＡＭＲ－ＷＢのみを含む）から初期依頼を受信すると、ＩＭＳはｔＵＥに転送される依頼に「ＥＶＳ ＩＯモードで開始するＥＶＳ」を追加する。

【0037】

変更２ｂによると、ｔＵＥが「ＥＶＳ ＩＯモードで開始するＥＶＳ」で応答する場合、ＩＭＳは、ｏＵＥがＡＭＲ－ＷＢのみをサポートし、ｔＵＥはＥＶＳ ＩＯモードをサポートすることを認識する。

【0038】

変更２ｃによると、ＩＭＳは、ｉ）この回答および後続の回答で「ＥＶＳ ＩＯモードで開始するＥＶＳ」をＡＭＲ－ＷＢに置き換え、ｉｉ）後続の依頼でＡＭＲ－ＷＢを「ＥＶＳ ＩＯモードで開始するＥＶＳ」に置き換える。

【0039】

例えば、ＵＥ１およびＵＥ２の２つの端末を備えたシステムでは、ＵＥ１がＡＭＲ－ＷＢのみをサポートし、ＵＥ２がＥＶＳをサポートし、ＡＭＲ－ＷＢをＥＶＳ ＩＯにマッピングすることをＩＭＳが認識している場合がある。

【0040】

変更１ａによると、回答にＡＭＲ－ＷＢが含まれ、ＥＶＳは含まれず、初期依頼にＥＶＳが含まれる場合、ＩＭＳネットワークは「ＡＭＲ－ＷＢ」を「ＥＶＳ」に、特に回答メッセージのＥＶＳ ＩＯ機能に置き換える。

【0041】

変更１ｂによると、依頼にＡＭＲ－ＷＢが含まれ、ＥＶＳは含まれず、初期回答メッセージにＥＶＳが含まれる場合、ＩＭＳネットワークは「ＡＭＲ－ＷＢ」を「ＥＶＳ」に、特に依頼メッセージのＥＶＳ ＩＯ機能に置き換える。

【0042】

変更２によると、ＥＶＳ ＩＯサポートのためにｔＵＥを探査（probe）できる。
この場合、依頼にＡＭＲ－ＷＢが含まれるがＥＶＳが含まれない場合、ＩＭＳネットワークはＥＶＳ ＩＯ機能を呼依頼に追加する。
ＩＭＳは、ＵＥ１がＥＶＳをサポートし、ＵＥ２がＡＭＲ－ＷＢのみをサポートすることを「認識」しているため、ＥＶＳ ＩＯをＡＭＲ－ＷＢにマッピングする。

【0043】

第３クラスの変更、特に変更３ａによると、回答メッセージにＥＶＳ ＩＯが含まれ、初期呼依頼にＥＶＳが含まれなない場合、ＩＭＳネットワークは回答メッセージのＥＶＳ ＩＯをＡＭＲ－ＷＢ機能に置き換える。

【0044】

さらに、第３クラスの変更では、変更３ｂによると、呼依頼にＥＶＳ ＩＯが含まれ、初期回答メッセージにＥＶＳが含まれない場合、ＩＭＳネットワークは呼依頼のＥＶＳ ＩＯをＡＭＲ－ＷＢ機能に置き換える。

【0045】

ＳＩＰコマンドの関連部分とともに、依頼／応答中のＳＤＰの変更については、図２および３に関連して後で説明する。
メッセージシーケンスは、コーデックネゴシエーション関連メッセージに縮小されることに注意されたい。
また、読み易さを向上させるために、ＳＤＰメッセージが短縮されている。
指定された２つの例は、「ＧＳＭＡ ＦＣＭ．０１－ＶｏＬＴＥサービスの説明と実装ガイド（バージョン２．０）」のセクション３．２において説明されている単一のＰＭＮ呼確立の事例に基づいている。
詳細については、ＳＤＰパラメータの使用の詳細な説明を含む「３ＧＰＰ ２６４４５ Ａｎｎｅｘ Ａ３．３．３」、およびＶｏＬＴＥのＥＶＳ固有のＳＤＰ制限について説明する「ＧＳＭＡ ＩＲ．９２章２．４．３．３」を参照されたい。

【0046】

すべての変更は、すでにＳＤＰメッセージをマングリングしているＩＭＳネットワークインスタンスに実装されると想定される。
例えばそれらは、ＳＲＶＣＣにすでに存在するＡＴＣＦ（アクセス転送制御機能）などのＰ－ＣＳＣＦまたは他のＩＭＳネットワークインスタンスに実装できる。
再パッケージ化は、例えばメディアリソースファンクションプロセッサ（ＭＲＦＰ）（ｔｂｃ．）またはアクセス転送ゲートウェイ（ＡＴＧＷ）に実装されてもよい。

【0047】

図１は、本発明によるネットワーク装置１１０を含むシステム１００を示す。
ネットワーク装置１１０は、第１のユーザ端末１２０が呼の第１の音声符号化モードの使用をサポートできるかどうかを確認し、第２のユーザ端末１３０が呼の第２の音声符号化モードを使用することを意図（intends to）するかどうかを確認する。
この実施形態では、第１の音声符号化モードと第２の音声符号化モードとは異なっていてもよく、第１の音声符号化モードはＥＶＳを指し、第２の音声符号化モードはＡＭＲ－ＷＢを指してもよい。
上述の音声モードは単なる例であり、異なる符号化技術を含んでもよいことは当業者には明らかである。

【0048】

ネットワーク装置１１０は、第１のユーザ端末１２０が第１の音声符号化モードの使用をサポートし、第２のユーザ端末が呼の第２の音声符号化モードを使用することを意図する場合、第１のユーザ端末１２０から第２のユーザ端末１３０に送信され、第２の音声符号化モードを参照する第１のパケットにパケット化されたデータを、第１の音声符号化モードを参照する第２のパケットに再パッキングする。
逆に、第２のユーザ端末１３０から第１のユーザ端末１２０に送信され、第２の音声符号化モードを参照する第３のパケットにパケット化された呼の第２のデータは、第１の音声符号化モードを参照する第４のパケットにパケット化される。

【0049】

ネットワーク装置１１０、第１のユーザ端末１２０、第２のユーザ端末１３０、および場合によってはさらなるユーザ端末１４０を含むシステムでは、制御およびユーザプレーンにアクティブなネットワークノードが存在すると想定され、ＩＭＳは、呼のセットアップに関係するＥＰＣおよびＩＭＳのすべてのネットワークノードの同義語として使用される。
発信ユーザ端末またはユーザ機器は、前述のｏＵＥに対応し、着信ＵＥは前述のｔＵＥに対応する。

【0050】

一般に、ｏＵＥは、ユーザ機器またはユーザ端末が接続されているＩＰマルチメディアサブシステムであるＩＭＳとデータを送受信する。
また、ｔＵＥはＩＭＳに接続されているため、ｏＵＥとｔＵＥとの間の通信はＩＭＳを介して容易になる。

【0051】

通信に使用されるコーデックを確立するとき、およびＡＭＲ－ＷＢが使用される場合、ＵＥは送信側および／または受信側のＡＭＲ－ＷＢの代替実装としてＡＭＲ－ＷＢ ＩＯモードを使用できる。
前述したように、この動作は従来のＡＭＲ－ＷＢに対して有益であるが、ＡＭＲ－ＷＢ ＩＯを使用してＡＭＲ－ＷＢを実装するのはＵＥ提供会社の裁量であり、ＩＭＳネットワークによってＵＥを強制することはできない。

【0052】

以下では、オペレータ／ＩＭＳネットワークが、ＥＶＳ対応ＵＥに、非ＥＶＳ対応ＵＥへの呼に対して、従来のＡＭＲ－ＷＢの代わりにＥＶＳ ＩＯモードを介して組み込みＡＭＲ－ＷＢ相互運用モードを使用するように強制する場合の手法について提供する。
これは、呼の確立中に前述のＳＤＰ変更によって実装できる。

【0053】

ｏＵＥの初期依頼に対するｔＵＥの回答を受信すると、ＩＭＳは、ｏＵＥがＥＶＳ－ＩＯモードをサポートし、ｔＵＥがＡＭＲ－ＷＢのみをサポートしていることを認識する。
ＩＭＳは、この回答および後続の回答でＡＭＲ－ＷＢを「ＥＶＳ ＩＯモードで開始するＥＶＳ」に置き換え、後続の依頼で「ＥＶＳ ＩＯモードで開始するＥＶＳ」をＡＭＲ－ＷＢに置き換える。

【0054】

図１は、２つのユーザ端末１２０および１３０と通信するネットワーク装置１１０を示す。
前述のように、ネットワーク装置１１０は、端末が呼の特定の音声符号化モードを使用することを意図するかどうかを確認する。
例えば、ネットワーク装置１１０は、第１のユーザ端末１２０がＥＶＳ規格に関連する音声符号化モードを使用することを意図するかどうか、および第２のユーザ端末１３０が異なる音声符号化モード、例えばＡＭＲを使用することを意図するかどうかを確認してもよい。

【0055】

第１および第２のユーザ端末が共通の音声符号化モードを使用することを意図する限り、通信はさらなる取り組み（efforts）なしに実行され得る。
第１のユーザ端末１２０が以下で第１の音声符号化モードと呼ばれるＥＶＳ関連の音声符号化モードをサポートし、第２のユーザ端末が以下で第２の音声符号化モードと呼ばれるＡＭＲ関連の音声符号化モードを使用する場合、ネットワーク装置１１０はさらなる取り組み（efforts）をしなければならない。
より詳細には、ネットワーク装置１１０は、第１のユーザ端末１２０から送信されたデータを第１から第２の音声符号化モードに再パッキングし、第２のユーザ端末から送信されたデータを第２の音声符号化モードから第１の音声符号化モードに再パッキングする。

【0056】

通常、ネットワーク装置は、呼のセットアップ中に個々のユーザ端末がどの音声符号化モードを使用することを意図するかを確認する。
それでも、呼のセットアップ中にこの確認を実行することは絶対に必要ではないが、呼がすでに確立された後でもこの確認が実行される可能性もある。
これは、例えば、制限された帯域幅条件またはユーザ端末の計算能力に関する考慮事項に適応するために、呼で使用される音声符号化モードを変更する必要がある場合である。

【0057】

確認が呼のセットアップ中にすでに実行されている例では、ネットワーク装置１１０は、発信ユーザ端末から送信された第１の初期呼依頼が、第２の音声符号化モードが呼に使用されることを示すかどうか、または第１の音声符号化モードが推奨されるかどうかを確認する。
第２の音声符号化モードを使用することが示されている場合、この第１の初期呼依頼はインターセプトされ、これに代わって、第２の初期呼依頼が着信ユーザ端末に送信され、第２の初期呼依頼は、第１の音声符号化モードが呼に使用されることを示す。

【0058】

同様に、ネットワーク装置１１０は、第２の初期呼依頼の回答が、第１の音声符号化モードが呼に使用されることを示すかどうかを確認し、すると、この第１の回答はインターセプトされ、第１の回答の代わりに発信ユーザ端末への第２の回答に置き換え／転送され、第２の回答は第２の音声符号化モードの使用を示す。
この呼依頼のインターセプトおよび置換とその応答により、発信ユーザ端末には第２の音声符号化モードが使用されているように見え、着信ユーザ端末には第１の音声符号化モードが呼に使用されているように見える。
言い換えれば、これは、着信ユーザ端末が第１の音声符号化モードの使用をサポートし、発信ユーザ端末が第２の音声符号化モードを使用することを意図していると表明する。

【0059】

発信ユーザ端末から着信ユーザ端末に送信される第１の初期呼依頼は、呼の第１の音声符号化モードの使用を従属的に示す。

【0060】

第１の初期呼依頼が第２の音声符号化モードの使用を示す場合に何が起こるかについては上記で説明した。
以降、この呼依頼に対する回答について説明する。
第１の回答が呼の第２の音声符号化モードの使用が実行されることを示す場合、発信ユーザ端末への第１の回答が発信ユーザ端末に転送され、第１の回答は、呼の第２の音声符号化モードが使用されることを示す。
第１のユーザ端末も第２のユーザ端末も、呼の第１の音声符号化モードの使用をサポートしていないと表明される。

【0061】

発信ユーザ端末から着信ユーザ端末への第１の初期呼依頼に応答して着信ユーザ端末から第１の回答を受信した後、第２の音声符号化モードの使用を示すか、さらに第１の音声符号化モードが属する呼の音声符号化モードのグループのいずれかの使用を示すかが確認される。
第１の回答が呼の第２の音声符号化モードの使用を示す場合、第１の回答はインターセプト（途中で捕獲され）され、代わりに第２の回答が発信ユーザ端末に転送され、第２の回答は、呼の第１の音声符号化モードの使用を示す。
さらに、発信ユーザ端末が第１の音声符号化モードの使用をサポートし、着信ユーザ端末が呼の第２の音声符号化モードを使用することを意図していると表明される。

【0062】

一実施形態では、第１の初期呼依頼は、第１の音声符号化モードの使用を従属的に示し得る。

【0063】

別の実施形態では、ネットワーク装置は、発信ユーザ端末から着信ユーザ端末に送信された第１の初期呼依頼が第１の音声符号化モードの使用を示すかどうかを確認してもよく、そうであれば、第１の初期呼依頼をインターセプトし、代わりに第１の音声符号化モードおよび第２の音声符号化モードを含む複数の音声符号化モードの使用を示す第２の初期呼依頼を転送してもよい。

【0064】

異なる音声符号化モードを使用できることは明らかであり、実施形態では、第２の音声符号化モードはＡＭＲ－ＷＢモードであってもよく、第１の音声符号化モードはＥＶＳのＡＭＲ－ＷＢ相互運用モードであってもよい。

【0065】

さらなる実施形態では、第２の音声モードは、ＡＭＲ－ＷＢ用のＲＴＰフォーマットを使用するＡＭＲ－ＷＢモードであり、第１の音声符号化モードは、ＥＶＳ用のＲＴＰフォーマットを使用するＥＶＳのＡＭＲ－ＷＢ相互運用モードである。
しかしながら、現在議論されている発明が前述の音声符号化モードに限定されず、他の音声符号化モードにも使用できることは、当業者には明らかである。

【0066】

音声符号化モードに関しては、これらのモードは、等しい符号化構文を使用して、または等しく解析可能なペイロードを使用して、またはトランスコーディングなしで相互に転送可能な音声コンテンツを表してもよい。
例えば、トランスコーディング（データの形式変換）を行わないということは、再量子化の必要がなくなるということであってもよい。

【0067】

様々な音声符号化モードでエンコードされたデータを転送する場合、このデータはパケットの形式で転送される。
当業者は、パケットがペイロードセクションを含み、第１および第２の音声データを参照する第１および第２のパケットが、それらのペイロードセクションに関して内容が一致することを知っている。
さらに、第２のユーザ端末から第１のユーザ端末に送信されたデータに対応する第３および第４のパケットは、オプションの非トランスコーディング動作を除き、ペイロードセクションに関して内容が一致してもよい。

【0068】

ネットワーク装置は、再パッキングにおけるオプションの非トランスコーディング動作を除き、再パッキングにおいて第１および第３のパケットのペイロードセクションを未修正の状態にするように構成できる。

【0069】

図２は、ＥＶＳとＡＭＲ－ＷＢが可能な発信ユーザ機器ｏＵＥと、ＡＭＲ－ＷＢを使用できる着信ユーザ機器ｔＵＥとの間の通信のシグナリングシーケンスの例を示している。
これらのユーザ機器は、前述のように管理ネットワーク装置に接続でき、管理ネットワーク装置は、ＥＶＳおよびＡＭＲ－ＷＢの両方を使用して通信でき、ＥＶＳとＡＭＲ－ＷＢの間でメッセージを解釈／変換する。
次の例で説明するように、この管理ネットワーク装置は、ＩＰマルチメディアサブシステム、ＩＭＳであってもよい。

【0070】

ステップ２１０で、ＳＤＰ依頼がｏＵＥからＩＭＳに送信される。このメッセージは、ＥＶＳおよびＡＭＲ－ＷＢの両方を使用できることを示している。
ステップ２２０で、メッセージはＩＭＳからｔＵＥに転送される。
このメッセージには、ＡＭＲ－ＷＢモードのみが記載されている。
ステップ２１０およびステップ２２０は、「ＳＩＰ招待」メッセージを表す。
ステップ２１０および２２０は、端末が第１および／または第２の音声符号化モードの使用をサポートするかどうか、ならびにどの音声符号化モードが呼に示されるかを呼依頼を用いて確認する確認４００ａに関する。

【0071】

ＳＩＰ招待に対する応答として、メッセージ、この場合はＳＤＰ回答が、ステップ２３０でｔＵＥからＩＭＳに送信され、このメッセージはＡＭＲ－ＷＢ形式である。
ステップ２４０で、メッセージはＩＭＳからｏＵＥに転送され、ＥＶＳモードに変換される。
ステップ２３０および２４０は、「ＳＩＰ１８３『進行』」メッセージを表す。
ステップ２３０および２４０は、ＳＤＰ回答を使用してどの音声符号化モードが呼に対して示されているかを確認する確認４００ｂに関する。

【0072】

ステップ２５０で、ＥＶＳモードを使用して、ｏＵＥからＩＭＳにＳＩＰ依頼が送信される。
ステップ２５０は、「ＳＩＰ更新」メッセージに関する。
ステップ２６０で、ＡＭＲ－ＷＢモードを使用して、ＳＤＰ依頼メッセージがＩＭＳからｔＵＥに送信される。

【0073】

ステップ２７０で、ＡＭＲ－ＷＢを使用して、ＳＤＰ回答メッセージがｔＵＥからＩＭＳに送信される。
ステップ２７０は、「ＳＩＰ ２００『ＯＫ』」メッセージに関する。
ステップ２８０で、ＳＤＰ回答メッセージは、ＥＶＳモードを使用してｏＵＥに転送される。

【0074】

この実施形態では、ＥＶＳ ＩＯがｏＵＥで使用され、ＡＭＳ－ＷＢがｔＵＥで使用される。
ここでＩＭＳによって表されるネットワークは、ｏＵＥとｔＵＥとの間の接続を容易にするために再パッケージ化を実行してもよい。
ここでは、トランスコーディングは必要ない。

【0075】

さらに、この実施形態では、前述の変更１ａ（ＩＭＳネットワークがＡＭＲ－ＷＢをＥＶＳ－ＩＯに交換することによりＳＤＰ回答を変更する）、および変更３ｂ（ＩＭＳネットワークが（２回目のＳＤＰ依頼において）ＥＶＳ ＩＯをＡＭＲ－ＷＢに交換する）が適用される。

【0076】

図３は、発信ユーザ機器ｏＵＥと着信ユーザ機器ｔＵＥとの間の図２に関連して示され説明されたものと同様の信号シーケンス／信号フローを示すが、この場合、ｏＵＥはＡＭＲ－ＷＢに対応し、ｔＵＥはＥＶＳおよびＡＭＲ－ＷＢに対応している。
また、ｏＵＥおよびｔＵＥは、前述のように管理ネットワーク装置に接続でき、管理ネットワーク装置は、ＥＶＳおよびＡＭＲ－ＷＢの両方を使用して通信でき、ＥＶＳとＡＭＲ－ＷＢとの間でメッセージを解釈／変換できる。
この管理ネットワーク装置は、ＩＰマルチメディアサブシステム、ＩＭＳであってもよい。

【0077】

ステップ３１０で、「ＳＤＰ依頼」がＡＭＲ－ＷＢモードでｏＵＥからＩＭＳに送信される。
ステップ３２０で、ＳＤＰ依頼がＩＭＳからｔＵＥに、この場合はＥＶＳモードで送信／転送される。
ステップ３１０および３２０は、「ＳＩＰ招待」に関連していてもよい。
ステップ３１０および３２０は、端末が第１および／または第２の音声符号化モードの使用をサポートするかどうか、ならびにどの音声符号化モードが呼に示されるかを確認する確認４００ｃに関する。

【0078】

ステップ３３０で、ＥＶＳモードを使用して、「ＳＤＰ回答」がｔＵＥからＩＭＳに送信される。
ステップ３４０で、ＡＭＲ－ＷＢモードを使用して、ＳＤＰ回答がＩＭＳからｏＵＥに転送される。
ステップ３３０および３４０の両方は、「ＳＩＰ１８３『進行』」メッセージに関してもよい。
ステップ３３０および３４０は、ＳＤＰ回答を使用してどの音声符号化モードが呼に対して示されているかを確認する確認４００ｄに関する。

【0079】

ステップ３５０で、ＡＭＲ－ＷＢモードを使用して、「ＳＤＰ依頼」メッセージがｏＵＥからＩＭＳに送信される。
ステップ３５０は、「ＳＩＰ更新」メッセージに関してもよい。
ステップ３６０で、ＥＶＳモードを使用して、ＳＤＰ依頼がＩＭＳから着信ＵＥに転送される。

【0080】

ステップ３７０で、ＥＶＳモードを使用して、「ＳＤＰ回答」メッセージがｔＵＥからＩＭＳに送信される。
ステップ３７０は、「ＳＩＰ ２００『ＯＫ』」メッセージに関してもよい。
ステップ３８０で、ＡＭＲ－ＷＢモードを使用して、ステップ３７０のＳＤＰ回答がＩＭＳからｏＵＥに転送される。

【0081】

この実施形態では、ＥＶＳ ＩＯがｔＵＥで使用され、ＡＭＳ－ＷＢがｏＵＥで使用される。
ここで、ＩＭＳによって表されるネットワークは、ｏＵＥとｔＵＥとの間の接続を容易にするために再パッケージ化を実行してもよい。ここでも、トランスコーディングは必要ない。

【0082】

さらに、この実施形態では、前述の変更２（ＩＭＳネットワークがＥＶＳ ＩＯをＳＤＰ依頼に追加して、（初期ＳＤＰ依頼において）ＥＶＳのｔＵＥを探査（probe）する）、変更３ａ（ＩＭＳネットワークが（ＳＤＰ回答において）ＥＶＳ ＩＯとＡＭＲ－ＷＢを交換する）および変更１ｂ（ＩＭＳネットワークが（２回目のＳＤＰ依頼において）ＡＭＲ－ＷＢとＥＶＳ ＩＯを交換する）が適用される。

【0083】

一部の態様を装置の文脈で説明したが、これらの態様は対応する方法の説明も表し、ブロックまたはデバイスが方法ステップまたは方法ステップの特徴に対応することは明らかである。
同様に、方法ステップの文脈で説明される態様は、対応するブロックまたはアイテムまたは対応する装置の機能の説明も表す。
方法ステップの一部またはすべては、例えばマイクロプロセッサ、プログラム可能なコンピュータ、または電子回路などのハードウェア装置によって（またはそれらを使用して）実行されてもよい。
一部の実施形態では、最も重要な方法ステップのうちの１つ以上をそのような装置によって実行することができる。

【0084】

本発明によって符号化された音声信号は、デジタル記憶媒体に記憶することができ、またはインターネットなどの無線伝送媒体または有線伝送媒体などの伝送媒体で伝送することができる。

【0085】

特定の実装要件に応じて、本発明の実施形態は、ハードウェアまたはソフトウェアで実装することができる。
実装は、電子的に読み取り可能な制御信号が格納され、それぞれの方法が実行されるように、プログラム可能なコンピュータシステムと協働する（または協働することができる）デジタル記憶媒体、例えばフロッピーディスク、ＤＶＤ、Ｂｌｕ－Ｒａｙ、ＣＤ、ＲＯＭ、ＰＲＯＭ、ＥＰＲＯＭ、ＥＥＰＲＯＭまたはフラッシュメモリを使用して実行できる。
したがって、デジタル記憶媒体はコンピュータで読み取り可能であってもよい。

【0086】

本発明による一部の実施形態は、本明細書に記載の方法の１つが実行されるように、プログラム可能なコンピュータシステムと協働することができる電子的に読み取り可能な制御信号を有するデータキャリアを含む。

【0087】

一般に、本発明の実施形態は、プログラムコードを有するコンピュータプログラム製品として実装することができ、プログラムコードは、コンピュータプログラム製品がコンピュータ上で実行されるときに方法の１つを実行するように動作する。
プログラムコードは、例えば、機械読み取り可能なキャリアに保存されてもよい。

【0088】

他の実施形態は、機械読み取り可能なキャリアに格納された、本明細書に記載の方法の１つを実行するためのコンピュータプログラムを含む。

【0089】

言い換えれば、したがって、本発明の方法の実施形態は、コンピュータプログラムがコンピュータ上で実行されるときに、本明細書に記載の方法の１つを実行するためのプログラムコードを有するコンピュータプログラムである。

【0090】

したがって、本発明の方法のさらなる実施形態は、本明細書に記載の方法の１つを実行するためのコンピュータプログラムを記録したデータキャリア（またはデジタル記憶媒体、またはコンピュータ読み取り可能な媒体）である。
データキャリア、デジタル記憶媒体、または記録されたメディアは、通常、有形および／または非一時的である。

【0091】

したがって、本発明の方法のさらなる実施形態は、本明細書に記載の方法の１つを実行するためのコンピュータプログラムを表すデータストリームまたは信号のシーケンスである。
データストリームまたは信号シーケンスは、例えば、インターネットなどのデータ通信接続を介して転送されるように構成されてもよい。

【0092】

さらなる実施形態は、本明細書に記載の方法の１つを実行するように構成または適合された処理手段、例えばコンピュータ、またはプログラム可能なロジックデバイスを含む。

【0093】

さらなる実施形態は、本明細書に記載の方法の１つを実行するためのコンピュータプログラムをインストールしたコンピュータを含む。

【0094】

本発明によるさらなる実施形態は、本明細書に記載の方法の１つを実行するためのコンピュータプログラムを受信機に（例えば、電子的または光学的に）転送するように構成された装置またはシステムを含む。
受信機は、例えば、コンピュータ、モバイルデバイス、メモリデバイスなどであり得る。
装置またはシステムは、例えば、コンピュータプログラムを受信機に転送するためのファイルサーバを備えてもよい。

【0095】

一部の実施形態では、プログラム可能なロジックデバイス（例えば、フィールドプログラマブルゲートアレイ）を使用して、本明細書に記載の方法の機能の一部またはすべてを実行することができる。
一部の実施形態では、フィールドプログラマブルゲートアレイは、本明細書に記載の方法の１つを実行するためにマイクロプロセッサと協働してもよい。
一般に、これらの方法は、任意のハードウェア装置によって実行されることが好ましい。

【0096】

本明細書で説明する装置は、ハードウェア装置を使用して、またはコンピュータを使用して、またはハードウェア装置とコンピュータの組み合わせを使用して実装することができる。

【0097】

本明細書に記載の装置、または本明細書に記載の装置の任意のコンポーネントは、少なくとも部分的にハードウェアおよび／またはソフトウェアにおいて実装することができる。

【0098】

本明細書で説明される方法は、ハードウェア装置を使用して、またはコンピュータを使用して、またはハードウェア装置とコンピュータの組み合わせを使用して実行することができる。

【0099】

本明細書に記載の方法、または本明細書に記載の装置の任意のコンポーネントは、少なくとも部分的にハードウェアおよび／またはソフトウェアによって実行することができる。

【0100】

上述の実施形態は、本発明の原理の単なる例示である。
本明細書に記載の構成および詳細の修正および変更は、当業者には明らかであることを理解されたい。
したがって、本明細書の実施形態の説明および解釈として提示される特定の詳細によってではなく、差し迫った特許請求の範囲によってのみ制限されることが意図されている。

【図1】

【図2】

【図3】