(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2022-07-29
(45)【発行日】2022-08-08
(54)【発明の名称】対話型ビデオ会議
(51)【国際特許分類】
H04N 7/15 20060101AFI20220801BHJP
【FI】
H04N7/15
(21)【出願番号】P 2020203978
(22)【出願日】2020-12-09
(62)【分割の表示】P 2018116662の分割
【原出願日】2015-08-07
【審査請求日】2020-12-09
(32)【優先日】2014-10-02
(33)【優先権主張国・地域又は機関】US
(32)【優先日】2015-05-05
(33)【優先権主張国・地域又は機関】US
(73)【特許権者】
【識別番号】503260918
【氏名又は名称】アップル インコーポレイテッド
【氏名又は名称原語表記】Apple Inc.
【住所又は居所原語表記】One Apple Park Way,Cupertino, California 95014, U.S.A.
(74)【代理人】
【識別番号】100094569
【氏名又は名称】田中 伸一郎
(74)【代理人】
【識別番号】100103610
【氏名又は名称】▲吉▼田 和彦
(74)【代理人】
【識別番号】100067013
【氏名又は名称】大塚 文昭
(74)【代理人】
【識別番号】100086771
【氏名又は名称】西島 孝喜
(74)【代理人】
【識別番号】100139712
【氏名又は名称】那須 威夫
(74)【代理人】
【識別番号】100121979
【氏名又は名称】岩崎 吉信
(72)【発明者】
【氏名】オイマン、オズガー
(72)【発明者】
【氏名】ギアカロン、ジィーン-ピェール
(72)【発明者】
【氏名】フォックス、イワン
【審査官】松元 伸次
(56)【参考文献】
【文献】特開2006-135709(JP,A)
【文献】米国特許第07321384(US,B1)
【文献】米国特許出願公開第2011/0085016(US,A1)
【文献】Intel (ROI Rapporteur),ROI Permanent Document - Requirements, Working Assumptions and Potential Solutions,Tdoc S4-140975,3GPP TSG-SA4 Meeting #80,2014年08月07日,pp.1-5,http://www.3gpp.org/ftp/tsg_sa/WG4_CODEC/TSGS4_80/Docs/S4-140975.zip,[平成30年1月9日検索], インターネット
(58)【調査した分野】(Int.Cl.,DB名)
H04M3/00
3/16-3/20
3/38-3/58
7/00-7/16
11/00-11/10
H04N5/222-5/257
7/10-7/173
7/20-7/56
19/00-21/858
(57)【特許請求の範囲】
【請求項1】
インターネットプロトコル(IP)マルチメディアサブシステム(IMS)(MTSI)受信機を介して、MTSI送信機とともに関心領域(ROI)シグナリングをサポートするように動作する装置であって、前記装置は、1または複数のプロセッサおよびメモリを有し、前記1または複数のプロセッサおよびメモリは、
前記MTSI受信機で、前記MTSI受信機から送信された1または複数のパン・チルト・ズーム・フォーカス(PTZF)コマンドを処理するために前記MTSI送信機で使用される1または複数のステップサイズを前記MTSI送信機から受信し、
前記MTSI受信機で、要求された関心領域(ROI)を規定し、
前記MTSI受信機で、
前記1または複数のステップサイズに基づいて、前記要求されたROIを
前記1または複数のパン・チルト・ズーム・フォーカス(PTZF)コマンドにマッピングし、
前記要求されたROIにマッピングされた前記1または複数のPTZFコマンドを前記メモリに格納し、
リアルタイムトランスポートプロトコル(RTP)パケットを介した前記MTSI送信機への送信のために、前記要求されたROIを表す前記1または複数のPTZFコマンドをシグナリングし、前記要求されたROIは、前記1または複数のPTZFコマンドに基づいて前記MTSI送信機において識別されるものであり、
前記MTSI受信機で、前記MTSI送信機から受信した符号化ビデオを復号し、前記符号化ビデオは、前記要求されたROI内にある、ように構成される、装置。
【請求項2】
前記1または複数のPTZFコマンドを、前記RTPパケットを介して前記MTSI送信機に送信し、前記MTSI送信機から前記符号化ビデオを受信する、送受信機を更に備える、請求項1に記載の装置。
【請求項3】
前記1または複数のPTZFコマンドは、パン・チルト・ズーム・フォーカス(PTZF)のためのカメラの移動をサポートする国際電気通信連合(ITU)H.281プロトコルに基づく、請求項1に記載の装置。
【請求項4】
パンコマンドは、前記MTSI送信機が固定された非移動カメラを含む場合に、画像プレーンにわたる左または右の移動または変換にマッピングされる、または、
チルトコマンドは、前記MTSI送信機が前記固定された非移動カメラを含む場合に、前記画像プレーンにわたる上または下の移動または変換にマッピングされる、請求項1に記載の装置。
【請求項5】
前記1または複数のPTZFコマンドは、遠隔カメラ制御(FECC)プロトコルに従って、前記MTSI送信機へシグナリングされる、請求項1に記載の装置。
【請求項6】
前記1または複数のPTZFコマンドは、
スタックインターネットプロトコル(IP)/ユーザデータグラムプロトコル(UDP)/RTP/H.224/H.281を使用する複数のH.224フレームを伝える前記複数のRTPパケットを介した送信のために、前記MTSI送信機へシグナリングされる、請求項1に記載の装置。
【請求項7】
前記1または複数のPTZFコマンドは、前記MTSI受信機が任意のROIにズームすることを可能にする、請求項1に記載の装置。
【請求項8】
対話型ズーミング機能をサポートするローカルクライアントにおいてビデオ会議アプリケーションを動作させるための命令が記録されたコンピュータ可読記録媒体であって、1または複数のプロセッサによって前記命令が実行されたときに、前記ローカルクライアントに、
前記ローカルクライアントから送信された1または複数のパン・チルト・ズーム・フォーカス(PTZF)のコマンドを処理するためにリモートクライアントで使用される1または複数のステップサイズを前記リモートクライアントから受信する手順と、
前記リモートクライアントと関連するカメラの視野内の関心領域(ROI)を規定する手順と、
前記1または複数のステップサイズに基づいて、前記ROIを1または複数のパン・チルト・ズーム・フォーカス(PTZF)コマンドにマッピングする手順と、
リアルタイムトランスポートプロトコル(RTP)パケットを介した前記ローカルクライアントから前記リモートクライアントへの送信のために前記1または複数のPTZFコマンドを処理する手順であって、前記1または複数のPTZFコマンドに基づいて前記リモートクライアントで前記ROIが識別される、手順と、
前記リモートクライアントから受信した前記ROI内の符号化ビデオであって、前記ROI内の領域を含み、前記ROI外の領域を除く前記符号化ビデオを復号する手順と、
前記ローカルクライアントにおけるレンダリングおよび表示のために、前記ROI内の前記符号化ビデオを提供する手順と、を実行させる、コンピュータ可読記録媒体。
【請求項9】
前記1または複数のPTZFコマンドは、国際電気通信連合(ITU)H.281/H.224プロトコルに基づく、請求項8に記載のコンピュータ可読記録媒体。
【請求項10】
前記1または複数のプロセッサによって実行されたときに、前記ローカルクライアントに、単一伝送での前記リモートクライアントへの配信のために前記1または複数のPTZFコマンドを処理する手順を実行させる命令をさらに含む、請求項8に記載のコンピュータ可読記録媒体。
【請求項11】
前記1または複数のプロセッサによって実行されたときに、前記ローカルクライアントに、受信ユーザ入力に基づいて前記ROIを規定する手順を実行させる命令をさらに含む、請求項8に記載のコンピュータ可読記録媒体。
【請求項12】
前記1または複数のPTZFコマンドは、遠隔カメラ制御(FECC)プロトコルに従って、前記リモートクライアントへ送信される、請求項8に記載のコンピュータ可読記録媒体。
【請求項13】
前記1または複数のプロセッサによって実行されたときに、前記ローカルクライアントに、前記ローカルクライアントに提供されたユーザ選択に基づいて前記ROIを規定する手順を実行させる命令をさらに含む、請求項8に記載のコンピュータ可読記録媒体。
【請求項14】
前記1または複数のプロセッサによって実行されたときに、前記ローカルクライアントに、ROIベースの対話型ズーム機能をサポートする前記リモートクライアントとビデオ会議アプリケーションを動作する手順を実行させる命令をさらに含む、請求項8に記載のコンピュータ可読記録媒体。
【請求項15】
ローカルユーザ装置(UE)とビデオ会議を実行するように動作可能なリモートUEの装置であって、前記装置は、1または複数のプロセッサを有し、前記1または複数のプロセッサは、
前記リモートUEで、前記ローカルUEから送信された1または複数のパン・チルト・ズーム・フォーカス(PTZF)のコマンドを処理するために前記リモートUEで使用される1または複数のステップサイズを前記ローカルUEへ送信し、
前記リモートUEで、リアルタイムトランスポートプロトコル(RTP)パケットを介して前記ローカルUEから受信した1または複数のパン・チルト・ズーム・フォーカス(PTZF)コマンドを処理し、
前記リモートUEで、前記1または複数のPTZFコマンドに基づいて前記リモートUEのカメラの視野内の関心領域(ROI)を特定し、
前記ROI内のビデオを符号化し、前記符号化ビデオは前記ROI内の領域を含み、前記ROI外の領域を除き、
前記リモートUEで、前記ローカルUEへの送信のために前記ROI内の前記符号化ビデオを処理する、ように構成される、装置。
【請求項16】
前記1または複数のPTZFコマンド、および、前記1または複数のPTZFコマンドに対応する前記ROIを格納するように構成されるメモリを更に備える、請求項15に記載の装置。
【請求項17】
前記1または複数のPTZFコマンドは、国際電気通信連合(ITU)H.281/H.224プロトコルに基づく、請求項15に記載の装置。
【請求項18】
前記1または複数のプロセッサは、単一伝送にて前記ローカルUEから受信した前記1または複数のPTZFコマンドを処理する、請求項15に記載の装置。
【請求項19】
前記ROI内の前記符号化ビデオをキャプチャするように構成された固定された非移動カメラを更に有し、
パンコマンドは、前記リモートUEが前記固定された非移動カメラを含む場合に、画像プレーンにわたる左または右の移動または変換にマッピングされる、または、
チルトコマンドは、前記リモートUEが前記固定された非移動カメラを含む場合に、前記画像プレーンにわたる上または下の移動または変換にマッピングされる、請求項15に記載の装置。
【請求項20】
前記1または複数のPTZFコマンドは、遠隔カメラ制御(FECC)プロトコルに従って、前記ローカルUEから受信される、請求項15に記載の装置。
【発明の詳細な説明】
【背景技術】
【0001】
ストリーミングサービスおよび会話型サービスを含むマルチメディアサービスの成長は、新しい移動広帯域技術および規格に対する進化の主要な推進要因の1つである。デジタルビデオコンテンツは、携帯デバイスにおける消費が次第に増加している。日常生活では、携帯デバイス上で幅広く使用される多くのビデオアプリケーションが存在する。例えば、オンライン・ビデオ・ストリーミングは、YouTube(登録商標)やHuluのような人気のあるサービスを含む。ビデオ録画およびビデオ会議は、SkypeやGoogle Hangoutのようなサービスを含む。2011年には、YouTube(登録商標)は、世界中で1兆回以上の視聴を有した。視聴の10パーセントは、携帯電話またはタブレットを介してアクセスされた。より多くのスマートフォン、タブレット、および他の携帯コンピューティングデバイスが購入されるにつれて、ビデオ録画およびビデオ会議のためにそれらを使用することが、劇的に増加するであろう。マルチメディアサービスに対するそのような高い消費者の要求が、メディア圧縮およびワイヤレス・ネットワーク・インフラストラクチャにおける発展と結合される状況では、将来のセルラおよび移動広帯域システムのマルチメディアサービス能力を向上させると共に、高い体感品質(QoE)を消費者に届けることは関心のあることであり、これによって、任意の場所から、任意の時間に、任意のデバイスおよび技術を使用して、ビデオコンテンツおよびビデオサービスに普遍的にアクセスすることを保証する。
【発明を実施するための形態】
【0002】
本開示の特徴および利点は、以下に記載する詳細な説明を添付図面と併用して参照することで明らかとなるであろう。添付図面は、例として、本開示の特徴を共に図示している。添付図面は以下の通りである。
【0003】
(
図1)一例による関心領域(ROI)ズーム機能をサポートするIMS(MTSI)ベースビデオ会議システムを通じたマルチメディアテレフォニーサービスを示す。
【0004】
(
図2)一例による遠端カメラ制御(FECC)プロトコルを介して複数のパン・チルト・ズーム・フォーカス(PTZF)コマンドを生成し、複数のPTZFコマンドをシグナリングするユーザインターフェースを示す。
【0005】
(
図3)一例によるユーザ規定の関心領域(ROI)を1または複数のパン・チルト・ズーム・フォーカス(PTZF)コマンドにマッピングするための技術を例示する。
【0006】
(
図4)一例によるIMS(MTSI)ベースのビデオ会議アプリケーションを通じたマルチメディア電話サービスにおける関心領域(ROI)ズーム機能を開始するためのリモートユーザ装置(UE)とローカルUEとの間の通信を示すフロー図である。
【0007】
(
図5A)一例によるリアルタイムトランスポートプロトコル(RTP)ヘッダ拡張技術に基づく強化型遠端カメラ制御(FECC)プロトコル能力を示すセッション記述プロトコル(SDP)提供メッセージを示す。
【0008】
(
図5B)一例によるリアルタイムトランスポートプロトコル(RTP)ヘッダ拡張技術に基づく強化型遠端カメラ制御(FECC)プロトコル能力を承認するセッション記述プロトコル(SDP)応答メッセージを示す。
【0009】
(
図6A)一例によるリアルタイムトランスポート制御プロトコル(RTCP)フィードバック技術に基づく強化型遠端カメラ制御(FECC)プロトコル能力を示すセッション記述プロトコル(SDP)提供メッセージを示す。
【0010】
(
図6B)一例によるリアルタイムトランスポート制御プロトコル(RTCP)フィードバック技術に基づく強化型遠端カメラ制御(FECC)プロトコル能力を承認するセッション記述プロトコル(SDP)応答メッセージを示す。
【0011】
(
図7)一例によるリモートUEとビデオ会議を実行するように動作可能なローカルユーザ装置(UE)の機能を示す。
【0012】
(
図8)一例による対話型ズーム機能をサポートするローカルユーザ装置(UE)にてビデオ会議アプリケーションを動作するためにそれに関して具現化された命令を有する少なくとも1つの非一時的機械可読記憶媒体のフローチャートを示す。
【0013】
(
図9)一例によるリモートUEとビデオ会議を実行するように動作可能なローカルユーザ装置(UE)の機能を示す。
【0014】
(
図10)一例によるローカルUEとビデオ会議を実行するように動作可能なリモートユーザ装置(UE)の機能を示す。
【0015】
(
図11)一例による無線デバイス(例えば、UE)を示す図である。
【0016】
ここで、説明される複数の例示的な実施形態に対して、参照がなされ、特定の言語は、それを説明するために本明細書において使用されるであろう。それにも関わらず、それにより本発明の範囲の限定は意図されないことは、理解されるであろう。
【0017】
本発明が開示され、説明される前に、次のことは理解されるべきである。即ち、この発明は、本明細書で開示される特別な構造、プロセスステップ、または材料に限定されないが、関連技術における当業者によって認識されると思われるような、それらの等価物に拡張される、ということは理解されるべきである。さらに理解されるべきことであるが、本明細書にて使用される用語は、特別な例を説明する目的のためだけに使用され、限定的であることは意図されるものではない。異なる複数の図面における同じ複数の参照数詞は、同じ要素を表す。複数のフローチャートおよびプロセスにおいて提供されている複数の数詞は、複数のステップおよび工程を図示するのを明瞭にするために提供されており、必ずしも、特定の順序またはシーケンスを示さない。
[例示的な実施形態]
【0018】
複数の技術の実施形態の最初の概要が以下に提供され、それゆえ特定の複数の技術の実施形態が後でさらに詳細に説明される。この最初の要約は、読み手が当該技術をより速く理解するのを助けることを意図されるが、当該技術の重要な特徴または不可欠な特徴を特定することを意図されるものではなく、請求の対象となる主題の範囲を限定することを意図されるものでもない。
【0019】
技術が、対話型ズーム機能をサポートするローカルユーザ装置(UE)でビデオ会議アプリケーションを動作させるために説明される。ローカルUEでのローカルユーザは、ビデオ会議アプリケーションを使用することによりリモートUEにてリモートユーザと通信することができる。ローカルUEのディスプレイスクリーン上のビデオ会議アプリケーションを介して、シーンを見ているローカルユーザは、シーン内の領域を選択することができる。この領域は、リモートUEでの視野内の関心領域(ROI)と呼ばれ得る。ローカルユーザが、ROI内のより詳細なコンテンツの表示を望む場合、ローカルユーザは、ROIを選択することができる。ローカルユーザは、対話型ズーム機能を使用して、シーンのビデオフィードからシーン内の選択された領域(すなわち、ROI)へ動的に切り替えることができる。ROIは、1または複数のパン・チルト・ズーム・フォーカス(PTZF)コマンドにマッピングされ得る。言い換えれば、複数のPTZFコマンドは、ローカルUEでのローカルユーザによって選択されたROIを説明または特徴づけることができる。ローカルUEは、リアルタイムトランスポート制御プロトコル(RTCP)フィードバックメッセージを介して、または、代わりに、リアルタイムトランスポートプロトコル(RTP)ヘッダ拡張を使用して、リモートUEにPTZFコマンドを通信することができる。リモートUEは、ROIを特定するべく複数のPTZFコマンドを処理することができる。リモートUEは、ROI内のビデオをキャプチャすることができる。また、リモートUEは、ROI内のビデオを符号化することができる。符号化ビデオは、ROI内の領域を含み、ROI外の領域を除くことができる。リモートUEは、符号化ビデオをローカルUEへ送信することができる。符号化ビデオは、規定された品質レベルを実質的に維持しつつ、増大されたズームレベルにてROI内の領域を含むことができる。言い換えれば、リモートUEは、ローカルUEでの符号化ビデオの再生を可能にするべく、ROI内の符号化ビデオを提供することができる。シーンの選択された領域(すなわち、ROI)のみをローカルUEへ送信し、シーンの非選択領域を送信から除くリモートUEにより、ビデオ会議アプリケーションは、利用可能な帯域幅をより効果的に使用することができる。
【0020】
これまでに多くのマルチメディア規格が存在するが、それらは、マルチメディアが、携帯コンピューティングデバイスへ、携帯コンピューティングデバイスから、または携帯コンピューティングデバイス間で通信されるのを可能とするために開発されてきた。例えば、ビデオのストリーミングについて、第3世代パートナシッププロジェクト(3GPP)が、オンデマンドコンテンツまたはライブコンテンツのユニキャストストリーミングのためのリアルタイムストリーミングプロトコル(RTSP)に基づくパケット交換ストリーミングサービス(PSS)を説明している技術仕様書(TS)26.234(例えば、リリース11.0.0)を開発した。また、プログレッシブダウンロードおよびHTTPを介したダイナミックアダプティブストリーミング(DASH)を含むハイパーテキスト転送プロトコル(HTTP)ベースのストリーミングサービスは、3GPP TS 26.247(例えば、リリース11.0.0)に説明されている。3GPPベースのマルチメディアブロードキャストマルチキャストサービス(MBMS)の仕様のTS26.346(例えば、リリース11.0.0)は、マルチキャスト/ブロードキャストのコンテンツ配信のためのストリーミングおよびダウンロードの技術を規定している。そのため、ユーザ機器(UE)のような、DASH/PSS/MBMSをベースとした携帯コンピューティングデバイスは、UEデバイスにおいて、ストリームされたビデオを復号すると共にレンダリングする。3GPP TS26.244(例えば、リリース11.0.0)における3GPファイルフォーマットのサポートは、ファイルダウンロードおよびHTTPベースのストリーミングの利用ケースをサポートするべく、これらの仕様のいずれにおいても義務付けられている。
【0021】
会話形式ビデオ通信、例えば、ビデオ会議の規格の1つの例が3GPP TS 26.114(例えば、11.0.0)に規定されている。この規格は、高度なマルチメディア会話型サービスおよびコンテンツを、インターネットプロトコル(IP)マルチメディアサブシステム(IMS)ベースのネットワークを介して配信可能にする、IMSを介したマルチメディア電話サービス(MTSI)を説明している。IMSは、3GPP TS 26.140(例えば、リリース11.0.0)で規格化されている。3GPP TS 26.140はメディア操作およびインタラクションを説明し、メディア制御、メディアコーデック、メディアおよび制御データのトランスポートを含む。3GPP TS 26.140はまた、3GPファイルフォーマット向けのサポートが提供されているマルチメディア共有サービス(MMS)を使用したビデオ共有を可能とする。
【0022】
さらに詳細に以下に説明されるように、MTSI呼び出しは、その呼び出し(例えば、ビデオ会議アプリケーション)に含まれる複数のUE間の制御プレーンシグナリングを再経路化するべく、複数の呼び出しセッション制御機能(CSCF)機構を使用することができる。制御プレーンにおいて、アプリケーションサーバ(AS)が存在することができ、呼び出し保留または再開、呼び出し転送、および多者呼び出しなどのような補足的サービスを提供することができる。
【0023】
MTSIベースの送信側UE端末は、ビデオをキャプチャおよび録画することができ、次に当該ビデオをMTSIベースの受信側UE端末に3GPPネットワークを通じて転送することができる。受信側UE端末は、次に、ビデオを復号およびレンダリングすることができる。MTSIにおいて、セッション開始プロトコル(SIP)は、ビデオ会議、インターネット電話呼び出しなどのような、会話形式マルチメディアセッションを確立、修正さらおよび停止するべくアプリケーション層制御プロトコルとして使うことができる。送信および受信端末間のセッション記述プロトコル(SDP)ベースのシグナリングは、コーデック、ビットレート、解像度などを含むメディア関連能力のネゴシエーションにおける提供/応答の考慮を可能にすることができる。MTSIのメディアのトランスポートは、UDP/IPを通じてリアルタイムトランスポートプロトコル(RTP)(IETF RFC 3550によって指定される)に基づく。
【0024】
キャプチャデバイスの解像度、ひいては圧縮ビデオの解像度は、急激に向上している。例えば、最近の高効率ビデオ符号化(HEVC)規格を使用すれば、4Kコンテンツが、操作可能製品の一部としてトランスポートされ、格納され得る。4k×2kの解像度を有するカメラが、現在広く利用可能である。ライブストリーミングビデオが、8k×4kの解像度で実証されている。画素数の点から、解像度は将来向上する可能性があある。これらの非常に高い解像度のコンテンツにより、対話型ズーム機能のようなビデオストリーミングの新たな使用法が現在可能である。
【0025】
現在市場に存在する、MTSIなどの会話形式のビデオサービスは、帯域幅、空間解像度、指向性などの点からビデオのダイナミックな適合を可能にする。しかしながら、これらの会話形式のビデオサービスは、ユーザがストリーミングされているビデオにてユーザ選択領域へと動的に切り替えて、このユーザ選択領域に対する符号化を最適化することを可能にしない。その結果、ビデオ呼び出し時の対話型ズーム機能の使用中に達成可能なビデオ解像度は、限定され得る。受信機アプリケーションが関心領域(ROI)へとズームインし、ビデオの不要な部分を切り落とすことができるが(例えば、ユーザインターフェースからのコマンドに応答して)、現在のシステムの1つの制約は、送信端末が、受信端末からのROIシグナリングがない時にビデオフレーム全体を今まで通り符号化し送信してしまうことである。
【0026】
1つの例において、MTSI受信機からMTSI送信機へのROI情報のシグナリングは、MTSI送信機がより高品質のストリームを配信することを可能にし得る。MTSI送信機は、ビデオのROI部分の符号化に対してネゴシエーションされたビットレートを完全にまたは重点的に使用することができる。これを可能にするべく、両方向のシグナリングが実行され得る。MTSI送信機は、能力を示すべくMTSI受信機にメッセージを送信することができ、MTSI受信機は、所望のROIを示すべくMTSI送信機にメッセージを送信することができる。
【0027】
図1は、関心領域(ROI)ズーム機能をサポートするIMSを通じたマルチメディア電話サービス(MTSI)ベースの例示的なビデオ会議システムを示す。リモートユーザ装置(UE)128(例えば、携帯電話、タブレットコンピュータ、デスクトップコンピュータ、または他の適したデバイス)と関連するユーザ(例えば、ユーザA)は、ローカルUE148と関連する別のユーザ(例えば、ユーザB)とビデオ会議中であり得る。言い換えれば、リモートUE128およびローカルUE148の両方が、二方向ビデオ会議アプリケーション160を実行中であり得る。ユーザAは、リモートUE128と近接し得(例えば、リモートUE128の前)、ユーザBは、ローカルUE148と近接し得る(例えば、ローカルUE148の前)。両方のリモートUE128およびローカルUE148はそれぞれ、ビデオ会議アプリケーション160が実行している間、ユーザが互いを見ることを可能にするカメラを含むことができる。リモートUE128は、リモートカメラを含むことができ、ローカルUE148は、ローカルカメラを含むことができる。リモートUE128は、動作中にユーザAのビデオをキャプチャするカメラと、動作中にユーザBのビデオをユーザAに表示するディスプレイスクリーンとを含むことができる。同様に、ローカルUE148は、動作中にユーザBのビデオをキャプチャするカメラと、動作中にユーザAのビデオをユーザBに表示するディスプレイスクリーンとを含むことができる。言い換えれば、ユーザAは、リモートUE128上のディスプレイスクリーンを介してユーザBを見ることができ、ユーザBは、ローカルUE148上のディスプレイスクリーンを介してユーザAを見ることができる。
【0028】
1つの例において、ビデオ会議アプリケーション160は、MTSIベースの会話形式ビデオシステムを通じて可能である。言い換えれば、ビデオ会議アプリケーション160は、3GPPベースのマルチメディア電話サービスを通じて動作することができ、これによりリモートUE128およびローカルUE148を互いに接続し、電話ネットワークと接続する。
【0029】
リモートUE128は、無線アクセスネットワーク(RAN)126、サービング汎用パケット無線サービス(GPRS)サポートノード(SGSN)124および/またはゲートウェイGPRSサポートノード(GGSN)122を介してコアネットワークと接続することができる。リモートUE128は、代理呼セッション制御機能(P-CSCF)120を介してデータを送信および受信することができる。P-CSCF120は、サービス呼セッション制御機能(S-CSCF)114を用いてデータを送信および受信することができる。いくつかの例において、S-CSCF114は、アプリケーションサーバ(AS)122からのデータを送信および受信することができ、呼び出し保留/再開、呼び出し転送および多者呼び出しなどのような補足的サービスを提供することができる。この例では、RAN126、SGSN124、GGSN122、P-CSCF120、S-CSCF114およびAS112が、オペレータA110と関連され得る。S-CSCF114は、コアネットワークの複数の他の部分からのデータを送信および受信をすることができる。例えば、オペレータA110と関連するS-CSCF114は、オペレータB130と関連するインタロゲーティングCSCF(I-CSCF)136と通信することができる。
【0030】
ローカルUE148は、それ自身の無線アクセスネットワーク(RAN)146、サービング汎用パケット無線サービス(GPRS)サポートノード(SGSN)144およびゲートウェイGPRSサポートノード(GGSN)142を介してコアネットワークと接続することができる。ローカルUE148は、代理呼セッション制御機能(P-CSCF)140を介してデータを送信および受信することができる。P-CSCF140は、サービス呼セッション制御機能(S-CSCF)134でデータを送信および受信することができる。いくつかの例において、S-CSCF134は、アプリケーションサーバ(AS)132からのデータを送信および受信することができ、呼び出し保留/再開、呼び出し転送および多者呼び出しなどのような補足的サービスを提供することができる。S-CSCF114およびS-CSCF134はそれぞれ、インタロゲーティングCSCF(I-CSCF)136と通信することができる。言い換えれば、オペレータA110は、S-CSCF114とI-CSCF136との間の通信を介してオペレータB130と通信することができる。I-CSCF134は、ホーム加入者サーバ(HSS)138および/または加入者ロケーション機能(SLF)138に書き込みおよび読み取りすることができる。この例において、RAN146、SGSN144、GGSN142、P-CSCF140、HSS/SLF138、I-CSCF136、S-CSCF134およびAS132は、オペレータB130と関連し得る。
【0031】
1つの構成において、ビデオ会議アプリケーション160は、ズーム機能をサポートすることができる。例えば、ローカルUE148は、リモートカメラ(すなわち、リモートUE128と関連するカメラ)の視野の特定の特徴または場所へとズームすることができる。ローカルUE148で、ユーザBは、リモートUE128での視野内の関心領域(ROI)150を規定することができる。非限定的な例として、リモートUE128にて、ユーザAは、リモートUE128のディスプレイスクリーン上にユーザBの頭を見ることができる。ローカルUE148で、ユーザBは、ローカルUE148のディスプレイスクリーン上にユーザAの頭および胴を見ることができる。ユーザBは、ユーザAの向上されたビューを要求することができる(例えば、ユーザBは、ユーザAの顔へとズームするように要求することができる)。ユーザBは、ROI150がユーザAの顔を含むようにローカルUE150でROI150を規定することができる。ROI150は、例えば、グラフィカルなユーザインターフェースを使用して、ローカルUE150で規定され得る。言い換えれば、ユーザBは、コンピュータマウスまたはタッチスクリーンなどの入力デバイスを使用して領域を選択してよい。ROI150は、リモートカメラの視野内の複数の他の適した領域を含むことができる。例えば、ユーザBは、ユーザAの胴、ユーザAの背後の木などを含むようROI150を規定することができる。複数の他の例として、ROI150は、ローカルUE148のディスプレイスクリーンの右上領域(リモートカメラの適切な視野に対応する)、ローカルUE148のディスプレイスクリーンの左下領域などを含むことができる。
【0032】
1つの例において、ユーザBは、ROI150をリモートカメラの視野内の任意のサイズおよび場所を有するように規定することができる。別の例において、リモートUE128は、ROI150が規定された場合、静止したままとすることができ、その結果、ROI150の選択により、リモートカメラの視野を移動または変化させない。さらに別の例において、ユーザBは意のままに新しいROI150を選択することができる。さらに、ユーザA(リモートUE128で)はまた、ユーザB(ローカルUE148で)にズームインするべく類似したROIを選択することができる。
【0033】
さらに詳細に以下に説明されるように、ROI150は、1または複数のパン・チルト・ズーム・フォーカス(PTZF)コマンドにマッピングされ得る。複数のPTZFコマンドは、ユーザBによって選択されるROI150を特徴づけるか、記述することができる。1つの例において、一連のPTZFコマンドまたは連続するPTZFコマンドは、ROI150を記述するのに使用され得る。複数のPTZFコマンドは、H.281/H.224プロトコルにさらに規定され得る。複数のPTZFコマンドは、具体的な座標の使用とは対照的に、ROI150の特徴づけに対する代替解決策となり得る。ROI150を記述する複数のPTZFコマンドは、ローカルUE148からリモートUE128に送信され得る。さらに詳細に以下に述べられるように、ROI150を記述する複数のPTZFコマンドは、リアルタイムトランスポート制御プロトコル(RTCP)フィードバックメッセージを使用して通信され得る。代替解決策において、ROI150を記述する複数のPTZFコマンドは、キャプチャされたローカルビデオ(すなわち、ローカルUE148にキャプチャされたビデオ)の少なくとも1つのリアルタイムトランスポートプロトコル(RTP)ヘッダ拡張に埋め込まれ得る。RTCPフィードバックメッセージまたはRTPヘッダ拡張は、ROI110内のビデオをキャプチャようにリモートUE128を指示することができる。
【0034】
いくつかの例において、リモートUE128は、ROI150だけを含み、ROI150外の複数の領域を除くビデオをキャプチャすることができる。非限定的な例として、RTPヘッダ拡張またはRTCPフィードバックメッセージ(ROI150を記述する複数のPTZFコマンドを含む)はリモートUE128に、ユーザAのあごの傷をキャプチャするように指示することができる。言い換えれば、リモートUEのカメラは、ユーザAのあごの傷のみをキャプチャすることができ、ユーザAのあごを囲む複数の他の領域はキャプチャしない。
【0035】
ROI150に従ってビデオをキャプチャする時、リモートUE128は、例えば、比較的低圧縮での符号化スキームを使用してビデオを符号化することができる。従って、ビデオは、規定された品質レベルを実質的に維持しつつ、ROI150の比較的大写しおよび詳細な表示を提供することができる。視野全体を符号化するべく以前に使用されたリソースが、現在はROI150を符号化するべく使用されるだけなので、リモートUE128は、あまり損失がない符号化スキームでビデオ(ROI150を有する)を符号化することができる。リモートUE128は、符号化ビデオ(ROIのみを有する)をローカルUE148に送信することができる。リモートUE128は、符号化ビデオ(ROI150のみを有する)を送信する場合に実質的に同じ量の帯域幅を消費することができるので、リモートカメラ(リモートUE128と関連する)の全視野とは対照的に、符号化ビデオは実質的に高品質となり得る。言い換えれば、ROIの符号化ビデオは、比較的鮮明に、かつ画質が粗くも、ぼやけてもなくできる。この点について、本明細書中に説明された技術は、ユーザ(例えば、ユーザB)が、ディスプレイスクリーンに表示されたフレームへと手動でズームすることで品質レベルの低減をもたらし得る以前の技術より優れている。現在の解決策において、リモートUE128は、キャプチャされたフレーム全体ではなくて、ネゴシエーションされた解像度でROI150のみを符号化することができ、これはローカルUE148でのより高い全体の解像度およびより良いユーザ体験をもたらすものである。
【0036】
非限定的な例として、リモートUE128は、ユーザAのあごの傷のビデオを符号化することができる。リモートUE128は、ユーザAのあごが、比較的大きな解像度および明瞭度レベルで見ることができるように、比較的低い圧縮度での符号化スキームを使用することができる。言い換えれば、符号化ビデオは、ユーザAのあごの表示にズームされ得るが、比較的高い品質レベル(例えば、画質が粗くない)を今まで通り維持することができる。また、帯域幅全体がユーザAのあごの符号化ビデオを送信するために使用され得、これによりユーザAのあごの比較的明確かつ詳細な表示がもたらされ得る。この表示は、ユーザAの顔全部が符号化ビデオの部分として含まれた場合とは対照的に、ユーザAの顔の付加的な詳細を提供することができる。
【0037】
代替構成において、リモートUE128は、(リモートUE128と関連する)リモートカメラの全視野を含むビデオをキャプチャすることができる。 しかしながら、リモートUE108は、ROI150を含むビデオの一部のみを符号化することができる。また、リモートUE108は、ROI150だけを含み、ROI150外の領域を除く符号化ビデオを送信することができる。
【0038】
ローカルUE148は、リモートUE128から符号化ビデオを受信することができ、符号化ビデオは、ROI150内の複数の領域を含み、ROI150外の複数の領域を除く。ローカルUE148は、ローカルUE148と関連するディスプレイスクリーン上に符号化ビデオをレンダリングおよび表示することができる。非限定的な例として、ローカルUE148の前に坐っているユーザBは、ユーザAのあごの傷の詳細かつ大写しの表示を見ることができる。ユーザBは、ユーザAの前の表示にいつでも戻ることができ、例えば、ユーザBは、非ズームとし、ローカルUE148のディスプレイスクリーン上のユーザAの顔全体および胴を表示する状態に戻ることができる。
【0039】
リアルタイムトランスポートプロトコル(RTP)ベースのマルチメディアサービス向けの国際電気通信連合(ITU)電気通信標準化セクタ(ITU-T)による遠端カメラ制御は、スタックインターネットプロトコル(IP)/ユーザデータグラムプロトコル(UDP)/RTP/H.224/H.281を使用して、ITU-T仕様H.224/H.281にて、およびインターネット技術タスクフォース(IETF)のリクエスト・フォー・コメント(RFC)4573にて規定される。
【0040】
遠端カメラ制御(FECC)プロトコルにおいて、関心領域(ROI)および特定のROIへのズーム化の指示は、ITU-T H.281によって規格化されるように、複数のPTZFつまり、パン・チルト・ズーム・フォーカスコマンドのシグナリングによって、達成され得る。例えば、開始動作メッセージのメッセージフォーマットは、以下のようにすることができる。
【表1】
【0041】
開始動作メッセージは、パン(P)用に、右(R)用の第1値、および左(L)用の第2値を含むことができる。 開始動作メッセージは、チルト(T)用に、上(U)用の第1値、および下(D)用の第2値を含むことができる。開始動作メッセージは、ズーム(Z)用に、ズームイン(I)用の第1値、およびズームアウト(O)用の第2値を含むことができる。開始動作メッセージは、フォーカス(F)用に、フォーカスイン(I)用の第1値、およびフォーカスアウト(O)用の第2値を含むことができる。
【0042】
FECCプロトコルは、H.224の上位のITU-T H.281に依存する。従って、ROI情報は、H.224フレームを伝えるRTPパケットを介してシグナリングされ得る。FECCは、H.224フレームに内在し得、H.224パケットのクライアントIDフィールドによって特定され得る。さらに、RFC4573は、H.224を使用する遠端カメラ制御プロトコルをサポートするべく使用される複数のセッション記述プロトコル(SDP)パラメータの統語論および意味論を規定する。SDP提供/応答は、2つのMTSIクライアント間の能力のネゴシエーションを可能にすることができる。
【0043】
3GPP MTSIの場合、カメラは、デバイス(例えば、タブレットまたはスマートフォン)に固定され得、実際には独立して制御される能力は有し得ない。パン/チルト能力がない固定カメラに対しては、パンコマンドは、左/右の移動/変換にマッピングされ得、チルトコマンドは、2次元(2D)画像プレーンにわたる上/下の移動/変換にマッピングされ得る。そのため、PTZコマンドの組み合わせは、任意の関心領域へのズーム化を可能にし得る。これらの機能は、vPTZ(仮想PTZ)と呼ばれる。カメラモーションは、例えば、パンまたはチルトが画像全体に適用された場合、カメラの入力バッファを変えることによってエミュレートされ得るが、修正は行われない。カメラがズームされる場合、より小さい長方形領域が選択され得、パンおよびチルトは次に、選択された長方形を変換することによって承認され得る。
【0044】
1つの例において、ROIシグナリングのためのFECCプロトコルの直接の利用は、潜在的に貧弱な帯域幅でリンク特性が動的に変動する移動体通信環境ではレイテンシの観点から不利となり得る。FECCは、ユーザが所望のROIを有するストリームを取得するまで、受信機(例えば、ユーザがROIを選択するローカルUE)による複数のPTZFコマンドの連続送信を使用するプログレッシブプロトコルである。言い換えれば、送信機(例えば、符号化が発生するリモートUE)は、正確なROI情報を有しない。また、受信機(例えば、ROI情報を生成するユーザインターフェースを有するローカルUE)は、送信機(例えば、リモートUE)が受信された複数のPTZFコマンドの処理時に使用する複数のステップサイズを知らない。複数のステップサイズは、所与のPおよびTコマンドから結果として生じる上/下および左/右変換の複数の画素を示すことができる。複数のステップサイズはまた、Zコマンドの送信後に発生するズーム量を示すことができる。これらの不確実性の要素により、所望のROIを有するストリームが受信され得るまで、FECCプロトコルを使用してPTZFコマンドシーケンスの送信を余儀なくさせ得る。
【0045】
非限定的な例として、ROIは、13個のPTZFコマンドを使用して説明され得る。言い換えれば、13個のPTZFコマンドは、受信機(または、ローカルUE)にてユーザによって選択されたROIを記述することができる。13個のPTZFコマンドは、受信機(例えば、ローカルUE)から送信機(例えば、リモートUE)へ送信され得る。従来の技術では、13個のPTZFコマンドを送信する時間量は、ラウンドトリップ時間(RTT)と、新たなPTZFコマンドを発行するユーザインターフェース遅延(UI_遅延)とに基づき得る。非限定的な例として、ラウンドトリップ時間は、300ミリ秒(ms)であり得、ユーザインターフェース遅延は、100msであり得る。従って、13個のPTZFコマンドを送信する時間量(すなわち、レイテンシ)は、13×UI_delay+RTT(つまり、1.6秒)と、13×RTT(つまり、3.9秒)との間に境界づけられ得る。言い換えれば、この例では、PTZFコマンドシーケンスを送信する場合のレイテンシは、1.6秒と3.9秒の中間になり得る。従って、要求されたROIに対応するストリームを見るべくユーザによって体験されるレイテンシは、従来の技術を使用した場合、3.9秒と同じくらい大きくなり得、不満足なユーザ体験となり得る。
【0046】
本明細書中に説明される新規な技術は、前のFECCプロトコルを拡張し、それにより、ビデオ受信機(例えば、ローカルUE)は、単一RTPパケットの(すなわち、単一伝送の)グループ化されたシーケンスの複数のPTZFコマンドをビデオ送信機または遠端端末(例えば、リモートUE)へ送信することができる。代替解決策において、ビデオ受信機は、単一RTCPパケットのグループ化されたシーケンスの複数のPTZFコマンドをビデオ送信機へ送信することができる。複数のPTZFコマンドが、ビデオ送信機においてある順序で実行され得、ビデオ送信機がメッセージの前後の交換により所望のROIへと迅速に収束することを可能にする。FECCプロトコルのこの拡張バージョンは、強化型FECC(eFECC)と呼ばれる。言い換えれば、強化型FECCサポートは、ビデオ受信機(例えば、ローカルUE)が単一伝送にてPTZFコマンドシーケンスを送信するように構成され、ビデオ送信機(例えば、リモートUE)がPTZFコマンドシーケンスを処理し、PTZFコマンドに基づきROIを特定し、それに応じてROI内のビデオを符号化するように構成されることを示すことができる。
【0047】
前の例において、13個のPTZFコマンドに送信する時間量は、従来の技術を使用した場合、1.6秒と3.9秒の中間になり得る。強化型FECCを使用することにより、同じ13個のPTZFコマンドを送信する時間量は、低減され得る。要求されたROIに対応するストリームを見るべく、ユーザによって体験されるレイテンシは、Ul遅延+RTTによって決定され得る。この例では、Ul遅延は、300msであり、RTTは100msであり、従ってレイテンシは400ms(つまり、0.4秒)となり得る。移動式設定に以前のFECCプロトコルをむやみに使用すると、ユーザが要求されるROIに対応するストリームを見る前に、体験されるレイテンシが許容できないレベルになる場合がある。強化型FECCを使用することにより、レイテンシ量は、低減され得る。
【0048】
図2は、遠端カメラ制御(FECC)プロトコルを介して、複数のパン・チルト・ズーム・フォーカス(PTZF)コマンドを生成し、複数のPTZFコマンドをシグナリングする例示的なユーザインターフェース240を示す。ユーザインターフェース240は、ローカルユーザ装置(UE)220に存在し得る。ローカルUE220の第1ユーザ210は、第2ユーザ230とビデオ会議中であり得る。第2ユーザ230は、第1ユーザ210とビデオ会議を実行するべくリモートUE(
図2に不図示)を使用中であり得る。従って、第1ユーザ210は、ローカルUE220上で実行中のビデオ会議アプリケーションを介して第2ユーザ230を見ることができる。第1ユーザ210は、ローカルUE220上のユーザインターフェース240を介して、関心領域(ROI)250を選択することができる。例えば、第1ユーザ210は、第2ユーザの顔の領域を選択することができる。第1ユーザ210によって選択されるこの領域は、ROI250を示すことができる。ROI250の選択に基づき、ローカルUE220は、PTZFコマンドシーケンスを生成することができる。ローカルUE220は、PTZFコマンドシーケンスをリモートUEに送信することができる。リモートUEは、PTZFコマンドシーケンスに基づきROI250を特定することができる。リモートUEは、ROI250を含む符号化ビデオを送信することができるのみである。従って、ローカルUE220のユーザインターフェース240は、ROI250をより詳細に第1ユーザ210に対して表示することができる。
【0049】
図3は、ユーザ規定の関心領域(ROI)330を1または複数のパン・チルト・ズーム・フォーカス(PTZF)コマンドにマッピングするための例示的な技術を示す。ユーザインターフェース310は、リモートユーザ320を表示することができる。ユーザインターフェース310は、ローカルユーザ装置(UE)と関連し得、リモートユーザ320は、リモートUEと関連し得る。1つの例において、ローカルUEと関連するローカルユーザは、1080pかつ1920×1080のネゴシエーション解像度でリモートユーザ320とビデオ会議中であり得る。ローカルUEのローカルユーザは、リモートユーザの顔へとズームすることを望む場合がある。言い換えれば、ローカルUEのローカルユーザは、リモートユーザの顔がユーザインターフェース310の増大された部分を満たし、より詳しく(すなわち、より大きなズームレベル)したいかもしれない。この場合、ローカルユーザは、ローカルUE上のユーザインターフェース310を介して関心領域(ROI)330を選択することができる。例えば、ローカルユーザは、リモートユーザの顔を包含するROI330を選択することができる。
【0050】
図3に示されるように、ユーザインターフェース310は、X方向とY方向にて選択された数のタイルへと分割され得る。ROI330のユーザ選択は、ローカルUEからリモートUEへと送信されるPTZFコマンドシーケンスへと変換され得る。1つの例において、Zコマンドは、XおよびY寸法の両方にて約90%に集中されたズームとなり得、元の画像の約10%をXおよびY寸法から除外し得る。Pコマンドは、中央タイル340を中心にした複数のタイルを越える左/右の動きをもたらし、Pコマンドごとに1つのステップの4分の1のXタイルサイズをもたらし得る。Tコマンドは、中央タイル340を中心にした複数のタイルを越える上/下の動きをもたらし、Tコマンドごとに1つのステップの4分の1のYタイルサイズをもたらし得る。
【0051】
図3に示されるように、ユーザ規定のROI330は、(1080,1560)のX座標、(540,810)のY座標と関連し得る。ユーザインターフェース310の左下隅は、(0,0)のXおよびY座標を有する原点となり得る。PTZFコマンドシーケンスを使用してROI330を表すべく、少なくとも8つのズームコマンド(
図3の実線の矢印によって示される)が、中央タイル340を取得するべく使用され得る。8つのズームコマンドは、X(720,1200)およびY(405,675)のX-Y座標でズームした後に中央タイル340を取得するべく使用され得、対応する中央タイル340は、480×270の寸法を有する。言い換えれば、中央タイル340は、480画素のXタイルサイズと、270画素のYタイルサイズとを有する。また、上方向の少なくとも2つのコマンドおよび右方向の少なくとも3つのコマンドは、ROI330(
図3の破線の矢印によって示される)を取得するべく使用され得る。従って、総数13個のPTZFコマンドが、ROI330を記述または特徴づけるべく使用され得る。複数のPTZFコマンドは、ローカルUEからリモートUEに送信され得る。リモートUEは、複数のPTZFコマンドに基づきROI330を特定し、それに応じてROI330内のビデオをローカルUEに提供することができる。
【0052】
図4は、IMS(MTSI)ベースのビデオ会議アプリケーションを通じたマルチメディア電話サービスにおける関心領域(ROI)ズーム機能を開始するためのリモートユーザ装置(UE)402とローカルUE404との間の通信を示す例示的なフロー図である。1つの例において、リモートUE402は、送信クライアントと呼ばれ得、ローカルUE404は、受信クライアントと呼ばれ得る。リモートUE402およびローカルUE404はそれぞれ、リモートUE402と関連するリモートユーザが、ローカルUE404と関連するローカルユーザと通信することを可能にするビデオ会議アプリケーションを実行することができる。
【0053】
リモートUE402とローカルUE404との間でのセッション記述プロトコル(SDP)ベースのシグナリングは、強化型遠端カメラ制御(FECC)プロトコルサポートに向けたメディア関連能力のネゴシエーションにおける提供/応答の考慮を可能にすることができる。強化型FECCプロトコルサポートは、ローカルUE404(または受信機)の能力を示すことができ、単一のリアルタイムトランスポート制御プロトコル(RTCP)フィードバックメッセージの、および/または、RTPヘッダ拡張機構を使用した単一のリアルタイムトランスポートプロトコル(RTP)パケットのH.281/H.224FECCプロトコルを使用したグループ化されたパン・チルト・ズーム・フォーカス(PTZF)コマンドシーケンスを送信する。また、強化型FECCプロトコルサポートは、リモートUE402(または送信機)の能力を示し、PTZFコマンドシーケンスを処理し、複数のPTZFコマンドに基づく関心領域(ROI)を特定し、それに応じてROI内のビデオを符号化することができる。
【0054】
リモートUE402は、SDP提供メッセージをローカルUE404に送信することができる。SDP提供メッセージは、前述のように、リモートUE404が強化型FECCプロトコルをサポートすることを示すことができる。ローカルUE404は、リモートUE402からのSDP提供メッセージを受信し得、応答して、強化型FECCプロトコル能力を承認するSDP応答メッセージを送信し得る。
【0055】
1つの構成において、リモートUE402は、複数のステップサイズをローカルUE404に送信することができる。言い換えれば、複数のステップサイズは、リモートUE404およびローカルUE404からのシグナリングに含まれ得る。ローカルUE404は、リモートUE402が受信された複数のPTZFコマンドの処理時に使用するであろう複数のステップサイズを最初は知らない。従って、リモートUE402は、複数のステップサイズをローカルUE404に送信することができる。リモートUE402は、複数の専用のRTPヘッダ拡張属性として複数のステップサイズを送信することができる。複数のステップサイズは、所与のPおよびTコマンドから生じる複数の画素の上/下および左/右変換を示すことができる。複数のステップサイズはまた、Zコマンドの送信後に発生するズーム量を示すことができる。その結果、ローカルUE404は、複数のPTZFコマンドがどのようにリモートUE402で処理されるかを決定することができ、ローカルUE404がそれに応じて複数のPTZFコマンドを選択することができる。
【0056】
ローカルUE404は、リモートUE402から前に受信された複数のステップサイズに基づいて複数のPTZFコマンドシーケンスを導出することができる。複数のPTZFコマンドは、ユーザ規定の関心領域(ROI)に対応することができる。言い換えれば、ROIは、ローカルUE404のローカルユーザによって規定され得る。ローカルUE404は、PTZFコマンドシーケンスをリモートUE402にシグナリングすることができる。1つの構成において、PTZFコマンドシーケンスは、単一伝送において、ローカルUE404からリモートUE402に送信され得る。言い換えれば、PTZFコマンドは、共にグループ化され、同時にリモートUE402に送信され得る。例えば、PTZFコマンドシーケンスは、単一RTCPパケットで送信され得る。あるいは、PTZFコマンドシーケンスは、単一RTPパケットでRTPヘッダ拡張として送信され得る。ローカルUE404は、複数の逆方向のビデオストリーム用のRTPヘッダ拡張を使用して、PTZFコマンドシーケンスをリモートUE402に通信することができる。
【0057】
リモートUE402は、PTZFコマンドシーケンスをローカルUE404から受信することができる。リモートUE402は、PTZFコマンドシーケンスに基づきROIを特定することができる。複数のPTZFコマンドは、単一伝送にて共にグループ化されるので、リモートUE402は、複数のPTZFコマンドを迅速に処理し、低レイテンシで所望のROIに対応するストリームを配信することができる。リモートUE402は、ROIだけを含み、ROI外の複数の領域を除くビデオをキャプチャすることができる。リモートUE402は、ROIのみを含むビデオを符号化することができる。リモートUE402は、ローカルUE404に符号化ビデオを送信することができる。1つの例において、リモートUE402はまた、複数の順方向ビデオストリーム用のRTPヘッダ拡張に実際に送信されたROIを示すことができる。ローカルUE404は、ROIを含む符号化ビデオを受信し、ローカルUE404でビデオを再生することができる。
【0058】
複数のPTZFコマンド(例えば、ROI情報)が、RTPヘッダ拡張メッセージを使用してローカルUE404からリモートUE402にシグナリングされた場合、強化型FECC機能(前述のように)をサポートするMTSIクライアントは、ビデオを含む全てのメディアストリーム向けの複数のSDPメッセージの強化型FECCを提供することができる。強化型FECCは、関連するメディアラインスコープ下で強化型FECC統一資源名(URN)を示すa=extmap属性を含むことにより、提供され得る。例えば、強化型FECC URNは、urn:3gpp:efeccと設定され得る。このURNを含むメディアラインの例は、a=extmap:7urn:3gpp:efeccである。メディアラインの上記の例では、番号7は、1から14の範囲の任意の番号と置き換えられ得る。
【0059】
複数のPTZFコマンド(例えば、ROI情報)が、RTCPメッセージを使用してローカルUE404からリモートUE402へシグナリングされる場合、強化型FECC機能をサポートするMTSIクライアントは、ビデオを含む全てのメディアストリーム向けの複数のSDPメッセージでeFECCを提供することができる。強化型FECC機能は、関連するメディアラインスコープの下に新規なeFECCタイプに対するa=rtcp-fb属性を含むことにより提供され得る。例えば、RTCPフィードバック技術と併用したeFECCタイプは、3gpp:efeccなるパラメータで表現され得る。ワイルドカードペイロードタイプ(「*」)は、RTCPフィードバック属性強化型FECCが全てのペイロードタイプに適合することを示すべく使用され得る。複数のタイプのROIフィードバックがサポートされる場合、および/または、同じROIフィードバックがペイロードタイプのサブセットに対して規定されるべきである場合、複数のa=rtcp-fbラインが使用され得る。RTCPフィードバック技術に基づくメディアラインに関連したeFECCをシグナリングするこの属性の例示的な使用法は、a=rtcp-fb:*3gpp-efeccである。
【0060】
RTCPフィードバック技術は、即時フィードバック技術および複数の早期RTCPモードの両方での複数のPTZFコマンド(例えば、ROI)のシグナリングを含むことができる。eFECC用の新規なRTCPフィードバックタイプは、3gpp-efeccのバリューネーム、強化型遠端カメラ制御のロングネーム、および第3世代パートナシッププロジェクト(3GPP)技術仕様(TS)26.114のリファレンスを含むことができる。
【0061】
強化型FECC能力は、クライアントがSDP能力のネゴシエーション中にどのように特徴をサポートするかによって双方向的または一方向的にサポートされ得る。非対称能力(例えば、複数のPTZFコマンドまたはROI情報を処理するが、ROI情報を検出/シグナリングしない能力)を備えた複数の端末に対して、「sendonly」および「recvonly」属性が使用され得る。複数の端末は、十分明確なやり方で各方向にそれらの能力を表現することができ、それにより、複数の信号は両方が有用な情報を表現し、受信者によって処理され得る程度に各方向に送信されるだけである。
【0062】
強化型FECC機能は、複数のPTZFコマンドシーケンスにて受信ユーザ(リモートUE402と関連する)の現在のROIのシグナリングを含むことができる。複数のPTZFコマンドのシグナリングは、H.281/H.224プロトコルに基づき得る。複数のPTZFコマンドは、リモートUE402(例えば、送信機)へ送信され得、それにより、リモートUE402は、ROI内にキャプチャされたビデオを最適に符号化して送信することができる。強化型FECCがうまくネゴシエーションされた場合、MTSIクライアントによってシグナリングされ得る。PTZFコマンドシーケンスのシグナリングは、単一RTCPメッセージ、またはRTPヘッダ拡張を使用した単一RTPパケットを通じてグループ化されたやり方で発生し得る。
【0063】
複数のRTCPフィードバックメッセージを使用する場合、ローカルUE404(すなわち、受信端末)は、リモートUE402(すなわち、送信端末)へ送信中のRTCPフィードバックメッセージの受信ユーザの現在のROI情報に対応するPTZFコマンドシーケンスを含むことができる。RTPヘッダ拡張を使用する場合、ローカルUE404(すなわち、受信端末)は、リモートUE402(すなわち、送信端末)へ送信中の複数のRTPパケットに受信ユーザの現在のROI情報に対応するPTZFコマンドシーケンスを含むことができる。これらのRTPパケットは、MTSIの双方向ビデオ通信に対して使用され得る逆方向に複数のビデオストリームを伝えることができる。
【0064】
図5Aは、例示的なセッション記述プロトコル(SDP)提供メッセージを示す。SDP提供メッセージは、リモートユーザ装置(UE)からローカルUEへ通信され得る。SDP提供メッセージは、リアルタイムトランスポートプロトコル(RTP)ヘッダ拡張技術に基づき得る。SDP提供メッセージは、リモートUEでの強化型遠端カメラ制御(FECC)プロトコル能力を示すことができる。特に、強化型FECCプロトコル能力は、ローカルUEから受信されたパン・チルト・ズーム・フォーカス(PTZF)コマンドシーケンスを処理し、PTZFコマンドシーケンスからの関心領域(ROI)を特定し、それに応じてROI内のビデオを符号化するリモートUEの能力を示すことができる。例として、SDP提供メッセージは、a=extmap」の属性と、「4urn:3gpp:efecc」の関連値とを含むことができる。
【0065】
図5Bは、例示的なセッション記述プロトコル(SDP)応答メッセージを示す。SDP応答メッセージは、ローカルユーザ装置(UE)からリモートUEへ通信され得る。SDP応答メッセージは、リアルタイムトランスポートプロトコル(RTP)ヘッダ拡張技術に基づき得る。SDP応答メッセージは、リモートUEの強化型遠端カメラ制御(FECC)プロトコル能力を承認することができる。例として、SDP応答メッセージは、「a=extmap」の属性と、「4urn:3gpp:efecc」の関連値とを含むことができる。
【0066】
図6Aは、例示的なセッション記述プロトコル(SDP)提供メッセージを示す。SDP提供メッセージは、リモートユーザ装置(UE)からローカルUEへ通信され得る。SDP提供メッセージは、リアルタイムトランスポート制御プロトコル(RTCP)フィードバック技術に基づき得る。SDP提供メッセージは、リモートUEにて強化型遠端カメラ制御(FECC)プロトコル能力を示すことができる。特に、強化型FECCプロトコル能力は、ローカルUEから受信されたパン・チルト・ズーム・フォーカス(PTZF)コマンドシーケンスを処理し、PTZFコマンドシーケンスからの関心領域(ROI)を特定し、それに応じてROI内のビデオを符号化するリモートUEの能力を示すことができる。例として、SDP提供メッセージは、「a=rtcp-fb」の属性と、「3gpp:efecc」の関連値とを含むことができる。
【0067】
図6Bは、例示的なセッション記述プロトコル(SDP)応答メッセージを示す。SDP応答メッセージは、ローカルユーザ装置(UE)からリモートUEへ通信され得る。SDP応答メッセージは、リアルタイムトランスポート制御プロトコル(RTCP)フィードバック技術に基づき得る。SDP応答メッセージは、リモートUEの強化型遠端カメラ制御(FECC)プロトコル能力を承認することができる。例として、SDP応答メッセージは、「a=extmap」の属性と、「4urn:3gpp:efecc」の関連値とを含むことができる。
【0068】
別の例は、
図7のフローチャートに示されるように、リモートUEとビデオ会議を実行するように動作可能なローカルユーザ装置(UE)の機能700を提供する。機能は、方法として実施され得、または、機能は、機械上で複数の命令として実行され得る。ここで、複数の命令は、少なくとも1つのコンピュータ可読媒体または1つの非一時的機械可読記憶媒体に含まれる。ローカルUEは、ブロック710のように、リモートUEのカメラの視野内に、ローカルUEにて関心領域(ROI)を規定するように構成される1または複数のプロセッサを有することができる。1または複数のプロセッサは、ブロック720のように、ROIを1または複数のパン・チルト・ズーム・フォーカス(PTZF)コマンドへマッピングするように構成され得る。1または複数のプロセッサは、ブロック730のように、ローカルUEからリモートUEへ1または複数のPTZFコマンドを送信するように構成され得、リモートUEは、1または複数のPTZFコマンドに基づきROIを特定するように構成される。1または複数のプロセッサは、ブロック740のように、リモートUEからROI内の符号化ビデオを受信するように構成され得、符号化ビデオはROI内の領域を含み、ROI外の領域を除き、符号化ビデオは、ROI内の符号化ビデオがローカルUEにてレンダリングおよび表示されるのを可能にするべく規定された品質レベルを実質的に維持しつつ、増大されたズームレベルでROI内の複数の領域を含む。
【0069】
1つの構成において、第1プロセッサは、ブロック710および720の工程を実行することができる。第1プロセッサは、単一プロセッサであり得、または、代わりに、第1プロセッサは、1または複数の別個のプロセッサから成り得る。1つの構成において、第2プロセッサは、ブロック730および740の工程を実行することができる。第2プロセッサの1つの例は、ベースバンドプロセッサである。
【0070】
1つの例において、1または複数のPTZFコマンドは、国際電気通信連合(ITU)H.281/H.224プロトコルに基づく。別の例において、1または複数のプロセッサは、1または複数のPTZFコマンドを単一伝送にてリモートUEへ送信するように構成される。さらに別の例において、ROIは、ローカルUEと対話するユーザによって選択される。また、1または複数のプロセッサは、リアルタイムトランスポート制御プロトコル(RTCP)フィードバックメッセージを使用して、1または複数のPTZFコマンドをリモートUEに送信するように構成される。
【0071】
1つの例において、1または複数のプロセッサは、少なくとも1つのリアルタイムトランスポートプロトコル(RTP)ヘッダ拡張に1または複数のPTZFコマンドを埋め込み、キャプチャされたローカルビデオをリモートUEへ送信するように構成され、キャプチャされたローカルビデオは、1または複数のPTZFコマンドを有するRTPヘッダ拡張を含む。別の例において、1または複数のプロセッサはさらに、ローカルUEから送信された1または複数のPTZFコマンドを処理するべくリモートUEにて使用される、リモートUEからの1または複数のステップサイズを受信するように構成される。
【0072】
1つの例において、1または複数のステップサイズは、複数の専用リアルタイムトランスポートプロトコル(RTP)ヘッダ拡張属性としてシグナリングされる。別の例において、符号化ビデオは、リモートUEの固定された非移動カメラを使用してキャプチャされる。さらに別の例において、1または複数のPTZFコマンドが遠端カメラ制御(FECC)プロトコルに従ってリモートUEへ送信される。また、1または複数のプロセッサはさらに、リモートUEが1または複数のPTZFコマンドを受信するための強化型遠端カメラ制御(FECC)プロトコルをサポートすることを示す、リモートUEからのセッション記述プロトコル(SDP)提供メッセージを受信するように構成される。
【0073】
1つの例において、1または複数のプロセッサはさらに、ローカルUEが1または複数のPTZFコマンドを送信するための強化型遠端カメラ制御(FECC)プロトコルをサポートすることを確認するセッション記述プロトコル(SDP)応答メッセージを送信するように構成される。別の例において、1または複数のプロセッサは、1または複数のPTZFコマンドをリモートUEに送信するように構成され、リモートUEは、1または複数のPTZFコマンドに対応し、ROI内のビデオを符号化するだけのROI内のビデオをキャプチャするように構成される。さらに別の例において、1または複数のプロセッサはさらに、ROIベースの対話型ズーム機能をサポートするリモートUEでビデオ会議アプリケーションを動作するように構成される。
【0074】
図8のフローチャートに示される別の例は、対話型ズーム機能をサポートするローカルユーザ装置(UE)にてビデオ会議アプリケーションを動作するために具現化された複数の命令をそれに有する少なくとも1つの非一時的機械可読記憶媒体の機能800を提供する。複数の命令が実行される場合、ブロック810のように、ローカルUEの少なくとも1つのプロセッサを使用して、ローカルUEに、リモートUEのカメラの視野内のユーザ規定の関心領域(ROI)を特定する工程をローカルUEに実行させることができる。複数の命令が実行される場合、ブロック820のように、ローカルUEの少なくとも1つのプロセッサを使用して、ROIを1または複数のパン・チルト・ズーム・フォーカス(PTZF)コマンドにマッピングする工程をローカルUEに実行させることができる。複数の命令が実行される場合、ブロック830のように、ローカルUEの少なくとも1つのプロセッサを使用して、ローカルUEからリモートUEへ1または複数のPTZFコマンドを送信する工程をローカルUEに実行させ得、リモートUEは、1または複数のPTZFコマンドに基づきROIを特定するように構成される。複数の命令が実行される場合、ブロック840のように、ローカルUEの少なくとも1つのプロセッサを使用して、リモートUEからROI内の符号化ビデオを受信する工程をローカルUEに実行させ得、符号化ビデオはROI内の領域を含み、ROI外の領域を除き、符号化ビデオは、規定された品質レベルを実質的に維持しつつ、増大されたズームレベルでROI内の複数の領域を含む。複数の命令が実行される場合、ブロック850のように、ローカルUEの少なくとも1つのプロセッサを使用して、ローカルUEでのレンダリングおよび表示のためにROI内の符号化ビデオを提供する工程をローカルUEに実行させることができる。
【0075】
1つの例において、1または複数のPTZFコマンドは、国際電気通信連合(ITU)H.281/H.224プロトコルに基づく。別の例において、少なくとも1つの非一時的機械可読記憶装置はさらに、ローカルUEの少なくとも1つのプロセッサによって実行される場合、1または複数のPTZFコマンドをローカルUEへ単一伝送で送信する工程をリモートUEに実行させる複数の命令を含むことができる。さらに別の例において、少なくとも1つの非一時的機械可読記憶装置はさらに、ローカルUEの少なくとも1つのプロセッサによって実行される場合、リアルタイムトランスポート制御プロトコル(RTCP)フィードバックメッセージを使用して、1または複数のPTZFコマンドをリモートUEへ送信する工程をローカルUEに実行させる複数の命令を含むことができる。
【0076】
1つの例において、少なくとも1つの非一時的機械可読記憶装置はさらに、ローカルUEの少なくとも1つのプロセッサによって実行される場合、少なくとも1つのリアルタイムトランスポートプロトコル(RTP)ヘッダ拡張に1または複数のPTZFコマンドを埋め込む工程と、キャプチャされたローカルビデオをリモートUEへ送信する工程とをローカルUEに実行させる複数の命令を含むことができ、キャプチャされたローカルビデオは、1または複数のPTZFコマンドを有するRTPヘッダ拡張を含む。別の例において、少なくとも1つの非一時的機械可読記憶装置はさらに、ローカルUEの少なくとも1つのプロセッサによって実行される場合、ローカルUEから送信された1または複数のPTZFコマンドを処理するべくリモートUEにて使用される、リモートUEからの1または複数のステップサイズを受信する工程をローカルUEに実行させる複数の命令を含むことができ、1または複数のステップサイズは、専用リアルタイムトランスポートプロトコル(RTP)ヘッダ拡張属性としてシグナリングされる。また、1または複数のPTZFコマンドは、遠端カメラ制御(FECC)プロトコルに従ってリモートUEに送信される。
【0077】
別の例は、
図9のフローチャートに示されるように、リモートUE950とビデオ会議を実行するように動作可能なローカルユーザ装置(UE)900の機能を提供する。ローカルUE900は、リモートUE950のカメラの視野内に、ユーザ規定のROIを特定するように構成される関心領域(ROI)モジュール910を含むことができる。ローカルUE900は、ROIを1または複数のパン・チルト・ズーム・フォーカス(PTZF)コマンドにマッピングするように構成されるマッピングモジュール920を含むことができ、1または複数のPTZFコマンドが国際電気通信連合(ITU)H.281/H.224プロトコルに基づき規定される。ローカルUE900は、1または複数のPTZFコマンドをローカルUEからリモートUE950へ単一伝送にて送信し、リモートUEは1または複数のPTZFコマンドに基づきROIを特定するように構成され、ROI内の符号化ビデオをリモートUEから受信するように構成される通信モジュール930を含むことができ、符号化ビデオはROI内の領域を含み、ROI外の領域を除き、符号化ビデオは、規定された品質レベルを実質的に維持しつつ、増大されたズームレベルでROI内の複数の領域を含む。ローカルUE900は、ローカルUEでのレンダリングおよび表示のためにROI内の符号化ビデオを提供するように構成されるディスプレイモジュール940を含むことができる。
【0078】
1つの例において、通信モジュール930はさらに、リモートUEが1または複数のPTZFコマンドを受信するための強化型遠端カメラ制御(FECC)プロトコルをサポートすることを示すリモートUE950からのセッション記述プロトコル(SDP)提供メッセージを受信し、ローカルUEが1または複数のPTZFコマンドを送信するための強化型遠端カメラ制御(FECC)プロトコルをサポートすることを確認するセッション記述プロトコル(SDP)応答メッセージを送信するように構成され得る。
【0079】
1つの例において、通信モジュール930はさらに、1または複数のPTZFコマンドをリモートUE950に送信するように構成され得、リモートUEは、1または複数のPTZFコマンドに対応し、ROI内のビデオを符号化するだけのROI内のビデオをキャプチャするように構成される。別の例において、通信モジュール930はさらに、リアルタイムトランスポート制御プロトコル(RTCP)フィードバックメッセージを使用して、1または複数のPTZFコマンドをリモートUEに送信するように構成され得る。
【0080】
別の例は、
図10のフローチャートに示されるように、ローカルUEとビデオ会議を実行するように動作可能なリモートユーザ装置(UE)の機能1000を提供する。機能は、方法として実施され得、または、機能は、機械上で複数の命令として実行され得る。ここで、複数の命令は、少なくとも1つのコンピュータ可読媒体または1つの非一時的機械可読記憶媒体に含まれる。リモートUEは、ブロック1010のように、1または複数のパン・チルト・ズーム・フォーカス(PTZF)コマンドをローカルUEから受信するように構成される1または複数のプロセッサを有することができる。1または複数のプロセッサは、ブロック1020のように、リモートUEにて、1または複数のPTZFコマンドに基づく関心領域(ROI)を特定するように構成され得、ROIはリモートUEのカメラの視野内に存在する。1または複数のプロセッサは、ブロック1030のように、ROI内の符号化ビデオを生成するように構成され得、符号化ビデオはROI内の複数の領域を含み、ROI外の領域を除き、符号化ビデオは、規定された品質レベルを実質的に維持しつつ、増大されたズームレベルでROI内の複数の領域を含む。1または複数のプロセッサは、ブロック1040のように、ローカルUEがROI内の符号化ビデオをレンダリングおよび表示するのを可能にするべく、ROI内の符号化ビデオをローカルUEへ送信するように構成され得る。
【0081】
1つの構成において、第1プロセッサは、ブロック1010、1020および1030の複数の工程を実行することができる。第1プロセッサは、単一プロセッサであり得、または、代わりに、第1プロセッサは、1または複数の別個のプロセッサから成り得る。1つの構成において、第2プロセッサは、ブロック1040の工程を実行することができる。第2プロセッサの1つの例は、ベースバンドプロセッサである。
【0082】
1つの例において、1または複数のPTZFコマンドは、国際電気通信連合(ITU)H.281/H.224プロトコルに基づく。別の例において、1または複数のプロセッサは、1または複数のPTZFコマンドを単一伝送にてローカルUEから受信するように構成される。さらに別の例において、1または複数のプロセッサは、リアルタイムトランスポート制御プロトコル(RTCP)フィードバックメッセージを使用して、1または複数のPTZFコマンドをローカルUEから受信するように構成される。また、1または複数のプロセッサはさらに、1または複数のステップサイズをローカルUEへ送信するように構成され、ステップサイズは、1または複数のPTZFコマンドを処理するべくリモートUEで使用され、1または複数のステップサイズは、複数の専用リアルタイムトランスポートプロトコル(RTP)ヘッダ拡張属性としてシグナリングされる。
【0083】
図11は、ユーザ装置(UE)、移動局(MS)、移動無線デバイス、移動無線通信デバイス、移動体通信デバイス、タブレット、ハンドセット、または他のタイプの無線デバイスなどの無線デバイスの例示的な説明を提供する。無線デバイスは、基地局(BS)、進化型Node B(eNB)、ベースバンドユニット(BBU)、リモート無線ヘッド(RRH)、リモート無線装置(RRE)、中継局(RS)、無線装置(RE)、リモート無線ユニット(RRU)、セントラルプロセッシングモジュール(CPM)、または他のタイプのワイヤレスワイドエリアネットワーク(WWAN)アクセスポイントなどノード、または送信局と通信を行うよう構成された1または複数のアンテナを含み得る。ワイヤレスデバイスは、3GPP LTE、WiMAX、高速パケットアクセス(HSPA)、ブルートゥース(登録商標)、およびWiFiを含む、少なくとも1つのワイヤレス通信規格を使用して、通信するように構成することが可能である。無線デバイスは、各無線通信規格用の別個のアンテナを使用して、または、複数の無線通信規格用の共有アンテナを使用して通信できる。無線デバイスは、無線ローカルエリアネットワーク(WLAN)、無線パーソナルエリアネットワーク(WPAN)、および/または、WWANで通信できる。
【0084】
図11はまた、無線デバイスからのオーディオ入出力のために使用され得るマイクおよび1または複数のスピーカの説明を提供する。ディスプレイスクリーンは、液晶ディスプレイ(LCD)スクリーン、または有機発光ダイオード(OLED)ディスプレイなどの他のタイプのディスプレイスクリーンであり得る。ディスプレイスクリーンは、タッチスクリーンとして構成され得る。タッチスクリーンは、容量、抵抗、または別のタイプのタッチスクリーン技術を使用することができる。アプリケーションプロセッサおよびグラフィックプロセッサは、処理能力および表示能力を提供するために、内部メモリと結合され得る。不揮発性メモリポートはまた、データ入力/データ出力の選択肢をユーザに提供するべく使用され得る。不揮発性メモリポートはまた、無線デバイスのメモリ能力を拡張するべく使用され得る。キーボードは、追加のユーザ入力を提供するべく、無線デバイスと統合され得る、または、無線デバイスと無線で接続され得る。また、タッチスクリーンを使用して仮想キーボードが提供され得る。
【0085】
様々な技術、または、それらの特定の態様あるいは一部は、有形の媒体で具現化されるプログラムコード(すなわち、命令)の形態を取ることができる。有形の媒体としては、フロッピー(登録商標)ディスケット、コンパクトディスクリードオンリーメモリ(CD-ROM)、ハードドライブ、非一時的コンピュータ可読記憶媒体または任意の他の機械可読記憶媒体が挙げられる。プログラムコードがコンピュータ等の機械へとロードされてそれによって実行される場合、当該機械は様々な技術を実施する装置となる。回路は、ハードウェア、ファームウェア、プログラムコード、実行可能なコード、コンピュータ命令、および/またはソフトウェアを含み得る。非一時的コンピュータ可読記憶媒体は、信号を含まないコンピュータ可読記憶媒体であり得る。プログラミング可能なコンピュータ上のプログラムコード実行の場合、コンピューティングデバイスは、プロセッサ、プロセッサ可読記憶媒体(揮発性および不揮発性メモリ、および/または記憶素子を含む)、少なくとも1つの入力デバイス、および少なくとも1つの出力デバイスを含み得る。揮発性および不揮発性メモリおよび/または記憶素子は、ランダムアクセスメモリ(RAM)、消去可能プログラミング可能なリードオンリーメモリ(EPROM)、フラッシュドライブ、光ドライブ、磁気ハードドライブ、ソリッドステートドライブ、または、電子データを格納する他の媒体であってよい。ノードおよび無線デバイスはまた、送受信機モジュール(すなわち、送受信機)、カウンタモジュール(すなわち、カウンタ)、プロセッシングモジュール(すなわち、プロセッサ)、および/または、クロックモジュール(すなわち、クロック)あるいはタイマモジュール(すなわち、タイマ)を含むことができる。本明細書に説明される様々な技術を実施または利用し得る1または複数のプログラムは、アプリケーションプログラミングインタフェース(API)、再利用可能な制御などを使用し得る。複数のそのようなプログラムは、コンピュータシステムと通信するべく、高水準手続型またはオブジェクト指向型のプログラミング言語で実装され得る。しかし、所望であれば、プログラムは、アセンブリ言語または機械言語で実装され得る。いずれの場合も、言語はコンパイラ型言語またはインタプリタ型言語であり得、ハードウェア実装と組み合わせられ得る。
【0086】
本明細書にて使用されるように、用語のプロセッサは、汎用プロセッサ、特殊プロセッサ、たとえばVLSI、FPGAまたは複数の他のタイプの特殊プロセッサ、ならびに無線通信を送信、受信および処理する送受信機に使用されるベースバンドプロセッサを含むことができる。
【0087】
本明細書において説明される複数の機能ユニットの多くは、それらの実装の独立性をより具体的に強調すべくモジュールとして示されていることを理解されるべきである。例えば、モジュールは、カスタマイズされた超大規模集積(VLSI)回路あるいはゲートアレイ、ロジックチップ、トランジスタまたはその他の別個の構成要素等の市販の半導体素子を備えるハードウェア回路として実施され得る。モジュールはまた、複数のプログラミング可能なハードウェアデバイス、たとえば、フィールドプログラミング可能なゲートアレイ、プログラミング可能なアレイロジック、プログラミング可能なロジックデバイス等で実施され得る。
【0088】
1つの例において、複数のハードウェア回路または複数のプロセッサが、本明細書に説明される複数の機能ユニットを実装するのに使用され得る。例えば、第1ハードウェア回路または第1プロセッサは、処理工程を実行するべく使用され得、第2ハードウェア回路または第2プロセッサ(例えば、送受信機)は、複数の他のエンティティと通信するべく使用され得る。第1ハードウェア回路および第2ハードウェア回路は単一ハードウェア回路へと統合され得、または、代わりに、第1ハードウェア回路および第2ハードウェア回路は、別個のハードウェア回路であり得る。
【0089】
モジュールはまた、様々なタイプのプロセッサにより実行されるソフトウェアを使って実装され得る。実行可能なコードの識別されたモジュールは、例えば、複数のコンピュータ命令からなる1または複数の物理ブロックあるいは論理ブロックを含み得る。これらのブロックは例えば、オブジェクト、手順、または機能として構成され得る。それでもなお、特定のモジュールの複数の実行ファイルは、物理的に共に配置される必要はなく、複数の異なる位置に格納されている複数の別個の命令を備えることができる。これらの命令は、論理的に一緒に集められる場合、モジュールを構成し、当該モジュールに対して記述された目的を実現する。
【0090】
実際に、実行可能なコードのモジュールは単一の命令または多くの命令であり得、複数の異なるプログラムの中の数個の異なるコードセグメント上、およびいくつかのメモリデバイスにわたり分配され得る。同様に、演算データは複数のモジュール内で識別されて本明細書に示され得、任意の適切な形態で具現化され、任意の適切なタイプのデータ構造内に構成され得る。演算データは、単一データセットとして収集され得、または異なる記憶デバイス以上を含む異なる位置にわたり分配され得、システムまたはネットワーク上に単に電子信号として、少なくとも部分的に存在し得る。モジュールは、受動型または能動型であり得、所望の機能を実行するよう動作可能なエージェントを含む。
【0091】
本明細書を通した「例」または「例示的」についての言及は、例に関連して説明される特定の特徴、構造または特性が、本発明の少なくとも1つの実施形態に含まれることを意味する。従って、本明細書を通した「例において」なる表現または「例示的」なる単語が様々な場所に現れるが、必ずしも全てが同じ実施形態を指すものではない。
【0092】
本明細書に使用されるとき、複数のアイテム、構造要素、構成要素、および/または材料は便宜上、共通のリストに提示され得る。しかしながら、これらのリストは、リストの各部材が別個の固有の部材として個別に識別されるように解釈されるべきである。従って、そのようなリストの個別の部材は、共通のグループにおけるそれらの表示のみに基づいて、相反する指示のない限り、同じリストの任意の他の部材の事実上の均等物と解釈されるべきではない。また、本発明の様々な実施形態および例が、それらの様々な構成要素の代替例と共に本明細書に言及され得る。このような実施形態、例および代替例は、互いの事実上の均等物と解釈されるべきではなく、別個かつ自立した本発明の説明と解釈されるべきと理解されたい。
【0093】
さらに、説明された複数の特徴、構造、または特性は、1または複数の実施形態において、任意の適切な態様で組み合わせられ得る。以下の説明において、本発明の実施形態の深い理解を提供すべく、レイアウトの複数の例、複数の距離、ネットワークの複数の例など多数の具体的な詳細が提供される。しかしながら、当業者は、それら具体的な詳細のうち1または複数を用いなくとも、または、複数の他の方法、構成要素、レイアウトなどを用いて、本発明は実施され得ることを認めるだろう。他の例において、周知の構造、材料または動作は、本発明の態様の不明瞭化を回避するべく、詳細に示されないか、説明されていない。
【0094】
前述された複数の例は、1または複数の特定の用途における本発明の原理を例示するものであるが、発明力を発揮することなく、かつ、発明の原理および概念から逸脱することなく、実装の形態、使用法および詳細にて多数の修正がなされ得ることは、当業者にとって明らかであろう。従って、以下に記載する請求項以外で、本発明は限定されることを意図されるものではない。