WO2005041488A1

WO2005041488A1 - Method for exchanging data between devices on wireless personal area network

Info

Publication number: WO2005041488A1
Application number: PCT/KR2004/002663
Authority: WO
Inventors: Hyun-Ah Sung; Dae-Gyu Bae; Jin-Woo Hong
Original assignee: Samsung Electronics Co., Ltd.
Priority date: 2003-10-29
Filing date: 2004-10-18
Publication date: 2005-05-06
Also published as: EP1528733A3; JP2007510350A; US20050094657A1; EP1528733A2

Abstract

The present invention relates to a method and an apparatus for bi-directionally exchanging data within an allocated channel time by improving the MAC (Media Access Control) of devices operating on a wireless PAN (Personal Area Network). The method of the present invention comprises the steps of (1) generating a channel time request frame containing directional information to determine whether data transmission is unidirectional or bi-directional, and transmitting the channel time request frame to a device responsible for channel time allocation; (2) generating a frame containing channel time allocation information including the directional information based on the information contained in the channel time request frame, and broadcasting the generated frame; and (3) exchanging data between first and second devices, which are designated as source and destination devices in the frame containing the channel time allocation information, during a predetermined channel time in accordance with the directional information.

Description

Description METHOD FOR EXCHANGING DATA BETWEEN

DEVICES ON WIRELESS PERSONAL AREA NETWORK Technical Field [1] The present invention relates to a method and an apparatus for performing effective ccrαnunication between devices on a wireless network, and more particularly, to a method and an apparatus for bi-directionally exchanging data during the period of an allocated channel time by improving the MAC (Media Access Control) of devices operating on a wireless PAN (Personal Area Network). Background Art [2] UWB (Ultra Wideband), which is also known as digital pulse wireless, has been developed by U.S. Department of Defense for military purposes, and is a wireless technology for transmitting large amount of digital data over a wide spectrum of frequency bands with low power within a short distance. Standardization of UWB is currently being carried out by a Working Group that establishes the IEEE 802.153 i.e. wireless PAN standards. The IEEE 802.15.3 deals with PHY (physical layer) and MAC. Recently, research studies for improving the MAC have been active in the field of radio technology. [3] 802.15.3 MAC is characterized by a rapidly established wireless network . Further, 802.15.3 MAC is not based on an AP (Access Point) but rather on an Ad Hoc Network called a Piconet controlled by a PNC (Piconet Coordinator). The 802.15.3 MAC adopts a TDMA (Time Division Multiple Access) system. A MAC frame for exchanging data between devices is embodied in a temporal structure called a superframe as shown in FIG. 1. The superframe is composed of a beacon containing control information, a CAP (Contention Access Period) for transmitting data through backoff, and CTAP (Channel Time Allocation Period) for transmitting data without contention within the allocated time. Among them, CAP can be replaced by MCTA (Management CTA). Currently, competitive access can be made in CAP through a CSMA/CA (Carrier Sense Multiple Access/Collision Avoidance) system and a channel can be accessed in MCTA through a slotted Aloha method. [4] CTAP can comprise a plurality of MCTA blocks and a plurality of CTA blocks. CTA (Channel Time Allocation) is classified into two types: i.e., a dynamic CTA and a pseudo-static CTA. The dynamic CTA can be changed in position in each superframe, but cannot be used in a relevant superframe if the beacon of a superframe is lost. On the other hand, the pseudo static CTA remains unchanged in the same fixed position, and can be used in the fixed position even if the beacon of a superframe is lost. However, the pseudo static CTA cannot be used if a beacon is continuously lost over the number of times corresponding to mMaxLostBeacons. Therefore, since the 802.15.3 MAC is based on the TDMA system capable of ensuring QoS (Quality of Service), it is particularly suitable for multimedia audio deo (A/V) streaming on a home network. Nevertheless, MAC should be still further improved to effectively utilize throughput as well as QoS.

[5] There are two data transmission schemes in 802.15.3 MAC: i.e., an isochronous data transmission scheme and an asynchronous data transmission scheme.

[6] In the isochronous data transmission scheme, a channel time is first allocated from the PNC through a MAC sublayer Management Entity (MLME)-CREATE-STREAM.request. Then a MLME-CREATE-STREAM.confirm and data are actually transmitted during the allocated channel time through MAC- ISOCH-DATA.request and MAC-ISOCH-DATA.confirm, as shown in FIG. 2. The allocated channel time can be obtained by analyzing the beacon, and a device constituting the piconet (hereinafter referred to as 'DEN') can thus know the communication start time and comtnunication end time based on the obtained channel time. At this instant, a source device (src DEN) and a destination device (dest DEN) are assigned for the allocated channel time. The device for transmitting data in the allocated channel time must be the src DEN, but the device for receiving the data is not necessarily the dest DEN specified in the CTA information. However, a device capable of receiving the data is a device in which an 'Always AWAKE bit' or a 'listen to source bit' is set to 1.

