KR20050040692A - 무선 ｐａｎ상에서 디바이스 간에 효율적으로 데이터를송수신하는 방법 - Google Patents

무선 ｐａｎ상에서 디바이스 간에 효율적으로 데이터를송수신하는 방법 Download PDF

Info

Publication number
KR20050040692A
KR20050040692A KR1020040049655A KR20040049655A KR20050040692A KR 20050040692 A KR20050040692 A KR 20050040692A KR 1020040049655 A KR1020040049655 A KR 1020040049655A KR 20040049655 A KR20040049655 A KR 20040049655A KR 20050040692 A KR20050040692 A KR 20050040692A
Authority
KR
South Korea
Prior art keywords
frame
data
channel time
transmitting
ack
Prior art date
Application number
KR1020040049655A
Other languages
English (en)
Other versions
KR100772855B1 (ko
Inventor
성현아
배대규
홍진우
Original Assignee
삼성전자주식회사
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 삼성전자주식회사 filed Critical 삼성전자주식회사
Priority to CN2004800320589A priority Critical patent/CN1875575B/zh
Priority to JP2006537872A priority patent/JP2007510350A/ja
Priority to PCT/KR2004/002663 priority patent/WO2005041488A1/en
Priority to US10/970,467 priority patent/US20050094657A1/en
Priority to EP04256557A priority patent/EP1528733A3/en
Publication of KR20050040692A publication Critical patent/KR20050040692A/ko
Application granted granted Critical
Publication of KR100772855B1 publication Critical patent/KR100772855B1/ko

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/324—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the data link layer [OSI layer 2], e.g. HDLC
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
    • H04L1/1607—Details of the supervisory signal
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/22—Parsing or analysis of headers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/80—Services using short range communication, e.g. near-field communication [NFC], radio-frequency identification [RFID] or low energy communication

Abstract

본 발명은 무선 PAN(Wireless Personal Area Network) 상에서 동작하는 디바이스의 MAC을 개선함으로써 할당된 채널 시간 동안 양방향으로 데이터를 송수신하는 방법 및 장치에 관한 것이다.
본 발명에 따른 데이터 송수신 방법은, 데이터 송신 방향이 단방향인지 양방향인지를 결정하는 방향 정보를 포함하는 채널 시간 요청 프레임을 생성하여 채널 시간 할당을 담당하는 디바이스에 전송하는 제1단계; 상기 채널 시간 요청 프레임에 존재하는 정보를 이용하여 상기 방향 정보가 포함된 채널 시간 할당 정보를 갖는 프레임을 생성하고 상기 생성된 프레임을 브로드캐스팅하는 제2단계; 및 상기 비콘 프레임에서 소스 디바이스로 지정된 제1 디바이스와 목적지 디바이스로 지정된 제2 디바이스 간에 소정의 채널 시간 동안 상기 방향 정보에 맞게 데이터를 송수신하는 제3단계로 이루어진다.
본 발명에 따르면, TCP/IP와 같이 상호 프레임을 주고 받아야 하는 프로토콜에 대해서 전송효율을 향상시킬 수 있다.

Description

무선 ＰＡＮ상에서 디바이스 간에 효율적으로 데이터를 송수신하는 방법{Method for Exchanging Data between Devices on Wireless Personal Area Network}
본 발명은 무선 네트워크에서 디바이스 간에 효율적으로 통신하는 방법 및 장치에 관한 것으로, 보다 상세하게는 무선 PAN(Wireless Personal Area Network) 상에서 동작하는 디바이스의 MAC(Media Access Control)을 개선함으로써 할당된 채널 시간 동안 양방향으로 데이터를 송수신하는 방법 및 장치에 관한 것이다.
무선 디지털 펄스라고도 알려져 있는 UWB(Ultra wideband)는 단거리 구간에서 저전력으로 넓은 스펙트럼 주파수를 통해 많은 양의 디지털 데이터를 전송하기 위한 무선 기술이며, 미국 국방부가 군사적 목적으로 개발한 무선 기술이다. 이러한 UWB에 관한 표준화는 현재 IEEE 802.15.3, 즉 무선 PAN 규격 제정을 위한 워킹 그룹(Working Group)에서 진행되고 있다. IEEE 802.15.3에는 PHY와 MAC에 관해서 다루고 있는데, 현재 업계에서는 이 중에서도 MAC의 개선 방안에 대한 활발한 연구를 진행하고 있다.
802.15.3 MAC의 특징은 무선 네트워크의 형성이 신속하다는 것이다. 그리고, AP(Access Point) 기반이 아니라 PNC(Piconet Coordinator)를 중심으로 한 피코넷이라고 하는 애드혹 네트워크(Ad Hoc Network)를 기반으로 한다. 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에 해당하는 횟수 이상 연속해서 비콘을 놓치면 사용할 수 없도록 하고 있다. 이와 같이, 802.15.3 MAC은 QoS(Quality of Service)를 보장할 수 있는 TDMA 기반으로 구성되어 있어 특히 홈네트워크 상에서의 멀티미디어 오디오/비디오 스트리밍(A/V Streaming)에 적합하다. 그러나, MAC에 있어서 QoS뿐 아니라 쓰루풋(Throughput)을 효과적으로 사용하기 위해서는 여전히 개선의 여지가 있다.
802.15.3 MAC에서는 데이터 전송 방식으로 두 가지가 있다. 첫번째는 등시적 데이터(isochronous 데이터)를 전송하는 방식이고 두번째는 비동기적 데이터(asynchronous data)를 전송하는 방식이다.
등시적 데이터를 전송하기 위해서는 도 2에서 보는 바와 같이, MLME-CREATE-STREAM.request 및 MLME-CREATE-STREAM.confirm을 이용해 우선 PNC로부터 채널 시간(channel time)을 할당 받은 다음, MAC-ISOCH-DATA.request 및 MAC-ISOCH-DATA.confirm을 이용하여 상기 할당된 채널 시간 동안 실제로 데이터를 전송한다. 할당된 채널 시간은 비콘을 해석함으로써 알 수 있으며, 이 정보를 이용하여 피코넷을 구성하는 디바이스(이하 ＇DEV＇라 한다)는 통신이 시작될 시간과 끝날 시간을 알 수 있다. 이 때 할당된 채널 시간에는 src DEV(소스 디바이스)와 dest DEV(목적지 디바이스)가 지정되어 있다. 할당된 채널 시간에 데이터를 송신하는 DEV는 반드시 src DEV이어야 하지만, 데이터를 수신하는 DEV는 반드시 CTA 정보에서 지정한 dest DEV일 필요는 없다. 다만, 상기 데이터를 수신할 수 있는 DEV는 ＇Always AWAKE bit＇ 또는＇listen to source bit＇이 1로 세팅되어 있는 DEV만이다.
한편, 비동기적 데이터를 전송하기 위해서는 도 3에서 보는 바와 같이, 송신할 데이터가 MAC-ASYNC-DATA.request를 통하여 MAC 층으로 도착하면, src DEV는 PNC에게 channel time request command 프레임을 보낸다. 이후 src DEV가 요청한 채널 시간이 할당되었다는 것을 비콘을 통해 알게 되면 그 채널 시간 동안 데이터를 송신한다. 상기 등시적 데이터 전송의 경우와 마찬가지로 할당된 채널 시간에 대하여는 src DEV 및 dest DEV 쌍이 지정되어 있으며, 할당된 채널 시간 동안에는 지정된 src DEV만이 데이터를 송신할 수 있다. 이외에, 비동기적 데이터를 보내는 또 다른 방법으로는 CAP(Contention Access Period)에서 백오프 알고리즘(backoff algorithm)를 이용하여 프레임을 보내는 방법도 있다.
TCP/IP의 경우 데이터 전송의 확실성을 보장하기 위해 DEV1에서 프레임을 전송하면 DEV2에서는 전송받은 프레임에 대한 ACK 프레임(도 2, 도 3에서의 Imm-ACK 프레임과 달리 TCP/IP 레벨의 ACK 프레임을 의미함)을 보낸다. 이러한 메커니즘을 갖는 TCP/IP에 802.15.3 MAC에서 제공되는 데이터 전송 메커니즘을 그대로 사용하는 경우에 발생하는 문제점을 구체적으로 살펴보면 다음과 같다.
첫번째로, 등시적으로 TCP/IP 데이터를 전송하는 경우를 살펴 보면, 먼저 DEV1은 DEV2와 연결(connection)을 확립하기 위한 프레임을 보낼 것이다. 그러기 위해 우선 PNC에게 MLME-CREATE-STREAM.request를 보냄으로써 src DEV가 DEV1, dest DEV가 DEV2인 채널 시간 할당을 요청한다. PNC가 채널 시간을 할당하여 그 정보를 비콘에 실어서 보내면 DEV1은 비콘 정보를 읽어 지정된 시간에 상기 프레임을 DEV2에게 전송한다. DEV2는 그에 대한 응답 프레임을 보내기 위해 src DEV가 DEV2이고, dest DEV가 DEV1인 채널 시간의 할당을 요청한다. 그리고, 마찬가지로 PNC가 채널 시간을 할당하고 이에 관한 정보를 비콘에 실어 보내면, DEV2는 비콘 정보를 읽어 지정된 시간에 상기 응답 프레임을 DEV1에게 전송한다. MLME-TERMINATE-STREAM.request를 전달받기 전까지는 채널 시간이 계속 할당되기 때문에 그 다음부터는 DEV1과 DEV2가 서로 주고 받는 데이터 및 ACK 프레임은 비콘의 채널 시간 정보에 따라 src DEV 및 dest DEV 쌍에 할당된 시간에 보내지게 될 것이다. 그러나, TCP/IP의 특성상 송신자(sender)는 데이터 프레임을 보낸 후, ACK 프레임을 받기 전까지는 다른 프레임을 전송하지 않는다. 그런데, 802.15.3 MAC에서는 비콘에서 알려 주는 채널 시간 할당의 src DEV만이 그 채널 시간의 송신자가 될 수 있다. 따라서 DEV2가 TCP/IP 레벨의 ACK 프레임을 보내려면, src DEV가 DEV2인 채널 시간이 될 때까지 기다렸다가 ACK 프레임을 보내야 한다. 결국, DEV1가 데이터를 보낸 후 DEV1 및 DEV2에 할당된 시간이 남는다고 하더라도 DEV1은 그 남는 시간을 이용하여 DEV2로부터 ACK를 받을 수는 없으므로 채널 시간의 낭비가 발생하는 것이다.
두번째로, 비동기적으로 TCP/IP 프레임을 전송하는 경우를 살펴 본다. 우선, CAP에 비동기적 데이터를 보내는 경우를 보면, PNC가 CAP를 슈퍼프레임에 할당할 수도 있고, 할당하지 않을 수도 있다. 뿐만 아니라, 만약 할당된 CAP가 있다고 하더라도 PNC가 설정한 기준에 따라서 그 구간 동안에 비동기적 데이터를 보낼 수 있는지 없는지가 결정되기 때문에, CAP를 이용하여 TCP/IP 프레임을 보내는 방법으로는 확실한 전송을 보장할 수 없다. 다음으로, 채널 시간 할당을 이용하여 비동기적 데이터를 보내려면 상기한 바와 같이 MAC-ASYNCH-DATA.request를 이용하게 된다. 그러나 도 3에 나타낸 바와 같이, 매번 channel time request command를 PNC에 보내서 채널 시간을 할당 받은 후에 데이터 프레임을 전송하여야 하므로 계속적으로 데이터를 전달해야 한다면 대역폭(bandwidth)의 낭비가 아닐 수 없다. 또한 채널 시간 할당을 요청하였다 하더라도 요청한 시간이 언제 할당될지는 보장이 되지 않아서 한 번 데이터 프레임을 보낼 때마다 최소 다음 슈퍼프레임까지 기다려야 하므로 시간 지연이 매번 발생하게 될 것이다.
상기한 문제점은 TCP/IP에서 뿐만이 아니라, 두 DEV가 서로 데이터를 주고 받는 프로토콜이 802.15.3 MAC의 상위 층에서 구동되는 경우라면 마찬가지로 발생할 수 있다.
따라서 본 발명은 상기한 문제점을 감안하여 창안된 것으로, 802.15.3 MAC을 개선하여 상위 프로토콜에서의 통신이 효율적으로 이루어질 수 있도록 하는 것을 목적으로 한다. 이를 위하여 802.15.3에서 CTA를 단방향 전송이 아닌 양방향 전송에 사용하는 방법을 제공하고자 한다.
상기한 목적을 달성하기 위하여, 본 발명에 따른 무선 PAN상에서 디바이스간에 데이터를 송수신하는 방법은, 데이터 송신 방향이 단방향인지 양방향인지를 결정하는 방향 정보를 포함하는 채널 시간 요청 프레임을 생성하여 채널 시간 할당을 담당하는 디바이스에 전송하는 제1단계; 상기 채널 시간 요청 프레임에 존재하는 정보를 이용하여 상기 방향 정보가 포함된 채널 시간 할당 정보를 갖는 프레임을 생성하고 상기 생성된 프레임을 브로드캐스팅하는 제2단계; 및 상기 비콘 프레임에서 소스 디바이스로 지정된 제1 디바이스와 목적지 디바이스로 지정된 제2 디바이스 간에 소정의 채널 시간 동안 상기 방향 정보에 맞게 데이터를 송수신하는 제3단계를 포함하는 것을 특징으로 한다.
상기 채널 시간 요청 프레임은 IEEE 802.15.3에서 규정하는 channel time request command 프레임인 것이 바람직하다.
그리고, 상기 채널 시간 할당을 담당하는 디바이스는 IEEE 802.15.3에서 규정하는 피코넷 코디네이터(PNC)인 것이 바람직하다.
또한, 상기 채널 시간 할당 정보를 갖는 프레임은 IEEE 802.15.3에서 규정하는 비콘 프레임인 것이 바람직하다.
상기 제3단계는 상기 제1 디바이스가 상기 제2 디바이스에 데이터를 전송하는 단계; 및 상기 데이터 전송 결과 상기 제1 디바이스가 더 이상 전송할 데이터가 없으면 상기 제2디바이스에 NULL 프레임을 전송하는 단계를 포함하는 것이 바람직하다.
상기 무선 PAN상에서 디바이스간에 데이터를 송수신하는 방법은, 상기 NULL 프레임을 수신한 제2 디바이스가 상기 제1 디바이스에 전송할 데이터가 있으면 데이터를 전송하고, 전송할 데이터가 없으면 상기 제1 디바이스가 전송한 데이터에 대한 확인 프레임을 전송하는 단계를 더 포함하는 것이 바람직하다.
무선 PAN상에서 디바이스간에 데이터를 송수신하는 방법은, 상기 확인 프레임을 수신한 제1 디바이스가 상기 제2 디바이스에 전송할 데이터가 있으면 데이터를 전송하고, 전송할 데이터가 없으면 상기 제2 디바이스에 NULL 프레임을 전송하는 단계를 더 포함하는 것이 바람직하다.
그리고, 상기 확인 프레임은 MAC 층에서의 Immediate ACK 프레임인 것이 바람직하다.
또한, 상기 NULL 프레임은 MAC 헤더만으로 구성되는 것이 바람직하다.
이하, 첨부된 도면을 참조하여 본 발명의 바람직한 일 실시예를 상세히 설명한다.
두 DEV가 송신측과 수신측으로 역할이 고정되지 않고 동적으로 송신측과 수신측의 역할을 서로 바꾸어 할 수 있는 채널 시간 구간을 추가하고, TCP/IP에서와 같이 두 DEV가 상호 데이터를 송수신하여야 하는 프로토콜이 MAC 층의 상위에서 구동되는 경우에 상기 채널 시간을 PNC에게 요청한다. 상기 PNC(piconet coordinator)는 피코넷 내의 DEV에 각종 서비스를 제공하는 디바이스인데, 무선 통신 매체를 이용하여 채널 시간을 할당하고, DEV 간에 동기화를 수행하며, DEV를 피코넷에 가입하게 하는 어소시에이션(association) 기능 등을 수행한다.
상기 상호 데이터 송수신을 위해서는, 먼저 802.15.3 MAC에서 제공하는 MLME-CREATE-STREAM.request의 파라미터를 수정할 필요가 있다. 다음의 [표 1]에서는 기존의 파라미터에 'DirectionType'이라는 파라미터를 추가하여 수정된 MLME-CREATE-STREAM.request의 파라미터를 나타내었다. DirectionType은 데이터 송신 방향이 단방향인지 양방향인지를 결정하는 방향 정보를 의미한다.
[표 1]
MLME-CREATE-STREAM.request{ TrgtID, DSPSSetIndex, StreamRequestID, StreamIndex, ACKPolicy, Priority, PNCTRqType, CTAType, CTARateType, CTARateFactor, DirectionType , CTRqTU, MinNumTUs, DesiredNumTUs, RequestTimeout}
상기 DirectionType 파라미터는 다음의 [표 2]와 같이 정의된다.
[표 2]
Name Type Valid range Description
DirectionType Enumeration ONE_WAY,TWO_WAY 할당된 채널 시간 동안 한 DEV만이 src DEV가 되어서 데이터를 보낼 수 있는지(ONE_WAY),두 DEV 모두 src DEV가 될 수 있는지 (TWO_WAY)를 나타낸다.
DEV1이 DEV2에 TCP/IP 프로토콜을 이용하여 데이터를 보낸다고 가정하자. DEV1는 PNC에게 채널 시간을 요청하기 위해 우선 MLME-CREATE-STREAM.request를 호출한다. 이 때, DirectionType은 TWO_WAY로 설정한다. DEV1의 MLME가 MLME-CREATE-STREAM.request를 받으면 PNC에게 도 4에서와 같은 channel time request command(100)를 보낸다. 이 때 channel time request command(100)를 구성하는 channel time request block(110)에는 상기 [표 1]에서와 같이 ＇DirectionType＇을 정의하는 비트 필드가 추가된다. 상기 ＇DirectionType＇필드는 1octet 이 할당되어 있지만 ONE_WAY인 경우에는 ＇0＇을 갖고, TWO_WAY인 경우에는 ＇1＇을 가지므로 1비트 정보로 충분하므로 실제로 1비트만 사용하며, 나머지 7비트는 reserved로 남겨져 있다.
PNC가 channel time request command(100)를 받은 후 통신 매체의 리소스(resources)가 충분할 경우에는 상기 채널 시간을 비콘을 통하여 해당 DEV에 할당하게 된다. 도 5에서는 비콘 프레임(beacon frame; 200)의 구조, 비콘 프레임이 갖는 하나 이상의 ＇Information element＇필드 중에서 ＇channel time allocation information element＇ 필드(210)의 구조, 그리고 상기 ＇channel time allocation information element＇ 필드(210)에 존재하는 하나 이상의 ＇channel time allocation block＇ 필드(211)의 구조를 나타내었다. 상기 channel time allocation block 필드(211)의 구조는 수신측 DEV의 ID를 나타내는 DestID 필드, 송신측 DEV의 ID를 나타내는 SrcID 필드, 데이터 전송방향이 ONE_WAY인지 TWO_WAY인지를 나타내는 본 발명에서 정의한 DirectionType 필드, 전송하는 데이터 스트림의 동일성을 나타내는 Stream index 필드, 슈퍼프레임에서 CTA의 위치를 나타내는 CTA location 필드, 그리고 CTA의 지속시간을 나타내는 CTA duration 필드로 구성된다.
DirectionType이 ONE_WAY인 채널 시간 동안에는 SrcID로 지정된, 즉 channel time request command(100)를 보낸 DEV만이 송신자(sender)가 될 수 있다. 이는 기존의 802.15.3과 같다. 만약 DirectionType이 TWO_WAY인 채널 시간이 할당되면 그 시간 동안에는 SrcID와 DestID로 지정된 두 DEV 모두가 송신자가 되어서 상대편 DEV에 원하는 데이터를 전송할 수 있다. 비콘에는 channel time request command(100)를 보낸 DEV1이 SrcID이고, DEV2가 DestID로 지정된 channel time allocation block(211)이 포함되어 있는데, 비콘 정보에 따라 우선 SrcID로 지정된 DEV1이 먼저 송신자로 된다.
이하에서, 도 6 내지 도 8은 본 발명의 제1 실시예를 설명하는 도면들이고, 도 9 내지 도 11은 본 발명의 제2 실시예를 설명하는 도면들이다.
제1 실시예는 송신자가 더 이상 보낼 데이터가 없을 때에는 'NULL 프레임'을 전송하며 이에 따라 수신자 측에서는 데이터를 전송할 수 있으며, 수신자가 NULL 프레임을 받고도 전송할 데이터가 없으면 다시 Imm-ACK(Immediate ACK)를 전송하여 다시 데이터 전송 기회를 송신자 측으로 넘기는 방식이다. 따라서, 제1 실시예에 따르면 NULL 프레임의 'ACK policy'는 Imm-ACK이 된다.
한편, 제2 실시예는 송신자가 더 이상 보낼 데이터가 없을 때에는 'TOKEN 프레임'을 전송하며 이에 따라 수신자 측에서는 데이터를 전송할 수 있으며, 수신자가 TOKEN 프레임을 받고도 전송할 데이터가 없으면 다시 TOKEN 프레임를 전송하여 다시 데이터 전송 기회를 송신자 측으로 넘기는 방식이다. 따라서, 제2 실시예에 따르면 TOKEN 프레임의 'ACK policy'는 No-ACK이 된다. 이하 도 6 내지 도 8을 참조하여 본 발명에 따른 제1 실시예를 설명한다.
도 6은 DirectionType이 TWO_WAY인 채널 시간을 할당 받았을 때, 그 채널 시간에 DEV1과 DEV2이 데이터를 주고 받는 과정을 나타낸 것이다. channel time request command(100)를 보냈던 DEV1이 SrcID로, DEV2가 DestID로 지정된 channel time allocation block(211)을 비콘으로부터 받은 후, 지정된 시간이 되면 DEV1이 먼저 송신자(sender)가 되어 DEV2에 데이터를 전송한다(S10). DEV2는 DEV1으로부터 받은 데이터 프레임의 ACK policy에 맞게 ACK 프레임을 보낸다. 본 예에서는 Imm-ACK(Immediate ACK) policy를 가정한다(S20). 현 상태에서 DEV1이 더 이상 보낼 데이터가 없으면 DEV2로 NULL 프레임을 전송한다(S30). 상기 NULL 프레임은 MAC 헤더 부분만 존재하고 프레임 바디(frame body) 부분은 존재하지 않는 프레임으로서 그 구조는 도 7a에서 나타내는 바와 같다. 만약 상기 S30 단계에서 보낼 프레임이 있었다면 NULL 프레임이 아니라 바로 데이터 프레임을 보냈을 것이다. NULL 프레임을 받은 시점에서 DEV2가 현재 보낼 데이터가 없다면 바로 Imm-ACK를 전송한다(S40). DEV1은 자신이 보낸 NULL 프레임에 대해 Imm-ACK를 받은 후에 DEV2로 보낼 데이터가 있으면 그것을 전송하고, 보낼 데이터가 없으면 다시 NULL 프레임을 전송한다(S50). DEV2가 다시 NULL 프레임을 받고 그 시점에 DEV1으로 보낼 데이터가 준비 되었다면 이번에는 Imm-ACK 프레임이 아니라 데이터 프레임을 DEV1으로 전송한다(S60). DEV1은 자신이 보낸 NULL 프레임에 대해 Imm-ACK가 아닌 데이터 프레임을 받았으므로 이에 대한 Imm-ACK를 DEV2로 보낸다(S70). Imm-ACK를 받은 DEV2는 더 보낼 데이터가 있으면 계속 DEV1으로 그것들을 전송하고, 그렇지 않으면 NULL 프레임을 DEV1으로 보낸다(S80). DEV1이 그 시점에서 보낼 데이터가 없으면 Imm-ACK를 DEV2로 전송한다(S90). 이와 같은 과정이 두 DEV에 할당 된 채널 시간이 끝날 때까지 반복된다.
도 7a는 본 발명에서 제안하는 상기 ＇NULL 프레임＇의 구조를 상세히 나타낸 것이다. NULL 프레임은 MAC 헤더만 존재하고 프레임 바디는 존재하지 않는 프레임으로서 종래의 MAC 헤더와 같이 10 octets의 크기를 가지고, 각각의 필드는 1 octet의 크기를 갖는다. 여기서 Frame type 필드(710)는 NULL 프레임의 type value를 기록하는 곳이다. 각종 필드 프레임의 type value를 정의한 테이블이 도 7b에 나타나 있다. 이러한 type value는 MAC 헤더의 b5, b4 및 b3 비트에 기록되는데, 각 비트의 조합에 따라 해당 프레임이 어떤 프레임인지를 알려 준다. 예를 들어, ＇000＇은 비콘 프레임을 의미하고, ＇001＇은 Imm-ACK 프레임을 의미한다. 기존의 IEEE 802.15.3에서는 이외에도 Delayed ACK 프레임(value=＇010＇), command 프레임(value=＇011＇), 데이터 프레임(value=＇100＇) 등의 type value가 규정되어 있다. 본 발명에서는 상기 type value들과 아울러, NULL 프레임의 type value를 새로이 추가하고 이를 ＇101＇로 규정하였다.
다시 도 7a를 참조하면, ACK policy 필드(720)에는 ACK policy에 따른 ACK 프레임의 type value를 기록한다. 상기 ACK 프레임의 type value는 IEEE 802.15.3에 따르면, MAC 헤더의 b8, b7 비트에 기록되는데, No ACK는 ＇00＇, Immediate ACK는 ＇01＇, Delayed ACK는 ＇10＇의 값을 갖는다. 따라서, 본 실시예에 따른 ACK policy 필드는＇01＇값을 갖는다. 그리고, DestID 필드(730)에는 해당 NULL 프레임을 송신하는 DEV의 ID를 기록하고, SrcID 필드(740)에는 해당 NULL 프레임을 수신하는 DEV의 ID를 기록한다. 이외의 MAC 헤더의 필드값은 모두 ＇0＇으로 한다.
도 8은 본 발명의 전체 동작을 설명하는 흐름도이다.
먼저, 제1 디바이스는 채널 시간을 요청하는 커맨드 프레임을 생성하여 PNC에 전송하고 전송된 프레임에 대한 ACK를 수신한다 (S801). 이를 위해서는 먼저, 제1 디바이스의 DME에서 MLME-CREATE-STREAM.request를 생성하여 MAC의 MLME에 전달한다. 상기 MLME-CREATE-STREAM.request의 파리미터는 상기 [표 1]에서 정의된 바와 같이 기존의 파라미터에 ＇DirectionType＇을 더 포함한다. 상기 MLME에 전달된 MLME-CREATE-STREAM.request를 이용하여 MLME에서는 채널 시간을 요청하는 커맨드 프레임, 즉 channel time request command 프레임을 생성하고 이를 물리층을 통하여 PNC에 전송한다.
상기 커맨드 프레임을 전송받은 PNC는 현재 채널(무선 통신 매체)에 사용할 수 있는 리소스(available resources)가 있는지를 판단한다(S802). 상기 판단 결과 리소스가 없으면, channel time response command 프레임의 reason code를 ＇priority unsupported＇, ＇channel time unavailable＇ 또는 ＇unable to allocate as pseudo-static CTA＇ 등으로 적절하게 표시하고 제1 디바이스에 channel time response command 프레임을 전송한다. 그리고, 리소스가 있는 경우에는 상기 채널 시간 요청에 응답하는 커맨드 프레임, 즉 channel time response command 프레임에 reason code를 ＇success＇로 표시하여 상기 제1 디바이스에 전송하고 상기 제1 디바이스로부터 Imm-ACK를 수신한다(S803).
다음으로, PNC는 상기 전송받은 channel time request command 프레임에 존재하는 정보를 이용하여 비콘 프레임을 생성하고 피코넷의 멤버인 DEV들에게 비콘 프레임을 브로드캐스팅한다(S804). 상기 비콘 프레임에는 채널 할당에 관한 정보가 포함되는데, 상기 정보로는 CTA 지속시간, 슈퍼프레임 상에서 CTA가 차지하는 위치, 데이터의 동일성을 식별하는 스트림 인덱스, 데이터를 송신할 디바이스(제1 디바이스)의 ID, 데이터를 수신할 디바이스(제2 디바이스)의 ID, 그리고 데이터의 전송방향이 단방향인지 양방향인지를 나타내는＇DirectionType＇이 있다. 본 실시예에서는 DirectionType은 양방향 즉 ＇1＇로 설정된다. 상기 DirectionType 정보를 갖는 비콘 프레임을 전송받은 제1 디바이스와 제2 디바이스는 양자간에 양방향으로 데이터를 송수신한다는 것을 알 수 있게 된다.
이 후, 제1 디바이스와 제2 디바이스가 통신할 CTA의 시작 시간이 되면(S805의 예), 제1 디바이스는 제2 디바이스에 데이터 프레임을 전송하고, 제2 디바이스로부터 Imm-ACK 프레임을 수신한다(S806). 데이터는 최대 프레임 길이 이하의 프레임 단위로 조각화되어 전송되므로, 단위보다 큰 데이터를 전송할 경우에는 복수의 데이터 프레임의 전송과정을 거쳐야 한다. 또한 상기 데이터를 모두 전송한 후 또 다른 데이터를 전송할 경우에도 추가적인 프레임 전송과정을 거쳐야 한다.
상기와 같은 전송과정을 거쳐 제1 디바이스가 전송할 데이터 프레임이 더 이상 존재하지 않으면(S807의 아니오), 제1 디바이스는 제2 디바이스에 더 이상 전송할 데이터가 없음을 표시하는 NULL 프레임을 전송한다(S808).
상기 NULL 프레임을 전송받은 제2 디바이스는 전송할 데이터가 없으면(S809의 아니오), 제1 디바이스에 Imm-ACK를 전송하고(S810), 상기 S807 단계로 돌아간다. 한편, 전송할 데이터가 있으면(S809의 예) 제2 디바이스는 제1 디바이스에 데이터 프레임을 전송하고 제1 디바이스로부터 Imm-ACK를 수신한다(S811). 그 다음 제2 디바이스가 전송할 데이터가 더 있으면(S812의 예), 추가적인 데이터 프레임 전송과정(S811)을 거치고, 전송할 데이터가 더 없으면(S812의 아니오) 제2 디바이스는 제1 디바이스에 NULL 프레임을 전송한다(S813). 마찬가지로 상기 NULL 프레임을 전송받은 제1 디바이스는 전송할 데이터가 있으면(S814의 예) 상기 S806 단계로 돌아가고, 전송할 데이터가 없으면 제2 디바이스에 Imm-ACK를 전송한 후(S815) 상기 S812 단계로 돌아간다.
상기 S806 단계 부터 S815 단계는 해당 CTA의 시작 시간부터 종료 시간까지만 진행되며, 상기 단계 중 임의의 단계에서 CTA의 종료 시간이 되면 도 8에서의 과정은 종료한다.
이하에서는, 도 9 내지 도 11을 참조하여 본 발명에 따른 제2 실시예를 설명한다. 도 9는 DirectionType이 TWO_WAY인 채널 시간을 할당 받았을 때, 그 채널 시간에 DEV1과 DEV2이 데이터를 주고 받는 과정을 나타낸 것이다. channel time request command(100)를 보냈던 DEV1이 SrcID로, DEV2가 DestID로 지정된 channel time allocation block(211)을 비콘으로부터 받은 후, 지정된 시간이 되면 DEV1이 먼저 송신자(Sender)가 되어 DEV2에 데이터를 전송한다(S110). DEV2는 DEV1으로부터 받은 데이터 프레임의 ACK policy에 맞게 ACK 프레임을 보낸다. 본 예에서는 데이터 전송에 대한 ACK 으로는 Imm-ACK(Immediate ACK) policy를 가정한다(S120). 현 상태에서 DEV1이 더 이상 보낼 데이터가 없으면 DEV2로 TOKEN 프레임을 전송한다(S130). 상기 TOKEN 프레임은 MAC 헤더 부분만 존재하고 프레임 바디(frame body) 부분은 존재하지 않는 프레임으로서 그 구조는 도 10a에서 나타내는 바와 같다.
만약 상기 S130 단계에서 보낼 프레임이 있었다면 TOKEN 프레임이 아니라 바로 데이터 프레임을 보냈을 것이다. TOKEN 프레임을 받은 시점에서 DEV2가 현재 보낼 데이터가 없다면 마찬가지로 TOKEN 프레임을 전송한다(S140). 이와 같이 TOKEN 프레임은 데이터를 전송할 수 있는 권리를 상대편 DEV에 넘기는 역할을 한다.
DEV1은 TOKEN 프레임을 보내고 다시 TOKEN 프레임을 받은 후에는 DEV2로 보낼 데이터가 있으면 그것을 전송하고, 보낼 데이터가 없으면 다시 TOKEN 프레임을 전송할 수 있다(S150). 만약, DEV2가 또 다시 TOKEN 프레임을 받고 그 시점에 DEV1으로 보낼 데이터가 준비 되었다면 이번에는 데이터 프레임을 DEV1으로 전송하게 된다(S160). DEV1은 자신이 보낸 TOKEN 프레임에 대해 TOKEN 프레임이 아닌, 데이터 프레임을 받았으므로 이에 대한 Imm-ACK를 DEV2로 보낸다(S170). Imm-ACK를 받은 DEV2는 더 보낼 데이터가 있으면 계속 DEV1으로 그것들을 전송하고, 그렇지 않으면 TOKEN 프레임을 DEV1으로 보낸다(S180). 이와 같은 과정이 두 DEV에 할당 된 채널 시간이 끝날 때까지 반복된다.
도 10a는 본 발명에서 제안하는 상기 ＇TOKEN 프레임＇의 구조를 상세히 나타낸 것이다. TOKEN 프레임은 MAC 헤더만 존재하고 프레임 바디는 존재하지 않는 프레임으로서 종래의 MAC 헤더와 같이 10 octets의 크기를 가지고, 각각의 필드는 1 octet의 크기를 갖는다. 여기서 Frame type 필드(1710)는 TOKEN 프레임의 type value를 기록하는 곳이다. 각종 필드 프레임의 type value를 정의한 테이블이 도 10b에 나타나 있다. 이러한 type value는 MAC 헤더의 b5, b4 및 b3 비트에 기록되는데, 각 비트의 조합에 따라 해당 프레임이 어떤 프레임인지를 알려 준다. 예를 들어, ＇000＇은 비콘 프레임을 의미하고, ＇001＇은 Imm-ACK 프레임을 의미한다. 기존의 IEEE 802.15.3에서는 이외에도 Delayed ACK 프레임(value=＇010＇), command 프레임(value=＇011＇), 데이터 프레임(value=＇100＇) 등의 type value가 규정되어 있다. 본 발명에서는 상기 type value들과 아울러, TOKEN 프레임의 type value를 새로이 추가하고 이를 ＇101＇로 규정하였다.
다시 도 10a를 참조하면, ACK policy 필드(1720)에는 ACK policy에 따른 ACK 프레임의 type value를 기록한다. 상기 ACK 프레임의 type value는 IEEE 802.15.3에 따르면, MAC 헤더의 b8, b7 비트에 기록되는데, No ACK는 ＇00＇, Immediate ACK는 ＇01＇, Delayed ACK는 ＇10＇의 값을 갖는다. 따라서, 제2 실시예에 따른 ACK policy는 No-ACK 이므로 ACK policy 필드는＇00＇값을 갖는다. 그리고, DestID 필드(1730)에는 해당 TOKEN 프레임을 송신하는 DEV의 ID를 기록하고, SrcID 필드(1740)에는 해당 TOKEN 프레임을 수신하는 DEV의 ID를 기록한다. 이외의 MAC 헤더의 필드값은 모두 ＇0＇으로 한다.
도 11은 본 발명의 전체 동작을 설명하는 흐름도이다. 먼저, 제1 디바이스는 채널 시간을 요청하는 커맨드 프레임을 생성하여 PNC에 전송하고 전송된 프레임에 대한 ACK를 수신한다 (S901). 이를 위해서는 먼저, 제1 디바이스의 DME에서 MLME-CREATE-STREAM.request를 생성하여 MAC의 MLME에 전달한다. 상기 MLME-CREATE-STREAM.request의 파리미터는 상기 [표 1]에서 정의된 바와 같이 기존의 파라미터에 ＇DirectionType＇을 더 포함한다. 상기 MLME에 전달된 MLME-CREATE-STREAM.request를 이용하여 MLME에서는 채널 시간을 요청하는 커맨드 프레임, 즉 channel time request command 프레임을 생성하고 이를 물리층을 통하여 PNC에 전송한다.
상기 커맨드 프레임을 전송받은 PNC는 현재 채널(무선 통신 매체)에 사용할 수 있는 리소스(available resources)가 있는지를 판단한다(S902). 상기 판단 결과 리소스가 없으면, channel time response command 프레임의 reason code를 ＇priority unsupported＇, ＇channel time unavailable＇ 또는 ＇unable to allocate as pseudo-static CTA＇ 등으로 적절하게 표시하고 제1 디바이스에 channel time response command 프레임을 전송한다. 그리고, 리소스가 있는 경우에는 상기 채널 시간 요청에 응답하는 커맨드 프레임, 즉 channel time response command 프레임에 reason code를 ＇success＇로 표시하여 상기 제1 디바이스에 전송하고 상기 제1 디바이스로부터 Imm-ACK를 수신한다(S903).
다음으로, PNC는 상기 전송받은 channel time request command 프레임에 존재하는 정보를 이용하여 비콘 프레임을 생성하고 피코넷의 멤버인 DEV들에게 비콘 프레임을 브로드캐스팅한다(S904). 상기 비콘 프레임에는 채널 할당에 관한 정보가 포함되는데, 상기 정보로는 CTA 지속시간, 슈퍼프레임 상에서 CTA가 차지하는 위치, 데이터의 동일성을 식별하는 스트림 인덱스, 데이터를 송신할 디바이스(제1 디바이스)의 ID, 데이터를 수신할 디바이스(제2 디바이스)의 ID, 그리고 데이터의 전송방향이 단방향인지 양방향인지를 나타내는＇DirectionType＇이 있다. 제2 실시예에서는 DirectionType은 양방향 즉 ＇1＇로 설정된다. 상기 DirectionType 정보를 갖는 비콘 프레임을 전송받은 제1 디바이스와 제2 디바이스는 양자간에 양방향으로 데이터를 송수신한다는 것을 알 수 있게 된다.
이 후, 제1 디바이스와 제2 디바이스가 통신할 CTA의 시작 시간이 되면(S905의 예), 제1 디바이스는 제2 디바이스에 데이터 프레임을 전송하고, 제2 디바이스로부터 Imm-ACK 프레임을 수신한다(S906). 데이터는 최대 프레임 길이 이하의 프레임 단위로 조각화되어 전송되므로, 단위보다 큰 데이터를 전송할 경우에는 복수의 데이터 프레임의 전송과정을 거쳐야 한다. 또한 상기 데이터를 모두 전송한 후 또 다른 데이터를 전송할 경우에도 추가적인 프레임 전송과정을 거쳐야 한다.
상기와 같은 전송과정을 거쳐 제1 디바이스가 전송할 데이터 프레임이 더 이상 존재하지 않으면(S907의 아니오), 제1 디바이스는 제2 디바이스에 더 이상 전송할 데이터가 없음을 표시하는 TOKEN 프레임을 전송한다(S908).
상기 TOKEN 프레임을 전송받은 제2 디바이스는 전송할 데이터가 없으면(S909의 아니오), 제1 디바이스에 TOKEN를 전송하고(S910), 상기 S907 단계로 돌아간다. 한편, 전송할 데이터가 있으면(S909의 예) 제2 디바이스는 제1 디바이스에 데이터 프레임을 전송하고 제1 디바이스로부터 Imm-ACK를 수신한다(S911). 그 다음 제2 디바이스가 전송할 데이터가 더 있으면(S912의 예), 추가적인 데이터 프레임 전송과정(S911)을 거치고, 전송할 데이터가 더 없으면(S912의 아니오) 제2 디바이스는 제1 디바이스에 TOKEN 프레임을 전송한다(S913). 마찬가지로 상기 TOKEN 프레임을 전송받은 제1 디바이스는 전송할 데이터가 있으면(S914의 예) 상기 S906 단계로 돌아가고, 전송할 데이터가 없으면 제2 디바이스에 TOKEN 프레임을 전송한 후(S915) 상기 S912 단계로 돌아간다.
상기 S906 단계 부터 S915 단계는 해당 CTA의 시작 시간부터 종료 시간까지만 진행되며, 상기 단계 중 임의의 단계에서 CTA의 종료 시간이 되면 도 11에서의 과정은 종료한다.
이하에서는, 도 12 및 도 13을 참조하여 종래 기술에 따라 CTA에서 단방향 전송을 하는 경우와 본 발명에 따라 CTA에서 양방향 전송 적용 경우에 전송 효율의 차이를 비교하고자 한다.
도 12는 종래의 기술에 따라 단방향 전송을 하는 경우에 대하여 슈퍼프레임(900) 구조 및 데이터 전송 과정을 설명하기 위한 도면이다. 두 개의 DEV가 피코넷에 존재하고(DEV1, DEV2), TCP/IP를 이용하여 DEV1이 DEV2로 스트림을 전송하고자 한다면, DEV1에서 DEV2로 데이터 프레임이 전송되고, 이에 대한 ACK 프레임이 DEV2에서 DEV1으로 전송될 것이다. 데이터 전송시 MAC 층에서 사용하는 ACK policy는 IMM-ACK policy라고 하고, 슈퍼프레임 duration은 10ms, CAP는 1ms라고 가정한다. 그리고, MAC header의 전송률은 22Mbps, 프레임 payload의 전송률은 55Mbps라고 한다.
우선 DEV1과 DEV2 모두가 rate factor를 1로 한 슈퍼레이트 CTA(super-rate CTA)를 요청하였다고 한다면, 슈퍼프레임(900)은 도 13과 같이 사용될 것이다. 도 12에서와 같이 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로 가정함)으로 구성된다. [표 3]과 같은 계산 과정의 결과 상기와 같은 비콘을 전송하는 데는 약 0.012 ms가 걸린다.
[표 3]
헤더 전송 시간 : (10×8bits)×1000ms / 22Mbps = 0.0036ms,페이로드 전송 시간 : (21+16+20)×8bits×1000ms / 55Mbps = 0.0082ms
CTA1(930)과 CTA2(940)의 duration은 각각 DEV1과 DEV2가 PNC에 요청한 TU(Time Unit)의 크기와 Desired number of TUs에 따라 달라질 것이다. TU는 지정한 ACK policy에 따라 최소한 한 프레임은 전송할 수 있도록 하야여 한다. 비콘 전송 시간과 CAP(920)를 제외한 나머지 시간을 모두 각 DEV에 할당해 준다고 하면, DEV1, DEV2 모두 rate factor가 1인 슈퍼레이트 CTA를 요청하였다고 가정하였기 때문에, 도 12에서와 같이 src DEV가 DEV1이고 dest DEV가 DEV2인 CTA1(930)과, src DEV가 DEV2이고 dest DEV가 DEV1인 CTA2(940)가 배정될 것이다. CTA1(930)과 CTA2(940)의 duration은 각각의 DEV가 요청한 TU 및 PNC의 channel time allocation 알고리즘에 따라 달라질 수 있다.
CTA1(930)이 시작하는 시간이 되면 먼저 DEV1이 DEV2로 프레임1(950)을 전송한다. 이 때 프레임1(950)의 페이로드는 TCP/IP의 데이터 프레임이다. 최대 프레임 길이가 2048 bytes(MAC 헤더는 제외)이므로 프레임1(950)을 2048 bytes라고 하면, 프레임1(950)의 전송시간은 다음의 [표 4]에서와 같이 0.3014ms가 된다.
[표 4]
(MAC 헤더 전송시간) + (2048×8bits)×1000ms / 55Mbps=0.0036ms+0.2979ms=0.3014ms
ACK1(960)은 DEV2에서 DEV1으로 보내는 ACK 프레임이다. 이는 MAC 층에서 MAC의 ACK policy에 따라 전송되는 것이다. IEEE 802.15.3에서 ACK 프레임은 MAC 헤더만으로만 이루어져 있으므로 ACK 프레임을 전송하는 데는 0.0036 ms가 걸릴 것이다.
본 예에서 MAC 층의 상위층에서는 TCP/IP를 이용하여 전송하므로, DEV1은 DEV2로부터 TCP/IP 레벨의 ACK 프레임을 받지 못하면 더 이상 새로운 프레임을 전송할 수 없다. DEV1이 DEV2로 TCP/IP를 이용하여 프레임을 전송하면, DEV2는 이에 대한 ACK 프레임을 보내야 한다. 이는 MAC 층에서 보내는 ACK(예를 들어, 상기 Imm-ACK)와는 별도로, MAC 층의 상위층에서 전송되는 것이기 때문에 MAC 층에서 보면 다른 데이터 프레임과 마찬가지로 처리가 된다. 도 12에서 프레임2는 DEV2가 DEV1으로 전송하는 TCP/IP 레벨의 ACK 프레임을 나타낸다. 이와 같이, DEV2가 DEV1으로 프레임2를 보내고자 하여도 자신이 src로 지정된 채널 시간이 될 때까지 기다려야 한다. 따라서 CTA2(940)가 시작하는 시간이 되어야만 프레임2(970)를 전송할 수 있다. ACK2(980)는 MAC 층의 ACK policy에 따라 전송되는 MAC 층 레벨의 ACK 프레임이다.
이상에서 살펴 본 것과 같이, 기존의 802.15.3의 CTA 방식을 사용할 경우에는 10ms이라는 슈퍼프레임 동안에 DEV1에서 DEV2로 2048 bytes 크기의 프레임 하나가 전송되고, 반대로 DEV2로부터 DEV1으로도 2048 bytes의 프레임 하나만이 전송된다.
도 13은 본 발명에 따라 양방향 전송을 하는 경우에 대하여 슈퍼프레임(900) 구조 및 데이터 전송 과정을 설명하기 위한 도면이다. DEV1이 PNC에 대하여 DirectionType이 TWO_WAY인 채널 시간을 요청하면, 이에 대한 슈퍼프레임은 도 13과 같이 구성된다. 도 12에서와 마찬가지로, 비콘 전송시간과 CAP(920)를 제외한 나머지 시간을 모두 DEV들에게 할당한다고 가정한다. 그리고, 프레임1(950)은 DEV1에서 DEV2로 보내는 TCP/IP 데이터 프레임이고, 프레임2(970)는 DEV2에서 DEV1으로 보내는 TCP/IP 레벨의 ACK 프레임이다. 프레임2(970)가 전송되기까지 처리 시간(processing time)을 고려하여 중간에 NULL 프레임 또는 TOKEN 프레임(990) 하나가 전송된다고 가정하였다. 그러면, DEV1에서 DEV2로 TCP/IP 데이터 프레임을 하나 보내고 이에 대하여 TCP/IP 레벨의 ACK 프레임을 받는 것까지 걸리는 시간(A)을 계산해 보면 [표 5]와 같다.
[표 5]
A = Frame 1 전송 시간 + SIFS + ACK 1 전송 시간 + SIFS + NULL frame(또는 TOKEN 프레임) 전송 시간 + SIFS + Frame 2 전송 시간 + SIFS + ACK 2 전송 시간 + SIFS= 0.3015 ms + 0.01 ms + 0.0036 ms + 0.01ms + 0.0036 ms + 0.01 ms + 0.3015 ms + 0.01 ms + 0.0036 ms +0.01 ms = 0.6638 ms
따라서 10 ms의 슈퍼프레임(900) 동안 비콘(910) 전송 시간과 CAP(920)를 제외한 값을 상기 시간(A)로 나누면 다음의 [표 6]에서의 결과와 같다.
[표 6]
(10 - 0.012 - 0.01 - 1) / 0.6638 ≒ 13
이 결과에 따르면, 단위 슈퍼프레임 동안, DEV1은 DEV2로 2048 bytes 짜리 프레임을 13개 보낼 수 있고, 마찬가지로 이 시간 동안에 DEV2도 DEV1으로 2048 bytes의 프레임 13개를 보낼 수 있다. 물론, 앞에서 CTA rate factor를 1을 초과하는 수로 지정하여 PNC에 채널 시간을 요청한다면 도 12에서 보다는 많은 양의 데이터를 전송할 수 있을 것이다. 그러나 rate factor나 PNC의 채널 시간 할당 알고리즘에 따라 채널 시간의 배치가 달라 질 수 있고, 또한 항상 채널 시간을 최대로 사용할 수 있다는 보장이 없기 때문에, 본 발명에서와 같이 DirectionType을 갖는 채널 시간을 이용하는 것이 더 효율적이라고 할 수 있다.
이상 첨부된 도면을 참조하여 본 발명의 실시예를 설명하였지만, 본 발명이 속하는 기술분야의 통상의 지식을 가진 자는 본 발명이 그 기술적 사상이나 필수적인 특징을 변경하지 않고서 다른 구체적인 형태로 실시될 수 있다는 것을 이해할 수 있을 것이다. 그러므로 이상에서 기술한 실시예들은 모든 면에서 예시적인 것이며 한정적이 아닌 것으로 이해해야만 한다. 본 발명의 범위는 상기 상세한 설명보다는 후술하는 특허청구의 범위에 의하여 나타내어지며, 특허청구의 범위의 의미 및 범위 그리고 그 균등 개념으로부터 도출되는 모든 변경 또는 변형된 형태가 본 발명의 범위에 포함되는 것으로 해석되어야 한다.
기존의 802.15.3 MAC에서 제공하는 채널 시간은 소스 디바이스와 목적지 디바이스가 고정되어 있어서 한 채널 시간 동안에는 한 디바이스만이 데이터를 보내고, 다른 디바이스는 일방적으로 그것을 받을 수 밖에 없도록 되어 있다. 따라서, 앞에서 살펴 본 바와 같이 TCP/IP와 같이 상호 프레임을 주고 받아야 하는 프로토콜에 대해서는 비효율적으로 동작을 하게 된다. 본 발명에 따르면, 이러한 비효율성을 감소시켜 전체적인 전송효율을 향상시킬 수 있다.
도 1은 종래의 슈퍼프레임의 구조를 나타낸 도면.
도 2는 종래의 채널 시간 할당을 요청하는 과정을 나타낸 도면.
도 3은 종래의 비동기 데이터를 전송하는 과정을 나타낸 도면.
도 4는 본 발명에 따른 Channel time request comman 프레임의 구조를 나타낸 도면.
도 5는 본 발명에 따른 Beacon frame의 구조를 나타낸 도면.
도 6은 제1 실시예에 따라 채널 시간내에 디바이스간에 양방향으로 데이터를 송수신하는 예를 나타낸 도면.
도 7a는 제1 실시예에 따른 NULL 프레임의 구조를 나타낸 도면.
도 7b는 제1 실시예에 따른 각종 프레임의 Frame type value를 나타낸 표.
도 8은 제1 실시예에 따른 본 발명의 전체 동작을 설명하는 흐름도.
도 9는 제2 실시예에 따라 채널 시간내에 디바이스간에 양방향으로 데이터를 송수신하는 예를 나타낸 도면.
도 10a는 제2 실시예에 따른 NULL 프레임의 구조를 나타낸 도면.
도 10b는 제2 실시예에 따른 각종 프레임의 Frame type value를 나타낸 표.
도 11은 제2 실시예에 따른 본 발명의 전체 동작을 설명하는 흐름도.
도 12는 종래의 단방향 전송을 하는 경우에 대하여 슈퍼프레임 구조 및 데이터 전송 과정을 나타낸 도면.
도 13은 본 발명에 따른 양방향 전송을 하는 경우에 대하여 슈퍼프레임 구조 및 데이터 전송 과정을 나타낸 도면.

