WO2010024784A1

WO2010024784A1 - Methods and devices for requesting radio resources and/or synchronization within a radio communication system

Info

Publication number: WO2010024784A1
Application number: PCT/SG2009/000303
Authority: WO
Inventors: Ananth Subramanian; Xiaoming Peng; Po Shin Francois Chin
Original assignee: Agency for Science Technology and Research Singapore
Current assignee: Agency for Science Technology and Research Singapore
Priority date: 2008-08-28
Filing date: 2009-08-28
Publication date: 2010-03-04
Anticipated expiration: 2011-02-28
Also published as: CN102132617A; TW201012157A

Abstract

A method for requesting radio resources in a radio communication system comprises generating and encoding a first request message for radio resources including a plurality of slotted time/frequency portions, wherein the first request message includes an Information Element encoded in accordance with a first communication protocol format which can be decoded by a terminal of a first type configured to provide slotted time/frequency communication and by a terminal of a second type configured to provide slotted time/frequency communication and slotted offset time/frequency communication. A method of synchronizing a first terminal device with a second terminal in a radio communication system comprising a determining whether the second terminal has not changed its synchronization transmission period start time for a predetermined time and setting the synchronization transmitting period start time of the first radio terminal to the synchronization transmitting start time of the second terminal.

Description

METHODS AND DEVICES FOR REQUESTING RADIO RESOURCES AND/OR SYNCHRONIZATION WITHIN A RADIO COMMUNICATION SYSTEM

[0001] The present application claims the benefit of the United States provisional application 61/092,467 (filed on 28 August 2008), the entire contents of which are incorporated herein by reference for all purposes.

Technical Field

[0002] Embodiments relate to the field of communication systems, such as radio communication systems, for example. By way of example, embodiments relate to methods of requesting and reserving radio resources. By way of example, embodiments relate to methods of synchronizing among the radio communication terminal devices within the radio communication system. For example, the radio communication system may be an ad hoc radio communication system comprising a plurality of ad hoc radio communication terminal devices.

Background

[0003] A communication system generally consists of a plurality of communication devices, wherein the communication among the communication devices are either central-controlled or self-organized.

[0004] An ad hoc radio communication group generally includes a plurality of ad hoc radio communication terminal devices, wherein the communication among these devices is self-organized. The plurality of devices are able to discover each other within a range to form the communication group, and within the communication group, they can communicate with each other without the need of a central control. [0005] Orthogonal Frequency Division Multiplexing (OFDM) is a widely used technique in ad hoc radio communication systems. OFDM is a multi-carrier transmission technique, which divides the available frequency spectrum into many subcarriers, each one being modulated by a low data rate stream. OFDM can achieve high-speed data transmission and high spectral efficiency. So far, several OFDM based standards have been put forward, such as the ECMA standard [I]. [0006] A multi-band OFDM scheme is used to transmit information in the ECMA standard [I]. In operation, for example, a plurality of ad hoc radio communication terminal devices tend to operate as an ad hoc communication group (beacon group) in a particular frequency channel. In [1], when the ad hoc radio communication terminal devices in a particular beacon group under normal equilibrium operation are tuned to a particular frequency channel, the devices end up using only up to three frequency bands of the available fourteen frequency bands. Moreover, a frequency band in one of the three utilized frequency bands is only used up to one-third of the time (if devices operate in respective time-frequency-codes). The above translates to low spectral usage and unutilized bands of frequencies.

[0007] Reference [2] proposed a method of enhancing the network throughput by using the slotted offset Time-Frequency Codes (TFCs).

Summary

[0008] In one embodiment, a method for requesting radio resources in a radio communication system is provided.

[0009] In one embodiment, the method includes generating and encoding a first request message for radio resources including a plurality of slotted time/frequency portions. In one embodiment, the first request message includes an Information Element being encoded in accordance with a first communication protocol format which can be decoded by a radio communication terminal device of a first type being configured to provide only slotted time/frequency portion communication without slotted offset time/frequency portion communication and by a radio communication terminal device of a second type being configured to provide slotted time/frequency portion communication and slotted offset time/frequency portion communication, hi one embodiment, the method may further include, in case the radio resources requested by the first request message are not available, generating and encoding a second request message for radio resources including a plurality of slotted offset time/frequency portions. In one embodiment, the second request message may include an Application Specific Information Element being encoded in accordance with a second communication protocol format which can be decoded by a radio communication terminal device of the second type. [0010] In one embodiment, a method for determining available radio resources in a radio communication system is provided. In one embodiment, the method may include determining as to whether required radio resources including a plurality of slotted offset time/frequency portions are available. In one embodiment, the method may further include, in case the required radio resources are not available, determining as to whether required radio resources including a different plurality of slotted offset time/frequency portions are available using a request message for the radio resources. In one embodiment, the request message may include an Application Specific Information Element being encoded in accordance with a communication protocol format which can be decoded by a radio communication terminal device of a type being configured to provide slotted time/frequency portion communication and slotted offset time/frequency portion communication.

[0011] In one embodiment, a method for synchronizing at least a first radio communication terminal device with a second radio communication terminal device in a radio communication system is provided. In one embodiment, the method may include determining as to whether the second radio communication terminal device has not changed its synchronization transmitting period start time for a predetermined time. In one embodiment, the method may further include determining the synchronization transmitting period start time of the second radio communication terminal device. In one embodiment, the method may further include, in case the second radio communication terminal device has not changed its synchronization transmitting period start time for a predetermined time, setting the synchronization transmitting period start time of the first radio communication terminal device to the synchronization transmitting period start time of the second radio communication terminal device.

[0012] In one embodiment, a method for synchronizing a first plurality of radio communication terminal devices with a second plurality of radio communication terminal devices in a radio communication system is provided. In one embodiment, the method may include, in a radio communication terminal device of the second plurality, carrying out: determining a synchronization transmitting period start time of a radio communication terminal device of the first plurality. In one embodiment, the method may include, in a radio communication terminal device of the second plurality, carrying out: setting the synchronization transmitting period start time of the radio communication terminal device of the second plurality to the determined synchronization transmitting period start time of the radio communication terminal device of the first plurality. In one embodiment, the method may include, in a radio communication terminal device of the second plurality, carrying out: generating a synchronization message including information about the determined synchronization transmitting period start time of the radio communication terminal device of the first plurality.

[0013] According to other embodiments, devices according to the methods described above are provided.

[0014] It should also be noted that the embodiments describing the methods are also analogously valid for the corresponding devices where applicable.

Brief Description of the Drawings

[0015] In the drawings, like reference characters generally refer to the same parts throughout the different views. The drawings are not necessarily to scale, emphasis instead generally being placed upon illustrating the principles of various embodiments. In the following description, various embodiments are described with reference to the following drawings, in which:

FIG. 1 shows an illustration of ad hoc radio communications among ad hoc radio communication terminal devices within an ad hoc radio communication devices' group in accordance with an embodiment;

FIG. 2 shows an illustration of a method to transmit OFDM symbols according to one embodiment;

FIG. 3 shows an illustration of the structure of a superframe in accordance with an embodiment;

FIG. 4 shows format of the Application Specific Information Element (ASIE) in accordance with an embodiment;

FIG. 5 shows the format of the payload of Application Specific Command/Control frames in accordance with an embodiment;

FIG. 6 shows the format of the Application Specific Probe Information Element in accordance with an embodiment; FIG. 7 shows the format of the Application Specific Control field according to one embodiment;

FIG. 8 shows an example format of the Application Specific Data field of the ASIE according to one embodiment;

FIG. 9 (a) shows the format of the Application Specific Identifier field of the Application Specific Data field of the ASIE according to one embodiment;

FIG. 9 (b) shows the format of the Field Information octet of the Application Specific Identifier field according to one embodiment;

FIG. 9 (c) shows the correspondence of the value of the Field Type in the Field Information Octet with the element type in accordance with an embodiment;

FIG. 10 (a) shows the format of a Control element according to one embodiment;

FIG. 10 (b) shows the format of the Control Element Information octet in the Control element in accordance with an embodiment;

FIG. 11 (a) shows the format of a Command Element according to one embodiment;

FIG. 11 (b) shows the format of the Command Element Information octet in the Command element in accordance with an embodiment;

FIG. 12 (a) shows the format of Query Information field in accordance with an embodiment;

FIG. 12 (b) shows the format of Query Control octet in the Query Information field according to one embodiment;

FIGs. 13 (a)-(c) show an illustration of the details of Modified Distributed Reservation Protocol (DRP) IE according to one embodiment;

FIGs. 14 (a)-(c) show an illustration of the proposed Modified Prioritized Channel Access (PCA) Availability IE according to one embodiment;

FIGs. 15 (a)-(c) show an illustration of the proposed Modified Relinquish Request IE according to one embodiment;

FIGs. 16 (a)-(b) show an illustration of the proposed Modified PHY Capabilities IE according to one embodiment;

FIGs. 17 (a)-(c) show an illustration of the proposed Enhanced DRP Availability IE according to one embodiment; FIG. 18 (a) shows an illustration of an ad hoc radio communication system according to one embodiment;

FIG. 18 (b) shows a method of reserving radio resources according to one embodiment;

FIG. 18 (c) shows a method of reserving radio resources according to one embodiment;

FIG. 18 (d) shows an ad hoc radio communication terminal device according to one embodiment;

FIG. 18 (e) shows an ad hoc radio communication terminal device according to one embodiment;

FIG. 19 shows an illustration of the back off module and protocol according to one embodiment;

FIG. 20 (a) shows the format of the payload for Link Feedback command frame according to one embodiment;

FIG. 20 (b) shows the format of the Link Feedback Control field in one embodiment;

FIG. 20 (c) shows the format of Link Information field in one embodiment;

FIG. 21 (a) shows an alternative format of the Link Information field according to one embodiment;

FIG. 21 (b) shows the format of the Device List field in one embodiment;

FIG. 22 (a) shows the format of the payload for the Command or Control frame according to one embodiment;

FIG. 22 (b) shows the format of the Link Feedback Control octet according to one embodiment;

FIG. 22 (c) shows an alternative format of the Link Feedback Control octet according to one embodiment;

FIG. 23 (a) shows an illustration of a synchronization method according to one embodiment;

FIG. 23 (b) shows an illustration of an ad hoc radio communication terminal device according to one embodiment; FIG. 24 shows the format of the Enhanced BP Switch IE according to one embodiment;

FIG. 25 (a) shows an illustration of a synchronization method according to one embodiment;

FIG. 25 (b) shows an illustration of an ad hoc radio communication terminal device according to one embodiment;

FIG. 26 shows an illustration of a synchronization method according to one embodiment; and

FIG. 27 shows the possible values of some parameters used in the synchronization method.

Description

[0016] It should be noted that although different exemplary embodiments of the present invention are described in context of ad hoc radio communication terminal devices and ad hoc radio communication systems, the scope of the application of the present invention does not only apply to an ad hoc radio communication system comprising of a plurality of ad hoc radio communication terminal devices but also applies to a general radio communication system comprising a plurality of radio communication devices wherein the radio communication system may comprise a central control of the plurality of radio communication devices.

[0017] As used herein, the term frequency band may refer to a predefined continuous frequency range, which may be used for signal transmission. In the context of this description, a frequency band may often be referred to using a (frequency) band number associated with it.

[0018] Further, the term frequency channel may refer to a combination of one or more frequency bands, and such a combination may be used for signal transmission as well. In this context, a frequency channel may or may not have a continuous frequency range. In the context of this description, a frequency channel is often referred to using a frequency channel number associated with it. [0019] Additionally, the term band group may refer to a group of frequency bands. A band group may or may not be used for signal transmission. It is possible that a frequency channel may have the same frequency bands as a band group.

[0020] Still further, the term Time-Frequency Code (TFC) may include a frequency hopping pattern, wherein some patterns hop among frequency bands and some stay fixed in a single frequency band. For example, the ECMA standard [1] specifies 3 types of TFCs: one is referred to as Time-Frequency Interleaving (TFI) where the coded information is interleaved over three frequency bands; one is referred to as two-band TFI or TFI2, where the coded information is interleaved over two frequency bands; one is referred to as Fixed Frequency Interleaving (FFI), where the coded information is transmitted on a single band. Under the ECMA standard [1] and as used hereinafter, the terms "Time-Frequency Codes (TFC)" and "frequency hopping pattern" are synonymous with the term "frequency channel".

[0021] In general, in the ECMA standard (reference [I]) for OFDM transmission system, when an ad hoc radio communication group operates in a particular frequency channel, a frequency band in a frequency band group is utilized only up to a maximum of a certain portion of the time. For example according to the ECMA standard [1], a frequency band is used only up to a maximum of one-third of the time if TFI is used. Further, if a device is transmitting in a particular frequency band during an OFDM symbol duration, the other bands in the band group (and possibly other band groups) are unutilized during that OFDM symbol transmission time.

[0022] In the present invention, methods and ad hoc radio communication terminal devices for requesting and reserving radio resources based on the use of slotted offset TFCs as proposed in reference [2] are provided. Further, methods for synchronization among ad hoc radio communication terminal devices within the ad hoc radio communication system based on the enhanced synchronization scheme as disclosed in reference [3] are provided in various embodiments. Further, formats for the data fields in the Application Specific Information Element (ASIE), Application Specific Probe Information Element, Application Specific Control Frame, and Application Specific Command Frame as defined in the ECMA specification [1] are given in various embodiments. [0023] For example, FIG. 1 shows an illustration of an ad hoc radio communication group 100 including ad hoc radio communication terminal devices A to H (111 -118), wherein all the devices A to H (111-118) work in a particular frequency channel. For illustration, circle line 101 represents the transmission range of device B 112, meaning that device B is able to transmit OFDM symbols to other devices that are located within the circle line 101. In this illustration, device B 112 is able to transmit OFDM symbols to devices A 111, C 113, D 114, E 115, and H 118. Similarly, circle line 102 represents the transmission range of device C 113, meaning that device C is able to transmit OFDM symbols to other devices that are located within the circle line 102, and circle line 103 represents the transmission range of device D 114, meaning that device D is able to transmit OFDM symbols to other devices that are located within the circle line 103. According to the current ECMA standard [1], for example, when device A l I l sends OFDM symbols to device B 112, no other data transmission among the ad hoc radio communication devices C, D, E, G, and H (113, 114, 115, 117 and 118) in the radio communication devices' group 100 could be carried out at the same time. [0024] In the ECMA standard [1] for OFDM transmission system, transmission of OFDM symbols from device A 111 to device B 112 is illustrated in FIG. 2, wherein device A l I l transmits OFDM symbols to device B 112 in a frequency band group 201. The band group 201 includes three frequency bands 211 , 221 , and 231. When TFI is used, transmitted OFDM symbols is interleaved over three frequency bands 211, 221, and 231 according to a frequency hopping pattern, such as illustrated in the grey colored boxes 241-246. Accordingly, a frequency band is used only up to a maximum of one-third of the time during the transmission. Further, when device A 111 is transmitting data to device B 112 in a particular frequency band during an OFDM symbol duration time, the other bands in the band group are unutilized during that OFDM symbol transmission time. Thus, the spectral usage is low due to the unutilized bands of frequencies. [0025] 1. Slotted Offset TFCs

[0026] Methods for achieving higher throughput in a network of ECMA [1] specified devices were proposed in reference [2]. The schemes proposed in [2] were based on a Slotted Offset TFC concept that allows efficient utilization of the bandwidth available to WiMedia/ECMA [1] specified devices. The slotted offset TFC based method is summarized in the following.

[0027] Reference [2] proposes the use of slotted offset Time Frequency Codes (TFCs) to utilize the available spectrum (say, entire band group) effectively at a given time by a particular beacon group. Using offset TFCs proposed in [2], the entire band group may be utilized at the same time. The method proposed in [2] is summarized as below. [0028] Assume that OFDM symbols are transmitted with a frequency hopping pattern among the three frequency bands as (band 211) to (band 221) to (band 231) as shown in the grey colored boxes in FIG. 2. For example, a device will transmit a first OFDM symbol in the frequency band 211 during a first OFDM symbol time 202, transmit a second OFDM symbol in the frequency band 221 during a second OFDM symbol time 203, and transmit a third OFDM symbol in the frequency band 231 during a third OFDM symbol time 204. After this, the device will send a fourth OFDM symbol restarting from the frequency band 211 during a fourth OFDM symbol time 205, and follow the frequency hopping pattern of (band 211) to (band 221) to (band 231) in the subsequent OFDM symbol transmissions. Also referring to FIG. 2, it can be seen that the black colored boxes 261-266 as well as the white colored boxes 251-256 represent the same frequency hopping pattern as the grey colored boxes 241-246, with the only exception of the starting frequency band for transmission of the first OFDM symbols. Such a difference can be interpreted in another way: the black colored boxes 261-266 as well as the white colored boxes 251-256 respectively represent a slotted offset time/frequency portions of the slotted time/frequency portions represented by the grey colored boxes 241-246. That is, the black colored boxes 261-266 as well as the white colored boxes 251-256 respectively represent an offset of the frequency hopping pattern, or a time shifted version of the frequency hopping pattern represented by the grey colored boxes 241-246. For example, the black colored boxes 261-266 represent a time shifted version of the frequency hopping pattern relative to the frequency hopping pattern represented by the grey colored boxes 241-246. That is, the black colored boxes 261-266 represent a slotted offset time/frequency portions relative to the slotted time/frequency portions represented by the grey colored boxes 241-246. Similarly, the white colored boxes 251- 256 represent a still larger time shifted version of the frequency hopping pattern relative to the frequency hopping pattern represented by the grey colored boxes 241-246. That is, the white colored boxes 251-256 represent another set of slotted offset time/frequency portions relative to the slotted time/frequency portions represented by the grey colored boxes 241-246. According to reference [2], a first ad hoc radio communication device of the ad hoc radio communication devices' group (not shown) may transmit a first OFDM symbol within a first frequency band 211 during a first OFDM symbol transmission time 202 (see grey colored box 241 in FIG. 2). In the same transmission time period 202, a second ad hoc radio communication device may transmit a second OFDM symbol in a second frequency band 221 (see white colored box 251 in FIG. 2), wherein the second frequency band 221 is different from the first frequency band 211. Further, in the same transmission time period, a third ad hoc radio communication device of the ad hoc radio communication devices' group may transmit a third OFDM symbol in a third frequency sub-range, wherein the third frequency sub-range is different from the first and second frequency sub-ranges. This embodiment of reference [2] is also illustrated in FIG. 2. In the same transmission time period 202 of the first and second OFDM symbols transmitted by two separate devices, a third ad hoc radio communication device (not shown) may transmit a third OFDM symbol in a third frequency band 231 (see black colored box 261 in FIG. 2), wherein the third frequency band 231 is different from the first frequency band 211 and second frequency band 221.

[0029] It thus can be seen that according to reference [2], the entire band group may be utilized at the same time. For example, in FIG. 2, the grey colored boxes 241-246 constitute TFC offset 0, the black colored boxes 261-266 constitute TFC offset 1, and white colored boxes 251-256 constitute TFC offset 2. Here, TFC offset 0, TFC offset 1, and TFC offset 2 are within a same frequency channel (same frequency hopping pattern) and are three offsets of the frequency channel that can be used for transmission of OFDM symbols. TFC offset 1 and TFC offset 2 have a frequency pattern time shifting with respect to TFC offset 0 within the same hopping pattern. In this context, the TFC offset 0 is also referred to as default TFC offset, or slotted TFC with no offset. TFC offset 1 has a time shifted version of the frequency hopping pattern relative to TFC offset 0, and TFC offset 2 has a still larger time shifted version of the frequency hopping pattern relative to TFC offset 0. For a frequency channel with 3 frequency bands, there can only be up to two offsets of a TFC (offset 0). In this context, an ad hoc radio communication terminal device according to the ECMA standard [1] is referred to as a device which can only use the slotted time/frequency portions for transmission, hi this context, an ad hoc radio communication device which may use different offset(s) of the slotted time/frequency portions for communication is referred as a device which can use slotted offset time/frequency portions for communication. Now, refer to FIG. 1. If a device A l I l sends OFDM symbols to device B 112 using TFC offset 0, device C 113 would be able to send OFDM symbols to device D 114 simultaneously using TFC offset 1. Similarly, device E 115 would be able to send OFDM symbols to device F 116 at the same time using TFC offset 2. Hence up to three transmissions can go on simultaneously, thereby increasing the network throughput up to three times using a single band group compared with the ECMA standard (reference [I]). In addition to the benefit of offset TFCs mentioned above, another benefit is that a device with three separate RF chains while transmitting data to another device would be able to receive data from up to two other devices using two offsets of TFC offset 0.

