(57)【要約】  ユーザ機器(UE)は、リアルタイム通信セッションの間に喪失メディアの回復を選択的に試みる。一実施形態では、UEは、UEに正しく到着しなかった、リアルタイム通信セッションに参加する別のUEからの喪失メディアパケットの存在を検出する。UEは、複数の外部ソースから少なくとも1つの外部ソースを動的に選択しようと試みるために喪失メディアパケットに関連する回復基準値の組を評価し、少なくとも1つの外部ソースから、喪失メディアパケットは、回復基準値の組に基づいて喪失メディアパケットの回復を試みるために様々な予測信頼性および/または応答時間において回復され得る可能性がある。UEは、この評価に基づいて選択された少なくとも1つの外部ソースから喪失メディアパケットを回復しようと試みる。
2016524352.tif 000002
【特許請求の範囲】
【請求項１】
リアルタイム通信セッションの間に喪失メディアの回復を選択的に試みるように構成されたユーザ機器(UE)を動作させる方法であって、
前記UEに正しく到着しなかった、前記リアルタイム通信セッションに参加する別のUEからの喪失メディアパケットの存在を検出するステップと、
複数の外部ソースから少なくとも1つの外部ソースを動的に選択しようと試みるために前記喪失メディアパケットに関連する回復基準値の組を評価するステップであって、前記少なくとも1つの外部ソースから、前記喪失メディアパケットは、回復基準値の前記組に基づいて前記喪失メディアパケットの回復を試みるために様々な予測信頼性および/または応答時間において回復され得る可能性がある、ステップと、
前記評価に基づいて前記選択された少なくとも1つの外部ソースから前記喪失メディアパケットを回復しようと試みるステップと
を含む、方法。
【請求項２】
前記選択された少なくとも1つの外部ソースは、複数の外部ソースを含む、請求項1に記載の方法。
【請求項３】
前記試みるステップは、前記複数の外部ソースの各々が前記喪失メディアパケットのコピーを提供することを要求するステップを含む、請求項2に記載の方法。
【請求項４】
前記複数の外部ソースのうちの1つから前記喪失メディアパケットの単一のコピーを受信するステップと、
前記喪失メディアパケットの終了期限の前に前記喪失メディアパケットの前記受信された単一のコピーが受信された場合、前記喪失メディアパケットの前記受信された単一のコピーを再生するステップと
をさらに含む、請求項3に記載の方法。
【請求項５】
前記複数の外部ソースのうちの2つ以上から前記喪失メディアパケットの2つ以上のコピーを受信するステップと、
前記喪失メディアパケットの前記2つ以上の受信されたコピーのうちの1つを選択するステップと、
前記喪失メディアパケットの終了期限の前に前記喪失メディアパケットの前記選択されたコピーが受信された場合、前記喪失メディアパケットの前記選択されたコピーを再生するステップと
をさらに含む、請求項3に記載の方法。
【請求項６】
前記選択するステップは、前記選択されたコピーとして最も早く受信されたコピーを選択する、請求項5に記載の方法。
【請求項７】
前記選択された少なくとも1つの外部ソースは、単一の外部ソースを含む、請求項1に記載の方法。
【請求項８】
前記試みるステップは、前記単一の外部ソースが前記喪失メディアパケットのコピーを提供することを要求するステップを含む方法であって、
前記単一の外部ソースから前記喪失メディアパケットの前記要求されたコピーを受信するステップと、
前記喪失メディアパケットの終了期限の前に前記喪失メディアパケットの前記受信された要求されたコピーが受信された場合、前記喪失メディアパケットの前記受信された要求されたコピーを再生するステップと
をさらに含む、請求項7に記載の方法。
【請求項９】
前記単一の外部ソースは、前記複数の外部ソースのうちの最も信頼性が高い外部ソースに相当するか、または
前記単一の外部ソースは、前記複数の外部ソースのうちの最速の応答時間に関連する所与の外部ソースに相当する、
請求項7に記載の方法。
【請求項１０】
前記選択された少なくとも1つの外部ソースから前記喪失メディアパケットを回復しようとする前記試みは、前記喪失メディアパケットを回復することができず、
前記喪失メディアパケットの回復を再試行しないと決定するステップ
をさらに含む、方法であって、
前記リアルタイム通信セッションは、前記喪失メディアパケットの再生なしに続く、
請求項1に記載の方法。
【請求項１１】
前記選択された少なくとも1つの外部ソースから前記喪失メディアパケットを回復しようとする前記試みは、前記喪失メディアパケットを回復することができず、
前記喪失メディアパケットの回復を再試行すると決定するステップと、
回復基準値の前記組に基づいて前記喪失メディアパケットの回復を再試行するために前記複数の外部ソースから少なくとも1つの異なる外部ソースを動的に選択しようと試みるために前記喪失メディアパケットに関連する回復基準値の前記組を再評価するステップと、
前記評価に基づいて前記選択された少なくとも1つの異なる外部ソースから前記喪失メディアパケットを回復することを再試行するステップと
をさらに含む、請求項1に記載の方法。
【請求項１２】
前記喪失メディアパケットが回復され得る可能性がある前記複数の外部ソースは、前記別のUE、前記リアルタイム通信セッションを通信調停しているサーバ、および/または前記リアルタイム通信セッションに同様に参加している1つもしくは複数の異なるUEを含む、請求項1に記載の方法。
【請求項１３】
前記検出に応答して前記リアルタイム通信セッションを休止するステップと、
前記選択された少なくとも1つの外部ソースから前記喪失メディアパケットのコピーを受信するステップと、
前記リアルタイム通信セッションを休止解除し、前記喪失メディアパケットの前記受信されたコピーを再生するステップと
をさらに含む、請求項1に記載の方法。
【請求項１４】
前記選択された少なくとも1つの外部ソースは、前記複数の外部ソースから最も高い信頼性に関連する所与の外部ソースを含む、請求項13に記載の方法。
【請求項１５】
回復基準値の前記組は、
(i)前記喪失メディアパケットの再生緊急度、
(ii)前記喪失メディアパケットが回復され得る可能性がある前記複数の外部ソースの各々の信頼性、
(iii)前記複数の外部ソースの各々の期待応答時間、および/または、
(iv)前記喪失メディアパケットの優先度
を含む、請求項1に記載の方法。
【請求項１６】
回復基準値の前記組は、少なくとも(i)および(iii)を含む、請求項15に記載の方法。
【請求項１７】
前記喪失メディアパケットの前記再生緊急度は高く、
前記評価するステップは、前記高い再生緊急度を満足する期待応答時間で前記複数の外部ソースのサブセットとして前記選択された少なくとも1つの外部ソースを動的に選択する、
請求項16に記載の方法。
【請求項１８】
前記サブセットは、
前記リアルタイム通信セッションに同様に参加し、前記リアルタイム通信セッションを通信調停しているサーバをバイパスする補助通信リンクを介して前記UEに接続される異なるUE
を少なくとも含む、請求項17に記載の方法。
【請求項１９】
回復基準値の前記組は、少なくとも(i)、(ii)、および(iii)を含む、請求項15に記載の方法。
【請求項２０】
前記喪失メディアパケットの前記再生緊急度は中間的であり、
前記評価するステップは、前記中間的な再生緊急度を満足する所与の期待応答時間を有する少なくとも最も信頼性が高い外部ソースを含むものとして前記選択された少なくとも1つの外部ソースを動的に選択する、
請求項19に記載の方法。
【請求項２１】
前記中間的な再生緊急度を満足する前記所与の期待応答時間を有する前記最も信頼性が高い外部ソースは、前記リアルタイム通信セッションを通信調停しているサーバである、請求項20に記載の方法。
【請求項２２】
前記喪失メディアパケットの前記再生緊急度は低く、
前記評価するステップは、前記低い再生緊急度を満足する所与の期待応答時間で少なくとも最も信頼性が高い外部ソースを含むものとして前記選択された少なくとも1つの外部ソースを動的に選択する、
請求項19に記載の方法。
【請求項２３】
前記低い再生緊急度を満足する前記所与の期待応答時間を有する前記最も信頼性が高い外部ソースは、前記別のUEである、請求項22に記載の方法。
【請求項２４】
回復基準値の前記組は、少なくとも(iv)を含む、請求項15に記載の方法。
【請求項２５】
前記試みるステップは、しきい値を超える前記喪失メディアパケットの前記優先度に基づいて実行され、
前記リアルタイム通信セッション中に1つまたは複数の他の喪失メディアパケットを回復しようとする1つまたは複数の試みは、前記しきい値未満の前記1つまたは複数の他の喪失メディアパケットの優先度に基づいてスキップされる、
請求項24に記載の方法。
【請求項２６】
前記試みるステップは、前記リアルタイム通信セッションのリアルタイム通信フェーズを出ることなく前記喪失メディアパケットの回復を試みる、請求項1に記載の方法。
【請求項２７】
前記UEに正しく到着しなかった、前記リアルタイム通信セッションに参加する前記別のUEからの別の喪失メディアパケットの存在を検出するステップと、
前記複数の外部ソースから1つまたは複数の外部ソースを動的に選択しようと試みるために前記別の喪失メディアパケットに関連する回復基準値の前記組を評価するステップであって、前記1つまたは複数の外部ソースから、前記別の喪失メディアパケットは、回復基準値の前記組に基づいて前記別の喪失メディアパケットの回復を試みるために様々な予測信頼性および/または応答時間において回復され得る可能性がある、ステップと、
前記別の喪失メディアパケットに関連する回復基準値の前記組の前記評価に基づいて前記選択された1つまたは複数の外部ソースから前記別の喪失メディアパケットを回復しようと試みるステップと
をさらに含み、
前記喪失メディアパケットの回復のために選択された前記少なくとも1つの選択外部ソースは、前記別の喪失メディアパケットの回復のために選択された前記1つまたは複数の選択外部ソースとは異なる、
請求項1に記載の方法。
【請求項２８】
リアルタイム通信セッションの間に喪失メディアの回復を選択的に試みるように構成されたユーザ機器(UE)であって、
前記UEに正しく到着しなかった、前記リアルタイム通信セッションに参加する別のUEからの喪失メディアパケットの存在を検出するための手段と、
複数の外部ソースから少なくとも1つの外部ソースを動的に選択しようと試みるために前記喪失メディアパケットに関連する回復基準値の組を評価するための手段であって、前記少なくとも1つの外部ソースから、前記喪失メディアパケットは、回復基準値の前記組に基づいて前記喪失メディアパケットの回復を試みるために様々な予測信頼性および/または応答時間において回復され得る可能性がある、手段と、
前記評価に基づいて前記選択された少なくとも1つの外部ソースから前記喪失メディアパケットを回復しようと試みるための手段と
を含む、ユーザ機器(UE)。
【請求項２９】
リアルタイム通信セッションの間に喪失メディアの回復を選択的に試みるように構成されたユーザ機器(UE)であって、
前記UEに正しく到着しなかった、前記リアルタイム通信セッションに参加する別のUEからの喪失メディアパケットの存在を検出するように構成された論理と、
複数の外部ソースから少なくとも1つの外部ソースを動的に選択しようと試みるために前記喪失メディアパケットに関連する回復基準値の組を評価するように構成された論理であって、前記少なくとも1つの外部ソースから、前記喪失メディアパケットは、回復基準値の前記組に基づいて前記喪失メディアパケットの回復を試みるために様々な予測信頼性および/または応答時間において回復され得る可能性がある、論理と、
前記評価に基づいて前記選択された少なくとも1つの外部ソースから前記喪失メディアパケットを回復しようと試みるように構成された論理と
を含む、ユーザ機器(UE)。
【請求項３０】
リアルタイム通信セッションの間に喪失メディアの回復を選択的に試みるように構成されたユーザ機器(UE)によって実行されるとき前記UEに動作を実行させる命令を記憶している、非一時的コンピュータ可読媒体であって、前記命令は、
前記UEに正しく到着しなかった、前記リアルタイム通信セッションに参加する別のUEからの喪失メディアパケットの存在を前記UEに検出させる少なくとも1つの命令と、
複数の外部ソースから少なくとも1つの外部ソースを動的に選択しようと試みるために前記喪失メディアパケットに関連する回復基準値の組を前記UEに評価させる少なくとも1つの命令であって、前記少なくとも1つの外部ソースから、前記喪失メディアパケットは、回復基準値の前記組に基づいて前記喪失メディアパケットの回復を試みるために様々な予測信頼性および/または応答時間において回復され得る可能性がある、命令と、
前記評価に基づいて前記選択された少なくとも1つの外部ソースから前記喪失メディアパケットを前記UEに回復を試みさせる少なくとも1つの命令と
を含む、非一時的コンピュータ可読媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
米国特許法第119条に基づく優先権の主張
本特許出願は、本出願の譲受人に譲渡され、全体が参照によって本明細書に明確に組み込まれる、本出願と同じ発明者による、2013年4月3日に出願された「OPPORTUNISTIC MEDIA PATCHING FOR A COMMUNICATION SESSION」と題する仮出願第61/807,955号の優先権を主張する。
【０００２】
本発明の実施形態は、通信セッションの間の機会主義的メディアパッチ適用(opportunistic media patching)に関する。
【背景技術】
【０００３】
ワイヤレス通信システムは、第1世代アナログワイヤレス電話サービス(1G)、第2世代(2G)デジタルワイヤレス電話サービス(暫定の2.5Gおよび2.75Gネットワークを含む)、第3世代(3G)および第4世代(4G)高速データ/インターネット対応ワイヤレスサービスを含む、様々な世代を通じて発展してきた。現在、セルラーシステムおよびパーソナル通信サービス(PCS)システムを含む、多くの様々なタイプのワイヤレス通信システムが使用されている。知られているセルラーシステムの例には、セルラーAnalog Advanced Mobile Phone System(AMPS)、および、符号分割多元接続(CDMA)、周波数分割多元接続(FDMA)、時分割多元接続(TDMA)、TDMAのGlobal System for Mobile access(GSM（登録商標）)変形に基づくデジタルセルラーシステム、および、TDMA技術とCDMA技術の両方を使用するより新しいハイブリッドデジタル通信システムがある。
【０００４】
つい最近、モバイル電話および他のデータ端末の高速データのワイヤレス通信用のワイヤレス通信プロトコルとして、ロングタームエボリューション(LTE)が開発されてきている。LTEは、GSM（登録商標）に基づいており、GSM（登録商標）進化型高速データレート(EDGE)などの様々なGSM（登録商標）関連のプロトコル、および高速パケットアクセス(HSPA)などのユニバーサルモバイル通信システム(UMTS)プロトコルからの寄与を含む。
【０００５】
上述の通信プロトコルのいずれかにおいて、ユーザ機器(UE)は、メディア(たとえば、オーディオメディア、ビデオメディアなど)が交換され「リアルタイム」で再生される、他のUEとの通信セッションに関わる可能性がある。リアルタイム通信セッションでは、時間(たとえば、1秒のうちのほんの10分の数秒)が経過したとき、メディアの価値は急激に落ちる。たとえば、通話中に受信されるオーディオパケットに含まれるオーディオデータ(たとえば、1つまたは複数のオーディオフレーム)は、通常、ターゲットUEによって受信された後、比較的早く(たとえば、100〜200msで)再生される必要があるか、または別様に、そのオーディオデータは、通話とは関連がなくなる。また、通話中にオーディオパケットが喪失される場合、喪失オーディオパケットを(たとえば、スピーカー、または通話のためのオーディオパケットを保管するサーバから)取り戻すのに比較的長い時間(たとえば、数秒)がかかる可能性がある。リアルタイム通信セッション中のパケット喪失を緩和するために、前方誤り訂正(FER)またはインターリーブなどの機構が使用される。しかしながら、リアルタイム通信セッション中にメディアパケット(上述の例のオーディオパケットなど)が喪失された場合、ターゲットUEは、通常、回復が試みられた場合に喪失メディアパケットに含まれたメディアがその最終的な到着時には関連がなくなるという見込みにより、リアルタイム通信セッションがこのメディアを回復しようと試みることなく続くことを可能にする。
【発明の概要】
【課題を解決するための手段】
【０００６】
ユーザ機器(UE)は、リアルタイム通信セッションの間に喪失メディアの回復を選択的に試みる。一実施形態では、UEは、UEに正しく到着しなかった、リアルタイム通信セッションに参加する別のUEからの喪失メディアパケットの存在を検出する。UEは、複数の外部ソースから少なくとも1つの外部ソースを動的に選択しようと試みるために喪失メディアパケットに関連する回復基準値の組を評価し、少なくとも1つの外部ソースから、喪失メディアパケットは、回復基準値の組に基づいて喪失メディアパケットの回復を試みるために様々な予測信頼性および/または応答時間において回復され得る可能性がある。UEは、この評価に基づいて選択された少なくとも1つの外部ソースから喪失メディアパケットを回復しようと試みる。
【０００７】
本発明の実施形態のより完全な理解、およびその付随する利点の多くは、以下の詳細な説明を添付の図面と併せ読んでよりよく理解すると、容易に得られる。添付の図面は、単に説明のために提示されているにすぎず、本発明を限定するものではない。
【図面の簡単な説明】
【０００８】
【図１】本発明の一実施形態によるワイヤレス通信システムのハイレベルシステムアーキテクチャを示す図である。
【図２Ａ】本発明の一実施形態による、無線アクセスネットワーク(RAN)、および1xEV-DOネットワーク用のコアネットワークのパケット交換部分の例示的な構成を示す図である。
【図２Ｂ】本発明の一実施形態による、RAN、および3G UMTS W-CDMA(登録商標)システム内の汎用パケット無線サービス(GPRS)コアネットワークのパケット交換部分の例示的な構成を示す図である。
【図２Ｃ】本発明の一実施形態による、RAN、および3G UMTS W-CDMA(登録商標)システム内のGPRSコアネットワークのパケット交換部分の別の例示的な構成を示す図である。
【図２Ｄ】本発明の一実施形態による、RAN、および進化型パケットシステム(EPS:Evolved Packet System)またはロングタームエボリューション(LTE)ネットワークに基づくコアネットワークのパケット交換部分の例示的な構成を示す図である。
【図２Ｅ】本発明の一実施形態による、EPSまたはLTEネットワークに接続された拡張型高速パケットデータ(HRPD)RAN、およびまたHRPDコアネットワークのパケット交換部分の例示的な構成を示す図である。
【図３】本発明の実施形態によるユーザ機器(UE)の例を示す図である。
【図４】本発明の一実施形態による、機能を実行するように構成された論理を含む通信デバイスを示す図である。
【図５】本発明の一実施形態によるサーバを示す図である。
【図６】送信側UEがターゲットUEにメディアを配信中であるアプリケーションサーバによって通信調停される従来のリアルタイム通信セッションを示す図である。
【図７】本発明の一実施形態による、1つまたは複数の他のUEとのリアルタイム通信セッションに関わるUEによって実施される喪失メディアパケット回復プロシージャを示す図である。
【図８】本発明の一実施形態による、送信側UEがターゲットUEにメディアを配信中であるアプリケーションサーバによって通信調停されるリアルタイム通信セッションを示す図である。
【図９Ａ】本発明の一実施形態による、図8のプロセスの続きを示す図である。
【図９Ｂ】本発明の一実施形態による、オーディオパケットに関して実行される図8および図9Aのプロセスの一部分を示す流れ図である。
【図１０Ａ】本発明の一実施形態による、図8のプロセスの続きを示す図である。
【図１０Ｂ】本発明の一実施形態による、図8のプロセスの続きを示す図である。
【図１０Ｃ】本発明の一実施形態による、図8のプロセスの続きを示す図である。
【図１０Ｄ】本発明の一実施形態による、図8のプロセスの続きを示す図である。
【発明を実施するための形態】
【０００９】
本発明の特定の実施形態を対象とする以下の説明および関連する図面において、本発明の態様が開示される。本発明の範囲から逸脱することなく、代替の実施形態が考案され得る。さらに、本発明の関連する詳細を不明瞭にしないように、本発明のよく知られている要素は詳細に説明されないか、または省略される。
【００１０】
「例示的」および/または「例」という言葉は、本明細書では「例、事例、または例示として機能すること」を意味するために使用される。本明細書で「例示的」および/または「例」として説明するいかなる実施形態も、必ずしも他の実施形態よりも好ましいまたは有利であると解釈されるべきではない。同様に、「本発明の実施形態」という用語は、本発明のすべての実施形態が、論じられた特徴、利点、または動作モードを含むことを必要としない。
【００１１】
さらに、多くの実施形態について、たとえばコンピューティングデバイスの要素によって実行されるべき、一連の動作に関して説明する。本明細書で説明する様々な動作は、特定の回路(たとえば、特定用途向け集積回路(ASIC))によって、1つもしくは複数のプロセッサによって実行されるプログラム命令によって、または両方の組合せによって実施され得ることを認識されよう。加えて、本明細書で説明するこれらの一連の動作は、実行時に、関連するプロセッサに本明細書で説明する機能を実施させるコンピュータ命令の対応するセットを記憶した、任意の形式のコンピュータ可読記憶媒体内で完全に具現化されるものと見なされ得る。したがって、本発明の様々な態様は、請求する主題の範囲内にすべて入ることが企図されているいくつかの異なる形式で具現化され得る。さらに、本明細書で説明する実施形態ごとに、任意のそのような実施形態の対応する形式について、本明細書では、たとえば、記載の動作を実行する「ように構成された論理」として説明することがある。
【００１２】
本明細書ではユーザ機器(UE)と呼ばれるクライアントデバイスは、モバイルであるか、または固定されている可能性があり、無線アクセスネットワーク(RAN)と通信し得る。本明細書で使用する「UE」という用語は、「アクセス端末」または「AT」、「ワイヤレスデバイス」、「加入者デバイス」、「加入者端末」、「加入者局」、「ユーザ端末」または「UT」、「モバイル端末」、「移動局」、およびそれらの変形形態と互換的に参照され得る。一般に、UEは、RANを介してコアネットワークと通信する可能性があり、コアネットワークを介してインターネットなどの外部ネットワークに接続され得る。当然、UEには、有線アクセスネットワーク、(たとえば、IEEE 802.11などに基づく)WiFiネットワークなどの、コアネットワークおよび/またはインターネットに接続する他の機構も考えられる。UEは、限定はしないが、PCカード、コンパクトフラッシュ（登録商標）デバイス、外付けもしくは内蔵のモデム、またはワイヤレスもしくは有線の電話などを含むいくつかのタイプのデバイスのうちの任意のものによって具体化され得る。UEが信号をRANに送信し得る通信リンクは、アップリンクチャネル(たとえば、逆方向トラフィックチャネル、逆方向制御チャネル、アクセスチャネルなど)と呼ばれる。RANが信号をUEに送信し得る通信リンクは、ダウンリンクチャネルまたは順方向リンクチャネル(たとえば、ページングチャネル、制御チャネル、ブロードキャストチャネル、順方向トラフィックチャネルなど)と呼ばれる。本明細書で使用される場合、トラフィックチャネル(TCH)という用語は、アップリンク/逆方向トラフィックチャネル、またはダウンリンク/順方向トラフィックチャネルのいずれかを指し得る。
【００１３】
図1は、本発明の一実施形態によるワイヤレス通信システム100のハイレベルシステムアーキテクチャを示す。ワイヤレス通信システム100はUE1...Nを含む。UE1...Nは、携帯電話、携帯情報端末(PDA)、ページャ、ラップトップコンピュータ、デスクトップコンピュータなどを含み得る。たとえば、図1において、UE1...2は発呼側携帯電話として示され、UE3...5はタッチスクリーン携帯電話またはスマートフォンとして示され、UENはデスクトップコンピュータまたはPCとして示されている。
【００１４】
図1を参照すると、UE1...Nは、図1にエアインターフェース104、106、108および/または直接有線接続として示されている物理通信インターフェースまたはレイヤを介してアクセスネットワーク(たとえば、RAN120、アクセスポイント125など)と通信するように構成される。エアインターフェース104および106は、所与のセルラー通信プロトコル(たとえば、CDMA、EVDO、eHRPD、GSM(登録商標)、EDGE、W-CDMA(登録商標)、LTEなど)に準拠し得るが、エアインターフェース108は、ワイヤレスIPプロトコル(たとえば、IEEE802.11)に準拠し得る。RAN120は、エアインターフェース104および106などのエアインターフェースを介してUEにサービスする複数のアクセスポイントを含む。RAN120内のアクセスポイントは、アクセスノードまたはAN、アクセスポイントまたはAP、基地局またはBS、ノードB、eノードBなどと呼ばれ得る。これらのアクセスポイントは、地上アクセスポイント(もしくは地上局)または衛星アクセスポイントであり得る。RAN120は、RAN120によってサービスされるUEとRAN120または異なるRANによってサービスされる他のUEとの間の回線交換(CS)呼を完全にブリッジングすることを含む様々な機能を実行することができ、かつインターネット175などの外部ネットワークとのパケット交換(PS)データの交換を仲介することもできるコアネットワーク140に接続するように構成される。インターネット175は、いくつかのルーティングエージェントおよび処理エージェント(便宜上図1には示されていない)を含む。図1において、UENはインターネット175に直接接続する(すなわち、WiFiまたは802.11ベースネットワークのイーサネット(登録商標)接続を介するなど、コアネットワーク140から分離される)ように示されている。それによって、インターネット175は、コアネットワーク140を介してUENとUE1...Nとの間のパケット交換データ通信をブリッジングするように機能し得る。図1には、RAN120から分離されたアクセスポイント125も示されている。アクセスポイント125は、コアネットワーク140とは無関係に(たとえば、FiOS、ケーブルモデムなどの光通信システムを介して)インターネット175に接続され得る。エアインターフェース108は、一例ではIEEE 802.11などのローカルワイヤレス接続を介してUE4またはUE5にサービスし得る。UENは、一例では(たとえば、有線接続性とワイヤレス接続性の両方を有するWiFiルータ用の)アクセスポイント125自体に相当する可能性があるモデムまたはルータとの直接接続などのインターネット175との有線接続を含むデスクトップコンピュータとして示されている。
【００１５】
図1を参照すると、アプリケーションサーバ170は、インターネット175、コアネットワーク140、またはその両方に接続されるように示されている。アプリケーションサーバ170は、構造的に分離された複数のサーバとして実装され得るか、または代替として単一のサーバに相当し得る。以下により詳しく説明するように、アプリケーションサーバ170は、コアネットワーク140および/またはインターネット175を介してアプリケーションサーバ170に接続することのできるUEについて1つまたは複数の通信サービス(たとえば、Voice-over-Internet Protocol(VoIP)セッション、Push-to-Talk(PTT)セッション、グループ通信セッション、ソーシャルネットワーキングサービスなど)をサポートするように構成される。
【００１６】
ワイヤレス通信システム100をより詳細に説明するのを助けるために、RAN120およびコアネットワーク140に関するプロトコル固有の実装形態の例を図2A〜図2Dに関して以下に提供する。詳細には、RAN120およびコアネットワーク140の構成要素は、パケット交換(PS)通信をサポートすることに関連する構成要素に対応し、従来の回線交換(CS)構成要素もこれらのネットワーク内に存在し得るが、図2A〜図2Dには、いずれの従来のCS固有の構成要素も明示的に示さない。
【００１７】
図2Aは、本発明の一実施形態による、RAN120、およびCDMA2000 1xエボリューションデータオプティマイズド(EV-DO)ネットワークにおけるパケット交換通信用のコアネットワーク140の例示的な構成を示す。図2Aを参照すると、RAN120は、有線バックホールインターフェースを介して基地局コントローラ(BSC)215Aに結合される複数の基地局(BS)200A、205A、および210Aを含む。単一のBSCによって制御されるBSのグループは、サブネットと総称される。当業者なら諒解するように、RAN120は、複数のBSCおよびサブネットを含むことができるが、便宜上、図2Aには単一のBSCを示す。BSC215Aは、コアネットワーク140内でA9接続を介してパケット制御機能(PCF)220Aと通信する。PCF220Aは、パケットデータに関連するBSC215Aのためのいくつかの処理機能を実行する。PCF220Aは、コアネットワーク140内でA11接続を介してパケットデータサービングノード(PDSN)225Aと通信する。PDSN225Aは、ポイントツーポイント(PPP)セッションを管理すること、ホームエージェント(HA)および/または外部エージェント(FA)として機能することを含む様々な機能を有し、(以下でより詳細に説明するように)GSM(登録商標)ネットワークおよびUMTSネットワークにおけるゲートウェイ汎用パケット無線サービス(GPRS)サポートノード(GGSN)と機能的に同様である。PDSN225Aは、コアネットワーク140をインターネット175などの外部IPネットワークに接続する。
【００１８】
図2Bは、本発明の一実施形態による、RAN120、および3G UMTS W-CDMA(登録商標)システム内のGPRSコアネットワークとして構成されたコアネットワーク140のパケット交換部分の例示的な構成を示す。図2Bを参照すると、RAN120は、有線バックホールインターフェースを介して無線ネットワークコントローラ(RNC)215Bに結合される複数のノードB 200B、205B、および210Bを含む。1xEV-DOネットワークと同様に、単一のRNCによって制御されるノードBのグループは、サブネットと総称される。当業者なら諒解するように、RAN120は、複数のRNCおよびサブネットを含むことができるが、便宜上、図2Bには単一のRNCを示す。RNC215Bは、コアネットワーク140内のサービングGRPSサポートノード(SGSN)220Bと、RAN120によってサービスされるUEとの間で、シグナリングし、ベアラチャネル(すなわち、データチャネル)を確立し、それを切断することを担う。また、リンクレイヤ暗号化が可能な場合、RNC215Bは、エアインターフェースを介する送信のためにコンテンツをRAN120に転送する前に、コンテンツを暗号化する。RNC215Bの機能は、当技術分野でよく知られており、簡潔にするためこれ以上は説明しない。
【００１９】
図2Bでは、コアネットワーク140は、上述のSGSN220B(およびいくつかの他のSGSNも含む可能性がある)およびGGSN225Bを含む。一般に、GPRSは、IPパケットをルーティングするための、GSM(登録商標)に使用されるプロトコルである。GPRSコアネットワーク(たとえば、GGSN225Bおよび1つまたは複数のSGSN220B)は、GPRSシステムの中心部分であり、W-CDMA(登録商標)ベースの3Gアクセスネットワークのサポートも提供する。GPRSコアネットワークは、GSM(登録商標)およびW-CDMA(登録商標)ネットワークにおけるIPパケットサービスのモビリティ管理、セッション管理、およびトランスポートを提供する、GSM(登録商標)コアネットワーク(すなわち、コアネットワーク140)の一体化された部分である。
【００２０】
GPRSトンネリングプロトコル(GTP)は、GPRSコアネットワークを特徴付けるIPプロトコルである。GTPは、GGSN225Bにおいて、1つの位置からインターネット175に接続し続けているかのようにしながら、GSM(登録商標)またはW-CDMA(登録商標)ネットワークのエンドユーザ(たとえば、UE)が方々に移動することを可能にするプロトコルである。これは、UEの現在のSGSN220Bから、それぞれのUEのセッションを処理しているGGSN225BにそれぞれのUEのデータを転送することによって達成される。
【００２１】
GTPの3つの形態、すなわち(i)GTP-U、(ii)GTP-C、および(iii)GTP'(GTP Prime)がGPRSコアネットワークによって使用される。GTP-Uは、パケットデータプロトコル(PDP)コンテキストごとに分離されたトンネルでのユーザデータの転送に使用される。GTP-Cは、制御シグナリング(たとえば、PDPコンテキストのセットアップおよび削除、GSN到達可能性の検証、加入者があるSGSNから別のSGSNに移動した場合などの更新または変更など)に使用される。GTP'は、GSNから課金機能への課金データの転送に使用される。
【００２２】
図2Bを参照すると、GGSN225Bは、GPRSバックボーンネットワーク(図示せず)とインターネット175との間のインターフェースとして機能する。GGSN225Bは、関連するパケットデータプロトコル(PDP)形式(たとえば、IPまたはPPP)のパケットデータを、SGSN220Bから来るGPRSパケットから抽出し、対応するパケットデータネットワーク上でパケットを送出する。反対方向において、着信データパケットは、GGSNによってSGSN220Bに接続されたUEに向けられ、SGSN220Bは、RAN120によってサービスされるターゲットUEの無線アクセスベアラ(RAB)を管理および制御する。それによって、GGSN225Bは、ターゲットUEの現在のSGSNアドレスおよびその関連のプロファイルをロケーションレジスタ(たとえば、PDPコンテキスト内)に記憶する。GGSN225Bは、IPアドレス割当てを担い、接続されたUEのデフォルトのルータである。また、GGSN225Bは、認証および課金機能を実行する。
【００２３】
一例では、SGSN220Bは、コアネットワーク140内の多くのSGSNのうちの1つの代表である。各SGSNは、関連する地理的サービスエリア内で、UEとの間でのデータパケットの配信を担う。SGSN220Bのタスクには、パケットルーティングおよび転送、モビリティ管理(たとえば、接続/切断およびロケーション管理)、論理リンク管理、ならびに認証機能および課金機能が含まれる。SGSN220Bのロケーションレジスタは、位置情報(たとえば、現在のセル、現在のVLR)、および、SGSN220Bに登録されたすべてのGPRSユーザのユーザプロファイル(たとえば、パケットデータネットワークで使用されるIMSI、PDPアドレス)を、たとえばユーザまたはUEごとに1つまたは複数のPDPコンテキスト内に記憶する。したがって、SGSN220Bは、(i)GGSN225BからのダウンリンクGTPパケットの逆トンネリング、(ii)GGSN225Bに向かうIPパケットのアップリンクトンネリング、(iii)UEがSGSNサービスエリアの間を移動するときのモビリティ管理の実行、(iv)モバイル加入者の支払い請求を担う。当業者が諒解するように、(i)〜(iv)の他に、GSM(登録商標)/EDGEネットワークのために構成されたSGSNは、W-CDMA(登録商標)ネットワークのために構成されたSGSNと比較して、わずかに異なる機能を有する。
【００２４】
RAN120(または、たとえば、UMTSシステムアーキテクチャにおけるUTRAN)は、Radio Access Network Application Part(RANAP)プロトコルを介して、SGSN220Bと通信する。RANAPは、Iuインターフェース(Iu-ps)を介して、フレームリレーまたはIPなどの伝送プロトコルとともに動作する。SGSN220Bは、SGSN220Bおよび他のSGSN(図示せず)と内部のGGSN(図示せず)との間のIPベースのインターフェースであり、上記で定義されたGTPプロトコル(たとえば、GTP-U、GTP-C、GTP'など)を使用する、Gnインターフェースを介してGGSN225Bと通信する。図2Bの実施形態では、SGSN220BとGGSN225Bとの間のGnは、GTP-CとGTP-Uの両方を搬送する。図2Bには示されないが、Gnインターフェースは、ドメイン名システム(DNS)によっても使用される。GGSN225Bは、公衆データネットワーク(PDN)(図示せず)に、次にインターネット175に、IPプロトコルによるGiインターフェースを介して直接、またはワイヤレスアプリケーションプロトコル(WAP)ゲートウェイを介して接続される。
【００２５】
図2Cは、本発明の一実施形態による、RAN120、および3G UMTS W-CDMA(登録商標)システム内のGPRSコアネットワークとして構成されたコアネットワーク140のパケット交換部分の別の例示的な構成を示す。図2Bと同様に、コアネットワーク140は、SGSN220BおよびGGSN225Bを含む。しかしながら、図2Cでは、ダイレクトトンネルは、SGSN220Bが、PSドメイン内のRAN120とGGSN225Bとの間のダイレクトユーザプレーントンネル、GTP-Uを確立することを可能にする、Iuモードにおける任意選択の機能である。図2CのSGSN220Bなどのダイレクトトンネル対応SGSNは、SGSN220Bがダイレクトユーザプレーン接続を使用できるかどうかにかかわらず、GGSN単位およびRNC単位で構成され得る。図2CのSGSN220Bは、制御プレーンシグナリングを処理し、ダイレクトトンネルをいつ確立するべきかの決定を行う。PDPコンテキストに割り当てられたRABが解放される(すなわち、PDPコンテキストが保たれる)とき、ダウンリンクパケットの処理を可能にするために、GGSN225BとSGSN220Bとの間にGTP-Uトンネルが確立される。
【００２６】
図2Dは、本発明の一実施形態による、RAN120、および進化型パケットシステム(EPS)またはLTEネットワークに基づくコアネットワーク140のパケット交換部分の例示的な構成を示す。図2Dを参照すると、図2B〜図2Cに示すRAN120と異なり、EPS/LTEネットワーク内のRAN120は、図2B〜図2CのRNC215Bなしに、複数の発展型ノードB(EノードBまたはeNB)200D、205D、および210Dとともに構成される。これは、EPS/LTEネットワーク内のEノードBは、コアネットワーク140と通信するためにRAN120内に別個のコントローラ(すなわち、RNC215B)を必要としないからである。言い換えれば、図2B〜図2CのRNC215Bの機能のいくつかは、図2DのRAN120のそれぞれのeノードBに内蔵される。
【００２７】
図2Dでは、コアネットワーク140は、複数のモビリティ管理エンティティ(MME)215Dおよび220D、ホーム加入者サーバ(HSS)225D、サービングゲートウェイ(S-GW)230D、パケットデータネットワークゲートウェイ(P-GW)235D、ならびにポリシーおよび課金ルール機能(PCRF)240Dを含む。これらの構成要素、RAN120、およびインターネット175間のネットワークインターフェースは、図2Dに示され、(下記の)Table 1(表1)に次のように定義される。
【００２８】
【表１】
2016524352.tif 000003
【００２９】
ここで、図2DのRAN120およびコアネットワーク140に示される構成要素のハイレベル記述について説明する。しかしながら、これらの構成要素は各々、様々な3GPP TS規格により当技術分野でよく知られており、本明細書に含まれる記述は、これらの構成要素によって実行されるすべての機能の網羅的な記述となることを意図しない。
【００３０】
図2Dを参照すると、MME215Dおよび220Dは、EPSベアラの制御プレーンシグナリングを管理するように構成される。MME機能は、非アクセス層(NAS)シグナリング、NASシグナリングセキュリティ、インター技術ハンドオーバおよびイントラ技術ハンドオーバのモビリティ管理、P-GWおよびS-GW選択、ならびにMME変更を伴うハンドオーバに関するMME選択を含む。
【００３１】
図2Dを参照すると、S-GW230Dは、RAN120の方へのインターフェースの終端にあるゲートウェイである。EPSベースのシステムのコアネットワーク140に関連するUEごとに、所与の時点において単一のS-GWが存在する。GTPベースおよびプロキシモバイルIPv6(PMIP)ベースの両S5/S8に関して、S-GW230Dの機能は、モビリティアンカーポイント、パケットルーティングおよび転送、ならびに関連のEPSベアラのQoSクラス識別子(QCI)に基づくDiffServ Code Point(DSCP)の設定を含む。
【００３２】
図2Dを参照すると、P-GW235Dは、パケットデータネットワーク(PDN)、たとえばインターネット175の方へのSGiインターフェースの終端にあるゲートウェイである。UEが複数のPDNにアクセスしている場合、そのUEのために2つ以上のP-GWが存在し得るが、S5/S8接続とGn/Gp接続との混合は、通常、そのUEに関して同時にサポートされない。P-GW機能は、GTPベースの両S5/S8に関して、(ディープパケット検査による)パケットフィルタリング、UE IPアドレス割当て、関連のEPSベアラのQCIに基づくDSCPの設定、オペレータ間の課金のためのアカウンティング、3GPP TS23.203に定義されたアップリンク(UL)およびダウンリンク(DL)ベアラバインディング、3GPP TS23.203に定義されたULベアラバインディング検証を含む。P-GW235Dは、E-UTRAN、GSM(登録商標)/EDGE無線アクセスネットワーク(GERAN)、またはUTRANのいずれかを使用して、GERAN/UTRAN専用UEとE-UTRAN対応UEの両方へのPDN接続を提供する。P-GW235Dは、E-UTRANを使用してS5/S8インターフェースのみを介してE-UTRAN対応UEへのPDN接続を提供する。
【００３３】
図2Dを参照すると、PCRF240Dは、EPSベースのコアネットワーク140のポリシーおよび課金制御要素である。非ローミングシナリオでは、UEのインターネットプロトコル接続アクセスネットワーク(IP-CAN)セッションに関連するHPLMN内に単一のPCRFが存在する。PCRFは、RxインターフェースおよびGxインターフェースの終端にある。トラフィックのローカルブレークアウトを伴うローミングシナリオでは、UEのIP-CANセッションに関連する2つのPCRFが存在し得る。ホームPCRF(H-PCRF)は、HPLMN内に存在するPCRFであり、訪問先PCRF(V-PCRF)は、訪問先VPLMN内に存在するPCRFである。PCRFは、3GPP TS23.203により詳細に記載されており、したがって、簡潔のためにさらに説明しない。図2Dでは、アプリケーションサーバ170(たとえば、3GPP専門用語においてAFと呼ばれ得る)は、インターネット175を介してコアネットワーク140に、または代替としてRxインターフェースを介して直接PCRF240Dに接続されるように示される。一般に、アプリケーションサーバ170(すなわちAF)は、コアネットワークによりIPベアラリソース(たとえば、UMTS PSドメイン/GPRSドメインリソース/LTE PSデータサービス)を使用するアプリケーションを提供する要素である。アプリケーション機能の一例は、IPマルチメディアサブシステム(IMS)コアネットワークサブシステムのプロキシ呼セッション制御機能(P-CSCF)である。AFは、PCRF240Dにセッション情報を提供するためにRx参照点を使用する。セルラーネットワークを介してIPデータサービスを提供する他のいかなるアプリケーションサーバも、Rx参照点を介してPCRF240Dに接続され得る。
【００３４】
図2Eは、本発明の一実施形態による、EPSまたはLTEネットワーク140Aに接続された拡張型高速パケットデータ(HRPD)RANとして構成されたRAN120、およびまたHRPDコアネットワーク140Bのパケット交換部分の一例を示す。コアネットワーク140Aは、図2Dに関して上記で説明したコアネットワークと同様に、EPSまたはLTEコアネットワークである。
【００３５】
図2Eでは、eHRPD RANは、拡張型BSC(eBSC)および拡張型PCF(ePCF)215Eに接続された、複数のトランシーバ基地局(BTS)200E、205E、および210Eを含む。eBSC/ePCF215Eは、S101インターフェースを介してEPSコアネットワーク140A内のMME215Dまたは220Dのうちの1つに接続し、EPSコアネットワーク140A内の他のエンティティとインターフェースするためのA10および/またはA11インターフェースを介してHRPDサービングゲートウェイ(HSGW)220Eに(たとえば、S103インターフェースを介してS-GW220Dに、S2aインターフェースを介してP-GW235Dに、Gxaインターフェースを介してPCRF240Dに、STaインターフェースを介して3GPP AAAサーバ(図2Dには明示的に示さず)に、など)接続し得る。HSGW220Eは、HRPDネットワークとEPS/LTEネットワークとの間に相互動作を提供するために3GPP2に定義される。諒解されるように、eHRPD RANおよびHSGW 220Eは、従来のHRPDネットワークで利用可能でないEPC/LTEネットワークへのインターフェース機能で構成される。
【００３６】
再びeHRPD RANを参照すると、EPS/LTEネットワーク140Aとのインターフェースに加えて、eHRPD RANは、HRPDネットワーク140Bなどの従来のHRPDネットワークとインターフェースすることもできる。諒解されるように、HRPDネットワーク140Bは、図2AのEV-DOネットワークなどの従来のHRPDネットワークの例示的な実装形態である。たとえば、eBSC/ePCF215Eは、A12インターフェースを介して認証、許可、およびアカウンティング(AAA)サーバ225Eと、A10またはA11インターフェースを介してPDSN/FA230Eとインターフェースすることができる。PDSN/FA230Eは、次に、HA235Eに接続し、それによって、インターネット175にアクセスし得る。図2Eでは、いくつかのインターフェース(たとえば、A13、A16、H1、H2など)が明示的に記載されていないが、完全に示されており、HRPDまたはeHRPDに精通している当業者には理解されよう。
【００３７】
図2B〜図2Eを参照すると、LTEコアネットワーク(たとえば、図2D)、ならびにeHRPD RANおよびHSGWとインターフェースするHRPDコアネットワーク(たとえば、図2E)は、場合によっては、(たとえば、P-GW、GGSN、SGSNなどによって)ネットワーク主導型サービス品質(QoS)をサポートし得ることが諒解されよう。
【００３８】
図3は、本発明の実施形態によるUEの例を示す。図3を参照すると、UE300Aは発呼側電話として示され、UE300Bはタッチスクリーンデバイス(たとえば、スマートフォン、タブレットコンピュータなど)として示されている。図3に示すように、UE300Aの外部ケーシングは、当技術分野で知られているように、特に、アンテナ305A、ディスプレイ310A、少なくとも1つのボタン315A(たとえば、PTTボタン、電源ボタン、音量調節ボタンなど)、キーパッド320Aなどの構成要素で構成される。また、UE300Bの外部ケーシングは、当技術分野で知られているように、特に、タッチスクリーンディスプレイ305B、周辺ボタン310B、315B、320B、および325B(たとえば、電力制御ボタン、音量または振動制御ボタン、飛行機モードトグルボタンなど)、少なくとも1つのフロントパネルボタン330B(たとえば、Homeボタンなど)などの構成要素で構成される。UE300Bの一部として明示的に示されてはいないが、UE300Bは、限定はしないが、WiFiアンテナ、携帯アンテナ、衛星位置システム(SPS)アンテナ(たとえば全地球測位システム(GPS)アンテナ)などを含む1つもしくは複数の外部アンテナおよび/またはUE300Bの外部ケーシングに内蔵された1つもしくは複数の集積アンテナを含み得る。
【００３９】
UE300AおよびUE300BなどのUEの内部構成要素は、それぞれに異なるハードウェア構成によって具体化され得るが、内部ハードウェア構成要素のための基本的なハイレベルUE構成は図3にプラットフォーム302として示されている。プラットフォーム302は、最終的にコアネットワーク140、インターネット175、ならびに/または他のリモートサーバおよびネットワーク(たとえば、アプリケーションサーバ170、ウェブURLなど)から得ることのできるRAN120から送信されたソフトウェアアプリケーション、データ、および/またはコマンドを受信し実行し得る。プラットフォーム302は、ローカルに記憶されたアプリケーションをRAN対話なしに独立して実行することもできる。プラットフォーム302は、特定用途向け集積回路(ASIC)308もしくは他のプロセッサ、マイクロプロセッサ、論理回路、または他のデータ処理デバイスに動作可能に結合されたトランシーバ306を含み得る。ASIC308または他のプロセッサは、ワイヤレスデバイスのメモリ312中の任意の常駐プログラムとインターフェースするアプリケーションプログラミングインターフェース(API)310レイヤを実行する。メモリ312は、読取り専用またはランダムアクセスメモリ(RAMおよびROM)、EEPROM、フラッシュカード、またはコンピュータプラットフォームに共通の任意のメモリから構成され得る。プラットフォーム302は、メモリ312中でアクティブに使用されないアプリケーションおよび他のデータを記憶し得るローカルデータベース314も含み得る。ローカルデータベース314は、一般的にフラッシュメモリセルであるが、磁気媒体、EEPROM、光学媒体、テープ、ソフトまたはハードディスクなどの、当技術分野で知られている任意の二次記憶デバイスであり得る。
【００４０】
したがって、本発明の一実施形態は、本明細書で説明する機能を実行する能力を含むUE(たとえば、UE300A、300Bなど)を含み得る。当業者が諒解するように、様々な論理要素は、本明細書で開示する機能を達成するために、個別の要素、プロセッサ上で実行されるソフトウェアモジュール、またはソフトウェアとハードウェアとの任意の組合せで具体化され得る。たとえば、ASIC308、メモリ312、API310およびローカルデータベース314をすべて協働的に使用して、本明細書で開示する様々な機能をロード、記憶および実行し得、したがって、これらの機能を実行する論理を様々な要素に分散し得る。代替として、機能は1つの個別構成要素に組み込まれ得る。したがって、図3のUE300Aおよび300Bの特徴は例示的なものにすぎないと見なすべきであり、本発明は図示の特徴または構成に制限されない。
【００４１】
UE300Aおよび/または300BとRAN120との間のワイヤレス通信は、CDMA、W-CDMA(登録商標)、時分割多元接続(TDMA)、周波数分割多元接続(FDMA)、直交周波数分割多重化(OFDM)、GSM(登録商標)、またはワイヤレス通信ネットワークもしくはデータ通信ネットワークで使用され得る他のプロトコルなどの、様々な技術に基づき得る。上記で説明され、当技術分野で知られているように、音声送信、および/またはデータは、様々なネットワークおよび構成を使用してRANからUEに送信され得る。したがって、本明細書で提供する例は、本発明の実施形態を限定するためのものではなく、単に本発明の実施形態の態様の説明を助けるためのものにすぎない。
【００４２】
図4は、機能を実行するように構成された論理を含む通信デバイス400を示す。通信デバイス400は、限定はしないが、UE300Aもしくは300B、RAN120の任意の構成要素(たとえば、BS200A〜210A、BSC215A、ノードB200B〜210B、RNC215B、eノードB200D〜210Dなど)、コアネットワーク140の任意の構成要素(たとえば、PCF220A、PDSN225A、SGSN220B、GGSN225B、MME215Dもしくは220D、HSS225D、S-GW230D、P-GW235D、PCRF240D)、コアネットワーク140に結合される任意の構成要素、および/またはインターネット175(たとえば、アプリケーションサーバ170)などを含む、上述の通信デバイスのうちのいずれかに対応し得る。したがって、通信デバイス400は、図1のワイヤレス通信システム100を介して1つまたは複数の他のエンティティと通信する(または通信を容易にする)ように構成された任意の電子デバイスに対応し得る。
【００４３】
図4を参照すると、通信デバイス400は、情報を受信および/または送信するように構成された論理405を含む。一例では、通信デバイス400がワイヤレス通信デバイス(たとえば、UE300Aまたは300B、BS200A〜210Aのうちの1つ、ノードB200B〜210Bのうちの1つ、eノードB200D〜210Dのうちの1つなど)に対応する場合、情報を受信および/または送信するように構成された論理405は、ワイヤレストランシーバおよび関連のハードウェア(たとえば、RFアンテナ、モデム、変調器および/または復調器など)などのワイヤレス通信インターフェース(たとえば、Bluetooth(登録商標)、WiFi、2G、CDMA、W-CDMA(登録商標)、3G、4G、LTEなど)を含み得る。別の例では、情報を受信および/または送信するように構成された論理405は、有線通信インターフェース(たとえば、インターネット175にアクセスし得るシリアル接続、USBまたはファイアワイヤ接続、イーサネット(登録商標)接続など)に対応し得る。したがって、通信デバイス400が、何らかのタイプのネットワークベースのサーバ(たとえば、PDSN、SGSN、GGSN、S-GW、P-GW、MME、HSS、PCRF、アプリケーションサーバ170など)に対応する場合、情報を受信および/または送信するように構成された論理405は、一例では、イーサネット(登録商標)プロトコルを介してネットワークベースのサーバを他の通信エンティティに接続するイーサネット(登録商標)カードに対応し得る。さらなる例では、情報を受信および/または送信するように構成された論理405は、通信デバイス400がそのローカル環境を監視し得る感知または測定ハードウェア(たとえば、加速度計、温度センサー、光センサー、ローカルRF信号を監視するためのアンテナなど)を含み得る。情報を受信および/または送信するように構成された論理405は、実行されると、情報を受信および/または送信するように構成された論理405の関連ハードウェアがその受信および/または送信機能を実行することを可能にする、ソフトウェアも含み得る。しかしながら、情報を受信および/または送信するように構成された論理405は、ソフトウェア単体に対応せず、情報を受信および/または送信するように構成された論理405は、その機能を達成するためのハードウェアに少なくとも部分的に依拠する。
【００４４】
図4を参照すると、通信デバイス400は、情報を処理するように構成された論理410をさらに含む。一例では、情報を処理するように構成された論理410は、少なくともプロセッサを含み得る。情報を処理するように構成された論理410によって実行され得るタイプの処理の例示的な実装形態は、限定はしないが、判断を行うこと、接続を確立すること、異なる情報オプション間で選択を行うこと、データに関連する評価を行うこと、測定操作を実行するために通信デバイス400に結合されたセンサーと対話すること、情報をあるフォーマットから別のフォーマットに(たとえば、.wmvから.aviへなど、異なるプロトコル間で)変換することなどを含む。たとえば、情報を処理するように構成された論理410中に含まれるプロセッサは、汎用プロセッサ、デジタル信号プロセッサ(DSP)、ASIC、フィールドプログラマブルゲートアレイ(FPGA)もしくは他のプログラマブル論理デバイス、個別ゲートもしくはトランジスタ論理、個別ハードウェア構成要素、または本明細書で説明する機能を実行するように設計されたそれらの任意の組合せに対応し得る。汎用プロセッサはマイクロプロセッサであり得るが、代替として、プロセッサは任意の従来のプロセッサ、コントローラ、マイクロコントローラ、または状態機械であり得る。プロセッサはまた、コンピューティングデバイスの組合せ、たとえば、DSPおよびマイクロプロセッサの組合せ、複数のマイクロプロセッサ、DSPコアと連携する1つもしくは複数のマイクロプロセッサ、または任意の他のそのような構成として実装され得る。情報を処理するように構成された論理410は、実行されると、情報を処理するように構成された論理410の関連ハードウェアがその処理機能を実行することを可能にする、ソフトウェアも含み得る。しかしながら、情報を処理するように構成された論理410は、ソフトウェア単体に対応せず、情報を処理するように構成された論理410は、その機能を達成するためのハードウェアに少なくとも部分的に依拠する。
【００４５】
図4を参照すると、通信デバイス400は、情報を記憶するように構成された論理415をさらに含む。一例では、情報を記憶するように構成された論理415は、少なくとも非一時的メモリおよび関連ハードウェア(たとえば、メモリコントローラなど)を含み得る。たとえば、情報を記憶するように構成された論理415に含まれる非一時的メモリは、RAMメモリ、フラッシュメモリ、ROMメモリ、EPROMメモリ、EEPROMメモリ、レジスタ、ハードディスク、リムーバブルディスク、CD-ROM、または当技術分野で知られている任意の他の形態の記憶媒体に対応し得る。情報を記憶するように構成された論理415は、実行されると、情報を記憶するように構成された論理415の関連ハードウェアがその記憶機能を実行することを可能にするソフトウェアも含み得る。しかしながら、情報を記憶するように構成された論理415は、ソフトウェア単体に対応せず、情報を記憶するように構成された論理415は、その機能を達成するためのハードウェアに少なくとも部分的に依拠する。
【００４６】
図4を参照すると、通信デバイス400は、場合によっては、情報を提示するように構成された論理420をさらに含む。一例では、情報を提示するように構成された論理420は、少なくとも出力デバイスおよび関連ハードウェアを含み得る。たとえば、出力デバイスは、ビデオ出力デバイス(たとえば、ディスプレイ画面、USB、HDMI(登録商標)などの、ビデオ情報を搬送することができるポートなど)、オーディオ出力デバイス(たとえば、スピーカー、マイクロフォンジャック、USB、HDMI(登録商標)などの、オーディオ情報を搬送することができるポートなど)、振動デバイス、および/あるいは情報が出力のためにフォーマットされるか、または通信デバイス400のユーザもしくはオペレータによって実際に出力され得る任意の他のデバイスを含み得る。たとえば、通信デバイス400が図3に示すようにUE300AまたはUE300Bに相当する場合、情報を提示するように構成された論理420は、UE300Aのディスプレイ310AまたはUE300Bのタッチスクリーンディスプレイ305Bを含み得る。さらなる例では、情報を提示するように構成された論理420は、ローカルユーザを有しないネットワーク通信デバイス(たとえば、ネットワークスイッチまたはルータ、リモートサーバなど)などのいくつかの通信デバイスでは省略されることがある。情報を提示するように構成された論理420は、実行されると、情報を提示するように構成された論理420の関連ハードウェアが提示機能を実行することを可能にする、ソフトウェアも含み得る。しかしながら、情報を提示するように構成された論理420は、ソフトウェア単体に対応せず、情報を提示するように構成された論理420は、その機能を達成するためのハードウェアに少なくとも部分的に依拠する。
【００４７】
図4を参照すると、通信デバイス400は、場合によっては、ローカルユーザ入力を受信するように構成された論理425をさらに含む。一例では、ローカルユーザ入力を受信するように構成された論理425は、少なくともユーザ入力デバイスおよび関連ハードウェアを含み得る。たとえば、ユーザ入力デバイスは、ボタン、タッチスクリーンディスプレイ、キーボード、カメラ、オーディオ入力デバイス(たとえば、マイクロフォン、またはマイクロフォンジャックなどのオーディオ情報を搬送することができるポートなど)、および/または情報が通信デバイス400のユーザもしくはオペレータから受信され得る任意の他のデバイスを含み得る。たとえば、通信デバイス400が図3に示すようにUE300AまたはUE300Bに相当する場合、ローカルユーザ入力を受信するように構成された論理425は、キーパッド320A、ボタン315Aまたは310B〜325Bのうちのいずれか、タッチスクリーンディスプレイ305Bなどを含み得る。さらなる例では、ローカルユーザ入力を受信するように構成された論理425は、ローカルユーザを有しないネットワーク通信デバイス(たとえば、ネットワークスイッチまたはルータ、リモートサーバなど)などのいくつかの通信デバイスでは省略されることがある。ローカルユーザ入力を受信するように構成された論理425は、実行されると、ローカルユーザ入力を受信するように構成された論理425の関連ハードウェアがその入力受信機能を実行することを可能にする、ソフトウェアも含み得る。しかしながら、ローカルユーザ入力を受信するように構成された論理425は、ソフトウェア単体に対応せず、ローカルユーザ入力を受信するように構成された論理425は、その機能を達成するためのハードウェアに少なくとも部分的に依拠する。
【００４８】
図4を参照すると、405〜425の構成された論理は、図4では別個のまたは相異なるブロックとして示されているが、それぞれの構成された論理がその機能を実行するハードウェアおよび/またはソフトウェアは、部分的に重複し得ることが諒解されよう。たとえば、405〜425の構成された論理の機能を容易にするために使用されるいずれのソフトウェアも、情報を記憶するように構成された論理415に関連する非一時的メモリに記憶することができ、その結果、405〜425の構成された論理は各々、その機能(すなわち、この場合、ソフトウェア実行)を、情報を記憶するように構成された論理415によって記憶されたソフトウェアの動作に部分的に基づいて実行する。同様に、構成された論理のうちの1つに直接関連付けられたハードウェアは、時々、他の構成された論理によって借用または使用され得る。たとえば、情報を処理するように構成された論理410のプロセッサは、データを、情報を受信および/または送信するように構成された論理405によって送信される前に、適切な形式にフォーマットすることができるので、情報を受信および/または送信するように構成された論理405は、その機能(すなわち、この場合、データの送信)を、情報を処理するように構成された論理410に関連付けられたハードウェア(すなわち、プロセッサ)の動作に部分的に基づいて実行する。
【００４９】
概して、別段に明示的に記載されていない限り、本開示全体にわたって使用される「ように構成された論理」という句は、ハードウェアにより少なくとも部分的に実施される実施形態を呼び出すものとし、ハードウェアから独立したソフトウェアだけの実施形態に位置づけるものではない。様々なブロックにおける構成された論理または「ように構成された論理」は、特定の論理ゲートまたは論理要素に限定されるのではなく、概して、本明細書に記載した機能性を、(ハードウェアまたはハードウェアとソフトウェアの組合せのいずれかを介して)実施するための能力を指すことが諒解されよう。したがって、様々なブロックに示す構成された論理または「ように構成された論理」は、「論理」という言葉を共有するにもかかわらず、必ずしも論理ゲートまたは論理要素として実装されるとは限らない。様々なブロックの論理間の他の対話または協働が、以下でより詳細に説明する実施形態の検討から、当業者には明らかになるであろう。
【００５０】
様々な実施形態は、図5に示すサーバ500などの、様々な市販のサーバデバイスのいずれかにおいて実装され得る。一例では、サーバ500は、上述のアプリケーションサーバ170の1つの例示的な構成に対応し得る。図5において、サーバ500は、揮発性メモリ502と、ディスクドライブ503などの大容量の不揮発性メモリとに結合されたプロセッサ501を含む。サーバ500は、プロセッサ501に結合された、フロッピー（登録商標）ディスクドライブ、コンパクトディスク(CD)またはDVDのディスクドライブ506も含み得る。サーバ500は、他のブロードキャストシステムコンピュータおよびサーバに、またはインターネットに結合されたローカルエリアネットワークなどの、ネットワーク507とのデータ接続を確立するための、プロセッサ501に結合されたネットワークアクセスポート504も含み得る。図4の文脈において、図5のサーバ500は、通信デバイス400の1つの例示的な実装形態を示すが、情報を送信および/または受信するように構成された論理405は、ネットワーク507と通信するためにサーバ500によって使用されるネットワークアクセスポート504に相当し、情報を処理するように構成された論理410は、プロセッサ501に相当し、情報を記憶するように構成された論理415は、揮発性メモリ502、ディスク(disk)ドライブ503、および/またはディスク(disc)ドライブ506のうちの任意の組合せに相当することが諒解されよう。情報を提示するように構成されたオプションの論理420およびローカルユーザ入力を受信するように構成されたオプションの論理425は、図5には明示的に示さず、その中に含まれる場合もあれば、含まれない場合もある。したがって、図5は、通信デバイス400が、図3に示すような305Aまたは305BなどのUEの実装形態に加えてサーバとして実装され得ることを説明するのを助ける。
【００５１】
上述の通信プロトコル(たとえば、EV-DO、W-CDMA、LTE、eHRPDなど)のいずれかにおいて、ユーザ機器(UE)は、メディア(たとえば、オーディオメディア、ビデオメディアなど)が交換され「リアルタイム」で再生される、他のUEとの通信セッションに関わる可能性がある。リアルタイム通信セッションでは、時間(たとえば、1秒のうちのほんの10分の数秒)が経過したとき、メディアの価値は急激に落ちる。たとえば、通話中に受信されるオーディオパケットに含まれるオーディオデータ(たとえば、1つまたは複数のオーディオフレーム)は、通常、ターゲットUEによって受信された後、比較的早く(たとえば、100〜200msで)再生される必要があるか、または別様に、そのオーディオデータは、通話とは関連がなくなる。また、通話中にオーディオパケットが喪失される場合、喪失オーディオパケットを(たとえば、スピーカー、または通話のためのオーディオパケットを保管するサーバから)取り戻すのに比較的長い時間(たとえば、数秒)がかかる可能性がある。リアルタイム通信セッション中のパケット喪失を緩和するために、前方誤り訂正(FER)またはインターリーブなどの機構が使用される。しかしながら、リアルタイム通信セッション中にメディアパケット(上述の例のオーディオパケットなど)が喪失された場合、ターゲットUEは、通常、回復が試みられた場合に喪失メディアパケットに含まれたメディアがその最終的な到着時には関連がなくなるという見込みにより、リアルタイム通信セッションがこのメディアを回復しようと試みることなく続くことを可能にする。
【００５２】
図6は、UE1がUE2にメディア(たとえば、オーディオメディア、ビデオメディアなど)を配信中であるアプリケーションサーバ170によって通信調停される従来のリアルタイム通信セッションを示す。図6のリアルタイム通信セッションは、図6がUE1からUE2への単方向のメディアパケットの流れに焦点を合わせていても、半二重または全二重である可能性がある。一例では、図6のリアルタイム通信セッションは、ユーザデータグラムプロトコル(UDP)上のリアルタイムトランスポートプロトコル(RTP)セッションに相当する可能性があり、そのセッションで、メディア(たとえば、オーディオメディア、ビデオメディアなど)は、各々が少なくとも1つのメディアフレームを含むRTPパケット内に含まれる。
【００５３】
図6を参照すると、リアルタイム通信セッション中、UE1はメディアを捕捉する(600)。600で起こるメディア捕捉は、UE1のオペレータの音声などのオーディオデータを捕捉するオーディオ記録デバイス(たとえば、マイクロフォン)、および/またはUE1の環境のビデオデータを捕捉するビデオ記録デバイス(たとえば、カメラ)に相当する場合がある。UE1は、メディアパケットの組内の捕捉メディアをバッファリングする(605)。説明の便宜のために、捕捉メディアが、メディアパケット1〜8内にバッファリングされると仮定されたい。図6において、UE1は、アプリケーションサーバ170にメディアパケット1〜6および8を正しく送信する(610)が、UE1は、アプリケーションサーバ170にメディアパケット7を正しく送信しない(615)と仮定されたい。たとえば、615の送信失敗は、UE1とそのサービングRANとの間の物理レイヤ干渉、UE1のサービングRANとアプリケーションサーバ170との間のバックホール喪失などによって引き起こされ得る。UE1は、610および615においてメディアパケット1〜8を送信しようと試みた後、そのバッファをクリアし、メディアパケット1〜8を保持しない(620)。図6では、615においてメディアパケット7が正しく送信されなかったとしても、UE1は、メディアパケット7を再送信しようと試みない。たとえば、伝送制御プロトコル(TCP)データ転送と異なり、UDP上のRTPセッションは、一般に、各RTPパケットの時間的制約のある性質のために、失敗(またはパケット喪失)が検出されたとき、データ送信を必要としない。
【００５４】
図6を参照すると、アプリケーションサーバ170は、UE2にメディアパケット1、2、3、5、6、および8を正しく送信する(625)が、アプリケーションサーバ170は、メディアパケット4を正しく送信することができない(630)と仮定されたい。たとえば、630の送信失敗は、UE2とそのサービングRANとの間の物理レイヤ干渉、UE2のサービングRANとアプリケーションサーバ170との間のバックホール喪失などによって引き起こされ得る。また、615から認識されるように、メディアパケット7がアプリケーションサーバ170に到着しなかったので、メディアパケット7は、625または630において送信されない。
【００５５】
UE2は、メディアパケット1、2、3、5、6、および8を受信し、それらをバッファリングする(635)。UE2はまた、メディアパケット4および7が転送中のある点において喪失されたことを認識するが(640)、UE2は、喪失メディアパケット4および7を回復しようと試みず、その理由は、UE2は、回復が試みられた場合、これらのパケットが到着時には古くなっているものと仮定するからである。再び、この仮定は、図6のリアルタイム通信セッションの動作に組み込まれる。UE2は、メディアパケット1、2、3、5、6、および8(すなわち、UE2によって実際に受信されたメディアパケット)内に含まれるメディアフレームを再生し(645)、メディアパケット4および7(すなわち、UE2に正しく到着しなかったメディアパケット)は再生されない。
【００５６】
図6は、リアルタイム通信セッションの間に喪失メディアパケットの再送信がまったく試みられないシナリオに関連するが、リアルタイム通信セッションの間にメディアパケットの再送信を可能にする無線リンクプロトコル(RLP)などの従来のプロトコルが存在する。RLPセッションでは、ターゲットUEがメディアパケットを損失するとき、ターゲットUEは、損失(または喪失)メディアパケットを再送信するためにそのサービングRANを直ちに要求する。しかしながら、ターゲットUEのサービングRANが喪失メディアパケット(たとえば、図6のメディアパケット7など)にアクセスしない場合、喪失メディアパケットには、再送信することができない。また、ターゲットUEのサービングRANが喪失メディアパケット(たとえば、メディアパケット4など)にアクセスしても、喪失メディアパケットの再送信は、RLPセッション中に再生されるにはあまりにも遅くなって起こるだけであり得る可能性がある。これらの理由により、本発明の実施形態は、回復基準値の組に基づいてリアルタイム通信セッション中に喪失メディアパケットを選択的に回復することを対象とする。
【００５７】
図7は、本発明の一実施形態による、1つまたは複数の他のUEとのリアルタイム通信セッションに関わるUEによって実施される喪失メディアパケット回復プロシージャを示す。図7の実施形態では、UEは、リアルタイム通信セッションに能動的に参加している可能性があるか、または、UEが比較的早くリアルタイム通信セッションへの能動的な参加に戻ると見込んで一時的に休止状態もしくは保留状態になる(たとえば、UEがリアルタイム通信セッションをキャンセルすることなく別の呼に切り替える、UEのオペレータが休止オプションを選択する、など)可能性があるかのいずれかである。
【００５８】
図7を参照すると、UEは、1つまたは複数の他のUEとのリアルタイム通信セッションに関わる(700)と仮定されたい。リアルタイム通信セッションは、半二重または全二重の通信セッションに相当し得る。リアルタイム通信セッションはまた、UEと他の1つのUEとの間の1:1もしくは直接の通信セッション、またはUEと2つ以上の他のUEとの間のグループ通信セッションのいずれかに相当し得る。
【００５９】
リアルタイム通信セッション中、UEは、メディアパケットが喪失されたことを検出する(705)。喪失メディアパケットは、1つまたは複数の他のUEからアプリケーションサーバ170への転送中の誤り(たとえば、サービングRANまたはバックホール接続部への物理レイヤ接続不良)、またはアプリケーションサーバ170からUE自体への転送中の誤り(たとえば、サービングRANまたはバックホール接続部への物理レイヤ接続不良)のために起こる場合がある。
【００６０】
705において喪失メディアパケットの検出に応答して、UEは、喪失メディアパケットを回復しようと試みるべきかどうかを決定する(715)ために、回復基準値の組を評価する(710)。図7に明示的には示さないが、喪失メディアパケットに関する利用可能な外部ソースが存在しない(たとえば、喪失メディアパケットにアクセスしたエンティティのいずれも喪失メディアパケットのバッファリングされたバージョンを有する見込みがない、など)可能性があり、その場合、715の決定は、回復基準値の組とは無関係に喪失メディアパケットの回復を試みないと自動的に決定する。喪失メディアパケットに対してメディアパケット回復がまったく試みられない図6、およびサービングRANから常にメディアパケット回復が試みられる代替のRLCセッションシナリオとは異なり、710の評価は、喪失メディアパケット回復を試みるべきかどうかの決定が選択的に起こることを可能にする。一例では、回復基準値の組は、限定はしないが、(i)喪失メディアパケットの再生緊急度、(ii)喪失メディアパケットが回復され得る可能性がある外部ソースの組の各々の信頼性、(iii)外部ソースの組の各々の期待応答時間、および/または(iv)喪失メディアパケットの優先度(たとえば、喪失メディアパケットが発信されたUEの優先度に基づく可能性がある)を含み得る。本明細書で使用する「外部」ソースは、UE自体の外部の、喪失メディアパケットを提供することができる可能性がある任意のエンティティに相当する。一例として、UEが接続されるサーバは、外部ソースの一例であるが、UEのローカルキャッシュメモリは、UE自体の一部であるので、外部ソースではない。
【００６１】
710の評価に基づいて、UEは、喪失メディアパケットの回復を試みるべきかどうかを決定する(715)。UEが715において喪失メディアパケットの回復を試みないと決定する場合、プロセスは700に戻り、喪失メディアパケットは、リアルタイム通信セッション中にUEによって回復も再生もされない。別段に、UEが715において喪失メディアパケットの回復を試みると決定する場合、UEは、回復基準値の組に基づいて喪失メディアパケットの回復を試みるための複数の外部ソースから少なくとも1つの外部ソースを識別する(720)。以下に提供する例から諒解されるように、回復を試みるための少なくとも1つの外部ソースの識別は、リアルタイムの考察に基づく動的な選択であり、UEが初期設定の外部ソースに任意の損失パケットを提供することを単に依頼する静的な選択ではない。
【００６２】
Table 2(表2)(下記)は、回復基準値の組が715の決定および/または720の識別を実行するためにどのように使用され得るかの一例を示す。
【００６３】
【表２】
2016524352.tif 000004
【００６４】
Table 2(表2)(上記)の例#1を参照すると、図7のプロセスを実行するUEはUE2に相当し、喪失メディアパケットの発信側UEはUE1であり、リアルタイム通信セッションはUE3およびUE4も含むグループセッションであると仮定されたい。さらに、喪失メディアパケットの緊急度が高い(たとえば、UEは、そのセッションに能動的に関わり、早く喪失メディアパケットを再生する必要がある)と仮定されたい。UE1は、喪失メディアパケットの発信ソースであり、その送信メディアパケットをバッファリングしていると見なされるので、UE1が喪失メディアパケットを提供することができる信頼性は高いが、UE1にはアプリケーションサーバ170を介してアクセスされるので、UE1は、遅い応答時間を有する。アプリケーションサーバ170は、そのセッションの間はメディアをバッファリングしている可能性もあるが、UE1とアプリケーションサーバ170との間でメディアパケットが喪失され得るので、中間的な信頼性を有する。それによって、アプリケーションサーバ170は、中間的な信頼性と中間的な応答時間の両方を有する。Table 2(表2)の例#1では、UE3はUE2への高速接続を有する(たとえば、UE2およびUE3はLTE Directを介して接続される、UE2およびUE3は、同じWLAN APまたはBluetooth（登録商標）接続を介して接続されアプリケーションサーバ170に関わることなく直接データを交換し得る、など)と仮定されたい。したがって、UE3は、低い信頼性を有するが、速い応答時間を有する。しかしながら、UE4はUE2への遅い接続を有し(たとえば、UE2およびUE4は、互いに除去されるか、またはアプリケーションサーバ170を介して接続されるにすぎない場合がある)、その結果、UE4は低い信頼性および遅い応答時間を有すると仮定されたい。Table 2(表2)の例#1では、喪失メディアパケットの優先度は、デフォルトであると見なされる。Table 2(表2)の例#1に関するこれらの仮定のもとで、UE(すなわち、UE2)は、その高い緊急度を満足するために喪失メディアパケットを時間内に提供することができると予想される少なくとも1つの利用可能な外部ソースが存在するので、715において喪失メディアパケットの回復を試みると決定し、このUEは、720において他の利用可能な外部ソースがあまりにも遅いと予想されるので、喪失メディアパケットを回復するための外部ソースとしてUE3を識別する。
【００６５】
Table 2(表2)(上記)の例#2を参照すると、図7のプロセスを実行するUEはUE2に相当し、喪失メディアパケットの発信側UEはUE1であり、リアルタイム通信セッションは1:1または直接のセッションであると仮定されたい。さらに、喪失メディアパケットの緊急度が高いと仮定されたい。Table 2(表2)の例#2では、例#1と同様に、UE1は、高い信頼性および遅い応答時間を有するが、アプリケーションサーバ170は、中間的な信頼性および中間的な応答時間を有する。Table 2(表2)の例#2では、喪失メディアパケットの優先度は、デフォルトであると見なされる。Table 2(表2)の例#2に関するこれらの仮定のもとで、UE(すなわち、UE2)は、その高い緊急度を満足するために喪失メディアパケットを時間内に提供することができると予想される利用可能な外部ソースが存在しないので、715において喪失メディアパケットの回復を試みないと決定する。
【００６６】
Table 2(表2)(上記)の例#3を参照すると、図7のプロセスを実行するUEはUE2に相当し、喪失メディアパケットの発信側UEはUE1であり、リアルタイム通信セッションはUE3も含むグループセッションであると仮定されたい。さらに、喪失メディアパケットの緊急度が低い(たとえば、UE2のオペレータは、別の呼に応答することによって一時的にリアルタイム通信セッションを休止した、など)と仮定されたい。Table 2(表2)の例#3では、例#1と同様に、UE1は、高い信頼性および遅い応答時間を有し、アプリケーションサーバ170は、中間的な信頼性および中間的な応答時間を有し、UE3は、(たとえば、UE2およびUE3がLTE-Direct、WLAN、またはBluetooth（登録商標）などの高速のバックチャネル接続部にアクセスするという仮定のもとで)低い信頼性および速い応答時間を有する。Table 2(表2)の例#3では、喪失メディアパケットの優先度は、デフォルトであると見なされる。Table 2(表2)の例#3に関するこれらの仮定のもとで、UE(すなわち、UE2)は、その高い緊急度を満足するために喪失メディアパケットを時間内に提供することができると予想される少なくとも1つの利用可能な外部ソースが存在するので、715において喪失メディアパケットの回復を試みると決定し、このUEは、UE1が最高の信頼性を有し喪失メディアパケットが特に緊急性はないので、UE1の低い応答時間にもかかわらず喪失メディアパケットを回復するための外部ソースとしてUE1を識別する。
【００６７】
Table 2(表2)(上記)の例#4を参照すると、図7のプロセスを実行するUEはUE2に相当し、喪失メディアパケットの発信側UEはUE1であり、リアルタイム通信セッションはUE3も含むグループセッションであると仮定されたい。さらに、喪失メディアパケットの緊急度が低い(たとえば、UE2のオペレータは、別の呼に応答することによって一時的にリアルタイム通信セッションを休止した、など)と仮定されたい。Table 2(表2)の例#4では、例#3と同様に、UE1は、高い信頼性および遅い応答時間を有し、アプリケーションサーバ170は、中間的な信頼性および中間的な応答時間を有し、UE3は、(たとえば、UE2およびUE3がLTE-Direct、WLAN、またはBluetooth（登録商標）などの高速のバックチャネル接続部にアクセスするという仮定のもとで)低い信頼性および速い応答時間を有する。Table 2(表2)の例#4では、喪失メディアパケットの優先度は、低いと見なされる。Table 2(表2)の例#4に関するこれらの仮定のもとで、UE(すなわち、UE2)は、喪失メディアパケットの低い優先度のために、715において喪失メディアパケットの回復を試みないと決定する。したがって、喪失メディアパケットが利用可能な外部ソースのうちのいずれかから回復できる可能性があっても、喪失メディアパケットの低い優先度は、UE2上のバッテリーリソースを節約し、および/または喪失パケット回復の試みを控えることによってシステムリソースを節約するにはこの場合には十分である。
【００６８】
Table 2(表2)(上記)の例#5を参照すると、図7のプロセスを実行するUEはUE2に相当し、喪失メディアパケットの発信側UEはUE1であり、リアルタイム通信セッションはUE3も含むグループセッションであると仮定されたい。さらに、喪失メディアパケットの緊急度が中間的である(たとえば、UE2のオペレータは、一時的にリアルタイム通信セッションを休止したが、リアルタイム通信セッションに比較的早く戻ることが予想される)と仮定されたい。Table 2(表2)の例#5では、例#4と同様に、UE1は、高い信頼性および遅い応答時間を有し、アプリケーションサーバ170は、中間的な信頼性および中間的な応答時間を有し、UE3は、(たとえば、UE2およびUE3がLTE-Direct、WLAN、またはBluetooth（登録商標）などの高速のバックチャネル接続部にアクセスするという仮定のもとで)低い信頼性および速い応答時間を有する。Table 2(表2)の例#5では、喪失メディアパケットの優先度は、高いと見なされる。Table 2(表2)の例#5に関するこれらの仮定のもとで、UE(すなわち、UE2)は、その高い緊急度を満足するために喪失メディアパケットを時間内に提供することができると予想される少なくとも1つの利用可能な外部ソースが存在するので、715において喪失メディアパケットの回復を試みると決定し、このUEは、720において喪失メディアパケットを回復するための外部ソースとしてアプリケーションサーバ170とUE3の両方を識別する。この場合、喪失メディアパケットの高い優先度は、喪失メディアパケットを時間内に提供することができると予想される複数の利用可能な外部ソースから喪失パケットの回復を試みるようにUE2に促すには十分である。
【００６９】
図7に戻ると、UEは、720において回復基準値の組に基づいて喪失メディアパケットの回復を試みるための外部ソースの組から少なくとも1つの外部ソースを識別(すなわち、動的に選択)した後、少なくとも1つの識別された外部ソースに喪失メディアパケットを要求する(725)。喪失メディアパケットからメディアフレームを再生するための終了期限内に、要求されたコピー(すなわち、喪失メディアパケットの差替用コピー)が受信される場合、要求されたコピーからのメディアフレームは、バッファリングされ、次いで、喪失メディアパケットが最初に喪失されなかったかのように再生される(730)。他方では、要求されたコピーがあまりにも遅く到着するか、またはまったく到着しない場合、リアルタイム通信セッションは、730において、喪失メディアパケットに関するメディアフレームを飛ばすにすぎない。
【００７０】
図7に明示的には示していないが、図7のプロセスは、リアルタイム通信セッション中、複数の喪失メディアパケットに関して繰り返し得る。図7のプロセスが実行される度に、回復基準値の組は、710において各特定の喪失メディアパケットに関して再評価される。諒解されるように、720において、これらの評価に基づいて喪失メディアパケットの回復のために様々な外部ソースが動的に選択され得る。したがって、第1の喪失メディアパケットの回復のために第1の喪失メディアパケットの発信ソース(すなわち、UE)を選択することができ、第2の喪失メディアパケットの回復のためにアプリケーションサーバを選択することができ、第3の喪失メディアパケットの回復のために局所的なUEを選択することができる、など。
【００７１】
図8は、本発明の一実施形態による、UE1がUE2にメディア(たとえば、オーディオメディア、ビデオメディアなど)を配信中であるアプリケーションサーバ170によって通信調停されるリアルタイム通信セッションを示す。特に、図8のリアルタイム通信セッションは、図7に関して上記で説明したプロセスとともに実行される。図8の実施形態では、リアルタイム通信セッションは、図8がUE1からUE2への単方向のメディアパケットの流れに焦点を合わせていても、半二重または全二重である可能性がある。一例では、図8のリアルタイム通信セッションは、UDP上のRTPセッションに相当する可能性があり、そのセッションで、メディア(たとえば、オーディオメディア、ビデオメディアなど)は、各々が少なくとも1つのメディアフレームを含むRTPパケット内に含まれる。また、図8のリアルタイム通信セッションは、1:1もしくは直接のセッションまたはグループセッションのいずれかに相当し得る。それによって、UE3およびその関連するプロセスは、リアルタイム通信セッションがUE1とUE2との間の1:1または直接のセッションであるシナリオにおいてこれらの態様がオプションであることを強調するために、点線を介して示される。
【００７２】
図8を参照すると、リアルタイム通信セッション中、UE1はメディアを捕捉する(800)。800で起こるメディア捕捉は、UE1のオペレータの音声などのオーディオデータを捕捉するオーディオ記録デバイス(たとえば、マイクロフォン)、および/またはUE1の環境のビデオデータを捕捉するビデオ記録デバイス(たとえば、カメラ)に相当する場合がある。UE1は、メディアパケットの組内の捕捉メディアをバッファリングする(805)。説明の便宜のために、捕捉メディアが、メディアパケット1〜8内にバッファリングされると仮定されたい。図8において、UE1は、アプリケーションサーバ170にメディアパケット1〜6および8を正しく送信する(810)が、UE1は、アプリケーションサーバ170にメディアパケット7を正しく送信しない(815)と仮定されたい。たとえば、815の送信失敗は、UE1とそのサービングRANとの間の物理レイヤ干渉、UE1のサービングRANとアプリケーションサーバ170との間のバックホール喪失などによって引き起こされ得る。810および815においてメディアパケット1〜8を送信しようと試みた後、図6の620と同様に805のバッファをクリアする代わりに、UE1は、少なくともしきい値時間期間の間はそのバッファにメディアパケット1〜8を維持する(820)。特に、メディアパケット1〜8は、リアルタイム通信セッションに参加する任意のターゲットUEからの任意の喪失メディアパケットを求める要求に応えるために拡張された時間期間(たとえば、10秒、15秒など)の間はUE1のバッファに維持され得る。
【００７３】
図8を参照すると、アプリケーションサーバ170は、UE1からメディアパケット1〜6および8を受信し、それらをバッファリングし(825)、アプリケーションサーバ170は、UE2(およびグループセッションシナリオにおけるUE3)にメディアパケット1、2、3、5、6、および8を正しく送信する(830)が、アプリケーションサーバ170は、UE2にメディアパケット4を正しく送信することができない(835)と仮定されたい。たとえば、835の送信失敗は、UE2および/またはUE3とそのそれぞれのサービングRANとの間の物理レイヤ干渉、UE2およびUE3のサービングRANとアプリケーションサーバ170との間のバックホール喪失などによって引き起こされ得る。また、815から認識されるように、メディアパケット7がアプリケーションサーバ170に到着しなかったので、メディアパケット7は、825においてバッファリングされないか、または830もしくは835において送信されない。840において、805のバッファをクリアする代わりに、アプリケーションサーバ170は、少なくともしきい値時間期間の間はそのバッファにメディアパケット1〜6および8を維持する。特に、メディアパケット1〜6および8は、リアルタイム通信セッションに参加する任意のターゲットUEからの任意の喪失メディアパケットを求める要求に応えるために拡張された時間期間(たとえば、10秒、15秒など)の間はアプリケーションサーバ170のバッファに維持され得る。
【００７４】
UE2は、メディアパケット1、2、3、5、6、および8を受信し、それらをバッファリングする(845)。グループセッションシナリオでは、UE3は、(オプションで)メディアパケット1〜6および8を受信し、それらをバッファリングする(850)が、その理由は、835におけるメディアパケット4のパケット送信失敗が、グループセッションシナリオにおいてはUE3に影響を及ぼさなかったと見なされるためである。UE2はまた、メディアパケット4および7が転送中のある点において喪失されたことを認識する(855)。従来の図6のように喪失メディアパケット4および7を無視するだけか、または従来のRLCセッションシナリオのようにサービングRANに喪失メディアパケット4および7を自動的に要求する代わりに、UE2は、図7の710〜720と同様に、喪失メディアパケット4および/または7の回復を試みるべきかどうか、および/またはどこで試みるべきかを決定するために回復基準値の組を評価する(860)。以下に、860の評価の結果に基づく代替の使用事例を示す図9A〜図10Dに関して図8のいくつかの例示的な続きについて説明する。
【００７５】
図9Aは、本発明の一実施形態による、図8のプロセスの続きを示す。特に、図9Aは、リアルタイム通信セッションがUE1〜3間のグループセッションである例を示す。図9Aの実施形態において、900Aでは、UE2は、図8の860の評価に基づいて、UE3からの喪失メディアパケット4の回復を試み、UE1からの喪失メディアパケット7の回復を試みると決定すると仮定されたい。たとえば、900AにおけるUE2の決定は、(たとえば、それぞれ、Table 2(表2)の例#1および#3のような)メディアパケット4がメディアパケット7と比較してより高い緊急度を含むパケットシーケンスにおける喪失メディアパケット4の初期の位置に基づく可能性がある。
【００７６】
喪失メディアパケット4および7の回復を試みるための外部ソースとして900AのそれぞれUE3およびUE1を識別(または、動的に選択)した後、UE2は、喪失メディアパケット4に関してはUE3に要求を送信し(905A)、UE2はまた、アプリケーションサーバ170を介して喪失メディアパケット7に関してはUE1に要求を送信する(910A)。一例では、905Aの送信は、リアルタイム通信セッションの間にUE2のサービングRANによってサポートされるチャネルとは別にバックチャネル(たとえば、LTE-Direct、WLANまたはWiFi、Bluetooth（登録商標）など)を介して起こる場合があるが、910Aの送信は、UE2のサービングRANを介して起こる。喪失メディアパケット4を求める要求に応答して、UE3は、915Aにおいてメディアパケット4のコピーを提供し、UE2は、そのバッファにメディアパケット4の差替用コピーを加える(920A)。図9Aでは、UE3は、メディアパケット4を提供することができるが、その理由は、パケット4は、850においてUE3によってバッファリングされ、UE2と同じ送信失敗をしなかったためである。喪失メディアパケット7を求める要求に応答して、UE1は、(たとえば、図8の820のバッファリングに基づいて)そのバッファからメディアパケット7を取り出し、925Aにおいてメディアパケット7のコピーをアプリケーションサーバ170に再送信し、アプリケーションサーバ170は、メディアパケット7をUE2に再送信し(930A)、その後、UE2は、そのバッファにメディアパケット7の差替用コピーを加える(935A)。940Aにおいて、UE2は、UE2がこの点でメディアパケット1〜8の各々をバッファリングしたので、メディアパケット1〜8の各々に含まれるメディアフレームを再生するが、UE3は、UE3がメディアパケット7を回復しなかったので、(メディアパケット7を除く)メディアパケット1〜6および8に含まれるメディアフレームを再生する(945A)。当然、別の実施形態では、UE3は、UE3がUE1または何らかの他の外部ソースのいずれかからメディアパケット7を別個に回復することができる、図7のプロセスを実行することもできる。
【００７７】
図9Bは、本発明の一実施形態による、オーディオパケットに関して実行される図8および図9Aのプロセスの一部分を示す流れ図を示す。図9Bを参照すると、アプリケーションサーバ170は、オーディオサーバ構成要素170Aおよびマルチポイント制御ユニット(MCU)170Bを含む。図9Bに示すように、UE1は、805においてオーディオパケット1〜8をバッファリングし、810においてバッファリングされたオーディオパケットをオーディオサーバ構成要素170AおよびMCU170Bに送信する。オーディオサーバ構成要素170Aは、受信したオーディオパケットをバッファリングし(825)、MCU170Bは、830〜835のようにターゲットUE2およびUE3にオーディオパケットを送信し、オーディオパケットは、845〜850においてUE2およびUE3によってバッファリングされる。860の評価に基づいて(図9Bに明示的には示さないが)、UE2は、900AにおいてUE3からのオーディオパケット4を回復し、UE1からのオーディオパケット7を回復すると決定する。UE2は、オーディオパケット4および7を回復した後、940Aにおいてオーディオパケット1〜8の各々を再生する。また、図9BにMCU170BからUE1への別のクローズドフィードバックループが示され、それによって、MCU170Bは、UE2および/またはUE3におけるユーザエクスペリエンスに関連するUE1にフィードバック(たとえば、パケット誤り率(PER)など)を送信する(900B)。UE1またはそのオペレータは、905Bにおいて1つまたは複数の呼パラメータを調整するためにそのフィードバックを使用し得る。
【００７８】
図10Aは、本発明の別の実施形態による、図8のプロセスの続きを示す。特に、図10Aは、リアルタイム通信セッションがUE1〜3間のグループセッションである例を示す。図10Aの実施形態において、1000Aでは、UE2は、図8の860の評価に基づいて、喪失メディアパケット4の回復を試みず、UE3からの喪失メディアパケット7の回復を試みると決定すると仮定されたい。たとえば、1000AにおけるUE2の決定は、メディアパケット4がメディアパケット7と比較してより高い緊急度を含むパケットシーケンスにおける喪失メディアパケット4の初期の位置に基づく可能性があり、(たとえば、それぞれ、Table 2(表2)の例#2および#1のように)メディアパケット4の緊急度は、高すぎて利用可能な外部ソースのうちのいずれかによって満足することができないが、メディアパケット7の緊急度は、少なくともUE3の期待応答時間によって満足され得る。
【００７９】
喪失メディアパケット7の回復を試みるための外部ソースとして1000AのUE3を識別(または、動的に選択)した後、UE2は、喪失メディアパケット7に関してUE3に要求を送信する(1005A)。一例では、1005Aの送信は、リアルタイム通信セッションの間にUE2のサービングRANによってサポートされるチャネルとは別にバックチャネル(たとえば、LTE-Direct、WLANまたはWiFi、Bluetooth（登録商標）など)を介して起こる場合がある。喪失メディアパケット7を求める要求に応答して、UE3は、UE3がまたメディアパケット7を受信しなかったので、メディアパケット7のコピーを提供することができない(1010A)。それによって、UE2は、UE3から喪失メディアパケット7を回復することができない。しかしながら、UE2とUE3との間の接続が比較的速いので、UE2は、何らかの他の外部ソース(または複数のソース)からの喪失メディアパケット7の回復を試みるのに十分な時間でUE3がメディアパケット7のコピーをUE2に提供することができないことを認識し得る。したがって、図8の860と同様に、UE2は、喪失メディアパケット7の回復を再試行すべきかどうか、および/またはどこで再試行すべきかを決定するために回復基準値の組を再評価する(1015A)。諒解されるように、UE3は、詳細には、回復のための潜在的なソースとして考察から除外されるが、その理由は、UE2は、1015AにおいてUE3がメディアパケット7のコピーを有しないことを知るためである。1015Aの評価に基づいて、UE2は、異なる外部ソース(または複数のソース)からの喪失メディアパケット7の回復を再試行すべきかどうかを決定する(1020A)。UE2が1020Aにおいて異なる外部ソース(または複数のソース)からの喪失メディアパケット7の回復を再試行すると決定する場合、このプロセスは720に進み、(1000Aと同様であるが、異なる外部ソースの識別によって)これらのソースが識別される。他方では、UE2が喪失メディアパケット7の回復を再試行しないと決定する(たとえば、あまりにも多くの時間が経過し、もしあったとしても、残りの利用可能な外部ソースのうちのいずれも、この点において十分に速く喪失メディアパケット7のコピーを提供することができないと予想される)場合、UE2は、UE2がこの点において(メディアパケット4も7も除く)メディアパケット1〜3、5、6、および8の各々をバッファリングしたので、メディアパケット1〜3、5、6、および8の各々に含まれるメディアフレームを再生し(1025A)、UE3も、(メディアパケット7を除く)メディアパケット1〜6および8に含まれるメディアフレームを再生する(1030A)。
【００８０】
図10Bは、本発明の別の実施形態による、図8のプロセスの続きを示す。特に、図10Bは、リアルタイム通信セッションがUE1とUE2との間の1:1または直接のセッションである例を示し、したがって、図10BからUE3が完全に省略される。図10Bの実施形態において、1000Bでは、UE2は、図8の860の評価に基づいてアプリケーションサーバ170からの喪失メディアパケット4の回復を試み、UE1からの喪失メディアパケット7の回復を試みると決定すると仮定されたい。たとえば、1000BにおけるUE2の決定は、メディアパケット4がメディアパケット7と比較してより高い緊急度を含むパケットシーケンスにおける喪失メディアパケット4の初期の位置に基づく可能性があり、メディアパケット4の緊急度は、UE1ではなくアプリケーションサーバ170の期待応答時間によって満足され得るが、メディアパケット7の緊急度は、アプリケーションサーバ170またはUE1のいずれかの期待応答時間によって満足される可能性があり、UE1は、(たとえば、Table 2(表2)の例#3のように)UE1の比較的高い信頼性に基づいてメディアパケット7を回復するために選択される。
【００８１】
1000Bにおいて、喪失メディアパケット4の回復を試みるための外部ソースとしてアプリケーションサーバ170を識別(または、動的に選択)し、喪失メディアパケット7の回復を試みるための外部ソースとしてUE1を識別した後、UE2は、喪失メディアパケット4に関してはアプリケーションサーバ170に要求を送信し(1005B)、UE2は、喪失メディアパケット7に関してはアプリケーションサーバ170を介してUE1に要求を送信する(1010B)。喪失メディアパケット4を求める要求に応答して、アプリケーションサーバ170は、840のそのバッファリングに基づいてメディアパケット4のコピーを再送信し(1015B)、UE2は、そのバッファにパケット4の再送信されたコピーを加える(1020B)。喪失メディアパケット7を求める要求に応答して、UE1は、820のそのバッファリングに基づいてアプリケーションサーバ170にメディアパケット7のコピーを送信し(1025B)、アプリケーションサーバ170は、次に、メディアパケット7のコピーをUE2に送信し(1030B)、UE2は、そのバッファにメディアパケット7の送信されたコピーを加える(1035B)。それによって、UE2は、喪失メディアパケット4と7の両方を回復することができ、1040Bにおいて、UE2は、UE2がこの点でメディアパケット1〜8の各々をバッファリングしたので、メディアパケット1〜8の各々に含まれるメディアフレームを再生する。
【００８２】
図10Cは、本発明の別の実施形態による、図8のプロセスの続きを示す。特に、図10Cは、リアルタイム通信セッションがUE1〜3間のグループセッションである例を示す。図10Cの実施形態において、1000Cでは、UE2は、図8の860の評価に基づいて、アプリケーションサーバ170とUE3の両方からのメディアパケット4の回復を試み、UE1からのメディアパケット7の回復を試みると決定すると仮定されたい。たとえば、1000CにおけるUE2の決定は、(たとえば、それぞれ、Table 2(表2)の例#5および#3のように)高い優先度および中間的な緊急度を有する喪失メディアパケット4と、比較的低い緊急度を有するメディアパケット7とに基づく可能性がある。
【００８３】
喪失メディアパケット4の回復を試みるための外部ソースとして1000Cのアプリケーションサーバ170とUE3の両方を識別(または、動的に選択)した後、UE2は、喪失メディアパケット4に関してUE3に要求を送信し(1005C)、喪失メディアパケット4に関してアプリケーションサーバ170に要求を送信する(1010C)。一例では、1005Cの送信は、リアルタイム通信セッションの間にUE2のサービングRANによってサポートされるチャネルとは別にバックチャネル(たとえば、LTE-Direct、WLANまたはWiFi、Bluetooth（登録商標）など)を介して起こる場合がある。また、喪失メディアパケット7の回復を試みるための外部ソースとして1000CのUE1を識別した後、UE2は、アプリケーションサーバ170を介して喪失メディアパケット7に関してUE1に要求を送信する(1015C)。
【００８４】
1005Cの喪失メディアパケット4を求める要求に応答して、UE3は、850のバッファリングに基づいてメディアパケット4のコピーを提供し(1020C)、UE2は、メディアパケット4のコピーを受信し、それをバッファリングする(1025C)。1010Cの喪失メディアパケット4を求める要求に応答して、アプリケーションサーバ170はまた、840のバッファリングに基づいてメディアパケット4のコピーを提供する(1030C)。この場合、UE2は、UE3がアプリケーションサーバ170よりも遅い応答時間を有するので、この点でメディアパケット4をすでにバッファリングし、したがって、1030Cの送信は、UE2によって無視される(バッファリングされない)。諒解されるように、UE3が要求メディアパケットをバッファリングしなかったシナリオでは、1035Cのように無視される代わりに、より信頼性が高いアプリケーションサーバからのメディアパケットのコピーの送信が使用される。1015Cの喪失メディアパケット7を求める要求に応答して、UE1は、820のバッファリングに基づいてメディアパケット7のコピーを送信し(1040C)、アプリケーションサーバ170は、メディアパケット7のコピーをUE2に送信し(1045C)、UE2は、メディアパケット7のコピーを受信し、それをバッファリングする(1050C)。それによって、UE2は、喪失メディアパケット4および7を回復することができ、1055Cにおいて、UE2は、UE2がこの点でメディアパケット1〜8の各々をバッファリングしたので、メディアパケット1〜8の各々に含まれるメディアフレームを再生し、UE3は、(メディアパケット7を除く)メディアパケット1〜6および8に含まれるメディアフレームを再生する(1060C)。
【００８５】
図10Dは、本発明の別の実施形態による、図8のプロセスの続きを示す。特に、図10Dは、リアルタイム通信セッションがUE1とUE2との間の1:1または直接のセッションである例を示し、したがって、図10DからUE3が完全に省略される。図10Dの実施形態では、図8の860の前のある点において、UE2は、一時的にリアルタイム通信セッションを(たとえば、休止状態または休止モードで)保留する(1000D)と仮定されたい。これは、UE2が短い時間期間(たとえば、5秒、10秒など)にリアルタイム通信セッションに戻ることが予想されるが、このセッションに関連するメディアを現時点では再生していないことを意味する。したがって、図8の860が実行されるとき、任意の喪失メディアパケット(この場合、メディアパケット4および7)の緊急度は、喪失メディアパケットが再生される前にUE2がこれらのメディアパケットを回復するためのある時間を有するので、低い緊急度に設定される。
【００８６】
したがって、1005Dでは、UE2は、図8の860の評価に基づいて、UE1からの喪失メディアパケット4および7の回復を試みると決定する。たとえば、1005DにおけるUE2の決定は、(Table 2(表2)の例#3のように)メディアパケット4および7の緊急度が低く、UE1がこれらのメディアパケットの利用可能な外部ソースのうちで最高の信頼性を有することに基づく可能性がある。
【００８７】
1005Dにおいて喪失メディアパケット4および7の回復を試みるための外部ソースとしてUE1を識別(または、動的に選択)した後、UE2は、アプリケーションサーバ170を介して喪失メディアパケット4および7に関してUE1に要求を送信する(1010D)。喪失メディアパケット4および7を求める要求に応答して、UE1は、820のそのバッファリングに基づいてアプリケーションサーバ170にメディアパケット4および7のコピーを送信し(1015D)、アプリケーションサーバ170は、次に、メディアパケット4および7のコピーをUE2に送信し(1020D)、UE2は、そのバッファにメディアパケット4および7の送信されたコピーを加える(1025D)。それによって、UE2は、喪失メディアパケット4と7の両方を回復することができ、1030Dにおいて、UE2は、UE2がこの点でメディアパケット1〜8の各々をバッファリングしたので、このセッションを「休止解除」し、メディアパケット1〜8の各々に含まれるメディアフレームを再生する。
【００８８】
本発明の上記で説明した実施形態は、パケット喪失の検出および喪失パケットの回復に関して説明してきたが、本発明の他の実施形態は、フレーム喪失の検出およびフレーム喪失の回復を対象とする場合があることが諒解されよう。たとえば、RTPパケットは、複数のメディアフレームを含む可能性があり、これらのフレームのうちのいくつかは正しく受信されるが、他のフレームは受信されないことがあり得る。この場合、使用可能なフレームは、バッファリングされ得るが、図7に関して上記で説明した論理は、任意の喪失フレームの回復を試みるべきかどうかを決定するために実行され得る。一般に、パケットに関する上記で説明した同じ論理は、当業者なら容易に諒解されるように、フレームに引き継がれ得る。
【００８９】
情報および信号が多種多様な異なる技術および技法のいずれかを使用して表すことができることを、当業者は諒解されよう。たとえば、上記の説明全体を通して言及できるデータ、命令、コマンド、情報、信号、ビット、シンボル、およびチップは、電圧、電流、電磁波、磁場もしくは磁性粒子、光場もしくは光学粒子、またはそれらの任意の組合せによって表現することができる。
【００９０】
さらに、本明細書で開示された実施形態に関連して説明された様々な例示的な論理ブロック、モジュール、回路、およびアルゴリズムステップは、電子ハードウェア、コンピュータソフトウェア、または両方の組合せとして実装され得ることを、当業者は諒解されよう。ハードウェアおよびソフトウェアのこの互換性を明確に示すために、様々な例示的な構成要素、ブロック、モジュール、回路、およびステップを、上記では概してそれらの機能性に関して説明した。そのような機能がハードウェアとして実装されるか、またはソフトウェアとして実装されるかは、具体的な適用例および全体的なシステムに課される設計制約に依存する。当業者は、説明された機能を具体的な適用例ごとに様々な方法で実装することができるが、そのような実装の決定は、本発明の範囲からの逸脱を生じるものと解釈されるべきではない。
【００９１】
本明細書で開示する実施形態に関して説明する様々な例示的な論理ブロック、モジュール、および回路は、汎用プロセッサ、デジタル信号プロセッサ(DSP)、特定用途向け集積回路(ASIC)、フィールドプログラマブルゲートアレイ(FPGA)または他のプログラマブル論理デバイス、個別ゲートまたはトランジスタ論理、個別ハードウェア構成要素、または本明細書で説明する機能を実行するように設計されたそれらの任意の組合せで実装または実行することができる。汎用プロセッサはマイクロプロセッサであり得るが、代替として、プロセッサは任意の従来のプロセッサ、コントローラ、マイクロコントローラ、または状態機械であり得る。プロセッサはまた、コンピューティングデバイスの組合せ、たとえば、DSPおよびマイクロプロセッサの組合せ、複数のマイクロプロセッサ、DSPコアと連携する1つもしくは複数のマイクロプロセッサ、または任意の他のそのような構成として実装され得る。
【００９２】
本明細書で開示した実施形態に関連して説明した方法、シーケンス、および/またはアルゴリズムは、ハードウェアで、プロセッサによって実行されるソフトウェアモジュールで、またはその2つの組合せで直接具体化され得る。ソフトウェアモジュールは、RAMメモリ、フラッシュメモリ、ROMメモリ、EPROMメモリ、EEPROMメモリ、レジスタ、ハードディスク、リムーバブルディスク、CD-ROM、または当技術分野で知られている任意の他の形態の記憶媒体中に常駐し得る。例示的な記憶媒体は、プロセッサが記憶媒体から情報を読み取り、かつ記憶媒体に情報を書き込むことができるように、プロセッサに結合される。代替形態において、記憶媒体はプロセッサと一体であり得る。プロセッサおよび記憶媒体はASIC内に存在することができる。ASICはユーザ端末(たとえば、UE)中に存在し得る。代替として、プロセッサおよび記憶媒体は、ユーザ端末内に個別構成要素として存在することができる。
【００９３】
1つまたは複数の例示的な実施形態では、説明される機能は、ハードウェア、ソフトウェア、ファームウェア、またはそれらの任意の組合せにおいて実装され得る。ソフトウェアに実装された場合、機能は、1つまたは複数の命令またはコードとして、コンピュータ可読記録媒体上に記憶されるか、またはコンピュータ可読記録媒体を介して送信され得る。コンピュータ可読記録媒体は、ある場所から別の場所へのコンピュータプログラムの転送を容易にする任意の媒体を含む、コンピュータ記憶媒体と通信媒体の両方を含む。記憶媒体は、コンピュータによってアクセス可能である任意の入手可能な媒体とすることができる。例として、限定はしないが、そのようなコンピュータ可読記録媒体は、RAM、ROM、EEPROM、CD-ROMもしくは他の光ディスク記憶装置、磁気ディスク記憶装置もしくは他の磁気記憶デバイス、または、命令またはデータ構造の形態の所望のプログラムコードを搬送または記憶するために用いることができ、コンピュータによってアクセス可能である、任意の他の媒体を含むことができる。また、当然、あらゆる接続がコンピュータ可読記録媒体と呼ばれる。たとえば、ソフトウェアが、同軸ケーブル、光ファイバケーブル、ツイストペア、デジタル加入者回線(DSL)、または赤外線、無線、およびマイクロ波などのワイヤレス技術を使用して、ウェブサイト、サーバ、または他のリモートソースから送信される場合、同軸ケーブル、光ファイバケーブル、ツイストペア、DSL、または赤外線、無線、およびマイクロ波などのワイヤレス技術は、媒体の定義に含まれる。本明細書で使用する場合、ディスク(disk)およびディスク(disc)は、コンパクトディスク(CD)、レーザーディスク(登録商標)、光ディスク、デジタル多用途ディスク(DVD)、フロッピー(登録商標)ディスク、およびブルーレイディスクを含み、ディスク(disk)は、通常、磁気的にデータを再生するが、ディスク(disc)は、レーザーで光学的にデータを再生する。上記の組合せもコンピュータ可読記録媒体の範囲内に含めるべきである。
【００９４】
上記の開示は本発明の例示的な実施形態を示すが、添付の特許請求の範囲によって定義された本発明の範囲から逸脱することなく、様々な変更および修正を本明細書において加えることができることを留意されたい。本明細書で説明する本発明の実施形態による機能、ステップ、および/または方法クレームのアクションが任意の特定の順序で実行される必要はない。さらに、本発明の要素は、単数で記載され、または請求されているが、単数への制限が明示的に述べられない限り、複数は企図される。
【符号の説明】
【００９５】
100  ワイヤレス通信システム
104  エアインターフェース
106  エアインターフェース
108  エアインターフェース
120  無線アクセスネットワーク(RAN)
125  アクセスポイント(AP)
140  コアネットワーク
170  アプリケーションサーバ
170A  オーディオサーバ構成要素
170B  マルチポイント制御ユニット
175  インターネット
200A  基地局
205A  基地局
210A  基地局
215A  基地局コントローラ(BSC)
220A  パケット制御機能
225A  パケットデータサービングノード
200B  ノードB
205B  ノードB
210B  ノードB
215B  無線ネットワークコントローラ(RNC)
220B  サービングGRPSサポートノード(SGSN)
225B  ゲートウェイ汎用パケット無線サービス(GPRS)サポートノード(GGSN)
200D  eノードB
205D  eノードB
210D  eノードB
215D  モビリティ管理エンティティ(MME)
220D  モビリティ管理エンティティ(MME)
225D  ホーム加入者サーバ(HSS)
230D  サービングゲートウェイ(S-GW)
235D  パケットデータネットワークゲートウェイ(P-GW)
240D  ポリシーおよび課金ルール機能(PCRF)
200E  トランシーバ基地局(BTS)
205E  トランシーバ基地局(BTS)
210E  トランシーバ基地局(BTS)
215E  拡張型BSC(eBSC)および拡張型PCF(ePCF)
220E  HRPDサービングゲートウェイ(HSGW)
225E  認証、許可、およびアカウンティング(AAA)サーバ
230E  PDSN/FA
235E  HA
300A  UE(発呼側)
300B  UE(タッチスクリーンデバイス)
302  プラットフォーム
305A  アンテナ
305B  タッチスクリーンディスプレイ
306  トランシーバ
308  特定用途向け集積回路(ASIC)
310  アプリケーションプログラミングインターフェース(API)
310A  ディスプレイ
310B  周辺ボタン
312  メモリ
314  ローカルデータベース
315A  ボタン
315B  周辺ボタン
320A  キーパッド
320B  周辺ボタン
325B  周辺ボタン
330B  フロントパネルボタン
400  通信デバイス
405  情報を受信および/または送信するように構成された論理
410  情報を処理するように構成された論理
415  情報を記憶するように構成された論理
420  情報を提示するように構成された論理
425  ローカルユーザ入力を受信するように構成された論理
500  サーバ
501  プロセッサ
502  揮発性メモリ
503  ディスク(disk)ドライブ
504  ネットワークアクセスポート
506  ディスク(disc)ドライブ
507  ネットワーク
【図１】
2016524352.tif 000005
【図２Ａ】
2016524352.tif 000006
【図２Ｂ】
2016524352.tif 000007
【図２Ｃ】
2016524352.tif 000008
【図２Ｄ】
2016524352.tif 000009
【図２Ｅ】
2016524352.tif 000010
【図３】
2016524352.tif 000011
【図４】
2016524352.tif 000012
【図５】
2016524352.tif 000013
【図６】
2016524352.tif 000014
【図７】
2016524352.tif 000015
【図８】
2016524352.tif 000016
【図９Ａ】
2016524352.tif 000017
【図９Ｂ】
2016524352.tif 000018
【図１０Ａ】
2016524352.tif 000019
【図１０Ｂ】
2016524352.tif 000020
【図１０Ｃ】
2016524352.tif 000021
【図１０Ｄ】
2016524352.tif 000022
【手続補正書】
【提出日】平成27年3月12日(2015.3.12)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
リアルタイム通信セッションの間に喪失メディアの回復を選択的に試みるように構成されたユーザ機器(UE)を動作させる方法であって、
前記UEに正しく到着しなかった、前記リアルタイム通信セッションに参加する別のUEからの喪失メディアパケットの存在を検出するステップと、
前記検出するステップに応答して前記喪失メディアパケットの回復に関連して複数の外部ソースからの任意の外部ソースに接触する前に、前記複数の外部ソースから少なくとも1つの外部ソースを動的に選択するために前記喪失メディアパケットに関連する回復基準値の組を評価するステップであって、前記少なくとも1つの外部ソースから、前記喪失メディアパケットは、回復基準値の前記組に基づいて前記喪失メディアパケットの回復を試みるために様々な予測信頼性および応答時間において回復され得る可能性がある、ステップと、
前記評価に基づいて前記選択された少なくとも1つの外部ソースから前記喪失メディアパケットを回復しようと試みるステップと
を含む、方法。
【請求項２】
前記選択された少なくとも1つの外部ソースは、複数の外部ソースを含む、請求項1に記載の方法。
【請求項３】
前記試みるステップは、前記複数の外部ソースの各々が前記喪失メディアパケットのコピーを提供することを要求するステップを含む、請求項2に記載の方法。
【請求項４】
前記複数の外部ソースのうちの1つから前記喪失メディアパケットの単一のコピーを受信するステップと、
前記喪失メディアパケットの終了期限の前に前記喪失メディアパケットの前記受信された単一のコピーが受信された場合、前記喪失メディアパケットの前記受信された単一のコピーを再生するステップと
をさらに含む、請求項3に記載の方法。
【請求項５】
前記複数の外部ソースのうちの2つ以上から前記喪失メディアパケットの2つ以上のコピーを受信するステップと、
前記喪失メディアパケットの前記2つ以上の受信されたコピーのうちの1つを選択するステップと、
前記喪失メディアパケットの終了期限の前に前記喪失メディアパケットの前記選択されたコピーが受信された場合、前記喪失メディアパケットの前記選択されたコピーを再生するステップと
をさらに含む、請求項3に記載の方法。
【請求項６】
前記選択するステップは、前記選択されたコピーとして最も早く受信されたコピーを選択する、請求項5に記載の方法。
【請求項７】
前記選択された少なくとも1つの外部ソースは、単一の外部ソースを含む、請求項1に記載の方法。
【請求項８】
前記試みるステップは、前記単一の外部ソースが前記喪失メディアパケットのコピーを提供することを要求するステップを含む方法であって、
前記単一の外部ソースから前記喪失メディアパケットの前記要求されたコピーを受信するステップと、
前記喪失メディアパケットの終了期限の前に前記喪失メディアパケットの前記受信された要求されたコピーが受信された場合、前記喪失メディアパケットの前記受信された要求されたコピーを再生するステップと
をさらに含む、請求項7に記載の方法。
【請求項９】
前記単一の外部ソースは、前記複数の外部ソースのうちの最も信頼性が高い外部ソースに相当するか、または
前記単一の外部ソースは、前記複数の外部ソースのうちの最速の応答時間に関連する所与の外部ソースに相当する、
請求項7に記載の方法。
【請求項１０】
前記選択された少なくとも1つの外部ソースから前記喪失メディアパケットを回復しようとする前記試みは、前記喪失メディアパケットを回復することができず、
前記喪失メディアパケットの回復を再試行しないと決定するステップ
をさらに含む、方法であって、
前記リアルタイム通信セッションは、前記喪失メディアパケットの再生なしに続く、
請求項1に記載の方法。
【請求項１１】
前記選択された少なくとも1つの外部ソースから前記喪失メディアパケットを回復しようとする前記試みは、前記喪失メディアパケットを回復することができず、
前記喪失メディアパケットの回復を再試行すると決定するステップと、
回復基準値の前記組に基づいて前記喪失メディアパケットの回復を再試行するために前記複数の外部ソースから少なくとも1つの異なる外部ソースを動的に選択しようと試みるために前記喪失メディアパケットに関連する回復基準値の前記組を再評価するステップと、
前記評価に基づいて前記選択された少なくとも1つの異なる外部ソースから前記喪失メディアパケットを回復することを再試行するステップと
をさらに含む、請求項1に記載の方法。
【請求項１２】
前記喪失メディアパケットが回復され得る可能性がある前記複数の外部ソースは、前記別のUE、前記リアルタイム通信セッションを通信調停しているサーバ、および/または前記リアルタイム通信セッションに同様に参加している1つもしくは複数の異なるUEを含む、請求項1に記載の方法。
【請求項１３】
前記検出に応答して前記リアルタイム通信セッションを休止するステップと、
前記選択された少なくとも1つの外部ソースから前記喪失メディアパケットのコピーを受信するステップと、
前記リアルタイム通信セッションを休止解除し、前記喪失メディアパケットの前記受信されたコピーを再生するステップと
をさらに含む、請求項1に記載の方法。
【請求項１４】
前記選択された少なくとも1つの外部ソースは、前記複数の外部ソースから最も高い信頼性に関連する所与の外部ソースを含む、請求項13に記載の方法。
【請求項１５】
回復基準値の前記組は、
(i)前記喪失メディアパケットの再生緊急度、
(ii)前記喪失メディアパケットが回復され得る可能性がある前記複数の外部ソースの各々の信頼性、
(iii)前記複数の外部ソースの各々の期待応答時間、および/または、
(iv)前記喪失メディアパケットの優先度
を含む、請求項1に記載の方法。
【請求項１６】
回復基準値の前記組は、少なくとも(i)および(iii)を含む、請求項15に記載の方法。
【請求項１７】
前記喪失メディアパケットの前記再生緊急度は高く、
前記評価するステップは、前記高い再生緊急度を満足する期待応答時間で前記複数の外部ソースのサブセットとして前記選択された少なくとも1つの外部ソースを動的に選択する、
請求項16に記載の方法。
【請求項１８】
前記サブセットは、
前記リアルタイム通信セッションに同様に参加し、前記リアルタイム通信セッションを通信調停しているサーバをバイパスする補助通信リンクを介して前記UEに接続される異なるUE
を少なくとも含む、請求項17に記載の方法。
【請求項１９】
回復基準値の前記組は、少なくとも(i)、(ii)、および(iii)を含む、請求項16に記載の方法。
【請求項２０】
前記喪失メディアパケットの前記再生緊急度は中間的であり、
前記評価するステップは、前記中間的な再生緊急度を満足する所与の期待応答時間を有する少なくとも最も信頼性が高い外部ソースを含むものとして前記選択された少なくとも1つの外部ソースを動的に選択する、
請求項19に記載の方法。
【請求項２１】
前記中間的な再生緊急度を満足する前記所与の期待応答時間を有する前記最も信頼性が高い外部ソースは、前記リアルタイム通信セッションを通信調停しているサーバである、請求項20に記載の方法。
【請求項２２】
前記喪失メディアパケットの前記再生緊急度は低く、
前記評価するステップは、前記低い再生緊急度を満足する所与の期待応答時間で少なくとも最も信頼性が高い外部ソースを含むものとして前記選択された少なくとも1つの外部ソースを動的に選択する、
請求項19に記載の方法。
【請求項２３】
前記低い再生緊急度を満足する前記所与の期待応答時間を有する前記最も信頼性が高い外部ソースは、前記別のUEである、請求項22に記載の方法。
【請求項２４】
回復基準値の前記組は、少なくとも(iv)を含む、請求項15に記載の方法。
【請求項２５】
前記試みるステップは、しきい値を超える前記喪失メディアパケットの前記優先度に基づいて実行され、
前記リアルタイム通信セッション中に1つまたは複数の他の喪失メディアパケットを回復しようとする1つまたは複数の試みは、前記しきい値未満の前記1つまたは複数の他の喪失メディアパケットの優先度に基づいてスキップされる、
請求項24に記載の方法。
【請求項２６】
前記試みるステップは、前記リアルタイム通信セッションのリアルタイム通信フェーズを出ることなく前記喪失メディアパケットの回復を試みる、請求項1に記載の方法。
【請求項２７】
前記UEに正しく到着しなかった、前記リアルタイム通信セッションに参加する前記別のUEからの別の喪失メディアパケットの存在を検出するステップと、
前記複数の外部ソースから1つまたは複数の外部ソースを動的に選択しようと試みるために前記別の喪失メディアパケットに関連する回復基準値の前記組を評価するステップであって、前記1つまたは複数の外部ソースから、前記別の喪失メディアパケットは、回復基準値の前記組に基づいて前記別の喪失メディアパケットの回復を試みるために様々な予測信頼性および/または応答時間において回復され得る可能性がある、ステップと、
前記別の喪失メディアパケットに関連する回復基準値の前記組の前記評価に基づいて前記選択された1つまたは複数の外部ソースから前記別の喪失メディアパケットを回復しようと試みるステップと
をさらに含み、
前記喪失メディアパケットの回復のために選択された前記少なくとも1つの選択外部ソースは、前記別の喪失メディアパケットの回復のために選択された前記1つまたは複数の選択外部ソースとは異なる、
請求項1に記載の方法。
【請求項２８】
リアルタイム通信セッションの間に喪失メディアの回復を選択的に試みるように構成されたユーザ機器(UE)であって、
前記UEに正しく到着しなかった、前記リアルタイム通信セッションに参加する別のUEからの喪失メディアパケットの存在を検出するための手段と、
前記検出するステップに応答して前記喪失メディアパケットの回復に関連して複数の外部ソースからの任意の外部ソースに接触する前に、前記複数の外部ソースから少なくとも1つの外部ソースを動的に選択するために前記喪失メディアパケットに関連する回復基準値の組を評価するための手段であって、前記少なくとも1つの外部ソースから、前記喪失メディアパケットは、回復基準値の前記組に基づいて前記喪失メディアパケットの回復を試みるために様々な予測信頼性および応答時間において回復され得る可能性がある、手段と、
前記評価に基づいて前記選択された少なくとも1つの外部ソースから前記喪失メディアパケットを回復しようと試みるための手段と
を含む、ユーザ機器(UE)。
【請求項２９】
リアルタイム通信セッションの間に喪失メディアの回復を選択的に試みるように構成されたユーザ機器(UE)であって、
前記UEに正しく到着しなかった、前記リアルタイム通信セッションに参加する別のUEからの喪失メディアパケットの存在を検出するように構成された論理と、
前記検出するステップに応答して前記喪失メディアパケットの回復に関連して複数の外部ソースからの任意の外部ソースに接触する前に、前記複数の外部ソースから少なくとも1つの外部ソースを動的に選択するために前記喪失メディアパケットに関連する回復基準値の組を評価するように構成された論理であって、前記少なくとも1つの外部ソースから、前記喪失メディアパケットは、回復基準値の前記組に基づいて前記喪失メディアパケットの回復を試みるために様々な予測信頼性および応答時間において回復され得る可能性がある、論理と、
前記評価に基づいて前記選択された少なくとも1つの外部ソースから前記喪失メディアパケットを回復しようと試みるように構成された論理と
を含む、ユーザ機器(UE)。
【請求項３０】
リアルタイム通信セッションの間に喪失メディアの回復を選択的に試みるように構成されたユーザ機器(UE)によって実行されるとき前記UEに動作を実行させる命令を記憶している、非一時的コンピュータ可読媒体であって、前記命令は、
前記UEに正しく到着しなかった、前記リアルタイム通信セッションに参加する別のUEからの喪失メディアパケットの存在を前記UEに検出させる少なくとも1つの命令と、
前記検出するステップに応答して前記喪失メディアパケットの回復に関連して複数の外部ソースからの任意の外部ソースに接触する前に、前記複数の外部ソースから少なくとも1つの外部ソースを動的に選択するために前記喪失メディアパケットに関連する回復基準値の組を前記UEに評価させる少なくとも1つの命令であって、前記少なくとも1つの外部ソースから、前記喪失メディアパケットは、回復基準値の前記組に基づいて前記喪失メディアパケットの回復を試みるために様々な予測信頼性および応答時間において回復され得る可能性がある、命令と、
前記評価に基づいて前記選択された少なくとも1つの外部ソースから前記喪失メディアパケットを前記UEに回復を試みさせる少なくとも1つの命令と
を含む、非一時的コンピュータ可読媒体。
【請求項３１】
前記喪失メディアパケットが回復され得る可能性がある前記複数の外部ソースは、前記リアルタイム通信セッションに同様に参加している1つまたは複数のリモートエンティティおよび1つまたは複数の様々なターゲットUEを含み、
前記1つまたは複数の様々なターゲットUEは、前記1つまたは複数のリモートエンティティと比較してより遅い応答時間を有し、
前記1つまたは複数のリモートエンティティは、前記1つまたは複数の様々なターゲットUEと比較してより高い予測信頼性を有し、
前記評価するステップは、前記喪失メディアパケットの再生が緊急でない場合は前記1つまたは複数のリモートエンティティから所与のリモートエンティティを動的に選択するステップと、前記喪失メディアパケットの再生が緊急である場合は前記1つまたは複数の様々なターゲットUEから所与のUEを動的に選択するステップとを含む、
請求項1に記載の方法。
【国際調査報告】
2016524352.tif 000023
2016524352.tif 000024
2016524352.tif 000025