JP4784867B2 - 省電力モードで動作する無線装置に対してサービスを提供する方法及びシステム - Google Patents

Description

この出願は、３５ＵＳＣ１１９条（ｅ）に従って、米国特許商標庁において２００３年１１月１０日に提出された仮特許出願の利益を主張し、また、この仮特許出願の内容は、これを参照することにより本願に組み込まれる。

この出願は、無線通信に係り、特に、省電力性能を利用してクライアント装置にサービスを提供することに関する。

サーバ、ルータ、アクセスポイント、クライアント装置の無線ネットワークは、既存のネットワークを形成して拡張できるユーザの能力を大きく拡げてきている。また、無線ネットワークは、ユーザがネットワークに接続する際に動的に修正変更することができる。実際に、無線ネットワークによれば、クライアントは、例えばノート型パソコン又はラップトップコンピュータ、携帯端末（ＰＤＡ）、携帯電話等としての装置を、一般的にネットワークに関連付けられない離隔した場所からオフィスネットワーク及びホームネットワークに対して接続することができる。ホットスポットと称されるそのような離隔した場所により、クライアントは、地方のコーヒー店から、それら自身のネットワークにアクセスすることができる。

無線通信の爆発的な拡大を容易にし且つ異なる装置間において互換性を与えるために、ＩＥＥＥ８０２．１１ａ／ｂ／ｇ等の通信プロトコルが確立されてきた。しかしながら、これらのプロトコルは、主にデータ送信用に設計されており、総てのデータを均等に処理する。そのような均等な処理は、送信されたデータがテキストデータ、ビデオ、音声又は電話の混合を含んでいる場合、サービスプロバイダによる既知のサービス品質（ＱｏＳ）の保証を妨げる。ビデオデータを適時に配信できないと、例えば、使用できない画像を分離する動作にエラーが生じる虞がある。そのため、異なるタイプのデータのための送信優先順位を定めるＩＥＥＥ８０２．１１ｅ規格が提案された。一つの態様において、優先順位は、単にデータのタイプに基づいて定められる。他の態様においては、指定のＱｏＳを保証するために、特定のデータタイプに対してパラメータが割り当てられ得る。

ネットワーククライアント装置の重要な態様は、これらがバッテリ動作されるということである。従って、これらの装置の多くは、電力の節約を望み、省電力モードで動作する。このモードにおいて、クライアント装置は、給電がなされず、そのため、送信が必要とされる場合、ルータ、サーバ又はアクセスポイントで動作するサービスプロバイダからデータを受け取ることができない。むしろ、クライアント装置は、サービスプロバイダが所定の時間、即ち、スケジュールされた時間にサービスを提供すること、又は、オンデマンド、即ち、スケジュールされていない時間にサービスを提供することを要求するかもしれない。しかしながら、より多くの装置がネットワークに入ってネットワークからサービスを要求するため、一つ又は複数のネットワーク構成要素内において、即ち、サーバ、ルータ、アクセスポイント等において、個々の装置の要求（需要）が競合する可能性があり、又は、ネットワークが受け入れることができない要求が存在する場合がある。

従って、産業界においては、クライアント装置のサービス要求を処理するための方法及びシステムであって、そのような要求によって生じ得る競合を回避し及び／又は解決できる方法及びシステムに対する需要が存在する。

省電力クライアント装置に対してサービスを提供するべき時期を決定するネットワーク構成要素のための方法及びシステムが開示される。当該方法は、クライアント装置から要求されたサービス方法を受け取るステップと、要求されたサービス方法に適応するための能力を決定するステップと、要求されたサービス方法に適応するための能力の表示をクライアント装置に対して与えるステップとを含んでいる。本発明の一つの態様において、適応するための能力は、要求されたサービス方法、提案されたスケジュール、ネットワーク構成要素での現在の需要、ネットワーク構成要素の現在の動作状態、からなるグループから選択される少なくとも一つの因子（ファクタ）に基づいている。

図面は、単に本発明の概念を示すだけのものであり、本発明を限定しようとするものではないことは言うまでもない。図面に示され且つ付随の詳細な説明に記載された実施の形態は、例示的な実施の形態として使用されるべきであり、本発明を実行する唯一の態様として解釈されるべきではない。また、適切な場合には、参照文字で補足される同一の参照番号は、同様の要素を特定するために使用されている。