[0030J hi the slotted offset TFCs implementation proposed in [2], all the devices that are synchronized assume that their first OFDM symbol starts at the Beacon Period Start Time (BPST) of the slowest neighbor or the average of the BPSTs of all the devices in a beacon group. In this regard, Beacon Period (BP) may be defined as a period of time declared by a device during which it sends or listens for beacons according to the ECMA standard [1], and the term beacon may refer to information regarding such as the reservation of time slots in the further data period. Each superframe starts with a BP, which extends over one or more contiguous Medium Access Slots (MASs). The start of the first MAS in the BP, and the superframe, is called the Beacon Period Start Time (BPST). As background information, under the ECMA standard [1], frame is defined as unit of data transmitted by a device, and a superframe is the basic timing structure for frame transmissions. A superframe may be composed of 256 MASs, and a superframe may include a BP followed by a data period. A BP may include a number of beacon slots, and a beacon can be transmitted within a beacon slot. An ad hoc radio communication terminal device may start its OFDM transmission in a MAS in the data period at the start of that MAS. [0031] FIG. 3 illustrates the basic structure of superframe 310 according to the ECMA standard (reference [I]). According to the ECMA standard [1], a superframe is defined as periodic time interval used to coordinate frame transmissions between devices, which contains a beacon period 301 followed by a data period 302, wherein frame is defined as unit of data transmitted by a device. A superframe is composed of 256 MASs 303. [0032] An OFDM in-band time (in a band) including band switching time is 312.5ns + 9.47ns = 321.97ns according to ECMA standard [I]. With the slotted offset TFCs, each OFDM symbol is transmitted only during an OFDM Symbol Transmission Duration (OSTD) of period 321.97ns. Referring to FIG. 3, it was proposed in [2] that all the OSTDs 304 be aligned contiguously from the beginning 305 of a MAS. 'S' 304 represents an OSTD in FIG. 3, and the second OSTD 304 (S = 2) follows right after the first OSTD 304 (S = 1). The third OSTD 304 (S = 3) follows right after the second OSTD 304 (S = 2), and the fourth OSTD 304 (S = 4) follows right after the third OSTD 304 (S = 3) and so on. Since a MAS length is 256 microseconds, a number of 795 OSTDs can be transmitted within each MAS, and some small time is left over at the end of the MAS (considering in band time of an OFDM symbol as given in ECMA specification [I]). The first OSTD of the next MAS is scheduled to begin at the beginning of the next MAS 305. In order to facilitate transmission of OFDM symbol at exactly each OSTD, reference [3] proposed a synchronization method using virtual clock concept to achieve finer synchronization between devices at clock period level so that OSTDs of devices are synchronized and do not overlap much to cause interference. The content of reference [3] will be summarized later in this application. [0033] 2. Proposed Formats of ASIE and Other Information Elements [0034] Application Specific Information Element (ASIE), Application Specific Probe IE, Application Specific Command Frame and Application Specific Control Frame have been defined in the ECMA specification [1] pertaining to high data rate Ultra Wide Band (UWB) systems.

[0035] FIG. 4 illustrates the format 400 of an ASIE as defined in the ECMA specification [I]. As can be seen, the ASIE may comprise an Element ID field 401, a Length field 402 indicating the length of the payload of the ASIE, a ASIE Specifier ID field 403, and an Application Specific data field 404. Element ID 401 aids in distinguishing ASIE from other IEs including the Application Specific Probe IE. Each element ID (0-255) may be associated with an IE. Specifier ID 403 identifies the vendor or manufactory to distinguish different manufacturers/vendors. Data field 404 is left to be defined by the vendor. Some content and format for the data field are provided herein. [0036] FIG. 5 illustrates the format 500 of the payload of Application Specific Command and Control Frames as defined in the ECMA specification [I]. As can be seen, the payload 500 of the Application Specific Command/Control frame may include a Specifier ID field 501 and an Application specific Data field 502.

[0037] FIG. 6 illustrates the format 600 of the Application Specific Probe IE as defined in the ECMA specification [I]. As can be seen, the format 600 may include an element ID field 601, a Length field 602, a Target Dev Address field 603, an ASIE Specifier ID field 604, and an Application Specific Request Information field 605. [0038] In one embodiment, formats for the data fields defined as part of the ASIE, Application Specific Probe IE, and Application Specific Command and Control frames are provided. In one embodiment, methods as to how the data fields in the above IEs/frames can be used to implement the Distributed Reservation Protocol (DRP) and Prioritized Channel Access (PCA) using slotted offset TFC concept introduced in reference [2] keeping in view the synchronization algorithm given in reference [3] are provided. In a further embodiment, an algorithm is provided for beacon period merge among alien beacon groups that utilize an enhanced synchronization scheme as given in [3] (for use with slotted offsets TFCs).

[0039] 2.1 PROPOSED FORMATS FOR APPLICATION SPECIFIC DATA [0040] FIG. 7 illustrates the format of Application Specific Control field 700 according to one embodiment. In one embodiment, the first octet of the data field in ASIE, Application Specific Probe IE, the payload of the Application Specific Command or Control Frames is the Application Specific Control field 700.

[0041] In one embodiment, the Application Specific Control field 700 may include one or two octets with the bitθ-bit2 701 being used to indicate the product or protocol version of the ad hoc radio communication terminal device. In one embodiment, the bit3- bit7/bitl5 702 of the Application Specific Control field 700 are reserved. [0042] FIG. 8 illustrates the format 800 for the data field in ASIE apart from the first one or two octets of the Application Specific Control field 700.

[0043] As can be seen, according to one embodiment, the rest of the data apart from the Application Specific Control field 700 as included in the "Application Specific Data" field 404 are categorized into different field types and all the information pertaining to a single field type are contiguously packed. In one embodiment, an Application Specific Identifier field 801 is provided preceding every contiguous set of information 802 pertaining to the single field type.

[0044] FIG. 9 (a) illustrates the format of the Application Specific Identifier field 801. The Application Specific Identifier field 801 may include information pertaining to field type and the number of elements or octets in that type that follows it. For example, the Application Specific Identifier field 801 may include an octet of Field Information field 901 for indicating the field type and a Number of Elements/Number of Octets field 902 for indicating the number of elements or octets in that type that follows the Application Specific Identifier field 801 in the data field 404 of the ASIE.

[0045] FIG. 9 (b) illustrates the format of the Field Information field 901 in one embodiment. In one embodiment, bit4-bit7 903 of the Field Information field 901 are reserved. In one embodiment, bitθ-bit3 904 of the Field Information field 901 are used to indicate the Field type.

[0046] An alternate format for the "Application Specific Identifier" field 801 may utilize just one octet (Field Information octet 901 alone) that uses the reserved bits (e.g. bit4-bit7) in the Field Information octet 901 to represent the Number of Elements or Number of Octets field similarly as in FIG. 9 (a).

[0047] FIG. 9 (c) shows a table illustrating the correspondence of the value in Field Type field 904 and the various field types in one embodiment. As can be seen, a value of "0" in Field Type field 904 may be used to indicate the Field Type of Information Element, a value of "1" in Field type field 904 may be used to indicate the Field Type of Control Elements, a value of "2" in Field Type field 904 may be used to indicate the Field Type of Command Elements, and a value of "3" in Field Type field 904 may be used to indicate the Field type of Data Elements, and values of "4" - "15" in Field Type field 904 may be reserved. [0048] As can be seen from FIG. 8, the Application Specific Control field 700 is included in the data field of ASIE followed by the first Application Specific Identifier field 801 and that followed by the first contiguous set of information pertaining to a single field type (of type information elements). In one embodiment, in the data field of the ASIE, all the information elements are packed together and all the command elements are packed together. There is no restriction on the order in which the field types follow each other in the ASIE. There is also no limitation of the IEs sent using ASIEs (the IEs sent using ASIE may be the ones proposed in this description or the ones as given in ECMA specification [I]). In one embodiment, before every set of information pertaining to a single field type, an Application Specific Identifier field 801 is placed. [0049] FIG. 10 (a) illustrates the format of a Control Element 1001 for an Application Specific Control Frame in one embodiment. The Control Element 1001 may include one or two octets as the Control Element Information field 1002, a octet as the Control Element Length field 1003, and a Control Element Payload field 1004. [0050] FIG. 10 (b) illustrates the format of the Control Element Information field 1002. hi one embodiment, the bitθ-bit3 1005 of the Control Element Information field 1002 are used to indicate the Control Element Type, hi one embodiment, the bit4- bit7/bitl5 1006 of the Control Element Information field 1002 are reserved. Depending on the type of the control element (given in the Control Element Information Octet 1002), it may be inferred if length or/and payload fields 1003 and/or 1004 would follow the Control Element Information Octet 1002 in the Control Element 1001. [0051] FIG. 11 (a) illustrates the format of a Command Element 1101 for an Application Specific Command Frame in one embodiment. The Command Element 1101 may include one or two octets as the Command Element Information field 1102, an octet as the Command Element Length field 1103, and a Command Element Payload field 1104.

[0052] FIG. 11 (b) illustrates the format of the Command Element Information field 1102. hi one embodiment, the bitθ-bit3 1105 of the Command Element Information field 1102 are used to indicate the Command Element Type. In one embodiment, the bit4- bit7/bit 15 1106 of the Command Element Information field 1102 are reserved. Depending on the type of the command element (given in the Command Element Information Octet 1102), it may be inferred if length or/and payload fields 1103 and/or

1104 would follow the Command Element Information Octet 1102 in the Command

Element 1101.

[0053] FIG. 12 (a) illustrates the format of a Query Information field 1201 according to one embodiment. In one embodiment, the Application-specific Request Information field 605 in the Application Specific Probe IE 600 as shown in FIG. 6 may include a group of Query Information fields 1201 contiguously arranged.

[0054] In one embodiment, the Query Information field 1201 may include one octet as the Query Control field 1202. In one embodiment, the Query Information field 1201 may include an octet as the Query Length field 1203 indicating the length of the Query

Specific Data 1204. In one embodiment, the Query Information field 1201 may include a

Query Specific Data field 1204.

[0055] FIG. 12 (b) illustrates the format of the Query Control octet 1202 according to one embodiment. In one embodiment, bitθ-bit3 1205 of the Query Control field 1202 are used to indicate the Query Type/ID. In one embodiment, bit4-bit6 1206 of the Query

Control field 1202 are reserved. In one embodiment, bit7 1207 is used to indicate whether there is Query Specific Data 1204 being included in the Query Information field 1201.

For example, if the bit7 1207 is set to ZERO in the Query Control octet 1202, then the

Query Information field 1201 is of length 1 octet (Query Length octet and Query Specific

Data are not included).

[0056] 2.2 USE OF APPLICATION SPECIFIC DATA PERTAINING TO

SLOTTED OFFSET TFC

[0057] A few modifications to currently defined IEs in ECMA specification [1] and a new IE in addition to the ones defined in ECMA specification [1] were proposed in reference [2] to cater to slotted offset TFC implementation which are summarized as follows.

[0058] DRP IE: According to reference [2], bits bl3 and bl4 that are currently reserved in the DRP Control field are proposed in the DRP IE to indicate the TFC offset of the channel as shown in FIG. 13. Format 1301 in FIG. 13 (a) illustrates the Modified

DRP IE. Format 1302 in FIG. 13 (b) shows the DRP control field of DRP IE 1301. Table

1303 in FIG. 13 (c) shows the correspondence of the value of bits bl3 and bl4 of the DRP Control field 1302 with the TFC offset of the channel. In this example, it can be seen that value of "0" indicates TFC offset 0, a value of "1" corresponds to TFC offset 1, and a value of "2" corresponds to TFC offset 2.

[0059] PCA Availability IE: According to reference [2], the two reserved bits (b2- bl) of the Interpretation field of the PCA Availability IE are proposed to indicate the TFC offset of the channel. As shown in FIG. 14, additional PCA Availability IEs are proposed to be sent if PCA availabilities for additional TFC offsets of the channel are required. Format 1401 in FIG. 14 (a) shows the Modified PCA Availability IE. Format 1402 in FIG. 14 (b) shows the Interpretation field of format 1401, namely the PCA Availability IE. Table 1403 in FIG. 14 (c) shows the correspondence of the value of two reserved bits b2-bl of the Interpretation field 1402 with the TFC offset of the channel. In this example, it can be seen that value of "0" indicates TFC offset 0, a value of "1" corresponds to TFC offset 1, and a value of "2" corresponds to TFC offset 2. [0060] Relinquish Request IE: According to reference [2], two reserved bits (b5-b4) of the Relinquish Request IE are proposed to indicate the TFC offset of the channel. FIG. 15 (a) shows the format of the Modified Relinquish Request IE 1501. Format 1502 in FIG. 15 (b) shows the Relinquish Request Control field of the Relinquish Request IE 1501 in more detail. Table 1503 in FIG. 15 (c) shows the correspondence of the value of reserved bits b5-b4 of the Relinquish Request Control field 1502 with the TFC offset of the channel. In this example, it can be seen that value of "0" indicates TFC offset 0, a value of "1" corresponds to TFC offset 1, and a value of "2" corresponds to TFC offset 2. [0061] MAC Capabilities IE: It was proposed in [2] that one of the reserved bits in the current MAC Capabilities IE as given in ECMA standard [1] be used to indicate the capability of the device to transmit in slotted offset TFCs.

[0062] PHY Capabilities IE: According to reference [2], one of the reserved octets are proposed to be used for TFC Offset Control. In the TFC Offset Control field, one of the bits is used to indicate the capability of a device to transmit in TFC offsets of the channel as shown in FIG. 16. FIG. 16 (a) shows the format of the Modified PHY Capabilities IE 1601. FIG. 16 (b) shows the TFC Offset Control field 1602 of the PHY Capabilities IE 1601. [0063] Enhanced DRP Availability IE: Reference [2] proposed a new IE to indicate a device's view of the current utilization of MASs in the current superframe (catering to the use of TFC offsets of the channel) as shown in FIG. 17. FIG. 17 (a) shows the format of the newly proposed IE, namely the Enhanced DRP Availability IE 1701. FIG. 17 (b) shows the Interpretation field 1702 of the Enhanced DRP Availability IE 1701. FIG. 17 (c) shows a table 1703 illustrating the correspondence of the value of bitl-bitO of the Interpretation field 1702 with the TFC offset of the channel. In this example, it can be seen that value of "0" indicates TFC offset 0, a value of "1" corresponds to TFC offset 1, and a value of "2" corresponds to TFC offset 2.

[0064] According to one embodiment, every device capable of operating in slotted offset TFC and from the same vendor (related to ASIE) may include ASIE in its beacon. In one embodiment, every device may also include in its ASIE, information pertaining to all other devices in its beacon group as to whether all those devices are from the same vendor and are able to operate in slotted offset TFCs. In one embodiment, one of the reserved bits 702 in Application Specific Control field 700 (see FIG. 7) may be used to indicate if all the devices in a device's beacon group are from the same vendor and are able to operate in slotted offset TFCs. In one embodiment, all the IEs related to the use of slotted offset TFCs (including the proposed modified IEs and the newly proposed Enhanced DRP Availability IE) are included in the ASIE. In one embodiment, implicit reservation negotiation takes place through the ASIEs. An illustration of how IEs are packed as part of the ASIE is shown in FIG. 8. In the following, methodologies by which slotted offset TFCs based reservation of bandwidth is performed are provided using ASIEs by maintaining backward compatibility. [0065] 3.1 Distributed Reservation Protocol (DRP)

[0066] Before the implementation of the DRP using slotted offset TFCs and ASIEs is given, the DRP reservation policy is provided as follows in accordance with an embodiment.

[0067] In one embodiment, a device always tries to search or reserve MASs where transmissions and receptions can take place using default offset (no offset of the default channel, e.g. TFC offset 0). If adequate bandwidth is not available, then the device may try to reserve MASs for transmissions and reception using the next higher offset (e.g. TFC offset 1 or TFC offset 2 as shown in FIG. 2) of the channel that is used. In one embodiment, a device always reserves MASs pertaining to the least possible (in other words, the TFC offset with the lowest possible number) and available offset should it require bandwidth, and if all the MASs are reserved for a given offset, then only the device tries to reserve MASs for a higher offset in the same channel. In one embodiment, no MAS is negotiated for use with an offset higher than default offset unless that MAS has already been reserved for use with default offset.

[0068] In one embodiment, a device sends an ASIE in its beacon. In one embodiment, all the IEs related to the use of slotted offset TFCs (including the proposed modified IEs and the proposed new IE in this invention) are included in the ASIE. hi one embodiment, implicit reservation negotiation takes place through the ASIEs between devices capable of operating in slotted offset TFCs and from the same vendor. In one embodiment, if the reservation negotiation is for MASs using default offset, then DRP IEs as given in ECMA specification (reference [I]) are sent in addition to the ASIE. In one embodiment, the reservation types are the same as given in ECMA specification [I]. In one embodiment, a device that is capable of operating in slotted offset TFCs may be able to operate in slotted offset TFCs using DRP reserved MASs in the current superframe if it has another device as its neighbour from the same vendor, and that is able to operate in slotted offset TFCs, and if that neighbouring device had not moved its BPST for the previous six (or any other fixed value greater or lower than six) superframes. In one embodiment, towards this end, a device capable of operating in slotted offset TFCs saves or stores a history of BPST values of the previous six (or any other fixed value greater or lower than six, in general an arbitrary number) superframes for each of its neighbours. In the above, it is assumed that every device capable of using slotted offset TFCs and from the same vendor keeps moving its BPST every superframe by a non zero value (in nano seconds) if it were to follow the synchronization algorithm as given in ECMA specification [I]. In the above, it is also assumed that if a device capable of using slotted offset TFCs is a neighbour of the slowest device in its beacon group (that had not moved its BPST for 6 superframes), the device will synchronize with the slowest device using the synchronization scheme proposed in [3]. In the following, the terms "ECMA [1] specified device" and "device according to ECMA [1] specification" refer to a device that has been built according to reference [1] with possibly no additional features such as slotted offset time/frequency portion communication capability. In one embodiment, a device that is capable of operating in slotted offset time/frequency portion communication may also have features specified by reference [I].

[0069] In one embodiment, implicit negotiation is carried out by transmitting the modified DRP IE 1301 (as shown in FIG. 13(a)) as part of the ASIE in beacon frames, hi one embodiment, a device that supports slotted offset TFCs and from the same vendor as alluded to in ASIE, parses all ASIEs from neighbors for modified DRP IEs whose Target/Owner device address field matches either the device's address or a multicast address for which the device has activated the multicast reservation, hi one embodiment, the rest of the reservation negotiation procedure is similar to that given in ECMA specification [1] with the exception that modified DRP IEs in the ASIEs are used instead of the DRP IEs. In one embodiment, the devices that are able to operate in slotted offset TFCs and from the same vendor (related to ASIE) rely on the ASIEs for DRP negotiation/reservation and slot availability advertisements, hi one embodiment, if a reservation for MASs is negotiated pertaining to default offset, then implicit negotiation is carried out simultaneously using the procedure as given in ECMA specification [1] in addition to the implicit negotiation through ASIEs.

[0070] hi one embodiment, a device (owner or target) that sends a modified DRP IE in its ASIE as part of its beacon frame also sends the DRP IE (separate from ASIE) in its beacon frame under the following condition. For every modified DRP IE included in the device's ASIE that seeks or establishes or concerns reservation using default offset (no offset, i.e. TFC offset 0), a corresponding DRP IE is sent (a copy of the modified DRP IE except for the reserved bits in the DRP IE) in its beacon frame separate from ASIE (Reservation for default offset may be treated in a manner similar to a reservation sought or negotiated by a ECMA specified device according to ECMA specification [I]). [0071] Concerning the above, resolution of conflicts for default TFC offset using DRP IEs may be same as that given in ECMA specification [1] according to one embodiment. If the device is able to assert its reservation using the above conflict resolution protocol, then the device may continue to send the modified DRP IE as part of its ASIE and a separate DRP IE asserting a reservation, hi one embodiment, if the device is unable to assert its reservation using the above conflict resolution protocol, then the device ceases to send the modified DRP IE as part of the ASIE and a separate DRP IE pertaining to the conflicting MAS bit map in the immediate next superframe or removes conflicting MASs from the negotiation using ASIEs and DRP IEs. [0072] hi one embodiment, if a device capable of operating in slotted offset TFCs and from the same vendor (related to ASIE) discovers that there is not enough bandwidth available in default offset, the device may seek to reserve slots using the next higher offset. If all the MASs that are sought have already been reserved using the default offset, the device may not send any DRP IE separate from the ASIE in its beacon pertaining to the MASs sought unless the device has current reservation for those MASs using the default offset. In this case, according to one embodiment, it suffices for the device that is negotiating the above MASs for an offset higher than the default offset to just send the modified DRP IE as part of its ASIE in its beacon if the device has no current reservation for those MASs using the default offset. Without loss of generality, it is assumed that the target device and owner device both are able to operate in slotted offset TFCs and are from the same vendor when they negotiate using ASIEs. Hence, the reservation negotiation for higher offsets are hidden to ECMA [1] specified devices, but reservation negotiation for default offset is carried out using both DRP IE and the earlier proposed modified DRP IE thus making it transparent to ECMA [1] specified devices. In the above, the phrase "hidden" implies that a ECMA [1] specified device is not required to parse and decode all ASIEs. In one embodiment, if the owner or the target does not receive any DRP IE in the previous one (or mMaxLostBeacons) superframe(s) asserting a reservation for any MAS that the owner and target have agreed to utilize with an offset higher than the default offset, the owner or/and target respectively may forfeit the agreed upon reservation (using the higher offset) and cease to send any modified DRP IE in ASIE asserting the reservation in the next superframe, and the related MASs may not be used in the current or next superframe. The owner and the target may then seek to newly negotiate a reservation using the default offset for such available MASs (with DRP IE also sent separately from ASIE) or may negotiate a subset of MASs already being in use using default offset for use with a higher offset (without DRP IE being sent separately from ASIE). [0073] In other words, in one embodiment, if the MASs sought for reservation (using a higher offset) form a subset of MASs already used by default offset, it suffices for the owner and the target to restrict their negotiation using ASIEs without any DRP IE. In one embodiment, if MASs not reserved originally using default offset are being sought for reservation using default offset, DRP IE is sent by both owner and target seeking or negotiating column/row reservation for these MASs alone. In such a case, in the MAS bit map of the DRP IEs sent, MASs already in use by default offset during this reservation negotiation are not listed. In one embodiment, conflicts pertaining to the above column/ row reservation may be handled as defined by the conflict resolution protocol in ECMA specification (reference [I]).

[0074] Moreover, in one embodiment, if a ECMA [1] specified device reserves a MAS, the MAS is not used by any other device using any higher offset or default offset. In one embodiment, only MASs reserved by a device capable of operating in slotted offset TFCs from the same vendor for use with default offset are reserved using higher offsets.

[0075] In one embodiment, a device capable of operating in slotted offset TFCs may send the modified Relinquish Request IE in its ASIE as part of the beacon frame. In one embodiment, a device capable of operating in slotted offset TFCs does not send relinquish requests for MASs that are being used by offsets higher than the default offset in its beacon outside ASIE. In one embodiment, the modified Relinquish Request IE sent as part of the ASIE may be for any offset. In one embodiment, if the modified relinquish request is for a set of MASs that includes at least one MAS that uses the default offset, an additional relinquish request is also to be sent in the beacon outside of the ASIE for such MASs that use the default offset. In one embodiment, if any device relinquishes MASs that were reserved for default offset, then all the devices that had reserved these MASs using higher offsets forgo these MASs as well. In one embodiment, a device is allowed to maintain reservation for a MAS using an offset higher than the default offset only if a reservation for that MAS is maintained using the default offset by that device or any other device capable of operating in slotted offset TFCs.

[0076] In one embodiment, DRP availability is advertised in the following manner. The device that wants to advertise its view of available MASs sends the enhanced DRP availability 1701 (see FIG. 17) in its ASIE (see FIG. 8). In one embodiment, three enhanced DRP availability IEs may be sent in the ASIE if availability needs to be advertised for three offsets of a channel. Moreover, the device also may send the DRP availability as defined in ECMA specification (reference [I]), in its beacon. In one embodiment, no MAS that is reserved with any offset by any device (with reservation status set to 1 in the modified DRP IE as part of the ASIE) or reserved by a ECMA [1] specified device is advertised as available in the DRP Availability IE (separate from ASIE) sent in the beacon. This is to allow any ECMA [1] specified device to know the precise availability of MASs for DRP.

[0077] In other words, devices capable of operating in slotted offset TFCs and from same vendor may follow the rules given in ECMA [1] specification pertaining to DRP for default offset and use a hidden (hidden to ECMA [1] specified devices) procedure using ASIEs to negotiate reservations for MASs for offsets higher than default offset. [0078] In one embodiment, if all the devices in the beacon group are capable of transmitting in slotted offset TFCs, and assuming that they stay synchronized using the synchronization algorithm in [3], every device's virtual clock is synchronized to the physical clock of the slowest neighbor.

[0079] FIG. 18 (a) illustrates an example of a extended beacon group 1800 consisting of devices A1-A5 1851-1855 and devices B1-B3 1856-1858. In this context, extended beacon group of a device refers to the union of all its neighbors' beacon groups. A device's beacon group refers to a set of all its neighbors. Assume that the devices Al to A5 are from the same vendor and are able to operate in slotted offset TFCs. Assume the devices Bl to B3 are ECMA [1] specified devices. In one embodiment, if any of the devices Al to A5 or Bl to B3 is the slowest, and if the virtual clocks of the devices Al to A5 may be synchronized to the slowest device by virtue of the synchronization algorithm given in this invention and devices Bl to B3 may synchronize to the slowest device by virtue of the synchronization algorithm given in ECMA [1] specification, the devices Al to A5 1851-1855 may use slotted offset TFCs. Though all the devices A1-A5 1851-1855 may be synchronized to a clock period level, devices Bl to B3 1856-1858 may not be synchronized to other devices to such levels. Hence, in one embodiment, when any of the devices A1-A5 1851-1855 try to reserve a MAS that shares boundary with a ECMA [1] specified device (e.g. Bl to B3 1856-1858)'s reserved MASs, that device (any of Al to A5 1851-1855) does not use the MAS that shares boundary with a ECMA [1] specified device's reserved MASs for data transmission (allowing for guard time within its reservation) or does not use few fixed number of OSTDs at the beginning or end (sharing the above boundary) of such MASs, since the ECMA [1] specified device may not maintain precise MAS boundary. In one embodiment, the fixed number may be predetermined.

[0080] In one embodiment, explicit reservation of MASs may be carried out between devices capable of operating in slotted offset TFCs and that are from the same vendor using control/command elements in Application Specific Control/Command frames. The modified IEs as given in this description and the Enhanced DRP Availability IE proposed in this description may be used pertaining to Application Specific Control/Command frames. Once reservation is established, reservations are asserted implicitly through beacons. The DRP reservation policy proposed earlier may be followed for explicit negotiation as well. In one embodiment, rules for sending modified DRP IEs in ASIE and DRP IEs outside ASIE after an explicit negotiation is completed are similar to those given above for implicit negotiation.

[0081] As an alternate option to the methodologies given above, if all the devices in a device's extended beacon group are capable of operating in slotted offset TFC and are from the same vendor (related to ASIE), then the device may work using the ASIE based DRP negotiation and slotted offset TFCs explained earlier. If one of the devices in the device's extended beacon group is a device that does not operate in slotted offset TFCs or is not from the same vendor, then the device may use the normal DRP as defined in ECMA [1] specification. The above information as to whether all the devices in the device's extended beacon group are from the same vendor or not may be propagated using the Application Specific Control Field 700 proposed earlier (see FIG. 7). FIG. 18 (b) illustrates a method for requesting radio resources in a radio communication system according to one embodiment. In one embodiment, the method may include a step 1801 of generating and encoding a first request message for radio resources including a plurality of slotted time/frequency portions. In one embodiment, the first request message may include an Information Element being encoded in accordance with a first communication protocol format which can be decoded by a radio communication terminal device of a first type being configured to provide only slotted time/frequency portion communication without slotted offset time/frequency portion communication and by a radio communication terminal device of a second type being configured to provide slotted time/frequency portion communication and slotted offset time/frequency portion communication. In one embodiment, the method may further include step 1803, in case the radio resources requested by the first request message are not available, generating and encoding a second request message for radio resources including a plurality of slotted offset time/frequency portions. In one embodiment, the second request message may include an Application Specific Information Element being encoded in accordance with a second communication protocol format which can be decoded by a radio communication terminal device of the second type. In one embodiment, the radio communication system is an ad hoc radio communication system, and the radio communication terminal device of the first type and the radio communication terminal device of the second type are ad hoc radio communication terminal devices.

[0082] In this context, the radio resources including a plurality of slotted time/frequency portions may for example be a frequency hopping pattern (simple TFC without slotted offset TFCs). In one embodiment, the frequency hopping pattern may not be aligned (or synchronous) in time with the start of any OSTD or MAS boundary. In this context, the slotted offset time/frequency portion communication may refer to the communication which may use slotted offset TFCs (TFC offset 0 and/or a higher offset of the TFC such as TFC offset 1 and TFC offset 2). For example, the devices as proposed in reference [2] may use both slotted time/frequency portions and slotted offset time/frequency portions for communication, thereby enhancing the network throughput, hi this context, in one embodiment a device capable of using slotted offset time/frequency portion communication may always treat its default TFC offset (offset 0) as same as slotted time/frequency portion if there is at least one other device in its neighborhood to which the device can synchronize to clock period level. In other words, even if a reservation is made by a device capable of using slotted offset time/frequency portion communication for the reservation of slotted time/frequency portions, the device may still use TFC offset 0 (default offset) as if the TFC offset 0 were slotted time/frequency portion during such reserved MASs if there is at least one other device in its neighborhood to which the device can synchronize to clock period level. Any device not capable of using slotted offset TFCs may treat TFC offset 0 used by another device as just a slotted time/frequency portion communication.

[0083] In this context, in one embodiment, the method for requesting radio resources in an ad hoc radio communication system may include a step of generating and encoding a first request message for radio resources. In one embodiment, the radio resources may include a plurality of slotted time/frequency portions. For example, for TFC offset 0 as shown in FIG. 2, the slotted offset time/frequency portions are represented by the grey colored boxes 261-266. For example, the first message may be sent for reservation of the radio resource of TFC offset 0 (a slotted TFC with no offset), namely a default TFC offset, hi one embodiment, the first request message may include an Information Element. For example, the first request message may be sent during a beacon slot. The Information Element may be encoded in accordance with a first communication protocol format, e.g. the format of the Information Element as proposed by the ECMA [1] standard. For example, the Information Element may be decoded by. both an ad hoc radio communication terminal device (the first type device) according to the ECMA [1] standard which may only use slotted time/frequency portions and an ad hoc radio communication terminal device (the second type device) which is capable to use slotted offset time/frequency portions i.e., any of the TFC offsets, e.g. TFC offset 0, TFC offset 1, and TFC offset 2 (see FIG. 2). For example, the method may further include, in case the TFC offset 0 requested by the first request message is not available, generating and encoding a second request message for radio resources, e.g. a higher TFC offset. For example, the second request message may be sent during a beacon slot. In one embodiment, the second request message may include an Application Specific Information Element (ASIE). For example, the ASIE may have the format as shown in FIG. 8. hi one embodiment, the ASIE may be encoded in accordance with a second communication protocol format, e.g. format as shown in FIG. 8, which can be decoded by an ad hoc radio communication terminal device of the second type. [0084] hi one embodiment, the time/frequency portions comprise Time-Frequency Codes (TFC). An illustration of the TFC may be seen in FIG. 2. [0085] In one embodiment, the first request message includes an Information Element requesting a Medium Access Slot (MAS) including a plurality of slotted time/frequency portions analogous with a default slotted offset time/frequency portion (TFC offset 0). For example, each MAS may include a number of 795 OSTDs. Each OSTD may correspond to a time portion, such as any of the time portions 202-207 as shown in FIG. 2. Further, according to the TFC offset 0 a frequency portion is designated for each time portion. For example, according to TFC offset 0, for the time portion 202, the frequency portion is represented by the frequency band 211. That is, the time/frequency portion is represented by the grey colored box 241 corresponding to the time portion 202 according to the TFC offset 0.

[0086] In one embodiment, the method is carried out by an ad hoc radio communication terminal device.

[0087] In one embodiment, the method may further include a step of transmitting the first request message to another ad hoc radio communication terminal device which is in the same ad hoc radio communication group as the ad hoc radio communication terminal device.

[0088] In one embodiment, the ad hoc radio communication group may be an ad hoc radio communication beacon group. For example, within the same ad hoc radio communication group, all the devices may share a same beacon period start time. [0089] In one embodiment, the method may further include a step of 1802, in case the radio resources requested by the first request message are available, reserving the requested radio resources. For example, the reservation of the requested radio resources may be achieved by sending Information Elements during the Beacon Period announcing the reservation of a certain MAS.

[0090] hi one embodiment, the method may further include a step of 1804, in case the radio resources requested by the first request message are not available, generating, encoding and transmitting a resource reservation message to another ad hoc radio communication terminal device which is in the same ad hoc radio communication group as the ad hoc radio communication terminal device. For example, when default TFC offset is not available, a higher TFC offset (TFC offset 1 or TFC offset 2) may be reserved. Such a reservation may be achieved by sending ASIE as proposed with reference to FIG. 8 during the beacon period requesting and/or announcing the reservation of the use of a MAS for a higher TFC offset. In this regard, a resource may be reserved for use with a higher TFC offset (TFC offset 1 or TFC offset 2) only if the resource has been reserved for use with TFC offset 0 by a device capable of using slotted offset TFCs.

[0091] In one embodiment, the resource reservation message may include an Application Specific Information Element being encoded in accordance with the second communication protocol format. For example, the format may be as shown in FIG. 8. [0092] FIG. 18 (c) illustrates a method for determining available radio resources in a radio communication system according to one embodiment. In one embodiment, the method may include a step 1810 of determining as to whether required radio resources including a plurality of slotted offset time/frequency portions are available. In one embodiment, the method may further include a step 1812, in case the required radio resources are not available, determining as to whether required radio resources including a different plurality of slotted offset time/frequency portions are available using a request message for the radio resources, wherein the request message includes an Application Specific Information Element being encoded in accordance with a communication protocol format which can be decoded by a radio communication terminal device of a type being configured to provide slotted time/frequency portion communication and slotted offset time/frequency portion communication. In one embodiment, the radio communication system is an ad hoc radio communication system, and the radio communication terminal device of the type being configured to provide slotted time/frequency portion communication and slotted offset time/frequency portion communication is an ad hoc radio communication terminal device. [0093] hi other words, for example, the method may include a step of determining as to whether TFC with a particular offset is available. That is, a device first seeks to reserve TFC with a particular offset, hi one embodiment, the method may further include, in case the required TFC with particular offset is not available, determining as to whether a higher TFC offset is available. The determining may be by a request message for the radio resources. For example, the request message may be sent during a beacon slot. For example, the request message may include an Application Specific Information Element (ASIE) which may be encoded in accordance with a communication protocol format such as the format of the ASIE as proposed in FIG. 8. For example, the ASIE may be decoded by an ad hoc radio communication terminal device of a type being configured to provide slotted time/frequency portion communication and slotted offset time/frequency portion communication.

[0094] In one embodiment, the determining as to whether required radio resources are available comprises determining as to whether required radio resources are available using a request message for the radio resources, wherein the request message comprises an Information Element being encoded in accordance with a communication protocol format which can be decoded by a radio communication terminal device of a type being configured to provide only slotted time/frequency portion communication without slotted offset time/frequency portion communication. In one embodiment, the radio communication terminal device of the type being configured to provide only slotted time/frequency portion communication without slotted offset time/frequency portion communication is an ad hoc radio communication terminal device.

[0095] In one embodiment, the time/frequency portions may include time/frequency codes.

[0096] In one embodiment, the request message for determining as to whether required radio resources including a plurality of slotted offset time/frequency portions are available includes an Application Specific Information Element requesting a Medium

Access Slot comprising a plurality of slotted offset time/frequency portions, The format of the ASIE is illustrated in FIG. 8.

[0097] hi one embodiment, the method may be carried out by an ad hoc radio communication terminal device.

[0098] In one embodiment, the method may further include a step of transmitting the request message to another ad hoc radio communication terminal device which is in the same ad hoc radio communication group as the ad hoc radio communication terminal device.

[0099] In one embodiment, the ad hoc radio communication group may be an ad hoc radio communication beacon group. [00100] In one embodiment, the method may further include a step of 1811, in case the radio resources including a plurality of slotted offset time/frequency portions requested by the request message are available, reserving the required radio resources (Note that any device not capable of using slotted offset TFCs may treat TFC offset 0 used by another device as just a slotted time/frequency portion communication). For example, if there are available MASs for the default TFC offset, the MASs for the default TFC offset may be reserved by sending Information Element during the beacon period announcing the reservation of the MASs for the default TFC offset.

[00101] In one embodiment, the method may further include a step 1813, in case the required radio resources including a plurality of slotted offset time/frequency portions are not available, generating, encoding and transmitting a resource reservation message to another ad hoc radio communication terminal device which is in the same ad hoc radio communication group as the ad hoc radio communication terminal device. For example, if a device finds out that there is no available MAS for the default TFC offset, then the device may request reservation of a MAS for a higher TFC offset. The device sends the request message to another device that is of the same type of the device which may use slotted offset TFC for communication. The device may further reserve the MAS for the higher TFC offset by a resource reservation message.

[00102] In one embodiment, the resource reservation message includes an Application Specific Information Element being encoded in accordance with the second communication protocol format. For example, the second communication protocol format may be the format as shown in FIG. 8.

[00103] FIG. 18 (d) illustrates a radio communication terminal device 1830 for requesting radio resources in a radio communication system in one embodiment. In one embodiment, the radio communication terminal device 1830 comprises a first generator 1831 and a first encoder 1832 being configured to generate and encode a first request message for radio resources including a plurality of slotted time/frequency portions. In one embodiment, the first request message includes an Information Element being encoded in accordance with a first communication protocol format which can be decoded by a radio communication terminal device of a first type being configured to provide only slotted time/frequency portion communication without slotted offset time/frequency portion communication and by a radio communication terminal device of a second type being configured to provide slotted time/frequency portion communication and slotted offset time/frequency portion communication. In one embodiment, the radio communication terminal device 1830 may further include a second generator 1833 and a second encoder 1834 being configured to, in case the radio resources requested by the first request message are not available, generate and encode a second request message for radio resources including a plurality of slotted offset time/frequency portions. In one embodiment, the second request message includes an Application Specific Information Element being encoded in accordance with a second communication protocol format which can be decoded by a radio communication terminal device of the second type. In one embodiment, the radio communication device 1830 is ad hoc radio communication terminal device for requesting radio resources in an ad hoc radio communication system, wherein the radio communication device of the first type and the radio communication device of the second type are ad hoc radio communication terminal devices. [00104] hi one embodiment, the time/frequency portions may include time/frequency codes.

[00105] hi one embodiment, the first request message includes an Information Element requesting a Medium Access Slot including a plurality of slotted time/frequency portions with a default slotted time/frequency portion offset or TFC offset 0 treated as slotted time/frequency portions.

[00106] hi one embodiment, the radio communication terminal device 1830 may further include a first transmitter 1835 being configured to transmit the first request message to another ad hoc radio communication terminal device which is in the same ad hoc radio communication group as the ad hoc radio communication terminal device. [00107] hi one embodiment, the ad hoc radio communication group is an ad hoc radio communication beacon group.

[00108] In one embodiment, the radio communication terminal device 1830 may further include a reserving circuit 1836 being configured to, in case the radio resources requested by the first request message are available, reserve the requested radio resources. [00109] In one embodiment, the radio communication terminal device 1830 may further include a third generator 1837, a third encoder 1838, and a second transmitter 1839 being configured to, in case the radio resources requested by the first request message are not available, generate, encode and transmit a resource reservation message to another radio communication terminal device which is in the same radio communication group as the radio communication terminal device 1830. [00110] In one embodiment, the first generator 1831, the second generator 1833, and the third generator 1837 may be the same generator. In one embodiment, the first encoder 1832, the second encoder 1834, and the third encoder 1838 may be the same encoder, hi one embodiment, the first transmitter 1835 and the second transmitter 1839 may be the same transmitter.

[00111] In one embodiment, the resource reservation message includes an Application Specific Information Element being encoded in accordance with the second communication protocol format.

[00112] FIG. 18 (e) illustrates a radio communication terminal device 1840 for determining available radio resources in a radio communication system in one embodiment. In one embodiment, the radio communication terminal device 1840 may include a first determining circuit 1841 being configured to determine as to whether required radio resources including a plurality of slotted time/frequency portions are available. In one embodiment, the radio communication terminal device 1840 may further include a second determining circuit 1842 being configured to, in case the required radio resources are not available, determine as to whether required radio resources including a plurality of slotted offset time/frequency portions are available using a request message for the radio resources, wherein the request message includes an Application Specific Information Element being encoded in accordance with a communication protocol format which can be decoded by a radio communication terminal device of a type being configured to provide slotted time/frequency portion communication and slotted offset time/frequency portion communication. In one embodiment, the radio communication device 1840 is an ad hoc radio communication terminal device for determining available radio resources in an ad hoc radio communication system, wherein the radio communication terminal device of the type being configured to provide slotted time/frequency portion communication and slotted offset time/frequency portion communication is an ad hoc radio communication terminal device.

[00113] In one embodiment, the first determining circuit 1841 and the second determining circuit 1842 may be the same determining circuit.

[00114] In one embodiment, the first determining circuit 1841 is configured to determine as to whether required radio resources are available using a request message for the radio resources, wherein the request message may include an Information Element being encoded in accordance with a communication protocol format which can be decoded by a radio communication terminal device of a type being configured to provide only slotted time/frequency portion communication without slotted offset time/frequency portion communication. In one embodiment, the radio communication terminal device of the type being configured to provide only slotted time/frequency portion communication without slotted offset time/frequency portion communication is an ad hoc radio communication terminal device.

[00115] In one embodiment, the time/frequency portions may include time/frequency codes.

[00116] In one embodiment, the request message to determine as to whether required radio resources including a plurality of slotted offset time/frequency portions are available includes an Application Specific Information Element requesting a Medium

Access Slot comprising a plurality of slotted offset time/frequency portions.

[00117] In one embodiment, the radio communication terminal device 1840 may further include a first transmitter 1843 being configured to transmit the request message as to determine whether required radio resources including a plurality of slotted offset time/frequency portions are available to another ad hoc radio communication terminal device which is in the same ad hoc radio communication group as the ad hoc radio communication terminal device.

[00118] In one embodiment, the ad hoc radio communication group may be an ad hoc radio communication beacon group.

[00119] In one embodiment, the radio communication terminal device 1840 may further include a reserving circuit 1844 being configured to, in case the radio resources requested by the request message as to determine whether required radio resources including a plurality of slotted time/frequency portions are available are available, reserving the required radio resources.

[00120] In one embodiment, the radio communication terminal device 1840 may further include a generator 1845, an encoder 1846, and a second transmitter 1847 being configured to, in case the required radio resources are not available, generating, encoding and transmitting a resource reservation message to another ad hoc radio communication terminal device which is in the same ad hoc radio communication group as the ad hoc radio communication terminal device.

[00121] In one embodiment, the first transmitter 1843 and the second transmitter 1847 may be the same transmitter.

[00122] In one embodiment, the resource reservation message includes an Application

Specific Information Element being encoded in accordance with the second communication protocol format.

[00123] 3.2 Prioritized Channel Access fPCA)

