特許 7405154 基地局、通信方法及び通信プログラム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2023-12-18

(45)【発行日】2023-12-26

(54)【発明の名称】基地局、通信方法及び通信プログラム

(51)【国際特許分類】

   H04W 48/16 20090101AFI20231219BHJP

   H04W 84/12 20090101ALI20231219BHJP

【ＦＩ】

H04W48/16 132

H04W84/12

【請求項の数】 5

(21)【出願番号】P 2021569694

(86)(22)【出願日】2020-01-10

(86)【国際出願番号】 JP2020000670

(87)【国際公開番号】W WO2021140651

(87)【国際公開日】2021-07-15

【審査請求日】2022-05-10

【前置審査】

(73)【特許権者】

【識別番号】000004226

【氏名又は名称】日本電信電話株式会社

(74)【代理人】

【識別番号】110003708

【氏名又は名称】弁理士法人鈴榮特許綜合事務所

(72)【発明者】

【氏名】岸田 朗

(72)【発明者】

【氏名】井上 保彦

(72)【発明者】

【氏名】永田 健悟

(72)【発明者】

【氏名】淺井 裕介

(72)【発明者】

【氏名】鷹取 泰司

【審査官】伊東 和重

(56)【参考文献】

【文献】特開平１１－２９８５３３（ＪＰ，Ａ）

【文献】国際公開第２０１８／１７５９１９（ＷＯ，Ａ１）

【文献】特開２０１４－０１７５４９（ＪＰ，Ａ）

【文献】特表２０１９－５３６３３４（ＪＰ，Ａ）

【文献】Suhwook Kim(LG)，Latency enhancement in multi-link，IEEE 802.11-19/1851r1，IEEE，2019年11月11日，[検索日 2023.06.20],インターネット＜URL:https://mentor.ieee.org/802.11/dcn/19/11-19-1851-01-00be-latency-enhancemen t-in-multi-link.pptx＞

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｈ０４Ｂ ７／２４－７／２６

Ｈ０４Ｗ ４／００－９９／００

(57)【特許請求の範囲】

【請求項1】

端末からデータ通信時の遅延に関する要求条件を含む第１フレームを受信した場合、前記要求条件を満たした通信が可能であるか否かを判定するデータ処理部と、
前記要求条件を満たした通信が可能であると判定した場合、許可通知を前記端末に送信する無線信号処理部と、を具備し、
前記データ処理部は、前記端末から前記要求条件に従い送信されるデータのバッファ状況に関する情報を含む第２フレームを受信した場合、前記バッファ状況及びトラヒック状況から、後の通信において前記要求条件を満たせない可能性があるか否かを判定し、
後の通信において前記要求条件を満たせない可能性があると判定した場合、前記端末との通信が優先されるように送信機会を制御する制御部をさらに具備する基地局。

【請求項2】

前記制御部は、前記バッファ状況に示されるデータ量が多いほど、前記端末に割り当てるＴＸＯＰ（Transmission Opportunity）期間を長くする、請求項１に記載の基地局。

【請求項3】

前記制御部は、前記端末との通信を優先するパラメータを含む、ポーリングフレーム、トリガーフレーム及びビーコン信号の少なくとも１つを用いて、前記端末の送信機会を制御する、請求項１又は請求項２に記載の基地局。

【請求項4】

端末からデータ通信時の遅延に関する要求条件を含む第１フレームを受信した場合、前記要求条件を満たした通信が可能であるか否かを判定し、
前記要求条件を満たした通信が可能であると判定した場合、許可通知を前記端末に送信し、
前記端末から前記要求条件に従い送信されるデータのバッファ状況に関する情報を含む第２フレームを受信した場合、前記バッファ状況及びトラヒック状況から、後の通信において前記要求条件を満たせない可能性があるか否かを判定し、
後の通信において前記要求条件を満たせない可能性があると判定した場合、前記端末との通信が優先されるように送信機会を制御する、通信方法。

【請求項5】

コンピュータに、
端末からデータ通信時の遅延に関する要求条件を含む第１フレームを受信した場合、前記要求条件を満たした通信が可能であるか否かを判定するデータ処理機能と、
前記要求条件を満たした通信が可能であると判定した場合、許可通知を前記端末に送信する無線信号処理機能と、を実現させるための通信プログラムであって、
前記データ処理機能は、前記端末から前記要求条件に従い送信されるデータのバッファ状況に関する情報を含む第２フレームを受信した場合、前記バッファ状況及びトラヒック状況から、後の通信において前記要求条件を満たせない可能性があるか否かを判定し、
後の通信において前記要求条件を満たせない可能性があると判定した場合、前記端末との通信が優先されるように送信機会を制御する制御機能をさらに具備する、通信プログラム。

【発明の詳細な説明】

【技術分野】

【0001】

実施形態は、端末、基地局、通信方法及び通信プログラムに関する。

【背景技術】

【0002】

無線ＬＡＮ（Local Area Network）の基地局と端末とは、ＣＳＭＡ／ＣＡ（Carrier Sense Multiple Access with Collision Avoidance）を用いてチャネルにアクセスし、無線信号を送信する。ＣＳＭＡ／ＣＡでは、基地局及び端末は、アクセスパラメータによって規定された時間を待ちつつ、キャリアセンスにより、他の端末等によってチャネルが使用中でないことを確認した上で無線信号を送信する。

【0003】

