Method and apparatus for Time-Of-Day synchronization between nodes

BACKGROUND OF THE INVENTION

1. Technical Field

0001The present invention pertains to synchronization of nodes within a network. In particular, the present invention pertains to a time-of-day synchronization (TOD) within wireless ad-hoc networks that determines an appropriate time for network nodes to switch to a common GPS time without disruption of existing communication links.

2. Discussion of Related Art

0002Commercial wireless devices employ clock synchronization techniques for their operation in WPAN (Wireless Personal Area Networks) and WLAN (Wireless Local Area Networks) type networks. Exemplary WPAN type devices include Bluetooth devices designed to support low bandwidth and short distance (e.g., less than ten meters) wireless connections. Bluetooth specifies the protocols to be used by different handheld computing devices in order to communicate and exchange data. For timing purposes, Bluetooth specifies a master/slave clock synchronization mechanism allowing synchronization between neighboring nodes that reside one-hop away from each other within the network.

0003The IEEE 802.11 WLAN standard specifies two different approaches for time synchronization. One approach accommodates infrastructure-based networks, while the other approach accommodates independent networks. With respect to infrastructure-based networks, IEEE 802.11 provides a master/slave clock synchronization mechanism, where a special fixed node (referred to as an access point (AP)) is used as a master. In an independent network, a mobile node transmits a beacon message at a selected beacon period. Each node receiving the beacon message updates the node clock with the value in the received beacon message in response to the received value being greater than the node current local time. If the received value is less than the node local time, the received value is discarded.

0004In a tactical environment, Radio Frequency (RF) communications must be protected against major enemy threats including jamming and signal interception. In order to protect against these threats, a modern tactical system constantly changes the transmission frequency (e.g., by frequency hopping (FH), by direct sequence spread spectrum (DSSS), by both techniques, etc.) and encrypts the transmitted data with a time dependent encryption algorithm. Tactical network nodes must therefore be accurately synchronized in time to communicate. The time synchronization problem is especially difficult in a tactical network due to the volatility of RF links.

0005An example of a tactical ad-hoc radio system employing a conventional approach to time-of-day (TOD) synchronization includes a Near Term Data Radio (NTDR) system from ITT. This system employs three time-of-day (TOD) message types (e.g., Cold Start, Late Net Entry (LNE) and In-Net) to enable all radios or nodes within the network to synchronize with a common time (e.g., time-of-day). In Cold Start (CS) mode, all radios or nodes within the network use a fixed time (Transmission Security (TRANSEC)). This enables all radios within the network to listen to the Cold Start messages without an initial time (e.g., time-of-day) reference. Upon receiving a Cold Start time-of-day update message, a radio extracts the transmitter time from the message and uses that time to update the node time-of-day. Subsequently, the radio in Cold Start mode enters a Late Net Entry (LNE) mode and selects an LNE time (TRANSEC), which is generally within six minutes from an In-Net time-of-day. A radio dwelling in LNE mode remains in that mode until the radio time-of-day is within twenty milliseconds (20 msec) of the transmitter time. Once this occurs, the radio transitions into an In-Net mode. An In-Net mode message is used for normal message transmission within the network.

0006The time-of-day synchronization scheme of the Near Term Data Radio (NTDR) system has been modified to satisfy the constrained requirements of a Small Unit Operation (SUO) network. This type of network includes extremely mobile, volatile, power and bandwidth limited operational conditions. The basic functionality of the Cold Start (CS), Late Net Entry (LNE) and In-Net modes of the Near Term Data Radio (NTDR) system are similar to "Isolated", "In Sync", and "Associated" modes employed in the SUO system. Due to the severe timing constraints imposed by the Small Unit Operation (SUO) security features, nodes must establish a common network time before commencing communications. This is accomplished by the time-of-day (TOD) synchronization scheme or protocol. If a node with local Global Positioning System (GPS) time or capability is present, the aggregate network time (e.g., "net time" or non-GPS based network time) must be slowly pulled towards the GPS time in order to facilitate multi-tier operation. It should be noted that "GPS time" in the following is used as a well known possible source for a "common reference time". The principles described however could be bases on any other kind of common reference time. However, the time-of-day synchronized nodes constantly lose and regain connectivity with each other in a tactical or ad-hoc environment. In order to solve the problem of fragmented networks, a "flywheel" technique has been proposed to allow nodes to continue to predict, and therefore track, the movement of the network time as adjusted by neighboring nodes. This type of technique or scheme is disclosed in <patcit id="pcit0001" dnum="US20040047307A"><text>U.S. Patent Application Publication No. 2004/0047307 (Yoon et al.</text></patcit>), the disclosure of which is incorporated herein by reference in its entirety. One of the advantages of the flywheel time-of-day synchronization scheme includes a roaming node with local GPS time being able to synchronize with existing (non-GPS based) network time immediately, and slowly pull the network time toward the GPS based time.

0007Although the flywheel technique overcomes difficulties encountered with respect to time synchronization within an ad-hoc environment, the technique can stand some improvement. For example, when the network time (e.g., non-GPS based time) differs from the GPS time by one-second, the interval for the network time to reach the GPS based time is in excess of one hour (e.g., 1.33 hours). The time-offset between the network time and the GPS time is unpredictable and depends upon the operational scenario (e.g., the node starting first and/or the node having a local GPS time among the neighboring nodes, the start time of the node, etc.). This potentially long pulling time by the flywheel technique may be unacceptable in the highly mobile, volatile, power and bandwidth limited tactical networks. In an attempt to overcome this problem, a node with local GPS time may flood an LNE message to neighboring nodes directing the nodes to acquire the GPS signal and set node clocks to GPS time immediately. However, the sudden changes of network time may disturb the current communication in the existing network since nodes more than one hop away from a group or island head node may not timely receive information related to the GPS transition and be unaware of when to perform that transition to GPS time.

0008Further, if a node local clock time is not updated by neighboring nodes with GPS time, drifts in the local clock may accumulate during the long pulling period of the flywheel technique. The accumulated clock drifts during the flywheel pulling interval may cause fragmented networks. For example, a node with a clock drift rate of one part per million (ppm) that updates the node clock via the flywheel technique loses connectivity with the existing network after two-hundred updates since the maximum value for staying within the network time is exceeded (e.g., Δt_max of two-hundred microseconds (200 µsec)).

0009When two unconnected islands or groups of nodes (e.g., fragmented networks) come within proximity of one another, some of the member nodes within the different islands begin to establish RF neighbor relationships in order to merge. Unless time synchronization is achieved between these neighboring nodes, the merging of the fragmented networks cannot be resolved.

0010The time synchronization between fragmented networks is very expensive with respect to the hardware/software processing required. For example, an Associated node within the SUO system requires an extra receiver during the pulling period of the flywheel technique in order to monitor reception of an LNE message for resolving fragmented networks for merging. Even if the node receives the LNE message, additional processing or techniques are needed to arrange other nodes and set the node times to the targeted time without interrupting the communication links.

0011Thus, pulling network time to GPS time by a node with GPS may be problematic in tactical ad-hoc networks due to a potentially long pulling time, accumulated clock drifts and very expensive hardware/software implementation for a merge.

