KR20190126125A - 다중-홉 릴레이 기반 지향성 무선 통신을 위한 방법 및 시스템 - Google Patents

Abstract

PHY 계층에서 이루어지는 다중-홉 릴레이 기반의 지향성 빔포밍 기반 무선 통신(mm-파 메시 네트워크) 방법 및 장치. 발신 STA로부터, 중간 STA들을 통해, 목적지 STA로 통신할 때 이웃하는 STA들 사이의 라우팅 프로토콜들을 개선시킴으로써 네트워크 능력이 향상된다. 라우팅은 이웃하는 STA들에 대한 간섭을 제한하기 위해 안테나 섹터 선택을 고려하고, 스루풋을 증가시키기 위해 채널 시간 이용률을 고려한다. 발신 STA와 목적지 STA 사이의 중간 스테이션들의 결정 및 라우팅을 최적화하기 위해 링크 메트릭들 및 채널 시간들이 확립된다. 이 장치 및 방법은 엔드-엔드 경로 링크 품질 및 간섭 영향 둘 다를 밸런싱한다.

Description

다중-홉 릴레이 기반 지향성 무선 통신을 위한 방법 및 시스템

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

해당 사항 없음

연방정부의 후원을 받은 연구 또는 개발에 관한 진술

해당 사항 없음

참조에 의한 컴퓨터 프로그램 부록의 포함

해당 사항 없음

저작권 보호를 받는 자료의 공지

본 특허 문서 내의 자료의 일부는 미국 및 다른 국가들의 저작권법 하에서 저작권 보호를 받을 수 있다. 저작권 권리의 소유자는, 특허 문서 또는 특허 개시내용의 타인에 의한 팩시밀리 복사가 미국 특허청의 공개적으로 입수가능한 파일이나 기록에 나타나는 경우라면 이의가 없지만, 그렇지 않다면 모든 저작권 권리를 보유한다. 이로써, 저작권 소유자는, 제한 없이 37 C.F.R. § 1.14에 따른 권리를 포함하여, 본 특허 문서를 비밀로 유지할 어떠한 권리도 포기하지 않는다.

1. 기술 분야

본 개시내용의 기술은 일반적으로 스테이션들 사이의 지향성 무선 통신, 보다 상세하게는 다중-홉 릴레이 기반 지향성 무선 통신(multiple-hop relayed directional wireless communication)에 관한 것이다.

2. 배경기술 논의

30 GHz 내지 300 GHz, 보다 바람직하게는 약 60 GHz와 같은, 밀리미터파(mm-파) 기술은 고 대역폭 통신을 위한 유망한 물리(PHY) 계층(예컨대, 7계층 OSI 모델) 기술이다. mm-파 PHY 계층에서의 특정한 통신 디바이스들은 자신의 열악한 링크 버짓을 완화시키기 위해 지향성 전송들을 사용하도록 구성된다. 전송이 빔포밍될 때, 다른 이웃 STA들에 대한 간섭을 완화시키는 것이 가능하다. 이론적으로, 이것은 보다 높은 시스템 용량을 가져오는데, 그 이유는 스펙트럼이, 2.4 GHz 또는 5 GHz WLAN과 같은, 비-빔포밍 기반(non-beam-formed) PHY와 비교하여 이웃하는 STA들에 의해 더 공격적으로(aggressively) 재사용될 수 있기 때문이다. 그렇지만, 현재의 시스템들은, 그들의 구성으로 인해, 이러한 이론적 한계들에 도달할 수 없다.

개선된 지향성 무선 라우팅 프로토콜들에 대한 요구가 존재한다. 그에 따라, 본 개시내용은 PHY 계층(즉, mm-파 PHY)에서 지향성 전송을 사용하고 본 명세서에서 mm-파 메시 네트워크라고 지칭되는 효율적인 다중-홉(멀티-홉(multi-hop)) 통신 네트워크를 설명한다. mm-파 PHY의 링크 버짓(link budget)이 빔포밍 기반 전송(beam-formed transmission)에서도 여전히 열악하다는 점이 주목되어야 한다. 멀티-홉 릴레이 능력을 추가(add)하는 것은 mm-파 PHY의 단점들 중 일부를 극복하기 위한 유망한 기술 믹스(technology mix)이다.

비록 mm-파 메시 네트워크의 개념이 새로운 것은 아니지만, 그러한 네트워크를 어떻게 운영하고 관리할지에 관한 많은 미지의 것들이 있으며, 현재 제공된 것들은 수많은 단점들을 갖는다.

본 개시내용은 mm-파 메시 네트워크에 새로운 운영 및 최적화 프로세스들을 제공한다. 보다 구체적으로는, 개시된 시스템, 장치 및/또는 방법은 mm-파 PHY를 통해 운영될 때 무선 메시 네트워크들의 기존의 라우팅 프로토콜들을 개선시키기 위한 컴포넌트들을 제공한다. 그에 부가하여, 이웃 스테이션들(STA들) 간의 스펙트럼 재사용을 용이하게 함으로써 네트워크 용량을 최대화하기 위한 접근법이 교시되어 있다.

본 개시내용에서 다수의 용어들이 발견되는데, 그 의미들은 일반적으로 아래에 설명되는 바와 같이 이용된다.

AODV: 애드혹 온-디맨드 거리 벡터(Ad-hoc On-Demand Distance Vector), 애드혹 무선 네트워크들에서의 데이터 패킷들에 대한 라우팅 프로토콜.

메시 네트워크들: 메시 네트워크 토폴로지에서, 각각의 노드는 네트워크에 대한 데이터를 릴레이하며(relays) 모든 메시 노드들은 네트워크에서의 데이터 분배에 협력한다. 메시 네트워크들은 한 유형의 애드혹(자발적(spontaneous), 즉흥적(impromptu) 또는 온-더-플라이 구성(on-the-fly construction)) 네트워크이다.

이웃 리스트: 이웃 STA들에 관한 정보를 포함하는 데이터 테이블. STA가 자신의 1홉 통신 영역(1hop communication area) 내의 다른 STA로부터 비컨 프레임(Beacon frame)과 같은 관리 프레임을 일단 수신하면, STA는 이웃 STA에 관한 정보를 자신의 메모리에 저장한다. STA는 이웃 STA로부터 관리 프레임들을 수신하는 것에 의해 데이터 테이블을 생성한다. STA는 다수의 이웃 STA들의 정보를 수집하고 그들의 정보를 이웃 리스트에 저장할 수 있다.

P2P: 2개 이상의 스테이션이 접속되고 별개의 제어기/서버를 거치지 않고 자원들을 공유할 때 피어-투-피어(P2P) 통신이 발생한다. P2P 네트워크는 애드혹 접속일 수 있다.

라우팅 테이블: 목적지 STA들까지의 루트(route)에 관한 정보를 저장하는 데이터 테이블. STA는 프레임을 목적지 STA로 전송하려고 시도할 때 프레임을 어느 바로 이웃 STA(immediate neighbor STA)로 전송할지(다음 홉 STA)를 결정하기 위해 라우팅 테이블을 룩업한다(looks up).

RREQ: 라우팅 요청(Routing Request), 소스 STA와 목적지 STA 사이의 경로(path)를 발견하기 위해 데이터 라우팅 프로토콜들에서 사용되는 패킷.

RREP: 라우팅 응답(Routing Reply), 라우팅 프로토콜들에서 RREQ에 응답하여 전송되는 패킷. 소스 STA에 의한 RREP의 수신 시에, 소스 STA는 데이터 패킷들을 전송하기 시작할 수 있다.

RSS: 수신 신호 강도(RSS)는 수신된 라디오 신호에 존재하는 전력의 측정치이다.

SSW: 섹터 스위프(Sector Sweep)는, 전송들이 상이한 섹터들(방향들)에서 수행되고 수신된 신호들, 강도들 등에 관한 정보가 수집되는, 동작이다.

STA: 스테이션(Station); 무선 매체(WM)에 대한 매체 액세스 제어(MAC) 및 물리 계층(PHY) 인터페이스의 개별적으로 어드레싱가능한 인스턴스(singly addressable instance)인 논리적 엔티티.

전형적인 메시 네트워크에서, 발신 STA(Originating STA)로부터 목적지 STA까지의 루트는 엔드-엔드 경로(end-end path)에 대한 중간 STA들을 선택하는 것에 의해 결정된다. 종종, AODV 예에서 알 수 있는 바와 같이, 사용을 위한 링크들이 최상의 링크 품질을 제공하도록 중간 STA들이 선택된다.

네트워크 용량 최적화를 위해, 전송들이 다른 전송들에 영향을 미치지 않도록 메시 링크들이 선택되는 것이 바람직하다. 그렇지만, 전송 신호들이 이웃하는 STA들로 방사되면 간섭을 관리하기가 어렵다.

지향성 전송이 사용되는 mm-파 PHY에서, 적절한 안테나 섹터를 선택함으로써 다른 이웃 STA들에 대한 간섭 영향을 제한하는 것이 가능하다. 무선 지향성 메시 네트워크들의 영역에서 우리의 종래의 특허 출원들에 개시된 기술들을 사용하여, STA들이 하나의 홉 이웃 STA들 사이의 각각의 안테나 섹터의 링크 품질을 탐지(learn)하는 것이 가능하다.

본 개시내용은, 예를 들어, 다음과 같은 것들 각각에 의해 멀티-홉 mm-파 메시 네트워크를 어떻게 최적화할지를 교시한다: (a) 엔드-엔드 루트를 결정하기 위해 라우팅 프로토콜을 실행하는 것; (b) 루트를 셋업할 때 사용하기 위한 적절한 안테나 섹터를 픽업하는 것; (c) 이웃 STA들의 채널 시간 이용률 및 이웃 STA들에서의 진행 중인 트래픽에 대한 영향을 고려하는 것; (d) 루트 셋업 시에 채널 시간을 할당하는 것; (e) 루트의 결정을 위해 순방향 링크 및 역방향 링크 메트릭을 누적하는 것; 및 (f) 멀티-홉 경로에 대한 중간 STA들을 결정하는 것.

이 기술의 다른 양태는 mm-파 메시 네트워크를 최적화하는 데 사용하기 위한 적절한 중간 STA들 및 안테나 섹터 둘 다를 픽업하는 것을 포함하도록 라우팅 결정 프로토콜들을 확장하는 것이다. 이 기술의 또 다른 양태는 엔드-엔드 경로 링크 품질 및 간섭 영향 둘 다를 밸런싱하는 능력이다.

본 명세서에 설명된 기술의 추가의 양태들은 본 명세서의 하기의 부분들에서 나타날 것이며, 여기서 상세한 설명은 기술의 바람직한 실시예들을 제한들을 두지 않고 완전히 개시하기 위한 것이다.

본 명세서에 설명된 기술은 단지 예시 목적들을 위한 것인 하기의 도면들을 참조하는 것에 의해 보다 완전히 이해될 것이다:
도 1은 본 개시내용의 실시예에 따라 이용되는 바와 같은, 다수의 스테이션들(STA들) 사이의 통신을 예시하는 라디오 노드 토폴로지 다이어그램이다.
도 2는 본 개시내용의 실시예에 따라 이용되는 바와 같은, 다수의 스테이션들(STA들) 사이의 통신을 위한 안테나 섹터 방향들을 예시하는 라디오 노드 토폴로지 다이어그램이다.
도 3은 본 개시내용의 실시예에 따라 이용되는 바와 같은 스테이션 하드웨어의 블록 다이어그램이다.
도 4는 본 개시내용의 실시예에 따라 STA들 상에서 이용되는 바와 같은 빔 패턴 다이어그램이다.
도 5는 본 개시내용의 실시예에 따라 이용되는 바와 같은 섹터 스위프 탐지 시퀀스(sector sweep learning sequence)이다.
도 6은 본 개시내용의 실시예에 따라 이용되는 바와 같은 이웃 리스트들에 대한 데이터 테이블이다.
도 7은 본 개시내용의 실시예에 따라 이용되는 바와 같은 이웃 정보 교환에 대한 데이터 필드 포맷이다.
도 8은 본 개시내용의 실시예에 따라 이용되는 바와 같은 이웃 정보 교환에 대한 에어-타임 다이어그램(air-time diagram)이다.
도 9는 본 개시내용의 실시예에 따라 이용되는 바와 같은 이웃 리스트 구성을 위한 데이터 테이블 포맷이다.
도 10은 본 개시내용의 실시예에 따라 이용되는 바와 같은 이웃 리스트 데이터 구조체 내의 데이터 포맷이다.
도 11은 본 개시내용의 실시예에 따라 이용되는 바와 같은 이웃하는 STA들 사이의 라우팅 테이블에 대한 데이터 포맷이다.
도 12a 및 도 12b는 본 개시내용의 실시예에 따라 이용되는 바와 같은 RREQ 및 RREP 프레임들에 대한 데이터 필드 포맷들이다.
도 13은 본 개시내용의 제1 실시예에 따른 발신 STA로부터 목적지 STA까지의 루트를 확립하는 동안 프레임 교환들을 위한 메시지 시퀀스이다.
도 14는 본 개시내용의 실시예에 따라 이용되는 바와 같은 발신 RREQ 전송 로직의 흐름 다이어그램이다.
도 15a 및 도 15b는 본 개시내용의 실시예에 따른 RREQ들을 이웃 STA들로 전파하는 것의 흐름 다이어그램이다.
도 16a 및 도 16b는 본 개시내용의 실시예에 따른 이웃하는 STA에 대한 송신 안테나 섹터를 결정하는 것의 흐름 다이어그램이다.
도 17은 본 개시내용의 실시예에 따라 이용되는 바와 같은, STA1@P1의 통신 시나리오에 대한 이웃 리스트 및 라우팅 테이블 구조체 예이다.
도 18a 및 도 18b는 본 개시내용의 실시예에 따른 RREQ 수신 절차의 흐름 다이어그램이다.
도 19는 본 개시내용의 실시예에 따라 이용되는 바와 같은, STA2@P2의 통신 시나리오에 대한 이웃 리스트 및 라우팅 테이블 구조체 예이다.
도 20은 본 개시내용의 실시예에 따라 이용되는 바와 같은, STA2@P5의 통신 시나리오에 대한 이웃 리스트 및 라우팅 테이블 구조체 예이다.
도 21은 본 개시내용의 실시예에 따라 이용되는 바와 같은, STA4@P6의 통신 시나리오에 대한 이웃 리스트 및 라우팅 테이블 구조체 예이다.
도 22는 본 개시내용의 실시예에 따른 RREP 전송을 개시하는 것의 흐름 다이어그램이다.
도 23은 본 개시내용의 실시예에 따른 RREP를 이웃 STA로 전파하는 것의 흐름 다이어그램이다.
도 24는 본 개시내용의 실시예에 따라 이용되는 바와 같은, STA4@P7의 통신 시나리오에 대한 이웃 리스트 및 라우팅 테이블 구조체 예이다.
도 25는 본 개시내용의 실시예에 따른 RREP 수신 절차의 흐름 다이어그램이다.
도 26은 본 개시내용의 실시예에 따른 RREP 수신을 확인하는 것의 흐름 다이어그램이다.
도 27은 본 개시내용의 실시예에 따라 이용되는 바와 같은, STA2@P8의 통신 시나리오에 대한 이웃 리스트 및 라우팅 테이블 구조체 예이다.
도 28은 본 개시내용의 실시예에 따라 이용되는 바와 같은, STA1@P9의 통신 시나리오에 대한 이웃 리스트 및 라우팅 테이블 구조체 예이다.
도 29는 본 개시내용의 제2 실시예에 따른 발신 STA로부터 목적지 STA까지의 루트를 확립하는 동안 프레임 교환들을 위한 메시지 시퀀스이다.
도 30은 본 개시내용의 실시예에 따라 이용되는 바와 같은, STA5@P21의 통신 시나리오에 대한 이웃 리스트 및 라우팅 테이블 구조체 예이다.
도 31은 본 개시내용의 실시예에 따라 이용되는 바와 같은, STA6@P22의 통신 시나리오에 대한 이웃 리스트 및 라우팅 테이블 구조체 예이다.
도 32는 본 개시내용의 실시예에 따라 이용되는 바와 같은, STA7@P23의 통신 시나리오에 대한 이웃 리스트 및 라우팅 테이블 구조체 예이다.
도 33은 본 개시내용의 실시예에 따라 이용되는 바와 같은, STA6@P24의 통신 시나리오에 대한 이웃 리스트 및 라우팅 테이블 구조체 예이다.
도 34는 본 개시내용의 실시예에 따라 이용되는 바와 같은, STA5@P25의 통신 시나리오에 대한 이웃 리스트 및 라우팅 테이블 구조체 예이다.
도 35는 본 개시내용의 제3 실시예에 따른 발신 STA로부터 목적지 STA까지의 루트를 확립하는 동안 프레임 교환들을 위한 메시지 시퀀스이다.
도 36은 본 개시내용의 실시예에 따라 이용되는 바와 같은, STA1@P41의 통신 시나리오에 대한 이웃 리스트 및 라우팅 테이블 구조체 예이다.
도 37은 본 개시내용의 실시예에 따라 이용되는 바와 같은, STA2@P43의 통신 시나리오에 대한 이웃 리스트 및 라우팅 테이블 구조체 예이다.
도 38은 본 개시내용의 실시예에 따라 이용되는 바와 같은, STA4@P44의 통신 시나리오에 대한 이웃 리스트 및 라우팅 테이블 구조체 예이다.
도 39는 본 개시내용의 실시예에 따라 이용되는 바와 같은, STA3@P45의 통신 시나리오에 대한 이웃 리스트 및 라우팅 테이블 구조체 예이다.
도 40은 본 개시내용의 실시예에 따라 이용되는 바와 같은, STA4@P46의 통신 시나리오에 대한 이웃 리스트 및 라우팅 테이블 구조체 예이다.
도 41은 본 개시내용의 실시예에 따라 이용되는 바와 같은, STA4@P47의 통신 시나리오에 대한 이웃 리스트 및 라우팅 테이블 구조체 예이다.
도 42는 본 개시내용의 실시예에 따라 이용되는 바와 같은, STA3@P48의 통신 시나리오에 대한 이웃 리스트 및 라우팅 테이블 구조체 예이다.
도 43은 본 개시내용의 실시예에 따라 이용되는 바와 같은, STA1@P49의 통신 시나리오에 대한 이웃 리스트 및 라우팅 테이블 구조체 예이다.

1. IEEE802.11ad에서의 빔포밍(BF) 트레이닝

