特許 6618204 無線通信システムの伝送制御プロトコル接続制御装置及び方法

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】6618204

(24)【登録日】2019年11月22日

(45)【発行日】2019年12月11日

(54)【発明の名称】無線通信システムの伝送制御プロトコル接続制御装置及び方法

(51)【国際特許分類】

   H04L 29/06 20060101AFI20191202BHJP

   H04L 29/00 20060101ALI20191202BHJP

【ＦＩ】

   H04L13/00 305C

   H04L13/00 T

【請求項の数】6

【全頁数】22

(21)【出願番号】特願2017-512283(P2017-512283)

(86)(22)【出願日】2015年9月2日

(65)【公表番号】特表2017-535101(P2017-535101A)

(43)【公表日】2017年11月24日

(86)【国際出願番号】KR2015009244

(87)【国際公開番号】WO2016036134

(87)【国際公開日】20160310

【審査請求日】2018年8月31日

(31)【優先権主張番号】903/KOL/2014

(32)【優先日】2014年9月2日

(33)【優先権主張国】IN

(31)【優先権主張番号】10-2015-0124106

(32)【優先日】2015年9月2日

(33)【優先権主張国】KR

(73)【特許権者】

【識別番号】503447036

【氏名又は名称】サムスン エレクトロニクス カンパニー リミテッド

(74)【代理人】

【識別番号】100133400

【弁理士】

【氏名又は名称】阿部 達彦

(74)【代理人】

【識別番号】100110364

【弁理士】

【氏名又は名称】実広 信哉

(74)【代理人】

【識別番号】100154922

【弁理士】

【氏名又は名称】崔 允辰

(74)【代理人】

【識別番号】100140534

【弁理士】

【氏名又は名称】木内 敬二

(72)【発明者】

【氏名】ヨン−キ・ホン

(72)【発明者】

【氏名】カルティケヤン・アルナーチャラム

(72)【発明者】

【氏名】ラナ・プラサド・サフ

(72)【発明者】

【氏名】ムトゥ・ヴィーラッパン・アラガッパン

(72)【発明者】

【氏名】ジン−ホ・イ

【審査官】 宮島 郁美

(56)【参考文献】

【文献】 国際公開第２０１４／０３９８５３（ＷＯ，Ａ１）

【文献】 米国特許出願公開第２０１４／００６４１３４（ＵＳ，Ａ１）

【文献】 佐藤 彰洋 Akihiro Sato，電気関係学会関西支部連合大会，電気学会論文誌Ｃ Ｖｏｌ．１２９ Ｎｏ．１１ IEEJ，日本，（社）電気学会 The Institute of Electrical Engineers of Japan，２００９年１１月 １日，第129巻

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｈ０４Ｌ２９／００

Ｈ０４Ｂ７／２４−７／２６，Ｈ０４Ｗ４／００−９９／００

Ｈ０４Ｍ１／００，１／２４−１／８２，９９／００

(57)【特許請求の範囲】

【請求項1】

無線通信システムにおけるクライアントの動作方法において:
第１時間区間（time period）及び第２時間区間に基づいて、少なくとも１つの伝送制御プロトコル（transmission control protocol、ＴＣＰ）接続に対するガードタイム区間（guard time period）を決定する過程と、
前記ガードタイム区間の満了に対応して、前記少なくとも１つのＴＣＰ接続を終了する過程を含み、
前記第１時間区間は要求の伝送時点から前記要求に対する応答の受信時点までの時間区間で、
前記第２時間区間は前記応答の受信時点から次の要求の伝送時点までの時間区間である方法。

【請求項2】

前記ガードタイム区間はサーバによって開始される（server-initiated）ＴＣＰ接続終了に対する時点より先である請求項１に記載の方法。

【請求項3】

前記サーバ開始のＴＣＰ接続終了は前記少なくとも１つのＴＣＰ接続の終了を指示するメッセージに対応して行われ、
前記メッセージはサーバから受信される請求項２に記載の方法。

【請求項4】

無線通信システムにおけるクライアントの装置において、
第１時間区間（time period）及び第２時間区間に基づいて、少なくとも１つの伝送制御プロトコル（transmission control protocol、ＴＣＰ）接続に対するガードタイム区間（guard time period）を決定し、前記ガードタイム区間の満了に対応して、前記少なくとも１つのＴＣＰ接続を終了する制御部を含み、
前記第１時間区間は要求の伝送時点から前記要求に対する応答の受信時点までの時間区間で、
前記第２時間区間は前記応答の受信時点から次の要求の伝送時点までの時間区間である装置。

【請求項5】

前記ガードタイム区間はサーバによって開始される（server-initiated）ＴＣＰ接続終了に対する時点より先である請求項４に記載の装置。

【請求項6】

前記サーバ開始のＴＣＰ接続終了は前記少なくとも１つのＴＣＰ接続の終了を指示するメッセージに対応して行われ、
前記メッセージはサーバから受信される請求項５に記載の装置。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、一般にコンピュータ装置に関する。本発明は、より具体的には、無線通信システムにおけるＴＣＰ接続を制御する装置及び方法に関する。

【背景技術】

【0002】

最近、無線通信環境では、スマートフォンのような電子装置（又はクライアント装置）は独立及び遠隔サーバとの相互作用によって複数のネットワークアプリケーション（例えば、Ｆａｃｅｂｏｏｋ、Ｔｗｉｔｔｅｒ、Ｅｍａｉｌ、Ｆｌｉｐｂｏａｒｄ、ＡｃｃｕＷｅａｔｈｅｒ）を実行する。これらのアプリケーションの大半は現実的に寿命の短い伝送プロトコル接続、例えば、伝送制御プロトコル（ｔｒａｎｓｍｉｓｓｉｏｎ ｃｏｎｔｒｏｌ ｐｒｏｔｏｃｏｌ、ＴＣＰ）接続の設定によってサーバと連動する。

【0003】

一方、クライアント装置でＴＣＰ接続に対する終了処理を適切に行えない場合は、クライアント装置で大きな電力消耗を引き起こす場合がある。そのために、ＴＣＰ接続に対する終了処理をクライアントで開始したりサーバで開始する典型的な方法がある。

【0004】

従来のクライアント開始の終了（ｃｌｉｅｎｔ−ｉｎｉｔｉａｔｅｄ ｃｌｏｓｅ ｉｎ ＴＣＰ ｃｏｎｎｅｃｔｉｏｎｓ）処理は、データの交換が終わった場合、該当非活性ＴＣＰ接続を直ちに終了処理する方法である。しかし、この方法は、再使用の必要がある非活性ＴＣＰ接続に対しても終了処理を行うため、再使用のためにはトランスポート層（ｔｒａｎｓｐｏｒｔ ｌａｙｅｒ）を再度セットアップしなければならないという不便さとその手順の遂行による時間が求められる。

【0005】

一方で、サーバ開始の終了（ｓｅｒｖｅｒ−ｉｎｉｔｉａｔｅｄ ｃｌｏｓｅ ｉｎ ＴＣＰ ｃｏｎｎｅｃｔｉｏｎｓ）処理は、数秒から数分（例えば、３０ｓ、６０ｓ、１２０ｓ等）までの間隔のサーバタイムアウト（ｓｅｒｖｅｒ ｔｉｍｅｏｕｔ）の後、サーバは各クライアントに対してＦＩＮ（Ｆｉｎｉｓｈ）パケットを伝送することによってＴＣＰ接続終了を開始する。

【0006】

これらのＴＣＰ接続は、クライアントとサーバエンドポイントの間のデータ伝送の制限された周波数を有する。一旦データが交換されると、設定されたＴＣＰ接続の残り時間はアイドル（ｉｄｌｅ）状態である。設定されたまだアイドル状態のＴＣＰ接続は、数秒から数分までの間隔で終了メッセージ（例えば、ＦＩＮ（Ｆｉｎｉｓｈ）パケット）を引き起こすサーバタイムアウト（ｓｅｒｖｅｒ ｔｉｍｅｏｕｔ）に対して脆弱である。

