CN113875272B - 实时应用 - Google Patents

实时应用 Download PDF

Info

Publication number
CN113875272B
CN113875272B CN202080038802.5A CN202080038802A CN113875272B CN 113875272 B CN113875272 B CN 113875272B CN 202080038802 A CN202080038802 A CN 202080038802A CN 113875272 B CN113875272 B CN 113875272B
Authority
CN
China
Prior art keywords
rta
layer
session
app
sta
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
CN202080038802.5A
Other languages
English (en)
Other versions
CN113875272A (zh
Inventor
忻良骁
M·阿布欧埃尔首德
迫田和之
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 Group Corp
Original Assignee
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 Group Corp filed Critical Sony Group Corp
Publication of CN113875272A publication Critical patent/CN113875272A/zh
Application granted granted Critical
Publication of CN113875272B publication Critical patent/CN113875272B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W80/00—Wireless network protocols or protocol adaptations to wireless operation
    • H04W80/08—Upper layer protocols
    • H04W80/12—Application layer protocols, e.g. WAP [Wireless Application Protocol]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W24/00—Supervisory, monitoring or testing arrangements
    • H04W24/04—Arrangements for maintaining operational condition
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/80—Services using short range communication, e.g. near-field communication [NFC], radio-frequency identification [RFID] or low energy communication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W24/00—Supervisory, monitoring or testing arrangements
    • H04W24/10—Scheduling measurement reports ; Arrangements for measurement reports
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/70—Services for machine-to-machine communication [M2M] or machine type communication [MTC]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W76/00—Connection management
    • H04W76/10—Connection setup
    • H04W76/18—Management of setup rejection or failure
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W80/00—Wireless network protocols or protocol adaptations to wireless operation
    • H04W80/02—Data link layer protocols
    • 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)
  • Mobile Radio Communication Systems (AREA)

Abstract

OSI模型中互通通信的介质访问控制(MAC)和应用(APP)层之间的实时应用(RTA)接口，用于无线局域网(WLAN)。MAC和APP层之间的接口能够被用于RTA分组，而非RTA分组仍然能够使用常规OSI模型。在初始化新的RTA会话时，APP层将要求的集合传送到MAC层。MAC层监视信道并测量关键性能指标(KPI)并且或者接受或者拒绝请求。APP和MAC层之间的互操作性提供了减少RTA分组时延的增强能力，以及其它好处。

Description

