KR20240056822A - 피어-투-피어(p2p) 통신들을 위한 저 레이턴시 방식들 - Google Patents

Abstract

본 개시내용은 제한된 TWT(target wake time) SP(service period)들에서 데이터 트래픽을 관리하기 위한 시스템들, 방법들 및 장치를 제공한다. 일부 양상들에서, AP(access point)는, P2P(peer-to-peer) 링크를 통해 클라이언트 디바이스와 연관된 무선 STA(station)로부터 요청 프레임을 수신하고, 요청 프레임은, 무선 매체에 스케줄링된 r-TWT SP 동안 STA가 클라이언트 디바이스와 P2P 통신들을 교환하고자 의도함을 표시한다. AP는 r-TWT SP 동안 무선 매체 상에서 TXOP(transmission opportunity)를 획득하고, 요청 프레임은 클라이언트 디바이스를 식별한다. AP는, TXOP를 획득하는 것에 대한 응답으로, 무선 매체 상에서 트리거 프레임을 송신하고, 트리거 프레임은 STA와 클라이언트 디바이스 사이의 P2P 통신들을 위해, 획득된 TXOP의 일부를 배정하고, 응답 프레임 또는 트리거 프레임 중 적어도 하나는 클라이언트 디바이스에 대한 NAV(Network Allocation Vector) 예외(exception)를 표시한다.

Description

피어-투-피어(P2P) 통신들을 위한 저 레이턴시 방식들

[0001] 본 특허 출원은 AJAMI 등에 의해서 2021년 9월 22일에 "LOW LATENCY SCHEMES FOR PEER-TO-PEER (P2P) COMMUNICATIONS"라는 명칭으로 출원된 미국 특허 출원 번호 제17/482,417호의 이익을 주장하며, 그 미국 특허 출원은 본 출원의 양수인에게 양도되었고, 그 전체가 인용에 의해 본원에 포함된다.

[0002] 본 개시내용은 일반적으로 무선 통신에 관한 것으로, 더 구체적으로는, 제한된 TWT(target wake time) 서비스 기간들에서 데이터 트래픽을 관리하는 것에 관한 것이다.

[0003] WLAN(wireless local area network)은 다수의 클라이언트 디바이스들 또는 STA(station)들에 의한 사용을 위해 공유된 무선 매체를 제공하는 하나 이상의 AP(access point)들에 의해 형성될 수 있다. BSS(Basic Service Set)에 대응할 수 있는 각각의 AP는 비콘 프레임들을 주기적으로 브로드캐스팅하여, AP의 무선 범위 내의 임의의 STA들이 WLAN과의 통신 링크를 확립 및 유지할 수 있게 할 수 있다. IEEE 802.11 표준군에 따라 동작하는 WLAN들은 일반적으로 Wi-Fi 네트워크들로 지칭된다.

[0004] 일부 무선 통신 디바이스들은 데이터 트래픽에 대한 엄격한 엔드-투-엔드 레이턴시, 스루풋 및 타이밍 요건들을 갖는 저-레이턴시 애플리케이션들과 연관될 수 있다. 예시적인 저-레이턴시 애플리케이션들은 실시간 게이밍 애플리케이션들, 비디오 통신들, 및 AR(augmented reality) 및 VR(virtual reality) 애플리케이션들(총괄하여 XR(extended reality) 애플리케이션들로 지칭됨)을 포함한다(그러나 이것들로 제한되지는 않음). 그러한 저-레이턴시 애플리케이션들은 이러한 애플리케이션들에 대한 연결을 제공하는 무선 통신 시스템들에 대한 다양한 레이턴시, 스루풋 및 타이밍 요건들을 특정할 수 있다. 따라서, WLAN들이 그러한 저-레이턴시 애플리케이션들의 다양한 레이턴시, 스루풋 및 타이밍 요건들을 충족시킬 수 있도록 보장하는 것이 바람직하다.

[0005] 본 개시내용의 시스템들, 방법들, 및 디바이스들 각각은 몇몇 혁신적인 양상들을 가지며, 그 양상들 중 어떠한 단일 양상도 본원에 개시된 바람직한 속성들을 단독으로 담당하지 않는다.

[0006] 본 개시내용에서 설명되는 청구대상의 하나의 혁신적인 양상은 AP(access point)에 의한 무선 통신 방법으로서 구현될 수 있다. 일부 구현들에서, 방법은, AP와 연관되고 그리고 P2P(peer-to-peer) 링크를 통해 클라이언트 디바이스와 또한 연관된 무선 STA(station)로부터 요청 프레임을 수신하는 단계를 포함할 수 있고, 요청 프레임은, 무선 매체에 스케줄링된 r-TWT(restricted target wake time) SP(service period) 동안 STA가 클라이언트 디바이스와 P2P 통신들을 교환하고자 의도함을 표시하고, 요청 프레임은 클라이언트 디바이스를 식별한다. 방법은, 요청 프레임을 수신하는 것에 대한 응답으로, 무선 매체 상에서 STA에 응답 프레임을 송신하는 단계를 포함할 수 있다. 방법은, r-TWT SP 동안 무선 매체 상에서 TXOP(transmission opportunity)를 획득하는 단계를 포함할 수 있다. 방법은, TXOP를 획득하는 것에 대한 응답으로, 무선 매체 상에서 트리거 프레임을 송신하는 단계를 포함할 수 있고, 트리거 프레임은 STA와 클라이언트 디바이스 사이의 P2P 통신들을 위해, 획득된 TXOP의 일부를 배정(allocate)하고, 응답 프레임 또는 트리거 프레임 중 적어도 하나는 클라이언트 디바이스에 대한 NAV(Network Allocation Vector) 예외(exception)를 표시한다. 일부 양상들에서, 응답 프레임 및 트리거 프레임 각각은 클라이언트 디바이스의 MAC(medium access control) 어드레스를 포함한다. 일부 구현들에서, NAV 예외는, 클라이언트 디바이스가 트리거 프레임에 의해 표시되는 NAV 지속기간 및 트리거 프레임에 대한 응답으로 CTS(clear-to-send) 프레임에 의해 표시되는 NAV 지속기간을 무시해야 함을 표시한다. 일부 양상들에서, CTS 프레임은 클라이언트 디바이스의 MAC 어드레스를 포함한다.

[0007] 일부 다른 구현들에서, STA는 클라이언트 디바이스와 통신하도록 구성된 코로케이트(collocate)된 softAP를 포함하고, 응답 프레임 또는 트리거 프레임 중 적어도 하나는 코로케이트된 softAP에 대한 NAV 예외를 또한 표시한다. 일부 예시들에서, NAV 예외는, r-TWT SP에 속하는 STA들과 코로케이트된 softAP들이 트리거 프레임에 의해 표시되는 NAV 지속기간 및 트리거 프레임에 대한 응답으로 CTS 프레임에 의해 표시되는 NAV 지속기간을 무시해야 함을 표시한다. 요청 프레임은 코로케이트된 softAP의 MAC 어드레스를 AP에 표시할 수 있고, 트리거 프레임 및 CTS 프레임 각각은 코로케이트된 softAP의 MAC 어드레스를 포함할 수 있다. 일부 양상들에서, 트리거 프레임은 NAV 예외를 표시하기 위해 0의 값으로 설정된 비트를 반송하는 CS(Carrier Sense) 필수 필드(Required field)를 포함한다.

[0008] 다양한 구현들에서, 요청 프레임은 클라이언트 디바이스의 MAC 어드레스를 표시하고, 응답 프레임은 클라이언트 디바이스가 AP로부터 송신된 트리거 프레임들에 의해 설정되는 NAV 지속기간들 및 트리거 프레임들에 대한 응답으로 CTS 프레임들에 의해 설정되는 NAV 지속기간들을 무시해야 함을 표시한다. 일부 구현들에서, 요청 프레임은 클라이언트 디바이스의 MAC 어드레스를 표시하는 TWT 엘리먼트를 포함하는 TWT 요청 프레임이다. TWT 엘리먼트는 r-TWT SP의 주기성(periodicity), r-TWT SP의 지속기간, r-TWT SP의 공유 모드, r-TWT SP의 웨이크 지속기간(wake duration), r-TWT SP의 흐름 타입, 또는 r-TWT SP의 파라미터 세트 중 하나 이상을 표시할 수 있다. 일부 예시들에서, 응답 프레임은 r-TWT SP에 대해 참여 디바이스들에 의해 사용될 TWT 파라미터들의 세트를 표시하는 TWT 엘리먼트를 포함하는 TWT 응답 프레임일 수 있다. 다른 구현들에서, 요청 프레임은 클라이언트 디바이스의 MAC 어드레스를 표시하는 TSPEC(traffic specification) 엘리먼트를 포함하는 SCS(Stream Classification Service) 요청 프레임이다. TSPEC 엘리먼트는 또한, r-TWT SP에 대한 최소 데이터 레이트, r-TWT SP에 대한 평균 데이터 레이트, r-TWT SP에 대한 지연 한계(delay bound), 및 r-TWT SP에 대한 UP(user priority)를 표시할 수 있다. 일부 예시들에서, 응답 프레임은 SCS 응답 프레임일 수 있다. 일부 다른 구현들에서, 요청 프레임은, 적어도 클라이언트 디바이스의 MAC 어드레스를 표시하는 TWT 엘리먼트, TSPEC 엘리먼트, 또는 VSIE(vendor-specific information element) 중 하나 이상을 포함하는 P2P 요청 프레임이다. TWT 엘리먼트는 r-TWT SP에 대해 제안된 다양한 TWT 파라미터들을 표시할 수 있고, P2P 엘리먼트는 r-TWT SP에 대해 제안된 다양한 P2P 파라미터들을 표시할 수 있다. 일부 예시들에서, 응답 프레임은 얼마나 많은 디바이스들이 r-TWT SP의 멤버들인지를 표시하는 P2P 응답 프레임일 수 있다.

[0009] 일부 구현들에서, 트리거 프레임은, 클라이언트 디바이스와 연관된 P2P 통신들에 대응하는 TXOP 공유 모드를 표시하는 TXOP 공유 모드 서브필드를 포함하는 MU(multi-user) RTS(Request-to-Send) TXS(TXOP Sharing) 트리거 프레임일 수 있다. 일부 예시들에서, TXOP 공유 모드 서브필드는, STA가 MU-RTS TXS 트리거 프레임에 대한 응답으로, 클라이언트 디바이스의 MAC 어드레스를 포함하는 수신기 어드레스 필드를 포함하는 CTS 프레임을 송신하라는 요청을 표시한다. 일부 다른 구현들에서, 요청 프레임은 STA가 r-TWT SP 내에서 무선 매체를 사용하고자 의도하는 제1 시간 기간을 표시하고, 트리거 프레임은 TXOP의 일부가 클라이언트 디바이스와 연관된 P2P 통신들을 위해 배정되는 제2 시간 기간을 표시하는 지속기간 필드를 포함하며, 제2 시간 기간은 제1 시간 기간보다 짧다. 일부 양상들에서, 제2 시간 기간은 STA로부터의 CTS 프레임을 요청하는 것과 연관된 시간 기간에 기반한다.

[0010] 본 개시내용에서 설명되는 청구대상의 다른 혁신적인 양상은 무선 통신 디바이스로 구현될 수 있다. 무선 통신 디바이스는 적어도 하나의 모뎀, 적어도 하나의 모뎀과 통신 가능하게 커플링된 적어도 하나의 프로세서, 및 적어도 하나의 프로세서와 통신 가능하게 커플링된 적어도 하나의 메모리를 포함할 수 있다. 일부 구현들에서, 적어도 하나의 메모리는 프로세서-판독가능 코드를 저장하고, 프로세서-판독가능 코드는, 적어도 하나의 모뎀과 함께 적어도 하나의 프로세서에 의해 실행될 때, AP와 연관되고 그리고 P2P 링크를 통해 클라이언트 디바이스와 또한 연관된 STA로부터 요청 프레임을 수신하도록 구성되고, 요청 프레임은, 무선 매체에 스케줄링된 r-TWT SP 동안 STA가 클라이언트 디바이스와 P2P 통신들을 교환하고자 의도함을 표시하고, 요청 프레임은 클라이언트 디바이스를 식별한다. 프로세서-판독가능 코드의 실행은, 요청 프레임을 수신하는 것에 대한 응답으로, 무선 매체 상에서 STA에 응답 프레임을 송신하도록 구성된다. 프로세서-판독가능 코드의 실행은, r-TWT SP 동안 무선 매체 상에서 TXOP를 획득하도록 구성된다. 프로세서-판독가능 코드의 실행은, TXOP를 획득하는 것에 대한 응답으로, 무선 매체 상에서 트리거 프레임을 송신하도록 구성되고, 트리거 프레임은 STA와 클라이언트 디바이스 사이의 P2P 통신들을 위해, 획득된 TXOP의 일부를 배정하고, 응답 프레임 또는 트리거 프레임 중 적어도 하나는 클라이언트 디바이스에 대한 NAV 예외를 포함한다.

[0011] 일부 구현들에서, 응답 프레임 및 트리거 프레임 각각은 클라이언트 디바이스의 MAC 어드레스를 포함한다. 일부 예시들에서, NAV 예외는, 클라이언트 디바이스가 트리거 프레임에 의해 표시되는 NAV 지속기간 및 트리거 프레임에 대한 응답으로 CTS 프레임에 의해 표시되는 NAV 지속기간을 무시해야 함을 표시한다. 일부 양상들에서, CTS 프레임은 클라이언트 디바이스의 MAC 어드레스를 표시한다.

[0012] 일부 다른 구현들에서, STA는 클라이언트 디바이스와 통신하도록 구성된 코로케이트된 softAP를 포함하고, 응답 프레임 또는 트리거 프레임 중 적어도 하나는 softAP에 대한 NAV 예외를 또한 표시한다. 일부 예시들에서, NAV 예외는, r-TWT SP에 속하는 STA들과 코로케이트된 softAP들이 트리거 프레임에 의해 표시되는 NAV 지속기간 및 트리거 프레임에 대한 응답으로 CTS 프레임에 의해 표시되는 NAV 지속기간을 무시해야 함을 표시한다. 요청 프레임은 코로케이트된 softAP의 MAC 어드레스를 AP에 표시할 수 있고, 트리거 프레임 및 CTS 프레임 각각은 코로케이트된 softAP의 MAC 어드레스를 포함할 수 있다. 일부 양상들에서, 트리거 프레임은 NAV 예외를 표시하기 위해 0의 값으로 설정된 비트를 반송하는 CS(Carrier Sense) 필수 필드(Required field)를 포함한다.

[0013] 다양한 구현들에서, 요청 프레임은 클라이언트 디바이스의 MAC 어드레스를 표시하고, 응답 프레임은 클라이언트 디바이스가 AP로부터 송신된 트리거 프레임들에 의해 설정되는 NAV 지속기간들 및 트리거 프레임들에 대한 응답으로 CTS 프레임들에 의해 설정되는 NAV 지속기간들을 무시해야 함을 표시한다. 일부 구현들에서, 요청 프레임은 클라이언트 디바이스의 MAC 어드레스를 표시하는 TWT 엘리먼트를 포함하는 TWT 요청 프레임이다. TWT 엘리먼트는 r-TWT SP의 주기성(periodicity), r-TWT SP의 지속기간, r-TWT SP의 공유 모드, r-TWT SP의 웨이크 지속기간(wake duration), r-TWT SP의 흐름 타입, 또는 r-TWT SP의 파라미터 세트 중 하나 이상을 표시할 수 있다. 일부 예시들에서, 응답 프레임은 r-TWT SP에 대해 참여 디바이스들에 의해 사용될 TWT 파라미터들의 세트를 표시하는 TWT 엘리먼트를 포함하는 TWT 응답 프레임일 수 있다. 다른 구현들에서, 요청 프레임은 클라이언트 디바이스의 MAC 어드레스를 표시하는 TSPEC(traffic specification) 엘리먼트를 포함하는 SCS(Stream Classification Service) 요청 프레임이다. TSPEC 엘리먼트는 또한, r-TWT SP에 대한 최소 데이터 레이트, r-TWT SP에 대한 평균 데이터 레이트, r-TWT SP에 대한 지연 한계(delay bound), 및 r-TWT SP에 대한 UP(user priority)를 표시할 수 있다. 일부 예시들에서, 응답 프레임은 SCS 응답 프레임일 수 있다. 일부 다른 구현들에서, 요청 프레임은, 적어도 클라이언트 디바이스의 MAC 어드레스를 표시하는 TWT 엘리먼트, TSPEC 엘리먼트, 또는 VSIE(vendor-specific information element) 중 하나 이상을 포함하는 P2P 요청 프레임이다. TWT 엘리먼트는 r-TWT SP에 대해 제안된 다양한 TWT 파라미터들을 표시할 수 있고, P2P 엘리먼트는 r-TWT SP에 대해 제안된 다양한 P2P 파라미터들을 표시할 수 있다. 일부 예시들에서, 응답 프레임은 얼마나 많은 디바이스들이 r-TWT SP의 멤버들인지를 표시하는 P2P 응답 프레임일 수 있다.

[0014] 일부 구현들에서, 트리거 프레임은, 클라이언트 디바이스와 연관된 P2P 통신들에 대응하는 TXOP 공유 모드를 표시하는 TXOP 공유 모드 서브필드를 포함하는 MU-RTS TXS 트리거 프레임일 수 있다. 일부 예시들에서, TXOP 공유 모드 서브필드는, STA가 MU-RTS TXS 트리거 프레임에 대한 응답으로, 클라이언트 디바이스의 MAC 어드레스를 포함하는 수신기 어드레스 필드를 포함하는 CTS 프레임을 송신하라는 요청을 표시한다. 일부 다른 구현들에서, 요청 프레임은 STA가 r-TWT SP 내에서 무선 매체를 사용하고자 의도하는 제1 시간 기간을 표시하고, 트리거 프레임은 TXOP의 일부가 클라이언트 디바이스와 연관된 P2P 통신들을 위해 배정되는 제2 시간 기간을 표시하는 지속기간 필드를 포함하며, 제2 시간 기간은 제1 시간 기간보다 짧다. 일부 양상들에서, 제2 시간 기간은 STA로부터의 CTS 프레임을 요청하는 것과 연관된 시간 기간에 기반한다.

[0015] 본 개시내용에 설명된 청구대상의 하나 이상의 구현들의 세부사항들은 첨부한 도면들 및 아래의 설명에서 기술된다. 다른 특징들, 양상들 및 이점들은 설명, 도면들 및 청구항들로부터 명백해질 것이다. 하기 도면들의 상대적 치수들은 실척대로 도시되지 않을 수 있음을 주목한다.

[0016] 도 1은 예시적인 무선 통신 네트워크의 도면(pictorial diagram)을 도시한다.
[0017] 도 2a는 AP(access point)와 하나 이상의 무선 STA(station)들 사이의 통신들에 사용가능한 예시적인 PDU(protocol data unit)를 도시한다.
[0018] 도 2b는 도 2a의 PDU의 예시적인 필드를 도시한다.
[0019] 도 3a는 AP와 하나 이상의 STA들 간의 통신들에 사용가능한 다른 예시적인 PDU를 도시한다.
[0020] 도 3b는 AP와 하나 이상의 STA들 간의 통신들에 사용가능한 다른 예시적인 PDU를 도시한다.
[0021] 도 4는 AP와 다수의 STA들 간의 통신들에 사용가능한 예시적인 PPDU(PLCP(physical layer convergence protocol) protocol data unit)를 도시한다.
[0022] 도 5는 예시적인 무선 통신 디바이스의 블록도를 도시한다.
[0023] 도 6a는 예시적인 AP(access point)의 블록도를 도시한다.
[0024] 도 6b는 예시적인 STA(station)의 블록도를 도시한다.
[0025] 도 7은 BSS(basic service set)에 속하는 디바이스들 사이의 무선 통신의 예를 도시하는 타이밍도를 도시한다.
[0026] 도 8은 일부 구현들에 따른, 레이턴시 민감 트래픽(latency sensitive traffic)을 지원하는 무선 통신의 다른 예를 도시하는 타이밍도를 도시한다.
[0027] 도 9는 일부 구현들에 따른, 레이턴시 민감 트래픽을 지원하는 무선 통신의 다른 예를 도시하는 타이밍도를 도시한다.
[0028] 도 10은 일부 구현들에 따른, 레이턴시 민감 트래픽을 지원하는 무선 통신의 다른 예를 도시하는 타이밍도를 도시한다.
[0029] 도 11은 일부 구현들에 따른, 레이턴시 민감 트래픽을 지원하는 무선 통신의 다른 예를 도시하는 타이밍도를 도시한다.
[0030] 도 12는 일부 구현들에 따른, 레이턴시 민감 트래픽을 지원하는 무선 통신의 다른 예를 도시하는 타이밍도를 도시한다.
[0031] 도 13은 일부 구현들에 따른, 레이턴시 민감 트래픽을 지원하는 무선 통신의 다른 예를 도시하는 타이밍도를 도시한다.
[0032] 도 14는 일부 구현들에 따른, 레이턴시 민감 트래픽을 지원하는 무선 통신의 다른 예를 도시하는 타이밍도를 도시한다.
[0033] 도 15는 일부 구현들에 따른, 레이턴시 민감 트래픽을 지원하는 무선 통신의 다른 예를 도시하는 타이밍도를 도시한다.
[0034] 도 16은 일부 구현들에 따른, 저-레이턴시 통신들을 지원하는 무선 통신을 위한 예시적인 프로세스를 예시하는 흐름도를 도시한다.
[0035] 도 17은 일부 다른 구현들에 따른, 저-레이턴시 통신들을 지원하는 무선 통신을 위한 예시적인 프로세스를 예시하는 흐름도를 도시한다.
[0036] 도 18은 일부 다른 구현들에 따른, 저-레이턴시 통신들을 지원하는 무선 통신을 위한 다른 예시적인 프로세스를 예시하는 흐름도를 도시한다.
[0037] 도 19a는 일부 구현들에 따른, 무선 통신들에 사용가능한 TWT 엘리먼트의 예시적인 구조를 도시한다.
[0038] 도 19b는 일부 구현들에 따른, 무선 통신들에 사용가능한 브로드캐스트 TWT 파라미터 세트 필드의 예시적인 구조를 도시한다.
[0039] 도 19c는 일부 구현들에 따른, 무선 통신들에 사용가능한 브로드캐스트 TWT 파라미터 세트 필드 내의 요청 타입 필드의 예시적인 구조를 도시한다.
[0040] 도 20a는 일부 구현들에 따른, 무선 통신들에 사용가능한 트리거 프레임의 예시적인 구조를 도시한다.
[0041] 도 20b는 도 20a의 트리거 프레임의 사용자 정보 필드의 예시적인 구조를 도시한다.
[0042] 도 21은 일부 구현들에 따른 예시적인 무선 통신 디바이스의 블록도를 도시한다.
[0043] 도 22는 일부 구현들에 따른 다른 예시적인 무선 통신 디바이스의 블록도를 도시한다.
[0044] 다양한 도면들에서 유사한 참조 부호들 및 지정들은 유사한 엘리먼트들을 표시한다.

[0045] 다음의 설명은 본 개시내용의 혁신적인 양상들을 설명하려는 목적들을 위한 일부 특정 구현들에서 관한 것이다. 그러나, 당업자는 본원의 교시들이 다수의 상이한 방식들로 적용될 수 있음을 용이하게 인식할 것이다. 설명되는 구현들은, 특히, 3GPP(3rd Generation Partnership Project)에 의해 공표된 LTE(Long Term Evolution), 3G, 4G 또는 5G(New Radio, NR) 표준들, IEEE(Institute of Electrical and Electronics Engineers) 802.11 표준들, IEEE 802.15 표준들, 또는 블루투스 SIG(Special Interest Group)에 의해 정의된 Bluetooth® 표준들 중 하나 이상에 따라 RF(radio frequency) 신호들을 송신 및 수신할 수 있는 임의의 디바이스, 시스템 또는 네트워크에서 구현될 수 있다. 설명되는 구현들은, 다음의 기술들 또는 기법들: CDMA(code division multiple access), TDMA(time division multiple access), FDMA(frequency division multiple access), OFDMA(orthogonal FDMA), SC-FDMA(single-carrier FDMA), SU(single-user) MIMO(multiple-input multiple-output) 및 MU(multi-user) MIMO 중 하나 이상에 따라 RF 신호들을 송신 및 수신할 수 있는 임의의 디바이스, 시스템 또는 네트워크에서 구현될 수 있다. 설명되는 구현들은 또한, WWAN(wireless wide area network), WPAN(wireless personal area network), WLAN(wireless local area network), 또는 IOT(internet of things) 네트워크 중 하나 이상에서 사용하기에 적합한 다른 무선 통신 프로토콜들 또는 RF 신호들을 사용하여 구현될 수 있다.

[0046] 많은 무선 네트워크들은 공유 무선 매체에 대한 액세스를 제어하기 위해 랜덤 채널 액세스 메커니즘들을 사용한다. 이러한 무선 네트워크들에서, 무선 통신 디바이스들(AP(access point)들 및 무선 STA(station)들을 포함함)은 무선 매체에 대한 액세스를 얻기 위해 CSMA/CA(carrier sense multiple access with collision avoidance) 기법들을 사용하여 서로 경합한다. 일반적으로, 가장 낮은 백-오프 넘버(back-off number)(RBO)를 랜덤하게 선택하는 무선 통신 디바이스가 매체 액세스 경합 동작에서 승리하고, 일반적으로 TXOP(transmit opportunity)로 지칭되는 시간 기간 동안 무선 매체에 대한 액세스를 승인받을 수 있다. 다른 무선 통신 디바이스들은 일반적으로, 공유 무선 매체 상에서의 충돌들을 회피하기 위해 다른 무선 통신 디바이스의 TXOP 동안 송신하도록 허용되지 않는다.

[0047] 일부 랜덤 채널 액세스 메커니즘들, 이를테면, EDCA(enhanced distributed channel access)는 고-우선순위 트래픽이 저-우선순위 트래픽보다 매체 액세스를 획득할 더 큰 가능성을 제공한다. EDCA는, 예컨대 음성(AC_VO), 비디오(AC_VI), 최선 노력(AC_BE) 및 배경(AC_BK)과 같은 상이한 액세스 카테고리(AC)들로 데이터를 분류한다. 각각의 AC는 상이한 우선순위 레벨과 연관되고, 상이한 범위의 RBO들을 할당(assign) 받을 수 있어서, (이를테면, 더 높은 우선순위 데이터에 더 낮은 RBO들을 할당하고 더 낮은 우선순위 데이터에 더 높은 RBO들을 할당함으로써), 더 높은 우선순위 데이터가 더 낮은 우선순위 데이터보다 TXOP를 획득할 가능성이 더 높다. EDCA가 주어진 경합 기간 동안 저-레이턴시 데이터 트래픽이 공유 무선 매체에 대한 액세스를 획득할 가능성을 증가시키기는 하지만, 매체 액세스 경합 동작들의 예측 불가능한 결과들은 저-레이턴시 애플리케이션들이 특정 스루풋 레벨들을 달성하거나 또는 특정 레이턴시 요건들을 충족시키는 것을 막을 수 있다.

[0048] IEEE 802.11 표준의 IEEE 802.11be 개정안은 제한된 TWT(target wake time) SP(service period)를 설명하며, 이는 레이턴시-민감 트래픽에 대한 더 높은 신뢰성과 함께, 더 예측가능한 레이턴시, 감소된 최악 경우 레이턴시(worst case latency), 또는 감소된 지터(jitter)를 제공하는 데 사용될 수 있다. 본원에서 사용되는 바와 같이, "비-레거시(non-legacy) STA"라는 용어는 제한된 TWT 동작을 지원하는 임의의 STA를 지칭할 수 있는 한편, "저-레이턴시 STA"라는 용어는 전송 또는 수신하기 위한 레이턴시-민감 트래픽을 갖는 임의의 비-레거시 STA를 지칭할 수 있다. 대조적으로, "레거시 STA"라는 용어는 제한된 TWT 동작을 지원하지 않는 임의의 STA를 지칭할 수 있다. IEEE 802.11be 개정안은, 제한된 TWT SP 외부의 TXOP 홀더(holder)들인 모든 비-레거시 STA들이, 이들이 멤버가 아닌 임의의 r-TWT SP(restricted TWT SP)의 시작 전에 그들의 개개의 TXOP들을 종료하도록 요구한다. r-TWT SP에서의 멤버십이 저-레이턴시 STA들을 위해 예비(reserve)되지만, r-TWT SP들에 관한 현재 규칙들은 비-멤버 STA들이 r-TWT SP 동안 TXOP를 획득하는 것을 막지 않는다. 결과적으로, 일부 비-멤버 STA들은, 심지어 r-TWT SP의 멤버들이 채널 액세스를 획득할 수 있기 전에, r-TWT SP 동안 공유 무선 매체에 대한 액세스를 획득할 수 있다. 따라서, r-TWT SP들과 연관된 레이턴시-민감 트래픽을 추가로 보호하기 위해서는, 새로운 통신 프로토콜들 및/또는 새로운 채널 보호 메커니즘들이 필요하다.

[0049] 다양한 양상들은 일반적으로 레이턴시-민감 통신(latency-sensitive communication)들에 관한 것으로, 보다 구체적으로는, r-TWT SP들과 연관된 레이턴시-민감 트래픽에 r-TWT SP들 동안 충분한 채널 액세스가 제공되게 하여, 그러한 레이턴시-민감 트래픽의 다양한 레이턴시, 스루풋 및 타이밍 요건들을 충족시키도록 보장하는 것에 관한 것이다. 일부 구현들에서, AP는 전송 또는 수신할 저-레이턴시 P2P(peer-to-peer) 데이터를 갖는 저-레이턴시 STA들을 위해 무선 매체에 r-TWT SP를 스케줄링할 수 있다. 일부 예시들에서, AP와 연관된 STA는, 송신 또는 수신할 저-레이턴시 P2P 통신들을 갖는 클라이언트 디바이스와 연관된 코로케이트된 softAP를 포함할 수 있다. softAP 및 그의 클라이언트 디바이스는 P2P 링크와 연관될 수 있고, 그 P2P 링크를 통해, softAP와 클라이언트 디바이스 사이에서 P2P 통신들이 교환될 수 있다. softAP 또는 클라이언트 디바이스 중 어느 것도 AP와 연관되지 않기 때문에, AP는 r-TWT SP들 동안 무선 매체를 통해 송신되는 트리거 프레임들에서 softAP 또는 클라이언트 디바이스를 식별하지 못할 수 있다. 결과적으로, STA가 r-TWT SP 동안 softAP 및 클라이언트 디바이스와 연관된 P2P 통신들을 위해 무선 매체를 사용하고자 의도할 때, softAP 및 클라이언트 디바이스는 그들의 개개의 NAV들을 트리거 프레임에 의해 표시되는 지속기간으로 부주의하게 설정할 수 있고, 그에 따라, r-TWT SP 동안 서로 P2P 통신들을 송신 또는 수신하지 못할 수 있다.

[0050] 일부 구현들에서, AP는, AP와 연관되고 그리고 P2P 링크를 통해 클라이언트 디바이스와 제휴(affiliate)되는 STA로부터 요청 프레임을 수신할 수 있다. 요청 프레임은, STA가 무선 매체에 스케줄링된 r-TWT SP 동안 클라이언트 디바이스와 P2P 통신들을 교환하고자 의도함을 표시한다. 요청 프레임은 클라이언트 디바이스를 식별하고, r-TWT SP에 대한 하나 이상의 TWT 파라미터들을 표시할 수 있다. AP는 요청 프레임에서 수신된 정보에 기반하여 클라이언트 디바이스에 대한 NAV(Network Allocation Vector) 예외를 구성하고, STA에 응답 프레임을 송신할 수 있다. AP는 무선 매체 상에서 TXOP(transmission opportunity)를 획득할 수 있고, r-TWT SP 동안 무선 매체 상에서 트리거 프레임을 송신할 수 있다. 트리거 프레임은 STA와 클라이언트 디바이스 사이의 P2P 통신들을 위해, 획득된 TXOP의 일부를 배정할 수 있다. 응답 프레임 또는 트리거 프레임 중 적어도 하나는 클라이언트 디바이스에 대한 NAV 예외를 표시한다. 일부 예시들에서, NAV 예외는, 클라이언트 디바이스가 트리거 프레임에 의해 표시되는 NAV 지속기간 및 트리거 프레임에 대한 응답으로 CTS(clear-to-send) 프레임에 의해 표시되는 NAV 지속기간을 무시해야 함을 표시한다. 즉, NAV 예외는, 클라이언트 디바이스가 r-TWT SP 동안 송신된 트리거 프레임들에 의해 표시되는 NAV 지속기간들에 기반하여 자신의 NAV를 설정하지 않아야 함을 표시할 수 있다. 일부 예시들에서, STA는, 클라이언트 디바이스와 P2P 링크를 갖거나 또는 P2P 링크를 확립할 수 있는 코로케이트된 softAP를 포함할 수 있다. NAV 예외는 또한, 코로케이트된 softAP에 적용될 수 있어서, 예컨대, 코로케이트된 softAP는 r-TWT SP 동안 송신된 트리거 프레임들에 의해 표시되는 NAV 지속기간들에 기반하여 자신의 NAV를 설정하지 않는다.

[0051] 본 개시내용에서 설명되는 청구대상의 특정한 구현들은 다음의 잠재적인 장점들 중 하나 이상을 실현하도록 구현될 수 있다. AP와 연관되고 r-TWT SP에 속하는 STA들과 코로케이트되거나 또는 제휴되는 softAP들(뿐만 아니라 임의의 연관된 P2P 클라이언트 디바이스들)이 r-TWT SP 동안 AP로부터 송신된 트리거 프레임에 의해 표시되는 지속기간으로 그들의 개개의 NAV들을 설정하지 않아야 함을 표시하는 NAV 예외를 시그널링함으로써, 본 개시내용의 양상들은 그러한 softAP들 및 이들의 연관된 클라이언트 디바이스들이 r-TWT SP의 스케줄링된 부분들 동안 서로 레이턴시 민감 P2P 통신들을 교환할 수 있음을 보장할 수 있다. 이러한 방식으로, 본원에서 개시된 청구대상의 구현들은 P2P 디바이스들 또는 P2P 통신들과 연관된 레이턴시 민감 트래픽에 향상된 채널 보호 메커니즘들이 제공되는 것을 보장할 수 있다.