[00124] Prioritized Channel Access (PCA) is used in the ECMA [1] standard to provide differentiated distributed contention access to the medium for a device for transmission.

[00125] In one embodiment, three independent and parallel implementations of the existing PCA back off module and protocol (as specified by the WiMedia/ECMA [1] specification) may be used in parallel for use of slotted offset TFCs using PCA.

[00126] In one embodiment, the use of one back off counter is provided for each TFC offset of the channel (three independent modules each similar to that used by PCA in the

ECMA [1] specification; see FIG. 19). When a device has packet to send and senses all the TFC offsets of the channel busy, the device invokes a back off mechanism similar to that used by the PCA in the ECMA [1] specification. The back off counter for a TFC offset is frozen as long as the TFC offset remains in use or busy, and the back off counter is decremented when the TFC offset of the channel is sensed idle. When any of the three back off counters reaches zero, the packet is transmitted using the TFC offset corresponding to the back off counter that reached zero. Hence, the packet is transmitted as soon as one of the back off counters corresponding to the three TFC offsets of the channel reaches zero. As a side note, the delay in accessing one of the TFC offsets by a packet is lower as compared to the case when only a default channel (with no TFC offsets) is used. Optionally, every TFC offset can also cater to multiple Access Categories (ACs) as specified in the ECMA standard. The Arbitration Inter-Frame Spacing (AIFS) and the maximum back off counter value may be different for different Access Categories for each TFC offset.

