(57)【要約】  伝送のためにネットワーク装置からパケットの送給をスケジューリングするためのシステム及び方法が提供される。パケットは、形式によって分類され、同じ形式の他のパケットとキューに入れられる。各々のパケットは有効時間と関連され、この後で送給されることはない。キュートラッカはキューを監視し、有効時間が切れたパケットを除去する。【選択図】図８
2008546328.tif 000002
【特許請求の範囲】
【請求項１】
伝送のためにネットワーク装置からパケットの送給をスケジューリングするための方法であって、
（ａ）パケットを形式に分類し、
（ｂ）前記パケットを前記形式と関連するキューに挿入し、
（ｃ）前記形式に基づいて前記パケットに時間を関連させ、
（ｄ）前記時間の有効期間前に、前記パケットが伝送のためにスケジューリングされていない場合には、前記パケットの有効期間が切れたことをスケジューラに通知し、
（ｅ）前記時間の有効期間前に、前記パケットが伝送のためにスケジューリングされている場合には、前記キューにより前記パケットを送信する
ステップを含むことを特徴とする方法。
【請求項２】
前記ステップ（ａ）において、前記パケットは、音声、ビデオ、オーディオ、又はデータのいずれか１つに分類されることを特徴とする請求項１に記載の方法。
【請求項３】
最大エラー率は前記形式と関連されることを特徴とする請求項２に記載の方法。
【請求項４】
再伝送の最大試行数は前記形式と関連されることを特徴とする請求項３に記載の方法。
【請求項４】
前記パケットが「音声」形式である場合には、前記パケットと関連する前記時間はパレート分布モデルに従うことを特徴とする請求項４に記載の方法。
【請求項５】
前記パケットが「データ」形式である場合には、前記パケットと関連する前記時間は指数分布モデルに従うことを特徴とする請求項５に記載の方法。
【請求項６】
伝送のためにパケットをスケジューリングするためのシステムであって、
（ａ）キューマネージャと、
（ｂ）音声、データ、オーディオ、及びビデオの組を含む形式にパケットを分類し、時間を前記パケットに関連させるためのパケット分類器と、
（ｃ）前記形式の各々に対して、伝送のために前記形式のパケットを受信する対応するキューと、
を含み、そこから前記キューマネージャは前記伝送されるべきパケットを求め、
（ｄ）有効期間が切れたパケットを前記キューマネージャに報告するためのキュートラッカ
を含むことを特徴とするシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ネットワーク上のデータトラフィックを管理するためのシステム及び方法に関し、より具体的には、異なるデータ形式の様々な要求、及び、各々が異なる特性及び変化するネットワークステータスを有する異なる形式の有線及び無線ネットワーク上でのそれらの挙動に対処するためのシステム及び方法に関する。
本出願は、２００５年６月６日に出願された米国仮特許出願第６０／６８７，３３９号に基づく優先権を主張するものである。
【背景技術】
【０００２】
無線ネットワークは、一般に、従来の有線ネットワークと比較すると、非常に異なる特性を有する。例えば、有線ネットワークの「バックボーン」は、無線ネットワークより均一であり、有線ネットワークは、典型的には、データトラフィックを制御するルータ及びスイッチにより接続されたインテリジェントなサブネットワークのメッシュである。有線ネットワークにおいては、ユーザは、一般に、静止しており、したがって、ユーザの移動は、ネットワークのサービスに対してほとんど影響力がない。有線ネットワークにおけるユーザサービスに対する主要な影響は、ネットワーク上のデータトラフィック輻輳である。この輻輳問題は、ほとんどのアプリケーションが用いる通信プロトコルである転送制御プロトコル／インターネットプロトコル（ＴＣＰ／ＩＰ）を用いることにより対処される。
【０００３】
無線ネットワーク特性及び実施は、例えば、以下のように、有線ネットワークとは、かなり異なるものである。
１．無線ネットワークのネットワーク基礎構造は、モバイルネットワーク装置とネットワークにおける第１有線リンクとの間のノードの数に関して、より単純である。
２．無線ネットワークのステータスは、（例えば、ダウンタウンの都市エリアと、異なる信号減衰及び伝搬をもつ郊外エリアのような）環境条件、（例えば、大きい電源フィールドの近くと、大きい空地のような）モバイル装置の位置、所定時間におけるネットワークトラフィック、ネットワークの隣接するユーザの使用、及び（例えばファイバと、メタル系バックボーンのような）基地局バックボーンを含む幾つかの要因のために頻繁に変化する。
３．ソフトウェアアプリケーションは、一般に、頻繁なステータス変動を含む無線ネットワーク環境のために設計されていない。したがって、こうしたアプリケーションを無線ネットワーク上で動作させることは、付加的なトラフィックを加えることによりネットワークステータスを悪化させ、したがって、ネットワークの全体的な遅延及び待ち時間を増加させ、これは次いで、他のモバイル装置ユーザの経験に影響を与えることになる。
【０００４】
無線ネットワーク技術には２つの平行する変化が生じており、１つはｉ）新規な無線ネットワーク形式の導入であり、全体の無線ネットワーク基礎構造は単一形式のネットワーク、例えば、汎用パケット無線システム（ＧＰＲＳ）のみから、ＧＰＲＳ、Ｗｉ−Ｆｉ、マイクロ波アクセスのための世界的な相互接続性（ＷｉＭＡＸ）、及び世界規模の移動体通信システム（ＵＭＴＳ）のような多数のネットワーク形式を含む基礎構造に変化していること、もう１つはｉｉ）無線ネットワークユーザはもはや電子メール、ショートメッセージサービス（ＳＭＳ）、及びダウンロードのような「バックグラウンドクラス」形式を用いるだけではなくなり、現在はウェブ閲覧、ネットワークゲーム、及びデータベースアクセスのようなより対話型のアプリケーション、マルチメディアアプリケーション、ビデオオンデマンド、及びウェブ放送のようなストリーミングアプリケーション、及びインターネット・プロトコル上の音声（ＶｏＩＰ）、ビデオテレフォニー、及びテレビゲーム遊びのような、対話型のアプリケーションを用いるようになっていることである。サービスプロバイダ又はキャリアは、「ユーザ当たりの平均収益」及び加入率を増加させることに関して、これらのアプリケーションの無線ネットワーク上での使用を増加させようとしている。サービスプロバイダは、さらに、第３者のアプリケーションと比較したときに、彼らの「保証する」アプリケーションのサービス品質（ＱｏＳ）と併せて提供されるサービスにより、彼ら自体を競合者から区別している。しかし、これらの異なる種類のアプリケーションを使用することは、各々のデータ形式が（アプリケーションの時間に敏感なスペクトルとエラーに敏感なスペクトルにおいて）異なる送給（時間）要求及び異なるエラー許容差を有する異なるデータトラフィック形式がネットワークを移動することになる。例えば、ＶｏＩＰパケットは、非常に時間に敏感であり、短い寿命を有するが、データパケットは、非常にエラーに敏感である。（多数のソフトウェアアプリケーションにより広く用いられる）ＴＣＰ及びＵＤＰ／ＩＰプロトコルの両方は、ネットワーク及びアプリケーションに寛容である。ＴＣＰは、有線ネットワーク上に生じる輻輳制御特徴を与えるが、プロトコルは有線ネットワークを無線ネットワークから区別しない。さらに、これらのプロトコルのいずれもアプリケーション感知ではない（これらは、アプリケーションの種類に敏感ではなく、時間とエラーに敏感でもない）。ＴＣＰ／ＩＰは、ネットワーク上の輻輳を検出し、２つの通信部間のトラフィックを制御することにより、有線ネットワークにおける輻輳問題を克服するように特別に設計された。しかし、無線ネットワーク上でのＴＣＰ／ＩＰの使用は、問題がある。例えば、無線ネットワークにおける遅延は、（輻輳ではなく）信号減衰により生じることがあり、これはＴＣＰ／ＩＰが、事実上、無線ネットワークの性能を減少させることになる。
【０００５】
したがって、従来技術には、ネットワーク装置が、ネットワーク内でインテリジェントで統合された（ルータ／スイッチと同様な）要素として働くことによる、ネットワークにおけるネットワーク（例えばモバイルのような）装置の認識及び参加がない。従来技術においては、ネットワーク装置、特にモバイル装置は、使用可能な有線ネットワーク又は無線ネットワークの形式、及び、他のネットワーク装置と通信しているデータ形式に基づいて決定する能力がない（無線ネットワークと有線ネットワークとの間の差異が与えられると、データ通信は２つのネットワーク形式上で異なって扱われるべきである）。
【０００６】
従来技術は、以下の問題に対処できていない。
１．無線ネットワーク上のＴＣＰ／ＩＰの非能率性。
２．ネットワーク装置のプロトコル層内の無線ネットワークの知識がないこと。
３．リアルタイムデータ転送制御プロトコル（ＲＴＣＰ）として知られる無線ネットワーク上のＶｏＩＰ及び標準的なストリーミングビデオ制御プロトコルの非能率性。
４．ＩＰヘッダ情報に頼ることなく、異なる形式のデータ間を動的に区別すること及び混合ネットワークにおけるリアルタイムの要求を満たすことに対して無能であること。
５．混合ネットワークにおけるモバイル装置が、使用可能なネットワークの形式、及び、任意の所定時間において各々のネットワークのステータスを認識して、どのような付加的なトランザクションも必要とすることなく、データプロトコルの送給の一部として、ステータス情報をネットワークにフィードバックすることに対して無能であること。
６．混合ネットワークにおけるモバイル装置が、無線ネットワークの物理層の外及びＩＰ層の下で、信号雑音比（ＳＮＲ）を予測して、トラフックを異なるネットワークを通してフォワードする／宛先変更する、又は、条件及びネットワークポリシーに基づいて、同時に２つの形式のネットワークを用いるといった適当なトラフィック形式を決定することに対して無能であること。
７．ＩＰの下の層におけるモバイル装置内で局所ジッタ操作を与えることに対して無能であること。
８．ネットワーク条件及びポリシーに基づいて又はカタログＩＤにより設定されるＤＮＡ／指紋により、モバイル装置内のモバイルデータトラフックの優先順位付け、キューイング及びスケジューリングを与えること、又は、アプリケーションの種類を判断することに対して無能であること。
【０００７】
上に挙げられた問題の１つ、具体的には、無線ネットワーク上のＴＣＰ／ＩＰの非能率性を解決することが試みられてきた。これらの解決法は、ＴＣＰ／ＩＰスプーフィング及びトンネリング技術を用いることを含むが、非能率的であり、無線ネットワーク上に不要なデータをさらに送ることになることが多く、ネットワーク装置に対して付加的な処理経費を生み出す。
ＴＣＰ／ＩＰは、有線ネットワークのために設計されたプロトコルであり、通常は輻輳が関係する、その環境における問題によく適している。ＴＣＰ／ＩＰを用いるネットワークにおけるノードが承認を受信しなかった場合には、ノードは、ネットワークに輻輳があると判断し、伝送を遅くしてフロー制御を与えることによりネットワークを助けようとする。無線ネットワークにおいては、所定時間内に承認を受信することに対する失敗は、通常は、輻輳のためではなく、その時点でのネットワーク遅延、信号強度の降下、又は待ち時間の変動のためである。こうした状況においては、ＴＣＰ／ＩＰノードは、伝送を遅くして、その通常の動作速度に戻る前に幾らかの時間をかける。この時間において、同じ帯域幅にわたる処理量は、不要に遅くされた伝送のために減少する。
【０００８】
ＴＣＰ／ＩＰにより引き起こされる別の問題は、これが有線ネットワークの低ビットエラー率のリンク環境のために設計されたものであり、したがって、パケットストリーム内の１つのパケットがなくなった場合には、すべてのパケットが再送される。例えば、１つのパケットが２０パケットストリーム内でなくなった場合には、ほとんどは首尾よく受信されていたとしても、ネットワークノードは、ストリーム内のすべてのパケットを再送する。
ハイパーテキスト転送プロトコル（ＨＴＴＰ）のような幾つかのアプリケーションレベルプロトコルは、無線ネットワークに好都合ではない方法でＴＣＰ／ＩＰを用いる。例えば、マイクロソフト・エキスプローラのようなＨＴＴＰブラウザが通信要求をしたとき、ＨＴＴＰブラウザは、２つ又は３つの同時ＴＣＰ／ＩＰコールを実行する。各々のＴＣＰ／ＩＰコールは、リンクを確立するために、３方向ハンドシェーク（３つの要求及び応答）を必要とする。（通常は有線リンクより長い待ち時間を有する）無線リンク上で、応答が時間通りに到着しない場合には、新規なＴＣＰ／ＩＰに対する必要があると解釈される。１つのＴＣＰ／ＩＰリンクが遅延した場合には、ブラウザは、別の３方向ハンドシェークにより、別のＴＣＰ／ＩＰリンクを要求する。これらの通信のすべては、付加的な経費をもたらし、無線ネットワークに遅延を加える。
【０００９】
これらの問題を解決するために、インターネット・エキスプローラのようなアプリケーションを用いて、単一のデータ形式を主たる対象とする幾つかの非能率的な解決法があった。以下は、無線ネットワーク上でＴＣＰ／ＩＰの非能率性を克服するのに取られる手法である。
１．ネットワーク上を通るデータ量を減らす、データ（コンテンツ）の圧縮。
２．モバイル装置内のドメイン・ネーム・システム（「ＤＮＳ」）のキャッシュ。
３．圧縮されたＴＣＰ／ＩＰパケットのユーザ・データグラム（「ＵＤＰ」）トンネリング及びＴＣＰ／ＩＰのスプーフィング。
今日、これらの手法のいずれも完全に不十分である。これらの各々の欠点は以下の通りである。
１．コンテンツの圧縮
コンテンツの圧縮は、典型的には、「バックグラウンド」アプリケーション及びインターネット・エキスプローラのような、テキスト及びピクチャオブジェクトの両方を含むウェブサイトを要求する幾つかの対話型アプリケーションにのみ適用される。この方法は、例えば、静止画像の圧縮・伸長の国際標準規格（「ＪＰＥＧ」）及びテキスト「ｔｘｔ」ファイルのフォーマットのように、損失の多いデータ又は損失のないデータとしての分類に基づいてコンテンツを圧縮する。これらの分類は、異なる方法及び比率における圧縮を可能にする。この方法はネットワークを移動するデータ量を減少させるが、間接的には帯域幅をより多く使用することになり、これはＴＣＰ／ＩＰの奇妙な挙動を引き起こす無線遅延変動であるため、無線ネットワーク上のＴＣＰ／ＩＰの非能率性を排除しない。
２．モバイル装置内のＤＮＳキャッシング
モバイル装置内のＤＮＳキャッシングは、ＤＮＳ検索に必要とされる時間を減少させるのに用いられる。この技術は、各々のＤＮＳクエリに対して、ＤＮＳからの結果をキャッシュするソフトウェアをモバイル装置内に必要とする。次に同じクエリが要求されたときには、要求をネットワーク上で送信して応答を待つのではなく、ＤＮＳキャッシュを用いられて結果を与える。この技術は、頻繁に要求されるクエリを転送する必要を減らすが、ＴＣＰ／ＩＰの非能率性に直接対処するものではない。
【００１０】
３．トンネリング
トンネリングは、圧縮された又は圧縮されていないＴＣＰ／ＩＰデータのＵＤＰトンネリングを含む。トンネリングは、モバイル装置及びサーバの両方の中にＴＣＰ／ＩＰデータを取り込み、ＵＤＰを通してＴＣＰパケット全体をトンネリングするように通信するソフトウェアを必要とする。この技術の欠点は以下のものを含む。
（ｉ）プロセス消費。ＴＣＰデータは既に生成され、下層に送られているため、ネットワークノードは、ＴＣＰパケットをカーネルモードのプロトコル層に戻すように送る高層のユーザモードのプロキシ型アプリケーションにデータを戻すべきであるが、このときはＵＤＰパケットを要求する（ＵＤＰトンネルと呼ばれる）。ネットワークノードがＩＰセキュリティ（ＩＰＳｅｃ）仮想プライベートネットワーク（ＶＰＮ）暗号化セキュリティを使用している場合には、トンネリングされたＴＣＰデータは、さらに別のＩＰＳｅｃトンネルを通る。このことは、より多くの処理時間が小さいモバイル装置に必要であり、さらなる遅延がトンネリング技術により引き起こされることを意味する。さらに、圧縮又は暗号化が層４（ＴＣＰ及びＵＤＰ層の上であり、アプリケーション層の下）で生じた場合には、プロキシ型は、アプリケーションの種類を区別することができない。
（ｉｉ）ネットワークトラフィックの増加。（上述のような）トンネリング内のトンネリングは、ネットワーク上のトラフィックを増加させる。この「解決法」は、ＴＣＰデータは既に生成されているが、伝送のために異なるプロトコルの周りにラップされているため、無線ネットワークの待ち時間の変動により生成されるＴＣＰ非能率性問題を解決しない。ＴＣＰデータをトンネリングする主要な理由は、データを圧縮して、データが、伝送のために別のプロトコルの周りにラップされるようにすることである。しかし、ネットワークが長い待ち時間を有する場合には、ＴＣＰは、適時に応答を受信しないために、依然として奇妙な挙動をもたらす。
【００１１】
無線及び混合ネットワーク上のＴＣＰ問題を克服するためには、幾つかの解決法は、ｐｉｎｇ又は付加的な承認のような付加的なパケットを転送して、無線リンク上で適当なＴＣＰ挙動を維持して、ソフトウェアアプリケーションに対してリンクを「生きた状態」にしておくことを含む。この手法は、さらに、不要なデータを加えることにより無線ネットワーク上のトラフィックを増加させ、また、新規なパケット交換ネットワークの機構を古い旧来の回路交換ネットワークの機構に変化させる。パケット交換ネットワークの原理は、伝送することができるデータがあるときのみ、リンクをモバイルユーザに割り当てることである。ユーザが応答を待っている間、アップリンクが別のモバイルユーザに割り当てられる。このことは、より高いネットワーク容量をもたらし、より多数のネットワークユーザが既存のネットワークの使用することを可能にする。回路交換ネットワークは、モバイルユーザが伝送できるデータをもっているかどうかに関わらず、特定に時間の期間において、リンクがモバイル装置ユーザに割り当てられている。この時間において、他のモバイル装置ユーザは、ネットワークにより、リンクがそのモバイル装置ユーザからの割り当てを解除されて、彼らに再び割り当てられるのを待つ。
【００１２】
ローミング
ローミングは、例えば、空港で移動するモバイル装置ユーザのような、無線リンク上で、１つのアクセルポイント（「ＡＰ」）から別のＡＰに移動するプロセスである。（例えば、ＴＣＰ／ＩＰベースのもののような）接続指向のアプリケーションにおいては、通信を転送するための待ち時間及び１つのＡＰから別のＡＰへの接続は、新規なＩＰを新規なドメインから受信した後のデータの再伝送及びＴＣＰの再確立をもたらすことがある（ドメイン内移動の場合）。時間に敏感なアプリケーションにおいては、このことは、１つのＡＰ又はドメインから別のＡＰ又はドメインへの移動により引き起こされる付加的な遅延をもたらす。
この問題に対処するための２つの現在好ましい方法がある。
１．ローミングする決定をする前に使用可能なＡＰの強度をチェックするためにモバイル装置が使用可能なネットワークを走査するプリエンプティブＡＰ発見、及び、モバイル装置がローミングの決定をし、次いでエリアを走査して代替的なＡＰを見出すローミング時間ＡＰ発見。この方法は、ベンダー特有のものであり、どのような特定の基準にも基づくものではない。
２．クライアントは、種々の基準に明確に定義されたローミングを開始し、したがって、クライアントはアプリケーションセッションを再開することができる。
当該技術分野における問題は、アプリケーションセッションを再開することにあり、このことは、どの基準にも特定されていない。ネットワーク内のモバイルＩＰ基準がこの問題を解決することが提案されているが、モバイルＩＰ内の信号通知トラフィック量は、あまりに多くの不要なトラフィックを生成する。
【発明の開示】
【００１３】
本発明によるシステム及び方法は、有線、無線、又は混合ネットワーク上で混合モバイルデータトラフィック管理を提供するソフトウェアプラットフォームを含む。このシステム及び方法は、異なるデータ形式の様々な要求、及び、各々が異なる特性及び変化するネットワークステータスを有する異なる無線ネットワーク上でのそれらの挙動に対処する。モバイル装置は、ネットワーク外部の独立したエンティティとして扱われるのではなく、ネットワーク全体の一部として組み込まれる。従来技術においては、モバイルノード（すなわち、モバイル装置）は独立したエンティティであり、ネットワークとは交わらず、使用可能なネットワーク形式に左右されず、他のネットワーク装置と通信する異なるデータ形式に左右されない。本発明は、モバイルノードをネットワークの一部として組み込んで、ネットワーク内のアクティブな参加者にすることを可能にし、ネットワーク構成要素と特定のデータ要求を管理し、交渉することを可能にする包括的なソフトウェアソリューションを提供する。
本発明によるシステム及び方法は、モバイル装置がネットワーク状況及びアプリケーション形式、したがってそれらの要求に気づき、さらに、任意の所定の時間にネットワークポリシーに気づいて、効率的な決定ができるようにする。必要な「インテリジェンス」が使用可能であるため、「どの」アプリケーションも、モバイル装置のオペレイティングシステム（ＯＳ）のコード構造も、ハードウェアも変更する必要がない。この解決法は、ネットワークが本発明によるシステムにより又はこのシステムなしで動作し（ネットワークはこうしたシステムによって、より効率的になるが）、このシステムを用いない他のモバイル装置がネットワーク内で動作できるものである。このことは、モバイル装置のＯＳに、システムコールをインターセプトし、イニシエータ及び宛先介入なしでコールを変更する能力を加えることにより達成される。
【００１４】
これらの能力を実施するために、モバイル装置のカーネルＯＳ内に２つの層が挿入されて、アプリケーション経路がインターセプトされる。第１層は、アプリケーションコールを受信し、アプリケーション及びデータの形式を識別し、プロトコルを構築し、（ＴＣＰに向けられている場合には）ＵＤＰに方向を変える。第２層は、物理層を制御して、第２層がネットワークのステータスを監視し、近い将来のネットワークステータスを予測し、この情報に基づいて出て行くトラフィック形式をスケジューリングし、アプリケーションの会話型クラスに対して受信されたパケットに局所ジッタ操作を与え、収集されたステータスを他の層に与える。第２層は、さらに、使用可能な多数のネットワーク形式の間のパケットの方向変換及びフォワーディングを与える。
したがって、本発明によるシステムは、
ｉ）プロトコル手法を取ることにより、単一及び混合ネットワーク上のすべてのデータ形式を管理することによって、より大きい帯域幅効率及びネットワーク容量を与え、したがって、したがって、無線ネットワークにおけるアプリケーションにより確立された付加的な接続によって生成された経費を減少させ（１つの接続だけが必要である）、要求される承認を減少させ、有効期間が切れていないデータだけを送信して他のデータはフィルタ処理により除去し、非能率的なＴＣＰ／ＩＰスプーフィング及びトンネリング技術を用いないことによって、伝送されるデータの経費を減少させる。
ｉｉ）無線ネットワークのために特別に設計された効率的なプロトコルを用いることによりサービス品質全体を増加させて、（「バックグラウンド」データ形式だけでなく）すべてのデータ形式と動作できるようにする。モバイル装置（又は他のネットワーク装置）上の上層におけるＴＣＰ／ＩＰに直接つなげることにより、プロトコルが生成され、異なるデータ形式の効率的な優先化、キューイング、及びスケジューリングを与えることにより、電子メール及びコーポレイトアプリケーションと併せて、ＶｏＩＰ、対話型ゲーム、及びストリーミングビデオといったアプリケーションに対する上位の経験が与えられる。
【００１５】
ｉｉｉ）多数のネットワーク（混合ネットワーク）を支持するキャリアにより良好なネットワーク報告及び統合戦略を与える。システム内にはクライアント構成要素があるため、キャリアは、ここでは、そのネットワークをエンドツーエンドで観察し、モバイル装置をネットワーク要素として取り扱い、キャリアがより強力なサービスレベルアグリーメント（ＳＬＡ）及びサービス品質保証を支持することを可能にすることができる。さらに、ネットワーク及びアプリケーションステータス及び性能についての情報は、データを送給するのと同じプロトコルの一部として含まれており、したがって、ネットワークのステータス及び性能を求めるための付加的なトランザクション又はスケジューリングされた試験の必要性をなくす。さらに、キャリアは、ソフトウェア及びモバイル装置構成を含むクライアントの装置上に何があるかを観察し、したがって、キャリアが適時にサービス問題に対処して、費用及び顧客の不満足度の両方を減少させることを可能にする。ネットワーク情報が、データプロトコル送給の一部としてサーバ構成要素に伝送されるとき、キャリアは、ネットワークステータス上で広範囲にわたる報告を受信して、ネットワークの完全な可視性をキャリアにもたらすことができる。本発明によるモバイル装置上のシステムの下層構成要素は、使用ポリシー、アプリケーション形式、及び／又はネットワークポリシーに基づくものとすることができる多数のネットワーク技術（例えば、セルラー２．５Ｇ／３Ｇ／４Ｇ、Ｗｉ−Ｆｉ、及びＷｉＭＡＸ間）の継ぎ目のない切り換え又は同時使用を可能にする。このことは、ユーザ要求を最も満足させる選択肢を用いて、それら自体がどのようにネットワークを使用するか、又は、ユーザ又はアプリケーションを干渉することなく、いつネットワークに切り換えるについて懸念することなく、キャリアがその顧客に多数のネットワークの選択肢を与えることを可能にする。このことは、さらに、キャリアが、例えば音楽ダウンロードのためのＷｉ−Ｆｉのようなバックホール転送のためのより高速なネットワーク、及び、電子メール及び他のデータアプリケーションのためのより高価なセルラーネットワークを使用することを可能することによって、より大きいネットワーク効率を与える。
【００１６】
伝送のためにネットワーク装置からパケットの送給をスケジューリングするための方法が提供され、この方法は、パケットを形式に分類し、パケットを形式と関連するキューに挿入し、形式に基づいてパケットに時間を関連させ、時間の有効期間前に、パケットが伝送のためにスケジューリングされていない場合には、パケットの有効期間が切れたことをスケジューラに通知し、時間の有効期間前に、パケットが伝送のためにスケジューリングされている場合には、キューによりパケットを送信するステップを含む。
パケットは、音声、ビデオ、オーディオ、又はデータの１つに分類され、最大エラー率及び再伝送の最大試行数は前述の形式と関連される。パケットが「音声」形式である場合には、前述のパケットと関連する時間はパレート分布モデルに従い、パケットが「データ」形式である場合には、前述のパケットと関連する時間は指数分布モデルに従う。
伝送のためにパケットをスケジューリングするためのシステムが提供され、キューマネージャと、音声、データ、オーディオ、及びビデオの組を含む形式にパケットを分類し、時間をパケットに関連させるためのパケット分類器と、形式の各々に対して、伝送のために前述の形式のパケットを受信する対応するキューと、を含み、そこから前述のキューマネージャは伝送されるべきパケットを求め、さらに、有効期間が切れたパケットを前述のキューマネージャに報告するためのキュートラッカを含む。
【発明を実施するための最良の形態】
【００１７】
本文書において、以下の用語は、以下の意味を有する。
「アドバンスサーバ」は、ＩＣＳと通信するサーバを意味し、これを通してＩＣＳはネットワークにアクセスする。
「ファーホスト」は、伝送先であるネットワークと通信するモバイル装置、サーバ、又はソフトウェアアプリケーションのような宛先ネットワーク装置である。
「混合ネットワーク」は、異なるネットワークノード及びネットワーク装置に対して異なる通信プロトコルを用いるネットワークであり、モバイル装置を含むことができ、通信のために、１つより多い種類の無線プロトコルを採用することができる。
「ネットワーク装置」は、有線、無線、又は混合ネットワークの一部を形成する他のネットワーク装置と通信することができる装置を意味する。
「無線装置」又は「モバイル装置」は、無線又は混合ネットワーク上で有線又は無線装置と通信するための装置を意味する。
本発明によるシステムは、混合ネットワークと併せて用いるように設計されており、その例は図１及び図２に示される。本発明によるシステム及び方法の例示的な例は混合ネットワークに関して説明されるが、本発明は、単一の通信プロトコルのみが用いられるネットワークにおいて用いることができる。
【００１８】
図１は、幾つかのネットワークが互いに通信する代表的な混合ネットワーク環境１、インターネット１０、及びモバイル装置３０を示す。混合ネットワーク環境１の要素は、モバイル交換センター（ＭＳＣ）４０、基地トランシーバ局（ＢＴＳ）５０、基地コントローラ局（ＢＣＳ）６０、ネットワークノード７０、無線ネットワークコントローラ（ＲＮＣ）８０、公衆交換電話網（ＰＳＴＮ）、汎欧州デジタルセルラーシステムセンターのショートメッセージサービス（ＳＭＳ−ＧＳＭＣ）１００、ホーム位置登録／認証センター（ＨＬＲ／ＡｕＣ）１１０、信号通知システム＃７（ＳＳ７）ネットワーク１２０、モバイルアプリケーションパートプロキシ（ＭＡＰ−Ｐ）を用いる機器識別レジスタ（ＥＩＲ）１５５、汎用パケット無線システム（ＧＰＲＳ）ネットワーク１３０、ゲートウェイＧＰＲＳサポートノード１４０、ブレイクアウトゲイトウェイ（ＢＧ）１４５、ゲートウェイＧＰＲＳサポートノード（ＧＧＳＮ）１５０、公有地モバイルネットワーク（ＰＬＭＮ）１６０、及びＰＬＭＮ間バックボーンネットワーク１７０を含む。
混合ネットワーク環境１では、幅広い種類の構成要素及び通信プロトコルが用いられている。図１は、典型的ではあるが、代表的ではないネットワークを示す。
図２は、垂直方向の図により混合無線ネットワーク環境１の代替的な視点を示す。サテライトネットワーク２００は、最大幅のカバー範囲を与え、サテライトネットワーク２００内には、無線広域ネットワーク２１０、この場合はＧＳＭ／３Ｇネットワーク２２０がある。無線広域ネットワーク２１０内には、メトロポリタンエリアネットワーク２３０、この場合はＷｉＭＡＸネットワーク２４０がある。無線ローカルエリアネットワーク２５０は、無線メトロポリタンネットワーク２６０内にあり、この場合はＷｉＦｉネットワークアクセスポイント２７０である。最後に、無線ローカルエリアネットワーク内には、複数のネットワーク装置３０からなる無線パーソナルエリアネットワーク２８０があり、通信するのにブルートゥース及び超広域（ＵＷＢ）を用いる。
【００１９】
図３及び図４は、本発明によるシステムを組み込むモバイル装置３０の図を示す。図３はこうしたモバイル装置３０の概観を示し、図４はカーネル層３０の詳細及び本発明によるインテリジェントなクライアントシステムとモバイル装置のオペレーティングシステム（ＯＳ）との関係を示す。
トラフィック管理システムは、図３及び図４に示すように、標準的なＯＳライブラリ及びファンクションコールとインターフェースする一連のドライバとしてモバイル装置上に格納されている。トラフィック管理システムは、以下の３つの主要な構成要素からなるインテリジェントなクランアントシステム（「ＩＣＳ」）３１０を含む。
１．上層、ＴＯＰＩＣＳ３２０
２．移送層プロトコルとして用いられる動的マルチメディアプロトコル（「ＤＭＰ」）３３０
３．下層、ＬＯＷＩＣＳ３４０
【００２０】
クライアントＩＣＳ３１０はＴＣＰ３５０と同じ高さにあるが、図５に示すように、データリンク層（ミニポートドライバ３１５）まで延びる。図５は、ＬＯＷＩＣＳ３１０とＯにおける他のプロトコルとの間の関係を示す。ＬＯＷＩＣＳ３１０は、ＯＳ内のプロトコルとして常駐するが、ＴＯＰＩＣＳ３２０以外のどのアプリケーション又は層もＬＯＷＩＣＳ３１０をコールすることはなく、ＬＯＷＩＣＳ３１０は、例えばＴＣＰ／ＩＰ３５０のような他のプロトコルに到達するコールをインターセプトする。プロトコルは、ＯＳ内の階層に関して、鎖形態で互いに関連されている。各々のプロトコルは、鎖における次のプロトコルを指し、それ自体をミニポートドライバ３１５と呼ばれる使用可能なネットワークドライバにバインドする。したがって、ＬＯＷＩＣＳ３１０は、すべての他のプロトコルがロードされた後でロードされ、次いで、鎖における第１のプロトコルエントリ、すなわちＴＣＰ／ＩＰ３５０を指し、使用可能なネットワークドライバ、すなわちミニポートドライバ３１５に登録し、バインドする。このように、ＬＯＷＩＣＳ３１０はどのようなパケットもインターセプトして、ＩＰ層をＭＡＣ層に残し、したがって、ポリシー及びスケジューリングをＬＯＷＩＣＳ層３１０におけるパケットに適用することができる。
図３に示すモバイル装置３０の他の構成要素は、ライブラリ３７０、システムコールインターフェース３８０、ＴＣＰ／ＩＰ．ｓｙｓファイル３９０、ファイルサブシステム４００、バッファキャッシュ４１０、装置ドライバ４２０、キャラクタ４３０、ブロック４４０、ハードウェアコントロール４５０、及びハードウェアレベル４７０におけるハードウェア／ＮＩＣ４６０を含む。カーネルレベル３００は、さらに、スケジューラ７００、メモリマネージャ５３０、及びプロセス間コミュニケータ５４０を含むプロセス制御サブシステム５１０を含む。
【００２１】
ＴＯＰＩＣＳ層３２０
ＴＯＰＩＣＳ層３２０の主要な仕事は、アプリケーション３６０からのコールとインターフェースすることである。ＴＯＰＩＣＳ３２０は、ソケット情報、装置及びファイルオブジェクト情報を含むすべてのアプリケーション（リクエスタ）情報、及び、予測される最大伝送ユニット（ＭＴＵ）、バッファサイズ、受信インターフェース、予測される受信メッセージフォーマット、タイムアウト等を含むそれらのインターフェースを維持する。ＴＯＰＩＣＳ層３２０は、アプリケーション３６０の予測される挙動に関する記録を維持する。図４に示すように、モバイル装置３０の他の構成要素は、ネットワークドライバインターフェース仕様（ＮＤＩＳ）インターフェース４８０、ＵＤＰインターフェース４９０、ＩＰインターフェース５００、及びＡＲＰインターフェース５１０を含む。移送ドライバインターフェース５５０はＴＯＰＩＣＳ３２０とアプリケーション３６０との間にある。
ＴＯＰＩＣＳ層３２０は、さらに、下層、すなわちＬＯＷＩＣＳ３４０とも通信して、ＬＯＷＩＣＳ３４０に、本明細書においては「プレチャネル伝送」と呼ばれる、出て行くトラフィックの形式を知らせる。ＴＯＰＩＣＳ層３２０は、パケットをアセンブルするためのＴＯＰＩＣＳ−ＤＭＰアセンブリワーカ（図示せず）と、アプリケーション３６０と通信するためのＴＯＰＩＣＳインターフェースとを含む。
【００２２】
出て行くトラフィック
以下は、ＩＣＳ３１０を通してモバイル装置３０によりアプリケーション３６０によってファーホストに送信される出て行くパケットのトランザクションシーケンスである。
１．アプリケーション３６０のプロトコルは、アプリケーション名、通信ポートを用いることにより、及び／又は、接続を要求した最初の２つのユーザアプリケーションのヘッダ情報を走査することにより、ＴＯＰＩＣＳ３２０によって識別される。付加的な情報は、ＴＯＰＩＣＳ３２０により、抽出された情報と、装置に格納されたアプリケーションＩＤ及び／又は署名及び／又はアプリケーションカタログＩＤと比較することによって証明される。ＴＯＰＩＣＳはさらに、アプリケーション３６０が要求した移送層プロトコルの種類を調べて判断する。
２．リクエスタ（アプリケーション３６０）に対する応答は、ＴＯＰＩＣＳ３２０によって、要求（例えば、ＴＣＰソケットを生成するための要求及び／又は特定のホストに接続するための要求）が成功したか又は失敗したかに応じて、関連するタスクのアプリケーション３６０に送られる。
３．ＴＯＰＩＣＳ３２０は、次いで、アプリケーション３６０、及びファーホストからの応答を適当なアプリケーション３６０にフォワードするのに用いられるソケット情報についてのアプリケーションブックキーピングデータ構造を生成及び維持する。
４．ＬＯＷＩＣＳ３４０は、ＴＯＰＩＣＳ３２０により、適当な出て行くトラフィックの形式について通知される。
５．ＴＯＰＩＣＳは、次いで、アプリケーションの種類に基づいて対応するＤＭＰ要求プロトコルを構築するためにアプリケーション３６０データをＤＭＰサブモジュールに送り、ＤＭＰパケットが構築される（以下に述べられる）。
６．ＤＭＰパケットはＵＤＰ１９０に送られ、次いでＩＰ５００層に送られる。
７．ＬＯＷＩＣＳ３４０はＩＰ／ＵＤＰ／ＤＭＰパケットをＩＰ５００層から受信する。
８．ＩＰ／ＵＤＰ／ＤＭＰパケットはスケジューリングされて、アドバンスサーバを通してファーホストに伝送されるように、適当なネットワークインターフェースカード（ＮＩＣ）４６０に送られる。
【００２３】
入ってくるトラフィック
ＩＣＳ３１０がモバイル装置３０のパケットを受信するプロセスは図６に示されており、以下の通りである。
１．ＤＭＰパケットがＮＩＣ４６０により受信される。
２．ＬＯＷｓＩＣＳ３４０がＩＰヘッダをＤＭＰパケットから分離する。
３．ＤＭＰの形式がＤＭＰヘッダ及びＬＯＷＩＣＳ３４０レシーバモジュールにより識別されて、局所ジッタ操作が必要かどうかを判断する。
４．ＤＭＰがリアルタイム以外のいずれかの形式のデータを含む場合には、ＤＭＰパケットは直接コールを通してＤＭＰモジュール内の構成要素であるＴＯＰＩＣＳ  ＤＭＰアセンブリワーカ（図示せず）に送られる（そのため、パケットはＩＰ層５００を通って進む必要がない）。
５．ＴＯＰＩＣＳ−ＤＭＰアセンブリワーカモジュールは、パケットがメッセージを構築するようにアセンブルし、メッセージが完成したときにはＴＯＰＩＣＳ−Ｉｎｔｅｒｆａｃｅ５３０に送られる。
６．ＴＯＰＩＣＳ−Ｉｎｔｅｒｆａｃｅ５３０は、そのアプリケーションブックキーピングデータ構造を通して、メッセージを受け取るべき適当なアプリケーション３６０を判断する。
７．ＴＯＰＩＣＳ−Ｉｎｔｅｒｆａｃｅは、メッセージを標準的なＯＳコールを通してアプリケーション３６０に送る。
【００２４】
ＤＭＰ（動的マルチメディアプロトコル）
ＤＭＰ３３０は、どのような形式のデータも運ぶことができるプロトコルである。ＤＭＰ３３０は、必要に応じて、例えば、多様な承認要求及び最適なパケットサイズにそれ自体を動的に適応させる。ＤＭＰ３３０は、ＵＤＰの特性の幾つか、さらに、ＴＣＰの特性の幾つかを共有するが、ＤＭＰは、図１１、図１２、図１３に示すように、その動的ヘッダビットにより、どのような形式の無線リンク形式においても各々のデータ形式の要求を満たしつつどのような形式のデータも運ぶ。ＤＭＰ３３０は、ＵＤＰ／ＩＰ層５００を移送及びネットワーク層プロトコルとして用いる。ＤＭＰ３３０は、ＩＰｖ４及びＩＰｖ６の両方により動作し、アプリケーションに対する標準的なインターフェース、及びＵＤＰ／ＩＰ層５００に対する標準的なインターフェースを提供することが好ましい。図１３は、ＤＭＰの分岐を示す。図１３に示すように、ヘッダビットにより識別される３つのレベルがＤＭＰにある。
１．ＤＭＰ層１：「ＤＭＰインターナル」及び「ＤＭＰ」通信（ＤＭＰ  ＣＯＭ）を含む。ＤＭＰインターナルは、例えば、ＴＯＰＩＣＳ３２０とＬＯＷＩＣＳ３４０との間の通信のような単一のサブシステム内の構成要素間の内部通信に用いられる。
２．ＤＭＰ層２は、ＤＭＰ  ＣＯＭから分岐したものであり、信号通知、制御、及びセッションという３つの種類のメッセージを運ぶ。ＤＭＰ信号通知は、以下のような２つのサブシステム間の通信に用いられる。
ａ．ＤＭＰ制御
ＡＰにおけるＬＯＷＩＣＳ←→ソフトウェア間の活動、及び、制御目的のためのＡＰにおけるソフトウェア←→サーバ間の活動。例えば、サーバはＩＣＳに対して、パケットサイズを変更するように通知するか、又は、ＩＣＳはサーバにネットワークステータス情報又はログを与える。さらに、ＤＭＰ制御は、制御メッセージをＩＣＳに送って、ＩＣＳの機能性を制御するのに用いられる。
【００２５】
３．ＤＭＰ層３は、ＤＭＰ信号通知及びＤＭＰセッションから分岐したものである（各々が２つに分岐する）
ａ．ＤＭＰＣｏｍＳｉｇｎａｌｉｎｇ要求：登録、再登録、非登録、及び承認といった信号通知要求をＴＯＰＩＣＳ３２０←→アドバンスサーバ間で運ぶ。
ｂ．ＤＭＰＣｏｍＳｉｇｎａｌｉｎｇ応答：要求された信号に応答を運ぶ。
ｃ．ＤＭＰＣｏｍＳｅｓｓｉｏｎメッセージ：実際のアプリケーションデータを運ぶ。
ｄ．ＤＭＰＣｏｍＳｅｓｓｉｏｎ制御：ソケット接続のようなアプリケーション接続要求、及び／又は、ＲＴＣＰのような制御フィードバック情報。
図１１及び図１２は、上述の３層構造によるＤＭＰ信号通知及びＤＭＰセッション両方に対するＤＭＰ構造の詳細及び実施形態を示す。本明細書及び図において説明される特徴のサブセットを含むＤＭＰプロトコルの他の実施形態を用いることができる。
【００２６】
ＬＯＷＩＣＳ層
ＬＯＷＩＣＳ層３４０は、４つの主要なサブモジュールを含み、各々は以下で説明される。ＬＯＷＩＣＳ層３４０は、層、フッキング（層をオペレーティングシステムに挿入するための方法）、及びプロトコルとして３つの異なるフォーマットにおいて、モバイル装置３０のＯＳに常駐する。図７は、ＯＳ及びその内部構成要素に対するＬＯＷＩＣＳ３４０の概観を示す。図７に示されるように、モジュールは以下のものを含む。
１．スケジューラシステム７００
２．ネットワークモニタ５７０
（ａ）周囲発見
（ｂ）信号対雑音比テラー
（ｃ）パケットフォワーディング
３．局所ジッタバッファ７１０
４．パケット分類器７２０
【００２７】
ＬＯＷＩＣＳ−スケジューラ
本発明によるシステムは、モバイル装置３０（又は他のネットワーク装置）により受信された又は送信された異なる形式のデータを区別する能力を有し、こうしたデータに対するモバイルトラフィックモデルを識別することができる。各々の異なるデータ形式は、エンドツーエンド伝送制御を含むそれ自体の要求、及び待ち時間に敏感なリアルタイム要求を有する。本発明によるシステムの目的は、これらの異なるデータ形式に対して、できるだけ多くの要求を満たすことである。したがって、システムはデータを区別し、無線リンク上のトラフックを制御する、ロードを維持する、ネットワーク容量を増加させる、帯域幅の改善を与えるという目的でパケットを操作する。
データ形式の要求を識別するために、３つのパラメータが識別され、考慮される。
ｉ）最大エラー率：物理チャネル並びに移送層プロトコルに対するエラー検出の種類を識別するのに用いられる許容できる値として解釈される。
ｉｉ）最小処理能力：異なる形式のパケットは送給のために異なる時間要求を有するため、送給の優先度として解釈される。幾つかのデータ形式においては（音声、ストリーミング、ビデオ等）、時間の有効期間が切れた後のパケットの伝送は、単純に、ネットワーク経費の一部になるため、時間切れになった形式のデータは、送給されない。
ｉｉｉ）最大遅延：そのデータ形式に対する再伝送の最大試行数、及び再伝送試行間の時間として解釈される。
【００２８】
多様なトラフィック形式を管理するために、システムは「寿命」を計算する。この寿命は、特定のアプリケーションのすべてのパケットに対して決定される時間の期間である。例えば、パケットの群は、メッセージアプリケーションに属することができる。「セッション」はパケットが属する寿命であり、単一のアプリケーションのその寿命に存在する。寿命は、決定論形式であってもよいし又はランダム分布到着間隔形式であってもよい。異なるサービスクラス、すなわちバックグラウンド、対話型、ストリーミング、及び会話型のサービスは、音声、ビデオ、オーディオ、及びデータというのカテゴリにトラフィッククラスを狭くするのに用いられ、各々のデータ形式の特性及び要求を概説することができ、モバイルトラフィックモデルは以下に表１及び表２に識別される。
2008546328.tif 000003
【００２９】
一例として、インターネット・プロトコル上の音声（ＶｏＩＰ）は、待ち時間に高度に敏感であるが、エラーには敏感でなく、ユーザは常に他の当事者に繰り返すように要求することができる。しかし、ＴＯＰＩＣＳ３２０に到着するデータ速度は一定であり、パケットサイズも一定である。ＶｏＩＰが生成するトラフィックを見ると、パレート分布のモデルに従う。しかし、インターネット・エキスプローラが典型的に通信するようなデータは、待ち時間に対して非常に敏感度が低いが、例えば、破損した銀行決済情報のようなエラーに対しては高度に敏感である。データに対するパケットの到着率（又はその生成率）は、バーストで生成されて到着するため、可変で予測不能なものであり、これが生成するトラフィック形式は指数分布に従う。このトラフィックモデルの形式の情報は、スケジューラシステム７００が、予測されるトラフックモデルの形式、及び、使用可能なネットワークがトラフィックを送給する能力があるかどうかに基づいて、スケジューリング決定することを可能にする。例えば、モバイルユーザが、ＧＰＲＳのような、ＶｏＩＰアプリケーションを用いる２．５生成ネットワーク上にいる混合ネットワークにおいては、この形式のネットワークはこの形式のトラフィックを送給する能力をもたないため、適当ではない。
2008546328.tif 000004
【００３０】
表２に示すように、及び、表１に基づいて、トラフィック形式は、それらがネットワークに対してサービス、送給、及び転送されなければならない優先度、及び、耐ビットエラー率（ＢＥＲ）に関して分類されて、パケットにおけるエラーがＢＥＲより少ない場合には、データの再伝送を要求する必要、さらに、データが（寿命に基づいて）なくなる前に、何回データを再伝送できるかを判断する必要がなくなる。例えば、ＶｏＩＰパケットは、（到着していない場合には）、パケットの寿命が切れる前に高速再伝送を用いて３回だけ再伝送することができ、これは（ＶｏＩＰ標準で設定されるように）エンドツーエンドで２５０ミリ秒である。この方法を用いると、Ｔの値（到着間隔時間ｔの予測される値）、Ｓ（最小パケットサイズ）、及びα（定値）を、表１に示すパレート又は指数分布関数に挿入して、スケジューラシステム７００がパケットスケジューリングのための決定をするようにすることができる。
異なるサービスクラスは、対話型のサービスクラスを含み、これは、要求／応答指向であり、ユーザ対話を必要とするアプリケーション／トラフィックの形式を指す。このアプリケーションの例は、要求が送信され、応答が受信されるインターネット・エキスプローラである。バックグラウンドのサービスクラスは、バックグラウンドで稼動し、バースト形式の対話を行うアプリケーション形式を指す。電子メールはバックグラウンドで稼動して情報を受信し、ユーザ対話の必要がないため、電子メールがこのアプリケーション形式の例である。ユーザが、バックグラウンドで電子メールを稼動させ、情報を受信するのに対話する必要がないため、このアプリケーション形式の例となる。ストリーミングのサービスクラスは、必ずしもリアルタイムである必要はない、ビデオ又はオーディオと同様なメディアを受信するための要求があるアプリケーション形式を指す。会話型とも呼ばれるリアルタイムのサービスクラスは、非常に時間に敏感なサービスクラスである。これらは、典型的に、業界により設定された一定の寿命を有する。一例として、インターネット・プロトコル上の音声パケットは、２５０ミリ秒の遅延しか許容されていないため、それより後で受信された場合には、パケットは受信者により処理されない。この形式のアプリケーション／サービスの例は、インターネット・プロトコル上の音声（ＶｏＩＰ）及びテレビ電話である。
【００３１】
スケジューラシステム７００は、３つの主要なタスク、すなわち、キュー管理、スケジューリング、及びチャネルＳＮＲテラーを完成させる。
図８に示すように、スケジューラシステム７００におけるキューマネージャ８００は、パケット分類器８１０、異なる形式のデータ専用の多数のキュー８２０、及び各々のキュー内に格納されたトラフィック及び各々のキュー内の期限切れパケット及び遅延パケットの数を報告するキュートラッカ８３０（キュースキャナ及び分析器）を含む。スケジューラ８４０は、キューマネージャ８００とデータリンク層８５０との間の決定メーカとして働く。スケジューラ８４０は、キューマネージャ８００及びデータリンク８５０のコンテンツを調べて、決定をする。スケジューラ８４０は、さらに、ネットワーク層とデータリンク層８５０との間のデータトラフィックを管理する。このプロセスは、高層アプリケーション又はネットワーク層を、下層との直接的な対話から隔離する。しかし、これらの層は、相互に、互いを認識している。
実際、ＩＰ層５００は、パケットをパケット分類器８１０に送り、パケット分類器８１０はパケット形式を調べて、パケット形式に基づいて、パケットにとって適当な時間を関連させ、次いで、パケットを適当なキュー８２０に挿入する。システムの好ましい実施形態においては、キューは、上述のように４つの区別できるデータ形式、すなわち、音声、ビデオ、オーディオ、及びデータのためのものである。無線ネットワークが成長するに伴い、異なる特性の他のデータ形式を含むことができるようになる。キュー８２０により課される課題は、モジュールがキューを監視する必要性であり、このことは、通常、伝送スケジューリングに遅延を加える。この理由のために、キュー８２０のバッファに挿入される各々のキューはアクティブな記録であり、タイプタイマーパケットの生成をもたらす。タイマーパケットは、さらに、（音声、ビデオ、オーディオ、又はデータタイマーとして）タイプされるためこれらのパケットの期限は、各々のタイマー毎に異なる。タイマーの期限前にパケットがスケジューラ８４０に到着しなかった場合には、パケットはキュー８２０を出て、キュートラッカ８３０にその期限切れについて通知する。キュートラッカ８３０は、スケジューラ８４０に、期限切れパケットの数を報告し、したがって、各々のキュー８２０でのトラフック輻輳についてスケジューラ８４０に通知する。スケジューラ８４０は、キュー８２０内のデータ形式の時間敏感度に基づいて、どのキュー８２０が最初にサービスを受けるべきであるかについて判断する。スケジューラ８４０は、さらに、ダウンリンクデータトラフィックを、多数のモバイル装置に、及び異なるデータトラフィックをモバイル装置内にスケジュールリングするようにサーバ上に配置される。
【００３２】
ＬＯＷＩＣＳ−ネットワークステータスモニタ
図９に示すＳＮＥテラー９００は、ネットワークステータスモニタモジュールの一部である。ＳＮＲテラーは、現在（０）と次の１０ミリ秒との間の時間枠において、将来の信号対雑音比を予測する。この構成要素の目的は、予測される信号対妨害対雑音比（ＳＩＮＲ）値を検出できるようにすることである。一般に、ＳＩＮＲは、バックグラウンドの雑音比に対する信号強度の比である。リンク速度はユーザ位置のＳＩＮＲに依存する。ＳＩＮＲは、セル内で大幅に異なることがある。この変動は、すべての無線システムに内在する特性であり、主として、ＲＦ伝搬、ビルディングペネトレーション損失、フェージング効果損損失、及び同一チャネル干渉の変動のために生じる。その結果、ユーザにより経験されるリンク速度は、ちょうどＤＳＬの場合のように、セル内のユーザ位置によって決まるとすることができる。
ネットワークモニタ５２０からのサポートに基づいて、ＳＮＲ値が監視される。ＳＮＲテラーシステムの目的は、監視されたＳＮＲ値を受信し、過去５ミリ秒におけるこれらの値を見ることにより、予測されるＳＮＲ値を計算して、この値が次の５から１０ミリ秒にあるかを推定できることを呈示することである。結果として得られるこの予測値は、ネットワークモニタステータスモジュールにより用いられて、ネットワークを１つのネットワーク形式から別のネットワーク形式にいつ交換するかを決定し、さらに、スケジュールラシステムにより用いられて、このパラメータを考慮して、スケジューリングの決定をする。
【００３３】
ＬＯＷＩＣＳ−周囲発見
周囲発見は、本発明によれば、無線リンク上で、例えば、モバイル装置ユーザが空港で移動するように（「ローミング」として知られる）、１つのアクセスポイント（「ＡＰ」）から別のＡＰに移動するのに必要とされる時間を減少させる方法である。特に、ＲＦ層（層１）において、この遅延をなくすことに対して幾つかの異なる研究領域がある。好ましい実施形態においては、ＲＦレベル待ち時間減少層３．５解決法が用いられる。（例えば、ＴＣＰ／ＩＰベースのもののような）接続指向アプリケーションにおいては、通信の転送及び１つのＡＰから別のＡＰへの接続に対する待ち時間は、新規なＩＰを新規なドメインから受信した後のデータの再伝送及びＴＣＰの再確立をもたらすことがある（ドメイン内移動の場合において）。時間に敏感なアプリケーションにおいては、このことは、１つのＡＰ又はドメインから別のＡＰ又はドメインに移動することにより引き起こされる付加的な遅延をもたらす。
好ましい実施形態においては、層２ローミングのスーパーセットである層３．５解決法が用いられる。本実施形態においては、メディアアクセス制御（ＭＡＣ）層の上で、ＩＰ層５００の下の層がＡＰ及びドメインを監視し、異なるＡＰ間でフォワードされるパケットを操作し、さらにどのような変化からも高層を遮蔽する。この解決法は、最初に層２ローミングを必要とするが、新規なＡＰに対する認証及びローミングアプリケーションの付加的な遅延はなくす。
好ましいローミング方法を実現するためには、以下の３つの主要なエリアが考慮される。
ａ）周囲発見
ｂ）前登録
ｃ）パケットフォワーディング
【００３４】
好ましい実施形態においては、ＬＯＷＩＣＳ３４０内に配置されたネットワークステータスデータモジュール５７０は、ネットワークステータスデータ及び周囲発見を与える。本実施形態においては、ＬＯＷＩＣＳ３４０は、ＩＰ層５００に対して単一の仮想アダプタインターフェースを有するが、それ自体をできるだけ多くの使用可能なＮＩＣ４６０にバインドすることができる。ネットワークステータスモニタ５７０は、ＡＰ名、ＭＡＣ、信号強度、雑音強度、及び信号対雑音比を含む、Ｗｉ−Ｆｉカードから収集されたＡＰ情報を監視する。ネットワークステータスモニタは、小さい時間枠内の過去から始まる将来への時間期間に対するＳＮＲを計算するＳＮＲテラー９００から情報を受信することにより、次に最も近いＡＰを検出する。ＳＮＲテラー９００は、次いで、移動されるべきであると決定された「バックアップＡＰ」と共に、前登録情報をネットワークステータスモニタ５７０に送信する。したがって、ＳＰはローミングを行う決定の前に配置される。
好ましい実施形態においては、ＡＰは、アップデート可能なファームウェアを含む。通常、ＡＰファームウェアは、ルーティング表、ＭＡＣアドレスアップデート表、ＤＮＳ、及び他の機能を含む、ＩＰ層プロトコル構造を含む。このファームウェアは、前登録表を加えることによりアップデートすることができる。ＡＰを識別した後で、ネットワークステータスモジュールは、次いで、前登録要求をＡＰに送信する。ＡＰはアドバンスサーバ（「ＡＳ」）に要求をフォワードし、モバイル装置３０に対して認証を求める。ＡＳは、そのデータベースに対してモバイル装置３０の認証をチェックし、認証をＡＰに送信する。ＡＰは、次いで、ＡＰの前登録表にモバイル装置３０のＭＡＣアドレスを記録する。ＡＰは、さらに、それ自体のＭＡＣアドレス、ネットワークアドレス、及び寿命をモバイル装置３０に送信する。ネットワークステータスデータモジュール５７０がこの情報を受信したときには、次のローミングに使用するためにこれを格納する。寿命は、ネットワークステータスモニタ５７０に、ＡＰがその前登録表内に情報を保持する時間の期間を知らせる。この時間が切れた場合には、ネットワークステータスモニタ５７０は、前登録要求の別の回を探すべきである。その間、ネットワークステータスモニタ５７０は、バックアップＡＰが次をローミングするのに適当なＡＰであるかどうかを判断するために、継続的にＳＮＲを監視する。
【００３５】
バックアップＡＰ  ＳＮＲが劣化した場合には、ネットワークモニタは、新規なＡＰを見出し、前登録することを考える。ＬＯＷＩＣＳ３４０におけるネットワークステータスデータモジュール５７０は、ネットワークステータス及びＳＮＲを継続的に監視する。高速ローミング時間とクライアント安定性との間でバランスを維持することが重要である。一例として、ＡＰの信号強度は、その環境及び周波数の関数として減少するのが通常であり、したがって、こうした発生は、ＡＰ信号強度の即時の発生とすることができ、こうしたＡＰに対する通常の信号強度ではないため、ローミング又は「ハンドオフ」を考慮すべきではない。これを達成するためには、そのＡＰにローミングする前に信号の安定性に対する時間枠閾値が生成される。好ましい閾値は、５から１０ミリ秒であるべきであるが、より長い又はより短い期間を用いてもよい。
ＳＮＲは、ローミングが生じる前に、アクティブＡＰにおいて減少し、バックアップＡＰにおいて増加すべきである。１つのＡＰ又はドメインから別のＡＰ又はドメインに移動するために、ネットワークステータスモニタ５７０は、まず、バックアップＡＰを通してアップデート登録（再登録）をＡＳに送信する。バックアップＡＰは既にその前登録表に情報を有しているため、単に要求をＡＳに直ちに送る。このことは、ＡＳにＩＰの変化について通知するため、ＡＳは、モバイル装置の新規な宛先ＩＰを通して、ダウンリンクトラフィックの方向をモバイル装置３０に変え始める。モバイル装置３０がＡＳから確認を受信した後で、モバイル装置３０はアップリンクトラフィックの方向を変える。この時間において、モバイル装置３０は、確認を受信するまで、どのようなアップリンクトラフィックもＡＳに送信しない。この方法は、ローミング中のパケット損失を減少させ、情報が既にＡＰおける前登録表にあり、モバイル装置ＩＰに対する変更はモバイル装置及びオンターネット上のファーエンドアプリケーションの両方のアプリケーションに対して完全にトランスペアレントであるため、ローミング持続時間を減少させる。後者は、ＡＳをモバイル装置としてみなす。
図１０は、前登録及び周囲発見におけるイベントの全体的なシーケンスを示す。
【００３６】
ＬＯＷＩＣＳ３４０の局所ジッタハンドラ７１０は、受信したリアルタイムのデータ形式を操作する。この主要な仕事は、ネットワークステータス及び受信した情報に基づいて、ＶｏＩＰ及びリアルタイムのビデオ上のジッタを操作することである。このことは、高いネットワーク経費を生成するＲＴＣＰの使用を不要にする。これを実現するために、バッファエージェントは、ＤＭＰ内のコンテンツ形式（ＴｏＣ）を調べて、ＤＭＰをより高い層に送給するか、又は、バッファモジュール内に保持しておくかを決める。バッファに挿入される各々のパケットは、タイマーに取り付けられる。タイマーが切れると、データパケットは高層におけるバッファキューを出る。このことは、バッファの個々の行を、バッファの状態を「見る」アクティブなエージェントにする。このことは、エージェントが、バッファから何を除去しなければならないか及び何を除去しなくてもよいかについて追跡する必要性を減らし、したがって、バッファ遅延を減少させる。決定は、ＲＴＣＰにより与えられるフィードバック機構ではなく、リアルタイムのネットワーク情報に基づいて行われるため、ジッタバッファは下層にある。入ってくるフィードバックの周波数は無線トラフィックの効率に調整できず、さらに、ジッタを減少させるために、十分で適時の情報を与えるため、フィードバック機構はあまり効率的なものではない。上述のプロセスを用いることにより、ジッタは２０ないし３０％だけ減少させることができる。
【００３７】
ネットワークポリシー
本発明による方法及びシステムは、さらに、ネットワークポリシーの要求に基づいて、ネットワーク装置を制御することができる。こうした場合においては、ネットワークポリシーを作成して、格納のために、ネットワーク装置が登録を要求したときに、モバイル装置のようなネットワーク装置に送信されなければならない。
アプリケーションがネットワークにアクセスすることを試みているとき、ネットワークポリシーの使用がチェックされ、ＴＯＰＩＣＳ及びＬＯＷＩＣＳは、ポリシーにより、アプリケーションに対するネットワークアクセスを与える。ネットワーク装置とネットワークサーバとの間のトランザクション中、ネットワークポリシーがアドバンスサーバにおけるデータベースで変更された場合にはどのようなときでも、この変更は「ポリシープッシュ」コマンドの形態でネットワーク装置に送られる。
以下の２つの表は、好ましい実施形態において、登録時間にネットワーク装置に送られるポリシーパラメータを記述する。表３は、ポリシーパラメータを記述し、表４は「サービスクラス」データ構造を記述する。
表３
2008546328.tif 000005
表４
2008546328.tif 000006
【００３８】
ネットワーク性能
本発明による方法及びシステムは、どのような形式のネットワーク上のどのようなアプリケーションのキャリアに対しても、ネットワーク上の付加的なトランザクションを生成することなく、サービス性能及びステータス情報を与えることができる。これを行うためには、ネットワーク装置は、アプリケーション毎に許容できる性能閾値パラメータを装置に格納する。アプリケーションデータがアドバンスサーバに運ばれるとき、ネットワーク装置は、パケット毎に用いられるネットワーク形式、各々のパケットに対する信号対雑音比のパラメータ、損失したパケット、複製、再伝送、及びアプリケーションメッセージを送給し、応答情報を受信するのに必要な合計時間についての情報を格納する。この情報は、ネットワークステータスモニタ５２０におけるデータベース内に格納される。パラメータのうちのいずれかが、データベースに設定された、ネットワーク装置に局所的に設定された、又は、（ネットワークポリシーといった）特定の規則に基づいて計算された閾値を超える場合には、アラートが生成され、アドバンスサーバに送信される。
【００３９】
アプリケーションデータ形式の判断
本発明によるシステム及び方法は、アプリケーションを変更することなく、モバイル装置のようなクライアント装置上のアプリケーションデータ形式を判断するのに用いることができる。これは、コールをインターセプトすることにより、ＩＣＳがアプリケーション要求を受信したときに行われる。ＩＣＳは、次いで、アプリケーション名、及び／又はメッセージを送信するのに用いられるポート、及び／又は（接続要求のために送信された最初の２つのアプリケーションメッセージの一部である）ヘッダ情報を識別する。ＶｏＩＰ、ビデオ、電子メール、インターネット・エキスプローラのような抽出された情報は、リアルタイム、ストリーミング、バックグラウンド、対話型といった対応するタグを生成するのに用いられて、パケットはこれに従ってタグ付けされる。
上述のシステム及び方法は、ＲＡＭ内のようなネットワーク装置内のコンピュータ可読メモリ上、又は、コンピュータ可読格納媒体上に格納された一連の命令として実施することができる。この方法及びシステムは、コンピュータデータ信号を具現する搬送波に存在する一連の命令として表現して、命令をネットワーク装置又はサーバに通信することができ、モバイル装置又はサーバ内のプロセッサにより実行されたときに方法が実行される。
上述の方法及びシステムは、無線又は混合ネットワークの内容で説明されたが、さらに有線ネットワーク装置が「スマート」で、入ってくるパケットを識別し、処理することができる場合には、有線ネットワークにおいても適用できる。
本発明の特定の好ましい実施形態が例示目的のために詳細に開示されたが、本発明の範囲内には、開示された装置の変形又は修正が含まれることが理解される。
【図面の簡単な説明】
【００４０】
【図１】混合ネットワークを示すブロック図である。
【図２】混合無線ネットワークの垂直方向図を示すブロック図である。
【図３】本発明によるモバイル装置の概略図である。
【図４】本発明によるシステムにおけるクライアント層の概観を示すブロック図である。
【図５】他のプロトコルに対するクライアント位置を示すブロック図である。
【図６】アプリケーションに入ってくるトラフィックの管理を示すフロー図である。
【図７】下方クライアントアーキテクチャを示す概略図である。
【図８】スケジューラを示す概略図である。
【図９】ＳＮＲテラーを示す概略図である。
【図１０】前登録及び発見プロセスを示すフローチャートである。
【図１１】ＤＭＰ信号通知構造を示す表である。
【図１２】ＤＭＰセッションの好ましい実施形態を示す表である。
【図１３】ＤＭＰパケットの構造を示すツリーである。
【図１】
2008546328.tif 000007
【図２】
2008546328.tif 000008
【図３】
2008546328.tif 000009
【図４】
2008546328.tif 000010
【図５】
2008546328.tif 000011
【図６】
2008546328.tif 000012
【図７】
2008546328.tif 000013
【図８】
2008546328.tif 000014
【図９】
2008546328.tif 000015
【図１０】
2008546328.tif 000016
【図１１】
2008546328.tif 000017
【図１１−２】
2008546328.tif 000018
【図１２】
2008546328.tif 000019
【図１２−３】
2008546328.tif 000020
【図１３】
2008546328.tif 000021
【図１２−２】
2008546328.tif 000022
【手続補正書】
【提出日】平成20年2月12日(2008.2.12)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
伝送のためにネットワーク装置からパケットの送給をスケジューリングするための方法であって、
（ａ）パケットを形式に分類し、
（ｂ）前記パケットを前記形式と関連するキューに挿入し、
（ｃ）前記形式に基づいて前記パケットに時間を関連させ、
（ｄ）前記時間の有効期間前に、前記パケットが伝送のためにスケジューリングされていない場合には、前記パケットの有効期間が切れたことをスケジューラに通知し、
（ｅ）前記時間の有効期間前に、前記パケットが伝送のためにスケジューリングされている場合には、前記キューにより前記パケットを送信する
ステップを含むことを特徴とする方法。
【請求項２】
前記ステップ（ａ）において、前記パケットは、音声、ビデオ、オーディオ、又はデータのいずれか１つに分類されることを特徴とする請求項１に記載の方法。
【請求項３】
最大エラー率は前記形式と関連されることを特徴とする請求項２に記載の方法。
【請求項４】
再伝送の最大試行数は前記形式と関連されることを特徴とする請求項３に記載の方法。
【請求項５】
前記パケットが「音声」形式である場合には、前記パケットと関連する前記時間はパレート分布モデルに従うことを特徴とする請求項４に記載の方法。
【請求項６】
前記パケットが「データ」形式である場合には、前記パケットと関連する前記時間は指数分布モデルに従うことを特徴とする請求項５に記載の方法。
【請求項７】
伝送のためにパケットをスケジューリングするためのシステムであって、
（ａ）キューマネージャと、
（ｂ）音声、データ、オーディオ、及びビデオの組を含む形式にパケットを分類し、時間を前記パケットに関連させるためのパケット分類器と、
（ｃ）前記形式の各々に対して、伝送のために前記形式のパケットを受信する対応するキューと、
を含み、そこから前記キューマネージャは伝送されるべき前記パケットを求め、
（ｄ）有効期間が切れたパケットを前記キューマネージャに報告するためのキュートラッカ
を含むことを特徴とするシステム。
【請求項８】
ネットワーク装置において動作するアプリケーションからファーホストにパケットを伝送するための方法であって、
（ａ）前記アプリケーションから送信された後で、前記装置内の前記パケットをインターセプトし、
（ｂ）前記パケットの伝送に用いられたプロトコル及び前記パケットの分類に関する情報を含むように、前記パケットを修正し、
（ｃ）前記分類に基づいて、伝送のために前記修正されたパケットをスケジューリングし、
（ｄ）前記パケットを前記ファーホストに伝送する
ステップを含むことを特徴とする方法。
【請求項９】
前記ステップ（ａ）の前に、
（ｉ）前記パケットを送信しているアプリケーションを識別する
ステップをさらに含むことを特徴とする請求項８に記載の方法。
【請求項１０】
前記ステップ（ｉ）の後で、
（ｉｉ）前記アプリケーションと関連する転送プロトコルを要求する
ステップをさらに含むことを特徴とする請求項９に記載の方法。
【請求項１１】
前記ステップ（ｉｉ）の後で、
（ｉｉｉ）前記パケットが処理されたという応答を前記アプリケーションに送信する
ステップをさらに含むことを特徴とする請求項１０に記載の方法。
【請求項１２】
前記ステップ（ｂ）の後で、
（ｂ．１）前記パケットの形式により前記パケットを分類する
ステップをさらに含むことを特徴とする請求項１１に記載の方法。
【請求項１３】
前記ステップ（ｃ）の後で、
（ｃ．１）前記修正されたパケットを前記装置におけるＵＰＤ／ＩＰに送る
ステップをさらに含むことを特徴とする請求項１２に記載の方法。
【請求項１４】
受信したパケットを管理するネットワーク装置のための方法であって、
（ａ）前記ネットワーク装置により、前記パケットを送信しているアプリケーション及び前記パケットの分類に関するデータを有するパケットを受信し、
（ｂ）ＩＰヘッダを前記パケットから分離し、
（ｃ）メッセージを構築するように前記パケットをアセンブルし、
（ｄ）前記メッセージに対する受け取りアプリケーションを判断し、
（ｅ）オペレイティングシステムコールを通して前記メッセージを前記アプリケーションに送る
ステップを含むことを特徴とする方法。
【請求項１５】
前記パケットは前記ネットワーク装置内のＮＩＣにより受信されることを特徴とする請求項１４に記載の方法。
【請求項１６】
前記ステップ（ｂ）の後で、
（ｂ．１）前記パケットを形式にカテゴリ化する
ステップをさらに含むことを特徴とする請求項１５に記載の方法。
【請求項１７】
前記ステップ（ｄ）は前記パケット形式がデータである場合においてのみ実行されることを特徴とする請求項１６に記載の方法。
【請求項１８】
アプリケーションを変更することなく、クライアント装置上のアプリケーションデータ形式を判断するための方法であって、
（ａ）コールをインターセプトすることによりアプリケーション要求を受信し、
（ｂ）前記アプリケーション名、及び／又はメッセージを送信するのに用いられたポート、及び／又は前記アプリケーション要求を用いるヘッダ情報を識別することにより、前記要求から情報を取得し、
（ｃ）リアルタイム、ストリーミング、バックグラウンド、又は対話型からなる群の中で対応するタグを生成するように前記情報を用い、
（ｄ）前記アプリケーション要求と関連されたパケットにタグ付けする
ステップを含むことを特徴とする方法。
【請求項１９】
モバイル装置をアクセスポイントに登録するための方法であって、
（ａ）前記モバイル装置が前登録要求を前記アクセスポイントに送信し、
（ｂ）前記アクセスポイントがサーバから前記モバイル装置の認証を要求し、
（ｃ）前記サーバは前記モバイル装置が前記アクセスポイントにアクセスすることを認証し、
（ｄ）前記アクセスポイントが前登録表に前記モバイル装置のアドレスを記録し、
（ｅ）前記アクセスポイントが、第２アドレス、ネットワークアドレス、及び寿命を前記モバイル装置に送信する
ステップを含むことを特徴とする方法。
【請求項２０】
前記モバイル装置は、前記第２アドレス、前記ネットワークアドレス、及び前記寿命をデータベース内に格納することを特徴とする請求項１９に記載の方法。
【請求項２１】
前記アクセスポイントはアップデータ可能なファームウェアを含むことを特徴とする請求項２０に記載の方法。
【請求項２２】
信号対雑音比は、前記アクセスポイントにローミングするかどうかを判断するために前記モバイル装置により用いられることを特徴とする請求項２１記載の方法。
【請求項２３】
第１アクセスポイントから第２アクセスポイントにローミングするモバイル装置のための装置であって、
（ａ）信号対雑音比が、いつ前記第１アクセスポイントから増加し、いつ前記第２アクセスポイントから減少するかを判断し、
（ｂ）登録要求を前記第２アクセスポイントに送信し、
（ｃ）前記登録要求をアドバンスサーバに送信し、
（ｄ）前記アドバンスサーバが、前記モバイル装置に関連する宛先ＩＰを通してトラフィックの方向を前記モバイル装置に変え、
（ｅ）前記アドバンスサーバが確認を前記モバイル装置に送信し、
（ｆ）前記モバイル装置が前記確認を前記アドバンスサーバから受信した後で、前記トラフィックの方向を前記アドバンスサーバに変える
ステップを含むことを特徴とする方法。
【請求項２４】
閾値は、前記信号対雑音比が前記第２アクセスポイントから増加しなければならない時間について求められることを特徴とする請求項２３に記載の方法。
【請求項２５】
前記モバイル装置は、前記閾値が送られた後で、前記アクセスポイントに登録することを特徴とする請求項２４に記載の方法。
【請求項２６】
前記モバイル装置は、前記第２アクセスポイントに前登録することを特徴とする請求項２５に記載の方法。
【請求項２７】
ネットワークポリシーに基づいてモバイル装置を制御するための方法であって、
（ａ）前記ポリシーをアドバンスサーバ上のデータベースに格納し、
（ｂ）前記モバイル装置が前記サーバへの登録を要求したときに前記ポリシーを該モバイル装置に送信し、
（ｃ）前記モバイル装置上のアプリケーションが前記サーバによりネットワークにアクセスすることを試みたときに前記ポリシーをチェックし、
（ｄ）前記ポリシーが許可したときには、前記アプリケーションのための前記ネットワークに対するアクセスを与える
ステップを含むことを特徴とする方法。
【請求項２８】
前記ポリシーが前記データベースにおいて変更した場合には、前記変更されたポリシーは前記モバイル装置に送られることを特徴とする請求項２７に記載の方法。
【請求項２９】
前記ネットワークポリシーは複数のポリシーパラメータを含むことを特徴とする請求項２８に記載の方法。
【請求項３０】
前記ポリシーパラメータは、前記アプリケーションにより与えられるサービス形式に基づく第１パラメータを含むことを特徴とする請求項２９に記載の方法。
【請求項３１】
前記ポリシーパラメータは、許容可能な最大遅延に基づく第２パラメータを含むことを特徴とする請求項３０に記載の方法。
【請求項３２】
前記ポリシーパラメータは、前記アプリケーションの使用時間に基づく第３パラメータを含むことを特徴とする請求項３１に記載の方法。
【請求項３３】
ネットワーク上でサービス性能情報をアプリケーションのためのキャリアに与えるための方法であって、
（ａ）ネットワーク装置上のアプリケーションに関する許容できる性能閾値パラメータを格納し、
（ｂ）前記アプリケーションに関連するパケットが前記ネットワーク上でサーバに伝送されるとき、前記ネットワーク装置内で、前記パケットについての情報を維持し、
（ｃ）前記情報が前記閾値パラメータを超える場合には、アラートを生成し、前記サーバに伝送する
ステップを含むことを特徴とする方法。
【請求項３４】
前記パケットについての前記情報は、用いられるネットワークの形式を含むことを特徴とする請求項３３に記載の方法。
【請求項３５】
前記パケットについての前記情報は、前記パケットに対する信号対雑音比を含むことを特徴とする請求項３４に記載の方法。
【請求項３６】
前記パケットについての前記情報は、前記パケットを送給するのにかかった時間を含むことを特徴とする請求項３５に記載の方法。
【請求項３７】
複数のさらに別の閾値は複数の規則に基づいて計算することができ、前記情報が前記さらに別の閾値の１つを超える場合には、アラートを生成し、前記サーバに伝送することを特徴とする請求項３６に記載の方法。
【請求項３８】
ネットワーク装置からファーホストに伝送するデータパケットのためのデータ構造であって、
（ａ）前記パケットの分類に関する複数のビットと、
（ｂ）前記パケットと関連するアプリケーションのアイデンティティに関する複数のビットと、
（ｃ）前記アプリケーションにより要求される転送プロトコルに関する複数のビットと、
（ｄ）ファーホストのためのデータと
を含むことを特徴とするデータ構造。
【請求項３９】
ネットワーク装置に関連する複数のビットをさらに含むことを特徴とする請求項３８に記載のデータ構造。
【請求項４０】
前記ネットワーク装置はモバイル装置であることを特徴とする請求項３９に記載のデータ構造。
【請求項４１】
内部情報のための第１層をさらに含むことを特徴とする請求項４０に記載のデータ構造。
【請求項４２】
通信情報のための第１層をさらに含むことを特徴とする請求項４０に記載のデータ構造。
【請求項４３】
信号通知情報のための第２層をさらに含むことを特徴とする請求項４２に記載のデータ構造。
【請求項４４】
制御情報のための第２層をさらに含むことを特徴とする請求項４２に記載のデータ構造。
【請求項４５】
セッション情報のための第２層をさらに含むことを特徴とする請求項４２に記載のデータ構造。
【請求項４６】
第３層をさらに含むことを特徴とする請求項４３に記載のデータ構造。
【請求項４７】
前記データ構造は、伝送のために使用可能なネットワークに応答して動的に生成されることを特徴とする請求項３９に記載のデータ構造。
【請求項４８】
モバイル装置のためのオペレイティングシステムであって、
ａ）インテリジェントなクライアントシステム
を含み、前記クライアントシステムは、
（ｉ）ソフトウェアアプリケーションとインターフェースし、ＩＰ層と通信する上層と、
（ｉｉ）パケット形式に関する情報を含むように、前記モバイル装置により送信されるパケットを動的に修正する通信プロトコルと、
（ｉｉｉ）前記上層と通信し、入ってくる及び出て行くパケットを分類するためのパケット分類器を含む下層と
を含むことを特徴とするオペレイティングシステム。
【請求項４９】
前記下層は、信号対雑音比テラーをさらに含むことを特徴とする請求項４８に記載のオペレイティングシステム。
【請求項５０】
前記下層は、スケジューリングシステムをさらに含むことを特徴とする請求項４９に記載のオペレイティングシステム。
【請求項５１】
前記下層は、ネットワークインターフェースカートと通信することを特徴とする請求項５０に記載のオペレイティングシステム。
【請求項５２】
前記下層はネットワークステータスモニタをさらに含むことを特徴とする請求項５１に記載のオペレイティングシステム。
【国際調査報告】
2008546328.tif 000023
2008546328.tif 000024
2008546328.tif 000025