KR102195782B1 - 무선 근거리 네트워크들에서 균일한 다수의 액세스 포인트들의 커버리지에 대한 매체 액세스 제어를 위한 방법 및 장치 - Google Patents

Abstract

다중-AP 및 다중-무선 송수신 유닛 송신들에서 방법과 장치가 사용될 수도 있다. 그 장치는 제 1 매체 상에서 송신 요청을 송신하고, 제 1 매체 상에서 송신 응답을 수신하도록 구성될 수도 있다. 응답하여, 그 장치는 제 2 매체 상에서 송신 협상을 수행하고 송신 협상에 기초하여 제 2 매체 상에서 데이터를 송신할 수도 있다. 그 장치는 액세스 포인트(AP)/PCP 협상들을 통해 협응형 섹터화된 또는 빔포밍된 송신들을 수행하도록 구성될 수도 있다. 그 장치는 송신 및 협응형 섹터화된 또는 빔포밍된 송신들에 대한 지원의 표시를 제공할 수도 있다. 그 방법과 장치는 다중-AP/WTRU RTS(request-to-send)/CTS(clear-to-send) 절차들을 또한 구현할 수도 있다. 그 장치는 협응형 섹터화된 또는 빔포밍 그룹화를 수행하도록 구성될 수도 있다.

Description

무선 근거리 네트워크들에서 균일한 다수의 액세스 포인트들의 커버리지에 대한 매체 액세스 제어를 위한 방법 및 장치{A METHOD AND APPARATUS FOR MEDIUM ACCESS CONTROL FOR UNIFORM MULTIPLE ACCESS POINTS COVERAGE IN WIRELESS LOCAL AREA NETWORKS}

관련 출원들에 대한 상호 참조

본 출원은 2012년 11월 8일자로 출원된 미국 가출원 제61/724,032호를 우선권 주장하며, 그 전체 내용은 참조로 본원에 통합된다.

인프라스트럭처 기본 서비스 세트(basic service set, BSS) 모드에서의 WLAN이 BSS를 위한 액세스 포인트(Access Point, AP)와 AP에 연관된 무선 송수신 유닛(wireless transmit/receive unit, WTRU)들이라고 또한 본원에서 지칭되는 하나 이상의 스테이션들(STA들)을 갖는다. BSS 안팎으로 트래픽을 운반하는 AP는 분배 시스템(distribution system, DS) 또는 다른 유형의 유무선 네트워크에 통상적으로 액세스하거나 또는 인터페이싱한다. BSS 외부로부터 비롯되는 STA들에 대한 트래픽은 AP를 통해 도착하고 STA들로 전달될 수도 있다. BSS 외부의 목적지들까지 STA들로부터 비롯되는 트래픽은 각각의 목적지들로 전달되기 위해 AP로 전송될 수도 있다. BSS 내의 STA들 간의 트래픽은 AP를 통해 또한 전송될 수도 있는데 소스 STA는 트래픽을 AP로 전송하고 AP는 그 트래픽을 목적지 STA로 전달한다. BSS 내의 STA들 간의 이러한 트래픽은 피어 투 피어 트래픽일 수도 있다. 이러한 피어 투 피어 트래픽은 802.11e DLS 또는 802.11z 터널링된 DLS(tunneled DLS, TDLS)를 사용하여 직접 링크 셋업(direct link setup, DLS)으로 소스 및 목적지 STA들 간에 또한 직접 전송될 수도 있다. 독립 BSS 모드에서의 WLAN이 서로 직접적으로 통신하는 AP 및 STA들을 갖지 않을 수도 있다. 이들 시스템들에 대해 개선된 스루풋 성능 및 감소된 간섭이 필요하다.

다중-AP 및 다중-무선 송수신 유닛 공동 송신(joint transmission)들에서 방법과 장치가 사용될 수도 있다. 그 장치는 제 1 매체 상에서 공동 송신 요청을 송신하고, 제 1 매체 상에서 공동 송신 응답을 수신하도록 구성될 수도 있다. 응답하여, 그 장치는 제 2 매체 상에서 공동 송신 협상을 수행하고 공동 송신 협상에 기초하여 제 2 매체 상에서 데이터를 송신할 수도 있다. 그 장치는 액세스 포인트(access point; AP)/PCP 협상들을 통해 협응형 섹터화된 또는 빔포밍된(coordinated sectorized or beamformed) 송신들을 수행하도록 구성될 수도 있다. 그 장치는 공동 송신 및 협응형 섹터화된 또는 빔포밍된 송신들에 대한 지원의 표시를 제공할 수도 있다. 그 방법과 장치는 다중-AP/WTRU RTS(request-to-send)/CTS(clear-to-send) 절차들을 또한 구현할 수도 있다. 그 장치는 협응형 섹터화된 또는 빔포밍 그룹화를 수행하도록 구성될 수도 있다.

다음의 첨부 도면들에 연계하여 예로서 주어진다고 하면 다음의 설명으로부터 더 상세한 이해가 얻어질 수도 있다:
도 1a는 하나 이상의 개시된 실시형태들이 구현될 수도 있는 일 예의 통신 시스템의 시스템도이다;
도 1b는 도 1a에 예시된 통신 시스템 내에서 사용될 수도 있는 일 예의 무선 송수신 유닛(WTRU)의 시스템도이다;
도 1c는 도 1a에서 예시된 통신 시스템 내에서 사용될 수도 있는 일 예의 무선 액세스 네트워크 및 일 예의 코어 네트워크의 시스템도이다;
도 2는 일 예의 WiFi(wireless fidelity) 핫스팟 전개의 도면이다;
도 3a는 다중-AP 협응형 공동 송신의 하이 레벨 신호 흐름도이다;
도 3b는 다중-WTRU 협응형 공동 송신의 다운링크에서의 하이 레벨 신호 흐름도이다;
도 3c는 다중-WTRU 협응형 공동 송신의 업링크에서의 하이 레벨 신호 흐름도이다;
도 4는 일 예의 공동 송신 능력 정보 엘리먼트(Information Element, IE)의 도면이다;
도 5a는 협응형 공동 송신을 위해 사용되는 일 예의 제어 정보 교환의 하이 레벨 신호 흐름도이다;
도 5b는 일 예의 공동 송신 요청 IE의 도면이다;
도 6은 일 예의 공동 송신 응답 IE의 도면이다;
도 7a는 AP들에서의 공동 송신 능력들을 결정하고 공동 송신을 준비하는 일 예의 흐름도를 도시한다;
도 7b는 일 예의 공동 송신 질의(query) IE의 도면이다;
도 7c는 일 예의 공동 송신 피드백 IE의 도면이다;
도 7d는 일 예의 공동 송신 통지 IE의 도면이다;
도 8은 공동 송신 세션 동안 수신용 WTRU로 전송되기 위해 AAP로부터 ATAP로 전송될 수도 있는 데이터 패킷의 일 예를 도시한다;
도 9는 협응형 공동 송신을 가능하게 하기 위해 AP 또는 WTRU와 연관시키기 위한 일 예의 절차의 흐름도를 도시한다;
도 10은 협응형 공동 송신을 위해 ATAP를 선택하는 일 예의 절차를 도시한다;
도 11은 일 예의 스케줄링된 병행 공동 송신 절차의 도면이다;
도 12는 일 예의 스케줄링된 순차 공동 송신 절차의 도면이다;
도 13은 일 예의 공동 송신(Joint Transmission, JT)-RTS 프레임의 도면이다;
도 14는 일 예의 JT-RTS 프레임의 도면이다;
도 15는 일 예의 경합 기반 병행 공동 송신 절차의 도면이다;
도 16은 일 예의 경합 기반 순차 공동 송신 절차의 도면이다;
도 17a는 다중-WTRU 협응형 공동 송신을 위해 사용되는 일 예의 제어 정보 교환의 하이 레벨 신호 흐름도를 도시한다;
도 17b는 다중-WTRU 협응형 공동 송신을 위해 사용되는 일 예의 공동 송신 요청 IE의 도면이다;
도 18은 AP들에서의 공동 송신 능력들을 결정하고 공동 송신을 준비하는 일 예의 흐름도를 도시한다;
도 19는 다운링크에서 협응형 공동 송신을 위해 A-WTRU를 선택하는 일 예의 절차를 도시한다;
도 20은 업링크에서 협응형 공동 송신을 위해 A-WTRU를 선택하는 C-WTRU에 의해 사용되는 일 예의 절차를 도시한다;
도 21a는 AP/PCP/WTRU 협상들을 통해 협응형 섹터화된 동작 또는 빔포밍된 송신들을 가능하게 하는 일 예의 절차를 도시한다;
도 21b는 섹터화된 또는 빔포밍된 송신들 및 수신들을 사용하는 시스템의 일 예를 도시한다;
도 22는 섹터화된 수신 보고 IE의 일 예의 설계를 도시한다;
도 23은 보고용(reporting) 필드의 일 예를 도시한다;
도 24는 송신 섹터 충돌 리스트들 또는 테이블들을 공유하는 송신 섹터 충돌 IE의 일 예의 설계를 도시한다;
도 25a는 협응형 섹터화된 또는 빔포밍된 송신들의 일 예를 도시한다;
도 25b는 협응형 섹터화된 또는 빔포밍된 송신들의 다른 예를 도시한다;
도 26은 협응형 섹터화된 및 빔포밍 능력 IE의 일 예를 도시한다;
도 27은 WTRU들에 하나를 초과하는 WLAN 인터페이스가 갖추어진 예의 시스템을 도시한다;
도 28은 숨은 노드 문제의 일 예를 제공한다;
도 29는 상이한 주파수 대역들을 통한 RTS/CTS 패킷들의 송을 위한 일 예의 절차를 도시한다;
도 30은 일 예의 RTS/CTS 포맷을 도시한다;
도 31은 숨은 노드 문제가 핸들링되는 다중-AP WiFi의 일 예를 제공한다;
도 32는 MRTS 및 MCTS를 위한 일 예의 프레임 포맷을 제공한다;
도 33a는 슈퍼 AP에 의한 공동 디코딩의 일 예를 도시한다;
도 33b는 1차 AP에 의한 공동 디코딩의 일 예를 도시한다;
도 33c는 복수의 AP들에 의한 별개의 디코딩의 일 예를 도시한다;
도 33d는 단일 AP에 의한 별개의 디코딩의 일 예를 도시한다;
도 34a는 단일 WTRU가 복수의 AP들에 송신할 수도 있는 일 예의 CSMA/CA 절차를 도시한다;
도 34a는 단일 WTRU가 복수의 AP들에 송신할 수도 있는 다른 예의 CSMA/CA 절차를 도시한다;
도 35는 일 예의 UniFi_RTS 프레임 포맷을 도시한다;
도 36은 독립 UniFi_CTS 프레임 포맷을 도시한다;
도 37은 공동 UniFi_CTS 프레임 포맷을 도시한다;
도 38은 그룹 ID 및 부가적인 AP ID들을 갖는 데이터 프레임의 일 예를 도시한다;
도 39a는 다수의 수신 어드레스들을 포함할 수도 있는 공동 ACK의 일 예를 도시한다;
도 39b는 결집된(aggregated) ACK의 일 예를 도시한다;
도 40은 공간 협응형 다중-AP 송신(spatial coordinated multi-AP transmission, SCMAT)을 위한 그룹화의 일 예를 도시한다;
도 41은 사용자 포지션 어레이 필드의 일 예를 제공한다;
도 42a는 SCMAT 그룹 관리 프레임을 위한 부분적 MAC 헤더의 일 예를 제공한다;
도 42b는 SCMAT 그룹을 형성하기 위해 SCMAT 그룹 관리 프레임을 이용하는 일 예의 절차를 제공한다; 그리고
도 43은 SCMAT 관련된 송신들을 위해 정의된 프레임 포맷의 일 예를 제공한다.

도 1a는 하나 이상의 개시된 실시형태들이 구현될 수도 있는 일 예의 통신 시스템(100)의 도면이다. 통신 시스템(100)은 콘텐츠, 이를테면 음성, 데이터, 비디오, 메시징, 브로드캐스트 등을 다수의 무선 사용자들에게 제공하는 다중 액세스 시스템일 수도 있다. 통신 시스템(100)은 다수의 무선 사용자들이 무선 대역폭을 포함한 시스템 자원들의 공유를 통해 이러한 콘텐츠에 액세스하는 것을 가능하게 할 수도 있다. 예를 들어, 통신 시스템들(100)은 하나 이상의 채널 액세스 방법들, 이를테면 코드 분할 다중 접속(code division multiple access, CDMA), 시분할 다중 접속(time division multiple access, TDMA), 주파수 분할 다중 접속(frequency division multiple access, FDMA), 직교 FDMA(orthogonal FDMA, OFDMA), 단일 캐리어 FDMA(single-carrier FDMA, SC-FDMA) 등을 채용할 수도 있다.

도 1a에 도시된 바와 같이, 통신 시스템(100)은 무선 송수신 유닛들(WTRU들)(102a, 102b, 102c, 102d), 무선 액세스 네트워크(radio access network, RAN)(104), 코어 네트워크(106), 공중전화망(public switched telephone network, PSTN)(108), 인터넷(110), 및 다른 네트워크들(112)을 포함할 수도 있지만, 개시된 실시형태들은 임의의 수의 WTRU들, 기지국들, 네트워크들, 및/또는 네트워크 엘리먼트들을 생각하고 있다는 것이 이해될 것이다. WTRU들(102a, 102b, 102c, 102d)의 각각은 무선 환경에서 동작 및/또는 통신하도록 구성된 임의의 유형의 디바이스일 수도 있다. 예로서, WTRU들(102a, 102b, 102c, 102d)은 무선 신호들을 송신 및/또는 수신하도록 구성될 수도 있고 사용자 장비(UE), 이동국, 고정된 또는 모바일 가입자 유닛, 페이저, 셀룰러 전화기, 개인휴대 정보 단말(personal digital assistant, PDA), 스마트폰, 랩톱, 넷북, 개인용 컴퓨터, 무선 센서, 소비자 가전기기들 등을 포함할 수도 있다.

통신 시스템들(100)은 기지국(114a)과 기지국(114b)을 또한 포함할 수도 있다. 기지국들(114a, 114b)의 각각은 하나 이상의 통신네트워크들, 이를테면 코어 네트워크(106), 인터넷(110), 및/또는 네트워크들(112)에 대한 액세스를 용이하게 하기 위해 WTRU들(102a, 102b, 102c, 102d) 중 적어도 하나와 무선으로 인터페이싱하도록 구성된 임의의 유형의 디바이스일 수도 있다. 예로서, 기지국들(114a, 114b)은 기지국 트랜시버(base transceiver station; BTS), 노드-B, eNode B, 홈 노드 B, 홈 eNode B, 사이트 제어기, 액세스 포인트(AP), 무선 라우터 등일 수도 있다. 기지국들(114a, 114b)이 각각 단일 엘리먼트로서 묘사되지만, 기지국들(114a, 114b)은 임의의 수의 상호접속된 기지국들 및/또는 네트워크 엘리먼트들을 포함할 수도 있다.

기지국(114a)은 RAN(104)의 부분일 수도 있는데, 이 RAN은 다른 기지국들 및/또는 네트워크 엘리먼트들(미도시), 이를테면 기지국 제어기(base station controller, BSC), 무선 네트워크 제어기(radio network controller, RNC), 릴레이 노드들 등을 또한 포함할 수도 있다. 기지국(114a) 및/또는 기지국(114b)은 셀(미도시)이라고 지칭될 수도 있는 특정 지리적 지역 내에서 무선 신호들을 송신 및/또는 수신하도록 구성될 수도 있다. 그 셀은 셀 섹터들로 더욱 세분될 수도 있다. 예를 들어, 기지국(114a)에 연관된 셀은 3 개의 섹터들로 나누어질 수도 있다. 따라서, 하나의 실시형태에서, 기지국(114a)은 3 개의 트랜시버들을, 즉, 셀의 각각의 섹터마다 하나씩 포함할 수도 있다. 다른 실시형태에서, 기지국(114a)은 다중 입력 다중 출력(multiple-input multiple output, MIMO) 기술을 채용할 수도 있고, 그러므로, 셀의 각각의 섹터에 대해 다수의 트랜시버들을 이용할 수도 있다.

기지국들(114a, 114b)은 에어 인터페이스(116)를 통해 WTRU들(102a, 102b, 102c, 102d) 중 하나 이상과 통신할 수도 있는데, 에어 인터페이스는 임의의 적합한 무선 통신 링크(예컨대, 무선 주파수(radio frequency, RF), 마이크로파, 적외선(infrared, IR), 자외선(ultraviolet, UV), 가시광선 등)일 수도 있다. 에어 인터페이스(116)는 임의의 적합한 무선 접속 기술(radio access technology, RAT)을 사용하여 확립될 수도 있다.

더 구체적으로는, 위에서 언급했듯이, 통신 시스템(100)은 다중 액세스 시스템일 수도 있고, 하나 이상의 채널 액세스 체계(scheme)들, 이를테면 CDMA, TDMA, FDMA, OFDMA, SC-FDMA 등을 채용할 수도 있다. 예를 들어, RAN(104)에서의 기지국(114a)과 WTRU들(102a, 102b, 102c)은 유니버셜 이동 통신 시스템(Universal Mobile Telecommunications System, UMTS) 지상파 라디오 액세스(Terrestrial Radio Access, UTRA)와 같은 라디오 기술을 구현할 수도 있는데, 이 라디오 기술은 광대역 CDMA(wideband CDMA, WCDMA)를 사용하여 에어 인터페이스(116)를 확립할 수도 있다. WCDMA는 고속 패킷 액세스(High-Speed Packet Access, HSPA) 및/또는 진화형 HSPA(Evolved HSPA, HSPA+)와 같은 통신 프로토콜들을 포함할 수도 있다. HSPA는 고속 다운링크 패킷 액세스(High-Speed Downlink Packet Access, HSDPA) 및/또는 고속 업링크 패킷 액세스(HSUPA)를 포함할 수도 있다.

다른 실시형태에서, 기지국(114a)과 WTRU들(102a, 102b, 102c)은 진화형 UMTS 지상파 라디오 액세스(Evolved UMTS Terrestrial Radio Access, E-UTRA)와 같은 라디오 기술을 구현할 수도 있는데, 이 라디오 기술은 LTE(Long Term Evolution) 및/또는 LTE-A(LTE-Advanced)를 사용하여 에어 인터페이스(116)를 확립할 수도 있다.

다른 실시형태들에서, 기지국(114a)과 WTRU들(102a, 102b, 102c)은 IEEE 802.16(즉, WiMAX(Worldwide Interoperability for Microwave Access)), CDMA2000, CDMA2000 IX, CDMA2000 EV-DO, 잠정 표준 2000(IS-2000), 잠정 표준 95(IS-95), 잠정 표준 856(IS-856), GSM(Global System for Mobile communications), EDGE(Enhanced Data rates for GSM Evolution), GSM EDGE(GERAN) 등과 같은 라디오 기술들을 구현할 수도 있다.

도 1a에서의 기지국(114b)은, 예를 들어, 무선 라우터, 홈 노드 B, 홈 eNode B, 또는 액세스 포인트일 수도 있고, 국소화된 영역, 이를테면 사업장, 홈, 차량, 캠퍼스 등에서 무선 접속을 용이하게 하기 위해 임의의 적합한 RAT를 이용할 수도 있다. 하나의 실시형태에서, 기지국(114b)과 WTRU들(102c, 102d)은 무선 로컬 영역 네트워크(wireless local area network, WLAN)를 확립하기 위해 IEEE 802.11과 같은 라디오 기술을 구현할 수도 있다. 다른 실시형태에서, 기지국(114b)과 WTRU들(102c, 102d)은 무선 개인 영역 네트워크(wireless personal area network, WPAN)를 확립하기 위해 IEEE 802.15와 같은 라디오 기술을 구현할 수도 있다. 또 다른 실시형태에서, 기지국(114b)과 WTRU들(102c, 102d)은 피코셀 또는 펨토셀을 확립하기 위해 셀룰러 기반 RAT(예컨대, WCDMA, CDMA2000, GSM, LTE, LTE-A 등)를 이용할 수도 있다. 도 1a에서 도시된 바와 같이, 기지국(114b)은 인터넷(110)에 대한 직접 접속을 가질 수도 있다. 따라서, 기지국(114b)은 코어 네트워크(106)를 통해 인터넷(110)에 액세스하는데 필요하지 않을 수도 있다.

RAN(104)은 코어 네트워크(106)와 통신할 수도 있는데, 이 코어 네트워크는 음성, 데이터, 애플리케이션들, 및/또는 VoIP(voice over internet protocol) 서비스들을 WTRU들(102a, 102b, 102c, 102d) 중 하나 이상에 제공하도록 구성된 임의의 유형의 네트워크일 수도 있다. 예를 들어, 코어 네트워크(106)는 호 제어, 빌링 서비스들, 모바일 로케이션 기반 서비스들, 선불 전화, 인터넷 접속성, 비디오 배포 등을 제공하며 그리고/또는 하이-레벨 보안 기능들, 이를테면 사용자 인증을 수행할 수도 있다. 도 1a에 도시되진 않았지만, RAN(104) 및/또는 코어 네트워크(106)는 RAN(104)과는 동일한 RAT 또는 상이한 RAT를 채용하는 다른 RAN들과 직접 또는 간접 통신할 수도 있다는 것이 이해될 것이다. 예를 들어, E-UTRA 라디오 기술을 이용하고 있을 수도 있는 RAN(104)에 연결되는 것 외에도, 코어 네트워크(106)는 GSM 라디오 기술을 채용하는 다른 RAN(미도시)과 또한 통신할 수도 있다.

코어 네트워크(106)는 PSTN(108), 인터넷(110), 및/또는 다른 네트워크들(112)에 액세스하기 위한 WTRU들(102a, 102b, 102c, 102d)에 대한 게이트웨이로서 또한 역할을 할 수도 있다. PSTN(108)은 기존 전화 서비스(plain old telephone service, POTS)를 제공하는 회선 교환식 전화기 네트워크들을 포함할 수도 있다. 인터넷(110)은 공통 통신 프로토콜들, 이를테면 TCP/IP 인터넷 프로토콜 스위트에서의 송신 제어 프로토콜(transmission control protocol, TCP), 사용자 데이터그램 프로토콜(user datagram protocol, UDP) 및 인터넷 프로토콜(internet protocol, IP)을 사용하는 상호접속된 컴퓨터 네트워크들 및 디바이스들의 글로벌 시스템을 포함할 수도 있다. 네트워크들(112)은 다른 서비스 제공자들에 의해 소유된 및/또는 동작되는 유선 통신 또는 무선 통신 네트워크들을 포함할 수도 있다. 예를 들어, 네트워크들(112)은 하나 이상의 RAN들에 접속된 다른 코어 네트워크를 포함할 수도 있는데, 이 하나 이상의 RAN들은 RAN(104)과는 동일한 RAT 또는 상이한 RAT를 채용할 수도 있다.

통신 시스템(100)에서의 WTRU들(102a, 102b, 102c, 102d) 중 일부 또는 전부는 다중-모드 능력들을 구비할 수도 있으며, 즉, WTRU들(102a, 102b, 102c, 102d)은 상이한 무선 링크들을 통해 상이한 무선 네트워크들과 통신하기 위해 다수의 트랜시버들을 구비할 수도 있다. 예를 들어, 도 1a에 도시된 WTRU(102c)는 셀룰러 기반 라디오 기술을 채용할 수도 있는 기지국(114a)과 그리고 IEEE 802 라디오 기술을 채용할 수도 있는 기지국(114b)과 통신하도록 구성될 수도 있다.

도 1b는 일 예의 WTRU(102)의 시스템도이다. 도 1b에 도시된 바와 같이, WTRU(102)는 프로세서(118), 트랜시버(120), 송수신 엘리먼트(122), 스피커/마이크로폰(124), 키패드(126), 디스플레이/터치패드(128), 비-착탈식 메모리(106), 착탈식 메모리(132), 전력원(134), 글로벌 포지셔닝 시스템(global positioning system, GPS) 칩셋(136), 및 다른 주변장치들(138)을 포함할 수도 있다. WTRU(102)는 전술한 엘리먼트들의 임의의 하위조합을 포함하면서도 일 실시형태와 일치하게 유지할 수도 있다는 것이 이해될 것이다.

프로세서(118)는 범용 프로세서, 특수 목적 프로세서, 기존의 프로세서, 디지털 신호 프로세서(DSP), 복수의 마이크로프로세서들, DSP 코어에 연관된 하나 이상의 마이크로프로세서들, 제어기, 마이크로제어기, 주문형 집적회로들(ASIC들), 필드 프로그램가능 게이트 어레이(FPGA들) 회로들, 임의의 다른 유형의 집적 회로(IC), 상태 기계 등일 수도 있다. 프로세서(118)는 신호 코딩, 데이터 프로세싱, 전력 제어, 입력/출력 프로세싱, 및/또는 WTRU(102)가 무선 환경에서 동작하는 것을 가능하게 하는 임의의 다른 기능을 수행할 수도 있다. 프로세서(118)는 트랜시버(120)에 커플링될 수도 있는데, 그 트랜시버는 송수신 엘리먼트(122)에 커플링될 수도 있다. 도 1b가 프로세서(118)와 트랜시버(120)를 별개의 컴포넌트들로서 묘사하지만, 프로세서(118)와 트랜시버(120)는 전자 패키지 또는 칩 내에 함께 통합될 수도 있다.

송수신 엘리먼트(122)는 에어 인터페이스(116)를 통해 신호들을 기지국(예컨대, 기지국 114a)으로 송신하거나 또는 그 기지국으로부터 신호들을 수신하도록 구성될 수도 있다. 예를 들어, 하나의 실시형태에서, 송수신 엘리먼트(122)는 RF 신호들을 송신 및/또는 수신하도록 구성된 안테나일 수도 있다. 다른 실시형태에서, 송수신 엘리먼트(122)는, 예를 들어, IR, UV, 또는 가시광선 신호들을 송신 및/또는 수신하도록 구성된 방출기/검출기일 수도 있다. 또 다른 실시형태에서, 송수신 엘리먼트(122)는 RF 및 광 신호들 양쪽 모두를 송신 및 수신하도록 구성될 수도 있다. 송수신 엘리먼트(122)는 무선 신호들의 임의의 조합을 송신 및/또는 수신하도록 구성될 수도 있다는 것이 이해될 것이다.

덧붙여서, 비록 송수신 엘리먼트(122)는 도 1b에서 단일 엘리먼트로서 묘사되지만, WTRU(102)는 임의의 수의 송수신 엘리먼트들(122)을 포함할 수도 있다. 더 구체적으로는, WTRU(102)는 MIMO 기술을 채용할 수도 있다. 따라서, 하나의 실시형태에서, WTRU(102)는 에어 인터페이스(116)를 통해 무선 신호들을 송신 및 수신하기 위한 둘 이상의 송수신 엘리먼트들(122)(예컨대, 다수의 안테나들)을 구비할 수도 있다.

트랜시버(120)는 송수신 엘리먼트(122)에 의해 송신될 신호들을 변조하도록 그리고 송수신 엘리먼트(122)에 의해 수신된 신호들을 복조하도록 구성될 수도 있다. 위에서 언급했듯이, WTRU(102)는 다중-모드 능력들을 가질 수도 있다. 따라서, 트랜시버(120)는 WTRU(102)가, 예를 들어, UTRA 및 IEEE 802.11과 같은 다수의 RAT들을 통해 통신하는 것을 가능하게 하는 다수의 트랜시버들을 포함할 수도 있다.

WTRU(102)의 프로세서(118)는 스피커/마이크로폰(124), 키패드(126), 및/또는 디스플레이/터치패드(128)(예컨대, 액정 디스플레이(LCD) 디스플레이 유닛 또는 유기 발광 다이오드(OLED) 디스플레이 유닛)에 커플링될 수도 있고 그것들로부터 사용자 입력 데이터를 수신할 수도 있다. 프로세서(118)는 사용자 데이터를 스피커/마이크로폰(124), 키패드(126), 및/또는 디스플레이/터치패드(128)로 또한 출력할 수도 있다. 덧붙여서, 프로세서(118)는 임의의 유형의 적합한 메모리, 이를테면 비-착탈식 메모리(106) 및/또는 착탈식 메모리(132)에서 정보를 액세스하고 데이터를 그 메모리에 저장할 수도 있다. 비착탈식 메모리(106)는 랜덤-액세스 메모리(RAM), 판독-전용 메모리(ROM), 하드 디스크, 또는 임의의 다른 유형의 메모리 저장 디바이스를 포함할 수도 있다. 착탈식 메모리(132)는 가입자 식별 모듈(subscriber identity module, SIM) 카드, 메모리 스틱, 보안 디지털(secure digital, SD) 메모리 카드 등을 포함할 수도 있다. 다른 실시형태들에서, 프로세서(118)는 WTRU(102) 상에, 이를테면 서버 또는 홈 컴퓨터(미도시) 상에 물리적으로 위치되지 않은 메모리로부터 정보를 액세스하고 데이터를 그 메모리에 저장할 수도 있다.

프로세서(118)는 전력원(134)으로부터 전력을 받을 수도 있고, WTRU(102)에서의 다른 컴포넌트들에 전력을 분배하며 그리고/또는 제어하도록 구성될 수도 있다. 전력원(134)은 WTRU(102)에 전력을 공급하는 임의의 적합한 디바이스일 수도 있다. 예를 들어, 전력원(134)은 하나 이상의 건전지 배터리들(예컨대, 니켈-카드뮴(NiCd), 니켈-아연(NiZn), 니켈 금속 수소화물(NiMH), 리듐이온(Li-ion) 등), 태양 전지들, 연료 전지들 등을 포함할 수도 있다.

프로세서(118)는 GPS 칩셋(136)에 또한 커플링될 수도 있는데, 이 GPS 칩셋은 WTRU(102)의 현재 로케이션에 관한 로케이션 정보(예컨대, 경도 및 위도)를 제공하도록 구성될 수도 있다. GPS 칩셋(136)으로부터의 정보 외에도, 또는 그 정보 대신에, WTRU(102)는 기지국(예컨대, 기지국들(114a, 114b))으로부터 에어 인터페이스(116)를 통해 로케이션 정보를 수신하며 그리고/또는 둘 이상의 인근 기지국들로부터 수신된 신호들의 타이밍에 기초하여 자신의 로케이션를 결정할 수도 있다. WTRU(102)는 임의의 적합한 로케이션-결정 방법에 의해 로케이션 정보를 획득하면서도 일 실시형태와 일치하게 유지할 수도 있다는 것이 이해될 것이다.

프로세서(118)는 추가로 다른 주변장치들(138)에 커플링될 수도 있는데, 이 다른 주변장치들은 부가적인 특징들, 기능성 및/또는 유선 또는 무선 접속성을 제공하는 하나 이상의 소프트웨어 및/또는 하드웨어 모듈들을 포함할 수도 있다. 예를 들어, 주변장치들(138)은 가속도계, e-나침반, 위성 트랜시버, 디지털 카메라(사진들 또는 비디오용), 유니버셜 직렬 버스(universal serial bus, USB) 포트, 진동 디바이스, 텔레비전 트랜시버, 핸즈 프리 헤드셋, Bluetooth® 모듈, FM(frequency modulated) 라디오 유닛, 디지털 뮤직 플레이어, 미디어 플레이어, 비디오 게임 플레이어 모듈, 인터넷 브라우저 등을 포함할 수도 있다.

도 1c는 일 실시형태에 따른 RAN(104) 및 코어 네트워크(106)의 시스템도이다. 위에서 언급했듯이, RAN(104)은 에어 인터페이스(116)를 통해 WTRU들(102a, 102b, 102c)과 통신하는 E-UTRA 라디오 기술을 채용할 수도 있다. RAN(104)은 코어 네트워크(106)와 또한 통신할 수도 있다.

RAN(104)은 eNode-B들(140a, 140b, 140c)을 포함할 수도 있지만, RAN(104)은 임의의 수의 eNode-B들을 포함하면서도 일 실시형태와 일치하게 유지할 수도 있다는 것이 이해될 것이다. eNode-B들(140a, 140b, 140c)은 에어 인터페이스(116)를 통해 WTRU들(102a, 102b, 102c)과 통신하는 하나 이상의 트랜시버들을 각각 구비할 수도 있다. 하나의 실시형태에서, eNode-B들(140a, 140b, 140c)은 MIMO 기술을 구현할 수도 있다. 따라서, eNode-B(140a)는, 예를 들어, WTRU(102a)로 무선 신호들을 송신하고 그 WTRU로부터 무선 신호들을 수신하는 다수의 안테나들을 사용할 수도 있다.

eNode-B들(140a, 140b, 140c)의 각각은 특정 셀(미도시)과 연관될 수도 있고 라디오 자원 관리 판정들, 핸드오버(handover) 판정들, 업링크 및/또는 다운링크에서의 사용자들의 스케줄링 등을 핸들링하도록 구성될 수도 있다. 도 1c에 도시된 바와 같이, eNode-B들(140a, 140b, 140c)은 X2 인터페이스를 통해 서로 통신할 수도 있다.

도 1c에 도시된 코어 네트워크(106)는 이동성 관리 게이트웨이(mobility management gateway, MME)(142), 서빙 게이트웨이(144), 및 패킷 데이터 네트워크(packet data network, PDN) 게이트웨이(146)를 포함할 수도 있다. 전술한 엘리먼트들의 각각이 코어 네트워크(106)의 부분으로서 묘사되지만, 이들 엘리먼트들 중 어느 것이나 코어 네트워크 오퍼레이터 이외의 엔티티에 의해 소유되며 그리고/또는 동작될 수도 있다는 것이 이해될 것이다.