【0007】

しかし、サーバによって開始される終了メッセージは、無線通信ネットワーク（例えば、３Ｇ／ＬＴＥネットワーク）で引き起こされるテールエネルギー（ｔａｉｌ ｅｎｅｒｇｙ）とともにアイドル状態から活性状態へのネットワーク無線状態移行によって引き起こされるエネルギーオーバーヘッドを招く。これらの遅延された終了メッセージは無線階層タイマー（ｒａｄｉｏ−ｌａｙｅｒ ｔｉｍｅｒ）を再設定することでより長い時間の間無線インタフェースを維持し、さらには、エネルギーオーバーヘッドを招いて無線インタフェースをターンオンさせ追加的な無線状態の変化をトリガする。

【発明の概要】

【発明が解決しようとする課題】

【0008】

したがって、本発明は、無線通信システムにおけるＴＣＰ接続を制御する装置及び方法を提供することを目的とする。

【0009】

本発明は、無線通信システムにおけるスマートフォン端末のような電子装置のバッテリ寿命を改善するためのＴＣＰ接続を制御する装置及び方法を提供することを他の目的とする。

【0010】

本発明は、スマートフォン端末のようなクライアントがアイドル状態から活性状態に移行することによって引き起こされるエネルギーオーバーヘッドを減少させるためのＴＣＰ接続を制御する装置及び方法を提供することをさらに他の目的とする。

【0011】

本発明は、クライアントでＴＣＰ接続の終了を開始する装置及び方法を提供することをさらに他の目的とする。

【0012】

本発明は、クライアントでＴＣＰ接続の終了を先行処理、バッチ処理、またはこれらの結合によって処理する装置及び方法を提供することをさらに他の目的とする。

【課題を解決するための手段】

【0013】

本発明の一実施例によれば、無線通信システムにおけるクライアントの動作方法が提供される。上記方法は、複数の伝送制御プロトコル（ＴＣＰ）接続のうち少なくとも１つのＴＣＰ接続に対するデータ伝送非活性化時間を決定する過程と、前記データ伝送非活性化時間に前記ＴＣＰ接続を終了する過程と、を含む。

【0014】

本発明の他の実施例によれば、無線通信システムにおけるクライアントの動作方法が提供される。上記方法は、複数の伝送制御プロトコル（ＴＣＰ）接続のうちサーバによって終了処理が開始される少なくとも１つの第１ＴＣＰ接続を確認する過程と、前記ＴＣＰ接続のうち前記第１ＴＣＰ接続を除く少なくとも１つの第２ＴＣＰ接続に対する処理とともに前記第１ＴＣＰ接続をバッチ処理して終了する過程と、を含む。

【0015】

本発明のさらに他の実施例によれば、無線通信システムのクライアント装置が提供される。前記装置は、複数の伝送制御プロトコル（ＴＣＰ）接続のうち少なくとも１つのＴＣＰ接続に対するデータ伝送非活性化時間を決定し、前記データ伝送非活性化時間に前記ＴＣＰ接続を終了する制御機を含む。

【0016】

本発明のさらに他の実施例によれば、無線通信システムのクライアント装置が提供される。前記装置は、複数の伝送制御プロトコル（ＴＣＰ）接続のうちサーバによって終了処理が開始される少なくとも１つの第１ＴＣＰ接続を確認し、前記ＴＣＰ接続のうち前記第１ＴＣＰ接続を除く少なくとも１つの第２ＴＣＰ接続に対する処理とともに前記第１ＴＣＰ接続をバッチ処理して終了する制御機を含む。

【発明の効果】

【0017】

本発明の様々な実施例は、スマートフォン端末のようなクライアント装置でアプリケーションソフトウエアを変更する必要なくユーザーエクスペリエンスを悪化させたりアプリケーション機能に影響を及ぼしたりすることなく、より長いアイドル時間を有するようにしてより高いバッテリ寿命を達成することに役立つ。

【図面の簡単な説明】

【0018】

他の目的、機能及び長所は添付図面及び次の好ましい実施例の説明から当業者に明白である。

【図1】本発明の実施例が適用されるネットワーク環境を示す図である。

【図2】サーバによって開始されるクライアントでのＴＣＰ接続に対する終了の動作を示す図である。

【図3A】本発明の実施例に係る先行ＴＣＰ接続終了の動作を示す図である。

【図3B】本発明の実施例に係るバッチ遅延ＴＣＰ接続終了の動作を示す図である。

【図4】本発明の様々な実施例に係るクライアント装置のブロック構成を示す図である。

【図5】本発明の様々な実施例に係るＬＰＴＣＰのための全体ソフトウェアアーキテクチャを示す図である。

【図6A】本発明の一実施例によってサーバによって開始されるＴＣＰ接続終了時間を検出する方法を示す図である。

【図6B】本発明の他の実施例によってガードタイムアウト（ｇｕａｒｄ ｔｉｍｅｏｕｔ）を検出する方法を示す図である。

【図7】本発明の様々な実施例に係るＴＣＰ接続終了動作を示す図である。

【図8】本発明の実施例に係るＴＣＰ接続先行及びバッチ終了の結合動作を説明するための図面である。

【図9A】本発明の一実施例に係る先行ＴＣＰ接続終了動作のために行われるステップを示す図である。

【図9B】本発明の他の実施例に係る先行ＴＣＰ接続終了動作のために行われるステップを示す図である。

【図10A】本発明の実施例に係る遅延ＴＣＰ接続終了に対するバッチ動作時に行われるステップを示す図である。

【図10B】本発明の実施例に係る遅延ＴＣＰ接続終了に対するバッチ動作時に行われるステップを示す図である。

【図11】本発明の様々な実施例に係るＴＣＰ制御方法の全体フローを示す図である。

【図12】本発明の一実施例に係る、データ伝送非活性時間又はガードタイムアウトを推定するためのＴＣＰ制御の動作フローを示す図である。

【図13】本発明の一実施例に係る、非活性の非恒久的ＴＣＰ接続に対する先行終了方法のためのＴＣＰ制御の動作フローを示す図である。

【図14】本発明の一実施例に係る、非活性の非恒久的ＴＣＰ接続に対するバッチ終了方法のためのＴＣＰ制御の動作フローを示す図である。

【図15】本発明の一実施例に係る、非活性の非恒久的ＴＣＰ接続に対する先行及びバッチ終了を含む結合された方法のためのＴＣＰ制御の動作フローを示す図である。

【図16A】本発明の様々な実施例に係るＴＣＰ制御動作に対する電力節約面からみた試験結果を示す図である。

【図16B】本発明の様々な実施例に係るＴＣＰ制御動作に対する電力節約面からみた試験結果を示す図である。

【図17】本発明の様々な実施例に係るＴＣＰ制御動作に対するネットワークシグナリング減少面からみた試験結果を示す図である。

【0019】

本発明の特定の機能が一部の図面には図示され、他の図面には図示されないが、それぞれの機能が本発明に係る他の機能のすべて又はいずれか１つと結合されることができるため、これは単に便宜のために行われる。

【発明を実施するための形態】

【0020】

以下、本発明の実施例を添付図面に基づき詳細に説明する。そして、以下では、本発明の実施例に係る動作を理解するために必要な部分のみが説明され、その他の部分の説明は本発明の要旨から逸脱しないように省略されることを留意するべきである。そして、後述される用語は本発明の実施例における機能を考慮して定義された用語であって、これはユーザ、運用者の意図又は慣例などによって異なる場合がある。よって、その定義は本明細書全般に亘る内容に基づいて行われるべきである。