实时应用
对相关申请的交叉引用
本申请要求于2019年12月23日提交的美国临时专利申请序列No.62/952,681的优先权和权益，该申请通过引用整体并入本文。
关于联邦政府资助的研究或开发的声明
不适用
通过引用纳入计算机程序附录
不适用
受版权保护的资料的通知
本专利文档中的资料的一部分可以根据美国和其他国家的版权法受到版权保护。版权所有者不反对任何人按照本专利文档或专利公开登载在专利商标局公众可获得的文件或记录中那样传真复制本专利文档或专利公开，但在其他方面保留所有版权。版权所有者据此不放弃其使本专利文档保密的任何权利，包括但不限于其依据37.C.F.R.§1.14的权利。
背景技术
1、技术领域
本公开的技术一般而言涉及无线网络通信，并且更具体地涉及实现无线通信设备协议的介质访问控制(MAC)和应用层之间的特定实时应用(RTA)接口。
2、背景技术讨论
使用开放系统互连(OSI)模型的当前无线技术(诸如IEEE802.11协议)不提供低时延能力。但是，诸如实时应用(RTA)之类的广泛应用都要求低时延。
RTA要求低时延通信并且使用尽力而为通信。从RTA生成的数据被称为RTA业务，并在发送者站(STA)处被打包为RTA分组。相反，从非时间敏感应用生成的数据在本文中被称为非RTA业务并且将在发送者STA处被打包为非RTA分组。
RTA分组由于其对分组递送的高及时性要求而要求低时延。RTA分组只有在一定时间段内递送才有效。为了实现这个要求，在OSI模型中要求新的通信功能，以及网络层之间的互通通信。
OSI是由国际标准化组织(IOS)定义的概念模型，以在具有标准通信协议的各种计算系统之间建立电信。通常，OSI由七层组成，应用(APP)层、表示层、会话层、传输层、网络层、数据链路层和物理层。那些层被用于定义和标准化在各种形式的通信中使用的功能。当两个系统在同一层处共享相同的通信协议时，它们就能够在彼此之前交换信息。
当通信发生时，每一层向其上方的层提供服务并从其下方的层请求服务。因此，OSI模型中网络层之间的互通通信被用于启用这些服务。
IEEE 802.11协议定义了数据链路(即，MAC)和物理(即，PHY)层的标准通信协议。目前的802.11协议只关注获得无线网络的吞吐量性能。但是，没有考虑无线网络的时延性能并且这对于RTA来说是有问题的。当网络传输RTA分组时，它们通常只在一定时间段内有效，它要求APP层和MAC层建立互通通信，以控制和监视那个时间内的业务传输，从而要求对分组时延进行控制的测量。
现有技术不满足RTA分组的及时性要求并且不针对最小化RTA分组传输时延。
因而，存在对WLAN系统中的RTA分组业务进行增强的时延控制的需要。本公开满足该需要并提供优于先前技术的附加益处。
发明内容
IEEE 802.11的当前无线通信系统不识别RTA分组和非RTA分组。所有分组都使用相同的OSI模型。IEEE 802.11的当前OSI模型没有表征或标准化用于RTA分组的低时延通信功能。IEEE 802.11标准此时并未解决控制RTA分组所经受的时延问题。这些功能的缺失使得当前的IEEE 802.11协议无法满足RTA分组的低时延要求。
为了满足RTA业务的低时延要求，本公开描述了区分RTA分组并在作为OSI模型中互通通信的一部分的介质访问控制(MAC)和应用(APP)层之间提供有益的RTA接口。
由于网络上RTA业务和非RTA业务的共存，在MAC和APP层之间创建RTA接口的任务更具挑战性。这个处理中的挑战可以被概括为：(a)识别和区分RTA分组与非RTA分组；(b)在网络层之间设计新的互通通信，以支持RTA分组的低时延要求；以及(c)允许RTA分组使用新的互通通信来获得低时延服务，而非RTA分组可以利用现有的互通通信从高吞吐量服务中受益。
MAC和APP层之间的RTA接口旨在考虑RTA业务的时间有效性并通过互通通信提供可能的低时延服务，其中RTA和非RTA业务共存于无线网络中。
低时延通信的若干功能可能在MAC或PHY层处被表征和标准化。为了在IEEE802.11的OSI模型中启用那些功能，OSI模型的网络层之间新的互通通信是必要的。
RTA业务主要涉及端到端时延，这是在发送者的APP层处生成业务时和在接收者的APP层接收业务时之间的时间。因此，允许APP层具有某种能力来控制和监视用于RTA业务的MAC层功能是有益的。
本公开教导MAC和APP层之间的RTA接口作为用于RTA分组的OSI模型中的互通通信的一部分，而非RTA分组仍然可以使用常规OSI模型。本公开可以应用于IEEE 802.11，并且更优选地是IEEE 802.11及其以后。
MAC和APP层之间的RTA接口允许APP层管理MAC层处的RTA会话。常常，RTA以面向连接的通信方式周期性地生成业务。由应用在STA之间建立的面向RTA连接的通信被称为RTA会话。站(STA)有可能可以在网络中具有多个RTA会话。APP能够通过使用所公开的MAC和APP层之间的接口来适当管理那些RTA会话。
MAC和APP层之间的RTA接口允许APP层管理MAC层处的RTA队列。APP层能够通过RTA接口发送设置RTA队列的参数的命令。该接口还允许MAC层向APP层报告RTA队列状态。
MAC和APP层之间的RTA接口允许APP层测量MAC和PHY层处的RTA关键性能指标(KPI)。APP层向MAC层发送RTA KPI测量请求并且MAC层通过RTA接口向APP层报告KPI测量结果。
本文描述的技术的进一步的方面将在说明书的以下部分中提出，其中详细描述是为了充分公开该技术的优选实施例而不对其进行限制。
附图说明
通过参照以下仅出于说明性的目的的附图，将更充分地理解本文中描述的技术：
图1是载波侦听多址(CSMA)/冲突避免(CA)中常规的基于竞争的信道接入的流程图。
图2是示出当ReadyToSend/ClearToSend(RTS/CTS)被禁用时CSMA/CA中的分组传输的信令图。
图3是增强型分布式信道接入(EDCA)队列系统的数据流图。
图4是根据本公开的至少一个实施例使用的无线mmW通信站硬件的框图。
图5是具有两个AP的小型WLAN网络的网络拓扑图，在本公开中用作示例拓扑。
图6是根据本公开的至少一个实施例的开放系统互连(OSI)模型中的RTA和非RTA业务通信的分层通信图。
图7是示出根据本公开的至少一个实施例的用于RTA业务通信的在先协商的分层通信图。
图8是根据本公开的至少一个实施例的在发送者侧识别RTA分组的流程图。
图9是根据本公开的至少一个实施例的RTA会话标识内的字段的数据字段图。
图10是示出根据本公开的至少一个实施例的APP层和MAC层之间的报头信息交换的分层通信图。
图11是根据本公开的至少一个实施例的在接收者侧识别RTA分组的流程图。
图12是根据本公开的至少一个实施例的RTA管理的互通模型。
图13是根据本公开的至少一个实施例的RTA管理的层管理模型。
图14是示出根据本公开的至少一个实施例的RTA会话信息字段的数据字段图。
图15A至图15C是根据本公开的至少一个实施例执行的RTA会话发起的通信序列图。
图16是根据本公开的至少一个实施例的RTA会话发起请求帧格式的数据字段图。
图17是根据本公开的至少一个实施例的RTA会话发起响应帧格式的数据字段图。
图18A和图18B是根据本公开的至少一个实施例执行的用于RTA会话发起的替代过程的通信序列图。
图19是根据本公开的至少一个实施例执行的被发起站(STA)拒绝的RTA会话发起的通信序列图。
图20A和图20B是根据本公开的至少一个实施例执行的被接收方站(STA)的APP层拒绝的RTA会话发起的通信序列图。
图21A和图21B是例示根据本公开的至少一个实施例执行的RTA会话重新发起的过程的通信序列图。
图22是例示根据本公开的至少一个实施例执行的RTA会话破坏的过程的通信序列图。
图23是根据本公开的至少一个实施例的RTA会话破坏请求帧格式的数据字段图。
图24是根据本公开的至少一个实施例的例示RTA会话公告的过程的通信序列图。
图25是根据本公开的至少一个实施例的RTA会话公告帧格式的数据字段图。
图26A和图26B是例示根据本公开的至少一个实施例的RTA队列参数设置的通信序列图。
图27是根据本公开的至少一个实施例的RTA队列参数设置请求帧的数据字段图。
图28是根据本公开的至少一个实施例的RTA队列参数设置响应帧的数据字段图。
图29是例示根据本公开的至少一个实施例按照不同的重要性指数对队列中的RTA分组进行排序的队列图。
图30是例示根据本公开的至少一个实施例将信道时间分配给不同队列的传输序列图。
图31是例示根据本公开的至少一个实施例执行的RTA关键性能指标(KPI)测量处理的通信序列图。
图32是根据本公开的至少一个实施例的RTA关键性能指标(KPI)测量请求帧格式的数据字段图。
图33是根据本公开的至少一个实施例的RTA关键性能指标(KPI)测量报告帧格式的数据字段图。
图34是根据本公开的至少一个实施例的用于信道带宽测量的RTA关键性能指标(KPI)测量方法字段格式的数据字段图。
图35是根据本公开的至少一个实施例的用于信道带宽测量的RTA关键性能指标(KPI)测量报告字段格式的数据字段图。
图36A和图36B是根据本公开的至少一个实施例的信道带宽测量的流程图。
图37是根据本公开的至少一个实施例的用于分组时延的RTA KPI测量方法字段格式的数据字段图。
图38是根据本公开的至少一个实施例的分组时延的RTA KPI测量报告字段格式的数据字段图。
图39A和图39B是根据本公开的至少一个实施例的分组时延测量过程的流程图。
图40是根据本公开的至少一个实施例的用于信道使用情况的RTA KPI测量方法字段格式的数据字段图。
图41是根据本公开的至少一个实施例的用于信道使用情况测量的RTA KPI测量报告字段格式的数据字段图。
图42是根据本公开的至少一个实施例的信道使用情况测量过程的流程图。
图43是根据本公开的至少一个实施例的用于队列状态测量的RTA KPI测量方法字段格式的数据字段图。
图44是根据本公开的至少一个实施例的用于队列状态测量的RTA KPI测量报告字段格式的数据字段图。
图45是根据本公开的至少一个实施例的队列状态测量过程的流程图。
图46是根据本公开的至少一个实施例的用于业务分析的RTA KPI测量方法字段格式的数据字段图。
图47是根据本公开的至少一个实施例的用于业务分析的RTA KPI测量报告字段格式的数据字段图。
图48是根据本公开的至少一个实施例的业务分析过程的流程图。
图49是示出根据本公开的至少一个实施例的将测量结果用于多链路传输的示例的通信链路图。
具体实施方式
1.802.11WLAN系统介绍
1.1.CSMA/CA操作
图1描绘了在IEEE 802.11下使用载波侦听多路访问/冲突避免(CSMA/CA)以允许站(STA)随机接入信道以进行分组传输和重传的WLAN系统的细节。在CSMA/CA系统中，当有数据要被传输时，STA感测信道以进行传输。在每次传输和重传之前，STA必须感测信道并设置(等待)退避时间以竞争信道接入。
退避时间由零和竞争窗口的尺寸(持续时间)之间的统一随机变量决定。在STA等待退避时间并感测到信道空闲之后，它决定是否发送RTS帧以确保信道占用。如果STA发送RTS帧，那么在它接收到CTS帧时确保信道占用，此时STA发送分组。如果STA没有发送RTS帧，那么在一些情况下它可以直接发送分组。如果在发送RTS帧之后没有接收到CTS帧，或者如果STA在超时之前没有接收到ACK，那么要求重传。否则，如果接收到CTS帧，那么传输已成功。当要求重传时，STA检查分组的重传次数，并且如果重传次数超过重试限制，那么丢弃该分组，并且不调度重传；否则，调度重传。如果调度重传，那么需要另一个退避时间以竞争信道接入以进行重传。如果竞争窗口的尺寸没有达到上限，那么STA增加它。STA根据竞争窗口的新尺寸设置另一个退避时间，并等待退避时间以进行重传，并且这个处理续。
图2图示了在禁用RTS/CTS的CSMA/CA下发送者站和接收站之间的随机信道接入的示例。当发送者STA的MAC层从其上层接收数据时，它为获得信道接入而竞争。当发送者STA竞争信道时，它必须等到退避时间，由此竞争窗口的尺寸是“n”个时隙(CW＝n个时隙)，它在退避期间倒计时到零。当另一个分组传输通过信道发生时，倒计时处理被中断(即，空闲信道评估(CCA)指示忙)。在发送者STA获得用于传输数据的信道接入之后，将数据打包成分组并通过信道传输该分组。如图所示，如果分组的初传失败，那么要求分组的重传。发送者STA设置另一个退避时间以竞争信道接入。这一次，竞争窗口的尺寸加倍，即，2*n个时隙(CW＝2*n个时隙)，因为这是重传。预期的退避时间也会因竞争窗口尺寸而加倍。当退避时间更长时，倒计时处理将被另一个分组传输中断(即，CCA忙)的可能性增加。该图示出，在最初失败的传输，然后竞争信道三次之后，它最终执行第一次重传，该重传在接收到ACK时成功。
该图还描绘了具有SIFS、DIFS和ACK超时的定时。图中的G1表示短帧间间距(ShortInter-frame Spacing，SIFS)，即，无线设备在接收帧和对帧响应之间所需的时间间隔。分布式协调功能(DCF)协议控制对物理介质的访问，其中站必须在传输之前感测无线介质的状态。如果发现介质持续空闲达DCF帧间空间(DIFS)持续时间内，那么允许传输帧。如果在DIFS间隔期间发现信道忙，那么站应当推迟其传输。该图将DIFS表示为G2。应该注意的是，常规DIFS被计算为DIFS＝SIFS+(2*时隙时间)。G3表示ACK超时间隔，它是在假设传输错误已发生之前允许接收传输的确认的时间。
1.2.EDCA队列系统
图3描绘了WLAN增强型分布式信道接入(EDCA)队列系统。在WLAN系统中，IEEE802.11使用EDCA协议将分组分类为不同的访问类别(AC)，每个AC表示不同的业务优先级。STA将所有分组映射到不同的AC中并将它们推送到关于AC的独立队列中。
使用EDCA协议的队列系统的参考实施方式模型在图中示出，其中看到四个AC，诸如语音(VO)、视频(VI)、尽力而为(BE)和后台(BK)，优先级从左到右递减。每个AC具有独立的队列来管理分组传输的次序。每个队列依靠基于CSMA/CA的随机信道接入机制来获得信道接入。取决于AC的业务优先级，每个队列获得信道接入的退避时间不同。AC的业务优先级越高，那个AC队列的平均退避时间越短。因此，越高优先级AC的队列中的分组比越低优先级AC的队列中的分组具有更早获得信道接入的更高概率。
2.问题陈述
IEEE 802.11的当前无线通信系统没有识别和区分RTA分组与非RTA分组，所有分组都根据相同的传统OSI模型被处置，没有专门解决RTA分组的时延问题。此时，IEEE802.11的当前OSI模型并未表征或标准化用于RTA分组的低时延通信的功能。这些功能的缺失意味着当前的IEEE 802.11协议无法满足RTA分组的低时延要求。
3.发明性贡献
为了支持低时延通信，本文描述了若干功能，用于在MAC或PHY层处被表征和标准化。为了在IEEE 802.11的OSI模型中启用那些功能，需要对OSI模型的网络层之间的互通通信模型进行改变。
在RTA业务中，非常重要的因素是端到端时延，这是在发送者的APP层处生成业务时和在接收者的APP层接收业务时之间的时间。因此，允许APP层具有某种能力来控制和监视用于RTA业务的MAC层功能是有益的。
本公开将MAC和APP层之间的RTA接口描述为用于RTA分组的OSI模型中互通通信的一部分，而非RTA分组仍然可以依靠传统(常规)OSI模型的元素。
MAC和APP层之间的RTA接口允许APP层管理MAC层处的RTA会话。常常，RTA周期性地生成业务，作为面向连接的通信的形式。由应用在STA之间建立的面向RTA连接的通信被称为RTA会话。STA有可能可以在网络中具有多个RTA会话。APP能够通过使用所公开的MAC和APP层之间的接口来适当管理那些RTA会话。
MAC和APP层之间的RTA接口允许APP层管理MAC层处的RTA队列。APP层能够通过RTA接口发送设置RTA队列的参数的命令。该接口还允许MAC层向APP层报告RTA队列状态。
MAC和APP层之间的RTA接口允许APP层测量MAC和PHY层处的RTA关键性能指标(KPI)。APP层向MAC层发送RTA KPI测量请求并且MAC层通过RTA接口向APP层报告KPI测量结果。
4.硬件实施例
4.1.站(STA)硬件配置
图4图示了根据本公开的WLAN站的示例实施例10。I/O路径14被示为电路块12，其具有连接到至少一个计算机处理器(CPU)18、存储器(RAM)20和至少一个调制解调器22的总线16。总线14允许将各种设备连接到CPU，诸如连接到传感器、致动器等。来自存储器20的指令在处理器18上被执行以执行实现通信协议的程序，该程序被执行以允许STA执行接入点(AP)站或常规站(STA)的功能。还应当认识到的是，编程被配置为在不同模式下操作(源、中间、目的地、第一AP、其它AP、与第一AP相关联的站、与其它AP关联的站、协调者、被协调者等等)，这取决于它在当前的通信环境中扮演着什么角色。
这个主机机器被示为配置有至少一个调制解调器和RF电路。作为示例而非限制，mmW调制解调器22耦合到至少一个射频(RF)电路24，该RF电路24连接到多个天线26a、26b、26c至26n(例如，天线阵列)以与相邻STA传输和接收帧。处理器、调制解调器和RF电路的组合允许支持波束赋形(定向)通信，以及支持来自天线阵列的准全向(本文简称为全向)模式传输。此外，在至少一个优选实施例中，可以在由天线阵列创建的定向模式中生成零点，以屏蔽选择的方向(扇区)并因此减少站之间的干扰。该示例还描绘了耦合到全向RF电路28和天线29的调制解调器22。
因此，STA HW被示为配置有至少一个调制解调器和用于在至少一个频带上提供通信的相关联的RF电路系统。作为示例而非限制，预期的定向通信频带是用mmW频带调制解调器及其相关联的用于在mmW频带中传输和接收数据的RF电路来实现的。在一些实施方式中，硬件中可以支持另一个频带，一般称为发现频带，作为示例而非限制，其可以包括6GHz以下调制解调器及其相关联的用于在6GHz以下频带中传输和接收数据的RF电路系统。
应当认识到的是，本公开可以配置有多个调制解调器22，每个调制解调器耦合到任何任意数量的RF电路。一般而言，使用大量RF电路将导致天线波束方向的覆盖范围更广。应当认识到的是，所利用的RF电路的数量和天线的数量由具体设备的硬件约束确定。当STA确定不必与相邻的STA通信时，可以禁用其中一些RF电路系统和天线。在至少一个实施例中，RF电路系统包括变频器、阵列天线控制器等，并且连接到多个天线，这些天线被控制以执行波束赋形以用于传输和接收。以这种方式，STA可以使用多个波束方向图集合来传输信号，每个波束方向都被认为是天线扇区。
4.2.说明性拓扑
图5图示了用于解释所提出技术的操作的示例网络场景实施例50。应当认识到的是，本公开不限于这个特定场景，因为本公开可以用在包含多于两个AP、任何期望数量的STA、STA和AP的任何相对方向以及具有广播区域的任何任意或固定边界的更大网络的场景中。在这个示例场景中，在房间或本地区域68中的两个基本服务集(BSS)内可以看到STA0(AP)52、STA5(AP)62和六个其它STA(STA1 54、STA2 56、STA3 58、STA4 60、STA6 64和STA766)。将注意到的是，基本服务集由已经成功地与网络中的AP同步的站(STA)的集合组成。每个STA可以与同一BSS中的其它STA通信。所有STA都使用CSMA/CA进行针对非RTA分组的随机信道接入。STA的位置及其传输链路如图所示。
4.3.站(STA)层模型
本公开将无线通信系统中的分组分类为或者RTA分组或者非RTA分组。RTA分组使用本公开进行分组传输，而非RTA分组可以使用常规的IEEE 802.11CSMA/CA方案。为此，STA在MAC层处识别RTA分组和非RTA分组。
图6图示了OSI模型中的RTA和非RTA业务通信的示例实施例70。在本节中，解释用于业务通信的STA层模型。如这个示例中所示，两个STA，STA1 72和STA2 74，生成RTA业务和非RTA业务80、82，并且用RTA分组84和非RTA分组86彼此通信。下面解释整个处理。
RTA业务和非RTA业务都是由发送者STA的APP层76a、78a生成的。发送者STA的APP层经由(通过)中间层76b、78b将RTA业务和非RTA业务传递到MAC层76c、78c。MAC层76c、78c和PHY层76d、78d将MAC报头和PLCP报头中的附加信号字段附加到分组，并且分组通过网络的PHY层被传输。
接收者STA在PHY层接收分组，将它们解码并且如果分组被正确解码择将其发送到其MAC层，之后数据通过(经由)中间层馈送到其APP层。
4.4.用于识别RTA和非RTA分组的机制
所公开的技术将无线通信系统中的分组分类为或者RTA或者非RTA。RTA分组使用立即重传方案进行分组重传，而非RTA分组可以使用常规CSMA/CA方案。为此，STA在MAC层处识别RTA分组和非RTA分组。
根据图6中所示的STA层模型，发送者STA的MAC层有可能识别来自上层的RTA业务和非RTA业务并将它们分别打包成RTA分组和非RTA分组。本节提供发送者STA如何使用在先协商识别RTA业务的细节。
根据图6中所示的STA层模型，发送者STA通过网络的PHY层将分组传输到接收者STA。当接收者STA在MAC层接收到分组时，它能够基于嵌入在MAC报头或PLCP报头中的信息来识别RTA分组和非RTA分组。本节提供有关接收者STA如何基于PLCP或MAC报头信息识别RTA分组的细节。
必须在给定的生命周期内传送RTA业务以确保数据的有效性。换句话说，如果接收者在这个生命周期到期之前没有接收到RTA业务，那么该RTA业务是无效的并且可以被丢弃。STA将RTA业务打包成RTA分组，以便通过PHY层传输。因此，RTA分组也有用于传输的生命周期。本节提供有关STA如何应对RTA分组的生命周期到期的细节。
4.4.1.在先协商
常常，RTA以面向连接的通信的方式周期性地生成业务。由应用在STA之间建立的面向RTA连接的通信被称为RTA会话。STA有可能在网络中可以具有多个RTA会话。根据本公开的每个STA能够适当地管理那些RTA会话。
在RTA会话开始传输RTA业务之前，在发送者STA和接收者STA之间发生在先协商以建立连接。在这个在先协商期间，发送者STA和接收者STA记录RTA会话和RTA会话识别信息，RTA会话识别信息可以被用于识别发送者侧的MAC层的RTA业务和接收者侧的MAC层的RTA分组。
如图6中所示，当APP层将业务传递到发送者侧的MAC层时，中间层向业务添加报头信息。当发送者STA的MAC层从上层接收业务时，它从上层提取报头信息并查找(搜索)由在先协商创建的RTA会话记录。如果报头信息与记录中的一个RTA会话匹配，那么业务是RTA；否则，业务被认为是非RTA。表1中列出了可以被用于识别RTA业务的报头信息。在本节中，描述在先协商的细节。
根据在先协商结果，接收者STA也可以按用于分组传输的信道资源(诸如时间、频率和其它度量)对RTA分组和非RTA分组进行分类。当使用为RTA分组准许的信道资源接收到分组时，STA将其识别为RTA分组。否则，该分组是非RTA分组。当分组以多用户上行链路模式被传输时，将使用这个场景，如第4.6.2.2中所解释的。
图7图示了用于在发送者侧92和接收者侧94处的RTA业务分组的在先协商的示例实施例90。应当认识到的是，一个在先协商建立一个RTA会话并且可以被用于由那个RTA会话生成的所有RTA分组。该图示出了在STA层模型中在两个STA之间建立RTA会话的在先协商，如图6中所看到的。发送者STA 92被示为具有层APP96a、中间层96b、MAC层96c和PHY层96d，接收者STA 94具有相同的层APP 98a、中间层98b、MAC层98c和PHY层98d。下面解释在先协商的处理。
参考图7，看到以下步骤。发送者92的APP层96a请求104资源(例如，时间、信道)协商。因此，在发送者STA侧，APP层起动RTA会话并为其RTA业务传输请求关于信道资源(诸如时间和带宽)的协商。这个协商请求从APP层的管理实体传输到MAC层中的管理实体。
发送者STA的MAC层从上层接收协商请求并在其一侧检查106资源可用性。而且，它还记录由上层提供的用于识别会话中的RTA业务的RTA会话识别信息。识别信息的记录可以从表1中列出的信息中挑选，诸如TCP/UDP端口号、服务的类型。也可以拒绝来自上层的请求，如果资源不可用，或者与上层重新协商。
如果发送者STA的MAC层发现可用资源，那么它向接收者STA的MAC层发送108协商请求帧。协商帧包含RTA会话的识别信息，以便接收者可以记录并且以后使用它。
在接收者STA的MAC层接收到协商请求帧之后，它首先通过从MAC层中的管理实体向APP层中的管理实体发送协商请求来通知110其APP层准备好接收RTA分组。如果APP层不可用于RTA传输，那么协商可能会失败。
接收者的APP层准许其层的资源可用性，并将这个信息从APP层中的管理实体发送112到驻留在MAC层中的管理实体。
然后，接收者STA的MAC层在其侧检查114资源可用性。如果资源不可用，那么MAC层可以拒绝或重新协商。接收者STA的MAC层收集其侧的所有协商信息并将其报告116给发送者的MAC层。
发送者的MAC层接收协商结果并将其转发118到其APP层。如果协商成功，那么APP层可以开始使用由双方STA准许的资源传输RTA业务。
根据由在先协商创建的RTA会话记录，发送者STA的MAC层通过来自上层的报头信息识别RTA业务和非RTA业务。当APP层生成RTA业务时，RTA业务与由中间层提供的报头信息一起被传递到其MAC层。通过查找由在先协商创建的RTA会话记录，发送者STA能够使用那个报头信息来识别RTA业务并在MAC层将RTA业务打包成RTA分组。
图8图示了在发送者侧识别RTA分组业务的示例实施例130。例程开始132并且发送者STA的MAC层从上层接收业务134。MAC层提取136由上层嵌入的用于识别RTA业务的信息，并检查上层的报头信息(诸如服务的类型和TCP/UDP端口号)。
发送者STA的MAC层将来自上层的报头信息与通过在先协商创建的RTA会话记录进行比较(查找)138。对报头信息进行检查140。如果来自上层的报头信息与记录中的RTA会话匹配，那么用确定为RTA业务的业务到达方框144，否则用作为非RTA业务的业务到达方框142。在识别分组之后，处理结束146。
4.4.2.分组报头信息
图9图示了RTA会话识别信息格式的示例实施例150。当发送者STA生成RTA分组时，它在PLCP或MAC报头中添加附加的信号字段。当附加的信号字段包含RTA会话识别信息时，接收者STA可以使用PLCP或MAC报头中的RTA会话识别信息在MAC层区分RTA分组与非RTA分组。RTA会话识别信息的一个示例在图中示出。
图10图示了APP层和MAC层之间的报头信息交换180、182的示例实施例170。发送者STA 172被视为具有APP层176a、中间层176b、MAC层176c和PHY层176d。看到接收者STA 174具有相同的层APP层178a、中间层178b、MAC层178c和PHY层178d。
该图描绘了这个处理如何在STA层模型中的两个STA之间工作的细节。发送者STA的APP层生成184RTA业务并将其传递到MAC层。当业务通过中间的层时，报头信息(诸如“服务的类型”字段和TCP/UDP端口号)被添加到业务中。
当发送者STA的MAC层从上层接收到RTA业务时，它从业务中提取报头信息(诸如服务的类型和TCP/UDP端口号)。通过查找由现有技术创建的RTA会话记录，MAC层识别186业务是RTA业务。
然后，发送者STA的MAC层将业务打包成RTA分组180并将服务的类型和TCP/UDP端口号嵌入MAC报头或PLCP报头中作为RTA会话识别信息。图9中示出了RTA会话识别信息的一个示例。接下来，发送者STA将RTA分组发送188到接收分组182的接收者STA。
当接收者STA在其MAC层接收到RTA分组时，它可以基于PLCP或MAC报头中的RTA会话识别信息来识别189RTA分组。
图11图示了用于在MAC层识别接收者侧的RTA分组的处理的示例实施例190。该处理开始192并且接收者在PHY层194接收分组。如图10中所解释的，RTA分组的MAC报头或PLCP报头包括RTA会话的识别信息。再次参考图11，进行检查196以确定识别信息是否存在。如果识别信息存在，那么执行移动到方框200，因为接收者STA已经确定该分组是RTA分组。否则，如果该信息不存在，那么执行从方框196移动到198，因为已经确定该分组是非RTA分组。之后处理结束202。
4.5.RTA接口
4.5.1.参考模型
当RTA用户发起RTA会话时，发起过程由应用层启动并在MAC层处执行，如图7中所解释的。有两种类型的通信。一种类型的通信发生在一个STA中的不同网络层之间。另一种类型的通信发生在两个STA之间。
图12图示了用于所公开的RTA管理的互通模型的示例实施例210。该图图示了RTA用户214和其它更高层214。MAC子层216被示为在它与更高层214之间具有MAC服务接入点(SAP)218。看到用于PHY层的相似SAP 220连接到物理(PHY)和物理介质相关(PMD)子层222。MAC层管理实体(MLME)224被示为用于在MAC子层216中通信，并且通过MLME到PHY层管理实体(PLME)SAP 226到PLME 228。在图中的右下方看到具有用于与RTA用户212通信的RTA管理功能232的站管理实体(SME)230。此外，看到SME具有用于与MLME通信的MLME SAP 234和用于与PLME 228通信的PLME SAP 236。
在操作中，当一个STA的不同网络层之间的通信发生时，RTA用户可以通过跨层接口来管理RTA活动。RTA用户可以与MAC层和更高层(诸如APP层)通信并交换信息。
在APP层处RTA用户可以向MAC层提供多个RTA服务。例如，STA可以提供：(a)RTA事件服务，诸如RTA会话管理；(b)RTA命令服务，诸如RTA队列设置；以及(c)RTA信息服务，诸如RTA KPI测量。
RTA用户可以在MAC层处通过站管理实体(SME)230的RTA管理232来传递那些服务请求。然后，根据请求信息，SME能够通过MAC子层管理实体服务接入点(MLME SAP)接口234在MAC层处采取动作。
当两个STA之间发生通信时，RTA用户可以通过跨层接口传递消息并且让MAC在两个STA之间传输和接收帧。
除了RTA用户和SME之间的直接消息交换外，在APP层处RTA用户还有可能通过MAC状态通用收敛函数(MSGCF)与SME交换消息，从而可以经由在IEEE 802.11中定义的MSGCFSAP和MSGCF-SME SAP来转发消息。
图13图示了用于RTA管理的层管理模型的示例实施例250。该图描绘了SME 252、MLME 254和MAC子层256。看到RTA管理258(在图12中示为方框232)具有用于RTA队列管理260、RTA KPI测量策略262和RTA会话管理264的模块。在MLME级别，看到用于RTA队列设置266a、外部RTA队列设置266b、RTA KPI测量266c、RTA KPI测量请求和报告266d以及RTA会话发起和破坏266e的功能集合。应当认识到的是，以上功能是作为具体实施例的示例给出的，而这些功能可以在不脱离本公开的教导的情况下被截断或扩展。看到一系列模块耦合到这些功能，如RTA队列操作协议270a、RTA队列设置框架270b、RTA KPI测量协议270c、RTA KPI测量帧270d和RTA会话事件270e。下面看到这些作为在MAC子层处耦合到队列结构276的用于RTA队列控制和监视274的功能。此外，看到MAC定时(TSF训练)方框272用于与方框270a至270e通信。
层管理在MLME和SME之间具有一定的功能划分。如图所示，驻留在SME 252中的RTA管理实体258表示管理决定，而驻留在MLME中的功能遵循来自SME的管理决定采取动作。SME中的RTA管理能够为RTA队列管理、RTA KPI测量策略和RTA会话管理做出决定并接收反馈。
当RTA管理实体258关于RTA会话管理264做出决定时，它调用MLME处的RTA会话事件功能270e。根据该决定，STA能够发起、重新发起或破坏266e与另一个STA的RTA会话。更多细节将在第4.5.2节中解释。
当RTA管理实体258关于RTA队列管理260做出决定时，它或者调用MLME处的RTA队列操作协议270a功能来控制MAC子层处的内部队列266a，或者调用MLME处的RTA队列设置帧功能270b以发送管理帧来设置外部队列266b。RTA队列操作协议功能270a能够向RTA管理实体258报告队列的状态。RTA队列设置帧功能270b能够从其它STA接收帧并将帧中的信息传递到RTA管理。更多细节在第4.5.3节中解释。
当RTA管理关于RTA KPI测量策略262做出决定时，它或者调用MLME处的RTA KPI测量协议功能270c以在MAC和PHY层处启动RTA KPI测量266c，或者调用MLME处的RTA KPI测量帧功能270d以向其它STA传输管理帧以在另一个STA处调度RTA KPI测量266d。RTA KPI测量协议功能270c能够向RTA管理258报告测量结果。RTA KPI测量帧功能270d可以从其它STA接收测量报告帧并向RTA管理传递报告。更多细节在第4.5.4节中解释。
当MLME处的功能根据由SME处的RTA管理做出的决定执行动作时，它可以使用MAC层处的时间戳(诸如TSF定时)作为时间参考。
4.5.2.RTA会话管理
本节解释STA如何通过使用SME处的RTA会话管理和MLME处的RTA会话事件功能之间的接口来发起、重新发起和破坏RTA会话。
图14图示了RTA会话信息的示例实施例290，包括识别信息292、状态信息294、要求信息296、传输信息298、队列信息300和测量信息302。
当两个STA建立RTA会话时，它们需要为RTA会话交换信息。该图示出了RTA会话信息的示例。内容包含以下消息和字段。
识别信息292是来自MAC报头的识别信息，诸如源MAC地址和目的地MAC地址，即，来自MAC层之上的层，如表1中列出的，诸如会话ID、服务的类型、源IP地址、源端口、目的地IP地址和目的地端口。
状态信息294是包含诸如会话状态、评论和上次活动时间之类的状态的状态信息。会话状态示出RTA会话是否被设置为生成业务。表2列出了可能的RTA会话状态。当RTA会话状态是活动时，RTA会话已被启用并正在生成RTA业务。当RTA会话状态是非活动时，RTA会话被禁用并且不从用户生成RTA业务。当RTA会话状态是错误时，由于错误，RTA会话无法生成或传输RTA业务。“评论”字段可以被用于示出RTA会话状态的细节。它可以被用于携带警告或错误消息。例如，当大量RTA分组在这个会话中被损坏时，评论可以示出传输质量差。它还可以被用于携带建议操作参数的信息，用于创建新的RTA会话。“上次活动时间”字段可以被用于触发某个事件以检查RTA会话的状态。每次针对RTA会话发生RTA分组传输时，上次活动时间都被更新。这个信息可以被用于跟踪RTA业务是否是定期生成或递送的。如果在特定时间段内未更新上次活动时间，那么RTA会话不在生成或递送RTA业务。应当检查RTA会话状态以确定是否发生了某个错误。
要求信息296包含关于要求信息的字段，包括带宽要求、延迟要求、抖动要求、周期性时间、会话开始时间和会话结束时间。“带宽要求”字段指示要传输的RTA业务的量。当STA测量信道带宽时，它可以将测得的带宽与所需的带宽进行比较。带宽测量的细节在第4.5.4.2.1节中解释。如果测量结果不能满足要求，那么STA可以拒绝RTA会话发起。
“延迟要求”字段指示RTA分组的传输延迟。当STA测量分组传输时延时，它可以将测得的时延与所需的延迟进行比较。时延测量的细节在第4.5.4.2.2节中解释。如果测量结果不能满足要求，那么STA可以拒绝RTA会话发起。
“抖动要求”字段指示在每个周期性传输时间期间RTA分组延迟的最大差异。当STA测量分组传输时延时，它可以获得抖动信息并将其与抖动要求进行比较。时延测量的细节在第4.5.4.2.2节中解释。如果测量结果不能满足要求，那么STA可以拒绝RTA会话发起。
周期性时间表示直到RTA会话生成一次RTA业务的持续时间；即，RTA会话每个周期性时间生成业务。“会话开始时间”字段和“结束时间”字段指示RTA会话的开始时间和结束时间。
传输信息298是包括用于时间分配、RU分配和SS分配的字段的传输信息消息。“时间分配”字段指示分发给RTA会话进行传输的信道时间的量。
“RU分配”字段指示分发给RTA会话进行传输的信道的资源单元(RU)。RU是IEEE802.11ax中使用的OFDMA术语中的单位。RU确定使用哪个信道频率用于传输。
“SS分配”字段指示用于RTA会话业务传输的空间流分配。SS分配可以是IEEE802.11中使用的MIMO术语中的单位，或者是波束赋形术语中定向天线方向图的索引。
队列信息300提供队列信息并且包含包括初始队列类型、生命周期、RTA优先级的字段。初始队列类型指示当RTA会话生成业务时应当将业务推送到哪个队列。生命周期表示RTA分组可以存储在队列处的时间。当生命周期到期时，分组被丢弃。在根据本公开的至少一个实施例的一种模式中，首先传输更接近其到期时间的RTA分组。“RTA优先级”字段指示RTA分组的优先级。在根据本公开的至少一个实施例的一种模式中，应当首先传输具有更高优先级的RTA分组。
测量信息302-测量信息具有包括测量指示、RTA KPI测量方法、RTA KPI测量报告的字段。“测量指示”子字段可以被实现为一位指示。当它被设置为第一状态(例如，“1”)时，STA在发起RTA会话之前请求RTA KPI测量；但是，当它被设置为第二状态(例如，“0”)时，RTA会话发起不请求RTA KPI测量。
“RTA KPI测量方法”字段指示在RTA会话发起过程期间应当启动哪些类型的RTAKPI测量。测量的若干示例将在第4.5.4.2节中提供。“RTA KPI测量报告”字段携带RTA KPI测量结果。
4.5.2.1.RTA会话发起
图15A至图15C图示了例示发起者312和接收方之间的RTA会话发起和消息交换的完整过程的示例实施例310，发起者312和接收方各自具有APP层316、326、SME层318、324、MLME层320、322。将注意到的是，实际消息是在这两个STA的MAC层之间交换的。
当始发者STA的RTA用户决定(确定)发起RTA会话328时，它向其SME传递如表3中所示的RTASESSIONEVENT.request消息330。然后SME需要发起RTA会话332，诸如通过首先测量RTA KPI以确保信道资源可用于建立RTA会话。始发者的STA处的SME的RTA会话管理做出决定并向MLME层320处的RTA KPI测量协议功能发送RTAKPIMEASURE.request消息334。RTAKPIMEASURE.request消息的格式在表30中解释。
然后，MLME根据RTAKPIMEASURE.request消息中的请求启动RTA KPI测量过程336。例如，如果始发者STA计划传输RTA分组，那么可以在此处执行如第4.5.4.2.1节中解释的信道带宽测量。RTA KPI测量过程在第4.5.4节中解释。在MLME完成测量过程之后，它发送如表31中解释的RTAKPIMEASURE.confirm消息338以报告测量结果。
当始发者STA的SME接收到RTA KPI测量结果时，它编译测量报告340并决定是否继续发起342RTA会话。例如，STA可以将RTA KPI测量结果(诸如信道带宽)与RTA会话的要求信息(如图14中定义的)进行比较。如果测量结果满足要求，那么它继续发起RTA会话。
如果STA决定继续RTA会话发起，那么始发者STA的SME处的RTA会话管理经由MLMESAP接口向MLME处的RTA会话事件功能发送RTASESSIONINIT.request消息344。RTASESSIONINIT.request消息的格式在表7中解释。
当始发者STA的MLME接收到RTASESSIONINIT.request消息时，它收集RTASESSIONINIT.request消息中的RTA会话信息并且向接收方STA发送RTA会话发起请求帧346。RTA会话发起请求帧格式在图16中示出。接收方STA 314的MLME接收该帧并经由MLMESAP接口向其SME生成如表8中所示的RTASESSIONINIT.indication消息348。
然后，SME层324将如表4中所示的RTASESSIONINITEVENT.indicate消息350传递到接收方STA的APP层处的RTA用户。如果在接收方STA的APP层处RTA用户确定352在图15B中遵循发起事件，那么它向SME层传递回如表5中所示的RTASESSIONINITEVENT.response消息354。在这个响应消息内，如果APP层已经决定继续发起，那么它在RTASESSIONINITEVENT.response消息中设置FollowEvent字段以指示遵循发起事件，例如在示例中通过将其设置为“1”。
然后SME继续遵循RTA会话发起356过程。如图4.4 1中所解释的，接收方STA需要检查信道资源可用性并确定是否准许RTA会话发起请求。为了做出这个确定，接收方STA需要测量它一侧的RTA KPI。RTA KPI测量的过程与始发者STA处相同，只是发送RTAKPIMEASURE.request消息358，响应于此，执行KPI测量处理360，并且RTAKPIMEASURE.confirm消息362被发送回SME。例如，如果接收方STA计划接收RTA分组，那么可以在此执行如第4.5.4.2.2节中解释的分组传输时延测量。编译364测量信息并且在图15C中做出366是否准许RTA会话发起的决定。
然后，接收方STA的SME向其MLME发送包含反馈信息的RTASESSIONINIT.response消息368。RTASESSIONINIT.response消息的格式在表9中解释。然后，接收方STA的MLME向始发者STA的MLME发送RTA会话发起响应帧370。始发者STA的MLME接收该帧并向其SME发送如表10中所示的RTASESSIONINIT.confirm消息372，使得该SME知晓374会话发起协定。始发者的SME然后通过RTASESSIONINITEVENT.confirm消息通知380RTA用户RTA会话的发起成功与否，这完成382RTA会话发起，相似的RTASESSIONINITEVENT.confirm消息378从接收方SME324发送到其在APP层处的用户。
始发者STA和接收方STA两者的SME都知晓RTA会话发起结果。他们经由如表6中所示的RTASESSIONINITEVENT.confirm消息将结果转发到APP层。
图16图示了具有以下字段的RTA会话发起请求帧格式的示例实施例390。“帧控制”字段指示帧的类型。“持续时间”字段包含用于CSMA/CA信道接入的NAV信息。“RA”字段包含帧的接收方的地址。“TA”字段包含传输帧的STA的地址。“动作”字段指示管理帧的类型；在这种情况下，它指示管理帧是RTA会话发起请求帧。
当“动作”字段指示帧是RTA会话发起请求帧时，在“动作”字段之后是“发起请求信息”字段。“发起请求信息”字段包含以下子字段。(a)“RTA会话ID”子字段识别RTA会话，其内容在图9中示出。(b)“资源要求”子字段包含RTA会话的要求信息，如图14中所述。(c)“队列信息”子字段为RTA会话提供队列信息，如图14中所述。(d)“测量指示”子字段指示对于RTA发起是否要求测量，并且可以被实现为一位指示。当这个字段被设置为第一状态(例如，“1”)时，对于RTA会话发起要求测量，而当这个字段被设置为第二状态(例如，“0”)时，不要求测量。(e)“RTA KPI测量方法”子字段携带关于如何在接收方STA处测量RTA KPI的信息。这个字段可以使用第4.5.4.2节中所示的格式。例如，这个字段可以是分组传输时延测量，如第4.5.4.2.2节的图37中解释的。
图17图示了RTA会话发起应答帧的示例实施例410。“帧控制”字段指示帧的类型。“持续时间”字段包含用于CSMA/CA信道接入的NAV信息。“RA”字段包含帧的接收方的地址。“TA”字段包含传输帧的STA的地址。“动作”字段指示管理帧的类型，在这种情况下它指示管理帧是RTA会话发起应答帧。
当“动作”字段指示该帧是RTA会话发起应答帧时，在“动作”字段之后是“发起响应信息”字段，并且包含以下子字段。“RTA会话ID”子字段提供用于RTA会话的识别信息。这个字段的内容在图9中示出。“发起结果”子字段提供指示(例如，一位)以示出是否准许发起。当这个字段被设置为第一状态(例如，“1”)时，发起被另一个STA准予；否则，这个字段被设置为第二状态(例如，“0”)。“传输信息”子字段提供RTA会话的传输信息，如图14中所述。“状态信息”子字段包含用于RTA会话的状态信息，如图14中所述。“测量指示”子字段指示是否包括测量结果。举例来说，当这个字段被设置为第一状态(例如，“1”)时，包括测量结果，而当这个字段被设置为第二状态(例如，“0”)时，不包括测量结果。“RTA KPI测量报告”子字段携带RTA KPI测量结果。
图18A和图18B图示了用于执行RTA会话发起的替代过程的示例实施例430。在某些情况下，始发者STA在不与接收方STA协商的情况下发起RTA会话。该图提供了在两个STA之间进行消息交换以完成RTA会话发起的另一个示例。该图描绘了如图15A至图15C中的始发者和接收方之间的通信。
始发者STA的RTA用户决定328发起RTA会话并且将RTASESSIONEVENT.request消息330传递给其SME。RTASESSIONEVENT.request消息330在表3中示出。然后SME需要在发起RTA会话之前确定332一些事情。首先，SME测量RTA KPI以确保有足够的信道资源可用于建立RTA会话。在这种情况下，始发者STA的SME处的RTA会话管理做出发起RTA会话的决定并且向MLME层处的RTA KPI测量协议功能发送RTAKPIMEASURE.request消息334。RTAKPIMEASURE.request消息的格式在表30中解释。
然后MLME根据RTAKPIMEASURE.request消息中的请求启动RTA KPI测量过程336。例如，如果始发者STA计划传输RTA分组，那么此时可以执行如第4.5.4.2.1节中解释的信道带宽测量。RTA KPI测量过程在第4.5.4节中解释。在MLME完成测量过程之后，它发送如表31中解释的RTAKPIMEASURE.confirm消息338以报告测量结果。
当始发者STA的SME在图18B中接收并编译340RTA KPI测量结果时，它决定342是否建立RTA会话。例如，STA可以将RTA KPI测量结果与RTA会话的要求信息(如图14中定义的)进行比较。如果测量结果满足要求，那么确定建立RTA会话。
如果STA决定建立RTA会话发起，那么发起者STA的SME处的RTA会话管理经由MLMESAP接口向MLME处的RTA会话事件功能发送如表17中所示的RTASESSIONANNOUNCE.request消息432。当始发者STA的MLME接收到RTASESSIONANNOUNCE.request消息时，它收集RTASESSIONANNOUNCE.request消息中的RTA会话信息并向接收方STA发送RTA会话公告请求帧434。RTA会话公告请求帧的格式在图25中示出。接收方STA的MLME接收该帧并经由MLMESAP接口向其SME生成如表18中所示的RTASESSIONANNOUNCE.confirm消息436。
始发者STA和接收方STA两者的SME都知晓438、442RTA会话发起结果。他们经由RTASESSIONINITEVENT.confirm消息440、444将结果转发其相应的APP层，从而完成RTA会话发起446。RTASESSIONINITEVENT.confirm消息如表6中所示。
表11示出了当考虑图5中的网络拓扑时由STA 0处的RTA会话发起过程创建的RTA会话表的示例。表中的RTA会话可以包含图14中列出的所有信息。为了使RTA会话表更易于理解，该表仅包含图14中列出的RTA会话信息的一部分。如表11中所示在STA 0(AP)处的RTA会话表包含三个RTA会话。表中的每一列表示RTA会话。会话ID被简化为索引号。
“第一会话ID”列表示RTA会话1(简化的会话ID)，其将RTA业务从STA 0传输到STA2。RTA会话1在1ms(会话开始时间)开始并且在900ms(会话结束时间)结束。每次RTA会话生成业务时，STA 0都具有完全的灵活性来分配信道时间(时间分配选项)、RU(RU分配选项)和空间流(SS分配选项)。RTA会话1的周期性时间是0ms，这意味着RTA会话1每10ms生成RTA业务。RTA优先级是5并且它将通过VI队列被传输。会话状态是活动，这意味着RTA会话发起成功完成并且会话正在生成RTA分组。
“第二会话ID”列表示RTA会话2，其将RTA业务从STA 3传输到STA 0。RTA会话2在3ms开始并且在800ms结束。每次RTA会话生成业务时，STA 0都具有完全的灵活性来分配信道时间(时间分配选项)、RU(RU分配选项)，但空间流(SS分配选项)必须是固定的。RTA会话2的周期性时间是20ms，这意味着RTA会话2每20ms生成RTA业务。RTA优先级是5并且它将通过VI队列被传输。会话状态是活动，这意味着RTA会话发起成功完成并且会话正在生成RTA分组。
“第三会话ID”列表示RTA会话3，其将RTA业务从STA 4传输到STA 0。RTA会话3在3ms开始并且在700ms结束。每次RTA会话生成业务时，STA 0都具有完全的灵活性来分配信道时间(时间分配选项)、RU(RU分配选项)和空间流(SS分配选项)。RTA会话3的周期性时间是0ms，这意味着RTA会话3不周期性地生成RTA业务。RTA优先级是6，高于其它两个RTA会话。由这个RTA会话生成的分组将通过VO队列传输。会话状态是活动，这意味着RTA会话发起成功完成并且会话正在生成RTA分组。
图19图示了被始发者STA拒绝的RTA会话发起的示例实施例470。如图18A和图18B中那样，APP、SME和MLME之间的通信发生在始发者侧，通信从APP层到SME和MLME直到SME编译测量340的点，然后不是如图18A和图18B中那样决定接受发起，而是在这个示例中它决定拒绝发起472。SME将RTASESSIONINITEVENT.confirm消息474传递到APP，其中InitiationSuccess字段被设置为“0”，以便当APP层处的RTA用户接收到这个消息时，知道RTA会话发起失败476。
图20A和图20B图示了被接收方STA拒绝的RTA会话发起的示例实施例490。如图18A和图18B中那样，APP、SME和MLME之间的通信发生在始发者侧，通信从APP层到SME和MLME直到图20B中SME编译测量340的点，并且在此它决定从接收方APP请求会话发起492。RTASESSIONINIT.request消息494被发送到MLME，MLME向接收方的MLME生成RTA会话发起请求帧496。接收方MLME接收这个输入并向其SME生成RTASESSIONINIT.indication消息498，其SME进而向APP层生成RTASESSIONINITEVENT.indication消息500。APP层决定拒绝发起502，并向其SME发送RTASESSIONINITEVENT.response消息504，指示发起被拒绝，其SME向其MLME发送RTASESSIONINIT.response消息506，其MLME向始发站的MLME发送RTA会话发起响应帧508。始发者MLME向其SME发送RTASESSIONINIT.confirm消息510，其SME向使RTA会话发起失败514的APP层发送包含发起拒绝的指示的RTASESSIONINITEVENT.confirm消息512。
表12示出了在STA 0和STA 1之间发起新的RTA会话之后STA0处的RTA会话表的示例。发起过程之前的RTA会话表在表11中示出。在此，新的RTA会话4被插入到RTA会话表中。会话ID表示简化的RTA会话识别信息。在新的RTA会话中，由于会话发起被STA 0拒绝，因此会话状态是错误。
4.5.2.2.RTA会话重新发起
图21A和图21B图示了用于RTA会话重新发起的过程的示例实施例530。当发起请求被接收方STA拒绝时，始发者STA能够重新发起RTA会话。该图示出了两个STA之间用于RTA会话重新发起的消息交换。除了两侧都跳过RTA KPI测量过程之外，RTA会话重新发起的过程与图15A至图15C中所示的RTA会话发起的完整过程相同。STA能够通过在消息中将MeasurementIndication参数设置为“0”来指示不需要测量。
当始发者STA的RTA用户决定(确定)发起RTA会话532时，它向其SME传递RTASESSIONEVENT.request消息534。然后由于该消息包含不需要测量的信息，因此SME立即开始发起536RTA会话并且经由MLME SAP接口向MLME处的RTA会话事件功能发送RTASESSIONINIT.request消息538。RTASESSIONINIT.request消息的格式在表7中解释。
当始发者STA的MLME接收到RTASESSIONINIT.request消息时，它收集RTASESSIONINIT.request消息中的RTA会话信息，并向接收方STA MLME发送RTA会话发起请求帧540。接收方STA的MLME接收该帧并经由MLME SAP接口向其SME生成如表8中所示的RTASESSIONINIT.indication消息542。
然后，接收方SME向接收方STA的APP层处的RTA用户传递如表4中所示的RTASESSIONINITEVENT.indicate消息544。如果在接收方STA的APP层处的RTA用户确定546允许发起事件，那么它生成如表5中所示返回SME层的RTASESSIONINITEVENT.response消息548。在这个响应消息内，它已将RTASESSIONINITEVENT.response消息548中的FollowEvent字段设置为“1”，因为APP层已决定继续发起。
然后如图21B中所看到的，SME继续遵循550RTA会话发起过程，并且它可以在没有测量的情况下继续进行，如从始发者侧指示的。做出决定552以准许RTA会话发起。接收方STA的SME向其MLME发送包含反馈信息的RTASESSIONINIT.response消息554。RTASESSIONINIT.response消息的格式在表9中解释。然后，接收方STA的MLME向始发者STA发送RTA会话发起响应帧556。始发者STA的MLME接收该帧并向其SME发送如表10中所示的RTASESSIONINIT.confirm消息558，该SME知晓560会话发起协定。发起者的SME然后通过发送RTASESSIONINITEVENT.confirm消息562向RTA用户通知RTA会话的发起是否成功，这完成564RTA会话发起。将注意到的是，接收方的SME类似地知晓566会话发起协定并向其APP层处的用户发送RTASESSIONINITEVENT.confirm消息568。
表13示出了在STA 0和STA 1之间重新发起RTA会话4之后STA 0处的RTA会话表的示例。发起过程之前的RTA会话表在表12中示出。RTA会话4的发起在RTA会话信息的“评论”字段中建议推迟会话开始时间，如图14中所示。因此在这种情况下，RTA会话4由STA1和STA0以新的会话开始时间重新发起。STA0准许RTA会话4的重新发起。
4.5.2.3.RTA会话破坏
图22图示了用于在发起者和接收方STA之间执行RTA会话破坏的过程的示例实施例590。当始发者STA的RTA用户决定592破坏(结束/关闭)RTA会话时，它向其SME传递RTASESSIONDESTRUCT.request消息594。然后，始发者STA的SME处的RTA会话管理开始破坏596会话并经由MLME SAP接口向MLME处的RTA会话事件功能发送RTASESSIONDESTRUCT.request消息598。RTASESSIONDESTRUCT.request消息的格式在表14中解释。当始发者STA的MLME接收到RTASESSIONDESTRUCT.request消息时，它收集RTASESSIONDESTRUCT.request消息中的RTA会话信息并向接收方STA发送RTA会话破坏请求帧600。RTA会话破坏请求帧的格式在图23中示出。接收方STA的MLME接收该帧并经由MLMESAP接口向其SME生成如表15中所示的RTASESSIONDESTRUCT.confirm消息602并将其转发604到接收方的APP层处的RTA用户。
图23图示了RTA会话发起请求帧的示例实施例610。“帧控制”字段指示帧的类型。“持续时间”字段包含用于CSMA/CA信道接入的NAV信息。“RA”字段包含帧的接收方的地址。“TA”字段包含传输帧的STA的地址。“动作”字段指示管理帧的类型；在这个示例中，它指示管理帧是RTA会话破坏请求帧。“RTA会话ID”字段指示RTA会话的识别信息，其在图9中示出。
表16示出了在RTA会话3被破坏之后STA 0处的RTA会话表的示例。发起过程之前的RTA会话表在表13中示出。
4.5.2.4.RTA会话公告
图24图示了用于执行RTA会话公告的过程的示例实施例630，其中STA能够将其RTA会话信息通知其相邻STA。在图中，看到共享RTA会话信息的两个STA之间的消息交换。一个STA如何与另一个STA共享RTA会话的细节描述如下。
当始发者STA的APP层处的RTA用户决定632共享或公告RTA会话时，它向这个发起者STA的SME处的RTA会话管理传递RTASESSIONANNOUNCE.request消息634，该RTA会话管理决定公告RTA会话636并且经由MLME SAP接口将消息转发638到MLME处的RTA会话事件功能。RTASESSIONANNOUNCE.request消息的格式在表17中解释。
当始发者STA的MLME接收到RTASESSIONANNOUNCE.request消息638时，它收集RTASESSIONANNOUNCE.request中的RTA会话信息并向接收方STA发送RTA会话公告请求帧640。RTA会话公告请求帧的格式在图25中示出。接收方STA的MLME接收该帧并经由MLME SAP接口向其SME生成如表18中所示的RTASESSIONANNOUNCE.confirm消息642。SME然后将这个消息644转发到APP层的RTA用户。
图25图示了具有以下字段的RTA会话公告帧格式的示例实施例650。“帧控制”字段指示帧的类型。“持续时间”字段包含用于CSMA/CA信道接入的NAV信息。“RA”字段包含帧的接收方的地址。“TA”字段包含传输帧的STA的地址。“动作”字段指示管理帧的类型，在这种情况下指示管理帧是RTA会话公告帧。
当“动作”字段指示帧是RTA会话公告帧时，在“动作”字段之后是“公告信息”字段。公告信息字段包含以下子字段。“RTA会话ID”子字段提供RTA会话的识别信息。这个“RTA会话ID”子字段的内容在图9中示出。“要求信息”子字段包含RTA会话的要求信息，如图14中所述。“传输信息”子字段为RTA会话提供传输信息，如图14中所述。“状态信息”子字段包含RTA会话的状态信息，如图14中所述。
表19示出了在STA5公告其建立RTA会话5之后STA 0处的RTA会话表的示例。发起过程之前的RTA会话表在表16中示出。
4.5.3.RTA队列管理
图26A和图26B图示了RTA队列参数设置的示例实施例670。本节解释STA如何通过SME的RTA队列管理与MLME处的RTA队列操作协议功能和RTA队列设置帧功能之间的接口设置队列参数。该图示出了当发起者STA在接收方STA处设置队列参数时两个STA之间的消息交换。
当始发者STA决定672设置接收方STA的RTA队列参数时，APP层处的RTA会话管理发送RTAQUEUEPARASETREQUEST.request消息674，然后经由MLME SAP接口将其转发676到MLME处的RTA会话事件功能。RTAQUEUEPARASETREQUEST.request消息的格式在表20中解释。
当始发者STA的MLME接收到RTAQUEUEPARASETREQUEST.request消息时，它收集RTAQUEUEPARASETREQUEST.request消息中的RTAQueuePara，并向接收方STA发送RTA队列参数设置请求帧678。RTA队列参数设置请求帧格式在图27中示出。接收方STA的MLME接收该帧并且在图26B中经由MLME SAP接口向其SME生成如表21中所示的RTAQUEUEPARASETREQUEST.indication消息680。
接收方STA的SME处的RTA会话管理然后将RTAQUEUEPARASET.request消息682传递到MLME层处的RTA队列操作协议功能以执行RTA队列参数设置684。RTAQUEUEPARASET.request消息的格式在表24中解释。然后MLME根据RTAQUEUEPARASET.request消息中的RTAQueuePara设置队列参数。
在MLME完成队列参数设置之后，它发送如表25中所示的RTAQUEUEPARASET.confirm消息686，以报告参数设置结果。然后，接收方STA的SME发送两个消息。SME向接收方APP层发送RTAQUEUEPARASETREQUEST.confirm消息688，以通知它队列的参数更新。SME还向其MLME发送包含参数设置结果的RTAQUEUEPARASETREQUEST.response消息690。RTAQUEUEPARASETREQUEST.response消息的格式在表22中解释。然后，接收方STA的MLME向始发者STA发送RTA队列参数设置响应帧692。始发者STA的MLME接收该帧并向其SME发送如表23中所示的RTAQUEUEPARASETREQUEST.confirm消息694。始发者的SME然后转发消息696以向RTA用户通知RTA会话的发起是否已经成功。
图27图示了具有以下字段的RTA队列参数设置请求帧的示例实施例710。“帧控制”字段指示帧的类型。“持续时间”字段包含用于CSMA/CA信道接入的NAV信息。“RA”字段包含帧的接收方的地址。“TA”字段包含传输帧的STA的地址。“动作”字段指示管理帧的类型，在这个示例中指示管理帧是RTA队列参数设置请求帧。
“RTA队列参数”字段包含具有以下子字段的RTA队列参数设置信息。“队列类型”子字段指示要设置其参数的队列的类型，诸如VO、VI、BE、BK。“最大缓冲区尺寸”子字段指示队列的最大缓冲区尺寸。“最大信道时间”子字段指示可以分配给队列的信道时间的最大比率。“RTA会话的最大数量”子字段指示其分组可以在RTA队列中等待的RTA会话的最大数量。“生命周期”子字段指示队列中分组的生命周期；当生命周期到期时，分组将被丢弃。“排序方法”子字段指示用于对队列中的分组进行排序的方法。“队列信道时间分配”子字段指示期间队列被允许传输分组的时间；它与用于周期性时间、开始时间、每个时段的持续时间和结束时间的子字段一起示出。
图28图示了具有以下字段的RTA队列参数设置响应帧的示例实施例730。“帧控制”字段指示帧的类型。“持续时间”字段包含用于CSMA/CA信道接入的NAV信息。“RA”字段包含帧的接收方的地址。“TA”字段包含传输帧的STA的地址。“动作”字段指示管理帧的类型；在这种情况下，它指示管理帧是RTA队列参数设置响应帧。“RTA队列参数设置结果”字段指示RTA队列参数设置是否成功。
图29和图30图示了响应于设置队列参数的RTA队列操作的示例实施例750、770。
在图29中看到按重要性指数对RTA分组进行排序的情况。该图解释STA如何设置排序方法以改变其VI队列中分组的传输次序的细节。看到VI队列按照RTA优先级752对分组进行排序，队列中具有最高RTA优先级的分组将首先被传输。该图给出了STA改变排序方法的示例756，在这个示例中按到期时间对分组进行排序754，示出了现在描绘的分组的不同排序次序，其中最短到期时间分组将首先被传输。
在图30中看到站如何将信道时间分配给不同队列的示例。每个周期性时间772，STA将单独的信道时间分配给不同的队列，诸如EDCA中的VO 774、VI 776、BE 778、BK队列780。当信道时间被分配给一个队列时，STA只传输来自那个队列的分组。
4.5.4.RTA KPI测量
4.5.4.1.一般场景
本节解释站如何通过使用在SME处的RTA会话管理与在MLME处的RTA KPI测量协议功能和RTA KPI测量帧功能之间的接口来测量RTA KPI的细节。
图31图示了示例实施例790，其描绘了发起者和接收方的MAC层之间的RTA KPI测量过程的示例场景，示出了当始发者STA在接收方STA处请求RTA KPI测量时的消息交换。
当始发者STA的APP处的RTA用户确定792请求接收方STA处的RTA KPI测量时，它向始发者STA的SME处的RTA会话管理发送RTAKPIMREQUEST.request消息794，该RTA会话管理经由MLME SAP接口将其转发796到MLME处的RTA KPI测量帧功能。RTAKPIMREQUEST.request消息的格式在表26中解释。当始发者STA的MLME解释到RTAKPIMREQUEST.request消息时，它收集RTAKPIMREQUEST.request消息796中的RTA KPI测量方法和报告方法并且始发者MLME向接收方STA MLME发送RTA KPI测量请求帧798。RTA KPI测量请求帧的格式在图32中示出。接收方STA的MLME接收该帧并经由MLME SAP接口向其SME生成如表27中所示的RTAKPIMREQUEST.indication消息800。
接收方STA的SME处的RTA会话管理然后向MLME层处的RTA KPI测量协议功能传递RTAKPIMEASURE.request消息802。RTAKPIMEASURE.request消息的格式在表30中解释。然后，MLME开始在RTA KPI测量处理804中测量RTA KPI。在MLME完成RTA KPI测量之后，它发送如表31中解释的RTAKPIMEASURE.confirm消息806以报告测量结果。
然后，接收方STA的SME编译KPI测量报告808并向其MLME发送包含测量结果的RTAKPIMREPORT.request消息810。RTAKPIMREPORT.response消息的格式在表28中解释。然后，接收方STA的MLME向始发者STA发送RTA KPI测量报告帧812。RTA KPI测量报告帧的格式在图33中示出。始发者STA的MLME接收该帧并向其SME发送如表29中所示的RTAKPIMREPORT.confirm消息814。始发者的SME然后向RTA用户转发这个消息816以提供RTAKPI测量结果。
图32图示了具有以下字段的RTA KPI测量请求帧格式的示例实施例830。“帧控制”字段指示帧的类型。“持续时间”字段包含用于CSMA/CA信道接入的NAV信息。“RA”字段包含帧的接收方的地址。“TA”字段包含传输帧的STA的地址。“动作”字段指示管理帧的类型；在这种情况下，它指示管理帧是RTA KPI测量请求帧。“RTA KPI测量方法”字段指定如何测量RTA KPI。这个字段的格式的若干示例在第4.5.4.2节中解释。“RTA KPI报告方法”字段指定如何报告RTA KPI。在至少一个实施例中，这个字段可以被实现为一位指示。当这个字段被设置为第一状态(例如，“1”)时，在RTA KPI测量完成之后立即传输报告；否则，当这个字段被设置为第二状态(例如，“0”)时，报告将在稍后被传输。
图33图示了具有以下字段的RTA KPI测量报告帧格式的示例实施例850。“帧控制”字段指示帧的类型。“持续时间”字段包含用于CSMA/CA信道接入的NAV信息。“RA”字段包含帧的接收方的地址。“TA”字段包含传输帧的STA的地址。“动作”字段指示管理帧的类型，在这种情况下它指示管理帧是RTA KPI测量报告帧。“RTA KPI测量报告”字段携带RTA KPI测量结果。这个字段的格式取决于RTA KPI测量方法。这个字段的格式的若干示例在第4.5.4.2节中提供。
4.5.4.2.RTA KPI测量的示例
4.5.4.2.1.信道带宽测量
本节示出了使用RTA KPI测量过程测量信道带宽的示例。
图34图示了用于信道带宽测量的RTA KPI测量方法字段格式的示例实施例870。该图图示了在RTA KPI测量过程期间STA请求测量信道带宽时图32中所示的“RTA KPIs测量方法”字段的内容。“测量代码”字段指示RTA KPI测量的类型，在这种情况下它指示RTA KPI测量是信道带宽测量。“开始时间”字段指示测量的开始时间。“结束时间”字段指示测量的结束时间。“超时”字段指示STA传输分组以测量信道状况所需的最长间隔。
图35图示了当STA在RTA KPI测量过程期间报告信道带宽测量结果时图33中所示的“RTA KPI测量报告”字段的内容的示例实施例890。“测量代码”字段指示RTA KPI测量的类型，在这种情况下它指示RTA KPI测量是信道带宽测量。“信道带宽测量时间”字段指示测量的持续时间。“最佳吞吐量调制和编码方案(MCS)”字段指示STA可以用来实现其最高吞吐量的估计MCS。“最佳吞吐量MCS的PER”字段指示当使用最佳吞吐量MCS进行传输时的分组错误率。“次佳吞吐量MCS”字段指示STA可以用来实现次高吞吐量的估计MCS。“次佳吞吐量MCS的PER”字段指示当使用次佳吞吐量MCS进行传输时的分组错误率。
“最佳概率MCS”字段指示STA可以用来实现最低分组丢失的估计MCS。“最佳概率MCS的PER”字段指示当使用最佳概率MCS进行传输时的分组错误率。“平均信道接入延迟”字段指示STA花费在信道竞争上的平均时间。“信道接入延迟的偏差”字段指示STA在信道竞争上花费的时间的偏差。“传输时间”字段指示STA在测量期间的传输时间。“估计的信道带宽”字段指示估计的信道带宽。作为示例而非限制，对此的一种算法如下：(估计的信道带宽)＝(最佳吞吐量MCS)*(传输时间)/(信道带宽测量时间)。
图36A和图36B图示了信道带宽测量过程的示例实施例900。STA在开始时间开始902信道带宽测量。检查904STA是否在队列中具有要在超时前发送的分组。如果有分组，那么STA发送908来自队列中的分组；否则站生成906探测分组。在任一情况下，都到达方框910，在那里STA记录MCS、信道接入延迟、分组错误和分组的传输时间。检查912确定测量持续时间是否还没有到期。如果我们仍处于测量持续时间中，那么执行返回到方框904并且STA继续发送用于测量目的的分组。否则，持续时间已经到期并且执行到达方框914。
在方框914中，STA根据测量期间的记录计算最佳吞吐量MCS、次佳吞吐量和最佳概率MCS。最佳吞吐量MCS是具有MCS*(1-PERMCS)的最大值的MCS，其中PERMCS表示为MCS处的分组错误率。次佳吞吐量MCS是具有MCS*(1-PERMCS)的次最大值的MCS。最佳概率MCS是具有PERMCS的最低值的MCS。STA还在图36B中计算916测量期间分组的信道接入延迟的平均值和偏差。最后，在过程结束922之前，STA计算918STA在测量期间的总传输时间并使用图35中所示的格式生成920信道带宽测量报告。
4.5.4.2.2.分组传输时延
本节示出了使用RTA KPI测量过程测量分组传输时延的示例。
图37图示了用于分组时延测量的“RTA KPI测量方法”字段格式的示例实施例930。在图中看到当STA在RTA KPI测量过程期间请求测量分组传输时延时图32中所示的“RTAKPI测量方法”字段的内容。“测量代码”字段指示RTA KPI测量的类型；在这种情况下，它指示RTA KPI测量是分组时延测量。“开始时间”字段指示测量的开始时间。“结束时间”字段指示测量的结束时间。“超时”字段指示STA需要传输分组以测量信道状况的最长间隔。如果STA在超时之前没有要传输的分组，那么它生成并传输用于时延测量的探测分组，如图39A的976中所示。
图38图示了用于分组时延测量的“RTA KPI测量报告”字段格式的示例实施例950。在图中看到在RTA KPI测量过程期间当STA报告分组传输时延测量结果时图33中所示的“RTA KPIs测量报告”字段的内容。“测量代码”字段指示RTA KPI测量的类型；在这种情况下，它是分组传输时延测量。“平均传输时延”字段指示测量期间的平均分组传输时延。“抖动”字段指示测量期间分组传输时延的标准偏差。“最大传输时延”字段指示测量期间的最大分组传输时延。
图39A和图39B图示了分组时延测量过程的示例实施例970。为了说明的简化起见，在这个示例中假设发送者STA和接收者STA的定时充分良好地同步，诸如可以在IEEE802.1AS下实现，但是在不脱离本公开的教导的情况下系统可以被配置为同步和/或克服同步问题。
接收者STA在开始时间以信道带宽测量开始972，并且通过发送与图32相似的具有如图37中所示的“RTA KPI测量方法”字段的帧来通知974发送者STA开始测量。进行检查976以确定发送者STA是否在队列中具有要在超时之前发送的分组。如果队列中有分组，那么发送者STA准备980发送来自队列中的分组。否则，如果在方框976处确定队列中没有分组，那么STA生成978要发送的探测分组。然后在任一情况下，执行到达方框980，其中发送者STA发送982具有嵌入在分组中的当前TSF时间戳的分组。当接收者STA接收到分组时，它可以通过计算分组中的TSF定时与当前TSF定时之间的差(增量)来确定分组传输时延984。
图39B中的检查986然后确定测量是否仍在进行中。如果测量尚未结束，那么执行返回到方框976，发送者STA继续发送用于测量目的的分组。否则，如果在方框986确定测量持续时间已经到期，那么接收者STA计算988平均时延、抖动和最大时延，之后，在过程结束992之前，STA使用如图38中所示的格式生成分组传输时延测量报告990。
4.5.4.2.3.信道使用情况
本节描绘响应于执行RTA KPI测量过程而测量信道使用情况的示例。
图40图示了图32中所示的“RTA KPI测量方法”字段格式的示例实施例1010，用于在RTA KPI测量过程期间当STA请求测量信道使用情况时进行信道使用情况测量。“测量代码”字段指示RTA KPI测量的类型。在这个示例实例中，RTA KPI测量是信道使用情况测量。“开始时间”字段指示测量的开始时间。“结束时间”字段指示测量的结束时间。
图41图示了当STA在RTA KPI测量过程期间报告分组传输时延测量结果时图33中所示的“RTA KPI测量报告”字段的内容的示例实施例1030。“测量代码”字段指示RTA KPI测量的类型；在此它指示RTA KPI测量是信道使用情况测量。“信道带宽测量时间”字段指示测量持续时间。“平均NAV时间”字段指示测量期间NAV时段的平均时间。“NAV时间的偏差”字段指示测量期间NAV时段的时间的偏差。“由于802.11分组引起的平均空闲信道评估(CCA)忙时间”字段指示测量期间由于802.11分组传输引起的CCA忙时段的平均时间。“由于802.11分组引起的CCA忙时间的偏差”字段指示在测量期间由于802.11分组传输引起的CCA忙时段的时间的偏差。“由于非802.11分组引起的平均CCA忙时间”字段指示在测量期间由于非802.11分组传输引起的CCA忙时段的平均时间。“由于非802.11分组引起的CCA忙时间的偏差”字段指示在测量期间由于非802.11分组传输引起的CCA忙时段的时间的偏差。“平均信道空闲时间”字段指示在测量期间信道空闲时段的平均时间。“信道空闲时间的偏差”字段指示在测量期间信道空闲时段的时间的偏差。
图42图示了信道使用情况测量过程的示例实施例1050。发送者STA在开始时间开始1052信道使用情况测量。STA停止传输分组并监视1054信道。STA记录1056NAV时间、由于802.11分组引起的CCA忙时间、由于非802.11分组引起的CCA忙时间，以及信道空闲时间。在测量的结束时间，STA根据在测量期间的记录来计算1058NAV时间的平均值和偏差、由于802.11分组引起的CCA忙时间、由于非802.11分组引起的CCA忙时间，以及信道空闲时间。STA然后使用如图41中所示的格式生成1060信道使用情况测量报告并且处理结束1062。
4.5.4.2.4.队列状态
本节示出了使用RTA KPI测量过程测量队列状态的示例。
图43图示了用于队列状态测量的“RTA KPI测量方法”字段格式的示例实施例1070。在RTA KPI测量过程期间当STA请求测量队列状态时“RTA KPIs测量方法”字段的内容在图32中示出。“测量代码”字段指示RTA KPI测量的类型；在这种情况下，它指示RTA KPI测量是队列状态测量。“开始时间”字段指示测量的开始时间，并且“结束时间”字段指示测量的结束时间。
图44图示了用于队列状态测量的“RTA KPI测量报告”字段格式的示例实施例1090。在RTA KPI测量过程期间当STA报告队列状态测量结果时“RTA KPIs测量报告”字段的内容在图33中示出。“测量代码”字段指示RTA KPI测量的类型；在这种情况下，它指示RTAKPI测量是队列状态测量。“队列的数量”字段指示其状态包括在这个报告中的队列的数量。“队列状态”字段1至N指示关于队列1至N的队列状态的测量结果。“状态”字段包括以下子字段。“队列类型”子字段指示队列的标识。“最大队列尺寸”子字段指示测量期间的最大队列尺寸。“最小队列尺寸”子字段指示测量期间的最小队列尺寸。“分组到达率”子字段指示在测量期间入队的分组的速率。“分组服务率”子字段指示在测量期间出队的分组的速率。“平均排队延迟”子字段指示在测量期间队列中分组的平均等待时间。“排队延迟的偏差”子字段指示在测量期间队列中分组的等待时间的偏差。
图45图示了队列状态测量过程的示例实施例1110。STA在开始时间开始1112队列状态测量。STA记录1114在测量期间每个队列的最大队列尺寸、最小队列尺寸、分组到达率和分组服务率。在测量的结束时间，STA计算1116在测量期间分组的排队延迟的平均值和偏差。STA使用如图44中所示的格式生成1118队列状态测量报告并且处理结束1120。
4.5.4.2.5.业务分析
本节描述使用RTA KPI测量过程的业务分析的示例。
图46图示了用于业务分析的“RTA KPI测量方法”字段格式的示例实施例1130。在RTA KPI测量过程期间当STA请求测量队列状态时“RTA KPIs测量方法”字段的内容在图32中示出。“测量代码”字段指示RTA KPI测量的类型；在这种情况下，它指示RTA KPI测量是队列状态测量。“开始时间”字段指示测量的开始时间。“结束时间”字段指示测量的结束时间。“超时”字段指示STA需要传输分组以测量信道状况的最长间隔。
图47图示了用于业务分析的“RTA KPI测量报告”字段格式的示例实施例1150。在RTA KPI测量过程期间当STA报告业务分析结果时“RTA KPIs测量报告”字段的内容在图33中示出。“测量代码”字段指示RTA KPI测量的类型；在这个示例中，它指示RTA KPI测量是业务分析测量。“业务类型的数量”字段指示在这个报告中被分析的业务类型的数量。
“业务类型状态”字段1至N指示每个业务类型的分析结果，并且具有以下子字段。“业务类型”子字段指示非RTA业务的接入类别或RTA业务的RTA优先级。“平均重试计数”子字段指示在测量期间分组的平均重试计数。“重试计数的偏差”子字段指示在测量期间分组的重试次数的偏差。“平均竞争时间”子字段指示在测量期间分组的平均竞争时间。“竞争时间的偏差”子字段指示在测量期间分组的竞争时间的偏差。“平均重传时间”子字段指示第一次重传的开始到最后一次重传的结束之间的平均时间。“重传时间的偏差”子字段指示第一次重传的开始到最后一次重传的结束的时间偏差。“分组错误率(PER)”子字段指示分组传输失败的概率。“业务的总量”子字段指示在测量期间的业务的总量(字节)。
图48图示了业务分析过程的示例实施例1170。STA在开始时间开始1172业务分析。进行检查1174以确定STA是否在超时之前有要传输的分组。如果有分组要传输，那么在到达方框1178之前在方框1176处它传输该分组并记录分组的AC/RTA优先级、长度、重试计数、竞争时间和重传时间。如果在方框1174处STA在超时之前没有要发送的分组或者STA完成了传输一个分组，那么执行从检查1174移至方框1178。
在方框1178处，检查测量持续时间是否仍在进行。如果测量还没有结束，那么执行返回到方框1174并且STA尝试传输用于测量目的的另一个分组。否则，如果在方框1178处确定测量时段已经结束，那么在方框1180处，STA计算每种业务类型的重试次数、竞争时间和重传时间的平均值和偏差、分组丢失和总量。STA使用如图47中所示的格式生成1182业务分析报告，处理结束1184。
4.5.4.3.RTA KPI测量的应用
图49图示了使用用于多链路传输的测量结果的示例实施例1210，在这种情况下使用用于RTA分组传输的RTA KPI测量。该图示出了如何使用RTA KPI测量结果来调度多个链路(multi-link)上的RTA分组传输。在图中示出了多个链路，在此作为示例而非限制看到四个链路，Link1 1212、Link2 1214、Link3 1216和Link4 1218。该图描绘了多个选项，在此作为示例而非限制可以看到四个选项，选项#11220、选项#2 1222、选项#3 1224和选项#41226。这个应用的目的是找到一些如图所示的多链路传输选项。当STA使用一个选项传输由RTA会话生成的RTA分组并且传输失败率低于RTA会话的分组丢失要求时，RTA分组的分组丢失满足要求并且不需要重传。
每个选项表示通过多链路同时传输复制的分组。每个链路上分组传输的MCS是固定的。例如，图中的选项#1 1220表示通过使用MCS 8的Link1 1212和使用MCS 5的Iink21214的分组1的同时多链路传输。选项#2 1222描述了通过使用MCS7的Link3 1216和通过使用MCS9的Link4 1218的分组2的同时多链路传输。选项中的多链路传输可能挑选多于两个链路进行传输，如选项#3 1224中所示，该选项描绘了通过使用MCS10的Link1 1212、通过使用MCS10的Link2 1214和通过使用MCS9的Link4 1218的分组3的同时多链路传输。
还有可能在选项中的相同链路上发生重复传输。例如，图中的选项#41226表示通过使用MCS11的Link1 1212和通过使用MCS3的Link31216的分组4的同时多链路传输。在图中将看到分组通过Link1被多次传输。
STA能够通过使用RTA KPI测量来估计使用一个选项的传输失败率。由pfail(Optioni)表示的选项i的多链路传输失败率是：
/>
其中Optioni表示在选项i(i＝1，2，...)中用于传输的链路的集合，pfail(linkj)表示在链路j(j＝1，2，3，...)处的传输失败率。链路j处的传输失败率可以通过下式计算：
pfail(linkj)＝(pfail(MCSk，linkj))n
其中pfail(MCSk，linkj)表示当在链路j上使用MCS k(k＝0，1，2，...)传输分组时的分组错误率，并且n表示重复分组传输的数量。分组错误率可以通过信道带宽测量来测量，如第4.5.4.2.1节中解释的。
当RTA会话的分组到达率时，STA能够使用选项来调度分组传输或轮询。而且，重试限制可以是0，因为不需要重传。
5.实施例的一般范围
所提出的技术中描述的增强可以容易地在各种无线通信站及其相关联的协议内实现。还应当认识到的是，通信站优选地被实现为包括一个或多个计算机处理器设备(例如，CPU、微处理器、微控制器、启用计算机的ASIC等)以及相关联的存储指令的存储器(例如，RAM、DRAM、NVRAM、FLASH、计算机可读介质等)，其中在处理器上执行存储在存储器中的编程(指令)以执行本文描述的各种处理方法的步骤。
为了说明的简单起见，并未在每一个图中描绘计算机和存储器设备，因为本领域的普通技术人员认识到使用计算机设备来执行与无线数据通信相关的步骤。就存储器和计算机可读介质而言，所呈现的技术是非限制性的，只要它们是非暂态的且因此不构成暂态电子信号即可。
还将认识到的是，这些计算系统中的计算机可读介质(存储指令的存储器)是“非暂态的”，其包括任何和所有形式的计算机可读介质，唯一的例外是暂态的、传播信号。因而，所公开的技术可以包括任何形式的计算机可读介质，包括随机存取的那些(例如，RAM)、要求定期刷新的那些(例如，DRAM)、随时间退化的那些(例如，EEPROMS、盘解释)，或者仅在短时间段内和/或仅在有电的情况下存储数据的那些，唯一的限制是术语“计算机可读介质”不适用于暂态的电子信号。
本技术的实施例在本文中可以参考根据本技术的实施例的方法和系统的流程图图示、和/或也可以被实现为计算机程序产品的过程、算法、步骤、操作、公式或其它计算描绘来描述。就这一点而言，流程图的每个方框或步骤、流程图中的方框(和/或步骤)的组合、以及任何过程、算法、步骤、操作、公式或计算描绘都可以通过各种手段来实现，诸如硬件、固件和/或包括包含在计算机可读程序代码中的一个或多个计算机程序指令的软件。如将认识到的，任何这样的计算机程序指令都可以被一个或多个计算机处理器(包括但不限于通用计算机或专用计算机、或产生机器的其它可编程处理装置)执行，以使得在(一个或多个)计算机处理器或其它可编程处理装置上执行的计算机程序指令创建用于实现所指定的(一个或多个)功能的手段。
因而，本文描述的流程图的方框和过程、算法、步骤、操作、公式或计算描绘支持用于执行(一个或多个)指定功能的手段的组合、用于执行(一个或多个)指定功能的步骤的组合，和用于执行(一个或多个)指定功能的计算机程序指令(诸如实施在计算机可读程序代码逻辑手段中)。还将理解的是，本文描述的流程图图示的每个方框以及任何过程、算法、步骤、操作、公式或计算描绘及其组合可以由执行指定的(一个或多个)功能或(一个或多个)步骤的基于专用硬件的计算机系统或专用硬件和计算机可读程序代码的组合来实现。
此外，诸如实施在计算机可读程序代码中的这些计算机程序指令也可以存储在一个或多个计算机可读存储器或存储器设备中，其可以指导计算机处理器或其它可编程处理装置以特定方式起作用，使得存储在计算机可读存储器或存储器设备中的指令产生包括实现在(一个或多个)流程图的(一个或多个)方框中指定的功能的指令手段的制品。计算机程序指令还可以由计算机处理器或其它可编程处理装置执行，以使得在计算机处理器或其它可编程处理装置上执行一系列操作步骤以产生计算机实现的处理，使得在计算机处理器或其他可编程处理装置上执行的指令提供用于实现在(一个或多个)流程图的(一个或多个)方框、(一个或多个)过程、(一个或多个)算法、(一个或多个)步骤、(一个或多个)操作、(一个或多个)公式或(一个或多个)计算描绘中指定的功能的步骤。
还将认识到的是，本文使用的术语“编程程序”或“程序可执行”是指可以由一个或多个计算机处理器执行以执行如本文所述的一个或多个功能的一个或多个指令。指令可以被实施为软件、固件或软件和固件的组合。指令可以本地存储在非暂态介质的设备中，或者可以远程存储在诸如服务器上，或者可以本地和远程地存储全部或部分指令。远程存储的指令可以通过用户发起或者基于一个或多个因素自动地下载(推送)到设备。
还将认识到的是，如本文所使用的，术语处理器、计算机处理器、中央处理单元(CPU)和计算机被同义地使用来表示能够执行指令以及与输入/输出接口和/或外围设备进行通信的设备，以及术语处理器、计算机处理器、CPU和计算机旨在包括单个或多个设备、单核和多核设备及其变形。
从本文中的描述将认识到的是，本公开包含多个实施例，所述多个实施例包括但不限于以下实施例：
1.一种用于在网络中无线通信的装置，该装置包括：(a)无线通信电路，用于通过信道与位于其接收区域中的至少一个其它无线局域网(WLAN)站无线通信；(b)处理器，耦合到被配置用于在WLAN上操作的站(STA)内的所述无线通信电路；(c)非暂态存储器，存储处理器可执行的指令；(d)其中所述指令在由处理器执行时执行一个或多个步骤，包括：(d)(i)将所述无线通信电路作为WLAN站进行操作，该WLAN站被配置为支持传送对通信延迟敏感的实时应用(RTA)分组以及非实时分组，以及将实时应用(RTA)分组与非实时应用(非RTA)分组区分开来；(d)(ii)其中所述指令配置有生成和接收应用数据的应用(APP)层、确定到端到端对等无线通信电路和下一跳对等无线通信电路设备的路由的网络层、用于控制无线介质访问协议的介质访问控制(MAC)层、用于向下一跳对等无线通信电路传输和接收物理信号的物理(PHY)层，以及用于生成新的实时应用(RTA)会话并具有与MAC层管理实体(MLME)通信的接口的应用层；(d)(iii)由STA的应用(APP)层生成请求，以请求MAC层开始具有给定要求集的新会话；(d)(iv)由MAC层监视信道并获得关键性能指标(KPI)以得出对APP层的响应；(d)(v)由MAC层根据RTA会话要求和测得的KPI或者接受或者拒绝由APP层做出的开始新会话的请求；以及(d)(vi)如果新会话发起被拒绝，那么由APP层重新发出具有经调整的参数的新会话适应请求。
2.一种用于在网络中无线通信的装置，该装置包括：(a)无线通信电路，用于通过信道与位于其接收区域中的至少一个其它无线局域网(WLAN)站无线通信；(b)处理器，耦合到被配置用于在WLAN上操作的站(STA)内的所述无线通信电路；(c)非暂态存储器，存储处理器可执行的指令；(d)其中所述指令在由处理器执行时执行一个或多个步骤，包括：(d)(i)将所述无线通信电路作为WLAN站进行操作，该WLAN站被配置为支持传送对通信延迟敏感的实时应用(RTA)分组以及非实时分组，以及将实时应用(RTA)分组与非实时应用(非RTA)分组区分开来；(d)(ii)其中所述指令配置有生成和接收应用数据的应用(APP)层、确定到端到端对等无线通信电路和下一跳对等无线通信电路设备的路由的网络层、用于控制无线介质访问协议的介质访问控制(MAC)层、用于向下一跳对等无线通信电路传输和接收物理信号的物理(PHY)层，以及用于生成新的实时应用(RTA)会话并具有与MAC层管理实体(MLME)通信的接口的应用层；(d)(iii)由STA的应用(APP)层生成请求，以请求MAC层开始具有给定要求集的新会话；(d)(iv)由MAC层监视信道并获得关键性能指标(KPI)以得出对APP层的响应；(d)(v)在MAC层处根据RTA会话要求和测得的KPI或者接受或者拒绝由APP层做出的开始新会话的请求；(d)(vi)其中，如果在MAC层处由APP层做出的开始新会话的请求被接受，那么APP层在MAC层处开始新的RTA会话，并且或者：(A)为RTA分组设置生命周期值以提供队列管理，或者(B)为RTA分组设置优先级值以提供队列管理，或者(C)为RTA分组设置请求的时延，或者(D)将RTA分组的目标分组丢失率或者设置为调整用于RTA分组的调制和编码方案(MCS)和重试限制的目标分组丢失率，或者设置为重复分组传输或多链路传输的目标分组丢失率；(d)(vii)如果新会话发起被拒绝，那么由APP层重新发出具有经调整的参数的新会话适应请求。
3.一种用于在网络中无线通信的方法，该方法包括：(a)将无线通信电路作为WLAN站进行操作，以用于通过信道与其接收区域中的至少一个其它无线局域网(WLAN)站无线通信，所述站被配置为支持传送对通信延迟敏感的实时应用(RTA)分组以及非实时分组，以及将实时应用(RTA)分组与非实时应用(非RTA)分组区分开来；(b)其中所述指令配置有生成和接收应用数据的应用(APP)层、确定到端到端对等无线通信电路和下一跳对等无线通信电路设备的路由的网络层、用于控制无线介质访问协议的介质访问控制(MAC)层、用于向下一跳对等无线通信电路传输和接收物理信号的物理(PHY)层，以及用于生成新的实时应用(RTA)会话并具有与MAC层管理实体(MLME)通信的接口的应用层；(c)由STA的应用(APP)层生成请求，以请求MAC层开始具有给定要求集的新会话；(d)由MAC层监视信道并获得关键性能指标(KPI)以得出对APP层的响应；(e)由MAC层根据RTA会话要求和测得的KPI或者接受或者拒绝由APP层做出的开始新会话的请求；(f)如果新会话发起被拒绝，那么由APP层重新发出具有经调整的参数的新会话适应请求；以及(g)其中所述方法是由执行存储在非暂态介质上的指令的处理器执行的。
4.一种执行分组的传输的无线通信系统/装置，其中应用层生成和接收应用数据，网络层确定到端到端对端通信设备和下一跳无线通信对等设备的路由，MAC层控制无线介质访问协议，PHY层向下一跳无线通信对等设备传输和接收物理信号，应用层具有与MAC层管理实体进行通信的接口，应用层在系统/装置中生成新的实时应用(RTA)会话，包括：(a)STA的应用层(APP层)请求MAC层开始带要求的新会话；(b)MAC层监视信道并获得关键性能指标(KPI)以得出对APP层的响应；(c)MAC层根据RTA会话要求和测得的KPI或者接受或者拒绝APP层的新会话适应；以及(d)如果新会话发起被拒绝，那么由APP层重新发出具有经调整的参数的请求。
5.任一前述实施例的装置、系统或方法，其中所述指令在由处理器执行时还执行一个或多个步骤，包括APP层在MAC层处开始新的RTA会话并且为RTA分组设置生命周期值以提供队列管理。
6.任一前述实施例的装置、系统或方法，其中所述指令在由处理器执行时还执行一个或多个步骤，包括APP层在MAC层处开始新的RTA会话并且为RTA分组设置优先级值以提供队列管理。
7.任一前述实施例的装置、系统或方法，其中所述指令在由处理器执行时还执行一个或多个步骤，包括APP层在MAC层处开始新的RTA会话并且为RTA分组设置目标分组丢失率。
8.任一前述实施例的装置、系统或方法，其中所述指令在由处理器执行时还执行一个或多个步骤，包括站的MAC层将目标分组丢失率设置为调整用于RTA分组的调制和编码方案(MCS)和重试限制的目标分组丢失率。
9.任一前述实施例的装置、系统或方法，其中所述指令在由处理器执行时还执行一个或多个步骤，包括站的MAC层将目标分组丢失率设置为用于复制分组传输或多链路传输的目标分组丢失率。
10.任一前述实施例的装置、系统或方法，其中所述指令在由处理器执行时还执行一个或多个步骤，包括APP层在MAC层处开始新的RTA会话并且为RTA分组设置请求的时延。
11.任一前述实施例的装置、系统或方法，其中所述指令在由处理器执行时还执行一个或多个步骤，包括MAC层监视信道并且测量信道的关键性能指标(KPI)。
12.任一前述实施例的装置、系统或方法，其中信道的所述关键性能指标(KPI)选自由带宽、调制和编码方案(MCS)、信道接入率、分组错误率(PER)以及信道用于传输分组的时间比率组成的性能指标的组。
13.任一前述实施例的装置、系统或方法，其中所述指令在由处理器执行时还执行一个或多个步骤，包括MAC层利用用于复制分组传输或多链路传输的测量结果来测量信道的所述关键性能指标(KPI)。
14.任一前述实施例的装置、系统或方法，其中所述指令在由处理器执行时还执行一个或多个步骤，包括监视信道的MAC层获得关于分组时延的所述关键性能指标(KPI)的统计数据并将它们与RTA请求的时延进行比较。
15.任一前述实施例的装置、系统或方法，其中所述指令在由处理器执行时还执行一个或多个步骤，包括MAC层在获得关于分组时延的所述关键性能指标(KPI)的统计数据并将它们与RTA请求的时延进行比较时利用MAC层处的时间戳。
16.任一前述实施例的装置、系统或方法，其中所述指令在由处理器执行时还执行一个或多个步骤，包括获得分组时延的统计数据的MAC层在发送者和接收者处都执行时延的测量。
17.任一前述实施例的装置、系统或方法，其中所述指令在由处理器执行时还执行一个或多个步骤，包括获得分组时延的统计数据的MAC层执行平均重传率的测量。
18.任一前述实施例的装置、系统或方法，其中所述指令在由处理器执行时还执行一个或多个步骤，包括MAC层在确定信道空闲之间的平均时间和标准偏差以及信道占用之间的平均时间时监视信道并测量分组到达率的关键性能指标(KPI)。
19.任一前述实施例的装置、系统或方法，其中所述指令在由处理器执行时还执行一个或多个步骤，包括MAC层利用对分组到达率的测量进行调度分组传输或基于RTA会话期间所请求的分组到达率来执行轮询。
20.任一前述实施例的装置、系统或方法，其中所述指令在由处理器执行时还执行一个或多个步骤，包括MAC层执行信道的监视并且测量队列状态的关键性能指标(KPI)。
21.任一前述实施例的装置、系统或方法，其中所述指令在由处理器执行时还执行一个或多个步骤，包括MAC层执行信道的监视并且测量包括当前队列尺寸的关键性能指标(KPI)。
22.任一前述实施例的装置、系统或方法，其中所述指令在由处理器执行时还执行一个或多个步骤，包括MAC层监视信道并且测量关键性能指标(KPI)以及记录关于分组业务的改变的历史信息。
23.任一前述实施例的装置、系统或方法，其中所述指令在由处理器执行时还执行一个或多个步骤，包括MAC层监视信道和测量关键性能指标(KPI)并将测得的KPI与RTA会话要求进行比较，并且如果测得的KPI不满足RTA会话要求，那么拒绝RTA会话发起。
24.任一前述实施例的装置、系统或方法，其中所述指令在由处理器执行时还执行一个或多个步骤，包括拒绝新的RTA会话的MAC层执行将在MAC层处获得的关键性能指标(KPI)报告给APP层。
25.任一前述实施例的装置、系统或方法，其中所述指令在由处理器执行时还执行一个或多个步骤，包括MAC层拒绝新的RTA会话并向APP层建议用于创建新的RTA会话的操作参数。
26.任一前述实施例的装置、系统或方法，其中APP层在MAC层处开始新的RTA会话可以设置可以被用于队列管理的RTA分组的生命周期。
27.任一前述实施例的装置、系统或方法，其中APP层在MAC层处开始新的RTA会话可以设置可以被用于队列管理的RTA分组的优先级。
28.任一前述实施例的装置、系统或方法，其中APP层在MAC层处开始新的RTA会话可以设置RTA分组的目标分组丢失率。
29.任一前述实施例的装置、系统或方法，其中APP层在MAC层处开始新的RTA会话可以设置RTA分组的请求的时延。
30.任一前述实施例的装置、系统或方法，其中监视信道的STA的MAC层可以测量信道的KPI，诸如带宽、MCS、信道接入率、分组错误率和信道被用于传输分组的时间比率。
31.任一前述实施例的装置、系统或方法，其中监视信道的STA的MAC层可以测量诸如分组时延的统计数据之类的KPI并将其与RTA请求的时延进行比较。
32.任一前述实施例的装置、系统或方法，其中监视信道的STA的MAC层可以测量诸如分组到达率之类的KPI，以获得信道空闲之间的平均时间、信道占用之间的平均时间及其标准偏差。
33.任一前述实施例的装置、系统或方法，其中监视信道的STA的MAC层可以测量队列状态的KPI，诸如当前队列尺寸。
34.任一前述实施例的装置、系统或方法，其中监视信道并获得KPI的STA的MAC层可以记录业务的改变的历史。
35.任一前述实施例的装置、系统或方法，其中监视信道并获得KPI的STA的MAC层可以将测得的KPI与RTA会话要求进行比较，并且如果测得的KPI不满足要求，那么拒绝RTA会话发起。
36.任一前述实施例的装置、系统或方法，其中MAC层拒绝新的RTA会话，可以向APP层报告在MAC层处获得的KPI。
37.任一前述实施例的装置、系统或方法，其中MAC层拒绝新的RTA会话，可以向APP层建议创建新RTA会话的操作参数。
38.任一前述实施例的装置、系统或方法，其中设置RTA分组的目标分组丢失率的STA的MAC层可以使用目标分组丢失率来调整RTA分组的MCS和重试限制。
39.任一前述实施例的装置、系统或方法，其中设置RTA分组的目标分组丢失率的STA的MAC层可以将目标分组丢失率用于重复分组传输或多链路传输。
40.任一前述实施例的装置、系统或方法，其中测量信道的KPI的STA的MAC层可以将测量结果用于重复分组传输或多链路传输。
41.任一前述实施例的装置、系统或方法，其中获得分组时延的统计数据的STA的MAC层可以在MAC层处使用时间戳。
42.任一前述实施例的装置、系统或方法，其中获得分组时延的统计数据的STA的MAC层可以测量发送者和接收者两者处的时延。
43.任一前述实施例的装置、系统或方法，其中获得分组时延的统计数据的STA的MAC层可以测量平均重传率。
44.任一前述实施例的装置、系统或方法，其中测量分组到达率的STA的MAC层可以使用该测量基于所请求的RTA会话的分组到达率来调度分组传输或轮询。
如本文所使用的，除非上下文中另有明确规定，否则单数术语“一”、“一个”和“该”可包括复数指示。除非明确说明，否则以单数形式提及对象并不旨在表示“一个与仅一个”，而是“一个或多个”。
在本公开中的短语构建体(诸如“A、B和/或C”)描述其中可以存在A、B或C，或项A、B和C的任何组合的情况。指示“至少一个”后跟着列出元素的短语构建体指示存在这些组元素中的至少一个，其包括这些列出的元素的任何可能组合(如适用的话)。
本说明书中对“实施例”、“至少一个实施例”或类似实施例措辞的引用指示结合所描述的实施例描述的特定特征、结构或特点包括在本公开的至少一个实施例中。因此，这些各种实施例短语不一定都是指同一个实施例，或是指不同于所描述的所有其它实施例的特定实施例。实施例措辞应当被解释为意味着给定实施例的特定特征、结构或特点可以以任何合适的方式组合在所公开的装置、系统或方法的一个或多个实施例中。
如本文所使用的，术语“集合”指的是一或多个对象的集合。因此，例如，对象的集合可以包括单个对象或多个对象。
如本文所使用的，术语“基本上”和“大约”被用来描述和解释小的变化。当与事件或情况一起使用时，该术语可以指事件或情况恰好发生的实例以及事件或情况发生到类似的实例。当与数值结合使用时，术语可以指小于或等于该数值的±10％的变化范围，诸如小于或等于±5％、小于或等于±4％、小于或等于±3％、小于或等于±2％、小于或等于±1％、小于或等于±0.5％、小于或等于±0.1％、或小于或等于±0.05％。例如，“基本上”可以指小于或等于该数值的±10°的角度变化范围，诸如小于或等于±5°、小于或等于±4°、小于或等于±3°、小于或等于±2°、小于或等于±1°、小于或等于±0.5°、小于或等于±0.1°、或小于或等于±0.05°。
此外，量、比率和其它数值有时可以以范围格式呈现于本文中。应当理解，这种范围格式是为了方便和简洁而使用的，并且应当被灵活地理解为包括明确指明为范围限制的数值，但是也包括包含在该范围内的所有单独数值或子范围，如同明确指明的每个数值和子范围。例如，大约1至大200的范围内的比率应当理解为包括明确列举的大约1和大约200的限制，但也包括单独的比率，诸如大约2、大约3和大约4，以及诸如大约10至大约50、大约20至大约100等子范围。
虽然本文的描述包含许多细节，但是这些细节不应当被解释为限制本公开的范围，而是仅仅提供一些当前优选实施例的说明。因此，将认识到的是，本公开的范围完全涵盖对于那些本领域技术人员变得显而易见的实施例。
本领域普通技术人员已知的所公开实施例的元素的所有结构和功能等同物通过引用明确地并入本文，并且旨在由本申请专利范围所涵盖。此外，无论元素、组件或方法步骤是否在申请专利范围中明确地陈述，本公开中的元素、组件或方法步骤都不旨在对公众专用。本文中的申请专利范围不应当被解释为“部件加功能”元素，除非使用短语“用于......的部件”明确地描述该元素。本文中的申请专利范围不应当被解释为“步骤加功能”元素，除非使用短语“用于......的步骤”明确地描述该元素。
表1
用于在发送者侧识别RTA业务的报头信息
层 报头信息
APP RTA会话ID、RTA会话名称、签名
传输 TCP/UDP端口号
网络 源和目的地的IP地址、服务的类型
表2
RTA会话状态的列表
状态 报头信息
活动 RTA会话是活动的以生成业务
不活动 RTA会话被禁用并且不生成业务
错误 会话有错误
表3
RTASESSIONINITEVENT.request消息格式
表4
RTASESSIONINITEVENT.indicate消息格式
表5
RTASESSIONINITEVENT.response消息格式
/>
表6
RTASESSIONINITEVENT.confirm消息格式
表7
RTASESSIONINIT.request消息格式
/>
表8
RTASESSIONINIT.indicate消息格式
/>
表9
RTASESSIONINIT.response消息格式
/>
表10
RTASESSIONINIT.confirm消息格式
表11
在STA 0(AP)处的RTA会话发起的示例
表12
RTA会话发起被拒绝的示例
/>
表13
RTA会话重新发起的示例
/>
表14
RTASESSIONDESTRUCT.request消息格式
表15
RTASESSIONDESTRUCT.confirm消息格式
表16
RTA会话破坏的示例
/>
表17
RTASESSIONANNOUNCE.request消息格式
表18
RTASESSIONANNOUNCE.confirm消息格式
表19
RTA会话公告的示例
/>
表20
RTAQUEUEPARASETREQUEST.request消息格式
表21
RTAQUEUEPARASETREQUEST.indicate消息格式
表22
RTAQUEUEPARASETREQUEST.response消息格式
表23
RTAQUEUEPARASETREQUEST.confirm消息格式
/>
表24
RTAQUEUEPARASET.request消息格式
表25
RTAQUEUEPARASET.confirm消息格式
/>
表26
RTAKPIMREQUEST.request消息格式
表27
RTAKPIMREQUEST.indicate消息格式
/>
表28
RTAKPIMREPORT.request消息格式
表29
RTAKPIMREPORT.confirm消息格式
/>
表30
RTAKPIMEASURE.request消息格式
表31
RTAKPIMEASURE.confirm消息格式
/>
/>

