[go: up one dir, main page]

WO2010024784A1 - Procédés et dispositifs de demande de ressources radio et/ou de synchronisation dans un système de radiocommunication - Google Patents

Procédés et dispositifs de demande de ressources radio et/ou de synchronisation dans un système de radiocommunication Download PDF

Info

Publication number
WO2010024784A1
WO2010024784A1 PCT/SG2009/000303 SG2009000303W WO2010024784A1 WO 2010024784 A1 WO2010024784 A1 WO 2010024784A1 SG 2009000303 W SG2009000303 W SG 2009000303W WO 2010024784 A1 WO2010024784 A1 WO 2010024784A1
Authority
WO
WIPO (PCT)
Prior art keywords
radio communication
communication terminal
terminal device
time
slotted
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
PCT/SG2009/000303
Other languages
English (en)
Inventor
Ananth Subramanian
Xiaoming Peng
Po Shin Francois Chin
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Agency for Science Technology and Research Singapore
Original Assignee
Agency for Science Technology and Research Singapore
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Agency for Science Technology and Research Singapore filed Critical Agency for Science Technology and Research Singapore
Priority to CN2009801327450A priority Critical patent/CN102132617A/zh
Publication of WO2010024784A1 publication Critical patent/WO2010024784A1/fr
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W72/00—Local resource management
    • H04W72/20—Control channels or signalling for resource management
    • H04W72/21—Control channels or signalling for resource management in the uplink direction of a wireless link, i.e. towards the network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L5/00—Arrangements affording multiple use of the transmission path
    • H04L5/003—Arrangements for allocating sub-channels of the transmission path
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W72/00—Local resource management
    • H04W72/04—Wireless resource allocation
    • H04W72/044—Wireless resource allocation based on the type of the allocated resource
    • H04W72/0446—Resources in time domain, e.g. slots or frames
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W84/00—Network topologies
    • H04W84/18—Self-organising networks, e.g. ad-hoc networks or sensor networks

