(57)【要約】本開示は一般に、ボイスオーバインターネットプロトコル（ＶｏＩＰ）セッションおよび／または他の音声ベースのマルチメディアサービスに関してネットワークカバレッジを増加させるための様々な方法に関する。特に、音声セッションを確立するとき、２つ以上の端末は、サポートされたマルチメディアコーデックおよび／またはコーデックモード、ジッタバッファ管理（ＪＢＭ）、およびパケットロスコンシールメント（ＰＬＣ）能力に関する情報を交換するためにコーデック交渉を実施し得る。交換された情報に基づいて、各端末についての最大パケットロスレート（ＰＬＲ）を示すためのメッセージが基地局に送られ得る。追加的な技法は、異なる無線アクセス技術への不必要な、および／または過度なハンドオーバを回避するのを助けるために、カバレッジのエッジに接近するときに利用可能な最もロバストなコーデックまたはコーデックモードを端末が使用することを保証し得る。【選択図】図３
2020522940.tif 000002
【特許請求の範囲】
【請求項１】
第１のユーザ装置（ＵＥ）と第２のＵＥとの間のボイスオーバインターネットプロトコル（ＶｏＩＰ）セッションのためのネットワークカバレッジを増加させるための方法であって、
前記第１のＵＥと前記第２のＵＥとの間で、前記第１のＵＥと前記第２のＵＥとの間の前記ＶｏＩＰセッションで使用するためのコーデック構成を交渉することと、
前記第１のＵＥにおいて、前記交渉されたコーデック構成に少なくとも部分的に基づいて、受信される媒体について前記第１のＵＥおよび前記第２のＵＥが許容することができる最大エンドツーエンドパケットロスレート（ＰＬＲ）を決定することと、
前記第１のＵＥにおいて、前記第１のＵＥおよび前記第２のＵＥにおけるそれぞれのアップリンクおよびダウンリンクの間の前記最大エンドツーエンドＰＬＲの分配を決定することと、
前記第１のＵＥによって、サービング基地局に、前記決定された分配に従って、前記第１のＵＥから前記第２のＵＥへの方向に送信される媒体についてのアップリンクＰＬＲおよび前記第２のＵＥから前記第１のＵＥへの方向に送信される媒体についてのダウンリンクＰＬＲを要求するためのメッセージを送信することと、
を備える、方法。
【請求項２】
受信される媒体について前記第１のＵＥおよび前記第２のＵＥが許容することができる前記最大エンドツーエンドＰＬＲを決定することが、
前記第１のＵＥによって、前記第２のＵＥに、前記交渉されたコーデック構成を考慮して受信される媒体について前記第１のＵＥが許容することができる前記最大エンドツーエンドＰＬＲを送信することと、
前記第１のＵＥにおいて、前記第２のＵＥから、前記交渉されたコーデック構成を考慮して受信される媒体について前記第２のＵＥが許容することができる前記最大エンドツーエンドＰＬＲを受信することと、
を備える、請求項１に記載の方法。
【請求項３】
前記サービング基地局が、前記要求されるアップリンクＰＬＲおよび前記要求されるダウンリンクＰＬＲに少なくとも部分的に基づいて、前記ＶｏＩＰセッションについてのハンドオーバしきい値を確立するように構成される、請求項１に記載の方法。
【請求項４】
前記ハンドオーバしきい値が、単一無線音声呼連続性（ＳＲＶＣＣ）しきい値を備える、請求項３に記載の方法。
【請求項５】
前記最大エンドツーエンドＰＬＲが、前記第１のＵＥおよび前記第２のＵＥにおいて使用される、それぞれのパケットロスコンシールメント（ＰＬＣ）およびジッタバッファ管理（ＪＢＭ）インプリメンテーションにさらに基づく、請求項１に記載の方法。
【請求項６】
前記決定された分配が、アップリンクＰＬＲ対ダウンリンクＰＬＲ比を表す合意済み比（Ｒ）を備える、請求項１に記載の方法。
【請求項７】
前記合意済み比（Ｒ）に従って、前記サービング基地局に対して要求するための前記アップリンクＰＬＲおよび前記ダウンリンクＰＬＲを、
前記要求されるアップリンクＰＬＲが、受信される媒体について前記第２のＵＥが許容することができる前記最大エンドツーエンドＰＬＲ掛けるＲ／（Ｒ＋１）に等しく、
前記要求されるダウンリンクＰＬＲが、受信される媒体について前記第１のＵＥが許容することができる前記最大エンドツーエンドＰＬＲ掛ける１／（Ｒ＋１）に等しい、
ように計算することをさらに備える、請求項６に記載の方法。
【請求項８】
前記第１のＵＥおよび前記第２のＵＥは、セッション記述プロトコル（ＳＤＰ）を介して、前記それぞれのアップリンクおよびダウンリンクの間の前記最大エンドツーエンドＰＬＲの前記分配を、
前記サービング基地局に対して要求される前記アップリンクＰＬＲが、受信される媒体について前記第２のＵＥが許容することができる前記最大エンドツーエンドＰＬＲと、前記第２のＵＥが、それに関連したサービング基地局に対して要求するダウンリンクＰＬＲとの間の差より低いか、またはそれに等しく、
前記サービング基地局に対して要求される前記ダウンリンクＰＬＲが、受信される媒体について前記第１のＵＥが許容することができる前記最大エンドツーエンドＰＬＲと、前記第２のＵＥが、それに関連した前記サービング基地局に対して要求するアップリンクＰＬＲとの間の差より低いか、またはそれに等しい、
ように決定するように構成される、
請求項１に記載の方法。
【請求項９】
前記それぞれのアップリンクおよびダウンリンクの間の前記最大エンドツーエンドＰＬＲの前記分配を決定することが、
前記第１のＵＥによって、前記第２のＵＥに、受信される媒体について前記第１のＵＥが許容することができる前記最大エンドツーエンドＰＬＲ、前記サービング基地局に対して要求されるべき提案されるアップリンクＰＬＲ、および前記サービング基地局に対して要求されるべき提案されるダウンリンクＰＬＲを含むオファー側トライアドを示すＳＤＰオファーを送信することと、
前記第１のＵＥにおいて、前記第２のＵＥから、少なくとも、受信される媒体について前記第２のＵＥが許容することができる前記最大エンドツーエンドＰＬＲを示すＳＤＰアンサーを受信することと、ここにおいて、前記ＳＤＰアンサーが前記ＳＤＰオファーに示された前記オファー側トライアドとの合意を示すことに応答して、前記サービング基地局に対して要求される前記アップリンクＰＬＲおよび前記ダウンリンクＰＬＲが、前記提案されたアップリンクＰＬＲおよび前記提案されたダウンリンクＰＬＲに等しくなる、
を備える、請求項８に記載の方法。
【請求項１０】
前記ＳＤＰアンサーが、前記ＳＤＰオファーに示される前記提案されたダウンリンクＰＬＲと組み合わせられたとき、受信される媒体について前記第１のＵＥが許容することができる前記最大エンドツーエンドＰＬＲを完全には利用しない前記第２のＵＥについての提案されたアップリンクＰＬＲをさらに示す、請求項９に記載の方法。
【請求項１１】
前記ＳＤＰアンサーが、前記ＳＤＰオファーに示される前記提案されたアップリンクＰＬＲと組み合わせられたとき、受信される媒体について前記第２のＵＥが許容することができる前記最大エンドツーエンドＰＬＲを完全には利用しない前記第２のＵＥについての提案されたダウンリンクＰＬＲをさらに示す、請求項９に記載の方法。
【請求項１２】
前記それぞれのアップリンクおよびダウンリンクの間の前記最大エンドツーエンドＰＬＲの前記分配を決定することが、
前記第１のＵＥによって、前記第２のＵＥに、受信される媒体について前記第１のＵＥが許容することができる前記最大エンドツーエンドＰＬＲ、前記サービング基地局に対して要求されるべき提案されるアップリンクＰＬＲ、および前記サービング基地局に対して要求されるべき提案されるダウンリンクＰＬＲを含むオファー側トライアドを示すＳＤＰオファーを送信することと、
前記第１のＵＥにおいて、前記第２のＵＥから、前記サービング基地局に対して要求されるべき前記提案されたアップリンクＰＬＲおよび前記提案されたダウンリンクＰＬＲについての値を示すＳＤＰアンサーを受信することと、ここにおいて、前記ＳＤＰアンサーに示された前記値のうちの１つまたは複数は、受信される媒体について前記第２のＵＥが許容することができる前記最大エンドツーエンドＰＬＲ内に収まるように、前記ＳＤＰオファーから修正されている、
を備える、請求項８に記載の方法。
【請求項１３】
前記サービング基地局に対して要求される前記アップリンクＰＬＲおよび前記ダウンリンクＰＬＲが、前記ＳＤＰアンサーに示された前記値に等しい、請求項１２に記載の方法。
【請求項１４】
前記サービング基地局に対して要求される前記アップリンクおよびダウンリンクＰＬＲについての最大可能値および前記最大エンドツーエンドＰＬＲが、デバイスレベルにおいて、事前構成されるか、オープンモバイルアライアンスデバイス管理（ＯＭＡ−ＤＭ）を介して動的に構成されるか、またはセルにわたってブロードキャストされるネットワークＰＬＲコンディションに少なくとも部分的に基づくか、のうちの１つまたは複数である、請求項８に記載の方法。
【請求項１５】
前記第１のＵＥと前記第２のＵＥとの間の前記ＶｏＩＰセッションで使用するための前記コーデック構成を交渉することが、
前記第１のＵＥによって、前記第１のＵＥにおいてサポートされる最もロバストなコーデック構成を示す情報を送信すること、ここにおいて、前記サービング基地局は、前記第１のＵＥにおいてサポートされる前記最もロバストなコーデック構成に少なくとも部分的に基づいて、前記ＶｏＩＰセッションについてのハンドオーバしきい値を確立するように構成される、
を備える、請求項１に記載の方法。
【請求項１６】
前記第１のＵＥによって、前記第２のＵＥから前記第１のＵＥへの前記方向に送信される前記媒体についての増加したパケットロスを検出することと、
前記第１のＵＥによって、前記第２のＵＥに、前記第１のＵＥと第２のＵＥとの間で交渉されたビットレートに応じて、前記最もロバストなコーデック構成、アプリケーションレイヤ冗長性、または部分的な冗長性のうちの１つまたは複数を使用するための能力に順応することを求める要求を送ることと、
をさらに備える、請求項１５に記載の方法。
【請求項１７】
前記第１のＵＥにおいて、前記第１のＵＥと第２のＵＥとの間で交渉されたビットレートに応じて、前記最もロバストなコーデック構成、アプリケーションレイヤ冗長性、または部分的な冗長性のうちの１つまたは複数を使用するための能力に順応することを求める要求を受信することと、
前記第１のＵＥによって、前記要求に示された前記順応した能力に従って、前記第１のＵＥから前記第２のＵＥへの前記方向に媒体を送信することと、
をさらに備える、請求項１５に記載の方法。
【請求項１８】
前記第１のＵＥによって、低送信電力ヘッドルームまたはアップリンク送信バッファにおける増大のうちの１つまたは複数に基づいて、不良ネットワークカバレッジを検出することと、
前記第１のＵＥによって、前記第１のＵＥから前記第２のＵＥへの前記方向に媒体を送信するために、前記第１のＵＥにおいてサポートされる前記最もロバストなコーデック構成を使用することと、
をさらに備える、請求項１５に記載の方法。
【請求項１９】
装置であって、
ピアユーザ装置（ＵＥ）と、前記ピアＵＥとのボイスオーバインターネットプロトコル（ＶｏＩＰ）セッションで使用するためのコーデック構成を交渉することと、前記交渉されたコーデック構成に少なくとも部分的に基づいて、受信される媒体について前記装置および前記ピアＵＥが許容することができる最大エンドツーエンドパケットロスレート（ＰＬＲ）を決定することと、前記装置および前記ピアＵＥにおけるそれぞれのアップリンクおよびダウンリンクの間の前記最大エンドツーエンドＰＬＲの分配を決定することと、を行うように構成される、少なくとも１つのプロセッサと、
サービング基地局に、前記決定された分配に従って、前記装置から前記ピアＵＥへの方向に送信される媒体についてのアップリンクＰＬＲおよび前記ピアＵＥから前記装置への方向に送信される媒体についてのダウンリンクＰＬＲを要求するためのメッセージを送信するように構成されるトランシーバと、
を備える、装置。
【請求項２０】
前記トランシーバが、
前記ピアＵＥに、前記交渉されたコーデック構成を考慮して受信される媒体について前記装置が許容することができる前記最大エンドツーエンドＰＬＲを送信することと、
前記ピアＵＥから、前記交渉されたコーデック構成を考慮して受信される媒体について前記ピアＵＥが許容することができる前記最大エンドツーエンドＰＬＲを受信することと、
を行うようにさらに構成される、
請求項１９に記載の装置。
【請求項２１】
前記サービング基地局が、前記要求されるアップリンクＰＬＲおよび前記要求されるダウンリンクＰＬＲに少なくとも部分的に基づいて、前記ＶｏＩＰセッションについてのハンドオーバしきい値を確立するように構成される、請求項１９に記載の装置。
【請求項２２】
前記ハンドオーバしきい値が、単一無線音声呼連続性（ＳＲＶＣＣ）しきい値を備える、請求項２１に記載の装置。
【請求項２３】
前記最大エンドツーエンドＰＬＲが、前記装置および前記ピアＵＥにおいて使用される、それぞれのパケットロスコンシールメント（ＰＬＣ）およびジッタバッファ管理（ＪＢＭ）インプリメンテーションにさらに基づく、請求項１９に記載の装置。
【請求項２４】
前記決定された分配が、アップリンクＰＬＲ対ダウンリンクＰＬＲ比を表す合意済み比（Ｒ）を備える、請求項１９に記載の装置。
【請求項２５】
前記少なくとも１つのプロセッサが、前記合意済み比（Ｒ）に従って、前記サービング基地局に対して要求するための前記アップリンクＰＬＲおよび前記ダウンリンクＰＬＲを、
前記要求されるアップリンクＰＬＲが、受信される媒体について前記ピアＵＥが許容することができる前記最大エンドツーエンドＰＬＲ掛けるＲ／（Ｒ＋１）に等しく、
前記要求されるダウンリンクＰＬＲが、受信される媒体について前記装置が許容することができる前記最大エンドツーエンドＰＬＲ掛ける１／（Ｒ＋１）に等しい、
ように計算するようにさらに構成される、請求項２４に記載の装置。
【請求項２６】
前記装置および前記ピアＵＥは、セッション記述プロトコル（ＳＤＰ）を介して、前記それぞれのアップリンクおよびダウンリンクの間の前記最大エンドツーエンドＰＬＲの前記分配を、
前記サービング基地局に対して要求される前記アップリンクＰＬＲが、受信される媒体について前記ピアＵＥが許容することができる前記最大エンドツーエンドＰＬＲと、前記ピアＵＥが、それに関連したサービング基地局に対して要求するダウンリンクＰＬＲとの間の差より低いか、またはそれに等しく、
前記サービング基地局に対して要求される前記ダウンリンクＰＬＲが、受信される媒体について前記装置が許容することができる前記最大エンドツーエンドＰＬＲと、前記ピアＵＥが、それに関連した前記サービング基地局に対して要求するアップリンクＰＬＲとの間の差より低いか、またはそれに等しい、
ように決定するように構成される、請求項１９に記載の装置。
【請求項２７】
前記トランシーバが、
前記ピアＵＥに、受信される媒体について前記装置が許容することができる前記最大エンドツーエンドＰＬＲ、前記サービング基地局に対して要求されるべき提案されるアップリンクＰＬＲ、および前記サービング基地局に対して要求されるべき提案されるダウンリンクＰＬＲを含むオファー側トライアドを示すＳＤＰオファーを送信することと、
前記ピアＵＥから、少なくとも、受信される媒体について前記ピアＵＥが許容することができる前記最大エンドツーエンドＰＬＲを示すＳＤＰアンサーを受信することと、ここにおいて、前記ＳＤＰアンサーが前記ＳＤＰオファーに示された前記オファー側トライアドとの合意を示すことに応答して、前記サービング基地局に対して要求される前記アップリンクＰＬＲおよび前記ダウンリンクＰＬＲが、前記提案されたアップリンクＰＬＲおよび前記提案されたダウンリンクＰＬＲに等しくなる、
を行うようにさらに構成される、請求項２６に記載の装置。
【請求項２８】
前記ＳＤＰアンサーが、前記ＳＤＰオファーに示される前記提案されたダウンリンクＰＬＲと組み合わせられたとき、受信される媒体について前記装置が許容することができる前記最大エンドツーエンドＰＬＲを完全には利用しない前記ピアＵＥについての提案されたアップリンクＰＬＲをさらに示す、請求項２７に記載の装置。
【請求項２９】
前記ＳＤＰアンサーが、前記ＳＤＰオファーに示される前記提案されたアップリンクＰＬＲと組み合わせられたとき、受信される媒体について前記ピアＵＥが許容することができる前記最大エンドツーエンドＰＬＲを完全には利用しない前記ピアＵＥについての提案されたダウンリンクＰＬＲをさらに示す、請求項２７に記載の装置。
【請求項３０】
前記トランシーバが、
前記ピアＵＥに、受信される媒体について前記装置が許容することができる前記最大エンドツーエンドＰＬＲ、前記サービング基地局に対して要求されるべき提案されるアップリンクＰＬＲ、および前記サービング基地局に対して要求されるべき提案されるダウンリンクＰＬＲを含むオファー側トライアドを示すＳＤＰオファーを送信することと、
前記ピアＵＥから、前記サービング基地局に対して要求されるべき前記提案されたアップリンクＰＬＲおよび前記提案されたダウンリンクＰＬＲについての値を示すＳＤＰアンサーを受信することと、ここにおいて、前記ＳＤＰアンサーに示された前記値のうちの１つまたは複数は、受信される媒体について前記ピアＵＥが許容することができる前記最大エンドツーエンドＰＬＲ内に収まるように、前記ＳＤＰオファーから修正されている、
を行うようにさらに構成される、請求項２６に記載の装置。
【請求項３１】
前記サービング基地局に対して要求される前記アップリンクＰＬＲおよび前記ダウンリンクＰＬＲが、前記ＳＤＰアンサーに示された前記値に等しい、請求項３０に記載の装置。
【請求項３２】
前記サービング基地局に対して要求される前記アップリンクおよびダウンリンクＰＬＲについての最大可能値および前記最大エンドツーエンドＰＬＲが、デバイスレベルにおいて、事前構成されるか、オープンモバイルアライアンスデバイス管理（ＯＭＡ−ＤＭ）を介して動的に構成されるか、またはセルにわたってブロードキャストされるネットワークＰＬＲコンディションに少なくとも部分的に基づくか、のうちの１つまたは複数である、請求項２６に記載の装置。
【請求項３３】
前記トランシーバが、
前記サービング基地局または前記ピアＵＥのうちの１つまたは複数に、前記装置においてサポートされる最もロバストなコーデック構成を示す情報を送信すること、ここにおいて、前記サービング基地局が、前記装置においてサポートされる前記最もロバストなコーデック構成に少なくとも部分的に基づいて、前記ＶｏＩＰセッションについてのハンドオーバしきい値を確立するように構成される、
を行うようにさらに構成される、請求項１９に記載の装置。
【請求項３４】
前記トランシーバが、
前記ピアＵＥに、前記ピアＵＥから前記装置への前記方向に送信される前記媒体についてのパケットロスの増加に応答して、前記第１のＵＥとピアＵＥとの間で交渉されたビットレートに応じて、前記最もロバストなコーデック構成、アプリケーションレイヤ冗長性、または部分的な冗長性のうちの１つまたは複数を使用するための能力に順応することを求める要求を送ること、
を行うようにさらに構成される、請求項３３に記載の装置。
【請求項３５】
前記トランシーバが、
前記第１のＵＥとピアＵＥとの間で交渉されたビットレートに応じて、前記最もロバストなコーデック構成、アプリケーションレイヤ冗長性、または部分的な冗長性のうちの１つまたは複数を使用するための能力に順応することを求める要求を受信することと、
前記要求に示された前記順応した能力に従って、前記装置から前記ピアＵＥへの前記方向に媒体を送信することと、
を行うようにさらに構成される、請求項３３に記載の装置。
【請求項３６】
前記少なくとも１つのプロセッサが、
低送信電力ヘッドルームまたはアップリンク送信バッファにおける増大のうちの１つまたは複数に基づいて不良ネットワークカバレッジを検出することと、
前記装置から前記ピアＵＥへの前記方向に媒体を送信するために、前記装置においてサポートされる前記最もロバストなコーデック構成を使用することと、
を行うようにさらに構成される、請求項３３に記載の装置。
【請求項３７】
第１のユーザ装置（ＵＥ）と第２のＵＥとの間のボイスオーバインターネットプロトコル（ＶｏＩＰ）セッションのためのネットワークカバレッジを増加させるための方法であって、
前記第１のＵＥにサービス提供しているネットワーク要素によって、前記第１のＵＥと前記第２のＵＥとの間のコーデック構成交渉をモニタすることと、ここにおいて、前記コーデック構成交渉は、前記交渉されたコーデック構成に少なくとも部分的に基づいて、受信される媒体について前記第１のＵＥおよび前記第２のＵＥが許容することができる最大エンドツーエンドパケットロスレート（ＰＬＲ）の交換を含む、
前記ネットワーク要素によって、前記第１のＵＥおよび前記第２のＵＥにおけるそれぞれのアップリンクおよびダウンリンクの間の前記最大エンドツーエンドＰＬＲの合意済み分配を決定することと、
前記ネットワーク要素によって、前記第１のＵＥにサービス提供している基地局に、前記合意済み分配に従って、前記第１のＵＥから前記第２のＵＥへの方向に送信される媒体についてのアップリンクＰＬＲおよび前記第２のＵＥから前記第１のＵＥへの方向に送信される媒体についてのダウンリンクＰＬＲを要求するためのメッセージを送信することと、
を備える、方法。
【請求項３８】
前記第１のＵＥにサービス提供している前記基地局が、前記要求されるアップリンクＰＬＲおよび前記要求されるダウンリンクＰＬＲに少なくとも部分的に基づいて、前記ＶｏＩＰセッションについてのハンドオーバしきい値を確立するように構成される、請求項３７に記載の方法。
【請求項３９】
前記ハンドオーバしきい値が、単一無線音声呼連続性（ＳＲＶＣＣ）しきい値を備える、請求項３８に記載の方法。
【請求項４０】
前記最大エンドツーエンドＰＬＲが、前記第１のＵＥおよび前記第２のＵＥにおいて使用される、それぞれのパケットロスコンシールメント（ＰＬＣ）およびジッタバッファ管理（ＪＢＭ）インプリメンテーションにさらに基づく、請求項３７に記載の方法。
【請求項４１】
前記合意済み分配が、アップリンクＰＬＲ対ダウンリンクＰＬＲ比を表す合意済み比（Ｒ）を備える、請求項３７に記載の方法。
【請求項４２】
前記合意済み比（Ｒ）に従って、前記サービング基地局に対して要求するための前記アップリンクＰＬＲおよび前記ダウンリンクＰＬＲを、
前記要求されるアップリンクＰＬＲが、受信される媒体について前記第２のＵＥが許容することができる前記最大エンドツーエンドＰＬＲ掛けるＲ／（Ｒ＋１）に等しく、
前記要求されるダウンリンクＰＬＲが、受信される媒体について前記第１のＵＥが許容することができる前記最大エンドツーエンドＰＬＲ掛ける１／（Ｒ＋１）に等しい、
ように計算することをさらに備える、請求項４１に記載の方法。
【請求項４３】
前記第１のＵＥおよび前記第２のＵＥが、セッション記述プロトコル（ＳＤＰ）を介して、前記それぞれのアップリンクおよびダウンリンクの間の前記最大エンドツーエンドＰＬＲの前記合意済み分配を、
前記要求されるアップリンクＰＬＲが、受信される媒体について前記第２のＵＥが許容することができる前記最大エンドツーエンドＰＬＲと、前記第２のＵＥが、それに関連したサービング基地局に対して要求するダウンリンクＰＬＲとの間の差より低いか、またはそれに等しく、
前記要求されるダウンリンクＰＬＲが、受信される媒体について前記第１のＵＥが許容することができる前記最大エンドツーエンドＰＬＲと、前記第２のＵＥが、それに関連した前記サービング基地局に対して要求するアップリンクＰＬＲとの間の差より低いか、またはそれに等しい、
ように交渉するように構成される、請求項３７に記載の方法。
【請求項４４】
少なくとも、受信される媒体について前記第１のＵＥおよび前記第２のＵＥが許容することができる前記最大エンドツーエンドＰＬＲ、および少なくとも１つのアップリンクおよび少なくとも１つのダウンリンクについての合意済みの値を指定するＳＤＰアンサーから、前記第１のＵＥにサービス提供している前記基地局に対して要求するための、前記アップリンクＰＬＲおよび前記ダウンリンクＰＬＲを抽出することをさらに備える、請求項４３に記載の方法。
【請求項４５】
セッション記述プロトコル（ＳＤＰ）を介して、前記第２のＵＥにサービス提供しているネットワーク要素と、前記それぞれのアップリンクおよびダウンリンクの間の前記最大エンドツーエンドＰＬＲの前記合意済み分配を交渉することをさらに備える、請求項３７に記載の方法。
【請求項４６】
前記最大エンドツーエンドＰＬＲの前記合意済み分配を交渉することが、
前記ネットワーク要素において、受信される媒体について前記第１のＵＥが許容することができる前記最大エンドツーエンドＰＬＲを示す前記第１のＵＥによって送信されたＳＤＰオファーを受信することと、
前記ネットワーク要素において、オペレータポリシーに基づいて、前記第１のＵＥにサービス提供している前記基地局から前記第１のＵＥへの前記ダウンリンクに割り振るための、受信される媒体について前記第１のＵＥが許容することができる前記最大エンドツーエンドＰＬＲの比率を決定することと、
前記ネットワーク要素において、前記オペレータポリシーに基づいて、前記第１のＵＥから前記第１のＵＥにサービス提供している前記基地局への前記アップリンクについての好ましいＰＬＲを決定することと、
前記ネットワーク要素によって、前記第１のＵＥへの前記ダウンリンクに割り振るための前記決定された比率および前記第１のＵＥからの前記アップリンクについての前記好ましいＰＬＲを示すように前記ＳＤＰオファーを修正することと、
前記ネットワーク要素によって、前記第２のＵＥにサービス提供しているネットワーク要素に、前記修正されたＳＤＰオファーを送信することと、
を備える、請求項４５に記載の方法。
【請求項４７】
前記最大エンドツーエンドＰＬＲの前記合意済み分配を交渉することが、
前記ネットワーク要素において、前記第２のＵＥにサービス提供している前記ネットワーク要素からＳＤＰアンサーを受信することと、ここにおいて、前記ＳＤＰアンサーは、前記第２のＵＥについての提案されたアップリンクＰＬＲを含む、
前記ネットワーク要素によって、前記第２のＵＥについての前記提案されたアップリンクＰＬＲが、受信される媒体について前記第１のＵＥが許容することができる前記最大エンドツーエンドＰＬＲと、前記第１のＵＥへの前記ダウンリンクに割り振られた前記最大エンドツーエンドＰＬＲの前記比率との間の差より低いか、またはそれに等しいことを決定することに応答して、前記ＳＤＰアンサーを受け入れることと、
をさらに備える、請求項４６に記載の方法。
【請求項４８】
前記最大エンドツーエンドＰＬＲの前記合意済み分配を交渉することが、
前記ネットワーク要素において、前記第２のＵＥにサービス提供している前記ネットワーク要素からＳＤＰアンサーを受信することと、ここにおいて、前記ＳＤＰアンサーは、前記第２のＵＥについての提案されたアップリンクＰＬＲを含む、
前記ネットワーク要素によって、前記第２のＵＥについての前記提案されたアップリンクＰＬＲが、受信される媒体について前記第１のＵＥが許容することができる前記最大エンドツーエンドＰＬＲと、前記第１のＵＥへの前記ダウンリンクに割り振られた前記最大エンドツーエンドＰＬＲの前記比率との間の差を超えると決定することに応答して、前記ＳＤＰアンサーを拒否することと、
をさらに備える、請求項４６に記載の方法。
【請求項４９】
前記最大エンドツーエンドＰＬＲの前記合意済み分配が、受信される媒体について前記第１のＵＥおよび前記第２のＵＥが許容することができる前記最大エンドツーエンドＰＬＲのうちの１つまたは複数を完全には利用しない、請求項４５に記載の方法。
【請求項５０】
装置であって、
前記装置によってサービス提供される第１のユーザ装置（ＵＥ）と第２のＵＥとの間のコーデック構成交渉をモニタするように構成される少なくとも１つのプロセッサと、ここにおいて、前記コーデック構成交渉は、前記交渉されたコーデック構成に少なくとも部分的に基づいて、受信される媒体について前記第１のＵＥおよび前記第２のＵＥが許容することができる最大エンドツーエンドパケットロスレート（ＰＬＲ）の交換を含み、前記少なくとも１つのプロセッサはさらに、前記第１のＵＥおよび前記第２のＵＥにおけるそれぞれのアップリンクおよびダウンリンクの間の前記最大エンドツーエンドＰＬＲの合意済み分配を決定するように構成される、
前記第１のＵＥにサービス提供している基地局に、前記合意済み分配に従って、前記第１のＵＥから前記第２のＵＥへの方向に送信される媒体についてのアップリンクＰＬＲおよび前記第２のＵＥから前記第１のＵＥへの方向に送信される媒体についてのダウンリンクＰＬＲを要求するためのメッセージを送信するように構成されるトランシーバと、
を備える、装置。
【請求項５１】
前記第１のＵＥにサービス提供している前記基地局が、前記要求されるアップリンクＰＬＲおよび前記要求されるダウンリンクＰＬＲに少なくとも部分的に基づいて、前記第１のＵＥと前記第２のＵＥとの間のボイスオーバインターネットプロトコル（ＶｏＩＰ）セッションについてのハンドオーバしきい値を確立するように構成される、請求項５０に記載の装置。
【請求項５２】
前記ハンドオーバしきい値が、単一無線音声呼連続性（ＳＲＶＣＣ）しきい値を備える、請求項５１に記載の装置。
【請求項５３】
最大エンドツーエンドＰＬＲが、前記第１のＵＥおよび前記第２のＵＥにおいて使用される、それぞれのパケットロスコンシールメント（ＰＬＣ）およびジッタバッファ管理（ＪＢＭ）インプリメンテーションにさらに基づく、請求項５０に記載の装置。
【請求項５４】
前記合意済み分配が、アップリンクＰＬＲ対ダウンリンクＰＬＲ比を表す合意済み比（Ｒ）を備える、請求項５０に記載の装置。
【請求項５５】
前記少なくとも１つのプロセッサが、前記合意済み比（Ｒ）に従って、前記サービング基地局に対して要求するための前記アップリンクＰＬＲおよび前記ダウンリンクＰＬＲを、
前記要求されるアップリンクＰＬＲが、受信される媒体について前記第２のＵＥが許容することができる前記最大エンドツーエンドＰＬＲ掛けるＲ／（Ｒ＋１）に等しく、
前記要求されるダウンリンクＰＬＲが、受信される媒体について前記第１のＵＥが許容することができる前記最大エンドツーエンドＰＬＲ掛ける１／（Ｒ＋１）に等しい、
ように計算するようにさらに構成される、請求項５４に記載の装置。
【請求項５６】
前記第１のＵＥおよび前記第２のＵＥが、セッション記述プロトコル（ＳＤＰ）を介して、前記それぞれのアップリンクおよびダウンリンクの間の前記最大エンドツーエンドＰＬＲの前記合意済み分配を、
前記要求されるアップリンクＰＬＲが、受信される媒体について前記第２のＵＥが許容することができる前記最大エンドツーエンドＰＬＲと、前記第２のＵＥが、それに関連したサービング基地局に対して要求するダウンリンクＰＬＲとの間の差より低いか、またはそれに等しく、
前記要求されるダウンリンクＰＬＲが、受信される媒体について前記第１のＵＥが許容することができる前記最大エンドツーエンドＰＬＲと、前記第２のＵＥが、それに関連した前記サービング基地局に対して要求するアップリンクＰＬＲとの間の差より低いか、またはそれに等しい、
ように交渉するように構成される、請求項５０に記載の装置。
【請求項５７】
前記少なくとも１つのプロセッサが、少なくとも、受信される媒体について前記第１のＵＥおよび前記第２のＵＥが許容することができる前記最大エンドツーエンドＰＬＲ、および少なくとも１つのアップリンクおよび少なくとも１つのダウンリンクについての合意済みの値を指定するＳＤＰアンサーから、前記第１のＵＥにサービス提供している前記基地局に対して要求するための、前記アップリンクＰＬＲおよび前記ダウンリンクＰＬＲを抽出するようにさらに構成される、請求項５６に記載の装置。
【請求項５８】
前記少なくとも１つのプロセッサが、セッション記述プロトコル（ＳＤＰ）を介して、前記第２のＵＥにサービス提供しているネットワーク要素と、前記それぞれのアップリンクおよびダウンリンクの間の前記最大エンドツーエンドＰＬＲの前記合意済み分配を交渉するようにさらに構成される、請求項５０に記載の装置。
【請求項５９】
前記少なくとも１つのプロセッサが、
前記トランシーバを介して、受信される媒体について前記第１のＵＥが許容することができる前記最大エンドツーエンドＰＬＲを示す前記第１のＵＥによって送信されたＳＤＰオファーを受信することと、
オペレータポリシーに基づいて、前記第１のＵＥにサービス提供している前記基地局から前記第１のＵＥへの前記ダウンリンクに割り振るための、受信される媒体について前記第１のＵＥが許容することができる前記最大エンドツーエンドＰＬＲの比率を決定することと、
前記オペレータポリシーに基づいて、前記第１のＵＥから前記第１のＵＥにサービス提供している前記基地局への前記アップリンクについての好ましいＰＬＲを決定することと、
前記第１のＵＥへの前記ダウンリンクに割り振るための前記決定された比率および前記第１のＵＥからの前記アップリンクについての前記好ましいＰＬＲを示すように前記ＳＤＰオファーを修正することと、
前記トランシーバを介して、前記第２のＵＥにサービス提供しているネットワーク要素に、前記修正されたＳＤＰオファーを送信することと、
を行うようにさらに構成される、請求項５８に記載の装置。
【請求項６０】
前記少なくとも１つのプロセッサが、
前記トランシーバを介して、前記第２のＵＥにサービス提供している前記ネットワーク要素からＳＤＰアンサーを受信することと、ここにおいて、前記ＳＤＰアンサーが、前記第２のＵＥについての提案されたアップリンクＰＬＲを含む、
前記第２のＵＥについての前記提案されたアップリンクＰＬＲが、受信される媒体について前記第１のＵＥが許容することができる前記最大エンドツーエンドＰＬＲと、前記第１のＵＥへの前記ダウンリンクに割り振られた前記最大エンドツーエンドＰＬＲの前記比率との間の差より低いか、またはそれに等しいことに応答して、前記ＳＤＰアンサーを受け入れることと、
を行うようにさらに構成される、請求項５９に記載の装置。
【請求項６１】
前記少なくとも１つのプロセッサが、
前記トランシーバを介して、前記第２のＵＥにサービス提供している前記ネットワーク要素からＳＤＰアンサーを受信することと、ここにおいて、前記ＳＤＰアンサーが、前記第２のＵＥについての提案されたアップリンクＰＬＲを含む、
前記第２のＵＥについての前記提案されたアップリンクＰＬＲが、受信される媒体について前記第１のＵＥが許容することができる前記最大エンドツーエンドＰＬＲと、前記第１のＵＥへの前記ダウンリンクに割り振られた前記最大エンドツーエンドＰＬＲの前記比率との間の差を超えることに応答して、前記ＳＤＰアンサーを拒否することと、
を行うようにさらに構成される、請求項５９に記載の装置。
【請求項６２】
前記最大エンドツーエンドＰＬＲの前記合意済み分配が、受信される媒体について前記第１のＵＥおよび前記第２のＵＥが許容することができる前記最大エンドツーエンドＰＬＲのうちの１つまたは複数を完全には利用しない、請求項５８に記載の装置。
【発明の詳細な説明】
【技術分野】
【０００１】
［関連出願の相互参照］
[0001]  本出願は、「METHODS FOR INCREASING VOIP NETWORK COVERAGE」と題されて２０１７年６月５日に出願された米国仮出願第６２／５１５，３４２号、「METHODS FOR INCREASING VOIP NETWORK COVERAGE」と題されて２０１７年１０月３日に出願された米国仮出願第６２／５６７，６１３号、および「METHODS FOR INCREASING VOIP NETWORK COVERAGE」と題されて２０１８年３月３０日に出願された米国仮出願第６２／６５１，０４５号の利益を主張し、それらは各々本願の譲受人に譲渡され、それらの内容は各々、これにより全体が参照によって明示的に組み込まれる。
【０００２】
［技術分野］
[0002]  ここに説明される様々な態様および実施形態は一般に、ワイヤレス通信に関し、特に、ボイスオーバインターネットプロトコル（ＶｏＩＰ）セッションおよび／または他の音声ベースのマルチメディアサービスのためのネットワークカバレッジを増加させることに関する。
【背景技術】
【０００３】
[0003]  ワイヤレス通信システムは、第１世代アナログワイヤレス電話サービス（１Ｇ）、第２世代（２Ｇ）デジタルワイヤレス電話サービス（中間の２．５Ｇおよび２．７５Ｇネットワークを含む）、および第３世代（３Ｇ）および第４世代（４Ｇ）高速データおよびインターネット対応ワイヤレスサービスを含む、様々な世代を通して開発されてきた。セルラおよびパーソナル通信サービス（ＰＣＳ）システムを含む、多くのワイヤレス通信システムが使用されている。例示的なセルラシステムは、セルラアナログアドバンストモバイル電話システム（ＡＭＰＳ）と、符号分割多元接続（ＣＤＭＡ）、周波数分割多元接続（ＦＤＭＡ）、時分割多元接続（ＴＤＭＡ）、ＴＤＭＡのＧＳＭ（登録商標）（Global System for Mobile access）バリエーションに基づくデジタルセルラシステムと、ＴＤＭＡおよびＣＤＭＡ技術の両方を使用するより新しいハイブリッドデジタル通信システムとを含む。つい最近、高速でデータを通信するための携帯電話および他の端末のためのワイヤレス通信プロトコルとしてロングタームエボリューション（ＬＴＥ（登録商標））が開発された。ＬＴＥはＧＳＭに基づき、様々なＧＳＭ関連プロトコル、例えばＧＳＭエボリューションのための向上されたデータレート（ＥＤＧＥ）、およびユニバーサルモバイル電気通信システム（ＵＭＴＳ）プロトコル、例えば高速パケットアクセス（ＨＳＰＡ）からの貢献を含む。
【０００４】
[0004]  第５世代（５Ｇ）モバイル規格は、現在策定中であり、数ある改善の内でも特に、より速いデータ転送速度、より多くの接続、およびより良いカバレッジを要求する。次世代モバイルネットワークアライアンスによる５Ｇ規格は、オフィスフロアの何十人もの雇用者に対して１秒あたり１ギガビットを提供して、何万ものユーザの各々に１秒あたり数十メガビットのデータレートを提供することが期待されている。大きなセンサ展開をサポートするために、数十万の同時の接続がサポートされるべきである。その結果、５Ｇモバイル通信のスペクトル効率は、現在の４Ｇ規格に比べて著しく向上されるべきである。さらに、現在の規格に比べてシグナリング効率が向上されるべきであり、レイテンシが十分に低減されるべきである。
【発明の概要】
【０００５】
[0005]  以下は、ここに開示される１つまたは複数の態様および／または実施形態に関する簡略化された概要を提示する。したがって、以下の概要は、すべての考慮された態様および／または実施形態に関する広範な概観と見なされるべきではなく、また以下の概要は、すべての考慮された態様および／または実施形態に関係する主要または重要な要素を特定するように、あるいは任意の特定の態様および／または実施形態に関連する範囲を詳細に叙述するように考えられるべきでもない。したがって、以下の概要は、ここに開示されたメカニズムに関係する１つまたは複数の態様および／または実施形態に関係するある特定の概念を、以下に提示される詳細な説明に先立って、簡略化された形式で提示することを唯一の目的としている。
【０００６】
[0006]  様々な態様によれば、本開示は一般に、ボイスオーバインターネットプロトコル（ＶｏＩＰ）セッションおよび／または他の音声ベースのマルチメディアサービスに関してネットワークカバレッジを増加させるための様々な方法に関する。特に、音声セッションを確立するとき、２つ以上の端末は、サポートされたマルチメディアコーデックおよび／またはコーデックモード、ジッタバッファ管理（ＪＢＭ）、およびパケットロスコンシールメント（ＰＬＣ）能力に関する情報を交換するためにコーデック交渉を実施し得る。交換された情報に基づいて、各端末についての最大パケットロスレート（ＰＬＲ）を示すためのメッセージが基地局に送られ得る。追加的な技法は、不必要および／または過度なハンドオーバを回避するのを助けるために、カバレッジのエッジに接近するときに利用可能な最もロバストなコーデックまたはコーデックモードを端末が使用することを保証し得る。
【０００７】
[0007]  例えば、様々な態様によれば、第１のユーザ装置（ＵＥ）と第２のＵＥとの間のＶｏＩＰセッションのためのネットワークカバレッジを増加させるための方法は、第１のＵＥと第２のＵＥとの間で、第１のＵＥと第２のＵＥとの間のＶｏＩＰセッションで使用するためのコーデック構成を交渉することと、第１のＵＥにおいて、交渉されたコーデック構成に少なくとも部分的に基づいて、受信される媒体について第１のＵＥおよび第２のＵＥが許容することができる最大エンドツーエンドＰＬＲを決定することと、第１のＵＥにおいて、第１のＵＥおよび第２のＵＥにおけるそれぞれのアップリンクおよびダウンリンクの間の最大エンドツーエンドＰＬＲの分配を決定することと、第１のＵＥによって、サービング基地局に、決定された分配に従って、第１のＵＥから第２のＵＥへの方向に送信される媒体についてのアップリンクＰＬＲおよび第２のＵＥから第１のＵＥへの方向に送信される媒体についてのダウンリンクＰＬＲを要求するためのメッセージを送信することと、を備え得る。さらに、様々な実施形態において、最大エンドツーエンドＰＬＲは、第１のＵＥおよび第２のＵＥにおいて使用されるそれぞれのＰＬＣおよびＪＢＭインプリメンテーションにさらに基づき得る。一態様では、受信される媒体について第１のＵＥおよび第２のＵＥが許容することができる最大エンドツーエンドＰＬＲを決定することは、第１のＵＥによって、第２のＵＥに、交渉されたコーデック構成を考慮して受信される媒体について第１のＵＥが許容することができる最大エンドツーエンドＰＬＲを送信することと、第１のＵＥにおいて第２のＵＥから、交渉されたコーデック構成を考慮して受信される媒体について第２のＵＥが許容することができる最大エンドツーエンドＰＬＲを受信することと、を備え得る。一態様では、サービング基地局は、要求されるアップリンクＰＬＲおよび要求されるダウンリンクＰＬＲに少なくとも部分的に基づいて、ＶｏＩＰセッションについてのハンドオーバしきい値（例えば、単一無線音声呼連続性（ＳＲＶＣＣ）しきい値）を確立するように構成され得る。
【０００８】
[0008]  様々な態様によれば、第１のＵＥと第２のＵＥとの間のＶｏＩＰセッションのためのネットワークカバレッジを増加させるための別の方法は、第１のＵＥにサービス提供しているネットワーク要素によって、第１のＵＥと第２のＵＥとの間のコーデック構成交渉をモニタすること、ここにおいて、コーデック構成交渉は、交渉されたコーデック構成に少なくとも部分的に基づいて、受信される媒体について第１のＵＥおよび第２のＵＥが許容することができる最大エンドツーエンドＰＬＲの交換を含み、最大エンドツーエンドＰＬＲは、第１のＵＥおよび第２のＵＥにおいて使用されるそれぞれのＰＬＣおよびＪＢＭインプリメンテーションにさらに基づき得る、と、ネットワーク要素によって、第１のＵＥおよび第２のＵＥにおけるそれぞれのアップリンクおよびダウンリンクの間の最大エンドツーエンドＰＬＲの合意済み分配を決定することと、ネットワーク要素によって、第１のＵＥにサービス提供している基地局に、合意済み分配に従って、第１のＵＥから第２のＵＥへの方向に送信される媒体についてのアップリンクＰＬＲおよび第２のＵＥから第１のＵＥへの方向に送信される媒体についてのダウンリンクＰＬＲを要求するためのメッセージを送信することと、を備え得る。第１のＵＥにサービス提供している基地局は、ゆえに、要求されるアップリンクＰＬＲおよび要求されるダウンリンクＰＬＲに少なくとも部分的に基づいて、ＶｏＩＰセッションについてのハンドオーバしきい値（例えば、単一無線音声呼連続性（ＳＲＶＣＣ）しきい値）を確立するように構成され得る。
【０００９】
[0009]  様々な態様によれば、上記の方法では、それぞれのアップリンクおよびダウンリンクの間の最大エンドツーエンドＰＬＲの分配は、アップリンクＰＬＲ対ダウンリンクＰＬＲ比を表す合意済み比（Ｒ）を備え得る。そのようなケースでは、サービング基地局に対して要求するためのアップリンクＰＬＲおよびダウンリンクＰＬＲは、合意済み比（Ｒ）に従って、要求されるアップリンクＰＬＲが、受信される媒体について第２のＵＥが許容することができる最大エンドツーエンドＰＬＲ掛けるＲ／（Ｒ＋１）に等しいように、および要求されるダウンリンクＰＬＲが、受信される媒体について第１のＵＥが許容することができる最大エンドツーエンドＰＬＲ掛ける１／（Ｒ＋１）に等しいように、（例えば要求しているＵＥまたは要求しているネットワーク要素によって）計算され得る。１つの代替的な態様では、第１のＵＥおよび第２のＵＥは、サービング基地局に対して要求されるアップリンクＰＬＲが、受信される媒体について第２のＵＥが許容することができる最大エンドツーエンドＰＬＲと、第２のＵＥが、それに関連したサービング基地局に対して要求するダウンリンクＰＬＲとの間の差より低いか、またはそれに等しいように、およびサービング基地局に対して要求されるダウンリンクＰＬＲが、受信される媒体について第１のＵＥが許容することができる最大エンドツーエンドＰＬＲと、第２のＵＥが、それに関連したサービング基地局に対して要求するアップリンクＰＬＲとの間の差より低いか、またはそれに等しいように、セッション記述プロトコル（ＳＤＰ）を介して、それぞれのアップリンクおよびダウンリンクの間の最大エンドツーエンドＰＬＲの分配を決定するように構成され得る。
【００１０】
[0010]  様々な態様によれば、ネットワーク要素は、セッション記述プロトコル（ＳＤＰ）を介して、第２のＵＥにサービス提供しているネットワーク要素と、それぞれのアップリンクおよびダウンリンクの間の最大エンドツーエンドＰＬＲの合意済み分配を交渉し得、それは、ネットワーク要素において、受信される媒体について第１のＵＥが許容することができる最大エンドツーエンドＰＬＲを示す、第１のＵＥによって送信されたＳＤＰオファーを受信することと、ネットワーク要素において、オペレータポリシーに基づいて、第１のＵＥにサービス提供している基地局から第１のＵＥへのダウンリンクに割り振るための、受信される媒体について第１のＵＥが許容することができる最大エンドツーエンドＰＬＲの比率を決定することと、ネットワーク要素において、オペレータポリシーに基づいて、第１のＵＥから第１のＵＥにサービス提供している基地局へのアップリンクについての好ましいＰＬＲを決定することと、ネットワーク要素によって、第１のＵＥへのダウンリンクに割り振るための決定された比率および第１のＵＥからのアップリンクについての好ましいＰＬＲを示すようにＳＤＰオファーを修正することと、ネットワーク要素によって、第２のＵＥにサービス提供しているネットワーク要素に、修正されたＳＤＰオファーを送信することと、を備え得る。ネットワーク要素は次いで、第２のＵＥにサービス提供しているネットワーク要素から、第２のＵＥについての提案されたアップリンクＰＬＲを含むＳＤＰアンサーを受信し、第２のＵＥについての提案されたアップリンクＰＬＲが、受信される媒体について第１のＵＥが許容することができる最大エンドツーエンドＰＬＲと、第１のＵＥへのダウンリンクに割り振られた最大エンドツーエンドＰＬＲの比率との間の差より低いか、またはそれに等しいかどうかに応じて、ＳＤＰアンサーを受け入れるかまたは拒否し得る。
【００１１】
[0011]  ここに開示される態様および実施形態に関連する他の目的および利点は、添付の図面および詳細な説明に基づいて、当業者に明らかとなる。
【００１２】
[0012]  ここに説明される様々な態様および実施形態およびそれに付随する多くの利点についてのより完全な理解は、限定のためではなく例示のためだけに提示されている添付の図面に関連して考慮されたときに、以下の詳細な説明を参照することによってそれらがより良く理解されるようになるので、容易に得られることになる。
【図面の簡単な説明】
【００１３】
【図１】[0013]  図１は、様々な態様によれる、音声ベースのマルチメディアサービスをサポートし得るワイヤレス通信システムの高レベルシステムアーキテクチャを例示する。
【図２】[0014]  図２は、様々な態様によれる、音声ベースのマルチメディアサービスをサポートし得る例示的なワイヤレスネットワークアーキテクチャを例示する。
【図３】[0015]  図３は、様々な態様によれる、音声ベースのマルチメディアセッションに携わっている２つの端末間の例示的なエンドツーエンド通信フローを例示する。
【図４Ａ】[0016]  図４Ａは、様々な態様による、端末における許容可能なパケットロスに基づいた適切なハンドオーバしきい値を確立するために基地局に好適な情報を提供するために使用されることができる例示的な通信フローを例示する。
【図４Ｂ】図４Ｂは、様々な態様による、端末における許容可能なパケットロスに基づいた適切なハンドオーバしきい値を確立するために基地局に好適な情報を提供するために使用されることができる例示的な通信フローを例示する。
【図４Ｃ】図４Ｃは、様々な態様による、端末における許容可能なパケットロスに基づいた適切なハンドオーバしきい値を確立するために基地局に好適な情報を提供するために使用されることができる例示的な通信フローを例示する。
【図５】[0017]  図５は、様々な態様によれる、音声セッションに携わっている端末が、カバレッジエッジに到達する際によりロバストなマルチメディアコーデックまたはコーデックモードを使用することになることを保証するために使用されることができる例示的な通信フローを例示する。
【図６】[0018]  図６は、ここに説明される様々な態様および実施形態に従って使用され得る例示的なユーザ装置（ＵＥ）構成を例示する。
【図７】[0019]  図７は、ここに説明される様々な態様および実施形態に従って使用され得る例示的なアクセスポイントを例示する。
【図８】[0020]  図８は、ここに説明される様々な態様および実施形態に従って使用されるように構成されることができる様々な構造コンポーネントを有する例示的な通信デバイスを例示する。
【図９】[0021]  図９は、ここに説明される様々な態様および実施形態に従って構成され得る例示的なサーバを例示する。
【詳細な説明】
【００１４】
[0022]  様々な態様および実施形態が、例示的な態様および実施形態に関する特定の例を示すために、以下の説明および関連する図に開示される。代替の態様および実施形態は、本開示を読むと関連技術における当業者にとって明らかとなり、本開示の範囲または精神から逸脱することなく、解釈および実施され得る。さらに、周知の要素は詳細に説明されないか、またはここに開示される態様および実施形態の関連する詳細を不明瞭にすることを避けるために省略され得る。
【００１５】
[0023]  「例示的な（exemplary）」という用語は、ここで「例、事例、または例示としての役割を果たす」という意味で使用される。「例示的」としてここに説明されるいずれの実施形態も、必ずしも他の実施形態よりも有利であるまたは好ましいと解釈されるべきではない。同様に、「実施形態」という用語は、すべての実施形態が、説明された特徴、利点、または動作のモードを含むことを必要としない。
【００１６】
[0024]  ここで使用される用語は、単に特定の実施形態を説明するものであり、ここに開示されたいずれの実施形態も限定するように解釈されるべきではない。ここで使用される場合、単数形の「a」、「an」および「the」は、文脈上明確にそうでないことを示していない限り、複数形も含むように意図している。ここで使用されるとき、「備える（comprises）」、「備える（comprising）」、「含む（includes）」、および／または「含む（including）」という用語は、示される特徴、整数、ステップ、動作（operations）、要素、および／またはコンポーネントの存在を明示するが、１つまたは複数の他の特徴、整数、ステップ、動作、要素、コンポーネント、および／またはそれらのグループの存在または追加を除外しないことを、当業者はさらに理解するだろう。
【００１７】
[0025]  さらに、様々な態様および／または実施形態は、例えば、コンピューティングデバイスの要素によって実施されることになる一連のアクションの観点から説明され得る。当業者は、ここに説明される様々なアクションが、特定の回路（例えば、特定用途向け集積回路（ＡＳＩＣ））によって、１つまたは複数のプロセッサによってプログラム命令が実行されることによって、またはそれら両方の組合せによって、実施されることができることを認識するだろう。さらに、ここに説明されるこれらの一連のアクションは、実行されると、関連するプロセッサに、ここに説明される機能性を実施させることになるコンピュータ命令の対応するセットを記憶した、任意の形態の非一時的なコンピュータ読み取り可能な媒体内に、全体が具現化されると考えられることができる。したがって、ここに説明される様々な態様は、いくつかの異なる形態で具現化され得、それらのすべては、特許請求された主題事項の範囲内にあるものとして考慮されている。加えて、ここに説明される態様の各々に関して、任意のそのような態様の対応する形態は、例えば、説明されるアクションを実施する「ように構成される論理」および／または説明されるアクションを実施するように構成される他の構造コンポーネントとしてここに説明され得る。
【００１８】
[0026]  ここに説明される技法は、ＣＤＭＡ、ＴＤＭＡ、ＦＤＭＡ、ＯＦＤＭＡ、およびＳＣ−ＦＤＭＡシステムのような様々なワイヤレス通信システムに関連して使用され得る。「システム」および「ネットワーク」という用語は、交換可能に使用されることが多い。ＣＤＭＡシステムは、ユニバーサル地上波無線アクセス（ＵＴＲＡ）、ＣＤＭＡ２０００等のような無線技術をインプリメントし得る。ＵＴＲＡは、ワイドバンドＣＤＭＡ（ＷＣＤＭＡ（登録商標））およびＣＤＭＡの他の変形を含む。ＣＤＭＡ２０００は、ＩＳ−２０００、ＩＳ−９５、およびＩＳ−８５６規格をカバーする。ＴＤＭＡシステムは、移動体通信のためのグローバルシステム（ＧＳＭ）のような無線技術をインプリメントし得る。ＯＦＤＭＡシステムは、発展型ＵＴＲＡ（Ｅ−ＵＴＲＡ）、ウルトラモバイルブロードバンド（ＵＭＢ）、ＩＥＥＥ  ８０２．１１（Ｗｉ−Ｆｉ）、ＩＥＥＥ８０２．１６（ＷｉＭＡＸ）、ＩＥＥＥ８０２．２０、フラッシュＯＦＤＭＴＭ等のような無線技術をインプリメントし得る。ＵＴＲＡおよびＥ−ＵＴＲＡは、ユニバーサルモバイル電気通信システム（ＵＭＴＳ）の一部である。３ＧＰＰ（登録商標）ロングタームエボリューション（ＬＴＥ）は、Ｅ−ＵＴＲＡを使用するＵＭＴＳのリリースであり、それはダウンリンク上ではＯＦＤＭＡを用い、アップリンク上ではＳＣ−ＦＤＭＡを用いる。ＵＴＲＡ、Ｅ−ＵＴＲＡ、ＵＭＴＳ、ＬＴＥ、およびＧＳＭは、「第３世代パートナーシッププロジェクト」（３ＧＰＰ）からの文書に説明されている。ｃｄｍａ２０００およびＵＭＢは、「第３世代パートナーシッププロジェクト２」（３ＧＰＰ２）と名付けられた組織からの文書に説明されている。明瞭さのために、ある特定の態様は、ＬＴＥについて以下で説明され、ＬＴＥ用語が以下の説明の大部分で使用され得る。
【００１９】
[0027]  ここで使用される場合、「ユーザデバイス」、「ユーザ装置」（または「ＵＥ」）、「ユーザ端末」、「クライアントデバイス」、「通信デバイス」、「ワイヤレスデバイス」、「ワイヤレス通信デバイス」、「ハンドヘルドデバイス」、「モバイルデバイス」、「モバイル端末」、「モバイル局」、「ハンドセット」、「アクセス端末」、「加入者デバイス」、「加入者端末」、「加入者局」、「端末」という用語およびそれらの変形は、任意の好適なモバイルまたは固定デバイスを置換え可能に指し得る。したがって、上述の用語は、特定の無線アクセス技術（ＲＡＴ）をインプリメントする無線アクセスネットワーク（ＲＡＮ）上で、ワイヤードネットワーク上で、ワイヤレスローカルエリアネットワーク（ＷＬＡＮ）上で（例えば、ＩＥＥＥ  ８０２．１１等に基づいて）、および／または直接のデバイスツーデバイス（Ｄ２Ｄ）またはピアツーピア（Ｐ２Ｐ）接続を介して他のデバイスと通信する、およびそれに接続するための、回路構成、メモリ、およびプログラマブルプロセッサを有する、セルラ電話、スマートフォン、パーソナルまたはモバイルマルチメディアプレーヤ、携帯情報端末、ラップトップコンピュータ、パーソナルコンピュータ、タブレットコンピュータ、スマートブック、パームトップコンピュータ、ワイヤレス電子メール受信機、マルチメディアインターネット対応セルラ電話、ワイヤレスゲーミングコントローラ、および同様のデバイスのうちの任意のものまたはそれらのすべてを適切に指し得る。
【００２０】
[0028]  様々な態様によれば、１つまたは複数のＵＥがＲＡＮ、ワイヤードネットワーク、ＷＬＡＮ等に信号を送ることができる通信リンクは、アップリンクまたはリバースリンクチャネル（例えば、リバーストラフィックチャネル、リバース制御チャネル、アクセスチャネル等）と呼ばれ、一方で、ＲＡＮ、ワイヤードネットワーク、ＷＬＡＮ等がＵＥに信号を送ることができる通信リンクは、ダウンリンクまたはフォワードリンクチャネル（例えば、ページングチャネル、制御チャネル、ブロードキャストチャネル、フォワードトラフィックチャネル等）と呼ばれる。ここで使用される場合、トラフィックチャネル（ＴＣＨ）という用語は、アップリンク／リバースリンクチャネルまたはダウンリンク／フォワードリンクチャネルのいずれかを指すことができる。
【００２１】
[0029]  様々な態様によれば、図１は、音声ベースのマルチメディアサービスをサポートし得るワイヤレス通信システム１００の高レベルシステムアーキテクチャを例示する。様々な実施形態において、ワイヤレス通信システム１００は、ここにおいて集合的にＵＥ１０２−１．．Ｎと呼ばれる、ＵＥ１０２−１、ＵＥ１０２−２、ＵＥ１０２−３、ＵＥ１０２−４、ＵＥ１０２−５、１０２−６、ＵＥ１０２−Ｎを含む様々なＵＥを包含し得る。ＵＥ１０２−１．．Ｎは、セルラ電話、スマートフォン、パーソナルまたはモバイルマルチメディアプレーヤ、携帯情報端末、ラップトップコンピュータ、パーソナルコンピュータ、タブレットコンピュータ等を含むことができる。例えば、図１において、ＵＥ１０２−１．．６は、セルラタッチスクリーン電話またはスマートフォンとして例示され、ＵＥ１０２−Ｎは、デスクトップコンピュータとして例示される。
【００２２】
[0030]  図１に関して、ＵＥ１０２−１．．Ｎは、エアインタフェース１０４、１０６、１０８および／または直接のまたは間接のワイヤード接続１０９として図１に示される物理通信インタフェースまたはレイヤ上で、アクセスネットワーク（例えば、ＲＡＮ１２０、アクセスポイント１２５等）と通信し得る。エアインタフェース１０４および１０６は、所与のセルラ通信プロトコル（例えば、ＣＤＭＡ、ＥＶ−ＤＯ、ｅＨＲＰＤ、ＧＳＭ、ＥＤＧＥ、Ｗ−ＣＤＭＡ（登録商標）、ＬＴＥ等）に適合することができ、一方でエアインタフェース１０８は、ワイヤレスローカルエリアネットワーク（ＷＬＡＮ）プロトコル（例えば、ＩＥＥＥ  ８０２．１１）に適合することができる。図１には明示的に示されていないが、ＲＡＮ１２０は、エアインタフェース１０４および１０６のようなエアインタフェース上でＵＥにサービス提供することができる様々なアクセスポイントを含み得る。ＲＡＮ１２０における各アクセスポイントは、アクセスノードまたはＡＮ、アクセスポイントまたはＡＰ、基地局またはＢＳ、ノードＢ、発展型ノードＢ、ｅノードＢまたはｅＮＢ等と称されることができる。これらのアクセスポイントは、地上アクセスポイント（または地上局）または衛星アクセスポイントであることができる。ＲＡＮ１２０は、ＲＡＮ１２０を介してサービス提供されるＵＥと、ＲＡＮ１２０または全く異なるＲＡＮを介してサービス提供される他のＵＥとの間で呼（例えば、音声呼）をブリッジすることを含む様々な機能を実施することができる、コアネットワーク１４０に接続するように構成され得る。
【００２３】
[0031]  様々な実施形態において、ＲＡＮ１２０は、ＲＡＮ１２０を介してサービス提供されるＵＥと、ＲＡＮ１２０または全く異なるＲＡＮを介してサービス提供される他のＵＥとの間の回線交換（ＣＳ）コールをブリッジするように構成され得る。様々な実施形態において、ＲＡＮ１２０はまた、インターネット１７５のような外部のネットワークとのパケット交換（ＰＳ）データの交換を仲介するように構成され得る。インターネット１７５は一般に、様々なルーティングエージェントおよび処理エージェント（便宜上図１には明示的に示されない）を含み得る。図１では、ＵＥ１０２−Ｎは、ワイヤード接続１０９を介してインターネット１７５に接続している（すなわち、８０２．１１ベースのワイヤレスローカルエリアネットワークへのイーサネット（登録商標）接続を介するなどして、コアネットワーク１４０とは分離されている）ように示される。インターネット１７５は、それにより、コアネットワーク１４０を介して、ＵＥ１０２−ＮとＵＥ１０２−１〜１０２−６との間の（音声呼に関連するデータを含む）パケット交換データ通信をブリッジすることができる。ＲＡＮ１２０とは分離されたアクセスポイント１２５もまた図１に示されている。アクセスポイント１２５は、（例えば、光通信システム、ケーブルモデム等を介して）コアネットワーク１４０から独立してインターネット１７５に接続し得る。エアインタフェース１０８は、一例では、ＩＥＥＥ  ８０２．１１のようなローカルワイヤレス接続によってＵＥ１０２−５またはＵＥ１０２−６にサービス提供し得る。ＵＥ１０２−Ｎは、一例では、それ自体がアクセスポイント１２５に対応することができるルータまたはモデムへの直接接続のようなインターネット１７５へのワイヤード接続１０９を有するデスクトップコンピュータとして示される（例えば、ワイヤードおよび／またはワイヤレス接続性を有するＷＬＡＮルータは、アクセスポイント１２５に対応し得る）。
【００２４】
[0032]  図１に関して、サーバ１７０は、インターネット１７５、コアネットワーク１４０、またはその両方に接続されるように示される。サーバ１７０は、複数の構造的に分離したサーバとして、または代わりに単一のサーバとしてインプリメントされることができる。サーバ１７０は、（例えば、ボイスオーバインターネットプロトコル（ＶｏＩＰ）セッション、ボイスオーバＬＴＥ（ＶｏＬＴＥ）セッション、プッシュトーク（ＰＴＴ）セッション、グループ通信セッション、ソーシャルネットワーキングサービス、リッチ通信サービス（ＲＣＳ）、ビデオオーバＬＴＥ（ＶｉＬＴＥ）または他の好適なビデオコールサービスに関わるセッション等の）インターネット１７５および／またはコアネットワーク１４０を介してサーバ１７０に接続することができるＵＥのための１つまたは複数の通信サービスをサポートするように構成されるアプリケーションサーバ、アプリケーションダウンロードサーバ、または（例えばウェブページをホストする）ウェブサーバのような、任意の好適なタイプのサーバに対応し得る。
【００２５】
[0033]  図１に関して、ＵＥ１０２−１、１０２−２、および１０２−３は、ＵＥ１０２−１および１０２−３がエアインタフェース１０４を介してＲＡＮ１２０に接続された状態で、Ｄ２ＤネットワークまたはＤ２Ｄグループ１８５の一部として示される。一実施形態では、ＵＥ１０２−２はまた、ＵＥ１０２−１および／または１０２−３による仲介によってＲＡＮ１２０への間接的なアクセスを得る可能性があり、それによって、ＵＥ１０２−２ならびにＵＥ１０２−２の代わりにＲＡＮ１２０と通信し得るＵＥ１０２−１および１０２−３のうちの１つ（または複数）へ／から、データが「ホップ」する。
【００２６】
[0034]  様々な態様によれば、ＲＡＮ１２０およびコアネットワーク１４０のための１つの例示的なプロトコル固有のインプリメンテーションが、ワイヤレス通信システム１００をより詳細に説明することを助けるために図２に関して以下に提供される。さらに、以下の説明では、ＲＡＮ１２０およびコアネットワーク１４０のコンポーネントは、音声ベースのマルチメディアセッションで使用されることができるパケット交換（ＰＳ）通信をサポートすることに関する機能を参照して説明され得る。しかしながら、当業者は、図２には明示的に示されないかまたはそうでなければここで詳細に説明されてはいないが、レガシー回線交換（ＣＳ）コンポーネントが存在し得ることを認識することになるだろう。
【００２７】
[0035]  様々な態様によれば、図２は、第１のＵＥ２０２−１と第２のＵＥ２０２−２との間の音声ベースのセッションをサポートし得る例示的なワイヤレスネットワークアーキテクチャ２００を例示する。様々な実施形態において、ワイヤレスネットワークアーキテクチャ２００は、ロングタームエボリューション（ＬＴＥ）（または発展型パケットシステム（ＥＰＳ））ネットワークアーキテクチャ２００を備え得る。様々な実施形態において、ワイヤレスネットワークアーキテクチャ２００は、発展型ＵＭＴＳ地上波無線アクセスネットワーク（Ｅ−ＵＴＲＡＮ）２２０、発展型パケットコア（ＥＰＣ）２４０、ホーム加入者サーバ（ＨＳＳ）２５５、およびオペレータ（例えば、モバイルネットワークオペレータ（ＭＮＯ））に関連するオペレータインターネットプロトコル（ＩＰ）サービス２６０を含み得る。ＥＰＳネットワークアーキテクチャ２００は、他のアクセスネットワークおよびコアネットワーク（図示せず）、例えばＵＭＴＳアクセスネットワークまたはＩＰコアネットワークと相互接続することができる。示されているように、ＥＰＳネットワークアーキテクチャ２００は、パケット交換サービスを提供するが、しかしながら、当業者は、ここに開示された様々な概念は、回線交換サービスを提供するネットワークに拡張され得ることを容易に認識することとなる。
【００２８】
[0036]  様々な実施形態において、Ｅ−ＵＴＲＡＮ２２０は、ＵＥ２０２−１と通信している第１のｅノードＢ（ｅＮＢ）２２２−１と、ＵＥ２０２−２と通信している第２のｅＮＢ（ｅＮＢ）２２２−２とを含み得る。ｅＮＢ２２２−１、２２２−２は、ＵＥ２０２−１、２０２−２へのユーザプレーンおよび制御プレーンプロトコル終端を提供し得、バックホール（例えば、Ｘ２インタフェース）を介して互いに接続され得る。ｅＮＢ２２２−１、２２２−２はまた、基地局、ノードＢ、アクセスポイント、トランシーバ基地局、無線基地局、無線トランシーバ、トランシーバ機能、基本サービスセット（ＢＳＳ）、拡張サービスセット（ＥＳＳ）、または何らかの他の好適な用語でも呼ばれ得る。ｅＮＢ２２２−１、２２２−２は各々、それぞれのＵＥ２０２−１、２０２−２に、ＥＰＣ２４０へのアクセスポイントを提供する。
【００２９】
[0037]  ｅＮＢ２２２−１、２２２−２は各々、Ｓｉインタフェースを介してＥＰＣ２４０に接続し得、ここにおいて、ＥＰＣ２４０は、モビリティ管理エンティティ（ＭＭＥ）２４２、他のＭＭＥ２４４、サービングゲートウェイ２４６、マルチメディアブロードキャストマルチキャストサービス（ＭＢＭＳ）ゲートウェイ２５０、ブロードキャストマルチキャストサービスセンター（ＢＭ−ＳＣ）２５２、およびパケットデータネットワーク（ＰＤＮ）ゲートウェイ２４８を含み得る。ＭＭＥ２４２は、ＵＥ２０２−１、２０２−２とＥＰＣ２４０との間のシグナリングを処理する制御ノードである。一般に、ＭＭＥ２４２は、ベアラおよび接続管理を提供する。すべてのユーザＩＰパケットは、サービングゲートウェイ２４６を通して転送され、それはＰＤＮゲートウェイ２４８に接続され得る。ＰＤＮゲートウェイ２４８は、ＵＥＩＰアドレス割り振りならびに他の機能を提供する。ＰＤＮゲートウェイ２４８は、オペレータＩＰサービス２６０に接続され、それは、インターネット、イントラネット、ＩＰマルチメディアサブシステム（ＩＭＳ）および、ＰＳストリーミングサービス（ＰＳＳ）を含み得る。ＢＭ−ＳＣ２５２は、ＭＢＭＳユーザサービスプロビジョニングおよび配信のための機能を提供し得る。ＢＭ−ＳＣ２５２は、コンテンツプロバイダＭＢＭＳ送信のためのエントリポイントの役割を果たし得、ＰＬＭＮ内でのＭＢＭＳベアラサービスを許可するおよび始めるために使用され得、ＭＢＭＳ送信をスケジュールおよび配信するために使用され得る。ＭＢＭＳゲートウェイ２５０は、特定のサービスをブロードキャストするマルチキャストブロードキャスト単一周波数ネットワーク（ＭＢＳＦＮ）エリアに属するｅＮＢ（例えば、２２２−１、２２２−２）にＭＢＭＳトラフィックを分配するために使用され得、セッション管理（開始／停止）とｅＭＢＭＳ関連チャージ情報を収集することとを担い得る。
【００３０】
[0038]  様々な実施形態において、ＵＥペア（例えば、ＵＥ２０２−１およびＵＥ２０２−２）は、それぞれのｅＮＢ２２２−１、２２２−２を利用することなく直接的に通信するために、デバイスツーデバイス（Ｄ２Ｄ）接続２０４を確立し得る。ＵＥペア２０２−１、２０２−２は次いで、Ｄ２Ｄ接続２０４上でデータトラフィックを転送し得る。一般に、ネットワークインフラストラクチャ中の１つまたは複数のエンティティ（例えば、ｅＮＢ２２２−１、２２２−２、ＥＰＣ２４０中のエンティティ等）は、ネットワークエンティティがＤ２Ｄ接続２０４を確立するのを支援し得るという点でＵＥ２０２−１、２０２−２間のＤ２Ｄ通信を調整すること、Ｄ２Ｄモード対レガシーモードにおける使用を制御すること、セキュリティサポートを提供すること等を行い得る。様々な実施形態において、ＵＥペア２０２−１、２０２−２は、Ｄ２Ｄ接続２０４を自発的に確立するように構成され得、ここにおいて、最初の発見およびＤ２Ｄ接続２０４の確立は、それらの間で直接的に信号を通信する能力に基づき得る。
【００３１】
[0039]  マルチメディア（例えば、会話(speech)）サービスをサポートする端末またはＵＥが、ネットワークカバレッジのエッジ（例えば、ＬＴＥネットワークのようなワイヤレスワイドエリアネットワーク（ＷＷＡＮ）のエッジ）に到達するとき、ネットワークは典型的に、ハンドオーバしきい値を検査し、端末からの測定報告に基づいて、異なる無線アクセス技術に端末をハンドオフするべきかどうか決める。例えば、ＬＴＥネットワークは、最初は音声ベースのサービスではなくデータサービスをサポートするために展開されたが、ＬＴＥネットワークは次第にＶｏＬＴＥおよび他の音声ベースのサービスをサポートするように進化した。しかしながら、ある特定のネットワーク（例えば、ＬＴＥネットワーク）におけるアップリンクカバレッジは、制限される傾向があるかまたは少なくともダウンリンクカバレッジに比べてより制限される。したがって、生ずる１つの問題は、ネットワークエッジにおける端末からｅＮＢへのアップリンクカバレッジは、弱い（例えば、それはより高いパケットロスレート（ＰＬＲ）またはブロックエラーレート（ＢＬＥＲ）をもたらす）傾向があることである。したがって、ＬＴＥネットワークにおけるパケット交換音声呼を既存のネットワークと相互運用可能にするために、増加されたパケットロスに起因する音声サービスのさらなる劣化を回避するためにＶｏＬＴＥコールを回線交換ネットワークにハンドオーバするための単一無線音声呼連続性（ＳＲＶＣＣ）しきい値が定義される。他の状況（例えば、ＬＴＥネットワークからＷＬＡＮへのハンドオフ、５ＧＮＲネットワークからＬＴＥネットワークへのハンドオフ）では、パケットロスに起因する音声サービスの劣化を回避するためにハンドオーバしきい値が定義されるという点で原理は概して同じであるが、端末は、ハンドオーバしきい値を検査し、いつハンドオフすべきか決める。他の状況では、ハンドオーバはまた、１つの無線セルから同様の無線アクセス技術を有する隣接した無線セルへのものである可能性がある。
【００３２】
[0040]  一般に、ハンドオーバしきい値（例えば、ＳＲＶＣＣしきい値）はゆえに、ＵＥによっても（even from one UE to another）変化し得、それは、音声サービスに対するパケットロスの影響が、音声サービスが使用しているマルチメディアコーデックまたはコーデックモード、受信側ＵＥ（１つまたは複数）においてインプリメントされるパケットロスコンシールメント（ＰＬＣ）アルゴリズム、および受信側ＵＥ（１つまたは複数）において使用されるジッタ（またはデジッタ）バッファ管理（ＪＢＭ）インプリメンテーションを含む様々な要因によって決まり得るからである。例えば、使用されることができる１つのマルチメディアコーデックは、適応型マルチレート（ＡＭＲ）オーディオコーデックであり、それはリンクコンディションに基づいて、８つの異なるビットレートのうちの１つから選択するためのリンク適応を使用し、一般に回線交換ネットワークで使用される。適応型マルチレートワイドバンド（ＡＭＲ−ＷＢ）は、ＡＭＲ−ＷＢが、ＡＭＲオーディオコーデックと比較してより広い会話バンド幅に起因する改善された会話品質を提供する点を除いて、ＡＭＲコーデックと同様である。３ＧＰＰ  ＴＳ２６．４４１に説明されているような向上された音声サービス（ＥＶＳ）は、ＡＭＲおよびＡＭＲ−ＷＢに比べてより優れたロバスト性を提供し、また、ＥＶＳ非チャネルアウェアモードまたはＡＭＲ／ＡＭＲ−ＷＢと比較して改善された品質／了解度（intelligibility）をもたらす部分的な冗長性ベースのパケットロスコンシールメントメカニズムを含むチャネルアウェアモードを提供する。したがって、ここに説明される様々な態様および実施形態は一般に、ＡＭＲオーディオコーデックがＡＭＲ−ＷＢに比べてロバスト性がより低く、そして今度はＡＭＲ−ＷＢがＥＶＳコーデックに比べてロバスト性がより低く、一方でＥＶＳチャネルアウェアモードは、ＡＭＲ、ＡＭＲ−ＷＢ、およびＥＶＳと比較して最もロバストであり得る階層を考慮している。しかしながら、当業者は、他の可能性のあるオーディオコーデックがその階層に含まれ得ることを認識することになるだろうし、そしてそれは場合によってはＥＶＳチャネルアウェアモードに比べてより高いロバスト性を提供する将来開発されるオーディオコーデックもまた含む。したがって、ＥＶＳチャネルアウェアモードが最もロバストでありＡＭＲが最もロバストでない階層が、単に例示のためだけにここに説明されており、どのような点でも限定するようには意図していない。
【００３３】
[0041]  さらに、ＰＬＣアルゴリズム、例えばゼロ挿入、波形置換、モデルベースの方法等は、一般に、ＶｏＩＰ通信におけるパケットロスの影響を隠す（mask）。これは、音声信号が、異なる複数のルートを通して宛先に伝わり得、かつそれゆえに遅れて届いたり、破損して届いたり、順序が狂って届いたり、または全く届かなかったりするパケットで、ネットワーク上で送られるからである。関連して、パケットは復号器に順序が狂ってまたは到達時間にランダムなジッタを伴って到達し得るので、ＪＢＭインプリメンテーションは、会話パケットが、均等に間隔を空けられた周期的なインターバルで復号器に供給され得るように、パケット到達時間におけるジッタ（１つまたは複数）を吸収するための複数の異なる技法を使用し得る。その結果、各ＵＥが品質音声セッションを維持するために許容することができるパケットロスに影響を与え得る様々な要因が存在する。
【００３４】
[0042]  一般に（例えば、ＬＴＥネットワークにおけるｅＮＢにおけるものを例として）ＷＷＡＮまたは他のワイヤレスネットワークにおけるモバイルインフラストラクチャにおいて処理される、適切なハンドオーバしきい値を設定する際の複数の課題のうちの１つは、ゆえに、大いに劣化した品質および／または了解度をもたらすことなくコーデック、ＰＬＣ、およびＪＢＭが対処することができる最大パケットロスを、媒体の送信元（the media sender）から受信機へのトランスポート経路を渡るエンドツーエンド（ｅ２ｅ）エラーレートが、超えないことを保証することである。例えば、図３に関して、ＵＥ３０２−２からＵＥ３０２−１への方向における音声送信は、アップリンク３３２上でＵＥ３０２−２からローカルｅＮＢ３２２−２に送られ、それは次いでそれら送信をバックホールリンク３３４上でＵＥ３０２−１のためのローカルｅＮＢ３２２−１に送る。ローカルｅＮＢ３２２−１は次いで、ダウンリンク３３６上で、音声送信を受信側ＵＥ３０２−１に送る。同様に、反対方向では、ＵＥ３０２−１からＵＥ３０２−２への音声送信は、アップリンク３４２上でＵＥ３０２−１からローカルｅＮＢ３２２−１に送られ、それは次いでそれら送信をバックホールリンク３４４上でＵＥ３０２−２のためのローカルｅＮＢ３２２−２に送る。ローカルｅＮＢ３２２−２は次いで、ダウンリンク３４６上で受信側ＵＥ３０２−２に音声送信を送る。バックホールリンク３３４、３４４上にパケットロスが無いかまたはパケットロスがごくわずかしかないと仮定すれば、これは、ＵＥ３０２−２からＵＥ３０２−１への方向において送られる音声送信について、アップリンク３３２およびダウンリンク３３６上のパケットロスレート（ＰＬＲ）の合計が、ＵＥ３０２−１において使用されるＪＢＭインプリメンテーション（１つまたは複数）およびＰＬＣアルゴリズム（１つまたは複数）および音声セッションの間に使用されるコーデックについての最大ＰＬＲより低いか、またはそれに等しい必要があることを意味する。同様に、ＵＥ３０２−１からＵＥ３０２−２に音声を送信するもう一方の方向では、アップリンク３４２およびダウンリンク３４６上のパケットロスレート（ＰＬＲ）の合計は、ＵＥ３０２−２において使用されるＪＢＭインプリメンテーション（１つまたは複数）およびＰＬＣアルゴリズム（１つまたは複数）および音声セッションの間に使用されるコーデックについての最大ＰＬＲより低いか、またはそれに等しい必要がある。
【００３５】
[0043]  いくつか状況では、マルチメディアセッションは、パケットロスに対する異なるロバスト性を有する複数のコーデックまたはコーデックモードの使用を交渉する。そのような状況では、ＵＥ３０２−１、３０２−２は、交渉されたコーデックまたはコーデックモードのうちの任意のものを任意の時間に使用することができ、インフラストラクチャ（例えば、ｅＮＢ３２２−１、３２２−２）は、いずれのコーデックが使用されているか明確に知らない。したがって、図４Ａ〜図４Ｃは、端末（例えば、ＵＥ３０２−１、３０２−２）における許容可能なパケットロスに基づいた適切なハンドオーバしきい値を確立するための好適な情報を基地局（例えば、ｅＮＢ３２２−１、３２２−２）に提供するために使用されることができる、例示的な通信フローを例示する。さらに、ＰＬＣアルゴリズム（１つまたは複数）およびＪＢＭインプリメンテーション（１つまたは複数）は、端末によって変化し得るので、適切なハンドオーバしきい値は、ＵＥ固有であり得る、なぜなら同じマルチメディアコーデックを使用している２つのＵＥは、それぞれのＵＥにおいて使用されるＰＬＣアルゴリズム（１つまたは複数）および／またはＪＢＭインプリメンテーション（１つまたは複数）の差に起因して異なるＰＬＲを許容することが可能であり得るからである。しかしながら、ＰＬＣアルゴリズム（１つまたは複数）およびＪＢＭインプリメンテーション（１つまたは複数）およびパフォーマンスは従来、媒体を受信する端末で知られているだけなので、ＰＬＣアルゴリズム（１つまたは複数）およびＪＢＭインプリメンテーション（１つまたは複数）はネットワークにシグナリングされる必要がある。さらに、送信側の端末から受信側の端末へのエンドツーエンド経路には典型的に２つの無線リンクが存在する（例えば、ＵＥ３０２−２からＵＥ３０２−１に送るときのエンドツーエンド経路におけるアップリンク３３２およびダウンリンク３３６）ので、情報は、適切なＰＬＲターゲットを如何に設定するかを決定するために、トランスポート経路における２つのｅＮＢ３２２−１、３２２−２と共有される必要がある。
【００３６】
[0044]  したがって、図４Ａは、使用されているコーデックならびに使用されているＰＬＣおよびＪＢＭインプリメンテーションに基づいて、ＵＥ３０２−１、３０２−２間のトランスポート経路における２つのｅＮＢ３２２−１、３２２−２に対してＰＬＲ要件をシグナリングする１つの可能性のある解決策を例示する。より具体的には、４３２において、ＵＥ３０２−１、３０２−２は、コーデック交渉を実施し得、その間にＵＥ３０２−１、３０２−２は、それらのＰＬＣおよびＪＢＭ能力についての情報を交換する。例えば、ＰＬＣ能力は、１つまたは複数のＰＬＣアルゴリズム、例えば、ゼロ挿入、波形置換、モデルベースの方法を含み得、一方でＪＢＭ能力は、（例えば、時間、ロケーションに渡って経験される、有効パケットロス、ジッタ誘導パケット／遅延損失統計値、等の）パケット交換ネットワークにおけるジッタに対抗するために使用されるターゲットアンダーフローレートまたは他の好適なＪＢＭインプリメンテーションを指し得る。ＰＬＣおよびＪＢＭ能力は、それぞれのＵＥ３０２−１、３０２−２が所与のコーデック／モードおよび現在のＰＬＣおよびＪＢＭインプリメンテーションについて許容することができる合計許容可能パケットロスレート（ＰＬＲ）の形態をとり得る。例えば、コーデックモードは、コーデックの任意の動作ポイントであることができ、それは異なるビットレート（例えば、ＴＳ２６．４４１におけるＥＶＳまたはＡＭＲ−ＷＢコーデックレートのような）、オーディオバンド幅（例えば、ナローバンド、ワイドバンド、超ワイドバンド）、会話／オーディオコーディングタイプ、チャネルアウェアまたは非チャネルアウェアモード、拡張されたＰＬＣ後処理技法等を含み得る。
【００３７】
[0045]  要求される最大エンドツーエンド（ｅ２ｅ）ＰＬＲのこの交換に基づいて、それぞれのＵＥ３０２−１、３０２−２は、それぞれのローカルｅＮＢ３２２−１、３２２−２にどのような最大ＰＬＲを要求するかを決定することができる。様々な実施形態において、ＵＥ３０２−１、３０２−２は、合意済み比に従って、アップリンクおよびダウンリンクにわたって最大エンドツーエンド（ｅ２ｅ）ＰＬＲを分割するために、指定される、事前構成される、または動的に構成される（例えば、オープンモバイルアライアンスデバイス管理（ＯＭＡ−ＤＭ）を介して）ことができる。例えば、最大ｅ２ｅＰＬＲは、１：１の比に従って分割される可能性があり、それによってＵＥ３０２−１、３０２−２は、ｅＮＢ３２２−１、３２２−２の各々が最大ｅ２ｅＰＬＲの半分であるＰＬＲをサポートするためのリンクを提供することを要求し得る。代替的に、ＵＥ３０２−１、３０２−２は、異なる比に従って最大許容可能エンドツーエンドＰＬＲを如何に分配するかを交渉することができる。例えば、ＬＴＥネットワークは典型的により限定されたアップリンクカバレッジを有するので、ＵＥ３０２−１、３０２−２は、ダウンリンクに比べてアップリンクにおいてより多くのエラーを許す比を交渉し得る。したがって、再度図３を参照すると、アップリンクＰＬＲ対ダウンリンクＰＬＲの比を表すために変数Ｒが使用される場合には、ＵＥ３０２−１は、ＵＥ３０２−１からｅＮＢ３２２−１へのアップリンク３４２上で、ＵＥ３０２−２が許容することができる最大ｅ２ｅ  ＰＬＲ掛けるＲ／（Ｒ＋１）に等しいＰＬＲをｅＮＢ３２２−１がサポートすることを要求し得、およびＵＥ３０２−１はさらに、ＵＥ３０２−１が許容することができる最大ｅ２ｅ  ＰＬＲ掛ける１／（Ｒ＋１）に等しいＰＬＲをｅＮＢ３２２−１がダウンリンク３３６上でサポートすることを要求し得る。同様の点で、ＵＥ３０２−２は、ＵＥ３０２−１が許容することができる最大ｅ２ｅ  ＰＬＲ掛けるＲ／（Ｒ＋１）に等しいＰＬＲをｅＮＢ３２２−２がＵＥ３０２−２からｅＮＢ３２２−２へのアップリンク３３２上でサポートすることを要求し得、さらに、ＵＥ３０２−２が許容することができる最大ｅ２ｅ  ＰＬＲ掛ける１／（Ｒ＋１）に等しいＰＬＲをｅＮＢ３２２−２がダウンリンク３４６上でサポートすることを要求し得る。
【００３８】
[0046]  様々な態様によれば、さらなる代替において、以下にさらに詳細に説明されることになるように、ＵＥ３０２−１、３０２−２は、分配最大許容可能エンドツーエンドＰＬＲをどのように分配するかを明示的に交渉するために、（例えば、セッション記述プロトコル（ＳＤＰ）を介した）交渉に携わり得る。例えば、ＵＥ３０２−１がＵＥ３０２−２において使用されるＰＬＣおよび／またはＪＢＭインプリメンテーションと比較してより多くの許容可能なパケットロスを許すＰＬＣおよび／またはＪＢＭインプリメンテーションを用いると仮定すれば、ＵＥ３０２−１は、ＵＥ３０２−２がｅＮＢ３２２−２に対して要求するリンクと比較してより高いＰＬＲをサポートするためのリンクをｅＮＢ３２２−１が提供することを要求する可能性がある。例えば、４３２において、ＵＥ３０２−１は、ＵＥ３０２−１がコーデックモードおよび現在のＰＬＣ／ＪＭＢインプリメンテーションについて受信することができる最大エンドツーエンドＰＬＲ（例えば、６パーセント）を有するセッション記述プロトコル（ＳＤＰ）メッセージを送り得る。他のＵＥ３０２−２は、ＳＤＰメッセージにおいてパラメータを受信し、ｅＮＢ３２２−２へのアップリンクのためにこのエンドツーエンドＰＬＲの一部（例えば、４パーセント）を使用すると決める。ＵＥ３０２−２は次いで、ＵＥ３０２−２が４％を使用することになることを示すためにＵＥ３０２−１に応答する、またはＵＥ３０２−１に、ＵＥ３０２−１がローカルｅＮＢ３２２−１に対して残りの２％の許容可能ＰＬＲを要求する必要があることを教える。ＵＥ３０２−２はまた、ＵＥ３０２−２がｅＮＢ３２２−２へのアップリンク上で４％のＰＬＲのみを要求することを示すためにローカルｅＮＢ３２２−２にシグナリングする。いずれの場合も、４３４に示されるように、ＵＥ３０２−２は、それのそれぞれのアップリンクおよびダウンリンクＰＬＲ要件をローカルｅＮＢ３２２−２にシグナリングし、一方でＵＥ３０２−１は同様に、アップリンクおよびダウンリンクＰＬＲ要件を４３６においてそれのローカルｅＮＢ３２２−１にシグナリングする。
【００３９】
[0047]  様々な態様によれば、図４Ｂは、それぞれのＵＥ３０２−１、３０２−２において使用されているＰＬＣおよびＪＢＭインプリメンテーションならびに使用されているコーデックに基づいて、ＵＥ３０２−１、３０２−２間のトランスポート経路における２つのローカルｅＮＢ３２２−１、３２２−２にＰＬＲ要件をシグナリングするための別の可能性のある解決策を例示する。図４Ｂに示される通信フローでは、４３２において、ＵＥ３０２−１、３０２−２は、図４Ａに関して上述したのと同様の方法で、コーデック交渉に携わり得る。しかしながら、図４Ｂにおける通信フローは、１つの端末（すなわち、例示された例ではＵＥ３０２−２）がローカルｅＮＢ３２２−２に対してどのようなＰＬＲを要求するかに関する最初の決定を行い、その結果として４３４において最初の決定をシグナリングするという意味で異なる。そして、４３５において、ＵＥ３０２−２は、ＵＥ３０２−２がｅＮＢ３２２−１に対して要求されることを求めるＰＬＲを示すためのメッセージをＵＥ３０２−１に送り、ＵＥ３０２−１は次いで、４３６において示されるように、示されたＰＬＲをｅＮＢ３２２−１に要求する。
【００４０】
[0048]  様々な態様によれば、図４Ｃは、それぞれのＵＥ３０２−１、３０２−２において使用されているＰＬＣおよびＪＢＭインプリメンテーションならびに使用されているコーデックに基づいて、ＵＥ３０２−１、３０２−２間のトランスポート経路における２つのｅＮＢ３２２−１、３２２−２にＰＬＲ要件をシグナリングするためのさらに別の可能性のある解決策を例示する。より具体的には、４３２において、ＵＥ３０２−１、３０２−２は、コーデック交渉を実施し得、その間にＵＥ３０２−１、３０２−２は、それらのＰＬＣおよびＪＢＭ能力についての情報を交換する。例えば、ＰＬＣ能力は、１つまたは複数のＰＬＣアルゴリズム、例えば、ゼロ挿入、波形置換、モデルベースの方法を含み得、一方でＪＢＭ能力は、（例えば、時間、ロケーションに渡って経験される、有効パケットロス、ジッタ誘導パケット／遅延損失統計値、等の）パケット交換ネットワークにおけるジッタに対抗するために使用されるターゲットアンダーフローレートまたは他の好適なＪＢＭインプリメンテーションを指し得る。ＰＬＣおよびＪＢＭ能力は、それぞれのＵＥ３０２−１、３０２−２が所与のコーデック／モードおよび現在のＰＬＣおよびＪＢＭインプリメンテーションについて許容することができる合計許容可能パケットロスレート（ＰＬＲ）の形態をとり得る。
【００４１】
[0049]  要求される最大エンドツーエンドＰＬＲのこの交換に基づいて、１つまたは複数のネットワーク要素は、それぞれのローカルｅＮＢ３２２−１、３２２−２にどのような最大ＰＬＲを要求するかを決定することができる。例えば、図４Ｃに示されるように、ネットワーク要素（１つまたは複数）は、ＵＥ３０２−１についてのアップリンクおよびダウンリンクＰＬＲをシグナリングするためのメッセージ４４２をｅＮＢ３２２−１に送るＣＳＣＦ（Call Session Control Function）またはＰＣＲＦ（Policy and Charging Rules Function）４１２−１、ならびにＵＥ３０２−２についてのアップリンクおよびダウンリンクＰＬＲをシグナリングするためのメッセージ４４４をｅＮＢ３２２−２に送るＣＳＣＦ／ＰＣＲＦ４１２−２を備え得る。様々な実施形態において、ＣＳＣＦ／ＰＣＲＦ４１２−１、４１２−２は、ｅＮＢ３２２−１、３２２−２の各々が特定の比に基づいたＰＬＲをサポートするためのリンクを提供することを要求することを決めることができる。例えば、比は、最大エンドツーエンドＰＬＲの半分がアップリンクに割り振られ、もう半分がダウンリンクに割り振られるように１：１の比であり得るか、または、ＬＴＥネットワークはより限定されたアップリンクカバレッジを有する傾向があるので、アップリンクについてより多くのエラーを最大許容可能エンドツーエンドＰＬＲが許す比を、ＣＳＣＦ／ＰＣＲＦ４１２−１、４１２−２は決めることができる。比が使用されるそのような状況では、変数Ｒは、アップリンクＰＬＲ対ダウンリンクＰＬＲの比を表し得る。そのようなものとして、ＣＳＣＦ／ＰＣＲＦ４１２−１は、ｅＮＢ３２２−１がＵＥ３０２−１からのアップリンク上でＵＥ３０２−２が許容することができる最大ｅ２ｅ  ＰＬＲ掛けるＲ／（Ｒ＋１）に等しいＰＬＲをサポートすることを要求し得、さらに、ｅＮＢ３２２−１がＵＥ３０２−１へのダウンリンク上で、ＵＥ３０２−１が許容することができる最大ｅ２ｅ  ＰＬＲ掛ける１／（Ｒ＋１）に等しいＰＬＲをサポートすることを要求し得る。同様の点で、ＣＳＣＦ／ＰＣＲＦ４１２−２は、ｅＮＢ３２２−２がＵＥ３０２−２からのアップリンク上でＵＥ３０２−１が許容することができる最大ｅ２ｅ  ＰＬＲ掛けるＲ／（Ｒ＋１）に等しいＰＬＲをサポートすることを要求し得、さらに、ｅＮＢ３２２−２がＵＥ３０２−２へのダウンリンク上で、ＵＥ３０２−２が許容することができる最大ｅ２ｅ  ＰＬＲ掛ける１／（Ｒ＋１）に等しいＰＬＲをサポートすることを要求し得る。
【００４２】
[0050]  様々な実施形態において、別のアプローチは、ＵＥ３０２−１、３０２−２間のセッション記述プロトコル（ＳＤＰ）交渉に基づき得る。例えば、ＵＥ３０２−１は、ＵＥ３０２−１がコーデックモードおよび現在のＰＬＣ／ＪＭＢインプリメンテーションについて受信することができる最大エンドツーエンドＰＬＲ（例えば、６パーセント）を有するセッション記述プロトコル（ＳＤＰ）メッセージを送り得る。ＣＳＣＦ／ＰＣＲＦ４１２−１は、ＳＤＰメッセージ中のパラメータを見る可能性があり、ＵＥ３０２−１へのダウンリンク上で、最大エンドツーエンドＰＬＲのある比率（例えば、アドバタイズされた６％中の２％）を割り振ることを決める。４４２において、ＣＳＣＦ／ＰＣＲＦ４１２−１はゆえに、ローカルｅＮＢ３２２−１に、ＵＥ３０２−１へのダウンリンク上で２％のＰＬＲをサポートするように教える。ＣＳＣＦ／ＰＣＲＦ４１２−１はまた、４％のＰＬＲが要求されていることを示すようにＳＤＰオファーにおけるパラメータを修正し、この修正されたＳＤＰオファーをＣＳＣＦ／ＰＣＲＦ４１２−２に送る。ＣＳＣＦ／ＰＣＲＦ４１２−２は次いで、ｅＮＢ３２２−２におけるアップリンクＰＬＲを設定するためにＳＤＰオファーにおける修正されたＰＬＲ値を使用する（例えば、それはＵＥ３０２−２からのアップリンクについて４％のＰＬＲを使用するようにｅＮＢ３２２−２に命令する）。さらに、反対の方向でも同様のプロシージャが生じ得る。特に、ＵＥ３０２−２は、ＳＤＰアンサーにおいて、ＵＥ３０２−２が受信することができる最大ＰＬＲを送り返し、ローカルＣＳＣＦ／ＰＣＲＦ４１２−２は、ＰＬＲバジェットの一部を取る。ローカルＣＳＣＦ／ＰＣＲＦ４１２−２はまた、ＵＥ３０２−２へのダウンリンクについてこれを設定するようにローカルｅＮＢ３２２−２に命令し、ＣＳＣＦ／ＰＣＲＦ４１２−１へとＳＤＰアンサーをリレイする前にＳＤＰアンサーにおける最大ＰＬＲ値を修正し、それは今度は、ＵＥ３０２−１からのアップリンクについて修正された最大ＰＬＲ値を使用するようにローカルｅＮＢ３２２−１に命令する。
【００４３】
[0051]  様々な態様によれば、上述したように、図４Ａ〜図４Ｃの各々は、ＵＥ３０２−１、３０２−２がコーデックおよび／またはコーデックモードをその間に交渉し、さらに、ＰＬＣおよびＪＢＭ情報を交換するシグナリング交換４３２を例示する。したがって、そして図３をさらに参照して、ＵＥ３０２−１、３０２−２は、少なくとも、ＵＥ３０２−１からＵＥ３０２−２の方向における、ＵＥ３０２−１からｅＮＢ３２２−１へのアップリンク３４２およびｅＮＢ３２２−２からＵＥ３０２−２へのダウンリンク３４６、ならびに、ＵＥ３０２−２からＵＥ３０２−１への方向における、ＵＥ３０２−２からｅＮＢ３２２−２へのアップリンク３３２およびｅＮＢ３２２−１からＵＥ３０２−１へのダウンリンク３３６を含む、各リンクについてのエラーレートおよび最大エンドツーエンドエラーレートを交渉するためにシグナリング交換４３２を使用し得る。様々な実施形態において、各リンクについての最大エンドツーエンドエラーレートおよびエラーレートは、パケットロスレート（ＰＬＲ）値および／またはブロックエラーレート（ＢＬＥＲ）値を備え得、それらは一般に割合として表される。したがって、ここに説明される様々な態様は、ＰＬＲ値またはＢＬＥＲ値を指し得るが、当業者は、ここに説明される様々な態様および実施形態は、ＰＬＲ値および／またはＢＬＥＲ値を使用して適切に実施され得ることを認識することになるだろう。いずれにしろ、図３および図４Ａ〜図４Ｃにおけるシグナリング交換４３２を参照して、以下の説明は、２つのエンドポイントＵＥ３０２−１、３０２−２がリンク３３２、３３６、３４２、３４６の各々についてのエラーレートおよび最大エンドツーエンドエラーレートを交渉するために使用され得る例示的なメカニズムを記載する。以下の説明では、最大エンドツーエンドエラーレートおよびリンク固有エラーレートは、簡潔性のためにＰＬＲ割合値として説明される。しかしながら、上述したように、交渉メカニズムが、ＢＬＥＲ割合値に基づいたエラーレートを使用して代わりにインプリメントされ得る。
【００４４】
[0052]  様々な態様によれば、ここに説明されるように、リンク３３２、３３６、３４２、３４６の各々についての最大エンドツーエンドＰＬＲおよびＰＬＲは、デバイスレベルで（例えば、製造時に）事前構成され得る、および／またはオープンモバイルアライアンスデバイス管理（ＯＭＡ−ＤＭ）を介してデバイスレベルで構成され得る。例えば、上述したように、ＰＬＲ値は、一般に、サポートされるコーデック、サポートされるコーデックモード、ＰＬＣアルゴリズム、ＪＢＭインプリメンテーション等に関するデバイス固有および／またはオペレータ固有のパラメータに依存し得る。さらに、様々な実施形態において、最大エンドツーエンドおよびリンク固有ＰＬＲ値は、ネットワークコンディションに依存することができる。例えば、ネットワークは、任意の所与の時点において負荷が軽いまたは重い可能性があり得、それは所与のＰＬＲ値をサポートするためのネットワークの能力に影響し得る。他の例では、ネットワークは、セルのエッジに到達するまで、（例えば、低いアップリンク／ダウンリンクＰＬＲ等の）良好なカバレッジが提供されることができる１つまたは複数のエリアを含み得るか、または最大ＰＬＲ値は、オペレータポリシーに依存し得る（例えば、ネットワークは、ビジーである時刻の間にはより信頼性の低いベアラを提供し得る）等である。様々な実施形態において、サポートされるＰＬＲについてのこの非静的な情報は、ＣＳＣＦ／ＰＣＲＦ４１２−１、４１２−２に通信されることができ、それは次いで、リンク固有ＰＬＲ制限（１つまたは複数）を反映するために、ＵＥ３０２−１、３０２−２間のセッション記述プロトコル（ＳＤＰ）オファー／アンサー交換で使用される１つまたは複数のパラメータを修正し得る。１つの代替的なインプリメンテーションでは、ネットワークＰＬＲコンディションは、ＵＥ３０２−１、３０２−２がＳＤＰオファー／アンサー交渉を始めることに先立ってＵＥ３０２−１、３０２−２に送られ得る（すなわち、ネットワークＰＬＲコンディションはセルにわたってブロードキャストされる）。図４Ｃに示されるもののような様々な実施形態において、ＣＳＣＦ／ＰＣＲＦ４１２−１、４１２−２のような１つまたは複数のネットワークノードは、エンドポイントＵＥ３０２−１、３０２−２間のＳＤＰオファー／アンサー交渉の結果を見る可能性があり、そしてメッセージ４４２、４４４を介してそれぞれのｅＮＢ３２２−１、３２２−２に適切な要求をし得る。
【００４５】
[0053]  様々な態様によれば、ＳＤＰオファー／アンサー交渉の間、エンドポイントＵＥ３０２−１、３０２−２のうちの一方はオファー側デバイスであり得、他方はアンサー側デバイスであり得る。ここでさらに詳細に説明されることになるように、（ｉ）受信するためにオファー側デバイスがセットアップされる最大エンドツーエンド（ｅ２ｅ）ＰＬＲ（ｍａｘ＿ｅ２ｅ＿ＰＬＲ＿Ｏｆｆ）、（ｉｉ）オファー側デバイスからアンサー側デバイスへの方向における提案されるアップリンクＰＬＲ（ＵＬ＿ＰＬＲ＿Ｏｆｆ）、および（ｉｉｉ）アンサー側デバイスからオファー側デバイスへの方向における提案されるダウンリンクＰＬＲ（ＤＬ＿ＰＬＲ＿Ｏｆｆ）を指定するオファー側デバイスのためのトライアド（triad）を含む、ある特定のＳＤＰ属性が、ＳＤＰオファー／アンサー交渉において使用され得る。加えて、ＳＤＰオファー／アンサー交渉で使用されるＳＤＰ属性は、アンサー側デバイスについても事実上同様のトライアドを含み得、ここにおいて、アンサー側トライアドは、（ｉ）受信するためにアンサー側デバイスがセットアップされる最大エンドツーエンド（ｅ２ｅ）ＰＬＲ（ｍａｘ＿ｅ２ｅ＿ＰＬＲ＿Ａｎｓ）、（ｉｉ）アンサー側デバイスからオファー側デバイスへの方向にける提案されるアップリンクＰＬＲ（ＵＬ＿ＰＬＲ＿Ａｎｓ）、および（ｉｉｉ）オファー側デバイスからアンサー側デバイスへの方向における提案されるダウンリンクＰＬＲ（ＤＬ＿ＰＬＲ＿Ａｎｓ）を指定する。上述したように、すべてのＰＬＲ値は割合として表され得る。さらに、所与の方向におけるアップリンクＰＬＲプラスダウンリンクＰＬＲは、一般に合計エンドツーエンドＰＬＲになるので、上で述べたオファー側トライアドおよびアンサー側トライアドは、以下の制約を受ける。
ＵＬ＿ＰＬＲ＿Ｏｆｆ＋ＤＬ＿ＰＬＲ＿Ａｎｓ＜＝ｍａｘ＿ｅ２ｅ＿ＰＬＲ＿Ａｎｓ、および、
ＵＬ＿ＰＬＲ＿Ａｎｓ＋ＤＬ＿ＰＬＲ＿Ｏｆｆ＜＝ｍａｘ＿ｅ２ｅ＿ＰＬＲ＿Ｏｆｆ
[0054]  様々な態様によれば、上述したＳＤＰ属性に基づいて、ＳＤＰオファー／アンサー交渉は、以下の様に進み得る。最初に、オファー側デバイスが、ｍａｘ＿ｅ２ｅ＿ＰＬＲ＿Ｏｆｆ、ＵＬ＿ＰＬＲ＿Ｏｆｆ、およびＤＬ＿ＰＬＲ＿Ｏｆｆを含む、オファー側トライアドのセットを示すＳＤＰオファーをアンサー側デバイスに送り得る。アンサー側デバイスは次いで、ＳＤＰオファーを受信すると、提案されたＵＬ＿ＰＬＲ＿ＯｆｆおよびＤＬ＿ＰＬＲ＿Ｏｆｆ値を受け入れるかまたは修正し得る。例えば、提案されたＵＬ＿ＰＬＲ＿Ｏｆｆがｍａｘ＿ｅ２ｅ＿ＰＬＲ＿ＡｎｓとＤＬ＿ＰＬＲ＿Ａｎｓとの間の差を超える場合、提案されたＵＬ＿ＰＬＲ＿Ｏｆｆは、アンサー側デバイスが対処することができるものを上回る可能性がある。そのようなケースでは、アンサー側デバイスは、アンサー側デバイスがＤＬ＿ＰＬＲ＿Ａｎｓのために予約することが必要であり得るそれの任意の部分を考慮して、アンサー側デバイスが対処することができるエンドツーエンドＰＬＲ制限内に収まるように、提案されたＵＬ＿ＰＬＲ＿Ｏｆｆ値を低減し得る。アンサー側デバイスがＳＤＰオファーを受信するとき、アンサー側デバイスは、オファー側トライアドにおける情報およびアンサー側デバイスにおけるＰＬＲ構成、具体的にはｍａｘ＿ｅ２ｅ＿ＰＬＲ＿Ａｎｓ、ＵＬ＿ＰＬＲ＿Ａｎｓ、およびＤＬ＿ＰＬＲ＿Ａｎｓについての値に基づいて、オファーを受け入れるかまたは修正するために必要とされるすべての情報を有し得る。アンサー側デバイスがオファー側トライアドに定められたＰＬＲパラメータを修正することを決める場合には、オファー側デバイスは、修正されたオファーにおける修正されたＰＬＲパラメータを受け入れ得るか、または修正されたオファーを拒否し得る。様々な実施形態において、アンサー側デバイスはゆえに、それのトライアドセットで応答し得る。ある特定の場合には、所与の方向におけるアップリンクＰＬＲおよびダウンリンクＰＬＲは、その方向における合計エンドツーエンドＰＬＲになるので、アンサー側デバイスが提供する必要があるのはｍａｘ＿ｅ２ｅ＿ＰＬＲ＿Ａｎｓ値のみであり得る、なぜなら他の値は、オファー側トライアドにおける値から導出されることができるからである。しかしながら、以下で説明するように、ＳＤＰアンサーにおいて提供されるパラメータを低減することは、（例えば、より高品質の音声呼を維持するために）全ＰＬＲバジェットを使い果たさない状況を可能にしない可能性がある、および／またはアップリンクＰＬＲおよびダウンリンクＰＬＲが等しく分割される状況への適応可能性を制限し得る。
【００４６】
[0055]  １つのインプリメンテーションでは、上述したようなＳＤＰオファー／アンサー交渉は、オファー側デバイスからのＳＤＰオファーに含まれるオファー側トライアドとの合意を示すＰＬＲ構成をアンサー側デバイスが有し、さらに全エンドツーエンドＰＬＲバジェットが利用される状況に適用され得る。例えば、ＳＤＰオファーは、ｍａｘ＿ｅ２ｅ＿ＰＬＲ＿Ｏｆｆが５（５）に等しく、ＵＬ＿ＰＬＲ＿Ｏｆｆが７（７）に等しく、ＤＬ＿ＰＬＲ＿Ｏｆｆが１（１）に等しい、オファー側トライアドを含み得る。アンサー側デバイスが、サポートされるコーデック／コーデックモード、ＰＬＣアルゴリズム、および／またはＪＢＭインプリメンテーションに基づいて、これらのＰＬＲ要件をサポートすることができると仮定すると、アンサー側デバイスは、オファー側トライアドを修正することなく、アンサー側トライアドをＳＤＰアンサーに入れ得る。したがって、この例では全エンドツーエンドＰＬＲバジェットが利用されるので、ＳＤＰアンサーは、ｍａｘ＿ｅ２ｅ＿ＰＬＲ＿Ａｎｓが９（９）に等しく、ＵＬ＿ＰＬＲ＿Ａｎｓが４（４）に等しく、およびＤＬ＿ＰＬＲ＿Ａｎｓが２（２）に等しい、アンサー側トライアドを含み得る。したがって、アンサー側デバイスからオファー側デバイスへの方向において、ｍａｘ＿ｅ２ｅ＿ＰＬＲ＿Ｏｆｆについての最大５％のエンドツーエンドバジェットは、オファー側デバイスへのダウンリンクについての１％のＰＬＲ、およびアンサー側デバイスからのアップリンクについての４％のＰＬＲに分割される。同様に、オファー側デバイスからアンサー側デバイスへの方向において、ｍａｘ＿ｅ２ｅ＿ＰＬＲ＿Ａｎｓのための最大９％のエンドツーエンドバジェットは、アンサー側デバイスへのダウンリンクのための２％のＰＬＲ、およびオファー側デバイスからのアップリンクについての７％のＰＬＲへと分割される。
【００４７】
[0056]  別の例示的なインプリメンテーションでは、上述したようなＳＤＰオファー／アンサー交渉は、この状況が、全エンドツーエンドＰＬＲバジェットが利用されない点で前の状況とは異なり得ることを除いて、アンサー側デバイスが、オファー側デバイスからのＳＤＰオファーに含まれるオファー側トライアドに合意するＰＬＲ構成を有する状況に適用され得る。当業者に明らかになるように、音声品質は、ＰＬＲ／ＢＬＥＲが増加するにつれて一般に劣化し得、それによってより全エンドツーエンドＰＬＲバジェットに満たないエンドツーエンドＰＬＲバジェットを利用することは、より良い品質の音声セッションをリーダし得る。例えば、ＳＤＰオファーは、ｍａｘ＿ｅ２ｅ＿ＰＬＲ＿Ｏｆｆについての値が１０（１０）であり、ＵＬ＿ＰＬＲ＿Ｏｆｆについての値が５（５）であり、ＤＬ＿ＰＬＲ＿Ｏｆｆについての値が１（１）であるオファー側トライアドを含み得る。サポートされるコーデック／コーデックモード、ＰＬＣアルゴリズム、および／またはＪＢＭインプリメンテーションに基づいて、アンサー側デバイスがこれらのＰＬＲ要件をサポートすることができると仮定すると、アンサー側デバイスは、オファー側トライアドを修正することなく、アンサー側トライアドをＳＤＰアンサーへと入れ得る。しかしながら、この例では全エンドツーエンドＰＬＲバジェットは利用されないので、ＳＤＰアンサーは、全ｍａｘ＿ｅ２ｅ＿ＰＬＲ＿Ｏｆｆおよび／またはｍａｘ＿ｅ２ｅ＿ＰＬＲ＿Ａｎｓエンドツーエンドバジェットを利用しないように値が構成されるアンサー側トライアドを含み得る。例えば、この目的を達成し得る１つの可能性のあるアンサー側トライアドでは、ｍａｘ＿ｅ２ｅ＿ＰＬＲ＿Ａｎｓについての値は９（９）に設定され得、ＵＬ＿ＰＬＲ＿Ａｎｓについての値は４（４）に設定され得、ＤＬ＿ＰＬＲ＿Ａｎｓについての値は２（２）に設定され得る。したがって、アンサー側デバイスからオファー側デバイスへの方向において、ｍａｘ＿ｅ２ｅ＿ＰＬＲ＿Ｏｆｆについての最大１０％のエンドツーエンドバジェットは、５％のエンドツーエンドバジェットを利用されないまま残して、オファー側へのダウンリンクについての１％のＰＬＲ、およびアンサー側からのアップリンクについての４％のＰＬＲに分割される。同様に、オファー側デバイスからアンサー側デバイスへの方向において、ｍａｘ＿ｅ２ｅ＿ＰＬＲ＿Ａｎｓについての最大９％のエンドツーエンドバジェットは、２％のエンドツーエンドバジェットを利用されないまま残して、アンサー側へのダウンリンクについての２％のＰＬＲ、およびオファー側からのアップリンクについての５％のＰＬＲに分割される。
【００４８】
[0057]  さらに別の例示的なインプリメンテーションでは、上述したようなＳＤＰオファー／アンサー交渉は、オファー側デバイスからのＳＤＰオファーに含まれるオファー側トライアドと抵触するＰＬＲ構成をアンサー側デバイスが有する状況に適用され得、ここでは、いずれかまたは両方の方向において、リンク固有ＰＬＲ値を最大エンドツーエンドＰＬＲ値に収めるために、全エンドツーエンドＰＬＲバジェットが利用される必要があり得る。例えば、この状況は、ｍａｘ＿ｅ２ｅ＿ＰＬＲ＿Ｏｆｆについての値が１０（１０）であり、ＵＬ＿ＰＬＲ＿Ｏｆｆについての値が７（７）であり、ＤＬ＿ＰＬＲ＿Ｏｆｆについての値が１（１）であるオファー側トライアドを含むＳＤＰオファーに例示され得る。ｍａｘ＿ｅ２ｅ＿ＰＬＲ＿Ａｎｓが７（７）であり、ＵＬ＿ＰＬＲ＿Ａｎｓが４（４）であり、およびＤＬ＿ＰＬＲ＿Ａｎｓが２（２）であるＰＬＲ構成をアンサー側デバイスが有すると仮定すれば、ＵＬ＿ＰＬＲ＿Ｏｆｆについての提案される値は、ｍａｘ＿ｅ２ｅ＿ＰＬＲ＿ＡｎｓとＤＬ＿ＰＬＲ＿Ａｎｓとの間の差によって定義される制限を超える。したがって、アンサー側デバイスは、ＵＬ＿ＰＬＲ＿Ｏｆｆ＋ＤＬ＿ＰＬＲ＿Ａｎｓ＝ｍａｘ＿ｅ２ｅ＿ＰＬＲ＿Ａｎｓであるように、ＵＬ＿ＰＬＲ＿Ｏｆｆについての値を７（７）から５（５）へと低減するようにＳＤＰオファーを修正し得る。そのような場合には、ＳＤＰアンサーは、ｍａｘ＿ｅ２ｅ＿ＰＬＲ＿Ａｎｓが７（７）であり、ＵＬ＿ＰＬＲ＿Ａｎｓが４（４）であり、ＤＬ＿ＰＬＲ＿Ａｎｓが２（２）であり、およびさらに、オファー側トライアドが、ｍａｘ＿ｅ２ｅ＿ＰＬＲ＿Ｏｆｆが１０（１０）のままであり、ＵＬ＿ＰＬＲ＿Ｏｆｆが５（５）に低減され、ＤＬ＿ＰＬＲ＿Ｏｆｆが１（１）のままであるように修正されるＳＤＰ属性を含み得る。ＳＤＰアンサーを受信すると、オファー側デバイスは、ペイロードタイプを受け入れるかまたは拒否することができる。
【００４９】
[0058]  様々な態様によれば、上に簡潔に述べたように、ＳＤＰオファー／アンサーで使用されるＳＤＰ属性の数が、上述したオファー側／アンサー側トライアドで使用される３つから低減されることができる、ある特定の場合が存在し得る。例えば、様々な実施形態において、所与の方向におけるアップリンクＰＬＲおよびダウンリンクＰＬＲは一般に、その方向における合計エンドツーエンドＰＬＲになると仮定されることができる。したがって、オファー側／アンサー側ＰＬＲ構成は、２つのパラメータ、すなわちアップリンクまたはダウンリンクのいずれかの方向におけるエンドツーエンドＰＬＲおよびリンク固有ＰＬＲに単純化され得る、なぜなら他方の方向におけるＰＬＲは他の値から導出されることができるからである。しかしながら、このアプローチは、（例えば、より良い音声品質を維持するために）全エンドツーエンドＰＬＲバジェットが利用されない状況は可能にしない。さらに、別の可能性のある単純化は、単に１つのパラメータ、すなわち最大エンドツーエンドＰＬＲバジェットのみを通信することであり得、それは、アップリンクＰＬＲおよびダウンリンクＰＬＲの間で最大エンドツーエンドＰＬＲバジェットが等しく分割されるインプリメンテーションによく適している可能性がある。
【００５０】
[0059]  様々な態様によれば、図４Ｃを特に参照して、上で説明された原理は、ＣＳＣＦ／ＰＣＲＦ４１２−１、４１２−２が、メッセージ４４２、４４４を使用して、要求される最大アップリンクＰＬＲおよびダウンリンクＰＬＲ値をｅＮＢ３２２−１、３２２−２に送る状況に適用され得る。例えば、ＳＤＰ交渉アプローチ（SDP-negotiated approach）では、ＵＥ３０２−１、３０２−２は、上述したものと事実上同様の方法で、それらのローカルｅＮＢ３２２−１、３２２−２に関連するアップリンクおよびダウンリンクに割り振るための最大エンドツーエンド（ｅ２ｅ）ＰＬＲの比率を交渉し得る。しかしながら、ＵＥ３０２−１、３０２−２に、直接的にｅＮＢ３２２−１、３２２−２に対して結果的なアップリンクおよびダウンリンクＰＬＲを要求させるのではなく、ＣＳＣＦ／ＰＣＲＦ４１２−１、４１２−２は、交渉されたＰＬＲ構成を抽出するためにＳＤＰアンサーを検査し、適切な値をそれぞれのローカルｅＮＢ３２２−１、３２２−２に通信し得る。例えば、ＵＥ３０２−１がオファー側デバイスであり、ＵＥ３０２−２がアンサー側デバイスである場合には、ＣＳＣＦ／ＰＣＲＦ４１２−１は、ＵＥ３０２−２からのＳＤＰアンサーに示された適切な値に基づいて、ｅＮＢ３２２−１に対して、ＵＥ３０２−１からのそれのアップリンク上でＵＬ＿ＰＬＲ＿Ｏｆｆをサポートするように求め得、さらに、ｅＮＢ３２２−１に対して、ＵＥ３０２−１へのそれのダウンリンク上でＤＬ＿ＰＬＲ＿Ｏｆｆについてサポートすることを求め得る。さらに、ＣＳＣＦ／ＰＣＲＦ４１２−２は、ｅＮＢ３２２−２に対して、ＵＥ３０２−２からのそれのアップリンク上でＵＬ＿ＰＬＲ＿Ａｎｓをサポートするように求め得、さらに、ｅＮＢ３２２−２に対して、ＵＥ３０２−２へのそれのダウンリンク上でＤＬ＿ＰＬＲ＿Ａｎｓをサポートするように求め得る。
【００５１】
[0060]  様々な態様によれば、ＰＣＲＦ交渉アプローチ（PCRF-negotiated approach）もまたインプリメントされ得、それはＵＥ３０２−１、３０２−２にサービス提供しているｅＮＢ３２２−１、３２２−２のカバレッジ状況およびローディングについてのより動的な情報をＣＳＣＦ／ＰＣＲＦ４１２−１、４１２−２が有し得る事実を有利に活用し得る。したがって、ＰＣＲＦ交渉アプローチでは、ＣＳＣＦ／ＰＣＲＦ４１２−１、４１２−２は、ｅＮＢ３２２−１、３２２−２に関連するアップリンクおよびダウンリンクに割り振るための最大エンドツーエンド（ｅ２ｅ）ＰＬＲの比率を以下の様に交渉する。最初に、アンサー側ＵＥ３０２−２へのＳＤＰオファー中に、オファー側ＵＥ３０２−１は、それの最大エンドツーエンドＰＬＲ（ｍａｘ＿ｅ２ｅ＿ＰＬＲ＿Ｏｆｆ）を示し得る。ＣＳＣＦ／ＰＣＲＦ４１２−１は、オペレータポリシーに基づいて、ｅＮＢ３２２−１のダウンリンクに、ｍａｘ＿ｅ２ｅ＿ＰＬＲ＿Ｏｆｆの比率をどのように割り振るかを決めるためにこのパラメータ値を見る可能性があり、それはＳＤＰオファーにＤＬ＿ＰＬＲ＿Ｏｆｆを追加することによって示され得る。ＣＳＣＦ／ＰＣＲＦ４１２−１はまた、ＳＤＰオファーにＵＬ＿ＰＬＲ＿Ｏｆｆを追加することによって好ましいアップリンクＰＬＲを示し得る。ＣＳＣＦ／ＰＣＲＦ４１２−２は、ＳＤＰオファーにＤＬ＿ＰＬＲ＿ＯｆｆおよびＵＬ＿ＰＬＲ＿Ｏｆｆの値を記憶し得、ＳＤＰオファーからこれらのＳＤＰパラメータを、これをアンサー側ＵＥ３０２−２に送る前に、削除し得る。アンサー側ＵＥ３０２−２は、ＳＤＰオファーを受信し、それが送り返すＳＤＰアンサーに、それの最大エンドツーエンドＰＬＲ、ｍａｘ＿ｅ２ｅ＿ＰＬＲ＿Ａｎｓを含めることによって応答する。ＣＳＣＦ／ＰＣＲＦ４１２−２は、ＳＤＰアンサーを受信し、ＤＬ＿ＰＬＲ＿ＡｎｓプラスＵＬ＿ＰＬＲ＿Ｏｆｆがｍａｘ＿ｅ２ｅ＿ＰＬＲ＿Ａｎｓより低いことをチェックする。この条件が満たされる場合には、ＣＳＣＦ／ＰＣＲＦ４１２−２は、ＤＬ＿ＰＬＲ＿ＡｎｓおよびＵＬ＿ＰＬＲ＿ＯｆｆをＳＤＰアンサーに追加する。そうでなければ、ＣＳＣＦ／ＰＣＲＦ４１２−２は、ＤＬ＿ＰＬＲ＿ＡｎｓおよびＵＬ＿ＰＬＲ＿Ｏｆｆの両方を修正してそれらの合計がｍａｘ＿ｅ２ｅ＿ＰＬＲ＿Ａｎｓより低いようにし、そしてそれらをＳＤＰアンサーに含める。同様の点で、ＣＳＣＦ／ＰＣＲＦ４１２−２は、ＵＬ＿ＰＬＲ＿ＡｎｓプラスＤＬ＿ＰＬＲ＿Ｏｆｆがｍａｘ＿ｅ２ｅ＿ＰＬＲ＿Ｏｆｆより低いことをチェックし得る。この条件が満たされる場合、ＣＳＣＦ／ＰＣＲＦ４１２−１は、ＵＬ＿ＰＬＲ＿ＡｎｓおよびＤＬ＿ＰＬＲ＿ＯｆｆをＳＤＰアンサーに追加し得る。そうでなければ、ＣＳＣＦ／ＰＣＲＦ４１２−２は、ＵＬ＿ＰＬＲ＿ＡｎｓおよびＤＬ＿ＰＬＲ＿Ｏｆｆの両方を修正してそれらの合計がｍａｘ＿ｅ２ｅ＿ＰＬＲ＿Ｏｆｆより低いようにし、そしてそれらをＳＤＰアンサーに含める。ＣＳＣＦ／ＰＣＲＦ４１２−１がＳＤＰアンサーを受信するとき、ＳＤＰアンサーは、ＣＳＣＦ／ＰＣＲＦ４１２−２によって修正されたＵＬ＿ＰＬＲ＿ＯｆｆおよびＤＬ＿ＰＬＲ＿Ｏｆｆの値が受け入れ可能でない場合には拒否され得る。ＣＳ���Ｆ／ＰＣＲＦ４１２−１がＳＤＰアンサーを受け入れる場合には、ＣＳＣＦ／ＰＣＲＦ４１２１、４１２−２の両方は、要求されるＵＬおよびＤＬ  ＰＬＲをそれらのローカルｅＮＢ３２２−１、３２２−２に通信するために必要なすべての情報を有する。
【００５２】
[0061]  様々な態様によれば、いくつかの実施形態では、ＰＣＲＦ交渉アプローチは、単一のＳＤＰパラメータ、すなわち最大エンドツーエンドＰＬＲまたはｍａｘ＿ｅ２ｅ＿ＰＬＲを使用してインプリメントされ得る。以下の説明では「＿Ｏｆｆ」および「＿Ａｎｓ」という付加部分は、説明されているものを理解することを助けるため、明確にするために追加されている、なぜなら実際のＳＤＰパラメータにおいてはｍａｘ＿ｅ２ｅ＿ＰＬＲパラメータのみが使用され得るからである。単一のＳＤＰパラメータを使用するＰＣＲＦ交渉アプローチでは、オファー側ＵＥ３０２−１は、ＳＤＰオファーにおいてｍａｘ＿ｅ２ｅ＿ＰＬＲ＿Ｏｆｆを送る。ＣＳＣＦ／ＰＣＲＦ４１２−１は、ＳＤＰオファー中のこのパラメータを見る可能性があり、ｍａｘ＿ｅ２ｅ＿ＰＬＲ＿Ｏｆｆより低いＤＬ＿ＰＬＲ＿ＯｆｆをそれがＵＥ３０２−１へのダウンリンク上で割り振ることにすると決め得る。ＣＳＣＦ／ＰＣＲＦ４１２−１はまた、新ｍａｘ＿ｅ２ｅ＿ＰＬＲ＿Ｏｆｆ＝旧ｍａｘ＿ｅ２ｅ＿ＰＬＲ＿Ｏｆｆ−ＤＬ＿ＰＬＲ＿Ｏｆｆであることを示すように、ＳＤＰオファーにおけるｍａｘ＿ｅ２ｅ＿ＰＬＲ＿Ｏｆｆパラメータを修正する。この修正されたＳＤＰオファーは、ＣＳＣＦ／ＰＣＲＦ４１２−２に送られ、それはｅＮＢ３２２−２におけるアップリンクＰＬＲをＵＬ＿ＰＬＲ＿Ａｎｓ＝新ｍａｘ＿ｅ２ｅ＿ＰＬＲ＿Ｏｆｆに設定するためにＳＤＰオファーにおける修正されたｍａｘ＿ｅ２ｅ＿ＰＬＲ＿Ｏｆｆ値を使用する。ＣＳＣＦ／ＰＣＲＦ４１２−２はまた、それが全ｅ２ｅＰＬＲバジェットを使用したくない場合には、新ｍａｘ＿ｅ２ｅ＿ＰＬＲ＿Ｏｆｆより低いＵＬ＿ＰＬＲ＿Ａｎｓを使用することを選び得る。反対の方向では同様のプロシージャが生じ、ここにおいて、アンサー側ＵＥ３０２−２は、それのｍａｘ＿ｅ２ｅ＿ＰＬＲ＿ＡｎｓをＳＤＰアンサーにおいて送る。ローカルＣＳＣＦ／ＰＣＲＦ４１２−２は、ｍａｘ＿ｅ２ｅ＿ＰＬＲ＿Ａｎｓの一部を取り、それをＤＬ＿ＰＬＲ＿ＡｎｓにおいてｅＮＢ３２２−２のダウンリンクに割り振る。ＣＳＣＦ／ＰＣＲＦ４１２−２はまた、新ｍａｘ＿ｅ２ｅ＿ＰＬＲ＿Ａｎｓ＝旧ｍａｘ＿ｅ２ｅ＿ＰＬＲ＿Ａｎｓ−ＤＬ＿ＰＬＲ＿Ａｎｓであることを示すように、ＳＤＰアンサーにおけるｍａｘ＿ｅ２ｅ＿ＰＬＲ＿Ａｎｓを修正する。ＣＳＣＦ／ＰＣＲＦ４１２−２は次いで、この修正されたｍａｘ＿ｅ２ｅ＿ＰＬＲ＿Ａｎｓ値をＣＳＣＦ／ＰＣＲＦ４１２−１に送り、それはＵＬ＿ＰＬＲ＿Ｏｆｆ＝新ｍａｘ＿ｅ２ｅ＿ＰＬＲ＿Ａｎｓであるように、ｅＮＢ３２２−１におけるアップリンクＰＬＲを設定するために、ＳＤＰアンサーにおける修正されたｍａｘ＿ｅ２ｅ＿ＰＬＲ＿Ａｎｓ値を使用する。ＣＳＣＦ／ＰＣＲＦ４１２−１はまた、それが全ｅ２ｅＰＬＲバジェットを使用したくない場合には、新ｍａｘ＿ｅ２ｅ＿ＰＬＲ＿Ａｎｓより低いＵＬ＿ＰＬＲ＿Ｏｆｆについての値を使用することを選び得る。
【００５３】
[0062]  様々な態様によれば、音声セッションに携わっている端末がカバレッジエッジに到達する際によりロバストなマルチメディアコーデックまたはコーデックモードを使用することになることを保証するために使用されることができる例示的な通信フローが、これより図５を参照して説明されることになる。特に、様々な実施形態に従って、音声セッションに携わっている各ＵＥは、音声セッションの間に実際のパケットロスレートを決定し得る。媒体パケットを受信する遠端のＵＥが不良ネットワークカバレッジに起因するパケットロスの増加を検出するとき、媒体パケットを受信する遠端のＵＥは、媒体パケットを送信するＵＥに、（例えば、ＡＭＲまたはＡＭＲ−ＷＢからＥＶＳへの移行、ＥＶＳからＥＶＳチャネルアウェアへの移行等の）よりロバストなコーデックまたはコーデックモードを使用することを求める要求を送り得る（例えば、コーデックモード要求（ＣＭＲ）を使用して）。他の例では、媒体パケットを受信するＵＥが不良ネットワークカバレッジに起因する増加したパケットロスを検出するとき、受信側ＵＥは、交渉されたビットレートに応じてアプリケーションレイヤ冗長性および／またはペイロードまたは部分的な冗長性を使用することを求める要求を送信側ＵＥに送り得る。別の可能性のある解決策では、送信側ＵＥは、（例えば、低送信電力ヘッドルーム、アップリンク送信バッファの増大等に起因する）不良ネットワークカバレッジを検出し得る。そのようなケースでは、送信側ＵＥは、よりロバストなコーデックまたはコーデックのよりロバストなモードを使用して送信することを自発的に開始し得る。
【００５４】
[0063]  様々な態様によれば、音声セッションに携わっている端末がよりロバストなマルチメディアコーデックまたはコーデックモードを使用することになることを保証するための別の可能性のある解決策が図５に例示される。図５に示される通信フローは、ＵＥ３０２−１、３０２−２の両方がコーデック適応を実施することになることを示すセッション記述プロトコル（ＳＤＰ）パラメータに基づき得、それは、５３２において実施される最初のコーデック交渉の一部として、ＵＥ３０２−１、３０２−２間で交換され得る。コアネットワーク要素（例えば、ＣＳＣＦ／ＰＣＲＦ４１２−１、４１２−２）がＳＤＰコーデック適応パラメータ／能力が交渉されたことを検出するとき、ＣＳＣＦ／ＰＣＲＦ４１２−１、４１２−２は、５４２、５４４において、最もロバストなモードに関連するＰＬＲをローカルｅＮＢ３２２−１、３２２−２に送り得る。これは、ネットワークカバレッジが不良になる場合には、ＵＥ３０２−１、３０２−２がよりロバストなコーデック／モードへと切り替わることになるという前提に基づき得る。そうでなければ、ＳＤＰコーデック適応パラメータ／能力が交渉されていない場合には、ＣＳＣＦ／ＰＣＲＦ４１２−１、４１２−２は、（例えば、ＵＥ３０２−１、３０２−２がよりロバストなコーデック／モードに切り替わることになるかどうかに関して不確実性があるとき、コール継続性を保証するために）最もロバストでないモードに関連するＰＬＲをローカルｅＮＢ３２２−１、３２２−２に送り得る。さらに、保証されたビットレート（ＧＢＲ）よりも最大ビットレート（ＭＢＲ）を高く設定するべきかどうか、および／または、保証されたビットレート（ＧＢＲ）よりも最大ビットレート（ＭＢＲ）をいつ高く設定するべきかを決定するためにコーデック適応パラメータをＣＳＣＦ／ＰＣＲＦ４１２−１、４１２−２が使用し得るので、このコーデック適応パラメータはまた、一般に有益であり得る。
【００５５】
[0064]  様々な態様によれば、カバレッジエッジにあるときのコーデックのエラーロバスト性を改善するために（ＥＶＳチャネルアウェアモードで使用される部分的な冗長性の代わりに）アプリケーションレイヤ冗長性を使用するときに生じ得る１つの可能性のある問題は、（例えば、異なるＰＬＣおよび／またはＪＢＭインプリメンテーション、異なるコーデック／モード構成オプション等の）会話品質とエラーロバスト性の間でトレードオフするいくつかの可能性が存在するので、高いパケットロスが検出されるときにＵＥ３０２−１、３０２−２が使用することになる特定の構成が、未知であり得ることである。したがって、この不確実性に対処するために、ＵＥ３０２−１、３０２−２のうちの１つまたは複数がカバレッジエッジに近づくか、またはそうでなければ増加したパケットロスおよび／または不良ネットワークカバレッジを検出するとき、ネットワーク要素（例えば、ｅＮＢ３２２−１、３２２−２およびＣＳＣＦ／ＰＣＲＦ４１２−１、４１２−２）が、何を求めるべきかを知り得るように、ＵＥ３０２−１、３０２−２は、それぞれのＵＥ３０２−１、３０２−２においてサポートされる「最もロバストなコーデック構成」を（例えば、ＳＤＰ中で）示すように構成され得る。適切なネットワーク要素（１つまたは複数）は、それにより、それぞれのＵＥ３０２−１、３０２−２によって示される最もロバストなコーデック構成に従って、適用可能ＳＲＶＣＣしきい値（１つまたは複数）を設定することができる。さらに、様々な実施形態において、オペレータはオプションとして、高いパケットロスが検出されるとき、特定の構成を使用するようにＵＥ３０２−１、３０２−２のうちの１つまたは複数を構成し得、およびこの構成は、遠端のｅＮＢおよびＵＥに、ＳＤＰを介してシグナリングされ得る。例示的な実施形態では、ＵＥ３０２−１、３０２−２からのシグナリングに基づいて、ｅＮＢ３２２−１、３２２−２は、それぞれＣＳＣＦ／ＰＣＲＦ４１２−１、４１２−２からのシグナリングに基づいて当初設定されたＳＲＶＣＣしきい値（１つまたは複数）をさらに更新するまたは修正するように構成され得る。別の例示的な実施形態では、ＣＳＣＦ／ＰＣＲＦ４１２−１、４１２−２からのシグナリングに基づいて、ｅＮＢ３２２−１、３２２−２は、それぞれＵＥ３０２−１、３０２−２からのシグナリングに基づいて当初設定されたＳＲＶＣＣしきい値（１つまたは複数）および／または他の好適なハンドオフしきい値をさらに更新または修正するように構成され得る。別の例示的な実施形態では、ｅＮＢ３２２−１、３２２−２は、ＵＥ３０２−１、３０２−２とＣＳＣＦ／ＰＣＲＦ４１２−１、４１２−２の両方からのシグナリングに基づいて、ＳＲＶＣＣしきい値（１つまたは複数）および／または他の好適なハンドオフしきい値をさらに更新または修正するように構成され得る。
【００５６】
[0065]  これより図６を参照すると、ここに説明される様々な態様および実施形態による使用に適切な構成を有し得るユーザ装置（ＵＥ）６００が例示される。一般に、ＵＥ６００は、１つまたは複数のプロセッサ６０５（例えば、１つまたは複数のＡＳＩＣ、１つまたは複数のデジタルシグナルプロセッサ（ＤＳＰ）等）およびメモリ６１０（例えば、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ（登録商標）、フラッシュカード、またはコンピュータプラットフォームに共通の任意のメモリ）を含み得る。ＵＥ６００はまた、１つまたは複数のＵＩ入力コンポーネント６１５（例えば、キーボードおよびマウス、タッチスクリーン、マイクロフォン、ボリュームまたは電力ボタンのような１つまたは複数のボタン等）、および１つまたは複数のＵＩ出力コンポーネント６２０（例えば、スピーカ、ディスプレイスクリーン、ＵＥ６００を振動させるためのバイブレーションデバイス等）を含む。
【００５７】
[0066]  ＵＥ６００はさらに、ワイヤード通信インタフェース６２５およびワイヤレス通信インタフェース６３０を含む。例示的な実施形態では、ワイヤード通信インタフェース６２５は、（例えば、イーサネットケーブルまたは別のタイプのケーブルであってＨＤＭＩｖ１．４またはより高度のもののようなワイヤードアクセスネットワークへのブリッジとして機能することができるものを介するなどして）ワイヤードアクセスネットワークへの、および／または（例えば、ＵＳＢ接続、ミニＵＳＢまたはライトニング接続、ヘッドホンジャック、グラフィックスポート、例えばシリアル、ＶＧＡ、ＨＤＭＩ（登録商標）、ＤＶＩ、またはディスプレイポート、オーディオポート等の）周辺デバイスへのワイヤードローカル接続をサポートするために使用されることができる。別の例示的な実施形態では、ワイヤレス通信インタフェース６３０は、（例えば、ＷＬＡＮ、Ｗｉ−Ｆｉダイレクト、Ｂｌｕｅｔｏｏｔｈ（登録商標）等の）ローカルワイヤレス通信プロトコルに従って通信するための１つまたは複数のワイヤレストランシーバを含む。ワイヤレス通信インタフェース６３０はまた、（例えば、ＣＤＭＡ、Ｗ−ＣＤＭＡ、時分割多元接続（ＴＤＭＡ）、周波数分割多元接続（ＦＤＭＡ）、直交周波数分割多重（ＯＦＤＭ）、ＧＳＭ、またはワイヤレス通信ネットワークまたはデータ通信ネットワークにおいて使用され得る他のプロトコルを介して）セルラＲＡＮと通信するための１つまたは複数のワイヤレストランシーバを含み得る。ＵＥ６００の様々なコンポーネント６０５〜６３０は、バス６３５を介して互いに通信することができる。
【００５８】
[0067]  図６に関して、ＵＥ６００は、スマートフォン、ラップトップコンピュータ、デスクトップコンピュータ、タブレットコンピュータ、ウェアラブルデバイス（例えば、歩数計、スマートウォッチ等）等に限定されるわけではないが、それらを含むいかなるタイプのＵＥにも対応し得る。ＵＥ６００の２つの特定のインプリメンテーションの例が図６に示され、それらはラップトップ６４０およびタッチスクリーンデバイス６５５（例えば、スマートフォン、タブレットコンピュータ等）として例示される。ラップトップ６４０は、ディスプレイスクリーン６４５およびＵＩエリア６５０（例えば、キーボード、タッチパッド、電力ボタン等）を含み、および示されていないが、ラップトップ６４０は、様々なポートならびにワイヤードおよび／またはワイヤレストランシーバ（例えば、イーサネットカード、ＷＬＡＮカード、ブロードバンドカード等）を含み得る。
【００５９】
[0068]  タッチスクリーンデバイス６５５は、当該技術分野において知られているように、いくつかのコンポーネントの中でもとりわけ、タッチスクリーンディスプレイ６６０、周辺機器ボタン６６５、６７０、６７５および６８０（例えば、電力制御ボタン、ボリュームまたはバイブレート制御ボタン、飛行機モードトグルボタン等）および少なくとも１つの前方パネルボタン６８５（例えば、ホームボタン等）で構成される。タッチスクリーンデバイス６５５の一部として明示的には示されていないが、タッチスクリーンデバイス６５５は、ＷＬＡＮアンテナ、セルラアンテナ、衛星ポジションシステム（ＳＰＳ）アンテナ（例えば、グローバルポジショニングシステム（ＧＰＳ）アンテナ）等に限定されるわけではないが、それらを含む、タッチスクリーンデバイス６５５の外装へと組み込まれた１つまたは複数の統合されたアンテナおよび／または１つまたは複数の外部のアンテナを含むことができる。
【００６０】
[0069]  様々な実施形態において、図６に例示されるＵＥ６００は、図３、図４Ａ〜図４Ｃ、および図５に例示されたＵＥ３０２−１、３０２−２を含む、上述したＵＥのいずれのものにも対応し得る。したがって、ＵＥ６００の様々なコンポーネントは、少なくとも、図３、図４Ａ〜図４Ｃ、および図５に例示されたＵＥ３０２−１、３０２−２に関連する機能を実施するための手段を提供し得る。
【００６１】
[0070]  これより図７を参照すると、そこに例示される例示的なアクセスポイント７００は、ここに説明される様々な態様および実施形態に従って使用され得る。アクセスポイント７００は、１つまたは複数のプロセッサ７０５（例えば、１つまたは複数のＡＳＩＣ、１つまたは複数のＤＳＰ等）、およびメモリ７１０（例えば、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュカード、またはコンピュータプラットフォームに共通の任意のメモリ）を含み得る。アクセスポイント７００はさらに、ワイヤード通信インタフェース７２５およびワイヤレス通信インタフェース７３０を含む。アクセスポイント７００の様々なコンポーネント７０５〜３３０は、バス７３５を介して互いに通信することができる。
【００６２】
[0071]  例示的な実施形態では、ワイヤード通信インタフェース７２５は、１つまたは複数のバックホールコンポーネントに接続するために使用されることができる。アクセスポイントが展開されるネットワークインフラストラクチャに応じて、ワイヤード通信インタフェース７２５を介してアクセスポイント７００が接続される先の１つまたは複数のバックホールコンポーネントは、基地局コントローラ（ＢＳＣ）、無線ネットワークコントローラ（ＲＮＣ）、他のアクセスポイント（例えば、ＬＴＥによって定義されるようなＸ２接続を介した他のノードＢ）、サービングゲートウェイ（Ｓ−ＧＷ）またはモバイル管理エンティティ（ＭＭＥ）のようなコアネットワークコンポーネント等を含み得る。
【００６３】
[0072]  別の例示的な実施形態では、ワイヤレス通信インタフェース７３０は、ワイヤレス通信プロトコルに従って通信するための１つまたは複数のワイヤレストランシーバを含む。ワイヤレス通信プロトコルは、アクセスポイント７００の構成に基づき得る。例えば、アクセスポイント７００がマクロセル７４０またはスモールセル７４５（例えば、フェムトセル、ピコセル等）としてインプリメントされる場合、ワイヤレス通信インタフェース７３０は、（例えば、ＣＤＭＡ、Ｗ−ＣＤＭＡ、ＧＳＭ、３Ｇ、４Ｇ、５Ｇ等の）セルラプロトコルをインプリメントするように構成される１つまたは複数のワイヤレストランシーバを含み得る。別の例では、アクセスポイント７００がワイヤレスローカルエリアネットワーク（ＷＬＡＮ）アクセスポイント７５０としてインプリメントされる場合、ワイヤレス通信インタフェース７３０は、（例えば、８０２．１１ａ、８０２．１１ｂ、８０２．１１ｇ、８０２．１１ｎ等の）Ｗｉ−Ｆｉ（または８０２．１１）プロトコルをインプリメントするように構成される１つまたは複数のワイヤレストランシーバを含み得る。
【００６４】
[0073]  様々な実施形態において、図７に例示されるアクセスポイント７００は、図３、図４Ａ〜図４Ｃ、および図５に例示されたｅＮＢ３２２−１、３２２−２を含む、上述したアクセスポイント、基地局等のうちのいずれのものにも対応し得る。したがって、図７に例示されるアクセスポイント７００の様々なコンポーネントは、少なくとも、図３、図４Ａ〜図４Ｃ、および図５に例示されたｅＮＢ３２２−１、３２２−２に関連する機能を実施するための手段を提供し得る。
【００６５】
[0074]  これより図８を参照すると、ここに例示される例示的な通信デバイス８００は、ここに説明される様々な態様および実施形態に従って構成されることができる様々な構造コンポーネントを含み得る。通信デバイス８００は、ＵＥまたはアクセスポイント、基地局、アクセスポイント、ｅＮＢ、ＢＳＣまたはＲＮＣのようなＲＡＮに含まれる任意のコンポーネント、ＣＳＣＦまたはＰＣＲＦまたはコアネットワークの任意の他の好適なコンポーネント、サーバ、またはインターネットに結合される任意の他のコンポーネント等に限定されるわけではないが、それらを含む、上述された通信デバイスのいずれのものにも対応することができる。したがって、通信デバイス８００は、ここに説明される１つまたは複数の他のエンティティと通信する（またはそれらとの通信を容易にする）ように構成される任意の電子デバイスに対応することができる。
【００６６】
[0075]  図８に関して、通信デバイス８００は、情報を受信および／または送信するように構成されるトランシーバ回路構成８０５を含む。一例では、通信デバイス８００がＵＥのようなワイヤレス通信デバイスに対応する場合、情報を受信および／または送信するように構成されるトランシーバ回路構成８０５は、ワイヤレストランシーバおよび関連したハードウェア（例えば、ＲＦアンテナ、ＭＯＤＥＭ、変調器および／または復調器等）のようなワイヤレス通信インタフェース（例えば、Ｂｌｕｅｔｏｏｔｈ、ＷＬＡＮ、Ｗｉ−Ｆｉダイレクト、ＬＴＥダイレクト等）を含むことができる。別の例では、情報を受信および／または送信するように構成されるトランシーバ回路構成８０５は、（例えば、インターネットがそれを通してアクセスされることができるイーサネット接続、Ｆｉｒｅｗｉｒｅ接続またはＵＳＢ、直列接続等の）ワイヤード通信インタフェースに対応することができる。したがって、通信デバイス８００がネットワークベースのサーバのいくつかのタイプに対応する場合、情報を受信および／または送信するように構成されるトランシーバ回路構成８０５は、一例ではイーサネットプロトコルを介して他の通信エンティティにネットワークベースのサーバを接続するイーサネットカードに対応することができる。さらなる例では、情報を受信および／または送信するように構成されるトランシーバ回路構成８０５は、（例えば、ローカルＲＦ信号をモニタするためのアンテナ、光センサ、温度センサ、加速度計等の）通信デバイス８００がそれのローカル環境をそれによってモニタすることができる、感覚または測定ハードウェア（sensory or measurement hardware）を含むことができる。情報を受信および／または送信するように構成されるトランシーバ回路構成８０５はまた、実行されると、情報を受信および／または送信するように構成されるトランシーバ回路構成８０５の関連するハードウェアに、それの受信および／または送信機能（１つまたは複数）の実施を許すソフトウェアを含むことができる。しかしながら、情報を受信および／または送信するように構成されるトランシーバ回路構成８０５は、ソフトウェア単体には対応せず、情報を受信および／または送信するように構成されるトランシーバ回路構成８０５は、それの機能性を達成するために少なくとも部分的に構造的ハードウェアに依存する。また、情報を受信および／または送信するように構成されるトランシーバ回路構成８０５は、根本的な機能が受信または送信機能に対応する限り、「受信する」および「送信する」以外の用語によって示され得る。例えば、取得する、獲得する、取り出す、測定する等のような機能は、特定のタイプの受信機能としてある特定のコンテキストにおいて情報を受信および／または送信するように構成されるトランシーバ回路構成８０５によって実施され得る。別の例では、送る（sending）、配信する、伝送する、送る（forwarding）等のような機能は、特定のタイプの送信機能としてある特定のコンテキストにおいて情報を受信および／または送信するように構成されるトランシーバ回路構成８０５によって実施され得る。他のタイプの受信および／または送信機能に対応する他の機能もまた、情報を受信お���び／または送信するように構成されるトランシーバ回路構成８０５によって実施され得る。
【００６７】
[0076]  図８に関して、通信デバイス８００はさらに、情報を処理するように構成される少なくとも１つのプロセッサ８１０を含む。情報を処理するように構成される少なくとも１つのプロセッサ８１０によって実施されることができる処理のタイプの例示的なインプリメンテーションは、決定を実施する、接続を確立する、異なる情報オプション間で選択を行う、データに関する評価を実施する、測定動作を実施するために通信デバイス８００に結合されたセンサと相互作用する、１つのフォーマットから別のフォーマットに情報を変換する（例えば、．ｗｍｖから．ａｖｉへのような異なるプロトコル間等で）等を含むが、それらに限定されるわけではない。例えば、情報を処理するように構成される少なくとも１つのプロセッサ８１０は、ここに説明された機能を実施するように設計された、汎用プロセッサ、ＤＳＰ、ＡＳＩＣ、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）または他のプログラマブル論理デバイス、ディスクリートゲートまたはトランジスタ論理、ディスクリートハードウェアコンポーネント、またはそれらの任意の組合せを含むことができる。汎用プロセッサは、マイクロプロセッサであり得るが、別の方法では、情報を処理するように構成される少なくとも１つのプロセッサ８１０は、任意の従来のプロセッサ、コントローラ、マイクロコントローラ、またはステートマシンであり得る。プロセッサはまた、コンピューティングデバイスの組合せ（例えば、ＤＳＰとマイクロプロセッサとの組合せ、複数のマイクロプロセッサ、ＤＳＰコアと連結した１つまたは複数のマイクロプロセッサ、または任意の他のそのような構成）としてもインプリメントされ得る。情報を処理するように構成される少なくとも１つのプロセッサ８１０はまた、実行されると、情報を処理するように構成される少なくとも１つのプロセッサ８１０の関連するハードウェアに、それの処理機能（１つまたは複数）を実施することを許すソフトウェアを含むことができる。しかしながら、情報を処理するように構成される少なくとも１つのプロセッサ８１０は、ソフトウェア単体には対応せず、情報を処理するように構成される少なくとも１つのプロセッサ８１０は、それの機能性を達成するために少なくとも部分的に構造的ハードウェアに依存する。また、情報を処理するように構成される少なくとも１つのプロセッサ８１０は、根本的な機能が処理機能に対応する限り、「処理する」以外の用語によって示され得る。例えば、評価する、決定する、計算する、識別する等のような機能は、特定のタイプの処理機能としてある特定のコンテキストにおいて情報を処理するように構成される少なくとも１つのプロセッサ８１０によって実施され得る。他のタイプの処理機能に対応する他の機能もまた、情報を処理するように構成される少なくとも１つのプロセッサ８１０によって実施され得る。
【００６８】
[0077]  図８に関して、通信デバイス８００はさらに、情報を記憶するように構成されるメモリ８１５を含む。一例では、情報を記憶するように構成されるメモリ８１５は、少なくとも非一時的なメモリおよび関連したハードウェア（例えば、メモリコントローラ等）を含むことができる。例えば、情報を記憶するように構成されるメモリ８１５に含まれる非一時的なメモリは、ＲＡＭ、フラッシュメモリ、ＲＯＭ、消去可能なプログラマブルＲＯＭ（ＥＰＲＯＭ）、ＥＥＰＲＯＭ、レジスタ、ハードディスク、リムーバブルディスク、ＣＤ−ＲＯＭ、または当該技術分野において知られている任意の他の形態の記憶媒体に対応することができる。情報を記憶するように構成されるメモリ８１５はまた、実行されると、情報を記憶するように構成されるメモリ８１５の関連するハードウェアに、それの記憶機能（１つまたは複数）を実施することを許すソフトウェアを含むことができる。しかしながら、情報を記憶するように構成されるメモリ８１５は、ソフトウェア単体には対応せず、情報を記憶するように構成されるメモリ８１５は、それの機能性を達成するために少なくとも部分的に構造的ハードウェアに依存する。また、情報を記憶するように構成されるメモリ８１５は、根本的な機能が記憶機能に対応する限り、「記憶する」以外の用語によって示され得る。例えば、キャッシュする、維持する等のような機能は、特定のタイプの記憶機能としてある特定のコンテキストにおいて情報を記憶するように構成されるメモリ８１５によって実施され得る。他のタイプの記憶機能に対応する他の機能もまた、情報を記憶するように構成されるメモリ８１５によって実施され得る。
【００６９】
[0078]  図８に関して、通信デバイス８００はさらに、オプションとして、情報を提示するように構成されるユーザインタフェース出力回路構成８２０を含む。一例では、情報を提示するように構成されるユーザインタフェース出力回路構成８２０は、少なくとも出力デバイスおよび関連したハードウェアを含むことができる。例えば、出力デバイスは、ビデオ出力デバイス（例えば、ディスプレイスクリーン、ＨＤＭＩ、ＵＳＢのようなビデオ情報を搬送することができるポート等）、オーディオ出力デバイス（例えば、スピーカ、ＨＤＭＩ、ＵＳＢ、マイクロフォンジャックのようなオーディオ情報を搬送することができるポート等）、バイブレーションデバイスおよび／または、情報がそれによって出力のためにフォーマットされるまたは通信デバイス８００のオペレータまたはユーザによって実際に出力されることができる任意の他のデバイスを含むことができる。例えば、通信デバイス８００が、図６に示されるようなＵＥ６００に対応する場合は、情報を提示するように構成されるユーザインタフェース出力回路構成８２０は、タッチスクリーンディスプレイ６６０またはディスプレイスクリーン６４５のようなディスプレイを含むことができる。さらなる例では、情報を提示するように構成されるユーザインタフェース出力回路構成８２０は、（例えば、ネットワークスイッチまたはルータ、リモートサーバ等の）ローカルユーザを有しないネットワーク通信デバイスのようなある特定の通信デバイスについては除外されることができる。情報を提示するように構成されるユーザインタフェース出力回路構成８２０はまた、実行されると、情報を提示するように構成されるユーザインタフェース出力回路構成８２０の関連するハードウェアに、それの提示機能（１つまたは複数）を実施することを許すソフトウェアを含むことができる。しかしながら、情報を提示するように構成されるユーザインタフェース出力回路構成８２０は、ソフトウェア単体には対応せず、情報を提示するように構成されるユーザインタフェース出力回路構成８２０は、それの機能性を達成するために少なくとも部分的に構造的ハードウェアに依存する。また、情報を提示するように構成されるユーザインタフェース出力回路構成８２０は、根本的な機能が提示機能に対応する限り、「提示する」以外の用語によって示され得る。例えば、表示する、出力する、促す、伝送する等のような機能は、特定のタイプの提示機能としてある特定のコンテキストにおいて情報を提示するように構成されるユーザインタフェース出力回路構成８２０によって実施され得る。他のタイプの提示機能に対応する他の機能もまた、情報を提示するように構成されるユーザインタフェース出力回路構成８２０によって実施され得る。
【００７０】
[0079]  図８に関して、通信デバイス８００はさらに、オプションとして、ローカルユーザ入力を受け取るように構成されるユーザインタフェース入力回路構成８２５を含む。一例では、ローカルユーザ入力を受け取るように構成されるユーザインタフェース入力回路構成８２５は、少なくとも、ユーザ入力デバイスおよび関連したハードウェアを含むことができる。例えば、ユーザ入力デバイスは、ボタン、タッチスクリーンディスプレイ、キーボード、カメラ、オーディオ入力デバイス（例えば、マイクロフォンジャックのようなオーディオ情報を搬送することができるポートまたはマイクロフォン等）、および／または通信デバイス８００のオペレータまたはユーザからそれによって情報が受け取られることができる任意の他のデバイスを含むことができる。例えば、通信デバイス８００が図６に示されるようなＵＥ６００に対応する場合は、タッチスクリーンディスプレイ６６０またはローカルＵＩエリア６５０を受け取るように構成されるユーザインタフェース入力回路構成等。さらなる例では、ローカルユーザ入力を受け取るように構成されるユーザインタフェース入力回路構成８２５は、（例えば、ネットワークスイッチまたはルータ、リモートサーバ等の）ローカルユーザを有しないネットワーク通信デバイスのようなある特定の通信デバイスについては除外されることができる。ローカルユーザ入力を受け取るように構成されるユーザインタフェース入力回路構成８２５はまた、実行されると、ローカルユーザ入力を受け取るように構成されるユーザインタフェース入力回路構成８２５の関連するハードウェアに、それの入力受取機能（１つまたは複数）を実施することを許すソフトウェアを含むことができる。しかしながら、ローカルユーザ入力を受け取るように構成されるユーザインタフェース入力回路構成８２５は、ソフトウェア単体には対応せず、ローカルユーザ入力を受け取るように構成されるユーザインタフェース入力回路構成８２５は、それの機能性を達成するために少なくとも部分的に構造的ハードウェアに依存する。また、ローカルユーザ入力を受け取るように構成されるユーザインタフェース入力回路構成８２５は、根本的な機能がローカルユーザ入力受取機能に対応する限り、「ローカルユーザ入力を受け取る」以外の用語によって示され得る。例えば、取得する、受け取る、収集する等のような機能は、特定のタイプのローカルユーザ受取機能としてある特定のコンテキストにおいてローカルユーザ入力を受け取るように構成されるユーザインタフェース入力回路構成８２５によって実施され得る。他のタイプのローカルユーザ入力受取機能に対応する他の機能もまた、ローカルユーザ入力を受け取るように構成されるユーザインタフェース入力回路構成８２５によって実施され得る。
【００７１】
[0080]  図８に関して、８０５〜８２５の構成された構造コンポーネントは（明示的に図示されていない）関連する通信バスを介して互いに黙示的に結合された別々のまたは個別のブロックとして図８では示されているが、８０５〜８２５のそれぞれの構成された構造コンポーネントがそれによってそれらのそれぞれの機能性を実施するソフトウェアおよび／またはハードウェアは部分的にオーバーラップすることができることは、認識されることになる。例えば、８０５〜８２５の構成された構造コンポーネントの機能性を容易にするために使用される任意のソフトウェアは、８０５〜８２５の構成された構造コンポーネントが各々、情報を記憶するように構成されるメモリ８１５によって記憶されるソフトウェアの動作に部分的に基づいてそれらのそれぞれの機能性（すなわち、このケースではソフトウェア実行）を実施するように、情報を記憶するように構成されるメモリ８１５に関連する非一時的なメモリに記憶されることができる。同様に、８０５〜８２５の構成された構造コンポーネントのうちの１つに直接的に関連するハードウェアは、時々８０５〜８２５の構成された構造コンポーネントのうちの他のものによって使用されるまたは借りられることができる。例えば、情報を処理するように構成される少なくとも１つのプロセッサ８１０は、情報を処理するように構成される少なくとも１つのプロセッサ８１０に関連する構造的ハードウェアの動作に部分的に基づいて、情報を受信および／または送信するように構成されるトランシーバ回路構成８０５がそれの機能性（すなわち、このケースでは、データの送信）を実施するように、情報を受信および／または送信するように構成されるトランシーバ回路構成８０５によって送信される前にデータを適切なフォーマットにフォーマットすることができる。
【００７２】
[0081]  ここに説明される様々な態様および実施形態は、図９に例示されるサーバ９００のような多様な市販のサーバデバイスのうちのいずれのものでもインプリメントされ得る。一例では、サーバ９００は、上述したサーバ１７０の１つの例示的な構成に対応し得る。図９では、サーバ９００は、揮発性メモリ９０２に結合されたプロセッサ９０１、およびディスクドライブ９０３のような大容量不揮発性メモリを含む。サーバ９００はまた、プロセッサ９０１に結合されたフロッピー（登録商標）ディスクドライブ、コンパクトディスク（ＣＤ）またはＤＶＤディスクドライブ９０６を含み得る。サーバ９００はまた、他のブロードキャストシステムコンピュータおよびサーバにまたはインターネットに結合されたローカルエリアネットワークのようなネットワーク９０７とのデータ接続を確立するためにプロセッサ９０１に結合されたネットワークアクセスポート９０４を含み得る。図８のコンテキストでは、図９のサーバ９００は、通信デバイス８００の１つの例示的なインプリメンテーションを例示し、それによって、情報を送信するおよび／または受信するように構成されるトランシーバ回路構成８０５は、ネットワーク９０７と通信するためにサーバ９００によって使用されるネットワークアクセスポート９０４に対応し、情報を処理するように構成される少なくとも１つのプロセッサ８１０は、プロセッサ９０１に対応し、情報を記憶するためのメモリ構成８１５は、揮発性メモリ９０２、ディスクドライブ９０３、および／またはディスクドライブ９０６のいかなる組合せにも対応することは、認識されることになる。情報を提示するように構成されるオプションのユーザインタフェース出力回路構成８２０およびローカルユーザ入力を受け取るように構成されるオプションのユーザインタフェース入力回路構成８２５は、図９に明示的に示されず、そこに含まれるまたは含まれない可能性がある。したがって、図９は、図８に例示された通信デバイス８００が、図６にあるようなＵＥ６００および／または図７にあるようなアクセスポイント７００に加えて、および／またはその代替として、図９に示されるようなサーバとしてインプリメントされ得ることを明示するのを助ける。
【００７３】
[0082]  当業者は、情報および信号は、多様な異なる技術および技法のうちのいずれを使用しても表され得ることを認識することになるだろう。例えば、上の説明の全体を通して言及された可能性のあるデータ、命令、コマンド、情報、信号、ビット、シンボル、およびチップは、電圧、電流、電磁波、磁場または磁性粒子、光場または光粒子、あるいはそれらの任意の組合せによって表され得る。
【００７４】
[0083]  さらに、当業者は、ここに開示された態様に関連して説明された様々な例示的な論理ブロック、モジュール、回路、アルゴリズムステップは、電子ハードウェア、コンピュータソフトウェア、またはその両方の組合せとしてインプリメントされ得ることを認識するだろう。ハードウェアおよびソフトウェアのこの互換性を明確に例示するために、様々な例示的なコンポーネント、ブロック、モジュール、回路、およびステップが、一般にそれらの機能性の観点から上に説明されている。そのような機能性が、ハードウェアとしてインプリメントされるかまたはソフトウェアとしてインプリメントされるかは、特定の用途およびシステム全体に課せられる設計制約に依存する。当業者は、特定の用途ごとに様々な方法において説明された機能性をインプリメントし得るが、そのようなインプリメンテーションの決定は、ここに説明された様々な態様および実施形態の適用範囲から逸脱するように解釈されるべきではない。
【００７５】
[0084]  ここに開示された態様に関連して説明された様々な例示的な論理ブロック、モジュール、回路は、汎用プロセッサ、デジタルシグナルプロセッサ（ＤＳＰ）、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）または他のプログラマブル論理デバイス、ディスクリートゲートまたはトランジスタ論理、ディスクリートハードウェアコンポーネント、またはここに説明された機能を実施するように設計されたそれらの任意の組合せを用いて、インプリメントまたは実施され得る。汎用プロセッサは、マイクロプロセッサであり得るが、別の方法では、プロセッサはいかなる従来のプロセッサ、コントローラ、マイクロコントローラ、またはステートマシンでもあり得る。プロセッサはまた、コンピューティングデバイスの組合せ（例えば、ＤＳＰとマイクロプロセッサとの組合せ、複数のマイクロプロセッサ、ＤＳＰコアと連結した１つまたは複数のマイクロプロセッサ、または他のそのような構成）としてもインプリメントされ得る。
【００７６】
[0085]  ここに開示された態様に関連して説明された方法、シーケンスおよび／またはアルゴリズムは、直接的にハードウェアにおいて、プロセッサによって実行されるソフトウェアモジュールにおいて、またはそれら２つの組合せにおいて、具現化され得る。ソフトウェアモジュールは、ＲＡＭ、フラッシュメモリ、ＲＯＭ、ＥＰＲＯＭ、ＥＥＰＲＯＭ、レジスタ、ハードディスク、リムーバブルディスク、ＣＤ−ＲＯＭ、または当該技術分野において周知であるその他任意の形態の非一時的なコンピュータ読み取り可能な媒体内に存在し得る。例示的な非一時的なコンピュータ読み取り可能な媒体は、プロセッサが非一時的なコンピュータ読み取り可能な媒体から情報を読み出すことができるように、および非一時的なコンピュータ読み取り可能な媒体に情報を書き込むことができるように、プロセッサに結合され得る。別の方法では、非一時的なコンピュータ読み取り可能な媒体は、プロセッサに統合され得る。プロセッサおよび非一時的なコンピュータ読み取り可能な媒体は、ＡＳＩＣに存在し得る。ＡＳＩＣは、ＩｏＴデバイス中に存在し得る。別の方法では、プロセッサおよび非一時的なコンピュータ読み取り可能な媒体は、ユーザ端末中のディスクリートコンポーネントであり得る。
【００７７】
[0086]  １つまたは複数の例示的な態様では、ここに説明される機能は、ハードウェア、ソフトウェア、ファームウェア、またはそれらの任意の組合せにおいてインプリメントされ得る。ソフトウェアでインプリメントされる場合、それら機能は、非一時的なコンピュータ読み取り可能な媒体上の１つまたは複数の命令またはコードとして記憶または送信され得る。コンピュータ読み取り可能な媒体は、１つの場所から別の場所へのコンピュータプログラムの転送を容易にし得る任意の非一時的な媒体を含む記憶媒体および／または通信媒体を含み得る。記憶媒体は、コンピュータによってアクセスされることができる任意の利用可能な媒体であり得る。限定ではなく例として、そのようなコンピュータ読み取り可能な媒体は、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、ＣＤ−ＲＯＭまたは他の光ディスク記憶装置、磁気ディスク記憶装置または他の磁気記憶デバイス、あるいは、命令またはデータ構造の形態で所望のプログラムコードを搬送または記憶するために使用されることができ、コンピュータによってアクセスされることができる、任意の他の媒体を備えることができる。また、いかなる接続も、コンピュータ読み取り可能な媒体と適切に称される。例えば、ソフトウェアが、同軸ケーブル、光ファイバーケーブル、ツイストペア、ＤＳＬ、または赤外線、無線、およびマイクロ波のようなワイヤレス技術を使用して、ウェブサイト、サーバ、または他のリモートソースから送信される場合、同軸ケーブル、光ファイバーケーブル、ツイストペア、ＤＳＬ、または赤外線、無線、およびマイクロ波のようなワイヤレス技術は、媒体の定義に含まれる。ディスク（disk）およびディスク（disc）という用語は、ここで置換え可能に使用され得、ＣＤ、レーザーディスク（登録商標）、光ディスク、ＤＶＤ、フロッピーディスク、およびＢｌｕ−ｒａｙ（登録商標）ディスクを含み、それらは通常データを磁気的に再生するおよび／またはレーザを用いて光学的に再生する。上記の組合せもまた、コンピュータ読み取り可能な媒体の範囲内に含まれるべきである。
【００７８】
[0087]  前述の開示は、例示的な態様および実施形態を示すが、当業者は、様々な変更および修正が、添付の特許請求の範囲によって定義されるような本開示の範囲から逸脱することなくここで成され得ることを認識することになるだろう。さらに、ここに説明される様々な例示的な態様および実施形態に従って、当業者は、上述した任意の方法におけるおよび／またはここに添付した任意の方法の請求項に記載した機能、ステップ、および／またはアクションは、如何なる特定の順序でも実施される必要はないことを認識することになるだろう。さらに、任意の要素が単数形で上述されたかまたは添付の特許請求の範囲に記載される範囲で、当業者は、単数形（１つまたは複数）への限定が明示的に述べられていない限り、単数形（１つまたは複数）は複数形も考慮することを認識することになるだろう。
【図１】
2020522940.tif 000003
【図２】
2020522940.tif 000004
【図３】
2020522940.tif 000005
【図４Ａ】
2020522940.tif 000006
【図４Ｂ】
2020522940.tif 000007
【図４Ｃ】
2020522940.tif 000008
【図５】
2020522940.tif 000009
【図６】
2020522940.tif 000010
【図７】
2020522940.tif 000011
【図８】
2020522940.tif 000012
【図９】
2020522940.tif 000013
【国際調査報告】
2020522940.tif 000014
2020522940.tif 000015