図１は、従来型無線ネットワーク１００を示しており、この無線ネットワーク１００により、無線装置１１０は、サーバ、ルータ又はアクセスポイント（ＡＰ）１２０を介して、データを例えばインターネット等の通信ネットワーク１３０に対して受信又は送信することができる。また、ＡＰ１２０により、ケーブル１４５を介して接続された装置１４０がデータをネットワーク１３０及び／又は装置１１０に対して送受信できてもよい。また、図示のように、ネットワーク１３０はサーバ１５０と通信しており、このサーバ１５０は、第２のネットワーク１６０と通信を行ってもよい。第２のネットワーク１６０及びネットワーク１３０は同一のネットワークであってもよく又は異なるネットワークであってもよいことは言うまでもない。この実施の形態において、ネットワーク１３０は、ローカルホットスポットに関連するネットワークであってもよく、また、ネットワーク１６０は、許可されたユーザによるアクセスだけを可能にする企業ネットワーク又はホームネットワークであってもよい。

破線により示される装置１１０．１は、ＡＰ１２０を介してネットワーク１３０に対して動的に接続されるクライアント装置を表している。この場合、ＡＰ１２０は、装置１１０．１の追加を認識するとともに、既に接続された装置１１０，１４０により課される既存の負荷を考慮して装置１１０．１のサービス要求に適応しなければならない。

図２Ａは、提案されたＩＥＥＥ８０２．１１ｅ ＭＡＣ層データフォーマットを示している。図２Ｂは、ＭＡＣ層のフレーム制御フィールドのフォーマットを示している。図２Ｂに示されるフレーム制御フィールドは、タイプ用に２ビット２１０及びサブタイプ用に４ビット２１１を含んでおり、これらは次のフレームがＭＡＣ層データ、管理又は制御フォーマットを有しているかどうかを規定する。また、図２Ｂは、クライアント装置のパワー管理モードを示すために使用されるパワー管理フィールドも含んでいる。一つのモードにおいて、パワー管理フィールド中の値「１」は、クライアント装置が常にアクティブモードにあることを示している。

図２Ｃは、管理フレームフォーマットのタイプを規定した２バイトフレーム制御フィールドを含む提案されたＭＡＣ層管理フレームフォーマットを示している。例えば、管理フレームフォーマットは、要求（アソシエーション、プローブ、アクション、追加ＴＳアクション、ブロック認識）及び応答（アソシエーション、プローブ、アクション、追加ＴＳアクション、ブロック認識）等であってもよい。アクション要求内には、ＱｏＳ、ＤＬＰ、ブロック認識アクションが存在する。また、ＱｏＳアクション要求とともに、「追加トラフィック仕様」（ＡｄｄＴＳ）のためのサブ要求及びＡｄｄＴＳ要求への応答も存在する。要求ＡｄｄＴＳへの応答は、要求された動作の成功又は失敗を示すために応答管理フレームが使用される状態コード固定フィールドを含んでいる。図２Ｄは、２バイト状態コードフィールドを示している。状態コードフィールドの一例が表１に示されている。

表１ 典型的な状態コードフィールド定義
３２ 不特定のＱｏＳ関連の失敗
３３ 他のＱＳＴＡを処理するには不十分な帯域幅を有するＱＡＰに起因して
拒否されたアソシエーション
３４ 過度なフレーム損失率及び／又は現在の動作チャンネルに関する劣悪な
条件に起因して拒否されたアソシエーション
３５ ＱｏＳ機能をサポートしない要求局に起因して
拒否されたアソシエーション（ＱＢＳＳを伴う）
３７ 要求が拒否された
３８ 一つ又は複数のパラメータが無効な値を有していたために
要求が成功しなかった
３９ 要求を受け入れることができなかったためにＴＳが形成されなかった。
しかしながら、推奨ＴＥＰＥＣが与えられることにより、
開始ＱＳＴＡは、ＴＳＰＥＣへの推奨された変更と共に、
他のＴＳを設定することを試み得る。
４０ ＴＳが形成されなかった。しかしながら、ＴＳ遅延素子において示された
時間後に、要求に応じてＨＣがＴＳを形成し得る。
４１ 方針により直接リンクがＢＳＳにおいて許可されない
４２ このＱＢＢＳ内に送信先ＳＴＡが存在しない
４３ 送信先ＳＴＡがＱＳＴＡではない

