JP2004180131A - 無線端末およびその無線アクセス制御方法 - Google Patents

無線端末およびその無線アクセス制御方法 Download PDF

Info

Publication number
JP2004180131A
JP2004180131A JP2002346010A JP2002346010A JP2004180131A JP 2004180131 A JP2004180131 A JP 2004180131A JP 2002346010 A JP2002346010 A JP 2002346010A JP 2002346010 A JP2002346010 A JP 2002346010A JP 2004180131 A JP2004180131 A JP 2004180131A
Authority
JP
Japan
Prior art keywords
packet
terminal
rts packet
transmission timing
rts
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
JP2002346010A
Other languages
English (en)
Other versions
JP4042901B2 (ja
Inventor
Satoshi Konishi
聡 小西
Yoji Kishi
洋司 岸
Shinichi Nomoto
真一 野本
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
KDDI Corp
Original Assignee
KDDI Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by KDDI Corp filed Critical KDDI Corp
Priority to JP2002346010A priority Critical patent/JP4042901B2/ja
Publication of JP2004180131A publication Critical patent/JP2004180131A/ja
Application granted granted Critical
Publication of JP4042901B2 publication Critical patent/JP4042901B2/ja
Anticipated expiration legal-status Critical
Expired - Fee Related legal-status Critical Current

Links

Images

Landscapes

  • Small-Scale Networks (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

【課題】RTSパケットの衝突を可能な限り回避し、かつVoIP呼のように周期的にデータパケットが発生する呼のジッタを最小限に抑える。
【解決手段】送信タイミング情報登録部11は、自端末から送信する今回のRTSパケットに、次回のRTCパケットの送信タイミングを特定する送信タイミング情報を登録する。RTSパケット受信部20は送信端末から送信されたRTSパケットを受信する。送信タイミング情報抽出部21は、受信したRTSパケットに登録されている送信タイミング情報を抽出する。送信タイミング決定部23は、抽出された送信タイミング情報に基づいて送信端末による次回のRTSパケットの送信タイミングを判別し、このRTSパケットと衝突しない送信タイミングを、自端末からのRTSパケットの送信タイミングとして決定する。
【選択図】 図1

Description

【0001】
【発明の属する技術分野】
本発明は、無線端末およびその無線アクセス制御方法に係り、特に、送受信端末間でのデータ送信に先立ってRTS(Request−To−Send)およびCTS(Clear−To−Send)の各パケットを交換して回線の予約と予約状況の周知とを行う無線通信プロトコルを採用する無線端末およびその無線アクセス制御方法に関する。
【0002】
【従来の技術】
自律分散型の無線アクセス制御(Medium Access Control: MAC)プロトコルでは、基地局などの制御局は各端末の無線アクセスのタイミングを制御せず、各端末が独自に無線アクセスのタイミングを決定する。このような自律分散型MACプロトコルは、無線LANシステムのみならず、基地局を介さずに端末同士が直接通信するアドホックネットワークでも使用される。また、セルラーシステムのように、基地局やアクセスポイントが存在するシステムでも、基地局(もしくはアクセスポイント)の通信可能範囲が狭いためにマルチホップによって通信を行うマルチホップ型無線通信システムでは、自律分散型MACプロトコルの使用が検討されている。
【0003】
現在、無線LAN におけるMAC プロトコルとして、端末がパケットを送信する前に送信する搬送波(キャリア)の検出(キャリアセンス)を行い、搬送波が検出されなければ自身のパケットを送信するCSMA(Carrier Sense Multiple Access)方式、およびこのCSMA 方式に、さらにパケットの衝突回避機能を付加したCSMA/CA (CSMA with Collision Avoidance)方式が用いられるようになってきている。
【0004】
上記したCSMAやCSMA/CAなどの自律分散型MACプロトコルでは、データパケットの送受信前に送受信端末間で回線の予約が行われず、また回線予約の状況を周辺の無線局(端末)に周知することも行われない。このため、互いに通信できない複数の無線局(端末)が、これらの端末にとって共通に通信可能な端末と通信を行おうとする「隠れ端末問題」が存在し、スループットの劣化が生じる。このような隠れ端末問題に対応すべく、送受信端末間でRTS(Request−To−Send)パケットとCTS(Clear−To−Send)パケットを事前に交換し、回線の予約と予約状況の周知を行う、MACA(Multiple Access with Collision Avoidance)と呼ばれる自律分散型MACプロトコルが考案されている。
【0005】
図10は、前記MACAの概要を示した図であり、送信端末は、データフレームの送信に先立ってRTSパケットを送信する。これに応答して宛先端末からCTSパケットが返信されればデータパケットDATAを送信し、CTSパケットが返信され無ければ、無線リソースを他の資源に振り分け等する。データパケットDATAを正常に受信し終えた宛先端末はACKパケットを返信する。
【0006】
このMACAを発展させた自律分散型プロトコルが、無線LANシステムでの自律分散型プロトコルとして標準化され、無線LANシステムで採用されているIEEE 802.11 DCF(Distributed Coordinated Function)である。
【0007】
図11はIEEE 802.11 DCFプロトコルのシーケンスの概要を示した図であり、送信すべきパケットが発生した送信端末は、キャリアセンスによってチャネルの状態を調べる。チャネルがアイドルであると、更にDIFSの時間だけアイドル状態が継続した後にデータを直ちに送信する。キャリアセンスした際、チャネルがビジー状態であれば、チャネルがアイドルになるまで待機する。そして、チャネルがアイドルになってからDIFS の時間だけアイドル状態が継続した後、送信すべきデータを有する他の複数の端末が同時にRTSパケットを送信して衝突が生じることを防止するために、Backoff Windowと呼ばれる待機モードへ移行する。Backoff Windowでの待機時間twは、Contention Windowと呼ばれる時間幅の中から一様乱数を用いて決定され、カウンタにセットされる。
【0008】
バックオフに入った端末は単位時間Δtごとにキャリアセンスを実行し、チャネルがアイドルであればカウンタを減らし、チャネルがビジーであればチャネルがアイドルになるまでカウンタを止めておき、チャネルがアイドルになり次第、再びカウンタを減らしていく。
【0009】
カウンタが0になると自身のRTSパケットを送信する。ここでは、複数の端末のカウンタが同時に0にならなければRTSパケットの衝突は起らずに送信が行われる。複数の端末のカウンタが同時に0になるとRTSパケットの衝突が発生する。このような場合には、BEB(Binary Exponential Backoff)と呼ばれる機能が作用してContention Windowの時間が2倍に増加する。
【0010】
RTSパケットを受信した全ての端末は、そのduration field を読み取る。送信されたパケットが自分宛でないことを確認した端末は、NAV (Network Allocation Vector) をセットし、それにしたがって現在送信中のパケットとそれに対するACK が返ってくるまでの間、何もせずに待機する。宛先端末は、RTSパケットを受け取るとCTS パケットを返信する。宛先端末以外の他端末は、前記CTSパケットのduration field を読み取ってNAV を更新する。送信端末は、CTSパケットを正確に受け取るとデータパケットの送信が成功したことを確認できる。
【0011】
上記した従来の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による差別化を図っている。
【0012】
RTSパケットとCTSパケットとを使用した自律分散型MACプロトコルに関しては、上記のIEEE 802.11 DCFやDCFの拡張版であるEDCFの他、さまざまなプロトコルが提案されている。たとえば、電子情報通信学会2002年総合大会B−5−270では、送信範囲が異なる端末が存在する場合の問題、さらに具体的に言えば、小電力端末から送信されるRTSパケットやCTSパケットが周辺の端末に届かないために、他の大電力端末は無線チャネルが空いていると判断し、パケットを送信することによって、小電力端末の送受信に干渉を与えるという問題に対し、小電力端末から送信されたRTSパケットやCTSパケットを大電力端末が転送することにより、周辺端末への周知を行う方式が提案されている。
【0013】
また、電波伝搬距離やフェージングの影響によって、無線LANのアクセスポイント(セルラーシステムの基地局に相当)で受信する端末の信号強度が異なると、RTSパケットが衝突したとしても受信電力が強い端末では受信され、受信電力が低い端末では破棄される。また、受信電力値が大きな端末へのCTSパケット送信と受信電力値の小さな端末からのRTSパケット送信とが重なると、受信電力値の小さな端末は他端末へのCTSを認識することができず、RTSパケット送信を繰り返すという結果になる。
【0014】
このような問題を解決するために、電子情報通信学会2000年ソサイエティ大会B−5−165では、RTSパケットの受信後、CTSパケットの送信までの時間を長く設定し、その間、アクセスポイントがキャリアセンスを行い、CTSパケット送信とRTSパケット受信とが重ならないようにする技術が開示されている。
【0015】
さらに、電子情報通信学会2001年総合大会B−5−280では、1フレームを予約部とデータ部とに分け、予約部をさらに即時系専用予約スロットと待時系専用予約スロットとに分けている。即時系の呼(たとえば、音声呼)が一度スロットを予約すると、連続して同じスロットが予約され、待時系の呼(たとえば、データ呼)は即時系の呼に割り当てられたスロット以外が使用可能である。これによって、要求サービス品質を考慮したMACプロトコルが実現される(なお、このような考え方は、PRMA: Packet Reservation Multiple Accessと呼ばれる、基地局制御型のMACとして公知である)。
【0016】
しかしながら、このプロトコルを適用するためには、すべての無線局(端末)がフレーム単位の時刻同期を確立する必要があるため、この論文では、GPSによる時刻同期が前提となっている。
【0017】
【発明が解決しようとする課題】
前記IEEE 802.11 DCFや、現在標準化活動が進められているEDCFでは、各端末が独自にBack−off Windowを決定し、決定した値に基づいてRTSパケットを送信しているためにRTSパケットの衝突が発生しやすい。そして、これを回避するためにContention Windowが広く設定されるが、Contention Windowが増加すると、相対的に無送信時間、すなわち無線資源を使用していない時間が増える。このため、無線資源を効率的に使用できないのみならず、データ送信までの待ち時間が増加し、スループットが向上しないという結果になる。
【0018】
また、上記した従来の送信電力や受信電力の差を考慮したMACプロトコルでも、RTSパケットの衝突を避ける工夫がなされておらず、またQoSも考慮されていない。
【0019】
さらに、VoIP(Voice Over IP)呼のように、符号化された音声パケットが周期的に回線に送出され、また、パケットの送出ジッタを最小限に抑えたい呼の場合でも、EDCFではRTSパケットの衝突が発生するために、送信ジッタの抑制に対する直接的な対処は考えられていない。
【0020】
さらに、PRMAプロトコルの考え方を導入した、自律分散型MACプロトコルは、即時呼のQoSを考慮しているが、時刻同期を前提とするために、その適用が容易ではなく、汎用性も劣る。
【0021】
本発明の目的は、上記した従来技術の課題を解決し、RTSパケットの衝突を可能な限り回避し、かつVoIP呼のように周期的にデータパケットが発生する呼のジッタを最小限に抑えられる無線端末およびその無線アクセス制御方法を提供することにある。
【0022】
【課題を解決するための手段】
上記した目的を達成するために、本発明は、データパケットを送信する際に予めRTSパケットを送信し、宛先端末から返信されるCTSパケットに応答してデータパケットを送信する一方、他の無線端末から送信されたRTSパケットを受信するとRTSパケット送信を延期する無線端末において、以下のような手段を講じた点に特徴がある。
【0023】
(1)今回のRTSパケットに、次回のRTSパケットの送信タイミングを規定する送信タイミング情報を登録する送信タイミング情報登録手段と、RTSパケットを送信するRTSパケット送信手段と、他の無線端末から送信されたRTSパケットを受信する手段と、受信したRTSパケットから前記次回のRTSパケットの送信タイミング情報を抽出する送信タイミング情報抽出手段と、抽出された送信タイミングを避けて自身のパケットの送信タイミングを決定する送信タイミング決定手段とを含むことを特徴とする。
【0024】
(2)自端末宛のRTSパケットを受信すると、これに応答して返信するCTSパケットに、当該RTSパケットに登録されている送信タイミング情報を転記する送信タイミング情報転記手段を含むことを特徴とする。
【0025】
(3)送信するRTSパケットに当該呼の優先度を代表する呼種別情報ACを登録する呼種別情報登録手段と、受信したRTSパケットに登録されている呼種別情報ACを抽出する呼種別情報抽出手段とを含み、送信タイミング決定手段は、受信したRTSパケットに登録されている呼種別情報ACと自端末が確立しようとする呼の呼種別情報AC’とに基づいて両者の優先度を比較し、この比較結果と送信タイミング情報とに基づいて、自端末からのパケットの送信タイミングを決定することを特徴とする。
【0026】
上記した特徴(1)によれば、待機端末のRTSパケットは、送信端末のRTSパケットの送信タイミングを避けて送信されるので、送信端末からのRTSパケットの送信が待機端末のRTSパケットにより妨げられることがない。
【0027】
上記した特徴(2)によれば、送信端末からRTSパケットを受信できない待機端末(隠れ端末)も、その宛先端末から送信される、次回のRTSパケットの送信タイミング情報が転記されたCTSパケットを受信できるので、いわゆる隠れ端末問題が解消される。その結果、CTSパケットを受信できた隠れ端末からのRTSパケットは、送信端末のRTSパケットの送信タイミングを避けて送信されるので、送信端末からのRTSパケットの送信が隠れ端末のRTSパケットにより妨げられることがない。
【0028】
上記した特徴(3)によれば、待機端末のRTSパケット送信タイミングが、送信端末および待機端末の優先度を考慮して決定されるので、優先度の低い呼が優先されたり、優先度の高い呼の品質が低下したりするなどの問題が解消される。
【0029】
【発明の実施の形態】
以下、図面を参照して本発明の好ましい実施の形態について詳細に説明する。図1は、本発明に係る無線端末の第1実施形態の機能ブロック図であり、ここでは、無線端末の動作を以下の3つの状態(1)〜(3)に分類して説明する。
【0030】
(1)送信すべきデータパケットを所有し、かつRTCパケットを送信できた「送信端末」として動作する場合。
(2)データパケットを受信する「宛先端末」として動作する場合。
(3)送信すべきデータパケットを所有するもののRTCパケットを送信できない「待機端末」として動作する場合。
【0031】
図1では、主に「送信端末」としての動作に必要な機能ブロックに添字[S]を付し、主に「宛先端末」としての動作に必要な機能ブロックに添字[D]を付し、主に「待機端末」としての動作に必要な機能ブロックに添字[W]を付している。
【0032】
送信タイミング情報登録部11[S]は、データパケットの送信に先立って、自端末から送信する今回のRTSパケット▲1▼に、次回のRTCパケット▲2▼の送信タイミングを特定する送信タイミング情報を登録する。本実施形態では、送信タイミング情報として、例えば次回のRTSパケット▲2▼の送信時刻やBack−off Windowを登録する。RTSパケット送信部10[S]は、前記送信タイミング情報の登録されたRTSパケットを送信する。
【0033】
RTSパケット受信部20[D][W]は、送信端末から上記のようにして送信されたRTSパケット▲1▼を受信する。送信タイミング情報抽出部21[W]は、受信したRTSパケットに登録されている送信タイミング情報を抽出する。送信タイミング決定部23[W]は、前記抽出された送信タイミング情報に基づいて送信端末による次回のRTSパケット▲2▼の送信タイミングを判別し、このRTSパケット▲2▼と衝突しない送信タイミングを、自端末(待機端末)からのRTSパケットの送信タイミングとして決定する。
【0034】
CTSパケット送信部30[D]は、自端末を宛先とするRTSパケットを受信すると、これに応答して、その送信元である送信端末に向けてCTSパケットを送信する。CTSパケット受信部40[S]は、前記宛先端末から送信されたCTSパケットを受信する。
【0035】
図2は、本実施形態の動作を示したタイミングチャートであり、ここでは、無線端末間で送受信されるパケットのみに着目し、Back−off Window、DIFS、SIFS等の各期間は図示を省略している。
【0036】
送信端末は、送信しようとする今回のRTSパケット▲1▼に、前記送信タイミング情報登録部11において次回のRTSパケット▲2▼の送信タイミング情報を登録し、これをRTSパケット送信部10から送信する。
【0037】
宛先端末は、前記RTSパケット受信部20において自端末を宛先とする今回のRTSパケット▲1▼を受信すると、これに応答して前記CTSパケット送信部30から、送信端末を宛先としてCTSパケットを送信する。
【0038】
待機端末は、前記RTSパケット受信部20において、自端末以外を宛先とする今回のRTSパケット▲1▼を受信すると、このRTSパケット▲1▼に登録されている次回のRTSパケット▲2▼の送信タイミング情報を前記送信タイミング情報抽出部21で抽出する。送信タイミング決定部23は、次回のRTSパケット▲2▼の送信タイミングを自端末(待機端末)からのRTSパケットの送信禁止期間と認識し、それ以外の期間からRTSパケットの送信タイミングを決定する。
【0039】
さらに具体的に言えば、全ての待機端末は、前記次回のRTSパケット▲2▼の送信開始時刻を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内から乱数により決定してもよい。
【0040】
本実施形態によれば、待機端末のRTSパケットは、送信端末のRTSパケットの送信タイミングを避けて送信されるので、送信端末からのRTSパケットの送信が待機端末のRTSパケットにより妨げられることがない。
【0041】
なお、送信端末の送信を優先させたいのであれば、図3に示したように、待機端末は、自端末からのパケット送信に必要な時間(RTSパケットの送信からACKパケットの受信までの時間)をDFとしたとき、自端末のRTS送信タイミングを、TRTS(j)−DFより前の時刻か、TRTS(j)+ DRTS(j)より後の時刻に決定する。このようにすれば、送信端末/宛先端末間でのパケット交換が待機端末によって妨げられることがないので、特に、送信端末の呼がリアルタイム通信のようにジッタの発生を最小限に抑えたい場合に有効である。
【0042】
図4は、本発明に係る無線端末の第2実施形態の機能ブロック図であり、前記と同一の符号は同一または同等部分を表している。
【0043】
送信タイミング情報転記部31[D]は、当該無線端末が宛先端末として機能する際に、送信端末から受信したRTSパケットに応答して返信するCTSパケットに、当該RTSパケットから抽出した送信タイミング情報を転記する。CTSパケット送信部30[D]は、前記送信タイミング情報の転記されたCTSパケットを前記と同様に送信する。
【0044】
CTSパケット受信部40[W]は、当該無線端末が主に待機端末として機能する際に、宛先端末から送信されたCTSパケットを受信する。送信タイミング情報抽出部41[W]は、受信したCTSパケットに登録されている送信タイミング情報を抽出する。送信タイミング決定部43[W]は、前記抽出された送信タイミング情報に基づいて次回のRTSパケット▲2▼の送信タイミングを判別し、このRTSパケット▲2▼と衝突しない送信タイミングを、自端末(待機端末)によるRTSパケットの送信タイミングとして決定する。
【0045】
前記RTSパケット送信部10[W]は、前記送信タイミング決定部23[W]で決定された送信タイミング、または前記送信タイミング決定部43[W]で決定された送信タイミングでRTSパケットを送信する。
【0046】
図5は、本実施形態における送信端末、宛先端末および2つの待機端末A,Bの動作を示したタイミングチャートであり、ここでは、図6に示したように、待機端末Bと送信端末および待機端末Aとの通信が遮蔽物50により遮られている場合を例にして説明する。
【0047】
宛先端末は、今回のRTSパケット▲1▼をRTSパケット受信部20で受信すると、このRTSパケット▲1▼に登録されている次回のRTSパケット▲2▼の送信タイミング情報を送信タイミング情報抽出部21で抽出する。送信タイミング情報転記部31は、前記抽出された送信タイミング情報をCTSパケット▲1▼に転記し、CTSパケット送信部30から送信する。
【0048】
一方の待機端末Aは、前記今回のRTSパケット▲1▼を送信端末から受信できるので、このRTSパケット▲1▼に登録されている次回のRTSパケット▲2▼の送信タイミング情報を抽出し、この期間をRTS送信禁止期間と認識し、それ以外の期間をRTS送信タイミングとして決定する。
【0049】
他方の待機端末Bは、送信端末からは今回のRTSパケット▲1▼を受信できないものの、宛先端末から送信されたCTSパケット▲1▼を受信し、送信タイミング情報抽出部41において、前記CTSパケット▲1▼から送信タイミング情報を抽出する。送信タイミング決定部43は、送信タイミング情報に基づいてRTS送信禁止期間と認識し、それ以外の期間をRTS送信タイミングとして決定する。
【0050】
本実施形態によれば、RTSパケットに登録されている送信タイミング情報が宛先端末においてCTSパケットに転記されて送信されるので、いわゆる隠れ端末問題も解消される。
【0051】
図7は、本発明に係る無線端末の第3実施形態の機能ブロック図であり、前記と同一の符号は同一または同等部分を表している。
【0052】
呼種別情報登録部12[S]は、当該無線端末が送信端末として機能する際、送信しようとするRTCパケットに、当該呼の優先度を代表する呼種別情報ACを登録する。RTSパケット送信部10[S]は、前記送信タイミング情報および呼種別情報ACの登録されたRTSパケットを送信する。
【0053】
本実施形態では、VoIP呼のように周期的にパケットを送出することを特徴とするリアルタイム呼のACを「01」、周期的にパケットを送出するわけではないがテレビ会議やライブビデオのように即時性が要求されるリアルタイム呼のACを「02」、即時性は要求されないものの比較的高いスループットや応答性が要求されるWebページのダウンロードなどのノンリアルタイム呼のACを「11」、さらには遅延やスループットの要求条件が比較的緩やかな電子メールのようなノンリアルタイム呼のACを「12」とし、呼種別情報ACの優先度を、「01」>「02」>「11」>「12」と定義する。
【0054】
呼種別情報抽出部22[D][W]は、当該無線端末が宛先端末または待機端末として機能する際に、送信端末から上記と同様にして送信されたRTSパケットに登録されている呼種別情報ACを抽出する。送信タイミング決定部23[W]は、前記抽出された送信タイミング情報に基づいて前記他の無線端末から送信される次回のRTSパケットの送信タイミングを識別すると共に、前記抽出した呼種別情報ACに基づいて、当該呼の優先度を自端末が確立しようとしている呼の優先度と比較する。そして、優先度の比較結果と次回のRTSパケットの送信タイミングとに基づいて、自端末によるRTSパケットの送信タイミングを決定する。
【0055】
呼種別情報転記部32[D]は、当該無線端末が宛先端末として機能する際、受信したRTSパケットに応答して返信するCTSパケットに、当該RTSパケットから抽出した呼種別情報ACを転記する。CTSパケット送信部30[D]は、前記送信タイミング情報および呼種別情報ACの転記されたCTSパケットを送信する。
【0056】
呼種別情報抽出部42[W]は、当該無線端末が待機端末として機能する際に、宛先端末から送信されたCTSパケットに登録されている呼種別情報ACを抽出する。送信タイミング決定部43[W]は、前記抽出された送信タイミング情報に基づいて前記送信端末から送信される次回のRTSパケット▲2▼の送信タイミングを識別すると共に、前記抽出した呼種別情報ACに基づいて当該呼の優先度を自端末が確立しようとしている呼の優先度と比較する。そして、優先度の比較結果と次回のRTSパケット▲2▼の送信タイミングとに基づいて、自端末によるRTSパケットの送信タイミングとして決定する。
【0057】
図8、9は、本実施形態における送信端末、宛先端末および待機端末の動作を示したタイミングチャートであり、図8は、送信端末の呼種別情報(AC)で代表される優先度が待機端末の優先度以下である場合の動作を示し、図9は、送信端末の優先度が待機端末の優先度よりも上位である場合の動作を示している。
【0058】
送信端末優先度≦待機端末優先度であれば、図8に示したように、待機端末のRTSパケットの送信タイミングは、送信端末の次回のRTSパケット▲2▼の送信タイミングと重ならないように、その前後に設定される。すなわち、早い時刻にRTSを送信した端末が優先される「Straight−forward」の処理となる。
【0059】
これに対して、送信端末優先度>待機端末優先度であれば、図9に示したように、待機端末のRTSパケット〜ACKパケットの送信期間が送信端末のRTSパケット▲2▼の送信タイミングと重ならないように、その前後に設定される。
【0060】
本実施形態によれば、待機端末のRTSパケット送信タイミングが、送信端末および待機端末の優先度を考慮して決定されるので、優先度の低い呼が優先されたり、優先度の高い呼の品質が低下したりするなどの問題が解消される。
【0061】
なお、上記した各実施形態では、今回のRTSパケット▲1▼に、次回のRTSパケット▲2▼の送信タイミング情報のみを登録し、あるいは送信タイミング情報と共に呼種別情報ACを登録するものとして説明したが、本発明はこれのみに限定されるものではなく、送信タイミング情報を登録することなく呼種別情報ACのみを登録するようにしても良い。
【0062】
この場合には、呼種別情報AC毎に次回のRTSパケット送信タイミングをあらかじめ定義しておくか、あるいは、IEEE 802.11 DCFやEDCFのように、各呼種別情報ACで定められたContention Windowから選択されるであろう各Back−off Windowの確率を算出し(一様乱数を使用すると、同じ確率値となる)、衝突する確率がもっとも低いと思われる時刻を各端末がRTS送信タイミングとして決定すれば良い。
【0063】
【発明の効果】
本発明によれば、RTSパケットの衝突を回避しやすくなるため、結果的にContention Windowの狭小化が図れ、無線資源の有効利用やデータパケット送出遅延の削減、スループットの向上が実現できる。また、周期的にデータパケットが発生する呼のパケット送信タイミングを阻害しないため、ジッタに対して敏感な呼のQoSを満足することが可能となる。
【図面の簡単な説明】
【図1】本発明に係る無線端末の第1実施形態の機能ブロック図である。
【図2】第1実施形態のタイミングチャート(その1)である。
【図3】第1実施形態のタイミングチャート(その2)である
【図4】本発明に係る無線端末の第2実施形態の機能ブロック図である。
【図5】第2実施形態のタイミングチャートである
【図6】第2実施形態による隠れ端末問題の解消方法を示した図である。
【図7】本発明に係る無線端末の第3実施形態の機能ブロック図である。
【図8】第3実施形態のタイミングチャート(その1)である。
【図9】第3実施形態のタイミングチャート(その2)である
【図10】従来のMACAの通信手順を示した図である。
【図11】従来のIEEE 802.11 DCFプロトコルのシーケンス図である。
【符号の説明】10…RTSパケット送信部,11…送信タイミング情報登録部,12…呼種別情報登録部,20…RTSパケット受信部,21…送信タイミング情報抽出部,22…呼種別情報抽出部,23…送信タイミング決定部,30…CTSパケット送信部,31…送信タイミング情報転記部,32…呼種別情報転記部,40…CTSパケット受信部,41…送信タイミング情報抽出部,42…呼種別情報抽出部,43…送信タイミング決定部

Claims (15)

  1. データパケットを送信しようとする無線端末の一つが送信端末として予めRTS(Request−To−Send)パケットを宛先端末へ送信し、データパケットを送信しようする他の無線端末は、前記RTSパケットを受信すると待機端末としてRTSパケットの送信を延期し、前記送信端末は、宛先端末から返信されるCTS(Clear−To−Send)パケットに応答してデータパケットを送信する無線アクセス制御方法において、
    前記送信端末は、今回のRTSパケットに、次回のRTSパケットの送信タイミングを規定する送信タイミング情報を登録して送信し、
    前記待機端末は、前記今回のRTSパケットを受信すると、当該RTSパケットに登録されている前記送信タイミング情報を抽出し、前記次回のRTSパケットの送信タイミングに基づいて自身のパケットの送信タイミングを決定することを特徴とする無線アクセス制御方法。
  2. 前記待機端末は、自端末のRTSパケットを、前記送信端末の次回のRTSパケットと重ならないように送信することを特徴とする請求項1に記載の無線アクセス制御方法。
  3. 前記待機端末は、自端末のRTSパケットを、当該RTSパケットを含む一連のCTSパケット、データパケットおよびACKパケットが前記送信端末の次回のRTSパケットと重ならないように送信することを特徴とする請求項1に記載の無線アクセス制御方法。
  4. 前記宛先端末が、受信したRTSパケットに登録されている前記送信タイミング情報を抽出し、これをCTSパケットに転記して返信することを特徴とする請求項1ないし3のいずれかに記載の無線アクセス制御方法。
  5. 前記送信端末は、今回のRTSパケットに、当該呼の優先度を代表する呼種別情報ACを登録して送信し、
    前記待機端末は、受信した今回のRTSパケットから前記送信タイミング情報および呼種別情報ACを抽出し、前記呼種別情報ACに応じて、少なくとも自端末のRTSパケットが前記次回のRTSパケットと重ならないように各パケットの送信タイミングを制御することを特徴とする請求項1ないし4のいずれかに記載の無線アクセス制御方法。
  6. 前記待機端末は、受信したRTSパケットに登録されている呼種別情報ACと自身が確立しようとする呼の呼種別情報AC’とを比較し、自身の優先度が送信端末の優先度よりも高ければ、自身のRTSパケットを、前記送信端末の次回のRTSパケットと重ならないように送信することを特徴とする請求項5に記載の無線アクセス制御方法。
  7. 前記待機端末は、受信したRTSパケットに登録されている呼種別情報ACと自身が確立しようとする呼の呼種別情報AC’とを比較し、自身の優先度が送信端末の優先度よりも低ければ、自身のRTSパケットを、当該RTSパケットを含む一連のCTSパケット、データパケットおよびACKパケットが前記送信端末の次回のRTSパケットと重ならないように送信することを特徴とする請求項5に記載の無線アクセス制御方法。
  8. 前記宛先端末が、前記今回のRTSパケットを受信すると、当該RTSパケットに登録されている前記次回のRTSパケットの送信タイミングおよび呼種別情報ACを抽出し、これをCTSパケットに登録して返信することを特徴とする請求項5ないし7のいずれかに記載の無線アクセス制御方法。
  9. データパケットを送信する際に予めRTS(Request−To−Send)パケットを送信し、宛先端末から返信されるCTS(Clear−To−Send)パケットに応答してデータパケットを送信する一方、他の無線端末から送信されたRTSパケットを受信するとRTSパケット送信を延期する無線端末において、
    今回のRTSパケットに、次回のRTSパケットの送信タイミングを規定する送信タイミング情報を登録する送信タイミング情報登録手段と、
    前記RTSパケットを送信するRTSパケット送信手段と、
    他の無線端末から送信されたRTSパケットを受信する手段と、
    前記受信したRTSパケットから前記次回のRTSパケットの送信タイミング情報を抽出する送信タイミング情報抽出手段と、
    前記抽出された送信タイミングに基づいて自身のパケットの送信タイミングを決定する送信タイミング決定手段とを含むことを特徴とする無線端末。
  10. 前記送信タイミング決定手段は、自端末のRTSパケットを、他の無線端末による次回のRTSパケットと重ならないように送信することを特徴とする請求項9に記載の無線端末。
  11. 前記送信タイミング決定手段は、自身のRTSパケットを、当該RTSパケットを含む一連のCTSパケット、データパケットおよびACKパケットが他の無線端末による次回のRTSパケットと重ならないように送信することを特徴とする請求項9に記載の無線端末。
  12. 自端末宛のRTSパケットを受信すると、これに応答して返信するCTSパケットに、当該RTSパケットに登録されている前記送信タイミング情報を転記する送信タイミング情報転記手段を含むことを特徴とする請求項9ないし11のいずれかに記載の無線端末。
  13. 送信するRTSパケットに当該呼の優先度を代表する呼種別情報ACを登録する呼種別情報登録手段と、
    受信したRTSパケットに登録されている呼種別情報ACを抽出する呼種別情報抽出手段とを含み、
    前記送信タイミング決定手段は、受信したRTSパケットに登録されている呼種別情報ACと自端末が確立しようとする呼の呼種別情報AC’とに基づいて両者の優先度を比較し、自端末の優先度が相手端末の優先度よりも高ければ、自端末のRTSパケットを、前記次回のRTSパケットと重ならないように送信させることを特徴とする請求項9ないし12のいずれかに記載の無線端末。
  14. 送信するRTSパケットに当該呼の優先度を代表する呼種別情報ACを登録する呼種別情報登録手段と、
    受信したRTSパケットに登録されている呼種別情報ACを抽出する呼種別情報抽出手段とを含み、
    前記送信タイミング決定手段は、受信したRTSパケットに登録されている呼種別情報ACと自端末が確立しようとする呼の呼種別情報AC’とに基づいて両者の優先度を比較し、自端末の優先度が相手端末の優先度よりも低ければ、自端末のRTSパケットを含む一連のCTSパケット、データパケットおよびACKパケットを、前記次回のRTSパケットと重ならないように送信させることを特徴とする請求項9ないし12のいずれかに記載の無線端末。
  15. 前記RTSパケットを受信すると、当該RTSパケットに登録されている呼種別情報ACをCTSパケットに転記する呼種別情報転記手段を含むことを特徴とする請求項13または14に記載の無線端末。
JP2002346010A 2002-11-28 2002-11-28 無線端末およびその無線アクセス制御方法 Expired - Fee Related JP4042901B2 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2002346010A JP4042901B2 (ja) 2002-11-28 2002-11-28 無線端末およびその無線アクセス制御方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2002346010A JP4042901B2 (ja) 2002-11-28 2002-11-28 無線端末およびその無線アクセス制御方法

Publications (2)

Publication Number Publication Date
JP2004180131A true JP2004180131A (ja) 2004-06-24
JP4042901B2 JP4042901B2 (ja) 2008-02-06

Family

ID=32707043

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2002346010A Expired - Fee Related JP4042901B2 (ja) 2002-11-28 2002-11-28 無線端末およびその無線アクセス制御方法

Country Status (1)

Country Link
JP (1) JP4042901B2 (ja)

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2007019715A (ja) * 2005-07-06 2007-01-25 Oki Electric Ind Co Ltd 無線lanシステムおよびその通信方法
JP2007129570A (ja) * 2005-11-04 2007-05-24 Oki Electric Ind Co Ltd パケット衝突回避方法、通信端末及び通信システム
JP2009177634A (ja) * 2008-01-25 2009-08-06 Toyota Central R&D Labs Inc 通信装置
US8144677B2 (en) 2007-08-08 2012-03-27 Ntt Docomo, Inc. Wireless communication device and wireless communication method
US9538414B2 (en) 2011-12-19 2017-01-03 Fujitsu Limited Transmission control method and node
WO2018047432A1 (ja) * 2016-09-12 2018-03-15 シャープ株式会社 通信端末、制御方法、および制御プログラム

Cited By (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2007019715A (ja) * 2005-07-06 2007-01-25 Oki Electric Ind Co Ltd 無線lanシステムおよびその通信方法
JP4563882B2 (ja) * 2005-07-06 2010-10-13 Okiセミコンダクタ株式会社 無線lanシステムおよびその通信方法
KR101176028B1 (ko) * 2005-07-06 2012-08-24 오끼 덴끼 고오교 가부시끼가이샤 무선 랜 시스템 및 그 통신 방법
JP2007129570A (ja) * 2005-11-04 2007-05-24 Oki Electric Ind Co Ltd パケット衝突回避方法、通信端末及び通信システム
US8144677B2 (en) 2007-08-08 2012-03-27 Ntt Docomo, Inc. Wireless communication device and wireless communication method
JP2009177634A (ja) * 2008-01-25 2009-08-06 Toyota Central R&D Labs Inc 通信装置
JP4518155B2 (ja) * 2008-01-25 2010-08-04 株式会社豊田中央研究所 通信装置
US9538414B2 (en) 2011-12-19 2017-01-03 Fujitsu Limited Transmission control method and node
WO2018047432A1 (ja) * 2016-09-12 2018-03-15 シャープ株式会社 通信端末、制御方法、および制御プログラム

Also Published As

Publication number Publication date
JP4042901B2 (ja) 2008-02-06

Similar Documents

Publication Publication Date Title
JP3389511B2 (ja) キャリア検知を向上させた無線ローカルエリア・ネットワーク
EP1430619B1 (en) A system and method employing algorithms and protocols for optimizing carrier sense multiple access (CSMA) protocols in wireless networks
US8031744B2 (en) Full-duplex wireless communications
US8446907B2 (en) Medium access control method and apparatus in wireless distributed network
EP1606829B1 (en) Mechanism for reserving multiple channels of a single medium access control and physical layer
JP4473069B2 (ja) フレーム・バーストの管理
US5721725A (en) Protocol for channel access in wireless or network data communication
US7535919B2 (en) Wireless communication method adapting priority for transmitting packets in WPAN
Sivaram et al. Improved enhanced DBTMA with contention-aware admission control to improve the network performance in MANETS
US20080205370A1 (en) Method for Controlling Use Amount of Radio Channel in Ad Hoc Network and Communication Apparatus Using the Same
MX2007009325A (es) Metodo y aparato para controlar congestion de medio inalambrico ajustando el tamano de la ventana de contencion y disociando las estaciones moviles seleccionadas.
JP3484390B2 (ja) 無線パケット優先制御方法
AU2021323746B2 (en) Channel contention method and related apparatus
CN102256317B (zh) 无线信道访问控制方法
JP2010539776A (ja) 媒体へのアクセスの管理
JP2007518352A (ja) 送信衝突回避のための装置および方法
EP3079432B1 (en) Channel reservation method and communications device
JP4042901B2 (ja) 無線端末およびその無線アクセス制御方法
EP2198658B1 (en) A method of reducing occurrence of masked nodes, a node and a computer program product therefor
CN112512082A (zh) 无线网络的传输方法、装置、通信节点及存储介质
EP2070262B1 (en) Wireless network
Ye et al. A jamming‐based MAC protocol to improve the performance of wireless multihop ad‐hoc networks
Wang et al. An improved busy-tone solution for collision avoidance in wireless ad hoc networks
Roy et al. An efficient cooperative MAC protocol for enhancing QoS of IEEE 802.11 e EDCA in saturated conditions
JP2006245908A (ja) 無線lanシステムおよび通信装置

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20051111

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20071026

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20071107

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20071108

R150 Certificate of patent or registration of utility model

Free format text: JAPANESE INTERMEDIATE CODE: R150

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20101122

Year of fee payment: 3

LAPS Cancellation because of no payment of annual fees