KR20130098276A - 트리플 플레이 프로토콜 - 네트워크 코딩된 세 노드의 양방향 협업으로 전송하기 위한 매체 접근 제어 계층 프로토콜 - Google Patents

Abstract

송신 요구 신호를 전송하는 단계, 송신 클리어 신호 및 역방향 전송 요구 신호가 수신되었는지를 판단하는 단계, 상기 제1 판단에 응답하여 제1 데이터, 제1 블록 확인응답 요구 신호 및 역방향 승인 신호를 전송하는 단계, 제1 블록 확인응답 신호, 제2 데이터 및 제2 블록 확인응답 요구 신호가 수신되었는지를 판단하는 단계, 상기 제2 판단에 응답하여 제2 블록 확인응답 신호를 전송하는 단계, 제3 블록 확인응답 신호가 수신되었는지를 판단하는 단계 및 상기 제3 판단에 응답하여 제4 블록 확인응답 신호를 전송하는 단계를 포함하는 방법 및 장치가 기술된다. 또한, 채널에 경청하는 단계, 상기 경청 단계에 응답하여 채널 상태를 추정하는 단계, 신호가 수신되었는지를 판단하는 단계, 채널 상태가 중계 노드로서 동작하기에 적합한지를 판단하는 단계, 상기 제1 및 제2 판단에 응답하여 중계 노드의 송신 클리어 신호를 멀티캐스팅하는 단계 및 상기 제1 및 제2 판단에 응답하여 블록 확인응답 신호 및 데이터를 멀티캐스팅하는 단계를 포함하는 방법 및 장치가 기술된다.

Description

트리플 플레이 프로토콜 - 네트워크 코딩된 세 노드의 양방향 협업으로 전송하기 위한 매체 접근 제어 계층 프로토콜{TRIPLE-PLAY PROTOCOL - A MEDIA ACCESS CONTROL LAYER PROTOCOL FOR TRANSMISSIONS IN NETWORK-CODED THREE NODE BIDIRECTIONAL COOPERATION}

본 발명은 드래프트 IEEE 802.11n 표준의 양방향 전송(통신)에 도움이 되는 세 노드의 협업 방식(three node cooperation scheme)에 관한 것이다.

멀티캐스트(multicast) 및 브로드캐스트(broadcast) 응용에서, 데이터는 서버로부터 유선 및/또는 무선 네트워크를 통해 다수의 수신기로 전송된다. 본 명세서에서 사용된 바와 같은 멀티캐스트 시스템은 서버가 동일한 데이터를 다수의 수신기에 동시에 전송하는 시스템으로, 여기서 이들 수신기는 모든 수신기들에 이르기까지 모든 수신기들의 부분집합(subset)을 이룬다. 브로드캐스트 시스템은 서버가 동일한 데이터를 모든 수신기에 동시에 전송하는 시스템이다. 즉, 멀티캐스트 시스템은 정의에 의하면 브로드캐스트 시스템을 포함할 수 있다.

액세스 포인트(access point: AP)가 하나이고 노드가 여러 개인 멀티캐스트(다운링크) 및 멀티 액세스(업링크) 채널을 생각해 보자. IEEE 802.11n 드래프트 표준에서, 전송 기회(transmission opportunity: TXOP) 내에서 양방향 트래픽 흐름을 고속으로 스케줄링(scheduling)하는 역방향(RD) 프로토콜이 도입된다. 이러한 역방향 프로토콜은 TXOP를 얻은 노드가 역시 TXOP의 제어 하에 있는 또 다른 노드로의 역방향 전송을 승인하는 것을 허용한다(가능하게 한다). 만일 그 노드 간의 채널 상태가 부적절하면(나쁘면), 두 노드 간의 전송은 어려움을 겪는다. 그러한 어려움으로 인해 데이터 속도 및/또는 처리율(throughput)이 저하될 수 있다.

IEEE 802.11n 드래프트 표준에서, 도 1에서와 같은 역방향(RD) 프로토콜이 제안되었다. IEEE 802.11n 드래프트 표준의 역방향 프로토콜은 단지 두 노드 간의 양방향 전송만을 스케줄링한다. IEEE 802.11 WLAN 표준에서 기존에는 세 노드의 양방향 전송을 위한 스케줄링 프로토콜이 존재하지 않는다.

제3 노드가 두 노드의 중계(relay) 노드로서 역할을 하는 것이 유리할 것이다. 그러나, 그러한 제3 (중계) 노드를 사용하면 두 노드 간의 통신(전송)이 복잡해진다.

본 명세서에서 사용된 바와 같은 노드는 (다음으로 제한되지 않지만) 스테이션(STA), 모바일 장치, 모바일 단말기, 이중 모드(dual mode) 스마트폰, 컴퓨터, 랩탑 컴퓨터 또는 IEEE 802.11n 드래프트 표준 하에서 동작할 수 있는 어떤 다른 등가의 장치를 포함한다.

액세스 포인트(AP)가 하나이고 노드가 여러 개인 멀티캐스트(다운링크) 및 멀티 액세스(업링크) 채널을 생각해 보자. IEEE 802.11n 드래프트 표준에서, 전송 기회(TXOP) 내에서 양방향 트래픽 흐름을 고속으로 스케줄링하는 역방향(RD) 프로토콜이 도입된다. 이러한 역방향 프로토콜은 TXOP를 얻은 노드가 역시 TXOP의 제어 하에 있는 또 다른 노드로의 역방향 전송을 승인하는 것을 허용한다(가능하게 한다). 이러한 두 노드 간의 전송이 반 이중(half-duplex) 중계 노드(RN)인 제3 노드를 통한 협업을 수반하면, 상황은 더 복잡해지고, 시스템 처리율을 더 높이기 위해 무선 네트워크 코딩이 이용될 수 있다. 본 발명은 MAC 계층에서 네트워크 코딩된 세 노드의 양방향 협업을 이용하여 전송을 스케줄링하는 트리플 플레이 프로토콜을 기술한다.

송신 요구 신호를 전송하는 단계, 송신 클리어 신호 및 역방향 전송 요구 신호가 수신되었는지를 판단하는 단계, 상기 제1 판단에 응답하여 제1 데이터, 제1 블록 확인응답 요구 신호 및 역방향 승인 신호를 전송하는 단계, 제1 블록 확인응답 신호, 제2 데이터 및 제2 블록 확인응답 요구 신호가 수신되었는지를 판단하는 단계, 상기 제2 판단에 응답하여 제2 블록 확인응답 신호를 전송하는 단계, 제3 블록 확인응답 신호가 수신되었는지를 판단하는 단계 및 상기 제3 판단에 응답하여 제4 블록 확인응답 신호를 전송하는 단계를 포함하는 방법 및 장치가 기술된다. 또한, 송신 요구 신호가 수신되었는지를 판단하는 단계, 상기 제1 판단에 응답하여 송신 클리어 신호, 역방향 전송 요구 신호를 전송하는 단계, 제1 데이터, 제1 블록 확인응답 요구 신호 및 역방향 전송 승인 신호가 수신되었는지를 판단하는 단계, 상기 제2 판단에 응답하여 제1 블록 확인응답 신호, 제2 데이터 및 제2 블록 확인응답 요구를 전송하는 단계, 제2 블록 확인응답 신호 및 제3 데이터가 수신되었는지를 판단하는 단계 및 상기 제3 판단에 응답하여 제3 블록 확인응답 신호를 전송하는 단계를 포함하는 방법 및 장치가 기술된다. 또한, 채널에 경청하는 단계, 상기 경청 단계에 응답하여 채널 상태를 추정하는 단계, 신호가 수신되었는지를 판단하는 단계, 채널 상태가 중계 노드로서 역할을 하기에 적합한지를 판단하는 단계, 상기 제1 및 제2 판단에 응답하여 중계 노드의 송신 클리어 신호를 멀티캐스팅하는 단계 및 상기 제1 및 제2 판단에 응답하여 블록 확인응답 신호 및 데이터를 멀티캐스팅하는 단계를 포함하는 방법 및 장치가 기술된다.