Claims (13)

  1. 데이터 송신 방향이 단방향인지 양방향인지를 결정하는 방향 정보를 포함하는 채널 시간 요청 프레임을 생성하여 채널 시간 할당을 담당하는 디바이스에 전송하는 제1단계;
    상기 채널 시간 요청 프레임에 존재하는 정보를 이용하여 상기 방향 정보가 포함된 채널 시간 할당 정보를 갖는 프레임을 생성하고 상기 생성된 프레임을 브로드캐스팅하는 제2단계; 및
    상기 비콘 프레임에서 소스 디바이스로 지정된 제1 디바이스와 목적지 디바이스로 지정된 제2 디바이스 간에 소정의 채널 시간 동안 상기 방향 정보에 맞게 데이터를 송수신하는 제3단계를 포함하는 것을 특징으로 하는 무선 PAN상에서 디바이스 간에 데이터를 송수신하는 방법.
  2. 제1항에 있어서, 상기 채널 시간 요청 프레임은 IEEE 802.15.3에서 규정하는 channel time request command 프레임인 것을 특징으로 하는 무선 PAN상에서 디바이스 간에 데이터를 송수신하는 방법.
  3. 제1항에 있어서, 상기 채널 시간 할당을 담당하는 디바이스는 IEEE 802.15.3에서 규정하는 피코넷 코디네이터(PNC)인 것을 특징으로 하는 무선 PAN상에서 디바이스 간에 데이터를 송수신하는 방법.
  4. 제1항에 있어서, 상기 채널 시간 할당 정보를 갖는 프레임은 IEEE 802.15.3에서 규정하는 비콘 프레임인 것을 특징으로 하는 무선 PAN상에서 디바이스 간에 데이터를 송수신하는 방법.
  5. 제1항에 있어서, 상기 제3단계는
    상기 제1 디바이스가 상기 제2 디바이스에 데이터를 전송하는 단계; 및
    상기 데이터 전송 결과 상기 제1 디바이스가 더 이상 전송할 데이터가 없으면 상기 제2디바이스에 NULL 프레임을 전송하는 단계를 포함하는 것을 특징으로 하는 무선 PAN상에서 디바이스 간에 데이터를 송수신하는 방법.
  6. 제5항에 있어서,
    상기 NULL 프레임을 수신한 제2 디바이스가 상기 제1 디바이스에 전송할 데이터가 있으면 데이터를 전송하고, 전송할 데이터가 없으면 상기 제1 디바이스가 전송한 데이터에 대한 확인 프레임을 전송하는 단계를 더 포함하는 것을 특징으로 하는 무선 PAN상에서 디바이스 간에 데이터를 송수신하는 방법.
  7. 제6항에 있어서,
    상기 확인 프레임을 수신한 제1 디바이스가 상기 제2 디바이스에 전송할 데이터가 있으면 데이터를 전송하고, 전송할 데이터가 없으면 상기 제2 디바이스에 NULL 프레임을 전송하는 단계를 더 포함하는 것을 특징으로 하는 무선 PAN상에서 디바이스 간에 데이터를 송수신하는 방법.
  8. 제6항 또는 제7항에 있어서, 상기 확인 프레임은
    MAC 층에서의 Immediate ACK 프레임인 것을 특징으로 하는 무선 PAN상에서 디바이스 간에 데이터를 송수신하는 방법.
  9. 제5항 내지 제7항에 있어서, 상기 NULL 프레임은
    MAC 헤더만으로 구성되며, Immediat ACK policy를 취하는 것을 특징으로 하는 무선 PAN상에서 디바이스 간에 데이터를 송수신하는 방법.
  10. 제1항에 있어서, 상기 제3단계는
    상기 제1 디바이스가 상기 제2 디바이스에 데이터를 전송하는 단계; 및
    상기 데이터 전송 결과 상기 제1 디바이스가 더 이상 전송할 데이터가 없으면 상기 제2디바이스에 TOKEN 프레임을 전송하는 단계를 포함하는 것을 특징으로 하는 무선 PAN상에서 디바이스 간에 데이터를 송수신하는 방법.
  11. 제10항에 있어서,
    상기 NULL 프레임을 수신한 제2 디바이스가 상기 제1 디바이스에 전송할 데이터가 있으면 데이터를 전송하고, 전송할 데이터가 없으면 다시 TOKEN 프레임을 전송하는 단계를 더 포함하는 것을 특징으로 하는 무선 PAN상에서 디바이스 간에 데이터를 송수신하는 방법.
  12. 제11항에 있어서,
    상기 TOKEN 프레임을 수신한 제1 디바이스가 상기 제2 디바이스에 전송할 데이터가 있으면 데이터를 전송하고, 전송할 데이터가 없으면 상기 제2 디바이스에 TOKEN 프레임을 전송하는 단계를 더 포함하는 것을 특징으로 하는 무선 PAN상에서 디바이스 간에 데이터를 송수신하는 방법.
  13. 제10항 내지 제12항 중 어느 한 항에 있어서, 상기 TOKEN 프레임은
    MAC 헤더만으로 구성되며, No ACK policy를 취하는 것을 특징으로 하는 무선 PAN상에서 디바이스 간에 데이터를 송수신하는 방법.
