JP2014512748A

JP2014512748A - リソースをリクエストする方法と、サイト及びセンター・アクセスポイント

Info

Publication number: JP2014512748A
Application number: JP2014501420A
Authority: JP
Inventors: ドンシャンバオ; ユーバオジョウ; シャオヤンユー; フイジュエンヤオ; ジーガンヤン; シェンファリウ
Original assignee: Beijing Nufront Mobile Multimedia Technology Co Ltd
Current assignee: Beijing Nufront Mobile Multimedia Technology Co Ltd
Priority date: 2011-03-31
Filing date: 2012-03-23
Publication date: 2014-05-22
Anticipated expiration: 2032-03-23
Also published as: US20140112264A1; KR101910219B1; CN103444249A; WO2012130097A1; JP6105550B2; KR20140034178A; EP2693818A4; CN102781102A; EP2693818A1

Abstract

本発明はリソースをリクエストする方法と、サイトとセンター及びアクセスポイントを提供する。当該方法が次の構成を含む。リソース伝送リクエストをデータフレームに載せ、前記リソース伝送リクエストをキャリーするデータフレームを送信する。当該方法はアップリンクデータに必要なリソースを取得するためのソリューションを提供する。

Description

本発明は、無線通信分野に属し、特にリソースをリクエストする方法及びその装置に関するものである。

近年来、無線通信システムは盛んに発展しており、例えば８０２．１１規格に準じる無線ＬＡＮ技術ＷｉＦｉや、８０２．１５規格に準じるブルートゥース(Ｂｌｕｅｔｏｏｔｈ（登録商標）)システム及び移動通信システムによって発展された室内のアプリケーションに向けるＦｅｍｔｏ技術等が広くアプリケーションされている。

８０２．１１規格に準じるＷｉＦｉ技術は、現在に、一番広く使用されている無線ネットワーク伝送技術である。ＷｉＦｉシステムは搬送波感知多重アクセス／衝突回避(ＣＳＭＡ／ＣＡ、Carrier Sense Multiple Access with Collision Avoidance)方式を採用しているので、システムは効率が低く、無線リソースが大幅に無駄になる。この問題を招く根本的な原因は、ＣＳＭＡ／ＣＡ方式が競争に基づくランダム多重アクセス方式であり、センターアクセスポイント(ＣＡＰ、Access Point)とステーション(ＳＴＡ、Station)の間、又は異なるＳＴＡ同士の間は、ＣＳＭＡ／ＣＡ方式により無線リソースの使用権を競争するとともに、無線チャンネルを競争する。この場合、衝突が発生し、無線リソースの無駄を招く。衝突を回避するために、ＣＳＭＡ／ＣＡ方式においては、ＣＡＰ又はＳＴＡが無線チャンネルを競争する時に、ランダムに退避することが要求されており、全部のＣＡＰ及びＳＴＡがいずれも退避した場合、無線チャンネルは空いているが、使用されていない。これも無線チャンネルに対する巨大な無駄である。上記原因により、８０２．１１システムは効率が低い。例えば、８０２．１１ｇシステムでは物理層におけるピークレートは５４Ｍｂｐｓに到達できるが、ＴＣＰ層における大容量パケットのダウンロードレートが３０Ｍｂｐｓ以下である。上記欠陥が存在しているが、８０２．１１システムは柔軟性があり、集中コントロール方式によらず、装置のコストダウンを図ることができる。

３ＧＰＰ規格に準じるＦｅｍｔｏ技術は、移動通信システムから発展された室内向けの新規技術である。３Ｇシステムのデータ統計によれば、略７０％のデータ業務は室内に行われるので、室内ハイレートデータアクセス方案は特に重要である。Ｆｅｍｔｏ基地局は、超小型基地局と称され、体積が小さくて(Ｗｉ−Ｆｉと相当)、設置の融通性がよい。移動通信システムから発展されたので、Ｆｅｍｔｏ基地局はほとんど移動通信システムの全部の特徴を継続している。Ｆｅｍｔｏ装置は、制限されたカバー範囲や少ないアクセスユーザーなどのアプリケーションシーン特徴に合わせて、装置処理能力を低減して装置コストを低減させる。デュプレックスモードから考慮すると、移動通信システムと同様に、Ｆｅｍｔｏ基地局はＦＤＤとＴＤＤの２種類のデュプレックスモードに分けられる。ＦＤＤでは、アップ・ダウンリンク搬送波リソースが対称するが、データ業務におけるアップ・ダウンリンクデータ通信量の非対称業務特徴により、ＦＤＤシステムがデータ業務に際してある程度のリソースの無駄が存在している。ＴＤＤシステムではアップ・ダウンリンクリンクが同一搬送波で作業し、時リソースを分けることにより、アップ・ダウンリンクに異なる無線リソースを割当てるので、ＦＤＤよりもアップ・ダウンリンク業務が必要な非対称のデータ業務に好適適用できる。しかしながら、移動通信システム(Ｆｅｍｔｏシステムを含む)のＴＤＤデュプレックスモードでは、アップ・ダウンリンクリソースが静的に割当てられ、要望の異なる各種類のデータ業務、例えば、ウェブページの閲覧、移動ビデオ、移動ゲーム等に対して、業務要望とリソース配分の動的アダプテーションが実現することが困難である。Ｗｉ−Ｆｉと比較すると、Ｆｅｍｔｏが調達に基づく集中コントロール方式を採用し、基地局又はＣＡＰと端末、あるいは端末同士の間には、競争衝突及びランダム退避による無線リソースの無駄が存在しないので、リンク効率が高い。

無線通信システムに対して、無線ネットワークにアクセスする必要がある。

本発明が解決しようとする課題は、リソースをリクエストする方法、サイトとセンター・アクセスポイントを提供することにより、データをアップリンクするための必要なリソースをリクエストすることに用いられるものである。

上記の技術的課題を解決するために、本発明は、
リソースをリクエストする方法を提供し、チャネル連携リクエストでリソース伝送をリクエストすることを発起し、下記のステップを含む。
リソース伝送リクエストをデータフレームの中にキャリーし、
リソース伝送リクエストをキャリーする前記データフレームを送信する。

上記の技術的課題を解決するために、本発明は、
リソースをリクエストする方法を提供し、チャネル連携リクエストでリソース伝送をリクエストすることを発起し、下記のステップを含む。
リソース伝送リクエストをキャリーするデータフレームを受信し、
前記データフレームの中から前記リソース伝送リクエストを解析し、
前記リソース伝送リクエストに応じて、対応のサイトSTAのために伝送リソースをアロケートし、
リソース伝送リクエスト応答をSTAに送信し、
前記リソース伝送リクエスト応答の中にがリソース伝送の指示がキャリーされる。

上記の技術的課題を解決するために、本発明は、
リソースリクエストに用いられるサイトSTAを提供し、チャネル連携リクエストでリソース伝送をリクエストすることを発起し、下記の構成を含む。

パッケージモジュールは、リソース伝送リクエストをデータフレームの中に載せることに用いられているものであり、
第1送信モジュールは、リソース伝送リクエストをキャリーするデータフレームを送信することに用いられているものである。

上記の技術的課題を解決するために、本発明は、
受信モジュールは、リソース伝送リクエストをキャリーするデータフレームを受信することに用いられているものであり、
解析モジュールは、前記データフレーム中からリソース伝送リクエストを解析することに用いられているものであり、
リソースアロケートモジュールは、前記リソース伝送リクエストに基づき、対応のSTAのために伝送リソースをアロケートすることに用いられているものであり、
送信モジュールは、リソース伝送リクエスト応答を対応のSTAに送信することに用いられているもので、前記リソース伝送リクエスト応答の中にはリソース伝送の指示がキャリーされる。

本発明で提供するリソースをリクエストする方法と、サイト及びセンター・アクセスポイントは、データのアップリンクに必要なリソースを取得することに用いられるものである。

本願は、出願日が２０１１年３月３１日、出願番号が２０１１１００８１２８８．６、発明の名称が『無線通信方法』である中国特許出願の優先権を主張するものであり、当該先行出願の全部内容は本願に表される。

本願は、出願日が２０１１年５月１９日、出願番号が２０１１１０１３０１９４．３、発明の名称が『通信システム』である中国特許出願の優先権を主張するものであり、当該先行出願の全部内容は本願に表される。

本願は、出願日が２０１１年７月６日、出願番号が２０１１１０１８８５９４．X、発明の名称が『リソースリクエストの方法、装置及びシステム』である中国特許出願の優先権を主張するものであり、当該先行出願の全部内容は本願に表される。

本願は、出願日が２０１２年２月８日、出願番号が２０１２１００２７８９８．２、発明の名称が『リソースリクエストの方法及び装置』である中国特許出願の優先権を主張するものであり、当該先行出願の全部内容は本願に表される。

本願は、出願日が２０１２年２月２１日、出願番号が２０１２１００４１６２８．７、発明の名称が『リソースリクエストの方法、サイト及びセンター・アクセスポイント』である中国特許出願の優先権を主張するものであり、当該先行出願の全部内容は本願に表される。

本発明の実施例1におけるリソースをリクエストする方法を示すフローチャートである。本発明の実施例におけるスケジューリング・リクエスト・シーケンスをジェネレートする方法を示す図である。本発明の実施例におけるPNシーケンスの原理を示す図である。本発明の実施例における独立リソース・リクエストフレームの構造を示す図である。本発明の実施例１における競争方式でリソースをリクエストする方法を実現するためのSTA装置のブロック図である。本発明の実施例１における競争方式でリソースをリクエストする方法を実現するためのCAP装置のブロック図である。本発明の実施例２におけるチャンネル連携でリソース伝送リクエスト方法を示すフローチャートである。本発明の実施例２におけるチャンネル連携でリソース伝送リクエスト方法を実現するためのSTA装置のブロック図である。本発明の実施例２におけるチャンネル連携でリソース伝送リクエスト方法を実現するためのCAP装置のブロック図である。本発明の実施例３におけるポーリングでリソース伝送リクエスト方法を示すフローチャートである。本発明の実施例３におけるポーリングでリソース伝送リクエスト方法を実現するためのCAP装置のブロック図である。本発明の実施例４におけるポーリングでリソース伝送リクエスト方法を示すフローチャートである。本発明の実施例４におけるポーリングでリソース伝送リクエスト方法を実現するためのCAP装置のブロック図である。本発明の実施例５におけるポーリングでリソース伝送リクエスト方法を示すフローチャートである。本発明の実施例５におけるポーリングでリソース伝送リクエスト方法を実現するためのCAP装置のブロック図である。本発明の実施例６におけるポーリングでリソース伝送リクエスト方法を示すフローチャートである。本発明の実施例６におけるポーリングでリソース伝送リクエスト方法を実現するためのCAP装置のブロック図である。

当業者が本発明の具体的な実施方式を実施できるように、以下の記述及び図面はそれらを十分に示している。その他の実施方式は構成、論理、電気、過程及びその他の変更を含むことができる。実施例は可能な変更のみを代表している。明確な要求を除いて、単独な部品及び機能は選択でき、且つ操作の順は変更できる。一部の実施案の部分及び特徴はその他の実施案の部分及び特徴に含まれる、又は交替される。本発明の実施案の範囲は、特許請求の範囲の全部範囲、及び特許請求の範囲の全ての取得できる等同物を含む。本文において、本発明のこれらの実施案は、単独的又は総括的に『発明』という用語により表される。これは、便利にするために過ぎない。そして、事実上、１個以上の発明が公開されても、該応用の範囲が任意の単独な発明又は発明構想に自動的に規制するものではない。

実施例1
実施例1に関わる本発明は、リソースをリクエストする方法を提供し、データアップリンクするサイト(Station、略称STA)が自発的にセンター・アクセスポイント（Central Access Point 、略称CAP）へリソース伝送をリクエストすることにより、競合方式でアップリンクリソースを取得する。そのうち、CAPがアクセスしたSTAにアクセスサービスを提供する実体であり、STAがメディア・アクセス・コントロール(MAC)と物理層（PHY）機能インターフェイスを有するCAPと通信可能な端末装置である。本発明の実施例におけるリクエスト方法は、図1に示すように、下記のステップを含む。