[7] On the other hand, in the asynchronous data transmission scheme, the src DEN sends a channel time request command frame to the PΝC when the data to be transmitted arrive at a MAC layer via MAC-ASYΝC-DATA.request, as shown in FIG. 3. Then, when the src DEN knows from the beacon that a requested channel time has been allocated, data are transmitted during the allocated channel time. Similar to the isochronous data transmission scheme, a pair of src DEN and dest DEN are assigned for the allocated channel time and only the assigned src DEN can transmit data during the allocated channel time. In addition, as an alternative method for sending asynchronous data, there is provided a method for sending frames using a backoff algorithm in the Contention Access Period (CAP).

[8] To ensure the reliability of data transmission, TCPΛP is configured such that DENl transmits a frame to DEN2 and DEN2 returns an ACK frame (an ACK frame at the TCP/IP level, not an Iran- ACK frame as shown in FIGS. 2 and 3) to DENl. A problem occurring when a data transmission mechanism provided by the 802.15.3 MAC is directly used in the TCPΛP having this mechanism will be described in detail as follows.

[9] First, when TCPΪP data are isochronously transmitted, DENl will send DEN2 a frame for establishing a connection with DEN2. To this end, DENl first sends a PΝC MLME-CREATE-STREAM.request to request channel time allocation in which the src DEN is DENl and the dest DEN is DEN2. When the PΝC allocates channel time and sends a beacon containing information on the channel time, DENl reads information on the beacon and transmits the frame to DEN2 at the designated time. To send a response frame to the frame transmitted frcm DENl, DEN2 requests channel time allocation in which the src DEN is DEN2 and the dest DEN is DENl. Similarly, when the PΝC allocates channel time and sends a beacon containing information on the channel time, DEN2 reads information on the beacon and transmits a response frame to DENl at the designated time. Since the channel time continues to be allocated until MLME-TERMIΝATE-STREAM.request is received, the data and ACK frame exchanged between DEVI and DEN2 will be sent at the time allocated to the pair of src DEN and dest DEN according to the channel time information in the beacon. However, according to the characteristics of TCPΛP, until a sender receives an ACK frame after sending a data frame, the sender does not send other frames. Only the src DEN specified in the channel time allocation from the beacon can be a sender of the channel time in 802.15.3 MAC. Therefore, DEN2 should send an ACK frame at the TCPIP level after the channel time in which the src DEN is DEN2. Consequently, although the time allocated to DENl and DEN2 is remaining after DENl sends data, DENl cannot receive an ACK frame from DEN2 during the time left, and thus, a waste of channel time occurs.

[10] Second, a case where the TCPΛP frame is asynchronously transmitted will be discussed. When asynchronous data are sent to the Contention Access Period, the PΝC may or may not allocate the CAP to a superframe. Furthermore, even though there is an allocated CAP, the method of sending the TCPΛP frame using the CAP does not ensure reliable transmission of the TCPIP frame since the determination of whether the asynchronous data can be sent or not takes place during the period according to a criterion set by the PΝC. Next, to send asynchronous data through channel time allocation, a MAC-ASYNCH-DATA.request should be used as described above. Disclosure of Invention Technical Problem

[11] As shown in FIGS. 2 and 3, however, a data frame should be transmitted only after the channel time request command has been sent to the PNC and the channel time has been subsequently allocated. Such a successive transmission of data results in a waste of bandwidth. In addition, since it cannot be ensured that the requested channel time would be allocated even when the channel time allocation is requested, a device that attempts to transmit data should wait until at least the next superframe whenever each data frame is sent. Therefore, time delays will always occur.

[12] The aforementioned problems may occur not only in TCPSP but also when a protocol for exchanging data between two DENs is executed in a higher layer of the 802.15.3 MAC. Technical Solution

[13] The present invention is conceived to solve the aforementioned problems. The present invention aims to achieve effective communication in a higher protocol by improving 802.15.3 MAC (Media Access Control). To this end, a method of using CTA in the bi-directional transmissions other than the unidirectional transmissions in 802.15.3 MAC will be presented.

[14] According to one aspect of the present invention for achieving the objective, there is provided a method for exchanging data between devices on a wireless personal area network (PAN), comprising the steps of (1) generating a channel time request frame containing directional information to determine whether data transmission is unidirectional or bi-directional, and transmitting the channel time request frame to a device responsible for channel time allocation; (2) generating a frame containing channel time allocation information including the directional information based on the information contained in the channel time request frame, and broadcasting the generated frame; and (3) exchanging data between first and second devices, which are designated as source and destination devices in the frame containing the channel time allocation information, during a predetermined channel time in accordance with the directional information.

[15] Preferably, but not necessarily, the channel time request frame is a channel time request ccrαnand frame specified in IEEE 802.15.3.

[16] Preferably, but not necessarily, the device responsible for the channel time allocation is a piconet coordinator (PNC) specified in IEEE 802.15.3.

