説明的な実施形態についての詳細な説明が、様々な図を参照して今から行われる。この説明は、可能な実施についての詳細な例を提供するが、詳細は例示的なものであり、決して本出願の範囲を限定するものではないことが意図されていることに留意されたい。
近接性発見またはD2Dリンク確立などのProximityサービスが(例えば、アプリケーションに代わって)アプリケーションサービスの一環として提供されることを可能にするためのシステムおよび/または方法(例えば、それらの様々な実施形態を含む)が開示され得る。例えば、一実施形態では、アプリケーションとD2Dサーバなどのサーバとの間で一時サービス名または一時識別子が確立され得、UEおよび/またはネットワークは、おそらくはアプリケーションからの関与またはアプリケーションの関与なしに、そのようなサービスを後で実行し得るようになる。加えて、実施形態では、(例えば、オープンIDによって定義される)中間識別情報が、アプリケーションがユーザ名をこの中間識別情報に変換し得、ネットワークに提供され得るD2D要求において識別情報を使用し得るように、(例えば、MNOによって)提供および/または使用され得る。加えて、そのようなシステムおよび方法は、本明細書で説明されるように、差別化サービス品質(QoS)をフローに提供し得る。例えば、サービスは、提供および/もしくは使用され得るD2Dネットワークサービスもしくは調整されたサービスを含むことができ、またはそれらのサービスとすることができる。サービスに基づいて、アプリケーションQoSなどのQoSが、本明細書で説明されるように、差別化され得る。
図1Aは、1または複数の開示される実施形態が実施され得る例示的な通信システム100の図を示している。通信システム100は、音声、データ、ビデオ、メッセージング、放送などのコンテンツを複数のワイヤレスユーザに提供する、多元接続システムとすることができる。通信システム100は、複数のワイヤレスユーザが、ワイヤレス帯域幅を含むシステムリソースの共用を通して、そのようなコンテンツにアクセスすることを可能にできる。例えば、通信システム100は、符号分割多元接続(CDMA)、時分割多元接続(TDMA)、周波数分割多元接続(FDMA)、直交FDMA(OFDMA)、およびシングルキャリアFDMA(SC-FDMA)など、1または複数のチャネルアクセス方法を利用できる。
図1Aに示されるように、通信システム100は、(一般にまたは一括してWTRU102と呼ばれることがある)無線送受信ユニット(WTRU)102a、102b、102c、および/または102d、無線アクセスネットワーク(RAN)103/104/105、コアネットワーク106/107/109、公衆交換電話網(PSTN)108、インターネット110、ならびに他のネットワーク112を含むことができるが、開示される実施形態は、任意の数のWTRU、基地局、ネットワーク、および/またはネットワーク要素を企図していることが理解されよう。WTRU102a、102b、102c、および/または102dの各々は、ワイヤレス環境において動作および/または通信するように構成された任意のタイプのデバイスとすることができる。例を挙げると、WTRU102a、102b、102c、および/または102dは、ワイヤレス信号を送信および/または受信するように構成され得、ユーザ機器(UE)、移動局、固定もしくは移動加入者ユニット、ページャ、セルラ電話、携帯情報端末(PDA)、スマートフォン、ラップトップ、ネットブック、パーソナルコンピュータ、ワイヤレスセンサ、家電製品などを含むことができる。
通信システム100は、基地局114aおよび基地局114bも含むことができる。基地局114a、114bの各々は、コアネットワーク106/107/109、インターネット110、および/またはネットワーク112などの1または複数の通信ネットワークへのアクセスを円滑化するために、WTRU102a、102b、102c、および/または102dの少なくとも1つとワイヤレスでインターフェース接続するように構成された、任意のタイプのデバイスとすることができる。例を挙げると、基地局114aおよび/または114bは、基地トランシーバ局(BTS)、ノードB、eノードB、ホームノードB、ホームeノードB、サイトコントローラ、アクセスポイント(AP)、およびワイヤレスルータなどとすることができる。基地局114a、114bは各々、単一の要素として示されているが、基地局114a、114bは、任意の数の相互接続された基地局および/またはネットワーク要素を含むことができることが理解されよう。
基地局114aは、RAN103/104/105の部分とすることができ、RAN103/104/105は、他の基地局、および/または基地局コントローラ(BSC)、無線ネットワークコントローラ(RNC)、中継ノードなどのネットワーク要素(図示されず)も含むことができる。基地局114aおよび/または基地局114bは、セル(図示されず)と呼ばれることがある特定の地理的領域内で、ワイヤレス信号を送信および/または受信するように構成され得る。セルは、さらにセルセクタに分割され得る。例えば、基地局114aに関連付けられたセルは、3つのセクタに分割され得る。したがって、一実施形態では、基地局114aは、送受信機を3つ、すなわち、セルのセクタ毎に1つずつ含むことができる。別の実施形態では、基地局114aは、多入力多出力(MIMO)技術を利用でき、したがって、セルのセクタ毎に複数の送受信機を利用できる。
基地局114aおよび/または114bは、エアインターフェース115/116/117上で、WTRU102a、102b、102c、および/または102dの1または複数と通信でき、エアインターフェース115/116/117は、任意の適切なワイヤレス通信リンク(例えば、無線周波数(RF)、マイクロ波、赤外線(IR)、紫外線(UV)、可視光など)とすることができる。エアインターフェース115/116/117は、任意の適切な無線アクセス技術(RAT)を使用して確立され得る。
より具体的には、上で言及されたように、通信システム100は、多元接続システムとすることができ、CDMA、TDMA、FDMA、OFDMA、およびSC-FDMAなどの、1または複数のチャネルアクセス方式を利用できる。例えば、RAN103/104/105内の基地局114a、ならびにWTRU102a、102b、および/または102cは、広帯域CDMA(WCDMA)を使用してエアインターフェース115/116/117を確立できる、ユニバーサル移動体通信システム(UMTS)地上無線アクセス(UTRA)などの無線技術を実施できる。WCDMAは、高速パケットアクセス(HSPA)および/または進化型HSPA(HSPA+)などの通信プロトコルを含むことができる。HSPAは、高速ダウンリンクパケットアクセス(HSDPA)および/または高速アップリンクパケットアクセス(HSUPA)を含むことができる。
別の実施形態では、基地局114a、ならびにWTRU102a、102b、および/または102cは、ロングタームエボリューション(LTE)および/またはLTEアドバンスト(LTE-A)を使用してエアインターフェース115/116/117を確立できる、進化型UMTS地上無線アクセス(E-UTRA)などの無線技術を実施できる。
他の実施形態では、基地局114a、ならびにWTRU102a、102b、および/または102cは、IEEE802.16(すなわち、マイクロ波アクセス用の世界的相互運用性(WiMAX))、CDMA2000、CDMA2000 1X、CDMA2000 EV-DO、暫定標準2000(IS-2000)、暫定標準95(IS-95)、暫定標準856(IS-856)、移動体通信用グローバルシステム(GSM)、GSMエボリューション用の高速データレート(EDGE)、およびGSM EDGE(GERAN)などの無線技術を実施できる。
図1Aの基地局114bは、例えば、ワイヤレスルータ、ホームノードB、ホームeノードB、またはアクセスポイントとすることができ、職場、家庭、乗物、およびキャンパスなどの局所的エリアにおけるワイヤレス接続性を円滑化するために、任意の適切なRATを利用できる。一実施形態では、基地局114b、およびWTRU102c、102dは、IEEE802.11などの無線技術を実施して、ワイヤレスローカルエリアネットワーク(WLAN)を確立できる。別の実施形態では、基地局114b、およびWTRU102c、102dは、IEEE802.15などの無線技術を実施して、ワイヤレスパーソナルエリアネットワーク(WPAN)を確立できる。また別の実施形態では、基地局114b、およびWTRU102c、102dは、セルラベースのRAT(例えば、WCDMA、CDMA2000、GSM、LTE、LTE-Aなど)を利用して、ピコセルまたはフェムトセルを確立できる。図1Aに示されるように、基地局114bは、インターネット110への直接的な接続を有することがある。したがって、基地局114bは、コアネットワーク106/107/109を介して、インターネット110にアクセスする必要がないことがある。
RAN103/104/105は、コアネットワーク106/107/109と通信でき、コアネットワーク106/107/109は、音声、データ、アプリケーション、および/またはボイスオーバインターネットプロトコル(VoIP)サービスをWTRU102a、102b、102c、および/または102dの1または複数に提供するように構成された、任意のタイプのネットワークとすることができる。例えば、コアネットワーク106/107/109は、呼制御、請求サービス、モバイルロケーションベースのサービス、プリペイド通話、インターネット接続性、ビデオ配信などを提供でき、および/またはユーザ認証など、高レベルのセキュリティ機能を実行できる。図1Aには示されていないが、RAN103/104/105および/またはコアネットワーク106/107/109は、RAN103/104/105と同じRATまたは異なるRATを利用する他のRANと直接的または間接的に通信できることが理解されよう。例えば、E-UTRA無線技術を利用できるRAN103/104/105に接続するのに加えて、コアネットワーク106/107/109は、GSM無線技術を利用する別のRAN(図示されず)と通信することもできる。
コアネットワーク106/107/109は、PSTN108、インターネット110、および/または他のネットワーク112にアクセスするための、WTRU102a、102b、102c、および/または102dのためのゲートウェイとしてもサービスできる。PSTN108は、基本電話サービス(POTS)を提供する回路交換電話網を含むことができる。インターネット110は、TCP/IPインターネットプロトコルスイート内の伝送制御プロトコル(TCP)、ユーザデータグラムプロトコル(UDP)、およびインターネットプロトコル(IP)など、共通の通信プロトコルを使用する、相互接続されたコンピュータネットワークとデバイスとからなるグローバルシステムを含むことができる。ネットワーク112は、他のサービスプロバイダによって所有および/または運営される有線またはワイヤレス通信ネットワークを含むことができる。例えば、ネットワーク112は、RAN103/104/105と同じRATまたは異なるRATを利用できる1または複数のRANに接続された、別のコアネットワークを含むことができる。
通信システム100内のWTRU102a、102b、102c、および/または102dのいくつかまたはすべては、マルチモード機能を含むことができ、すなわち、WTRU102a、102b、102c、および/または102dは、異なるワイヤレスリンク上で異なるワイヤレスネットワークと通信するための複数の送受信機を含むことができる。例えば、図1Aに示されたWTRU102cは、セルラベースの無線技術を利用できる基地局114aと通信するように、またIEEE802無線技術を利用できる基地局114bと通信するように構成され得る。
図1Bは、例示的なWTRU102のシステム図を示している。図1Bに示されるように、WTRU102は、プロセッサ118と、送受信機120と、送信/受信要素122と、スピーカ/マイクロフォン124と、キーパッド126と、ディスプレイ/タッチパッド128と、着脱不能メモリ130と、着脱可能メモリ132と、電源134と、全地球測位システム(GPS)チップセット136と、他の周辺機器138とを含むことができる。WTRU102は、実施形態との整合性を保ちながら、上記の要素の任意のサブコンビネーションを含むことができることが理解されよう。また、実施形態は、基地局114a、114b、ならびに/またはとりわけ、送受信機局(BTS)、ノードB、サイトコントローラ、アクセスポイント(AP)、ホームノードB、進化型ホームノードB(eNodeB)、ホーム進化型ノードB(HeNB)、ホーム進化型ノードBゲートウェイ、およびプロキシノードなどの、しかし、それらに限定されない、基地局114a、114bが表し得るノードが、図1Bに示され、本明細書で説明される要素のいくつかまたはすべてを含むことができることを企図している。
プロセッサ118は、汎用プロセッサ、専用プロセッサ、従来型プロセッサ、デジタル信号プロセッサ(DSP)、複数のマイクロプロセッサ、DSPコアと連携する1または複数のマイクロプロセッサ、コントローラ、マイクロコントローラ、特定用途向け集積回路(ASIC)、フィールドプログラマブルゲートアレイ(FPGA)回路、他の任意のタイプの集積回路(IC)、および状態機械などとすることができる。プロセッサ118は、信号符号化、データ処理、電力制御、入出力処理、および/またはWTRU102がワイヤレス環境で動作することを可能にする他の任意の機能を実行できる。プロセッサ118は、送受信機120に結合され得、送受信機120は、送信/受信要素122に結合され得る。図1Bは、プロセッサ118と送受信機120とを別々のコンポーネントとして示しているが、プロセッサ118と送受信機120は、電子パッケージまたはチップ内に一緒に統合され得ることが理解され得よう。
送信/受信要素122は、エアインターフェース115/116/117上で、基地局(例えば、基地局114a)に信号を送信し、または基地局から信号を受信するように構成され得る。例えば、一実施形態では、送信/受信要素122は、RF信号を送信および/または受信するように構成されたアンテナとすることができる。別の実施形態では、送信/受信要素122は、例えば、IR、UV、または可視光信号を送信および/または受信するように構成された放射器/検出器とすることができる。また別の実施形態では、送信/受信要素122は、RF信号と光信号の両方を送信および受信するように構成され得る。送信/受信要素122は、ワイヤレス信号の任意の組み合わせを送信および/または受信するように構成され得ることが理解されよう。
加えて、図1Bでは、送信/受信要素122は単一の要素として示されているが、WTRU102は、任意の数の送信/受信要素122を含むことができる。より具体的には、WTRU102は、MIMO技術を利用できる。したがって、一実施形態では、WTRU102は、エアインターフェース115/116/117上でワイヤレス信号を送信および受信するための2つ以上の送信/受信要素122(例えば、複数のアンテナ)を含むことができる。
送受信機120は、送信/受信要素122によって送信される信号を変調し、送信/受信要素122によって受信された信号を復調するように構成され得る。上で言及されたように、WTRU102は、マルチモード機能を有することができる。したがって、送受信機120は、WTRU102が、例えば、UTRAおよびIEEE802.11などの複数のRATを介して通信することを可能にするための、複数の送受信機を含むことができる。
WTRU102のプロセッサ118は、スピーカ/マイクロフォン124、キーパッド126、および/またはディスプレイ/タッチパッド128(例えば、液晶表示(LCD)ディスプレイユニットもしくは有機発光ダイオード(OLED)ディスプレイユニット)に結合され得、それらからユーザ入力データを受け取ることができる。プロセッサ118は、スピーカ/マイクロフォン124、キーパッド126、および/またはディスプレイ/タッチパッド128にユーザデータを出力することもできる。加えて、プロセッサ118は、着脱不能メモリ130および/または着脱可能メモリ132など、任意のタイプの適切なメモリから情報を入手でき、それらにデータを記憶できる。着脱不能メモリ130は、ランダムアクセスメモリ(RAM)、リードオンリメモリ(ROM)、ハードディスク、または他の任意のタイプのメモリ記憶デバイスを含むことができる。着脱可能メモリ132は、加入者識別モジュール(SIM)カード、メモリスティック、およびセキュアデジタル(SD)メモリカードなどを含むことができる。他の実施形態では、プロセッサ118は、WTRU102上に物理的に配置されたメモリではなく、サーバまたはホームコンピュータ(図示されず)などの上に配置されたメモリから情報を入手でき、それらにデータを記憶できる。
プロセッサ118は、電源134から電力を受け取ることができ、WTRU102内の他のコンポーネントへの電力の分配および/または制御を行うように構成され得る。電源134は、WTRU102に給電するための任意の適切なデバイスとすることができる。例えば、電源134は、1または複数の乾電池(例えば、ニッケル-カドミウム(NiCd)、ニッケル-亜鉛(NiZn)、ニッケル水素(NiMH)、リチウムイオン(Li-ion)など)、太陽電池、および燃料電池などを含むことができる。
プロセッサ118は、GPSチップセット136にも結合され得、GPSチップセット136は、WTRU102の現在位置に関する位置情報(例えば、経度および緯度)を提供するように構成され得る。GPSチップセット136からの情報に加えて、またはその代わりに、WTRU102は、基地局(例えば、基地局114a、114b)からエアインターフェース115/116/117上で位置情報を受け取ることができ、および/または2つ以上の近くの基地局から受信した信号のタイミングに基づいて、自らの位置を決定できる。WTRU102は、実施形態との整合性を保ちながら、任意の適切な位置決定方法を用いて、位置情報を獲得できることが理解されよう。
プロセッサ118は、他の周辺機器138にさらに結合され得、他の周辺機器138は、追加的な特徴、機能、および/または有線もしくはワイヤレス接続性を提供する、1または複数のソフトウェアモジュールおよび/またはハードウェアモジュールを含むことができる。例えば、周辺機器138は、加速度計、eコンパス、衛星送受信機、(写真またはビデオ用の)デジタルカメラ、ユニバーサルシリアルバス(USB)ポート、バイブレーションデバイス、テレビ送受信機、ハンズフリーヘッドセット、Bluetooth(登録商標)モジュール、周波数変調(FM)ラジオユニット、デジタル音楽プレーヤ、メディアプレーヤ、ビデオゲームプレーヤモジュール、およびインターネットブラウザなどを含むことができる。
図1Cは、実施形態による、RAN103およびコアネットワーク106のシステム図を示している。上で言及されたように、RAN103は、UTRA無線技術を利用して、エアインターフェース115上でWTRU102a、102b、および/または102cと通信できる。RAN103は、コアネットワーク106とも通信できる。図1Cに示されるように、RAN103は、ノードB140a、140b、および/または140cを含むことができ、ノードB140a、140b、および/または140cは各々、エアインターフェース115上でWTRU102a、102b、および/または102cと通信するための1または複数の送受信機を含むことができる。ノードB140a、140b、および/または140cは各々、RAN103内の特定のセル(図示されず)に関連付けることができる。RAN103は、RNC142aおよび/または142bも含むことができる。RAN103は、実施形態との整合性を保ちながら、任意の数のノードBおよびRNCを含むことができることが理解されよう。
図1Cに示されるように、ノードB140aおよび/または140bは、RNC142aと通信できる。加えて、ノードB140cは、RNC142bと通信できる。ノードB140a、140b、および/または140cは、Iubインターフェースを介して、それぞれのRNC142a、142bと通信できる。RNC142a、142bは、Iurインターフェースを介して、互いに通信できる。RNC142a、142bの各々は、それが接続されたそれぞれのノードB140a、140b、および/または140cを制御するように構成され得る。加えて、RNC142a、142bの各々は、アウタループ電力制御、負荷制御、アドミッションコントロール、パケットスケジューリング、ハンドオーバ制御、マクロダイバーシティ、セキュリティ機能、およびデータ暗号化など、他の機能を実施またはサポートするように構成され得る。
図1Cに示されるコアネットワーク106は、メディアゲートウェイ(MGW)144、モバイル交換センタ(MSC)146、サービングGPRSサポートノード(SGSN)148、および/またはゲートウェイGPRSサポートノード(GGSN)150を含むことができる。上記の要素の各々は、コアネットワーク106の部分として示されているが、これらの要素は、どの1つをとっても、コアネットワークオペレータとは異なる主体によって所有および/または運営され得ることが理解されよう。
RAN103内のRNC142aは、IuCSインターフェースを介して、コアネットワーク106内のMSC146に接続され得る。MSC146は、MGW144に接続され得る。MSC146とMGW144は、PSTN108などの回路交換ネットワークへのアクセスをWTRU102a、102b、および/または102cに提供して、WTRU102a、102b、および/または102cと従来の陸線通信デバイスの間の通信を円滑化できる。
RAN103内のRNC142aは、IuPSインターフェースを介して、コアネットワーク106内のSGSN148にも接続され得る。SGSN148は、GGSN150に接続され得る。SGSN148とGGSN150は、インターネット110などのパケット交換ネットワークへのアクセスをWTRU102a、102b、および/または102cに提供して、WTRU102a、102b、および/または102cとIP対応デバイスの間の通信を円滑化できる。
上で言及されたように、コアネットワーク106は、ネットワーク112にも接続され得、ネットワーク112は、他のサービスプロバイダによって所有および/または運営される他の有線またはワイヤレスネットワークを含むことができる。
図1Dは、実施形態による、RAN104およびコアネットワーク107のシステム図を示している。上で言及されたように、RAN104は、エアインターフェース116上でWTRU102a、102b、および/または102cと通信するために、E-UTRA無線技術を利用できる。RAN104は、コアネットワーク107とも通信できる。
RAN104は、eノードB160a、160b、および/または160cを含むことができるが、RAN104は、実施形態との整合性を保ちながら、任意の数のeノードBを含むことができることが理解されよう。eノードB160a、160b、および/または160cは、各々が、エアインターフェース116上でWTRU102a、102b、および/または102cと通信するための1または複数の送受信機を含むことができる。一実施形態では、eノードB160a、160b、および/または160cは、MIMO技術を実施できる。したがって、eノードB160aは、例えば、複数のアンテナを使用して、WTRU102aにワイヤレス信号を送信し、WTRU102aからワイヤレス信号を受信できる。
eノードB160a、160b、および/または160cの各々は、特定のセル(図示されず)に関連付けることができ、無線リソース管理決定、ハンドオーバ決定、ならびにアップリンクおよび/またはダウンリンクにおけるユーザのスケジューリングなどを処理するように構成され得る。図1Dに示されるように、eノードB160a、160b、および/または160cは、X2インターフェース上で互いに通信できる。
図1Dに示されるコアネットワーク107は、モビリティ管理ゲートウェイ(MME)162、サービングゲートウェイ164、およびパケットデータネットワーク(PDN)ゲートウェイ166を含むことができる。上記の要素の各々は、コアネットワーク107の部分として示されているが、これらの要素は、どの1つをとっても、コアネットワークオペレータとは異なる主体によって所有および/または運営され得ることが理解されよう。
MME162は、S1インターフェースを介して、RAN104内のeノードB160a、160b、および/または160cの各々に接続され得、制御ノードとしての役割を果たすことができる。例えば、MME162は、WTRU102a、102b、および/または102cのユーザの認証、ベアラアクティブ化/非アクティブ化、WTRU102a、102b、および/または102cの初期接続中における特定のサービングゲートウェイの選択などを担うことができる。MME162は、RAN104と、GSMまたはWCDMAなどの他の無線技術を利用する他のRAN(図示されず)との間の交換のためのコントロールプレーン機能も提供できる。
サービングゲートウェイ164は、S1インターフェースを介して、RAN104内のeノードB160a、160b、および/または160cの各々に接続され得る。サービングゲートウェイ164は、一般に、ユーザデータパケットのWTRU102a、102b、および/または102cへの/からの経路選択および転送を行うことができる。サービングゲートウェイ164は、eノードB間ハンドオーバ中におけるユーザプレーンのアンカリング(anchoring)、ダウンリンクデータがWTRU102a、102b、および/または102cに利用可能な場合に行う一斉呼出のトリガ、ならびにWTRU102a、102b、および/または102cのコンテキストの管理および記憶など、他の機能も実行できる。
サービングゲートウェイ164は、PDNゲートウェイ166にも接続され得、PDNゲートウェイ166は、インターネット110などのパケット交換ネットワークへのアクセスをWTRU102a、102b、および/または102cに提供して、WTRU102a、102b、および/または102cとIP対応デバイスの間の通信を円滑化できる。
コアネットワーク107は、他のネットワークとの通信を円滑化できる。例えば、コアネットワーク107は、PSTN108などの回路交換ネットワークへのアクセスをWTRU102a、102b、および/または102cに提供して、WTRU102a、102b、および/または102cと従来の陸線通信デバイスの間の通信を円滑化できる。例えば、コアネットワーク107は、コアネットワーク107とPSTN108の間のインターフェースとしての役割を果たすIPゲートウェイ(例えば、IPマルチメディアサブシステム(IMS)サーバ)を含むことができ、またはIPゲートウェイと通信できる。加えて、コアネットワーク107は、ネットワーク112へのアクセスをWTRU102a、102b、および/または102cに提供でき、ネットワーク112は、他のサービスプロバイダによって所有および/または運営される他の有線またはワイヤレスネットワークを含むことができる。
図1Eは、実施形態による、RAN105およびコアネットワーク109のシステム図を示している。RAN105は、IEEE802.16無線技術を利用して、エアインターフェース117上でWTRU102a、102b、および/または102cと通信する、アクセスサービスネットワーク(ASN)とすることができる。以下でさらに説明されるように、WTRU102a、102b、および/または102c、RAN105、ならびにコアネットワーク109の異なる機能エンティティ間の通信リンクは、参照点として定義され得る。
図1Eに示されるように、RAN105は、基地局180a、180b、および/または180cと、ASNゲートウェイ182とを含むことができるが、RAN105は、実施形態との整合性を保ちながら、任意の数の基地局とASNゲートウェイとを含むことができることが理解されよう。基地局180a、180b、および/または180cは、各々が、RAN105内の特定のセル(図示されず)に関連付けることができ、各々が、エアインターフェース117上でWTRU102a、102b、および/または102cと通信するための1または複数の送受信機を含み得る。一実施形態では、基地局180a、180b、および/または180cは、MIMO技術を実施できる。したがって、基地局180aは、例えば、複数のアンテナを使用して、WTRU102aにワイヤレス信号を送信し、WTRU102aからワイヤレス信号を受信できる。基地局180a、180b、および/または180cは、ハンドオフトリガリング、トンネル確立、無線リソース管理、トラフィック分類、およびサービス品質(QoS)ポリシ実施などの、モビリティ管理機能も提供できる。ASNゲートウェイ182は、トラフィック集約ポイントとしてサービスでき、ページング、加入者プロファイルのキャッシング、およびコアネットワーク109へのルーティングなどを担うことができる。
WTRU102a、102b、および/または102cとRAN105の間のエアインターフェース117は、IEEE802.16仕様を実施する、R1参照点として定義され得る。加えて、WTRU102a、102b、および/または102cの各々は、コアネットワーク109との論理インターフェース(図示されず)を確立できる。WTRU102a、102b、および/または102cとコアネットワーク109の間の論理インターフェースは、R2参照点として定義され得、R2参照点は、認証、認可、IPホスト構成管理、および/またはモビリティ管理のために使用され得る。
基地局180a、180b、および/または180cの各々の間の通信リンクは、WTRUハンドオーバおよび基地局間でのデータの転送を円滑化するためのプロトコルを含む、R8参照点として定義され得る。基地局180a、180b、および/または180cとASNゲートウェイ182の間の通信リンクは、R6参照点として定義され得る。R6参照点は、WTRU102a、102b、および/または102cの各々に関連するモビリティイベントに基づいたモビリティ管理を円滑化するためのプロトコルを含むことができる。
図1Eに示されるように、RAN105は、コアネットワーク109に接続され得る。RAN105とコアネットワーク109の間の通信リンクは、例えばデータ転送およびモビリティ管理機能を円滑化するためのプロトコルを含む、R3参照点として定義され得る。コアネットワーク109は、モバイルIPホームエージェント(MIP-HA)184と、認証認可課金(AAA)サーバ186と、ゲートウェイ188とを含むことができる。上記の要素の各々は、コアネットワーク109の部分として示されているが、これらの要素は、どの1つをとっても、コアネットワークオペレータとは異なる主体によって所有および/または運営され得ることが理解されよう。
MIP-HAは、IPアドレス管理を担うことができ、WTRU102a、102b、および/または102cが、異なるASNの間で、および/または異なるコアネットワークの間でローミングを行うことを可能にできる。MIP-HA184は、インターネット110などのパケット交換ネットワークへのアクセスをWTRU102a、102b、および/または102cに提供して、WTRU102a、102b、および/または102cとIP対応デバイスの間の通信を円滑化できる。AAAサーバ186は、ユーザ認証、およびユーザサービスのサポートを担うことができる。ゲートウェイ188は、他のネットワークとの網間接続を円滑化できる。例えば、ゲートウェイ188は、PSTN108などの回路交換ネットワークへのアクセスをWTRU102a、102b、および/または102cに提供して、WTRU102a、102b、および/または102cと従来の陸線通信デバイスの間の通信を円滑化できる。加えて、ゲートウェイ188は、ネットワーク112へのアクセスをWTRU102a、102b、および/または102cに提供し、ネットワーク112は、他のサービスプロバイダによって所有および/または運営される他の有線またはワイヤレスネットワークを含むことができる。
図1Eには示されていないが、RAN105は、他のASNに接続され得、コアネットワーク109は、他のコアネットワークに接続され得ることが理解されるべきであり、理解され得、および/または理解されよう。RAN105と他のASNの間の通信リンクは、R4参照点として定義され得、R4参照点は、RAN105と他のASNの間で、WTRU102a、102b、および/または102cのモビリティを調整するためのプロトコルを含むことができる。コアネットワーク109と他のコアネットワークの間の通信リンクは、R5参照として定義され得、R5参照は、ホームコアネットワークと在圏コアネットワークの間の網間接続を円滑化するためのプロトコルを含むことができる。
上で説明されたように、最近の5年間にわたって、セルラ通信の世界は、セルラ顧客またはユーザが寄せる期待に関して大きな変化を経験した。例えば、歴史的には、セルラまたはモバイル通信は、一般に、音声通話を含む単一の目的のために進化してきており、データ接続性は、好ましい拡張機能と見なされていた。加えて、非音声サービスは、「インターネット接続性」の傘の下に一括される傾向にあり、サービス品質(QoS)差別化は、問題とはならない傾向にあり、および/またはモバイルネットワークは、WTRUもしくはユーザ機器(UE)で生じるデータサービスに差別化QoSを提供するうえで重要な機能を有していない傾向にあった。
しかしながら、今日では、ワイヤレスおよびモバイルサービスが優勢になる傾向にある。例えば、ユーザは、様々なサービスおよび/またはサービス差別化を利用し得る数々のアプリケーションを実行する。例えば、そのようなアプリケーションは、以下のうちの1または複数を含むことができ、すなわち、小グループのプレーヤの間で行われる対話型ゲームは、そのようなプレーヤの間の最適化されたポイントツーポイント接続性を使用すること、またはその恩恵を受けることができ(例えば、これは、そのようなプレーヤが互いに物理的に近接して存在し、性能およびリソース使用を最適化し得る場合に特に言い得る)、電子リーダサービスからダウンロードされる書籍などのユーザダウンロードコンテンツは、迅速に(例えば、出発便に搭乗する前に)ダウンロードされる必要があることがあり、そのため、そのような購入に対しては、ユーザに関連付けられたデバイスへの最適化されたコンテンツ配送をもたらす、「迅速配送」が要求されることがあり、ユーザに関連付けられた心拍モニタは、異常を検出し得、その結果、高優先度のレポートが、ユーザに関連付けられた現在の所在地に物理的に近接した健康管理センタに転送され得る。実施形態では、そのようなサービスは、指定されたユーザのアプリケーションが他の潜在的なユーザの別のアプリケーションから受信し得、および/またはそれに送信し得る情報とすることができ、それは、そのような情報がどのように送信および/または受信され得るかを含む。さらに、そのようなサービスは、(例えば、サービスが自らを発見し得る、および/または発見し得ないことに関する)発見のための近接性情報またはロケーション情報を含む情報の転送を含むことができる。
加えて、モバイルネットワークは、効果的なサービス差別化を可能にし得る機能を有するように進化してきており、または現在も進化し続けている。サービス差別化についてのそのような進化の例は、以下のうちの1または複数を、すなわち、QoS最適化のために、バルクオフロードだけではなく、WiFiも使用し得ること、互いの範囲内にいるUEの間に直接デバイスツーデバイス(D2D)接続をセットアップし得ること、ロケーションおよび時刻などのコンテキスト情報に基づいてサービスをカスタマイズし得ること(例えば、送信先エンドポイント)のうちの1または複数を含むことができる。例示的な実施形態では、アプリケーションは、ネットワークがアプリケーションによるネットワークリソースの使用に応じて課金および/または料金請求し得るように、そのようなサービスを差別化し得る。
そのような発展は、モバイルネットワークがアプリケーションに提供し得るQoSが、アプリケーション自体、モバイルサービスおよび/もしくはアプリケーションサービスへのユーザの加入、「オンライン」状態にあり、ユーザに物理的に近接しているユーザの「友人」が存在するか、それとも存在しないか、ならびに/または様々な他のコンテキスト要因に(例えば、著しい程度で、または特定の程度で)依存し得る、未来を指し示すことができる。そのようなアプリケーションに固有の、コンテキストに依存したエクスペリエンスを可能にするために、アプリケーションが提供し得る特定のサービスをサポートし得るアプリケーションサービスプロバイダと、実際の接続性を提供し得るモバイルサービスプロバイダとの間で、新しいタイプの対話が使用され得る。そのような対話の性質は、本明細書で説明され得る。
実施形態では、提供され得る、および/またはユーザによって使用され得る、そのようなサービスおよび/または対話は、いくつかの特徴に従って分類され得る。そのような特徴の第1は、誰がサービスを使用し得るかに関連し得る。そのような実施形態では、サービスは、以下のうちの1または複数を含むことができる3つの広範なカテゴリにグループ化され得、すなわち、それらは、インターネットアクセスを目的とするテザリング(またはカバレージ拡張という密接な関連がある概念)など、誰にでも利用可能であり得る無差別なサービスまたはそのようなタイプのサービス、対話型ゲームおよび/またはオンラインコラボレーションなどの同じサービスを共用し得、事前定義され得る(例えば、既存のCompName+Circle)、または他のどのユーザとサービスを共用したいかを指定することによってサービスセットアップ時にユーザによって定義され得る、ユーザの閉鎖的なグループまたは一般に明確に定義された通常は小規模なグループ、ならびに閉鎖的なグループが単一のユーザになるように制限され得る場合に、閉鎖的なグループのサービスの特殊なケースとして扱われ得るサービスのタイプとすることができる、健康管理および購入されたオンラインコンテンツの「迅速」ダウンロードなど、特定のユーザに固有のユーザまたはサービスである。本明細書で説明されるように、「閉鎖的なグループ」のサービスは、「ユーザ固有」のサービスを含むことができる。
そのようなサービスおよび/または対話の第2の特徴は、それらに関連付けられたカスタマイズのレベルとすることができる。そのような実施形態では、サービスは、汎用または調整(例えば、個人化)として差別化され得る。汎用は、各セッションが他の1または複数のセッションと、広い範囲にわたって、同じまたは類似の特徴を有し得る、サービスを含むことができる。例えば、電子書籍ブラウズおよび購入セッション(例えば、AmazonのKindle)は、そのようなセッションを開始し得、非常に長い時間にわたってセッションを維持し得るユーザについて、ほぼ同じ送信先(例えば、Kindleサーバファーム)およびQoS使用(例えば、要件)を有し得る。
調整されたサービスは、あらゆるセッションが異なり得る、サービスを含むことができる。例えば、対話型ピアツーピアゲームの各セッションは、異なる場所にいる異なるユーザを含むことができ、接続性を確立するために異なるタイプの最適化を使用し得る。そのようなタイプのサービスは、調整されたサービスとすることができる(例えば、調整と呼ばれることがある)。別の例は、ユーザが購入した書籍の迅速ダウンロードを要求し得る場合とすることができる。ダウンロードは、そのユーザのコンテキスト(例えば、支払った料金、場所、利用可能なネットワーク、およびコンテンツサイズなど)に応じて最適化されなければならないので、電子書籍ダウンロードは、調整されたサービスとすることができる(例えば、調整と呼ばれることがある)。
調整されたサービスの2つの特徴は、そのようなサービスが通常は、閉鎖的なグループ向けであること、および/または短期間であることとすることができる。例えば、汎用「電子書籍」サービスと、「Jane Doeが彼女の現在地であるJFK国際空港の1番ターミナルで今から2分以内に「戦争と平和」を1部獲得し得るように設計された電子書籍ダウンロード」は、様々な相違を含むことができる。前者は、長い期間にわたって、複数の場所にいる多くのユーザに対して、基本的に同じであり続け得る。したがって、アプリケーションプロバイダとネットワークオペレータが、このサービスがどのように処理され得るかについてオフラインで「事前ネゴシエート」し、ポリシおよび手順をネットワーク機器およびユーザデバイスに事前プログラムすることが可能であり得る。後者のサービスは、それを使用し得る特定のユーザのために特定の場所においてサービスが使用され得る時間の範囲が狭く、その範囲の外では無意味であり得る。そのようなサービスを事前セットアップしようとする試みは失敗するであろう。したがって、アプリケーションサービスとネットワークオペレータの間の何らかの自発的なリアルタイムオンラインネゴシエーションが使用され得る。そのようなタイプのネゴシエーションは、本明細書で説明され得る。
一例では、アプリケーションサービスプロバイダとモバイルネットワークオペレータの間のネゴシエーションのための調整されたサービスセットアップは、本明細書で説明されるような閉鎖的なグループの調整されたサービスにおいて、ならびに/または同様に無差別的もしくは汎用的なサービスにおいても、定義および/または適用され得る。
加えて、本明細書で説明されるように、アプリケーションサービスに関連付けられたモバイルネットワークサービスは、リアルタイムで生成され、管理され得る。本明細書で開示される実施形態を定式化する場合、モバイルネットワークと想定されるアプリケーションサーバとの間の対話に関して、様々な対話、仮定、または特徴が提供され、および/または使用され得る。例えば、一実施形態では、アプリケーションサーバ(AppSe)とモバイルネットワークの間の合理的な対話が提供され得る。そのような対話は、存在し得る、または存在すると仮定され得る、確立されたビジネス関係を使用し得る。加えて、実施形態では、UEまたはモバイルデバイスは、それらがサービス契約を有し得るアプリケーションサーバにアクセスし得るが、モバイルネットワーク(MN)は、例えば、モバイルオペレータとアプリケーションサーバ(もしくはアプリケーションエンティティサーバ)のオペレータとの間の(例えば、ビジネス関係などの)関係が欠如している(ならびに/または相手に知られているMNおよび/もしくはアプリケーションサーバの証明書が欠如している)せいで、そのようなアプリケーションサーバにアクセスし得ないことがある。そのような関係の欠如は、同じ機能を提供するために使用され得る(例えば、MNとアプリケーションサーバの間のアクセスを可能にし得、標準化され得る、または標準化され得ない)(例えば、本明細書で開示される)実施形態および機能をもたらすことができる。
上で説明されたように、(例えば、「ソケットインターフェース」(例えば、アプリケーションプログラミングインターフェース(API))を使用して、IPアドレスを通して、互いに通信し得るアプリケーションなどの)アプリケーションは、それらを実行しているであろうデバイスの物理的コンテキストを認識するように設計され得ない。例えば、アプリケーションは、デバイスに関連付けられたMACアドレスを認識すること、特定のデバイスに対する他のデバイスの近接性についての情報を認識すること、および使用または提供され得る下層のアクセス制御メカニズムを認識することなどができない。他方、モバイルネットワークは、ネットワーク内のデバイス、およびそれらの物理的特性を認識し得る(例えば、デバイスの物理的近接性は、モバイルネットワークが当然所有し得る情報のタイプとすることができる)。モバイルネットワークは、IPアドレスをデバイスに割り当てること、および例えば、デバイスが移動するときなど、IPアドレスのシームレスな接続性を保証し、不変性も保証することに責任をもつこともできる。しかしながら、モバイルネットワークは、ユーザが提供され得るIP接続性をどのように使用するかについては最低限の認識を有し得るにすぎない。そのため、モバイルネットワークは、IPデータストリームを個々の「アプリケーションフロー」に差別化して分けることはできるとしても、1または複数のユーザに関連付けられた、アプリケーション識別情報、プリファレンス、およびソーシャルアソシエーションなどを認識し得ない。
加えて、モバイルネットワークは、特定のアプリケーションフローを識別し、それをいくつかのアプリケーションサービスに関連付けることができるが、そのようなフローに、差別化QoSを提供すべき場合に、どの差別化QoSを提供すべきかを知り得ない。上で説明されたように、そのような情報は事前構成され得る。しかしながら、そのような情報の事前構成は、突然サービスが生じるまで、サービスについて何も分からないので、事前構成が可能でないことがある、調整されたサービスに対しては機能し得ない(例えば、失敗することがある)。そのため、そのような実施形態において、(例えば、本明細書で説明されるような)方法、技法、またはプロセスが提供され得る。
本明細書では、近接性発見またはD2Dリンク確立などのProximityサービスが(例えば、アプリケーションに代わって)アプリケーションサービスの一環として提供されることを可能にする、実施形態が開示され得る。
例えば、実施形態(例えば、第1の方法または手順)では、アプリケーションとネットワークまたはD2Dサーバなどのサーバとの間における一時サービス名の確立を可能にする、アーキテクチャおよび関連する手順が提供され得る。そのような実施形態は、UEおよびネットワークが、おそらくはアプリケーションの直接的な関与なしに、そのようなサービスを後で実行することを可能にし得る。
別の実施形態(例えば、第2の方法または手順)では、アプリケーションは、D2Dサービスの実行中、関与し続け得る。そのような実施形態では、一時サービス名は、使用されなくてよい。代わりに、MNOによって提供される中間識別情報(例えば、ブートストラップID(B-TID)またはオープンID)が提供および/または使用され得る。そのような実施形態では、アプリケーションは、ユーザ名を中間識別情報に変換し得、その後、ネットワークに送信されるD2D要求において、そのような識別情報を使用し得る。加えて、実施形態によれば、中間識別情報がUE上のアプリケーションに提供され得た場合、アプリケーションは、発見中に関与し続けることを必要としなくてよい。
加えて、両方の実施形態は、相補的とすることができる。例えば、アプリケーションは、(例えば、第1の方法または手順において)D2D動作とは独立とすることができ、UEドリブンモデルを可能にするが、アプリケーション内でのProximityサービスのより踏み込んだ統合が、(例えば、第2の方法または手順において)可能にされ得る。さらに、両方の実施形態は、様々な利点を有することができる。例えば、第1の方法または手順は、ユーザが、アプリケーションにログオンせずに、ProSeに従事することを可能にし得、それは、バッテリ消費とシグナリングにおけるネットワークトラフィックを低減させ、およびアライブメッセージを保つことができる。第2の方法または手順は、アプリケーションが、ProSeサービスの料金を、また特定のイベントが、例えば、発見の試みおよび発見の成功などの料金を、どのように(例えば、いくら)課され得るかを含む、アプリケーションのリアルタイム制御を可能にし得る。
第1の方法または手順では、D2Dネットワークサービスなどのサービスは、QoS差別化のために使用され得る。そのようなサービスは、アプリケーションQoSを差別化するために使用され得る。加えて、実施形態では、例示的なアプリケーションは、ユーザ(または人々)のグループの間でプレーされ得る、対話型ゲーム(例えば、GameName)を含むことができる。そのようなアプリケーションまたは対話型ゲームでは、グループは、(例えば、目標として)中世の都市国家を建設および/または維持するなどの目標または目的を実行および/または実施し得、ゲームサーバによってシミュレートされ得る攻撃から、それを守り得る。加えて、都市は、参加者の閉鎖的なグループに関連付けることができ、グループどうしは、対話し得ない。実施形態では、グループの一人のプレーヤがオンラインであり、プレーし得ている場合、その都市に関連付けられたセッションは、アクティブであり得る。そのため、ゲームは、プレーヤ間のデータレートを高くし、待ち時間を短くするために、QoSが高い接続を使用し得、プレーヤが直接無線(D2D)リンクを確立し得る場合は、いくつかの機能が可能にされ得る。
実施形態では(例えば、第1の方法または手順を実行する場合)、モバイルネットワーク(MN)からアプリケーションサーバ(AppSE)へのインターフェースが提供および/または使用され得る(例えば、存在し得る)。そのような実施形態では、リアルタイムサービスネゴシエーションは、以下のように提供され得る。アプリケーションサーバは、以下のことを、すなわち、他のアプリケーションユーザを参照するために、またはそれと交信するために、各アプリケーションユーザによって使用され得るサービスおよび識別情報を使用することを許可されたユーザのリスト、コンテキスト固有の情報(例えば、ロケーション制限)などを含む、サービスのQoS要求または要望、ならびに(例えば、料金が請求され得る)モバイルネットワークプロバイダによるそのようなサービスの提供が行われる適用可能なビジネス期間を知り得、または一般に認識し得る。
加えて、アプリケーションサーバは、新しいサービスを確立するために、モバイルネットワークに要求または要望(例えば、必要)を通知し得る。そうする際、アプリケーションサーバは、サービスのパラメータ(例えば、QoS差別化要望(または要求)、ならびに手段およびロケーション制限など)をネゴシエートし得る。加えて、アプリケーションサーバは、どのユーザがサービスの使用を許可され得るかを、ネットワークに分からせることもできる。例えば、アプリケーションサーバは、GameNameセッションなどの新しいアプリケーションまたはゲームセッションが開始し得たこと、この特定のセッションがD2Dリンク上で動作し得る(例えば、それがゲームのD2D機能(例えば、D2D限定機能)のためのセッションであり得る)ことを、ネットワークに通知し得る。
実施形態では(例えば、サービスが無差別的でない限り)、(例えば、特定のユーザの)ユーザ識別情報が、(例えば、MNからAppSeへのインターフェースが存在し得る場合)使用されることがあり、または使用されなければならないことがある。例えば、アプリケーションサーバは、開始されたセッションにどのユーザが参加し得るかを、ネットワークに通知しなければならないことがある。その結果、アプリケーションによって使用されるユーザIDは、ネットワークによって使用されるユーザIDに関連付けることができる。例えば、アプリケーションサーバおよびネットワークプロバイダは、ネットワークプロバイダによって使用されるIDを生成すること、および/またはそれを持続的なアプリケーション識別情報(例えば、本明細書で説明されるような、アプリケーションサーバにおけるユーザの識別情報)に関連付けることができる。加えて、アプリケーションおよびモバイルネットワークの両方によって信頼され得る、サードパーティ識別情報プロバイダが使用され得る。オープンIDプロトコルは、そのような連合識別情報管理サービスをサポートし得る、プロトコルの例とすることができる。実施形態では、ネットワークプロバイダによって使用され得る識別情報は、2以上のネットワークプロバイダにわたっても使用可能であり得る。例えば、グループ内の1つのユーザは、1つのMNOによってアプリケーションサービスを提供され得、同じグループ内の別のユーザは、別のMNOによってアプリケーションサービスを提供され得、識別情報は、MNOにわたって一致され得、例えば、アプリケーションサーバにおける、単一の一意的な識別情報まで遡り得る。加えて、実施形態では、そのような識別情報は、オープンな(例えば、無差別的な)発見のためにさえも有益であり得る。例えば、そのような識別情報は、UEまたはユーザによって発見され得るが、依然として識別子を使用すること、または必要とすることがある、商業的な広告のために使用され得る。
アプリケーションサービスとネットワークプロバイダが、新しいサービスの確立についてネゴシエートし得た後、一時サービス名が、与えられたネットワークプロバイダに関連付けられたサービスのために生成され得る。アプリケーションプロバイダは、このサービス名を、この特定のネットワークオペレータを利用し得るユーザの各々に提供し得る。実施形態では、この点では、アプリケーションプロバイダの役割は、限られたものであり得る。例えば、アプリケーションプロバイダは、セッションが変更される必要があり得る(例えば、ユーザがオンラインになり、または退出したために、セッションQoSが再ネゴシエートまたは終了され得る)場合に呼び出され、または使用され得る。それとは別に、新たに生成されたサービスは、事前ネゴシエートされたQoS(例えば、事前ネゴシエートされたQoS要求、要望、または必要)を用いる汎用的な「命名された」サービスとして、ネットワークによって扱われ得、ネットワークは、そのようなサービスのための接続性管理を引き継ぎ得る。
本明細書で説明されるように、実施形態では、アプリケーション識別子(ID)とネットワークIDの間のマッピングは、一対一とすることができる。あるいは、実施形態では、単一のネットワーク識別情報と複数のアプリケーション識別情報の間の一対多マッピングが、提供および/または使用され得る。これは、識別情報を維持および更新するために使用され得る、ネットワークシグナリングを節約し得る。このタイプのマッピングを用いて行われる発見は、コンテキストが、発見が行われ得たアプリケーションのうちのどれのものかを一意的に識別し得ないことがある。そのため、手順および/または方法では、発見後に、追加のアクションが提供され得る。例えば、アプリケーションは、そのようなサーバまたはアプリケーションのどれがさらなるアクションを取るべきかを決定するために、それぞれのアプリケーションサーバと交信し得る。加えて、実施形態では、UEは、(例えば、サービスのためのセッションを開始する場合、および/またはそれに参加する場合)安全な通信チャネルを確立し得、その後、互いの間で(例えば、曖昧さが存在し得ない)アプリケーション識別情報を交換し得る。
ネットワークオペレータは、UEおよび他のネットワーク機器が従い得るポリシおよび/または手順において、サービス名を使用し得る。例えば、実施形態では、D2Dサービスを可能にすることは、D2Dを使用するフローのために、UEによって特定の組のIPアドレスを使用することを含むことができる。そのような実施形態では、ネットワークは、例えば、特定のセッションに関連付けられたアプリケーション(例えば、GameNameアプリケーション)によって開始されたフローが、D2D対応IPアドレスおよび送信元IPを使用し得ることを、UEに知らせることができる。
別の例示的な実施形態では(例えば、第1の方法または手順を実行する場合)、MNからアプリケーションサーバ(AppSe)へのインターフェースが、提供および/または使用されないことがある(例えば、存在しないことがある)。そのような実施形態では、(例えば、リアルタイムの)サービスネゴシエーションが、以下のように提供され得る。アプリケーションサーバは、以下のことを、例えば、サービスおよびそれらの識別情報を使用することを許可されたユーザのリスト、コンテキスト固有の情報(例えば、ロケーション制限)などを含む、サービスのQoS要求または要望、ならびに請求を含むモバイルネットワークプロバイダによるそのようなサービスの提供が行われる適用可能なビジネス期間などの、パラメータまたは情報を知ることができ、または一般に認識し得る。
実施形態によれば、モバイルネットワークオペレータ(MNO)に登録され得る、UEおよびWTRUなどのモバイルデバイスは、AppSeに安全にアクセスし得、それ(例えば、AppSe)を用いて、上で説明されたパラメータを確立し得る。これらのパラメータを確立した後、パラメータは、その後、デバイス上に記憶され得る。
加えて、アプリケーションに関連するサービスに関心があり得るUEは、ネットワークまたはMNOと交信し得、新しいサービスを要求し得る。サービスタイプおよびパラメータなどの1または複数のパラメータが、(例えば、新しいサービスを要求するために)提供および/または使用され得る。例示的な実施形態では、サービスパラメータは、以下のうちの1または複数を、すなわち、サービスのために交換されるデータの性質(例えば、「ベストエフォート」)、リンクタイプ(例えば、ProSe)、それに対するサービスが望まれ得る個人ユーザまたはユーザのグループを示す指示子、およびUEが参加することを要望または望み得る既存のサービスの一時名などのうちの1または複数を含むことができる。
本明細書で説明されるように、実施形態では、特定のユーザ識別情報などのユーザ識別情報が、(例えば、MNからAppSeへのインターフェースが存在しないことがある場合に)提供および/または使用され得る。例えば、アプリケーションサーバは、どのユーザが開始されたセッションに参加し得るかを、UE上に記憶しなければならないことがある。そのため、アプリケーションによって使用され得るユーザIDは、ネットワークによって使用され得るユーザIDに関連付けることができる。例えば、アプリケーションサーバおよびネットワークプロバイダまたはMNOは、ネットワークプロバイダによって使用され得るIDを生成すること、および/またはそれを持続的なアプリケーション識別情報に関連付けることができる。加えて、実施形態では、アプリケーションおよびモバイルネットワークの両方によって信頼され得る、サードパーティ識別情報プロバイダが使用され得る。例示的な実施形態によれば、ネットワークによって使用され得るIDとともに、またはそれに加えて、発見されたUEによって送信され得る第2のIDが存在し得る。2つのIDの間のマッピングは、例えば、一対一とすることができ、ネットワークに知られ得る。実施形態では、一時識別情報(例えば、一時サービス名)は、アプリケーション自体によって提供され得、すなわち、アプリケーションサーバは、アプリケーションプロバイダとしての役割に加えて、識別情報プロバイダの機能を引き受け得る。そのような実施形態では、オペレータネットワークとアプリケーションサーバの間で、オープンIDプロトコルが依然として順守され得る。
さらに、上で説明されたように、オープンIDプロトコルは、(例えば、MNからAppSeへのインターフェースが存在しないことがある場合に)そのような連合識別情報管理サービスをサポートし得る、プロトコルの例とすることができる。実施形態では、ネットワークプロバイダによって使用され得る識別情報は、2以上のネットワークプロバイダにわたって使用可能であるようなものであり得る。例えば、グループ内の1つのユーザは、1つのMNOによってアプリケーションサービスを提供され得、同じグループ内の別のユーザは、別のMNOによってアプリケーションサービスを提供され得、識別情報は、MNOにわたって一致され得、アプリケーションサーバにおける、単一の一意的な識別情報まで遡り得る。
例示的な実施形態では、MNOは、アプリケーションの性質を知り得ないが、アプリケーションおよび関連するサービスパラメータへのアクセスがUEによって(例えば、直接的に)要求され得るので、それのための一意識別子を知り得る。異なるアプリケーションサーバにわたって一意的なアプリケーション識別子は、以下のうちの1または複数に従って生成され得、すなわち、サービスディレクトリ内に登録されたアプリケーション名を用いて、(例えば、混同を生じる低い確率を残し得るが、アプリケーションIDが発見のために使用され得、UE IDがそれから推測され得ない場合は、そのような混同の影響は深刻ではあり得ない)長いランダム識別子を使用して、サードパーティからリアルタイムで受信および/または獲得され得るアプリケーションおよび/またはサービス識別情報(例えば、おそらくは、それがUE加入者識別情報を検証し得るのと同時に、オープンID)を用いて生成され得る。
加えて、識別子が、以下のうちの1または複数を使用して生成され得る。実施形態では、アプリケーション名は、URLアドレス、例えば、app-sub-type.app-type@company.type-of-appに類似した、標準化された方法で登録され得る。例えば、チェスアプリケーションは、以下を、すなわち、fast-chess.chess-online@chess-is-us.gamesを登録し得、これは、アプリケーションの一意的な参照または識別子とすることができる。加えて、ランダムなアプリケーション識別子が、アプリケーションによって生成され、ユーザIDに追加され得る。そのようなランダムな識別子は、アプリケーション間のユーザID衝突の確率を小さくし得、より長いユーザIDをもたらし得る。別の実施形態では、オペレータがアプリケーションプロバイダに安全に料金を請求することを可能にするために、アプリケーションは、いくつかのソースのいずれかまたは組み合わせから、暗号化されて安全な識別子を獲得し得る。これらの暗号化されて安全な識別子は、偽造または複製することが可能であり得ず、支払いの証拠として使用され得る。例えば、これらの識別子は、サードパーティビジネスエンティティ(例えば、クレジットカード会社、および支払いを示し得るID)、ならびに/またはモバイルオペレータを含むことができ、IDは、モバイルネットワークとの対話を通して、および/またはそのような対話の外で提供され得る。(例えば、MNとAppSeの間にインターフェースが存在し得ない場合であっても)UEおよびネットワークプロバイダが、新しいサービスの確立をネゴシエートし得た後、一時サービス名が、本明細書で説明されるように、サービスのために生成され得る。サービス識別情報が、本明細書で説明されるように、提供および/または使用され得る。サードパーティから受信または獲得され得るサービス識別情報は、本質的に一意であり得、したがって、ネットワークプロバイダにわたって使用され得る。加えて、他のサービス識別情報も、提供および/または使用され得、ネットワークプロバイダ内で一意であり得る。UEは、一時サービス名を認識し得、それ(および/または他のUEの他の一時サービス名)をAppSeに提供し得る。
アプリケーションプロバイダは、このサービス名を1または複数のユーザに提供し得、それらのユーザは、セッションまたは対話またはサービスに参加し得るようになる。上で説明したように、この点では、アプリケーションプロバイダの役割は、限られたものであり得る。例えば、それは、セッションが変更され得る場合(例えば、ユーザがオンラインになり、または退出して、セッションQoSが再ネゴシエートされ得る場合、セッションが終了され得る場合など)に関わらされ、または使用され得る。それとは別に、新たに生成されたサービスは、事前ネゴシエートされたQoSを用いる汎用的な「命名された」サービスとして、ネットワークによって扱われ得、ネットワークは、このサービスのための接続性管理を引き継ぎ得る。
ネットワークオペレータおよびそれのMNは、UEおよび他のネットワーク機器が従い得るポリシおよび手順において、サービス名を使用し得る。例えば、実施形態では、D2Dサービスを可能にすることで、D2Dを使用し得るフローのために、特定の組のIPアドレスがUEによって使用されるようにすることができる。そのような実施形態では、ネットワークは、特定のセッションに関連付けられた、GameNameアプリケーションなどの、アプリケーションによって開始されたフローが、D2D対応IPアドレスおよび送信元IPを使用し得ることを、UEに知らせ得る。ネットワークは、同じサービスの一部であり得る複数のUEからの情報を照合および調整することもでき、ユーザリストおよびポリシなどにおける不一致を管理し得る。
図2は、ネットワークを使用してアプリケーションによって提供されるセッションに参加することを例えば望み得るデバイスを発見するために使用され得る、サードパーティサービスアクセス方法、手順、またはプロセスの例示的な実施形態を示している。図2に示されるように、実施形態では、UEに先在するインターネットプロトコル(IP)接続性が、ネットワークによって管理され得る。例えば、202において、IPベアラが、UE201またはWTRU102a~dなどのUEと、ネットワーク203または図1A~図1Eで説明されたネットワークなどのネットワークとの間でセットアップされ得る。UEとネットワークまたはそれのネットワークプロバイダとの間の交換も、そのようなIP接続性上のアプリケーションレイヤプロトコルを使用し得る。加えて、ネットワークオペレータとサービスプロバイダの間の通信のためのプロトコルが使用され得る。そのようなプロトコルは、HTTP、HTML、XML-SOAP、および/または他の任意の適切なプロトコルなどの、1または複数の既存のプロトコルを含むことができる。本明細書で説明されるように、ネットワークとアプリケーションサーバの間の対話を含む、交換のコンテキストが定義され得る。
図2に示されるように、UEは、その後、アプリケーションサーバ205などのアプリケーションサーバ、およびそれのサービスプロバイダと交信し得る。例えば、実施形態では、204において、UEは、対話型ゲームのセッションを開始すること、またはそれに参加することを求める要求をアプリケーションサーバに送信し得る。要求は、UEが利用可能であり得、UEがアプリケーションサーバによって提供されるセッションまたはサービスに参加することを望んでいることを示す表示をアプリケーションサーバに提供すること、またはそれを含むことができる。要求は、UE、および/またはそれが参加することを望み得るサービスもしくはセッションについての適切な情報も提供し得る。例えば、要求内のサービスプロバイダが利用可能な情報は、UEによって使用され得るネットワークオペレータを含むことができる。実施形態では、要求を受信した後、サービスプロバイダまたはアプリケーションサーバのアプリケーションプロバイダは、それがネットワークおよびネットワークオペレータ(例えば、MNO)との関係を有し得るかどうかを検証し得、関係が存在し得る場合は、サービスがサポートされ、要求が果たされるようになり得る。そのような検証を実行するために、サービスまたはアプリケーションプロバイダは、204において受信された要求内の情報に照らして、それが関係を有し得るオペレータのリストをチェックし得、情報がリスト内のオペレータと一致する場合、これを1つのそのようなオペレータとして識別し得る。別の実施形態では、関係が存在し得ない場合であっても、サービスがサポートされ得、D2Dなどのオプションを通してサポートされる拡張QoSが、ネットワークオペレータとサービスプロバイダの間の協調を提供または可能にするために使用され得る。
本明細書で説明されるように、206において、サービス開始およびネゴシエーション手順が、(例えば、MNからAppSeへのインターフェースが存在し得る場合に)実行され得る。例えば、実施形態では、サービスプロバイダが、UEを、ゲームセッションなどのセッション、対話、またはサービスに参加する、ネットワークプロバイダからの最初のUEとして識別し得る場合、サービスプロバイダは、208において、ネットワークのユーザのための新しいサービスを開始または始動するために、ネットワークに要求を送信し得る。例えば、204においてアプリケーションサーバによって受信され得る、セッションに参加することを求めるUEの要求に応答して、セッションが開始され得ていない場合は、UEは、208において、新しいサービスを開始するようにプロバイダに要求し得る。
その後、210において、ネットワークとサービスプロバイダの間のサービスネゴシエーションが後続し得る。サービスネゴシエーションにおいて、セッションおよび/またはサービスのためのパラメータが、アプリケーションサーバとネットワークの間で交換され得る。加えて、アプリケーションサーバは、(例えば、204において)要求がそこから受信され得たUEがどのようにセッションまたはサービスに加えられ得るかを、ネットワークに知らせること、または伝えることができる。例示的な実施形態では、サービスネゴシエーションは、以下のサービスパラメータのうちの1または複数についての合意を確立または生成することを含むことができ、サービスパラメータは、サービス名(例えば、一時サービス名)、ユーザおよび/もしくはUE識別情報、サービスに関連付けられたデータ通信に対する適切な請求および/もしくは課金のために使用され得る請求および/もしくは課金参照番号、サービスセキュリティパラメータ(例えば、データの保護および認証などがどの程度行われ得なければならないか)、特定のネットワーク接続性要件、例えば、D2D使用:<必須;好ましい;優先されない;可能な場合は避ける;禁止>、WLAN使用:<必須;好ましい;優先されない;可能な場合は避ける;禁止>などを含むサービスQoS要件、大域的、事前定義されたエリアに限定的、ネットワークサブセット、およびサービスが開始され得る特定のアクセスエリアに限定的などの、ローカライゼーションパラメータ、サービス開始時間および終了時間(例えば、サービスがアクティブであり得る、および/もしくは失効せずに未使用であり続け得る期間)などの、時間制限、ならびに/または他の任意の適切なパラメータである。
例示的な実施形態によれば、アプリケーションサーバまたはそれのプロバイダによって提供されるサービスのためのセッションがすでに開始され得ている(例えば、UEがセッションをすでに開始し得ている)場合、210におけるサービスネゴシエーションは、セッションに参加することを要望し得る後続のUEのために、再び実行されることを必要としなくてよい。代わりに、後続のUEは、上で説明したように、204において、セッションへの参加を求める要求をアプリケーションサーバに送信し得、アプリケーションサーバは、サービスネゴシエーションを実行する代わりに、後続のUEがセッションに参加する権限を与えられているかどうかを判定し得る。
サービスネゴシエーションを実行した後、および/またはサービスネゴシエーションの最中に、212において、サービス名が生成され、ネットワークからアプリケーションサーバに送信され得る。実施形態では、サービスの命名は、一意的であり得る。加えて、実施形態では、サービス名は、本明細書で説明されるように、ユーザ名、もしくはアプリケーションサーバによって提供されるアプリケーションに関連付けられた証明書とは独立であり得、ならびに/またはUEおよび/もしくはネットワークに関連付けられたネットワーク識別子とは独立であり得る。例えば、ネットワークおよび/またはアプリケーションサーバは、アプリケーションサーバにログオンするユーザ、またはネットワークにアクセスするUEによって使用される実際の証明書を交換することなく、サービス名を使用して、セッションまたはサービスを開始し得る。
例えば、選択された名前は、ネットワークオペレータおよびアプリケーションプロバイダを用いる、アクティブであり得る(または最近アクティブであり得た)多数の他のサービスに対して、一意的であり得る。加えて、実施形態では、名前内のソーシャルネットワーク要素、サービスを生じさせるアプリケーション、およびユーザグループなどの識別も、提供または使用され得る。例えば、新しいGameNameゲームセッションが、ユーザのグループ(例えば、CompName+circle、サークルのメンバがプレーヤであり得る)に関連付けられ得ると仮定する。結果のセッションは、CompName.GameName.CompNameGroupXYZ.Application_abcと命名され得、ここで、CompNameは、サービスを提供するソーシャルネットワークサービスの名前とすることができ、GameNameは、Proximityサービスのための一意名とすることができ、CompNameGroupXYZは、閉鎖的なユーザアクセスグループを表すCompName+circleの名前とすることができ、Application_abcは、アプリケーションセッションの名前とすることができる。実施形態では、「Application_abc」は、ランダムに生成された文字列を表し得る。そのようなランダムに生成された文字列は、セッション名の一意性を、これらが生成および破棄されるときに保証するために使用され得る。ランダムに生成された文字列も、衝突の可能性が十分に低くなり得るように、十分に長くすることができる。あるいは、サービス(例えば、アプリケーション)プロバイダとネットワークプロバイダの間の一意的な識別子(例えば、「ServiceNetID」)は、長期的な関係の一部として、ネットワークとアプリケーションサーバの間でネゴシエートされ得る。加えて、調整された一時セッションが、(例えば、衝突を回避するのに十分な長さであり得る識別子を生成するために)ランダムに生成された文字列をそのようなセッションのための識別子に追加することによって識別され得、および/または十分に増大することを可能にされ得たシーケンス番号が、定められた期間内の繰り返しを回避するために使用され得る。加えて、意味のある一意的なサービス名および/または識別子を保証する他の代替策も使用され得る。本明細書で(例えば、以下で)説明されるように、特定のサービスセッションを識別するために一意名が生成され得る限り、(例えば、形式における特定性のために記述のコンパクト性を犠牲にした)上記のものの1または複数の適切な変形も使用され得る。
実施形態では、一時サービス名およびそれのレジストリが、各名前がアプリケーションにわたって一意的であり得ることを保証するために構成され得る。例えば、上で説明されたように、例えば、A.B@C.Dなどのアドレス形式を指定することによって、URL規約または形式を使用して、名前が構成され得る。そのような実施形態では、「D」は、「.game」、「.date」、「.meet」、または「.machine」など、アプリケーションのタイプを示すトップドメイン名とすることができる。これらは、固定された意味を有するように業界によって合意され得、または恣意的とすることができる。「C」は、会社によって使用されるドメイン名とすることができ、すなわち、会社は、(まだ使用され得ていない)任意の名前を使用することを決定し、それを登録し得る。ひとたび登録されると、名前は、別のアプリケーションによって使用され得ない。加えて、オプションとすることができる「A」および「B」は、アプリケーションに固有とすることができ、登録されることを必要としなくてよく、「サブ」タイプを定義するために使用され得る。加えて、(http://xxx.xx/zhtjk)などの短いURL形式は、アプリケーション(CompName.GameName.CompNameCirclexyz.Application_abc)のための短いURLとすることができる。そのような短いURLは、ドメイン内に登録され得、与えられたドメイン内で、局所的に、動作の範囲内で、および/または大域的に、一意的とすることができる。実施形態では、そのような一意性は、すでに割り当てられた、アプリケーションの記憶された識別情報をチェックすることによって、可能にされ得る。変形として、一意性は、暗号化によって可能にされ得、アプリケーション識別情報は、部分的に、
RandomAppId=KDF(固定されたシード,「CompName.GameName.CompNameCirclexyz.Application_abc」)
Appld=CompName.GameName.RandomAppId
を使用して、導出され得る。
サービス名を生成した後、214において、UEサービスアクセスが、ネットワークとアプリケーションサーバの間で交換され得、216において、サービス名および他の識別子が、アプリケーションサーバからUEに送信され得、UEは、サービス名を使用してセッションに参加し得るようになる(例えば、UEは、特定のユーザとの特定のセッションのための識別子を与えられ得る)。本明細書で説明されるように、D2Dでは、UEは、それが特定のサービス名または識別子を有する特定のセッション内にあり得ること、およびそれが他のUEから利用可能であり得ることを、ネットワーク上の他のUEにさらに広告し得る。加えて、サービスのためのセッションに参加することを望み得る後続のUEが、そうする権限を与えられ得る場合、それらの後続のUEがサービスのためのセッションに参加し得るように、それらの後続のUEは、216において、サービス名を提供され得る(例えば、サービス名が、216において、それらのUEに送信され得る)。
例えば、サービス名がひとたび定義され得ると(またはそれがすでに存在し得る場合)、サービスプロバイダおよびネットワークプロバイダは、214において、任意の適切なプロトコルを使用して、サービスへのUEのアクセスをネゴシエートし得る。アクセス制御および/または認可が提供され得るような他の手法となり得る、オープンIDまたは(例えば、3GPPにおける)汎用ブートストラップアーキテクチャ(GBA)などの、シングルサインオンソリューションがさらに使用され得る。そのようなプロセスが完了し得た後、または完了し得た場合、サービスプロバイダは、216において、所望のサービスセッションに対応し得るネットワークサービス名を用いて、UEに応答し得る。
その後、UEとモバイルネットワークは、(例えば、218において)サービス名および関連するパラメータを使用して、特定のサービスのための通信を管理し得る。実施形態では(例えば、サービス名および関連するパラメータを使用して、特定のサービスのための通信を管理するために)、拡張アクセスネットワーク発見および選択機能(ANDSF)およびそれの概念が使用され得る。ANDSFは、ネットワークが、通信のためにどのアクセスネットワークを使用すべきかをUEに知らせ得る、ポリシフレームワークとすることができる。例えば、ANDSFは、システム間ルーティングポリシ(ISRP)を提供し得る。ANDSF内にすでに存在し得るISRPおよびそれの概念は、ポリシが特定のIPの5タプルに関連付けられ得るという意味で、そのような仕様が、IPフロー固有であることを可能にし得、または許可し得る。そのようなANDSFおよび/またはISRPならびにそれらの概念は、ポリシがアプリケーション名および送信先ドメイン名などによって指定されることを可能にし得、または許可し得る。したがって、例えば、新しい調整されたサービスが定義され得る場合、ANDSFポリシの更新が、そのようなサービスを使用し得るUEに提供され得る。実施形態では、更新は、UEが、例えば、名前または送信先ドメインによって関連するアプリケーションを識別することを要求し得、または必要とし得、適切なポリシをIPフローに適用し得る。そのような実施形態では、アプリケーションは、提供されるアプリケーションサービスのためにユーザによって使用されるアプリケーションとすることができる。加えて、ポリシは、ネットワークによってネゴシエートされたような、サービスに関連するQoS仕様を反映し得る。UEへのポリシの提供は、UEが特定のサービス名についてのポリシ更新を要求し得るプル方法によって、またはネットワークが更新をそれを使用し得る1組のUEにプッシュし得るプッシュ方法によって行われ得る。実施形態では、特定のサービスを使用し得ないUEは、特定のサービスに関連するポリシを単に無視し得る。
加えて、本明細書で説明されるように、MNからAppSeへのインターフェースが存在し得ない場合の、サービスネゴシエーション(例えば、210)が提供および/または使用され得る。例えば、ネットワークとアプリケーションプロバイダの間に正式なビジネス協定が存在し得ない、または提供され得ない、実施形態では、UEは、アプリケーションとのサービスネゴシエーションを実行し得、サービス名、ユーザ識別情報、QoS、および時間制約などを含む、初期の1組のサービスパラメータに合意し得る。UEは、その後、これらのネゴシエートされたパラメータをネットワークに提供し得る。サービス名から、ネットワークは、UEが新しいサービスを開始しようとしているのか、それとも既存のサービスに参加しようとしているのかを認識または判定し得る。ネットワークは、その後、ポリシを用いて、および(例えば、既存のサービスの場合は)既存の1組のサービスパラメータも用いて、UEによって提供され得るサービス機能(例えば、要件)を調停し得る。例示的な実施形態によれば、ネットワークは、サービスのためのアクセスパラメータの最終決定者とすることができ、それをUEに提供し得る。UEは、その後、サービスパラメータの変更について、アプリケーションサーバに通知し得る。例えば、UEを通して、サービスパラメータをネットワークとネゴシエートするアプリケーションの能力は、サービスパラメータを求めるUEから出された要求に対するネットワークのサポートに依存し得る。
本明細書で説明されるように、ポリシ管理も提供および/または使用され得る。本明細書で使用され得るポリシプルプロセスまたは方法の例が、図3に示され得る。実施形態では、図3は、図2が停止または終了したところで(例えば、216においてサービス名を含むアプリケーションサーバからUEへの応答があったときに、および/または218においてネットワークサービスアクセスが管理され得るときに)開始し得る。図3に示されるように、UE201などのUEは、アプリケーション207などの(例えば、プロセスとして動作している)アプリケーション、およびCM209などの接続マネージャ(CM)を含むことができる。
CMは、UEの通信上の必要または要望を自動化および管理するように設計された、一般に使用されるエンティティとすることができる。例えば、CMは、通信のためのエアインターフェース(例えば、セルラまたはWiFi)を選択するために使用され得る。それは、サインオンプロセスを自動化するため、エアインターフェース品質測定値を収集するため、および他のタスクのためにも使用され得る。そのため、CMは、ANDSFクライアントなどのポリシクライアントのための自然なロケーションであり得、ポリシクライアントは、そこに配置され得る。
したがって、UE上のアプリケーションが、(例えば、216において)調整されたサービスの名前をアプリケーションサーバから受信し得る場合、アプリケーションは、220において、名前をCMに通知(例えば、登録)し得る。CMは、222において、そのようなサービス名に関連付けられた、制約、許容、およびパラメータなど(例えば、本明細書で説明される、特定のフローについての制約など)といったポリシを現在有し得るかどうかをチェック(例えば、判定)し得る。(例えば、新しい調整されたサービスの場合がそうであるように)CMがポリシを有し得ない場合、それは、224において、アプリケーションサーバと(またはネットワークとさえも)交信して、与えられたサービスのためのポリシを要求し得る。上で説明されたように、ポリシを送信および符号化するためのプロトコルとして、ANDSFが使用され得、CMは、ANDSFポリシのための実施ポイントとすることができる。アプリケーションサーバは、226において、CMが記憶するように、(例えば、それとアプリケーションサーバとの先行する対話に基づいて)適切なポリシを返し得る(例えば、送信し得る)。アプリケーションは、その後、228において、開始され得る。(例えば、後の時点で)アプリケーションが、(例えば、一般にはソケットインターフェースを介して)そのようなサービスに関連付けられたIPフローをオープンし得た場合、CMは、230において、そのようなフローを検出し得、適切なポリシを適用し得る。フロー検出は、フローおよび/またはサブフローを検出し得る数々の異なる方法または技法を介して実行され得、適切なポリシは、検出されたフロー、または帯域幅、フローの特性、および検出レベルなどの他のパラメータに基づき得る、任意の適切な基準またはポリシを含むことができる。
図4は、ポリシが、例えば、(例えば、多数のUEへの)ブロードキャストを介して、またはUEへの直接的なプッシュを介して、サーバからUEにプッシュされ得る、方法または手順の例示的な実施形態を示している。方法または手順は、CMがポリシ更新をアプリケーションサーバに要求し得ないことを除いて、(例えば、図3に示された)プル方法または手順と同様とすることができる。代わりに、CMは、232において、アプリケーションサーバからのポリシのプッシュを受信し得る。ポリシのプッシュを受信すると、それ(例えば、CM)は、234において、ポリシ更新を記憶し得る。それを行う際、CMは、例えば、それが認識し得るサービスのためのポリシを記憶するなど、フィルタを適用し得る。したがって、そのような実施形態では、アプリケーションは、(例えば、必要とされる場合)サービス固有のポリシが存在し得ることを保証するために、依然としてサービスをCMに事前登録し得る。
セキュリティに対する考慮も、本明細書で説明されるように、提供および/または使用され得る。例えば、アプリケーション(および/またはAppSe)とネットワークの間の(ならびにそれとは逆方向の)通信は、(例えば、少なくとも)インテグリティ保護を、および/または(例えば、任意選択で)暗号化を施され得る。加えて、ユーザおよび/または加入者と、シグナリングおよび制御に関し得るアプリケーションとの間で発生し得る通信は、TLSまたは何らかの形式のアプリケーションレベル保護を介して保護され得る。実施形態では(例えば、任意選択で)、通信は、中間者攻撃、なりすまし攻撃、および仮装攻撃を抑制するために、TLSなどのチャネルに結び付けられ得る。
ユーザおよび/または加入者は、(例えば、任意選択で)明示的または暗黙的に認可を提供するように構成され得る。暗黙的な認可は、セッション鍵またはシグナリング鍵の所有を証明することを介して提供され得、一方、明示的な認可は、何らかのパスワード/PIN/パスフレーズのユーザ入力、および生体認証または精神的/心理的特徴といったユーザの特徴を介するなどして提供され得る。
実施形態では、プライバシに対する考慮が提供および/または使用され得る。例えば、提供および/または考察され得る通信の別の態様は、UE、ユーザ識別情報、およびサービスプライバシなどのプライバシとすることができる。実施形態によれば、ユーザは、その識別情報、ロケーション、物理的近接性、サービス利用可能性、および他のユーザからのニーズまたは要求についてのプライバシを維持することを望み得、または要望し得る。アクセスレイヤにおいて広告され得るサービスが、サービスプロバイダサービスに容易に関連付けられ、または結び付けられ得る場合、UEは、それが秘密にしておきたいことがある情報を、アクセスレイヤにおいて不注意に広告することがあり得る。例えば、ユーザは、その存在を他から秘密にしておきたいことがある。同時に、UE識別情報も、他のUEから秘密にしておき得る。例えば、UEは、「友人」が近くに存在し得る場合、最初に相談されることなく、他のUEによって発見されることを望まない、または要望しないことがある。そのため、UEは、その近くのCompName+circleなどの友人サークルに伝達することを望むとき、または要望するときまで、存在情報を秘密にしておくことを望み得、または要望し得る。したがって、情報を難読化した識別情報が、アプリケーションサーバに伝達され得、アプリケーションサーバは、識別情報を特定のUEに関連付けることができ、UEのプライバシ設定を維持し得る。
プライバシに対処する1つの方法は、一意性およびプライバシを保証し得る、サービスまたはUE識別情報のためのランダム識別子を使用することとすることができる。例えば、一意的なランダム識別子は、提供され得るリストからのランダム選択、アプリケーションサービス名もしくはUE識別情報の暗号学的ハッシュ、および/または他の任意の適切な方法を含む様々な方法で生成され得る。識別情報をさらに難読化するために、識別情報は、頻繁に交換または更新され得、通信のロギングおよび長期観察を通した識別を防止する。そのような実施形態のいずれでも、名前は、一時的であり得、および/またはリアルタイムで動的に定義され得る、一意的なサービス名またはUE識別情報を含むことができる。
サービス広告の間、プライバシを維持する1つの手段として、一時サービス名が使用および循環され得、実際のサービス名は、やはり同じサービスに加入している他のUEによる以外は、発見可能ではない。例えば、サービス名(例えば、CompName.GameName.CompNameGroupXYZ.Application_abc)は、秘密の名前として使用され得、または秘密の「マスタサービス鍵」文字列が、それに追加され得、もしくはこのサービスのために別に送信され得る。各UEは、そのような文字列を受信し得、セキュアハッシュなどの安全な導出方法を使用して、一時サービス広告を導出し得る。そのような一時サービス広告は、UE(および同じサービスに加入する他のUE)によってブロードキャストされ得る。やはりこのサービスの加入者であり得る別のUEは、広告された文字列を自らの広告される文字列と照合することによって、実際のサービス名を推測でき得る。しかしながら、サービスに加入していないUEは、実際のサービス名を導出でき得ない。
セキュリティをさらに改善するため、一時ブロードキャストサービス名は、例えば、一時ブロードキャストサービス名を「リフレッシュ」するために、時間またはアプリケーションサーバによってブロードキャストされたノンスを強力な秘密と一緒にハッシュすることによって、時々、新しいサービス名に変更され得る。サービスに加入しているUEは、ブロードキャストされた文字列をローカルに導出でき得る文字列と照合することによって、複数の異なる一時サービス名を同じ基礎となるサービスと関連付けることができ得るが、サービスに加入しておらず、「マスタサービス鍵」を所有していないUEは、そのようにすることができ得ず、すなわち、2つの一時サービス名を同じサービスに関連付けることができ得ず、したがって、プライバシを提供する。
一時識別情報(例えば、サービス名もしくは一時サービス名、および/または一時UE識別情報)を導出するためのシステムおよび/または方法(例えば、メカニズム)が、提供および/または使用され得、それは、例えば、KDF(鍵,文字列)の形式の鍵導出関数に基づき得る。鍵は、UEとネットワークの間で共有される秘密とすることができるが、文字列は、鍵導出関数(KDF)が使用され得るコンテキストを表し得る。文字列は、UEの識別情報(例えば、永続的な識別情報)(例えば、IMSI)、およびネゴシエーションまたは認証の間に使用され得たランダム変数などを含むことができる(例えば、少なくとも、それらで作成され得る)。加えて、文字列は、「ProSe」など、使用(または利用)のコンテキストを記述し得るパラメータを含むことができる(例えば、それらで作成され得る)。
例示的な実施形態では、KDFは、UETemp=HMAC-SHA256(KeyN,IMSI|NonceMNO|UTF-8encoding(“ProSe”))の形式を取り得、導出される一時的な値または識別情報は、KDFの出力の先頭の32ビットとすることができる。KeyNは、UEとMNO/オペレータまたはProSeサーバとの間で共有される秘密とすることができる。IMSIは、UEの識別情報とすることができる。T-IMSI、B-TIDなど、他の導出される、または永続的な識別情報も、IMSIの代わりに使用され得る。NonceMNOは、MNOによって生成され得るランダム値とすることができ、またはUE(NonceUE)もしくは両方が使用され得、様々な長さを有するが、良好なランダム特性を有する。「ProSe」などの形の文字列は、UETempを導出するために、任意選択で使用され得る。UETempは、他のパラメータを使用することなく、NonceおよびKeyNなど、2つのパラメータのみを使用することによって導出され得る。実施形態では、NonceMNOまたはNonceUEが、UE一時識別情報生成プロセスのためのパラメータとして使用され得る。加えて、一時識別情報のサイズは、様々であり得(例えば、実装に委ねることができ)、一時識別情報の一意性を保証するのに適した長さとすることができる。その後、UEのために導出される一時識別情報は、UEtempID=(Temp)base64@prose.MNO.comの形式を取り得る。
同様に、加入者/ユーザのための一時アプリケーション識別情報は、以下のように導出され得、UserTemp=KDF(KA,Nonce,UTF-8encoding(UserIdentity|“CompName.GameName.CompNameGroupXYZ.Application_abc”))、それから導出される一時ユーザ/加入者識別情報は、USERTempID=(USERTemp)base64@applicationabc.CompNameGroupXYZ.GameName.CompName.comの形式、またはhttp/applicationabc.CompNameGroupXYZ.GameName.CompName.com/(USERTemp)base64の形式を取り得る。KAは、UEとアプリケーションの間で共有される秘密とすることができる。Nonceは、NonceAPPもしくはNonceUser、またはNonceUserとNonceAPPの両方の組み合わせとすることができる。NonceAPPは、アプリケーションによって生成されるランダム値とすることができる。Userldentityは、そのアプリケーションに関連付けられたユーザの識別情報とすることができる。アプリケーション名も、UserTempを導出するためのパラメータとして含まれ得る。ユーザによって生成されるNonceUserも、UserTemp生成プロセスの一部として、任意選択で含まれ得る。Userldentityおよびアプリケーション名(CompName.GameName.CompNameCirclexyz.Application_abc)は、任意選択パラメータとすることができる。実施形態では、NonceUserまたはNonceAPPが、一時識別情報生成プロセスの一部として含まれ得る。NonceUserおよびNonceAppはともに、一時識別情報生成プロセスの一部として含まれ得る。別の実施形態では、UserTempIDおよびUETempIDは、(日付および時刻などの)時間成分を周期的に使用して、UEとネットワークまたはアプリケーションの両方によって自己生成され得る。周期性は、登録プロセスの間に合意され得る。これは、UEとネットワークまたはアプリケーションの両方が、エンティティ間でNonceを伝達する必要性を回避し、したがって、リソースを節約し、待ち時間を改善する。あるいは、Nonceは、一時識別情報の初期生成の間に使用され得、その後は、一時識別情報は、Nonceを伝達することなく、時間成分を使用して、各エンティティにおいて生成され、またはNonceは、より低い頻度で使用され得、一方、時間成分は、より高い頻度で使用され得る。例示的な実施形態は、以下のようにすることができ、すなわち、一時識別情報は、毎日、Nonceおよび/または時間成分を用いて生成され得、その後は、一時識別情報は、1時間おきに、時間成分のみを使用して、エンティティの各々において生成され得る。新しいNonceが、翌日に生成され得、そのNonceおよび時間成分に基づいた新しい一時識別情報が、翌日、1時間おきに生成される。類似の実施形態および/または本明細書で説明される実施形態の変形も使用され得る。
例示的な実施形態では、一時識別情報は、ネットワークとアプリケーションの間の通信のために使用され得る。アプリケーションは、ネットワークとの通信のために、USERtempIDを使用し得、一方、ネットワークは、アプリケーションと通信するために、UEtempIDを使用し得る。UEtempIDは、D2DまたはProximityサービス(ProSe)のために他のUEに広告し、または他のUEを発見するために、IMSIの代わりに、UEの識別情報として、UEによって使用され得る。アプリケーションおよびネットワークは、その後、2つの一時識別情報のマッピングを実行し得る。あるいは、一時識別情報は、暗号学的な方法(例えば、TempID(domain2)=KDF(Key,TempID(domain1)))で、2つのドメイン(例えば、アプリケーションとネットワーク)を結び付け得る、一意的な一時識別情報を導出するための入力として使用され得る(例えば、それは、これらの一時識別情報を広告し得るUEの間の無線通信のために使用され得る)。
実施形態によれば、ProSe識別情報サービス機能(PISF)は、一時識別情報生成およびマッピングのためのサービスを提供し得る。これらのサービスは、MNOに結び付けられ得、またはサードパーティサービスとして提供され得る。ProSe一時Id(ProSeID)は、そのようなサービスのために生成され得、またはPISFがMNO内に配置され得る場合、UETempIDはその後、ProSeIDとして使用され得る。UEは、ProSeIDをPISFに要求し得、またはあるいは、ProSeIDは、PISFによってUEにプッシュされ得る。
プライバシ要件に基づいて、ProSe識別情報は、関連する存続期間を有する一時識別情報とすることができる。新しいProSeIDが、古いProSeIDに関連する存続期間の満了前に、再生成されなければならないことがある。古いProSeIDと新しいProSeIDは、限られた時間の間にマッピングされ得、そのため、発見プロセスの間に、同期問題は存在し得ない。プル手法またはプッシュ手法を使用して、UEは、新しいProSeIDを要求し、または新しいProSeIDをプッシュされる。
図5は、ProSe識別情報機能の例示的な実施形態を示している。図5に示されるように、メッセージ1aでは、UE1は、ProSeIDを要求し得、PISFは、メッセージ1bに示されるように、新たに生成されたProSeIDを送信し得る。あるいは、PISFは、ProSeIDの存続期間の満了前に、新しいProSeIDを生成し得、要求メッセージ1aを受信することなく、メッセージ1bを使用して、新しいProSeIDをUEに送信し得る。実施形態は、PISFが、一時ProSeIDの生成のために必要とされるシード材料を生成し、メッセージ2aに示されるように、シード材料のみをUEに送信することを可能にする。NonceProSeが、要求に応答して、PISFによって送信され得、またはUEにプッシュされ得、その後、それは、ProSeIDを生成するために、UEおよびPISFによって使用され得、ProSeID=(KeyProSe,NonceProSe)であり、ここで、KeyProSeは、UEとPISFの間で共有される秘密とすることができる。あるいは、UEが、ProSeIDを生成するためのシード材料をPISFに送信し得、または各エンドで生成され得るUEおよびPISFの両方からのシード材料が、互いに伝達され、その後、ProSeIDを生成するために、両方のエンティティによって使用され得る。あるいは、ProSeIDは、(日付および時刻などの)時間成分を周期的に使用して、UEとPISFの両方によって自己生成され得る。周期性は、登録プロセスの間に合意され得る。これは、UEとPISFの両方が、エンティティ間でNonceを伝達することを回避し、したがって、リソースを節約し、待ち時間を改善することができるようにできる。あるいは、Nonceは、ProSeIDの初期生成の間に使用され得、その後は、一時識別情報は、Nonceを伝達することなく、時間成分を使用して、UEおよびPISFにおいて生成され得、またはNonceは、より低い頻度で使用され得、一方、時間成分は、より高い頻度で使用され得る。例示的な実施形態は、以下のようにすることができ、すなわち、ProSeIDは、毎日、朝6時に、Nonceおよび/または時間成分によって生成され得、その後は、ProSeIDは、1時間おきに、時間成分のみを使用して、エンティティの各々において生成され得る。新しいNonceが、翌日に生成され得、そのNonceに基づいた新しいProSeIDが、生成され得、その後、時間成分のみを使用して、ProSeIDが、1時間おきに生成される。類似の実施形態もしくは変形、または本明細書で説明される実施形態もしくは変形の組み合わせも使用され得る。
ProSe発見および/または広告メッセージ3bは、UE1のProSeID(ProSeID_1)を搬送し得、同様に、UE2は、メッセージ3aで、そのProSe識別情報としてProSeID_2を広告し得る。ProSe識別情報の搬送に加えて、各発見および/または広告メッセージは、任意選択で、ProSe識別情報に関連付けられるサービスクラス(CS)も搬送し得る。加えて、UEは、2以上のProSeIDに関連付けることができ、各ProSeIDは、アプリケーションまたはサービスのクラスに関連付けることができる。ゲームは、サービスクラスの一例とすることができ、同様に、ソーシャルネットワークは、異なるセキュリティおよびプライバシ要件も有し得る、サービスクラスとすることができる。UEは、ゲームのためのProSeID、およびソーシャルネットワークのための別のProSeIDを有し得る。
PISFは、発見機能も実施し得、それは、ProSeIDの適切なアプリケーションおよびそれぞれの一時アプリケーション識別情報へのマッピングを支援する。PISFは、(例えば、CompName.GameName.CompNamexyz.Application_abc.UserTempID1をProSeID1にマッピングするなど)複数のアプリケーションを同じだが一意的なProSeIDにマッピングするマネージャとして機能し得る。加えて、PISFは、発見および接続機能を用いて、共通のProSe接続性に関心を有する2つのユーザを接続するエンティティとして機能し得る。PISFは、ProSeユーザのためにフィルタリングおよびデータ収集も実行し得、そのような情報をアプリケーションサーバに報告し得る。PISFは、各UEによって発見されたProSeIDのデータベースも維持し得、プライバシ保護を提供するために、ProSeIDリフレッシュ機能も提供する。また、PISFは、発見データをフィルタリングする場合などに、古いProSeIDと新しいProSeIDの結び付けを可能にし得る。実施形態では、PISFは、その機能のいくつか(例えば、CompName.GameName.CompNamexyz.Application_abc.UserTempID1など、アプリケーションサーバ名のレベルにおけるフィルタリング)をUEに委任し得る。PISFは、UEの一時ProSeIDを、ユーザが契約した一時アプリケーション識別情報にマッピングする、識別情報マッピングテーブルを使用し得る。図5に示されるように、マッピングテーブルは、関連するProSeID_1を有するUE1の、関連するアプリケーション一時識別情報UserTempID1_App1およびUserTempID2_App3との対応付けを含むことができる。同様に、ProSeID_2を有するUE2は、アプリケーション識別情報UserTempID2_App1およびUserTempID1_App2に関連付けることができる。観察され得るように、UE1およびUE2はともに、アプリケーションApp1との関連付けを有する。ProSeID_1に関連付けられ得るUE1は、UE2のProSeID(ProSeID_2)と、任意選択で、サービスクラス(CoS)表示とを含む、ProSe発見メッセージ、メッセージ3aをUE2から受信し得る。同様に、UE2は、UEのProSeID_2と、任意選択で、CoS表示とを含む、発見および/または広告メッセージをUE1から受信し得る。UEは、受信された発見および/または広告メッセージに対して何らかの形のフィルタリングを実行し得、加えて、検出された各ProSeIDについての測定値を検出および収集し、定期的に、またはある時間間隔で、スキャンの実行および検出を行い得、フォールスアラームならびに偽のトリガおよび過渡条件を回避するために、発見データをフィルタリングする。例えば、特定のProSeIDが、x回の連続的なスキャンにおいて発見され得る場合、それが検出されたと見なされ得る。同様に、検出の喪失および報告のため、検出され得るものの変化が、通信帯域幅を制限するために、PISF機能に送信され得る(例えば、新しいProSeIDが発見され得た、または失われ得た場合、情報がPISFに送信され得る)。
実施形態では、発見メッセージの受信に続いて、UE1は、アプリケーション識別情報と、UE2と通信するために起動するアプリケーションとを発見するために、アプリケーション発見要求メッセージ4aをPISFの発見機能に送信し得る。メッセージ4aは、ProSeID_2を含むことができ、UE1がUE2から受信した関連するCoSも有することができる。UE2がUE1から受信し得たProSeID_1と、関連するCoSも含む、UE2からの同様の要求が、メッセージ4bで、PISFの発見機能に送信され得る。メッセージ4aまたは4bのどちらかを受信すれば十分であり得るが、PISFは、アプリケーション発見要求メッセージをUEの一方から受信する代わりに、関与する両方のパーティからそれを受信した場合、より高い程度の確かさで、要求について検証でき得る。発見機能は、その後、Idマッピングテーブルのテーブル検索に基づいて、UE1とUE2の両方が、互いにProSeサービスを要求していることを推測し得る。メッセージ4cは、UE1およびUE2の両方のアプリケーション識別情報を獲得するために、発見機能によって使用され得、それらのProSeIDと、任意選択で、UEの各々に関連付けられたCoSも送信され得る。メッセージ4cの結果として(例えば、それに応答して)、検索が実行され得、両方のUEのProSeIDが、それらが加入しているアプリケーションと比較され得、任意選択で、それらが属するCoSを比較し得る。両方のUEが、同じアプリケーションまたはアプリケーションクラスもしくはサービスクラスに関連付けられ、またはそれらに加入し得ている場合、それぞれのアプリケーション識別情報が獲得され得る。発見機能は、また、UE1とUE2がともにApp1に加入し得ていることを発見し得る。発見機能は、メッセージ4dを使用して、UserTempID2_App1をUE1に送信し得、メッセージ4eを使用して、UserTempID1_App1をUE2に送信し得る。あるいは、PISFは、UserTempID1_App1とUserTempID2_App1の間のサービスを開始するために、メッセージ4hを使用して、App1と直接的に通信し得る。メッセージ4dおよび4eは、任意選択とすることができ、メッセージ4hは、実施され得る。あるいは、メッセージ4fが実施され得、その後、App1は、アプリケーション識別情報UserTempID2_App1を使用するUE2とのメッセージ4iを使用して、サービスおよび認可要求を開始し得る。あるいは、メッセージ4gが実施され得、その場合、App1は、アプリケーション識別情報UserTempID1_App1を使用するUE1へのメッセージ4iを使用して、サービスおよび認可要求を開始する。あるいは、メッセージ4d、4e、4f、および4gは、スキップされ得、メッセージ4gのみが、PISF/発見機能によって送信され得る。App1は、その後、メッセージ4iを使用して、認可要求を両方のUEに送信することによって、UEのアプリケーション識別情報を使用して、2つのUEの間のサービスを開始し得る。あるいは、ProSeIDが一対多アプリケーションIdマッピングであり得るために、PISFが正しいアプリケーションを発見でき得ない場合、PISFは、UEが使用したいアプリケーションを決定するために、両方のUEが加入しているアプリケーションを尋ねる要求をUEに送信し得る。PISFは、また、UE1とUE2の両方に共通し得るすべてのアプリケーションを起動し得、アプリケーションの各々にUEの関連するアプリケーション識別情報を提供し得る。メッセージ4dおよび4eの一部として、UE1およびUE2は、誰が接続するかを選択するためにUEによって使用され得る、ターゲットUEの複数のアプリケーション識別情報を受信し得る。PISFは、それぞれのアプリケーションとの合意に基づいて、UEが選択し得るアプリケーションに優先順位を付け得る。
実施形態によれば、UEは、アクティブな発見シナリオにおいて、追跡および発見の回数、ひいては、UEリソースへの影響が減少し得るように、関心がある他のUEまたはユーザ/加入者の一時識別情報のリストを維持し得る。同様に、ネットワークは、関心があり得るUEについての情報をアプリケーションに伝達し得、または統合された方法で伝達し得、それによって、ネットワーク上の負荷を低減する。
加えて、各UEは、各UEが完全に異なる一時サービス名をブロードキャストし得るように、自らの(IMSIまたは他の識別子などの)UE識別子情報をブロードキャストサービス名に含めることができ得る。同じサービスに属する他のUEは、他のUEの知られたTempIDと「マスタサービス鍵」の組み合わせを使用して、そのようなUEが広告し得る一時サービス文字列のリストをローカルで導出し、一致するかどうかブロードキャスト文字列と照合し得る。サービスに加入していないUEは、そのような手順を実行でき得ず、したがって、異なるUEによってブロードキャストされた異なるサービス識別子が実際は同じサービスを広告していることがあることを理解すらでき得ない。
実施形態によれば、発見および管理のためのクロスレイヤ通信が提供および/または使用され得る(例えば、最適化され得る)。アプリケーションサーバを介してプレゼンスベースのサービスを提供するために、UEは、それらの識別情報、およびサービス要求または利用可能性を広告し得る。アプリケーションサーバは、プレゼンスサービスを管理し得るエンドポイントであり得るので、UEによって集められた情報は、アプリケーションサーバに伝達され得る。しかしながら、感知される情報、通信の頻度、および参加するUEの数などが考察または考慮され得る場合、情報の量は、指数関数的に増加し得る。通信を減らすために、情報は、UEにおいてローカルにフィルタリングされ得、フィルタリングされた情報が、上流方向にアプリケーションサーバに伝達され得る。特定のサービスセッションを識別するための本明細書で説明される階層は、実施形態によるフィルタリング機能の基礎として使用され得る。加えて、そのような属性は、UEにおいて提供されるポリシを通してUEにおいてローカルにフィルタリングを提供して、アプリケーションサーバへの通信を減少させるために使用され得る。これらのポリシは、ネットワークレベルのポリシを反映した代理ポリシとすることができ、信頼できる方法で(例えば、適切で安全な保護された信頼できるポリシ実行を介して)、UE上で忠実に実行され得る。実施形態では、ランダムな一時IDまたは人間が読めるIDが、階層的フィルタリングのために使用され得る。前者の場合、一時識別情報から生成される短い文字列が、直接UE-UEリンクを介して、またはアプリケーションサーバを通して検証される、より長い文字列とともに、UEにおける初期フィルタリングのために使用され得る。後者では、命名規約が、ユーザの階層的な組を暗示し得、各々は、上位層の厳格なサブセットであり得る。
例えば、上で説明されたCompName.GameName.CompNameGroupXYZ.Applicationabc命名例が、ローカルなフィルタリングによる漸進的なトラフィックの削減を提供するために使用され得る。そのような実施形態では、「CompName」レベルは、例えば、CompNameによって提供されるもの以外のサービス発見情報をUEにおいて分離する、フィルタリングの最低のレベルを提供し得る。「CompName.GameName」レベルは、例えば、GameNameアプリケーションサービスのCompNameによって提供されるもの以外のサービス発見情報をUEにおいて分離する、フィルタリングの次のレベルを提供し得る。「CompName.GameName.CompNameGroupXYZ」レベルは、例えば、特定のCompName+CompNameGroupXYZサークルグループのGameNameアプリケーションサービスのCompNameによって提供されるもの以外のサービス発見情報をUEにおいて分離する、フィルタリングの次のレベルを提供し得る。「CompName.GameName.CompNameGroupXYZ.Applicationabc」レベルは、例えば、特定のCompName+CompNameGroupXYZグループおよびApplicationabcアプリケーションセッションのGameNameアプリケーションサービスのCompNameによって提供されるもの以外のサービス発見情報をUEにおいて分離する、フィルタリングの最高のレベルを提供し得る。
加えて、発見情報は、ハンドオフ動作およびQoS管理のために使用される無線測定と同様に、さらに調整され得る。例えば、実施され得る測定の頻度、およびこれらの測定がどれほどの頻度でアプリケーションサーバに報告され得るかが、トラフィックを管理するために使用され得る、さらなる手段または情報を提供し得る。
様々なアプリケーションサービスのための設定に応じて、UE上で提供されるポリシは、アプリケーションサーバへの発見情報トラフィックの微調整および調整も可能にし得、その結果、依然として高品質のサービスを提供しながら、通信の最適化を可能にし得る。
別の実施形態によれば、D2Dサービスを用いたサービスアクセスが提供および/または使用され得る。例えば、ネットワークとアプリケーションサーバサービスの間の対話、発見、およびデバイスツーデバイス通信の特定のケースのための登録が、提供および/または使用され得る。そのような実施形態では、そのようなメッセージフローは、D2Dサーバが、新しいコアネットワークノード、および/またはネットワークにおいてD2D関連情報を管理する責任がある機能として導入され得る、上で説明され、図1に示された手順の特定の例と見なされ得る。D2Dサーバは、直接D2Dリンクを使用すること、またはそれから利益を得ることができるサービスおよび/またはアプリケーションについてのサービスアクセスをネゴシエートするために、アプリケーションサーバと対話し得る、コアネットワークエンティティとすることができる。
(例えば、アプリケーションサーバとのインターフェースが存在し得ない)実施形態では、D2Dサーバは、上で説明されたようなD2D関連情報を受信し、サービスパラメータを決定するために、UEと対話し得る。
D2Dサーバを有する(例えば、3GPPの)EPCアーキテクチャ(例えば、オペレータ間D2Dアーキテクチャ)の例示的な実施形態が、図6に示され得る。そのようなアーキテクチャでは、D2Dサーバは、1つのオペレータ(例えば、PLMN A)のドメイン内に存在し得るが、別のオペレータ(例えば、PLMN B)内のノードからアクセス可能であり得る。加えて、D2Dサーバと、MME、HSS、PCRF、およびANDSFなど、EPC内の様々な既存のエンティティとの間の新しいインターフェースが、提供および/または使用され得る。実施形態では、そのようなアーキテクチャにおいて、データプレーンは影響を受けずにいることができ、コントロールプレーンへの新しいインターフェースが使用され得る。
図7は、UEが別のUEとのD2Dセッションに携わる場合の、UEからネットワーク(例えば、3GPPネットワーク)への接続に関するイベントのシーケンスを説明し得る、呼フローの例示的な実施形態を提供している。図7に示されるように、フローは、3つのセグメントに分割され得る。第1のステージにおいて、UEは、自らをネットワーク(例えば、3GPPネットワーク)に接続し得る。接続プロセスの一環として、UEは、それらが広告し得るD2Dデバイス識別子も獲得し得、そのため、他のUEは、デバイス発見手順を使用して、それらを見出し得る。接続プロセスの終わりにはユーザは、すでにネットワークに認証され得ており、ネットワークは、対応するユーザがD2Dサービスを獲得することを許可され得ていることを検証し得ている。D2Dサーバは、PCRFおよび/またはANDSFともシグナリングを交換し得る。
第2のステージ(例えば、サービス登録手順)において、ユーザは、それらが使用または必要とし得るサービスに応じて、自らを1または複数のアプリケーションサーバに登録し得る。サービス要求の一部として、ユーザは、オープンID、GBA、SSO、またはそれに関連付けられた他の識別情報を送信し得る。加えて、実施形態では、この要求の一部として、ユーザは、PLMN ID、および/またはセルラネットワークに関する他のパラメータも送信し得る。これは、アプリケーションサーバが、ユーザがすでにネットワーク(例えば、3GPPネットワーク)において認証され得ている事実を利用することを可能にし得、それが、関連するD2Dサーバと交信することを可能にし得る。アプリケーションサーバおよびD2Dサーバは、最初にオープンID、SSO、または他のプロトコルを使用して、ユーザを認証し得る。サービス要求は、UEがユニキャストサービスを要求しているか、それともマルチキャストサービスを要求しているかも、アプリケーションサーバに通知し得る。
その後、アプリケーションサーバは、ユーザによって要求されているサービスによってサポートされるD2D構成を、D2Dサーバに送信し得る。D2D構成は、サービスを使用するために必須であり得るD2D動作、任意選択であり得るD2D動作(例えば、UEは、D2Dモードにあるか、それとも基本的なセルラモードにあるかに関わりなく、アプリケーションに参加し得る)、および特定のサービスにおいて許可され得ないD2D動作などを含むことができる(しかし、それらに限定され得ない)。
加えて、実施形態では、D2Dサーバは、D2Dサービスが使用され得ない場合であっても、アプリケーションサーバとネットワーク(例えば、3GPPネットワーク)の間の制御インターフェースとして機能し得る。
D2Dサーバは、アプリケーションサーバから、QoSなどに関するサービス要件も受信し得、HSSとの対話によって、特定のUEがこれらのサービスを獲得することを許可され得ているかどうかを確認し得る。
D2Dサーバは、アプリケーションサーバから、D2Dサービス固有のポリシ要件をさらに受信し得、例えば、PCRFとの対話によって、UEがこれらのポリシ要件に満足でき得るかどうかを確認し得る。
実施形態では、確認がアプリケーションサーバに提供され得る。アプリケーションサーバは、その場合、そのようなサービスをネットワーク(例えば、3GPPネットワーク)内で識別するために使用され得る名前であり得る一時サービス名を、D2Dサーバに提供し得る。(例えば、友人のリストに関して)現在サービスに登録され得ている他のユーザのリストも提供され得る。D2Dサーバは、これら(例えば、リスト)の他に、デバイス発見のためにUEによって使用され得るサービス識別情報とそれらに対応するデバイス識別情報との間のマッピングも提供され得る。その後、(例えば、サービス登録プロセスの最終部分として)、UEは、確認をアプリケーションサーバに送信し得る。
サービス登録が実行され得た後(例えば、両方のUEが、上で説明された接続および登録手順を完了し得た後)、図7の最後のシーケンスまたはステージは、UE1とUE2の間のD2Dサービスの開始を示している。このフェーズの間に、D2D EPSおよび無線ベアラが確立され得る。D2Dサーバは、機能の中でもとりわけ、(IPアドレスなどの)ターゲットMME識別子情報をソースMMEに提供すること、およびUE能力を調停した後で、許容し得る構成に達することによって、ここでの特定の役割を果たし得る。
別の実施形態(例えば、第2の実施形態)によれば、ProSe制御インターフェース動作は、例えば、オペレータによって提供される識別情報に基づく。そのような実施形態では、ProSeサーバは、(例えば、第1の実施形態の)D2Dサーバの等価物であり得る。本明細書で使用され得るProSeアーキテクチャの概要が、図8に示され得る。
加えて、この実施形態では、MNオペレータによって提供される識別情報(例えば、本明細書で説明される頭字語OPI)が、セルラネットワークUE識別情報(例えば、TMSI、MSISDN)とユーザのアプリケーションレイヤユーザ識別情報の間の、識別情報の中間レイヤとして使用され得る。一実施形態によれば、オープンID(例えば、オープンIDプロトコルから導出されるOPI)が、そのようなOPIの主要な例であり得る。しかしながら、追加の実施形態では、(例えば、それがPLMN認証システム(例えば、GBA)と統合され得る限り、および「OPI識別情報」が、Facebookログインハンドルなどの「アプリケーションレイヤユーザ識別情報」の代わりに、使用および/または提供され得る場合)リバティアライアンス識別情報連合フレームワーク(Liberty Alliance Identity Federation Framework)などの別の技術が、代わりに使用され得る。
複数のアプリケーション識別情報が単一のOPIにマッピングされ得る場合、どのアプリケーションがそれを生じさせたかをそれ自らが決定し得ないという意味で、発見イベント自体が曖昧であり得る。その場合、例えば、以下のうちの1つを含むことができる追加のステージが、提供および/または実行され得る。一実施形態では、グループ内のアプリケーションの各々は、それらのアプリケーションサーバと交信して、どのアプリケーションまたはサーバが発見を生じさせたものであり得るかを確認し得る。別の実施形態では、UEが、セキュアチャネルを確立し得、それらのアプリケーションIDを交換して、どのアプリケーションが一致するかを調べ得る。セキュアチャネル鍵は、ProSe IDに基づき得る。そのような方法は、ネットワーク負荷を低減させ得る。別の実施形態では、UEは、それから再構成され得ないアプリケーションIDに基づいて、セキュアチャネルを生成し得、そのようなチャネルを使用して、どのアプリケーションが発見を起動し得たかを確認し得る。アプリケーションIDが一致しない場合、チャネルは機能し得ず、したがって、発見情報は、合法的なアプリケーションから利用可能であり得る。一実施形態では、そのような方法は、同様に、アプリケーションによって導出されたIDとともに使用され得る。
実施され得るProximityサービスは、近接サーバ(この実施形態ではProSeサーバ)によってサポートされ得る。ProSeサーバは、HTTP、SIP、または他のプロトコルに基づいたAPIなどのインターフェースを、UEとアプリケーションの両方に提供し得る。加えて、ProSeサーバとUEの間のインターフェースは、(例えば、UEの適切な機密性および認証を保証し得る)NASシグナリング上にあり得る。ProSeサービスを可能にするために、UEは、OPI識別情報、アプリケーションIDを指定し、おそらくは、アプリケーション固有の構成を追加して、ProSeサーバに登録し得る。その後、ユーザは、アプリケーションXにログインし得、他のアプリケーション加入者を発見し、それとデバイスツーデバイス(D2D)で通信するために、ProSeサービスを使用し得る。実施形態によれば、ユーザは、アプリケーションに直ちにログインしないこともあり得るが、依然として他のアプリケーション加入者によって発見可能であり得る。
識別情報に関して、ProSeサーバは、(例えば、現在サービスに登録されているユーザのために)OPI識別情報とセルラネットワーク識別情報の間のマッピングを維持し得、アプリケーションは、アプリケーションの加入者のために、OPI識別情報とアプリケーションレイヤユーザ識別情報(例えば、ユーザ名)の間のマッピングを維持し得る。
実施形態で説明されるProSe機能は、D2D通信、近接性発見、および(例えば、ユーザが、ProSeサービスに登録してはいるが、アプリケーションにログインしていない場合に使用され得る)アプリケーションウェイクアップ通知などを含むことができる。追加のサポート手順は、OPI識別情報検証も含むことができる。
ProSeサーバは、また、例えば、使用法に最小限の拡張を施した既存のスポンサ付きデータ接続性機能を通して、ProSe動作およびD2D通信の料金をアプリケーションプロバイダに請求することをサポートし得る。
例示的な実施形態では、ユーザは、アプリケーションを使用することを決定し得、それに接続し得、ユーザ名を用いてアカウントを生成し得、加えて、ProSeサービスのためのユーザ識別を受けるためにOPI識別情報を入力し得る(例えば、Alice@mno-y.comがMNO Yによって提供され得、それは、どのMNOと通信すべきかをアプリケーションにさらに知らせ得る)。アプリケーションは、また、OPI識別情報を獲得および/または検証し得、この時点から、Aliceは、このアプリケーションを通して提供されるProSeサービスを使用し得る。例示的な実施形態によれば、Aliceは、ProSeサーバに登録し、このアプリケーションProSeサービスをアクティブ化するための、OPI識別情報、アプリケーションの名前、および何らかのアプリケーション固有の構成を含めることができ、これは、任意の時点で(例えば、Aliceがアプリケーションにログインし得ていない場合であっても)実行され得る。アプリケーションは、そのユーザの1つがProSeサービスに登録した場合、通知され得、および/またはユーザアプリケーション固有の構成を獲得し得る。例えば、Aliceは、ある1組の友人たちが彼女とともに発見を開始し得ること、および彼女の現在のデバイスがビデオまたは他の機能を有し得ることを指定し得る。
図9は、本明細書で説明されるようなOPIに基づいて、ProSe制御インターフェース動作を提供および/または使用し得る実施形態のためのネットワークアーキテクチャ概要を示している。例えば、AP Xは、MNO YとのProSe協調合意を有し得、AP Xの1組の加入者にProSeサービスを提供することに、AP XとMNO Yは合意し得る。そのような合意は、AS-X1/3の場合は直接的とし得、またはAX-X2の場合は間接的とし得、AS-X2は、拡張OneAPIゲートウェイなどのAPIゲートウェイと協調し得る(例えば、APIゲートウェイは、ASとProSeサーバの間の相互接続を成立させ得る)。
加えて、そのような実施形態の変形が、アプリケーションとProSeサーバの間にインターフェースが存在し得ないケースを可能にするために使用され得、そのような実施形態の変形は、本明細書で(例えば、以下で)説明されるように、UEがカバレージの外に存在する場合のD2D通信、および/または複数のProSeサーバもしくはMNOが起動され得るケースを扱う拡張を容易にし得る。
実施形態によれば、オープンID識別情報が、例えば、中間識別情報レイヤとして、提供および/または使用され得る。例えば、MNOによって提供されるオープンID識別情報が、UE、ProSeサーバ、およびアプリケーションの間の中間識別情報として、提供および/または使用され得る。加えて、実施形態では、MNと一体化された他の認証方式(例えば、リバティアライアンス)を使用して導出され得る識別情報も使用され得る。
実施形態で説明されるように、UEは、MSISDNまたは仮名を依拠当事者(例えば、一般にASの一部として実施され得るRP)に提供し得、(例えば、0で表されるCN内のGBA/オープンIDノードの一部であり得る)NAF/OPは、この情報を認識し、それを3GPP識別情報に関連付け得るようになる。加えて、実施形態では、NAF/OPは、USS(例えば、提供、定義、および/または使用され得る、ユーザセキュリティ設定またはGBA USS)内に記憶され得る、IMPI、MSISDN、または他の識別子を受信し得る。USSは、firstname.lastname@example.com、またはmy.pseudonym@example.comなどのユーザID(UID)を含むことができる。そのため、GBAとオープンIDとの現在の統合は、いくつかのオープンID識別情報がエンドユーザから利用可能であることを可能にし得る。
例示的な実施形態では、オペレータは、人間によって生成される仮名または機械によって生成される仮名を含む、新しいIDを生成するための技法を提供し得る(例えば、これは、ウェブポータルを通して、またはUEがオープンIDを使用して新しいアプリケーションにアクセスするときに自動的にトリガされるUE上のローカルアプリケーションを通して行われ、その場合、ユーザは、既存のオープンIDを選択し得、またはアプリケーションのために新しいものを生成し得る)。この実施形態では、ローカルアプリケーションは、新しいIDを生成して返し得、またIDをHSS内のユーザプロファイルのUSSに記憶し得る、オープンID識別情報マネージャサービスなどの、MNOによって提供されるサービスに接続し得る。
実施形態によれば、MNOによって提供される識別情報を中間識別情報として使用することは有益であり得、そのため、ProSeサーバは、この識別情報が加入者に有効に属し得ることを(例えば、HSSを用いてチェックすることによって)検証し得る。加えて、中間識別情報は、ユーザが、アプリケーションにログインすることなく、ProSe検出機能をオンにすることを可能にし得る、存続期間の長い識別情報とすることができる。
アプリケーションに関連付けられたユーザ識別情報セットの例は、以下の通りであり得、または以下のうちの1もしくは複数を含むことができ、すなわち、それらは、彼女がいくつかの仕事関連または政府関連のアプリケーションとともに使用することを選択した識別情報であり得る、alice.smith@mno1.com、彼女がいくつかの電話関連のアプリケーションとともに使用することを選択した識別情報であり得る、<MSISDN>@mno1.com、彼女がオンラインファイルホスティングサービスにログオンするために使用し得る、(例えば、要求時にMNO1によって生成される)abc123ab12@mno1.com、ならびに彼女がCompNameメール、CompNameトーク、および他のCompNameアプリケーションにログインするために使用し得る(例えば、CompNameは、これらのアカウントが同じ物理的人物に属し得ることを認識し得ない)、異なるIDであり得る、567abc12dc@mno1.com、および789cde34ed@mno1.comなどである。
実施形態では、いくつかのアプリケーションプロバイダは、ユーザが2以上のアカウントを有することを不可能にし得る(例えば、ユーザが2以上の異なるアカウントを有することを不可能にし得る)ポリシを有し得る。セルラユーザおよびアプリケーションレイヤユーザ識別情報毎に提供されるOPI識別情報は、直交であり得、アプリケーションにおけるマッピングを通して関連し得るので、本明細書で開示される実施形態は、そのようなタイプのポリシをサポートし得る。
加えて(例えば、利用の容易さ対プライバシに関して)、ユーザ関与を最低限に抑えるために、ユーザは、単一のOPI識別情報をサービスとともに使用し得る。これは、サードパーティが、このユーザの関与を異なるアプリケーションに関連付けることを可能にし得、または可能にさせ得る。(例えば、仕事用に1つ、ゲーム用に1つなど)いくつかのレベルの仮名識別情報が、提供および/または使用され得る(例えば、それによって、少しまたは僅かながら、より安全になり得る)。加えて、ユーザは、アプリケーション毎に1または複数の個別の識別情報を使用することを選択し得る。
実施形態によれば、(例えば、サービス登録のための)UE-ProSe制御インターフェースが提供および/または使用され得る。例えば、(例えば、近接性発見およびデバイスツーデバイス通信など)アプリケーションXに関連するProSeサービスから利益を得ることを要望または望むことがあるユーザは、適切なOPI識別情報(例えば、アプリケーションXがUEのユーザのアプリケーション識別情報に関連付け得たOPI識別情報)を使用して、ProSeサーバに登録し得る。実施形態では(例えば、一般に)、UEが認証され得るように、また提供されたOPI識別情報が実際にユーザに属し得ること(例えば、それが加入者のプロファイルのUSSに記載され得ていること)を保証するために、ProSeサーバがHSSと通信し得るように、UEとProSeサーバの間のNASシグナリングが使用され得る。代替的な実施形態は、UEとProSeサーバの間のアプリケーションシグナリング(例えば、HTTPS)を使用することを含むことができる。この実施形態では、GBA/オープンIDが統合された手順が、ユーザを適切に認証するために使用され得る。例示的な実施形態によれば、それは安全であり得、また認証されて、ProSeサーバがUEの3GPP識別情報などの識別情報を知り得る(例えば、したがって、加入者プロファイルをHSSから獲得し得る)ことを保証し得るので、NASシグナリングが提供および/または使用され得る。代替的な実施形態では、ProSeサーバは、与えられたOPI識別情報に関連する加入者プロファイルを獲得するために、HSSに問い合わせ得る。ProSeサーバがEPSの一部であり得る場合にも、NASシグナリングが提供および/または使用され得る。実施形態によれば、ProSeサーバは、EPC内のいくつかの他のエンティティとインターフェース接続し得るので、それは、EPCの外部ではなく、EPCの一部と見なされ得る。
Proximityサービス機能(例えば、それの便益)への明示的な登録は、ユーザによるProSeサーバのきめ細かい制御を可能にし得る。例えば、ユーザは、アプリケーションにログインしている場合であっても、(例えば、バッテリ電力を節約するために)いずれかのProximityサービスを止めることを要望または望み得る。ユーザは、どのアプリケーションにおいてProximityサービスを使用することを望みまたは要望するかを選択し得る。1つのアプリケーション内であっても、ユーザは、1つのアプリケーション識別情報を使用する場合はProximityサービスを使用し、別のものを用いる場合は使用しないことを望みまたは要望し得る。加えて、いくつかの協力するアプリケーションに加入するユーザは、これらのアプリケーションの各々において同じ識別情報を使用することから利益を得ることができる。例えば、D2Dビデオアプリケーションなどのアプリケーションは、同じエリアで動作する異なるPLMNとともに機能し得、ユーザ間でのProSe機能の網間接続を可能にすることを決定し得る。
UEは、ProSeサーバに認証され得た後、例えば、以下のうちの1または複数を含む、この登録についての1または複数のパラメータを送信し得る。例えば、UEは、アプリケーションが、ProSe APIを使用する場合に、それ自体を識別するために使用し得る名前であり得る、app-name@app-domain.comなどの、受け入れられたアプリケーションの識別情報を含むこと、または送信することができる。アプリケーションIDとともに、UEは、(例えば、発見、およびアプリケーション通知など)このアプリケーションのための認可されたProSe機能のリストも含むことができる。
加えて、アプリケーション固有の構成が、(例えば、UEによって)含まれ、または送信され得る。例えば、アプリケーション固有の構成は、ProSeサーバに不明瞭なデータであり得、例えば、XMLドキュメントを含むことができ、またはXMLドキュメントであり得る。MNOがこの情報にアクセスし得ないことを保証するために、実施形態では、アプリケーション固有の構成は、アプリケーションによって提供される公開鍵を使用して、それを暗号化することによって、秘密にされ得る。加えて、アプリケーションは、この構成を(例えば、ProSeサーバからの通知を通して)ProSeサーバから獲得し得る。使用の一例は、発見可能性を、(ソーシャルネットワークアプリケーション内の友人またはサークルなど)限定された1組の他のアプリケーション加入者に限定することとすることができる。使用の別の例は、デバイスの機能(例えば、デバイスがビデオ機能および/または他の機能を有し得るかどうか)についての記述を提供することとすることができる。
実施形態では、UE-ProSeサーバ通信は、(例えば、一般に)NASシグナリングを通したものであり得るので、ProSeサーバは、デバイスの識別情報(例えば、TMSI)を有し得、したがって、どのデバイスが与えられた識別情報とともに登録され得ているかを知り得る。加えて、アプリケーションは、上で説明された、アプリケーション固有の構成を通して伝達され得る、ビデオに対するサポートなど、アプリケーション関連の機能を除いて、それ(例えば、デバイスおよび/または与えられた識別情報)について知り得ず、関心をもち得ない。ProSeサーバは、OPI識別情報に言及する要求を受信し得た場合、デバイスが、与えられたOPI識別情報を用いて、現在ログオンまたはログインし得ているかどうかをチェックし得る。そのため、ProSeサーバは、OPI識別情報を、加入者(例えば、USIM上の加入者識別情報によって表されるようなAlice)と対応付け、またProximityサービス(例えば、デバイスツーデバイス通信、近接性検出など)を可能にし得る、この識別情報に現在登録されているデバイスと対応付け得る。
UE-アプリケーションインターフェース上のユーザ識別情報も、本明細書で説明されるように提供および/または使用され得る。例えば、実施形態では、UEは、例えば、2回(例えば、一度はOPI識別情報を用いて、一度はアプリケーションレイヤユーザ識別情報を用いて)、アプリケーションに認証され得る。本明細書で説明されるように、これらのレベルの認証は、統合され得、または少なくとも、ユーザに対する影響は、最小化され得る。
例えば、実施形態(例えば、ケース1)では、アプリケーションプロバイダは、自らのアプリケーションレイヤ認証方式(例えば、ソーシャルネットワークアプリケーションログイン)を使用し得る。このアプリケーションを通してProSeサービスを使用することを可能にするために、ユーザは、アプリケーションプロファイルにOPI識別情報をさらに入力することを求められる。この時点から、アプリケーションは、アプリケーションIDとOPI識別情報を対応付け得る。
別の実施形態(例えば、ケース2)では、アプリケーションプロバイダは、ユーザのOPI識別情報を通してユーザを認証することを選択し得る。そのような実施形態では、アプリケーションレイヤユーザ識別情報とOPI識別情報は、同じとすることができ、対応付けは、使用または提供されなくてよい。
さらに、実施形態(例えば、ケース3)では、アプリケーションプロバイダは、アプリケーションレイヤユーザ識別情報またはOPI識別情報を通して、ユーザを認証し得る。例えば、Facebookなどのサービスは、一般にアプリケーションレイヤログインを受け入れ得るが、ProSeサービスを提供するMNOなど、あるオープンIDプロバイダからのオープンID識別情報も受け入れ得る。UE上のクライアントアプリケーションまたはエージェントは、したがって、選択されたOPI識別情報を使用して、アプリケーションにログインし得る。実施形態では、アプリケーションは、(例えば、初回には)既存のアカウントにログインするようにユーザに提案し得、アプリケーションIDとOPI識別情報の間の対応付けを記録し得る。そのため、次回、またはアクセスを試みる場合、アプリケーションは、このアカウントにユーザを自動的にログインさせ得る。
例示的な実施形態によれば、アプリケーション-ProSe制御インターフェースが、本明細書で説明されるように(例えば、サービス要求のために)提供および/または使用され得る。例えば、アプリケーション-ProSeサーバ制御インターフェースは、直接的なインターフェースとすることができ、または代わりに、APIゲートウェイ(例えば、拡張OneAPIゲートウェイ)を通して存在し得る。このインターフェースは、Proximityサービス要求を伝達するために使用され得る。そのような要求は、以下のうちの1または複数を、すなわち、(例えば、本明細書で説明され得る)D2D通信、近接性検出、およびアプリケーションウェイクアップ通知などのうちの1または複数を含むことができる。UEがProSe機能をアクティブ化し得た場合に通知される、OPI識別情報検出および/または登録など、さらなる機能が、このインターフェース上で可能にされ得る。例示的な実施形態によれば、そのような要求でアプリケーションによってProSeサーバに提供される情報は、以下のうちの1または複数を、すなわち、アプリケーションID(例えば、APまたはMNOによって提供され得、ProSeサービス協調合意の一部として合意され得る識別子)、要求のタイプ(例えば、D2D通信、近接性検出、およびアプリケーションウェイクアップ通知など)、本人(例えば、この要求を発したユーザ)のOPI識別情報、他のユーザ(例えば、D2D通信の場合は相手、近接性検出の場合は友人のグループ、およびアプリケーションウェイクアップ通知の場合はなしなど)のOPI識別情報、ならびにD2D通信上のトラフィックフローを識別し得る何らかのトラフィックフィルタなどのうちの1または複数を含むことができる。
加えて、実施形態では、アプリケーション-ProSe制御インターフェースが、保護されたウェブサービスとして実施され得る。例えば、ゲートウェイが提供および/または使用され得る場合、ゲートウェイの両側で、異なるプロトコルが提供および/または使用され得る。
請求も、本明細書で説明されたように、提供および/または使用され得る。実施形態では、近接サーバは、請求システム(例えば、一般にRf/Mf上のオフラインOFCS、または一般にRo/Mo上のオンラインOCS、ここで、Mo/Mfは、現在提供および/または使用され得、セキュリティの追加レイヤなどの追加された機能を有するRo/Rfに基づき得る、Ro/Rfと等価のインターフェースであり得る)と相互接続され得る。
実施形態では、Proximityサービス請求の場合、アプリケーションプロバイダは、サービスに対する料金を請求され得、または請求され得た。そのようなモデルを可能にするために、(例えば、有益な概要を含むように現在定義および/または提供され得る)既存のスポンサ付きデータ接続性機能が拡張され得る。今日、それは、AFとPCRFの間のRxインターフェース上で可能にされ得る。PCRFは、その後、ベアラをセットアップまたは更新するために、PCEF/BBERF(例えば、PDNゲートウェイ)と通信し得る。PDNゲートウェイは、請求システムと通信し得る。例えば、それは、アカウンティング記録をRf上でオフライン請求システムに送信し得、または記録され得る使用データをRo上でオンライン請求システムに送信し得る。Ro/Rfインターフェースは、スポンサ-識別情報AVP(例えば、Rxのために定義されるのと同じAVP)にスポンサ識別情報を設定することをサポートし得る。あるいは、特定の請求鍵が、請求記録をアプリケーションプロバイダに関連付けるために、請求システムによって使用され得る。
例示的な実施形態によれば、ProSeサーバは、アプリケーションプロバイダ識別情報をスポンサとしてRo/RfもしくはMo/Mfに渡し得、および/または特定のアプリケーションプロバイダに関連付けられた特定の請求鍵を使用し得る。そのような実施形態は、シグナリング変更を使用し得ないが、(例えば、この新しいスポンサ機能はデータ接続性の他に、請求イベントのためのものであり得るので、またPCEFまたはBBERF以外の別のエンティティが機能を利用し得るので)既存のシグナリングの新しい使用を含むことができる。
加えて、ProSeサーバは、例えば、Rx上で、D2DポリシをPCRFに伝達し得る場合、このセッションがAPによって支払われ得ることを仮定して、(例えば、上で説明されたAVPを使用して)スポンサ識別情報も設定し得る。
そのため、実施形態では、ProSe動作の料金をアプリケーションプロバイダに請求ことが、(例えば、ProSeサービス自体の料金を請求するために)一方の側において、拡張された「スポンサ付きデータ接続性」PCC機能を使用するProSeサーバを有することによって可能にされ得、(例えば、D2D接続上のトラフィックの料金を請求するために)他方において、既存の「スポンサ付きデータ接続性」PCC機能を使用し得る。
セキュリティ機能および/または態様も、本明細書で説明されるように提供および/または使用され得る。例えば、実施形態では、UEがProSeサーバに対して偽のOPI識別情報を使用するリスクが軽減され得る。本明細書で説明されるように、UEとProSeサーバの間の通信の方法は、NASシグナリングを介したもの、またはNASシグナリング上のものであり得る。これは、UEが認証され得、通信が保護され得ることを保証し得る。ProSeサーバは、したがって、UEのセルラネットワーク識別情報(例えば、TMSI)を知り得る。ProSeサーバは、その後、HSSから加入者プロファイルを獲得し得、与えられたOPI識別情報が実際にこのプロファイルのUSSセクションに記載されていることを検証し得る。
UE-ProSeサーバ通信がアプリケーションレイヤ(例えば、HTTPS)で行われ得る、実施形態では、UEは、GBA-リバティアライアンス、オープンID、および/または他の統合された手順を使用して、ProSeサーバに認証され得るが、その結果、MNOが、使用されるOPI識別情報と、UE 3GPP識別情報などのUE識別情報との間の結び付きを保証し得るので、UEは、偽のOPI識別情報を使用し得なくなる。ProSeサーバは、問い合わせ(例えば、新しい問い合わせ)を使用して、与えられたOPI識別情報を含み得る加入者プロファイルを獲得することによって、HSSから加入者プロファイルを獲得し得る。
加えて、実施形態では、UEがアプリケーションに対して偽のOPI識別情報を使用するリスクが軽減され得る。例えば、UEがアプリケーションに対して偽のOPI識別情報を使用するリスクは、本明細書で説明されるオープンID認証手順の使用を通して軽減され得る。実施形態(例えば、ケース1)では、UEは、GBA-リバティアライアンス、オープンID、および/または他の統合された手順を使用して、アプリケーションサーバを認証し得る。そのような実施形態は、アプリケーションプロバイダがMNOとのサービス協調を有し得る場合に使用され得る。加えて、そのような実施形態では、MNOは、このUEが実際にこの識別情報を保有することを保証し得る。
別の実施形態(例えば、ケース2)によれば、アプリケーションは、他の認証方式(例えば、サードパーティ識別情報プロバイダからのOAuthもしくはオープンID、またはアプリケーションレイヤ認証)を使用し得る。Proximityサービスを使用するために、アプリケーションは、その後、ユーザがOPI識別情報を入力するための方法(例えば、ウェブフォーム)を提供し得る。アプリケーションは、OPI識別情報が有効にエンドユーザに属し得ることを検証するために、(例えば、統合されたGBAまたはオープンID手順を使用して)認証手順を実行し得る。実施形態では、アプリケーションは、GBA/オープンID手順が使用され得ることを認識し得ない。例えば、アプリケーションは、識別情報プロバイダが、ProSeサービスを提供し得るMNOであり得ることを知り得る。
アプリケーションがProSeサーバに対して偽のUE OPI識別情報を使用するリスクも軽減され得る。例えば、MNOは、APが自らの加入者のオープンIDを使用し得ることを盲目的に信用し得ない。そのため、実施形態では、ProSeアプリケーションAPIは、「user_id_verification(OPI識別情報)」関数を含むことができ、アプリケーションは、検証されたOPI識別情報を利用し得る(例えば、1つの未検証のOPI識別情報を含む要求は拒否され得る)。(例えば、MNOおよびAPが同じエンティティであり得る)いくつかの実施形態では、
これ(例えば、関数)は省略され得る。
検証APIは、(例えば、この時点でアプリケーションとProSeサーバの両方にログオンし得る)UEの他、アプリケーションにも関与し得る。この手順では、ProSeは、アプリケーションによって与えられたOPI識別情報が実際にアプリケーションにログオンし得ることを検証し得る。例えば、ProSeサーバは、ランダムなトークンをアプリケーションに送信し得る。アプリケーションは、それをUEに(例えば、アプリケーションシグナリングを通して)伝達し得る。加えて、UEは、ProSeサーバに通知するために、ProSeサーバ-UE API関数「user_id_verification_token(unencrypted_token)」を通して、トークンを送信し得る。実施形態では、UEは、ProSeサーバに認証され得、ProSeサーバは、(例えば、UEが、UEとProSeサーバの間の安全な認証されたアプリケーションセッション上で、この情報を伝達し得るので)与えられたOPI識別情報に関連付けられたUEが、実際にアプリケーションと通信し得ることを知り得る。OPI検証は、一定の期間、有効であり得、および/または手順は、アプリケーションから退出するユーザを考慮して、アプリケーションによって周期的に再実行され得る。識別情報検証手順は、以下でより詳細に説明され得る。
実施形態によれば、アプリケーションが偽のApp IDを使用して、別のアプリケーションプロバイダに請求を行うリスクが軽減され得る。例えば、アプリケーションXは、ProSeサーバに伝達する場合にアプリケーションYのIDを使用して、利用コストを別のアプリケーションプロバイダに転嫁し得る。そのような問題を回避するために、アプリケーションとProSeサーバの間の安全な接続が提供および/または使用され得る。加えて、APとMNOの間のProSe合意の一環として、APは、その識別情報(例えば、ドメイン名)をMNOに伝達し得、またはMNOからそれ(例えば、アカウント番号)を獲得し得る。そのような識別情報は、相互接続セットアップ中に、安全に伝達され得る(例えば、それは、信用されたサードパーティ(認証局)によって配送され得る公開鍵証明書によって保証され得る)。
実施形態では、ユーザセキュリティ設定(USS)増大のリスクが軽減され得る。例えば、GBAまたはオープンID統合が使用され得る場合、オープンID識別情報は、加入者プロファイルのUSS内に記憶され得る。そのような実施形態では、1つの潜在的な問題は、様々な識別情報が長期間にわたって蓄積され、とめどなく増大するUSSのサイズをもたらすことを含むことができる。そのよう難点を抑制するために、MNOは、一般に、識別情報の数を制限し得る。例えば、数個の長期識別情報(例えば、<MSISDN>@mno.com)が、MNOによってセットアップされ得、ユーザによって変更され得ない。加えて、ユーザは、固定された最大数を超えるこれらのエントリが存在し得ないように、数個の識別情報(例えば、first.last@mno.com)を選択し得、および/または新しい識別情報を生成するために、ユーザは、その後、古いものを削除し得る。
実施形態では、MNOは、(例えば、1つの特定のアプリケーションとともに使用される)識別情報をオンデマンドでも生成し得る。これらのエントリは、作成日付または単調増加数と関連付けられ、識別情報(例えば、<random>-12@mno.com、<another-random>-13@mno.comなど)の一部とし得、または識別情報とともに記憶され得る。加えて、識別情報の最大数に到達し得た場合、最も以前に生成された識別情報が削除され得る。あるいは、実施形態では、最後に使用された日付-時刻が識別情報とともに記憶され得、最も以前に使用された識別情報が代わりに削除され得る。そのような実施形態では、ユーザは、もはや存在し得ない、または使用され得ない、古い識別情報の再利用を望み得る。新しいOPI識別情報も生成され得る。そのため、アプリケーションは、特定のアプリケーション識別情報に関連付けられたOPI識別情報の変更をサポートし得る。
本明細書で説明されるように、アプリケーションとProSeサーバの間のインターフェースが存在し得ない場合のサポートが提供され得る。例えば、本明細書で開示される実施形態の1つの特徴は、Proximityサービスがアプリケーションを通して可能にされ得ることとすることができる。そのような実施形態またはモデルは、(例えば、ProSeサーバとのインターフェースを有さないサードパーティアプリケーションに関連する)PLMN加入者の各々によってアクセス可能な汎用Proximityサービスを有することを妨げ得ない。例えば、汎用近接性検出およびD2Dオーディオ/ビデオ接続サービスが、オペレータによって配備され得、MNOは、この実施形態では、MNO-ProSe-アプリケーションなどのアプリケーション(例えば、非IMS AS)を配備し得る。MNO-ProSe-アプリケーションは、ProSeサーバと関連付けることができ、またはProSeサーバの一部として実施され得る。他の外部的に提供されるアプリケーションは、MNOとの関係を有し得るが、EPCへのインターフェースを有し得ない。
請求の観点からは、アプリケーションがProSeサーバとのインターフェースを有し得ない場合であっても、アプリケーションは、MNOとの合意を有し得、または有し得ない。実施形態では、アプリケーションが料金を請求され得、例えば、UEは、アプリケーション識別情報をProSeサーバに渡し得、MNOは、(例えば、サードパーティCAからのApp識別情報、アプリケーションサーバからの認可、ならびにHSSおよび/またはProSeサーバ内の内部PLMN構成からのチェック認可などの)検証を実行し得る。実施形態では、エンドユーザがサービスの料金を請求され得る。
加えて、実施形態では、メカニズムの基本原理は、UEが要求をアプリケーションに送信し得、アプリケーションは、要求の様々な行為者のアプリケーションレイヤユーザ識別情報からマッピングされるOPI識別情報のリストによって(例えば、受け入れられる場合は)応答し得る。アプリケーションは、D2D通信のためのトラフィックを識別するフィルタなど、他の情報も追加し得る。UEは、その後、MNO-ProSe-アプリケーションに、本明細書で(例えば、上で)説明された要求などの要求を送信し得る。
そのため、App-CNインターフェースがない実施形態のサポートは、アプリケーションが(例えば、おそらくはProSeサーバ自体の一部として)MNOによって配備され得る、本明細書で説明される第2の実施形態の主要な変形の特殊なケースであり得る。主要な相違は、(例えば、CNとのインターフェースを有さない)サードパーティアプリケーションが、ユーザ名をOPI識別情報と対応付けることができ得、これらのOPI識別情報を要求時にユーザに提供し得ることとすることができる。実施形態では、サードパーティアプリケーションのユーザ名がOPI識別情報であり得る場合、対応付けは使用されなくてよい。それ以外の場合、サードパーティアプリケーションは、本明細書で説明されるように、ユーザ名/OPI識別情報の対応付けをサポートしなければならない。
実施形態では、UEがカバレージの外にあり得る場合のサポートも提供され得る。例えば、UEの1または複数がセルラネットワークカバレージの外にあり得る場合、デバイスツーデバイス通信も可能にされ得る。この実施形態では、各UEは、発見の他、D2D機能のためにも使用され得る、他の識別情報を認識し得る。さらに、UEは、両立可能なD2D検出構成を有し得る(例えば、一方のUEはリスン動作中であり得、他方のUEはビーコンの送信を開始し得る)。
そのような実施形態の方法は、例えば、UEがネットワークカバレージの下にあり得、アプリケーションおよびProSeサーバに接続され得るときに、あらかじめそのような動作のために、UEを事前構成することを可能にし得る。実施形態では、1つのユーザが、アプリケーションとともに、事前構成手順を開始し得る。アプリケーションは、要求をProSeサーバに送信し得る。ProSeサーバは、(例えば、OPI識別情報からUE識別情報へのマッピングの後、UEが適切な識別情報とともにProSeサーバに登録されることを望み得る)要求をUEに伝達し得る。この実施形態で説明される典型的な発見またはd2d接続とは対照的に、ProSeサーバは、これらの要求を「遅延」としてマークし得る。加えて、何らかの時刻またはイベント(例えば、「カバレージ外」イベント)における「ユーザ開始」など、1または複数のトリガタイプを、これらの要求に関連付けることができる。
第1の実施形態に類似する方法では、アプリケーションおよびProSeサーバは、動作のための一時サービス名を確立し得、本明細書で説明されるものなど(例えば、時間制限およびQoS要件など)、パラメータをそれに関連付けることができる。そのため、カバレージ外のケースのサポートは、第1の実施形態の拡張として使用または提供され得る。
ProSe機能の初期アクティブ化のための手順または方法が、図10に示され得る。例えば、図10に示されるメッセージフローは、ユーザがアプリケーションにログインしたときに実行され得、このアプリケーション内でProximityサービスをオンにし得る、手順または方法を説明し得る。この例では、アプリケーションは、アプリケーションレイヤログインおよびオープンIDログインの両方をサポートし得る。実施形態(例えば、ケース1および2)の他、他の実施形態(例えば、ケース)もサポートされ得る。
加えて、識別情報検証手順もしくは方法が、図11に示され得、アプリケーションにログインして、もしくはログインせずに、ProSeに登録するための手順もしくは方法が、図12に示され得、および/または発見手順もしくは方法が、図13に示され得る。図12に示される方法または手順は、UEベースの発見を示し得る。しかしながら、実施形態では、MMEが、UEから近接性更新を収集し得、この情報に基づいて近接性を検出し得る、ネットワークベースの発見も提供および/または使用され得る。アプリケーションウェイクアップ通知方法または手順が、図14に示され得、デバイスツーデバイス接続セットアップ手順または方法が、図15に示され得る。
本明細書で説明されるように、1または複数の拡張が提供および/または使用され得る。例えば、複数のProSeサーバが、ロードバランシングおよびフォールバックのために、MNOによって配備され得る。この実施形態では、UEがProSeサーバに登録し得た後、このProSeサーバは、DNSシステムまたは別のマッピングシステムを使用して、それ自体と、UEによって使用され得る特定のOPI識別情報とを結び付け得る。異なるProSeサーバによって扱われるUEに対するProSeサービスが要求され得た場合、これらのサーバは協力し得る。例えば、アプリケーションによって最初に接触が図られ得るProSeサーバ(例えば、「代理ProSeサーバ」)は、DNSを使用して、それが知り得ない識別情報を扱う他のProSeサーバを見つけ出し、その後、3GPP UE識別情報などのUE識別情報を、(例えば、get_user_profile(OPI識別情報,AP-X)などの、ProSeサーバ-ProSeサーバメッセージを使用して)これらのProSeサーバに要求し得る。例示的な実施形態では、要求アプリケーションが、ProSeサーバに登録するときに、エンドユーザによって認可され得た場合、これらのProSeサーバは、3GPP UE識別情報などのUE識別情報を提供し得る。
同様に、異なるMNOによって配備されるProSeサーバも、3GPP UE識別情報を交換するために協力し得、代理ProSeサーバは、ProSeサービスを可能にするために、異なるコアネットワークのノードと対話し得るようになる。
(例えば、同じPLMN内の、または異なるPLMNの)複数のProSeのための拡張は、以下のうちの1または複数を含むことができる。例えば、一実施形態(例えば、拡張)では、2つのProSeサーバの間のインターフェースが可能にされ得、このインターフェースは、例えば、MNOがロードバランシングのために2以上のProSeサーバを配備し得る場合、1つのMNOの内部にあり得る。加えて、このインターフェースは、例えば、2つのMNOがProSe協力合意を有し得る場合、これらの2つのMNOの間に存在し得る。
例示的な実施形態(例えば、拡張)では、GetIdentifierなどの、ProSeサーバ対ProSeサーバメッセージ(例えば、新しいメッセージ)が提供および/または使用され得る。そのようなメッセージは、OPI識別情報、および要求アプリケーションの名前などを含む、1または複数のパラメータを含むことができる。加えて、そのような要求またはメッセージを相手から受信した場合、ProSeサーバは、現在登録されているUEの中からOPI識別情報を探索し得、以下の情報のうちの1または複数を、すなわち、OPI識別情報に関連する3GPP識別情報(例えば、TMSI、MSISDN)、およびProSe機能などのうちの1または複数を返し得る。そのような実施形態では、アプリケーションは、MNO1およびMNO2の両方とのProSe合意を有し得る。そのため、アプリケーションは、UE2などのUEがPLMN2などの特定のPLMNに登録され得ることを通知され得る。この通知は、アプリケーション固有の構成を含むことができ、アプリケーションは、MNO1を通して動作を要求する場合に、この構成を考慮し得るようになる。
実施形態(例えば、拡張)によれば、ProSeサーバとOPI識別情報の間のDNSまたはENUMマッピング、およびそのための方法が提供および/または使用され得る。例えば、UEがOPI識別情報をProSeサーバに登録し得る場合、ProSeサーバは、DNSまたはENUMシステムのマッピング情報(例えば、alice@mno1.comに対して、proseサーバprose-server-1.mno1.comのエイリアスとしてalice.prose.mno1を定義し得る、DNS CNAMEエントリ)をアップロードし得る。
加えて、ProSeサーバが、現在このProSeサーバにログインされていない少なくとも1つのOPI識別情報(例えば、bob@mno1.com、またはbob@mno2.com)を含む要求を受信した場合、サーバは、以下のうちの1または複数(例えば、手順、または方法、またはアクション)を実行し得る。例えば、識別情報プロバイダが、ProSeサーバを配備するものと同じMNOであり得る場合、および/またはいくつかのProSeサーバが、このMNOによって配備され得る場合、DNSシステムは、bob.prose.mno1.comについて問い合わせされ得る。回答が得られ得た場合、ProSeサーバのBobの3GPP識別情報は、返されたIPアドレスに(GetIdentifier()を使用して)要求され得る。回答が得られ得ない場合、このOPI識別情報は、登録され得ておらず、ローカルポリシに応じて、ProSeサーバは、元の要求を拒否し得、または可能であれば部分的な処理を継続し得る。加えて、MNOによって配備されるProSeサーバが1つしか存在し得ない場合、このOPI識別情報は、登録され得ていない(例えば、上で説明されたように、拒否され得、または部分的な処理が継続され得る)。実施形態では、識別情報プロバイダが、MNO1とのProSe協力に合意した別のMNO2であり得る場合、DNSシステムは、bob.prose.mno2.comについて問い合わされ得、応答は、上で説明されたように、処理され得る。
実施形態によれば、代理ProSeサーバは、関連するUEの3GPP識別情報および機能を獲得し得た後、デバイス発見の手順もしくは方法、または他の手順もしくは方法などの動作を継続および開始し得る。
本明細書では、UEもしくはWTRU、ユーザ、またはUE/ユーザという用語が使用され得るが、そのような用語の使用は、交換可能になされ得、そのため、区別され得なくてよいことが理解され得よう。
加えて、本明細書で使用されるProSeは、地理的および/もしくは物理的に近接するUEの発見、ならびに/またはそれらの間の情報交換を表す、Proximityサービスのことであり得る。同じ名前が、類似しているが必ずしも同じではない機能を表すために、3GPPによって使用されることがある。また、本明細書では、D2DおよびProSeという用語が使用され得るが、そのような用語の使用は、交換可能になされ得、そのため、区別され得なくてよいことが理解され得よう。例えば、D2DサーバはProSeサーバを、もしくはProSeサーバはD2Dサーバを表し得、および/または一方は他方の機能のサブセットを実施し得る。さらに、本明細書では、一時サービス名および一時識別子ProSeという用語が使用され得るが、そのような用語の使用は、交換可能になされ得、そのため、区別され得なくてよいことが理解され得よう。
上では特徴および要素が特定の組み合わせで説明されたが、各特徴または要素は、単独で使用され得、または他の特徴および要素との任意の組み合わせで使用され得ることを当業者は理解されよう。加えて、本明細書で説明された方法は、コンピュータまたはプロセッサによって実行される、コンピュータ可読媒体内に包含された、コンピュータプログラム、ソフトウェア、またはファームウェアで実施され得る。コンピュータ可読媒体の例は、(有線またはワイヤレス接続上で送信される)電子信号、およびコンピュータ可読記憶媒体を含む。コンピュータ可読記憶媒体の例は、リードオンリメモリ(ROM)、ランダムアクセスメモリ(RAM)、レジスタ、キャッシュメモリ、半導体メモリデバイス、内蔵ハードディスクおよび着脱可能ディスクなどの磁気媒体、光磁気媒体、ならびにCD-ROMディスクおよびデジタル多用途ディスク(DVD)などの光媒体を含むが、それらに限定されない。ソフトウェアと連携するプロセッサは、WTRU、UE、端末、基地局、RNC、または任意のホストコンピュータのための無線周波数送受信機を実施するために使用され得る。