[00127] It should be noted that the device may be equipped with a counter clock for each TFC offset for every AC, and the device may start to transmit an OFDM symbol for an AC using a TFC offset whose counter clock first reaches zero. This embodiment is also illustrated in FIG. 19, wherein the device is equipped with a counter clock for each TFC offset of the channel (TFC offset 0, TFC offset 1, and TFC offset 2). As can be seen in FIG. 19, after the 'Medium busy' state, there is an Arbitration Inter-Frame Spacing (AIFS) period before a counter clock is applied. For each TFC offset of the channel, there is a corresponding counter clock. In the illustration of FIG. 19, the counter clock of TFC offset 2 first reaches zero. Thus, TFC offset 2 will be selected by the device to transmit an OFDM symbol of a first buffered packet. It can also be seen that the counter clock corresponding to TFC offset 1 secondly reaches zero. Thus, the device may use TFC offset 1 for the transmission of OFDM symbol of next buffered packet. This embodiment may have the effect that the delay in accessing the channel (any TFC offset) by a data packet is lower.

[00128] In one embodiment, a device that is capable of transmitting with slotted offset TFCs sends modified PCA Availability IE in its ASIE as part of the beacon. Slots where a device is available for PCA using a given offset may be advertized in one modified PCA availability IE in the ASIE according to one embodiment. Multiple modified PCA Availability IEs may be included to advertize device's availability in slots pertaining to multiple offsets of TFC. As an example, if a particular slot has been reserved for DRP for offset 0, then the device's availability for the same slot may be advertized in two modified PCA Availability IEs pertaining to two other offsets in ASIE. [00129] In one embodiment, the device also sends a PCA Availability IE as defined in ECMA [1] specification. Only slots unreserved for DRP using the default offset (no offset) of TFC and unreserved by ECMA [1] specified devices are advertized as available for PCA in the PCA Availability IE. By virtue of the protocol related to DRP proposed earlier, no slot may be occupied by any device at an offset higher than the default offset without first being occupied at the default offset. In one embodiment, only MASs occupied by lower TFC offsets may be considered for PCA availability in a particular TFC offset whose offset is higher than zero. In one embodiment, if all the devices in the device's extended beacon group are capable of operating in slotted offset TFC and are from the same vendor (related to ASIE), then the device may work using the enhanced PCA explained earlier. Even if one of the devices in a device's extended beacon group is a device that does not operate in slotted offset TFCs or is not from the same vendor, then the device uses the normal PCA as defined in ECMA [1] specification. The above information as to whether all the devices in the device's extended beacon group are from the same vendor or not may be propagated using the Application Specific Control Field 700 proposed earlier (see FIG. 7).

[00130] 4. Use of Application Specific Data pertaining to Link Feedback [00131] According to the current WiMedia standard, the Link Feedback IE contains information on the recommended change to the data rate and transmit power level recommended by a recipient device for one or more source devices. A device may include a Link Feedback IE in its beacon to provide feedback on a link with a specific neighbor. A recipient device may use the Link Feedback IE to suggest the optimal data rate to be used by a source device, for example, to increase throughput and/or to reduce the frame error rate. The data rate in the Link Feedback IE is interpreted as the maximum data rate that the source device should use for this particular link, for an acceptable frame error rate. The source device is not required to follow the recommendation. A recipient device may recommend a transmit power level change to be used by a source device by including a Link Feedback IE in its beacon. A device that receives a Link Feedback IE is not required to change its transmit power level. The recipient device might use the signal to noise ratio, received signal strength, frame error ratio or other parameters to determine the transmit power change to recommend to the source device.

[00132] According to the ECMA [1] standard, Link Feedback IE is sent once every superframe. However, the coherence time of channels can be much less than the duration of a superframe, which is 65.536 ms. [00133] New link feedback strategies that use command/control frames for devices are proposed by reference [4]. The proposed strategies by reference [4] cater to lower channel coherence times (less than one superframe duration, i.e., 65.536ms) and some of them also allow for power and rate control at the transmitter side.

[00134] Reference [4] provides a method for determining a data transmission characteristic, wherein data are transmitted in at least one superframe, wherein each superframe is configured to transmit a plurality of frames, the method including: sending, in the superframe, a plurality of data transmission characteristic request messages to a receiver for requesting data transmission characteristic information from the receiver, wherein the data transmission characteristic request messages are command/control messages; receiving, in the superframe, a plurality of data transmission characteristic response messages including data transmission characteristic information from the receiver in response to the data transmission characteristic request messages wherein the data transmission characteristic response messages are command/control messages; determining, from the data transmission characteristic information, at least one data transmission characteristic.

[00135] In other words, according to one embodiment of reference [4], in order to determine at least one data transmission characteristic, a device A may send, within a superframe, a data transmission characteristic request message to another device B every 'x' μs or at least once every 'x' μs. Since the duration of a superframe is about 65 ms, the transmitter of device A may send a plurality of data transmission characteristic request messages to the receiver of device B within a superframe. According to reference [4], the receiver of device B may respond to each data transmission characteristic request message by sending a data transmission characteristic response message to device A, wherein the data transmission characteristic response message includes at least one data transmission characteristic. Device A may determine the at least one data transmission characteristic based on the data transmission characteristic response message. According to reference [4], both the data transmission characteristic request message and the data transmission characteristic response message are command/control frames. [00136] According to one embodiment of reference [4], the data transmission characteristic request message sent by device A may also include data transmission characteristic information or at least one data transmission characteristic. Both device A and device B may determine at least one data transmission characteristic based on at least one data transmission characteristic request message and/or at least one data transmission characteristic response message. The data transmission characteristic may refer to information about transmission rate or transmission power of data transmission, but is not limited thereto. The data transmission characteristic may also include Link Quality Indicator (LQI) or Signal to Noise Ratio (SNR), the number of correctly received packets, the number of lost packets, the number of packets received with Frame Check Sequence (FCS) error (with no Header Check Sequence or HCS error), the number of packets transmitted to intended recipient of the command frame, and the size of measurement window in number of microseconds or milliseconds. [00137] According to one embodiment in reference [4], the command/control messages are command/control frames. According to the ECMA [1] standard, command/control frames are for sending command/control information among communication devices within a communication devices' group.

[00138] According to one embodiment in reference [4], two or more frames (or sets of two or more frames) are transmitted in the superframe by a device, and at least one data transmission characteristic request message is sent by the device before (e.g. at the beginning of) the transmission of every set of two or more frames by the device. In other words, a characteristic request message is transmitted by the device for each set of frames transmitted in the superframe by the device, such that the transmission of a characteristic request message by the device is followed by the reception of a characteristic response message by the device followed by transmission of the respective set of frames by the device.

[00139] According to one embodiment of reference [4], the data transmission characteristic request messages are sent periodically. According to one embodiment of reference [4], a data transmission characteristic request message is sent at least once during each predetermined periodic time interval. According to one embodiment of reference [4], the transmitter and the receiver are communication devices according to ECMA [1] specification. According to one embodiment, the transmitter and the receiver are communication devices according to IEEE 802.15.3b specification. [00140] According to one embodiment in line with an embodiment of reference [4], the data transmission characteristic request messages are medium access control layer messages. According to one embodiment in line with an embodiment of reference [4], the data transmission characteristic response messages are medium access control layer messages.

[00141] According to one embodiment in line with an embodiment of reference [4], data transmission may include the transmission of a plurality of data packets, and the data transmission characteristic information may include the number of data packets correctly received by the receiver or the number of data packets lost or the number of data packets received with FCS error (and not with HCS error) or the number of data packets transmitted by the receiver in a measurement window time period. According to one embodiment in line with an embodiment of reference [4], the data transmission characteristic information includes information about the measurement window time period as well.

[00142] According to one embodiment in line with an embodiment of reference [4], data transmission is performed via a communication link between a transmitter and the receiver and the data transmission characteristic information is communication link feedback information or link quality information. According to one embodiment in line with an embodiment of reference [4], the data transmission characteristic information includes information about the signal to noise ratio at the receiver pertaining to the data transmission. According to one embodiment in line with an embodiment of reference [4], the data transmission characteristic response message includes information for setting the transmit power level of the data transmission. According to one embodiment in line with an embodiment of reference [4], the data transmission characteristic response message includes information for setting the transmit data rate of the data transmission. According to one embodiment of reference [4], a data transmission characteristic request message is sent aperiodically. According to one embodiment in line with an embodiment of reference [4], the data transmission characteristic response messages include information for setting the data rate of the data transmission.

[00143] According to one embodiment in line with an embodiment of reference [4], the data transmission characteristic information includes information about suggested data rate, information about suggest transmit power level change, information about number of packets received with error, information about number of packets lost, information about number of packets transmitted to the recipient of the command frame, information about measurement window, information about number of packets correctly received, and information about SNR/LQI of communication link. [00144] According to one embodiment in line with an embodiment of reference [4], the transmitter transmits a command/control frame or a data transmission characteristic request message every 'x' μs or at least once in every 'x' μs or aperiodically or at the beginning of frame transactions and the receiver replies with a command/control frame or a data transmission characteristic response message upon reception of a command /control frame or a request message after a fixed period of time which may for example be Short Interframe Spacing (SIFS).

[00145] Reference [4] illustrates several different embodiments (possible frame payload formats for command/control frames), which also may be provided in various implementations of various embodiments in this description. According to one embodiment in line with an embodiment of reference [4], the transmitter may include a command/control frame (payload(s) as shown in various options) every 'x' μs (or at least once every 'x' μs) and/or at the beginning of frame transactions or aperiodically, and the receiver reply with a command/control frame upon reception of a command/control frame after a fixed time period which for example may be Short Interframe Spacing (SIFS). The command/control frame sent by the transmitter requesting data transmission characteristic is referred to Link Feedback Request frame. The command/control frame sent by the receiver in response to a Link Feedback Request frame is referred to "Link Feedback Reply frame".

[00146] An exemplary embodiment in line with an embodiment of reference [4] is shown in FIGs. 22 (a)-(c) illustrating the command/control frame payload formats. [00147] The command/control frame (Link Feedback Request frame, namely the data transmission characteristic request message) sent by the transmitter and the command/control frame (Link Feedback Reply frame, namely the data transmission characteristic response message) sent by the receiver in response to the Link Feedback Request frame may have the same format as shown in frame 2210 in FIG. 22 (a). [00148] The command/control frame 2210 may include a Link Feedback Control octet 2201. The command/control frame 2210 may include one or two octets 2202 in addition to the Link Feedback Control octet 2201 in the command/control frame 2210 to indicate the number of correctly received packets. The command/control frame 2210 may include one or two octets 2203 in addition to the Link Feedback Control octet 2201 in the command/control frame 2210 to indicate the number of packets lost. The command/control frame 2210 may include two octets 2204 in addition to the Link Feedback Control octet 2201 in the command/control frame 2210 to indicate the number of packets received with FCS error and with no HCS error. The command/control frame 2210 may include two octets 2205 in addition to the Link Feedback Control octet 2201 in the command/control frame 2210 to indicate the number of packets transmitted to intended recipient of the command frame. The command/control frame 2210 may include one or two octets 2206 in addition to the Link Feedback Control octet 2201 in the command/control frame 2210 to indicate the size of measurement window in number of microseconds or milliseconds. The command/control frame 2210 may include one octet 2207 in addition to the Link Feedback Control octet 2201 in the command/control frame 2210 to indicate the LQI or SNR.

[00149] Link Feedback Control octet 2201 may have the format as shown in 2220 in FIG. 22 (b). Bit2-bit7 2208 of the Link Feedback Control octet 2201 may be reserved. Bitl 2209 may be used to indicate whether there is/are other octets, such as octets 2202 and/or octets 2203 and/or octets 2204, and/or octets 2205, and/or octet(s) 2206, and/or octet 2207, included in the command/control frame 2210 following the Link Feedback Control octet 2201. BitO 2211 may be used to indicate whether the command/control frame 2210 is a Link Feedback Request frame (data transmission characteristic request message) sent by the transmitter or a Link Feedback Reply frame (data transmission characteristic response message) sent by the receiver. BitO 2211 may be set to be 0 to indicate that the command/control frame is a Link Feedback Request frame. BitO 2211 may be set to be 1 to indicate that the command/control frame is a Link Feedback Reply frame.

[00150] Link Feedback Control octet 2201 may have the format as shown in 2230 in FIG. 22 (c). Bit3-bit7 2212 of the Link Feedback Control octet 2201 may be reserved. Bit2 2213 may be used to indicate whether there is/are other octets, such as octets 2202 and/or octets 2203 and/or octets 2204, and/or octets 2205, and/or octet(s) 2206, included in the command/control frame 2210 following the Link Feedback Control octet 2201. Bitl 2214 may be used to indicate whether octet 2207 is included in the command/control frame 2210. BitO 2215 may be used to indicate whether the command/control frame is a Link Feedback Request frame (data transmission characteristic request message) or a Link Feedback Reply frame (data transmission characteristic response message). BitO 2215 may be set to be 0 to indicate that the command/control frame is a Link Feedback Request frame. BitO 2215 may be set to be 1 to indicate that the command/control frame is a Link Feedback Reply frame. Some or all of bits 3-7 2212 of the Link Feedback Control octet 2201 may indicate individually (or collectively) if one of the octets 2202, octets 2203, octets 2204, octets 2205, and octet(s) 2206 is included in the command/control frame 2210 following the Link Feedback Control octet 2201. In this context, in one embodiment bit b2 2213 may be reserved.

[00151] The transmitter may include a command/control frame (payload as shown in format 2210) once in every 'x' microseconds or aperiodically, and the receiver reply with a command/control frame upon reception of a command/control frame after a fixed time period, say for example SIFS (or later; transmitter node is also able to give feedback to the receiver node).

[00152] In one embodiment of the present invention, the proposed payloads of the command/control frames in reference [4] may be sent through Application Specific Command/Control Frames respectively using the format given in FIGs. 10 or 11. For example, the payloads as proposed in reference [4] may be included in the Command/Control Element Payload octet(s) 1104/1004 of the Application Specific Command/Control frames as shown in FIGs. 10 and 11. The Command/Control Element Type 1105/1005 may respectively be set to be a value between 0 and 15 (a fixed value to be used always for Link Feedback Command/Control Element). In other words, the Command/Control Element Type 1105/1005 may be set to be a predetermined value to correspond to a Link Feedback Command/Control Element. In one embodiment, if a receiver receives an Application Specific Command/Control Frame corresponding a Link Feedback Command/Control Element, and the device determines that the Application Specific Command/Control Element is a Link Feedback request message from the Link Feedback Control octet, e.g. the octet 2201 as shown in FIG. 22, the device may reply with a corresponding Application Specific Command/Control Frame with respective Link Feedback Command/Control Element (Link Feedback response message) after SIFS. [00153] FIG. 20 (a) illustrates the Link Feedback Command/Control Payload that may be included into an Application Specific Command/Control frame according to one embodiment.

[00154] In one embodiment, the command/control payload of the Application Specific Command/Control frames (Link Feedback Request frame, namely the data transmission characteristic request message) sent by a transmitter may have the format 2001 as shown in FIG. 20 (a). In one embodiment, the command/control payload of the Application Specific Command/Control frames (Link Feedback Reply frame, namely the data transmission characteristic response message) sent by the receiver in response to the Link Feedback Request frame may have the format as shown in format 2001 without the octets 2011. In this context, the Application Specific Command/Control frame is also referred to as the Application Specific Link Feedback command/control frame when the Application Specific Command/Control frames are sent by a device which requests the receivers to reply with a the Application Specific Command/Control frame including the requested Link feedback information or when the Application Specific Command/Control frame is sent by the receiver including the Link feedback information as requested by the transmitter.

[00155] In one embodiment, the command/control payload 2001 may include a Link Feedback Control field 2010.

[00156] In one embodiment, the command/control payload 2001 transmitted by a transmitter may include two or more octets 2011 in addition to the Link Feedback Control field 2010 in the command/control payload 2001 to indicate the device addresses of the receivers that should respond to this command/control frame transmitted by the transmitter. The order in which the device addresses of the receivers are mentioned in the list 2001 may be the order in which they need to respond with a response Link feedback command frame in one embodiment. The Device List field 2011 need not be included in a transmitted Application Specific Link feedback command frame addressed to a single receiver (unicast address). The Device List field 2011 may be included in a transmitted

Application Specific Link feedback command frame if that Application Specific Link feedback command frame is sent to multiple receivers or more than one receiver

(multicast address).

[00157] In one embodiment, Link Feedback Control field 2010 may have the format as shown in 2002 as shown in FIG. 20 (b).

[00158] In one embodiment, bitl2-bitl5 2020 of the Link Feedback Control field 2010 may be reserved.

[00159] In one embodiment, bit8-bitl 1 of the Link Feedback Control field 2010 may be used as the Data Rate field 2021 to indicate the data rate that the sender of the

Application Specific Link feedback command frame recommends to the receiver of the

Application Specific Link feedback command frame. The Data Rate field 2021 may be encoded as given in ECMA [1] specification.

[00160] In one embodiment, bit4-bit7 may be used as the Transmit Power Level

Change field 2022 to indicate the change in transmit power level that the sender of the

Application Specific Link feedback command frame. The Transmit Power Level Change field 2022 encoding may be as given in ECMA [1] specification.

[00161] In one embodiment, bit3 may be used as the Device List Field Inclusion bit

2023 to indicate whether the device list field 2011 is included in the payload 2001. In one embodiment, the Device List Field Inclusion bit 2023 is set to one if the Link feedback command frame is sent to a multicast address with Link Feedback Request bit set to one.

The Device List field 2011 may be included by the sender of the Link feedback command frame with Link Feedback Request bit set to ONE and that sent to a multicast address.

Alternatively bit3 2023 may be reserved.

[00162] In one embodiment, the bit2 of the Link Feedback Control field 2010 may be used as the Link Information Field Request bit 2024, which may be set to ONE by the sender of the Application Specific Link Feedback command frame which has its Link

Feedback Request bit 2026 set to ONE if the sender is requesting the Link Information field 2012 to be included in any Application Specific Link feedback command frame in response to the transmitted Application Specific Link feedback command frame. The Link Information Field Request bit2 2024 may be set to ONE by the sender of the Application Specific Link feedback command frame 2001 which has its Link Feedback Request bitO 2026 set to ZERO if the Link Information field 2012 is included in the transmitted Application Specific Link Feedback command frame. In all other cases, the sender of the Link feedback command frame may set the Link Information Field Request bit2 2024 to ZERO.

[00163] In one embodiment, the bitl of the Link Feedback control field 2010 may be used as the LQI Request bit 2025, which is set to one by the sender of the Link feedback command frame if the sender is requesting LQI field to be included in a Link feedback command frame in response to the transmitted link feedback command frame. In one embodiment, the LQI Request bit 2025 in a Link feedback command frame transmitted in response to a received Link feedback command frame may be treated as reserved. [00164] In one embodiment, the bitO of the Link Feedback Control field 2010 may be used as the Link Feedback Request bit 2026, which may be set to ONE by the sender of the Application Specific Link feedback command frame if the sender is requesting a Application Specific Link feedback command frame in response to the transmitted Application Specific Link feedback command frame. The Link Feedback Request bitO 2026 may be set to ZERO in the Application Specific Link feedback command frame that is transmitted in response to a Application Specific Link feedback command frame received.

[00165] In one embodiment, the command/control payload 2001 may include two octets as the LQI field 2013 in addition to the Link Feedback Control field 2010 in the Application Specific Command/Control frame to indicate the LQI or SNR. [00166] The LQI field 2013 is the Link Quality Indicator (LQI) of the link between the sender of the Application Specific Link feedback command frame and the destination of the Application Specific Link feedback command frame as measured by the sender of the Application Specific Link feedback command frame. In one embodiment, the LQI field 2013 may not be included as part of the transmitted Application Specific Link feedback command frame if the Link Feedback Request bit 2026 is set to one. [00167] In one embodiment, the Application Specific Command/Control frame may include a Link Information field 2012 in the payload 2001. The Link Information Field Request bit 2024 is set to one by the sender of the Application Specific Link feedback command frame if the sender is requesting the Link Information field 2012 to be included in a Application Specific Link feedback command frame in response to the transmitted Application Specific Link feedback command frame. In one embodiment, the Link Information Field Request bit 2024 in a Application Specific Link feedback command frame transmitted in response to a received Application Specific Link feedback command frame may be treated as reserved. In one embodiment, the octets 2012 may not be included in a transmitted Application Specific Link feedback command frame if the Link Feedback Request bit 2026 in that Application Specific Link feedback command frame 2001 is set to ONE.

[00168] hi one embodiment, Link Information field 2012 may have the format 2003 as shown in FIG. 20 (c). In one embodiment, the Link Information field 2012 includes the Recipient Frame Loss Count field 2030 indicating the number of frames as determined by the sender of the Application Specific Link feedback command frame that have been lost. [00169] In one embodiment, the Link Information field 2012 includes the Recipient Frame Error Count field 2031 indicating the total number of frames that were received with FCS errors but not with HCS errors by the sender of the Application Specific Link feedback command frame from the destination of the Link feedback command frame. [00170] hi one embodiment, the Link Information field 2012 includes the Recipient Frame Count field 2032 indicating the total number of frames that were correctly received by the sender of the Application Specific Link feedback command frame from the destination of the Application Specific Link feedback command frame. [00171] In one embodiment, the Link Information field 2012 includes the Source Frame Count field 2033 indicating the total number of frames, including retransmissions, that were transmitted by the sender of the Link feedback command frame to the destination of the Application Specific Link feedback command frame. [00172] hi one embodiment, the Link Information field 2012 includes the Measurement Window Size field 2034 indicating the amount of time in micro-seconds during which the measurements were taken.