[17] Preferably, but not necessarily, the frame containing the channel time allocation in- formation is a beacon frame specified in IEEE 802.15.3. [18] Further, the step (3) comprises the steps of transmitting data from the first device to the second device, and transmitting a NULL frame to the second device when the first device has no further data to transmit after the data transmission. [19] Preferably, but not necessarily, the method for exchanging data between devices on a PAN further comprises the steps of: if the second device that received the NULL frame has data to be transmitted to the first device, transmitting the data to the first device; and if the second device has no data, transmitting an ACK frame for the data transmitted by the first device. [20] Preferably, but not necessarily, the method for exchanging data between devices on PAN further comprises the steps of: if the first device that received the ACK frame has data to be transmitted to the second device, transmitting the data to the second device; and if the first device has no data, transmitting the NULL frame to the second device. [21] Preferably, but not necessarily, the ACK frame is an intermediate ACK frame in a MAC layer. [22] Preferably, but not necessarily, the NULL frame is composed of only a MAC header. Description of Drawings [23] The above and other objects, features and advantages of the present invention will become apparent from the following description of preferred en±odiments given in conjunction with the accompanying drawings, in which: [24] FIG. 1 is a view showing the structure of a related art superframe;

[25] FIG. 2 is a view showing the process of requesting channel time allocation according to the prior art; [26] FIG. 3 is a view showing the process of transmitting asynchronous data according to the prior art; [27] FIG. 4 is a view showing the structure of a channel time request ccrαnand frame according to the present invention; [28] FIG. 5 is a view showing a structure of a beacon frame according to the present invention; [29] FIG. 6 is a view showing a first exemplary en±odiment where data are bi- directionally exchanged between devices within a given channel time; [30] FIG. 7 is a view showing the structure of a NULL frame;

[31] FIG. 8 is a table according to a first exemplary en±odiment showing frame type values in various kinds of frames; [32] FIG. 9 is a flowchart illustrating the overall operation of a first exemplary en±Ddiment;

[33] FIG. 10 is a view showing a second exemplary en±odiment where data are bi- directionally exchanged between devices within a given channel time;

[34] FIG. 11 is a view showing the structure of a TOKEN frame;

[35] FIG. 12 is a table of a second exemplary en±odiment showing frame type values in various kinds of frames;

[36] FIG. 13 is a flowchart illustrating the overall operation of a second exemplary en±odiment of the present invention;

[37] FIG. 14 is a view showing a superframe structure and a data transmission process in a case where unidirectional transmission is made according to the prior art; and

[38] FIG. 15 is a view showing a superframe structure and a data transmission process in a case where bi-directional transmission is made according to the present invention. Mode for Invention

[39] Hereinafter, an exemplary en±odiment of the present invention will be described in detail with reference to the accompanying drawings.

[40] A channel time period where roles of two DENs as a transmitting side and a receiving side are not fixed but dynamically exchanged is added, and a channel time is then requested of a PΝC (piconet coordinator) when a protocol where the two DENs should exchange data as in TCPΪP is executed in a higher MAC layer. The PΝC that functions to provide a variety of services to DENs in a piconet allocates the channel time, performs the synchronization between the DENs and performs an association function of causing the DENs to join the piconet, via a wireless ccrαnunication medium.

[41 ] For the exchange of data, a parameter of MLME-CREATE-STREAM.request provided by 802.15.3 MAC first needs to be modified. The following Table 1 shows the modified parameter of the MLME-CREATE-STREAM.request to which a new parameter of 'DirectionType' was added. 'DirectionType' defines directional information that is used to determine whether data transmission is unidirectional or bidirectional.

[42] Table 1 MLME-CREATE-STREAM.request { TrgtID, DSPSSetlndex, StreamRequestID, Streamlndex, ACKPolicy Priority, PNCTRqType, CTAType, CTARateType, CTARateFactor, DirectionType, CTRqTU, MinNinnTUs, DesiredNumTUs, RequestTimeout }

[43] The parameter of 'DirectionType' is defined as in the following Table 2. [44] Table 2

[45] Assume that DEVI sends data to DEV2 using the TCP/IP protocol. Firstly, DEVI calls MLME-CREATE-STREAM.request to request a channel time from the PNC. At this time, 'DirectionType' is set as 'TWO_WAY. When MLME of the DEVI receives the MLME-CREATE-STREAM.request, it sends the PNC a channel time request ccrαnand 100 as shown in FIG. 4. At this time, as illustrated in Table 1, a bit field for defining 'DirectionType' is added to the channel time request block 110 constituting the channel time request command 100. Although the 'DirectionType' field is allocated 1 octet, only 1-bit information is sufficient for this field because this field is '0' in the case of 'ONE_WAY and T in the case of 'TWO_WAY. Thus, this field actually uses only 1 bit and the remaining 7 bits are reserved.

[46] When resources of the ccrαnunication medium are sufficient even after the PNC receives the channel time request ccrαnand 100, the channel time is allocated to a relevant DEN via a beacon. FIG. 5 shows the structure of a beacon frame 200, the structure of a 'channel time allocation information element' field 210 of at least one 'Information element' field in the beacon frame, and the structure of at least one 'channel time allocation block' field 211 existing in the 'channel time allocation information element' field 210. The 'channel time allocation block' fields 211 is composed of a DestlD field for indicating the ID of a receiving DEN, a SrcID field for indicating the ID of a transmitting DEN, a DirectionType field that is defined in the present invention so as to indicate whether the data transmission direction is ONE_WAY or TWO_WAY, a Stream index field for indicating the identity of a data stream to be transmitted, a CTA location field for indicating the location of CTA in the superframe, and a CTA duration field for indicating the duration of CTA.

