KR100678941B1 - 할당된 시간 동안 양방향으로 데이터를 송수신하는 방법및 그 방법을 이용하는 무선 디바이스 - Google Patents

Abstract

본 발명은 두 개의 디바이스 간에 통신을 할 수 있도록 허여된 시간 동안 양방향으로 데이터를 송수신하는 방법 및 장치에 관한 것이다.

본 발명에 따른 무선 디바이스는, 무선 매체를 통하여 MAC 프레임을 수신하는 PHY 모듈과, 수신된 MAC 프레임의 제1 필드(전송될 데이터가 더 존재하는지 여부를 나타내는 필드)의 값을 판독하는 MAC 모듈과, 상기 제1 필드의 값이 전송될 데이터가 더 존재하지 않음을 나타내는 비트이고, 상기 MAC 프레임이 수신된 후 소정의 임계시간 동안 채널이 비어 있으면 전송권이 전환된 것으로 판단하는, 전송권 판단 모듈; 및 전송권이 전환된 것으로 판단되고, 수신된 MAC 프레임을 전송한 디바이스로 전송할 데이터가 존재하면, 전송할 데이터를 포함하는 MAC 프레임을 전송하도록 MAC 모듈 및 PHY 모듈을 제어하는 제어 모듈을 포함한다.

IEEE 802.15.3, CTA, 피코넷, PNC

Description

할당된 시간 동안 양방향으로 데이터를 송수신하는 방법 및 그 방법을 이용하는 무선 디바이스{Method for transceiving data bi-directionally during allocated time and wireless device using the method}

도 1은 종래의 슈퍼프레임의 구조를 나타낸 도면.

도 2는 종래의 채널 시간 할당을 요청하는 과정을 나타낸 도면.

도 3은 종래의 비동기 데이터를 전송하는 과정을 나타낸 도면.

도 4는 IEEE 802.15.3 표준에 따른 MAC 프레임의 구조를 나타낸 도면.

도 5는 본 발명의 일 실시예에 따라 채널 시간내에 디바이스간에 양방향으로 데이터를 송수신하는 예를 나타낸 도면.

도 6은 본 발명의 일 실시예에 따른 무선 디바이스의 구성을 나타내는 블록도.

도 7은 본 발명의 일 실시예에 따른 전체 동작을 설명하는 흐름도.

도 8은 종래의 단방향 전송을 하는 경우에 대하여 슈퍼프레임 구조 및 데이터 전송 과정을 나타낸 도면.

도 9는 본 발명에 따른 양방향 전송을 하는 경우의 데이터 전송 과정을 나타낸 도면.

본 발명은 무선 디바이스 간에 통신하는 방법 및 장치에 관한 것으로, 보다 상세하게는 두 개의 무선 디바이스 간에 통신을 할 수 있도록 허여된 시간 동안 양방향으로 데이터를 송수신하는 방법 및 장치에 관한 것이다.

무선 디지털 펄스라고도 알려져 있는 UWB(Ultra wideband)는 단거리 구간에서 저전력으로 넓은 스펙트럼 주파수를 통해 많은 양의 디지털 데이터를 전송하기 위한 무선 기술이며, 미국 국방부가 군사적 목적으로 개발한 무선 기술이다. 이러한 UWB에 관한 표준화는 현재 IEEE 802.15.3, 즉 무선 PAN 규격 제정을 위한 워킹 그룹(Working Group)에서 진행되고 있다. IEEE 802.15.3에는 PHY와 MAC에 관해서 다루고 있는데, 현재 업계에서는 이 중에서도 MAC의 개선 방안에 대한 활발한 연구를 진행하고 있다.

IEEE 802.15.3 MAC의 특징은 무선 네트워크의 형성이 신속하다는 것이다. 그리고, AP(Access Point) 기반이 아니라 PNC(Piconet Coordinator)를 중심으로 한 피코넷이라고 하는 애드혹 네트워크(Ad Hoc Network)를 기반으로 한다. IEEE 802.15.3 MAC은 TDMA(시분할 다중 접속; Time Division Multiple Access)방식을 채택하고 있다. 도 1과 같은 슈퍼프레임(superframe)이라고 하는 시간적인 배치 구조 안에 디바이스 간에 데이터 송수신을 위한 MAC 프레임을 배치한다. 슈퍼프레임의 구성으로는 제어정보를 담고 있는 비콘(beacon)과 백오프(backoff)를 통해 데이터를 전송하는 CAP(Contention Access Period) 구간, 그리고 할당받은 시간에 경합없 이 데이터를 보내는 CTAP(Channel Time Allocation Period) 구간이 있다. 이 중에서 CAP는 MCTA(Management CTA)로 대체되어 사용될 수도 있다. 이 때, CAP 구간에는 CSMA/CA(Carrier Sense Multiple Access/Collision Avoidance) 방식을 사용하여 경쟁적 접근이 이루어지고, MCTA에서는 Slotted Aloha를 이용하여 채널을 억세스할 수 있다.

CTAP는 여러 개의 MCTA와 여러 개의 CTA 블럭으로 구성될 수 있다. CTA(Channel Time Allocation; 채널 시간 할당)의 종류에는 동적 CTA(Dynamic CTA)와 의사 정적 CTA(Pseudo static CTA) 두 가지 종류가 있다. 동적 CTA는 슈퍼프레임마다 그 위치가 바뀔 수 있으며, 비콘을 놓치면 해당 슈퍼프레임에서 CTA를 사용하지 못한다. 이에 반해, 의사 정적 CTA는 위치가 변하지 않고 같은 위치에 고정되어 있으며, 비콘을 놓치더라도 슈퍼프레임을 놓치더라도 고정된 위치에서 CTA 구간을 사용할 수 있다. 하지만, 의사 정적 CTA도 mMaxLostBeacons에 해당하는 횟수 이상 연속해서 비콘을 놓치면 사용할 수 없도록 하고 있다. 이와 같이, IEEE 802.15.3 MAC은 QoS(Quality of Service)를 보장할 수 있는 TDMA 기반으로 구성되어 있어 특히 홈네트워크 상에서의 멀티미디어 오디오/비디오 스트리밍(A/V Streaming)에 적합하다. 그러나, MAC에 있어서 QoS뿐 아니라 쓰루풋(Throughput)을 효과적으로 사용하기 위해서는 여전히 개선의 여지가 있다.

IEEE 802.15.3 MAC에서는 데이터 전송 방식으로 두 가지가 있다. 첫번째는 등시적 데이터(isochronous 데이터)를 전송하는 방식이고 두번째는 비동기적 데이터(asynchronous data)를 전송하는 방식이다.

도 2에서 보는 바와 같이, DEV 1는 등시적 데이터를 전송하기 위해서, 우선 MLME-CREATE-STREAM.request 및 MLME-CREATE-STREAM.confirm을 이용해 PNC로부터 채널 시간(channel time)을 할당 받는다. 그리고, MAC-ISOCH-DATA.request 및 MAC-ISOCH-DATA.confirm을 이용하여 상기 할당된 채널 시간 동안 실제 데이터를 전송한다. 할당된 채널 시간은 비콘을 해석함으로써 알 수 있으며, 이 정보를 이용하여 피코넷을 구성하는 디바이스(이하 ＇DEV＇라 한다)는 통신이 시작될 시간과 끝날 시간을 알 수 있다.