기존의 802.11ad 프로토콜은 60 GHz PHY WLAN에 대한 표준이며, 각각의 STA가 다수의 안테나 섹터들을 가지며 최고 링크 품질을 제공하는 안테나 섹터를 이용한다고 가정할 때, 2개의 STA(STA1 및 STA2) 간에 신호들을 교환하는 것에 의해 사용을 위한 안테나 섹터들을 어떻게 선택하는지를 정의한다. 이 프로토콜은 초기 섹터 탐지(initial sector learning)를 위한 섹터 스위프 핸드셰이킹(sector sweep handshaking), 및 빔포밍의 유지(maintenance)를 위한 빔 미세조정 핸드셰이킹(beam refinement handshaking)을 정의한다. 이러한 핸드셰이킹을 완료하는 것에 의해, STA들은 링크의 최상의 링크 품질을 확보하기 위해 어느 안테나 섹터가 사용되어야 하는지를 탐지할 수 있다.

그렇지만, 802.11ad는 이웃하는 STA들에 대한 간섭을 제한하거나 완화시키는 것, 또는 mm-파 메시 네트워크 동작들을 고려하지 않는다.

1.1 라우팅 프로토콜 예(AODV)

라우팅 프로토콜은 다수의 홉들(중간 STA들)을 통한 발신 STA와 목적지 STA 사이의 통신 경로를 확립하기 위한 규칙들의 세트이다. AODV는 무선 매체들을 통한 멀티-홉 라우팅의 일반적 본질(general essence)을 나타내는 라우팅 프로토콜이다. AODV의 경우, STA들은 하기의 단계들에 따라 루트를 생성한다: (1) STA1(발신 STA)은 RREQ 프레임들(RREQ1)을 브로드캐스트한다; (2) STA2는 RREQ1을 수신하고, 자신과 RREQ1의 송신기(STA1) 사이의 링크의 품질을 측정하며, 링크 품질 정보를 임베딩하는 RREQ(RREQ2)를 재브로드캐스트한다(rebroadcasts); (3) STA3은 RREQ1을 수신하고, 자신과 RREQ1의 송신기(STA1) 사이의 링크의 품질을 측정하며, 링크 품질 정보를 포함하는 RREQ(RREQ3)를 재브로드캐스트한다; (4) STA4(목적지 STA)는 STA2로부터 RREQ2를 수신하고, 자신과 RREQ2의 송신기(STA2) 사이의 링크의 품질을 측정하며, RREQ2에 임베딩된 링크 품질로 값을 누적한다. 이제 STA4는 STA2를 통해 STA1에 대한 엔드-엔드 품질(end-end quality)이 어떠한지를 알고 있다. (5) STA4는 또한 STA3으로부터 RREQ3을 수신하고, 자신과 RREQ3의 송신기(STA3) 사이의 링크의 품질을 측정하며, RREQ3에 임베딩된 링크 품질로 값을 누적한다. 이제 STA4는 STA3을 통해 STA1에 대한 엔드-엔드 품질이 어떠한지를 알고 있다. (6) STA4는 STA2를 통한 STA1에 대한 링크 품질이 STA3을 통한 것보다 양호하다는 것을 발견한다. STA4는 중간 및 발신 STA들에 대한 최상의 루트를 확인하기 위해 RREP 프레임(RREP1)을 STA2로 다시 송신한다. STA2를 STA1을 향한 다음 홉 STA로서 설정한다; (7) STA2는 STA4로부터 RREP1을 수신한다. STA2는 자신이 STA4와 STA1 사이의 중간 STA임을 인식한다. STA4가 STA4를 향한 다음 홉 STA로서 설정된다; (8) STA2는 RREP(RREP2)를 STA1(발신 STA)을 향해 추가로 재전송한다. STA1이 STA1을 향한 다음 홉 STA로서 설정된다; (9) STA1은 STA2로부터 RREP2를 수신한다. STA1은 STA4를 향한 멀티-홉 경로가 확인되었고 STA4에 대한 다음 홉 STA가 STA2임을 인식한다; 그리고 (10) 그 결과, STA2를 통한 STA1과 STA4 사이의 양방향 루트가 확립된다.

2. 고려할 STA 토폴로지.

도 1은 복수의 STA들(STA1 내지 STA7)이 동일한 공간 근방(spatial vicinity)에 있는 예시적인 무선 네트워크(10)를 묘사하고 있다. 이 예시적인 시나리오에서, STA1은 STA4와 통신(12)하려고 시도하고 있으며, 이어서 STA5는 STA7과 통신(14)하려고 시도한다. 이 시나리오에서, STA1로부터 STA4로의 그리고 STA5로부터 STA7로의 직접 링크들(12, 14) 둘 다는 너무 약해서 적절한 통신을 제공하지 못한다. 따라서, 이 시나리오에서 중간 STA로서 기능하는(performing) 다른 STA들이 이러한 엔드-엔드 경로들을 확립하는 데 도움을 줄 수 있다면 바람직하다.

도 2는 도 1에 도시된 바와 같은 STA1 내지 STA7에 대한 예시적인 안테나 방향들(30)을 예시하고 있다. 이 예에서, 각각의 STA는 다수의 안테나 섹터들(예컨대, 이 예에서는 4개)를 사용하는 것으로 간주된다. STA의 하드웨어 구성 및 STA가 스테이션들의 그룹의 맥락에서 어떻게 적합할지(fits)에 따라 각각의 파이 형상의 안테나 섹터의 각도 스팬(angular span)이 달라질 수 있다는 점에 주목할 것이다. 예를 들어, STA1에서의 섹터 0 내지 섹터 3이 다른 STA들을 향하여 약 180º만을 스팬(span)하는 반면, STA4에서 섹터 0 내지 섹터 3이 적어도 270º를 스팬하는 것을 알 수 있다. 비록 보다 많은 섹터들이 섹터 번호를 지정하기 위해 부가 비트들을 요구하지만, 섹터들의 수가 임의의 원하는 수로 설정될 수 있음이 인식되어야 한다. 4개의 섹터(0 내지 3)의 값은 단지 2 비트의 섹터 방향 정보를 요구하는 절충안으로 간주되는 반면, 8개의 섹터(0 내지 7)는 특정한 고 트래픽 응용분야들에 보다 적절할 수 있으며 3 비트의 섹터 방향 정보를 요구할 것이다.

2.1. STA 하드웨어 구성.

도 3은 스테이션(STA) 하드웨어 구성의 예시적인 실시예(50)를 예시하고 있다. 이 예에서, 컴퓨터 프로세서(CPU)(52) 및 메모리(RAM)(54)는 버스(56)에 커플링되고, 버스(56)는, 센서들, 액추에이터들 등에 대한 것과 같은, STA 외부 I/O를 제공하는 I/O 경로(64)에 커플링된다. 메모리(54)로부터의 명령어들은 통신 프로토콜들을 구현하는 프로그램을 실행하기 위해 프로세서(52) 상에서 실행된다. 이 호스트 머신은 이웃하는 STA들과 프레임들을 송수신(transmit and receive)하기 위해 복수의 안테나들(62a 내지 62n, 67a 내지 67n, 및 69a 내지 69n)에 대한 라디오 주파수(RF) 회로부(60, 66, 및 68)에 커플링된 모뎀(58)으로 구성된 것으로 도시되어 있다. 비록 이 예에서 3개의 RF 회로부가 모뎀(58)에 커플링된 것으로 도시되어 있지만, 본 개시내용을 벗어나지 않으면서 임의의 수의 RF 회로들이 모뎀에 커플링될 수 있음이 인식되어야 한다. 일반적으로, 보다 많은 수의 RF 회로들은 안테나 빔 방향의 보다 넓은 커버리지를 결과할 것이다. 일반적으로, 이용되는 RF 회로들의 수와 안테나들의 수는 특정 디바이스 및 응용분야의 하드웨어 제약조건들에 의해 결정된다. STA가 이웃 STA들과 통신할 필요가 없다고 결정할 때 RF 회로부 및 안테나들 중 일부가 디스에이블될 수 있다. 적어도 하나의 실시예에서, RF 회로부는 주파수 변환기, 어레이 안테나 제어기 등을 포함하고, 송수신(transmission and reception)을 위해 빔포밍을 수행하도록 제어되는 다수의 안테나들에 접속된다. 이러한 방식으로, STA는 다수의 빔 패턴 세트들을 사용하여 신호들을 전송할 수 있으며, 각각의 빔 패턴 방향은 안테나 섹터로서 간주된다. 안테나 섹터는 어레이 안테나 제어기에 의해 명령된 빔포밍 및 RF 회로부의 선택에 의해 결정된다. 비록 STA 하드웨어 컴포넌트들, 즉 도 3에서의 52 내지 69n이 위에서 설명된 것과 상이한 기능 파티션들(functional partitions)을 가질 수 있는 것이 가능하지만, 그러한 구성들은 개시된 시스템의 상이한 예들에 불과하다.

도 4는 다수의 안테나 섹터 패턴들(예컨대, 예로서 36개가 도시됨)을 생성하기 위해 STA에 의해 수행될 수 있는 안테나 방향들(70)의 예시적인 실시예를 예시하고 있다. 이 예에서, STA는 3개의 RF 회로 및 접속된 안테나들을 구현하고, 각각의 RF 회로 및 접속된 안테나는 다수의(예컨대, 예로서 12개가 도시됨)의 빔포밍 패턴들을 생성하는데, 이는 STA가 36개의 안테나 섹터를 갖는다고 말해진다. 그러나 본 명세서의 설명을 쉽게 하기 위해 모든 STA들이 4개의 안테나 섹터를 갖는 것으로 가정한다. 임의의 빔 패턴이 안테나 섹터에 매핑될 수 있다. 전형적으로, 빔 패턴은 예리한 빔(sharp beam)을 생성하도록 형성되지만, 빔 패턴이 다수의 각도들로부터 신호들을 전송하거나 수신하도록 생성되는 것이 가능하다.

2.2. 안테나 섹터 정보 탐지 프로세스

도 5는 각각의 STA가 각각의 안테나 섹터의 링크 품질을 탐지하기 위해 섹터 스위프 신호 교환을 수행하는 실시예(90)를 예시하고 있다. 각각의 STA는 이웃하는 STA들이 각각의 안테나 섹터의 수신 신호 품질(received signal quality)을 탐지하게 하도록 일련의 섹터 스위프(TXSS) 신호들을 전송(92, 94, 96)한다. 이웃 STA들은 TXSS 신호들을 리스닝하고, 그들의 이웃 STA들이 각각의 안테나 섹터의 신호 품질을 알게 하기 위해 SSW 피드백으로 다시 보고한다. 그 결과, STA1, STA2, 및 STA3은 각각의 이웃 STA들로부터의 안테나 섹터당 신호 품질을 탐지한다.

도 1에 묘사된 토폴로지와 함께 도 5에 도시된 탐지 프로세스를 고려하면, STA1 내지 STA7은 그의 이웃에서의 안테나 섹터 신호 품질 정보를 탐지할 수 있다. 안테나 섹터 정보 탐지 프로세스의 결과로서, 각각의 STA는 이웃 리스트(Neighbor List)라고 불리는 데이터베이스를 구축하고 STA당 TX 안테나 섹터당 수신 신호 품질 정보를 자신의 메모리에 저장한다. 이웃 리스트의 각각의 인스턴스는 이웃 STA 관한 다양한 정보를 저장한다.

도 6은 STA1에 구성된(constructed) 이웃 리스트의 예시적인 실시예(110)를 예시하고 있으며, 여기서 STA1은 STA2 및 STA3을 그의 이웃 STA들로서 인식하고, 이웃 리스트 엔트리의 2개의 인스턴스를 생성한다. STA1은 수신 링크 품질 정보를 a.RxQuality[N]에 저장하며, 여기서 N은 이웃 STA의 Tx 안테나 섹터와 연관된다.

2.3. 트래픽 활동 감독

각각의 STA는 또한 자신의 트래픽 활동을 모니터링하고, STA가 그 때에 어떤 유형의 트래픽을 서빙하고 있는지를 트래킹한다. STA는 루트 발견 프로세스를 통해 새로운 흐름이 활성화될 때 트래픽 흐름 정보를 수집하고, 트래픽 흐름당 다음과 같은 정보: (a) 트래픽 발신 STA, (b) 트래픽 목적지 STA, (c) 트래픽 ID, (d) 트래픽 대역폭, (e) 이 트래픽을 전송하는 데 요구된 채널 시간 비(듀티 사이클)를 기록한다. 이 정보도 이웃 리스트에 저장된다. 트래픽 흐름 인스턴스는 STA가 전송하고 있는 대상의 이웃 리스트 인스턴스에 부가된다.

2.4. 이웃 STA들 간의 정보 공유

각각의 STA는 안테나 섹터 정보 및 트래픽 활동 정보를 포함하는 관리 정보를 자신의 이웃하는 STA들로 전송한다. 이러한 방식으로, 이웃 STA들은 이웃 STA들의 안테나 섹터 정보 및 트래픽 활동을 탐지할 수 있다. 이웃 STA들은 본 명세서에서 "이웃 정보 교환"이라고 지칭되는 프로세스에서 그 정보를 포함하는 관리 프레임들을 교환한다.

도 7은 섹터 스위프(SSW) 제어 프레임(132)에서 이웃 정보 교환을 위한 프레임 내용(frame content)의 예시적인 실시예(130)를 예시하고 있다. 프레임 제어(Frame Control) 필드는 프레임의 유형을 나타낸다. 지속기간 필드(Duration)는 CSMA/CA 채널 액세스에 사용되는 NAV 정보를 포함한다. RA 필드(RA)는 프레임의 수신자의 어드레스를 포함한다. TA 필드(TA)는 프레임을 전송하는 STA의 어드레스를 포함한다.

SSW 피드백 엘리먼트(134)(SSW Feedback element)는 본 개시내용에 따라 이용되는 바와 같은 신호 품질 정보를 포함한다. 이 엘리먼트 내에서, 길이 필드(Length) 및 유형 필드(Type)에 뒤이어서, 하나 이상의 SSW 피드백 필드(들)(SSW Feedback field 1, SSW Feedback field 2, ...SSW Feedback field N)가 있다. 각각의 필드는 특정의 이웃 STA들로부터의 링크 품질 정보를 포함한다. 예를 들어, 도 5에서의 STA1은 2개의 SSW 피드백 필드를 포함하며, 하나는 STA2의 안테나 섹터들에 관한 RX 링크 품질 정보를 포함하고, 다른 하나는 STA3의 안테나 섹터들에 관한 RX 링크 품질 정보를 포함한다.

SSW 피드백 필드 내에는, 3개의 서브필드(138), 즉 스테이션 식별(station identification)(STA ID), 섹터 번호(Sector Num), 및 섹터 품질 정보(Sector Quality Bitmap)가 있다. STA ID 서브필드는 이 정보와 연관된 STA를 식별해주고, Sector Num 서브필드는 Sector Quality Bitmap의 길이를 식별해주며, Sector Quality Bitmap은 각각의 섹터들에 대한 양자화된 링크 품질 값을 보여준다.

도 7에서, 각각의 섹터에 대해 2 비트가 할당되고, 비트맵이 첫 번째 섹터부터 시작하여 M 번째 섹터까지 계속된다는 점에 주목해야 한다. 각각의 Sector Bitmap은 양자화된 링크 품질 값을 나타내도록 인코딩된다. 이 예에서: 00: 고품질(HQ), 01: 중간 품질(MQ), 10: 저품질(LQ), 11: 신호 미검출(ND). 비록 본 명세서에서 이 양자화된 링크 품질 값을 계속 사용하지만, 양자화의 세분성(granularity)(분해능(resolution))은 Sector Bitmap에 보다 적은 또는 보다 많은 비트들을 할당하고 그에 따라 선택된 분해능에 따라 동작함으로써 원하는 대로 구성될 수 있다.

SSW Feedback element에 뒤이어서, STA는 트래픽 활동에 관한 정보(Traffic Activity element)를 프레임에 포함시킨다. 이 엘리먼트는 STA가 진행 중인 트래픽들을 수용(전송 및/또는 수신)하고 있을 때를 나타낸다. Traffic Activity element(136)는 길이 필드(Length) 및 유형 필드(Type)를 포함하고, 진행 중인 트래픽에 관한 정보를 포함하는 하나 이상의 필드(Ongoing Traffic field 1, ...Ongoing Traffic field M)가 있다. 각각의 필드(140)는, 다음과 같은 서브필드들을 갖는, 트래픽 스트림당 진행 중인 트래픽 정보를 포함한다. 트래픽 발신 STA를 포함하는 발신 스테이션 식별자 필드(Orig STA ID), 트래픽 목적지 STA를 포함하는 목적지 스테이션 식별자 필드(Dest STA ID), 트래픽 ID를 포함하는 트래픽 식별기호 필드(Traffic ID), 및 특정한 시간 프레임에서 언제 트래픽이 전송되는지에 관한 정보를 포함하는 채널 시간 정보 필드(Channel Time). 아래에 설명되는 바와 같이 이웃 정보를 전송하는 2가지 방식이 있다.

2.4.1. 정보 공유(사례 1).

일 구현에서, 정보 공유는 도 5에 보이는 SSW 피드백을 사용하여 수행되는데, 프레임 또는 정보 엘리먼트는 SSW 피드백 프레임으로서 전송되는 것으로 도 7에 도시되어 있다.

2.4.2. 정보 공유(사례 2).

다른 구현에서, 정보 공유는, 도 7에 도시된 바와 같이, 이웃 정보 교환을 위해 특정적으로(specifically) 이용되는 지정된 프레임을 통해 수행되며, 이 프레임은, 시간 또는 이벤트들에 기초하는 것과 같이, STA에 의해 주기적으로 전송된다.

도 8은 이웃 정보 교환의 다른 예시적인 실시예(150)를 예시하고 있다. Neighbor Info Exchange 프레임은 STA1(152)에 대해 보이는 바와 같이 이웃의 안테나 섹터 신호 품질을 수집한 후와 같이, 필요할 때마다 일반 관리 프레임(general management frame)으로서 전송되는데, 이웃 정보 교환은 정보를 수집한(156a) 후에 발생한다. 정보를 수집하고(156b) STA1로부터 이웃 정보 교환을 수신한 후에 이웃 정보 교환을 수행하는 STA2(154)에 대한 유사한 상황이 보인다. Neighbor Info Exchange 프레임이 유니캐스트 프레임에서 전송될 때, 이 프레임의 RA 필드가 특정의 STA의 어드레스로 설정되고, (RA 필드에 의해 식별되는 이웃 STA에 관한 정보를 포함하는) 단지 하나의 SSW 피드백 필드가 SSW Feedback element에 포함되는 것이 가능하다.