Claims (24)

1.一种用于在网络中无线通信的装置，该装置包括：
(a)无线通信电路，用于通过信道与位于其接收区域中的至少一个其它无线局域网(WLAN)站无线通信；
(b)处理器，耦合到被配置用于在WLAN上操作的站(STA)内的所述无线通信电路；以及
(c)非暂态存储器，存储处理器可执行的指令；
(d)其中所述指令在由处理器执行时执行下列步骤：
(i)将所述无线通信电路作为WLAN站进行操作，该WLAN站被配置为支持传送对通信延迟敏感的实时应用(RTA)
分组以及非实时分组，以及将实时应用(RTA)分组与非实时应用(非RTA)分组区分开来；
(ii)其中所述指令配置有生成和接收应用数据的应用
(APP)层、确定到端到端对等无线通信电路和下一跳对等无线通信电路设备的路由的网络层、用于控制无线介质访问协议的介质访问控制(MAC)层、用于向下一跳对等无线通信电路传输和接收物理信号的物理(PHY)层，以及用于生成新的实时应用
(RTA)会话并具有与MAC层管理实体(MLME)通信的接口的应用层；
(iii)由所述WLAN站的应用(APP)层生成请求，以请求MAC层开始具有给定要求集的所述WLAN站与接收方WLAN站之间的新RTA会话，其中所述WLAN站是发起者WLAN站，并且其中MAC和APP层之间的RTA接口作为用于RTA分组的OSI模型中的互通通信的一部分；
(iv)由MAC层监视信道并获得关键性能指标(KPI)以得出对APP层的响应；
(v)由MAC层根据RTA会话要求和测得的KPI或者接受或者拒绝由APP层做出的开始新会话的请求；以及
(vi)如果新会话发起被拒绝，那么由APP层重新发出由APP层开始具有经调整的参数的新会话的请求。
2.如权利要求1所述的装置，其中所述指令在由处理器执行时还执行下列步骤：APP层在MAC层处开始新的RTA会话并且为RTA分组设置生命周期值以提供队列管理。
3.如权利要求1所述的装置，其中所述指令在由处理器执行时还执行下列步骤：APP层在MAC层处开始新的RTA会话并且为RTA分组设置优先级值以提供队列管理。
4.如权利要求1所述的装置，其中所述指令在由处理器执行时还执行下列步骤：APP层在MAC层处开始新的RTA会话并且为RTA分组设置目标分组丢失率。
5.如权利要求4所述的装置，其中所述指令在由处理器执行时还执行下列步骤：所述站的MAC层将目标分组丢失率设置为调整用于RTA分组的调制和编码方案(MCS)和重试限制的目标分组丢失率。
6.如权利要求4所述的装置，其中所述指令在由处理器执行时还执行下列步骤：所述站的MAC层将目标分组丢失率设置为用于复制分组传输或多链路传输的目标分组丢失率。
7.如权利要求1所述的装置，其中所述指令在由处理器执行时还执行下列步骤：APP层在MAC层处开始新的RTA会话并且为RTA分组设置请求的时延。
8.如权利要求1所述的装置，其中所述指令在由处理器执行时还执行下列步骤：MAC层监视信道并且测量信道的关键性能指标(KPI)。
9.如权利要求8所述的装置，其中信道的所述关键性能指标(KPI)选自由带宽、调制和编码方案(MCS)、信道接入率、分组错误率(PER)以及信道用于传输分组的时间比率组成的性能指标的组。
10.如权利要求8所述的装置，其中所述指令在由处理器执行时还执行下列步骤：MAC层利用用于复制分组传输或多链路传输的测量结果来测量信道的所述关键性能指标(KPI)。
11.如权利要求1所述的装置，其中所述指令在由处理器执行时还执行下列步骤：监视信道的MAC层获得关于分组时延的所述关键性能指标(KPI)的统计数据并将它们与RTA请求的时延进行比较。
12.如权利要求11所述的装置，其中所述指令在由处理器执行时还执行下列步骤：MAC层在获得关于分组时延的所述关键性能指标(KPI)的统计数据并将它们与RTA请求的时延进行比较时利用MAC层处的时间戳。
13.如权利要求12所述的装置，其中所述指令在由处理器执行时还执行下列步骤：获得分组时延的统计数据的MAC层在发送者和接收者处都执行时延的测量。
14.如权利要求11所述的装置，其中所述指令在由处理器执行时还执行下列步骤：获得分组时延的统计数据的MAC层执行平均重传率的测量。
15.如权利要求1所述的装置，其中所述指令在由处理器执行时还执行下列步骤：MAC层在确定信道空闲之间的平均时间和标准偏差以及信道占用之间的平均时间时监视信道并测量分组到达率的关键性能指标(KPI)。
16.如权利要求15所述的装置，其中所述指令在由处理器执行时还执行下列步骤：MAC层利用对分组到达率的测量进行调度分组传输或基于RTA会话期间所请求的分组到达率来执行轮询。
17.如权利要求1所述的装置，其中所述指令在由处理器执行时还执行下列步骤：MAC层执行信道的监视并且测量队列状态的关键性能指标(KPI)。
18.如权利要求17所述的装置，其中所述指令在由处理器执行时还执行下列步骤：MAC层执行信道的监视并且测量包括当前队列尺寸的关键性能指标(KPI)。
19.如权利要求1所述的装置，其中所述指令在由处理器执行时还执行下列步骤：MAC层监视信道并且测量关键性能指标(KPI)以及记录关于分组业务的改变的历史信息。
20.如权利要求1所述的装置，其中所述指令在由处理器执行时还执行下列步骤：MAC层监视信道和测量关键性能指标(KPI)并将测得的KPI与RTA会话要求进行比较，并且如果测得的KPI不满足RTA会话要求，那么拒绝RTA会话发起。
21.如权利要求1所述的装置，其中所述指令在由处理器执行时还执行下列步骤：拒绝新的RTA会话的MAC层执行将在MAC层处获得的关键性能指标(KPI)报告给APP层。
22.如权利要求1所述的装置，其中所述指令在由处理器执行时还执行下列步骤：MAC层拒绝新的RTA会话并向APP层建议用于创建新的RTA会话的操作参数。
23.一种用于在网络中无线通信的装置，所述装置包括：
(a)无线通信电路，用于通过信道与位于其接收区域中的至少一个其它无线局域网(WLAN)站无线通信；
(b)处理器，耦合到被配置用于在WLAN上操作的站(STA)内的所述无线通信电路；以及
(c)非暂态存储器，存储处理器可执行的指令；
(d)其中所述指令在由处理器执行时执行下列步骤：
(i)将所述无线通信电路作为WLAN站进行操作，该WLAN站被配置为支持传送对通信延迟敏感的实时应用(RTA)
分组以及非实时分组，以及将实时应用(RTA)分组与非实时应用(非RTA)分组区分开来；
(ii)其中所述指令配置有生成和接收应用数据的应用
(APP)层、确定到端到端对等无线通信电路和下一跳对等无线通信电路设备的路由的网络层、用于控制无线介质访问协议的介质访问控制(MAC)层、用于向下一跳对等无线通信电路传输和接收物理信号的物理(PHY)层、以及用于生成新的实时应用
(RTA)会话并具有与MAC层管理实体(MLME)通信的接口的应用层；
(iii)由所述WLAN站的应用(APP)层生成请求，以请求MAC层开始具有给定要求集的所述WLAN站与接收方WLAN站之间的新RTA会话，其中所述WLAN站是发起者WLAN站，并且其中MAC和APP层之间的RTA接口作为用于RTA分组的OSI模型中的互通通信的一部分；
(iv)由MAC层监视信道并获得关键性能指标(KPI)以得出对APP层的响应；
(v)在MAC层处根据RTA会话要求和测得的KPI或者接受或者拒绝由APP层做出的开始新会话的请求；
(vi)其中，如果在MAC层处由APP层做出的开始新会话的请求被接受，那么APP层在MAC层处开始新的RTA会话，
并且：或者(A)为RTA分组设置生命周期值以提供队列管理，或者(B)为RTA分组设置优先级值以提供队列管理，或者(C)
为RTA分组设置请求的时延，或者(D)将RTA分组的目标分组丢失率或者设置为调整用于RTA分组的调制和编码方案(MCS)和重试限制的目标分组丢失率，或者设置为用于重复分组传输或多链路传输的目标分组丢失率；以及
(vii)如果新会话发起被拒绝，那么由APP层重新发出由APP层开始具有经调整的参数的新会话的请求。
24.一种用于在网络中无线通信的方法，其中所述方法是由执行存储在非暂态介质上的指令的处理器执行的，该方法包括：
(a)将无线通信电路作为WLAN站进行操作，以用于通过信道与其接收区域中的至少一个其它无线局域网(WLAN)站无线通信，所述站被配置为支持传送对通信延迟敏感的实时应用(RTA)分组以及非实时分组，以及将实时应用(RTA)分组与非实时应用(非RTA)分组区分开来；
(b)其中所述指令配置有生成和接收应用数据的应用(APP)层、确定到端到端对等无线通信电路和下一跳对等无线通信电路设备的路由的网络层、用于控制无线介质访问协议的介质访问控制(MAC)层、用于向下一跳对等无线通信电路传输和接收物理信号的物理(PHY)层、以及用于生成新的实时应用(RTA)会话并具有与MAC层管理实体(MLME)通信的接口的应用层；
(c)由所述WLAN站的应用(APP)层生成请求，以请求MAC层开始具有给定要求集的所述WLAN站与接收方WLAN站之间的新RTA会话，其中所述WLAN站是发起者WLAN站，并且其中MAC和APP层之间的RTA接口作为用于RTA分组的OSI模型中的互通通信的一部分；
(d)由MAC层监视信道并获得关键性能指标(KPI)以得出对APP层的响应；
(e)由MAC层根据RTA会话要求和测得的KPI或者接受或者拒绝由APP层做出的开始新会话的请求；以及
(f)如果新会话发起被拒绝，那么由APP层重新发出由APP层开始具有经调整的参数的新会话的请求。
CN202080038802.5A 2019-12-23 2020-12-17 实时应用 Active CN113875272B (zh)

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
US201962952681P 2019-12-23 2019-12-23
US62/952,681 2019-12-23
US16/998,569 2020-08-20
US16/998,569 US11716784B2 (en) 2019-12-23 2020-08-20 RTA interface between MAC and app layer
PCT/IB2020/062075 WO2021130621A1 (en) 2019-12-23 2020-12-17 Real time applications

