JP2015207835A - アプリケーションに応じた複数の送信キューを有するカーネルプログラム、装置及び方法 - Google Patents

Abstract

【課題】アプリケーションに影響を与えることなく、瞬間的な大量の送信パケットの発生を分散させることができるカーネルプログラム、装置及び方法を提供する。【解決手段】アプリケーションから出力された送信パケットをネットワークへ送信するパケットフィルタリング手段を有するカーネルプログラムについて、送信パケットの送信元ポート番号又は宛先アドレスからアプリケーション名を検索するアプリ名解決手段と、アプリケーション名に応じて異なる複数の送信キューと、パケットフィルタリング手段に対して、送信元ポート番号又は宛先アドレス及び送信キューの設定テーブルを更新するテーブル更新手段としてコンピュータを機能させる。パケットフィルタリング手段は、設定テーブルを用いて、送信パケットをいずれかの送信キューへ出力する。送信キューはそれぞれ、異なる時間タイミングで、バッファしている送信パケットをバースト的に送信する。【選択図】図４

Description

本発明は、スマートフォンに搭載されるカーネルプログラムの技術に関する。

現在、３Ｇ(3rd Generation)やＬＴＥ(Long Term Evolution)のような携帯電話網に、急速に普及した大量のスマートフォンが接続するようになってきている。スマートフォンは、音声通話やメール送受信に限られず、パーソナルコンピュータと同様に、ネットワークを介してサーバにアクセスしながら、ユーザに多様なサービスを提供することができる。また、スマートフォンには、ユーザ自ら、多数のアプリケーションをインストールすることができる。これらアプリケーションの一部は、スマートフォンの使用状況に関係無く、ネットワークを介してサーバとの間で、定期的又は不定期的に通信する。各アプリケーションが送信パケットを発生させる毎に、スマートフォンは、携帯電話網に対してセッション確立のためのシーケンスを実行する。その際、携帯電話網の通信事業設備に対して、多数のシグナリングをが発生する。

スマートフォンに、ユーザ自らインストールするアプリケーションの数は、増加傾向にある。各アプリケーションの中には、バックグランド（ユーザの操作に拘わらず）にあっても、自らの判断で送信パケットを発生するものが存在するために、携帯電話網に対するシグナリングの数も極めて増加してきている。これによって、携帯電話網のシステム全体（伝送路や通信事業設備）における処理負荷も大きくなり、リソースやコストの増大を招くこととなっている。

現在、世界で最も普及が進むスマートフォン用ＯＳであるAndroid（登録商標）を採用する端末について、インストールアプリ数の平均は３３個（２０１３年時点の米国平均）であるという調査結果がある（例えば特許文献１参照）。また、例えばＬＩＮＥ（登録商標）のＩＭ(Instant Message)アプリケーションによれば、バックグランドで、頻繁に携帯電話網に接続し、新規メッセージの到達を確認している。

ここで、スマートフォンと携帯電話網との間は、常時接続しているわけではなく、アイドル状態（非通信状態）とアクティブ状態（通信状態）とを交互に切り替えている。例えばＬＴＥによれば、以下のような状態遷移で表されている（例えば非特許文献２参照）。
アイドル状態(RRC_IDLE)<->アクティブ状態(RRC_CONNECTED)
RRC：Radio Resource Control

（アイドル状態->アクティブ状態）
アプリケーションが送信パケットを発生した場合、スマートフォンの無線通信インタフェースは、アイドル状態からアクティブ状態へ遷移し、通信路を確立する。このとき、スマートフォンと携帯電話網との間で、多数のシグナリング発生を伴うシーケンスが実行される。そして、通信路が確立されてアクティブ状態となり、アプリケーションは、携帯電話網を介してアプリケーションサーバと通信することができる。