이 때 할당된 채널 시간에는 src DEV(소스 디바이스)와 dest DEV(목적지 디바이스)가 지정되어 있다. 도 2에서 보면, DEV 1가 src DEV가 되고, DEV 2가 dest DEV가 될 것이다. 할당된 채널 시간에 데이터를 송신하는 DEV는 반드시 src DEV이어야 하지만, 데이터를 수신하는 DEV는 반드시 CTA 정보에서 지정한 dest DEV일 필요는 없다. 다만, 상기 데이터를 수신할 수 있는 DEV는 ＇Always AWAKE bit＇ 또는＇listen to source bit＇이 1로 세팅되어 있는 DEV만이다.

한편, 도 3은 DEV 1가 비동기적 데이터를 전송하기 위한 과정을 나타낸 것이다. DEV 1는 송신할 데이터가 MAC-ASYNC-DATA.request를 통하여 MAC 층으로 도착하면, src DEV는 PNC에게 channel time request command 프레임을 보낸다. 이후 src DEV가 요청한 채널 시간이 할당되었다는 것을 비콘을 통해 알게 되면 그 채널 시간 동안 데이터를 송신한다. 상기 등시적 데이터 전송의 경우와 마찬가지로 할당된 채널 시간에 대하여는 src DEV 및 dest DEV 쌍이 지정되어 있으며, 할당된 채널 시간 동안에는 지정된 src DEV만이 데이터를 송신할 수 있다. 도 3에서도, DEV 1가 src DEV가 되고, DEV 2가 dest DEV가 될 것이다. 이외에, 비동기적 데이터를 보내는 또 다른 방법으로는 CAP(Contention Access Period)에서 백오프 알고리즘(backoff algorithm)를 이용하여 프레임을 보내는 방법도 있다.

TCP/IP의 경우 데이터 전송의 확실성을 보장하기 위해 DEV 1에서 프레임을 전송하면 DEV 2에서는 전송받은 프레임에 대한 ACK 프레임(도 2, 도 3에서의 Imm-ACK 프레임과 달리 TCP/IP 레벨의 ACK 프레임을 의미함)을 보낸다. 이러한 메커니즘을 갖는 TCP/IP에 IEEE 802.15.3 MAC에서 제공되는 데이터 전송 메커니즘을 그대로 사용하는 경우에 발생하는 문제점을 구체적으로 살펴보면 다음과 같다.

첫번째로, 등시적으로 TCP/IP 데이터를 전송하는 경우를 살펴 보면, 먼저 DEV 1은 DEV 2와 연결(connection)을 확립하기 위한 프레임을 보낼 것이다. 그러기 위해 우선 PNC에게 MLME-CREATE-STREAM.request를 보냄으로써 src DEV가 DEV 1, dest DEV가 DEV 2인 채널 시간 할당을 요청한다. PNC가 채널 시간을 할당하여 그 정보를 비콘에 실어서 보내면 DEV 1은 비콘 정보를 읽어 지정된 시간에 상기 프레임을 DEV 2에게 전송한다. DEV 2는 그에 대한 응답 프레임을 보내기 위해 src DEV가 DEV 2이고, dest DEV가 DEV 1인 채널 시간의 할당을 요청한다. 그리고, 마찬가지로 PNC가 채널 시간을 할당하고 이에 관한 정보를 비콘에 실어 보내면, DEV 2는 비콘 정보를 읽어 지정된 시간에 상기 응답 프레임을 DEV 1에게 전송한다. MLME-TERMINATE-STREAM.request를 전달받기 전까지는 채널 시간이 계속 할당되기 때문에 그 다음부터는 DEV 1과 DEV 2가 서로 주고 받는 데이터 및 ACK 프레임은 비콘의 채널 시간 정보에 따라 src DEV 및 dest DEV 쌍에 할당된 시간에 보내지게 될 것이 다. 그러나, TCP/IP의 특성상 송신자(sender)는 데이터 프레임을 보낸 후, ACK 프레임을 받기 전까지는 다른 프레임을 전송하지 않는다. 그런데, IEEE 802.15.3 MAC에서는 비콘에서 알려 주는 채널 시간 할당의 src DEV만이 그 채널 시간의 송신자가 될 수 있다. 따라서 DEV 2가 TCP/IP 레벨의 ACK 프레임을 보내려면, src DEV가 DEV 2인 채널 시간이 될 때까지 기다렸다가 ACK 프레임을 보내야 한다. 결국, DEV 1가 데이터를 보낸 후 DEV 1 및 DEV 2에 할당된 시간이 남는다고 하더라도 DEV 1은 그 남는 시간을 이용하여 DEV 2로부터 ACK를 받을 수는 없으므로 채널 시간의 낭비가 발생하는 것이다.

두번째로, 비동기적으로 TCP/IP 프레임을 전송하는 경우를 살펴 본다. 우선, CAP에 비동기적 데이터를 보내는 경우를 보면, PNC가 CAP를 슈퍼프레임에 할당할 수도 있고, 할당하지 않을 수도 있다. 뿐만 아니라, 만약 할당된 CAP가 있다고 하더라도 PNC가 설정한 기준에 따라서 그 구간 동안에 비동기적 데이터를 보낼 수 있는지 없는지가 결정되기 때문에, CAP를 이용하여 TCP/IP 프레임을 보내는 방법으로는 확실한 전송을 보장할 수 없다. 다음으로, 채널 시간 할당을 이용하여 비동기적 데이터를 보내려면 상기한 바와 같이 MAC-ASYNCH-DATA.request를 이용하게 된다. 그러나 도 3에 나타낸 바와 같이, 매번 channel time request command를 PNC에 보내서 채널 시간을 할당 받은 후에 데이터 프레임을 전송하여야 하므로 계속적으로 데이터를 전달해야 한다면 대역폭(bandwidth)의 낭비가 아닐 수 없다. 또한 채널 시간 할당을 요청하였다 하더라도 요청한 시간이 언제 할당될지는 보장이 되지 않아서 한 번 데이터 프레임을 보낼 때마다 최소 다음 슈퍼프레임까지 기다려야 하므 로 시간 지연이 매번 발생하게 될 것이다.

상기한 문제점은 IEEE 802.15.3 MAC의 상위층으로서 TCP/IP 이외에 다른 프로토콜을 사용하는 경우에도 마찬가지로 발생할 수 있다.

본 발명은 상기한 문제점을 감안하여 창안된 것으로, IEEE 802.15.3 MAC을 개선하여, 두 개의 디바이스 간에 할당된 채널 시간 동안, 보다 효율적으로 통신할 수 있도록 하는 것을 목적으로 한다. 이를 위하여 본 발명은, IEEE 802.15.3에서 정의되는 CTA를 단방향 전송이 아닌 양방향 전송에 사용하는 방법을 제공하고자 한다.