無線ＬＡＮにおける優先制御方式の１つとして、ＥＤＣＡ（Enhanced Distribution Channel Access）が規定されている。ＥＤＣＡでは、上位層からのデータが４つのアクセスカテゴリ（ＡＣ）、すなわちＡＣ＿ＶＯ（Voice）、ＡＣ＿ＶＩ(Video)、ＡＣ＿ＢＥ(Best effort)、ＡＣ＿ＢＫ（Background）の何れかに分類される。そして、ＥＤＣＡでは、アクセスカテゴリごとにＣＳＭＡ／ＣＡが行われる。ＥＤＣＡでは、アクセスパラメータは、ＡＣ＿ＶＯ、ＡＣ＿ＶＩ、ＡＣ＿ＢＥ、ＡＣ＿ＢＫの順で無線信号の送信が相対的に優先されるように割り当てられている。

【先行技術文献】

【非特許文献】

【0004】

【文献】IEEE Std 802.11-2016, “10.22.2 HCF contention based channel access （EDCA）”, 7 December 2016

【発明の概要】

【発明が解決しようとする課題】

【0005】

ＥＤＣＡにより、トラヒック間での相対的な優先付けがされる。ここで、例えばネットワークゲームや工業用ロボットの制御のようなＲＴＡ（Real-Time Application）は、アプリケーション毎の絶対的な遅延やジッタの要求条件を有していることがある。相対的な優先付けだけでは、ＲＴＡを利用可能か分からない、又は、ＲＴＡを利用可能とするための制御ができるかわからない。

【課題を解決するための手段】

【0006】

一態様の端末は、データ処理部と、無線信号処理部とを含む。データ処理部は、データ通信時の遅延に関する要求条件を含み、前記要求条件を満たした通信が可能であるか否かを基地局に問い合わせる第１フレームを生成する。無線信号処理部は、前記第１フレームを送信する。

【発明の効果】

【0007】

実施形態によれば、要求条件に対応した無線通信環境を提供することができる。

【図面の簡単な説明】

【0008】

【図1】図１は、本実施形態に係る通信システム構成の一例を示す図である。

【図2】図２は、基地局のハードウェア構成の一例を示す図である。

【図3】図３は、端末のハードウェア構成の一例を示す図である。

【図4】図４は、基地局と端末との通信の際のＭＡＣ（Media Access Control）層の処理を示す図である。

【図5】図５は、基地局の機能ブロック図である。

【図6】図６は、端末の機能ブロック図である。

【図7】図７は、本実施形態に係る端末の動作を示すフローチャートである。

【図8】図８は、ネゴシエーションフレームのフォーマットの一例を示す図である。

【図9】図９は、状況通知フレームのフォーマットの一例を示す図である。

【図10】図１０は、本実施形態に係る基地局の動作を示すフローチャートである。

【図11】図１１は、基地局による端末の送信機会制御の一例を示すシーケンス図である。

【発明を実施するための形態】

【0009】

以下、実施形態を、図面に基づいて説明する。図１は、実施形態に係る通信システムの一例の構成を示す図である。通信システム１は、基地局１０と、複数の端末２０とを含む。基地局１０は、予め定められたサービスエリア内の端末２０と無線を介して通信する。図１では示されていないが、端末２０同士の間で通信が行われてもよい。

【0010】

次に、基地局１０のハードウェア構成の一例について図２を参照して説明する。基地局１０は、端末２０に対するアクセスポイント（ＡＰ）である。基地局１０は、固定されているものに限らず、移動体に搭載されているものであってもよい。
基地局１０は、プロセッサ１１と、ＲＯＭ（Read Only Memory）１２と、ＲＡＭ（Random Access Memory）１３と、無線モジュール１４と、ルータモジュール１５とを含む。

【0011】

プロセッサ１１は、基地局１０の全体の制御をする処理装置である。プロセッサ１１は、例えばＣＰＵ（Central Processing Unit）である。プロセッサ１１は、ＣＰＵに限るものではない。また、ＣＰＵに代えてＡＳＩＣ（Application Specific IC）等が用いられてもよい。また、プロセッサ１１は、１つでなく、２つ以上であってもよい。

【0012】

ＲＯＭ１２は、読み出し専用の記憶装置である。ＲＯＭ１２は、基地局１０の動作に必要なファームウェア、ソフトウェア、及び各種のプログラムを記憶する。
ＲＡＭ１３は、任意に書き込みできる記憶装置である。ＲＡＭ１３は、プロセッサ１１のための作業エリアとして使用され、ＲＯＭ１２に格納されているファームウェア等を一時的に記憶する。

【0013】

無線モジュール１４は、無線ＬＡＮ通信のために必要な処理を行うように構成されたモジュールである。無線モジュール１４は、例えばプロセッサ１１から転送されたデータからＭＡＣ（Media Access Control）フレームを構成し、構成したＭＡＣフレームを無線信号に変換して端末２０に送信する。また、無線モジュール１４は、端末２０から無線信号を受信し、受信した無線信号からデータを取り出して例えばプロセッサ１１に転送する。

【0014】

ルータモジュール１５は、基地局１０が例えば図示しないサーバとネットワークを介して通信するために設けられている。なお、基地局１０は、必ずしもルータモジュール１５を有していなくてもよい。基地局１０は、無線通信又は有線通信によって基地局１０の外部に設けられたルータにアクセスし、このルータ経由でネットワークに接続するように構成されていてもよい。

【0015】

次に、端末２０のハードウェア構成の一例について図３を参照して説明する。端末２０は、スマートフォン、タブレット端末等の端末装置（ＳＴＡ）である。端末２０は、携帯端末であってもよいし、移動体に搭載される端末であってもよいし、固定された端末であってもよい。
端末２０は、プロセッサ２１と、ＲＯＭ２２と、ＲＡＭ２３と、無線モジュール２４と、ディスプレイ２５と、ストレージ２６とを含む。

【0016】

プロセッサ２１は、端末２０の全体の制御をする処理装置である。プロセッサ２１は、例えばＣＰＵである。プロセッサ２１は、ＣＰＵに限るものではない。また、ＣＰＵに代えてＡＳＩＣ等が用いられてもよい。また、プロセッサ２１は、１つでなく、２つ以上であってもよい。

【0017】

ＲＯＭ２２は、読み出し専用の記憶装置である。ＲＯＭ２２は、端末２０の動作に必要なファームウェア、ソフトウェア及び各種のプログラムを記憶する。
ＲＡＭ２３は、任意に書き込みできる記憶装置である。ＲＡＭ２３は、プロセッサ２１のための作業エリアとして使用され、ＲＯＭ２２に格納されているファームウェア等を一時的に記憶する。

【0018】

無線モジュール２４は、無線ＬＡＮ通信のために必要な処理を行うように構成されたモジュールである。無線モジュール２４は、例えばプロセッサ２１から転送されたデータから無線通信のためのＭＡＣフレームを構成し、構成したＭＡＣフレームを無線信号に変換して基地局１０に送信する。また、無線モジュール２４は、基地局１０から無線信号を受信し、受信した無線信号からデータを取り出して例えばプロセッサ２１に転送する。

【0019】

ディスプレイ２５は、各種の画面を表示する表示装置である。ディスプレイ２５は、液晶ディスプレイ、有機ＥＬディスプレイ等であってよい。また、ディスプレイ２５は、タッチパネルを備えていてもよい。
ストレージ２６は、ＨＤＤ（Hard Disk Drive）、ＳＳＤ（Solid State Drive）等の記憶装置である。ストレージ２６は、例えばプロセッサ２１によって実行される各種のアプリケーションを記憶する。

【0020】

次に、基地局１０と端末２０との通信の際のＭＡＣ層の処理について、図４の概念図を参照して説明する。図４では、送信側の処理と受信側の処理との両方が示されている。基地局１０と端末２０のうちの一方の無線モジュールが送信側の処理をするとき、他方の無線モジュールが受信側の処理をする。以下の例では、送信側と受信側の無線モジュールを区別せずに記載する。

【0021】

まず、送信側の処理について説明する。ステップＳ１０において、無線モジュールは、Ａ－ＭＳＤＵアグリゲーションを行う。具体的には、無線モジュールは、アプリケーション層等の上位層から入力される複数のデータを結合してＡ－ＭＳＤＵ（Aggregate-MAC service data unit）を生成する。

【0022】

ステップＳ１１において、無線モジュールは、Ａ－ＭＳＤＵにシーケンスナンバー（ＳＮ）を割り当てる。シーケンスナンバーは、Ａ－ＭＳＤＵを特定するための一意の番号である。

【0023】

ステップＳ１２において、無線モジュールは、Ａ－ＭＳＤＵを複数のＭＰＤＵ（MAC protocol data unit）にフラグメント（分割）する。

【0024】

ステップＳ１３において、無線モジュールは、それぞれのＭＰＤＵを暗号化し、暗号化ＭＰＤＵを生成する。

【0025】

ステップＳ１４において、無線モジュールは、それぞれの暗号化ＭＰＤＵにＭＡＣヘッダと誤り検出符号（ＦＣＳ）とを付加する。誤り検出符号は、例えばＣＲＣ（Cyclic Redundancy Check）符号である。

【0026】

ステップＳ１５において、無線モジュールは、Ａ－ＭＰＤＵアグリゲーションを行う。具体的には、無線モジュールは、複数のＭＰＤＵを結合し、ＭＡＣフレームとしてのＡ－ＭＰＤＵ（Aggregate-MAC protocol data unit）を生成する。
ステップＳ１５の後、無線モジュールは、ＭＡＣフレームに対して物理層の処理を行う。つまり、無線モジュールは、ＭＡＣフレームに対して変調処理等を行って無線信号を生成し、無線信号を基地局１０に送信する。

【0027】

次に、受信側の処理について説明する。無線信号が受信されると、無線モジュールは、物理層の処理を行って無線信号からＭＡＣフレームを復元する。その後、無線モジュールは、図４に示すＭＡＣ層の処理を行う。

【0028】

ステップＳ２０において、無線モジュールは、Ａ－ＭＰＤＵデアグリゲーションを行う。具体的には、無線モジュールは、Ａ－ＭＰＤＵをＭＰＤＵの単位に分割する。

【0029】

ステップＳ２１において、無線モジュールは、誤り検出をする。例えば、無線モジュールは、ＣＲＣにより、無線信号の受信が成功したか否かを判定する。無線信号の受信が失敗したときには、無線モジュールは、再送要求をしてよい。このとき、無線モジュールは、ＭＰＤＵの単位で再送を要求してよい。一方、無線信号の受信が成功したときには、無線モジュールは、次の処理を行う。

【0030】

ステップＳ２２において、無線モジュールは、アドレス検出を行う。このとき、無線モジュールは、それぞれのＭＰＤＵのＭＡＣヘッダに記録されているアドレスにより、送られてきたＭＰＤＵが自分宛であるか否かを判定する。自分宛でないときには、無線モジュールは、次の処理を行わない。自分宛であるときには、無線モジュールは、次の処理を行う。

【0031】

ステップＳ２３において、無線モジュールは、暗号化されているＭＰＤＵを復号する。

【0032】

ステップＳ２４において、無線モジュールは、ＭＰＤＵに対してデフラグメントを行う。つまり、無線モジュールは、複数のＭＰＤＵからＡ－ＭＳＤＵを復元する。

【0033】

ステップＳ２５において、無線モジュールは、Ａ－ＭＳＤＵデアグリゲーションを行う。具体的には、無線モジュールは、Ａ－ＭＳＤＵをＭＳＤＵ単位のデータに復元する。
ステップＳ２５の後、無線モジュールは、データをＭＡＣ層の上位層に出力する。上位層は、例えばアプリケーション層である。