（アクティブ状態->アイドル状態）
携帯電話網における限られた無線リソースを有効利用するために、無通信時間が一定時間（Inactivity Timerと称されるタイマ値以上）続く場合には、アクティブ状態からアイドル状態へ遷移し、携帯電話網との通信路を切断する。Inactivity Timerの時間値は、携帯電話基地局により設定される。また、その時間値は、基地局毎及び通信キャリア毎に異なるが、都市部では、無線リソースを有効利用するために、短めに設定される傾向にある。例えば米国のボストン周辺では、約0.6秒程度との調査結果もある（例えば非特許文献２参照）。

図１は、スマートフォンにインストールされたアプリケーションによって発生するバックグランドの通信発生頻度を表すグラフである。

図１のグラフは、本願発明者自らが計測したものである。初期状態のスマートフォン（2014年2月時点で最新のAndroid OSを搭載）に、米国平均の３３個のアプリケーションをインストールした。アプリケーションは、Google Play（登録商標）のランキング上位のものから、無作為に選択したものである。そして、ユーザが全く操作しないバックグランドで、スマートフォン自らが送受信するパケットを、９０分間計測した。

図１によれば、バックグランドで断続的かつ頻繁に、通信が実行されている様子が確認できる。また、断続的かつ頻繁に通信が発生する毎に、無線通信インタフェースは状態を遷移し、携帯電話網に対するシグナリングを発生させることとなる。そのために、多数のスマートフォンにおける無線通信インタフェースの頻繁な状態遷移は、携帯電話網に対して大量のシグナリングが発生することとなる。大量に発生するシグナリングは、携帯電話網の通信事業設備に対する処理負荷の増加を招き、コストの増加につながっている。

特に、多数の端末が、同一時刻に、無線通信インタフェースの状態遷移によってシグナリングを発生させた場合が問題となる。携帯電話網の通信事業設備にとっては、瞬間的に大きな処理負荷がかかり、携帯電話の通信品質にも影響を及ぼすこととなる。

図２は、従来技術における突発的なシグナリングの発生を表す説明図である。

図２によれば、３台のスマートフォンａ，ｂ，ｃそれぞれが、異なるユーザによって所持されており、人気のアプリケーションＡ，Ｂ，Ｃがインストールされているとする。各アプリケーションは、必要な時にパケットを発生させ、そのパケットは、RRC_connectedの際に送信される。

ここで、これらアプリケーションが、同一時刻に通信を発生させた場合、突発的にシグナリングが増加することとなる。特に人の時間間隔によれば、アプリケーションに対して定時刻（例えば１時間毎、１５分毎、１０分毎、５分毎、１分毎、・・・）に設定することが多い。そのために、多数且つ多様なアプリケーションは、比較的、定時刻に送信パケットを発生させる場合がある。例えば起床アラームと共に携帯電話網に接続し、天気予報等の情報を利用者に提示するアラームアプリケーションによれば、「７：００」ような定時刻には、大量のユーザのスマートフォンから通信トリガが発生することとなる。こうした通信トリガは、スマートフォンにおけるネットワークに対する時刻同期は極めて精度が高いために、全く同一時刻に発生することとなる。

これに対し、従来、バックグランドの通信トラヒックに起因する、携帯電話網のシグナリングを削減する技術がある（例えば非特許文献４参照）。この技術は、ＮＳＲＭ(Network Socket Request Management)と称され、スマートフォンのハードウェアにおける通信チップによって実現される。

図３は、ＮＳＲＭにおけるアプリケーションの通信パケットの遅延を表す説明図である。

図３によれば、スマートフォンについて２つの状態が表されている。
バックグランド状態：ユーザによってスマートフォンが操作されてなく、
ディスプレイがオフになっている状態
フォアグランド状態：ユーザによってスマートフォンが操作されており、
ディスプレイがオンになっている状態