図３Ａは、クライアント装置とネットワークアクセスポイントとの間の通信をセットアップするために使用されるトラフィック仕様フォーマットを示している。図３Ｂは、図３Ａに示されるトラフィック仕様フォーマット内のＴＳ情報フィールドのフォーマットを示している。図示のように、ＴＳ情報フィールドは、自動省電力配信（ＡＰＳＤ）フィールド及びスケジュールフィールドを含んでいる。ＡＰＳＤフィールドは、設定されると、クライアント装置が省電力モードで動作していることをＡＰに知らせ、また、スケジュールフィールドは、設定されると、提案されたスケジュールに基づいてサービスが提供されることをクライアント装置が要求していることをＡＰに知らせる。このようにして、クライアント装置は、要求されたサービスの予期された送信の直前に省電力モードから呼び起こされ得る。図３Ｃは、提案されたスケジュールのためのフォーマットを示している。

図４は、クライアント装置からのサービス要求を本発明の原理に従って処理するための典型的な処理手続き４００のフローチャートを示している。この図示されたプロセスにおいて、サービス要求は、ブロック４１０において受け取られる。ブロック４２０においては、要求されたサービスがスケジュールに基づいて提供されるべきかどうかの決定がなされる。本発明の一つの態様において、スケジュールに基づくサービスは、図３Ｂに示される「スケジュールビット」を設定することにより要求され得る。応答が否定的である場合には、ブロック４３０において、サービスプロバイダがスケジュールされていない即ち「予定外の」要求を受け入れることができるかどうかの決定がなされる。応答が肯定的である場合には、ブロック４３５において、要求されたサービスに適応することができるという表示が、要求しているクライアント装置に戻される。一つの態様において、この表示は、図３Ｂに示される「スケジュールビット」を第１の論理値、例えば０の値に設定することを含んでいてもよい。

しかしながら、応答が否定的である場合には、ブロック４４０において、要求しているクライアント装置に対してサービスを提供するためのスケジュールが決定される。与えられるスケジュールは、現在の動作需要（動作デマンド）及び見込まれる動作需要、負荷、処理能力に基づいていてもよい。その後、ブロック４５０において、変更と共にサービスが適応されるという表示が、要求しているクライアント装置に戻される。一つの態様において、この表示は、図３Ｂに示される「スケジュールビット」を第２の論理値、例えば１の値に設定することを含んでいてもよい。また、決定されたスケジュールも、要求しているクライアント装置に対して与えられる。

ブロック４２０における決定に戻ると、応答が肯定的である場合には、ブロック４６０において、サービスプロバーダは要求されたスケジュールを再検討する。ブロック４６５において、サービスプロバイダは提案されたスケジュールを修正してもよい。提案されたスケジュールの修正は、既存のスケジュールとの不一致、局の負荷、現在の需要（デマンド）、現在の負荷、見込まれる需要、見込まれる負荷及び／又は他の処理検討材料等の因子（ファクタ）に基づいて必要となる場合がある。

ブロック４７０においては、要求されたサービスが適応され又は変更と共に適応されるという表示が、要求しているクライアント装置に対して戻される。一つの態様において、この表示は、図３Ｂに示される「スケジュールビット」を第２の論理値、例えば１の値に設定することを含んでいてもよい。また、クライアント装置によって提案され若しくは要求されたかどうか、又は、例えばＡＰ１２０等のネットワークの構成要素によって修正されたかどうかにかかわらず、決定されたスケジュールも、要求しているクライアント装置に対して与えられる。

図５は、図４に示された処理手続きの第２の態様５００のフローチャートを示している。本発明のこの図示された態様では、スケジュールされたサービスの要求が受け取られたことをブロック４２０において決定した後、ブロック５１０において、ネットワークの方針及び／又はネットワーク条件（状態）が要求を受け入れることができるかどうかの決定がなされる。応答が肯定的である場合には、処理手続きが移行し、図４のブロック４６０，４６５，４７０での処理に関して説明したように、提案されたスケジュールが再検討されるとともに必要に応じて修正され、スケジュールされたサービスの表示が送信される。

しかしながら、応答が否定的である場合には、ブロック５３０において、サービスの要求が拒否されたという表示が、要求している装置に対して与えられる。サービスは、例えば、ＡＰ１２０がオンデマンドモードだけで動作し且つスケジュールを準備する用意ができていない場合に拒否されてもよい。図示しないが、クライアントが提案したスケジュールの再検討がブロック５１０での決定前に行われてもよく、また、ＡＰ１２０における現在の需要及び負荷要件を考慮して提案されたスケジュールに適応することができない場合にサービスの拒否が生じてもよいことは言うまでもない。