MME(142)는 S1 인터페이스를 통해 RAN(104)에서의 eNode-B들(142a, 142b, 142c)의 각각에 접속될 수도 있고 제어 노드로서 역할을 할 수도 있다. 예를 들어, MME(142)는 WTRU들(102a, 102b, 102c)의 사용자들의 인증, 베어러 활성화/불활성화, WTRU들(102a, 102b, 102c)의 초기 연결(attach) 동안의 특정 서빙 게이트웨이의 선택 등을 담당할 수도 있다. MME(142)는 RAN(104)과 다른 라디오 기술들, 이를테면 GSM 또는 WCDMA를 채용하는 다른 RAN들(미도시) 간의 스위칭을 위한 제어 평면 기능을 또한 제공할 수도 있다.

서빙 게이트웨이(144)는 S1 인터페이스를 통해 RAN(104)에서의 eNode B들(140a, 140b, 140c)의 각각에 접속될 수도 있다. 서빙 게이트웨이(144)는 사용자 데이터 패킷들을 WTRU들(102a, 102b, 102c)로/로부터 일반적으로 라우팅 및 포워딩할 수도 있다. 서빙 게이트웨이(144)는 다른 기능들, 이를테면 eNode B 간(inter-eNode B) 핸드오버들 동안의 사용자 평면들의 앵커링, 다운링크 데이터가 WTRU들(102a, 102b, 102c)에 이용가능할 때의 페이징의 트리거링, WTRU들(102a, 102b, 102c)의 콘텍스트들의 관리 및 저장 등을 또한 수행할 수도 있다.

서빙 게이트웨이(144)는 PDN 게이트웨이(146)에 또한 접속될 수도 있는데, 이 PDN 게이트웨이는, WTRU들(102a, 102b, 102c) 및 IP-가능(IP-enabled) 디바이스들 간의 통신들을 용이하게 하기 위해, 패킷 교환식 네트워크들, 이를테면 인터넷(110)에 대한 액세스를 WTRU들(102a, 102b, 102c)에 제공할 수도 있다. 무선 로컬 영역 네트워크(WLAN)(155)의 액세스 라우터(access router, AR)(150)가 인터넷(110)과 통신할 수도 있다. AR(150)은 AP들(160a, 160b, 및 160c) 간의 통신들을 용이하게 할 수도 있다. AP들(160a, 160b), 및 160c)은 STA들(170a, 170b), 및 170c)과 통신할 수도 있다.

코어 네트워크(106)는 다른 네트워크들과의 통신들을 용이하게 할 수도 있다. 예를 들어, 코어 네트워크(106)는, WTRU들(102a, 102b, 102c)과 전통적인 지상선 통신 디바이스들 간의 통신들을 용이하게 하기 위해, 회선 교환식 네트워크들, 이를테면 PSTN(108)에 대한 액세스를 WTRU들(102a, 102b, 102c)에 제공할 수도 있다. 예를 들어, 코어 네트워크(106)는 코어 네트워크(106)와 PSTN(108) 간의 인터페이스로서 역할을 하는 IP 게이트웨이(예컨대, IP 멀티미디어 서브시스템(IP multimedia subsystem, IMS) 서버)를 포함하거나 또는 그 IP 게이트웨이와 통신할 수도 있다. 덧붙여서, 코어 네트워크(106)는 WTRU들(102a, 102b, 102c)에 네트워크들(112)에 대한 액세스를 제공할 수도 있는데, 그 네트워크들은 다른 서비스 제공자들에 의해 소유된 그리고/또는 동작되는 다른 유선 또는 무선 네트워크들을 포함할 수도 있다.

인프라스트럭처 기본 서비스 세트(BSS) 모드에서의 WLAN이 그 BSS를 위한 AP와 그 AP에 연관된 하나 이상의 스테이션들(STA들)(또한 본원에서 WTRU들이라고 지칭됨)을 갖는다. 이후로 설명되는 실시형태들에서 사용되는 바와 같이, WTRU가 STA 또는 통신 디바이스를 포함할 수도 있으나 그것들로 제한되지 않는다.

BSS 안팎으로 트래픽을 운반하는 AP는 분배 시스템(DS) 또는 다른 유형의 유무선 네트워크에 통상적으로 액세스하거나 또는 인터페이싱한다. BSS 외부로부터 비롯되는 WTRU들에 대한 트래픽은 AP를 통해 도착하고 WTRU들로 전달될 수도 있다. WTRU 외부의 목적지들까지 WTRU들로부터 비롯되는 트래픽은 각각의 목적지들로 전달되기 위해 AP로 전송될 수도 있다. BSS 내의 WTRU들 간의 트래픽은 AP를 통해 또한 전송될 수도 있는데 소스 WTRU는 트래픽을 AP로 전송하고 AP는 그 트래픽을 목적지 WTRU로 전달한다. BSS 내의 WTRU들 간의 이러한 트래픽은 피어 투 피어 트래픽일 수도 있다. 이러한 피어 투 피어 트래픽은 802.11e DLS 또는 802.11z 터널링된 DLS(TDLS)를 사용하여 직접 링크 셋업(DLS)으로 소스 및 목적지 WTRU들 간에 또한 직접 전송될 수도 있다. 독립 BSS 모드에서의 WLAN이 서로 직접적으로 통신하는 AP 및 WTRU들을 갖지 않을 수도 있다.

협응형 다중-포인트(coordinated multi-point, CoMP) 송수신이, 높은 데이터 레이트들의 커버리지를 개선하기 위해, 셀-에지 스루풋을 개선하기 위해, 그리고/또는 높은 부하 시나리오 및 낮은 부하 시나리오 양쪽 모두에서 시스템 스루풋을 증가시키기 위해, LTE-A(LTE-Advanced)에 대해 고려될 수도 있다. LTE에서의 CoMP는 다운링크 또는 업링크에서 적용될 수도 있다.

공동 송신(joint transmission, JT) CoMP 체계에서, 데이터는 기지국들 간에 공유될 수도 있고, 각각의 협동(cooperating) 셀에서 이용가능하다. JT CoMP 체계가 적용됨에 따라, WTRU는 수신된 신호 대 간섭 및 잡음 비(signal to interference and noise ratio)가 개선될 수도 있는 방도로 다수의 송신 포인트들(또는 셀들)로부터 자신의 원하는 신호들을 수신할 수도 있다. 수신된 신호 대 간섭 및 잡음 비가 개선될 수도 있는 이유들은 두 가지이다. 첫 번째는 수신 신호 세기 개선으로 인한 것일 수도 있고, 두 번째는 수신된 간섭 세기 유추(deduction)로 인한 것일 수도 있다.

협응형 빔포밍/협응형 스케줄링(coordinated beamforming/coordinated scheduling, CS/CB)은 셀들 간에 임의의 데이터 공유를 필요로 하지 않을 수도 있다. 데이터는 서빙 셀에서만 이용가능할 수도 있고, 그 서빙 셀로부터만 송신될 수도 있다. 그러나, 사용자 스케줄링과 빔포밍 판정들은 협동 셀 세트에서 셀들 간의 협응(coordination)으로 이루어질 수도 있다. CS/CB CoMP를 위해, WTRU의 수신된 간섭 강도는 수신된 신호 대 간섭 및 잡음 비가 개선되는 방식으로 감소될 수도 있다는 사실로부터 잠재적 이득들이 획득될 수도 있다. CS/CB CoMP는 JT CoMP보다 더 낮은 구현예 복잡도와 더 낮은 백홀(backhaul) 용량에 대한 요건을 가질 수도 있다.

동적 송신 포인트 선택이 다운링크 CoMP라고 또한 지칭될 수도 있다. 동적 셀 선택은 임의의 주어진 순간에 하나의 송신 포인트, 예를 들어, 단일 셀만이 WTRU로 송신하는 기법이라고 지칭될 수도 있다. 송신 포인트는 동적으로 변경할 수도 있고 서빙 셀이 아닐 수도 있다. JT CoMP와 유사하게, 데이터는 기지국들 간에 공유될 수도 있고 각각의 협동 셀에서 이용가능할 수도 있다. 각각의 셀의 WTRU에 대한 순간 채널에 기초하여, 동적 선택은 어떤 셀이 WTRU로 송신할 수도 있는지를 결정하는데 사용될 수도 있다. 예를 들어, WTRU에 대한 최고 SINR을 갖는 셀은 당해 서브프레임에서 송신하기 위해 선택될 수도 있다.

업링크 CoMP에서, 셀 에지 사용자 스루풋이 상이한 셀들로부터의 신호 수신을 협응함으로써 개선될 수도 있다. 공동 수신 및 프로세싱에서, 시스템은 가상 안테나 어레이를 형성하기 위해 상이한 셀 사이트들의 안테나들을 이용할 수도 있다. 결과적인 신호들은 최종 출력 신호를 생성하기 위해 결합되고 프로세싱될 수도 있다. 이 예는 eNB들 간의 대용량 백홀을 필요로 할 수도 있다. 협응형 스케줄링에서, eNB들의 스케줄링 판정들은 간섭을 최소화하기 위해 조정될 수도 있다.

협응형 송신들은 802.11ad에서 수행될 수도 있다. 예를 들어, PBSS(personal basic service set) 내의 협응형 빔포밍이 802.11ad로 구현될 수도 있다. PBSS 중앙 포인트(PBSS central point, PCP)가 서로에 대해 지향성 송신들을 행할 의도인 한 쌍의 WTRU들에 지향성 측정을 행할 것을 요청할 수도 있는 반면, 다른 쌍의 WTRU들은 능동적으로 지향성으로 송신할 수도 있다. 그 뒤에, PCP는 지향성 측정들을 행할 것을 제 2 쌍의 WTRU들에 요청할 수도 있는 반면, 제 1 쌍의 WTRU들은 서로에 지향성으로 송신할 수도 있다. 양쪽 쌍들의 WTRU들이 서로의 송신들로부터의 간섭이 거의 없거나 또는 전혀 없음을 보고한다면, 두 쌍들의 WTRU들은 병행(concurrent) 지향성 송신들을 행하기 위해 동일한 서비스 기간(Service Period, SP)에 스케줄링될 수도 있다.

도 2는 WiFi 핫스팟 전개(200)를 위해 사용될 수도 있는 다양한 사용 사례들의 하이 레벨 도면이다. 제 1 사용 사례는 하이 계층 상호접속을 일으키는 3GPP 게이트웨이(203)를 통해 셀룰러 코어 네트워크에 상호접속된 고정된 네트워크의 사용을 포함할 수도 있다. 이 고정된 네트워크 접속이 WiFi 제어기(201)와 함께 사용될 수도 있다. WiFi 핫스팟 전개에 대한 제 2 사용 사례는 WiFi 제어기(201)로 AP들(202a, 202b, 202c)을 클러스터링할 수도 있다. WiFi 핫스팟에 대한 또 다른 사용 사례에서, 독립 실행형(stand-alone) AP(204)가 사용될 수도 있다. AP들에 연관된 WTRU들은, BSS 또는 중첩하는 BSS(overlapping BSS, OBSS)에서의 다른 WTRU들에 비하여 그 WTRU들이 허용가능한 채널 컨디션(channel conditions)을 갖지 않을 때, 또는 연관된 AP로부터 더 먼 거리에 위치될 때 열악한 다운링크(DL)/업링크(UL) 성능을 경험할 수도 있다. 예를 들어, WTRU가 AP로부터 먼 거리에 위치될 때, 그것의 스루풋 성능은 AP에 더 가까이 위치될 수도 있는 다른 WTRU들에 비하여 상당히 제한될 수도 있다.

도 3a 내지 도 3c는 제 1 실시형태에 따른 협응형 공동 송신들의 예들을 도시하는데, 이 제 1 실시형태는 WLAN BSS 또는 OBSS에서의 모든 WTRU들에 대해 더욱 균일한 DL/UL 스루풋 성능을 제공할 수도 있다. 제 1 실시형태에서, 다수의 WTRU들 또는 복수의 AP들은 동일한 수신용 WTRU 또는 AP에 대한 공동 송신을 병행하여 또는 순차적으로 중 어느 하나로 행할 수도 있다. 이는 BSS 또는 OBSS에서의 모든 WTRU들 및 AP들에 대해 더욱 균일한 성능을 가능하게 할 수도 있다. 공동 송신들은 DL 송신 및 UL 송신이 더 높은 DL 및 UL 스루풋 성능을 초래하는 더 높은 평균 레이트들에서 행해지는 것을 또한 허용할 수도 있다. 공동 송신들은 다음을 포함하는 상황들, 즉, (1) WTRU가 AP로부터 너무 먼 거리에 위치될 때; (2) WTRU와 AP 간의 순간 채널이 이동성, 제한된 전력, 페이딩, 및 간섭으로 인해 열악한 품질을 경험할 때; 또는 (3) DL/UL 스루풋이 제한될 때, 사용될 수도 있지만 그것들로 한정되지는 않을 수도 있다.

도 3a는 일 예의 협응형 다중-AP 공동 송신(300)의 하이 레벨 신호 흐름도를 도시한다. WTRU(301)가 연관될 수도 있는 AP는 연관된 AP(associated AP, AAP)(302)라고 지칭될 수도 있다. 수신용 WTRU(receiving WTRU, R-WTRU)(301)에 대한 다중-AP 송신에 참여하는 제 2 AP가 보조(assistant) AP(ATAP)(303)라고 지칭될 수도 있다. 이 예에서, AAP(302)는 데이터 패킷들(311)을 WTRU(301)로 송신할 수도 있다. ATAP(303)는 동일한 데이터 패킷들(312)을 WTRU(301)로 또한 송신할 수도 있다. 동일한 데이터 패킷들(311 및 312)을 WTRU(301)로 송신하는 것에 대한 대안으로서, AAP(302) 및 ATAP(303)로부터의 송신된 데이터 패킷들이 동일한 데이터 패킷들의 상이한 버전들일 수도 있다. 예를 들어, AAP 및 ATAP로부터의 데이터 패킷들은, 상이한 데이터 레이트들을 사용하여 코딩될, 상이한 MCS, STBC(space-time block coded), 또는 하이브리드 ARQ(hybrid ARQ, HARQ) 체계들을 사용하여 송신될 수도 있다. 도 3a의 예에서, 협응형 다중-AP 공동 송신은 병행하여 또는 순차적으로 중 어느 하나로 행해질 수도 있다. 순차 송신 체계에서, AAP(302)와 ATAP(301)는 그것들의 송신들 간에 지연을 가지고서 또는 지연 없이 수신용 WTRU(301)에 순차적으로 송신할 수도 있다.

도 3b는 AP와 적어도 하나의 WTRU가 수신용 WTRU에 다운링크에서 송신할 수도 있는 일 예의 다중-WTRU 협응형 공동 송신의 하이 레벨 신호 흐름도를 도시한다. 도 3b의 예에서, 다중-WTRU 다운링크 공동 송신이 수행된다. AAP(305)가 수신용 WTRU(301)에 대해 보조 WTRU(A-WTRU)(306)라고 지칭되는 비-AP와 공동 송신(321)을 협응할 수도 있다. AAP(305)는 데이터 패킷들을 WTRU(304)로 송신할 수도 있다(322). A-WTRU(306)는 동일한 데이터 패킷들을 WTRU(304)로 또한 송신할 수도 있다(323). 동일한 데이터 패킷들을 WTRU(304)로 송신하는 것(322 및 323)에 대한 대안으로서, AAP(305) 및 A-WTRU(306)로부터의 송신된 데이터 패킷들은 동일한 데이터 패킷들의 상이한 버전들일 수도 있다. 도 3b의 예에서, 다운링크에서 협응형 다중-WTRU 공동 송신은 병행하여 또는 순차적으로 중 어느 하나로 행해질 수도 있다. 순차 송신 체계에서, AAP(305)와 A-WTRU(306)는 그것들의 송신들 간에 지연을 가지고서 또는 지연 없이 수신용 WTRU(304)에 순차적으로 송신할 수도 있다.

도 3c는 일 예의 다중-WTRU 협응형 업링크 공동 송신의 하이 레벨 신호 흐름도를 도시한다. 도 3c의 예에서, 협응하는(coordinating) WTRU(C-WTRU)(307)라고 지칭되는 비-AP는 수신용 AP(309)에 대해 보조 WTRU(A-WTRU)(308)와 UL 공동 송신을 협응(331)할 수도 있다. C-WTRU(307)는 데이터 패킷들을 AP(309)로 송신할 수도 있다(332). A-WTRU(308)는 동일한 데이터 패킷들을 AP(309)로 또한 송신할 수도 있다(333). 동일한 데이터 패킷들을 AP(309)로 송신하는 것(332 및 323)에 대한 대체예로서, C-WTRU(307) 및 A-WTRU(308)로부터의 송신된 데이터 패킷들은 동일한 데이터 패킷들의 상이한 버전들일 수도 있다. 도 3c의 예에서, 업링크에서 협응형 다중-WTRU 공동 송신은 병행하여 또는 순차적으로 중 어느 하나로 행해질 수도 있다. 순차 송신 체계에서, C-WTRU(307)와 A-WTRU(308)는 그것들의 송신들 간에 지연을 가지고서 또는 지연 없이 수신용 AP(309)에 순차적으로 송신할 수도 있다.

도 4는 AP 또는 WTRU가 제 1 실시형태(400)에 따라 공동 송신 능력 표시로서 사용할 수도 있는 공동 송신 능력 정보 엘리먼트(IE)의 일 예를 도시한다. AP 또는 WTRU가 자신의 비콘에서 또는 프로브 요청/응답 프레임, 연관 요청/응답 프레임, 액션 프레임, 또는 액션 ACK 없음(no ACK) 프레임을 비제한적으로 포함하는 다른 관리 또는 제어 프레임에서 공동 송신 능력 IE를 사용하여 다중-AP 또는 다중-WTRU 공동 송신에 대한 자신의 능력을 표시할 수도 있다. WTRU가 공동 송신 능력 IE를 포함하는 관리 또는 제어 프레임을 전송하는 것에 의해 공동 송신을 할 수 있다는 것을 또한 표시할 수도 있다.

도 4의 공동 송신 능력 정보 엘리먼트(IE) 설계 예는 다음의 필드들, 즉 엘리먼트 ID 필드(401), 길이 필드(402), 및 공동 송신 능력 필드(403)를 포함할 수도 있다.

엘리먼트 ID 필드(401)는 IE가 공동 송신 능력 IE임을 표시할 수도 있다. 길이 필드(402)는 공동 송신 능력 IE의 길이를 포함할 수도 있다. 공동 송신 능력 필드(403)는 디바이스가 공동 송신 가능(capable)임을 표시할 수도 있다. 공동 송신 능력 필드(403)에 대한 예의 표시들은 아래의 표 1에 도시되어 있다.

표시	설명
연관된 AP 공동 송신 가능	AAP로서 공동 송신이 가능
보조 AP 공동 송신 가능	ATAP로서 공동 송신이 가능
보조 WTRU(A-WTRU) 공동 송신 가능	A-WTRU로서 공동 송신을 행하는 것이 가능
보조 AP 협응(Coordination) 가능	공동 송신에 대해 AAP와 협응을 행하는 것이 가능
보조 WTRU(A-WTRU) 협응 가능	공동 송신에 대해 A-WTRU와 협응을 행하는 것이 가능
병행 공동 송신 가능	병행 공동 송신이 가능
순차 공동 송신 가능	STBC 가능 상이한 MCS 가능 HARQ 가능 상이한 채널 코딩 가능
병행 공동 송신 수신 가능	공동 송신의 수신이 가능
순차 공동 송신 수신 가능	STBC 수신 가능 상이한 MCS 수신 가능 HARQ 수신 가능 상이한 채널 코딩 수신 가능
공동 송신 협응 옵션들	DS(Distribution System)를 통한 협응 가능 무선을 통한 협응 가능 협응 제어 송신 포맷: 이더넷, 802.11 레거시/a/b/g/n/ac/af/ah, X-1, UMTS, LTE, WiMAX 등 협응 제어 송신 대역 및 채널: 802.11af 및 802.11ah에 대한 1 GHz 아래, 2.4 GHz, 5 GHz, 60 GHz 등과 같은 주파수 대역들뿐 아니라 채널 번호들
데이터/제어 포워딩 옵션들	TDLS(Tunneled Direct Link Setup) DLS(Direct Link Setup) OCT(On Channel Transfer) 공동 송신 포워딩: 공동 송신들에 연관된 데이터 및 제어 패킷들을 포워딩하기 위해 특수하게 설계된 포워딩 방법 DS를 통한 데이터/제어 포워딩 가능 무선을 통한 데이터/제어 포워딩 가능 데이터/제어 포워딩 송신 포맷: 이더넷, 802.11 레거시/a/b/g/n/ac/af/ah, X-1, UMTS, LTE 등 데이터/제어 포워딩 송신 대역 및 채널: 802.11af 및 802.11ah에 대한 1 GHz 아래, 2.4 GHz, 5 GHz, 60 GHz 등과 같은 주파수 대역들뿐 아니라 채널 번호들

표 1에서 설계된 바와 같은 공동 송신 능력 표시가 IE로서 설명되지만, 본원에서 설명되는 엘리먼트들의 임의의 필드, 서브필드, 또는 서브세트가 구현될 수도 있다. IE는 관리 프레임, 제어 프레임, 데이터 프레임, 또는 임의의 다른 유형의 프레임의 임의의 부분일 수도 있다. 공동 송신 능력 표시는, 물리 계층 수렴 절차(Physical Layer Convergence Procedure, PLCP) 또는 매체 액세스 제어(medium access control, MAC) 헤더, 프레임 바디(body), 스크램블러 초기화 시드(seed)들 등의 임의의 부분을 비제한적으로 포함할 수도 있는 모든 명시적 및 암시적 시그널링을 포함할 수도 있다.

도 5a는 협응형 공동 송신을 위해 사용되는 일 예의 제어 정보 교환(500)의 하이 레벨 신호 흐름도를 도시한다. 도 5a의 예에서, AAP(502)와 ATAP(503)는 위에서 설명된 바와 같은 다중-AP 공동 송신을 행할 것을 준비하기 위해 제어 정보(511a 및 511b)를 교환할 수도 있다. 제어 정보(511a)는 공동 송신 요청을 포함할 수도 있다. 제어 정보(511b)는 공동 송신 응답을 포함할 수도 있다. 부가적으로 또는 대안으로, AAP(502)는 데이터 패킷들(512)을 ATAP(503)로 포워딩할 수도 있다. AAP(502)와 ATAP(503)는 그 다음에 데이터 패킷들(513a 및 513b)을 수신용 WTRU(501)에 공동 송신 세션에서 송신할 수도 있다. 협응 정보의 상호교환뿐만 아니라 연관된 데이터 패킷들의 포워딩은 적어도 2 개 방도들로 일어날 수도 있다. 첫째, 그것들은 다른 WLAN, UMTS, LTE, WiMAX 인터페이스를 비제한적으로 포함하는 동일한 또는 별개의 무선 인터페이스들을 사용하여 무선으로 송신될 수도 있다. 둘째, 그것들은 유선 백홀 링크를 통해 송신될 수도 있다. 제어 정보는 도 5a에 도시된 동일한 절차를 사용하여 다중-WTRU 협응형 공동 송신을 위해 WTRU들 간에 그리고 AP들 및 WTRU들 간에 교환될 수도 있다.

도 5b는 AAP 및 ATAP 간에 협응을 행하기 위해 그리고 협응 제어 정보를 송신하기 위해 사용될 수도 있는 일 예의 공동 송신 요청 IE를 도시한다. 공동 송신 요청 IE가 다음의 필드들 및/또는 정보, 즉, 엘리먼트 ID 필드(521), 길이 필드(522), ID 필드(523), 옵션 필드(524), 스케줄 필드(525), 송신 사양(TxSpec) 필드(526), 및 요청 유형 필드(527)를 비제한적으로 포함할 수도 있다.

엘리먼트 ID 필드(521)는 IE가 공동 송신 요청 IE라는 것을 표시할 수도 있다. 길이 필드(522)는 공동 송신 요청 IE의 길이를 포함할 수도 있다.

ID 필드(523)는 아래의 표 2에 도시된 하나 이상의 ID들을 포함할 수도 있다. ID(들)는 MAC 어드레스, BSSID, SSID, AID, 또는 WTRU들이 합의할 수도 있는 임의의 다른 유형의 ID들로서 구현될 수도 있다.

예의 ID	설명
공동 송신의 수신자인 수신용 WTRU들	공동 송신에서 데이터 패킷들을 수신하는 WTRU(들)의 ID
요청하는 AAP	요청하는 AAP의 ID
요청되는 ATAP	요청된 ATAP의 ID
세션 ID	특정 수신용 WTRU에 대해 특정 공동 송신 세션을 식별하는 또는 특정 AAP에 의해 요청된 시퀀스 번호

옵션 필드(524)는 공동 송신들에 대한 다양한 옵션들을 포함할 수도 있다. 옵션 필드의 예의 내용들이 표 3에 도시되어 있다.

예의 옵션들	설명
공동 송신 패킷 수	그 패킷 수는 공동 송신 세션들 동안 송신될 것으로 예상될 수도 있다
공동 송신 패킷들의 사이즈/시간/TXOP	공동 송신 패킷들의 사이즈는 바이트수(bytes)로, 송신 시간으로, 또는 마이크로초 또는 임의의 다른 시간 단위들로 표현된 TXOP로 특정될 수도 있다
공동 송신 세션에 대해 예상된 데이터 레이트(또는 MCS)	공동 송신에서 사용될 데이터 레이트(또는 MCS)
공동 송신 세션의 지속기간	공동 송신에서 사용될 지속기간
병행 공동 송신	ATAP는 병행 공동 송신을 행할 수도 있다
순차 공동 송신	ATAP는 순차 공동 송신을 행할 수도 있다. ATAP는 자신과 수신용 WTRU 간의 채널 컨디션(conditions) 및/또는 자신 소유의 송신 능력들에 따라 AAP에 의해 자신에게 포워딩된 데이터 패킷들을 포함하는 PPDU 또는 PSDU 프레임들을 구성하기 위해 다음의 사양들 중 하나 이상을 사용할 수도 있다. 이들 사양들은 STBC, 상이한 MCS, HARQ, 및 상이한 채널 코딩을 포함할 수도 있다.
스케줄링된 공동 송신	ATAP는 AAP에 의해 특정된 스케줄에 따라 스케줄링된 시간에 송신을 행할 수도 있다.
협응 정보 포워딩 옵션	■ TDLS ■ DLS ■ OCT ■ 공동 송신 포워딩: 공동 송신들에 연관된 데이터 및 제어 패킷들을 포워딩하기 위해 설계될 수도 있는 포워딩 방법 ■ 분배 시스템(DS)을 통한 포워딩 ■ 무선을 통한 포워딩 ■ 포워딩 송신 포맷: 이더넷, 802.11 레거시/a/b/g/n/ac/af/ah, X-1, UMTS, LTE 등 ■ 포워딩 송신 대역 및 채널: 802.11af 및 802.11ah에 대한 1 GHz 아래, 2.4 GHz, 5 GHz, 60 GHz 등과 같은 주파수 대역들뿐만 아니라 채널 번호들
데이터 포워딩 옵션들	■ TDLS ■ DLS ■ OCT ■ 공동 송신 포워딩: 공동 송신들에 연관된 데이터 및 제어 패킷들을 포워딩하기 위해 설계될 수도 있는 포워딩 방법 ■ DS를 통한 포워딩 ■ 무선을 통한 포워딩 ■ 포워딩 송신 포맷: 이더넷, 802.11 레거시/a/b/g/n/ac/af/ah, X-1, UMTS, LTE 등 ■ 포워딩 송신 대역 및 채널: 802.11af 및 802.11ah에 대한 1 GHz 아래, 2.4 GHz, 5 GHz, 60 GHz 등과 같은 주파수 대역들뿐만 아니라 채널 번호들
매체 액세스 제어 옵션들	CTS 포워딩 옵션들: 위에서 설명된 바와 같은 협응 정보 포워딩과 유사

TxSpec 필드(506)는 공동 송신들에 연관될 수도 있는 송신 사양들을 포함할 수도 있다. TxSpec 필드(506)의 예의 내용들이 표 4에 도시되어 있다. TxSpec는 그것이 PHY 서비스 기본요소(primitive), TXVECTOR와 유사할 수도 있거나, 또는 그것이 TXVECTOR의 수정된 버전일 수도 있고 MCS, 송신 전력, 채널 매트릭스, 및/또는 사전-코딩 매트릭스 등을 특정할 수도 있도록 구현될 수도 있다. 순차 공동 송신이 사용될 때, AAP는 MAC 프로토콜 데이터 단위(MAC protocol data unit, MPDU)를 구성하는 방법에 관해 ATAP를 위한 TxSpec, 이를테면 프레임 체크 시퀀스(frame check sequence, FCS) 길이, 어드레스 필드 값들 등을 포함할 수도 있다. ATAP는 TxSpec과 AAP로부터 수신된 포워딩된 패킷들에 기초하여 PLCP 헤더 및 연관된 PLCP 서비스 데이터 단위(PLCP service data unit, PSDU)들/PLCP 프로토콜 데이터 단위(PLCP protocol data unit, PPDU)들을 구성할 수도 있다.

예의 TxSpec	설명
채널 액세스 방법	■ 스케줄링됨 ■ 경합 기반 ■ AAP에 의해 시그널링됨
AAP 송신 사양들	■ AAP가 원래의 데이터 패킷, 이를테면 MCS, 송신 전력, 채널 매트릭스, 사전-코딩 매트릭스 등을 송신할 수도 있는 다양한 송신 사양들 ■ ATAP는 AAP의 송신 사양들과 ATAP 및 수신용 WTRU 간의 채널 컨디션에 기초하여 공동 송신 세션에서 패킷들을 수신용 WTRU들로 송신하기 위해 자신의 가장 최적의 셋팅을 결정할 수도 있다.

스케줄 필드(505)의 예의 내용들이 표 5에 도시되어 있다.

예의 스케줄	설명
스케줄링된 시작	공동 송신 세션의 스케줄링된 시작 시간; 그 시간은 AP, 그리니치 평균시(Greenwich Mean Time, GMT) 또는 임의의 다른 기준 클록 중 어느 하나의 TSF 타이머를 기준으로 할 수도 있다.
스케줄링된 송신 시간들	공동 송신 패킷들의 스케줄링된 송신 시간들; 그 시간들은 AP, GMT 또는 임의의 다른 기준 클록 중 어느 하나의 TSF 타이머를 기준으로 할 수도 있다.
스케줄링된 주파수	얼마나 자주 공동 송신이 일어날 수도 있나
스케줄링된 종료	공동 송신 세션의 스케줄링된 종료
현재 TSF 타이머	AAP의 현재 TSF 타이머; 이 스케줄에서의 시간들은 AAP의 TSF 타이머를 기준으로서 사용할 수도 있다. 대안으로, 기준 클록은 이 필드 역시 사용하여 특정될 수도 있다.
추정된 상호 클록 드리프트	이 서브필드는 기준 클록과 ATAP에서의 국소 클록 간의 추정된 클록 드리프트를 포함할 수도 있다. 추정된 클록 드리프트는 비콘들, 짧은 비콘들, 동기 패킷들, 또는 클록 기준 시간을 포함할 수도 있는 임의의 다른 유형들의 프레임들을 모니터링하는 것에 의해 또한 추정될 수도 있다.

요청 유형 필드(507)의 예의 내용들이 표 6에 도시되어 있다.

예의 요청	설명
새로운 공동 송신 요청
공동 송신 요청 갱신	현재 또는 이전 공동 송신 세션 요청의 갱신
종료	공동 송신 세션의 종료.

비록 공동 송신 요청이 도 5b에서 IE의 형태로 설명되었지만, 논의된 엘리먼트들의 임의의 필드, 서브필드, 또는 서브세트가 관리 프레임, 제어 프레임, 데이터 프레임, 또는 임의의 다른 유형의 프레임의 임의의 부분으로서 구현될 수도 있다. 이들 프레임들은 모든 명시적 및 암시적 시그널링, 이를테면 PLCP/MAC 헤더, 프레임 바디, 및/또는 스크램블러 초기화 시드들 등의 임의의 부분을 포함할 수도 있다. 공동 송신 요청은, 예를 들어, LTE, UMTS, 임의의 WiFi 표준들, 및 이더넷 등과 같은 다른 유형들의 통신 시스템들에서 프레임들 또는 프레임들의 필드들로서 또한 구현될 수도 있다. 예를 들어, 그것은, 프레임이 공동 송신 프로토콜을 포함할 수도 있거나 또는 다중-AP 송신 프로토콜 프레임들에 관련될 수도 있다는 것을 나타내기 위해 페이로드 유형이 4 또는 4 ~ 255 사이의 임의의 다른 수들로 설정된 Ethertype 89-0d를 사용하여 구현될 수도 있다. 포함된 프레임이 서브유형 공동 송신 요청 패킷(Joint Transmission Request Packet, JDReq)일 수도 있음을 표시하기 위해 부가적인 필드들이 포함될 수도 있다. 세션 ID들은 하나 이상의 수신용 WTRU들에 대해 특정 공동 송신 세션을 식별할 수도 있다. 수신용 WTRU들은 수신용 WTRU들의 세트일 수도 있다. 프레임의 ID, 예를 들어, 세션 ID에 의해 식별된 공동 송신 세션에서의 패킷의 시퀀스 번호, AAP의 ID, 및/또는 ATAP의 ID가 부가적인 필드로서 포함될 수도 있다.

도 6은 AAP로부터의 제어 정보에서 공동 송신 요청을 수신한 후 ATAP가 AAP로 송신할 수도 있는 공동 송신 응답 IE(600)의 일 예를 도시한다. 공동 송신 응답 IE는 그것의 개개의 프레임, 관리 프레임, 제어 프레임, 또는 공동 송신 응답 IE를 포함할 수도 있는 임의의 다른 유형의 프레임에 포함될 수도 있다. 공동 송신 응답 IE는 다음의 필드들 및/또는 정보, 즉, 엘리먼트 ID 필드(601), 길이 필드(602), ID 필드(603), 및 결과 필드(604)를 비제한적으로 포함할 수도 있다.