バックグランド状態の場合、無線通信インタフェースの送信バッファは、例えば１０分間のうち１分間(Topen)のみゲートオープンとなる（例えば非特許文献４参照）。そのために、ゲートクローズ(Tclose)の時間帯に、アプリケーションからの通信トリガは、次にゲートクローズまで遅延される。ゲートオーブンとなった場合、先のゲートクローズの間に遅延された通信トリガについて、一度にセッションが確立される。
一方で、フォアグランド状態の場合、無線通信インタフェースの送信バッファは、ゲートオープンであって、アプリケーションからの通信トリガについては、遅延されることなく、直ぐにセッションが確立される。

Google Our Mobile Planet、[online]、［平成２６年４月５日検索］、インターネット＜URL:http://www.thinkwithgoogle.com/mobileplanet/ja/＞ 3GPP Radio Resource Control (RRC) State Machine、[online]、［平成２６年４月５日検索］、インターネット＜URL:http://www.3gpp.org/＞ Shuo Deng and Hari Balakrishnan, "Traffic-Aware Techniques to Reduce 3G/LTE Wireless Energy Consumption," Proceedings of the 8th international conference on Emerging networking experiments and technologies, Pages 181-192, 2012 Managing Background Data Traffic in Mobile Devices、[online]、［平成２６年４月５日検索］、インターネット＜URL:http://www.qualcomm.com/media/documents/managing-background-data-traffic-mobile-devices＞

しかしながら、非特許文献４に記載の技術によれば、無線通信インタフェースのハードウェアチップに制御部分を組み込む必要がある。多種多様なハードウェア上で動作させることを想定した、例えばAndroid OSのスマートフォンの場合、ハードウェアに技術的制約が発生することは許容されない場合もある。

また、アプリケーションによっては、通信トリガの発生から最大９分間も遅延させた場合、タイムアウトによってエラー処理に遷移すると想定され、既存のアプリケーションをそのまま利用することができない。アプリケーションが、ＮＳＲＭの存在を考慮して、最大９分間の遅延を許容した実装に作り変える必要がある。

更に、アプリケーションによっては、ユーザの体感品質が大きく低下する場合がある。例えば、通信遅延の影響が大きくかつ日常的に利用する利用者が多い、ＬＩＮＥのようなアプリケーションの場合、ユーザの体感品質を維持するためには、その遅延時間のみを短くするような柔軟な対応を必要とする。

そこで、本発明は、アプリケーションに影響を与えることなく、瞬間的な大量の送信パケットの発生を分散させることができるカーネルプログラム、装置及び方法を提供することを目的とする。

本発明によれば、アプリケーションから出力された送信パケットをネットワークへ送信するパケットフィルタリング手段を有するようにコンピュータを機能させるカーネルプログラムにおいて、
送信パケットの送信元ポート番号又は宛先アドレスからアプリケーション名を検索するアプリ名解決手段と、
アプリケーション名に応じて異なる複数の送信キューと、
パケットフィルタリング手段に対して、送信元ポート番号又は宛先アドレス及び送信キューの設定テーブルを更新するテーブル更新手段と
してコンピュータを機能させ、
パケットフィルタリング手段は、設定テーブルを用いて、送信パケットをいずれかの送信キューへ出力し、
送信キューはそれぞれ、異なる時間タイミングで、バッファしている送信パケットをバースト的に送信する
ようにコンピュータを機能させることを特徴とする。

本発明のカーネルプログラムにおける他の実施形態によれば、
設定テーブルに含まれていない送信ポート番号又は宛先アドレスの送信パケットが、アプリケーションから出力された際に、アプリ名解決手段を用いてアプリケーション名を解決する
ようにコンピュータを機能させることも好ましい。

本発明のカーネルプログラムにおける他の実施形態によれば、
パケットフィルタリング手段は、
当該ユーザインタフェースがフォアグランドで起動している場合、その送信パケットを直ぐに送信し、又は、
当該ユーザインタフェースがバックグランドで起動している場合、その送信パケットを設定テーブルに応じていずれか１つの送信キューへ出力する
べく切り替える
ようにコンピュータを機能させることも好ましい。