【0021】

本発明は、多様な変更を加えることができ、様々な実施例を有することができ、特定の実施例を図面に例示して詳しく説明する。しかし、これは本発明を特定の実施形態に限定することを意図するものでなく、本発明の思想及び技術範囲に含まれるあらゆる変更、均等物乃至代替物を含むものであると理解されるべきである。よって、本特許明細書で本発明の原理を説明するために使用される図１乃至図１７は単なる例示のためのものであって、発明の範囲を制限するいかなるものとして解釈されてはならない。

【0022】

後述の本発明の様々な実施例は、バッテリ寿命を改善するためにスマートフォン端末のような電子装置（又はクライアント）でＴＣＰ接続を制御する装置及び方法を提供する。本発明の実施例は、コンピュータ装置、例えば図１に示すネットワーク環境で適用され得る。

【0023】

図１を参照すると、クライアント１００は、ネットワーク３００を介してサーバ２００に接続される。ネットワーク３００は、３Ｇ又はロングタームエボリューション（ｌｏｎｇ ｔｅｒｍ ｅｖｏｌｕｔｉｏｎ、ＬＴＥ）の無線通信システムの場合がある。クライアント１００は、複数のアプリケーション（例えば、Ａｐｐ−Ａ１１、Ａｐｐ−Ｂ１２、Ａｐｐ−Ｃ１３）１０の実行によってサーバ２００と連動し、その結果、サーバ２００と様々なコンテンツをやり取りすることができる。クライアント１００とサーバ２００は伝送制御プロトコル（ｔｒａｎｓｍｉｓｓｉｏｎ ｃｏｎｔｒｏｌ ｐｒｏｔｏｃｏｌ、ＴＣＰ）のような伝送プロトコルを介して互いに接続され得る。クライアント１００は、様々な電子装置又はユーザ端末の場合があり、代表的にはスマートフォンの場合がある。

【0024】

本発明の実施例は、アプリケーションソフトウエアを変更する必要なくユーザーエクスペリエンスを悪化させたりアプリケーション機能に影響を及ぼしたりすることなく、より長いアイドル時間を有するようにしてより高いバッテリ寿命を達成することに役立つ。

【0025】

現在、スマートフォンエージェント（ａｇｅｎｔｓ）によって設定されるＴＣＰ接続（ｃｏｎｎｅｃｔｉｏｎｓ）は恒久的な（ｐｅｒｓｉｓｔｅｎｔ）接続及び非恒久的（ｎｏｎ−ｐｅｒｓｉｓｔｅｎｔ）接続の場合がある。サーバ２００によって終了される非活性の非恒久的な接続（ｉｎａｃｔｉｖｅｎｏｎ−ｐｅｒｓｉｓｔｅｎｔ ｃｏｎｎｅｃｔｉｏｎｓ）は、セルラー無線のようなネットワークリソースがアイドル状態から活性状態に移行する原因となる。このような現象は電力消費に繰り返し影響を及ぼす。本発明の実施例は、サーバ２００によるＴＣＰ接続終了を最適化することでクライアント装置のバッテリ寿命を増加させるものである。

【0026】

後述の本発明の実施例は、クライアント１００側、すなわち、スマートフォン末端で非活性の非恒久的なＴＣＰ接続を制御して終了する様々な方法を提示する。本発明の実施例に係る方法は、最小限の無線状態移行機会を使用することによって、サーバによって開始されるＴＣＰ接続終了処理によって招かれる電力消耗を低減できるようにする。

【0027】

本発明の実施例によれば、ＴＣＰ接続終了処理方式は、後述の図７に示すように、先行（ｐｒｏａｃｔｉｖｅ）ＴＣＰ接続終了方式７１０、バッチ遅延（ｂａｔｃｈｉｎｇ ｄｅｌａｙｅｄ）ＴＣＰ接続終了方式７２０、及び結合された先行及びバッチＴＣＰ接続終了方式７３０を含む。

【0028】

本発明の実施例は、サーバによって開始されるＴＣＰ接続終了を制御しつつも調整前と同じように全体機能が維持されるようにすることによってバッテリ寿命を向上させることに焦点を当てる。

【0029】

本発明の実施例は、ＴＣＰ接続を終了するサーバに対する依存性を減らし、特定及び異なるサーバ終了タイムアウトを有する全てのアプリケーションに適用され得る。本発明の実施例は、クライアント側でネットワークリソースを最小化する追加的な長所があり、ネットワーク側の要素からの追加的なサポートを必要としない。本発明の実施例は、ネットワークサポートを問わないため、これらの実施例は速かに使用されることができる。

【0030】

本発明の実施例は、恒久的及び非恒久的接続に対するＴＣＰ接続の分類が行われた後、アプリケーショントランスペアレント層でＴＣＰ接続情報をキャプチャすることから開始される。このような分類の高い精密度及び正確度を獲得するために使用される方法は、ＴＣＰ接続が終了した後、接続再設定を試みる時間をモニタすることに基づく。

【0031】

恒久的接続（ｐｅｒｓｉｓｔｅｎｔ ｃｏｎｎｅｃｔｉｏｎ）は、１つ以上の連続的なＴＣＰ接続を使用することによってクライアントとサーバの間のデータ交換が常に可能な接続に対して決定される。

【0032】

非恒久的接続を検出する例示的なステップは以下の通りであるが、これに限定されない。
１）接続の寿命が所定の時間より長く、
２）類似のＴＣＰ接続が以前のＴＣＰ接続の終了後に所定の時間及び所定の回数内で再設定される。ここで、類似のＴＣＰ接続とは、接続の同じホスト名又は宛先ＩＰアドレス又はポートがキャッシュ及び／又はＤＢ内にある場合を意味する。

【0033】

本発明の実施例は、進行中のＴＣＰ接続から様々な属性を動的に計算するものである。これらの属性は次のうちの１つ以上又は組み合わせであるが、これに限定されない。

【0034】

１）サーバ終了タイムアウト（ｓｅｒｖｅｒ ｃｌｏｓｅ ｔｉｍｅｏｕｔ）：図６Ａに示すように、サーバ終了タイムアウト６１２値は、最終データ伝送とサーバ２００によって開始される終了の間で要する時間である。

【0035】

ａ）最終データ伝送はサーバ２００からの（該当クライアント要求に対する）最終応答が受信された時間（Ｔ２５）を表す。
ｂ）サーバ２００によって開始される終了はサーバ２００によって開始される終了からＴＣＰ ＦＩＮパケットが受信された時間（Ｔ３０）を表す。

【0036】

２）ガードタイムアウト（ｇｕａｒｄ ｔｉｍｅｏｕｔ）：図６Ｂに示すように、ガードタイムアウト６２２値は、サーバ２００とクライアントの特定のアプリケーション１００−１間でこれ以上データ伝送がない後の最終データ伝送以後の最も早い時間である。ここで、最終データ伝送以降の最も早い時間は、連続的な要求及び該当応答（Ｔ８５，Ｔ９０）の後の非活性時間予測結果を表す。

【0037】

本発明の実施例は、次のようにサーバ終了タイムアウト６１２を計算する最適の方法を考慮するが、これに限定されない。

【0038】

サーバ終了タイムアウトの検出方法：
図６Ａは、本発明の一実施例によってサーバによって開始されるＴＣＰ接続終了時間を検出する方法を示す。本発明の一実施例によれば、サーバによって開始される終了動作は、データ伝送に対する長期間の非活性化の後サーバ２００によってトリガされる。

【0039】