[00173] The Link Information field may not be included in a Link feedback command frame with its Link Feedback Request bit set to one according to one embodiment. [00174] FIG. 21 (a) illustrates an alternate format of the Link Information field 2012 according to one embodiment.

[00175] As can be seen, the Link Information field 2012 may comprise an octet as the Recipient Frame Loss Ratio field 2101 indicating the decimal value of the ratio between Recipient Frame Loss Count and Recipient Frame Count. In one embodiment, the Link Information field 2012 may further include an octet as the Recipient Frame Error Ratio field 2102 indicating the decimal value of the ratio between Recipient Frame Error Count and Recipient Frame Count. In one embodiment, the Link Information field 2012 may further comprise 2 octets as the Measurement Window Size field 2103 indicating the amount of time in micro-seconds during which the measurements were taken. [00176] FIG. 21 (b) illustrates the format of the Device List field 2011 according to one embodiment.

[00177] In one embodiment, the Device List field 2011 may include one or a plurality of Device Address fields 2110, each Device Address field 2110 indicating the address of a device wherein the device is one of the devices that the sender wants to receive a Link Feedback command frame from.

[00178] A device that receives a Application Specific Link feedback command frame 2001 addressed to a unicast address (single receiver) and with its Link Feedback Request bit 2026 set to ONE may respond with a Application Specific Link feedback command frame after SIFS or any fixed time period after the reception of the received Application Specific Link feedback command frame. The device may include suggested transmit power level change 2022 and data rate 2021 in the Application Specific Link feedback command frame 2001 the device transmits in response to a received Application Specific Link feedback command frame. The device may include LQI field 2013 in the Application Specific Link Feedback command frame 2001 that the device transmits in response to a received Application Specific Link Feedback command frame if the LQI Field Request bit 2025 was set to ONE in the received Application Specific Link Feedback Command frame. The device may include Link Information field 2012 in the Application Specific Link feedback command frame 2001 that the device transmits in response to a received Application Specific Link feedback command frame if the Link Information Field Request bit 2024 was set to ONE in the received Application Specific

Link feedback command frame.

[00179] In one embodiment, on reception of a Application Specific Link feedback command frame sent to a multicast address (multiple receivers), if the receiver device determines that the address of its own (its Dev Address) is in the Device List of the received Link feedback command frame, the device may respond with a Link feedback command frame. The device may transmit a Link feedback command frame after a delay given by:

[00180] Time_to_send_Response = pSIFS + pSlotTime + (Position in Device List) x

(Link feedback command frame duration + pSIFS)

[00181] Time to send Response is calculated from the end of reception of the Link feedback command frame. Possible values of Position in Device List in Link feedback command frame are in the range [0, N-I], inclusive. pSIFS and pSlotTime are as given in

ECMA [1] specification.

[00182] The receiver device may respond with a response Application Specific Link feedback command frame with the payload 2001. The device may include suggested transmit power level change 2022 and data rate 2021 in the Link feedback command frame 2001 that the device transmits in response to a received Application Specific Link feedback command frame. The device may include LQI field 2013 in the response

Application Specific Link feedback command frame 2001 that the device transmits in response to a received Application Specific Link feedback command frame if the LQI

Field Request bit 2025 was set to ONE in the received Application Specific Link feedback command frame. The device may include Link Information field 2012 in the response Application Specific Link feedback command frame with payload 2001 that the device transmits in response to a received Application Specific Link feedback command frame if the Link Information Field Request bit 2024 was set to ONE in the received

Application Specific Link feedback command frame.

[00183] 5. USE OF APPLICATION SPECIFIC DATA PERTAINING TO

CHANNEL CONSENSUS IE

[00184] Reference [5] provides a method for operating an ultra-wideband radio communication device. The method provided includes generating a channel changing negotiating message including information about at least one frequency channel the ultra- wideband radio communication device intends to change to. The method provided further includes transmitting the channel changing negotiating message to at least one other ultra-wideband radio communication device with which the ultra-wideband radio communication device has an established communication connection in a current frequency channel.

[00185] Further according to reference [5], the ultra-wideband radio communication device may receive channel changing negotiating messages from the at least one other ultra-wideband radio communication device, where the channel changing negotiating messages include information about at least one frequency channel the other ultra- wideband radio communication device intends to change to. The ultra- wideband radio communication device may determine whether the ultra-wideband radio communication device is able to change to the at least one frequency channel included in the channel changing negotiating message, and may generate a further channel changing negotiating message including information about at least one frequency channel the ultra-wideband radio communication device intends to change to. The ultra- wideband radio communication device may then transmit the further channel changing negotiating message to the other ultra-wideband radio communication device.

[00186] According to one embodiment of the reference [5], the Channel Consensus (CC) Information Element (IE) is used as a channel changing negotiating message. [00187] In order for each communication device to provide information on the frequency channels that it is able or willing to change to, the communication device may include a Channel Consensus (CC) Information Element in its beacon, for example, in the next superframe.

[00188] The Channel Consensus (CC) Information Element may then be used by all communication devices within the beacon group which are willing to move their operation to a new unused frequency channel to move to a common unused frequency channel. In this context, the Channel Consensus (CC) Information Element is used by a communication device to provide the necessary information (on the available unused frequency channel options the communication device may be able to change to) to the neighboring communication devices in the beacon group, so that a consensus decision may be obtained on which unused frequency channel to change to. [00189] For example, according to an embodiment in line with an embodiment reference [5], the Channel Consensus (CC) Information Elements may include a Length field in the CC IEs to store the length of the information stored (in terms of octets) in the Channel Consensus (CC) Information Element. For example, the Channel Consensus (CC) Information Elements may include a Channel Consensus (CC) Control field to store control information. For example, the Channel Consensus (CC) Information Elements may include a Device Address field to store the address of the communication device which is making a beacon transmission. For example, the Channel Consensus (CC) Information Elements may include a plurality of Channel Number fields to store the status of all the frequency channels in the communication system. For example, the Channel Consensus (CC) Information Elements may include a Band Availability field to store information on the availability of frequency bands.

[00190] According to one embodiment in line with an embodiment of reference [5], once a communication device detects an interference signal energy level, which is greater than a energy threshold level, for example, the communication device may include a Channel Consensus (CC) Information Element in its beacon transmission in every superframe starting from the next superframe, for a predetermined number of superframes (after the transmission of its first Channel Consensus (CC) Information Element).

[00191] The Channel Consensus (CC) Information Element transmitted may include information on the frequency channels which the communication device is able or willing to switch to. Further, the Channel Consensus (CC) Information Element transmitted may also include information that the communication device transmitting the beacon is the originator or initiator of the Channel Consensus (CC) Information Element. [00192] The communication device, which is the originator (or the initiator) of the Channel Consensus (CC) Information Element, waits in one embodiment for the predetermined number of superframes (after transmitting its first Channel Consensus (CC) Information Element) in order to receive all the response Channel Consensus (CC) Information Elements from its neighboring communication devices, before making the decision on which frequency channel to switch to. The decision made on frequency channel to switch to may be observed in the Channel Change Information Element transmitted by the communication device (which is the originator (or the initiator) of the Channel Consensus (CC) Information Element) subsequently.

[00193] According to one embodiment in line with an embodiment of reference [5] only the communication device, which is the originator (or the initiator) of the Channel Consensus (CC) Information Element, makes the decision on which frequency channel to switch to. Additionally in one embodiment of reference [5], the communication device, which is the originator (or the initiator) of the Channel Consensus (CC) Information Element, only considers the information from the last received Channel Consensus (CC) Information Element from any neighboring communication device when making the decision on which frequency channel to switch to.

[00194] Upon receiving a Channel Consensus (CC) Information Element, a communication device, which is not the originator (or the initiator) of the Channel Consensus (CC) Information Element, for example transmits a response Channel Consensus (CC) Information Element in the next superframe. The response Channel Consensus (CC) Information Element transmitted for example includes information on the frequency channels which the communication device is able or willing to switch to, as well as information that it is not the originator of the Channel Consensus (CC) Information Element.

[00195] A communication device, which transmits a response Channel Consensus (CC) Information Element (i.e., which includes information that the communication device transmitting the beacon is not the originator or initiator of the Channel Consensus (CC) Information Element), may not include information on any frequency channel (or band) which was not included on the last received Channel Consensus (CC) Information Element from a neighbor.

[00196] If a communication device receives a Channel Consensus (CC) Information Element after it had earlier transmitted a Channel Change Information Element, the communication device may only transmit its response Channel Consensus (CC) Information Element, which includes information on the frequency channel (or band) which it is switching to as included in its Channel Change Information Element. Alternatively, a communication device which receives a Channel Consensus (CC) Information Element after it had earlier transmitted a Channel Change Information Element may not respond with any Channel Consensus Information Element until a channel change.

[00197] According to one embodiment, the use of Channel Consensus IE for ECMA [1] specified devices as proposed by reference [5] may be sent as part of the ASIE using the format given in FIG. 9 in accordance with various embodiments. For example, the Channel Consensus IE may be included in the ASIE after the Application Specific Identifier field which corresponds to Information Elements. The rules for using Channel Consensus IE can be found in [5] and those rules apply even when Channel Consensus IE is sent through ASIE. The inclusion of the Channel Consensus IE as part of the ASIE may, for example, be used for the communication among devices which are using a higher TFC offsets.

[00198] 6. ALIEN BEACON PERIODS ALIGNMENT