図６は、本発明の第３の態様６００のフローチャートを示している。この態様では、要求されたサービスが予定外のサービスであることがブロック４２０において決定されると、ブロック４３０において、要求されたサービスをＡＰ１２０（サービスプロバイダ）が受け入れることができるかどうかの決定がなされる。応答が肯定的である場合には、処理ブロック４３５（図４参照）に関して既に説明したように、要求している装置に対して所定の表示が与えられる。

しかしながら、ブロック４３０での応答が否定的である場合には、ブロック６３０において、ネットワークの方針及び／又はネットワーク状態が要求を受け入れることができるかどうかの決定がなされる。応答が肯定的である場合には、図４に示される処理ブロック４４０，４５０に関して既に説明したように、スケジュールがセットアップされるとともに、要求している装置に対して所定の表示が与えられる。

しかしながら、応答が否定的である場合には、ブロック５３０において、要求されたサービスが拒否されるという表示が、要求している装置に対して与えられる。

本発明の一つの態様において、ＩＥＥＥ８０２．１１ｅ通信プロトコルを使用して通信する要求しているクライアント装置に対して与えられた表示は、例えば、図２に示されるデータ項目の組み合わせとして形成されてもよい。例えば、表示が表２に示されるように定式化されてもよい。

表２ 提案された表示構成
動作 状態コード ＡＰＳＤ スケジュールビット
要求されたスケジュール ００ １ ０ 適応
されていないサービス
要求されたスケジュール ００ １ １ 適応
されているサービス
要求されたスケジュール ００ １ １ 変更と共に適応
されていないサービス
要求されたスケジュール ００ １ １ 変更と共に適応
されているサービス
要求されたスケジュール ３７ Ｘ Ｘ 拒否
されていないサービス
要求されたスケジュール ３７ Ｘ Ｘ 拒否
されているサービス
Ｘ＝配慮せず

図７は、本発明の原理を実行するために使用され得るシステム７００の典型的な実施の形態を示している。システム７００は、一つ又は複数の入力／出力装置７０２と、プロセッサ７０３と、メモリ７０４とを有し得る。Ｉ／Ｏ装置７０２は、プロセッサ７０３からサービスを要求する一つ又は複数のソース７０１にアクセスしてもよく、又は、当該ソース７０１から情報を受け取ってもよい。クライアント装置７０１は、テレビシステム、コンピュータ、ノート型パソコン、ＰＤＡ、携帯電話又は他の携帯機器等の装置であり得る。装置７０１は、例えば無線広域ネットワーク、無線メトロポリタンエリアネットワーク、無線ローカルエリアネットワーク、地上放送システム（ラジオ、ＴＶ）、衛星ネットワーク、携帯電話若しくは無線電話ネットワーク、又は、これらのタイプ及び他のタイプのネットワークの一部若しくは組み合わせを介して、一つ若しくは複数のネットワーク接続７５０を経由してアクセスを要求し得る。

入力／出力装置７０２、プロセッサ７０３、メモリ７０４は、通信媒体７２５を介して通信してもよい。通信媒体７２５は、例えばバス、通信ネットワーク、回路、回路カード又は他の装置の一つ若しくは複数の内部接続、これらの通信媒体又は他の通信媒体の一部若しくは組み合わせを表してもよい。クライアント装置７０１からの入力データ要求は、メモリ７０４に記憶され且つプロセッサ７０３により実行され得る一つ又は複数のプログラムに従って処理される。プロセッサ７０３は、例えば汎用コンピュータシステム若しくは専用コンピュータシステム等の任意の手段であってもよく、又は、ラップトップコンピュータ、デスクトップコンピュータ、サーバ、ハンドヘルドコンピュータ、専用論理回路若しくは集積回路等のハードウェア構造であってもよい。また、プロセッサ７０３は、既知の入力に応じて既知の出力を供給するソフトウェア命令を含むようにハードウェア「プログラムされ」得るプログラマブルアレイロジック（ＰＡＬ）、特定用途向け集積回路（ＡＳＩＣ）等であってもよい。一つの態様において、ハードウェア回路は、本発明を実行するためのソフトウェア命令の代わりに又は当該命令と組み合わせて使用され得る。また、ここに図示された要素は、コード化された論理演算を使用して又はハードウェア実行可能コードを実行することにより図示の演算を行うようになっている別個のハードウェア要素として実施されてもよい。