本発明のカーネルプログラムにおける他の実施形態によれば、
パケットフィルタリング手段は、
Linux（登録商標）におけるNetfilter機能のOUTPUTチェインであり、
設定テーブルは、少なくとも、送信パケットの送信元ポート番号又は宛先アドレスと、出力先となる送信キューの送信キュー番号とを対応付けたiptablesである
ようにコンピュータを機能させることも好ましい。

本発明のカーネルプログラムにおける他の実施形態によれば、
アプリ名解決手段は、
Linux（登録商標）におけるnetstat機能を用いて、送信パケットの送信元ポート番号からプロセス番号を特定し、
当該プロセス番号からアプリケーション名を特定する
ようにコンピュータを機能させることも好ましい。

本発明のカーネルプログラムにおける他の実施形態によれば、
アプリケーション名毎に、バースト送信時間間隔が対応付けられており、
送信キューはそれぞれ、送信を担う送信パケットのアプリケーション名に応じて、バースト的に送信する時間間隔が異なる
ようにコンピュータを機能させることも好ましい。

本発明のカーネルプログラムにおける他の実施形態によれば、
アプリケーション名毎に、送信パケットの送信時間間隔を計測し、当該送信時間間隔から、再送シーケンスが発生しないようなバースト送信時間間隔を設定する送信時間間隔計測手段と
してコンピュータを更に機能させることも好ましい。

本発明のカーネルプログラムにおける他の実施形態によれば、
無線通信インタフェースに対するパケットの送信有効／無効タイミングが規定されており、
送信キューはそれぞれ、送信有効タイミングの際に、異なる時間タイミングで、バッファしている送信パケットをバースト的に送信するものであり、
送信有効／無効タイミングは、当該カーネルプログラムによって機能する装置毎に分散して設定される
ようにコンピュータを更に機能させることも好ましい。

本発明のカーネルプログラムにおける他の実施形態によれば、
携帯電話網に接続する携帯端末に搭載されたＯＳ(Operating System)に適用される
ことも好ましい。

本発明によれば、アプリケーションから出力された送信パケットをネットワークへ送信するパケットフィルタリング手段を有する装置において、
送信パケットの送信元ポート番号又は宛先アドレスからアプリケーション名を検索するアプリ名解決手段と、
アプリケーション名に応じて異なる複数の送信キューと、
パケットフィルタリング手段に対して、送信元ポート番号又は宛先アドレス及び送信キューの設定テーブルを更新するテーブル更新手段と
を有し、
パケットフィルタリング手段は、設定テーブルを用いて、送信パケットをいずれかの送信キューへ出力し、
送信キューはそれぞれ、異なる時間タイミングで、バッファしている送信パケットをバースト的に送信する
ことを特徴とする。

本発明によれば、装置を用いて、アプリケーションから出力された送信パケットをネットワークへ送信するパケットフィルタリング方法において、
アプリケーション名に応じて異なる複数の送信キューを有し、
送信パケットの送信元ポート番号又は宛先アドレスからアプリケーション名を検索する第１のステップと、
送信元ポート番号又は宛先アドレス及び送信キューの設定テーブルを更新する第２のステップと、
設定テーブルを用いて、送信パケットを、その送信元ポート番号又は宛先アドレスに応じていずれかの送信キューへ出力する第３のステップと、
送信キューはそれぞれ、異なる時間タイミングで、バッファしている送信パケットをバースト的に送信する第４のステップと
を有することを特徴とする。

本発明のカーネルプログラム、装置及び方法によれば、アプリケーションに影響を与えることなく、瞬間的な大量の送信パケットの発生を分散させることができる。