엘리먼트 ID 필드(601)는 IE가 공동 송신 응답 IE라는 것을 표시할 수도 있다. 길이 필드(602)는 공동 송신 응답 IE의 길이를 포함할 수도 있다. ID 필드(603)는 공동 송신의 수신자일 수도 있는 수신용 WTRU들의 하나 이상의 ID들을 포함할 수도 있다. ID 필드의 예의 내용들이 표 7에 도시되어 있다. ID(들)는 MAC 어드레스, BSSID, SSID, AID, 또는 WTRU들이 합의할 수도 있는 임의의 다른 유형의 ID로서 구현될 수도 있다.

예의 ID	설명
요청하는 AAP
요청되는 ATAP
세션 ID	특정 수신용 WTRU에 대해 특정 공동 송신 세션을 식별하는 또는 특정 AAP에 의해 요청된 시퀀스 번호
프레임의 ID	예를 들어, 공동 송신 세션에서 세션 ID에 의해 식별된 패킷의 시퀀스 번호.

결과 필드(604)의 예의 내용들이 표 8에 도시되어 있다.

예의 결과	설명
수락	ATAP는 공동 송신 요청 프레임에 의해 특정된 바와 같은 요청된 공동 송신 세션에 참여할 수도 있다.
거부	ATAP는 공동 송신 요청 프레임에 의해 특정된 바와 같은 요청된 공동 송신 세션에 참여하지 않을 수도 있다. 거부에 대한 예의 이유들은 다음 중 하나 이상을 포함할 수도 있다: 공동 송신 능력 없음, 수신용 WTRU에 대한 링크 없음, 허용불가 TxSpec, 임시 불능(disabling) 공동 송신, 높은 트래픽 부하/혼잡, 미지의 수신용 WTRU, 허용불가 스케줄, 상황 변경 그리고 ATAP는 공동 송신 세션을, 그리고/또는, 아무것도 더 이상 수용할 수 없다.

도 7a는 AP들에서의 공동 송신 능력들을 결정하고 공동 송신을 준비하는 일 예의 흐름도(700)를 도시한다. 도 7a의 예에서, AAP(702)는 자신의 공동 송신(JT) 능력들(711)에 대해 그리고/또는 공동 송신들을 위해 트리거되는 하나 이상의 WTRU들에 연관된 자신의 채널 컨디션(712)에 대해 다른 AP 또는 ATAP(703)에 질의(query)할 수도 있다. ATAP(703)는 공동 송신 피드백(713)으로 응답할 수도 있다. WTRU(701)는 그러면 AAP(702)로부터 계류중인(pending) 공동 송신 세션의 통지(714)를 수신할 수도 있다. 공동 송신들의 수신에 참여하기 전의 WTRU(701)는 공동 송신 능력 표시(715a 및 715b)를 임의의 관리 프레임, 제어 프레임, 또는 프로브 요청, 연관 요청 등과 같은 임의의 다른 유형의 프레임에서 AAP(702) 및/또는 ATAP(703)에 송신하는 것에 의해 자신의 공동 송신 및 수신 능력을 표시할 수도 있다. 대안으로, 병행 공동 송신이 행해진다면, 공동 송신 세션은 수신용 WTRU에 대해 투명하게 일어날 수도 있다. WTRU(701)는 자신이 순차 공동 송신들을 수신할 수 있음을 또한 표시할 수도 있다.

AAP는 공동 송신 질의 프레임 또는 ATAP의 JT 능력들을 질의하기 위한 공동 송신 질의 IE를 포함하는 임의의 유형의 프레임을 사용할 수도 있다. 도 7b는 공동 송신 질의 IE의 일 예를 도시한다. 공동 송신 질의 IE는 다음의 필드들 및/또는 정보, 즉, 엘리먼트 ID 필드(721), 길이 필드(722), ID 필드(723), 및 옵션 필드(724)를 비제한적으로 포함할 수도 있다.

엘리먼트 ID 필드(721)는 IE가 공동 송신 질의 IE라는 것을 표시할 수도 있다. 길이 필드(722)는 공동 송신 질의 IE의 길이를 포함할 수도 있다.

ID 필드(723)는 AAP가 질의하는 수신용 WTRU들의 하나 이상의 ID들을 포함할 수도 있다. ID(들)는 MAC 어드레스, BSSID, AID, 또는 WTRU들이 합의할 수도 있는 임의의 다른 유형의 ID로서 구현될 수도 있다. 공동 송신 질의 프레임이 AP의 공동 송신 능력을 질의하려는 것이라는 것을 표시하기 위해 사전 확립된 일반 ID 또는 질의되고 있는 AP의 ID가 사용될 수도 있다.

옵션 필드(724)는 요청된 피드백의 내용에 관한 정보를 포함할 수도 있고 표 9에 도시된 표시들을 포함할 수도 있다.

예의 표시	설명
채널 피드백	조회되고 있는 AP와 수신용 WTRU 간에 압축되거나 또는 압축되지 않았다
공동 송신의 능력들	공동 송신의 능력들을 나타낸다
채널 피드백	조회하는 AP와 질의되고 있는 WTRU 간에 압축되거나 또는 압축되지 않았다
바람직한 공동 송신 파라미터들	조회되고 있는 AP는 바람직한 공동 송신 옵션들뿐만 아니라 TxSpec을 제공할 수도 있다. 바람직한 TxSpec은 각각의 수신용 WTRU를 위한 것일 수도 있다. 바람직한 공동 송신 옵션들은 공동 송신 요청 IE를 위해 설명되는 것일 수도 있다.

AAP는 공동 송신 피드백 프레임 또는 AAP에 의한 JT 능력들 질의에 대응하기 위해 공동 송신 피드백 IE를 포함하는 임의의 유형의 프레임을 사용할 수도 있다. 도 7c는 공동 송신 피드백 IE의 일 예를 제공한다. 공동 송신 피드백 IE는 다음의 필드들 및/또는 정보, 즉, 엘리먼트 ID 필드(731), 길이 필드(732), 옵션 필드(733), 및 피드백 프레임(734)을 비제한적으로 포함할 수도 있다.

엘리먼트 ID 필드(731)는 IE가 공동 송신 피드백 IE라는 것을 표시할 수도 있다. 길이 필드(732)는 공동 송신 피드백 IE의 길이를 포함할 수도 있다. 옵션 필드(733)는 송신용 AP에 대한 공동 송신 능력들 및 바람직한 공동 송신 옵션들을 포함할 수도 있다.

피드백 필드(734)는 하나 이상의 WTRU들의 피드백을 포함할 수도 있다. 피드백 필드(734)의 예의 내용들이 표 10에 도시되어 있다.

예의 피드백	설명
피드백 필드 수	포함된 피드백 필드들의 수
피드백 필드 1 - N	■ ID: 피드백 필드가 질의하는 AP를 위한 피드백을 포함한다면 질의하는 AP의 ID 또는 질의하는 AP에 의해 질의된 수신용 WTRU의 ID; 이는 MSC 어드레스들, AID, 또는 WTRU들이 합의하는 임의의 다른 유형의 ID들로서 구현될 수도 있다 ■ 송신용 AP와 ID 필드에서 표시된 WTRU 간의 채널 피드백 ■ 이 WTRU에 대한 바람직한 공동 송신 옵션들 ■ 이 WTRU에 대한 바람직한 공동 송신 TxSpec

AAP는, 일단 AAP와 ATAP가 공동 송신 세션(joint transmission session, JTS)에 합의하면 계류중인 JTS를 수신용 WTRU에 통지하기 위해 공동 송신 통지 프레임 또는 공동 송신 통지 IE 또는 그것의 필드들 또는 서브필드들을 포함하는 임의의 유형의 프레임을 사용할 수도 있다. 이 통지는, 수신용 WTRU가 2 개를 초과하는 AP들로부터 유사한 또는 관련된 데이터를 수신하고 있다고 알고 있을 수도 있는 불투명 JTS에서 수신용 WTRU에 의해 사용될 수도 있다. 예를 들어, 불투명 JTS에서, AAP와 ATAP는 특정 데이터 패킷에 연관되지만 헤더에서의 상이한 TA 어드레스들과도 연관될 수도 있는 MPDU들을 송신할 수도 있다. 수신용 WTRU가 절전을 위해 활동중지(sleep) 상태에 들어가지 않도록 수신용 WTRU에 계류중인 스케줄링된 공동 송신을 통지하는 것이 또한 중요할 수도 있다.

도 7d는 공동 송신 통지 IE의 일 예의 설계를 도시한다. 공동 송신 통지 IE는 다음의 필드들 및/또는 정보, 즉, 엘리먼트 ID 필드(741), 길이 필드(742), 수신용 WTRU(R-WTRU) 필드(743), ATAP/A-WTRU 필드(744), 참조 필드(745), 및 공동 송신(JT) 옵션 필드(746)를 비제한적으로 포함할 수도 있다.

엘리먼트 ID 필드(741)는 IE가 공동 송신 통지 IE라는 것을 표시할 수도 있다. 길이 필드(742)는 공동 송신 통지 IE의 길이를 포함할 수도 있다. 참조 필드(745)는 계류중인 JTS에 대한 하나 이상의 참조들, 이를테면 JTS의 ID 또는 시퀀스 번호를 포함할 수도 있다.

R-WTRU 필드(743)는 JTS에 대해 R-WTRU들의 하나 이상의 ID들을 포함할 수도 있다. 그 ID들은 MAC 어드레스들, AID들 등으로서 구현될 수도 있다. 의도된 R-WTRU들의 ID들 또는 어드레스들이 MAC 헤더에서 그룹 또는 개개의 어드레스로서 이미 포함될 수도 있을 때, R-WTRU 필드(743)는 프레임에 포함되지 않을 수도 있다.

ATAP 필드(744)는 계류중인 JTS에 대해 수신용 WTRU(R-WTRU)에 할당된(assigned) ATAP의 하나 이상의 ID들을 포함할 수도 있다. 그 ID들은 MAC 어드레스들, BSSID들, SSID들, AID들 등으로서 구현될 수도 있다.

JT 옵션 필드(746)는 공동 송신들에 대한 다양한 옵션들을 포함할 수도 있다. JT 옵션 필드(746)의 예의 내용들이 표 11에 도시되어 있다.

예의 JT 옵션	설명
공동 송신 패킷 수	공동 송신 세션들 동안 송신될 것으로 예상될 수도 있는 패킷들의 수.
공동 송신 패킷들/시간/TXOP의 사이즈	공동 송신 패킷들의 사이즈는 바이트수로, 송신 시간으로, 또는 마이크로초 또는 임의의 다른 시간 단위들로 표현된 TXOP로 특정될 수도 있다
공동 송신 세션에 대해 예상된 데이터 레이트(또는 MCS)	JTS를 위해 사용되는 데이터 레이트(또는 MCS)
공동 송신 세션의 지속기간	JTS를 위해 사용되는 지속기간
병행 공동 송신	ATAP는 병행 공동 송신을 행할 수도 있다
순차 공동 송신	ATAP는 순차 공동 송신을 행할 수도 있다. ATAP는 자신과 수신용 WTRU 간의 채널 컨디션(conditions) 및/또는 자신 소유의 송신 능력들에 따라 AAP에 의해 자신에게 포워딩된 데이터 패킷들을 포함하는 PPDU 또는 PSDU 프레임들을 구성하기 위해 다음의 사양들 중 하나 이상을 사용할 수도 있다. 예의 사양은 STBC, 상이한 MCS, HARQ, 및/또는 상이한 채널 코딩을 포함할 수도 있다.
스케줄링된 공동 송신	ATAP는 AAP에 의해 특정된 스케줄에 따라 스케줄링된 시간에 공동 송신을 행할 수도 있다.
TxSpec	공동 송신들에 연관되는 송신 사양들: ■ TxSpec은 TXVECTOR와는 유사하게 또는 TXVECTOR의 수정된 버전으로서 구현될 수도 있고 MCS, 송신 전력, 채널 매트릭스, 사전-코딩 매트릭스 등을 특정할 수도 있다. ■ 순차 공동 송신이 사용되면, AAP는 MPDU를 구성하는 방법에 관해 ATAP를 위한 TxSpec, 이를테면 FCS 길이, 어드레스 필드 값들 등을 포함할 수도 있다 ■ ATAP는 TxSpec과 AAP로부터 수신된 포워딩된 패킷들에 기초하여 PLCP 헤더 및 연관된 PSDU들/PPDU들을 구성할 수도 있다 ■ 채널 액세스 방법: AAP에 의한 스케줄링, 경합 기반, 또는 시그널링됨을 포함할 수도 있다 ■ AAP 송신 사양들: o AAP가 MCS, 송신 전력, 채널 매트릭스, 사전-코딩 매트릭스 등과 같은 원래의 데이터 패킷을 송신하는 다양한 송신 사양들 o ATAP는 AAP의 송신 사양들과 ATAP 및 수신용 WTRU 간의 채널 컨디션에 기초하여 공동 송신 세션에서 패킷들을 수신용 WTRU들로 송신하기 위해 자신의 가장 최적의 셋팅들을 결정할 수도 있다
스케줄	■ 스케줄링된 시작: 공동 송신 세션의 스케줄링된 시작 시간; 이 시간은 AP, GMT 또는 임의의 다른 기준 클록 중 어느 하나의 TSF 타이머를 기준으로 할 수도 있다 ■ 스케줄 송신 시간들: 공동 송신 패킷들의 스케줄링된 송신 시간들; 이 시간들은 AP, GMT 또는 임의의 다른 기준 클록 중 어느 하나의 TSF 타이머를 기준으로 할 수도 있다 ■ 스케줄링된 주파수: 얼마나 자주 공동 송신이 일어나는가 ■ 스케줄링된 종료: 공동 송신 세션의 스케줄링된 종료 ■ 현재 TSF 타이머: AAP의 현재 TSF 타이머; 이 스케줄에서의 시간들은 AAP들의 TSF 타이머를 기준으로서 사용할 수도 있다. 대안으로, 기준 클록은 이 필드 역시 사용하여 특정될 수도 있다.

비록 도 7b 내지 도 7d의 다양한 공동 송신 프레임들의 예가 IE의 형태로 설명되지만, 논의되는 엘리먼트들의 임의의 필드 또는 서브필드 또는 서브 세트는 관리 프레임, 제어 프레임, 데이터 프레임, 또는 다른 유형의 프레임의 임의의 부분으로서 구현될 수도 있다. 이들 프레임들은 모든 명시적 및 암시적 시그널링, 이를테면 PLCP/MAC 헤더, 프레임 바디, 및/또는 스크램블러 초기화 시드들 등의 임의의 부분을 포함할 수도 있다. 공동 송신 프레임들은 다른 유형의 통신 시스템, 예를 들어, LTE, UMTS, 임의의 WiFi 표준, 및/또는 이더넷 등에서, 프레임들, 또는 프레임들의 필드들로서 또한 구현될 수도 있다. 예를 들어, 프레임은 그것이 공동 송신 프로토콜 관련된 프레임들 또는 다중-AP 송신 프로토콜 관련된 프레임들을 포함한다는 것을 나타내기 위해 페이로드 유형이 4 또는 4 ~ 255 사이의 임의의 다른 수들로 설정된 Ethertype 89-0d를 사용하여 구현될 수도 있다. 포함된 프레임이 서브유형 공동 송신 데이터 패킷들(subtype joint transmission data packets, JTDP)을 가짐을 표시하기 위해 부가적인 필드들, 즉 수신용 WTRU들(의 세트)가 특정 공동 송신 세션을 식별하게 하는 하나 이상의 세션 ID들, AAP의 ID, ATAP의 ID, 및/또는 R-WTRU의 ID가 포함될 수도 있다.

도 8은 공동 송신 세션 동안 수신용 WTRU로 전송되기 위해 AAP로부터 ATAP로 전송될 수도 있는 데이터 패킷(800)의 일 예를 도시한다. 이들 패킷들은 공동 송신 데이터 패킷들(JTDP)이라고 지칭될 수도 있다. JTDP는 유형 데이터를 반드시 갖는 것은 아닐 수도 있다. 그러나, 그것들은 데이터 패킷들이라고 지칭될 수도 있는데 그것들이 공동 송신 세션들 동안 수신용 WTRU로 송신되는 패킷들이라서이다. JTDP는 다음의 필드를 비제한적으로 포함할 수도 있다: 포함된 프레임이 서브유형 JTDP를 가질 수도 있다는 것을 표시할 수도 있는 서브유형 ID 필드(801), 하나 이상의 수신용 WTRU들이 특정 공동 송신 세션을 식별하게 하는 하나 이상의 세션 ID 필드들(802), AAP ID 필드(803), 및/또는 ATAP/A-WTRU ID 필드(804).

도 8에 도시된 바와 같은 JTDP는 그 유형의 MAC 프로토콜 데이터 단위들(MPDU들) 또는 MAC 서비스 데이터 단위(MAC service data unit; MSDU)들일 수도 있다. JTDP는 또한, 자신의 프레임 바디에 MPDU/MSDU들을 갖는 프레임의 다른 유형들일 수도 있다. JTPD들은 LTE, UMTS, 임의의 WiFi 표준들, 및/또는 이더넷 등을 비제한적으로 포함하는 다른 유형의 통신 시스템에서, 프레임들, 또는 프레임들의 필드들로서 또한 구현될 수도 있다. 예를 들어, 프레임들은 그것들이 공동 송신 프로토콜 프레임들 또는 다중-AP 송신 프로토콜 데이터 프레임들을 포함한다는 것을 나타내기 위해 페이로드 유형이 6 또는 4 ~ 255 사이의 임의의 다른 수들로 설정된 Ethertype 89-0d를 사용하여 구현될 수도 있다.

병행 공동 송신이 사용될 때, AAP는 위에서 설명된 방법들에 따라 사용될 원래의 MPDU들 및 송신 사양들을 ATAP에 포워딩할 수도 있다. 원래의 MPDU들은 공동 송신 동안 AAP가 수신용 WTRU들에 송신하고 있을 수도 있는 것들과 동일할 수도 있다. 병행 공동 송신에서, AAP 및 ATAP 양쪽 모두는 MAC 헤더들에서 어드레스 필드들을 포함한 동일한 PPDU들을 송신할 수도 있다.

순차적 또는 스케줄링된 공동 송신이 사용될 때, AAP와 ATAP는 위에서 설명된 방법들에 따라 상이한 PPDU들을 송신할 수도 있다. AAP는 AAP 및/또는 ATAP를 위한 송신 사양들과 함께 원래의 MSDU들을 ATAP에 포워딩할 수도 있다. AAP는 공동 송신 세션 동안 송신할 때 ATAP를 위한 송신 사양을 결정할 수도 있다. 대안으로 또는 부가적으로, ATAP는 자신과 수신용 WTRU 사이의 채널 컨디션 및/또는 AAP에 의해 사용되는 송신 사양들에 기초하여 자신 소유의 송신 사양들을 결정할 수도 있다.

도 9는 협응형 공동 송신을 가능하게 하기 위해 AP 또는 WTRU와 RSNA(Robust Security Network Association)를 인증하고 확립하는 일 예의 절차(900)의 흐름도를 도시한다. WTRU가 송신용 AP와 연관되지 않는 한, WTRU 또는 AP가 802.11 인터페이스를 통한 데이터 프레임과 같은 클래스 3 패킷을 수신하지 못할 수도 있다. 그러므로 AAP가 JTDP를 ATAP 또는 A-WTRU로 포워딩하지 못할 수도 있거나, 또는 수신용 WTRU가 ATAP 또는 A-WTRU에 연관되지 않는 한 수신용 WTRU가 그 ATAP 또는 A-WTRU에 의해 자신에게 전송된 패킷을 받지 못할 수도 있다. 802.11ad에서 정의된 바와 유사한 방도로 상태 4로 전환하는 것은 AAP, ATAP, A-WTRU, C-WTRU, 및 수신용 WTRU 간에 모든 클래스들의 프레임들의 송신 및 수신을 가능하게 할 수도 있다. 예의 절차에서, AAP가 다른 AP 또는 WTRU가 공동 송신에 참여하려고 하는지의 여부를 결정할 수도 있다(901). 대상이 된 AAP 또는 WTRU가 공동 송신에 참여하려고 하면, AAP는 대상이 된 AP 또는 WTRU가 AAP에 연관되는지의 여부를 결정할 수도 있다(902). 대상이 된 AP 또는 WTRU가 연관되지 않는다면, AAP는, 상태 4에 들어가 모든 클래스들의 프레임들을 AAP로 송신하고 그 AAP로부터 수신할 수 있기 위하여, 대상이 된 AP 또는 WTRU를 인증(903)한 다음 대상이 된 AP 또는 WTRU와 RSNA를 확립(904)할 수도 있다. 이 절차는 ATAP, A-WTRU, 또는 C-WTRU에 의해 수행될 수 있게 또한 확장될 수도 있다.

AAP와 ATAP 또는 A-WTRU가 LTE 및/또는 유선 이더넷을 비제한적으로 포함하는 다른 인터페이스들 상에서 통신한다면, WiFi 인터페이스 상의 도 9의 절차는 필요하지 않을 수도 있다. 그 경우, 수신용 WTRU는 도 9의 절차에 따라 AAP 및 ATAP 중 어느 하나 또는 양쪽 모두 또는 A-WTRU와 인증할 수도 있다. WTRU는 AAP에만 연관될 수도 있거나, 또는 그것은 AAP 뿐만 아니라 ATAP 또는 A-WTRU와 연관될 수도 있다. 대안으로, WTRU는 AAP 및/또는 ATAP 또는 A-WTRU와 연관을 행하지 않고, 대신 AAP 및 ATAP 중 어느 하나 또는 양쪽 모두 또는 A-WTRU와 RSNA를 확립할 수도 있다.

도 10은 협응형 공동 송신을 위해 ATAP를 선택하는 일 예의 절차(1000)를 도시한다. 도 10의 예의 절차에서, AAP는 자신의 능력들을 알리기 위해 자신의 비콘, 프로브 응답, 연관 응답, 또는 임의의 다른 유형의 관리 및 제어 프레임에 공동 송신 능력 표시를 포함시킬 수도 있다(1001).

AAP는 WTRU들에 연관된 이웃 AP의 공동 송신 능력들 및 채널 특성들을 또한 모니터링/기록할 수도 있다(1002). 이들 능력들 및 채널 특성들은, AP가 공동 송신 능력 표시를 포함할 수도 있는 비콘, 프로브 응답, 연관 응답, 또는 임의의 다른 유형의 관리 및 제어 프레임과 같은 프레임들을 수신할 때, 그 AP에 의해 수신될 수도 있다. 임의의 AP가, 다른 WTRU로부터 프레임을 수신할 때, 송신용 WTRU와 자신 간의 채널의 사정을 기록할 수도 있다.

AAP는 공동 송신을 위해 수신용 WTRU를 식별할 수도 있고, 수신용 WTRU가 주변의 AP들로부터 하나 이상의 비콘 라디오 측정들 또는 다른 유형들의 프레임들에 대한 라디오 측정들을 행하고 피드백을 제공할 것을 요청할 수도 있다(1003). 수신용 WTRU는 요청된 라디오 측정들을 행할 수도 있고 피드백을 AAP로 제공할 수도 있다. AAP는 이웃 AP의 측정들을 행하여 측정 보고를 획득할 것이 수신용 WTRU에 의해 또한 요청될 수도 있다.

AAP는 수신용 WTRU로부터 피드백된 측정 보고들에 기초하여 ATAP가 될 후보들을 선택할 수도 있다(1004).

AAP는 ATAP 후보들과 수신용 WTRU 간의 채널 컨디션을 획득하기 위해 수신용 WTRU로부터의 피드백에 기초하여 공동 송신 질의를 후보 ATAP들로 전송할 수도 있다(1005). AAP는 공동 송신 능력들을 갖는다고 알려진 AP들에 공동 송신 질의를 전송할 수도 있거나 또는 AP들이 위에서 설명된 방법에 따라 공동 송신 능력들이 미리 알려지지 않았다면 그 AP들의 공동 송신 능력들을 질의할 수도 있다.

이들 AP들은 그 다음에 채널 품질 표시, 바람직한 공동 송신 옵션들, 및/또는 응답하는 AP가 채널 컨디션, 트래픽 부하, 국소 매체 점유 시간, 및 송신 전력 제한 등과 같은 자신의 국소적 상황에 기초하여 국소적으로 결정한 공동 송신 TxSpec을 제공할 수도 있는 질의된 ATAP 후보들로부터의 피드백을 공동 송신 피드백 프레임에서 수신할 수도 있다(1006).

AAP는 AAP가 모든 AP들로부터 수신했던 공동 송신 피드백에 기초하여 하나 이상의 수신용 WTRU들에 대한 공동 송신 세션을 위한 ATAP로서 하나 이상의 후보 ATAP들을 선택할 수도 있다(1007). ATAP에 대한 선택 기준은 다음을 비제한적으로 포함할 수도 있다:

(1) ATAP가 공동 송신이 수신용 WTRU에 대한 스루풋 개선을 상당히 제공할 수도 있도록 수신용 WTRU에 대해 양호한 채널 컨디션을 가짐;

(2) ATAP가 오버헤드로서 간주될 수도 있는 협응 정보 및 JTDP의 포워딩에 비교적 짧은 기간이 걸리도록 AAP와의 양호한 채널 컨디션을 가짐;

(3) ATAP가 AAP와는 스케줄링된 채널 액세스와, 유사한 유무선 인터페이스들 등과 같은 유사한 능력들을 공유함;

(4) ATAP가 JTS 동안 그 AAP가 원하는 공동 송신 옵션들과 TxSpec을 사용가능할 수 있음; 및

(5) ATAP가 공동 송신 세션에 대한 지연을 유발할 수도 있는 트래픽의 과도한 오버로드를 수신하지 않음.

이 절차는 ATAP, A-WTRU, 또는 C-WTRU에 의해 수행될 수 있게 또한 확장될 수도 있다. 대안으로 또는 부가적으로, 언제라도 AAP가 위의 절차를 종료할 수도 있고, 위에서 설명된 바와 같이 하나 이상의 이웃 AP들의 공동 송신 능력들을 획득하기 위해 이웃 AP들에 공동 송신 질의 프레임을 송신하는 것에 의해 도 7a에서 설명된 바와 같은 공동 송신 능력 절차를 수행할 수도 있다.

일단 AAP가 하나 이상의 수신용 WTRU들에 대해 JTS를 위한 ATAP를 선택하였다면, AAP, ATAP, 및 WTRU는 다중-AP 공동 송신 절차를 행할 수도 있다. 본원에서 설명된 바와 같은 공동 송신 요청 및 응답 교환들을 사용하여, AAP와 ATAP가 협응형 공동 송신의 유형에 합의할 수도 있다. 협응형 공동 송신의 예들은, 스케줄링된 병행 공동 송신들, 스케줄링된 순차 공동 송신들, 경합 기반 병행 공동 송신들, 및 경합 기반 순차 공동 송신을 비제한적으로 포함한다. 각각의 유형의 공동 송신들에 대한 절차는 아래에서 논의된다.

도 11은 스케줄링된 병행 공동 송신 절차(1100)의 일 예를 도시한다. AAP(1101)와 ATAP(1102)가 서로의 비콘들을 청취하고 자신들의 국소 타이머, 이를테면 AAP(1101) 및 ATAP(1102)에서의 TSF 타이머들 간의 차이를 결정할 수도 있다. 심지어 AAP(1101)와 ATAP(1102)가 무선 WiFi 인터페이스 상에서 서로의 범위 내에 있지 않더라도 공동 송신은 가능할 수도 있다. 비콘들은 DS 또는 다른 유형의 무선 또는 유선 인터페이스를 통해 교환될 수도 있다.

AAP(1101)는 무선 또는 유선 접속 중 어느 하나로 송신되는 공동 송신 요청(1110)을 사용하여 JTS를 설정할 수도 있다. 공동 송신 요청(1110)은 동일한 WiFi 매체(1105) 상에서 계류중인 JTS로서 전송될 수도 있다. 대안으로, 공동 송신 요청(1110)은 그것이 ATAP(1102)로 전달될 수도 있다면 대안적 인터페이스를 통해 대체 매체(1104) 상에서 또한 전송될 수도 있다. 예를 들어, 공동 송신 요청(1110)은 LTE, UMTS, WiMAX, 이더넷, 또는 상이한 WiFi 표준에 부합하는 상이한 인터페이스를 사용하여, 또는 동일한 WiFi 표준들이지만 상이한 채널 상으로 전송될 수도 있다.

AAP는 공동 송신 요청(1110)을 사용하여 하나 이상의 송신 기회들의 송신을 위한 JTS에 대한 스케줄 정보를 제공할 수도 있다. 이 스케줄 정보는 ATAP 또는 AAP 중 어느 하나에서의 로컬 타이머를 기준으로 할 수도 있거나 또는 합의된 임의의 다른 타이머를 기준으로 할 수도 있다. 이 스케줄은, 예를 들어, 시간과 지속기간 또는, 예를 들어, 송신 기회(transmit opportunity, TXOP)들, PSMP(power save multi-poll) 다운링크(DL) 슬롯들, S-APSD(scheduled automatic power save delivery) 슬롯들, 또는 예를 들어, 802.11ad에서의 서비스 기간들과 같은 임의의 다른 유형의 기간 표시일 수도 있다. AAP 및/또는 ATAP는 자신들의 비콘들, 짧은 비콘들, 또는 임의의 다른 유형의 프레임에서 이러한 스케줄을 알릴 수도 있다.

ATAP(1102)는 공동 송신 요청(1110)을 송신하기 위해 사용되는 동일한 매체 상에서 JTS를 수락 또는 거부 중 어느 하나를 하는 공동 송신 응답(1112)을 전송하는 것에 의해 응답할 수도 있다. JTS가 거부되면, AAP(1101)는 공동 송신 요청(1110)을 송신하기 위해 차선의 적합한 AP를 선택할 수도 있다. 대안으로, AAP(1101)는 거부 이유 코드에 따라 공동 송신 파라미터들 및 사양들을 조정하고 새로운 공동 송신 요청(1110)을 동일한 AP로 전송할 수도 있다. 선택된 AP가 JTS를 수락하면, AAP(1101)가 새로운 ATAP를 선택하지 않는 한 또는 변경을 나타내는 결과 필드와 함께 공동 송신 응답(1112)을 AP로 전송하는 것에 의해 JTS를 더 이상 수용할 수도 없다는 것을 ATAP(1102)가 AAP(1101)에 표시하지 않는 한, ATAP(1102)는 WTRU 또는 WTRU 세트를 위해 JTS에 대해 동일하게 유지될 수도 있다. 대안으로, ATAP(1102)는 JTS에 대해 상이한 매체, 이를테면 동일한 WiFi 매체(1105)를 선택할 수도 있다.

AAP(1101)는 그 다음에 JTDP들(1111)을 ATAP(1102)로 포워딩할 수도 있다. JTDP들(1111)이 공동 송신 요청(1110)과 함께 결집된 패킷들에서 포워딩되면, 공동 송신 응답은 포워딩된 JTDP들(1111)을 위한 JTDP ACK 블록 ACK(BA)(1113) 프레임들과 결집될 수도 있다. 대안으로, 공동 송신 요청(1110) 프레임들은 JTDP들을 갖는 필드들을 포함할 수도 있고 공동 송신 응답(1112) 프레임들은 포워딩된 JTDP들(1111)을 위한 JTDP ACK/BA(1113) 프레임들을 나타내는 필드를 포함할 수도 있다.

JTDP들은 공동 송신 능력들에 포함된 데이터 포워딩 옵션들에 따라 또는 공동 송신 요청(1110) 및 공동 송신 응답(1112) 교환 동안의 합의에 따라 AAP(1101)에 의해 ATAP(1102)로 포워딩될 수도 있다. JTDP들(1111)의 포워딩은 결집된 프레임들에서의 공동 송신 요청(1110)과 같은 협응 정보로 행해질 수도 있다. JTDP들(1111)의 포워딩은 그들 JTDP들의 공동 송신이 시작되기 전에 완료되고 확인응답(acknowledgement)될 수도 있다. 포워딩된 JTDP들은 MPDU들 또는 MSDU들일 수도 있다. 이들 MPDU들 또는 MSDU들은 프레임 바디 내에 캡슐화되고, 예를 들어, 이더넷, WiFi, LTE, 또는 WiMAX 프레임들로서 송신될 수도 있다.

MSDU들이 ATAP(1102)로 포워딩되면, ATAP(1102)는 MSDU들과 AAP(1101)에 의해 제공된 정보 및 TxSpec를 사용하여 MPDU들을 구성할 수도 있다. AAP(1101)가 TxSpec과 함께 MPDU들을 ATAP(1102)로 포워딩할 때, ATAP(1102)는 MPDU들을 직접 추출할 수도 있다. 공동 송신을 위해, ATAP(1102)는 MPDU들을 별개의 큐(queue)에 저장하고 PHY-TXSTART.request(TXVECTOR)와 같은 기본요소들을 사용하여 적절한 시간에 그 MPDU들을 물리적(PHY) 계층으로 전달할 수도 있는데, 여기서 TXVECTOR는 ATAP(1102)가 AAP(1101)로부터 획득했거나 또는 국소적으로 결정했던 TxSpec으로부터 유도될 수도 있다.

RSTA에 대해 투명한 공동 송신들에서, AAP(1101) 및 ATAP(1102)에 의해 송신된 PPDU들은 MAC 헤더들에서의 어드레스 필드들과 PLCP 헤더들에서의 그룹 ID들을 포함하여 동일할 수도 있다.

