Low duty cycle network controller

[0001] The present application claims priority to U.S. Provisional Patent Application No. 60/815,679, entitled, “Low Duty Cycle Network Controller” filed on Jun. 21, 2006, which is assigned to the assignee hereof and which is expressly incorporated herein by reference.

[0002] 1. Field

[0003] The present invention generally relates to the transmission of data over telecommunication networks, and to telecommunication devices that enable such transmission. More particularly, the invention concerns a new technique for maintaining synchronization with a telecommunication device in a half-duplex mode for a low duty cycle data transmission operation.

[0004] 2. Background

[0005] Remote monitoring of operations may involve remotely-situated, battery-operated, wireless telecommunication devices that capture operational status information and transmit via radio frequency signals the operational status information to a centrally-situated information-processing device. Oftentimes, the operational status information can be transmitted via radio frequency signals as short messages. In such remote monitoring and transmission applications, issues associated with power consumption management are an important concern.

[0006] In a typical operational environment, battery-operated monitoring and telecommunication devices are desirable to facilitate operating efficiency and to reduce maintenance costs. Implementation efficiency is improved because batteries obviate arrangements for an external power source and enable deployment of self-contained units that are easily installed at a variety of sites. Maintenance costs are reduced because the unit lacks dependence on external power sources and because a faulty unit is easily replaced by another. To optimize these advantages, it is most desirable for the monitoring and telecommunication device to operate for an extended period of time without requiring battery replacement or the like.

[0007] One way to extend the life of a battery is to reduce the load demanded of it. For example, a remotely-situated telecommunication device may be configured to operate according to a reduced duty cycle, where it is placed in a sleep or low-power operational mode when there are no ongoing communications with, for example, a centrally-situated information-processing device. This usually requires that a trade-off be made between the availability of the battery-powered telecommunication device for communications with the information-processing device and the amount of achievable reduction in power consumption. However, a remote telecommunication device employing such a power consumption saving technique may not be able to communicate optimally with a centrally-situated information-processing device because all or part of its communication circuitry is shut down when the device is in sleep mode to conserve battery power. That is, communication by the remote device is available only on an occasional basis.

[0008] There is therefore a need in the art for means of synchronizing the exchange of information between a remotely-situated monitoring and transmission device configured to operate according to a low duty cycle, and a centrally-situated information-processing device with which it is in communication.

[0009] In one aspect, a method of operating a low duty cycle (LDC) controller is disclosed. The method includes operating at least one low duty cycle (LDC) controller to maintain synchronization between the LDC controller and a plurality of LDC terminals operating over a communication network using only overhead channels of the network and conforming to the protocol and timing of the network, where the synchronization between the LDC controller and the plurality of LDC terminals is maintained separately from the protocol and timing of the communication network, and enables the LDC controller to schedule power down and wake up of the plurality of LDC terminals for durations longer than allowable under the protocol and timing of the communication network.

[0010] In another aspect, a low duty cycle (LDC) network system is disclosed. The system includes at least one LDC controller operating to maintain synchronization between the LDC controller and a plurality of LDC terminals operating over a communication network using only overhead channels of the network and conforming to the protocol and timing of the network, where the synchronization between the LDC controller and the plurality of LDC terminals is maintained separately from the protocol and timing of the communication network, and enables the LDC controller to schedule power down and wake up of the plurality of LDC terminals for durations longer than allowable under the protocol and timing of the communication network.

[0011] In another aspect, a tangible storage medium including a computer program for operating a network using at least one LDC controller is disclosed. The program comprises executable instructions that cause a computer to operate at least one low duty cycle (LDC) controller to maintain synchronization between the LDC controller and a plurality of LDC terminals operating over a communication network using only overhead channels of the network and conforming to the protocol and timing of the network, where the synchronization between the LDC controller and the plurality of LDC terminals is maintained separately from the protocol and timing of the communication network, and enables the LDC controller to schedule power down and wake up of the plurality of LDC terminals for durations longer than allowable under the protocol and timing of the communication network.