スマートフォンにインストールされたアプリケーションによって発生するバックグランドの通信発生頻度を表すグラフである。 従来技術における突発的なシグナリングの発生を表す説明図である。 ＮＳＲＭにおけるアプリケーションの通信パケットの遅延を表す説明図である。 本発明におけるカーネルプログラムの機能構成図である。 本発明における突発的なシグナリングの分散を表す説明図である。 Android OSを搭載したスマートフォンで観測されたパケットログを表す説明図である。

以下、本発明の実施の形態について、図面を用いて詳細に説明する。

本発明は、携帯電話網に接続するスマートフォン（携帯端末）に搭載されたＯＳ(Operating System)のカーネルプログラムに適用される。具体的には、Andoroid（登録商標）OSのカーネルとなるLinux（登録商標）に適用される。これによって、非特許文献４に記載されたような、無線通信インタフェースのハードウェアチップにおける制約を取り除くことができる。

図４は、本発明におけるカーネルプログラムの機能構成図である。

図４のカーネルプログラム１によれば、複数の送信キュー１１と、パケットフィルタリング部１２と、アプリ名解決部１３と、テーブル更新部１４と、送信時間間隔計測部１５とを有する。これら機能構成部は、装置に搭載されたコンピュータを機能させるカーネルプログラムを実行することによって実現される。また、これら機能構成部の処理の流れは、パケットフィルタリング方法としても理解できる。

［複数の送信キュー１１］
複数の送信キュー１１は、アプリケーション名に応じて異なるものとして備えられる。これら送信キュー１１は、ユーザインタフェースがバックグランドの場合にのみ設定される。逆に、ユーザインタフェースがフォアグランドの場合、既存のパケットフィルタリング部１２が適用されるだけである。尚、送信キュー１１は、動的に生成され又は消去されるものであってもよい。

送信キューはそれぞれ、当該アプリケーションのタイムアウトに影響のない範囲の時間タイミングで、バッファしている送信パケットをバースト的に送信する。各送信キューは、例えば１０秒間に、１秒間ずつ、送信許可を得るように動作するものであってもよい。勿論、タイムアウトに影響のない時間タイミングが複数のアプリケーションで同じであれば、これらアプリケーションに対して１つの送信キューを共有して割り当てるものであってもよい。

また、アプリケーション名毎に、バースト送信時間間隔が対応付けられていることも好ましい。バースト送信時間間隔は、アプリケーションから見て、再送シーケンスが発生しない程度のものである。送信キュー１１はそれぞれ、送信パケットのアプリケーション名に応じて、バースト的に送信する時間間隔が異なる。これは、通信事業者によって予め、システムパラメータとして設定されたものであってもよい。

図５は、本発明における突発的なシグナリングの分散を表す説明図である。

図５によれば、従来技術の図２と比較して、瞬間的なシグナリング（パケット）の送信タイミングが、スマートフォン間で分散されている。ここで、各スマートフォンについて、無線通信インタフェースに対するパケットの送信有効／無効タイミングは、Control Windowによって規定されている。送信キューはそれぞれ、送信有効タイミング(Enable)の際に、異なる時間タイミングで各送信キューからバースト的にパケットを送信する。以下の第１の遅延と第２の遅延とが組み合わされている。

第１に、スマートフォン毎に、Control WindowのEnable時刻（送信有効／無効タイミング）が分散してずらして設定されている。Control Windowは、RRC_connectedのタイミングをずらすものであって、例えば端末固有の識別子や電話番号から、時刻差が設定される。例えば最大１０秒間を、１秒毎に１０段階に設定し、識別子の末番号に応じて自らの設定遅延量を認識する。図５によれば、スマートフォン毎にControl WindowsのEnable時刻がずれている。

第２に、アプリケーション毎の送信キューに応じて、パケットの送信が更に遅延される。これによって、通信事業設備に係る瞬間的な大量の送信パケットの発生が分散されると共に、特定のアプリケーションのパケットがそのアプリケーションサーバに瞬間的に集中的にアクセスすることも回避できる。図５によれば、アプリケーションＡ，Ｂ，Ｃのパケットが、送信キューに応じて遅延されている。