적어도 하나의 실시예에서, STA들이 모든 안테나 섹터 정보를 교환하는 것이 가장 효율적인 것으로 간주된다. 그렇지만, STA들이 STA를 구성하는 안테나 섹터들의 실제 수보다 적은 수의 섹터들에 관한 정보를 결정하고 교환하는 것이 또한 가능하다. 따라서, STA들은 섹터 정보의 서브세트만을 교환할 수 있다. 또는 다른 실시예들에서, STA들은 일부 섹터들을 그룹화하고 그룹화된 섹터 정보를 교환할 수 있다. 예를 들어, STA가 도 3에 도시된 것과 같은 하드웨어 구성을 갖는다면, STA는 총 36개의 섹터를 결과하는 것과 같은 3개의 RF 회로를 갖는다. STA는, 이웃 정보 교환을 위해 요구된 비트들의 수를 최소화하고 구현을 쉽게 하기 위해, 섹터들의 신호 품질을 평균화함으로써 12개의 실제 안테나 섹터를 단일 섹터 정보로 그룹화하고 그룹화된 섹터 정보를 교환할 수 있다. 이 예시적인 경우에서, 비록 STA가 총 36개의 섹터를 갖지만, STA는 3개의 섹터 정보를 교환한다. 이 예에서, STA는 RF 회로부당 섹터 정보를 그룹화한다.

2.4.3. 이웃 정보를 이웃 리스트에 저장하기.

이웃 정보 교환 프로세스의 결과로서, STA는 이웃 정보 교환 프로세스로부터 획득된 정보를 자신의 이웃 리스트에 어펜딩한다(appends).

STA는 SSW Feedback element 및 Traffic Activity element를 포함하는 Neighbor Info Exchange 프레임 또는 SSW Feedback 프레임 중 어느 하나를 수신할 때, STA는 이웃 리스트의 인스턴스를 업데이트한다.

도 9는 STA2(172) 및 다른 스테이션들(174)에 대해 도시된 이웃 리스트 데이터 구조체의 예시적인 실시예(170)를 예시하고 있다. 트래픽 활동 정보는 대응하는 이웃 리스트 인스턴스의 b.TrafficAct[]에 저장된다.

이 도면은, STA1이 4개의 안테나 섹터를 갖는 것으로 가정하여, STA2 및 STA3으로부터 (Neighbor Info Exchange 프레임 또는 SSW Feedback 프레임 중 어느 하나를 통해) SSW Feedback element 및 Traffic Activity element를 수집한 도 7에 따라 STA1에서 작성된 이웃 리스트를 도시하고 있다. STA1은 수신된 정보 엘리먼트를 파싱하고, Traffic Activity element 내의 정보를 자신의 이웃 리스트 내의 b.TrafficAct 어레이에 복사하고, 각각의 섹터 품질 정보를 자신의 이웃 리스트 내의 c.TxQuality[M]에 복사하며, 여기서 M은 STA1의 Tx Antenna Sector와 연관된다. 이 시점에서 STA1은, 어느 안테나 섹터를 이용할지(예컨대, 섹터 1, 섹터 2, 섹터 3, 또는 섹터 4)를 선택할 때, STA2 및 STA3에서의 신호 품질의 대략적 추정치들을 획득하였다. 그에 부가하여, STA1은 각각의 이웃 STA에서의 트래픽 활동에 관한 정보를 획득하였다. STA1은 또한 자신이 내부적으로 실행하는 타이머로부터의 타임스탬프를 참조하여, 기입된 정보의 만료 시간을 계산하고, 만료 시간을 f.ExpTime으로 설정한다.

도 10은 이웃 리스트 TxQuality 데이터 구조체의 예시적인 실시예(190)를 예시하고 있다. 이 도면에서, 이웃 리스트(192)는 각각의 이웃 STA에 대한 구조체들을 갖고, STA2(194a) 및 STA3(194b)을 예로서 묘사하고 있으며, 각각의 STA2 섹터(196a, 198a, 200a, 202a)에 대한 TxQuality가 보여지고 각각의 STA3 섹터(196b, 198b, 200b, 202b)에 대한 TxQuality가 보여지고 있다. 각각의 이웃 STA들의 특정의 TxQuality[i]가 용이하게 스캔될 수 있도록, 데이터 c.TxQuality[]는 전형적으로 2차원 리스트 구조체로서 구현된다.

2.5. 라우팅 테이블 및 데이터 포워딩.

도 11은, 예로서 3개의 목적지(서브테이블(subtables))를 목적지 AAA(212), BBB(214), 및 CCC(216)로서 보여주는, 라우팅 테이블 데이터 구조체의 예시적인 실시예(210)를 예시하고 있다. STA(발신 STA)가 데이터 프레임을 다른 STA(목적지 STA)로 전송하려고 할 때, 발신 STA는 목적지 STA까지의 루트를 셋업해야 한다. 라우팅 테이블(Routing Table)은 루트 발견 프로세스로부터의 결과물(outcome)로서 구성되며, 이에 대해서는 추후 섹션에서 설명될 것이다.

목적지 STA까지의 루트는 라우팅 테이블을 생성함으로써 관리된다. 라우팅 테이블은 목적지 STA당 데이터 인스턴스들을 가지며, STA는 프레임을 목적지 STA로 전송할 때 인스턴스를 룩업한다. 라우팅 테이블의 각각의 인스턴스는 각각의 목적지에 대한 다음과 같은 정보(서브필드들)를 포함한다.

Dest : 목적지 STA 어드레스;

a. NextHop : Dest를 향한 다음 홉 STA 어드레스;

b. TxAntSec: 프레임들을 다음 홉으로 전송하는 데 사용되는 안테나 섹터;

c. Metric: 목적지 STA까지의 거리를 결정하는 값;

d. SeqNum: 라우팅 관리 프레임의 루프를 제어하는 값;

e. TrafficID: 라우팅 테이블에 의해 핸들링되는 대응하는 트래픽 ID;

f. ExpTime: 이 라우팅 테이블 인스턴스의 만료 시간;

g. ValidFlag: 이 인스턴스가 유효한지 여부를 식별해준다;

STA가 목적지 STA로 전송할 데이터 프레임을 가질 때, STA는 라우팅 테이블을 룩업하고, 프레임의 RA 필드를 a. NextHop에 저장된 어드레스로 설정하며, b. TxAntSec에 저장된 안테나 섹터를 사용하여 프레임을 전송한다.

라우팅 테이블이 판독 섹션 및 기입 섹션을 갖는다는 점이 인식되어야 한다. 목적지 STA까지의 루트를 탐색할 때, 라우팅 테이블의 판독 섹션에서 룩업이 수행되는 반면, 기입 섹션은 루트 결정 프로세스 동안 이용된다.

2.6. 라우팅 관리 프레임 포맷.

STA가 목적지 STA까지의 루트가 이용가능하지 않다는 것을 발견했을 때, STA는 라우팅 프로토콜을 실행하기 시작한다. 라우팅 프로토콜은 발신 STA로부터 목적지 STA까지의 루트를 셋업하기 위해 두 가지 유형의 프레임들을 교환한다. RREQ 프레임은 발신 STA로부터 목적지 STA를 향해 전송된다. 목적지 STA가 RREQ 프레임을 수신할 때, 목적지 STA는 목적지가 발신 STA인 RREP 프레임으로 응답할 것이다.

도 12a 및 도 12b는, 제각기, RREQ 및 RREP 프레임 내의 내용의 예시적인 실시예(230, 240)를 예시하고 있다. 제한이 아닌 예로서, 이 도면들에 예시된 RREQ 및 RREP의 기본 형태(232, 242)는 동일하며 Frame Control, Duration, RA, TA, 및 FCS가 RREQ/RREP element를 둘러싸고 있다. 프레임 제어 필드(Frame Control)는 프레임의 유형을 나타낸다. 지속기간 필드(Duration)는 CSMA/CA 채널 액세스에 사용되는 네트워크 할당 벡터(network allocation vector, NAV) 정보를 포함한다. 수신자 어드레스 필드(RA)는 프레임의 수신자의 어드레스를 포함한다. 전송 어드레스 필드(TA)는 프레임을 전송하는 STA의 어드레스를 포함한다.

도 12a의 RREQ element(234)는 다음과 같은 필드들을 포함한다.

Length : 이 프레임의 길이;

Type : 이 프레임의 유형(RREQ);

Orig STA : 발신 STA의 어드레스;

Dest STA : 목적지 STA의 어드레스;

SeqNum : 이 루트 셋업을 식별해주는 시퀀스 번호. SeqNum은 발신 STA가 루트를 셋업 또는 유지하려고 시도할 때마다 증분된다;

Metric : 누적된 메트릭 값을 발신 STA를 향해 운반한다;

Lifetime : 이 루트의 만료 시간까지의 수명;

Traffic ID : 연관된 트래픽 스트림의 트래픽 ID;

QoS Spec : 이 트래픽 스트림의 트래픽 사양(traffic specification), 즉, 대역폭 등.

Access Time : TA STA(TA 필드에 의해 식별된 STA)가 RA STA(RA 필드에 의해 식별된 STA)를 향해 데이터 프레임들을 전송하기 위해 사용하는 채널 시간;

TxAntSector : TA STA가 RA STA를 향해 데이터 프레임들을 전송하기 위해 사용하는 Tx 안테나 섹터;

AffectRatio : 이 전송이 다른 이웃하는 STA들에 영향을 미치는 채널 시간 듀티 사이클;

RxQualList : (RA STA에 대응하는) TA STA의 이웃 리스트 인스턴스 내의 a.RxQuality[]에 포함된 값들.

도 12b의 RREP 프레임(242)의 RREP element(244)는, AffectRatio 필드 및 RxQualList 필드를 누락하고 있는 것을 제외하고는, 위에서 설명된 RREQ element (234)에서와 동일한 필드들을 포함한다.

2.7. 라우팅 테이블 구성하기(시나리오 1).

예를 위해, 이 라우팅 시나리오에서, STA1이 STA4로의 어떠한 유효한 직접 루트도 갖지 않을 때, STA1이 STA4와 통신하려고 시도하는 상황을 고려하여, STA 토폴로지는 도 2에서와 같은 것으로 가정된다. 하기는 이 하위절의 이 루트 셋업 프로세스를 논의한다.

2.7.1. 메시지 시퀀스 차트(시나리오 1).

이 시나리오에서, STA1은 데이터 프레임들을 STA4를 향해 전송하려고 시도하고 있다. 그와 같이, STA1은 트래픽 발신 STA이고, STA4는 트래픽 목적지 STA이다. 다른 STA들은 잠재적인 중간 STA들이지만, STA1로부터 STA4까지의 루트가 결정될 때까지는 그것이 불확실하다. 이러한 잠재적인 중간 STA들은 RREQ 프레임 수신 및 RREP 프레임 수신마다 일련의 이벤트들을 활성화시킨다. 발신 STA(STA1)가 목적지 STA까지의 루트를 확립하려고 시도할 때, STA1은 RREQ 프레임들을 자신의 이웃 STA들로 전송하기 시작하고, 잠재적인 중간 STA들인 이웃 STA들은 RREQ 프레임들을 자신들의 이웃 STA들로 전파하며, 목적지 STA(STA4)는 최종적으로 RREQ 프레임들을 수신한다. 자신의 이웃 STA들로부터 RREQ 프레임들을 수신하는 것에 의해, 목적지 STA(STA4)는 STA2를 통한 루트가 이 전송에 가장 적합하다고 결정하고, 다시 발신 STA1을 향해 RREP 프레임으로 다시 응답한다. 발신 STA1이 중간 STA로서 결정된 STA2를 통해 RREP를 수신할 때, STA1로부터 STA4로의(그리고 STA4로부터 STA1로의) 엔드-엔드 루트가 확립된다. 이것은 다음과 같이 보다 상세히 설명된다.

도 13은 이 루트를 셋업할 때 이루어지는 전체적인 프레임 교환 시퀀스를 묘사하는 메시지 시퀀스 차트의 예시적인 실시예(250)를 예시하고 있다. 시간 기간들(p1 내지 p9)이 도시되어 있으며, 이들은 본 개시내용 전반에 걸쳐 참조될 수 있다. 스테이션들(STA1 내지 STA7) 각각은 차트의 상단을 따라 보이며, 시간은 차트의 상단에서 시작하여 차트 아래로 순차적으로 이동한다. 이 시퀀스에서, 트래픽 발신 STA인 STA1이 RREQ를 그의 이웃 STA들(STA2 및 STA3)로 송신하는 것을 볼 수 있다. RREQ를 수신한 각각의 STA는, 자신이 이 루트 셋업 시도의 목적지 STA가 아닌 한, RREQ를 자신의 이웃 STA들로 전파한다. 이 예에서, 그에 응답하여, STA2는 RREQ들을 STA3, STA4 및 STA5인 자신의 이웃 STA들로 송신한다. RREQ를 수신한 STA3은 RREQ를 STA2 및 STA4로 송신한다. 이와 유사하게, RREQ를 수신한 STA5는 RREQ를 STA4 및 STA6으로 송신한다. RREQ를 수신한 STA6은 RREQ를 STA4 및 STA7로 송신한다. RREQ를 수신한 STA7은 RREQ를 STA4로 송신한다. 로컬 STA들에 관한 필요한 정보를 수집한 후, STA4인 목적지 STA는 STA2를 발신 STA1를 향한 중간 STA로서 픽업하고 라우팅 응답(RREP)을 STA2로 송신한다. RREP의 수신 시에, STA2는 자신이 중간 STA로서 선택되었음을 인식하고, RREP를 다시 발신 STA1로 송신한다. 이제, RREP가 발신 STA1에 수신된다. STA1은 STA2를 목적지 STA4를 향한 중간 STA로서 인식한다. 이러한 방식으로, STA들은 STA1(발신 STA)로부터 STA2(중간 STA)를 통해 STA4(목적지 STA)까지의 라우팅 경로를 확립한다.

2.7.2. RREQ 송신기 STA 거동.

2.7.2.1. RREQ 송신기 STA 로직 흐름 1

도 14는 발신 STA RREQ 전송 로직의 예시적인 실시예(270)를 예시하고 있다. STA가 상위 계층으로부터의 전송 트래픽(transmitting traffic)을 수신하여 RREQ TX 절차(272)에 들어갈 때, STA는 목적지 STA까지의 이용가능한 루트가 있는지를 결정(274)하기 위해 자신의 라우팅 테이블을 룩업한다. 목적지까지의 루트가 존재하면, 루트 만료 시간에 거의(close to) 도달했는지를 결정하기 위해 블록(276)이 실행된다. 루트가 그의 만료 시간에 가깝지 않으면, 루트는 사용될 수 있고 프로세스가 종료된다(282). 루트가 만료 시간에 가깝거나, 또는 블록(274)에 따라 목적지까지의 루트가 발견되지 않으면, 실행은 초기, 디폴트, 또는 주어진 값들을 전송 RREQ에 설정하는 블록(278)으로 이동하고, 이어서 프로세스를 종료(282)하기 전에, RREQ를 이웃 STA들로 전파하기 위해 프로세스(280)를 실행한다. 따라서, 목적지 STA까지의 루트가 발견될 때, STA가 루트의 만료 시간이 가까운지를 또한 체크한다는 것을 알 수 있다. 그러하면, STA는 기존의 루트를 리프레시(refresh)하여 유지하기 위해 RREQ 전송을 또한 킥킹한다(kicks). 그렇지 않으면, STA는 기존의 라우팅 테이블을 그냥 사용한다.

2.7.2.2. RREQ 송신기 STA 로직 흐름 2

도 15a 및 도 15b는 도 14의 블록(280)에 보이는 바와 같이 RREQ들을 이웃 STA들로 전파하는 로직 흐름의 예시적인 실시예(290)를 예시하고 있다. RREQ 전송은 가능한 루트들을 결정하기 위해 테스트하는 프로세스이며, 이 프로세스에서, STA가 다수의 이웃 STA들을 가지면, STA는 RREQ를 다수의 이웃 STA들 또는 선택된 이웃 STA(들)로 전송한다.

이 프로세스가 시작되고(292), 이어서 STA는 자신의 이웃 리스트 내의 모든 이웃 STA들을 스캔하여, 이웃 STA들을 하나씩 픽업하며(294), 타깃 이웃은 픽킹된(picked) 이웃 STA 인스턴스이다. 따라서, STA는 RREQ를 이 이웃들(294, 296) 각각으로 송신하려고 시도한다. RREQ 전송이 RREQ의 수신에 의해 트리거되고 TargetNeighbor가 RREQ.TA 또는 RREQ.OrigSTA 중 어느 하나와 매칭하는지의 결정이 블록(298)에서 이루어진다. 매치(match)가 있으면, STA는 RREQ를 이웃 STA로 전송하지 않고 실행이 종료(310)된다. 그렇지 않으면, 매칭이 없었기 때문에 STA 프로세스는, TargetNeighbor를 향한 송신 안테나 섹터를 결정하는, 블록(300)으로 진행한다. 이 단계의 결과로서, STA는 AffectRatio 및 BestSector를 결정한다. 이어서 블록(302)에서, 전송 RREQ의 AffectRatio 필드, TxAntSector 필드, RxQual[] 필드들, 및 RA 필드들을 포함하여, 다수의 RREQ 필드 값들이 설정된다.

이어서, 블록(304)에서, STA가 BestSector를 사용하여 데이터 프레임들을 TargetNeighbor로 전송하는 경우 STA는 이 트래픽이 전송되어야 할 때를 결정한다. 구체적으로는 STA는 RREQ.QoSSpec 및 이웃 리스트를 참조하여 채널 시간 할당을 결정하고, 최상의 섹터를 사용하는 TargetNeighbor로의 트래픽의 전송에 채널 시간을 할당한다. 따라서, 이용가능한 시간 할당을 탐색하기 위해 RREQ 엘리먼트 내의 QoSSpec 필드(요청된 대역폭), 및 이웃 리스트 인스턴스들 내의 c.TxQuality[BestSector] 및 b.TrafficAct[]에 설정된 정보가 참조된다. 간결함을 위해, 채널 시간을 결정하는 프로세스의 세부사항들이 설명되지 않지만, 그것이 다수의 방식들로 결정될 수 있음이 본 기술분야의 통상의 기술자에 의해 인식될 것이다.

블록(306)에 도달하면, 결정된 채널 시간이 RREQ 엘리먼트 내의 AccessTime 필드에 복사되고 TargetNeighbor 내의 g.AccessTime에 저장된다. 그렇지만, 루트가 확인될 때까지 이 채널 시간 할당이 보류된다. 그와 같이, TargetNeighbor 내의 g.AccessTime은 확인 타임아웃마다 제거된다. STA는 g.AccessTime을 제거하기 위해 타이머를 실행한다. 그리고 타이머가 기동될(fires) 때, 이 데이터가 TargetNeighbor에서 제거된다.