[0019] The nature, objectives, and advantages of the present invention will become more apparent to those skilled in the art after considering the following detailed description in connection with the accompanying drawings.

Introduction

[0020] In recognition of the above-stated problems associated with remote monitoring of operational status information and transmission of the information via radio frequency signals, the present disclosure describes several embodiments for controlling and synchronizing communications using only overhead channels of a telecommunication network (e.g., a cellular network such as a CDMA or GSM network) in a half-duplex mode. In particular, the operational status information is received by a controller hosted at a centrally-situated information-processing device, in messages transmitted in a half-duplex mode from a remotely-situated communication device configured to operate according to a low duty cycle (LDC).

[0021] In one implementation, the centrally-situated information-processing device at which a LDC controller is hosted is a processor located within or coupled to a CDMA network, such as a base station controller or other network controller, and the remote communication device is a wireless telecommunication device including capabilities for CDMA communication.

[0022] In another implementation, the overhead channels used in CDMA 2000 1× (First Evolution) include pilot, sync, and paging channels in the forward link and an access channel in the reverse link. The overhead channels used in CDMA 2000 1× EV-DO (First Evolution-Data Only) include pilot, sync, and control channels in the forward link and an access channel in the reverse link. In other implementations, the overhead channels include any non-traffic channels that provide reference, timing, system configuration, and access. In a CDMA application, traffic channels carry principal information such as two-way voice signals for providing telephone conversation.

[0023] The term “half-duplex mode” refers to a mode in which a communication device is permitted to act as either a transmitter or a receiver, but not both during the same communication period.

[0024] The term “low duty cycle” (LDC) refers to intermittent, occasional, and relatively low frequency of activity operation.

[0025] The term “terminal” refers generally to a substantially remotely-situated device, including a communication device.

[0026] The term “hibernate mode” refers to a mode of the communication device that places the communication device in a state of sleep and turns off all units in the communication device except for a timing device to keep track of the duration of the sleep. For LDC applications, the duration of the sleep is often substantially longer than allowable under the protocol of a conventional wireless communication network. For example, the duration of sleep is typically substantially longer than a CDMA slot cycle.

[0027] The term “idle mode” refers to a mode of the communication device where the device is awake for normal operations. For example, idle mode in a CDMA system includes slotted mode operation.

[0028] FIG. 1 illustrates how hibernate and idle modes of LDC operation relate to the slot cycles of a communication system. Such a communication system may, for example, be a CDMA-based system. Principal characteristics of LDC operation include an idle mode significantly shorter in duration than the hibernate mode, as shown at the top of FIG. 1. The close-up view of an idle mode period shows that it can be defined by a wakeup time 100 and a power down time 110. Alternatively, an idle mode may be defined by a wakeup time 100 and an idle mode duration 120. In one embodiment, the power down time 110 is dynamically adjusted according to the amount of information requiring transmission during idle mode. The close-up view further shows that a slot cycle of a CDMA system may be significantly shorter in duration than the LDC idle mode 120, shown for purposes of demonstration to span 5 slot cycles. The slot cycle essentially represents the wake/sleep cycle of a communication device under the protocol of the communication network, which under CDMA, for example, can range from 1.28 seconds (slot cycle 0) to 163.84 seconds (slot cycle 7). However, slot cycles of these durations are inappropriate for LDC purposes because a terminal's hibernate mode may extend from several minutes to a month or more, far longer than the maximum length slot cycle. Implementing a 1-month duty cycle, for example, by waking a battery-powered device every 163.84 seconds according to CDMA slot cycle 7 would cause battery depletion much sooner than waking only at the end of each 1-month cycle. Because (a) the sleep cycles provided by protocols such as CDMA that underlie existing communication infrastructures are inadequately short for the relatively long-term hibernations of LDC terminals, and (b) typical remotely-situated LDC terminals are hibernating most of the time and not accessible to the network facilitating communications, a mechanism is therefore required to synchronize communications between a centrally-situated information processing device and the terminals.

Low Duty Cycle Controller

