(57)【要約】【課題】ＲＴＳパケットの衝突を可能な限り回避し、かつＶｏＩＰ呼のように周期的にデータパケットが発生する呼のジッタを最小限に抑える。【解決手段】送信タイミング情報登録部１１は、自端末から送信する今回のＲＴＳパケットに、次回のＲＴＣパケットの送信タイミングを特定する送信タイミング情報を登録する。ＲＴＳパケット受信部２０は送信端末から送信されたＲＴＳパケットを受信する。送信タイミング情報抽出部２１は、受信したＲＴＳパケットに登録されている送信タイミング情報を抽出する。送信タイミング決定部２３は、抽出された送信タイミング情報に基づいて送信端末による次回のＲＴＳパケットの送信タイミングを判別し、このＲＴＳパケットと衝突しない送信タイミングを、自端末からのＲＴＳパケットの送信タイミングとして決定する。【選択図】        図１
2004180131.tif 000002
【特許請求の範囲】
【請求項１】
データパケットを送信しようとする無線端末の一つが送信端末として予めＲＴＳ（Ｒｅｑｕｅｓｔ−Ｔｏ−Ｓｅｎｄ）パケットを宛先端末へ送信し、データパケットを送信しようする他の無線端末は、前記ＲＴＳパケットを受信すると待機端末としてＲＴＳパケットの送信を延期し、前記送信端末は、宛先端末から返信されるＣＴＳ（Ｃｌｅａｒ−Ｔｏ−Ｓｅｎｄ）パケットに応答してデータパケットを送信する無線アクセス制御方法において、
前記送信端末は、今回のＲＴＳパケットに、次回のＲＴＳパケットの送信タイミングを規定する送信タイミング情報を登録して送信し、
前記待機端末は、前記今回のＲＴＳパケットを受信すると、当該ＲＴＳパケットに登録されている前記送信タイミング情報を抽出し、前記次回のＲＴＳパケットの送信タイミングに基づいて自身のパケットの送信タイミングを決定することを特徴とする無線アクセス制御方法。
【請求項２】
前記待機端末は、自端末のＲＴＳパケットを、前記送信端末の次回のＲＴＳパケットと重ならないように送信することを特徴とする請求項１に記載の無線アクセス制御方法。
【請求項３】
前記待機端末は、自端末のＲＴＳパケットを、当該ＲＴＳパケットを含む一連のＣＴＳパケット、データパケットおよびＡＣＫパケットが前記送信端末の次回のＲＴＳパケットと重ならないように送信することを特徴とする請求項１に記載の無線アクセス制御方法。
【請求項４】
前記宛先端末が、受信したＲＴＳパケットに登録されている前記送信タイミング情報を抽出し、これをＣＴＳパケットに転記して返信することを特徴とする請求項１ないし３のいずれかに記載の無線アクセス制御方法。
【請求項５】
前記送信端末は、今回のＲＴＳパケットに、当該呼の優先度を代表する呼種別情報ＡＣを登録して送信し、
前記待機端末は、受信した今回のＲＴＳパケットから前記送信タイミング情報および呼種別情報ＡＣを抽出し、前記呼種別情報ＡＣに応じて、少なくとも自端末のＲＴＳパケットが前記次回のＲＴＳパケットと重ならないように各パケットの送信タイミングを制御することを特徴とする請求項１ないし４のいずれかに記載の無線アクセス制御方法。
【請求項６】
前記待機端末は、受信したＲＴＳパケットに登録されている呼種別情報ＡＣと自身が確立しようとする呼の呼種別情報ＡＣ’とを比較し、自身の優先度が送信端末の優先度よりも高ければ、自身のＲＴＳパケットを、前記送信端末の次回のＲＴＳパケットと重ならないように送信することを特徴とする請求項５に記載の無線アクセス制御方法。
【請求項７】
前記待機端末は、受信したＲＴＳパケットに登録されている呼種別情報ＡＣと自身が確立しようとする呼の呼種別情報ＡＣ’とを比較し、自身の優先度が送信端末の優先度よりも低ければ、自身のＲＴＳパケットを、当該ＲＴＳパケットを含む一連のＣＴＳパケット、データパケットおよびＡＣＫパケットが前記送信端末の次回のＲＴＳパケットと重ならないように送信することを特徴とする請求項５に記載の無線アクセス制御方法。
【請求項８】
前記宛先端末が、前記今回のＲＴＳパケットを受信すると、当該ＲＴＳパケットに登録されている前記次回のＲＴＳパケットの送信タイミングおよび呼種別情報ＡＣを抽出し、これをＣＴＳパケットに登録して返信することを特徴とする請求項５ないし７のいずれかに記載の無線アクセス制御方法。
【請求項９】
データパケットを送信する際に予めＲＴＳ（Ｒｅｑｕｅｓｔ−Ｔｏ−Ｓｅｎｄ）パケットを送信し、宛先端末から返信されるＣＴＳ（Ｃｌｅａｒ−Ｔｏ−Ｓｅｎｄ）パケットに応答してデータパケットを送信する一方、他の無線端末から送信されたＲＴＳパケットを受信するとＲＴＳパケット送信を延期する無線端末において、
今回のＲＴＳパケットに、次回のＲＴＳパケットの送信タイミングを規定する送信タイミング情報を登録する送信タイミング情報登録手段と、
前記ＲＴＳパケットを送信するＲＴＳパケット送信手段と、
他の無線端末から送信されたＲＴＳパケットを受信する手段と、
前記受信したＲＴＳパケットから前記次回のＲＴＳパケットの送信タイミング情報を抽出する送信タイミング情報抽出手段と、
前記抽出された送信タイミングに基づいて自身のパケットの送信タイミングを決定する送信タイミング決定手段とを含むことを特徴とする無線端末。
【請求項１０】
前記送信タイミング決定手段は、自端末のＲＴＳパケットを、他の無線端末による次回のＲＴＳパケットと重ならないように送信することを特徴とする請求項９に記載の無線端末。
【請求項１１】
前記送信タイミング決定手段は、自身のＲＴＳパケットを、当該ＲＴＳパケットを含む一連のＣＴＳパケット、データパケットおよびＡＣＫパケットが他の無線端末による次回のＲＴＳパケットと重ならないように送信することを特徴とする請求項９に記載の無線端末。
【請求項１２】
自端末宛のＲＴＳパケットを受信すると、これに応答して返信するＣＴＳパケットに、当該ＲＴＳパケットに登録されている前記送信タイミング情報を転記する送信タイミング情報転記手段を含むことを特徴とする請求項９ないし１１のいずれかに記載の無線端末。
【請求項１３】
送信するＲＴＳパケットに当該呼の優先度を代表する呼種別情報ＡＣを登録する呼種別情報登録手段と、
受信したＲＴＳパケットに登録されている呼種別情報ＡＣを抽出する呼種別情報抽出手段とを含み、
前記送信タイミング決定手段は、受信したＲＴＳパケットに登録されている呼種別情報ＡＣと自端末が確立しようとする呼の呼種別情報ＡＣ’とに基づいて両者の優先度を比較し、自端末の優先度が相手端末の優先度よりも高ければ、自端末のＲＴＳパケットを、前記次回のＲＴＳパケットと重ならないように送信させることを特徴とする請求項９ないし１２のいずれかに記載の無線端末。
【請求項１４】
送信するＲＴＳパケットに当該呼の優先度を代表する呼種別情報ＡＣを登録する呼種別情報登録手段と、
受信したＲＴＳパケットに登録されている呼種別情報ＡＣを抽出する呼種別情報抽出手段とを含み、
前記送信タイミング決定手段は、受信したＲＴＳパケットに登録されている呼種別情報ＡＣと自端末が確立しようとする呼の呼種別情報ＡＣ’とに基づいて両者の優先度を比較し、自端末の優先度が相手端末の優先度よりも低ければ、自端末のＲＴＳパケットを含む一連のＣＴＳパケット、データパケットおよびＡＣＫパケットを、前記次回のＲＴＳパケットと重ならないように送信させることを特徴とする請求項９ないし１２のいずれかに記載の無線端末。
【請求項１５】
前記ＲＴＳパケットを受信すると、当該ＲＴＳパケットに登録されている呼種別情報ＡＣをＣＴＳパケットに転記する呼種別情報転記手段を含むことを特徴とする請求項１３または１４に記載の無線端末。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、無線端末およびその無線アクセス制御方法に係り、特に、送受信端末間でのデータ送信に先立ってＲＴＳ（Ｒｅｑｕｅｓｔ−Ｔｏ−Ｓｅｎｄ）およびＣＴＳ（Ｃｌｅａｒ−Ｔｏ−Ｓｅｎｄ）の各パケットを交換して回線の予約と予約状況の周知とを行う無線通信プロトコルを採用する無線端末およびその無線アクセス制御方法に関する。
【０００２】
【従来の技術】
自律分散型の無線アクセス制御（Ｍｅｄｉｕｍ  Ａｃｃｅｓｓ  Ｃｏｎｔｒｏｌ：  ＭＡＣ）プロトコルでは、基地局などの制御局は各端末の無線アクセスのタイミングを制御せず、各端末が独自に無線アクセスのタイミングを決定する。このような自律分散型ＭＡＣプロトコルは、無線ＬＡＮシステムのみならず、基地局を介さずに端末同士が直接通信するアドホックネットワークでも使用される。また、セルラーシステムのように、基地局やアクセスポイントが存在するシステムでも、基地局（もしくはアクセスポイント）の通信可能範囲が狭いためにマルチホップによって通信を行うマルチホップ型無線通信システムでは、自律分散型ＭＡＣプロトコルの使用が検討されている。
【０００３】
現在、無線ＬＡＮ  におけるＭＡＣ  プロトコルとして、端末がパケットを送信する前に送信する搬送波（キャリア）の検出（キャリアセンス）を行い、搬送波が検出されなければ自身のパケットを送信するＣＳＭＡ（Ｃａｒｒｉｅｒ  Ｓｅｎｓｅ  Ｍｕｌｔｉｐｌｅ  Ａｃｃｅｓｓ）方式、およびこのＣＳＭＡ  方式に、さらにパケットの衝突回避機能を付加したＣＳＭＡ／ＣＡ  （ＣＳＭＡ  ｗｉｔｈ  Ｃｏｌｌｉｓｉｏｎ  Ａｖｏｉｄａｎｃｅ）方式が用いられるようになってきている。
【０００４】
上記したＣＳＭＡやＣＳＭＡ／ＣＡなどの自律分散型ＭＡＣプロトコルでは、データパケットの送受信前に送受信端末間で回線の予約が行われず、また回線予約の状況を周辺の無線局（端末）に周知することも行われない。このため、互いに通信できない複数の無線局（端末）が、これらの端末にとって共通に通信可能な端末と通信を行おうとする「隠れ端末問題」が存在し、スループットの劣化が生じる。このような隠れ端末問題に対応すべく、送受信端末間でＲＴＳ（Ｒｅｑｕｅｓｔ−Ｔｏ−Ｓｅｎｄ）パケットとＣＴＳ（Ｃｌｅａｒ−Ｔｏ−Ｓｅｎｄ）パケットを事前に交換し、回線の予約と予約状況の周知を行う、ＭＡＣＡ（Ｍｕｌｔｉｐｌｅ  Ａｃｃｅｓｓ  ｗｉｔｈ  Ｃｏｌｌｉｓｉｏｎ  Ａｖｏｉｄａｎｃｅ）と呼ばれる自律分散型ＭＡＣプロトコルが考案されている。
【０００５】
図１０は、前記ＭＡＣＡの概要を示した図であり、送信端末は、データフレームの送信に先立ってＲＴＳパケットを送信する。これに応答して宛先端末からＣＴＳパケットが返信されればデータパケットＤＡＴＡを送信し、ＣＴＳパケットが返信され無ければ、無線リソースを他の資源に振り分け等する。データパケットＤＡＴＡを正常に受信し終えた宛先端末はＡＣＫパケットを返信する。
【０００６】
このＭＡＣＡを発展させた自律分散型プロトコルが、無線ＬＡＮシステムでの自律分散型プロトコルとして標準化され、無線ＬＡＮシステムで採用されているＩＥＥＥ  ８０２．１１  ＤＣＦ（Ｄｉｓｔｒｉｂｕｔｅｄ  Ｃｏｏｒｄｉｎａｔｅｄ  Ｆｕｎｃｔｉｏｎ）である。
【０００７】
図１１はＩＥＥＥ  ８０２．１１  ＤＣＦプロトコルのシーケンスの概要を示した図であり、送信すべきパケットが発生した送信端末は、キャリアセンスによってチャネルの状態を調べる。チャネルがアイドルであると、更にＤＩＦＳの時間だけアイドル状態が継続した後にデータを直ちに送信する。キャリアセンスした際、チャネルがビジー状態であれば、チャネルがアイドルになるまで待機する。そして、チャネルがアイドルになってからＤＩＦＳ  の時間だけアイドル状態が継続した後、送信すべきデータを有する他の複数の端末が同時にＲＴＳパケットを送信して衝突が生じることを防止するために、Ｂａｃｋｏｆｆ  Ｗｉｎｄｏｗと呼ばれる待機モードへ移行する。Ｂａｃｋｏｆｆ  Ｗｉｎｄｏｗでの待機時間ｔｗは、Ｃｏｎｔｅｎｔｉｏｎ  Ｗｉｎｄｏｗと呼ばれる時間幅の中から一様乱数を用いて決定され、カウンタにセットされる。
【０００８】
バックオフに入った端末は単位時間Δｔごとにキャリアセンスを実行し、チャネルがアイドルであればカウンタを減らし、チャネルがビジーであればチャネルがアイドルになるまでカウンタを止めておき、チャネルがアイドルになり次第、再びカウンタを減らしていく。
【０００９】
カウンタが０になると自身のＲＴＳパケットを送信する。ここでは、複数の端末のカウンタが同時に０にならなければＲＴＳパケットの衝突は起らずに送信が行われる。複数の端末のカウンタが同時に０になるとＲＴＳパケットの衝突が発生する。このような場合には、ＢＥＢ（Ｂｉｎａｒｙ  Ｅｘｐｏｎｅｎｔｉａｌ  Ｂａｃｋｏｆｆ）と呼ばれる機能が作用してＣｏｎｔｅｎｔｉｏｎ  Ｗｉｎｄｏｗの時間が２倍に増加する。
【００１０】
ＲＴＳパケットを受信した全ての端末は、そのｄｕｒａｔｉｏｎ  ｆｉｅｌｄ  を読み取る。送信されたパケットが自分宛でないことを確認した端末は、ＮＡＶ  （Ｎｅｔｗｏｒｋ  Ａｌｌｏｃａｔｉｏｎ  Ｖｅｃｔｏｒ）  をセットし、それにしたがって現在送信中のパケットとそれに対するＡＣＫ  が返ってくるまでの間、何もせずに待機する。宛先端末は、ＲＴＳパケットを受け取るとＣＴＳ  パケットを返信する。宛先端末以外の他端末は、前記ＣＴＳパケットのｄｕｒａｔｉｏｎ  ｆｉｅｌｄ  を読み取ってＮＡＶ  を更新する。送信端末は、ＣＴＳパケットを正確に受け取るとデータパケットの送信が成功したことを確認できる。
【００１１】
上記した従来のＩＥＥＥ  ８０２．１１  ＤＣＦでは、トラヒックの種別（ＡＣ：  Ａｃｃｅｓｓ  Ｃａｔｅｇｏｒｙ）ごとに異なる要求サービス品質（ＱｏＳ：  Ｑｕａｌｉｔｙ  ｏｆ  Ｓｅｒｖｉｃｅ）が考慮されていないため、現在、ＩＥＥＥ  ８０２．１１  Ｔａｓｋ  Ｇｒｏｕｐ  Ｅでは、ＱｏＳを考慮したＤＣＦの標準化を進めている（ＥＤＣＦ：  Ｅｎｈａｎｃｅｄ  ＤＣＦと呼ばれる）。このＥＤＣＦではＱｏＳを考慮し、トラヒックの種別ＡＣごとにＣｏｎｔｅｎｔｉｏｎ  Ｗｉｎｄｏｗを設定できるようにするなどのＡＣによる差別化を図っている。
【００１２】
ＲＴＳパケットとＣＴＳパケットとを使用した自律分散型ＭＡＣプロトコルに関しては、上記のＩＥＥＥ  ８０２．１１  ＤＣＦやＤＣＦの拡張版であるＥＤＣＦの他、さまざまなプロトコルが提案されている。たとえば、電子情報通信学会２００２年総合大会Ｂ−５−２７０では、送信範囲が異なる端末が存在する場合の問題、さらに具体的に言えば、小電力端末から送信されるＲＴＳパケットやＣＴＳパケットが周辺の端末に届かないために、他の大電力端末は無線チャネルが空いていると判断し、パケットを送信することによって、小電力端末の送受信に干渉を与えるという問題に対し、小電力端末から送信されたＲＴＳパケットやＣＴＳパケットを大電力端末が転送することにより、周辺端末への周知を行う方式が提案されている。
【００１３】
また、電波伝搬距離やフェージングの影響によって、無線ＬＡＮのアクセスポイント（セルラーシステムの基地局に相当）で受信する端末の信号強度が異なると、ＲＴＳパケットが衝突したとしても受信電力が強い端末では受信され、受信電力が低い端末では破棄される。また、受信電力値が大きな端末へのＣＴＳパケット送信と受信電力値の小さな端末からのＲＴＳパケット送信とが重なると、受信電力値の小さな端末は他端末へのＣＴＳを認識することができず、ＲＴＳパケット送信を繰り返すという結果になる。
【００１４】
このような問題を解決するために、電子情報通信学会２０００年ソサイエティ大会Ｂ−５−１６５では、ＲＴＳパケットの受信後、ＣＴＳパケットの送信までの時間を長く設定し、その間、アクセスポイントがキャリアセンスを行い、ＣＴＳパケット送信とＲＴＳパケット受信とが重ならないようにする技術が開示されている。
【００１５】
さらに、電子情報通信学会２００１年総合大会Ｂ−５−２８０では、１フレームを予約部とデータ部とに分け、予約部をさらに即時系専用予約スロットと待時系専用予約スロットとに分けている。即時系の呼（たとえば、音声呼）が一度スロットを予約すると、連続して同じスロットが予約され、待時系の呼（たとえば、データ呼）は即時系の呼に割り当てられたスロット以外が使用可能である。これによって、要求サービス品質を考慮したＭＡＣプロトコルが実現される（なお、このような考え方は、ＰＲＭＡ：  Ｐａｃｋｅｔ  Ｒｅｓｅｒｖａｔｉｏｎ  Ｍｕｌｔｉｐｌｅ  Ａｃｃｅｓｓと呼ばれる、基地局制御型のＭＡＣとして公知である）。
【００１６】
しかしながら、このプロトコルを適用するためには、すべての無線局（端末）がフレーム単位の時刻同期を確立する必要があるため、この論文では、ＧＰＳによる時刻同期が前提となっている。
【００１７】
【発明が解決しようとする課題】
前記ＩＥＥＥ  ８０２．１１  ＤＣＦや、現在標準化活動が進められているＥＤＣＦでは、各端末が独自にＢａｃｋ−ｏｆｆ  Ｗｉｎｄｏｗを決定し、決定した値に基づいてＲＴＳパケットを送信しているためにＲＴＳパケットの衝突が発生しやすい。そして、これを回避するためにＣｏｎｔｅｎｔｉｏｎ  Ｗｉｎｄｏｗが広く設定されるが、Ｃｏｎｔｅｎｔｉｏｎ  Ｗｉｎｄｏｗが増加すると、相対的に無送信時間、すなわち無線資源を使用していない時間が増える。このため、無線資源を効率的に使用できないのみならず、データ送信までの待ち時間が増加し、スループットが向上しないという結果になる。
【００１８】
また、上記した従来の送信電力や受信電力の差を考慮したＭＡＣプロトコルでも、ＲＴＳパケットの衝突を避ける工夫がなされておらず、またＱｏＳも考慮されていない。
【００１９】
さらに、ＶｏＩＰ（Ｖｏｉｃｅ  Ｏｖｅｒ  ＩＰ）呼のように、符号化された音声パケットが周期的に回線に送出され、また、パケットの送出ジッタを最小限に抑えたい呼の場合でも、ＥＤＣＦではＲＴＳパケットの衝突が発生するために、送信ジッタの抑制に対する直接的な対処は考えられていない。
【００２０】
さらに、ＰＲＭＡプロトコルの考え方を導入した、自律分散型ＭＡＣプロトコルは、即時呼のＱｏＳを考慮しているが、時刻同期を前提とするために、その適用が容易ではなく、汎用性も劣る。
【００２１】
本発明の目的は、上記した従来技術の課題を解決し、ＲＴＳパケットの衝突を可能な限り回避し、かつＶｏＩＰ呼のように周期的にデータパケットが発生する呼のジッタを最小限に抑えられる無線端末およびその無線アクセス制御方法を提供することにある。
【００２２】
【課題を解決するための手段】
上記した目的を達成するために、本発明は、データパケットを送信する際に予めＲＴＳパケットを送信し、宛先端末から返信されるＣＴＳパケットに応答してデータパケットを送信する一方、他の無線端末から送信されたＲＴＳパケットを受信するとＲＴＳパケット送信を延期する無線端末において、以下のような手段を講じた点に特徴がある。
【００２３】
（１）今回のＲＴＳパケットに、次回のＲＴＳパケットの送信タイミングを規定する送信タイミング情報を登録する送信タイミング情報登録手段と、ＲＴＳパケットを送信するＲＴＳパケット送信手段と、他の無線端末から送信されたＲＴＳパケットを受信する手段と、受信したＲＴＳパケットから前記次回のＲＴＳパケットの送信タイミング情報を抽出する送信タイミング情報抽出手段と、抽出された送信タイミングを避けて自身のパケットの送信タイミングを決定する送信タイミング決定手段とを含むことを特徴とする。
【００２４】
（２）自端末宛のＲＴＳパケットを受信すると、これに応答して返信するＣＴＳパケットに、当該ＲＴＳパケットに登録されている送信タイミング情報を転記する送信タイミング情報転記手段を含むことを特徴とする。
【００２５】
（３）送信するＲＴＳパケットに当該呼の優先度を代表する呼種別情報ＡＣを登録する呼種別情報登録手段と、受信したＲＴＳパケットに登録されている呼種別情報ＡＣを抽出する呼種別情報抽出手段とを含み、送信タイミング決定手段は、受信したＲＴＳパケットに登録されている呼種別情報ＡＣと自端末が確立しようとする呼の呼種別情報ＡＣ’とに基づいて両者の優先度を比較し、この比較結果と送信タイミング情報とに基づいて、自端末からのパケットの送信タイミングを決定することを特徴とする。
【００２６】
上記した特徴（１）によれば、待機端末のＲＴＳパケットは、送信端末のＲＴＳパケットの送信タイミングを避けて送信されるので、送信端末からのＲＴＳパケットの送信が待機端末のＲＴＳパケットにより妨げられることがない。
【００２７】
上記した特徴（２）によれば、送信端末からＲＴＳパケットを受信できない待機端末（隠れ端末）も、その宛先端末から送信される、次回のＲＴＳパケットの送信タイミング情報が転記されたＣＴＳパケットを受信できるので、いわゆる隠れ端末問題が解消される。その結果、ＣＴＳパケットを受信できた隠れ端末からのＲＴＳパケットは、送信端末のＲＴＳパケットの送信タイミングを避けて送信されるので、送信端末からのＲＴＳパケットの送信が隠れ端末のＲＴＳパケットにより妨げられることがない。
【００２８】
上記した特徴（３）によれば、待機端末のＲＴＳパケット送信タイミングが、送信端末および待機端末の優先度を考慮して決定されるので、優先度の低い呼が優先されたり、優先度の高い呼の品質が低下したりするなどの問題が解消される。
【００２９】
【発明の実施の形態】
以下、図面を参照して本発明の好ましい実施の形態について詳細に説明する。図１は、本発明に係る無線端末の第１実施形態の機能ブロック図であり、ここでは、無線端末の動作を以下の３つの状態（１）〜（３）に分類して説明する。
【００３０】
（１）送信すべきデータパケットを所有し、かつＲＴＣパケットを送信できた「送信端末」として動作する場合。
（２）データパケットを受信する「宛先端末」として動作する場合。
（３）送信すべきデータパケットを所有するもののＲＴＣパケットを送信できない「待機端末」として動作する場合。
【００３１】
図１では、主に「送信端末」としての動作に必要な機能ブロックに添字［Ｓ］を付し、主に「宛先端末」としての動作に必要な機能ブロックに添字［Ｄ］を付し、主に「待機端末」としての動作に必要な機能ブロックに添字［Ｗ］を付している。
【００３２】
送信タイミング情報登録部１１［Ｓ］は、データパケットの送信に先立って、自端末から送信する今回のＲＴＳパケット▲１▼に、次回のＲＴＣパケット▲２▼の送信タイミングを特定する送信タイミング情報を登録する。本実施形態では、送信タイミング情報として、例えば次回のＲＴＳパケット▲２▼の送信時刻やＢａｃｋ−ｏｆｆ  Ｗｉｎｄｏｗを登録する。ＲＴＳパケット送信部１０［Ｓ］は、前記送信タイミング情報の登録されたＲＴＳパケットを送信する。
【００３３】
ＲＴＳパケット受信部２０［Ｄ］［Ｗ］は、送信端末から上記のようにして送信されたＲＴＳパケット▲１▼を受信する。送信タイミング情報抽出部２１［Ｗ］は、受信したＲＴＳパケットに登録されている送信タイミング情報を抽出する。送信タイミング決定部２３［Ｗ］は、前記抽出された送信タイミング情報に基づいて送信端末による次回のＲＴＳパケット▲２▼の送信タイミングを判別し、このＲＴＳパケット▲２▼と衝突しない送信タイミングを、自端末（待機端末）からのＲＴＳパケットの送信タイミングとして決定する。
【００３４】
ＣＴＳパケット送信部３０［Ｄ］は、自端末を宛先とするＲＴＳパケットを受信すると、これに応答して、その送信元である送信端末に向けてＣＴＳパケットを送信する。ＣＴＳパケット受信部４０［Ｓ］は、前記宛先端末から送信されたＣＴＳパケットを受信する。
【００３５】
図２は、本実施形態の動作を示したタイミングチャートであり、ここでは、無線端末間で送受信されるパケットのみに着目し、Ｂａｃｋ−ｏｆｆ  Ｗｉｎｄｏｗ、ＤＩＦＳ、ＳＩＦＳ等の各期間は図示を省略している。
【００３６】
送信端末は、送信しようとする今回のＲＴＳパケット▲１▼に、前記送信タイミング情報登録部１１において次回のＲＴＳパケット▲２▼の送信タイミング情報を登録し、これをＲＴＳパケット送信部１０から送信する。
【００３７】
宛先端末は、前記ＲＴＳパケット受信部２０において自端末を宛先とする今回のＲＴＳパケット▲１▼を受信すると、これに応答して前記ＣＴＳパケット送信部３０から、送信端末を宛先としてＣＴＳパケットを送信する。
【００３８】
待機端末は、前記ＲＴＳパケット受信部２０において、自端末以外を宛先とする今回のＲＴＳパケット▲１▼を受信すると、このＲＴＳパケット▲１▼に登録されている次回のＲＴＳパケット▲２▼の送信タイミング情報を前記送信タイミング情報抽出部２１で抽出する。送信タイミング決定部２３は、次回のＲＴＳパケット▲２▼の送信タイミングを自端末（待機端末）からのＲＴＳパケットの送信禁止期間と認識し、それ以外の期間からＲＴＳパケットの送信タイミングを決定する。
【００３９】
さらに具体的に言えば、全ての待機端末は、前記次回のＲＴＳパケット▲２▼の送信開始時刻をＴＲＴＳ（ｉ）、このＲＴＳパケットの送信に要する時間をＤＲＴＳ（ｉ）とすれば、時刻ＴＲＴＳ（ｉ）から時刻［ＴＲＴＳ（ｉ）＋ＤＲＴＳ（ｉ）］の期間［ＴＲＴＳ（ｉ），  ＴＲＴＳ（ｉ）＋  ＤＲＴＳ（ｉ）］が自端末のＲＴＳパケットの送信期間と重ならないように、その送信タイミングを決定する。なお、ＲＴＳパケットの送信タイミングは、前記［ＴＲＴＳ（ｉ），  ＴＲＴＳ（ｉ）＋  ＤＲＴＳ（ｉ）］の期間以外であれば、ＩＥＥＥ  ８０２．１１  ＤＣＦやＥＤＣＦのように、Ｃｏｎｔｅｎｔｉｏｎ  Ｗｉｎｄｏｗ内から乱数により決定してもよい。
【００４０】
本実施形態によれば、待機端末のＲＴＳパケットは、送信端末のＲＴＳパケットの送信タイミングを避けて送信されるので、送信端末からのＲＴＳパケットの送信が待機端末のＲＴＳパケットにより妨げられることがない。
【００４１】
なお、送信端末の送信を優先させたいのであれば、図３に示したように、待機端末は、自端末からのパケット送信に必要な時間（ＲＴＳパケットの送信からＡＣＫパケットの受信までの時間）をＤＦとしたとき、自端末のＲＴＳ送信タイミングを、ＴＲＴＳ（ｊ）−ＤＦより前の時刻か、ＴＲＴＳ（ｊ）＋  ＤＲＴＳ（ｊ）より後の時刻に決定する。このようにすれば、送信端末／宛先端末間でのパケット交換が待機端末によって妨げられることがないので、特に、送信端末の呼がリアルタイム通信のようにジッタの発生を最小限に抑えたい場合に有効である。
【００４２】
図４は、本発明に係る無線端末の第２実施形態の機能ブロック図であり、前記と同一の符号は同一または同等部分を表している。
【００４３】
送信タイミング情報転記部３１［Ｄ］は、当該無線端末が宛先端末として機能する際に、送信端末から受信したＲＴＳパケットに応答して返信するＣＴＳパケットに、当該ＲＴＳパケットから抽出した送信タイミング情報を転記する。ＣＴＳパケット送信部３０［Ｄ］は、前記送信タイミング情報の転記されたＣＴＳパケットを前記と同様に送信する。
【００４４】
ＣＴＳパケット受信部４０［Ｗ］は、当該無線端末が主に待機端末として機能する際に、宛先端末から送信されたＣＴＳパケットを受信する。送信タイミング情報抽出部４１［Ｗ］は、受信したＣＴＳパケットに登録されている送信タイミング情報を抽出する。送信タイミング決定部４３［Ｗ］は、前記抽出された送信タイミング情報に基づいて次回のＲＴＳパケット▲２▼の送信タイミングを判別し、このＲＴＳパケット▲２▼と衝突しない送信タイミングを、自端末（待機端末）によるＲＴＳパケットの送信タイミングとして決定する。
【００４５】
前記ＲＴＳパケット送信部１０［Ｗ］は、前記送信タイミング決定部２３［Ｗ］で決定された送信タイミング、または前記送信タイミング決定部４３［Ｗ］で決定された送信タイミングでＲＴＳパケットを送信する。
【００４６】
図５は、本実施形態における送信端末、宛先端末および２つの待機端末Ａ，Ｂの動作を示したタイミングチャートであり、ここでは、図６に示したように、待機端末Ｂと送信端末および待機端末Ａとの通信が遮蔽物５０により遮られている場合を例にして説明する。
【００４７】
宛先端末は、今回のＲＴＳパケット▲１▼をＲＴＳパケット受信部２０で受信すると、このＲＴＳパケット▲１▼に登録されている次回のＲＴＳパケット▲２▼の送信タイミング情報を送信タイミング情報抽出部２１で抽出する。送信タイミング情報転記部３１は、前記抽出された送信タイミング情報をＣＴＳパケット▲１▼に転記し、ＣＴＳパケット送信部３０から送信する。
【００４８】
一方の待機端末Ａは、前記今回のＲＴＳパケット▲１▼を送信端末から受信できるので、このＲＴＳパケット▲１▼に登録されている次回のＲＴＳパケット▲２▼の送信タイミング情報を抽出し、この期間をＲＴＳ送信禁止期間と認識し、それ以外の期間をＲＴＳ送信タイミングとして決定する。
【００４９】
他方の待機端末Ｂは、送信端末からは今回のＲＴＳパケット▲１▼を受信できないものの、宛先端末から送信されたＣＴＳパケット▲１▼を受信し、送信タイミング情報抽出部４１において、前記ＣＴＳパケット▲１▼から送信タイミング情報を抽出する。送信タイミング決定部４３は、送信タイミング情報に基づいてＲＴＳ送信禁止期間と認識し、それ以外の期間をＲＴＳ送信タイミングとして決定する。
【００５０】
本実施形態によれば、ＲＴＳパケットに登録されている送信タイミング情報が宛先端末においてＣＴＳパケットに転記されて送信されるので、いわゆる隠れ端末問題も解消される。
【００５１】
図７は、本発明に係る無線端末の第３実施形態の機能ブロック図であり、前記と同一の符号は同一または同等部分を表している。
【００５２】
呼種別情報登録部１２［Ｓ］は、当該無線端末が送信端末として機能する際、送信しようとするＲＴＣパケットに、当該呼の優先度を代表する呼種別情報ＡＣを登録する。ＲＴＳパケット送信部１０［Ｓ］は、前記送信タイミング情報および呼種別情報ＡＣの登録されたＲＴＳパケットを送信する。
【００５３】
本実施形態では、ＶｏＩＰ呼のように周期的にパケットを送出することを特徴とするリアルタイム呼のＡＣを「０１」、周期的にパケットを送出するわけではないがテレビ会議やライブビデオのように即時性が要求されるリアルタイム呼のＡＣを「０２」、即時性は要求されないものの比較的高いスループットや応答性が要求されるＷｅｂページのダウンロードなどのノンリアルタイム呼のＡＣを「１１」、さらには遅延やスループットの要求条件が比較的緩やかな電子メールのようなノンリアルタイム呼のＡＣを「１２」とし、呼種別情報ＡＣの優先度を、「０１」＞「０２」＞「１１」＞「１２」と定義する。
【００５４】
呼種別情報抽出部２２［Ｄ］［Ｗ］は、当該無線端末が宛先端末または待機端末として機能する際に、送信端末から上記と同様にして送信されたＲＴＳパケットに登録されている呼種別情報ＡＣを抽出する。送信タイミング決定部２３［Ｗ］は、前記抽出された送信タイミング情報に基づいて前記他の無線端末から送信される次回のＲＴＳパケットの送信タイミングを識別すると共に、前記抽出した呼種別情報ＡＣに基づいて、当該呼の優先度を自端末が確立しようとしている呼の優先度と比較する。そして、優先度の比較結果と次回のＲＴＳパケットの送信タイミングとに基づいて、自端末によるＲＴＳパケットの送信タイミングを決定する。
【００５５】
呼種別情報転記部３２［Ｄ］は、当該無線端末が宛先端末として機能する際、受信したＲＴＳパケットに応答して返信するＣＴＳパケットに、当該ＲＴＳパケットから抽出した呼種別情報ＡＣを転記する。ＣＴＳパケット送信部３０［Ｄ］は、前記送信タイミング情報および呼種別情報ＡＣの転記されたＣＴＳパケットを送信する。
【００５６】
呼種別情報抽出部４２［Ｗ］は、当該無線端末が待機端末として機能する際に、宛先端末から送信されたＣＴＳパケットに登録されている呼種別情報ＡＣを抽出する。送信タイミング決定部４３［Ｗ］は、前記抽出された送信タイミング情報に基づいて前記送信端末から送信される次回のＲＴＳパケット▲２▼の送信タイミングを識別すると共に、前記抽出した呼種別情報ＡＣに基づいて当該呼の優先度を自端末が確立しようとしている呼の優先度と比較する。そして、優先度の比較結果と次回のＲＴＳパケット▲２▼の送信タイミングとに基づいて、自端末によるＲＴＳパケットの送信タイミングとして決定する。
【００５７】
図８、９は、本実施形態における送信端末、宛先端末および待機端末の動作を示したタイミングチャートであり、図８は、送信端末の呼種別情報（ＡＣ）で代表される優先度が待機端末の優先度以下である場合の動作を示し、図９は、送信端末の優先度が待機端末の優先度よりも上位である場合の動作を示している。
【００５８】
送信端末優先度≦待機端末優先度であれば、図８に示したように、待機端末のＲＴＳパケットの送信タイミングは、送信端末の次回のＲＴＳパケット▲２▼の送信タイミングと重ならないように、その前後に設定される。すなわち、早い時刻にＲＴＳを送信した端末が優先される「Ｓｔｒａｉｇｈｔ−ｆｏｒｗａｒｄ」の処理となる。
【００５９】
これに対して、送信端末優先度＞待機端末優先度であれば、図９に示したように、待機端末のＲＴＳパケット〜ＡＣＫパケットの送信期間が送信端末のＲＴＳパケット▲２▼の送信タイミングと重ならないように、その前後に設定される。
【００６０】
本実施形態によれば、待機端末のＲＴＳパケット送信タイミングが、送信端末および待機端末の優先度を考慮して決定されるので、優先度の低い呼が優先されたり、優先度の高い呼の品質が低下したりするなどの問題が解消される。
【００６１】
なお、上記した各実施形態では、今回のＲＴＳパケット▲１▼に、次回のＲＴＳパケット▲２▼の送信タイミング情報のみを登録し、あるいは送信タイミング情報と共に呼種別情報ＡＣを登録するものとして説明したが、本発明はこれのみに限定されるものではなく、送信タイミング情報を登録することなく呼種別情報ＡＣのみを登録するようにしても良い。
【００６２】
この場合には、呼種別情報ＡＣ毎に次回のＲＴＳパケット送信タイミングをあらかじめ定義しておくか、あるいは、ＩＥＥＥ  ８０２．１１  ＤＣＦやＥＤＣＦのように、各呼種別情報ＡＣで定められたＣｏｎｔｅｎｔｉｏｎ  Ｗｉｎｄｏｗから選択されるであろう各Ｂａｃｋ−ｏｆｆ  Ｗｉｎｄｏｗの確率を算出し（一様乱数を使用すると、同じ確率値となる）、衝突する確率がもっとも低いと思われる時刻を各端末がＲＴＳ送信タイミングとして決定すれば良い。
【００６３】
【発明の効果】
本発明によれば、ＲＴＳパケットの衝突を回避しやすくなるため、結果的にＣｏｎｔｅｎｔｉｏｎ  Ｗｉｎｄｏｗの狭小化が図れ、無線資源の有効利用やデータパケット送出遅延の削減、スループットの向上が実現できる。また、周期的にデータパケットが発生する呼のパケット送信タイミングを阻害しないため、ジッタに対して敏感な呼のＱｏＳを満足することが可能となる。
【図面の簡単な説明】
【図１】本発明に係る無線端末の第１実施形態の機能ブロック図である。
【図２】第１実施形態のタイミングチャート（その１）である。
【図３】第１実施形態のタイミングチャート（その２）である
【図４】本発明に係る無線端末の第２実施形態の機能ブロック図である。
【図５】第２実施形態のタイミングチャートである
【図６】第２実施形態による隠れ端末問題の解消方法を示した図である。
【図７】本発明に係る無線端末の第３実施形態の機能ブロック図である。
【図８】第３実施形態のタイミングチャート（その１）である。
【図９】第３実施形態のタイミングチャート（その２）である
【図１０】従来のＭＡＣＡの通信手順を示した図である。
【図１１】従来のＩＥＥＥ  ８０２．１１  ＤＣＦプロトコルのシーケンス図である。
【符号の説明】１０…ＲＴＳパケット送信部，１１…送信タイミング情報登録部，１２…呼種別情報登録部，２０…ＲＴＳパケット受信部，２１…送信タイミング情報抽出部，２２…呼種別情報抽出部，２３…送信タイミング決定部，３０…ＣＴＳパケット送信部，３１…送信タイミング情報転記部，３２…呼種別情報転記部，４０…ＣＴＳパケット受信部，４１…送信タイミング情報抽出部，４２…呼種別情報抽出部，４３…送信タイミング決定部
【図１】
2004180131.tif 000003
【図２】
2004180131.tif 000004
【図３】
2004180131.tif 000005
【図４】
2004180131.tif 000006
【図５】
2004180131.tif 000007
【図６】
2004180131.tif 000008
【図７】
2004180131.tif 000009
【図８】
2004180131.tif 000010
【図９】
2004180131.tif 000011
【図１０】
2004180131.tif 000012
【図１１】
2004180131.tif 000013