[0052] 도 1은 예시적인 무선 통신 네트워크(100)의 블록도를 도시한다. 일부 양상들에 따르면, 무선 통신 네트워크(100)는, Wi-Fi 네트워크와 같은 WLAN(wireless local area network)(이는 이후 WLAN(100)으로 지칭될 것임)의 예일 수 있다. 예컨대, WLAN(100)은 IEEE 802.11 표준군(이를테면, IEEE 802.11-2016 규격 또는 802.11ah, 802.11ad, 802.11ay, 802.11ax, 802.11az, 802.11ba, 및 802.11be를 포함하는(그러나 이것들로 제한되지는 않음) 그것의 개정안들에 의해 정의된 것) 중 적어도 하나를 구현하는 네트워크일 수 있다. WLAN(100)은 AP(access point)(102) 및 다수의 STA(station)들(104)과 같은 다수의 무선 통신 디바이스들을 포함할 수 있다. 단지 하나의 AP(102)만이 도시되지만, WLAN 네트워크(100)는 또한 다수의 AP들(102)을 포함할 수 있다.

[0053] STA들(104) 각각은 또한, 다른 가능성들 중에서도 MS(mobile station), 모바일 디바이스, 모바일 핸드셋, 무선 핸드셋, AT(access terminal), UE(user equipment), SS(subscriber station), 또는 가입자 유닛으로 지칭될 수 있다. STA들(104)은 다른 가능성들 중에서도, 모바일 폰들, PDA(personal digital assistant)들, 다른 핸드헬드 디바이스들, 넷북들, 노트북 컴퓨터들, 태블릿 컴퓨터들, 랩톱들, 디스플레이 디바이스들(예컨대, 다른 것들 중에서도, TV들, 컴퓨터 모니터들, 내비게이션 시스템들), 음악 또는 다른 오디오 또는 스테레오 디바이스들, 원격 제어 디바이스들("리모트들(remotes)"), 프린터들, 주방 또는 다른 가정 기기들, (예컨대, PKES(passive keyless entry and start) 시스템들에 대한) 키 포브(key fob)들과 같은 다양한 디바이스들을 표현할 수 있다.

[0054] 단일 AP(102) 및 연관된 세트의 STA들(104)은, 개개의 AP(102)에 의해 관리되는 BSS(basic service set)로 지칭될 수 있다. 도 1은, 부가적으로, WLAN(100)의 BSA(basic service area)를 표현할 수 있는 AP(102)의 예시적인 커버리지 영역(106)을 도시한다. BSS는, SSID(service set identifier)에 의해 사용자들에게 식별될 수 있을뿐만 아니라, AP(102)의 MAC(medium access control) 어드레스일 수 있는 BSSID(basic service set identifier)에 의해 다른 디바이스들에게 식별될 수 있다. AP(102)는, AP(102)의 무선 범위 내의 임의의 STA들(104)이 AP(102)와 "연관되거나" 또는 재연관되어, AP(102)와의 개개의 통신 링크(108)(이후 또한, "Wi-Fi 링크"로 지칭됨)를 확립하는 것 또는 AP(102)와의 통신 링크(108)를 유지하는 것을 가능하게 하기 위해, BSSID를 포함하는 비콘 프레임들("비콘들")을 주기적으로 브로드캐스트한다. 예컨대, 비콘들은 AP(102)와의 타이밍 동기화를 확립하거나 유지하기 위한 타이밍 동기화 기능뿐만 아니라 개개의 AP(102)에 의해 사용되는 프라이머리 채널(primary channel)의 식별(identification)을 포함할 수 있다. AP(102)는 개개의 통신 링크들(108)을 통해 WLAN 내의 다양한 STA들(104)에 대한 외부 네트워크들로의 액세스를 제공할 수 있다.

[0055] AP(102)와의 통신 링크(108)를 확립하기 위해, STA들(104) 각각은 하나 이상의 주파수 대역들(예컨대, 2.4 GHz, 5.0 GHz, 6.0 GHz, 또는 60 GHz 대역들) 내의 주파수 채널들 상에서 수동 또는 능동 스캐닝 동작들("스캔들")을 수행하도록 구성된다. 수동 스캐닝을 수행하기 위해, STA(104)는 TBTT(target beacon transmission time)(TU(time unit)들에서 측정되고 여기서 하나의 TU는 1024 마이크로초(㎲)와 동일할 수 있음)로 지칭되는 주기적 시간 인터벌로 각각의 AP들(102)에 의해 송신되는 비콘들을 청취한다. 능동 스캐닝을 수행하기 위해, STA(104)는 스캐닝될 각각의 채널 상에서 프로브 요청들을 생성 및 순차적으로 송신하고, AP들(102)로부터 프로브 응답들을 청취한다. 각각의 STA(104)는, 수동 또는 능동 스캔들을 통해 획득된 스캐닝 정보에 기반하여 연관될 AP(102)를 식별하거나 또는 선택하도록 그리고 선택된 AP(102)와의 통신 링크를(108) 확립하기 위해 인증 및 연관 동작들을 수행하도록 구성될 수 있다. AP(102)는, AP(102)가 STA(104)를 추적하기 위해 사용하는 연관 동작들의 절정(culmination)에서 AID(association identifier)를 STA(104)에 할당한다.

[0056] 무선 네트워크들의 증가하는 편재성(ubiquity)의 결과로서, STA(104)는, STA의 레인지(range) 내의 많은 BSS들 중 하나를 선택하거나 또는 다수의 연결된 BSS들을 포함하는 ESS(extended service set)를 함께 형성하는 다수의 AP들(102) 사이에서 선택하는 기회를 가질 수 있다. WLAN(100)과 연관된 확장된 네트워크 스테이션(미도시)은, 다수의 AP들(102)이 이러한 ESS에서 접속되도록 허용할 수 있는 유선 또는 무선 분배 시스템에 접속될 수 있다. 따라서, STA(104)는 하나 초과의 AP(102)에 의해 커버될 수 있고, 상이한 송신들을 위해 상이한 시간들에 상이한 AP들(102)과 연관될 수 있다. 부가적으로, AP(102)와의 연관 이후, STA(104)는 또한 연관되기에 더 적합한 AP(102)를 발견하기 위해 자신의 주위를 주기적으로 스캔하도록 구성될 수 있다. 예컨대, 자신의 연관된 AP(102)에 대해 이동하고 있는 STA(104)는, 더 큰 RSSI(received signal strength indicator) 또는 감소된 트래픽 로드와 같은 더 바람직한 네트워크 특성들을 갖는 다른 AP(102)를 발견하기 위해 "로밍" 스캔을 수행할 수 있다.

[0057] 일부 경우들에서, STA들(104)은, STA들(104) 자체 이외의 다른 장비 또는 AP들(102) 없이, 네트워크들을 형성할 수 있다. 이러한 네트워크의 일 예는 애드 혹(ad hoc) 네트워크(또는 무선 애드 혹 네트워크)이다. 애드 혹 네트워크는 대안적으로, 메시 네트워크들 또는 P2P(peer-to-peer) 네트워크들로 지칭될 수 있다. 일부 경우들에서, 애드 혹 네트워크들은, WLAN(100)과 같은 더 큰 무선 네트워크 내에서 구현될 수 있다. 이러한 구현들에서, STA들(104)은 통신 링크들(108)을 사용하여 AP(102)를 통해 서로 통신할 수 있지만, STA들(104)은 또한 다이렉트 무선 링크들(110)을 통해 서로 직접 통신할 수 있다. 부가적으로, 2개의 STA들(104)은, STA들(104) 둘 모두가 동일한 AP(102)와 연관되고 그 동일한 AP(102)에 의해 서빙되는지 여부에 관계없이, 다이렉트 통신 링크(110)를 통해 통신할 수 있다. 그러한 애드 혹 시스템에서, STA들(104) 중 하나 이상은 BSS에서 AP(102)에 의해 이행(fill)되는 역할을 가정할 수 있다. 그러한 STA(104)는 GO(group owner)로 지칭될 수 있으며 애드 혹 네트워크 내의 송신들을 조정할 수 있다. 다이렉트 무선 링크들(110)의 예들은 Wi-Fi 다이렉트 연결들, WiFi TDLS(Tunneled Direct Link Setup) 링크를 사용함으로써 확립된 연결들, 및 다른 P2P 그룹 연결들을 포함한다.

[0058] AP들(102) 및 STA들(104)은 IEEE 802.11 표준군(이를테면, IEEE 802.11-2016 규격 또는 802.11ah, 802.11ad, 802.11ay, 802.11ax, 802.11az, 802.11ba, 및 802.11be를 포함하는(그러나 이것들로 제한되지는 않음) 그것의 개정안들에 의해 정의된 것)에 따라 (개개의 통신 링크들(108)을 통해) 기능 및 통신할 수 있다. 이러한 표준들은 PHY 및 MAC(medium access control) 계층들에 대한 WLAN 라디오 및 기저대역 프로토콜들을 정의한다. AP들(102) 및 STA들(104)은 PPDU(PLCP(physical layer convergence protocol) protocol data unit)들의 형태로 서로에게 그리고 서로로부터 무선 통신들(이후, "Wi-Fi 통신들"로 또한 지칭됨)을 송신하고 수신한다. WLAN(100) 내의 AP들(102) 및 STA들(104)은 비면허 스펙트럼을 통해 PPDU들을 송신할 수 있고, 이는 2.4 GHz 대역, 5.0 GHz 대역, 60 GHz 대역, 3.6 GHz 대역, 및 900 MHz 대역과 같은 Wi-Fi 기술에 의해 종래에 사용된 주파수 대역들을 포함하는 스펙트럼의 일부분일 수 있다. 본원에서 설명되는 AP들(102) 및 STA들(104)의 일부 구현들은 또한 6.0 GHz 대역과 같은 다른 주파수 대역들에서 통신할 수 있고, 이는 면허 및 비면허 통신들 둘 모두를 지원할 수 있다. AP들(102) 및 STA들(104)은 또한, 다수의 운영자들이 동일한 또는 중첩하는 주파수 대역 또는 대역들에서 동작하기 위한 면허를 가질 수 있는 공유된 면허 주파수 대역들과 같은 다른 주파수 대역들을 통해 통신하도록 구성될 수 있다.

[0059] 주파수 대역들 각각은 다수의 서브-대역들 또는 주파수 채널들을 포함할 수 있다. 예컨대, IEEE 802.11n, 802.11ac, 및 802.11ax 표준 개정안들을 따르는 PPDU들은 2.4 및 5.0 GHz 대역들을 통해 송신될 수 있으며, 이들 각각은 다수의 20 MHz 채널들로 분할된다. 따라서, 이들 PPDU들은 20 MHz의 최소 대역폭을 갖는 물리적 채널을 통해 송신되지만, 채널 본딩(channel bonding)을 통해 더 큰 채널들이 형성될 수 있다. 예컨대, PPDU들은 다수의 20 MHz 채널들 함께 본딩함으로써 40 MHz, 80 MHz, 160 또는 320 MHz의 대역폭들을 갖는 물리적 채널들을 통해 송신될 수 있다.

[0060] 각각의 PPDU는 PSDU(PLCP service data unit) 형태의 페이로드 및 PHY 프리앰블을 포함하는 복합 구조이다. 프리앰블에서 제공되는 정보는 PSDU 내의 후속 데이터를 디코딩하기 위해 수신 디바이스에 의해 사용될 수 있다. PPDU들이 본딩된 채널을 통해 송신되는 예시들에서, 프리앰블 필드들은 다수의 컴포넌트 채널들 각각에서 복제(duplicate)되어 송신될 수 있다. PHY 프리앰블은 레거시(legacy) 부분(또는 "레거시 프리앰블") 및 비-레거시(non-legacy) 부분(또는 "비-레거시 프리앰블") 둘 모두를 포함할 수 있다. 레거시 프리앰블은, 다른 용도들 중에서도, 패킷 검출, 자동 이득 제어 및 채널 추정을 위해 사용될 수 있다. 레거시 프리앰블은 또한 일반적으로, 레거시 디바이스들과의 호환성을 유지하는 데 사용될 수 있다. 프리앰블의 비-레거시 부분에서 제공되는 정보의 포맷 및 코딩은 페이로드를 송신하는 데 사용될 특정 IEEE 802.11 프로토콜에 기반한다.

[0061] 도 2a는 AP와 다수의 STA들 간의 통신들에 사용가능한 예시적인 PDU(protocol data unit)(200)를 도시한다. 예컨대, PDU(200)는 PPDU로서 구성될 수 있다. 도시된 바와 같이, PDU(200)는 PHY 프리앰블(202) 및 PHY 페이로드(204)를 포함한다. 예컨대, PHY 프리앰블(202)은 L-STF(legacy short training field)(206), L-LTF(legacy long training field)(208), 및 L-SIG(legacy signaling field)(210)를 자체적으로 포함하는 레거시 부분을 포함할 수 있다. PHY 프리앰블(202)은 또한 비-레거시 부분(미도시)을 포함할 수 있다. L-STF(206)는 일반적으로 수신 디바이스가 AGC(automatic gain control) 및 개략적인 타이밍 및 주파수 추정을 수행할 수 있게 한다. L-LTF(208)는 일반적으로 수신 디바이스가 정밀한 타이밍 및 주파수 추정을 수행하고 또한 무선 채널을 추정할 수 있게 한다. L-SIG(210)는 일반적으로 수신 디바이스가 PDU의 지속기간을 결정하고 결정된 지속기간을 사용하여 PDU 외의 송신을 방지할 수 있게 한다. 예컨대, L-STF(206), L-LTF(208) 및 L-SIG(210)는 BPSK(binary phase shift keying) 변조 방식에 따라 변조될 수 있다. 페이로드(204)는 BPSK 변조 방식, Q-BPSK(quadrature BPSK) 변조 방식, QAM(quadrature amplitude modulation) 변조 방식 또는 다른 적절한 변조 방식에 따라 변조될 수 있다. 페이로드(204)는 일반적으로, 예컨대, MPDU(medium access control (MAC) protocol data unit)들 또는 A-MPDU(aggregated MPDU)들의 형태로 상위 계층 데이터를 반송할 수 있다.

[0062] 도 2b는 도 2a의 PDU의 예시적인 L-SIG 필드(220)를 도시한다. L-SIG(220)는 데이터 레이트 필드(222), 예비 비트(reserved bit)(224), 길이 필드(226), 패리티 비트(228) 및 테일 필드(tail field)(220)를 포함한다. 데이터 레이트 필드(222)는 데이터 레이트를 표시한다(데이터 레이트 필드(222)에 표시된 데이터 레이트는 페이로드(204)에서 반송되는 데이터의 실제 데이터 레이트가 아닐 수 있음을 유의한다). 길이 필드(226)는 패킷의 길이를 예컨대 바이트 단위로 표시한다. 패리티 비트(228)는 비트 에러들을 검출하기 위해 사용된다. 테일 필드(220)는 디코더(예컨대, 비터비(Viterbi) 디코더)의 동작을 종료하기 위해 수신 디바이스에 의해 사용되는 테일 비트들을 포함한다. 수신 디바이스는 예컨대, 마이크로초(μs) 단위로 패킷의 지속기간을 결정하기 위해, 데이터 레이트 필드(222) 및 길이 필드(226)에 표시된 데이터 레이트 및 길이를 활용한다.

[0063] 도 3a는 AP와 하나 이상의 STA들 간의 무선 통신에 사용가능한 다른 예시적인 PDU(300)를 도시한다. PDU(300)는 SU, OFDMA 또는 MU-MIMO 송신들을 위해 사용될 수 있다. PDU(300)는 IEEE 802.11 무선 통신 프로토콜 표준에 대한 IEEE 802.11ax 개정안에 따라 HE(High Efficiency) WLAN PPDU로서 포맷팅될 수 있다. PDU(300)는, 레거시 부분(302) 및 비-레거시 부분(304)을 포함하는 PHY 프리앰블을 포함한다. PDU(300)는, 프리앰블 이후에, 예컨대 데이터 필드(324)를 포함하는 PSDU의 형태로 PHY 페이로드(306)를 더 포함할 수 있다.

[0064] 프리앰블의 레거시 부분(302)은 L-STF(308), L-LTF(310), 및 L-SIG(312)를 포함한다. 비-레거시 부분(304)은, RL-SIG(repetition of L-SIG)(314), 제1 HE-SIG-A(HE signal field)(316), HE-STF(HE short training field)(320) 및 하나 이상의 HE 롱 트레이닝 필드들(또는 심볼들)(HE-LTF들)(322)을 포함한다. OFDMA 또는 MU-MIMO 통신들의 경우, 제2 부분(304)은 HE-SIG-A(316)와 별개로 인코딩된 제2 HE-SIG-B(HE signal field)(318)를 더 포함한다. L-STF(308), L-LTF(310) 및 L-SIG(312)와 마찬가지로, RL-SIG(314) 및 HE-SIG-A(316)의 정보는, 본딩된 채널의 사용을 수반하는 인스턴스들에서 컴포넌트 20 MHz 채널들 각각에서 복제되어 송신될 수 있다. 대조적으로, HE-SIG-B(318)의 콘텐츠는 각각의 20 MHz 채널 및 타깃 특정 STA들(104)에 고유할 수 있다.

[0065] RL-SIG(314)는, PDU(300)가 HE PPDU임을 HE-호환가능 STA들(104)에게 표시할 수 있다. AP(102)는, HE-SIG-A(316)를 사용하여, AP가 다수의 STA들(104)에 대한 UL 또는 DL 자원들을 스케줄링했음을 식별하고 이들에게 통지할 수 있다. 예컨대, HE-SIG-A(316)는 식별된 STA들(104)에 대한 자원 배정들을 표시하는 자원 배정 서브필드를 포함할 수 있다. HE-SIG-A(316)는 AP(102)에 의해 서빙되는 각각의 HE-호환가능 STA(104)에 의해 디코딩될 수 있다. MU 송신들의 경우, HE-SIG-A(316)는 연관된 HE-SIG-B(318)를 디코딩하기 위해 각각의 식별된 STA(104)에 의해 사용가능한 정보를 더 포함한다. 예컨대, HE-SIG-A(316)는, 다른 예들 중에서도, HE-SIG-B들(318)의 로케이션들 및 길이들, 이용가능한 채널 대역폭들 및 MCS(modulation and coding scheme)들을 포함하는 프레임 포맷을 표시할 수 있다. HE-SIG-A(316)는 또한, 식별된 STA들(104) 이외의 STA들(104)에 의해 사용가능한 HE WLAN 시그널링 정보를 포함할 수 있다.

[0066] HE-SIG-B(318)는, 예컨대, STA-특정(또는 "사용자-특정") MCS 값들 및 STA-특정 RU 배정 정보와 같은 STA-특정 스케줄링 정보를 반송할 수 있다. DL MU-OFDMA의 맥락에서, 이러한 정보는 개개의 STA들(104)이 연관된 데이터 필드(324)에서 대응하는 RU(resource unit)들을 식별 및 디코딩할 수 있게 한다. 각각의 HE-SIG-B(318)는 공통 필드 및 적어도 하나의 STA-특정 필드를 포함한다. 공통 필드는, 다른 예들 중에서도, 주파수 도메인에서의 RU 할당들을 포함하는 RU 배정들을 다수의 STA들(104)에 표시하고, MU-MIMO 송신들에 대해 어느 RU들이 배정되는지, 어느 RU들이 MU-OFDMA 송신들에 대응하는지, 및 배정들에서의 사용자들의 수를 표시할 수 있다. 공통 필드는 공통 비트들, CRC 비트들 및 테일 비트들로 인코딩될 수 있다. 사용자-특정 필드들은 특정 STA들(104)에 할당되며, 그리고 특정 RU들을 스케줄링하기 위해 그리고 다른 WLAN 디바이스들에 스케줄링을 표시하기 위해 사용될 수 있다. 각각의 사용자-특정 필드는 다수의 사용자 블록 필드들을 포함할 수 있다. 각각의 사용자 블록 필드는, 2개의 개개의 STA들이 데이터 필드(324)에서 그들의 개개의 RU 페이로드들을 디코딩하기 위한 정보를 포함하는 2개의 사용자 필드들을 포함할 수 있다.

[0067] 도 3b는 AP와 하나 이상의 STA들 사이의 무선 통신에 사용가능한 다른 예시적인 PPDU(350)를 도시한다. PDU(350)는 SU, OFDMA 또는 MU-MIMO 송신들을 위해 사용될 수 있다. PDU(350)는 IEEE 802.11 무선 통신 프로토콜 표준에 대한 IEEE 802.11be 개정안에 따라 EHT(Extreme High Throughput) WLAN PPDU로서 포맷팅될 수 있거나, 또는 미래의 IEEE 802.11 무선 통신 프로토콜 표준 또는 다른 무선 통신 표준을 준수하는 새로운 무선 통신 프로토콜의 임의의 나중 (포스트-EHT) 버전을 준수하는 PPDU로서 포맷팅될 수 있다. PDU(350)는, 레거시 부분(352) 및 비-레거시 부분(354)을 포함하는 PHY 프리앰블을 포함한다. PDU(350)는, 프리앰블 이후에, 예컨대 데이터 필드(376)를 포함하는 PSDU의 형태로 PHY 페이로드(356)를 더 포함할 수 있다.

[0068] 프리앰블의 레거시 부분(352)은 L-STF(358), L-LTF(360), 및 L-SIG(362)를 포함한다. 프리앰블의 비-레거시 부분(354)은 RL-SIG(364) 및 RL-SIG(364) 이후의 다수의 무선 통신 프로토콜 버전-종속적 신호 필드들을 포함한다. 예컨대, 비-레거시 부분(354)은 범용 신호 필드(366)(본원에서 "U-SIG(366)"로 지칭됨) 및 EHT 신호 필드(368)(본원에서 "EHT-SIG(368)"로 지칭됨)를 포함할 수 있다. U-SIG(366) 및 EHT-SIG(368) 중 하나 또는 둘 모두는, EHT 이외의 다른 무선 통신 프로토콜 버전들로서 구조화될 수 있고, 이러한 다른 무선 통신 프로토콜 버전들에 대한 버전-종속적 정보를 반송할 수 있다. 비-레거시 부분(354)은 추가적인 쇼트 트레이닝 필드(372)(본원에서는 "EHT-STF(372)"로 지칭되지만, 이는 EHT 이외의 다른 무선 통신 프로토콜 버전들로서 구조화되고 이러한 다른 무선 통신 프로토콜 버전들에 대한 버전-종속적 정보를 반송할 수 있음), 및 하나 이상의 추가적인 롱 트레이닝 필드(374)(본원에서는 "EHT-LTF들(374)"로 지칭되지만, 이들은 EHT 이외의 다른 무선 통신 프로토콜 버전들로서 구조화되고 이러한 다른 무선 통신 프로토콜 버전들에 대한 버전-종속적 정보를 반송할 수 있음)를 더 포함한다. L-STF(358), L-LTF(360) 및 L-SIG(362)와 마찬가지로, U-SIG(366) 및 EHT-SIG(368)의 정보는, 본딩된 채널의 사용을 수반하는 인스턴스들에서 컴포넌트 20 MHz 채널들 각각에서 복제되어 송신될 수 있다. 일부 구현들에서, EHT-SIG(368)는 부가적으로 또는 대안적으로, 프라이머리 20 MHz 채널에서 반송되는 정보와 상이한 정보를 하나 이상의 비-프라이머리 20 MHz 채널들에서 반송할 수 있다.

[0069] EHT-SIG(368)는 하나 이상의 공동으로 인코딩된 심볼을 포함할 수 있고, U-SIG(366)가 인코딩된 블록과 다른 블록에서 인코딩될 수 있다. EHT-SIG(368)는, AP가 다수의 STA들(104)에 대한 UL 또는 DL 자원을 스케줄링했음을 식별하고 이들에게 통지하기 위해 AP에 의해 사용될 수 있다. EHT-SIG(368)는 AP(102)에 의해 서빙되는 각각의 호환가능 STA(104)에 의해 디코딩될 수 있다. EHT-SIG(368)는 일반적으로, 데이터 필드(376)의 비트를 해석하기 위해 수신 디바이스에 의해 사용될 수 있다. 예컨대, EHT-SIG(368)는, 다른 예들 중에서도, RU 배정 정보, 공간 스트림 구성 정보, 및 MCS와 같은 사용자별 시그널링 정보를 포함할 수 있다. EHT-SIG(368)는 BCC(binary convolutional code)에 사용될 수 있는 CRC(cyclic redundancy check)(예컨대, 4 비트) 및 테일(예컨대, 6 비트)을 더 포함할 수 있다. 일부 구현들에서, EHT-SIG(368)는, 각각 CRC 및 테일을 포함하는 하나 이상의 코드 블록들을 포함할 수 있다. 일부 양상들에서, 코드 블록들 각각은 개별적으로 인코딩될 수 있다.

[0070] EHT-SIG(368)는, 예컨대, 사용자-특정 MCS 값들 및 사용자-특정 RU 배정 정보와 같은 STA-특정 스케줄링 정보를 반송할 수 있다. EHT-SIG(368)는 일반적으로, 데이터 필드(376)의 비트를 해석하기 위해 수신 디바이스에 의해 사용될 수 있다. DL MU-OFDMA의 맥락에서, 이러한 정보는 개개의 STA들(104)이 연관된 데이터 필드(376)에서 대응하는 RU들을 식별 및 디코딩할 수 있게 한다. 각각의 EHT-SIG(368)는 공통 필드 및 적어도 하나의 사용자-특정 필드를 포함할 수 있다. 공통 필드는, 다른 예들 중에서도, 다수의 STA들(104)에 대한 RU 분포들을 표시하고, 주파수 도메인에서의 RU 할당들을 표시하고, MU-MIMO 송신들에 대해 어느 RU들이 배정되는지, 어느 RU들이 MU-OFDMA 송신들에 대응하는지, 및 배정들에서의 사용자들의 수를 표시할 수 있다. 공통 필드는 공통 비트들, CRC 비트들 및 테일 비트들로 인코딩될 수 있다. 사용자-특정 필드들은 특정 STA들(104)에 할당되며, 그리고 특정 RU들을 스케줄링하기 위해 그리고 다른 WLAN 디바이스들에 스케줄링을 표시하기 위해 사용될 수 있다. 각각의 사용자-특정 필드는 다수의 사용자 블록 필드들을 포함할 수 있다. 각각의 사용자 블록 필드는, 예컨대, 2개의 개개의 STA들이 그들의 개개의 RU 페이로드들을 디코딩하기 위한 정보를 포함하는 2개의 사용자 필드들을 포함할 수 있다.

[0071] RL-SIG(364) 및 U-SIG(366)의 존재는, PPDU(350)가 EHT PPDU임을, 또는 미래의 IEEE 802.11 무선 통신 프로토콜 표준을 따르는 새로운 무선 통신 프로토콜의 임의의 이후의(포스트-EHT) 버전을 따르는 PPDU임을 EHT- 또는 이후의 버전-준수 STA들(104)에 표시할 수 있다. 예컨대, U-SIG(366)는 EHT-SIG(368) 또는 데이터 필드(376) 중 하나 이상 내의 비트들을 해석하기 위해 수신 디바이스에 의해 사용될 수 있다.

[0072] 도 4는 AP(102)와 다수의 STA들(104) 사이의 통신들에 사용가능한 예시적인 PPDU(400)를 도시한다. 위에서 설명된 바와 같이, 각각의 PPDU(400)는 PHY 프리앰블(402) 및 PSDU(404)를 포함한다. 각각의 PSDU(404)는 하나 이상의 MPDU(MAC protocol data unit)들, 예컨대, 다수의 MPDU 서브프레임들(408)을 포함하는 A-MPDU(aggregated MPDU)(406)를 반송할 수 있다. 각각의 MPDU 서브프레임(408)은, 첨부되는 프레임 바디(frame body)(416) 이전에 MAC 구분자(delimiter)(412) 및 MAC 헤더(414)를 포함할 수 있고, 첨부되는 프레임 바디(416)는 MPDU 서브프레임(408)의 데이터 부분 또는 "페이로드"를 포함한다. 프레임 바디(416)는 하나 이상의 MSDU(MAC service data unit)들, 예컨대, 다수의 MSDU 서브프레임들(424)을 포함하는 A-MSDU(aggregated MSDU)(422)를 반송할 수 있다. 각각의 MSDU 서브프레임(424)은, 서브프레임 헤더(428), 프레임 바디(430) 및 하나 이상의 패딩 비트들(432)을 포함하는 대응하는 MSDU(426)를 포함한다.

[0073] A-MPDU 서브프레임(406)을 다시 참조하면, MAC 헤더(414)는, 프레임 바디(416) 내에 캡슐화된 데이터의 특성들 또는 속성들을 정의하거나 표시하는 정보를 포함하는 다수의 필드들을 포함할 수 있다. MAC 헤더(414)는 또한, 프레임 바디(416) 내에 캡슐화된 데이터에 대한 어드레스들을 표시하는 다수의 필드들을 포함한다. 예컨대, MAC 헤더(412)는 소스 어드레스, 송신기 어드레스, 수신기 어드레스, 또는 목적지 어드레스의 조합을 포함할 수 있다. MAC 헤더(414)는 제어 정보를 포함하는 프레임 제어 필드를 포함할 수 있다. 프레임 제어 필드는 프레임 타입, 예컨대, 데이터 프레임, 제어 프레임 또는 관리 프레임을 특정한다. MAC 헤더(414)는 PPDU의 끝에서부터 무선 통신 디바이스에 의해 송신될 마지막 PPDU의 ACK(acknowledgement)(예컨대, A-MPDU의 경우에 BA(block ACK))의 끝까지 연장되는 지속기간을 표시하는 지속기간 필드를 더 포함할 수 있다. 이러한 지속기간 필드의 사용은, 표시된 지속기간 동안 무선 매체를 예비(reserve)하여, NAV를 확립하는 역할을 한다. 각각의 A-MPDU 서브프레임(408)은 또한 에러 검출을 위한 FCS(frame check sequence) 필드(418)를 포함할 수 있다. 예컨대, FCS 필드(418)는 CRC(cyclic redundancy check)를 포함할 수 있고, 하나 이상의 패딩 비트들(420)이 후속할 수 있다.

[0074] 위에서 설명된 바와 같이, AP들(102) 및 STA들(104)은 MU(multi-user) 통신들을 지원할 수 있다. 즉, 하나의 디바이스로부터 다수의 디바이스들 각각으로의 동시 송신들(예컨대, AP(102)로부터 대응하는 STA들(104)로의 다수의 동시 다운링크(DL) 통신들), 또는 다수의 디바이스들로부터 단일 디바이스로의 동시 송신들(예컨대, 대응하는 STA들(104)로부터 AP(102)로의 다수의 동시 업링크(UL) 송신들). MU 송신들을 지원하기 위해, AP들(102) 및 STA들(104)은 MU-MIMO(multi-user multiple-input, multiple-output) 및 MU-OFDMA(multi-user orthogonal frequency division multiple access) 기법들을 활용할 수 있다.

[0075] MU-OFDMA 방식들에서, 무선 채널의 이용 가능한 주파수 스펙트럼은 다수의 RU(resource unit)들로 분할될 수 있고, 각각의 RU는 다수의 상이한 주파수 서브캐리어들("톤들")을 포함한다. 상이한 RU들이 특정 시간들에서 상이한 STA(104)들에 대해 AP(102)에 의해 배정 또는 할당될 수 있다. RU들의 크기들 및 분포들은 RU 배정으로 지칭될 수 있다. 일부 구현들에서, RU들은 2 MHz 인터벌들로 배정될 수 있고, 그에 따라, 가장 작은 RU는 24개의 데이터 톤들 및 2개의 파일럿 톤들로 구성된 26개의 톤들을 포함할 수 있다. 결과적으로, 20 MHz 채널에서, (일부 톤들은 다른 목적들을 위해 예비되기 때문에) 최대 9개의 RU들(이를테면, 2 MHz, 26-톤 RU들)이 배정될 수 있다. 유사하게, 160 MHz 채널에서는, 최대 74개의 RU들이 배정될 수 있다. 더 큰 52 톤, 106 톤, 242 톤, 484 톤 및 996 톤 RU들이 또한 배정될 수 있다. 인접 RU들은, 예컨대, 인접하는 RU들 사이의 간섭을 감소시키고, 수신기 DC 오프셋을 감소시키고, 그리고 송신 중심 주파수 누설을 방지하기 위해, 널 서브캐리어(이를테면, DC 서브캐리어)에 의해 분리될 수 있다.

[0076] UL MU 송신들의 경우, AP(102)는 다수의 STA들(104)로부터 AP(102)로의 UL MU-OFDMA 또는 UL MU-MIMO 송신을 개시하고 동기화하기 위해 트리거 프레임을 송신할 수 있다. 따라서, 그러한 트리거 프레임들은 다수의 STA들(104)이 시간적으로 동시에 UL 트래픽을 AP(102)에 전송하는 것을 가능하게 할 수 있다. 트리거 프레임은 개개의 AID(association identifier)들을 통해 하나 이상의 STA들(104)을 어드레싱할 수 있으며, 그리고 UL 트래픽을 AP(102)에 전송하는 데 사용될 수 있는 하나 이상의 RU들을 각각의 AID (및 그에 따라 각각의 STA(104))에 할당할 수 있다. AP는 또한, 스케줄링되지 않은(unscheduled) STA들(104)이 경합할 수 있는 하나 이상의 RA(random access) RU들을 지정할 수 있다.

[0077] 도 5는 예시적인 무선 통신 디바이스(500)의 블록도를 도시한다. 일부 구현들에서, 무선 통신 디바이스(500)는 도 1을 참조로 위에서 설명된 STA들(104) 중 하나와 같은 STA에서 사용하기 위한 디바이스의 예일 수 있다. 일부 구현들에서, 무선 통신 디바이스(500)는 도 1을 참조로 위에서 설명된 AP(102)와 같은 AP에서 사용하기 위한 디바이스의 예일 수 있다. 무선 통신 디바이스(500)는 무선 통신들을 (예컨대, 무선 패킷들의 형태로) 송신(또는 송신을 위해 출력) 및 수신할 수 있다. 예컨대, 무선 통신 디바이스(500)는 IEEE 802.11 표준, 이를테면 IEEE 802.11-2016 규격 또는 802.11ah, 802.11ad, 802.11ay, 802.11ax, 802.11az, 802.11ba, 및 802.11be를 포함하는(그러나 이것들로 제한되지는 않음) 그것의 개정안들에 의해 정의된 것을 준수하는 PPDU(PLCP(physical layer convergence protocol) protocol data unit)들 및 MPDU(MAC(medium access control) protocol data unit)들의 형태의 패킷들을 송신 및 수신하도록 구성될 수 있다.