Publications (2)

Publication Number Publication Date
CN113875272A CN113875272A (zh) 2021-12-31
CN113875272B true CN113875272B (zh) 2024-04-30

Family

ID=76438739

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202080038802.5A Active CN113875272B (zh) 2019-12-23 2020-12-17 实时应用

Country Status (6)

Country Link
US (1) US11716784B2 (zh)
EP (1) EP4059241A1 (zh)
JP (1) JP2023508171A (zh)
KR (1) KR20220100004A (zh)
CN (1) CN113875272B (zh)
WO (1) WO2021130621A1 (zh)

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11363539B1 (en) * 2019-12-04 2022-06-14 Silvus Technologies, Inc. Adaptive power control for mobile ad-hoc networks
US11916804B2 (en) * 2020-06-01 2024-02-27 Intel Corporation QOS model for supporting low latency services and time-sensitive networking
EP4241335A1 (en) * 2020-11-06 2023-09-13 Dejero Labs Inc. System and method for housing antennas
US20220201755A1 (en) * 2020-12-23 2022-06-23 Intel Corporation Dynamic transmission bandwidth selection

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1586055A (zh) * 2001-11-13 2005-02-23 皇家飞利浦电子股份有限公司 为ieee802.11e mac提供服务质量信令的设备和方法
US6970422B1 (en) * 2000-07-14 2005-11-29 At&T Corp. Admission control for QoS-Driven Wireless LANs
US7756092B1 (en) * 2000-07-14 2010-07-13 At&T Intellectual Property Ii, L.P. In-band QoS signaling reference model for QoS-driven wireless LANs connected to one or more networks
CN110336765A (zh) * 2019-07-05 2019-10-15 北京神经元网络技术有限公司 高速工业通信系统的同步方法、装置、网络设备及存储介质

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6049549A (en) * 1997-08-14 2000-04-11 University Of Massachusetts Adaptive media control
US7027462B2 (en) * 2001-01-02 2006-04-11 At&T Corp. Random medium access methods with backoff adaptation to traffic
CN1305276C (zh) 2004-01-15 2007-03-14 中兴通讯股份有限公司 一种快速处理实时媒体流数据包的方法及其系统

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6970422B1 (en) * 2000-07-14 2005-11-29 At&T Corp. Admission control for QoS-Driven Wireless LANs
US7756092B1 (en) * 2000-07-14 2010-07-13 At&T Intellectual Property Ii, L.P. In-band QoS signaling reference model for QoS-driven wireless LANs connected to one or more networks
CN1586055A (zh) * 2001-11-13 2005-02-23 皇家飞利浦电子股份有限公司 为ieee802.11e mac提供服务质量信令的设备和方法
CN110336765A (zh) * 2019-07-05 2019-10-15 北京神经元网络技术有限公司 高速工业通信系统的同步方法、装置、网络设备及存储介质

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
Chih-Wei Huang.Airtime Fair Distributed Cross-Layer Congestion Control for Real-Time Video Over WLAN.《IEEE Transactions on Circuits and Systems for Video Technology》.2009,全文. *