[0029] The block diagram in FIG. 2 provides an overview of the relationships between a LDC controller 200 and a plurality of LDC terminals 230A-N with which the LDC controller 200 is tasked to maintain synchronization. As shown, communications are facilitated by a communications infrastructure 220, representing an existing system for communications including, for example, wireless telephonic voice communications. In one implementation, the communications infrastructure 220 is a CDMA system. The LDC controller 200 is a process or processor typically hosted by or co-located with a centrally-situated information processor performing as a component of the communications infrastructure 220. The information processor might be, for example, a base station, a server, or a call processing center. In one implementation, there is at least one LDC controller 200.

[0030] The LDC controller 200 formulates messages that are passed into the communications infrastructure 220 for delivery to one or more of the LDC terminals 230A-N. The LDC controller 200 receives messages formulated by LDC terminals 230A-N which are passed in the reverse direction through the communications infrastructure 220. In one implementation the messages thus received by the LDC controller 200 may include information regarding the position of a terminal 230A-N, its operating mode, its wake up time, and its wake up duration. In another implementation the messages transmitted by the LDC controller 200 include configuration information for a terminal 230. Messages from a LDC terminal 230 may be stored in memory 210, as may configuration information and messages downlinked externally and scheduled by the LDC controller 200 for transmission to the LDC terminal 230.

[0031] Synchronization is required between the LDC controller 200 and the terminals 230A-N because the relatively long hibernation intervals of the LDC terminals 230A-N make them inaccessible to the network underlying the communications infrastructure 220. A usage profile 240A depicted in FIG. 2 exhibits LDC operational parameters such as a wake up time 100, power down time 110, and an offset 250A from a timing reference. Similarly, the other usage profiles 240B, 240C as shown depict offsets 250B, 250C of different durations. Offsets will be discussed in more detail below. At wake up 100 the LDC terminal 230A enters idle mode. In one implementation using a CDMA communications system, activities performed by a LDC terminal 230 during idle mode include typical slotted mode operations such as listening to a paging channel, receiving messages, and sending messages. At power down 110 a terminal 230 A-N enters hibernation mode, during which time a LDC terminal 230A-N is substantially asleep, except for maintaining a timing reference, to minimize power drain on the battery. Communications between a LDC controller 200 and a LDC terminal 230 must therefore be synchronized so that they occur during the LDC terminal's 230 idle mode, and are not attempted during its hibernation. Advantages provided include those due to enabling synchronization of communications in a way that non-invasively overlays the protocols of the existing communications infrastructure.

[0032] FIG. 3 is a block diagram exemplifying a typical CDMA communications infrastructure 220. A category of channels called overhead channels 300 is shown separated from the traffic channels 310. Traffic channels 310 include the full-duplex channels used for voice communications, for example, and are typically assigned to individual users to carry all traffic. Overhead channels 300 include half-duplex forward link channels 320 and reverse link channels 330. The forward link channels 320 include pilot channels providing beacon functionality for initial system acquisition, sync channels for carrying system parameters required at system acquisition, and paging channels used to carry overhead messages, pages, setup messages, and orders. The reverse link channels 330 typically include access channels, use by a remote device to transmit registration requests, call setup requests, page responses, order responses, and other signally information required by system protocols.

[0033] One embodiment of the present invention provides for maintenance of synchronization by a LDC controller 200 with a plurality of LDC terminals 230A-N using the protocol and timing of the network underlying only the half-duplex communication channels. However, the scheduling inherent to the synchronization does not rely for its own timing on the protocols and timing of the network, and so is separate from those protocols and timing. Synchronization is essentially overlaid on the protocols needed to facilitate principal communications over the overhead channels 300.

[0034] For example, in one implementation, communications by a LDC controller 200 with LDC terminals 230 while the LDC terminals 230 are in idle mode conform in and of themselves to a CDMA slotted mode protocol. Whereas, the schedule implementing synchronization is defined substantially without reference to the timing inherent to the CDMA slotted mode protocol. That is, by further example, a configuration message including information regarding a wake up time 100 and a power down time 110 sent from a LDC controller 200 to a LDC terminal 230A is transmitted in conformance to the timing and protocol of the communications network, but the actual wake up and power down of the terminal 230A conforms to the information included in the message, not necessarily in conformance with the timing and protocol of the network that carried the message. Extended hibernation intervals of the LDC terminals 230A-N may thus be accommodated because the timing inherent to the protocols of the communications infrastructure 220 (e.g., CDMA slotted mode sleep) is not necessarily a factor in synchronization scheduling.