【0034】

次に、端末２０の機能ブロック図について図５を参照して説明する。
端末２０は、データ処理部２０１と、無線信号処理部２０２と、バッファ情報取得部２０３とを含む。データ処理部２０１と、無線信号処理部２０２と、バッファ情報取得部２０３とは、例えばプロセッサ２１及び無線モジュール２４によって実現される。

【0035】

データ処理部２０１は、例えば上位のアプリケーションから入力されたデータからＭＡＣフレームを構成する。また、データ処理部２０１は、無線信号処理部２０２から転送されてきたＭＡＣフレームからデータを復元する。このデータは、例えば上位のアプリケーションによって使用される。具体的に、データ処理部２０１は、アプリケーションにおいてデータ通信時の遅延に関する制約がある場合、データ通信時の遅延に関する要求条件を含み、要求条件を満たした通信が可能であるか否かを問い合わせるネゴシエーションフレーム（第１フレームともいう）を生成する。要求条件は、例えば、データ通信における遅延、ジッタなどの通信品質に関する要求を含む。

【0036】

本実施形態では、遅延に関する制約があるアプリケーションとして、例えば、オンラインゲーム（ネットワークゲーム）、工業用ロボットの制御アプリケーションといった、通信の遅延がサービスの品質に大きな影響があるアプリケーション（以下、リアルタイムアプリケーション又はＲＴＡともいう）を想定する。なお、これらのアプリケーションに限定されず、通信品質に関する要求があるアプリケーションであれば、本実施形態に開示される構成及び処理を適用できる。

【0037】

データ処理部２０１は、基地局１０から要求条件を満たした通信が可能である旨の通知を受けた場合、要求条件に従い送信されるデータのバッファ状況に関する情報を含む状況通知フレーム（第２フレームともいう）を生成する。バッファ状況は、例えば、データを送信する際の送信キューに蓄積されたデータ量に関する情報を示す。当該バッファにおいて測定された待ち時間やその平均値、ジッタ等の統計値を含めても良い。以降、バッファ状況には、蓄積されたデータ量の他に当該バッファに関して測定できる情報を含み、また、リアルタイムアプリケーションから入力されたデータが基地局１０に受信されるまでにかかる各遅延時間（バッファの最後尾に入力されてからバッファの先頭となるまでにかかった時間、チャネルがビジー状態であることから生じる送信待ち時間、送信失敗による再送のためにかかった時間等を含む）に関する情報を含んでもよい。本実施形態に係る送信キューは、ＥＤＣＡ方式による送信制御を行なう場合を想定したときの無線信号処理部２０２における送信キューであり、詳細は後述する。

【0038】

無線信号処理部２０２は、無線信号の送信又は受信のための処理を行う。例えば、無線信号処理部２０２は、データ処理部２０１で構成されたＭＡＣフレームを無線信号に変換し、無線信号を例えば基地局１０に送信する。具体的に、無線信号処理部２０２は、ネゴシエーションフレーム及び状況通知フレームを無線信号に変換して基地局１０に送信する。また、無線信号処理部２０２は、基地局１０から無線信号を受信し、受信した無線信号からＭＡＣフレームを抽出してデータ処理部２０１に転送する。

【0039】

ここで、無線信号処理部２０２は、例えば、優先制御方式としてＥＤＣＡ（Enhanced Distributed Channel Access）で無線信号を送信してもよい。この場合、無線信号処理部２０２は、アクセスカテゴリ（ＡＣ）ごとの送信キューＡＣ＿ＶＯ、ＡＣ＿ＶＩ、ＡＣ＿ＢＥ、ＡＣ＿ＢＫを含む。送信キューＡＣ＿ＶＯは、ＶＯ（Voice）にカテゴライズされたＭＡＣフレームを保持するためのキューである。送信キューＡＣ＿ＶＩは、ＶＩ（Video）にカテゴライズされたＭＡＣフレームを保持するためのキューである。送信キューＡＣ＿ＢＥは、ＢＥ（Best effort）にカテゴライズされたＭＡＣフレームを保持するためのキューである。送信キューＡＣ＿ＢＫは、ＢＫ（Background）にカテゴライズされたＭＡＣフレームを保持するためのキューである。
なお、アクセスカテゴリではなく、トラヒック種別（ＴＩＤ）毎にカテゴライズされてもよい。ＴＩＤは、端末２０が扱うアプリケーション（セッション）単位で付与される。前述したアクセスカテゴリへのマッピングは、ＴＩＤに基づいて行われてもよい。

【0040】

無線信号処理部２０２は、データ処理部２０１から転送されてきたＭＡＣフレームを、ＭＡＣフレームに記録されているデータのカテゴリに応じて、４つのアクセスカテゴリのうちのいずれかにマッピングする。このマッピングの結果に従って、無線信号処理部１０２は、ＭＡＣフレームを対応する送信キューに入力する。

【0041】

無線信号処理部２０２は、他の端末等による無線信号の送信がないことをアクセスカテゴリごとのキャリアセンスによって確認しつつ、アクセスカテゴリごとに設定されたアクセスパラメータによって規定された時間だけ送信を待つ。送信を待っている間に、他の端末等による無線信号の送信がなければ、無線信号処理部２０２は、対応する送信キューからＭＡＣフレームを取り出し、このＭＡＣフレームを無線信号に変換して送信する。

【0042】