Also Published As

Publication number Publication date
US20210195683A1 (en) 2021-06-24
US11716784B2 (en) 2023-08-01
KR20220100004A (ko) 2022-07-14
JP2023508171A (ja) 2023-03-01
EP4059241A1 (en) 2022-09-21
CN113875272A (zh) 2021-12-31
WO2021130621A1 (en) 2021-07-01

Similar Documents

Publication Publication Date Title
CN113875272B (zh) 实时应用
US11259324B2 (en) MU-MIMO pre-packet arrival channel contention
US7743310B2 (en) Communication apparatus, communication system, communication method, and communication control program
US8274961B2 (en) Apparatus and associated methodology of adjusting a RTS/CTS transmission protocol
JP7427170B2 (ja) 時間内及び周波数内ｒｔａパケット重複
US11178694B2 (en) RTA queue management in wireless local area network (WLAN) stations
JP7284925B2 (ja) パケット到着前チャネル競合
JP7288590B2 (ja) 無線ローカルエリアネットワークにおける将来的チャネル時間の予約
JP2023521087A (ja) Ｒｔａパケットのためのｅｄｃａキュー
CN114303411A (zh) 用于rta会话管理的ts操作
WO2022208211A2 (en) Sharing an edca txop with rta traffic
US20220322460A1 (en) Sharing an edca txop with rta traffic

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant