JP2009540647A - プッシュ・トゥ・トーク・オーバ・セルラーシステムにおける遅延の低減 - Google Patents

Abstract

プッシュ・トゥ・トーク通信システムにおいて、発信側装置がフロアを持つのを確認する前に、フレームが通話装置によって送信される。フレームにはフラグが付され、制限時間内に受聴側装置に送信され、バッファされる。‘確認’としてのフラグ付のフレームの受信または、サーバからの‘受信トーク・バースト’の受領によって、再生が始まる。

Description

本発明は、プッシュ・トゥ・トーク・セルラー通信システムに関する。

（システムの概要）
ＯＭＡ（オープン・マーケット・アライアンス）プッシュ・トゥ・トーク・オーバ・セルラー（ＰｏＣ；Push to Talk over Cellular）システムは、携帯電話の使用者にウォーキートーキーのような機能を提供するように意図されている。ＰｏＣは、以下の図１“ＰｏＣ １対多グループ・セッション（音声伝送）の例”におけるような受信者のグループ間での使用者音声およびデータ通信を可能にする。

プッシュ・トゥ・トーク・オーバ・セルラーでは、可搬型ハンドセットは、ネットワークの‘ＰｏＣサーバ’と通信するＰｏＣクライアントと呼ばれる。これらのサーバのうちの１個が‘ＰｏＣ制御機能’と呼ばれる役割を果たし、全部のＰｏＣクライアントはＰｏＣ制御機能から話す許可を要求しなければならない（授与される‘フロア’の要求を行わなければならない）。一般に使用者は、ハンドセットのボタンを押すことによってこれを行う。使用者が話す許可を得た場合、これは通常、可聴‘トーク’トーンによって指示される。使用者が話す時、使用者は、“トーク・バースト”、より一般には、オーディオ、ビデオまたは他の情報を含み得る“メディア・ストリーム”を送信する。

現在具体化されているシステムは、使用者の見聞を悪くする望ましくない遅延に多いに悩まされがちである。この提案は、ＯＭＡ ＰｏＣアーキテクチャの文脈における全部のこれらの遅延要因の最小化に関連している。

（ＯＭＡ ＰｏＣアーキテクチャの概要）
各使用者のハンドセットは“ＰｏＣクライアント”と呼ばれる。ＰｏＣセッション自体は“ＰｏＣ制御機能”によって制御され、これはアドミッションといった管理機能を実行し、どの使用者がフロアに入るのを許されるかを決定する。ＰｏＣクライアントは“ＰｏＣ参加機能”を通じてＰｏＣコントローラと通信する。ＰｏＣクライアントがＰｏＣ制御機能と同じネットワークに属していれば、ＰｏＣ制御および参加機能はまったく同一の実体であってもよい。そうでなければ、それらは異なる実体であり、ＰｏＣ参加機能はＰｏＣクライアントと同じネットワークに存在する。これは、図２“ＰｏＣ制御機能、ＰｏＣ参加機能およびＰｏＣクライアントの関係”に例示されている。

トーク・バースト制御メッセージといったメディアおよびメディア関連信号は、現在フロアを有し、常にＰｏＣ制御機能を通じて経路指定され、他のＰｏＣクライアントにおいて終端するＰｏＣクライアントから発出する。効率のために、それはＰｏＣ参加機能を迂回してもよい。

セッション制御信号（セッションに入る、セッションを出る、セッションを設定するといった）は常にＰｏＣ参加機能によって経路指定される。

（システム遅延分析）
ＰＴＴボタンを押した話者は、（スピーク要求が成功したと仮定して）トーク・トーンが生成される前に若干の明らかな遅延を経験するが、この時間は以下の図においてＴ_{ｆｌｏｏｒ}として例示される。一般に、遅延が少なければ少ないほど、話者はより良好に知覚する。

第二に、話者がＰＴＴボタンを押した時から受聴者が最初に話者が話すのを聞くまでにかなりの遅延が存在する。この遅延を最小限にすることは、会話が休止したように思えるが実際には一方の話者がすでにフロアを求めた時に起こる‘衝突’を防ぐために重要である。この遅延は以下でＴ_{ｐｔｔ−ｐｌａｙ}と呼ばれる。