[47] During the channel time in which DirectionType is ONE_WAY, only a DEN that has been designated by SrcID, i.e. has sent the channel time request command 100 can be a sender. This is the same as in the existing 802.15.3. If the channel time in which DirectionType is TWO_WAY is allocated, both of two DENs to which SrcID and DestlD have been respectively assigned can be a sender to transmit desired data to the other DEN during the allocated channel time. The beacon includes a channel time allocation block 211 in which the DENl that has sent the channel time request ccrαnand 100 is designated by SrcID and DEN2 which is designated by DestlD. The DENl designated by SrcID will first become a sender based on the beacon information.

[48] Hereinbelow, FIGS. 6 through 9 illustrate a first exemplary embodiment of the present invention and FIGS. 10 through 13 illustrate a second exemplary embodiment of the present invention.

[49] In the first exemplary embodiment, a 'NULL' frame is transmitted when there remains no data to be transmitted by the src DEN and subsequently the dest DEN can transmit data. When there is no data to be transmitted although the dest DEN has received the NULL frame, it transmits again an Iron- ACK (Immediate ACK) to the src DEN, to thereby hand over an opportunity of transmitting the data again to the src DEN. Accordingly, the 'ACK-policy' of the NULL frame becomes 'Iran- ACK.'

[50] In the second exemplary embodiment, the src DEN sends a 'TOKEN frame' when there remains no data to be transmitted. In response, the dest DEN can transmit data. When there is no data to be transmitted although the dest DEN has received the TOKEN frame, it transmits again a TOKEN frame to the src DEN, to thereby hand over an opportunity of transmitting the data again to the src DEN. Accordingly, the 'ACK-policy' of the TOKEN frame becomes 'No-ACK.'

[51] The first exemplary embodiment of the present invention will be described with reference to FIGS. 6 through 9.

[52] FIG. 6 shows a process of exchanging data between DEVI and DEN2 during the channel time in which DirectionType is TWO_WAY. After receiving frcm the beacon the channel time allocation block 211 in which DENl that has sent the channel time request ccrαnand 100 is designated by SrcID and DEN2 is designated by DestlD, DENl first becomes a sender and transmits data to DEN2 at the designated time (S10). DEN2 sends an ACK frame in accordance with the ACK policy of the data frame received frcm DENl. An Iron- ACK (Immediate ACK) policy is assumed in this example (S20). If DENl has no data to be sent at this time, DENl transmits a NULL frame to DEN2 (S30). The NULL frame is a frame in which only a MAC header but no frame body portion is present, the structure of which is shown in FIG. 7. If there were seme frames to be sent in step S30, data frames would be sent instead of a NULL frame. If DEN2 has no data frame to be sent at the time when a NULL frame is received, an Iron- ACK is immediately transmitted (S40). After receiving the Imm- ACK in response to the previously sent NULL frame, DEVI transmits data to DEN2 if there are any data to be sent to DEN2, or transmits a NULL frame again to DEN2 if there are no data (S50). When DEN2 receives a NULL frame again and other data are then ready to be sent to DEVI, data frames, rather than an Imm-ACK are transmitted to DEVI (S60). Since DEVI did not receive an Imm-ACK frame but data frames in response to the previously sent NULL frame, DEVI sends DEN2 an Imm-ACK in response to the received data frame (S70). If DEN2 that received the Imm-ACK has further data, DEN2 continuously sends data. Otherwise, DEN2 sends a NULL frame to DEVI (S80). If DEVI has no data frame to be sent at that time, it transmits an Imm- ACK to DEN2 (S90). The above process is repeated until the channel time allocated to the two DENs ends.

[53] FIG. 7 shows a detailed structure of the 'NULL frame' proposed in the present invention. The NULL frame corresponds to a frame having only a MAC header and no frame body and has a size of 10 octets as in a conventional MAC header. Each field of the NULL frame has a size of 1 octet. Here, a Frame type field 710 is a field in which type values of the NULL frame are recorded. A table in which the type values of the various field frames are defined is shown in FIG. 8. These type values are recorded in b5, b4 and b3 bits of the MAC header and indicate what a relevant frame is according to the cαr±ination of the above bits. For example, '000' means a beacon frame and '001' means an Imm-ACK frame. Furthermore, a variety of type values such as a delayed ACK frame (value = '010'), a command frame (value = '011') and a data frame (value = '100') are specified in the existing IEEE 802.15.3. In the present invention, a new type value of NULL frame is added and specified as '101'.

[54] Referring again to FIG. 7, type values of the ACK frame according to the ACK policy are recorded in an ACK policy field 720. According to IEEE 802.15.3, the type values of the ACK frame are recorded in b8 and b7 bits of the MAC header, wherein 'No ACK' has a value of '00', 'Immediate ACK' has a value of '01' and 'Delayed ACK' has a value of '10'. Therefore, the ACK policy field has a value of '01' in this en±odiment. Further, the ID of a DEN for transmitting a relevant NULL frame is recorded in a DestlD field 730, and the ID of a DEN for receiving the relevant NULL frame is recorded in a SrcID field 740. Moreover, all field values of the MAC header become '0'.