AAP(1101) 및/또는 ATAP(1102)는 공동 송신 통지 프레임(1114)을 사용하여 계류중인 스케줄링된 병행 JTS 및 그것의 스케줄을 R-WTRU(1103)에 통지할 수도 있다. 대안으로 또는 부가적으로, AAP(1101) 및/또는 ATAP(1102)는 동일한 목적을 달성하기 위해 자신들의 비콘, 짧은 비콘 또는 임의의 다른 유형의 프레임들에 공동 송신 통지 IE를 포함시킬 수도 있다. R-WTRU(1103)에 유니캐스트 프레임을 사용하여 통지되면, R-WTRU(1103)는 공동 송신 통지 프레임(1114)의 수신에 대한 ACK(1115)를 송신할 수도 있다.

AAP(1101)와 ATAP(1102)는, AAP에 의해 결정된 또는 국소적으로 결정된 TxSpec로부터 도출될 수도 있는 TXVECTOR들을 사용하여, 스케줄링된 시간에 공동 송신들(1116)을 시작할 수도 있다. 스케줄링된 병행 JTS에서, AAP(1101)와 ATAP(1102) 양쪽 모두에 의해 송신된 패킷 데이터(1117 및 1118)를 포함하는 PPDU들은 동일할 수도 있다. R-WTRU(1103)에게는 자신이 수신하고 있는 패킷 데이터(1117 및 1118)가 스케줄링된 병행 공동 송신물이라는 것이 명확할 수도 있다. 공동으로 송신된 패킷 데이터(1117 및 1118)를 수신했을 때, R-WTRU(1103)는 ACK(1119), 짧은 ACK, 또는 BA를 AAP(1101)로 송신하는 것에 의해 수신을 확인응답할 수도 있다. R-WTRU(1103)는 특정된 ACK 정책들에 따라 확인응답을 또한 건너뛸 수도 있다. 공동 송신이 실패하면, AAP(1101)는 나중의 예약된 시간에 개별적으로 또는 공동으로 중 어느 하나로 패킷 데이터(1117)를 재송신할 것을 판정할 수도 있다.

도 12는 스케줄링된 순차 공동 송신 절차(1200)의 일 예를 도시한다. AAP(1201)와 ATAP(1202)가 서로의 비콘들을 청취하고 자신들의 국소 타이머, 이를테면 AAP(1201) 및 ATAP(1202)에서의 TSF 타이머들 간의 차이를 결정할 수도 있다. 심지어 AAP(1201)와 ATAP(1202)가 무선 WiFi 인터페이스 상에서 서로의 범위 내에 있지 않더라도 공동 송신은 가능할 수도 있다. 비콘들은 DS 또는 다른 유형의 무선 또는 유선 인터페이스를 통해 교환될 수도 있다.

AAP(1201)는 무선 또는 유선 접속 중 어느 하나로 송신되는 공동 송신 요청(1210)을 사용하여 JTS를 설정할 수도 있다. 공동 송신 요청(1210)은 동일한 WiFi 매체(1205) 상에서 계류중인 JTS로서 전송될 수도 있다. 대안으로, 공동 송신 요청(1210)은 그것이 ATAP(1202)로 전달될 수도 있다면 대안적 인터페이스를 통해 대체 매체(1204) 상에서 또한 전송될 수도 있다. 예를 들어, 공동 송신 요청(1210)은 LTE, UMTS, WiMAX, 이더넷, 또는 상이한 WiFi 표준에 부합하는 상이한 인터페이스를 사용하여, 또는 동일한 WiFi 표준들이지만 상이한 채널 상으로 전송될 수도 있다.

AAP는 공동 송신 요청(1210)을 사용하여 하나 이상의 송신 기회들의 송신을 위한 JTS에 대한 스케줄 정보를 제공할 수도 있다. 이 스케줄 정보는 ATAP 또는 AAP 중 어느 하나에서의 로컬 타이머를 기준으로 할 수도 있거나 또는 합의된 임의의 다른 타이머를 기준으로 할 수도 있다. 이 스케줄은, 예를 들어, 시간과 지속기간 또는, 예를 들어, 송신 기회(transmit opportunity, TXOP)들, PSMP(power save multi-poll) 다운링크(DL) 슬롯들, S-APSD(scheduled automatic power save delivery) 슬롯들, 또는 예를 들어, 802.11ad에서의 서비스 기간들과 같은 임의의 다른 유형의 기간 표시일 수도 있다. AAP 및/또는 ATAP는 자신들의 비콘들, 짧은 비콘들, 또는 임의의 다른 유형의 프레임에서 이러한 스케줄을 알릴 수도 있다.

ATAP(1202)는 공동 송신 요청(1210)을 송신하기 위해 사용되는 동일한 매체 상에서 JTS를 수락 또는 거부 중 어느 하나를 하는 공동 송신 응답(1112)을 전송하는 것에 의해 응답할 수도 있다. JTS가 거부되면, AAP(1201)는 공동 송신 요청(1210)을 송신하기 위해 차선의 적합한 AP를 선택할 수도 있다. 대안으로, AAP(1201)는 거부 이유 코드에 따라 공동 송신 파라미터들 및 사양들을 조정하고 새로운 공동 송신 요청(1210)을 동일한 AP로 전송할 수도 있다. 선택된 AP가 JTS를 수락하면, AAP(1201)가 새로운 ATAP를 선택하지 않는 한 또는 변경을 나타내는 결과 필드와 함께 공동 송신 응답(1212)을 AP로 전송하는 것에 의해 JTS를 더 이상 수용할 수도 없다는 것을 ATAP(1202)가 AAP(1201)에 표시하지 않는 한, ATAP(1202)는 WTRU 또는 WTRU 세트를 위해 JTS에 대해 동일하게 유지될 수도 있다. 대안으로, ATAP(1202)는 JTS에 대해 대체 매체(1204), 이를테면 동일한 WiFi 매체(1205)를 선택할 수도 있다.

AAP(1201)는 그 다음에 JTDP들(1211)을 ATAP(1202)로 포워딩할 수도 있다. JTDP들(1211)이 공동 송신 요청(1210)과 함께 결집된 패킷들에서 포워딩되면, 공동 송신 응답은 포워딩된 JTDP들(1211)을 위한 JTDP ACK 블록 ACK(BA)(1213) 프레임들과 결집될 수도 있다. 대안으로, 공동 송신 요청(1210) 프레임들은 JTDP들을 갖는 필드들을 포함할 수도 있고 공동 송신 응답(1212) 프레임들은 포워딩된 JTDP들(1211)을 위한 JTDP ACK/BA(1213) 프레임들을 나타내는 필드를 포함할 수도 있다.

JTDP들은 공동 송신 능력들에 포함된 데이터 포워딩 옵션들에 따라 또는 공동 송신 요청(1110) 및 공동 송신 응답(1212) 교환 동안의 합의에 따라 AAP(1201)에 의해 ATAP(1202)로 포워딩될 수도 있다. JTDP들(1211)의 포워딩은 결집된 프레임들에서의 공동 송신 요청(1210)과 같은 협응 정보로 행해질 수도 있다. JTDP들(1211)의 포워딩은 그들 JTDP들의 공동 송신이 시작되기 전에 완료되고 확인응답될 수도 있다. 포워딩된 JTDP들은 MPDU들 또는 MSDU들일 수도 있다. 이들 MPDU들 또는 MSDU들은 프레임 바디 내에 캡슐화되고, 예를 들어, 이더넷, WiFi, LTE, 또는 WiMAX 프레임들로서 송신될 수도 있다.

MSDU들이 ATAP(1202)로 포워딩되면, ATAP(1202)는 MSDU들과 AAP(1201)에 의해 제공된 정보 및 TxSpec를 사용하여 MPDU들을 구성할 수도 있다. AAP(1201)가 TxSpec과 함께 MPDU들을 ATAP(1202)로 포워딩할 때, ATAP(1202)는 MPDU들을 직접 추출할 수도 있다. 공동 송신을 위해, ATAP(1202)는 MPDU들을 별개의 큐에 저장하고 PHY-TXSTART.request(TXVECTOR)와 같은 기본요소들을 사용하여 적절한 시간에 그 MPDU들을 물리적(PHY) 계층으로 전달할 수도 있는데, 여기서 TXVECTOR는 ATAP(1202)가 AAP(1201)로부터 획득했거나 또는 국소적으로 결정했던 TxSpec으로부터 유도될 수도 있다.

RSTA에 대해 투명한 공동 송신들에서, AAP(1201) 및 ATAP(1202)에 의해 송신된 PPDU들은 MAC 헤더들에서의 어드레스 필드들과 PLCP 헤더들에서의 그룹 ID들을 포함하여 동일할 수도 있다.

AAP(1201) 및/또는 ATAP(1202)는 공동 송신 통지 프레임(1214)을 사용하여 계류중인 스케줄링된 순차 JTS 및 자신의 스케줄을 R-WTRU(1203)에 통지할 수도 있다. 대안으로 또는 부가적으로, AAP(1201) 및/또는 ATAP(1202)는 동일한 목적을 달성하기 위해 자신들의 비콘, 짧은 비콘 또는 임의의 다른 유형의 프레임들에 공동 송신 통지 IE를 포함시킬 수도 있다. R-WTRU(1203)에 유니캐스트 프레임을 사용하여 통지되면, R-WTRU(1203)는 공동 송신 통지 프레임(1214)의 수신에 대한 ACK(1215)를 송신할 수도 있다.

AAP(1201)와 ATAP(1202)는, AAP에 의해 결정된 또는 국소적으로 결정된 TxSpec로부터 도출될 수도 있는 TXVECTOR들을 사용하여, 스케줄링된 시간에 공동 송신들(1216 및 1219)을 시작할 수도 있다. 스케줄링된 순차 JTS에서, AAP(1201)와 ATAP(1202) 양쪽 모두에 의해 송신된 패킷 데이터(1217 및 1220)를 포함하는 PPDU들은 동일할 수도 있다. R-WTRU(1203)에게는 자신이 수신하고 있는 패킷 데이터(1217 및 1220)가 스케줄링된 순차 공동 송신물이라는 것이 명확할 수도 있다.

대안으로, 패킷 데이터(1217 및 1220)는 공동 송신 옵션들에서 특정될 수도 있을, 예를 들어, STBC, HARQ 체계들을 사용하는 것에 의해 상이할 수도 있다. R-WTRU(1203)에게는 자신이 수신하고 있는 패킷 데이터(1217 및 1218)가 스케줄링된 순차 송신물이라는 것이 명확(transparent)할 수도 있다. 공동 순차 송신들에서, 공동 송신들은 R-WTRU(1203)에게 반드시 투명한(transparent) 것은 아닐 수도 있다. TA 어드레스들과 프레임 바디는, 예를 들어, 순차 송신들에서 상이할 수도 있다. R-WTRU(1203)에게는 AAP(1201) 및/또는 ATAP(1202)에 의해 공동 송신 통지 프레임(1214)을 사용하여 불투명 공동 순차 송신들이 통지될 수도 있다.

HARQ 순차 송신이 사용되면, AAP(1201) 또는 ATAP(1202) 중 어느 하나는 자신의 패킷 데이터(1217 및 1220)를 송신하는 것을 시작할 수도 있다. R-WTRU(1203)는 ACK/피드백(1218)을 되(back) 전송할 수도 있다. AAP(1201) 또는 ATAP(1202) 중 송신하지 않은 하나는, 제 1 송신이 이미 확인응답 되었다면, 자신의 송신을 취소할 수도 있다. 그렇지 않으면, 그것은 자신 소유의 PPDU를 R-WTRU(1203)로부터의 피드백에 기초하여 조정하고, R-WTRU(1203)로부터의 피드백으로부터 프레임간 공간(interframe space, IFS)과 같은 간격 후에 송신할 수도 있다. STBC가 사용되면, AAP(1201)와 ATAP(1202)는 STBC 체계에 따라 동시에 송신할 수도 있다. R-WTRU(1203)는 수신된 신호들을 STBC 디코딩 방법에 따라 프로세싱할 수도 있다.

공동으로 송신된 패킷 데이터(1217 및 1220)를 수신했을 때, R-WTRU(1203)는 공동 순차 송신의 AAP(1201) 및 ATAP(1202) 송신 부분들에 대한 개개의 ACK(1221), 짧은 ACK, 또는 BA를 AAP(1201)로 송신하는 것에 의해 수신을 확인응답할 수도 있다. R-WTRU(1203)는 특정된 ACK 정책들에 따라 확인응답을 또한 건너뛸 수도 있다. 공동 송신이 실패하면, AAP(1201)는 나중의 예약된 시간에 개별적으로 또는 공동으로 중 어느 하나로 패킷 데이터(1217)를 재송신할 것을 판정할 수도 있다.

R-WTRU(1203)는 또한, 전체 공동 순차 송신이 완료되기까지 기다린 다음 ACK들(1218 및 1221)을 AAP(1201)로 전송할 수도 있다. AAP(1201) 또는 ATAP(1202)는 JTDP가 제대로 수신되었음을 나타내는 공동 순차 송신들의 앞선(earlier) 송신 부분의 수신에 응답하여 RSTA가 ACK를 이미 송신하였다면 자신들의 계류중인 송신들을 취소할 수도 있다. 공동 송신이 실패하면, AAP는 나중의 예약된 시간에 개별적으로 또는 공동으로 중 어느 하나로 프레임을 재송신할 것을 판정할 수도 있다.

도 13은 JT-RTS 프레임의 일 예의 설계를 제공하는데, 이것은 경합 기반 공동 송신들(1300)에서의 사용을 위한 RTS(request to send) 프레임의 수정된 버전일 수도 있다. JT-RTS 프레임은 다음의 필드들, 즉, 프레임 제어 필드(1301), 지속기간 필드(1302), RA 필드(1303), TA 필드(1304), 참조 필드(1305), 및 FCS 필드(1306)를 비제한적으로 포함할 수도 있다. 이 프레임은 제어 프레임, 관리 프레임, 또는 임의의 다른 유형의 프레임, 필드, 또는 그것의 서브필드 중 임의의 유형으로서 또한 구현될 수도 있다.

프레임 제어 필드(1301)는 이것이 JT-RTS 프레임임을 나타내는 유형 정보를 포함할 수도 있다. 대안으로, 그 유형은 RTS일 수도 있지만 PLCP 헤더, 초기 스크램블링 시드들, 및/또는 FCS 인코딩을 포함한 모든 다른 필드들과 같은 그 프레임의 다른 부분들은 그 유형이 공동 송신을 위한 RTS임을 나타낼 수도 있다.

지속기간 필드(1302)는 AAP, ATAP 및 R-WTRU가 JT-CTS, 일반 RTS/CTS 교환, 및 모든 공동 송신, ACK/BA들에 더하여, 송신된 프레임들 간의 적절한 IFS들을 송신하는데 충분한 지속기간을 포함할 수도 있다. RA 필드는 ATAP의 어드레스를 포함할 수도 있고, TA 필드는 AAP의 어드레스를 포함할 수도 있다.

참조 필드(1305)는 특정 AAP에 대한 또는 AAP/ATAP 쌍에 대한 JTS의 ID 또는 시퀀스 번호와 같은 계류중인 JTS에 대한 참조들을 포함할 수도 있다.

도 14는 JT-CTS 프레임의 일 예의 설계를 도시하는데, 이것은 경합 기반 공동 송신들(1400)에서 사용하기 위한 CTS(clear to send) 프레임의 수정된 버전일 수도 있다. JT-CTS 프레임은 다음의 필드들, 즉, 프레임 제어 필드(1401), 지속기간 필드(1402), RA 필드(1403), 참조 필드(1404), 및 FCS 필드(1405)를 비제한적으로 포함할 수도 있다. 이 프레임은 제어 프레임, 관리 프레임, 또는 임의의 다른 유형의 프레임, 필드, 또는 그것의 서브필드 중 임의의 유형으로서 또한 구현될 수도 있다.

프레임 제어 필드(1401)는 이것이 JT-CTS 프레임임을 나타내는 유형 정보를 포함할 수도 있다. 대안으로, 그 유형은 CTS일 수도 있지만 PLCP 헤더, 초기 스크램블링 시드들, 및/또는 FCS 인코딩을 포함한 모든 다른 필드들과 같은 그 프레임의 다른 부분들은 그 유형이 공동 송신을 위한 CTS임을 나타낼 수도 있다.

지속기간 필드(1402)는 AAP, ATAP 및 R-WTRU가 일반 RTS/CTS 교환과, 모든 공동 송신, 및 ACK/BA들에 더하여, 송신된 프레임들 간의 적절한 IFS들을 송신하는데 충분한 지속기간을 포함할 수도 있다. 지속기간 필드는 Duration_in_JT-RTS - aSIFSTime - JT-CTS_Duration으로 설정될 수도 있는데, 여기서 Duration_in_JT-RTS는 JT-RTS 프레임에 포함된 값이며, aSIFSTime은 SIFS의 지속기간이고 JT-CTS_Duration은 JT-CTS 프레임을 송신하는데 필요한 지속기간이다.

RA 필드(1403)는 AAP의 어드레스를 포함할 수도 있다. 참조 필드는 특정 AAP에 대한 또는 AAP/ATAP 쌍에 대한 JTS의 ID 또는 시퀀스 번호와 같은 계류중인 JTS에 대한 참조들을 포함할 수도 있다.

도 15는 경합 기반 병행 공동 송신 절차(1500)의 일 예를 도시한다. AAP(1501)와 ATAP(1502)는 서로의 비콘들을 경청하고 서로의 공동 송신 능력들을 결정할 수도 있다. AAP(1501)는 병행 공동 송신 요청(1510)을 사용하여 JTS를 설정할 수도 있다. 공동 송신 요청(1510)은 동일한 WiFi 매체(1505) 상에서 계류중인 JTS로서 전송될 수도 있다. 대안으로, 공동 송신 요청(1510)은 그것이 ATAP(1502)로 전달될 수 있다면 대안적 인터페이스를 통해 대체 매체(1504) 상에서 또한 전송될 수도 있다. 예를 들어, 공동 송신 요청(1510)은, 예를 들어, LTE, UMTS, WiMAX, 이더넷, 또는 상이한 WiFi 표준에 부합하는 상이한 인터페이스를 사용하여, 또는 동일한 WiFi 표준들이지만 상이한 채널 상으로 전송될 수도 있다. ATAP(1502)는 공동 송신 요청(1510)을 송신하기 위해 사용되는 동일한 매체 상에서 JTS를 수락 또는 거부 중 어느 하나를 하는 공동 송신 응답(1512)을 전송하는 것에 의해 응답할 수도 있다. 대안으로, ATAP(1502)는 상이한 매체, 이를테면 계류중인 JTS와 동일한 WiFi 매체(1105)를 선택할 수도 있다. JTDP들이 공동 송신 요청(1510)과 함께 결집된 패킷들에서 포워딩되면(1511), 공동 송신 응답(1512)은 포워딩된 JTDP들을 위한 ACK/BA 프레임들(1513)과 결집될 수도 있다. 대안으로, 공동 송신 요청(1510) 프레임들은 JTDP를 갖는 필드들을 포함할 수도 있고, 공동 송신 응답(1512) 프레임들은 포워딩된 JTDP에 대한 ACK/BA를 나타내는 필드를 포함할 수도 있다.

ATAP(1502)가 JTS를 수락하면, JTDP들은 공동 송신 능력들에 포함된 데이터 포워딩 옵션들에 따라 또는 공동 송신 요청(1510) 및 공동 송신 응답(1512) 교환 동안의 합의에 따라 AAP(1501)에 의해 ATAP(1502)로 포워딩(1511)될 수도 있다. JTDP들은 결집된 프레임들에서 공동 송신 요청(1510)과 같은 협응 정보와 함께 또한 포워딩(1511)될 수도 있다. JTDP 포워딩(1511)은 그 JTDP의 공동 송신이 시작되기 전에 완료되고 확인응답될 수도 있다. 포워딩된 JTDP들은 MSDU들 또는 MPDU들일 수도 있다. R-WTRU에 대해 투명한 공동 송신들에서, AAP(1501) 및 ATAP(1502)에 의해 송신된 PPDU들은 MAC 헤더들에서의 어드레스 필드들과 PLCP 헤더들에서의 그룹 ID들을 포함하여 동일할 수도 있다.

AAP(1501) 및/또는 ATAP(1502)는 공동 송신 통지(1514) 프레임을 사용하여 계류중인 경합 기반 병행 JTS를 R-WTRU(1503)에 통지할 수도 있다. 대안으로, AAP(1501) 및/또는 ATAP(1502)는 동일한 목적을 달성하기 위해 자신들의 비콘, 짧은 비콘 또는 임의의 다른 유형의 프레임에 공동 송신 통지(1514) IE를 포함시킬 수도 있다. 공동 송신 통지(1514) IE가 비콘 또는 짧은 비콘에 포함된다면, AAP(1501) 및/또는 ATAP(1502)는 R-WTRU(1503)가 절전 모드에 있지 않음을 알고 그러므로 공동 송신 통지(1514) IE를 수신할 수도 있는 기간에만 그 IE를 포함시킬 수도 있다. AAP(1501) 및/또는 ATAP(1502)가 유니캐스트 프레임을 사용하여 R-WTRU(1503)에 통지하면, R-WTRU(1503)는 공동 송신 통지(1514) 프레임의 수신을 확인응답할 수도 있다. R-WTRU(1503)는 ACK(1515)로 공동 송신 통지(1514) 프레임에 응답할 수도 있다.

AAP(1501)는 JT-RTS 프레임(1516)을 ATAP(1502)에 송신하는 것에 의해 JTS를 개시할 수도 있고 JT-RTS 프레임(1516)의 지속기간 필드에 포함된 지속기간을 사용하여 자신의 네트워크 할당 벡터(network allocation vector, NAV) 카운터를 업데이트할 수도 있다. ATAP(1502)는 JT-CTS(1517) 프레임으로 JT-RTS(1516)에 응답할 수도 있다.

JT-RTS의 지속기간 값을 사용하여 자신의 NAV 카운터를 업데이트한 후, AAP(1501)는, JT-RTS 프레임(1516)의 말단으로부터 카운트한 2xaSIFS_time + JT-CTS_duration + Interval 후에 BSS에서의 ATAP(1502) 및 다른 AP들/WTRU들이 임의의 송신을 검출하지 못했다면, JT-RTS 프레임(1516)에 연관된 NAV를 취소할 수도 있는데, 여기서 aSIFS_time은 SIFS의 지속기간이며, JT-CTS_duration은 JT-CTS 프레임을 송신하는 지속기간이고, Interval은 얼마간의 임의의 시간 간격이고 aSlotTime이 슬롯의 지속기간인 Interval = 2*aSlotTime + aPHY-RX-START-Delay로서 구현될 수도 있다.

대안으로, BSS에서의 이들 다른 AP들/WTRU들은 절전을 위해 활동중지하도록 또한 선택할 수도 있다. 덧붙여서, JT-RTS의 지속기간 값을 사용하여 자신의 NAV 카운터를 업데이트한 AAP(1501)는, JT-RTS 프레임의 말단으로부터 카운트한 2xaSIFS_time + JT-CTS_duration 후에 AAP(1501)가 RTS 프레임을 검출하지 않지만, JT-RTS 프레임의 말단으로부터 카운트한 4xaSIFS_time + JT-CTS_duration + RTS_Duration + CTS_Duration + Interval 후에 임의의 송신을 검출하지 못하면, JT-RTS 프레임(1516)에 연관된 NAV를 취소할 수도 있는데, 여기서 RTS_Duration 및 CTS_Duration은 RTS 및 CTS 프레임을 송신하기 위해 필요한 지속기간이다.

계류중인 JTS가 통지되었을 수도 있는 R-WTRU(1503)는, TA 및 참조의 조합과 JT-RTS 프레임(1516)에서의 JTS를 비교하는 것에 의해 이 JTS가 자신을 위해 의도된다는 것을 JT-RTS 프레임(1516)으로부터 검출할 수도 있다. JT-RTS 프레임(1516)이 자신에 대해 JTS를 개시하려고 함을 R-WTRU(1503)가 검출하면, R-WTRU(1503)는 절전 모드에 들어가지 않을 수도 있고 자신의 NAV 카운터를 설정할 필요가 없을 수도 있다.

SIFS 지속기간 후, AAP(1501)와 ATAP(1502)는 RSTA의 어드레스인 RA 어드레스와 AAP(1501)의 어드레스인 TA 어드레스와 AAP(1501), ATAP(1502), 및 R-WTRU(1503)가 CTS(1520), 모든 공동 송신들, 적절한 응답 프레임들, 및 적절한 IFS들을 송신하는데 충분할 수도 있는 지속기간으로 설정된 지속기간 필드와 함께 일반 RTS(1518 및 1519)를 병행하여 송신할 수도 있다. 대안으로, AAP(1501)와 ATAP(1502)는 먼저 RTS/CTS 교환을 통하는 일 없이 직접적으로 데이터의 공동 병행 송신들을 시작할 수도 있다.

RTS(1518)를 수신하는 ATAP(1502)는 지속기간 값을 사용하여 자신의 NAV 카운터를 수정할 수도 있다. JT-CTS를 사용하여 자신의 NAV 카운터를 수정한 다음 JT-CTS 후의 RTS 및 SIFS 시간을 수정한 AP/WTRU의 경우, JT-CTS 시간의 종료로부터 카운트한 3xaSIFS_time + RTS_Duration + CTS_Duration + Interval 후에 임의의 송신을 검출하지 못하면, 그 AP/WTRU는 매체 예약을 취소할 수도 있다.

R-WTRU(1503)는 CTS 프레임(1520)을 송신하는 것에 의해 RTS(1518 및/또는 1519)에 응답할 수도 있다. AAP(1501)와 ATAP(1502) 양쪽 모두는 AAP(1520)에 어드레싱된 CTS를 위한 매체를 모니터링하는데 필요할 수도 있다. AAP(1501)와 ATAP(1502)가 이러한 CTS를 RSTA로부터 수신하지 못하면, 그것들은, 예약된 기간 동안 언제라도 JTS에 대한 매체 예약을 취소하기 위해, CF-End 프레임을 병행하여, 또는 따로따로 전송할 수도 있다. CF-End 프레임의 TA 필드는 AAP의 MAC 어드레스로 설정될 수도 있다. AAP/ATAP가 R-WTRU(1503)로부터 CTS를 수신하였다면, 그것들은 R-WTRU(1503)로의 데이터의 공동 병행 송신들을 시작할 수도 있다. JT TXOP가 JT-RTS/JT-CTS 및/또는 RTS/CTS 교환들을 사용하여 예약되었다면, AAP(1501)와 ATAP(1502)는 TXOP 동안 다수의 데이터 패킷들(1521 및 1522)을 병행하여 송신할 수도 있다.

R-WTRU(1503)는 그 다음에 프레임 교환 시퀀스들에서 허용된 바와 같은 ACK(1523), BA 또는 임의의 다른 프레임을 전송하는 것에 의해 하나 또는 다수의 패킷들의 수신을 확인응답할 수도 있다. ACK 정책들이 지시하는 대로 확인응답은 또한 건너뛸 수도 있다. JTS의 완료 후, AAP(1501)와 ATAP(1502)는 남아있는 TXOP가 이러한 송신들에 충분하다면 남아 있을 수도 있는 TXOP를 취소하기 위해 CF-End 프레임을 병행하여 또는 따로따로 전송할 수도 있다. 대안으로, AAP(1501)는 CF-End를 먼저 전송할 수도 있고 ATAP(1502)는 CF-End를 반복할 수도 있다. 공동 송신이 실패하면, AAP(1501)는 나중의 경합 기반 또는 스케줄 기반 공동 송신 세션에서 개별적으로 또는 공동으로 중 어느 하나로 프레임을 재송신할 것을 결정할 수도 있다.

도 16은 경합 기반 순차 공동 송신 절차(1600)의 일 예를 제공한다. AAP(1601)와 ATAP(1602)는 서로의 비콘들을 경청하고 서로의 공동 송신 능력들을 결정할 수도 있다. AAP(1601)는 순차 공동 송신 요청(1611)을 사용하여 JTS를 설정할 수도 있다. 공동 송신 요청(1611)은 동일한 WiFi 매체(1605) 상에서 계류중인 JTS로서 전송될 수도 있다. 대안으로, 공동 송신 요청(1611)은 그것이 ATAP(1602)로 전달될 수 있다면 대안적 인터페이스를 통해 대체 매체(1604) 상에서 또한 전송될 수도 있다. 예를 들어, 공동 송신 요청(1611)은, 예를 들어, LTE, UMTS, WiMAX, 이더넷, 또는 상이한 WiFi 표준에 부합하는 상이한 인터페이스를 사용하여, 또는 동일한 WiFi 표준들이지만 상이한 채널 상으로 전송될 수도 있다. ATAP(1602)는 공동 송신 요청(1611)을 송신하기 위해 사용되는 동일한 매체 상에서 JTS를 수락 또는 거부 중 어느 하나를 하는 공동 송신 응답(1612)을 전송하는 것에 의해 응답할 수도 있다. 대안으로, ATAP(1602)는 상이한 매체, 이를테면 계류중인 JTS와 동일한 WiFi 매체(1105)를 선택할 수도 있다. JTDP들이 공동 송신 요청(1611)과 함께 결집된 패킷들에서 포워딩되면(1613), 공동 송신 응답(1612)은 포워딩된(1613) JTDP들을 위한 ACK/BA 프레임들(1614)과 결집될 수도 있다. 대안으로, 공동 송신 요청(1611) 프레임들은 JTDP를 갖는 필드들을 포함할 수도 있고, 공동 송신 응답(1612) 프레임들은 포워딩된 JTDP에 대한 ACK/BA(1614)를 나타내는 필드를 포함할 수도 있다.

ATAP(1602)가 JTS를 수락하면, JTDP들은 공동 송신 능력들에 포함된 데이터 포워딩 옵션들에 따라 또는 공동 송신 요청(1611) 및 공동 송신 응답(1612) 교환 동안의 합의에 따라 AAP(1601)에 의해 ATAP(1602)로 포워딩(1613)될 수도 있다. JTDP들은 결집된 프레임들에서 공동 송신 요청(1611)과 같은 협응 정보와 함께 또한 포워딩(1613)될 수도 있다. JTDP 포워딩(1613)은 그 JTDP의 공동 송신이 시작되기 전에 완료되고 확인응답될 수도 있다. 포워딩된 JTDP들은 MSDU들 또는 MPDU들일 수도 있다. R-WTRU(1603)에 대해 투명한 공동 송신들에서, AAP(1601) 및 ATAP(1602)에 의해 송신된 PPDU들은 MAC 헤더들에서의 어드레스 필드들과 PLCP 헤더들에서의 그룹 ID들을 포함하여 동일할 수도 있다. 그것들은 TA 어드레스들, 프레임 바디, 및/또는 MCS 등에서 또한 상이할 수도 있다. ATAP(1602)에 의해 송신된 MPDU들은 TxSpec과 함께 AAP(1601)에 의해 결정될 수도 있다. 대안으로, AAP(1601)는 MSDU들을 ATAP(1602)로 포워딩할 수도 있고 ATAP(1602)는 자신과 R-WTRU(1603) 간의 채널 컨디션, 국소 특성들, 및/또는 R-WTRU(1603)로부터의 피드백 등에 기초하여 MPDU 뿐만 아니라 PPDU들을 구성할 수도 있다.

AAP(1601) 및/또는 ATAP(1602)는 공동 송신 통지(1615) 프레임을 사용하여 계류중인 경합 기반 순차 JTS를 R-WTRU(1603)에 통지할 수도 있다. 대안으로, AAP(1601) 및/또는 ATAP(1602)는 동일한 목적을 달성하기 위해 자신들의 비콘, 짧은 비콘 또는 임의의 다른 유형의 프레임에 공동 송신 통지(1615) IE를 포함시킬 수도 있다. 공동 송신 통지(1615) IE가 비콘 또는 짧은 비콘에 포함된다면, AAP(1601) 및/또는 ATAP(1602)는 R-WTRU(1603)가 절전 모드에 있지 않음을 알고 그러므로 공동 송신 통지(1614) IE를 수신할 수도 있는 기간에만 그 IE를 포함시킬 수도 있다. AAP(1601) 및/또는 ATAP(1602)가 유니캐스트 프레임을 사용하여 R-WTRU(1603)에 통지하면, 그 R-WTRU는 공동 송신 통지(1615) 프레임의 수신을 확인응답할 수도 있다. R-WTRU(1303)는 ACK(1616)로 공동 송신 통지(1615) 프레임에 응답할 수도 있다.

AAP(1601)는 다음의 셋팅들을 갖는 RTS 프레임의 수정된 버전인 JT-RTS(1617)를 ATAP(1602)로 송신하는 것에 의해 JTS를 개시할 수도 있다. AAP, ATAP 및 R-WTRU가 2 JT-CTS 프레임들, JT-RTS 프레임 및 모든 공동 순차 송신, ACK/BA들 더하기, 송신된 프레임들 간의 적절한 IFS들을 송신하는데 충분한 지속기간을 지속기간 필드가 포함할 수도 있다. RA 필드가 ATAP의 어드레스를 포함할 수도 있다. TA 필드가 AAP의 어드레스를 포함할 수도 있다. 참조 필드는 특정 AAP에 대한 또는 AAP/ATAP 쌍에 대한 JTS의 ID 또는 시퀀스 번호와 같은 계류중인 순차 JTS에 대한 참조들을 포함할 수도 있다. AAP(1501)는 JT-RTS 프레임의 지속기간 필드에 포함된 지속기간을 사용하여 자신의 NAV 카운터를 업데이트할 수도 있고, JT-RTS 프레임의 말단으로부터 카운트한 2xaSIFS_time + JT-CTS_duration + Interval 후에 BSS에서의 ATAP(1602) 및 다른 AP들/WTRU들이 임의의 송신을 검출하지 못했다면, JT-RTS 프레임에 연관된 NAV를 취소할 수도 있는데, 여기서 aSIFS_time은 SIFS의 지속기간이며, JT-CTS_duration은 JT-CTS 프레임을 송신하는 지속기간이고, Interval은 얼마간의 임의의 시간 간격이고 aSlotTime이 슬롯의 지속기간인 Interval = 2*aSlotTime + PHY-RX_Delay로서 구현될 수도 있다.