KR1020040049655A 2003-10-29 2004-06-29 무선 ｐａｎ상에서 디바이스 간에 효율적으로 데이터를송수신하는 방법 KR100772855B1 (ko)

Priority Applications (5)

Application Number Priority Date Filing Date Title
CN2004800320589A CN1875575B (zh) 2003-10-29 2004-10-18 在无线个人域网上的装置之间交换数据的方法
JP2006537872A JP2007510350A (ja) 2003-10-29 2004-10-18 無線ｐａｎ上でデバイス間に効率的にデータを送受信する方法
PCT/KR2004/002663 WO2005041488A1 (en) 2003-10-29 2004-10-18 Method for exchanging data between devices on wireless personal area network
US10/970,467 US20050094657A1 (en) 2003-10-29 2004-10-22 Method for exchanging data between devices on wireless personal area network
EP04256557A EP1528733A3 (en) 2003-10-29 2004-10-23 Method for exchanging data between devices on a wireless personal area network (WPAN)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
KR1020030076034 2003-10-29
KR20030076034 2003-10-29

Publications (2)

Publication Number Publication Date
KR20050040692A true KR20050040692A (ko) 2005-05-03
KR100772855B1 KR100772855B1 (ko) 2007-11-02

Family

ID=37242459

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020040049655A KR100772855B1 (ko) 2003-10-29 2004-06-29 무선 ｐａｎ상에서 디바이스 간에 효율적으로 데이터를송수신하는 방법