OBJECTS AND SUMMARY OF THE INVENTION

0012Accordingly, it is an object of the present invention to rapidly transition network nodes to the common reference time (e.g. GPS time) within an ad-hoc wireless network.

0013It is another object of the present invention to determine an appropriate time for network nodes to transition to common reference time (e.g. GPS time) without affecting communication links within the network.

0014The aforesaid objects may be achieved individually and/or in combination, and it is not intended that the present invention be construed as requiring two or more of the objects to be combined unless expressly required by the claims attached hereto.

0015According to the present invention, a node or communication unit with local common reference time (e.g. GPS time) in an ad-hoc wireless network synchronizes with the network time immediately and slowly pulls the network time to common reference time (e.g. GPS time). Nodes within the network transition to the common reference time after an island or group head node or unit determines that the transition in network time does not disturb the communication links. In particular, preferably an island or group head node or unit determines a score value based on the quantity of members in an island and the offset between network time and common reference time. If the score exceeds a threshold value, the island or group head node or unit sends a transition request message to corresponding member nodes of the group or island. The island or group head node or unit further starts a timer for the next update sequence.

0016When a member node of an island or group receives the transition request message, preferably the node sends an acknowledgement (ACK) message back to the island head node or unit. Once the island head node receives acknowledgement messages from more than a predefined percentage of known island members within the timer interval, the island head node determines the proper time to transition to common reference time and sends a confirmation message to corresponding member nodes.

0017When island member nodes receive the confirmation messages, the node local network time may be updated to common reference time in response to proper conditions. If acknowledgement messages are received from less than a predefined percentage of member nodes, the island head node retransmits a transition request message and repeats the negotiation for a predefined number of trials (e.g., typically three times). When the negotiation is not successful and the pulling interval is still large, the island head node delays by a random back-off interval and restarts the process again. In the case where some nodes do not transition to the common reference time (e.g. GPS time), these nodes become Isolated and attempt to synchronize with the existing networks. The present invention technique may control degradation of the existing communication links based on the predefined value of the response percentage.

0018Once the network time transitions to the common reference time, the problem of network time merge is resolved since the ultimate goal of the time-of-day synchronization is to have all network times be based upon the common reference time. If the network time cannot transition to the common reference time (for any reason), the clock drift rate must be estimated and compensated when the local clock is updated without hearing from neighboring nodes with the common reference based time (e.g. GPS based time). Although the clock drift rate does not change significantly, the rate may cause fragmentation when a node cannot hear from neighboring nodes with GPS based time for several minutes.

0019The above and still further objects, features and advantages of the present invention will become apparent upon consideration of the following detailed description of specific embodiments thereof, particularly when taken in conjunction with the accompanying drawings wherein like reference numerals in the various figures are utilized to designate like components.

BRIEF DESCRIPTION OF THE DRAWINGS

0020<dl id="dl0001" compact="compact"><dt>Fig. 1A</dt><dd>is a diagrammatic illustration of an exemplary time-of-day synchronization waveform transmitted by a network node in an Isolated state in order to join the network.</dd><dt>Fig. 1 B</dt><dd>is a diagrammatic illustration of an exemplary time-of-day synchronization waveform transmitted by a network node in an Associated state after joining the network.</dd><dt>Fig. 2A</dt><dd>is a diagrammatic illustration of network nodes according to the present invention arranged in an exemplary communication network.</dd><dt>Fig. 2B</dt><dd>is a block diagram of a network node of Fig. 2A.</dd><dt>Figs. 3A - 3B</dt><dd>are a procedural flow chart illustrating the manner in which time-of-day synchronization messages are transmitted by a network node in accordance with the time-of-day synchronization of the present invention.</dd><dt>Figs. 4A - 4B</dt><dd>are a procedural flow chart illustrating the manner in which time-of-day synchronization messages are received and processed by a network node in accordance with the time-of-day synchronization of the present invention.</dd><dt>Figs. 5A - 5C</dt><dd>are a procedural flow chart illustrating the manner in which a network node maintains an Associated status with other network nodes in accordance with the time-of-day synchronization of the present invention.</dd><dt>Fig. 6</dt><dd>is a diagrammatic illustration of an exemplary communication network with network nodes arranged in a single tier.</dd><dt>Fig. 7</dt><dd>is a graphical plot illustrating the performance of the flywheel technique within the network of Fig. 6.</dd><dt>Figs. 8A - 8B</dt><dd>are graphical plots illustrating the performance of the time-of-day synchronization according to the present invention within the network of Fig. 6.</dd><dt>Fig. 9</dt><dd>is a diagrammatic illustration of an exemplary communication network with network nodes arranged in plural tiers.</dd><dt>Fig. 10</dt><dd>is a graphical plot illustrating the performance of the flywheel technique within the network of Fig. 9.</dd><dt>Figs. 11A- 11B</dt><dd>are graphical plots illustrating the performance of the time-of-day synchronization according to the present invention within the network of Fig. 9.</dd><dt>Fig. 12</dt><dd>is a diagrammatic illustration of an exemplary communication network with network nodes arranged in a plurality of fragmented networks.</dd><dt>Figs. 13A - 13B</dt><dd>are graphical plots illustrating the performance of the flywheel technique within the network of Fig. 12.</dd><dt>Figs. 14A- 14B</dt><dd>are graphical plots illustrating the performance of the time-of-day synchronization according to the present invention within the network of Fig. 12.</dd></dl>

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

0021Initially, network nodes must typically establish a common network time before communications can commence due to severe timing constraints imposed by the particular network. This is accomplished by a time-of-day (TOD) synchronization protocol. If a network node or unit with local Global Positioning System (GPS) time as the common reference time is present, the aggregate network time ("net time" or non-GPS based time) must be slowly pulled towards the GPS time in order to facilitate multi-tier operation.

0022In particular, a conventional time-of-day synchronization protocol for a Small Unit Operation (SUO) type network includes an Isolated node devoting resources to discovering and synchronizing time with RF neighboring nodes. The Isolated node issues Late Net Entry (LNE) signals at a high rate and periodically monitors an LNE channel for LNE messages from other network nodes. LNE signals are transmitted on the highest frequency channel available to the radio. The LNE signal uses a fixed code division multiple access (CDMA) spreading code and a fixed transmission security (TRANSEC) from the current key fill.

0023An Associated node issues LNE signals at a low rate. Since all Associated nodes issue LNE messages independently, an Isolated node quickly detects an LNE signal despite transmission of those messages at a low rate. Once an LNE message is detected, the Isolated node synchronizes with the Associated nodes. After a node completes the time-of-day synchronization, Packet Radio Organizational Packets (PROP) messages are transmitted to identify other RF neighboring nodes for establishing bi-directional communications. These messages are basically used to discover new RF neighboring nodes and exchange information for automatic transmission power (ATP) calculations.

