GB2455771A

GB2455771A - Data collection system employing a network of sensor nodes

Info

Publication number: GB2455771A
Application number: GB0724927A
Authority: GB
Inventors: Timothy Bauge; Chiang Kang Tan; Richard Egan
Original assignee: Thales Holdings UK PLC
Current assignee: Thales Holdings UK PLC
Priority date: 2007-12-20
Filing date: 2007-12-20
Publication date: 2009-06-24
Anticipated expiration: 2027-12-20
Also published as: GB2455771B; GB0724927D0

Abstract

Sensor nodes (32,34,36) are adapted to change their duty cycles when they detect an event and transmit, by way of a duty cycle notification protocol, requests to neighboring nodes to influence their duty cycles. The sensor nodes in the network can modify their own duty cycle between a plurality of values dependent on the timing of the event, the location in an area where the event is detected and the requests they receive from neighboring nodes.

Description

1 2455771 Method and system for communication employing a node network The present invention relates to a method of communication and to a communication system employing a network of nodes, more particularly, but not exclusively, to a sensor node network.

Sensor node networks can be viewed as a group of devices, each with a limited computing and communication capability, located over a predefined area. Dependent on the application the network of devices can collect data associated with a wide variety of physical or enviroimiental conditions. For example, typically the sensors, can monitor sound, pressure, temperature, vibration, motion or pollutants, at different locations over a given area. Sensor networks can find applications in healthcare, home automation, traffic control and security. In addition to monitoring the above parameters the network can integrate the collected data andlor answer queries related to the data.

Each sensor device in the network defines a node of the network, and in the instance of wireless sensor nodes (WSN) each sensor device typically has a radio transceiver, a small microprocessor and an energy source such as a battery. One of the critical operational requirements for such nodes is conservation of energy as their energy source is typically a battery, and it may be unacceptable to require the battery to be changed on a periodic basis (weekly or monthly for example), due to their sheer number, or to the inaccessibility of their location. This means that energy is a finite resource which is generally unlikely to be subsequently replenished. In order to achieve a meaningful life expectancy for deployment of sensor nodes, the energy must be preserved. To accomplish this objective various strategies may be employed, for example, by switching off parts of the device when such actions will lead to energy savings (power down I power up energy costs must be offset, etc).

Referring to Figure 1 there is shown a schematic representation of a generic sensor node architecture identified by numeral 20. A "MCU" (Micro Controller Unit) block 22 serves as the overall controller of the device, linking all the other blocks together and providing the nodes management functions as well as running the application. A "sensors" block 24 contains the actual sensors attached to the node. A "Comms Radio" block 26 contains the communication capabilities of the device, which will typically be a low-power radio. A "Peripherals" block 28 contains all other optional functionality, which in the context of timing and synchronisation is mainly external time sources such as GPS or radio clock receivers.

All the components within the sensor node architecture 20 shown in Figure 1 are chosen to be as energy efficient as possible, and to preserve energy the components in the sensor node architecture 20 may be duty cycled. The leading consumer of energy within the system is typically the communications radio block 26. As devices are not permanently communicating (in fact they may communicate quite infrequently), the radio should be duty cycled to preserve energy. This requires synchronisation across the network to ensure that neighbouring nodes switch on their radios at the same time, and therefore must trade-off energy with the cost of maintaining appropriate levels of clock precision. The complexity rises if the synchronisation is provided by the network (by employing a network synchronisation protocol), as the synchronisation is both required by, and dependent on the communications radio's duty cycling. An additional trade-off in duty cycling the communications radio is linked to the network communication latency. The longer a device's radio is allowed to sleep, the longer it may take to communicate with it. Considering the case of a multi-hop network, for example, this delay is multiplied by the number of hops, which may rapidly cause an unacceptable latency through the network.

Usually, this trade-off with the communication radio block 26 and any trade offs associated with the sensor block 24, MCU block 22 and peripherals 28 are set once and for all for a particular system, which is suitable for highly predictable sensing applications. This approach is however limiting when considering applications which have varying operating characteristics over time, such as scenarios where no activity is detected for long periods, followed by short periods of heavy activity requiring distributed processing as a stimulus travels through the sensor field.

Accordingly, the invention strives to overcome the disadvantages described above by optimising the energy consumption in such scenarios by providing a framework to enable dynamic control of duty cycles to achieve particular trade-offs of energy, clock precision, and network latency.

According to one aspect of the invention there is provided a method of communication within a node network, each node having a plurality of operating states wherein an event detected within the network causes one or more nodes to adopt a given state, said one or more nodes communicating with one or more other nodes causing said one or more other nodes to adopt related states, for a period of time or until explicitly requested otherwise.

Each of the states operates at a respective duty cycle rate, the duty cycle rates being different for each of the operating states. The transition of a node between different operating states is dependent on the desired operation duty cycle rate for the node, which can be either from a higher duty cycle rate to a lower duty cycle rate or from a lower duty cycle rate to a higher duty cycle rate.

In one embodiment each node having at least two operating states comprising a first state and a second state, and initially all said nodes being in the second state, wherein an event detected within the network causes one or more nodes to adopt the first state, said one or more nodes in said first state communicating with one or more other nodes causing said one or more other nodes to also adopt the first state.

Each of the first and second states of node operation have respective first and second duty cycles, the first duty cycle operating on higher rate than the second duty cycle.

In one embodiment each node has a third state of operation, and initially all said nodes being in the third state, wherein an event detected within the network causes one or more nodes to adopt the first state, said one or more nodes in said first state communicating with one or more other nodes causing said one or more other nodes to also adopt the first or the second state.

The third state of node operation has a third duty cycle, said third duty cycle rate being lower than both the first and second duty cycle rates.

The nodes may be sensor nodes which together define a sensor node network.

In one embodiment the nodes are sensor nodes operable between two states, the first state is an active state and the second state is an idle state, the nodes initially in idle state, a sensing stimulus detected within the network causing one or more nodes within the neighbourhood of the detected stimulus to enter their active state, the active nodes communicating with one or more other nodes causing them to also enter active state.

In a further embodiment each sensor node has three operating states including an active state, a standby state and an idle state, all nodes initially in idle state, a sensing stimulus detected within the network causing one or more nodes within the neighbourhood of the stimulus to adopt the active state, said one or more active nodes communicating with one or more other nodes causing them to enter the active state, said one or more active nodes communicating with one or more further nodes causing them to enter the standby state.

The duty cycle rate of the active state is higher than the duty cycle rate of the standby state which is higher than the duty cycle rate of the idle state. The duty cycle schedules of all levels are synchronised to have periodic coinciding times when communications between nodes operating on different duty cycles is possible.

In one embodiment an initiating node is adapted to receive a stimulus setting its duty cycle and initiate a duty cycle notification protocol (DCCN) comprising a REQUEST message for broadcasting to neighbouring nodes, the REQUEST message containing information about the associated duty cycling rate to be applied to the neighbouring nodes. For example, nodes in a standby state may be promoted to an active state, which nodes may then return to their previous standby state or an idle state after the event has past.