Country Status (2)

Country Link
KR (1) KR100772855B1 (ko)
CN (1) CN1875575B (ko)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR100868474B1 (ko) * 2006-12-04 2008-11-12 한국전자통신연구원 개인 무선 통신망에서의 타이머를 이용한 방송형 데이터수신 방법
US8780869B2 (en) 2009-04-15 2014-07-15 Qualcomm Incorporated Method and apparatus for efficient association procedure
US8917655B2 (en) 2008-07-11 2014-12-23 Samsung Electronics Co., Ltd. Method and apparatus for allowing device supporting multiple PHY communication mode to communicate with device in wireless personal area network
KR20170007174A (ko) * 2015-07-09 2017-01-18 한국전자통신연구원 무선 통신 방법

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101394249B (zh) * 2007-09-19 2011-05-04 华为技术有限公司 传输控制方法、传输方法及装置
KR100999686B1 (ko) 2008-04-25 2010-12-08 금오공과대학교 산학협력단 하이브리드 네트워크를 위한 실시간 동기화 방법
US8363586B2 (en) * 2008-12-31 2013-01-29 Intel Corporation Social networking and advertisements in a mobile device on a local personal area network
CN101998682A (zh) * 2009-08-27 2011-03-30 中兴通讯股份有限公司 一种个人网设备获取业务内容的装置、方法及相关装置

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1457006A2 (en) * 2001-10-03 2004-09-15 Freescale Semiconductor, Inc. Method of operating a media access controller
US7184767B2 (en) * 2001-11-28 2007-02-27 Freescale Semiconductor, Inc. System and method of communication between multiple point-coordinated wireless networks
AU2003216068A1 (en) * 2002-01-22 2003-09-02 Xtremespectrum, Inc. Method for transmission of isochronous and asynchronous data in a radio network

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR100868474B1 (ko) * 2006-12-04 2008-11-12 한국전자통신연구원 개인 무선 통신망에서의 타이머를 이용한 방송형 데이터수신 방법
US8917655B2 (en) 2008-07-11 2014-12-23 Samsung Electronics Co., Ltd. Method and apparatus for allowing device supporting multiple PHY communication mode to communicate with device in wireless personal area network
US8780869B2 (en) 2009-04-15 2014-07-15 Qualcomm Incorporated Method and apparatus for efficient association procedure
US8971256B2 (en) 2009-04-15 2015-03-03 Qualcomm Incorporated Ad-hoc directional communication in contention access period
KR20170007174A (ko) * 2015-07-09 2017-01-18 한국전자통신연구원 무선 통신 방법