0024Time-of-day message transmission waveforms are illustrated, by way of example only, in Figs. 1A - 1 B. Specifically, a synchronization waveform 102 includes a plurality of epochs, each including a series of Time Division Multiple Access (TDMA) time slots 105. The time slots contain desired information for transmission and/or reception. The epochs are continuously transmitted and referenced herein as even epoch 103 and odd epoch 104. An odd epoch 103 is transmitted after a predetermined delay (e.g., TODXmtDelay as viewed in Figs. 1A - 1 B) from the transmission of an even epoch 102. Similarly, an even epoch 102 is transmitted after a predetermined delay (e.g., TODXmtReat as viewed in Figs. 1A - 1 B) from the transmission of an odd epoch 103. Thus, the even and odd epochs are continuously transmitted in an interleaved fashion.

0025An Isolated network node attempts to discover neighbors by listening for LNE and RTS (request-to-send) transmissions from neighboring nodes. During Isolated status, PROP messages (e.g., S1 as viewed in Fig. 1A) and LNE messages (e.g., S2 as viewed in Figs. 1A - 1 B) are selected randomly in order to minimize the possibility of other nodes being able to intercept local node transmissions and to avoid collision. An exemplary synchronization waveform for an Isolated node transmitting PROP and LNE messages is illustrated in Fig. 1A. Since the RTS and LNE signals use different spreading codes and frequencies, the Isolated node transceiver is typically assigned to listen for one of these signals, while an auxiliary receiver listens for the other. However, in a battery powered or portable system, the use of two receiving devices consumes significant power. Typically, the auxiliary receiver in an Isolated node is placed into a standby mode to conserve power, while the transceiver alternately switches between the frequencies and codes used for LNE and RTS messages. Since the transmitting node sends an LNE and an RTS message in both even and odd epochs, the transceiver detects the new RF neighboring node (e.g., even if the epoch counters of the two nodes are out of phase with each other).

0026The neighbor discovery process continues until the Isolated node becomes Associated with its RF neighboring nodes. In this case, the newly Associated node transmits the LNE message (without the PROP message) in even and odd epochs 103, 104 (e.g., message S2) as illustrated in Fig. 1 B.

0027The conventional time-of-day synchronization described above leads to a fragmented communications network, where one group of network nodes may be synchronized to one time-of-day while another group of network nodes may be synchronized to a different time-of-day. Further, synchronized nodes are constantly losing and regaining connectivity within a tactical or ad-hoc wireless environment. In order to accommodate these conditions, the flywheel technique described above enables nodes to continue to predict, and therefore track, the movement of the network time as adjusted by neighboring nodes. However, the flywheel technique may need a long pulling period to transition network nodes to GPS time. This may be undesirable for the tactical or ad-hoc wireless environment. Accordingly, the present invention time-of-day synchronization provides network nodes with rapid transition to GPS time in the tactical or ad-hoc wireless environment.

0028An exemplary network architecture that may be employed by the present invention is a multi-hop wireless ad-hoc network. This type of network does not include an infrastructure (e.g., there is no base station as in a cellular network, where a single-hop environment of a cellular network becomes a special case) and may be utilized in a hostile network environment (e.g., a tactical battlefield, etc.) with unfriendly jamming. An exemplary SUO type wireless ad-hoc network including network nodes according to the present invention is illustrated in Fig. 2A. Specifically, a wireless network 100 includes a plurality of nodes 14 arranged in islands 18. Each island is in the form of a flat multi-hop network and includes corresponding island member nodes 14 with one of those member nodes designated as an island head node 15. These island arrangements form a first tier of network 100 and facilitate communication within an island between the island head and member nodes and between the member nodes themselves. The head nodes of each island are in communication with each other and form a backbone network 16. The backbone network essentially forms a second tier of network 100 and facilitates communications between nodes of different islands (e.g., generally providing communications over greater distances). For example, a node 14A from a first island desires to transmit a message to node 14B of a second island. Node 14A transmits the message to a corresponding head node 15A of the first island that utilizes the second tier of network 100 to forward the message to a head node 15B of the second island. Head node 15B subsequently forwards the received message to destination node 14B. Alternatively, nodes 14 may be arranged to form a network including a single or any quantity of tiers.

0029A network node 14 according to the present invention is illustrated in Fig. 2B. Specifically, node 14 includes a transceiver or receive/transmit unit 22, a modem 24, a processor 26 and an optional GPS receiver 34. The processor is preferably implemented by a conventional microprocessor or controller and controls the node for transmission and reception of messages and time-of-day synchronization in accordance with the present invention as described below. Transceiver 22 is preferably implemented by a conventional transceiver (e.g., transmitter and receiver) that transmits and receives messages, preferably in the form of radio frequency (RF) signals, in accordance with processor instructions. The transceiver is coupled to an antenna 36 to transfer signals with the surrounding environment. Modem 24 is preferably implemented by a conventional modem and transfers signals between the transceiver and processor.

0030GPS receiver 34 may be implemented by any conventional or other GPS or satellite receiver and obtains GPS time from GPS satellites via a GPS antenna 38. The GPS receiver may alternatively be a separate unit and coupled to node 14. The GPS receiver typically resides within a single network node to provide GPS time for the network; however, any quantity of nodes may include the GPS receiver and provide the GPS time.

0031Processor 26 includes a time management unit 28 and a local clock generator 32. These units may be implemented by individual, or any combination of, software and/or hardware (e.g., circuitry, logic, processors, etc.) modules or units. The local clock generator generates a reference time that may be adjusted or updated by time management unit 28 to produce a node local time-of-day. The local time-of-day may be sent to transceiver 22 via modem 24 and transmitted onto the network through antenna 36. Conversely, transceiver 22 may receive messages from neighboring nodes via antenna 36. The received messages may include a time-of-day of a neighboring node and other information as described below. The received messages are provided to time management unit 28 via modem 24.

0032Time management unit 28 utilizes the GPS-based time from GPS receiver 34, the local time-of-day from clock generator 32 and the time-of-day received from a neighboring node to update or adjust the node local time-of-day in accordance with the present invention time-of-day synchronization as described below. The time management unit may include a counter 30 to determine an integer value corresponding to a quantity of update values for synchronization of the node time-of-day to the GPS-based time as described below. The counter may store an integer count value that may be set to a specific value or adjusted (e.g., incremented or decremented by any value). The processor may further include a memory unit (not shown) to store the integer count value and other parameters. A head node 15 is substantially similar to node 14 described above.

0033Initially, the link layer of the communications protocol within network nodes sends and receives Packet Radio Organizational Packets (PROP) messages to discover and learn basic facts about neighboring nodes. This information is used to begin formation of a network. A node neighbor table includes various information (e.g., island size, island ID, partition ID, Community of Interest (COI), Distance to Island Head, Remaining battery power, Node type, GPS status, GPS relays, Remaining Pulling Interval to GPS time, flywheel status, time offset to GPS time, etc.) that is preferably utilized by an island head node to determine the appropriate time to cease pulling of the network time and immediately transition to GPS time without significantly disturbing the communication links of the existing network.