그러한 MAC 계층의 트리플 플레이 프로토콜은 차세대 IEEE 802.11 초고처리율(VHT) 표준에 필수적일 수 있다. 본 발명의 트리플 플레이 프로토콜의 장점은 미래 표준의 변경이 최소화되고 역호환성(backward compatible)이 용이하도록 그 프로토콜이 IEEE 802.11n 드래프트 표준에서 제안된 역방향(RD) 프로토콜에 기반하여 설계된다는 점이다.

본 발명은 첨부의 도면과 함께 읽어볼 때 다음의 상세한 설명으로부터 가장 잘 이해된다. 도면은 아래에서 간략히 기술된 다음과 같은 도면을 포함한다.
도 1은 역방향 전송을 요구하는 IEEE 802.11n 표준에 따라서 동작하는 두 노드의 동작을 예시하는 도면이다.
도 2는 RN과 초기 핸드쉐이킹(handshaking)을 하지 않는 본 발명의 트리플 플레이 프로토콜의 제1 실시예를 예시하는 도면이다.
도 3은 RN과 초기 핸드쉐이킹을 하는 본 발명의 트리플 플레이 프로토콜의 제2 실시예를 예시하는 도면이다.
도 4는 본 발명의 트리플 플레이 프로토콜의 제1 실시예의 원리에 따른 Node₁의 동작 흐름도이다.
도 5는 본 발명의 트리플 플레이 프로토콜의 제1 실시예의 원리에 따른 Node₂의 동작 흐름도이다.
도 6은 본 발명의 트리플 플레이 프로토콜의 제1 실시예의 원리에 따른 RN의 동작 흐름도이다.
도 7은 본 발명의 트리플 플레이 프로토콜의 제2 실시예의 원리에 따른 Node₁의 동작 흐름도이다.
도 8은 본 발명의 트리플 플레이 프로토콜의 제2 실시예의 원리에 따른 Node₂의 동작 흐름도이다.
도 9는 본 발명의 트리플 플레이 프로토콜의 제2 실시예의 원리에 따른 RN의 동작 흐름도이다.
도 10은 본 발명의 원리에 따른 예시적인 장치의 블록도이다.

본 발명의 세 노드의 양방향 협업 프로토콜에서, 두 노드 Node₁ 및 Node₂는 각각 이들 간에 양방향 트래픽 흐름이 존재한다는 점에서 소스 및 목적지 노드이며, 제3 노드 RN은 양방향 전송에서 도움이 되는 중계 노드이다. 어떠한 노드라도 소스 노드가 될 수 있고 어떠한 노드라도 목적지 노드가 될 수 있으며 어떠한 노드라도 RN이 될 수 있다는 점을 주목하여야 한다. 실제로, 어떤 한 노드가 동시에 소스 노드, 목적지 노드 및 RN으로서 동작할 수 있다. 일반성을 잃지 않고, Node₁이 TXOP를 얻고, Node₁이 Node₂와 양방향 통신(트래픽 흐름, 전송)을 시작한다고 가정하자. 그러나, 두 노드 간의 직접 링크의 채널 상태가 나빠지면, 두 노드에서의 디코딩 프로세스에 도움이 되는 데이터를 두 노드로 전송하는 협업 중계 노드(RN)가 사용된다. 노드에서는 데이터 전송(통신)을 수신한 후에 디코딩이 실시된다. 디코딩은 데이터의 신뢰성을 높이기 위해 사용된 인코딩을 역방향으로 처리하는데 사용된다. 예를 들어, 리드 솔로몬(Reed-Solomon) 및 비터비(Viterbi) 인코딩 또는 심지어 간단한 패리티 검사(parity checking) 조차도 전송된 데이터의 신뢰성을 높이는데 사용된다. 데이터는, 다음으로 제한되지 않지만, 오디오, 비디오, 멀티미디어, 콘텐츠 또는 어떤 다른 형태의 데이터를 포함할 수 있다. 데이터는 패킷 및/또는 프레임으로 포맷화하는데 사용되지만 이러한 용어는 본 명세서에서 임의의 포맷팅 방식을 나타내는데 상호 교환적으로 사용된다.

무선 네트워크 코딩은 협업을 통한 데이터 전송(통신)의 신뢰성 증가와 직접 링크를 통한 단방향 전송의 소정의 데이터 속도 유지 간의 상충 관계(trade-off)에 해당한다. 중계 노드(RN)는 (서로 다른 타임 슬롯에서, 또는 동시에) Node₁ 및 Node₂ 둘 다로부터 데이터를 수신하고 두 데이터 세트를 혼합(조합)하여 새로운 데이터 세트를 생성하며, 새로운 혼합된 데이터를 두 노드로 브로드캐스트(멀티캐스트)한다. 각각의 노드(소스 및 목적지)는 다른 노드(소스 및 목적지)로부터의 원하는 데이터의 전송과, RN으로부터의 전송을 모두 수신한다. 각 노드는 이어서 그 노드가 전송한(송신한) 데이터에 관한 지식에 기초하여 그 노드가 원하는 데이터를 공동으로 디코딩할 수 있다.

RN에서 혼합된 데이터는 두 세트의 수신 데이터의 함수이다. RN이 데이터를 혼합하는 방법은 네트워크 코딩에 기반한다. 본 기술 분야에서 공지된 몇 가지 네트워크 코딩 예들뿐만 아니라 가능한 데이터 혼합 방법이 아래에 제시된다. 아래의 예들은 포괄적인 목록이 아님을 알아야 한다.

(1) 데이터는 디코딩 후 전송(decode-and-forward) 기반 네트워크 코딩된 것일 수 있다, 즉, 두 시퀀스의 디코딩된 정보 비트들의 이진 가산(binary addition)일 수 있다.

(2) 데이터는 소프트 디코딩 후 전송 기반 네트워크 코딩된 것일 수 있다, 즉, 두 데이터의 소프트 디코딩된 비트들의 로그 우도비(log-likelihood ratios: LLR)의 조합일 수 있다.

(3) 데이터는 증폭 후 전송(amplify-and-forward) 또는 압축 후 전송(compress-and-forward) 기반 네트워크 코딩된 것일 수 있다, 즉, 두 가중 수신 신호(weighted received siganls)의 선형 조합일 수 있다. 데이터는 중계 노드(RN)가 개개의 신호를 개별적으로 수신하는지, 두 노드로부터 혼합된 신호를 수신하는지에 따라, 디지털 네트워크 코딩 및 아날로그 네트워크 코딩으로 더 분류될 수 있다.