대안으로, BSS에서의 다른 AP들/WTRU들은 절전을 위해 활동중지하도록 또한 선택할 수도 있다. 덧붙여서, JT-RTS의 지속기간 값을 사용하여 자신의 NAV 카운터를 업데이트한 AP들/WTRU들은, JT-RTS 프레임의 말단으로부터 카운트한 2xaSIFS_time + JT-CTS_duration 후에 이들 AP들/WTRU들이 JT-RTS 프레임을 검출하지 않지만, JT-RTS 프레임의 말단으로부터 카운트한 4xaSIFS_time + JT-CTS_duration + JT-RTS_Duration + JT-CTS_Duration + Interval 후에 임의의 송신을 검출하지 못하면, JT-RTS 프레임에 연관된 NAV를 취소할 수도 있는데, 여기서 JT-RTS_Duration 및 JT-CTS_Duration은 JT-RTS 및 JT-CTS 프레임을 송신하기 위해 필요한 지속기간이다.

계류중인 JTS가 통지된 RSR-WTRU(1603)는, TA 및 참조 필드의 조합과 JT-RTS 프레임(1617)에서의 JTS를 비교하는 것에 의해 이 JTS가 자신을 위해 의도된다는 것을 JT-RTS 프레임(1617)으로부터 검출할 수도 있다. JT-RTS(1617)가 자신에 대해 JTS를 개시하려고 함을 R-WTRU(1603)가 검출하면, 그 R-WTRU는 절전 모드에 들어가지 않아야 하고 자신의 NAV 카운터를 설정할 필요가 없을 수도 있다. 그것은 참조 필드로부터 계류중인 JTS가 순차 JTS임을 인식할 수도 있다.

ATAP(1602)는 다음의 셋팅들을 갖는 JT-CTS(1618) 프레임으로 JT-RTS(1617)에 응답할 수도 있다. 지속기간 필드는 Duration_in_JT-RTS - aSIFSTime - JT-CTS_Duration으로 설정될 수도 있는데, 여기서 Duration_in_JT-RTS는 JT-RTS 프레임에 포함된 값이며, aSIFSTime은 SIFS의 지속기간이고 JT-CTS_Duration은 JT-CTS 프레임을 송신하는데 필요한 지속기간이다.

SIFS 지속기간 후, AAP(1602)와 ATAP(1603)는 R-WTRU(1603)의 어드레스인 RA 어드레스와 AAP(1601)의 어드레스인 TA 어드레스와 AAP(1601), ATAP(1602), 및 R-WTRU가 JT-CTS, 모든 공동 송신들, 및 적절한 IFS들을 송신하는데 충분한 지속기간으로 설정된 지속기간 필드와 함께 JT-RTS(1619 및 1620)를 병행하여 송신할 수도 있다. 마찬가지로, JT-RTS는 순차적 JTS에 대한 참조를 포함할 수도 있다. 대안으로, AAP(1601)와 ATAP(1602)는 RTS/CTS 교환을 먼저 수행하는 일 없이 직접적으로 데이터의 공동 순차 송신들을 시작할 수도 있다.

AAP(1601)와 ATAP(1602)는 지속기간 값을 사용하여 자신들의 NAV 카운터를 수정할 수도 있다. R-WTRU(1603)는 JT-CTS 프레임(1621)을 송신하는 것에 의해 JT-RTS(1619 및 1620)에 응답할 수도 있다. AAP(1601)와 ATAP(1602)는 AAP(1601)에 어드레싱된 JT-CTS를 위한 매체를 모니터링하는데 필요할 수도 있다. AAP(1601) 및/또는 ATAP(1602)가 이러한 JT-CTS를 R-WTRU로부터 수신하지 못하면, 그것들은, 예약된 기간 동안 언제라도 JTS에 대한 매체 예약을 취소하기 위해, CF-End 프레임을 병행하여, 또는 따로따로 전송할 수도 있다. CF-End 프레임의 TA 필드는 AAP의 MAC 어드레스로 설정될 수도 있다. AAP(1601) 또는 ATAP(1602)가 R-WTRU(1603)로부터 JT-CTS(1621)를 수신하였다면, 그것들은 R-WTRU(1603)로의 데이터(1622 및 1623)의 공동 순차 송신들을 시작할 수도 있다. JT TXOP가 JT-RTS/JT-CTS 및/또는 RTS/CTS 교환들을 사용하여 예약되었다면, AAP(1601)와 ATAP(1602)는 TXOP 동안 다수의 데이터 패킷들을 송신할 수도 있다.

HARQ 순차 송신이 사용되면, AAP(1601) 또는 ATAP(1602) 중 어느 하나는 자신의 패킷 데이터(1622 및 1623)를 송신하는 것으로 시작할 수도 있고, R-WTRU(1603)는 ACK/피드백(1622)을 되 전송할 수도 있다. AAP(1601) 또는 ATAP(1602) 중 송신하지 않은 하나는, 제 1 송신이 이미 확인응답 되었다면, 자신의 송신을 취소할 수도 있다. 그렇지 않으면, 그것은 자신 소유의 PPDU를 R-WTRU(1603)로부터의 ACK/피드백(1622)에 기초하여 조정하고 R-WTRU(1603)로부터의 ACK/피드백(1622)으로부터 IFS 후에 송신할 수도 있다. STBC가 사용되면, AAP(1601) 또는 ATAP(1602)는 STBC 체계에 따라 동시에 송신할 수도 있다. R-WTRU(1603)는 수신된 신호들을 STBC 디코딩 방법에 따라 프로세싱할 수도 있다.

R-WTRU(1603)는 그 다음에 프레임 교환 시퀀스들에서 허용된 바와 같은 ACK(1624), BA 또는 임의의 다른 프레임들을 전송하는 것에 의해 하나 또는 다수의 패킷들의 수신을 확인응답할 수도 있다. ACK 정책들이 지시하는 대로 확인응답은 또한 건너뛸 수도 있다. JTS의 완료 후, AAP(1601)와 ATAP(1602)는 남아있는 TXOP가 이러한 송신들에 충분하다면 남아 있을 수도 있는 TXOP를 취소하기 위해 CF-End 프레임을 병행하여 또는 따로따로 전송할 수도 있다. 대안으로, AAP(1601)는 CF-End를 먼저 전송할 수도 있고 ATAP(1602)는 CF-End를 반복할 수도 있다. 공동 송신이 실패하면, AAP(1601)는 나중의 경합 기반 또는 스케줄 기반 공동 송신 세션에서 개별적으로 또는 공동으로 중 어느 하나로 프레임을 재송신할 것을 판정할 수도 있다.

위에서 설명된 바와 같이, WTRU가 연관된 AP는 다른 WTRU, 예를 들어, 보조 WTRU(A-WTRU)와는 다운링크(DL) 송신이 높은 레이트로 일어나고 그러므로 그 WTRU에 높은 DL 스루풋 성능을 제공할 수도 있도록 그 WTRU로의 공동 송신들을 행하기 위해, 또한 협응할 수도 있다.

이들 다중-WTRU DL 공동 송신 절차들은 위에서 설명된 바와 같은 다중-AP 공동 송신들을 위한 것들을 따른다. AAP는 다른 ATAP 대신에 WTRU들 또는 A-WTRU와 다중-WTRU JTS를 협응할 수도 있다. A-WTRU는 AP와 연관될 수도 있거나 또는 또는 연관되지 않을 수도 있다.

도 17a는 AAP 및 A-WTRU에 의한 협응형 공동 송신을 위해 사용되는 일 예의 제어 정보 교환(1700)의 하이 레벨 신호 흐름도를 도시한다. 도 17a의 예에서, AAP(1702)와 A-WTRU(1703)는 위에서 설명된 바와 같은 다중-AP 공동 송신을 행할 것을 준비하기 위해 협응 제어 정보(1711a 및 1711b)를 교환할 수도 있다. 제어 정보(1711a)는 공동 송신 요청을 포함할 수도 있다. 제어 정보(1711b)는 공동 송신 응답을 포함할 수도 있다. 부가적으로 또는 대안으로, AAP(1702)는 데이터 패킷들(1712)을 A-WTRU(1703)로 포워딩할 수도 있다. AAP(1702)와 A-WTRU(1703)는 그 다음에 데이터 패킷들(1713a 및 1713b)을 수신용 WTRU(1701)에 공동 송신 세션에서 송신할 수도 있다. 협응 정보의 상호교환뿐만 아니라 연관된 데이터 패킷들의 포워딩은 적어도 2 개 방도들로 일어날 수도 있다. 첫째, 그것들은 다른 WLAN, UMTS, LTE, WiMAX 인터페이스를 비제한적으로 포함하는 동일한 또는 별개의 무선 인터페이스들을 사용하여 무선으로 송신될 수도 있다. 둘째, 그것들은 유선 백홀 링크를 통해 송신될 수도 있다.

AAP는 위에서 설명된 바와 같은 유사한 협응 제어 정보 프레임들의 설계들을 사용하여 공동 송신에 관한 협응 제어 정보를 A-WTRU로 전송할 수도 있다. 도 17b는 AAP 및 A-WTRU 간에 협력을 행하기 위해 사용될 수도 있는 일 예의 공동 송신 요청 프레임을 도시한다. 공동 송신 요청 IE는 다음의 필드들 및/또는 정보, 즉, 엘리먼트 ID 필드(1720), 길이 필드(1721), ID 필드(1722), 옵션 필드(1723), 스케줄 필드(1724), 송신 사양(TxSpec) 필드(1725), 및 요청 유형 필드(1726)를 비제한적으로 포함할 수도 있다.

엘리먼트 ID 필드(1720)는 IE가 공동 송신 요청 IE라는 것을 표시할 수도 있다. 길이 필드(1721)는 공동 송신 요청 IE의 길이를 포함할 수도 있다.

ID 필드(1722)는, 공동 송신의 수신자일 수도 있는 수신용 WTRU들, 요청 AAP, 요청되고 있는 A-WTRU 의 하나 이상의 ID, 및/또는 특정 AAP에 의해 요청되거나 또는 특정 수신용 WTRU에 특정 공동 송신 세션을 식별시키는 시퀀스 번호를 포함할 수도 있는 세션 ID를 포함할 수도 있다. ID(들)는 MAC 어드레스, AID, 또는 WTRU들이 합의할 수도 있는 임의의 다른 유형의 ID들로서 구현될 수도 있다.

옵션 필드(1723)는 공동 송신들에 대한 다양한 옵션들을 포함할 수도 있다. 옵션 필드(1723)의 예의 내용들이 표 12에 도시되어 있다.

예의 옵션들	설명
공동 송신 패킷 수	공동 송신 세션들 동안 송신될 것으로 예상된 패킷들의 수
공동 송신 패킷들/시간/TXOP의 사이즈	공동 송신 패킷들의 사이즈는 바이트수로, 송신 시간으로, 또는 마이크로초 또는 임의의 다른 시간 단위들로 표현된 TXOP로 특정될 수도 있다
공동 송신 세션에 대해 예상된 데이터 레이트(또는 MCS)	사용되는 데이터 레이트(또는 MCS)
공동 송신 세션의 지속기간	사용된 지속기간
병행 공동 송신	A-WTRU는 병행 공동 송신을 행할 수도 있다
순차 공동 송신	A-WTRU는 순차 공동 송신을 행할 수도 있다. A-WTRU는 자신과 수신용 WTRU 간의 채널 컨디션 및/또는 자신 소유의 송신 능력들에 따라 AAP에 의해 자신에게 포워딩된 데이터 패킷들을 포함하는 PPDU 또는 PSDU 프레임들을 구성하기 위해 다음의 사양들 중 하나 이상을 사용할 수도 있다. 예의 사양들은 STBC, 상이한 MCS, HARQ, 및/또는 상이한 채널 코딩을 포함할 수도 있다.
스케줄링된 공동 송신	A-WTRU는 AAP에 의해 특정된 스케줄에 따라 스케줄링된 시간에 공동 송신을 행할 수도 있다.
협응 정보 포워딩 옵션	ATAP가 AAP와 연관되면, ■ WiFi 인터페이스를 통한 일반 데이터 교환 ■ 공동 송신 포워딩: 공동 송신들에 연관된 데이터 및 제어 패킷들을 포워딩하기 위해 특수하게 설계된 포워딩 방법 ■ DS를 통한 포워딩 ■ 무선을 통한 포워딩 ■ 포워딩 송신 포맷: 이더넷, 802.11 레거시/a/b/g/n/ac/af/ah, X-1, UMTS, LTE 등 ■ 포워딩 송신 대역 및 채널: 802.11af 및 802.11ah에 대한 1 GHz 아래, 2.4 GHz, 5 GHz, 60 GHz 등과 같은 주파수 대역들뿐만 아니라 채널 번호들 ATAP가 AAP와 연관되지 않으면, ■ TDLS ■ DLS ■ OCT ■ 공동 송신 포워딩: 공동 송신들에 연관된 데이터 및 제어 패킷들을 포워딩하기 위해 특수하게 설계된 포워딩 방법 ■ DS를 통한 포워딩 ■ 무선을 통한 포워딩 ■ 포워딩 송신 포맷: 이더넷, 802.11 레거시/a/b/g/n/ac/af/ah, X-1, UMTS, LTE 등 ■ 포워딩 송신 대역 및 채널: 802.11af 및 802.11ah에 대한 1 GHz 아래, 2.4 GHz, 5 GHz, 60 GHz 등과 같은 주파수 대역들뿐만 아니라 채널 번호들
데이터 포워딩 옵션들	ATAP가 AAP와 연관되면, o WiFi 인터페이스를 통한 일반 데이터 교환 o 공동 송신 포워딩: 공동 송신들에 연관된 데이터 및 제어 패킷들을 포워딩하기 위해 설계될 수도 있는 포워딩 방법 o DS를 통한 포워딩 o 무선을 통한 포워딩 o 포워딩 송신 포맷: 이더넷, 802.11 레거시/a/b/g/n/ac/af/ah, X-1, UMTS, LTE 등 o 포워딩 송신 대역 및 채널: 802.11af 및 802.11ah에 대한 1 GHz 아래, 2.4 GHz, 5 GHz, 60 GHz 등과 같은 주파수 대역들뿐만 아니라 채널 번호들 ATAP가 AAP와 연관되지 않으면, o TDLS o DLS o OCT o 공동 송신 포워딩: 공동 송신들에 연관된 데이터 및 제어 패킷들을 포워딩하기 위해 특수하게 설계되는 포워딩 방법 o DS를 통한 포워딩 o 무선을 통한 포워딩 o 포워딩 송신 포맷: 이더넷, 802.11 레거시/a/b/g/n/ac/af/ah, X-1, UMTS, LTE 등 o 포워딩 송신 대역 및 채널: 802.11af 및 802.11ah에 대한 1 GHz 아래, 2.4 GHz, 5 GHz, 60 GHz 등과 같은 주파수 대역들뿐만 아니라 채널 번호들

스케줄 필드(1724)는 공동 송신들에 대한 다양한 옵션들을 포함할 수도 있다. 스케줄 필드(1724)의 예의 내용들이 표 13에 도시되어 있다.

스케줄링된 시작	공동 송신 세션의 스케줄링된 시작 시간; 그 시간은 AP들의 TSF 타이머, GMT 또는 임의의 다른 기준 클록을 기준으로 할 수도 있다
스케줄링 송신 시간들	공동 송신 패킷들의 스케줄링된 송신 시간들; 그 시간들은 AP들의 TSF 타이머, GMT 또는 임의의 다른 기준 클록을 기준으로 할 수도 있다
스케줄링된 주파수	얼마나 자주 공동 송신이 일어나나
스케줄링된 종료	공동 송신 세션의 스케줄링된 종료
현재 TSF 타이머	AAP의 현재 TSF 타이머; 이 스케줄에서의 시간들은 AAP의 TSF 타이머를 기준으로서 사용할 수도 있다. 대안으로, 기준 클록은 이 필드 역시 사용하여 특정될 수도 있다.
추정된 상호 클록 드리프트	이 서브필드 기준 클록과 A-WTRU의 로컬 클록 간의 추정된 클록 드리프트를 포함한다. 추정된 클록 드리프트는 비콘들, 짧은 비콘들, 동기 패킷들, 또는 클록 기준 시간을 포함하는 임의의 다른 유형들의 프레임들을 모니터링하는 것에 의해 또한 추정될 수도 있다.

TxSpecs 필드(1725)는 공동 송신들에 대한 다양한 옵션들을 포함할 수도 있다. 공동 송신들에 연관된 송신 사양들이 TxSpecs 필드에 포함된다. TxSpec은 TXVECTOR와는 매우 유사하게 또는 TXVECTOR의 수정된 버전으로서 구현될 수도 있고 MCS, 송신 전력, 채널 매트릭스, 사전-코딩 매트릭스 등을 특정할 수도 있다. 순차 공동 송신이 사용되면, AAP는 MPDU를구성하는 방법에 관해 ATAP를 위한 TxSpec, 이를테면 FCS 길이, 어드레스 필드 값들 등을 포함할 수도 있다 A-WTRU는 TxSpec과 AAP로부터 수신된 포워딩된 패킷들에 기초하여 PLCP 헤더 및 연관된 PSDU들/PPD들을 구성할 수도 있다 TxSpecs 필드(1725)의 예의 내용들이 표 14에 도시되어 있다.

채널 액세스 방법	스케줄링됨 경합 기반 AAP에 의해 시그널링됨
AAP 송신 사양들	AAP가 MCS, 송신 전력, 채널 매트릭스 사전-코딩 매트릭스 등과 같은 원래의 데이터 패킷을 송신하는 다양한 송신 사양들. A-WTRU는 AAP의 송신 사양들과 A-WTRU 및 수신용 WTRU 간의 채널 컨디션에 기초하여 포인트 송신 세션에서 패킷들을 수신용 WTRU들로 송신하기 위해 자신의 가장 최적의 셋팅들을 결정할 수도 있다

요청 유형 필드(1726)는 공동 송신들에 대한 다양한 옵션들을 포함할 수도 있다. 스케줄 필드(1724)의 예의 내용들이 표 15에 도시되어 있다

요청 유형

o 새로운 공동 송신 요청 o 공동 송신 요청 갱신: 현재 또는 이전 공동 송신 세션 요청의 갱신 o 종료: 공동 송신 세션의 종료

비록 위에서 설명된 공동 송신 요청 프레임이 IE의 형태이지만, 논의된 엘리먼트들의 임의의 필드, 서브필드, 또는 서브 세트는, PLCP/MAC 헤더, 프레임 바디, 및/또는 스크램블러 초기화 시드들 등의 임의의 부분과 같은 모든 명시적 및 암시적 시그널링을 포함한 관리 프레임, 제어 프레임, 데이터 프레임, 또는 임의의 다른 유형의 프레임의 임의의 부분으로서 구현될 수도 있다. 공동 송신 요청은 다른 유형의 통신 시스템, 예를 들어, LTE, UMTS, 임의의 WiFi 표준들, 이더넷 등에서, 프레임들, 또는 프레임들의 필드들로서 또한 구현될 수도 있다. 예를 들어, 그것은 그것이

공동 송신 프로토콜 관련된 프레임들 또는 다중-AP 송신 프로토콜 관련된 프레임들을 포함한다는 것을 나타내기 위해 페이로드 유형이 4 또는 4 ~ 255 사이의 임의의 다른 수들로 설정된 Ethertype 89-0d를 사용하여 구현될 수도 있다. 포함된 프레임이 서브유형 JTDP이라는 것을 나타내기 위해 부가적인 필드들이 포함될 수도 있다. 하나 이상의 세션 ID들이 하나 이상의 수신용 WTRU들에 특정 공동 송신 세션을 식별시키기 위해 사용될 수도 있다. 프레임의 ID, 예를 들어, 세션 ID에 의해 식별된 공동 송신 세션에서의 패킷의 시퀀스 번호, AAP의 ID, 및/또는 A-WTRU의 ID가 부가적인 필드로서 포함될 수도 있다.

일단 A-WTRU가 AAP로부터 공동 송신 요청을 수신하면, 그 A-WTRU는 공동 송신 응답 프레임 또는 관리 프레임, 제어 프레임, 또는 공동 송신 응답 IE를 포함하는 임의의 다른 유형의 프레임으로 응답할 수도 있다. 공동 송신 응답 프레임이 도 6의 예에서 도시된 바와 동일한 포맷을 취할 수도 있다. A-WTRU는 JTS를 수락 또는 거부할 수도 있다.

도 18은 WTRU들에서의 공동 송신 능력들을 결정하고 공동 송신을 준비하기 위한 일 예의 흐름도(1800)를 도시한다. 도 18의 예에서, AAP(1802)는 자신의 공동 송신(JT) 능력들(1811)에 대해 그리고/또는 하나 이상의 WTRU들에 연관된 자신의 채널 컨디션(1812)에 대해 A-WTRU(1803)에 질의할 수도 있다. WTRU가 AP와 연관되는 경우, AP는 WTRU의 능력을 충분히 알고 있고; AP는 그 WTRU가 자신과 연관되지 않으면 WTRU의 능력을 질의할 수도 있다. A-WTRU(1803)는 공동 송신 피드백(1813)으로 응답할 수도 있다. WTRU(1801)는 그러면 AAP(1802)로부터 계류중인 공동 송신 세션(1814)의 통지를 수신할 수도 있다. 공동 송신들의 수신에 참여하기 전의 WTRU(1801)는 공동 송신 능력 표시(1815a 및 1815b)를 임의의 관리 프레임, 제어 프레임, 또는 프로브 요청, 연관 요청 등과 같은 임의의 다른 유형의 프레임에서 AAP(1802) 및/또는 A-WTRU(1803)에 송신하는 것에 의해 자신의 공동 송신 및 수신 능력을 표시할 수도 있다. 대안으로, 병행 공동 송신이 행해진다면, 공동 송신 세션은 수신용 WTRU에 대해 투명하게 일어날 수도 있다. WTRU(1801)는 자신이 순차 공동 송신들을 수신할 수 있음을 또한 표시할 수도 있다.

AAP가 공동 송신 질의 프레임 또는 공동 송신 질의 IE를 포함하는 임의의 유형의 프레임을 사용하여 A-WTRU에게 하나 이상의 다른 WTRU에 대한 그것의 능력들 및 그것의 채널 컨디션을 질의할 수도 있다. 공동 송신 질의 프레임은 도 7b의 예에서 정의된 바와 동일한 포맷일 수도 있다.

WTRU가 AP, 예를 들어, AAP에 의해 질의될 때, A-WTRU는 공동 송신 피드백 프레임 또는 공동 송신 피드백 IE를 포함하는 임의의 다른 유형의 프레임을 전송하는 것에 의해 공동 송신 질의 프레임에 응답할 수도 있다. 공동 송신 피드백 프레임은 도 7c의 예에서 정의된 바와 동일한 포맷일 수도 있다.

AAP와 A-WTRU가 JTS에 합의할 때, AAP는 공동 송신 통지 프레임 또는 공동 송신 통지 IE를 포함하는 임의의 다른 유형의 프레임을 사용하여 계류중인 JTS를 수신용의 것에게 알려줄 수도 있다. 이는, 수신용 WTRU가 2 개를 초과하는 AP들 또는 다른 WTRU들로부터 유사한 또는 관련된 데이터를 수신하고 있음을 알지 못할 수도 있는 불투명 JTS에서 사용될 수도 있다. 예를 들어, 불투명 JTS에서, AAP와 A-WTRU는 특정 데이터 패킷에 연관되지만 헤더에서 상이한 TA 어드레스들과도 연관될 수도 있는 MPDU들을 송신할 수도 있다. 수신용 WTRU가 절전을 위해 활동중지 상태에 들어가지 않도록 수신용 WTRU에게 계류중인 스케줄링된 공동 송신을 통지하는 것이 또한 중요할 수도 있다. 공동 송신 통지 IE는 도 7d의 예에서 정의된 바와 동일한 포맷일 수도 있다.

AAP는 공동 송신 세션 동안 수신용 WTRU에게 송신될 수도 있는 JTDP들을 A-WTRU에게 전송할 수도 있다. JTDP는 도 8의 예에서 정의된 바와 동일한 포맷일 수도 있다.

병행 공동 송신이 사용될 때, AAP는 원래의 MPDU들, 뿐만 아니라 공동 송신 동안 AAP가 수신용 WTRU들에게 송신하고 있을 수도 있는 것들과 동일한 사용된 송신 사양들을 A-WTRU에게 포워딩할 수도 있다. 병행 공동 송신에서, AAP와 A-WTRU 양쪽 모두는 MAC 헤더들에서 어드레스 필드들을 포함할 수도 있는 동일한 PPDU들을 송신할 수도 있다.

순차 또는 스케줄링된 공동 송신이 사용될 때, AAP와 A-WTRU는 상이한 PPDU들을 송신할 수도 있다. AAP는 AAP 및/또는 A-WTRU를 위한 송신 사양들과 함께 원래의 MSDU들을 A-WTRU에게 포워딩할 수도 있다. AAP는 공동 송신 세션 동안 송신할 때 A-WTRU를 위한 송신 사양을 결정할 수도 있다. 대안으로 또는 부가적으로, A-WTRU는 자신과 수신용 WTRU 사이의 채널 컨디션 및/또는 AAP에 의해 사용되는 송신 사양들에 기초하여 자신 소유의 송신 사양들을 결정할 수도 있다. AAP가 JTDP들을 A-WTRU에게 포워딩하게 하기 위하여, 위에서 논의된 도 9의 동일한 연관 절차가 사용될 수도 있다. 도 9에서의 절차는 모든 클래스들의 프레임들을 A-WTRU로 송신하고 그 A-WTRU로부터 수신하기 위하여 상태 4에 들어가기 위하여 A-WTRU를 인증한 다음 수신용 WTRU와 RSNA를 확립하기 위해 사용될 수도 있다. 대안으로, A-WTRU가 수신용 WTRU와 동일한 BSS 내에 있다면, A-WTRU와 수신용 WTRU가 모든 클래스들의 프레임들을 교환할 수도 있도록 그 A-WTRU는 수신용 WTRU와 TDLS 또는 DLS 접속을 확립할 수도 있다. AAP와 수신용 WTRU는 인증되고 연관될 수도 있고, 그것들은 인증되고 RSNA 확립되거나 또는 요청되지 않은 상태 4에 또한 있을 수도 있다.

도 19는 다운링크에서 협응형 공동 송신을 위해 A-WTRU를 선택하는 일 예의 절차(1900)를 도시한다. 도 19의 예의 절차에서, AAP는 자신의 능력들을 알리기 위해 자신의 비콘, 프로브 응답, 연관 응답, 또는 임의의 다른 유형의 관리 및 제어 프레임에 공동 송신 능력 표시를 포함시킬 수도 있다(1901).

AAP는 그 다음에 특정 수신용 WTRU와 공동 송신을 행할 것이 요청되거나 또는 그러한 공동 송신을 행할 것을 판정할 수도 있다(1902). 공동 송신들의 수신에 참여하기 원할 수도 있는 수신용 WTRU는 공동 송신 능력 표시를 임의의 관리 프레임, 제어 프레임, 또는 프로브 요청, 연관 요청 등과 같은 임의의 다른 유형의 프레임에 포함시키는 것에 의해 자신의 공동 송신 및 수신 능력을 표시할 수도 있다. 대안으로, 병행 공동 송신이 행해진다면, 공동 송신 세션은 수신용 WTRU에 대해 투명하게 일어날 수도 있다. 그러나, 스케줄링된 또는 스케줄링되지 않은 중 어느 하나의 순차 공동 송신들을 위해, 수신용 WTRU는 자신이 순차 공동 송신물들을 수신할 수 있다는 것을 표시해야만 한다. AAP는 자신의 BBS에서 수신용 WTRU에게 더욱 균일한 커버리지를 제공하는데 공동 송신이 필요할 수도 있다는 것을 검출할 수도 있다. 대안으로 또는 부가적으로, WTRU는 또한, 더 높은 스루풋과 같은 양호한 성능을 원하고 그것을 달성하기 위해 공동 송신들을 행할 것을 AAP에게 요청할 수도 있다.

AAP는, 공동 송신들을 행할 것이 요청되고 있거나 또는 그러한 공동 송신들을 행할 것을 판정 시, 그 AAP가 수신용 WTRU로부터 획득한 능력들 및/또는 라디오 측정에 기초하여 하나 이상의 WTRU들과 하나 이상의 수신용 WTRU들 간의 채널 컨디션을 획득하기 위해 공동 송신 질의 프레임을 하나 이상의 WTRU들에게 전송할 수도 있다(1903). 이 측정은 비콘 측정과 유사할 수도 있다. AAP는 공동 송신 능력들을 갖는 것으로 알려지지 않은 WTRU들에게 공동 송신 질의를 전송할 수도 있다. AAP는 WTRU들의 공동 송신 능력들이 미리 알려져 있지 않다면 그 공동 송신 능력들을 또한 질의할 수도 있다.

조회되는 이들 WTRU들은 채널 품질 표시, 다른 측정들, 및/또는 바람직한 공동 송신들 옵션들 및/또는 응답하는 AP/WTRU가 채널 컨디션, 트래픽 부하, 송신 전력 제한 등과 같은 자신의 국소 상황에 기초하여 국소적으로 결정한 공동 송신 TxSpec을 제공하는 공동 송신 피드백 프레임으로 응답할 수도 있다(1904).

AAP가 모든 WTRU들로부터 수신했던 공동 송신 피드백에 기초하여, AAP는 하나 이상의 수신용 WTRU들과의 공동 송신 세션을 위한 A-WTRU로서 하나 이상의 WTRU들을 선택할 수도 있다(1905). A-WTRU에 대한 선택 기준은 위에서 설명된 바와 같은 ATAP에 대한 것들과 유사할 수도 있다.

대안으로 또는 부가적으로, 언제라도 AAP가 위의 절차를 종료할 수도 있고, 위에서 설명된 바와 같이 하나 이상의 이웃 WTRU들의 공동 송신 능력들을 획득하기 위해 이웃 WTRU들에게 공동 송신 질의 프레임을 송신하는 것에 의해 도 7a에서 설명된 바와 같은 공동 송신 능력 절차를 수행할 수도 있다.

일단 AAP가 하나 이상의 수신용 WTRU들에 대해 공동 송신 세션을 위한 A-WTRU를 선택하면, AP와 A-WTRU(들)는 다중-WTRU 공동 송신을 행할 수도 있다. 다중-AP 공동 송신과 유사하게, AAP와 A-WTRU는 경합 기반 병행 공동 송신들, 경합 기반 순차 공동 송신, 스케줄링된 병행 공동 송신들, 및 스케줄링된 순차 공동 송신들을 포함한 다양한 유형들의 공동 송신들을 행할 수도 있다. 이들 공동 송신들을 위한 절차들은 도 11, 도 12, 도 15, 및 도 16의 예들에서 설명된 바와 같이 A-WTRU가 ATAP를 교체하는 다중-AP 공동 송신을 위한 절차들을 따를 수도 있다.

A-WTRU와 수신용 WTRU가 동일한 BSS에 있고 AAP에 연관될 때, 공동 송신 절차는 최적화될 수도 있다. 예를 들어, 스케줄링된 병행 및 순차 공동 송신들을 위해, AP는 스케줄 정보, JTS ID 또는 시퀀스 번호 등과 같은 JTS 정보를, 자신의 비콘, 짧은 비콘 또는 임의의 다른 유형의 관리 프레임 또는 제어 프레임, 또는 BSS의 모든 WTRU들에 의해 수신되는 임의의 다른 유형의 프레임 내에 포함시킬 수도 있다. 이 정보가 유니캐스트 프레임들에서 따로따로 송신되지 않았을 수도 있기 때문에, 공동 송신 요청과 같은 프레임들은 단축될 수도 있고, 공동 송신 통지들과 같은 프레임들은 필요하지 않을 수도 있는데, 이는 더 높은 MAC 효율 및 더 높은 시스템 스루풋으로 이어질 수도 있다.

도 20은 협응형 업링크 공동 송신을 위해 A-WTRU를 선택하는 C-WTRU에 의해 사용되는 일 예의 절차(2000)를 도시한다. 다중-WTRU UL 공동 송신 시그널링 및 절차들은 DL에서의 다중-AP 및 다중-WTRU 공동 송신들의 절차들을 따를 수도 있다. C-WTRU가 다중-WTRU DL 공동 송신에서 AAP에 의해 사용되는 A-WTRU와 동일한 A-WTRU를 UL에서의 A-WTRU 다중-WTRU 공동 송신을 위해 사용할 수도 있다.

C-WTRU는 후보 A-WTRU들의 리스트를 AAP에게 요청할 수도 있다(2001). 공동 송신들의 수신에 참여하기 원하는 AAP가 공동 송신 능력 표시를 임의의 관리 프레임, 제어 프레임, 또는 비콘, 프로브 응답, 연관 응답 등과 같은 임의의 다른 유형의 프레임에 포함시키는 것에 의해 자신의 공동 송신 및 수신 능력을 표시할 수도 있다. 대안으로, 병행 공동 송신이 행해진다면, 공동 송신 세션은 AAP에 대해 투명하게 일어날 수도 있다. 그러나, 스케줄링된 또는 스케줄링되지 않은 중 어느 하나의 순차 공동 송신들을 위해, AAP는 자신이 순차 공동 송신물들을 수신할 수 있다는 것을 표시해야만 한다.