0034The island manager or head node for network formation is responsible for controlling the time-of-day synchronization operation and utilizes commands sent via the link layer of the node communications protocol. When a new command (e.g., a Begin_TOD_Sync() command) is received on a network tier, a new synchronization procedure is initialized on the tier indicated within the received command. Once the time-of-day synchronization is completed in the network, the network formation process commences and is based on neighboring node data obtained by the link layer initiating the neighbor discovery process (e.g., transmission of PROP messages). In particular, once time-of-day synchronization has been performed, network nodes begin to exchange PROP messages to discover new RF neighboring nodes for establishing bi-directional communication. The PROP messages are broadcast packets for local node information change, periodic discovery and inquiry. The PROP messages include node status information (e.g., island size, island ID, partition ID, Community of Interest (COI), Distance to Island Head, Remaining battery power, Node type, GPS status, GPS relays, Remaining Pulling Interval to GPS time, flywheel status, time offset to GPS time, etc.) as described above. The island head node may determine the proper time for the transition to GPS time to enable all network nodes or members (if possible) to reach common GPS time.

0035Different time-of-day synchronization modes may be available for an operator to select for satisfying specific operational requirements. The modes include a flywheel mode, a flywheel/jump mode and a manual mode. The flywheel mode is described in the aforementioned published patent application, while the flywheel/jump mode corresponds to the time-of-day synchronization of the present invention described below. Manual mode disables automatic time-of-day synchronization updates.

0036The present invention time-of-day (TOD) synchronization is performed by each network node. By way of example only, the present invention synchronization is described with respect to an exemplary SUO type network; however, the synchronization may be applied to any suitable networks. The synchronization of the present invention includes each network node formatting and transmitting time-of-day messages to another network node, and receiving time-of-day messages for predicting and updating the node internal local clock. The manner in which a network node (e.g., via processor 26) transmits a time-of-day synchronization message according to the present invention is illustrated in Figs. 3A - 3B. Specifically, the node initially determines the node status as Isolated or Associated with other nodes in the network at step 302. If the node is in an Associated state, the node transmits an LNE packet at step 306 in response to time-of-day information not being ready as determined at step 303 and the process returns to step 302 to be repeated. When the time-of-day information data is ready, the node resets the LNE packet for the last TDMA time slot within the next even epoch (e.g., message S2 within Fig. 1 B) at step 304 and collects the time-of-day information (e.g., node ID (node identification), island ID (network identification), local clock (local time-of-day of node), number of hops away from a node having GPS-based time, the number of updates to GPS time, etc.) from neighboring nodes at step 307 (Fig. 3B). Each node computes the minimum number of hops away from a GPS node (NhopsAwayGpsCount) continuously when the node receives time-of-day information from neighboring nodes. A node with local GPS time sets the hop count (NhopsAwayGpsCount) to be zero, and each node receiving the relayed GPS-based time information increases or increments this count before relaying the count to a neighboring node.

0037When an island head node receives a non-zero update count (NumUpdatesToGpsTimeCount described below) from an island member node, the head node determines the feasibility of transitioning to GPS time without disturbing the communication link. In particular, if the node is an island head node as determined at step 322, the node determines a score value (JumpToGpsScore) at step 323 that is utilized for indicating proper conditions to transition to GPS time. The score value may be determined as follows. <maths id="math0001" num=""><math display="block"><mi>JumpToGpsScore</mi><mo>=</mo><mfenced separators=""><mi mathvariant="normal">k</mi><mo>⁢</mo><mn>1</mn><mo>*</mo><mfenced><mi>island size</mi></mfenced></mfenced><mo>+</mo><mfenced separators=""><mi mathvariant="normal">k</mi><mo>⁢</mo><mn>2</mn><mo>*</mo><mi>NumUpdatesToGpsTimeCount</mi></mfenced></math><img file="EP1901458A2_D0001.tif" /></maths> where k1 and k2 are predefined weight factors and NumUpdatesToGpsTimeCount is determined from a time offset between local GPS time of a node and the network time received by that node within an LNE message as described below.

0038The island head node compares the resulting score value to a threshold (JumpToGpsThreshold) at step 324. If the score value is greater than the threshold, the island head node initiates a negotiation process to transition to GPS time. In particular, once the score value indicates a transition, the island head node initializes a trial counter (Num Trial) at step 325 and sends a transition request message to island members at step 326. The island head node further starts a transition timer (JumpToGpsTimeWait) at step 327 and waits for expiration of an associated time interval (T_wait). When a member node receives the transition request message, the node replies with an acknowledgement (ACK) message back to the island head node. Once the time interval expires, the island head node determines the quantity of received acknowledgement messages. If acknowledgements are received from more than a predefined percentage of member nodes (JumpResponsePercentage) as determined at step 328, the island head node determines the transition time or count (JumpToGpsTimeCount) for switching to GPS time at step 329. The transition time or count may be determined as follows. <maths id="math0002" num=""><math display="block"><mi>JumpToGpsTimeCount</mi><mo mathvariant="normal">=</mo><mi>NumUpdatesToGpsTimeCount</mi><mo mathvariant="normal">-</mo><mi>FixedNumUpdates</mi><mo mathvariant="normal">-</mo><mi>PrioJump</mi><mo mathvariant="normal">-</mo><mi>Interger</mi><mfenced separators=""><msub><mi mathvariant="normal">T</mi><mi>Wait</mi></msub><mo mathvariant="normal">/</mo><mi mathvariant="normal">Δ</mi><mo>⁢</mo><msub><mi mathvariant="normal">T</mi><mi>max</mi></msub></mfenced></math><img file="EP1901458A2_D0002.tif" /></maths> where NumUpdatesToGpsTimeCount is determined from the time offset between local GPS time of a node and the network time received by that node within an LNE message as described below, FixedNumUpdatesPrioJump is the amount of updates required prior to a GPS transition as described below to enable network nodes several hops away to receive a transmission and become synchronized, T_Wait is the transition timer interval and ΔT_max is the update interval as described below.

0039A transition confirmation message (e.g., time-of-day information including the transition count and other data) is transmitted to the member nodes at step 330. When the island member nodes receive the confirmation messages, the node network time may be updated to GPS time in response to proper conditions as described below (Figs. 5A - 5C).

0040Since transmissions may take several hops to be received by all network nodes, the network time is pulled for several clock time updates (FixedNumUpdatesPrioJump) to enable the network nodes to be synchronized by the update count (NumUpdatesToGPSTimeCount) prior to transitioning to GPS time. Accordingly, the head node floods the time-of-day information (including the transition time or count) after a fixed quantity of clock time updates (FixedNumUpdatesPrioJump). By way of example only, the default value for this parameter (FixedNumUpdatesPrioJump) is set to three since the average hop count in an island is approximately three hops.

0041If acknowledgements are received by the island head node within the transition timer interval from less than the predefined percentage of member nodes, the island head node retransmits the transition requests for a predefined number of trials (MaxNumTrials) (e.g., usually three times) as determined at steps 333, 334. If the negotiation is not successful and the pulling interval is still large as determined at step 335, the island head node delays by a random back-off interval (T_backoff) at step 336 and restarts this process again. In case some nodes do not transition to GPS time, the nodes become Isolated and retry to synchronize with existing networks. The degradation of existing communications may be regulated by controlling the value of the predefined percentage of island members acknowledging the transition request.