The REQUEST message may contain information about the radii of zones around the initiating node within the network, the nodes within the zones having associated duty cycles andlor information about one or more node paths for the data to be conveyed through the network from the initiating node to one or more remote nodes.

In another aspect of the invention there is provided a method of detecting an event comprising deploying a sensor node network in an area where the event may occur, and adapting the sensor nodes in the network to modify their duty cycle between a plurality of values dependent on the timing of the event and the location in the area where the event is detected.

In a further aspect of the invention there is provided a sensor node for use in a sensor node network, the sensor node comprising an energy source, a sensor, a processor and a duty cycle controller, the duty cycle controller being operable to change the duty cycle when its sensor detects an event and to transmit a signal to neighbouring nodes in the network to influence their duty cycle.

In a yet further aspect of the invention there is provided a communication system comprising a control unit for receiving communication data from a node network, each node having a plurality of operating states wherein an event detected within the network causes one or more nodes to adopt a given state, said one or more nodes communicating with one or more other nodes causing said one or more other nodes to adopt related states for a period of time or until explicitly requested otherwise.

In one embodiment each node in the network has two operating states comprising a first state and a second state, and where nodes are initially in the second state, wherein an event detected within the network causes one or more nodes to adopt the first state, said one or more nodes in said first state communicating with one or more other nodes causing said one or more other nodes to adopt the first state.

In another embodiment of the system each sensor node has three operating states including an active state, a standby state and an idle state, all nodes initially in the idle state, a sensing stimulus detected within the network causing one or more nodes within the neighbourhood of the stimulus to adopt the active state, said one or thore active nodes communicating with one or more other nodes causing them to enter the active state, said one or more active nodes communicating with one or more further nodes causing them to enter the standby state.

In a further embodiment the system comprises a plurality of sensor nodes, each node including a power source and a sensor for producing observation data indicating a quantity being measured, a wireless interface for sending the observation data from the sensor to neighbouring nodes within the network and at least one consumer of sensor node output or proxy thereof such as a gateway to other networks such as, but not limited to the Internet.

In yet a further aspect of the invention there is provided a sensor node network comprising a plurality of nodes, each having an energy source and a sensor for producing observation data indicating a parameter being monitored, each node having a plurality of operating states wherein an event detected within the network causes one or more nodes to adopt a given state, said one or more nodes communicating with one or more other nodes causing said one or more other nodes to adopt related states, for a period of time or until explicitly requested otherwise.

In one embodiment of the net-work, each node has two operating states comprising a first state and a second state, all nodes initially in second state, wherein the parameter or event detected within the network causes one or more nodes to adopt the first state, said one or more nodes in said first state communicating with one or more other nodes causing said one or more other nodes to adopt the first state.

Each node must have a duty cycle control mechanism to determine their duty cycle in response to a signal received either from the sensing of a stimulus or from a signal received from another neighbouring node. A neighbouring node within the context of this specification refers to a node which is in direct communication to its neighbour without the need to communicate through another node. Typically a number of nodes will be in direct wireless contact with each other so defining a group of neighbouring nodes.

In one embodiment an initiating node receives a stimulus setting its duty cycle and initiates a duty cycle notification protocol (DCCN) comprising a REQUEST packet broadcast to all neighbouring nodes, the REQUEST packet containing information about the associated duty cycling rate to be applied to the neighbouring nodes. The REQUEST packet may also contain information about the radii of zones, each of the nodes in a neighbouring group of nodes within each zone having a respective duty cycle. The duty cycle notification protocol (DCCN)) may also include a CANCEL message for broadcasting to neighbouring nodes to cancel a previous REQUEST message.

Further embodiments of the method, system, network and DCCN protocol are defined within the appended claims.

The invention will now be described in greater detail with reference to the accompanying figures, in which: Figure 1 is a schematic diagram illustrating the architecture of a sensor node; Figure 2 is a diagram showing several predefined duty cycles for a node network in accordance with one embodiment of the invention; Figure 3 is a sensor node network in accordance with an embodiment of the invention; Figure 4 is an event diagram illustrating a zone notification procedure for the node network of Figure 3; Figure 5 is an event diagram illustrating an operation during a path alert procedure in the node network of Figure 3; Figure 6 illustrates a REQUEST message format of a protocol used in accordance with one embodiment of the invention; Figure 7 illustrates a CANCEL message format of the protocol used in accordance with the invention; Figure 8 is a session header format of the protocol of Figures 6 and 7; Figure 9 illustrates an interfaces link to DCC operation in the control plane and Figure 10 illustrates an interfaces link relevant to DCC operation in the data plane.

In the following description, specific implementations of the invention are described. It will be appreciated by the reader that these are provided by way of example only, and are not intended to provide restriction or limitation on the scope of the invention which is defined in the appended claims.

The system described below relates to a duty cycle control approach which is tailored to, and tightly integrated with the duty cycling of the sensor nodes. It is characterised by its flexible and dynamic trade-off between energy saving and communication delay, and is in the main targeted at medium to large deployment, multi-hop sensor networks.

In the embodiment described below multi-level duty cycling is employed -this is shown in Figure 2 which illustrates three predefined duty cycles, thereby allowing different duty cycles to be used at different times for any given node. The rationale behind doing this is to allow communications to be able to take place more frequently, using a higher duty cycle, when needed. This has the advantage of reducing communication delay. Furthermore, each duty cycle level maintains the wake times of the level below it, and adds its own wake times to the pattern. This ensures that neighbouring nodes operating on different duty cycling levels can always communicate using the lowest common level. Clearly the system would benefit from link reliability mechanisms as neighbouring nodes may not always be awake at the same time if they are operating on different duty cycling rates.

Although Figure 2 shows three different duty cycle rates, other embodiments of the invention may make use of more than three different duty cycles rates. Furthermore, an embodiment can be employed in which only two different duty cycle rates are employed.

The method is rate adaptive in that nodes only return to a sleep state if they consider their task accomplished in the short term. This means that although the rising edges of pulses shown in Figure 2, will always be periodically distributed, the falling edges will depend on the level of activity. This enables a greater degree of flexibility in the utilisation of resources so that nodes can be highly available when required, and only wake up for very short periods of time (long enough to detect whether or not a neighbour is attempting to communicate).

It is envisaged that at some point certain areas covered by the sensor nodes require more intensive monitoring compared to the rest. For example, with reference to the scenario depicted in Figure 3, a few sensor nodes sense something happening around the grey area 30. In a large sensor field, there is no real need for every node to participate even if a true alarm is sensed, apart from those close to the stimulus where tasks such as distributed local processing for example needs to be done. Even when there are a couple of gateway nodes 38, only nodes along the path from the source to the gateway nodes 38 need to be employed in relaying the reporting data. The embodiment shown in Figure 3 uses both zone and path scope control to the sensor nodes with multi-level duty cycling. The advantage of this is sensor nodes do not need to operate in just one rate of duty cycle throughout the network. The sensor nodes close to the stimulus, i.e. within an active zone 32, and those on one or more reporting paths 40 between the active zone 32 and the gateway nodes 38 (referred to as active nodes in Figure 3) can operate at the highest duty cycle available, providing high availability to participate in distributed operations. Sensor nodes that are remote from any distributed tasks need not participate, such as nodes 36, can continue to operate at the lowest duty cycle. As for the nodes 34, which are located in the standby zone in Figure 3, they are put on standby mode, i.e. operating at medium duty cycle, so that they can be called upon for action with less delay when needed. Scoping is performed in a distributed fashion within the network, and is application driven.

