JP5933006B2

JP5933006B2 - データストリームの終結を示し、ユーザコンテキストを更新するための帯域内シグナリング

Info

Publication number: JP5933006B2
Application number: JP2014527360A
Authority: JP
Inventors: マーク・エー・リンドナー
Original assignee: クアルコム，インコーポレイテッド
Priority date: 2012-08-23
Filing date: 2012-08-28
Publication date: 2016-06-08
Anticipated expiration: 2032-08-28
Also published as: KR20140084001A; KR101651025B1; JP2014529957A; CN103875261B; CN103875261A

Description

米国特許法第119条に基づく優先権の主張
本特許出願は、本出願の譲受人に譲渡され、参照により明白に本明細書に組み込まれる、2011年8月26日に出願された「IN-BAND SIGNALING TO INDICATE END OF DATA STREAM AND UPDATE USER CONTEXT」という名称の仮出願第61/527,968号の優先権を主張する。

本発明の実施形態は、リアルタイムまたはほぼリアルタイムであるユーザコンテキスト更新のために着信データストリームの終結を示すための帯域内シグナリングに関する。

ワイヤレス通信システムは、第1世代アナログワイヤレス電話サービス(1G)、第2世代(2G)デジタルワイヤレス電話サービス(暫定の2.5Gおよび2.75Gネットワークを含む)、ならびに第3世代(3G)高速データ/インターネット対応ワイヤレスサービスを含む、様々な世代を通じて発展してきた。現在、セルラーシステムおよびパーソナル通信サービス(PCS)システムを含む、多くの様々なタイプのワイヤレス通信システムが使用されている。知られているセルラーシステムの例には、セルラーAnalog Advanced Mobile Phone System(AMPS)、および、符号分割多元接続(CDMA)、周波数分割多元接続(FDMA)、時分割多元接続(TDMA)、TDMAのGlobal System for Mobile接続(GSM(登録商標))変形に基づくデジタルセルラーシステム、および、TDMA技術とCDMA技術の両方を使用するより新しいハイブリッドデジタル通信システムがある。

CDMAモバイル通信を提供するための方法は、本明細書ではIS-95と呼ぶ、「Mobile Station-Base Station Compatibility Standard for Dual-Mode Wideband Spread Spectrum Cellular System」と題するTIA/EIA/IS-95-Aにおいて、米国電気通信工業会/米国電子工業会によって米国で規格化された。複合AMPS&CDMAシステムは、TIA/EIA規格IS-98に記載されている。他の通信システムは、広帯域CDMA(WCDMA(登録商標))、CDMA2000(たとえばCDMA2000 1xEV-DO標準など)またはTD-SCDMAと呼ばれるものを対象とする、IMT-2000/UM、すなわちInternational Mobile Telecommunications System 2000/Universal Mobile Telecommunications System規格に記載されている。

WCDMA(登録商標)ワイヤレス通信システムにおいて、ユーザ機器(UE)は、基地局に隣接するか、または基地局を囲む特定の地理的領域内の通信リンクまたはサービスをサポートする固定位置のノードB(セルサイトまたはセルとも呼ばれる)から信号を受信する。ノードBは、一般にサービス品質(QoS)要求に基づいてトラフィックを区別するための方法をサポートする標準Internet Engineering Task Force(IETF)ベースのプロトコルを使用したパケットデータネットワークであるアクセスネットワーク(AN)/無線アクセスネットワーク(RAN)にエントリポイントを提供する。したがって、ノードBは、一般に、エアインターフェースを介してUEと、またインターネットプロトコル(IP)ネットワークデータパケットを介してRANと対話する。

ワイヤレス電気通信システムでは、プッシュツートーク(PTT)機能がサービスセクタおよび消費者に普及している。PTTは、たとえばWCDMA(登録商標)、CDMA、FDMA、TDMA、GSM(登録商標)など、標準的な商用のワイヤレスインフラストラクチャ上で動作する「ディスパッチ」ボイスサービスをサポートすることができる。ディスパッチモデルでは、エンドポイント(たとえば、UE)間の通信が仮想グループ内で行われ、そこでは1人の「送話者(talker)」のボイスが1人または複数の「受話者(listener)」に送信される。このタイプの通信の単一のインスタンスは、通常、ディスパッチ呼(dispatch call)、または単にPTT呼と呼ばれる。PTT呼は、呼の特徴を定義するグループのインスタンス化である。グループは、本質的に、メンバーリスト、およびたとえばグループ名またはグループ識別情報などの関連する情報によって定義される。

1つまたは複数の着信データ(たとえば、オーディオ、ビデオなど)ストリームを受信中であるアプリケーションは、データストリームが終結したとき、ユーザコンテキストを更新する必要がある。いくつかのアプリケーションは、ユーザコンテキスト更新に対してリアルタイム(たとえば、最小待ち時間)要件を有する場合があり、したがって、これらのアプリケーションは、データストリームがいつ終結するかに関して、正確に瞬時に知る必要がある。従来、データストリームの終結は、ある程度の期間のトラフィック非アクティビティの後に推論することができ、または帯域外シグナリングの使用により(たとえば、「END」信号により)明示的に示すことができた。概して、帯域外シグナリングは、遅れる場合があり、実装するのが複雑な場合がある。また、データストリームの終結を示すために帯域外シグナリングに依拠すると、「END」信号があまりにも早く、またはあまりにも遅く到着する時間間隙が残る場合があり、その結果、ストリームが短く切り捨てられ(たとえば、「END」信号が早く到着した場合)、またはストリームを不足モードで継続させる(たとえば、RTPパケットが到着しなくなり、ユーザコンテキスト更新が行われないような、「END」信号が遅く到着した場合)可能性がある。

さらに、非アクティビティタイマの使用は、データストリームに関連付けられたストリーミングパケットが、閾値期間だけ受信されなかった後の、ユーザコンテキストの更新を伴う。非アクティビティタイマは、一時的なネットワーク途絶ならびに実際のストリーム終了に対応しなければならず、単一タイマ値は、両方のシナリオにとって適切でない可能性があるので、非アクティビティタイマに基づいてセッションの終結を推論するのは、困難な場合がある。

本開示の実施形態は、帯域内シグナリングを使ってデータストリームの終結を示すことに関する。ある実施形態は、データストリームを送信し、データストリームは複数のパケットを含み、複数のパケットの各パケットは、マーカビットフィールドおよびペイロードをもつヘッダを含み、またこの実施形態は、複数のパケットのうちの少なくとも1つのパケットのマーカビットフィールドおよび/またはペイロードを、データストリームの終結を示すように構成し、ペイロードを構成することは、ペイロードに含まれるデータの量を複数のパケットのうちの他のパケットのペイロードから削減すること、および/またはデータストリームの最終パケットまでのカウントダウンを示すペイロード中のフィールドを設定することを含む。

本開示の実施形態は、帯域内シグナリングを使ってデータストリームの終結を検出することに関する。ある実施形態は、データストリームを受信し、データストリームは複数のパケットを含み、複数のパケットの各パケットは、マーカビットフィールドおよびペイロードをもつヘッダを含み、実施形態は、複数のパケットのうちの少なくとも1つのパケットが、データストリームの終結を示すように構成されていることを検出し、検出することは、少なくとも1つのパケットのマーカビットフィールドが、データストリームの終結を示すように構成されていること、少なくとも1つのパケットのペイロードが、複数のパケットのうちの他のパケットのペイロード未満のデータ量を含むこと、および/または少なくとも1つのパケットのペイロードが、データストリームの最終パケットまでのカウントダウンを示すフィールドを含むことを検出することを含む。

説明する方法および装置の適用性のさらなる範囲は、以下の詳細な説明、請求項および図面から明らかとなろう。詳細な説明および具体的な例は、本開示の具体的な例および請求項を示しているが、説明の趣旨および範囲の中にある様々な変更および修正が当業者に明らかになると思われるため、例示として与えられるものにすぎない。

本発明の実施形態およびその付随する利点の多くのより完全な理解は、以下の詳細な説明を参照し、本発明を限定するためではなく単に例示するために提示する添付の図面とともに考察することによってよりよく理解されれば、容易に得られるであろう。

本発明の少なくとも1つの実施形態による、アクセス端末とアクセスネットワークとをサポートするワイヤレスネットワークアーキテクチャの図である。本発明の一実施形態による図1のコアネットワークを示す図である。本発明の別の実施形態による図1のコアネットワークを示す図である。図1のワイヤレス通信システムの一例をより詳細に示す図である。本発明の少なくとも1つの実施形態によるアクセス端末の図である。本発明の少なくとも1つの実施形態による、着信データストリームの終結を示すための帯域内シグナリングの図である。着信データストリームの終結を示すための従来の帯域外シグナリングの図である。本発明の少なくとも1つの実施形態による、2つの着信ストリームを用いる帯域内シグナリングの例を示す図である。マーカビットを検出するサーバを用いた帯域内シグナリングの例を示す図である。マーカビットを検出するサーバを用いた帯域内シグナリングの例を示す図である。メディア/フロア解放の終結が検出されたとき、サーバにおいて帯域内シグナリングを生成する例を示す図である。機能性を実施するように構成された論理を含む通信デバイスを示す図である。

本発明の態様は、以下の説明および特定の実施形態を対象とする関連する図面において、開示される。本発明の範囲から逸脱することなく代替的な実施形態を考案することができる。さらに、実施形態の関連する詳細を不明瞭にしないように、実施形態のよく知られている要素については詳細に説明しないか、または省略する。

「例示的」および/または「例」という用語は、本明細書では「例、事例、または例示として機能すること」を意味するために使用される。本明細書で「例示的」および/または「例」として説明するいかなる実施形態も、必ずしも他の実施形態よりも好ましいまたは有利であると解釈されるべきではない。同様に、「本発明の実施形態」という用語は、すべての実施形態が、論じられた特徴、利点または動作モードを含むことを必要としない。