0042When the score value is less than or equal to the threshold as determined at step 324, the process terminates. For example, when an island includes a small quantity of members or the update count is low, the island head node may decide to permit nodes to continue pulling by periodic local clock updates as described below (without immediate transition to GPS time). The synchronization technique of the present invention may regulate sensitivity toward transitioning to GPS time by controlling the value of the predefined weights (e.g., k1 and k2) and/or the threshold value (JumpToGpsThreshold).

0043When the node is not a head node as determined at step 322, the node waits for a transition request message from a corresponding island head node at step 331 and transmits an acknowledgement in response to receiving that message at step 332. The above process is repeated while the node maintains an Associated state.

0044If the node is in an Isolated state as determined at step 302 (Fig. 3A), the node further determines the presence of GPS-based time at step 305. When an Isolated node has GPS-based time, the node sets the node local clock time to GPS-based time and transmits PROP and LNE signals (e.g., Fig. 1A). If this node does not attain an Associated status in a predetermined time interval (e.g., remains in an Isolated state), the node listens for LNE signals from RF neighboring nodes as described below. In particular, when the node has GPS-based time as determined at step 305, the node checks for newly available GPS time at step 308. When a new GPS time is available, the local clock of the node is updated to GPS-based time at step 311. Regardless of the availability of a new GPS time, the node transmits PROP and LNE packets at step 313 (Fig. 1A). A wait time (IN_SYNC_TIME) for a timer is set at step 314 after transmission of the packets at step 313, or in response to an In Sync node state as determined at step 302. The node status is examined after the timer interval. If the node attains an Associated state as determined at step 317, the node status is set to Associated at step 320. However, when the node status remains as Isolated or In Sync after expiration of the timer as determined at step 317, the node status is set to Isolated at step 321. The above process returns to step 302 and is repeated.

0045When the node lacks GPS-based time, the node does not transmit LNE signals until a specified waiting interval expires. In particular, when the node lacks GPS based time as determined at step 305, the node local clock is set manually at step 309 and the node sets a wait time (WAIT_LNE_XMT_TIME) for a timer at step 312 and transmits an LNE packet at step 318 after expiration of the timer. However, the node receives RF neighboring node LNE signals and sets the node local clock with the time received in the LNE packet at step 315. The node further sets the node status as In Sync at step 319. The process returns to step 302 to be repeated.

0046The manner in which a network node (e.g., via processor 26) receives and processes time-of-day synchronization messages according to the present invention is illustrated in Figs. 4A - 4B. Specifically, the node identifies the type of message received at step 404. The message is typically received from a neighboring node. If the received message is a PROP or data type message (e.g., confirmation message from a head node for transitioning to GPS time, time-of-day information from a neighboring node, etc.), the node determines the time-of-day node status at step 405. If the node status is Isolated or In Sync, the node retrieves the time-of-day information from the message or packet at step 407. After examining the received message, the node declares the status of the node as Associated at step 410. If the node has an Associated status as determined at step 405, the time-of-day information is read at step 413. The neighboring node time-of-day information (e.g., node ID (node identification), island ID (network identification), local clock (local time-of-day of neighboring node), number of hops away from a node having GPS-based time, the number of updates to GPS time, count to the GPS transition) within the message is collected at step 415.

0047The node examines an update count (NumUpdatesToGpsTimeCount described below) received from the neighboring node at step 418. An update count greater than zero indicates that a node in the network has GPS-based time and is gradually attempting to pull the network non-GPS based time-of-day toward the GPS-based time. An update count equal to zero indicates that there is no pulling activity in the network. A positive value of the update count may be replaced and the sign of the value added to the time-of-day information. When the initial non-zero value of the update count (NumUpdatesToGpsTimeCount) is received in a node from a neighboring node, that value becomes the update count in the receiving node. The value of the update count is decremented at the receiving node as described below (Figs. 5A - 5C) and transmitted in the time-of-day information to another network node (Figs. 3A - 3B). In other words, when an initial non-zero value of the update count is received by a node from neighboring nodes, the initially received value becomes the update count in that node. Once a node local clock time is updated by the maximum clock update value (Δt_max described below), the update count (NumUpdatesToGpsTimeCount) is decremented and transmitted to neighboring nodes as described below (Figs. 5A - 5C). Specifically, if the update count is greater than zero (e.g., indicating pulling activity in the network) as determined at step 418, the node sets the update count value of the node to the received update count value at step 419 in response to the reception being an initial reception of the count as determined at step 417. The node subsequently performs time-of-day maintenance at step 420 as described below. When the update count has a value of zero (e.g., indicating no pulling activity in the network) as determined at step 418, the node performs time-of-day maintenance at step 420 as described below.

0048If the received message is an LNE type message as determined at step 404, the node determines the node time-of-day status at step 403. When the node has an In Sync or Associated status, the received time-of-day packet is ignored or discarded at step 402. However, when the node status is Isolated, and the node receives an LNE signal from another network node, the node local clock is synchronized with the time information contained in that signal. The Isolated node enters an In Sync state and starts to transmit PROP and LNE messages (Fig. 1A) without delays (TODXmitDelay or TODXmtRepeat). In particular, the Isolated node examines the time-of-day information in the received LNE packet at step 406. If the node lacks local GPS-based time as determined at step 408, the node local clock is set to the received neighboring node local clock at step 411 and the node status is declared as In Sync at step 414. The processing of the received message subsequently terminates at step 416. When the In Sync node subsequently receives PROP or data messages, the node becomes Associated and is ready to communicate with RF neighboring nodes as described above. The Associated node transmits LNE signals periodically (Fig. 1 B).

0049When an Isolated node with local GPS time tries to synchronize with the existing network time (e.g., non-GPS based time), the node sets the node local clock time with time-of-day information in the received LNE message in order to synchronize with the network immediately. The node subsequently determines the update count (NumUpdatesToGpsTimeCount) and adds this information to the time-of-day information in the synchronization. The number of updates to the GPS time (NumUpdatesToGpsTimeCount) is an integer-value determined by an Isolated node synchronizing with existing network time. This update parameter is determined from the time offset between local GPS time of a node and the network time received by that node within an LNE message. Since a round-off error (ε) arising within the determination of the update parameter (NumUpdatesToGpsTimeCount) as an integer value may cause fragmented networks at the transition to GPS time, the round-off error (ε) must be accounted for at the time of transition to the common GPS time. In particular, if the Isolated node has GPS-based time as determined at step 408, a pulling flag (RTC_flag) is set (e.g., to a value of one) at step 409. The pulling flag is set to indicate that the node with local GPS time has set the node local clock to the time-of-day received in an LNE message and intends to join the network as soon as possible and cause the local network time to synchronize to GPS-based time. If the pulling flag is set in a local node, the local node slowly pulls the network time to GPS-based time. Otherwise, neighboring node information is collected during a time window and the local node uses this information to update the node local clock. The local clock time, the number of hops away from a GPS node, an update count and other time-of-day information are transmitted in a communication packet to neighboring nodes as described above.