이제, TargetNeighbor을 향한 RREQ 프레임 전송이 준비된, 블록(308)에 도달한다. STA는 자신의 어드레스를 RREQ 프레임 내의 TA 필드에 설정하고, 이어서 BestSector를 사용하여 RREQ 프레임을 TargetNeighbor로 전송한다. 이 프로세스는 이어서 종료된다(310).

2.7.2.3. RREQ 송신기 STA 로직 흐름 3

도 16a 및 도 16b는, 도 15a의 블록(300)에서 실행된 바와 같이, 타깃 이웃을 향한 송신 섹터를 결정하기 위한 로직 흐름의 예시적인 실시예(330)를 예시하고 있다. 도 16a에서 이 절차에 진입(332)한 후에, STA는 데이터를 TargetNeighbor로 전송하기 위해 어느 Tx 안테나 섹터가 사용되어야 하는지를 결정한다. 여기서의 기본 전략은 다른 이웃 STA들에 대한 간섭 효과를 최소화하면서 보다 높은 데이터 레이트를 제공하는 Tx 섹터를 찾아내려고 시도하는 것이다.

먼저, 블록(334)에서, 변수 MaxRate가 초기화된다. 이어서 블록(336)에서, STA는 이 이웃 리스트 인스턴스(TargetNeighbor) 내의 모든 TxQuality를 스캔하고, TxQuality[i]를 하나씩 픽업한다. 이어서 블록(338)에서, STA는 TxAnt를 픽킹된 Tx 안테나 섹터(c.TxQuality[i])로 설정한다. 이어서 STA는 c.TxQuality[i] 및 b.TrafficAct를 사용하여 TargetNeighbor에 대한 예상 링크 레이트를 계산(340)한다. TxQuality[i]는 근사화된 링크 레이트를 제공하고 b.TrafficAct는 이 트래픽을 수용하기 위해 이용가능한 채널 시간 듀티 사이클을 제공한다. c.TxQuality[i]와 채널 시간 듀티 사이클을 곱한 것이 계산된 링크 레이트에 사용될 수 있다. 이 값은 변수 TxRate에 저장된다.

이어서, 블록(342)에서, STA가 TxAnt를 사용하는 경우 STA는 STA가 얼마만큼의 간섭을 생성할 것인지를 체크한다. 이 실시예에서, 이것은, 이웃 리스트 내의 다른 이웃 STA 인스턴스들의 c.TxQuality[i]를 스캔하고, 루프를 실행하여 이웃 STA의 TxQuality[i]를 하나씩 픽업하는 것에 의해, 결정된다. 본 개시내용의 교시내용들을 벗어나지 않으면서, 다른 방법들이 간섭 레벨을 추정하는 데 이용될 수 있다는 것이 인식될 것이다.

블록(344)에서, 픽킹된 이웃 STA 인스턴스가 AffectedSTA에 저장된다. AffectedSTA가 TargetNeighbor와 상이하면 도 16b의 체크가 이루어진다(346). 상이하지 않으면, AffectedSTA의 c.TxQuality[i]를 참조하여 AffectedSTA에 대한 Affect Factor를 결정하기 위해 계산이 이루어지고; Affect Factor는 그것이 AffectSTA에 대한 간섭을 얼마나 생성할 것인지를 나타낸다. c.TxQuality[i]가 보다 높은 품질이면, 그것은 크게 영향을 받을 것이고 Affect Factor가 보다 클 수 있다(최대 1.0). c.TxQuality[i]가 검출되지 않으면(ND), 그것은 영향을 받지 않을 것이며 Affect Factor는 0이다. Affect Factor가 이어서 계산(348)된다. 적어도 하나의 실시예에서, AffectedSTA에 대한 Affect Factor는 AffectFactor[AffectedSTA] = Func(c.TxQuality[i]) * DutyCycle로서 계산되고, 여기서 Func()는 0.0부터 1.0까지의 선형 함수이고, DutyCycle은 TargetNeighbor 내의 b.TrafficAct로부터 계산되지만, Affect Factor는 본 개시내용의 교시내용들을 벗어나지 않으면서 다른 방식들로 결정될 수 있다. STA는 자신의 이웃 리스트 내의 모든 인스턴스에 대해 동일한 동작을 반복한다.

STA는, 총 영향이 Affect Factor에 반영되도록, 이어서 이웃 STA들 간의 Affect Factor를 누적(350)한다.

다음에, STA는 TxAnt를 이용하여 TargetNeighbor에 대한 유효 링크 레이트를 계산(352)한다. TxRate는 베이스 링크 레이트(base link rate)이며, 이 값은 Affect Factor에 의해 조정된다. 유효 레이트는 EffectRate = TxRate * (1 - AffectFactor)로서 계산되며; 여기서 EffectRate는 최종 유효 레이트이다.

STA는 최대 EffectRate를 제공하는 이웃 리스트 인스턴스로부터의 데이터를 픽업할 것이다. EffectRate가 MaxRate보다 큰지의 결정(354)이 이루어진다. EffectRate가 MaxRate보다 크면, STA가 MaxRate를 EffectRate로 설정하고, BestSector를 TxAnt로 설정하며, AffectRatio를 Affect Factor로 설정하는 블록(356)이 실행된다.

블록(336)에서 루프백을 실행한 후에, STA는 블록(358)에서 BestSector의 최종 결과를 획득한다. 이것은 TargetNeighbor의 e.CandSector에 복사(360)되고, 여기서 CandSector는 후보 송신 안테나 섹터를 나타낸다. 이어서 프로세스가 종결(362)된다.

2.7.2.4. STA1@P1에서의 이웃 리스트 및 라우팅 테이블

선행하는 섹션들은 발신 STA인 STA1이 전송 RREQ를 어떻게 결정하는지를 논의하였다. 그리고 도 13에서와 같이, STA1은, 설명된 바와 같은 로직에 따라, RREQ를 자신의 이웃 STA들(STA2 및 STA3)로 전송한다. 도 13에서의 시간 기준 P1인 RREQ 전송 시에, STA1의 이웃 리스트가 업데이트된다.

도 17은 RREQ 전송 시의 이웃 리스트 업데이트의 예시적인 실시예(370)를 예시하고 있다. 이 도면에서, STA2에 대한 데이터의 테이블(372), STA3에 대한 테이블(374), 및 비어 있는 라우팅 테이블(376)이 보인다.

도 15a에서의 단계(300)로부터의 결과로서, STA1은 이웃 리스트 인스턴스들 내의 e.CandSector를 적절한 번호(최상의 유효 링크 레이트를 제공하는 Tx 안테나 섹터)로 설정한다. 도 15b에서의 단계들(304, 306)로부터의 결과로서, 제안된 채널 할당 시간 및 연관된 정보가 이웃 리스트 인스턴스들 내의 g.AccessTime에 기입된다. 도 17에서, RREQ 전송 프로세스의 결과인 업데이트된 데이터는 밑줄(underlining)로 표시되는 반면, 이 시점에서, STA1은 아직 라우팅 테이블의 인스턴스를 갖지 않는다.

2.7.3. RREQ 수신기 STA 거동

2.7.3.1. RREQ 수신기 STA 로직 흐름

도 18a 및 도 18b는 RREQ 프레임을 수신하는 STA들에 대한 RREQ 수신 절차의 프로그램 흐름의 예시적인 실시예(390)를 예시하고 있다. STA가 이웃 STA로부터 RREQ를 수신할 때, STA는 도 18a에서 이 프로세스(392)를 시작한다. 도 13에 도시된 시나리오에 대해, 이 프로세스는 도 18a에서 STA1에 의해 전송된 RREQ들이, 본 명세서에서 STA2 및 STA3으로서 예시된, 다른 스테이션들에 수신되는 것으로 시작(392)된다. 제한이 아닌 예로서, 이 하위절(subclause) 예는 STA2에 초점을 맞추고 RREQ의 수신 시의 STA2의 거동을 설명한다.

STA가 자신의 이웃 STA들 중 하나로부터 RREQ 프레임을 수신할 때, STA는 이웃 리스트를 룩업(탐색)(394)하고, 수신된 RREQ의 TA 필드 내의 어드레스와 매칭하는 인스턴스를 픽업하며(찾으며), 이 이웃 리스트 인스턴스를 TargetNeighbor에 넣는다(puts).

이어서, STA는 이웃 STA(STA1)와 자신(STA2) 사이의 링크 메트릭 값을 계산(396)한다. 링크 메트릭은 수신 신호 품질의 함수이다. 신호 품질이 보다 양호하면, 링크 메트릭 값은 보다 작을 것이다. 보다 작은 메트릭 값은 보다 양호한 링크 품질을 의미한다. STA는 TargetNeighbor 내의 RxQuality[RREQ.TxAntSector]를 참조하여 링크 품질을 픽업한다. RREQ 내의 TxAntSector 필드가, RREQ 프레임의 Tx 안테나 섹터 번호를 전송한 STA인, STA1을 포함한다는 점을 주목한다. STA는 또한 링크 품질을 결정하기 위해 수신된 RREQ의 신호 품질을 고려할 수 있다. 계산의 결과로서, STA는 계산된 메트릭 값을 변수 LinkMetricForward에 저장한다.

이어서, STA는 도 15a에서의 단계(300)와 동등한 로직(398)을 실행한다. 도 18a에서의 블록(398)은 TargetNeighbor를 향한 송신 섹터를 결정한다. 이 단계의 결과로서, STA는, 이미 설명된 바와 같이, AffectRatio 및 BestSector를 결정한다.

STA는 자신(STA2)과 이웃 STA(STA1) 사이의 링크 메트릭 값들을 추가로 계산(400)한다. STA는 수신된 RREQ 엘리먼트 내의 RxQual[BestSector] 필드를 참조하여 링크 품질을 픽업한다. RREQ 내의 RxQual 필드가 STA1의 STA2로부터의 수신 신호 품질을 포함한다는 점이 인식되어야 한다. STA는 계산된 메트릭 값을 변수 LinkMetricReverse에 저장한다.

이어서, STA는 수신된 RREQ 엘리먼트 내의 Metric 필드 내의 값(LinkMetricForward 및 LinkMetricReverse)을 누적함으로써 PathMetric을 결정(402)한다.

STA는 자신의 라우팅 테이블을 룩업(탐색)(404)하고 Dest가 수신된 RREQ 엘리먼트 내의 Orig STA 필드와 동일한 것에 의해 식별된 인스턴스를 픽업한다. STA가 그러한 인스턴스를 찾을 수 없으면, STA는 새로운 라우팅 테이블 인스턴스를 생성한다. STA는 RouteTable 포인터를 픽킹된 또는 새로 생성된 라우팅 테이블 인스턴스로 설정한다.

STA는 이어서 RREQ의 시퀀스 번호 및 메트릭 값을 평가한다(도 18b에서의 406). 수신된 RREQ가 새로운 루트 셋업 또는 유지 시도(RREQ.SeqNum > RouteTable.d.SeqNum)이거나 계산된 PathMetric이 이전에 RouteTable에 저장된 메트릭 값보다 양호하면(작으면), STA가 목적지 STA까지의 후보 루트를, TargetNeighbor를 목적지 STA까지의 다음 홉 STA로서 사용하도록 제안하는 새로운 데이터로 대체하는 블록(408)이 실행된다. 위의 조건이 충족되지 않으면, STA는 수신된 RREQ 프레임을 단순히 폐기하고 블록(420)에서 이 프로세스를 종료한다.

STA가 블록(408)에 따라 목적지 STA까지의 후보 루트를 대체하면, 그 블록에 보이는 바와 같이, STA는 RouteTable 내의 멤버들을 도시된 변수들로 대체한다.

이어서 STA는 TrafficID 필드 및 QoSSpec 필드에 포함된 정보를 TargetNeighbor의 g.AccessTime에 저장(410)한다.

RREQ 프레임 내의 Dest STA 필드가 그 자신의 어드레스와 매칭하는지의 결정이 이루어진다(412). 이것이 그 자신의 어드레스이면, STA는 RREP 프레임의 전송을 스케줄링하도록 타이머(RREP 송신 타이머)를 설정하기 위해 블록(418)을 실행한다.

그렇지 않으면, RREQ 프레임 내의 Dest STA 필드가 그 자신의 어드레스와 상이하면, STA는 블록(414)에 도달하고, Metric 필드를 PathMetric으로 오버라이트하기 위해, 수신된 RREQ 프레임 내의 필드들을 전송 RREQ 프레임에 복사한다. 그 후에, STA는 RREQ를 이웃 STA들로 전파하기 위해 도 14에서의 블록(280)과 동등한 프로세스(416)를 실행하며, 그 세부사항들은 이전의 섹션에서 설명되었다.

2.7.3.2. STA2@P2/P5에서의 이웃 리스트 및 라우팅 테이블

RREQ 프레임의 수신 시에 스테이션(예컨대, 이 예에서 STA2)이 어떻게 거동하는지를 위에서 설명하였으며, 도 18b에서의 블록(410)까지의 단계들은 RREQ 수신 프로세스를 예시하고, 단계들(414 및 416)은 RREQ 전파 프로세스를 도시하고 있다.

도 19는 RREQ 수신 프로세스의 결과로서 STA2의 이웃 리스트 및 라우팅 테이블이 어떻게 업데이트되었는지의 예시적인 실시예(430)를 도 13에서의 시간 기준 P2를 고려하여 예시하고 있다. 도 19는 참여 스테이션들에 대한 이웃 리스트들(STA1(432), STA3(434), STA4(436), STA5(438))을 묘사하고, Dest = STA1에 대한 라우팅 테이블(440)을 도시하고 있다. 업데이트된 값들, 구체적으로는 STA1(432)에 대해 e.CardSector = 3, g.AccessTime[0] = x, 및 라우팅 테이블(440) 전체가 도시되어 있음을 알 것이다.

위의 업데이트들은 도 18a에서의 단계(398)로부터의 결과로서 발생하고, STA2는 STA1의 이웃 리스트 인스턴스들 내의 e.CandSector를 적절한 번호(최상의 유효 링크 레이트를 제공하는 Tx 안테나 섹터)로 설정한다. 도 18b에서의 단계(410)로부터의 결과로서, Traffic ID 및 QoSSpec은 이웃 리스트 인스턴스 내의 g.AccessTime에 기입된다. 또한, 그 도면의 단계(408)로부터의 결과로서, STA2는 Dest = STA1인 라우팅 테이블 인스턴스를 생성하였다.

도 20은 도 13에 보이는 바와 같은, RREQ 전파 프로세스의 결과로서 이웃 리스트들을 보여주는 예시적인 실시예(450)를 예시하고 있으며, 도 18b에서의 블록(416)에 따라 설명된 로직에 따라 STA2는 RREQ를 STA3, STA4, 및 STA5로 전송한다. 도 13에서의 시간 기준 P5인 RREQ 전송 시에, STA2의 이웃 리스트가 업데이트된다. 도 20에는 이웃 리스트(STA1(452), STA3(454), STA4(456), STA5(458)) 및 Dest = STA1에 대한 라우팅 테이블(460)이 도시되어 있다.

도 18a에서의 단계(398)로부터의 결과로서, STA2는 이웃 리스트 인스턴스들 내의 e.CandSector를 적절한 번호(최상의 유효 링크 레이트를 제공하는 Tx 안테나 섹터)로 설정한다. 도 15b에 보이는 바와 같은 단계(304 및 306)로부터의 결과로서, 제안된 채널 할당 시간 및 연관된 정보가 이웃 리스트 인스턴스들 내의 g.AccessTime에 기입된다. RREQ 전송 프로세스의 결과로서의 도 20의 리스트들에서의 변화들은 파선으로 둘러싸여 도시되어 있다.

2.7.3.3. STA4@P6에서의 이웃 리스트 및 라우팅 테이블

STA2가 전송한 RREQ 프레임들이 STA3, STA4, 및 STA5에 수신된다. 이 하위절에서는, STA4에 초점을 맞추어, 본 개시내용에 따라 RREQ의 수신 시에 STA4가 어떻게 거동하는지를 설명한다.

도 21은 STA2(472), STA3(474), 및 STA1의 Dest를 갖는 라우팅 테이블에 대한 데이터 업데이트들의 예시적인 실시예(470)를 예시하고 있다. STA4가 RREQ 프레임을 수신했을 때, STA4가 도 18a 및 도 18b에 도시된 것과 동일한 로직을 실행하여 업데이트들이 발생한다. 도 18b의 단계(410)까지, STA4는 STA2와 동일한 프로세싱을 따라서 자신의 이웃 리스트 및 라우팅 테이블을 업데이트한다. 그 결과, 도 13에서의 시간 기준 P6에서, STA4의 이웃 리스트 및 라우팅 테이블은 도 21에 보이는 바와 같이 업데이트된다.

도 18a에서의 단계(398)로부터의 결과로서, STA4는 STA2의 이웃 리스트 인스턴스들 내의 e.CandSector를 적절한 번호(최상의 유효 링크 레이트를 제공하는 Tx 안테나 섹터)로 설정한다. 도 18b의 단계(410)로부터의 결과로서, Traffic ID 및 QoSSpec은 이웃 리스트 인스턴스 내의 g.AccessTime에 기입된다. 또한, 단계(408)로부터의 결과로서, STA4는 Dest = STA1인 라우팅 테이블 인스턴스를 생성하였다. 도 21에서, RREQ 수신 프로세스의 결과로서의 데이터 업데이트는 파선으로 둘러싸여 도시되어 있다.

도 18b에서의 단계(412)에서, STA4는 RREQ 내의 Dest STA 필드가 자신과 동등하다고 결정한다. 그와 같이, STA4는 RREQ를 더 전파하지 않고, RREP로 응답하기 위해 RREP 송신 타이머를 시작한다.

2.7.4. RREP 송신기 STA 거동

2.7.4.1. RREP 송신기 STA 로직 흐름

도 22는 RREP 송신 타이머가 기동(트리거)될 때의 프로세스 흐름의 예시적인 실시예(490)를 예시하고 있다. 위에서 논의된 바와 같이, 이 타이머는 목적지 STA에서 설정되며, 이벤트는 목적지 STA에서 발생한다. 도 13에 도시된 예시적인 시나리오에서, STA4는 이 프로세스를 시작(492)하기 위해 RREP 전송 절차를 개시한다. 블록(494)에서, STA는 수신된 RREQ 프레임 내의 필드들을 전송 RREP 내의 필드들에 복사하고, 이어서 RREP 프레임 내의 Metric 필드를 초기화한다. 이어서, STA는, 종료(498)하기 전에, RREP를 이웃 STA로 전파(496)하는 로직을 실행하는데, 이는 다음 도면에서 상술된다.