ステップS101：STAは、第1リソース伝送リクエストを送信する。
ステップS102：CAPは、前記第1リソース伝送リクエストを受信し、前記STAに第1伝送リソースをアロケートする。
ステップS103：前記CAPが前記STAに第1リソース伝送リクエスト応答を送信し、前記第1リソース伝送リクエスト応答の中には第1リソース伝送指示がキャリーされる。
ステップS104：前記STAは前記第1リソース伝送リクエスト応答を受信する。
ステップS105：前記STAは前記第1リソース伝送リクエストを用いて第2リソース伝送リクエストを送信する。
ステップS106：前記CAPは第2リソース伝送リクエストを受信し、前記STAに第2伝送リソースをアロケートする。
ステップS107：前記CAPは第2リソース伝送リクエスト応答を前記STAに送信し、前記第2リソース伝送リクエスト応答の中には第2リソース伝送指示がキャリーされる。
ステップS108：前記STAは前記第2リソース伝送リクエスト応答を受信する。
ステップS109：前記STAは第2伝送リソースを用いてデータを送信する。

本発明の実施例における上記のリソースをリクエストする方法は、STAから自発的にCAPへリソース伝送リクエストを送信し、二回のインタラクティブにより、即ち、第1リソース伝送リクエストを送信し、リソースリクエストのプロセスを有効にし、第1伝送リソースをリクエストしてから、第1リソース伝送を用いて第2リソース伝送リクエストを送信し、データのアップリンクに用いられる第2伝送リソースをリクエストすることにより、リソース伝送リクエストの全プロセスが完成し、データアップリンクに必要なリソースを取得する。

好ましくは、前記第1リソース伝送リクエストはアップリンク・スケジューリング方式で発起できる。当然なら、ほかの実施例では、前記第1リソース伝送リクエストも別途に発起できる。例えば、フリー状態にあるアップリンク伝送リソースを活用して発起するか、またはアップリンクデータフレームの中にキャリーされてデータフレームと一緒に発送することで発起するなどことが望まれている。本発明はここで制限されるものではない。次に、本発明の実施例におけるスケジューリング方式で第1リソース伝送リクエストを発起する方式について更に詳しく説明する。

前記第1リソース伝送リクエストは、具体的に、スケジューリング・リクエスト・シーケンスでもいい。CAPは、第1リソース伝送リクエストとしてのスケジューリング・リクエスト・シーケンスを受信してから、第1リソース伝送リクエスト応答の中には、前記スケジューリング・リクエスト・シーケンスのインデックスと、前記スケジューリング・リクエスト・シーケンスの周波数領域循環シフトのインデックスと、前記スケジューリング・リクエスト・シーケンスのアップリンク・スケジューリング・リクエスト通信チャンネルにおける送信位置及び前記スケジューリング・リクエスト・シーケンスから送られたシステムフレーム番号がキャリーされる。STAは、スケジューリング・リクエスト・シーケンスを送信するときに用いられたスケジューリング・リクエスト・シーケンスのインデックスと、スケジューリング・リクエスト・シーケンスの周波数領域の循環シフトのインデックスと、前記スケジューリング・リクエスト・シーケンスのアップリンク・スケジューリング・リクエスト通信チャンネルにおける送信位置及び前記スケジューリング・リクエスト・シーケンスから送られたシステムフレーム番号に基づき、前記スケジューリング・リクエスト・シーケンスと対応する第1リソース伝送リクエスト応答を受信する。

当然なら、ほかの実施例では、第1リソース伝送リクエストが別途の形式を採用してもよい。本発明はここで制限されるものではない。次に、本発明の実施例におけるスケジューリング・リクエスト・シーケンスのデバイズを第1リソース伝送リクエストの方式とすることについて説明する。

第1リソース伝送リクエストとする複数のスケジューリング・リクエスト・シーケンスを予めデバイズする。STAは第1リソース伝送リクエストを発起する時、予め規定されたルールに従い、前記複数のスケジューリング・リクエスト・シーケンスの中から１つを選んで第1リソース伝送リクエストとしてよい。選択方式が必要によって設けられてもよく、例えば、等確率選択方式、など。

スケジューリング・リクエスト・シーケンスのマークをデバイズする時、第1リソース伝送リクエストとして選択可の複数のスケジューリング・リクエスト・シーケンスにたいして番号をつけ、スケジューリング・リクエスト・シーケンスのシリアル番号をスケジューリング・リクエスト・シーケンスのマークとして用い、前記番号がインデックス形式でもよい。当然なら、ほかの方式で異なるスケジューリング・リクエスト・シーケンスをマーキングしてもよく、本発明はここで制限されるものではない。

当然なら、ほかの実施例では、その他の方式でスケジューリング・リクエスト・シーケンスをジェネレートすることができる。本発明はここで制限されるものではない。

その後、STAはアップリンク・スケジューリング・リクエスト・チャンネルで前記第1リソース伝送リクエストを送信できる。

本発明の実施例は、アップリンク・スケジューリング・リクエスト・チャンネルを介して第1リソース伝送リクエストを送信し、競合方式で本発明実施例のリソースリクエストプロセスを実現する。従って、アップリンク通信チャンネルに利用できるリソースの有無を監視することは不要となり、アップリンク伝送リソースがないとしても、リソース伝送リクエストを行うことができる。当然なら、ほかの実施例では、第1リソース伝送リクエストもそのチャンネルを介して送信できる。例えば、アップリンク通信チャンネルを介して伝送するなど。本発明はここで制限されるものではない。

本発明の実施例では、アップリンク・スケジューリング・リクエスト・チャンネルで第1リソース伝送リクエストを送信し、アップリンク・スケジューリング・リクエスト・チャンネルのOFDM記号の位置マークに前記スケジューリング・リクエスト・シーケンスの送信位置に対応するスケジューリング・リクエスト・シーケンスをデバイズすることができる。当然なら、ほかの実施例では、その他の方式でスケジューリング・リクエスト・シーケンスの送信位置をマーキングすることができる。本発明はここで制限されるものではない。

アップリンク・スケジューリング・リクエスト・チャンネルで第1リソース伝送リクエストを発起するとき、必要に応じて、例えばBPSK、QPSKなど方式で第1伝送リソースリクエストを一つのアップリンク・スケジューリング・リクエスト・チャンネルに変調させて送信する。

好ましくは、前記CAPは前記STAに第1伝送リソースをアロケートした後、伝送制御チャンネルによりリソースアロケートの指示を発行されることが望まれている。即ち、前記CAPは伝送制御チャンネルで第1リソース伝送リクエスト応答を送信し、第1リソース伝送の指示がキャリーされる。それに応じて、前記STAは、前記伝送制御チャンネルで前記第1リソース伝送リクエスト応答を受信することにより、そのアロケートされた第1リソース伝送リクエストが分かる。当然なら、ほかの実施例では、ほかのチャンネルで第1リソース伝送リクエスト応答を発行してもよい。本発明はここで制限されるものではない。

好ましくは、前記CAPは前記STAに第1伝送リソースをアロケートした後、ブロードキャスト方式で第1リソース伝送リクエスト応答を送信することができる。ブロードキャスト方式で第1リソース伝送リクエスト応答を送信するとき、前記STAは予め設定されたルールに従い、対応の応答を受信する。STAはスケジューリング・リクエスト・シーケンスを用いてアップリンクリソースリクエストを触発するとき、スケジューリング・リクエスト・シーケンスを送信するときに用いられたスケジューリング・リクエスト・シーケンスのインデックスと、前記スケジューリング・リクエスト・シーケンスの周波数領域の循環シフトのインデックスと、前記スケジューリング・リクエスト・シーケンスのアップリンク・スケジューリング・リクエスト通信チャンネルにおける送信位置及び前記スケジューリング・リクエスト・シーケンスから送られたシステムフレーム番号に基づき、前記スケジューリング・リクエスト・シーケンスと対応する第1リソース伝送リクエスト応答を受信することが望まれている。

本発明実施例は、ここで具体的な第1リソース伝送リクエスト応答フォーマットを提案し、次に、それについてを説明する。表2を参照する。

好ましくは、本発明の実施例では、第2リソース伝送リクエストのフォーマットを提供し、業務フローに基づいてリクエスト対象となるリソースの報告に対応可能である。そのうち、前記第2リソース伝送リクエストの中には、前記第2リソース伝送リクエストを発起したSTAのマークが含まれ、前記STAは１つまたは複数の業務フローの中の各の業務フローによりリクエストされる帯域幅リソースのサイズおよび各の業務フローのマークである。CAPは前記第2リソース伝送リクエストを解析することにより、STAの各の業務フロー
および各の業務フローのリソースの需要状況を把握できることが望まれている。

好ましくは、前記第2リソース伝送リクエストの中には各の業務フローのためにリクエストされる帯域幅リソースのタイプ更にを含む。CAPは、STAが必要に応じて各の業務フローのためにリクエストされる帯域幅リソースのタイプを選択可能で、リソースリクエストはより柔軟で、人間性が格別に向上することが望まれている。

選択可能な帯域幅リソースのタイプは下記のとおり。
増分の帯域幅は、業務フローのために第2伝送リソースをアロケートするよう指示するとき、前記業務フローのためにアロケートされた帯域幅リソースのサイズをもとに、前記業務フローの今回のリクエストの帯域幅リソースのサイズを増加または削減する。

総量の帯域幅は、業務フローのために第2伝送リソースをアロケートするよう指示する時、前記業務フローが今回にリクエストする帯域幅リソースのサイズを業務フローのためにアロケートされた帯域幅リソースのサイズと交換する。

好ましくは、本発明の実施例には、もうひとつの第2リソース伝送リクエストのフォーマットを提供し、STAに基づいてリクエスト対象となるリソースの報告に対応可能である。そのうち、前記第2リソース伝送リクエストの中には前記第2リソース伝送リクエストを発起するSTAのマークおよび前記STAによりリクエストされた総計の帯域幅リソースのサイズを含むことが望まれている。

好ましくは、前記第2リソース伝送リクエストの中にはSTAの必要な帯域幅リソースのタイプを更に含む。CAPは、STAが必要に応じてリクエストした帯域幅リソースのタイプ選択可能で、リソースリクエストはより柔軟で、人間性が格別に向上することが望まれている。

選択可能な帯域幅リソースのタイプは下記のとおり：
増分の帯域幅は、STAのために第2伝送リソースをアロケートするよう指示する時、STAのためにアロケートされた帯域幅リソースのサイズをもとに、STA今回のリクエストの帯域幅リソースのサイズを増加または削減する。

総量の帯域幅は、STAのために第2伝送リソースをアロケートするよう指示する時、STA今回のリクエストの帯域幅リソースのサイズをSTAのアロケートされた帯域幅リソースのサイズと交換する。

好ましくは、本発明の実施例には、帯域幅リソースの表示方法をさらに提供し、リソースリストをデバイズすることにより、該当帯域幅リソースが予め設定されたリソースリストの中でインデックスすることで、リクエストされる帯域幅リソースのサイズを指示する。それによって必要な帯域幅リソースを報告する時、前記帯域幅リソースに対応する前記帯域幅リソースリストの中のインデックス値だけをキャリーしてもよいく、特にリクエストの帯域幅リソースがわりに大きい時、インデックス値で具体的な帯域幅リソースの数値を代わり、占有されたビットが大いに削減し、伝送リソースの節約を図ることが望まれている。さらに直観的に説明するため、表3に示すように、下記にリソースの表示例を提供する。

好ましくは、必要に応じて多種の精度範囲のリソースリストをデバイズすることができる。リソース伝送リクエストを実行する時、リクエストされるリソースによって適当なリソースリストを選んで、リソース伝送リクエストの中にリソースリストのマークとインデックスがキャリーし、CAP側に同様なリソースリストを保守し、受信されたリソース伝送リクエストの中のリソースリストのマークとインデックスに基づき、対応するリソースリストの中に対応するインデックスのリソースのサイズを定位し、STAによりリクエストされるリソースのサイズを得る。