C-WTRU는 그 다음에 특정 수신용 WTRU와 공동 송신을 행할 것이 요청되거나 또는 그러한 공동 송신을 행할 것을 판정할 수도 있다(2002). UL에서 다중-WTRU 공동 송신을 행할 것이라는 판정은, WTRU에게 그것의 BSS에서 더욱 균일한 커버리지를 제공하기 위해 공동 송신이 필요함을 AAP가 검출하는 것에서부터 초래될 수도 있다. 대안으로 또는 부가적으로, WTRU는 높은 스루풋과 같은 개선된 성능을 원할 수도 있고 AAP가 성능을 개선하기 위하여 공동 송신들을 수신할 것을 요청할 수도 있다.

C-WTRU는, 공동 송신들을 행할 것이 요청되고 있거나 또는 그러한 공동 송신들을 행할 것을 판정 시, 그 C-WTRU가 AP로부터 획득한 능력들 및/또는 라디오 측정에 기초하여 하나 이상의 WTRU들과 AP 간의 채널 컨디션을 획득하기 위해 공동 송신 질의 프레임을 하나 이상의 WTRU들에게 전송할 수도 있다(2003). C-WTRU는 WTRU들의 공동 송신 능력들이 미리 알려지지 않으면 그 WTRU들의 공동 송신 능력들을 질의할 수도 있다.

조회되는 WTRU들은 채널 품질 표시들, 다른 측정들, 및/또는 바람직한 공동 송신들 옵션들 및/또는 응답하는 WTRU가 채널 컨디션, 트래픽 부하, 및/또는 송신 전력 제한과 같은 자신의 국소 상황에 기초하여 국소적으로 결정할 수 있는 공동 송신 TxSpec을 제공하는 공동 송신 피드백 프레임으로 응답할 수도 있다(2004).

C-WTRU가 질의된 모든 WTRU들로부터 수신했던 공동 송신 피드백에 기초하여, C-WTRU는 AP와의 공동 송신 세션을 위한 A-WTRU로서 하나 이상의 WTRU들을 선택할 수도 있다(2005).

C-WTRU로부터 A-WTRU로의 협응 정보 및 JTDP들의 포워딩은 무선 또는 유선을 포함한 다양한 매체 및 인터페이스들을 통해 송신될 수도 있다. 협응 정보는 LTE, UMTS, WiMAX, 임의의 WiFi 표준들, 이더넷 등과 같은 다른 유형의 통신 시스템들에서 프레임들의 필드들로서 구현될 수도 있다. 예를 들어, 그것은 그것이 공동 송신 프로토콜 또는 다중-AP 송신 프로토콜 데이터 프레임들을 포함한다는 것을 나타내기 위해 페이로드 유형이 6 또는 4 ~ 255 사이의 임의의 다른 수들로 설정된 Ethertype 89-0d를 사용하여 구현될 수도 있다. 덧붙여서, 포워딩된 협응 정보와 JTDP들은 TDLS, DLS 또는 OCT 접속들을 통해 또한 전송될 수도 있다.

일단 C-WTRU가 하나 이상의 수신용 AP들에 대해 공동 송신 세션을 위한 A-WTRU를 선택하면, A-WTRU들은 다중-WTRU 공동 송신을 행할 수도 있다. DL에서의 다중-WTRU 공동 송신과 유사하게, C-WTRU와 A-WTRU는 경합 기반 병행 공동 송신들, 경합 기반 순차 공동 송신, 스케줄링된 병행 공동 송신들, 및 스케줄링된 순차 공동 송신들을 포함한 다양한 유형들의 공동 송신들을 행할 수도 있다. 이들 공동 송신들을 위한 절차들은, 도 11, 도 12, 도 15, 및 도 16의 예들에서 설명되는 바와 같이 AAP를 대체한 C-WTRU와 수신용 WTRU(R-WTRU)를 대체한 수신용 AP를 이용하는 다중-WTRU 공동 송신을 위한 절차들을 따를 수도 있다.

도 21a는 제 2 실시형태(2100)에 따라 AP/PCP/WTRU 협상들을 통해 협응형 섹터화된 동작 또는 빔포밍된 송신들을 가능하게 하는 일 예의 절차를 도시하는데, 이 절차는 명세서에서 설명되는 실시형태들의 임의의 것과 조합하여 사용될 수도 있다. 복수의 AP들에 의해 공동으로 또한 행해질 수도 있는 섹터화된 송신 또는 빔포밍된 송신을 수행하는 것은 스루풋을 증가시킬 뿐만 아니라 또한 간섭을 감소시킬 수도 있다. 여러 BSS가 중첩할 때, AP들, WTRU들, 또는 PCP들은 송신된 신호들이 각각의 수신용 WTRU들에서 서로 간섭하지 않는 것을 보장하면서도 병행하는 협응형 섹터화된 동작 또는 빔포밍된 송신들을 행할 수도 있다.

본원에서 사용될 때, 섹터화된 동작이, WTRU가 연관할 수도 있는 AP의 커버리지의 각진 일부(angular portion)인 섹터 내에서 WTRU와 AP가 송신하고 수신할 때를 지칭한다. 섹터들은 영역에 기초하고 있다.

본원에서 사용될 때 빔포밍된 송신들은 라디오 신호들의 송신 및 수신의 지향성을 제어하는, WTRU들 및 AP들 모두에 의해 사용되는 신호 프로세싱 기법을 사용하는 송신을 지칭한다. 각각의 AP 또는 WTRU는 지향성 송신 및/또는 수신을 위한 특정 채널들을 가질 수도 있다.

WTRU들은 그 WTRU의 데이터 패킷들의 송신 또는 수신과 간섭할 수도 있는 중첩하는 BSS 또는 중첩하는 PBSS로부터의 섹터화된 동작 또는 빔포밍된 송신들을 관찰할 수도 있다. 자신들의 섹터화된 또는 빔포밍된 송신들/수신들이 다른 PBSS들, BSS 등에서의 임의의 다른 병행 섹터화된 또는 빔포밍된 송신들/수신들에 대한 자신들의 간섭을 제한하는 방도로, 중첩하는 BSS들이 협응한다면, 시스템 용량은 상당히 증가될 수도 있다.

중첩하는 BSS들에서의 AP들, WTRU들, 또는 PCP들은 그것들에 어드레싱되지 않은 수신된 프레임들에 정보를 기록할 수도 있다(2101). AP들, WTRU들, 또는 PCP들은 그 다음에 그것들이 경험하는 간섭을 빔포밍된 또는 섹터화된 수신 보고에서 보고할 수도 있다(2102). BSS에서의 AP/PCP는 그 다음에 빔포밍된 또는 섹터화된 수신 보고를 수신한(2103) 다음, 빔포밍된 또는 섹터화된 수신 보고들을 결합할 수도 있다(2104). AP들/PCP들은 그 다음에 빔포밍된 또는 섹터화된 수신 보고들과 그들 빔포밍된 또는 섹터화된 수신 보고들에 포함된 보고된 간섭에 기초하여 송신 충돌 리스트(2105)를 구성할 수도 있다. AP들/PCP들은 그 다음에 다른 AP들/PCP들과의 송신 충돌 리스트 정보를 보고할 수도 있다(2106). AP들/PCP들은 그 다음에 보고된 송신 충돌 리스트 정보에 기초하여 협응형 섹터화된 또는 빔포밍된 송신들을 스케줄링할 수도 있다(2107). BSS 간 또는 PBSS 간 협응형 빔포밍된 또는 섹터화된 송신들은 위에서 설명된 절차를 사용하여 WTRU 협상들을 통해 달성될 수도 있고 WLAN BSS 또는 OBSS 내에서 병행하는 섹터화된 동작 또는 빔포밍된 송신들을 가능하게 하기 위해 적용될 수도 있다. 이들 협응형 섹터화된 또는 빔포밍된 송신들은 간섭을 감소시킬 수도 있다. 예를 들어, 이 실시형태에서, AP/PCP가 자신의 BSS 커버리지를 섹터들로 분할하고 단계 2106에서 만들어진 송신 충돌 리스트로부터 도출된 스케줄에 따라 주어진 시간에 단지 하나 이상의 섹터들로부터만 송신하고 수신할 수도 있다.

도 21b는 섹터화된 또는 빔포밍된 송신들 및 수신들을 사용하는 시스템의 일 예를 도시한다. 도 21b의 시스템은 AP1(2121), WTRU1(2125), WTRU2(2123), 섹터 1(2111), 섹터 2(2112), 및 섹터 3(2113)을 포함하는 제 1 BSS로 이루어질 수도 있다. 제 2 BSS가 AP2(2126), WTRU3(2124), 및 WTRU4(2125), 섹터 4(2114), 섹터 5(2115), 및 섹터 6(2116)을 포함할 수도 있다. 도 21b에 도시된 바와 같이, 섹터들은 중첩할 수도 있다.

도 21b의 예에서, 섹터화된 송신 및 수신들은 중첩하는 BSS들(OBSS들)에서 서로 간섭할 수도 있다. 섹터 4(2114)에서 WTRU2(2123)로 송신할 때의 AP1(2121)은 AP2(2126)로부터 WTRU3(2124)로의 섹터화된 송신들과 간섭할 수도 있다. 마찬가지로 AP2(2126)가 섹터 2(2112)에서 송신할 때 그 AP2는 AP1(2121)에서의 수신과 간섭할 수도 있다. 이 예에서, 섹터화된 또는 빔포밍된 송신에 연관된 송신 전력은 특정한 방향들에서 종종 집중될 수도 있다. 강하게 지향성인 송신들로 인해, 다수의 섹터화된 송신들은 집계된 시스템 스루풋을 증가시키기 위해 병행하여 일어날 수도 있다. 지향성 송신들은 송신 빔들 내부에 위치될 수도 있는 수신기에 대해 심각한 간섭을 또한 유발할 수도 있다.

협응형 섹터화된 동작 또는 빔포밍이 사용되는 경우, WTRU1(2122)은 AP2(2126)가 WTRU4(2125)에게 송신할 때 제 2 BSS의 섹터 3(2113)으로부터의 간섭을 WTRU1가 경험함을 빔포밍된 또는 섹터화된 수신 보고를 사용하여 보고할 수도 있다. WTRU1(2122)은 AP2(2126)가 섹터화된/빔포밍된 또는 무지향성 비콘들을 송신할 때 WTRU1가 간섭을 경험함을 빔포밍된 또는 섹터화된 수신 보고를 사용하여 또한 보고할 수도 있다. 유사하게 WTRU2(2123)는 AP2(2126)가 섹터 2(2112)에서 송신할 때 제 2 BSS의 섹터 2(2112)로부터의 간섭을 WTRU2가 경험함을 빔포밍된 또는 섹터화된 수신 보고를 사용하여 보고할 수도 있다. AP1(2121)은 자신이 무지향성 수신 모드에 있을 때 경험하는 임의의 간섭을 또한 기록할 수도 있다. 섹터 5(2115)에서 수신기 섹터화를 사용하는 경우, AP1(2121)은 AP2(2126)가 무지향성으로 또는 섹터화 동작 모드로 중 어느 하나로 비콘들을 송신할 때 제 2 BSS의 섹터 2로부터의 임의의 간섭을 또한 기록할 수도 있다.

위에서 언급된 바와 같이, WTRU, PCP 또는 AP가 그것들에 어드레싱되지 않은 프레임을 수신할 때, 그것들은 수신된 프레임들에 도 21a에서 설명된 절차에 따라 정보를 기록할 수도 있다. 이러한 정보의 예가 표 16에 도시되어 있다.

정보	설명
송신기 어드레스
수신기 어드레스
BSSID
빔포밍됨 또는 빔포밍되지 않음	수신된 패킷이 빔포밍된 것으로 송신되는지의 여부. SU VHT 프레임에서의 빔포밍된 표시, 또는 표시된 빔포밍된 송신들에 대해 설계된 MU-MIMO VHT 프레임 또는 다른 필드들에서 0 또는 63이 아닌 그룹 ID와 같은 이러한 정보는 PLCP 헤더로부터 획득될 수도 있다.
섹터 ID	섹터 ID는, 섹터화된 비콘 프레임, 섹터화된 짧은 비콘인 프레임으로부터, 또는 개시자 섹터 스위프(Initiator Sector Sweep, ISS), 응답자 섹터 스위프(Responder Sector Sweep, RSS), 및 섹터 스위프 피드백에 속하는 프레임들, 또는 관리, 제어, 및 데이터 프레임들과 같은 임의의 다른 유형의 프레임들로부터 획득될 수도 있다.
수신 모드	수신용 WTRU PCP 또는 AP에서의 현재 수신 모드가 무지향성인지, 준-무지향(quasi-omni)인지, 지향성인지 등.
수신 모드 정보	수신 모드 정보는 수신 모드의 세부 설명들, 이를테면 수신기 빔포밍 패턴들/가중치들, 또는 수신용 WTRU가 자신의 PCP, AP 또는 다른 WTRU의 섹터 쪽으로 지향성으로 수신하고 있었는지의 여부, 또는 수신용 PCP 또는 AP가 WTRU, 다른 PCP 또는 AP 쪽으로 지향성으로 수신하고 있었는지의 여부를 포함할 수도 있다.

위에서 언급된 바와 같이, AP들, PCP들, 또는 WTRU들은 그 다음에 도 21a에서 설명된 절차에 따라 섹터화된 수신 보고를 사용하여 주기적으로 그것들의 BSS에서의 PCP 또는 AP에 그것들의 관찰된 송신들에 대한 레코딩된 정보를 전송할 수도 있다. 섹터화된 수신 보고는 프레임에서 전송되고 정보 엘리먼트, 관리 프레임, 제어 프레임, 데이터 프레임, 또는 임의의 다른 유형의 프레임, 필드들, 또는 임의의 유형의 프레임의 서브필드들로서 구현될 수도 있다.

도 22는 빔포밍된 또는 섹터화된 수신 보고 IE(2200)의 일 예의 설계를 도시한다. 빔포밍된 또는 섹터화된 수신 보고는 다음의 필드들 및/또는 정보를 포함할 수도 있다: IE가 섹터화된 수신 보고 IE임을 표시할 수도 있는 엘리먼트 ID 필드(2201), 섹터화된 수신 보고 IE의 길이를 포함할 수도 있는 길이 필드(2202), ID 필드(2203), 수신 모드 필드(2204), 수신 모드 정보 필드(2205), 보고용 필드 수 필드(2206), 및 하나 이상의 보고용 필드들(2207 및 2208).

ID 필드(2203)는 보고용 WTRU들의 ID들을 표시할 수도 있다. ID들은 MAC 어드레스, BSSID, SSID, AID, 또는 WTRU들이 합의하였을 수도 있는 임의의 다른 유형의 ID들로서 구현될 수도 있다. 대안으로, 보고용 WTRU의 ID는 MAC 헤더의 임의의 어드레스 필드, 이를테면 TA에서 표시될 수도 있다. 빔포밍된 또는 섹터화된 수신 보고의 대상은 RA 필드와 같은 MAC 헤더의 임의의 어드레스 필드에서 표시될 수도 있다. ID 필드는, 보고용 WTRU가 위치되는 PCP/AP/PBSS/BSS의 섹터의 ID를 포함할 수도 있는 섹터 ID를 포함할 수도 있다.

수신 모드 필드(2204)는 보고용 AP, PCP, 또는 WTRU가 그것을 목적지로 하지 않는 보고되는 송신들을 관찰할 때 있는 모드를 표시할 수도 있다. 수신 모드는 무지향성(표준), 준-무지향성 또는 지향성일 수도 있다. 하나의 빔포밍된 또는 섹터화된 수신 보고 프레임/IE는 보고용 WTRU의 하나 이상의 수신 모드에 대한 수신 보고들을 포함할 수도 있다. 예를 들어, 보고용 WTRU는 과거의 보고용 기간에서 작동하였던 각각의 수신 모드마다 별개의 빔포밍된 또는 섹터화된 수신 보고 프레임을 전송할 수도 있다. 다른 예에서, 보고용 WTRU는 다수의 빔포밍된 또는 섹터화된 수신 보고 IE들을 프레임 내에 포함할 수도 있어, 상이한 수신 모드에 대해 각각의 IE를 갖는다. 제 3 예에서, 빔포밍된 또는 섹터화된 수신 보고가 다수의 수신 모드들에 대한 보고용 필드들을 포함할 수도 있다. 다수의 수신 모드들에 대해 수신 보고들이 있는 경우, 빔포밍된 또는 섹터화된 수신 보고 IE는 다수의 수신 모드 필드들, 수신 모드 정보 필드들, 및 다수의 일련의 보고용 필드들을 각각의 수신 모드마다 각각 포함할 수도 있다.

수신 모드 정보 필드(2205)는 수신 모드 필드에서 특정된 수신 모드(들)에 대한 상세 정보를 포함할 수도 있다. 예를 들어, 지향성 수신 모드에 대해, 다음의 세부사항들, 즉, 빔포밍 가중치들; AP 또는 PCP, (P)BSS를 향하는 방향; 수신용 WTRU가 빔포밍된 송신을 수신했던 섹터의 AP, PCP 또는 WTRU의 ID; 및 수신용 WTRU가지향성 수신 모드에서 사용하였던 RX 섹터의 ID 중 하나 이상이 표시될 수도 있다.

보고용 필드 수 필드(2206)는 특정된 수신 모드를 위해 포함된 보고용 필드들의 수를 표시할 수도 있다. 예를 들어, 각각의 수신 모드에 대해 n 개의 보고용 필드들(2207 및 2208)이 있을 수도 있다. 각각의 보고용 필드는 보고용 필드 1 - n이라고 지칭될 수도 있다.

도 23은 보고용 필드(2300)의 일 예를 도시한다. 보고용 필드가 BSSID 필드(2301), Tx ID 필드(2302), Rx ID 필드(2303), Tx 모드 필드(2304), Tx 모드 정보 필드(2305), Tx 시간 필드(2306), 및 측정값들 필드(2307)를 포함할 수도 있다.

BSSID 필드(2301)는 수신된 패킷들이 송신되는 BSS 또는 PBSS의 BSSID를 표시할 수도 있다.

Tx ID 필드(2302)는 송신용 AP, PCP, 또는 WTRU의 ID를 표시할 수도 있다. 그 ID는 MAC 어드레스, BSSID, AID, 부분적 AID, 그룹 ID, 또는 WTRU들이 합의하였을 수도 있는 임의의 다른 유형의 ID들로서 구현될 수도 있다. Tx ID는 수신된 패킷들의 TA 필드로부터 취해질 수도 있다.

Rx ID 필드(2303)는 수신된 패킷들이 목적지로 했던 수신용 AP, PCP, 또는 WTRU의 ID를 표시할 수도 있다. 그 ID는 MAC 어드레스, BSSID, AID, 부분적 AID, 그룹 ID, 또는 WTRU들이 합의했던 임의의 다른 유형의 ID들로서 구현될 수도 있다. Rx ID는 수신된 패킷들의 RA 필드로부터 취해질 수도 있다.

Tx 모드 필드(2304)는 수신된 패킷의 송신 모드를 포함할 수도 있다. 송신 모드는 무지향성 또는 지향성일 수도 있다. 이러한 정보, 이를테면 SU VHT 프레임에서의 빔포밍된 표시, 또는 MU-MIMO VHT 프레임에서의 0 또는 63이 아닌 Group ID, 또는 이러한 정보를 표시하도록 설계된 임의의 다른 필드들은 PLCP 헤더로부터 획득될 수도 있다.

Tx 모드 정보 필드(2305)는 수신 모드 필드에서 특정된 수신 모드(들)에 대한 상세 정보를 포함할 수도 있다. 예를 들어, 지향성 수신 모드에 대해, 다음의 세부사항들, 즉, 예를 들어, 사운딩 패킷으로부터 획득될 수도 있는 빔포밍 가중치들; 수신된 패킷들을 송신하는데 사용되었던 송신용 AP, PCP, 또는 WTRU의 섹터의 ID; 및 그 패킷들을 수신하고 있는 AP, PCP, 또는 WTRU가 위치된 AP/PCP/BSS/PBSS의 섹터의 ID 중 하나 이상이 표시될 수도 있다.

Tx 시간 필드(2306)는 무선 매체 상의 수신된 패킷들의 시작 시간들, 지속기간들, 및/또는 종료 시간들을 포함할 수도 있다.

측정값들 필드(2307)는 평균 또는 피크 RSSI 또는 RCPI를 비제한적으로 포함하는 수신된 패킷들의 측정값들을 포함할 수도 있다.

위에서 설명된 바와 같이, PCP 또는 AP는 그 다음에 도 21a에서 설명된 절차에 따라 빔포밍된 또는 섹터화된 수신 보고 프레임들을 결합할 수도 있다. PCP 또는 AP는 일부 기준에 따라 WTRU 서브세트로부터 빔포밍된 또는 섹터화된 수신 보고를 결합할 수도 있다. 예를 들어, PCP/AP/PBSS/BSS의 특정 섹터에 위치된 WTRU들로부터의 빔포밍된 또는 섹터화된 수신 보고 프레임들은 함께 결합될 수도 있다. 다른 예에서, 동일한 PBSS/BSS로부터의 간섭을 경험하는 WTRU 서브세트로부터의 빔포밍된 또는 섹터화된 수신 보고 프레임들이 결합될 수도 있다. 덧붙여서, PCP 또는 AP는 도 21a에서 설명된 절차에 따라 송신 섹터 충돌 리스트를 구성하기 위해 빔포밍된 또는 섹터화된 수신 보고 프레임들을 자신 소유의 간섭 관측값들과 결합할 수도 있다. 표 17은 송신 충돌 리스트에 기초한 송신 섹터 충돌 테이블의 일 예의 설계이다.

섹터 ID (또는 WTRU 서브세트)	(P) BSS 1	(P) BSS 2	...	(P) BSS N
1	섹터 4, 5 또는 WTRU1, WTRU2, AP1(무지향성 tx)	NA	...	섹터 1 또는 WTRU16 내지 WTRU20(빔포밍된 tx)
2	섹터 5, 6 또는 WTRU93 내지 WTRU1(빔포밍된 tx)	NA	...	섹터 15 또는 WTRU21 내지 AP5 & AP5 내지 WTRU21(빔포밍된 tx)
...	...	...	...	...
M	NA	섹터 23 또는 WTRU75(무지향성 tx)	...	NA

현재 PBSS/BSS/AP/PCP의 (WTRU 서브세트 또는) 하나의 특정 섹터가 패킷을 송신하고 있거나 또는 수신하고 있을 때, 표시된 충돌 섹터들 역시 송신하고/수신하고 있다면, 그 패킷의 수신은 (P)BSSl - (P)BSSN으로부터의 간섭을 경험할 수도 있다는 것을 송신 섹터 충돌 테이블이 나타낸다. 대안으로 또는 부가적으로, 이들 (P)BSS들에서의 간섭하는 WTRU들(무지향성 또는 지향성 송신 및 수신 중 어느 하나)은 식별될 수도 있다. 다른 예에서, 특정 송신용 WTRU로부터 특정 수신용 WTRU로의 빔포밍된 또는 섹터화된 송신들은 특정 (P)BSS 섹터 또는 WTRU 서브세트에 대한 송신들/수신들과 충돌하는 것으로서 마킹될 수도 있다.

충돌 섹터들/WTRU들은 보고하는 WTRU들로부터의 빔포밍된 또는 섹터화된 수신 보고로부터 유추될 수도 있다. WTRU가 상이한 (P)BSS의 특정 섹터에서 다른 WTRU들로부터 무지향성 송신 또는 지향성 송신 중 어느 하나를 수신한다고 보고할 때, 그 WTRU는 간섭을 피하기 위하여 당해 섹터에서 상이한 시간에 송신하는 것을 필요로 할 수도 있다. 도 21b에 도시된 예의 시스템을 위한 송신 섹터 충돌 테이블의 일 예가 표 18에 예시되어 있다.

섹터 ID(또는 WTRU 서브세트의 ID)	BSS 2	...
3	섹터 2 AP1(무지향성 & 지향성 tx)	...
4	섹터 2 AP1(무지향성 & 지향성 tx)	...
5	섹터 5 AP2 내지 WTRU4(지향성 tx)	...

송신 섹터 충돌 리스트 또는 테이블은 제어, 관리 또는 임의의 다른 유형의 프레임들 또는 필드들, 다른 프레임들에서의 서브필드들 또는 IE들로서 구현될 수도 있는 송신 섹터 충돌 프레임들을 사용하여 AP들/PCP들 중에서 공유될 수도 있다. AP들/PCP들은 서로 또는 하나 이상의 협응하는 PCP들/AP들, 이를테면 WiFi 제어기 또는 승인(Admission) 제어기와 송신 섹터 충돌 보고 프레임들을 사용하여 송신 충돌 정보를 공유할 수도 있다. 도 24는 송신 섹터 충돌 리스트 또는 테이블을 공유하는 송신 섹터 충돌 IE의 일 예의 설계(2400)를 도시한다. 송신 섹터 충돌 IE는, IE가 송신 섹터 충돌 보고 IE임을 표시할 수도 있는 엘리먼트 ID 필드(2401), 송신 섹터 충돌 보고 IE의 길이를 포함할 수도 있는 길이 필드(2402), ID 필드(2403), 옵션 필드(2404), 필드 수 필드(2405), 및 보고용 필드 1 - N(2406)을 포함할 수도 있다.

옵션 필드(2404)는 충돌하는 송신들을 보고하는 옵션들을 포함할 수도 있다. 예를 들어, OBSS에서의 섹터가 보고하는 (P)BSS의 특정 섹터에 대한 간섭으로서 표시될 수도 있다. 다른 예에서, 송신용 및 수신용 WTRU들의 MAC 어드레스들은 특정 섹터에 대한 간섭 지향성 송신으로서 표시될 수도 있다.

필드수 (2405) 필드는 송신 섹터 충돌 IE에 포함되는 포함된 보고용 필드들의 수를 포함할 수도 있다. 각각의 보고용 필드(2406)는 보고용 필드 1 - N(2406)으로서 지칭될 수도 있고, 하나 이상의 섹터 또는 빔(또는 WTRU 서브세트)에 대한 간섭자(inteferer)들의 보고들을 포함할 수도 있다. 하나 이상의 보고용 필드들은 하나의 섹터 또는 빔 또는 WTRU 서브세트에 대한 간섭자들을 보고하는데 사용될 수도 있다.

각각의 보고용 필드(2406)는 섹터 ID 필드(2407), 지속기간/스케줄 필드(2408), 간섭자 수(2409) 필드, 옵션 필드(2410), 및 간섭자 필드 1 - M(2411)으로서 지칭될 수도 있는 하나 이상의 간섭자 필드들을 포함할 수도 있다.

섹터 ID 필드(2407)는 간섭자들이 보고되고 있는 (P)BSS 섹터의 ID를 포함할 수도 있다. 대안으로, 그것은 WTRU 서브세트의 ID(들), 이를테면 그룹 ID를 포함할 수도 있다.

지속기간/스케줄 필드(2408)는 섹터 ID 필드(2407)에 의해 식별된 WTRU들의 섹터 또는 서브세트에 대한 대상이 된 지속기간 또는 대상이 된 송신 시간의 스케줄을 포함할 수도 있다. 이 필드는 PCP/AP에 의한 식별된 섹터 또는 WTRU 서브세트에 대한 소망의 지속기간/스케줄을 표시할 수도 있다.

간섭자 수 필드(2409)는 보고용 필드 내에서 보고되고 있는 간섭자들의 수를 포함할 수도 있다.

각각의 보고용 필드는 충돌하는 송신들을 보고하기 위한 옵션 필드(2410)를 또한 포함할 수도 있다. 각각의 간섭자 필드(2411)는 옵션 필드(2410)의 사양들에 의존하는 하나 이상의 간섭자들에 대한 정보를 포함할 수도 있다.

간섭자 필드(2411)는 다음의 서브필드들을 포함할 수도 있다: 간섭하는 (P)BSS의 BSSID를 표시할 수도 있는 BSSID 서브필드(2412), 간섭자 ID 서브필드(2413), Tx 모드 서브필드(2414), 및 Tx 모드 정보 서브필드(2415).

간섭자 ID 서브필드(2413)는 옵션 필드에서의 사양에 따라 간섭자들의 하나 이상 또는 그룹의 ID를 표시할 수도 있다. 예를 들어, 이 필드는 간섭하고 있는 섹터의 ID를 포함할 수도 있다. 다른 예에서, 이 필드는 보고 BSS에서 지향성 송신들이 섹터에 대한 간섭을 초래하는 송신용 및 수신용 WTRU 쌍을 포함할 수도 있다.

Tx 모드 서브필드(2414)는 섹터화된 수신 보고 프레임에서의 유사한 필드들에 포함된 정보와 동일한 정보를 포함할 수도 있다.

Tx 모드 정보 필드(2415)는 섹터화된 수신 보고 프레임에서의 유사한 필드들에 포함된 정보와 동일한 정보를 포함할 수도 있다.

협응형 섹터화된 또는 빔포밍된 송신들은 도 21a에서 설명된 절차에 따라 분산형 또는 집중형(centralized) 패션으로 스케줄링될 수도 있다. 분산형 방법에서, AP들/PCP들은 중첩하는 (P)BSS의 다른 AP들/PCP들로부터 송신 섹터 충돌 보고 프레임들을 수신한 후 미리 결정된 순서에 기초하여 스케줄을 결정할 수도 있다. 예를 들어, 이러한 순서가 그것들의 MAC 어드레스들/BSSID/SSID의 순서일 수도 있다. 최저(또는 최고) MAC 어드레스의 AP/PCP는 그것의 섹터들을 송신하기 위해 자신의 스케줄을 결정할 수도 있다. 그 다음에 제 2 최저 (또는 두 번째로 높은) MAC 어드레스의 PCP/AP는 제 1 PCP/AP의 스케줄 및 송신 섹터 충돌 보고에 기초하여 자신의 스케줄을 결정할 수도 있다. 나머지 AP들/PCP들은 모든 AP들/PCP들의 모든 섹터들에 대한 스케줄들이 결정되기까지 동일한 프로세스를 따를 수도 있다.

다른 예에서, 최저(또는 최고) MAC 어드레스의 AP/PCP는 자신의 섹터들 중 하나의 섹터에 대해 송신하기 위한 자신의 스케줄을 결정할 수도 있다. 그 다음에 제 2 최저(또는 두 번째로 높은) MAC 어드레스의 AP/PCP는 지금까지 스케줄링된 송신들 및 송신 섹터 충돌 보고 프레임들에 기초하여 자신의 제 1 섹터를 스케줄링할 수도 있다. 최저(또는 최고) MAC 어드레스의 AP/PCP는 그 다음에 모든 AP들/PCP들이 그것들의 제 1 섹터에 대한 스케줄을 결정한 때에 제 2 섹터에 대해 송신하기 위한 자신의 스케줄을 결정할 수도 있다. 그 프로세스는 모든 AP들/PCP들이 그것들의 섹터들의 모두에 대해 모든 송신들을 스케줄링하기까지 계속할 수도 있다.

집중형 방법에서, 협응형 섹터화된 또는 빔포밍된 송신들에 능동적으로 참여하는 AP들/PCP들 중 하나일 수도 있는 하나 이상의 협응하는 AP들/PCP는, 모든 중첩하는 (P)BSS들에서의 모든 충돌 섹터들에 대한 송신 스케줄들을 결정할 수도 있다. 상이한 섹터들에서 송신하기 위한 스케줄들은 그 다음에 모든 다른 AP들/PCP들에 배포될 수도 있다. 예를 들어, PCP에 의해 향해진(headed) PBSS에서, 송신 섹터 충돌 보고 프레임은 협응하는 AP가 될 수도 있는 그들의 AP와 공유될 수도 있다. 그러면, 협응하는 AP는 후속하여, PBSS들에서의 모든 섹터들에 대한 스케줄을 결정하고 그 스케줄링을 PCP들에 배포할 수도 있다. 그러면 PCP들은 지향성의 섹터화된 비콘 프레임 또는 짧은 비콘 프레임과 같은 트리거 프레임을 송신하는 것에 의해, 명시적으로 또는 암시적으로 중 어느 하나로, 섹터 송신들의 스케줄링을 WTRU들에게 후속하여 배포할 수도 있다.

분산형 방법 및 집중형 방법 양쪽 모두에서, 스케줄링 병행 송신들은 송신용 및 수신용 WTRU들 양쪽 모두에 대해 간섭을 고려할 수도 있는데, 수신용 WTRU들이 응답 프레임, 이를테면 ACK, BA, 또는 짧은 ACK로 종종 응답할 수도 있어서이다.

도 25a와 도 25b는 협응형 섹터화된 또는 빔포밍된 송신들(2500)의 예들을 도시한다. 도 25a의 시스템은 AP1(2501a), WTRU1(2503a), WTRU2(2504a), 섹터 1(2511a), 섹터 2(2512a), 및 섹터 3(2513a)을 포함하는 제 1 BSS로 이루어질 수도 있다. 제 2 BSS가 AP2(2502a), WTRU3(2505a), 및 WTRU4(2506a), 섹터 4(2514a), 섹터 5(2515a), 및 섹터 6(2516a)을 포함할 수도 있다. 도 25a에 도시된 바와 같이, 섹터들은 중첩할 수도 있다. 제 1 BSS에서 AP1(2501a)은 시간 = i에 섹터 6(2516a)에서 데이터 패킷들의 WTRU1(2503a)로의 섹터화된 송신을 수행할 수도 있다. 제 2 BSS에서 AP2(2502a)는 또한 시간 = i에 섹터 1(2511a)에서 데이터 패킷들의 WTRU3(2505a)으로의 섹터화된 송신을 수행할 수도 있다. 이런 식으로, 2 개의 협응형 섹터화된 송신들이 서로 간에 간섭하는 일 없이 병행하여 일어날 수도 있다.