(4) 데이터는 물리 계층 네트워크 코딩된 것일 수 있다, 즉, 물리 계층 도메인에서 연산한 것일 수 있지만, 이진 도메인에서 이진 가산에 등가적이다.

(5) 데이터는 잡음 제거 후 전송(denoise-and-forward) 기반 네트워크 코딩된 것일 수 있다, 즉, 다른 지정된 코드북(codebook)을 이용하여 가능한 전송된 데이터를 나타낸 것일 수 있다.

본 발명의 트리플 플레이 프로토콜(Triple-play protocol)은 단일 안테나 및/또는 다중 안테나 기술과 결합될 수 있다. 공간 다중화, 공간-시간 블록 코드, 송신 및/또는 수신 빔형성은 모든 전송에 적용될 수 있다.

이러한 트리플 플레이 프로토콜은 두 가지 실시예를 갖는데, 제1 실시예는 초기 핸드쉐이킹(initial handshaking)을 하지 않으며 반면에 제2 실시예는 노드(Node₁, Node₂ 및 RN) 간에 초기 핸드쉐이킹을 한다. 본 발명의 트리플 플레이 프로토콜은 Node₁의 TXOP 내에서 세 개의 노드로부터의 전송을 스케줄링하려고 시도한다. IEEE 802.11n 드래프트 표준에 기술된 프레임 집약(aggregation) 및 다중 트래픽 ID 블록 확인응답(acknowledgement)(MTBA)이 본 발명의 트리플 플레이 프로토콜에서 가정된다. 따라서, 본 발명의 시스템은 두 노드(소스 및 목적지)가 데이터를 정확하게 디코딩하지 못한 서브 프레임만을 RN이 처리하는 경우에 데이터 속도를 더 높일 수 있다.

제1 실시예는 RN과 초기 핸드쉐이킹을 하지 않는 본 발명의 트리플 플레이 프로토콜이다. 이 실시예에서, Node₁과 Node₂ 간의 두 전송의 수신이 양호한 어떤 노드는 중계 노드(RN)로서 역할을 하도록 경쟁할 수 있다. 도 2에는 제1 실시예가 예시되어 있다. 초기 핸드쉐이킹을 하지 않는 본 발명의 트리플 플레이 프로토콜은 다음과 같이 동작한다.

(1) Node₂가 송신 클리어(clear-to-send: CTS) 메시지(신호)를 송신함으로써 Node₁에 의해 전송된(송신된) 송신 요구(request-to-send: RTS) 신호(메시지)에 대해 (Node₁에) 확인응답할 때, Node₂는 양방향 통신인 역방향 전송을 또한 요구한다. 그러면 Node₁은 DATA₁ 및 블록 확인응답 요구(Block ACK request)를 전송하고 Node₂에 RD 전송을 승인한다. 본 발명의 다른 실시예에서, Node₁은 Node₂로부터의 명시적 요구없이 Node₂에 RD 전송을 승인할 수 있다.

(2) Node₂는 DATA₁ 내에 있는 부정확하게 수신된 임의의 서브 프레임에 관한 정보를 포함하는 Block ACK(BA₁)를 Node₁로 반송한다. Node₂는 또한 그의 DATA₂를 송신하고 그에 이어서 그의 Block ACK Request를 송신한다.

(3) Node₁은 DATA₂ 내에 있는 부정확하게 수신된 임의의 서브 프레임에 관한 정보를 포함하는 Block ACK(BA₂)를 Node₂로 송신한다. 만일 Node₂가 DATA₁ 내에 있는 모든 서브 프레임을 정확하게 수신하지 못하고 및/또는 Node₁이 DATA₂ 내에 있는 모든 서브 프레임을 정확하게 수신하지 못하면, Node₁은 Request_RS_To_Send(R_RS_TS) 메시지(신호)를 포스팅하여 RN으로부터의 도움을 요청한다.

(4) 만일 RN이 DATA₁에 대한 Node₂의 분실(missing) 부분 및 DATA₂의 Node₁에 대한 분실 부분 둘 다를 정확하게 수신하고, 또한 R_RS_TS 메시지(신호)를 수신하면, RN은 Clear_RS_To_Send(C_RS_TS) 메시지(신호)를 전송(송신)하여 그것이 RN으로서 역할을 한다는 것을 Node₁ 및 Node₂에게 알려줄 수 있다. RN은 이어서 Block ACK(BA_{1 &2})를 멀티캐스트(브로드캐스트)하여 전술한 예에서 제시된 바와 같이 다양한 네트워크 코딩 방식 중 임의의 하나에 기반하여 DATA₁ 및 DATA₂의 분실 부분 및 그에 이어서 조합된 DATA₃ 모두의 수신을 보고한다. RN이 어느 데이터를 분실(부정확하게 수신, 유실, 손상, 훼손)하였는지를 판단하여 전술한 예들과 같은 임의의 네트워크 코딩 방식을 이용하여 데이터의 분실 부분을 혼합(결합)할 수 있도록 하기 위해 RN이 데이터의 분실 부분뿐만 아니라 BA₁ 및 BA₂를 모두 수신하였다고 가정한다.

만일 RN이 단지 DATA₁에 대한 Node₂의 분실 부분의 일부 및 DATA₂에 대한 Node₁의 분실 부분의 일부만을 정확하게 수신한다면, RN은 또한 전술한 예시적인 네트워크 코딩 방식에 기반하여 그러한 데이터 부분을 조합하여 이를 DATA₃로서 전송(전달, 송신)할 수 있음을 주목하자.

정확하게 수신된 DATA₁의 분실 부분만에 관한 정보에 이어서 정확하게 수신된 DATA₂의 분실 부분만에 관한 정보를 포함한 것으로 자동 축소된 BA_{1 &2}의 비트맵이 존재한다. RN은 Node₁ 및 Node₂ 둘 다가 이러한 비트맵을 인지하기(알고 있기) 때문에, 그것의 전송 후에 Block ACK Request를 전송(전달, 송신)할 필요가 없다.

(5) Node₂는 DATA₁의 분실 부분의 수신을 보고하는 Block ACK(BA₃₂)를 먼저 송신(전송, 전달)한 다음에, Node₁은 나중에 BA₃₁을 전달(송신, 전송)하여 단지 DATA₂의 분실 부분만의 수신을 보고한다. 본 발명의 대안의 실시예에서, Block ACK를 송신하는 순서는 정반대이다.

(6) RN의 전송 후에, 만일 Node₁ 및 Node₂ 중 어느 하나 또는 둘 다가 여전히 어떤 서브 프레임의 재전송을 필요로 하고, TXOP가 만료(런 아웃)하지 않았다면, 이들 중 어느 하나는 다른 R_RS_TS를 전송(송신, 전달)하여 다시 도움을 요청할 수 있으며, 동일하거나 다른 노드가 RN으로서 역할을 할 수 있거나, 또는 다른 소스 노드(만일 Node₁이 분실 데이터를 필요로 하고 다른 R_RS_TS 메시지(신호)를 먼저 송신한다면, Node₂가 다른 소스 노드임)가 재전송할 수 있다.