一つの態様において、本発明の原理は、プロセッサ７０３により実行されるコンピュータ可読コードによって実施されてもよい。このコードは、メモリ７０４に記憶されてもよく、又は、メモリ媒体７８３、Ｉ／Ｏ装置７８５、若しくは、フロッピーディスク、ＣＤ−ＲＯＭ、ＤＶＤ等の磁気媒体や光媒体から読み取られ／ダウンロードされてもよい。

また、ここに示された機能を果たすようになっている一つ又は複数のソフトウェアプログラムに従った処理後にＩ／Ｏ装置７０２によって受け取られた装置７０１からの要求は、ネットワーク７７０を介して、ディスプレイ７８０、報告装置７９０又は第２の処理システム７９５として表される一つ又は複数の出力装置に対して送信されてもよい。図４乃至図６に関して説明したように、要求されたサービスに応答する表示は、要求している装置に対して戻される。戻された表示は、典型的にはネットワーク６３０を介して供給されるが、他の通信媒体（図示せず）によって供給されてもよい。

当業者であれば分かるように、コンピュータ又はコンピュータシステムなる用語は、一つ又は複数のメモリユニットと通信する一つ又は複数の処理ユニットや、例えば少なくとも一つの処理ユニットに電子的に接続され且つ当該処理ユニットと通信を行う周辺機器等の他の装置を表してもよい。また、装置は、内部バス、例えばＩＳＡバス、マイクロチャンネルバス、ＰＣＩバス、ＰＣＭＣＩＡバス等を介して、又は、回路、回路カード若しくは他の装置の一つ若しくは複数の内部接続により、及び、これらの通信媒体若しくは他の通信媒体の一部及び組み合わせ、又は、インターネットやイントラネット等の外部ネットワークを介して、一つ又は複数の処理ユニットに対して電子的に接続されてもよい。

本発明の好ましい実施の形態に適用される本発明の基本的な新規の特徴を図示して、説明し、指摘してきたが、本発明の思想から逸脱することなく、説明した機器において、開示された装置の形態及び詳細において、それらの動作において、当業者が様々な省略、置換、変更を行うことができることは言うまでもない。実質的に同じ方法で略同一の機能を実行して同じ結果を達成する要素の総ての組み合わせが本発明の範囲内に入ることが明らかに意図されている。説明した一つの実施の形態から他の実施の形態への要素の置き換えも総て意図されており、また、考えられる。

従来の無線通信システムを示している。 提案されたＩＥＥＥ８０２．１１ｅ規格におけるＭＡＣ層フォーマットを示している。 提案されたＩＥＥＥ８０２．１１ｅ規格におけるＭＡＣ層フォーマットを示している。 提案されたＩＥＥＥ８０２．１１ｅ規格におけるＭＡＣ層フォーマットを示している。 提案されたＩＥＥＥ８０２．１１ｅ規格におけるＭＡＣ層フォーマットを示している。 要求装置とネットワーク構成要素との間のトラフィック仕様要素フォーマットを示している。 要求装置とネットワーク構成要素との間のトラフィック仕様要素フォーマットを示している。 要求装置とネットワーク構成要素との間のトラフィック仕様要素フォーマットを示している。 省電力モードで動作するクライアント装置に対してサービスを提供するための本発明の第１の態様に係るフローチャートを示している。 省電力モードで動作するクライアント装置に対してサービスを提供するための本発明の第２の態様に係るフローチャートを示している。 省電力モードで動作するクライアント装置に対してサービスを提供するための本発明の第２の態様に係るフローチャートを示している。 ここに示された処理を実行するためのシステムを示している。

Claims (21)

1. 無線ネットワークにおいて省電力モードで動作するクライアント装置に対してサービスを提供すべき時期をネットワーク構成要素において決定する方法であって、
   前記クライアント装置からサービス要求信号を受け取るステップと、
   前記サービス要求信号に適応するための能力を決定するステップと、
   前記サービス要求信号に適応するための能力の表示を前記クライアント装置に対して与えるステップと、を含み、
   前記能力を決定するステップは、前記サービス要求信号がスケジュールに基づいて提供されたものか否かを判定し、前記スケジュールは、トラフィック仕様フォーマットのスケジュールフィールド内のスケジュールビットの設定により決められることを特徴とする方法。