A duty cycled multi-hop network synchronised for communication is established, employing multi-level duty cycling. This can be approached one of two ways. Either a dedicated distributed synchronisation approach is enforced solely focussed on duty-cycling, or higher layer synchronisation is exploited to align the duty cycling schedules.

The benefits of the latter are particularly attractive if the application requires this synchronisation, as the duty-cycling does not incur any additional synchronisation cost.

The system employed operates the multi-level duty-cycling by overlaying schedules, which allows all nodes to be able to communicate on the lowest cycle regardless of their current state.

Clock drift is an unavoidable phenomenon that can unsettle the timing of the duty cycles. A combination of suitable preamble length and time synchronisation mechanisms is used to combat the clock drift problem.

fri the event of losing synchronisation, a backup state is designed to ensure that nodes can resume communication with others within the maximum acceptable time.

The sensor node platform is assumed to provide a suitable synchronisation mechanism.

A radio clock could provide a suitable solution to this requirement, based on a suitable duty cycles operation to provide minimum energy consumption to achieve the required accuracy for the system clock. The device is further required to have a multi-rate duty cycling features in the link layer. Furthermore, the application running on the nodes must be able to signal its requirements to the duty cycle control mechanism, mainly in terms of the session profile of the connection it is establishing, and the scope of required local collaboration (and hence communication).

The scenarios, which will benefit most, from the proposed mechanism are those which monitor rare, but long lived incidents. The approach may incur a high delay during the "wake-up" phase, but allows low latency communication once it is established, and very low energy consumption between incidents. Moreover, it is assumed that nodes need to collaborate locally in order to provide added value services. Examples of such collaboration range from distributed processing to tasking of neighbouring sensors to supplementlconfirm locally sensed information. Finally, groups of nodes will provide the results of their collaboration through consolidated reports sent to the network's gateways and/or other consumers of such information in the network. The implications are that there will be a small number of communication paths between the zone surrounding a stimulus (where all the local collaborative processing is being done) and the information consumers.

The network may typically spend most of its time in the idle state. This means that no stimulus is present, and that the only activity within the network is related to maintenance and management. During this phase, the main concern is to save as much energy as possible. All devices should therefore be on the low duty cycle, like that shown in Figure 2, allowing the longest possible sleep time acceptable to the scenario.

A number of factors must be taken into account to determine the rate of the low duty cycle. Firstly one must consider synchronisation decay, for example local clock drift, will place limitations on how long one can allow the device to sleep. If one were to consider all devices to have a radio clock, then no synchronisation is required over the network. Secondly, there is the issue of contact latency, namely the longer the device sleeps, the longer it may take to initially contact it (i.e. wait for it to become awake).

The length of the duty cycle should therefore consider how long the application can afford to wait to communicate with a neighbour. Once contact has been made, the neighbouring device can be asked to reduce its duty cycling rate, reducing the delay for further communication.

When the device senses a stimulus which it must analyse, the application may decide if it requires collaboration with neighbouring nodes in order to gather more information and/or share processing tasks. As all devices are at this stage in idle state, the local device will establish two zones around itself -the nodes in the inner zone (called the active zone) will be required to be in a state of high availability (high duty cycle) while the nodes in the outer zone (called the standby zone) will be required to be in a state of medium availability (median duty cycle). The process by which this is achieved is described below.

Referring to Figure 4, there is illustrated an event diagram summarising the zone notification procedure, in this example each zone is one hop in diameter. This means that the inner zone (high availability) is made up of all the neighbouring nodes, while the standby zone is made up of all the two hop neighbours. The diameter of each zone is set dynamically by the application.

The diagram in Figure 4 represents three nodes, in a one hop per zone example. Under the scenario described above, an application 42 in the initiating node receives notification from its sensors of an event of interest. It foresees the need for collaboration in the future, and decides to place itself and its neighbours in the collaboration state. To achieve this, the application 42 signals, by way of signal 1, a duty cycle control mechanism 44, informing it of the diameter of the active and standby zones, as well as the required duty rates which should be used in each zone. Beyond the standby zone, an idle state will be maintained. The duty cycle control mechanism first sets its own link layer duty cycle to the requested rate, by way of transmitting a signal 2 to the medium Access control (MAC) 48, and initiates a duty cycle control notification protocol (DCCN). This causes a REQUEST packet, signal 3, to be broadcast to all neighbouring nodes at the next common wake time, which contains information about the radius of the zones and their associated duty cycling rate. The message also contains the ID of the initiating node, a request ID and a time to live (TTL) field. Each neighbour receives this packet, signal 4, and processes it to identify how far away it is from the initiating node (time to live field). This allows it to determine which zone it is in and hence which duty cycle rates to apply. The duty cycle control functionality stores the information from the REQUEST message in order to identify subsequent associated requests. It then sets the duty cycle rates in its own link layer, signal 5. From the zone diameter information and the time to live field, it is able to determine that it is not on the outer perimeter of layer to zone, and must therefore rebroadcast the REQUEST message. The duty cycle control mechanism 44 therefore updates the message's time to live field, and rebroadcasts the message to its neighbours on their next common wake time, signal 6. This procedure will be repeated by each node until the outer boundary of the standby zone is reached, signal 7. The duty cycle control mechanism 44 in this node establishes that it is on the standby zone's outer boundary, and therefore does not rebroadcast the message. It does however set its own link layer's duty cycling rate to the appropriate value, signal 8, after storing the REQUEST message information.

The description above considers a single request (i.e. a single REQUEST message). It is likely that when the stimulus appears in a sensor field, more than one node will detect it.

As these are likely to be neighbouring nodes, it will be common for multiple zones to overlap. Some nodes may find themselves to be in the active zone for one initiating node, and in the standby zone for another, or in the same zone but on different rates for two different initiating nodes.

These conflicts are resolved by applying a rule that the rate to be applied is the highest requested. As all REQUEST messages are stored, new requests or cancellations lead to a fresh assessment of what the currently highest requested rate is to be.

While one requires neighbouring nodes to be available for collaborative analysis of the stimulus, one also needs to be able to return to the idle state once the incident is passed.

To achieve this embodiments of the invention make use of a combination of two methods.