本発明の実施例では、第2リソース伝送リクエストを独立リソースのリクエストフレームとしてパッケージして送信することができる。本発明の実施例は上記の業務フローの報告方式を例とし、具体的な独立リソースのリクエストフレーム構成を提供する。図4に示すように、フレームヘッドと、フレーム本体及びフレームチェックシーケンス（FCS）を含む。フレームヘッドの中にフレーム制御情報を含む。例えばフレームタイプ（ここで管理コントロールである）、サブタイプ（ここで独立リソースリクエストフレームである）、バージョン情報など。フレーム本体にSTAIDと、FID個数と、および１つまたは複数のFIDメッセージブロックを含む。各のFIDメッセージブロックの中に業務フローのマークとリソースインデックスを含む。そのうち、リソースインデックスは、リクエストされる帯域幅リソースがリソースリストにおけるインデックスである。なお、タイプの異なるリソースをアロケートすることに対応可能な時、例えば増分と総量のリソースがアロケートすることに対応可能な時、業務フローの帯域幅リソース情報の中にこの業務フローを指示するリクエストのリソースのタイプ情報を更に設定してもよい。

なお、本発明は、独立リソースリクエストフレームのフレーム本体の中において、STAIDフィールドが12bitを占用し、FID個数フィールドが4bitを占用し、 FCSフィールドが32bitを占用し、そのうち、各のFIDメッセージブロックが16bitを占用し、順次に4bitのFIDフィールドと、4bitのリザーブフィールドと、7bitのリソースインデックスのフィールド及び1bitのリザーブフィールドであることをデバイズする。従って、バイトに基づいて読み取りを実現し、処理を簡素化する。

もし、上記のSTAに基づき報告方式を採用すると、図4に示す独立リソースリクエストフレームのフレーム本体の部分を変えていい。フレーム本体の部分にSTAIDとリソースインデックスをパッケージする。なお、もし、多種の精度のリソースリストを採用すれば、フレーム本体にリソースリストのタイプのフィールドを設定してもよい。本発明の実施例はここで贅言しない。

前記CAP は前記STAに第2伝送リソースをアロケートした後、ユニキャスト方式で第2リソース伝送リクエスト応答を送信することができる。その中に第2リソース伝送の指示がキャリーされる。前記STAは予め設定されたルールに従い、対応の応答を受信する。例えば、STAIDが正しく受信する根拠とし、即ち、STAは第2リソース伝送リクエストの中で自身のSTAIDをキャリーし、CAPはSTAに第2リソース伝送リクエスト応答を返信する時、第2リソース伝送リクエスト応答の中でSTAのSTAIDもキャリーする。STAは、受信した第2リソース伝送リクエスト応答の中で自身のSTAIDがキャリーされるかどうかを判断することにより正しく対応の応答を受信するかどうかを確認する。

好ましくは、前記CAP は前記STAに第2伝送リソースをアロケートした後、制御チャンネルを経由してリソースをアロケートする指示を送信することができる。即ち、前記CAPは伝送制御チャンネルで第2リソース伝送リクエスト応答を送信することができる。その中に第2リソース伝送の指示がキャリーされる。それに応じて、前記STAが前記伝送制御チャンネルで前記第2リソース伝送リクエスト応答を受信して、その中からアロケートされた第2リソースを得ることが望まれている。当然なら、ほかの実施例では、ほかのチャンネルで前記第2リソース伝送リクエスト応答を発行することがデバイスできる。本発明はここで制限されるものではない。

第1リソース伝送リクエストを送信した後に、もし、予め設定された第1最大待ちフレームの間隔を越えた後に、第1リソース伝送リクエスト応答を受信していない場合には、今回のリソース送信に失敗したと認めてリソースを再びリクエストする必要。または、第2リソース伝送リクエストを送信した後に、予め設定された第2最大待ちフレームの間隔を越えた後に、第2リソース伝送リクエスト応答を受信していない場合には、今回のリソース送信に失敗したと認めてリソースを再びリクエストする必要。本発明の実施例において、応答の返信時間を監視することによりリソースリクエストが成功しているかを判断し、遅滞なく再びリソース伝送リクエストを送る。また、フレームをカウントすることによりタイマー機能を実現し、タイマー機能を更に精確にし、すぐに処理することができることが望まれている。

上記の競争方式でリソースをリクエストする方法を実現するために、実施例に関わる本発明は、リソースリクエストに適用されるSTAを提供する。図5に示すように下記の構成を含む。

第1送信モジュール501は、第1リソース伝送リクエストを送信することに用いられているものである。

第1受信モジュール502は、第1リソース伝送リクエスト応答を受信することに用いられているもので、第1リソース伝送リクエスト応答の中で第1リソース伝送の指示がキャリーされる。

第2送信モジュール503は、第1伝送リソースを用いて第2リソース伝送リクエストを送信することに用いられているものである。

第2受信モジュール504は、第2リソース伝送リクエスト応答を受信することに用いられているもので、第2リソース伝送リクエスト応答の中に第2リソース伝送の指示がキャリーされる。

第3送信モジュール505は、第2リソース伝送データを送信することに用いられているものである。

好ましくは、ほかの実施例において、前記STAは、次のような構成をさらに含む。

前記STAはリソースアロケートモジュールをさらに含み、リソースアロケートモジュールは第2受信モジュール504と第3送信モジュール505の間に配置され、第2リソース伝送の指示によって各の業務フローの間にリソースをアロケートすることに用いられる。前記第3送信モジュール505は、前記リソースアロケートモジュールにおけるリソースのアロケートの結果によって複数の業務フローをそれぞれに対応する伝送リソースの上でデータを伝送することが望まれている。

好ましくは、前記第1リソース伝送リクエストは一つのスケジューリング・リクエスト・シーケンスである。

前記第1リソース伝送リクエストは一つのスケジューリング・リクエスト・シーケンスである。

前記第1送信モジュール501は、アップリンク・スケジューリング・リクエスト・チャンネルで前記スケジューリング・リクエスト・シーケンスを送信することに用いられているものであることが望まれている。

好ましくは、前記第1受信モジュール502は前記スケジューリング・リクエスト・シーケンスのインデックスと、前記スケジューリング・リクエスト・シーケンスの周波数領域の循環シフトのインデックスと、前記スケジューリング・リクエスト・シーケンスのアップリンク・スケジューリング・リクエスト・チャンネルにおける送信位置及びスケジューリング・リクエスト・シーケンスから送られるシステムフレーム番号に基づいて、前記スケジューリング・リクエスト・シーケンスに対応する第1伝送リソースリクエスト応答を受信するに用いられる。

前記第1受信モジュール502は、伝送制御チャンネルで第1リソース伝送リクエスト応答を受信することに用いられているものであることが望まれている。

前記第2送信モジュール503は、第2リソース伝送リクエストの中にSTAのマークとリクエストされたリソースがキャリーされることに用いられているものであることが望まれている。

前記第2送信モジュール503は、前記第2リソース伝送リクエストの中に１つまたは複数の業務フローのマークおよび各の業務フローのためにリクエストされた帯域幅リソースのサイズをキャリーされることにより、業務フローに基づいてリソースリクエストを行うことが望まれている。

前記第2送信モジュール503は、前記第2リソース伝送リクエストの中に予め設定されたリソースリストの中のインデックスで帯域幅リソースのサイズを指示することに用いられているものであることが望まれている。

前記第2送信モジュール503は、前記第2リソース伝送リクエストの中にリソースの業務フローの個数がキャリーされることに用いられているものであることが望まれている。

前記第2送信モジュール503は、前記第2リソース伝送リクエストを独立リソースのリクエストフレームとしてパッケージすることに用いられているものであることが望まれている。

前記独立リソースのリクエストフレームは、フレームヘッドと、フレーム本体及びフレームチェックシーケンスFCSを含む。

前記フレーム本体は、STAのマークと、および１つあるいは複数のFIDメッセージブロックを含む。各のFIDメッセージブロックには業務フローマークとリソースインデックスを含む。

前記第2送信モジュール503は、第2伝送リソースを別の独立リソースのリクエストフレームとしてパッケージし、送信することに用いられているものであることが望まれている。

前記独立リソースリクエストフレームは、フレームヘッドと、フレーム本体及びチェックシーケンスFCSを含む。

前記フレーム本体は、STAのマークと、業務フローの個数と、および１つあるいは複数のFIDメッセージブロックを含む。各のFIDメッセージブロックの中に業務フローマークとリソースインデックスを含むことが望まれている。

好ましくは、ほかの実施例では、第1再送信モジュールをさらに含んでもいい。前記第1再送信モジュールが第1送信モジュール501及び第1受信モジュール502とそれぞれに繋げる。前記第1送信モジュール501から第1リソース伝送リクエストを送信したあと、タイマーを起動し、もし、予め設定された第1最大待ちフレームの間隔を超えた後に、前記第1受信モジュール502は第1リソース伝送リクエスト応答を受信していない場合に今回のリソースリクエストに失敗したと認められ、前記第1送信モジュール501が第1リソース伝送リクエストを再びに送信させるよう触発する。

好ましくは、ほかの実施例では、第2再送信モジュールをさらに含み、前記第2再送信モジュールが第2送信モジュール503及び前記第2受信モジュール504とそれぞれに繋げる。前記第2送信モジュール503から第2リソース伝送リクエストを送信したあと、予め設定された第2最大待ちフレームの間隔を超えた後に、前記第2受信モジュール504が第2リソース伝送リクエスト応答を受信していない場合に今回のリソースリクエストに失敗したと認められ、前記第1送信モジュール501を第1リソース伝送リクエストを再びに送信させるよう触発する。

前記第2リソース伝送リクエストの中に各の業務フローのためにリクエストされる帯域幅リソースのタイプを更に含むことが望まれている。

前記帯域幅リソースのタイプに次のようなことを含むことが望まれている。
増分の帯域幅は、業務フローのために第2リソース伝送リクエストをアロケートする時、業務フローのためにアロケートされた帯域幅リソースのサイズを基づき、業務フローにおける今回のリクエストの帯域幅リソースのサイズを増加や削減することの指示に用いられる。

総量の帯域幅は、業務フローのために第2リソース伝送リクエストをアロケートする時、業務フローにおける今回のリクエストの帯域幅リソースのサイズを用いて、業務フローのためにアロケートされら帯域幅リソースのサイズに替わることの指示に用いられる。

前記第2リソース伝送リクエストはSTAを基づいてリソースリクエストを報告することができることが望まれている：
即ち、前記第2リソース伝送リクエストの中には、前記第2リソース伝送リクエストのSTAの必要な帯域幅リソースのサイズを発起することも含む。

予め設定されたリソースリストには多種の精度範囲のリソースリストを含むことが望まれている。

上記競争方式でのリソースリクエスト方法を実現するため、実施例に関わる本発明は、リソース伝送リクエストに用いられるCAPを提供する。図6に示すように、下記の構成を含む。

第1受信モジュール601は、第1リソース伝送リクエストを受信し、対応のSTAに第1伝送リソースをアロケートすることに用いられているものである。

第1送信モジュール602は、第1リソース伝送リクエスト応答を対応のSTAに送信することに用いられているもので、前記第1リソース伝送リクエスト応答には第1リソース伝送の指示がキャリーされる。

第2送信モジュール603は、第2リソース伝送リクエストを受信し、対応のSTAに第2伝送リソースをアロケートすることに用いられているものである。

第2送信モジュール604は、第2リソース伝送リクエスト応答をSTAに送信することに用いられているもので、前記第2リソース伝送リクエスト応答に第2リソース伝送の指示がキャリーされる。

前記第1リソース伝送はSTAが第2リソース伝送リクエストを送信することに用いられているものである。

前記第2リソース伝送はSTAがデータを送信することに用いられているものである。

好ましくは、前記第1送信モジュール601は、アップリンク・スケジューリング・リクエスト・チャンネルで前記第1リソース伝送リクエストを受信し、前記第1リソース伝送リクエストシーケンスが一つのスケジューリング・リクエスト・シーケンスである。前記第1送信モジュール602は、前記第1リソースリクエスト応答の中に、前記対応のスケジューリング・リクエスト・シーケンスインデックスと、前記スケジューリング・リクエスト・シーケンスの周波数領域の循環シフトのインデックスと、前記スケジューリング・リクエスト・シーケンスがアップリンクスケジューリング・リクエスト通信チャンネルにおける送信位置及びスケジューリング・リクエスト・シーケンスから送られたシステムのフレーム番号がキャリーされることに用いられる。

