JP2008538689A - Ｈ．３２４の高速セッション起動の拡張 - Google Patents

Abstract

【課題】１又は複数の３Ｇ通信ネットワークを用いて起動時間を短縮した状態でユーザ間の呼処理を開始する方法。
【解決手段】この方法は、１又は複数の３Ｇ通信ネットワークで接続された少なくとも一対のＨ．３２４類似端末（エンティティＡ及びエンティティＢ）の間で提供される。その方法は、呼信号プロセス後に第１の端末と第２の端末との間でベアラチャンネルを確立することと、前記第１の端末から前記第２の端末へ第１のＦＳＳメッセージを送信することとを含んでいる。前記第１のＦＳＳメッセージは、呼動作の第１のモードと関連する第１優先度プロファイルと、呼動作の第２のモードと関連する第２優先度プロファイルとを含んでいる。その方法は、前記第１のモードか前記第２のモードかのいずれかを選択することを含んでいる。
【選択図】図７Ａ

Description

［関連出願の相互参照］
本出願は、２００５年４月２１日に出願した米国仮出願番号６０／６７４１６０の優先度を主張し、ここに引用して援用するものである。

本発明は、一般には装置（「端末」）間でのマルチメディア通信（マルチメディア「呼」）に関する。より詳細には、ＩＴＵ−ＴのＨ．３２４勧告、および第三世代パートナーシッププロジェクト（３ＧＰＰおよび３ＧＰＰ２）により開発され、採用された３Ｇ−３２４Ｍ勧告などのＨ．３２４勧告に由来又は関連する他の標準および勧告を使用する端末間での呼確立に必要な時間を短縮する方法に関する。単に一例としてではあるが、本発明は、移動通信ネットワ−ク上での３Ｇ−３２４Ｍ（Ｈ．３２４ベースのプロトコル）マルチメディア・ハンドセット間、および各エンドポイントで用いられるプロトコル間を仲介するマルチメディア・ゲ−トウェイを用いたパケットネットワ−ク上での３Ｇ−３２４Ｍマルチメディア・ハンドセットとＨ．３２３ベースの端末間でのマルチメディア通信の確立に適用されているが、本発明はまた他にも適用できることは明らかであろう。

Ｈ．３２４は、一般アナログ電話網（ＧＳＴＮ）上でのマルチメディア通信に対して標準の、国際電気通信連合（ＩＴＵ）のプロトコルである。Ｈ．３２４Ｍは、Ｈ．３２４の拡張版であり、移動通信ネットワ−ク上での接続を目的とする。また、３Ｇ−３２４Ｍは、第三世代パートナーシップ・プログラム（３ＧＰＰ）による勧告であり、３ＧＰＰの範囲内でのＨ．３２４Ｍの使用に対する適合性を規定し、また３ＧＰＰ２により採用される。Ｈ．３２４ベース又は由来のプロトコルを用いる装置やシステムをＨ．３２４類似装置と呼ぶことにする。Ｈ．３２４類似装置は、他のＨ．３２４類似装置と交換局経由で接続でき、Ｈ．３２４類似ではない他の装置とはマルチメディア・ゲ−トウェイを介して接続できる。Ｈ．３２４類似ではない他の装置の例として、Ｈ．３２３装置がある。Ｈ．３２３は、帯域非保証型パケットネットワ−ク上でのマルチメディア通信に対して標準の、国際電気通信連合のプロトコルである。Ｈ．３２３類似装置とは、Ｈ．３２３プロトコルベース又は由来のプロトコルを用いる装置のことをいう。

一般性を失うことなく、「Ｈ．３２４」という表現を、Ｈ．３２４Ｍおよび３Ｇ−３２４Ｍ装置を含むＨ．３２４類似装置を示すのに用いることとし、「Ｈ．３２３」という表現をＨ．３２３類似装置を示すのに用いることとする。

また、一般性を失うことなく、「装置」という表現を、ハンドセットなどのようなユ−ザ端末装置、あるいは交換機やゲ−トウェイなどのネットワ−ク端末装置のいずれかを示すのに用いることとする。用語「装置」は、「エンティティ」の意味をカバーする。「装置」と「端末」という表現は可換であり、どちらも本文書中では同じ意味を示すものとする。

Ｈ．３２４、Ｈ．３２４Ｍ、又は３Ｇ−３２４Ｍの実施形態である機器間で呼がなされる場合、呼の第１段階は、装置間でエンドツーエンド・ベアラを確立することである。この段階のことを呼信号とよび、モデムや一般アナログ電話網が使用されている場合を除き、Ｈ．３２４の範囲外である。呼の第２段階は、Ｈ．３２４のセッションを確立することであり、それは、装置がサポートする形式で、装置間に映像、音声、およびデータの送信手段を設けることである。これを行うために、Ｈ．３２４Ｍは、さらに２つのＩＴＵ−Ｔ勧告を用いる。

この用いる勧告のうち、最初の１つは、「低ビットレートのマルチメディア通信用多重化プロトコル」であるＨ．２２３である。Ｈ．２２３は、フレーム指向の多重化プロトコルの仕様を定めており、単一通信回線上で、あらゆる組み合わせの音声、映像、およびデータ（例えば、コマンドとコントロールなど）のデジタル情報を送信できるようにする。このＨ．２２３は、多くの接続モ−ドが使え、それは、エラーの存在下でもより高い柔軟性の実現を目的としたＨ．２２３勧告の補遺Ａ、Ｂ、およびＣに仕様が定められている。これはまた、モバイルレベル１、２、および３としても知られている。この補遺のいずれも適用しなければ、Ｈ．２２３は、時には、モバイルレベル０（基準の）での接続ともみなされる。Ｈ．３２４には、論理チャネルの概念があり、その概念とは、回線交換リンク上に仮想チャネルを設ける方法のことである。マルチプレクサの役割は、論理チャネル上に書き込まれたデータチャンク各部を、マルチプレクサ・プロトコルデータユニット（ＭＵＸ−ＰＤＵ）として知られるフレームに混合（多重化）することである。論理チャネル０は、常に利用可能であり、コマンドとコントロールに用いられる。データ（音声、映像、コマンドとコントロール、および他の一般的なデータ）は、サービスデータユニット（ＳＤＵ）と呼ばれるビットストリームチャンクを介して、マルチプレクサとやり取りされる。種々のＳＤＵは、多重化される前にアダプテーション層を通過し、そこで、エラー検出、シ−ケンス番号付与、再送リクエストなどの目的のために追加情報を付加することができる。

勧告のうちの２番目は、「マルチメディア通信用コントロールプロトコル」であるＨ．２４５であり、端末情報メッセージの構文と動作、および通信開始時又は通信の最中でのインバンド・ネゴシエーションに対するそれらの使用手順に関して仕様を定める。このメッセージは、機能と設定、ロジカルチャネルシグナリング、およびコントロールとインジケーションの送受信を扱う。Ｈ．２４５で仕様を定めたこのメッセージは、ＩＴＵ−Ｔの抽象構文記法１（ＡＳＮ．１）に示されており、リクエスト、レスポンス、コマンド、又はインジケーションタイプのメッセージとして分類することができる。Ｈ．２４５メッセージは、送信される前に、ＡＳＮ．１標準に従ってエンコードされる。リクエストタイプのＨ．２４５メッセージを端末が送信すると、この端末は、遠隔端末がレスポンスタイプの適切なメッセージを返信するようにリクエストする。もし、そのレスポンス（受信確認を意味するアック「Ａｃｋ」と呼ばれることもある）が一定時間内に受信されなければ、送信側端末がリクエストを再送信する。あるいはリクエストを繰り返してもなんらのレスポンスも受信されなければ、他の適切な処置をとることになる。リクエストの再送信は、何度でも生じる可能性がある。呼設定に関わるＨ．２４５メッセージの多くが、リクエストタイプのものである。

また、Ｈ．２４５は、正確な接続のために信頼性の高いリンク層を要求する。これを実現する主要な手段は、Ｈ．３２４の補遺Ａに仕様を定めてあるが、簡易再送プロトコル（ＳＲＰ）又は番号を付与した簡易再送プロトコル（ＮＳＲＰ）を用いることであり、このプロトコルでは、全般的にはマルチメディアシステムコントロールＰＤＵとして、また本文書ではＨ．２４５ＰＤＵとして知られる１つ又は複数のＨ．２４５メッセージが送信前にＳＲＰコマンドフレームに形成され、受信側端末は、ＳＲＰコマンドフレームを正しく受信したという確認のためにＳＲＰレスポンスフレーム（ＳＲＰアックと呼ばれることもある）を送信しなければならない。最後のメッセージに対するＳＲＰアックが受信されるまで、端末装置は、それ以上のいかなるＨ．２４５メッセージも送信してはならない。

受信された各Ｈ．２４５リクエストメッセージに対するＨ．２４５レスポンスメッセージの送信リクエストと、送信された各ＳＲＰコマンドフレームに対するＳＲＰアックの受信の必要性との複合効果は、単独のリクエストメッセージでは無事に伝達されるのにある程度時間がかかる、ということを意味する。一方の端末（Ａ）から他方の端末（Ｂ）へのＨ．２４５メッセージの送信と、Ｈ．２４５レスポンス（アック）メッセージの入手に関わる通信について、特表２００６−５１０２４２号公報の図１Ａに示す。また、図１Ａには、片道のＨ．２４５メッセージが片道のＳＲＰコマンドフレーム（ＳＲＰ ＣＦ）に形成された場合に関与するＳＲＰコマンドフレーム（ＳＲＰ ＣＦ）とＳＲＰレスポンスフレーム（ＳＲＰ ＲＦ 又は ＳＲＰアック）とを示す。Ｈ．３２４標準により、複数のＨ．２４５メッセージが１つのＳＲＰコマンドフレーム内で連結されることが可能となるが、この機能は、このような端末がもしＳＲＰコマンドフレーム内で遭遇した最初のＨ．２４５メッセージのみに応答する場合は、そう頻繁には利用されない。場合によっては、複数のＨ．２４５リクエスト又はレスポンスを含むＳＤＵを受信すると、この機能をサポートしない端末は誤動作を起こすかもしれない。

ある端末によって送信された情報が他の端末に到達、最初の端末(図１Ａの例を参照)への応答が、反転して戻ってくるのに要する時間は、「往復遅延」として、参照される。この往復遅延は、メディア処理及び通信に関わる装置の遅延が加えられてはおらず、ネットワーク遅延を表現する尺度とする意図もないことに留意すべきである。往復遅延値の概算は、Ｈ．２４５のRoundTripDelayRequest及びRoundTripDelayResponseメッセージの使用によって測定され得る。

典型的なＨ．３２４呼設定および呼接続に関わる重要なステップは以下の通りである。

１．呼信号（ベアラ確立）−Ｈ．３２４の範囲外。通常は、ＧＳＴＮであれば、ＩＳＤＮを介したモデム接続。又は移動体通信の場合は移動体交換局を介した信号伝達。
２．モバイルレベル検出（ＭＬＤ）−ここで、共通のモバイルレベルが装置間で一致する。このステップは、Ｈ．３２４Ｍや３Ｇ−３２４Ｍ装置などのモバイル用の拡張をサポートするＨ．３２４装置により実行される。
３．端末機能交換（ＴＣＳ）−Ｈ．２４５メッセージング
４．マスタ・スレーブ判定（ＭＳＤ）−Ｈ．２４５メッセージング
５．オープン／クローズ論理チャネル（ＯＬＣ）−Ｈ．２４５メッセージング
６．マルチプレクサ・テーブル・エントリ交換（ＭＴＥ）− Ｈ．２４５メッセージング

ステップ（３）〜（６）は、前述のようにＨ．２４５リクエストとレスポンスメッセージのシーケンスを用いて実行され、これを図１Ａに示す。Ｈ．３２４の呼に関するリクエストとレスポンスの完全なシーケンスを特表２００６−５１０２４２号公報の図１Ｂに示す。ここで留意すべきは、上記ステップ（５）および（６）の順序は可換だということである。また、ステップ（３）〜（６）は、シグナリングエンティティとしても知られる基礎をなす状態機械により定義される手順に関係することに留意すべきである。この関連するシグナリングエンティティには次のものがある。
１．機能交換シグナリングエンティティ（ＣＥＳＥ）
２．マスタ・スレーブ判定シグナリングエンティティ（ＭＳＤＳＥ）
３．論理チャネル・シグナリングエンティティ（ＬＣＳＥ）
４．多重化テーブル・シグナリングエンティティ（ＭＴＳＥ）

一旦これらのステップが完了すると、メディア（映像、音声、およびデータ）は端末間を流れることができる。ここで留意すべきは、Ｈ．２４５メッセージは、先に説明したように、事前に定義され、マルチプレクサの事前に定義した多重化テーブルエントリ０により伝わる論理チャネル０上を流れることである。一旦、他の多重化テーブルエントリと交換すると、それもＨ．２４５メッセージとあわせて用いることができる。

上記の重要なステップは、多くの場合、順番に処理されるが、これは、各方向に２つの論理チャネルでＨ．３２４セッションを確立するために、Ｈ．２４５メッセージの往復遅延が１０も生ずる結果となる。さらに、送信された各メッセージに対して、その他のメッセージを送信する前に、それが同じシグナリングエンティティと関連するか否かにかかわらず、エンドポイントがＳＲＰメッセージを受信することを要求するＨ．３２５／Ｈ．２４５に用いられるＳＲＰスキーム（あるいは、もしモバイルレベルが０を超える場合は、番号付与バージョンであるＮＳＲＰ）は、そうでない場合よりも呼設定を遅くしつつ、さらに範囲をネットワーク上のパイプラインメッセージに制限する。図１Ｂには、ＳＲＰメッセージは示されていない。

Ｈ．３２４Mに対しては、図１Ｂに示す上述の端末機能設定（ＴＣＳ）リクエストのステップに先立ち、モバイルレベル検出／マルチプレクサ同期化フェーズが実行される。これは、各端末が接続する最高のモバイルレベルを示すビット（フラグ）の繰り返しパターンを送信する各端末からなる。各端末は、各端末が受信しているそのフラグを検証する。もし、このフラグが下位のモバイルレベルを示す場合は、端末は、同じ下位レベルまで下がる。両端末が同じフラグシーケンスを送信すると、このステップは終了する。