さらに、多くの実施形態が、たとえばコンピューティングデバイスの要素によって実施すべき、一連のアクションに関して説明される。本明細書で説明する様々なアクションは、特定の回路(たとえば、特定用途向け集積回路(ASIC))によって、1つまたは複数のプロセッサによって実行されるプログラム命令によって、あるいは両方の組合せによって実行され得ることを認識されよう。さらに、本明細書で説明するこれらの一連のアクションは、実行時に、関連するプロセッサに本明細書で説明する機能性を実施させるコンピュータ命令の対応するセットを記憶した、任意の形式のコンピュータ可読記憶媒体内で全体として具現化されるものと見なすことができる。したがって、本実施形態の様々な態様は、すべてが請求する主題の範囲内に入ることが企図されているいくつかの異なる形式で実施され得る。さらに、本明細書で説明する実施形態ごとに、そのような任意の実施形態の対応する形式を、たとえば、記載の動作を実施する「ように構成された論理」として本明細書で説明することがある。

本明細書ではユーザ機器(UE)と呼ばれる高データレート(HDR)加入者局は、モバイルでも固定でもよく、ノードBと呼ばれ得る1つまたは複数のアクセスポイント(AP)と通信することができる。UEは、ノードBのうちの1つまたは複数を介して、無線ネットワークコントローラ(RNC)との間でデータパケットを送受信する。ノードBおよびRNCは、無線アクセスネットワーク(RAN)と呼ばれるネットワークの部分である。無線アクセスネットワークは、複数のアクセス端末間でボイスパケットおよびデータパケットをトランスポートすることができる。

無線アクセスネットワークは、無線アクセスネットワークの外部の追加のネットワークにさらに接続されていてもよく、そのようなコアネットワークは、特定のキャリア関連のサーバおよびデバイス、ならびに企業内イントラネット、インターネット、公衆交換電話網(PSTN)、サービング汎用パケット無線サービス(GPRS)サポートノード(SGSN)、ゲートウェイGPRSサポートノード(GGSN)など他のネットワークへの接続を含んでおり、各UEとそのようなネットワークとの間でボイスパケットおよびデータパケットをトランスポートすることができる。1つまたは複数のノードBとのアクティブなトラフィックチャネル接続を確立したUEは、アクティブなUEと呼ぶことができ、トラフィック状態であると呼ぶことができる。1つまたは複数のノードBとのアクティブなトラフィックチャネル(TCH)接続を確立する過程にあるUEは、接続セットアップ状態であると呼ぶことができる。UEは、ワイヤレスチャネルまたはワイヤードチャネルを介して通信する任意のデータデバイスであり得る。UEは、さらに、限定はしないが、PCカード、コンパクトフラッシュ(登録商標)デバイス、外付けまたは内蔵のモデム、またはワイヤレスもしくは有線の電話を含むいくつかのタイプのデバイスのうちのいずれであってもよい。UEが信号をノードBに送る通信リンクは、アップリンクチャネル(たとえば、逆方向トラフィックチャネル、制御チャネル、アクセスチャネルなど)と呼ばれる。ノードBが信号をUEに送る通信リンクは、ダウンリンクチャネル(たとえば、ページングチャネル、制御チャネル、ブロードキャストチャネル、順方向トラフィックチャネルなど)と呼ばれる。本明細書で使用する場合、トラフィックチャネル(TCH)という用語は、アップリンク/逆方向トラフィックチャネル、またはダウンリンク/順方向トラフィックチャネルのいずれかを指し得る。

図1は、少なくとも1つの実施形態によるワイヤレス通信システム100の例示的な一実施形態のブロック図を示す。システム100は、パケット交換データネットワーク(たとえばイントラネット、インターネット、および/またはコアネットワーク126)とUE102、108、110、112との間にデータ接続を提供するネットワーク機器にアクセス端末102を接続することができるアクセスネットワークまたは無線アクセスネットワーク(RAN)120と、エアインターフェース104を介して通信しているセルラー電話102などのUEを含むことができる。本明細書に示すように、UEは、セルラー電話102、携帯情報端末108、本明細書では双方向テキストページャとして示すページャ110、さらにはワイヤレス通信ポータルを有する個別のコンピュータプラットフォーム112とすることができる。したがって、様々な実施形態は、それだけには限定されないが、ワイヤレスモデム、PCMCIAカード、パーソナルコンピュータ、電話、またはそれらの任意の組合せまたは部分的組合せを含めて、ワイヤレス通信ポータルを含む、またはワイヤレス通信機能を有する任意の形態のアクセス端末において実現することができる。さらに、本明細書で使用するように、他の通信プロトコル(すなわちWCDMA(登録商標)以外)における「UE」という用語は、互換的に「アクセス端末」、「AT」、「ワイヤレスデバイス」、「クライアントデバイス」、「モバイル端末」、「移動局」、およびそれらの変形と呼ばれ得る。

再び図1を参照すると、ワイヤレス通信システム100の構成要素、および本例示的な実施形態の要素の相互関係は、図示の構成に限定されない。システム100は、例にすぎず、ワイヤレスクライアントコンピューティングデバイス102、108、110、112などのリモートUEが、無線で互いの間で、および/またはそれだけには限定されないが、コアネットワーク126、インターネット、PSTN、SGSN、GGSN、および/または他のリモートサーバを含めて、エアインターフェース104およびRAN120を介して接続される構成要素の間で通信することができる任意のシステムを含むことができる。

RAN120は、RNC122に送られる(一般的にデータパケットとして送られる)メッセージを制御する。RNC122は、サービング汎用パケット無線サービス(GPRS)サポートノード(SGSN)とUE102/108/110/112との間のベアラチャネル(すなわち、データチャネル)のシグナリング、確立、およびティアダウンを行う役目を果たす。また、リンクレイヤ暗号化が可能な場合、RNC122は、エアインターフェース104を介してコンテンツをフォワードする前に、コンテンツを暗号化する。RNC122の機能は、当技術分野でよく知られており、簡潔のためにこれ以上は説明しない。コアネットワーク126は、ネットワーク、インターネット、および/または公衆交換電話網(PSTN)によってRNC122と通信することができる。代わりに、RNC122は、インターネットまたは外部ネットワークに直接接続することができる。一般的に、コアネットワーク126とRNC122との間のネットワークまたはインターネット接続は、データを転送し、PSTNは、ボイス情報を転送する。RNC122は、複数のノードB124に接続することができる。コアネットワーク126と同様の方法で、RNC122は、一般的に、データ転送および/またはボイス情報のために、ネットワーク、インターネット、および/またはPSTNによってノードB124に接続される。ノードB124は、データメッセージを、たとえばセルラー電話102などのUEにワイヤレスでブロードキャストすることができる。当技術分野で知られているように、ノードB124、RNC122、および他の構成要素は、RAN120を形成することができる。しかし、代替構成が使用されてもよく、様々な実施形態は、図示の構成に限定されない。たとえば、別の実施形態では、RNC122の機能性とノードB124のうちの1つまたは複数の機能性とが、RNC122とノードB124の両方の機能性を有する単一の「ハイブリッド」モジュールに縮小され得る。

図2Aは、一実施形態によるコアネットワーク126を示す。特に、図2Aは、WCDMA(登録商標)システム内に実装される汎用パケット無線サービス(GPRS)コアネットワークの構成要素を示す。図2Aの実施形態では、コアネットワーク126は、サービングGPRSサポートノード(SGSN)160、ゲートウェイGPRSサポートノード(GGSN)165、およびインターネット175を含む。しかし、代替実施形態では、インターネット175および/または他の構成要素の部分がコアネットワークの外部に配置されていてもよいことを諒解されたい。

一般に、GPRSは、インターネットプロトコル(IP)パケットを送信するために、Global System for Mobile communications(GSM(登録商標))電話によって使用されるプロトコルである。GPRSコアネットワーク(たとえば、GGSN165および1つまたは複数のSGSN160)は、GPRSシステムの中央部であり、WCDMA(登録商標)ベースの3Gネットワークのサポートも提供する。GPRSコアネットワークは、GSM(登録商標)コアネットワークの一体部であり、GSM(登録商標)およびWCDMA(登録商標)ネットワークにおけるIPパケットサービスのモビリティ管理、セッション管理、およびトランスポートを提供する。

GPRSトンネリングプロトコル(GTP)は、GPRSコアネットワークの限定的なIPプロトコルである。GTPは、GSM(登録商標)またはWCDMA(登録商標)ネットワークのエンドユーザ(たとえば、アクセス端末)が、GGSN165において、まるで1つの位置からインターネットに接続し続けながら、あちこちに移動することができるプロトコルである。これは、加入者の現在のSGSN160から、加入者のセッションを処理しているGGSN165に加入者のデータを転送することによって達成される。

GTPの3つの形態、すなわち(i)GTP-U、(ii)GTP-C、および(iii)GTP'(GTP Prime)がGPRSコアネットワークによって使用される。GTP-Uは、パケットデータプロトコル(PDP)コンテキストごとに分離されたトンネルでのユーザデータの転送に使用される。GTP-Cは、制御シグナリング(たとえば、PDPコンテキストのセットアップおよび削除、GSN到達可能性の検証、加入者があるSGSNから別のSGSNに移動したときなどの更新または変更)に使用される。GTP'は、GSNから課金機能への課金データの転送のために使用される。

図2Aを参照すると、GGSN165は、GPRSバックボーンネットワーク(図示せず)と外部パケットデータネットワーク175との間のインターフェースとして働く。GGSN165は、関連するパケットデータプロトコル(PDP)形式(たとえば、IPまたはPPP)のパケットデータを、SGSN160から来るGPRSパケットから抽出し、対応するパケットデータネットワーク上でパケットを送出する。反対方向において、着信データパケットは、GGSN165によってSGSN160に向けられ、SGSN160は、RAN120によってサービスされる宛先のUEの無線アクセスベアラ(RAB)を管理および制御する。それによって、GGSN165は、ターゲットUEの現在のSGSNアドレス、およびそのユーザのプロファイルをそのロケーションレジスタ(たとえば、PDPコンテキスト内)に記憶する。GGSNは、IPアドレス割当ての役目を果たし、接続されたUEのデフォルトルータである。また、GGSNは、認証および課金機能を実行する。