[0035] In one implementation, a LDC controller 200 provides configuration information to LDC terminals 230, where the information includes synchronization parameters defining a time window. Shown in FIG. 4 are four exemplary usage profiles assigned to four LDC terminals 230 identified as LDC terminals 1, 2, N−1 and N. The usage profile for LDC terminal 1 depicts two idle mode periods 400 and an intervening hibernation mode 405. The usage profile for LDC terminal 2 is substantially identical to that of LDC terminal 1 except for a time shift to the right. The usage profiles for LDC terminals 1 and 2 are overlaid by dashed lines 410, 420 indicating times T_BEGIN and T_END, respectively. T_BEGIN and T_END are configuration parameters provided by the LDC controller 200 which enable maintenance of a common timing reference between the LDC controller 200 and LDC terminals 230. More specifically, T_BEGIN and T_END bracket a period during which the LDC terminals 1 and 2 are to enter and leave idle mode 400. That is, the LDC controller 200 instructs a LDC terminal 230 to wake up at some time within the interval defined by T_BEGIN and T_END, and to be in hibernate mode at times exterior to that interval. Given the values T_BEGIN and T_END, wake up times 100 for LDC terminals 1 and 2 may be defined as offsets 430, 440, respectively, from T_BEGIN. Offsets 430, 440 are typically determined by a hashing process to distribute the wake up times 100 substantially evenly over the interval defined by T_BEGIN and T_END. Similar time windows for LDC terminals N−1 and N are defined by dashed lines 415, 425, respectively, within which offsets 450, 460 are hashed to define corresponding wake up times 100. In one implementation, hashing is performed by each LDC terminal 230A-N for itself. In another implementation, hashing is performed by the LDC controller 200 and the result communicated to the LDC terminal 230.

[0036] A LDC controller 200 thus provides parameters T_BEGIN and T_END to LDC terminals 1, 2, N−1 and N. LDC terminals 1 and 2 receive values defining a first window of time, and LDC terminals N−1 and N receive values defining a second window. Wake up times 100 are hashed for LDC terminals 1 and 2 in the form of offsets 430, 440 from T_BEGIN associated with the first window, and wake up times 100 for LDC terminals N−1 and N are hashed in the form of offsets 450, 460 from T_BEGIN associated with the second window. Messages transmitted by the LDC terminals 1, 2, N−1 and N to a LDC controller 200 are thereby substantially evenly distributed in time when received at the LDC controller 200 so as to prevent, for example, uneven loads on overhead channels 300 and at the LDC controller 200. In one implementation, the LDC controller is not advised of the power down times 110 of the LDC terminals 230A-N, where instead the LDC terminals 230A-N merely cease transmitting messages until the next wake up time 100 occurs.

[0037] A usage profile is substantially defined according to an operational mode required of a LDC terminal 230. For example, an operational mode accommodating periodic meter reading may define a usage profile in which a wake up time 100 is scheduled to occur once a month. Another example is an operational mode accommodating vehicle position reports from a LDC terminal 230, for which a usage profile scheduling wake up times 100 once per hour may be appropriate. Yet another example includes a so-called SOS mode, in which emergency position reports from a LDC terminal 230 coupled to a person may require a usage profile scheduling transmissions once every five minutes.