Also Published As

Publication number Publication date
KR100772855B1 (ko) 2007-11-02
CN1875575B (zh) 2011-05-11
CN1875575A (zh) 2006-12-06

Similar Documents

Publication Publication Date Title
EP1528733A2 (en) Method for exchanging data between devices on a wireless personal area network (WPAN)
KR100678941B1 (ko) 할당된 시간 동안 양방향으로 데이터를 송수신하는 방법및 그 방법을 이용하는 무선 디바이스
US6980541B2 (en) Media access controller having pseudo-static guaranteed time slots
CA2556062C (en) A system and method for an ultra wide-band medium access control distributed reservation protocol
US7593422B2 (en) Method of operating a media access controller having pseudo-static guaranteed time slots
US6975613B1 (en) System and method for scheduling communication sessions in an ad-hoc network
EP2108234B1 (en) A method for transmitting a data packet and a method of allocating a channel in a wireless network
US20060050728A1 (en) Method for bi-directional communication between source device and destination device during allocated channel time
JP2005198305A (ja) 無線個人領域ネットワークにおけるチャネル時間割当て方法
CA2586171C (en) Techniques for stream handling in wireless communications networks
KR20040033069A (ko) 무선 네트워크에 있어서의 반송파 감지 다중 접속프로토콜을 최적화하기 위한 알고리듬 및 프로토콜을이용하는 시스템 및 방법
US9185729B2 (en) Wireless communication method and apparatus
KR100666127B1 (ko) Ｗｐａｎ에서 동적 응답 정책을 이용한 데이터 프레임전송방법
US7349413B2 (en) Method and apparatus for communicating between coordinator-based wireless networks connected through a backbone network
KR100586864B1 (ko) 경쟁 접속 구간 매커니즘을 개선한 무선 개인영역네트워크 통신방법 및 시스템
JP4064394B2 (ja) 周波数ホッピング方式のマルチバンド超広域通信方法
US20050089002A1 (en) Method for wireless local area network communication in distributed coordination function mode
KR100772855B1 (ko) 무선 ｐａｎ상에서 디바이스 간에 효율적으로 데이터를송수신하는 방법
WO2001071981A2 (en) Multimedia extensions for wireless local area networks
WO2010114487A1 (en) Methods for transmitting a message, methods for storing information, message transmission devices and information storage devices
Bhattacharya et al. Multimedia communication in cognitive radio networks based on sample division multiplexing
EP1684474A2 (en) Improved method and device for managing a shared transmission medium based on a TDMA/TDD scheme
US20230413268A1 (en) Short feedback procedure for signalling multiple technologies in wireless networks
Wu et al. A self organize multichannel medium access control (SMMAC) protocol for wireless sensor networks

Legal Events

Date Code Title Description
A201 Request for examination
E902 Notification of reason for refusal
E601 Decision to refuse application
J201 Request for trial against refusal decision
AMND Amendment
E801 Decision on dismissal of amendment
B601 Maintenance of original decision after re-examination before a trial
S901 Examination by remand of revocation
GRNO Decision to grant (after opposition)
GRNT Written decision to grant
FPAY Annual fee payment

Payment date: 20120927

Year of fee payment: 6

FPAY Annual fee payment

Payment date: 20130927

Year of fee payment: 7

FPAY Annual fee payment

Payment date: 20140929

Year of fee payment: 8

FPAY Annual fee payment

Payment date: 20150925

Year of fee payment: 9

LAPS Lapse due to unpaid annual fee