(7) 제어 프레임은 스케줄링 및 시그널링 시에 중요한 역할을 하기 때문에 제어 프레임은 데이터 프레임보다 더 중요하므로, 제어 프레임은 이들의 수신이 목적지에서 다이버시티(diversity)를 갖도록 낮은 데이터 속도를 이용하여 송신(전송, 전달)되며 반면에 데이터는 높은 데이터 속도를 이용하여 송신(전송, 전달)되는 것이 권장된다. 낮은 데이터 속도의 전송은 본질적으로 더 신뢰할 수 있어야 한다.

(8) 본 발명의 트리플 플레이 프로토콜에서, RN은 Node₁와 독립적으로 지정되며, 반면에 실제로 RN은 존재하지 않을 수 있거나 또는 모든 RN은 양 세트의 데이터, 또는 양 세트의 데이터의 대부분을 성공적으로 디코딩하지 않을 수 있음을 주목하자. 그러한 경우, 만일 Node₁이 소정의 시간을 대기하지만 C_RS_TS를 듣지 못하면, 즉, RN이 도움이 될 수 없다면, Node₁은 Node₂가 정확하게 수신하지 못한 BA₂ 내에서 Node₂에 의해 표시된 데이터를 재전송해야 한다.

제2 실시예는 RN와 초기 핸드쉐이킹을 하는 본 발명의 트리플 플레이 프로토콜이다. 제1 실시예와 비교해서 이 실시예의 장점은 다음과 같다. 첫째, Node₁ 및 Node₂는 전용 RN이 존재한다는 것을 알고 있기 때문에, 이들의 전송(통신)은 좀 더 공격적일 수 있다. 둘째, RN은 두 노드(소스 및 목적지)로부터의 전송에 민감할 것이며 데이터를 복원하고 처리할 것이다. 셋째, 두 노드(소스 및 목적지)로부터 아마도 신호를 수신할 수 있는 다른 노드들은 이들 노드가 항상 채널에 경청(listen)할 필요가 없기 때문에 완화된다. 그러나, RN을 포함하여 자유로운(이용가능한) 다른 노드들은 이들 노드가 RN으로서 역할을 하는 경우 네트워크에 주는 이익을 잘 추정할 수 있도록 여전히 채널에 어떻게든 경청하고 다른 노드로부터 채널 정보를 획득할 필요가 있을 수 있다. 더욱이, RN이 되려는 경쟁은 이제 단지 데이터의 양호한 수신에 의해서만 동기되지 않고, 적절하거나 최적의 채널 품질(상태)을 갖지 않는 노드가 RN이 되려는 다른 노드를 제칠 수 있는 의지(willingness)가 좀 더 동기가 된다. 따라서, 채널 상태에 기반한 양호한 RN 경쟁 메커니즘이 필요하다. 도 3에는 제2 실시예가 예시되어 있다. 그 설명은 다음과 같다.

(1) 만일 RN이 Node₁의 RTS를 수신하면, RN은 C_RS_TS (Clear_RS_To_Send) 프레임을 송신(전송, 전달)하여 Node₂가 CTS를 송신(전송, 전달)하기 전에 그것이 RN으로서 역할을 한다고 다른 노드에게 알려줄 수 있다. Node₁ 및 Node₂는 둘 다 C_RS_TS를 수신할 수 있어야 한다. Node₁ 및 Node₂는 이어서 RN과 그 자신들 간의 채널 상태에 기반하여 자신들의 데이터 속도를 결정할 수 있다. 만일 채널 상태가 충분히 양호하면, Node₁ 및 Node₂는 이들 간의 직접 링크의 용량보다 더 높은 데이터 속도조차도 이용할 수 있다. 이어서 Node₂는 양방향 통신 요구인 그의 RD 전송 요구와 함께 그의 CTS를 송신(전송, 전달)한다. 이것으로 RN과의 핸드쉐이킹이 완료된다.

(2) Node₁은 이어서 DATA₁ 및 Block ACK request를 전송하고 Node₂에 RD 전송을 승인한다. Node₂는 DATA₁ 내에 있는 부정확하게 수신된(유실된, 손상된, 훼손된) 서브 프레임에 관한 정보를 포함하는 Block ACK(BA₁) 및 그에 이어서 그의 DATA₂와 그의 Block ACK Request를 Node₁로 송신한다. 본 발명의 다른 실시예에서, Node₁은 Node₂로부터의 명시적 요구없이 Node₂에 RD 전송을 승인할 수 있다.

(3) 후속 처리는 Node₁이 더 이상 R_RS_TS 프레임을 송신할 필요가 없고 이에 이어서, RN이 C_RS_TS 프레임을 송신할 필요가 없다는 것을 제외하고는, 초기 핸드쉐이킹을 하지 않는 트리플 플레이 프로토콜과 유사할 것이다.

이제 도 4를 참조하면, 본 발명의 트리플 플레이 프로토콜의 제1 실시예의 원리에 따른 Node₁의 동작 흐름도이다. (405)에서, Node₁은 RTS 신호(메시지)를 전송(전달, 송신)한다. (410)에서 Node₁이 전송한 RTS 메시지(신호)에 응답하여 Node₁이 CTS 신호(메시지) 및 RD 전송 요구 메시지(신호)를 수신하였는지를 판단하는 테스트가 수행된다. 만일 Node₁이 CTS 신호(메시지) 및 RD 전송 요구 메시지(신호)를 수신하지 않았다면, 처리는 (410)으로 되돌아간다. 만일 Node₁이 CTS 신호(메시지) 및 RD 전송 요구 메시지(신호)를 수신하였다면, (415)에서 Node₁은 DATA₁, Block ACK request₁ 및 RD 전송 승인을 전송(전달, 송신)한다. (420)에서 Node₁이 BA₁, DATA₂ 및 Block ACK request₂를 수신하였는지를 판단하는 테스트가 수행된다. 만일 Node₁이 BA₁, DATA₂ 및 Block ACK request₂ 신호(메시지)를 수신하지 않았다면, 처리는 (420)으로 되돌아간다. 만일 Node₁이 BA₁, DATA₂ 및 Block ACK request₂ 신호(메시지)를 수신하였다면, (425)에서 Node₁은 BA₂ 및 R_RS_TS 메시지(신호)를 전송(전달, 송신)한다. (427)에서 C_RS_TS 신호(메시지)가 수신되었는지를 판단하는 테스트가 수행된다. 만일 C_RS_TS 신호(메시지)가 수신되었다면, (430)에서 Node₁이 BA₃₂ 메시지(신호)를 수신하였는지를 판단하는 테스트가 수행된다. 만일 Node₁이 BA₃₂ 메시지(신호)를 수신하지 않았다면, 처리는 (430)으로 되돌아간다. 만일 Node₁이 BA₃₂ 메시지(신호)를 수신하였다면, (435)에서 Node₁은 BA₃₁을 전송(전달, 송신)한다. BA₃₁은 RN으로부터의 브로드캐스트(멀티캐스트)에서 수신된 DATA₃에 응답하여 송신된다. BA₃₂는 RN으로부터의 브로드캐스트(멀티캐스트)에서 수신된 DATA₃에 응답하여 Node₂로부터 수신된다. 만일 C_RS_TS 신호(메시지)가 수신되지 않았다면, 처리는 (427)로 되돌아간다. 도 4에는 타이머가 도시되지 않았다. 그러나, 타이머는 테스트가 수행되는 각 시점에서 사용된다. 예를 들어, (405)에서 타이머는 RTS 신호(메시지)가 송신된(전송된) 후 설정되고 (410)에서 만일 타이머가 만료되기 전에 CTS 신호(메시지)가 수신되지 않으면, Node₁은 RTS 신호(메시지)를 재송신할 것이다. 만일 CTS 신호(메시지)가 수신되고 RD 신호(메시지)가 수신되지 않으면, Node₁은 다음 단계로 진행하고 RD 요구 신호(메시지)가 없었다고 가정할 수 있거나 또는 RD 요구 신호(메시지)가 내포되어 있었다고 가정할 수 있다. 유사하게 (415)에서 타이머는 DATA₁, Block ACK request₁ 및 RD 전송 승인의 전송 후에 설정된다. 만일 타이머가 만료되고 BA₁, DATA₂ 및 Block ACK request₂ 신호(메시지)가 수신되지 않았다면, Node₁은 BA₁, DATA₂ 및 Block ACK request₂ 신호(메시지)를 재전송할 것이다. 대안으로, 만일 타이머가 만료되고 BA₁, DATA₂ 및 Block ACK request₂ 신호(메시지)가 수신되지 않았다면, Node₁은 R_RS_TS 신호(메시지)를 송신하여 중계 노드로부터의 도움을 요청할 것이다. 유사하게, (427) 및 (430)에서, 타이머는 C_RS_TS 신호(메시지) 및 BA₃₂의 수신을 대기하도록 설정된다.