[0038] In one implementation, synchronization by a LDC controller 200 with a LDC terminal 230 involves a reachability state on the part of the LDC terminal 230. A state-machine depicting states of reachability is shown in FIG. 5. Initially 500, the LDC terminal 230 is unreachable 510. When a keep alive (KA) message 520 is received by the LDC controller 200 from the LDC terminal 230, a state of reachability 530 is established. The LDC controller 200 may therefore regard the LDC terminal 230 as being in idle mode, for example, indicating that subsequent communication may be commenced. Further KA messages 540 received by the LDC controller 200 from the LDC terminal 230 each maintain the reachable state 530. If a timeout 550 occurs, i.e., the LDC controller 200 fails to receive a KA message from the LDC terminal 230 before a predetermined amount of time has elapsed, the LDC controller 200 regards the LDC terminal 230 as unreachable 510. Thus, when regarded as unreachable by the LDC controller 200, an LDC terminal 230 may also be assumed, for example, to be in hibernate mode. Upon receiving a subsequent KA message 520 from the LDC terminal 230, the LDC terminal 200 regards the LDC terminal 230 as once again reachable 530.

[0039] In one implementation, when receiving a KA message from a LDC terminal 230, the LDC controller 200 marks the LDC terminal 230 as reachable and saves the current time as the last received KA message timestamp. If more than a predetermined time interval elapses without the LDC controller 200 receiving a subsequent KA message from the LDC terminal 230, or the LDC controller 200 fails to send messages to the LDC terminal 230 for some predetermined number of hibernation intervals, then the LDC controller 200 marks the LDC terminal 230 as unreachable. If the LDC controller 200 has marked the LDC terminal 230 as unreachable because of its failure to send messages to the LDC terminal 230 for some predetermined number of hibernation intervals, and the LDC controller 200 subsequently receives a KA message from the LDC terminal 230 thus marked as unreachable, the LDC controller 200 may send a configuration message to the LDC terminal 230 to reestablish synchronization.

[0040] In another implementation, usage profiles are distinguished between those that provide for wake up times 100 of a LDC terminal 230 at resolutions of less than one day, and those that provide wake up times 100 at resolutions of one day or greater. In the former case, synchronous scheduling is implemented, and in the latter case, asynchronous scheduling is used.

[0041] Synchronous scheduling 600 as used in one implementation is illustrated in FIG. 6. Shown are timelines for a LDC controller 200 and a LDC terminal 230. It will be appreciated that FIG. 6 depicts timelines for a single LDC controller 200 and a single LDC terminal 230, and that implementations of the present invention provide for at least one LDC controller 200 and a plurality of LDC terminals 230A-N. A wake up time 605 for the LDC terminal 230 based on T_BEGIN 510 has been hashed and is known to both the LDC controller 200 and the LDC terminal 230. The LDC controller 200 has received messages for the LDC terminal 230, which have been stored and sorted in memory 210 according to destination LDC terminal 230 and time of future transmission. At substantially wake up time 605 the LDC controller 200 sends 615 a message including any stored messages for the LDC terminal 230. The message is received 620 at the LDC terminal 230. A responsive message is received by the LDC controller 200, from the LDC terminal 230. Before power down time 610 is reached, the LDC controller 200 may receive 632 one or more messages from the LDC terminal 230. Such a message may be, for example, a KA message including information regarding operational status, battery status, network information, and a request for configuration data. In one implementation, after T_END occurs and the LDC terminal 230 is regarded as being in hibernate mode, the LDC controller 200 may select 640 pending messages for the LDC terminal 230 and schedule them for the next transmission time, coinciding with the next idle mode period of the LDC terminal 230. At substantially the next wake up time 642 the LDC controller sends 645 the pending messages to the LDC terminal 230, after which the LDC controller 200 receives 650 a message from the LDC terminal 230. The LDC controller 200 may continue to receive 632 further messages such as KA messages depending upon the amount of time left before the power down time 652. In another implementation, the power down time 610, 652 is dynamically adjusted according to the number and nature of the messages sent and received by the LDC controller 200. For example, if the number of pending messages is too large to be carried by a single message sent 615, 645 by the LDC controller 200, then only a portion will be sent 615, 645. Upon receiving 630, 650 a message from the LDC terminal 230, the LDC controller 200 may then reset and extend the power down time 610, 652. The LDC controller 200 may then send (not shown) a subsequent portion or the remainder of the pending messages in a similar manner to before. This process may be continued until all of the pending messages are sent by the LDC controller 200.