도 23은 블록(512)에서 시작되는 바와 같은, RREP를 이웃 STA로 전파하기 위한 프로세스 흐름의 예시적인 실시예(510)를 예시하고 있다. STA는 자신의 라우팅 테이블을 룩업(탐색)(514)하고 RREP 엘리먼트 내의 Dest == OrigSTA인 인스턴스를 픽업한다(찾는다). STA는 RouteTable 포인터를 픽킹된 인스턴스로 설정한다. 이어서 블록(516)에서, STA는 RouteTable 내의 a.NextHop을 RREP 프레임 내의 RA 필드에 복사하고, RouteTable 내의 b.TxAntSec를 RREP 프레임의 TxAntSector 필드에 복사한다. 게다가, STA는 이 RouteTable 인스턴스를 유효성 확인하기 위해 RouteTable의 g.ValidFlag를 True로 설정한다. 유효성 확인의 결과로서, RouteTable 정보는 라우팅 테이블의 판독 섹션(read section)으로 송신되며, 이는 데이터 포워딩(릴레잉(relaying))에 사용된다.

이어서 블록(518)에서, STA는 자신의 이웃 리스트를 룩업(탐색)하고, RouteTable 내의 a.NextHop와 매칭하는 이웃 리스트 인스턴스를 픽업하고(찾고), TargetNeighbor는 이 인스턴스를 식별해준다.

블록(520)에서, STA는 RouteTable 내의 b.TxAntSec를 사용하여 이 트래픽이 TargetNeighbor로 전송되어야 하는 때를 결정한다. 이용가능한 시간 할당을 탐색하기 위해 전송 RREP 엘리먼트 내의 QoSSpec 필드에 설정된 정보(요청된 대역폭), 및 이웃 리스트 인스턴스들 내의 c.TxQuality[RouteTable.b.TxAntSec] 및 b.TrafficAct[]가 참조된다.

블록(522)에서, 이용가능한 채널 시간을 찾아낸 후에, 결정된 채널 시간이 RREP 엘리먼트 내의 AccessTime 필드에 복사되고 TargetNeighbor 내의 g.AccessTime에 저장된다. 여기서, 이 채널 시간 할당은 결정된 할당이고, STA가 데이터 프레임들을 전송하려고 의도할 때 시간 정보가 사용된다.

이어서 블록(524)에서, STA는 e.CandSector를 TargetNeighbor 내의 d.TxAntSector에 복사한다. 이 값을 설정하는 것에 의해, 송신 안테나 섹터가 확인되고 실제 사용에 유효하다.

블록(526)에서, STA는 그 자신의 어드레스를 RREP 프레임 내의 TA 필드에 복사하고, 이어서, 이 프로세스를 종료(528)하기 전에, RouteTable의 b.TxAntSec에 의해 식별되는 Tx 안테나 섹터를 사용하여 RREP 프레임을 TargetNeighbor로 전송한다.

2.7.4.2. STA4@P7에서의 이웃 리스트 및 라우팅 테이블

도 24는 STA4에서의 STA2(532), STA3(534)의 이웃 리스트들 및 Dest = STA1의 라우팅 테이블(540)에 대한 업데이트들의 예시적인 실시예(530)를 예시하고 있다. 이전의 섹션들에서, 목적지 STA인 STA4가 RREP 전송 시에 어떻게 거동하는지가 논의되었다. 도 13에서의 시간 기준 P7인 RREP 전송의 결과로서, STA4의 이웃 리스트 및 라우팅 테이블이 업데이트된다.

도 23에서의 단계(516)로부터의 결과로서, STA4는 Dest == STA1인 라우팅 테이블 인스턴스를 유효성 확인한다. 도 23에서의 단계(524)의 결과로서, STA4는 STA2의 이웃 리스트 인스턴스들 내의 d.TxAntSector를 적절한 번호(최상의 유효 링크 레이트를 제공하는 Tx 안테나 섹터)로 설정한다. 도 23의 단계(520)로부터의 결과로서, 결정된 채널 시간 정보는 이웃 리스트 인스턴스 내의 g.AccessTime에 기입된다. 이 도면에서, RREP 개시 프로세스의 결과로서 업데이트된 데이터는 파선으로 둘러싸여 도시되어 있다.

2.7.5. RREP 수신기 STA 거동

2.7.5.1. RREP 수신기 STA 로직 흐름 1

도 25는 블록(552)에서 시작되는 RREP 수신 절차의 예시적인 실시예(550)를 예시하고 있다. STA는 이웃 STA로부터 RREP를 수신할 시에 이 프로세스를 시작(552)한다. 도 13에 도시된 시나리오에서, STA4에 의해 전송된 RREP는 STA2에 수신된다. RREP 프레임을 수신하는 STA는 이 도면에 도시된 로직을 실행하며, 이 하위절의 논의는 STA2 및 STA2가 RREP의 수신을 어떻게 핸들링하도록 구성되는지에 초점을 맞추고 있다.

STA가 자신의 이웃 STA 중 하나로부터 RREP 프레임을 수신할 때, RREQ 전파 프로세스에 내장된(built in) 것은 후보 루트의 확인이다. RREP 프레임을 수신하는 STA는 이웃 STA로부터의 RREP 수신 확인(554) 절차를 실행하며, 이 절차는 추후 섹션에서 상세하게 논의될 것이다.

RREP 프레임 내의 OrigSTA 필드가 그 자신의 어드레스와 매칭하는지의 결정이 이루어진다(556). RREP 프레임이 그 자신의 어드레스와 매칭하면, 실행은 종료(562)로 이동하고, RREP가 발신 STA에 도달했을 때 STA는 루트 셋업 프로세스를 마무리할 것이며, 목적지 STA까지의 모든 루트들이 셋업되었다.

그렇지 않고, RREP 프레임 내의 OrigSTA 필드가 그 자신의 어드레스와 상이하면, STA는 수신된 RREP 프레임 내의 필드들을 전송 RREP 프레임에 복사(558)하고, 도 22에서의 496과 동등한, RREP를 이웃 STA로 전파(560)하는 프로세스를 실행한다.

2.7.5.2. RREP 수신기 STA 로직 흐름 2

도 26은, 도 25의 블록(554)에서 실행된 바와 같은, 이웃 STA로부터의 RREP 수신을 확인하는 예시적인 실시예(570)를 예시하고 있다. 이 프로세스는 블록(572)에서 시작되고, 이어서 STA는 자신의 라우팅 테이블을 룩업(탐색)(574)하고 Dest가 수신된 RREP 엘리먼트 내의 DestSTA 필드와 동일한 것에 의해 식별된 인스턴스를 픽업한다(찾는다). STA가 그러한 인스턴스를 찾을 수 없으면, STA는 새로운 라우팅 테이블 인스턴스를 생성한다. STA는 RouteTable 포인터를 픽킹된 또는 새로 생성된 라우팅 테이블 인스턴스로 설정한다.

블록(576)에서, STA는 자신의 이웃 리스트를 룩업(탐색)하고 RREP 프레임 내의 TA 필드와 매칭하는 인스턴스를 픽업한다(찾는다). 이 인스턴스는 NeighborEntry에 의해 식별된다.

블록(578)에서, STA는 RouteTable 내의 멤버들을 도시된 변수들로 대체한다. 여기서, STA는 이 RouteTable 인스턴스를 유효성 확인하기 위해 RouteTable의 g.ValidFlag를 True로 설정한다. 유효성 확인의 결과로서, RouteTable 정보는 라우팅 테이블의 판독 섹션으로 송신되며, 이는 데이터 포워딩(릴레잉)에 사용된다.

이어서, 채널 시간 할당이 결정된 할당이고 STA가 데이터 프레임들을 전송하려고 의도할 때 시간 정보가 사용되도록 하기 위해, STA는 NeighborEntry의 g.AccessTime을 유효성 확인(580)한다.

블록(582)에서, STA는 e.CandSector를 NeighborEntry 내의 d.TxAntSector에 복사한다. 이 값을 설정하는 것에 의해, 송신 안테나 섹터가 확인되고 실제 사용에 유효하며, 프로세스가 종료(584)된다.

2.7.5.3. STA2@P8에서의 이웃 리스트 및 라우팅 테이블

도 27은 STA2@P8의 이웃 리스트 및 라우팅 테이블 상태의 예시적인 실시예(590)를 예시하고 있다. 이 도면에는 STA1(592), STA3(594), STA4(596), STA5(598)는 물론 Dest = STA1(600) 및 Dest = STA4(602)의 라우팅 테이블에 대한 업데이트들이 도시되어 있다. 이전의 섹션들에서는, RREP 수신 시에 STA2가 어떻게 거동하도록 구성되는지가 논의되었다. 도 13에서의 시간 기준 P8인 RREP 수신 및 RREP 전파의 결과로서, STA2의 이웃 리스트 및 라우팅 테이블이 업데이트된다.

도 26에서의 단계(578)로부터의 결과로서, STA2는 Dest == STA4인 라우팅 테이블 인스턴스를 생성하고 유효성 확인한다. 도 26의 단계(580)의 결과로서, STA2는 STA4의 이웃 리스트 인스턴스 내의 g.AccessTime을 유효성 확인한다. 도 26에서의 단계(582)의 결과로서, STA2는 STA4의 이웃 리스트 인스턴스 내의 d.TxAntSector를 적절한 번호로 설정한다.

도 23에서의 단계(516)로부터의 결과로서, STA2는 Dest == STA1인 라우팅 테이블 인스턴스를 유효성 확인한다. 도 23에서의 단계(524)의 결과로서, STA2는 STA1의 이웃 리스트 인스턴스 내의 d.TxAntSector를 적절한 값으로 설정한다. 도 23에서의 단계(520)로부터의 결과로서, 결정된 채널 시간 정보는 이웃 리스트 인스턴스 내의 g.AccessTime에 기입된다. 게다가, 다른 이웃 리스트 인스턴스들 내의 g.AccessTime은 확인 타임아웃마다 NULL로 복귀된다. 도 27에서, 업데이트된 필드들은 RREP 수신 및 RREP 전파 프로세스의 결과로서 파선으로 둘러싸여 도시되어 있다.

2.7.5.4. STA1@P9에서의 이웃 리스트 및 라우팅 테이블

도 28은 STA2(612), STA3(614)에 대한 STA1@P9의 이웃 리스트 및 라우팅 테이블 상태, 및 Dest = STA4에 대한 라우팅 테이블(620)의 예시적인 실시예(610)를 예시하고 있다. STA2가 전송한 RREP 프레임이 STA1에 수신된다. STA1이 RREP 프레임을 수신했을 때, STA1은 도 25에 도시된 것과 동일한 로직을 실행한다. STA1은 도 25에서의 단계(554)에서의 동일한 로직을 실행하지만, STA1은 RREP 프레임 내의 OrigSTA 필드가 그 자신의 어드레스와 매칭한다고 결정하고 이 절차를 마무리한다. 그 결과, 도 13에서의 시간 기준 P9에서, STA1의 이웃 리스트 및 라우팅 테이블은 도 28에 보이는 바와 같이 업데이트되었다.

특히, 도 26으로부터의 단계(578)의 결과로서, STA1은 Dest == STA4인 라우팅 테이블 인스턴스를 생성하고 유효성 확인한다. 도 26으로부터의 단계(580)의 결과로서, STA1은 STA2의 이웃 리스트 인스턴스 내의 g.AccessTime을 유효성 확인한다. 도 26으로부터의 단계(582)의 결과로서, STA1은 STA2의 이웃 리스트 인스턴스 내의 d.TxAntSector를 적절한 번호로 설정한다. 테이블들에 대한 변경들은 도 28에서 파선으로 둘러싸여 도시되어 있다.

2.8. 라우팅 테이블을 구성하는 방법(시나리오 2)

도 29는 제2 시나리오에 따른 메시지 시퀀스의 예시적인 실시예(630)를 예시하고 있다. 이 시나리오에서, 도 2에서와 같은 STA 토폴로지가 또다시 가정된다. 이 시나리오에서, 이전의 하위절에서 설명된 바와 같이 STA1이 STA4까지의 루트를 셋업한 후에, STA5는 STA7과 통신하려고 시도하고 있다. STA5가 처음에 STA7까지의 어떠한 유효한 루트도 갖지 않음이 주목되어야 한다. 하기는 이 하위절에서의 루트 셋업 프로세스를 논의한다. 시간 기간들(p21 내지 p25)이 도시되어 있으며, 이들은 본 개시내용 전반에 걸쳐 참조될 수 있다.

2.8.1. 메시지 시퀀스 차트(시나리오 2).

이 시나리오에서, STA5는 트래픽 발신 STA이고, STA7은 트래픽 목적지 STA이다. 다른 STA들은 잠재적인 중간 STA들이지만, STA5로부터 STA7까지의 루트가 결정될 때까지는 어느 STA들이 중간 STA들인지가 불확실하다. 이러한 잠재적인 중간 STA들은 RREQ 프레임 수신 및 RREP 프레임 수신마다 일련의 이벤트들을 활성화시킨다. 발신 STA인 STA5가 데이터 프레임들을 STA7로 전송하려고 시도할 때, STA5는 RREQ 프레임들을 자신의 이웃 STA들로 전송하기 시작하는데, 예시적인 토폴로지에서 이들은 STA2(632), STA4(634), 및 STA6(636)이며, 이러한 이웃 STA들은 RREQ 프레임들을 전파한다. 이 스테이지에서, 이러한 이웃 STA들은 잠재적인 중간 STA들로서 거동한다. 특히 STA2가 RREQ를 STA1(638), STA3(640) 및 STA4(642)로 전파하는 것을 알 수 있다. STA4는 RREQ를 STA2(644), STA3(646), STA6(648) 및 STA7(650)로 전파한다. STA6은 RREQ를 STA4(652) 및 STA7(654)로 전파한다. 이상으로부터의 결과는 STA7이 궁극적으로 RREQ 프레임들을 수신한다는 것이다. 자신의 이웃 STA들로부터 RREQ 프레임들을 수신하는 것에 의해, 목적지 STA인 STA7은 궁극적으로 STA6을 통한 루트가 이 전송에 가장 적합하다고 결정하고, STA6을 발신 STA4를 향한 중간 STA로서 픽업하며, STA5를 향해 RREP 프레임을 생성하는 것으로 다시 응답한다. 특히, STA7은 중간 STA(STA6)를 픽업하기 위해 라우팅 응답(RREP)을 송신한다. RREP의 수신 시에, STA6은 자신이 중간 STA로서 선택되었음을 인식하고, RREP를 다시 발신 STA5로 송신한다. STA5가 STA6을 통해 RREP를 수신할 때, STA5는 STA6을 목적지 STA7을 향한 중간 STA로서 인식한다. 이러한 방식으로, 발신 STA5로부터 목적지 STA7까지의(그리고 STA7로부터 STA5까지의) 엔드-엔드 루트가 확립된다.

2.8.1.1. STA5@P21에서의 이웃 리스트 및 라우팅 테이블

도 30은 STA5@P21의 이웃 리스트 및 라우팅 테이블 상태의 예시적인 실시예(670)를 예시하고 있으며, STA5는 도 14에 도시된 로직을 실행한다. STA2(672), STA4(674), STA6(676)에 대한 이웃 리스트들은 보이지만, 라우팅 테이블(678)은 아직 생성되지 않았다.

도 29에서와 같이, STA5는 설명된 로직에 따라 RREQ를 STA2, STA4, 및 STA6으로 전송한다. 도 29에서의 시간 기준 P21인 RREQ 전송 시에, STA5의 이웃 리스트가 업데이트된다.

도 15a에서의 단계(300)로부터의 결과로서, STA5는 이웃 리스트 인스턴스들 내의 e.CandSector를 적절한 번호(최상의 유효 링크 레이트를 제공하는 Tx 안테나 섹터)로 설정한다. STA5가 안테나 섹터 0을 STA6에 대한 BestSector로서 픽업하는 반면, 안테나 섹터 1이 최고 대역폭을 STA6에 제공한다는 점이 주목되어야 한다. 이것은 안테나 섹터 1이 진행 중인 트래픽을 갖는 STA4에 대한 간섭을 생성한다는 사실로부터 결과된다. 도 16b에서의 단계들(352, 354)인 BestSector 결정 시에, STA5는 안테나 섹터 0에 대한 EffectRate가 안테나 섹터 1에 대한 EffectRate보다 양호한 값을 제공한다고 결정하였다.

도 15b에서의 단계(304, 306)로부터의 결과로서, 제안된 채널 할당 시간 및 연관된 정보가 이웃 리스트 인스턴스들 내의 g.AccessTime에 기입된다. 이 도면에서, RREQ 전송 프로세스의 결과로서 업데이트된 데이터는 파선으로 둘러싸여 도시되어 있다. 이 시점에서, STA5는 라우팅 테이블의 어떠한 인스턴스도 아직 갖지 않는다.

2.8.1.2. STA6@P22에서의 이웃 리스트 및 라우팅 테이블

도 31은 STA6@P22의 이웃 리스트 및 라우팅 테이블 상태의 예시적인 실시예(690)를 예시하고 있다. STA4(692), STA5(694), STA7(696)에 대한 이웃 리스트들이, Dest = STA5에 대한 라우팅 테이블(700)과 함께, 보인다.

STA5에 의해 전송된 RREQ들은 STA2, STA4, 및 STA6에 수신된다. RREQ 프레임을 수신하는 STA들은 도 18a 및 도 18b에 도시된 로직을 실행한다. 다음 섹션은 STA6 및 STA6의 이웃 리스트 및 라우팅 테이블이 어떻게 변하는지에 초점을 맞추고 있다.

도 29에서의 시간 기준 P22인 RREQ 수신 및 RREQ 전파 프로세스의 결과로서, STA6의 이웃 리스트 및 라우팅 테이블이 업데이트된다.

도 18a에서의 단계(398)로부터의 결과로서, STA6은 STA5의 이웃 리스트 인스턴스들 내의 e.CandSector를 적절한 번호(최상의 유효 링크 레이트를 제공하는 Tx 안테나 섹터)로 설정한다. 도 18b에서의 단계(410)로부터의 결과로서, Traffic ID 및 QoSSpec은 이웃 리스트 인스턴스 내의 g.AccessTime에 기입된다. STA6이 안테나 섹터 3을 STA5에 대한 BestSector로서 픽업하는 반면, 안테나 섹터 2가 최고 대역폭을 STA5에 제공한다는 점이 주목되어야 한다. 이것은 안테나 섹터 2가 진행 중인 트래픽을 갖는 STA4에 대한 간섭을 생성한다는 결정으로부터 결과된다. 도 16b에서의 단계들(352, 354)인 BestSector 결정 시에, STA6은 안테나 섹터 3에 대한 EffectRate가 안테나 섹터 2에 대한 EffectRate보다 양호한 값을 제공한다고 결정하였다. 또한, 도 18b에서의 단계(408)로부터의 결과로서, STA6은 Dest = STA5인 라우팅 테이블 인스턴스를 생성하였다.