前記第1送信モジュール602は、伝送制御チャンネルで前記第1伝送リソースリクエスト応答を送信することに用いられているものであることが望まれている。

前記第1送信モジュール602は、ブロードキャストの方式で前記第1リソース伝送リクエスト応答を送信することに用いられているものであることが望まれている。

前記第2送信モジュール604は、伝送制御チャンネルで第2伝送リソースリクエスト応答を送信することに用いられているものであることが望まれている。

前記第2送信モジュール604は、ブロードキャストの方式で第2伝送リソースリクエスト応答を送信することに用いられているものであることが望まれている。

前記第2送信モジュール604は、前記第2リソース伝送リクエスト応答の中に対応のSTAのマークおよび前記STAにアロケートされたリソースがキャリーされることが望まれている。

上記競争方式でリソースリクエスト方法を実現するため、実施例に関わる本発明は、リソース伝送リクエストを実現するためのシステムを提供し、前記システムが上記STAとCAPを含み、両者が互いにインタラクティブで、競合方式でリソースリクエストプロセスを完成し、特に、STAが伝送リソースを有してない場合に最適である。

本発明の実施例には、リソースリクエスト方法をさらに提供する。下記のステップを含む。

リソース伝送リクエストをジェネレートする。前記リソース伝送リクエストの中にはSTAのマークと、１つまたは複数の業務フローのマークおよび各の業務フローのためにリクエストされた帯域幅リソースのサイズを含む。

リソース伝送リクエストを送信する。
リソース伝送リクエストの中にはリクエストリソースの業務フローの個数をさらに含むことが望まれている。

前記リソース伝送リクエストを独立リソースのリクエストフレームとしてパッケージして送信することが望まれている：
前記独立リソースリクエストフレームにはフレームヘッドと、フレーム本体及びFCSを含む。

前記フレーム本体は、STAのマークおよび１つあるいは複数のFIDメッセージブロックを含む。各のFIDメッセージブロックの中に業務フローマークとリソースインデックスを含む。

前記リソース伝送リクエストを他種の独立リソースリクエストフレームとしてパッケージして送信することが望まれている：
前記独立リソースリクエストフレームにはフレームヘッドと、フレーム本体及びFCSを含む。

前記フレーム本体は、STAのマークと、業務フローの個数および１つあるいは複数のFIDメッセージブロックを含む。各のFIDメッセージブロックの中に業務フローマークとリソースインデックスを含む。

リソース伝送リクエストの中には各の業務フローの必要な帯域幅リソースのタイプをさらに含むことが望まれている。

好ましくは、前記帯域幅リソースは下記のタイプを含む。
増分の帯域幅は、業務フローのためにリソース伝送リクエストをアロケートする時、業務フローにアロケートされた帯域幅リソースのサイズを基づき、業務フローにおける今回のリクエストの帯域幅リソースのサイズを増加や削減することの指示に用いられる。

総量の帯域幅は、業務フローのためにリソース伝送リクエストをアロケートする時、業務フローにおける今回のリクエストの帯域幅リソースのサイズが業務フローにアロケートされた帯域幅リソースのサイズに替わることに用いられる。

前記帯域幅リソースのサイズは予め設定されたリソースリストの中のインデックスで指示することが望まれている。

前記リソース伝送リクエストの中に予め設定されたリソースリストのタイプがキャリーされ、異なるタイプのリソースリストが異なる精度範囲に対応する。前記予め設定されたリソースリストには多種の精度範囲のリソースリストが含まれることが望まれている。

実施例に関わる本発明は、リソースをリクエストするもうひとつの方法を提供する。下記のプロセスを含む。

リソース伝送リクエストをジェネレートし、前記リソース伝送リクエストの中にはSTAのマーク及び前記STAによりリクエストされる総計帯域幅リソースのサイズを含む。前記リソース伝送リクエストを送信する。

前記リソース伝送リクエストの中にはSTAによりリクエストされる帯域幅リソースのタイプをさらに含まれることが望まれている。

帯域幅リソースは下記のタイプを含む。
増分の帯域幅は、STAのためにリソース伝送リクエストをアロケートする時、前記STAにアロケートされた帯域幅リソースのサイズを基づき、前記STAにおける今回のリクエストの帯域幅リソースのサイズを増加や削減することの指示に用いられる。

総量の帯域幅は、STAのためにリソース伝送リクエストをアロケートする時、前記STAにおける今回のリクエストの帯域幅リソースのサイズが前記STAにアロケートされた帯域幅リソースのサイズに替わることに用いられる。

実施例２
実施例２関わる本発明は、リソースをリクエストするもう一つの方法を提供する。アップリンクのデータの時機とリソースを活かし、リソース伝送リクエストをアップリンクのデータに連携させて一緒にCAPに送信する。具体的には図7に示すように、下記のステップを含む。
ステップS701：STAはリソース伝送リクエストをデータフレームの中に載せる。
ステップS702：前記STAは、リソース伝送リクエストをキャリーしたデータフレームを送信する。
ステップS703：CAPはリソース伝送リクエストをキャリーしたデータフレームを送信する。
ステップS704：前記CAPはデータフレームの中からリソース伝送リクエストを解析する。
ステップS705：前記CAPはリソース伝送リクエストに応じて、前記STAのためにリソース伝送リクエストをアロケートする。
ステップS706：前記CAPはリソース伝送リクエスト応答をSTAに送信し、前記リソース伝送リクエスト応答にはリソース伝送の指示がキャリーされる。
ステップS707：前記STAは受信リソース伝送リクエスト応答を受信する。
ステップS708：前記STAは伝送リソースを用いてデータを送信する。
実施例２に関わる本発明は、上記の方法でリソース伝送リクエストをアップリンクのデータに連携させて一緒にCAPに送信することにより、リソースのリクエストを図る。アップリンクのデータ伝送がある時、上記のチャンネル連携リソース伝送リクエスト方法でリソースをリクエストすることにより、前記リソース伝送リクエストに必要なアップリンク伝送リソースを先にリクエストすることは不要となり、リソース伝送リクエストの実現プロセスにおけるインタラクティブステップは更に少なくなり、リソースリクエストに必要な時間はより短くなる。

好ましくは、STAは、リソース伝送リクエストをキャリーしたデータフレームの中にチャネル連携リクエストの指示をキャリーし、伝送リソースリクエストの存在を指示することに用いられている。それに応じて、CAPはデータフレームを受信した後で、チャネル連携リクエストの指示によりデータフレーム中にはリソース伝送リクエストがキャリーされるかどうかを速やかに判断できる。当然なら、ほかの実施例では、チャネル連携リクエストの指示をキャリーしなくてもいい。例えば特定のフィールドを設定することでリソース伝送リクエストを載せ、対応のフィールドを解析することにより、データフレーム中にはリソース伝送リクエストがキャリーされるかどうかを判断する。本発明はここで制限されるものではない。

CAPはデータフレームを解析する時、一般にフレームヘッドを先に解析してパラメーター情報を得るので、データフレームの中にチャネル連携リクエストの指示をパッケージする時、チャネル連携リクエストの指示をデータフレームのフレームヘッド中にパッケージしてよい。

チャネル連携リクエストの指示のことを具体的に実現する時、データフレームのフレームヘッドの中に一つのチャネル連携リクエストの指示のフィールドを設定することができ、前記フィールドの値に基づいて前記リソース伝送リクエストが存在することを指示する。例えば、1はリソース伝送リクエストが存在していることを示す、0はリソース伝送リクエストが存在しないことを示す。

前記チャネル連携リクエストの指示フィールドが新規されたフィールドでもよく、フレームヘッドの中に既存のフィールドでもよい。例えば、フリーフィールドをチャネル連携リクエストの指示のフィールドと再定義する。本発明はここで制限されるものではない。前記チャネル連携指示フィールドのフレームヘッドにおける位置は、予め設定されたルールに基づいて設定できる。本発明はここで制限されるものではない。

STAは前記リソース伝送リクエストをデータのフレーム本体の中に載せることができる。それを具体的に実現する時、データのフレーム本体に前記リソース伝送リクエストを載せる一つのチャネル連携リソースリクエストフィールドを設定する。データフレームの中にリソース伝送リクエストがキャリーしない時、データのフレーム本体にチャネル連携リソースリクエストフィールドを設定しなくてもよく、または前記チャネル連携リソースリクエストフィールドに固定値を充填してもよい。

前記チャネル連携リソースリクエストフィールドは新規フィールドであってもよく、フレームヘッドに既存フィールドであってもよい。例えば、フリーフィールドをチャネル連携リソースリクエストフィールドと再定義してもよい。本発明はここで制限されるものではない。前記チャネル連携リソースリクエストフィールドはフレーム本体における位置が予め設定されたルールに設定することができる。例えば、チャネル連携リソースリクエストフィールドは、フラーム本体における位置は予め設定されたルールに基づいて設定できる。例えば、チャネル連携リソースリクエストフィールドはフラーム本体の上若干のビットであると規定する。本発明はここで制限されるものではない。

実施例に関わる本発明は、チャネル連携方式でリソース伝送リクエストのフォーマットを提供し、業務フローに基づいてリクエストを報告することが実現できる。そのうち、前記リソース伝送リクエストの中には前記リソース伝送リクエストを発起するSTAのマークと、前記STAの１つあるいは複数の業務フロー中の各の業務フローのためにリクエストされる帯域幅リソースのサイズおよび各の業務フローマークが含まれる。CAPはリソース伝送リクエストを解析して、前記STAの各の業務フローおよび前記各の業務フローのリソースの需要状況を認識することができることが望まれている。

前記リソース伝送リクエストの中には各の業務フローのためにリクエストされる帯域幅リソースのタイプが更に含まれる。CAPは、STAが必要に応じて異なる業務フローのためにリクエストされる帯域幅リソースのタイプを選ぶことに対応可能で、リソースリクエストはより柔軟で、人間性が格別に向上することが望まれている。

好ましくは、本発明の実施例には、もうひとつの第2リソース伝送リクエストのフォーマットを提供し、STAに基づいてリクエスト対象となるリソースの報告に対応可能である。そのうち、前記第2リソース伝送リクエストの中には前記第2リソース伝送リクエストを発起するSTAのマークおよび前記STAによりリクエストされた総計の帯域幅リソースのサイズを含むことが望まれている。
好ましくは、前記第2リソース伝送リクエストの中にはSTAの必要な帯域幅リソースのタイプを更に含む。CAPは、STAが必要に応じてリクエストした帯域幅リソースのタイプ選択可能で、リソースリクエストはより柔軟で、人間性が格別に向上することが望まれている。

好ましくは、本発明の実施例には、帯域幅リソースの表示方法をさらに提供し、（例えば表3）、リソースリストをデバイズすることにより、該当帯域幅リソースが予め設定されたリソースリストの中でインデックスすることで、リクエストされる帯域幅リソースのサイズを指示する。それによって必要な帯域幅リソースを報告する時、前記帯域幅リソースに対応する前記帯域幅リソースリストの中のインデックス値だけをキャリーしてもよいく、特にリクエストの帯域幅リソースがわりに大きい時、インデックス値で具体的な帯域幅リソースの数値を代わり、占有されたビットが大いに削減し、伝送リソースの節約を図ることが望まれている。

実施例に関わる本発明は、リソース伝送リクエストをキャリーする具体的なデータフレームの構成を提供し、フレームヘッドと、フレーム本体及びFCSを含む。フレームヘッドの中にはチャネル連携リソースリクエストフィールドを含み、前記チャネル連携リソースリクエストフィールドの値は本体の中にリソース伝送リクエストがあると指示するとき、前記フレーム本体にはチャネル連携リソースリクエストフィールドを含み、前記チャネル連携リソースリクエストフィールドには１つあるいは複数のFIDメッセージブロックを含み、各のFIDメッセージブロックには業務フロー(FID)とリソースインデックスを含む。そのうち、リソースインデックスはリクエストされる帯域幅リソースのリソースリストの中のインデックスを示す。

ほかの実施例では、FIDメッセージブロックの中にはリソースリストのタイプのフィールドをさらに含むので、精細度別にリソースを区別することが実現できる。なお、異なるタイプのリソースをアロケートすることに対応可能な時、例えば増分と総量のリソースのアロケートが対応可能な時、FIDメッセージブロックの中にこの業務フローのためにリクエストされるリソースのタイプ情報を設定することができる。