The. first method is to employ a REQUEST timeout. In this method REQUEST messages which request for use a higher duty cycle rate than the idle default contain an optional timeout value. If this value is not present, an implementation specific default value is used. In either case, a node may return to its idle state if it has not been solicited by any of its neighbours for the timeout period. The decision to return to the idle state is also dependent on the application, which may have reasons of its own for maintaining a high state of availability.

The second method is to employ a CANCEL message. An explicit request to cancel a previous REQUEST message can be issued by using the CANCEL message. This message contains the source node and REQUEST request ID so that recipient nodes can match the CANCEL to the stored REQUEST message.

In both of these methods, the timeout or removal of a REQUEST message causes the duty cycle control mechanism to re-evaluate the duty cycle rates it is supposed to be using based on the remaining REQUEST messages it has stored. Eventually, once the stimulus has passed, all nodes will progressively return to an idle state.

The functionality described above allows nodes to proactively establish a low latency communication zone around themselves in order to facilitate local collaboration between devices. However, if this group of collaborating nodes needs to export data, alarms, or any form of report, they will find that the path between themselves and the Gateway node is mainly made up of nodes which are operating on a low duty cycle (idle node). One therefore requires to define the communication notification procedure, which allows a node to set up a low latency path to a remote device, and this will described hereinbelow.

When an application needs to send data to a remote node, a route will be established through the network. Although the path can be of any length, the embodiment described considers a 2-hop paths length. Given the fact that in idle mode, the devices are only on very infrequently, communication may initially be very slow. If the application only has one message to send, it has no choice but to incur that latency. If however the application has a stream of data to send, it can use the communication notification procedure to signal all nodes on the path to switch to a high availability state, to reduce the latency of subsequent transmissions. This procedure is shown in Figure 5, which is an event diagram showing the operation during a path alert.

In Figure 5, the application is assumed to have a stTeam of data to send. It sends the data to the communication stack (1) through a dedicated interface which allows it to specify session information. This session information is communicated by the network layer to the duty cycle control component (2), and includes a session identifier, a timeout value, and an indication of the duty cycle level required on the path. This information is included in a set of fields which have been added to the standard network header. The duty cycle control (DCC) mechanism then sets the link layer's duty cycle to the requested level (3), and stores the information relative to the session. At the forwarding node, the network layer processes the session information in the packet headers, and informs the local duty cycle control mechanism of the requested duty cycle level (4).

The duty cycle control component sets the duty cycling level in the link layer (5), stores the session information, and forwards the data packet according to the rule of the network protocols. At the destination node, the same procedure takes place: the session information is retrieved by the network layer and sent to the duty cycle control mechanism (6), which stores information and sets the duty cycle to the appropriate level (7). The packet is sent up to the application (8).

Although this initial packet will have experienced a high latency through. the network (the devices are in idle mode as it reaches them), subsequent packets will enjoy a much lower latency. It should be noted that no dedicated control messages were used for this procedure.

For scenarios where the network topology is likely to fluctuate, routes may change on a regular basis. The method therefore provides an optional feature, which is beneficial if combined with a suitable choice for the routing protocol. Nodes may implement a snooping approach, whereby they parse all messages which appear on the channel regardless of their link layer destination address. If this is implemented, nodes which are neighbours to the communication route can also process the session headers. They then store the session state in the duty cycle control component, which sets the link layer's duty cycle of the local node to an intermediate level (higher than idle, up to that requested by the session). In the event of the route breaking, the nodes surrounding the original route will form a high availability corridor to facilitate a rapid establishment of the new route.

In the description above, we have considered a unique session. In practice any given node may be on the path of multiple sessions, which each request a different level of duty cycling. In the event that this happens, the duty cycling level should be set to the highest requested level. As sessions come and go, the duty cycling level should be determined in each node by analysing the state stored in all the currently active sessions.

As subsequent data packets flow from source to destination over the path, the state in the duty cycle control at each node is updated. In particular, if the route changes, some existing intermediate nodes may find they are no longer on the path, while new intermediate nodes find they are solicited. Each time a data packet is received by the network layer, the session headers must be passed to the duty cycle control so that timers can be refreshed for existing sessions, and a new state established (and duty cycle rate set) for new sessions.

The communication notification procedure uses a soft timeout approach, as routes may change. Each session has an associated timeout value, which must be larger than the maximum inter packet delay for the session. In each node along the path (including source and destination node), the duty cycle control mechanism will revert back to an idle state if it has not received the data message from the session within the timeout period. Clearly the application may not always be able to set the timeout value precisely, in which case it attempts a reasonable trade-off between the energy cost of maintaining a high duty cycle and the latency incurred by transmitting data over idle state paths.

Above are described mechanisms for setting node duty cycling rates in a distributed manner. Nodes may find themselves requested to set their duty cycling to different settings by different mechanisms. These conflicts can always be resolved by setting the duty cycle level to the highest request, as the different levels are aligned (meaning that the wake-up pattern for level N+ 1 is the pattern of level N with added wake-ups).

The Duty Cycle Control Notification Protocol (DCCN) will now be described. As referred to above REQUEST and CANCEL are the message types defined by DCCN.

These message types are received via the network and network header processing applies. So, for instance, the requesting node is expected to use its network address as the Originator identifier for the messages. To broadcast messages, which is the method suitable for disseminating the messages, network broadcast address is used. However, the messages need to be disseminated widely in the network. The range of dissemination is determined by the Time to Live (TTL) field in the message (if a TTL field is already present in the network header, this TTL field can be used instead).

The DCCN protocol is only invoked when there is a request to either put nodes into collaborative state or to cancel a REQUEST message. When there is one of these requests, for instance the former, a REQUEST message is broadcast by the originating node. When a neighbour receives the REQUEST message, it will decrement the TTL value and compare the value with the standby zone radius to work out which zone it belongs to. If the TTL is greater than zero, the node will rebroadcast the REQUEST message.

CANCEL message is used when the originating node wants to explicitly cancel the previous REQUEST message, to get the nodes back to idle state (depending on what other requests the node is subject to). Similar to the above REQUEST operation, a CANCEL message is broadcast by the originating node. And the message is rebroadcast until TTL reaches zero.

DCCN is a duty cycle control protocol, and it deals with duty cycle rate management.

DCCN keeps the following states in the DCCN table for each entry of REQUEST request: o Originator identifier o Request identifier o Active zone width o Standby zone width o Active zone rate o Standby zone rate o Lifetime o Application identifier (at the originating node) Maintaining entries for these states ensure that when one of them is cancelled, either via a CANCEL message or by timeout, the correct duty cycling rate is used based on remaining constraints.

DCCN Terminology Definitions broadcast Broadcasting means transmitting to the MAC protocol's broadcast address. A broadcast is only a single hop (although the receiver may decide to forward the packet further based on it's routing decision), but broadcasting is useful to enable dissemination of DCCN messages widely in the network originating node A node that initiates a DCCN REQUEST or CANCEL message to be processed and retransmitted by other nodes in the network.

DCCN messages DCCN messages refer to REQUEST and CANCEL messages.

REQUEST requirements The REQUEST requirements consist of the active zone width, standby zone width, active zone rate, standby zone rate and duration that are requested by the application.