それぞれの接続のＴＣＰサーバ終了タイムアウトは、ポールシステムコール（ｐｏｌｌ ｓｙｓｔｅｍ ｃａｌｌ）での所謂ＰＯＬＬＲＤＨＵＰイベントをモニタリングすることで計算される。ＰＯＬＬＲＤＨＵＰイベントは、ピア（ｐｅｅｒ）がその接続を切る際にトリガされる。すなわち、ＰＯＬＬＲＤＨＵＰイベントは接続の遠隔終端（ｒｅｍｏｔｅ ｅｎｄ）（例えば、サーバ２００）がＴＣＰ ＦＩＮパケットを伝送する際にトリガされる（図６ＡのＴ３０）。

【0040】

例示的なアルゴリズム：
サーバ終了タイムアウト（Ｓｅｒｖｅｒ Ｃｌｏｓｅ Ｔｉｍｅ−ｏｕｔ）＝接続設定時間（ｃｏｎｎｅｃｔｉｏｎ ｅｓｔａｂｌｉｓｈｅｄ ｔｉｍｅ）−ＰＯＬＬＲＤＨＵＰイベントトリガ時間（ｅｖｅｎｔ ｔｒｉｇｇｅｒｅｄ ｔｉｍｅ）（ＦＩＮ受信時間（ｒｅｃｅｉｖｉｎｇ ｔｉｍｅ））

【0041】

本発明の実施例は、次のようにガードタイムアウトを計算する最適の方法を考慮するが、これに限定されない。

【0042】

ガードタイムアウト検出方法：
図６Ｂは、本発明の他の実施例によってガードタイムアウト（ｇｕａｒｄ ｔｉｍｅｏｕｔ）を検出する方法を示す。本発明の一実施例によれば、サーバ（例えば、図１のサーバ２００）とモバイルアプリケーション（例えば、図１のＡｐｐ−Ａ１１）の間の非恒久的接続のためのデータ伝送完了時間又は非活性化時間は、往復時間（ＲＴＴ）及び応答処理時間の関数で計算される。

【0043】

ガードタイムアウトは、クライアントによって開始される終了からＴＣＰ接続ソケットが保護される時間の量である。これはソケットに対する「保護タイムアウト（ｐｒｏｔｅｃｔｅｄ ｔｉｍｅｏｕｔ）」とも言える。

【0044】

ガードタイムアウトに対する計算は、一般にサーバの応答に対するアプリケーション処理時間（図６Ｂのｐｒｏｃｅｓｓｉｎｇ ｔｉｍｅ Ｎ）と、要求／応答の往復時間（ＲＴＴ Ｍ）、すなわち、要求と応答の間の遅延の関数である。

【0045】

ガードタイムアウト値は、ＴＣＰ接続ソケットごとに異なる。それはソケットの寿命の間にソケット判読&作成時間スタンプに基づいて動的にアップデートされる。

【0046】

例示的なアルゴリズム：
ガードタイムアウト（Ｇｕａｒｄ Ｔｉｍｅｏｕｔ）＝平均処理時間（Ａｖｇ Ｐｒｏｃｅｓｓｉｎｇ Ｔｉｍｅ）＋（処理時間分散（Ｐｒｏｃｅｓｓｉｎｇ Ｔｉｍｅ Ｖａｒｉａｎｃｅ））＋平均ＲＴＴ（Ａｖｇ ＲＴＴ）＋（ＲＴＴ分散（ＲＴＴ Ｖａｒｉａｎｃｅ））。例えば、ＰＣＴ接続ソケットｘに対するガードタイムアウトｇ（ｘ）は下記のように計算される：

【0047】

例示的な数式

【数1】

【0048】

計算の細部事項：
処理時間（Ｐｒｏｃｅｓｓｉｎｇ Ｔｉｍｅ）＝要求伝送時間−最終応答受信時間
ＲＴＴ＝応答受信時間−最終要求伝送時間

【0049】

【数2】

処理時間の合計／処理期間の個数、ここで、Ｎは処理時間。

【数3】

平均処理時間からの分散

【数4】

Ｗ_１＝処理時間分散に対する重み因子
Ｗ_２＝ＲＴＴ分散に対する重み因子

【0050】

図４は、本発明の様々な実施例に係るクライアント装置のブロック構成を示す。例えば、クライアント装置は、図１に示すクライアント１００の場合がある。

【0051】

図４を参照すると、クライアント１００は、アンテナ部１１０、送受信機１２０、制御機１３０、及びメモリ１４０を含む。

【0052】

アンテナ部１１０は、送受信機１２０によって送信処理された信号を、無線チャネルを介して送信し、無線チャネル上の信号を受信する。アンテナ部１１０は、ビームフォーミングをサポートするための多数のアンテナ、アレイアンテナ又はアンテナ要素（ｅｌｅｍｅｎｔ）を含むことができる。

【0053】

送受信機１２０は、送信される信号を送信処理し、または、受信される信号を受信処理する。例えば、送受信機１２０は、システムの物理層規格に従って基底帯域信号及びビット列間変換機能を行う。データ送信の際、送受信機１２０は、送信ビット列を符号化及び変調することによって複素シンボルを生成する。この時、送受信機１２０は、前記複素シンボルを副搬送波にマッピングし、ＩＦＦＴ（ｉｎｖｅｒｓｅ ｆａｓｔ Ｆｏｕｒｉｅｒ ｔｒａｎｓｆｏｒｍ）演算によってＯＦＤＭシンボルを生成できる。データ受信の際、送受信機１２０は、基底帯域信号を復調及び復号化して受信ビット列を復元する。また、送受信機１２０は、基底帯域信号をＲＦ（ｒａｄｉｏ ｆｒｅｑｕｅｎｃｙ）帯域信号にアップコンバートした後、アンテナ部１１０を介して送信し、前記アンテナ１１０を介して受信されるＲＦ帯域信号を基底帯域信号にダウンコンバートする。例えば、送受信機１２０は、送信フィルタ、受信フィルタ、増幅器、ミキサ（ｍｉｘｅｒ）、オシレータ（ｏｓｃｉｌｌａｔｏｒ）、ＤＡＣ（Ｄｉｇｉｔａｌ ｔｏ Ａｎａｌｏｇ Ｃｏｎｖｅｒｔｅｒ）、ＡＤＣ（Ａｎａｌｏｇ ｔｏ Ｄｉｇｉｔａｌ Ｃｏｎｖｅｒｔｅｒ）などを含むことができる。

【0054】

また、送受信機１２０は、多数のＲＦチェーンを含むことができる。さらに、送受信機１２０は、ビームフォーミング（ｂｅａｍｆｏｒｍｉｎｇ）をサポートできる。ビームフォーミングのために、送受信機１２０は、アンテナ部１１０に含まれる多数のアンテナ又はアンテナ要素（ｅｌｅｍｅｎｔ）を介して送受信される信号それぞれの位相及び大きさを調節できる。また、送受信機１２０は、送信される複数のデータストリームに対してプリコーディング（ｐｒｅｃｏｄｉｎｇ）を行うことができる。これにより、送信装置は、ＭＵ−ＭＩＭＯ通信を行うことができる。送受信機１２０は、上述のように信号を送信及び受信する。このような送受信機１２０は、通信部又は送受信部と称することができ、場合によっては、送信機と受信機又は送信部と受信部に分離されて図示されることができる。

【0055】

メモリ１４０は、送受信機１２０の動作のための基本プログラム、アプリケーションプログラム、設定情報などのデータを格納する。また、メモリ１４０は、制御機１３０の要求に応じて保存されたデータを提供する。例えば、メモリ１４０は、図１１乃至図１５に示すフローによる低電力ＴＣＰ接続終了動作の遂行と関連するプログラム及び／又は命令を格納することができる。

【0056】