［パケットフィルタリング部１２］
パケットフィルタリング部１２は、アプリケーションから出力された送信パケットをネットワークへ送信すると共に、ネットワークから受信した受信パケットをアプリケーションへ出力する。「パケットフィルタリング」とは、パケットのヘッダ部分を見て、設定テーブルの要素と一致するかどうかを判定し、一致した場合に所定のアクション（転送、破棄、アドレス書き換え等）を実行するものである。

パケットフィルタリング部１２は、具体的には、Linux（登録商標）におけるNetfilterのOUTPUTチェインである。本発明のパケットフィルタリング部１２は、以下のように、スマートフォンの操作状態に応じて、制御を切り替える。
フォアグランドの場合、その送信パケットを直ぐに送信する（既存のパケットフィルタリング部の動作）。
バックグランドの場合、その送信パケットを送信キューへ出力する（本発明のパケットフィルタリング部の動作）。

パケットフィルタリング部１２は、設定テーブルを用いて、送信パケットをいずれかの送信キューへ出力する。ここで、「設定テーブル」は、送信パケットの送信元ポート番号と、出力先となる送信キューの送信キュー番号とを対応付けたiptablesである。iptablesは、具体的には、以下のように対応付けられたテーブルである。
「プロトコル(TCP/UDP/ICMP)」「送信元ＩＰアドレス」「送信元ポート番号」
「宛先ＩＰアドレス」「宛先ポート番号」
<->「送信キュー番号」

「送信元ポート番号」は、アプリケーションがパケットを送信する毎にＯＳによって動的に割り当てられる。また、セッションが継続する間、同じ送信元ポート番号が維持される（但し、アプリケーションによれば、複数のセッションを利用するものもあり、その場合１つのアプリケーションに複数の送信元ポート番号が付与される場合もある）。

一方で、パケットフィルタリング部１２は、iptables（設定テーブル）に登録されていない未知の送信ポート番号の送信パケットを受信した場合、アプリ名解決部１３へその送信パケットを出力する。

［アプリ名解決部１３］
アプリ名解決部１３は、送信パケットの送信元ポート番号からアプリケーション名を検索する。アプリ名解決部１３は、Linuxのnetstat機能を用いて、送信パケットの送信元ポート番号からプロセス番号を特定する。そして、そのプロセス番号からアプリケーション名を検索する。そして、アプリ名解決部１３は、新たに検索されたアプリケーション名に対して、新たな送信キューを生成するべく、送信キュー１１へ指示する。

例えば"netstat"コマンドを実行することによって、以下の結果を得ることができる。
Proto Local Address Foreign Address State PID
Proto：TCP/UDPの表示
Local Address：送信元IPアドレス、送信元ポート番号
Foreign Address：宛先IPアドレス、宛先ポート番号
State：接続状況
PID：使用しているアプリケーション

［テーブル更新部１４］
テーブル更新部１４は、パケットフィルタリング部１１に対して、送信元ポート番号及び送信キューの設定テーブル（振り分けルール）を更新する。即ち、アプリケーション名に応じた送信キューが新たに生成された際に、その送信キューをOUTPUTチェインのiptables（設定テーブル）に登録する。但し、一定時間以上、利用されていない送信キュー１１については、その送信元ポート番号に基づく要素を、iptablesから削除する。

ここで、全てのアプリケーション毎に送信キューを設定してもよいし、特定のアプリケーションのみ優先度を高く（遅延時間を短く）設定した送信キューを設定してもよい。即ち、複数のアプリケーションをまとめて１つの送信キューを設定してもよい。

［送信時間間隔計測部１５］
送信時間間隔計測部１５は、アプリケーション名毎に、送信パケットの送信時間間隔を計測する。そして、その送信時間間隔から、再送シーケンスが発生しないようなバースト送信時間間隔を設定する。これによって、アプリケーションに影響の無い遅延時間を設定することができる。