[0078] 무선 통신 디바이스(500)는 칩, SoC(system on chip), 칩셋, 패키지, 또는 하나 이상의 모뎀들(502), 예컨대 Wi-Fi(IEEE 802.11 준수) 모뎀을 포함하는 디바이스일 수 있거나 또는 이를 포함할 수 있다. 일부 구현들에서, 하나 이상의 모뎀들(502)(총괄하여 "모뎀(502)")은 부가적으로, WWAN 모뎀(예컨대, 3GPP 4G LTE 또는 5G 준수 모뎀)을 포함한다. 일부 구현들에서, 무선 통신 디바이스(500)는 또한, 하나 이상의 라디오들(504)(총괄하여 "라디오(504)")을 포함한다. 일부 구현들에서, 무선 통신 디바이스(500)는 하나 이상의 프로세서들, 프로세싱 블록들 또는 프로세싱 엘리먼트들(506)(총괄적으로 "프로세서(506)"), 및 하나 이상의 메모리 블록들 또는 엘리먼트들(508)(총괄적으로 "메모리(508)")을 더 포함한다.

[0079] 모뎀(502)은 다른 가능성들 중에서, 예컨대 ASIC(application-specific integrated circuit)와 같은 지능형 하드웨어 블록 또는 디바이스를 포함할 수 있다. 모뎀(502)은 일반적으로, PHY 계층을 구현하도록 구성된다. 예컨대, 모뎀(502)은, 패킷들을 변조하고 변조된 패킷들을 무선 매체를 통한 송신을 위해 라디오(504)에 출력하도록 구성된다. 모뎀(502)은 유사하게, 라디오(504)에 의해 수신된 변조된 패킷들을 획득하도록 그리고 패킷들을 복조하여 복조된 패킷들을 제공하도록 구성된다. 변조기 및 복조기에 추가하여, 모뎀(502)은 DSP(digital signal processing) 회로, AGC(automatic gain control), 코더, 디코더, 다중화기, 및 역다중화기를 더 포함할 수 있다. 예컨대, 송신 모드에 있는 동안, 프로세서(506)로부터 획득된 데이터는 코더에 제공되고, 코더는 데이터를 인코딩하여 인코딩된 비트들을 제공한다. 그런 다음, 인코딩된 비트들은, 변조된 심볼들을 제공하기 위해 (선택된 MCS를 사용하여) 변조 성상도(modulation constellation)의 포인트들에 맵핑된다. 그런 다음, 변조된 심볼들은 공간 스트림들의 수(N_SS) 또는 공간-시간 스트림들의 수(N_STS)에 맵핑될 수 있다. 그런 다음, 개개의 공간 또는 공간-시간 스트림들 내의 변조된 심볼들은 멀티플렉싱되고, IFFT(inverse fast Fourier transform) 블록을 통해 변환되고, 그리고 후속적으로 Tx 윈도우잉(windowing) 및 필터링을 위해 DSP 회로부에 제공될 수 있다. 그런 다음, 디지털 신호들은 DAC(digital-to-analog converter)에 제공될 수 있다. 그런 다음, 결과적인 아날로그 신호들은 주파수 상향변환기, 그리고 궁극적으로 라디오(504)에 제공될 수 있다. 빔포밍을 수반하는 구현들에서, 개개의 공간 스트림들 내의 변조된 심볼들은, 이들이 IFFT 블록에 제공되기 전에, 스티어링 매트릭스를 통해 프리코딩된다.

[0080] 수신 모드에 있는 동안, 라디오(504)로부터 수신되는 디지털 신호들은 DSP 회로부에 제공되며, 이러한 DSP 회로부는, 예컨대, 신호의 존재를 검출하고 그리고 최초 타이밍 및 주파수 오프셋들을 추정함으로써, 수신되는 신호를 획득하도록 구성된다. DSP 회로부는, 궁극적으로 협대역 신호를 획득하기 위해, 예컨대, 채널(협대역) 필터링, 아날로그 손상 컨디셔닝(이를테면, I/Q 불균형 교정)을 사용하고 그리고 디지털 이득을 적용함으로써, 디지털 신호들을 디지털 방식으로 컨디셔닝하도록 추가로 구성된다. 그런 다음, DSP 회로부의 출력이 AGC에 공급될 수 있고, 이 AGC는 적절한 이득을 결정하기 위해, 예컨대 하나 이상의 수신된 트레이닝 필드들에서, 디지털 신호들로부터 추출된 정보를 사용하도록 구성된다. DSP 회로부의 출력은 또한 복조기와 커플링되며, 이 복조기는 신호로부터 변조된 심볼들을 추출하도록 그리고 예컨대, 각각의 공간 스트림에서 각각의 서브캐리어의 각각의 비트 포지션에 대한 LLR(logarithm likelihood ratio)들을 컴퓨팅하도록 구성된다. 복조기는 디코더와 커플링되며, 이러한 디코더는 디코딩된 비트들을 제공하기 위해 LLR들을 프로세싱하도록 구성될 수 있다. 그런 다음, 모든 공간 스트림들로부터의 디코딩된 비트들은 디멀티플렉싱을 위해 디멀티플렉서에 공급된다. 그런 다음, 역다중화된 비트들은 디스크램블링되고, 프로세싱, 평가 또는 해석을 위해 MAC 계층(프로세서(506))에 제공될 수 있다.

[0081] 라디오(504)는 일반적으로, 하나 이상의 트랜시버들로 결합될 수 있는, 적어도 하나의 RF(radio frequency) 송신기(또는 "송신기 체인") 및 적어도 하나의 RF 수신기(또는 "수신기 체인")를 포함한다. 예컨대, RF 송신기들 및 수신기들은, 각각, 적어도 하나의 PA(power amplifier) 및 적어도 하나의 LNA(low-noise amplifier)를 포함하는 다양한 DSP 회로부를 포함할 수 있다. RF 송신기들 및 수신기들은 차례로 하나 이상의 안테나들에 커플링될 수 있다. 예컨대, 일부 구현들에서, 무선 통신 디바이스(500)는 다수의 송신 안테나들(각각은 대응하는 송신 체인을 가짐) 및 다수의 수신 안테나들(각각은 대응하는 수신 체인을 가짐)을 포함하거나 이것들과 결합될 수 있다. 모뎀(502)으로부터 출력된 심볼들은 라디오(504)에 제공되고, 이어서 라디오(504)는 커플링된 안테나들을 통해 심볼들을 송신한다. 유사하게, 안테나들을 통해 수신된 심볼들은 라디오(504)에 의해 획득되고, 이어서 라디오(504)는 심볼들을 모뎀(502)에 제공한다.

[0082] 프로세서(506)는 지능형 하드웨어 블록 또는 디바이스, 이를테면, 예컨대 프로세싱 코어, 프로세싱 블록, CPU(central processing unit), 마이크로프로세서, 마이크로제어기, DSP(digital signal processor), ASIC(application-specific integrated circuit), PLD(programmable logic device), 이를테면 FPGA(field programmable gate array), 이산 게이트 또는 트랜지스터 로직, 이산 하드웨어 컴포넌트들, 또는 본원에서 설명된 기능들을 수행하도록 설계된 이것들의 임의의 조합을 포함할 수 있다. 프로세서(506)는 라디오(504) 및 모뎀(502)을 통해 수신된 정보를 프로세싱하고, 무선 매체를 통한 송신을 위해 모뎀(502) 및 라디오(504)를 통해 출력될 정보를 프로세싱한다. 예컨대, 프로세서(506)는 MPDU들, 프레임들 또는 패킷들의 생성 및 송신과 관련된 다양한 동작들을 수행하도록 구성된 제어 평면 및 MAC 계층을 구현할 수 있다. MAC 계층은, 다른 동작들 또는 기법들 중에서도, 프레임들의 코딩 및 디코딩, 공간 멀티플렉싱, STBC(space-time block coding), 빔포밍, 및 OFDMA 자원 배정을 수행하거나 이를 가능하게 하도록 구성된다. 일부 구현들에서, 프로세서(506)는 일반적으로 모뎀(502)으로 하여금 위에서 설명된 다양한 동작들을 수행하게 하도록 모뎀(502)을 제어할 수 있다.

[0083] 메모리(508)는 RAM(random-access memory) 또는 ROM(read-only memory), 또는 이들의 조합들과 같은 유형의(tangible) 저장 매체들을 포함할 수 있다. 메모리(508)는 또한 명령들을 포함하는 비-일시적인 프로세서- 또는 컴퓨터-실행가능 소프트웨어(SW) 코드를 저장할 수 있고, 그 명령들은 프로세서(506)에 의해 실행될 때, 그 프로세서로 하여금 MPDU들, 프레임들 또는 패킷들의 생성, 송신, 수신, 및 해석을 포함하는 무선 통신을 위한 본원에서 설명된 다양한 동작들을 수행하게 한다. 예컨대, 본원에서 개시된 컴포넌트들의 다양한 기능들, 또는 본원에서 개시된 방법, 동작, 프로세스 또는 알고리즘의 다양한 블록들 또는 단계들은 하나 이상의 컴퓨터 프로그램들의 하나 이상의 모듈들로서 구현될 수 있다.

[0084] 도 6a는 예시적인 AP(602)의 블록도를 도시한다. 예컨대, AP(602)는 도 1을 참조로 설명된 AP(102)의 예시적인 구현일 수 있다. AP(602)는 WCD(wireless communication device)(610)를 포함한다. 예컨대, 무선 통신 디바이스(610)는 도 5를 참조하여 설명된 무선 통신 디바이스(500)의 예시적인 구현일 수 있다. AP(602)는 또한 무선 통신들을 송신 및 수신하기 위해 무선 통신 디바이스(610)와 커플링된 다수의 안테나들(620)을 포함한다. 일부 구현들에서, AP(602)는 추가적으로 무선 통신 디바이스(610)와 커플링된 애플리케이션 프로세서(630) 및 애플리케이션 프로세서(630)와 커플링된 메모리(640)를 포함한다. AP(602)는, AP(602)가 인터넷을 포함하는 외부 네트워크들로의 액세스를 얻기 위해 코어 네트워크 또는 백홀 네트워크와 통신할 수 있게 하는 적어도 하나의 외부 네트워크 인터페이스(650)를 더 포함한다. 예컨대, 외부 네트워크 인터페이스(650)는 유선(예컨대, 이더넷) 네트워크 인터페이스 및 무선 네트워크 인터페이스(예컨대, WWAN 인터페이스) 중 하나 또는 둘 모두를 포함할 수 있다. 전술된 컴포넌트들 중의 컴포넌트들은 이러한 컴포넌트들 중의 다른 컴포넌트들과 적어도 하나의 버스를 통해 간접적으로 또는 직접적으로 통신할 수 있다. AP(602)는 무선 통신 디바이스(610), 애플리케이션 프로세서(630), 메모리(640), 및 안테나들(620) 및 외부 네트워크 인터페이스(650)의 적어도 일부들을 포함하는 하우징을 더 포함한다.

[0085] 도 6b는 예시적인 STA(604)의 블록도를 도시한다. 예컨대, STA(604)는 도 1을 참조로 설명된 STA(104)의 예시적인 구현일 수 있다. STA(604)는 무선 통신 디바이스(615)를 포함한다. 예컨대, 무선 통신 디바이스(615)는 도 5를 참조하여 설명된 무선 통신 디바이스(500)의 예시적인 구현일 수 있다. STA(604)는 또한 무선 통신들을 송신 및 수신하기 위해 무선 통신 디바이스(615)와 커플링된 하나 이상의 안테나들(625)을 포함한다. STA(604)는 추가적으로 무선 통신 디바이스(615)와 커플링된 애플리케이션 프로세서(635) 및 애플리케이션 프로세서(635)와 커플링된 메모리(645)를 포함한다. 일부 구현들에서, STA(604)는 터치스크린 디스플레이를 형성하기 위해 UI(655)와 통합될 수 있는 UI(user interface)(655)(이를테면, 터치스크린 또는 키패드) 및 디스플레이(665)를 더 포함한다. 일부 구현들에서, STA(604)는 하나 이상의 센서들(675), 이를테면 예컨대 하나 이상의 관성 센서들, 가속도계들, 온도 센서들, 압력 센서들, 또는 고도 센서를 더 포함할 수 있다. 전술된 컴포넌트들 중의 컴포넌트들은 이러한 컴포넌트들 중의 다른 컴포넌트들과 적어도 하나의 버스를 통해 간접적으로 또는 직접적으로 통신할 수 있다. STA(604)는 무선 통신 디바이스(615), 애플리케이션 프로세서(635), 메모리(645), 및 안테나들(625), UI(655) 및 디스플레이(665)의 적어도 일부들을 포함하는 하우징을 더 포함한다.

[0086] 위에서 설명된 바와 같이, IEEE 802.11 표준의 IEEE 802.11be 개정안은 r-TWT SP를 설명하며, 이는 레이턴시-민감 트래픽에 대한 더 높은 신뢰성과 함께, 더 예측가능한 레이턴시, 감소된 최악 경우 레이턴시, 또는 감소된 지터를 제공하는 데 사용될 수 있다. 본원에서 사용되는 바와 같이, "비-레거시 STA"라는 용어는 IEEE 802.11 표준의 IEEE 802.11be 개정안 또는 미래 세대들을 지원하는 임의의 STA를 지칭하는 한편, "저-레이턴시 STA"라는 용어는 전송 또는 수신하기 위한 레이턴시-민감 트래픽을 갖는 임의의 비-레거시 STA를 지칭한다. 대조적으로, "레거시 STA"라는 용어는 IEEE 802.11 표준의 IEEE 802.11ax 또는 이전 세대들만을 지원하는 임의의 STA를 지칭할 수 있다. r-TWT 동작을 지원하고 그리고 r-TWT SP 외부의 TXOP 홀더들인 비-레거시 STA들은, 이들이 멤버가 아닌 임의의 r-TWT SP의 시작 전에 그들의 개개의 TXOP들을 종료해야 한다. 또한, AP는 r-TWT SP와 중첩되도록 콰이어트 인터벌(quiet interval)을 스케줄링함으로써 r-TWT SP 동안 모든 레거시 STA들로부터의 트래픽을 억제할 수 있다. 그러나, 일부 비-레거시 STA들은 r-TWT 동작을 지원하지 않을 수 있고, 따라서, r-TWT SP들 및 콰이어트 인터벌들의 스케줄링을 무시할 수 있다. 일부 예시들에서, 그러한 비-레거시 STA들은 r-TWT SP의 시작 시에 공유 무선 매체를 점유하여, SP의 멤버들인 저-레이턴시 STA들에 대한 액세스를 차단 또는 지연시킬 수 있다. 따라서, r-TWT SP들에서 레이턴시-민감 트래픽을 추가로 보호하기 위해서는, 새로운 통신 프로토콜들 또는 메커니즘들이 필요하다.

[0087] 다양한 양상들은 일반적으로 레이턴시-민감 통신들에 관한 것으로, 보다 구체적으로는, r-TWT SP들과 연관된 레이턴시-민감 트래픽에 r-TWT SP들 동안 충분한 채널 액세스가 제공되게 하여, 그러한 레이턴시-민감 트래픽의 다양한 레이턴시, 스루풋 및 타이밍 요건들을 충족시키도록 보장하는 것에 관한 것이다. 일부 구현들에서, AP는 전송 또는 수신할 저-레이턴시 P2P(peer-to-peer) 데이터를 갖는 저-레이턴시 STA들을 위해 무선 매체에 r-TWT SP를 스케줄링할 수 있다. 일부 예시들에서, AP와 연관된 STA는, 송신 또는 수신할 저-레이턴시 P2P 통신들을 갖는 클라이언트 디바이스와 연관된 코로케이트된 softAP를 포함할 수 있다. softAP 및 그의 클라이언트 디바이스는 P2P 링크와 연관될 수 있고, 그 P2P 링크를 통해, softAP와 클라이언트 디바이스 사이에서 P2P 통신들이 교환될 수 있다. softAP 또는 클라이언트 디바이스 중 어느 것도 AP와 연관되지 않기 때문에, AP는 r-TWT SP들 동안 무선 매체를 통해 송신되는 트리거 프레임들에서 softAP 또는 클라이언트 디바이스를 식별하지 못할 수 있다. 결과적으로, STA가 r-TWT SP 동안 softAP 및 클라이언트 디바이스와 연관된 P2P 통신들을 위해 무선 매체를 사용하고자 의도할 때, softAP 및 클라이언트 디바이스는 그들의 개개의 NAV들을 트리거 프레임에 의해 표시되는 지속기간으로 부주의하게 설정할 수 있고, 그에 따라, r-TWT SP 동안 서로 P2P 통신들을 송신 또는 수신하지 못할 수 있다.

[0088] 일부 구현들에서, AP는, AP와 연관되고 그리고 P2P 링크를 통해 클라이언트 디바이스와 제휴(affiliate)되는 STA로부터 요청 프레임을 수신할 수 있다. 요청 프레임은, STA가 무선 매체에 스케줄링된 r-TWT SP 동안 클라이언트 디바이스와 P2P 통신들을 교환하고자 의도함을 표시한다. 요청 프레임은 클라이언트 디바이스를 식별하고, r-TWT SP에 대한 하나 이상의 TWT 파라미터들을 표시할 수 있다. AP는 요청 프레임에서 수신된 정보에 기반하여 클라이언트 디바이스에 대한 NAV(Network Allocation Vector) 예외를 구성하고, STA에 응답 프레임을 송신할 수 있다. AP는 무선 매체 상에서 TXOP(transmission opportunity)를 획득할 수 있고, r-TWT SP 동안 무선 매체 상에서 트리거 프레임을 송신할 수 있다. 트리거 프레임은 STA와 클라이언트 디바이스 사이의 P2P 통신들을 위해, 획득된 TXOP의 일부를 배정할 수 있다. 응답 프레임 또는 트리거 프레임 중 적어도 하나는 클라이언트 디바이스에 대한 NAV 예외를 표시한다. 일부 예시들에서, NAV 예외는, 클라이언트 디바이스가 트리거 프레임에 의해 표시되는 NAV 지속기간 및 트리거 프레임에 대한 응답으로 CTS(clear-to-send) 프레임에 의해 표시되는 NAV 지속기간을 무시해야 함을 표시한다. 즉, NAV 예외는, 클라이언트 디바이스가 r-TWT SP 동안 송신된 트리거 프레임들에 의해 표시되는 NAV 지속기간들에 기반하여 자신의 NAV를 설정하지 않아야 함을 표시할 수 있다. 일부 예시들에서, STA는, 클라이언트 디바이스와 P2P 링크를 갖거나 또는 P2P 링크를 확립할 수 있는 코로케이트된 softAP를 포함할 수 있다. NAV 예외는 또한, 코로케이트된 softAP에 적용될 수 있어서, 예컨대, 코로케이트된 softAP는 r-TWT SP 동안 송신된 트리거 프레임들에 의해 표시되는 NAV 지속기간들에 기반하여 자신의 NAV를 설정하지 않는다.

[0089] 본 개시내용에서 설명되는 청구대상의 특정한 구현들은 다음의 잠재적인 장점들 중 하나 이상을 실현하도록 구현될 수 있다. AP와 연관되고 r-TWT SP에 속하는 STA들과 코로케이트되거나 또는 제휴되는 softAP들(뿐만 아니라 임의의 연관된 P2P 클라이언트 디바이스들)이 r-TWT SP 동안 AP로부터 송신된 트리거 프레임에 의해 표시되는 지속기간으로 그들의 개개의 NAV들을 설정하지 않아야 함을 표시하는 NAV 예외를 시그널링함으로써, 본 개시내용의 양상들은 그러한 softAP들 및 이들의 연관된 클라이언트 디바이스들이 r-TWT SP의 스케줄링된 부분들 동안 서로 레이턴시 민감 P2P 통신들을 교환할 수 있음을 보장할 수 있다. 이러한 방식으로, 본원에서 개시된 청구대상의 구현들은 P2P 디바이스들 또는 P2P 통신들과 연관된 레이턴시 민감 트래픽에 향상된 채널 보호 메커니즘들이 제공되는 것을 보장할 수 있다.

[0090] 도 7은 일부 구현들에 따른 다른 예시적인 무선 네트워크(700)의 블록도를 도시한다. 일부 양상들에서, 무선 네트워크(700)는 도 1의 WLAN(100)의 예일 수 있다. 무선 네트워크(700)는 AP(702), 제1 무선 STA(station)(710), 제2 STA(720) 및 제3 STA(730)를 포함하는 것으로 도시된다. 일부 구현들에서, AP(702)는 도 1의 AP(102) 또는 도 6a의 AP(602)의 일 예일 수 있고, IEEE 802.11 무선 통신 표준군의 하나 이상의 버전들에 따라 무선 매체 상에서 BSS를 동작시킬 수 있다. STA들(710, 720 및 730)은 도 1의 STA들(104), 도 5의 무선 통신 디바이스(500) 또는 도 6b의 STA(604)의 예들일 수 있다. STA들(710, 720 및 730)은 AP(702)와 연관되고, AP(702)에 의해 동작되는 BSS에 따라 무선 매체 상에서 AP(702)와 통신할 수 있다.

[0091] 도 7의 예에서, 제1 STA(710)는 제1 클라이언트 디바이스(712)와 연관된 제1 softAP(711)와 코로케이트되고, 제2 STA(720)는 제2 클라이언트 디바이스(722)와 연관된 제2 softAP(721)와 코로케이트된다. 제1 softAP(711) 및 제1 클라이언트 디바이스(712)는 P2P 링크(713)를 확립할 수 있고, 그 P2P 링크(713)를 통해, 제1 softAP(711)와 클라이언트 디바이스(712) 사이에서 P2P 통신들이 교환될 수 있다. 제2 softAP(721) 및 제2 클라이언트 디바이스(722)는 P2P 링크(723)를 확립할 수 있고, 그 P2P 링크(723)를 통해, 제2 softAP(721)와 클라이언트 디바이스(722) 사이에서 P2P 통신들이 교환될 수 있다. 일부 예시들에서, P2P 링크들(713 및 723)은 무선 매체 상에서 확립되는 TDLS(tunneled direct-link setup) 링크들일 수 있다. 다른 예시들에서, P2P 링크들(713 및 723)은 Wi-Fi 다이렉트 피어-투-피어 통신 프로토콜에 기반할 수 있다.

[0092] 일부 구현들에서, 제1 STA(710)는, AP(702)와의 무선 통신들을 위한 MAC 계층 기능들 및 클라이언트 디바이스(712)와의 무선 통신들을 위한 MAC 계층 기능들을 독립적으로 수행할 수 있는 별개의 MAC 엔티티들을 포함한다. 예컨대, 제1 STA(710)는 제1 STA(710)에 대응하는 제1 MAC-SAP(MAC service access point) 엔드포인트(endpoint)(S1)를 포함할 수 있고, 제1 softAP(711)에 대응하는 제2 MAC-SAP 엔드포인트(A1)를 포함할 수 있다. 제1 MAC-SAP 엔드포인트(S1)는 AP(702)로부터 무선 매체 상에서 수신되는 프레임들 및 패킷들을 디코딩하는 것을 담당할 수 있고, 제1 STA(710)로부터 AP(702)로 무선 매체를 통해 송신하기 위해 프레임들을 구성 및 포맷팅하는 것을 담당할 수 있다. 제2 MAC-SAP 엔드포인트(A1)는 클라이언트 디바이스(712)로부터 무선 매체 상에서 수신되는 프레임들 및 패킷들을 디코딩하는 것을 담당할 수 있고, 제1 softAP(711)로부터 클라이언트 디바이스(712)로 제1 P2P 링크(713)를 통해 송신하기 위해 프레임들을 구성 및 포맷팅하는 것을 담당할 수 있다. 일부 예시들에서, MAC-SAP 엔드포인트들(S1 및 A1)은 상이한 MAC 어드레스들을 가질 수 있다.

[0093] 유사하게, 제2 STA(720)는 제2 STA(720)에 대응하는 제1 MAC-SAP(MAC service access point) 엔드포인트(S2)를 포함할 수 있고, 제2 softAP(721)에 대응하는 제2 MAC-SAP 엔드포인트(A2)를 포함할 수 있다. 제1 MAC-SAP 엔드포인트(S2)는 AP(702)로부터 무선 매체 상에서 수신되는 프레임들 및 패킷들을 디코딩하는 것을 담당할 수 있고, 제2 STA(720)로부터 AP(702)로 무선 매체를 통해 송신하기 위해 프레임들을 구성 및 포맷팅하는 것을 담당할 수 있다. 제2 MAC-SAP 엔드포인트(A2)는 클라이언트 디바이스(722)로부터 무선 매체 상에서 수신되는 프레임들 및 패킷들을 디코딩하는 것을 담당할 수 있고, 제2 softAP(721)로부터 클라이언트 디바이스(722)로 제2 P2P 링크(723)를 통해 송신하기 위해 프레임들을 구성 및 포맷팅하는 것을 담당할 수 있다. 일부 예시들에서, MAC-SAP 엔드포인트들(S2 및 A2)은 상이한 MAC 어드레스들을 가질 수 있다.

[0094] 제1 STA(710)는 제1 클라이언트 디바이스(712)와 같은 P2P 디바이스들에 대한 제1 커버리지 영역(715)을 제공할 수 있고, 제2 STA(720)는 제2 클라이언트 디바이스(722)와 같은 P2P 디바이스들에 대한 제2 커버리지 영역(725)을 제공할 수 있다. 일부 예시들에서, 제1 및 제2 커버리지 영역들(715 및 725)은 (도 7의 예에 도시된 바와 같이) 서로 중첩되지 않을 수 있다. 일부 다른 예시들에서, 제1 및 제2 커버리지 영역들(715 및 725)은 서로 중첩될 수 있다. 간략함을 위해 도시되지는 않았지만, AP(702)에 의해 제공되는 커버리지 영역은 제1 STA(710)의 제1 softAP(711)에 의해 제공되는 제1 커버리지 영역(715)의 일부 또는 전부를 포함할 수 있고, 제2 STA(720)의 제2 softAP(721)에 의해 제공되는 제2 커버리지 영역(725)의 일부 또는 전부를 포함할 수 있다. 예컨대, 일부 예시들에서, 클라이언트 디바이스들(712 및 722) 중 하나 또는 둘 모두는 AP(702)에 의해 송신되는 프레임들을 수신하고 성공적으로 디코딩할 수 있는 한편, 다른 예시들에서, 클라이언트 디바이스들(712 및 722) 중 하나 또는 둘 모두는, (이를테면, 클라이언트 디바이스들(712 및 722)이 AP(702)의 무선 커버리지 영역 내에 있지 않기 때문에), AP(702)에 의해 송신되는 프레임들을 수신하고 성공적으로 디코딩하지 못할 수 있다.

[0095] 클라이언트 디바이스들(712 및 722)은 개개의 softAP들(711 및 721)과 P2P 링크들을 확립할 수 있는 임의의 적절한 디바이스들일 수 있다. 도 7의 예에서, 클라이언트 디바이스들(712 및 722)은 데이터 트래픽에 대한 엄격한 엔드-투-엔드 레이턴시, 스루풋 및 타이밍 요건들을 갖는 저-레이턴시 애플리케이션들과 연관된다. 일부 예시들에서, 클라이언트 디바이스들(712 및 722)은 실시간 게이밍 애플리케이션들, 비디오 통신들, 또는 AR(augmented reality) 및 VR(virtual reality) 애플리케이션들(총괄하여 XR(extended reality) 애플리케이션들로 지칭됨)과 연관될 수 있다. 예컨대, 클라이언트 디바이스들(712 및 722)은 제1 및 제2 STA들(710 및 720)과 각각 코로케이트된 softAP들(711 및 721)과 연관된 VR 헤드셋들일 수 있다. 따라서, 제1 STA(710) 및 제2 STA(720) 각각은 저-레이턴시 STA로 지칭될 수 있다. 제3 STA(730)가 레이턴시 민감 트래픽과 연관되는 예시들에서, 제3 STA(730)는 또한 저-레이턴시 STA로 지칭될 수 있다.

[0096] 논의된 바와 같이, 저-레이턴시 애플리케이션들은 WLAN(700)에 대한 다양한 레이턴시, 스루풋 및 타이밍 요건들을 특정할 수 있고, 따라서, WLAN(700)이 그러한 저-레이턴시 애플리케이션들의 다양한 레이턴시, 스루풋 및 타이밍 요건들을 충족시킬 수 있도록 보장하는 것이 바람직하다. 일부 구현들에서, 저-레이턴시 STA들(710, 720 및 730) 각각은, 무선 매체 상에서 대응하는 r-TWT REQ 프레임을 AP(702)에 전송함으로써 r-TWT SP를 스케줄링하도록 AP(702)에 요청할 수 있다. r-TWT REQ 프레임들 각각은 AP(702)의 MAC 어드레스, 개개의 STA의 MAC 어드레스 및 하나 이상의 TWT 파라미터들을 포함할 수 있다. 일부 양상들에서, 하나 이상의 TWT 파라미터들은 요청된 r-TWT SP의 주기성, 요청된 r-TWT SP의 지속기간, 요청된 r-TWT SP의 공유 모드, 요청된 r-TWT SP의 웨이크 지속기간, 요청된 r-TWT SP의 흐름 타입, r-TWT SP의 파라미터 세트, 또는 개개의 STA와 연관된 클라이언트 디바이스 사이의 P2P 통신들을 위해 r-TWT SP를 사용하고자 하는 개개의 STA의 의도를 포함할 수 있다(그러나 이것들로 제한되지는 않음).

[0097] r-TWT SP REQ들을 수신한 후, AP(702)는 각각의 STA들(710, 720 및 730)에 의해 제안된 TWT 파라미터들을 수락할지, 거절할지 또는 수정할지를 결정할 수 있다. 구체적으로, AP(702)는 r-TWT SP 수락 프레임을 제1, 제2 및 제3 STA들(710, 720 및 730) 각각에 전송한다. 각각의 r-TWT SP 수락 프레임은 대응하는 STA의 MAC 어드레스 및 무선 매체에 스케줄링된 r-TWT SP들에 사용될 TWT 파라미터들의 세트를 포함할 수 있다. 일부 예시들에서, AP(702)는 개개의 STA에 의해 제안된 TWT 파라미터들을 수락할 수 있고, 따라서, 대응하는 r-TWT SP 수락 프레임에서 반송되는 TWT 파라미터들의 세트는 제안된 TWT 파라미터들과 동일할 수 있다. 다른 예시들에서, AP(702)는 새로운 또는 수정된 TWT 파라미터들을 개개의 STA에 제안할 수 있고, 따라서, 대응하는 r-TWT SP 수락 프레임에서 반송되는 TWT 파라미터들의 세트는 제안된 TWT 파라미터들과 상이할 수 있다. 일부 다른 예시들에서, AP(702)는 STA들(710, 720 또는 730) 중 하나 이상에 의해 요청된 r-TWT SP 또는 TWT 파라미터들을 거절할 수 있다.

[0098] 도 8은 BSS에 속하는 디바이스들 사이의 예시적인 무선 통신을 도시하는 타이밍도(800)를 도시한다. BSS는 도 7을 참조하여 설명된 AP(702), 제1 STA(710) 및 코로케이트된 제1 softAP(711), 제1 클라이언트 디바이스(712), 제2 STA(720) 및 코로케이트된 제2 softAP(721), 제2 클라이언트 디바이스(722), 및 제3 STA(730)를 포함하는 것으로 도시된다. 일부 구현들에서, 제1, 제2 및 제3 STA들(710, 720 및 730) 각각은 저-레이턴시 STA들로 지칭될 수 있다. 도 8의 예에서, 제1 및 제2 STA들(710 및 720)은 시간 t₁ 내지 시간 t₉의 시간 기간에 걸쳐 있는 스케줄링된 r-TWT SP의 멤버들일 수 있는 반면, 제3 STA(730)는 r-TWT SP의 멤버가 아니고 (그에 따라, "비-멤버 STA"로 지칭될 수 있다).

[0099] 도 7을 참조하여 논의된 바와 같이, 제1 STA(710)는 AP(702)와 연관되고, 제1 P2P 링크(713)를 통해 제1 클라이언트 디바이스(712)와 연관된 제1 softAP(711)를 구현 또는 동작시킨다. 유사하게, STA(720)는 AP(702)와 연관되고, 제2 P2P 링크(723)를 통해 제2 클라이언트 디바이스(722)와 연관된 제2 softAP(721)를 구현 또는 동작시킨다. 일부 구현들에서, 제1 STA(710)는 2개의 MAC-softAP 엔드포인트들(S1 및 A1)을 포함할 수 있고, 제2 STA(720)는 2개의 MAC-softAP 엔드포인트들(S2 및 A2)을 포함할 수 있다. 제3 STA(730)는 AP(702)와 연관되고, softAP를 구현 또는 동작시키지 않는다. 도 8의 예에는 단지 3개의 STA들만이 도시되지만, 실제 구현들에서, BSS는 임의의 수의 STA들(이를테면, 저-레이턴시 STA들)을 포함할 수 있고, 임의의 수의 비-레거시 STA들을 또한 포함할 수 있다.

[0100] 논의된 바와 같이, 제한된 TWT 동작에 관한 기존의 규칙들은 비-멤버 STA들이 제한된 TWT SP의 시작까지 자신들의 TXOP들을 종료할 것을 요구한다. 도 8의 제한된 TWT SP는 시간 t₁에 시작되고, 따라서 모든 비-멤버 STA들(이를테면, 제3 STA(730))은, 존재하는 경우, 시간 t₁까지 그들의 개개의 TXOP들을 트렁케이팅(truncate)한다. 일부 예시들에서, AP(702)는 제한된 TWT SP와 중첩되도록 콰이어트 인터벌을 스케줄링함으로써 BSS와 연관된 모든 레거시 STA들로부터의 트래픽을 억제할 수 있다. 예컨대, 콰이어트 인터벌의 지속기간은, 제한된 TWT SP의 시작 이전에 AP(702)에 의해 송신되는 관리 프레임들(이를테면, 비컨 프레임들 및 프로브 응답 프레임들)에 포함된 하나 이상의 콰이어트 엘리먼트(Quiet Element)들에 의해 표시될 수 있다.