制御機１３０は、（図１の）クライアント１００の全般的な動作を制御する。例えば、制御機１３０は、送受信機１２０を介して信号を送受信する。また、制御機１３０は、メモリ１４０にデータを記録し、メモリ１４０に記録されているデータを読み込む。このために、制御機１３０は、少なくとも１つのプロセッサ（ｐｒｏｃｅｓｓｏｒ）を含むことができる。

【0057】

本発明の実施例に係るＴＣＰ接続制御のために、制御機１３０は、タイムアウト計算モジュール１３２及びＴＣＰ接続終了モジュール１３４を含む。タイムアウト計算モジュール１３２は、本発明の実施例に係る低電力ＴＣＰ接続終了動作のために、各ＴＣＰ接続に対してサーバ開始のＴＣＰ接続終了時間及びガードタイムアウト（又はデータ伝送非活性化時間）を計算又は推定する。例えば、タイムアウト計算モジュール１３２は、図６Ａに示すフローに従ってサーバ開始のＴＣＰ接続終了時間を検出する。また、タイムアウト計算モジュール１３２は、図６Ｂに示すフローに従ってガードタイムアウトを検出する。

【0058】

ＴＣＰ接続終了モジュール１３４は、本発明の実施例に係る低電力ＴＣＰ接続終了動作を行う。一実施例において、ＴＣＰ接続終了モジュール１３４は、後述の図１３に示すフローに従って先行ＴＣＰ接続終了動作を行う。他の実施例において、ＴＣＰ接続終了モジュール１３４は、後述の図１４に示すフローに従ってバッチＴＣＰ接続終了動作を行う。他の実施例において、ＴＣＰ接続終了モジュール１３４は、後述の図１５に示すフローに従って結合された先行及びバッチＴＣＰ接続終了動作を行う。

【0059】

本発明の一実施例によれば、制御機１３０は、複数のＴＣＰ接続のうち少なくとも１つのＴＣＰ接続に対するデータ伝送非活性化時間を決定し、前記データ伝送非活性化時間に前記ＴＣＰ接続を終了する。

【0060】

一実施例において、前記データ伝送非活性化時間は、クライアント１００とサーバ２００の間での前記ＴＣＰ接続に関わる一連の要求の送信から応答の受信までの往復時間（ＲＴＴ）、及び前記サーバ２００からの任意の応答受信以後の次の要求送信までの処理時間に基づいて決定されることができる。

【0061】

一実施例において、前記データ伝送非活性化時間は、サーバによって開始される前記ＴＣＰ接続に対する終了時点より早い。前記サーバによって開始される前記ＴＣＰ接続に対する終了は、前記サーバから前記ＴＣＰ接続の終了を指示するメッセージが受信されることに応じて行われることができる。

【0062】

本発明の他の実施例によれば、制御機１３０は、複数のＴＣＰ接続のうちサーバ２００によって終了処理が開始される少なくとも１つの第１ＴＣＰ接続を確認し、前記ＴＣＰ接続のうち前記第１ＴＣＰ接続を除く少なくとも１つの第２ＴＣＰ接続に対する処理とともに前記第１ＴＣＰ接続をバッチ処理して終了する。

【0063】

一実施例において、前記第２ＴＣＰ接続に対する処理は、前記第２ＴＣＰ接続に対する接続処理、終了処理、及びデータパケットの送信及び／又は受信動作のうち１つを含むことができる。

【0064】

一実施例において、前記制御機は、前記複数のＴＣＰ接続のうち前記サーバからの終了メッセージの受信に応じて前記第１ＴＣＰ接続を確認する動作を行うことができる。

【0065】

一実施例において、前記制御機は、前記第１ＴＣＰ接続に対するデータ伝送非活性化時間が所定の基準時間より大きい場合に前記第１ＴＣＰ接続を確認し、前記第１ＴＣＰ接続をバッチ処理して終了する動作を行うことができる。前記制御機は、前記データ伝送非活性化時間が前記基準時間より大きくない場合、前記データ伝送非活性化時間に前記第１ＴＣＰ接続を終了する動作をさらに行うことができる。

【0066】

一実施例において、前記データ伝送非活性化時間は、前記クライアント１００とサーバ２００の間での前記第１ＴＣＰ接続に関わる一連の要求の送信から応答の受信までの往復時間（ＲＴＴ）、及び前記サーバ２００からの任意の応答受信以後の次の要求送信までの処理時間に基づいて決定されることができる。

【0067】

一実施例において、前記データ伝送非活性化時間は、前記サーバによって開始される前記第１ＴＣＰ接続に対する終了時点より早い場合がある。前記サーバによって開始される前記第１ＴＣＰ接続に対する終了は、前記サーバ２００から前記第１ＴＣＰ接続の終了を指示するメッセージが受信されることに応じて行うことができる。

【0068】

図５は、本発明の様々な実施例に係る低電力伝送制御プロトコル（ｌｏｗ ｐｏｗｅｒ ｔｒａｎｓｍｉｓｓｉｏｎ ｃｏｎｔｒｏｌ ｐｒｏｔｏｃｏｌ、ＬＰＴＣＰ）のための全体ソフトウェアアーキテクチャ５００を示す。例えば、このアーキテクチャ５００は、図４に示す制御機１３０によって制御されることができる。本発明の一実施例によれば、図５は、アプリケーションによって使用されるネットワークソフトウェア構成要素とソフトウェアアーキテクチャ５００でのＬＰＴＣＰソリューションの使用を示す。

【0069】

図５を参照すると、アーキテクチャ５００は、アプリケーション５１０、ＴＣＰ接続モニタ（ｃｏｎｎｅｃｔｉｏｎ ｍｏｎｉｔｏｒ）（又はラッパー（ｗｒａｐｐｅｒ））５２０、ＴＣＰ接続制御機（ｃｏｎｎｅｃｔｉｏｎ ｃｏｎｔｒｏｌｌｅｒ）５３０、ソケットレイヤライブラリ（ｓｏｃｋｅｔ ｌａｙｅｒ ｌｉｂｒａｒｙ）（又はＬＩＢＣ（Ｌｉｂｒａｒｙ ｆｏｒ Ｃ））５４０、及びカーネル（Ｋｅｒｎｅｌ）５５０を含む。本発明の実施例は、ＴＣＰ接続モニタ５２０及びＴＣＰ接続制御機５３０を含むシステムを使用して具現されるが、本発明の範囲はこれに限定されない。

【0070】

図５に示すように、全てのネットワーク伝送はソケットレイヤライブラリ５４０上で発生する。ＴＣＰ接続モニタ５２０は、ソケットレイヤライブラリ５４０、例えば、ＬＩＢＣ上のラッパー（ｗｒａｐｐｅｒ）である。

【0071】

ＴＣＰ接続モニタ５２０の役割及び任務は以下の通りであるが、これに限定されない。
ａ）ＴＣＰ接続モニタ５２０はソケット呼び出し（すなわち、ソケット、終了、読み込み、作成、伝送／〜に伝送、受信／〜から受信、ｇｅｔａｄｄｒｉｎｆｏ）動作をモニタリングできる。
ｂ）ＴＣＰ接続モニタ５２０は、戻り値（ｒｅｔｕｒｎ ｖａｌｕｅ）として、ストリームソケットピア終了された接続を指示するＰＯＬＬＲＤＨＵＰを確認したり又は接続の半分のライティング（ｗｒｉｔｉｎｇ）をシャットダウンするために、ｐｏｌｌ（）関数を呼び出すことでサーバによって開始されるＴＣＰ接続終了を識別できる。
ｃ）ＴＣＰ接続モニタ５２０は、ＣＬＯＳＥ＿ＷＡＩＴ又はＬＡＳＴ＿ＡＣＫ状態へのＴＣＰ接続状態変化をモニタリングすることでサーバによって開始されるＴＣＰ接続終了を識別できる。
ｄ）ＴＣＰ接続モニタ５２０は、ＴＣＰ接続のシャットダウン（ｓｈｕｔｄｏｗｎ）を行うことができる。
ｅ）ＴＣＰ接続モニタ５２０は、独立型モード（ｓｔａｎｄ−ａｌｏｎｅ ｍｏｄｅ）でＴＣＰ接続の終了を開始できる。
ｆ）ＴＣＰ接続モニタ５２０は、ソケット呼び出しに対するラッパー（ｗｒａｐｐｅｒ）の場合がある（ＬＩＢＣライブラリ内にある場合がある）。
ｇ）ＴＣＰ接続モニタ５２０は、修正されたソケットレイヤの場合がある。

【0072】

ＴＣＰ接続制御機５３０は、スマートフォン上で使用される独立したプロセスである。ＴＣＰ接続制御機５３０は、非活性のＴＣＰ接続を先行終了するための決定及び時間に対して通知する決定ユニット（ｄｅｃｉｓｉｖｅ ｕｎｉｔ）としてＴＣＰ接続モニタ５２０と相互作用する。

【0073】

ＴＣＰ接続制御機５３０の役割及び任務は以下の通りであるが、これに限定されない。
ａ）ＴＣＰ接続制御機５３０は、ＴＣＰ接続の端末側終了に対する通知を開始できる。
ｂ）ＴＣＰ接続制御機５３０は、発生した（ｉｎｖｏｋｅｄ）任意のＴＣＰ接続に対する接続又は終了関数とともに１つ以上のＴＣＰ接続モニタ（例えば、ＴＣＰ接続モニタ５２０）に対するバッチＴＣＰ接続終了を調整することができる。
ｃ）ＴＣＰ接続制御機５３０は、ローソケットパケットキャプチャライブラリ（ｒａｗ ｓｏｃｋｅｔ ｐａｃｋｅｔ ｃａｐｔｕｒｅ ｌｉｂｒａｒｙ）（すなわち、ｌｉｂｐｃａｐ）を介してネットワーク層をモニタリングすることで任意の送信又は受信データパケットと共に１つ以上のＴＣＰ接続モニタ（例えば、ＴＣＰ接続モニタ５２０）に対するバッチＴＣＰ接続終了を調整することができる。（図示せず）
ｄ）ＴＣＰ接続制御機５３０は、ネットワーク統計でパケットカウントの変化をモニタリングすることで任意の送信又は受信データパケットと共に１つ以上のＴＣＰ接続モニタに対するバッチＴＣＰ接続終了を調整することができる。

【0074】

本発明の実施例は、ランダムにサーバによって開始されるＴＣＰ接続終了による電力消費に比べてより良好なバッテリ寿命を達成するための次の方法を含むが、本発明の範囲はこれに限定されない。前述のように、本発明の実施例に係るＴＣＰ接続終了処理方式は、図７に示すように、先行ＴＣＰ接続終了（ｐｒｏａｃｔｉｖｅ ＴＣＰ ｃｏｎｎｅｃｔｉｏｎ ｃｌｏｓｅ）方式７１０、バッチ遅延ＴＣＰ接続終了（ｂａｔｃｈｉｎｇ ｄｅｌａｙｅｄ ＴＣＰ ｃｏｎｎｅｃｔｉｏｎ ｃｌｏｓｅ）方式７２０、及び結合された先行及びバッチＴＣＰ接続終了方式（ｃｏｍｂｉｎｅｄ ｐｒｏａｃｔｉｖｅ ａｎｄ ｂａｔｃｈｉｎｇ ＴＣＰ ｃｏｎｎｅｃｔｉｏｎ ｃｌｏｓｅ）７３０を含む。

【0075】

先行ＴＣＰ接続終了（ｐｒｏａｃｔｉｖｅ ＴＣＰ ｃｏｎｎｅｃｔｉｏｎ ｃｌｏｓｅ）：
図３Ａは、本発明の実施例に係る先行ＴＣＰ接続終了の動作を示す。この終了動作は図１に示すクライアント１００で開始されることができる。

【0076】

図３Ａを参照すると、非活性のＴＣＰ接続４１−４３は先行して終了されるが、このような動作はいかなる追加的な無線状態移行も招かない。これはＴＣＰ接続４１−４３の終了動作のための区間を無線活性化期間の最小時間に設定可能であるからである。この実施例によれば、非活性状態の非恒久的ＴＣＰ接続（例えば、４１−４３）がクライアント装置１００で先に終了される。クライアント装置１００はサーバ開始の終了が発生したＴＣＰ接続のサーバタイムアウトを算出し、安全に終了できる時間の間非活性状態のＴＣＰ接続に対して前記算出されたサーバタイムアウトの前に直ちに終了する。

【0077】

Ａｐｐ−Ａ１１、Ａｐｐ−Ｂ１２及びＡｐｐ−Ｃ１３は、同時にデータ同期化動作を開始する（図３Ａの２０）。データ同期化活性化によって、無線状態はアイドル状態から活性状態に１回のみ移行される（図３Ａの６０）。例えば、この実施例によれば、図２に示すように、４回にわたる無線状態の移行が１回に減るようになる。活性無線状態で、電力消費は状態が活性状態の時まで維持される。この機会を利用して、図５のＴＣＰ接続制御機５３０は設定された未だに非活性のＴＣＰ接続４１−４３を終了する。

【0078】

一方で、サーバによって開始されるクライアントでのＴＣＰ接続に対する終了の動作を図示する図２を参照すると、３つのアプリケーション１０に対するＴＣＰ接続４１−４３の終了動作のために、アイドル状態から活性状態への無線状態変化に対する４つのインスタント（ｉｎｓｔａｎｔｓ）５１−５４が存在する。このように無線状態の変化の回数が多いほどクライアントでの電力消費を大きくなる。

【0079】

上述のようなガードタイムアウトは、進行中のデータ伝送からの本発明の実施形態による先行ＴＣＰ接続終了動作を決定する決定的な属性である。

【0080】

図９Ａは、本発明の一実施例に係る先行ＴＣＰ接続終了動作のために行われるステップ９００を示す。この動作のために、ＴＣＰ接続制御機９１０とアプリケーション側でのＴＣＰ接続モニタ９２０の間の相互作用が存在する。

【0081】

図９Ａに示すように、ＴＣＰ接続モニタ９２０及びＴＣＰ接続制御機９１０は、次の通信ステップに従って相互作用する。

【0082】

ａ）期限が経過したガードタイムアウトを有するＴＣＰ接続モニタ９２０はＴＣＰ接続制御機９１０に先行ＴＣＰ終了を登録する（図９の９３１，９３２）。
ｂ）ＴＣＰ接続制御機９１０は、ＴＣＰ接続又は終了（図９の９３３−１）、新規パケットトランザクション（図９の９３３−２）を待つか、又はタイムアウト満了（図９の９３３）を待ち、一旦それが発生すると、ＴＣＰ接続モニタ９２０に先行終了メッセージを伝送する（図９の９３４）。

【0083】

図９Ｂは、本発明の他の実施例に係る先行ＴＣＰ接続終了動作のために行われるステップ９５０を示す。この動作はＴＣＰ接続制御機９１０を利用できないシナリオを考慮したものである。独立型モードはアプリケーション範囲の一部として展開されることができる。

【0084】

図９Ｂを参照すると、ＴＣＰ接続モニタ９２０は、独立型モード（ｓｔａｎｄａｌｏｎｅ ｍｏｄｅ）で先行ＴＣＰ接続終了を開始する機能を有する。期限が経過したガードタイムアウト９４１を有するＴＣＰ接続モニタ９２０は先行ＴＣＰ接続終了９４２を行う。

【0085】