0050Once the pulling flag is set, the node determines an integer value of the update count (NumUpdatesToGpsTimeCount) including a corresponding value sign (e.g., positive or negative) at step 412. For example, a positive sign may indicate that the GPS-based time leads the received neighboring node local clock, while a negative sign may indicate that the GPS-based time lags the received neighboring node local clock. The update count is determined based on the following expression: <maths id="math0003" num=""><math display="block"><mi>NumUpdatesToGPSTimeCount</mi><mo mathvariant="normal">=</mo><mi>Integer</mi><mfenced open="{" close="}" separators=""><mfenced separators=""><msub><mi mathvariant="normal">t</mi><mi>GPS</mi></msub><mo mathvariant="normal">-</mo><msub><mi mathvariant="normal">t</mi><mi>RTC</mi></msub></mfenced><mo mathvariant="normal">/</mo><mi mathvariant="normal">Δ</mi><mo>⁢</mo><msub><mi mathvariant="normal">T</mi><mi>max</mi></msub></mfenced></math><img file="EP1901458A2_D0003.tif" /></maths> where t_GPS is the GPS (or real) time, t_RTC is the local clock time and Δt_max is the maximum value of local clock time that the node local clock may be updated without losing time-of-day synchronization with a neighboring node (e.g., 200 microseconds). The number of updates to the GPS time (NumUpdatesToGpsTimeCount) is an integer-value based on the time offset between local GPS time of the node and the network time received by that node within the LNE message. Once the update count value is determined, the node local clock is set to the receiving neighboring node local clock at step 411 and the node status is declared as In Sync at step 414. The processing of the received message subsequently terminates at step 416.

0051The manner in which a node maintains an Associated state according to the present invention is illustrated in Figs. 5A - 5C. Initially, when an update interval expires, the local clock time of a node (with or without GPS time) is updated by Δt_max until the update count (NumUpdatesToGpsTimeCount) becomes zero as described below. The update intervals are typically the same for all network nodes (e.g., one second, etc.). Specifically, neighbor information (e.g., update count, transition count, etc.) are initially collected at step 500 and the local clock time (T_rtc) of the node is ascertained at step 501. The node subsequently determines the presence of GPS time at step 502. If the node has GPS-based time, the node waits for an update timer to expire at step 504 (e.g., one-second update time interval). The update interval of the node with local GPS is preferably one-second since GPS sends the time information to the node at one second (1 PPS) intervals and the node is required to update the local clock upon availability of the GPS signal. The node determines an absolute value of the difference between the local clock time, t_RTC, and GPS time, t_GPS, (e.g., |t_GPS- t_RTC|) representing a delta time or offset at step 508.

0052If the delta time exceeds a maximum threshold value (e.g., 200 microseconds) as determined at step 512, the node updates the node local clock to GPS-based time at step 514 and resets the update count (NumUpdatesToGpsTimeCount) to zero at step 519. When the delta time is less than or equal to the maximum threshold value as determined at step 512, the update count (NumUpdatesToGpsTimeCount) is compared with the transition count (JumpToGpsTimeCount) at step 540. If the value of the update count (NumUpdatesToGpsTimeCount) is less than that of the transition count (JumpToGpsTimeCount) (e.g., indicating that the node will reach GPS time before the GPS transition time and, therefore, can immediately transition to GPS time without significantly affecting communications), the node local clock time is updated with the GPS time at step 514 as described above.

0053When value of the update count is greater than or equal to the value of the transition count (e.g., indicating that the node will not reach GPS time before the GPS transition time and, therefore, cannot immediately transition to GPS time without significantly affecting communications) as determined at step 540, the node compares the update count to zero at step 515. If the update count is not equal to zero (e.g., indicating the presence of pulling activity and that updates are to be performed), the node updates the node local clock by the maximum threshold value (e.g., by +/- the maximum threshold value, Δt_max) at step 516 and decrements the update count at step 517. When the update count (NumUpdatesToGpsTimeCount) is less than or equal to zero as determined at step 518, the update count is reset to zero at step 519 as described above. The node determines the next GPS update interval at step 520 subsequent resetting of the update count at step 519, or in response to the update count (NumUpdatesToGpsTimeCount) being greater than zero as determined at steps 515, 518.

0054Once the update interval is determined, the node subsequently compares the update count (NumUpdatesToGpsTimeCount) to zero at step 521. If the update count is not greater than zero and the node does not hear from other nodes after a predetermined time interval expires (e.g., ten seconds, etc.) as determined at step 522, the node resets the node time-of-day status to Isolated at step 524. The process terminates at step 523 after resetting of the node status at step 524, in response to the update count being greater than zero as determined at step 521, or in response to hearing from another node within the predetermined interval as determined at step 522.

0055If a node has no local GPS time and is ready to transition to GPS time, the remaining number of updates between the update count (NumUpdatesToGpsTimeCount) and transition count (JumpToGpsTimeCount), and the round-off error (ε) are used to reset the local clock time with GPS time. Once the local clock is reset, the value of the update count (NumUpdatesToGpsTimeCount) is set to zero to complete the process as described below. In particular, if the node does not have GPS-based time as determined at step 502, the node waits for a network time update timer to expire (e.g., a one second time interval) as determined at step 503. The nodes without GPS time preferably update node clocks at one second intervals similar to the updates for GPS based nodes. The one second update time interval (ΔT_max) is selected based on an optimum value determined from parameterizing the interval in a simulation.

0056Once the timer expires, the node compares the update count (NumUpdatesToGpsTimeCount) with the transition count (JumpToGpsTimeCount) at step 541. If the value of the update count (NumUpdatesToGpsTimeCount) is less than that of the transition count (JumpToGpsTimeCount) (e.g., indicating that the node will reach GPS time before the GPS transition time and, therefore, can immediately transition to GPS time without significantly affecting communications), the node local clock time is updated with the GPS time at step 542 and the update count is reset to zero at step 544.

0057When the value of the update count is greater than or equal to the value of the transition count (e.g., indicating that the node will not reach GPS time before the GPS transition time and, therefore, cannot immediately transition to GPS time without significantly affecting communications) as determined at step 541, the node compares the update count to zero at step 543. If the update count is not equal to zero (e.g., indicating the presence of pulling activity and that updates are to be performed), the node updates the node local clock by the maximum threshold value (e.g., by +/- the maximum threshold value, Δt_max) at step 511 and decrements the update count at step 525.

0058Once the update count is decremented, or in response to the update count being zero as determined at step 543, the node updates the node local clock to GPS-based time at step 527 in response to the GPS time being available from a node that is less than a predetermined maximum number of hops away (e.g., less than three hops away) as determined at step 526.

0059If the GPS-based time is not available as determined at step 526, the node checks for communications from an island head node at step 528. When the node has received a communication from the island head node, the node local clock is updated to the local clock time of the island head node at step 529. Otherwise, the node local clock is updated to the average network time among neighboring nodes at step 530. The node determines or increments the update timer (e.g., one second) at step 531 subsequent the local clock updates of steps 527 or 530.