본 발명의 목적은 기존의 802.15.3 MAC 명세서에 다른 어떤 것들을 추가하지 않고도 할당받은 channel time을 양방향으로 쓸 수 있게 함으로써 TCP와 같이 양방향으로 데이터를 서로 주고 받아야 하는 프로토콜을 효율적으로 지원하도록 하는 것이다.

상기한 목적을 달성하기 위하여, 본 발명에 따른 무선 디바이스는, 무선 매체를 통하여 MAC 프레임을 수신하는 PHY 모듈; 상기 수신된 MAC 프레임의 제1 필드의 값을 판독하는데, 상기 제1 필드는 전송될 데이터가 더 존재하는지 여부를 나타내는 필드인, MAC 모듈; 상기 제1 필드의 값이 제1 비트이고, 상기 MAC 프레임이 수신된 후 소정의 임계시간 동안 채널이 비어 있으면 전송권이 전환된 것으로 판단하는데, 상기 제1 비트는 전송될 데이터가 더 존재하지 않음을 나타내는, 전송권 판단 모듈; 및 상기 전송권이 전환된 것으로 판단되고, 상기 수신된 MAC 프레임을 전송한 디바이스로 전송할 데이터가 존재하면, 상기 전송할 데이터를 포함하는 MAC 프레임을 전송하도록 상기 MAC 모듈 및 상기 PHY 모듈을 제어하는 제어 모듈을 포함한다.

상기 제어 모듈은, 상기 전송권이 전환된 것으로 판단되고, 상기 수신된 MAC 프레임을 전송한 디바이스로 전송할 데이터가 존재하지 않으면, 상기 디바이스에 전송권을 넘겨주는 프레임을 전송하도록 상기 MAC 모듈 및 PHY 모듈을 제어하는 것이 바람직하다.

상기한 목적을 달성하기 위하여, 본 발명에 따른, 할당된 시간 동안 양방향으로 데이터를 송수신하는 방법은, (a) 무선 매체를 통하여 MAC 프레임을 수신하는 단계; (b) 상기 수신되는 MAC 프레임의 제1 필드의 값을 판독하는 단계로서, 상기 제1 필드는 전송될 데이터가 더 존재하는지 여부를 나타내는, 단계; (c) 상기 필드의 값이 제1 비트이고, 상기 MAC 프레임이 수신된 후 소정의 임계시간 동안 채널이 비어 있으면 전송권이 전환된 것으로 판단하는 단계로서, 상기 제1 비트는 전송될 데이터가 더 존재하지 않음을 나타내는, 단계; 및 (d) 상기 전송권이 전환된 것으로 판단되고, 상기 수신된 MAC 프레임을 전송한 디바이스로 전송할 데이터가 존재하면, 상기 전송할 데이터를 포함하는 MAC 프레임을 상기 디바이스에 전송하는 단계를 포함한다.

상기 제1 필드는, IEEE 802.15.3의 MAC 헤더에 존재하는 More data 필드인 것이 바람직하다.

상기 임계 시간은, 적어도 IEEE 802.15.3의 retransmission interframe space(RIFS) 보다는 큰 것이 바람직하다.

상기 할당된 시간 동안 양방향으로 데이터를 송수신하는 방법은, (e) 상기 전송권이 전환된 것으로 판단되고, 상기 수신된 MAC 프레임을 전송한 디바이스로 전송할 데이터가 존재하지 않으면, 상기 디바이스에 전송권을 넘겨주는 프레임을 전송하는 단계를 더 포함하는 것이 바람직하다.

상기 전송권을 넘겨주는 프레임은, MAC 헤더만으로 구성되며, 상기 제1 필드는 제1 비트로 설정되는 것이 바람직하다.

상기 전송권을 넘겨주는 프레임은, No-ACK policy를 사용하는 것이 바람직하다.

상기 수신되는 데이터 프레임의 ACK policy가 No-ACK policy인 경우에는 상기 임계시간은 0인 것이 바람직하다.

이하, 첨부된 도면을 참조하여 본 발명의 바람직한 일 실시예를 상세히 설명한다.

IEEE 802.15.3 표준에서는 네 개의 IFS(interframe space)를 정의하고 있는데, minimum interframe space(MIFS), short interframe space(SIFS), backoff interframe space(BIFS), 그리고 retransmission interframe space(RIFS)가 그 것이다.

상기 IFS들(MIFS, SIFS, BIFS, 및 RIFS)의 실제 값은 물리층(Physical layer)에 따라서 결정된다. 예컨대, 2.4 GHz 물리층을 사용하는 경우에, 상기 IFS 들은 다음의 표 1와 같이 정의될 수 있다. 여기서, pPHYMIFSTime은 연속되는 프레임 간의 시간을 의미하고, pPHYSIFSTime은 RX-to-TX 전환 시간(receive-to-transmit turnaround time)을 의미한다. 그리고, pCCADetectTime은 CCA 감지 시간(Clear Channel Assessment detection time)을 의미한다.

Imm-ACK 프레임 및 Dly-ACK 프레임은 ACK을 요구하는 이전 프레임의 전송이 끝난 후 SIFS가 경과한 후에 전송된다. 그리고, MIFS는 No-ACK 또는 Dly-ACK policy를 갖도록 설정된 어떤 프레임과 그와 연속된 프레임 사이에 허용되는 시간으로 사용된다. 한편, CTAP 동안 src DEV가 Imm-ACK을 갖도록 설정된 프레임를 전송한 후, 소정의 타임 아웃 시간 동안 Imm-ACK을 전송받지 못하면 상기 프레임을 재전송한다. RIFS는 이와 같이 하나의 프레임을 보내고 그 프레임을 다시 재전송하는데 까지 소요되는 타임 아웃 시간이다.

IEEE 802.15.3 표준에 따른 MAC 프레임(400)은 도 4에서 도시한 바와 같이, MAC 헤더(MAC header; 500)와 MAC 프레임 바디(MAC frame body; 600)로 구성되는데, 이와 같이 IEEE 802.15.3 표준에서는 시간적으로 앞서는 필드를 우측부터 나타 낸다. MAC 프레임(400)은 데이터 프레임, 컨트롤 프레임, ACK 등과 같이 MAC 헤더를 구비하는 모든 프레임을 가리킨다.

MAC 프레임 바디(600)는 실제 데이터가 기록되는 가변 길이의 Frame payload 필드(610)와, MAC 프레임(400)에 대한 에러를 체크하는 FCS(frame check sequence) 필드(620)로 구성된다.

그리고, MAC 헤더(500)는 Frame control 필드(510)와, 피코넷에 대한 고유의 식별자가 기록되는 PNID 필드(520)와, MAC 프레임을 수신하는 디바이스의 ID가 기록되는 DestID 필드(530)와, MAC 프레임을 송신하는 디바이스의 ID가 기록되는 SrcID 필드(540)와, MSDU를 조각화(fragmentation)하고 조립(assemble)하기 위하여 사용되는 정보가 기록되는 Fragmentation control 필드(550)와, CTA를 구분하기 위하여 PNC(Piconet Coordinator)에 의하여 부여되는 스트림 인덱스가 기록되는 Stream index 필드(560)를 포함할 수 있다.