[0101] 도시된 바와 같이, AP(702)는 r-TWT SP의 시작 전에 공유 무선 매체에 액세스하고자 시도한다. 더 구체적으로, AP(702)는, TXOP를 획득하고자 시도하기 전에 채널 감지 동작(이를테면, CCA(clear channel assessment))에 기반하여 매체가 적어도 SIFS 지속기간, 즉 시간 t₀ 내지 시간 t₁ 동안 유휴 상태(idle)임을 감지한다. 일부 예시들에서, AP(702)는, 채널 액세스를 얻고자 시도하기 전에 무선 매체가 PIFS 지속기간 동안 유휴 상태이고 (그에 따라, 시간 t₀ 내지 시간 t₁의 시간 기간이 PIFS 지속기간임을) 감지할 수 있다. 시간 t₁에, AP(702)는 무선 매체가 여전히 유휴 상태임을 감지하고, 예컨대, 공유 매체를 통한 송신을 개시함으로써, TXOP를 획득하도록 진행한다. 구체적으로, AP(702)는 무선 매체 상에서, 트리거링-기반(triggered-based) 업링크(UL) 송신을 위해 제1 STA(710) 및 제2 STA(720)를 식별하는 트리거 프레임(810)을 송신한다. 일부 예시들에서, 트리거 프레임(810)은 제1 및 제2 STA들(710 및 720)에 할당된 AID(association identifier)들을 반송하는 사용자별 정보 필드(Per User Info field)들을 포함한다.

[0102] 일부 구현들에서, 트리거 프레임(810)은 제한된 TWT SP에서 레이턴시-민감 트래픽을 보호하기 위해 사용될 수 있는 (MAC 헤더 내의) 지속기간 필드를 포함한다. 설명된 바와 같이, IEEE 802.11 표준의 기존 버전들을 따르는 STA들은, 적어도 트리거 프레임(이를테면, 트리거 프레임(810)) 내의 지속기간 필드에 의해 표시되는 지속기간 동안 매체 액세스를 연기해야 한다. 일부 구현들에서, 지속기간 필드에 의해 표시되는 지속기간은 트리거 프레임(810)을 송신하는 데 필요한 지속기간보다 클 수 있다. 예컨대, 도 8에 도시된 바와 같이, 제3 STA(730)는 시간 t₂ 내지 시간 t₃의 시간 기간에 걸쳐 있는, 트리거 프레임(810)의 지속기간 필드에 의해 표시되는 지속기간으로 자신의 NAV(803)를 설정할 수 있다. 이러한 방식으로, AP(702)는 트리거링되지 않은 STA들로부터, WLAN(700)을 사용하여 통신되는 저-레이턴시 트래픽을 보호할 수 있다.

[0103] 일부 다른 구현들에서, AP(702)는, (존재하는 경우) STA들 중 어느 것이 전송할 UL 데이터를 가지고 있는 지를 결정하기 위해, 제한된 TWT SP의 시작 전에 저-레이턴시 STA들을 폴링(poll)할 수 있다. 예컨대, AP(702)는 제한된 TWT SP와 연관된 저-레이턴시 STA들에 BSRP(buffer status report poll) 트리거 프레임을 송신할 수 있다. 각각의 저-레이턴시 STA는, STA에 의해 버퍼링된 UL 데이터의 양을 표시하는 BSR(buffer status report)을 AP(702)에 송신함으로써, BSRP 트리거 프레임에 응답한다. AP(702)는, 트리거 프레임들(이를테면, 트리거 프레임(810))에 의해 요청된 TB PPDU들에 대한 자원 배정을 결정하기 위해, 각각의 BSR에서 반송된 정보를 사용할 수 있다.

[0104] 제1 및 제2 STA들(710 및 720)은 트리거 프레임(810)을 수신하고, 그들의 개개의 AID 값들이 트리거 프레임(810)에서 반송되는 AID 값들과 매칭한다고 결정한다. 시간 t₂ 내지 시간 t₃에, 제1 STA(710)는 제1 TB(trigger-based) PPDU(PLCP(physical layer convergence protocol) protocol data unit)(811)를 무선 매체를 통해 AP(702)에 송신하고, 제2 STA(720)는 제2 TB PPDU(812)를 무선 매체를 통해 AP(702)에 송신한다. 일부 예시들에서, 제1 및 제2 TB PPDU들(811 및 812)은 MU UL PPDU로서 송신될 수 있다. AP(702)는 TB PPDU들(811 및 812)을 수신하고, 시간 t₄에 무선 매체를 통해 제1 및 제2 STA들(710 및 720)에 블록 ACK 프레임(813)을 송신함으로써 그들의 수신을 확인응답한다.

[0105] 시간 t₅에, AP(702)는 TXOP를 획득하고, 무선 매체를 통해 MU(multi-user) RTS(Request-to-Send) TXS(TXOP Sharing) 트리거 프레임(820)을 송신한다. 일부 구현들에서, MU-RTS TXS 트리거 프레임(820)은 획득된 TXOP의 지속기간을 표시하는 지속기간 필드를 포함하여서, 예컨대, 트리거링되지 않은 STA들은 자신들의 NAV들을 그러한 지속기간 필드에 표시된 지속기간으로 설정한다. 도 8의 예에서, MU-RTS TXS 트리거 프레임(820)은 r-TWT SP 동안, AP(702)에 의해 획득된 TXOP의 일부(T₁)를 제1 STA(710)에 배정할 수 있다. 구체적으로, MU-RTS TXS 트리거 프레임(820)은 STA의 MAC 어드레스를 포함할 수 있으며, 그리고 (예컨대, 제1 STA(710)로부터 하나 이상의 TB PPDU들을 요청하기 위해) 제1 STA(710)의 AID 값을 또한 포함할 수 있다.

[0106] 논의된 바와 같이, 제1 STA(710)는 레이턴시 민감 트래픽과 연관된 제1 클라이언트 디바이스(712)에 링크된 softAP와 코로케이트된다. 도 8의 예에서, 제1 STA(710)는 코로케이트된 softAP와 제1 클라이언트 디바이스(712) 사이의 P2P 통신들을 용이하게 하기 위해, TXOP의 배정된 부분을 사용하고자 의도한다. 그러나, AP(702)는 제1 STA(710)가 softAP와 코로케이트된다는 것을 인식하지 못할 수 있으며, 따라서, 제1 STA(710)가, 자신의 코로케이트된 softAP 및 제1 클라이언트 디바이스(712)가 TXOP의 배정된 부분 동안 무선 매체를 통해 P2P 통신들을 교환하는 것을 허용하고자 의도한다는 것을 인식하지 못할 수 있다. 구체적으로, MU-RTS TXS 트리거 프레임(820)이 제1 STA(710)의 MAC 어드레스를 포함할 수 있지만, MU-RTS TXS 트리거 프레임(820)은 제1 softAP(711)의 MAC 어드레스 또는 연관된 클라이언트 디바이스(712)의 MAC 어드레스를 포함하지 않을 수 있다. softAP 또는 그의 연관된 클라이언트 디바이스(712) 중 어느 것도 MU-RTS TXS 트리거 프레임(820)에 의해 식별되지 않기 때문에, softAP 및 클라이언트 디바이스(712) 둘 모두는 그들의 개개의 NAV들(831 및 832)을 MU-RTS TXS 트리거 프레임(820)의 지속기간 필드에 표시된 지속기간으로 설정할 수 있다. 결과적으로, 제1 softAP(711) 또는 클라이언트 디바이스(712) 중 어느 것도, TXOP의 배정된 부분 동안 제1 softAP(711)에 P2P 통신들을 송신하거나 또는 그로부터 P2P 통신들을 수신하지 못할 수 있다.

[0107] 제1 STA(710)는 MU-RTS TXS 트리거 프레임(820)을 수신하고, 자신의 AID가 MU-RTS TXS 트리거 프레임(820)에서 반송된다고 결정하고, TXOP의 일부가 제1 STA(710)에 배정된다고 결정한다. 제1 STA(710)는 시간 t₇에 CTS 프레임(821)을 AP(702)에 송신함으로써 MU-RTS TXS 트리거 프레임(820)의 수신을 확인응답한다. CTS 프레임(821)은, 예컨대, AP(702)의 MAC 어드레스를 포함할 수 있고, 그에 따라, AP(702)는 CTS 프레임(821)이 MU-RTS TXS 트리거 프레임(820)의 수신을 확인응답하고 있다고 결정할 수 있다. 그러나, softAP 또는 그의 연관된 클라이언트 디바이스(712) 중 어느 것도 CTS 프레임(821)에 의해 식별되지 않기 때문에, 제1 softAP(711) 및 클라이언트 디바이스(712)는, (이들이 MU-RTS TXS 트리거 프레임(820)에 표시된 지속기간에 기반하여 그들의 개개의 NAV들을 이미 설정하지 않은 한) 그들의 개개의 NAV들(831 및 832)을 CTS 프레임(821)의 지속기간 필드에 표시된 지속기간으로 설정할 수 있다. 따라서, 제1 softAP(711) 또는 클라이언트 디바이스(712) 중 어느 것도, TXOP의 배정된 부분 동안 서로 P2P 통신들을 송신 또는 수신하지 못할 수 있다. 유사하게, MU-RTS TXS 트리거 프레임(820) 또는 CTS 프레임(821) 중 어느 것도 TXOP의 배정된 부분을 사용하기 위해 제2 STA(720), 제2 코로케이트된 softAP(721) 또는 클라이언트 디바이스(722)를 어드레싱하거나 달리 식별하지 않기 때문에, 제2 STA(720), 제2 softAP(721) 및 클라이언트 디바이스(722) 각각은 그들의 개개의 NAV들(840, 841 및 842)을 CTS 프레임(821)에 표시된 지속기간으로 설정한다. 제3 STA(730)는 또한 자신이 MU-RTS TXS 트리거 프레임(820)에 의해 식별되지 않는다고 결정하고, 자신의 NAV(843)를 MU-RTS TXS 트리거 프레임(820) 또는 CTS 프레임(821)의 지속기간 필드에 표시된 지속기간으로 설정한다.

[0108] 도 9는 일부 구현들에 따른, BSS에 속하는 디바이스들 사이의 예시적인 무선 통신(900)을 도시하는 타이밍도를 도시한다. BSS는 도 7을 참조하여 설명된 AP(702), 제1 STA(710), 제2 STA(720) 및 제3 STA(730)를 포함하는 것으로 도시된다. 도 9의 예에서, 제1 및 제2 STA들(710 및 720)은 시간 t₃ 내지 시간 t₁₅의 시간 기간에 걸쳐 있는 스케줄링된 r-TWT SP의 멤버들인 반면, 제3 STA(730)는 r-TWT SP의 멤버가 아니고 (그에 따라, "비-멤버 STA"로 지칭될 수 있다). 논의된 바와 같이, 제1 STA(710)는 AP(702)와 연관되며, 그리고 제1 클라이언트 디바이스(712)와 P2P 링크(713)를 갖거나 또는 이를 확립할 수 있는 제1 코로케이트된 softAP(711)를 구현 또는 동작시킨다. 유사하게, 제2 STA(720)는 AP(702)와 연관되며, 그리고 제2 클라이언트 디바이스(722)와 P2P 링크(723)를 갖거나 또는 이를 확립할 수 있는 제2 코로케이트된 softAP(721)를 구현 또는 동작시킨다. 도 9의 예에는 단지 3개의 저-레이턴시 STA들만이 도시되지만, 실제 구현들에서, BSS는 임의의 수의 저-레이턴시 STA들을 포함할 수 있고, 임의의 수의 비-레거시 STA들을 또한 포함할 수 있다.

[0109] 도 9의 예에서, 제1 STA(710)는 자신의 코로케이트된 제1 softAP(711)와 클라이언트 디바이스(712) 사이의 P2P 통신들을 위해 r-TWT SP를 요청한다. 구체적으로, 시간 t₀에, 제1 STA(710)는 무선 매체를 통해 요청(REQ) 프레임(901)을 AP(702)에 송신한다. 요청 프레임(901)은, AP(702)가 제1 STA(710)에 대해, r-TWT SP를 스케줄링하라는 요청을 포함할 수 있고, r-TWT SP 동안, 제1 softAP(711)는 무선 매체를 사용하여 클라이언트 디바이스(712)에 저-레이턴시 데이터를 송신하거나 또는 클라이언트 디바이스(712)로부터 저-레이턴시 데이터를 수신할 수 있다. 일부 예시들에서, 요청 프레임(901)은 r-TWT SP 동안 스케줄링된 통신 교환의 참여자들로서 softAP 및 그의 클라이언트 디바이스(712)를 식별한다. 예컨대, 일부 양상들에서, 요청 프레임(901)은 softAP 및 클라이언트 디바이스(712)의 MAC 어드레스들을 포함할 수 있다. AP(702)는 r-TWT SP 동안 무선 매체를 통해 교환되는 P2P 통신들을 위한 향상된 보호 메커니즘을 제공하기 위해 softAP 및 클라이언트 디바이스(712)의 MAC 어드레스들 또는 다른 적합한 식별자들을 사용할 수 있다. 일부 구현들에서, 요청 프레임(901)은 클라이언트 디바이스(712)의 MAC 어드레스를 반송하는 TWT 엘리먼트를 포함할 수 있다. TWT 엘리먼트는 또한 r-TWT SP와 연관된 하나 이상의 TWT 파라미터들을 반송할 수 있다. 예시적인 TWT 파라미터들은 r-TWT SP의 주기성, r-TWT SP의 지속기간, r-TWT SP의 공유 모드, r-TWT SP의 웨이크 지속기간, r-TWT SP의 흐름 타입, r-TWT SP의 파라미터 세트, 또는 r-TWT SP 동안 무선 매체를 사용하고자 하는 softAP의 의도를 포함할 수 있다(그러나 이것들로 제한되지는 않음).

[0110] 시간 t₀ 내지 시간 t₁에, AP(702)는 요청 프레임(901)을 디코딩하고, 제1 STA(710)에 의해 요청된 r-TWT SP와 연관된 TWT 파라미터들을 획득한다. AP(702)는 또한, 어느 디바이스들이 r-TWT SP의 일부 동안 P2P 통신들을 위해 무선 매체를 사용하고자 의도하는지를 결정할 수 있다. 일부 구현들에서, AP(702)는 요청 프레임(901)으로부터 디코딩된 정보를 사용하여, r-TWT SP에 속하는 STA들과 코로케이트된 softAP들과 연관된 P2P 통신들에 대한 NAV 예외를 구성할 수 있다. 구체적으로, 일부 예시들에서, NAV 예외는, MU-RTS TXS 트리거 프레임들에 의해 표시되는 NAV 지속기간들 및 MU-RTS TXS 트리거 프레임들에 후속하는 CTS 프레임들에 의해 표시되는 NAV 지속기간들을 무시해야 하는, AP(702)와 연관된 하나 이상의 디바이스들 또는 코로케이트된 softAP를 식별할 수 있다. 도 9의 예에서, NAV 예외는, 제1 softAP(711) 및 클라이언트 디바이스(712)가, AP(702)로부터 후속하여 송신되는 MU-RTS TXS 트리거 프레임들 및 이러한 후속적으로 송신되는 MU-RTS TXS 트리거 프레임들에 응답하여 송신되는 임의의 CTS 프레임들에 의해 표시되는 NAV 지속기간들을 무시해야 함을 표시할 수 있다. 결과적으로, 제1 softAP(711) 및 클라이언트 디바이스(712)는 MU-RTS TXS 트리거 프레임(또는 후속하는 CTS 프레임)의 지속기간 필드에 표시된 지속기간에 기반하여 그들의 개개의 NAV들을 설정하지 않지만, r-TWT SP의 멤버들이 아니거나 MU-RTS TXS 트리거 프레임에 의해 식별되지 않는 다른 무선 통신 디바이스들은 MU-RTS TXS 트리거 프레임(또는 후속하는 CTS 프레임)에 의해 표시된 지속기간에 기반하여 그들의 개개의 NAV들을 설정한다.

[0111] AP(702)는 시간 t₁ 내지 시간 t₂에 무선 매체 상에서 응답(Resp) 프레임(902)을 제1 STA(710)에 송신한다. 응답 프레임(902)은 스케줄링된 r-TWT SP에 대한 TWT 파라미터들의 세트를 반송하는 TWT 엘리먼트를 포함할 수 있다. 일부 구현들에서, 응답 프레임(902)은 또한 softAP1 및 클라이언트 디바이스(712)의 MAC 어드레스들을 포함할 수 있다. 일부 다른 구현들에서, 응답 프레임(902)은 또한, 얼마나 많은 무선 통신 디바이스들이 스케줄링된 r-TWT SP의 멤버들인지를 표시할 수 있다. 일부 예시들에서, 이는 제1 STA(710)가, 자신이 r-TWT SP의 유일한 멤버인지 여부를 결정하고, 그에 따라, r-TWT SP 동안 MU-RTS TXS 트리거 프레임들보다, 공격적인 채널 액세스 기법들을 사용할 수 있는지 여부를 결정할 수 있게 한다.

[0112] AP(702)는, TXOP를 획득하고자 시도하기 전에 채널 감지 동작(이를테면, CCA(clear channel assessment))에 기반하여 무선 매체가 PIFS 지속기간, 즉 시간 t₂ 내지 시간 t₃ 동안 유휴 상태임을 감지한다. 시간 t₃에, AP(702)는 무선 매체가 여전히 유휴 상태임을 감지하고, 예컨대, 공유 매체 상에서의 송신을 개시함으로써, TXOP를 획득하도록 진행한다. 구체적으로, AP(702)는 시간 t₃에 무선 매체 상에서 트리거 프레임(910)을 송신한다. 도 9의 예에서, 트리거 프레임(910)은 예컨대, 제1 STA(710) 및 제3 STA(730)의 AID들을 트리거 프레임(910)의 개개의 사용자 정보 필드들에 포함시킴으로써, 제1 STA(710) 및 제3 STA(730)를 식별한다.

[0113] 제1 STA(710) 및 제3 STA(730)는 트리거 프레임(910)을 수신하고, 그들의 개개의 AID들이 트리거 프레임(910)에서 반송된 AID들과 매칭한다고 결정한다. 시간 t₄ 내지 시간 t₅에, 제1 STA(710)는 무선 매체를 통해 제1 TB PPDU(911)를 AP(702)에 송신하고, 제2 STA(720)는 무선 매체를 통해 제2 TB PPDU(912)를 AP(702)에 송신한다. 일부 예시들에서, 제1 및 제2 TB PPDU들(911 및 912)은 MU UL PPDU로서 송신될 수 있다. AP(702)는 TB PPDU들(911 및 912)을 수신하고, 시간 t₆에 무선 매체를 통해 제1 및 제2 STA들(710 및 720)에 블록 ACK 프레임(913)을 송신함으로써 그들의 수신을 확인응답한다.

[0114] 제2 STA(720)는 트리거 프레임(910)을 수신하고, 자신이 트리거 프레임(910)에 의해 UL 송신들에 대해 식별되지 않는다고 결정한다. 따라서, 제2 STA(720)는 자신의 NAV(903)를 트리거 프레임(910)의 지속기간 필드로 설정한다. 일부 예시들에서, 트리거 프레임(910)에 표시되는 지속기간은 무선 매체를 통한 TB PPDU의 송신과 연관된 시간 기간에 대응할 수 있다. 예컨대, 도 9에 도시된 바와 같이, 제2 STA(720)는 시간 t₄ 내지 시간 t₅의 시간 기간에 걸쳐 있는, 트리거 프레임(910)의 지속기간 필드에 의해 표시되는 지속기간으로 자신의 NAV(903)를 설정할 수 있다. 이러한 방식으로, AP(702)는 적어도 인근의 STA들로부터, WLAN(700)을 사용하여 통신되는 저-레이턴시 트래픽을 보호할 수 있다.

[0115] 블록 ACK 프레임(913)의 송신의 종료 이후 SIFS 지속기간일 수 있는 시간 t₇에, AP(702)는 TXOP를 획득하고, 시간 t₇ 내지 시간 t₈에 무선 매체를 통해 MU-RTS TXS 트리거 프레임(920)을 송신한다. MU-RTS TXS 트리거 프레임(920)은, r-TWT SP 동안 클라이언트 디바이스(712)와 제1 softAP(711) 사이의 P2P 통신들을 위해, AP(702)에 의해 획득된 TXOP의 일부를 배정한다. MU-RTS TXS 트리거 프레임(920)은, TXOP가 P2P 통신들을 위해 배정되는 시간 지속기간(T₁)을 표시하는 지속기간 필드를 포함한다. 이러한 방식으로, MU-RTS TXS 트리거 프레임(920)에 의해 식별되지 않은 수신 디바이스들은, 예컨대, 표시된 시간 지속기간(T₁)으로 그들의 개개의 NAV들을 설정하며, 그에 따라, 클라이언트 디바이스(712)와 제1 softAP(711) 사이의 저-레이턴시 P2P 통신들이 중단되거나 저하되지 않는다.

[0116] 다양한 구현들에서, MU-RTS TXS 트리거 프레임(920)은, 제1 softAP(711) 및 클라이언트 디바이스(712)가 MU-RTS TXS 트리거 프레임(920)에 의해 표시되는 NAV 지속기간들 또는 MU-RTS TXS 트리거 프레임(920)에 후속하는 CTS 프레임들에 의해 표시되는 NAV 지속기간들을 무시해야 함을 표시하는 NAV 예외를 시그널링한다. 일부 양상들에서, MU-RTS TXS 트리거 프레임(920)은, 예컨대, 제1 softAP(711) 및 클라이언트 디바이스(712)의 MAC 어드레스들을 포함하거나 표시할 수 있으며, 그에 따라, 제1 softAP(711) 및 클라이언트 디바이스(712)는 MU-RTS TXS 트리거 프레임(920)을 수신 및 디코딩한다.

[0117] 제1 STA(710)는 시간 t₈ 내지 시간 t₉에 MU-RTS TXS 트리거 프레임(920)을 수신 및 디코딩하고, 클라이언트 디바이스(712)와 연관된 P2P 통신들을 위해 TXOP의 일부가 배정된다고 결정한다. 시간 t₉에, 제1 STA(710)는 CTS 프레임(921)을 AP(702)에 송신함으로써 MU-RTS TXS 트리거 프레임(920)의 수신을 확인응답한다. CTS 프레임(921)은, TXOP가 P2P 통신들을 위해 배정되는 시간 지속기간(T₁)을 표시하는 지속기간 필드를 포함한다. 이러한 방식으로, CTS 프레임을 수신하지만 MU-RTS TXS 트리거 프레임(920)을 수신하지 않는 수신 디바이스들은 그들의 개개의 NAV들을 표시된 시간 지속기간(T₁)으로 설정할 수 있다. 일부 예시들에서, CTS 프레임(921)은, MU-RTS TXS 트리거 프레임(920)을 참조하여 설명된 NAV 예외를 시그널링하고, 또한, 예컨대, 제1 softAP(711) 및 클라이언트 디바이스(712)가 CTS 프레임(921)을 수신 및 디코딩하도록, 클라이언트 디바이스(712) 및 제1 softAP(711)의 MAC 어드레스들을 표시한다.

[0118] 클라이언트 디바이스(712) 및 제1 softAP(711)는 시간 t₈ 내지 시간 t₉에 MU-RTS TXS 트리거 프레임(920)을 수신 및 디코딩할 수 있다. 구체적으로, 클라이언트 디바이스(712) 및 제1 softAP(711)는 MU-RTS TXS 트리거 프레임(920)에 의해 시그널링된 NAV 예외를 디코딩할 수 있으며, 그리고 NAV 예외에 대한 응답으로, MU-RTS TXS 트리거 프레임(920)의 지속기간 필드에 표시된 지속기간으로 그들의 개개의 NAV들을 설정하지 않는다. 일부 예시들에서, 클라이언트 디바이스(712) 및 제1 softAP(711)는 또한 제1 STA(710)에 의해 송신된 CTS 프레임(921)을 수신 및 디코딩할 수 있다. 예컨대, 클라이언트 디바이스(712) 및 제1 softAP(711)는 CTS 프레임(921)에 의해 시그널링된 NAV 예외를 디코딩할 수 있으며, 그리고 NAV 예외에 대한 응답으로, CTS 프레임(921)의 지속기간 필드에 표시된 지속기간으로 그들의 개개의 NAV들을 설정하지 않는다. 따라서, 클라이언트 디바이스(712)가 MU-RTS TXS 트리거 프레임(920)을 수신하지 않거나 디코딩할 수 없는 경우(이를테면, 클라이언트 디바이스(712)가 AP(702)의 무선 커버리지 영역 외부에 있기 때문임), 클라이언트 디바이스(712)는 제1 STA(710)에 의해 송신된 CTS 프레임(921)으로부터 NAV 예외를 획득할 수 있다. 이러한 방식으로, 본원에 개시된 청구대상의 구현들은, 클라이언트 디바이스(712)뿐만 아니라 제1 softAP(711)가 NAV 예외를 획득하고, 예컨대, 그들의 개개의 NAV들을 MU-RTS TXS 트리거 프레임(920)에 의해 표시되는 지속기간으로 설정하지 않음으로써, TXOP의 배정된 부분 동안 서로 P2P 통신들을 교환하도록 이용가능하게 유지될 수 있음을 보장할 수 있다.

[0119] 시간 t₁₀에, 제1 softAP(711)는 무선 매체가 유휴 상태임을 감지하고, 무선 매체 상에서 클라이언트 디바이스(712)에 트리거 프레임(930)을 송신한다. 도 9의 예에서, 트리거 프레임(930)은 예컨대, 트리거 프레임(930)에 포함되는 사용자 정보 필드에 MAC 어드레스(또는 다른 적절한 식별자)를 포함시킴으로써 클라이언트 디바이스(712)를 식별한다.

[0120] 클라이언트 디바이스(712)는 트리거 프레임(930)을 수신하고, 트리거 프레임(930)이 클라이언트 디바이스(712)를 식별한다고 결정한다. 일부 예시들에서, 트리거 프레임(930)은 클라이언트 디바이스(712)로부터 UL P2P 송신들을 요청할 수 있다. 트리거 프레임(930)에 대한 응답으로, 클라이언트 디바이스(712)는 시간 t₁₁ 내지 시간 t₁₂에 무선 매체 상에서 TB PPDU(931)를 제1 softAP(711)에 송신한다. 제1 softAP(711)는 TB PPDU(931)를 수신하고, 시간 t₁₃ 내지 시간 t₁₄에 블록 ACK 프레임(932)을 클라이언트 디바이스(712)에 송신함으로써 TB PPDU(931)의 수신을 확인응답한다. 제1 STA(710)로의 TXOP의 배정은 시간 t₁₄에 종료된다. 제2 STA(720), 그것의 코로케이트된 softAP(721), 제2 클라이언트 디바이스(722) 및 제3 STA(730)의 NAV들 또한 시간 t₁₄에 종료된다. r-TWT SP는 시간 t₁₅에 종료된다.

[0121] 일부 예시들에서, P2P 링크(713)는 Wi-Fi TDLS(Tunneled Direct Link Setup)를 사용하여 확립될 수 있다. 다른 예시들에서, P2P 링크(713)는 W-Fi 다이렉트 연결일 수 있다. 일부 다른 예시들에서, 제1 STA(710) 또는 제1 softAP(711)는 GO(group owner)일 수 있고, 클라이언트 디바이스(712)로의 또는 클라이언트 디바이스(712)로부터의 P2P 송신들을 조정할 수 있다. 일부 예시들에서, NAV 예외들은 P2P 응답 프레임(902)에서 반송되는 TWT 엘리먼트에 포함되거나 또는 이에 의해 표시될 수 있다. 일부 다른 예시들에서, NAV 예외들은 P2P 응답 프레임(902) 내의 또는 그와 연관된 다른 적합한 시그널링에 포함되거나 또는 이에 의해 표시될 수 있다.

[0122] 도 10은 일부 구현들에 따른, BSS에 속하는 디바이스들 사이의 예시적인 무선 통신(1000)을 도시하는 타이밍도를 도시한다. BSS는 도 7을 참조하여 설명된 AP(702), 제1 STA(710), 제2 STA(720) 및 제3 STA(730)를 포함하는 것으로 도시된다. 도 10의 예에서, 제1 및 제2 STA들(710 및 720)은 시간 t₃ 내지 시간 t₁₅의 시간 기간에 걸쳐 있는 스케줄링된 r-TWT SP의 멤버들인 반면, 제3 STA(730)는 r-TWT SP의 멤버가 아니고 (그에 따라, "비-멤버 STA"로 지칭될 수 있다). 논의된 바와 같이, 제1 STA(710)는 AP(702)와 연관되며, 그리고 제1 클라이언트 디바이스(712)와 P2P 링크(713)를 갖거나 또는 이를 확립할 수 있는 제1 코로케이트된 softAP(711)를 구현 또는 동작시킨다. 유사하게, 제2 STA(720)는 AP(702)와 연관되며, 그리고 제2 클라이언트 디바이스(722)와 P2P 링크(723)를 갖거나 또는 이를 확립할 수 있는 제2 코로케이트된 softAP(721)를 구현 또는 동작시킨다. 도 10의 예에는 단지 3개의 저-레이턴시 STA들만이 도시되지만, 실제 구현들에서, BSS는 임의의 수의 저-레이턴시 STA들을 포함할 수 있고, 임의의 수의 비-레거시 STA들을 또한 포함할 수 있다.

[0123] 도 10의 타이밍도는 많은 양상들에서 도 9의 타이밍도와 유사하고, 일부 양상들에서 도 9의 타이밍도와 상이하다. 예컨대, 도 9의 예시적인 통신(900)에서 NAV 예외는 MU-RTS TXS 트리거 프레임(920)을 사용하여 클라이언트 디바이스(712) 및 제1 softAP(711)에 시그널링되지만, 도 10의 예시적인 통신(1000)에서는, 응답 프레임(1002)을 사용하여 제1 softAP(711) 및 그의 연관된 클라이언트 디바이스(712)에 NAV 예외를 시그널링할 수 있다. 구체적으로, 시간 t₀에, 제1 STA(710)는 무선 매체를 통해 요청(REQ) 프레임(1001)을 AP(702)에 송신한다. 도 9의 요청 프레임(901)의 예일 수 있는 요청 프레임(1001)은 AP(702)가 r-TWT SP를 스케줄링하라는 요청을 포함할 수 있고, r-TWT SP 동안, 인근의 다른 무선 통신 디바이스들로부터 (만일 있다고 있더라도) 최소의 간섭을 가지면서, 클라이언트 디바이스(712)와 제1 softAP(711) 사이에서 무선 매체를 통해 P2P 통신들이 교환될 수 있다.

[0124] 일부 예시들에서, 요청 프레임(1001)은 제1 softAP(711) 및 그의 연관된 클라이언트 디바이스(712)를, r-TWT SP의 적어도 일부 동안 스케줄링된 P2P 통신들의 참여자들로서 식별한다. 예컨대, 요청 프레임(1001)은 제1 softAP(711) 및 클라이언트 디바이스(712)의 MAC 어드레스들을 포함할 수 있다. AP(702)는 제1 softAP(711) 및 클라이언트 디바이스(712)의 MAC 어드레스들 또는 다른 적합한 식별자들을 사용하여, 제1 softAP(711) 및 클라이언트 디바이스(712)에 대한 NAV 예외를 구성할 수 있다. 일부 예시들에서, AP(702)는, AP(702)와 연관되고 r-TWT SP의 멤버들인 STA들과 코로케이트된 softAP들과 연관된 P2P 통신들에 대한 NAV 예외를 구성할 수 있다.

[0125] AP(702)는 시간 t₀ 내지 시간 t₁에 요청 프레임(1001)을 수신하고, 제1 softAP(711) 및 클라이언트 디바이스(712)(또는 r-TWT SP에 참여하고자 의도하는 다른 디바이스들)의 아이덴티티들을 획득한다. 일부 예시들에서, 요청 프레임(1001)은, 제1 softAP(711)와 그의 클라이언트 디바이스(712) 사이의 P2P 통신들을 위해, AP(702)에 의해 획득된 TXOP의 배정된 부분들 동안 무선 매체를 사용하고자 하는 제1 STA(710)의 의도를 표시할 수 있다. 요청 프레임(1001)은 또한 r-TWT SP에 대해 제1 STA(710)에 의해 요청된 하나 이상의 TWT 파라미터들을 표시할 수 있다.

[0126] AP(702)는, 하나 이상의 연관된 STA들과 제휴되지만 BSS의 일부가 아닌 또는 AP(702)와 연관된 저-레이턴시 디바이스들이 r-TWT SP의 배정된 부분 동안 P2P 통신들을 송신 또는 수신하도록 허용할 수 있는 NAV 예외를 구성한다. 구체적으로, 일부 예시들에서, NAV 예외는, AP(702)에 의해 송신된 특정 트리거 프레임들 및 연관된 STA들에 의해 송신된 특정 응답 프레임들에 의해 표시되는 NAV 지속기간들을 무시해야 하는, AP(702)의 무선 범위 내의 또는 AP(702)와 연관된 하나 이상의 STA들의 무선 범위 내의 하나 이상의 디바이스들을 식별할 수 있다.

[0127] 도 10의 예에서, AP(702)에 의해 구성된 NAV 예외는, 제1 softAP(711) 및 그의 클라이언트 디바이스(712)가 r-TWT SP 동안 후속적으로 송신되는 MU-RTS TXS 트리거 프레임들에 의해 표시되는 NAV 지속기간들을 무시해야 함을 표시할 수 있다. NAV 예외는 또한, 제1 softAP(711) 및 그의 클라이언트 디바이스(712)가 MU-RTS TXS 트리거 프레임들에 후속하는 CTS 프레임들에 의해 표시되는 NAV 지속기간들을 무시해야 함을 표시할 수 있다. 결과적으로, r-TWT SP의 멤버들이 아니거나 또는 MU-RTS TXS 트리거 프레임에 의해 식별되지 않은 다른 무선 통신 디바이스들은 MU-RTS TXS 트리거 프레임(또는 후속하는 CTS 프레임)에 의해 표시되는 지속기간에 기반하여 그들의 개개의 NAV들을 설정하는 반면, 제1 softAP(711) 및 그의 연관된 클라이언트 디바이스(712)는 MU-RTS TXS 트리거 프레임 또는 MU-RTS TXS 트리거 프레임에 후속하는 CTS 프레임에 의해 표시되는 지속기간들에 기반하여 그들의 개개의 NAV들을 설정하지 않는다.