一例では、SGSN160は、コアネットワーク126内の多くのSGSNのうちの1つの代表である。各SGSNは、関連する地理的サービスエリア内で、UEとの間でデータパケットを配信する役目を果たす。SGSN160のタスクには、パケットルーティングおよび転送、モビリティ管理(たとえば、接続/切断およびロケーション管理)、論理リンク管理、ならびに認証および課金機能などがある。SGSNのロケーションレジスタは、位置情報(たとえば、現在のセル、現在のVLR)、および、SGSN160に登録されたすべてのGPRSユーザのユーザプロファイル(たとえば、パケットデータネットワークで使用するIMSI、PDPアドレス)を、たとえばユーザまたはUEごとに1つまたは複数のPDPコンテキスト内に記憶する。したがって、SGSNは、(i)GGSN165からのダウンリンクGTPパケットの逆トンネリング、(ii)GGSN165方向のIPパケットのアップリンクトンネル、(iii)UEがSGSNサービスエリアの間を移動するときのモビリティ管理の実行、(iv)モバイル加入者の支払い請求の役目を果たす。当業者なら諒解するように、(i)〜(iv)の他に、GSM/EDGEネットワークのために構成されたSGSNは、WCDMA(登録商標)ネットワークのために構成されたSGSNと比較して、わずかに異なる機能を有する。

RAN120(またはユニバーサルモバイル通信システム(UMTS)システムアーキテクチャにおけるUTRANなど)は、無線アクセスネットワークアプリケーションパート(RANAP)プロトコルにより、SGSN160と通信する。RANAPは、Iuインターフェース(Iu-ps)を介して、フレームリレーまたはIPなどの伝送プロトコルとともに動作する。SGSN160は、SGSN160および他のSGSN(図示せず)と内部のGGSNとの間のIPベースのインターフェースであり、上記で定義されたGTPプロトコル(たとえば、GTP-U、GTP-C、GTP'など)を使用するGnインターフェースを介してGGSN165と通信する。図2の実施形態において、SGSN160とGGSN165との間のGnは、GTP-CとGTP-Uの両方を搬送する。図2Aには示さないが、Gnインターフェースは、ドメインネームシステム(DNS)によっても使われる。GGSN165は、公衆データネットワーク(PDN)(図示せず)に、次にインターネット175に、IPプロトコルによるGiインターフェースを介して直接、またはワイヤレスアプリケーションプロトコル(WAP)ゲートウェイを介して接続される。

図2Bは、別の実施形態によるコアネットワーク126を示す。図2Bは、図2Bがダイレクトトンネル機能性の実装形態を示すことを除いて、図2Aと同様である。

ダイレクトトンネルは、SGSN160に、パケット交換(PS)ドメイン内のRANとGGSNとの間のダイレクトユーザプレーントンネルを確立させる、Iuモードにおける任意選択の機能である。ダイレクトトンネル可能SGSN、たとえば図2BのSGSN160は、SGSNがダイレクトユーザプレーン接続を使い得るかどうかにかかわらず、GGSN単位およびRNC単位で構成され得る。図2BのSGSN160は、制御プレーンシグナリングを処理し、ダイレクトトンネルをいつ確立するべきか決定を行う。PDPコンテキストに割り当てられた無線ベアラ(RAB)が解放される(すなわち、PDPコンテキストが保たれる)と、ダウンリンクパケットを処理することができるようにするために、GGSN165とSGSN160との間にGTP-Uトンネルが確立される。

SGSN160とGGSN165との間の任意選択のダイレクトトンネルは通常、(i)ローミングのケースにおいて(たとえば、SGSNは、GGSNが同じPLMNにあるか、それとも異なるPLMNにあるかを知る必要があるので)、(ii)SGSNが加入者プロファイル中のCustomized Applications for Mobile Enhanced Logic(CAMEL)加入情報をホームロケーションレジスタ(HLR)から受信済みである場合、および/または(iii)GGSN165がGTPプロトコルバージョン1をサポートしない場合は、許可されない。CAMEL制約に関して、ダイレクトトンネルが確立されている場合、SGSN160はユーザプレーンをもはや見ることができないので、SGSN160からのボリューム報告は可能ではない。したがって、CAMELサーバは、PDPコンテキストの存続期間中はいつでもボリューム報告を呼び出すことができるので、ダイレクトトンネルの使用は、CAMEL加入情報を含むプロファイルをもつ加入者に対して禁止される。

SGSN160は、パケット移動管理(PMM)切断状態、PMMアイドル状態またはPMM接続状態で動作中であり得る。ある例では、ダイレクトトンネル機能のための、図2Bに示すGTP接続を確立することができ、そうすることにより、SGSN160はPMM接続状態になり、UEからIu接続確立要求を受信する。SGSN160は、新たなIu接続と既存のIu接続が同じUE向けであるようにし、同じである場合、SGSN160は、新たな要求を処理し、既存のIu接続と、それに関連付けられたすべてのRABとを解放する。新たなIu接続と既存の接続が同じUE向けであるようにするために、SGSN160は、セキュリティ機能を実施すればよい。Iu接続確立要求がシグナリングのみについてであるケースでは、ダイレクトトンネルがUE用に確立された場合、SGSN160は、更新PDPコンテキスト要求を、関連付けられたGGSN165に送って、SGSN160とGGSN165との間のGTPトンネルを確立する。Iu接続確立要求がデータ転送についてであるケースでは、SGSN160は、直ちに新たなダイレクトトンネルを確立し、関連付けられたGGSN165に更新PDPコンテキスト要求を送り、ユーザプレーンについてのRNCのアドレス、データについてのダウンリンクトンネルエンドポイント識別子(TEID)を含めることができる。

UEがRRC接続解放メッセージを受信済みであるとき、UEは、PMMアイドル状態に入ると直ちに、ルーティングエリアが最終更新以来変化していない場合であっても、原因が「指示されたシグナリング接続再確立」であるルーティングエリア更新(RAU)手順も実施する。ある例では、RNCが、Iur接続の欠如により、UEを検証するためにサービングRNCに連絡することができないとき、RNCは、「指示されたシグナリング接続再確立」が原因であるRRC接続解放メッセージを送る(たとえば、TS 25.331 [52]参照)。UEがユーザデータを送るのを保留しているとき、UEは、RAU手順の完了成功の後、後に続くサービス要求手順を実施して、無線アクセスベアラを再確立する。

PDPコンテキストは、UEがアクティブなGPRSセッションを有するとき、特定のUEの通信セッション情報を含む、SGSN160とGGSN165の両方に存在するデータ構造である。UEは、GPRS通信セッションを開始することを望むとき、まず、SGSN160に接続し、次いで、GGSN165を用いてPDPコンテキストをアクティブ化しなければならない。これによって、加入者が現在訪問しているSGSN160、およびUEのアクセスポイントにサービスしているGGSN165において、PDPコンテキストデータ構造が割り振られる。

図2Cは、図1のワイヤレス通信システム100の一例をより詳細に示す。特に、図2Cを参照すると、UE1...Nは、異なるパケットデータネットワークのエンドポイントによってサービスされる位置でRAN120に接続するものとして示されている。図2Cの例は、WCDMA(登録商標)システムおよび用語に固有のものであるが、1xEV-DOシステムに適合するために図2Cをどのように変更することができるかが諒解されよう。したがって、UE1およびUE3は、第1のパケットデータネットワークエンドポイント162(たとえば、SGSN、GGSN、PDSN、ホームエージェント(HA)、外部エージェント(FA)などに対応し得る)によってサービスされる部分でRAN120に接続する。第1のパケットデータネットワークエンドポイント162は、次に、ルーティングユニット188を介して、インターネット175、ならびに/または認証、認可およびアカウンティング(AAA)サーバ182、プロビジョニングサーバ184、インターネットプロトコル(IP)マルチメディアサブシステム(IMS)/セッション開始プロトコル(SIP)登録サーバ186、および/もしくはアプリケーションサーバ170のうちの1つもしくは複数に接続する。UE2およびUE5...Nは、第2のパケットデータネットワークエンドポイント164(たとえば、SGSN、GGSN、PDSN、FA、HAなどに対応し得る)によってサービスされる部分でRAN120に接続する。第1のパケットデータネットワークエンドポイント162と同様に、第2のパケットデータネットワークエンドポイント164は、次に、ルーティングユニット188を介して、インターネット175、ならびに/またはAAAサーバ182、プロビジョニングサーバ184、IMS/SIP登録サーバ186、および/もしくはアプリケーションサーバ170のうちの1つもしくは複数に接続する。UE4は、直接インターネット175に接続し、次いでインターネット175を介して、上記のシステム構成要素のうちのいずれかに接続することができる。

図2Cを参照すると、UE1、UE3、およびUE5...Nは、ワイヤレス携帯電話として示され、UE2は、ワイヤレスタブレット型PCとして示され、UE4は、有線のデスクトップステーションとして示されている。しかしながら、他の実施形態では、ワイヤレス通信システム100は任意のタイプのUEに接続することができ、図2Cに示される例は、システム内に実装され得るUEのタイプを制限するものではないことが諒解されよう。また、AAA182、プロビジョニングサーバ184、IMS/SIP登録サーバ186、およびアプリケーションサーバ170はそれぞれ、構造的に別のサーバとして示されているが、少なくとも1つの実施形態において、これらのサーバのうちの1つまたは複数は、統合されていてもよい。

さらに、図2Cを参照すると、アプリケーションサーバ170は、複数のメディア制御コンプレックス(MCC)1...N170Bと複数の地域ディスパッチャ1...N170Aとを含むものとして示されている。集合的に、地域ディスパッチャ170AおよびMCC170Bは、少なくとも1つの実施形態では、ワイヤレス通信システム100内の通信セッション(たとえば、IPユニキャストプロトコルおよび/またはIPマルチキャストプロトコルを介した半二重グループ通信セッション)を調停するように集合的に機能するサーバの分散型ネットワークに対応し得る、アプリケーションサーバ170内に含まれる。たとえば、アプリケーションサーバ170によって調停される通信セッションは、理論上、システム100内のどこかに位置するUE間で行われ得るので、調停された通信セッションの待ち時間を減らすために(たとえば、北米のMCCが中国に位置するセッション参加者間で媒体をあちこち中継しないように)、複数の地域ディスパッチャ170AおよびMCCが分散される。したがって、アプリケーションサーバ170を参照すると、関連する機能性は、地域ディスパッチャ170Aのうちの1つもしくは複数、および/またはMCC170Bのうちの1つもしくは複数によって実施することができることを諒解されよう。地域ディスパッチャ170Aは、全般的に、通信セッションを確立することに関連する任意の機能性(たとえば、UE間のシグナリングメッセージの処理、告知メッセージのスケジューリングおよび/または送信など)を受け持ち、MCC170Bは、通話中シグナリング、調停された通信セッション中の媒体の実際の交換を行うことを含めて、呼インスタンスの間の通信セッションをホストする役目を果たす。

図3を参照すると、たとえばセルラー電話などのUE200(ここではワイヤレスデバイス)は、プラットフォーム202を有し、プラットフォーム202は、RAN120から送信され、最終的にはコアネットワーク126、インターネット、および/または他のリモートサーバおよびネットワークから来る可能性がある、ソフトウェアアプリケーション、データ、および/またはコマンドを受信し、実行することができる。プラットフォーム202は、特定用途向け集積回路(「ASIC」208)または他のプロセッサ、マイクロプロセッサ、論理回路、または他のデータ処理デバイスに動作可能に結合されたトランシーバ206を含むことができる。ASIC208または他のプロセッサは、ワイヤレスデバイスのメモリ212中の任意の常駐プログラムとインターフェースするアプリケーションプログラミングインターフェース(API)210レイヤを実行する。メモリ212は、読取り専用メモリまたはランダムアクセスメモリ(RAMおよびROM)、EEPROM、フラッシュカード、またはコンピュータプラットフォームに共通の任意のメモリから構成され得る。プラットフォーム202は、メモリ212中でアクティブに使用されないアプリケーションを保持することができるローカルデータベース214も含み得る。ローカルデータベース214は、一般にフラッシュメモリセルであるが、磁気媒体、EEPROM、光学媒体、テープ、ソフトまたはハードディスクなど、当技術分野で知られている任意の二次記憶デバイスであってもよい。内部プラットフォーム202の構成要素はまた、当技術分野で知られていているように、構成要素の中でもとりわけ、アンテナ222、ディスプレイ224、プッシュツートークボタン228およびキーパッド226のような外部デバイスに動作可能に結合され得る。

したがって、一実施形態は、本明細書で説明した機能を実施する能力を含むUEを含むことができる。当業者ならば諒解するように、様々な論理要素は、本明細書で開示する機能性を達成するために、個別の要素、プロセッサ上で実行されるソフトウェアモジュール、またはソフトウェアとハードウェアとの任意の組合せで実施できる。たとえば、ASIC208、メモリ212、API210およびローカルデータベース214をすべて協働的に使用して、本明細書で開示するような帯域内シグナリングアプリケーション250の様々な機能をロード、記憶および実行することができ、したがってこれらの機能を実施する論理を様々な要素に分散することができる。代替的に、機能性を1つの個別構成要素に組み込むことができる。したがって、図3のUE200の特徴は、単に例示にすぎないものと見なされ、様々な実施形態は、示された特徴または構成に限定されない。

UE102またはUE200とRAN120との間のワイヤレス通信は、たとえば符号分割多元接続(CDMA)、WCDMA(登録商標)、時分割多元接続(TDMA)、周波数分割多元接続(FDMA)、直交周波数分割多元(OFDM)、Global System for Mobile Communications(GSM(登録商標))、またはワイヤレス通信ネットワークもしくはデータ通信ネットワークで使用され得る他のプロトコルなど、異なる技術に基づき得る。たとえば、WCDMA(登録商標)では、データ通信は、一般的に、クライアントデバイス102、ノードB124、およびRNC122の間である。RNC122は、コアネットワーク126、PSTN、インターネット、仮想専用ネットワーク、SGSN、GGSNなど複数のデータネットワークに接続することができ、したがって、UE102またはUE200は、より広い通信ネットワークにアクセスすることができる。上記で説明し、当技術分野で知られているように、ボイス送信、および/またはデータは、様々なネットワークおよび構成を使用してRANからUEに送信することができる。したがって、本明細書で提供する例は、様々な実施形態を限定するためのものではなく、単に実施形態の態様の説明を助けるためのものにすぎない。

マルチメディアは、リアルタイムトランスポートプロトコル(RTP)を使うデータパケットにより、上記の通信ネットワークのうちのどれを介しても交換することができる。RTPは、一群のマルチメディアフォーマット(たとえばH.264、MPEG-4、MJPEG、MPEGなど)をサポートし、RTP規格を改訂することなく、新たなフォーマットが追加されることを認める。40オクテットのオーバーヘッドRTPパケットのヘッダ部分の例は、次のように構成され得る。

Table 1(表1)を参照すると、RTPパケットヘッダ部分の一般フィールドは、当該分野においてよく知られている。RTPヘッダ部分の後に、RTPパケットはデータペイロード部分を含む。データペイロード部分は、デジタル化されたボイスおよび/またはビデオのサンプルを含み得る。データペイロードの長さは、異なるRTPパケットに対して変わり得る。たとえば、ボイスRTPパケットでは、データペイロードによって搬送されるボイスサンプルの長さは、20ミリ秒(ms)の音に対応し得る。概して、より長いメディア継続時間(たとえば、より高いレートフレーム)に対して、データペイロードは、やはりより長くなければならず、さもなければメディアサンプルの品質が低下する。

概して、RTP送出機は、マルチメディアデータを(たとえば、RTP送出機のユーザから)キャプチャし、データは次いで、エンコードされ、フレーム化され、適切なタイムスタンプと増加するシーケンス番号とをもつRTPパケットとして送信される。RTP送出機によって送信されるRTPパケットは、RTP送出機と受信機との間のセッションを調停するサーバを介して、ターゲットRTPデバイス(またはRTP受信機)に、あるいはピアツーピア(P2P)プロトコルによりRTP送出機からRTP受信機に直接伝えることができる。RTP受信機は、RTPパケットを受信し、欠落パケットを検出し、パケットの並び替えを実施することができる。フレームは、ペイロードフォーマットに依存してデコードされ、RTP受信機のユーザに提示される。

図4は、ある実施形態による、RTPベースの通信を終了させるプロセスを示す。図4を参照すると、デバイスA401(たとえば、上述したUE200などのUE)は、オーディオデータのフレーム110〜113を含むフレームバッファ402にオーディオを記録中である。フレームバッファ402からのオーディオデータは、1つまたは複数のRTPパケットのペイロード(図4では、これらのフレームは、RTPパケット9用のペイロードの一部として示してある)にフォーマットされ、オーディオ送信(またはストリーム)中に送信される。オーディオ送信の終結時、デバイスA401のユーザは、オーディオ送信またはストリームの終結を肯定的に(たとえば、PTTボタンの解放403によって)示すことができる。この指示により、マーカビット(MB)404が、パケット9のリアルタイムトランスポートプロトコル(RTP)ヘッダ中に設定される。MB404は、よく知られているRTPヘッダフィールドであるが、従来、データストリームの終結を示すのには使われていない。実際、MB404は通常、ストリームまたはトークスパートの始端(終結ではなく)を示すのに使われる。さらに、パケット9は、目次(TOC)およびオーディオペイロード(フレーム110〜113)を含む。図示する例では、パケット9は、パケット7、8および9中の様々なフレーム中にストリーミングオーディオデータを含むパケットストリーム407の一部であることに留意されたい。この図示する例では、パケット7および8は各々、RTPヘッダ、TOCならびに6つのフレーム(それぞれ、フレーム98〜103およびフレーム104〜109)を有する。パケット9には、オーディオ送信が切り捨てられているので、4つのフレームしかない。ただし、ストリーム407中の最終パケットは、この例では、オーディオ送信の終結がどの任意の位置でも起こり得るので、0〜6つのフレームを有してもよい。さらに、様々な実施形態は、任意の数のフレームが使われ得るので、パケットごとに6つのフレームのバンドリングファクタに限定されないことが諒解されよう。オーディオ送信を含む最終パケット中のフレームの数にかかわらず、最終パケットは、オーディオ送信の終結を肯定的に示すためのマーカビットを、RTPヘッダ中に含む。また、MB404は、図4の実施形態では、データストリーム(またはオーディオ送信)の終結を示すために利用されているが、他の実施形態では、この目的のために他のRTPヘッダフィールドが利用されてもよいことが諒解されよう。

メディアストリーム407は、任意選択でサーバ(たとえば、アプリケーションサーバ170)を通り、ネットワークレベルでバッファリングおよび/または並び替えることができる。さらに、パス遅延、ルーティング問題、ネットワーク輻輳などにより、否定的な意味でのネットワーク並び替え420が起こり得る(たとえば、パケットを順不同にする)。ネットワーク並び替え420により、現実のストリーム終結がいつ起こるか判断するのが困難になる。様々な実施形態により、現実のストリーム終結をより検出しやすくなる。具体的には、順不同に配信されるマーカビットパケットは、デジッタ/並び替えバッファの一部として、自動的に「並び替えられ」、このことは、帯域外シグナリングでは容易に行うことができないことだが、送信された順序で出力/処理されることを意味する。

ただし、パケットがネットワークにおいてバッファリングおよび/または並び替えられるかどうかにかかわらず、ストリーム407は、デバイスB411においてデジッタバッファ408中で受信され、バッファリングされ、必要な場合は任意選択で並び替えられる。フレームは次いで、デバイスBにおいてプレイアウトされ、デバイスBは、デバイスAが通話中であり、PTTコンテキストにおいてフロアを有する状態409におかれる。その後、フレーム113が再生され、マーカビットがパケット9のRTPヘッダ中に設定されたので、デバイスBは、ストリームが終結したことを肯定的に通知される。デバイスBは次いで、フロアが現在オープン(たとえば、デバイスBまたは別のデバイスからのオーディオ送信に利用可能)であること410に直ちに気づくことができ、アプリケーションサーバ170からの、フロア入手可能性の帯域外シグナリング指示を待つ必要はない。帯域内シグナリングを使うことによって、ストリームの終結およびフロア状態は、帯域外シグナリングを待つことによる遅延なしで、直ちに更新され得ることが諒解されよう。ただし、サーバは、帯域内シグナリングを監視していない場合、まだ知らせを受けていない可能性があるので、フロアは、ローカルな観点からは「オープン」になることに留意されたい(この態様についてのさらなる考察は、以下の段落で行う)。

別の態様では、パケット9がドロップされ、マーカビットが失われ、したがってストリームインジケータの帯域内終結も欠落される可能性に対処するために、マーカビットを含む設定可能な数のRTPパケットが、ストリームインジケータ(たとえば、マーカビット)の帯域内終結が受信される確率を高めるために送られてよい。たとえば、オーディオ送信の最後のN個のRTPパケットは、オーディオ送信(またはストリーム)の終結を示すようにマーカビットが設定されたMB404を搬送することができる。さらに別の例では、デバイスAのユーザが送話をやめたことにターゲットデバイスが気づくようにするために、最終実質RTPパケットの後に、N個の「空」RTPパケット(すなわち、オーディオペイロードデータがない)が送信されてよい。

別の態様では、パケット9がドロップされ、マーカビットが失われ、したがってストリームインジケータの帯域内終結も欠落される可能性に対処するために、最後のいくつかのデータストリームパケットが、最終パケットまでカウントダウンするように構成されてよい。ユーザがPTTボタンを解放したとき、デバイスA401に、バッファリングされたパケットが依然として存在する場合がある。これらのパケットは、最終パケットまでの「カウントダウン」を示す、ペイロード中のフィールドもしくはバイトまたはヘッダ拡張で構成することができる。たとえば、ユーザがPTTボタンを解放したとき、パケット7〜9が依然としてデバイスA401においてバッファリングされていたと仮定すると、パケット7中のフィールドは、ストリーム中にさらに3つのパケットがあることを示すように「3」に設定されてよい。あるいは、パケット7中のフィールドが、最終パケットの前にさらに2つのパケットがあることを示すように「2」に設定されてもよい。同様に、パケット8中のフィールドは、「2」または「1」に設定されてよい。最終パケットとしてのパケット9中のフィールドは、「1」または「0」に設定されてよい。あるいは、パケット9は、パケット7および8のようにフィールドを含むのではなく、むしろ、本明細書で論じるように、マーカビットを設定させ、または特殊ペイロードをもつことができる。ペイロード中のフィールドは、オーディオペイロード中のフィールドであり、別個のストリーム終結パケットのペイロード中のフィールドではないことに留意されたい。

データストリームの終結におけるいくつかのパケットは、最終パケットまでカウントダウンするように構成されるので、ターゲットは、これらのパケットのうちの少なくとも1つを受信する限り、どのパケットが最終であり、または最終であるべきか判断することが可能である。たとえば、デバイスB411が各パケットに、受信されるまで120msを与えると仮定すると、デバイスB411は、240ms以内にパケット7は受信するがパケット8および9は受信しない場合、パケット9が最終パケットであるので、パケット10を待ち続ける必要はないことがわかる。デバイスB411は代わりに、別の着信ストリームがある場合は、そのストリームに直ちに切り替えてよい。

図4を、オーディオデータの送信に関して説明したが、デバイスA401は、追加または代替として、ビデオおよび/または不透明データ(たとえば、デバイスA401のユーザインターフェースを移動されるポインタのx-y座標)を記録および送信し得ることが明らかであろう。そのようなケースでは、パケット7、8、および9の、それぞれフレーム98〜103、104〜109、および110〜113は、オーディオ、ビデオ、および/または不透明データを含むことになる。不透明データとは、隠れた表現、またはフォーマットをもつデータであり、したがって、不透明データの表現へのアクセスを有するサブルーチンをコールすることによってのみ操作することができる。

別の態様では、デバイス401は、同期したオーディオストリームとビデオストリームを送信中であり得る。これらの2つのストリームが同期されるので、オーディオストリームの終結も判断することができる。したがって、オーディオストリームとビデオストリームの一方または両方の終結は、様々な実施形態でのようにマーキングされ得る。一方のストリームの最終パケットまたは最後の数パケットが失われた場合、他方のストリームの終結、およびしたがって失われたパケットがあるストリームの終結が依然としてわかるように、両方のストリームの終結をマーキングすることが好ましい。あるいは、一方のストリームの終結のみがマーキングされればよく、受信機は、他方のストリームの終結を、マーキングされたストリームに基づいて判断することができる。

上記開示を鑑みると、当業者には諒解されるように、帯域内シグナリングは、帯域外シグナリングを帯域内メディア転送と同期させることが困難であることにより、受信機の観点からストリームが本当に終結した、より正確な時点を示す可能性がある。正しく同期されない場合、帯域外シグナリングは、「END」信号があまりにも早く、またはあまりにも遅く到着する時間間隙を残す場合があり、その結果、ストリームが短く切り捨てられ、またはストリームを不足モードで継続させる可能性がある(たとえば、RTPパケットが到着しなくなるが、ユーザコンテキストは更新されない)。帯域内「シグナリング」は、ストリームをサーバまたは他の制御エンティティへのシグナリングと同期させるための、他のさらなる複雑さを緩和する。また、帯域内シグナリングの使用により、データストリーム中の最終(またはほぼ最終)パケットが受信されるとすぐに、データストリームのエンドポイントを伝えることができ、そうすることによって、セッション終結状況を認識するだけのトラフィック非アクティビティタイマよりも、ストリーム中の最終パケットが受信された後の閾値期間だけ早くセッション終結状況を伝えることができる。

図5は、従来の帯域外シグナリングによりRTPベースの通信セッションを終了させるプロセスを示す。図5のプロセスは、図4のプロセスと、いくつかの点で同様であり、したがってデバイスA501は、オーディオデータのフレームを含むフレームバッファ502を有し、様々なパケットを含むストリーム507が、デバイスB511のデジッタバッファ508に送信される。図4のシステムとの追加共通要素については、冗長性を避けるために記載しない。ただし、図5に示すプロセスでは、メディアコンテンツ(たとえば、PTT呼中のオーディオ)の終結を示すためのマーカビットがない。そうではなく、従来の帯域外シグナリングベースのセッション終了では、デバイスA501は、デバイスA501がフロアを解放した(たとえば、デバイスAからのストリームが終結した)ことを示す帯域外シグナリング504を、アプリケーションサーバ170に送る。アプリケーションサーバ170は次いで、デバイスA501からの帯域外シグナリング504を処理し、帯域外シグナリング505を使って、フロアが解放されたこと(ストリームの終結を示し、フロアがオープンであること510も示す)を他のデバイス(たとえば、デバイスB511)に通知する。帯域内バッファ(たとえば、デジッタバッファ508または他のバッファ)中での様々な待ち時間および/または他の遅延によって、フロア解放の帯域外シグナリング505は、参照509で示すように、あまりにも早くターゲットデバイスに到着する場合があり(たとえば、フロアの早期解放、およびデバイスA501のオーディオの一部の切り捨てにつながる)、あるいは、あまりにも遅く到着する場合がある(たとえば、図5には明示的に示さないが、フロアが解放されるのに先立つ、オーディオ/メディアなしの期間が延びることになる)。

図6を参照すると、2つの着信ストリームを用いる帯域内シグナリングの例が示されている。デバイスA601は、一連のパケットとして607でストリーミングされ得るメディア602(たとえば、ビデオ、オーディオ、不透明データなど)をキャプチャすることができる。同様に、デバイスB611は、一連のパケットとして617でストリーミングされ得るBメディア612(たとえば、ビデオ、オーディオ、不透明データなど)をキャプチャすることができる。各ストリームは、デバイスC621において、それぞれデジッタバッファAおよびデジッタバッファB中で受信され得る。各ストリームは、それぞれのRTPパケットのヘッダに含まれる固有の同期ソース(SSRC)を有し、したがってデバイスC621は、ストリームを識別し区別することができる。上述の説明と同様に、ストリーム607は、メディアの終結または送出側デバイス(たとえば、デバイスA)がメディアを切り替えることを望むポイントを示すマーカビットも含むパケット9を含む。これにより、デバイスCは、第1のストリームデジッタバッファ608から、デジッタバッファ618に含まれる第2のストリームに、630で、ソースを直ちにカットオーバーすることができる。結果として、631で、メディアも、Aメディア602からBメディア612にカットオーバーされ、これは622でデバイスC621において反映され得る(たとえば、メディアプレーヤ、ディスプレイなど)。したがって、上で論じたように、帯域外シグナリングを使う場合は容易に達成することができない、正確なカットオーバー時間が与えられる。

上では、ストリームまたはストリーム送信の終結をマーキングするための、帯域内シグナリングの使用および実装のいくつかの基本的な例を挙げたが、様々な実施形態は上記例によって限定されないことが諒解されよう。

たとえば、図7Aは、帯域内シグナリングを用いたサーバ対話をさらに含む、ある実施形態による、RTPベースの通信セッションを終了させるプロセスを示す。このプロセスは、図4に関係して開示したものと同様であり、710で、オーディオ、ビデオ、または不透明データなどのメディアが、デバイスBに送信されるために、デバイスAからアプリケーションサーバ170にストリーミングされる(たとえば、パケット7および8)。PTTボタンは、712で解放されてよく、714で、マーカビットが最終パケット(たとえば、パケット9)に追加されてよく、パケットは次いで、アプリケーションサーバ170に送信される。代替例では、デバイスAが、デバイスAのスクリーンを移動するポインタのx-y座標などの不透明データをストリーミングしている場合、712でのユーザのセッション終結入力、すなわち、PTT解放は、PTT解放に対応する必要はなく、指やスタイラスなどのポインタを、スクリーンから持ち上げることを含む他のユーザ入力に対応してよく、この入力は、デバイスAに、714で、不透明データの最終パケットにマーカビットを追加するようシグナリングすることができる。図7Aの例示した実施形態では、アプリケーションサーバ170は、メディアストリーム(たとえば、パケット7および8)を受信し、次いで、メディアストリームを、720で、意図されたターゲット(たとえば、デバイスB)にフォワードする。722で、アプリケーションサーバ170は任意選択で、マーカビットをもつパケットを受信し検出する。アプリケーションサーバ170は、デバイスAのコンテキストおよび/またはフロア状況(たとえば、オープン)をアクティブに更新することができる。あるいは、アプリケーションサーバ170は、マーカビットの検出以外のどのアクションもとらなくてよい。メディアの残りは、724で、ターゲットにストリーミングされる。この時点で、アプリケーションサーバ170は、何もせず、デバイスAからの、メディア/フロア解放の終結を確認するための帯域外シグナリングを待ち受ければよい。

デバイスAがフロアをもっているので、デバイスBは、730において、リッスンモードで動作している。ストリーミングメディア(たとえば、パケット7および8)を732で受信すると、デバイスBは、メディアを従来のやり方で再生/処理する。対照的に、734で、マーカビットをもつ最終パケットが受信されると、736で、発信側デバイスAのユーザコンテキストおよびフロア状況がオープン状態に変えられる(デバイスBにおいてローカルに)。

デバイスBのみを参照して例示したが、図7Bに示すように、複数のターゲットデバイスがあってよく、各々が異なる待ち時間をもつ場合があり、したがって、帯域内シグナリングと、ターゲットからの帯域内シグナリングの肯定応答とを使ってのフロア状況の調整または他の遷移により、システム性能およびユーザエクスペリエンスが高まり得ることが諒解されよう。たとえば、より速いデバイスへの、フロアの早期グラントを防止することができる。

図7Bを参照すると、発信側デバイスAからのメディアは、図7Aの場合と同じであると見なされるので、再度説明はしない。さらに、この図示は、724での、様々なターゲット(たとえば、デバイスBからデバイスN)への、マーカビットをもつ最終パケットの送信から始まる。各デバイスは、734、744で、マーカビットをもつ最終パケットを受信し、736、746で、発信側デバイスAのユーザコンテキストおよびフロア状況がオープン状態に変えられる。デバイスBからのフロア解放(フロアオープン)の肯定応答が、738で、アプリケーションサーバ170に送信される。次いで、より後の時点で、フロア解放(フロアオープン)の肯定応答が、748で、デバイスNから送信される。さらに、本実施形態では、アプリケーションサーバ170は、726に示すように、アプリケーションサーバ170においてフロアをオープンであると指定する前に、ターゲットからの肯定確認を待ち受けてよい。本代替実施形態は、従来のPTTモデルとは異なる。従来のPTTモデルでは、サーバは、ストリームを受信したデバイスがストリームの終結を確認応答するまで待たない。ただし、本代替実施形態では、サーバは、誤判断を避けるため、各ターゲット/受話者から確認応答を受信する(738、748)まで、フロアオープン状態を反映しない。736および746における「フロアがオープンである」という概念は、デバイス/ユーザの観点からのものであることが諒解されよう。さらに、図7Aでは、アプリケーションサーバ170は任意選択で、デバイスAからの着信RTPパケットのRTPヘッダフィールドを評価しており、そうすることによってアプリケーションサーバ170は、図7Aの722で、データストリームの終結を示すようにマーカビットが設定された、デバイスAからのRTPパケットを認識できることが諒解されよう。ただし、図7Bの738および/または748でACKを受信すると、図7Bのアプリケーションサーバ170には、フロアをあきらめるという、デバイスAの意図が通知される。したがって、図7Bでは、図7Aからの722の任意選択の動作が実施されないと想定される。

別の態様では、デバイスAは、そのメディアを終結させ、そのように示すためのマーカビットを与えることができる。ただし、その後間もなく、デバイスAは、継続するためにフロアを再獲得することを望む場合がある。このシナリオにおいて、デバイスAからの要求/メディアが受信されたとき、マーカビットをもつパケットが、アプリケーションサーバ170において依然としてバッファリングされている場合、アプリケーションサーバ170は、バッファリングされているパケットからマーカビットを取り去ってよいので、ターゲットデバイスによって知覚されるフロア状態の変化はない。

図8は、サーバがマーカビットを検出することができる実施形態のフローチャート800を示す。810において、プロセスでは最初に、サーバが、特定のデータストリームについての最終RTPパケットを送信デバイスから受信する。820で、最終パケット状況がマーカビットによって肯定的に示されるとサーバが判断した場合、プロセスは、上で(たとえば、図7の722で)論じたように継続し得る。ただし、検出されたマーカビットがない場合、メディアの終結を判断するための代替方法(たとえば、帯域外シグナリング、トラフィック非アクティビティタイマ満了など)を、サーバによって利用することができる。たとえば、サーバは、830で、メディアの送信を停止するための、および/またはフロアを解放するための送信デバイスの意図を帯域外シグナリングが示すかどうか判断し、サーバは、840で、送信デバイスへの接続についてのトラフィック非アクティビティタイマがタイムアウトしたかどうかも判断することができる。830または840のいずれかが、送信デバイスからのメディアストリーム(または送信セッション)の終結を示す場合、サーバは、850で、マーカビットを含むパケットを生成し、860で、そのパケットをターゲットデバイスに送信してよい。したがって、このハイブリッド構成により、帯域外シグナリングの受信のための従来の処理が可能になり、さらに、メディア終結および/またはフロア解放が判断されると、帯域内シグナリングを活用することができる。これは、最終メディアパケットのインジケータとしてのマーカビットの認識をサポートしないレガシーデバイスまたは非ネイティブシステムとのインターフェースをとるのに有用であり得る。最後に、ウォッチドッグ(またはトラフィック非アクティビティ)タイマが、840で、メディアおよび/またはフロア解放の終結の指示としてタイムアウトするように構成され得る。どのメディアパケットもどのシグナリングも受信されない場合、サーバは、850で、マーカビットを含むパケットを生成し、860で、そのパケットをターゲットデバイスに送信してよい。これは、マーカビットをもつ1つのパケットまたは複数のパケットが失われ、または崩壊された場合にマーカビットを実際に含むデバイス用のバックアップとしても機能し得る。したがって、サーバにおけるマーカビットの検出により
、マーカビットが受信されないケースに対して帯域内シグナリングを活用する際の柔軟性が増し得る。

上で述べたように、マーカビットは、メディアストリームの終結をマーキングするための肯定的な帯域内シグナリングを記述するのに使われている。ただし、他の機構も帯域内シグナリングに使われてよいことが諒解されよう。たとえば、消去フレーム、ヌル/空白レートフレーム、ペイロードなしのRTPパケット、部分ペイロードをもつRTPパケットなどが、ストリームの終結をマーキングするための帯域内シグナリングとして使われ得る。さらに、メディアストリームの終結の帯域内シグナリングは、ファクタをパッケージ化およびバンドリングする、ストリームの残りに準拠するフルおよび可聴パケットに準拠しないどのパケットでも示すことができる。さらに、上記の組合せ(たとえば、マーカビットと、ペイロードなしのRTPパケット)が使われ得ることが諒解されよう。したがって、様々な実施形態は、どの特定の帯域内シグナリング技法にも限定されない。

様々な実施形態を、主としてUE/デバイスの間の1対1の通信セッションを参照して記載したが、他の実施形態は、図7Bによって証明されるように、3つ以上のUEを含み得るグループ通信セッションを対象とし得ることが諒解されよう。

図9に、機能性を実施するように構成された論理を含む通信デバイス900を示す。通信デバイス900は、限定はしないが、UE102、108、110、112または200、ノードBまたは基地局124、RNCまたは基地局制御装置122、パケットデータネットワークエンドポイント(たとえば、SGSN160、GGSN165、Long Term Evolution(LTE)のモビリティ管理エンティティ(MME)など)、サーバ170〜186のいずれかなどを含む上記の通信デバイスのいずれかに対応し得る。したがって、通信デバイス900は、ネットワークを介して1つまたは複数の他のエンティティと通信する(または通信を容易にする)ように構成されたどの電子デバイスにも対応し得る。

図9を参照すると、通信デバイス900は、情報を受信および/または送信するように構成された論理905を含む。一例では、通信デバイス900がワイヤレス通信デバイス(たとえば、UE200、ノードB124など)に対応する場合、情報を受信および/または送信するように構成された論理905は、ワイヤレストランシーバおよび関連ハードウェア(たとえば、RFアンテナ、モデム、変調器および/または復調器など)のようなワイヤレス通信インターフェース(たとえば、Bluetooth(登録商標)、WiFi、2G、3Gなど)を含むことができる。別の例では、情報を受信および/または送信するように構成された論理905は、有線通信インターフェース(たとえば、インターネット175にアクセスする手段となり得る直列接続、USBまたはFirewire接続、イーサネット(登録商標)接続など)に対応し得る。したがって、通信デバイス900が何らかのタイプのネットワークベースのサーバ(たとえば、SGSN160、GGSN165、アプリケーションサーバ170など)に対応する場合、情報を受信および/または送信するように構成された論理905は、一例では、ネットワークベースのサーバをイーサネット(登録商標)プロトコルを介して他の通信エンティティに接続するイーサネット(登録商標)カードに対応し得る。さらなる一例では、情報を受信および/または送信するように構成された論理905は、通信デバイス900がそのローカル環境を監視する手段となり得る知覚または測定ハードウェア(たとえば、加速度計、温度センサ、光センサ、ローカルRF信号を監視するためのアンテナなど)を含むことができる。情報を受信および/または送信するように構成された論理905は、実行されると、その受信および/または送信機能を実施するための、情報を受信および/または送信するように構成された論理905の関連ハードウェアを許可するソフトウェアも含み得る。ただし、情報を受信および/または送信するように構成された論理905は、ソフトウェア単体に対応するのではなく、情報を受信および/または送信するように構成された論理905は、その機能性を遂行するためのハードウェアに少なくとも部分的に依拠する。

図9を参照すると、通信デバイス900は、情報を処理するように構成された論理910をさらに含む。一例では、情報を処理するように構成された論理910は、少なくともプロセッサを含むことができる。情報を処理するように構成された論理910によって実施することができる処理タイプの例示的実装形態は、判断を実施すること、接続を確立すること、異なる情報選択肢の間での選択を行うこと、データに関連した評価を実施すること、測定動作を実施するための、通信デバイス900に結合されたセンサと対話すること、ある形式から別の形式に(たとえば、.wmvから.aviなど、異なるプロトコルの間で)情報を変換することなどを含むが、それに限定されない。たとえば、情報を処理するように構成された論理910に含まれるプロセッサは、汎用プロセッサ、デジタル信号プロセッサ(DSP)、特定用途向け集積回路(ASIC)、フィールドプログラマブルゲートアレイ(FPGA)または他のプログラマブル論理デバイス、個別ゲートまたはトランジスタ論理、個別ハードウェア構成要素、あるいは本明細書で説明する機能を実施するように設計されたそれらの任意の組合せに相当し得る。汎用プロセッサはマイクロプロセッサであり得るが、代替として、プロセッサは、任意の従来のプロセッサ、コントローラ、マイクロコントローラ、または状態機械であり得る。プロセッサはまた、コンピューティングデバイスの組合せ、たとえば、DSPとマイクロプロセッサとの組合せ、複数のマイクロプロセッサ、DSPコアと連携する1つまたは複数のマイクロプロセッサ、あるいは任意の他のそのような構成として実装され得る。情報を処理するように構成された論理910は、実行されると、その処理機能を実施するための、情報を処理するように構成された論理910の関連ハードウェアを許可するソフトウェアも含み得る。ただし、情報を処理するように構成された論理910は、ソフトウェア単体に対応するのではなく、情報を処理するように構成された論理910は、その機能性を遂行するためのハードウェアに少なくとも部分的に依拠する。

図9を参照すると、通信デバイス900は、情報を記憶するように構成された論理915をさらに含む。一例では、情報を記憶するように構成された論理915は、少なくとも非一時的メモリおよび関連ハードウェア(たとえば、メモリコントローラなど)を含むことができる。たとえば、情報を記憶するように構成された論理915中に含まれる非一時的メモリは、RAMメモリ、フラッシュメモリ、ROMメモリ、EPROMメモリ、EEPROMメモリ、レジスタ、ハードディスク、リムーバブルディスク、CD-ROM、または当技術分野で知られている任意の他の形態の記憶媒体に対応することができる。情報を記憶するように構成された論理915は、実行されると、その記憶機能を実施するための、情報を記憶するように構成された論理915の関連ハードウェアを許可するソフトウェアも含み得る。ただし、情報を記憶するように構成された論理915は、ソフトウェア単体に対応するのではなく、情報を記憶するように構成された論理915は、その機能性を遂行するためのハードウェアに少なくとも部分的に依拠する。

図9を参照すると、通信デバイス900はさらに、情報を提示するように構成された論理920を任意選択で含む。一例では、情報を提示するように構成された論理920は、少なくとも出力デバイスおよび関連ハードウェアを含むことができる。たとえば、出力デバイスは、ビデオ出力デバイス(たとえば、ディスプレイスクリーン、USB、HDMI(登録商標)など、ビデオ情報を搬送することができるポートなど)、オーディオ出力デバイス(たとえば、スピーカー、マイクロフォンジャック、USB、HDMI(登録商標)など、オーディオ情報を搬送することができるポートなど)、振動デバイス、および/または情報が出力のためにフォーマットされるか、通信デバイス900のユーザもしくはオペレータによって実際に出力される手段となり得る任意の他のデバイスを含むことができる。たとえば、通信デバイス900が、図3に示すようなUE200に対応する場合、情報を提示するように構成された論理920は、ディスプレイ224を含み得る。さらに別の例では、情報を提示するように構成された論理920は、ローカルユーザをもたないネットワーク通信デバイス(たとえば、ネットワークスイッチやルータ、リモートサーバなど)など、いくつかの通信デバイスに関しては省いてもよい。情報を提示するように構成された論理920は、実行されると、その提示機能を実施するための、情報を提示するように構成された論理920の関連ハードウェアを許可するソフトウェアも含み得る。ただし、情報を提示するように構成された論理920は、ソフトウェア単体に対応するのではなく、情報を提示するように構成された論理920は、その機能性を遂行するためのハードウェアに少なくとも部分的に依拠する。

図9を参照すると、通信デバイス900はさらに、ローカルユーザ入力を受信するように構成された論理925を任意選択で含む。一例では、ローカルユーザ入力を受信するように構成された論理925は、少なくともユーザ入力デバイスおよび関連ハードウェアを含むことができる。たとえば、ユーザ入力デバイスは、ボタン、タッチスクリーンディスプレイ、キーボード、カメラ、オーディオ入力デバイス(たとえば、マイクロフォン、またはマイクロフォンジャックなど、オーディオ情報を搬送することができるポートなど)、および/または情報がそれによって通信デバイス900のユーザもしくはオペレータから受信され得る任意の他のデバイスを含むことができる。たとえば、通信デバイス900が、図3に示すようなUE200に対応する場合、ローカルユーザ入力を受信するように構成された論理925は、ディスプレイ224(タッチスクリーンを実装した場合)、キーパッド226などを含み得る。さらに別の例では、ローカルユーザ入力を受信するように構成された論理925は、ローカルユーザをもたないネットワーク通信デバイス(たとえば、ネットワークスイッチやルータ、リモートサーバなど)など、いくつかの通信デバイスに関しては省いてもよい。ローカルユーザ入力を受信するように構成された論理925は、実行されると、その入力受信機能を実施するための、ローカルユーザ入力を受信するように構成された論理925の関連ハードウェアを許可するソフトウェアも含み得る。ただし、ローカルユーザ入力を受信するように構成された論理925は、ソフトウェア単体に対応するのではなく、ローカルユーザ入力を受信するように構成された論理925は、その機能性を遂行するためのハードウェアに少なくとも部分的に依拠する。

図9を参照すると、905〜925の構成された論理は、図9では別個または相異なるブロックとして示されているが、それぞれの構成された論理がその機能性を実施するためのハードウェアおよび/またはソフトウェアは、部分的に重複し得ることが諒解されよう。たとえば、905〜925の構成された論理の機能性を容易にするのに使われるどのソフトウェアも、情報を記憶するように構成された論理915に関連付けられた非一時的メモリに記憶することができ、そうすることによって、905〜925の構成された論理は各々、その機能性(すなわち、この場合、ソフトウェア実行)を、情報を送信するように構成された論理905によって記憶されたソフトウェアの動作に部分的に基づいて実施する。同様に、構成された論理のうちの1つに直接関連付けられたハードウェアは、他の構成された論理によって時々借り、または使うことができる。たとえば、情報を処理するように構成された論理910のプロセッサは、データを、情報を受信および/または送信するように構成された論理905によって送信される前に、適切な形式にフォーマットすることができ、そうすることによって、情報を受信および/または送信するように構成された論理905は、その機能性(すなわち、この場合、データの送信)を、情報を処理するように構成された論理910に関連付けられたハードウェア(すなわち、プロセッサ)の動作に部分的に基づいて実施する。

様々なブロックにおける構成された論理または「ように構成された論理」は、特定の論理ゲートまたは論理要素に限定されるのではなく、概して、本明細書に記載した機能性を、(ハードウェアまたはハードウェアとソフトウェアの組合せのいずれかを介して)実施するための能力を指すことが諒解されよう。したがって、様々なブロックに示す構成された論理または「ように構成された論理」は、「論理」という言葉を共有するにもかかわらず、必ずしも論理ゲートまたは論理要素として実装されるわけではない。

情報および信号は、多種多様な技術および技法のいずれかを使用して表すことができることを当業者は諒解されよう。たとえば、上記の説明全体にわたって言及され得るデータ、命令、コマンド、情報、信号、ビット、シンボル、およびチップは、電圧、電流、電磁波、磁界または磁性粒子、光場または光学粒子、あるいはそれらの任意の組合せによって表され得る。

さらに、本明細書で開示した実施形態に関連して説明した様々な例示的な論理ブロック、モジュール、回路、およびアルゴリズムステップは、電子ハードウェア、コンピュータソフトウェア、または両方の組合せとして実装できることを、当業者は諒解されよう。ハードウェアとソフトウェアのこの互換性を明確に示すために、様々な例示的な構成要素、ブロック、モジュール、回路、およびステップを、上記では概してそれらの機能性に関して説明した。そのような機能性をハードウェアとして実装するか、ソフトウェアとして実装するかは、特定の適用例および全体的なシステムに課される設計制約に依存する。当業者は、説明した機能性を特定の適用例ごとに様々な方法で実装し得るが、そのような実装の決定は、様々な実施形態の範囲からの逸脱を生じるものと解釈すべきではない。

本明細書で開示される実施形態に関して説明される様々な例示的な論理ブロック、モジュール、および回路は、汎用プロセッサ、デジタル信号プロセッサ(DSP)、特定用途向け集積回路(ASIC)、フィールドプログラマブルゲートアレイ(FPGA)もしくは他のプログラマブル論理デバイス、個別ゲートもしくはトランジスタ論理、個別ハードウェア構成要素、または、本明細書で説明される機能を実行するように設計されたそれらの任意の組合せによって、実装または実施され得る。汎用プロセッサはマイクロプロセッサであり得るが、代替として、プロセッサは、任意の従来のプロセッサ、コントローラ、マイクロコントローラ、または状態機械であり得る。プロセッサはまた、コンピューティングデバイスの組合せ、たとえば、DSPとマイクロプロセッサとの組合せ、複数のマイクロプロセッサ、DSPコアと連携する1つまたは複数のマイクロプロセッサ、あるいは任意の他のそのような構成として実装され得る。

本明細書で開示した実施形態と関連して説明した方法、シーケンス、および/またはアルゴリズムは、ハードウェアで、プロセッサによって実行されるソフトウェアモジュールで、またはその2つの組合せで直接実施され得る。ソフトウェアモジュールは、RAMメモリ、フラッシュメモリ、ROMメモリ、EPROMメモリ、EEPROMメモリ、レジスタ、ハードディスク、リムーバブルディスク、CD-ROM、または当技術分野で知られている任意の他の形態の記憶媒体中に存在し得る。例示的な記憶媒体は、プロセッサが記憶媒体から情報を読み取り、記憶媒体に情報を書き込むことができるように、プロセッサに結合される。代替として、記憶媒体はプロセッサと一体であり得る。プロセッサおよび記憶媒体はASIC中に常駐し得る。ASICはユーザ端末(たとえば、アクセス端末)中に常駐し得る。代替として、プロセッサおよび記憶媒体は、ユーザ端末中に個別構成要素として常駐し得る。

1つまたは複数の例示的な実施形態では、説明した機能は、ハードウェア、ソフトウェア、ファームウェア、またはそれらの任意の組合せで実装され得る。ソフトウェアで実装する場合、機能は、1つまたは複数の命令またはコードとしてコンピュータ可読媒体上に記憶されるか、あるいはコンピュータ可読媒体を介して送信され得る。コンピュータ可読媒体は、ある場所から別の場所へのコンピュータプログラムの転送を可能にする任意の媒体を含む、コンピュータ記憶媒体とコンピュータ通信媒体の両方を含む。記憶媒体は、コンピュータによってアクセスされ得る任意の利用可能な媒体であり得る。限定ではなく例として、そのようなコンピュータ可読媒体は、RAM、ROM、EEPROM、CD-ROMもしくは他の光ディスクストレージ、磁気ディスクストレージもしくは他の磁気ストレージデバイス、または、命令もしくはデータ構造の形態の所望のプログラムコードを搬送もしくは記憶するために使用でき、コンピュータによってアクセスできる、任意の他の媒体を含み得る。同様に、いかなる接続も適切にコンピュータ可読媒体と称される。たとえば、ソフトウェアが、同軸ケーブル、光ファイバケーブル、ツイストペア、デジタル加入者回線(DSL)、または赤外線、無線、およびマイクロ波などのワイヤレス技術を使用して、ウェブサイト、サーバ、または他のリモートソースから送信される場合、同軸ケーブル、光ファイバケーブル、ツイストペア、DSL、または赤外線、無線、およびマイクロ波などのワイヤレス技術は、媒体の定義に含まれる。本明細書で使用するディスク(disk)およびディスク(disc)は、コンパクトディスク(disc)(CD)、レーザディスク(disc)、光ディスク(disc)、デジタル多用途ディスク(disc)(DVD)、フレキシブルディスク(disk)およびブルーレイ(登録商標)ディスク(disc)を含み、ディスク(disk)は、通常、データを磁気的に再生し、ディスク(disc)は、データをレーザで光学的に再生する。上記の組合せもコンピュータ可読媒体の範囲内に含めるべきである。

上記の開示は本発明の例示的な実施形態を示すが、添付の特許請求の範囲によって規定される本発明の範囲から逸脱することなく、本明細書において様々な変更および修正を行えることに留意されたい。本明細書で説明した本発明の実施形態による方法クレームの機能、ステップおよび/または動作は、特定の順序で実施されなくてもよい。さらに、本発明の要素は、単数形で説明または請求されていることがあるが、単数形に限定することが明示的に述べられていない限り、複数形が企図される。

100 ワイヤレス通信システム、システム
102 UE、アクセス端末、セルラー電話、ワイヤレスクライアントコンピューティングデバイス
104 エアインターフェース
108 UE、携帯情報端末、ワイヤレスクライアントコンピューティングデバイス
110 UE、ページャ、ワイヤレスクライアントコンピューティングデバイス
112 UE、コンピュータプラットフォーム、ワイヤレスクライアントコンピューティングデバイス
120 無線アクセスネットワーク(RAN)
122 RNC、基地局制御装置
124 ノードB、基地局
126 コアネットワーク
160 サービングGPRSサポートノード(SGSN)
162 第1のパケットデータネットワークエンドポイント
164 第2のパケットデータネットワークエンドポイント
165 ゲートウェイGPRSサポートノード(GGSN)
170 アプリケーションサーバ、サーバ
170A 地域ディスパッチャ
170B メディア制御コンプレックス(MCC)
175 インターネット
182 認証、認可およびアカウンティング(AAA)サーバ、サーバ
184 プロビジョニングサーバ、サーバ
186 インターネットプロトコル(IP)マルチメディアサブシステム(IMS)/セッション開始プロトコル(SIP)登録サーバ、サーバ
188 ルーティングユニット
200 UE
202 プラットフォーム
206 トランシーバ
208 特定用途向け集積回路(ASIC)
210 アプリケーションプログラミングインターフェース(API)
212 メモリ
214 ローカルデータベース
222 アンテナ
224 ディスプレイ
228 プッシュツートークボタン
226 キーパッド
250 帯域内シグナリングアプリケーション
401 デバイスA、デバイス
402 フレームバッファ
404 MB
407 パケットストリーム、ストリーム
408 デジッタバッファ
411 デバイスB
501 デバイスA
502 フレームバッファ
504 帯域外シグナリング
505 帯域外シグナリング
507 ストリーム
508 デジッタバッファ
511 デバイスB
601 デバイスA
602 メディア、Aメディア
608 第1のストリームデジッタバッファ、デジッタバッファ
611 デバイスB
612 Bメディア
621 デバイスC
900 通信デバイス
905 情報を受信および/または送信するように構成された論理、構成された論理
910 情報を処理するように構成された論理、構成された論理
915 情報を記憶するように構成された論理、構成された論理
920 情報を提示するように構成された論理、構成された論理
925 ローカルユーザ入力を受信するように構成された論理、構成された論理

Claims

帯域内シグナリングを使ってデータストリーム(507、607、617)の終結を示すための方法であって、
前記データストリームを送信するステップ(710、720、860)であって、前記データストリームが複数のパケットを含み、前記複数のパケットの各パケットが、ヘッダおよびペイロードを含む、ステップと、
前記複数のパケットのうちの少なくとも1つのパケットを、前記データストリームの前記終結を示すように構成するステップ(714、850)であって、前記ヘッダ中のマーカビットフィールドを、前記データストリームの前記終結を示すように設定するステップを含むステップと、前記データストリームの最終パケットの直前にくる、一群のパケットの各パケットの前記ペイロード内のフィールドを、前記データストリームの前記終結を示すように構成するステップであって、前記一群のパケットが、前記最終パケットまでのカウントダウンとして作用するように構成されるステップとを含み、
サーバが、前記少なくとも1つのパケットの前記構成を検出し、帯域外シグナリングを受信する前にユーザコンテキストを更新する方法。
前記ペイロードに含まれるデータ量を削減するステップが、
前記ペイロード中の内容の全量未満を含めるステップ、
フレームの部分的バンドルを含めるステップ、
すべての空白および/もしくは消去フレームを含めるステップ、または
前記ペイロードを削除するステップのうちの少なくとも1つを含む、請求項1に記載の方法。
ワイヤレスデバイスが、前記一群のパケットのうちの少なくとも1つに基づいて、前記データストリームの前記終結を判断する、請求項1に記載の方法。
前記データストリームの前記終結を示すステップが、関連データストリームへの終結を示す、請求項1に記載の方法。
前記最終パケットが、ビデオストリームに関連し、前記関連するストリームがオーディオストリームである、請求項4に記載の方法。
サーバにおいて、前記少なくとも1つのパケットの前記構成を検出する前に、前記データストリームの前記終結を示す帯域外シグナリングを検出するステップであって、
前記サーバが、前記帯域外シグナリングを検出するステップに応答して、前記構成するステップを実施するステップと、
前記構成された少なくとも1つのパケットを、少なくとも1つのターゲットデバイスに送信するステップとをさらに含む、請求項1に記載の方法。
帯域内シグナリングを使ってデータストリーム(507、607、617)の終結を検出するための方法であって、
前記データストリームを受信するステップ(732、810)であって、前記データストリームが複数のパケットを含み、前記複数のパケットの各パケットが、ヘッダおよびペイロードを含む、ステップと、
前記複数のパケットのうちの少なくとも1つのパケットが、前記データストリームの前記終結を示すように構成されていることを検出するステップ(734、744、820)であって、検出する前記ステップが、前記少なくとも1つのパケットの前記ヘッダ中のマーカビットフィールドが前記データストリームの前記終結を示すように構成されていることを検出するステップを含み、前記データストリームの最終パケットの直前にくる、一群のパケットの各パケットの前記ペイロードが、前記データストリームの前記終結を示すことを検出するステップをさらに含み、前記一群のパケットが、前記最終パケットまでのカウントダウンとして作用するように構成されるステップとを含み、
サーバが、前記少なくとも1つのパケットの前記構成を検出し、帯域外シグナリングを受信する前にユーザコンテキストを更新する方法。
前記データストリームが、第1のワイヤレスデバイスから受信された第1のデータストリームであり、前記方法が、
第2のワイヤレスデバイスから第2のデータストリームを受信するステップと、
前記第1のデータストリームおよび前記第2のデータストリームをバッファリングするステップと、
前記検出するステップに応答して、前記第1のデータストリームの再生から、前記第2のデータストリームの再生に切り替えるステップとをさらに含む、請求項7に記載の方法。
帯域内シグナリングを使ってデータストリーム(507、607、617)の終結を示すための装置(102、108、110、112、170、200、401、411、601、611、621、900)であって、
前記データストリームを送信するように構成された論理部(710、720、860)であって、前記データストリームが複数のパケットを含み、前記複数のパケットの各パケットが、マーカビットフィールドをもつヘッダとペイロードとを含む、論理部と、
前記複数のパケットのうちの少なくとも1つのパケットを、前記データストリームの前記終結を示すように構成するように構成された論理部(714、850)であって、前記ヘッダ中のマーカビットフィールドを、前記データストリームの前記終結を示すように設定することを含む論理部と、
前記データストリームの最終パケットの直前にくる、一群のパケットの各パケットの前記ペイロード内のフィールドを、前記データストリームの前記終結を示すように構成するように構成された論理部であって、前記一群のパケットが、前記最終パケットまでのカウントダウンとして作用するように構成される論理部とを備え、
サーバが、前記少なくとも1つのパケットの前記構成を検出し、帯域外シグナリングを受信する前にユーザコンテキストを更新する装置。
帯域内シグナリングを使ってデータストリーム(507、607、617)の終結を検出するための装置(102、108、110、112、170、200、401、411、601、611、621、900)であって、
前記データストリームを受信するように構成された論理部(732、810)であって、前記データストリームが複数のパケットを含み、前記複数のパケットの各パケットが、ヘッダおよびペイロードを含む論理部と、
前記複数のパケットのうちの少なくとも1つのパケットが、前記データストリームの前記終結を示すように構成されていることを検出するように構成された論理部(734、744、820)とを備え、
前記検出するように構成された論理部が、前記少なくとも1つのパケットの前記ヘッダ中のマーカビットフィールドが前記データストリームの前記終結を示すように構成されていることを検出するように構成された論理部と、前記データストリームの最終パケットの直前にくる、一群のパケットの各パケットの前記ペイロードが、前記データストリームの前記終結を示すことを検出するように構成された論理部とを備え、前記一群のパケットが、前記最終パケットまでのカウントダウンとして作用するように構成され、
サーバが、前記少なくとも1つのパケットの前記構成を検出し、帯域外シグナリングを受信する前にユーザコンテキストを更新する装置。
請求項1から8のいずれか１項に記載の方法を実施するための手段を含む装置(102、108、110、112、170、200、401、411、601、611、621、900)。
請求項1から8のいずれか１項に記載の方法を通信エンティティ(102、108、110、112、170、200、401、411、601、611、621、900)に実施させるための少なくとも1つの命令を含む、コンピュータプログラム。