Message format The REQUEST message format is shown in Figure 6, and contains the following fields:

Field Description

Originator Contains the network address of the originator of the REQUEST identifier message.

Request identifier A number uniquely identifying the particular REQUEST message when taken in conjunction with the originator identifier.

Standby zone width The number of hops between the outer standby zone and the outer active zone.

Active zone rate Duty cycle rate to be used for the active zone, represented by a number (0 -15) matching a predefined duty cycle rate.

Standby zone rate Duty cycle rate to be used for the standby zone, represented by a number (0-15) matching a predefined duty cycle rate.

Time To Live The initial value of this TTL field is set to the radius of the standby zone. It is decremented every time the message is received by a node. When TTL reaches zero, the message is no longer rebroadcast.

Duration Contains the duration for the duty cycle rate change. This field is optional and will not be included in the REQUEST message if it is not used.

Table 1: Fields description of the REQUEST message.

The CANCEL message format is shown in Figure 7, and contains the following

fields:

Field Description

Request identifier Contains the request identifier of the previous REQUEST message that this CANCEL message is trying to cancel.

Reserved Sent as 0; ignored on reception.

Table 2: Fields description of the CANCEL message.

DCCN Operation This section describes the scenarios under which nodes generate REQUEST and CANCEL messages to be disseminated in the network, and how the messages are handled. In order to process the messages correctly, certain state information has to be maintained in the DCCN table entries for the destinations involved.

Generating REQUEST message A node disseminates a REQUEST message when it is requested by the DCC. The originator identifier is set to the network address of the node. The request identifier field is incremented by one from the last request identifier used by the current node. The standby zone width, active zone rate, standby zone rate and duration fields are set according to the values provided by the application. The TTL' field is set to the sum of the active zone width and the standby zone width. It is the maximum number of hops the REQUEST message will propagate in the network. If the network layer has its own TTL field, that TTL field can be used instead, thus saving a byte on the message.

If the node is currently in idle state, the DCC is notified the requested duty cycle rate change, to active zone rate. If the node is currently not in idle state, the requested REQUEST requirements are compared with the current operating REQUEST requirements. If the current operating REQUEST requirements are more stringent than the requested REQUEST requirements, or equally stringent, no REQUEST message is broadcast. Otherwise, a duty cycle rate change request to the requested active zone rate is made to the DCC and the REQUEST message is broadcast.

Before broadcasting the REQUEST message, the originating node buffers the request identifier and the originator identifier in a new entry in the DCCN table for a period equal to the duration value. The purpose of this is two fold. Firstly, these identifiers need to be stored to allow later cancellation of the duty cycle rate change by a CANCEL message. Secondly, when the node receives the REQUEST message again from its neighbours, it will not reprocess and rebroadcast the message. Other fields that form the REQUEST requirements, such as the active zone width, standby zone width, active zone rate, standby zone rate and duration are also buffered in the same entry in the DCCN table. Lastly, the application identifier is buffered to track the application that has initiated a REQUEST message.

Generating CANCEL message A node disseminates a CANCEL message when it is requested by the DCC. The originator identifier is set to the network address of the node. The request identifier field is set to the request identifier used by the previous REQUEST message that this CANCEL message is trying to cancel. The TTL field is set to the sum of the active zone width and standby zone width, which are stored in the DCCN table. It is the maximum number of hops the CANCEL message will propagate in the network. Lastly, the application identifier is buffered to track the application that has initiated a CANCEL message.

Before broadcasting the CANCEL message, the originating node buffers the request identifier and the originator identifier for DISSEMINATION TIME. In this way, when the node receives the message again from its neighbours, it will not reprocess and rebroadcast the message.

Controlling dissemination of D CCN messages To prevent unnecessary dissemination of DCCN messages to nodes that are not involved, the TTL field is used. The originating node sets the initial TTL value to the sum of the active zone width and the standby zone width, which is also known as the radius of the standby zone. Every time a node receives a DCCN message, the TTL value in the message is decremented by one. The DCCN message is rebroadcast until TTL value reaches zero, which it will not be rebroadcast again.

Processing and re-broadcasting DCCN message REQUEST message When a node receives a REQUEST message, determined by doing a message length check, it first checks to determine whether it has received a REQUEST message with the same originator identifier and request identifier. If such a REQUEST message has been received, the node silently discards the newly received REQUEST message. If the message is not discarded the functions described below take place Firstly, an entry identified by the originator identifier and request identifier, is created in the DCCN table. The lifetime of this new entry is set to the value of the duration field in the REQUEST message. If there is not a duration field in the REQUEST message, default lifetime value is used. After that, two more fields are added to the entry, namely active zone and requested duty cycle rate. The value of the active zone field is worked out by comparing the TTL value with the standby zone width. If the node is located in the active zone, a one is set to the active zone field. Otherwise a zero is set. Based on whether the node is located in the active zone or the standby zone, the requested duty cycle rate is set accordingly. At this point, the requested duty cycle rate is compared with the current operating duty cycle rate. If the requested duty cycle rate is the greater of the two, a request is made to the DCC for a change to the requested duty cycle rate.

Finally, the TTL value in the REQUEST message is decremented by one, and is rebroadcast to the neighbours, provided that the TTL value is greater than zero.

CANCEL messa.e When a node receives a CANCEL message, it first checks to determine whether it has received a CANCEL message with the same originator identifier and request identifier.

If such a CANCEL message has been received, the node silently discards the newly received CANCEL message. The rest of this subsection describes actions taken for CANCEL messages that are not discarded.

Firstly, the DCCN table is checked to determine whether an entry identified by the originator identifier and request identifier of the CANCEL message exists. If such an entry exists, the DCCN table is then checked to determine if there are more than one entries in it. If there are other entries, the highest requested duty cycle rate among these entries is sought, and a request is made to the DCC to change to this duty cycle rate. If there is only one entry in the DCCN table, a request is made to the DCC to change to idle state. Either way, the entry, as requested by the CANCEL message, is deleted from the DCCN table. If no such entry exists, as the entry could have time-out itself, no action is taken to the DCCN table. Finally, the TTL is decremented by one, and is rebroadcast to the neighbours, provided that the TTL value is greater than zero.

DCCN table entries timeout and deletion All the entries in the DCCN table are given a lifetime, regardless of whether the value is coming from a REQUEST message or is set using an implementation default value.

This is to prevent the duty cycle rate change from lasting indefinitely, should there be no CANCEL message received. When the lifetime is up, the DCCN table is checked to determined if there are other entries in it. If there are other entries, the highest requested duty cycle rate among these entries is sought, and a request is made to the DCC to change to this duty cycle rate. If there is only one entry in the DCCN table, a request is made to the DCC to change to idle state. Either way, the "time-out" entry is deleted

from the DCCN table.

Comparing REQUEST requirements The requested REQUEST requirements are only compared with the current operating REQUEST requirements at the originating node. The reason for the comparison is to avoid sending REQUEST messages that have less stringent REQUEST requirements into the network, thus reducing network overhead.