RREQ 전파 프로세스의 결과로서, 도 29에서와 같이, STA6은 설명된 로직에 따라 RREQ를 STA4 및 STA7로 전송한다. 도 18a에서의 단계(398)로부터의 결과로서, STA6은 STA4 및 STA7의 이웃 리스트 인스턴스들 내의 e.CandSector를 적절한 번호로 설정한다. STA6이 안테나 섹터 0을 STA7에 대한 BestSector로서 픽업하는 반면, 안테나 섹터 1이 최고 대역폭을 STA7에 제공한다는 점이 주목될 것이다. 이것은 안테나 섹터 1이 진행 중인 트래픽을 갖는 STA4에 대한 간섭을 생성한다는 결정으로부터 결과된다. 도 16b에서의 단계들(352, 354)인 BestSector 결정 시에, STA6은 안테나 섹터 0에 대한 EffectRate가 안테나 섹터 1에 대한 EffectRate보다 양호한 값을 제공한다고 결정하였다.

도 15b에서의 단계(304, 306)로부터의 결과로서, 제안된 채널 할당 시간 및 연관된 정보가 이웃 리스트 인스턴스들 내의 g.AccessTime에 기입된다. 이 도면에서, RREQ 전송 프로세스의 결과로서 업데이트된 데이터는 파선으로 둘러싸여 도시되어 있다.

2.8.1.3. STA7@P23에서의 이웃 리스트 및 라우팅 테이블

도 32는 STA7@P23의 이웃 리스트 및 라우팅 테이블 상태의 예시적인 실시예(710)를 예시하고 있다. STA4(712), STA6(714)에 대한 이웃 리스트들이, Dest = STA5에 대한 라우팅 테이블(720)과 함께, 보인다. STA6이 전송한 RREQ 프레임들이 STA4 및 STA7에 수신된다.

이 하위절에서, STA7 및 STA7이 본 개시내용에서 RREQ의 수신 시에 어떻게 거동하도록 구성되는지에 초점이 맞춰져 있다. STA7이 RREQ 프레임을 수신했을 때, STA7은 도 18a 및 도 18b에 도시된 바와 같은 로직을 실행한다. 그 결과, 도 29에서의 시간 기준 P23에서, STA7에 대한 이웃 리스트 및 라우팅 테이블이 업데이트된다.

도 18a에서의 단계(398)로부터의 결과로서, STA7은 STA6의 이웃 리스트 인스턴스들 내의 e.CandSector를 적절한 번호로 설정한다. STA7이 안테나 섹터 3을 STA6에 대한 BestSector로서 픽업하는 반면, 안테나 섹터 2가 최고 대역폭을 STA6에 제공한다는 점이 주목되어야 한다. 이 결과는 안테나 섹터 2가 진행 중인 트래픽을 갖는 STA4에 대한 간섭을 생성한다는 결정으로부터 발생한다. 도 16b에서의 단계들(352, 354)인 BestSector 결정 시에, STA7은 안테나 섹터 3에 대한 EffectRate가 안테나 섹터 2에 대한 EffectRate보다 양호한 값을 제공한다고 결정하였다. 또한, 도 18b에서의 단계(408)로부터의 결과로서, STA7은 Dest = STA6인 라우팅 테이블 인스턴스를 생성하였다. STA7은 RREP 송신 타이머 만료마다 도 22에 도시된 로직을 추가로 실행하고, RREP 프레임을 STA6으로 전송한다. 도 29에서의 시간 기준 P23인 RREP 전송의 결과로서, 도 32에 도시된 바와 같이 STA7의 이웃 리스트 및 라우팅 테이블이 업데이트된다.

도 23에서의 단계(516)로부터의 결과로서, STA7은 Dest == STA5인 라우팅 테이블 인스턴스를 유효성 확인한다. 도 23에서의 단계(524)의 결과로서, STA7은 STA6의 이웃 리스트 인스턴스들 내의 d.TxAntSector를 적절한 번호로 설정한다. 도 23에서의 단계(520)로부터의 결과로서, 결정된 채널 시간 정보는 이웃 리스트 인스턴스 내의 g.AccessTime에 기입된다. 이 도면에서, RREQ 수신 및 RREP 개시 프로세스의 결과로서 업데이트된 데이터는 파선으로 둘러싸여 도시되어 있다.

2.8.1.4. STA6@P24에서의 이웃 리스트 및 라우팅 테이블

도 33은 STA6@P24의 이웃 리스트 및 라우팅 테이블 상태의 예시적인 실시예(730)를 예시하고 있다. STA4(732), STA5(734), STA7(736)에 대한 이웃 리스트들이, Dest = STA5에 대한 라우팅 테이블(738), 및 Dest = STA7에 대한 라우팅 테이블(740)과 함께, 보인다. STA7에 의해 전송된 RREP는 STA6에 수신된다. RREP 프레임을 수신하는 STA는 도 25에 도시된 로직을 실행한다. 그 결과, STA6은 루트들을 확인하고 RREP를 STA5로 전파한다.

도 29에서의 시간 기준 P24인 RREP 수신 및 RREP 전파의 결과로서, STA6에 대한 이웃 리스트 및 라우팅 테이블이 업데이트된다.

단계(S93)로부터의 결과로서, STA6은 Dest == STA7인 라우팅 테이블 인스턴스를 생성하고 유효성 확인한다. 도 26에서의 단계(580)의 결과로서, STA6은 STA7의 이웃 리스트 인스턴스 내의 g.AccessTime을 유효성 확인한다. 도 26에서의 단계(582)의 결과로서, STA6은 STA7의 이웃 리스트 인스턴스 내의 d.TxAntSector를 적절한 번호로 설정한다.

도 23에서의 단계(516)로부터의 결과로서, STA6은 Dest == STA5인 라우팅 테이블 인스턴스를 유효성 확인한다. 도 23에서의 단계(524)의 결과로서, STA6은 STA5의 이웃 리스트 인스턴스들 내의 d.TxAntSector를 적절한 번호로 설정한다. 도 23에서의 단계(520)로부터의 결과로서, 결정된 채널 시간 정보는 이웃 리스트 인스턴스 내의 g.AccessTime에 기입된다. 게다가, 다른 이웃 리스트 인스턴스들 내의 g.AccessTime은 확인 타임아웃마다 NULL로 복귀된다. 이 도면에서, RREP 수신 및 RREP 전파 프로세스의 결과로서 업데이트된 데이터는 파선으로 둘러싸여 도시되어 있다.

2.8.1.5. STA5@P25에서의 이웃 리스트 및 라우팅 테이블

도 34는 STA5@P25의 이웃 리스트 및 라우팅 테이블 상태의 예시적인 실시예(750)를 예시하고 있다. STA2(752), STA4(754), STA6(756)에 대한 이웃 리스트들이, Dest = STA7에 대한 라우팅 테이블(760)과 함께, 보인다.

STA6이 전송한 RREP 프레임이 STA5에 수신된다. STA5가 RREP 프레임을 수신했을 때, STA5는 도 25에 도시된 로직을 실행한다. STA5는 RREP 프레임 내의 OrigSTA 필드가 그 자신의 어드레스와 매칭한다고 결정하고 이 절차를 마무리한다. 그 결과, 도 29에서의 시간 기준 P25에서, STA5에 대한 이웃 리스트 및 라우팅 테이블이 업데이트된다.

도 26에서의 단계(578)로부터의 결과로서, STA5는 Dest == STA7인 라우팅 테이블 인스턴스를 생성하고 유효성 확인한다. 도 26의 단계(580)의 결과로서, STA5는 STA6의 이웃 리스트 인스턴스 내의 g.AccessTime을 유효성 확인한다. 도 26에서의 단계(582)의 결과로서, STA5는 STA6의 이웃 리스트 인스턴스 내의 d.TxAntSector를 적절한 번호로 설정한다.

2.9. 라우팅 테이블을 구성하는 방법(시나리오 3)

이 시나리오에서, 도 2에 보이는 바와 같은 STA 토폴로지가 또다시 가정된다. 이 시나리오에서, STA1이 STA4까지의 자신의 루트를 리프레시하고 있다. 위의 논의의 결과로서 셋업된 통신이 진행 중임이 주목될 것이다. STA1이 STA4까지의 유효한 루트를 갖지만, 이번에는, 이 루트를 셋업한 후에 STA5로부터 STA7로의 트래픽이 추가됨에 따라 바람직한 루트가 변할 것이다. 하기는 이 하위절에서의 루트 유지 프로세스를 논의한다.

2.9.1. 메시지 시퀀스 차트(시나리오 3).

도 35는 이러한 루트 셋업 프로세스의 전반적인 프레임 교환 시퀀스의 예시적인 실시예(770)를 예시하고 있다. 이 시나리오에서, 발신 STA(STA1)는, 목적지 STA(STA4)를 향한 루트를 리프레시하기 위해, RREQ 프레임들을 STA2(772) 및 STA3(774)을 포함하는 자신의 이웃 STA들로 전송하기 시작한다. RREQ를 수신한 STA는, 자신이 이 루트 셋업 시도의 목적지 STA가 아닌 한, RREQ를 자신의 이웃 STA들로 전파한다. 이웃 STA들(STA2, STA3)은 RREQ 프레임들을 전파한다. 특히, STA2는 RREQ를 STA3(776), STA4(778) 및 STA5(780)로 전파하고, STA3은 RREQ를 STA2(782) 및 STA4(784)로 전파하며, STA5는 RREQ를 STA4(786) 및 STA6(788)으로 전파하고, STA6은 RREQ를 STA4(790) 및 STA7(792)로 전파하는 반면, STA7은 RREQ를 STA4(794)로 전파한다. 시간 기간들(p41 내지 p49)이 도시되어 있으며, 이들은 본 개시내용 전반에 걸쳐 참조될 수 있다.

이러한 방식으로, STA4가 RREQ 프레임들을 수신한다는 것을 알 수 있다. 이 RREQ는 시나리오 1에서 이전에 논의된 것과 상이한 루트 발견 프로세스이기 때문에, 발신 STA(STA1)는 전송 RREQ 내의 SeqNum 값을 증분시킨다. 자신의 이웃 STA들로부터 RREQ 프레임들을 수신하는 것에 의해, STA4는 궁극적으로 STA3을 통한 루트가 이 전송에 보다 양호하다고 결정하고, STA3을 통해 STA1을 향해 RREP 프레임(796)으로 다시 응답한다. RREP 프레임(796)의 수신 시에, STA3은 자신이 중간 STA로서 선택되었음을 인식하고, STA3은 RREP 프레임(798)을 생성하여 STA1로 송신한다. STA1이 STA3을 통해 RREP를 수신할 때, STA1은 STA가 목적지 STA4를 향한 새로운 중간 STA임을 인식한다. 이러한 방식으로, STA1로부터 STA4까지의(그리고 STA4로부터 STA1까지의) 엔드-엔드 루트가 리프레시된다.

2.9.1.1. STA1@P41에서의 이웃 리스트 및 라우팅 테이블

도 36은 STA1@P41의 이웃 리스트 및 라우팅 테이블 상태의 예시적인 실시예(810)를 예시하고 있다. STA2(812), STA3(814)에 대한 이웃 리스트들이, Dest = STA4에 대한 라우팅 테이블(820)과 함께, 보인다.

STA1은 도 14에 도시된 로직을 실행한다. 이제 STA4를 향한 루트의 만료가 가까이 다가오고 있으며, 따라서 STA1은 RREQ 생성을 시작한다. 도 35에서와 같이, STA1은 설명된 로직에 따라 RREQ를 STA2 및 STA3으로 전송한다. 도 35에서의 시간 기준 P41인 RREQ 전송 시에, 마지막 업데이트 이후로 STA1의 이웃 리스트 및 라우팅 테이블이 변경되지 않는다.

2.9.1.2. STA2@P43에서의 이웃 리스트 및 라우팅 테이블

도 37은 STA2@P43의 이웃 리스트 및 라우팅 테이블 상태의 예시적인 실시예(830)를 예시하고 있다. STA1(832), STA3(834), STA4(836), STA5(838)에 대한 이웃 리스트들이, Dest = STA1(840) 및 Dest = STA4(842)에 대한 라우팅 테이블들과 함께, 보인다.

STA1에 의해 전송된 RREQ들은 STA2 및 STA3에 수신된다. RREQ 프레임의 수신 시에, STA2는 도 18a 및 도 18b에 도시된 로직을 실행한다. STA2는, 이 로직에 따라, 자신의 라우팅 테이블을 업데이트하고 RREQ 프레임들을 자신의 이웃 STA들로 전파한다.

도 35에서의 시간 기준 P43인 RREQ 수신 및 RREQ 전파 프로세스의 결과로서, STA2와 관련한 이웃 리스트 및 라우팅 테이블이 업데이트된다.

이 트랜잭션은 유지를 위한 것이기 때문에, 이웃 리스트 인스턴스들에 대한 어떠한 변경들로 이루어지지 않는다. 그렇지만, 도 18b에서의 단계(408)로부터의 결과로서, STA2는 Dest = STA1인 라우팅 테이블 인스턴스를 RREQ(41) 수신에 의해 획득된 정보로 오버라이트하였다. 수신된 RREQ의 SeqNum이 STA2의 라우팅 테이블 내의 것보다 크기 때문에 이것이 발생한다. 이 도면에서, RREQ 전송 프로세스의 결과로서 업데이트된 데이터는 파선으로 둘러싸여 도시되어 있다.

2.9.1.3. STA4@P44에서의 이웃 리스트 및 라우팅 테이블

도 38은 STA4@P44의 이웃 리스트 및 라우팅 테이블 상태에 대한 예시적인 실시예(850)를 예시하고 있다. STA2(852), STA3(854)에 대한 이웃 리스트들이, Dest = STA1에 대한 라우팅 테이블(860)과 함께, 보인다. STA2가 전송한 RREQ 프레임들이 STA3, STA4, 및 STA5에 수신된다. 하기는 STA4가 이 경우에 어떻게 거동하도록 구성되는지에 초점을 맞추고 있다.

STA4가 RREQ 프레임을 수신했을 때, STA4는 도 18a 및 도 18b에 도시된 바와 같은 로직을 실행한다. 그 결과, 도 35에서의 시간 기준 P44에서, STA4의 이웃 리스트 및 라우팅 테이블이 업데이트된다.

도 18a에서의 단계(398)로부터의 결과로서, STA4는 STA2의 이웃 리스트 인스턴스들 내의 e.CandSector를 적절한 번호로 설정한다. BestSector가 1로부터 0으로 변경된다는 점이 주목되어야 한다. STA4의 Tx 안테나 섹터 1은 STA5에 영향을 미친다. 이제 STA5는 통신을 시작하였고, STA4는 Tx 안테나 섹터 0을 보다 바람직한 섹터로서 선택하였다. 이 결정은 도 16b에서의 단계들(348, 350, 352)로부터 결론된다.

또한, 도 18b에서의 단계(408)로부터의 결과로서, STA4는 Dest = STA1인 라우팅 테이블 인스턴스를 업데이트하였다. 수신된 RREQ의 SeqNum이 STA4의 라우팅 테이블 내의 것보다 크기 때문에 이것이 발생한다. 또한, 라우팅 테이블 인스턴스의 b.TxAntSec가 또한 0으로 업데이트된다는 점이 주목되어야 한다. 이 도면에서, RREQ 수신 및 RREP 개시 프로세스의 결과로서 업데이트된 데이터는 파선으로 둘러싸여 도시되어 있다.

2.9.1.4. STA3@P45에서의 이웃 리스트 및 라우팅 테이블

도 39는 STA3@P45의 이웃 리스트 및 라우팅 테이블 상태에 대한 예시적인 실시예(870)를 예시하고 있다. STA1(872), STA2(874), STA4(876)에 대한 이웃 리스트들이, Dest = STA1에 대한 라우팅 테이블(880)과 함께, 보인다.

STA1에 의해 전송된 RREQ는 STA3에 또한 수신된다. STA3은 도 18a 및 도 18b에 도시된 로직을 또한 실행한다. 도 35에서의 시간 기준 P45인 RREQ 수신 및 RREQ 전파 프로세스의 결과로서, STA3의 이웃 리스트 및 라우팅 테이블이 업데이트된다.

STA3은 STA1의 이웃 리스트 인스턴스 내의 e.CandSector를 변경하지 않았는데, 그 이유는 그것이 지난 번 이후로 변경되지 않았기(0으로 유지되기) 때문이다. 도 18b에서의 단계(410)로부터의 결과로서, Traffic ID 및 QoSSpec은 이웃 리스트 인스턴스 내의 g.AccessTime에 기입된다(이전의 기록은 확인 타임아웃마다 제거되었다). 또한, 도 18b에서의 단계(408)로부터의 결과로서, STA3은 Dest = STA1인 라우팅 테이블 인스턴스를 업데이트하였다. 수신된 RREQ의 SeqNum이 STA4의 라우팅 테이블 내의 것보다 크기 때문에 이것이 발생한다.

RREQ 전파 프로세스의 결과로서, 도 35에서와 같이, STA3은 설명된 로직에 따라 RREQ를 STA2 및 STA4로 전송한다. 도 15b에서의 단계(304, 308)로부터의 결과로서, 제안된 채널 할당 시간 및 연관된 정보가 STA2 및 STA4의 이웃 리스트 인스턴스들 내의 g.AccessTime에 기입된다. 이 도면에서, RREQ 전송 프로세스의 결과로서 업데이트된 데이터는 파선으로 둘러싸여 도시되어 있다.

2.9.1.5. STA4@P46에서의 이웃 리스트 및 라우팅 테이블

도 40은 STA4@P46의 이웃 리스트 및 라우팅 테이블 상태에 대한 예시적인 실시예(890)를 예시하고 있다. STA2(892), STA3(894)에 대한 이웃 리스트들이, Dest = STA1에 대한 라우팅 테이블(900)과 함께, 보인다. STA3이 전송한 RREQ 프레임들이 STA2 및 STA4에 수신된다. 하기는 STA4가 본 개시내용에 따라 어떻게 거동하도록 구성되는지에 초점을 맞추고 있다.

STA4가 RREQ 프레임을 수신했을 때, STA4는 도 18a 및 도 18b에 도시된 바와 같은 로직을 실행한다. 그 결과, 도 35에서의 시간 기준 P46에서, STA4의 이웃 리스트 및 라우팅 테이블이 업데이트된다.