Definitions

  • Embodiments relate to the field of communication systems, such as radio communication systems, for example.
  • embodiments relate to methods of requesting and reserving radio resources.
  • embodiments relate to methods of synchronizing among the radio communication terminal devices within the radio communication system.
  • the radio communication system may be an ad hoc radio communication system comprising a plurality of ad hoc radio communication terminal devices.
  • 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.
  • 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.
  • OFDM 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.
  • a multi-band OFDM scheme is used to transmit information in the ECMA standard [I].
  • 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.
  • 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.
  • 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.
  • a method for requesting radio resources in a radio communication system is provided.
  • the method includes generating and encoding a first request message for radio resources including a plurality of slotted time/frequency portions.
  • 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.
  • 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.
  • a method for determining available radio resources in a radio communication system 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.
  • 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.
  • a method for synchronizing at least a first radio communication terminal device with a second radio communication terminal device in a radio communication system 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.
  • 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 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.
  • 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.
  • 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.
  • 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
  • FIG. 27 shows the possible values of some parameters used in the synchronization method.
  • frequency band may refer to a predefined continuous frequency range, which may be used for signal transmission.
  • a frequency band may often be referred to using a (frequency) band number associated with it.
  • 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.
  • a frequency channel may or may not have a continuous frequency range.
  • a frequency channel is often referred to using a frequency channel number associated with it.
  • 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.
  • Time-Frequency Code may include a frequency hopping pattern, wherein some patterns hop among frequency bands and some stay fixed in a single frequency band.
  • TFC Time-Frequency Interleaving
  • TFI Time-Frequency Interleaving
  • FFI Fixed Frequency Interleaving
  • TFC Time-Frequency Interleaving
  • FFI Fixed Frequency Interleaving
  • 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.
  • 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.
  • 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.
  • device B 112 is able to transmit OFDM symbols to devices A 111, C 113, D 114, E 115, and H 118.
  • 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
  • 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.
  • 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.
  • FIG. 2 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.
  • 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.
  • 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.
  • TFCs Time Frequency Codes
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • a first ad hoc radio communication device of the ad hoc radio communication devices' group 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).
  • 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.
  • 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.
  • 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.
  • the entire band group may be utilized at the same time.
  • the grey colored boxes 241-246 constitute TFC offset 0
  • the black colored boxes 261-266 constitute TFC offset 1
  • white colored boxes 251-256 constitute TFC offset 2.
  • 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.
  • 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
  • TFC offset 2 has a still larger time shifted version of the frequency hopping pattern relative to TFC offset 0.
  • offset 0 For a frequency channel with 3 frequency bands, there can only be up to two offsets of a TFC (offset 0).
  • 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
  • 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.
  • Beacon Period 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).
  • MASs Medium Access Slots
  • FIG. 3 illustrates the basic structure of superframe 310 according to the ECMA standard (reference [I]).
  • 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.
  • OFDM Symbol Transmission Duration (OSTD)
  • 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.
  • 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.
  • ASIE Application Specific Information Element
  • Probe IE Application Specific Probe IE
  • Application Specific Command Frame Application Specific Control Frame
  • UWB Ultra Wide Band
  • FIG. 4 illustrates the format 400 of an ASIE as defined in the ECMA specification [I].
  • 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.
  • the payload 500 of the Application Specific Command/Control frame may include a Specifier ID field 501 and an Application specific Data field 502.
  • FIG. 6 illustrates the format 600 of the Application Specific Probe IE as defined in the ECMA specification [I].
  • 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.
  • formats for the data fields defined as part of the ASIE, Application Specific Probe IE, and Application Specific Command and Control frames are provided.
  • 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.
  • DRP Distributed Reservation Protocol
  • PCA Prioritized Channel Access
  • FIG. 7 illustrates the format of Application Specific Control field 700 according to 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.
  • 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.
  • the bit3- bit7/bitl5 702 of the Application Specific Control field 700 are reserved.
  • 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.
  • 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.
  • an Application Specific Identifier field 801 is provided preceding every contiguous set of information 802 pertaining to the single field type.
  • 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.
  • 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.
  • FIG. 9 (b) illustrates the format of the Field Information field 901 in one embodiment.
  • bit4-bit7 903 of the Field Information field 901 are reserved.
  • bit ⁇ -bit3 904 of the Field Information field 901 are used to indicate the Field type.
  • 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).
  • Field Information octet 901 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).
  • 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.
  • 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
  • a value of "3" in Field Type field 904 may be used to indicate the Field type of Data Elements
  • values of "4" - "15" in Field Type field 904 may be reserved.
  • 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).
  • the data field of the ASIE all the information elements are packed together and all the command elements are packed together.
  • the IEs sent using ASIEs 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]).
  • an Application Specific Identifier field 801 is placed before every set of information pertaining to a single field type. [0049] FIG.
  • 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.
  • FIG. 10 (b) illustrates the format of the Control Element Information field 1002.
  • the bit ⁇ -bit3 1005 of the Control Element Information field 1002 are used to indicate the Control Element Type
  • the bit4- bit7/bitl5 1006 of the Control Element Information field 1002 are reserved.
  • 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.
  • FIG. 11 (b) illustrates the format of the Command Element Information field 1102.
  • the bit ⁇ -bit3 1105 of the Command Element Information field 1102 are used to indicate the Command Element Type.
  • the bit4- bit7/bit 15 1106 of the Command Element Information field 1102 are reserved.
  • FIG. 12 (a) illustrates the format of a Query Information field 1201 according to 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.
  • 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
  • the Query Information field 1201 may include a
  • FIG. 12 (b) illustrates the format of the Query Control octet 1202 according to one embodiment.
  • bit ⁇ -bit3 1205 of the Query Control field 1202 are used to indicate the Query Type/ID.
  • Control field 1202 are reserved.
  • bit7 1207 is used to indicate whether there is Query Specific Data 1204 being included in the Query Information field 1201.
  • bit7 1207 is set to ZERO in the Query Control octet 1202
  • Query Information field 1201 is of length 1 octet (Query Length octet and Query Specific
  • 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.
  • value of "0" indicates TFC offset 0
  • a value of "1” corresponds to TFC offset 1
  • a value of "2" corresponds to TFC offset 2.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • value of "0" indicates TFC offset 0
  • a value of "1" corresponds to TFC offset 1
  • a value of "2" corresponds to TFC offset 2.
  • every device capable of operating in slotted offset TFC and from the same vendor may include ASIE in its beacon.
  • 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.
  • one of the reserved bits 702 in Application Specific Control field 700 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.
  • all the IEs related to the use of slotted offset TFCs are included in the ASIE.
  • 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.
  • DRP Distributed Reservation Protocol
  • the DRP reservation policy is provided as follows in accordance with an 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.
  • 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.
  • 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.
  • a device sends an ASIE in its beacon.
  • all the IEs related to the use of slotted offset TFCs are included in the ASIE.
  • implicit reservation negotiation takes place through the ASIEs between devices capable of operating in slotted offset TFCs and from the same vendor.
  • DRP IEs as given in ECMA specification (reference [I]) are sent in addition to the ASIE.
  • the reservation types are the same as given in ECMA specification [I].
  • 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.
  • 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.
  • 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.
  • a device that is capable of operating in slotted offset time/frequency portion communication may also have features specified by reference [I].
  • 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.
  • the devices that are able to operate in slotted offset TFCs and from the same vendor 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.
  • 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.
  • DRP IE Separate from ASIE
  • 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.
  • 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.
  • 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.
  • 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.
  • the phrase "hidden” implies that a ECMA [1] specified device is not required to parse and decode all ASIEs.
  • the owner or the target 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).
  • DRP IE is sent by both owner and target seeking or negotiating column/row reservation for these MASs alone.
  • conflicts pertaining to the above column/ row reservation may be handled as defined by the conflict resolution protocol in ECMA specification (reference [I]).
  • a ECMA [1] specified device reserves a MAS
  • the MAS is not used by any other device using any higher offset or default offset.
  • 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.
  • 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.
  • 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.
  • 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).
  • three enhanced DRP availability IEs may be sent in the ASIE if availability needs to be advertised for three offsets of a channel.
  • the device also may send the DRP availability as defined in ECMA specification (reference [I]), in its beacon.
  • 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.
  • 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.
  • ECMA [1] e.g., ECMA [1] specification pertaining to DRP for default offset
  • ASIEs e.g., devices 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.
  • 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.
  • 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.
  • the devices Al to A5 are from the same vendor and are able to operate in slotted offset TFCs.
  • the devices Bl to B3 are ECMA [1] specified devices.
  • 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.
  • 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
  • a device any of Al to A5 1851-1855
  • the fixed number may be predetermined.
  • 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.
  • 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.
  • 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).
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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).
  • the frequency hopping pattern may not be aligned (or synchronous) in time with the start of any OSTD or MAS boundary.
  • 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).
  • 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.
  • offset 0 TFC offset
  • 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.
  • 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.
  • the radio resources may include a plurality of slotted time/frequency portions.
  • the slotted offset time/frequency portions are represented by the grey colored boxes 261-266.
  • 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.
  • 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.
  • 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).
  • 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.
  • the second request message may be sent during a beacon slot.
  • the second request message may include an Application Specific Information Element (ASIE).
  • ASIE Application Specific Information Element
  • 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).
  • TFC Time-Frequency Codes
  • 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).
  • MAS Medium Access Slot
  • 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.
  • a frequency portion is designated for each time portion.
  • 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.
  • the method is carried out by an ad hoc radio communication terminal device.
  • 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.
  • 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.
  • 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.
  • 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.
  • a higher TFC offset (TFC offset 1 or TFC offset 2) may be reserved.
  • TFC offset 1 or TFC offset 2 may be reserved.
  • 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.
  • the resource reservation message may include an Application Specific Information Element being encoded in accordance with the second communication protocol format.
  • the format may be as shown in FIG. 8.
  • FIG. 18 (c) illustrates a method for determining available radio resources in a radio communication system according to 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.
  • 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.
  • the radio communication system is an ad hoc radio communication system
  • 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.
  • 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.
  • the request message may be sent during a beacon slot.
  • 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.
  • ASIE Application Specific Information Element
  • 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.
  • 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.
  • 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.
  • the time/frequency portions may include time/frequency codes.
  • 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.
  • the method may be carried out by an ad hoc radio communication terminal device.
  • 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.
  • the ad hoc radio communication group may be an ad hoc radio communication beacon group.
  • 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.
  • 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.
  • the resource reservation message includes an Application Specific Information Element being encoded in accordance with the second communication protocol format.
  • the second communication protocol format may be the format as shown in FIG. 8.
  • FIG. 18 (d) illustrates a radio communication terminal device 1830 for requesting radio resources in a radio communication system 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the time/frequency portions may include time/frequency codes.
  • 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.
  • 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.
  • the ad hoc radio communication group is an ad hoc radio communication beacon group.
  • 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.
  • 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.
  • the first generator 1831, the second generator 1833, and the third generator 1837 may be the same generator.
  • 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.
  • the resource reservation message includes an Application Specific Information Element being encoded in accordance with the second communication protocol format.
  • FIG. 18 (e) illustrates a radio communication terminal device 1840 for determining available radio resources in a radio communication system 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.
  • 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.
  • 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.
  • 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.
  • the first determining circuit 1841 and the second determining circuit 1842 may be the same determining circuit.
  • 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.
  • 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.
  • the time/frequency portions may include time/frequency codes.
  • 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.
  • 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.
  • the ad hoc radio communication group may be an ad hoc radio communication beacon group.
  • 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.
  • 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.
  • the first transmitter 1843 and the second transmitter 1847 may be the same transmitter.
  • the resource reservation message includes an Application
  • Specific Information Element being encoded in accordance with the second communication protocol format.
  • PCA Prioritized Channel Access
  • three independent and parallel implementations of the existing PCA back off module and protocol may be used in parallel for use of slotted offset TFCs using PCA.
  • 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
  • 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.
  • the packet is transmitted using the TFC offset corresponding to the back off counter that reached zero.
  • the packet is transmitted as soon as one of the back off counters corresponding to the three TFC offsets of the channel reaches zero.
  • 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.
  • 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).
  • 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.
  • AIFS Arbitration Inter-Frame Spacing
  • the counter clock of TFC offset 2 first reaches zero.
  • 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.
  • 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.
  • 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.
  • no slot may be occupied by any device at an offset higher than the default offset without first being occupied at the default offset.
  • only MASs occupied by lower TFC offsets may be considered for PCA availability in a particular TFC offset whose offset is higher than zero.
  • 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).
  • 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.
  • Link Feedback IE is sent once every superframe.
  • the coherence time of channels can be much less than the duration of a superframe, which is 65.536 ms.
  • 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.
  • 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.
  • 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.
  • both the data transmission characteristic request message and the data transmission characteristic response message are command/control frames.
  • 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.
  • LQI Link Quality Indicator
  • SNR Signal to Noise Ratio
  • FCS Frame Check Sequence
  • HCS Header Check Sequence
  • the command/control messages are command/control frames.
  • command/control frames are for sending command/control information among communication devices within a communication devices' group.
  • 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.
  • 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.
  • 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.
  • data transmission may include the transmission of a plurality of data packets
  • 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.
  • the data transmission characteristic information includes information about the measurement window time period as well.
  • 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.
  • the data transmission characteristic information includes information about the signal to noise ratio at the receiver pertaining to the data transmission.
  • the data transmission characteristic response message includes information for setting the transmit power level of the data transmission.
  • the data transmission characteristic response message includes information for setting the transmit data rate of the data transmission.
  • a data transmission characteristic request message is sent aperiodically.
  • the data transmission characteristic response messages include information for setting the data rate of the data transmission.
  • 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.
  • 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).
  • SIFS Short Interframe Spacing
  • 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.
  • 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).
  • SIFS Short Interframe Spacing
  • 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".
  • FIGs. 22 (a)-(c) 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.
  • 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).
  • 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.
  • 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.
  • octets 2202 and/or octets 2203 and/or octets 2204 and/or octets 2205, and/or octet(s) 2206, and/or octet 2207
  • 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.
  • 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.
  • 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.
  • bit b2 2213 may be reserved.
  • 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).
  • a command/control frame payload as shown in format 2210
  • 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.
  • 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).
  • the Command/Control Element Type 1105/1005 may be set to be a predetermined value to correspond to a Link Feedback Command/Control Element.
  • FIG. 20 illustrates the Link Feedback Command/Control Payload that may be included into an Application Specific Command/Control frame according to 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).
  • 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.
  • 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.
  • the command/control payload 2001 may include a Link Feedback Control field 2010.
  • 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
  • Link Feedback Control field 2010 may have the format as shown in 2002 as shown in FIG. 20 (b).
  • bitl2-bitl5 2020 of the Link Feedback Control field 2010 may be reserved.
  • 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
  • the Data Rate field 2021 may be encoded as given in ECMA [1] specification.
  • 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 recommends to the receiver of the
  • the Transmit Power Level Change field 2022 encoding may be as given in ECMA [1] specification.
  • bit3 may be used as the Device List Field Inclusion bit
  • 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.
  • bit3 2023 may be reserved.
  • 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
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • Link Information field 2012 may have the format 2003 as shown in FIG. 20 (c).
  • 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.
  • 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.
  • 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.
  • 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.
  • FIG. 21 (a) illustrates an alternate format of the Link Information field 2012 according to one embodiment.
  • 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.
  • 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.
  • 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.
  • FIG. 21 (b) illustrates the format of the Device List field 2011 according to 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.
  • 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
  • the device may respond with a Link feedback command frame.
  • the device may transmit a Link feedback command frame after a delay given by:
  • Time_to_send_Response pSIFS + pSlotTime + (Position in Device List) x
  • 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
  • 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
  • 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
  • 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.
  • 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.
  • the Channel Consensus (CC) Information Element is used as a channel changing negotiating message.
  • the communication device may include a Channel Consensus (CC) Information Element in its beacon, for example, in the next superframe.
  • 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.
  • 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.
  • 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.
  • the Channel Consensus (CC) Information Elements may include a Channel Consensus (CC) Control field to store control information.
  • 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.
  • 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.
  • the Channel Consensus (CC) Information Elements may include a Band Availability field to store information on the availability of frequency bands.
  • 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).
  • CC Channel Consensus
  • 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.
  • 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.
  • 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.
  • a communication device 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.
  • 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.
  • CC Channel Consensus
  • 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.
  • a 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.
  • CC Channel Consensus
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the method further includes a step 2302 of determining the synchronization transmitting period start time of the second radio communication terminal device.
  • 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.
  • 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).
  • 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.
  • 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).
  • 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.
  • the slowest device is one of communication devices B1-B3 1856-1858
  • one of communication devices A1-A5 1851-1855 synchronizes with the slowest device first.
  • other communication devices of A2-A5 1852-1855 then synchronize with communication device Al 1851.
  • 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)).
  • 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.
  • 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.
  • a predetermined time e.g. a number of superframes
  • device Al 1851 may decide whether device Bl 1856 is slower than device Al 1851 or not.
  • 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.
  • 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.
  • the step 2302 may further comprise determining the clock period of the second radio communication terminal device.
  • device Al 1851 determines the clock period of the device Bl 1856.
  • 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.
  • the synchronization transmitting period start time is a Beacon Period Start Time (BPST).
  • 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.
  • 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.
  • 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.
  • 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).
  • the time/frequency portions comprise time/frequency codes (TFCs).
  • TFCs time/frequency codes
  • 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.
  • 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.
  • the method is carried out by an ad hoc radio communication terminal device.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the third radio communication terminal device is of the same type of radio communication terminal device as the first radio communication terminal device.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the second determining circuit 2312 is further configured to determine the clock period of the second radio communication terminal device.
  • 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.
  • 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.
  • the synchronization transmitting period start time is a
  • 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.
  • 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.
  • the time/frequency portions may include time/frequency codes.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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
  • the synchronization transmitting period start time may be a Beacon Period Start Time.
  • the second radio communication terminal device Bl 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.
  • 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.
  • the time/frequency portions may include time/frequency codes.
  • 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.
  • the radio communication system may further include a third radio communication terminal device A5 1855.
  • 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.
  • 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.
  • 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.
  • 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
  • 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.
  • HCS Header Check Sequence
  • FCS Frame Check Sequence
  • an alien BP length in an alien beacon is referred to as an alien BP.
  • an Enhanced BP Switch IE is provided to indicate that a device will change its BPST to align with an alien BP.
  • FIG. 24 illustrates the format of the proposed Enhanced BP Switch IE 2400.
  • 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.
  • the Enhanced BP Switch IE 2400 may further include a BP Move Countdown field 2403.
  • the Enhanced BP Switch IE 2400 may further include a Beacon Slot Offset field 2404.
  • the Enhanced BP Switch IE 2400 may further include a Clock Period Offset field 2405.
  • the Enhanced BP Switch IE 2400 may further include a BPST Offset field 2406.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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 BPST
  • 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.
  • device Al 1851 may generate a synchronization message including information about the determined synchronization transmitting period start time of device A4 1854.
  • 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.
  • 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.
  • 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
  • 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.
  • 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.
  • 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.
  • 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.
  • the second type of radio communication terminal devices is configured to provide slotted time/frequency portion communication and slotted offset time/frequency portion communication.
  • 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.
  • the synchronization message includes an Application
  • 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.
  • 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.
  • the first plurality of radio communication terminal devices are members of a first radio communication terminal devices group.
  • the second plurality of radio communication terminal devices are members of a second radio communication terminal devices group.
  • the radio communication terminal devices groups may be or may include radio communication terminal devices beacon groups.
  • 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.
  • the time/frequency portions may include time/frequency codes.
  • 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.
  • device Al 1851 sends out the ASIE
  • other device for example device A5 1855, receives and decodes the ASIE from device Al 1851.
  • 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.
  • 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.
  • 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.
  • the determining circuit 2511 is configured to determine the clock period of the second radio communication terminal device of the second plurality.
  • 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.
  • 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.
  • the first type of radio communication terminal devices is configured to provide slotted time/frequency portion communication and slotted offset time/frequency portion communication
  • 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.
  • 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.
  • the synchronization message includes information about the determined clock period of the second radio communication terminal device.
  • 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.
  • 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.
  • the first plurality of radio communication terminal devices are members of a first radio communication terminal devices group.
  • the second plurality of radio communication terminal devices are members of a second radio communication terminal devices group.
  • the radio communication terminal devices groups are ad hoc radio communication terminal devices beacon groups.
  • the synchronization transmitting period start time may include at least one of a Beacon Period Start Time and a Beacon Period Start Time offset.
  • the time/frequency portions may include time/frequency codes.
  • a radio communication system comprising a first plurality of radio communication terminal devices and a second plurality of radio communication terminal devices.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the radio communication terminal device e.g. device Al 1851
  • the radio communication terminal device e.g. device Al 1851
  • the radio communication terminal device 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.
  • the synchronization message includes information about the determined clock period of the radio communication terminal device of the first plurality.
  • 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.
  • 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
  • the second type of radio communication terminal devices is configured to provide slotted time/frequency portion communication and slotted offset time/frequency portion communication.
  • 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.
  • 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.
  • the first plurality of radio communication terminal devices are members of a first ad hoc radio communication terminal devices group
  • the second plurality of radio communication terminal devices are members of a second ad hoc radio communication terminal devices group.
  • the ad hoc radio communication terminal devices groups may be or include ad hoc radio communication terminal devices beacon groups.
  • the synchronization transmitting period start time may include at least one of a Beacon Period Start Time and a Beacon Period Start Time offset.
  • the time/frequency portions may include time/frequency codes.
  • the at least one other radio communication terminal device e.g. device A5 1855 is configured to carry out receiving the synchronization message
  • 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 .
  • 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.
  • 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.
  • 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.
  • the device may follow the BP alignment rules given in ECMA [1] specification. [00283] 6.2.1 Overlapping BPs
  • 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.
  • 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.
  • 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.
  • the mSignalSlotCount may represent two beacon slots.
  • it may follow normal BP join rules as specified in ECMA [1] specification to relocate its beacon to the alien BP.
  • the device does not send further beacons in its previous BP.
  • the device 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
  • a device may merge BPs according to the following rules according to one embodiment.
  • 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.
  • DRP IE see, for example, FIG. 13
  • 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.
  • 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:
  • the device should not change beacon slots, unless a collision is detected.
  • the device shall listen for beacons during the MASs indicated in the reservation. [00288] 6.2.3 Beacon relocation
  • 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:
  • 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:
  • the device may set the BP Move Countdown field 2403 (see FIG. 24) to a value equal to mBPMergeWaitTime.
  • 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 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
  • 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.
  • 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.
  • BPOIE Beacon Period Occupancy IE
  • 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
  • the device may set the
  • the device may set the BP Move Countdown field 2403
  • the device may follow the following rules according to one embodiment:
  • the device may include an Enhanced BP Switch IE in its beacon in the following superframe with the fields set as follows:
  • the device may set the BP Move Countdown field 2403 to the BP Move Countdown field of the neighbour's Enhanced BP Switch IE.
  • the device may set the BPST Offset field 2406 to the value of the same field contained in the neighbour's beacon.
  • the device may set the Clock Period Offset field 2405 to the value of the same field contained in the neighbour's beacon.
  • 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.
  • 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.
  • a device may continue to do so until it completes or halts the relocation process according to one embodiment.
  • a device may halt the relocation process.
  • the device may halt the relocation process if a neighbour halts the relocation process.
  • 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.
  • the device may follow the rules above.
  • 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.
  • 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.
  • the device may transmit a beacon in that superframe, or delay one superframe to begin beacon transmission in its new BP.
  • the device may include neither the Enhanced BP Switch IE nor the alien BP DRP IE in its beacon.
  • 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
  • Each device may maintain a Beacon Period Start Time (BPST).
  • BPST Beacon Period Start Time
  • Each device may also maintain a virtual clock (which may be a register).
  • Each device may maintain superframe synchronization with its slowest neighbour.
  • 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.
  • 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.
  • 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).
  • 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
  • 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.
  • the device 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.
  • 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.
  • the device starts the neighbour's clock period estimation procedure in the current superframe, it may do the following.
  • 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 c i 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.
  • the beacon slot of D 114 as seen by A 111 be rii, a known quantity.
  • P clk can be selected differently depending on individual implementations. For example,
  • P clk may also be selected based on 66 MHz clock.
  • 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.
  • 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
  • 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.
  • 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.
  • 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 -
  • C D can be estimated as 1.89405 ns and using equation (6), B D can be estimated as 2.5752 ⁇ s.
  • FIG. 27 illustrates a table of the possible values of the parameters of pClockFrequency, pClockPeriod, pNumberofClockCyclesperSuperframe, and pNumberofClockCyclesperBeaconSlot.
  • 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.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