[00199] FIG. 23 (a) illustrates a method for synchronizing at least a first radio communication terminal device with a second radio communication terminal device in a radio communication system in one embodiment. In one embodiment, the method may include a step 2301 of determining as to whether the second radio communication terminal device has not changed its synchronization transmitting period start time for a predetermined time. In one embodiment, the method further includes a step 2302 of determining the synchronization transmitting period start time of the second radio communication terminal device. In one embodiment, the method may further include a step 2303, in case the second radio communication terminal device has not changed its synchronization transmitting period start time for a predetermined time, setting the synchronization transmitting period start time of the first radio communication terminal device to the synchronization transmitting period start time of the second radio communication terminal device. In one embodiment, the first radio communication terminal device and the second radio communication terminal device are ad hoc radio communication terminal devices in an ad hoc radio communication system. [00200] In other words, for example, referring to an ad hoc radio communication system 1800 as shown in FIG. 18 (a). Assuming that devices B1-B3 1856-1858 are the ad hoc radio communication terminal devices according to the ECMA [1] standard wherein devices B1-B3 1856-1858 may only use slotted time/frequency portions for communication but can not use slotted offset TFC for communication. Assuming that devices A1-A5 1851-1855 are from the same vendor and are ad hoc radio communication terminal devices which may communicate with slotted offset TFC (TFC offset 0, TFC offset 1 and TFC offset 2 as shown in FIG. 2). In a situation that devices A1-A5 1851- 1855 and devices B1-B3 1856-1858 are within a same extended beacon group of device Al 1851 and devices A3-A5 1853-1855 and Bl 1856 are in the beacon group of device Al, all the devices A1-A5 1851-1855 and B1-B3 1856-1858 need to synchronize with each other for communication purpose, e.g. for reservation of radio resources. In one embodiment, for example, if the slowest device is one of communication devices B1-B3 1856-1858, then one of communication devices A1-A5 1851-1855 synchronizes with the slowest device first. Further, other communication devices of A2-A5 1852-1855 then synchronize with communication device Al 1851. In one embodiment, the method relates to the synchronizing of a first ad hoc radio communication terminal device (any of communication devices A1-A5 1851-1855 shown in FIG. 18 (a)) with a second ad hoc radio communication terminal device (any of communication devices A1-A5 1851-1855 or B1-B3 1856-1858 as shown in FIG. 18 (a)) in an ad hoc radio communication system (e.g. communication system 1800 as shown in FIG. 18 (a)). For example, the ad hoc radio communication terminal device Al 1851 may determine as to whether the ad hoc radio communication terminal device Bl 1856 has not changed Bl 1856's synchronization transmitting period start time for a predetermined time. It is a general rule for an ad hoc communication system that devices within the communication system synchronize with each other. Normally, for example, devices synchronize with the slowest device in the system (beacon group). According to the ECMA [1] standard and in accordance with various embodiments, upon synchronization, for example, a faster device adjusts its Beacon Period Start Time (BPST) every superframe in order to align its BPST with the BPST of the slowest device. Thus, generally speaking, the ECMA [1] specified device which does not change its BPST in each superframe is the slowest device in the communication group, and is the one that the other communication device should synchronize with. In the example with reference to FIG. 18 (a), device Al 1851 determines that whether device Bl 1856 changes its synchronization transmitting period start time, e.g. BPST, for a predetermined time, e.g. a number of superframes, such that device Al 1851 may know whether device Bl 1856 is the slowest communication device of at least the beacon group of Al 1851 (note that if the slowest device in Al 185 l's beacon group is A5 1855 and if A5 1855 does not move its BPST for a predetermined amount of time, Al would be able to synchronize with A5 1855 to clock period level using the procedure given in [3]). In one embodiment, device Al 1851 may determine the synchronization transmitting period start time of Bl 1856. For example, using the methods as provided by reference [3] which is also summarized later in the present application, device Al 1851 may decide whether device Bl 1856 is slower than device Al 1851 or not. In this example, assume that device Al 1851 finds out that device Bl 1856 is slower than device Al 1851 (and Bl 1856 is the slowest in Al 1851's beacon group), meaning that device Al 1851 needs to adjust its synchronization transmitting period start time in order to synchronize with device Bl 1856. In one embodiment, in case device Bl 1856 has not changed its synchronization transmitting period start time for a predetermined time, device Al 1851 sets the synchronization transmitting period start time of device Al 1851 to the synchronization transmitting period start time of device Bl 1856, thereby synchronizing with device Bl 1856.

[00201] In one embodiment, the step 2302 may further comprise determining the clock period of the second radio communication terminal device. For example, device Al 1851 determines the clock period of the device Bl 1856.

[00202] In one embodiment, the step 2303 may further comprise, in case the second radio communication terminal device has not changed its synchronization transmitting period start time for a predetermined time, setting a virtual clock which may be a register of the first ad hoc radio communication terminal device to the clock of the second radio communication terminal device. For example, if device Al 1851 determines that device Bl 1856 has not changed its BPST for a predetermined number of superframes, device Al 1851 may set a virtual clock which may be a register to the clock of device Bl 1856 in order to synchronize with device Bl 1856.

[00203] In one embodiment, the synchronization transmitting period start time is a Beacon Period Start Time (BPST). [00204] In one embodiment, the second radio communication terminal device is of a first type of ad hoc radio communication terminal device configured to provide only slotted time/frequency portion communication without slotted offset time/frequency portion communication. For example, the second radio communication terminal device Bl 1856 is an ad hoc radio communication terminal device according to the ECMA [1] standard, and may only use slotted time/frequency portions without an offset for communication, but can not use slotted offset TFC (TFC offset 0, TFC offset 1, and TFC offset 2) for communication.

[00205] In one embodiment, the first radio communication terminal device is of a second type of radio communication terminal device configured to provide slotted time/frequency portion communication and slotted offset time/frequency portion communication. In other words, for example, referring to the example in relation to FIG. 18 (a), devices A1-A5 1851-1855 are of the second type of ad hoc radio communication terminal devices which may communicate using both the default TFC (TFC offset 0) and the higher slotted offset TFC (TFC offset 1 and TFC offset 2).

[00206] hi one embodiment, the time/frequency portions comprise time/frequency codes (TFCs).

[00207] In one embodiment, determining as to whether the second radio communication terminal device has not changed its synchronization transmitting period start time for a predetermined time comprises determining as to whether the second radio communication terminal device has not changed its synchronization transmitting period start time for a predetermined number of at least one of frames and superframes. For example, referring to FIG. 18 (a), device Al 1851 may determine whether device Bl 1856 has changed its synchronization transmitting period start time (e.g. BPST) for a predetermined number of superframes, e.g. the previous six superframes. [00208] In one embodiment, the method is carried out by an ad hoc radio communication terminal device.

[00209] In one embodiment, the method may further include a step 2304 of determining as to whether the synchronization transmitting period start time of the first radio communication terminal device has been set to the synchronization transmitting period start time of the second radio communication terminal device. For example, referring to FIG. 18 (a), device Al 1851 may determine whether device Al 1851 has adjusted its BPST to align with the BPST of device Bl 1856. Other devices A2-A5 1852- 1855 may determine from the BPSTs of device Al 1851 as to whether device Al 1851 has adjusted Al's BPST in alignment with device Bl 1856.

[00210] In one embodiment, the method may further include a step 2305, in case the synchronization transmitting period start time of the first radio communication terminal device has been set to the synchronization transmitting period start time of the second radio communication terminal device, setting the synchronization transmitting period start time of a third radio communication terminal device to the synchronization transmitting period start time of the first radio communication terminal device. In other words, for example, referring to FIG. 18 (a), if device A5 1855 determines that device Al 1851 has already set Al 1851 's synchronization transmitting period start time (e.g. BPST) to the synchronization transmitting period start time of device Bl 1856, device A5 1855 may then take steps to synchronize with device Al 1851's BPST, for example, using the methods as proposed in reference [4] which is also disclosed later in the present application. Similarly, all the other devices A3-A4 1853-1854 may synchronize with device Al 1851 after they determine that device Al 1851 has synchronized with device Bl 1856. In one embodiment methods in [4] are continued to be used every superframe by a device only if there is a slowest device in the beacon group that has not moved its BPST for a particular number of previous superframes.

[00211] hi one embodiment, the third radio communication terminal device is of the same type of radio communication terminal device as the first radio communication terminal device. In other words, for example, referring to FIG. 18 (a), device Al 1851 and all the other devices A3-A5 1853-1855 in beacon group of Al 1851 are of the same type of ad hoc radio communication terminal devices which may use slotted offset TFC for communication.

[00212] FIG. 23 (b) illustrates a first radio communication terminal device 2310 for synchronizing with a second radio communication terminal device (not shown) in a radio communication system. In one embodiment, the first radio communication terminal device 2310 comprises a first determining circuit 2311 being configured to determine as to whether the second radio communication terminal device has not changed its synchronization transmitting period start time for a predetermined time. In one embodiment, the first radio communication device and the second radio communication device are ad hoc radio communication terminal devices, and the radio communication system is an ad hoc radio communication system.

[00213] In one embodiment, the first radio communication terminal device 2310 may further include a second determining circuit 2312 being configured to determine the synchronization transmitting period start time of the second radio communication terminal device. In one embodiment, the second determining circuit 2312 is further configured to determine the clock period of the second radio communication terminal device.

[00214] In one embodiment, the first radio communication terminal device 2310 may further include a synchronization circuit 2313 being configured to, in case the second radio communication terminal device has not changed its synchronization transmitting period start time for a predetermined time, set the synchronization transmitting period start time of the first radio communication terminal device 2310 to the synchronization transmitting period start time of the second radio communication terminal device. In one embodiment, the synchronization circuit 2313 is further configured to, in case the second radio communication terminal device has not changed its synchronization transmitting period start time for a predetermined time, set a virtual clock which may be a register of the first radio communication terminal device to the clock of the second radio communication terminal device.

[00215] In one embodiment, the synchronization transmitting period start time is a

Beacon Period Start Time.

[00216] In one embodiment, the second radio communication terminal device is of a first type of radio communication terminal device configured to provide only slotted time/frequency portion communication without slotted offset time/frequency portion communication.

[00217] In one embodiment, the first radio communication terminal device 2310 is of a second type of radio communication terminal device configured to provide slotted time/frequency portion communication and slotted offset time/frequency portion communication. [00218] In one embodiment, the time/frequency portions may include time/frequency codes.

[00219] In one embodiment, determining as to whether the second radio communication terminal device has not changed its synchronization transmitting period start time for a predetermined time by the first determining circuit 2311 may include determining as to whether the second radio communication terminal device has not changed its synchronization transmitting period start time for a predetermined number of at least one of frames and superframes.

[00220] In one embodiment, the first radio communication terminal device 2310 may further include a third determining circuit 2314 being configured to determine as to whether the synchronization transmitting period start time of the first radio communication terminal device 2310 has been set to the synchronization transmitting period start time of the second radio communication terminal device. [00221] FIG. 18 (a) illustrates a radio communication system which may include at least a first radio communication terminal device Al 1851 and a second radio communication terminal Bl 1856 in one embodiment. In one embodiment, the first radio communication terminal device Al 1851 may be configured to determine as to whether the second radio communication terminal device Bl 1856 has not changed its synchronization transmitting period start time for a predetermined time. In one embodiment, the first radio communication terminal device Al 1851 may be configured to determine the synchronization transmitting period start time of the second radio communication terminal device Bl 1856. In one embodiment, the first radio communication terminal device Al 1851 may be configured to, in case the second radio communication terminal device Bl 1856 has not changed its synchronization transmitting period start time for a predetermined time, set the synchronization transmitting period start time of the first radio communication terminal device Al 1851 to the synchronization transmitting period start time of the second radio communication terminal device Bl 1856. In one embodiment, the radio communication system is an ad hoc radio communication system, wherein the at least first radio communication terminal device and second radio communication terminal device comprised in the radio communication system are ad hoc radio communication terminal devices. [00222] In one embodiment, wherein the first radio communication terminal device

Al 1851 is further configured to determine the clock period of the second radio communication terminal device Bl 1856.

[00223] hi one embodiment, the first radio communication terminal device Al 1851 is configured to, in case the second radio communication terminal device Bl 1856 has not changed its synchronization transmitting period start time for a predetermined time, set virtual clock which may be a register of the first radio communication terminal device

Al 1851 to clock of the second radio communication terminal device Bl 1856.

[00224] hi one embodiment, the synchronization transmitting period start time may be a Beacon Period Start Time.

[00225] In one embodiment, the second radio communication terminal device Bl

1856 is of a first type of radio communication terminal device configured to provide only slotted time/frequency portion communication without slotted offset time/frequency portion communication.

[00226] In one embodiment, the first radio communication terminal device Al 1851 is of a second type of radio communication terminal device configured to provide slotted time/frequency portion communication and slotted offset time/frequency portion communication.

[00227] In one embodiment, the time/frequency portions may include time/frequency codes.

[00228] hi one embodiment, determining as to whether the second radio communication terminal device Bl 1856 has not changed its synchronization transmitting period start time for a predetermined time by the first radio communication terminal device Al 1851 may include determining as to whether the second radio communication terminal device Bl 1856 has not changed its synchronization transmitting period start time for a predetermined number of at least one of frames and superframes.

[00229] hi one embodiment, the radio communication system may further include a third radio communication terminal device A5 1855. In one embodiment, the first radio communication terminal device Al 1851 may be configured to determine as to whether the synchronization transmitting period start time of the first radio communication terminal device Al 1851 has been set to the synchronization transmitting period start time of the second radio communication terminal device Bl 1856. In one embodiment, the third radio communication terminal device A5 1855 is configured to, in case the synchronization transmitting period start time of the first radio communication terminal device Al 1851 has been set to the synchronization transmitting period start time of the second radio communication terminal device Bl 1856, set the synchronization transmitting period start time of a third radio communication terminal device A5 1855 to the synchronization transmitting period start time of the first radio communication terminal device Al 1851.

[00230] In one embodiment, the third radio communication terminal device A5 1855 is of the same type of ad hoc radio communication terminal device as the first ad hoc radio communication terminal device Al 1851.

[00231] In one embodiment, the third radio communication terminal device A5 1855 is configured to, in case the synchronization transmitting period start time of the first radio communication terminal device Al 1851 has been set to the synchronization transmitting period start time of the second radio communication terminal device Bl

1856, set the virtual clock which may be a register of the third radio communication terminal device A5 1855 to the clock of the first radio communication terminal device Al

1851.

[00232] 6.1 Enhanced BP Switch IE

[00233] Due to changes in the propagation environment, mobility, or other effects, devices using two or more unaligned BPSTs may come into range. This may cause overlapping superframes. A received beacon with valid Header Check Sequence (HCS) and Frame Check Sequence (FCS) that indicates a BPST that is not aligned with a device's own BPST is referred to as an alien beacon. The BP defined by the BPST and

BP length in an alien beacon is referred to as an alien BP.

[00234] In one embodiment, an Enhanced BP Switch IE is provided to indicate that a device will change its BPST to align with an alien BP.

[00235] FIG. 24 illustrates the format of the proposed Enhanced BP Switch IE 2400.

[00236] As can be seen, the Enhanced BP Switch IE 2400 may include an Element ID field 2401 indicating the type of the Information Element. The Enhanced BP Switch IE

2400 may further include a Length field 2402 indicating the length of the payload of the IE. In one embodiment, the Enhanced BP Switch IE 2400 may further include a BP Move Countdown field 2403. In one embodiment, the Enhanced BP Switch IE 2400 may further include a Beacon Slot Offset field 2404. In one embodiment, the Enhanced BP Switch IE 2400 may further include a Clock Period Offset field 2405. In one embodiment, the Enhanced BP Switch IE 2400 may further include a BPST Offset field 2406.

[00237] In one embodiment, the BP Move Countdown field 2403 may be set to the number of superframes after which the device will adjust its BPST, for example, to align its BPST with the BPST of another device. In one embodiment, if value of BP Move Countdown is zero, the next beacon frame transmitted will be at the time specified by this IE.

[00238] In one embodiment, the Beacon Slot Offset field 2404 is set to a positive number by which the device will adjust its beacon slot number when changing its BPST or is set to zero to indicate the device will join the alien BP using normal BP join rules as given in ECMA [1] specification.

[00239] The Clock Period Offset field 2405 is set to the positive amount of time in units of 0.01 femto seconds the clock period of the alien device is larger than the current clock period of the slowest device in the device's beacon group that the device's virtual clock is synchronized to. The BPST Offset field 2406 is set to the positive amount of time the device will delay its BPST, in nanoseconds.

[00240] FIG. 25 (a) illustrates a method for synchronizing a first plurality of radio communication terminal devices with a second plurality of radio communication terminal devices in a radio communication system. In one embodiment, the method may include, in a radio communication terminal device of the second plurality, carrying out: a step 2501 of determining a synchronization transmitting period start time of a radio communication terminal device of the first plurality. In one embodiment, the method may further include, the radio communication terminal device of the second plurality, carrying out a step 2502 of beginning the process of setting the synchronization transmitting period start time of the radio communication terminal device of the second plurality to the determined synchronization transmitting period start time of the radio communication terminal device of the first plurality. In one embodiment, the method may further include, the radio communication terminal device of the second plurality, carrying out a step 2503 of generating a synchronization message including information about the determined synchronization transmitting period start time of the radio communication terminal device of the first plurality. In one embodiment, the first plurality of radio communication terminal devices and the second plurality of radio communication terminal devices are ad hoc radio communication terminal devices in an ad hoc radio communication system.

[00241] In other words, for example, referring to FIG. 18 (a), a communication device Al 1851 may receive a beacon from device A4 1854 and determine that the beacon from A4 1854 is an alien beacon, meaning that the BPST of device A4 1854 is not aligned with the BPST of device Al. In this example, assume the BPST of the first plurality of devices A3-A4 (1853 and 1854) is not aligned with the BPST of the second plurality of devices Al and A5 (1851 and 1855). According to the method in one embodiment, for example, the device Al 1851 may, based on the reception time of the alien beacon from device A4 1854, determine a synchronization transmitting period start time (e.g. BPST) of device A4 1854. In this example, assuming that based on the BPST of device A4 1854 determined by device Al 1851, device Al 1851 determines that device Al 1851 is faster than device A4 1854. Then device Al 1851 needs to take step to adjust its BPST to align with the BPST of device A4 1854 so that device Al 1851 is synchronized with device A4 1854. In other words, device Al 1851 may set the synchronization transmitting period start time (e.g. BPST) of device Al 1851 to the determined synchronization transmitting period start time (BPST) of device A4 1854. The way to setting the BPST of device Al 1851 may be through the setting of a virtual clock, which will be described later in the application. Further, device Al 1851 may generate a synchronization message including information about the determined synchronization transmitting period start time of device A4 1854. For example, referring to FIG. 24, the synchronization message may comprise the proposed Enhance BP Switch IE element 2400 as shown in FIG. 24. The BP Move Countdown field 2403 of the Enhanced BP Switch IE element is used to indicate the time that the device Al 1851 will start to adjust its BPST to align with the BPST of device A4 1854. In one embodiment, the Enhanced BP Switch IE element 2400 is included into an Application Specific Information Element (ASIE) and is sent by device Al 1851 in its beacon. The ASIE may be encoded according to the format as proposed in FIG. 8, for example.

[00242] In one embodiment, the step 2501 may further comprise, in the radio communication terminal device, e.g. device Al 1851, of the second plurality, carrying out: determining the clock period of a radio communication terminal device, e.g. device

A4 1854, of the first plurality.

[00243] hi one embodiment, the step 2504 may further comprise in the radio communication terminal device, e.g. device Al 1851, of the second plurality, carrying out: setting the virtual clock which may be a register of the radio communication terminal device, e.g. device Al 1851, of the second plurality to the clock of the radio communication terminal device, e.g. device 1854, of the first plurality.

[00244] In one embodiment, the step 2503 may further comprise in the radio communication terminal device, e.g. device Al 1851 of the second plurality, carrying out: generating a synchronization message including information about the determined clock period of the radio communication terminal device, e.g. device A4 1854, of the first plurality.

[00245] hi one embodiment, the first plurality of radio communication terminal devices is of a first type, and the second plurality of radio communication terminal devices is of a second type. In one embodiment, the first type of radio communication terminal devices is configured to provide only slotted time/frequency portion communication without slotted offset time/frequency portion communication. In one embodiment, the second type of radio communication terminal devices is configured to provide slotted time/frequency portion communication and slotted offset time/frequency portion communication. For example, the first plurality of radio communication terminal devices may be according to the ECMA standard [I]. The second plurality of ad hoc radio communication terminal devices may be able to use slotted offset time/frequency portions for communication.

[00246] hi one embodiment, the synchronization message includes an Application

Specific Information Element being encoded in accordance with a second communication protocol format which can be decoded by a radio communication terminal device of the second type. [00247] In one embodiment, the method may further include, the radio communication terminal device of the second plurality, carrying out a step 2504 of transmitting the synchronization message to at least one other radio communication terminal device of the second plurality. In other words, for example, device Al 1851 of the second type may transmit the ASIE which includes the Enhanced BP Switch IE element 2400 to A5 1855 of the second plurality.

[00248] In one embodiment, the first plurality of radio communication terminal devices are members of a first radio communication terminal devices group. In one embodiment, the second plurality of radio communication terminal devices are members of a second radio communication terminal devices group.

[00249] hi one embodiment, the radio communication terminal devices groups may be or may include radio communication terminal devices beacon groups. [00250] hi one embodiment, the synchronization transmitting period start time may include at least one of a Beacon Period Start Time and a Beacon Period Start Time offset, hi other words, the indicated started time by Al 1851 may be the time offset that device Al 1851 needs to adjust its BPST in order to align with the BPST of device A4 1854. [00251] In one embodiment, the time/frequency portions may include time/frequency codes.

[00252] hi one embodiment, the method may further include, in the at least one other radio communication terminal device of the second plurality, carrying out a step 2505 of receiving the synchronization message. In one embodiment, the method may further include, in the at least one other radio communication terminal device of the second plurality, carrying out a step 2506 of setting the synchronization transmitting period start time of the at least one other radio communication terminal device of the second plurality to the inferred synchronization transmitting period start time of the radio communication terminal device of the first plurality. In other words, for example, referring to FIG. 18 (a), after device Al 1851 sends out the ASIE, other device, for example device A5 1855, receives and decodes the ASIE from device Al 1851. Further, device A5 1855 may also set the time to adjust its BPST in line with the device Al 1851 (implying with device A4 1854). [00253] In one embodiment, the step 2506 may further comprise in the at least one other radio communication terminal device, e.g. device A5 1855, of the second plurality: setting the virtual clock which is a register of the at least one other radio communication terminal device, e.g. device A5 1855, of the second plurality to the clock of the radio communication terminal device, e.g. device A4 1854, of the first plurality.

[00254] FIG. 25 (b) illustrates a first radio communication terminal device 2510 which is among a first plurality of radio communication terminal devices for synchronizing with a second radio communication terminal device which is among a second plurality of radio communication terminal devices in an radio communication system, hi one embodiment, the first plurality and the second plurality of radio communication terminal devices are ad hoc radio communication terminal devices within an ad hoc radio communication system.

[00255] In one embodiment, the first radio communication terminal device 2510 may include a determining circuit 2511 being configured to determine a synchronization transmitting period start time of the second radio communication terminal device. In one embodiment, the first radio communication terminal device 2510 may include a synchronization circuit 2512 being configured to set the synchronization transmitting period start time of the first radio communication terminal device 2510 to the determined synchronization transmitting period start time of the second radio communication terminal device.

[00256] In one embodiment, the determining circuit 2511 is configured to determine the clock period of the second radio communication terminal device of the second plurality.

[00257] In one embodiment, the synchronization circuit 2512 is configured to set the virtual clock which may be a register of the first radio communication terminal device to the clock of the second radio communication terminal device.

[00258] In one embodiment, the first plurality of radio communication terminal devices is of a first type, the second plurality of radio communication terminal devices is of a second type. In one embodiment, the first type of radio communication terminal devices is configured to provide slotted time/frequency portion communication and slotted offset time/frequency portion communication, and the second type of radio communication terminal devices is configured to provide only slotted time/frequency portion communication without slotted offset time/frequency portion communication.

[00259] In one embodiment, the first radio communication terminal device 2510 may include a generating circuit 2513 being configured to generate a synchronization message including information about the synchronization transmitting period start time of the first radio communication terminal device of the first plurality.

[00260] In one embodiment, the synchronization message includes information about the determined clock period of the second radio communication terminal device.

[00261] In one embodiment, the synchronization message includes an Application

Specific Information Element being encoded in accordance with a second communication protocol format which can be decoded by a radio communication terminal device of the second type.

[00262] In one embodiment, the first radio communication terminal device 2510 may include a transmitting circuit 2514 being configured to transmit the synchronization message to at least one other radio communication terminal device of the first plurality of radio communication terminal devices.

[00263] hi one embodiment, the first plurality of radio communication terminal devices are members of a first radio communication terminal devices group. In one embodiment, the second plurality of radio communication terminal devices are members of a second radio communication terminal devices group.

[00264] In one embodiment, the radio communication terminal devices groups are ad hoc radio communication terminal devices beacon groups.

[00265] hi one embodiment, the synchronization transmitting period start time may include at least one of a Beacon Period Start Time and a Beacon Period Start Time offset.

[00266] hi one embodiment, the time/frequency portions may include time/frequency codes.

[00267] hi one embodiment, a radio communication system comprising a first plurality of radio communication terminal devices and a second plurality of radio communication terminal devices is provided. In one embodiment, the radio communication system is an ad hoc radio communication system, wherein the first plurality of radio communication terminal devices and the second plurality of radio communication terminal devices are ad hoc radio communication terminal devices. FIG. 18 (a) illustrates a radio communication system 1800 according to one embodiment. [00268] In one embodiment, a radio communication terminal device, e.g. device Al 1851, of the second plurality of radio communication terminal devices is configured to carry out determining a synchronization transmitting period start time of a radio communication terminal device, e.g. device A4 1854 of the first plurality. In one embodiment, the radio communication terminal device Al 1851 is also configured to carry out setting the synchronization transmitting period start time of device Al 1851 to the determined synchronization transmitting period start time of the radio communication terminal device, e.g. device A4 1854 of the first plurality. In one embodiment, the radio communication terminal device Al 1851 is also configured to carry out generating a synchronization message including information about the determined synchronization transmitting period start time. In one embodiment, the synchronization message includes an Application Specific Information Element being encoded in accordance with a second communication protocol format which can be decoded by a radio communication terminal device A5 1855 of the second plurality.

[00269] In one embodiment, the radio communication terminal device, e.g. device Al 1851, of the second plurality of radio communication terminal devices is configured to carry out: determining the clock period of the radio communication terminal device, device A4 1854, of the first plurality.

[00270] In one embodiment, the radio communication terminal device, e.g. device Al 1851, of the second plurality of radio communication terminal devices is configured to carry out: setting the virtual clock which may be a register of the radio communication terminal device, e.g. device Al 1851, of the second plurality to the clock of the radio communication terminal device, e.g. device A4 1854, of the first plurality. [00271] In one embodiment, the synchronization message includes information about the determined clock period of the radio communication terminal device of the first plurality.

[00272] In one embodiment, the first plurality of radio communication terminal devices is of a first type, and the second plurality of radio communication terminal devices is of a second type. In one embodiment, the first type of radio communication terminal devices is configured to provide only slotted time/frequency portion communication without slotted offset time/frequency portion communication, and the second type of radio communication terminal devices is configured to provide slotted time/frequency portion communication and slotted offset time/frequency portion communication.

[00273] hi one embodiment, the synchronization message includes an Application

[00274] hi one embodiment, the radio communication terminal device Al 1851 is also configured to transmit the synchronization message to at least one other radio communication terminal device, e.g. device A5 1855 of the second plurality.

[00275] hi one embodiment, the first plurality of radio communication terminal devices are members of a first ad hoc radio communication terminal devices group, hi one embodiment, the second plurality of radio communication terminal devices are members of a second ad hoc radio communication terminal devices group.

[00276] hi one embodiment, the ad hoc radio communication terminal devices groups may be or include ad hoc radio communication terminal devices beacon groups.

[00277] hi one embodiment, the synchronization transmitting period start time may include at least one of a Beacon Period Start Time and a Beacon Period Start Time offset.

[00278] hi one embodiment, the time/frequency portions may include time/frequency codes.

[00279] hi one embodiment, the at least one other radio communication terminal device, e.g. device A5 1855 is configured to carry out receiving the synchronization message, hi one embodiment, the at least one other radio communication terminal device, e.g. device A5 1855 is configured to set the synchronization transmitting period start time of the at least one other radio communication terminal device to the inferred synchronization transmitting period start time .

[00280] In one embodiment, the at least one other radio communication terminal device, e.g. device A5 1855, of the second plurality is configured to carry out: setting the virtual clock which is a register of the at least one other radio communication terminal device, e.g device A5 1855 of the second plurality to the inferred clock of the radio communication terminal device, e.g. device A4 1854, of the first plurality. [00281] 6.2 BP Alignment

[00282] Synchronization problems may cause the beacon of a fast device to appear to be an alien beacon. A device may consider a BPST to be aligned with its own if that BPST differs from its own by less than a predetermined period length of time, e.g. mGuardTime (12 ns). A device may consider an alien BP to overlap its own if its BPST falls within the alien BP or if the alien BPST falls within its own BP. If a device does not receive an alien beacon for up to mMaxLostBeacons superframes after receiving one in a previous superframe, the device may use information contained in the most recently received beacon as if the alien beacon were received at the same offset within the current superframe. The value of mMaxLostBeacons may be 3, for example, hi one embodiment, if a device that is able to operate in slotted offset TFCs encounters an alien device that is from the same vendor and capable of operating in slotted offset TFCs (e.g. inferred from ASIE as shown in FIG. 8 and the Application Specific Control field as shown in FIG. 7) and if that alien device had not moved its BPST for four (or a fixed value greater than four) superframes, the device may take steps concerning BP alignment which will be described as follows. If the device that is capable of operating in slotted offset TFCs encounters an alien device which is a ECMA [1] specified device or a device that has not kept its BPST unmoved for previous four superframes, the device may follow the BP alignment rules given in ECMA [1] specification. [00283] 6.2.1 Overlapping BPs

[00284] In one embodiment, if the BPST of a device falls within an alien BP, or an alien BPST falls within a device's BP, the device does the following: 1. The device determines if it is faster than the alien device by using the neighbour's clock period estimation procedure given in section 6.3.1.1. The device may treat the alien device as a neighbour for the purpose of using the neighbour's clock period estimation procedure given in section 6.3.1.1 for estimating the clock period of the alien device. If the device is faster than the alien device, a. the device synchronizes with the alien device using the synchronization algorithm given in section 6.3.1.2 by relocating its beacon, relocating its BPST to the alien BPST, and setting up its virtual clock, within the next 2 x mBPMergeWaitTime superframes subject to rule l(b) given below. The device may treat the alien device as the slowest neighbour for the purpose of using the procedure given in section 6.3.1.2 to synchronize with the alien device. In this context, the mBPMergeWaitTime may be 32 superframes. b. the device does not relocate to the alien BP if a beacon received in that alien

BP includes an Enhanced BP Switch IE. If the device is slower than the alien device, the device does not relocate its beacon.

2. If the device moved its BPST, the device adjusts its beacon slot number such that its new beacon slot number is its old beacon slot number plus one, plus the number of the highest occupied beacon slot indicated in any beacon received in the alien BP, minus mSignalSlotCount. In this context, the mSignalSlotCount may represent two beacon slots. Alternatively, it may follow normal BP join rules as specified in ECMA [1] specification to relocate its beacon to the alien BP.

3. The device does not send further beacons in its previous BP.

4. After changing its BPST, if the device is required to send a beacon in a signalling slot, the device waits for a random number of superframes before sending the beacon in the signalling slot. The device chooses the random number with equal probability in the range zero to the BP Length declared in its last beacon before relocating to the alien BP. [00285] 6.2.2 Non-overlapping BPs

[00286] If a device detects an alien BP that does not overlap in time with its own BP, it may merge BPs according to the following rules according to one embodiment.

1. The device includes in its beacon a DRP IE (see, for example, FIG. 13) with Reservation Type set to Alien BP for the alien BP. Since the MAS boundaries may not be aligned, the device may need to include an additional MAS in the reservation to completely cover the alien BP. If the device received multiple beacons from the alien BP, it may include all MASs used by the largest reported BP length in the reservation. If the MASs occupied by the alien BP change over time, the device may update the DRP IE accordingly.

2. The device may determine if it is faster than the alien device by using the neighbour's clock period estimation procedure given in section 6.3.1.1. The device may treat the alien device as a neighbour for the purpose of using the neighbour's clock period estimation procedure given in section 6.3.1.1 for estimating the clock period of the alien device. If the device is faster than the alien device, a) the device synchronizes with the alien device using the synchronization algorithm given in section 6.3.1.2 by relocating its beacon, relocating its BPST to the alien BPST, and setting up its virtual clock, within the next 2 x mBPMergeWaitTime superframes subject to rule 2(b) given below. The device may treat the alien device as the slowest neighbour for the purpose of using the procedure given in section 6.3.1.2 to synchronize with the alien device. b) the device does not relocate to the alien BP if a beacon received in that alien BP includes an Enhanced BP Switch IE.

If the device is slower than the alien device, the device does not relocate it's beacon. [00287] A device that transmits or receives a beacon in its own BP that contains a DRP IE with Reservation Type set to Alien BP shall observe the following rules:

1. The device should not change beacon slots, unless a collision is detected.

2. The device shall listen for beacons during the MASs indicated in the reservation. [00288] 6.2.3 Beacon relocation

[00289] If a device starts or has started the beacon relocation process and receives an alien beacon, it may follow the following rules according to one embodiment:

[00290] If the device did not include an Enhanced BP Switch IE in its last beacon and did not receive a beacon from its neighbour with Enhanced BP Switch IE included, it may include an Enhanced BP Switch IE in its beacon in the following superframe with the fields set as follows:

Al. The device may set the BP Move Countdown field 2403 (see FIG. 24) to a value equal to mBPMergeWaitTime.

A2. The device may set the BPST Offset field 2404 (see FIG. 24) to the positive difference in nanoseconds between the alien BPST and the device's BPST. That is, the field contains the number of nanoseconds that the device needs to delay its own BPST to align with the alien BPST. If multiple alien beacons are received, the device may set the