図６は、Android OSを搭載したスマートフォンで観測されたパケットログを表す説明図である。

図６によれば、送信許可までの時間を非常に長く設定することによって観測されたものである。これによって、アプリケーション毎に、適切な遅延時間を特定することができる。

アプリケーションは、宛先のサーバや端末のＩＰアドレスを取得するために、最初に、DNS lookupパケット（udp宛先ポート番号53番のパケット）を送信する。ここで、各パケットの送信時間に注目する。図６によれば、５秒間隔で、同一の送信元ポート番号（同一のプロセス番号）から２回、DNS lookupパケットが送信されていることが観測できる。また、DNS lookupは、１０秒間でタイムアウトしており、一般に２回送信（再送信）されていることが理解できる。そのため、DNS lookupパケットを、アプリケーションに影響なく処理するためには、最大５秒間（再送を期待する場合は１０秒間）（実際にはDNS lookupの応答を受信するまでの時間）、送信を保留できることが理解できる。このように、送信時間間隔計測部１５は、アプリケーションから出力される送信パケットを観測することによって、適切な送信時間間隔を設定することができる。

以上、詳細に説明したように、本発明のカーネルプログラム、装置及び方法によれば、アプリケーションに影響を与えることなく、瞬間的な大量の送信パケットの発生を分散させることができる。また、本発明によれば、Android OSに限られず、Firefox OS（登録商標）やTizen（登録商標）のようなLinuxベースとした様々なＯＳにも実装することができる。

本発明によれば、スマートフォンにインストールされたアプリケーションが発生する通信トラヒックの中でも、特にバックグランド通信に注目している。ユーザインタフェースの即時の反応と必要としない時間帯に、アプリケーションからの送信パケットを遅延させることによって、通信事業設備に係る瞬間的な処理負荷をできる限り軽減することができる。

前述した本発明の種々の実施形態について、本発明の技術思想及び見地の範囲の種々の変更、修正及び省略は、当業者によれば容易に行うことができる。前述の説明はあくまで例であって、何ら制約しようとするものではない。本発明は、特許請求の範囲及びその均等物として限定するものにのみ制約される。

１ カーネルプログラム
１１ 送信キュー
１２ パケットフィルタリング部
１３ アプリ名解決部
１４ テーブル更新部
１５ 送信時間間隔計測部
２ セッション確立サーバ
３ アプリケーションサーバ

Claims (11)

1. アプリケーションから出力された送信パケットをネットワークへ送信するパケットフィルタリング手段を有するようにコンピュータを機能させるカーネルプログラムにおいて、
   送信パケットの送信元ポート番号又は宛先アドレスからアプリケーション名を検索するアプリ名解決手段と、
   前記アプリケーション名に応じて異なる複数の送信キューと、
   前記パケットフィルタリング手段に対して、前記送信元ポート番号又は宛先アドレス及び前記送信キューの設定テーブルを更新するテーブル更新手段と
   してコンピュータを機能させ、
   前記パケットフィルタリング手段は、前記設定テーブルを用いて、前記送信パケットをいずれかの送信キューへ出力し、
   前記送信キューはそれぞれ、異なる時間タイミングで、バッファしている送信パケットをバースト的に送信する
   ようにコンピュータを機能させることを特徴とするカーネルプログラム。
2. 前記設定テーブルに含まれていない送信ポート番号又は宛先アドレスの送信パケットが、アプリケーションから出力された際に、前記アプリ名解決手段を用いてアプリケーション名を解決する
   ようにコンピュータを機能させることを特徴とする請求項１に記載のカーネルプログラム。