Ｈ．３２４Ｍの呼確立のために実行する必要がある上記一連の手順のため、Ｈ．３２４の実施形態である端末から呼がなされる場合は、呼信号が起動される時間から、Ｈ．３２４類似エンドポイント（Ｈ．３２４、Ｈ．３２４Ｍ、又は３Ｇ−３２４Ｍ）とＨ．３２４類似か否かにかかわらず他の端末との間での音声と映像の交換が開始される時間までの間、長い呼設定時間にいらいらしがちである。

ＩＴＵ−Ｔ勧告Ｈ．３２３は、呼に関係するコマンド、コントロール、およびインジケーションメッセージの信号伝達に関して、Ｈ．３２４と同様の方法でＨ．２４５を用いる。ただし、Ｈ．３２４とは異なり、Ｈ．３２３は、Ｈ．３２３装置間での呼設定時間を短縮するために多くの特徴を備える。ＩＥＴＦのセッション開始プロトコルにも、同様の技術が存在する。

このように、Ｈ．３２４類似端末と、Ｈ．３２４タイプ又はマルチメディア・ゲートウェイを介したＨ．３２３などのもう一方の端末との間での呼設定時間を短縮する技術が求められている。Ｈ．３２４プロトコル（およびＨ．３２４Ｍや３Ｇ−３２４Ｍなどのその拡張版）と、Ｈ．３２３やその他のプロトコルとの違いは、Ｈ．３２４類似端末に対して呼確立時間を短縮する技術を導入する場合は、付加的な側面を考慮する必要がある、という点である。その違いには、用いるモバイルレベルに関する情報、および多重化テーブルエントリやアダプテーション層などのマルチプレクサに関するメッセージングと情報とが含まれる。

本発明は、通信技術を提供する。より詳細には、ＩＴＵ−Ｔ Ｈ．３２４勧告、および第三世代パートナーシップ・プロジェクト（３ＧＰＰおよび３ＧＰＰ２）により開発され、採用された３Ｇ−３２４Ｍ勧告などのＨ．３２４勧告に由来又は関連する他の標準および勧告を使用する端末間での呼確立に必要な時間を短縮する方法を提供する。より詳細には、セッション起動、３ＧＰＰ ３Ｇ−３２４Ｍ端末を含むＨ．３２４類似の端末、例えばインハンド・ベアラ接続のセッション起動時間を低減する技術に関する。本発明の実施形態によれば、ここに記載される技術は、既存のＨ．３２４類似と下位互換性がある。他の実施形態によれば、本発明は、モバイル通信ネットワークの３Ｇ−３２４Ｍ（Ｈ．３２４ベースのプロトコル）ハンドセット間、および各エンドポイントで用いられるプロトコル間を仲介するマルチメディア・ゲ−トウェイを用いたパケットネットワ−ク上での３Ｇ−３２４Ｍマルチメディア・ハンドセットとＨ．３２３ベースの端末間でのマルチメディア通信の確立に適用されるが、本発明はまた他にも適用できることは明らかであろう。

本発明の実施形態によれば、１又は複数の３Ｇ通信ネットワーク用い、短縮された起動時間でユーザ間の呼の起動プロセスを開始する方法が提供される。その方法は、１又は複数の３Ｇ通信ネットワークに接続された少なくとも一対のＨ．３２４類似の端末間にも提供される。その方法は、呼信号プロセス後の第１の端末と第２の端末との間のベアラチャンネルを、前記第１の端末から前記第２の端末に第１のＦＳＳメッセージを送信することにより、確立することを含んでいる。前記ＦＳＳメッセージは、呼に対する第１のモードに関連する第１の優先度プロファイルと、呼に対する第２のモードに関連する第２の優先度プロファイルとを含んでいる。その方法は、前記第１の動作モードと、前記第２の動作モードとのいずれかを選択することも含んでいる。

本発明の他の実施形態によれば、１又は複数の３Ｇ通信ネットワークを用い、短縮された起動時間で、ユーザ間で呼の起動プロセスを開始する方法が提供される。その方法は、１又は複数の３Ｇ通信ネットワークと接続された少なくとも一対のＨ．３２４類似の端末間に提供される。その方法は、動作モードの複数のプロファイルを提供し、複数のプロファイルのうちの１つを用いた呼の確立を試みることにより、呼信号プロセス後に、第１の端末と第２の端末との間のベアラチャンネルを確立することを含む。その方法は、呼が、複数のプロファイルのうちの１つを用いて確立されなかったことと、前記複数のプロファイルのうちの他の１つを用いて確立されたこととを判定することも含む。

本発明の詳細な実施形態によれば、１又は複数の３Ｇ通信ネットワークを用い、短縮された起動時間でユーザ間の呼の起動プロセスを開始する方法が提供される。その方法は、１又は複数の３Ｇ通信ネットワークに接続された、少なくとも一対のＨ．３２４類似端末間に適用される。その方法は、呼信号プロセス後に、第１の端末と第２の端末との間のベアラチャンネルを確立することと、第１のＦＳＳメッセージによって定義された１又は複数の動作モードを提供することとを含む。１又は複数の動作モードは、１又は複数の音声コーデック及び設定、映像コーデック及び設定、多重化レベル、多重化テーブルエントリ、データチャンネル、又は多重化機能を含んでいる。その方法は、前記第１の端末で、前記第２の端末からの前記第１のＦＳＳメッセージを受信することと、第２のＦＳＳメッセージにおいて、第１の端末から第２の端末への第１のデータストリームを送信することとを含む。前記第１のデータストリームは、１又は複数の動作モードを用いる。

本発明の他の詳細な実施形態によれば、１又は複数の３Ｇ通信ネットワークを用い、短縮された起動時間でユーザ間の呼の起動プロセスを開始する方法が提供される。その方法は、１又は複数の３Ｇ通信ネットワークに接続された、少なくとも一対のＨ．３２４類似端末間に適用される。その方法は、呼信号プロセス後に、第１の端末と第２の端末との間のベアラチャンネルを確立することと、第１のＦＳＳメッセージによって定義された１又は複数の動作モードを提供することとを含む。前記１又は複数の動作モードは、コーデックの設定及び多重化テーブルエントリを含む。その方法は、前記第１の端末で、前記第２の端末からの前記第１のＦＳＳメッセージを受信することと、前記第２の端末からのレスポンスメッセージが前記第１の端末で受信されるまで、前記第２の端末が受信したメディアを受信可能でないことを、前記第１の端末で前記第１のＦＳＳメッセージから判定することとをも含む。その方法は、前記第２の端末からのレスポンスメッセージの受信後に、メディアを送信することを含む。

本発明の詳細な実施形態によれば、１又は複数の３Ｇ通信ネットワークを用い、短縮された起動時間でユーザ間の呼の起動プロセスを開始する方法が提供される。その方法は、１又は複数の３Ｇ通信ネットワークに接続された、少なくとも一対のＨ．３２４類似端末間に適用される。その方法は、呼信号プロセス後に、第１の端末と第２の端末との間のベアラチャンネルを確立することと、第１のＦＳＳメッセージによって定義された１又は複数の動作モードを提供することとを含む。前記１又は複数の動作モードは、コーデックの設定及び多重化テーブルエントリを含む。その方法は、前記第１の端末で、前記第２の端末からの前記第１のＦＳＳメッセージを受信することと、前記第２の端末からのレスポンスメッセージが前記第１の端末で受信される前に、前記第２の端末がメディアを受信可能であることを、前記第１の端末で、前記第１のＦＳＳメッセージから判定することとをも含む。その方法は、前記第２の端末からのレスポンスメッセージが前記第１の端末で受信される前に、メディアを送信することを含む。その方法は、前記第２の端末からのレスポンスメッセージが受信される前に、メディアを送信することをさらに含む。

本発明の代替的な実施形態によれば、１又は複数の３Ｇ通信ネットワークを用いた情報の送信方法が提供される。その方法は、１又は複数の３Ｇ通信ネットワークに接続された、少なくとも一対のＨ．３２４類似端末間に適用される。その方法は、第１の端末に情報を提供することと、誤りに対して頑健に、かつ、１又は複数の予期される標準フラグのエミュレーションが回避されるような結果となるように、前記情報をエンコードすることとを含む。その方法は、フレームシーケンスを形成するために１又は複数のフラグシーケンスでエンコードされた情報をフレーム化することと、フレームシーケンスを埋め込むことと、埋め込まれたフレームシーケンスを送信することとをも含む。

多くの利点が、従来の技術を上回る本発明によって達成される。例えば、呼起動時間を低減する本発明の実施形態は、それにより顧客の知見を高めることができる。さらに、本発明の実施形態は、既存のプロトコルとの互換性を維持する。実施形態によれば、１つ又は複数のこれらの利点が、他の利点と同様に、達成される。知る限りにおいては新規である本発明の目的、特徴、および効果は、詳細には添付の請求項に記載される。本発明は、その構成と運用方法のいずれに関しても、これ以上の目的と効果とともに、添付の図面と併せて、以下の説明を参照することで最もよく解読することができる。

Ｈ．３２４Ｍの規格勧告(補遺Ｃの拡張を付帯するＨ．３２４勧告)は、３Ｇネットワ−クの回線交換ベアラ上の対話型テレビ電話サービスの提供用に、３Ｇ−３２４Ｍの技術的仕様書として第３世代パートナーシッププロジェクト（３ＧＰＰ）によって採用された。Ｈ．３２４は、セッション起動の長い遅延に悩まされており、Ｈ．３２３とは異なり、高速な映像セッションの確立の強化の恩恵を受けていなかった。セッション起動時間の短縮がユ−ザの知見を高めることにつながるというのは産業界で一致するところである。本発明の実施形態によれば、Ｈ．３２４、Ｈ．３２４Ｍ、及び３ＧＰＰの３Ｇ−３２４Ｍのセッション起動時間を短縮する方法及びシステムを提供する。

２台のＨ．３２４Ｍ端末間の典型的なテレビ電話セッションの確立は、モバイルレベル検出やＨ．２４５のメッセージ交換のようないくつかの手順の完了を要求する。

Ｈ．３２４へのより高速なセッション起動技術の導入は、類似するテレビ電話プロトコル（Ｈ．３２３及びＳＩＰ）に起動時間を一致させ、ユ−ザの知見を大いに高めるであろう。本発明の実施形態は、Ｈ．３２４勧告に対して、１又は複数の付加又は強化（例えば１又は複数の補遺）と、高速及び／又はフレキシブルな方法でメディアチャンネルを確立させ、それによりセッション起動時間を短縮する呼手順とを提供する。明確にすることを目的として、ここに記述された技術は、高速セッション起動（ＦＳＳ）として参照される。これは、AnswerFastType4として予め知られているものである。

高速セッション起動手順に基づくベアラ

本発明の実施形態によれば、Ｈ．３２４における音声及び映像通信セッションを確立する代替的な手順としての高速セッション起動（ＦＳＳ）手順を含む方法及びシステムが提供される。その手順は、ベアラチャンネル上を送信される最初のビットとして、推奨の動作モ−ドを送る。これらのビットが、基準のＨ．３２４モ−ドを含む既存のモバイルレベルフラグをエミュレートできないようにするので、それらは既存の端末によって無視され、それで既存の端末での相互運用が維持される。その手順は、セッション起動時間を大幅に短縮させる。

フォ−ルバックメカニズムは、ＦＳＳをサポートしない接続端末のために記述される。

応用通信規格に関連する付加的な情報が存在する。例えば、以下の参考文献が、全ての目的のためにそれらの全部を参照することによってここに組み込まれる。

［１］Ｈ．３２４ ＩＴＵ−Ｔ勧告 − 低ビットレ−トのマルチメディア通信の端末．０３／２００２．
［２］３ＧＰＰ ＴＳ２４．００８ − モバイル無線インターフェイス層３仕様書；コア・ネットワ−ク・プロトコル
［３］３ＧＰＰ ＴＳ２６．１１０ 回線交換マルチメディアテレビ電話サービスのコーデック；概要
［４］３ＧＰＰ ＴＳ２６．１１１ 回線交換マルチメディアテレビ電話サービスのコーデック；Ｈ．３２４の修正

定義

発呼者：呼を発信する端末（呼び出した端末）

被発呼者：呼に応答する端末（呼び出された端末）

フォ−ルバック：端末がＦＳＳ手順を途中で中止し、Ｈ．３２４の補遺Ｃによるセッション起動を続行するときに呼び出される手順

推定共通モ−ド（ＩＣＭ）：ロ−カルプロファイルリクエスト及びピアプロファイルリクエスト（両端末で常に同じ）に基づいて両端末によって定義されるメディアモ−ド

標準モバイルレベル動作（ＮＭＬＯ）：ベアラチャンネル上のＨ．２２３マルチプレクサの標準動作。それは、ベアラチャンネル上で、与えられたモバイルレベルでＭＵＸ−ＰＤＵを送信する端末手順のフェーズＥにおけるものである。Ｈ．２４５メッセージ交換の端末手順のフェーズＤは、ＦＳＳモ−ドが受け入れられなかった場合に開始される。

再提案：通常のＨ．２４５メッセージ交換のフォ−ルバックなしに、新しくリクエストを設定してＦＳＳを再スタートする手順

リクエストフレーム：フレーム＆同期フラグセクションで規定されるリクエスト種別のＦＳＳフレーム

リクエストメッセージ：ＦＳＳリクエストフレームペイロードフィールド中に含まれる、ＡＳＮ．１でコ−ド化されたＦＳＳリクエストメッセージ。代替的に、ＦＳＳリクエストメッセージに対して他のコ−ディングも用いられ得る。

レスポンスフレーム：フレーム＆同期フラグセクションで規定されるレスポンス種別のＦＳＳフレーム。代替的に、ＦＳＳレスポンスメッセージに対して他のコ−ディングも用いられ得る。