もし、STAに基づいて報告する上記の方式を採用すると、前記チャネル連携リソースリクエストフィールドに載せられた内容だけを変えてもよい。その中にリソースリストのマークとリソースインデックスが載せられる。本発明の実施例はここで贅言しない。

前記CAP は前記STAのために伝送リソースをアロケートした後で、ユニキャスト方式でリソース伝送リクエスト応答を送信することができ、そのうちにリソース伝送の指示がキャリーされる。前記STAは予め設定されたルールに基づいて、対応の応答を受信する。例えば、STAIDが正しく受信する根拠とし、即ち、STAは第2リソース伝送リクエストの中で自身のSTAIDをキャリーし、CAPはSTAに第2リソース伝送リクエスト応答を返信する時、第2リソース伝送リクエスト応答の中でSTAのSTAIDもキャリーする。STAは、受信した第2リソース伝送リクエスト応答の中で自身のSTAIDがキャリーされるかどうかを判断することにより正しく対応の応答を受信するかどうかを確認する。

STAは受信リソース伝送リクエスト応答を受信した後、伝送リソースを用いてデータを送信する前、リソース伝送の指示に従いて、リソースを各の業務フローの間にアロケートを行うことが望まれている。

STAは、リソース伝送リクエストをキャリーする前記データフレームを送信した後で、もし、予め設定された第1最大待ちフレームの間隔を越えた後に、第1リソース伝送リクエスト応答を受信していない場合には、今回のリソース送信に失敗したと認めてリソースを再びリクエストする必要。本発明の実施例において、応答の返信時間を監視することによりリソースリクエストが成功しているかを判断し、遅滞なく再びリソース伝送リクエストを送る。また、フレームをカウントすることによりタイマー機能を実現し、タイマー機能を更に精確にし、すぐに処理することができることが望まれている。

上記のチャネル連携方式でリソースリクエストする方法を実現するため、実施例に関わる本発明は、チャネル連携リソースリクエストに用いられているSTAを提供し、図8に示すように下記の構成を含む。

パッケージ・モジュール801は、リソース伝送リクエストをデータフレームの中に載せることに用いられているものである。

第1送信モジュール802は、リソース伝送リクエストをキャリーする前記データフレームを送信することに用いられているものである。

受信モジュール803は、リソース伝送リクエスト応答を受信することに用いられているもので、前記リソース伝送リクエスト応答の中にはリソース伝送の指示がキャリーされる。

第2送信モジュール804は、リソース伝送データを送信することに用いられているものである。

ほかの実施例では、前記STAには、下記のような構成を含むことが望まれている。

リソースアロケートモジュールは、受信モジュール803と第2送信モジュール804の間に位置し、前記リソース伝送の指示に従い、リソースを各の業務フローの間にアロケートする。前記第2送信モジュール804は、リソースアロケートモジュールにおけるリソースアロケートの結果に基づき、複数の業務フローのそれぞれに対応する伝送リソースの上でデータを伝送する。

前記パッケージモジュール801は、データフレームの中にチャネル連携リクエスト指示をパッケージし、前記リソース伝送リクエストの存在を指示することに用いられていることもできることが望まれている。

前記パッケージモジュール801は、前記チャネル連携リクエストの指示をデータフレームヘッド中で載せることができることが望まれている。

前記パッケージモジュール801は、データフレームのフレームヘッドの中に１フィールドを設定し、フィールドの値を通じて前記リソース伝送リクエストの存在を指示することが望まれている。

前記パッケージモジュール801は、前記リソース伝送リクエストをデータのフレーム本体の中で載せることができる。

前記パッケージモジュール801は、データフレームのフレーム本体に1フィールドを設定することができ、前記リソース伝送リクエストを載せる。

前記リソース伝送リクエストは業務フローに基づいてリソースリクエストを報告することができることが望まれている：
即ち、リソース伝送リクエストの中には１つあるいは複数の業務フローのマークおよび各の業務フローのためにリクエストされる帯域幅リソースのサイズを含む。

前記リソース伝送リクエストの中には各の業務フローのためにリクエストされる帯域幅リソースのタイプを更に含むことが望まれている。

前記帯域幅リソースがに次のようなタイプを含むことが望まれている。
増分の帯域幅は、業務フローのためにリソース伝送リクエストをアロケートする時、業務フローにアロケートされた帯域幅リソースのサイズを基づき、業務フローにおける今回のリクエストの帯域幅リソースのサイズを増加や削減することの指示に用いられる。

前記リソース伝送リクエストは、STAを基づいてリソースリクエストを報告することができることが望まれている。
即ち、前記リソース伝送リクエストの中には前記リソース伝送リクエストのSTAの必要な帯域幅リソースのサイズを発起することも含む。

前記リソース伝送リクエストの中に帯域幅リソースのタイプを更に含むことができることが望まれている。

帯域幅リソースが次のようなタイプを含むことが望まれている。
増分の帯域幅は、STAのためにリソース伝送リクエストをアロケートする時、前記STAにアロケートされた帯域幅リソースのサイズを基づき、前記STAにおける今回のリクエストの帯域幅リソースのサイズを増加や削減することの指示に用いられる。

前記リソース伝送リクエストの中にリソース伝送リクエストを送るSTAのマークを含む。前記リソース伝送リクエスト応答がSTAのマークをキャリーすることが望まれている。

前記予め設定されたリソースリストには多種の精度範囲のリソースリストが含まれることが望まれている。

前記第2送信モジュール804は、複数の業務フローを前記伝送リソースにおけるそれぞれ対応する伝送リソースでデータを伝送することが望まれている。

前記受信モジュール803は、伝送制御チャンネルでリソース伝送リクエスト応答を受信することができることが望まれている。

ほかの実施例では、前記STAには、次のような構成をさらに含むことが望まれている：
再送信モジュールは前記第1送信モジュール802から前記リソース伝送リクエストをキャリーするデータフレームを送信したあと、タイマーをONにし、予め設定された最大待ち時間が越えた後、前記受信モジュール803はリソース伝送リクエスト応答を受信できない場合に、今回のリソースリクエストに失敗したと認められ、パッケージモジュール801を触発して、データの伝送がある時、前記リソース伝送リクエストをデータフレームの中に載せ、リソース伝送リクエストを再びに発起する。

上記のチャネル連携方式でリソースをリクエストする方法を実現するため、実施例に関わる本発明は、チャネル連携リソースリクエストの実現に用いられるCAPを提供し、図9に示すように、下記の構成を含む。

受信モジュール901は、リソース伝送リクエストをキャリーするデータフレームを受信することに用いられているものである。

解析モジュール902は、前記データフレーム中からリソース伝送リクエストを解析することに用いられているものである。

リソースアロケートモジュール903は、前記リソース伝送リクエストに基づき、対応のSTAのために伝送リソースをアロケートすることに用いられているものである。

送信モジュール904は、リソース伝送リクエスト応答を対応のSTAに送信することに用いられているもので、前記リソース伝送リクエスト応答の中にはリソース伝送の指示がキャリーされる。

前記データフレーム中にはチャネル連携リクエストの指示を更に含んで、伝送リソースリクエストの存在を指示することに用いられていることもできる。それに応じて、前記解析モジュール902は、データフレームの中のチャネル連携リクエストの指示を解析することにより、リソース伝送リクエストの存在を指示することを識別することが望まれている。

データフレームのフレームヘッドの中に一つのフィールドを設定し、前記フィールドの値はリソース伝送リクエストの存在を指示する。それに応じて、前記解析モジュール902は、データフレームヘッドの中にチャネル連携リクエストのフィールドを解析することにより、前記チャネル連携リクエストの指示を取得することが望まれている。

前記リソース伝送リクエストは前記データフレームのフレーム本体の中で載せることができる。それに応じて、前記解析モジュール902は、データフレームの本体を解析するによりリソース伝送リクエストを得ることができることが望まれている。

前記データフレームのフレーム本体の中に一つのフィールドを設定し、リソース伝送リクエストを載せる。それに応じて、前記解析モジュール902は、データフレームのフレーム本体におけるチャネル連携リソースリクエストフィールドを通じて、リソース伝送リクエストを得ることができることが望まれている。

リソース伝送リクエストの中には各の業務フローのためにリクエストされる帯域幅リソースのタイプを更に含むことが望まれている。

前記帯域幅リソースはに次のようなタイプを含むことが望まれている。
増分の帯域幅は、業務フローのためにリソース伝送リクエストをアロケートする時、業務フローにアロケートされた帯域幅リソースのサイズを基づき、業務フローにおける今回のリクエストの帯域幅リソースのサイズを増加や削減することの指示に用いられる。

前記送信モジュール904は、伝送制御チャンネルで前記リソース伝送リクエスト応答をSTAに送信することができる。

前記送信モジュール904は、ユニキャスト方式で前記リソース伝送リクエスト応答をSTAに送信することができる。

上記のチャネル連携方式でリソースをリクエストする方法を実現するため、実施例に関わる本発明は、チャネル連携リソースリクエストを実現するシステムを提供し、前記STAとCAPを含み、両者が互いにインタラクティブで、データ伝送の時機とリソースを活用し、チャネル連携方式でリソースリクエストプロセスを完成する。

実施例３
実施例３に関わる本発明は、リソースをアロケートする方法をさらに提供する。CAPが自発的に少なくとも１つのSTAのためにリソース伝送リクエストのリソースをポーリングでアロケートする。具体的には、図10に示すように、下記のステップを含む。
ステップS1001：CAPは少なくとも１つのSTAをポーリングし、ポーリングされた各のSTAのために第1伝送リソースをアロケートする。
ステップS1002：前記CAPは第1リソース伝送の指示を前記ポーリングされたSTAに送信する。
ステップS1003：前記STAは前記第1リソース伝送の指示を受信する。
ステップS1004：前記STAは前記第1リソースを用いてリソース伝送リクエストを送信する。
ステップS1005：前記CAPは前記リソース伝送リクエストを受信し、対応のSTAのために第2伝送リソースをアロケートする。
ステップS1006：前記CAPはリソース伝送リクエスト応答を対応のSTAに送信し、前記リソース伝送リクエスト応答の中には第2リソース伝送の指示がキャリーされる。
ステップS1007：前記STAは前記受信リソース伝送リクエスト応答を受信する。
ステップS1008：前記STAは前記第2伝送リソースを用いてデータを送信する。

本発明実施例では、CAPがポーリング方式で自発的にSTAへ第1伝送リソースをアロケートするので、STAが第1伝送リソースを用いてリソース伝送リクエストを発起することができる。アップリンクデータにリソース伝送をリクエストする時、どのようにアップリンクデータの伝送に必要な伝送リソースを得るかという課題を解決する。

CAPは予め設定されたポーリング策略に従いSTAをポーリングすることができることが望まれている：
例えば、ポーリングの順位、ポーリング間隔、リソースのアロケート条件などポーリングパラメーターを設定し、これに基づいてSTAをポーリングすることができる。本実施例の中にはリソースのアロケートの条件を設定して各のポーリングしたSTAへリソースをアロケートすることが望まれている。

ポーリング策略を次のように設定してもよい。現行のアロケートできる伝送リソースの有無を判断し、現行のアロケートできる伝送リソースが有する時、ポーリングのステップをスタートする。それによって、アロケートできる伝送リソースが有する時、CAPが自発的にSTAのためにリソース伝送リクエストをアロケートし、STAによるリクエストが不要で、リソースリクエストプロセスの中インタラクティブを減らし、システム全般のリソース伝送リクエストのスピードが向上できることが望まれている。

前記CAPは予め設定されたルールに従い現行のアロケートできる帯域幅リソースの判断を触発することができる。例えば、周期的な判断、リアルタイム判断、またはいくつかの条件に合う時の判断など。本発明はここで制限されるものではない。

前記CAP はSTAのために第1伝送リソースをアロケートした後、ユニキャスト方式で第1リソース伝送の指示をSTAに送信することができる。