また、いったん話者が話し出すと、話者の声から使用者の耳までに遅延（‘エンド・トゥ・エンド’遅延）が存在する。この遅延は多くの要因からなり、これらに限らないが以下を含む。
−話者の音声を離散的なデジタル音声フレームまたはパケットに符号化する時間。
−パケットを話者のハンドセットから受聴者のハンドセットへ送信する時間。
−受聴者のハンドセットにおいて復号する遅延。

エンド・トゥ・エンドの‘マウス・トゥ・イヤー’遅延を最小限にすることが望ましい。

ＯＭＡ ＰｏＣシステムにおいて、現在の遅延要因は以下を含む。
１．話したいと欲する使用者がボタンを押すと、ｔａｌｋ＿ｂｕｒｓｔ＿ｒｅｑｕｅｓｔメッセージがＰｏＣクライアントからＰｏＣコントローラに送られフロアを要求する。
２．メッセージｔａｌｋ＿ｂｕｒｓｔ＿ｃｏｎｆｉｒｍがＰｏＣ制御機能からＰｏＣクライアントに来てフロアを授与する（その要求が成功したとして）。また、対応するｒｅｃｅｉｖｅｉｎｇ＿ｔａｌｋ＿ｂｕｒｓｔメッセージがセッションにおける他の全部のＰｏＣクライアントに送られて、別の使用者がフロアを得たことを指示する。
３．ＰｏＣクライアントは自己がフロアを有することを話者に知らせる（一般に可聴トーンを再生することによって）。この時点でその者は話し始めることができる。
４．話はフレームに符号化され、ＰｏＣクライアントから他のＰｏＣ受聴者に送られる。遅延は可変であるが、最小遅延はＴ_ｅ２ｅであると仮定する。
５．通話フレームはＰｏＣ受聴者においてバッファされる。遅延が最小値から可変であるという事実に対処するために、ＰｏＣ聴取側クライアントは最初に継続時間Ｔ_ｊｉｔのバッファを収集しなければならず、ここでこれは一般に、それらを再生（play out）する時間内にフレームの９９％が受信されることを保証するために十分に長くなければならない。

これは以下の図３に示されており、ここで時間遅延は次の通りである。
Ｔ_{ｆｌｏｏｒ}：これは押しボタンから使用者が話すのを許されたという指示までの遅延である。一般に、これは１秒未満である（非特許文献２）。
Ｔ_ｓｅｎｄ：これは押しボタンから送信側クライアントがネットワークに向けて通話フレームを送信し始めるのを許された時までの遅延である。従来システムの場合、Ｔ_ｓｅｎｄ＝Ｔ_{ｆｌｏｏｒ}。
Ｔ_ｅ２ｅ：これはＩＰネットワーク間の伝送遅延である。一般にこれはほぼ５０〜２５０ｍｓである（非特許文献２、非特許文献３）。
Ｔ_ｊｉｔ：これはＩＰネットワーク間の伝送遅延ジッターまたは変動である。ネットワークに応じて、それは最大３００ｍｓの範囲となり得る（非特許文献５）。

その場合、話者がＰＴＴボタンを押してから受聴者が最初に話者の話を聞くことができるまでの時間は、次の通りである。
Ｔ_{ｐｔｔ−ｐｌａｙ}＝Ｔ_{ｆｌｏｏｒ}＋Ｔ_ｅ２ｅ＋Ｔ_ｊｉｔ

（遅延ジッター値）
遅延ジッター値Ｔ_ｊｉｔは重要であり、この提案において、音声またはメディアを再生
する際の全遅延を少なくともＴ_ｊｉｔだけ上記の値から低減する方法が示されるであろう。

非特許文献３は、約５０ｍｓの遅延ジッター値を報告しているが、それはエンド・トゥ・エンド遅延の増加とともに増加する傾向がある。非特許文献４において、公共インターネットによるビデオフレームについて９０百分位数（パーセンタイル値）のジッター・オーバは、１秒もの長さであると記録されている（この研究は通話フレームを扱っていない）。非特許文献５は、米国の都市間のインターネット・バックボーンでの音声フレーム遅延および遅延ジッターに関する極めて包括的な測定を行っている。それは多くの事例で低い最小遅延（５０ｍｓ）報告しているが、相当の百分位数の事例について最大３００ｍｓの遅延変動を伴う。それは、そのインターネット・バックボーン・リンクが、そのリンクの特性となる傾向があり、「高、交番する２状態、周期的スパイクまたは一貫して低」として分類することができる遅延ジッター特性を有することを発見した。非特許文献６は、Ｔ_ｔａｌｋについて２秒、そしてインターボイス遅延について１．３秒の平均数を報告している。