0060When time-of-day information is received from neighboring nodes with GPS based time, a clock drift rate can be computed and averaged. The estimated clock drift rates are averaged over time and must be compensated or accounted for in the clock updates to avoid fragmented networks when a node cannot receive GPS based time during the updates. Accordingly, a clock drift rate is determined at step 545 subsequent determination of the update timer at step 531 to compensate the local clock. The drift rate is determined as follows. <maths id="math0004" num=""><math display="block"><msub><mi mathvariant="normal">t</mi><mi mathvariant="normal">i</mi></msub><mo>⁢</mo><mi mathvariant="normal">ʹ</mi><mo mathvariant="normal">=</mo><msub><mi mathvariant="normal">t</mi><mrow><mi mathvariant="normal">i</mi><mo mathvariant="normal">-</mo><mn mathvariant="normal">1</mn></mrow></msub><mo>⁢</mo><mi mathvariant="normal">ʹ</mi><mo mathvariant="normal">+</mo><mi mathvariant="normal">Δ</mi><mo>⁢</mo><msub><mi mathvariant="normal">T</mi><mi>max</mi></msub></math><img file="EP1901458A2_D0004.tif" /></maths><maths id="math0005" num=""><math display="block"><mi>Drift_Rate</mi><mo mathvariant="normal">=</mo><msub><mi mathvariant="normal">t</mi><mi mathvariant="normal">i</mi></msub><mo mathvariant="normal">-</mo><msub><mi mathvariant="normal">t</mi><mi mathvariant="normal">i</mi></msub><mo>⁢</mo><mi mathvariant="normal">ʹ</mi></math><img file="EP1901458A2_D0005.tif" /></maths> where t_i' and t_i-1' are the current and previous local clock time updates, t_i is the received GPS based time from neighboring nodes and ΔT_max is the update interval. The process subsequently terminates at step 523.

0061Ad-hoc networks use a synchronization scheme that allows synchronization between neighboring nodes located one-hop away from each other. Consequently, the rate at which the time spreads throughout the network is dependent on the number of nodes in the network and the capability for direct communication between the nodes.

0062In order to evaluate the time-of-day synchronization of the present invention in tactical ad-hoc networks, performance of the synchronization is described within three exemplary scenarios or network configurations including a single tier configuration (e.g., all nodes reside in the same tier), a two tier configuration (e.g., nodes reside in both first and second tiers) and a configuration with two fragmented networks. The fragmented network configuration illustrates the effectiveness of the synchronization for a merge. By way of example only, the tactical radios within the configurations are equipped with an imperfect hardware clock oscillator. The exact clock drift is difficult to predict since the drift depends on the tactical environment (e.g., temperature, pressure, power voltage, etc.). A typical value for clock drift rate is assumed to be +/- 10^-6, where the local clock drifts away from real-time by no more than one second in ten days. The maximum clock drift value of each node is selected randomly in +/- 3 part per million (ppm) increments.

0063An exemplary single tier configuration is illustrated in Fig. 6. Specifically, the configuration includes nodes 1 - 10 with nodes 2 - 10 arranged in a single tier. Node 1 includes GPS time and is accessible by node 2. Nodes 5 - 6 lose and regain connectivity with the network tier. The pulling of network time by the flywheel technique is illustrated in Fig. 7. The initial time offset of network time from the GPS time is 0.018134 seconds at a real time of 11.145 seconds. The time for the network time to lock to the GPS time is approximately 100 seconds.

0064The improvement achieved with the present invention synchronization is illustrated in Figs. 8A - 8B. The initial time offset of network time from the GPS time is 0.018133 seconds (a real time of 11.96314 seconds). An identical random seed was used to get an identical time offset at the beginning of an Associated status to show the effectiveness of the present invention synchronization. The time to reach the common GPS time with the flywheel technique is approximately 100 seconds. However, with respect to the present invention synchronization, the island head unit determines to transition to GPS time at thirty seconds and GPS time synchronization is accomplished at approximately forty-two seconds (Fig 8A). The network time may alternatively transition to the GPS time immediately after a predetermined quantity of updates (e.g., three updates) when the island head unit decides to transition based upon the network status. In this case, GPS time synchronization is accomplished at approximately eighteen seconds (Fig. 8B).

0065An exemplary two tier configuration is illustrated in Fig. 9. Specifically, the configuration includes nodes 1- 10 with nodes 2-10 arranged in two tiers. Nodes 2 - 7 reside within a first tier and nodes 8-10 reside within a second tier with node 8 designated as an island head unit. Node 1 includes GPS time and is accessible by node 2. The pulling of network time in the first and second tiers by the flywheel technique is illustrated in Fig. 10. The initial time offsets of network time from GPS time for the first and second tiers are approximately -0.00987 and -0.03319 seconds, respectively, at a real time of 11.145 seconds. The time for the network time of the first and second tiers to reach GPS time is approximately one-hundred sixty-four seconds and forty-eight seconds, respectively.

0066The improvement achieved with the present invention synchronization is illustrated in Figs. 11A - 11 B. The network times of both tiers reach the common GPS time at the same instant so that an island merge may be implemented. The island head node determines to transition to GPS time at thirty seconds and GPS time synchronization is accomplished at approximately forty-eight seconds for both tiers with the present invention (Fig 11A). The network time may alternatively transition to the GPS time immediately after a predetermined quantity of updates (e.g., three updates) when the island head node decides to transition based upon the network status. In this case, GPS time synchronization is accomplished for both tiers at approximately eighteen seconds (Fig. 11 B).

0067An exemplary configuration with fragmented networks is illustrated in Fig. 12. Specifically, the configuration includes nodes 1-10 arranged in fragmented networks. Nodes 2 - 5 reside within a first network and nodes 6 - 9 reside within a second network. Nodes 1 and 10 include GPS time and are accessible by the first and second networks, respectively. Nodes 5 - 6 lose and regain connectivity with their respective networks. The pulling of network time in the first and second networks by the flywheel technique is illustrated in Fig. 13A. The initial time offsets for the first and second networks between the network time and GPS time are approximately 0.005783 and 0.035455 seconds at real times of 11.360 seconds and 17.560 seconds, respectively. The time for the first and second networks to reach GPS time is approximately twenty-seven seconds and one-hundred seventy-five seconds, respectively.

0068The time offset during the roaming period of nodes 5 and 6 (e.g., from thirty seconds to eighty seconds) is illustrated in Fig. 13B. Node 5 attains an Isolated status at approximately 40 seconds, synchronizes with node 6, and stays with the second network time even after node 5 connects back with the first network. This indicates that nodes 5 and 6 stay time-synchronized after these nodes roam together. This problem is overcome by the present invention synchronization as described below.