前記CAPはSTAのために第1伝送リソースをアロケートした後、伝送制御チャンネルでリソースをアロケートする指示を発送することができる。即ち、前記CAP伝送制御チャンネルで第1リソース伝送指示を送信することができる。それに応じて、前記STAが伝送制御チャンネルで第1リソース伝送の指示を受信することにより、その中からアロケートされた第1リソース伝送リクエストを取得できる。当然なら、ほかの実施例では、ほかのチャンネルで第1リソース伝送の指示を発送することを設定することができることが望まれている。本発明はここで制限されるものではない。

実施例に関わる本発明はリソース伝送リクエストのフォーマットを提供し、業務フローに基づいてリクエスト対象となるリソースの報告に対応可能である。そのうち、前記リソース伝送リクエストの中にはリソース伝送リクエストのSTAのマークと、１つあるいは複数の業務フローのマークおよび各の業務フローのためにリクエストされる帯域幅リソースのサイズを含む。CAPはリソース伝送リクエストを解析して、STAの各の業務フローおよび各の業務フローのリソースの需要状況を取得することができることが望まれている。

前記リソース伝送リクエストの中には各の業務フローのためにリクエストされる帯域幅リソースのタイプを更に含む。CAPは、STAが必要に応じて各の業務フローのためにリクエストされる帯域幅リソースのタイプを選ぶことに対応可能で、リソースリクエストはより柔軟で、人間性が格別に向上することが望まれている。

本発明の実施例では、前記リソース伝送リクエストをリソースリクエストフレームの中に載せて送信することができる。実施例関わる本発明は上記の業務フローに基づいて報告する方式を例として、具体的なリソース伝送リクエストのフレーム構成を提出し、図4に示すように、フレームヘッドと、フレーム本体及びFCSを含む。フレームヘッドの中にフレーム制御情報を含む。例えば、フレームのタイプ（ここで制御管理である）、サブタイプ（ここで独立リソースリクエストフレームである）、バージョン情報など。フレーム本体にはSTAIDと、FIDの個数および１つあるいは複数のFIDメッセージブロックを含む。各のFIDメッセージブロックの中に業務フローマークとリソースインデックスを含む。そのうち、リソースインデックスは、リクエストされる帯域幅リソースのリソースリストの中のインデックスである。なお、タイプの異なるリソースをアロケートすることに対応可能な時、例えば増分と総量のリソースのアロケートに対応可能な時、前記業務フローの帯域幅リソース情報の中には、この業務フローのタイプを指示する情報を設定してもよい。

なお、本発明は、独立リソースリクエストフラームのフレーム本体のSTAIDフィールドが12bit、FID個数フィールドが4bit、 FCSフィールドが32bit、各のFIDメッセージブロックは16bit、順次に4bitのFIDフィールド、4bitのリザーブフィールド、7bitのリソースインデックスフィールド、1bitのリザーブフィールドであることをデバイズしている。バイトに従ってのリードが実現し、処理が簡素化できる。

もし、上記のようにSTAに基づいて報告する方式が採用すると、図4に示す独立リソースのリクエストフラームのフレーム本体の一部を変えて、フレーム本体の一部にSTAIDとリソースインデックスをパッケージしてよい。なお、多種の精度のリソースリストを採用すれば、フレーム本体にリソースリストのタイプを示すフィールドを更に設定しよい。本発明の実施例はここで贅言しない。

前記CAPは前記STAのために第2伝送リソースをアロケートした後、ユニキャスト方式でリソース伝送リクエスト応答を送信することができ、そのうち、第2リソース伝送の指示がキャリーされる。前記STAは予め設定されたルールに従って対応の応答を受信する。例えば、STAIDが正しく受信する根拠とし、即ち、STAはリソース伝送リクエストの中に自身のSTAIDをキャリーし、CAPは前記STAのためにリソース伝送リクエスト応答を返信する時、リソース伝送リクエスト応答に前記STAのSTAIDをキャリーすることができる。STAは、受信した伝送リソース応答の中にその自身のSTAIDがキャリーされたかどうかを判断することにより、正しく対応の応答を受信するかどうかを確認する。

前記CAPは伝送制御チャンネルでリソース伝送リクエスト応答を送信することができる。そのうち、第2リソース伝送の指示がキャリーされる。それに応じて、前記STAが前記伝送制御チャンネルで前記リソース伝送リクエスト応答を受信でき、そのなかからアロケートされた第2伝送リソースを取得する。当然なら、ほかの実施例では、ほかのチャンネルで、例えばダウンリンク通信チャンネルで、リソース伝送リクエスト応答を発送することもできる。本発明はここで制限されるものではないことが望まれている。

上記のポーリングアロケートを実現するために、実施例に関わる本発明は、リソースのアロケートのためのCAPを提供し、図11に示すように、下記の構成を含む。

第1リソースアロケートモジュール1101は、少なくとも１つのSTAをポーリングして、ポーリングされた各のSTAのために第1伝送リソースをアロケートすることに用いられているものである。
第1送信モジュール1102は、第1リソース伝送の指示をポーリングされたSTAに送信することに用いられているものである。

第2リソースアロケートモジュール1103は、リソース伝送リクエストを受信し、対応のSTAのために第2伝送リソースをアロケートすることに用いられているものである。

第2送信モジュール1104は、リソース伝送リクエスト応答をSTAに送信することに用いられているもので、前記リソース伝送リクエスト応答に第2リソース伝送の指示がキャリーされる。

前記第1リソース伝送リクエストは、STAがリソース伝送リクエストを送信することに用いられているものである。

前記第2リソース伝送リクエストは、STAがデータを送信することに用いられているものである。

前記第2リソースアロケートモジュール1103は業務フローに基づいて報告するリソース伝送リクエストの処理に対応可能である。業務フローに基づいて報告するリソースリクエストは次の構成を含む。前記リソース伝送リクエストの中にはSTAのマークと、１つあるいは複数の業務フローのマークおよび各の業務フローのためにリクエストされる帯域幅リソースのサイズを含む。前記第2リソースモジュール1103は、前記リソース伝送リクエストを解析することにより、STAの各の業務フローおよび各の業務フローのリソースの需要状況を取得することができることが望まれている。

前記リソース伝送リクエストの中には各の業務フローのためにリクエストされる帯域幅リソースのタイプを更に含む。前記第2リソースアロケートモジュール1103は、STAが必要に応じて各の業務フローのためにリクエストされる帯域幅リソースのタイプを選ぶことに対応可能で、リソースリクエストはより柔軟で、人間性が格別に向上することが望まれている。

前記第2リソースアロケートモジュール1103はSTAに基づいて報告するリソース伝送リクエストの処理に対応可能である。前記STAに基づいて報告するリソース伝送リクエストには、前記リソース伝送リクエストのSTAのマークおよび前記STAに必要となる総計帯域幅リソースのサイズを含む。前記第2リソースアロケートモジュール1103は前記リソース伝送リクエストを解析することにより、前記STA総計リソースの需要状況を識別することができることが望まれている。

前記リソース伝送リクエストの中にSTAが要る帯域幅リソースのタイプを更に含むことが望まれている。前記第2リソースアロケートモジュール1103にリクエストされる帯域幅リソースのタイプSTAを指示するようにアロケートし、リソースリクエストはより柔軟で、人間性が格別に向上する。

前記帯域幅リソースの予め設定されたリソースリストの中のインデックスでリクエスト帯域幅リソースのサイズを指示することができることが望まれている。

予め設定された前記リソースリストに多種の精度範囲のリソースリストを含むことが望まれている。

前記第1送信モジュール1102は、伝送制御チャンネルで第1リソース伝送の指示を送信することができることが望まれている。

前記第1送信モジュール1102は、ユニキャスト方式で第1リソース伝送の指示を送信することができることが望まれている。

前記第2送信モジュール1104は伝送制御チャンネルでリソース伝送リクエスト応答を送信することができることが望まれている。

前記第2送信モジュール1104は、ユニキャスト方式でリソース伝送リクエスト応答を送信することができることが望まれている。

前記CAPは、下記の構成をさらに含むこともできることが望まれている。
判断モジュール1105は、現行にアロケートできる伝送リソースの有無を判断し、現行にアロケートできる伝送リソースがあった時、前記第1リソースモジュール1101へリソースアロケート指令を発送する。前記第1リソースアロケートモジュール1101は、前記リソースアロケート指令を受信した後に、ポーリングを実行する。

実施例４
実施例４に関わる本発明は、リソースアロケート方法を提供する。CAPが自発的にSTAにデータ通信のためのリソースをアロケートする。図12に示すように、下記のステップを含む。
ステップS1201：CAPは少なくとも１つのSTAをポーリングし、ポーリングされた各のSTAに第1伝送リソースをアロケートする。
ステップS1202：前記CAPは第1リソース伝送の指示をポーリングされたSTAに送信する。
ステップS1203：前記STAは第1リソース伝送の指示を受信する。
ステップS1204：前記STAは前記第1伝送リソースを用いてデータを送信する。

実施例3に記載されているリソースアロケート方法との違いは、CAPが直接にSTAにデータ伝送に用いられるリソースをアロケートし、STAからリソースリクエストを出してデータ伝送のリソースを受信することが不要である。

上記のポーリングアロケートを実現するため、実施例４に関わる本発明は、リソースのアロケートを実現するために用いられているCAPを提供する。図13に示すように、下記の構成を含む。

第1リソースアロケートモジュール1301は、少なくとも１つのSTAをポーリングし、ポーリングされら各のSTAのために第1伝送リソースをアロケートすることに用いられているものである。
第1送信モジュール1302は、第1リソース伝送の指示をポーリングされたSTAに送信することに用いられているものである。

前記第1伝送リソースは、STAがデータを送信することに用いられているものである。

前記第1送信モジュール1302は、伝送制御チャンネルで第1リソース伝送の指示を送信することができることが望まれている。

前記第1送信モジュール1302は、ユニキャスト方式で第1リソース伝送の指示を送信することができることが望まれている。

前記CAPは次の構成をさらに含むこともできることが望まれている。

判断モジュール1303は、現行にアロケートできる伝送リソースの有無を判断し、現行にアロケートできる伝送リソースが有する時、前記第1リソースモジュール1301へリソースアロケート指令を発送する。前記第1リソースアロケートモジュール1301は、リソースアロケート指令を受信後に、ポーリングを実行する。

実施例５
実施例５に関わる本発明は、リソースをアロケートする方法をさらに提供する。CAPが自発的に少なくとも１つのSTAのためにリソース伝送リクエストのリソースをポーリングでアロケートする。具体的には、図1４に示すように、下記のステップを含む。
ステップS1401：CAPは少なくとも１つのSTAをポーリングし、ポーリングされた且つリソースのアロケートの周期が到達した各のSTAのために第1伝送リソースをアロケートする。
ステップS1402：前記CAPは第1リソース伝送の指示を前記ポーリングされたSTAに送信する。
ステップS1403：前記STAは前記第1リソース伝送の指示を受信する。
ステップS1４04：前記STAは前記第1リソースを用いてリソース伝送リクエストを送信する。
ステップS1405：前記CAPは前記リソース伝送リクエストを受信し、対応のSTAのために第2伝送リソースをアロケートする。
ステップS1406：前記CAPはリソース伝送リクエスト応答を対応のSTAに送信し、前記リソース伝送リクエスト応答の中には第2リソース伝送の指示がキャリーされる。
ステップS1407：前記STAは前記受信リソース伝送リクエスト応答を受信する。
ステップS1408：前記STAは前記第2伝送リソースを用いてデータを送信する。

本発明の上記の実施例には、実施例3に記載されているポーリングアロケート方案をもとにSTAリソースのアロケート周期に対してを監視し、既にリソースのアロケートの周期に達したSTAに対して優先にリソースをアロケートし、従って、リソースのアロケートがより合理である。

CAPはSTAのリソースのアロケートの周期を維持し、STAのために第1伝送リソースをアロケートした後、第1伝送リソースがアロケートされたSTAに対して、リソースのアロケートの周期を再計算する。

具体的には、前記CAPはタイマーを用いてSTAのリソースのアロケート周期を維持する。タイマーがタイムアウトになったとき、STAが配置リソースのアロケートの周期に達していると認め、前記STAへリソースをアロケートし、タイマーを再起動する。タイムアウトではないと、前記STAが配置リソースのアロケートの周期に達していないと判断し、前記STAのためにリソースをアロケートしない。