이제 도 5를 참조하면, 본 발명의 트리플 플레이 프로토콜의 제1 실시예의 원리에 따른 Node₂의 동작 흐름도가 도시된다. (505)에서 Node₂가 Node₁에 의해 전송된(전달된, 송신된) RTS 메시지(신호)를 수신하였는지를 판단하는 테스트가 수행된다. 만일 Node₂가 Node₁에 의해 송신된(전송된, 전달된) RTS 메시지(신호)를 수신하지 않았다면, 처리는 (505)로 되돌아간다. 만일 Node₂가 Node₁에 의해 송신된(전송된, 전달된) RTS 메시지 신호를 수신하였다면, (510)에서 Node₂는 CTS 메시지(신호) 및 RD 전송 요구를 전송(전달, 송신)한다. (515)에서 Node₂가 DATA₁, Block ACK request₁ 및 RD 전송 승인 메시지(신호)를 수신하였는지를 판단하는 테스트가 수행된다. 만일 Node₂가 DATA₁, Block ACK request₁ 및 RD 전송 승인 메시지(신호)를 수신하지 않았다면, 처리는 (515)로 되돌아간다. 만일 Node₂가 DATA₁, Block ACK request₁ 및 RD 전송 승인 메시지(신호)를 수신하였다면, (520)에서 Node₂는 BA₁, DATA₂ 및 Block ACK request₂를 전송(전달, 송신)한다. (525)에서 Node₂가 RN에 의해 브로드캐스트(멀티캐스트)된 C_RS_TS 메시지(신호), BA_{1 &2} 및 DATA₃를 수신하였는지를 판단하는 테스트가 수행된다. 만일 Node₂가 C_RS_TS 메시지(신호), BA_1&2 및 DATA₃를 수신하지 않았다면, 처리는 (525)으로 되돌아간다. 만일 Node₂가 C_RS_TS 메시지(신호), BA_{1 &2} 및 DATA₃를 수신하였다면, (530)에서 Node₂는 BA₃₂를 전송한다. BA₃₂는 RN으로부터 브로드캐스트(멀티캐스트)로 수신된 DATA₃에 응답하여 Node₂로부터 수신된다. 도 5에는 타이머가 도시되지 않았다. 그러나, 타이머는 테스트가 수행되는 대부분의 시점에서 사용된다. 예를 들어, (510)에서 타이머는 Node₂가 CTS 및 RD 전송 요구를 전송(전달, 송신)한 후 설정되고 (515)에서 타이머가 만료되기 전에 만일 DATA₁, Block ACK request₁ 및 RD 전송 승인 신호(메시지)가 수신되지 않았다면, Node₂는 CTS 및 RD 전송 요구 신호(메시지)를 재전송한다. 유사하게, (525)에서 타이머는 Node₂가 BA₁, DATA₂ 및 Block ACK request₂ 신호(메시지)를 전송(전달, 송신)한 후에 설정되고 만일 Node₂가 C_RS_TS, BA_{1 &2} 및 DATA₃를 수신하지 않았다면, Node₂는 BA₁, DATA₂ 및 Block ACK request₂ 신호(메시지)를 재전송한다.

이제 도 6을 참조하면, 본 발명의 트리플 플레이 프로토콜의 제1 실시예의 원리에 따른 RN의 동작 흐름도가 도시된다. (605)에서 RN은 채널에 경청하고 채널 상태를 추정한다. 여러 신호 품질 측정치(measures) 중 어떤 것이라도 (다음으로 제한되지 않지만) 신호대 잡음비(SNR) 및 수신 신호 강도 표시(RSSI)와 같은 채널 상태를 나타내는데 사용될 수 있다. (610)에서 RN이 Node₁로부터 R_RS_TS 메시지(신호)를 수신하였는지를 판단하는 테스트가 수행된다. 만일 RN이 R_RS_TS 메시지(신호)를 수신하지 않았다면, 처리는 (605)로 되돌아간다. 만일 RN이 R_RS_TS 메시지(신호)를 수신하였다면, (615)에서 채널 상태가 (여러 신호 품질 측정치 중 임의의 하나 이상에 기초하여) RN으로서 역할을 하기에 충분히 양호한지를 판단하는 테스트가 수행된다. 만일 채널 상태가 (여러 신호 품질 측정치 중 임의의 하나 이상에 기초하여) RN으로서 역할을 하기에 충분히 양호하지 않으면, 처리는 (605)로 되돌아간다. 만일 채널 상태가 (여러 신호 품질 측정치 중 임의의 하나 이상에 기초하여) RN으로서 역할을 하기에 충분히 양호하면, (620)에서 RN은 C_RS_TS, BA_1&2 및 DATA₃를 브로드캐스트(멀티캐스트)한다. 위에서 기술되고 설명된 바와 같은 DATA₃은 DATA₁ 및 DATA₂의 분실 부분들의 혼합(조합)이다. RN은 RN이 블록 ACKs, DATA₁ 및 DATA₂에서 엿들은 정보에 기초하여 그러한 혼합(조합)을 생성한다.