図４および５はこの研究から得ており、周期的スパイクの例を示している。

プッシュ・トゥ・トーク・オーバ・セルラー（ＰｏＣ）−アーキテクチャ候補バージョン１．０−２００６年１月２７日，オープン・モバイル・アライアンス（Push to talk over Cellular (PoC) - Architecture Candidate Version 1.0 - 27 Jan 2006, Open Mobile Alliance） http://www.incodewireless.com/media/whitepapers/2004/PoC White Paper- Feb 2004.pdf. (www.nordstream.se) インターネット電話通信品質の測定：我々は今日どこにいるか：Ｏ．ハグサンド、Ｊ．ハンソン、Ｉ．マーシュ、グローブコム’９９（Measuring internet telephony quality: where are we today: O Hagsand, J Hanson, I Marsh, Globecomm'99）［文書の終わり］ インターネットによるリアルビデオ性能の経験的な研究、ユービン・ワン、マーク・クレイプール、ジャン・ジョウ、ＡＣＭ ＳＩＧＣＯＭＭインターネット測定ワークショップ２００１（An Empirical Study of RealVideo Performance Across the Internet, Yubing Wang, Mark Claypool, Zheng Zuo, ACM SIGCOMM Internet Measurement Workshop 2001） インターネット・バックボーンによる音声通信の品質の評価、マルコポーロ、トバギ、カラム、２００３、ＩＥＥＥＡＣＭトランス・ネットワーキング（Assessing the Quality of Voice Communications Over Internet Backbones, Markopoulou, Tobagi, Karam, 2003, IEEE ACM Trans Networking） 性能測定のためのプッシュ・トゥ・トーク・クライアントの設計、トゥーカ・カルボネン、テーゼス、３．２．０５ケルチアス・オイ（Design of Push to Talk Client for Performance Measurement, Tuuka Karvonen, Thesis, 3.2.05 Celtius Oy）

本発明は、プッシュ・トゥ・トーク・セルラー通信システムを提供する。‘話す’権利は実際上、話す権利またはメディア・ストリームを送る権利を意味し得ることに留意されたい。通話またはメディアの初期セグメントは限られた継続時間を有する。他の要因の中で、それはクライアント装置のバッファの大きさによって制限されるが、好ましくはそれはより積極的なやり方で、例えば遅延ジッターといったネットワークの性能の測定値に基
づいて制限される。これはサーバによってクライアント装置に中継され得る。

別の態様において、システムは、初期送信セグメントの継続時間がシステムにおける遅延ジッターまたは遅延の他の側面に依存することを特徴とする。

本発明はまた、本発明のシステムに適格なクライアント装置を提供する。

１対多プッシュ・トゥ・トーク・グループ・セッションを示す概略図 上述の機能とクライアントとの関係を示す図 従来のプッシュ・トゥ・トーク・システムに存在する遅延を示す図 プッシュ・トゥ・トーク・システムにおける遅延の研究に基づくグラフ プッシュ・トゥ・トーク・システムにおける遅延の研究に基づくグラフ 本発明により期待される改良を示す図３に類似のタイミング図 図６のシステムへの光学的増強を示す図３および図６に類似の別のタイミング図

本発明の実施形態はここで例証としてのみ添付図面に関して説明する。

本発明は、状況に応じて（例えば、ある特定期間にわたり無音が存在した）、確認がＰｏＣ制御機能から受け取られる前に‘授与されたフロア’指示が使用者に指示される予測授与の仕組みの導入に依拠する。従って、Ｔ_{ｆｌｏｏｒ}＜Ｔ_ｓｅｎｄである。以下の図６はタイミングを示している。

