(57)【特許請求の範囲】
【請求項１】
データパケットを送信しようとする無線端末の一つが送信端末として予めRTS（Request-To-Send）パケットを宛先端末へ送信し、データパケットを送信しようする他の無線端末は、前記RTSパケットを受信すると待機端末としてRTSパケットの送信を延期し、前記送信端末は、宛先端末から返信されるCTS（Clear-To-Send）パケットに応答してデータパケットを送信する無線アクセス制御方法において、
前記送信端末は、今回のRTSパケットに、次回のRTSパケットの送信タイミングを規定する送信タイミング情報を登録して送信し、
前記待機端末は、前記今回のRTSパケットを受信すると、当該RTSパケットに登録されている前記送信タイミング情報を抽出し、前記次回のRTSパケットの送信タイミングに基づいて自身のパケットの送信タイミングを決定することを特徴とする無線アクセス制御方法。
【請求項２】
前記待機端末は、自端末のRTSパケットを、前記送信端末の次回のRTSパケットと重ならないように送信することを特徴とする請求項１に記載の無線アクセス制御方法。
【請求項３】
前記待機端末は、自端末のRTSパケットを、当該RTSパケットを含む一連のCTSパケット、データパケットおよびACKパケットが前記送信端末の次回のRTSパケットと重ならないように送信することを特徴とする請求項１に記載の無線アクセス制御方法。
【請求項４】
前記宛先端末が、受信したRTSパケットに登録されている前記送信タイミング情報を抽出し、これをCTSパケットに転記して返信することを特徴とする請求項１ないし３のいずれかに記載の無線アクセス制御方法。
【請求項５】
前記送信端末は、今回のRTSパケットに、当該呼の優先度を代表する呼種別情報ACを登録して送信し、
前記待機端末は、受信した今回のRTSパケットから前記送信タイミング情報および呼種別情報ACを抽出し、前記呼種別情報ACに応じて、少なくとも自端末のRTSパケットが前記次回のRTSパケットと重ならないように各パケットの送信タイミングを制御することを特徴とする請求項１ないし４のいずれかに記載の無線アクセス制御方法。
【請求項６】
前記待機端末は、受信したRTSパケットに登録されている呼種別情報ACと自身が確立しようとする呼の呼種別情報AC’とを比較し、自身の優先度が送信端末の優先度よりも高ければ、自身のRTSパケットを、前記送信端末の次回のRTSパケットと重ならないように送信することを特徴とする請求項５に記載の無線アクセス制御方法。
【請求項７】
前記待機端末は、受信したRTSパケットに登録されている呼種別情報ACと自身が確立しようとする呼の呼種別情報AC’とを比較し、自身の優先度が送信端末の優先度よりも低ければ、自身のRTSパケットを、当該RTSパケットを含む一連のCTSパケット、データパケットおよびACKパケットが前記送信端末の次回のRTSパケットと重ならないように送信することを特徴とする請求項５に記載の無線アクセス制御方法。
【請求項８】
前記宛先端末が、前記今回のRTSパケットを受信すると、当該RTSパケットに登録されている前記次回のRTSパケットの送信タイミングおよび呼種別情報ACを抽出し、これをCTSパケットに登録して返信することを特徴とする請求項５ないし７のいずれかに記載の無線アクセス制御方法。
【請求項９】
データパケットを送信する際に予めRTS（Request-To-Send）パケットを送信し、宛先端末から返信されるCTS（Clear-To-Send）パケットに応答してデータパケットを送信する一方、他の無線端末から送信されたRTSパケットを受信するとRTSパケット送信を延期する無線端末において、
今回のRTSパケットに、次回のRTSパケットの送信タイミングを規定する送信タイミング情報を登録する送信タイミング情報登録手段と、
前記RTSパケットを送信するRTSパケット送信手段と、
他の無線端末から送信されたRTSパケットを受信する手段と、
前記受信したRTSパケットから前記次回のRTSパケットの送信タイミング情報を抽出する送信タイミング情報抽出手段と、
前記抽出された送信タイミングに基づいて自身のパケットの送信タイミングを決定する送信タイミング決定手段とを含むことを特徴とする無線端末。
【請求項１０】
前記送信タイミング決定手段は、自端末のRTSパケットを、他の無線端末による次回のRTSパケットと重ならないように送信することを特徴とする請求項９に記載の無線端末。
【請求項１１】
前記送信タイミング決定手段は、自身のRTSパケットを、当該RTSパケットを含む一連のCTSパケット、データパケットおよびACKパケットが他の無線端末による次回のRTSパケットと重ならないように送信することを特徴とする請求項９に記載の無線端末。
【請求項１２】
自端末宛のRTSパケットを受信すると、これに応答して返信するCTSパケットに、当該RTSパケットに登録されている前記送信タイミング情報を転記する送信タイミング情報転記手段を含むことを特徴とする請求項９ないし１１のいずれかに記載の無線端末。
【請求項１３】
送信するRTSパケットに当該呼の優先度を代表する呼種別情報ACを登録する呼種別情報登録手段と、
受信したRTSパケットに登録されている呼種別情報ACを抽出する呼種別情報抽出手段とを含み、
前記送信タイミング決定手段は、受信したRTSパケットに登録されている呼種別情報ACと自端末が確立しようとする呼の呼種別情報AC’とに基づいて両者の優先度を比較し、自端末の優先度が相手端末の優先度よりも高ければ、自端末のRTSパケットを、前記次回のRTSパケットと重ならないように送信させることを特徴とする請求項９ないし１２のいずれかに記載の無線端末。
【請求項１４】
送信するRTSパケットに当該呼の優先度を代表する呼種別情報ACを登録する呼種別情報登録手段と、
受信したRTSパケットに登録されている呼種別情報ACを抽出する呼種別情報抽出手段とを含み、
前記送信タイミング決定手段は、受信したRTSパケットに登録されている呼種別情報ACと自端末が確立しようとする呼の呼種別情報AC’とに基づいて両者の優先度を比較し、自端末の優先度が相手端末の優先度よりも低ければ、自端末のRTSパケットを含む一連のCTSパケット、データパケットおよびACKパケットを、前記次回のRTSパケットと重ならないように送信させることを特徴とする請求項９ないし１２のいずれかに記載の無線端末。
【請求項１５】
前記RTSパケットを受信すると、当該RTSパケットに登録されている呼種別情報ACをCTSパケットに転記する呼種別情報転記手段を含むことを特徴とする請求項１３または１４に記載の無線端末。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、無線端末およびその無線アクセス制御方法に係り、特に、送受信端末間でのデータ送信に先立ってRTS（Request-To-Send）およびCTS（Clear-To-Send）の各パケットを交換して回線の予約と予約状況の周知とを行う無線通信プロトコルを採用する無線端末およびその無線アクセス制御方法に関する。
【０００２】
【従来の技術】
自律分散型の無線アクセス制御（Medium Access Control: MAC）プロトコルでは、基地局などの制御局は各端末の無線アクセスのタイミングを制御せず、各端末が独自に無線アクセスのタイミングを決定する。このような自律分散型MACプロトコルは、無線LANシステムのみならず、基地局を介さずに端末同士が直接通信するアドホックネットワークでも使用される。また、セルラーシステムのように、基地局やアクセスポイントが存在するシステムでも、基地局（もしくはアクセスポイント）の通信可能範囲が狭いためにマルチホップによって通信を行うマルチホップ型無線通信システムでは、自律分散型MACプロトコルの使用が検討されている。
【０００３】
現在、無線LAN におけるMAC プロトコルとして、端末がパケットを送信する前に送信する搬送波（キャリア）の検出(キャリアセンス)を行い、搬送波が検出されなければ自身のパケットを送信するCSMA（Carrier Sense Multiple Access）方式、およびこのCSMA 方式に、さらにパケットの衝突回避機能を付加したCSMA/CA （CSMA with Collision Avoidance）方式が用いられるようになってきている。
【０００４】
上記したCSMAやCSMA/CAなどの自律分散型MACプロトコルでは、データパケットの送受信前に送受信端末間で回線の予約が行われず、また回線予約の状況を周辺の無線局（端末）に周知することも行われない。このため、互いに通信できない複数の無線局（端末）が、これらの端末にとって共通に通信可能な端末と通信を行おうとする「隠れ端末問題」が存在し、スループットの劣化が生じる。このような隠れ端末問題に対応すべく、送受信端末間でRTS（Request-To-Send）パケットとCTS（Clear-To-Send）パケットを事前に交換し、回線の予約と予約状況の周知を行う、MACA（Multiple Access with Collision Avoidance）と呼ばれる自律分散型MACプロトコルが考案されている。
【０００５】
図１０は、前記MACAの概要を示した図であり、送信端末は、データフレームの送信に先立ってRTSパケットを送信する。これに応答して宛先端末からCTSパケットが返信されればデータパケットDATAを送信し、CTSパケットが返信され無ければ、無線リソースを他の資源に振り分け等する。データパケットDATAを正常に受信し終えた宛先端末はACKパケットを返信する。
【０００６】
このMACAを発展させた自律分散型プロトコルが、無線LANシステムでの自律分散型プロトコルとして標準化され、無線LANシステムで採用されているIEEE 802.11 DCF（Distributed Coordinated Function）である。
【０００７】
図１１はIEEE 802.11 DCFプロトコルのシーケンスの概要を示した図であり、送信すべきパケットが発生した送信端末は、キャリアセンスによってチャネルの状態を調べる。チャネルがアイドルであると、更にDIFSの時間だけアイドル状態が継続した後にデータを直ちに送信する。キャリアセンスした際、チャネルがビジー状態であれば、チャネルがアイドルになるまで待機する。そして、チャネルがアイドルになってからDIFS の時間だけアイドル状態が継続した後、送信すべきデータを有する他の複数の端末が同時にRTSパケットを送信して衝突が生じることを防止するために、Backoff Windowと呼ばれる待機モードへ移行する。Backoff Windowでの待機時間twは、Contention Windowと呼ばれる時間幅の中から一様乱数を用いて決定され、カウンタにセットされる。
【０００８】
バックオフに入った端末は単位時間Δtごとにキャリアセンスを実行し、チャネルがアイドルであればカウンタを減らし、チャネルがビジーであればチャネルがアイドルになるまでカウンタを止めておき、チャネルがアイドルになり次第、再びカウンタを減らしていく。
【０００９】
カウンタが０になると自身のRTSパケットを送信する。ここでは、複数の端末のカウンタが同時に０にならなければRTSパケットの衝突は起らずに送信が行われる。複数の端末のカウンタが同時に０になるとRTSパケットの衝突が発生する。このような場合には、BEB（Binary Exponential Backoff）と呼ばれる機能が作用してContention Windowの時間が２倍に増加する。
【００１０】
RTSパケットを受信した全ての端末は、そのduration field を読み取る。送信されたパケットが自分宛でないことを確認した端末は、NAV (Network Allocation Vector) をセットし、それにしたがって現在送信中のパケットとそれに対するACK が返ってくるまでの間、何もせずに待機する。宛先端末は、RTSパケットを受け取るとCTS パケットを返信する。宛先端末以外の他端末は、前記CTSパケットのduration field を読み取ってNAV を更新する。送信端末は、CTSパケットを正確に受け取るとデータパケットの送信が成功したことを確認できる。
【００１１】
上記した従来のIEEE 802.11 DCFでは、トラヒックの種別（AC: Access Category）ごとに異なる要求サービス品質（QoS: Quality of Service）が考慮されていないため、現在、IEEE 802.11 Task Group Eでは、QoSを考慮したDCFの標準化を進めている（EDCF: Enhanced DCFと呼ばれる）。このEDCFではQoSを考慮し、トラヒックの種別ACごとにContention Windowを設定できるようにするなどのACによる差別化を図っている。
【００１２】
RTSパケットとCTSパケットとを使用した自律分散型MACプロトコルに関しては、上記のIEEE 802.11 DCFやDCFの拡張版であるEDCFの他、さまざまなプロトコルが提案されている。たとえば、電子情報通信学会2002年総合大会B-5-270では、送信範囲が異なる端末が存在する場合の問題、さらに具体的に言えば、小電力端末から送信されるRTSパケットやCTSパケットが周辺の端末に届かないために、他の大電力端末は無線チャネルが空いていると判断し、パケットを送信することによって、小電力端末の送受信に干渉を与えるという問題に対し、小電力端末から送信されたRTSパケットやCTSパケットを大電力端末が転送することにより、周辺端末への周知を行う方式が提案されている。
【００１３】
また、電波伝搬距離やフェージングの影響によって、無線LANのアクセスポイント（セルラーシステムの基地局に相当）で受信する端末の信号強度が異なると、RTSパケットが衝突したとしても受信電力が強い端末では受信され、受信電力が低い端末では破棄される。また、受信電力値が大きな端末へのCTSパケット送信と受信電力値の小さな端末からのRTSパケット送信とが重なると、受信電力値の小さな端末は他端末へのCTSを認識することができず、RTSパケット送信を繰り返すという結果になる。
【００１４】
このような問題を解決するために、電子情報通信学会2000年ソサイエティ大会B-5-165では、RTSパケットの受信後、CTSパケットの送信までの時間を長く設定し、その間、アクセスポイントがキャリアセンスを行い、CTSパケット送信とRTSパケット受信とが重ならないようにする技術が開示されている。
【００１５】
さらに、電子情報通信学会2001年総合大会B-5-280では、１フレームを予約部とデータ部とに分け、予約部をさらに即時系専用予約スロットと待時系専用予約スロットとに分けている。即時系の呼（たとえば、音声呼）が一度スロットを予約すると、連続して同じスロットが予約され、待時系の呼（たとえば、データ呼）は即時系の呼に割り当てられたスロット以外が使用可能である。これによって、要求サービス品質を考慮したMACプロトコルが実現される（なお、このような考え方は、PRMA: Packet Reservation Multiple Accessと呼ばれる、基地局制御型のMACとして公知である）。
【００１６】
しかしながら、このプロトコルを適用するためには、すべての無線局（端末）がフレーム単位の時刻同期を確立する必要があるため、この論文では、GPSによる時刻同期が前提となっている。
【００１７】
【発明が解決しようとする課題】
前記IEEE 802.11 DCFや、現在標準化活動が進められているEDCFでは、各端末が独自にBack-off Windowを決定し、決定した値に基づいてRTSパケットを送信しているためにRTSパケットの衝突が発生しやすい。そして、これを回避するためにContention Windowが広く設定されるが、Contention Windowが増加すると、相対的に無送信時間、すなわち無線資源を使用していない時間が増える。このため、無線資源を効率的に使用できないのみならず、データ送信までの待ち時間が増加し、スループットが向上しないという結果になる。
【００１８】
また、上記した従来の送信電力や受信電力の差を考慮したMACプロトコルでも、RTSパケットの衝突を避ける工夫がなされておらず、またQoSも考慮されていない。
【００１９】
さらに、VoIP（Voice Over IP）呼のように、符号化された音声パケットが周期的に回線に送出され、また、パケットの送出ジッタを最小限に抑えたい呼の場合でも、EDCFではRTSパケットの衝突が発生するために、送信ジッタの抑制に対する直接的な対処は考えられていない。
【００２０】
さらに、PRMAプロトコルの考え方を導入した、自律分散型MACプロトコルは、即時呼のQoSを考慮しているが、時刻同期を前提とするために、その適用が容易ではなく、汎用性も劣る。
【００２１】
本発明の目的は、上記した従来技術の課題を解決し、RTSパケットの衝突を可能な限り回避し、かつVoIP呼のように周期的にデータパケットが発生する呼のジッタを最小限に抑えられる無線端末およびその無線アクセス制御方法を提供することにある。
【００２２】
【課題を解決するための手段】
上記した目的を達成するために、本発明は、データパケットを送信する際に予めRTSパケットを送信し、宛先端末から返信されるCTSパケットに応答してデータパケットを送信する一方、他の無線端末から送信されたRTSパケットを受信するとRTSパケット送信を延期する無線端末において、以下のような手段を講じた点に特徴がある。
【００２３】
(1)今回のRTSパケットに、次回のRTSパケットの送信タイミングを規定する送信タイミング情報を登録する送信タイミング情報登録手段と、RTSパケットを送信するRTSパケット送信手段と、他の無線端末から送信されたRTSパケットを受信する手段と、受信したRTSパケットから前記次回のRTSパケットの送信タイミング情報を抽出する送信タイミング情報抽出手段と、抽出された送信タイミングを避けて自身のパケットの送信タイミングを決定する送信タイミング決定手段とを含むことを特徴とする。
【００２４】
(2)自端末宛のRTSパケットを受信すると、これに応答して返信するCTSパケットに、当該RTSパケットに登録されている送信タイミング情報を転記する送信タイミング情報転記手段を含むことを特徴とする。
【００２５】
(3)送信するRTSパケットに当該呼の優先度を代表する呼種別情報ACを登録する呼種別情報登録手段と、受信したRTSパケットに登録されている呼種別情報ACを抽出する呼種別情報抽出手段とを含み、送信タイミング決定手段は、受信したRTSパケットに登録されている呼種別情報ACと自端末が確立しようとする呼の呼種別情報AC’とに基づいて両者の優先度を比較し、この比較結果と送信タイミング情報とに基づいて、自端末からのパケットの送信タイミングを決定することを特徴とする。
【００２６】
上記した特徴(1)によれば、待機端末のRTSパケットは、送信端末のRTSパケットの送信タイミングを避けて送信されるので、送信端末からのRTSパケットの送信が待機端末のRTSパケットにより妨げられることがない。
【００２７】
上記した特徴(2)によれば、送信端末からRTSパケットを受信できない待機端末（隠れ端末）も、その宛先端末から送信される、次回のRTSパケットの送信タイミング情報が転記されたCTSパケットを受信できるので、いわゆる隠れ端末問題が解消される。その結果、CTSパケットを受信できた隠れ端末からのRTSパケットは、送信端末のRTSパケットの送信タイミングを避けて送信されるので、送信端末からのRTSパケットの送信が隠れ端末のRTSパケットにより妨げられることがない。
【００２８】
上記した特徴(3)によれば、待機端末のRTSパケット送信タイミングが、送信端末および待機端末の優先度を考慮して決定されるので、優先度の低い呼が優先されたり、優先度の高い呼の品質が低下したりするなどの問題が解消される。
【００２９】
【発明の実施の形態】
以下、図面を参照して本発明の好ましい実施の形態について詳細に説明する。図１は、本発明に係る無線端末の第１実施形態の機能ブロック図であり、ここでは、無線端末の動作を以下の３つの状態(1)〜(3)に分類して説明する。
【００３０】
(1)送信すべきデータパケットを所有し、かつRTCパケットを送信できた「送信端末」として動作する場合。
(2)データパケットを受信する「宛先端末」として動作する場合。
(3)送信すべきデータパケットを所有するもののRTCパケットを送信できない「待機端末」として動作する場合。
【００３１】
図１では、主に「送信端末」としての動作に必要な機能ブロックに添字[S]を付し、主に「宛先端末」としての動作に必要な機能ブロックに添字[D]を付し、主に「待機端末」としての動作に必要な機能ブロックに添字[W]を付している。
【００３２】
送信タイミング情報登録部１１[S]は、データパケットの送信に先立って、自端末から送信する今回のRTSパケット▲１▼に、次回のRTCパケット▲２▼の送信タイミングを特定する送信タイミング情報を登録する。本実施形態では、送信タイミング情報として、例えば次回のRTSパケット▲２▼の送信時刻やBack-off Windowを登録する。RTSパケット送信部１０[S]は、前記送信タイミング情報の登録されたRTSパケットを送信する。
【００３３】
RTSパケット受信部２０[D][W]は、送信端末から上記のようにして送信されたRTSパケット▲１▼を受信する。送信タイミング情報抽出部２１[W]は、受信したRTSパケットに登録されている送信タイミング情報を抽出する。送信タイミング決定部２３[W]は、前記抽出された送信タイミング情報に基づいて送信端末による次回のRTSパケット▲２▼の送信タイミングを判別し、このRTSパケット▲２▼と衝突しない送信タイミングを、自端末（待機端末）からのRTSパケットの送信タイミングとして決定する。
【００３４】
CTSパケット送信部３０[D]は、自端末を宛先とするRTSパケットを受信すると、これに応答して、その送信元である送信端末に向けてCTSパケットを送信する。CTSパケット受信部４０[S]は、前記宛先端末から送信されたCTSパケットを受信する。
【００３５】
図２は、本実施形態の動作を示したタイミングチャートであり、ここでは、無線端末間で送受信されるパケットのみに着目し、Back-off Window、DIFS、SIFS等の各期間は図示を省略している。
【００３６】
送信端末は、送信しようとする今回のRTSパケット▲１▼に、前記送信タイミング情報登録部１１において次回のRTSパケット▲２▼の送信タイミング情報を登録し、これをRTSパケット送信部１０から送信する。
【００３７】
宛先端末は、前記RTSパケット受信部２０において自端末を宛先とする今回のRTSパケット▲１▼を受信すると、これに応答して前記CTSパケット送信部３０から、送信端末を宛先としてCTSパケットを送信する。
【００３８】
待機端末は、前記RTSパケット受信部２０において、自端末以外を宛先とする今回のRTSパケット▲１▼を受信すると、このRTSパケット▲１▼に登録されている次回のRTSパケット▲２▼の送信タイミング情報を前記送信タイミング情報抽出部２１で抽出する。送信タイミング決定部２３は、次回のRTSパケット▲２▼の送信タイミングを自端末（待機端末）からのRTSパケットの送信禁止期間と認識し、それ以外の期間からRTSパケットの送信タイミングを決定する。
【００３９】
さらに具体的に言えば、全ての待機端末は、前記次回のRTSパケット▲２▼の送信開始時刻をTRTS(i)、このRTSパケットの送信に要する時間をDRTS(i)とすれば、時刻TRTS(i)から時刻[TRTS(i)＋DRTS(i)]の期間[TRTS(i), TRTS(i)+ DRTS(i)]が自端末のRTSパケットの送信期間と重ならないように、その送信タイミングを決定する。なお、RTSパケットの送信タイミングは、前記[TRTS(i), TRTS(i)+ DRTS(i)]の期間以外であれば、IEEE 802.11 DCFやEDCFのように、Contention Window内から乱数により決定してもよい。
【００４０】
本実施形態によれば、待機端末のRTSパケットは、送信端末のRTSパケットの送信タイミングを避けて送信されるので、送信端末からのRTSパケットの送信が待機端末のRTSパケットにより妨げられることがない。
【００４１】
なお、送信端末の送信を優先させたいのであれば、図３に示したように、待機端末は、自端末からのパケット送信に必要な時間（RTSパケットの送信からACKパケットの受信までの時間）をDFとしたとき、自端末のRTS送信タイミングを、TRTS(j)−DFより前の時刻か、TRTS(j)+ DRTS(j)より後の時刻に決定する。このようにすれば、送信端末／宛先端末間でのパケット交換が待機端末によって妨げられることがないので、特に、送信端末の呼がリアルタイム通信のようにジッタの発生を最小限に抑えたい場合に有効である。
【００４２】
図４は、本発明に係る無線端末の第２実施形態の機能ブロック図であり、前記と同一の符号は同一または同等部分を表している。
【００４３】
送信タイミング情報転記部３１[D]は、当該無線端末が宛先端末として機能する際に、送信端末から受信したRTSパケットに応答して返信するCTSパケットに、当該RTSパケットから抽出した送信タイミング情報を転記する。CTSパケット送信部３０[D]は、前記送信タイミング情報の転記されたCTSパケットを前記と同様に送信する。
【００４４】
CTSパケット受信部４０[W]は、当該無線端末が主に待機端末として機能する際に、宛先端末から送信されたCTSパケットを受信する。送信タイミング情報抽出部４１[W]は、受信したCTSパケットに登録されている送信タイミング情報を抽出する。送信タイミング決定部４３[W]は、前記抽出された送信タイミング情報に基づいて次回のRTSパケット▲２▼の送信タイミングを判別し、このRTSパケット▲２▼と衝突しない送信タイミングを、自端末（待機端末）によるRTSパケットの送信タイミングとして決定する。
【００４５】
前記RTSパケット送信部１０[W]は、前記送信タイミング決定部２３[W]で決定された送信タイミング、または前記送信タイミング決定部４３[W]で決定された送信タイミングでRTSパケットを送信する。
【００４６】
図５は、本実施形態における送信端末、宛先端末および２つの待機端末Ａ，Ｂの動作を示したタイミングチャートであり、ここでは、図６に示したように、待機端末Ｂと送信端末および待機端末Ａとの通信が遮蔽物５０により遮られている場合を例にして説明する。
【００４７】
宛先端末は、今回のRTSパケット▲１▼をRTSパケット受信部２０で受信すると、このRTSパケット▲１▼に登録されている次回のRTSパケット▲２▼の送信タイミング情報を送信タイミング情報抽出部２１で抽出する。送信タイミング情報転記部３１は、前記抽出された送信タイミング情報をCTSパケット▲１▼に転記し、CTSパケット送信部３０から送信する。
【００４８】
一方の待機端末Ａは、前記今回のRTSパケット▲１▼を送信端末から受信できるので、このRTSパケット▲１▼に登録されている次回のRTSパケット▲２▼の送信タイミング情報を抽出し、この期間をRTS送信禁止期間と認識し、それ以外の期間をRTS送信タイミングとして決定する。
【００４９】
他方の待機端末Ｂは、送信端末からは今回のRTSパケット▲１▼を受信できないものの、宛先端末から送信されたCTSパケット▲１▼を受信し、送信タイミング情報抽出部４１において、前記CTSパケット▲１▼から送信タイミング情報を抽出する。送信タイミング決定部４３は、送信タイミング情報に基づいてRTS送信禁止期間と認識し、それ以外の期間をRTS送信タイミングとして決定する。
【００５０】
本実施形態によれば、RTSパケットに登録されている送信タイミング情報が宛先端末においてCTSパケットに転記されて送信されるので、いわゆる隠れ端末問題も解消される。
【００５１】
図７は、本発明に係る無線端末の第３実施形態の機能ブロック図であり、前記と同一の符号は同一または同等部分を表している。
【００５２】
呼種別情報登録部１２[S]は、当該無線端末が送信端末として機能する際、送信しようとするRTCパケットに、当該呼の優先度を代表する呼種別情報ACを登録する。RTSパケット送信部１０[S]は、前記送信タイミング情報および呼種別情報ACの登録されたRTSパケットを送信する。
【００５３】
本実施形態では、VoIP呼のように周期的にパケットを送出することを特徴とするリアルタイム呼のACを「０１」、周期的にパケットを送出するわけではないがテレビ会議やライブビデオのように即時性が要求されるリアルタイム呼のACを「０２」、即時性は要求されないものの比較的高いスループットや応答性が要求されるWebページのダウンロードなどのノンリアルタイム呼のACを「１１」、さらには遅延やスループットの要求条件が比較的緩やかな電子メールのようなノンリアルタイム呼のACを「１２」とし、呼種別情報ACの優先度を、「０１」＞「０２」＞「１１」＞「１２」と定義する。
【００５４】
呼種別情報抽出部２２[D][W]は、当該無線端末が宛先端末または待機端末として機能する際に、送信端末から上記と同様にして送信されたRTSパケットに登録されている呼種別情報ACを抽出する。送信タイミング決定部２３[W]は、前記抽出された送信タイミング情報に基づいて前記他の無線端末から送信される次回のRTSパケットの送信タイミングを識別すると共に、前記抽出した呼種別情報ACに基づいて、当該呼の優先度を自端末が確立しようとしている呼の優先度と比較する。そして、優先度の比較結果と次回のRTSパケットの送信タイミングとに基づいて、自端末によるRTSパケットの送信タイミングを決定する。
【００５５】
呼種別情報転記部３２[D]は、当該無線端末が宛先端末として機能する際、受信したRTSパケットに応答して返信するCTSパケットに、当該RTSパケットから抽出した呼種別情報ACを転記する。CTSパケット送信部３０[D]は、前記送信タイミング情報および呼種別情報ACの転記されたCTSパケットを送信する。
【００５６】
呼種別情報抽出部４２[W]は、当該無線端末が待機端末として機能する際に、宛先端末から送信されたCTSパケットに登録されている呼種別情報ACを抽出する。送信タイミング決定部４３[W]は、前記抽出された送信タイミング情報に基づいて前記送信端末から送信される次回のRTSパケット▲２▼の送信タイミングを識別すると共に、前記抽出した呼種別情報ACに基づいて当該呼の優先度を自端末が確立しようとしている呼の優先度と比較する。そして、優先度の比較結果と次回のRTSパケット▲２▼の送信タイミングとに基づいて、自端末によるRTSパケットの送信タイミングとして決定する。
【００５７】
図８、９は、本実施形態における送信端末、宛先端末および待機端末の動作を示したタイミングチャートであり、図８は、送信端末の呼種別情報（AC）で代表される優先度が待機端末の優先度以下である場合の動作を示し、図９は、送信端末の優先度が待機端末の優先度よりも上位である場合の動作を示している。
【００５８】
送信端末優先度≦待機端末優先度であれば、図８に示したように、待機端末のRTSパケットの送信タイミングは、送信端末の次回のRTSパケット▲２▼の送信タイミングと重ならないように、その前後に設定される。すなわち、早い時刻にRTSを送信した端末が優先される「Straight-forward」の処理となる。
【００５９】
これに対して、送信端末優先度＞待機端末優先度であれば、図９に示したように、待機端末のRTSパケット〜ACKパケットの送信期間が送信端末のRTSパケット▲２▼の送信タイミングと重ならないように、その前後に設定される。
【００６０】
本実施形態によれば、待機端末のRTSパケット送信タイミングが、送信端末および待機端末の優先度を考慮して決定されるので、優先度の低い呼が優先されたり、優先度の高い呼の品質が低下したりするなどの問題が解消される。
【００６１】
なお、上記した各実施形態では、今回のRTSパケット▲１▼に、次回のRTSパケット▲２▼の送信タイミング情報のみを登録し、あるいは送信タイミング情報と共に呼種別情報ACを登録するものとして説明したが、本発明はこれのみに限定されるものではなく、送信タイミング情報を登録することなく呼種別情報ACのみを登録するようにしても良い。
【００６２】
この場合には、呼種別情報AC毎に次回のRTSパケット送信タイミングをあらかじめ定義しておくか、あるいは、IEEE 802.11 DCFやEDCFのように、各呼種別情報ACで定められたContention Windowから選択されるであろう各Back-off Windowの確率を算出し（一様乱数を使用すると、同じ確率値となる）、衝突する確率がもっとも低いと思われる時刻を各端末がRTS送信タイミングとして決定すれば良い。
【００６３】
【発明の効果】
本発明によれば、RTSパケットの衝突を回避しやすくなるため、結果的にContention Windowの狭小化が図れ、無線資源の有効利用やデータパケット送出遅延の削減、スループットの向上が実現できる。また、周期的にデータパケットが発生する呼のパケット送信タイミングを阻害しないため、ジッタに対して敏感な呼のQoSを満足することが可能となる。
【図面の簡単な説明】
【図１】  本発明に係る無線端末の第１実施形態の機能ブロック図である。
【図２】  第１実施形態のタイミングチャート（その１）である。
【図３】  第１実施形態のタイミングチャート（その２）である
【図４】  本発明に係る無線端末の第２実施形態の機能ブロック図である。
【図５】  第２実施形態のタイミングチャートである
【図６】  第２実施形態による隠れ端末問題の解消方法を示した図である。
【図７】  本発明に係る無線端末の第３実施形態の機能ブロック図である。
【図８】  第３実施形態のタイミングチャート（その１）である。
【図９】  第３実施形態のタイミングチャート（その２）である
【図１０】  従来のMACAの通信手順を示した図である。
【図１１】  従来のIEEE 802.11 DCFプロトコルのシーケンス図である。
【符号の説明】
１０…RTSパケット送信部，１１…送信タイミング情報登録部，１２…呼種別情報登録部，２０…RTSパケット受信部，２１…送信タイミング情報抽出部，２２…呼種別情報抽出部，２３…送信タイミング決定部，３０…CTSパケット送信部，３１…送信タイミング情報転記部，３２…呼種別情報転記部，４０…CTSパケット受信部，４１…送信タイミング情報抽出部，４２…呼種別情報抽出部，４３…送信タイミング決定部
【図１】
0004042901.tif 000002
【図２】
0004042901.tif 000003
【図３】
0004042901.tif 000004
【図４】
0004042901.tif 000005
【図５】
0004042901.tif 000006
【図６】
0004042901.tif 000007
【図７】
0004042901.tif 000008
【図８】
0004042901.tif 000009
【図９】
0004042901.tif 000010
【図１０】
0004042901.tif 000011
【図１１】
0004042901.tif 000012