0069The improvement achieved with the present invention synchronization is illustrated in Figs. 14A - 14B. The network time transitions to GPS time at approximately sixty seconds (Fig. 14A) immediately after attaining Associated status. Since the first and second networks are based upon common GPS time after the transition, a node within the first network can hear nodes in the second network once the nodes are within range. When two unconnected islands come within proximity of one another, some of the member nodes begin to establish inter-island RF neighbor relationships. The island head nodes of each island periodically evaluate the network topology, and if a potential merge condition is found, the merge operation is negotiated by the island head nodes of each island. Unless time synchronization is reached by the unconnected islands, the merge operation cannot commence. The present invention resolves the network time merge problem without an expensive hardware/software implementation. The network time may alternatively transition to the GPS time immediately after a predetermined quantity of updates (e.g., three updates) when the island heads decide to transition based upon the network status. In this case, GPS time synchronization is accomplished for both networks at approximately twenty seconds (Fig. 14B).

0070It is to be understood that the present invention is not limited to the specific applications or networks described herein (e.g., tactical (ground-based) ad-hoc wireless networks, etc.), but may be applied to military or other ad-hoc wireless networks including or associated with airborne, ship-based and/or mixed ground-based/airborne/ship-based network configurations. Further, the present invention may be applied to commercial ad-hoc WLAN (wireless LAN) networks deploying or anticipating deploying plural hops (e.g., emerging 802.11 LANs, Bluetooth networks for industrial, medical, mining, fire-fighting and residential applications, etc.).

0071It will be appreciated that the embodiments described above and illustrated in the drawings represent only a few of the many ways of implementing a method and apparatus for time-of-day synchronization between network nodes.

0072The communication networks employing the present invention nodes may include any quantity of those nodes or tiers. The network nodes may be arranged in any fashion into any quantity of islands each having any quantity of nodes. The backbone network may include any quantity of head nodes, while communications within an island and between neighboring head nodes of the backbone network may utilize the same or different transmission frequencies. The formation of islands and designation of head nodes may be predetermined or accomplished dynamically via any conventional or other algorithm or technique. The nodes may communicate via any suitable communications medium (e.g., wired or wireless communication devices, etc.).

0073The present invention node may include any quantity of conventional or other transmitters, receivers and/or transceivers, where each transmitter or transceiver may transmit signals at any suitable frequency and in any suitable energy form (e.g., radio signals, microwave, optical signals, etc.), and any quantity of conventional or other receivers or transceivers, where each receiver or transceiver may receive signals at any suitable frequency and in any suitable energy form (e.g., radio signals, microwave, optical signals, etc.). The present invention node may include any quantity of independent transmitting and/or receiving devices, and utilize any quantity of frequency channels of any desired frequencies to send voice and/or data. The present invention node may employ any conventional access scheme or protocol to access and/or transmit information on the data and/or voice channels. The present invention node may include any quantity of any conventional or other audio components (e.g., speaker, microphone, etc.) and associated circuitry or devices (e.g., coder, A/D or D/A converter, etc.) to process voice signals. The present invention node may further include any quantity of any types of input or control devices (e.g., buttons, switches, etc.) to enter voice or data and control node operation. The node may be in the form of any type of radio unit or other communications device.

0074The modem may be implemented by any quantity of any conventional modem or other suitable device to transfer signals between the transceiver and processor. The GPS receiver may be implemented by any conventional or other receiver to receive GPS or other signals. The node antennas (e.g., transceiver, GPS, etc.) may be implemented by any conventional or other antennas capable of receiving and/or transmitting the corresponding signals (e.g., messages, GPS signals, etc.). The processor of the present invention node may be implemented by any conventional or other microprocessor, controller or circuitry to perform the functions described herein, while any quantity of processors or processing devices or circuitry may be employed within the present invention node. The time management unit, local clock generator and counter may be implemented by any quantity of any combination of hardware and/or software units or modules. These devices may be within or coupled to the node processor. The local clock generator may provide any suitable clock signal or reference. The processor functions (e.g., including the time management unit, counter and local clock generator) may be distributed in any fashion among any quantity of hardware and/or software modules, processors or other processing devices or circuits. The software for the processor of the present invention node may be implemented in any suitable computer language, and could be developed by one of ordinary skill in the computer and/or programming arts based on the functional description contained herein and the flow charts illustrated in the drawings. Further, any references herein of software performing various functions generally refer to processors performing those functions under software control. The software and/or algorithms described above and illustrated in the flow charts may be modified in any manner that accomplishes the functions described herein. The present invention node may alternatively include any components arranged in any fashion to facilitate time-of-day synchronization within the network in the manner described above.

0075The time-of-day synchronization messages (e.g., LNE, PROP, time-of-day information, confirmation, acknowledgement, etc.) may be of any size, may have any format, and may contain any desired information. The packets or messages may be transmitted at any suitable transmission rate or in response to any desired conditions. The various messages or packets may include any identifier to identify the type of message or packet. The packets may be broadcasted or transmitted any quantity of times.

0076The synchronization waveforms may be of any quantity and include any quantity of time slots. The time slots may be reserved or assigned in any manner, where the waveform may be arranged in any fashion. The waveform may include any quantity of epochs that are transmitted at any desired or suitable time intervals. Information may be transmitted in either or both of even and odd epochs.

0077The various timers, delays and/or counters (e.g., status timer, wait timer, transition timer, update timer, etc.) may be implemented by any combination of hardware and/or software modules or units and may be configured to maintain any desired or suitable time intervals and/or counts. The score value may be based on any suitable parameters (e.g., island size, update counts, etc.) combined in any fashion (e.g., weighted, summed, averaged, etc.), where the weights for the score value may be set to any desired values to provide a suitable sensitivity for transitioning to GPS time. The negotiation may be performed for any quantity of trials. The score threshold and predefined percentage may be set to any suitable values for a particular application. The update and transition counts may be based on any suitable parameters (e.g., maximum threshold time, updates prior to transition, time intervals, etc.) combined in any fashion (e.g., weighted, summed, averaged, etc.).

0078The network may include any quantity of any suitable node states for determining appropriate actions. By way of example, the present invention has been described with respect to a SUO type network with corresponding node states; however, any suitable type of network and corresponding states may be employed with the present invention. Further, the transition to GPS time may be accomplished from any desired state or at any suitable time that does not significantly affect current communications.

0079The various parameters (e.g., number of updates prior to a transition, ΔT_max or the update interval, Δt_max or the maximum value of local clock time that a node local clock may be updated without losing time-of-day synchronization, maximum offset threshold, score threshold, percentage, number of trials, etc.) may be set to any suitable values for a particular application. The various flags (e.g., pulling, etc.) may be set and/or reset to any values to indicate corresponding conditions.

0080The various parameter names or labels are used herein by way of example and for descriptive purposes. The parameters may be associated with any desired labels or identifiers.

0081It is to be understood that the present invention is not limited to the applications or networks described herein, but may be utilized for various communication applications or networks, especially those including wireless ad-hoc radio networks.

0082From the foregoing description, it will be appreciated that the invention makes available a novel method and apparatus for time-of-day synchronization between network nodes, wherein a time-of-day synchronization (TOD) within wireless ad-hoc networks determines an appropriate time for network nodes to switch to a common GPS time without disruption of existing communication links.

0083Having described preferred embodiments of a new and improved method and apparatus for time-of-day synchronization between network nodes, it is believed that other modifications, variations and changes will be suggested to those skilled in the art in view of the teachings set forth herein.