3. 前記パケットフィルタリング手段は、
   当該ユーザインタフェースがフォアグランドで起動している場合、その送信パケットを直ぐに送信し、又は、
   当該ユーザインタフェースがバックグランドで起動している場合、その送信パケットを前記設定テーブルに応じていずれか１つの送信キューへ出力する
   べく切り替える
   ようにコンピュータを機能させることを特徴とする請求項１又は２に記載のカーネルプログラム。
4. 前記パケットフィルタリング手段は、
   Linux（登録商標）におけるNetfilter機能のOUTPUTチェインであり、
   前記設定テーブルは、少なくとも、送信パケットの送信元ポート番号又は宛先アドレスと、出力先となる前記送信キューの送信キュー番号とを対応付けたiptablesである
   ようにコンピュータを機能させることを特徴とする請求項１から３のいずれか１項に記載のカーネルプログラム。
5. 前記アプリ名解決手段は、
   Linux（登録商標）におけるnetstat機能を用いて、送信パケットの送信元ポート番号からプロセス番号を特定し、
   当該プロセス番号からアプリケーション名を特定する
   ようにコンピュータを機能させることを特徴とする請求項１から４のいずれか１項に記載のカーネルプログラム。
6. アプリケーション名毎に、バースト送信時間間隔が対応付けられており、
   前記送信キューはそれぞれ、送信を担う送信パケットのアプリケーション名に応じて、バースト的に送信する時間間隔が異なる
   ようにコンピュータを機能させることを特徴とする請求項１から５のいずれか１項に記載のカーネルプログラム。
7. アプリケーション名毎に、送信パケットの送信時間間隔を計測し、当該送信時間間隔から、再送シーケンスが発生しないような前記バースト送信時間間隔を設定する送信時間間隔計測手段と
   してコンピュータを更に機能させることを特徴とする請求項６に記載のカーネルプログラム。
8. 無線通信インタフェースに対するパケットの送信有効／無効タイミングが規定されており、
   前記送信キューはそれぞれ、送信有効タイミングの際に、異なる時間タイミングで、バッファしている送信パケットをバースト的に送信するものであり、
   送信有効／無効タイミングは、当該カーネルプログラムによって機能する装置毎に分散して設定される
   ようにコンピュータを更に機能させることを特徴とする請求項１から７のいずれか１項に記載のカーネルプログラム。
9. 携帯電話網に接続する携帯端末に搭載されたＯＳ(Operating System)に適用される
   ことを特徴とする請求項１から８のいずれか１項に記載のカーネルプログラム。
10. アプリケーションから出力された送信パケットをネットワークへ送信するパケットフィルタリング手段を有する装置において、
    送信パケットの送信元ポート番号又は宛先アドレスからアプリケーション名を検索するアプリ名解決手段と、
    前記アプリケーション名に応じて異なる複数の送信キューと、
    前記パケットフィルタリング手段に対して、前記送信元ポート番号又は宛先アドレス及び前記送信キューの設定テーブルを更新するテーブル更新手段と
    を有し、
    前記パケットフィルタリング手段は、前記設定テーブルを用いて、前記送信パケットをいずれかの送信キューへ出力し、
    前記送信キューはそれぞれ、異なる時間タイミングで、バッファしている送信パケットをバースト的に送信する
    ことを特徴とする装置。
11. 装置を用いて、アプリケーションから出力された送信パケットをネットワークへ送信するパケットフィルタリング方法において、
    前記アプリケーション名に応じて異なる複数の送信キューを有し、
    送信パケットの送信元ポート番号又は宛先アドレスからアプリケーション名を検索する第１のステップと、
    送信元ポート番号又は宛先アドレス及び送信キューの設定テーブルを更新する第２のステップと、
    前記設定テーブルを用いて、前記送信パケットを、その送信元ポート番号又は宛先アドレスに応じていずれかの送信キューへ出力する第３のステップと、
    前記送信キューはそれぞれ、異なる時間タイミングで、バッファしている送信パケットをバースト的に送信する第４のステップと
    を有することを特徴とするパケットフィルタリング方法。

Images