[0128] 구체적으로, AP(702)가 시간 t₈ 내지 시간 t₉에 무선 매체 상에서 MU-RTS TXS 트리거 프레임(920)을 송신할 때, 제1 softAP(711) 및 클라이언트 디바이스(712)는 응답 프레임(1002)에서 AP(702)에 의해 표시된 NAV 예외에 기반하여, MU-RTS TXS 트리거 프레임(920)에 의해 표시되는 NAV 지속기간들을 무시한다. 제1 softAP(711) 및 클라이언트 디바이스(712)는 또한, NAV 예외에 기반하여, 시간 t₉ 내지 시간 t₁₀에 제1 STA(710)에 의해 송신되는 CTS 프레임(921)에 의해 표시되는 NAV 지속기간들을 무시할 수 있다. 따라서, 제1 softAP(711) 및 그의 연관된 클라이언트 디바이스(712)는 MU-RTS TXS 트리거 프레임(920) 또는 후속하는 CTS 프레임(921)에 의해 표시되는 지속기간에 기반하여 그들의 개개의 NAV들을 설정하지 않으며, 그에 의해, 제1 softAP(711) 및 그의 연관된 클라이언트 디바이스(712)가, 제1 STA(710)에 배정된 r-TWT SP의 부분들 동안 P2P 링크(713)를 통해 저-레이턴시 P2P 통신들을 송신 또는 수신하도록 허용한다.

[0129] 예컨대, 제1 softAP(711)가 시간 t₁₀에 무선 매체를 통해 그의 연관된 클라이언트 디바이스(712)에 트리거 프레임(1030)을 송신할 때, 클라이언트 디바이스(712)는 자신의 NAV 세트를 갖지 않으며, 따라서 트리거 프레임(1030)을 수신 및 디코딩할 수 있다. 트리거 프레임(1030)에 대한 응답으로, 클라이언트 디바이스(712)는 시간 t₁₁ 내지 시간 t₁₂에 TB PPDU(1031)를 제1 softAP(711)에 송신할 수 있다. 제1 softAP(711)는 TB PPDU(1031)를 수신하고, 시간 t₁₃에 클라이언트 디바이스(712)에 블록 ACK(1032)를 전송한다. 제2 STA(720), 제2 softAP(721), 제2 클라이언트 디바이스(722) 및 제3 STA(730)는, 시간 t₉ 내지 시간 t₁₄에, MU-RTS TXS 트리거 프레임(1020)에 의해 표시되는 지속기간으로 그들의 개개의 NAV들(940-943)을 설정하고, 따라서, 시간 t₉ 내지 시간 t₁₄에 r-TWT SP 동안 무선 매체에 액세스하고자 시도하지 않으며, 그에 의해, r-TWT SP의 배정된 부분 동안 무선 매체 상에서의 경합 및 간섭을 감소시킨다.

[0130] 일부 다른 구현들에서, softAP들(711 및 721) 및 그들의 연관된 클라이언트 디바이스들(712 및 722)은, 무선 통신 프로토콜(이를테면, IEEE 802.11 무선 통신 표준군)에 의해 특정되거나 또는 그렇지 않으면 정의되는 규칙에 기반하여 특정 프레임들(이를테면, MU-RTS TXS 트리거 프레임(920) 및 CTS 프레임(921))에 의해 표시되는 NAV 지속기간들을 무시할 수 있다. 이러한 다른 구현들에서, 제1 softAP(711) 및 그의 연관된 클라이언트 디바이스(712)는 제1 STA(710)와 AP(702) 사이의 연관 또는 인증 동작들 동안 NAV 예외를 획득할 수 있다. 유사하게, 제2 softAP(721) 및 그의 연관된 클라이언트 디바이스(722)는 제2 STA(720)와 AP(702) 사이의 연관 또는 인증 동작들 동안 NAV 예외를 획득할 수 있다.

[0131] 도 11은 다른 구현들에 따른, BSS에 속하는 디바이스들 사이의 예시적인 무선 통신(1100)을 도시하는 타이밍도를 도시한다. BSS는 도 7을 참조하여 설명된 AP(702), 제1 STA(710), 제2 STA(720) 및 제3 STA(730)를 포함하는 것으로 도시된다. 논의된 바와 같이, 제1 STA(710)는 AP(702)와 연관되며, 그리고 제1 클라이언트 디바이스(712)와 연관된 제1 코로케이트된 softAP(711)를 구현 또는 동작시킨다. 유사하게, 제2 STA(720)는 AP(702)와 연관되며, 그리고 제2 클라이언트 디바이스(722)와 연관된 제2 코로케이트된 softAP(721)를 구현 또는 동작시킨다. 도 11의 예에는 단지 3개의 저-레이턴시 STA들만이 도시되지만, 실제 구현들에서, BSS는 임의의 수의 저-레이턴시 STA들을 포함할 수 있고, 임의의 수의 비-레거시 STA들을 또한 포함할 수 있다.

[0132] 도 11의 타이밍도는 많은 양상들에서 도 9 및 도 10의 타이밍도와 유사하고, 일부 양상들에서 도 9 및 도 10의 타이밍도와 상이하다. 예컨대, 도 9 및 도 10을 참조하여 설명된 예시적인 통신들(900 및 1000)은 softAP들(711 및 721) 및 이들의 연관된 클라이언트 디바이스들(712 및 722)에 NAV 예외를 표시하기 위한 메커니즘들을 포함하지만, 도 11의 예시적인 통신들(1100)은 NAV 예외들을 표시하거나 또는 시그널링하지 않을 수 있다. 대신에, AP(702)는, 레이턴시 민감 P2P 통신들을 위해 연관된 STA들(710, 720 또는 730) 중 하나 이상에 의해 표시되거나 요청된 시간 기간보다 짧은 시간 기간 동안, 그러한 레이턴시 민감 P2P 통신들을 위해 r-TWT SP 동안, 획득된 TXOP의 일부를 배정할 수 있다.

[0133] 일부 구현들에서, 도 11의 예는, 레이턴시 민감 P2P 통신들을 AP(702)에 통지하기 위해 AP(702)와 연관된 STA들에 의해 사용될 수 있을 뿐만 아니라, 그러한 P2P 통신들의 교환에 참여하고자 의도하는 임의의 대응하는 저-레이턴시 P2P 디바이스들에 의해 사용될 수 있는 수정된 요청 프레임 및 응답 프레임을 사용한다. 예컨대, 일부 구현들에서, 제1 STA(710)는 시간 t₀에 무선 매체를 통해 AP(702)에 요청(REQ) 프레임(1101)을 송신한다. 도 9의 요청 프레임(901) 또는 도 10의 요청 프레임(1001)의 예일 수 있는 요청 프레임(1101)은 AP(702)가 제1 softAP(711)와 클라이언트 디바이스(712) 사이의 P2P 통신들을 위해 r-TWT SP를 스케줄링하라는 요청을 포함할 수 있다. 요청 프레임(1101)은 제1 softAP(711) 및 클라이언트 디바이스(712)를, r-TWT SP 동안 스케줄링된 P2P 통신들의 참여자들로서 식별할 수 있다. 일부 양상들에서, 요청 프레임(1101)은 제1 softAP(711) 및 클라이언트 디바이스(712)의 MAC 어드레스들을 포함할 수 있다. 요청 프레임(1101)은 또한, 제1 softAP(711)와 클라이언트 디바이스(712) 사이의 P2P 통신들을 위해 제1 STA(710)에 무선 매체를 배정하기 위한 시간 기간(T₂)을 표시할 수 있다.

[0134] AP(702)는 시간 t₀ 내지 시간 t₁에 요청 프레임(1101)을 수신하고, TWT 파라미터들, 제1 softAP(711) 및 클라이언트 디바이스(712)의 아이덴티티들, 및 요청된 시간 기간(T₂)을 획득한다. 도 11의 예에 도시된 바와 같이, AP(702)는 요청된 시간 기간(T₂)보다 더 짧은 수정된 시간 기간(T₂')을 선택하고, MU-RTS TXS 트리거 프레임(1020)의 지속기간 필드를 수정된 (더 짧은) 시간 기간(T₂')으로 설정한다.