La présente invention porte sur un procédé de demande de ressources radio dans un système de radiocommunication. Ledit procédé comprend la génération et le codage d'un premier message de demande de ressources radio comprenant une pluralité de parties d'intervalle de temps/fréquence, le premier message de demande comprenant un élément d'informations codé selon un premier format de protocole de communication qui peut être décodé par un terminal d'un premier type configuré pour transmettre une communication pendant un intervalle de temps/fréquence et par un terminal d'un second type configuré pour transmettre une communication pendant un intervalle de temps/fréquence et une communication pendant un intervalle de temps/fréquence décalé. L’invention concerne également un procédé de synchronisation d'un premier dispositif terminal avec un second dispositif terminal dans un système de radiocommunication consistant à déterminer si le second terminal n'a pas changé son instant de début de la période de transmission de synchronisation pendant une durée prédéterminée et à établir l'instant de début de la période de transmission de synchronisation du premier terminal radio à l'instant de début de la transmission de synchronisation du second terminal.
PCT/SG2009/000303 2008-08-28 2009-08-28 Procédés et dispositifs de demande de ressources radio et/ou de synchronisation dans un système de radiocommunication Ceased WO2010024784A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN2009801327450A CN102132617A (zh) 2008-08-28 2009-08-28 用于请求无线电资源和/或在无线电通信系统内实现同步化的方法和装置

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US9246708P 2008-08-28 2008-08-28
US61/092,467 2008-08-28