도 18b에서의 단계(408)로부터의 결과로서, STA4는 Dest = STA1인 라우팅 테이블 인스턴스를 업데이트하였다. STA3을 통한 메트릭 값이 라우팅 테이블 내의 것보다 양호하기(작기)(210 < 220) 때문에 이것이 발생한다. 라우팅 테이블 인스턴스가 RREQ(47)에 의해 수신된 정보로 오버라이트된다. 이제 STA1을 향한 다음 홉 STA가 STA3으로 설정된다.

도 18b에서의 단계(410)로부터의 결과로서, Traffic ID 및 QoSSpec은 이웃 리스트 인스턴스 내의 g.AccessTime에 기입된다(이전의 기록은 확인 타임아웃마다 제거되었다). 이 도면에서, RREQ 수신 및 RREP 개시 프로세스의 결과로서 업데이트된 데이터는 파선으로 둘러싸여 도시되어 있다. STA4는 또한 STA3을 통해 RREP로 응답하기 위해 RREP 송신 타이머를 실행한다.

2.9.1.6. STA4@P47에서의 이웃 리스트 및 라우팅 테이블

도 41은 STA4@P47의 이웃 리스트 및 라우팅 테이블 상태에 대한 예시적인 실시예(910)를 예시하고 있다. STA2(912), STA3(914)에 대한 이웃 리스트들이, Dest = STA1에 대한 라우팅 테이블(920)과 함께, 보인다. STA4에서, RREP 송신 타이머는 STA3으로부터 RREQ를 수신한 후에 만료된다. RREP 송신 타이머 만료마다, STA4는 도 22에 도시된 로직을 실행하여 RREP 프레임을 STA3으로 전송하는데, 그 이유는 STA1을 향한 다음 홉 STA가 STA4의 라우팅 테이블에서 STA3으로 이제 설정되어 있기 때문이다.

도 35에서의 시간 기준 P47인 RREP 전송의 결과로서, STA4의 이웃 리스트 및 라우팅 테이블이 업데이트된다.

도 23에서의 단계(516)로부터의 결과로서, STA4는 Dest == STA1인 라우팅 테이블 인스턴스를 유효성 확인한다. 도 23에서의 단계(524)의 결과로서, STA4는 STA3의 이웃 리스트 인스턴스들 내의 d.TxAntSector를 적절한 번호로 설정한다. 도 23에서의 단계(520)로부터의 결과로서, 결정된 채널 시간 정보는 STA3의 이웃 리스트 인스턴스 내의 g.AccessTime에 기입되고, STA2의 이웃 리스트 인스턴스 내의 g.AccessTime이 제거되는데, 그 이유는 STA2를 통한 루트가 더 이상 유효하지 않기 때문이다. 이 도면에서, RREP 개시의 결과로서 업데이트된 데이터는 파선으로 둘러싸여 도시되어 있다.

2.9.1.7. STA3@P48에서의 이웃 리스트 및 라우팅 테이블

도 42는 STA3@P48의 이웃 리스트 및 라우팅 테이블 상태에 대한 예시적인 실시예(930)를 예시하고 있다. STA1(932), STA2(934), STA4(936)에 대한 이웃 리스트들이, Dest = STA1(938) 및 Dest = STA4(940)에 대한 라우팅 테이블들과 함께, 보인다.

STA4에 의해 전송된 RREP는 STA3에 수신된다. STA3은 도 25에 도시된 로직을 실행한다. 그 결과, STA3은 루트들을 확인하고 RREP를 STA1로 전파한다.

도 35에서의 시간 기준 P48인 RREP 수신 및 RREP 전파의 결과로서, STA3의 이웃 리스트 및 라우팅 테이블이 업데이트된다.

도 26에서의 단계(578)로부터의 결과로서, STA3은 Dest == STA4인 라우팅 테이블 인스턴스를 생성하고 유효성 확인한다. 도 26에서의 단계(580)의 결과로서, STA3은 STA4의 이웃 리스트 인스턴스 내의 g.AccessTime을 유효성 확인한다. 도 26에서의 단계(582)의 결과로서, STA3은 STA4의 이웃 리스트 인스턴스 내의 d.TxAntSector를 적절한 번호로 설정한다.

도 23에서의 단계(516)로부터의 결과로서, STA3은 Dest == STA1인 라우팅 테이블 인스턴스를 유효성 확인한다. 도 23에서의 단계(524)의 결과로서, STA3은 STA1의 이웃 리스트 인스턴스들 내의 d.TxAntSector를 적절한 번호로 설정한다. 도 23에서의 단계(520)로부터의 결과로서, 결정된 채널 시간 정보는 STA1의 이웃 리스트 인스턴스 내의 g.AccessTime에 기입된다. 게다가, 다른 이웃 리스트 인스턴스들 내의 g.AccessTime은 확인 타임아웃마다 NULL로 복귀된다. 이 도면에서, RREP 수신 및 RREP 전파 프로세스의 결과로서 업데이트된 데이터는 파선으로 둘러싸여 도시되어 있다.

2.9.1.8. STA1@P49에서의 이웃 리스트 및 라우팅 테이블

도 43은 STA1@P49의 이웃 리스트 및 라우팅 테이블 상태에 대한 예시적인 실시예(950)를 예시하고 있다. STA2(952), STA3(954)에 대한 이웃 리스트들이, Dest = STA4에 대한 라우팅 테이블(960)과 함께, 보인다.

STA3이 전송한 RREP 프레임이 STA1에 수신된다. STA1이 RREP 프레임을 수신했을 때, STA1은 도 25에 도시된 로직을 실행한다. STA1은 RREP 프레임 내의 OrigSTA 필드가 그 자신의 어드레스와 매칭한다고 결정하고 이 절차를 마무리한다.

그 결과, 도 35에서의 시간 기준 P49에서, STA1의 이웃 리스트 및 라우팅 테이블이 업데이트된다.

도 26에서의 단계(578)로부터의 결과로서, STA1은 Dest == STA4인 라우팅 테이블 인스턴스를 업데이트한다. 이제 라우팅 테이블 인스턴스의 a.NextHop이 STA3으로 변경되고, 라우팅 테이블 인스턴스의 b.TxAntSec가 2로 변경된다. 도 26의 단계(580)의 결과로서, STA1은 STA3의 이웃 리스트 인스턴스 내의 g.AccessTime을 유효성 확인한다. 도 26의 단계(582)의 결과로서, STA1은 STA3의 이웃 리스트 인스턴스 내의 d.TxAntSector를 적절한 번호로 설정한다. 게다가, 다른 이웃 리스트 인스턴스들(STA2) 내의 g.AccessTime이 제거되는데 그 이유는 STA2를 통한 루트가 더 이상 유효하지 않기 때문이다. 이 도면에서, RREP 수신 프로세스의 결과로서 업데이트된 데이터는 파선으로 둘러싸여 도시되어 있다.

제시된 기술에 설명된 향상들은 다양한 무선 라디오 네트워킹 노드들(예컨대, STA들) 내에서 쉽게 구현될 수 있다. 이러한 무선 라디오 노드들 각각이 바람직하게는 적어도 하나의 컴퓨터 프로세서 디바이스(예컨대, CPU, 마이크로프로세서, 마이크로컨트롤러, 컴퓨터 가능 ASIC(computer enabled ASIC) 등) 및 명령어들을 저장하는 연관된 메모리(예컨대, RAM, DRAM, NVRAM, FLASH, 컴퓨터 판독가능 매체들 등)을 포함하도록 구현되고 그에 의해 메모리에 저장된 프로그래밍(명령어들)이 본 명세서에 설명된 다양한 프로세스 방법들의 단계들을 수행하기 위해 프로세서 상에서 실행된다는 점이 또한 인식되어야 한다. 제시된 기술은 메모리 및 컴퓨터 판독가능 매체들에 관해, 이들이 비일시적이고, 따라서 일시적 전자 신호를 구성하지 않는 한, 비제한적이다.

본 기술의 실시예들은 본 기술의 실시예들에 따른 방법들 및 시스템들의 플로차트 예시들, 및/또는, 컴퓨터 프로그램 제품들로서 또한 구현될 수 있는, 절차들, 알고리즘들, 단계들, 연산들, 수식들, 또는 다른 계산 표현들(computational depictions)을 참조하여 본 명세서에 설명될 수 있다. 이 점에서, 플로차트의 각각의 블록 또는 단계, 및 플로차트에서의 블록들(및/또는 단계들)의 조합은 물론, 임의의 절차, 알고리즘, 단계, 연산, 수식, 또는 계산 표현은, 하드웨어, 펌웨어, 및/또는 컴퓨터 판독가능 프로그램 코드로 구체화된 하나 이상의 컴퓨터 프로그램 명령어를 포함하는 소프트웨어와 같은, 다양한 수단에 의해 구현될 수 있다. 인식될 것인 바와 같이, 컴퓨터 프로세서(들) 또는 다른 프로그래밍가능 프로세싱 장치 상에서 실행되는 컴퓨터 프로그램 명령어들이 명시된 기능(들)을 구현하기 위한 수단을 생성하도록, 임의의 그러한 컴퓨터 프로그램 명령어들은, 제한 없이 범용 컴퓨터 또는 특수 목적 컴퓨터를 포함한, 하나 이상의 컴퓨터 프로세서, 또는 머신을 생성하는 다른 프로그래밍가능 프로세싱 장치에 의해 실행될 수 있다.

그에 따라, 본 명세서에 설명된 플로차트들의 블록들, 및 절차들, 알고리즘들, 단계들, 연산들, 수식들, 또는 계산 표현들은 명시된 기능(들)을 수행하기 위한 수단들의 조합들, 명시된 기능(들)을 수행하기 위한 단계들의 조합들, 및 명시된 기능(들)을 수행하기 위한, 컴퓨터 판독가능 프로그램 코드 로직 수단으로 구체화된 것과 같은, 컴퓨터 프로그램 명령어들을 지원한다. 본 명세서에 설명된 플로차트 예시들의 각각의 블록은 물론, 임의의 절차들, 알고리즘들, 단계들, 연산들, 수식들, 또는 계산 표현들 및 이들의 조합들이 명시된 기능(들) 또는 단계(들)를 수행하는 특수 목적 하드웨어 기반 컴퓨터 시스템들, 또는 특수 목적 하드웨어 및 컴퓨터 판독가능 프로그램 코드의 조합들에 의해 구현될 수 있다는 점이 또한 이해될 것이다.

게다가, 컴퓨터 판독가능 메모리 또는 메모리 디바이스들에 저장된 명령어들이 플로차트(들)의 블록(들)에 명시된 기능을 구현하는 명령어 수단을 포함하는 제조 물품을 생성하도록, 컴퓨터 프로세서 또는 다른 프로그래밍가능 프로세싱 장치에 특정의 방식으로 기능하도록 지시할 수 있는, 컴퓨터 판독가능 프로그램 코드로 구체화된 것과 같은, 이러한 컴퓨터 프로그램 명령어들이 하나 이상의 컴퓨터 판독가능 메모리 또는 메모리 디바이스에 또한 저장될 수 있다. 컴퓨터 프로세서 또는 다른 프로그래밍가능 프로세싱 장치 상에서 실행되는 명령어들이 플로차트(들)의 블록(들), 절차(들), 알고리즘(들), 단계(들), 연산(들), 수식(들), 또는 계산 표현(들)에 명시된 기능들을 구현하기 위한 단계들을 제공하도록 하는 컴퓨터 구현 프로세스를 생성하기 위해, 컴퓨터 프로그램 명령어들은 일련의 동작 단계들이 컴퓨터 프로세서 또는 다른 프로그래밍가능 프로세싱 장치 상에서 수행되게 하기 위해 컴퓨터 프로세서 또는 다른 프로그래밍가능 프로세싱 장치에 의해 또한 실행될 수 있다.

본 명세서에서 사용되는 바와 같은 용어들 "프로그래밍" 또는 "프로그램 실행가능"이 본 명세서에 설명된 바와 같은 하나 이상의 기능을 수행하기 위해 하나 이상의 컴퓨터 프로세서에 의해 실행될 수 있는 하나 이상의 명령어를 지칭한다는 것이 추가로 인식될 것이다. 명령어들은 소프트웨어로, 펌웨어로, 또는 소프트웨어와 펌웨어의 조합으로 구체화될 수 있다. 명령어들은 비일시적 매체들에 디바이스에 로컬로 저장될 수 있거나, 서버 상에와 같이, 원격으로 저장될 수 있거나, 또는 명령어들의 전부 또는 일부가 로컬적으로 그리고 원격적으로 저장될 수 있다. 원격적으로 저장된 명령어들은 사용자 개시에 의해, 또는 하나 이상의 인자에 기초하여 자동으로 디바이스에 다운로드(푸시)될 수 있다.

본 명세서에서 사용되는 바와 같이, 용어들 프로세서, 하드웨어 프로세서, 컴퓨터 프로세서, 중앙 프로세싱 유닛(CPU), 및 컴퓨터가 명령어들을 실행하고 입/출력 인터페이스들 및/또는 주변 디바이스들과 통신할 수 있는 디바이스를 나타내기 위해 동의어로 사용된다는 것과 용어들 프로세서, 하드웨어 프로세서, 컴퓨터 프로세서, CPU, 및 컴퓨터가 단일의 또는 다수의 디바이스들, 단일 코어 및 멀티코어 디바이스들, 및 이들의 변형들을 포함하도록 의도된다는 것이 추가로 인식될 것이다.

본 명세서에서의 설명으로부터, 본 개시내용이 하기의 실시예들의 리스트를 포함하지만 이들로 제한되지 않는 다수의 실시예들을 포괄한다는 것이 인식될 것이다.

1. 지향성 송수신(directional transmission/reception)을 사용하는 스테이션들(STA들) 사이의 무선 통신을 위한 장치로서, (a) mm-파 통신을 위해 구성된 무선 통신 스테이션(STA) - 상기 STA 및 장치의 근방의 STA 인스턴스들은 안테나 섹터 정보를 교환하기 위해 섹터 스위프 및 피드백 시그널링을 수행하도록 구성됨 -; (b) 범위(range) 내에 있는 다른 무선 라디오 통신 디바이스들로의 지향성 라디오 전송들을 생성하도록 구성된 상기 무선 통신 스테이션(STA)의 송신기; (c) 다른 무선 라디오 통신 디바이스들로부터의 라디오 전송들을 수신하도록 구성된 상기 무선 통신 스테이션(STA)의 수신기; (d) 자신과 다른 무선 라디오 통신 디바이스들 사이의 통신을 제어하기 위한, 상기 송신기 및 상기 수신기에 커플링된 컴퓨터 프로세서; (e) 컴퓨터 프로세서에 의해 실행가능한 명령어들을 저장하는 비일시적 컴퓨터 판독가능 메모리를 포함하고; (f) 상기 명령어들은, 컴퓨터 프로세서에 의해 실행될 때, 단계들을 수행하고, 이 단계들은: (f)(i) 각각의 안테나 섹터의 양자화된 채널 이득 정보, 또는 경로 손실 정보를 하나 이상의 이웃하는 스테이션과 교환하는 단계; (f)(ii) 이웃하는 스테이션들과의 통신으로부터의 수신된 양자화된 채널 이득 정보를 기록하는 단계; (f)(iii) 발신 스테이션으로부터 목적지 스테이션까지의 다중 홉 라우팅 경로를 확립할 때 이웃하는 스테이션들로의 루트 발견 메시지들을 생성하는 단계; 및 (f)(iv) 수신된 루트 발견 메시지들을 (f)(iv)(A) 루트 발견 메시지를 생성한 이웃하는 스테이션과의 링크 메트릭들을 결정하는 단계, (f)(iv)(B) 라우팅 경로에서의 잠재적인 다음 홉인 이웃하는 스테이션에 대한 송신 안테나 섹터를 결정할 때 간섭 영향을 고려하는 단계; (f)(iv)(C) 스테이션이 목적지 스테이션이 아니면 루트 발견 메시지를 이웃 스테이션으로 전파하는 단계에 의해 프로세싱하는 단계를 포함하는, 장치.

2. 임의의 선행하는 실시예에 있어서, 사용하기 위한 다수의 안테나 섹터들을 체크하고 링크 품질 및/또는 이웃하는 스테이션들(STA들)에 대한 간섭 영향에 기초하여 섹터를 선택하는 것에 응답하여 간섭 영향이 고려되는, 장치.

3. 임의의 선행하는 실시예에 있어서, 채널 시간 이용률 및 이웃하는 스테이션들에서의 진행 중인 트래픽에 대한 영향은 다중 홉 라우팅 경로를 확립할 때 간섭 영향을 결정하는 데 이용되는, 장치.

4. 임의의 선행하는 실시예에 있어서, 상기 무선 통신 스테이션(STA)은 루트 발견이 이루어지기 전에 양자화된 채널 이득 정보 및 트래픽 활동 정보를 이웃하는 스테이션들과 상호 교환하는, 장치.

5. 임의의 선행하는 실시예에 있어서, 발신 스테이션으로부터 목적지 스테이션까지의 다중 홉 라우팅 경로를 확립할 때 채널 시간들이 할당되는, 장치.

6. 임의의 선행하는 실시예에 있어서, 할당된 채널 시간 정보를 루트 발견 메시지 내에서 전송하는 것에 응답하여 채널 시간들이 할당되는, 장치.

7. 임의의 선행하는 실시예에 있어서, 라우팅 경로를 결정할 때 루트 발견 메시지들로부터 순방향 링크 및 역방향 링크 메트릭들을 누적하여 이용하는 것을 추가로 포함하는, 장치.

8. 임의의 선행하는 실시예에 있어서, 상기 발견 메시지들은 루트 발견 프로세스 동안 수신 신호 품질 정보를 전송하는 데 이용되는, 장치.

