セッションネゴシエーションのための方法及び装置
セルラー通信システムにおける第１のクライアントと第２のクライアントとの間でのセッションネゴシエーションを行う方法において、前記第１のクライアントと前記第２のクライアントとが、セッション用の第１のコーデックタイプをネゴシエートし、かつ同意するＳ１０。次に、前記第１のクライアントと前記第２のクライアントが、前記セッションを開始し、前記第１のコーデックタイプに従ってメディアデータフレームを交換するＳ２０。続いて、前記開始されたセッション中に、前記第１のクライアントと前記第２のクライアントとの少なくとも一方が、少なくとも１つの後続のメディアデータフレームにおける第２のコーデックタイプに対する指示を提供するＳ３０。そして、前記指示の受信及び認識に応じて、前記第１のクライアントと前記第２のクライアントの一方が、次のメディアデータフレームにおいて、前記第２のコーデックタイプに切り替え、それによって、前記第１のクライアントと前記第２のクライアントとが、前記第２のコーデックタイプを利用して後続のメディアデータフレームを交換することを可能にする。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、一般的には、セルラー音声セッションに関するものであり、特に、そのようなセッションのためのメディアフォーマットのネゴシエーションに関するものである。
【背景技術】
【０００２】
３ＧＰＰは、３Ｇネットワークにおけるボイスサービス用の必須の音声コーデックとして、ＡＭＲ及びＡＭＲ−ＷＢを規定している。これらのコーデックは、ＩＭＳを介する３ＧＰＰマルチメディアテレフォニー内で規定される３ＧＰＰ ＶｏＩＰサービスに対しても必須となっている。メディア処理及び対話のための支配的な仕様には、３ＧＰＰ ＴＳ２６．１１４がある。これらのコーデックの必須の状況に関わらず、新規のボイスコーデックを規定することが３ＧＰＰ内で現在も要望されていて、この新規のボイスコーデックとは、ＡＭＲ−ＷＢで可能なこと以上により高度のサービスを実現可能とするものである。
【０００３】
しかしながら、新規の音声コーデックを音声通信システムに導入することは、いくつかの観点では問題がある可能性がある。１つの問題には、その新規のコーデックとは別に、既存の３ＧＰＰコーデック群だけあるいはそれらの１つだけ、例えば、ＡＭＲ−ＷＢをサポートする従来の機器の設置基盤を常に用意する必要があることである。これは、相互運用性の問題を招く可能性がある。この相互運用性の問題とは、システム内に適切なメカニズムを実装しない限り、新規の機器と従来の機器との間で通信ができないことである。この問題に対処するための従来の方法には、例えば、メディアゲート内にトランスコーダを提供することである。ここで、このメディアゲートウェイは、新規のコーディングフォーマットと旧来のコーディングフォーマットとの間の変換を行うものである。あるいは、この問題に対処するための従来の方法には、新規の端末における新規のコーデックとは別に従来の機器のコーデックを提供することである。ここで、新規の端末とは、従来の端末との接続が確立される場合に従来のコーディングフォーマットを選択することが可能なものである。後者の方法は、両方の端末をサポートする共通のコーデックを識別する実際の音声接続の前に端末間でケイパビリティの交換を行うことを要求する。ＩＭＳ内では、セッション記述プロトコル（ＳＤＰ） ＩＥＴＦ ＲＦＣ４５６６が、このケイパビリティ交換を実行するために使用される。
【０００４】
新規のコーデックを通信システムに導入する場合の相互運用性を保証するための上述の方法は、可能性だけでなく、様々な欠点を有している。トランスコーダを提供することは、追加する機器によって、ネットワークへの投資コスト及びメンテナンスコストを生じさせることを意味する。トランスコーダによる処理は、望ましくない音声品質低下にも関係する。発呼の前に端末間でのケイパビリティ交換を使用することはかなり洗練された方法であるが、常に可能であるとは限らない。常に可能であるとは限らない例には、複数人による会議や、ＭＴＳＩをサポートすることなくセルへローミングする移動ユーザに伴うハンドオーバの状況、ボイスメッセージング等がある。端末の実装の観点からも、新規のコーデックと従来のコーデックの完全なセットに対するサポートを提供することも望ましくない場合がある。これは、実装コスト及び技術のライセンス供与のコストが増加する可能性あるからである。
【０００５】
ここで、上述の問題を回避するために、好適なソリューションには、新規のコーデックに、従来のコーデックの（少なくとも）１つと相互運用可能なビットストリームを埋め込むことである。コーデックレベルでのこのような類のビットストリームの「埋込」は、相互運用性に対する必要な条件である一方で、システムレベルでの相互運用性を達成するための要件を満足するための更なる態様が必要とされる。２つの更なる必要な態様には、ＳＤＰシグナリング互換性とビットストリームトランスポートフォーマットの互換性がある。ＳＤＰケイパビリティネゴシエーションに関しては、トランスペアレントな方法で新規のデバイスと従来のデバイスとの間をＳＤＰケイパビリティネゴシエーションができることが要望される。このトランスペアレントな方法とは、新規コーデックを依然として認識していない従来の機器が新規のデバイスと音声サービスセッションを確立できることを意味する。
【発明の概要】
【発明が解決しようとする課題】
【０００６】
３ＧＰＰ ＭＴＳＩの場合での音声ビットストリームデータに対して使用されるトランスポートフォーマットは、リアルタイムアプリケーション（ＲＴＰ） ＩＥＴＦ ＲＦＣ ３５５０用のトランスポートプロトコルに対するＩＥＴＦ仕様と、音声コーデック専用音声ペイロードフォーマットの仕様に従う。ここで、ＡＭＲとＡＭＲ−ＷＢの場合、この使用は、ＩＥＴＦ ＲＦＣ ４８６７である。明らかなことは、従来の端末は専用音声ペイロードフォーマットに依存し、また、別の（新規の）フォーマットに従う音声ビットスリームを作成あるいは適切に受信することができないことである。
【０００７】
上述の問題及び要件のために、トランスペアレントな方法で新規のデバイスと従来のデバイスとの間でセッションネゴシエーションを実現可能にするための要望が存在する。
【課題を解決するための手段】
【０００８】
本発明は、既存のセッションネゴシエーション手順を再使用することを可能にするために、進行中のセッション中に新規のコーデックタイプをネゴシエートすることを可能にするための方法を提供する。
【０００９】
基本的には、セルラー通信システムにおける第１のクライアントと第２のクライアントとの間でのセッションネゴシエーションを行う方法は、以下のステップ群を備える。第１のインスタンスでは、前記第１のクライアントと前記第２のクライアントとが、セッション用の第１のコーデックタイプをネゴシエートし、かつ同意するＳ１０。次に、このセッションが開始され、メディアデータフレームが、前記第１のコーデックタイプに従って前記第１のクライアントと前記第２のクライアントとの間で交換されるＳ２０。続いて、そのセッション中に、前記第１のクライアントと前記第２のクライアントとの内の少なくとも一方が、少なくとも１つの後続のメディアデータフレームにおける第２のコーデックタイプに対する指示を提供するＳ３０。そして、提供される指示の受信及び認識に応じて、前記第１のクライアントと前記第２のクライアントの内の他方が、次のメディアデータフレームにおいて、前記第２のコーデックタイプに切り替えＳ４０、それによって、前記第１のクライアントと前記第２のクライアントとが、前記第２のコーデックタイプを利用して後続のメディアデータフレームを交換することを可能にする。
【００１０】
本発明の更なる態様に従えば、セルラー通信システムにおけるクライアントは、別のクライアントとのセッション用の第１のコーデックタイプについてネゴシエートし同意する手段１０と、セッションを開始し、前記第１のコーデックタイプに従ってメディアデータフレームを交換する手段２０を含んでいる。加えて、前記開始されるセッション中に、第２のコーデックタイプに対する指示を少なくとも１つの後続のメディアデータフレームに提供する手段３０が、クライアントに提供される。そして、クライアントは、対応する指示の受信及び認識に応じて、次のメディアデータフレームで前記第２のコーデックタイプに切り替える手段４０を含んでいて、それによって、当該クライアントと前記別のクライアントとが前記第２のコーデックタイプを利用して後続のメディアデータフレームを交換することを可能にする。
【００１１】
本発明の効果は、以下の点を含んでいる。
【００１２】
本発明の実施形態に従うセッションネゴシエーション用の２段階の方法を使用する利点は、ＳＩＰ／ＳＤＰシグナリングプレーン上で表現される後方互換性によるである。通常のＡＭＲ−ＷＢセッションのように見えるが、これに代えて、新規の音声コーデックを使用する可能性のためのＣＭＲシグナリング「プローブ」となる。ＣＭＲビットの特性はこの後方互換性を実現する。これは、従来のデコーダはＣＭＲリクエストあるいは「新規」のＦＴを伴う受信フレームを理解しない場合、自動的にそれらを却下するからである。
【図面の簡単な説明】
【００１３】
【図１】周知のＲＴＰペイロードフォーマットを示す図である。
【図２】本発明の実施形態のシグナリングを示す図である。
【図３】本発明の更なる実施形態のシグナリングを示す図である。
【図４】パケットフォーマットを示す図である。
【図５】本発明に従う方法の実施形態に対するフローチャートである。
【図６】本発明に従う方法の更なる実施形態に対するフローチャートである。
【図７】図６のフローチャートの続きを示すフローチャートである。
【図８】本発明の実施形態に従うユーザ機器を示す図である。
【発明を実施するための形態】
【００１４】
略語
３ＧＰＰ 第３世代パートナシッププロジェクト
ＡＭＲ 適応多重レート
ＡＭＲ−ＷＢ ＡＭＲワイドバンド
ＣＭＲ コーデックモードリクエスト
ＥＶＳ 拡張ボイスサービス
ＩＭＳ ＩＰマルチメディアサブシステム
ＭＴＳＩ ＩＭＳ用マルチメディアテレフォニーサービス
ＲＴＰ リアルタイムトランスポートプロトコル
ＲＴＣＰ リアルタイムトランポート制御プロトコル
ＲＴＣＰ＿ＡＰＰ アプリケーション定義に従うリアルタイムトランポート制御プロトコル
ＳＤＰ セッション記述プロトコル
ＳＩＰ セッション開始プロトコル
ＳＳＲＣ 同期ソース（Synchornization SouRCe）
ＵＥ ユーザ機器
本発明は、上述の問題を解消するための方法を記載する。これは、ＡＭＲ−ＷＢに基づくＭＴＳＩをサポートする従来の端末と、新規のビットストリームで相互運用可能なコーデックに基づいてＭＴＳＩを展開する新規の端末との間でシステムレベルの相互運用性を可能にすることになる。特に、本発明は、コーデックタイプシグナリングとその用途に対するソリューションを定義し、これは、ＡＭＲ−ＷＢの既存の設備と完全な互換性がある一方で、３ＧＰＰにおいて任意の新規のビットストリーム埋込音声コーデックの互換性の完全な使用を依然として実現可能にする。
【００１５】
本発明の利点を更に説明するために、従来技術の詳細説明を以下に示す。
【００１６】
サービスに対する通常のあるいは従来のセッションネゴシエーション手順において、セッション用のコーデック選択が、制御プレーンシグナリング中、典型的には、ＳＩＰとＳＤＰの中で実行される。ここで、その重要なことは、動作の後方互換モードを有する新規のコーデックが、既に存在して装備されているセッションネゴシエーションメカニズムを再使用できることである。そうでない場合、既存のコーデックとのビットストリーム相互運用性は使用されないことになる。これは、一致するコーデックタイプあるいはコーデックコンフィグレーションが検出されない場合にはセッションネゴシエーションが失敗することになるからである。
【００１７】
基本的には、本発明は、ＳＩＰ／ＳＤＰを使用するセッションネゴシエーション用の既存のシグナリングスキームを再使用し、かつＡＭＲ−ＷＢペイロードフォーマットで利用可能なシグナリングの範囲で再使用するための２つのステップによる方法を開示する。基本の概念は、ＳＩＰ／ＳＤＰにおけるセッションを標準ＡＷＲ−ＷＢセッションとしてセットアップすることであり、これは、場合によっては、後方互換性の程度に依存して制限されたコーデックモード（即ち、すべてのモードあるいはいくつかの選択されたモード）を使用する。続いて、新規のコーデックについての指示がペイロードパケット内に導入され、そうすることで、受信クライアントに、新規のセッションネゴシエーション手順を必要とさせることなく、可能性のある新規のコーデックタイプを識別しかつ利用することを可能にする。
【００１８】
本発明の実施形態の説明はＡＭＲ−ＷＢペイロードフォーマットで使用可能な構成に依存するので、このペイロードフォーマットの簡単な説明を、図１のＲＴＰパケットを参照しながら以下に示す。このペイロードフォーマットは、ＡＭＲとＡＭＲ−ＷＢの両方に対して同一である。この詳細については、文献［１］を参照されたい。
【００１９】
ＲＴＰパケットの最初の１２バイトは汎用ＲＴＰヘッダであり、ＡＭＲ専用ペイロードヘッダはＣＭＲビット、Ｆビット、ＦＴビット及ぶＱビットを含んでいる。ＡＭＲデータは、特に、この場合には、ｄ（０）、．．．、ｄ（２４３）で示される。最後のＰビットはパディングビットである。尚、このパケットは、ペイロード内の１つのＡＭＲパケットが１２．２ｋｂｐｓモードで符号化される場合の一例である。また、帯域幅が有効な形式のペイロードフォーマットが使用され、別のオプションでは、いくつかの追加のパディングビットがペイロードフォーマットヘッダ内にある場合にはオクテット配列を使用する。フィールドＦ、ＦＴ及びＱは、目次（ToC: Table of Contents（テーブルオブコンテンツ））と呼ばれる１つのエンティティにグループ化される。これは、パケット内の音声フレーム単位で一度に送信される。ＣＭＲフィールドは、パケット内に存在する音声フレームがどんなに多くても、各ＲＴＰパケットで一度に送信される。ペイロードヘッダ内のＡＭＲ固有シグナリングビットは以下のようになる。
【００２０】
ＣＭＲ− コーデックモードリクエスト（codec mode requests）の略称であり、これは、一方向で符号化及び送信を行う場合に使用するパケットの受信機に対する送信機のモードリクエストを符号化する。モードリクエストの符号化は、以下で説明するフレームタイプに従って実行される。
【００２１】
Ｆ− 別の音声フレームが、現在のＴｏＣを記述するフレームに後続するかどうかを示すものである。
【００２２】
ＦＴ− フレームタイプの略称である。これは、現在のフレームを符号化するために使用されたコーデックモードが何であるかを識別するものである。フレームタイプの符号化は、以下で説明するフレームタイプに従って実行される。
【００２３】
Ｑ− フレーム品質インジケータの略称である。これは、フレームがエラーのないものであるかどうかを識別するものである。但し、音声データがＩＰを使用してエンドツーエンドでトランスポートされる場合、配信されるすべての音声フレームがエラーのないものであるということではない。
【００２４】
この実施形態に関連して、ＲＴＰパケットの重要なフィールドはＣＭＲフィールドとＦＴフィールドである。これらのフィールドの両方は、以下の表１及び表２で参照される、ＡＭＲ［２］とＡＭＲ−ＷＢ［３］における表を符号化する。
【００２５】
【表１】
【００２６】
【表２】
【００２７】
尚、ＡＭＲとＡＭＲ−ＷＢの両方で利用可能なフレームタイプが存在し、これは、将来用のために予約されていて、ＡＭＲについてはこれはフレームタイプインデックス１２から１４であり、ＡＭＲ−ＷＢについてはこれはフレームタイプインデックス１０から１３である。
【００２８】
図２を参照すると、本発明に従う方法の基本的な実施形態は、セルラー通信システムにおいて第１のクライアントと第２のクライアントとの間の改良されたセッションネゴシエーションの方法を開示している。Ｓ１０で、これら２つのクライアントはセッション用の第１のコーデックタイプについてネゴシエートして同意し、続いて、Ｓ２０で、セッションを開始して、ネゴシエートした第１のコーデックタイプに従ってメディアデータフレームを交換する。開始されたセッション内でのメディアデータフレームの進行中の交換の間では、Ｓ３０で、第１のクライアントと第２のクライアントの少なくとも一方が、少なくとも１つの後続のメディアデータフレームで第２のコーデックタイプに対する指示を提供する。そして、提供される指示を受信して認識した際には、Ｓ４０で、第１のクライアントと第２のクライアントのもう一方が、次のメディアデータフレームにおいて指示された第２のコーデックタイプに切り替える。これによって、２つのクライアントは、第２のコーデックタイプを利用して後続のメディアデータフレームを交換することが可能になる。
【００２９】
クライアントは、所定数のステータスタイプインジケータが送信されるまで、あるいは対応するステータスタイプインジケータが受信されるまで、いくつかの連続する音声あるいはメディアデータフレームにステータスタイプインジケータを含める。所定数のインジケータが、対応するインジケータをクライアントが受信することなく送信される場合、クライアントは、インジケータの送信を停止し、最初にネゴシエートしたコーデックタイプを使用して送信を維持する。本発明の実施形態に従えば、クライアントは、後続のデータフレームにおいてリクエストされたコーデックタイプを直ちに切り替えることによって受信するステータスインジケータに応答する。しかしながら、少なくとも１つの対応するコーデックタイプインジケータを送信し、その後、リクエストされたコーデックタイプに切り替えることによって、受信するコーデックタイプインジケータに応答することも等しく可能である。
【００３０】
これによって、新規のセッションネゴシエーションを必要とすることがなく、また、新規のコーデック実装デバイスと従来のコーデック実装デバイスとの両方は、最初に交換されたメディアデータフレームにビットストリーム後方互換性があるという条件で、通信することができる。
【００３１】
本明細書で記載される本発明の開示の実施形態の重要な要素は、伝統的なセッション制御プロトコルシグナリング、例えば、メディアコンフィグレーション用のセッションをネゴシエートする場合のＳＩＰ／ＳＤＰと、ペイロードヘッダ内のＣＭＲフィールドでコーデックモード／タイプを信号送信してかつリクエストすることができるものと組み合わせることである。これらの２つのメカニズムを一緒に使用することによって、シグナリングレベルで従来のＡＭＲ−ＷＢ対応クライアントと相互動作することを脅かすことなく新規の音声コーダの使用をネゴシエートすることが可能になる。それゆえ、このセッションネゴシエーションは３つのステップで実行される。
【００３２】
まず、最初に、ＳＩＰ／ＳＤＰを使用して、「通常」のＡＭＲ−ＷＢセッションがネゴシエートされる。ここでは、新規の音声コーデックタイプの使用を指示するシグナリングは実行されない。次に、メディアが、クライアントＡとクライアントＢ（及びその逆）との間でフローすることを開始する場合、新規の音声コーデックタイプをサポートするクライアントがＡＭＲ−ＷＢタイプテーブル（表）において予約されている符号化の１つを使用してコーデックモードリクエスト（ＣＭＲ）を送信する。これは、適切な検出を保証するために第１のＮ個のフレームについて繰り返されることになる。このＮは１から∞の範囲で構成設定可能である。数を限定する理由は他の値でＣＭＲが送信される場合の混同を回避するためである。最後に、クライアントが、新規のコーデックタイプのサポートを示すＣＭＲを受信するとすぐに、新規のコーデックのコーデックモードを使用して、一方のクライアントがそれを復号できることを確実にすることを開始することができる。
【００３３】
コーデックの使用についての「階層的な」シグナリングに伴う主要な利点は、従前の装備を脅かすことなく新規の音声コーデックの装備を実現可能とし、かつシグナリングプレーン上での任意の更新を必要としないことである。
【００３４】
本発明は、ＡＭＲ−ＷＢセッションをネゴシエートする既存の方法の再使用に基づいている。
【００３５】
【表３】
【００３６】
表３は、ＩＭＳマルチメディアテレフォニーにおける典型的なＡＭＲ−ＷＢネゴシエーションの一例を示している。２つの異なるバージョンのＡＭＲ−ＷＢが提案されていて、１つは帯域幅有効ペイロードフォーマット（好ましくは）を使用し、もう１つはオクテット配列のペイロードフォーマットを使用する。ＲＴＰクロックレートは１６ｋＨｚに設定され、１つのオーディオチャネルが使用されることになる。
【００３７】
本発明に従う新規の音声コーデックに対するセッションネゴシエーションは、後方互換性がすべてのＡＭＲ−ＷＢモードに対して配備されている場合に同一のものとみなすことになる。一定のモード（群）だけに対して制限された後方互換性が存在する場合、モードの設定制限が信号通信されることになる。次に、ＳＤＰは、例示の指示がモード設定１、２に対してのみサポートすることに変更する。
【００３８】
【表４】
【００３９】
ＳＤＰの使用の種類は、ＡＭＲ−ＷＢをサポートする任意の２つのクライアントの間のセッションをセットアップし、また、これは、新規の音声コーデックに対する任意のサポートを示すことはない。
【００４０】
本発明の実施形態に従うネゴシエーション手順の第２の段階は、表２の空きフレームのタイプのインデックスの使用を行うことになる。この例では、フレームタイプ１２は新規の音声コーデックに対するサポートを示すために使用されているが、他のフレームタイプも使用することができる。セッションネゴシエーションのこの部分は、メディアフロー内の帯域内（インバンド：in-band）で実行されるので、ネゴシエーションが実行可能である専用のプロービング（probing）期間が設定される。新規の音声モードがプロービング期間内部で発生していることを示すＣＭＲビットの共同の交換がない場合、ネゴシエーションの第２の段階は失敗していると想定され、また、そのセッションは標準的なＡＭＲ−ＷＢセッションとして取り扱われることになる。
【００４１】
図３に示される例示のシグナリングスキームでは、全二重セッションが想定されることに注意されたい。この全二重セッションでは、クライアントの両方が音声データを送信し、それによって、自動的に、インバンドＣＭＲビット用のシグナリングチャネルを作成するものである。しかしながら、半二重フローの場合（図４参照）、つまり、メディアが一方向に流れる場合、これは不可能である。これらの場合、ＣＭＲビットを搬送する他の手段が、２段階のネゴシエーションを成功させるために使用されることを必要とする。このことを実現するための様々な方法が存在するが、その１つには、３ＧＰＰ［４］におけるＭＴＳＩサービスとの直接互換がある方法が１つ存在する。例示のシグナリングでは、第１のクライアントＵＥ１は一般的なＳＤＰ オファー（ＯＦＦＥＲ：提案） ＡＭＲ−ＷＢを第２のクライアントＵＥ２へ送信し、これは、２００ ＯＫで応答して、提案されるコーデックタイプを受け入れる。続いて、セッションが開始され、メディアデータフレームであるＲＴＰ ＭＥＤＩＡ（メディア），ＦＴ８が、２つのクライアントとの間で交換される。第１のクライアントは、次に、ＣＭＲ＝１２を含めることによって、Ｎ個の連続するメディアデータフレームに、第２のコーデックタイプ用の指示を含める。コーデックタイプの指示を受信し及び認識することで、第２のユーザ機器ＵＥ２は、ＣＭＲ＝１２を含むＮ個のメディアデータフレームで応答する。そして、２つのクライアントは、完全に新規なセッションネゴシエーション手順を開始することなく、現在同意されている第２のコーデックタイプを使用してメディアデータの交換を開始することができる。
【００４２】
ＣＭＲに基づくネゴシエーションに対する代替のソリューションは、ＣＭＲビットを搬送するためにＲＴＣＰ−ＡＰＰを使用することである。このメカニズムに伴う更なる利点は、半二重セッションに対しても動作することである。図４及び図５を参照されたい。ＭＴＳＩは、音声データがフローしている場合のセッション中に使用されるべき適合パラメータを搬送するための専用のＡＰＰレポートを定義している。この手順は、基本的には、いくつかの点を除いて、図５を参照して説明される手順と同一である。半二重セッションは、メディアフローの逆方向にＲＴＣＰレポートを送信することになるので、これは、発生するシグナリングに対する可能性を広げる。ここで、ＣＭＲリクエスト用のＲＴＣＰ−ＡＰＰエンコーディングは、インバンド形式と同一のものであり、そうすることで、同一の行動を確認することができることに注意されたい。ＲＴＣＰを使用して送信されるＣＭＲリクエストの速度に１つの違いがあり、これは、ＲＴＣＰ送信ルールによって設定される制限の１つである。しかしながら、この制限の最大の結論は、ネゴシエーションの第２の段階に対するセットアップ時間がわずかに延びることであり、最後には同一の正常な速度になる。
【００４３】
図６及び図７を参照して、本発明に従う方法の特定の実施形態を説明する。この例では、ＣＭＲ＝１２は新規のコーデックに対する代替に相当し、パラメータＮを構成設定可能である（ほぼ１０程度の値が使用されることになる）。ＡＭＲ−ＷＢへの拡張、即ち、新規の後方互換音声コーデックは、ＥＶＳと呼ばれる。ここで、ＣＭＲ値は、ＡＭＲ−ＷＢフレームタイプのインデックスで現在利用可能な任意の値とすることができることに注意されたい。
【００４４】
特定の実施形態はＡＭＲ−ＷＢとＥＶＳを使用しているが、これは第１のコーデックタイプ及び第２のコーデックタイプの一例であり、同一の方法を他の音声コーデックタイプの組み合わせにも等しく利用することができることは明らかである。
【００４５】
最初に、ＡＭＲ−ＷＢの場合、クライアントあるいはユーザ機器は、第１のコーデックタイプを含むインビテーション（招待）を伴うセッションネゴシエーション信号を送信する。次に、クライアントがそのインビテーションに対する肯定応答（２００ ＯＫ）を受信する場合、クライアントは、そのネゴシエーションされるコーデックタイプを使用してメディアフレームの送信／交換を開始することを継続する。Ｎ個の連続するデータフレームまで、クライアントは第２のコーデックタイプを使用することができることを示すために、ＣＭＲ＝１２を含める。同時に、クライアントは、受信する音声パケット、及び対応する指示用のＲＴＰＣＰ−ＡＰＰレポートの少なくとも一方を監視する。対応する指示を受信すると、クライアントは、第２のコーデックタイプ、例えば、ＥＶＳモードに従ってデータフレームを送信することを開始する。このような指示が提供されない場合、クライアントは、従前にネゴシエートされたコーデックタイプ、例えば、ＡＭＲ−ＷＢモードを維持する。
【００４６】
ここで、図６及び図７のフローは一例であり、ＥＶＳネゴシエーションの開始は、２００ ＯＫが受信された直後であることが必須ではなく、セッション中の任意の時間に実行することができることに注意されたい。また、テスト「ＣＭＲ＝１２？」は、厳密なテストにしなければならないわけではない。このことを実行するための代替の方法は、例えば、以下のものがある。
【００４７】
１）リモートクライアント（ＥＶＳ用のＣＭＲリクエストを受信するクライアント）は、ＥＶＳフレームタイプ（ＦＴ＝１２あるいは１３、あるいはそれ以外）を使用して直ちに開始することができる。このことは、ＥＶＳが可能であり、また、「ＣＭＲ＝１２」を指示するために「ＣＭＲ＝１２」を送信することが必要ないことを宣言することにもなる。
【００４８】
２）１つの構成には、「ＦＴ＝１２」が「ＥＶＳケイパビリティ用の問い合わせ／招待」であること、また、「ＦＴ＝１３」が確認応答であることを定義することができる。
【００４９】
図８を参照して、本発明に従うユーザ機器あるいはクライアントの実施形態を説明する。ユーザ機器あるいはクライアントについての１つの特定の態様は、リクエストされている新規のあるいは第２のコーデックタイプについての指示の受信を、認識して動作することができることが必要であることである。このことのために、ユーザ機器は、信号を送受信することを可能にするための汎用入力／出力ユニットＩ／Ｏ、別のクライアントとのセッション用の第１のコーデックタイプについてネゴシエートしかつ同意するためのネゴシエーションユニット１０と、ネゴシエートされた第１のコーデックタイプに従って別のユーザ機器とのセッションを開始し、メディアデータフレームを交換するためのセッションユニット２０とを含んでいる。また、クライアントは、開始されたセッション中に、第２のコーデックタイプのための指示を少なくとも１つの後続のメディアデータフレームで提供するためのコーデック切替ユニット３０を含んでいる。そして、クライアントは、対応する指示を受信し及び認識すると、次のメディアデータフレームで指示された第２のコーデックタイプへ切り替えるためのユニット４０を含み、これによって、第１のクライアントと第２のクライアントに第２のコーデックタイプを利用して後続のメディアデータフレームを交換することを可能にする。つまり、ユーザ機器あるいはクライアントはコーデック切替指示を提供するだけでなく、対応する指示を受信しそれに応答するように適合されている。上述のユニット群は、典型的には、１つ以上のハードウェアプロセッサあるいは、本開示の方法の開示される実施形態のステップ群を実行するように構成されているソフトウェアアルゴリズムによって実現可能である。加えて、上述のクライアントあるいはユーザ機器の機能は、電気通信システム内のノードにおいて実現することができる。
【００５０】
開示される方法及び構成に対する前提条件は、データパケット、例えば、ＲＴＰパケットが、ビットストリーム埋込後方互換コーデックフォーマットを有することである。本発明はパケット交換システムの内容で説明されるが、回線交換システムにも等しく適用可能である。
【００５１】
本発明の効果は、以下のことを含んでいる。
【００５２】
本発明の実施形態に従うセッションネゴシエーション用の２段階の方法を使用する利点は、ＳＩＰ／ＳＤＰシグナリングプレーン上で表現される後方互換性によるものである。通常のＡＭＲ−ＷＢセッションのように見えるが、これに代えて、新規の音声コーデックを使用する可能性のためのＣＭＲシグナリング「プローブ」となる。ＣＭＲビットの特性はこの後方互換性を実現する。これは、従来のデコーダはＣＭＲリクエストあるいは「新規」のＦＴを伴う受信フレームを理解しない場合、自動的にそれらを却下するからである。
【００５３】
文献群
［１］ ＩＥＴＦ ＲＦＣ ４８６７
［２］ ３ＧＰＰ ＴＳ２６．１０１、「適合マルチレート（ＡＭＲ）音声コーデックフレーム構造」
［３］ ３ＧＰＰ ＴＳ２６．２０１、「適合マルチレート−ワイドバンド（ＡＭＲ−ＷＢ）音声コーデック、フレーム構造」
［４］ ３ＧＰＰ ＴＳ２６．１１４、「ＩＰマルチメディアサブシステム（ＩＭＳ）、マルチメディアテレフォニー、メディア処理及び対話」
【技術分野】
【０００１】
本発明は、一般的には、セルラー音声セッションに関するものであり、特に、そのようなセッションのためのメディアフォーマットのネゴシエーションに関するものである。
【背景技術】
【０００２】
３ＧＰＰは、３Ｇネットワークにおけるボイスサービス用の必須の音声コーデックとして、ＡＭＲ及びＡＭＲ−ＷＢを規定している。これらのコーデックは、ＩＭＳを介する３ＧＰＰマルチメディアテレフォニー内で規定される３ＧＰＰ ＶｏＩＰサービスに対しても必須となっている。メディア処理及び対話のための支配的な仕様には、３ＧＰＰ ＴＳ２６．１１４がある。これらのコーデックの必須の状況に関わらず、新規のボイスコーデックを規定することが３ＧＰＰ内で現在も要望されていて、この新規のボイスコーデックとは、ＡＭＲ−ＷＢで可能なこと以上により高度のサービスを実現可能とするものである。
【０００３】
しかしながら、新規の音声コーデックを音声通信システムに導入することは、いくつかの観点では問題がある可能性がある。１つの問題には、その新規のコーデックとは別に、既存の３ＧＰＰコーデック群だけあるいはそれらの１つだけ、例えば、ＡＭＲ−ＷＢをサポートする従来の機器の設置基盤を常に用意する必要があることである。これは、相互運用性の問題を招く可能性がある。この相互運用性の問題とは、システム内に適切なメカニズムを実装しない限り、新規の機器と従来の機器との間で通信ができないことである。この問題に対処するための従来の方法には、例えば、メディアゲート内にトランスコーダを提供することである。ここで、このメディアゲートウェイは、新規のコーディングフォーマットと旧来のコーディングフォーマットとの間の変換を行うものである。あるいは、この問題に対処するための従来の方法には、新規の端末における新規のコーデックとは別に従来の機器のコーデックを提供することである。ここで、新規の端末とは、従来の端末との接続が確立される場合に従来のコーディングフォーマットを選択することが可能なものである。後者の方法は、両方の端末をサポートする共通のコーデックを識別する実際の音声接続の前に端末間でケイパビリティの交換を行うことを要求する。ＩＭＳ内では、セッション記述プロトコル（ＳＤＰ） ＩＥＴＦ ＲＦＣ４５６６が、このケイパビリティ交換を実行するために使用される。
【０００４】
新規のコーデックを通信システムに導入する場合の相互運用性を保証するための上述の方法は、可能性だけでなく、様々な欠点を有している。トランスコーダを提供することは、追加する機器によって、ネットワークへの投資コスト及びメンテナンスコストを生じさせることを意味する。トランスコーダによる処理は、望ましくない音声品質低下にも関係する。発呼の前に端末間でのケイパビリティ交換を使用することはかなり洗練された方法であるが、常に可能であるとは限らない。常に可能であるとは限らない例には、複数人による会議や、ＭＴＳＩをサポートすることなくセルへローミングする移動ユーザに伴うハンドオーバの状況、ボイスメッセージング等がある。端末の実装の観点からも、新規のコーデックと従来のコーデックの完全なセットに対するサポートを提供することも望ましくない場合がある。これは、実装コスト及び技術のライセンス供与のコストが増加する可能性あるからである。
【０００５】
ここで、上述の問題を回避するために、好適なソリューションには、新規のコーデックに、従来のコーデックの（少なくとも）１つと相互運用可能なビットストリームを埋め込むことである。コーデックレベルでのこのような類のビットストリームの「埋込」は、相互運用性に対する必要な条件である一方で、システムレベルでの相互運用性を達成するための要件を満足するための更なる態様が必要とされる。２つの更なる必要な態様には、ＳＤＰシグナリング互換性とビットストリームトランスポートフォーマットの互換性がある。ＳＤＰケイパビリティネゴシエーションに関しては、トランスペアレントな方法で新規のデバイスと従来のデバイスとの間をＳＤＰケイパビリティネゴシエーションができることが要望される。このトランスペアレントな方法とは、新規コーデックを依然として認識していない従来の機器が新規のデバイスと音声サービスセッションを確立できることを意味する。
【発明の概要】
【発明が解決しようとする課題】
【０００６】
３ＧＰＰ ＭＴＳＩの場合での音声ビットストリームデータに対して使用されるトランスポートフォーマットは、リアルタイムアプリケーション（ＲＴＰ） ＩＥＴＦ ＲＦＣ ３５５０用のトランスポートプロトコルに対するＩＥＴＦ仕様と、音声コーデック専用音声ペイロードフォーマットの仕様に従う。ここで、ＡＭＲとＡＭＲ−ＷＢの場合、この使用は、ＩＥＴＦ ＲＦＣ ４８６７である。明らかなことは、従来の端末は専用音声ペイロードフォーマットに依存し、また、別の（新規の）フォーマットに従う音声ビットスリームを作成あるいは適切に受信することができないことである。
【０００７】
上述の問題及び要件のために、トランスペアレントな方法で新規のデバイスと従来のデバイスとの間でセッションネゴシエーションを実現可能にするための要望が存在する。
【課題を解決するための手段】
【０００８】
本発明は、既存のセッションネゴシエーション手順を再使用することを可能にするために、進行中のセッション中に新規のコーデックタイプをネゴシエートすることを可能にするための方法を提供する。
【０００９】
基本的には、セルラー通信システムにおける第１のクライアントと第２のクライアントとの間でのセッションネゴシエーションを行う方法は、以下のステップ群を備える。第１のインスタンスでは、前記第１のクライアントと前記第２のクライアントとが、セッション用の第１のコーデックタイプをネゴシエートし、かつ同意するＳ１０。次に、このセッションが開始され、メディアデータフレームが、前記第１のコーデックタイプに従って前記第１のクライアントと前記第２のクライアントとの間で交換されるＳ２０。続いて、そのセッション中に、前記第１のクライアントと前記第２のクライアントとの内の少なくとも一方が、少なくとも１つの後続のメディアデータフレームにおける第２のコーデックタイプに対する指示を提供するＳ３０。そして、提供される指示の受信及び認識に応じて、前記第１のクライアントと前記第２のクライアントの内の他方が、次のメディアデータフレームにおいて、前記第２のコーデックタイプに切り替えＳ４０、それによって、前記第１のクライアントと前記第２のクライアントとが、前記第２のコーデックタイプを利用して後続のメディアデータフレームを交換することを可能にする。
【００１０】
本発明の更なる態様に従えば、セルラー通信システムにおけるクライアントは、別のクライアントとのセッション用の第１のコーデックタイプについてネゴシエートし同意する手段１０と、セッションを開始し、前記第１のコーデックタイプに従ってメディアデータフレームを交換する手段２０を含んでいる。加えて、前記開始されるセッション中に、第２のコーデックタイプに対する指示を少なくとも１つの後続のメディアデータフレームに提供する手段３０が、クライアントに提供される。そして、クライアントは、対応する指示の受信及び認識に応じて、次のメディアデータフレームで前記第２のコーデックタイプに切り替える手段４０を含んでいて、それによって、当該クライアントと前記別のクライアントとが前記第２のコーデックタイプを利用して後続のメディアデータフレームを交換することを可能にする。
【００１１】
本発明の効果は、以下の点を含んでいる。
【００１２】
本発明の実施形態に従うセッションネゴシエーション用の２段階の方法を使用する利点は、ＳＩＰ／ＳＤＰシグナリングプレーン上で表現される後方互換性によるである。通常のＡＭＲ−ＷＢセッションのように見えるが、これに代えて、新規の音声コーデックを使用する可能性のためのＣＭＲシグナリング「プローブ」となる。ＣＭＲビットの特性はこの後方互換性を実現する。これは、従来のデコーダはＣＭＲリクエストあるいは「新規」のＦＴを伴う受信フレームを理解しない場合、自動的にそれらを却下するからである。
【図面の簡単な説明】
【００１３】
【図１】周知のＲＴＰペイロードフォーマットを示す図である。
【図２】本発明の実施形態のシグナリングを示す図である。
【図３】本発明の更なる実施形態のシグナリングを示す図である。
【図４】パケットフォーマットを示す図である。
【図５】本発明に従う方法の実施形態に対するフローチャートである。
【図６】本発明に従う方法の更なる実施形態に対するフローチャートである。
【図７】図６のフローチャートの続きを示すフローチャートである。
【図８】本発明の実施形態に従うユーザ機器を示す図である。
【発明を実施するための形態】
【００１４】
略語
３ＧＰＰ 第３世代パートナシッププロジェクト
ＡＭＲ 適応多重レート
ＡＭＲ−ＷＢ ＡＭＲワイドバンド
ＣＭＲ コーデックモードリクエスト
ＥＶＳ 拡張ボイスサービス
ＩＭＳ ＩＰマルチメディアサブシステム
ＭＴＳＩ ＩＭＳ用マルチメディアテレフォニーサービス
ＲＴＰ リアルタイムトランスポートプロトコル
ＲＴＣＰ リアルタイムトランポート制御プロトコル
ＲＴＣＰ＿ＡＰＰ アプリケーション定義に従うリアルタイムトランポート制御プロトコル
ＳＤＰ セッション記述プロトコル
ＳＩＰ セッション開始プロトコル
ＳＳＲＣ 同期ソース（Synchornization SouRCe）
ＵＥ ユーザ機器
本発明は、上述の問題を解消するための方法を記載する。これは、ＡＭＲ−ＷＢに基づくＭＴＳＩをサポートする従来の端末と、新規のビットストリームで相互運用可能なコーデックに基づいてＭＴＳＩを展開する新規の端末との間でシステムレベルの相互運用性を可能にすることになる。特に、本発明は、コーデックタイプシグナリングとその用途に対するソリューションを定義し、これは、ＡＭＲ−ＷＢの既存の設備と完全な互換性がある一方で、３ＧＰＰにおいて任意の新規のビットストリーム埋込音声コーデックの互換性の完全な使用を依然として実現可能にする。
【００１５】
本発明の利点を更に説明するために、従来技術の詳細説明を以下に示す。
【００１６】
サービスに対する通常のあるいは従来のセッションネゴシエーション手順において、セッション用のコーデック選択が、制御プレーンシグナリング中、典型的には、ＳＩＰとＳＤＰの中で実行される。ここで、その重要なことは、動作の後方互換モードを有する新規のコーデックが、既に存在して装備されているセッションネゴシエーションメカニズムを再使用できることである。そうでない場合、既存のコーデックとのビットストリーム相互運用性は使用されないことになる。これは、一致するコーデックタイプあるいはコーデックコンフィグレーションが検出されない場合にはセッションネゴシエーションが失敗することになるからである。
【００１７】
基本的には、本発明は、ＳＩＰ／ＳＤＰを使用するセッションネゴシエーション用の既存のシグナリングスキームを再使用し、かつＡＭＲ−ＷＢペイロードフォーマットで利用可能なシグナリングの範囲で再使用するための２つのステップによる方法を開示する。基本の概念は、ＳＩＰ／ＳＤＰにおけるセッションを標準ＡＷＲ−ＷＢセッションとしてセットアップすることであり、これは、場合によっては、後方互換性の程度に依存して制限されたコーデックモード（即ち、すべてのモードあるいはいくつかの選択されたモード）を使用する。続いて、新規のコーデックについての指示がペイロードパケット内に導入され、そうすることで、受信クライアントに、新規のセッションネゴシエーション手順を必要とさせることなく、可能性のある新規のコーデックタイプを識別しかつ利用することを可能にする。
【００１８】
本発明の実施形態の説明はＡＭＲ−ＷＢペイロードフォーマットで使用可能な構成に依存するので、このペイロードフォーマットの簡単な説明を、図１のＲＴＰパケットを参照しながら以下に示す。このペイロードフォーマットは、ＡＭＲとＡＭＲ−ＷＢの両方に対して同一である。この詳細については、文献［１］を参照されたい。
【００１９】
ＲＴＰパケットの最初の１２バイトは汎用ＲＴＰヘッダであり、ＡＭＲ専用ペイロードヘッダはＣＭＲビット、Ｆビット、ＦＴビット及ぶＱビットを含んでいる。ＡＭＲデータは、特に、この場合には、ｄ（０）、．．．、ｄ（２４３）で示される。最後のＰビットはパディングビットである。尚、このパケットは、ペイロード内の１つのＡＭＲパケットが１２．２ｋｂｐｓモードで符号化される場合の一例である。また、帯域幅が有効な形式のペイロードフォーマットが使用され、別のオプションでは、いくつかの追加のパディングビットがペイロードフォーマットヘッダ内にある場合にはオクテット配列を使用する。フィールドＦ、ＦＴ及びＱは、目次（ToC: Table of Contents（テーブルオブコンテンツ））と呼ばれる１つのエンティティにグループ化される。これは、パケット内の音声フレーム単位で一度に送信される。ＣＭＲフィールドは、パケット内に存在する音声フレームがどんなに多くても、各ＲＴＰパケットで一度に送信される。ペイロードヘッダ内のＡＭＲ固有シグナリングビットは以下のようになる。
【００２０】
ＣＭＲ− コーデックモードリクエスト（codec mode requests）の略称であり、これは、一方向で符号化及び送信を行う場合に使用するパケットの受信機に対する送信機のモードリクエストを符号化する。モードリクエストの符号化は、以下で説明するフレームタイプに従って実行される。
【００２１】
Ｆ− 別の音声フレームが、現在のＴｏＣを記述するフレームに後続するかどうかを示すものである。
【００２２】
ＦＴ− フレームタイプの略称である。これは、現在のフレームを符号化するために使用されたコーデックモードが何であるかを識別するものである。フレームタイプの符号化は、以下で説明するフレームタイプに従って実行される。
【００２３】
Ｑ− フレーム品質インジケータの略称である。これは、フレームがエラーのないものであるかどうかを識別するものである。但し、音声データがＩＰを使用してエンドツーエンドでトランスポートされる場合、配信されるすべての音声フレームがエラーのないものであるということではない。
【００２４】
この実施形態に関連して、ＲＴＰパケットの重要なフィールドはＣＭＲフィールドとＦＴフィールドである。これらのフィールドの両方は、以下の表１及び表２で参照される、ＡＭＲ［２］とＡＭＲ−ＷＢ［３］における表を符号化する。
【００２５】
【表１】
【００２６】
【表２】
【００２７】
尚、ＡＭＲとＡＭＲ−ＷＢの両方で利用可能なフレームタイプが存在し、これは、将来用のために予約されていて、ＡＭＲについてはこれはフレームタイプインデックス１２から１４であり、ＡＭＲ−ＷＢについてはこれはフレームタイプインデックス１０から１３である。
【００２８】
図２を参照すると、本発明に従う方法の基本的な実施形態は、セルラー通信システムにおいて第１のクライアントと第２のクライアントとの間の改良されたセッションネゴシエーションの方法を開示している。Ｓ１０で、これら２つのクライアントはセッション用の第１のコーデックタイプについてネゴシエートして同意し、続いて、Ｓ２０で、セッションを開始して、ネゴシエートした第１のコーデックタイプに従ってメディアデータフレームを交換する。開始されたセッション内でのメディアデータフレームの進行中の交換の間では、Ｓ３０で、第１のクライアントと第２のクライアントの少なくとも一方が、少なくとも１つの後続のメディアデータフレームで第２のコーデックタイプに対する指示を提供する。そして、提供される指示を受信して認識した際には、Ｓ４０で、第１のクライアントと第２のクライアントのもう一方が、次のメディアデータフレームにおいて指示された第２のコーデックタイプに切り替える。これによって、２つのクライアントは、第２のコーデックタイプを利用して後続のメディアデータフレームを交換することが可能になる。
【００２９】
クライアントは、所定数のステータスタイプインジケータが送信されるまで、あるいは対応するステータスタイプインジケータが受信されるまで、いくつかの連続する音声あるいはメディアデータフレームにステータスタイプインジケータを含める。所定数のインジケータが、対応するインジケータをクライアントが受信することなく送信される場合、クライアントは、インジケータの送信を停止し、最初にネゴシエートしたコーデックタイプを使用して送信を維持する。本発明の実施形態に従えば、クライアントは、後続のデータフレームにおいてリクエストされたコーデックタイプを直ちに切り替えることによって受信するステータスインジケータに応答する。しかしながら、少なくとも１つの対応するコーデックタイプインジケータを送信し、その後、リクエストされたコーデックタイプに切り替えることによって、受信するコーデックタイプインジケータに応答することも等しく可能である。
【００３０】
これによって、新規のセッションネゴシエーションを必要とすることがなく、また、新規のコーデック実装デバイスと従来のコーデック実装デバイスとの両方は、最初に交換されたメディアデータフレームにビットストリーム後方互換性があるという条件で、通信することができる。
【００３１】
本明細書で記載される本発明の開示の実施形態の重要な要素は、伝統的なセッション制御プロトコルシグナリング、例えば、メディアコンフィグレーション用のセッションをネゴシエートする場合のＳＩＰ／ＳＤＰと、ペイロードヘッダ内のＣＭＲフィールドでコーデックモード／タイプを信号送信してかつリクエストすることができるものと組み合わせることである。これらの２つのメカニズムを一緒に使用することによって、シグナリングレベルで従来のＡＭＲ−ＷＢ対応クライアントと相互動作することを脅かすことなく新規の音声コーダの使用をネゴシエートすることが可能になる。それゆえ、このセッションネゴシエーションは３つのステップで実行される。
【００３２】
まず、最初に、ＳＩＰ／ＳＤＰを使用して、「通常」のＡＭＲ−ＷＢセッションがネゴシエートされる。ここでは、新規の音声コーデックタイプの使用を指示するシグナリングは実行されない。次に、メディアが、クライアントＡとクライアントＢ（及びその逆）との間でフローすることを開始する場合、新規の音声コーデックタイプをサポートするクライアントがＡＭＲ−ＷＢタイプテーブル（表）において予約されている符号化の１つを使用してコーデックモードリクエスト（ＣＭＲ）を送信する。これは、適切な検出を保証するために第１のＮ個のフレームについて繰り返されることになる。このＮは１から∞の範囲で構成設定可能である。数を限定する理由は他の値でＣＭＲが送信される場合の混同を回避するためである。最後に、クライアントが、新規のコーデックタイプのサポートを示すＣＭＲを受信するとすぐに、新規のコーデックのコーデックモードを使用して、一方のクライアントがそれを復号できることを確実にすることを開始することができる。
【００３３】
コーデックの使用についての「階層的な」シグナリングに伴う主要な利点は、従前の装備を脅かすことなく新規の音声コーデックの装備を実現可能とし、かつシグナリングプレーン上での任意の更新を必要としないことである。
【００３４】
本発明は、ＡＭＲ−ＷＢセッションをネゴシエートする既存の方法の再使用に基づいている。
【００３５】
【表３】
【００３６】
表３は、ＩＭＳマルチメディアテレフォニーにおける典型的なＡＭＲ−ＷＢネゴシエーションの一例を示している。２つの異なるバージョンのＡＭＲ−ＷＢが提案されていて、１つは帯域幅有効ペイロードフォーマット（好ましくは）を使用し、もう１つはオクテット配列のペイロードフォーマットを使用する。ＲＴＰクロックレートは１６ｋＨｚに設定され、１つのオーディオチャネルが使用されることになる。
【００３７】
本発明に従う新規の音声コーデックに対するセッションネゴシエーションは、後方互換性がすべてのＡＭＲ−ＷＢモードに対して配備されている場合に同一のものとみなすことになる。一定のモード（群）だけに対して制限された後方互換性が存在する場合、モードの設定制限が信号通信されることになる。次に、ＳＤＰは、例示の指示がモード設定１、２に対してのみサポートすることに変更する。
【００３８】
【表４】
【００３９】
ＳＤＰの使用の種類は、ＡＭＲ−ＷＢをサポートする任意の２つのクライアントの間のセッションをセットアップし、また、これは、新規の音声コーデックに対する任意のサポートを示すことはない。
【００４０】
本発明の実施形態に従うネゴシエーション手順の第２の段階は、表２の空きフレームのタイプのインデックスの使用を行うことになる。この例では、フレームタイプ１２は新規の音声コーデックに対するサポートを示すために使用されているが、他のフレームタイプも使用することができる。セッションネゴシエーションのこの部分は、メディアフロー内の帯域内（インバンド：in-band）で実行されるので、ネゴシエーションが実行可能である専用のプロービング（probing）期間が設定される。新規の音声モードがプロービング期間内部で発生していることを示すＣＭＲビットの共同の交換がない場合、ネゴシエーションの第２の段階は失敗していると想定され、また、そのセッションは標準的なＡＭＲ−ＷＢセッションとして取り扱われることになる。
【００４１】
図３に示される例示のシグナリングスキームでは、全二重セッションが想定されることに注意されたい。この全二重セッションでは、クライアントの両方が音声データを送信し、それによって、自動的に、インバンドＣＭＲビット用のシグナリングチャネルを作成するものである。しかしながら、半二重フローの場合（図４参照）、つまり、メディアが一方向に流れる場合、これは不可能である。これらの場合、ＣＭＲビットを搬送する他の手段が、２段階のネゴシエーションを成功させるために使用されることを必要とする。このことを実現するための様々な方法が存在するが、その１つには、３ＧＰＰ［４］におけるＭＴＳＩサービスとの直接互換がある方法が１つ存在する。例示のシグナリングでは、第１のクライアントＵＥ１は一般的なＳＤＰ オファー（ＯＦＦＥＲ：提案） ＡＭＲ−ＷＢを第２のクライアントＵＥ２へ送信し、これは、２００ ＯＫで応答して、提案されるコーデックタイプを受け入れる。続いて、セッションが開始され、メディアデータフレームであるＲＴＰ ＭＥＤＩＡ（メディア），ＦＴ８が、２つのクライアントとの間で交換される。第１のクライアントは、次に、ＣＭＲ＝１２を含めることによって、Ｎ個の連続するメディアデータフレームに、第２のコーデックタイプ用の指示を含める。コーデックタイプの指示を受信し及び認識することで、第２のユーザ機器ＵＥ２は、ＣＭＲ＝１２を含むＮ個のメディアデータフレームで応答する。そして、２つのクライアントは、完全に新規なセッションネゴシエーション手順を開始することなく、現在同意されている第２のコーデックタイプを使用してメディアデータの交換を開始することができる。
【００４２】
ＣＭＲに基づくネゴシエーションに対する代替のソリューションは、ＣＭＲビットを搬送するためにＲＴＣＰ−ＡＰＰを使用することである。このメカニズムに伴う更なる利点は、半二重セッションに対しても動作することである。図４及び図５を参照されたい。ＭＴＳＩは、音声データがフローしている場合のセッション中に使用されるべき適合パラメータを搬送するための専用のＡＰＰレポートを定義している。この手順は、基本的には、いくつかの点を除いて、図５を参照して説明される手順と同一である。半二重セッションは、メディアフローの逆方向にＲＴＣＰレポートを送信することになるので、これは、発生するシグナリングに対する可能性を広げる。ここで、ＣＭＲリクエスト用のＲＴＣＰ−ＡＰＰエンコーディングは、インバンド形式と同一のものであり、そうすることで、同一の行動を確認することができることに注意されたい。ＲＴＣＰを使用して送信されるＣＭＲリクエストの速度に１つの違いがあり、これは、ＲＴＣＰ送信ルールによって設定される制限の１つである。しかしながら、この制限の最大の結論は、ネゴシエーションの第２の段階に対するセットアップ時間がわずかに延びることであり、最後には同一の正常な速度になる。
【００４３】
図６及び図７を参照して、本発明に従う方法の特定の実施形態を説明する。この例では、ＣＭＲ＝１２は新規のコーデックに対する代替に相当し、パラメータＮを構成設定可能である（ほぼ１０程度の値が使用されることになる）。ＡＭＲ−ＷＢへの拡張、即ち、新規の後方互換音声コーデックは、ＥＶＳと呼ばれる。ここで、ＣＭＲ値は、ＡＭＲ−ＷＢフレームタイプのインデックスで現在利用可能な任意の値とすることができることに注意されたい。
【００４４】
特定の実施形態はＡＭＲ−ＷＢとＥＶＳを使用しているが、これは第１のコーデックタイプ及び第２のコーデックタイプの一例であり、同一の方法を他の音声コーデックタイプの組み合わせにも等しく利用することができることは明らかである。
【００４５】
最初に、ＡＭＲ−ＷＢの場合、クライアントあるいはユーザ機器は、第１のコーデックタイプを含むインビテーション（招待）を伴うセッションネゴシエーション信号を送信する。次に、クライアントがそのインビテーションに対する肯定応答（２００ ＯＫ）を受信する場合、クライアントは、そのネゴシエーションされるコーデックタイプを使用してメディアフレームの送信／交換を開始することを継続する。Ｎ個の連続するデータフレームまで、クライアントは第２のコーデックタイプを使用することができることを示すために、ＣＭＲ＝１２を含める。同時に、クライアントは、受信する音声パケット、及び対応する指示用のＲＴＰＣＰ−ＡＰＰレポートの少なくとも一方を監視する。対応する指示を受信すると、クライアントは、第２のコーデックタイプ、例えば、ＥＶＳモードに従ってデータフレームを送信することを開始する。このような指示が提供されない場合、クライアントは、従前にネゴシエートされたコーデックタイプ、例えば、ＡＭＲ−ＷＢモードを維持する。
【００４６】
ここで、図６及び図７のフローは一例であり、ＥＶＳネゴシエーションの開始は、２００ ＯＫが受信された直後であることが必須ではなく、セッション中の任意の時間に実行することができることに注意されたい。また、テスト「ＣＭＲ＝１２？」は、厳密なテストにしなければならないわけではない。このことを実行するための代替の方法は、例えば、以下のものがある。
【００４７】
１）リモートクライアント（ＥＶＳ用のＣＭＲリクエストを受信するクライアント）は、ＥＶＳフレームタイプ（ＦＴ＝１２あるいは１３、あるいはそれ以外）を使用して直ちに開始することができる。このことは、ＥＶＳが可能であり、また、「ＣＭＲ＝１２」を指示するために「ＣＭＲ＝１２」を送信することが必要ないことを宣言することにもなる。
【００４８】
２）１つの構成には、「ＦＴ＝１２」が「ＥＶＳケイパビリティ用の問い合わせ／招待」であること、また、「ＦＴ＝１３」が確認応答であることを定義することができる。
【００４９】
図８を参照して、本発明に従うユーザ機器あるいはクライアントの実施形態を説明する。ユーザ機器あるいはクライアントについての１つの特定の態様は、リクエストされている新規のあるいは第２のコーデックタイプについての指示の受信を、認識して動作することができることが必要であることである。このことのために、ユーザ機器は、信号を送受信することを可能にするための汎用入力／出力ユニットＩ／Ｏ、別のクライアントとのセッション用の第１のコーデックタイプについてネゴシエートしかつ同意するためのネゴシエーションユニット１０と、ネゴシエートされた第１のコーデックタイプに従って別のユーザ機器とのセッションを開始し、メディアデータフレームを交換するためのセッションユニット２０とを含んでいる。また、クライアントは、開始されたセッション中に、第２のコーデックタイプのための指示を少なくとも１つの後続のメディアデータフレームで提供するためのコーデック切替ユニット３０を含んでいる。そして、クライアントは、対応する指示を受信し及び認識すると、次のメディアデータフレームで指示された第２のコーデックタイプへ切り替えるためのユニット４０を含み、これによって、第１のクライアントと第２のクライアントに第２のコーデックタイプを利用して後続のメディアデータフレームを交換することを可能にする。つまり、ユーザ機器あるいはクライアントはコーデック切替指示を提供するだけでなく、対応する指示を受信しそれに応答するように適合されている。上述のユニット群は、典型的には、１つ以上のハードウェアプロセッサあるいは、本開示の方法の開示される実施形態のステップ群を実行するように構成されているソフトウェアアルゴリズムによって実現可能である。加えて、上述のクライアントあるいはユーザ機器の機能は、電気通信システム内のノードにおいて実現することができる。
【００５０】
開示される方法及び構成に対する前提条件は、データパケット、例えば、ＲＴＰパケットが、ビットストリーム埋込後方互換コーデックフォーマットを有することである。本発明はパケット交換システムの内容で説明されるが、回線交換システムにも等しく適用可能である。
【００５１】
本発明の効果は、以下のことを含んでいる。
【００５２】
本発明の実施形態に従うセッションネゴシエーション用の２段階の方法を使用する利点は、ＳＩＰ／ＳＤＰシグナリングプレーン上で表現される後方互換性によるものである。通常のＡＭＲ−ＷＢセッションのように見えるが、これに代えて、新規の音声コーデックを使用する可能性のためのＣＭＲシグナリング「プローブ」となる。ＣＭＲビットの特性はこの後方互換性を実現する。これは、従来のデコーダはＣＭＲリクエストあるいは「新規」のＦＴを伴う受信フレームを理解しない場合、自動的にそれらを却下するからである。
【００５３】
文献群
［１］ ＩＥＴＦ ＲＦＣ ４８６７
［２］ ３ＧＰＰ ＴＳ２６．１０１、「適合マルチレート（ＡＭＲ）音声コーデックフレーム構造」
［３］ ３ＧＰＰ ＴＳ２６．２０１、「適合マルチレート−ワイドバンド（ＡＭＲ−ＷＢ）音声コーデック、フレーム構造」
［４］ ３ＧＰＰ ＴＳ２６．１１４、「ＩＰマルチメディアサブシステム（ＩＭＳ）、マルチメディアテレフォニー、メディア処理及び対話」
【特許請求の範囲】
【請求項１】
セルラー通信システムにおける第１のクライアントと第２のクライアントとの間でのセッションネゴシエーションを行う方法であって、
前記第１のクライアントと前記第２のクライアントとが、セッション用の第１のコーデックタイプをネゴシエートし、かつ同意するステップと、
前記第１のクライアントと前記第２のクライアントが、前記セッションを開始し、前記第１のコーデックタイプに従ってメディアデータフレームを交換するステップと、
前記開始されたセッション中に、前記第１のクライアントと前記第２のクライアントとの内の少なくとも一方が、少なくとも１つの後続のメディアデータフレームにおける第２のコーデックタイプに対する指示を提供するステップと、
前記指示の受信及び認識に応じて、前記第１のクライアントと前記第２のクライアント内の他方が、次のメディアデータフレームにおいて、前記第２のコーデックタイプに切り替え、それによって、前記第１のクライアントと前記第２のクライアントとが、前記第２のコーデックタイプを利用して後続のメディアデータフレームを交換することを可能にするステップと
を有することを特徴とする方法。
【請求項２】
前記指示を所定数の連続するメディアデータフレームに提供する
ことを特徴とする請求項１に記載の方法。
【請求項３】
前記セッションは全二重セッションを含み、
前記第１のクライアントと前記第２のクライアントの両方は、前記指示を少なくとも１つの後続のメディアデータフレームに提供する
ことを特徴とする請求項１に記載の方法。
【請求項４】
前記セッションは半二重セッションであり、
前記第１のクライアントは、前記指示を後続のメディアデータフレームに提供し、
前記第２のクライアントは、前記指示を少なくとも１つの後続のシグナリング制御データフレームに提供する
ことを特徴とする請求項１に記載の方法。
【請求項５】
前記指示は、交換される前記メディアデータフレーム用のペイロードヘッダに含まれる
ことを特徴とする請求項１に記載の方法。
【請求項６】
前記指示は、前記メディアデータフレームのコーデックタイプリクエストに含まれる
ことを特徴とする請求項５に記載の方法。
【請求項７】
前記第１のクライアントは、前記指示を、交換される前記メディアデータフレームのペイロードに提供し、
前記第２のクライアントは、前記指示を、前記シグナリング制御データフレームのペイロードヘッダに提供する
ことを特徴とする請求項４に記載の方法。
【請求項８】
前記第１のクライアントと前記第２のクライアントの内の他方は、前記第２のコーデックタイプに切り替える前に、提供される指示に対応する指示を少なくとも１つの後続のメディアデータフレームに提供することによって、受信し認識する前記提供される指示に応答する
ことを特徴とする請求項１に記載の方法。
【請求項９】
前記第２のクライアントは、前記指示を伴う所定数のメディアデータフレームを受信した後に、前記第２のコーデックタイプに切り替える
ことを特徴とする請求項８に記載の方法。
【請求項１０】
前記セッションは、ＲＴＰパケット内に含まれるメディアデータフレームの送信を含んでいる
ことを特徴とする請求項１乃至９のいずれか１項に記載の方法。
【請求項１１】
セルラー通信システムにおけるクライアントであって、
別のクライアントとのセッション用の第１のコーデックタイプについてネゴシエートし同意する手段と、
前記セッションを開始し、かつ前記第１のコーデックタイプに従ってメディアデータフレームを交換する手段と、
前記開始されるセッション中に、第２のコーデックタイプに対する指示を少なくとも１つの後続のメディアデータフレームに提供する手段と、
対応する指示の受信及び認識に応じて、次のメディアデータフレームで前記第２のコーデックタイプに切り替える手段であって、それによって、当該クライアントと前記別のクライアントとが前記第２のコーデックタイプを利用して後続のメディアデータフレームを交換することを可能にする、切り替える手段と
を有することを特徴とするクライアント。
【請求項１２】
前記提供する手段は、前記指示を所定数の連続するメディアデータフレームに提供するように構成されている
ことを特徴とする請求項１１に記載のクライアント。
【請求項１３】
前記切り替える手段は、前記第２のコーデックタイプに直ちに切り替えるように構成されている
ことを特徴とする請求項１１または１２に記載のクライアント。
【請求項１４】
前記切り替える手段は、所定数の前記指示を受信しかつ認識した後に、前記第２のコーデックタイプに切り替えるように構成されている
ことを特徴とする請求項１１または１２に記載のクライアント。
【請求項１５】
電気通信システムにおけるノードであって、
請求項１１に記載のクライアントを有する
ことを特徴とするノード。
【請求項１】
セルラー通信システムにおける第１のクライアントと第２のクライアントとの間でのセッションネゴシエーションを行う方法であって、
前記第１のクライアントと前記第２のクライアントとが、セッション用の第１のコーデックタイプをネゴシエートし、かつ同意するステップと、
前記第１のクライアントと前記第２のクライアントが、前記セッションを開始し、前記第１のコーデックタイプに従ってメディアデータフレームを交換するステップと、
前記開始されたセッション中に、前記第１のクライアントと前記第２のクライアントとの内の少なくとも一方が、少なくとも１つの後続のメディアデータフレームにおける第２のコーデックタイプに対する指示を提供するステップと、
前記指示の受信及び認識に応じて、前記第１のクライアントと前記第２のクライアント内の他方が、次のメディアデータフレームにおいて、前記第２のコーデックタイプに切り替え、それによって、前記第１のクライアントと前記第２のクライアントとが、前記第２のコーデックタイプを利用して後続のメディアデータフレームを交換することを可能にするステップと
を有することを特徴とする方法。
【請求項２】
前記指示を所定数の連続するメディアデータフレームに提供する
ことを特徴とする請求項１に記載の方法。
【請求項３】
前記セッションは全二重セッションを含み、
前記第１のクライアントと前記第２のクライアントの両方は、前記指示を少なくとも１つの後続のメディアデータフレームに提供する
ことを特徴とする請求項１に記載の方法。
【請求項４】
前記セッションは半二重セッションであり、
前記第１のクライアントは、前記指示を後続のメディアデータフレームに提供し、
前記第２のクライアントは、前記指示を少なくとも１つの後続のシグナリング制御データフレームに提供する
ことを特徴とする請求項１に記載の方法。
【請求項５】
前記指示は、交換される前記メディアデータフレーム用のペイロードヘッダに含まれる
ことを特徴とする請求項１に記載の方法。
【請求項６】
前記指示は、前記メディアデータフレームのコーデックタイプリクエストに含まれる
ことを特徴とする請求項５に記載の方法。
【請求項７】
前記第１のクライアントは、前記指示を、交換される前記メディアデータフレームのペイロードに提供し、
前記第２のクライアントは、前記指示を、前記シグナリング制御データフレームのペイロードヘッダに提供する
ことを特徴とする請求項４に記載の方法。
【請求項８】
前記第１のクライアントと前記第２のクライアントの内の他方は、前記第２のコーデックタイプに切り替える前に、提供される指示に対応する指示を少なくとも１つの後続のメディアデータフレームに提供することによって、受信し認識する前記提供される指示に応答する
ことを特徴とする請求項１に記載の方法。
【請求項９】
前記第２のクライアントは、前記指示を伴う所定数のメディアデータフレームを受信した後に、前記第２のコーデックタイプに切り替える
ことを特徴とする請求項８に記載の方法。
【請求項１０】
前記セッションは、ＲＴＰパケット内に含まれるメディアデータフレームの送信を含んでいる
ことを特徴とする請求項１乃至９のいずれか１項に記載の方法。
【請求項１１】
セルラー通信システムにおけるクライアントであって、
別のクライアントとのセッション用の第１のコーデックタイプについてネゴシエートし同意する手段と、
前記セッションを開始し、かつ前記第１のコーデックタイプに従ってメディアデータフレームを交換する手段と、
前記開始されるセッション中に、第２のコーデックタイプに対する指示を少なくとも１つの後続のメディアデータフレームに提供する手段と、
対応する指示の受信及び認識に応じて、次のメディアデータフレームで前記第２のコーデックタイプに切り替える手段であって、それによって、当該クライアントと前記別のクライアントとが前記第２のコーデックタイプを利用して後続のメディアデータフレームを交換することを可能にする、切り替える手段と
を有することを特徴とするクライアント。
【請求項１２】
前記提供する手段は、前記指示を所定数の連続するメディアデータフレームに提供するように構成されている
ことを特徴とする請求項１１に記載のクライアント。
【請求項１３】
前記切り替える手段は、前記第２のコーデックタイプに直ちに切り替えるように構成されている
ことを特徴とする請求項１１または１２に記載のクライアント。
【請求項１４】
前記切り替える手段は、所定数の前記指示を受信しかつ認識した後に、前記第２のコーデックタイプに切り替えるように構成されている
ことを特徴とする請求項１１または１２に記載のクライアント。
【請求項１５】
電気通信システムにおけるノードであって、
請求項１１に記載のクライアントを有する
ことを特徴とするノード。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【公表番号】特表２０１２−５２３１９９（Ｐ２０１２−５２３１９９Ａ）
【公表日】平成２４年９月２７日（２０１２．９．２７）
【国際特許分類】
【出願番号】特願２０１２−５０４６５６（Ｐ２０１２−５０４６５６）
【出願日】平成２２年４月６日（２０１０．４．６）
【国際出願番号】ＰＣＴ／ＳＥ２０１０／０５０３７８
【国際公開番号】ＷＯ２０１０／１１７３２６
【国際公開日】平成２２年１０月１４日（２０１０．１０．１４）
【出願人】（５９８０３６３００）テレフオンアクチーボラゲット エル エム エリクソン（パブル） (2,266)
【Ｆターム（参考）】
【公表日】平成２４年９月２７日（２０１２．９．２７）
【国際特許分類】
【出願日】平成２２年４月６日（２０１０．４．６）
【国際出願番号】ＰＣＴ／ＳＥ２０１０／０５０３７８
【国際公開番号】ＷＯ２０１０／１１７３２６
【国際公開日】平成２２年１０月１４日（２０１０．１０．１４）
【出願人】（５９８０３６３００）テレフオンアクチーボラゲット エル エム エリクソン（パブル） (2,266)
【Ｆターム（参考）】
[ Back to top ]