Publications (1)

Publication Number Publication Date
WO2010024784A1 true WO2010024784A1 (fr) 2010-03-04

Family

ID=41721746

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/SG2009/000303 Ceased WO2010024784A1 (fr) 2008-08-28 2009-08-28 Procédés et dispositifs de demande de ressources radio et/ou de synchronisation dans un système de radiocommunication

Country Status (3)

Country Link
CN (1) CN102132617A (fr)
TW (1) TW201012157A (fr)
WO (1) WO2010024784A1 (fr)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2013534783A (ja) * 2010-07-07 2013-09-05 コーニンクレッカ フィリップス エヌ ヴェ 無線システムにおけるマルチバンド通信を可能にする方法及びシステム
CN111491354A (zh) * 2019-01-25 2020-08-04 阿里巴巴集团控股有限公司 自组网中的节点同步方法、装置和自组网系统
US11178563B2 (en) * 2017-04-13 2021-11-16 Telefonaktiebolaget Lm Ericsson (Publ) Distributed scheduling algorithm for CPRI over ethernet
RU2771740C1 (ru) * 2021-07-30 2022-05-11 Юрий Иванович Стародубцев Способ передачи абонентских сигналов с адаптивной ступенчатой дискретизацией по линии связи с отказами, работающей на выбранной скорости передачи

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP6048843B2 (ja) * 2012-02-20 2016-12-21 パナソニックＩｐマネジメント株式会社 多層式の無線通信システム
CN108770015B (zh) * 2018-05-29 2021-03-23 清华大学 通信系统传输方式的选择方法及装置

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20050159106A1 (en) * 2003-12-30 2005-07-21 Arto Palin Method and system for assigning time-frequency codes
US20050176371A1 (en) * 2004-02-09 2005-08-11 Arto Palin Synchronization of time-frequency codes
US20070201423A1 (en) * 2006-01-11 2007-08-30 Rajiv Laroia Methods and apparatus relating to timing and/or synchronization including the use of wireless terminals beacon signals
US20080056187A1 (en) * 2006-08-31 2008-03-06 Futurewei Technologies, Inc. System For Grouping Users To Share Time-Frequency Resources In A Wireless Communication System

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20050159106A1 (en) * 2003-12-30 2005-07-21 Arto Palin Method and system for assigning time-frequency codes
US20050176371A1 (en) * 2004-02-09 2005-08-11 Arto Palin Synchronization of time-frequency codes
US20070201423A1 (en) * 2006-01-11 2007-08-30 Rajiv Laroia Methods and apparatus relating to timing and/or synchronization including the use of wireless terminals beacon signals
US20080056187A1 (en) * 2006-08-31 2008-03-06 Futurewei Technologies, Inc. System For Grouping Users To Share Time-Frequency Resources In A Wireless Communication System