ここで、アクセスパラメータは、ＶＯ、ＶＩ、ＢＥ、ＢＫの順で無線信号の送信が相対的に優先されるように割り当てられてもよい。アクセスパラメータは、ＣＷｍｉｎ、ＣＷｍａｘ、ＡＩＦＳ、ＴＸＯＰＬｉｍｉｔを含んでいてよい。ＣＷｍｉｎとＣＷｍａｘはそれぞれ、送信待ちの時間であるＣＷ（Contention Window）の最大値、最小値である。ＣＷｍｉｎとＣＷｍａｘが短いほど、送信キューは、送信権を得やすくなる。ＡＩＦＳ（Arbitration Inter Frame Space）は、任意に設定可能な無線信号のフレーム送信間隔である。ＡＩＦＳが小さいほど、送信キューの優先度が高くなる。ＴＸＯＰＬｉｍｉｔは、チャネルの占有時間であるＴＸＯＰ（Transmission Opportunity）の上限値である。ＴＸＯＰＬｉｍｉｔの値が大きいほど、一度の送信権で多くの無線信号を送信することができる。

【0043】

次に、基地局１０の機能ブロック図の一例について図６を参照して説明する。基地局１０は、データ処理部１０１と、無線信号処理部１０２と、管理部１０３と、通信制御部１０４とを含む。データ処理部１０１と、無線信号処理部１０２と、管理部１０３と、通信制御部１０４とは、例えばプロセッサ１１及び無線モジュール１４によって実現される。

【0044】

データ処理部１０１は、ネットワーク上のサーバから転送されたデータからＭＡＣフレームを生成する。また、データ処理部１０１は、無線信号処理部１０２から転送されてきたＭＡＣフレームからデータを復元する。具体的に、データ処理部１０１は、端末２０からネゴシエーションフレームを受信した場合、基地局１０と端末２０との間で要求条件を満たした通信が可能であるか否かを判定する。データ処理部は、要求条件を満たした通信が可能であると判定した場合、リアルタイムアプリケーションのデータに関するトラヒック（以下、ＲＴＡトラヒックという）を優先した通信を許可する旨を示すフレーム（許可通知ともいう）を生成する。また、データ処理部１０１は、端末２０から状況通知フレームを受信した場合、バッファ情報及び基地局１０のサービスエリアのトラヒック状況から、その後の通信において要求条件を満たせない可能性があるか否かを判定する。なお、基地局１０は、要求条件を満たせるか否かを判定した場合に、図示しないネットワーク上のサーバとしてリアルタイムアプリケーションの取扱いの可否を管理するものがあるときは、当該サーバに対して、判定結果を通知してもよい。たとえば、当該サーバが、モバイルネットワーク（４Ｇ，５Ｇ等）等からアクセスできる場合には、端末２０は当該通信回線によりリアルタイムアプリケーションの取扱いの可否を取得することも可能となる。最初に当該サーバにアクセスしてリアルタイムアプリケーションの要求条件を満たすとされた基地局１０に対して端末２０がネゴシエーションを開始することにより、成功率を高めることができる。

【0045】

無線信号処理部１０２は、無線信号の送信又は受信のための処理を行う。例えば、無線信号処理部１０２は、データ処理部１０１で構成されたＭＡＣフレームを無線信号に変換し、無線信号を端末２０に送信する。また、無線信号処理部１０２は、端末２０から無線信号を受信し、受信した無線信号からＭＡＣフレームを抽出してデータ処理部１０１に転送する。具体的に、無線信号処理部１０２は、許可通知を無線信号に変換して送信する。

【0046】

管理部１０３は、端末２０から送られてくる要求条件を管理する。例えば、管理部１０３は、端末２０と端末２０が送信した要求条件との対応関係を、例えばテーブルで管理しておき、必要なタイミングでテーブルに管理される情報を利用する。

【0047】

通信制御部１０４は、管理部１０３で管理される対応関係に基づき、要求条件での通信を希望する端末２０の通信において要求条件を満たせない可能性がある場合に、当該端末２０の通信が優先されるように、当該端末の送信機会を制御する。通信機会の制御方法については後述する。

【0048】

次に、本実施形態に係る端末２０の動作について図７のフローチャートを参照して説明する。なお、図７に示す端末２０の動作は、ステップＳ７０１からステップＳ７０３までのネゴシエーションフェーズと、ステップＳ７０４からステップＳ７０７までの通信フェーズとを含む。

【0049】

ステップＳ７０１では、データ処理部２０１が、ネゴシエーションフレームを生成する。ネゴシエーションフレームには、ここでは、リアルタイムアプリケーションが許容できる最大遅延の情報が含まれる。
ステップＳ７０２では、無線信号処理部２０２が、ネゴシエーションフレームを無線信号に変換して基地局１０に送信する。ネゴシエーションフレームの送信においては、例えばＣＳＭＡ／ＣＡ方式のアクセス制御により端末２０が送信権を得た場合に、無線信号処理部１０２が、ネゴシエーションフレームを無線信号にして送信する。

【0050】

ステップＳ７０３では、データ処理部２０１が、基地局１０から許可通知を受信したかどうかを判定する。端末２０が許可通知を受信した場合、ステップＳ７０４に進む。これにより、ネゴシエーションフェーズにおいて、ネゴシエーションが完了する。
一方、端末２０が許可通知を受信しない場合、つまり、一定期間許可通知がなくタイムアウトした場合又は拒否通知を受信した場合、ステップＳ７０２に戻り、同様の処理を繰り返す。これは、ネゴシエーションフレームを受けた時点でのチャネルの混雑状況によりＲＴＡトラヒックを優先することができないという判定がなされたのであり、別の時点ではチャネルに余裕があり、ＲＴＡトラヒックを優先することができる可能性があるからである。

【0051】