BPST Offset field to the largest calculated value. A3. The device may set the Clock Period Offset field 2405 (see FIG. 24) to the positive difference in units of 0.01 femtoseconds, the clock period of the alien device and the clock period of the slowest device in the device's beacon group that the device's virtual clock is synchronized to differ by. A4. The device may set the Beacon Slot Offset field 2405 (see FIG. 24) to: a. One plus the number of the highest occupied beacon slot indicated by any beacon received in the alien BP, based on the Beacon Slot Number field and Beacon Period Occupancy IE (BPOIE), plus its old beacon slot number minus mSignalSlotCount; or b. Zero to indicate the device will join the alien BP using normal join rules as specified in ECMA specification.

[00291] If the device included an Enhanced BP Switch IE in its last beacon and it did not receive a beacon from its neighbour with Enhanced BP Switch IE included, it may modify the Enhanced BP Switch IE in the following superframe as follows:

The device may set the BPST Offset field as described in A2. The device may set the

Clock Period Offset field 2405 (see FIG. 24) as described in A3. The device may set the

Beacon Slot Offset field as described in A4 if the value in the field would be increased, or leave it unchanged otherwise. The device may set the BP Move Countdown field 2403

(see FIG. 24) to one less than the value used in its last beacon.

[00292] If a device receives a neighbour's beacon that contains an Enhanced BP

Switch IE, the device may follow the following rules according to one embodiment:

[00293] If the device did not include an Enhanced BP Switch IE in its last beacon, the device may include an Enhanced BP Switch IE in its beacon in the following superframe with the fields set as follows:

Cl. The device may set the BP Move Countdown field 2403 to the BP Move Countdown field of the neighbour's Enhanced BP Switch IE.

C2. The device may set the BPST Offset field 2406 to the value of the same field contained in the neighbour's beacon.

C3. The device may set the Clock Period Offset field 2405 to the value of the same field contained in the neighbour's beacon.

C4. The device may set the Beacon Slot Offset field 2404 to: a. The larger of: one plus the number of the highest occupied beacon slot indicated by any alien beacon received in the alien BP identified by the neighbour's BP Switch IE, based on the Beacon Slot Number field and BPOIE, plus its old beacon slot number, minus mSignalSlotCount; or the Beacon Slot Offset field contained in the neighbour's beacon; or b. Zero, to indicate the device will join the alien BP using normal join rules. [00294] If the device included an Enhanced BP Switch IE in its last beacon, it may modify the BP Switch IE as follows: a. If the Clock Period Offset field 2405 contained in the neighbour's beacon is larger than the device's Clock Period Offset field, the device may set the BP Move Countdown field 2403, the BPST Offset field 2406, Clock Period Offset field 2405, and the Beacon Slot Offset field 2404 as described in Cl, C2, C3, and C4 above respectively. b. If the Clock Period Offset field 2405 contained in the neighbour's beacon is smaller than or equal to the device's Clock Period Offset field, the device may set the BP Move Countdown field to one less than the value used in its last beacon, and leave its BPST Offset field, Clock Period Offset field, and the Beacon Slot Offset field unchanged from the beacon in the previous superframe.

[00295] If a device includes an Enhanced BP Switch IE in its beacon, it may continue to do so until it completes or halts the relocation process according to one embodiment. [00296] In one embodiment, if a device receives an alien beacon that indicates relocation earlier than its planned relocation, the device may halt the relocation process. [00297] In one embodiment, if a neighbour halts the relocation process, the device may halt the relocation process.

[00298] To halt the relocation process, in one embodiment, a device may include an Enhanced BP Switch IE 2400 (see FIG. 24) in its beacon with BPST Offset field 2406 set to 65 535, Clock Period Offset field 2405 set to zero, Beacon Slot Offset field 2404 set to zero, and BP Move Countdown field 2403 set to mBPMergeWaitTime. In following superframes, the device may follow the rules above.

[00299] In one embodiment, at the end of the superframe in which a device includes an Enhanced BP Switch IE 2400 with a BP Move Countdown field 2403 equal to zero, the device may adjust its BPST based on its BPST Offset field. The device may set its virtual clock count to zero at the new BPST. The device may update its virtual clock by following the procedure given in section 6.3.1.2 so as to synchronize its virtual clock to a clock whose period is the Clock Period Offset field plus the clock period of its previous slowest neighbour in the old BP in the superframe preceding the adjustment of its BPST. For the purpose of maintaining virtual clock count after adjusting its BPST and before performing any neighbour's clock period estimation procedure as given in section 6.3.1.1, the device may consider that its slowest neighbour in the new BP has a clock with clock period of value Clock Period Offset field plus the clock period of the device's previous slowest neighbour in the old BP in the superframe preceding the adjustment of its BPST. In one embodiment, the device may transmit a beacon in that superframe, or delay one superframe to begin beacon transmission in its new BP. After relocating its beacon to the alien BP, the device may include neither the Enhanced BP Switch IE nor the alien BP DRP IE in its beacon. If the Beacon Slot Offset field 2404 was non-zero, the device may transmit a beacon in the beacon slot with number equal to its prior beacon slot number plus the value from the Beacon Slot Offset field. If this beacon slot number is greater than or equal to mMaxBPLength, the device may follow the normal BP join rules as described in ECMA [1] specification to relocate its beacon to the alien BP. In this context, mMaxBPLength is as desribed in [I]. [00300] 6.3 Synchronization of Devices

[00301] In the following, methods disclosed in reference [3] as to how an ad hoc radio communication terminal device synchronizes with another ad hoc radio communication terminal device are summarized; these methods may be implemented in various embodiments.

[00302] Each device may maintain a Beacon Period Start Time (BPST). Each device may also maintain a virtual clock (which may be a register).

[00303] Each device may maintain superframe synchronization with its slowest neighbour. In this context, the slowest neighbour may refer to the device which has its physical clock signal behind the physical clock signals of all the other devices of the beacon group. In other words, for example, the physical clock period of the slowest neighbour may be longer than the physical clock periods of all the other devices of the beacon group. The procedure by which a device maintains its virtual clock to stay synchronized to its slowest neighbour is described subsequently in section 6.3.1. Each device may derive all times for communication with its neighbours based on the current BPST and the virtual clock. Before a device is synchronized to any other device, the device's virtual clock may be set by default to be the device's physical clock. Each device may store or save the history of at least the latest mMaxLostBeacons consecutive BPSTs of every neighbour in the latest mMaxLostBeacons superframes including the current superframe.

[00304] When a device receives a beacon from a neighbour, the device may determine the difference between the beacon's actual reception time and the expected reception time. The beacon's actual reception time is an estimate of the time that the start of the beacon preamble arrived at the device's antenna. The expected reception time is determined from the Beacon Slot Number field of the received beacon and the device's BPST. Two devices are said to be synchronized to each other if their virtual clocks are synchronized up to a clock period as given in section 6.3.1.2 (though their physical clocks may drift) and their BPSTs are aligned to each other within mGuardTime). [00305] In one embodiment, in a current superframe, if a device that is able to operate in slotted offset TFCs has a slower neighbour (inferred from a history of the neighbour's BPST values) and if that slower neighbour device had not moved its BPST for previous six (or a fixed value greater than six) superframes, the device shall follow the following rules concerning synchronization. Else, the device shall follow the synchronization algorithm as given in ECMA [ 1 ] specification in the next superframe. [00306] 6.3.1 Synchronization procedure

[00307] A device that starts the procedure of synchronization may estimate the clock period of each of its neighbour using the neighbour's clock period estimation procedure given in section 6.3.1.1. The device may determine the slowest neighbour by repeating the neighbour's clock period estimation procedure given in section 6.3.1.1 for each of its neighbours. The device may also synchronize with the slowest neighbour using the procedure given in section 6.3.1.2.

[00308] 6.3.1.1 Neighbour's clock period estimation procedure [00309] Before the device starts the neighbour's clock period estimation procedure to estimate the clock period of a neighbour, the device may have the values of at least latest mMaxLostBeacons consecutive BPSTs of that neighbour in the latest mMaxLostBeacons superframes including the current superframe. If the device has only 'x' consecutive BPSTs of that neighbour in the latest mMaxLostBeacons superframes including the current superframe, where x < mMaxLostBeacons, the device may wait for enough time to receive 'mMaxLostBeacons-x' more BPSTs to start the neighbour's clock period estimation procedure. From the latest three consecutive BPSTs of that neighbour in the latest mMaxLostBeacons superframes including the current superframe, the device may determine if that neighbour had moved its BPST in the latest two superframes including the current superframe. The neighbour is inferred to have moved its BPST in the latest two superframes including the current superframe if the time elapsed between the neighbour's BPST in the previous superframe and the neighbour's BPST in the current superframe is different from the time elapsed between the neighbour's BPST in the superframe preceding the previous superframe and the neighbour's BPST in the previous superframe. The device may start the neighbour's clock period estimation procedure only if the neighbour and the device had not moved their respective BPSTs in each of the latest two superframes including the current superframe. If it is inferred that either the device or the neighbour had moved it's BPST in the latest two superframes, the device may wait for at least two more superframes to start the neighbour's clock period estimation procedure.

[00310] If the device starts the neighbour's clock period estimation procedure in the current superframe, it may do the following.

[00311] For example, assume that devices A l I l and D 114 (as shown in FIG. 1) have entered or joined a same beacon group. Let P_cllc be the physical (hardware) clock (current ECMA [1] PHY clock is 528 MHz). As shown in Fig. 26, let B_A 2601 be the BPST of device A 111, B_D 2602 be the BPST of device D 114 from A 11 l's perspective, C_A 2603 be the clock period of A 111 (Assume A I l l's clock period to be 1/P_ci_k; assume A I l l's clock to be of 528 MHz (pClockFrequency), and hence A I l l 's clock period (pClockPeriod) is 1/528 microseconds), and C_D be the clock period of D 114 from A Il l's perspective. Let the beacon slot of D 114 as seen by A 111 be rii, a known quantity. Let m = T_bp x P_clk be the number of clock cycles for a beacon slot duration

(pNumberofClockCyclesperBeaconSlot), where T_bp is the time duration of each beacon slot. For current ECMA [1] specified devices, T_bp=85 μs and P_clk =528 MHz. Hence m =

85 x 528. In every beacon slot as seen by a device, the same device's physical clock counts m cycles. Let 72610 be the actual reception time of the beacon of D 114 at A 111 (discounting propagation time), Z 2611 be the estimated reception time of D 114's beacon at A 111.

[00312] Assume that no device moves its BPST at the end of the current (first) superframe (superframe N 2620). In the next superframe (superframe N+l 2621), the devices A 111 and D 114 do not move their BPSTs. Let F2612 and T 2613 be respectively the actual and estimated reception times of D 114's beacon at A 111 in superframe N+l 2621. Let n₂ be the Beacon Slot Number of beacon of D 114 in superframe N+l 2621. Let p = T_sf x. P_clk be the number of clock cycles for a superframe duration (pNumberofClockCyclesperSuperframe), where T_sf is the time duration of one superframe. For current ECMA [1] specified devices, T_sf = 65536 μs, hence p= 65536 x

528. In every superframe, the same device's physical clock counts p cycles. Note that P_clk can be selected differently depending on individual implementations. For example,

P_clk may also be selected based on 66 MHz clock. In such a case, A I l l 's clock period is 1/66 microseconds, and m = 85 x 66 and/? = 65536 x 66. In one embodiment, P_clk may be selected to be based on the frequency F Hz of the physical clock crystal used by the device A l I l. Accordingly, the clock period of device A 111 is 1/F seconds.

[00313] Now, 72610, Z 2611, T 2612, and T 2613 are known at device A l I l with respect to a fixed reference time (could be the BPST of A 111, B_A 2601). From the following four relations,

Z = B_A + {n_γ - \)C_Am (1)

Y = B_D + {n_x - \)C_Dm (2)

Z'= B_A + pC_A + (M₂ - I)C _Am (3) r= B_D +pC_D +(n₂ -\)C_Dm (4) where m = T_bp x P_clk =85x528, p = T_sf x P_clk= 65536x528 the estimates of B_D and C_D in two superframes can be obtained: C_x, = (r-y)/Q> + m(^#! ₂ - ^/!,)) (5)

B₀ = Y- (H₁ - \)C_Dm = Y- (n_x - \){T-Y)ml(p + m(n₂ - n_λ)) (6) [00314] If C_D < C_A, then the device A 1 11 is slower than the neighbour device D 114. If CD > C_A, then the neighbour device D 114 is slower than the device A l I l. [00315] In this example, assume that device A 111 is faster than device D 114. In the third superframe, the device A l I l may align its BPST to device D 1 14's BPST (which it knows through the knowledge of BD + 2pCo and the fixed reference time) and reset its virtual clock count to zero. The device A l I l may maintain a resolution of at least eight decimal places (rounded to the eighth decimal in fraction) in estimating the clock period in nano seconds. The device A l I l may maintain a resolution to at least one nano second when estimating the BPST of the neighbor. [00316] 6.3.1.2 Synchronization with the slowest neighbour

[00317] If the device A 111 has estimates of the clock period and BPST of the slowest neighbour device D 114 in the current superframe using the procedure given in section 6.3.1.1, the device A l I l may align its BPST to the slowest neighbour D 114's BPST and reset A 111' virtual clock count to zero at the slowest neighbour D 114's BPST in the next superframe. The adjustment of BPST may occur at any time after the estimation of slowest neighbour's clock in the current superframe, but may to be done before the end of the current superframe. The device may also follow the following rules. [00318] Let P_A be the number of physical clock cycles of A 111 during the superframe duration of D 114 (known to A 111), and P_D be the number of physical clock cycles of D 114 in that same superframe duration of D 114. It can be seen that P_D - P =65536 x528 (pNumberofClockCyclesperSuperframe). If the device A 211 maintains a count of virtual clock cycles from the third superframe in such a way that its count of virtual clock cycles is obtained from the count of its physical clock cycles by subtracting one clock cycle from the count of its physical clock cycles every floor [P_A /(P_A - P_D)] or Round [P_A /(P_A - P_D)] of its physical clock cycles, the virtual clock of A 211 will be synchronized to the physical clock of D 214 to one clock period level. In one embodiment, the virtual clock may specify a time offset between the virtual clock and the physical clock. The clock cycles counted by the virtual clock may correspond to or have a relation to the number of clock cycles counted by the physical clock. For example, the virtual clock may skip one clock cycle every floor [P_A /(PA - PD)] or Round [P_A /(P_A-

Po)]physical clock cycles.

[00319] In the above, the function floor [x] denotes the largest integer value not greater than the value 'x', and Round [x] denotes the nearest integer value to 'x'.

[00320] IfP_A - P_D =0, then the virtual clock is set to be the same as the physical clock.

As seen above, only the first two superframes are needed for estimating clock periods and establishing the virtual clocks.

[00321] Two examples are given to illustrate the above proposed schemes.

[00322] Example 1

[00323] Given

and P_clk =528 MHz, C_A=l/528 μs, Y is measured as

342.595 μs and T is measured as 65882.595 μs, then using equation (5), C_D can be estimated as 1.89405 ns and using equation (6), B_D can be estimated as 2.5752 μs. In the superframe duration of D 214 (= pC_D), A 21 l's clock counts, /?Ci/C~34605028 cycles. However, D 214's clock still counts /? = 65536x528 = 34603008 cycles. A 21 l's virtual clock is got from subtracting 1 clock cycle from every 17131 (which is =34605028/(34605028-34603008)) physical clock cycles of A 211. [00324] Example 2 [00325] Given H₁=H₂=H=S and P_clk =66 MHz, C_A=l/66 μs, 7 is measured as 342.595 μs and Y' is measured as 65882.595 μs, then using equation (5), C_D can be estimated as 15.152 ns and using equation (6), B_D can be estimated as 2.584 μs. In the superframe duration of D 1 \4(=pC_D), A 211 's clock counts, pC_f)/C_A~ 4325514 cycles. However, D 214's clock still counts p = 65536 x 66 = 4325376 cycles. A 21 l's virtual clock is got from subtracting 1 clock cycle from every 31344 (which is ~ 4325514/(4325514- 4325376)) physical clock cycles of A.

[00326] FIG. 27 illustrates a table of the possible values of the parameters of pClockFrequency, pClockPeriod, pNumberofClockCyclesperSuperframe, and pNumberofClockCyclesperBeaconSlot.

[00327] It should be noted that the various embodiments are not limited to the ECMA communication standards but can e.g. be applied to any mobile radio communication technology providing a fixed (e.g. predefined) frequency hopping pattern and may thus e.g. allow TFC slotted offset communication. Various embodiments may e.g. be applied to the CWPAN communication standard.

[00328] While the invention has been particularly shown and described with reference to specific embodiments, it should be understood by those skilled in the art that various changes in form and detail may be made therein without departing from the spirit and scope of the invention as defined by the appended claims. The scope of the invention is thus indicated by the appended claims and all changes which come within the meaning and range of equivalency of the claims are therefore intended to be embraced.

[00329] hi this document, the following documents are cited:

[1] Standard ECMA-368, High Rate Ultra Wideband PHY and MAC Standard, Dec.

2007

[2] WO 2009/038545 Al

[3] WO 2009/054812 Al

[4] WO 2009/088364 Al

[5] WO 2008/123834 Al

Claims

ClaimsWhat is claimed is:

1. A method for requesting radio resources in a radio communication system, the method comprising: generating and encoding a first request message for radio resources including a plurality of slotted time/frequency portions, wherein the first request message includes an Information Element being encoded in accordance with a first communication protocol format which can be decoded by a radio communication terminal device of a first type being configured to provide only slotted time/frequency portion communication without slotted offset time/frequency portion communication and by a radio communication terminal device of a second type being configured to provide slotted time/frequency portion communication and slotted offset time/frequency portion communication; in case the radio resources requested by the first request message are not available, generating and encoding a second request message for radio resources including a plurality of slotted offset time/frequency portions, wherein the second request message includes an Application Specific Information Element being encoded in accordance with a second communication protocol format which can be decoded by a radio communication terminal device of the second type.

2. The method as claimed in claim 1, wherein the radio communication system is an ad hoc radio communication system, and the radio communication terminal device of the first type and the radio communication terminal device of the second type are ad hoc radio communication terminal devices.

3. The method as claimed in claim 1, wherein the time/frequency portions comprise time/frequency codes.

4. The method as claimed in claim 1, wherein the first request message includes an Information Element requesting a Medium Access Slot comprising a plurality of slotted time/frequency portions as a default slotted offset time/frequency portion.

5. The method as claimed in claim 2, being carried out by an ad hoc radio communication terminal device.

6. The method as claimed in claim 5, further comprising: transmitting the first request message to another ad hoc radio communication terminal device which is in the same ad hoc radio communication group as the ad hoc radio communication terminal device.

7. The method as claimed in claim 6, wherein the ad hoc radio communication group is an ad hoc radio communication beacon group.

8. The method as claimed in claim 1, further comprising: in case the radio resources requested by the first request message are available, reserving the requested radio resources.

9. The method as claimed in claim 1, further comprising: in case the radio resources requested by the first request message are not available, generating, encoding and transmitting a resource reservation message to another radio communication terminal device which is in the same radio communication group as the radio communication terminal device.

10. The method as claimed in claim 9, wherein the resource reservation message includes an Application Specific Information Element being encoded in accordance with the second communication protocol format.

11. A method for determining available radio resources in a radio communication system, the method comprising: determining as to whether required radio resources including a plurality of slotted offset time/frequency portions are available; in case the required radio resources are not available, determining as to whether required radio resources including a different plurality of slotted offset time/frequency portions are available using a request message for the radio resources, wherein the request message includes an Application Specific Information Element being encoded in accordance with a communication protocol format which can be decoded by a radio communication terminal device of a type being configured to provide slotted time/frequency portion communication and slotted offset time/frequency portion communication.

12. The method as claimed in claim 11, wherein the radio communication system is an ad hoc radio communication system, and the radio communication terminal device of the type being configured to provide slotted time/frequency portion communication and slotted offset time/frequency portion communication is an ad hoc radio communication terminal device.

13. The method as claimed in claim 11, wherein the determining as to whether required radio resources are available comprises determining as to whether required radio resources are available using a request message for the radio resources, wherein the request message comprises an Information Element being encoded in accordance with a communication protocol format which can be decoded by a radio communication terminal device of a type being configured to provide only slotted time/frequency portion communication without slotted offset time/frequency portion communication.

14. The method as claimed in claim 13, wherein the radio communication terminal device of the type being configured to provide only slotted time/frequency portion communication without slotted offset time/frequency portion communication is an ad hoc radio communication terminal device.

15. The method as claimed in claim 11, wherein the time/frequency portions comprise time/frequency codes.

16. The method as claimed in claim 11, wherein the request message includes an Application Specific Information Element requesting a Medium Access Slot comprising a plurality of slotted offset time/frequency portions.

17. The method as claimed in claim 12, being carried out by an ad hoc radio communication terminal device.

18. The method as claimed in claim 17, further comprising: transmitting the request message to another ad hoc radio communication terminal device which is in the same ad hoc radio communication group as the ad hoc radio communication terminal device.

19. The method as claimed in claim 18, wherein the ad hoc radio communication group is an ad hoc radio communication beacon group.

20. The method as claimed in claim 13, further comprising: in case the radio resources requested by the request message are available, reserving the required radio resources.

21. The method as claimed in claim 17, further comprising: in case the required radio resources are not available, generating, encoding and transmitting a resource reservation message to another ad hoc radio communication terminal device which is in the same ad hoc radio communication group as the ad hoc radio communication terminal device.

22. The method as claimed in claim 21 , wherein the resource reservation message includes an Application Specific Information Element being encoded in accordance with the second communication protocol format.