이제 도 7을 참조하면, 본 발명의 트리플 플레이 프로토콜의 제2 실시예의 원리에 따른 Node₁의 동작 흐름도가 도시된다. (705)에서 Node₁은 RTS 신호(메시지)를 전송(전달, 송신)한다. (710)에서 Node₁이 전송한 RTS 메시지(신호)에 응답하여 Node₁이 CTS 신호(메시지), C_RS_TS 메시지(신호) 및 RD 전송 요구 메시지(신호)를 수신하였는지를 판단하는 테스트가 수행된다. 만일 Node₁이 CTS 신호(메시지), C_RS_TS 신호(메시지) 및 RD 전송 요구 메시지(신호)를 수신하지 않았다면, 처리는 (710)으로 되돌아간다. 만일 Node₁이 CTS 신호(메시지) 및 RD 전송 요구 메시지(신호)를 수신하였다면, (715)에서 Node₁은 DATA₁, Block ACK request₁ 및 RD 전송 승인을 전송(전달, 송신)한다. (720)에서 Node₁이 BA₁, DATA₂ 및 Block ACK request₂를 수신하였는지를 판단하는 테스트가 수행된다. 만일 Node₁이 BA₁, DATA₂ 및 Block ACK request₂ 신호(메시지)를 수신하지 않았다면, 처리는 (720)으로 되돌아간다. 만일 Node₁이 BA₁, DATA₂ 및 Block ACK request₂ 신호(메시지)를 수신하였다면, (725)에서 Node₁은 BA₂를 전송(전달, 송신)한다. (730)에서 Node₁이 BA₃₂ 메시지(신호)를 수신하였는지를 판단하는 테스트가 수행된다. 만일 Node₁이 BA₃₂ 메시지(신호)를 수신하지 않았다면, 처리는 (730)으로 되돌아간다. 만일 Node₁이 BA₃₂ 메시지(신호)를 수신하였다면, (735)에서 Node₁은 BA₃₁을 전송(전달, 송신)한다. BA₃₁은 RN으로부터 브로드캐스트(멀티캐스트)로 수신된 DATA₃에 응답하여 송신된다. BA₃₂는 RN으로부터 브로드캐스트(멀티캐스트)로 수신된 DATA₃에 응답하여 Node₂로부터 수신된다. 도 7에는 타이머가 도시되지 않았다. 그러나, 타이머는 테스트가 수행되는 각 시점에서 사용된다. 예를 들어, (705)에서 타이머는 RTS 신호(메시지)가 송신된(전송된) 후 설정되고 (710)에서 타이머가 만료되기 전에 만일 CTS 신호(메시지) 및 C_RS_TS 신호(메시지)가 수신되지 않으면, Node₁은 RTS 신호(메시지)를 재송신할 것이다. 만일 CTS 신호(메시지) 및 C_RS_TS 메시지(신호)가 수신되고 RD 신호(메시지)가 수신되지 않으면, Node₁은 다음 단계로 진행하고 RD 요구 신호(메시지)가 없었다고 가정할 수 있거나 또는 RD 요구 신호(메시지)가 내포되어 있었다고 가정할 수 있다. 만일 CTS 신호(메시지)가 수신되고 C_RS_TS 메시지(신호) 및 RD 신호(메시지)가 수신되지 않으면, Node₁은 다음 단계로 진행하고 중계 노드 및 RD 요구 신호(메시지)가 없었다고 가정할 수 있거나 또는 RD 요구 신호(메시지)가 내포되어 있었다고 가정할 수 있다. 유사하게 (715)에서 타이머는 DATA₁, Block ACK request₁ 및 RD 전송 승인의 전송 후에 설정된다. 만일 타이머가 만료되고 BA₁, DATA₂ 및 Block ACK request₂ 신호(메시지)가 수신되지 않았다면, Node₁은 BA₁, DATA₂ 및 Block ACK request₂ 신호(메시지)를 재전송할 것이다. 유사하게, (730)에서, 타이머는 BA₃₂의 수신을 대기하도록 설정된다.

이제 도 8을 참조하면, 본 발명의 트리플 플레이 프로토콜의 제2 실시예의 원리에 따른 Node₂의 동작 흐름도가 도시된다. (805)에서 Node₂가 Node₁에 의해 전송된(전달된, 송신된) RTS 메시지(신호) 및 RN에 의해 브로드캐스트(멀티캐스트)된 C_RS_TS 메시지(신호)를 수신하였는지를 판단하는 테스트가 수행된다. 만일 Node₂가 Node₁에 의해 송신된(전송된, 전달된) RTS 메시지(신호) 및 RN에 의해 브로드캐스트(멀티캐스트)된 C_RS_TS 메시지(신호)를 수신하지 않았다면, 처리는 (805)로 되돌아간다. 만일 Node₂가 Node₁에 의해 송신된(전송된, 전달된) RTS 메시지 신호 및 RN에 의해 브로드캐스트(멀티캐스트)된 C_RS_TS 메시지(신호)를 수신하였다면, (810)에서 Node₂는 CTS 메시지(신호) 및 RD 전송 요구를 전송(전달, 송신)한다. (815)에서 Node₂가 DATA₁, Block ACK request₁ 및 RD 전송 승인 메시지(신호)를 수신하였는지를 판단하는 테스트가 수행된다. 만일 Node₂가 DATA₁, Block ACK request₁ 및 RD 전송 승인 메시지(신호)를 수신하지 않았다면, 처리는 (815)로 되돌아간다. 만일 Node₂가 DATA₁, Block ACK request₁ 및 RD 전송 승인 메시지(신호)를 수신하였다면, (820)에서 Node₂는 BA₁, DATA₂ 및 Block ACK request₂를 전송(전달, 송신)한다. (825)에서 Node₂가 RN에 의해 브로드캐스트(멀티캐스트)된 BA_{1 &2} 및 DATA₃를 수신하였는지를 판단하는 테스트가 수행된다. 만일 Node₂가 BA_{1 &2} 및 DATA₃를 수신하지 않았다면, 처리는 (825)으로 되돌아간다. 만일 Node₂가 C_RS_TS 메시지(신호), BA_{1 &2} 및 DATA₃를 수신하였다면, (830)에서 Node₂는 BA₃₂를 전송한다. BA₃₂는 RN으로부터 브로드캐스트(멀티캐스트)로 수신된 DATA₃에 응답하여 Node₂에 의해 전송(전달, 송신)된다. 도 8에는 타이머가 도시되지 않았다. 그러나, 타이머는 테스트가 수행되는 대부분의 시점에서 사용된다. 예를 들어, (810)에서 타이머는 Node₂가 CTS 및 RD 전송 요구를 전송(전달, 송신)한 후 설정되고 (815)에서 타이머가 만료되기 전에 만일 DATA₁, Block ACK request₁ 및 RD 전송 승인 신호(메시지)가 수신되지 않았다면, Node₂는 CTS 및 RD 전송 요구 신호(메시지)를 재전송한다. 유사하게, (825)에서 타이머는 Node₂가 BA₁, Data₂ 및 Block ACK request₂ 신호(메시지)를 전송(전달, 송신)한 후에 설정되고 만일 Node₂가 BA_{1 &2} 및 Data₃를 수신하지 않았다면, Node₂는 BA₁, Data₂ 및 Block ACK request₂ 신호(메시지)를 재전송한다.