Frame control 필드(510)는 다시 세부적인 필드로 나뉘어지는데, 프로토콜 버전이 기록되는 Protocol version 필드(511)와, 프레임의 유형(비콘 프레임, ACK 프레임, command 프레임, 데이터 프레임 등)이 기록되는 Frame type 필드(512)와, MAC 프레임에 보안이 적용되었는가 여부가 기록되는 SEC 필드(513)와, 송신할 MAC 프레임에 대한 ACK의 유형(Imm-ACK, No-ACK, Dly-ACK 등)이 기록되는 ACK Policy 필드(514)와, 프레임에 대한 재전송 회수가 기록되는 Retry 필드(515)와, More data 필드(516)와, 예비 필드인 Reserved 필드(517)를 포함할 수 있다.

여기서, More data 필드(516)는 전송될 데이터가 더 존재하는지 여부(즉, 현 재 프레임이 마지막 프레임인지 여부)를 나타내는 표시하는 필드이다. More data 필드(516)는 하나의 비트로서 표현되는데, src DEV가 나머지 CTA 상의 잔여 채널 시간을 사용하지 않고자 하는 경우, 즉 src DEV가 전송하는 마지막 MAC 프레임에 대하여는 0으로 지정되고, 이외의 경우에는 1로 지정된다. 하지만, 이는 하나의 실시예로서 반대로 마지막 MAC 프레임에 대하여 1로, 이외의 경우에 0으로 지정할 수도 있다. 따라서, 본 명세서의 상세한 설명에서는 전자의 예에 따라서 설명할 것이지만, 본 명세서의 특허청구범위에서는, 상기 마지막 MAC 프레임에 대하여 사용되는 비트는 '제1 비트'로, 이후 전송할 프레임이 더 존재하는 경우는 '제2 비트'로 하여 표현할 것이다.

종래의 IEEE 802.15.3 표준에 따르면, More data 필드(516)이 0으로 설정된 MAC 프레임을 수신한 dest DEV는 해당 CTA의 남은 시간에 더 이상 수신할 프레임이 없으므로, 전력 절약 모드(power save mode)로 전환하게 된다. 이와 달리, 본 발명에서는, More data 필드(516)이 0으로 설정된 MAC 프레임을 수신한 dest DEV는 소정의 시간을 대기한 후에, src DEV에 바로 MAC 프레임을 전송할 수 있게 한다. 이와 같이, 본 발명에서는 More data 필드(516)의 사용법을 종래의 IEEE 802.15.3 표준에서 정의된 내용과 달리함으로써, MAC 프로토콜에서 일부 필드의 변경을 가하지 않고서도 양방향 CTA를 지원할 수 있도록 한다. 이하에서, src DEV가 전송권을 갖는 경우를 '모드 1'로, dest DEV가 전송권을 갖는 경우를 '모드 2'로 정의한다. 본 발명에서는 이와 같이 주어진 CTA 동안에 모드 1과 모드 2가 교번하면서 데이터를 전송할 수 있다.

도 5는 본 발명의 일 실시예에 따른 데이터 전송 과정을 도시한 흐름도이다. 여기서, src DEV인 DEV 1(100)은 자신에게 할당된 CTA 동안 dest DEV인 DEV 2(200) 또는 피코넷 내의 다른 디바이스에 데이터를 전송할 수 있다. DEV 1(100)이 DEV 2(200)에 MAC의 상위층 데이터를 전송하고자 하는 상황을 가정한다. MAC의 상위층 데이터는 도 5의 예에서는 TCP 데이터 1 및 TCP 데이터 2에 해당된다.

먼저, DEV 1(100)이 DEV 2(200)에 2개의 데이터 프레임으로 된 TCP 데이터 1을 전송하고자 한다. TCP 데이터 1은 복수의 데이터 프레임으로 나뉘어지므로, 각각의 데이터 프레임을 DEV 2(200)에 전송하여야 한다. DEV 1(100)은 More data 필드가 1로 설정된 데이터 프레임 1을 DEV 2(200)에 전송한다(S1). 만약, 데이터 프레임 1이 Imm-ACK policy를 취한다면, DEV 2(200)는 상기 데이터 프레임 1에 대한 Imm-ACK 1을 전송한다(S2).

이어서, DEV 1(100)은 DEV 2(200)에 More data 필드가 0으로 설정된 데이터 프레임 2를 DEV 2(200)에 전송한다(S3). More data 필드가 0으로 설정된 것은, DEV 1(100)이 DEV 2(200) 또는 피코넷 내의 다른 디바이스에 더 이상 보낼 프레임이 없기 때문이다.

DEV 2(200)는 상기 데이터 프레임 2에 대한 Imm-ACK 2를 전송한다(S4). S10 내지 S40에서 Imm-ACK policy를 이용하는 것으로 하였지만, Dly-ACK policy를 사용할 수도 있다. 만약, Dly-ACK policy를 사용한다면, S20 단계는 생략되고, S40 단계에서 DEV 2(200)는 Dly-ACK을 DEV 1(100)에 전송하게 될 것이다.

DEV 1(100)로부터 More data 필드가 0으로 설정된 데이터 프레임 2를 전송받 은 DEV 2(200)는 Imm-ACK 2를 전송한 때로부터 소정의 임계시간이 경과하면 데이터 전송권을 넘겨받게 된다. 본 발명에서, src DEV인 DEV 1이 전송권을 갖는 상태를 모드 1이라고 정의하면, dest DEV인 DEV 2가 전송권을 넘겨받은 상태를 모드 2라고 정의할 수 있다.

상기 임계시간은 TIFS(Two-way Interframe Space)라고 정의된다. 데이터 프레임 2가 Imm-ACK policy를 취하고 More data 필드가 0으로 설정된 경우, DEV 1(100)더 이상 보낼 데이터가 없다고 하더라도 DEV2는 TIFS 만큼 기다린 후에 데이터 프레임을 전송한다. 그 이유는 DEV 2(200)가 전송한 Imm-ACK 2를 DEV 1(100)이 수신하지 못한 경우, DEV 1(100)이 데이터 프레임 2의 재전송을 시도할 수 있기 때문이다. 따라서, Imm-ACK policy가 사용되는 경우에는, TIFS는 DEV 1(100)이 데이터 프레임을 재전송하는 시간인 RIFS 보다 다소 길도록 선택되어야 한다. 본 발명에서는 TIFS는 RIFS 보다 다소 큰 값, 예를 들어 RIFS+pPHYSIFSTime으로 정의할 수 있다.

다만, 이와 같이 DEV 2(200)가 TIFS 동안 대기하는 것은, More data 필드가 0이고 Imm-ACK policy, 또는 Dly-ACK policy를 취하는 데이터 프레임을 수신하는 경우이고, More data 필드가 0이고, No-ACK policy를 취하는 데이터 프레임을 수신하는 경우에는 SIFS 후 필요한 데이터 프레임을 바로 전송하면 된다. 이 경우에는 DEV 1(100)이 재전송할 가능성이 없으므로, 데이터를 수신한 후 전송하는데 요구되는 RX-to-TX 전환 시간, 즉 SIFS의 경과만을 기다리는 것이다.