その後、使用者は、ＰｏＣクライアントがその者がフロアを有することを確認するｔａｌｋ＿ｂｕｒｓｔ＿ｃｏｎｆｉｒｍメッセージを受け取る前に話し始めることができる（従って、使用者はそれが取り去られるためだけに明らかにフロアを授与されるというわずかな危険が存在する）。以下の図に示すように、送話側ＰｏＣクライアントは、確認が受け取られる前にメディア・ストリームを送り始める。しかしそれは、Ｔ_ｊｉｔの継続時間で、メディア・ストリームの最初のセグメントを送るだけにすぎない。この後それは、それが確認済フロア授与指示を受け取るまで、そのメディア・ストリームを記憶する。

ＰｏＣクライアントが遅延ジッターの支配的な値を知っていると期待されない点に留意されたい。これはサーバによってクライアントに通知され得る。クライアントがその者がフロアを有することを使用者に指示する前の時間遅延Ｔ_{ｆｌｏｏｒ}もまた原理的に通知され得る。

メディア・ストリームのこの最初のセグメントは、聴取側ＰｏＣクライアントへのその送信までＰｏＣサーバにおいてバッファされ、そこでそれはメディア・ジッター・バッファを初期化するためにバッファされ使用され得る。メディア・ストリームの各フレームは“予測／確認済フロア授与フラグ”と呼ばれるバイナリフラグを含んでおり、それは、このフレームが、フロア授与の確認が送話側ＰｏＣクライアントによって受け取られる前（予測フロア授与）か、または確認が受け取られた後（確認済フロア授与）に送信されたことを指示する。メディア・ストリームの最初のセグメントを含んでいるフレームは、それらが“予測フロア授与”とともに送られたことを指示するフラグでマークされており、ＰｏＣクライアントはそれらを再生しないという結果を伴う。このフラグは、この提案の新規な側面である。

送話側ＰｏＣクライアントは引き続き、それが授与されたフロアの確認を受け取るまで
メディア・ストリームをバッファする。その時点で、それはメディア・ストリームをＰｏＣ制御機能に向けて送り始め、後者はそれを聴取側ＰｏＣクライアントに向けて中継する。

メディアフレームにおける各フレームはこの時、それらが“確認済フロア授与”とともに送られたことを指示するフラグでマークされており、聴取側ＰｏＣクライアントは、メディア・ストリームデータが以後それが最終的に停止するまで連続的に着信するという知識に基づいて、最初の当該フレームを得るとただちにメディア・ストリームを再生し始めることができるという結果を伴う。

この方法の長所は、送話者がフロアを要求してから受聴者がメディア・ストリームの始まりを聴取するまでの遅延が低減するということである。加えて、送話者によって知覚されるフロア授与遅延が低減する。

この低減の範囲は次の通りである。上述の通り、従来システムにおいてこの遅延は次の通りである。
Ｔ_{ｐｔｔ−ｐｌａｙ}＝Ｔ_{ｆｌｏｏｒ}＋Ｔ_ｅ２ｅ＋Ｔ_ｊｉｔ

新システムにおいて遅延は次の通りである。
Ｔ_{ｐｔｔ−ｐｌａｙ}＝Ｔ_{ｆｌｏｏｒ}＋Ｔ_ｅ２ｅ

わかるように、ジッター・バッファを充填するための遅延が除去される。

例えば、フロア遅延が５００ｍｓであり、最小エンド・トゥ・エンド遅延が１００ｍｓ、最大ジッターが４００ｍｓである場合、これは４０％の改良に相当する。

（第１の改良例）
遅延をさらに最小化するためにトーク・バースト制御メッセージを利用する上記の解決策への拡張をここで説明する。トーク・バースト制御メッセージは、フロアの授与を制御するためにＰｏＣ制御サーバによって使用される。通常動作において、ＰｏＣ制御サーバは、フロアを授与されたことをクライアントに知らせるためにクライアントに“Ｔａｌｋ＿Ｂｕｒｓｔ＿Ｃｏｎｆｉｒｍ”メッセージを送るとともに、サーバは他の全部に対し“クライアントＸが話す権利を授与されたことを知らせるために“Ｒｅｃｅｉｖｉｎｇ＿Ｔａｌｋ＿Ｂｕｒｓｔ＿ｆｒｏｍ＿ＵｓｅｒＸ”メッセージを送る。