9. 지향성 송수신을 사용하는 스테이션들(STA들) 사이의 무선 통신을 위한 장치로서, (a) mm-파 통신을 위해 구성된 무선 통신 스테이션(STA) - 상기 STA 및 장치의 근방의 STA 인스턴스들은 안테나 섹터 정보를 교환하기 위해 섹터 스위프 및 피드백 시그널링을 수행하도록 구성됨 -; (b) 범위(range) 내에 있는 다른 무선 라디오 통신 디바이스들로의 지향성 라디오 전송들을 생성하도록 구성된 상기 무선 통신 스테이션(STA)의 송신기; (c) 다른 무선 라디오 통신 디바이스들로부터의 라디오 전송들을 수신하도록 구성된 상기 무선 통신 스테이션(STA)의 수신기; (d) 자신과 다른 무선 라디오 통신 디바이스들 사이의 통신을 제어하기 위한 상기 송신기 및 상기 수신기에 커플링된 컴퓨터 프로세서; (e) 컴퓨터 프로세서에 의해 실행가능한 명령어들을 저장하는 비일시적 컴퓨터 판독가능 메모리; (f) 상기 명령어들은, 컴퓨터 프로세서에 의해 실행될 때, 단계들을 수행하고, 이 단계들은: (f)(i) 각각의 안테나 섹터의 양자화된 채널 이득 정보, 또는 경로 손실 정보를 하나 이상의 이웃하는 스테이션과 교환하는 단계; (f)(ii) 이웃하는 스테이션들과의 통신으로부터의 수신된 양자화된 채널 이득 정보를 기록하는 단계; (f)(iii) 발신 스테이션으로부터 목적지 스테이션까지의 다중 홉 라우팅 경로를 확립할 때 이웃하는 스테이션들로의 루트 발견 메시지들을 생성하는 단계; 및 (f)(iv) 수신된 루트 발견 메시지들을 (f)(iv)(A) 루트 발견 메시지를 생성한 이웃하는 스테이션과의 링크 메트릭들을 결정하는 단계, (f)(iv)(B) 라우팅 경로에서의 잠재적인 다음 홉인 이웃하는 스테이션에 대한 송신 안테나 섹터를 결정할 때 간섭 영향을 고려하는 단계; (f)(iv)(C) 스테이션이 목적지 스테이션이 아니면 루트 발견 메시지를 이웃 스테이션으로 전파하는 단계에 의해 프로세싱하는 단계를 포함하고; (f)(v) 사용하기 위한 다수의 안테나 섹터들을 체크하고 링크 품질 및/또는 이웃하는 스테이션들(STA들)에 대한 간섭 영향에 기초하여 섹터를 선택하는 것에 응답하여 간섭 영향이 고려되며, (f)(vi) 채널 시간 이용률 및 이웃하는 스테이션들에서의 진행 중인 트래픽에 대한 영향은 다중 홉 라우팅 경로를 확립할 때 간섭 영향을 결정하는 데 이용되는, 장치.

10. 임의의 선행하는 실시예에 있어서, 상기 무선 통신 스테이션(STA)은 루트 발견이 이루어지기 전에 양자화된 채널 이득 정보 및 트래픽 활동 정보를 이웃하는 스테이션들과 상호 교환하는, 장치.

11. 임의의 선행하는 실시예에 있어서, 발신 스테이션으로부터 목적지 스테이션까지의 다중 홉 라우팅 경로를 확립할 때 채널 시간들이 할당되는, 장치.

12. 임의의 선행하는 실시예에 있어서, 할당된 채널 시간 정보를 루트 발견 메시지 내에서 전송하는 것에 응답하여 채널 시간들이 할당되는, 장치.

13. 임의의 선행하는 실시예에 있어서, 라우팅 경로를 결정할 때 루트 발견 메시지들로부터 순방향 링크 및 역방향 링크 메트릭들을 누적하여 이용하는 것을 추가로 포함하는, 장치.

14. 임의의 선행하는 실시예에 있어서, 상기 발견 메시지들은 루트 발견 프로세스 동안 수신 신호 품질 정보를 전송하는 데 이용되는, 장치.

15. 지향성 송수신을 사용하는 스테이션들(STA들) 사이의 무선 통신을 수행하기 위한 방법으로서, (a) 범위(range) 내에 있는 다른 무선 라디오 통신 디바이스들로의 지향성 라디오 전송들을 생성하도록, 그리고 다른 무선 라디오 통신 디바이스들로부터의 라디오 전송들을 수신하도록 구성된 STA들 사이에서 안테나 섹터 정보를 교환하기 위해, 각각의 안테나 섹터의 양자화된 채널 이득 정보 또는 경로 손실 정보를 mm-파 통신 및 섹터 스위프 및 피드백 시그널링을 위해 구성된 하나 이상의 이웃하는 스테이션(STA)과 교환하는 단계; (b) 이웃하는 스테이션들과의 통신으로부터의 수신된 양자화된 채널 이득 정보를 기록하는 단계; (c) 발신 스테이션으로부터 목적지 스테이션까지의 다중 홉 라우팅 경로를 확립할 때 이웃하는 스테이션들로의 루트 발견 메시지들을 생성하는 단계; 및 (d) 수신된 루트 발견 메시지들을 (d)(A) 루트 발견 메시지를 생성한 이웃하는 스테이션과의 링크 메트릭들을 결정하는 단계, (d)(B) 라우팅 경로에서의 잠재적인 다음 홉인 이웃하는 스테이션에 대한 송신 안테나 섹터를 결정할 때 간섭 영향을 고려하는 단계; (d)(C) 스테이션이 목적지 스테이션이 아니면 루트 발견 메시지를 이웃 스테이션으로 전파하는 단계에 의해 프로세싱하는 단계를 포함하는, 방법.

16. 임의의 선행하는 실시예에 있어서, 사용하기 위한 다수의 안테나 섹터들을 체크하고 링크 품질 및/또는 이웃하는 스테이션들(STA들)에 대한 간섭 영향에 기초하여 섹터를 선택하는 것에 응답하여 간섭 영향이 고려되는, 방법.

17. 임의의 선행하는 실시예에 있어서, 채널 시간 이용률 및 이웃하는 스테이션들에서의 진행 중인 트래픽에 대한 영향은 다중 홉 라우팅 경로를 확립할 때 간섭 영향을 결정하는 데 이용되는, 방법.

18. 임의의 선행하는 실시예에 있어서, 발신 스테이션으로부터 목적지 스테이션까지의 다중 홉 라우팅 경로를 확립할 때 채널 시간들이 할당되는, 방법.

19. 임의의 선행하는 실시예에 있어서, 라우팅 경로를 결정할 때 루트 발견 메시지들로부터 순방향 링크 및 역방향 링크 메트릭들을 누적하여 이용하는 단계를 추가로 포함하는, 방법.

20. 임의의 선행하는 실시예에 있어서, 상기 발견 메시지들은 루트 발견 프로세스 동안 수신 신호 품질 정보를 전송하는 데 이용되는, 방법.

비록 본 명세서에서의 설명이 많은 세부사항들을 포함하지만, 이들은 본 개시내용의 범위를 제한하는 것으로 해석되어서는 안되고 본 바람직한 실시예들 중 일부의 예시들을 제공할 뿐인 것으로 해석되어야 한다. 따라서, 본 개시내용의 범위가 본 기술분야의 통상의 기술자에게 명백해질 수 있는 다른 실시예들을 완전히 포괄한다는 것이 인식될 것이다.

청구항들에서, 단수의 요소에 대한 참조는 명시적으로 그렇게 진술되지 않는 한 "단 하나(one and only one)"를 의미하는 것으로 의도되지 않고, 오히려 "하나 이상"을 의미하는 것으로 의도된다. 본 기술분야의 통상의 기술자에게 알려져 있는 개시된 실시예들의 요소들의 모든 구조적, 화학적, 및 기능적 균등물들이 본 명세서에 참조로 명시적으로 포함되고 본 청구항들에 의해 포괄되는 것으로 의도된다. 게다가, 본 개시내용에서의 어떠한 요소, 컴포넌트, 또는 방법 단계도, 그 요소, 컴포넌트, 또는 방법 단계가 청구항들에서 명시적으로 열거되는지에 관계없이, 공중에 제공되는(dedicated to the public) 것으로 의도되지 않는다. 본 명세서에서의 어떠한 청구항 요소도, 그 요소가 문구 "~을 위한 수단(means for)"을 사용하여 명시적으로 열거되지 않는 한, "수단 + 기능(means plus function)" 요소로서 해석되어서는 안된다. 본 명세서에서의 어떠한 청구항 요소도, 그 요소가 문구 "~을 위한 단계(step for)"를 사용하여 명시적으로 열거되지 않는 한, "단계 + 기능(step plus function)" 요소로서 해석되어서는 안된다.

Claims (20)

1. 지향성 송수신(directional transmission/reception)을 사용하는 스테이션들(STA들) 사이의 무선 통신을 위한 장치로서,
   (a) mm-파 통신을 위해 구성된 무선 통신 스테이션(STA) - 상기 STA 및 상기 장치의 근방의 STA 인스턴스들은 안테나 섹터 정보를 교환하기 위해 섹터 스위프 및 피드백 시그널링을 수행하도록 구성됨 -;
   (b) 범위(range) 내에 있는 다른 무선 라디오 통신 디바이스들로의 지향성 라디오 전송들을 생성하도록 구성된 상기 무선 통신 스테이션(STA)의 송신기;
   (c) 다른 무선 라디오 통신 디바이스들로부터의 라디오 전송들을 수신하도록 구성된 상기 무선 통신 스테이션(STA)의 수신기;
   (d) 자신과 다른 무선 라디오 통신 디바이스들 사이의 통신을 제어하기 위한, 상기 송신기 및 상기 수신기에 커플링된 컴퓨터 프로세서;
   (e) 상기 컴퓨터 프로세서에 의해 실행가능한 명령어들을 저장하는 비일시적 컴퓨터 판독가능 메모리
   를 포함하고;
   (f) 상기 명령어들은, 상기 컴퓨터 프로세서에 의해 실행될 때, 단계들을 수행하고, 이 단계들은:
   (i) 각각의 안테나 섹터의 양자화된 채널 이득 정보, 또는 경로 손실 정보를 하나 이상의 이웃하는 스테이션과 교환하는 단계;
   (ii) 이웃하는 스테이션들과의 통신으로부터의 수신된 양자화된 채널 이득 정보를 기록하는 단계;
   (iii) 발신 스테이션으로부터 목적지 스테이션까지의 다중 홉 라우팅 경로를 확립할 때 이웃하는 스테이션들로의 루트 발견 메시지들을 생성하는 단계; 및
   (iv) 수신된 루트 발견 메시지들을 (A) 상기 루트 발견 메시지를 생성한 이웃하는 스테이션과의 링크 메트릭들을 결정하는 단계, (B) 상기 라우팅 경로에서의 잠재적인 다음 홉인 이웃하는 스테이션에 대한 송신 안테나 섹터를 결정할 때 간섭 영향을 고려하는 단계; (C) 상기 스테이션이 상기 목적지 스테이션이 아니면 상기 루트 발견 메시지를 이웃 스테이션으로 전파하는 단계에 의해 프로세싱하는 단계
   를 포함하는 장치.
2. 제1항에 있어서, 사용하기 위한 다수의 안테나 섹터들을 체크하고 링크 품질 및/또는 이웃하는 스테이션들(STA들)에 대한 간섭 영향에 기초하여 섹터를 선택하는 것에 응답하여 간섭 영향이 고려되는 장치.
3. 제1항에 있어서, 채널 시간 이용률 및 이웃하는 스테이션들에서의 진행 중인 트래픽에 대한 영향은 상기 다중 홉 라우팅 경로를 확립할 때 간섭 영향을 결정하는 데 이용되는 장치.
4. 제3항에 있어서, 상기 무선 통신 스테이션(STA)은 루트 발견이 이루어지기 전에 양자화된 채널 이득 정보 및 트래픽 활동 정보를 이웃하는 스테이션들과 상호 교환하는 장치.
5. 제1항에 있어서, 발신 스테이션으로부터 목적지 스테이션까지의 상기 다중 홉 라우팅 경로를 확립할 때 채널 시간들이 할당되는 장치.
6. 제5항에 있어서, 할당된 채널 시간 정보를 상기 루트 발견 메시지 내에서 전송하는 것에 응답하여 채널 시간들이 할당되는 장치.
7. 제1항에 있어서, 상기 라우팅 경로를 결정할 때 루트 발견 메시지들로부터 순방향 링크 및 역방향 링크 메트릭들을 누적하여 이용하는 것을 추가로 포함하는 장치.
8. 제7항에 있어서, 상기 발견 메시지들은 상기 루트 발견 프로세스 동안 수신 신호 품질 정보를 전송하는 데 이용되는 장치.
9. 지향성 송수신을 사용하는 스테이션들(STA들) 사이의 무선 통신을 위한 장치로서,
   (a) mm-파 통신을 위해 구성된 무선 통신 스테이션(STA) - 상기 STA 및 상기 장치의 근방의 STA 인스턴스들은 안테나 섹터 정보를 교환하기 위해 섹터 스위프 및 피드백 시그널링을 수행하도록 구성됨 -;
   (b) 범위 내에 있는 다른 무선 라디오 통신 디바이스들로의 지향성 라디오 전송들을 생성하도록 구성된 상기 무선 통신 스테이션(STA)의 송신기;
   (c) 다른 무선 라디오 통신 디바이스들로부터의 라디오 전송들을 수신하도록 구성된 상기 무선 통신 스테이션(STA)의 수신기;
   (d) 자신과 다른 무선 라디오 통신 디바이스들 사이의 통신을 제어하기 위한, 상기 송신기 및 상기 수신기에 커플링된 컴퓨터 프로세서;
   (e) 상기 컴퓨터 프로세서에 의해 실행가능한 명령어들을 저장하는 비일시적 컴퓨터 판독가능 메모리
   를 포함하고;
   (f) 상기 명령어들은, 상기 컴퓨터 프로세서에 의해 실행될 때, 단계들을 수행하고, 이 단계들은:
   (i) 각각의 안테나 섹터의 양자화된 채널 이득 정보, 또는 경로 손실 정보를 하나 이상의 이웃하는 스테이션과 교환하는 단계;
   (ii) 이웃하는 스테이션들과의 통신으로부터의 수신된 양자화된 채널 이득 정보를 기록하는 단계;
   (iii) 발신 스테이션으로부터 목적지 스테이션까지의 다중 홉 라우팅 경로를 확립할 때 이웃하는 스테이션들로의 루트 발견 메시지들을 생성하는 단계; 및
   (iv) 수신된 루트 발견 메시지들을 (A) 상기 루트 발견 메시지를 생성한 이웃하는 스테이션과의 링크 메트릭들을 결정하는 단계, (B) 상기 라우팅 경로에서의 잠재적인 다음 홉인 이웃하는 스테이션에 대한 송신 안테나 섹터를 결정할 때 간섭 영향을 고려하는 단계; (C) 상기 스테이션이 상기 목적지 스테이션이 아니면 상기 루트 발견 메시지를 이웃 스테이션으로 전파하는 단계에 의해 프로세싱하는 단계
   를 포함하고,
   (v) 사용하기 위한 다수의 안테나 섹터들을 체크하고 링크 품질 및/또는 이웃하는 스테이션들(STA들)에 대한 간섭 영향에 기초하여 섹터를 선택하는 것에 응답하여 간섭 영향이 고려되며,
   (vi) 채널 시간 이용률 및 이웃하는 스테이션들에서의 진행 중인 트래픽에 대한 영향은 상기 다중 홉 라우팅 경로를 확립할 때 간섭 영향을 결정하는 데 이용되는 장치.
10. 제9항에 있어서, 상기 무선 통신 스테이션(STA)은 루트 발견이 이루어지기 전에 양자화된 채널 이득 정보 및 트래픽 활동 정보를 이웃하는 스테이션들과 상호 교환하는 장치.
11. 제9항에 있어서, 발신 스테이션으로부터 목적지 스테이션까지의 상기 다중 홉 라우팅 경로를 확립할 때 채널 시간들이 할당되는 장치.
12. 제11항에 있어서, 할당된 채널 시간 정보를 상기 루트 발견 메시지 내에서 전송하는 것에 응답하여 채널 시간들이 할당되는 장치.
13. 제9항에 있어서, 상기 라우팅 경로를 결정할 때 루트 발견 메시지들로부터 순방향 링크 및 역방향 링크 메트릭들을 누적하여 이용하는 것을 추가로 포함하는 장치.
14. 제13항에 있어서, 상기 발견 메시지들은 상기 루트 발견 프로세스 동안 수신 신호 품질 정보를 전송하는 데 이용되는 장치.
15. 지향성 송수신을 사용하는 스테이션들(STA들) 사이의 무선 통신을 수행하기 위한 방법으로서,
    (a) 범위 내에 있는 다른 무선 라디오 통신 디바이스들로의 지향성 라디오 전송들을 생성하도록, 그리고 다른 무선 라디오 통신 디바이스들로부터의 라디오 전송들을 수신하도록 구성된 STA들 사이에서 안테나 섹터 정보를 교환하기 위해, 각각의 안테나 섹터의 양자화된 채널 이득 정보 또는 경로 손실 정보를 mm-파 통신 및 섹터 스위프 및 피드백 시그널링을 위해 구성된 하나 이상의 이웃하는 스테이션(STA)과 교환하는 단계;
    (b) 이웃하는 스테이션들과의 통신으로부터의 수신된 양자화된 채널 이득 정보를 기록하는 단계;
    (c) 발신 스테이션으로부터 목적지 스테이션까지의 다중 홉 라우팅 경로를 확립할 때 이웃하는 스테이션들로의 루트 발견 메시지들을 생성하는 단계; 및
    (d) 수신된 루트 발견 메시지들을 (A) 상기 루트 발견 메시지를 생성한 이웃하는 스테이션과의 링크 메트릭들을 결정하는 단계, (B) 상기 라우팅 경로에서의 잠재적인 다음 홉인 이웃하는 스테이션에 대한 송신 안테나 섹터를 결정할 때 간섭 영향을 고려하는 단계; (C) 상기 스테이션이 상기 목적지 스테이션이 아니면 상기 루트 발견 메시지를 이웃 스테이션으로 전파하는 단계에 의해 프로세싱하는 단계
    를 포함하는 방법.
16. 제15항에 있어서, 사용하기 위한 다수의 안테나 섹터들을 체크하고 링크 품질 및/또는 이웃하는 스테이션들(STA들)에 대한 간섭 영향에 기초하여 섹터를 선택하는 것에 응답하여 간섭 영향이 고려되는 방법.
17. 제15항에 있어서, 채널 시간 이용률 및 이웃하는 스테이션들에서의 진행 중인 트래픽에 대한 영향은 상기 다중 홉 라우팅 경로를 확립할 때 간섭 영향을 결정하는 데 이용되는 방법.
18. 제15항에 있어서, 발신 스테이션으로부터 목적지 스테이션까지의 상기 다중 홉 라우팅 경로를 확립할 때 채널 시간들이 할당되는 방법.
19. 제15항에 있어서, 상기 라우팅 경로를 결정할 때 루트 발견 메시지들로부터 순방향 링크 및 역방향 링크 메트릭들을 누적하여 이용하는 단계를 추가로 포함하는 방법.
20. 제19항에 있어서, 상기 발견 메시지들은 상기 루트 발견 프로세스 동안 수신 신호 품질 정보를 전송하는 데 이용되는 방법.

Images