이와 같이, DEV 2(200)는 ACK policy에 따라 TIFS 또는 SIFS가 경과한 후에, 현재 DEV 1(100)에 보낼 데이터가 존재할 경우에는 전력 절약 모드로 들어가는 것이 아니라, 준비된 프레임, 예를 들어, 상기 TCP 프레임 1에 대한 TCP 레벨의 ACK 프레임을 DEV 1(100)에 전송한다(S5). 이러한 TCP 레벨의 ACK 프레임은 MAC 단에서 보면 단순히 MAC 데이터로 보이므로 데이터 프레임 3으로 표시한 것이다. 이 경우 TCP 레벨의 ACK 프레임은 그 크기가 작아서 나누어 보낼 필요가 없으므로 하나의 데이터 프레임 3으로 전송되며, 이 때 MAC 헤더의 More data 필드는 0으로 설정된다. 이어서, DEV 1(100)은 데이터 프레임 3에 대한 Imm-ACK 3을 전송한다(S6).

그리고, DEV 1(100)은 수신한 데이터 프레임 3의 More data 필드가 0으로 설정되어 있으므로, 다시 전송권을 넘겨 받게 된다. 따라서, TIFS(데이터 프레임 3의 ACK policy가 Imm-ACK 대신 No-ACK 이었다면, SIFS가 될 것이다) 동안 대기한 후에 다시 데이터 프레임 4를 전송하고(S7), DEV 2(200)로부터 Imm-ACK 4를 수신한다(S8).

이상에서는, 전송권을 넘겨 받은 디바이스에 전송할 데이터가 존재하는 경우를 예로 들었지만, 만약 전송할 데이터가 존재하지 않으면, More data 필드가 0으로 설정되고 MAC 헤더만으로 구성된 프레임(이하, TOKEN 프레임이라고 함)을 전송함으로써 상대 디바이스에게 전송권을 넘겨 준다.

이 후에도 CTA 상의 잔여 시간이 존재하는 동안에는 이상의 같은 과정을 반복하게 된다.

도 6은 본 발명의 일 실시예에 따른 무선 디바이스(DEV)의 구성을 나타내는 블록도이다. 무선 디바이스(100, 200)는 전송권 판단 모듈(110)과, MAC 모듈(120) 과, 상위층 모듈(130)과, PHY 모듈(140)과, 제어 모듈(150)을 포함하여 구성될 수 있다.

전송권 판단 모듈(110)은, 데이터 프레임이 수신된 경우에 MAC 모듈(120)에서 판독된 More data 필드(516)의 값을 전달받아 그 값이 '현재 데이터 프레임이 마지막 데이터임을 나타내는 값', 즉 0인 경우에는 PHY 모듈(140)로부터 데이터 프레임이 수신된 후 소정의 임계시간 동안 채널이 idle 한지를 판단한다. 그리고, 채널이 idle한 상태로 상기 임계시간이 경과하면, 모드가 전환됨을 제어 모듈(150)에 전달한다.

MAC 모듈(120)은 MAC 층(Media Access Control Layer)에서의 동작을 관장한다. 즉, 상위층 모듈(130)로부터 MSDU(도 4의 Frame payload에 해당)를 전달받아 여기에 도 4에 도시한 MAC 헤더(500)를 부착하고 그 결과를 PHY 모듈(140)에 전달한다. 또한, MAC 모듈(120)은 PHY 모듈(140)에 의하여 수신된 데이터 프레임의 MAC 헤더를 판독한 후 MAC 헤더를 제거하고 그 결과를 상위층 모듈(130)에 전달한다. PHY 모듈(140)에 의하여 수신된 프레임이 Imm-ACK과 같이 MAC 헤더만 존재하는 프레임인 경우에는 상위층 모듈(130)로 전달되는 것은 없다. 그리고, MAC 모듈(120)은 MAC 헤더 중 More data 필드(516)의 값을 판독하여 전송권 판단 모듈(110)에 전달한다.

상위층 모듈(130)은 MSDU를 생성하여 MAC 모듈(120)에 전달하고, MAC 모듈(120)로부터 MAC 헤더가 제거된 데이터를 전달받는다. 이러한 상위층 모듈(130)은 LLC 층(Logical Link Layer) 이상의 네트워크 층, 예를 들어 TCP/IP 층을 관장한 다.

PHY 모듈(140)은 물리층(Physical Layer)에서의 동작을 관장한다. 즉, MAC 모듈(120)로부터 MPDU(MAC Protocol Data Unit)를 전달받아 PPDU(Packet Protocol Data Unit)를 생성하고 이를 포함하는 무선 신호를 생성하여 전송한다. 또한, 무선 매체를 통하여 전달되는 신호를 수신하여 가공한 후 이를 MAC 모듈(120)에 전달한다. PHY 모듈(140)은 다시 세분화하여 베이스밴드 프로세서(base band processor)와 RF(radio frequency) 모듈로 세분화 될 수 있다.

제어 모듈(150)은 무선 디바이스(100, 200) 내의 다른 모듈의 동작을 제어하는데, 중앙 처리 유닛(CPU), 마이콤(Microcomputer) 등으로 구현될 수 있다. 제어 모듈(150)은 전송권 판단 모듈(110)에 의하여 전송권이 전환된 것으로 판단되면, 상기 데이터 프레임을 전송한 타 디바이스로 전송할 데이터, 즉 MSDU가 존재하는지를 판단하여, 존재하면 MAC 모듈(120)로 하여금 상기 MSDU에 MAC 헤더를 생성/부가하여 데이터 프레임을 생성한다. 이 때, 상기 생성된 데이터 프레임이 전송할 마지막 프레임이면 More data 필드(516)는 0으로 설정되고, 마지막 프레임이 아니면 1로 설정된다. 그리고, PHY 모듈(140)을 통하여 생성된 데이터 프레임을 상기 타 디바이스에 전송한다.

한편, 제어 모듈(150)은 상기 전송권이 전환된 것으로 판단되고, 상기 전송할 데이터가 존재하지 않으면, 상기 타 디바이스에 전송권을 넘겨주는 프레임, 즉 TOKEN 프레임을 전송하도록 상기 MAC 모듈 및 PHY 모듈을 제어한다.

지금까지의 설명에서, "모듈(module)"은 소프트웨어 구성요소(software component) 또는 FPGA(field-programmable gate array) 또는 ASIC(application-specific integrated circuit)과 같은 하드웨어 구성요소(hardware component)를 의미하며 특정한 기능을 수행한다. 그렇지만 모듈은 소프트웨어 또는 하드웨어에 한정되는 의미는 아니다. 모듈은 어드레싱(addressing)할 수 있는 저장 매체에 있도록 구성될 수도 있고 하나 또는 그 이상의 프로세서들을 실행시키도록 구성될 수도 있다. 모듈들 안에서 제공되는 기능은 더 세분화된 모듈에 의하여 구현될 수 있으며, 복수의 모듈을 합하여 특정한 기능을 수행하는 것으로 구현할 수도 있다. 뿐만 아니라, 구성요소들 및 모듈들은 시스템 내의 하나 또는 그 이상의 컴퓨터들을 실행시키도록 구현될 수도 있다.