STAの現行の業務フロータイプのパラメーターによってSTAのリソースのアロケートの周期を計算する。前記業務フローのタイプのパラメーターは、プライオリティや、遅延予算や、パケット紛失率の予算などのパラメーターを含む。従って、業務フローの実際の需要によって設計し、業務フローの需要を満足し、リソースをより合理にアロケートすることが望まれている。

上記のポーリングアロケートを実現するために、実施例に関わる本発明は、リソースのアロケートのためのCAPを提供し、図15に示すように、下記の構成を含む。

第1リソースアロケートモジュール1501は、少なくとも１つのSTAをポーリングして、ポーリングされた且つリソースのアロケートの周期が到達した各のSTAのために第1伝送リソースをアロケートすることに用いられているものである。

第1送信モジュール1502は、第1リソース伝送の指示をポーリングされたSTAに送信することに用いられているものである。

第2リソースアロケートモジュール1503は、リソース伝送リクエストを受信し、対応のSTAのために第2伝送リソースをアロケートすることに用いられているものである。

第2送信モジュール1504は、リソース伝送リクエスト応答をSTAに送信することに用いられているもので、前記リソース伝送リクエスト応答に第2リソース伝送の指示がキャリーされる。

好ましくは、前記第1リソースアロケートモジュール1501は、第1伝送リソースがポーリングされたSTAのためにリソースアロケート周期を再算定することができる。

具体的には、前記第1リソースアロケートモジュール1501はタイマーを利用してSTAのリソースのアロケートの周期を維持することができる。タイマーがタイムアウトに達したとき、STAがリソースのアロケートの周期に達していると認められ、STAのためにリソースをアロケートするとともにタイマーを再起動する。タイムアウトでないと、STAがまだリソースのアロケートの周期に達していない認められ、前記STAのためにリソースをアロケートしない。

前記第1リソースアロケートモジュール1501は、STAの現行の業務タイプのパラメータに応じてSTAのリソースのアロケート周期を計算する。前記業務タイプのパラメーターは、プライオリティや、遅延予算や、パケット紛失率予算などのパラメーターを含むことが望まれている。

前記第2リソースアロケートモジュール1503は業務フローに基づいて報告するリソース伝送リクエストの処理に対応可能である。業務フローに基づいて報告するリソースリクエストは次の構成を含む。前記リソース伝送リクエストの中にはSTAのマークと、１つあるいは複数の業務フローのマークおよび各の業務フローのためにリクエストされる帯域幅リソースのサイズを含む。前記第2リソースモジュール1503は、前記リソース伝送リクエストを解析することにより、STAの各の業務フローおよび各の業務フローのリソースの需要状況を取得することができることが望まれている。

前記リソース伝送リクエストの中には各の業務フローのためにリクエストされる帯域幅リソースのタイプを更に含む。前記第2リソースアロケートモジュール1503は、STAが必要に応じて各の業務フローのためにリクエストされる帯域幅リソースのタイプを選ぶことに対応可能で、リソースリクエストはより柔軟で、人間性が格別に向上することが望まれている。

前記第2リソースアロケートモジュール1503はSTAに基づいて報告するリソース伝送リクエストの処理に対応可能である。前記STAに基づいて報告するリソース伝送リクエストには、前記リソース伝送リクエストのSTAのマークおよび前記STAに必要となる総計帯域幅リソースのサイズを含む。前記第2リソースアロケートモジュール1503は前記リソース伝送リクエストを解析することにより、前記STA総計リソースの需要状況を識別することができることが望まれている。

前記リソース伝送リクエストの中にSTAが要る帯域幅リソースのタイプを更に含むことが望まれている。前記第2リソースアロケートモジュール1503にリクエストされる帯域幅リソースのタイプSTAを指示するようにアロケートし、リソースリクエストはより柔軟で、人間性が格別に向上する。

予め設定されたリソースリストの中のインデックスでリクエスト帯域幅リソースのサイズを指示することが望まれている。

前記予め設定されたリソースリストは多種の精度範囲のリソースリストを含むことが望まれている。

前記第1送信モジュール1502は、伝送制御チャンネルで前記第1リソース伝送の指示を送信することができることが望まれている。

前記第1送信モジュール1502は、ユニキャスト方式で前記第1リソース伝送の指示を送信することができることが望まれている。

前記第2送信モジュール1504は、伝送制御チャンネルで前記リソース伝送リクエスト応答を送信することができることが望まれている。

前記第2送信モジュール1504は、ユニキャスト方式で前記リソース伝送リクエスト応答を送信することができることが望まれている。

前記CAPは次の構成をさらに含むこともできることが望まれている：
判断モジュール1505は、現行にアロケートできる伝送リソースの有無を判断することに用いられ、現行にリソース伝送アロケートが有する時、前記第1リソースモジュール1501へリソースアロケート指令を発送する。前記第1リソースモジュール1501は、リソースアロケート指令を受信後した後に、ポーリング処理を実行する。

実施例６
実施例６に関わる本発明は、リソースをアロケートする方法をさらに提供する。CAPが自発的に少なくとも１つのSTAのためにリソース伝送リクエストのリソースをポーリングでアロケートする。具体的には、図1６に示すように、下記のステップを含む。
ステップS1601：CAPは少なくとも１つのSTAをポーリングし、ポーリングされた且つリソースのアロケートの周期が到達した各のSTAのために第1伝送リソースをアロケートする。
ステップS1602：前記CAPは第1リソース伝送の指示を前記ポーリングされたSTAに送信する。
ステップS1603：前記STAは前記第1リソース伝送の指示を受信する。
ステップS1604：前記STAは前記第1リソースを用いてリソース伝送リクエストを送信する。

実施例５に記載されているリソースアロケート方法との違いは、CAPが直接にSTAにデータ伝送に用いられるリソースをアロケートし、STAからリソースリクエストを出してデータ伝送のリソースを受信することが不要である。

上記のポーリングアロケートを実現するため、実施例に関わる本発明は、リソースのアロケートを実現することに用いられるCAPを提供する。図17に示すように、下記の構成を含む。

第1リソースアロケートモジュール1701は、少なくとも１つのSTAをポーリングし、ポーリングされた各のSTAに第1伝送リソースをアロケートすることに用いられているものである。

第1送信モジュール1702は、第1リソース伝送の指示をポーリングされたSTAに送信することに用いられているものである。

前記第1リソース伝送リクエストは、STAがデータを送信することに用いられているものである。

前記第1リソースアロケートモジュール1701は、第1伝送リソースがポーリングされたSTAのためにリソースアロケート周期を再算定することができる。

具体的には、前記第1リソースアロケートモジュール1701はタイマーを利用してSTAのリソースのアロケートの周期を維持することができる。タイマーがタイムアウトに達したとき、STAがリソースのアロケートの周期に達していると認められ、STAのためにリソースをアロケートするとともにタイマーを再起動する。タイムアウトでないと、STAがまだリソースのアロケートの周期に達していない認められ、前記STAのためにリソースをアロケートしない。

前記第1リソースアロケートモジュール1701は、STAの現行の業務タイプのパラメータに応じてSTAのリソースのアロケート周期を計算する。前記業務タイプのパラメーターは、プライオリティや、遅延予算や、パケット紛失率予算などのパラメーターを含むことが望まれている。

前記第1送信モジュール1702は、伝送制御チャンネルで第1リソース伝送の指示を送信することができることが望まれている。

前記第1送信モジュール1702は、ユニキャスト方式で第1リソース伝送の指示を送信することができることが望まれている。

前記CAPは次の構成をさらに含むことが望まれている。

判断モジュール1703は、現行にアロケートできる伝送リソースの有無を判断し、現行にアロケートできる伝送リソースが有する時、前記第1アロケートモジュールにリソースアロケート指令を発送する。前記第1アロケートモジュールは、前記リソースアロケート指令を受信した後に、ポーリングを実行する。

実施例７
上記の実施例1〜6に関わる本発明は、STAがアップリンクデータを取得するに必要なリソースの取得方式が記載されている。競合リソースリクエスト方法（実施例1）と、チャネル連携リソースリクエスト方法（実施例2）と、ポーリングアロケート方式（実施例3〜6）を含む。

競合リソースリクエスト方法とチャネル連携リソースリクエスト方法は、STAが自発的にリクエストを発起する。そのうち、競合リソースリクエスト方法は、STAが競合方式で自発的にリクエストしてリソースを得ることであり、アップリンク伝送リソースのない場合に適用される。チャネル連携リソースリクエスト方法は、STAがリソースリクエスト情報をデータフレームの中に載せてアップリンクデータと一緒に伝送することであり、現行にデータアップリンクリソースがある場合に適用され、リソース伝送リクエストのインタラクティブ回数を減らすことができ、システム全般のリソースのアロケートスピードが向上できる。ポーリングアロケート方式は、CAPが自発的にSTAのためにリソースをアロケートする方式を提供することであり、STAによる自発的リクエストを発起することが不要で、合理的にリソースを分析することができる。利用可能であるとき、自発的にSTAのためにアロケートを行い、リソース伝送リクエストのインタラクティブ回数を減らすことができ、システム全般のリソースのアロケートスピードが向上できる。そのため、具体的なケースに応じて、この3種のリソースアロケート方式を合理的に融合させることができれば、更に優れている効果が出る。実施例７に関わる本発明は、ここで下記のような合理的な融合方式を提供する。

CAPは、利用可能なリソースが有する時、自発的にSTAのためにリソースをアロケートし、STAがCAPによりアロケートされたリソースを受信した後、前記アップリンク伝送リソースを用いて伝送リクエストを送信してよく、またはデータを直接に送信してもよい。CAPはSTAのためにリソースをアロケートしない時、現行にアップリンクリソースがないとき、STAは競合方式でリソース伝送リクエストを発起する。現行にアップリンクリソースがあるとき、チャネル連携方式でリソースリクエストをデータフレームの中に載せて送信する。

好ましくは、本発明実施例では、CAPがSTAのためにアロケートするデータアップリンクに用いられるリソースは、STAIDに基づいて実現されるものである。即ち、CAPはSTAによりリクエストされたリソース（FIDリクエストまたはSTAリクエストに基づき）に応じて、STAのためにアロケートした総計リソースを計算し、リソースの業務フローの間のアロケートはSTA側により実施される。即ち、STAはそのアロケートされた総計リソースを把握する上、内部調整によって、業務フローの間に2次アロケートを行って、すなわち伝送リソースを複数の業務フローの間にアロケートする。その後、前記複数の業務フローが対応の伝送リソースでデータを伝送するように制御する。リソースを業務フローの間にアロケートする方式が必要に応じて設定される。例えば、プライオリティ別によりアロケートや、均一にアロケートなど。本発明はここで制限されるものではない。上記の2次アロケート方式を採用すると、CAP側の操作が簡素化し、STA側が一部のリソースアロケート任務を分担し、複数のSTAを有するシステムにとって、システム全般のリソースアロケートのスピードが向上できる。また、STAは必要に応じてリソースアロケートの策略をデバイズすることができる。例えば、業務フローのプライオリティを設定し、リソースアロケートをより柔軟にし、多様なユーザーの需要を満たすことができ、ユーザーの体験効果が格別に高まるようにする。

好ましくは、前記STAがそのアロケートのリソースを受信した後、前記アロケートリソースが需要に満足するかどうかを判断する。満足であると、伝送リソースを用いてデータを送信する。満足でないと、前記伝送リソースを用いて送信待ちデータの中の一部を送信するとともに、現行の必要な帯域幅リソースによって、リソース伝送リクエストを再実行する。リソースリクエストの再実行する際、アップリンクデータがあるため、チャネル連携リソースリクエスト方法でリソースリクエストを実現することが望まれている。

アロケートされたリソースとリクエストされたリソースとを比較し、需要が満足するかどうか判断する。もし、アロケートされたリソースがリクエストされたリソースより小さいとき、需要が満足しないと認められる。ではないと、需要が満足すると認められる。

前記STAは、リクエストメッセージを送信した後の予め設定された期間に、対応の応答を受信しないと、今回のリクエストが失敗したと認められ、リソース伝送リクエストを再実行することが望まれている。好ましくは、本発明の実施例では、フレームカウント方式でタイマー機能を実現し、タイマー機能をより精確にし、すぐに処理できる。