この代替解決策では、送話側クライアント（クライアントＡ）の動作はまさしく上述の通りである。しかし、受信側クライアントの動作は、“Ｒｅｃｅｉｖｉｎｇ Ｔａｌｋ Ｂｕｒｓｔ ｆｒｏｍ ＵｓｅｒＡ”メッセージを受け取るとただちに、使用者Ａからのその受け取ったバッファの大きさを確認するように修正される。それが初期Ｔ_ｊｉｔ量のデータを受け取った場合、以降のデータパケットが着信するのを待つのではなく、すぐにこのデータを再生することに進むことができる。通常の条件下で、“Ｔａｌｋ Ｂｕｒｓｔ Ｃｏｎｆｉｒｍ”がクライアントＡのもとに着信したのとほぼ同時に“Ｒｅｃｅｉｖｉｎｇ Ｔａｌｋ Ｂｕｒｓｔ ｆｒｏｍ ＵｓｅｒＸ”が受け取られたと仮定した場合、この縮小の範囲は次の通りである。
Ｔ_{ｐｔｔ−ｐｌａｙ}≒Ｔ_ｓｅｎｄ

これは図７に例示されている。

（第２の改良例）
ＰｏＣシステムでは、全遅延は、２つの重要な成分から構成される。
−ライト・トゥ・スピーク遅延：使用者がトークボタンを押してからフロアを授与されるまでの間の遅延。
−マウス・トゥ・イヤー遅延：通話が送話側クライアントで記録されてからそれが受話器において再生されるまでの間の遅延。

上述の拡張予測授与機構は、エンド・トゥ・エンド遅延およびライト・トゥ・スピーク遅延の両方全体を低減するが、（クライアント送信バッファの導入のために）従来のＰｏＣシステムによるマウス・トゥ・イヤー遅延を増大させる。

ある特定の状況では、全体のエンド・トゥ・エンド遅延を維持しながら、増大したライト・トゥ・スピーク遅延が低下したマウス・トゥ・イヤー遅延と引き替えに導入されることが好ましいかもしれない。事実上、受け取られた通話は、受話器において再生される時にそれほど‘ｓｔａｌｅ（古びた状態）’ではない。

この第２の代替策において、これは、制限された初期セグメントの要求された長さおよびフロア要求からフロア授与までの遅延のヒストリカル測定に基づき、送話側クライアントが使用者に‘Ｏｋ ｔｏ ｓｐｅａｋ’を指示する時間を決定することによって達成できる。

１実施形態において、Ｔ_{ｐｔｔ−ｐｌａｙ}を最小化するとともに、通話が受聴者のもとに着信した時に可能な限り‘ｆｒｅｓｈ（新鮮な状態）’であることを保証するために、‘Ｏｋ ｔｏ ｓｐｅａｋ’指示は理想的にはＴ_{ｆｌｏｏｒ}−Ｔ_ｅ２ｅ−Ｔ_ｊｉｔで送られなければならず、この時点でＴ_ｊｉｔ量のデータが以前と同様に収集され送られなければならない。このシナリオにおいて、エンド・トゥ・エンド遅延はほぼＴ_{ｆｌｏｏｒ}のままである。この方法の長所は、クライアントＢによって受け取られる情報が以前に使用されたそれよりも‘ｓｔａｌｅ’ではないということである。

１実施形態において、受信側クライアントは、遅延ジッターを見込むために十分な量が受信されることを前提として、さらなる遅延を伴うことなく受信するとただちに通話を再生し始めることができる。

Claims (15)

1. モバイル通信装置をシステムのクライアントとして接続するためにモバイル通信ネットワークにおいて動作可能なプッシュ・トゥ・トーク・セルラー通信システムであって、
   クライアントが‘話す’権利を要求し、
   ‘話す’権利は中央制御機能によって授与され、
   確認が制御機能からクライアントに送られ、
   制御機能からの確認は予想されており、要求側クライアントは確認に先立って通話またはメディア情報の初期セグメントを送信し、
   通話またはメディアの初期セグメントは聴取側クライアントにおいて記憶され、
   要求側クライアントは制御機能からの確認メッセージの受信時に通話またはメディアの残部を送信し始め、
   聴取側クライアントはトリガ条件に従って通話またはメディアを再生し始めるものであり、
   制限された継続時間の通話またはメディアの初期セグメントがＰｏＣクライアントによって送られ、
   通話またはメディアに含まれるデータ・フレームは、送信側クライアントがフロア授与を確認するメッセージを受け取る前に送信されたデータ・フレームが“予測”とマークされ、その後に送信されたデータ・フレームが“確認済”とマークされるように送信側クライアントによって“予測／確認済フロア授与フラグ”でマークされ得る、プッシュ・トゥ・トーク・セルラー通信システム。