도 7은 본 발명의 전체 동작을 설명하는 흐름도이다.

먼저, DEV 1(100)(100)은 채널 시간을 요청하는 커맨드 프레임, 즉 channel time request 프레임을 생성하여 PNC에 전송한다. PNC는 상기 전송 받은 커맨드 프레임에 존재하는 정보를 이용하여 비콘 프레임을 생성하고 피코넷의 멤버인 DEV들에게 비콘 프레임을 브로드캐스팅한다. 이 때, src DEV인 DEV 1(100)(100) 및 dest DEV인 DEV 2(200)도 상기 비콘 프레임을 수신하게 된다(S10).

상기 비콘 프레임에는 도 1에서 도시한 바와 같이 적어도 하나 이상의 CTA 블록들이 존재하며, CTA 블록에는 예를 들어, CTA 시작시간, CTA 지속시간, CTA 동안 데이터를 송신할 src DEV(DEV 1(100))과 수신할 dest DEV(DEV 2(200))의 ID등이 포함된다.

이 후, DEV 1(100)와 DEV 2(200)가 통신할 CTA의 시작시간이 되면(S15의 예 ), DEV 1(100)은 DEV 2(200)에 데이터 프레임을 전송한다(S25, S65). 이 때, 상기 전송되는 프레임이 마지막 프레임이 아니면(S20의 아니오), 데이터 프레임의 MAC 헤더(500)에 존재하는 More data 필드(516)를 1로 설정하여 데이터 프레임을 전송하고(S65), 다시 다음 데이터 프레임을 전송하기 위하여 S20으로 돌아간다.

전송되는 프레임이 마지막 프레임이면(S20의 예), More data 필드(516)를 0으로 설정하여 데이터 프레임을 전송하고(S25), S26 단계로 진행한다.

한편, DEV 1(100)으로부터 More data 필드가 0으로 설정된 데이터 프레임을 수신한 DEV 2(200)는, 상기 수신된 데이터 프레임의 ACK policy를 체크하여 No-ACK policy가 아니면(S26의 아니오), DEV 1(100)에 ACK(Imm-ACK, 또는 Dly-ACK)를 전송하고(S27), ACK를 전송한 이후로 TIFS 동안 대기하며 채널이 idle 한지를 체크한다(S30). 그리고, 상기 채널이 idle 한 상태로 상기 TIFS이 경과하면 비로소 DEV 2(200)는 DEV 1(100)에 대한 데이터 전송권을 갖게 된다. 만약, DEV 2(200)가 ACK을 전송하고 TIFS 시간만큼 대기하는 동안 DEV 1(100)으로부터 데이터 프레임의 재전송이 있다면, 이에 대하여 ACK을 재전송한다.

S26 단계의 판단 결과, No-ACK policy이라면(S26의 예), DEV 2(200)는 S25단계에서의 데이터 프레임을 수신한 후 DEV 1(100)에 대한 데이터 전송권을 갖는다. 여기서, DEV 2(200)가 데이터 프레임 수신 후 다른 데이터 프레임 전송시까지는 적어도 SIFS 시간만큼 소요된다.

데이터 전송권을 갖게 된 DEV 2(200)는 비로소 DEV 1(100)에 데이터를 전송할 수 있는데, 만약, 전송할 데이터가 없다면(S35의 아니오), More data 필드가 0 으로 설정된 MAC 헤더만으로 이루어진 TOKEN 프레임을 DEV 1에 전송한다(S50). 이는 DEV 2(200)가 DEV 1(100)에 전송할 데이터가 없음을 알리는 것이다. TOKEN 프레임에 대한 ACK policy는 ACK을 필요로 하는 것으로 할 수도 있지만, 채널 내 트래픽 감소를 위하여 No-ACK으로 하는 것이 바람직하다. TOKEN 프레임이 No-ACK policy를 갖는 경우에는, TOKEN 프레임을 수신한 후에 TIFS를 기다릴 필요 없이 바로 전송권이 넘어가게 된다.

전송권을 넘겨 받은 DEV 1(100)도 마찬가지로 전송할 데이터가 존재하는가를 판단하여, 존재하면(S55의 예) S20 단계로 돌아가고, 존재하지 않으면 More data 필드가 0으로 설정된 TOKEN 프레임을 전송하고(S60), S35 단계로 돌아간다.

S35 단계에서, DEV 2(200)가 DEV 1(100)에 전송할 데이터가 존재하면(S35의 예), DEV 1(100)은 DEV 2(200)에 데이터 프레임을 전송한다(S45, S70). 이 때, 상기 전송되는 프레임이 마지막 프레임이 아니면(S40의 아니오), More data 필드(516)를 1로 설정하여 데이터 프레임을 전송하고(S70), 다시 다음 데이터 프레임을 전송하기 위하여 S35 단계로 돌아간다.

전송되는 프레임이 마지막 프레임이면(S40의 예), More data 필드(516)를 0으로 설정하여 데이터 프레임을 DEV 1(200)에 전송한다(S45). 이어서, DEV 1(100)는, 상기 전송 받은 데이터 프레임의 More data 필드(516)이 0으로 설정되었으로 전송권이 넘어옴을 알게 된다. DEV 1(100)는 상기 전송받은 데이터 프레임의 ACK policy를 체크하여 No-ACK policy가 아니면(S75의 아니오), DEV 2(200)에 ACK(Imm-ACK, 또는 Dly-ACK)를 전송하고(S76), 상기 ACK를 전송한 이후로 TIFS 동안 대기하 며 채널이 idle 한지를 체크한다(S77). 그리고, 상기 채널이 idle 한 상태로 상기 TIFS 시간이 경과한 후에는 S55 단계로 진행한다.

S75 단계의 판단 결과, No-ACK policy이라면(S75의 예), DEV 1(100)는 S45단계에서의 데이터 프레임을 수신한 후에는 다시 데이터 전송권을 넘겨 받는다. 이 후에는 S55 단계로 진행한다.

이상의 S10 내지 S78 단계는 해당 CTA의 시작 시간부터 종료 시간까지만 진행되며, 상기 단계 중 임의의 단계에서 CTA의 종료 시간이 되면 도 7에서의 과정은 종료된다.

이하에서는, 도 8 및 도 9를 참조하여 종래 기술에 따라 CTA에서 단방향 전송을 하는 경우와 본 발명에 따라 CTA에서 양방향 전송 적용 경우에 전송 효율의 차이를 비교하고자 한다.

도 8은 종래의 기술에 따라 단방향 전송을 하는 경우에 대하여 슈퍼프레임(900) 구조 및 데이터 전송 과정을 설명하기 위한 도면이다. 두 개의 DEV, 즉 DEV 1(100) 및 DEV 2(200)가 피코넷에 존재하고, TCP/IP를 이용하여 DEV 1(100)이 DEV 2(200)로 스트림을 전송하고자 한다. 그러면, DEV 1(100)에서 DEV 2(200)로 데이터 프레임이 전송되고, 이에 대한 ACK 프레임이 DEV 2(200)에서 DEV 1(100)으로 전송될 것이다. 데이터 프레임 전송시 MAC 헤더에 설정되는 ACK policy는 Imm-ACK policy라고 하고, 슈퍼프레임 duration은 10ms, CAP는 1ms라고 가정한다. 그리고, MAC header의 전송률은 22Mbps, 프레임 payload의 전송률은 55Mbps라고 한다.