[0042] FIG. 7 illustrates asynchronous scheduling 700 as performed in one implementation in which a usage profile instructs wake up times 100 at a resolution greater than one day. The LDC controller 200 initially regards the LDC terminal 230 as unreachable. The LDC controller 200 does nothing with respect to the LDC terminal 230 until it receives 630 an unsolicited message sent by the LDC terminal 230 after its hashed wake up time 605. The LDC controller 200 formulates and sends 645 a message including any pending messages stored in memory 210 and scheduled for transmission. If the number of pending messages is too large to be included by the message sent by the LDC controller 200 to the LDC terminal 230, then upon receiving 632 another message from the LDC terminal 230, the LDC controller 200 responds by sending (not shown) a subsequent portion or the remainder of the pending messages in a similar manner to before. In an implementation of the present invention, the LDC controller 200 continues to receive 632 messages from the LDC terminal 230 until substantially the power down time 610. Such messages may include KA messages as discussed in relation to synchronous scheduling illustrated in FIG. 6. In another implementation, the power down time 610, 652 is dynamically adjusted according to the number and nature of the messages sent and received by the LDC controller 200. For example, if the number of pending messages is too large to be carried by a single message sent 645, 665 by the LDC controller 200, then only a portion will be sent 615, 645. Upon receiving 632 a message from the LDC terminal 230, the LDC controller 200 may reset and extend the power down time 610, 652 until which the LDC terminal 230 will remain in idle mode. The LDC controller 200 may then send a subsequent portion or the remainder of the pending messages in a similar manner to before. The process is continued until all of the pending messages are sent by the LDC controller 200. At substantially the next wake up time 642 the LDC controller again receives 660 an unsolicited message from the LDC terminal 230.

Applications

[0043] Implementations of LDC controller operation described above can be used in many different applications including asset tracking, automated meter reading, cashless payment of parking meters, traffic lights and sensors, billboards and public displays, real-time health monitoring, home/office security and alarm systems, automotive telematics, utility distribution grid monitoring, position monitoring using GPS, and other related polling applications. Message transmission for these applications can range from an average of one short messaging service (SMS) message per hour for an asset tracking application to one SMS message per month for an automated meter reading application.

[0044] Those of skill in the art understand that information and signals may be represented using any of a variety of different technologies and techniques. For example, data, instructions, commands, information, signals, bits, symbols, and chips that may be referenced throughout the above description may be represented by voltages, currents, electromagnetic waves, magnetic fields or particles, optical fields or particles, or any combination thereof.

[0045] Those of skill further appreciate that the various illustrative logical blocks, modules, circuits, and algorithm steps described in connection with the embodiments disclosed herein may be implemented as electronic hardware, computer software, or combinations of both. To clearly illustrate this interchangeability of hardware and software, various illustrative components, blocks, modules, circuits, and steps have been described above generally in terms of their functionality. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the overall system. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present invention.

[0046] The various illustrative logical blocks, modules, and circuits described in connection with the embodiments disclosed herein may be implemented or performed with a general purpose processor, a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein. A general-purpose processor may be a microprocessor, but in the alternative, the processor may be any conventional processor, controller, microcontroller, or state machine. A processor may also be implemented as a combination of computing devices, e.g., a combination of a DSP and a microprocessor, a plurality of microprocessors, one or more microprocessors in conjunction with a DSP core, or any other such configuration.

[0047] The steps of a method described in connection with the embodiments disclosed herein may be embodied directly in hardware, in a software module executed by a processor, or in a combination of the two. A software module may reside in RAM memory, flash memory, ROM memory, EPROM memory, EEPROM memory, registers, hard disk, a removable disk, a CD-ROM, or any other form of storage medium known in the art. An exemplary storage medium is coupled to the processor such that the processor can read information from, and write information to, the storage medium. In the alternative, the storage medium may be integral to the processor. The processor and the storage medium may reside in an ASIC.

[0048] Moreover, the previous description of the disclosed embodiments is provided to enable any person skilled in the art to make or use the present invention. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other embodiments without departing from the spirit or scope of the invention. Thus, the present invention is not intended to be limited to the embodiments shown herein but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.