(57)【特許請求の範囲】
【請求項１】
無線チャネルによる通信のための無線部と、
前記無線部による通信を要求する少なくとも１つのアプリケーションを実行するように形成されたプロセッサであって、前記アプリケーションは、実行された場合に、無線部の動作モードを決定するために無線制御論理装置が使用するアクセス情報を提供し、前記アクセス情報は前記アプリケーションによる前記無線部の利用の仕方を規定している、プロセッサと
を有し、前記アクセス情報は、少なくともデータタイプに基づいて調整されるデータ送信周期を少なくとも含み、少なくとも幾つかの異なるデータタイプは異なるデータ送信周期に関連付けられ、前記データ送信周期は、１つ以上の伝送遅延パラメータに基づいて調整することが可能である、無線装置。
【請求項２】
メタアプリケーションが、複数のアプリケーションからアクセス情報を受信し、前記無線制御論理装置が使用する統合されたアクセス情報を提供するように該アクセス情報を処理する、請求項１に記載の無線装置。
【請求項３】
各々のアプリケーションが、前記無線部を用いて送信するためのデータを無線アクセス制御機能部にそれぞれ提供する、或いは前記無線部を用いて送信するためのデータを前記メタアプリケーションに提供し、前記メタアプリケーションは前記データを無線アクセス制御機能部に提供する、請求項２に記載の無線装置。
【請求項４】
前記アクセス情報が、
前記アプリケーションのアクティブ状態とインアクティブ状態との間の切り替えを示す通知、及び
少なくとも１つの送信遅延パラメータに基づいて調整される遅延トレランスのレベル
のうちの少なくとも１つを有する、請求項１に記載の無線装置。
【請求項５】
前記少なくとも１つのアプリケーションが複数のサービスを提供し、
前記アクセス情報が前記アプリケーションのアクティブ状態とインアクティブ状態との間の切り替えを示す通知を有し、前記アプリケーションが前記複数のサービスを監視し、前記通知を発行する時を決定し、
データを周期的に生成する他のサービスと同期して送信されるように、前記サービスの少なくとも幾つかのデータがバッファに蓄積され、及び／又は
前記アプリケーションが、前記アプリケーションにより提供される現在のサービスに依存している前記遅延トレランスのレベルを有する、請求項４に記載の無線装置。
【請求項６】
前記アクセス情報が遅延トレランスのレベルの情報を有し、前記アプリケーションが、送信されるべきデータのタイプを判別する、請求項１に記載の無線装置。
【請求項７】
必須でないサービスのみが動作していると判断された場合、又は必須でないサービスのみによるインアクティブ状態への遷移が禁止されていると判断された場合、前記アプリケーションは前記必須でないサービスを中止するか否かを判断し、該判断はバッテリ状態を考慮に入れてなされる、請求項５に記載の無線装置。
【請求項８】
（ｉ）呼の終了時点、
（ｉｉ）プレゼンス同期が完了した時点、及び
（ｉｉｉ）ファイル転送が完了した時点
のうちの少なくとも１つにおいてＶｏＩＰアプリケーションにより前記通知が生成される、請求項４に記載の無線装置。
【請求項９】
無線装置の無線部の動作モードを制御する方法であって、
少なくとも１つのアプリケーションを実行するステップであって、前記アプリケーションは、無線部の動作モードを決定するために無線制御論理装置が使用するアクセス情報を提供し、前記アクセス情報は前記アプリケーションによる前記無線部の利用の仕方を規定している、ステップ
を有し、前記アクセス情報は、少なくともデータタイプに基づいて調整されるデータ送信周期を少なくとも含み、少なくとも幾つかの異なるデータタイプは異なるデータ送信周期に関連付けられ、前記データ送信周期は、１つ以上の伝送遅延パラメータに基づいて調整することが可能である、方法。
【請求項１０】
請求項９に記載の方法を前記無線装置のコンピュータに実行させるコンピュータプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は電力消費を減らす目的で無線装置の無線通信の動作モードを制御すること等に関連する。
【背景技術】
【０００２】
図1にはそのような無線装置が概略的に示されている。無線装置1はコードの形式でプログラムを実行するマイクロプロセッサ2を含み、プログラムはマイクロプロセッサ2内にローカルに保持されていてもよいし或いはマイクロプロセッサ2に接続されたメモリ4に保持されていてもよい。移動装置1は無線アクセスチップ6を有し、無線アクセスチップ6は、例えば移動装置1とネットワーク8との間で無線周波数(RF)通信信号を送受信する。移動装置1は電力供給部を有し、電力供給部は図示されているようなバッテリ10の形式であってもよく、及び/又は移動装置1は外部の電力供給部(図示せず)と接続されていてもよい。
【０００３】
移動装置は不図示の他の多くの要素を含んでいてもよいことは明らかであり、他の多くの要素が不図示であるのはそれらが実施の形態に密接な関係を有していないからである。
【０００４】
移動装置1とネットワーク8との間のRF通信は、無線アクセスチップ6により、無線チャネル上でRF信号を送信及び受信することで実行される。あるチャネル上で送信又は受信する場合、無線部に電力が供給されなければならない。一方、無線部が使用されていない場合、無線部の電源は落とされ或いは節電モードに移行して装置1の電力消費を減らす。
【０００５】
従来技術として、セルラネットワークにおける無線通信を行うため、ネットワークは移動装置の通信を管理する基地局を含む。3GPP標準規格の一部として発展したロングタームエボリューション(LTE)標準規格では、移動装置における電力を節約する仕組みが導入されている。無線ネットワークで通信されるデータの品質は絶え間なく向上しているので、そのような移動装置の電力消費を減らすことが継続的に要請されている。LTE標準規格で採用されている方法によれば、無線装置は間欠受信(DRX)及び/又は間欠送信(DTX)状態になることが可能であり、DRX及び/又はDTXは、基地局との間で交渉又は決定された或る所定のインアクティビティタイマ値又は不活性タイマ値に基づいて、無線装置が長い期間にわたってスリープ状態にすることを許可する。LTE標準規格の場合、基地局はエンハンストノードB(eNB)と言及される。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】国際公開第2007/149732号
【特許文献２】米国特許出願公開第2004/076177号明細書
【特許文献３】米国特許出願公開第2007/178875号明細書
【発明の概要】
【発明が解決しようとする課題】
【０００７】
しかしながら、これらのインアクティビティタイマ値は、あまりに包括的(generic)であり、任意の所与の時点で無線装置に生じる特定のネットワークトラフィック活動を考慮できない。
【０００８】
本発明の課題は無線アクセス装置の節電機能を強化することである。
【課題を解決するための手段】
【０００９】
実施の形態による方法は、
無線装置の無線部の動作モードを制御する制御方法であって、
少なくとも１つのアプリケーションを実行するステップであって、前記アプリケーションは、無線部の動作モードを決定するために無線制御論理装置が使用するアクセス情報を提供し、前記アクセス情報は前記アプリケーションによる前記無線部の利用の仕方を規定している、ステップ
を有する制御方法である。
【図面の簡単な説明】
【００１０】
【図１】ネットワークで通信を行う無線装置の概略図。
【図２】プロトコルスタックのレイヤを示す図。
【図３】MACレイヤとやり取りを行うアプリケーションレイヤの概略図。
【図４】アプリケーションレイヤとMACレイヤとの間にアクセス情報を提供するアーキテクチャの概略図。
【図５】メタアプリケーション(meta-application)を実行する第1のアーキテクチャの概略図。
【図６】メタアプリケーションを実行する第2のアーキテクチャの概略図。
【発明を実施するための形態】
【００１１】
＜発明の概要＞
本発明の一形態により提供される方法は、
無線装置の無線部の動作モードを制御する制御方法であって、
少なくとも１つのアプリケーションを実行するステップであって、前記アプリケーションは、無線部の動作モードを決定するために無線制御論理装置が使用するアクセス情報を提供し、前記アクセス情報は前記アプリケーションによる前記無線部の利用の仕方を規定している、ステップ
を有する制御方法である。
【００１２】
本発明の別の形態により提供されるコンピュータプログラム(プロダクト)は、
アプリケーションを形成するプログラムコードを有し、プロセッサに制御方法を実行させるコンピュータプログラムであって、前記制御方法は、無線部の動作モードを決定するために無線制御論理装置が使用するアクセス情報を提供するステップであって、前記アクセス情報は前記アプリケーションによる前記無線部の利用の仕方を規定している、ステップを有するコンピュータプログラム(プロダクト)である。
【００１３】
本発明の別の形態によリ提供される無線装置は、
無線チャネルによる通信のための無線部と
前記無線部による通信を要求する少なくとも１つのアプリケーションを実行するように形成されたプロセッサであって、前記アプリケーションは、無線部の動作モードを決定するために無線制御論理装置が使用するアクセス情報を提供し、前記アクセス情報は前記アプリケーションによる前記無線部の前記無線部の利用の仕方を規定している、プロセッサ
を有する無線装置である。
【００１４】
本発明の別の形態により提供される方法は、
無線装置の無線部の動作モードを制御する制御方法であって、
少なくとも１つのアプリケーションを実行するステップであって、前記アプリケーションは、前記無線部を用いて前記無線装置から送信するための少なくとも１つのタイプのデータを生成し、前記データは前記アプリケーションにより決定された間隔で送信するために無線制御論理部に出力される、ステップと、
送信のために生成されたデータの前記タイプを判別するステップと、
データの前記タイプに基づいて前記間隔を前記アプリケーションにより調整するステップと
を有する制御方法である。
【００１５】
本発明の別の形態により提供される無線装置は、
無線チャネルによる通信のための無線部と
前記無線部による通信を要求する少なくとも１つのアプリケーションを実行するように形成されたプロセッサであって、前記アプリケーションは、実行された場合に、前記無線部を用いて当該無線装置から送信するための少なくとも１つのタイプのデータを生成するように形成され、前記データは前記アプリケーションにより決定された間隔で送信するために無線制御論理部に出力され、前記アプリケーションは、送信のために生成されたデータの前記タイプを判別しかつデータの前記タイプに基づいて前記間隔を調整するように形成されている、プロセッサ
を有する無線装置である。
【００１６】
本発明の別の形態により提供されるコンピュータプログラム(プロダクト)は、
アプリケーションを形成するプログラムコードを有し、プロセッサに制御方法を実行させるコンピュータプログラムであって、前記制御方法は、無線部を用いて送信するための少なくとも１つのタイプのデータを生成し、前記データは前記アプリケーションにより決定された間隔で送信するために無線制御論理部に出力され、前記アプリケーションは、送信のために生成されたデータの前記タイプを判別しかつデータの前記タイプに基づいて前記間隔を調整するステップを有する、コンピュータプログラム(プロダクト)である。
【００１７】
本発明の理解を促すため及び本発明がどのようにして実施されるかを説明するため、一例として図面を参照しながら説明を行う。
【００１８】
＜好適な実施形態の説明＞
図1に関連して説明したタイプの無線装置の観点から本発明を説明する。無線装置は、例えばUMTS、HSDPA、ワイマックス(Wimax)、LTE又はワイファイ(Wifi)のような少なくとも1つの無線アクセス技術を使用する任意のユーザ装置(UE)とすることができる。プロセッサにより実行されるソフトウェアは、図2に示すようなタイプのプロトコルスタックに組織されている。図2はスタックの単なる一例にすぎず、現在使用されている様々な形態が存在し、本発明は任意のタイプのスタックに適用できる。図2に例示されているスタックは、アプリケーションレイヤ12と、トランスポートレイヤ14と、インターネットレイヤ16と、リンクレイヤ18とを含む。リンクレイヤは、物理リンクレイヤ20と媒体アクセス制御(MAC)レイヤ22とに細分される。
【００１９】
リンクレイヤは装置1の通信方式又は通信技術を組織又は管理する責務を有する。リンクレイヤ18内の媒体アクセス制御(MAC)レイヤ22は、特に、様々なユーザをアドレス指定し、様々なユーザに複数のチャネルを割り当て、衝突を回避する責務を有する。特に、MACレイヤは無線機の動作モードを制御する責務を有する。MACレイヤは、送信されるべきデータを並べる(待ち行列に入れる)バッファと、制御論理装置とを含み、これらについては後述する。各々のレイヤは異なる無線装置における等価な又は対応するレイヤと通信を行うことが可能であり、リンクレイヤ18はRFデータの状態でフレーム形式で別の装置の対応するリンクレイヤと通信する。フレームは無線アクセスチップ6とネットワーク8との間のチャネルを介して送受信され、各々のアクセスは無線装置に電源が投入されていることを要する。「アクセス」という言葉は、データを送信及び/又は受信できるように、無線アクセスチップがネットワーク8又は他の装置と通信する状態を示す。上述したDRX/DTXを実行するLTE標準仕様によれば、リンクレイヤが所定の時間間隔の間何も送信しなかった場合、無線機は電源を落としてもよい或いは電力節約モード(節電モード)に入ってもよい。
【００２０】
この場合、例えばそのチャネルで媒体アクセス制御レイヤがフレームを送信する試みのような次のアクセスの直前に、無線機が電源を落としてしまう或いは節電モードに入ってしまうおそれがある。これは、無線機の動作モードを不必要に切り替えることになる。更に、無線機が「起動(wake  up)」する度に無線機はいちいちノード8や基地局に通知するので、そのような不要なモード変更はノードBや基地局に対するシグナリングオーバーヘッドを増やしてしまう。
【００２１】
以下に説明するように、本発明の実施の形態はそのような従来例を上回る改善をもたらす。先ず、スタック内の他のレイヤを説明する。
【００２２】
インターネットレイヤは、IP(インターネットプロトコル)ヘッダと共にIPデータを搬送するパケットの形式でインターネット通信を行う機能を提供し、かつIPアドレスを指定又は設定するIPアドレッシング機能も提供する。
【００２３】
トランスポートレイヤ14は、例えば伝送制御プロトコル(TCP)又はユーザデータグラムプロトコル(UDP)等に従って、通信を受け入れるようにホストを動作させる。この場合において、ホストは無線による通信を求める任意の種類のユーザ装置である。
【００２４】
アプリケーションレイヤ12は、通信しているホスト同士の間でプロセス間でアプリケーションによるやり取りを処理する。チャネルを通じて送信されるべきデータを生成するユーザアプリケーションを動作させるのはこのレイヤである。従って、本発明の実施の形態は、媒体アクセス制御レイヤ22により少なくとも1つの無線アクセス技術を用いてインターネット8に接続する少なくとも1つのアプリケーションをユーザ装置が動作させる観点から説明される。
【００２５】
本発明は多数の様々なアプリケーションと共に利用できるが、1つの特定の例はソーシャルコミュニケーション(social  communication)に関連し、例えばUE間のボイスオーバインターネットプロトコル(Voice  over  Internet  Protocol：VoIP)や、インスタントメッセージング(Internet  Messaging：IM)チャットや、会議の際に行われる実況会議中継又はライブミーティング(live  meeting)等である。これらの種類のサービスと共に、アプリケーションは、ファイル転送のようなデータ転送を行う責務や、ソーシャルネットワークの連絡先に対するプレゼンス情報(presence  information)又は「キープアライブ(keep-alive)」データのような制御データを更新すること等を行う責務を有する。本願においてアプリケーションレイヤで動作するアプリケーションは、そのような全ての可能性を網羅するように解釈される。
【００２６】
説明される本発明の実施の形態では、アプリケーションレイヤ12で動作する或るアプリケーションは、予想される将来のデータ送信又は受信をMACレイヤ22に通知する。これは、MACレイヤが、アプリケーションのチャネルアクセスに対する無線機の節電スケジュールを採用することを許容する(MACレイヤが、アプリケーションによるチャネルアクセスを考慮して、無線機の電力節約の予定を立てることを可能にする)。MACレイヤは様々な動作モードを含む節電スケジュールを有し、様々な動作モードは例えばスリープ(sleep)、アイドル(idle)、DRX/DTX等のような節電モードを含む。予定されているチャネルアクセスをMACレイヤ22に通知することで、多くの利点が得られる。先ず第1に、アプリケーションが終了すると、節電モードを起動するためにタイムアウト期間を待機することなく、速やかに節電モードにはいることができる。これにより大幅に電力を節約できる。第2に、アプリケーションが近い将来の活動又はアクティビティを報告した場合に、MACレイヤは、節電を中止する、或いは、より深い(より休止期間の長い)節電モードに入ることを回避できる。節電モードから無線機を起動させるには或る程度の時間と電力を要するので、これは有益である。
【００２７】
図3を参照しながら本発明を説明する。この実施の形態の場合、アプリケーションレイヤで動作しているアプリケーション30はアクティブ状態及びインアクティブ状態という2つの基本状態を有し、アクティブ状態は定常的な無線アクセスを必要とし、インアクティブ状態はそれを必要としない。一例として、IMチャット、VoIP呼、実況会議中継(ライブミーティング)等のようなアプリケーションにおける通信セッションを考察する。インアクティブ状態は、現在のアプリケーションセッションが終了していることを示す。アプリケーション30がアクティブ状態からインアクティブ状態に切り替わる又は遷移する時は常に、MACレイヤ22にそのインアクティブ状態を通知し、MACレイヤ22が節電モードに速やかに移行又は遷移できるようにする。オプション又は選択肢の1つとして、DRX起動メッセージを基地局eNBに送信してもよい。MACレイヤ22は制御論理装置34を含み、制御論理装置34は、アプリケーションレイヤで動作している複数のアプリケーションから通知を受信し、そのようなアプリケーションの全てがインアクティブである状況が生じたか否かを判定又は判断する。そのような状況が生じた場合、制御論理装置34はMACレイヤ22に節電モード36を採用させる。アクティブであるアプリケーションが残っていた場合、制御論理装置34は無線部を起動状態に留めるモード38をMACレイヤ22に採用させる。
【００２８】
インアクティブからアクティブに移行又は遷移する場合、アプリケーションはMACレイヤ22に明示的に通知してもよいし、或いは単にMACレイヤ22にデータを提供してもよい。
【００２９】
アプリケーションがインアクティブ状態に入っているか否かの判断は、必ずしも直接的に行われなくてもよい。アプリケーションが典型的には連動していない多数の並列的なサービスを有する状況では、アプリケーションは、「インアクティブ」の通知32を送信する前に、それらのサービスの全てを監視することができる。一例として、VoIPアプリケーションが或るサービス又は呼を終了し、ユーザが電話を切っているが、例えばプレゼンス情報の更新のような別のサービスが直後に始まるかもしれない。VoIPアプリケーションのインアクティブ状態は、例えば、(i)呼の終了時点、(ii)プレゼンス同期(presence  synchronization)が完了した時点、及び(iii)ファイル転送が完了した時点等の何れかの状態により判別することができる。
【００３０】
あるいは、必須でないサービスのみが動作していると判断された場合、無線機が節電モードに移行できるように、アプリケーションは必須でないサービスを中止することを選択してもよい。更に、バッテリレベルが所定の閾値未満である場合にのみ、必須でないサービスが中止されるように、(オペレーティングシステムを通じて取得される)バッテリ状態の情報を考慮して判断が行われてもよい。
【００３１】
本発明の別の実施の形態では、アプリケーションは周期的(規則的)な間隔でデータを送信している。例えば、装置1がファイヤウォールの背後に存在する場合、周期的なデータは、外部ネットワークとの接続又はコネクションを失わないためのキープアライブデータ(keep  alive  data)とすることができる。別の例は、ボイスオーバIP(VoIP)アプリケーションにおいてオーディオコーデックフレームレートでデータを送信することである。アプリケーションは、MACレイヤ22にその周期を通知し、周期が変わる毎にそれを更新する。アプリケーションが複数のサービスを実行している場合、周期性を確保するために、アプリケーションは、1つ以上のサービスにより生成されたデータをバッファに蓄積し、周期的にデータを生成する他のサービスと同期してそれを送信する。周期性に関する情報は、アプリケーションレイヤ12で動作している多数のアプリケーションから取得できる。この情報はMACレイヤ22の制御論理装置34により受信される。その周期性とアプリケーションがデータを送信した最後の時間とにより、制御論理装置は、そのアプリケーションからの次に予想されるデータ送信までの時間を推定することができる。全てのアプリケーションについてのこれらの時間を統合することで、何らかのアプリケーションがデータを送信するまでの時間testを推定することができる。制御論理装置34は、推定された時間testを利用して、節電モード36に切り替わる或いは起動モード38に留まる価値があるか否かを判断する。
【００３２】
特に、MACレイヤ22は様々な方法で周期性の情報を利用することができる。周期性の情報は、何れのDRX/DTXサイクルが起動されるべきかを知るために利用可能である。ただし、そのような選択を行う機能が無線装置に備わっていることを仮定している。
【００３３】
追加的に及び代替的に、アイドルモードについて、より長いインアクティビティタイマの設定値を使用することで、アイドルモードへの移行を遅延させるために、周期性の情報が無線装置により使用されてもよい。その理由は、アプリケーションによる次のメッセージによりアイドルモードは中断されかつネットワーク再エントリに起因する余分なシグナリングオーバーヘッドを招いてしまうことが既に判明しており、むしろ長いDRX/DTXサイクルはより良い節電効果をもたらすからである。従ってこれは無線装置が電力を節約するだけでなくシグナリングオーバーヘッドも節約することを可能にする。
【００３４】
MACレイヤ22が無線機にアクティブであることを要求する期間の長さを短くするように、データを送信する間隔を適合させる又は調整することで、アプリケーションは、そのような手段の利用の仕方を最適化してもよい。MACレイヤが無線機を起動(アクティブ)モードに留める場合、Xミリ秒の期間にわたってアクティブを維持すると仮定する。アプリケーションがYミリ秒(Y＞X)の間隔でデータを送信する場合、無線機はX/Yの時間起動することになる。従って、Yを増加させることで、起動時間及び電力消費は大幅に削減可能である。LTEのDRX/DTX方式に言及しながら背景技術で説明したような節電がタイムアウト期間に基づいているシステムでは、このようなことは不可能である。なぜなら、そのようなタイムアウト期間は、送信が周期的でない場合、過剰な節電モード切替を避けるためにかなり大きくしなければならないからである(タイムアウト期間＞Y)。そのような状況においてYを増加させると、長い遅延を導入するだけであり、節電効果は少ない。データが、呼(call)の最中に送信される音声データのようなリアルタイムデータである場合、受信信号で聴き取れるほどの遅延を導入しないためには、Yは或る閾値までしか増やすことができない。
【００３５】
ファイル転送のようにデータ送信がリアルタイムでない場合も、MACレイヤ22の送信バッファがあふれないように(又は過重に負担がかからないように)、送信間隔を制限する必要がある。
【００３６】
従って、アプリケーションは、送信されるデータのタイプを判別し、かつデータを送信する間の所定の間隔をMACレイヤ22に適用する。所定の間隔は送信されるデータのタイプに依存してもよい。その間隔は、データのタイプ単独の関数である必要はなく、他のパラメータも考慮に入れてよい。例えば、リターントリップタイム又はラウンドトリップタイム(RTT)やMACレイヤのバッファサイズ等の情報が考慮されてもよい。
【００３７】
図4はアーキテクチャを示し、このアーキテクチャを用いて、アクセス情報をアプリケーションレイヤ12からMACレイヤ22へ供給できる。図4はアプリケーションレイヤで動作する3つのアプリケーションApp1、App2、App3と、アプリケーションインタフェース(API)とを示し、アプリケーションインタフェース(API)は例えば無線装置のオペレーティングシステムで実現されてもよい。アプリケーションがMACレイヤに供給するアクセス情報を持っている場合、アプリケーションはAPIから或る関数を呼び出し、その関数はAPIがアクセスできる形式でデータが保存されるようにする。この情報は、MACレイヤ22からの要求に応じて又は適切な他の何らかの方法でMACレイヤ22に供給することができる。
【００３８】
図4のアーキテクチャは以下に説明する本発明の実施の形態にも適用可能である。
【００３９】
本発明の別の実施の形態によれば、アプリケーションレイヤで動作しているアプリケーションは、現在のリアルタイムの制約(constraints)をMACレイヤ22に通知する。すなわち、リアルタイムの制約又はアプリケーションの遅延トレランス(delay  tolerance)を示すメッセージ50がアプリケーションから通知される。これは制御論理装置34に供給され、無線部が節電モード36又は起動モード38の何れで動作すべきかを決定する。無線部が節電モードで動作している場合にアプリケーションレイヤからデータが受信された場合、無線部は起動してデータを速やかに送信する、或いは無線部は節電モードに留まりまとめて送信する多くのデータを待機する。後者はいっそう電力効率が良い。なぜなら、より長く節電モードに留まりかつモード間の切り替えを少なくするからである。一方、VoIPアプリケーションのようなリアルタイムデータの場合、そのように引き起こされる待機時間が通話品質を劣化させるかもしれない。リアルタイムの制約/遅延トレランスをアプリケーションからMACレイヤに提供することで、MACレイヤは、節電モードから切り替わるべきか否かを、豊富な情報に基づいて制御論理装置34により判断できる。
【００４０】
リアルタイムの制約は異なる理由により時間と共に変化してもよい。例えば、ネットワークコネクションを失わないようにするため、連絡先(contact)のプレゼンス情報を更新するため、或いはファイル転送のような他のサービスを実行するために、呼又は通話を現在行っていないVoIPアプリケーションでさえしばしばデータを送信してもよい。このタイプのサービスが行われている限り、これら全てのデータはリアルタイムの制約を有しておらず、MACレイヤは長い遅延トレランス(又は強い遅延耐性)の通知を受けるべきである。更に、会話の劣化はラウンドトリップ時間(RTT)に対して線形に増えるのではなく、指数関数的に増えることが知られている。例えば、現在のRTTが非常に短かった場合、通信に数十ミリ秒追加することは、会話の品質にほとんど影響を与えないので、電力消費を減らすために許容できる。アプリケーションが複数のサービス(S)を実行していた場合、これらのサービスのリアルタイムの制約は1つに統合される又はまとめられるべきである。好ましくは、最も厳しいリアルタイムの制約が使用される。
【００４１】
ラウンドトリップ時間は、多種多様な方法で決定できる既存の伝送遅延パラメータである。例えば、パケットの送信時間(タイムスタンプ)をパケットのペイロードに付加することができる。受信機はこのタイムスタンプを抽出し、それを別のパケットで送信機に返送し、その後、送信機は、フィードバックされてきたパケットの受信時間とタイムスタンプとの間の時間差としてRTTを推定することができる。
【００４２】
本発明の上記の実施の形態は、MACレイヤ22と相互にやり取りを行う用に設計された特定のメタアプリケーション(meta-application)を用いて実現することができる。メタアプリケーションは、複数のアプリケーションからMACレイヤへ指定された方法により情報を通信する機能を提供する。アーキテクチャの1つが図5に示されている。このアーキテクチャによれば、複数のアプリケーションApp1、App2、．．．AppNがメタアプリケーションMAに登録している。メタアプリケーションはオペレーティングシステムで動作することが可能である。メタアプリケーションは、全てのアプリケーションから到来したデータを処理し、かつそのデータをMACレイヤ22のソケット23に提供する。メタアプリケーションはアクセス情報統合部23を含み、アクセス情報統合部23は上記のタイプのアクセス情報を統合又は結合し、それをMACレイヤ22に供給する。このアーキテクチャの場合、アプリケーションレイヤとMACレイヤとの間の全ての通信はメタアプリケーションにより処理される。これは、図4を参照しながら説明したようなAPIにより実行可能である。
【００４３】
図6は代替的なアーキテクチャを示し、アプリケーションApp1、App2、．．．AppNの各々が各自のIPソケット231、232、．．．23NによりMACレイヤ22との間で各自のデータを通信している。アクセス情報は各々のアプリケーションからメタアプリケーションMAに供給され、メタアプリケーションMAは統合されたアクセス情報をMACレイヤ22に供給する。このアーキテクチャの場合、メタアプリケーションがMACレイヤに通知するものに基づいて、アプリケーションは、MACアクセス頻度とタイミング/位相ポイントとを、メタアプリケーションとの間で決定する。メタアプリケーションは、全てのアプリケーションが以後各自の処理を行う周期及びアクティビティ/インアクティビティをMACレイヤに通知する。
【００４４】
アクセス情報が周期的である上記の実施の形態の場合、複数のアプリケーションの周期がメタアプリケーションにおいて比較されてもよい。その後、メタアプリケーションはアプリケーションの統合された周期をMACレイヤ22に報告することができる。例えば、2つのアプリケーションがそれぞれインターネットに10秒毎に接続し、それらのアプリケーションはサイクルの半分だけ位相がずれているとする。この場合、メタアプリケーションは、アプリケーションがインターネットに接続する統合されたレートは、5秒毎であることを判断する。これはMACレイヤ22に報告され、無線部がインアクティブ状態に移行するタイミングをMACレイヤが制御できるようにする。
【００４５】
ユーザ装置で動作する任意のアプリケーションがメタアプリケーションに登録できる。このようにして、登録された全てのアプリケーションを、メタアプリケーション内で動作するサービスとして考慮できる。
【図１】
0006022486.tif 000002
【図２】
0006022486.tif 000003
【図３】
0006022486.tif 000004
【図４】
0006022486.tif 000005
【図５】
0006022486.tif 000006
【図６】
0006022486.tif 000007