JP2017076988A - 移動局上で実行されるアプリケーションの「キープアライブ」メッセージ頻度を交渉するための方法および装置 - Google Patents
移動局上で実行されるアプリケーションの「キープアライブ」メッセージ頻度を交渉するための方法および装置 Download PDFInfo
- Publication number
- JP2017076988A JP2017076988A JP2016215959A JP2016215959A JP2017076988A JP 2017076988 A JP2017076988 A JP 2017076988A JP 2016215959 A JP2016215959 A JP 2016215959A JP 2016215959 A JP2016215959 A JP 2016215959A JP 2017076988 A JP2017076988 A JP 2017076988A
- Authority
- JP
- Japan
- Prior art keywords
- frequency
- wtru
- message
- application
- keep
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L45/00—Routing or path finding of packets in data switching networks
- H04L45/02—Topology update or discovery
- H04L45/026—Details of "hello" or keep-alive messages
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L43/00—Arrangements for monitoring or testing data switching networks
- H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
- H04L43/0805—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters by checking availability
- H04L43/0811—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters by checking availability by checking connectivity
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L43/00—Arrangements for monitoring or testing data switching networks
- H04L43/10—Active monitoring, e.g. heartbeat, ping or trace-route
- H04L43/103—Active monitoring, e.g. heartbeat, ping or trace-route with adaptive polling, i.e. dynamically adapting the polling rate
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/14—Session management
- H04L67/143—Termination or inactivation of sessions, e.g. event-controlled end of session
- H04L67/145—Termination or inactivation of sessions, e.g. event-controlled end of session avoiding end of session, e.g. keep-alive, heartbeats, resumption message or wake-up for inactive or interrupted session
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W72/00—Local resource management
- H04W72/04—Wireless resource allocation
- H04W72/044—Wireless resource allocation based on the type of the allocated resource
- H04W72/0453—Resources in frequency domain, e.g. a carrier in FDMA
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/08—Configuration management of networks or network elements
- H04L41/0893—Assignment of logical groups to network elements
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/08—Configuration management of networks or network elements
- H04L41/0894—Policy-based network configuration management
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/50—Network service management, e.g. ensuring proper service fulfilment according to agreements
- H04L41/5003—Managing SLA; Interaction between SLA and QoS
- H04L41/5019—Ensuring fulfilment of SLA
- H04L41/5022—Ensuring fulfilment of SLA by giving priorities, e.g. assigning classes of service
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/28—Timers or timing mechanisms used in protocols
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Health & Medical Sciences (AREA)
- Cardiology (AREA)
- General Health & Medical Sciences (AREA)
- Environmental & Geological Engineering (AREA)
- Mobile Radio Communication Systems (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Telephonic Communication Services (AREA)
- Computer Security & Cryptography (AREA)
Abstract
【課題】ワイヤレス送受信ユニット(WTRU)上で実行されるアプリケーションの「キープアライブ」メッセージ頻度を交渉するための方法および装置を提供する。
【解決手段】ノードは、交渉および同期機能(NSF)を備える。このNSFは、WTRU上で実行される種々のアプリケーションについてアプリケーションサーバによって必要とされるキープアライブメッセージの頻度を含む情報を収集し、キープアライブメッセージ頻度交渉要求メッセージをアプリケーションサーバに送って、各アプリケーションについてのより適切な頻度をWTRUに代わって交渉する。ノードはさらに、バッファリングおよびキャッシング機能(BCF)を備える。このBCFは、各アプリケーションが定期的なキープアライブメッセージを関連アプリケーションサーバに送る必要があるかどうかの指示を含めた、アプリケーション特有属性を、キャッシュおよびバッファリングする。
【選択図】図7
【解決手段】ノードは、交渉および同期機能(NSF)を備える。このNSFは、WTRU上で実行される種々のアプリケーションについてアプリケーションサーバによって必要とされるキープアライブメッセージの頻度を含む情報を収集し、キープアライブメッセージ頻度交渉要求メッセージをアプリケーションサーバに送って、各アプリケーションについてのより適切な頻度をWTRUに代わって交渉する。ノードはさらに、バッファリングおよびキャッシング機能(BCF)を備える。このBCFは、各アプリケーションが定期的なキープアライブメッセージを関連アプリケーションサーバに送る必要があるかどうかの指示を含めた、アプリケーション特有属性を、キャッシュおよびバッファリングする。
【選択図】図7
Description
本発明は、無線通信に関する。
(関連出願の相互参照)
本出願は、2012年10月22日に出願された米国特許仮出願第61/716,679号明細書の利益を主張するものであり、この仮出願の内容の全体は、参照により本明細書に組み込まれる。
本出願は、2012年10月22日に出願された米国特許仮出願第61/716,679号明細書の利益を主張するものであり、この仮出願の内容の全体は、参照により本明細書に組み込まれる。
今日、マシンタイプ通信(MTC)アプリケーションおよび非MTCアプリケーションを含めた、モバイルデバイスのための何十万個ものモバイルデータアプリケーションが存在する。これらのアプリケーションの多くは、モバイルブロードバンド接続を利用して、様々なタイプの通信をワイヤレス送受信ユニット(WTRU)(すなわち移動局)のユーザに提供することができる。
インスタントメッセージング(IM)、ソーシャルネットワーキングアプリケーション、アラームおよびサーベイランスシステムなど、いくつかの既存の「常時オン」モバイルデータアプリケーションは、現在、オペレータネットワークに課題をもたらしつつある。一般に、WTRU上で実行されるモバイルデータアプリケーションは、オペレータネットワークを介した、インターネット中に位置するアプリケーションサーバ(AS)との対話式通信を伴うことがある。
ASとモバイルデータアプリケーションは、「ハートビート」メッセージ(「キープアライブ」メッセージとしても知られる)を定期的に交換して、アプリケーションセッションをアライブに維持することができるとともに、進行中のインターネットプロトコル(IP)セッションを切断させるおそれのあるネットワークアドレス変換(NAT)マッピングの失効を回避することもできる。定期的なキープアライブメッセージに加えて、アプリケーションはまた、頻繁なステータス更新メッセージを生成して、アプリケーションに関連するステータス更新についてWTRUユーザに知らせることもある(例えば、インスタントメッセージング(IM)バディリスト中のバディのプレゼンス情報、ユーザ「チェックイン」時のユーザ位置の更新、WTRUユーザの友達への「フェイスブックの”いいね”表明」の更新など)。
しかし、膨大な数のWTRU上で実行される種々のアプリケーションに関連するこれらのキープアライブメッセージおよびステータス更新メッセージは、これらのWTRUの電池寿命にかなりの損害を与えることがある。さらに、これらのメッセージのせいで、コアネットワーク中のかなりのシグナリングトラフィック輻輳が生じることがある。
ワイヤレス送受信ユニット(WTRU)上で実行されるアプリケーションの「キープアライブ」メッセージ頻度を交渉するための方法および装置について記述される。ノードが、交渉および同期機能(NSF)を備えてよく、このNSFは、WTRU上で実行される種々のアプリケーションについてアプリケーションサーバによって必要とされるキープアライブメッセージの頻度を含む情報を収集し、キープアライブメッセージ頻度交渉要求メッセージをアプリケーションサーバに送って、各アプリケーションについてのより適切な頻度をWTRUに代わって交渉するように構成される。ノードはさらに、バッファリングおよびキャッシング機能(BCF)を備えてよく、このBCFは、各アプリケーションが定期的なキープアライブメッセージを関連アプリケーションサーバに送る必要があるかどうかの指示を含めた、アプリケーション特有属性を、キャッシュおよびバッファリングするように構成される。ノードは、パケットデータネットワークゲートウェイ、交渉およびキャッシングゲートウェイ、またはサービングゲートウェイであってよい。
添付の図面と共に例として提供される後続の記述から、より詳細な理解が得られるであろう。
1または複数の開示される実施形態がその中で実現され得る例示的な通信システムを示す図である。
図1Aに示される通信システム内で使用され得る例示的なワイヤレス送受信ユニット(WTRU)を示す図である。
図1Aに示される通信システム内で使用され得る例示的な無線アクセスネットワークおよび例示的なコアネットワーク(CN)を示す図である。
ロングタームエボリューション(LTE)大域的アーキテクチャの例を示す図である。
非マシンタイプ通信(非MTC)およびMTCアプリケーションの一般的なアーキテクチャの例を示す図である。
電池寿命に対するキープアライブメッセージの影響の例を示す図である。
WTRUが頻繁なアイドル−アクティブ状態遷移の問題を経験するときのタイミングの例を示す図である。
モバイルデータアプリケーションステータス更新およびキープアライブメッセージによって引き起こされる、シグナリング非効率性および短縮された電池寿命の例を示す図である。
パケットデータネットワークゲートウェイ(P−GW)中の、交渉および同期機能(NSF)ならびにバッファリングおよびキャッシング機能(BCF)の例を示す図である。
P−GW中のBCFと、ポリシ制御および課金規則機能(PCRF)中のNSFとの例を示す図である。
P−GW中のBCFと、ポリシ制御および課金規則機能(PCRF)中のNSFとの例を示す図である。
サービングゲートウェイ(S−GW)、P−GW、PCRF、およびインターネットとインタフェースする、交渉およびキャッシングゲートウェイ(NC−GW)中の、NSFおよびBCFの例を示す図である。
P−GWとインタフェースするNC−GW中の、NSFおよびBCFの例を示す図である。
WTRUから発信されるかまたはWTRUをターゲットとする、P−GWによって転送されるメッセージの属性の例を示す図である。
WTRU上のアプリケーションの情報の例を示す図である。
NSFが交渉を実施するのに有用な場合のある情報の例を示す図である。
キープアライブメッセージ頻度交渉要求メッセージの例を示す図である。
キープアライブメッセージ頻度交渉応答メッセージの例を示す図である。
頻度交渉プロシージャのメッセージフロー図の例を示す図である。
更新済み頻度通知メッセージの例を示す図である。
更新済み頻度通知メッセージの例を示す図である。
モバイル発信(MO)キープアライブメッセージ頻度交渉および更新プロシージャの例の流れ図である。
簡略化された頻度交渉要求メッセージの例を示す図である。
1つのMOキープアライブメッセージ頻度が複数のアプリケーションサーバによって同意されるときの頻度更新プロシージャの流れ図の例を示す図である。
複数のMOキープアライブメッセージ頻度が複数のアプリケーションサーバによって同意されてグループに分けられるときの、頻度更新プロシージャの流れ図の例を示す図である。
複数のMOキープアライブメッセージ頻度が複数のアプリケーションサーバによって同意されてグループに分けられるときの、頻度更新プロシージャの流れ図の例を示す図である。
複数のMOキープアライブメッセージ頻度が複数のアプリケーションサーバによって同意されてグループに分けられるときの、頻度更新プロシージャの流れ図の例を示す図である。
NSFによって送られるMOキープアライブメッセージ削減要求メッセージの例を示す図である。
WTRUによって送られるMOキープアライブメッセージ削減応答メッセージの例を示す図である。
NSFによって開始されるMOキープアライブメッセージ削減プロシージャの例示的なメッセージフローを示す図である。
WTRUによって送られるMOキープアライブメッセージ削減要求メッセージの例を示す図である。
WTRUによって開始されるMOキープアライブメッセージ削減プロシージャの例示的なメッセージフローを示す図である。
図1Aに、1または複数の開示される実施形態がその中で実現され得る例示的な通信システム100を示す。通信システム100は、音声、データ、ビデオ、メッセージング、ブロードキャストなどのコンテンツを複数のワイヤレスユーザに提供する多元接続システムであってよい。通信システム100は、複数のワイヤレスユーザが、ワイヤレス帯域幅を含めたシステムリソースの共有を通してこのようなコンテンツにアクセスするのを可能にすることができる。例えば、通信システム100は、符号分割多元接続(CDMA)、時分割多元接続(TDMA)、周波数分割多元接続(FDMA)、直交FDMA(OFDMA)、シングルキャリアFDMA(SC−FDMA)など、1または複数のチャネルアクセス方法を採用することができる。
図1Aに示されるように、通信システム100は、ワイヤレス送受信ユニット(WTRU)102a、102b、102c、102d、無線アクセスネットワーク(RAN)104、コアネットワーク(CN)106、公衆交換電話網(PSTN)108、インターネット110、および他のネットワーク112を含んでよいが、開示される実施形態が任意の数のWTRU、基地局、ネットワーク、および/またはネットワーク要素を企図することは理解されるであろう。各WTRU102a、102b、102c、102dは、ワイヤレス環境で動作および/または通信するように構成された任意のタイプのデバイスであってよい。例として、WTRU102a、102b、102c、102dは、ワイヤレス信号を送信および/または受信するように構成されてよく、ユーザ機器(UE)、移動局、固定またはモバイルの加入者ユニット、ページャ、セルラ電話機、パーソナルディジタルアシスタント(PDA)、スマートフォン、ラップトップ、ネットブック、パーソナルコンピュータ、ワイヤレスセンサ、消費者電子機器などを含み得る。
通信システム100はまた、基地局114aおよび基地局114bを含んでよい。各基地局114a、114bは、WTRU102a、102b、102c、102dのうちの少なくとも1つとワイヤレスにインタフェースして、CN106、インターネット110、および/または他のネットワーク112など、1または複数の通信ネットワークへのアクセスを容易にするように構成された、任意のタイプのデバイスであってよい。例として、基地局114a、114bは、ベーストランシーバステーション(BTS)、Node−B、進化型(evolved)Node−B(eNB)、Home Node−B(HNB)、Home eNB(HeNB)、サイトコントローラ、アクセスポイント(AP)、ワイヤレスルータなどであってよい。基地局114a、114bはそれぞれ単一の要素として描かれているが、基地局114a、114bが任意の数の相互接続された基地局および/またはネットワーク要素を含んでよいことは理解されるであろう。
基地局114aはRAN104の一部であってよく、RAN104はまた、他の基地局および/または基地局コントローラ(BSC)や無線ネットワークコントローラ(RNC)や中継ノードなどのネットワーク要素(図示せず)を含んでもよい。基地局114aおよび/または基地局114bは、特定の地理領域内でワイヤレス信号を送信および/または受信するように構成されてよく、この地理領域はセル(図示せず)と呼ばれることがある。セルはさらに、セルセクタに分割されてよい。例えば、基地局114aに関連するセルが、3つのセクタに分割されてよい。したがって、一実施形態では、基地局114aは、3つの送受信機、すなわちセルの各セクタにつき1つの送受信機を備えることができる。別の実施形態では、基地局114aは、多入力多出力(MIMO)技術を採用することができ、したがって、セルの各セクタにつき複数の送受信機を利用することができる。
基地局114a、114bは、エアインタフェース116を介してWTRU102a、102b、102c、102dのうちの1または複数と通信することができ、エアインタフェース116は、任意の適切なワイヤレス通信リンク(例えば無線周波数(RF)、マイクロ波、赤外線(IR)、紫外線(UV)、可視光など)であってよい。エアインタフェース116は、任意の適切な無線アクセス技術(RAT)を使用して確立されてよい。
より具体的には、上記のように、通信システム100は、多元接続システムであってよく、CDMA、TDMA、FDMA、OFDMA、SC−FDMAなど、1または複数のチャネルアクセス方式を採用することができる。例えば、RAN104中の基地局114a、およびWTRU102a、102b、102cは、ユニバーサルモバイルテレコミュニケーションズシステム(UMTS)地上無線アクセス(UTRA)などの無線技術を実装することができ、無線技術は、広帯域CDMA(WCDMA(登録商標))を使用してエアインタフェース116を確立することができる。WCDMAは、高速パケットアクセス(HSPA)および/または進化型HSPA(HSPA+)などの通信プロトコルを含んでよい。HSPAは、高速ダウンリンクパケットアクセス(HSDPA)および/または高速アップリンクパケットアクセス(HSUPA)を含んでよい。
別の実施形態では、基地局114aおよびWTRU102a、102b、102cは、進化型UTRA(E−UTRA)などの無線技術を実装することができ、無線技術は、ロングタームエボリューション(LTE)および/またはLTEアドバンスト(LTE−A)を使用してエアインタフェース116を確立することができる。
他の実施形態では、基地局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は、例えばワイヤレスルータ、HNB、HeNB、またはAPであってよく、事業所、家庭、車両、キャンパスなどの局所化されたエリア中でのワイヤレス接続性を容易にするために任意の適切な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は、CN106を介してインターネット110にアクセスすることは必要とされなくてよい。
RAN104は、CN106と通信してよく、CN106は、音声、データ、アプリケーション、および/またはボイスオーバインターネットプロトコル(VoIP)サービスをWTRU102a、102b、102c、102dのうちの1または複数に提供するように構成された、任意のタイプのネットワークであってよい。例えば、CN106は、呼制御、料金請求サービス、モバイル位置ベースサービス、前払い電話、インターネット接続性、ビデオ配信などを提供することができ、かつ/または、ユーザ認証など、高レベルのセキュリティ機能を実施することができる。図1Aには示されていないが、RAN104および/またはCN106は、RAN104と同じRATまたは異なるRATを採用する他のRANと、直接的または間接的に通信してもよいことは理解されるであろう。例えば、CN106は、E−UTRA無線技術を利用しているであろうRAN104に接続されるのに加えて、GSM無線技術を採用する別のRAN(図示せず)と通信してもよい。
CN106はまた、WTRU102a、102b、102c、102dがPSTN108、インターネット110、および/または他のネットワーク112にアクセスするためのゲートウェイとしての働きをすることができる。PSTN108は、プレーンオールドテレフォンサービス(POTS)を提供する回路交換電話網を含んでよい。インターネット110は、TCP/IPスイート中の、伝送制御プロトコル(TCP)、ユーザデータグラムプロトコル(UDP)、およびインターネットプロトコル(IP)など、共通の通信プロトコルを使用する相互接続されたコンピュータネットワークおよびデバイスの地球規模のシステムを含んでよい。ネットワーク112は、他のサービスプロバイダによって所有および/または運営される、有線またはワイヤレス通信ネットワークを含んでよい。例えば、ネットワーク112は、RAN104と同じRATまたは異なるRATを採用するであろう1または複数のRANに接続された、別のCNを含んでよい。
通信システム100中のWTRU102a、102b、102c、102dのいくつかまたは全ては、マルチモード能力を備えることができる。すなわち、WTRU102a、102b、102c、102dは、種々のワイヤレスリンクを介して種々のワイヤレスネットワークと通信するために、複数の送受信機を備えることができる。例えば、図1Aに示されるWTRU102cは、セルラベースの無線技術を採用するであろう基地局114aと、かつIEEE802無線技術を採用するであろう基地局114bと、通信するように構成されてよい。
図1Bに、図1Aに示される通信システム100内で使用され得る例示的なWTRU102を示す。図1Bに示されるように、WTRU102は、プロセッサ118、送受信機120、送受信要素(例えばアンテナ)122、スピーカ/マイクロホン124、キーパッド126、表示装置/タッチパッド128、非取外し可能メモリ130、取外し可能メモリ132、電源134、全地球測位システム(GPS)チップセット136、および周辺装置138を備えてよい。WTRU102が実施形態との整合性を維持しながら前述の要素の任意のサブコンビネーションを備えてよいことは理解されるであろう。
プロセッサ118は、汎用プロセッサ、専用プロセッサ、従来型プロセッサ、ディジタル信号プロセッサ(DSP)、マイクロプロセッサ、DSPコアに関連する1または複数のマイクロプロセッサ、コントローラ、マイクロコントローラ、特定用途向け集積回路(ASIC)、フィールドプログラマブルゲートアレイ(FPGA)回路、集積回路(IC)、状態機械などであってよい。プロセッサ118は、信号符号化、データ処理、電力制御、入出力処理、および/または、WTRU102がワイヤレス環境で動作できるようにする他の任意の機能を実施することができる。プロセッサ118は送受信機120に結合されてよく、送受信機120は送受信要素122に結合されてよい。図1Bではプロセッサ118と送受信機120とを別々のコンポーネントとして描いているが、プロセッサ118と送受信機120とは共に電子パッケージまたはチップ中で統合されてもよい。
送受信要素122は、エアインタフェース116を介して基地局(例えば基地局114a)との間で信号を送信または受信するように構成されてよい。例えば、一実施形態では、送受信要素122は、RF信号を送信および/または受信するように構成されたアンテナであってよい。別の実施形態では、送受信要素122は、例えばIR、UV、または可視光信号を送信および/または受信するように構成された、エミッタ/検出器であってよい。さらに別の実施形態では、送受信要素122は、RF信号と光信号の両方を送受信するように構成されてよい。送受信要素122は、任意の組合せのワイヤレス信号を送信および/または受信するように構成されてよい。
加えて、図1Bでは送受信要素122が単一の要素として描かれているが、WTRU102は、任意の数の送受信要素122を備えてよい。より具体的には、WTRU102は、MIMO技術を採用することができる。したがって、一実施形態では、WTRU102は、エアインタフェース116を介してワイヤレス信号を送受信するために、2つ以上の送受信要素122(例えば複数のアンテナ)を備えることができる。
送受信機120は、送受信要素122によって送信されることになる信号を変調し、送受信要素122によって受信された信号を復調するように構成されてよい。上記のように、WTRU102は、マルチモード能力を有することができる。したがって、送受信機120は、WTRU102が複数のRAT(例えばUTRAおよびIEEE802.11など)を介して通信できるようにするために、複数の送受信機を備えることができる。
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)からエアインタフェース116を介して位置情報を受信することができ、かつ/または、2つ以上の近隣基地局から受信されている信号のタイミングに基づいてその位置を決定することができる。WTRU102は、実施形態との整合性を維持しながら任意の適切な位置決定方法によって位置情報を取得することができる。
プロセッサ118はさらに、他の周辺装置138に結合されてよく、周辺装置138は、追加の特徴、機能、および/または有線もしくはワイヤレス接続性を提供する、1または複数のソフトウェアおよび/またはハードウェアモジュールを含み得る。例えば、周辺装置138は、加速度計、電子コンパス、衛星送受信機、ディジタルカメラ(写真またはビデオ用)、ユニバーサルシリアルバス(USB)ポート、振動デバイス、テレビジョン送受信機、ハンズフリーヘッドセット、Bluetooth(登録商標)モジュール、周波数変調(FM)無線ユニット、ディジタル音楽プレーヤ、メディアプレーヤ、ビデオゲームプレーヤモジュール、インターネットブラウザなどを含み得る。
図1Cに、図1Aに示される通信システム100内で使用され得る例示的なRAN104および例示的なCN106を示す。上記のように、RAN104は、UTRA無線技術を採用して、エアインタフェース116を介してWTRU102a、102b、102cと通信することができる。RAN104はまた、CN106とも通信してよい。
RAN104は、eNB140a、140b、140cを含んでよいが、RAN104が実施形態との整合性を維持しながら任意の数のeNBを含んでよいことは理解されるであろう。eNB140a、140b、140cはそれぞれ、エアインタフェース116を介してWTRU102a、102b、102cと通信するために、1または複数の送受信機を備えることができる。一実施形態では、eNB140a、140b、140cは、MIMO技術を実装することができる。したがって、例えばeNB140aは、複数のアンテナを使用して、WTRU102aとの間でワイヤレス信号を送受信することができる。
各eNB140a、140b、および140cは、特定のセル(図示せず)に関連してよく、無線リソース管理決定、ハンドオーバ決定、アップリンクおよび/またはダウンリンクにおけるユーザのスケジューリングなどを扱うように構成されてよい。図1Cに示されるように、eNB140a、140b、140cは、X2インタフェースを介して相互と通信することができる。
図1Cに示されるCN106は、モビリティ管理エンティティ(MME)142、サービングゲートウェイ144、およびパケットデータネットワーク(PDN)ゲートウェイ146を含んでよい。前述の各要素はCN106の一部として描かれているが、これらの要素の任意の1つがCNオペレータ以外のエンティティによって所有および/または運営されてもよいことは理解されるであろう。
MME142は、S1インタフェースを介してRAN104中の各eNB140a、140b、140cに接続されてよく、制御ノードとしての働きをすることができる。例えば、MME142は、WTRU102a、102b、102cのユーザを認証すること、ベアラをアクティブ化/非アクティブ化すること、WTRU102a、102b、102cの最初のアタッチ中に特定のサービングゲートウェイを選択することなどを担うことができる。MME142はまた、RAN104と、GSMやWCDMAなど他の無線技術を採用する他のRAN(図示せず)との間で切り替えるための制御プレーン機能を提供することができる。
サービングゲートウェイ144は、S1インタフェースを介してRAN104中の各eNB140a、140b、140cに接続されてよい。サービングゲートウェイ144は一般に、WTRU102a、102b、102cとの間でユーザデータパケットをルーティングおよび転送することができる。サービングゲートウェイ144はまた、eNB間ハンドオーバ中にユーザプレーンをつなぎ留めること、ダウンリンクデータがWTRU102a、102b、102cに利用可能なときにページングをトリガすること、WTRU102a、102b、102cのコンテキストを管理および記憶することなど、他の機能を実施することもできる。
サービングゲートウェイ144はまた、PDNゲートウェイ146にも接続されてよく、PDNゲートウェイ146は、インターネット110などのパケット交換ネットワークへのアクセスをWTRU102a、102b、102cに提供して、WTRU102a、102b、102cとIP対応デバイスとの間の通信を容易にすることができる。
CN106は、他のネットワークとの通信を容易にすることができる。例えば、CN106は、PSTN108などの回路交換ネットワークへのアクセスをWTRU102a、102b、102cに提供して、WTRU102a、102b、102cと従来の陸線通信デバイスとの間の通信を容易にすることができる。例えば、CN106は、CN106とPSTN108との間のインタフェースとしての働きをするIPゲートウェイ(例えばIPマルチメディアサブシステム(IMS)サーバ)を含むか、またはそのようなIPゲートウェイと通信することができる。加えて、CN106は、他のサービスプロバイダによって所有および/または運営される他の有線またはワイヤレスネットワークを含み得るネットワーク112へのアクセスを、WTRU102a、102b、102cに提供することができる。
LTEネットワークは、展開された第3世代パートナーシッププロジェクト(3GPP)ネットワークの次世代であろう。本明細書で述べられる概念は、LTEネットワークに限定されず、UMTS、GSM、CDMA2000など、他の3GPPネットワークにも適用可能とすることができる。
図2に、進化型UMTS地上無線アクセスネットワーク(E−UTRAN)205と進化型パケットコア(EPC)ネットワーク210とを含むLTEネットワーク200の大域的アーキテクチャの例を示す。E−UTRAN205は、複数のWTRU215、および進化型Node−B(eNB)220を含んでよい。eNB220は、無線管理などの機能を統合する基地局であってよい。EPCネットワーク210は、LTEネットワーク200のCN部分としての働きをすることができる。EPCネットワーク210は、WTRU215の全体的な制御、および、WTRU215とPDNゲートウェイ(P−GW)225との間のベアラの確立を担うことができる。ベアラは、WTRU215とP−GW225との間のパケットフローまたはトンネルであってよい。
EPCネットワーク210中のP−GW225は、オペレータのIPネットワークとの接続を保証するように構成されてよい。P−GW225は、WTRU215にIPアドレスを割り振ることを担うことができる。P−GW225はまた、ダウンリンクパケットを、種々のサービス品質(QoS)および宛先(WTRU)のベアラにフィルタリングすることができる。
EPCネットワーク210は、サービングゲートウェイ(S−GW)230を含んでよく、S−GW230は、WTRU215がeNB220から別のeNBに移動する(ハンドオーバ)ときに、データベアラのためのアンカとしての働きをすることができる。S−GW230はまた、WTRU215がアイドル状態である(すなわち、電力節約のためにオフに切り替えられて、それが使用する無線帯域幅を他のWTRUのために解放する)ときに、かつモビリティ管理エンティティ(MME)235がWTRU215とのベアラを再確立する間に、ダウンリンクベアラのデータを保持することができる。
MME235は、WTRU215とEPCネットワーク210との間のシグナリングを処理することを担うことができるので、LTEアーキテクチャ200中で重要な要素としての働きをすることができる。MME235は、ベアラ管理(確立、維持、および解放)に関係する機能、ならびに、アタッチおよび接続管理(EPCネットワーク210とWTRU215との間の接続およびセキュリティの確立、認証)に関係する機能を実施することができる。MME235は、WTRU215に関する情報を保持することによって、無線ネットワーク中のオーバヘッドを低減する助けとなることができ、これは、WTRU215がアイドル状態のときに継続性を確実にすることができる。これらの機能は、非アクセス層(NAS)プロトコル中のセッション管理レイヤによって扱われてよい。
ポリシ制御および課金規則機能(PCRF)240Aおよび240Bが、ポリシ制御施行機能(PCEF)中の、ポリシ制御決定とフローベースの課金機能の管理とを担うことができる。PCEFは、P−GW225中にあってよく、QoS情報(QoSクラス識別子(QCI)およびビットレート)を提供することができる。この情報は、あるデータフローがPCEF中で(P−GW225によって)どのように扱われ得るかを決定し、また、これがユーザの加入プロファイルに従うことを確実にすることができる。
WTRU上で実行される、人間対話を通常必要とする非MTCアプリケーションのいくつかは、ウェブを閲覧したり電子メールを読んだりするなど、より「伝統的な」使用事例に焦点を合わせるものである場合があるが、ソーシャルネットワーキングアプリケーションなど、新たに出現しつつある他のアプリケーションは、ユーザが出先で自分の友達と「つながったままでいる」ための助けとなることができる。モバイル非MTCデータアプリケーションの種々のカテゴリは、ウェブ閲覧、電子メール、天気/ニュース更新、ボイスオーバIP(VoIP)(例えばSkypeなど)、ソーシャルネットワーキング(Facebook)、ジオサービス(Google places/位置にターゲットを絞った広告)、オンラインゲーム、ならびにメッセージング(ショートメッセージサービス(SMS)およびインスタントメッセージング)を含み得る。
MTCアプリケーションは、人間対話を必ずしも必要としない自動化されたマシンまたはデバイス通信とすることができる。MTCアプリケーションは、今日、軍事応用例から民間応用例までの範囲にわたるほぼどんな日常生活応用例においても使用されることがあり、これらの応用例は、セキュリティ(アラームシステム、自動車/運転手セキュリティ)、トラッキングおよびトレーシング(フリート管理、注文管理、ナビゲーション、交通最適化/操舵)、支払い(販売時点、ゲーミングマシン)、ヘルスケア(バイタルサインの監視、リモート診断)、リモート保守/制御(センサ、照明、ポンプ、エレベータ制御)、計測(電力、ガス、水、グリッド制御)などである。これらのMTCアプリケーションは一般に、LTEネットワークなどの広く展開されたネットワークを通して、広いエリアにわたって配布される。
図3に、非MTC WTRU305およびMTC WTRU310上で実行される非MTCアプリケーションおよびMTCアプリケーションの一般的なアーキテクチャ300を示す。非MTC WTRU305およびMTC WTRU310は、外部ネットワーク320中にある複数のアプリケーションサーバ(AS)315のうちの1つと、LTEネットワーク325を介して通信することができる。
加入者が始めることができ意識していることができるネットワーク接続に加えて、いわゆるキープアライブメッセージの存在が、非MTC WTRU305とMTC WTRU310の両方の場合にあることがあり、キープアライブメッセージは、加入者に知られることなく発生する場合がある。MTC WTRU310の場合、アラームシステム、エレベータ制御、およびバイタルサイン監視をサポートするアプリケーションのいくつかは、MTC WTRU310がアライブかつ到達可能であることをAS315に通知する必要があることがある。非MTC WTRU305の場合、キープアライブメッセージを使用して、ユーザの(すなわち加入者の)ステータスの更新が提供されることがある(例えば「自分がどこにいるか」、「自分がIMメッセージに応答できる状態であるか」など)。これらのキープアライブメッセージは、非MTC WTRUが使用されていないように見えるときでも、アプリケーションがアクティブである限り、非MTC WTRU305によって絶えず送られるであろう。キープアライブメッセージは、データトラフィックについてはほとんど生成しないであろうが、膨大な量のシグナリングトラフィックを生成するであろうし、また非MTC WTRUの予想電池寿命にも影響を及ぼすおそれがある。したがって、キープアライブメッセージを送るのに必要とされるシグナリングトラフィックの量は、有意な量のデータが送られるデータセッションをセットアップするのに必要とされるシグナリングトラフィックの量と何ら違いはないであろう。以下、非MTC WTRUおよびMTC WTRUは、単にWTRUとして言及される。
図4に、キープアライブメッセージが電話機の電池をどれだけ消耗させるかに関する例を示す。図4には、様々な頻度を、WTRU上のバックライトがまる1時間にわたってオンに切り替えられる時間量と比較することによって、キープアライブメッセージの影響を示す。例えば、図4に示されるように、7.53時間(ほぼまる8時間の就業日)にわたる、毎分1つのキープアライブメッセージの頻度は、WTRUのバックライトを60分(まる1時間)にわたってオンに維持するのに必要とされるよりも多くのエネルギーを必要とすることがある。
キープアライブメッセージの頻度は、過剰な電池消耗による問題を呈するおそれがある。SkypeやFringなどのVoIPアプリケーションは、30秒ごとから8分ごとにキープアライブメッセージを生成することがある。ステータス更新メッセージの頻度も、同様の問題を呈するおそれがある。FindMeなどのソーシャルネットワーキングアプリケーションは、地理的位置の変化時にステータス更新メッセージを生成することがある。このようなメッセージの頻度は、1日にわたる散発的な頻度(例えば、家から職場へ、ジムへと変化し、次いで家に戻る)から、60分ごとまでの定期的な頻度までの範囲に及ぶことがある。ソーシャルネットワーキングサーバは、加入者の友達のコンテンツおよびプレゼンス更新メッセージを、WTRU上のアプリケーションにプッシュすることがある(例えば、Facebookは、自分の友達が特定の記事に「いいね」を表明したときまたは特定のグループの「ファンになった」ときに、アクティビティを投稿することがある)。このようなコンテンツおよびプレゼンス更新メッセージの頻度は、およそ数分ごとに推定されることがある。
ステータス更新およびキープアライブメッセージの影響を悪化させるおそれのある1つの側面は、これらのメッセージが、モバイルによって発信される(以下、モバイル発信)(MO)か、またはモバイルによって終端される(以下、モバイル終端)(MT)場合があることであり、例えば、定期的なFindMeメッセージは、友達の位置の変化から、またはWTRUユーザ自身の位置の更新からくる場合がある。別の側面は、複数のアプリケーションが単一のWTRUにインストールされることが普通にあり、その場合に各アプリケーションがこれらの更新/キープアライブメッセージを自律的に生成する場合があることである。
キープアライブまたはステータス更新メッセージの送信が完了したとき、およびユーザ非アクティブ性の検出時、WTRUは、WTRUの電池電力を節約するために、低電力状態に(例えば接続状態からアイドル状態に)移行されることがある。結果として、ステータス更新および/またはキープアライブメッセージの平均頻度が非アクティブ性タイマよりも高いとき、WTRUは、アイドル、ウェイクアップ、接続の再確立、更新メッセージの送信または受信、アイドルへの回帰、などの間で循環しなければならないことがある。
図5に、WTRUが頻繁なアイドル−アクティブ状態遷移の問題を経験するときのタイミングの例を示す。図5に(左から右へ)示されるように、WTRUは、いくらかのデータトラフィックの処理を完了した後、しばらくの間アクティブ状態505に留まり、次いでアイドル状態510に遷移して電池電力を温存することができる。WTRUがアイドル状態510に入ったすぐ後で、第1のアプリケーション5151が、更新メッセージ520を生成し、WTRUに対して、ウェイクアップしていくつかのシグナリングメッセージを送受信し接続を確立するようにさせることがある。WTRUは、アクティブ状態505だがメッセージを送っていないときよりも多くのエネルギーを、シグナリングメッセージの送受信で消費する可能性がある。接続を確立した後、WTRUは、更新メッセージ520を送り、アイドル状態510に移る前に再びしばらくの間アクティブ状態505に留まることができる。このサイクルは、他のアプリケーションもまた更新メッセージ520を送受信する(例えば、いくつかのMT更新メッセージが第2のアプリケーション5152によってプッシュされることがあり、いくつかのMO更新メッセージが第3のアプリケーション5153によって生成されることがある)間に、繰り返す。
WTRUがアクティブ状態とアイドル状態との間で絶えず転回するとき、観察され得る2つの問題がある。第1の問題は、これらの時折起こる非常に小さい更新メッセージを送るための、増大した制御プレーンシグナリング(この場合、過剰なシグナリングオーバヘッドがある(RAN中とCN中の両方で))であろう。わずか1つの更新メッセージを送るのに、1ラウンドのアイドル−アクティブ遷移を要することがあり、これはかなりのシグナリングオーバヘッドを課すことがある。このシグナリングオーバヘッドは、RAN中の複数の無線リソース制御(RRC)メッセージ(例えば、サービス要求、無線ベアラ確立/解放、および、メッセージがMTメッセージであるときのページング)、ならびにEPCシグナリングメッセージ(例えば、サービス要求、接続セットアップ/解放)を含む。第2の問題は、WTRUの短縮された電池寿命であろう。最悪のケースのシナリオでは、WTRUがアイドル状態510に入ったすぐ後で複数のアプリケーション515が更新メッセージを生成するとき、アクティブ状態505とアイドル状態510との間で絶えず転回することによって生成される場合のある余分なシグナリングのせいでWTRUのエネルギー消費が増加することがあり、WTRUがアクティブ状態505に留まった方が電力消費はよりよいことがある。
図6に、モバイルデータアプリケーションステータス更新およびキープアライブメッセージによって引き起こされる、シグナリング非効率性および短縮された電池寿命を生じさせる可能性のある頻繁なアイドル−アクティブ状態遷移シナリオの、問題シナリオと、問題の根源と、影響を受ける要素とを要約する。
WTRU上で実行される種々のアプリケーションからのステータス更新メッセージおよびキープアライブメッセージに関するシグナリングトラフィックを低減すること、ならびに、WTRUのエネルギー消費を低減してその電池寿命を延ばすことが望まれる。これらの目標を達成するために、WTRUがより長い期間にわたってアイドル状態に留まることが望まれる。加えて、WTRUがアクティブ状態のときにWTRUが複数の実行中アプリケーションの更新メッセージおよびキープアライブメッセージを受信および送信できるように、キープアライブメッセージをアプリケーションにまたがって同期させることが望まれる。結果として、WTRUは、アイドル状態と、接続の再確立と、メッセージの送受信と、アイドル状態への回帰との間で非常に頻繁に循環しなくてもよいであろう。固定された期間中の削減されたサイクル数は、WTRUの電池寿命を著しく延ばし、CNおよびRAN中のシグナリングトラフィックを低減することができる。
交渉および同期機能(NSF)と呼ばれる新しいネットワーク機能が、P−GW中またはP−GWと密接に結合されたノード中など、CNノード中にあってよい。P−GWは、CNの境界にあってよい。MOメッセージについては、NSFは、WTRUのトラフィックがP−GWの中を通って外部ネットワークに行きASに到達し得る場合の、WTRUの代理としての役割を果たすことができる。
NSFは、WTRU上の実行中アプリケーションのASと交渉して、WTRUがどれくらいの頻度で更新メッセージおよび/またはキープアライブメッセージを送る必要があるか決定することを担当することができる。次いでNSFは、交渉された頻度(複数可)をWTRUに通信することができる。交渉に基づいて、1つの頻度が全ての実行中アプリケーションについて同意される場合は、WTRUは、その実行中アプリケーションのキープアライブメッセージを、同期された方式で送ることができる。あるいは、1つの頻度が全ての実行中アプリケーションについて同意されることはないが、アプリケーションが種々の同意された頻度パラメータによりグループに分けられ得る場合は、WTRUは、実行中アプリケーションの各グループのキープアライブメッセージを、同期された方式で送ることができる。
NSFは、仮想キープアライブメッセージについてWTRUと交渉することを担当することができる。非常に低い頻度をASが求める場合、通常の状況では、WTRUは、キープアライブメッセージを一定ベースで送ることがあり、代理サーバは、頻度を低減することについてASと同意に達しないことがある。NSFは、より低い頻度のキープアライブメッセージをWTRUに要求することができるが、NSFは、キープアライブメッセージがどれくらい長く有効かを示すことができる。代理サーバは、ASが求める頻度で仮想キープアライブメッセージを送ることができる。他方、WTRUは、ASが知ることなくWTRUの代わりに仮想キープアライブメッセージを送るよう、P−GWに事前対策的に要求することができる。
WTRUは、NSFによって同意された頻度(複数可)に基づいて、そのアクティブ状態およびアクティブ期間を設定することができる。
バッファリングおよびキャッシング機能(BCF)と呼ばれる新しいネットワーク機能が、CN境界にあってよく、おそらくはP−GW中にあるかまたはP−GWに密接に結合されてよい。BCFは、種々のASからWTRUへのステータス更新メッセージをバッファリングすることを担当することができる。BCFは、WTRUをターゲットとするアプリケーションメッセージを、優先度または重みを有する種々のタイプに分類することができる。BCFは、WTRUのバッファ空間が一杯のときに、またはWTRUがアウェイクでありリッスンしていることがわかっている期間中に、メッセージがWTRUに送達されるのを許可することができる。特定のASからの更新メッセージが、バッファリングされることを許可されない場合、または高優先度として分類される場合は、メッセージはすぐにWTRUに向けて転送されてよく、WTRUは、メッセージを受け取れるようにページングされてよい。
BCFは、データ維持を担う。NSFは、制御を担当する。図7、8A、8B、9A、および9Bに、WTRUがアクセスおよびCNエンティティを介して種々のASと通信する全体的なアーキテクチャの、種々のオプションを示す。
図7に示されるように、NSF705とBCF710は両方とも、P−GW715中にあってよい。NSF705およびBCF710は、SGiインタフェース725を介して種々のAS720と通信することができ、S8インタフェース735を介してS−GW730と通信することができる。P−GW715は、インターネット740へのアクセスを提供する。
図8Aおよび8Bでは、BCF710はP−GW715中にあってよく、一方NSF705はPCRF805中にあってよい。図8Aには、MTCシナリオと非MTCシナリオの両方に適するであろうアーキテクチャおよび参照ポイントを示す。BCF710は、SGi725を介してAS720と通信することができ、一方NSF705は、Rx810を介してAS720と通信することができる。図8Bには、MTCシナリオの場合のアーキテクチャおよび参照ポイントを示すが、この場合、NSF705は、参照ポイントを介して(Rx810を介して)MTC−IWF815と通信することができる。MTC−IWF815は、Tsp825を介してサービス能力サーバ(SCS)820と通信することができる。BCF710は、SGi725を介してSCS820と通信することができる。
図9Aおよび9Bに、NSF705およびBCF710が、交渉およびキャッシングゲートウェイ(NC−GW)900と呼ばれる新しいスタンドアロンノード中にあるのを示す。図9Aには、NC−GW900が、新たに定義されたSnインタフェース905によってS−GW730と対話し、新たに定義されたインタフェースNi910を介して種々のAS720と対話し、新たに定義されたインタフェースGn915によってP−GW715と対話し、新たに定義されたインタフェースNx920によってPCRF805と対話するのを示す。
図9Bでは、NC−GW900は、新たに定義されたインタフェースGn915によって、P−GW715とのみ直接に対話することができるが、P−GW715を介して、S−GW730、PCRF805、およびインターネット740と間接的に通信することができる。
BCFは、WTRUに関係する以下の情報を維持することを担当することができる。すなわち、アクティブおよびアイドルスケジュールと、実行中のアプリケーションと、種々のASからの、WTRUをターゲットとするメッセージ(更新メッセージなど)とである。実行中の各アプリケーションは、そのポート識別(ID)によって識別されることが可能である。各アプリケーションにつき、関連するASに定期的なキープアライブメッセージをアプリケーションが送る必要があるかどうかを示すアプリケーション特有の属性およびメッセージが、キャッシュされバッファリングされる。アプリケーションが定期的なキープアライブメッセージを送る必要がある場合は、時間に伴って変化する場合のある頻度、ならびに、キープアライブメッセージの送信先である関連するASが、示されてよい。この情報は、宛先トランスポートアドレス(例えばIPアドレス/ポートID)として記憶されてよい。アプリケーションが定期的なキープアライブメッセージを送る必要がある場合は、最新のキープアライブメッセージがキャッシュされてよい。
WTRUが、延長された間欠受信(DRX)サイクルをサポートするように構成された場合、または1日のうちのいくつかの時点で通信するようにプロビジョニングされた場合は、BCFは、WTRUのアクティブ/アイドルスケジュールを、ホーム加入者サーバ(HSS)、MME、またはSCSから取得することができる。あるいは、アクティブおよびアイドルスケジュールは、各WTRUに向けてP−GWによって転送されるメッセージから推論されてもよい。WTRUは、WTRUからASへのメッセージをP−GWが受け取ったときにアクティブであるものとすることができる。したがって、BCFは、WTRUから発信されたメッセージを受け取った時間をキャッシュすることができる。結果として、P−GWの中を通るトラフィックを有する各WTRUにつき、BCFは、図10に示されるように、WTRUから発信されP−GWによって転送されるメッセージの属性を記録することができる。P−GWはまた、WTRUがP−GWに事前対策的に知らせることによって、またはASから取り出すによって、アクティブおよびアイドル状態スケジュールを得ることもできる。
WTRU上の実行中の各アプリケーションにつき、BCFは、図11に示されるように、アプリケーションに関係する、ステータス、属性、モバイル発信(MO)または/およびモバイル終端(MT)メッセージを維持することができる。この情報は、制御のためにNSFによって利用されてよい。
NSFは、以下の機能を有する。すなわち、元のMOキープアライブメッセージ頻度情報照会、MOキープアライブメッセージ頻度交渉および解決、MOキープアライブメッセージ頻度更新、MOキープアライブメッセージ削減、ならびに、MTメッセージバッファリングおよび優先である。
WTRUに対して、NSFは、種々の実行中アプリケーションについてASによって必要とされるキープアライブメッセージの頻度を収集することができる。この情報は、NSFによって要求されてBCFから取り出されてよい。図12の情報に基づいて、NSFは、「常に実行中」のアプリケーションがキープアライブメッセージを種々のASに送ることができるように、WTRU上で実行されるアプリケーションをフィルタにかけることができる。したがって、NSFは、キープアライブメッセージ頻度、ならびにこれらのアプリケーションの関連ASのコンタクトアドレスを取り出すことができる。P−GWの中を通るトラフィックを有する各WTRUにつき、NSFは、図12に示される情報を使用して、以下のプロシージャを実施することができる。
図13に、キープアライブメッセージ頻度交渉要求メッセージ1300を示す。NSFは、要求メッセージ1300をこれらの関連ASに送って、実行中の各アプリケーションのより適切な頻度を求めてWTRUに代わって交渉することができる。より適切な頻度は、WTRUがキープアライブメッセージを送る先となるであろう種々のASによってこの頻度が同意され得ることを示すものとすることができる。要求メッセージ1300は、メッセージ識別子(ID)1305、WTRU ID1310、アプリケーション数を示すフィールド1315、アプリケーションIDフィールド13201,13202,...,1320n、キープアライブメッセージ頻度フィールド13251,13252,...,1325n、および、提案される頻度(以下、提案頻度)を示すフィールド1330を含んでよい。
メッセージIDは、応答メッセージ1400を要求メッセージ1300にマッチさせるためにエコーされてよい。アプリケーション数フィールド1315は、後続の、アプリケーションIDと頻度との組合せの数を示すことができる。NSFが提案する最適な頻度は、現在の頻度の全てのうちの最大とすることができる。要求メッセージ1300は、関係するASにマルチキャストまたはユニキャストされてよい。要求メッセージ1300をマルチキャストすることをNSFが選んだ場合は、要求メッセージ1300は、図13に示されるようなフォーマットを有することができる。要求メッセージをユニキャストすることをNSFが選んだ場合は、要求メッセージ1300は、宛先ASに対応するであろうアプリケーションIDフィールド1320およびアプリケーション頻度フィールド1325を含まなくてよい。例えば、特定のASに送られるであろう頻度交渉要求メッセージ1300から、フィールド13201および13251が除去されてよい。特定のASは、それ自体のデータベースからのWTRU IDおよびアプリケーションIDに基づいて、頻度を見出すことができるであろう。したがって、要求メッセージ1300のサイズ、および要求メッセージ1300を送信するための帯域幅使用量が削減されることが可能である。しかし、ユニキャスティング送信が使用されるかマルチキャスティング送信が使用されるかにかかわらず、要求メッセージ1300中の全てのアプリケーションIDおよび頻度が含まれてもよい。
アプリケーションごとの頻度パラメータが、P−GWによって、それが転送および検分したキープアライブメッセージから推論されてよいが、この頻度パラメータは、ASがそのデータベースに保持する頻度パラメータと全く同じではない可能性がある。したがって、一見重複する情報を使用して、P−GWがアプリケーションごとの正しい頻度パラメータを知るかどうか検証することができる。ASは、値を、ローカルに記憶された値と比較し、正しい値をP−GWに通知することが可能とすることができる。P−GWは、パラメータを訂正し、その頻度推論アルゴリズムを将来の使用に向けて調整することができる。
ASが頻度交渉要求メッセージ1300を受け取ったとき、ASは、WTRU上の全ての実行中アプリケーションのキープアライブメッセージ頻度ならびにNSFからの提案頻度の情報を、取り出すことができる。ASはまず、それ自体のアプリケーションについて必要とする頻度の正しさをチェックし、そのデータベース中のパラメータと比較することができる。正しい場合は、有効コードが応答メッセージに含められてよい。そうでない場合は、無効コードおよび正しいパラメータが含められてよい。ASはまた、提案頻度をチェックして、受諾できるかどうか確認することができる。WTRU上のアプリケーションが提案頻度でキープアライブメッセージを送ることをASが許可できる場合は、この頻度は、応答メッセージ中の提案頻度フィールド中でエコーされてよい。そうでない場合は、ASは、要求メッセージ中の他のアプリケーションの頻度を調べ、それ自体の提案頻度を案出することができる。ASは、元の頻度に固執することもでき、または、他のアプリケーションの頻度とNSFからの提案頻度とを入力として、そのプロプラエタリアルゴリズムを使用することもできる。
図14に、キープアライブメッセージ頻度交渉応答メッセージ1400を示すが、このキープアライブメッセージ頻度交渉応答メッセージ1400は、メッセージIDフィールド1405、アプリケーションIDフィールド1410、コードフィールド1415、頻度フィールド1420、および、提案頻度範囲を示すフィールド1425を含む。メッセージIDフィールド1405は、対応する要求メッセージ1300中のメッセージIDフィールド1305と同じであってよく、マッチングを実施するためにNSFにエコーバックされてよい。アプリケーションIDフィールド1410は、ASが関連付けられているアプリケーションを示すことができる。コードフィールド1415は、要求メッセージ1300に含まれるこの特定のアプリケーションの頻度が有効か否かを示すことができる。無効である場合は、頻度フィールド1420は、正しいパラメータを含んでよい。そうでない場合は、コードフィールド1415は含まれなくてよい。フィールド1425は、ASが要求メッセージ1300中の情報を入力としてそのプロプラエタリアルゴリズムを実行した後で許可する、頻度範囲を示すことができる。
図15に、MOキープアライブメッセージ頻度交渉要求メッセージ1505および応答メッセージ1510のメッセージフロー1500を示す。要求メッセージ1505は、関係する各ASにマルチキャストされるかまたはユニキャストされてよく、応答メッセージ1510は別々に返されてよい。NSF1515が複数のアプリケーションサーバ(AS)15201,15202,...,1520nからの全ての応答メッセージ1510を収集した後、NSF1515は、コードおよび提案頻度範囲に基づいて、理想的なシナリオで全てのAS1520によって受諾可能な頻度を選ぶことができる。NSF1515は、同意された頻度を含む頻度交渉確認メッセージ1525を、各AS1520に送ることができる。
WTRU上の1つの実行中アプリケーションに関連するあらゆるASは、WTRUが同じ頻度でキープアライブメッセージを送るのを可能にすることができる。このシナリオの下では、WTRUは、そのアライブおよびアイドルスケジュールを、同意された頻度に基づかせることができ、定期的にアクティブになって、アクティブ期間中に全ての実行中アプリケーションのキープアライブメッセージを送ることができる。
あるいは、NSFは種々のASからの応答を受け取ることができるが、複数の頻度が同意される。このシナリオの下では、実行中アプリケーションはグループに分けられてよく、各グループは、各グループに関連するそれぞれのアプリケーションサーバ全てが従う必要のあるキープアライブメッセージ頻度を有する。
別のシナリオでは、あらゆるASは、NSFとのどんな交渉への参加も拒否することができる。このシナリオの下では、全ての実行中アプリケーションは、元の必要とされる頻度に従って、キープアライブメッセージを各ASに送ることができる。
図16に、複数のアプリケーションおよび頻度1,2,...,xを識別する、更新済み頻度通知メッセージ1600を示す。
図17に、WTRU1705およびNSF1710によって実施される更新済み頻度通知プロシージャ1700のメッセージフローを示す。NSF1710は、更新済み頻度通知メッセージ1600をWTRU1705に送ることができる。WTRU1705上の各アプリケーションの頻度属性が、NSF1710によって相応に更新されてよい。これに応答して、WTRU1705は、肯定応答(ACK)メッセージ1715をNSF1710に送って、各アプリケーション(1,2,...,x)がそのMOキープアライブメッセージ頻度を更新済み頻度通知メッセージ1600に基づいて調整したことを確認することができる。
図18は、モバイル発信(MO)キープアライブメッセージ頻度交渉および更新プロシージャ1800の流れ図である。交渉および同期機能(NSF)が、WTRUに代わって、MOキープアライブメッセージ頻度交渉要求を複数のアプリケーションサーバに送ることができる(1805)。NSFおよびアプリケーションサーバは、MOキープアライブメッセージ頻度交渉および解決プロシージャを実施することができ、それにより、全てのアプリケーションサーバが1つのMOキープアライブメッセージ頻度に同意することができるか、または、全てのアプリケーションサーバが複数のMOキープアライブメッセージ頻度に同意することができ、アプリケーションサーバはグループに分けられる(1810)。WTRU上で、既存のアプリケーションが終了するたびに、またはキープアライブメッセージを必要とする新しいアプリケーションが起動されるたびに、NSFは、1または複数のキープアライブメッセージ頻度の更新を管理することができる(1815)。
図19に、メッセージIDフィールド1905および提案頻度フィールド1910を含む、簡略化された頻度交渉要求メッセージ1900の例を示す。
図20は、1つのMOキープアライブメッセージ頻度が複数のアプリケーションサーバによって同意されるときの頻度更新プロシージャ2000の流れ図の例である。結果として、キープアライブメッセージを送ることが必要とされる現在の実行中アプリケーションは、同意された頻度でそれらを送ることができる。アプリケーションが終了した場合は、アプリケーションが終了したことを反映するように、BCFに記憶されたアプリケーションのステータスが変更されてよい。同意された頻度パラメータは影響を受けないものとすることができる。WTRU上で起動された新しいアプリケーションがある場合は、BCFは、アプリケーションの元の頻度を推論および記録することができる。
図20を引き続き参照するが、現在実行中のアプリケーションに加えて、新しいアプリケーションAPPNEWが、WTRU上で実行を始めることができる(すなわち起動されてよい)(2005)。NSFが、APPNEWのMOキープアライブメッセージ頻度(FNEW)を、アプリケーションサーバの現在のグループによって前に同意された1つの頻度(FAGREED)と比較することができる(2010)。比較2010の結果、FNEWはFAGREEDよりも大きい(2015)か、FNEWはFAGREEDよりも小さい(2020)か、またはFNEW=FAGREED(2025)である場合がある。
図20に示されるように、NSFは、提案頻度をFNEWに設定し、現在のグループ中のアプリケーションサーバに頻度交渉要求メッセージを送ることができる(2030)。現在のグループ中の全てのアプリケーションサーバが提案頻度(FNEW)に同意する(2035)という条件で、新しいアプリケーションサーバは現在のグループに追加されてよい(2040)。現在のグループ中の全てのアプリケーションサーバが提案頻度(FNEW)に同意しない(2035)という条件で、NSFは、提案頻度をFAGREEDに設定し、APPNEWをサポートする新しいアプリケーションサーバに頻度交渉要求メッセージを送ることができる(2045)。新しいアプリケーションサーバが提案頻度(FAGREED)に同意する(2050)という条件で、新しいアプリケーションサーバは現在のグループに追加されてよい(2040)。新しいアプリケーションサーバが提案頻度(FAGREED)に同意しない(2050)という条件で、2つの新しいアプリケーションサーバグループが確立されてよく、一方はFAGREEDで実行されるグループであり、他方はFNEWで実行されるグループである。
比較2010の結果、FNEWがFAGREEDよりも大きい(2015)ときは、NSFは、提案頻度を、新しいアプリケーション(APPNEW)の頻度に設定し、関係するアプリケーションサーバに頻度交渉要求メッセージを送ることができる(図15の1505参照)。アプリケーション間の同意された頻度があるので、頻度交渉要求メッセージ1505は、図19のメッセージ1900に描かれるように、メッセージID1905および提案頻度1910のみを含むように簡略化されてよい。提案頻度が全てのアプリケーションサーバによって同意されない場合は、NSFは、提案頻度を古い同意された頻度に設定し、新しいアプリケーションに関連するASに、頻度交渉メッセージを送ることができる。このプロシージャは、WTRUがより高い速度でキープアライブメッセージを新しいアプリケーションサーバに送れることをNSFが提案することを、示すことができ、したがって、WTRUは常に、同じ頻度でウェイクアップして、新しいアプリケーションサーバを含めた全てのアプリケーションサーバにキープアライブメッセージを送る。新しいアプリケーションサーバは、不要なキープアライブメッセージを扱いたくないなどの理由で、提案頻度を拒否することができる。このシナリオが発生した場合、アプリケーション(アプリケーションサーバ)は、2つのグループに分けられてよい。第1のグループは、引き続き、古い同意された頻度に従うことができる。第2のグループは、新しい頻度(これは新しいアプリケーションサーバの頻度である)に従うことができ、このグループは新しいアプリケーションを含む。
比較2010の結果、FNEWがFAGREEDよりも小さい(2020)ときは、NSFは、提案頻度を、古い同意された頻度に設定し、簡略化された頻度交渉要求メッセージを新しいアプリケーションサーバに送ることができる。新しいアプリケーションサーバが提案頻度を受諾する場合は、新しいアプリケーションを含めた全てのアプリケーションは、1つの同意された頻度を有することができる。そうでない場合は、アプリケーション(アプリケーションサーバ)は、2つのグループに分けられてよい。第1のグループは、引き続き、古い同意された頻度に従うことができ、現在の(古い)アプリケーション全てを含むことができる。第2のグループは、新しい頻度(これは新しいアプリケーションの頻度である)に従うことができ、このグループは新しいアプリケーションのみを含むことができる。
比較2010の結果、FNEW=FAGREEDである(2025)ときは、頻度が同意された頻度と同じである場合は何も更新または変更される必要はなくてよい。
図21A、21B、および21Cは共に、複数のMOキープアライブメッセージ頻度が複数のアプリケーションサーバによって同意されてグループに分けられるときの、頻度更新プロシージャ2100の流れ図の例である。
図21Aを参照すると、複数のアプリケーションサーバグループが確立されてよく、各グループは、WTRU上でそれぞれのMOキープアライブメッセージ頻度で現在実行されている少なくとも1つのアプリケーションに関連する(2105)。新しいアプリケーションAPPNEWが、WTRU上で実行を始めることができる(すなわち起動されてよい)(2110)。NSFが、APPNEWのMOキープアライブメッセージ頻度(FNEW)を、アプリケーションサーバグループに関連するアプリケーションのそれぞれの頻度(FGROUPS)と比較することができる(2115)。比較2115の結果、FNEWはFGROUPSよりも大きい(2120)か、FNEWはFGROUPSよりも小さい(2125)か、FNEWはFGROUPSのうちの1つと等しい(2130)か、またはFNEWはFGROUP-LESSよりも大きくFGROUP-MOREよりも小さい(2135)場合がある。FGROUP-LESSおよびFGROUP-MOREは、アプリケーションサーバが動作する際のMOキープアライブメッセージ頻度の、頻度下限および上限である。
図21Aおよび21Bを参照すると、比較2115の結果、FNEWがFGROUPSよりも大きい(2120)ときは、NSFは、提案頻度をFNEWに設定し、最も高い頻度(FGROUP-MAX)で実行されているアプリケーションサーバのグループ(APPGROUP-MAX)に頻度交渉要求メッセージを送ることができる(2140)。グループ中の全てのアプリケーションサーバが提案頻度(FNEW)に同意する(2145)という条件で、APPNEWをサポートする新しいアプリケーションはAPPGROUP-MAXに追加されてよい(2150)。グループ中の全てのアプリケーションサーバが提案頻度(FNEW)に同意しない(2145)という条件で、NSFは、提案頻度をFGROUP-MAXに設定し、APPNEWをサポートする新しいアプリケーションサーバに頻度交渉要求メッセージを送ることができる(2155)。新しいアプリケーションサーバが提案頻度(FGROUP-MAX)に同意する(2160)という条件で、APPNEWをサポートする新しいアプリケーションはAPPGROUP-MAXに追加されてよい(2150)。新しいアプリケーションサーバが提案頻度(FGROUP-MAX)に同意しない(2160)という条件で、2つの新しいアプリケーションサーバグループが確立されてよく、一方はFGROUP-MAXで実行されるグループであり、他方はFNEWで実行されるグループである(2165)。
図21Aを参照すると、比較2115の結果、FNEWがFGROUPSよりも小さい(2125)ときは、NSFは、提案頻度を、アプリケーションサーバグループ(APPGROUP-MIN)の最も低いMOキープアライブメッセージ頻度(FGROUP-MIN)に設定し、APPNEWをサポートする新しいアプリケーションサーバに頻度交渉要求メッセージを送ることができる(2170)。新しいアプリケーションサーバが提案頻度(FGROUP-MIN)に同意する(2172)という条件で、新しいアプリケーションサーバはAPPGROUP-MINに追加されてよい(2174)。新しいアプリケーションサーバが提案頻度(FGROUP-MIN)に同意しない(2172)という条件で、2つの新しいアプリケーションサーバグループが確立されてよく、一方はFGROUP-MINで実行されるグループであり、他方はFNEWで実行されるグループである(2176)。
図21Aおよび21Cを参照すると、比較2115の結果、FNEWがFGROUP-LESSよりも大きくFGROUP-MOREよりも小さい(2135)ときは、NSFは、提案頻度を、FNEWよりも高いアプリケーションサーバグループ(APPGROUP-MORE)のMOキープアライブメッセージ頻度(FGROUP-MORE)に設定し、APPNEWをサポートする新しいアプリケーションサーバに頻度交渉要求メッセージを送ることができる(2178)。新しいアプリケーションサーバが提案頻度(FGROUP-MORE)に同意する(2180)という条件で、新しいアプリケーションサーバはAPPGROUP-MOREに追加されてよい(2182)。新しいアプリケーションサーバが提案頻度(FGROUP-MORE)に同意しない(2180)という条件で、NSFは、提案頻度をFNEWに設定し、FNEWよりも低いMOキープアライブメッセージ頻度(FGROUP-LESS)で実行されているアプリケーションサーバのグループ(APPGROUP-LESS)に頻度交渉要求メッセージを送ることができる(2184)。グループ「less」中の全てのアプリケーションサーバが提案頻度(FNEW)に同意する(2186)という条件で、新しいアプリケーションサーバは、FNEWで実行されるグループ「less」に追加されてよい(2188)。グループ「less」中の全てのアプリケーションサーバが提案頻度(FNEW)に同意しない(2186)という条件で、新しいアプリケーションサーバのみを含む新しいグループが追加されてよい(2190)。
図21Aを参照すると、比較2115の結果、FNEWがFGROUPSのうちの1つと等しい(2130)ときは、APPNEWをサポートする新しいアプリケーションサーバは、FNEWで実行されているアプリケーションサーバのグループに追加されてよい(2192)。
現在のアプリケーションサーバが、グループに分けられてよい(最も望まれないシナリオは、それぞれが1つのアプリケーションを含む複数のアプリケーションサーバグループがあることである)。各グループ中のアプリケーションサーバは、同じ頻度に従うことができる。NSFは、新しいアプリケーションのキープアライブメッセージ頻度を、既存のグループに関連するアプリケーションの頻度と比較することができる。
比較2115の結果、FNEWがFGROUPSよりも大きい(2120)ときは、NSFは、提案頻度を新しい頻度に設定し、最も高い頻度を有するアプリケーションサーバ(GroupMaxとして表される)に頻度交渉要求メッセージを送り、新しいより高い頻度に同意するようにこれらのアプリケーションサーバとの交渉を試みることができる。他のグループ中のアプリケーションサーバは、この交渉要求メッセージに含まれなくてよい。というのは、古い最も高い頻度は、前の交渉で他のグループによって拒否されたはずだからである。
あるシナリオでは、GroupMax中のアプリケーションサーバに関連する全てのアプリケーションと、新しいアプリケーションとは、提案頻度に同意することができる。別のシナリオでは、GroupMax中のアプリケーションサーバに関連するアプリケーションと、新しいアプリケーションとは、2つの新しいグループに分けられてよく、一方は古い最も高い頻度のグループであり、他方は新しい頻度のグループである。
比較2115の結果、FNEWがFGROUPSよりも小さい(2125)ときは、NSFは、提案頻度を、最も低い頻度(GroupMin)に設定し、新しいアプリケーションに関連する新しいアプリケーションサーバに、簡略化された交渉要求メッセージを送ることができる。新しいアプリケーションサーバが提案頻度を受諾する場合は、GroupMin中のアプリケーションサーバと、それに加えて新しいアプリケーションサーバとは、1つの同意された頻度を有することができ、新しいアプリケーションサーバはGroupMinに割り当てられてよい。そうでない場合は、1つの新しいグループが生み出されてよく、このグループは、新しいアプリケーションサーバのみを含む。
FNEWがFGROUP-LESS(最も低い頻度)よりも大きくFGROUP-MORE(最も高い頻度)よりも小さい(2135)ときは、NSFは、提案頻度をFGROUP-MOREに設定し、新しいアプリケーションサーバに、簡略化された頻度交渉要求メッセージを送ることができる。新しいアプリケーションサーバが提案頻度に同意する場合は、新しいアプリケーションサーバはグループ「more」に割り当てられてよい。新しいアプリケーションサーバが提案頻度を拒否する場合は、NSFは、提案頻度をFNEWに設定し、グループ「less」中の全てのアプリケーションサーバに頻度交渉要求メッセージを送ることができる。グループ「less」中の全てのアプリケーションサーバが提案頻度に同意する場合は、新しいアプリケーションサーバは、グループ「less」に割り当てられてよく、グループ「less」の頻度は、FNEWに変更されてよい。同意に達しない場合は、新しいアプリケーションサーバのみを含む新しいグループが追加されてよい。
FNEWがFGROUPSのうちの1つと等しい(2130)ときは、新しいアプリケーションサーバは、対応するグループに入れられてよい。
最適化方式がNSFによって提供されてよく、NSFは、WTRUの代理サーバとしての役割を果たすことができる。代理サービスは、NSFによって事前対策的に提供されてもよく、または、ASもしくはWTRUによって要求されてもよい。第1のシナリオは、NSFが、代理サービスをWTRUに提供しようと事前対策的に望むことができ(または代理サービスはASによって要求されてもよい)、WTRUがサービスを受諾することができるというものである。他方、第2のシナリオは、WTRUが、それに代理サービスを提供するようNSFに要求することができるというものである。NSFは、WTRUからの要求を受諾することができる。
各アプリケーションが、そのアプリケーションからの1つのキープアライブメッセージが複数のメッセージとして機能することをNSFに対して保証できるという条件下で、NSFは、全ての実行中アプリケーションについて同じ頻度でキープアライブメッセージを送るようWTRUと交渉を試みることができる。例えば、前述のプロシージャから、NSFとアプリケーションサーバとの間の同意された頻度は6秒、10秒、および15秒である場合がある。したがって、このWTRU上の全ての実行中アプリケーションに対して、NSFが観察できる最も望まれる同期された頻度は30秒である。
NSFは、6秒グループ中のアプリケーションに、30秒の頻度でキープアライブメッセージを送るよう要求することができるが、次の5つの6秒スロット中でそれがアライブであることを保証することができる。同様に、NSFは、10秒グループ中のアプリケーションに、30秒の頻度でキープアライブメッセージを送るよう要求することができるが、次の3つの10秒スロット中でそれがアライブであることを保証することができ、15秒グループ中のアプリケーションに、30秒の頻度でキープアライブメッセージを送るよう要求することができるが、次の2つの15秒スロット中でそれがアライブであることを保証することができる。NSFは、WTRUの代理となって、これらのグループ中の各アプリケーションの仮想キープアライブメッセージを、ASが必要とするのと同じフォーマットおよび頻度に従って送ることができる。
図22に、NSFによってWTRUに送られるMOキープアライブメッセージ削減要求メッセージ2200の例を示す。図23に、WTRUによって送られるMOキープアライブメッセージ削減応答メッセージ2300の例を示す。図22および23に示されるように、メッセージIDフィールド2205および2305を使用して、MOキープアライブメッセージ削減要求メッセージ2200とMOキープアライブメッセージ削減応答メッセージ2300とをマッチさせることができる。「グループ数」フィールド2210および2310は、実行中のアプリケーションが何個のグループに分けられるかを示すことができる。各グループにつき、1つのグループIDフィールド2215および関連する「アプリケーション数」フィールド2220があってよい。WTRU上で実行されている各アプリケーションにつき、アプリケーションIDフィールド2225があってよい。提案頻度フィールド2230は、全てのグループの同意された頻度の最小公倍数であってよい。
WTRUがMOキープアライブメッセージ削減要求メッセージ2200を受け取ったとき、WTRUは、全ての関係するアプリケーションに対して、新しい頻度を認識して相応に更新するようにさせることができる。これには、隣接する2つのキープアライブメッセージが送出されている間にアプリケーションがアライブであることをアプリケーションが保証する必要があるであろう。アプリケーションがこの保証をすることができない場合、アプリケーションは拒否応答でP−GWに答えることができる。結果として、MOキープアライブメッセージ削減応答メッセージ2300は、アプリケーションが新しい頻度を受諾するか拒否するかを示すことのできる受諾/拒否(a/r)フィールド2315、ならびに複数のアプリケーションIDフィールド2320を含んでよい。
MOキープアライブメッセージ削減要求メッセージ2200中の全てのアプリケーションが新しい頻度を受諾する場合、グループは、NSFによって管理される1つのグループにマージされてよい。
図24に、NSFによって開始されるMOキープアライブメッセージ削減プロシージャの例示的なメッセージフローを示す。BCFは、NSFによってこれらのアプリケーションについて送られる仮想キープアライブメッセージの数を維持することができ、この数から、NSFは、何個の仮想キープアライブメッセージがアプリケーションに代わってアプリケーションサーバに送られてよいかを知る。仮想キープアライブメッセージは、それがWTRUからアプリケーションによって送られるかのように、BCF中でキャッシュされた最新の本物のキープアライブメッセージと同じフォーマットを有することができる。アプリケーションのいくつかが拒否で返答した場合、これらのアプリケーションは、古いグループに留まることができる。他のアプリケーションは、新しい頻度を有する新しいグループに移行されてよい。
図25に、WTRUによって送られるMOキープアライブメッセージ削減要求メッセージ2500の例を示す。WTRUは、NSFとアプリケーションサーバとの間で頻度交渉または更新プロシージャがあるかどうかにかかわらず、任意の時点でMOキープアライブメッセージ削減要求メッセージ2500をNSFに送ることができる。WTRUは、1または複数のアプリケーションについて、特定の提案頻度(複数可)を含むMOキープアライブメッセージ削減要求メッセージ2500をNSFに送ることができる。提案頻度は、元の値の倍数であってよい。例えば、アプリケーションの元のキープアライブメッセージ頻度が、ASによって最初に必要とされるものであろうと、またはNSFとアプリケーションサーバとの間で交渉されてアプリケーションにプロビジョニングされるものであろうと、この元の頻度が5秒である場合、この削減要求メッセージ中の提案頻度は、10、15、20、30など、5の倍数であってよい。
図26に、WTRUによって開始されるMOキープアライブメッセージ削減プロシージャの例示的なメッセージフローを示す。キープアライブメッセージ削減応答メッセージ2300は、図23に示されるものと同様である。アプリケーションが「受諾」応答をNSFから受け取った後、アプリケーションは、キープアライブメッセージを提案頻度で送ることができる。NSFは、WTRUに代わって、アプリケーションサーバが必要とする頻度で仮想キープアライブメッセージを送ることができる。
NSFは、種々のアプリケーションサーバからの、WTRUをターゲットとするメッセージ(MTメッセージ)を、優先度または重みを有する種々のタイプに分類することができる。MTメッセージの優先度または重みは、アプリケーションの優先度属性から、または他の何らかの要因から導出されてよい。前述のプロシージャを実行することによって、NSFは、いつWTRUがアイドル状態からアクティブであり得るかを知って、キープアライブメッセージを送ることができる。WTRUをできるだけアイドル状態に維持するために、NSFは、WTRUがアクティブである期間中にMTメッセージ送信をトリガすることができる。バッファリングされたMTメッセージは、優先度の高い順に送られる規則に従って送られてよい。MTメッセージのいくつかが、遅延されることが不可能な非常に高い優先度または重みを有する場合は、これらのメッセージは、WTRUのステータスにかかわらず送られてよく、WTRUはアイドル状態からアクティブ状態にウェイクされてよい。
実施形態
1.コアネットワーク中のノードによって実施される、それぞれのアプリケーションに関連するアプリケーションサーバとキープアライブメッセージ頻度を交渉する方法であって、
ノードがモバイル発信(MO)キープアライブメッセージ頻度交渉要求メッセージを複数のアプリケーションサーバに送ること、および、
ノードがMOキープアライブメッセージ頻度交渉応答メッセージをアプリケーションサーバから受け取ることを含む方法。
1.コアネットワーク中のノードによって実施される、それぞれのアプリケーションに関連するアプリケーションサーバとキープアライブメッセージ頻度を交渉する方法であって、
ノードがモバイル発信(MO)キープアライブメッセージ頻度交渉要求メッセージを複数のアプリケーションサーバに送ること、および、
ノードがMOキープアライブメッセージ頻度交渉応答メッセージをアプリケーションサーバから受け取ることを含む方法。
2.ノードが、ワイヤレス送受信ユニット(WTRU)上で実行しおよびアプリケーションサーバに関連するアプリケーションによって送られるキープアライブメッセージの頻度を交渉することをさらに含む、実施形態1の方法。
3.ノードは、WTRUをターゲットとするアプリケーションメッセージを、優先度または重みを有する種々のタイプに分類するように構成されたバッファを備える、実施形態2の方法。
4.ノードがWTRUにメッセージを送ることをさらに含み、メッセージは、交渉された頻度よりも低い頻度でキープアライブメッセージを送るようWTRUに要求し、かつ、どれくらい長くキープアライブメッセージが有効かを示す、実施形態1〜3のいずれか1つにおける方法。
5.アプリケーションサーバの全ては、共通のMOキープアライブメッセージ頻度に同意し、アプリケーションは、同意されたMOキープアライブメッセージ頻度でキープアライブメッセージを送る、実施形態1〜4のいずれか1つにおける方法。
6.MOキープアライブメッセージ頻度交渉要求メッセージの各々は、メッセージ識別子フィールドと、WTRU識別子フィールドと、アプリケーション数を示すフィールドとを含む、実施形態1〜5のいずれか1つにおける方法。
7.MOキープアライブメッセージ頻度交渉要求メッセージの各々は、複数のアプリケーション識別子フィールドと、複数のキープアライブメッセージ頻度フィールドと、提案頻度フィールドとをさらに含む、実施形態1〜6のいずれか1つにおける方法。
8.MOキープアライブメッセージ頻度交渉応答メッセージの各々は、メッセージ識別子フィールドと、少なくとも1つのアプリケーション識別子フィールドと、少なくとも1つのキープアライブメッセージ頻度フィールドと、提案頻度範囲を示すフィールドとを含む、実施形態1〜7のいずれか1つにおける方法。
9.MOキープアライブメッセージ頻度交渉応答メッセージの各々は、アプリケーション頻度が有効か無効かを示すコードフィールドをさらに含む、実施形態1〜8のいずれか1つにおける方法。
10.ノードは、アプリケーションサーバによってWTRUに送られたキープアライブメッセージおよびステータス更新メッセージをバッファリングするように構成されたバッファをさらに備える、実施形態1〜9のいずれか1つにおける方法。
11.ノードが、同意された頻度を示すMOキープアライブメッセージ頻度交渉確認メッセージをアプリケーションサーバに送ることをさらに含む、実施形態1〜10のいずれか1つにおける方法。
12.ノードは、パケットデータネットワークゲートウェイと、交渉およびキャッシングゲートウェイと、サービングゲートウェイとのうちの1つである、実施形態1〜11のいずれか1つにおける方法。
13.コアネットワーク中のノードによって実施される、キープアライブメッセージ頻度を交渉する方法であって、
ノードが、ワイヤレス送受信ユニット(WTRU)上で実行を始めるように開始された新しいアプリケーションによって送られるキープアライブメッセージの新しい頻度を、WTRU上で現在実行されているアプリケーションのグループによって送られるキープアライブメッセージの共通頻度と比較すること、および、
新しいアプリケーションをアプリケーションのグループに追加するか、または、共通のキープアライブメッセージ頻度に関連する第1のアプリケーショングループと、新しいアプリケーションキープアライブメッセージ頻度に関連する第2のアプリケーショングループとを確立するかを決定することを含む方法。
ノードが、ワイヤレス送受信ユニット(WTRU)上で実行を始めるように開始された新しいアプリケーションによって送られるキープアライブメッセージの新しい頻度を、WTRU上で現在実行されているアプリケーションのグループによって送られるキープアライブメッセージの共通頻度と比較すること、および、
新しいアプリケーションをアプリケーションのグループに追加するか、または、共通のキープアライブメッセージ頻度に関連する第1のアプリケーショングループと、新しいアプリケーションキープアライブメッセージ頻度に関連する第2のアプリケーショングループとを確立するかを決定することを含む方法。
14.ノードは、パケットデータネットワークゲートウェイと、交渉およびキャッシングゲートウェイと、サービングゲートウェイとのうちの1つである、実施形態13の方法。
15.ノードは、WTRUをターゲットとするアプリケーションメッセージを、優先度または重みを有する種々のタイプに分類するように構成されたバッファを備える、実施形態13〜14のいずれか1つにおける方法。
16.ノードはWTRUにメッセージを送るように構成され、メッセージは、交渉された頻度よりも低い頻度でキープアライブメッセージを送るようWTRUに要求し、かつ、どれくらい長くキープアライブメッセージが有効かを示す、実施形態13〜15のいずれか1つにおける方法。
17.ノードが、新しいキープアライブメッセージ頻度を示す提案頻度フィールドを含むモバイル発信(MO)キープアライブメッセージ頻度交渉要求メッセージを、WTRU上で現在実行されているアプリケーションのグループをサポートする複数のアプリケーションサーバに送ること、および、
WTRU上で現在実行されているアプリケーションのグループをサポートするアプリケーションサーバの全てが新しいキープアライブメッセージ頻度に同意しなかったという条件で、ノードが、共通のキープアライブメッセージ頻度を示す提案頻度フィールドを含むMOキープアライブメッセージ頻度交渉要求メッセージを、新しいアプリケーションをサポートするアプリケーションサーバに送ることをさらに含む、実施形態13〜16のいずれか1つにおける方法。
WTRU上で現在実行されているアプリケーションのグループをサポートするアプリケーションサーバの全てが新しいキープアライブメッセージ頻度に同意しなかったという条件で、ノードが、共通のキープアライブメッセージ頻度を示す提案頻度フィールドを含むMOキープアライブメッセージ頻度交渉要求メッセージを、新しいアプリケーションをサポートするアプリケーションサーバに送ることをさらに含む、実施形態13〜16のいずれか1つにおける方法。
18.モバイル発信(MO)キープアライブメッセージ頻度交渉要求メッセージを複数のアプリケーションサーバに送って、ワイヤレス送受信ユニット(WTRU)上で実行しおよびアプリケーションサーバに関連するアプリケーションによって送られるキープアライブメッセージの頻度を交渉するように構成された回路と、
MOキープアライブメッセージ頻度交渉応答メッセージをアプリケーションサーバから受け取るように構成された回路とを備えるノード。
MOキープアライブメッセージ頻度交渉応答メッセージをアプリケーションサーバから受け取るように構成された回路とを備えるノード。
19.ノードは、パケットデータネットワークゲートウェイと、交渉およびキャッシングゲートウェイと、サービングゲートウェイとのうちの1つである、実施形態18のノード。
20.アプリケーションメッセージtを分類するように構成されたバッファを備える、実施形態18〜19のいずれか1つにおけるノード。
21.WTRUにメッセージを送るように構成された回路をさらに備え、メッセージは、交渉された頻度よりも低い頻度でキープアライブメッセージを送るようWTRUに要求し、かつ、どれくらい長くキープアライブメッセージが有効かを示す、実施形態18〜20のいずれか1つにおけるノード。
以上では特徴および要素が特定の組合せで記述されているが、各特徴または要素は、単独で、または他の特徴および要素のいずれかとの組合せで使用されてよいことを、当業者なら理解するであろう。加えて、本明細書に記載の実施形態は、コンピュータまたはプロセッサによって実行されるようにコンピュータ可読媒体に組み入れられたコンピュータプログラム、ソフトウェア、またはファームウェアにおいて実現されてよい。コンピュータ可読媒体の例は、電子信号(有線またはワイヤレス接続を介して伝送される)、およびコンピュータ可読記憶媒体を含む。コンピュータ可読記憶媒体の例は、読取専用メモリ(ROM)、ランダムアクセスメモリ(RAM)、レジスタ、キャッシュメモリ、半導体メモリデバイス、磁気媒体(例えば内蔵ハードディスクまたは取外し可能ディスク)、光磁気媒体、および、コンパクトディスク(CD)やディジタル多用途ディスク(DVD)などの光学媒体を含むが、これらに限定されない。プロセッサがソフトウェアと共に使用されて、WTRU、UE、端末、基地局、Node−B、eNB、HNB、HeNB、AP、RNC、ワイヤレスルータ、または任意のホストコンピュータ中で使用される無線周波数送受信機が実現されてよい。
Claims (1)
- コアネットワーク中のノードによって実施される、それぞれのアプリケーションに関連付けられたアプリケーションサーバとキープアライブメッセージ頻度を交渉する方法であって、
前記ノードが、モバイル発信(MO)キープアライブメッセージ頻度交渉要求メッセージを複数のアプリケーションサーバへ送信して、ワイヤレス送受信ユニット(WTRU)上で実行しおよび前記アプリケーションサーバに関連付けられたアプリケーションによって送信されるキープアライブメッセージの頻度を交渉するステップと、
前記ノードが、MOキープアライブメッセージ頻度交渉応答メッセージを前記アプリケーションサーバから受信するステップと、
前記ノードが、メッセージを前記WTRUへ送信するステップであって、前記メッセージは、交渉された頻度よりも低い頻度でキープアライブメッセージを送信するよう前記WTRUに要求し、および、どれくらいの期間前記キープアライブメッセージが有効であるかを示す、ステップと
を含むことを特徴とする方法。
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US201261716679P | 2012-10-22 | 2012-10-22 | |
US61/716,679 | 2012-10-22 |
Related Parent Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2015539719A Division JP6039819B2 (ja) | 2012-10-22 | 2013-10-22 | 移動局上で実行されるアプリケーションの「キープアライブ」メッセージ頻度を交渉するための方法および装置 |
Publications (1)
Publication Number | Publication Date |
---|---|
JP2017076988A true JP2017076988A (ja) | 2017-04-20 |
Family
ID=49552419
Family Applications (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2015539719A Active JP6039819B2 (ja) | 2012-10-22 | 2013-10-22 | 移動局上で実行されるアプリケーションの「キープアライブ」メッセージ頻度を交渉するための方法および装置 |
JP2016215959A Pending JP2017076988A (ja) | 2012-10-22 | 2016-11-04 | 移動局上で実行されるアプリケーションの「キープアライブ」メッセージ頻度を交渉するための方法および装置 |
Family Applications Before (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2015539719A Active JP6039819B2 (ja) | 2012-10-22 | 2013-10-22 | 移動局上で実行されるアプリケーションの「キープアライブ」メッセージ頻度を交渉するための方法および装置 |
Country Status (6)
Country | Link |
---|---|
US (1) | US9832101B2 (ja) |
EP (1) | EP2910000A1 (ja) |
JP (2) | JP6039819B2 (ja) |
KR (1) | KR20150084017A (ja) |
CN (1) | CN104813641B (ja) |
WO (1) | WO2014066393A1 (ja) |
Families Citing this family (30)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US8743885B2 (en) | 2011-05-03 | 2014-06-03 | Cisco Technology, Inc. | Mobile service routing in a network environment |
WO2014066393A1 (en) * | 2012-10-22 | 2014-05-01 | Interdigital Patent Holdings, Inc. | Method and apparatus for negotiating "keep-alive" message frequencies of applications running on a mobile station |
US11729661B2 (en) * | 2014-01-09 | 2023-08-15 | Nec Corporation | MTC-IWF entity, PCFR entity, and communication method |
US9842013B2 (en) * | 2014-10-27 | 2017-12-12 | Aruba Networks, Inc. | Dynamic adaptive approach for failure detection of node in a cluster |
TWI577154B (zh) * | 2014-10-31 | 2017-04-01 | 宏碁股份有限公司 | 保持遠端連線方法、電子裝置與伺服器 |
US10417025B2 (en) | 2014-11-18 | 2019-09-17 | Cisco Technology, Inc. | System and method to chain distributed applications in a network environment |
WO2016159115A1 (ja) * | 2015-03-31 | 2016-10-06 | 株式会社Nttドコモ | ゲートウェイ装置、及び通信方法 |
CN106162943B (zh) * | 2015-04-27 | 2019-08-16 | 中国移动通信集团公司 | 一种保活消息处理方法、装置、系统和相关设备 |
WO2016172839A1 (en) * | 2015-04-28 | 2016-11-03 | Telefonaktiebolaget Lm Ericsson (Publ) | Adaptive peer status check over wireless local area networks |
CN106302571B (zh) | 2015-05-14 | 2020-07-28 | 微软技术许可有限责任公司 | 用于对服务器连接进行维护和高速缓存的系统和方法 |
US9762402B2 (en) * | 2015-05-20 | 2017-09-12 | Cisco Technology, Inc. | System and method to facilitate the assignment of service functions for service chains in a network environment |
JP6531497B2 (ja) * | 2015-06-02 | 2019-06-19 | 富士通株式会社 | 無線通信システム、送信周期調整装置および移動機 |
US10404559B2 (en) * | 2015-07-17 | 2019-09-03 | Dataprobe Inc. | Apparatus and system for automatically rebooting an electronically powered device via power over ethernet |
US10932192B2 (en) | 2016-01-12 | 2021-02-23 | Qualcomm Incorporated | EMTC power saving mode (PSM) enhancements for service outage |
US11044203B2 (en) | 2016-01-19 | 2021-06-22 | Cisco Technology, Inc. | System and method for hosting mobile packet core and value-added services using a software defined network and service chains |
JP6360853B2 (ja) * | 2016-05-16 | 2018-07-18 | 株式会社Nttドコモ | 交換機、管理サーバ及び通信方法 |
US20170366423A1 (en) * | 2016-06-15 | 2017-12-21 | Qualcomm Incorporated | Data packet store, forward, and monitoring functionality for network node or modem |
CN109328469B (zh) * | 2016-06-20 | 2022-03-15 | 日本电气株式会社 | 通信网络设备、通信网络系统及通信网络设备的方法 |
US10496973B2 (en) | 2016-07-29 | 2019-12-03 | Square, Inc. | Reprogrammable point-of-sale transaction flows |
US20180033014A1 (en) * | 2016-07-29 | 2018-02-01 | Square, Inc. | Reprogrammable point-of-sale transaction flows |
US10692055B2 (en) | 2016-07-29 | 2020-06-23 | Square, Inc. | Reprogrammable point-of-sale transaction flows |
US10872320B2 (en) | 2016-07-29 | 2020-12-22 | Square, Inc. | Reprogrammable point-of-sale transaction flows |
US10568161B2 (en) * | 2016-09-29 | 2020-02-18 | Qualcomm Incorporated | Uplink (UL)-based mobility via immediate and delayed keep alive (KA) signals |
US11089114B1 (en) * | 2017-09-29 | 2021-08-10 | Amazon Technologies, Inc. | Message frequency modification for connection maintenance |
KR102123831B1 (ko) * | 2018-12-31 | 2020-06-17 | 주식회사 케이아이씨텍 | 킵 얼라이브 트렁킹을 통한 외부망에서의 내부망 접속 방법 및 그 장치 |
CN110049532B (zh) * | 2019-03-12 | 2021-04-30 | 上海感悟通信科技有限公司 | 一种用于无线自组网的心跳方法、受控节点和控制节点 |
CN112887416B (zh) * | 2021-02-04 | 2022-10-18 | 浙江大华技术股份有限公司 | 发送保活包的频率调整方法及装置 |
US11690006B2 (en) * | 2021-10-18 | 2023-06-27 | Skylo Technologies, Inc. | Connecting a wireless hub across multiple wireless networks |
WO2023082123A1 (en) * | 2021-11-11 | 2023-05-19 | Citrix Systems, Inc. | User status synchronization among workspace applications |
US11902138B2 (en) * | 2022-01-26 | 2024-02-13 | Getac Technology Corporation | Connection maintenance method for internet of things device |
Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2008113417A1 (en) * | 2007-03-21 | 2008-09-25 | Telefonaktiebolaget Lm Ericsson (Publ) | Session control in sip-based media services |
US20100322124A1 (en) * | 2009-06-23 | 2010-12-23 | Nokia Corporation | Method and apparatus for optimizing energy consumption for wireless connectivity |
JP6039819B2 (ja) * | 2012-10-22 | 2016-12-07 | インターデイジタル パテント ホールディングス インコーポレイテッド | 移動局上で実行されるアプリケーションの「キープアライブ」メッセージ頻度を交渉するための方法および装置 |
Family Cites Families (19)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7051118B2 (en) * | 1999-12-22 | 2006-05-23 | Tibo Software, Inc. | Method and apparatus for anonymous subject-based addressing |
US6983324B1 (en) * | 2000-10-23 | 2006-01-03 | International Business Machines Corporation | Dynamic modification of cluster communication parameters in clustered computer system |
GB2417389B (en) * | 2004-08-18 | 2007-10-31 | Wecomm Ltd | Transmitting data |
GB2417391B (en) * | 2004-08-18 | 2007-04-18 | Wecomm Ltd | Transmitting data over a network |
US9621473B2 (en) * | 2004-08-18 | 2017-04-11 | Open Text Sa Ulc | Method and system for sending data |
GB2417387B (en) * | 2004-08-18 | 2007-05-09 | Wecomm Ltd | Transmitting data |
US8260372B2 (en) * | 2006-06-30 | 2012-09-04 | Nokia Corporation | Traffic monitoring for regulating states of a terminal |
US8849961B2 (en) * | 2006-09-06 | 2014-09-30 | Nokia Corporation | Mobile network optimized method for keeping an application IP connection always on |
US7698409B2 (en) * | 2006-12-22 | 2010-04-13 | Nokia Corporation | Method and an apparatus for executing timed network operations |
EP2209283A1 (en) * | 2009-01-20 | 2010-07-21 | Vodafone Group PLC | Node failure detection system and method for SIP sessions in communication networks. |
US8375134B2 (en) * | 2009-06-08 | 2013-02-12 | Microsoft Corporation | Determining an efficient keep-alive interval for a network connection |
US7984161B2 (en) * | 2009-06-16 | 2011-07-19 | Microsoft Corporation | Optimizing mobile device synchronization with multiple data sources |
US8688826B2 (en) * | 2009-11-30 | 2014-04-01 | Motorola Mobility Llc | Mobile computing device and method with intelligent pushing management |
US8904206B2 (en) * | 2010-01-26 | 2014-12-02 | Motorola Mobility Llc | Mobile computing device and method for maintaining application continuity |
WO2012060995A2 (en) * | 2010-11-01 | 2012-05-10 | Michael Luna | Distributed caching in a wireless network of content delivered for a mobile application over a long-held request |
US8966292B2 (en) * | 2011-01-03 | 2015-02-24 | Qualcomm Incorporated | Performance improvements in a wireless client terminal using assistance from a proxy device |
BR112013022758A2 (pt) * | 2011-03-07 | 2016-12-06 | Intel Corp | método implementado por computador, dispositivo de máquina para máquina, sistema de computador e sistema de máquina para máquina |
CN102111899B (zh) * | 2011-03-08 | 2014-08-20 | 中兴通讯股份有限公司 | 会话保活方法及装置 |
US8959235B1 (en) * | 2011-07-05 | 2015-02-17 | Symantec Corporation | Techniques for determining an optimal connection duration for a connection between a client and a server across a network |
-
2013
- 2013-10-22 WO PCT/US2013/066187 patent/WO2014066393A1/en active Application Filing
- 2013-10-22 EP EP13788820.2A patent/EP2910000A1/en not_active Withdrawn
- 2013-10-22 CN CN201380055300.3A patent/CN104813641B/zh active Active
- 2013-10-22 KR KR1020157013708A patent/KR20150084017A/ko not_active Application Discontinuation
- 2013-10-22 US US14/437,429 patent/US9832101B2/en active Active
- 2013-10-22 JP JP2015539719A patent/JP6039819B2/ja active Active
-
2016
- 2016-11-04 JP JP2016215959A patent/JP2017076988A/ja active Pending
Patent Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2008113417A1 (en) * | 2007-03-21 | 2008-09-25 | Telefonaktiebolaget Lm Ericsson (Publ) | Session control in sip-based media services |
US20100322124A1 (en) * | 2009-06-23 | 2010-12-23 | Nokia Corporation | Method and apparatus for optimizing energy consumption for wireless connectivity |
JP6039819B2 (ja) * | 2012-10-22 | 2016-12-07 | インターデイジタル パテント ホールディングス インコーポレイテッド | 移動局上で実行されるアプリケーションの「キープアライブ」メッセージ頻度を交渉するための方法および装置 |
Non-Patent Citations (2)
Title |
---|
CHINA MOBILE: "Reducing keep-alive data of applications by network-based always-online solution", 3GPP TSG-SA WG2#93 S2-123534, JPN6016017223, 12 October 2012 (2012-10-12) * |
HUAWEI, HISILICON: "Use Push Proxy to reduce heartbeat/keep-alive data of Applications", 3GPP TSG-SA WG2#93 S2-124171, JPN6016017224, 12 October 2012 (2012-10-12) * |
Also Published As
Publication number | Publication date |
---|---|
US9832101B2 (en) | 2017-11-28 |
JP6039819B2 (ja) | 2016-12-07 |
WO2014066393A1 (en) | 2014-05-01 |
KR20150084017A (ko) | 2015-07-21 |
JP2016502780A (ja) | 2016-01-28 |
EP2910000A1 (en) | 2015-08-26 |
CN104813641B (zh) | 2018-08-24 |
CN104813641A (zh) | 2015-07-29 |
US20150282177A1 (en) | 2015-10-01 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
JP6039819B2 (ja) | 移動局上で実行されるアプリケーションの「キープアライブ」メッセージ頻度を交渉するための方法および装置 | |
US11611949B2 (en) | Keeping the UE awake | |
TWI700948B (zh) | 無線傳輸/接收單元及由其實施的方法 | |
KR102257786B1 (ko) | 이동성 시그널링 로드 감소 | |
JP6189817B2 (ja) | マシンタイプ通信をサポートする方法および装置 | |
CN105900504B (zh) | 下行链路数据传输方法和服务网关 | |
JP5767394B2 (ja) | マシンタイプ通信デバイスをトリガして同期させるための方法および装置 | |
US9345024B2 (en) | Exchanging configuration data | |
KR20200139771A (ko) | 5g 네트워크에서의 로컬 영역 데이터 네트워크(ladn)에 대한 접속들을 관리하는 방법들 | |
JP2017143562A (ja) | マシンツーマシンゲートウェイのアーキテクチャおよび機能性 | |
TW201618585A (zh) | 用於在無線通訊系統中傳送下行鏈路資料的方法與設備 | |
JP6208153B2 (ja) | Pppセッションを維持するための拡張時間期間を容易にするための装置および方法 | |
EP3066880A1 (en) | Paging in communications |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A132 Effective date: 20171212 |
|
A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20180703 |