우선 DEV 1(100)과 DEV 2(200) 모두가 rate factor를 1로 한 슈퍼레이트 CTA(super-rate CTA)를 요청하였다고 한다면, 슈퍼프레임(900)은 도 8과 같이 나타날 것이다. 도 8에서와 같이 CTA IE와 BSID IE 외에 다른 IE(information element)들은 갖고 있지 않다고 가정한다.

비콘(910)은 10 byte의 MAC header, 21 byte의 피코넷 sync parameters, 16 byte의 CTA IE(본 예에서는 두 개의 CTA 정보를 갖고 있으므로), 20 byte의 BSID IE(BSID의 크기를 10 bytes로 가정함)으로 구성된다. 표 2와 같은 계산 과정의 결과 상기와 같은 비콘을 전송하는 데는 약 0.012 ms가 소요된다.

헤더 전송 시간 : (10×8bits)×1000ms / 22Mbps = 0.0036ms, 페이로드 전송 시간 : (21+16+20)×8bits×1000ms / 55Mbps = 0.0082ms

CTA1(930)과 CTA2(940)의 duration은 각각 DEV 1(100)과 DEV 2(200)가 PNC에 요청한 TU(Time Unit)의 크기와 Desired number of TUs에 따라 달라질 것이다. TU는 지정한 ACK policy에 따라 최소한 한 프레임은 전송할 수 있도록 하여야 한다. 비콘 전송 시간과 CAP(920)를 제외한 나머지 시간을 모두 각 DEV에 할당해 준다고 하면, DEV 1(100), DEV 2(200) 모두 rate factor가 1인 슈퍼레이트 CTA를 요청하였다고 가정하였기 때문에, 도 8에서와 같이 src DEV가 DEV 1(100)이고 dest DEV가 DEV 2(200)인 CTA1(930)과, src DEV가 DEV 2(200)이고 dest DEV가 DEV 1(100)인 CTA2(940)가 배정될 것이다. CTA1(930)과 CTA2(940)의 duration은 각각의 DEV가 요청한 TU 및 PNC의 channel time allocation 알고리즘에 따라 달라질 수 있다.

CTA1(930)이 시작하는 시간이 되면 먼저 DEV 1(100)이 DEV 2(200)로 데이터 프레임 1(950)을 전송한다. 이 때 데이터 프레임 1(950)의 페이로드는 TCP/IP의 데 이터 프레임이다. 최대 프레임 길이가 2048 bytes(MAC 헤더는 제외)이므로 데이터 프레임 1(950)을 2048 bytes라고 하면, 데이터 프레임 1(950)의 전송시간은 다음의 표 3에서와 같이 0.3014ms가 된다.

(MAC 헤더 전송시간) + (2048×8bits)×1000ms / 55Mbps =0.0036ms+0.2979ms =0.3014ms

ACK 1(960)은 DEV 2(200)에서 DEV 1(100)으로 보내는 ACK 프레임이다. 이는 MAC 층에서 MAC의 ACK policy에 따라 전송되는 것이다. IEEE 802.15.3에서 ACK 프레임은 MAC 헤더만으로만 이루어져 있으므로 ACK 프레임을 전송하는 데는 0.0036 ms가 걸릴 것이다.

본 예에서 MAC 층의 상위층에서는 TCP/IP를 이용하여 전송하므로, DEV 1(100)은 DEV 2(200)로부터 TCP/IP 레벨의 ACK 프레임을 받지 못하면 더 이상 새로운 프레임을 전송할 수 없다. DEV 1(100)이 DEV 2(200)로 TCP/IP를 이용하여 프레임을 전송하면, DEV 2(200)는 이에 대한 ACK 프레임을 보내야 한다. 이는 MAC 층에서 보내는 ACK(예를 들어, 상기 Imm-ACK)와는 별도로, MAC 층의 상위층에서 전송되는 것이기 때문에 MAC 층에서 보면 다른 데이터 프레임과 마찬가지로 처리가 된다. 도 8에서 데이터 프레임 2는 DEV 2(200)가 DEV 1(100)으로 전송하는 TCP/IP 레벨의 ACK 프레임을 나타낸다. 이와 같이, DEV 2(200)가 DEV 1(100)으로 데이터 프레임 2를 보내고자 하여도 자신이 src로 지정된 채널 시간이 될 때까지 기다려야 한다. 따라서 CTA2(940)가 시작하는 시간이 되어야만 데이터 프레임 2(970)를 전송할 수 있다. ACK 2(980)는 MAC 층의 ACK policy에 따라 전송되는 MAC 층 레벨의 ACK 프레임이다.

이상에서 살펴 본 것과 같이, 기존의 IEEE 802.15.3의 CTA 방식을 사용할 경우에는 10ms이라는 슈퍼프레임 동안에 DEV 1(100)에서 DEV 2(200)로 2048 bytes 크기의 프레임 하나가 전송되고, 반대로 DEV 2(200)로부터 DEV 1(100)으로도 2048 bytes의 프레임 하나만이 전송된다.

도 9은 주어진 CTA 내에서 양방향 전송을 지원하는 본 발명에 따른 데이터 전송 과정을 설명하기 위한 도면이다. 도 8에서와 마찬가지로, 비콘 전송시간과 CAP(920)를 제외한 나머지 시간을 모두 DEV들에게 할당한다고 가정한다. 그리고, 데이터 프레임 1(950)은 DEV 1(100)에서 DEV 2(200)로 보내는 TCP/IP 데이터 프레임이고, 데이터 프레임 2(970)는 DEV 2(200)에서 DEV 1(100)로 보내는 TCP/IP 레벨의 ACK 프레임이다. 데이터 프레임 2(970)가 전송되기까지 처리 시간(processing time)을 고려하여 중간에 TOKEN 프레임(990) 하나가 전송된다고 가정하면, DEV 1(100)에서 DEV 2(200)로 TCP/IP 데이터 프레임을 하나 보내고 이에 대하여 TCP/IP 레벨의 ACK 프레임을 받는 것까지 걸리는 시간(A)을 계산해 보면 표 4와 같다.

A = 데이터 프레임 1 전송 시간 + SIFS + ACK 1 전송 시간 + TIFS + TOKEN 프레임 전송 시간 + SIFS + 데이터 프레임 2 전송 시간 + SIFS + ACK 2 전송 시간 + SIFS = 0.3015 ms + 0.01 ms + 0.0036 ms + 0.03ms + 0.0036 ms + 0.01 ms + 0.3015 ms + 0.01 ms + 0.0036 ms +0.01 ms = 0.6838 ms

따라서 10 ms의 슈퍼프레임(900) 동안 비콘(910) 전송 시간과 CAP(920)를 제외한 값을 상기 시간(A)로 나누면 다음의 표 5에서의 결과와 같다.

(10 - 0.012 - 0.01 - 1) / 0.6838 ≒ 13개