When comparing the REQUEST requirements, the following is the order of comparison: 1) Duration 2) Active zone width + standby zone width 3) Active zone width 4) Active zone rates For example, a requested REQUEST requirements is more stringent if it's duration is longer than the remaining lifetime of the current REQUEST requirements. If there is a tie, move to 2), and so on.

Session header specification

Extra fields are added in the network header to allow session information to be piggybacked and processed at the network layer when data is propagated across the network. The session header format is illustrated in Figure 8 and contains the following

fields:

Field Description

Session identifier A sequence number uniquely identifying the particular session when taken in conjunction with the source network address.

Path rate Duty cycle rate to be used for the data path, represented by a number (0 -15) matching a predefined duty cycle rate.

Duration Contains the duration for the duty cycle rate change. This field is optional.

Table 3: Fields description of the session header.

Interface overview The DCC provides an interface for the Application and the Network. It also accesses the MAC to change the duty cycle rate to use. Figure 9 depicts the interfaces that are linked to the DCC in the control plane.

In the data plane, the Application and the DCC need access to the network interface to send data. Figure 10 depicts the interfaces that are relevant to the DCC in the data plane.

Control plane interface description

The DCC-ZONE-NOTJIFICATION parameters are shown in Table 4 below

Name Type Valid range Description

ApplicationtiD Integer OxOO -OxOF An identifier uniquely identifying the __________________ ___________ ________________ requesting application.

ActiveZoneHops Integer OxOO -OxOF Radius of the active zone in hops.

StandbyZoneHops Integer OxOO -OxOF Radius of the standby zone in hops.

ActiveZoneRate Integer OxOO -OxOF Duty cycle rate to be used for the active _________________ zone.

StandbyZoneRate Integer OxOO -OxOF Duty cycle rate to be used for the _________________ __________ _______________ standby zone.

Duration Integer OxOO -OxFF Duration of duty cycle rate change in _________________ minutes. This parameter is optional.

Table 4: DCC-ZONE-NOTIFICATION parameters The DCC-PA TH-NOTIFJCATION parameters are shown in Table 5 below

Name Type Valid range Description

OriginatoriD Integer OxOO -OxFF Network address of the originator of the session data.

SessioniD Integer OxOO -OxFF A sequence number uniquely identifying the particular data session.

PathRate Integer OxOO -OxOF Duty cycle rate to be used for the path.

Duration Integer OxOO -OxFF Duration of duty cycle rate change in minutes. This parameter is optional.

TableS: DCC-PATH-NOTIFICATION parameters The MAC-DUTY-CYCLE parameters are shown in Table 6 below.

Name Type Valid range Description

DutyCycleRate Integer OxOO -OxOF One of a number of predefined duty cycle rate to be used for the MAC.

Table 6: MAC-DUTY-CYCLE parameters

Data plane interface description

The NET-BROADCAST parameters are shown in Table 7 below

Name Type Valid range Description

Broadcast Net Address -Network layer broadcast address.

MessagePayload Set of octets -Consists of either a REQUEST or a CANCEL message.

Table 7: NET-BROADCAST parameters The NET-SESSION parameters are shown in Table 8 below.

Name Type Valid range Description

SessioniD Integer OxOO -OxOF A sequence number uniquely identifying the particular session when taken in conjunction PathRate Integer OxOF -OxOF Duty cycle rate to be used for the data path, represented by a number (0 -15) matching a predefined duty cycle rate.

Duration Integer OxOO -OxFF Contains the duration for the duty cycle rate

change. This field is optional.

Datapayload Set of -Consists of the data the application wants to octets send.

Table 8: NET-SESSION parameters

Component responsibility specification

This section clarifies the responsibilities of different components -Application, DCC, Network and MAC -as the interfaces between the components are stepped through.

DCC-DCCN

The internal interface between DCC and its subcomponent DCCN is used when: I) I'he DCC wants to send a DCCN message. The values of the parameters from the Application will be relayed to the DCCN.

2) The DCCN requests to change the duty cycle rate at the MAC [The DCC will compare the requested duty cycle rate from the DCCN and current operating duty cycle rate, stored at the DCC, before requesting to change the duty cycle rate at the MAC.] 3) The DCC queries for information from the DCCN table, as may be required by the Application.

DCC-ZONE-NOTIFICATION

The DCC-ZONE-NOTIFICATION interface is invoked whenever an Application wants to get the nodes around into a collaboration state, or to get them out of the collaboration state.

To get the nodes around into collaboration state, the Application needs to provide at least four non-zero parameters to the DCC -ApplicationiD, ActiveZoneHops, StandbyZoneHops, ActiveZoneRates and StandbyZoneRates. The Duration parameter is only required if the Application wants the collaboration state to last for a duration other than the implementation specific duration. The DCC will then store the values of these parameters in the DCCN table. To keep track of what operation requirements have been requested from the DCC, which will be useful if the Application wants to improve the requirements, the application may want to store some of the values of the parameters.

Or, the Application can request this information from the DCC.

To get the nodes around out of the collaboration state, the Application needs to provide the same set of parameters that has been requested previously to the DCC. This allows the DCC to unambiguously cancel the previously requested operation state by the Application, as it is possible that the same Application may have requested more than one different operation state.

DCC-PATH-NOTIFICATION

The DCC-PATH-NOTIFICATION is invoked when the Network receives data with a session header. The Network, after processing the session header, will pass the session header information to the DCC. The DCC, when receives the session header information, will first of all check to determine whether there is an entry, identified by the OriginatorjD and SessiorilD, in the DCC-PATH table. If such an entry exists, the lifetime of the entry is refreshed, to a lifetime of Duration2 (If Duration is not available in the session header information, implement specific default durationis used instead.) If no such entry exists, a new entry is created for the requested path rate, identified by the OriginatoriD and Sessionld, for a lifetime of Duration2. Subsequently, the DCC checks to determine whether the node is currently in idle state. If the node is in idle state, the DCC will invoke the MAC-DUTY-CYCLE interface to change the duty cycle rate to the requested path rate. If the node is not in idle state, the DCC will compare the current operating duty cycle rate with the requested path rate. if the requested path rate is the greater of the two, similarly, the DCC will invoke the MAC-DUTY-CYCLE interface to change the duty cycle rate to the requested path rate. Otherwise, the current operating duty cycle rate will continue to be used.

D CC-PATH table entries timeout and deletion All the entries in the DCC-PATH table is given a lifetime, to prevent the duty cycle rate change from lasting indefinitely. When the lifetime is up, the DCC compares the highest requested duty cycle rate in the DCCN table and the highest duty cycle rate in the DCC-PATH table, and invokes the MAC-DUTY-CYCLE interface to change the duty cycle rate to the greater of the two duty cycle rates. If there is no entry in the DCCN and DCC-PATH tables, the MAC-DUTY-CYCLE interface is invoked to change the duty cycle rate to idle state. Finally, the "time-out" entry is deleted from the DCC-PATH