レスポンスメッセージ：ＦＳＳレスポンスフレームペイロードフィールド中に含まれる、ＡＳＮ．１でコ−ド化されたＦＳＳレスポンスメッセージ。代替的に、ＦＳＳレスポンスメッセージのために対してコ−ディングも用いられ得る。

セッションプロファイル：使用コーデック及びオープンした論理チャンネル用のＨ．２４５のパラメ−タに従ったマルチプレクサのあらゆる側面の規定値の集合。１又は複数の側面を定義するプロファイルがここに含まれ、例えば、セッションプロファイルは、音声プロファイル及びマルチプレクサプロファイルを含んでいる。

同時判定：両接続端末が、それらの各高速セッション起動リクエストメッセージからメディアチャンネルの共通モ−ド（推定共通モ−ド）を決定する、ＦＳＳ手順のモ−ド。

フォ−マットの協約

番号を付けること、現在の仕様で用いられるフィールドマッピング及びビット送信協約はＩＴＵ−Ｔ Ｖ．４２及び３．２／Ｈ．２２３で用いられるそれらと一致している。

手順を実装している端末は、以下のフェーズを経る。

フェーズ１：高速セッション起動
フェーズ２：メディア交換

端末は、Ｃ．６＼Ｈ．３２４に記述されているように、標準モバイルレベルシ−ケンスフラグを送信することによって、ＦＳＳフェーズに割り込むことができる。ＦＦＳフェーズは、必要に応じて繰り返されるようにしてもよい。

回線交換動作、例えば、３ＧＰＰ ３Ｇ−３２４Ｍでは、２台の接続端末が、次のフェーズへ進むのを待つ間、ＦＳＳフレーム（リクエスト又はレスポンス）の送信を繰り返す。

セッションプロファイルは、事前に定義されるか、明示的に表されるようにすることができる。ＦＳＳリクエスト及びＦＳＳレスポンスメッセージは、ＦＳＳリクエストペイロード及びＦＳＳレスポンスペイロードセクションで記述される手順により、それぞれ構成される。

ＦＳＳをサポートする端末は、事前に定義されたプロファイルをサポートする。明示的なプロファイルのサポートが推奨されている。速度と柔軟性のトレ−ドオフが、ここに含まれる事前に定義されたプロファイルによって提供される。一例として、標準化された事前に定義されたプロファイルが動作ポイントの範囲を制限することによってセッション起動の速度を増加させるようにする。端末がこの技術を利用すると、ピア端末で共有された事前に定義されたプロファイルを用いた選択及び送信の大いなる可能性が存するようになる。これら事前に定義されたプロファイルのマッチングは、こうしてセッション起動速度を増加させる。明示的なプロファイルも、本発明の実施形態に含まれ、それは、柔軟性を含むというさらなる利点を提供する。

ＦＳＳ手順における事前に定義されたプロファイル

本発明の実施形態は、ＦＳＳ手順における、いくつもの事前に定義されたプロファイルを提供する。これらの事前に定義されたプロファイルは、音声コーデック、映像コーデックのプロファイル、多重化機能プロファイル、及び多重化テーブルエントリプロファイルを含む。単に一例としてではあるが、以下の事前に定義された又は事前に設定された特性を、ここに提供する。

Audio Profiles

audioProfile 0 (0x0000)
//G.723.1 Audio
maxAL-sduAudioFrames=1
silenceSuppression=false

audioProfile 1 (0x0001)
//G.723.1 Audio
maxAL-sduAudioFrames=1
silenceSuppression=true

audioProfile 4096 (0x1000)
//GSM-AMR Audio
maxAl-sduFrames=l
gsmEFRComfortNoise=false
gsmIS641ComfortNoise=false
gsmPdcEFRComfortNoise=false

Video Profiles

videoProfile 0 (0x0000)
//H.263 baseline - QCIF Video
gcifMPI=2
maxBitRate=240
unrestrictedVector=false
arithmeticCoding=false
advancedPrediction=false
pbFrames=false
temporalSpatialTradeOffCapability=false
errorCompensation=false

videoProfile 128 (0x0080)
//H.263 baseline 3G-324M
gcifMPI=2
maxBitRate=480
unrestrictedVector=false
arithrneticCoding=false
advancedPrediction=false
pbFramesH=false
temporalSpatialTradeOffCapabty=false
errorCompensation=false
advancedIntraCodingMode=true
deblockingFilterMode=true
improvedPBFramesMode=false
unlimitedMotionVectors=false
partialPictureFreezeAndRelease=false
resizingPartPicFreezeAndRelease=false
fullPictureSnapshot=false
partialPictureSnapshot=false
videoSegmentTagging=false
progressiveRefinement=false
dynamicPictureResizingByFour=false
dynamicPictureResizingSixteenthPel=false
dynamicWarpingHalfeel=false
dynamicWarpingSixteenthPel=false
independentsegmentDecoding=false
sliceslnOrder-NonRect=raesliceslnOrder-Rect=false
slicesNoOrder-NonRect=false
slicesNoOrder-Rect=false
altematelnterVLCMode=false
modifiedQuantizationMode=true
reducedResolutionUpdate=false
separateVideoBackChannel=false
videoBadMBsCap=false
dataPartitionedSlices=false
fixedPointIDCTO=false
interlacedFields=false
currentPictureHeaderRepetition=false
previousPictureHeaderRepetition=false
nextPictureHeaderRepetition=false
pictureNumber=false
spareReferencePictures=false

videoProfile 4096 (0x1000)
// MPEG4-Video
gcifMPI=2
maxBitRate=4 8 0
sliceResynchronization=false
dataPartitioning=false
reversibleVLC=false
shortHeader=false

Multiplex Capability Profiles

capabilityProfile 0 (0x0000)
// H.324 default
transportWithI-frames=false
videoWithALl=false
videoWithAL2=false
videoWithAL3 =true
audioWithAL1 =false
audioWithAL2=true
audioWithAL3=false
dataWithALl=false
dataWithAL2=false
dataWithAL3=false
maximumA12SDUsize=1024
maximumABSDUsize=1024
maximumDelayJitter=200
h223MultiplexTableCapability==basic
maxMUXPDUSizeCapability=false
nsrpSupport=false

capabilityProfile 256 (0x0100)
// H.324/M default
transportWithI-frames=false
videoWithALl=false
videoWithAL2=false
videoWitbAL3=true
audioWitliALl=false
audioWithAL2=true
audioWitbAL3=false
dataWithALl=false
dataWithAL2=false
dataWithAL3=false
maximumA12SDUsize=1024
maximumA13SDUsize=l024
maximumDelayJitter=200
h223MultiplexTableCapability=basic
maxMUXPDUSizeCapability=false
nsrpSupport=true
modeChangeCapability=false
h223AnnexA=true
h223AnnexADoubleFlag=false
h223AnnexB=true
h223AnnexBwithHeader=false
videoWithAL1M=false
videoWitbAL2M=false
videoWithAL3M=true
audioWithALlM=false
audioWithAL2M=true
audioWithAL3M=false
dataWithALlM=false
dataWithAL2M=false
dataWithAL3M=false
alpdulnterleaving=false
maximumALlMPDUSize=1080
maximumAL2MPDUSize=4096
maximumAL3MSDUSize=4096

capabilityProfile 4096 (OxIOOO)
// 3G-324M default
tansportWithl-frames=false
videoWitliAL1=false
videoWithAL2=true
videoWithAL3=true
audioWithALl=false
audioWithAL2==true
audioWithAL3=false
dataWithALl=false
dataWithAL2=false
dataWithAL3=false
maximumA12SDUsize=l024
maximumA13SDUsize=l024
maximumDelayJitter=200
h223MultiplexTableCapability=basic

maxMUXPDUSizeCapability=false
nsrpSupport=trae
modeChangeCapability=false
h223AnnexA=true
h223AnnexADoubleFlag=false
h223AnnexB=true
h223AnnexBwithHeader=false

Multiplex Table Entries Profiles

Note Audio channels are represented as Al, A2, A3, ... Video channels are represented as V1. V2. V3, ...
multiplexProfile 0 (0x0000)
1= (LCN Al3RC UCF}
multiplexProfile 1 (0x0001)
1= (LCN Vl3RC UCF}
multiplexProfile 16 (0x0010)
1=(LCN A13RC UCF},
2={LCN Vl5RC UCF}