이 결과에 따르면, 단위 슈퍼프레임 동안, DEV 1(100)은 DEV 2(200)로 2048 bytes 짜리 프레임을 13개 보낼 수 있고, 마찬가지로 이 시간 동안에 DEV 2(200)도 DEV 1(100)으로 2048 bytes의 프레임 13개를 보낼 수 있다. 물론, 앞에서 CTA rate factor를 1을 초과하는 수로 지정하여 PNC에 채널 시간을 요청한다면 도 8에서 보다는 많은 양의 데이터를 전송할 수 있을 것이다. 그러나 rate factor나 PNC의 채널 시간 할당 알고리즘에 따라 채널 시간의 배치가 달라 질 수 있고, 또한 항상 채널 시간을 최대로 사용할 수 있다는 보장이 없기 때문에, 본 발명에서와 같이 양방향 전송을 지원하는 채널 시간을 이용하는 것이 더 효율적이라고 할 수 있다.

이상 첨부된 도면을 참조하여 본 발명의 실시예를 설명하였지만, 본 발명이 속하는 기술분야의 통상의 지식을 가진 자는 본 발명이 그 기술적 사상이나 필수적인 특징을 변경하지 않고서 다른 구체적인 형태로 실시될 수 있다는 것을 이해할 수 있을 것이다. 그러므로 이상에서 기술한 실시예들은 모든 면에서 예시적인 것이며 한정적이 아닌 것으로 이해해야만 한다. 본 발명의 범위는 상기 상세한 설명보다는 후술하는 특허청구의 범위에 의하여 나타내어지며, 특허청구의 범위의 의미 및 범위 그리고 그 균등 개념으로부터 도출되는 모든 변경 또는 변형된 형태가 본 발명의 범위에 포함되는 것으로 해석되어야 한다.

본 발명에 따르면, 기존의 IEEE 802.15.3 표준에 따른 MAC 프로토콜을 변화시키지 않고도 주어진 CTA 동안 두개의 디바이스가 양방향으로 통신할 수 있게 된다.

본 발명에 따르면, 피코넷 상의 디바이스 들이, 주어진 CTA를 보다 효율적으로 이용함으로써 피코넷 전체의 쓰루풋(throughput)을 향상시키는 효과가 있다.

Claims (14)

1. 무선 매체를 통하여 MAC 프레임을 수신하는 PHY 모듈;

   상기 수신된 MAC 프레임의 제1 필드의 값을 판독하는데, 상기 제1 필드는 전송될 데이터가 더 존재하는지 여부를 나타내는 필드인, MAC 모듈;

   상기 제1 필드의 값이 전송될 데이터가 더 존재하지 않음을 나타내는 값이고 상기 MAC 프레임이 수신된 후 소정의 임계시간 동안 채널이 비어 있으면, 전송권이 전환된 것으로 판단하는, 전송권 판단 모듈; 및

   상기 전송권이 전환된 것으로 판단되고, 상기 수신된 MAC 프레임을 전송한 디바이스로 전송할 데이터가 존재하면, 상기 전송할 데이터를 포함하는 MAC 프레임을 전송하도록 상기 MAC 모듈 및 상기 PHY 모듈을 제어하는 제어 모듈을 포함하는, 무선 디바이스.
2. 제1항에 있어서, 상기 제1 필드는

   IEEE 802.15.3의 MAC 헤더에 존재하는 More data 필드인, 무선 디바이스.
3. 제1항에 있어서, 상기 임계 시간은

   적어도 IEEE 802.15.3의 retransmission interframe space(RIFS) 보다는 큰 것을 특징으로 하는, 무선 디바이스.
4. 제1항에 있어서, 상기 제어 모듈은

   상기 전송권이 전환된 것으로 판단되고, 상기 수신된 MAC 프레임을 전송한 디바이스로 전송할 데이터가 존재하지 않으면, 상기 디바이스에 전송권을 넘겨주는 프레임을 전송하도록 상기 MAC 모듈 및 PHY 모듈을 제어하는, 무선 디바이스.
5. 제4항에 있어서, 상기 전송권을 넘겨주는 프레임은

   MAC 헤더만으로 구성되며, 상기 제1 필드는 1 비트로 설정되는, 무선 디바이스.
6. 제5항에 있어서, 상기 전송권을 넘겨주는 프레임은

   No-ACK policy를 사용하는, 무선 디바이스.
7. 제1항에 있어서,

   상기 수신되는 데이터 프레임의 ACK policy가 No-ACK policy인 경우에는 상기 임계시간은 0인 것을 특징으로 하는, 무선 디바이스.
8. (a) 무선 매체를 통하여 MAC 프레임을 수신하는 단계;

   (b) 상기 수신되는 MAC 프레임의 제1 필드의 값을 판독하는 단계로서, 상기 제1 필드는 전송될 데이터가 더 존재하는지 여부를 나타내는, 단계;

   (c) 상기 필드의 값이 전송될 데이터가 더 존재하지 않음을 나타내는 값이고 상기 MAC 프레임이 수신된 후 소정의 임계시간 동안 채널이 비어 있으면, 전송권이 전환된 것으로 판단하는 단계; 및

   (d) 상기 전송권이 전환된 것으로 판단되고, 상기 수신된 MAC 프레임을 전송한 디바이스로 전송할 데이터가 존재하면, 상기 전송할 데이터를 포함하는 MAC 프레임을 상기 디바이스에 전송하는 단계를 포함하는, 할당된 시간 동안 양방향으로 데이터를 송수신하는 방법.
9. 제8항에 있어서, 상기 제1 필드는

   IEEE 802.15.3의 MAC 헤더에 존재하는 More data 필드인, 할당된 시간 동안 양방향으로 데이터를 송수신하는 방법.
10. 제8항에 있어서, 상기 임계 시간은

    적어도 IEEE 802.15.3의 retransmission interframe space(RIFS) 보다는 큰 것을 특징으로 하는, 할당된 시간 동안 양방향으로 데이터를 송수신하는 방법.
11. 제8항에 있어서,

    (e) 상기 전송권이 전환된 것으로 판단되고, 상기 수신된 MAC 프레임을 전송한 디바이스로 전송할 데이터가 존재하지 않으면, 상기 디바이스에 전송권을 넘겨주는 프레임을 전송하는 단계를 더 포함하는, 할당된 시간 동안 양방향으로 데이터를 송수신하는 방법.
12. 제11항에 있어서, 상기 전송권을 넘겨주는 프레임은

    MAC 헤더만으로 구성되며, 상기 제1 필드는 1 비트로 설정되는, 할당된 시간 동안 양방향으로 데이터를 송수신하는 방법.
13. 제12항에 있어서, 상기 전송권을 넘겨주는 프레임은

    No-ACK policy를 사용하는, 할당된 시간 동안 양방향으로 데이터를 송수신하는 방법.
14. 제8항에 있어서,

    상기 수신되는 데이터 프레임의 ACK policy가 No-ACK policy인 경우에는 상기 임계시간은 0인 것을 특징으로 하는, 할당된 시간 동안 양방향으로 데이터를 송수신하는 방법.

Images