이제 도 9를 참조하면, 본 발명의 트리플 플레이 프로토콜의 제2 실시예의 원리에 따른 RN의 동작 흐름도가 도시된다. (905)에서 RN은 채널에 경청하고 채널 상태를 추정한다. 여러 신호 품질 측정치 중 어떤 것이라도 (다음으로 제한되지 않지만) 신호대 잡음비(SNR) 및 수신 신호 강도 표시(RSSI)와 같은 채널 상태를 나타내는데 사용될 수 있다. (910)에서 RN이 Node₁으로부터 RTS 메시지(신호)를 수신하였(엿들었)는지를 판단하는 테스트가 수행된다. 만일 RN이 RTS 메시지(신호)를 수신하지(엿듣지) 않았다면, 처리는 (905)로 되돌아간다. 만일 RN이 RTS 메시지(신호)를 수신하였(엿들었)다면, (915)에서 채널 상태가 (여러 신호 품질 측정치 중 임의의 하나 이상에 기초하여) RN으로서 역할을 하기에 충분히 양호한지를 판단하는 테스트가 수행된다. 만일 채널 상태가 (여러 신호 품질 측정치 중 임의의 하나 이상에 기초하여) RN으로서 역할을 하기에 충분히 양호하지 않으면, 처리는 (905)로 되돌아간다. 만일 채널 상태가 (여러 신호 품질 측정치 중 임의의 하나 이상에 기초하여) RN으로서 역할을 하기에 충분히 양호하면, (920)에서 RN은 C_RS_TS를 브로드캐스트(멀티캐스트)하고 (925)에서 RN은 BA_{1 &2} 및 DATA₃를 브로드캐스트(멀티캐스트)한다. 위에서 기술되고 설명된 DATA₃는 DATA₁ 및 DATA₂의 분실 부분들의 혼합(조합)이다. RN은 RN이 블록 ACKs, DATA₁ 및 DATA₂에서 엿들은 정보에 기초하여 그러한 혼합(조합)을 생성한다.

도 10은 본 발명의 원리에 따른 예시적인 장치의 블록도이다. 어떠한 노드라도 언제든지 소스 노드, 목적지 노드, 및 중계 노드로서 동작할 수 있기 때문에, 도 10의 장치는 언제든지 이러한 각각의 디바이스(장치)에 해당한다. 송수신기는 실제로 데이터 및 임의의 제어 신호를 송수신하고 제어 로직은 모든 다른 기능을 수행한다.

구체적으로, 소스 노드로서 동작할 때, 도 10의 장치의 제어 로직 부분은 송신 클리어 신호 및 역방향 전송 요구 신호가 수신되었는지를 판단하는 수단, 제1 블록 확인응답 신호, 제2 데이터 및 제2 블록 확인응답 요구 신호가 수신되었는지를 판단하는 수단 및 제3 블록 확인응답 신호가 수신되었는지를 판단하는 수단을 포함한다. (소스 노드로서 동작하는) 본 발명의 제2 실시예에서, 상기 제1 판단 수단은 중계 노드의 송신 클리어 신호가 수신되었는지를 판단하는 수단을 더 포함한다. 소스 노드로서 동작하는 도 10의 장치의 송수신기 부분은 송신 요구 신호를 전송하는 수단, 상기 제1 판단 수단에 응답하여 제1 데이터, 제1 블록 확인응답 요구 신호 및 역방향 승인 신호를 전송하는 수단, 상기 제2 판단 수단에 응답하여 제2 블록 확인응답 신호를 전송하는 수단 및 상기 제3 판단 수단에 응답하여 제4 블록 확인응답 신호를 전송하는 수단을 포함한다. (소스 노드로서 동작하는) 본 발명의 제1 실시예는 상기 제2 판단 수단에 응답하여 중계 노드의 송신 요구 신호를 전송하는 수단을 더 포함한다.

구체적으로, 목적지 노드로서 동작할 때, 도 10의 장치의 제어 로직 부분은 송신 요구 신호가 수신되었는지를 판단하는 수단, 제1 데이터, 제1 블록 확인응답 요구 신호 및 역방향 전송 승인 신호가 수신되었는지를 판단하는 수단, 및 제2 블록 확인응답 신호 및 제3 데이터가 수신되었는지를 판단하는 수단을 포함한다. 상기 제어 로직에서 (목적지 노드로서 동작하는) 본 발명의 제1 실시예에서, 상기 제3 판단 수단은 중계 노드의 송신 클리어 신호가 수신되었는지를 판단하는 수단을 더 포함한다. 상기 제어 로직에서 (목적지 노드로서 동작하는) 본 발명의 제2 실시예에서, 상기 제1 판단 수단은 중계 노드의 송신 클리어 신호가 수신되었는지를 판단하는 수단을 더 포함한다. (목적지 노드로서 동작하는) 도 10의 장치의 상기 송수신기 부분은 상기 제1 판단 수단에 응답하여 송신 클리어 신호, 역방향 전송 요구 신호를 전송하는 수단, 상기 제2 판단 수단에 응답하여 제1 블록 확인응답 신호, 제2 데이터 및 제2 블록 확인응답 요구를 전송하는 수단 및 상기 제3 판단 수단에 응답하여 제3 블록 확인응답 신호를 전송하는 수단을 포함한다.

구체적으로, 중계 노드로서 동작할 때, 도 10의 장치의 제어 로직 부분은 채널에 경청하는 수단, 상기 경청 수단에 응답하여 채널 상태를 추정하는 수단, 제1 노드로부터 제1 데이터를 수신하는 수단, 제2 노드로부터 제2 데이터를 수신하는 수단, 신호가 수신되었는지를 판단하는 수단, 채널 상태가 중계 노드로서 역할을 하기에 적합한지를 판단하는 수단을 포함한다. (중계 노드로서 동작하는) 본 발명의 제1 실시예에서, 상기 신호는 중계 노드의 송신 요구 신호이다. (중계 노드로서 동작하는) 본 발명의 제2 실시예에서, 상기 신호는 송신 요구 신호이다. (중계 노드로서 동작하는) 도 10의 장치의 송수신기 부분은 상기 제1 및 제2 판단 수단에 응답하여 중계 노드의 송신 클리어 신호를 멀티캐스팅하는 수단 및 상기 제1 및 제2 판단 수단에 응답하여 블록 확인응답 신호 및 제3 데이터를 멀티캐스팅하는 수단을 포함한다.

본 발명은 하드웨어, 소프트웨어, 펌웨어, 전용 프로세서, 또는 이들의 조합의 여러 형태로 구현될 수 있음은 물론이다. 바람직하게, 본 발명은 하드웨어 및 소프트웨어의 조합으로서 구현된다. 더욱이, 소프트웨어는 프로그램 저장 장치에서 유형으로 구체화된 응용 프로그램으로서 구현되는 것이 바람직하다. 이러한 응용 프로그램은 어떤 적절한 아키텍처를 포함하는 머신에 업로드되고, 그 머신에 의해 실행될 수 있다. 바람직하게, 이 머신은 하나 이상의 중앙 처리 유닛(CPU), 랜덤 액세스 메모리(RAM), 및 입/출력(I/O) 인터페이스(들)와 같은 하드웨어를 갖는 컴퓨터 플랫폼 상에서 구현된다. 이러한 컴퓨터 플랫폼은 또한 운영 체제 및 마이크로명령 코드를 포함한다. 본 명세서에서 기술된 각종 프로세스 및 기능은 운영 체제를 통해 실행되는 마이크로명령 코드의 일부이거나 또는 응용 프로그램의 일부 (또는 이들의 조합)일 수 있다. 또한, 각종 다른 주변 장치는 추가적인 데이터 저장 장치 및 인쇄 장치와 같은 컴퓨터 플랫폼에 연결될 수 있다.