バッチ遅延ＴＣＰ接続終了（ｂａｔｃｈｉｎｇ ｄｅｌａｙｅｄ ＴＣＰ ｃｏｎｎｅｃｔｉｏｎ ｃｌｏｓｅｓ）：
図３Ｂは、本発明の実施例に係るバッチ遅延ＴＣＰ接続終了の動作を示す。この実施例は、複数のＴＣＰ接続４１−４３が非活性の非恒久的接続に対するバッチとして終了されるように開始する。このような実施例は、図２に示すように、アイドル状態から活性状態への反復的な無線状態移行を防止する。

【0086】

この実施例は、複数のＴＣＰ接続４１−４３をバッチ処理して終了するためにアイドル状態から活性状態への単一の無線移行７２を引き起こす。この実施例によれば、非活性状態の非恒久的ＴＣＰ接続は他のＴＣＰ接続と同時に終了される。サーバ開始の終了が発生したＴＣＰ接続が非活性化されると、非活性化ＴＣＰ接続（例えば、図３Ｂの４１）は他のＴＣＰ接続（例えば、図３Ｂの４２−４３）の接続又は終了が発生する際にバッチ処理してともに終了される。

【0087】

図３Ｂを参照すると、Ａｐｐ−Ａ、Ａｐｐ−Ｂ及びＡｐｐ−Ｃ１０は同時にデータ同期化動作２０を開始する。データ同期化活性化によって、無線状態はアイドル状態から活性状態に移行される（図３Ｂの７１）。しかし、様々なデータ伝送非活性化時間によって、ＴＣＰ接続終了は独立して遅れる場合がある。

【0088】

ガードタイムアウト値は、アプリケーション１０それぞれのＴＣＰ接続のそれぞれ４１−４３によって異なる。したがって、ＴＣＰ接続４１−４３のすべてを共にバッチ処理することは複数の無線状態移行を防止する（図３Ｂの３０）。例えば、この実施例によれば、図２に示すように４回にわたる無線状態の移行が２回に減るようになる。

【0089】

図１０Ａ及び図１０Ｂは、本発明の実施例に係る遅延ＴＣＰ接続終了に対するバッチ動作時に行われるステップ１０００−１，１０００−２を示す。この動作のために、ＴＣＰ接続制御機１０１０とアプリケーションプロセスでのＴＣＰ接続モニタ１０２１−１０２３の間で一定の相互作用が存在する。

【0090】

図１０Ａ及び図１０Ｂに示すように、ＴＣＰ接続モニタ１０１０及びＴＣＰ接続制御機１０２１−１０２３は、次の通信ステップに従って相互作用する：
ａ）期限が経過したガードタイムアウトを有するＴＣＰ接続モニタ１０２１−１０２３はＴＣＰ接続制御機１０１０にＴＣＰバッチ終了をほぼ同時に登録する（図１０Ａのｓｔｅｐ １ １０００−１，１０３１−１０３４）。
ｂ）ＴＣＰ接続制御機１０１０は、ＴＣＰ終了又は最小サーバタイムアウトを待ち（図１０Ｂのｓｔｅｐ ２ １０００−２，１０３５）、一旦それが発生すると、バッチ終了メッセージを伝送する（図１０Ｂの１０３６）。
ｃ）ＴＣＰ接続制御機１０１０からＴＣＰバッチ終了メッセージを受信した後、ＴＣＰ接続モニタ１０２１−１０２３はＴＣＰ接続をバッチ処理して終了する。

【0091】

結合された先行及びバッチＴＣＰ接続終了（ｃｏｍｂｉｎｅｄ ｐｒｏａｃｔｉｖｅ ａｎｄ ｂａｔｃｈｉｎｇ ＴＣＰ ｃｏｎｎｅｃｔｉｏｎ ｃｌｏｓｅ）：
図８は、本発明の実施例に係るＴＣＰ接続先行及びバッチ終了の結合動作を説明するための図である。

【0092】

この動作は、先行ＴＣＰ接続終了方法とバッチＴＣＰ接続終了方法の組み合わせを含む。クライアント装置は、サーバ開始の終了が発生する前に非活性状態の非恒久的ＴＣＰ接続を終了したり、他のＴＣＰ接続の生成又は終了と同時に非活性状態の非恒久的ＴＣＰ接続を終了する。クライアント装置は、平常時は先行終了モードで動作する。もし、先行終了によって無線テール（ｒａｄｉｏ ｔａｉｌ）が長く延長されると予想される場合、クライアント装置は、バッチ終了モードで動作する。例えば、ｔ_{ＧｕａｒｄＴｉｍｅｏｕｔ}＞ｔ_{ＩｎａｃｔｉｖｉｔｙＴｉｍｅｒ}の場合、クライアント装置は、バッチ終了モードで動作する。別の例として、ｔ_{ＧｕａｒｄＴｉｍｅｏｕｔ}＜ｔ_{ＬｏｗＰｏｗｅｒ}の場合、クライアント装置は、先行終了モードで動作する。この実施例は、２つの実施例の節電利益の全体を累積した形態に該当する。この実施例のために所定のガードタイムアウト値が利用される。

【0093】

図１１は、本発明の様々な実施例に係るＴＣＰ制御方法のためのＴＣＰ接続モニタ１１０２とＴＣＰ接続制御機１１０４の間の全体フローを示す。ＴＣＰ接続モニタ１１０２は次のようなステップを行う：
１）ＴＣＰ接続モニタ１１０２は、ソケット、接続、リード、ライトなどのようなソケットアプリケーションプログラムインタフェース（ａｐｐｌｉｃａｔｉｏｎ ｐｒｏｇｒａｍ ｉｎｔｅｒｆａｃｅ、ＡＰＩ）を接続（ｈｏｏｋ）する（図１１の１１１１）。
２）ＴＣＰ接続モニタ１１０２は、ＴＣＰソケットに対するソケットであるか否かを確認する（図１１の１１１２）。正であれば、ステップ１１１３に進み、否であれば、ステップ１１１６に進む。
３）ＴＣＰ接続モニタ１１０２は、ソケットが新たに生成されるとＴＣＰ接続モニタ範囲で新規エントリーを生成し、そうでなければ、時間スタンプ、ガードタイムアウト、サーバタイムアウトなどのようなメタを使用して既存のＴＣＰ接続リスト（又はエントリー）をアップデートする（図１１の１１１３）。
ＴＣＰ接続モニタ１１０２は、ＴＣＰ終了をバッチ処理するＴＣＰ接続制御機１１０４にＴＣＰメタデータをアップデートする（図１１の１１２２）。
ＴＣＰ接続モニタ１１０２は、接続がサーバによって開始される終了であれば、ステップ１１１４に進み、否であれば、ステップ１１１６に進む。
４）ＴＣＰ接続モニタ１１０２は、ＴＣＰソケットリード／ライト動作の時間スタンプに基づいてガードタイムアウトを計算し、ガード時間満了通知のためにタイマーをトリガさせる（図１１の１１１４）。
５）ＴＣＰ接続モニタ１１０２は、一旦ガードタイムアウトが満了したり、ＴＣＰ接続制御機１１０４からバッチ終了通知が受信されると、ＴＣＰ接続を終了する（図１１の１１１５）。
６）ＴＣＰ接続モニタ１１０２は、該当ＬＩＢＣ（Ｌｉｂｒａｒｙ ｆｏｒ Ｃ）ＡＰＩを呼び出す（図１１の１１１６）。

【0094】

ＴＣＰ接続制御機１１０４は、次のようなステップを行う：
１）ＴＣＰ接続制御機１１０４は、ＴＣＰ接続モニタ１１０２からの要求を待つ（図１１の１１２１）。
２）ＴＣＰ接続モニタ１１０２から要求が受信されると、ＴＣＰ接続制御機１１０４は、ＴＣＰ接続モニタ１１０２のメモリエントリーを生成したり既存のエントリーをアップデートする（図１１の１１２２）。
３）ＴＣＰ接続制御機１１０４は、バッチ終了アプローチに対して決定し、ＴＣＰ接続モニタ１１０２にＴＣＰ終了通知をマルチキャスティングする（図１１の１１１５）。