23. A radio communication terminal device for requesting radio resources in a radio communication system, the radio communication terminal device comprising: a first generator and a first encoder being configured to generate and encode a first request message for radio resources including a plurality of slotted time/frequency portions, wherein the first request message includes an Information Element being encoded in accordance with a first communication protocol format which can be decoded by a radio communication terminal device of a first type being configured to provide only slotted time/frequency portion communication without slotted offset time/frequency portion communication and by a radio communication terminal device of a second type being configured to provide slotted time/frequency portion communication and slotted offset time/frequency portion communication; a second generator and a second encoder being configured to, in case the radio resources requested by the first request message are not available, generate and encode a second request message for radio resources including a plurality of slotted offset time/frequency portions, wherein the second request message includes an Application Specific Information Element being encoded in accordance with a second communication protocol format which can be decoded by a radio communication terminal device of the second type.

24. The radio communication terminal device as claimed in claim 23 being an ad hoc radio communication terminal device for requesting radio resources in an ad hoc radio communication system, wherein the radio communication device of the first type and the radio communication device of the second type are ad hoc radio communication terminal devices.

25. The radio communication terminal device as claimed in claim 23, wherein the time/frequency portions comprise time/frequency codes.

26. The radio communication terminal device as claimed in claim 23, wherein the first request message includes an Information Element requesting a Medium Access Slot comprising a plurality of slotted time/frequency portions as a default slotted offset time/frequency portion.

27. The radio communication terminal device as claimed in claim 24, further comprising: a transmitter being configured to transmit the first request message to another ad hoc radio communication terminal device which is in the same ad hoc radio communication group as the ad hoc radio communication terminal device.

28. The radio communication terminal device as claimed in claim 27, wherein the ad hoc radio communication group is an ad hoc radio communication beacon group.

29. The radio communication terminal device as claimed in claim 23, further comprising: a reserving circuit being configured to, in case the radio resources requested by the first request message are available, reserve the requested radio resources.

30. The radio communication terminal device as claimed in claim 27, further comprising: a third generator, a third encoder, and a second transmitter being configured to, in case the radio resources requested' by the first request message are not available, generate, encode and transmit a resource reservation message to another ad hoc radio communication terminal device which is in the same ad hoc radio communication group as the ad hoc radio communication terminal device.

31. The radio communication terminal device as claimed in claim 30, wherein the resource reservation message includes an Application Specific Information Element being encoded in accordance with the second communication protocol format.

32. A radio communication terminal device for determining available radio resources in a radio communication system, the radio communication terminal device comprising: a first determining circuit being configured to determine as to whether required radio resources including a plurality of slotted offset time/frequency portions are available; a second determining circuit being configured to, in case the required radio resources are not available, determine as to whether required radio resources including a different plurality of slotted offset time/frequency portions are available using a request message for the radio resources, wherein the request message includes an Application Specific Information Element being encoded in accordance with a communication protocol format which can be decoded by a radio communication terminal device of a type being configured to provide slotted time/frequency portion communication and slotted offset time/frequency portion communication.

33. The radio communication terminal device as claimed in claim 32 being an ad hoc radio communication terminal device for determining available radio resources in an ad hoc radio communication system, wherein the radio communication terminal device of the type being configured to provide slotted time/frequency portion communication and slotted offset time/frequency portion communication is an ad hoc radio communication terminal device.

34. The radio communication terminal device as claimed in claim 32, wherein the first determining circuit is configured to determine as to whether required radio resources are available using a request message for the radio resources, wherein the request message comprises an Information Element being encoded in accordance with a communication protocol format which can be decoded by a radio communication terminal device of a type being configured to provide only slotted time/frequency portion communication without slotted offset time/frequency portion communication.

35. The radio communication terminal device as claimed in claim 34, wherein the radio communication terminal device of the type being configured to provide only slotted time/frequency portion communication without slotted offset time/frequency portion communication is an ad hoc radio communication terminal device.

36. The radio communication terminal device as claimed in claim 32, wherein the time/frequency portions comprise time/frequency codes.

37. The radio communication terminal device as claimed in claim 33, wherein the request message includes an Application Specific Information Element requesting a Medium Access Slot comprising a plurality of slotted offset time/frequency portions.

38. The radio communication terminal device as claimed in claim 37, further comprising: a first transmitter being configured to transmit the request message to another ad hoc radio communication terminal device which is in the same ad hoc radio communication group as the ad hoc radio communication terminal device.

39. The radio communication terminal device as claimed in claim 38, wherein the ad hoc radio communication group is an ad hoc radio communication beacon group.

40. The radio communication terminal device as claimed in claim 32, further comprising: a reserving circuit being configured to, in case the radio resources requested by the first request message are available, reserving the required radio resources.

41. The radio communication terminal device as claimed in claim 38, further comprising: a generator, an encoder, and a second transmitter being configured to, in case the required radio resources are not available, generating, encoding and transmitting a resource reservation message to another ad hoc radio communication terminal device which is in the same ad hoc radio communication group as the ad hoc radio communication terminal device.

42. The radio communication terminal device as claimed in claim 41, wherein the resource reservation message includes an Application Specific Information Element being encoded in accordance with the second communication protocol format.

43. A method for synchronizing at least a first radio communication terminal device with a second radio communication terminal device in a radio communication system, the method comprising: determining as to whether the second radio communication terminal device has not changed its synchronization transmitting period start time for a predetermined time; determining the synchronization transmitting period start time of the second radio communication terminal device; in case the second radio communication terminal device has not changed its synchronization transmitting period start time for a predetermined time, setting the synchronization transmitting period start time of the first radio communication terminal device to the synchronization transmitting period start time of the second radio communication terminal device.

44. The method as claimed in claim 43, wherein the first radio communication terminal device and the second radio communication terminal device are ad hoc radio communication terminal devices in an ad hoc radio communication system.

45. The method as claimed in claim 43, further comprising: determining the clock period of the second radio communication terminal device.

46. The method as claimed in claim 43, further comprising: in case the second radio communication terminal device has not changed its synchronization transmitting period start time for a predetermined time, setting a virtual clock which is a register of the first radio communication terminal device to the clock of the second radio communication terminal device.

47. The method as claimed in claim 43, wherein the synchronization transmitting period start time is a Beacon Period Start Time.

48. The method as claimed in claim 43, wherein the second radio communication terminal device is of a first type of radio communication terminal device configured to provide only slotted time/frequency portion communication without slotted offset time/frequency portion communication.

49. The method as claimed in claim 43, wherein the first radio communication terminal device is of a second type of radio communication terminal device configured to provide slotted time/frequency portion communication and slotted offset time/frequency portion communication.

50. The method as claimed in claim 48 or 49, wherein the time/frequency portions comprise time/frequency codes.

51. The method as claimed in claim 43, wherein determining as to whether the second radio communication terminal device has not changed its synchronization transmitting period start time for a predetermined time comprises determining as to whether the second radio communication terminal device has not changed its synchronization transmitting period start time for a predetermined number of at least one of frames and superframes.

52. The method as claimed in claim 43, being carried out by an ad hoc radio communication terminal device.

53. The method as claimed in claim 43, further comprising: determining as to whether the synchronization transmitting period start time of the first radio communication terminal device has been set to the synchronization transmitting period start time of the second radio communication terminal device; in case the synchronization transmitting period start time of the first radio communication terminal device has been set to the synchronization transmitting period start time of the second radio communication terminal device, setting the synchronization transmitting period start time of a third radio communication terminal device to the synchronization transmitting period start time of the first radio communication terminal device.

54. The method as claimed in claim 53, wherein the third radio communication terminal device is of the same type of radio communication terminal device as the first radio communication terminal device.

55. A first radio communication terminal device for synchronizing with a second radio communication terminal device in a radio communication system, the first radio communication terminal device comprising: a first determining circuit being configured to determine as to whether the second radio communication terminal device has not changed its synchronization transmitting period start time for a predetermined time; a second determining circuit being configured to determine the synchronization transmitting period start time of the second radio communication terminal device; a synchronization circuit being configured to, in case the second radio communication terminal device has not changed its synchronization transmitting period start time for a predetermined time, set the synchronization transmitting period start time of the first radio communication terminal device to the synchronization transmitting period start time of the second radio communication terminal device.

56. The first radio communication terminal device as claimed in claim 55 being an ad hoc radio communication terminal device, wherein the second radio communication terminal device is an ad hoc radio communication terminal device and the radio communication system is an ad hoc radio communication system.

57. The first radio communication terminal device as claimed in claim 55, wherein the second determining circuit is further configured to determine the clock period of the second radio communication terminal device.

58. The first radio communication terminal device as claimed in claim 56, wherein the synchronization circuit is further configured to, in case the second radio communication terminal device has not changed its synchronization transmitting period start time for a predetermined time, set a virtual clock which is a register of the first radio communication terminal device to the clock of the second radio communication terminal device.

59. The first radio communication terminal device as claimed in claim 55, wherein the synchronization transmitting period start time is a Beacon Period Start Time.

60. The first radio communication terminal device as claimed in claim 55, wherein the second radio communication terminal device is of a first type of radio communication terminal device configured to provide only slotted time/frequency portion communication without slotted offset time/frequency portion communication.

61. The first radio communication terminal device as claimed in claim 55, wherein the first radio communication terminal device is of a second type of radio communication terminal device configured to provide slotted time/frequency portion communication and slotted offset time/frequency portion communication.

62. The first radio communication terminal device as claimed in claim 60 or 61, wherein the time/frequency portions comprise time/frequency codes.

63. The first radio communication terminal device as claimed in claim 55, wherein determining as to whether the second radio communication terminal device has not changed its synchronization transmitting period start time for a predetermined time by the first determining circuit comprises determining as to whether the second radio communication terminal device has not changed its synchronization transmitting period start time for a predetermined number of at least one of frames and superframes.

64. The first radio communication terminal device as claimed in claim 55, further comprising: a third determining circuit being configured to determine as to whether the synchronization transmitting period start time of the first radio communication terminal device has been set to the synchronization transmitting period start time of the second radio communication terminal device.

65. A radio communication system which comprises at least a first radio communication terminal device and a second radio communication terminal, wherein: the first radio communication terminal device is configured to determine as to whether the second radio communication terminal device has not changed its synchronization transmitting period start time for a predetermined time; the first radio communication terminal device is configured to determine the synchronization transmitting period start time of the second radio communication terminal device; the first radio communication terminal device is configured to, in case the second radio communication terminal device has not changed its synchronization transmitting period start time for a predetermined time, set the synchronization transmitting period start time of the first radio communication terminal device to the synchronization transmitting period start time of the second radio communication terminal device.

66. The radio communication system as claimed in claim 65 being an ad hoc radio communication system, wherein the at least first radio communication terminal device and second radio communication terminal device comprised in the radio communication system are ad hoc radio communication terminal devices.

67. The radio communication system as claimed in claim 65, wherein the first radio communication terminal device is further configured to determine the clock period of the second radio communication terminal device.

68. The radio communication system as claimed in claim 65, wherein the first radio communication terminal device is configured to, in case the second radio communication terminal device has not changed its synchronization transmitting period start time for a predetermined time, set virtual clock which is a register of the first radio communication terminal device to clock of the second radio communication terminal device.

69. The radio communication system as claimed in claim 65, wherein the synchronization transmitting period start time is a Beacon Period Start Time.

70. The radio communication system as claimed in claim 65, wherein the second radio communication terminal device is of a first type of radio communication terminal device configured to provide only slotted time/frequency portion communication without slotted offset time/frequency portion communication.

71. The radio communication system as claimed in claim 65, wherein the first radio communication terminal device is of a second type of radio communication terminal device configured to provide slotted time/frequency portion communication and slotted offset time/frequency portion communication.

72. The radio communication system as claimed in claim 70 or 71, wherein the time/frequency portions comprise time/frequency codes.

73. The radio communication system as claimed in claim 65, wherein determining as to whether the second radio communication terminal device has not changed its synchronization transmitting period start time for a predetermined time by the first radio communication terminal device comprises determining as to whether the second radio communication terminal device has not changed its synchronization transmitting period start time for a predetermined number of at least one of frames and superframes.

74. The radio communication system as claimed in claim 65, further comprising a third radio communication terminal device, wherein the first radio communication terminal device is configured to determine as to whether the synchronization transmitting period start time of the first radio communication terminal device has been set to the synchronization transmitting period start time of the second radio communication terminal device; the third radio communication terminal device is configured to, in case the synchronization transmitting period start time of the first radio communication terminal device has been set to the synchronization transmitting period start time of the second radio communication terminal device, set the synchronization transmitting period start time of the third radio communication terminal device to the synchronization transmitting period start time of the first radio communication terminal device.

75. The radio communication system as claimed in claim 74, wherein the third radio communication terminal device is of the same type of radio communication terminal device as the first radio communication terminal device.

76. The radio communication system as claimed in claim 75, the third radio communication terminal device is configured to, in case the synchronization transmitting period start time of the first radio communication terminal device has been set to the synchronization transmitting period start time of the second radio communication terminal device, set the virtual clock which may be a register of the third radio communication terminal device to the clock of the first radio communication terminal device.

77. A method for synchronizing a first plurality of radio communication terminal devices with a second plurality of radio communication terminal devices in a radio communication system, the method comprising: in a radio communication terminal device of the second plurality, carrying out: determining a synchronization transmitting period start time of a radio communication terminal device of the first plurality; setting the synchronization transmitting period start time of the radio communication terminal device of the second plurality to the determined synchronization transmitting period start time of the radio communication terminal device of the first plurality; and generating a synchronization message including information about the determined synchronization transmitting period start time of the radio communication terminal device of the first plurality.

78. The method as claimed in claim 77, wherein the first plurality of radio communication terminal devices and the second plurality of radio communication terminal devices are ad hoc radio communication terminal devices in an ad hoc radio communication system.

79. The method as claimed in claim 77, further comprising: in the radio communication terminal device of the second plurality, carrying out: determining the clock period of a radio communication terminal device of the first plurality.

80. The method as claimed in claim 77, further comprising: in the radio communication terminal device of the second plurality, carrying out: setting the virtual clock which is a register of the radio communication terminal device of the second plurality to the clock of the radio communication terminal device of the first plurality.

81. The method as claimed in claim 77, further comprising: in the radio communication terminal device of the second plurality, carrying out: generating a synchronization message including information about the determined clock period of the radio communication terminal device of the first plurality.

82. The method as claimed in claim 77, wherein the first plurality of radio communication terminal devices is of a first type, the second plurality of radio communication terminal devices is of a second type, wherein the first type of radio communication terminal devices is configured to provide only slotted time/frequency portion communication without slotted offset time/frequency portion communication, and wherein the second type of radio communication terminal devices is configured to provide slotted time/frequency portion communication and slotted offset time/frequency portion communication.

83. The method as claimed in claim 82, wherein the synchronization message includes an Application Specific Information Element being encoded in accordance with a second communication protocol format which can be decoded by a radio communication terminal device of the second type.

84. The method as claimed in claim 77, further comprising: transmitting the synchronization message to at least one other radio communication terminal device of the second plurality.

85. The method as claimed in claim 77, wherein the first plurality of radio communication terminal devices are members of a first radio communication terminal devices group; and wherein the second plurality of radio communication terminal devices are members of a second radio communication terminal devices group.

86. The method as claimed in claim 85, wherein the radio communication terminal devices groups are ad hoc radio communication terminal devices beacon groups.

87. The method as claimed in claim 77, wherein the synchronization transmitting period start time comprises at least one of a Beacon Period Start Time and a Beacon Period Start Time offset.

88. The method as claimed in claim 82, wherein the time/frequency portions comprise time/frequency codes.

89. The method as claimed in claim 84, further comprising: in the at least one other radio communication terminal device of the second plurality: receiving the synchronization message; setting the synchronization transmitting period start time of the at least one other radio communication terminal device of the second plurality to the inferred synchronization transmitting period start time of the radio communication terminal device of the first plurality.

90. The method as claimed in claim 89, further comprising: in the at least one other radio communication terminal device of the second plurality: setting the virtual clock which is a register of the at least one other radio communication terminal device of the second plurality to the clock of the radio communication terminal device of the first plurality.

91. A first radio communication terminal device of a first plurality of radio communication terminal devices for synchronizing with a second radio communication terminal device of a second plurality of radio communication terminal devices in a radio communication system, the first radio communication terminal device comprising: a determining circuit being configured to determine a synchronization transmitting period start time of the second radio communication terminal device of the second plurality; a synchronization circuit being configured to set the synchronization transmitting period start time of the first radio communication terminal device to the determined synchronization transmitting period start time of the second radio communication terminal device; and a generating circuit being configured to generate a synchronization message including information about the determined synchronization transmitting period start time of the first radio communication terminal device.

92. The first radio communication terminal device as claimed in claim 91, wherein the first plurality and the second plurality of radio communication terminal devices are ad hoc radio communication terminal devices within an ad hoc radio communication system.

93. The first radio communication terminal device as claimed in claim 91, wherein the determining circuit is configured to determine the clock period of the second radio communication terminal device of the second plurality.

94. The first radio communication terminal device as claimed in claim 91, wherein the synchronization circuit is configured to set the virtual clock which is a register of the first radio communication terminal device to the clock of the second radio communication terminal device.

95. The first radio communication terminal device as claimed in claim 91, wherein the synchronization message includes information about the determined clock period of the first radio communication terminal device.

96. The first radio communication terminal device as claimed in claim 91, wherein the first plurality of radio communication terminal devices is of a first type, the second plurality of radio communication terminal devices is of a second type, wherein the first type of radio communication terminal devices is configured to provide slotted time/frequency portion communication and slotted offset time/frequency portion communication, and wherein the second type of radio communication terminal devices is configured to provide only slotted time/frequency portion communication without slotted offset time/frequency portion communication.

97. The first radio communication terminal device as claimed in claim 91, wherein the synchronization message includes an Application Specific Information Element being encoded in accordance with a second communication protocol format which can be decoded by a radio communication terminal device of the second type.

98. The first radio communication terminal device as claimed in claim 91, further comprising: a transmitting circuit being configured to transmit the synchronization message to at least one other radio communication terminal device of the first plurality of radio communication terminal devices.

99. The first radio communication terminal device as claimed in claim 98, wherein the first plurality of radio communication terminal devices are members of a first radio communication terminal devices group; and wherein the second plurality of radio communication terminal devices are members of a second radio communication terminal devices group.

100. The first radio communication terminal device as claimed in claim 99, wherein the radio communication terminal devices groups are ad hoc radio communication terminal devices beacon groups.

101. The first radio communication terminal device as claimed in claim 91, wherein the synchronization transmitting period start time comprises at least one of a Beacon Period Start Time and a Beacon Period Start Time offset.

102. The first radio communication terminal device as claimed in claim 96, wherein the time/frequency portions comprise time/frequency codes.

103. A radio communication system comprising a first plurality of radio communication terminal devices and a second plurality of radio communication terminal devices, wherein: a radio communication terminal device of the second plurality of radio communication terminal devices is configured to carry out: determining a synchronization transmitting period start time of a radio communication terminal device of the first plurality; setting the synchronization transmitting period start time of the radio communication terminal device of the second plurality to the determined synchronization transmitting period start time and clock of the radio communication terminal device of the first plurality; and generating a synchronization message including information about the determined synchronization transmitting period start time of the radio communication terminal device of the first plurality.

104. The radio communication system as claimed in claim 103 being an ad hoc radio communication system, wherein the first plurality of radio communication terminal devices and the second plurality of radio communication terminal devices are ad hoc radio communication terminal devices.

105. The radio communication system as claimed in claim 103, wherein the radio communication terminal device of the second plurality of radio communication terminal devices is configured to carry out: determining the clock period of the radio communication terminal device of the first plurality.

106. The radio communication system as claimed in claim 103, wherein the radio communication terminal device of the second plurality of radio communication terminal devices is configured to carry out: setting the virtual clock which is a register of the radio communication terminal device of the second plurality to the clock of the radio communication terminal device of the first plurality.

107. The radio communication system as claimed in claim 103, wherein the synchronization message includes information about the determined clock period of the radio communication terminal device of the first plurality.

108. The radio communication system as claimed in claim 103, wherein the first plurality of radio communication terminal devices is of a first type, the second plurality of radio communication terminal devices is of a second type, wherein the first type of radio communication terminal devices is configured to provide only slotted time/frequency portion communication without slotted offset time/frequency portion communication, and wherein the second type of radio communication terminal devices is configured to provide slotted time/frequency portion communication and slotted offset time/frequency portion communication.

109. The radio communication system as claimed in claim 103, wherein the synchronization message includes an Application Specific Information Element being encoded in accordance with a second communication protocol format which can be decoded by a radio communication terminal device of the second type.

110. The radio communication system as claimed in claim 103, wherein the radio communication terminal device is further configured to carry out: transmitting the synchronization message to at least one other radio communication terminal device of the second plurality.

111. The radio communication system as claimed in claim 110, wherein the first plurality of radio communication terminal devices are members of a first radio communication terminal devices group; and wherein the second plurality of radio communication terminal are members of a second radio communication terminal devices group.

112. The radio communication system as claimed in claim 111, wherein the radio communication terminal devices groups are ad hoc radio communication terminal devices beacon groups.

113. The radio communication system as claimed in claim 103, wherein the synchronization transmitting period start time comprises at least one of a Beacon Period Start Time and a Beacon Period Start Time offset.

114. The radio communication system as claimed in claim 103, wherein the time/frequency portions comprise time/frequency codes.

115. The radio communication system as claimed in claim 110, wherein the at least one other radio communication terminal device of the second plurality is configured to carry out: receiving the synchronization message; setting the synchronization transmitting period start time of the at least one other radio communication terminal device of the second plurality to the inferred synchronization transmitting period start time of the radio communication terminal device of the first plurality.

116. The radio communication system as claimed in claim 110, wherein the at least one other radio communication terminal device of the second plurality is configured to carry out: setting the virtual clock which is a register of the at least one other radio communication terminal device of the second plurality to the inferred clock of the radio communication terminal device of the first plurality.