첨부의 도면에 도시된 시스템 구성 요소 및 방법 단계 중 일부는 소프트웨어로 구현되는 것이 바람직하므로, 시스템 구성 요소 (또는 프로세스 단계) 간의 실제 연결은 본 발명이 프로그램되는 방식에 따라 다를 수 있음을 추가로 알아야 한다. 본 명세서에서의 가르침이 주어진다면, 당업자는 본 발명의 이러한 구현 또는 구성과 유사한 구현 또는 구성을 계획할 수 있을 것이다.

Claims (10)

1. 송신 요구 신호(request-to-send signal)를 전송하는 단계;
   송신 클리어 신호(clear-to-send signal) 및 역방향 전송 요구 신호가 수신되었는지를 판단하는 단계;
   상기 제1 판단에 응답하여 제1 데이터, 제1 블록 확인응답(acknowledgement) 요구 신호 및 역방향 승인(grant) 신호를 전송하는 단계;
   제1 블록 확인응답 신호, 제2 데이터 및 제2 블록 확인응답 요구 신호가 수신되었는지를 판단하는 단계;
   상기 제2 판단에 응답하여 제2 블록 확인응답 신호를 전송하는 단계;
   제3 블록 확인응답 신호가 수신되었는지를 판단하고 상기 제2 판단에 응답하여 중계(relay) 노드의 송신 요구 신호를 전송하는 단계 - 상기 제1 판단은 중계 노드의 송신 클리어 신호가 수신되었는지를 판단하는 단계를 더 포함함 -; 및
   상기 제3 판단에 응답하여 제4 블록 확인응답 신호를 전송하는 단계
   를 포함하는 방법.
2. 송신 요구 신호를 전송하는 수단;
   송신 클리어 신호 및 역방향 전송 요구 신호가 수신되었는지를 판단하는 수단;
   상기 제1 판단 수단에 응답하여 제1 데이터, 제1 블록 확인응답 요구 신호 및 역방향 승인 신호를 전송하는 수단;
   제1 블록 확인응답 신호, 제2 데이터 및 제2 블록 확인응답 요구 신호가 수신되었는지를 판단하는 수단;
   상기 제2 판단 수단에 응답하여 제2 블록 확인응답 신호를 전송하는 수단;
   제3 블록 확인응답 신호가 수신되었는지를 판단하고 상기 제2 판단에 응답하여 중계 노드의 송신 요구 신호를 전송하는 수단 - 상기 제1 판단 수단은 중계 노드의 송신 클리어 신호가 수신되었는지를 판단하는 수단을 더 포함함 -; 및
   상기 제3 판단 수단에 응답하여 제4 블록 확인응답 신호를 전송하는 수단
   을 포함하는 장치.
3. 송신 요구 신호가 수신되었는지를 판단하는 단계;
   상기 제1 판단에 응답하여 송신 클리어 신호, 역방향 전송 요구 신호를 전송하는 단계;
   제1 데이터, 제1 블록 확인응답 요구 신호 및 역방향 전송 승인 신호가 수신되었는지를 판단하는 단계;
   상기 제2 판단에 응답하여 제1 블록 확인응답 신호, 제2 데이터 및 제2 블록 확인응답 요구를 전송하는 단계;
   제2 블록 확인응답 신호 및 제3 데이터가 수신되었는지를 판단하는 단계 - 상기 제1 판단과 상기 제3 판단 중 하나는 중계 노드의 송신 클리어 신호가 수신되었는지를 판단하는 단계를 더 포함함 -; 및
   상기 제3 판단에 응답하여 제3 블록 확인응답 신호를 전송하는 단계
   를 포함하는 방법.
4. 송신 요구 신호가 수신되었는지를 판단하는 수단;
   상기 제1 판단 수단에 응답하여 송신 클리어 신호, 역방향 전송 요구 신호를 전송하는 수단;
   제1 데이터, 제1 블록 확인응답 요구 신호 및 역방향 전송 승인 신호가 수신되었는지를 판단하는 수단;
   상기 제2 판단 수단에 응답하여 제1 블록 확인응답 신호, 제2 데이터 및 제2 블록 확인응답 요구를 전송하는 수단;
   제2 블록 확인응답 신호 및 제3 데이터가 수신되었는지를 판단하는 수단 - 상기 제1 판단 수단 및 상기 제3 판단 수단 중 하나는 중계 노드의 송신 클리어 신호가 수신되었는지를 판단하는 수단을 더 포함함 -; 및
   상기 제3 판단 수단에 응답하여 제3 블록 확인응답 신호를 전송하는 수단
   을 포함하는 장치.
5. 채널들에 경청(listening)하는 단계;
   제1 노드로부터 제1 데이터를 수신하는 단계;
   제2 노드로부터 제2 데이터를 수신하는 단계;
   신호가 수신되었는지를 판단하는 단계;
   상기 경청에 응답하여 채널 상태들이 중계 노드로서 동작하기에 적합한지를 판단하는 단계; 및
   상기 제1 및 제2 판단 단계에 응답하여 중계 노드의 송신 클리어 신호를 멀티캐스팅(multicasting)하는 단계
   를 포함하는 방법.
6. 제5항에 있어서,
   상기 제1 및 제2 판단에 응답하여 블록 확인응답 신호 및 제3 데이터를 멀티캐스팅하는 단계를 더 포함하며,
   상기 제3 데이터는 상기 제1 데이터의 손상된 부분들 및 상기 제2 데이터의 손상된 부분들의 조합인 방법.
7. 제5항에 있어서, 상기 신호는 중계 노드의 송신 요구 신호 및 송신 요구 신호 중 하나인 방법.
8. 채널들에 경청하는 수단;
   제1 노드로부터 제1 데이터를 수신하는 수단;
   제2 노드로부터 제2 데이터를 수신하는 수단;
   신호가 수신되었는지를 판단하는 수단;
   상기 경청에 응답하여 채널 상태들이 중계 노드로서 역할을 하기에 적합한지를 판단하는 수단; 및
   상기 제1 및 제2 판단 수단에 응답하여 중계 노드의 송신 클리어 신호를 멀티캐스팅하는 수단
   을 포함하는 장치.
9. 제8항에 있어서,
   상기 제1 및 제2 판단 수단에 응답하여 블록 확인응답 신호 및 제3 데이터를 멀티캐스팅하는 수단을 더 포함하며,
   상기 제3 데이터는 상기 제1 데이터의 손상된 부분들 및 상기 제2 데이터의 손상된 부분들의 조합인 장치.
10. 제8항에 있어서, 상기 신호는 중계 노드의 송신 요구 신호 및 송신 요구 신호 중 하나인 장치.

Images