[55] FIG. 9 is a flowchart illustrating the overall operation of the present invention.

[56] First, a first device generates a channel time request command frame, transmits the generated command frame to PNC, and receives an ACK for the transmitted command frame (S801). To this end, MLME-CREATE-STREAM.request is generated in DME ( Device Management Entity ) of the first device and then transmitted to MLME of the MAC. The MLME-CREATE-STREAM.request further includes a parameter of 'DirectionType' in addition to the existing parameters, as defined in the above Table 1. The MLME generates a command frame used for requesting the channel time, i.e. a channel time request ccmmand frame, and then transmits the generated command frame to the PNC via a physical layer.

[57] The PNC that received the ccmmand frame determines whether there are available resources in a current channel (wireless communication medium) (S802). If it is determined that there are no resources, a reason code of a channel time response command frame is properly expressed as 'priority unsupported', 'channel time unavailable', 'unable to allocate as pseudo-static CTA' or the like, and the channel time response command frame is then transmitted to the first device. If it is determined that there are available resources, a command frame responding to the channel time request, i.e. the channel time response command frame with a reason code thereof expressed as 'success', is transmitted to the first device and an Imm-ACK is then received from the first device (S803).

[58] Next, the PNC generates a beacon frame based on information existing in the received channel time request command frame and then broadcasts the beacon frame to the DENs that are members of the piconet (S804). The beacon frame includes information on channel time allocation, which in turn includes the duration of CTA, the location of CTA in a superframe, a stream index for data identification, the ID of the data transmitting device (the first device), the ID of the data receiving device (the second device), and a 'DirectionType' for indicating whether the data transmission is unidirectional (OΝE_WAY) or bi-directional (TWO_WAY). In this en±odiment, the 'DirectionType' is set to bi-directional, i.e. T. The first and second devices that have received the beacon frame containing the DirectionType information can know that data are exchanged between them in a bidirectional manner.

[59] Thereafter, when the start time of CTA at which the first and second devices can communicate with each other arrives ('Yes' in step S805), the first device transmits a data frame to the second device and then receives an Imm-ACK frame from the second device (S806). Since the data are segmented into unit frames having a length shorter than the maximum frame length and then transmitted, the data frame transmission procedure should be preformed twice or more so as to transmit data longer than the frame unit. Further, additional frame transmission procedures should be performed in order to transfer additional data after the above data have been fully transmitted.

[60] If there are no data frames to be transmitted by the first device ('No' in step S807) after the aforementioned data transmission procedures, the first device sends the second device a NULL frame indicating that there are no further data to be transmitted (S808).

[61] If the second device that received the NULL frame also has no data to be transmitted ('No' in step S809), the second device transmits an Imm-ACK to the first device (S810) and then returns to step S807. On the other hand, if there are any data ('Yes' in step S809), the second device transmits the data frames to the first device and receives an Imm-ACK from the first device (S811). Then, if there are further data to be transmitted by the second device ('Yes' in step S812), the data frame transmission step S811 is additionally performed. However, if there are no further data to be transmitted ('No' in step S812), the second device transmits a NULL frame to the first device (S813). Similarly, if the first device that received the NULL frame has data to be transmitted ('Yes' in step S814), the process returns to step S806. However, if there are no data, the first device transmits an Imm-ACK to the second device (S815) and the process then returns to step S812.

[62] Steps S806 to S815 are performed from the start time to end time of the relevant CTA. Further, if the end time of CTA arrives during any of the above steps, the process of FIG. 9 is terminated.

[63] Hereinbelow, the second exemplary embodiment of the present invention will be described with reference to the accompanying FIG. 10 to FIG. 13.

[64] FIG. 10 shows a process of exchanging data between DEVI and DEN2 during the channel time in which DirectionType is TWO_WAY. After receiving from the beacon the channel time allocation block 211 in which DENl that has sent the channel time request command 100 is designated by SrcID and DEN2 is designated by DestlD, DENl first becomes a sender and transmits data to DEN2 at the designated time (S 110). DEN2 sends an ACK frame in accordance with the ACK policy of the data frame received from DENl. An Imm-ACK (Immediate ACK) policy is assumed in this example (SI 20). If DENl has no data to be sent at this time, DENl transmits a TOKEN frame to DEV2 (SI 30). The TOKEN frame is a frame in which only a MAC header but no frame body portion is present, the structure of which is shown in FIG. 11. If there were some frames to be sent in step S 130, data frames would be sent instead of a TOKEN frame. If DEN2 has no data frame to be sent at the time when a TOKEN frame is received, another TOKEN frame is immediately transmitted (S140). After receiving the TOKEN frame in response to the previously sent TOKEN frame, DEVI transmits data to DEN2 if there are any data to be sent to DEN2, or transmits a TOKEN frame again to DEV2 if there are no data (S150). When DEV2 receives a TOKEN frame again and other data are then ready to be sent to DEVI, a data frame, rather than a TOKEN frame are transmitted to DEVI (S160). Since DEVI received a data frame in response to the previously sent TOKEN frame, DEVI sends DEN2 an Imm-ACK in response to the received data frame (S170). If DEN2 that received the Imm-ACK has further data, DEN2 continuously sends data. Otherwise, DEN2 sends a TOKEN frame to DEVI (S180). The above process is repeated until the channel time allocated to the two DENs ends.