multiplexProfile 512 (0x0200)
1={LCN Al5RC UCF},
2=(LCN Vl3RC UCF},
3={LCN Al5RC 251, {LCN Vl3RC UCF}
4={LCN Al ,RC 2215 (LCN Vl ,RC UCF}
5={LCN Al5RC 5}, {LCN Vl3RC UCF}
6={LCN Al5RC 25}, {LCNO3RC UCF}
7={LCN Al5RC 22}, {LCNO3RC UCF}
8={LCN Al3RC 5), {LCNO3RC UCF}

multiplexProfile 513 (0x0201)
1={LCN Al7RC UCF},
2={LCN Vl3RC UCF},
3={LCN Al5RC 261, {LCN Vl5RC UCF}
4={LCN AI.RC 231, {LCN Vl5RC UCF}
5={LCN Al5RC 6I5 {LCN Vl, RC UCF}
6={LCN Al5RC 261, {LCNO5RC UCF}
7={LCN Al5RC 231, {LCNO5RC UCF}
8={LCN Al5RC 61, {LCNO5RC UCF}

multiplexProfile 528 (0x0210)
1=(LCN AI5RC UCF},
2=(LCN VI1RC UCF},
3={LCN A1,RC 321, {LCN Vl5RC UCF}
4={LCN Al5RC 201, {LCN Vl, RC UCF}
5={LCN AI7RC 191, {LCN Vl5RC UCF}
6={LCN Al3RC 17}, {LCN VI5RC UCF}
7={LCN Al5RC 151, {LCN Vl5RC UCF}
8={LCN Al5RC 141, {LCN Vl3RC UCF}
9={LCN Al5RC 71, {LCN Vl5RC UCF}
10={LCN Al3RC 2), {LCN Vl5RC UCF}
11={LCN Al5RC 32I5 {LCNO3RC UCF}
12={LCN Al5RC 71, {LCNO3RC UCF}
13={LCN Al ,RC 21 , {LCNO5RC UCF}

multiplexProfile 529 (0x0211)
1={LCN AI3RC UCF},
2={LCN Vl5RC UCF},
3={LCN Al5RC 331, {LCN Vl5RC UCF}
4={LCN Al3RC 21}, {LCN Vl3RC UCF}
5={LCN Al3RC 20}, {LCN V L5RC UCF}
6={LCN Al3RC 18} , {LCN Vl5RC UCF}
7={LCN A1,RC-16}5 {LCN Vl5RC UCF}
8={LCN Al5RC 151, {LCN VI5RC UCF}
9={LCN Al5RC 8}, {LCN Vl5RC UCF}
10={LCN AI3RC 3}, {LCN VLRC UCF}
11={LCN AI3RC 33}, {LCNO3RC UCF}
12={LCN Al5RC 8}, {LCNO5RC UCF}
13={LCN Al5RC 3}, {LCNO5RC UCF}

これらの基準のプロファイルに加えて、本発明の実施形態によれば、同等な機能性を提供する独自仕様のプロファイルが含まれる。これら独自仕様のプロファイルは、他の利点の中でもサービスの柔軟性の増大を提供するであろう。当業者は、多くの変化、修正と代替物を認識するであろう。

フレーム＆同期フラグ

ＦＳＳリクエストフレーム及びＦＳＳレスポンスフレームは、オクテットで配列され、図１に示される構造を有している。

フレームインフォメ−ション（ＦＩ）フィールドは、３ビットのフレーム種別（ＦＴ）、続く３ビットのセグメントシ−ケンス番号（ＳＳＮ）、続く１ビットのラストＳＳＮ（ＬＳ）、続く１ビットのペイロードマ−カ（ＰＭ）から成る。Ｆ１フィールドのビット配列は、図２に示されている。

ＦＴフィールドは、高速セッション起動フレーム種別フィールドの記述を提供する、表１に示される値を有している。

ＳＳＮ及びＬＳフィールドの使用は、以下のＦＳＳペイロード分割及び再構成セクションに規定されている。

図２を参照すると、ＰＭフィールドは、１が設定されていたら、ペイロード長（ＰＬ）フィールドが存在していることを示している。０が設定されていたら、ＰＬは、存在せず、ＰＬ＝０である。

シ−ケンス番号（ＳＮ）フィールドは、ＬＳに１が設定されていたときに存在する。それは、ＦＳＳリクエストフレーム又はＦＳＳレスポンスフレームのシ−ケンス番号を示している。番号は０から始まる。ＦＳＳリクエストでは、それは、リクエストの再提案の総数と、任意のそれに続くレスポンス（単数又は複数）の逆提案の総数とを示している。ＦＳＳレスポンスでは、それは、レスポンスに関連する受信ＦＳＳリクエストのＳＮにマッチし、すなわち、受信ＦＳＳレスポンスの２５６を法とするＳＮの増加分である。

ペイロード長（ＰＬ）は、エミュレ−ション挿入オクテットの適用前のオクテッドでのペイロードの大きさを示している。ＦＳＳフレームペイロード又はＦＳＳ−ＰＤＵは、１５０オクテットを超えない。レシ−バは、以下のエミュレ−ション回避セクションで記述されたフラグエミュレ−ション回避手順中に挿入されたどんなオクテットを除いて１０５０オクテット以上の全体的なＦＳＳ−ＭＤＵのペイロード長をサポートする。

ペイロードは、それが存在する場合、FastSessionSetupRequestメッセージ、FastSessionSetupResponseメッセージ、又は単一のＨ．２２３ＭＵＸ−ＰＤＵのいずれかに対応する。ペイロードが存在するとき、ＰＭフィールドには１がセットされる。
FastSessionSetupRequestとFastSessionSetupResponseメッセージのＡＳＮ．１の定義及びこの補遺で参照される他の全てのＡＳＮ．１メッセージは、以下のＦＳＳ手順セクションのためのＡＳＮ．１構文で記述され、ＩＴＵ−Ｔ Ｒｅｃ．Ｘ．６９１で定義されるように、パックドエンコーディングルール（ＰＥＲ）によりエンコードされる。

ＣＲＣ(巡回冗長コード)フィールドは、１６ビットであり、ＦＳＳ同期フラグ(以下参照)を除くフレーム全体にＣＲＣを適用することによって決定される。ＣＲＣは、８．１．１．６．１／Ｖ．４２に記述されたとおりである。ＣＲＣは、以下のＦＳＳフラグエミュレ−ション回避セクションで記述されたＦＥＡ手順に先だって計算される。

ＣＲＣエラーを検出すると、対応するＦＳＳフレームは破棄される。

いくつかの実装のために、ＦＳＳフレームのいくつかのフィールドは完全に使用されない。これらのフィールドは、いくつかの実施形態で予約済みのビット又は固定コ−ド化された値が投入され、こうして、システムの複雑さが低減される。

図３は、本発明の一実施形態によるＦＳＳ同期フラグの定義を示す。他のフラグは、他の実施形態で利用され、ネゴシエートされていない多重化テーブルエントリ用の標準のマルチプレクサＰＤＵのフレーミングを含んでいる。

１本のＦＳＳ同期フラグは、各ＦＦＳフレームの直前に挿入され、１本のＦＳＳ同期フラグが、各ＦＦＳフレームの直後に挿入される。１本のＦＳＳ同期化フラグだけが、２つの連続したＦＳＳフレームの間に存在するようになる。

ＦＳＳリクエストペイロード

ＦＳＳリクエストペイロードは、ＡＳＮ．１のFastsessionsetupRequestメッセージによって表現され、端末が、事前に定義されたセッションプロファイルか明示的なセッションプロファイルの定義のいずれを用いるのかを許可する。詳細な実施形態では、端末が、事前に定義されたセッションプロファイルか明示的なセッションプロファイルのどちらかを使うことができるようにするために、１又は複数の事前に定義されたルール又はプロファイル・タイプの優先度を示す１又は複数の優先傾向に基づいて、事前に定義されたプロファイルか、明示的なセッションプロファイルかのいずれかの選択が行われる。単に一例としてではあるが、所定及び明示的なプロファイルの両方を用いることができる２台の端末ならば、明示的なプロファイルを用いることを選択するかもしれない。プロファイルの選択は、特定のアプリケ−ションに依存する。nonStandardフィールドは、非標準ベースのＦＳＳリクエストが規定されるのを許可する入れ物である。
nonStandardフィールド内に提供される付加的な情報の例としては、MultiplexTableEntry、Userlnputlndication、又はGenericCapabilityがある。

predefinedProfileフィールドは、事前に定義されたプロファイルアプロ−チを用いるＦＳＳリクエストの詳細な設定を含んでおり、以下の事前に定義されたプロファイルセクションを有するＦＳＳで記述される。explicitProfileフィールドは、明示的なプロファイルアプロ−チを用いるＦＳＳリクエストの詳細な設定を含んでおり、以下の明示的なプロファイルセクションを有するＦＳＳで記述される。

ＭＵＸ−ＰＤＵは、ＦＳＳリクエストペイロードに含まれない。

ＦＳＳレスポンスペイロード

ＦＳＳレスポンスペイロードはFastSessionSetupResponseメッセージによって表され、端末が、事前に定義されたセッションプロファイルか明示的なセッションプロファイル定義のどちらかを用いるのを許可する。nonStandardフィールドは、非標準ベースのＦＳＳレスポンスが規定されるのを、許可するための入れ物である。predefinedProfleフィールドは、事前に定義されたプロファイルアプロ−チを用いるＦＳＳレスポンスの詳細の設定を含んでおり、以下の事前に定義されたプロファイルセクションを有するＦＳＳで記述される。explicitProfileフィールドは、明示的なプロファイルを用いたＦＳＳレスポンスの詳細の設定を含んでおり、以下の明示的なプロファイルセクションを有するＦＳＳで記述される。

高速セッション起動ペイロード分割及び再構成（ＦＳＳＰＳＲ）手順

メッセージデータユニット(ＦＳＳ−ＭＤＵ)のサイズが、１５０オクテットを超えた場合、それはプロトコルデータユニット(ＦＳＳ−ＰＤＵ)と呼ばれる複数の副ユニットに分割される。ＦＳＳ−ＭＤＵが、分割されることなく、1つのＦＳＳ−ＰＤＵ５に直接マッピングされる場合、ＦＳＳフレームのＦＩフィールドにおけるＬＳフラグには、１がセットされる。ＦＳＳ−ＭＤＵが、１より大きい数のセグメントにマッピングされる場合、ＬＳフラグは、最後のセグメントを除いて０にセットされ、最後のセグメントのＬＳフラグには、１がセットされることになる。ＳＮＮには、最初のセグメントには０がセットされ、最後のセグメントまで単調増加し、その最大値は６である。値７は予約済みである。全てのセグメントは少なくとも１回送信される。

ＦＳＳ−ＭＤＵの受信及び再構成上、１又は複数の対応するＦＳＳ−ＰＤＵが、誤りを有する状態で受信された場合、再構成処理が、再構成されたＦＳＳ−ＭＤＵを処理する前に、ＦＳＳフレーム配信の次のサイクルを待つようにする。

ＦＳＳフラグエミュレ−ション回避

ベアラ上に、ＦＳＳフレームを送信する前に、フラグエミュレ−ション回避(ＦＥＡ)手順が、Ｈ．３２４の全てのモバイルレベルの同期フラグ(モバイルレベル０−３のフラグ)に対して実行される。フレーム情報、ペイロード長、ペイロードとＣＲＣを有するフィールドが、ＦＥＡ手順に含められる。値０ｘＡ３、０ｘ３５、０ｘＥｌ、０ｘ４Ｄ、０ｘ１９、０ｘＢ１及び０ｘ７Ｅを有するＡＵオクテットは、同じ値で隣接するオクテットに挿入することによって複製される。

事前に定義されたプロファイルを有するＦＳＳ

本発明の実施形態によれば、事前に定義されたプロファイルを有するＦＳＳを含む方法及び技術が提供される。例えば、事前に定義されたプロファイルリクエストペイロードは、以下のフィールドを有するＡＳＮ．１のメッセージである
FastSessionSetupPredefinedRequestによって表現される：

versionは、そのメッセージを送信する端末によって用いられるＦＳＳの事前に定義されたプロファイルバージョン番号を示している。それは、その勧告の現在のリリ−スでは１にセットされている。

h245versionは、メッセージを送信する端末によって用いられる１−１．２４５のバ−ジョン番号を示している。

vendorldは、メッセージを送信する端末用のＩＴＵ−Ｔ Ｒｅｃ．Ｈ．２４５によって採用されるように、ユニークな製造供給元の識別子を示している。

terminalTypeは、ＩＴＵ−Ｔ Ｒｅｃで規定されるように、端末の種別番号を示している。それは、Ｈ．２４５マスタ−スレーブ判定信号エンティティで用いられるものと同じ値を有する。

initialMobileLevelは、最初の端末がサポートできる開始時の最大モバイルレベルを示している。

h2231nfoは、サポートされるＨ．２２３の規定の設定を示している。
これは、h223AnnexADoubleFlag、h223AnnexBOptionalHeader及びmultiplexProfilesを含む。h223AnnexADoubleFlagは、最初のモバイルレベルとしてか最終的なモバイルレベルとしてかのいずれかとして、モバイルレベル１のＨ．２２３補遺Ａの２倍フラグモードの使用を示している。
h223AnnexBOptionalHeaderは、最初のモバイルレベルか最終的なモバイルレベルかのいずれかとして、モバイルレベル２か３のＨ．２２３補遺Ｂのオプショナルヘッダモードの使用を示している。multiplexProfileは、事前に定義された多重化テーブルプロファイルのうち、どのプロファイルが、メッセージを送信する端末によって用いられているかを示している。

capabilityProfileは、事前に定義された多重化機能プロファイルのうち、どのプロファイルが、メッセージを送信する端末によって用いられているかを示している。

audioProfilesは、使用の優先度に応じて秩序づけられた、事前に定義された音声プロファイルのリストを含んでいる。他の実施形態によれば、事前に定義された音声プロファイルのリストは、不規則であり、使用の優先度に応じてというよりむしろ能力を表現するために用いられている。

videoProfilesは、使用の優先度に応じて秩序づけられた、事前に定義された映像プロファイルのリストを含んでいる。他の実施形態によれば、事前に定義された映像プロファイルのリストは不規則であり、優先度に応じてというよりむしろ能力を表現するために用いられている。

dataApplicationProfilesは、使用の優先度に応じて秩序づけられた、事前に定義されたデータプリケ−ションプロファイルのリストを示している。このパラメ−タは予約済みであり、用いられない。このパラメ−タを受信しても、それは無視される。

encryptionProfilesは、使用の優先度に応じて秩序づけられた、事前に定義された暗号化プロファイルのリストを含んでいる。このパラメ−タは予約済みであって用いられない。このパラメ−タを受信しても無視される。他の実施形態によれば、事前に定義された暗号化プロファイルのリストは、不規則であり、優先度に応じてというよりむしろ能力を表現するために用いられている。

additionalParametersは、使用の優先度に応じて秩序づけられた非標準のプロファイルを含む、事前に定義された寄せ集めのプロファイルのリストを含んでいる。このパラメ−タは、予約済みであり、用いられない。このパラメ−タを受信しても、それは無視される。

mediaTunnelは、端末が、任意のＦＳＳレスポンスのペイロードとしてトンネル化されたメディアを受け入れることを示している。ＦＡＬＳＥがセットされたとき、端末は、いずれのＦＳＳレスポンスのメディアペイロードもサポートしない。mediaTunnelが、ＴＲＵＥにセットされた例によれば、端末は、好ましくは、直ちにメディアを受信するために適応する。例えば、受信端末でのメディアのバッファリングが、メッセージ処理時間、能力設定優先度のメッセージの衝突／消失、又は、レスポンス、それに類する送信されたもののいずれかに対応するように実行される。したがって、例えば、ピア端末によって送られた能力設定優先度又はレスポンスの消失が発生すると、メディアを受信する端末は、再送された、能力設定優先度又はレスポンスメッセージがピア端末から受信されるまで、そのメディアをバッファする。

modeDetermination：byCalleeにセットされたとき、応答する端末が動作モ−ドを決定し、発呼者に、そのＦＳＳレスポンスフレームでのモ−ドの情報を送信する。simultaneousにセットされたとき、セッションプロファイルは、推論共通モードとして両端末によって定義される。

事前に定義されたプロファイルレスポンスペイロード

ＦＳＳ同時判定では、事前に定義されたプロファイルレスポンスはいずれのメッセージペイロードも含まない。それがなされれば、そのメッセージペイロードは無視される。

ＦＳＳ非同時判定メカニズムでは、事前に定義されたプロファイルレスポンスは、次のフィールドを有するFastSessionSetupPredefinedResponseというＡＳＮ．１のメッセージペイロードから成る：

version、h245version、vendorld、terminalType及びcapabilityProfileは、上述した意味と同じような意味である。

mobileLevelは、２台の接続端末の間で最終的に選択された共通のモバイルレベルを示している。その選択は、スタッフィングフラグの送信が適用されないのを除いて、Ｃ．６．２と同一である。

h223Infoは、サポートされるＨ．２２３の詳細な設定を示している。これは、h223AnnexADoubleFlag、h223AnnexBOptionaIHeader及びmultiplexProfileを含む。h223AnnexADoubleFlagは、最終的なモバイルレベルとしてモバイルレベル１のH.２２３補遺Ａの２倍のフラグモードの使用を示す。
h223AnnexBOptionalHeaderは、最終的なモバイルレベルとしてモバイルレベル２又は３のＨ．２２３補遺Ｂのオプショナルヘッダモードの使用を示している。
multiplexProfileは、事前に定義された多重化テーブルプロファイルのいずれが、メッセージを送信する端末によって用いられたかを示している。

audioProfilesは、両メディア方向の事前に定義された音声プロファイルのリストを含んでいる。そのリストは、出て行く方向の少なくとも１本の音声のチャンネルパスと、入って来る方向のそれとを含んでおり、それは、ＰＰＩのＭＤＩによって示される。例えば、双方向の音声チャンネルに対して、少なくとも１つの音声プロファイルが特定される。そのリストが各々のメディア方向で単一方向の音声チャンネルから成る場合には、そのときには、少なくとも２つの音声プロファイルが特定される。

videoProfilesは、両メディア方向の事前に定義された映像プロファイルのリストを含んでいる。そのリストは、出て行く方向に少なくとも１本の映像チャンネルパスと、入って来る方向のそれとを含んでおり、それはＰＰＩのＭＤＩによって示される。例えば、双方向の映像チャンネルに対して、少なくとも１つの映像プロファイルが特定される。そのリストが、各々のメディア方向で単一方向の映像チャンネルから成る場合、そのときには少なくとも２つの映像プロファイルが特定される。

dataApplicationProfilesは、両メディア方向の事前に定義されたアプリケーションプロファイルのリストを含む。そのリストは、出て行く方向に少なくとも１本のデータアプリケーションチャンネルパスと、入ってくる方向のそれとを含んでおり、それはＰＰＩのＭＤＩによって示される。例えば、双方向のデータアプリケーションチャンネルに対して、少なくとも１つのデータアプリケーションプロファイルが特定される。そのリストが、各々のメディア方向で単一方向のデータアプリケーションチャンネルから成る場合、そのときには少なくとも２つのデータアプリケーションプロファイルが特定される。このパラメータは、予約済みで、用いられない。このパラメータを受信しても、無視される。

encryptionProfilesは両メディア方向の事前に定義された暗号化プロファイルのリストを含む。そのリストは、出て行く方向に少なくとも１本の暗号化チャンネルパスと、入ってくる方向のそれとを含んでおり、それはＰＰＩのＭＤＩによって示される。例えば、双方向の暗号化チャンネルに対して、少なくとも１つの暗号化プロファイルが特定される。そのリストが、各々のメディア方向で単一方向の暗号化チャンネルから成る場合、そのときには少なくとも２つの暗号化プロファイルが特定される。このパラメータは、予約済みで、用いられない。このパラメータを受信しても、無視される。

additionalParametersは、非標準プロファイルを含む事前に定義された寄せ集めのプロファイルのリストを含む。このパラメ−タは予約済みであって用いられない。このパラメ−タを受信しても、それは無視される。

事前に定義されたプロファイル及びインデックス

事前に定義されたプロファイルは、音声コーデック、映像コーデック、多重化機能及び多重化エントリテーブルのような、事前に定義されたパラメ−タの全てのセットを表すために事前に定義されたプロファイル・インデックス（ＰＰＩ）と呼ばれる、単一のインデックスを使用する。それは、各メディア種別用のメディア方向インデックス（ＭＤＩ）をも含む。他の実施形態によれば、これらのプロファイルのサブセットは、個々のアプリケ−ションに応じて適切に使用される。例えば、事前に定義されたプロファイルは、特殊な構成の音声コーデック又は論理チャンネルに関する全チャンネルの状態を表すようにしてもよい。

音声コーデック、映像コーデック、多重化機能及び多重化エントリテーブルの基準のプロファイルは、この勧告で定義されている。これらの基準のプロファイルは、上述のＦＳＳ手順セクションの事前に定義されたプロファイルで規定されている。追加のプロファイルは、通常の標準化手続を通じて加えることができる。

図４は、本発明の一実施形態によるＰＰＩの構造を示す。図４に示されるように、ＰＰＩは、１６ビットによって表現されている。最上位３ビット（ＭＳＢ）（ビット１４からビット１６）は、異なるメディア方向及びアダプテーション層種別のセクションのメディアチャンネル内に記述されるように、メディア方向インデックス（ＭＤＩ）を表す。残りの最下位１３ビット（ＬＳＢ）（ビット１からビット１３）は、詳細なプロファイル・インデックス（ＤＰＩ）を表す。０ｘ［３，５，７，９，Ｂ，Ｄ，Ｆ］ＦＦＦを有するＰＰＩ値が予約済みである。

ＤＰＩでは、５ビットのＭＳＢ（ビット１３からビット９）は、メディアの場合のメディア種別、多重化機能の場合の多重化機能カテゴリ、又は多重化エントリテーブルの場合の多重化カテゴリのいずれかを有するＤＰＩプロファイルカテゴリ−インデックス（ＤＰＩ−ＣＩ）を表す。８ビットのＬＳＢ（ビット１からビット８）は、特定のメディア、多重化機能、多重化エントリテーブルのプロファイルのユニークな識別子であり、プロファイル識別子（ＤＰＩ−ＰＩＤ）と呼ばれている。

表２は、本発明の一実施形態によるＤＰＩ−ＣＩの範囲を示す。

表３は、本発明の一実施形態による２０より小さい値のＤＰＩ−ＣＩのＤＰＩ−ＰＩＤの範囲を示す。

図５は、本発明の一実施形態によるＰＰＩにおけるＤＰＩの構造を示す。

ＩＴＵ−Ｔ Ｒｅｃ．Ｈ．３２４及び３ＧＰＰ ３Ｇ−３２４Ｍのセッションプロファイルの定義は、しばしば、分離したドキュメントで拡張される。定義された基準のプロファイルは、上述のＦＳＳ手順セクションの事前に定義されたプロファイルで記述される。

同一及び異なるメディア種別の複数のメディアチャンネルが、１つの機能記述子として０ｘ１ＦＦＦの値を有するＰＰＩセパレ−タの使用によってサポートされている。単独で、ＰＰＩセパレ−タは、直前に特定されるメディア優先度の同じセットを使用することを示している。そうでなければ、メディア優先度の付加的なセットはＰＰＩに従う。

事前に定義された音声プロファイル

音声コーデック種別の５ビットのＤＰＩ−ＣＩは、表４で示されるようにコーデックを定義する。

基準となる事前に定義された音声プロファイルの詳細は、上述のＦＳＳ手順セクションの事前に定義されたプロファイルに定義されている。

事前に定義された映像プロファイル

表５は、本発明の一実施形態による、事前に定義された映像コーデック種別の定義を示す。表５に示されるように、映像コーデックの５ビットＤＰＩ−ＣＩは、特定の実施形態で利用される。

基準となる事前に定義された映像プロファイルの詳細は、上述のＦＳＳ手順セクションのプロファイルに定義されている。

多重化機能プロファイル

多重化機能の５ビットＤＰＩ−ＣＩは、表６で示されるように多重化機能プロファイルを定義する。

基準となる事前に定義された多重化機能プロファイルの詳細は、上述のＦＳＳ手順セクションの事前に定義されたプロファイルに定義されている。

多重化テーブルエントリプロファイル

多重化エントリテーブル種別のための５ビットＤＰＩ−ＣＩは、表７に示されるように多重化テーブルプロファイルを定義する。

論理チャンネルは、前もって割り当てられている。１又は複数の音声チャンネルに対して、論理チャンネルの番号は、１(Ａ１)、１７（Ａ２）、３３（Ａ３）、…である。

１又は複数の映像チャンネルに対して、論理チャンネル番号は、２（Ｖ１）、１８（Ｖ２）、３４（Ｖ３）である。

１又は複数のデータプリケ−ションチャンネルに対して、論理チャンネル番号は３（Ｄ１）、１９（Ｄ２）、３５（Ｄ３）…である。

１又は複数の非標準チャンネルに対して、論理チャンネル番号は４（０１）、２０（０２）、３６（０３）…である。

任意の多重化テーブルＰＰＩの事前に定義された番号の最大値は１３である。

基準となる事前に定義された多重化テーブルプロファイルの詳細は、補遺IV．２．４に定義されている。

ＦＳＳの事前に定義されたプロファイルの交換手順

一度ベアラが確立されると、ＦＳＳをサポートする端末は、直ちにＦＳＳリクエストフレームを送信するようになる。そのフレームは、同時判定が呼び出されるかどうかに依存して、以下の状態のうちの１つが満たされるまで、繰り返される：

−ＦＳＳリクエストフレームが、非同時判定により被発呼者で検出された；ＦＳＳリクエストフレームが、同時判定により検出された

−ＦＳＳレスポンスフレームが検出された;

−Ｃ．６＼Ｈ．３２４に記述されるように、有効なモバイルレベルスタッフィングフラグが検出された;

−タイマＴ４０１終了。

本発明のいくつかの実施形態によれば、ＦＳＳレスポンスフレームはアックとして用いられ、動作条件を定義するために用いられない。この場合、受信した端末が、さらなるＦＳＳフレームを送信する必要はない。

有効なモバイルレベルスタッフィングフラグが検出されたとき、あるいはタイマＴ４０１が有効なＦＳＳフレームを検出する前に終了したとき、補遺Ｃによると、標準のＨ．３２４セッション手順が用いられる。これは、ＦＳＳフォールバックとも呼ばれる。

ＦＳＳリクエストが検出されると、ペイロードが処理される。

ペイロードの解読に成功すれば、端末は、ＦＳＳレスポンスフレームを送ることにより、それを受け入れる。ＦＳＳレスポンス自体は、modeDeterminationセクション及びmediaTunnelモ−ドセクションで定義されるＦＳＳリクエストにおけるmodeDetermination及びmediaTunnelフラグに依存するメッセージペイロードデータ又はメディアペイロードデータを組込むようにしてもよい。次の状況のいずれかが発生するまで、メディアペイロードデータのペイロードフィールドを除いて、そのフレームは直ちに繰り返される：

−同じＳＮを有するＦＳＳレスポンスが検出される；

−新たに単調増加する２５６を法とするＳＮを有するＦＳＳリクエストフレームが検出される；

−新たに単調増加する２５６を法とするＳＮを有するＦＳＳリクエストフレームがＦＳＳの再提案中に検出される；

−Ｃ．６＼Ｈ．３２４に記述されているように、標準のモバイルレベルシ−ケンスフラグが検出される;

−タイマＴ４０１終了。

マスタ−スレーブ判定では、２台の端末のＦＳＳリクエストフレームにおけるterminalTypeフィールドが同一であるとき、発呼者がマスタとなる。terminalTypeフィールドが異なるとき、より高いterminalType値を有する端末がマスタとなる。

端末は、以下のmediaTunnelモ−ドセクションによれば、mediaTunnelをＴＲＵＥに設定することによって、任意のＦＳＳレスポンスにおいてトンネル化したメディアを受け入れるその機能を示す。

ＦＳＳレスポンスが送信された後、そして、逆提案でないＦＳＳレスポンス(レスポンスの逆提案手順)が検出され受け入れられた後、端末は、一致するモバイルレベルを用いたＮＭＬＯを開始する。
ＩＣＭによって又は受け入れられたFastSessionSetupPredefinedResponseから定義される音声及び映像の交換も、それらが、ＦＳＳレスポンスフェーズ中にまだ開始されていなかった場合には、直ちに開始される。それらがＦＳＳレスポンスフェーズ中に開始された場合には、音声及び映像の交換は絶え間なく続けられる。

ＦＳＳリクエストが検出された後、端末は、ＦＳＳ手順を進めないことを決定してもよい。それは、高速セッション起動フォールバック手順の仕様セクションに記載された手順に従う。

ＦＳＳリクエストが送られ、ＦＳＳリクエストが検出された後、端末が、ＦＳＳレスポンスフレームを検出しないが、有効なモバイルレベルスタッフィングフラグを検出した場合には、その端末は、高速セッション起動フォールバック手順の仕様セクションに記載された手順に従う。

FastSessionSetupPredefinedResponseを受信した後、端末がレスポンスを受け入れないが、修正されたリクエストを実行しようとする場合には、リクエスト再提案手順セクションに記載されたリクエスト再提案手順に従う。もし、端末が、レスポンスを認めないがレスポンスの逆提案をしようとする場合には、それは、レスポンス逆提案手順セクションに記載された手順に従う。

ＦＳＳ手順の開始でＦＳＳリクエストを受信する前に、メッセージペイロードなしにＦＳＳレスポンスを受信すると、送信されるＦＳＳレスポンスは、ＳＳＮが７にセットされる。メッセージペイロードなしにＳＳＮが７にセットされたＦＳＳレスポンスを受け取ることで、端末は、ＮＭＬＯを開始するメディアビットストリームの生成を再スタートさせるためにリセットする。ＦＳＳレスポンスフレームでトンネル化されたメディアの送信は、無視される。

予期しないＦＳＳフレームを受信しても、それらは無視される。

modeDetermination

FastSessionSetupPredefmedRequestのmodeDeterminationフィールドが、一方又は両方の端末、byCalleeにセットされているとき、被発呼者は、両端末の能力以内で両方向のＰＰＩの形式で、選択された論理チャンネルを、そのFastSessionSetupPredefinedResponse内に入れて送信する。発呼者は、被発呼者からのFastSessionSetupPredefmedResponseを受信した後でだけ、メッセージペイロードなしにＦＳＳにレスポンスフレームを送信する。

両端末からFastSessionSetupPredefinedRequestのmodeDeterminationがsimultaneousにセットされているとき、ＩＣＭは、以下の異なるメディア方向を有するメディアチャンネル及びアダプテーション層種別セクションに記述された情報を有するＣ．４．１．３／Ｈ．２４５及びＣ．５．１．３／Ｈ．２４５における論理チャンネルの選択により両端末によって定義される。両端末のＦＳＳレスポンスフレームは、ＩＣＭを受け入れることで、いずれのメッセージペイロードも含まないようにする。他の実施形態によれば、ＦＳＳレスポンスフレームは送信されず、ＩＣＭを用いて送信されるメディアが、成功したセッション起動の承認と解釈される。

mediaTunnelモ−ド

FastSessionSetupPredefinedRequestのmediaTunnelフラグが、ＦＳＳレスポンスフレームでトンネル化された受信メディアにおけるその機能を示すために端末によってセットされる。端末がmediaTunnelモ−ドで動作していない場合、端末は、望ましくは、メディアを送信する前に、ＦＳＳレスポンスメッセージを受信するのを待つ。

端末からのmediaTunnelがＴＲＵＥに設定されているとき、ピア端末は、メッセージペイロードを要求しないＦＳＳレスポンスフレーム内にメディアデータのトンネルを形成する。メディアをトンネル化した端末は、いずれのモバイルフラグもないＦＳＳレスポンスフレームのペイロードとして、最終的に一致するモバイルレベルを用いたＩＴＵ−Ｔ Ｒｅｃ．に従って１つのＨ．２２３のＭＵＸ−ＰＤＵを送信する。ＦＳＳＰＳＲは、メディアペイロードには適用されない。ＭＵＸ−ＰＤＵは、ＦＳＳレスポンスフェーズが完了し、標準メディア送信フェーズ（ＮＭＬＯ）が開始されるまで、連続して送られる。端末が、そのFastSessionSetupPredefinedRequestのmediaTunnelにＦＡＬＳＥをセットしたとき、ピア端末は、そのＦＳＳレスポンスフレームにいずれのメディアに対してもトンネルを形成しない。

リクエストの再構成手順

端末は、高速セッション起動フォールバック手順規定セクションに記述されているように、フォールバックの代わりに新しいＦＳＳリクエストの再提案することを選択してもよい。

両端末のFastSessionSetupPredefinedRequestのmodeDeterminationがsimultaneousにセットされ、端末が、ピア端末からのＦＳＳリクエストを受けないときには、ＦＳＳリクエストフレームのＳＮを、新しいリクエスト設定をもって、２５６を法として１増加させることにより、新しいＦＳＳリクエストを再提案してもよい。両端末が、同時に新しいＦＳＳリクエストを再提案した場合、両端末によってmodeDeterminationがsimultaneousに設定されたことが提供される同時判定モードの採用が継続される。両端末が、同時に新しいＦＳＳリクエストを再提案し、いずれかの端末がmodeDeterminationをbyCalleeにセットした場合、非同時判定が採用される。

同時判定再提案モードは、推論共通モ−ド(ＩＣＭ)が、両端末によって定義されるか、端末が、高速セッション起動フォールバック手順仕様書セクションに記載されたフォールバック手順に従うのを決定するまで、繰り返される。同時判定再提案モ−ドは、非同時判定モードに準じ、逆もまた同様である。

少なくとも１台の端末が、FastSessionSetupPredefinedRequestで、modeDeterminationをbyCalleeにセットし、応答端末が、最初の試みで発呼者からのＦＳＳリクエストを受け入れないとき、応答端末は、ＦＳＳリクエストフレームのＳＮを、新しいリクエストの設定で、２５６を法とする１だけ増加させることによって、そのリクエストを再提案してもよい。発呼者が、応答端末によってＦＳＳリクエストを受け入れたとき、最後に選択されたＦＳＳリクエストフレームのそれにマッチするＦＳＳレスポンスフレームのＳＮを有するＦＳＳレスポンスを送ることによって応答端末に応答する。発呼者が、応答端末によってＦＳＳリクエストを受け入れないとき、発呼者は、新しいメッセージ設定をもって、２５６を法としてＦＳＳリクエストのＳＮを１だけ増加させることにより、そのリクエストを再提案してもよい。

端末が、ＦＳＳレスポンスを受け入れなければ、上述したような新しいＦＳＳリクエスト再提案してもよいし、レスポンス逆提案手順セクションで記述されるように、新しいＦＳＳレスポンスを逆提案するようにしてもよい。

両端末が、被発呼者によって最初に選択された共通モードを受け入れるか、又は、その後、端末の１台によって選択されるか、高速セッション起動フォールバック手順仕様セクションに記述されたフォールバック手順に従うように端末が決定するまで、非同時判定が、繰り返されるようにしてもよい。

レスポンス逆提案手順

この手順は、非同時判定のときだけ適用される。端末は、リクエスト再提案手順セクションで記述されているような新しいFastSessionSetupPredefinedRequestの再提案又は高速セッション起動フォールバック手順仕様セクションで記述されているようなフォールバックの代わりに、ピア端末からFastSessionSetupPredefinedResponseを受信した後、新しいFastSessionSetupPredefinedResponseの逆提案を選択する。

逆提案された新しいFastSessionSetupPredefinedResponseには、最後に受信したＦＳＳリクエストフレームにおいて、ＳＮから２５６を法として１だけ増加させたＦＳＳレスポンスフレームにおけるＳＮがセットされる。
FastSessionSetupPredefinedResponseの判定は、現在提案されているすべてのチャンネルプロファイルからのメディアチャンネル方向の調整を有する、受信したFastSessionSetupPredefinedResponseのメッセージの内容に基づく。受信したFastSessionSetupPredefinedResponseは、それが受け入れないチャンネルの除去と、それがサポートするチャンネルの付加により修正される。

明示的なプロファイルを有するＦＳＳ

ＦＳＳの明示的なプロファイルリクエスト

明示的なプロファイルリクエストは、FastSessionSetupExplicitRequestというＡＳＮ．１メッセージによって表されており、次のフィールドを有している：

versionは、メッセージを送信する端末によって用いられたＦＳＳの明示的なプロファイルのバ−ジョン番号を示す。

h245version、vendorld、terminalType、initialMobileLevel、mediaTunnel及びmodeDeterminationは、事前に定義されたプロファイルリクエストペイロードセクションでのそれと同じ意味を有している。

h223InfoはH.２２３でサポートされる詳細な設定を示す。
これは、h223AnnexADoubleFlag,h223AnnexBOptionalHeader及びmultiplexEntrySendを含む。
h223AnnexADoubleFlag及びh223AnnexBOptionalHeaderは、事前に定義されたプロファイルリクエストペイロードセクションでの意味と同じ意味を有している。
multiplexEntrySendは、メッセージを送信する端末によって用いられる多重化エントリテーブルを示し、Ｈ．２４５によって規定されている。

multiplexCapabilityは、メッセージを送信する端末によって用いられる多重化機能を示し、Ｈ．２４５によって規定されている。

openLogicalChannelsは、優先度によって秩序づけられて用いられる両方向のメディアチャンネルのリストを含んでおり、Ｈ．２４５によって規定される。メディアは音声、映像、データプリケ−ション及び暗号化されたものを含む。

additionalParametersは、Ｈ．２４５によりＡＳＮ．１でエンコードされるＨ．２４５メッセージのリストを含んでいる。そのリストは、付加的な情報、リクエスト、及び使用の優先度で秩序づけられた非標準のＨ．２４５メッセージを含むようにしてもよい。

ＦＳＳの明示的なプロファイルレスポンス

ＦＳＳ同時判定メカニズムでは、明示的なプロファイルレスポンスはいずれのペイロードも含まない。

ＦＳＳの非同時判定メカニズムでは、明示的なプロファイルレスポンスは、FastSessionSetupExplicitResponseというＡＳＮ．１メッセージによって表され、次のフィールドを有している：

version、h245version、vendorld及びterminalTypeは、事前に定義されたプロファイルリクエストペイロードセクションでの意味と同じような意味を有している。

mobileLevelは、事前に定義されたプロファイルレスポンスペイロードセクションでの意味と同じような意味を有している。

h223InfoはH.２２３の詳細な設定サポートを示している。
これはh223AnnexADoubleFlag、h223AnnexBOptionalHeader及びmultiplexEntrySendを含む。
h223AnnexADoubleFlag及びh223AnnexBOptionalHeaderは、事前に定義されたプロファイルレスポンスペイロードセクションでの意味と同じような意味を有している。
multiplexEntrySendは、ＦＳＳの明示的なプロファイルリクエストセクションでの意味と同じような意味を有している。

multiplexCapability及びadditionalParametersは、ＦＳＳの明示的なプロファイルリクエストセクションでの意味と同じような意味を有している。

openLogicalChannelsは、両メディア方向で選択されるメディアチャンネルのリストを含んでおり、Ｈ．２４５で規定されている。メディアは音声、映像、データアプリケ−ション及び暗号化されたものを含む。

additionalParametersは、Ｈ．２４５による、ＡＳＮ．１でエンコードされたＨ．２４５のメッセージのリストを含んでいる。そのリストは、付加的な情報、対応するFastSessionSetupExplicitRequestメッセージにおけるadditionalParametersで示されたリクエストに対するレスポンス、及び使用の優先度で秩序づけられた非標準のＨ．２４５メッセージを含む。

ＦＳＳの明示的なプロファイルリクエスト及びレスポンス交換手順

２台の接続端末が、ＦＳＳの明示的なプロファイルを用いるとき、ＦＳＳの明示的なプロファイルリクエスト及びレスポンス手順は、明示的なプロファイル及びFastSessionSetupExplicitResponseによって置き換えられる、事前に定義されたプロファイル及びFastSessionSetupPredefinedResponseの全てについて、ＦＳＳの事前に定義されたプロファイル交換手順セクションに記述された手順と同一である。

事前に定義された及び明示的なプロファイルの相互作用は、ＦＳＳの事前に定義されたプロファイル及びＦＳＳの明示的なプロファイルとの間の相互作用のセクションに記載されている。

論理チャンネル番号

論理チャンネル番号は、Ｈ．２４５のOpenLogicalChannelのリクエストメッセージでメッセージの送信元によって割り当てられる。双方向の論理チャンネルの場合では、前方向の論理チャンネル番号だけが規定される。逆方向の論理チャンネル番号は、前方向の論理チャンネル番号と同じとなる。実施形態によれば、逆方向の論理チャンネル番号が既に割り当てられていれば、次に利用可能な論理チャンネル番号が割り当てられる。最大の論理チャンネル番号は、１４である。そして、結果として１４を超える論理チャンネル番号となるOpenLogicalChannel番号のリクエストはいずれも無視される。

メッセージを要求するＨ．２４５のMultiplexEntrySendに定義された多重化テーブルエントリは、割り当てられた論理チャンネル番号にマッチする。

modeDeterminationモ−ド

その手順は、FastSessionSetupExplicitRequest及び
FastSessionSetupExplicitResponseのそれぞれによって置き換えられる、
FastSessionSerupPredefinedRequest
及びFastSessionSetupPredefmedResponseの全てについて、
modeDeterminationと同一であり、Ｈ．２４５のOpenLogicalChannelによるＰＰＩと同一である。

mediaTunnelモ−ド

その手順は、FastSessionSetupExplicitRequestによって取り替えられる、
FastSessionSetupPredefinedRequestの全てについて、mediaTunnelモ−ドと同一である。

リクエスト再提案手順

その手順は、FastSessionSetupExplicitRequestによって取り替えられる、
FastSessionSetupPredefinedRequestの全てについて１８．７と同一である。

レスポンス逆提案手順

その手順は、それぞれFastSessionSetupExplicitRequest及び
FastSessionSetupExplicitResponseによって取り替えられる、
FastSessionSetupPredefmedRequest及び
FastSessionSetupPredefinedResponseの全てについて、レスポンス逆提案手順と同一である。

ＦＳＳの事前に定義されたプロファイルとＦＳＳの明示的なプロファイルとの間の相互作用

２台の端末が、異なるプロファイル交換モード（事前に定義された、及び、明示的な）を用い、１台の端末だけが、事前に定義された及び明示的なプロファイルの交換手順をサポートしている場合、受信したプロファイル種別をデコードし、サポートする端末は、それが受信したのと同じプロファイル種別を用いるmodeDeterminationがbyCaleeにセットされたＦＳＳリクエストを再送し、ＦＳＳの事前に定義されたプロファイル交換手順又はＦＳＳの明示的なプロファイルリクエスト及びレスポンス交換手順セクションに記述された手順に従う。被発呼者が、事前に定義された及び明示的なプロファイルの両方を解読できる場合には、ＦＳＳリクエスト及びＦＳＳレスポンスを送る手順をスキップしてもよい。代替的には、被発呼者が両プロファイルを解読できる場合には、好ましいプロファイル交換モードを選択してもよい。好ましいプロファイル交換モード処理が、被発呼者によって最初に送信されるモードと同一か又は異なるモードを選択するようにすればよい。さらに、他の実施形態によれば、被発呼者は、最初の送信で事前に定義されたそして明示的なプロファイルの両方を選択する。単に一例としてではあるが、被発呼者が最初に送信される事前に定義されたプロファイルを送信し、発呼者が明示的なプロファイルを好む場合には、被発呼者は、事前に定義されたプロファイルから明示的なプロファイルにモ−ドを切り替えることを選択するようにしてもよい。ＦＳＳの事前に定義されたプロファイル交換手順又はＦＳＳの明示的なプロファイルリクエスト及びレスポンス交換手順セクションに規定された手順がそれに応じて実行され、非同時判定だけが用いられるようになる。

２台の端末が、異なるプロファイル交換モード（事前に定義された、及び、明示的な）を用い、両端末が、事前に定義された及び明示的なプロファイルの交換手順をサポートしている場合、受信したプロファイル種別をデコードし、サポートする端末は、メッセージペイロード（非同時判定）を有するＦＳＳレスポンスを送るか、それが受信したのと同じプロファイル種別を用いるmodeDeterminationがbyCaleeにセットされたＦＳＳリクエストを再送し、ＦＳＳの事前に定義されたプロファイル交換手順又はＦＳＳの明示的なプロファイルリクエスト及びレスポンス交換手順セクションに記述された手順に従う。

端末は、両プロファイルモードを解読可能とした後は、被発呼者が、それが受信したＦＳＳレスポンスを無視してもよい。被発呼者がＦＳＳレスポンスを送り、再送されたＦＳＳレスポンスフレームを受信した場合には、その受信したＦＳＳリクエストは、無視される。その被発呼者が、ＦＳＳリクエストを送り、再送されたＦＳＳリクエストフレームを受信した場合には、それは、用いるいずれかのプロファイルのモードを決定し、そして、ＦＳＳの事前に定義されたプロファイル交換手順又はＦＳＳの明示的なプロファイルリクエスト及びレスポンス交換手順にセクションに記述された手順に従う。発呼者は、ＦＳＳレスポンスフレームを受信した場合には、それは、ＦＳＳの事前に定義されたプロファイル交換手順又はＦＳＳの明示的なプロファイルリクエスト及びレスポンス交換手順セクションによるＦＳＳレスポンスフレームを処理する。

リクエストの再構成手順の相互作用

端末は、高速セッション起動フォールバック手順仕様セクションで記述されるように、フォールバックに代えて、新しいＦＳＳリクエストを再提案することを選択してもよい。

２台の端末のうち、異なるプロファイル種別を用いる少なくとも１台は、受信したリクエストを解析したが、ピア端末からＦＳＳリクエストを受け入れない場合、その端末は、ＦＳＳの事前に定義されたプロファイル交換手順又はＦＳＳの明示的なプロファイルリクエスト及びレスポンス交換手順によりピア端末として同一のプロファイル種別を用い、２５６を法として１だけ増加させたＦＳＳリクエストフレームのＳＮを有する新しいＦＳＳリクエストを送るようにしてもよい。ＦＳＳの事前に定義されたプロファイルと、ＦＳＳの明示的なプロファイルのセクションとの間の相互作用で、記述された手順が行われる。

高速セッション起動フォールバック手順仕様

ＦＳＳをサポートするＨ.３２４エンティティは、ピアのＨ．３２４エンティティがＦＳＳをサポートしていない場合のファールバック手順をサポートするか、ＦＳＳ手順の完了前に、モバイルレベルフラグを送信する。

端末が、ＦＳＳリクエストを受信しないが、同一の初期モバイルレベルで、標準のH.245のTerminalCapabilitySetメッセージでの標準の開始手順を検出した場合には、ピア端末がＦＳＳをサポートしてしないか、規定されたＦＳＳプロファイルのいずれも受け入れなかったものと見なす。
この場合には、端末は、ＦＳＳフレームの送信を停止し、従来のTerminalCapabilitySet、MasterSlaveDetermination、MultiplexEntrySend及びOpenLogicalChannel手順の使用を継続する。

端末が、同一の初期モバイルレベルで標準的なＨ．２４５のTerminalCapabilitySetのメッセージで標準の開始手順を検出した場合、端末がＦＳＳ手順を完了しても問題はなく、ピア端末には、ＦＳＳフォールバックが進められているものと考慮される。この場合には、端末は、ＦＳＳの結果を無視してもよく、セッションを確立するために従来のTerminalCapabilitySet、MasterSlaveDetermination、MultiplexEntrySend及びOpenLogicalChannel手順の使用を続ける。

端末がタイマＴ４０１以内で有効なＦＳＳフレームを検出しないか、標準の開始手順を検出しない場合には、それは、ピア端末が、ＦＳＳ及び補遺Ｃ．による標準のＨ．３２４セッション手順を継続するフォールバックをサポートしていないものとみなす。

端末が、ＰＰＩを解読せずに、ＦＳＳリクエスト又はレスポンスを受信した場合には、このセクションで記述されたＦＳＳフォールバック手順を開始する。

音声及び映像コーデック処理が、ＦＳＳレスポンスフレームの送信中に開始された場合、それらはビットストリームの生成を再スタートするためにリセットされる。

端末の手順

通信の準備段階が以下の修正を有する節Ｃ．５にリストアップされている：

フェーズＤ：この補遺に規定された高速セッション起動フェーズが、レベル起動手順前に挿入される。ＦＳＳが成功裏に完了した場合、Ｈ．２４５メッセージ交換がスキップされ、直ちに論理チャンネルが動作する。ＦＳＳフォールバックが発生した場合、初期モバイルレベル起動フェーズからの接続が継続される。

異なるメディア方向及びアダプテーション層の種別を有するメディアチャンネル

この節は、事前に定義されたプロファイルアプローチだけに当てはまる。メディアチャンネル種別は、次のフィールドによって管理される：

１．データ種別毎のアダプテーション層のサポート。フィールドは多重化機能プロファイルの範囲内ですでにカバーされている。

２．メディア方向能力

３．メディア方向モ−ド

アダプテーション層のサポートに対して、そのセッティングは、２台の端末間で開かれる最終的な論理チャンネルに影響を与えるように用いられる。アダプテーション層のサポートは、メディアのタイプ毎に以下の優先順位に従う：

1. ＡＬ１上のメディア

2. ＡＬ２上のメディア

3. ＡＬ３上のメディア

例えば、ＡＬ２上の映像と、ＡＬ３上の映像とが両方サポートされると、そのときには、ＡＬ２上の映像の方が優先され、ピア端末もそれをサポートしていれば、選択される。

ＦＳＳにおいて、アダプテーション層は、常に、以下に規定される設定で用いられる：

ＡＬ１：メディアの種別に依存してフレーム化又はフレーム化されない。ＡＬ１上の全ての音声及び映像データの種別のために、ＡＬ１は、フレーム化されたモ−ドを用いるようにセットされている。

ＡＬ２： シ−ケンス番号付き

ＡＬ３：７ビットのシーケンス番号付き。適切な勧告によって規定されるような推奨された値にセットされたバッファサイズを送る。オプションの再送信モードの使用は、その実装にゆだねられている。

オープンされた最終的な論理チャンネルの判定は、１又は複数のリクエスト再提案及び／又は逆提案のレスポンスを伴う標準のオープン論理チャンネルリクエストに従う。最終的な判定は、事前に定義されたプロファイルによるアプローチの結果である。

その判定は、アダプテーション層のサポートと、最終的なメディアモード設定を決定するためのメディア方向モードのさらなる情報を有するメディア方向機能から計算される。標準では、リクエストの全ての結合から決定される予期されるメディアは、ユニークである。そうでない場合には、１又は複数のそのリクエストの再提案が、リクエスト再提案手順セクション又はリクエスト再提案手順セクションの相互作用に記述されるように実行されるか、又は、ＦＳＳフォールバックが、高速セッション起動フォールバック手順仕様セクションで記述されるように用いられる。

予測可能な衝突が発生したとき、マスタ端末は、その好ましいメディアリストを最初に見て、結果的に、オープンすべき最終的なメディアとなることに留意する。

メディア方向インデックス（ＭＤＩ）は、最初に、ＦＳＳの事前に定義されたプロファイルによるアプローチで用いられる。さらに、以下の論理チャンネルの設定が無効であることに留意する：

１．反転するnullDataを有する双方向のＡＬ２チャンネル。

２．制御フィールドオクテットの数が０より大きい場合に反転パラメ−タが規定されていないＡＬ３。

しかしながら、次の論理チャンネル設定が有効であることに留意すること:

１．前方向のnullDataを有する双方向のＡＬ２チャンネル。

ＭＤＩを形成するメディア方向機能及びモ−ドの全ての有効な結合が、表８に示されている。

transmitModeは、一方向の論理チャンネルの使用を参照する。アダプテーション層３のため、これは、ＮＵＬＬとしての反転した論理チャンネルパラメータセットを有する双方向の論理チャンネルの使用を参照する。

transmitAndReceiveModeは双方向の論理チャンネルの使用を参照する。これは、使われるアダプテーション層の種別に依存せずに用いられる。

noTransmitModeは、入っているメディア方向の一方向の論理チャンネルの可能な使用を参照する。それは、遠くから信号を送られない限り、任意の方向の任意の論理チャンネルを開始しない。

表８に示されるように、端末は、１又は複数の与えられたチャンネルの動作モードで動作するようにしてもよい。本発明の実施形態によれば、端末は、送信と受信とを異なるモードで動作させるようにしてもよい。すなわち、チャンネルは、第１のモードでメディアを送信し、第２のモード（例えば、noTrandmitMode）でメディアを受信するようにしてもよい。他の実施形態によれば、モードは対称で、送信及び受信も両方同じである。こうして、単に一例としてではあるが、notransmitMode（ＭＤＩ＝２）のreceiveCapabilityを有するＨ２４３の映像プロファイル及びtransmitMode（ＭＤＩ＝３）のtransmitCapabilityを有するＭＰＥＧ−４の映像プロファイルを有するＦＳＳリクエストが送られる。こうして、例示した端末は、結果的に、ＭＰＥＧ−４の送信及びＨ．２６３のメディアの受信という非対称なセッションとなる。したがって、そのピア端末は、Ｈ．２６３の送信及びＭＰＥＧ−４の受信というＦＳＳリクエストの映像プロファイルのマッチングを提供する。

図６には、ベアラチャンネル上を送信されるイクイップメント・プレハード・モード（図６に示されるリクエスト及びレスポンスメッセージ）の本発明の一実施形態が示されている。イクイップメント・プレハード・モードは、米国特許出願１０／９３４，０７７のタイプIIIの実施形態に記載されたものと同様のものとすることができ、好ましいモードで明示的に記述されたもの、又はコード化されたもの（共通モードのテーブルにおけるルックアップ・インデックス）とすることができる。

図７Ａは、本発明の他の実施形態によるAnswerFast4を示す簡素化された図である。この場合には、推論又は優先度のルール・セットが各端末で用いられ、オプショナル・レスポンス・メッセージは、メディア送信が始まる前に、送ることをリクエストされることはない。図７Ｂは、AnswerFast4フレームで送信されるメディアを伴う本発明の他の実施形態によるAnswerFast4の方法を示す簡素化された図である。

AnswerFast4リクエストを送り、任意にAnswerFast4レスポンスを検出した後、端末は、一致するモバイルレベルを用いた標準セッションを開始する。音声及び映像の交換も、それらが、使用中に、AnswerFast4レスポンスステージ中に開始された場合には、ただちに開始される。本発明の実施形態を用いれば、それが開始されたのが、AnswerFast4レスポンスステージが使用中であるかいなかにかかわらず、音声及び映像交換を絶え間なく継続することができる。

図７Ａに示される実施形態で留意すべきは、応答者(エンティティＢ)が、発呼者（エンティティＢ）によってそのリクエストメッセージで提案された、プレファレンス・モードから好ましい操作モードを選択する意思決定者である。そのリクエストメッセージ中の発呼者優先モードは、１又は複数の優先モードを含めることができる。応答者のリクエストメッセージは、空とすることもでき、ダミーの情報メッセージを含めることもできる。発呼者リクエストメッセージは、空とすることができ、ダミーの情報メッセージを含め得る。応答者のレスポンスは、適用優先モード（例えば、応答者が継続するモードを決定）を運ぶ。

意思決定の役割が逆となり得ることに留意する。すなわち発呼者は、そのリクエストメッセージで、応答者によって送信される優先順位から適用されるべき優先度の決定をすることができる。

決定者を選択するもう１つの方法は、両端末にランダムな数を送信させ、最大の（又は最小の）数を有する者を決定者とする方法である。同数の場合、発呼者（又は応答者）が決定者として扱われるようになる。

決定者を指定する多くの可能性のある計画が、可能である。重要な側面は、決定者を指定する”ルール”が適用され、両端末によって用いられることである。いずれか一方で用いられたのでは、利点はない。最も簡単な実施形態の１つを示す。図６を参照すると、発呼者ＡＦ４のリクエストメッセージが以下に示す手順により構成されうる：

タイプIVのリクエスト及びレスポンス構成手順

ステップＡ：S1を装置優先メッセージ（テーブルのインデックスのような明示的な又はコード化された）とする。装置優先順位は、タイプIIIの技術で記載されたような情報を含む。メッセージは、エンコードされたＡＳＮ．１の文字列又は他の構文を用いて表現される。

ステップＢ：誤りに対して頑健にエンコードするためにS2=S1とする。誤りなくコード化された場合には、S2は、S1に等しくなる。

ステップＣ：検出及び同期を容易とすべくフレーミングフラグシーケンスでフレーム化するためにS3＝S2とする。S2におけるフレームフラグエミュレーションが、検出され、保護される必要があることに留意すべきである。保護は、反復メカニズムに用いられ得る。例えば、フレーミングフラグが＜ｆ１＞＜ｆ２＞であり、＜ｆ１＞＜ｆ２＞がS2となった場合、そのときは、＜ｆ１＞＜ｆ２＞が送信されることにより＜ｆ１＞＜ｆ２＞＜ｆ１＞＜ｆ２＞によって置き換えられる。受信者は、受信した＜ｆ１＞＜ｆ２＞＜ｆ１＞＜ｆ２＞を＜ｆ１＞＜ｆ２＞に置き換える。誤り訂正が用いられ、この手順におけるフレーミングフラグの異なるセットを用いることによって信号が送られることに留意する。

ステップＤ：複数の１６０オクテットにストリング（オクテット数）長さを拡張するためにフレームフラグシ−ケンスを埋めてフレーム化するためにS4=S3とする。このオプション的なステップは、送信時間スロットが典型的に１６０オクテットに相当する３Ｇ−３２４Ｍの実装に実用的である。パッディングが重要でなければ、S4はS3と同じとなることは重要である。

発呼者及び応答者端末は、最初のわずかなS4のオクテットが、ベアラ起動タイミングのために消失するケースが発生しないようにするために、１又は複数回（典型的には最低２回）、連続して（パッディング又は同期と、フレーミングフラグとだけは分離して）、上述のように構成されたそれらのリクエストメッセージを送信する。

発呼者端末がその好ましいモードを送信した後、それは、レスポンスを期待し、又はセッションを高速化するこの方法の従来のＨ．３２４類似の初期ベアラ送信はサポートされていない。ベアラチャンネル上で応答者が最初に送ったものは発呼者によって無視され、セッションの高速化のこの方法をサポートする、呼び出された（又は応答）端末が気づいたときに、発呼者によって用いられるだけである。呼ばれた端末は、そのメッセージが、レスポンスメッセージであるメッセージでの再構成手順により構成されていることだけが異なるタイプIIIの動作で記述されるように、受け入れた動作モード組み込んだそのレスポンスを送信する。

一度、発呼者端末がレスポンスを受信すると、メディアの送信の開始が可能となる。呼び出された端末は、そのレスポンスを送信したときに、メディアを受け入れる状態となったということである。

留意すべきは、発呼者が、リクエストを送信したときにその提案によりメディアを受け入れる位置にあるということである。

留意すべきは、端末が、そのメッセージを認識しないか、それら（例えば、衝突のため）を検出することができない場合には、それらは、タイプIIの高速化により手順を進めることができるということである。

本発明の実施形態は、AnswerFastタイプIV実装と関連して記載されたが、本発明の実施形態により提供される方法とシステムは、AnswerFastタイプII及びタイプIII実装にも適用可能であることが解読されるであろう。これら代替的な実装に関する付加的な議論は、２００３年１２月９日に提出され、「Ｈ．３２４および関連する通信プロトコルを用いた装置間でセッションを高速に確立する方法およびシステム」という名称の米国特許出願１０／７３２９１７号と、２００４年９月３日に提出され、「Ｈ．３２４および関連する通信プロトコルを用いた装置間でセッションを高速に確立する方法およびシステム」という名称の米国特許出願１０／９３４０７７号とで提供され、その両者は、すべてここに引用して援用される。

高速セッション起動手順のＡＳＮ．１構文

本発明の実施形態が、本発明の実施形態中に用いられる高速セッション起動手順に用いられるＡＳＮ．１構文スクリプト一式を提供する。

高速セッション起動ＡＳＮ．１構文

FASTSESSIONSETUP DEFINITIONS AUTOMATIC TAGS : := BEGIN

IMPORTS

NonStandardldentifier,
NonStandardParameter,
MultiplexCapability,
MultiplexEntrySend,
OpenLogicalChannel
FROM MULTIMEDIA-SYSTEM-CONTROL;

FastSessionSetupRequest : := CHOICE
{
nonStandard NonStandardParameter,
predefinedProfile FastSessionSetupPredefinedRequest, explicitProfile FastSessionSetupExplicitRequest,
}
FastSessionSetupResponse : : = CHOICE
{
nonStandard NonStandardParameter ,
predefinedProfile FastSessionSetupPredefinedResponse, explicitProfile FastSessionSetupExplicitResponse,
...
}

FastSessionSetupPredefinedReguest : := SEQUENCE
(
version INTEGER (1..7),
h245version INTEGER(1..31),
vendorId NonStandardldentifier OPTIONAL,
terminalType INTEGER(0..255),-For MasterSlaveDetermination
initialMobileLevel INTEGER (0..7), - [4,7] are reserved
h223Info SEQUENCE
{
h223AnnexADoubleFlag BOOLEAN,

h223AnnexBOptionalHeader BOOLEAN,

multiplexProfile INTEGER (0..65535) OPTIONAL,
} OPTIONAL,
capabilityProfile INTEGER (0..65535) OPTIONAL,
audioProfiles SET SIZE (1..65535) OF INTEGER (0..65535) OPTIONAL,
videoProfiles SET SIZE (1..65535) OF INTEGER (0..65535) OPTIONAL,
dataApplicationProfiles SET SIZE (1..65535) OF INTEGER (0..65535) OPTIONAL,
encryptionProfiles SET SIZE (1..65535) OF INTEGER (0..65535) OPTIONAL,
additionalParameters OCTET STRING OPTIONAL,
mediaTunnel BOOLEAN,
modeDetermination CHOICE
{
simultaneous NULL,
bycallee NULL,
}

FastSessionSetupPredefinedResponse ::= SEQUENCE
{
version INTEGER (1..7),
h245version INTEGER (1..31),
vendorld NonStandardldentifier OPTIONAL,
terminalType INTEGER (0..255), - For
MasterSlaveDetermination
mobileLevel INTEGER (0..7), - [4,7] are reserved
h2231nfo SEQUENCE
{
h223AnnexADoubleFlag BOOLEAN,
h223AnnexBOptionalHeader BOOLEAN,
multiplexProfile INTEGER (0..65535) OPTIONAL,
} OPTIONAL,
capabilityProfile INTEGER (0..65535) OPTIONAL,
audioProfiles SET SIZE (1..65535) OF INTEGER (0..65535)
OPTIONAL,
videoProfiles SET SIZE (1..65535) OF INTEGER (0..65535)
OPTIONAL,
dataApplicationProfiles SET SIZE (1..65535) OF INTEGER
(0..65535) OPTIONAL,
encryptionProfiles SET SIZE (1..65535) OF INTEGER (0..65535)
OPTIONAL,
additionalParameters OCTET STRING OPTIONAL,
・・・
｝

FastSessionSetupExplicitRequest : :== SEQUENCE
{
version INTEGER (1..7),
h245version INTEGER (1..31),
vendorld NonStandardldentifier OPTIONAL,
terminalType INTEGER (0..255), - For
MasterSlaveDetermination
initialMobileLevel INTEGER (0..7), - [4,7] are reserved
h223Info SEQUENCE
{
h223AnnexADoubleFlag BOOLEAN,
h223AnnexBOptionalHeader BOOLEAN,
multiplexEntrySend MultlplexEntrySend OPTIONAL,
・・・
} OPTIONAL,
multiplexCapability MultiplexCapability OPTIONAL,
openLogicalChannels SET SIZE (1..65535) OF OpenLogicalChannel
OPTIONAL,
additionalParameters OCTET STRING OPTIONAL,
mediaTunnel BOOLEAN,
modeDetermination CHOICE

{
simultaneous NULL,
bycallee NULL,
・・・
},
・・・
}

FastSessionSetupExplicitResponse ::= SEQUENCE
{
version INTEGER (1..7),
h245version INTEGER (1..31),
vendorld NonStandardldentifier OPTIONAL,
terminalType INTEGER (0..255), - For
MasterSlaveDetermination
mobileLevel INTEGER (0..7), - [4,7] are reserved
h223Info SEQUENCE
{
h223AnnexADoubleFlag BOOLEAN,
h223AnnexBOptionalHeader BOOLEAN,
multiplexEntrySend MultiplexEntrySend OPTIONAL,

} OPTIONAL,
multiplexCapability MultiplexCapability OPTIONAL,
openLogicalChannels SET SIZE (1..65535} OF OpenLogicalChannel
OPTIONAL,
additionalParameters OCTET STRING OPTIONAL,
・・・
}

END

さらに、本明細書中で説明した実施例や実施形態は、説明のためのみであり、しかも、それらを考慮した種々の修正又は変形形態は、当業者には暗示されており、本出願の精神と範囲、および添付の請求項の範囲内に含まれるべきであることも明らかである。

本発明の一実施形態によるＦＳＳフレームの構造を示す図である。 本発明の一実施形態によるＦＳＳフレーム情報フィールドの構造を示す図である。 本発明の一実施形態によるＦＳＳ同期フラグの構造を示す図である。 本発明の一実施形態による事前に定義されたプロファイルインデックスの構造を示す図である。 本発明の一実施形態による事前に定義されたプロファイルインデックスにおける詳細なプロファイルインデックスの構造を示す図である。 本発明の一実施形態によるリクエスト及びレスポンスの通信を示す図である。 本発明の一実施形態による高速化技術のタイプIVの一実施形態を示す図である。 本発明の一実施形態による高速化技術のタイプIVの一実施形態を示す図である。

Claims (33)

1. １つ又は複数の３Ｇ通信ネットワークを用いて、短縮された起動時間でユーザ間の呼起動プロセスを開始する方法であって、この方法は、前記１つ又は複数の３Ｇ通信ネットワークに結合した少なくとも一組のＨ．３２４類似端末間に設けられ、
   呼信号プロセス後に、第１の端末と第２の端末との間でベアラチャンネルを確立することと、
   前記第１の端末から前記第２の端末へ、呼に対する第１の動作モードに関連する第１の優先度プロファイルと、呼に対する第２の動作モードに関連する第２の優先度プロファイルとを含む第１のＦＳＳメッセージを送信することと、
   前記第１の動作モードか前記第２の動作モードかのいずれかを選択することと、
   を含む方法。
2. 前記第１の優先度プロファイルは、前記第１の動作モードか、前記第２の動作モードかのいずれかを選択するための優先度を含む請求項１に記載の方法。
3. 前記第１の端末から前記第２の端末へのメディアストリームを送信することを更に含み、
   前記メディアストリームは、１又は複数の前記チャンネルの特性によって特徴づけられる請求項２に記載の方法。
4. 前記第１の端末から前記第２の端末へ、第２のＦＳＳメッセージを送信することをさらに含む請求項１に記載の方法。
5. 前記第２のＦＳＳメッセージは、明示的なプロファイルを含む請求項４に記載の方法。
6. 前記第１のＦＳＳメッセージ及び前記第２のＦＳＳメッセージに含まれるコンテンツの少なくとも一部に基づいて、前記第２の動作モードの特性を決定することをさらに含む請求項５に記載の方法。
7. 前記第２の動作モードの特性は、
   １又は複数の音声コーデック及び設定、映像コーデック及び設定、多重化レベル、多重化テーブルエントリ、データチャンネル、又は多重化機能を含む請求項６に記載の方法。
8. 前記第１の優先度プロファイルは、事前に定義されたプロファイルを含み、
   前記第２の優先度プロファイルは、明示的なプロファイルを含む請求項１に記載の方法。
9. １つ又は複数の３Ｇ通信ネットワークを用いて、短縮された起動時間でユーザ間の呼起動プロセスを開始する方法であって、この方法は、前記１つ又は複数の３Ｇ通信ネットワークに結合した少なくとも一組のＨ．３２４類似端末間に設けられ、
   呼信号プロセス後に、第１の端末と第２の端末との間でベアラチャンネルを確立することと、
   動作モードに対する複数のプロファイルを提供することと、
   複数のプロファイルのうちの１つを用いた呼の確立を試みることと、
   複数のプロファイルのうちの１つを用いて確立されなかった呼を決定することと、
   複数のプロファイルのうちの他のものを用いた呼の確立を試みることと、
   を含む方法。
10. 前記複数のプロファイルは、複数の優先度プロファイルを含む請求項９に記載の方法。
11. 前記複数の優先度プロファイルのうちの１つは、明示的な優先度プロファイルを含む請求項１０に記載の方法。
12. 前記複数の優先度プロファイルのうちの他のものは、事前に定義されたプロファイルを含む請求項１０に記載の方法。
13. 前記複数のプロファイルのうちの他のものを用いた呼の確立を試みることは、前記第２の端末が前記複数のプロファイルのうちの他のものを用いた呼の確立に適することを、前記第１の端末で判定することを含む請求項９に記載の方法。
14. １又は複数の３Ｇ通信ネットワークを用いて、短縮された起動時間でユーザ間の呼起動プロセスを開始する方法であって、この方法は、前記１つ又は複数の３Ｇ通信ネットワークに結合した少なくとも一組のＨ．３２４類似端末間に設けられ、
    呼信号プロセス後に、第１の端末と第２の端末との間でベアラチャンネルを確立することと、
    １又は複数の音声コーデック及び設定、映像コーデック及び設定、多重化レベル、多重化テーブルエントリ、データチャンネル、又は多重化機能を含み、第１のＦＳＳメッセージによって定義された１又は複数の動作モードを提供することと、
    前記第２の端末から送信された前記第１のＦＳＳメッセージを前記第１の端末で受信することと、
    第２のＦＳＳメッセージにおいて、前記第１の端末から前記第２の端末へ、前記１又は複数の動作モードを用いる第１のデータストリームを送信することと、を含む方法。
15. 前記１又は複数の動作モードが、事前に設定された動作モードである請求項１４に記載の方法。
16. 第３のＦＳＳメッセージにおいて、前記第２の端末から前記第１の端末へ、前記１又は複数の動作モードを用いる第２のデータストリームを送信することをさらに含む請求項１４に記載の方法。
17. 前記１又は複数の動作モードが、事前に設定された動作モードである請求項１６に記載の方法。
18. ＦＳＳレスポンスフェーズの完了を判定することと、
    前記第２のＦＳＳメッセージにおいて、前記第１の端末から前記第２の端末へ前記第１のデータストリームを送信することと、
    標準のモバイル動作レベルを用いて、前記第１の端末から前記第２の端末への前記第１のデータストリームの送信を開始することと、
    をさらに含む請求項１４に記載の方法。
19. １又は複数の３Ｇ通信ネットワークを用いて、短縮された起動時間でユーザ間の呼起動プロセスを開始する方法であって、この方法は、前記１つ又は複数の３Ｇ通信ネットワークに結合した少なくとも一組のＨ．３２４類似端末間に設けられ、
    呼信号プロセス後に、第１の端末と第２の端末との間でベアラチャンネルを確立することと、
    コーデック設定及び多重化テーブルエントリを含み、第１のＦＳＳメッセージによって定義された１又は複数の動作モードを提供することと、
    前記第２の端末から送信された前記第１のＦＳＳメッセージを前記第１の端末で受信することと、
    前記第２の端末からのレスポンスメッセージが前記第１の端末で受信されるまで、前記第２の端末がメディアを受信可能でないことを、前記第１の端末が、前記第１のＦＳＳメッセージから判定することと、
    前記第２の端末からのレスポンスメッセージの受理後にメディアを送信することと、を含む方法。
20. １又は複数の３Ｇ通信ネットワークを用いて、短縮された起動時間で、ユーザ間の呼起動プロセスを開始する方法であって、この方法は、前記１つ又は複数の３Ｇ通信ネットワークに結合した少なくとも一組のＨ．３２４類似端末間に設けられ、
    呼信号プロセス後に、第１の端末と第２の端末との間でベアラチャンネルを確立することと、
    コーデック設定及び多重化テーブルエントリを含み、第１のＦＳＳメッセージによって定義された１又は複数の動作モードを提供することと、
    前記第２の端末から送信された前記第１のＦＳＳメッセージを前記第１の端末で受信することと、
    前記第２の端末からのレスポンスメッセージが前記第１の端末で受信される前に、前記第２の端末がメディアを受信可能であることを、前記第１の端末で、前記第１のＦＳＳメッセージから判定することと、
    前記第２の端末からのレスポンスメッセージの受信前にメディアを送信することと、を含む方法。
21. １又は複数の３Ｇ通信ネットワークを用いて、短縮された起動時間でユーザ間の呼起動プロセスを開始する方法であって、この方法は、前記１つ又は複数の３Ｇ通信ネットワークに結合した少なくとも一組のＨ．３２４類似端末間に設けられ、
    第１の端末に情報を提供することと、
    誤りに対して頑健に、かつ、１又は複数の予期される標準フラグのエミュレーションが回避されるような結果となるように、前記情報をエンコードすることと、
    フレームの順番を形成する１又は複数のフラグシーケンスで、前記エンコードされた情報をフレーム化することと、
    前記フレームシーケンスを埋め込むことと、
    前記埋め込まれたフレームシーケンスを、送信することと、を含む方法。
22. 前記情報は、メッセージを含む請求項２１に記載の方法。
23. 前記メッセージは、１又は複数の装置の優先度を含む請求項２２に記載の方法。
24. 前記１又は複数の装置の優先度は、事前に定義された動作モードを含む請求項２３に記載の方法。
25. 前記メッセージは、メディアを含む請求項２２に記載の方法。
26. 前記エンコードされた情報をフレーム化することは、検出及び同期を促進する請求項２１に記載の方法。
27. 前記誤りに対して頑健に前記情報をエンコードすることは、１又は複数のエンコードされた情報セグメントに、前記情報を分割することを含む請求項２１に記載の方法。
28. 前記誤りに対して頑健に前記情報をエンコードすることは、エンコードされた情報に、巡回冗長チェックを付加することを含む請求項２１に記載の方法。
29. 前記１又は複数の予期できる標準フラグのエミュレーションを回避するように前記情報をエンコードすることは、ネゴシエートされていない多重化テーブルエントリに対して標準の多重化ＰＤＵフレーミングを用いることを含む請求項２１に記載の方法。
30. 前記１又は複数の予期できる標準フラグのエミュレーションを回避するように前記情報をエンコードすることは、隣接するオクテットに、Ｈ．３２４の多重化レベルの任意の同期フラグを挿入することを含む請求項２１に記載の方法。
31. フラグのエミュレーションを回避するために前記情報をエンコードすることは、Ｈ．３２４の多重化レベルの任意の同期フラグを隣接するオクテットに挿入することを含む請求項３０に記載の方法。
32. 隣接して挿入されるオクテットは、Ｈ．３２４の多重化レベルの同期フラグと値が同じである請求項３１に記載の方法。
33. 埋め込まれたフレームシーケンスの送信を繰り返す請求項２１に記載の方法。

Images