好ましくは、競合リソースリクエスト方式でリソースをリクエストする時、CAPは第2リソース伝送リクエストを受信したあと、応答（ACK）メッセージをリターンすることにより、STAへ既に前記第2リソース伝送リクエストを受信したことを知らせる。STAは第1リソース伝送リクエストを送信したあと、予め設定された第1最大待ちフレームの間隔を超えた後に、第1リソース伝送リクエスト応答を受信していない場合には、今回のリソース送信が失敗したと認められ、リソース伝送を再びリクエストしなければならない。または、第2リソース伝送リクエストを送信したあと、予め設定された第2最大待ちフレームの間隔を超えた後に、第2リソース伝送リクエスト応答を受信していない場合には、今回のリソース送信に失敗したと認められ、リソース伝送を再びにリクエストしなければならない。

チャネル連携リソースリクエスト方法でリソース伝送リクエストを実現する時、リソースリクエスト情報をキャリーするデータフレームを送信した後、予め設定された第3最大待ちフレームの間隔を超えた後に、対応の応答を受信していない場合には、今回のリクエストが失敗したと認められ、リソース伝送リクエストを再実行する。

リソース伝送リクエストの再実行の具体的な方式について、現時のシーンによって確定し、現行にアップリンク伝送リソースがないとき、STAは競合方式でリソースリクエストを発起する。現行にアップリンク伝送リソースがあれば、チャネル連携方式でリソースリクエストをデータフレームの中に載せて送信する。

開示におけるステップの特定順序または段階は例示的な方法の実施例である。設計の好みベースで、過程の中のステップの特定順序または段階は、本開示の保護範囲から脱離することなく新たに振り当てることができると理解すべきである。特許請求の範囲における方法請求項は例示的な順序により各ステップの要素が挙げられるが、記載している特定順序または段階に限られることではない。

前記の詳しい説明では、各特徴を共にシグナル実施形態に組み合わせて、本開示を簡素化するが、このような開示方法を下記の意図の反映に説明するわけではなく、即ち、要求される保護の主題の実施形態は各請求項に明瞭に記載されている特徴よりも多い。その逆に、添付される特許請求の範囲で反映している通り、本発明は開示されるシグナル実施形態の全ての特徴よりも少ない状態に属する。このため、添付される特許請求の範囲が特に明瞭に詳細な説明に合弁され、そのうち、各請求項が独自に本発明の独立の好ましい技術案とする。

前記の記述は１つまたは複数の実施例の例を含む。当然ながら、前記の実施例を説明するために、部品または方法に対するすべての可能な組み合わせの説明は不可能であるが、当業者は各実施例を更に組み合わせ・配列できることを理解すべきである。このため、本文では説明する実施例は、添付される特許請求の範囲の保護範囲における全てのこのような変更、修正と変形を含む。また、明細書または特許請求の範囲に使用される「含める」という用語については、当該用語の表現する方式は「含む」という用語と類似し、請求項では接続用語で説明する「含む」の通りである。なお、特許請求の範囲及び明細書におけるいずれかの「または」という用語は「非排他的なまたは」を表すものである。

Claims

リソースをリクエストする方法であって、その特徴は、
リソース伝送リクエストをデータフレームの中にキャリーし、
リソース伝送リクエストをキャリーする前記データフレームを送信する。
請求項１に記載の方法において、
リソース伝送リクエスト応答を受信し、前記リソース伝送リクエスト応答にはソース伝送指示がキャリーされ、
前記伝送リソースを用いてデータを送信することを特徴とする。
請求項２に記載の方法において、
リソース伝送リクエスト応答を受信した後、前記伝送リソースを用いてデータを送信する前、前記ソース伝送指示に従って各の業務フローの間にリソースをアロケートすることを特徴とする。
請求項１に記載の方法において、
前記リソース伝送リクエストをデータフレームのフレーム本体の中にキャリーすることを特徴とする。
請求項１に記載の方法において、
前記データフレームのフレームヘッドの中に、チャネル連携リクエストの指示が設けられ、伝送リソースリクエストの存在を指示することに用いられていることを特徴とする。
請求項１に記載の方法において、
前記リソース伝送リクエストの中には、１つあるいは複数の業務フローのマークおよび各の業務フローのためにリクエストされる帯域幅リソースのサイズをパッケージすることを特徴とする。
請求項６に記載の方法において、
前記リソース伝送リクエストの中には、予め設定されたリソースリストの中のインデックスで帯域幅リソースのサイズを指示することを特徴とする。
請求項７に記載の方法において、
前記リソース伝送リクエストの中に予め設定されたリソースリストのタイプがキャリーされ、異なるタイプのリソースリストが異なる精度範囲に対応することを特徴とする。
請求項１に記載の方法において、
リソース伝送リクエストをキャリーする前記データフレームを送信したあと、予め設定された最大待ちフレーム間隔を超えたあと、今回のリソースリクエストが失敗したと認められ、リソース伝送リクエストを再びに発起する必要ことを特徴とする。
リソースをリクエストする方法であって、その特徴は、
リソース伝送リクエストをキャリーするデータフレームを受信し、
前記データフレームの中から前記リソース伝送リクエストを解析し、
前記リソース伝送リクエストに応じて、対応のサイトSTAのために伝送リソースをアロケートし、
リソース伝送リクエスト応答をSTAに送信し、
前記リソース伝送リクエスト応答の中にがリソース伝送の指示がキャリーされる。
請求項１０に記載の方法において、
前記データフレームのフレーム本体の中から前記リソース伝送リクエストを解析することを特徴とする。
請求項１１に記載の方法において、
データフレームのフレームヘッドを解析し、チャネル連携リクエストの指示を得ることにより、前記リソース伝送リクエストの存在を判断することを特徴とする。
請求項１０に記載の方法において、
前記リソース伝送リクエストの中には、１つあるいは複数の業務フローのマークおよび各の業務フローのためにリクエストされる帯域幅リソースのサイズをパッケージすることを特徴とする。
請求項１３に記載の方法において、
前記リソース伝送リクエストの中には、予め設定されたリソースリストの中のインデックスで帯域幅リソースのサイズを指示することを特徴とする。
請求項１４に記載の方法において、
前記リソース伝送リクエストの中に予め設定されたリソースリストのタイプがキャリーされ、異なるタイプのリソースリストが異なる精度範囲に対応することを特徴とする。
リソースリクエストに用いられるサイトSTAであって、その特徴は、
パッケージモジュールは、リソース伝送リクエストをデータフレームの中に載せることに用いられているものであり、
第１送信モジュールは、リソース伝送リクエストをキャリーするデータフレームを送信することに用いられているものである。
請求項１６に記載のSTAにおいて、
受信モジュールは、リソース伝送リクエスト応答を受信することに用いられ、
前記リソース伝送リクエスト応答の中にはリソース伝送の指示がキャリーされ、
第２送信モジュールは、前記リソース伝送の指示に従って対応の伝送リソースでデータを送信することに用いられているものである。
請求項１７に記載のSTAにおいて、
受信モジュールは、リソース伝送リクエスト応答を受信することに用いられ、前記リソース伝送リクエスト応答の中にはリソース伝送の指示がキャリーされ、
リソースアロケートモジュールは、前記受信モジュールと繋がり、前記リソース伝送の指示に従って各の業務フローの間にリソースをアロケートすることに用いられ、
第2送信モジュールは、前記リソースアロケートモジュールと繋がり、リソースのアロケートの結果によって対応の伝送リソースでデータを送信することに用いられている。
請求項１６に記載のSTAにおいて、
前記パッケージモジュールは、データフレームの中にチャネル連携リクエストの指示をさらにパッケージし、伝送リソースリクエストの存在を指示することに用いられている。
請求項１９に記載のSTAにおいて、
前記パッケージモジュールは、前記チャネル連携リクエストの指示をデータフレームのフレームヘッドに載せる。
請求項２０に記載のSTAにおいて、
前記パッケージモジュールは、データフレームヘッドの中に一つのフィールドを設定し、前記フィールドの値によってリソース伝送リクエストの存在を指示する。
請求項１６に記載のSTAにおいて、
前記パッケージモジュールは、前記リソース伝送リクエストをデータフレームのフレーム本体に載せる。
請求項２２に記載のSTAにおいて、
前記パッケージモジュールは、データフレームのフレーム本体に一つのフィールドを設定し、前記リソース伝送リクエストを載せる。
請求項１６に記載のSTAにおいて、
前記パッケージモジュールは、リソース伝送リクエストの中に１つあるいは複数の業務フローのマークおよび各の業務フローのためにリクエストされた帯域幅リソースのサイズをパッケージすることに用いられている。
請求項２４に記載のSTAにおいて、
前記パッケージモジュールは、予め設定されたリソースリストの中のインデックスで帯域幅リソースのサイズを指示することに用いられている。
請求項２５に記載のSTAにおいて、
前記パッケージモジュールは、リソース伝送リクエストの中にリソースリストのタイプを載せることに用いられ、異なるタイプのリソースリストが異なる精度範囲を有する。
請求項１７に記載のSTAにおいて、
再送信モジュールは、前記第1送信モジュールがリソース伝送リクエストをキャリーするデータフレームを送信したあと、タイマーをONにし、予め設定された最大待ち時間が超えたあと、前記受信モジュールがリソース伝送リクエスト応答を受信していない場合に、今回のリソースリクエストが失敗したと認められ、前記パッケージモジュールにデータの伝送がある時、前記リソース伝送リクエストをデータフレームの中に載せてリソース伝送リクエストを再びに発起する。
リソースリクエストに用いられるセンター・アクセスポイントCAPであって、
その特徴は、
リソース伝送リクエストをキャリーするデータフレームを受信する受信モジュールと、
前記データフレームの中から前記リソース伝送リクエストを解析することに用いられている解析モジュールと、
前記リソース伝送リクエストに応じて、対応のサイトSTAのために伝送リソースをアロケートするリソースアロケートモジュールと、
リソース伝送リクエスト応答をSTAに送信する送信モジュールと、
を含み、
前記リソース伝送リクエスト応答の中にがリソース伝送の指示がキャリーされる。
請求項２８に記載のCAPにおいて、
前記解析モジュールは、データフレームの中のチャネル連携リクエストの指示を解析することにより、リソース伝送リクエストの存在を識別する。
請求項２９に記載のCAPにおいて、
前記解析モジュールは、データフレームのフレームヘッドの中のチャネル連携リクエストの指示のフィールドを解析することにより、前記チャネル連携リクエストの指示を得る。
請求項２８に記載のCAPにおいて、
前記解析モジュールは、データフレームのフレーム本体を解析することにより、リソース伝送リクエストを得る。
請求項３１に記載のCAPにおいて、
前記解析モジュールは、データのフレーム本体におけるチャネル連携リソースリクエストフィールドを解析することにより、リソース伝送リクエストを得る。
請求項２８に記載のCAPにおいて、
前記リソース伝送リクエストの中には、１つあるいは複数の業務フローのマークおよび各の業務フローのためにリクエストされる帯域幅リソースのサイズを含み、
前記リソースアロケートモジュールは、前記リソース伝送リクエストにによって前記１つあるいは複数の業務フローのために帯域幅リソースをそれぞれにアロケートする。
請求項３３に記載のCAPにおいて、
前記帯域幅リソースのサイズは、前記帯域幅リソースの予め設定されたリソースリストにおけるインデックスで指示され、
前記リソースアロケートモジュールは、予め設定されたリソースリストを検索することにより、各の業務フローのためにリクエストされた帯域幅リソースのサイズを得る。
請求項３４に記載のCAPにおいて、
前記リソース伝送リクエストの中には、リソースリストのタイプがキャリーされ、
前記リソースアロケートモジュールは、インデックスによってリソースリストを検索する前に、事前にリソースリストのタイプによって対応の精度範囲のリソースリストをフィクスする。
請求項２８に記載のCAPにおいて、
前記送信モジュールは、伝送制御チャンネルで前記リソース伝送リクエスト応答を前記対応のSTAに送信する。
請求項２８に記載のCAPにおいて、
前記送信モジュールは、ブロードキャスト方式で前記リソース伝送リクエスト応答を前記対応のSTAに送信する。