2. 前記サービス要求信号は、スケジュールに基づいて提供されるものであることを特徴とする請求項１に記載の方法。
3. 前記スケジュールされたサービス要求信号は、提案されたサービススケジュールを含んでいることを特徴とする請求項２に記載の方法。
4. 前記提案されたサービススケジュールを修正するステップを更に含んでいることを特徴とする請求項３に記載の方法。
5. 前記修正されたサービススケジュールを前記クライアント装置に対して提供するステップを更に含んでいることを特徴とする請求項４に記載の方法。
6. 前記表示は、拒否、変更と共に適応、適応、からなるグループから選択されることを特徴とする請求項１に記載の方法。
7. 適応するための能力を決定する前記ステップは、要求されたサービス方法、提案されたスケジュール、ネットワーク動作状態、ネットワークの方針、ネットワーク状態、からなるグループから選択される少なくとも一つの因子に基づいていることを特徴とする請求項１に記載の方法。
8. 無線ネットワークにおいて省電力モードで動作するクライアント装置に対してサービスを提供すべき時期をネットワーク構成要素において決定する装置であって、
   メモリと、
   前記メモリと通信するプロセッサと、を備え、
   前記プロセッサは、
   前記クライアント装置からサービス要求信号を受け取り、
   前記サービス要求信号に適応するための能力を決定し、
   前記サービス要求信号に適応するための能力の表示を前記クライアント装置に対して与える、ためのコードを実行可能であり、
   前記能力の決定では、トラフィック仕様フォーマットのスケジュールフィールド内のスケジュールビットの設定に基づいて、スケジュールにより、あるいはスケジュールによらずに、前記サービス要求信号が提供されるか否かを決定することを特徴とする装置。
9. 前記サービス要求信号は、スケジュールに基づいて提供されるものであることを特徴とする請求項８に記載の装置。
10. 前記スケジュールされたサービス要求信号は、提案されたサービススケジュールを含んでいることを特徴とする請求項９に記載の装置。
11. 前記プロセッサは、前記提案されたサービススケジュールを修正するためのコードを更に実行可能であることを特徴とする請求項１０に記載の装置。
12. 前記プロセッサは、前記修正されたサービススケジュールを前記クライアント装置に対して与えるためのコードを更に実行可能であることを特徴とする請求項１１に記載の装置。
13. 前記表示は、拒否、変更と共に適応、適応、からなるグループから選択されることを特徴とする請求項８に記載の装置。
14. 要求されたサービス方法、提案されたスケジュール、ネットワーク動作状態、ネットワークの方針、ネットワーク状態、からなるグループから選択される少なくとも一つの因子に基づいて、適応するための前記能力を決定するためのコードを、プロセッサにて実行可能にしたことを特徴とする請求項１に記載の方法。
15. 前記ネットワークと前記プロセッサとの間のインタフェースとして動作可能なＩ／Ｏ装置を更に備えていることを特徴とする請求項８に記載の装置。
16. 前記コードが前記メモリ内に記憶されることを特徴とする請求項８に記載の装置。
17. 前記サービス要求信号を受け取るための受信装置と、
    少なくとも前記表示を前記クライアント装置に対して与えるための送信装置と、を更に備えていることを特徴とする請求項８に記載の装置。
18. ネットワーク構成要素内のプロセッサであって、クライアント装置から受け取るサービス要求信号を受け入れるための前記ネットワーク構成要素の能力を決定するプロセッサにおいて、
    前記ネットワーク構成要素の動作状態を調べ、
    前記サービス要求信号を調べ、
    前記動作状態と前記サービス要求信号とが対応しているときには、必要に応じて修正しながら、前記サービス要求信号に適応し、
    前記適応の表示を前記クライアント装置に対して与える、ためのコードを実行するものであり、
    前記サービス要求信号を調べる際には、トラフィック仕様フォーマットのスケジュールフィールド内のスケジュールビットの設定に基づいて、スケジュールにより、あるいはスケジュールによらずに、前記サービス要求信号が提供されるか否かを決定することを特徴とするプロセッサ。
19. 前記動作状態と前記サービス要求信号とが対応していないときには、前記サービス要求信号を拒否する表示を与えるためのコードを更に実行することを特徴とする請求項１８に記載のプロセッサ。
20. 前記動作状態は、処理負荷、需要、見込まれる処理負荷、見込まれる需要、ネットワーク構成要素の動作状態、ネットワーク構成要素の方針、ネットワーク構成要素の状態、からなるグループから選択されることを特徴とする請求項１８に記載のプロセッサ。
21. 前記サービス要求信号は、スケジュールされたサービスのための要求信号であることを特徴とする請求項１８に記載のプロセッサ。

Images