[0135] AP(702)가 시간 t₇ 내지 시간 t₈에 무선 매체를 통해 MU-RTS TXS 트리거 프레임(1020)을 송신할 때, 제1 softAP(711) 및 클라이언트 디바이스(712)는 그들의 개개의 NAV들을 MU-RTS TXS 트리거 프레임(1020)에 의해 표시된 더 짧은 시간 기간(T₂')으로 설정한다. 구체적으로, 제1 softAP(711) 및 클라이언트 디바이스(712)는 그들의 개개의 NAV들(1041 및 1042)을, 시간 t₈ 내지 시간 t_A에 걸쳐 있는 더 짧은 시간 기간(T₂')으로 설정한다. 논의된 바와 같이, 더 짧은 시간 기간(T₂')은 제1 STA(710)가 MU-RTS TXS 트리거 프레임(1020)을 수신하고 CTS 프레임(1021)을 송신하는 동안 무선 매체를 보호하기에 충분하다.

[0136] 시간 t_A에, 제1 softAP(711)의 NAV(1041)가 만료되고, 적어도 시간 t_A 내지 시간 t₁₀의 SIFS 지속기간을 대기한 후, 제1 softAP(711)는 무선 매체를 통해 클라이언트 디바이스(712)에 트리거 프레임(1030)을 송신한다. 일부 예시들에서, 제1 softAP(711)는 무선 매체 상에서 트리거 프레임(1030)을 송신하기 전에 PIFS 지속기간 동안 대기할 수 있다. 도 11의 예에서, 트리거 프레임(1030)은 예컨대, 트리거 프레임(1030)에 포함되는 사용자 정보 필드에 MAC 어드레스(또는 다른 적절한 식별자)를 포함시킴으로써 클라이언트 디바이스(712)를 식별한다.

[0137] 그 NAV(1042)가 또한 시간 t_A에 만료된 클라이언트 디바이스(712)는 시간 t₁₁ 내지 시간 t₁₂에 트리거 프레임(1030)을 수신한다. 일부 예시들에서, 트리거 프레임(1030)은 클라이언트 디바이스(712)로부터 UL P2P 송신들을 요청할 수 있다. 트리거 프레임(1030)을 수신하는 것에 대한 응답으로, 클라이언트 디바이스(712)는 시간 t₁₁ 내지 시간 t₁₂에 무선 매체 상에서 TB PPDU(1031)를 제1 softAP(711)에 송신한다. 제1 softAP(711)는 TB PPDU(1031)를 수신하고, 시간 t₁₃ 내지 시간 t₁₄에 블록 ACK 프레임(1032)을 클라이언트 디바이스(712)에 송신함으로써 TB PPDU(1031)의 수신을 확인응답한다. 제1 STA(710)에 의해 표시되거나 요청된 시간 기간(T₂)은 시간 t₁₄에 종료된다. 일부 예시들에서, 제2 STA(720), 제2 softAP(721), 제2 클라이언트 디바이스(722) 및 제3 STA(730)와 연관된 NAV들(940-943)은 시간 t₈ 내지 시간 t₁₄에 걸쳐 있는 시간 지속기간으로 설정된다. r-TWT SP는 시간 t₁₅에 종료된다.

[0138] 도 12는 다른 구현들에 따른, BSS에 속하는 디바이스들 사이의 예시적인 무선 통신(1200)을 도시하는 타이밍도를 도시한다. BSS는 도 7을 참조하여 설명된 AP(702), 제1 STA(710), 제2 STA(720) 및 제3 STA(730)를 포함하는 것으로 도시된다. 논의된 바와 같이, 제1 STA(710)는 AP(702)와 연관되며, 그리고 제1 클라이언트 디바이스(712)와 연관된 제1 코로케이트된 softAP(711)를 구현 또는 동작시킨다. 유사하게, 제2 STA(720)는 AP(702)와 연관되며, 그리고 제2 클라이언트 디바이스(722)와 연관된 제2 코로케이트된 softAP(721)를 구현 또는 동작시킨다. 도 12의 예에는 단지 3개의 저-레이턴시 STA들만이 도시되지만, 실제 구현들에서, BSS는 임의의 수의 저-레이턴시 STA들을 포함할 수 있고, 임의의 수의 비-레거시 STA들을 또한 포함할 수 있다.

[0139] 도 12의 타이밍도는, 도 12의 예시적인 통신들(1200)이 MU-RTS TXS 트리거 프레임들을 사용하지 않는다는 점을 제외하고, 많은 양상들에서 도 8의 타이밍도와 유사하다. 대신에, 예시적인 통신들(1200)은, 제1 STA(710)가 제1 softAP(711)와 클라이언트 디바이스(712) 사이의 P2P 통신들을 위해 무선 매체를 활용하고자 하는 자신의 의도를 AP(702)에 통지할 수 있도록 허용하는 시그널링을 사용한다.

[0140] 구체적으로, 시간 t₀에, 제1 STA(710)는 무선 매체를 통해 요청(REQ) 프레임(1201)을 AP(702)에 송신한다. 요청 프레임(1201)은, AP(702)가 r-TWT SP를 스케줄링하라는 요청을 포함할 수 있고, r-TWT SP 동안, 제1 softAP(711)는 무선 매체를 사용하여 클라이언트 디바이스(712)에 저-레이턴시 데이터를 송신하거나 또는 클라이언트 디바이스(712)로부터 저-레이턴시 데이터를 수신할 수 있다. 일부 구현들에서, 요청 프레임(1201)은 제1 STA(710)의 의도를 표시하는 VSIE(vendor-specific information element)를 포함한다. 일부 예시들에서, VSIE는 또한 요청된 r-TWT SP에 대한 다양한 TWT 파라미터들을 표시할 수 있다. 예컨대, VSIE는 TWT r-TWT SP의 주기성, r-TWT SP의 지속기간, r-TWT SP의 공유 모드, r-TWT SP의 웨이크 지속기간, r-TWT SP의 흐름 타입, 또는 r-TWT SP의 파라미터 세트를 표시할 수 있다.

[0141] 시간 t₀ 내지 시간 t₁에, AP(702)는 요청 프레임(1201)을 디코딩하고, 제1 softAP(711)와 클라이언트 디바이스(712) 사이의 P2P 통신들을 위해 r-TWT SP의 일부 동안 제1 STA(710)에 배정된 무선 매체를 사용하고자 하는 제1 STA(710)의 의도 및 TWT 파라미터들을 획득한다.

[0142] 시간 t₁에, AP(702)는 무선 매체 상에서 제1 STA(710)에 응답(Resp) 프레임(1202)을 송신한다. 응답 프레임(1202)은 스케줄링된 r-TWT SP에 대해 사용될 TWT 파라미터들의 세트를 표시하는 VSIE를 포함할 수 있다. 일부 구현들에서, VSIE는 또한 r-TWT SP의 멤버들인 디바이스들의 수를 표시할 수 있다. 이러한 정보는 제1 STA(710)가, 자신이 r-TWT SP의 유일한 멤버인지 여부를 결정하고, 그에 따라, r-TWT SP 동안 MU-RTS TXS 트리거 프레임들보다, 공격적인 채널 액세스 기법들을 사용할 수 있는지 여부를 결정하도록 허용할 수 있다. 일부 양상들에서, VSIE는 또한 제1 softAP(711) 및 클라이언트 디바이스(712)를 식별할 수 있다.

[0143] 제1 softAP(711)는, TXOP를 획득하고자 시도하기 전에 채널 감지 동작(이를테면, CCA(clear channel assessment))에 기반하여 무선 매체가 적어도 SIFS 지속기간, 즉 시간 t₃ 내지 시간 t₄ 동안 유휴 상태임을 감지한다. 시간 t₄에, 제1 softAP(711)는 무선 매체가 여전히 유휴 상태임을 감지하고 무선 매체 상에서 트리거 프레임(1210)을 송신한다. 도 12의 예에서, 트리거 프레임(1210)은, 예컨대, 트리거 프레임(1210)의 사용자 정보 필드에 클라이언트 디바이스(712)의 디바이스 식별자(이를테면, MAC 어드레스)를 포함시킴으로써 클라이언트 디바이스(712)를 식별한다.

[0144] 클라이언트 디바이스(712)는 트리거 프레임(1210)을 수신하고, 트리거 프레임(1210)이 클라이언트 디바이스(712)를 식별한다고 결정한다. 트리거 프레임(1210)을 수신하는 것에 대한 응답으로, 클라이언트 디바이스(712)는 시간 t₆ 내지 시간 t₇에 무선 매체 상에서 TB PPDU(1220)를 제1 softAP(711)에 송신한다. 제1 softAP(711)는 TB PPDU(1220)를 수신하고, 시간 t₈ 내지 시간 t₉에 블록 ACK 프레임(1230)을 클라이언트 디바이스(712)에 송신함으로써 TB PPDU(1220)의 수신을 확인응답한다. r-TWT SP는 시간 t₁₀에 종료된다.

[0145] 도 13은 다른 구현들에 따른, BSS에 속하는 디바이스들 사이의 예시적인 무선 통신(1300)을 도시하는 타이밍도를 도시한다. BSS는 도 7을 참조하여 설명된 AP(702), 제1 STA(710), 제2 STA(720) 및 제3 STA(730)를 포함하는 것으로 도시된다. 논의된 바와 같이, 제1 STA(710)는 AP(702)와 연관되며, 그리고 제1 클라이언트 디바이스(712)와 연관된 제1 (코로케이트된) softAP(711)를 구현 또는 동작시킨다. 유사하게, 제2 STA(720)는 AP(702)와 연관되며, 그리고 제2 클라이언트 디바이스(722)와 연관된 제2 (코로케이트된) softAP(721)를 구현 또는 동작시킨다. 도 13의 예에는 단지 3개의 저-레이턴시 STA들만이 도시되지만, 실제 구현들에서, BSS는 임의의 수의 저-레이턴시 STA들을 포함할 수 있고, 임의의 수의 비-레거시 STA들을 또한 포함할 수 있다.

[0146] 도 13의 타이밍도는, 도 13의 예시적인 통신들(1300)이 임의의 r-TWT SP 외부에서 발생한다는 점을 제외하고, 많은 양상들에서 도 9의 타이밍도와 유사하다. 일부 구현들에서, AP(702)는, TXOP를 획득하고자 시도하기 전에 채널 감지 동작(이를테면, CCA(clear channel assessment))에 기반하여 매체가 PIFS 지속기간, 즉 시간 t₀ 내지 시간 t₁ 동안 유휴 상태임을 감지한다. 시간 t₁에, AP(702)는 무선 매체가 여전히 유휴 상태임을 감지하고, 예컨대, 공유 매체를 통한 송신을 개시함으로써, TXOP를 획득하도록 진행한다. 구체적으로, AP(702)는 TXOP를 획득하기에 충분히 긴 무선 매체를 예비하기 위해 무선 매체 상에서 CTS2self(CTS-to-self) 프레임(1301)을 송신한다. AP(702)는 무선 매체 상에서 TXOP를 획득하고, 시간 t₃에, 트리거링-기반 UL 송신을 위해 제1 STA(710) 및 제2 STA(720)를 식별하는 트리거 프레임(910)을 송신한다. 일부 예시들에서, 트리거 프레임(910)은 제1 및 제2 STA들(710 및 720)에 할당된 AID(association identifier)들을 반송하는 사용자별 정보 필드(Per User Info field)들을 포함한다.

[0147] 도 13의 예시적인 통신(1300)에서의 시간 t₃ 내지 시간 t₁₄의 프레임 시퀀스들은 도 9의 예시적인 통신(900)에서의 시간 t₃ 내지 시간 t₁₄의 프레임 시퀀스들과 유사하다. 예컨대, AP(702)는 시간 t₇ 내지 시간 t₈에 무선 매체를 통해 MU-RTS TXS 트리거 프레임(920)을 송신한다. MU-RTS TXS 트리거 프레임(920)은, r-TWT SP 동안 클라이언트 디바이스(712)와 제1 softAP1(711) 사이의 P2P 통신들을 위해, AP(702)에 의해 획득된 TXOP의 일부를 배정한다. MU-RTS TXS 트리거 프레임(920)은, TXOP가 P2P 통신들을 위해 배정되는 시간 지속기간(T₁)을 표시하는 지속기간 필드를 포함한다. 이러한 방식으로, MU-RTS TXS 트리거 프레임(920)에 의해 식별되지 않은 수신 디바이스들은, 예컨대, 시간(T₁)의 표시된 지속시간으로 그들의 개개의 NAV들을 설정하며, 그에 따라, 클라이언트 디바이스(712)와 제1 softAP(711) 사이의 저-레이턴시 P2P 통신들이 중단되거나 저하되지 않는다.

[0148] MU-RTS TXS 트리거 프레임(920)은, 제1 softAP(711) 및 클라이언트 디바이스(712)가 MU-RTS TXS 트리거 프레임(920)에 의해 표시되는 NAV 지속기간들 또는 MU-RTS TXS 트리거 프레임(920)에 후속하는 CTS 프레임들에 의해 표시되는 NAV 지속기간들을 무시해야 함을 표시하는 NAV 예외를 시그널링한다. 일부 양상들에서, MU-RTS TXS 트리거 프레임(920)은, 예컨대, 제1 softAP(711) 및 클라이언트 디바이스(712)의 MAC 어드레스들을 포함하거나 표시할 수 있으며, 그에 따라, 제1 softAP(711) 및 클라이언트 디바이스(712)는 MU-RTS TXS 트리거 프레임(920)을 수신 및 디코딩한다. 이러한 방식으로, 제1 softAP(711)는 시간 t₁₀에 클라이언트 디바이스(712)에 트리거 프레임(930)을 송신할 수 있고, 클라이언트 디바이스(712)는 시간 t₁₁ 내지 시간 t₁₂에 제1 softAP(711)에 TB PPDU(931)를 송신할 수 있다.

[0149] 도 14는 다른 구현들에 따른, BSS에 속하는 디바이스들 사이의 예시적인 무선 통신(1400)을 도시하는 타이밍도를 도시한다. BSS는 도 7을 참조하여 설명된 AP(702), 제1 STA(710), 제2 STA(720) 및 제3 STA(730)를 포함하는 것으로 도시된다. 논의된 바와 같이, 제1 STA(710)는 AP(702)와 연관되며, 그리고 제1 클라이언트 디바이스(712)와 연관된 제1 코로케이트된 softAP(711)를 구현 또는 동작시킨다. 유사하게, 제2 STA(720)는 AP(702)와 연관되며, 그리고 제2 클라이언트 디바이스(722)와 연관된 제2 코로케이트된 softAP(721)를 구현 또는 동작시킨다. 도 14의 예에는 단지 3개의 저-레이턴시 STA들만이 도시되지만, 실제 구현들에서, BSS는 임의의 수의 저-레이턴시 STA들을 포함할 수 있고, 임의의 수의 비-레거시 STA들을 또한 포함할 수 있다. 도 14의 예에서, AP(702)는 시간 듀플렉싱 방식으로 r-TWT SP 내의 다수의 P2P 세션들을 스케줄링한다.

[0150] 예컨대, AP는, 제1 STA(710)와 연관된 P2P 통신들을 위해, AP(702)에 의해 획득된 TXOP의 일부를 배정하기 위하여 시간 t₁에 MU-RTS TXS 트리거 프레임(1410)을 송신한다. 시간 t₂에, 제1 softAP(711)는 AP(702)에 CTS 프레임(1511)을 송신한다. 시간 t₃에, 제1 softAP(711)는 무선 매체가 유휴 상태임을 감지하고, 무선 매체 상에서 클라이언트 디바이스(712)에 트리거 프레임(1412)을 송신한다. 도 14의 예에서, 트리거 프레임(1412)은 예컨대, 트리거 프레임(1412)에 포함되는 사용자 정보 필드에 MAC 어드레스(또는 다른 적절한 식별자)를 포함시킴으로써 클라이언트 디바이스(712)를 식별한다. 클라이언트 디바이스(712)는 트리거 프레임(1412)을 수신하고, 시간 t₄ 내지 시간 t₅에 무선 매체 상에서 제1 softAP(711)에 TB PPDU(931)를 송신한다. 제1 softAP(711)는 TB PPDU를 수신하고, 시간 t₅에 블록 ACK 프레임을 클라이언트 디바이스(712)에 송신함으로써 TB PPDU의 수신을 확인응답한다.

[0151] 그런 다음, 시간 t₆에, AP는 제2 STA(720)와 연관된 P2P 통신들을 위해, AP(702)에 의해 획득된 TXOP의 일부를 배정하기 위하여 다른 MU-RTS TXS 트리거 프레임(1420)을 송신한다. 시간 t₈에, 제2 softAP(721)는 무선 매체가 유휴 상태임을 감지하고, 무선 매체 상에서 클라이언트 디바이스(722)에 트리거 프레임(1422)을 송신한다. 도 14의 예에서, 트리거 프레임(1422)은 예컨대, 트리거 프레임(1422)에 포함되는 사용자 정보 필드에 MAC 어드레스(또는 다른 적절한 식별자)를 포함시킴으로써 클라이언트 디바이스(722)를 식별한다. 클라이언트 디바이스(722)는 트리거 프레임(1422)을 수신하고, 시간 t₉ 내지 시간 t₁₀에 무선 매체 상에서 제2 softAP(721)에 TB PPDU(931)를 송신한다. 제2 softAP(721)는 TB PPDU를 수신하고, 시간 t₁₁에 블록 ACK 프레임을 클라이언트 디바이스(722)에 송신함으로써 TB PPDU의 수신을 확인응답한다.

[0152] 도 15는 다른 구현들에 따른, BSS에 속하는 디바이스들 사이의 예시적인 무선 통신(1500)을 도시하는 타이밍도를 도시한다. BSS는 도 7을 참조하여 설명된 AP(702), 제1 STA(710), 제2 STA(720) 및 제3 STA(730)를 포함하는 것으로 도시된다. 논의된 바와 같이, 제1 STA(710)는 AP(702)와 연관되며, 그리고 제1 클라이언트 디바이스(712)와 연관된 제1 코로케이트된 softAP(711)를 구현 또는 동작시킨다. 유사하게, 제2 STA(720)는 AP(702)와 연관되며, 그리고 제2 클라이언트 디바이스(722)와 연관된 제2 코로케이트된 softAP(721)를 구현 또는 동작시킨다. 도 15의 예에는 단지 3개의 저-레이턴시 STA들만이 도시되지만, 실제 구현들에서, BSS는 임의의 수의 저-레이턴시 STA들을 포함할 수 있고, 임의의 수의 비-레거시 STA들을 또한 포함할 수 있다. 도 15의 타이밍도는, AP(702)가 r-TWT SP 내의 스케줄링된 다수의 P2P 세션들에 대해 동시에 주파수 멀티플렉싱을 사용한다는 점을 제외하고, 도 14의 타이밍도와 유사하다. 도시된 바와 같이, AP(702)는 하위 20 MHz 주파수 서브대역에서 제1 STA(710)와 연관된 P2P 통신들을 스케줄링하고, 상위 20 MHz 주파수 서브대역에서 제2 STA(720)와 연관된 P2P 통신들을 스케줄링한다.

[0153] 예컨대, AP는, 하위 20 MHz 주파수 서브대역 상에서 제1 STA(710)와 연관된 P2P 통신들을 위해 AP(702)에 의해 획득된 TXOP의 일부를 배정하고 그리고 상위 20 MHz 주파수 서브대역 상에서 제2 STA(720)와 연관된 P2P 통신들을 위해 TXOP의 일부를 배정하기 위해, 시간 t₁에 MU-RTS TXS 트리거 프레임(1510)을 송신한다. 시간 t₂에, 제1 softAP(711)는 AP(702)에 CTS 프레임(1511)을 송신한다. 시간 t₃에, 제1 softAP는 무선 매체 상에서 클라이언트 디바이스(712)에 트리거 프레임(1512)을 송신한다. 도 15의 예에서, 트리거 프레임(1512)은 예컨대, 트리거 프레임(1512)에 포함되는 사용자 정보 필드에 MAC 어드레스(또는 다른 적절한 식별자)를 포함시킴으로써 클라이언트 디바이스(712)를 식별한다. 클라이언트 디바이스(712)는 트리거 프레임(1512)을 수신하고, 시간 t₄ 내지 시간 t₅에 무선 매체 상에서 제1 softAP(711)에 TB PPDU를 송신한다. 제1 softAP(711)는 TB PPDU를 수신하고, 시간 t₅에 블록 ACK 프레임을 클라이언트 디바이스(712)에 송신함으로써 TB PPDU의 수신을 확인응답한다. 그런 다음, 시간 t₆에, AP는 다른 MU-RTS TXS 트리거 프레임(1520)을 송신한다. 시간 t₈에, 제1 softAP(711)는 무선 매체 상에서 클라이언트 디바이스(712)에 트리거 프레임(1522)을 송신한다.

[0154] 도 16은 일부 구현들에 따른, 저-레이턴시 통신들을 지원하는 무선 통신을 위한 예시적인 프로세스(1600)를 예시하는 흐름도를 도시한다. 프로세스(1600)는 도 5를 참조하여 위에서 설명된 무선 통신 디바이스(500)와 같은 무선 통신 디바이스에 의해 수행될 수 있다. 일부 구현들에서, 프로세스(1600)는, 각각 도 1 및 도 6a를 참조로 위에서 설명된 AP들(102 및 602) 중 하나와 같은 AP 내에 있거나 또는 이러한 AP로서 동작하는 무선 통신 디바이스에 의해 수행될 수 있다.

[0155] 일부 구현들에서, 프로세스(1600)는, 블록(1602)에서, AP와 연관되고 그리고 P2P(peer-to-peer) 링크를 통해 클라이언트 디바이스와 또한 연관된 무선 STA(station)로부터 요청 프레임을 수신하는 것으로 시작되고, 요청 프레임은, 무선 매체에 스케줄링된 r-TWT(restricted target wake time) SP(service period) 동안 STA가 클라이언트 디바이스와 P2P 통신들을 교환하고자 의도함을 표시하고, 요청 프레임은 클라이언트 디바이스를 식별한다. 블록(1604)에서, 프로세스(1600)는, 요청 프레임을 수신하는 것에 대한 응답으로, 무선 매체 상에서 STA에 응답 프레임을 송신하는 것으로 계속된다. 블록(1606)에서, 프로세스(1600)는 r-TWT SP 동안 무선 매체 상에서 TXOP(transmission opportunity)를 획득하는 것으로 계속된다. 블록(1608)에서, 프로세스(1600)는, TXOP를 획득하는 것에 대한 응답으로, 무선 매체 상에서 트리거 프레임을 송신하는 것으로 계속되고, 트리거 프레임은 STA와 클라이언트 디바이스 사이의 P2P 통신들을 위해, 획득된 TXOP의 일부를 배정하고, 응답 프레임 또는 트리거 프레임 중 적어도 하나는 클라이언트 디바이스에 대한 NAV 예외를 표시한다. 일부 예시들에서, 응답 프레임 및 트리거 프레임 각각은 클라이언트 디바이스의 MAC(medium access control) 어드레스를 포함할 수 있다.

[0156] 일부 구현들에서, NAV 예외는, 클라이언트 디바이스가 트리거 프레임에 의해 표시되는 NAV 지속기간 및 트리거 프레임에 후속하는 CTS(clear-to-send) 프레임에 의해 표시되는 NAV 지속기간을 무시해야 함을 표시한다. 일부 양상들에서, 트리거 프레임은 0의 값으로 설정된 비트를 반송하는 CS(Carrier Sense) 필수 필드를 포함하고, 0의 값으로 설정된 비트는 NAV 예외를 표시한다.

[0157] 요청 프레임은, r-TWT SP를 요청하고 그리고 r-TWT SP 동안 클라이언트 디바이스와의 P2P 통신들을 위해 무선 매체를 사용하고자 하는 STA의 의도를 시그널링할 수 있는 임의의 적절한 프레임일 수 있다. 일부 구현들에서, 요청 프레임은 클라이언트 디바이스의 MAC 어드레스를 표시하는 TWT 엘리먼트를 포함하는 TWT 요청 프레임일 수 있다. 일부 양상들에서, TWT 엘리먼트는 r-TWT SP 동안 클라이언트 디바이스와의 P2P 통신들을 위해 무선 매체를 사용하고자 하는 STA의 의도를 시그널링하기 위해 사용될 수 있다. TWT 엘리먼트는 또한, r-TWT SP의 주기성, r-TWT SP의 지속기간, r-TWT SP의 공유 모드, r-TWT SP의 웨이크 지속기간, r-TWT SP의 흐름 타입, 또는 r-TWT SP의 파라미터 세트를 포함하는(그러나 이것들로 제한되지는 않음) 다양한 TWT 파라미터들을 표시할 수 있다.

[0158] 다른 구현들에서, 요청 프레임은 클라이언트 디바이스의 MAC 어드레스를 표시하는 TSPEC(traffic specification) 엘리먼트를 포함하는 SCS(Stream Classification Service) 요청 프레임일 수 있다. TSPEC 엘리먼트는 또한, P2P 통신들과 연관된 TS(traffic stream), 제한된 TWT 세션에 대한 최소 데이터 레이트, 제한된 TWT 세션에 대한 평균 데이터 레이트, r-TWT SP에 대한 지연 한계, 및 r-TWT SP에 대한 UP(user priority)를 표시할 수 있다. 일부 다른 구현들에서, 요청 프레임은, 클라이언트 디바이스의 MAC 어드레스를 표시하고 그리고 r-TWT SP 동안 클라이언트 디바이스와의 P2P 통신들을 위해 무선 매체를 사용하고자 하는 STA의 의도를 시그널링하는 P2P 요청 프레임일 수 있다. 일부 예시들에서, P2P 요청 프레임은, 클라이언트 디바이스의 MAC 어드레스를 표시하고 STA의 의도를 시그널링하는 TWT 엘리먼트, TSPEC 엘리먼트, 또는 VSIE(vendor-specific information element) 중 하나 이상을 포함할 수 있다. TWT 엘리먼트는, P2P 요청 프레임에 존재하는 경우, r-TWT SP와 연관된 TWT 파라미터들을 또한 표시할 수 있다. TSPEC 엘리먼트는, P2P 요청 프레임에 존재하는 경우, BSS와 연관된 P2P 링크들의 다양한 QoS 파라미터들, 데이터 레이트들, 액세스 카테고리들 및 사용자 우선순위들을 또한 표시할 수 있다.

[0159] 응답 프레임은 STA에 의해 요청된 r-TWT SP의 스케줄링을 확인할 수 있는 임의의 적절한 프레임일 수 있다. 일부 구현들에서, 응답 프레임은 클라이언트 디바이스의 MAC 어드레스를 표시하는 TWT 응답 프레임일 수 있다. TWT 응답 프레임은 r-TWT SP의 멤버들인 디바이스들에 의해 사용될 TWT 파라미터들의 세트를 표시하는 TWT 엘리먼트를 포함할 수 있다. 다른 구현들에서, 응답 프레임은 클라이언트 디바이스의 MAC 어드레스를 표시하는 SCS 응답 프레임일 수 있다. SCS 응답 프레임은 TSPEC 엘리먼트를 포함할 수 있고, 이는 클라이언트 디바이스의 MAC 어드레스를 표시하는 TSPEC을 포함할 수 있다. TSPEC 엘리먼트는 또한, BSS와 연관된 P2P 링크들의 다양한 QoS 파라미터들, 데이터 레이트들, 액세스 카테고리들 및 사용자 우선순위들을 표시할 수 있다. 일부 다른 구현들에서, 응답 프레임은, 클라이언트 디바이스의 MAC 어드레스를 표시하고 그리고 r-TWT SP 동안 클라이언트 디바이스와의 P2P 통신들을 위해 무선 매체를 사용하고자 하는 STA의 의도를 시그널링하는 P2P 응답 프레임일 수 있다. 일부 예시들에서, P2P 응답 프레임은, 클라이언트 디바이스의 MAC 어드레스를 표시하고 STA의 의도를 시그널링하는 TWT 엘리먼트, TSPEC 엘리먼트, 또는 VSIE 중 하나 이상을 포함할 수 있다. TWT 엘리먼트는, P2P 응답 프레임에 존재하는 경우, r-TWT SP 동안 멤버 디바이스들에 의해 사용될 TWT 파라미터들의 세트를 또한 표시할 수 있다. TSPEC 엘리먼트는, P2P 응답 프레임에 존재하는 경우, 다양한 QoS 파라미터들, 데이터 레이트들, 액세스 카테고리들 및 사용자 우선순위들을 또한 표시할 수 있다.

[0160] 일부 예시들에서, 응답 프레임은 클라이언트 디바이스에 대한 NAV 예외를 표시할 수 있다. 즉, 응답 프레임은, 클라이언트 디바이스가 AP로부터 송신된 트리거 프레임들에 의해 설정되는 NAV 지속기간들 및 트리거 프레임들에 대한 응답으로 CTS 프레임들에 의해 설정되는 NAV 지속기간들을 무시해야 함을 표시할 수 있다. 다른 경우들에서, 응답 프레임은 r-TWT SP의 멤버들인 디바이스들의 수를 표시할 수 있다. r-TWT SP에 속하는 다른 디바이스들의 수는 r-TWT SP의 하나 이상의 속성들을 선택하기 위해 STA에 의해 사용될 수 있다. 예컨대, STA가 r-TWT SP의 유일한 멤버인 경우, STA는 MU-RTS TXS 트리거 프레임들이 필요하지 않다고(또는 선호되지 않는다고) 결정할 수 있고, MU-RTS TXS 트리거 프레임들의 송신들을 포함하지 않는 r-TWT SP를 요청할 수 있다.

[0161] 일부 구현들에서, 트리거 프레임은 MU(multi-user) RTS(Request-to-Send) TXS(TXOP Sharing) 트리거 프레임일 수 있다. MU-RTS TXS 트리거 프레임은 STA와 클라이언트 디바이스 사이의 P2P 통신들과 연관된 TXOP 공유 모드를 표시하는 TXOP 공유 모드 서브필드를 포함할 수 있다. 일부 예시들에서, TXOP 공유 모드 서브필드는 STA가 MU-RTS TXS 트리거 프레임에 대한 응답으로 CTS 프레임을 송신하라는 요청을 표시한다. CTS 프레임은 클라이언트 디바이스의 MAC 어드레스를 포함하는 수신기 어드레스 필드를 포함할 수 있다.

[0162] 일부 다른 구현들에서, STA는 STA와 클라이언트 디바이스 사이의 P2P 통신들을 관리하는 코로케이트된 softAP를 포함할 수 있다. 일부 예시들에서, softAP는 STA와 상이한 MAC 어드레스를 가질 수 있다. 예컨대, STA는, AP 및 클라이언트 디바이스와 독립적으로 통신할 수 있는 별개의 MAC 엔티티들을 포함할 수 있다. 일부 양상들에서, 제1 MAC-AP 엔드포인트는 AP와의 비-AP STA 통신들과 연관될 수 있고, 제2 MAC-SAP 엔드포인트는 클라이언트 디바이스와의 softAP 통신들과 연관될 수 있다. 이들 구현들에서, NAV 예외는 또한, r-TWT SP에 속하는 STA들과 코로케이트된 softAP들이 트리거 프레임들에 의해 표시되는 NAV 지속기간들 및 트리거 프레임들에 후속하는 CTS 프레임들에 의해 표시되는 NAV 지속기간들을 무시해야 함을 표시할 수 있다.

[0163] 도 17은 일부 다른 구현들에 따른, 저-레이턴시 통신들을 지원하는 무선 통신들을 위한 예시적인 프로세스(1700)를 예시하는 흐름도를 도시한다. 프로세스(1700)는 도 5를 참조하여 위에서 설명된 무선 통신 디바이스(500)와 같은 무선 통신 디바이스에 의해 수행될 수 있다. 일부 구현들에서, 프로세스(1700)는, 각각 도 1 및 도 6b를 참조로 위에서 설명된 STA들(104 및 604) 중 하나와 같은 STA 내에 있거나 또는 이러한 STA로서 동작하는 무선 통신 디바이스에 의해 수행될 수 있다.

[0164] 일부 구현들에서, 프로세스(1700)는, 블록(1702)에서, 무선 통신 디바이스를 AP(access point)와 연관된 무선 STA(station)로서 동작시키는 것으로 시작되고, STA는 P2P(peer-to-peer) 링크를 통해 클라이언트 디바이스와 또한 연관된다. 블록(1704)에서, 프로세스(1700)는 AP에 요청 프레임을 송신하는 것으로 계속되고, 요청 프레임은, 무선 매체에 스케줄링된 r-TWT(restricted target wake time) SP(service period) 동안 STA가 클라이언트 디바이스와 P2P 통신들을 교환하고자 의도함을 표시하고, 요청 프레임은 클라이언트 디바이스를 식별한다. 블록(1706)에서, 프로세스(1700)는 무선 매체 상에서 AP로부터 응답 프레임을 수신하는 것으로 계속된다. 블록(1708)에서, 프로세스(1700)는 무선 매체 상에서 제1 트리거 프레임을 수신하는 것으로 계속되고, 제1 트리거 프레임은 STA와 클라이언트 디바이스 사이의 P2P 통신들을 위해, AP에 의해 획득된 TXOP(transmission opportunity)의 일부를 배정하고, 응답 프레임 또는 제1 트리거 프레임 중 적어도 하나는 클라이언트 디바이스에 대한 NAV 예외를 표시한다. 블록(1710)에서, 프로세스(1700)는 무선 매체 상에서 AP에 CTS(clear-to-send) 프레임을 송신하는 것으로 계속되고, CTS 프레임은 클라이언트 디바이스의 MAC 어드레스를 포함하는 수신기 어드레스 필드를 포함한다. 일부 양상들에서, 응답 프레임 및 제1 트리거 프레임 각각은 클라이언트 디바이스의 MAC 어드레스를 포함한다.

[0165] 일부 구현들에서, NAV 예외는, 클라이언트 디바이스가 트리거 프레임에 의해 표시되는 NAV 지속기간 및 트리거 프레임에 후속하는 CTS(clear-to-send) 프레임에 의해 표시되는 NAV 지속기간을 무시해야 함을 표시한다. 일부 양상들에서, 트리거 프레임은 0의 값으로 설정된 비트를 반송하는 CS(Carrier Sense) 필수 필드를 포함하고, 0의 값으로 설정된 비트는 NAV 예외를 표시한다.

[0166] 요청 프레임은, r-TWT SP를 요청하고 그리고 r-TWT SP 동안 클라이언트 디바이스와의 P2P 통신들을 위해 무선 매체를 사용하고자 하는 STA의 의도를 시그널링할 수 있는 임의의 적절한 프레임일 수 있다. 일부 구현들에서, 요청 프레임은 클라이언트 디바이스의 MAC 어드레스를 표시하는 TWT 엘리먼트를 포함하는 TWT 요청 프레임일 수 있다. 일부 양상들에서, TWT 엘리먼트는 r-TWT SP 동안 클라이언트 디바이스와의 P2P 통신들을 위해 무선 매체를 사용하고자 하는 STA의 의도를 시그널링하기 위해 사용될 수 있다. TWT 엘리먼트는 또한, r-TWT SP의 주기성, r-TWT SP의 지속기간, r-TWT SP의 공유 모드, r-TWT SP의 웨이크 지속기간, r-TWT SP의 흐름 타입, 또는 r-TWT SP의 파라미터 세트를 포함하는(그러나 이것들로 제한되지는 않음) 다양한 TWT 파라미터들을 표시할 수 있다.

[0167] 다른 구현들에서, 요청 프레임은 클라이언트 디바이스의 MAC 어드레스를 표시하는 TSPEC(traffic specification) 엘리먼트를 포함하는 SCS(Stream Classification Service) 요청 프레임일 수 있다. TSPEC 엘리먼트는 또한, P2P 통신들과 연관된 TS(traffic stream), 제한된 TWT 세션에 대한 최소 데이터 레이트, 제한된 TWT 세션에 대한 평균 데이터 레이트, r-TWT SP에 대한 지연 한계, 및 r-TWT SP에 대한 UP(user priority)를 표시할 수 있다. 일부 다른 구현들에서, 요청 프레임은, 클라이언트 디바이스의 MAC 어드레스를 표시하고 그리고 r-TWT SP 동안 클라이언트 디바이스와의 P2P 통신들을 위해 무선 매체를 사용하고자 하는 STA의 의도를 시그널링하는 P2P 요청 프레임일 수 있다. 일부 예시들에서, P2P 요청 프레임은, 클라이언트 디바이스의 MAC 어드레스를 표시하고 STA의 의도를 시그널링하는 TWT 엘리먼트, TSPEC 엘리먼트, 또는 VSIE(vendor-specific information element) 중 하나 이상을 포함할 수 있다. TWT 엘리먼트는, P2P 요청 프레임에 존재하는 경우, r-TWT SP와 연관된 TWT 파라미터들을 또한 표시할 수 있다. TSPEC 엘리먼트는, P2P 요청 프레임에 존재하는 경우, BSS와 연관된 P2P 링크들의 다양한 QoS 파라미터들, 데이터 레이트들, 액세스 카테고리들 및 사용자 우선순위들을 또한 표시할 수 있다.

[0168] 응답 프레임은 STA에 의해 요청된 r-TWT SP의 스케줄링을 확인할 수 있는 임의의 적절한 프레임일 수 있다. 일부 구현들에서, 응답 프레임은 클라이언트 디바이스의 MAC 어드레스를 표시하는 TWT 응답 프레임일 수 있다. TWT 응답 프레임은 r-TWT SP의 멤버들인 디바이스들에 의해 사용될 TWT 파라미터들의 세트를 표시하는 TWT 엘리먼트를 포함할 수 있다. 다른 구현들에서, 응답 프레임은 클라이언트 디바이스의 MAC 어드레스를 표시하는 SCS 응답 프레임일 수 있다. SCS 응답 프레임은 TSPEC 엘리먼트를 포함할 수 있고, 이는 클라이언트 디바이스의 MAC 어드레스를 표시하는 TSPEC을 포함할 수 있다. TSPEC 엘리먼트는 또한, BSS와 연관된 P2P 링크들의 다양한 QoS 파라미터들, 데이터 레이트들, 액세스 카테고리들 및 사용자 우선순위들을 표시할 수 있다. 일부 다른 구현들에서, 응답 프레임은, 클라이언트 디바이스의 MAC 어드레스를 표시하고 그리고 r-TWT SP 동안 클라이언트 디바이스와의 P2P 통신들을 위해 무선 매체를 사용하고자 하는 STA의 의도를 시그널링하는 P2P 응답 프레임일 수 있다. 일부 예시들에서, P2P 응답 프레임은, 클라이언트 디바이스의 MAC 어드레스를 표시하고 STA의 의도를 시그널링하는 TWT 엘리먼트, TSPEC 엘리먼트, 또는 VSIE 중 하나 이상을 포함할 수 있다. TWT 엘리먼트는, P2P 응답 프레임에 존재하는 경우, r-TWT SP 동안 멤버 디바이스들에 의해 사용될 TWT 파라미터들의 세트를 또한 표시할 수 있다. TSPEC 엘리먼트는, P2P 응답 프레임에 존재하는 경우, 다양한 QoS 파라미터들, 데이터 레이트들, 액세스 카테고리들 및 사용자 우선순위들을 또한 표시할 수 있다.

[0169] 일부 예시들에서, 응답 프레임은 클라이언트 디바이스에 대한 NAV 예외를 표시할 수 있다. 즉, 응답 프레임은, 클라이언트 디바이스가 AP로부터 송신된 트리거 프레임들에 의해 설정되는 NAV 지속기간들 및 트리거 프레임들에 대한 응답으로 CTS 프레임들에 의해 설정되는 NAV 지속기간들을 무시해야 함을 표시할 수 있다. 다른 경우들에서, 응답 프레임은 r-TWT SP의 멤버들인 디바이스들의 수를 표시할 수 있다. r-TWT SP에 속하는 다른 디바이스들의 수는 r-TWT SP의 하나 이상의 속성들을 선택하기 위해 STA에 의해 사용될 수 있다. 예컨대, STA가 r-TWT SP의 유일한 멤버인 경우, STA는 MU-RTS TXS 트리거 프레임들이 필요하지 않다고(또는 선호되지 않는다고) 결정할 수 있고, MU-RTS TXS 트리거 프레임들의 송신들을 포함하지 않는 r-TWT SP를 요청할 수 있다.

[0170] 일부 구현들에서, 트리거 프레임은 MU(multi-user) RTS(Request-to-Send) TXS(TXOP Sharing) 트리거 프레임일 수 있다. MU-RTS TXS 트리거 프레임은 STA와 클라이언트 디바이스 사이의 P2P 통신들과 연관된 TXOP 공유 모드를 표시하는 TXOP 공유 모드 서브필드를 포함할 수 있다. 일부 예시들에서, TXOP 공유 모드 서브필드는 STA가 MU-RTS TXS 트리거 프레임에 대한 응답으로 CTS 프레임을 송신하라는 요청을 표시한다. CTS 프레임은 클라이언트 디바이스의 MAC 어드레스를 포함하는 수신기 어드레스 필드를 포함할 수 있다.

[0171] 일부 다른 구현들에서, STA는 STA와 클라이언트 디바이스 사이의 P2P 통신들을 관리하는 코로케이트된 softAP를 포함할 수 있다. 일부 예시들에서, softAP는 STA와 상이한 MAC 어드레스를 가질 수 있다. 예컨대, STA는, AP 및 클라이언트 디바이스와 독립적으로 통신할 수 있는 별개의 MAC 엔티티들을 포함할 수 있다. 일부 양상들에서, 제1 MAC-AP 엔드포인트는 AP와의 비-AP STA 통신들과 연관될 수 있고, 제2 MAC-SAP 엔드포인트는 클라이언트 디바이스와의 softAP 통신들과 연관될 수 있다. 이들 구현들에서, NAV 예외는 또한, r-TWT SP에 속하는 STA들과 코로케이트된 softAP들이 트리거 프레임들에 의해 표시되는 NAV 지속기간들 및 트리거 프레임들에 후속하는 CTS 프레임들에 의해 표시되는 NAV 지속기간들을 무시해야 함을 표시할 수 있다.

[0172] 도 18은 일부 다른 구현들에 따른, 저-레이턴시 통신들을 지원하는 무선 통신들을 위한 예시적인 프로세스(1800)를 예시하는 흐름도를 도시한다. 프로세스(1800)는 도 5를 참조하여 위에서 설명된 무선 통신 디바이스(500)와 같은 무선 통신 디바이스에 의해 수행될 수 있다. 일부 구현들에서, 프로세스(1800)는, 각각 도 1 및 도 6b를 참조로 위에서 설명된 STA들(104 및 604) 중 하나와 같은 STA 내에 있거나 또는 이러한 STA로서 동작하는 무선 통신 디바이스에 의해 수행될 수 있다.

[0173] 일부 구현들에서, 프로세스(1800)는 도 17의 블록(1710)에서 CTS 프레임을 송신한 이후 수행될 수 있다. 예컨대, 블록(1804)에서, 프로세스(1800)는 무선 매체 상에서, 클라이언트 디바이스로부터 P2P 통신들을 요청하는 제2 트리거 프레임을 송신하는 것으로 시작되고, 제2 트리거 프레임은 클라이언트 디바이스의 MAC 어드레스를 포함한다. 블록(1806)에서, 프로세스(1800)는 제2 트리거 프레임에 대한 응답으로 클라이언트 디바이스로부터 P2P 송신을 수신하는 것으로 계속된다. 일부 예시들에서, STA는, 클라이언트 디바이스에 제2 트리거 프레임을 송신하기 전에 적어도 SIFS(short interframe space) 지속기간 동안 무선 매체가 유휴 상태라고 결정한다. P2P 통신들은 STA와 클라이언트 디바이스 사이에 확립된 TDLS(tunneled direct-link setup) 링크를 통해 수신된다. 일부 양상들에서, 제2 시간 기간은 STA로부터의 CTS 프레임을 요청하는 것과 연관된 시간 기간에 기반할 수 있다.

[0174] 일부 다른 구현들에서, 요청 프레임은 STA가 r-TWT SP 내에서 무선 매체를 사용하고자 의도하는 제1 시간 기간을 표시하고, 제1 트리거 프레임은 TXOP의 일부가 STA에 배정되는 제2 시간 기간을 표시하는 지속기간 필드를 포함하며, 제2 시간 기간은 제1 시간 기간보다 짧다.

[0175] 도 19a는 일부 구현들에 따른, 무선 통신들에 사용가능한 TWT 엘리먼트(1900)의 예시적인 구조를 도시한다. TWT 엘리먼트(1900)는 엘리먼트 ID 필드(1902), 길이 필드(1904), 제어 필드(1906) 및 TWT 파라미터 정보 필드(1908)를 포함할 수 있다. 엘리먼트 ID 필드(1902)는 엘리먼트가 TWT 엘리먼트임을 표시한다. 길이 필드(1904)는 TWT 엘리먼트(1900)의 길이를 표시한다. 제어 필드(1906)는 TWT 엘리먼트(1900)에 의해 통지되는 제한된 TWT 세션에 대한 다양한 제어 정보를 포함한다. TWT 파라미터 정보 필드(1908)는 단일의 개별 TWT 파라미터 세트 필드 또는 하나 이상의 브로드캐스트 TWT 파라미터 세트 필드들을 포함한다.

[0176] 도 19b는 일부 구현들에 따른, 무선 통신들에 사용가능한 브로드캐스트 TWT 파라미터 세트 필드(1910)의 예시적인 구조를 도시한다. 일부 예시들에서, 브로드캐스트 TWT 파라미터 세트 필드(1910)는 도 19a의 TWT 파라미터 정보 필드(1908) 내에 포함될 수 있다. 브로드캐스트 TWT 파라미터 세트 필드(1910)는 요청 타입 필드(1912), 타깃 웨이크 시간 필드(1914), 공칭 최소 TWT 웨이크 지속기간 필드(1916), TWT 웨이크 인터벌 가수 필드(TWT Wake Interval Mantissa field)(1917) 및 브로드캐스트 TWT 정보 필드(1918)를 포함할 수 있다. 요청 타입 필드(1912)는 요청된 TWT 세션의 타입을 표시한다. 타깃 웨이크 시간 필드(1914)는 STA가 웨이크를 요청하는 TSF 시간에 대응하는 무부호 정수(unsigned integer)를 반송한다. 공칭 최소 TWT 웨이크 지속기간 필드(1916)는, TWT 요청 STA 또는 TWT 스케줄링된 STA가 어웨이크 상태 또는 모드를 유지하는 것으로 예상되는 최소 시간량을 표시한다. TWT 웨이크 인터벌 가수 필드(1917)는 주기적 TWT에 대해서는 비-제로 값으로 그리고 비주기적 TWT에 대해서는 제로 값으로 설정될 수 있다. 브로드캐스트 TWT 정보 필드(1918)는 대응하는 제한된 TWT 세션에 대한 브로드캐스트 TWT ID를 포함하고, 브로드캐스트 TWT 파라미터 세트에 대응하는 브로드캐스트 TWT SP들이 존재하는 TBTT들의 수를 표시하는 정보를 반송할 수 있다.

[0177] 도 19c는 일부 구현들에 따른, 무선 통신들에 사용가능한 브로드캐스트 TWT 파라미터 세트 필드의 요청 타입 필드(1920)의 예시적인 구조를 도시한다. 일부 예시들에서, 요청 타입 필드(1920)는 도 19c의 요청 타입 필드(1912)의 일 예일 수 있다. 요청 타입 필드(1920)는 TWT 요청 서브필드(1922), TWT 셋업 커맨드 서브필드(1924), 트리거 서브필드(1926), 마지막 브로드캐스트 파라미터 세트 서브필드(Last Broadcast Parameter Set subfield)(1928), 흐름 타입 서브필드(1930), 브로드캐스트 TWT 추천 서브필드(Broadcast TWT Recommendation subfield)(1932), TWT 웨이크 인터벌 지수 서브필드(TWT Wake Interval Exponent subfield)(1934), 및 다수의 예비 비트들(1936)을 포함할 수 있다. TWT 요청 서브필드(1922)는 대응하는 TWT 정보 엘리먼트가 스케줄링된 STA에 의해 송신되었는지 또는 스케줄링 STA에 의해 송신되었는지 여부를 표시하는 값을 반송할 수 있다. TWT 셋업 커맨드 서브필드(1924)는 TWT 정보 엘리먼트에서 반송되는 TWT 커맨드들의 타입을 표시하는 값들을 반송할 수 있다. 트리거 서브필드(1926)는 TWT 엘리먼트(1900)에 의해 표시된 TWT SP가 트리거 프레임들을 포함하는지 또는 TRS 제어 서브필드를 반송하는 프레임들을 포함하는지 여부를 표시할 수 있다.

[0178] 마지막 브로드캐스트 파라미터 세트 서브필드(1928)는 다른 브로드캐스트 TWT 파라미터 세트가 후속하는지 여부를 표시한다. 예컨대, 마지막 브로드캐스트 파라미터 세트 서브필드(1928)는, 이 세트에 후속하는 다른 TWT 파라미터 세트가 존재함을 표시하기 위해 0의 값으로 설정될 수 있거나, 또는 이것이 브로드캐스트 TWT 엘리먼트 내의 마지막 브로드캐스트 TWT 파라미터 세트임을 표시하기 위해 1의 값으로 설정될 수 있다. 흐름 타입 서브필드(1930)는, TWT에서의 TWT 요청 STA 또는 TWT 스케줄링된 STA와 TWT 응답 STA 또는 TWT 스케줄링 AP 사이의 상호작용의 타입을 표시한다. 예컨대, 흐름 타입 서브필드(1930)를 0의 값으로 설정하는 것은 통지(announced) TWT를 표시하며, 여기서, TWT 요청 STA 또는 TWT 스케줄링된 STA는 자신의 어웨이크 상태를 시그널링하기 위해 PS-Poll 또는 APSD 트리거 프레임을 전송한다. 흐름 타입 서브필드(1930)를 1의 값으로 설정하는 것은 비통지(unannounced) TWT를 표시하며, 여기서, TWT 응답 STA 또는 TWT 스케줄링 AP는 PS-Poll 또는 ASPD 트리거 프레임의 수신을 대기하지 않으면서 TWT에서 TWT 요청 STA 또는 TWT 스케줄링된 STA에 프레임을 전송할 것이다.

[0179] 브로드캐스트 TWT 추천 서브필드(1932)는, 브로드캐스트 TWT 엘리먼트에 대한 브로드캐스트 TWT 추천 서브필드(1932)에 따라 인코딩된, 브로드캐스트 TWT SP 동안 TWT 스케줄링된 STA들 및 스케줄링 AP에 의해 송신되는 프레임들의 타입들에 대한 추천들을 표시하는 값을 포함한다. 일부 예시들에서, 브로드캐스트 TWT 추천 서브필드(1932)는 제한된 TWT 세션이 피어-투-피어 TWT 세션인지 또는 브로드캐스트 TWT 세션인지 여부를 표시할 수 있다. TWT 웨이크 인터벌 지수 서브필드(1934)는 TWT 웨이크 인터벌이 획득될 수 있는 값을 반송한다. 일부 예시들에서, TWT 웨이크 인터벌 지수 서브필드(1934)는, 밑(base)이 2인, 마이크로초 단위의 TWT 웨이크 인터벌 값의 지수의 값으로 설정된다.

[0180] 도 20a는 일부 구현들에 따른 예시적인 트리거 프레임(2000)을 도시한다. 트리거 프레임(2000)은 도 8 내지 도 15를 참조하여 설명된 트리거 프레임들 중 하나 이상으로서 사용될 수 있다. 트리거 프레임(2000)은 프레임 제어 필드(2001), 지속기간 필드(2002), RA(receiver address) 필드(2003), TA(transmitter address) 필드(2004), 공통 정보 필드(2005), 다수의 사용자 정보 필드들(2006(1)-2006(n)), 선택적인 패딩 필드(2007), 및 FCS(frame check sequence) 필드(2008)를 포함하는 것으로 도시된다. 일부 구현들에서, 트리거 프레임(2000)은 UL OFDMA 트리거 프레임일 수 있다. 일부 다른 구현들에서, 트리거 프레임(2000)은 UL MU-MIMO 모드 트리거 프레임일 수 있다. 프레임 제어 필드(2001)는 타입 필드 및 서브-타입 필드(단순화를 위해 도시되지 않음)를 포함한다. 타입 필드(2001A)는 트리거 프레임(2000)이 제어 프레임인 것을 표시하기 위한 값을 저장할 수 있고, 서브-타입 필드(2001B)는 트리거 프레임(2000)의 타입을 표시하는 값을 저장할 수 있다.

[0181] 지속기간 필드(2002)는 트리거 프레임(2000)의 지속기간 또는 길이를 표시하는 정보를 저장할 수 있다. RA 필드(2003)는 도 8 내지 도 15의 STA들 중 하나 이상과 같은 수신 디바이스의 어드레스를 저장할 수 있다. TA 필드(1904)는 도 8 내지 도 15의 AP와 같은 송신 디바이스의 어드레스를 저장할 수 있다. 공통 정보 필드(2005)는 하나 이상의 수신 디바이스들에 공통인 정보를 저장할 수 있다. 사용자 정보 필드들(2006(1) -2006(n)) 각각은, 예컨대, 수신 디바이스의 AID를 포함하는 특정 수신 디바이스에 대한 정보를 저장할 수 있다. 패딩 필드(2007)는, 예컨대, 응답을 생성하기 위한 추가 시간을 수신 디바이스에 제공하기 위해, 트리거 프레임(2000)의 길이를 연장할 수 있다. FCS 필드(2008)는 프레임 체크 시퀀스를 (예컨대, 에러 검출을 위해) 저장할 수 있다.

[0182] 도 20b는 일부 구현들에 따른 예시적인 사용자 정보 필드(2010)를 도시한다. 사용자 정보 필드(2010)는 도 8 내지 도 15를 참조하여 설명된 트리거 프레임들 중 하나 이상에서 사용될 수 있다. 사용자 정보 필드(2010)는 AID12 필드(2011), RU 배정 필드(2012), ULFEC 코딩 타입 필드(2013), UL HE-MCS 필드(2014), UL DCM 필드(2015), SS 배정/RA-RU 정보 필드(2016), UL 타깃 RSSI 필드(2017), 예비 필드(2018), 및 트리거 종속 사용자 정보 필드(2019)를 포함하는 것으로 도시된다.

[0183] 도 21은 예시적인 무선 통신 디바이스(2100)의 블록도를 도시한다. 일부 구현들에서, 무선 통신 디바이스(2100)는 도 16을 참조하여 위에서 설명된 프로세스(1600)를 수행하도록 구성될 수 있다. 무선 통신 디바이스(2100)는 도 1의 AP들(102), 도 5의 무선 통신 디바이스(500) 또는 도 6a의 AP(602) 중 임의의 것의 예시적인 구현일 수 있다. 더 구체적으로, 무선 통신 디바이스(2100)는, 적어도 하나의 프로세서 및 적어도 하나의 모뎀(예컨대, Wi-Fi(IEEE 802.11) 모뎀 또는 셀룰러 모뎀)을 포함하는 칩, SoC, 칩셋, 패키지 또는 디바이스일 수 있다.

[0184] 무선 통신 디바이스(2100)는 수신 컴포넌트(2110), 통신 관리자(2120), 및 송신 컴포넌트(2130)를 포함한다. 통신 관리자(2120)는 채널 감지 컴포넌트(2122) 및 LS(latency-sensitive) 트래픽 보호 컴포넌트(2124)를 더 포함한다. 컴포넌트들(2122 또는 2124) 중 하나 이상의 부분들은 적어도 부분적으로 하드웨어 또는 펌웨어로 구현될 수 있다. 일부 구현들에서, 컴포넌트들(2122 또는 1424) 중 하나 이상은 메모리(이를테면, 도 5의 메모리(508))에 저장된 소프트웨어로서 적어도 부분적으로 구현된다. 예컨대, 컴포넌트들(2122 또는 2124) 중 하나 이상의 컴포넌트들의 부분들은, 개개의 컴포넌트의 기능들 또는 동작들을 수행하기 위해 프로세서(이를테면, 도 5의 프로세서(506))에 의해 실행가능한 비-일시적인 명령들(또는 "코드")로서 구현될 수 있다.

[0185] 수신 컴포넌트(2110)는 하나 이상의 다른 무선 통신 디바이스들로부터 RX 신호들을 수신하도록 구성되고, 송신 컴포넌트(2130)는 하나 이상의 다른 무선 통신 디바이스들에 TX 신호들을 송신하도록 구성된다. 통신 관리자(2120)는 하나 이상의 다른 무선 통신 디바이스들과의 무선 통신들을 관리하도록 구성된다. 일부 구현들에서, 채널 감지 컴포넌트(2122)는 무선 채널이 비지(busy) 상태인지 또는 유휴 상태인지 여부를 표시하는 채널 감지 동작을 수행할 수 있다. LS 트래픽 보호 컴포넌트(2124)는, AP와 연관되고 r-TWT SP의 멤버들인 STA들과 코로케이트된 softAP들뿐만 아니라, 코로케이트된 softAP와 연관된 임의의 클라이언트 디바이스들에 대한 NAV 예외를 표시하는 응답 프레임 또는 트리거 프레임을 송신할 수 있다. 일부 예시들에서, NAV 예외는, NAV 예외를 겪는 무선 통신 디바이스들이 r-TWT SP 동안 송신된 트리거 프레임들의 지속기간 필드들에 표시된 지속기간에 기반하여 그들의 개개의 NAV들을 설정하지 않는다는 것을 표시한다.

[0186] 도 22는 예시적인 무선 통신 디바이스(2200)의 블록도를 도시한다. 일부 구현들에서, 무선 통신 디바이스(2200)는 도 17 및 도 18을 참조하여 설명된 프로세스들(1700 및 1800)을 수행하도록 구성될 수 있다. 무선 통신 디바이스(2200)는 도 1의 STA들(104), 도 5의 무선 통신 디바이스(500) 또는 도 6b의 STA(604) 중 임의의 것의 예시적인 구현일 수 있다. 더 구체적으로, 무선 통신 디바이스(2200)는, 적어도 하나의 프로세서 및 적어도 하나의 모뎀(예컨대, Wi-Fi(IEEE 802.11) 모뎀 또는 셀룰러 모뎀)을 포함하는 칩, SoC, 칩셋, 패키지 또는 디바이스일 수 있다.

[0187] 무선 통신 디바이스(2200)는 수신 컴포넌트(2210), 통신 관리자(2220), 및 송신 컴포넌트(2230)를 포함한다. 통신 관리자(2220)는 LS(latency-sensitive) 트래픽 관리 컴포넌트(2222)를 더 포함한다. LS 트래픽 관리 컴포넌트(2222)의 부분들은 적어도 부분적으로 하드웨어 또는 펌웨어로 구현될 수 있다. 일부 구현들에서, LS 트래픽 관리 컴포넌트(2222)는 메모리(이를테면, 도 5의 메모리(508))에 저장된 소프트웨어로서 적어도 부분적으로 구현된다. 예컨대, LS 트래픽 관리 컴포넌트(2222)의 부분들은, 개개의 컴포넌트의 기능들 또는 동작들을 수행하기 위해 프로세서(이를테면, 도 5의 프로세서(506))에 의해 실행가능한 비-일시적인 명령들(또는 "코드")로서 구현될 수 있다.

[0188] 수신 컴포넌트(2210)는 하나 이상의 다른 무선 통신 디바이스들로부터 RX 신호들을 수신하도록 구성되고, 송신 컴포넌트(2230)는 하나 이상의 다른 무선 통신 디바이스들에 TX 신호들을 송신하도록 구성된다. 통신 관리자(2220)는 하나 이상의 다른 무선 통신 디바이스들과의 무선 통신들을 관리하도록 구성된다. 일부 구현들에서, 채널 감지 컴포넌트(2222)는, AP와 연관되고 r-TWT SP의 멤버들인 STA들과 코로케이트된 softAP들뿐만 아니라, 코로케이트된 softAP와 연관된 임의의 클라이언트 디바이스들에 대한 NAV 예외를 표시하는 응답 프레임 또는 트리거 프레임을 수신할 수 있다. 일부 예시들에서, NAV 예외는, NAV 예외를 겪는 무선 통신 디바이스들이 r-TWT SP 동안 송신된 트리거 프레임들의 지속기간 필드들에 표시된 지속기간에 기반하여 그들의 개개의 NAV들을 설정하지 않는다는 것을 표시한다.

[0189] 구현 예들은 다음의 번호가 매겨진 조항들에서 설명된다:

1. AP(access point)에 의한 무선 통신을 위한 방법으로서,

AP와 연관되고 그리고 P2P(peer-to-peer) 링크를 통해 클라이언트 디바이스와 또한 연관된 무선 STA(station)로부터 요청 프레임을 수신하는 단계 ― 요청 프레임은, 무선 매체에 스케줄링된 r-TWT(restricted target wake time) SP(service period) 동안 STA가 클라이언트 디바이스와 P2P 통신들을 교환하고자 의도함을 표시하고, 요청 프레임은 클라이언트 디바이스를 식별함 ―;

요청 프레임을 수신하는 것에 대한 응답으로, 무선 매체 상에서 STA에 응답 프레임을 송신하는 단계;

r-TWT SP 동안 무선 매체 상에서 TXOP(transmission opportunity)를 획득하는 단계; 및

TXOP를 획득하는 것에 대한 응답으로, 무선 매체 상에서 트리거 프레임을 송신하는 단계를 포함하고, 트리거 프레임은 STA와 클라이언트 디바이스 사이의 P2P 통신들을 위해, 획득된 TXOP의 일부를 배정(allocate)하고, 응답 프레임 또는 트리거 프레임 중 적어도 하나는 클라이언트 디바이스에 대한 NAV(Network Allocation Vector) 예외(exception)를 표시하는, AP에 의한 무선 통신을 위한 방법.

2. 조항 1의 방법에 있어서, 응답 프레임 및 트리거 프레임 각각은 클라이언트 디바이스의 MAC(medium access control) 어드레스를 포함하는, AP에 의한 무선 통신을 위한 방법.

3. 조항 1의 방법에 있어서, NAV 예외는, 클라이언트 디바이스가 트리거 프레임에 의해 표시되는 NAV 지속기간 및 트리거 프레임에 대한 응답으로 CTS(clear-to-send) 프레임에 의해 표시되는 NAV 지속기간을 무시해야 함을 표시하는, AP에 의한 무선 통신을 위한 방법.

4. 조항 1의 방법에 있어서, STA는 클라이언트 디바이스와 통신하도록 구성된 코로케이트(collocate)된 softAP를 포함하고, 응답 프레임 또는 트리거 프레임 중 적어도 하나는 softAP에 대한 NAV 예외를 추가로 표시하는, AP에 의한 무선 통신을 위한 방법.

5. 조항 4의 방법에 있어서, NAV 예외는, r-TWT SP에 속하는 STA들과 코로케이트된 softAP들이 트리거 프레임에 의해 표시되는 NAV 지속기간 및 트리거 프레임에 대한 응답으로 CTS(clear-to-send) 프레임에 의해 표시되는 NAV 지속기간을 무시해야 함을 표시하는, AP에 의한 무선 통신을 위한 방법.

6. 조항 1의 방법에 있어서, 트리거 프레임은 0의 값으로 설정된 비트를 반송하는 CS(Carrier Sense) 필수 필드(Required field)를 포함하고, 0의 값으로 설정된 비트는 NAV 예외를 표시하는, AP에 의한 무선 통신을 위한 방법.

7. 조항 1의 방법에 있어서, 요청 프레임은 클라이언트 디바이스의 MAC(medium access control) 어드레스를 표시하고, 응답 프레임은 클라이언트 디바이스가 AP로부터 송신된 트리거 프레임들에 의해 설정되는 NAV 지속기간들 및 트리거 프레임들에 대한 응답으로 CTS(clear-to-send) 프레임들에 의해 설정되는 NAV 지속기간들을 무시해야 함을 표시하는, AP에 의한 무선 통신을 위한 방법.

8. 조항 7의 방법에 있어서, 요청 프레임은 클라이언트 디바이스의 MAC 어드레스를 표시하는 TWT 엘리먼트를 포함하는 TWT 요청 프레임이고, TWT 엘리먼트는 r-TWT SP의 주기성(periodicity), r-TWT SP의 지속기간, r-TWT SP의 공유 모드, r-TWT SP의 웨이크 지속기간(wake duration), r-TWT SP의 흐름 타입, 또는 r-TWT SP의 파라미터 세트 중 하나 이상을 추가로 표시하는, AP에 의한 무선 통신을 위한 방법.

9. 조항 7의 방법에 있어서, 요청 프레임은 클라이언트 디바이스의 MAC 어드레스를 표시하는 TSPEC(traffic specification) 엘리먼트를 포함하는 SCS(Stream Classification Service) 요청 프레임이고, TSPEC 엘리먼트는 제한된 TWT 세션에 대한 최소 데이터 레이트, 제한된 TWT 세션에 대한 평균 데이터 레이트, r-TWT SP에 대한 지연 한계(delay bound), 및 r-TWT SP에 대한 UP(user priority)를 추가로 표시하는, AP에 의한 무선 통신을 위한 방법.

10. 조항 7의 방법에 있어서, 요청 프레임은, 적어도 클라이언트 디바이스의 MAC 어드레스를 표시하는 TWT 엘리먼트, TSPEC 엘리먼트, 또는 VSIE(vendor-specific information element) 중 하나 이상을 포함하는 P2P 요청 프레임인, AP에 의한 무선 통신을 위한 방법.

11. 조항 1의 방법에 있어서, 응답 프레임은 얼마나 많은 디바이스들이 r-TWT SP의 멤버들인지를 표시하는, AP에 의한 무선 통신을 위한 방법.

12. 조항 1의 방법에 있어서, 트리거 프레임은 MU(multi-user) RTS(Request-to-Send) TXS(TXOP Sharing) 트리거 프레임을 포함하는, AP에 의한 무선 통신을 위한 방법.

13. 조항 12의 방법에 있어서, MU-RTS TXS 트리거 프레임은 클라이언트 디바이스와 연관된 P2P 통신들에 대응하는 TXOP 공유 모드를 표시하는 TXOP 공유 모드 서브필드를 포함하는, AP에 의한 무선 통신을 위한 방법.

14. 조항 13의 방법에 있어서, TXOP 공유 모드 서브필드는, STA가 MU-RTS TXS 트리거 프레임에 대한 응답으로, 클라이언트 디바이스의 MAC 어드레스를 포함하는 수신기 어드레스 필드를 포함하는 CTS(clear-to-send) 프레임을 송신하라는 요청을 표시하는, AP에 의한 무선 통신을 위한 방법.

15. 조항 1의 방법에 있어서, 요청 프레임은 STA가 r-TWT SP 내에서 무선 매체를 사용하고자 의도하는 제1 시간 기간을 표시하고, 트리거 프레임은 TXOP의 일부가 클라이언트 디바이스와 연관된 P2P 통신들을 위해 배정되는 제2 시간 기간을 표시하는 지속기간 필드를 포함하며, 제2 시간 기간은 제1 시간 기간보다 짧은, AP에 의한 무선 통신을 위한 방법.

16. 조항 15의 방법에 있어서, 제2 시간 기간은 STA로부터의 CTS 프레임을 요청하는 것과 연관된 시간 기간에 기반하는, AP에 의한 무선 통신을 위한 방법.

17. 무선 통신 디바이스로서,

적어도 하나의 모뎀;

적어도 하나의 모뎀과 통신가능하게 커플링된 적어도 하나의 프로세서; 및

적어도 하나의 프로세서와 통신가능하게 커플링되고 프로세서-판독가능 코드를 저장하는 적어도 하나의 메모리를 포함하고, 프로세서-판독가능 코드는, 적어도 하나의 모뎀과 함께 적어도 하나의 프로세서에 의해 실행될 때:

AP와 연관되고 그리고 P2P(peer-to-peer) 링크를 통해 클라이언트 디바이스와 또한 연관된 무선 STA(station)로부터 요청 프레임을 수신하도록 ― 요청 프레임은, 무선 매체에 스케줄링된 r-TWT(restricted target wake time) SP(service period) 동안 STA가 클라이언트 디바이스와 P2P 통신들을 교환하고자 의도함을 표시하고, 요청 프레임은 클라이언트 디바이스를 식별함 ―;

요청 프레임을 수신하는 것에 대한 응답으로, 무선 매체 상에서 STA에 응답 프레임을 송신하도록;

r-TWT SP 동안 무선 매체 상에서 TXOP(transmission opportunity)를 획득하도록; 그리고

TXOP를 획득하는 것에 대한 응답으로, 무선 매체 상에서 트리거 프레임을 송신하도록 구성되고, 트리거 프레임은 STA와 클라이언트 디바이스 사이의 P2P 통신들을 위해, 획득된 TXOP의 일부를 배정하고, 응답 프레임 또는 트리거 프레임 중 적어도 하나는 클라이언트 디바이스에 대한 NAV(Network Allocation Vector) 예외를 표시하는, 무선 통신 디바이스.

18. 조항 17의 무선 통신 디바이스에 있어서, 응답 프레임 및 트리거 프레임 각각은 클라이언트 디바이스의 MAC(medium access control) 어드레스를 포함하는, 무선 통신 디바이스.

19. 조항 17의 무선 통신 디바이스에 있어서, NAV 예외는, 클라이언트 디바이스가 트리거 프레임에 의해 표시되는 NAV 지속기간 및 트리거 프레임에 대한 응답으로 CTS(clear-to-send) 프레임에 의해 표시되는 NAV 지속기간을 무시해야 함을 표시하는, 무선 통신 디바이스.

20. 조항 17의 무선 통신 디바이스에 있어서, STA는 클라이언트 디바이스와 통신하도록 구성된 코로케이트된 softAP를 포함하고, 응답 프레임 또는 트리거 프레임 중 적어도 하나는 softAP에 대한 NAV 예외를 추가로 표시하는, 무선 통신 디바이스.

21. 조항 20의 무선 통신 디바이스에 있어서, NAV 예외는, r-TWT SP에 속하는 STA들과 코로케이트된 softAP들이 트리거 프레임에 의해 표시되는 NAV 지속기간 및 트리거 프레임에 대한 응답으로 CTS(clear-to-send) 프레임에 의해 표시되는 NAV 지속기간을 무시해야 함을 표시하는, 무선 통신 디바이스.

22. 조항 17의 무선 통신 디바이스에 있어서, 트리거 프레임은 0의 값으로 설정된 비트를 반송하는 CS(Carrier Sense) 필수 필드를 포함하고, 0의 값으로 설정된 비트는 NAV 예외를 표시하는, 무선 통신 디바이스.

23. 조항 17의 무선 통신 디바이스에 있어서, 요청 프레임은 클라이언트 디바이스의 MAC(medium access control) 어드레스를 표시하고, 응답 프레임은 클라이언트 디바이스가 AP로부터 송신된 트리거 프레임들에 의해 설정되는 NAV 지속기간들 및 트리거 프레임들에 대한 응답으로 CTS(clear-to-send) 프레임들에 의해 설정되는 NAV 지속기간들을 무시해야 함을 표시하는, 무선 통신 디바이스.

24. 조항 23의 무선 통신 디바이스에 있어서, 요청 프레임은 클라이언트 디바이스의 MAC 어드레스를 표시하는 TWT 엘리먼트를 포함하는 TWT 요청 프레임이고, TWT 엘리먼트는 r-TWT SP의 주기성, r-TWT SP의 지속기간, r-TWT SP의 공유 모드, r-TWT SP의 웨이크 지속기간, r-TWT SP의 흐름 타입, 또는 r-TWT SP의 파라미터 세트 중 하나 이상을 추가로 표시하는, 무선 통신 디바이스.

25. 조항 23의 무선 통신 디바이스에 있어서, 요청 프레임은 클라이언트 디바이스의 MAC 어드레스를 표시하는 TSPEC(traffic specification) 엘리먼트를 포함하는 SCS(Stream Classification Service) 요청 프레임이고, TSPEC 엘리먼트는 제한된 TWT 세션에 대한 최소 데이터 레이트, 제한된 TWT 세션에 대한 평균 데이터 레이트, r-TWT SP에 대한 지연 한계, 및 r-TWT SP에 대한 UP(user priority)를 추가로 표시하는, 무선 통신 디바이스.

26. 조항 23의 무선 통신 디바이스에 있어서, 요청 프레임은, 적어도 클라이언트 디바이스의 MAC 어드레스를 표시하는 TWT 엘리먼트, TSPEC 엘리먼트, 또는 VSIE(vendor-specific information element) 중 하나 이상을 포함하는 P2P 요청 프레임인, 무선 통신 디바이스.

27. 조항 17의 무선 통신 디바이스에 있어서, 응답 프레임은 얼마나 많은 디바이스들이 r-TWT SP의 멤버들인지를 표시하는, 무선 통신 디바이스.

28. 조항 17의 무선 통신 디바이스에 있어서, 트리거 프레임은, 클라이언트 디바이스와 연관된 P2P 통신들에 대응하는 TXOP 공유 모드를 표시하는 TXOP 공유 모드 서브필드를 포함하는 MU(multi-user) RTS(Request-to-Send) TXS(TXOP Sharing) 트리거 프레임을 포함하는, 무선 통신 디바이스.

29. 조항 28의 무선 통신 디바이스에 있어서, TXOP 공유 모드 서브필드는, STA가 MU-RTS TXS 트리거 프레임에 대한 응답으로, 클라이언트 디바이스의 MAC 어드레스를 포함하는 수신기 어드레스 필드를 포함하는 CTS(clear-to-send) 프레임을 송신하라는 요청을 표시하는, 무선 통신 디바이스.

30. 조항 17의 무선 통신 디바이스에 있어서, 요청 프레임은 STA가 r-TWT SP 내에서 무선 매체를 사용하고자 의도하는 제1 시간 기간을 표시하고, 트리거 프레임은 TXOP의 일부가 클라이언트 디바이스와 연관된 P2P 통신들을 위해 배정되는 제2 시간 기간을 표시하는 지속기간 필드를 포함하며, 제2 시간 기간은 제1 시간 기간보다 짧은, 무선 통신 디바이스.

31. 무선 통신 디바이스에 의한 무선 통신을 위한 방법으로서,

무선 통신 디바이스를 AP(access point)와 연관된 무선 STA(station)로서 동작시키는 단계 ― STA는 P2P(peer-to-peer) 링크를 통해 클라이언트 디바이스와 또한 연관됨 ―;

AP에 요청 프레임을 송신하는 단계 ― 요청 프레임은, 무선 매체에 스케줄링된 r-TWT(restricted target wake time) SP(service period) 동안 STA가 클라이언트 디바이스와 P2P 통신들을 교환하고자 의도함을 표시하고, 요청 프레임은 클라이언트 디바이스를 식별함 ―;

무선 매체 상에서 AP로부터 응답 프레임을 수신하는 단계;

무선 매체 상에서 AP로부터 제1 트리거 프레임을 수신하는 단계 ― 제1 트리거 프레임은 STA와 클라이언트 디바이스 사이의 P2P 통신들을 위해, AP에 의해 획득된 TXOP(transmission opportunity)의 일부를 배정하고, 응답 프레임 또는 제1 트리거 프레임 중 적어도 하나는 클라이언트 디바이스에 대한 NAV(Network Allocation Vector) 예외를 표시함 ―; 및

무선 매체 상에서 AP에 CTS(clear-to-send) 프레임을 송신하는 단계를 포함하고, CTS 프레임은 클라이언트 디바이스의 MAC(medium access control) 어드레스를 포함하는 수신기 어드레스 필드를 포함하는, 무선 통신 디바이스에 의한 무선 통신을 위한 방법.

32. 조항 31의 방법에 있어서, 응답 프레임 및 제1 트리거 프레임 각각은 클라이언트 디바이스의 MAC 어드레스를 포함하는, 무선 통신 디바이스에 의한 무선 통신을 위한 방법.

33. 조항 31의 방법에 있어서, NAV 예외는, 클라이언트 디바이스가 제1 트리거 프레임에 의해 표시되는 NAV 지속기간 및 CTS 프레임에 의해 표시되는 NAV 지속기간을 무시해야 함을 표시하는, 무선 통신 디바이스에 의한 무선 통신을 위한 방법.

34. 조항 31의 방법에 있어서, 무선 통신 디바이스는 STA와 코로케이트된 softAP를 포함하고, 코로케이트된 softAP는 클라이언트 디바이스와 통신하도록 구성되고, 응답 프레임 또는 트리거 프레임 중 적어도 하나는 softAP에 대한 NAV 예외를 추가로 표시하는, 무선 통신 디바이스에 의한 무선 통신을 위한 방법.

35. 조항 34의 방법에 있어서, NAV 예외는, r-TWT SP에 속하는 STA들과 코로케이트된 softAP들이 제1 트리거 프레임에 의해 표시되는 NAV 지속기간 및 CTS 프레임에 의해 표시되는 NAV 지속기간을 무시해야 함을 표시하는, 무선 통신 디바이스에 의한 무선 통신을 위한 방법.

36. 조항 31의 방법에 있어서, 제1 트리거 프레임은 0의 값으로 설정된 비트를 반송하는 CS(Carrier Sense) 필수 필드를 포함하고, 0의 값으로 설정된 비트는 NAV 예외를 표시하는, 무선 통신 디바이스에 의한 무선 통신을 위한 방법.

37. 조항 31의 방법에 있어서, 요청 프레임은 클라이언트 디바이스의 MAC(medium access control) 어드레스를 표시하고, 응답 프레임은 클라이언트 디바이스가 제1 트리거 프레임 및 CTS 프레임에 의해 설정된 NAV 지속기간들을 무시해야 함을 표시하는, 무선 통신 디바이스에 의한 무선 통신을 위한 방법.

38. 조항 37의 방법에 있어서, 요청 프레임은 클라이언트 디바이스의 MAC 어드레스를 표시하는 TWT 엘리먼트를 포함하는 TWT 요청 프레임이고, TWT 엘리먼트는 r-TWT SP의 주기성, r-TWT SP의 지속기간, r-TWT SP의 공유 모드, r-TWT SP의 웨이크 지속기간, r-TWT SP의 흐름 타입, 또는 r-TWT SP의 파라미터 세트 중 하나 이상을 추가로 표시하는, 무선 통신 디바이스에 의한 무선 통신을 위한 방법.

39. 조항 37의 방법에 있어서, 요청 프레임은 클라이언트 디바이스의 MAC 어드레스를 표시하는 TSPEC(traffic specification) 엘리먼트를 포함하는 SCS(Stream Classification Service) 요청 프레임이고, TSPEC 엘리먼트는 제한된 TWT 세션에 대한 최소 데이터 레이트, 제한된 TWT 세션에 대한 평균 데이터 레이트, r-TWT SP에 대한 지연 한계, 및 r-TWT SP에 대한 UP(user priority)를 추가로 표시하는, 무선 통신 디바이스에 의한 무선 통신을 위한 방법.

40. 조항 37의 방법에 있어서, 요청 프레임은, 적어도 클라이언트 디바이스의 MAC 어드레스를 표시하는 TWT 엘리먼트, TSPEC 엘리먼트, 또는 VSIE(vendor-specific information element) 중 하나 이상을 포함하는 P2P 요청 프레임인, 무선 통신 디바이스에 의한 무선 통신을 위한 방법.

41. 조항 31의 방법에 있어서, 요청 프레임은, STA와 클라이언트 디바이스 사이의 P2P 통신들을 요청할 때 AP가 MU(multi-user) RTS(Request-to-Send) TXS(TXOP Sharing) 트리거 프레임들 또는 기본 트리거 프레임들을 송신하라는 요청을 포함하는, 무선 통신 디바이스에 의한 무선 통신을 위한 방법.

42. 조항 31의 방법에 있어서, 트리거 프레임은, STA와 클라이언트 디바이스 사이의 P2P 통신들과 연관된 TXOP 공유 모드를 표시하는 TXOP 공유 모드 서브필드를 포함하는 MU(multi-user) RTS(Request-to-Send) TXS(TXOP Sharing) 트리거 프레임을 포함하는, 무선 통신 디바이스에 의한 무선 통신을 위한 방법.

43. 조항 31의 방법에 있어서,

무선 매체 상에서, 클라이언트 디바이스로부터 P2P 통신들을 요청하는 제2 트리거 프레임을 송신하는 단계 ― 제2 트리거 프레임은 클라이언트 디바이스의 MAC 어드레스를 포함함 ―; 및

제2 트리거 프레임에 대한 응답으로 클라이언트 디바이스로부터 P2P 송신을 수신하는 단계를 더 포함하는, 무선 통신 디바이스에 의한 무선 통신을 위한 방법.

44. 조항 43의 방법에 있어서, STA는, 클라이언트 디바이스에 제2 트리거 프레임을 송신하기 전에 적어도 SIFS(short interframe space) 지속기간 동안 무선 매체가 유휴 상태(idle)라고 결정하는, 무선 통신 디바이스에 의한 무선 통신을 위한 방법.

45. 조항 44의 방법에 있어서, P2P 통신들은 STA와 클라이언트 디바이스 사이에 확립된 TDLS(tunneled direct-link setup) 링크를 통해 수신되는, 무선 통신 디바이스에 의한 무선 통신을 위한 방법.

46. 조항 31의 방법에 있어서, 요청 프레임은 STA가 r-TWT SP 내에서 무선 매체를 사용하고자 의도하는 제1 시간 기간을 표시하고, 제1 트리거 프레임은 TXOP의 일부가 클라이언트 디바이스와 연관된 P2P 통신들을 위해 배정되는 제2 시간 기간을 표시하는 지속기간 필드를 포함하며, 제2 시간 기간은 제1 시간 기간보다 짧은, 무선 통신 디바이스에 의한 무선 통신을 위한 방법.

47. 조항 46의 방법에 있어서, 제2 시간 기간은 STA로부터의 CTS 프레임을 요청하는 것과 연관된 시간 기간에 기반하는, 무선 통신 디바이스에 의한 무선 통신을 위한 방법.

48. 무선 통신 디바이스로서,

적어도 하나의 모뎀;

적어도 하나의 모뎀과 통신가능하게 커플링된 적어도 하나의 프로세서; 및

적어도 하나의 프로세서와 통신가능하게 커플링되고 프로세서-판독가능 코드를 저장하는 적어도 하나의 메모리를 포함하고, 프로세서-판독가능 코드는, 적어도 하나의 모뎀과 함께 적어도 하나의 프로세서에 의해 실행될 때:

무선 통신 디바이스를 AP(access point)와 연관된 무선 STA(station)로서 동작시키도록 ― STA는 P2P(peer-to-peer) 링크를 통해 클라이언트 디바이스와 또한 연관됨 ―;

AP에 요청 프레임을 송신하도록 ― 요청 프레임은, 무선 매체에 스케줄링된 r-TWT(restricted target wake time) SP(service period) 동안 STA가 클라이언트 디바이스와 P2P 통신들을 교환하고자 의도함을 표시하고, 요청 프레임은 클라이언트 디바이스를 식별함 ―;

무선 매체 상에서 AP로부터 응답 프레임을 수신하도록;

무선 매체 상에서 AP로부터 제1 트리거 프레임을 수신하도록 ― 제1 트리거 프레임은 STA와 클라이언트 디바이스 사이의 P2P 통신들을 위해, AP에 의해 획득된 TXOP(transmission opportunity)의 일부를 배정하고, 응답 프레임 또는 제1 트리거 프레임 중 적어도 하나는 클라이언트 디바이스에 대한 NAV(Network Allocation Vector) 예외를 표시함 ―; 그리고

무선 매체 상에서 AP에 CTS(clear-to-send) 프레임을 송신하도록 구성되고, CTS 프레임은 클라이언트 디바이스의 MAC(medium access control) 어드레스를 포함하는 수신기 어드레스 필드를 포함하는, 무선 통신 디바이스.

49. 조항 48의 무선 통신 디바이스에 있어서, 응답 프레임 및 제1 트리거 프레임 각각은 클라이언트 디바이스의 MAC 어드레스를 포함하는, 무선 통신 디바이스.

50. 조항 48의 무선 통신 디바이스에 있어서, NAV 예외는, 클라이언트 디바이스가 제1 트리거 프레임에 의해 표시되는 NAV 지속기간 또는 CTS 프레임에 의해 표시되는 NAV 지속기간을 무시해야 함을 표시하는, 무선 통신 디바이스.

51. 조항 48의 무선 통신 디바이스에 있어서, 무선 통신 디바이스는 STA와 코로케이트된 softAP를 포함하고, 코로케이트된 softAP는 클라이언트 디바이스와 통신하도록 구성되고, 응답 프레임 또는 트리거 프레임 중 적어도 하나는 softAP에 대한 NAV 예외를 추가로 표시하는, 무선 통신 디바이스.

52. 조항 51의 무선 통신 디바이스에 있어서, NAV 예외는, r-TWT SP에 속하는 STA들과 코로케이트된 softAP들이 제1 트리거 프레임에 의해 표시되는 NAV 지속기간 및 CTS 프레임에 의해 표시되는 NAV 지속기간을 무시해야 함을 표시하는, 무선 통신 디바이스.

53. 조항 48의 무선 통신 디바이스에 있어서, 제1 트리거 프레임은 0의 값으로 설정된 비트를 반송하는 CS(Carrier Sense) 필수 필드를 포함하고, 0의 값으로 설정된 비트는 NAV 예외를 표시하는, 무선 통신 디바이스.

54. 조항 48의 무선 통신 디바이스에 있어서, 요청 프레임은 클라이언트 디바이스의 MAC(medium access control) 어드레스를 표시하고, 응답 프레임은 클라이언트 디바이스가 제1 트리거 프레임 및 CTS 프레임에 의해 설정된 NAV 지속기간들을 무시해야 함을 표시하는, 무선 통신 디바이스.

55. 조항 48의 무선 통신 디바이스에 있어서, 요청 프레임은 클라이언트 디바이스의 MAC 어드레스를 표시하는 TWT 엘리먼트를 포함하는 TWT 요청 프레임이고, TWT 엘리먼트는 r-TWT SP의 주기성, r-TWT SP의 지속기간, r-TWT SP의 공유 모드, r-TWT SP의 웨이크 지속기간, r-TWT SP의 흐름 타입, 또는 r-TWT SP의 파라미터 세트 중 하나 이상을 추가로 표시하는, 무선 통신 디바이스.

56. 조항 55의 무선 통신 디바이스에 있어서, 요청 프레임은 클라이언트 디바이스의 MAC 어드레스를 표시하는 TSPEC(traffic specification) 엘리먼트를 포함하는 SCS(Stream Classification Service) 요청 프레임이고, TSPEC 엘리먼트는 제한된 TWT 세션에 대한 최소 데이터 레이트, 제한된 TWT 세션에 대한 평균 데이터 레이트, r-TWT SP에 대한 지연 한계, 및 r-TWT SP에 대한 UP(user priority)를 추가로 표시하는, 무선 통신 디바이스.

57. 조항 55의 무선 통신 디바이스에 있어서, 요청 프레임은, 적어도 클라이언트 디바이스의 MAC 어드레스를 표시하는 TWT 엘리먼트, TSPEC 엘리먼트, 또는 VSIE(vendor-specific information element) 중 하나 이상을 포함하는 P2P 요청 프레임인, 무선 통신 디바이스.

58. 조항 48의 무선 통신 디바이스에 있어서, 요청 프레임은, STA와 클라이언트 디바이스 사이의 P2P 통신들을 요청할 때 AP가 MU(multi-user) RTS(Request-to-Send) TXS(TXOP Sharing) 트리거 프레임들 또는 기본 트리거 프레임들을 송신하라는 요청을 포함하는, 무선 통신 디바이스.

59. 조항 48의 무선 통신 디바이스에 있어서, 트리거 프레임은, 클라이언트 디바이스와 연관된 P2P 통신들에 대응하는 TXOP 공유 모드를 표시하는 TXOP 공유 모드 서브필드를 포함하는 MU(multi-user) RTS(Request-to-Send) TXS(TXOP Sharing) 트리거 프레임을 포함하는, 무선 통신 디바이스.

60. 조항 48의 무선 통신 디바이스에 있어서, 프로세서-판독가능 코드의 실행은:

무선 매체 상에서, 클라이언트 디바이스로부터 P2P 통신들을 요청하는 제2 트리거 프레임을 송신하도록 ― 제2 트리거 프레임은 클라이언트 디바이스의 MAC 어드레스를 포함함 ―; 그리고

제2 트리거 프레임에 대한 응답으로 클라이언트 디바이스로부터 P2P 송신을 수신하도록 추가로 구성되는, 무선 통신 디바이스.

61. 조항 60의 무선 통신 디바이스에 있어서, STA는, 클라이언트 디바이스에 제2 트리거 프레임을 송신하기 전에 적어도 SIFS(short interframe space) 지속기간 동안 무선 매체가 유휴 상태(idle)라고 결정하는, 무선 통신 디바이스.

62. 조항 60의 무선 통신 디바이스에 있어서, P2P 통신들은 STA와 클라이언트 디바이스 사이에 확립된 TDLS(tunneled direct-link setup) 링크를 통해 수신되는, 무선 통신 디바이스.

63. 조항 48의 무선 통신 디바이스에 있어서, 요청 프레임은 STA가 r-TWT SP 내에서 무선 매체를 사용하고자 의도하는 제1 시간 기간을 표시하고, 제1 트리거 프레임은 TXOP의 일부가 클라이언트 디바이스와 연관된 P2P 통신들을 위해 배정되는 제2 시간 기간을 표시하는 지속기간 필드를 포함하며, 제2 시간 기간은 제1 시간 기간보다 짧은, 무선 통신 디바이스.

64. 조항 63의 무선 통신 디바이스에 있어서, 제2 시간 기간은 STA로부터의 CTS 프레임을 요청하는 것과 연관된 시간 기간에 기반하는, 무선 통신 디바이스.

65. AP(access point)에 의한 무선 통신을 위한 방법으로서,

AP와 연관되고 그리고 클라이언트 디바이스와 또한 연관된 무선 STA(station)로부터 요청 프레임을 수신하는 단계 ― 요청 프레임은, STA가 무선 매체 상에서 클라이언트 디바이스와 P2P(peer-to-peer) 통신들을 교환하고자 의도함을 표시하고, 요청 프레임은 클라이언트 디바이스를 식별함 ―;

무선 매체 상에서 TXOP(transmission opportunity)를 획득하는 단계; 및

TXOP를 획득하는 것에 대한 응답으로, 무선 매체 상에서 트리거 프레임을 송신하는 단계를 포함하고, 트리거 프레임은 STA와 클라이언트 디바이스 사이의 P2P 통신들을 위해, 획득된 TXOP의 일부를 배정하고, 트리거 프레임 또는 응답 프레임 중 적어도 하나는 클라이언트 디바이스에 대한 NAV(Network Allocation Vector) 예외를 표시하는, AP에 의한 무선 통신을 위한 방법.

66. 조항 65의 방법에 있어서, 트리거 프레임은 클라이언트 디바이스의 MAC(medium access control) 어드레스를 포함하는, AP에 의한 무선 통신을 위한 방법.

67. 조항 65의 방법에 있어서, NAV 예외는, 클라이언트 디바이스가 트리거 프레임에 의해 표시되는 NAV 지속기간 및 트리거 프레임에 대한 응답으로 CTS(clear-to-send) 프레임에 의해 표시되는 NAV 지속기간을 무시해야 함을 표시하는, AP에 의한 무선 통신을 위한 방법.

68. 조항 65의 방법에 있어서, STA는 클라이언트 디바이스와 통신하도록 구성된 softAP와 코로케이트되고, 트리거 프레임은 softAP에 대한 NAV 예외를 추가로 표시하는, AP에 의한 무선 통신을 위한 방법.

69. 조항 68의 방법에 있어서, NAV 예외는, AP와 연관된 STA들과 코로케이트된 softAP들이 트리거 프레임에 의해 표시되는 NAV 지속기간 및 트리거 프레임에 대한 응답으로 CTS(clear-to-send) 프레임에 의해 표시되는 NAV 지속기간을 무시해야 함을 표시하는, AP에 의한 무선 통신을 위한 방법.

70. 조항 65의 방법에 있어서, 트리거 프레임은 0의 값으로 설정된 비트를 반송하는 CS(Carrier Sense) 필수 필드를 포함하고, 0의 값으로 설정된 비트는 NAV 예외를 표시하는, AP에 의한 무선 통신을 위한 방법.

71. 조항 65의 방법에 있어서,

요청 프레임을 수신하는 것에 대한 응답으로, 무선 매체 상에서 STA에 응답 프레임을 송신하는 단계를 더 포함하고, 응답 프레임은 클라이언트 디바이스에 대한 NAV 예외를 표시하는, AP에 의한 무선 통신을 위한 방법.

72. 조항 71의 방법에 있어서, 요청 프레임은 클라이언트 디바이스의 MAC(medium access control) 어드레스를 표시하고, 응답 프레임은 클라이언트 디바이스가 AP로부터 송신된 트리거 프레임들에 의해 설정되는 NAV 지속기간들 및 트리거 프레임들에 대한 응답으로 CTS(clear-to-send) 프레임들에 의해 설정되는 NAV 지속기간들을 무시해야 함을 표시하는, AP에 의한 무선 통신을 위한 방법.

73. 조항 72의 방법에 있어서, 요청 프레임은 클라이언트 디바이스의 MAC 어드레스를 표시하는 TSPEC(traffic specification) 엘리먼트를 포함하는 SCS(Stream Classification Service) 요청 프레임이고, TSPEC 엘리먼트는 TS(traffic stream), TS와 연관된 PDU(protocol data unit)들에 대한 최소 데이터 레이트, TS와 연관된 PDU들에 대한 평균 데이터 레이트, TS에 대한 지연 한계, 및 TS에 대한 UP(user priority)를 추가로 표시하는, AP에 의한 무선 통신을 위한 방법.

74. 조항 72의 방법에 있어서, 요청 프레임은, 적어도 클라이언트 디바이스의 MAC 어드레스를 표시하는 TWT 엘리먼트, TSPEC 엘리먼트, 또는 VSIE(vendor-specific information element) 중 하나 이상을 포함하는 P2P 요청 프레임인, AP에 의한 무선 통신을 위한 방법.

75. 조항 65의 방법에 있어서, 트리거 프레임은 MU(multi-user) RTS(Request-to-Send) TXS(TXOP Sharing) 트리거 프레임을 포함하는, AP에 의한 무선 통신을 위한 방법.

76. 조항 75의 방법에 있어서, MU-RTS TXS 트리거 프레임은 클라이언트 디바이스와 연관된 P2P 통신들에 대응하는 TXOP 공유 모드를 표시하는 TXOP 공유 모드 서브필드를 포함하는, AP에 의한 무선 통신을 위한 방법.

77. 조항 76의 방법에 있어서, TXOP 공유 모드 서브필드는, STA가 MU-RTS TXS 트리거 프레임에 대한 응답으로, 클라이언트 디바이스의 MAC 어드레스를 포함하는 수신기 어드레스 필드를 포함하는 CTS(clear-to-send) 프레임을 송신하라는 요청을 표시하는, AP에 의한 무선 통신을 위한 방법.

78. 무선 통신 디바이스로서,

적어도 하나의 모뎀;

적어도 하나의 모뎀과 통신가능하게 커플링된 적어도 하나의 프로세서; 및

적어도 하나의 프로세서와 통신 가능하게 커플링되며 그리고 프로세서-판독가능 코드를 저장하는 적어도 하나의 메모리를 포함하고, 프로세서-판독가능 코드는, 적어도 하나의 모뎀과 함께 적어도 하나의 프로세서에 의해 실행될 때, 조항 65 내지 조항 77 중 임의의 하나 이상의 조항들의 동작들을 수행하도록 구성되는, 무선 통신 디바이스.

79. 무선 통신 디바이스에 의한 무선 통신을 위한 방법으로서,

무선 통신 디바이스를 AP(access point)와 연관된 무선 STA(station)로서 동작시키는 단계 ― STA는 P2P(peer-to-peer) 링크를 통해 클라이언트 디바이스와 또한 연관됨 ―;

AP에 요청 프레임을 송신하는 단계 ― 요청 프레임은, STA가 무선 매체 상에서 클라이언트 디바이스와 P2P 통신들을 교환하고자 의도함을 표시하고, 요청 프레임은 클라이언트 디바이스를 식별함 ―;

무선 매체 상에서 AP로부터 제1 트리거 프레임을 수신하는 단계 ― 제1 트리거 프레임은 STA와 클라이언트 디바이스 사이의 P2P 통신들을 위해, AP에 의해 획득된 TXOP(transmission opportunity)의 일부를 배정하고, 제1 트리거 프레임 또는 응답 프레임 중 적어도 하나는 클라이언트 디바이스에 대한 NAV(Network Allocation Vector) 예외를 표시함 ―; 및

무선 매체 상에서 AP에 CTS(clear-to-send) 프레임을 송신하는 단계를 포함하고, CTS 프레임은 클라이언트 디바이스의 MAC(medium access control) 어드레스를 포함하는 수신기 어드레스 필드를 포함하는, 무선 통신 디바이스에 의한 무선 통신을 위한 방법.

80. 조항 79의 방법에 있어서, 제1 트리거 프레임은 클라이언트 디바이스의 MAC 어드레스를 포함하는, 무선 통신 디바이스에 의한 무선 통신을 위한 방법.

81. 조항 79의 방법에 있어서, NAV 예외는, 클라이언트 디바이스가 제1 트리거 프레임에 의해 표시되는 NAV 지속기간 및 제1 트리거 프레임에 대한 응답으로 CTS(clear-to-send) 프레임에 의해 표시되는 NAV 지속기간을 무시해야 함을 표시하는, 무선 통신 디바이스에 의한 무선 통신을 위한 방법.

82. 조항 79의 방법에 있어서, 무선 통신 디바이스는 STA와 코로케이트된 softAP를 포함하고, 코로케이트된 softAP는 클라이언트 디바이스와 통신하도록 구성되고, 응답 프레임 또는 제1 트리거 프레임 중 적어도 하나는 softAP에 대한 NAV 예외를 추가로 표시하는, 무선 통신 디바이스에 의한 무선 통신을 위한 방법.

83. 조항 82의 방법에 있어서, NAV 예외는, AP와 연관된 STA들과 코로케이트된 softAP들이 제1 트리거 프레임에 의해 표시되는 NAV 지속기간 및 트리거 프레임에 대한 응답으로 CTS(clear-to-send) 프레임에 의해 표시되는 NAV 지속기간을 무시해야 함을 표시하는, 무선 통신 디바이스에 의한 무선 통신을 위한 방법.

84. 조항 79의 방법에 있어서, 제1 트리거 프레임은 0의 값으로 설정된 비트를 반송하는 CS(Carrier Sense) 필수 필드를 포함하고, 0의 값으로 설정된 비트는 NAV 예외를 표시하는, 무선 통신 디바이스에 의한 무선 통신을 위한 방법.

85. 조항 79의 방법에 있어서,

무선 매체 상에서 AP로부터 응답 프레임을 수신하는 단계를 더 포함하고, 응답 프레임은 요청 프레임에 응답하고, 클라이언트 디바이스에 대한 NAV 예외를 표시하는, 무선 통신 디바이스에 의한 무선 통신을 위한 방법.

86. 조항 85의 방법에 있어서, 요청 프레임은 클라이언트 디바이스의 MAC(medium access control) 어드레스를 표시하고, 응답 프레임은 클라이언트 디바이스가 AP로부터 송신된 트리거 프레임들에 의해 설정되는 NAV 지속기간들 및 트리거 프레임들에 대한 응답으로 CTS(clear-to-send) 프레임들에 의해 설정되는 NAV 지속기간들을 무시해야 함을 표시하는, 무선 통신 디바이스에 의한 무선 통신을 위한 방법.

87. 조항 86의 방법에 있어서, 요청 프레임은 클라이언트 디바이스의 MAC 어드레스를 표시하는 TSPEC(traffic specification) 엘리먼트를 포함하는 SCS(Stream Classification Service) 요청 프레임이고, TSPEC 엘리먼트는 TS(traffic stream), TS와 연관된 PDU(protocol data unit)들에 대한 최소 데이터 레이트, TS와 연관된 PDU들에 대한 평균 데이터 레이트, TS에 대한 지연 한계, 및 TS에 대한 UP(user priority)를 추가로 표시하는, 무선 통신 디바이스에 의한 무선 통신을 위한 방법.

88. 조항 86의 방법에 있어서, 요청 프레임은, 적어도 클라이언트 디바이스의 MAC 어드레스를 표시하는 TWT 엘리먼트, TSPEC 엘리먼트, 또는 VSIE(vendor-specific information element) 중 하나 이상을 포함하는 P2P 요청 프레임인, 무선 통신 디바이스에 의한 무선 통신을 위한 방법.

89. 조항 79의 방법에 있어서, 제1 트리거 프레임은 MU(multi-user) RTS(Request-to-Send) TXS(TXOP Sharing) 트리거 프레임을 포함하는, 무선 통신 디바이스에 의한 무선 통신을 위한 방법.

90. 조항 89의 방법에 있어서, MU-RTS TXS 트리거 프레임은 클라이언트 디바이스와 연관된 P2P 통신들에 대응하는 TXOP 공유 모드를 표시하는 TXOP 공유 모드 서브필드를 포함하는, 무선 통신 디바이스에 의한 무선 통신을 위한 방법.

91. 조항 90의 방법에 있어서, TXOP 공유 모드 서브필드는, STA가 MU-RTS TXS 트리거 프레임에 대한 응답으로, 클라이언트 디바이스의 MAC 어드레스를 포함하는 수신기 어드레스 필드를 포함하는 CTS(clear-to-send) 프레임을 송신하라는 요청을 표시하는, 무선 통신 디바이스에 의한 무선 통신을 위한 방법.

92. 조항 79의 방법에 있어서,

무선 매체 상에서, 클라이언트 디바이스로부터 P2P 통신들을 요청하는 제2 트리거 프레임을 송신하는 단계 ― 제2 트리거 프레임은 클라이언트 디바이스의 MAC 어드레스를 포함함 ―; 및

제2 트리거 프레임에 대한 응답으로 클라이언트 디바이스로부터 P2P 송신을 수신하는 단계를 더 포함하는, 무선 통신 디바이스에 의한 무선 통신을 위한 방법.

93. 조항 92의 방법에 있어서, STA는, 클라이언트 디바이스에 제2 트리거 프레임을 송신하기 전에 적어도 SIFS(short interframe space) 지속기간 동안 무선 매체가 유휴 상태(idle)라고 결정하는, 무선 통신 디바이스에 의한 무선 통신을 위한 방법.

94. 조항 92의 방법에 있어서, P2P 통신들은 softAP와 클라이언트 디바이스 사이에 확립된 TDLS(tunneled direct-link setup) 링크를 통해 수신되는, 무선 통신 디바이스에 의한 무선 통신을 위한 방법.

95. 무선 통신 디바이스로서,

적어도 하나의 모뎀;

적어도 하나의 모뎀과 통신가능하게 커플링된 적어도 하나의 프로세서; 및

적어도 하나의 프로세서와 통신 가능하게 커플링되며 그리고 프로세서-판독가능 코드를 저장하는 적어도 하나의 메모리를 포함하고, 프로세서-판독가능 코드는, 적어도 하나의 모뎀과 함께 적어도 하나의 프로세서에 의해 실행될 때, 조항 79 내지 조항 94 중 임의의 하나 이상의 조항들의 동작들을 수행하도록 구성되는, 무선 통신 디바이스.

96. AP(access point)에 의한 무선 통신을 위한 방법으로서,

AP와 연관된 무선 STA(station)로부터 요청 프레임을 수신하는 단계 ― STA는 P2P(peer-to-peer) 클라이언트 디바이스와 연관된 softAP와 코로케이트되고, 요청 프레임은, 무선 매체에 스케줄링된 r-TWT(restricted target wake time) SP(service period) 동안 softAP가 클라이언트 디바이스와 P2P 통신들을 교환하고자 의도함을 표시함 ―;

r-TWT SP 동안 무선 매체 상에서 TXOP(transmission opportunity)를 획득하는 단계; 및

softAP와 클라이언트 디바이스 사이의 P2P 통신들을 위해, 획득된 TXOP의 일부를 배정하는 MU(multi-user) RTS(Request-to-Send) TXS(TXOP Sharing) 트리거 프레임을 무선 매체를 통해 STA에 송신하는 단계를 포함하고, MU-RTS TXS 트리거 프레임은 softAP에 대한 NAV(Network Allocation Vector) 예외와 연관된 공유 모드를 표시하는, AP에 의한 무선 통신을 위한 방법.

97. 조항 96의 방법에 있어서, 요청 프레임은 클라이언트 디바이스와 P2P 통신들을 교환하려는 의도를 표시하는 VSIE(Vendor-Specific Information Element)를 포함하는, AP에 의한 무선 통신을 위한 방법.

98. 조항 96의 방법에 있어서, NAV 예외는, softAP가 MU-RTS TXS 트리거 프레임에 의해 표시되는 NAV 지속기간을 무시해야 함을 표시하는, AP에 의한 무선 통신을 위한 방법.

99. 조항 98의 방법에 있어서, NAV 예외는, 클라이언트 디바이스가 MU-RTS TXS 트리거 프레임에 의해 표시되는 NAV 지속기간을 무시해야 함을 추가로 표시하는, AP에 의한 무선 통신을 위한 방법.

100. 조항 99의 방법에 있어서, MU-RTS TXS 트리거 프레임은 softAP의 MAC(medium access control) 어드레스 및 클라이언트 디바이스의 MAC 어드레스를 표시하는, AP에 의한 무선 통신을 위한 방법.

101. 조항 96의 방법에 있어서, NAV 예외는 r-TWT SP에 속하는 STA들과 코로케이트된 softAP들이 MU-RTS TXS 트리거 프레임에 의해 표시되는 NAV 지속기간들을 무시해야 함을 표시하는, AP에 의한 무선 통신을 위한 방법.

102. 조항 96의 방법에 있어서,

요청 프레임을 수신하는 것에 대한 응답으로 무선 매체 상에서 AP에 응답 프레임을 송신하는 단계를 더 포함하고, 응답 프레임은 얼마나 많은 디바이스들이 r-TWT SP의 멤버들인지를 표시하는, AP에 의한 무선 통신을 위한 방법.

103. 조항 96의 방법에 있어서, MU-RTS TXS 트리거 프레임은 0의 값으로 설정된 비트를 반송하는 CS(Carrier Sense) 필수 필드를 포함하고, 0의 값으로 설정된 비트는 NAV 예외를 표시하는, AP에 의한 무선 통신을 위한 방법.

104. 조항 96의 방법에 있어서, 요청 프레임은 클라이언트 디바이스의 MAC 어드레스를 표시하는 TWT 엘리먼트를 포함하는 TWT 요청 프레임이고, TWT 엘리먼트는 r-TWT SP의 주기성, r-TWT SP의 지속기간, r-TWT SP의 공유 모드, r-TWT SP의 웨이크 지속기간, r-TWT SP의 흐름 타입, 또는 r-TWT SP의 파라미터 세트 중 하나 이상을 추가로 표시하는, AP에 의한 무선 통신을 위한 방법.

105. 조항 96의 방법에 있어서, 요청 프레임은 클라이언트 디바이스의 MAC 어드레스를 표시하는 TSPEC(traffic specification) 엘리먼트를 포함하는 SCS(Stream Classification Service) 요청 프레임이고, TSPEC 엘리먼트는 r-TWT SP에 대한 최소 데이터 레이트, r-TWT SP에 대한 평균 데이터 레이트, r-TWT SP에 대한 지연 한계, 및 r-TWT SP에 대한 UP(user priority)를 추가로 표시하는, AP에 의한 무선 통신을 위한 방법.

106. 조항 96의 방법에 있어서, 요청 프레임은, 적어도 클라이언트 디바이스의 MAC 어드레스를 표시하는 TWT 엘리먼트, TSPEC 엘리먼트, 또는 VSIE(vendor-specific information element) 중 하나 이상을 포함하는 P2P 요청 프레임인, AP에 의한 무선 통신을 위한 방법.

107. 조항 96의 방법에 있어서, 요청 프레임은 STA가 r-TWT SP 내에서 무선 매체를 사용하고자 의도하는 제1 시간 기간을 표시하고, MU-RTS TXS 트리거 프레임은 TXOP의 일부가 클라이언트 디바이스와 연관된 P2P 통신들을 위해 배정되는 제2 시간 기간을 표시하는 지속기간 필드를 포함하며, 제2 시간 기간은 제1 시간 기간보다 짧은, AP에 의한 무선 통신을 위한 방법.

108. 조항 107의 방법에 있어서, 제2 시간 기간은 STA로부터의 CTS 프레임을 요청하는 것과 연관된 시간 기간에 기반하는, AP에 의한 무선 통신을 위한 방법.

109. 무선 통신 디바이스로서,

적어도 하나의 모뎀;

적어도 하나의 모뎀과 통신가능하게 커플링된 적어도 하나의 프로세서; 및

적어도 하나의 프로세서와 통신 가능하게 커플링되며 그리고 프로세서-판독가능 코드를 저장하는 적어도 하나의 메모리를 포함하고, 프로세서-판독가능 코드는, 적어도 하나의 모뎀과 함께 적어도 하나의 프로세서에 의해 실행될 때, 조항 96 내지 조항 108 중 임의의 하나 이상의 조항들의 동작들을 수행하도록 구성되는, 무선 통신 디바이스.

[0190] 본원에서 사용되는 바와 같이, 아이템들의 리스트 "중 적어도 하나" 또는 "중 하나 이상"으로 지칭되는 구문은 단일 멤버들을 포함하여 그러한 아이템들의 임의의 조합을 지칭한다. 예컨대, "a, b 또는 c 중 적어도 하나"는 가능성들: a만, b만, c만, a와 b의 조합, a와 c의 조합, b와 c의 조합, 및 a와 b와 c의 조합을 커버하도록 의도된다.

[0191] 본원에서 개시된 구현들과 관련하여 설명된 다양한 예시적인 컴포넌트들, 로직, 로직 블록들, 모듈들, 회로들, 동작들 및 알고리즘 프로세스들은, 본 명세서에서 개시된 구조들 및 그 구조적 등가물들을 포함하여, 전자 하드웨어, 펌웨어, 소프트웨어, 또는 하드웨어, 펌웨어 또는 소프트웨어의 조합들로서 구현될 수 있다. 하드웨어, 펌웨어 및 소프트웨어의 상호교환가능성은 기능의 관점들에서 일반적으로 설명되었으며, 위에서 설명된 다양한 예시적인 컴포넌트들, 블록들, 모듈들, 회로들 및 프로세스들에서 예시된다. 이러한 기능이 하드웨어로 구현되는지 또는 펌웨어로 구현되는지 또는 소프트웨어로 구현되는지 여부는 특정 애플리케이션, 및 전체 시스템에 부과된 설계 제약들에 의존한다.

[0192] 본 개시내용에서 설명된 구현들에 대한 다양한 변형들은 당업자들에게 용이하게 명백할 수 있으며, 본원에서 정의된 일반적인 원리들은 본 개시내용의 사상 또는 범위를 벗어나지 않으면서 다른 구현들에 적용될 수 있다. 따라서, 청구항들은 본원에서 도시된 구현들로 제한되도록 의도되는 것이 아니라, 본 개시내용, 본원에서 개시된 원리들 및 신규 특징들과 일치하는 가장 넓은 범위에 부합할 것이다.

[0193] 부가적으로, 별개의 구현들의 상황에서 본 명세서에 설명되는 다양한 특징들은 또한 단일 구현으로 결합되어 구현될 수 있다. 반대로, 단일 구현의 상황에서 설명되는 다양한 특징들은 또한 다수의 구현들에서 별개로 또는 임의의 적절한 하위 결합으로 구현될 수 있다. 따라서, 특징들이 특정한 결합들로 작용하는 것으로 앞서 설명되고 심지어 초기에 이와 같이 청구될지라도, 일부 경우들에서, 청구된 결합으로부터의 하나 이상의 특징들은 그 결합으로부터 제거될 수 있고, 청구된 결합은 하위 결합 또는 하위 결합의 변화에 관련될 수 있다.

[0194] 유사하게, 동작들이 특정한 순서로 도면들에 도시되지만, 이것은, 바람직한 결과들을 달성하기 위해, 그러한 동작들이 도시된 특정한 순서 또는 순차적인 순서로 수행되거나, 모든 도시된 동작들이 수행된다는 것을 요구하는 것으로서 이해되지는 않아야 한다. 추가로, 도면들은 하나 이상의 예시적인 프로세스들을 플로우챠트 또는 흐름도의 형태로 개략적으로 도시할 수 있다. 그러나, 도시되지 않은 다른 동작들이 개략적으로 예시된 예시적인 프로세스들에서 통합될 수 있다. 예컨대, 하나 이상의 추가적인 동작들은 예시된 동작들 중 임의의 것 전에, 후에, 동시에, 또는 그 사이에서 수행될 수 있다. 일부 환경들에서는, 멀티태스킹 및 병렬 프로세싱이 유리할 수 있다. 또한, 위에서 설명된 구현들에서의 다양한 시스템 컴포넌트들의 분리는 모든 구현들에서 그러한 분리를 요구하는 것으로서 이해되지는 않아야 하며, 설명된 프로그램 컴포넌트들 및 시스템들이 일반적으로, 단일 소프트웨어 제품에 함께 통합되거나 다수의 소프트웨어 제품들로 패키징될 수 있음을 이해해야 한다.

Claims (30)

1. AP(access point)에 의한 무선 통신을 위한 방법으로서,
   상기 AP와 연관되고 그리고 P2P(peer-to-peer) 링크를 통해 클라이언트 디바이스와 또한 연관된 무선 STA(station)로부터 요청 프레임을 수신하는 단계 ― 상기 요청 프레임은, 무선 매체에 스케줄링된 r-TWT(restricted target wake time) SP(service period) 동안 상기 STA가 상기 클라이언트 디바이스와 P2P 통신들을 교환하고자 의도함을 표시하고, 상기 요청 프레임은 상기 클라이언트 디바이스를 식별함 ―;
   상기 요청 프레임을 수신하는 것에 대한 응답으로, 상기 무선 매체 상에서 상기 STA에 응답 프레임을 송신하는 단계;
   상기 r-TWT SP 동안 상기 무선 매체 상에서 TXOP(transmission opportunity)를 획득하는 단계; 및
   상기 TXOP를 획득하는 것에 대한 응답으로, 상기 무선 매체 상에서 트리거 프레임을 송신하는 단계를 포함하고, 상기 트리거 프레임은 상기 STA와 상기 클라이언트 디바이스 사이의 P2P 통신들을 위해, 상기 획득된 TXOP의 일부를 배정(allocate)하고, 상기 응답 프레임 또는 상기 트리거 프레임 중 적어도 하나는 상기 클라이언트 디바이스에 대한 NAV(Network Allocation Vector) 예외(exception)를 표시하는, AP에 의한 무선 통신을 위한 방법.
2. 제1 항에 있어서,
   상기 응답 프레임 및 상기 트리거 프레임 각각은 상기 클라이언트 디바이스의 MAC(medium access control) 어드레스를 포함하는, AP에 의한 무선 통신을 위한 방법.
3. 제1 항에 있어서,
   상기 NAV 예외는, 상기 클라이언트 디바이스가 상기 트리거 프레임에 의해 표시되는 NAV 지속기간 및 상기 트리거 프레임에 대한 응답으로 CTS(clear-to-send) 프레임에 의해 표시되는 NAV 지속기간을 무시해야 함을 표시하는, AP에 의한 무선 통신을 위한 방법.
4. 제1 항에 있어서,
   상기 STA는 상기 클라이언트 디바이스와 통신하도록 구성된 코로케이트(collocate)된 softAP를 포함하고, 상기 응답 프레임 또는 상기 트리거 프레임 중 적어도 하나는 상기 softAP에 대한 NAV 예외를 추가로 표시하는, AP에 의한 무선 통신을 위한 방법.
5. 제4 항에 있어서,
   상기 NAV 예외는, 상기 r-TWT SP에 속하는 STA들과 코로케이트된 softAP들이 상기 트리거 프레임에 의해 표시되는 NAV 지속기간 및 상기 트리거 프레임에 대한 응답으로 CTS(clear-to-send) 프레임에 의해 표시되는 NAV 지속기간을 무시해야 함을 표시하는, AP에 의한 무선 통신을 위한 방법.
6. 제1 항에 있어서,
   상기 트리거 프레임은 0의 값으로 설정된 비트를 반송하는 CS(Carrier Sense) 필수 필드(Required field)를 포함하고, 상기 0의 값으로 설정된 비트는 상기 NAV 예외를 표시하는, AP에 의한 무선 통신을 위한 방법.
7. 제1 항에 있어서,
   상기 요청 프레임은 상기 클라이언트 디바이스의 MAC(medium access control) 어드레스를 표시하고, 상기 응답 프레임은 상기 클라이언트 디바이스가 상기 AP로부터 송신된 트리거 프레임들에 의해 설정되는 NAV 지속기간들 및 상기 트리거 프레임들에 대한 응답으로 CTS(clear-to-send) 프레임들에 의해 설정되는 NAV 지속기간들을 무시해야 함을 표시하는, AP에 의한 무선 통신을 위한 방법.
8. 제7 항에 있어서,
   상기 요청 프레임은 상기 클라이언트 디바이스의 MAC 어드레스를 표시하는 TWT 엘리먼트를 포함하는 TWT 요청 프레임이고, 상기 TWT 엘리먼트는 상기 r-TWT SP의 주기성(periodicity), 상기 r-TWT SP의 지속기간, 상기 r-TWT SP의 공유 모드, 상기 r-TWT SP의 웨이크 지속기간(wake duration), 상기 r-TWT SP의 흐름 타입, 또는 상기 r-TWT SP의 파라미터 세트 중 하나 이상을 추가로 표시하는, AP에 의한 무선 통신을 위한 방법.
9. 제7 항에 있어서,
   상기 요청 프레임은 상기 클라이언트 디바이스의 MAC 어드레스를 표시하는 TSPEC(traffic specification) 엘리먼트를 포함하는 SCS(Stream Classification Service) 요청 프레임이고, 상기 TSPEC 엘리먼트는 제한된 TWT 세션에 대한 최소 데이터 레이트, 상기 제한된 TWT 세션에 대한 평균 데이터 레이트, 상기 r-TWT SP에 대한 지연 한계(delay bound), 및 상기 r-TWT SP에 대한 UP(user priority)를 추가로 표시하는, AP에 의한 무선 통신을 위한 방법.
10. 제7 항에 있어서,
    상기 요청 프레임은, 적어도 상기 클라이언트 디바이스의 MAC 어드레스를 표시하는 TWT 엘리먼트, TSPEC 엘리먼트, 또는 VSIE(vendor-specific information element) 중 하나 이상을 포함하는 P2P 요청 프레임인, AP에 의한 무선 통신을 위한 방법.
11. 제1 항에 있어서,
    상기 응답 프레임은 얼마나 많은 디바이스들이 상기 r-TWT SP의 멤버들인지를 표시하는, AP에 의한 무선 통신을 위한 방법.
12. 제1 항에 있어서,
    상기 트리거 프레임은 MU(multi-user) RTS(Request-to-Send) TXS(TXOP Sharing) 트리거 프레임을 포함하는, AP에 의한 무선 통신을 위한 방법.
13. 제12 항에 있어서,
    상기 MU-RTS TXS 트리거 프레임은 상기 클라이언트 디바이스와 연관된 P2P 통신들에 대응하는 TXOP 공유 모드를 표시하는 TXOP 공유 모드 서브필드를 포함하는, AP에 의한 무선 통신을 위한 방법.
14. 제13 항에 있어서,
    상기 TXOP 공유 모드 서브필드는, 상기 STA가 상기 MU-RTS TXS 트리거 프레임에 대한 응답으로, 상기 클라이언트 디바이스의 MAC 어드레스를 포함하는 수신기 어드레스 필드를 포함하는 CTS(clear-to-send) 프레임을 송신하라는 요청을 표시하는, AP에 의한 무선 통신을 위한 방법.
15. 제1 항에 있어서,
    상기 요청 프레임은 상기 STA가 상기 r-TWT SP 내에서 상기 무선 매체를 사용하고자 의도하는 제1 시간 기간을 표시하고, 상기 트리거 프레임은 상기 TXOP의 일부가 상기 클라이언트 디바이스와 연관된 P2P 통신들을 위해 배정되는 제2 시간 기간을 표시하는 지속기간 필드를 포함하며, 상기 제2 시간 기간은 상기 제1 시간 기간보다 짧은, AP에 의한 무선 통신을 위한 방법.
16. 제15 항에 있어서,
    상기 제2 시간 기간은 상기 STA로부터의 CTS 프레임을 요청하는 것과 연관된 시간 기간에 기반하는, AP에 의한 무선 통신을 위한 방법.
17. 무선 통신 디바이스로서,
    적어도 하나의 모뎀;
    상기 적어도 하나의 모뎀과 통신가능하게 커플링된 적어도 하나의 프로세서; 및
    상기 적어도 하나의 프로세서와 통신가능하게 커플링되고 프로세서-판독가능 코드를 저장하는 적어도 하나의 메모리를 포함하고,
    상기 프로세서-판독가능 코드는, 상기 적어도 하나의 모뎀과 함께 상기 적어도 하나의 프로세서에 의해 실행될 때:
    AP와 연관되고 그리고 P2P(peer-to-peer) 링크를 통해 클라이언트 디바이스와 또한 연관된 무선 STA(station)로부터 요청 프레임을 수신하도록 ― 상기 요청 프레임은, 무선 매체에 스케줄링된 r-TWT(restricted target wake time) SP(service period) 동안 상기 STA가 상기 클라이언트 디바이스와 P2P 통신들을 교환하고자 의도함을 표시하고, 상기 요청 프레임은 상기 클라이언트 디바이스를 식별함 ―;
    상기 요청 프레임을 수신하는 것에 대한 응답으로, 상기 무선 매체 상에서 상기 STA에 응답 프레임을 송신하도록;
    상기 r-TWT SP 동안 상기 무선 매체 상에서 TXOP(transmission opportunity)를 획득하도록; 그리고
    상기 TXOP를 획득하는 것에 대한 응답으로, 상기 무선 매체 상에서 트리거 프레임을 송신하도록 구성되고, 상기 트리거 프레임은 상기 STA와 상기 클라이언트 디바이스 사이의 P2P 통신들을 위해, 상기 획득된 TXOP의 일부를 배정하고, 상기 응답 프레임 또는 상기 트리거 프레임 중 적어도 하나는 상기 클라이언트 디바이스에 대한 NAV(Network Allocation Vector) 예외를 표시하는, 무선 통신 디바이스.
18. 제17 항에 있어서,
    상기 응답 프레임 및 상기 트리거 프레임 각각은 상기 클라이언트 디바이스의 MAC(medium access control) 어드레스를 포함하는, 무선 통신 디바이스.
19. 제17 항에 있어서,
    상기 NAV 예외는, 상기 클라이언트 디바이스가 상기 트리거 프레임에 의해 표시되는 NAV 지속기간 및 상기 트리거 프레임에 대한 응답으로 CTS(clear-to-send) 프레임에 의해 표시되는 NAV 지속기간을 무시해야 함을 표시하는, 무선 통신 디바이스.
20. 제17 항에 있어서,
    상기 STA는 상기 클라이언트 디바이스와 통신하도록 구성된 코로케이트된 softAP를 포함하고, 상기 응답 프레임 또는 상기 트리거 프레임 중 적어도 하나는 상기 softAP에 대한 NAV 예외를 추가로 표시하는, 무선 통신 디바이스.
21. 제20 항에 있어서,
    상기 NAV 예외는, 상기 r-TWT SP에 속하는 STA들과 코로케이트된 softAP들이 상기 트리거 프레임에 의해 표시되는 NAV 지속기간 및 상기 트리거 프레임에 대한 응답으로 CTS(clear-to-send) 프레임에 의해 표시되는 NAV 지속기간을 무시해야 함을 표시하는, 무선 통신 디바이스.
22. 제17 항에 있어서,
    상기 트리거 프레임은 0의 값으로 설정된 비트를 반송하는 CS(Carrier Sense) 필수 필드를 포함하고, 상기 0의 값으로 설정된 비트는 상기 NAV 예외를 표시하는, 무선 통신 디바이스.
23. 제17 항에 있어서,
    상기 요청 프레임은 상기 클라이언트 디바이스의 MAC(medium access control) 어드레스를 표시하고, 상기 응답 프레임은 상기 클라이언트 디바이스가 상기 AP로부터 송신된 트리거 프레임들에 의해 설정되는 NAV 지속기간들 및 상기 트리거 프레임들에 대한 응답으로 CTS(clear-to-send) 프레임들에 의해 설정되는 NAV 지속기간들을 무시해야 함을 표시하는, 무선 통신 디바이스.
24. 제23 항에 있어서,
    상기 요청 프레임은 상기 클라이언트 디바이스의 MAC 어드레스를 표시하는 TWT 엘리먼트를 포함하는 TWT 요청 프레임이고, 상기 TWT 엘리먼트는 상기 r-TWT SP의 주기성, 상기 r-TWT SP의 지속기간, 상기 r-TWT SP의 공유 모드, 상기 r-TWT SP의 웨이크 지속기간, 상기 r-TWT SP의 흐름 타입, 또는 상기 r-TWT SP의 파라미터 세트 중 하나 이상을 추가로 표시하는, 무선 통신 디바이스.
25. 제23 항에 있어서,
    상기 요청 프레임은 상기 클라이언트 디바이스의 MAC 어드레스를 표시하는 TSPEC(traffic specification) 엘리먼트를 포함하는 SCS(Stream Classification Service) 요청 프레임이고, 상기 TSPEC 엘리먼트는 제한된 TWT 세션에 대한 최소 데이터 레이트, 상기 제한된 TWT 세션에 대한 평균 데이터 레이트, 상기 r-TWT SP에 대한 지연 한계, 및 상기 r-TWT SP에 대한 UP(user priority)를 추가로 표시하는, 무선 통신 디바이스.
26. 제23 항에 있어서,
    상기 요청 프레임은, 적어도 상기 클라이언트 디바이스의 MAC 어드레스를 표시하는 TWT 엘리먼트, TSPEC 엘리먼트, 또는 VSIE(vendor-specific information element) 중 하나 이상을 포함하는 P2P 요청 프레임인, 무선 통신 디바이스.
27. 제17 항에 있어서,
    상기 응답 프레임은 얼마나 많은 디바이스들이 상기 r-TWT SP의 멤버들인지를 표시하는, 무선 통신 디바이스.
28. 제17 항에 있어서,
    상기 트리거 프레임은, 상기 클라이언트 디바이스와 연관된 P2P 통신들에 대응하는 TXOP 공유 모드를 표시하는 TXOP 공유 모드 서브필드를 포함하는 MU(multi-user) RTS(Request-to-Send) TXS(TXOP Sharing) 트리거 프레임을 포함하는, 무선 통신 디바이스.
29. 제28 항에 있어서,
    상기 TXOP 공유 모드 서브필드는, 상기 STA가 상기 MU-RTS TXS 트리거 프레임에 대한 응답으로, 상기 클라이언트 디바이스의 MAC 어드레스를 포함하는 수신기 어드레스 필드를 포함하는 CTS(clear-to-send) 프레임을 송신하라는 요청을 표시하는, 무선 통신 디바이스.
30. 제17 항에 있어서,
    상기 요청 프레임은 상기 STA가 상기 r-TWT SP 내에서 상기 무선 매체를 사용하고자 의도하는 제1 시간 기간을 표시하고, 상기 트리거 프레임은 상기 TXOP의 일부가 상기 클라이언트 디바이스와 연관된 P2P 통신들을 위해 배정되는 제2 시간 기간을 표시하는 지속기간 필드를 포함하며, 상기 제2 시간 기간은 상기 제1 시간 기간보다 짧은, 무선 통신 디바이스.