JP7334847B2 - 無線ローカルエリアネットワーク（ｗｌａｎ）局におけるｒｔａキュー管理 - Google Patents

無線ローカルエリアネットワーク（ｗｌａｎ）局におけるｒｔａキュー管理 Download PDF

Info

Publication number
JP7334847B2
JP7334847B2 JP2022506516A JP2022506516A JP7334847B2 JP 7334847 B2 JP7334847 B2 JP 7334847B2 JP 2022506516 A JP2022506516 A JP 2022506516A JP 2022506516 A JP2022506516 A JP 2022506516A JP 7334847 B2 JP7334847 B2 JP 7334847B2
Authority
JP
Japan
Prior art keywords
rta
queue
packets
packet
session
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.)
Active
Application number
JP2022506516A
Other languages
English (en)
Other versions
JP2022542460A (ja
Inventor
リャンシャオ シン
モハメド アブエルサウード
和之 迫田
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.)
Sony Corp
Sony Group Corp
Original Assignee
Sony Corp
Sony Group 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 Sony Corp, Sony Group Corp filed Critical Sony Corp
Publication of JP2022542460A publication Critical patent/JP2022542460A/ja
Application granted granted Critical
Publication of JP7334847B2 publication Critical patent/JP7334847B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W74/00—Wireless channel access
    • H04W74/08—Non-scheduled access, e.g. ALOHA
    • H04W74/0808—Non-scheduled access, e.g. ALOHA using carrier sensing, e.g. carrier sense multiple access [CSMA]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W74/00—Wireless channel access
    • H04W74/08—Non-scheduled access, e.g. ALOHA
    • H04W74/0808—Non-scheduled access, e.g. ALOHA using carrier sensing, e.g. carrier sense multiple access [CSMA]
    • H04W74/0816—Non-scheduled access, e.g. ALOHA using carrier sensing, e.g. carrier sense multiple access [CSMA] with collision avoidance
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/24—Traffic characterised by specific attributes, e.g. priority or QoS
    • H04L47/2425—Traffic characterised by specific attributes, e.g. priority or QoS for supporting services specification, e.g. SLA
    • H04L47/2433—Allocation of priorities to traffic types
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/24—Traffic characterised by specific attributes, e.g. priority or QoS
    • H04L47/2416—Real-time traffic
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/74—Address processing for routing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/24—Traffic characterised by specific attributes, e.g. priority or QoS
    • H04L47/2441—Traffic characterised by specific attributes, e.g. priority or QoS relying on flow classification, e.g. using integrated services [IntServ]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/24—Traffic characterised by specific attributes, e.g. priority or QoS
    • H04L47/2475—Traffic characterised by specific attributes, e.g. priority or QoS for supporting traffic characterised by the type of applications
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/50—Queue scheduling
    • H04L47/56—Queue scheduling implementing delay-aware scheduling
    • H04L47/564—Attaching a deadline to packets, e.g. earliest due date first
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/70—Admission control; Resource allocation
    • H04L47/80—Actions related to the user profile or the type of traffic
    • H04L47/801—Real time traffic
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L49/00—Packet switching elements
    • H04L49/20—Support for services
    • H04L49/205—Quality of Service based
    • H04L49/206—Real Time traffic
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L49/00—Packet switching elements
    • H04L49/90—Buffering arrangements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W74/00—Wireless channel access
    • H04W74/08—Non-scheduled access, e.g. ALOHA
    • H04W74/0833—Random access procedures, e.g. with 4-step access
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W8/00—Network data management
    • H04W8/02—Processing of mobility data, e.g. registration information at HLR [Home Location Register] or VLR [Visitor Location Register]; Transfer of mobility data, e.g. between HLR, VLR or external networks
    • H04W8/04—Registration at HLR or HSS [Home Subscriber Server]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/50—Queue scheduling
    • H04L47/56—Queue scheduling implementing delay-aware scheduling
    • H04L47/564—Attaching a deadline to packets, e.g. earliest due date first
    • H04L47/566—Deadline varies as a function of time spent in the queue
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/50—Queue scheduling
    • H04L47/62—Queue scheduling characterised by scheduling criteria
    • H04L47/6215—Individual queue per QOS, rate or priority
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L49/00—Packet switching elements
    • H04L49/90—Buffering arrangements
    • H04L49/9023—Buffering arrangements for implementing a jitter-buffer
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/02—Traffic management, e.g. flow control or congestion control
    • H04W28/0231—Traffic management, e.g. flow control or congestion control based on communication conditions
    • H04W28/0236—Traffic management, e.g. flow control or congestion control based on communication conditions radio quality, e.g. interference, losses or delay
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W84/00—Network topologies
    • H04W84/02—Hierarchically pre-organised networks, e.g. paging networks, cellular networks, WLAN [Wireless Local Area Network] or WLL [Wireless Local Loop]
    • H04W84/10—Small scale networks; Flat hierarchical networks
    • H04W84/12—WLAN [Wireless Local Area Networks]

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Quality & Reliability (AREA)
  • Databases & Information Systems (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Description

〔関連出願の相互参照〕
[0001] 本出願は、２０１９年９月９日に出願された米国仮特許出願第６２／８９７，６００号に対する優先権及びその利益を主張するものであり、この仮特許出願はその全体が引用により本明細書に組み入れられる。
〔連邦政府が支援する研究又は開発に関する記述〕
[0002] 適用なし
〔コンピュータプログラムによる添付物の引用による組み入れ〕
[0003] 適用なし
〔著作権保護を受ける資料の通知〕
[0004] 本特許文書中の資料の一部は、米国及びその他の国の著作権法の下で著作権保護を受けることができる。著作権の権利所有者は、米国特許商標庁の一般公開ファイル又は記録内に表されるとおりに第三者が特許文献又は特許開示を複製することには異議を唱えないが、それ以外は全ての著作権を留保する。著作権所有者は、限定するわけではないが、米国特許法施行規則§１．１４に従う権利を含め、本特許文献を秘密裏に保持しておくあらゆる権利を本明細書によって放棄するものではない。
[0006] 本開示の技術は、一般に、無線通信局に関し、具体的には、キュー管理システムを利用してリアルタイムトラフィックを通信する無線ローカルエリアネットワーク（ＷＬＡＮ）局に関する。
[0008] キャリア検知多重アクセス／衝突回避（ＣＳＭＡ／ＣＡ）を利用する現在の無線システムは、ネットワーク全体の高いスループットに焦点を当てているが、リアルタイムアプリケーション（ＲＴＡ）を適切にサポートするための低レイテンシ能力を欠く。
[0009] ＲＴＡは、低レイテンシ通信を必要とし、ベストエフォート通信を使用する。ＲＴＡから生成されるデータは、ＲＴＡトラフィックと呼ばれ、送信機局（ＳＴＡ）でＲＴＡパケットとしてパケット化され、一方、非時間依存アプリケーションから生成されるデータは、非ＲＴＡトラフィックと呼ばれ、送信機局（ＳＴＡ）で非ＲＴＡパケットとしてパケット化される。ＲＴＡパケットは、特定の期間内に配信できる場合のみに有効であるので、パケット配信のための高い適時性要件（リアルタイム）に起因して低レイテンシを必要とする。
[0010] ＣＳＭＡ／ＣＡ無線技術では、ＳＴＡは、拡張分散チャネルアクセス（Ｅｎｈａｎｃｅｄ Ｄｉｓｔｒｉｂｕｔｅｄ Ｃｈａｎｎｅｌ Ａｃｃｅｓｓ：ＥＤＣＡ）を利用して、優先度の高いトラフィックに、優先度の低いトラフィックよりも早く送信される機会を与えることができる。ＥＤＣＡは、ＩＥＥＥ ８０２．１１ｅ標準において定められて、Ｗｉ－Ｆｉサービス品質（ＱｏＳ）要件を満たす。ＥＤＣＡは、トラフィックを、優先度に関して異なるアクセスカテゴリ（ＡＣ）に分類する。優先度が高いＡＣほど平均チャネル競合時間が短いので、より頻繁にチャネルにアクセスすることができる。
[0011] 各アクセスカテゴリ（ＡＣ）は、それ自身のキューを有し、送信のためにキュー内のパケットを順序付ける。１つのＡＣ内において提供されたトラフィックが高い時に、そのキュー内のパケットは、１つずつチャネルアクセスを獲得するために待つ必要がある。キュー内のパケットの待ち時間は著しいので、そのパケット送信のレイテンシを増加させる。
[0012] ＥＤＣＡにおけるランダムチャネルアクセスのシナリオに起因して、優先度の高いトラフィックは、常に優先度の低いトラフィックよりも早くチャネルアクセスを獲得するとは限らない。したがって、現在のキューシステムは、ＲＴＡパケットの配信に影響を与える著しい遅延を受ける。上記に鑑みて、ＥＤＣＡを含むＣＳＭＡ／ＣＡ又は同様の機構を利用する無線ネットワーク内の時間依存ＲＴＡパケットの通信に伴う著しいレイテンシがあることが分かる。
したがって、パケットレイテンシを著しく低減するためのリアルタイムアプリケーション（ＲＴＡ）パケットの強化された処理に対するニーズが存在する。本開示は、このニーズを満たすとともに、これまでの技術を凌駕する更なる利点をもたらす。
[0013] ＥＤＣＡを含むＣＳＭＡ／ＣＡを使用する無線ネットワークのキューシステムによって生じるＲＴＡパケット遅延をなくすために、新たなＲＴＡキュー機構を作成して、局がチャネルアクセスを獲得する前のキュー内のＲＴＡパケットの待ち時間を低減することが非常に有益である。
[0014] ＣＳＭＡ／ＣＡシステムにおいてＲＴＡキュー管理を実行するタスクは、ＲＴＡトラフィック及び非ＲＴＡトラフィックの両方の共存に起因してより困難である。このプロセスにおける課題は、以下のように要約することができる。（ａ）ＲＴＡパケットと非ＲＴＡパケットとを識別及び区別すること。（ｂ）ＲＴＡパケットをＲＴＡキューにプッシュするとともに、非ＲＴＡパケットを非ＲＴＡキュー（すなわちＥＤＣＡキュー）にプッシュすること。（ｃ）ＲＴＡキューと非ＲＴＡキューとの間でチャネルアクセスを調整すること。（ｄ）適時性要件を満たさなくなった、キューに入れられたＲＴＡパケットに対処する（このようなパケットを処理する）こと。
[0015] 開示するＲＴＡキュー管理は、ＲＴＡトラフィックの時間有効性を考慮して、無線ネットワークにおいてＲＴＡトラフィック及び非ＲＴＡトラフィックが共存するキュー内のＲＴＡトラフィックの待ち時間を低減することによって、そのレイテンシを最小にする。
[0016] 具体的には、本開示の無線通信システム、装置及び／又は方法は、ＲＴＡパケットの強化された処理及びそのキューイングのための多数の機構を提供する。
[0017] 各局は、ＣＳＭＡ／ＣＡが適用される一方で、リアルタイムアプリケーション（ＲＴＡ）トラフィック及び非ＲＴＡトラフィックが共存するパケット送信を実行するように構成される。局は、少なくとも以下の動作を実行するように構成される。ＳＴＡは、ＲＴＡトラフィックと非ＲＴＡトラフィックとを区別する。ＳＴＡは、ＲＴＡパケットをキューに入れるためにＲＴＡキューを作成する一方で、非ＲＴＡパケットを、ＥＤＣＡキューなどの非ＲＴＡキューにプッシュする。ＳＴＡは、ＲＴＡセッションパラメータとＲＴＡキュー設定情報とを含む管理フレームを交換する。各ＳＴＡは、送信を実行するためのＲＴＡキューにチャネル時間を割り当てて、チャネル時間中に、非ＲＴＡキューがチャネルにアクセスすることを許可しない。ＳＴＡは、ＲＴＡセッションのＲＴＡキュー分類情報に基づいて、ＲＴＡパケットをどのＲＴＡキューに入れるべきかを決定する。各ＳＴＡは、ＲＴＡパケットの満了時間を設定し、満了したＲＴＡパケットが入れられた全てのＲＴＡキューから、満了したＲＴＡパケットを取り出す。
[0018] 更に、少なくとも１又は２以上の実施形態は、以下の発明の要素のうちの１又は２以上を含む。（ａ）ＳＴＡは、事前ネゴシエーション又はパケットヘッダ情報に基づく情報を使用して、ＲＴＡトラフィックと非ＲＴＡトラフィックとを区別することができる。（ｂ）ＲＴＡキューを作成するＳＴＡは、そのキューが他のキューに割り当てられるチャネル時間を使用してチャネルにアクセスできるようにすることができる。（ｃ）ＲＴＡキューを作成するＳＴＡは、各パケットの満了時間及び優先度に基づいて各パケットの重要度指標を計算することによって、キュー内のＲＴＡパケットをソートすることができる。（ｄ）ＲＴＡキューを作成するＳＴＡは、どのような順序でパケットがキューに含まれているかを考慮することなく、パケットに関するＲＴＡセッション情報に基づいて、キュー内のＲＴＡパケットを送信することができる。（ｅ）ＲＴＡキューを作成するＳＴＡは、そのキューに割り当てられるチャネルリソースを制限することができる。（ｆ）ＲＴＡセッションパラメータを含む管理フレームを交換するＳＴＡは、ＲＴＡキュー分類、ＲＴＡパケット満了時間、及びＲＴＡセッションの満了したＲＴＡパケットの動作を設定することができる。（ｇ）ＲＴＡキュー設定情報を含む管理フレームを交換するＳＴＡは、各キューのＲＴＡキューイング規則、ＲＴＡキューチャネル時間割り当て、及びＲＴＡキューチャネルリソース制限を設定することができる。（ｈ）ＲＴＡパケットをどのＲＴＡキューに入れるべきかを決定するＳＴＡは、事前ネゴシエーションによって交換されるＲＴＡセッションのキュー情報を使用することができる。（ｉ）ＲＴＡパケットをキューに入れるＳＴＡは、レイテンシ要件に基づいて、このパケットを複数のＲＴＡキューにプッシュすることができる。（ｊ）ＲＴＡパケットをキューに入れるＳＴＡは、１つのキューを通じてそのパケットの送信が成功した時に、全てのキューからそのＲＴＡパケットを取り出すことができる。（ｋ）ＲＴＡパケットの満了時間を設定するＳＴＡは、パケットを破棄すること又はパケットを非ＲＴＡキューに移動させることのいずれかを決定することができる。
[0019] 本明細書の以下の部分では、本明細書で説明する技術の更なる態様が明らかになり、この詳細な説明は、本技術の好ましい実施形態を制限することなく完全に開示するためのものである。
[0020] 本明細書で説明する技術は、例示のみを目的とする以下の図面を参照することによって十分に理解されるであろう。
ＣＳＭＡ／ＣＡにおける競合ベースのチャネルアクセスのフロー図である。 ＲＴＳ／ＣＴＳが無効であるＣＳＭＡ／ＣＡにおけるランダムチャネルアクセスの通信シーケンス図である。 ＥＤＣＡキューシステムのキュー図である。 本開示の少なくとも１つの実施形態による局（ＳＴＡ）ハードウェアのブロック図である。 本開示の少なくとも１つの実施形態に従って取り扱われるトポロジ例を示すネットワークトポロジ図である。 本開示の少なくとも１つの実施形態による開放型システム間相互接続（ＯＳＩ）モデルにおけるＲＴＡ及び非ＲＴＡトラフィック通信のための階層通信図である。 本開示の少なくとも１つの実施形態によるＲＴＡトラフィック通信のための事前ネゴシエーションを示す階層通信図である。 本開示の少なくとも１つの実施形態による、送信機側でＲＴＡパケットトラフィックを識別するフロー図である。 本開示の少なくとも１つの実施形態によるＲＴＡセッション識別情報のデータフィールド図である。 本開示の少なくとも１つの実施形態によるヘッダ情報交換の階層通信図である。 本開示の少なくとも１つの実施形態による、受信機側のＭＡＣ層でＲＴＡパケットを識別するフロー図である。 本開示の少なくとも１つの実施形態によるＲＴＡキューシステムのキュー図である。 本開示の少なくとも１つの実施形態によるＲＴＡセッション情報のデータ図である。 本開示の少なくとも１つの実施形態によるＲＴＡキューシステムの相互作用モデルを示す図である。 本開示の少なくとも１つの実施形態によるＲＴＡセッション開始プロセスを示す層間通信図である。 本開示の少なくとも１つの実施形態によるＲＴＡセッション開始要求フレームのデータフィールド図である。 本開示の少なくとも１つの実施形態によるＲＴＡセッション開始応答フレームのデータフィールド図である。 本開示の少なくとも１つの実施形態によるキュー分類のクロスレイヤ図である。 本開示の少なくとも１つの実施形態による、キューからＲＴＡパケットを破棄するフロー図である。 本開示の少なくとも１つの実施形態による、満了したＲＴＡパケット（セッション４）の非ＲＴＡキューへの移動を例示するキュー図である。 本開示の少なくとも１つの実施形態による、満了したＲＴＡパケット（セッション４）の破棄を例示するキュー図である。 本開示の少なくとも１つの実施形態による、優先度の高い非ＲＴＡキューから優先度の低い非ＲＴＡキューへの満了したＲＴＡパケットの移動を例示するキュー図である。 本開示の少なくとも１つの実施形態によるＲＴＡキューイング規則設定プロセスを示す層間通信図である。 本開示の少なくとも１つの実施形態によるＲＴＡキューソーティングフレームフォーマットのデータフィールド図である。 本開示の少なくとも１つの実施形態による、優先度によるＲＴＡパケットのソーティングを例示するパケットキュー図である。 本開示の少なくとも１つの実施形態による、満了時間によるＲＴＡパケットのソーティングを例示するパケットキュー図である。 本開示の少なくとも１つの実施形態による、重要度指標によるＲＴＡパケットのソーティングを例示するパケットキュー図である。 本開示の少なくとも１つの実施形態による、異なるキューへのチャネル時間の割り当てを示すチャネル割り当て図である。 本開示の少なくとも１つの実施形態によるキューチャネル時間割り当て手順を示す層間通信図である。 本開示の少なくとも１つの実施形態によるキューチャネル時間割り当てフレームフォーマットのデータフィールド図である。 本開示の少なくとも１つの実施形態によるキュー間の内部チャネルアクセス制御を示すフロー図である。 本開示の少なくとも１つの実施形態によるキュー間の内部チャネルアクセス制御を示すフロー図である。 本開示の少なくとも１つの実施形態によるＲＴＡキューパラメータ設定手順を示す層間通信図である。 本開示の少なくとも１つの実施形態によるＲＴＡキューパラメータ設定フレームフォーマットのデータフィールド図である。 本開示の少なくとも１つの実施形態による、ＲＴＡキューシステムを使用してパケットを送信するフロー図である。 本開示の少なくとも１つの実施形態によるＳＴＡ１におけるＲＴＡキューシステムを例示するキュー図である。 本開示の少なくとも１つの実施形態によるＳＴＡ２におけるＲＴＡキューシステムを例示するキュー図である。 本開示の少なくとも１つの実施形態によるＳＴＡ３におけるＲＴＡキューシステムを例示するキュー図である。 本開示の少なくとも１つの実施形態によるＳＴＡ４におけるＲＴＡキューシステムを例示するキュー図である。 本開示の少なくとも１つの実施形態による、ＣＢＡＰ中のＳＴＡ０（ＡＰ）における単一ユーザ送信を例示する通信シーケンス図である。 本開示の少なくとも１つの実施形態による、ＲＴＡセッション２に対してスケジュールされるチャネル時間中のＳＴＡ０（ＡＰ）における単一ユーザ送信を例示する通信シーケンス図である。 本開示の少なくとも１つの実施形態による、バックオフ時間が必要ない時にＲＴＡセッション２に対してスケジュールされるチャネル時間中のＳＴＡ０（ＡＰ）における単一ユーザ送信を例示する通信シーケンス図である。 本開示の少なくとも１つの実施形態による、ＴＡキューに対してスケジュールされるチャネル時間中のＳＴＡ０（ＡＰ）における単一ユーザ送信を例示する通信シーケンス図である。 本開示の少なくとも１つの実施形態による、受信機ノードによってパケットを分離するためのＳＴＡ０におけるＲＴＡキューサブシステムを例示するキュー図である。 本開示の少なくとも１つの実施形態による、受信機ノードによってパケットを分離するためのＳＴＡ０におけるＲＴＡキューサブシステムを例示するキュー図である。 本開示の少なくとも１つの実施形態によるマルチユーザダウンリンク送信を例示する通信シーケンス図である。 本開示の少なくとも１つの実施形態による、マルチユーザモードでのＲＴＡデータ送信のためのＲＴＡ通知トリガフレーム（ＲＴＡ－ＴＦ）のデータフィールド図である。 本開示の少なくとも１つの実施形態によるＲＴＡ制御フィールドフォーマットのデータフィールド図である。 本開示の少なくとも１つの実施形態によるＲＴＡ再送信スケジュールフィールドフォーマットのデータフィールド図である。 本開示の少なくとも１つの実施形態による、ＲＴＡトリガフレーム（ＴＦ）によって開始されるマルチユーザアップリンク送信を例示する通信シーケンス図である。 本開示の少なくとも１つの実施形態による、通常のトリガフレーム（ＴＦ）によって開始されるマルチユーザアップリンク送信を例示する通信シーケンス図である。
１．従来のＷＬＡＮシステム
１．１．ランダムチャネルアクセススキーム
[0072] 従来、ＩＥＥＥ ８０２．１１などの無線ローカルエリアネットワーク（ＷＬＡＮ）は、キャリア検知多重アクセス／衝突回避（ＣＳＭＡ／ＣＡ）機構を使用して、局（ＳＴＡ）がパケット送信及び再送信のためのチャネルにランダムアクセスできるようにしてきた。
[0073] 図１に、ＣＳＭＡ／ＣＡにおける競合ベースのチャネルアクセスを示す。ＣＳＭＡ／ＣＡシステムでは、ＳＴＡは、送信するデータがある時に、送信のためのチャネルを検知する。各送信及び再送信の前に、ＳＴＡは、チャネルを検知して、バックオフ時間を設定してチャネルアクセスを求めて競合する必要がある。バックオフ時間は、ゼロとコンテンションウィンドウ（ＣＷ）のサイズとの間の均一な確率変数によって決定される。
[0074] ＳＴＡがバックオフ時間にわたって待ち、チャネルがアイドル状態である（占有されていない）ことを検知した後、ＳＴＡは、送信要求（ＲＴＳ）フレームを送信してチャネル占有を確保するか否かを決定する。ＳＴＡがＲＴＳフレームを送信した場合、ＳＴＡが送信可（ＣＴＳ）フレームを受け取った時にチャネル占有が確保され、それによって、その時に、ＳＴＡはパケットを送信する。ＳＴＡがＲＴＳフレームを送信しない場合、ＳＴＡはパケットを直接送信する。ＲＴＳフレームを送信した後にＣＴＳフレームが受け取られない場合、又はタイムアウトの前にＳＴＡが確認応答（ＡＣＫ）を受け取らない場合、再送信が必要である。そうでない場合には、送信は成功する。再送信が必要な時に、ＳＴＡは、パケットの再送信の数をチェックする。再送信の数が再試行の限界を超える場合、パケットは破棄されて、再送信はスケジュールされない。そうでない場合には、再送信をスケジュールする。再送信がスケジュールされた場合、再送信のためのチャネルアクセスを求めて競合するために、別のバックオフ時間が必要である。コンテンションウィンドウのサイズが上限に達していない場合、ＳＴＡはサイズを大きくする。ＳＴＡは、コンテンションウィンドウの新たなサイズに応じて、別のバックオフ時間を設定する。ＳＴＡは、再送信などのためにバックオフ時間を待つ。
[0075] 図２に、ＲＴＳ／ＣＴＳが無効であるＣＳＭＡ／ＣＡにおけるランダムチャネルアクセスの一例を示す。なお、ＣＳＭＡ／ＣＡに関する８０２．１１標準は、ＯＳＩネットワーキングスタックにおける２つの最も低いレベル、すなわち、物理（ＰＨＹ）層及び媒体アクセス制御（ＭＡＣ）層を利用する。送信機ＳＴＡのＭＡＣ層がその上位層からデータを受け取った時に、送信機ＳＴＡは、アクセスを獲得するためにチャネルを求めて競合する。送信機ＳＴＡがチャネルを求めて競合する時に、送信機ＳＴＡはバックオフ時間まで待つ必要があり、それによって、コンテンションウィンドウのサイズはｎ個のスロットであり、ゼロまでカウントダウンする。チャネルを通じて他のパケット送信が行われている時に、例えばビジーを示すクリアチャネル評価（ＣＣＡ）によって、カウントダウンプロセスを中断することができる。送信機ＳＴＡは、データを送信するためのチャネルアクセスを獲得した後に、データをパケットにパケット化して、チャネルを通じてパケットを送信する。図に示すように、パケットの初期送信が成功しなかった場合、パケットの再送信が実行される。送信機ＳＴＡは、再びバックオフ時間を設定して、チャネルアクセスを求めて競合する。この時、再送信に起因して、コンテンションウィンドウのサイズを２倍、すなわち、２＊ｎ個のスロットにする。予想バックオフ時間も、コンテンションウィンドウサイズによって２倍にする。バックオフ時間を増加させた時に、他のパケット送信（すなわちＣＣＡビジー）によってカウントダウンプロセスを中断する機会も大きくなる。
１．２．ＥＤＣＡキューシステム
[0077] ＩＥＥＥ ８０２．１１によるＷＬＡＮシステムは、拡張分散チャネルアクセス（ＥＤＣＡ）プロトコルを使用して、パケットを異なるアクセスカテゴリ（ＡＣ）に分類する。各ＡＣは、トラフィックの異なる優先度を表す。ＳＴＡは、全てのパケットを異なるＡＣにマッピングして、ＡＣに関連する独立したキューにプッシュする。
[0078] 図３に、ＥＤＣＡプロトコルを使用するキューシステムの基準実装を示す。音声（ＶＯ）、ビデオ（ＶＩ）、ベストエフォート（ＢＥ）、及びバックグラウンド（ＢＫ）の４つのアクセスカテゴリ（ＡＣ）が示されており、各キューの優先度は、図中左から右に向かって低くなる。各ＡＣは、パケット送信の順序を管理するために独立したキューを有する。各キューは、チャネルアクセスを獲得するためにＣＳＭＡ／ＣＡに基づくランダムチャネルアクセス機構に依拠する。ＡＣのトラフィック優先度に応じて、各キューがチャネルアクセスを獲得するためのバックオフ時間は異なる。ＡＣのトラフィック優先度が高いほど、そのＡＣのキューの平均バックオフ時間は短くなる。したがって、優先度の高いＡＣのキュー内のパケットは、優先度の低いＡＣのキュー内のパケットよりも早くチャネルアクセスを獲得する可能性が高い。
２．課題の記述
[0080] ＣＳＭＡ／ＣＡを使用する現在の無線通信システムは、ＲＴＡパケットと非ＲＴＡパケットとを識別又は区別せず、また、ＲＴＡトラフィックのための特定のチャネル時間を確保することや、ＲＴＡパケットタイプと非ＲＴＡパケットタイプとを適切に統合する態様でキューを処理することもしない。現在のＣＳＭＡ／ＣＡの下では、全てのパケットは、同じランダムチャネルアクセススキームを使用しなければならない。ＣＳＭＡ／ＣＡにおけるランダムチャネルアクセススキームは、適時のＲＴＡパケット送信のためのチャネル時間を保証することができない。ＣＳＭＡ／ＣＡは、データがＭＡＣ層に到着した後に、チャネルアクセスを調整する。たいていの場合、データは、キュー内で送信されるのを待つ必要があり、これにより、パケット送信のキューイング遅延が生じる。
[0081] ＣＳＭＡ／ＣＡに基づくＥＤＣＡキューシステムは、トラフィックを、優先度に関して異なるＡＣに分類する。平均して、優先度が高いパケットは、バックオフ時間が短いので、優先度が低いパケットよりも早くチャネルにアクセスする。しかしながら、優先度が高いパケットが常に最初に送信されるという保証はなく、このことは、特にＲＴＡパケットの適時性要件の観点から問題である。ＣＳＭＡ／ＣＡに基づくＥＤＣＡキューシステムは、最悪の場合のパケット送信のレイテンシを考慮していない。現在のキューシステムにおけるパケットの待ち時間は長い可能性があり、最悪の場合のレイテンシに著しい影響がある。ＣＳＭＡ／ＣＡに基づくＥＤＣＡキューシステムは、ＲＴＡ間のレイテンシ要件の違いを考慮していない。いくつかのＲＴＡは高レイテンシ要件を有することができ、一方、いくつかのＲＴＡは低レイテンシ要件を有することができる。現在のキューシステムは、ＲＴＡパケットの様々なレイテンシ要件を満たすことができない。ＣＳＭＡ／ＣＡに基づくＥＤＣＡキューシステムは、パケットの適時性を考慮していない。すなわち、パケットは、そのパケットの再送信の数が再試行の限界を超える場合のみに、キューから破棄される。しかしながら、ＲＴＡパケットは、そのパケットの再送信の数が再試行の限界を超える前に無効になる場合がある。
３．本開示の寄与
[0083] 開示する技術を利用することによって、ＳＴＡは、ＲＴＡパケットと非ＲＴＡパケットとを識別及び区別することができる。提案する技術は、ＲＴＡパケットのための別個のキューを作成し、これらのキューは、非ＲＴＡパケットのためのキューとは別個である。それにもかかわらず、パケットは、ＥＤＣＡプロトコルに基づいて定められる通常のキューシステムを依然として使用することができる。
[0084] 開示する技術におけるＥＡキューの目的は、ＳＴＡがＲＴＡキューを特定できるので、ＳＴＡが常に非ＲＴＡパケットよりも早くＲＴＡパケットを送信できるようにすることである。ＲＴＡキューがまだエントリを有する（空ではない）時に、非ＲＴＡキューがチャネルアクセスを獲得することを許可しない。
[0085] 開示する技術におけるＴＡキューの目的は、ＳＴＡがＲＴＡキュー及び非ＲＴＡキューにチャネル時間を分散できるようにすることである。チャネル時間がＲＴＡキューに分散された時に、そのＲＴＡキュー内のＲＴＡパケットは、常に非ＲＴＡパケットよりも早く送信される。チャネル時間が非ＲＴＡキューに分散された時には、その非ＲＴＡキュー内の非ＲＴＡパケットがＲＴＡパケットよりも早く送信されることが可能である。
[0086] 提案する技術は、ＳＴＡがＲＴＡキューにおいて異なるキューイング規則を使用できるようにすることである。キュー内のＲＴＡパケットは、いくつかの所望の基準、例えば、ＲＴＡパケットの満了時間、優先度、又はいくつかの計算された重要度指標によってソートされて、キュー内のどのＲＴＡパケットをより早く送信すべきかを決定することができる。キューイング規則の目標は、全てのＲＴＡパケットをその満了時間前に送信できるようにすることである。
[0087] 提案する技術は、ＳＴＡがキュー内のＲＴＡパケットを追跡できるようにすることである。ＲＴＡパケットは、ＲＴＡキュー内で待つことなく送信することを許可される。また、ＲＴＡパケットは、ＲＴＡキュー内で待っている時に自身に関連する満了時間を有する。ＲＴＡパケットは、満了した時に、時間有効性（定められた有効期間）を失い、非ＲＴＡキューに移動させるか又は完全に破棄することができる。
４．実施形態例
４．１．ＳＴＡハードウェア構成
[0090] 図４に、ＳＴＡハードウェア構成の実施形態例１０を示し、ハードウェアブロック１３内へのＩ／Ｏ経路１２を示し、コンピュータプロセッサ（ＣＰＵ）１６及びメモリ（ＲＡＭ）１８が、ＳＴＡにセンサ、アクチュエータなどへの外部Ｉ／ＯをもたらすＩ／Ｏ経路１２に結合されたバス１４に結合される。プロセッサ１６上では、通信プロトコルを実装するプログラムを実行するための、メモリ１８からの命令が実行され、通信プロトコルが実行されて、ＳＴＡが「新規ＳＴＡ」（ネットワークに参加しようと試みる局）又はネットワーク内の既存のＳＴＡのうちの１つの機能を実行できるようにする。また、プログラミングは、現在の通信文脈においてどのような役割をしているかによって異なるモード（送信元、中間、送信先、アクセスポイント（ＡＰ）など）で動作するように構成されると理解されたい。
[0091] ＳＴＡは、単一のモデム及び単一の無線周波数（ＲＦ）回路を含むように構成することができるか、又は限定ではなく一例として図に示すように複数のモデム及び複数のＲＦ回路を含むように構成することができる。
[0092] この例では、図示のホストマシンは、近隣ＳＴＡとの間でフレームを送受信する複数のアンテナ２４ａ～２４ｎ、２５ａ～２５ｎ、２６ａ～２６ｎへの無線周波数（ＲＦ）回路２２ａ、２２ｂ、２２ｃに結合されたミリメートル波（ｍｍＷ）モデム２０を含むように構成される。また、ホストマシンは、（単複の）アンテナ２９への無線周波数（ＲＦ）回路２８に結合されたｓｕｂ－６ＧＨｚモデム２７を含むことも分かる。但し、この第２の通信経路が、本開示を実装するために絶対的に必要というわけではない。
[0093] したがって、この図示のホストマシンは、２つの異なる帯域で通信を行えるように、２つのモデム（マルチバンド）及びその関連するＲＦ回路を含むように構成される。一例として、限定するものではないが、所期の指向性通信帯域は、ｍｍＷ帯でデータを送受信するためのミリメートル波（ｍｍＷ）帯モデム及びその関連するＲＦ回路を含むように実装される。その他の帯域（一般に発見帯域と呼ばれる）は、ｓｕｂ－６ＧＨｚ帯でデータを送受信するためのｓｕｂ－６ＧＨｚモデム及びその関連するＲＦ回路を含む。
[0094] この例では、ｍｍＷ帯のためのＲＦ回路を３つ示しているが、本開示の実施形態は、所望の周波数帯又は周波数帯の範囲内であらゆる任意の数のＲＦ回路に結合されたモデム２０を含むように構成することができる。一般に、使用するＲＦ回路の数が多ければ多いほど、アンテナビーム方向のカバレッジが広くなる。なお、利用するＲＦ回路の数及びアンテナの数は、特定の装置のハードウェア制約によって決まると理解されたい。ＲＦ回路及びアンテナの中には、ＳＴＡが近隣ＳＴＡと通信する必要がないと判断した時に無効にできるものもある。少なくとも１つの実施形態では、ＲＦ回路が、周波数変換器及びアレイアンテナコントローラなどを含み、送受信のためにビームフォーミングを実行するように制御される複数のアンテナに接続される。このように、ＳＴＡは、複数のビームパターンの組を使用して信号を送信することができ、各ビームパターン方向がアンテナセクタとみなされる。
[0095] したがって、ホストマシンが近隣ＳＴＡとの間でデータフレームを送信／受信するモデムに対応することが分かる。モデムは、少なくとも１つのＲＦモジュールに接続されて、物理信号を生成及び受信する。（単複の）ＲＦモジュールは、送受信のためにビームフォーミングを実行するように制御される複数のアンテナに接続される。このように、ＳＴＡは、複数のビームパターンの組を使用して信号を送信することができる。
４．２．検討するＳＴＡトポロジ例
[0097] 図５に、開示する技術の目標を説明するためのネットワークトポロジ例（シナリオ）５０を示す。一例として、限定するものではないが、この例は、本明細書で部屋として例示する所与のエリア６８内に２つの基本サービスセット（ＢＳＳ）から構成される８つのＳＴＡがあると仮定する。各ＳＴＡは、同じＢＳＳ内の他のＳＴＡと通信することができる。全てのＳＴＡは、ランダムチャネルアクセスのためにＣＳＭＡ/ＣＡを使用する。第１のＢＳＳは、アクセスポイント（ＡＰ）として動作するＳＴＡ０ ５２と、非ＡＰ局ＳＴＡ１ ５４、ＳＴＡ２ ５６、ＳＴＡ３ ５８及びＳＴＡ４ ６０とを示す。第２のＢＳＳは、ＡＰとしてのＳＴＡ５ ６２と、ＳＴＡ６ ６４、ＳＴＡ７ ６６とを示す。
[0098] この例の全てのＳＴＡは、低レイテンシ通信を必要とするアプリケーション及びベストエフォート通信を利用するアプリケーションの両方をサポートするとみなされる。低レイテンシ通信を必要とするアプリケーションから生成されるデータは、リアルタイムアプリケーション（ＲＴＡ）トラフィックと呼ばれ、送信機ＳＴＡにおいてＲＴＡパケットとしてパケット化される。また、非時間依存アプリケーションから生成されるデータは、非ＲＴＡトラフィックと呼ばれ、送信機ＳＴＡにおいて非ＲＴＡパケットとしてパケット化される。結果として、送信機ＳＴＡは、通信のためにＲＴＡトラフィック及び非ＲＴＡトラフィックの両方を生成する。ＳＴＡ及びその送信リンクの位置は、このネットワークトポロジ例の図に示す通りである。
[0099] ＳＴＡが非ＲＴＡパケットを送信する時に、ＳＴＡは、通常のＣＳＭＡ／ＣＡスキームに従うことができる。ＳＴＡがＲＴＡパケットを送信する時に、ＳＴＡは、送信のためのチャネル時間を前もってスケジュールする。開示する技術の１つの目標は、ＲＴＡトラフィックのレイテンシを低減することである。
４．３．ＳＴＡ層モデル
[00101] 図６に、一般に開放型システム間相互接続（ＯＳＩ）モデルに従うＲＴＡ及び非ＲＴＡトラフィック通信の実施形態例７０を示す。ＯＳＩモデルでは、アプリケーション層、トランスポート層、ネットワーク層（ＩＰ）、データリンク層（ＭＡＣ）、及び物理層（ＰＨＹ）が存在する。本開示では、トランスポート層及びネットワーク層を単に中間の層と呼び、説明するプロトコル（例えば、提案するＩＥＥＥ ８０２．１１変形／標準）は、ＭＡＣ層及びＰＨＹ層を利用する。
[00102] この節では、トラフィック通信のためのＳＴＡ層モデルを説明する。この例に示すように、２つのＳＴＡ、すなわち、ＳＴＡ１ ７２及びＳＴＡ２ ７４が、ＲＴＡトラフィック及び非ＲＴＡトラフィック（８０、８２）を生成して、ＲＴＡパケット（８４）及び非ＲＴＡパケット（８６）で互いに通信する。以下、プロセス全体を説明する。
[00103] ＲＴＡトラフィック及び非ＲＴＡトラフィックの両方は、それぞれの送信機ＳＴＡのＡＰＰ層７６ａ、７８ａによって生成される。送信機ＳＴＡのＡＰＰ層は、中間の層７６ｂ、７８ｂを介して（通じて）ＭＡＣ層７６ｃ、７８ｃにＲＴＡトラフィック及び非ＲＴＡトラフィックを渡す。ＭＡＣ層７６ｃ、７８ｃ及びＰＨＹ層７６ｄ、７８ｄは、ＭＡＣヘッダ及びＰＬＣＰヘッダ内の追加の信号フィールドをパケットに追加し、パケットは、ネットワークのＰＨＹ層を通じて送信される。
[00104] 受信機ＳＴＡは、ＰＨＹ層でパケットを受け取り、復号し、パケットが正しく復号された場合、自機のＭＡＣ層に送信し、その後、データは、中間の層を通じて（介して）自機のＡＰＰ層に送られる。
[00105] 図７に、ＲＴＡトラフィックのための事前ネゴシエーションの実施形態例９０を示し、４．４．１節で説明する。
４．４．ＲＴＡパケットと非ＲＴＡパケットとを識別するための機構
[00107] 開示する技術は、無線通信システムにおいて、パケットがＲＴＡパケット又は非ＲＴＡパケットのいずれかである時に、パケットを分類する。ＲＴＡパケットは、パケット送信のために開示する技術を使用し、一方、非ＲＴＡパケットは、通常のＣＳＭＡ/ＣＡスキームを使用することができる。その目的のために、ＳＴＡは、この節で説明するように、ＭＡＣ層でＲＴＡパケットと非ＲＴＡパケットとを識別及び区別する。
[00108] 図８に、ＳＴＡ層モデルの実施形態例１３０を示し、この例では、送信機ＳＴＡのＭＡＣ層は、上位層からのＲＴＡトラフィックと非ＲＴＡトラフィックとを識別（１３２）して、それぞれＲＴＡパケットと非ＲＴＡパケットとにパケット化することができる。この節では、どのようにして送信機ＳＴＡが事前ネゴシエーションを使用してＲＴＡトラフィックを識別するかについての詳細を示す。
[00109] 図示のＳＴＡ層モデルによれば、送信機ＳＴＡは、ネットワークのＰＨＹ層を通じて受信機ＳＴＡにパケットを送信する。受信機ＳＴＡは、ＭＡＣ層でパケットを受け取った（１３４）時に、ＭＡＣヘッダ又は物理レイヤコンバージェンスプロトコル（ＰＬＣＰ）ヘッダに埋め込まれる情報を抽出（１３６）することに基づいて、ＲＴＡパケットと非ＲＴＡパケットとを識別することができる。この節では、どのようにして受信機ＳＴＡがＰＬＣＰ又はＭＡＣヘッダ情報に基づいてＲＴＡパケットを識別するかについての詳細を示す。図８の説明は、以下の節に続く。
[00110] ＲＴＡトラフィックは、所与の寿命以内に通信して、データ有効性を確実にする必要がある。換言すれば、ＲＴＡトラフィックは、寿命が満了する前に受信機によって受け取られなかった場合、無効であり破棄することができる。ＳＴＡは、ＰＨＹ層を通じて送信するために、ＲＴＡトラフィックをＲＴＡパケットにパケット化する。したがって、ＲＴＡパケットも、その送信の寿命を有する。この節では、どのようにしてＳＴＡがＲＴＡパケットの寿命満了に対処するかについての詳細を示す。
４．４．１．事前ネゴシエーション
[00112] 多くの場合、リアルタイムアプリケーション（ＲＴＡ）は、ちょうどコネクション型通信の場合と同様に、トラフィックを周期的に生成する。ＳＴＡ間にアプリケーションによって確立されるＲＴＡコネクション型通信は、ＲＴＡセッションと呼ばれる。ＳＴＡは、ネットワーク内の複数のＲＴＡセッションを有することができることが可能である。本開示による各ＳＴＡは、それらのＲＴＡセッションを適切に管理することができる。
[00113] ＲＴＡセッションがＲＴＡトラフィックの送信を開始する前に、接続を確立するために、送信機ＳＴＡと受信機ＳＴＡとの間で事前ネゴシエーションが行われる。事前ネゴシエーション中に、送信機ＳＴＡ及び受信機ＳＴＡは、送信機側のＭＡＣ層でＲＴＡトラフィックを識別し受信機側のＭＡＣ層でＲＴＡパケットを識別するために使用することができるＲＴＡセッション識別情報を含むＲＴＡセッションを記録する。
[00114] 図６に示したように、ＡＰＰ層が送信機側のＭＡＣ層にトラフィックを渡す時に、中間の層は、トラフィックにヘッダ情報を追加する。図８のブロック１３４で分かるように、送信機ＳＴＡのＭＡＣ層は、上位層からトラフィックを受け取った時に、上位層からのヘッダ情報を抽出（１３６）して、事前ネゴシエーションによって作成されるＲＴＡセッションレコードを探索（サーチ）する（１３８）。ヘッダ情報がレコード内の１つのＲＴＡセッションに一致する場合（１４０）、トラフィックはＲＴＡであり（１４４）、そうでない場合には、トラフィックは非ＲＴＡとみなされ（１４２）、いずれの場合にも、プロセスを終了する（１４６）。表１に、ＲＴＡトラフィックを識別するために使用することができるヘッダ情報を記載する。この節では、事前ネゴシエーションの詳細を説明する。
[00115] 事前ネゴシエーションの結果に従って、受信機ＳＴＡは、パケット送信のためのチャネルリソース、例えば、時間、周波数、及び他のメトリックによって、ＲＴＡパケットと非ＲＴＡパケットとを分類することも可能である。ＲＴＡパケットに許可されるチャネルリソースを使用して、パケットが受け取られた場合、ＳＴＡは、そのパケットをＲＴＡパケットとして識別する。そうでない場合には、そのパケットは非ＲＴＡパケットとみなされる。パケットがマルチユーザアップリンクモードで送信される時に、このシナリオを使用する。
[00116] 図７に、送信機側のＲＴＡトラフィックパケット（１００）及び受信機側のＲＴＡトラフィックパケット（１０２）のための送信機９２と受信機９４との間の事前ネゴシエーションを示す。１つの事前ネゴシエーションは、１つのＲＴＡセッションを確立し、そのＲＴＡセッションによって生成される全てのＲＴＡパケットのために使用することができると理解されたい。この図は、図６に示したようなＳＴＡ層モデルにおいて２つのＳＴＡ間でＲＴＡセッションを確立するための事前ネゴシエーションを示す。図示の送信機ＳＴＡ９２は、ＡＰＰ層９６ａと、中間の層９６ｂと、ＭＡＣ層９６ｃと、ＰＨＹ層９６ｄとを有し、受信機ＳＴＡ９４は、同じ層、すなわち、ＡＰＰ層９８ａと、中間の層９８ｂと、ＭＡＣ層９８ｃと、ＰＨＹ層９８ｄとを有する。以下、事前ネゴシエーションのプロセスを説明する。
[00117] 図７を参照すると、以下のステップが示されている。送信機９２のＡＰＰ層９６ａが、リソース（例えば、時間、チャネル）ネゴシエーションを要求（１０４）する。したがって、送信機ＳＴＡ側において、ＡＰＰ層はＲＴＡセッションを開始し、そのＲＴＡトラフィック送信のためのチャネルリソース（例えば時間及び帯域幅）のネゴシエーションを要求する。このネゴシエーション要求は、ＡＰＰ層内の管理エンティティから、ＭＡＣ層にある管理エンティティに送信される。
[00118] 送信機ＳＴＡのＭＡＣ層は、上位層からネゴシエーション要求を受け取り、送信機ＳＴＡ側のリソースの利用可能性をチェックする（１０６）。また、送信機ＳＴＡのＭＡＣ層は、セッションにおいて、ＲＴＡトラフィックを識別するために上位層によって提供されるＲＴＡセッション識別情報を記録する。識別情報のレコードは、表１に記載する情報、例えば、ＴＣＰ／ＵＤＰポート番号、サービスのタイプなどから選び出す（選択する）ことができる。送信機ＳＴＡのＭＡＣ層は、例えばリソースが利用できない場合に上位層からの要求を拒否するか、又は上位層と再交渉することができる。
[00119] 送信機ＳＴＡのＭＡＣ層は、リソースが利用可能であると分かった場合、受信機ＳＴＡのＭＡＣ層にネゴシエーション要求フレームを送信する（１０８）。ネゴシエーションフレームは、受信機が記録して後で使用できるようにＲＴＡセッションの識別情報を含む。
[00120] 受信機ＳＴＡのＭＡＣ層は、ネゴシエーション要求フレームを受け取った後に、ＭＡＣ層内の管理エンティティからＡＰＰ層内の管理エンティティにネゴシエーション要求を送信することによって、受信機ＳＴＡのＡＰＰ層にＲＴＡパケットの受信の準備をするように通知する（１１０）。ＡＰＰ層がＲＴＡ送信に利用できない場合、ネゴシエーションは失敗する場合がある。
[00121] 受信機のＡＰＰ層は、その層におけるリソースの利用可能性を許可し、ＡＰＰ層内の管理エンティティから、ＭＡＣ層にある管理エンティティにこの情報を送信する（１１２）。
[00122] 次に、受信機ＳＴＡのＭＡＣ層は、受信機ＳＴＡ側のリソースの利用可能性をチェックする（１１４）。ＭＡＣ層は、リソースが利用できない場合、拒否又は再交渉することができる。受信機ＳＴＡのＭＡＣ層は、受信機ＳＴＡ側の全てのネゴシエーション情報を収集して、送信機のＭＡＣ層に報告する（１１６）。
[00123] 送信機のＭＡＣ層は、ネゴシエーション結果を受け取り、送信機のＡＰＰ層に転送する（１１８）。ネゴシエーションが成功した場合、ＡＰＰ層は、両方のＳＴＡによって許可されるリソースを使用してＲＴＡトラフィックを送信することを開始することができる。
[00124] 事前ネゴシエーションによって作成されるＲＴＡセッションレコードに従って、送信機ＳＴＡのＭＡＣ層は、上位層からのヘッダ情報によって、ＲＴＡトラフィックと非ＲＴＡトラフィックとを識別する。ＡＰＰ層がＲＴＡトラフィックを生成した時に、中間の層によって提供されるヘッダ情報を含むＲＴＡトラフィックが、送信機ＳＴＡのＭＡＣ層に渡される。事前ネゴシエーションによって作成されるＲＴＡセッションレコードを探索することによって、送信機ＳＴＡは、そのヘッダ情報を使用してＲＴＡトラフィックを識別することができ、ＭＡＣ層においてＲＴＡトラフィックをＲＴＡパケットにパケット化する。
[00125] 送信機側でＲＴＡパケットトラフィックを識別する図８に再び戻る。ルーチンを開始（１３２）して、送信機ＳＴＡのＭＡＣ層が、上位層からトラフィックを受け取る（１３４）。ＭＡＣ層は、ＲＴＡトラフィックを識別するために上位層によって埋め込まれる情報を抽出（１３６）して、サービスのタイプ及びＴＣＰ／ＵＤＰポート番号などの上位層のヘッダ情報をチェックする。送信機ＳＴＡのＭＡＣ層は、上位層からのヘッダ情報と、事前ネゴシエーションによって作成されるＲＴＡセッションレコードとを比較（探索）する（１３８）。ヘッダ情報についてチェックする（１４０）。上位層からのヘッダ情報がレコード内のＲＴＡセッションに一致する場合、ブロック１４４に進んで、トラフィックはＲＴＡトラフィックであると判断され、そうでない場合には、ブロック１４２に進んで、トラフィックは非ＲＴＡトラフィックとみなされ、その後に、処理を終了する（１４６）。
４．４．２．パケットヘッダ情報
[00127] 図９に、ＲＴＡセッション識別情報フォーマットの実施形態例１５０を示す。送信機ＳＴＡは、ＲＴＡパケットを生成した時に、ＰＬＣＰヘッダ又はＭＡＣヘッダ内の追加の信号フィールドを追加する。追加の信号フィールドがＲＴＡセッション識別情報を含む時に、受信機ＳＴＡは、ＰＬＣＰヘッダ又はＭＡＣヘッダ内のＲＴＡセッション識別情報を使用して、ＭＡＣ層において、ＲＴＡパケットと非ＲＴＡパケットとを区別することができる。図に、サービスのタイプと、ＴＣＰ／ＵＤＰ送信元ポートと、ＴＣＰ／ＵＤＰ送信先ポートとを含むＲＴＡセッション識別情報の一例を示す。
[00128] 図１０に、ＡＰＰ層とＭＡＣ層との間のヘッダ情報交換（１８０、１８２）の実施形態例１７０を示す。図示の送信機ＳＴＡ１７２は、ＡＰＰ層１７６ａと、中間の層１７６ｂと、ＭＡＣ層１７６ｃと、ＰＨＹ層１７６ｄとを含む。図示の受信機ＳＴＡ１７４は、同じ層、すなわち、ＡＰＰ層１７８ａと、中間の層１７８ｂと、ＭＡＣ層１７８ｃと、ＰＨＹ層１７８ｄとを含む。
[00129] 図に、どのようにしてこのプロセスがＳＴＡ層モデルにおいて２つのＳＴＡ間で作動するかについての詳細を示す。送信機ＳＴＡのＡＰＰ層が、ＲＴＡトラフィックを生成（１８４）して、ＭＡＣ層に渡す。中間の層を通じてトラフィックが渡される時に、サービスのタイプフィールド及びＴＣＰ／ＵＤＰポート番号などのヘッダ情報がトラフィックに追加される。
[00130] 送信機ＳＴＡのＭＡＣ層は、上位層からＲＴＡトラフィックを受け取った時に、トラフィックからサービスのタイプ及びＴＣＰ／ＵＤＰポート番号などのヘッダ情報を抽出する。ＭＡＣ層は、事前ネゴシエーションによって作成されるＲＴＡセッションレコードを探索することによって、トラフィックがＲＴＡであると識別する（１８６）。
[00131] 次に、送信機ＳＴＡのＭＡＣ層は、トラフィックをＲＴＡパケット（１８０）にパケット化して、ＲＴＡセッション識別情報としてサービスのタイプ及びＴＣＰ／ＵＤＰポート番号をＭＡＣヘッダ又はＰＬＣＰヘッダに埋め込む。図９に、ＲＴＡセッション識別情報の一例を示した。次に、送信機ＳＴＡは、受信機ＳＴＡにＲＴＡパケットを送信（１８８）し、受信機ＳＴＡは、パケット（１８２）として受け取る。受信機ＳＴＡは、そのＭＡＣ層でＲＴＡパケットを受け取った時に、ＰＬＣＰヘッダ又はＭＡＣヘッダ内のＲＴＡセッション識別情報に基づいて、ＲＴＡパケットを識別（１８９）することができる。
[00132] 図１１に、受信機側のＭＡＣ層でＲＴＡパケットを識別するためのプロセスの実施形態例１９０を示す。プロセスを開始（１９２）して、受信機がＰＨＹ層でパケットを受け取る（１９４）。図１０で説明したように、ＲＴＡパケットのＭＡＣヘッダ又はＰＬＣＰヘッダは、ＲＴＡセッションの識別情報を含む。図１１を再び参照すると、識別情報が存在するかどうかを判断するためにチェックを行う（１９６）。識別情報が存在する場合、パケットがＲＴＡパケットであると受信機ＳＴＡが判断したので、実行はブロック２００に進む。一方で、識別情報が存在しない場合、パケットが非ＲＴＡパケットであると判断されたので、実行はブロック１９６からブロック１９８に進む。その後に、プロセスを終了する（２０２）。
４．５．ＲＴＡキューシステム
[00134] この節では、一般的な構造、ネットワーク層の相互作用モデル、及びキュー管理動作を含むＲＴＡキューシステムの詳細について説明する。ＲＴＡキューシステムは、ＲＴＡセッションの情報を使用して、そのＲＴＡセッションによって生成されるパケットを特定のＲＴＡキューにマッピングする。異なるＲＴＡキュー内のＲＴＡパケットは、キューの動作ルールに従って送信される。
４．５．１．ＲＴＡキュー構造
[00136] 図１２に、ＭＡＣ層におけるＲＴＡキューシステム（構造）の実施形態例２１０を示す。ＡＰＰ層２１２が、ＲＴＡトラフィック２１４及び非ＲＴＡトラフィック２１６を生成して、ＭＡＣ層に渡す。ＭＡＣ層は、トラフィックがキュー内で送信を待っている時にそのトラフィックを格納するための複数のキュー２１８を含むように構成される。図に示すように、ＲＴＡトラフィックを格納するために使用されるＲＴＡキューと、非ＲＴＡトラフィックを格納するために使用される非ＲＴＡキューとがある。非ＲＴＡキュー及びそのキュー管理動作は、図３に示したものと同じであり、音声（ＶＯ）キュー２３８、ビデオ（ＶＩ）キュー２４２、ベストエフォート（ＢＥ）キュー２４６、及びバックグラウンド（ＢＫ）キュー２５０として示す。ＲＴＡパケットは、複数のＲＴＡキュー２２６、２３０及び２３４にプッシュすることができる。キュー２１８の下に、チャネルアクセスバックオフ２２０が示され、これらは、キューの各々に対して２２８、２３２、２３６、２４０、２４４、２４８及び２５２として示され、チャネル２２４に結合される内部チャネルアクセス制御機構２２２に接続される。
[00137] 図中、異なるＲＴＡキューに含まれる同じパケットは、リンクするものとして示される。例えば、ＥＡキュー及びＳＡキュー内のセッション４のパケットは、１つのパケットである。ＲＴＡキューは、キューのチャネルアクセス方法に従って３つのタイプを有する。
[00138] 緊急チャネルアクセス（ＥＡ）キュー２２６：このキューは、最小送信レイテンシを必要とするＲＴＡパケットを送信するように設計される。ＥＡキューは、常にオープンであり、パケット送信のためのチャネルアクセスを獲得することを許可される。
[00139] 時間が割り当てられたチャネルアクセス（ＴＡ）キュー２３０：このキューは、割り当てられたチャネル時間を使用してＲＴＡパケットを送信するように設計される。ＴＡキューは、このキューに割り当てられるチャネル時間中にＲＴＡパケットを送信することのみを許可される。
[00140] セッションベースのチャネルアクセス（ＳＡ）キュー２３４：このキューは、特定のＲＴＡセッションパケットを送信するように設計される。ＳＡキューは、特定のＲＴＡセッションのパケットがＳＴＡによって要求された時にパケットを送信することを許可される。なお、キュー内の縦向きに示すパケットは、その（時間的な性質に対する）セッションの性質を示し、各パケット内に異なるセッションからのいくつかの情報を含む。例えば、図１２に示すように、ＳＴＡは、ＲＴＡセッション４のパケットを送信するように要求された場合、ＳＡキュー内のＲＴＡセッション４のパケットを送信する。
[00141] 開示するＲＴＡキューシステムでは、いくつかの制御機構は、効率的なキューイングのために相互運用する（一緒に協働して作動する）ように構成される。キュー分類機構は、ＲＴＡパケットを分類して異なるＲＴＡキューにマッピングするように構成される。満了パケット動作機構は、ＲＴＡパケットがＲＴＡキュー内で満了したことが分かった時に、ＲＴＡパケットに対する動作を定めるように構成される。例えば、動作は、満了したＲＴＡパケットを破棄すること、又は満了したＲＴＡパケットをＲＴＡキューから非ＲＴＡキューに移動させることとすることができる。キューイング規則機構は、ＲＴＡパケットがそのレイテンシ要件を確実に満たすように、ＲＴＡキュー内のＲＴＡパケットをソートする１又は２以上の方法を提供するように構成される。内部チャネルアクセス制御機構は、全てのＲＴＡキュー及び非ＲＴＡキューの間でチャネルアクセスを調整して、キュー間の競合衝突を回避するように構成される。キューチャネルリソース制限機構は、ＲＴＡキューが許容できないほど大量の（過剰な）既存のチャネルリソースを利用する（占有する）のを防ぐように構成される。
[00142] ＳＴＡは、ＲＴＡキュー内のパケットを送信する前に、チャネルアクセスを獲得するか否かのためにバックオフ時間を待つことができる。ＳＴＡは、パケットを送信する時に、チャネルアクセス方法に依存する。例えば、ＳＴＡがＣＳＭＡ／ＣＡを使用して、ＲＴＡキュー内のパケットを送信するためのチャネルにアクセスする場合、バックオフ時間が必要である。ＳＴＡがスケジュールされたチャネル時間を使用して、ＲＴＡキュー内のパケットを送信するためのチャネルにアクセスする場合、バックオフ時間は必要ない場合があり、本明細書では、多くの場合「任意」であるものとして説明する。図５に示すようなネットワークトポロジにおいて、一例を挙げることができる。ＳＴＡ０及びＳＴＡ５（２つのＡＰ）は、互いのチャネルスケジューリング情報を有する。ＳＴＡ０がＲＴＡキュー内のパケットを送信するための特定の期間をスケジュールした時に、ＳＴＡ５及びそれに関連するＳＴＡは、静かな（チャネルにアクセスしていない）状態のままであり、干渉を発生させない。ＳＴＡ０は、チャネルにアクセスすることを許可される唯一のＳＴＡであり、チャネルを求めて競合するためのバックオフ時間を必要としない。
４．５．２．ＲＴＡセッションのキュー構成
[00144] ＲＴＡセッションがＲＴＡパケットを生成した時に、ＲＴＡパケットは、そのレイテンシ要件に従って異なるＲＴＡキューにプッシュされる必要がある。したがって、ＲＴＡセッションは、そのＲＴＡパケットのためのキュー構成を設定する必要がある。ＲＴＡセッションのキュー構成は、そのＲＴＡセッションを開始する時に設定することができることが可能である。
[00145] ＳＴＡは、ＲＴＡセッションを記録する時に、セッションを追跡するために使用することができるそのセッションに関する情報を収集する。ＲＴＡセッションを追跡するために、ＲＴＡセッションは、例えば（ａ）ＲＴＡセッションを識別して他のＲＴＡセッションと区別するための識別情報、（ｂ）ＲＴＡセッションの最近のステータスを報告するためのステータス情報、（ｃ）ＲＴＡセッションによって生成されるＲＴＡトラフィックの送信品質要件を示すための要件情報、（ｄ）ＲＴＡセッションによって生成されるＲＴＡトラフィックに分散されるチャネルリソースを示すための送信情報、及び（ｅ）ＲＴＡセッションによって生成されるＲＴＡパケットのためのＲＴＡキュー構成を示すためのキュー情報、のうちの各々を含む多数の形態の情報を有する。
[00146] 図１３に、以下のデータのグループ、すなわち、識別情報２６５と、ステータス情報２７０と、要件情報２７５と、送信情報２８０と、キュー情報２８５とを含むＲＴＡセッション情報の実施形態例２６０を示す。
[00147] 識別情報２６５は、ＭＡＣヘッダからのもの、例えば送信元ＭＡＣアドレス及び送信先ＭＡＣアドレスであり、また、表１に記載するようなＭＡＣ層よりも上位の層からのもの、例えばセッションＩＤ、サービスのタイプ、送信元ＩＰアドレス、送信元ポート、送信先ＩＰアドレス、送信先ポートである。
[00148] ステータス情報２７０は、例えばセッションステータス、注釈、及び最新アクティブ時間として示す。セッションステータスは、トラフィックを生成するようにＲＴＡセッションを設定するか否かを示す。表２に、可能性のあるＲＴＡセッションステータスを記載する。ＲＴＡセッションステータスがアクティブである時に、ＲＴＡセッションを有効にしてＲＴＡトラフィックを生成する。ＲＴＡセッションステータスが非アクティブである時に、ユーザによってＲＴＡトラフィックを生成しないようにＲＴＡセッションを無効にする。ＲＴＡセッションステータスがエラーである時に、ＲＴＡセッションは、エラーによりＲＴＡトラフィックを生成又は送信することができない。注釈を使用して、ＲＴＡセッションステータスの詳細を示すことができる。注釈を使用して、警告又はエラーメッセージを搬送することができる。例えば、注釈は、このセッションにおいて多数のＲＴＡパケットが破損した時に送信品質が悪いことを示すことができる。最新アクティブ時間を使用して、ＲＴＡセッションのステータスをチェックするために何らかのイベントをトリガすることができる。最新アクティブ時間は、ＲＴＡセッションに対してＲＴＡパケット送信が行われるたびに更新される。この情報を使用して、ＲＴＡトラフィックが定期的に生成又は配信されるかどうかを追跡することができる。最新アクティブ時間が特定の期間にわたって更新されない場合、ＲＴＡセッションは、ＲＴＡトラフィックを生成又は配信していない。少なくとも１つの実施形態では、エラーが発生したかどうかを判断するために、ＲＴＡセッションステータスをチェックする。
[00149] 要件情報２７５は、帯域幅要件と、遅延要件と、ジッタ要件と、周期時間と、優先度と、セッション開始時間と、セッション終了時間とを含むことができる。帯域幅要件は、送信するＲＴＡトラフィックの量を示す。遅延要件は、ＲＴＡパケットの送信遅延を示す。ジッタ要件は、各周期送信時間中のＲＴＡパケット遅延の最大差分を示す。周期時間は、ＲＴＡセッションがＲＴＡトラフィックを１回生成する、すなわちＲＴＡセッションが周期時間ごとにトラフィックを生成する時間の継続を示す。優先度は、ＲＴＡトラフィックの優先度を示す。優先度が高いＲＴＡトラフィックを最初に送信すべきである。セッション開始時間及びセッション終了時間は、ＲＴＡセッションの開始時間及び終了時間を示す。
[00150] 送信情報２８０は、時間割り当てと、ＲＵ割り当てと、ＳＳ割り当てとを含むことができる。時間割り当ては、送信のためにＲＴＡセッションに分散されるチャネル時間を示す。ＲＵ割り当ては、送信のためにＲＴＡセッションに分散されるチャネルのリソースユニット（ＲＵ）を示す。ＲＵは、ＩＥＥＥ ８０２．１１ａｘで使用されるＯＦＤＭＡ用語におけるユニットである。ＲＵ割り当ては、送信のためにどのチャネル周波数を使用すべきかを決定する。ＳＳ割り当ては、ＲＴＡセッショントラフィック送信のための空間ストリーム割り当てを示す。ＳＳ割り当ては、ＩＥＥＥ ８０２．１１で使用されるＭＩＭＯ用語におけるユニット、又はビームフォーミング用語における指向性アンテナパターンの指標とすることができる。
[00151] キュー情報２８５は、初期キュータイプと、満了時間と、満了パケット破棄と、満了キュータイプとを含むことができる。初期キュータイプは、ＲＴＡセッションによってトラフィックが生成された時に、そのトラフィックをどのＲＴＡキューにプッシュすべきかを示す。初期キュータイプを使用して、非ＲＴＡキューを示すことも可能である。満了時間は、このＲＴＡセッションによって生成されるＲＴＡパケットが古くなる時間を表す。満了パケット破棄は、ＲＴＡキュー内の満了したＲＴＡパケットを破棄するか又は非ＲＴＡキューに移動させるかどうかを示す。満了キュータイプは、ＲＴＡセッションのトラフィックが満了した後に、そのトラフィックをどのキューにプッシュすべきかを示す。
[00152] ＲＴＡユーザがＲＴＡセッションを開始する時に、図７で説明したように、ＡＰＰ層によって開始手順が開始されて、ＭＡＣ層において実行される。２つのタイプの通信がある。すなわち、（ａ）１つのタイプの通信は、１つのＳＴＡ内の異なるネットワーク層間で行われ、（ｂ）第２のタイプの通信は、２つのＳＴＡのＭＡＣ層間で行われる。
[00153] １つのＳＴＡ内の異なるネットワーク層間の通信が行われる時に、ＲＴＡユーザは、クロスレイヤインターフェイスを通じてＲＴＡセッションを開始することができる。図７に、ＲＴＡキューシステムのための相互作用モデルを示した。ＲＴＡユーザは、ＭＡＣ層及びそれよりも上位の層と情報を通信及び交換することができる。ＲＴＡユーザは、ＭＡＣ層に複数のＲＴＡサービスを提供することができる。例えば、ＳＴＡは、ＭＡＣ層の局管理エンティティ（ＳＭＥ）におけるＲＴＡ管理を通じて、ＲＴＡセッションを開始して、ＲＴＡキューを構成することができる。次に、情報に従って、ＳＭＥは、ＭＡＣ副層管理エンティティサービスアクセスポイント（ＭＬＭＥ ＳＡＰ）インターフェイスを通じて、ＭＡＣ層において動作をすることができる。
[00154] ＲＴＡユーザがＲＴＡセッションを開始する時に、図７で説明したように、アプリケーション層によって開始手順が開始されて、ＭＡＣ層において実行される。２つのタイプの通信がある。第１のタイプの通信は、１つのＳＴＡ内の異なるネットワーク層間で行われ、一方、第２のタイプの通信は、２つのＳＴＡのＭＡＣ層間で行われる。
[00155] 図１４に、ＲＴＡキューシステムの相互作用の実施形態例２９０を示す。１つのＳＴＡ内の異なるネットワーク層間の通信が行われる時に、ＲＴＡユーザは、クロスレイヤインターフェイスを通じてＲＴＡセッションを開始することができる。ＲＴＡユーザは、ＭＡＣ層及びそれよりも上位の層と情報を通信及び交換することができる。ＲＴＡユーザは、ＭＡＣ層に複数のＲＴＡサービスを提供することができる。例えば、ＳＴＡは、ＭＡＣ層の局管理エンティティ（ＳＭＥ）におけるＲＴＡ管理を通じて、ＲＴＡセッションを開始して、ＲＴＡキューを構成することができる。次に、情報に従って、ＳＭＥは、ＭＡＣ副層管理エンティティサービスアクセスポイント（ＭＬＭＥ ＳＡＰ）インターフェイスを通じて、ＭＡＣ層において動作をすることができる。
[00156] 図１５に、２つのＳＴＡのＭＡＣ層間のメッセージ交換を例示する実施形態例３１０を示す。発信側ＳＴＡがＲＴＡセッションを開始することを決定した場合、発信側ＳＴＡのＳＭＥは、ＭＬＭＥ ＳＡＰインターフェイスを介してＭＬＭＥにＲＴＡＳＥＳＳＩＯＮＩＮＩＴ．ｒｅｑｕｅｓｔメッセージを送信する。ＲＴＡＳＥＳＳＩＯＮＩＮＩＴ．ｒｅｑｕｅｓｔメッセージのフォーマットは、表３で説明する。発信側ＳＴＡのＭＬＭＥは、ＲＴＡＳＥＳＳＩＯＮＩＮＩＴ．ｒｅｑｕｅｓｔメッセージを受け取った時に、ＲＴＡＳＥＳＳＩＯＮＩＮＩＴ．ｒｅｑｕｅｓｔメッセージ内のＲＴＡセッション情報を収集して、受信側ＳＴＡにＲＴＡセッション開始要求フレームを送信する。以下に、ＲＴＡセッション開始要求フレームのフォーマットを示す。受信側ＳＴＡのＭＬＭＥは、フレームを受け取り、ＭＬＭＥ ＳＡＰインターフェイスを通じて受信側ＳＴＡのＳＭＥに、表４に示すようなＲＴＡＳＥＳＳＩＯＮＩＮＩＴ．ｉｎｄｉｃａｔｉｏｎメッセージを生成する。図７で説明したように、受信側ＳＴＡのＭＡＣ層及び上位層は、リソースの利用可能性をチェックして、ＲＴＡセッション開始要求を許可すべきかどうかを決定する必要がある。次に、受信側ＳＴＡのＳＭＥは、受信側ＳＴＡのＭＬＭＥに、フィードバック情報を含むＲＴＡＳＥＳＳＩＯＮＩＮＩＴ．ｒｅｓｐｏｎｓｅメッセージを送信する。ＲＴＡＳＥＳＳＩＯＮＩＮＩＴ．ｒｅｓｐｏｎｓｅメッセージのフォーマットは、表５で説明する。次に、受信側ＳＴＡのＭＬＭＥは、発信側ＳＴＡにＲＴＡセッション開始応答フレームを送信する。発信側ＳＴＡのＭＬＭＥは、フレームを受け取り、発信側ＳＴＡのＳＭＥに、表６に示すようなＲＴＡＳＥＳＳＩＯＮＩＮＩＴ．ｃｏｎｆｉｒｍメッセージを送信する。次に、発信側のＳＭＥは、ＲＴＡユーザにＲＴＡセッションの開始が成功したか否かを通知する。
[00157] 図１６に、ＲＴＡセッション開始要求フレームの実施形態例３２０を示す。フレーム制御フィールドは、フレームのタイプを示す。継続時間フィールドは、ＣＳＭＡ／ＣＡチャネルアクセスのために使用されるＮＡＶ情報を含む。ＲＡフィールドは、フレームの受信側のアドレスを含む。ＴＡフィールドは、フレームを送信するＳＴＡのアドレスを含む。アクションフィールドは、管理フレームのタイプを示す。この場合、アクションフィールドは、管理フレームがＲＴＡセッション開始要求フレームであることを示す。開始要求情報フレームは、フレームがＲＴＡセッション開始要求フレームであることをアクションフィールドが示す時に、アクションフィールドに従い、以下のフィールドを含む。ＲＴＡセッションＩＤフィールドは、ＲＴＡセッションの識別情報を提供する。このフィールドの内容は、図９に示す。リソース要件フィールドは、図１３で説明したようなＲＴＡセッションの要件情報を示す。帯域幅要件フィールドは、送信するＲＴＡトラフィックの量を示す。遅延要件フィールドは、ＲＴＡパケットの送信遅延を示す。ジッタ要件フィールドは、各周期送信時間中のＲＴＡパケット遅延の最大差分を示す。周期時間フィールドは、ＲＴＡセッションがＲＴＡトラフィックを１回生成する時間の継続を示す。優先度フィールドは、ＲＴＡトラフィックの優先度を示す。セッション開始時間フィールドは、ＲＴＡセッションの開始時間を示す。セッション終了時間フィールドは、ＲＴＡセッションの終了時間を示す。キュー情報フィールドは、図１３で説明したようなＲＴＡセッションのキュー情報を含む。初期キュータイプフィールドは、ＲＴＡセッションによってトラフィックが生成された時に、そのトラフィックをどのＲＴＡキューにプッシュすべきかを示す。満了時間フィールドは、ＲＴＡパケットがＲＴＡキューに留まることを許可される時間を示す。満了パケット破棄フィールドは、ＲＴＡキュー内の満了したＲＴＡパケットを破棄するか又は非ＲＴＡキューに移動させるかどうかを示す。この例では、満了パケット破棄フィールドは、第１の状態（例えば「１」）に設定された時に、満了したＲＴＡパケットをキューシステムから破棄することを示す１ビットフィールドである。このフィールドが第２の状態（例えば「０」）に設定された時に、満了したＲＴＡパケットをＲＴＡキューから非ＲＴＡキューに移動させる。満了キュータイプフィールドは、ＲＴＡセッションのトラフィックが満了した後に、そのトラフィックをどのキューにプッシュすべきかを示す。
[00158] 図１７に、階層で示す以下のフィールドを有するＲＴＡセッション開始応答フレームの実施形態例３３０を示す。フレーム制御フィールドは、フレームのタイプを示す。継続時間フィールドは、ＣＳＭＡ／ＣＡチャネルアクセスのために使用されるＮＡＶ情報を含む。ＲＡフィールドは、フレームの受信側のアドレスを含む。ＴＡフィールドは、フレームを送信したＳＴＡのアドレスを含む。アクションフィールドは、管理フレームのタイプを示す。本例では、アクションフィールドは、管理フレームがＲＴＡセッション開始応答フレームであることを示す。開始応答情報フレームは、フレームがＲＴＡセッション開始応答フレームであることをアクションフィールドが示す時に、アクションフィールドに従う。開始応答情報フレームは、以下のフィールドを含む。ＲＴＡセッションＩＤフィールドは、ＲＴＡセッションの識別情報を提供する。このフィールドの内容は、図９に示す。開始結果フィールドは、開始が許可されるか否かを示す。この実施形態例では、開始結果フィールドは、第１の状態（例えば「１」）に設定された時に、開始が他のＳＴＡによって許可されたことを示す１ビットフィールド（指示）であり、そうでない場合には、このフィールドは、第２の状態（例えば「０」）に設定される。送信情報フィールドは、図１３で説明したようなＲＴＡセッションの送信情報を提供する。時間割り当てオプションフィールドは、送信のためにＲＴＡセッションにチャネル時間を分散するための割り当て方法のオプションを示す。ＲＵ割り当てオプションフィールドは、送信のためにＲＴＡセッションにチャネルのリソースユニット（ＲＵ）を分散するための割り当て方法のオプションを示す。ＳＳ割り当てオプションフィールドは、ＲＴＡセッションに空間ストリームを分散するための割り当て方法のオプションを示す。ステータス情報フィールドは、図９で説明したようなＲＴＡセッションのステータス情報を含む。セッションステータスフィールドは、ＲＴＡセッションのステータスを示す。注釈フィールドは、ＲＴＡセッションステータスの更なる詳細を示し、このフィールドを使用して、開始結果及びその詳細を報告することができる。キュー情報フィールドは、図９で説明したようなＲＴＡセッションのキュー情報を含む。初期キュータイプフィールドは、ＲＴＡセッションによってトラフィックが生成された時に、そのトラフィックをどのＲＴＡキューにプッシュすべきかを示す。満了時間フィールドは、ＲＴＡパケットがＲＴＡキューに留まることを許可される時間を示す。満了パケット破棄フィールドは、ＲＴＡキュー内の満了したＲＴＡパケットを破棄するか又は非ＲＴＡキューに移動させるかどうかを示す。この実施形態例では、満了パケット破棄フィールドは、第１の状態（例えば「１」）に設定された時に、満了したＲＴＡパケットをキューシステムから破棄することを示し、第２の状態（例えば「０」）に設定された時に、満了したＲＴＡパケットをＲＴＡキューから非ＲＴＡキューに移動させることを示す１ビットフィールドである。満了キュータイプフィールドは、ＲＴＡセッションのトラフィックが満了した後に、そのトラフィックをどのキューにプッシュすべきかを示す。
４．５．３．ＲＴＡキュー分類
[00160] キュー分類機構を使用して、ＲＴＡパケットを分類して異なるＲＴＡキューにプッシュする。この節では、どのようにしてキュー分類機構がパケットのＲＴＡセッション情報に基づいて作動するかについての詳細を示す。
[00161] 図１８に、ＲＴＡキューシステムと共に作動するキュー分類機構のためのクロスレイヤモデルの実施形態例３５０を示す。ＲＴＡユーザ３５２は、ＭＡＣ層よりも上位のネットワーク層（上位層３５４として示す）においてＲＴＡトラフィック識別情報を設定又は取得する（３５８）ことができる。すなわち、ＲＴＡセッションは、ＲＴＡトラフィックを生成する時に、そのＲＴＡトラフィックに一意の識別情報を埋め込む。図９に、ＲＴＡセッション識別情報の一例を示す。次に、ＲＴＡユーザは、識別情報を使用して（３６０）、４．４節で説明した方法を使用して、ＭＡＣ層３５６において、ＲＴＡトラフィック（３５５ａ）と非ＲＴＡトラフィック（３５５ｂ）とを識別することができる。ＲＴＡトラフィックはＲＴＡキューにプッシュされ、非ＲＴＡトラフィックは非ＲＴＡキューにプッシュされる。
[00162] キュー分類機構は、ＲＴＡ及び非ＲＴＡトラフィック識別機構とＲＴＡキューとの間に追加される。ＲＴＡトラフィックが識別（３６４）された後に、キュー分類機構３６６は、そのＲＴＡトラフィックをどのＲＴＡキューにプッシュすべきかを決定する。ＲＴＡユーザは、各ＲＴＡセッションに基づいて、キュー構成を設定する（３６２）ことができる。同じＲＴＡセッション識別情報を含むＲＴＡトラフィックは、そのＲＴＡセッションのキュー構成に従って、同じＲＴＡキューにプッシュされる。例えば、図に示すように、ＲＴＡセッション１及び２によって生成される全てのトラフィック（３７０）は、ＴＡキュー（３７６）及びＳＡキュー（３７８）にプッシュされる。ＲＴＡセッション３及び４によって生成される全てのトラフィック（３６８）は、ＥＡキュー（３７４）及びＳＡキュー（３７８）にプッシュされ、セッション１～４のＲＴＡトラフィック（３７２）は、ＳＡキュー（３７８）内にある。図示のキューの各々は、それぞれ、任意のバックオフ（３８０、３８２、３８４）を含む。
４．５．４．満了ＲＴＡパケット動作
[00164] 図１９に、ＳＴＡがＲＴＡキュー内の満了したＲＴＡパケットに対処する（このようなパケットを処理する）実施形態例３９０を示す。ＳＴＡがキューからＲＴＡパケットを破棄すべきかどうかを決定するプロセスを開始（３９２）して、ＳＴＡは、まず、このＲＴＡパケットがＲＴＡキュー又は非ＲＴＡキュー内にあるかどうかを識別する（３９４）。ＲＴＡパケットが非ＲＴＡキュー内にある場合、実行はブロック３９８に進んで、パケットの再送信の数が再試行の限界を超えるかどうかを判断するためにチェックする。再試行の限界を超えていない場合、実行はブロック４０６において終了する。一方で、再試行の限界を超える場合、ブロック４０４に進んでパケットを破棄して、その後、終了する（４０６）。
[00165] パケットがＲＴＡキュー内のＲＴＡパケットであることをチェック３９４が示す場合、ＲＴＡパケットが満了したかどうかをチェックする（３９６）。ＲＴＡパケットが満了していない場合、実行はブロック３９８に進んで、ＲＴＡパケットを破棄すべきかどうかを決定するために、再試行の限界をチェックする。一方で、ブロック３９６において、パケットが満了したと判断した場合、実行はブロック４００に進んで、パケットを非ＲＴＡキューに移動させるか又はパケットを破棄すべきかどうかを決定する。この決定は、図１３に示すようなＲＴＡセッションのキュー情報に基づいて行われるように構成される。キュー情報内の満了パケット破棄フィールドが「１」に設定されている場合、ＳＴＡは、ＲＴＡパケットをキューシステムから破棄する（４０４）。キュー情報内の満了パケット破棄フィールドが「０」に設定されている場合、ＳＴＡは、このパケットを非ＲＴＡキューに移動させて（ここでは、実行はブロック４０２に進む）、その後、プロセスを終了する（４０６）。本開示は、その他の又は追加の形態の情報に基づいて、パケットを移動又は破棄すべきかどうかについて決定を行うように構成することができると理解されるであろう。
[00166] 図２０及び図２１に、どのようにしてＳＴＡが満了したＲＴＡパケットをキューシステムから破棄するか又は満了したパケットをＲＴＡキューから非ＲＴＡキューに移動させるかを説明するための２つの例を示す実施形態例４１０、４７０を示す。図示のアプリケーション層４１２、４７２は、ＲＴＡトラフィック４１４、４７４、及び非ＲＴＡトラフィック４１６、４７５を処理する。これらの２つの例は、ＲＴＡセッション４のＲＴＡパケットが満了した後の、図１２に示したキューの変化（４１８、４７６）を示す。両図に、非ＲＴＡキューを、音声（ＶＯ）キュー４３２、４９０、ビデオ（ＶＩ）キュー４３４、４９２、ベストエフォート（ＢＥ）キュー４３６、４９４、及びバックグラウンド（ＢＫ）キュー４３８、４９６として示し、一方、ＲＴＡキューを、緊急アクセス（ＥＡ）４２６、４８４、時間が割り当てられたチャネルアクセス（ＴＡ）４２８、４８６、及びセッションベースのチャネルアクセス（ＳＡ）４３０、４８８として示す。任意のバックオフ４２０、４７８は、これらのキューの各々に対して、４４０、４４２、４４４、４４６、４４８、４５０、４５２、４９８、５００、５０２、５０４、５０６、５０８及び５１０として示され、これらは、チャネル４２４、４８２に接続する内部チャネルアクセス制御機構４２２、４８０に結合される。
[00167] 図２０に、満了したＲＴＡパケットをＲＴＡキューから非ＲＴＡキューに移動させる例を示す。この例は、図１９のブロック３９４、３９６、４００、４０２の論理に従う。図１２に示すように、ＲＴＡセッション４のＲＴＡパケットは、ＥＡキュー及びＳＡキュー内に存在した。ＲＴＡセッション４のＲＴＡパケットが満了した場合、ＳＴＡは、図に示すように、このパケットを非ＲＴＡキュー（例えばＢＫ４３８）に移動させる。
[00168] 図２１に、満了したＲＴＡパケットをＲＴＡキューシステムから破棄する例を示す。この例は、図１９のブロック３９４、３９６、４００、４０４に示す論理に従う。図１２に示すように、ＲＴＡセッション４のＲＴＡパケットは、ＥＡキュー及びＳＡキュー内に存在した。ＲＴＡセッション４のＲＴＡパケットが満了した場合、ＳＴＡは、このパケットをＥＡキュー及びＳＡキューから破棄する。
[00169] 図３に示すような通常のキューシステムにおいて満了ＲＴＡパケット動作を適用することが可能である。
[00170] 図２２に、満了したＲＴＡパケットを１つの非ＲＴＡキューから別の非ＲＴＡキューに移動させる実施形態例５３０を示す。図示のアプリケーション層５３２、５３２’は、キューに結合されるＲＴＡストリーム５３４、５３４’を含む。非ＲＴＡキュー５３６、５３６’を、音声（ＶＯ）キュー、ビデオ（ＶＩ）キュー、ベストエフォート（ＢＥ）キュー、及びバックグラウンド（ＢＫ）キューとして示す。これらのキューは、任意のバックオフ（５３８、５３８’）機構を通じて出力する。このシナリオは、ＲＴＡトラフィックがＲＴＡセッションによって生成された時にＥＤＣＡキューにプッシュされた場合に、発生することができる。図に示すように、ＲＴＡセッション３のＲＴＡパケットは、図の左側に示すように、生成された時にＶＯキューにプッシュされた。しかしながら、パケットは、満了した後まで送信される機会を得られなかった。次に、そのパケットは、図の右側に示すように、ＢＫなどの別のＥＤＣＡキューに移動（５４０）させることができる。
[00171] 図３に示すような通常のキューシステムにおけるＲＴＡパケットを、満了した時に破棄することができることも可能である。
４．５．５．ＲＴＡキューイング規則
[00173] この節では、どのようにしてＳＴＡがＲＴＡキューイング規則を設定してＲＴＡキュー内のＲＴＡパケットの送信の順序をソートするかについての詳細を説明する。ＲＴＡキューシステムでは、ＳＴＡは、異なる基準によってパケットをソートすることができる。限定ではなく一例として、３つの基準を説明する。（１）優先度によるＲＴＡパケットのソーティングを実行して、優先度が高いＲＴＡパケットが、優先度が低いパケットよりも早く送信されるようにする。（２）満了時間によるＲＴＡパケットのソーティングを実行して、満了時間が短いＲＴＡパケットが、満了時間が長いパケットよりも早く送信されるようにする。（３）重要度指標によるＲＴＡパケットのソーティングを実行して、ＲＴＡユーザが、キュー内のＲＴＡパケットの重要度指標を計算するようにカスタマイズされたアルゴリズムを提供することができるようにする。例えば、計算において、ＲＴＡパケットの優先度及び満了時間を考慮することができる。重要度指標が高いＲＴＡパケットは、重要度指標が低いパケットよりも早く送信される。
[00174] ＲＴＡキューイング規則は、別のＳＴＡによって設定することができる。例えば、ＡＰは、その関連するＳＴＡにおいてＲＴＡキューイング規則を制御する必要がある場合がある。
[00175] 図２３に、ＲＴＡキューイング規則を設定するための２つのＳＴＡのＭＡＣ層間のメッセージ交換の実施形態例５５０を示す。図１４に、ＳＴＡの相互作用モデルを示す。
[00176] 図２３に示すように、発信側ＳＴＡ（例えばＡＰ）が受信側ＳＴＡ（例えば非ＡＰ）においてＲＴＡキューイング規則を更新する必要がある時に、発信側ＳＴＡのＳＭＥは、ＭＬＭＥ ＳＡＰインターフェイスを介してＭＬＭＥにＲＴＡＱＵＥＵＥＳＯＲＴ．ｒｅｑｕｅｓｔメッセージを送信する。ＲＴＡＱＵＥＵＥＳＯＲＴ．ｒｅｑｕｅｓｔメッセージのフォーマットは、表７で説明する。発信側ＳＴＡのＭＬＭＥは、ＲＴＡＱＵＥＵＥＳＯＲＴ．ｒｅｑｕｅｓｔメッセージを受け取った時に、ＲＴＡＱＵＥＵＥＳＯＲＴ．ｒｅｑｕｅｓｔメッセージ内のＲＴＡキューイング規則情報（すなわち、ＲＴＡＱｕｅｕｅＴｙｐｅ及びＳｏｒｔＡｌｇｏｒｉｔｈｍ）を収集して、受信側ＳＴＡにＲＴＡキューソーティングフレームを送信する。以下に、ＲＴＡキューソーティングフレームを説明する例を示す。受信側ＳＴＡのＭＬＭＥは、フレームを受け取り、ＭＬＭＥ ＳＡＰインターフェイスを介して受信側ＳＴＡのＳＭＥに、表８に示すようなＲＴＡＱＵＥＵＥＳＯＲＴ．ｉｎｄｉｃａｔｉｏｎメッセージを生成する。次に、受信側ＳＴＡは、ＲＴＡＱＵＥＵＥＳＯＲＴ．ｉｎｄｉｃａｔｉｏｎメッセージ内の情報に従って、ＲＴＡキューイング規則を設定する。
[00177] 図２４に、以下のフィールドを有するＲＴＡキューソーティングフレームの実施形態例５７０を示す。フレーム制御フィールドは、フレームのタイプを示す。継続時間フィールドは、ＣＳＭＡ／ＣＡチャネルアクセスのために使用されるＮＡＶ情報を含む。ＲＡフィールドは、フレームの受信側のアドレスを含む。ＴＡフィールドは、フレームを送信したＳＴＡのアドレスを含む。アクションフィールドは、管理フレームのタイプを示す。この場合、アクションフィールドは、管理フレームがＲＴＡキューソーティングフレームであることを示す。ＲＴＡキューソート要求情報フィールドは、ＲＴＡキューイング規則要求情報を含む。ＲＴＡキューの数フィールドは、キューイング規則を設定する必要があるＲＴＡキューの数を示す。キュータイプフィールドは、後続のキューソートアルゴリズムによってソートされるＲＴＡパケットを有するキュー（例えば、ＥＡ、ＴＡ、及びＳＡ）を示す。キューソートアルゴリズムフィールドは、キュー内のＲＴＡパケットをソートする際にどのアルゴリズム（方法）を使用すべきかを示す。
[00178] 上記に説明したＲＴＡキューイング規則設定手順を使用して、図３に示すようなＥＤＣＡキューなどの非ＲＴＡキュー内のパケットをソートすることが可能である。
[00179] 図２５、図２６及び図２７は、ＲＴＡキュー内のＲＴＡパケットをソートする例の３つの実施形態例５９０、６１０、６３０である。各例では、ＲＴＡキューは、同じＲＴＡパケットを有する。各例は、異なるソーティング方法を使用し、その結果、キュー内のＲＴＡパケットの送信の順序が異なる。
[00180] 図２５では、ＳＴＡは、パケットの優先度によってＲＴＡキュー内のＲＴＡパケットをソートしている。ＲＴＡキューのタイプは、ＥＡ又はＴＡとすることができる。図に示すように、ＲＴＡパケットは、パケット優先度の高い順にソートされる。すなわち、優先度が高いＲＴＡパケットは、優先度が低いパケットよりも早く送信される。この例では、ＲＴＡパケットの満了時間は、キュー内のＲＴＡパケットの順序に影響を及ぼさない。
[00181] 図２６では、ＳＴＡは、パケットの満了時間によってＲＴＡキュー内のＲＴＡパケットをソートしている。図に示すように、ＲＴＡキューは、ＥＡ又はＴＡとすることができる。ＲＴＡパケットは、パケット満了時間の短い順にソートされる。すなわち、満了時間が短いＲＴＡパケットは、満了時間が長いパケットよりも早く送信される。この例では、ＲＴＡパケットの満了時間が同じである時に、優先度が高い方のＲＴＡパケットをより早く送信することができる。また、ＲＴＡパケットの優先度がキュー内のＲＴＡパケットの順序に影響を及ぼさないようにすることが可能である。
[00182] 図２７では、ＳＴＡは、パケットの重要度指標を計算することによって、ＲＴＡキュー内のＲＴＡパケットをソートする。例えば、パケットの重要度指標は、下式によって計算することができる。
ＩｍｐｏｒｔａｎｃｅＩｎｄｅｘ＝ｗ1×ＥｘｐｉｒａｔｉｏｎＴｉｍｅ＋ｗ2×Ｐｒｉｏｒｉｔｙ
ここで、ｗ1及びｗ2は、２つの任意の重み数である。図に示すように、ＲＴＡパケットの重要度指標は、ｗ1＝－０．１及びｗ2＝１で計算される。重要度指標に従って、重要度指標が高いＲＴＡパケットは、重要度指標が低いパケットよりも早く送信される。
４．５．６．内部チャネルアクセス制御
[00184] 図２８に、異なるキューにチャネル時間を割り当てる実施形態例６５０を示す。ＳＴＡは、ＲＴＡキュー及び非ＲＴＡキューに別個のチャネル時間を割り当てて、チャネルにアクセスしようと試みることができる。図に、ＳＴＡが異なるキューにチャネル時間を割り当てる例を示す。周期時間ごとに、ＳＴＡは、ＴＡキューと、異なるＲＴＡセッションに対応するＳＡキューと、非ＲＴＡキューとに別個のチャネル時間を割り当てる。ＥＡキューは、ＥＡキューによって送信されるパケットが高い優先度を有する場合、常時チャネルにアクセスすることができる。
[00185] 図２９に、キューチャネル時間割り当ての実施形態例６７０を示す。１つのＳＴＡ（例えばＡＰ）は、他のＳＴＡのチャネル時間割り当てを変更することが可能である。図に、１つのＳＴＡが別のＳＴＡにおいて異なるキューにチャネル時間を割り当てる例を示す。図１５に、ＳＴＡの相互作用モデルを示した。発信側ＳＴＡ（例えばＡＰ）が受信側ＳＴＡ（例えば非ＡＰ）においてＲＴＡキューパラメータを更新する必要がある時に、発信側ＳＴＡのＳＭＥは、ＭＬＭＥ ＳＡＰインターフェイスを通じてＭＬＭＥにＱＵＥＵＥＴＩＭＥＡＬＬＯＣＡＴＩＯＮ．ｒｅｑｕｅｓｔメッセージを送信する。ＱＵＥＵＥＴＩＭＥＡＬＬＯＣＡＴＩＯＮ．ｒｅｑｕｅｓｔメッセージのフォーマットは、表９で説明する。発信側ＳＴＡのＭＬＭＥは、ＱＵＥＵＥＴＩＭＥＡＬＬＯＣＡＴＩＯＮ．ｒｅｑｕｅｓｔメッセージを受け取った時に、ＱＵＥＵＥＴＩＭＥＡＬＬＯＣＡＴＩＯＮ．ｒｅｑｕｅｓｔメッセージ内のキューチャネル時間割り当て情報（すなわち、ＱｕｅｕｅＴｙｐｅ、ＰｅｒｉｏｄｉｃＴｉｍｅ、ＳｔａｒｔＴｉｍｅ、ＤｕｒａｔｉｏｎｏｆＥａｃｈＰｅｒｉｏｄ、及びＥｎｄＴｉｍｅ）を収集して、受信側ＳＴＡにキューチャネル時間割り当てフレームを送信する。
[00186] 以下に、キューチャネル時間割り当てフレームを説明する。受信側ＳＴＡのＭＬＭＥは、フレームを受け取り、ＭＬＭＥ ＳＡＰインターフェイスを通じて受信側ＳＴＡのＳＭＥに、表１０に示すようなＱＵＥＵＥＴＩＭＥＡＬＬＯＣＡＴＩＯＮ．ｉｎｄｉｃａｔｉｏｎメッセージを生成する。次に、受信側ＳＴＡは、ＱＵＥＵＥＴＩＭＥＡＬＬＯＣＡＴＩＯＮ．ｉｎｄｉｃａｔｉｏｎメッセージ内の情報に従って、キューチャネル時間割り当てを設定する。
[00187] 図３０に、以下のフィールドを有するキューチャネル時間割り当てフレームの実施形態例６９０を示す。フレーム制御フィールドは、フレームのタイプを示す。継続時間フィールドは、ＣＳＭＡ／ＣＡチャネルアクセスのために使用されるＮＡＶ情報を含む。ＲＡフィールドは、フレームの受信側のアドレスを含む。ＴＡフィールドは、フレームを送信したＳＴＡのアドレスを含む。アクションフィールドは、管理フレームのタイプを示す。この場合、アクションフィールドは、管理フレームがキューチャネル時間割り当てフレームであることを示す。キューチャネル時間割り当てフィールドは、キューにチャネル時間を割り当てることの情報を含む。キュータイプフィールドは、キューのタイプ（例えば、ＴＡキュー及び非ＲＴＡキュー）を示す。周期時間フィールドは、キュー内のパケットを１回送信するためにキューに割り当てられる時間の継続を示す。開始時間フィールドは、ＳＴＡがそのキュー内のパケットを初めて送信するための期間を有する時間を示す。各期間の継続時間フィールドは、ＳＴＡが周期時間ごとにキュー内のパケットを送信する必要があるチャネル時間を示す。終了時間フィールドは、ＳＴＡがそのキュー内のパケットを送信するための残り時間がない時間を示す。
[00188] 図３１Ａ及び図３１Ｂに、どのようにしてＳＴＡが異なるＲＴＡキューと非ＲＴＡキューとの間のチャネルアクセスを制御するかについての実施形態例７１０を示す。図３１Ａにおいて、ＳＴＡは、どのキューからパケットを送信すべきかを決定（７１２）する必要がある時に、まず、トリガフレームを受け取ったことによりチャネルアクセスを獲得したかどうかをチェックする（７１４）。ＳＴＡがトリガフレーム（ＴＦ）を受け取った場合、実行はブロック７１６に進んで、ＴＦがＲＴＡセッション情報を含むかどうかをチェックする。ＴＦがＲＴＡセッション情報を含む場合、実行は図３１Ｂのブロック７３２に進んで、ＴＦに埋め込まれるＲＴＡセッション情報に従って、ＳＡキューからＲＴＡパケットを送信して、プロセスを終了する（７４２）。また、なお、ＴＦが非ＲＴＡパケット送信要求を含む場合、ＳＴＡは、非ＲＴＡパケットを送信する。ＲＴＡセッション情報を含むＴＦのフォーマットは、後の節で説明する。
[00189] ブロック７１４に戻ると、ＳＴＡがＴＦを受け取ることなくチャネルアクセスを獲得したと判断した場合、ＲＴＡキュー内のパケットを送信するために現在のチャネル時間を割り当てたかどうかをチェックする（７１８）。例えば、ＴＡキューからパケットを送信するために、又はＳＡキューから特定のＲＴＡセッションのパケットを送信するために、現在のチャネル時間を割り当てることができる。異なるキューにチャネル時間を割り当てる方法は、図２８に示したものと同じである。図３１Ａのブロック７１８において、ＲＴＡキュー内のパケットを送信するために現在のチャネル時間を割り当てたのではないと判断した場合、実行はブロック７２０に進んで、ＳＴＡは、ＲＴＡパケットのためのＥＡキューのバッファをチェックする。ＥＡキューのバッファが空ではない場合、ＳＴＡは、最初に送信すべきいくつかのＲＴＡパケットをＥＡキュー内に有し、実行はブロック７３６に進んで、ＥＡキュー内の（単複の）ＲＴＡパケットを送信して、実行を終了する（７４２）。一方で、ＥＡキューのバッファが空であると分かった場合、ブロック７３８に進んで、ＳＴＡは非ＲＴＡキューから（単複の）パケットを送信して、その後、実行を終了する（７４２）。
[00190] ブロック７１８に戻ると、ＲＴＡキュー内のパケットを送信するために現在のチャネル時間を割り当てた場合、ＳＴＡは、ＴＡキュー内のパケットを送信するために又はＳＡキュー内の特定のＲＴＡセッションのパケットを送信するために現在のチャネル時間を割り当てたかどうかを知り（認識し）、実行はブロック７２２に進んで、ＴＡキュー内のパケットを送信するために現在のチャネル時間を割り当てたかどうかをチェックする。チェックにおいて、特定のＲＴＡセッションによる送信のためにチャネル時間を割り当てたのではないと判断した場合、ブロック７２４に進んで、候補パケットとして、送信パケット候補をＴＡキュー内の最初のパケットとして設定し、実行は図３１Ｂの判定ブロック７２８に進む。
[00191] 一方で、ブロック７２２において、ＳＡキュー内の特定のＲＴＡセッションのパケットを送信するために現在のチャネル時間を割り当てたと判断した場合、ブロック７２６に進んで、ＳＴＡは、ＳＡキュー内のそのＲＴＡセッションのパケットを送信パケット候補として設定して、その後、図３１Ｂのブロック７２８に進む。
[00192] 図３１Ｂのブロック７２８において、ＳＴＡは、候補パケットを送信することを決定する前に、ＲＴＡパケットのためのＥＡキューのバッファをチェックする。これは、ＥＡキューが、パケット送信のためにＴＡキュー及びＳＡキューに割り当てられるチャネル時間を使用することができるからである。ＥＡキュー内にＲＴＡパケットがある場合、ブロック７３０において、ＳＴＡは、ＥＡキュー内のパケットの優先度と候補パケットの優先度とを比較する。ブロック７３４において、ＥＡキュー内のパケットが高い優先度を有すると判断した場合、ブロック７３６に進んで、ＳＴＡはＥＡキュー内のパケットを送信して、その後、終了する（７４２）。
[00193] 一方で、ブロック７３４においてＥＡキュー内のパケットが低い優先度を有すると判断した場合、又はＥＡキューのバッファが空である場合、実行はブロック７４０に進んで、ＳＴＡは候補パケットを送信して、その後、終了する（７４２）。
[00194] ブロック７２８に戻ると、キュー内にＲＴＡパケットがないと判断した場合、実行はブロック７４０に進んで、候補パケットを送信して、プロセスを終了する（７４２）。
４．５．７．キューチャネルリソース制限機構
[00196] 少なくとも１つの実施形態では、ＲＴＡキューシステムは、ＲＴＡキューと非ＲＴＡキューとの間のチャネル時間割り当ての公平性も考慮する。この機構の目標は、ＲＴＡキューが送信を独占する、具体的には、ＲＴＡパケットを送信するために過剰な（法外な又は不公平な量の時間）チャネル時間を占有するのを防ぐことである。以下に、法外な長さの時間にわたってチャネルを占有するＲＴＡキューから非ＲＴＡキューを保護するための複数の方法を説明する。
[00197] （ａ）ＥＡ／ＴＡキューのバッファサイズを制限して、ＲＴＡパケット独占を防ぐ。ＳＴＡは、ＥＡ／ＴＡキューの最大バッファサイズを設定する。ＲＴＡユーザがＲＴＡセッションを開始する時に、ＳＴＡは、図１３に示すようなＲＴＡセッション要件情報に従って、ＲＴＡキューの必要なバッファサイズを推定する。バッファサイズがＲＴＡセッション要件を満たすことができない場合、ＳＴＡは、ＲＴＡセッション開始を拒絶することができる。
[00198] （ｂ）ＴＡ／ＳＡキューのチャネル時間を制限して、ＲＴＡパケット独占を防ぐ。ＳＴＡは、ＴＡ／ＳＡキュー内のＲＴＡパケットを送信するためのチャネル時間の最大比を設定する。前述の方法と同様に、ＳＴＡは、ＲＴＡセッションを開始する時に、チャネル時間の利用可能性をチェックすることができる。そのＲＴＡセッションのパケットをキュー内に追加した後に、そのキューのチャネル時間がパケットを送信するのに十分でない場合、ＳＴＡは、ＲＴＡセッション開始を拒絶することができる。
[00199] （ｃ）ＲＴＡキュー内のＲＴＡセッションの数を制限して、ＲＴＡパケット独占を防ぐ。ＳＴＡは、各ＲＴＡキュー内のＲＴＡセッションの最大数を設定する。ＳＴＡは、新たなＲＴＡセッションを開始する時に、そのＲＴＡセッションのパケットをＲＴＡキューにプッシュすることを決定する。そのＲＴＡキューにパケットがプッシュされたＲＴＡセッションの数が最大数に達した場合、ＳＴＡは、ＲＴＡセッション開始を拒絶することができる。
[00200] 図３２に、ＲＴＡキューパラメータ設定の実施形態例７５０を示す。少なくとも１つの実施形態では、ＳＴＡにおける最大バッファサイズ、最大チャネル時間、及び／又はＲＴＡキューのＲＴＡセッションの最大数のパラメータは、その関連するＡＰによって設定する（確立する）ことができる。図に、１つのＳＴＡ（例えばＡＰ）が、別のＳＴＡにおけるキューパラメータ、例えば最大バッファサイズ、最大チャネル時間及びＲＴＡキューのＲＴＡセッションの最大数を設定する例を示す。図１４に、ＳＴＡの相互作用モデルを示した。発信側ＳＴＡ（例えばＡＰ）が受信側ＳＴＡ（例えば非ＡＰ）においてＲＴＡキューパラメータを更新する必要がある時に、発信側ＳＴＡのＳＭＥは、ＭＬＭＥ ＳＡＰインターフェイスを介してＭＬＭＥにＲＴＡＱＵＥＵＥＰＡＲＡＳＥＴ．ｒｅｑｕｅｓｔメッセージを送信する。ＲＴＡＱＵＥＵＥＰＡＲＡＳＥＴ．ｒｅｑｕｅｓｔメッセージのフォーマットは、表１１で説明する。
[00201] 発信側ＳＴＡのＭＬＭＥは、ＲＴＡＱＵＥＵＥＰＡＲＡＳＥＴ．ｒｅｑｕｅｓｔメッセージを受け取った時に、ＲＴＡＱＵＥＵＥＰＡＲＡＳＥＴ．ｒｅｑｕｅｓｔメッセージ内のＲＴＡキューパラメータ情報（すなわち、ＲＴＡＱｕｅｕｅＴｙｐｅ、ＭａｘＢｕｆｆｅｒＳｉｚｅ、ＭａｘＣｈａｎｎｅｌＴｉｍｅ、及びＭａｘＮｕｍｏｆＲＴＡＳｅｓｓｉｏｎｓ）を収集して、受信側ＳＴＡにＲＴＡキューパラメータ設定フレームを送信する。
[00202] 図３３に、ＲＴＡキューパラメータ設定フレームの実施形態例７７０を示す。受信側ＳＴＡのＭＬＭＥは、フレームを受け取り、ＭＬＭＥ ＳＡＰインターフェイスを介して受信側ＳＴＡのＳＭＥに、表１２に示すようなＲＴＡＱＵＥＵＥＰＡＲＡＳＥＴ．ｉｎｄｉｃａｔｉｏｎメッセージを生成する。次に、受信側ＳＴＡは、ＲＴＡＱＵＥＵＥＰＡＲＡＳＥＴ．ｉｎｄｉｃａｔｉｏｎメッセージ内の情報に従って、ＲＴＡキューパラメータを設定する。
[00203] 図に、以下のようなＲＴＡキューパラメータ設定フレームの内容を示す。フレーム制御フィールドは、フレームのタイプを示す。継続時間フィールドは、ＣＳＭＡ／ＣＡチャネルアクセスのために使用されるＮＡＶ情報を含む。ＲＡフィールドは、フレームの受信側のアドレスを含む。ＴＡフィールドは、フレームを送信したＳＴＡのアドレスを含む。アクションフィールドは、管理フレームのタイプを示す。限定ではなく一例として、図示の例では、アクションフィールドは、管理フレームがＲＴＡキューパラメータ設定フレームであることを示す。ＲＴＡキューパラメータフィールドは、ＲＴＡキューパラメータ設定情報を含む。キュータイプフィールドは、後続のキューソートアルゴリズムによってソートされるＲＴＡパケットを有するキューのタイプ（例えば、ＥＡ、ＴＡ、及びＳＡ）を示す。最大バッファサイズフィールドは、キューの最大バッファサイズを示す。最大チャネル時間は、キューに割り当てることができるチャネル時間の最大比を示す。限定ではなく一例として、この最大比は、総チャネル時間の割合、又は他の所望通りのメトリックを示すことができる。ＲＴＡセッションの最大数フィールドは、ＲＴＡキュー内で待つことができるパケットを有するＲＴＡセッションの最大数を示す。
[00204] キューパラメータ、例えば最大バッファサイズ、最大チャネル時間、ＲＴＡセッションの最大数などは、図３に示すようなＥＤＣＡキューなどの非ＲＴＡキューと共に使用するために適用することもできる。
４．６．ＲＴＡキューシステムを使用するパケット送信
[00206] この節の目的は、どのようにして本開示によるＳＴＡがＲＴＡキューシステムを使用してパケットを送信するかについて説明するための複数の例を提供することである。
４．６．１．フローチャート
[00208] 図３４に、ＳＴＡが開示するＲＴＡキューシステムを使用してパケットを送信する実施形態例７９０を示す。プロセスを開始（７９２）して、ＳＴＡは、クリアチャネル評価（７９４）を実行してチャネルアクセスを獲得して、次に、どのキューから（単複の）パケットを送信すべきかを決定する（７９６）。この決定の手順は、図３１Ａ及び図３１Ｂで説明した。次に、ＳＴＡは、選択されたキューからパケットを送信する（７９８）。パケット送信が成功したかどうかを判断するためにチェック（８００）を行う。パケット送信が成功した場合、ＳＴＡは、キューからそのパケットを取り除いて（８０４）、プロセスを終了する（８１６）。複数のキューにパケットをリストすることができ、ＳＴＡはこれらのキューの全てからパケットを取り除くことに留意されたい。
[00209] 一方で、ブロック８００において、パケット送信が失敗したと判断した場合、ＳＴＡは、パケットがＲＴＡキューから選び出された（選択された）のかどうかをチェックする（８０２）。パケットがＲＴＡキューからのものである場合、ブロック８０６において、ＳＴＡは、図１９のフロー図で説明したように、このパケットをキューシステムから破棄すべきか又はこのパケットを非ＲＴＡキューに移動させるべきかどうか決定して、実行は判定ブロック８１０に進む。一方で、パケットがＲＴＡキューからのものではないと判断した場合、ブロック８０８に進んで、そのパケットの再送信の数が再試行の限界を超えるかどうかに基づいて、パケットを破棄すべきかどうかについて決定して、その後、ブロック８１０に進む。ブロック８１０において、パケットを破棄すべきかどうかを決定する。パケットを破棄すべきである場合、ブロック８１４において、パケットを破棄して、プロセスを終了する。一方で、パケットを破棄すべきではない場合、ブロック８１２において、パケット再送信をスケジュールして、その後、プロセスを終了する（８１６）。
４．６．２．ＲＴＡキューを使用するパケット送信の例
[00211] この節では、どのようにしてＳＴＡが開示するＲＴＡキューシステムを使用してパケットを送信するかについて説明するために複数の例を提供する。これらの例は、単一ユーザ送信及びマルチユーザ送信の両方のシナリオを含む。各シナリオは、特定のＲＴＡセッション、ＴＡキュー、又は非ＲＴＡキューに割り当てられるチャネル時間中のパケット送信を示す。これらの例は、図５に示したようなネットワークトポロジを考慮する。
４．６．２．１．キュー情報
[00213] 表１３に、これらの例に関連するＲＴＡセッションを記載する。表の各行は、ＲＴＡセッションを表す。例えば、第１行は、ＳＴＡ０においてパケットを生成してＳＴＡ１に送信するＲＴＡセッション１を表す。ＲＴＡセッション１によって生成されるパケットの優先度は５であり、ＴＡキュー又はＳＡキューのいずれかを通じてパケットを送信する。
[00214] 表１３のＲＴＡセッション情報に従って、以下の図に示すようなＲＴＡキューシステムにおいて、ＲＴＡパケットをキューに入れる。ＳＴＡ０におけるＲＴＡキューシステムのステータスは、図１２に示すと理解されたい。ＲＴＡセッション１、２、３、４のＲＴＡパケットは、ＲＴＡキュー内で送信を待っている。非ＲＴＡキューは空ではなく、非ＲＴＡキュー内のパケットは、非ＲＴＡトラフィックによって生成される。
[00215] 図３５～図３８に、それぞれ、ＳＴＡ１、ＳＴＡ２、ＳＴＡ３、ＳＴＡ４におけるＲＴＡキューシステムのための実施形態例８３０、８９０、９５０、及び１０１０を示す。各図に、アプリケーション層８３２、８９２、９５２、１０１２と、関連するＲＴＡトラフィック８３４、８９４、９５４及び１０１４と、非ＲＴＡトラフィック８３６、８９６、９５６及び１０１６とを示す。いくつかのキューが８３８、８９８、９５８及び１０１８として示され、具体的には、緊急アクセス（ＥＡ）キュー８４６、９０６、９６６、１０２６と、時間が割り当てられたアクセス（ＴＡ）キュー８４８、９０８、９６８、１０２８と、セッションベースのアクセス（ＳＡ）キュー８５０、９１０、９７０、１０３０とを例示する。図示の非ＲＴＡキューは、音声（ＶＯ）キュー８５２、９１２、９７２、１０３２と、ビデオ（ＶＩ）キュー８５４、９１４、９７４、１０３４と、ベストエフォート（ＢＥ）キュー８５６、９１６、９７６、１０３６と、バックグラウンド（ＢＫ）キュー８５８、９１８、９７８、１０３８とを含む。また、図に、チャネルアクセスのタイプ８４０、９００、９６０、１０２０を示し、これらは、ＲＴＡトラフィックキューのための任意のバックオフ８６０、８６２、８６４、９２０、９２２、９２４、９８０、９８２、９８４、１０４０、１０４２、１０４４、及び非ＲＴＡキューのためのＡＩＦＳ＋ＣＷバックオフ８６６、８６８、８７０、８７２、９２６、９２８、９３０、９３２、９８６、９８８、９９０、９９２、１０４６、１０４８、１０５０、１０５２である。各局に対して、内部チャネルアクセス制御機構８４２、９０２、９６２、１０２２と、チャネル自体８４４、９０４、９６４、１０２４とが示されている。
[00216] 図３５では、セッション５のパケット及びセッション６のパケットは、ＴＡキュー内に存在し、また、ＳＡキュー８５０内にも存在することが分かる。なお、セッション５のパケット及びセッション６のパケットは、２つの異なるキュー内で待つ同じパケットを表す。各キューは、それ自身のチャネルアクセス方法を使用して、独立してチャネルアクセスを獲得する。これらのキューのうちのいずれかがパケットを送信するためのチャネルアクセスを獲得した時に、そのパケットを送信することができる。パケットの送信が成功した時又はパケットが破棄された時に、両方のキューからパケットを取り除く。図３６に、セッション７のパケット及びセッション８のパケットが、それぞれ、ＥＡキュー９０６及びＴＡキュー９０８内に存在し、かつＳＡキュー９１０内に存在することを示す。図３５の場合と同様に、異なるキュー内のセッション７のパケットは同じパケットであり、セッション８のパケットについても同様である。これらのキューのうちのいずれかがパケットを送信するためのチャネルアクセスを獲得した時に、そのパケットを送信する。図３７に、セッション９のパケット及びセッション１０のパケットが、それぞれ、ＥＡキュー９６６及びＴＡキュー９６８内に存在し、かつＳＡキュー９７０内に存在することを示す。図３５の場合と同様に、異なるキュー内のセッション９のパケットは同じパケットであり、セッション１０のパケットについても同様である。これらのキューのうちのいずれかがパケットを送信するためのチャネルアクセスを獲得した時に、そのパケットを送信する。図３８に、単一のセッション１１のパケットがＳＡキュー１０３０内に存在することを示す。
４．６．２．２．単一ユーザ送信のシナリオ
[00218] 単一ユーザ送信のシナリオでは、ＳＴＡ０は、チャネルアクセスを獲得した時に、どのキューからパケットを送信するかを決定する（判断する）必要がある。この論理は、図３４で説明した。以下の例は、どのようにしてＳＴＡが、異なるキューに対するチャネル時間スケジューリングに応じて、異なるキューからパケットを送信することについてこれらの決定をするかについて示す。
[00219] 図３９に、非ＲＴＡキューに対してチャネル時間がスケジュールされた時のＳＴＡ０におけるパケット送信の実施形態例１０７０を示す。図に、送信機ＳＴＡ０（ＡＰ） １０７２と、受信機ＳＴＡ１ １０７４と、受信機ＳＴＡ２ １０７６と、受信機ＳＴＡ３ １０７８と、受信機ＳＴＡ４ １０８０とに関連するチャネル時間スケジューリング（１０８２）を示す。ＳＴＡ０は、バックオフ（１０８４）を待ち、セッション３に対してＲＴＡパケット（１０８６）を送信する。受信機ＳＴＡ１ １０７４、受信機ＳＴＡ２ １０７６、及び受信機ＳＴＡ４ １０８０は、それらのＣＣＡビジー（１０８８、１０９０、１０９２）を設定する。受信機ＳＴＡ３ １０７８は、ＲＴＡパケットを受け取った後に、確認応答（ＡＣＫ）（１０９４）を送信する。次に、ＳＴＡ０ １０７２は、別のバックオフ（１０９６）を行い、セッション４に対するＲＴＡパケット（１０９８）を送信する。受信機ＳＴＡ１ １０７４、受信機ＳＴＡ２ １０７６、及び受信機ＳＴＡ３ １０７８は、それらのＣＣＡビジー（１１００、１１０２、１１０４）を設定する。受信機ＳＴＡ３ １０７８は、ＲＴＡパケットを受け取った後に、確認応答（ＡＣＫ）（１１０６）を送信する。次に、ＳＴＡ０ １０７２は、別のバックオフ（１１０８）を実行して、セッション４に対するＲＴＡパケット（１１１０）を送信する。受信機ＳＴＡ１ １０７４、受信機ＳＴＡ３ １０７８、受信機ＳＴＡ４ １０８０は全て、ＣＣＡビジーを設定し、受信機ＳＴＡ２ １０７６は、受け取った非ＲＴＡパケットに対してＡＣＫ（１１１８）を行う。
[00220] 上記の例に関連するキューイングステータスは、図１２に既に示した。この例に示すチャネル時間中に、新たなパケットは生成されない。非ＲＴＡキューに対してチャネル時間がスケジュールされたので、ＳＴＡ０は、チャネルアクセスを獲得するためにバックオフ時間を待たなければならない。図３１Ａ及び図３１Ｂのブロック７１８、７２０及び７３４に従って、ＳＴＡ０は、まず、ＥＡキューからＲＴＡパケットを送信する。図１２に従って、セッション３及び４のＲＴＡパケットは送信されて、ＥＡキューは空になる。図３１Ａ及び図３１Ｂのブロック７２０及び７３８に従って、ＳＴＡ０は、非ＲＴＡパケットの送信を開始する。
[00221] 図４０に、ＲＴＡセッション２に対してチャネル時間がスケジュールされた時のＳＴＡ０におけるパケット送信を示す実施形態例１１３０を示す。
[00222] 図に、送信機ＳＴＡ０（ＡＰ） １１３２と、受信機ＳＴＡ１ １１３４と、受信機ＳＴＡ２ １１３６と、受信機ＳＴＡ３ １１３８と、受信機ＳＴＡ４ １１４０とに関連するセッション２に対するチャネル時間スケジューリング１１４２を示す。ＳＴＡ０は、任意のバックオフ（１１４４）を待ち、セッション３に対してＲＴＡパケット（１１４６）を送信する。受信機ＳＴＡ１ １１３４、受信機ＳＴＡ２ １１３６、及び受信機ＳＴＡ４ １１４０は、それらのＣＣＡビジー（１１４８、１１５０、１１５３）を設定する。受信機ＳＴＡ３ １１３８は、ＲＴＡパケットを受け取った後に、確認応答（ＡＣＫ）（１１５２）を送信する。次に、ＳＴＡ０ １１３２は、別の任意のバックオフ（１１５４）を実行して、セッション２に対するＲＴＡパケット（１１５６）を送信する。受信機ＳＴＡ１ １１３４、受信機ＳＴＡ３ １１３８、及び受信機ＳＴＡ４ １１４０は、それらのＣＣＡビジー（１１５８、１１６０、１１６２）を設定する。受信機ＳＴＡ２ １１３６は、パケットを受け取らないので、確認応答（ＡＣＫ）を送信しない。ＳＴＡ０ １１３２は、別の任意のバックオフ（１１６４）を含むセッション２に対する送信を再試行して、セッション２に対するＲＴＡパケット（１１６５）を送信する。受信機ＳＴＡ１ １１３４、受信機ＳＴＡ３ １１３８、受信機ＳＴＡ４ １１４０は全て、ＣＣＡビジー（１１６６、１１６８、１１７０）を設定する。この再送信を行うと、受信機ＳＴＡ２ １１３６は、パケットを受け取り、ＡＣＫ（１１７１）を行う。ＳＴＡ０ １１３２は、任意のバックオフ（１１７２）を待ち、セッション４に対してＲＴＡパケット（１１７４）を送信する。受信機ＳＴＡ１ １１３４、受信機ＳＴＡ２ １１３６、及び受信機ＳＴＡ３ １１３８は、それらのＣＣＡビジー（１１７６、１１７８、１１８０）を設定する。受信機ＳＴＡ４ １１４０は、ＲＴＡパケットを受け取った後に、確認応答（ＡＣＫ）（１１８２）を送信する。
[00223] 上記の例に関連するキューイングステータスは、図１２に示した。この例に示すチャネル時間中に、新たなパケットは生成されない。図３１Ａ及び図３１Ｂのブロック７１８、７２２及び７２６に従って、ＳＴＡ０は、セッション２のＲＴＡパケットを送信パケット候補としてみなす。一方で、図３１Ｂのブロック７２８、７３０、７３４及び７３６で説明したように、ＥＡキューの先頭のパケットが候補パケットよりも高い優先度を有する場合、ＳＴＡは、ＥＡキューからＲＴＡパケットを送信する。図４０に示すように、ＳＴＡ０は、セッション３のＲＴＡパケットを最初に送信する。次に、ＥＡキュー内のセッション４のＲＴＡパケットは、セッション２のＲＴＡパケットよりも低い優先度を有する。図３１Ｂのブロック７２８、７３０、７３４及び７４０に従って、ＳＴＡ０は、セッション２のＲＴＡパケットを送信するが、パケット送信は失敗する。ＲＴＡパケットが満了していないか又はその再送信の数が再試行の限界を超えていないので、ＳＴＡ０は、パケットを再送信する。この決定は、図３４のブロック８００、８０２、８０６、８１０及び８１２の論理に従って行われる。再送信が成功して、ＳＴＡ０は、残りのチャネル時間を使用して、セッション４のＲＴＡパケットを送信することができる。
[00224] 図４１に、バックオフ時間が必要ない時にＲＴＡセッション２に対してスケジュールされるチャネル時間中のＳＴＡ０ １１９２（ＡＰ）における単一ユーザ送信の実施形態例１１９０を示す。ＲＴＡセッション２に対してチャネル時間がスケジュールされたので、ＳＴＡ０は、チャネルアクセスを獲得するためにバックオフ時間を待つ必要がない。次に、図４０に示すパケット送信を、図４１に示すように行うことができ、図５に示したようなネットワークトポロジは、２つのＢＳＳを有する。
[00225] 図示の送信は、送信機ＳＴＡ０（ＡＰ） １１９２と、受信機ＳＴＡ１ １１９４と、受信機ＳＴＡ２ １１９６と、受信機ＳＴＡ３ １１９８と、受信機ＳＴＡ４ １２００と、ＳＴＡ５、６、７ １２０２とに関連する。送信機ＳＴＡ０ １１９２は、ＳＴＡ３ １１９８にＲＴＡパケット（１２０６）を送信し、ＳＴＡ３ １１９８は、パケットを受け取ると、それに対してＡＣＫ（１２０８）を行う。送信機ＳＴＡ０ １１９２は、ＳＴＡ２ １１９６にＲＴＡパケット（１２１０）を送信し、これに対して、パケットが受け取られなかった可能性が高いので、ＡＣＫは受け取られなかった。送信機ＳＴＡ０ １１９２は、ＳＴＡ２ １１９６にＲＴＡパケット（１２１２）を再送信し、今度は、ＳＴＡ２ １１９６は、パケットを受け取ると、それに対してＡＣＫ（１２１４）を行う。送信機ＳＴＡ０ １１９２は、ＳＴＡ４ １２００にＲＴＡパケット（１２１６）を送信し、ＳＴＡ４ １２００は、パケットを受け取ると、それに対してＡＣＫ（１２１８）を行う。この期間中に、ＳＴＡ５、６、７ １２０２は静かな状態（１２２０）のままであることが図で分かる。
[00226] ２つのＢＳＳ内の全てのノードは、ＳＴＡ０におけるチャネル時間スケジューリングを知った（チャネル時間スケジューリングに関する情報を取得することができた）時に、ＲＴＡセッション２に対してスケジュールされるチャネル時間中にパケットを送信することを回避することができることが分かった。ＳＴＡ０は、チャネルを争う他のＳＴＡが存在せず、競合衝突を回避するためのバックオフ時間が必要ないことを知る（判断した）。
[00227] セッション２のＲＴＡパケットの送信が成功した時に、ＴＡキュー及びＳＡキューからそのＲＴＡパケットを取り出す。セッション３及び４のＲＴＡパケットの送信が成功した時に、ＲＡキュー及びＳＡキューからそのＲＴＡパケットを取り出す。
[00228] 図４２に、ＴＡキューに対してチャネル時間がスケジュールされた時のＳＴＡ０におけるパケット送信の実施形態例１２３０を示す。
[00229] 図に、送信機ＳＴＡ０（ＡＰ） １２３２と、受信機ＳＴＡ１ １２３４と、受信機ＳＴＡ２ １２３６と、受信機ＳＴＡ３ １２３８と、受信機ＳＴＡ４ １２４０とに関連するＴＡキューに対するチャネル時間スケジューリング１２４２を示す。ＳＴＡ０は、任意のバックオフ（１２４４）を待ち、セッション３に対してＲＴＡパケット（１２４６）を送信する。受信機ＳＴＡ１ １２３４、受信機ＳＴＡ２ １２３６、及び受信機ＳＴＡ４ １２４０は、それらのＣＣＡビジー（１２４８、１２５０、１２５２）を設定する。受信機ＳＴＡ３ １２３８は、ＲＴＡパケットを受け取った後に、確認応答（ＡＣＫ）（１２５４）を送信する。次に、ＳＴＡ０ １２３２は、別の任意のバックオフ（１２５６）を実行して、セッション１に対するＲＴＡパケット（１２５８）を送信する。受信機ＳＴＡ２ １２３６、受信機ＳＴＡ３ １２３８、及び受信機ＳＴＡ４ １２４０は、それらのＣＣＡビジー（１２６０、１２６２、１２６４）を設定する。受信機ＳＴＡ１ １２３４は、パケットを受け取り、確認応答（ＡＣＫ）（１２６６）を送信する。ＳＴＡ０ １２３２は、別の任意のバックオフ（１２６８）を実行して、セッション２に対するＲＴＡパケット（１２７０）を送信する。受信機ＳＴＡ１ １２３４、受信機ＳＴＡ３ １２３８、及び受信機ＳＴＡ４ １２４０は全て、ＣＣＡビジー（１２７２、１２７４、１２７６）を設定する。受信機ＳＴＡ２ １２３６は、パケットを受け取り、ＡＣＫ（１２７８）を行う。ＳＴＡ０ １２３２は、任意のバックオフ（１２８０）を待ち、セッション４に対してＲＴＡパケット（１２８２）を送信する。受信機ＳＴＡ１ １２３４、受信機ＳＴＡ２ １２３６、及び受信機ＳＴＡ３ １２３８は、それらのＣＣＡビジー（１２８４、１２８６、１２８８）を設定する。受信機ＳＴＡ４ １２４０は、ＲＴＡパケットを受け取った後に、確認応答（ＡＣＫ）（１２９０）を送信する。
[00230] 上記の例に関連するキューイングステータスは、図１２に既に示した。この例に示すチャネル時間中に、新たなパケットは生成されない。図３１Ａのブロック７１８、７２２及び７２４で分かるように、ＳＴＡ０は、セッション１のＲＴＡパケットを送信パケット候補としてみなす。一方で、ＥＡキューの最初のパケットは、候補パケットよりも高い優先度を有する。図３１Ｂのブロック７２８、７３０、７３４及び７３６に示すように、ＳＴＡは、ＥＡキュー内のＲＴＡパケットを送信する。図４０に示したように、ＳＴＡ０は、セッション３のＲＴＡパケットを最初に送信する。次に、ＥＡキュー内のセッション４のＲＴＡパケットは、ＴＡキュー内のセッション１のＲＴＡパケットよりも低い優先度を有する。図３１Ｂのブロック７２８、７３０、７３４及び７４０に従って、ＳＴＡ０は、セッション１のＲＴＡパケットを送信する。次に、セッション２のＲＴＡパケットの優先度も、セッション１のＲＴＡパケットの優先度よりも高い。ＳＴＡ０は、セッション４のＲＴＡパケットを送信する前に、セッション２のＲＴＡパケットを送信する。
４．６．２．３．マルチユーザダウンリンクのシナリオ
[00232] 図４３Ａ～図４３Ｄに、受信機ノードによってパケットを分離するためのＳＴＡ０におけるＲＴＡキューサブシステムの実施形態例１３１０を示す。マルチユーザダウンリンクのシナリオでは、ＡＰは、その受信機ノードによってキュー内のパケットを分類することができる。図に、ＲＴＡキューを、緊急アクセス（ＥＡ）、時間が割り当てられたアクセス（ＴＡ）、及びセッションベースのアクセス（ＳＡ）として示し、一方、非ＲＴＡキューを、音声（ＶＯ）、ビデオ（ＶＩ）、ベストエフォート（ＢＥ）、及びバックグラウンド（ＢＫ）として示す。各受信機ＳＴＡにどのパケットを送信すべきかを決定するために、ＡＰは、図４３Ａ～図４３Ｄに示すように受信機ノードの各々に対して複数のＲＴＡキューサブシステムを作成することができる。これらの図の元のＲＴＡキューシステムは、図１２に示す。
[00233] この図では、ＳＴＡ０は、４つのＲＴＡキューサブシステム１３１２（図４３Ａ）、１３１４（図４３Ｂ）、１３１６（図４３Ｃ）及び１３１８（図４３Ｄ）を作成して、その受信機ノードによってパケットを分離する。すなわち、各ＲＴＡキューサブシステムは、同じ受信機ノードのパケットのみをリストする。キュー内の同じ受信機ノードのパケットの順序は、図４３Ａ～図４３Ｄの元のＲＴＡキューシステムのパケットの順序と比較して変わらない。各サブシステムでは、ＡＰは、図３４の論理に従うことによって、どのパケットを送信すべきかを決定することができる。次に、ＡＰは、マルチユーザ送信パケットを使用して、受信機ノードにパケットを送信する。図４３Ａにおいて、例（１３１２）は、ＳＴＡ１に送信される必要があるパケットを示し、図４３Ｂに、パケットがＳＴＡ３に送信される必要がある場合（１３１４）を示し、図４３Ｃに、パケットがＳＴＡ２に送信される必要がある場合（１３１６）を示し、図４３Ｄに、パケットがＳＴＡ４に送信される必要がある場合（１３１８）を示す。
[00234] 図４４に、ＳＴＡ０におけるマルチユーザダウンリンク送信の実施形態例１３５０を示す。各受信機ノードに対して、ＳＴＡ０は、別個に送信すべきパケットを選択する。図４３Ａ～図４３Ｄに示すような各受信機ノードに関連するキューサブシステムからパケットを選択する。送信パケットを選択する論理は、単一ユーザ送信のシナリオの場合と同じである。ＳＴＡ１及びＳＴＡ４に関連する非ＲＴＡキューと、受信機ＳＴＡ２に関連するＲＴＡセッション２と、受信機ＳＴＡ３に関連するＴＡキューとに対して、チャネル時間（１３６２）がスケジュールされる。
[00235] 図に、送信機ＳＴＡ０（ＡＰ） １３５２、受信機ＳＴＡ１ １３５４、受信機ＳＴＡ２ １３５６、受信機ＳＴＡ３ １３５８及び受信機ＳＴＡ４ １３６０の動作を示す。図に、送信ヘッダ（１３６４）及びデータ（１３６６）を示す。ＥＡキューはＳＴＡ１に送信すべきパケットを有さないので、ＳＴＡ０は、リソースユニット（ＲＵ）１を使用して、ＳＴＡ１に非ＲＴＡパケットを送信する。一方で、ＥＡキューは、ＳＴＡ４に送信すべきセッション４のＲＴＡトラフィックを有する。ＳＴＡ０は、ＲＵ４を使用して、セッション４のＲＴＡトラフィックを送信する。受信機ＳＴＡ２に関連するＲＴＡセッション２に対して、チャネル時間がスケジュールされている。次に、ＥＡキュー内にＲＴＡパケットが存在しないので、ＳＴＡ０は、ＲＵ２を使用して、ＳＡキュー内のＲＴＡセッション２のＲＴＡパケットを送信する。受信機ＳＴＡ３に関連するＴＡキューに対して、チャネル時間がスケジュールされている。ＴＡキュー内にＳＴＡ３に送信すべきＲＴＡパケットは存在しないが、ＥＡキューは空ではない。ＳＴＡ０は、ＲＵ４を使用して、ＥＡキューからセッション３のＲＴＡパケットを送信する。ＳＴＡ０に、ブロック確認応答（ＢＡ）（１３６８、１３７０、１３７２、１３７４）が返送される。
４．６．２．４．マルチユーザアップリンクのシナリオ
[00237] マルチユーザ（複数ユーザ）アップリンクのシナリオでは、例えば図３１Ａのブロック７１４、７１６に示したように、マルチユーザ送信パケットのペイロードが異なることができる。トリガフレームがＲＴＡトラフィック情報を含む場合、送信機ＳＴＡは、ＲＴＡトラフィック情報に従ってパケットを送信する。そうでない場合には、送信機ＳＴＡは、スケジュールされたチャネル時間に基づいて、どのパケットを送信すべきかを選択することができる。
[00238] 図４５に、ＲＴＡトラフィック情報を含むトリガフレーム（ＲＴＡ－ＴＦ）のためのパケットフォーマットの実施形態例１３９０を示す。少なくとも１つの実施形態では、フレームのフィールドＬ－ＳＴＦ、Ｌ－ＬＴＦ、Ｌ－ＳＩＧ、ＲＬ－ＳＩＧ、ＨＥ－ＳＩＧ－Ａ、ＨＥ－ＳＴＦ、ＨＥ－ＬＴＦ、ＰＥは、ＩＥＥＥ ８０２．１１ａｘにおける通常のＨＥ－ＴＢ ＰＰＤＵフォーマットと同じとすることができる。ＲＴＡ通知フィールドは、パケットのＭＡＣフレームを表す。フレーム制御フィールドは、フレームのタイプを示す。継続時間フィールドは、ＣＳＭＡ／ＣＡチャネルアクセスのために使用されるＮＡＶ情報を含む。ＲＡフィールドは、フレームの受信側のアドレスを含む。ＴＡフィールドは、フレームを送信したＳＴＡのアドレスを含む。以下のフィールドは、パケットの初期送信スケジュールを表す。共通情報フィールド及びユーザ情報フィールドは、ＩＥＥＥ ８０２．１１ａｘにおいて定められるトリガフレーム内のフィールドと同じとすることができる。これらの２つのフィールドは、別個のリソースブロック割り当て情報の情報を含む。ＲＴＡ制御の数は、このフィールドに続くＲＴＡ制御フィールドの数を示す。
[00239] 図４６に、以下のフィールドを有するＲＴＡ制御フィールドの実施形態例１４１０を示す。長さフィールドは、ＲＴＡ制御フィールドの長さを示す。送信元アドレスフィールドは、送信機ＳＴＡのアドレスを示す。送信先アドレスフィールドは、受信機ＳＴＡのアドレスを示すが、少なくとも１つの実施形態では、受信機ＳＴＡのアドレス、ＡＩＤ、又は他のタイプの識別情報とすることもできる。パケットＩＤフィールドは、パケットの識別を示す。同じパケットＩＤを有するパケットは、パケットにおいて同じＲＴＡトラフィックを搬送する。通知要求フィールドは、送信機ＳＴＡによって通知が要求されたかどうかを示し、この例では、１ビットの指示フィールドとして示される。このビットが第１の状態（例えば「１」）に設定された時には、パケット送信が終了した後に通知が要求されて、受信機ＳＴＡは、送信機ＳＴＡに通知を返送して、パケット送信が正しいことを報告する。そうでなければ、このビットは第２の状態（例えば「０」）に設定される。更なる再送信フィールドは、この送信の後に別の再送信がスケジュールされたかどうかを示す。このビットを第１の状態（例えば「１」）に設定することは、再送信がないことを示す。そうでなければ、このビットは第２の状態（例えば「０」）に設定される。トラフィックタイプフィールドは、トラフィックのタイプがＲＴＡトラフィック、非ＲＴＡトラフィック又は他のタイプのトラフィックであることができることを示す。ＲＴＡセッションＩＤフィールドは、ＲＴＡセッションの識別情報を提供し、この場合、表１に記載するような情報を使用することができる。図７に、一例を挙げた。優先度フィールドは、ＲＴＡトラフィックの優先度を示す。帯域幅要件フィールドは、ＲＴＡ送信に必要な帯域幅を示す。パケット寿命フィールドは、このパケットの満了時間までの寿命を示す。周期時間フィールドは、ＲＴＡトラフィック生成パケットの周期時間を示す。ＨＡＲＱタイプフィールドは、使用されるハイブリッドＡＲＱ（ＨＡＲＱ）タイプの指示であるが、このフィールドを所与の値に設定することによって、ＨＡＲＱを無効にすることもできる。
[00240] 図４７に、以下のフィールドを有するＲＴＡ再送信スケジュールフィールドの実施形態例１４３０を示す。再送信の数フィールドは、このフィールドに含まれる再送信スケジュールの数を示す。再送信スケジュールフィールドは、時間毎に再送信スケジュールを示す。再送信スケジュール内の長さは、スケジュールフィールドの長さを示す。少なくとも１つの実施形態では、共通情報フィールド及びユーザ情報フィールドは、それぞれ、ＩＥＥＥ ８０２．１１ａｘにおいて定められるトリガフレーム内のフィールドと同じとすることができる。ＲＴＡ制御の数フィールドは、このフィールドに続くＲＴＡ制御フィールドの数を示す。ＲＴＡ制御フィールドは、図４６に示した。
[00241] 図４８に、ＡＰ（ＳＴＡ０）がＲＴＡ－ＴＦ（１４６４）を送信して送信を開始する時のマルチユーザアップリンク送信を示す実施形態例１４５０を示す。図に、送信機ＳＴＡ０（ＡＰ） １４５２と、受信機ＳＴＡ１ １４５４と、受信機ＳＴＡ２ １４５６と、受信機ＳＴＡ３ １４５８と、受信機ＳＴＡ４ １４６０とに関連するこのＲＴＡ－ＴＦの受け取りに応答するトラフィックを示す。ＲＴＡ－ＴＦ（１４６２）にトラフィック情報が埋め込まれ、図示の情報は、ＳＴＡ１はＲＵ１を使用して非ＲＴＡトラフィックを送信し、ＳＴＡ２はＲＵ２を使用してＲＴＡセッション７のＲＴＡトラフィックを送信し、ＳＴＡ３はＲＵ３を使用してＲＴＡセッション９のＲＴＡトラフィックを送信し、ＳＴＡ４はＲＵ４を使用して非ＲＴＡトラフィックを送信することを示す。
[00242] ＲＴＡ－ＴＦ（１４６２）に埋め込まれるトラフィック情報に従って、送信機ＳＴＡは、どのパケットを送信すべきかを知る（決定する）ことができる。この例に示すように、ＳＴＡ１は、そのＲＴＡ制御フィールドを復号して、トラフィックタイプが非ＲＴＡトラフィックに設定されていることが分かり、マルチユーザアップリンク送信でヘッダ（１４６６）及び非ＲＴＡトラフィック（１４６８）を送信する。これは、図３１Ａ及び図３１Ｂのブロック７１４、７１６、７３２で既に説明した。図４８に戻ると、ＳＴＡ２がそのＲＴＡ制御フィールドを復号して、トラフィックタイプが、ＲＴＡセッションＩＤフィールドがセッション７に設定されたＲＴＡトラフィックである時に、ＳＴＡ２は、マルチユーザアップリンク送信でヘッダ（１４７０）及びセッション７のＲＴＡトラフィック（１４７２）を送信する。同様に、ＳＴＡ３及びＳＴＡ４は、それぞれ、ＲＴＡ－ＴＦ内のトラフィック情報に従って、それらのヘッダ（１４７４、１４７８）及びセッション９のＲＴＡパケット（１４７６）及び非ＲＴＡパケット（１４８０）を送信する。その後に、ＳＴＡ０ １４５２は、ブロック確認応答（ＢＡ）（１４８２）を送信する。
[00243] 図３１Ａのブロック７１４、７１６に従って、ＡＰがトラフィック情報を含まない通常のＴＦを送信した時に、送信機ＳＴＡは、スケジュールされたチャネル時間に従って、どのパケットを送信すべきかを決定することができる。図４８に示すようにパケットを選択する論理は、図３１Ａ及び図３１Ｂに示す単一ユーザ送信のシナリオで示したものと同じである。
[00244] 図４９に、通常のトリガフレーム（ＴＦ）（１５０４）によって開始されるマルチユーザアップリンクの実施形態例１４９０を示す。ＳＴＡ１に関連する非ＲＴＡキューと、ＳＴＡ２及びＳＴＡ４に関連するＲＴＡセッション８及びＲＴＡセッション１１と、ＳＴＡ３に関連するＴＡキューとに対して、チャネル時間がスケジュール（１５０２）される。図に、ＳＴＡ０（ＡＰ） １４９２と、送信機ＳＴＡ１ １４９４と、送信機ＳＴＡ２ １４９６と、送信機ＳＴＡ３ １４９８と、送信機ＳＴＡ４ １５００との間の相互作用を示す。
[00245] ＳＴＡ１、ＳＴＡ２、ＳＴＡ３及びＳＴＡ４は、ＡＰ（ＳＴＡ０）から通常のＴＦ（１５０４）を受け取った時に、自機側のスケジュールされたチャネル時間に従って、どのパケットを送信すべきかを決定する（判断する）ことができる。ＳＴＡ１において、非ＲＴＡキューに対してチャネル時間がスケジュールされている。ＳＴＡ１のＥＡキューは空であるので、ＳＴＡ１は、マルチユーザ送信でヘッダ（１５０６）及び非ＲＴＡトラフィック（１５０８）を送信する。ＳＴＡ２及びＳＴＡ４において、それぞれ、ＲＴＡセッション８及びＲＴＡセッション１１に対してチャネル時間がスケジュールされている。ＥＡキュー内のＲＴＡセッション７のＲＴＡパケットの優先度は、ＲＴＡセッション８のＲＴＡパケットよりも高いので、ＳＴＡ２は、ヘッダ（１５１０）及びＥＡキュー内のＲＴＡセッション７のＲＴＡパケット（１５１２）を最初に送信する。ＳＴＡ４のＥＡキュー内に他のＲＴＡパケットが存在しないので、ＳＴＡ４は、ヘッダ（１５１４）及びＲＴＡセッション１１のＲＴＡパケット（１５１６）を送信する。ＳＴＡ３において、ＴＡキューに対してチャネル時間がスケジュールされている。ＴＡキュー内のＲＴＡセッション１０のＲＴＡパケットの優先度は、ＥＡキュー内のＲＴＡセッション９のＲＴＡパケットよりも高いので、ＳＴＡ３は、ヘッダ（１５１８）及びＲＴＡセッション１０のＲＴＡパケット（１５２０）を最初に送信する。ＳＴＡ０ １４９２は、ブロック確認応答（１５２２）で応答する。
５．実施形態の一般的範囲
[00247] 提示した技術の説明した強化は、様々な無線ネットワーキング局内に容易に実装することができる。また、無線ネットワーキング局は、１又は２以上のコンピュータプロセッサ装置（例えば、ＣＰＵ、マイクロプロセッサ、マイクロコントローラ、コンピュータ対応ＡＳＩＣなど）、及び命令を記憶する関連するメモリ（例えば、ＲＡＭ、ＤＲＡＭ、ＮＶＲＡＭ、ＦＬＡＳＨ、コンピュータ可読媒体など）を含むように実装されることにより、メモリに記憶されたプログラム（命令）がプロセッサ上で実行されて、本明細書で説明した様々なプロセス法のステップを実行することが好ましいと理解されたい。
[00248] 当業者は、無線ネットワーキングに関連するステップを実行するコンピュータ装置の使用を認識しているため、各図には簡略化のためにコンピュータ装置及びメモリデバイスを示していない。提示した技術は、メモリ及びコンピュータ可読媒体が非一時的であり、したがって一時的電子信号を構成しない限り、これらに関して限定するものではない。
[00249] 本明細書では、コンピュータプログラム製品としても実装できる、本技術の実施形態による方法及びシステム、及び／又は手順、アルゴリズム、ステップ、演算、数式又はその他の計算表現のフロー図を参照して本技術の実施形態を説明することができる。この点、フローチャートの各ブロック又はステップ、及びフローチャートのブロック（及び／又はステップ）の組み合わせ、並びにあらゆる手順、アルゴリズム、ステップ、演算、数式、又は計算表現は、ハードウェア、ファームウェア、及び／又はコンピュータ可読プログラムコードの形で具体化された１又は２以上のコンピュータプログラム命令を含むソフトウェアなどの様々な手段によって実装することができる。理解されるように、このようなあらゆるコンピュータプログラム命令は、以下に限定されるわけではないが、汎用コンピュータ又は専用コンピュータ、又は機械を生産するための他のプログラマブル処理装置を含む１又は２以上のコンピュータプロセッサによって実行して、（単複の）コンピュータプロセッサ又は他のプログラマブル処理装置上で実行されるコンピュータプログラム命令が、（単複の）特定される機能を実施するための手段を生み出すようにすることができる。
[00250] したがって、本明細書で説明したフローチャートのブロック、並びに手順、アルゴリズム、ステップ、演算、数式、又は計算表現は、（単複の）特定の機能を実行する手段の組み合わせ、（単複の）特定の機能を実行するステップの組み合わせ、及びコンピュータ可読プログラムコード論理手段の形で具体化されるような、（単複の）特定の機能を実行するコンピュータプログラム命令をサポートする。また、本明細書で説明したフロー図の各ブロック、並びに手順、アルゴリズム、ステップ、演算、数式、又は計算表現、及びこれらの組み合わせは、（単複の）特定の機能又はステップを実行する専用ハードウェアベースのコンピュータシステム、又は専用ハードウェアとコンピュータ可読プログラムコードとの組み合わせによって実装することもできると理解されるであろう。
[00251] 更に、コンピュータ可読プログラムコードなどの形で具体化されるこれらのコンピュータプログラム命令を、コンピュータプロセッサ又は他のプログラマブル処理装置に特定の態様で機能するように指示することができる１又は２以上のコンピュータ可読メモリ又はメモリデバイスに記憶して、これらのコンピュータ可読メモリ又はメモリデバイスに記憶された命令が、（単複の）フローチャートの（単複の）ブロック内に指定される機能を実施する命令手段を含む製造の物品を生産するようにすることもできる。コンピュータプログラム命令をコンピュータプロセッサ又は他のプログラマブル処理装置によって実行し、コンピュータプロセッサ又は他のプログラマブル処理装置上で一連の動作ステップが実行されるようにしてコンピュータで実施される処理を生成し、コンピュータプロセッサ又は他のプログラマブル処理装置上で実行される命令が、（単複の）フローチャートの（単複の）ブロック、（単複の）手順、（単複の）アルゴリズム、（単複の）ステップ、（単複の）演算、（単複の）数式、又は（単複の）計算表現に特定される機能を実施するためのステップを提供するようにすることもできる。
[00252] 更に、本明細書で使用する「プログラム」又は「プログラム実行文」という用語は、本明細書で説明した１又は２以上の機能を実行するために１又は２以上のコンピュータプロセッサが実行できる１又は２以上の命令を意味すると理解されるであろう。命令は、ソフトウェア、ファームウェア、又はソフトウェアとファームウェアとの組み合わせで具体化することができる。命令は、装置の非一時的媒体に局所的に記憶することも、又はサーバなどに遠隔的に記憶することもでき、或いは命令の全部又は一部を局所的に又は遠隔的に記憶することもできる。遠隔的に記憶された命令は、ユーザが開始することによって、或いは１又は２以上の要因に基づいて自動的に装置にダウンロード（プッシュ）することができる。
[00253] 更に、本明細書で使用するプロセッサ、ハードウェアプロセッサ、コンピュータプロセッサ、中央処理装置（ＣＰＵ）及びコンピュータという用語は、命令、並びに入力／出力インターフェイス及び／又は周辺装置との通信を実行できる装置を示すために同義的に使用されるものであり、プロセッサ、ハードウェアプロセッサ、コンピュータプロセッサ、ＣＰＵ及びコンピュータという用語は、単一の又は複数の装置、シングルコア装置及びマルチコア装置、及びこれらの変種を含むように意図するものであると理解されるであろう。
[00254] 本明細書の説明から、本開示は、限定ではないが以下の内容を含む複数の実施形態を含むことができると理解されるであろう。
[00255] １．ネットワーク内の無線通信のための装置であって、前記装置は、（ａ）少なくとも１つのチャネルを通じて、自機の受信エリア内のローカルエリアネットワーク（ＷＬＡＮ）上の少なくとも１つの他の無線局と無線通信するように構成される無線通信回線と、（ｂ）前記ＷＬＡＮ上で動作するように構成される局内の前記無線通信回線に結合されるプロセッサと、（ｃ）前記プロセッサによって実行可能な命令を記憶する非一時的メモリと、を備え、（ｄ）前記命令は、前記プロセッサによって実行された時に、（ｄ）（ｉ）リアルタイムアプリケーション（ＲＴＡ）トラフィック及び非ＲＴＡトラフィックが共存する、キャリア検知多重アクセス／衝突回避（ＣＳＭＡ／ＣＡ）をサポートするネットワークを通じて、通信遅延に対して敏感であるリアルタイムアプリケーション（ＲＴＡ）パケット及び非リアルタイムパケットの通信をサポートするように構成される無線ローカルエリアネットワーク（ＷＬＡＮ）局として、前記無線通信回線を動作させるステップと、（ｄ）（ｉｉ）リアルタイムアプリケーション（ＲＴＡ）パケットと非リアルタイムアプリケーション（非ＲＴＡ）パケットとを区別するステップと、（ｄ）（ｉｉｉ）ＲＴＡパケットをキューに入れるためにＲＴＡキューを作成する一方で、非ＲＴＡパケットを非ＲＴＡキューにプッシュするステップと、（ｄ）（ｉｖ）ＲＴＡセッションパラメータとＲＴＡキュー設定情報とを含む管理フレームを交換するステップと、（ｄ）（ｖ）パケットを送信するための前記ＲＴＡキューにチャネル時間を割り当てて、前記チャネル時間中に、非ＲＴＡキューが前記チャネルにアクセスすることを許可しないステップと、（ｄ）（ｖｉ）ＲＴＡセッションのＲＴＡキュー分類情報に基づいて、ＲＴＡパケットをどのＲＴＡキューに入れるべきかを決定するステップと、を含む１又は２以上のステップを実行する、装置。
[00256] ２．ネットワーク内の無線通信のための装置であって、前記装置は、（ａ）少なくとも１つのチャネルを通じて、自機の受信エリア内のローカルエリアネットワーク（ＷＬＡＮ）上の少なくとも１つの他の無線局と無線通信するように構成される無線通信回線と、（ｂ）前記ＷＬＡＮ上で動作するように構成される局内の前記無線通信回線に結合されるプロセッサと、（ｃ）前記プロセッサによって実行可能な命令を記憶する非一時的メモリと、を備え、（ｄ）前記命令は、前記プロセッサによって実行された時に、（ｄ）（ｉ）リアルタイムアプリケーション（ＲＴＡ）トラフィック及び非ＲＴＡトラフィックが共存する、キャリア検知多重アクセス／衝突回避（ＣＳＭＡ／ＣＡ）をサポートするネットワークを通じて、通信遅延に対して敏感であるリアルタイムアプリケーション（ＲＴＡ）パケット及び非リアルタイムパケットの通信をサポートするように構成される無線ローカルエリアネットワーク（ＷＬＡＮ）局として、前記無線通信回線を動作させるステップと、（ｄ）（ｉｉ）リアルタイムアプリケーション（ＲＴＡ）パケットと非リアルタイムアプリケーション（非ＲＴＡ）パケットとを区別するステップであって、前記局が、事前ネゴシエーション又はパケットヘッダ情報に基づく情報を利用することによって、前記ＲＴＡトラフィックと前記非ＲＴＡトラフィックとを区別するステップと、（ｄ）（ｉｉｉ）ＲＴＡパケットをキューに入れるためにＲＴＡキューを作成する一方で、非ＲＴＡパケットを非ＲＴＡキューにプッシュするステップと、（ｄ）（ｉｖ）ＲＴＡセッションパラメータとＲＴＡキュー設定情報とを含む管理フレームを交換するステップと、（ｄ）（ｖ）パケットを送信するための前記ＲＴＡキューにチャネル時間を割り当てて、前記チャネル時間中に、非ＲＴＡキューが前記チャネルにアクセスすることを許可しないステップと、（ｄ）（ｖｉ）ＲＴＡセッションのＲＴＡキュー分類情報に基づいて、ＲＴＡパケットをどのＲＴＡキューに入れるべきかを決定するステップと、（ｄ）（ｖｉｉ）前記局が、ＲＴＡパケットの満了時間を設定し、満了したＲＴＡパケットが入れられた全てのＲＴＡキューから、前記満了したＲＴＡパケットを取り出すステップと、を含む１又は２以上のステップを実行する、装置。
[00257] ３．ネットワーク内の無線通信を実行する方法であって、（ａ）リアルタイムアプリケーション（ＲＴＡ）トラフィック及び非ＲＴＡトラフィックが共存する、キャリア検知多重アクセス／衝突回避（ＣＳＭＡ／ＣＡ）をサポートするネットワークを通じて、通信遅延に対して敏感であるリアルタイムアプリケーション（ＲＴＡ）パケット及び非リアルタイムパケットの通信をサポートするように構成される無線ローカルエリアネットワーク（ＷＬＡＮ）局として、無線通信回線を動作させるステップと、（ｂ）リアルタイムアプリケーション（ＲＴＡ）パケットと非リアルタイムアプリケーション（非ＲＴＡ）パケットとを区別するステップと、（ｃ）ＲＴＡパケットをキューに入れるためにＲＴＡキューを作成する一方で、非ＲＴＡパケットを非ＲＴＡキューにプッシュするステップと、（ｄ）ＲＴＡセッションパラメータとＲＴＡキュー設定情報とを含む管理フレームを交換するステップと、（ｅ）パケットを送信するための前記ＲＴＡキューにチャネル時間を割り当てて、前記チャネル時間中に、非ＲＴＡキューが前記チャネルにアクセスすることを許可しないステップと、（ｆ）ＲＴＡセッションのＲＴＡキュー分類情報に基づいて、ＲＴＡパケットをどのＲＴＡキューに入れるべきかを決定するステップと、を含む方法。
[00258] ４．ＣＳＭＡ／ＣＡが適用されて、リアルタイムアプリケーション（ＲＴＡ）トラフィック及び非ＲＴＡトラフィックがシステム／装置内に共存する、パケットの送信を実行する無線通信システム／装置であって、以下の動作を実行する。（ａ）ＳＴＡは、ＲＴＡトラフィックと非ＲＴＡトラフィックとを区別する。（ｂ）ＳＴＡは、ＲＴＡパケットをキューに入れるためにＲＴＡキューを作成する一方で、非ＲＴＡパケットを、ＥＤＣＡキューなどの非ＲＴＡキューにプッシュする。（ｃ）ＳＴＡは、ＲＴＡセッションパラメータとＲＴＡキュー設定情報とを含む管理フレームを交換する。（ｄ）ＳＴＡは、送信するためのＲＴＡキューにチャネル時間を割り当てて、チャネル時間中に、非ＲＴＡキューがチャネルにアクセスすることを許可しない。（ｅ）ＳＴＡは、ＲＴＡセッションのＲＴＡキュー分類情報に基づいて、ＲＴＡパケットをどのＲＴＡキューに入れるべきかを決定する。（ｆ）ＳＴＡは、ＲＴＡパケットの満了時間を設定し、満了したＲＴＡパケットが入れられた全てのＲＴＡキューから、満了したＲＴＡパケットを取り出す。
[00259] ５．前記命令は、前記プロセッサによって実行された時に、前記局がＲＴＡパケットの満了時間を設定し、満了したＲＴＡパケットが入れられた全てのＲＴＡキューから、前記満了したＲＴＡパケットを取り出す１又は２以上のステップを更に実行する、前出のいずれかの実施形態の装置又は方法。
[00260] ６．前記命令は、前記プロセッサによって実行された時に、前記局が、事前ネゴシエーション又はパケットヘッダ情報に基づく情報を利用することによって、前記ＲＴＡトラフィックと前記非ＲＴＡトラフィックとを区別する１又は２以上のステップを更に実行する、前出のいずれかの実施形態の装置又は方法。
[00261] ７．前記命令は、前記プロセッサによって実行された時に、ＲＴＡキューを作成する前記局が、そのキューが他のキューに割り当てられるチャネル時間を使用して前記チャネルにアクセスできるようにするように構成される１又は２以上のステップを更に実行する、前出のいずれかの実施形態の装置又は方法。
[00262] ８．前記命令は、前記プロセッサによって実行された時に、ＲＴＡキューを作成する前記局が、各パケットの満了時間及び優先度に基づいて各パケットの重要度指標を計算することによって、前記キュー内の前記ＲＴＡパケットをソートするように構成される１又は２以上のステップを更に実行する、前出のいずれかの実施形態の装置又は方法。
[00263] ９．前記命令は、前記プロセッサによって実行された時に、ＲＴＡキューを作成する前記局が、前記キュー内のパケットの順序を考慮することなく、ＲＴＡセッション情報に基づいて、前記キュー内の前記ＲＴＡパケットを送信するように構成される１又は２以上のステップを更に実行する、前出のいずれかの実施形態の装置又は方法。
[00264] １０．前記命令は、前記プロセッサによって実行された時に、ＲＴＡキューを作成する前記局が、そのキューに割り当てられるチャネルリソースを制限するように構成される１又は２以上のステップを更に実行する、前出のいずれかの実施形態の装置又は方法。
[00265] １１．前記命令は、前記プロセッサによって実行された時に、ＲＴＡセッションパラメータと、ＲＴＡキュー分類、ＲＴＡパケット満了時間、及び前記局と前記ネットワーク上の他の局との間の前記ＲＴＡセッションの満了したＲＴＡパケットを処理する方法の設定とを含む管理フレームを交換するステップを含む１又は２以上のステップを更に実行する、前出のいずれかの実施形態の装置又は方法。
[00266] １２．前記命令は、前記プロセッサによって実行された時に、前記局及び前記ネットワーク上の他の局が、ＲＴＡキュー設定情報と、各キューのＲＴＡキューイング規則、ＲＴＡキューチャネル時間割り当て、及びＲＴＡキューチャネルリソース制限の設定とを含む管理フレームを交換する１又は２以上のステップを更に実行する、前出のいずれかの実施形態の装置又は方法。
[00267] １３．前記命令は、前記プロセッサによって実行された時に、ＲＴＡパケットをどのＲＴＡキューに入れるべきかを決定する前記局が、前記決定を行う際に、事前ネゴシエーションによって交換される前記ＲＴＡセッションのキュー情報を利用するように構成される１又は２以上のステップを更に実行する、前出のいずれかの実施形態の装置又は方法。
[00268] １４．前記命令は、前記プロセッサによって実行された時に、ＲＴＡパケットをキューに入れる前記局が、レイテンシ要件に基づいて、このパケットを複数のＲＴＡキューにプッシュするように構成される１又は２以上のステップを更に実行する、前出のいずれかの実施形態の装置又は方法。
[00269] １５．前記命令は、前記プロセッサによって実行された時に、ＲＴＡパケットをキューに入れる前記局が、１つのキューを通じてそのパケットの送信が成功した時に、全てのキューからそのＲＴＡパケットを取り出すように構成される１又は２以上のステップを更に実行する、前出のいずれかの実施形態の装置又は方法。
[00270] １６．前記命令は、前記プロセッサによって実行された時に、ＲＴＡパケットの満了時間を設定する前記局が、その満了時間に達すると、前記パケットを破棄すること又は前記パケットを非ＲＴＡキューに移動させることのいずれかを決定するように構成される１又は２以上のステップを更に実行する、前出のいずれかの実施形態の装置又は方法。
[00271] 本明細書で使用する単数語「ａ」、「ａｎ」、及び「ｔｈｅ」は、文脈によって別途明確に指定しない限り、複数の参照物を含むことができる。単数形による物への言及は、明述しない限り「唯一」を意味するものではなく、「１又は２以上」を意味するものである。
[00272] 本開示内の「Ａ、Ｂ及び／又はＣ」などの語句の構成体は、Ａ、Ｂ、又はＣのいずれかが存在することができる場合、又は項目Ａ、Ｂ及びＣの任意の組み合わせを説明する。「のうちの少なくとも１つ」の後に要素を列挙したグループが続くような語句の構成体は、これらのグループ要素のうちの少なくとも１つが存在し、適用可能な場合、これらの列挙された要素の任意の可能な組み合わせを含むことを示す。
[00273] 本明細書中の「ある実施形態」、「少なくとも１つの実施形態」又は同様の実施形態の用語への言及は、説明された実施形態に関連して説明する特定の特徴、構造又は特性が、本開示の少なくとも１つの実施形態に含まれることを示す。したがって、これらの様々な実施形態の語句は、必ずしも全てが同じ実施形態、又は説明されている他の全ての実施形態と異なる特定の実施形態について言及するものではない。実施形態の語句は、所与の実施形態の特定の特徴、構造又は特性を、開示する装置、システム又は方法の１又は２以上の実施形態にあらゆる好適な態様で組み合わせることができることを意味すると解釈すべきである。
[00274] 本明細書で使用する「組（ｓｅｔ）」という用語は、１又は２以上の物体の集合を意味する。したがって、例えば物体の組は、単一の物体又は複数の物体を含むことができる。
[00275] 本明細書で使用する「実質的に（ｓｕｂｓｔａｎｔｉａｌｌｙ）」及び「約（ａｂｏｕｔ）」という用語は、わずかな変動の記述及び説明のために使用するものである。これらの用語は、事象又は状況に関連して使用した時には、これらの事象又は状況が間違いなく発生する場合、及びこれらの事象又は状況が発生する可能性が非常に高い場合を意味することができる。これらの用語は、数値に関連して使用した時には、その数値の±５％以下、±４％以下、±３％以下、±２％以下、±１％以下、±０．５％以下、±０．１％以下、又は±０．０５％以下などの、±１０％以下の変動範囲を意味することができる。例えば、「実質的に」整列しているということは、±５°以下、±４°以下、±３°以下、±２°以下、±１°以下、±０．５°以下、±０．１°以下、又は±０．０５°以下などの、±１０％以下の角度変動範囲を意味することができる。
[00276] また、本明細書では、量、比率及びその他の数値を範囲形式で示すこともある。このような範囲形式は、便宜的に簡略化して使用するものであり、範囲の限界として明確に指定された数値を含むが、この範囲に含まれる全ての個々の数値又は部分的範囲も、これらの各数値及び部分的範囲が明確に示されているかのように含むものであると柔軟に理解されたい。例えば、約１～約２００の範囲内の比率は、約１及び約２００という明確に列挙した限界値を含むが、約２、約３、約４などの個々の比率、及び約１０～約５０、約２０～約１００などの部分的範囲も含むと理解されたい。
[00277] 本明細書の説明は多くの詳細を含んでいるが、これらは本開示の範囲を限定するものではなく、現在のところ好ましい実施形態の一部を例示するものにすぎないと解釈すべきである。したがって、本開示の範囲は、当業者に明らかになると考えられる他の実施形態も完全に含むと理解されるであろう。
[00278] 当業者に周知の本開示の実施形態の要素の全ての構造的及び機能的同等物も、引用によって本明細書に明確に組み入れられ、本特許請求の範囲に含まれるように意図される。更に、本開示の要素、構成要素又は方法ステップは、これらが特許請求の範囲に明示されているかどうかにかかわらず、一般に公開されるように意図するものではない。本明細書における請求項の要素については、その要素が「～のための手段」という表現を使用して明確に示されていない限り、「ミーンズプラスファンクション」の要素として解釈すべきではない。また、本明細書における請求項の要素については、その要素が「～のためのステップ」という表現を使用して明確に示されていない限り、「ステッププラスファンクション」の要素として解釈すべきではない。
送信機側でＲＴＡトラフィックを識別するためのヘッダ情報
Figure 0007334847000001
ＲＴＡセッションステータスのリスト
Figure 0007334847000002
ＲＴＡセッション開始要求メッセージフォーマット
Figure 0007334847000003
ＲＴＡセッション開始指示メッセージフォーマット
Figure 0007334847000004
ＲＴＡセッション開始応答メッセージフォーマット
Figure 0007334847000005
ＲＴＡセッション開始確認メッセージフォーマット
Figure 0007334847000006
ＲＴＡキューソート設定要求メッセージフォーマット
Figure 0007334847000007
ＲＴＡキューソート設定指示メッセージフォーマット
Figure 0007334847000008
ＲＴＡキュー時間割り当て要求メッセージフォーマット
Figure 0007334847000009
ＲＴＡキュー時間割り当て指示メッセージフォーマット
Figure 0007334847000010
ＲＴＡＱＵＥＵＥＰＡＲＡＳＥＴ．ｒｅｑｕｅｓｔメッセージフォーマット
Figure 0007334847000011
ＲＴＡＱＵＥＵＥＰＡＲＡＳＥＴ．ｉｎｄｉｃａｔｉｏｎメッセージフォーマット
Figure 0007334847000012
ＲＴＡセッション情報
Figure 0007334847000013
１０ 実施形態例
１２ Ｉ／Ｏ経路
１３ ハードウェア
１４ バス
１６ プロセッサ
１８ メモリ
２０ ミリメートル波（ｍｍＷ）モデム
２２ａ，２２ｂ，２２ｃ 無線周波数（ＲＦ）回路
２４ａ～２４ｎ，２５ａ～２５ｎ，２６ａ～２６ｎ アンテナ
２７ ｓｕｂ－６ＧＨｚモデム
２８ 無線周波数（ＲＦ）回路
２９ アンテナ
５０ ネットワークトポロジ例（シナリオ）
５２ ＳＴＡ０
５４ ＳＴＡ１
５６ ＳＴＡ２
５８ ＳＴＡ３
６０ ＳＴＡ４
６２ ＳＴＡ５
６４ ＳＴＡ６
６６ ＳＴＡ７
６８ エリア
７０ 実施形態例
７２ ＳＴＡ１
７４ ＳＴＡ２
７６ａ ＡＰＰ層
７６ｂ 中間の層
７６ｃ ＭＡＣ層
７６ｄ ＰＨＹ層
７８ａ ＡＰＰ層
７８ｂ 中間の層
７８ｃ ＭＡＣ層
７８ｄ ＰＨＹ層
８０ ＲＴＡトラフィック及び非ＲＴＡトラフィック
８２ ＲＴＡトラフィック及び非ＲＴＡトラフィック
８４ ＲＴＡパケット
８６ 非ＲＴＡパケット
９０ 実施形態例
９２ 送信機ＳＴＡ
９４ 受信機ＳＴＡ
９６ａ ＡＰＰ層
９６ｂ 中間の層
９６ｃ ＭＡＣ層
９６ｄ ＰＨＹ層
９８ａ ＡＰＰ層
９８ｂ 中間の層
９８ｃ ＭＡＣ層
９８ｄ ＰＨＹ層
１００ ＲＴＡトラフィックパケット
１０２ ＲＴＡトラフィックパケット
１０４ リソースネゴシエーションを要求
１０６ リソースの利用可能性をチェック
１０８ ネゴシエーション要求フレームを送信
１１０ ＡＰＰ層にＲＴＡパケットの受信の準備をするように通知
１１２ 管理エンティティから、管理エンティティに情報を送信
１１４ リソースの利用可能性をチェック
１１６ 全てのネゴシエーション情報を報告
１１８ ネゴシエーション結果を転送
１３０ 実施形態例
１３２ 送信機側でＲＴＡトラフィックを識別
１３４ ＭＡＣ層が上位層からトラフィックを受け取る
１３６ ＲＴＡトラフィックを識別するために上位層によって埋め込まれる情報を抽出
１３８ 事前ネゴシエーションによって作成されるＲＴＡセッションレコードを探索
１４０ 既存のＲＴＡセッションが見つかったか？
１４２ トラフィックは非ＲＴＡである
１４４ トラフィックはＲＴＡである
１４６ 終了
１５０ 実施形態例
１７０ 実施形態例
１７２ 送信機ＳＴＡ
１７４ 受信機ＳＴＡ
１７６ａ ＡＰＰ層
１７６ｂ 中間の層
１７６ｃ ＭＡＣ層
１７６ｄ ＰＨＹ層
１７８ａ ＡＰＰ層
１７８ｂ 中間の層
１７８ｃ ＭＡＣ層
１７８ｄ ＰＨＹ層
１８０ ヘッダ情報交換／ＲＴＡパケット
１８２ ヘッダ情報交換／パケット
１８４ ＲＴＡトラフィックを生成
１８６ トラフィックがＲＴＡであると識別
１８８ ＲＴＡパケットを送信
１８９ ＲＴＡパケットを識別
１９０ 実施形態例
１９２ 受信機側でＲＴＡパケットを識別
１９４ ＰＨＹ層でパケットを受け取る
１９６ ＲＴＡ識別情報が存在するか？
１９８ パケットは非ＲＴＡである
２００ パケットはＲＴＡである
２０２ 終了
２１０ 実施形態例
２１２ ＡＰＰ層
２１４ ＲＴＡトラフィック
２１６ 非ＲＴＡトラフィック
２１８ 複数のキュー
２２０ チャネルアクセスバックオフ
２２２ 内部チャネルアクセス制御機構
２２４ チャネル
２２６ 緊急チャネルアクセス（ＥＡ）キュー
２２８ バックオフ（任意）
２３０ 時間が割り当てられたチャネルアクセス（ＴＡ）キュー
２３２ バックオフ（任意）
２３４ セッションベースのチャネルアクセス（ＳＡ）キュー
２３６ バックオフ（任意）
２３８ 音声（ＶＯ）キュー
２４０ バックオフ（ＡＩＦＳ＋ＣＷ）
２４２ ビデオ（ＶＩ）キュー
２４４ バックオフ（ＡＩＦＳ＋ＣＷ）
２４６ ベストエフォート（ＢＥ）キュー
２４８ バックオフ（ＡＩＦＳ＋ＣＷ）
２５０ バックグラウンド（ＢＫ）キュー
２５２ バックオフ（ＡＩＦＳ＋ＣＷ）
２６０ 実施形態例
２６５ 識別情報
２７０ ステータス情報
２７５ 要件情報
２８０ 送信情報
２８５ キュー情報
２９０ 実施形態例
３１０ 実施形態例
３２０ 実施形態例
３３０ 実施形態例
３５０ 実施形態例
３５２ ＲＴＡユーザ
３５４ 上位層
３５５ａ ＲＴＡトラフィックを識別
３５５ｂ 非ＲＴＡトラフィックを識別
３５６ ＭＡＣ層
３５８ ＲＴＡトラフィック識別情報を設定／取得
３６０ ＲＴＡトラフィック識別情報を設定して、ＲＴＡトラフィックを識別
３６２ ＲＴＡトラフィック識別情報に基づいて、ＲＴＡパケットのキュー分類ルールを設定
３６４ ＲＴＡトラフィック及び非ＲＴＡトラフィックの識別
３６６ キュー分類機構
３６８ ＲＴＡトラフィック（セッション３、４）
３７０ ＲＴＡトラフィック（セッション１、２）
３７２ ＲＴＡトラフィック（セッション１～４）
３７４ ＥＡキュー
３７６ ＴＡキュー
３７８ ＳＡキュー
３８０ バックオフ（任意）
３８２ バックオフ（任意）
３８４ バックオフ（任意）
３９０ 実施形態例
３９２ ＳＴＡがキューからＲＴＡパケットを破棄すべきかどうかを決定する
３９４ ＲＴＡパケットがＲＴＡキュー内にあるか？
３９６ ＲＴＡパケットが満了したか？
３９８ ＲＴＡパケットが再試行の限界を超えるか？
４００ ＲＴＡパケットを非ＲＴＡキューに移動させるか？
４０２ ＲＴＡパケットを非ＲＴＡキューに移動させる
４０４ ＲＴＡパケットを破棄
４０６ 終了
４１０ 実施形態例
４１２ アプリケーション層
４１４ ＲＴＡトラフィック
４１６ 非ＲＴＡトラフィック
４１８ キュー
４２０ 任意のバックオフ
４２２ 内部チャネルアクセス制御機構
４２４ チャネル
４２６ 緊急アクセス（ＥＡ）キュー
４２８ 時間が割り当てられたチャネルアクセス（ＴＡ）キュー
４３０ セッションベースのチャネルアクセス（ＳＡ）キュー
４３２ 音声（ＶＯ）キュー
４３４ ビデオ（ＶＩ）キュー
４３６ ベストエフォート（ＢＥ）キュー
４３８ バックグラウンド（ＢＫ）キュー
４４０ バックオフ（任意）
４４２ バックオフ（任意）
４４４ バックオフ（任意）
４４６ バックオフ（ＡＩＦＳ＋ＣＷ）
４４８ バックオフ（ＡＩＦＳ＋ＣＷ）
４５０ バックオフ（ＡＩＦＳ＋ＣＷ）
４５２ バックオフ（ＡＩＦＳ＋ＣＷ）
４７０ 実施形態例
４７２ アプリケーション層
４７４ ＲＴＡトラフィック
４７５ 非ＲＴＡトラフィック
４７６ キュー
４７８ 任意のバックオフ
４８０ 内部チャネルアクセス制御機構
４８２ チャネル
４８４ 緊急アクセス（ＥＡ）キュー
４８６ 時間が割り当てられたチャネルアクセス（ＴＡ）キュー
４８８ セッションベースのチャネルアクセス（ＳＡ）キュー
４９０ 音声（ＶＯ）キュー
４９２ ビデオ（ＶＩ）キュー
４９４ ベストエフォート（ＢＥ）キュー
４９６ バックグラウンド（ＢＫ）キュー
４９８ バックオフ（任意）
５００ バックオフ（任意）
５０２ バックオフ（任意）
５０４ バックオフ（ＡＩＦＳ＋ＣＷ）
５０６ バックオフ（ＡＩＦＳ＋ＣＷ）
５０８ バックオフ（ＡＩＦＳ＋ＣＷ）
５１０ バックオフ（ＡＩＦＳ＋ＣＷ）
５３０ 実施形態例
５３２，５３２’ アプリケーション層
５３４，５３４’ ＲＴＡストリーム／ＲＴＡトラフィック
５３６，５３６’ 非ＲＴＡキュー
５３８、５３８’ 任意のバックオフ
５４０ ＲＴＡパケットが満了した時に、セッション３のＲＴＡパケットをＶＯキューからＢＫキューに移動
５５０ 実施形態例
５７０ 実施形態例
５９０ 実施形態例
６１０ 実施形態例
６３０ 実施形態例
６５０ 実施形態例
６７０ 実施形態例
６９０ 実施形態例
７１０ 実施形態例
７１２ ＳＴＡがどのキューから送信パケットを抽出すべきかを決定する
７１４ ＴＦを受け取ったことによりチャネルアクセスを獲得したか？
７１６ ＴＦがＲＴＡセッション情報を含むか？
７１８ ＲＴＡキュー内のパケットを送信するために現在のチャネル時間を割り当てたか？
７２０ ＥＡキュー内にＲＴＡパケットがあるか？
７２２ 特定のＲＴＡセッションのパケットを送信するために現在のチャネル時間を割り当てたか？
７２４ 候補パケットをＴＡキュー内の最初のパケットとして設定
７２６ 候補パケットをＳＡキュー内の特定のＲＴＡセッションのパケットとして設定
７２８ ＥＡキュー内にＲＴＡパケットがあるか？
７３０ ＥＡキュー内の最初のパケットの優先度と候補パケットの優先度とを比較
７３２ ＲＴＡセッション情報に従ってＳＡキューからＲＴＡパケットを送信
７３４ ＥＡキュー内のパケットが高い優先度を有するか？
７３６ ＥＡキュー内のＲＴＡパケットを送信
７３８ 非ＲＴＡキュー内のパケットを送信
７４０ 候補パケットを送信
７４２ 終了
７５０ 実施形態例
７７０ 実施形態例
７９０ 実施形態例
７９２ 開始
７９４ クリアチャネル評価
７９６ ＳＴＡがどのキューから送信パケットを抽出すべきかを決定する
７９８ パケットを送信
８００ 送信が成功したか？
８０２ パケットがＲＴＡキューからのものか？
８０４ キューからパケットを取り除く
８０６ ＳＴＡは、ＲＴＡパケットをキューから破棄すべきかどうかを決定する
８０８ ＳＴＡは、パケットが再試行の限界を超える場合、パケットを破棄する
８１０ パケットを破棄すべきか？
８１２ パケットの再送信をスケジュール
８１４ パケットを破棄
８１６ 終了
８３０，８９０，９５０，１０１０ 実施形態例
８３２，８９２，９５２，１０１２ アプリケーション層
８３４，８９４，９５４，１０１４ ＲＴＡトラフィック
８３６，８９６，９５６，１０１６ 非ＲＴＡトラフィック
８３８，８９８，９５８，１０１８ いくつかのキュー
８４０，９００，９６０，１０２０ チャネルアクセスのタイプ
８４２，９０２，９６２，１０２２ 内部チャネルアクセス制御機構
８４４，９０４，９６４，１０２４ チャネル
８４６，９０６，９６６，１０２６ 緊急アクセス（ＥＡ）キュー
８４８，９０８，９６８，１０２８ 時間が割り当てられたアクセス（ＴＡ）キュー
８５０，９１０，９７０，１０３０ セッションベースのアクセス（ＳＡ）キュー
８５２，９１２，９７２，１０３２ 音声（ＶＯ）キュー
８５４，９１４，９７４，１０３４ ビデオ（ＶＩ）キュー
８５６，９１６，９７６，１０３６ ベストエフォート（ＢＥ）キュー
８５８，９１８，９７８，１０３８ バックグラウンド（ＢＫ）キュー
８６０，８６２，８６４，９２０，９２２，９２４，９８０，９８２，９８４，１０４０，１０４２，１０４４ 任意のバックオフ
８６６，８６８，８７０，８７２，９２６，９２８，９３０，９３２，９８６，９８８，９９０，９９２，１０４６，１０４８，１０５０，１０５２ ＡＩＦＳ＋ＣＷバックオフ
１０７０ 実施形態例
１０７２ 送信機ＳＴＡ０（ＡＰ）
１０７４ 受信機ＳＴＡ１
１０７６ 受信機ＳＴＡ２
１０７８ 受信機ＳＴＡ３
１０８０ 受信機ＳＴＡ４
１０８２ 非ＲＴＡキューに対してスケジュールされたチャネル時間
１０８４ バックオフ
１０８６ セッション３に対するＲＴＡパケット
１０８８ ＣＣＡビジー
１０９０ ＣＣＡビジー
１０９２ ＣＣＡビジー
１０９４ ＡＣＫ
１０９６ バックオフ
１０９８ セッション４に対するＲＴＡパケット
１１００ ＣＣＡビジー
１１０２ ＣＣＡビジー
１１０４ ＣＣＡビジー
１１０６ ＡＣＫ
１１０８ バックオフ
１１１０ 非ＲＴＡパケット
１１１２ ＣＣＡビジー
１１１４ ＣＣＡビジー
１１１６ ＣＣＡビジー
１１１８ ＡＣＫ
１１３０ 実施形態例
１１３２ 送信機ＳＴＡ０（ＡＰ）
１１３４ 受信機ＳＴＡ１
１１３６ 受信機ＳＴＡ２
１１３８ 受信機ＳＴＡ３
１１４０ 受信機ＳＴＡ４
１１４２ セッション２に対してスケジュールされたチャネル時間
１１４４ バックオフ（任意）
１１４６ セッション３に対するＲＴＡパケット
１１４８ ＣＣＡビジー
１１５０ ＣＣＡビジー
１１５２ ＡＣＫ
１１５３ ＣＣＡビジー
１１５４ バックオフ（任意）
１１５６ セッション２に対するＲＴＡパケット
１１５８ ＣＣＡビジー
１１６０ ＣＣＡビジー
１１６２ ＣＣＡビジー
１１６４ バックオフ（任意）
１１６５ セッション２に対するＲＴＡパケット
１１６６ ＣＣＡビジー
１１６８ ＣＣＡビジー
１１７０ ＣＣＡビジー
１１７１ ＡＣＫ
１１７２ バックオフ（任意）
１１７４ セッション４に対するＲＴＡパケット
１１７６ ＣＣＡビジー
１１７８ ＣＣＡビジー
１１８０ ＣＣＡビジー
１１８２ ＡＣＫ
１１９０ 実施形態例
１１９２ 送信機ＳＴＡ０（ＡＰ）
１１９４ 受信機ＳＴＡ１
１１９６ 受信機ＳＴＡ２
１１９８ 受信機ＳＴＡ３
１２００ 受信機ＳＴＡ４
１２０２ ＳＴＡ５、６、７
１２０４ セッション２に対してスケジュールされたチャネル時間
１２０６ セッション３に対するＲＴＡパケット
１２０８ ＡＣＫ
１２１０ セッション２に対するＲＴＡパケット
１２１２ セッション２に対するＲＴＡパケット
１２１４ ＡＣＫ
１２１６ セッション４に対するＲＴＡパケット
１２１８ ＡＣＫ
１２２０ 静かな状態のままである
１２３０ 実施形態例
１２３２ 送信機ＳＴＡ０（ＡＰ）
１２３４ 受信機ＳＴＡ１
１２３６ 受信機ＳＴＡ２
１２３８ 受信機ＳＴＡ３
１２４０ 受信機ＳＴＡ４
１２４２ ＴＡキューに対してスケジュールされたチャネル時間
１２４４ バックオフ（任意）
１２４６ セッション３に対するＲＴＡパケット
１２４８ ＣＣＡビジー
１２５０ ＣＣＡビジー
１２５２ ＣＣＡビジー
１２５４ ＡＣＫ
１２５６ バックオフ（任意）
１２５８ セッション１に対するＲＴＡパケット
１２６０ ＣＣＡビジー
１２６２ ＣＣＡビジー
１２６４ ＣＣＡビジー
１２６６ ＡＣＫ
１２６８ バックオフ（任意）
１２７０ セッション２に対するＲＴＡパケット
１２７２ ＣＣＡビジー
１２７４ ＣＣＡビジー
１２７６ ＣＣＡビジー
１２７８ ＡＣＫ
１２８０ バックオフ（任意）
１２８２ セッション４に対するＲＴＡパケット
１２８４ ＣＣＡビジー
１２８６ ＣＣＡビジー
１２８８ ＣＣＡビジー
１２９０ ＡＣＫ
１３１０ 実施形態例
１３１２，１３１４，１３１６，１３１８ ＲＴＡキューサブシステム
１３５０ 実施形態例
１３５２ 送信機ＳＴＡ０（ＡＰ）
１３５４ 受信機ＳＴＡ１
１３５６ 受信機ＳＴＡ２
１３５８ 受信機ＳＴＡ３
１３６０ 受信機ＳＴＡ４
１３６２ 受信機ＳＴＡ１、４に関連する非ＲＴＡキュー、受信機ＳＴＡ２に関連するＲＴＡセッション２、受信機ＳＴＡ３に関連するＴＡキューに対してスケジュールされたチャネル時間
１３６４ ヘッダ
１３６６ データ
１３６８，１３７０，１３７２，１３７４ ブロック確認応答（ＢＡ）
１３９０ 実施形態例
１４１０ 実施形態例
１４３０ 実施形態例
１４５０ 実施形態例
１４５２ 送信機ＳＴＡ０（ＡＰ）
１４５４ 受信機ＳＴＡ１
１４５６ 受信機ＳＴＡ２
１４５８ 受信機ＳＴＡ３
１４６０ 受信機ＳＴＡ４
１４６２ ＲＴＡ－ＴＦ
１４６４ ＲＴＡ－ＴＦ
１４６６ ヘッダ
１４６８ 非ＲＴＡトラフィック
１４７０ ヘッダ
１４７２ セッション７のＲＴＡトラフィック
１４７４ ヘッダ
１４７６ ＲＴＡセッション９のＲＴＡトラフィック
１４７８ ヘッダ
１４８０ 非ＲＴＡトラフィック
１４８２ ブロック確認応答（ＢＡ）
１４９０ 実施形態例
１４９２ 受信機ＳＴＡ０（ＡＰ）
１４９４ 送信機ＳＴＡ１
１４９６ 送信機ＳＴＡ２
１４９８ 送信機ＳＴＡ３
１５００ 送信機ＳＴＡ４
１５０２ ＳＴＡ１に関連する非ＲＴＡキュー、ＳＴＡ２、４に関連するＲＴＡセッション８、１１、ＳＴＡ３に関連するＴＡキューに対してスケジュールされたチャネル時間
１５０４ トリガフレーム
１５０６ ヘッダ
１５０８ 非ＲＴＡトラフィック
１５１０ ヘッダ
１５１２ ＲＴＡセッション７のＲＴＡトラフィック
１５１４ ヘッダ
１５１６ ＲＴＡセッション１０のＲＴＡトラフィック／ＲＴＡセッション１１のＲＴＡパケット
１５１８ ヘッダ
１５２０ ＲＴＡセッション１１のＲＴＡトラフィック／ＲＴＡセッション１０のＲＴＡパケット
１５２２ ブロック確認応答

Claims (23)

  1. ネットワーク内の無線通信のための装置であって、前記装置は、
    （ａ）少なくとも１つのチャネルを通じて、自機の受信エリア内のローカルエリアネットワーク（ＷＬＡＮ）上の少なくとも１つの他の無線局と無線通信するように構成される無線通信回線と、
    （ｂ）前記ＷＬＡＮ上で動作するように構成される局内の前記無線通信回線に結合されるプロセッサと、
    （ｃ）前記プロセッサによって実行可能な命令を記憶する非一時的メモリと、
    を備え、
    （ｄ）前記命令は、前記プロセッサによって実行された時に、
    （ｉ）リアルタイムアプリケーション（ＲＴＡ）トラフィック及び非ＲＴＡトラフィックが共存する、キャリア検知多重アクセス／衝突回避（ＣＳＭＡ／ＣＡ）をサポートするネットワークを通じて、通信遅延に対して敏感であるリアルタイムアプリケーション（ＲＴＡ）パケット及び非リアルタイムパケットの通信をサポートするように構成される無線ローカルエリアネットワーク（ＷＬＡＮ）局として、前記無線通信回線を動作させるステップと、
    （ｉｉ）リアルタイムアプリケーション（ＲＴＡ）パケットと非リアルタイムアプリケーション（非ＲＴＡ）パケットとを区別するステップと、
    （ｉｉｉ）ＲＴＡパケットをキューに入れるためにＲＴＡキューを作成する一方で、非ＲＴＡパケットを非ＲＴＡキューにプッシュするステップと、
    （ｉｖ）ＲＴＡセッションパラメータとＲＴＡキュー設定情報とを含む管理フレームを交換するステップと、
    （ｖ）パケットを送信するための前記ＲＴＡキューにチャネル時間を割り当てて、前記チャネル時間中に、非ＲＴＡキューが前記チャネルにアクセスすることを許可しないステップと、
    （ｖｉ）ＲＴＡセッションのＲＴＡキュー分類情報に基づいて、ＲＴＡパケットをどのＲＴＡキューに入れるべきかを決定するステップと、
    （ｖｉｉ）前記局がＲＴＡパケットの満了時間を設定し、満了したＲＴＡパケットが入れられた全てのＲＴＡキューから、前記満了したＲＴＡパケットを取り出すステップと、
    を含む１又は２以上のステップを実行する、
    ことを特徴とする装置。
  2. 前記命令は、前記プロセッサによって実行された時に、前記局が、事前ネゴシエーション又はパケットヘッダ情報に基づく情報を利用することによって、前記ＲＴＡトラフィックと前記非ＲＴＡトラフィックとを区別するステップを更に実行することを特徴とする、請求項１に記載の装置。
  3. 前記命令は、前記プロセッサによって実行された時に、ＲＴＡキューを作成する前記局が、当該作成されたキューが他のキューに割り当てられるチャネル時間を使用して前記チャネルにアクセスできるようにするように構成されるステップを更に実行することを特徴とする、請求項１に記載の装置。
  4. 前記命令は、前記プロセッサによって実行された時に、ＲＴＡキューを作成する前記局が、各パケットの満了時間及び優先度に基づいて各パケットの重要度指標を計算することによって、前記キュー内の前記ＲＴＡパケットをソートするように構成されるステップを更に実行することを特徴とする、請求項１に記載の装置。
  5. 前記命令は、前記プロセッサによって実行された時に、ＲＴＡキューを作成する前記局が、前記キュー内のパケットの順序を考慮することなく、ＲＴＡセッション情報に基づいて、前記キュー内の前記ＲＴＡパケットを送信するように構成されるステップを更に実行することを特徴とする、請求項１に記載の装置。
  6. 前記命令は、前記プロセッサによって実行された時に、ＲＴＡキューを作成する前記局が、そのキューに割り当てられるチャネルリソースを制限するように構成されるステップを更に実行することを特徴とする、請求項１に記載の装置。
  7. 前記命令は、前記プロセッサによって実行された時に、ＲＴＡセッションパラメータと、ＲＴＡキュー分類、ＲＴＡパケット満了時間、及び前記局と前記ネットワーク上の他の局との間の前記ＲＴＡセッションの満了したＲＴＡパケットを処理する方法の設定とを含む管理フレームを交換することを含むステップを更に実行することを特徴とする、請求項１に記載の装置。
  8. 前記命令は、前記プロセッサによって実行された時に、前記局及び前記ネットワーク上の他の局が、ＲＴＡキュー設定情報と、各キューのＲＴＡキューイング規則、ＲＴＡキューチャネル時間割り当て、及びＲＴＡキューチャネルリソース制限の設定とを含む管理フレームを交換するステップを更に実行することを特徴とする、請求項１に記載の装置。
  9. 前記命令は、前記プロセッサによって実行された時に、ＲＴＡパケットをどのＲＴＡキューに入れるべきかを決定する前記局が、前記決定を行う際に、事前ネゴシエーションによって交換される前記ＲＴＡセッションのキュー情報を利用するように構成されるステップを更に実行することを特徴とする、請求項１に記載の装置。
  10. 前記命令は、前記プロセッサによって実行された時に、ＲＴＡパケットをキューに入れる前記局が、レイテンシ要件に基づいて、このパケットを複数のＲＴＡキューにプッシュするように構成されるステップを更に実行することを特徴とする、請求項１に記載の装置。
  11. 前記命令は、前記プロセッサによって実行された時に、ＲＴＡパケットをキューに入れる前記局が、１つのキューを通じてそのパケットの送信が成功した時に、全てのキューからそのＲＴＡパケットを取り出すように構成されるステップを更に実行することを特徴とする、請求項１に記載の装置。
  12. 前記命令は、前記プロセッサによって実行された時に、ＲＴＡパケットの満了時間を設定する前記局が、その満了時間に達すると、前記パケットを破棄すること又は前記パケットを非ＲＴＡキューに移動させることのいずれかを決定するように構成されるステップを更に実行することを特徴とする、請求項１に記載の装置。
  13. ネットワーク内の無線通信のための装置であって、前記装置は、
    （ａ）少なくとも１つのチャネルを通じて、自機の受信エリア内のローカルエリアネットワーク（ＷＬＡＮ）上の少なくとも１つの他の無線局と無線通信するように構成される無線通信回線と、
    （ｂ）前記ＷＬＡＮ上で動作するように構成される局内の前記無線通信回線に結合されるプロセッサと、
    （ｃ）前記プロセッサによって実行可能な命令を記憶する非一時的メモリと、
    を備え、
    （ｄ）前記命令は、前記プロセッサによって実行された時に、
    （ｉ）リアルタイムアプリケーション（ＲＴＡ）トラフィック及び非ＲＴＡトラフィックが共存する、キャリア検知多重アクセス／衝突回避（ＣＳＭＡ／ＣＡ）をサポートするネットワークを通じて、通信遅延に対して敏感であるリアルタイムアプリケーション（ＲＴＡ）パケット及び非リアルタイムパケットの通信をサポートするように構成される無線ローカルエリアネットワーク（ＷＬＡＮ）局として、前記無線通信回線を動作させるステップと、
    （ｉｉ）リアルタイムアプリケーション（ＲＴＡ）パケットと非リアルタイムアプリケーション（非ＲＴＡ）パケットとを区別するステップであって、前記局が、事前ネゴシエーション又はパケットヘッダ情報に基づく情報を利用することによって、前記ＲＴＡトラフィックと前記非ＲＴＡトラフィックとを区別するステップと、
    （ｉｉｉ）ＲＴＡパケットをキューに入れるためにＲＴＡキューを作成する一方で、非ＲＴＡパケットを非ＲＴＡキューにプッシュするステップと、
    （ｉｖ）ＲＴＡセッションパラメータとＲＴＡキュー設定情報とを含む管理フレームを交換するステップと、
    （ｖ）パケットを送信するための前記ＲＴＡキューにチャネル時間を割り当てて、前記チャネル時間中に、非ＲＴＡキューが前記チャネルにアクセスすることを許可しないステップと、
    （ｖｉ）ＲＴＡセッションのＲＴＡキュー分類情報に基づいて、ＲＴＡパケットをどのＲＴＡキューに入れるべきかを決定するステップと、
    （ｖｉｉ）前記局が、ＲＴＡパケットの満了時間を設定し、満了したＲＴＡパケットが入れられた全てのＲＴＡキューから、前記満了したＲＴＡパケットを取り出すステップと、
    （ｖｉｉｉ）ＲＴＡキューを作成する前記局が、当該作成されたキューが他のキューに割り当てられるチャネル時間を使用して前記チャネルにアクセスできるようにするように構成されるステップと、
    を含む１又は２以上のステップを実行する、
    ことを特徴とする装置。
  14. 前記命令は、前記プロセッサによって実行された時に、ＲＴＡキューを作成する前記局が、満了時間及び優先度に基づいて各パケットの重要度指標を計算することによって、前記キュー内の前記ＲＴＡパケットをソートするように構成されるステップを更に実行することを特徴とする、請求項１３に記載の装置。
  15. 前記命令は、前記プロセッサによって実行された時に、ＲＴＡキューを作成する前記局が、前記キュー内のパケットの順序を考慮することなく、パケットのＲＴＡセッション情報に基づいて、前記キュー内の前記ＲＴＡパケットを送信するように構成されるステップを更に実行することを特徴とする、請求項１３に記載の装置。
  16. 前記命令は、前記プロセッサによって実行された時に、ＲＴＡキューを作成する前記局が、そのキューに割り当てられるチャネルリソースを制限するように構成されるステップを更に実行することを特徴とする、請求項１３に記載の装置。
  17. 前記命令は、前記プロセッサによって実行された時に、ＲＴＡセッションパラメータと、ＲＴＡキュー分類、ＲＴＡパケット満了時間、及び前記局と前記ネットワーク上の他の局との間の前記ＲＴＡセッションの満了したＲＴＡパケットを処理する方法の設定とを含む管理フレームを交換することを含むステップを更に実行することを特徴とする、請求項１３に記載の装置。
  18. 前記命令は、前記プロセッサによって実行された時に、前記局及び前記ネットワーク上の他の局が、ＲＴＡキュー設定情報と、各キューのＲＴＡキューイング規則、ＲＴＡキューチャネル時間割り当て、及びＲＴＡキューチャネルリソース制限の設定とを含む管理フレームを交換するステップを更に実行することを特徴とする、請求項１３に記載の装置。
  19. 前記命令は、前記プロセッサによって実行された時に、ＲＴＡパケットをどのＲＴＡキューに入れるべきかを決定する前記局が、この決定を行う際に、事前ネゴシエーションによって交換される前記ＲＴＡセッションのキュー情報を利用するように構成されるステップを更に実行することを特徴とする、請求項１３に記載の装置。
  20. 前記命令は、前記プロセッサによって実行された時に、ＲＴＡパケットをキューに入れる前記局が、レイテンシ要件に基づいて、このパケットを複数のＲＴＡキューにプッシュするように構成されるステップを更に実行することを特徴とする、請求項１３に記載の装置。
  21. 前記命令は、前記プロセッサによって実行された時に、ＲＴＡパケットをキューに入れる前記局が、１つのキューを通じてそのパケットの送信が成功した時に、全てのキューからそのＲＴＡパケットを取り出すように構成されるステップを更に実行することを特徴とする、請求項１３に記載の装置。
  22. 前記命令は、前記プロセッサによって実行された時に、ＲＴＡパケットの満了時間を設定する前記局が、その満了時間に達すると、前記パケットを破棄すること又は前記パケットを非ＲＴＡキューに移動させることのいずれかを決定するように構成されるステップを更に実行することを特徴とする、請求項１３に記載の装置。
  23. ネットワーク内の無線通信を実行する方法であって、
    （ａ）リアルタイムアプリケーション（ＲＴＡ）トラフィック及び非ＲＴＡトラフィックが共存する、キャリア検知多重アクセス／衝突回避（ＣＳＭＡ／ＣＡ）をサポートするネットワークを通じて、通信遅延に対して敏感であるリアルタイムアプリケーション（ＲＴＡ）パケット及び非リアルタイムパケットの通信をサポートするように構成される無線ローカルエリアネットワーク（ＷＬＡＮ）局として、無線通信回線を動作させるステップと、
    （ｂ）リアルタイムアプリケーション（ＲＴＡ）パケットと非リアルタイムアプリケーション（非ＲＴＡ）パケットとを区別するステップと、
    （ｃ）ＲＴＡパケットをキューに入れるためにＲＴＡキューを作成する一方で、非ＲＴＡパケットを非ＲＴＡキューにプッシュするステップと、
    （ｄ）ＲＴＡセッションパラメータとＲＴＡキュー設定情報とを含む管理フレームを交換するステップと、
    （ｅ）パケットを送信するための前記ＲＴＡキューにチャネル時間を割り当てて、前記チャネル時間中に、非ＲＴＡキューが前記チャネルにアクセスすることを許可しないステップと、
    （ｆ）ＲＴＡセッションのＲＴＡキュー分類情報に基づいて、ＲＴＡパケットをどのＲＴＡキューに入れるべきかを決定するステップと、
    （ｇ）前記局がＲＴＡパケットの満了時間を設定し、満了したＲＴＡパケットが入れられた全てのＲＴＡキューから、前記満了したＲＴＡパケットを取り出すステップと、
    を含むことを特徴とする方法。
JP2022506516A 2019-09-09 2020-09-02 無線ローカルエリアネットワーク（ｗｌａｎ）局におけるｒｔａキュー管理 Active JP7334847B2 (ja)

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
US201962897600P 2019-09-09 2019-09-09
US62/897,600 2019-09-09
US16/749,496 2020-01-22
US16/749,496 US11178694B2 (en) 2019-09-09 2020-01-22 RTA queue management in wireless local area network (WLAN) stations
PCT/IB2020/058181 WO2021048706A1 (en) 2019-09-09 2020-09-02 Rta queue management in wireless local area network (wlan) stations

Publications (2)

Publication Number Publication Date
JP2022542460A JP2022542460A (ja) 2022-10-03
JP7334847B2 true JP7334847B2 (ja) 2023-08-29

Family

ID=74849665

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2022506516A Active JP7334847B2 (ja) 2019-09-09 2020-09-02 無線ローカルエリアネットワーク（ｗｌａｎ）局におけるｒｔａキュー管理

Country Status (6)

Country Link
US (1) US11178694B2 (ja)
EP (1) EP4008089A1 (ja)
JP (1) JP7334847B2 (ja)
KR (1) KR102695233B1 (ja)
CN (1) CN113853828B (ja)
WO (1) WO2021048706A1 (ja)

Families Citing this family (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11937251B2 (en) * 2019-11-05 2024-03-19 Mediatek Inc. Apparatuses and methods for flexible Resource Unit (RU) allocation
US11916804B2 (en) * 2020-06-01 2024-02-27 Intel Corporation QOS model for supporting low latency services and time-sensitive networking
EP4292378A2 (en) * 2021-03-31 2023-12-20 Sony Group Corporation Sharing an edca txop with rta traffic
CN114630447A (zh) * 2022-02-14 2022-06-14 深圳市联洲国际技术有限公司 数据处理方法、装置，设备及计算机可读存储介质
US20240155685A1 (en) * 2022-02-14 2024-05-09 Tp-Link Corporation Limited Data processing method, apparatus, device and computer-readable storage medium
CN117955926B (zh) * 2024-03-25 2024-07-09 广州天奕技术股份有限公司 毫米波的数据面调度方法、装置及设备

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20120224483A1 (en) 2011-03-02 2012-09-06 3Inova Networks Inc. Traffic management in distributed wireless networks

Family Cites Families (22)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7095754B2 (en) * 2000-11-03 2006-08-22 At&T Corp. Tiered contention multiple access (TCMA): a method for priority-based shared channel access
KR20040028055A (ko) 2002-09-28 2004-04-03 주식회사 케이티 무선 랜에서의 실시간/비실시간 패킷 전송 장치 및 그 방법
KR100542346B1 (ko) * 2003-07-30 2006-01-11 삼성전자주식회사 무선 랜 액세스 포인트의 패킷 처리 장치 및 그 방법
US7656899B2 (en) * 2003-11-06 2010-02-02 Interdigital Technology Corporation Access points with selective communication rate and scheduling control and related methods for wireless local area networks (WLANs)
US20050152373A1 (en) * 2004-01-08 2005-07-14 Interdigital Technology Corporation Packet scheduling in a wireless local area network
KR100654429B1 (ko) * 2004-03-03 2006-12-06 삼성전자주식회사 무선 스테이션의 트래픽을 동적으로 제어하는 방법 및 장치
WO2005088903A2 (en) * 2004-03-05 2005-09-22 Nextnet Wireless, Inc. Method and apparatus for isochronous datagram delivery over contention-based data link
US7583664B2 (en) * 2004-12-28 2009-09-01 Michael Ho Techniques for transmitting and receiving traffic over advanced switching compatible switch fabrics
JP5121054B2 (ja) * 2007-06-01 2013-01-16 パナソニック株式会社 通信方法、通信装置、及び通信システム
EP2187568A4 (en) * 2007-08-31 2014-09-24 Fujitsu Ltd METHOD AND APPARATUS FOR WIRELESS ACCESS
US8665724B2 (en) * 2009-06-12 2014-03-04 Cygnus Broadband, Inc. Systems and methods for prioritizing and scheduling packets in a communication network
CN102075440B (zh) * 2011-02-23 2012-11-28 湖南大学 一种服务质量敏感的802.11e多媒体数据分组调度方法
US8660008B2 (en) * 2011-03-02 2014-02-25 3Inova Networks Inc. Traffic management in distributed wireless networks
US10080238B2 (en) * 2013-11-08 2018-09-18 Interdigital Patent Holdings, Inc. Distributed reservation contention access (DRCA) for wireless local area network (WLAN) carrier sense multiple access (CSMA) stations
US9832143B2 (en) * 2014-12-29 2017-11-28 Oracle International Corporation System and method for supporting efficient virtual output queue (VOQ) packet flushing scheme in a networking device
WO2016177435A1 (en) * 2015-05-06 2016-11-10 Telefonaktiebolaget Lm Ericsson (Publ) Methods and devices for handling data packet transmissions in a multi-path multi-hop adapted wireless communication network
US10445271B2 (en) * 2016-01-04 2019-10-15 Intel Corporation Multi-core communication acceleration using hardware queue device
GB2555142B (en) 2016-10-21 2019-09-04 Canon Kk Enhanced management of ACs in multi-user EDCA transmission mode in wireless networks
US10505859B2 (en) * 2016-11-10 2019-12-10 The Government Of The United States Of America, As Represented By The Secretary Of The Navy Packet deadlines in a queue to control the age of information
CN109121098B (zh) * 2018-08-24 2021-05-25 京东方科技集团股份有限公司 一种分配信道的方法及系统
US11095568B2 (en) * 2018-11-06 2021-08-17 Cox Communications, Inc. Systems and methods for network scheduling and re-transmission buffering
GB2582813B (en) * 2019-04-04 2022-02-16 Canon Kk Backoff management for intra-queue priority transmission in communication networks

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20120224483A1 (en) 2011-03-02 2012-09-06 3Inova Networks Inc. Traffic management in distributed wireless networks

Also Published As

Publication number Publication date
WO2021048706A1 (en) 2021-03-18
JP2022542460A (ja) 2022-10-03
CN113853828B (zh) 2024-02-13
CN113853828A (zh) 2021-12-28
KR102695233B1 (ko) 2024-08-16
KR20220037484A (ko) 2022-03-24
EP4008089A1 (en) 2022-06-08
US20210076420A1 (en) 2021-03-11
US11178694B2 (en) 2021-11-16

Similar Documents

Publication Publication Date Title
JP7334847B2 (ja) 無線ローカルエリアネットワーク（ｗｌａｎ）局におけるｒｔａキュー管理
JP7345739B2 (ja) Ｍｕ－ｍｉｍｏパケット到着前チャネル競合
JP7427170B2 (ja) 時間内及び周波数内ｒｔａパケット重複
CN113796153B (zh) 分组到达前信道竞争
CN113875272B (zh) 实时应用
JP7288590B2 (ja) 無線ローカルエリアネットワークにおける将来的チャネル時間の予約
GB2560540A (en) Queues management for multi-user and single user edca transmission mode in wireless networks
JP2022541620A (ja) リアルタイムアプリケーショントラフィックのための競合衝突回避
US20220322460A1 (en) Sharing an edca txop with rta traffic
KR20230144638A (ko) Rta 트래픽과 edca txop 공유
KR20220153610A (ko) Rta 패킷들을 위한 edca 큐
CN117336876A (zh) 低延迟业务传输方法及系统
KR102702545B1 (ko) Mu-mimo 패킷 도달 전 채널 경합
WATFA Quality of service in wireless local and metropolitan area networks

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20220131

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20230131

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20230215

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20230417

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: 20230718

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20230731

R151 Written notification of patent or utility model registration

Ref document number: 7334847

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R151