[65] FIG. 11 shows a detailed structure of the 'TOKEN frame' proposed in the present invention. The TOKEN frame corresponds to a frame having only a MAC header and no frame body and has a size of 10 octets as in a conventional MAC header. Each field of the TOKEN frame has a size of 1 octet. Here, a Frame type field 710 is a field in which type values of the TOKEN frame are recorded. A table in which the type values of the various field frames are defined is shown in FIG. 12. These type values are recorded in b5, b4 and b3 bits of the MAC header and indicate what a relevant frame is according to the combination of the above bits. For example, '000' means a beacon frame and '001' means an Imm-ACK frame. Furthermore, a variety of type values such as a delayed ACK frame (value = '010'), a command frame (value = '011') and a data frame (value = '100') are specified in the existing IEEE 802.15.3. In the present invention, a new type value of a TOKEN frame is added and specified as '101.'

[66] Referring again to FIG. 11, type values of the ACK frame according to the ACK policy are recorded in an ACK policy field 720. According to IEEE 802.15.3, the type values of the ACK frame are recorded in b8 and b7 bits of the MAC header, wherein 'No ACK' has a value of '00', 'Immediate ACK' has a value of '01' and 'Delayed ACK' has a value of '10'. Therefore, the ACK policy field has a value of '00' in this en±odiment. Further, the ID of a DEN for transmitting a relevant TOKEN frame is recorded in a DestlD field 730, and the ID of a DEN for receiving the relevant TOKEN frame is recorded in a SrcID field 740. Moreover, all field values of the MAC header become '0.'

[67] FIG. 13 is a flowchart illustrating the overall operation of a second en±odiment of the present invention.

[68] First, a first device generates a channel time request command frame, transmits the generated command frame to PNC, and receives an ACK for the transmitted command frame (S901). To this end, MLME-CREATE-STREAM.request is generated in DME of the first device and then transmitted to MLME of the MAC. The MLME- CREATE-STREAM.request further includes a parameter of 'DirectionType' in addition to the existing parameters, as defined in the above Table 1. The MLME generates a command frame used for requesting the channel time, i.e. a channel time request command frame, and then transmits the generated command frame to the PNC via a physical layer.

[69] The PNC that received the command frame determines whether there are available resources in a current channel (wireless communication medium) (S902). If it is determined that there are no resources, a reason code of a channel time response command frame is properly expressed as 'priority unsupported', 'channel time unavailable', 'unable to allocate as pseudo-static CTA' or the like, and the channel time response command frame is then transmitted to the first device. If it is determined that there are available resources, a command frame responding to the channel time request, i.e. the channel time response command frame with a reason code thereof expressed as 'success', is transmitted to the first device and an Imm-ACK is then received from the first device (S903).

[70] Next, the PNC generates a beacon frame based on information existing in the received channel time request command frame and then broadcasts the beacon frame to the DENs that are members of the piconet (S904). The beacon frame includes information on channel time allocation, which in turn includes the duration of CTA, the location of CTA in a superframe, a stream index for data identification, the ID of the data transmitting device (the first device), the ID of the data receiving device (the second device), and a 'DirectionType' for indicating whether the data transmission is unidirectional (OΝE_WAY) or bi-directional (TWO_WAY). In this en±odiment, the 'DirectionType' is set to bi-directional, i.e. T. The first and second devices that have received the beacon frame containing the DirectionType information can know that data are exchanged between them in a bidirectional manner.

[71] Thereafter, when the start time of CTA at which the first and second devices can communicate with each other arrives ('Yes' in step S905), the first device transmits a data frame to the second device and then receives an Imm-ACK frame from the second device (S906). Since the data are segmented into unit frames having a length shorter than the maximum frame length and then transmitted, the data frame transmission procedure should be performed twice or more so as to transmit data longer than the frame unit. Further, additional frame transmission procedures should be performed in order to transfer additional data after the above data have been fully transmitted.

[72] If there are no data frames to be transmitted by the first device ('No' in step S907) after the aforementioned data transmission procedures, the first device sends the second device a TOKEN frame indicating that there are no further data to be transmitted (S908). If the second device that received the TOKEN frame also has no data to be transmitted ('No' in step S909), the second device transmits an Imm-ACK to the first device (S910) and then returns to step S907. On the other hand, if there are any data ('Yes' in step S909), the second device transmits the data frames to the first device and receives an Imm-ACK from the first device (S911). Then, if there are further data to be transmitted by the second device ('Yes' in step S912), the data frame transmission step S911 is additionally performed. However, if there are no further data to be transmitted ('No' in step S912), the second device transmits a TOKEN frame to the first device (S913). Similarly, if the first device that received the TOKEN frame has data to be transmitted ('Yes' in step S914), the process returns to step S906. However, if there are no data, the first device transmits a TOKEN frame to the second device (S915) and the process then returns to step S912.

[73] Steps S906 to S915 are performed from the start time to end time of the relevant CTA. Further, if the end time of the CTA arrives during any of the above steps, the process of FIG. 13 is terminated.

[74] Hereinafter, a difference in transmission efficiency between unidirectional transmission in the CTA according to the prior art and bi-directional transmission in the CTA according to the present invention is compared with reference to FIGS. 14 and 15.

[75] FIG. 14 is a view showing the structure of a superframe 900 and a data transmission process when unidirectional transmission is made according to the prior art. When two devices DEVI and DEN2 exist on a piconet and DENl attempts to transmit a stream to DEN2 using TCPΛP, a data frame is transmitted from DENl and DEN2 and an ACK frame for the data frame is transmitted from DEN2 to DENl. It is assumed that an ACK policy for use in a MAC layer is an IMM-ACK policy, the superframe duration is 10ms, and CAP is 1ms. Further, it is also assumed that the transmission rate of a MAC header is 22Mbps and the transmission rate of a frame payload is 55Mbps.

[76] If both DENl and DEN2 have requested a super-rate CTA with a rate factor of 1, the superframe 900 will be used as illustrated in FIG. 14. It is now assumed that there are no information elements (IE) other than CTA IE and BSID IE in the superframe 900 as shown in HG. 14.

[77] A beacon 910 is composed of a MAC header of 10 bytes, piconet synchronization parameters of 21 bytes, a CTA IE of 16 bytes (because this example has information on two CTAs), and a BSID IE Of 20 bytes (it is assumed that the size of BSID is 10 bytes). As a result of the calculation in the following Table 3, it takes about 0.012ms to transmit the beacon so constructed.

[78] Table 3

Header transmission time: (10 x 8 bits) x 1000 ms / 22 Mbps = 0.0036 ms, Payload transmission time: (21 + 16 + 20) x 8 bits x 1000 ms / 55 Mbps = 0.0082 ms

[79] The transmission durations of CTAl 930 and CTA2 940 depend on the size of the TU (time unit) and the desired number of TUs that DENl and DEN2 request the PΝC to send, respectively. The TU should transmit at least one frame according to the specified ACK policy. If the remaining time except for beacon transmission time and CAP 920 is allocated to each of DENs, CTAl 930 in which the src DEN is DENl and the best DEN is DEN2 and the CTA2 940 in which the src DEN is DEN2 and the dest DEN is DENl will be allocated as illustrated in FIG. 14 because it was assumed that both DENl and DEN2 have requested a super-rate CTA with a rate factor of 1. The durations of CTAl 930 and CTA2 940 can be changed according to the channel time allocation algorithm of the PΝC and the TU requested by each DEN.

[80] When the start time of CTAl 930 arrives, DEN 1 first transmits a first frame 950 to DEN2. At this time, a payload of the first frame 950 is a data frame of the TCPΪP. Since a maximum frame length is 2048 bytes (except for the MAC header), the transmission time of the first frame 950 is 0.3014ms as illustrated in the following Table 4 if it is assumed that a length of the first frame 950 is 2048 bytes.

[81] Table 4

(MAC header transmission time) + (2048 x 8bits) x 1000ms / 55Mbps = 0.0036ms + 0.2979ms = 0.3014ms

[82] ACK1 960 is an ACK frame that is sent frcm DEN2 to DENl and transmitted according to the ACK policy of the MAC in the MAC layer. Since the ACK frame is composed of only a MAC header in IEEE 802.15.3, it will take 0.0036ms to transmit the ACK frame.

[83] Since frames are transmitted through the TCPSP in a higher layer of the MAC layer in this example, the DENl can no longer transmit a new frame if it does not receive the ACK frame of a TCP/IP level frcm DEN2. When DENl transmits a frame to DEN2 using TCPIP, DEN2 should send an ACK frame for the transmitted frame. Since this ACK frame is transmitted in the higher layer of the MAC layer separately from an ACK (for example, the Imm-ACK) that is sent in the MAC layer, it will be processed in the same way as other data frames in view of the MAC layer. As shown in FIG. 14, a second frame represents an ACK frame of the TCPIP level which DEN2 transmits to DENl. Even though DEN2 attempts to send the second frame to DENl, DEN2 should wait until the channel time in which DEN2 itself is allocated as the src DEN. Accordingly, the second frame 970 can be transmitted only when the start time of CTA2 940 arrives. ACK2 980 is an ACK frame of a MAC layer level that will be transmitted according to the ACK policy of the MAC layer.

[84] As described above, when the CTA system of the existing 802.15.3 is employed, one frame with the size of 2048 bytes is transmitted from DENl to DEN2 during the superframe of 10ms and vice versa.

[85] FIG. 15 is a view showing the structure of a superframe 900 and the data transmission process when bi-directional transmission is made according to the present invention. When DENl requests the PΝC to allocate a channel time in which DirectionType is TWO_WAY, a relevant superframe is configured as shown in FIG. 15. Similarly in FIG. 14, it is also assumed that the whole remaining time except for the beacon transmission time and CAP 920 is allocated to the DENs. The first frame 950 is a TCPIP data frame that will be sent frcm DENl to DEN2 and the second frame 970 is an ACK frame of a TCPIP level that will be sent from DEN2 to DENl. It is also assumed that one NULL frame or TOKEN frame 990 has been transmitted between the first and second frames in consideration of a processing time consumed until the second frame 970 is transmitted. Then, the time taken from when one TCPIP data frame is sent from DEVI to DEV2 to when an ACK frame of a TCPIP level for the data frame is received is calculated as illustrated in the following Table 5.

[86] Table 5 A =First frame transmission time + SIFS + ACK1 transmission time + SIFS + NULL frame (or TOKEN frame) transmission time + SIFS + Second frame transmission time + SIFS +ACK2 transmission time + SIFS = 0.3015ms +0.01ms + 0.0036ms + 0.01ms +0.0036ms + 0.01ms + 0.3015ms + 0.01ms +0.0036ms + 0.01ms = 0.6638ms

[87] Accordingly, the result illustrated in the following Table 6 will be obtained by dividing a value, which is obtained by subtracting the beacon 910 transmission time and CAP 920 from the superframe 900 of 10ms, by the time A.

[88] Table 6

(10 - 0.012 - 0.01 - 1) 70.6638 = 13

[89] According to this result, DEVI can send DEN2 13 frames, each of which has a size of 2048 bytes during a unit superframe and vice versa. Of course, if the channel time is requested to the PΝC with a CTA rate factor designated as a number exceeding 1, more data than in FIG. 14 can be transmitted. However, since the channel time allocation can be changed according to rate factors or the channel time allocation algorithm of the PΝC, and it cannot be ensured that the maximum channel time can be always available, it is more efficient to employ a channel time having a DirectionType as proposed in the present invention. Industrial Applicability

[90] Since a source device and a destination device are fixed in a channel time provided by the existing 802.15.3 MAC, only one device can send data during the channel time whereas the other device should merely receive the data. Therefore, as described above, it is not efficient to a protocol, such as TCPIP, by which frames should be exchanged between devices. According to the present invention, such inefficiency can be reduced and overall transmission efficiency can thus be improved. [91] Although the present invention has been described in connection with the preferred embodiment of the present invention, it will be apparent to those skilled in the art that various modifications and changes may be made thereto without departing from the scope and spirit of the invention. Therefore, it should be understood that the above embodiment is not restrictive but illustrative in all aspects. The scope of the present invention is defined by the appended claims rather than the detailed description of the invention. All modifications and changes derived from the scope and spirit of the claims and equivalents thereof should be construed to be included in the scope of the present invention.

Claims

[1] A method for exchanging data between devices on a wireless personal area network (PAN), comprising: (a) generating a channel time request frame containing directional information to determine whether data transmission is one of unidirectional and bi-directional, and transmitting the channel time request frame to a device responsible for channel time allocation; (b) generating a frame containing channel time allocation information including the directional information based on information contained in the channel time request frame, and broadcasting the generated frame; and (c) exchanging data between first and second devices, which are designated as source and destination devices in the frame containing the channel time allocation information, during a predetermined channel time in accordance with the directional information.

[2] The method as claimed in claim 1, wherein the channel time request frame is a channel time request command frame specified in IEEE 802.15.3.

[3] The method as claimed in claim 1, wherein a device responsible for the channel time allocation is a piconet coordinator (PNC) specified in IEEE 802.15.3.

[4] The method as claimed in claim 1, wherein the frame containing the channel time allocation information is a beacon frame specified in IEEE 802.15.3.

[5] The method as claimed in claim 1, wherein the step (c) comprises: transmitting data from the first device to the second device; and transmitting a NULL frame to the second device when the first device has no further data to be transmitted after the data transmission.

[6] The method as claimed in claim 5, wherein the step (c) further comprises: transmitting the data to the first device if the second device that received the NULL frame has data to be transmitted to the first device; and transmitting an acknowledgement (ACK) frame for the data transmitted by the first device if the second device has no data.

[7] The method as claimed in claim 6, wherein the step (c) further comprises: transmitting the data to the second device if the first device that received the ACK frame has data to be transmitted to the second device; and transmitting the NULL frame to the second device if the first device has no data.

[8] The method as claimed in claim 6, wherein the ACK frame is an intermediate ACK frame in a Media Access Control (MAC) layer.

[9] The method as claimed in claim 5, wherein the NULL frame is composed only of a Media Access Control (MAC) header and has an immediate ACK policy.

[10] The method as claimed in claim 1, wherein the step (c) comprises: transmitting data from the first device to the second device; and transmitting a first TOKEN frame to the second device when the first device has no further data to be transmitted after the data transmission.

[11] The method as claimed in claim 10, wherein the step (c) further comprises: transmitting the data to the first device if the second device that received the TOKEN frame has data to be transmitted to the first device; and transmitting a second TOKEN frame for the data transmitted by the first device if the second device has no data.

[12] The method as claimed in claim 11, wherein the step (c) further comprises: transmitting the data to the second device if the first device that received the second TOKEN frame has data to be transmitted to the second device; and transmitting the TOKEN frame to the second device if the first device has no data.

[13] The method as claimed in claim 10, wherein the first TOKEN frame is composed only of a Media Access Control (MAC) header, and has a No ACK policy.