table.

MAC-DUTY-CYCLE

The MAC-DUTY-CYCLE interface is invoked whenever the DCC wants to change the duty cycle rate at the MAC. The occasions when DCC wants to do that are: 1) Change from idle state to active/standby state, via REQUEST message 2) Change from idle state to active/standby state, via session data 3) Change from active/standby state to idle state, via CANCEL message 4) Change from active/standby state to idle state, via timeout 5) Change from active/standby state to another active/standby state, via REQUEST message 6) Change from active/standby state to another active/standby state, via session data 7) Change from active/standby state to another active/standby state, via timeout.

NET-BROADCAST

The NET-BROADCAST interface is used when the DCC sends and receives DCCN messages. As the DCCN message need to be broadcast hop-by-hop in the send process, network broadcast address is required. When receiving, only the DCCN message is passed from the Network to the DCC.

NET-SESSION

The NET-SESSION interface is used when the Application sends and receives session data. As session header needs to be set in the Network, session header information is required to be provided from the Application. When receiving, only the session data is passed from the Network to the Application.

It will be appreciated that the above description describes a number of embodiments of the invention and the invention lends itself to be applied to many scenarios. It is most effective for medium to large-scale deployments of nodes, sensing long-lived, localised, and geographically evolving phenomena. Its flexibility and geographical scoping capability are most useful for scenarios involving large disparities in the amount of activity in different parts of the node network.

Claims

1. A method of communication within a node network, each node having a plurality of operating states wherein an event detected within the network causes one or more nodes to adopt a given state, said one or more nodes communicating with one or more other nodes causing said one or more other nodes to adopt related states, for a period of time or until explicitly requested otherwise.

2. A method of communication as claimed in claim 1, wherein each of the states operates at a respective duty cycle rate, the duty cycle rates being different for each of the operating states.

3. A method of communication as claimed in claim 2, wherein the transition of a node between different operating states is dependent on the desired operation duty cycle rate for the node, which can be either from a higher duty cycle rate to a lower duty cycle rate or from a lower duty cycle rate to a higher duty cycle rate.

4. A method of communication as claimed in any of claims 1 to 3, wherein each node has two operating states comprising a first state and a second state, and initially all said nodes being in the second state, wherein an event detected within the network causes one or more nodes to adopt the first state, said one or more nodes in said first state communicating with one or more other nodes causing said one or more other nodes to adopt the first state.

5. A method of communication as claimed in claim 4, wherein each of the first and second states of node operation have respective first and second duty cycles, the first duty cycle being higher than the second duty cycle.

6. A method of communication as claimed in any one of claims I to 3, wherein each node has three operating states, and initially all said nodes being in the third state, wherein an event detected within the network causes one or more nodes to adopt the first state, said one or more nodes in said first state communicating with one or more other nodes causing said one or more other nodes to also adopt the first or the second state.

7. A method of communication as claimed in claim 6, wherein the third state of node operation has a third duty cycle, said third duty cycle being lower than either the first or second duty cycles.

8. A method of communication as claimed in any one of claims 1 to 3, wherein each node has N operating states, where N is a number greater than one, and initially all said nodes being in the Nth state, wherein an event detected within the network causes one or more nodes to adopt the first state, said one or more nodes in said first state communicating with one or more other nodes causing said one or more other nodes to adopt the first operating state or any other operating state up to the (N-1)th state.

9. A method of communication as claimed in any one of claims 1 to 3, wherein each node has N operating states, where N is a number greater than one, and initially the nodes being in one or more of the operating states, wherein an event detected within the network causes one or more nodes to adopt a different operating state, said one or more nodes in said different operating state communicating with one or more other nodes causing said one or more other nodes to adopt said different operating state or any other operating state.

10. A method of communication as claimed in any of claims 1 to 9, wherein the nodes are sensor nodes together defining a sensor node network.

II. A method as claimed in claim 10, when dependent on claim 4, wherein the first state is an active state and the second state is an idle state, a sensing stimulus detected within the network causing one or more nodes within the neighbourhood of the detected stimulus to enter their active state, the active nodes communicating with one or more other nodes causing them to enter their active state.

12. A method as claimed in claim 10, when dependent on claim 6 or claim 7, wherein each sensor node has three operating states including an active state, a standby state and an idle state, a sensing stimulus detected within the network causing one or more nodes within the neighbourhood of the stimulus to adopt the active state, said one or more active nodes communicating with one or more other nodes causing them to enter the standby state.

13. A method as claimed in claim 12, wherein the duty cycle of the active state is higher than the duty cycle of the standby state, which is higher than the duty cycle of the idle state.

14. A method as claimed in any one of claims 3 to 13, when dependent on claim 2, wherein the different duty cycles have periodic coinciding wake times that enable nodes operating on different duty cycles to communicate.

15. A method as claimed in any one of claims I to 14, wherein an initiating node is adapted to receive a stimulus setting its duty cycle and initiate a duty cycle notification protocol (DCCN) comprising a REQUEST message for broadcasting to neighbouring nodes, the REQUEST message containing information about the associated duty cycling rate to be applied to the neighbouring nodes

16. A method as claimed in claim 15 wherein the REQUEST message contains information about the radii of zones within the network, the nodes within the zones having associated duty cycles.

17. A method as claimed in claim 15 or claim 16 wherein the REQUEST contains information about duty cycles to be conveyed along one or more node paths through the network from the initiating node to one or more remote nodes, said duty cycle to be applied at nodes along said path.

1 8. A method as claimed in claim 17 wherein said one or more remote nodes are gateway nodes or nodes internal to the node network.

19. A method as claimed in any one of claims 15 to 18, wherein the initiating node issues a CANCEL message when the originating node wants to cancel a previous REQUEST message.

20. A method as claimed in any one of claims 15 to 18, wherein the REQUEST message is automatically cancelled after a period set by the REQUEST message.

21. A communication system comprising a control unit for receiving communication data from a node network, each node having a plurality of operating states wherein an event detected within the network causes one or more nodes to adopt a given state, said one or more nodes communicating with one or more other nodes causing said one or more other nodes to adopt related states for a period of time or until explicitly requested otherwise.

22. A communication system as claimed in claim 21, wherein each of the states operates at a respective duty cycle rate, the duty cycle rates being different for each of the operating states.

23. A communication system as claimed in claim 22, wherein the transition of a node between different operating states is dependent on the desired operation duty cycle rate for the node, which can be either from a higher duty cycle rate to a lower duty cycle rate or from a lower duty cycle rate to a higher duty cycle rate.

24. A communication system as claimed in any one of claims 21 to 23, wherein each node in the network has two operating states comprising a first state and a second state, and initially said nodes are in the second state, wherein an event detected within the network causes one or more nodes to adopt the first state, said one or more nodes in said first state communicating with one or more other nodes causing said one or more other nodes to adopt the first state.