도 25b의 시스템은 AP1(2501b), WTRU1(2503b), WTRU2(2504b), 섹터 1(2511b), 섹터 2(2512b), 및 섹터 3(2513b)을 포함하는 제 1 BSS로 이루어질 수도 있다. 제 2 BSS가 AP2(2502b), WTRU3(2505b), 및 WTRU4(2506b), 섹터 4(2514b), 섹터 5(2515b), 및 섹터 6(2516b)을 포함할 수도 있다. 도 25b에 도시된 바와 같이, 섹터들은 중첩할 수도 있다. 제 1 BSS에서 AP1(2501b)은 시간 = j에 섹터 4(2514b)에서 데이터 패킷들의 WTRU2(2504b)로의 섹터화된 송신을 수행할 수도 있다. 제 2 BSS에서 AP2(2502b)는 또한 시간 = j에 섹터 3(2513b)에서 데이터 패킷들의 WTRU4(2506b)로의 섹터화된 송신을 수행할 수도 있다. 이런 식으로, 2 개의 협응형 섹터화된 송신들이 서로 간에 간섭하는 일 없이 병행하여 일어날 수도 있다.

분산형 방법 또는 집중형 방법 양쪽 모두에서, 간섭은 여전히 발생할 수도 있는데, 이를테면 간섭하는 WTRU가 수신용 WTRU로부터 너무 먼 거리에 있을 때, 모든 간섭하는 프레임들이 간섭을 경험하는 WTRU들에 의해 디코딩되는 것이 아닐 수도 있기 때문이다. 이 문제를 해결하기 위하여, AP들/PCP들은, 중첩하는 (P)BSS들에서 다수의 섹터들의 병행하는 섹터화된 또는 빔포밍된 송신들을 스케줄링하기 전에, 또는 스케줄링된 협응형 섹터화된 또는 빔포밍된 송신들에서 간섭이 검출될 때, 측정들을 행할 수도 있다.

AP/PCP가 시간 프레임 (t1, t2)에 협응형 섹터화된 또는 빔포밍된 송신을 섹터에 추가하기 원할 때, AP/PCP는 미리 정의된 또는 구성가능한 지속기간에 대해 모든 이웃 (P)BSS들로부터의 어떠한 간섭이라도 측정할 것을 당해 섹터에서의 WTRU들에게 지시할 수도 있다. 대안으로 또는 부가적으로, 스케줄링에서의 간격이 특별히 측정을 위해 따로 설정될 수도 있다. AP/PCP는 모든 AP들/PCP들이 주어진 간격 동안 간섭에 대해 송신하고 측정하지 않을 것을 요청하는 요청을 모든 다른 AP들/PCP(또는 협응하는 AP/PCP)에게 또한 전송할 수도 있다. 동일한 간격 동안, 요청하는 AP/PCP는 소망의 섹터들 내의 자신의 WTRU들과 일반적인 송신들 및 수신들을 행할 수도 있다. 모든 AP들/PCP들/WTRU들은 간섭을 측정하고 송신 섹터 충돌 프레임들을 업데이트할 수도 있다. AP/PCP는 그 다음에 새로운 섹터에 대한 스케줄을 결정하기 위해 업데이트된 송신 섹터 충돌 프레임들을 사용할 수도 있다.

도 26은 섹터화된 동작 및/또는 빔포밍된 송신 및 수신에 대한 지원을 표시하는데 사용될 수도 있는 협응형 섹터화된 및 빔포밍 능력 IE(2600)의 일 예를 도시한다. 협응형 섹터화된 동작 및/또는 빔포밍된 송신을 할 수도 있는 각각의 WTRU, AP, PCP는 협응형 섹터화된 및 빔포밍 능력 IE 또는 필드를 임의의 유형의 관리, 제어 또는 프로브 요청/응답, 연관 요청/응답 프레임, 비콘, 짧은 비콘 등과 같은 다른 유형의 프레임에 포함시키는 것에 의해 자신의 능력을 나타낼 수도 있다. WTRU는 WiFi 협응형 섹터화 또는 빔포밍을 할 수 있다는 것을 나타내기 위해 VHT 능력 정보 필드의 비트 30 ~ 31과 같은 현존하는 또는 새로운 필드들의 하나 이상의 비트를 또한 사용할 수도 있다. 협응형 섹터화된 및 빔포밍 능력 IE는 다음의 필드들을 비제한적으로 포함할 수도 있다:

(1) IE가 협응형 섹터화된 및 빔포밍 능력 IE임을 나타낼 수도 있는 엘리먼트 ID 필드(2601);

(2) IE의 길이를 포함할 수도 있는 길이 필드(2602);

(3) WTRU가 섹터화 송신에 대한 지원과 같은 섹터화된 동작을 할 수 있는지의 여부를 나타내는 하나 이상의 비트들을 포함할 수도 있는 섹터화된 동작 필드(2603);

(4) WTRU가 빔포밍된 또는 섹터화된 수신 보고들을 제공 및 수신할 수 있는지의 여부를 나타내는 하나 이상의 비트들을 포함할 수도 있는 섹터화된 수신 보고 필드(2604);

(5) WTRU가 협응형 빔포밍을 할 수 있는지의 여부를 나타내는 하나 이상의 비트들을 포함할 수도 있는 협응형 빔포밍 가능 필드(2605);

(6) 사전-코딩 매트릭스 배정(assignment)을 위한 또는 훈련을 통한 빔포밍 방법 옵션, 집중된 또는 분산된 협력을 위한 협응형 빔포밍 스케줄링 옵션, 또는 집중된 협응형 빔포밍을 위한 협응 노드로서 역할을 할 수도 있는 협력 능력 옵션과 같은 협응형 빔포밍을 위한 옵션들을 포함할 수도 있는 협응형 빔포밍 옵션 필드(2606).

마찬가지로, PCP들과 AP는 협응형 빔포밍 동작들의 자신의 현재 모드를 나타내기 위해 협응형 섹터화된 및 빔포밍 능력 IE를 자신의 비콘, 짧은 비콘, 연관 응답 및 프로브 응답에 포함시킬 수도 있다. 협응형 섹터화된 및 빔포밍 능력 IE의 설계는 엘리먼트 ID 필드를 제외하면 도 26에서 제시된 것과 동일할 수도 있다.

WTRU들은 섹터화된 동작 및/또는 협응형 빔포밍을 (P)BSS와 연관시킬 능력이 있을 것을 AP/PCP가 요구할 수도 있다. 섹터화된 동작 또는 협응형 빔포밍을 지원하지 않는 WTRU가 PCP/AP와의 연관을 시도하면, PCP/AP의 MAC 계층은 결과코드(ResultCode) "REFUSED_SECTORIZED_OPERATION_NOT_SUPPORTED" 또는 "REFUSED_COORDINATED_BEAMFORMING_NOT_SUPPORTED"를 갖는 MLME-ASSOCIATE.response 기본요소를 발행하는 것에 의해 연관을 거부할 수도 있다. 마찬가지로, 연관된 연관 응답 프레임뿐만 아니라 MLME-ASSOCIATE.confirm 기본요소는 WTRU로부터의 연관 요청을 거부하는 때에 ResultCode 코드들과 동일한 2 개의 이유 코드들을 포함할 수도 있다.

도 27은 본원에서 설명되는 실시형태들 중 임의의 것과 조합하여 사용될 수도 있는 제 3 실시형태에 따른 하나를 초과하는 WLAN 인터페이스가 WTRU들에 갖추어진 일 예의 시스템(2700)을 도시한다. 이 실시형태는 공동 송신 및/또는 빔포밍된/섹터화된 송신이 하나를 초과하는 무선 인터페이스를 통해 수행되는 것을 가능하게 할 수도 있다. 디바이스가 상이한 WiFi 표준들을 준수하는 상이한 WiFi 인터페이스들과 함께 다수의 WiFi 인터페이스들을 가질 수도 있다. 예를 들어, 디바이스가 더 큰 영역 커버리지를 위한 802.11ac 인터페이스뿐만 아니라 폐쇄형 범위에 있는 WTRU들에의 다중-기가 비트(multi-giga bits) 접속들을 위한 802.11ad 인터페이스를 가질 수도 있다. 다른 예에서, 디바이스가 1km까지의 반경의 커버리지 영역을 위한 802.11ah 인터페이스뿐만 아니라 802.11n 인터페이스를 가질 수도 있다. 도 27의 예에서, AP1(2706)은 WiFi 제어기(2701)와의 802.11ac 인터페이스(2705) 및 WTRU(2707)와의 802.11ad 인터페이스(2704)를 갖는다. 마찬가지로, AP2(2707)는 WiFi 제어기(2701)와의 802.11ac 인터페이스(2702) 및 WTRU(2707)와의 802.11ad 인터페이스(2703)를 갖는다. 이 실시형태는 WLAN (P)BSS 및 OBSS들에서의 모든 WTRU들에 대해 더욱 균일한 커버리지를 제공하기 위해 커버리지 범위, 능력들, 및 데이터 레이트들과 같은 각각의 WLAN 인터페이스의 상이한 특성들을 활용할 수도 있다. 이들 WLAN 인터페이스들은 동일한 (예를 들어, 상이한 채널들에 튜닝하는 다수의 802.11ac 디바이스들) 또는 상이한 WLAN 표준들을 또한 준수할 수도 있다(예를 들어, 하나의 WLAN 인터페이스가 802.11ac WTRU일 수도 있는 반면 제 2 WLAN 인터페이스는 802.11ah WTRU일 수도 있다).

이들 상이한 특성들의 상이한 WiFi 디바이스들은 WiFi에서 더욱 균일한 커버리지를 제공하는 협응 및 데이터 포워딩을 달성하기 위해 활용될 수도 있다. 예를 들어, 디바이스 상의 802.11ac/ac+ 접속들이 동일한 디바이스 상의 802.11ad WTRU들, PCP들 및 AP들에 대한 협응형 빔포밍 또는 협응형 섹터화된 동작을 제공하기 위해 활용될 수도 있다. 위에서 설명된 바와 같이, 802.11ad WTRU들, PCP들 및 AP들은 빔포밍된 또는 섹터화된 수신 보고 프레임들, 송신 섹터 충돌 보고 프레임들, 협응형 섹터화된 및 빔포밍 능력 프레임들, 뿐만 아니라 (P)BSS의 섹터들에 대한 스케줄링 프레임들 및 데이터와 같은 협력 프레임들을 교환하기 위해 802.11ac/ac+ 접속들을 사용할 수도 있다. 마찬가지로, 802.11ac/ac+ WTRU들 및 AP들(또는 일반적인 표현으로, 임의의 802.11xx 표준들을 준수하는 WTRU들 및 AP들)은 섹터화된 수신 보고 프레임들, 송신 섹터 충돌 보고 프레임들, 협응형 섹터화된 및 빔포밍 능력 프레임들, 뿐만 아니라 (P)BSS의 섹터들에 대한 스케줄링 및 데이터 프레임들과 같은 협력 프레임들을 교환하기 위해 다른 802.11xx 접속을 사용할 수도 있다. 다른 802.11xx 접속은 사전-코딩 매트릭스들을 교환하기 위해 또한 활용될 수도 있다. 협응, 스케줄링 및 데이터 프레임들의 상호교환은 피어 투 피어일 수도 있거나 또는 도 27에 도시된 바와 같은 집중형 WiFi 제어기에 대한 것일 수도 있다.

덧붙여서, 디바이스가 동일한 WiFi 표준들을 준수할 수도 있는 다수의 WiFi 인터페이스들을 가질 수도 있다는 것이 또한 가능할 수도 있다. 이는 WiFi 인터페이스들 외에도 상이한 WiFi 표준들을 준수하는 것일 수도 있다. 이들 WiFi 인터페이스들은, WiFi 네트워크들에서 더욱 균일한 커버리지를 달성하기 위하여, WiFi 인터페이스들 중 하나가 데이터 프레임들의 송신, 공동 송신들, 협응형 빔포밍, 섹터화된 송신들의 수행을 위해 사용될 수도 있는 반면 다른 WiFi 인터페이스는 위에서 설명된 바와 같은 공동 송신들을 위해, 그리고 위에서 설명된 바와 같은 협응형 빔포밍 또는 섹터화된 동작을 위해 협응, 스케줄링 및 데이터 프레임들을 송신하는데 사용되도록 상이한 채널들로 튜닝될 수도 있다.

IEEE 802.11 네트워크들에서의 채널 액세스의 분산된 특성은 숨은 노드 문제를 불러일으킬 수도 있다. 도 28은 WTRU2(2802)와 AP(2804)가 WTRU1(2801)로부터의 송신들을 들을 수도 있는 반면 WTRU3(2803)이 WTRU1(2801)로부터의 송신들을 듣지 못할 수도 있는 숨은 노드 문제(2800)의 일 예를 제공한다. WTRU3(2803)은 따라서 WTRU1(2801) 및 AP(2804) 간의 통신에 관한 숨은 노드일 수도 있다. 이 경우, WTRU1(2801)가 패킷을 AP(2804)에게 송신할 때, 숨은 노드 WTRU3(2803)이 충돌을 초래하는 AP(2804)에게 다른 송신을 시도할 가능성이 있을 수도 있다. 802.11에서의 단일 AP에 대해, RTS(request-to-send)와 CTS(clear-to-send) 시그널링 교환들은 숨은 노드 문제를 해결하는데 사용될 수도 있다. 숨은 노드 시나리오는 복수의 AP들의 협응형 통신들에 대한 문제도 남아 있는데, 채널 액세스가 분산형 패션으로 계속 구현될 수도 있어서이다. 또한 일부 주파수 대역들(예컨대 60 GHz 대역)에 대해, 무지향성일 수도 있는 직접 송신 RTS/CTS 패킷들은 시간 낭비적일 수도 있다. 그 경우, 상이한 주파수 대역이 숨은 노드 문제를 해결하기 위해 RTS/CTS 패킷들을 송신하는데 사용될 수도 있다.

도 29는 제 4 실시형태에 따른 상이한 주파수 대역들을 통한 RTS/CTS 패킷들의 송신을 위한 일 예의 절차(2900)를 도시하는데, 이 절차는 본원에서 설명되는 실시형태들 중 임의의 것과 조합하여 사용될 수도 있다. 이 실시형태는 공동 및/또는 섹터화된 송신들을 협응하는 추가의 메커니즘들을 제공할 수도 있다. 이 절차는 상이한 주파수 대역들에 걸쳐 RTS/CTS를 구현할 수도 있고 60 GHz 대역에서 숨은 노드 문제를 해결하는데 사용될 수도 있다. 도 29의 예에는, 다음 3 개의 WTRU들이 있다: WTRU A(2901), WTRU B(2902), 및 WTRU C(2903). WTRU들은 이 예에서 예시 목적을 위해 사용되지만, 각각의 WTRU는 AP에 의해 또한 대체될 수도 있다. 또한 이 예에서, 각각의 WTRU/AP는 5 GHz 대역 및 60 GHz 대역 양쪽 모두에서 송수신할 수도 있다.

송신용 WTRU A(2901)는 특정된 지속기간에 대해 60 GHz 대역을 예약하려는 시도로, 5 GHz 대역에서 RTS 프레임을 전송할 수도 있다(2910). 수신용 WTRU B(2902)는 그 다음에 SIFS 기간 후에 5 GHz 대역에서 CTS 프레임을 전송하여(2911), 특정 지속기간에 대해 WTRU A(2901)를 위한 60 GHz 대역의 예약을 확인하고, 60 GHz에서의 수신을 준비할 수도 있다. 송신기 또는 수신기로서 포함되지 않을 수도 있는 WTRU C(2903)는, 60 GHz에 대한 자신의 NAV를 그에 따라 설정할 수도 있고(2912), 특정 지속기간 내에서는 송신을 하지 않고 보류할 수도 있다.

WTRU B(2902)로부터 5 GHz 대역에서 CTS 프레임을 수신한 후(2911), WTRU C(2903)는 그에 따라 60 GHz 상에서 자신의 NAV를 업데이트할 수도 있고(2913), 특정 지속기간 내에서 송신하지 않고 보류할 수도 있다. WTRU A(2901)는, 교차 대역 프레임 간 스페이싱(cross band interframe spacing, CBIFS) 시구간 후에(2914), WTRU B(2902)로의 60 GHz 상의 데이터 송신들을 진행할 수도 있다(2915). 60 GHz 송신들의 확인응답은 60 GHz 대역을 통한 WTRU A(2901)로부터의 성공적인 통신을 확인하기 위해 그리고 또는 WTRU A(2901)에 의해 원래 설정된 60 GHz NAV 셋팅들을 지우기 위해 5 GHz 대역을 통해 전송될 수도 있다(2916). 대안으로 또는 부가적으로, 확인응답은 원한다면 60 GHz 채널 상에서 송신될 수도 있다.

도 30은 RTS/CTS 포맷이 위의 절차를 지원하기 위해 수정될 수도 있는 방법(3000)의 일 예를 도시한다. RTS(3001)는 프레임 제어 필드(3010), 지속기간 필드(3011), 수신기 어드레스 필드(3012), 송신기 어드레스 필드(3013), 원하는 대역(5G/60G) 필드(3014), 및 FCS 필드(3015)를 포함할 수도 있다. 원하는 대역(5G/60G) 필드(3014)는 RTS 프레임이 60 GHz 대역(또는 5 GHz 대역)을 통하는 채널, 또는 60 GHz 대역 내의 채널을 예약하는 것임을 나타내는데 사용될 수도 있다. 마찬가지로, CTS(3002)는 프레임 제어 필드(3020), 지속기간 필드(3021), 송신기 어드레스 필드(3022), 원하는 대역(5G/60G) 필드(3023), 여분의(extra) 피드백 필드(3024), 및 FCS 필드(3025)를 포함할 수도 있다. 원하는 대역(5G/60G) 필드(3023)는 60 GHz 대역을 통하는 채널, 또는 60 GHz 대역 내의 특정 채널의 성공적인 예약을 확인하는데 사용될 수도 있다. 덧붙여서, 여분의 피드백 필드(3024)가 60 GHz 대역을 통하는 빔포밍 훈련 프로세스를 신속히 처리하는데 도움을 주기 위해 CTS에서 전송될 수도 있다. 정보는 WTRU의 이력 및/또는 로케이션 정보로부터의 공간적 빔포밍 벡터를 비제한적으로 포함할 수도 있는데, 이 공간적 빔포밍 벡터는 WTRU에 부속된 글로벌 포지셔닝 시스템(GPS)으로부터 획득될 수도 있다.

위의 예들에서, 5 GHz 컴포넌트와 60 GHz 컴포넌트는 동일한 물리적 디바이스, 예를 들어 동일한 WTRU에 존재할 수도 있다. 2 개의 컴포넌트들은 2 개의 상이한 물리적 디바이스들, 예를 들어, 5G WTRU 및 60G WTRU에 존재할 수도 있다는 점에 주의한다.

전통적인 IEEE 802.11에서, RTS/CTS 시그널링 교환은 숨은 노드 문제를 해결하는데 필요할 수도 있다. RTS는 잠재적인 송신기로부터 먼저 전송될 수도 있다. 잠재적 수신기를 제외한, RTS를 듣는 모든 다른 스테이션은, 자신들의 NAV들을 그에 따라 설정하고 자신의 송신들을 유지할 필요가 있을 것이다. 잠재적 수신기는 CTS 패킷으로 응답하여, RTS 요청을 확인할 수도 있다. RTS 및 CTS의 조합은 트랜시버 쌍이 라디오 자원을 예약하고 숨은 노드 문제로부터 다음의 송신을 보호하는 것을 도울 수도 있다.

도 31은 유사한 절차가 숨은 노드 문제를 다루는데 사용될 수도 있는 다중-AP WiFi에서의 일 예(3100)를 제공한다. 도 31의 예에서, AP1(3101)과 AP2(3102)는 라디오 자원들에 대한 요청을 하기 위해 다중-AP RTS(MRTS)를 송신할 수도 있다(3111a 및 3111b). 응답하여, 수신기, 이 경우에 WTRU1(3103)는, 요청을 확인하기 위해 다중-AP CTS(MCTS)로 응답할 수 있다(3112). AP1(3101) 및 AP2(3102)로부터 WTRU1(3103)로의 실제 데이터 송신들(3113a 및 3113b)은 보장될 수도 있다. 대안으로, 송신될 수도 있는(3111a 및 3111b) MRTS는 동시에, 또는 엇갈리는 방식(staggered manner)으로 차례차례로 송신될 수도 있다.

동일한 시간에, MRTS(3111a 및 3111b)를 들을 시, WTRU2(3104)는, AP1(3101) 및 AP2(3102)에 의해 추정된 바와 같은 ACK(3115)까지, 자신의 NAV를 그에 따라 설정할 수도 있다(3114a). MCTS(3112)를 들을 시, WTRU2(3104)는 MCTS(3112)에서 특정된 바와 같은 ACK(3115)의 종료까지 자신의 NAV를 그에 따라 업데이트할 수도 있다(3114b). WTRU3(3105)은 MCTS(3112)만을 듣고 따라서 MCTS(3112)에 의해 특정된 바와 같은 ACK(3115)의 종료까지 자신의 NAV를 설정할 수도 있다(3116). WTRU4(3106)는 MRTS(3111a 및 3111b)만을 듣고 그에 따라 MRTS(3111a 및 3111b)를 들을 시 AP1(3101) 및 AP2(3102)에 의해 추정된 바와 같은 ACK(3115)의 종료까지 자신의 NAV(3117)를 설정할 수도 있다. 이 절차는 각각의 WTRU/AP가 데이터 송신들(3113a 및 3113b)을 알고 충돌을 피하는 것을 보장한다.

도 32는 MRTS 및 MCTS를 위한 일 예의 프레임 포맷(3200)을 제공한다. MRTS(3201)는 다음의 필드들을 비제한적으로 포함할 수도 있다: 프레임 제어 필드(3211), 지속기간 필드(3212), 수신기 어드레스 필드(3213), 송신기 어드레스 1 필드(3214), 송신기 2 어드레스 필드(3215), 및 FCS 필드(3216). MCTS(3202)는 다음의 필드들을 비제한적으로 포함할 수도 있다: 프레임 제어 필드(3221), 지속기간 필드(3222), 송신기 어드레스 1 필드(3223), 송신기 2 어드레스 필드(3224), 및 FCS 필드(3225). 모든 송신기들의 어드레스는 MRTS 및 MCTS 패킷 양쪽 모두에서 특정될 수도 있고 MAC 어드레스들, 또는 송신기 1 및 송신기 2(예컨대 AP1 및 AP2)의 그룹을 나타내는 논리적 어드레스일 수도 있다.

도 33a 내지 도 33d는 복수의 AP들이 단일 WTRU로부터 송신된 신호를 수신하고 업링크 균일 WiFi(uniform WiFi, UniFi)에서 신호를 공동으로 또는 따로따로 디코딩할 수도 있는 여러 예들(3300)을 도시한다.

도 33a는 슈퍼 AP에 의한 공동 디코딩의 일 예를 도시한다. WTRU(3301)로부터 AP1(3302) 및 AP(3303)에 의해 수신된 정보는 디코딩을 위해 슈퍼(super) AP(3304)로 전송될 수도 있다. 슈퍼 AP(3304)는 예를 들어 WiFi 제어기일 수도 있다.

도 33b는 1차 AP에 의한 공동 디코딩의 일 예를 도시한다. UniFi 세트에서의 AP1(3312)과 AP2(3313)는 WTRU(3311)로부터 수신된 정보를 단일 또는 "기본(primary)" AP에게 포워딩할 수도 있고 디코딩은 이 예에서는 AP1(3312)인 1차 AP에서 수행될 수도 있다. 포워딩은 별개의 송신으로 유선 ESS 백홀 또는 OTA(over-the-air)를 통할 수도 있다.

도 33c는 복수의 AP들에 의한 별개의 디코딩의 일 예를 도시한다. 이 예에서 AP1(3322)과 AP2(3323)는 WTRU(3321)로부터 수신된 정보를 따로따로 디코딩할 수도 있다. 정보를 성공적으로 디코딩하는 임의의 AP는 그 정보를 전송 계층 또는 상위(higher) 계층으로 전송할 수도 있다. 중복들은 이 계층에서 다루어질 수도 있다.

도 33d는 단일 AP에 의한 별개의 디코딩의 일 예를 도시한다. 이 예에서, WTRU(3331)는 송신의 시간에 디코딩 성공의 최고 확률을 갖는 단일 AP를 선택하고 이 AP로 송신할 수도 있다. 이는 AP 선택 알고리즘으로서 보일 수도 있다. 이 예에서, WTRU(3331)는 AP1(3332)을 통해 AP2(3333)를 선택한다.

도 34a와 도 34b는 단일 WTRU가 복수의 AP들(3400)에 송신할 수도 있는 일 예의 CSMA/CA 절차(3400)를 도시한다. 도 34a에서, WTRU(3401)는 송신을 위한 채널을 예약하기 위해 UniFi_RTS 프레임(3411)을 AP1(3402)과 AP2(3403)로 송신할 수도 있다. WTRU(3401)로부터의 RTS의 수신 시, AP1(3402)과 AP2(3403)는 WTRU(3401)의 자원 예약을 확인하기 위해 UniFi CTS(3412 및 3413)를 WTRU(3401)로 송신할 수도 있다. 도 34a의 예에서, AP1(3402)과 AP2(3403)는 특정 지속기간 후에 UniFi_CTS(3412 및 3413)를 각각 독립적으로 송신할 수도 있다. 모든 AP들로부터의 UniFi_CTS(3412 및 3413)의 수신 시, WTRU(3401)는 이용가능한 AP들에게 데이터를 송신할 수도 있다.

UniFi_CTS(3412 및 3413)는 직교 커버 코드(orthogonal cover code, OCC)에 의해 코드 도메인에서 직교화된 또는, 예를 들어, RTS에서 AP ID들의 순서로 합의한 송신 지연에 기초하여 시간적으로 직교화된 UniFi_CTS 프레임들로서 송신될 수도 있다. 이 경우, AP1(3402)은 SIFS 시간 지체(time lag) 후 UniFi_CTS를 전송할 수도 있는 반면 AP2(3403)는 (2*SIFS + duration_UniFi_CTS) 시간 지체 후 UniFi_CTS를 전송할 수도 있다. 전파 지연을 설명하기 위해, AP들 중 하나 이상으로부터의 송신은 위에서 설명된 제 1 실시형태에서 설명된 것과 유사한 방식으로 시간 조정될 수도 있다.

WTRU(3401)는 그 다음에 데이터(3414)를 AP1(3402) 및 AP2(3403)로 송신할 수도 있다. AP들은 성공적이면 전송된 데이터의 확인응답(3415)으로 응답할 수도 있다. 이 확인응답은, 1차 AP로부터의 단일 ACK, 시간적으로 직교화된 각각의 AP로부터의, 또는 직교 커버 코드에 의한 단일 ACK, 또는 CDD를 사용한 AP들 양쪽 모두로부터의 공동 ACK일 수도 있다.

도 34b에서, WTRU(3401)는 송신을 위한 채널을 예약하기 위해 UniFi_RTS 프레임(3421)을 AP1(3402)과 AP2(3403)로 송신할 수도 있다. WTRU(3401)로부터의 RTS의 수신 시, AP1(3402)과 AP2(3403)가 자신들의 가용성에 대해 서로 협응할 수 있으면, 그것들은 이용가능한 AP들에 대한 정보와 함께 공동 UniFi CTS(3422)를 전송할 수도 있다. 공동 UniFi CTS는 순환 지연 다이버시티(cyclic delay diversity, CDD)를 사용하여 AP들 양쪽 모두로부터 전송될 수도 있다. AP1(3402)과 AP2(3403)는 WTRU(3401)의 자원 예약을 확인하기 위해 공동 UniFi CTS(3422)를 WTRU(3401)로 송신할 수도 있다. 공동 UniFi CTS(3422)의 수신 시, WTRU(3401)는 데이터를 이용가능한 AP들로 송신할 수도 있다. 이 예에서 WTRU(3401)는 데이터(3423)를 AP1(3402)과 AP2(3403)로 송신할 수도 있다. AP들은 성공적이라면 전송된 데이터의 확인응답(3414)으로 응답할 수도 있다. 이 확인응답은, 1차 AP로부터의 단일 ACK, 시간적으로 직교화된 각각의 AP로부터의, 또는 직교 커버 코드에 의한 단일 ACK, 또는 CDD를 사용한 AP들 양쪽 모두로부터의 공동 ACK일 수도 있다. 도 34b의 예에서, 공동 ACK(3414)가 도시되어 있다.

상이한 중첩 UniFi 세트들을 갖는 복수의 AP들 및 다수의 WTRU들이 있을 수도 있는 시나리오들에서, 이를테면 UniFi 세트에서의 모든 AP들이 이용가능할 때 UniFi 송신이 허용될 수도 있다. 이 경우, 요청된 UniFi 세트에서의 모든 AP들이 CTS를 반환해야만 WTRU는 송신할 수도 있다. 모든 APS가 이용가능하고 WTRU는 송신을 시작하고 있다는 것을 나타내는 WTRU로부터의 부가적인 신호들이 또한 있을 수도 있다. 이는 CTS 대 셀프(CTS-to-self) 또는 수정된 CTS 대 셀프 프레임일 수도 있다. 다른 예에서, UniFi 송신은 UniFi 세트에서의 지정된 AP가 이용가능할 때 허용될 수도 있다. 이 경우, WTRU는 1차 AP를 지정할 수도 있는데, 이 1차 AP는 예를 들어 최저 경로 손실을 갖는 AP일 수도 있다. WTRU는 그 다음에 이 AP 및 이용가능한 임의의 다른 AP에게 송신할 수도 있다. 모든 AP 이용가능 사례들에서처럼, 데이터 송신의 시작을 나타내기 위해 부가적인 신호가 있는 것이 필요할 수도 있다. 또 다른 예에서, UniFi 세트에서의 임의의 AP가 이용가능하면, WTRU는 임의의 AP에게 송신하여 그것이 이용가능함을 나타낼 수도 있다.

도 35는 도 34a와 도 34b의 절차들에서 사용하기 위한 일 예 UniFi_RTS 프레임 포맷(3500)을 도시한다. UniFi_TRS(3201)는 다음의 필드들을 비제한적으로 포함할 수도 있다: 프레임 제어 필드(3501), 지속기간 필드(3502), 수신기 1 어드레스 필드(3503), 송신기 1 어드레스 필드(3504), UniFi RTS Rx 수(UniFi RTS No. of Rx) 필드(3506), 수신기 2 어드레스 필드(3507), 및 FCS 필드(3508). UniFi RTS Rx 수 필드(3506)는 송신이 UniFi 송신임과, UniFi 세트 식별자를 나타내는 정보를 포함할 수도 있다. 이 UniFi 세트 식별자는 UniFi 세트에서의 AP들의 수와 UniFi 세트의 AP들의 각각에 대한 개개의 AP ID들을 나타내는 필드 세트, 즉 {2, AP1, AP2}일 수도 있다. 대안으로, UniFi 세트는 AP 세트를 위한 그룹 식별자로서 역할을 하는 단일 UniFi ID일 수도 있다. UniFi_ID는 UniFi 그룹 식별자 배정 프레임에 의해 UniFi 송신 설정 동안 배정될 수도 있다.

UniFi_CTS는 WTRU가 UniFi_RTS로 전송하였다는 사실에 기초하여 UniFi CTS로서 암시적으로 해석하는 레거시 CTS일 수도 있다. 대안으로, CTS가 UniFi RTS에 기초함을 나타내는 부가적인 정보를 갖는 수정된 CTS가 사용될 수도 있다.

도 36은 도 34a의 절차에서 사용될 수도 있는 독립적인 UniFi_CTS 프레임(3600)을 도시한다. 독립적인 UniFi_CTS 프레임은 다음의 필드들을 비제한적으로 포함할 수도 있다: 프레임 제어 필드(3601), 지속기간 필드(3602), 송신기 어드레스 필드(3603), UniFi RTS Rx 수 필드(3604), 수신기 x 어드레스 필드(3605), 및 FCS 필드(3606). UniFi RTS Rx 수 필드(3604)는 UniFi 세트에서 예상되는 AP들의 수와 CTS를 반환하는 AP의 어드레스를 나타내는 필드를 포함할 수도 있다. 이것이 독립적인 UniFi_CTS 프레임이기 때문에, 요청된 자원이 AP에 의해 사용중일 때, UniFi_CTS는 당해 특정 AP에 의해 송신되지 않을 수도 있다. AP들에 의해 송신되는 독립적인 UniFi_CTS 프레임들은 WTRU에서 구별될 수도 있다.

도 37은 도 34b의 절차에서 사용될 수도 있는 공동 UniFi_CTS 프레임(3700)을 도시한다. 공동 UniFi_CTS 프레임은 다음의 필드들을 비제한적으로 포함할 수도 있다: 프레임 제어 필드(3701), 지속기간 필드(3702), 송신기 어드레스 필드(3703), UniFi RTS Rx 수 필드(3704), 수신기 x 어드레스 필드(3705), 수신기 2 어드레스 필드(3706), 및 FCS 필드(3707). UniFi RTS Rx 수 필드(3704)는 도 37에 도시된 바와 같이 UniFi 세트에서 예상되는 AP들의 수와 CTS를 반환하는 AP의 어드레스들을 나타내는 필드를 포함할 수도 있다. 이것이 UniFi 세트 식별자일 수도 있다는 점에 주의한다.