Cited By (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2013534783A (ja) * 2010-07-07 2013-09-05 コーニンクレッカ フィリップス エヌ ヴェ 無線システムにおけるマルチバンド通信を可能にする方法及びシステム
US9730216B2 (en) 2010-07-07 2017-08-08 Koninklijke Philips N.V. Method and system for enabling multiple transmission in wireless systems
US11178563B2 (en) * 2017-04-13 2021-11-16 Telefonaktiebolaget Lm Ericsson (Publ) Distributed scheduling algorithm for CPRI over ethernet
US11770729B2 (en) 2017-04-13 2023-09-26 Telefonaktiebolaget Lm Ericsson (Publ) Distributed scheduling algorithm for CPRI over ethernet
CN111491354A (zh) * 2019-01-25 2020-08-04 阿里巴巴集团控股有限公司 自组网中的节点同步方法、装置和自组网系统
CN111491354B (zh) * 2019-01-25 2023-09-12 阿里巴巴集团控股有限公司 自组网中的节点同步方法、装置和自组网系统
RU2771740C1 (ru) * 2021-07-30 2022-05-11 Юрий Иванович Стародубцев Способ передачи абонентских сигналов с адаптивной ступенчатой дискретизацией по линии связи с отказами, работающей на выбранной скорости передачи

Also Published As

Publication number Publication date
CN102132617A (zh) 2011-07-20
TW201012157A (en) 2010-03-16

Similar Documents

Publication Publication Date Title
AU2005297231B2 (en) A system and method for dynamic adaptation of data rate and transmit power with a beaconing protocol
US7492736B2 (en) System and method for access and management of beacon periods in distributed wireless networks
US8018912B2 (en) System and method for a dynamic beacon period in a MAC distributed reservation protocol
EP2232938B1 (fr) Structure souple de supertrame mac et procédé de balisage associé
JP4806721B2 (ja) アドホックネットワークのための分散型無線メディアアクセス制御プロトコル
CA2556062C (fr) Systeme et procede pour un protocole de reservation repartie de commande d'acces au support a bande ultra large
TWI387279B (zh) 高速媒體存取控制及直接鏈路協定
CN101953107B (zh) 网络吞吐量增强方法
KR20060063897A (ko) 무선 통신 시스템, 무선 통신 장치 및 무선 통신 방법, 및컴퓨터 프로그램
AU2008252714A1 (en) Improved use of network capacity
CN102090013B (zh) 用于提高网络吞吐量的方法
WO2010024784A1 (fr) Procédés et dispositifs de demande de ressources radio et/ou de synchronisation dans un système de radiocommunication
CN101044695B (zh) 用于通过信标协议进行数据速率和传输功率的动态自适应的系统和方法
MXPA06008800A (en) A system and method for a dynamic beacon period in a mac distributed reservation protocol

Legal Events

Date Code Title Description
WWE Wipo information: entry into national phase

Ref document number: 200980132745.0

Country of ref document: CN

121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 09810330

Country of ref document: EP

Kind code of ref document: A1

DPE1 Request for preliminary examination filed after expiration of 19th month from priority date (pct application filed from 20040101)
NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 09810330

Country of ref document: EP

Kind code of ref document: A1