ステップＳ７０４では、通信フェーズにおいて、リアルタイムアプリケーションで生成されたデータ（以下、ＲＴＡデータという）が発生した場合を想定する。この場合、データ処理部２０１が、基地局１０にＲＴＡデータを送信すると共に自端末のバッファ状況を基地局１０に通知するため、状況通知フレームを生成する。具体的には、ＲＴＡのデータが上位レイヤからデータ処理部２０１に入力されると、データ処理部２０１が、ＲＴＡデータ用の送信キューに蓄積されたデータ量をバッファ状況として取得し、当該データ量に関する情報とＲＴＡデータ本体とを含む状況通知フレームを生成する。

【0052】

ステップＳ７０５では、データ処理部２０１が、状況通知フレームを基地局１０に送信する。状況通知フレームの送信においては、ステップＳ７０２と同様に、例えばＣＳＭＡ／ＣＡ方式のアクセス制御を用いて、無線信号処理部１０２が、状況通知フレームを無線信号に変換して送信する。

【0053】

ステップＳ７０６では、無線信号処理部２０２が、得られたチャネルアクセスの送信権に基づいて、状況通知フレームを無線信号に変換して基地局１０に送信する。端末２０はアクセスカテゴリごとに送信キューを有し、アクセスカテゴリごとに割り当てられた、上述のようなアクセスパラメータを用いて、送信キューごとにＣＳＭＡ／ＣＡでチャネルアクセスを行う。例えば、上述の様にアクセスカテゴリ（ＡＣ＿ＶＯ、ＡＣ＿ＶＩ、ＡＣ＿ＢＥ、ＡＣ＿ＢＫ）に加え、ＲＴＡ用のアクセスカテゴリＡＣ＿ＲＴＡを追加してもよい。つまり、ＡＣ＿ＲＴＡ用の送信キューを用意し、ＡＣ＿ＲＴＡのアクセスパラメータを最優先に設定してもよい。これにより、端末２０が基地局１０から送信権を与えられた場合は、ＡＣ＿ＲＴＡ用の送信キューから優先したＲＴＡのデータフレームを送信でき、ＲＴＡトラヒックを優先できる。

【0054】

無線信号処理部２０２は、基地局１０から送信権を与えられた場合、ＲＴＡキューに蓄積されたＲＴＡのデータフレームをＲＴＡキューの先頭から順に無線信号に変換して送信する。
なお、説明の便宜上、ＡＣ＿ＲＴＡのアクセスカテゴリに分類されるＲＴＡデータ以外のデータ、つまり、ＡＣ＿ＶＯ、ＡＣ＿ＶＩ、ＡＣ＿ＢＥ及びＡＣ＿ＢＫのアクセスカテゴリに分類されるデータを非ＲＴＡデータとも呼ぶ。

【0055】

ステップＳ７０７では、発生したＲＴＡのデータフレームの全てについて送信が完了したか否かを判定する。発生したＲＴＡのデータフレームが全て送信された場合、処理を終了し、発生したＲＴＡデータの全てについて送信が完了していない場合、ステップＳ７０６に戻り、同様の処理を繰り返す。
なお、ＲＴＡデータが発生するたびにステップＳ７０４からステップＳ７０７までの処理が繰り返されればよい。

【0056】

次に、端末２０で生成されるネゴシエーションフレームのフォーマットの一例について図８を参照して説明する。
ネゴシエーションフレーム８００は、端末２０の識別情報などを含むヘッダフィールド８０１と、リアルタイムアプリケーションの要求条件、ここではリアルタイムアプリケーションで許容できる最大の遅延量を示す最大遅延フィールド８０２とを含む。なお、リアルタイムアプリケーションで許容できる最大のジッタ量などの通信品質に関する他の情報がネゴシエーションフレーム８００に含まれてもよい。

【0057】

次に、端末２０で生成される状況通知フレームのフォーマットの一例について図９を参照して説明する。
状況通知フレーム９００は、端末の識別情報を含むヘッダフィールド９０１と、ＲＴＡデータのバッファ状況を示すバッファ状況フィールド９０２と、ＲＴＡデータ本体が格納されるペイロードフィールド９０３とを含む。
なお、状況通知フレーム９００は、基地局１０にバッファ状況を伝えるだけの場合は、ペイロードフィールド９０３にＲＴＡデータ本体を含まなくてもよい。

【0058】

また、バッファ状況は、ヘッダフィールド９０１及びペイロードフィールド９０３から独立したバッファ状況フィールド９０２に格納されることを想定するが、これに限らず、バッファ状況フィールド９０２を設けずに、バッファ状況がヘッダフィールド９０１又はペイロードフィールド９０３に含まれてもよい。

【0059】

次に、本実施形態に係る基地局１０の動作について図１０のフローチャートを参照して説明する。図１０に示す基地局１０の動作は、ステップＳ１００１からステップＳ１００３までのネゴシエーションフェーズと、ステップＳ１００４からステップＳ１００９までの通信フェーズとを含む。

【0060】

ステップＳ１００１では、無線信号処理部１０２が、端末２０からネゴシエーションフレームを受信する。無線信号処理部１０２は、ネゴシエーションフレームからＲＴＡの要求条件（例えば、最大遅延）を抽出する。

【0061】

ステップＳ１００２では、データ処理部１０１が、現在の通信状況に基づいて、抽出されたリアルタイムアプリケーションの要求条件を満たすか否かを判定する。具体的には、データ処理部１０１は、例えば、通信状況として、基地局１０のサービスエリアにおけるトラヒックの混雑状況、干渉波により連続的にチャネルが占有される期間、及び、既に確立しているＲＴＡ用セッション数などの判定材料の少なくとも１つを考慮して、リアルタイムアプリケーションが要求する最大遅延よりも大きい遅延が発生すると想定されるか否かを判定すればよい。

【0062】

より詳細には、データ処理部１０１は、例えば干渉波を判定材料とする場合、干渉波により連続的にチャネルが占有される期間が閾値以上の期間であれば、リアルタイムアプリケーションの要求条件を満たすことができないと判定し、チャネルが占有される期間が閾値未満の期間であれば、リアルタイムアプリケーションの要求条件を満たすことができると判定する。既に確立しているＲＴＡ用セッション数であれば、ＲＴＡ用セッション数の最大値としての設定値を確立しているＲＴＡ用セッション数を超えていれば、要求条件を満たすことができないと判定され、ＲＴＡ用セッション数以下であれば要求条件を満たすことができると判定されればよい。または、各ＲＴＡ用セッションの実際の通信において測定された遅延から線型推測する等により、既に確立してあるＲＴＡ用セッションの遅延を確保しつつ新たなＲＴＡ用セッションを受け入れた場合に想定される遅延が要求される遅延を超えていれば、要求条件を満たすことができないと判定され、新たなＲＴＡ用セッションを受け入れても想定される遅延が要求される遅延以下であれば、要求条件を満たすことができると判定されればよい。
トラヒックの混雑状況としては、基地局１０内で測定した既存のＲＴＡトラヒックを送信する際の遅延または端末２０からのレポートされた既存のＲＴＡトラヒックを送信する際の遅延に基づいて、平均値、最大遅延、ジッタ等が閾値を上回っていれば、要求条件を満たすことができないと判定され、平均値、最大遅延、ジッタ等が閾値以下であれば、要求条件を満たすことができると判定されればよい。または、線型推測するなどにより、新たなＲＴＡトラヒックを受け入れることで、平均値、最大遅延、ジッタ等が閾値を上回っていれば、要求条件を満たすことができないと判定され、新たなＲＴＡトラヒックを受け入れても平均値、最大遅延、ジッタ等が閾値以下であれば、要求条件を満たすことができると判定されればよい。
なお、データ処理部１０１は、端末２０からアクセスカテゴリごとの遅延又はジッタの測定結果のレポートを受信できる場合は、当該レポートを判定材料の１つとして用いてもよい。

【0063】

現在の通信状況に基づいて、最大遅延よりも大きい遅延が発生すると想定される場合、要求条件を満たすことができないため、ステップＳ１００３に進む。一方、最大遅延以下の遅延が発生すると想定される場合、要求条件を満たすことができるため、ステップＳ１００４に進む。
なお、要求条件について判定する判定材料は上述したものに限らず、要求条件を満たすことができるか否かの判定材料となり得る情報であれば、どのような情報を用いて判定してもよい。

【0064】

ステップＳ１００３では、基地局１０のデータ処理部１０１及び無線信号処理部１０２は、ネゴシエーションフレームを送信してきた端末２０に対し、要求条件を満たした通信ができないことを示す拒否通知を当該端末２０に対して送信する。
ステップＳ１００４では、管理部１０３は、ネゴシエーションフレームから抽出した要求条件、ここでは最大遅延に関する情報を取得して格納する。

【0065】

ステップＳ１００５では、基地局１０のデータ処理部１０１及び無線信号処理部１０２は、ネゴシエーションフレームを送信してきた端末２０に対し、要求条件を満たした通信を確保できることを示す許可通知を当該端末２０に対して送信する。なお、基地局１０は、許可通知に対するＡＣＫを送信するよう要求してもよい。これにより、ネゴシエーションフェーズにおいて、ネゴシエーションが完了する。

【0066】

ステップＳ１００６では、データ処理部１０１が、端末２０から状況通知フレームを受信したかどうかを判定する。状況通知フレームを受信した場合、ステップＳ１００７に進み、状況通知フレームを受信していない場合、ステップＳ１００８に進む。

【0067】

ステップＳ１００７では、データ処理部１０１が、状況通知フレームに含まれるバッファ状況に基づいて、ＲＴＡトラヒックが滞留し、その後の通信において要求条件を満たせない可能性があるか否かを判定する。具体的には、例えば、バッファ状況に示されるデータ量が閾値以上である場合、ＲＴＡトラヒックが滞留しており、端末２０とネゴシエートした最大遅延にデータ通信時の遅延が収まらない可能性があると考えられるため、データ処理部１０１は、その後の通信において要求条件を満たせない可能性があると判定すればよい。また、バッファ状況に加えて、ステップＳ１００２に示した要求条件が判定される場合と同様の通信状況をさらに考慮し、要求条件を満たせない可能性があるか否かを判定してもよい。要求条件を満たせない可能性がある場合、ステップＳ１００９に進み、要求条件を満たせない可能性がない場合、ステップＳ１００８に進む。

【0068】

ステップＳ１００８では、通信制御部１０４が、非ＲＴＡデータ、つまり通常のデータフレームに関する通信制御を行なう。
ステップＳ１００９では、通信制御部１０４が、ＲＴＡトラヒックが滞留しないように、つまり要求条件を満たすような通信制御を行なう。通信制御の方法としては、例えば、ＲＴＡトラヒックが優先的に送信されるようにアクセスパラメータを変更する旨の通知を含むビーコン信号を端末２０に向けて送信する。端末２０は、ビーコン信号に含まれるアクセスパラメータに応じてパラメータを設定することで、ＲＴＡトラヒックが優先的に送信される。又は、基地局１０から、ＨＣＣＡ（Hybrid coordination function Controlled Channel Access）方式により、ポーリングフレームを端末２０に送信することで、端末２０に送信機会を付与する頻度を高めてもよい。又は、ＯＦＤＭＡ（Orthogonal Frequency Division Multiple Access）のトリガーフレームにより、送信権が端末２０に与えられる頻度を高め、より多くの送信機会が得られるようにしてもよい。
例えば、通信制御部１０４は、バッファ状況に示されるデータ量が多いほど、端末２０に割り当てるＴＸＯＰ期間を長くする制御を行えばよい。

【0069】

ここで、基地局１０による端末２０の送信機会制御の一例として、ＨＣＣＡ方式におけるポーリングフレームを用いる場合について図１１を参照して説明する。なお、ビーコン信号及びトリガーフレームを用いて端末の送信機会を制御する場合も、図１１の方式と同様の方式で制御することができる。

【0070】

図１１は、基地局１０と端末２０－１及び端末２０－２との間のフレーム送受信を示すシーケンス図である。ここでは、端末２０－１がリアルタイムアプリケーションによる要求条件を有する端末（以下、ＲＴＡ端末という）であり、端末２０－２はリアルタイムアプリケーションによる要求条件がない、通常のデータ通信を行なう端末である。なお、ＲＴＡ端末及び通常のデータ通信を行なう端末は、それぞれ２つ以上存在してもよい。

【0071】

まず、端末２０－１は、リアルタイムアプリケーションによる要求条件（最大遅延）に基づく通信が可能であるか、ネゴシエーションフレーム１１０１を基地局１０に送信する。
基地局１０では、ネゴシエーションフレーム１１０１に含まれる要求条件を判定し、ここでは、要求条件を満たせるとして、許可通知１１０２を端末２０－１に送信する。

【0072】

端末２０－１では、許可通知１１０２により要求条件が満たされることを把握できるので、ＲＴＡデータを含む状況通知フレーム１１０３を送信する。

【0073】

基地局１０は、ＲＴＡデータの遅延が要求条件の最大遅延以内に収まるように、トラヒック状況を監視する。ここで、基地局１０が端末２０－１から受信した状況通知フレーム１１０３により、ＲＴＡデータのバッファ状況から蓄積しているＲＴＡトラヒックが滞留する可能性がある場合を想定する。

【0074】

この場合、基地局１０は、端末２０－１に送信機会を与える指示を含むポーリングフレームを生成する。基地局１０は、生成したポーリングフレーム１１０４－１を自局に帰属する端末群、端末２０－１及び端末２０－２に送信する。ポーリングフレーム１１０４－１を受けた端末２０－１は、基地局から優先的に送信機会を与えられるため、ＲＴＡデータを含む状況通知フレーム１１０３を生成して、基地局１０に送信する。その後、基地局１０からＡＣＫ１１０６を受信するといった、ＲＴＡデータについての優先的なデータ通信を行なうことができる。

【0075】

なお、１度のポーリングフレーム１１０４－１により付与されたＴＸＯＰ期間ではＲＴＡ要求条件を満たせない場合、要求条件である最大遅延時間の期間１１１０を有する周期で、端末２０－１に送信機会を与える指示を含むポーリングフレーム１１０４－２を送信してもよい。これにより、例えば端末２０－１は連続して送信機会を得られるため、ＲＴＡデータの通信制御を適切に行うことができる。

【0076】

一方、端末２０－２は、図１１の例では２度目のポーリングフレーム１１０４－２が送信された後端末２０－１のＴＸＯＰ期間（図１１の例では、期間１１１１）が終了するまでは送信禁止期間となるため、データの送受信は行わない。端末２０－２は、送信禁止期間の終了後、送信権を得た場合に、データフレーム１１０５を送信できる。

【0077】

以上に示した本実施形態によれば、基地局と端末との間でリアルタイムアプリケーションの要求条件を満たすことができるか否かについて、端末がネゴシエーションフレームを基地局に送信する。基地局が要求条件を満たすことができると判定した場合、基地局が許可通知を端末に送信することで、ネゴシエーションが完了する。
端末は、ＲＴＡデータを通信する際、ＲＴＡデータのバッファ状況を通知する基地局に送信する。これにより、基地局では、ＲＴＡトラヒックのデータが滞留する可能性がある場合、ＲＴＡトラヒックが優先されるように、基地局から端末に対して優先的に送信機会を与える送信制御を行なうことができる。結果として、ＲＴＡトラヒックの要求条件に対応した無線通信環境を提供することができる。

【0078】

また、上述した実施形態による各処理は、コンピュータであるプロセッサに実行させることができるプログラムとして記憶させておくこともできる。この他、磁気ディスク、光ディスク、半導体メモリ等の外部記憶装置の記憶媒体に格納して配布することができる。そして、プロセッサは、この外部記憶装置の記憶媒体に記憶されたプログラムを読み込み、この読み込んだプログラムによって動作が制御されることにより、上述した処理を実行することができる。

【0079】

なお、本発明は、上記実施形態に限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で種々に変形することが可能である。また、各実施形態は適宜組み合わせて実施してもよく、その場合組み合わせた効果が得られる。更に、上記実施形態には種々の発明が含まれており、開示される複数の構成要件から選択された組み合わせにより種々の発明が抽出され得る。例えば、実施形態に示される全構成要件からいくつかの構成要件が削除されても、課題が解決でき、効果が得られる場合には、この構成要件が削除された構成が発明として抽出され得る。

【符号の説明】

【0080】

１…通信システム
１０…基地局
１１，２１…プロセッサ
１２，２２…ＲＯＭ
１３，２３…ＲＡＭ
１４，２４…無線モジュール
１５…ルータモジュール
２０…端末
２５…ディスプレイ
２６…ストレージ
１０１，２０１…データ処理部
１０２，２０２…無線信号処理部
１０３…管理部
１０４…通信制御部
２０３…バッファ情報取得部

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】