도 38은 그룹 ID 및 부가적인 AP ID들을 갖는 데이터 프레임의 일 예(3800)를 도시한다. 송신된 데이터의 PLCP 헤더는 업링크 UniFi 송신을 나타내는 플래그를 포함하도록 수정될 수도 있다. 덧붙여서, 송신된 데이터의 PLCP 헤더는 송신을 도모하는 AP들을 식별하는 UniFi 세트 식별자를 포함하도록 수정될 수도 있다. 이는 수신을 위해 이용가능한 AP들의 AP ID들을 명시적으로 열거하는 것, 수신을 위해 이용가능한 AP들을 나타내는 AP 그룹 식별자 UniFi ID를 사용하는 것, 또는 (단일의 선택된 AP을 이용한 별개의 디코딩의 경우의) 단일의 선택된 AP ID를 사용하는 것 중 어느 하나에 의해 수행될 수도 있다. 도 38의 예에서, 다음의 필드들이 사용된다: 프레임 제어 필드(3801), 지속기간 id 필드(3802), 어드레스1 unifi grp ID 필드(3803), 어드레스2 필드(3804), 어드레스3 필드(3805), 시퀀스 제어 필드(3806), 어드레스4 필드(3807), QoS 제어 필드(3808), HT 제어 필드(3809), 어드레스 AP1 필드(3810), 어드레스 APx 필드(3811), 프레임 바디 필드(3812), 및 FCS 필드(3813).

도 39a와 도 39b는 사용될 수도 있는 수정된 ACK들의 예들(3900)을 도시한다. 도 39a는 다수의 수신 어드레스들을 포함할 수도 있는 공동 ACK의 일 예를 도시한다. 도 39a의 공동 ACK는 다음의 필드들을 비제한적으로 포함할 수도 있다: 프레임 제어 필드(3901), 지속기간 필드(3902), 수신기 어드레스 필드(3903), 수신기 2 어드레스 필드(3904), 수신기 n 어드레스 필드(3905), 및 FCS 필드(3906).

대안으로, 다수의 별개의 ACK들이 단일 프레임 속으로 결집될 수도 있다. 도 39b는 결집된 ACK의 일 예를 도시하는데, 그 ACK는 다음의 필드들을 비제한적으로 포함할 수도 있다: 프레임 제어 필드(3911), 지속기간 필드(3912), 수신기 어드레스 1 필드(3913), FCS 필드(3914), 프레임 제어 필드(3915), 지속기간 필드(3916), 수신기 어드레스 1 필드(3917), 및 FCS 필드(3918).

도 40은 제 5 실시형태에 따른 공간적 협응형 다중-AP 송신(SCMAT)의 그룹화의 일 예(4000)를 도시하는데, 그것은 본원에서 설명되는 실시형태들 중 임의의 것과 조합하여 사용될 수도 있다. SCMAT는 하나 또는 다수의 WTRU들과 통신하는 복수의 AP들이 공동 및/또는 빔포밍된/섹터화된 송신들에서 공간적 특성들을 활용하는 것을 허용하기 위해 사용될 수도 있다. 관련된 AP들 및 WTRU들의 그룹화는 실제 UniFi 송신들 전에 확립되고 제공될 수도 있다. 도 40의 예에서, WTRU1(4001)은 AP1(4002)과 AP2(4003) 양쪽 모두를 들을 수도 있다. 마찬가지로, WTRU2(4004)는 AP1(4002)과 AP2(4003) 양쪽 모두를 들을 수도 있다. AP1(4002)과 AP2(4003)는 무선 접속 접속 또는 유선 접속 중 어느 하나를 통해 서로 통신할 수도 있다. 따라서, SCMAT 송신에 관계되는 모든 디바이스들은 서로 들을 수도 있다. AP들과 WTRU들은 그것들이 SCMAT 송신들을 수행하도록 함께 그룹화될 수도 있다. SCMAT 능력들을 갖는 AP들 및 WTRU들은 프로브 응답, 비콘, 및 연관 응답 프레임들과 같은 프레임들로 SCMAT 능력을 알릴 수도 있다. 이 SCMAT 능력 정보는 예를 들어 VHT 능력 엘리먼트에서 정의될 수도 있다.

그룹화 기준들은 고유하지 않을 수도 있고 여러 예의 기준들이 아래에서 설명된다. 예를 들어, AP들은 수신 전력에 따라 WTRU들을 그룹화하도록 선택할 수도 있다. 예를 들어, WTRU1(4001)은 AP2(4003)로부터의 신호보다 더 강한 신호 또는 그 신호와 동일한 세기의 신호 중 어느 하나의 신호를 AP1(4002)로부터 수신할 수도 있다. 마찬가지로, WTRU2(4004)는 AP1(4002)로부터의 신호보다 더 강한 신호 또는 그 신호와 동일한 세기의 신호 중 어느 하나의 신호를 AP2(4003)로부터 수신할 수도 있다. 더구나, SCMAT 송신에 관련된 WTRU들 양쪽 모두는 AP들 양쪽 모두를 들을 수 있는 것이 또한 요구할 수도 있다. 그렇지 않고, WTRU들이 자신 소유의 AP만을 들을 수 있다면, SCMAT 송신이 필요하지 않을 수도 있다.

제 2 예에서, AP들은 공간적 분리 정도에 따라 WTRU들을 그룹화하도록 선택할 수도 있다. 예를 들어, SCMAT의 목적은 복수의 AP들이 다수의 WTRU들에게 동시에 송신하는 것을 허용하는 것일 수도 있다. AP는 공간적 가중치 세트를 선택할 수도 있는데, 그 공간적 가중치 세트는 소망의 WTRU에 대한 신호 세기들을 향상시키고 다른 원치 않는 WTRU(들)에 대한 신호 세기들을 동시에 억제한다. 이 경우, 소망의 WTRU 및 원치 않는 WTRU 간의 공간적 분리간격은 가능한 한 클 수도 있다.

제 3 예에서, AP들은 비교적 큰 패킷 사이즈들을 갖는 WTRU들을 그룹화하도록 선택될 수도 있고, 각각의 공간적 송신 링크의 패킷 사이즈는 유사할 수도 있다. 여분의 오버헤드로 인해 패킷 사이즈가 너무 작다면, 효율적이지 않을 수도 있다. 더구나, SCMAT 송신의 하나의 요건은 모든 DL 데이터 송신 후에 WTRU들이 ACK로 회신하는 것일 수도 있다. 그러므로, 각각의 공간적 링크의 패킷 사이즈가 많이 다르면, 전체적으로 효율적이지 않을 수도 있다.

제 4 예에서, AP들은 QoS 요건들에 따라 WTRU들을 그룹화할 것을 선택할 수도 있다. 예를 들어, 일부 패킷들은 지연 및 지터에 대한 엄격한 요건들을 가질 수도 있으며; 이들 패킷들의 송신을 가능한 한 빨리 구성하는 것이 좋을 수도 있다. 다른 선택은 유사한 QoS 범주를 갖는 패킷들을 그룹화하는 것일 수도 있다.

그룹화 메커니즘은 선택된 그룹화 기준들에 기초할 수도 있다. 전력 기준은 가능한 그룹화 메커니즘들을 설명하는 일 예로서 이용될 수도 있다. SCMAT 능력을 갖고 AP1(4002)에 연관된 WTRU들은 AP2(4003)의 RSSI 또는 다른 신호 측정들이 특정한 문턱값들을 초과하면 그 RSSI 또는 다른 측정들을 AP1(4002)에게 보고할 수도 있다. 이런 식으로, AP1(4002)은 AP2(4003)를 청취할 수도 있는 자신의 BSS에서의 모든 WTRU들로부터 정보를 수집할 수도 있다. AP1(4002)은 이 정보를 AP2(4003)에게 무선 접속, 또는 유선 접속을 통해 전송할 것을 선택할 수도 있는데, 이 선택은 예를 들어 제어기에 의해 달성될 수도 있다. AP2(4003)는 유사한 절차를 수행하고 관련 정보를 AP1(4002)에게 무선 접속 또는 유선 접속을 통해 또는 제어기를 통해 전송할 수도 있다. AP1(4002)과 AP2(4003)는 그 다음에 SCMAT 그룹의 후보들을 선택하기 위해 서로 협상할 수도 있다.

SCMAT 그룹을 형성하기 위하여, AP1(4002)과 AP2(4003)는 SCMAT 그룹 관리 프레임들을 후보 WTRU들, 즉 도 40에 도시된 바와 같은 WTRU1(4001) 및 WTRU2(4004)에게 송신할 수도 있다. 도 40의 시스템은 일 예로서 역할을 하기 위한 것이고 SCMAT 그룹을 형성하는 것은 임의의 수의 WTRU들로 확장할 수도 있다. SCMAT 그룹 관리 프레임은 범주 VHT의 액션 프레임일 수도 있다. 그것은 하나의 그룹에서 정의된 하나를 초과하는 AP를 허용하는 수정들로 정의된 그룹 ID 관리 프레임 포맷을 추종할 수도 있다.

SCMAT 그룹 관리 프레임의 일 예 포맷이 아래의 표 19에 도시되어 있다.

순서	정보
1	범주
2	VHT 액션
3	구성원 스테이터스 어레이
4	사용자 포지션 어레이

범주 필드는 VHT에 대한 값으로 설정될 수도 있다. VHT 액션 필드는 SCMAT 그룹 관리를 위한 값으로 설정될 수도 있다. 구성원 스테이터스(membership status) 어레이 필드는, 예를 들어, 그룹 ID 관리 프레임을 따르는 비트맵 포맷을 사용할 수도 있다. 허용된 SCMAT 그룹 ID들의 최대 수는 표준 사양 또는 WLAN 시스템에 의해 정의될 수도 있다. 예를 들어, 64 개까지의 SCMAT 그룹들이 허용되면, 구성원 스테이터스 어레이 필드는 64 개의 비트들을 포함할 수도 있는데, 여기서 비트 n은 SCMAT 그룹 ID n-1에서의 구성원 스테이터스를 정의한다. 비트 n을 0으로 설정하는 것은 WTRU/AP가 그룹 n-1의 구성원이 아닐 수도 있다는 것을 의미하는 반면, 비트 n을 1 설정하는 것은 WTRU/AP가 그룹 n-1의 구성원임을 의미한다.

사용자 포지션 어레이 필드는 그룹에서의 사용자 포지션을 정의하는데 사용될 수도 있다. SCMAT 송신이 AP들 및 WTRU들 모두에 관계하므로, 송신기들(AP들) 및 수신기들(WTRU들) 간에는 명확한 분할이 있을 수도 있다. 예를 들어, 각각의 SCMAT 그룹이 AP들 및 WTRU들 모두를 포함한 2^2N 개까지의 디바이스들을 갖는 것을 시스템이 허용하면, 사용자 포지션 어레이 필드는 2N x M 개의 비트들을 포함할 수도 있다. 여기서 M은 허용된 SCMAT 그룹 ID들의 최대 수일 수도 있다.

도 41은 사용자 포지션 어레이 필드의 일 예(4100)를 제공한다. 도 41에 도시된 바와 같이, 각각의 SCMAT 그룹(4101, 4102), 및 4103)은 2N 개의 비트들을 가지며, 여기서 비트 0 내지 비트 N-1은 AP들의 포지션을 정의하고 비트 N 내지 비트 2N-1은 WTRU들의 포지션을 정의한다. 이런 식으로, 사용자 포지션 값 k를 갖는 AP는 k= 0, ... N-1인 N+k와 동일한 사용자 포지션 값을 갖는 WTRU에게 패킷을 송신할 수도 있다.

AP들의 사용자 포지션이 다른 방법들로 정의될 수도 있으므로, 각각의 그룹에 대한 WTRU들의 사용자 포지션을 식별하기 위해 N 개의 비트들을 유지하는 대안적 선택이 있을 수도 있다. SCMAT 그룹 ID를 사용하는 것이 고유한 그룹을 정의하는데 충분하지 않을 수도 있다는 점에 주의한다. 예를 들어, 3 개의 AP들 및 4 개의 WTRU들을 갖는 시스템에서, AP1과 AP2는 AP1, AP2, WTRU1, 및 WTRU2를 포함한 그룹을 식별하기 위해 SCMAT 그룹 ID k를 사용할 수도 있다. 동시에, AP1과 AP3은 구성원들(AP1, AP3, WTRU3, 및 WTRU4)을 갖는 다른 그룹을 식별하기 위해 동일한 ID k를 사용할 것이다. AP1이 ID k를 참조할 때, WTRU1, WTRU2, WTRU3, WTRU4는 이 ID k가 자신들을 위한 그룹 ID라고 믿을 수도 있다.

도 42a는 SCMAT 그룹 관리 프레임을 위한 부분적 MAC 헤더의 일 예(4200)를 제공한다. SCMAT 그룹 관리 프레임은 다음의 예의 필드들을 비제한적으로 포함할 수도 있다: 프레임 제어 필드(4211), 지속기간 필드(4212), addr1 필드(4213), addr2 필드(4214), addr3 필드(4215), 및 addr4 필드. 각각의 디바이스는 그룹을 고유하게 식별하기 위해 SCMAT 그룹 ID 및 AP의 MAC 어드레스를 체크할 수도 있다. SCMAT 그룹에 AP MAC 어드레스를 포함시키는 2 개의 예의 방법들이 있다. 제 1 예의 방법에서, AP MAC 어드레스가 SCMAT 그룹 ID 관리 프레임에 추가될 수도 있다. 예를 들어, '순서 5'는 표 19에 AP MAC 어드레스로서 추가될 수도 있다. 양쪽 모두의 AP들에 대한 MAC 어드레스들은 이 필드에 포함될 수도 있다. AP MAC 어드레스들의 순서는 AP들의 사용자 포지션을 뜻하는데 이용될 수도 있다.

제 2 예의 방법에서, MAC 헤더에 정의된 4 개의 어드레스 필드들은 재사용될 수도 있다. 이런 식으로, 4 개의 어드레스 필드들은 재정의될 수도 있다. 도 42에 도시된 바와 같이, addr1(4213)은 AP1의 MAC 어드레스일 수도 있으며; addr2(4214)는 AP2의 MAC 어드레스일 수도 있다. Addr3(4215)은 WTRU1의 MAC 어드레스로서 수정될 수도 있으며, addr4(4216)는 WTRU2의 MAC 어드레스로서 수정될 수도 있다. 패킷의 수신 시, 디바이스는 이것이 SCMAT 그룹 관리 프레임이라는 것을 알 수 있다. 디바이스는 MAC 헤더에서의 어드레스 필드를 다시 찾아가고 자신 소유의 MAC 어드레스와 4 개의 어드레스 필드들을 비교할 수도 있다. 일단 그것들 중의 하나와 일치하면, SCMAT 그룹을 추가로 식별하기 위해 리스트 내에 SCMAT 그룹 ID 및 addr1(4213) 및 addr2(4214)를 유지할 수도 있다. 이런 식으로, AP2에 연관되는 WTRU들은 AP1 역시 청취할 수도 있다. 어드레스 매핑의 순서는 본원에서 설명되는 것과 상이할 수도 있다. 그러나, 그것은 사양이 앞 부분에 붙어야 한다.

도 42b는 SCMAT 그룹을 형성하기 위해 SCMAT 그룹 관리 프레임을 이용하는 일 예의 절차를 제공한다. 이 예에서, SCMAT 그룹 관리 프레임은 다음과 같이 구성될 수도 있다: addr1은 AP1(4223)의 MAC 어드레스일 수도 있으며, addr2는 AP2(4224)의 MAC 어드레스일 수도 있으며, addr3은 WTRU1(4221)의 MAC 어드레스로서 수정될 수도 있고, addr4는 WTRU2(4222)의 MAC 어드레스로서 수정될 수도 있다. AP1(4223)은 개시자(initiator) AP일 수도 있고 자신을 AP 사용자 포지션 값 0으로 설정할 수도 있다. AP1(4223)은 AP2(4224)에게 정보를 제공하고 AP2(4224)를 사용자 포지션 값 1로 설정할 수도 있다(4231). 이는 유선 접속 또는 무선 접속으로 행해질 수도 있다. 무선 접속으로, SCMAT 그룹 관리 프레임이 AP1로부터 AP2로 송신될 수도 있다(4232). 사용자 포지션 어레이 필드가 2N x M 개의 비트들을 포함하면, AP2의 사용자 포지션은 명시적으로 할당될 수도 있다. 사용자 포지션 어레이 필드가 N x M 개의 비트들을 포함한다면, 사용자 포지션 어레이 필드는 WTRU들에 대한 포지션을 식별하기 위해서만 사용될 수도 있다. 이 경우, AP2는 MAC 헤더의 addr3 및 addr4를 조사하고, 사용자 포지션을 암시적으로 얻을 수도 있다. AP1(4223)은 그 다음에 SCMAT 그룹 관리 프레임을 WTRU1(4221)로 전송할 수도 있다(4233). AP2(4224)는 SCMAT 그룹 관리 프레임을 WTRU2(4222)로 전송할 수도 있다(4234). AP1(4223)이 SCMAT 그룹 관리 프레임을 WTRU2(4222)로 전송하는 것(4235)과, AP2(4224)가 SCMAT 그룹 관리 프레임을 WTRU1(4221)로 전송하는 것은, 심지어 그것들이 연관되지 않더라도, 또한 가능할 수도 있다.

도 43은 SCMAT 관련된 송신을 위해 정의된 프레임 포맷의 일 예(4300)를 제공한다. 이 프레임은 프리앰블(4301), SIG 필드(4302), 프레임 바디(4303), MAC 헤더(4304), MAC 바디(4305), 프레임 제어 필드(4306), 지속기간 필드(4307), addr1 필드(4308), addr2 필드(4309), addr3 필드(4310), 및 addr4 필드(4311)를 비제한적으로 포함할 수도 있다. 이 프레임 포맷은 SCMAT 관련된 송신들, 예를 들어, NDPA 프레임들, NDP 프레임들; ADD-SCMAT 프레임들, A-SCMAT 프레임들 ACK 프레임들에 의해 이용될 수도 있다. SCMAT 데이터 프레임들은 이 프레임 포맷 또한 이용할 수도 있다. 이 예에서, 하나의 비트가 SIG 필드에 추가되는데, 이는 이것이 SCMAT 프레임임을 나타낸다. SCMAT 그룹 ID는 SIG 필드에도 역시 포함될 수도 있다. SCMAT 그룹 ID의 정의에 따라, MAC 헤더에서의 4 개의 어드레스 필드들이 둘 이상의 관련된 AP들을 식별하기 위해 재정의될 수도 있다.

실시형태들:

1. 무선 통신에서 사용하기 위한 방법으로서, 다중 무선 송수신 유닛(multi wireless transmission/receive unit)(다중-WTRU) 공동 송신 능력 표시를 포함하는 프레임을 수신하는 단계를 포함하는, 무선 통신에서 사용하기 위한 방법.

2. 실시형태 1에 있어서, 다중-WTRU 공동 송신 능력 표시는 공동 송신 능력 정보 엘리먼트(information element, IE)인, 무선 통신에서 사용하기 위한 방법.

3. 실시형태 1에 있어서, 상기 프레임은 관리 프레임인, 무선 통신에서 사용하기 위한 방법.

4. 실시형태 1에 있어서, 상기 프레임은 제어 프레임인, 무선 통신에서 사용하기 위한 방법.

5. 제 1 항에 있어서, 상기 프레임은 데이터 프레임인, 무선 통신에서 사용하기 위한 방법.

6. 실시형태 1 내지 실시형태 5 항 중 어느 한 실시형태에 있어서, 이웃 액세스 포인트(access pointAP) 능력을 모니터링하는 단계를 더 포함하는, 무선 통신에서 사용하기 위한 방법.

7. 실시형태 1 내지 실시형태 6 중 어느 한 실시형태에 있어서, 적어도 하나의 WTRU의 채널 특성을 모니터링하는 단계를 더 포함하는, 무선 통신에서 사용하기 위한 방법.

8. 실시형태 6 또는 실시형태 7에 있어서, 수신용 WTRU(R-WTRU)에게 비콘 라디오 측정을 수행하라는 요청을 송신하는 단계를 더 포함하는, 무선 통신에서 사용하기 위한 방법.

9. 실시형태 8에 있어서, 측정 및 R-WTRU 피드백에 기초하여 후보 보조 AP(candidate assistant AP, ATAP)를 선택하는 단계를 더 포함하는, 무선 통신에서 사용하기 위한 방법.

10. 실시형태 9에 있어서, 후보 ATAP에게 공동 송신 질의를 송신하는 단계를 더 포함하는, 무선 통신에서 사용하기 위한 방법.

11. 실시형태 10에 있어서, AP로부터의 수신된 공동 송신 피드백에 기초하여 하나 이상의 R-WTRU들을 위한 ATAP를 선택하는 단계를 더 포함하는, 무선 통신에서 사용하기 위한 방법.

12. 연관된 액세스 포인트(associated access point, AAP)로서, 송신기; 및 멀티스테이션(다중-WTRU) 공동 송신 능력 표시를 포함하는 프레임을 수신하도록 구성된 수신기를 포함하는, 연관된 액세스 포인트(associated access point, AAP).

13. 실시형태 12에 있어서, 다중-WTRU 공동 송신 능력 표시는 공동 송신 능력 정보 엘리먼트(information element, IE)인, AAP.

14. 실시형태 12에 있어서, 프레임은 관리 프레임인, AAP.

15. 실시형태 12에 있어서, 프레임은 제어 프레임인, AAP.

16. 실시형태 12에 있어서, 프레임은 데이터 프레임인, AAP.

17. 실시형태 12 내지 실시형태 16 중 어느 한 실시형태에 있어서, 상기 AAP는 이웃 액세스 포인트(access point, AP) 능력을 모니터링하는 것을 더 포함하는, AAP.

18. 실시형태 12 내지 실시형태 17 중 어느 한 실시형태에 있어서, 상기 AAP는 적어도 하나의 WTRU의 채널 특성을 모니터링하는 것을 더 포함하는, AAP.

19. 실시형태 17 또는 실시형태 18에 있어서, 수신용 WTRU(R-WTRU)에게 비콘 라디오 측정을 수행하라는 요청을 송신하는 것을 더 포함하는, AAP.

20. 실시형태 19에 있어서, 상기 AAP는, 측정 및 R-WTRU 피드백에 기초하여 후보 보조 AP(candidate assistant AP, ATAP)를 선택하는 단계를 더 포함하는, AAP.

21. 실시형태 20에 있어서, 상기 AAP는, 후보 ATAP에게 공동 송신 질의를 송신하는 것을 더 포함하는, AAP.

22. 실시형태 21에 있어서, 상기 AAP는, AP로부터의 수신된 공동 송신 피드백에 기초하여 하나 이상의 R-WTRU들을 위한 ATAP를 선택하는 것을 더 포함하는, AAP.

23. 연관된 액세스 포인트(associated access point, AAP)에서 사용하기 위한 방법으로서, 공동 송신 요청을 송신하는 단계; 공동 송신 응답을 수신하는 단계; 공동 송신 협상을 수행하는 단계; 및 공동 송신 협상에 기초하여 데이터를 송신하는 단계를 포함하는, AAP에서 사용하기 위한 방법.

24. 연관된 액세스 포인트(associated access point, AAP)에서의 사용을 위한 방법으로서, 제 1 매체 상에서, 공동 송신 요청을 송신하는 단계; 제 1 매체 상에서, 공동 송신 응답을 수신하는 단계; 제 2 매체 상에서 공동 송신 협상을 수행하는 단계; 제 2 매체 상에서 공동 송신 RTS(request-to-send) 프레임을 송신하는 단계; 제 2 매체 상에서 보조 AP(assistant AP, ATAP)로부터 공동 송신 CTS(clear-to-send) 프레임을 수신하는 단계; 및 제 2 매체 상에서 데이터를 송신하는 단계를 포함하는, AAP에서의 사용을 위한 방법.

25. 실시형태 24에 있어서, 제 1 매체는 LTE(Long Term Evolution) 매체인, AAP에서의 사용을 위한 방법.

26. 실시형태 24에 있어서, 제 1 매체는 802.11 매체인, AAP에서의 사용을 위한 방법.

27. 실시형태 24에 있어서, 제 1 매체는 유니버셜 이동 통신 시스템(Universal Mobile Telecommunications System, UMTS) 매체인, AAP에서의 사용을 위한 방법.

28. 실시형태 24의 방법에 있어서, 제 1 매체는 WiMAX(Worldwide Interoperability for Microwave Access) 매체인, AAP에서의 사용을 위한 방법.

29. 실시형태 24 내지 실시형태 28 중 어느 한 실시형태에 있어서, 제 2 매체는 802.11 매체인, AAP에서의 사용을 위한 방법.

30. 실시형태 24 내지 실시형태 29 중 어느 한 실시형태에 있어서, 다중 무선 송수신 유닛(multi wireless transmission/receive unit)(다중-WTRU) 공동 송신 능력 표시는 협응형 섹터화된 동작에 대한 지원을 나타내는, AAP에서의 사용을 위한 방법.

31. 실시형태 24 내지 실시형태 30 중 어느 한 실시형태에 있어서, 다중 무선 송수신 유닛(multi wireless transmission/receive unit)(다중-WTRU) 공동 송신 능력 표시는 협응형 빔포밍 동작에 대한 지원을 나타내는, AAP에서의 사용을 위한 방법.

32. 실시형태 24 내지 실시형태 31 중 어느 한 실시형태에 있어서, WTRU는 협응형 섹터화된 동작을 수행하는, AAP에서의 사용을 위한 방법.

33. 실시형태 24 내지 실시형태 32 중 어느 한 실시형태에 있어서, 협응형 섹터화된 동작은 AP에 의해 제공된 스케줄에 기초하는, AAP에서의 사용을 위한 방법.

34. 실시형태 24 내지 실시형태 33 중 어느 한 실시형태에 있어서, 협응형 빔포밍된 동작은 AP에 의해 제공된 스케줄에 기초하는, AAP에서의 사용을 위한 방법.

35. 실시형태 24 내지 실시형태 34의 방법들 중 어느 하나의 방법을 수행하도록 구성된 연관된 액세스 포인트(associated access point, AAP).

36. 실시형태 24 내지 실시형태 34의 방법들 중 어느 하나의 방법을 수행하도록 구성된 집적 회로.

37. 실시형태 24 내지 실시형태 34의 방법들 중 어느 하나의 방법을 수행하도록 구성된 이동국(mobile station, STA).

38. 실시형태 24 내지 실시형태 34의 방법들 중 어느 하나의 방법을 수행하도록 구성된 AP.

39. 실시형태 24 내지 실시형태 34의 방법들 중 어느 하나의 방법을 수행하도록 구성된 네트워크.

40. 실시형태 24 내지 실시형태 34의 방법들 중 어느 하나의 방법을 수행하도록 구성된 무선 통신 시스템.

41. 실시형태 24 내지 실시형태 34의 방법들 중 어느 하나의 방법을 수행하도록 구성된 기지국.

42. 실시형태 24 내지 실시형태 34의 방법들 중 어느 하나의 방법을 수행하도록 구성된 WTRU.

비록 특징들과 엘리먼트들이 특정 조합들에서 위에서 설명되어 있지만, 당업자는 각각의 특징 또는 엘리먼트가 단독으로 또는 다른 특징들 및 엘리먼트들과의 임의의 조합으로 사용될 수 있다는 것이 이해될 것이다. 비록 위에서 설명된 해법들이 802.11 특정 프로토콜들을 고려하지만, 본원에서 설명되는 해법들이 이 시나리오로 제한되지 않고 다른 무선 시스템들에도 적용가능하다는 것이 이해된다. 덧붙여서, 본원에서 설명되는 방법들은 컴퓨터 프로그램, 소프트웨어, 또는 컴퓨터 또는 프로세서에 의한 실행을 위해 컴퓨터 판독가능 매체에 통합된 펌웨어에서 구현될 수도 있다. 컴퓨터-판독가능 매체들의 예들은 (유선 또는 무선 접속들을 통해 송신되는) 전자 신호들 및 컴퓨터-판독가능 저장 매체들을 포함한다. 컴퓨터-판독가능 저장 매체들의 예들은, 판독 전용 메모리(ROM), 랜덤 액세스 메모리(RAM), 레지스터, 캐시 메모리, 반도체 메모리 디바이스들, 내장형 하드 디스크들 및 착탈식 디스크들과 같은 자기 매체들, 자기-광 매체들, 그리고 CD-ROM 디스크들 및 디지털 다기능 디스크들(DVD들)과 같은 광 매체들을 포함하지만 그것들로 제한되지 않는다. 소프트웨어에 관련한 프로세서가 WTRU, UE, 단말, 기지국, RNC, 또는 임의의 호스트 컴퓨터에서의 사용을 위해 무선 주파수 트랜시버를 구현하는데 사용될 수도 있다.

Claims (20)

1. IEEE 802.11 무선 송수신 유닛(wireless transmit/receive unit, WTRU)에서의 사용을 위한 방법에 있어서,
   액세스 포인트(access point, AP)로, 상기 IEEE 802.11 WTRU가 상기 IEEE 802.11 WTRU와 연관된 적어도 하나의 섹터에서의 섹터화된 동작을 지원한다는 것을 표시하는 제1 섹터화된 빔포밍 능력 정보 엘리먼트(Information Element, IE)를 포함하는 요청 프레임을 송신하는 단계;
   상기 AP로부터, 상기 AP가 상기 IEEE 802.11 WTRU와 연관된 적어도 하나의 섹터에서의 섹터화된 동작을 지원한다는 것을 표시하는 제2 섹터화된 빔포밍 능력 IE를 포함하는 응답 프레임을 수신하는 단계;
   상기 적어도 하나의 섹터에서의 섹터 송신의 스케쥴링을 포함하는 섹터화된 비콘 프레임을 수신하는 단계;
   상기 AP로, 상기 섹터화된 비콘 프레임의 상기 섹터 송신의 스케쥴링에 기초하여 데이터 패킷을 송신하는 단계
   를 포함하는, IEEE 802.11 WTRU에서의 사용을 위한 방법.
2. 제 1 항에 있어서,
   상기 섹터 송신의 스케쥴링은 섹터 ID 및 상기 섹터화된 동작의 지속기간을 포함하는 것인, IEEE 802.11 WTRU에서의 사용을 위한 방법.
3. 제 2 항에 있어서
   상기 섹터 ID 및 상기 섹터화된 동작의 지속기간에 기초하여 데이터 패킷을 송신하는 단계를 더 포함하는 IEEE 802.11 WTRU에서의 사용을 위한 방법.
4. 제 1 항에 있어서,
   상기 요청 프레임은 연관 요청 프레임인 것인, IEEE 802.11 WTRU에서의 사용을 위한 방법.
5. 제 1 항에 있어서,
   상기 응답 프레임은 연관 응답 프레임인 것인, IEEE 802.11 WTRU에서의 사용을 위한 방법.
6. IEEE 802.11 무선 송수신 유닛(wireless transmit/receive unit, WTRU)에 있어서,
   액세스 포인트(access point, AP)로, 상기 IEEE 802.11 WTRU가 상기 IEEE 802.11 WTRU와 연관된 적어도 하나의 섹터에서의 섹터화된 동작을 지원한다는 것을 표시하는 제1 섹터화된 빔포밍 능력 정보 엘리먼트(Information Element, IE)를 포함하는 요청 프레임을 송신하도록 구성된 송신기;
   상기 AP로부터, 상기 AP가 상기 IEEE 802.11 WTRU와 연관된 적어도 하나의 섹터에서의 섹터화된 동작을 지원한다는 것을 표시하는 제2 섹터화된 빔포밍 능력 IE를 포함하는 응답 프레임을 수신하도록 구성된 수신기
   를 포함하고,
   상기 수신기는 또한, 상기 적어도 하나의 섹터에서의 섹터 송신의 스케쥴링을 포함하는 섹터화된 비콘 프레임을 수신하도록 구성되고,
   상기 송신기는 또한, 상기 AP로, 상기 섹터화된 비콘 프레임의 상기 섹터 송신의 스케쥴링에 기초하여 데이터 패킷을 송신하도록 구성되는 것인,
   IEEE 802.11 WTRU.
7. 제 6 항에 있어서,
   상기 섹터 송신의 스케쥴링은 섹터 ID 및 상기 섹터화된 동작의 지속기간을 포함하는 것인, IEEE 802.11 WTRU.
8. 제 7 항에 있어서
   상기 송신기는 또한, 상기 섹터 ID 및 상기 섹터화된 동작의 지속기간에 기초하여 데이터 패킷을 송신하도록 구성되는 것인, IEEE 802.11 WTRU.
9. 제 6 항에 있어서,
   상기 요청 프레임은 연관 요청 프레임인 것인, IEEE 802.11 WTRU.
10. 제 6 항에 있어서,
    상기 응답 프레임은 연관 응답 프레임인 것인, IEEE 802.11 WTRU.
11. 무선 송수신 유닛(wireless transmit/receive unit, WTRU)에 있어서,
    액세스 포인트(access point, AP)로부터, 상기 AP가 상기 WTRU와 연관된 적어도 하나의 섹터에서의 섹터화된 동작을 지원한다는 것을 표시하는 섹터화된 빔포밍 능력 정보 엘리먼트(Information Element, IE)를 포함하는 관리 프레임을 수신하도록 구성된 수신기로서, 상기 수신기는 또한, 상기 적어도 하나의 섹터와 연관된 적어도 하나의 섹터 ID를 포함하는 섹터화된 비콘 프레임을 수신하도록 구성되는 것인, 수신기; 및
    상기 적어도 하나의 섹터 ID에 기초하여 상기 AP로 섹터화된 송신으로 패킷을 송신하도록 구성된 송신기
    를 포함하는 WTRU.
12. 제 11 항에 있어서,
    상기 송신기는 또한, 상기 AP로, 상기 WTRU가 상기 WTRU와 연관된 적어도 하나의 섹터에서의 섹터화된 동작을 지원한다는 것을 표시하는 제2 섹터화된 빔포밍 능력 IE를 포함하는 제2 관리 프레임을 송신하도록 구성되는 것인, WTRU.
    
13. 삭제
14. 삭제
15. 삭제
16. 삭제
17. 삭제
18. 삭제
19. 삭제
20. 삭제

Images