2. 聴取側クライアントのためのトリガは“確認済”とマークされた通話またはメディアの一部の受信である、請求項１に記載のプッシュ・トゥ・トーク・セルラー通信システム。
3. 聴取側クライアントは、別のクライアントがデータ・フレームを送る権利を授与されそれが予測とマークされたいくつかのフレームをすでに受信していることを通知するメッセージを受け取った時にトリガされる、請求項１に記載のプッシュ・トゥ・トーク・セルラー通信システム。
4. 通話またはメディアの初期セグメントの継続時間はプッシュ・トゥ・トーク・サーバによって提供された情報に基づいて制限される、請求項１、２または３に記載のシステム。
5. 聴取側クライアントはそれが通話またはデータの前記初期セグメントの全体を受け取るまでトリガされない、請求項３および４に記載のシステム。
6. 継続時間はネットワークに存在する支配的な遅延ジッターに基づいている、請求項４または５に記載のシステム。
7. サーバは要求側クライアントに遅延ジッターを通知し、クライアントはこれを使用して通話またはメディアの初期セグメントの継続時間を決定する、請求項６に記載のシステム。
8. 使用者がデータを送るのを許可するために要求側クライアントの使用者に信号が送られ、信号の送信は、使用者がトークボタンを押してからフロアを授与されるまでの間の遅延と、通話が送話側クライアントで記録されてからそれが受話器において再生されるまでの間の遅延とに基づいて遅延される、いずれかの上記請求項に記載のシステム。
9. モバイル通信装置をシステムのクライアントとして接続するためにモバイル通信ネットワークにおいて動作可能なプッシュ・トゥ・トーク・セルラー通信システムであって、
   クライアントが‘話す’権利を要求し、
   ‘話す’権利は中央制御機能によって授与され、
   確認が制御機能からクライアントに送られ、
   制御機能からの確認は予想されており、要求側クライアントは確認に先立って通話またはメディア情報の初期セグメントを送信し、
   通話またはメディアの初期セグメントは聴取側クライアントにおいて記憶され、
   要求側クライアントは制御機能からの確認メッセージの受信時に通話またはメディアの残部を送信し始め、
   聴取側クライアントはトリガ条件に従って通話またはメディアを再生し始めるものであり、
   通話またはデータの初期セグメントの継続時間は、支配的な遅延ジッターまたはシステムにおける他の遅延要因に基づいて制限される、プッシュ・トゥ・トーク・セルラー通信システム。
10. サーバはクライアントに支配的な遅延ジッターを通知し、クライアントはこれを使用して通話またはメディア情報の初期セグメントの継続時間を制限する、請求項９に記載のシステム。
11. 以下の機能性を有するプッシュ・トゥ・トーク・セルラー通信システムにおけるクライアントとしての使用のためのモバイル通信装置であって、
    “話す”権利を要求する信号を生成することと、
    “話す”権利が授与されたことを確認する制御機能からのメッセージを受け取り応答することと、
    確認メッセージを受け取ることに先立って通話またはメディア情報の初期セグメントを送るための機能性であり、
    通話またはメディアに含まれるデータ・フレームを、フロア授与を確認するメッセージの受信前に送信されたデータ・フレームが“予測”とマークされ、その後に送信されたデータ・フレームが“確認済”とマークされるように“予測／確認済フロア授与フラグ”でマークすることを特徴とする、モバイル通信装置。
12. 予測とマークされた受信フレームが使用者に再生される前にバッファされる聴取モードで動作するための機能性を有する、請求項１１に記載の装置。
13. 受信フレームの再生は“確認済”とマークされた通話またはメディアの一部の受信によってトリガされる、請求項１２に記載の装置。
14. 受信フレームの再生は、別のクライアントがデータ・フレームを送る権利を認められそれが予測とマークされたいくつかのフレームをすでに受信していることを通知するメッセージの受信によってトリガされる、請求項１２に記載の装置。
15. サーバによって供給された情報に基づいて初期セグメントの継続時間を制限する能力を有する請求項１１から１３のいずれかに記載の装置。

Images