【0095】

図１２は、本発明の一実施例に係る、データ伝送非活性時間又はガードタイムアウトを計算するための動作のフロー１２００を示す。例えば、このフローは図１１に示すＴＣＰ接続モニタ１１０２及びＴＣＰ接続制御機１１０４によって行われることができる。

【0096】

１）ステップ１２１０にて、ソケット、接続、リード、ライトなどのようなソケットＡＰＩが接続される。
２）ステップ１２２０にて、ソケットがＴＣＰソケットであるか否かが確認される。ＴＣＰソケットが確認されると、ステップ１２３０に進み、否であれば、ステップ１２６０に進む。
３）ステップ１２３０にて、サーバＩＰ、ポート、ドメイン名、サーバタイムアウトなどのようなＴＣＰメタ情報が生成／アップデートされる。
４）ステップ１２４０にて、ＴＣＰソケットリード／ライト動作の時間スタンプに基づいてガードタイムアウトが計算される。
５）ステップ１２５０にて、ＴＣＰ接続メタ、すなわちローカルキャッシュにガードタイムアウトがアップデートされる。
６）ステップ１２６０にて、該当ＬＩＢＣ ＡＰＩが呼び出される。

【0097】

図１３は、本発明の一実施例に係る、非活性の非恒久的ＴＣＰ接続に対する先行終了方法のためのＴＣＰ制御の動作フロー１３００を示す。例えば、このフローは図１１に示すＴＣＰ接続モニタ１１０２及びＴＣＰ接続制御機１１０４によって行われることができる。

【0098】

１）ステップ１３１０にて、ＴＣＰソケットリード／ライト動作に基づいて動的にガードタイムアウトが計算され、ガードタイムアウト満了通知のためにタイマーが設定される。
２）ステップ１３１０にて、ソケットリード／ライトが途中に発生する場合、タイマーが再設定される。
３）ステップ１３２０にて、ガードタイムアウト満了まで待機する。
４）ステップ１３３０にて、ＴＣＰ接続が終了される。

【0099】

図１４は、本発明の一実施例に係る、非活性の非恒久的ＴＣＰ接続に対するバッチ終了方法のためのＴＣＰ制御の動作フロー１４００を示す。例えば、このフローは図１１に示すＴＣＰ接続モニタ１１０２及びＴＣＰ接続制御機１１０４によって行われることができる。

【0100】

１）ステップ１４１０にて、ＴＣＰソケットリード／ライト動作に基づいて動的にガードタイムアウトが計算され、ガードタイムアウト満了通知のためにタイマーが設定される。
２）ステップ１４１０にて、ソケットリード／ライト途中に発生する場合、タイマーが再設定される。
３）ステップ１４２０にて、ガードタイムアウト満了まで待機する。
４）ステップ１４３０にて、ガードタイムアウトが正常値又は基準値より長い場合、他のＴＣＰ接続からのデータパケット又は制御パケットと共にバッチ終了が登録される。
５）ステップ１４４０にて、ＴＣＰ接続制御機１１０４からのバッチ終了通知が待機される。
６）ステップ１４５０にて、ＴＣＰ接続制御機１１０２からバッチ終了通知が受信されると、ＴＣＰ接続モニタ１１０２はＴＣＰ接続を終了する。

【0101】

図１５は、本発明の一実施例に係る、非活性の非恒久的ＴＣＰ接続に対する先行及びバッチ終了を含む結合された方法のためのＴＣＰ制御の動作フロー１５００を示す。例えば、このフローは、図１１に示すＴＣＰ接続モニタ１１０２及びＴＣＰ接続制御機１１０４によって行われることができる。

【0102】

ａ）ステップ１５１０にて、ＴＣＰ接続に対するガードタイムアウトがＴＣＰ接続モニタ１１０２でアップデートされる。
ｂ）ステップ１５２０にて、ガードタイムアウトが満了した後、ステップ１５３０にて、ガードタイムアウト値が所定の基準時間又はネットワーク非活性化タイマー値と比較される。ガードタイムアウトの満了はネットワーク非活性の開始によって推定される。
ｃ）ガードタイムアウトが所定のしきい値より小さい場合、ステップ１５６０にて、先行ＴＣＰ接続終了動作が行われる。
ｄ）ガードタイムアウトが所定のしきい値より大きい場合、ステップ１５４０にて、他の進行中の接続に対して、バッチ要求がＴＣＰ接続制御機１１０４に登録される。
ｅ）ステップ１５４０にて、ＴＣＰ接続制御機１１０４からのバッチ終了通知が待機される。
ｆ）ステップ１５５０にて、ＴＣＰ接続制御機１１０２からバッチ終了通知が受信されると、ＴＣＰ接続モニタ１１０２はＴＣＰ接続を終了する。

【0103】

図１６Ａ及び図１６Ｂは、本発明の様々な実施例に係るＬＰＴＣＰ（ｌｏｗ ｐｏｗｅｒ ｔｒａｎｓｍｉｓｓｉｏｎ ｃｏｎｔｒｏｌ ｐｒｏｔｏｃｏｌ）終了動作に対する電力節約面からみた試験結果１６１０，１６２０を示す。

【0104】

図１６Ａ及び図１６Ｂを参照すると、本発明の様々な実施例に係るＬＰＴＣＰ終了動作は、従来のＴＣＰ動作に比べてスマートフォンのような移動端末で１７％程度電源が節約されることが分かる。

【0105】

図１７は、本発明の様々な実施例に係るＴＣＰ制御動作に対するネットワークシグナリング減少面からみた試験結果１７１０，１７２０を示す。この試験結果は、接続分析器（ｃｏｎｎｅｃｔｉｏｎ ａｎａｌｙｚｅｒ）１７００によって得られた結果である。

【0106】

図１７を参照すると、本発明の様々な実施例に係るＬＰＴＣＰ終了動作によれば、シグナリングロード１７１０は１６．２%（１３６→１１４）減少され、接続状態での時間１７２０は、２５．８%（２９分３２秒→２１分５４秒）減少されることが分かる。

【0107】

上述のように本発明の実施例は本発明の様々な実施例はスマートフォン端末のようなクライアント装置でアプリケーションソフトウエアを変更する必要なくユーザーエクスペリエンスを悪化させたりアプリケーション機能に影響を及ぼしたりすることなく、より長いアイドル時間を有するようにしてより高いバッテリ寿命を達成することに役立つ。

【0108】

一方、本発明の詳細な説明では具体的な実施例に関して説明したが、本発明の範囲から逸脱しない限度内で様々な変形が可能であることは勿論である。よって、本発明の範囲は説明された実施例に限定されて定められてはならず、後述の特許請求の範囲だけでなくこの特許請求の範囲と均等なものによって定められるべきである。

【符号の説明】

【0109】

１００ クライアント
１１０ アンテナ
１２０ 送受信機
１３０ 制御機
１３２ タイムアウト計算モジュール
１３４ TCP接続終了モジュール
１４０ メモリ
２００ サーバ
３００ ネットワーク
５００ アーキテクチャ
５１０ アプリケーション
５２０ TCP接続モニタ
５３０ TCP接続制御機
５４０ ソケットレイヤライブラリ
５５０ カーネル

【図1】

【図2】

【図3a】

【図3b】

【図4】

【図5】

【図6a】

【図6b】

【図7】

【図8】

【図9A】

【図9B】

【図10A】

【図10B】

【図11】

【図12】

【図13】

【図14】

【図15】

【図16a】

【図16b】

【図17】