25. A communication system as claimed in any one of claims 21 to 23, wherein each sensor node has three operating states including an active state, a standby state and an idle state, a sensing stimulus detected within the network causing one or more nodes within the neighbourhood of the stimulus to adopt the active state, said one or more active nodes communicating with one or more other nodes causing them to enter the standby state.

26. A communication system as claimed in any one of claims 21 to 25 wherein the system provides a plurality of sensor nodes, each node including a power source and a sensor for producing observation data indicating a quantity being measured, a wireless interface for sending the observation data from the sensor to neighbouring nodes within the network and at least one gateway node for receiving the observation data to be passed onto a computer server.

27. A sensor node network comprising a plurality of nodes, each having an energy source and a sensor for producing observation data indicating a parameter being monitored, each node having a plurality of operating states wherein an event detected within the network causes one or more nodes to adopt a given state, said one or more nodes communicating with one or more other nodes causing said one or more other nodes to adopt related states, for a period of time or until explicitly requested otherwise.

28. A sensor node network as claimed in claim 27, wherein each of the states operates at a respective duty cycle rate, the duty cycle rates being different for each of the operating states.

29. A sensor node network as claimed in claim 28, wherein the trajsition of a node between different operating states is dependent on the desired operation duty cycle rate for the node, which can be either from a higher duty cycle rate to a lower duty cycle rate or from a lower duty cycle rate to a higher duty cycle rate.

30. A sensor node network as claimed in any of claims 27 to 29, each node having at least two operating states comprising a first state and a second state, said nodes being initially in the second state, wherein an event detected within the network causes one or more nodes to adopt the first state, said one or more nodes in said first state communicating with one or more other nodes causing said one or more other nodes to adopt the first state.

31. A sensor node network as claimed in any of claims 27 to 30, wherein each node has a duty cycle control mechanism to determine the duty cycle in response to a signal received either from the sensing of a stimulus or from a signal received from another neighbouring node.

32. A sensor network as claimed in claim 31, wherein an initiating node is adapted to receive a stimulus setting its duty cycle and initiate a duty cycle notification protocol (DCCN) comprising a REQUEST message for broadcasting to neighbouring nodes, the REQUEST message containing information about the associated duty cycling rate to be applied to the neighbouring nodes.

33. A sensor network as claimed in claim 32 wherein the REQUEST message contains information about the radii of zones within the network, the nodes within the zones having the associated duty cycles.

34. A sensor network as claimed in claim 32 or claim 33 wherein the REQUEST contains information about duty cycles to be conveyed along one or more node paths through the network from the initiating node to one or more remote nodes, said duty cycle to be applied at nodes along said path.

35. A sensor node network as claimed in claim 34 wherein said one or more remote nodes are gateway nodes.

36. A sensor node network as claimed in any one of claims 32 to 35 wherein the duty notification protocol includes a CANCEL message for broadcasting to neighbouring nodes to cancel a previous REQUEST message.

37. A method of detecting an event comprising deploying a sensor node network in an area where the event may occur, and adapting the sensor nodes in the network to modify their duty cycle between a plurality of values dependent on the timing of the event and the location in the area where the event is detected.

38. A sensor node for use in a sensor node network, the sensor node comprising an energy source, a sensor, a processor and a duty cycle controller, the duty cycle controller being operable to change the duty cycle when its sensor detects an event and to transmit a signal to neighbouring nodes in the network to influence their duty cycle.

39. A method of detecting an event as claimed in claim 37 wherein the sensor node *.,... network is as claimed in any one of claims 27 to 36. S... * .

: **.*

40. A method of detecting an event as claimed in claim 37 or claim 39, wherein the sensor nodes in the sensor node network comprise sensor nodes as claimed in claim 38. * ..

* S * -*..

39. A method of detecting an event as claimed in claim 37 wherein the sensor node network is as claimed in any one of claims 27 to 36.

40. A method of detecting an event as claimed in claim 37 or claim 39, wherein the sensor nodes in the sensor node network comprise sensor nodes as claimed in claim 38.

AMENDMENTS TO THE CLAIMS HAVE BEEN FILED AS FOLLOWED: 1. A method of communication within a node network, each node having a plurality of operating states wherein an event detected within the network causes one or more nodes to adopt a given state, said one or more nodes communicating with one or more other nodes causing said one or more other nodes to adopt related states, for a period of time or until explicitly requested otherwise.

6. A method of communication as claimed in any one of claims 1 to 3, wherein each node has three operating states, and initially all said nodes being in the third state, wherein an event detected within the network causes one or more nodes to adopt the first state, said one or more nodes in said first state communicating with one or more other nodes causing said one or more other nodes to also adopt the first or the second state.

8. A method of communication as claimed in any one of claims 1 to 3, wherein each node has N operating states, where N is a number greater than one, and initially all said nodes being in the Nth state, wherein an event detected within the network causes one or more nodes to adopt the first state, said one or more nodes in said first state communicating with one or more other nodes causing said one or more other nodes to adopt the first operating state or any other operating state up to the (N-i)th state.

10. A method of communication as claimed in any of claims I to 9, wherein the nodes are sensor nodes together defining a sensor node network.

11. A method as claimed in claim 10, when dependent on claim 4, wherein the first state is an active state and the second state is an idle state, a sensing stimulus detected within the network causing one or more nodes within the neighbourhood of the detected stimulus to enter their active state, the active nodes communicating with one or more other nodes causing them to enter their active state.

15. A method as claimed in any one of claims I to 14, wherein an initiating node is adapted to receive a stimulus setting its duty cycle and initiate a duty cycle notification protocol (DCCN) comprising a REQUEST message for broadcasting to neighbouring nodes, the REQUEST message containing information about the associated duty cycling rate to be applied to the neighbouring nodes 16. A method as claimed in claim 15 wherein the REQUEST message contains information about the radii of zones within the network, the nodes within the zones having associated duty cycles.

18. A method as claimed in claim 17 wherein said one or more remote nodes are gateway nodes or nodes internal to the node network.

23. A comniunicatjon system as claimed in claim 22, wherein the transition of a node between different operating states is dependent on the desired operation duty cycle rate for the node, which can be either from a higher duty cycle rate to a lower duty cycle rate or from a lower duty cycle rate to a higher duty cycle rate.

29. A sensor node network as claimed in claim 28, wherein the transition of a node between different operating states is dependent on the desired operation duty cycle rate for the node, which can be either from a higher duty cycle rate to a lower duty cycle rate or from a lower duty cycle rate to a higher duty cycle rate.

34. A sensor network as claimed in claim 32 or claim 33 wherein the REQUEST contains infonnation about duty cycles to be conveyed along one or more node paths through the network from the initiating node to one or more remote nodes, said duty cycle to be applied at nodes along said path.

37. A method of detecting an event comprising deploying a sensor node network in an area where the event may occur, and adapting the sensor nodes in the network to modif' their duty cycle between a plurality of values dependent on the timing of the event and the location in the area where the event is detected, the sensor nodes being operable to transmit a signal to neighbouring nodes in the network to influence their duty cycle.