WO2016048202A1

WO2016048202A1 - Constrained devices and methods for managing a constrained device

Info

Publication number: WO2016048202A1
Application number: PCT/SE2014/051090
Authority: WO
Inventors: Oscar Novo Diaz; Francesco MILITANO; Patrik Salmela
Original assignee: Telefonaktiebolaget L M Ericsson (Publ)
Priority date: 2014-09-24
Filing date: 2014-09-24
Publication date: 2016-03-31

Abstract

Constrained devices and methods for managing a constrained device Methods for managing a constrained device are disclosed. The constrained device is one of a plurality of constrained devices within a network, each constrained device in the network having a device identity. A first method (100) comprises detecting that functionality of the constrained device will be reduced within a threshold period of time (110), and transferring the identity of the constrained device to another of the constrained devices in the network (130). Another method (200) comprises receiving an identity of another constrained device in the network (250), receiving a request directed to the received identity (260), and responding to the request (270). Also disclosed are constrained devices (400, 500, 600) and a computer program product configured to implement the above methods.

Description

Constrained devices and methods for managing a constrained device

Technical Field The present invention relates to constrained devices and to methods for managing a constrained device, which device is one of a plurality of constrained devices within a network. The present invention also relates to a computer program product configured, when run on a computer, to carry out a method managing a constrained device. Background

Cellular communications networks continue to experience rapid growth. In addition to growing volumes of data traffic, the number of devices connected via cellular communications networks is also forecast to increase substantially in the near future, and it is expected that machine devices (MD) will contribute significantly to this forecast increase in connected devices. Machine devices are autonomous, often very small devices typically associated with equipment or apparatus as opposed to a human user. MDs use cellular or other types of communication networks to communicate with an application server, which may or may not be comprised within the cellular network. The application server receives information from the MD and configures the MD remotely. MDs thus typically access the cellular network more or less infrequently, transmitting and receiving very small amounts of data, or being polled for data. MDs represent a subset within the larger category of User Equipment devices (UEs), and may also be referred to as machine type communication (MTC) devices or machine to machine (M2M) devices. Machine Devices are also an example of constrained devices, which are devices in which at least one of power, capacity, device complexity and/or network connectivity is subject to limitation.

Supporting MTC over a cellular network involves changes to the network architecture, accommodating differences between MTC network interaction and user interaction with the network. Figure 1 shows a reference network architecture 20 used to allow MTC devices to connect to a 3GPP network (UTRAN, E-UTRAN etc). Figure 1 is reproduced from 3GPP TS 23.682 V1 1 .3.0, "3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Architecture enhancements to facilitate communications with packet data networks and applications (Release 1 1 )", December 2012. Referring to Figure 1 , the UE 4, in this case an MTC device, can be seen to include an MTC UE application 6. The MTC device 4 communicates over the radio access network (RAN) to access application servers via the core network of its home public land mobile network (HPLMN). Within the HPLMN various network entities may be introduced according to the particular model envisaged for MTC traffic. Figure 1 illustrates a direct model, in which an application server (AS) 8 connects directly to a 3GPP operator network to perform direct communications with the MTC device. Figure 1 also illustrates an indirect model, in which an application server (AS) 10 connects indirectly to an operator network via a Services Capability Server (SCS) 12. An MTC Inter Working Function (MTC-IWF) 14, acts as an interface enabling interworking of the 3GPP core network and the MTC service capability. A hybrid model may use both direct and indirect models simultaneously. The network architecture may also include an MTC Authentication, Authorisation and Accounting (AAA) function 16 within the HPLMN. The nature of MTC devices and their envisaged use patterns mean that these devices are often required to be highly energy efficient. External power sources for MTC devices will often not be available, meaning the device must operate using energy harvesting or battery power, with frequent replacing or recharging of batteries being neither practical nor economically feasible. One way of increasing the energy efficiency of MTC devices is to enable the devices to enter energy efficient low power modes, known as sleep modes, between communication or other events. Devices enter active modes when action is required of them or when communication with the network is necessary. At all other times, the devices may enter a sleep mode and so conserve energy. If this energy saving approach is applied, information stored on the devices is only available to the network when the devices are awake and able to communicate. This reduced information availability can be problematic, and in order to address this, Mirror Servers may be implemented in MTC networks. A Mirror Server is a server or service within the network that stores MTC device data on behalf of the MTC device. An interested party can query the Mirror Server for the MTC data at any time, even when the MTC device itself is in sleep mode. The implementation of Mirror Servers usually requires the MTC device to sign the data it passes to the Mirror Server in order to authenticate the data. A client retrieving the data from the Mirror Server may thus verify that the data retrieved has been produced by the MTC device in question. The use of low power modes in combination with Mirror Servers can represent a good energy solution for many deployment scenarios for MTC devices. However, this approach does have some drawbacks, particularly in the context of extreme deployment situations and Delay Tolerant Networking. MTC devices are often used in networks that may be in mobile environments, in extreme terrestrial environments or in space. One example of an extreme terrestrial environment is a nuclear power plant, in which MTC sensors may provide vital environmental data but are subject to very high levels of radiation which may damage the devices. Other examples include marine environments, where MTC devices may be required to support huge pressures deep under the oceans, or military environments. In all these situations, there is a very high probability that any one device may suffer malfunctions during its operational lifetime. If a malfunction is suffered while a device is sleeping, critical information may be lost, and the recovery of that information may be almost impossible. Mirror Servers do not offer a reliable back-up for such deployment situations. If the Mirror Server is implemented within the same extreme conditions as the MTC devices, the Mirror Server is subject to the same high probability of failure. Owing to its function as a central repository for data from multiple MTC devices, the Mirror Server then represents a single point of failure for a large amount of data, and thus represents a very high risk solution. If the Mirror Server is implemented remotely from the MTC devices, it may escape the harsh environmental conditions but its functioning is then dependent upon good network connectivity to enable the MTC devices to transfer their data before entering sleep mode. Continuous network connectivity can often not be assured in such environments, where a Delay Tolerant Networking approach is preferred. The data in a Mirror Server may thus be out of date, for example if network connectivity was not available immediately before a MTC device entered sleep mode.

Even in less extreme deployment scenarios, when using a Mirror Server, a client never connects with the actual source of the requested data, and if the Mirror Server is located far from the MTC devices, the Mirror Server may have less information than would be available directly from the MTC devices, or the client may learn less from the Mirror Server about the relevant system than would be possible via a direct connection to an MTC device. Summary It is an aim of the present invention to provide a method and apparatus which obviate or reduce at least one or more of the disadvantages mentioned above.

According to a first aspect of the present invention, there is provided a method for managing a constrained device which is one of a plurality of constrained devices within a network, each constrained device in the network having a device identity. The method comprises detecting that functionality of the constrained device will be reduced within a threshold period of time and transferring the identity of the constrained device to another of the constrained devices in the network. In this manner, according to examples of the invention, the other constrained device, also referred to below as the peer constrained device, may act as a delegate for the constrained device, for example responding to queries addressed to the constrained device while the constrained device is experiencing reduced functionality. A constrained device may comprise a device in which at least one of power, capacity, device complexity and/or network connectivity is subject to limitation. A constrained device may for example be a machine device.

According to some embodiments, detecting that functionality of the constrained device will be reduced within a threshold period of time may comprise detecting at least one of a programmed transition to sleep mode for the constrained device within the threshold period of time, or evidence of a malfunction within the constrained device. In some examples, the threshold period of time may be set according to network configuration in order to allow sufficient time for another constrained device to be identified and for transfer of identity to be carried out before sleep mode is entered or the detected malfunction begins to impede device functioning.

According to some embodiments, the method may further comprise transferring data held by the constrained device to the other constrained device in the network. In some examples, the data transferred comprise device data such as sensor data in the case of a sensor network, or the data may comprise metadata. In some examples, the metadata may indicate that the constrained device is unavailable and may additionally indicate a time at which it is predicted the constrained device will become available again. In some examples, by transferring data in addition to identity, the constrained device enables the other, peer constrained device to satisfy requests made to the constrained device, furnishing data to client entities on behalf of the constrained device that is entering sleep mode or malfunctioning. Even if the transferred data is merely metadata then the requesting client entity may still receive useful information in the form for example of a predicted time at which the device will become available again. According to some embodiments, the method may further comprise authenticating the source of the data held by the constrained device before transferring the data. In some examples, authenticating the source of the data may comprise signing the data and transferring the signature with the data. In this manner a requesting entity may have confidence that the response received from the delegate device to which the identity has been transferred is authentic.

According to some embodiments, the method may further comprise applying at least one of a time stamp or a sequence number to the data held by the constrained device before transferring the data. In some examples, time stamping may enable identification of a time at which a certain item of data was generated. It may be envisaged for example that a device which has delegated its identity to at least one peer constrained device re-enters active mode, and a request for data is received by the device network before the original identity owner can de-activate its delegate. In such a situation, multiple responses to the data request may be sent by the delegate and the original identity owner, but the data from the original owner of the identity will have a later time stamp, and so can be identified as the latest, most up to date response. In some examples, the timestamp and/or sequence number may also be signed, such that it is the combination of data and timestamp, and/or data and sequence number which is signed.

According to some embodiments, the method may further comprise transferring the identity of the constrained device to a plurality of other constrained devices in the network. In this manner, redundancy may be introduced into the method, with multiple delegates being created from amongst the peer constrained devices.

According to some embodiments, the method may further comprise transferring data held by the constrained device to the plurality of other constrained devices in the network. In some examples, the plurality of other constrained devices may be a specific group of constrained devices, for example fulfilling certain criteria relating to availability, capacity etc. In such examples, the transfer of identity and any data may comprise a multicast transmission to the members of the group. In alternative examples, the plurality of other constrained devices may comprise all other constrained devices in the network, and the transfer may comprise a broadcast transmission to all constrained devices in the network. In still further examples, a broadcast transmission to all constrained devices in the network may be conducted, but the constrained device may await a transfer acknowledgement from a device fulfilling certain criteria in order to confirm that the identity and data have been received by a peer constrained device having the desired capabilities to act as a delegate for the identity and data.

According to some embodiments, the method may further comprise transferring different data to different ones of the plurality of other constrained devices in the network. In some examples, such selective delegation may enable load balancing between peer constrained devices acting as delegates. In further examples, data of varying levels of importance may be matched to a peer constrained device having appropriate capabilities and programmed awake schedule for that data. In such examples, data transfer may be effected via a series of unicast transmissions to individual constrained devices. According to some embodiments, different data may be transferred to different ones of the plurality of other constrained devices in the network according to at least one of importance of the data and capabilities of the plurality of other constrained devices. In some examples, capabilities of the other, peer constrained devices in the network may be communicated to the constrained device by the other constrained devices, or may be stored in the constrained device.

According to some embodiments, the method may further comprise transferring an identity of a third constrained device in the network to the other constrained device in the network, wherein the identity of the third constrained device is stored in the constrained device following transfer to the constrained device from the third constrained device. In some examples, a constrained device may already be acting as a delegate for one of its peers at a time when that device detects upcoming reduced functionality, and so in addition to transferring its own identity to a new delegate the subject device may also transfer the identity of the peer device for whom it is acting as a delegate. According to some embodiments, the method may further comprise transferring a deletion policy for the identity to the other constrained device in the network. In some examples, the transferred deletion policy may also apply to any data transferred to the delegate. In some examples, the deletion policy may specify active deletion or passive deletion. Active deletion may comprise awaiting a signal from the constrained device instructing deletion of the identity and any data transferred from the constrained device. The instruction may be signed and/or otherwise authenticated. Passive deletion may comprise a condition upon fulfilment of which the identity and any data should be deleted by the delegate. The condition may be a time period following transfer or may comprise a threshold number of uses of the transferred identity to respond to a query directed to the identity.

According to some embodiments, the method may further comprise transferring a delegation policy to the other constrained device in the network. In some examples, the delegation policy may for example comprise a hierarchical list of other peer constrained devices in the network which are capable of receiving and/or authorised to receive the identity and data of the constrained device. The delegation policy may specify capabilities required of a peer constrained device in order to transfer identity of the subject device. In further examples, the delegation policy may comprise a public key and only peer constrained devices having a private key corresponding to the public key may be authorised to receive the identity of the subject device. In some examples, transferring the delegation policy may enable the policy to be followed in the event of multi-hop delegation, in which the peer device to which the identity is transferred itself detects imminent reduced functionality and seeks to transfer its identity to another peer constrained device.

According to some embodiments, the method may further comprise requesting another constrained device in the network to receive the identity of the constrained device. According to some embodiments, requesting another constrained device may comprise transmitting a unicast request to a single constrained device. In some examples, the single constrained device may be selected according to a delegation policy stored in the constrained device. In such examples, the delegation policy may for example comprise a hierarchical list of other constrained devices in the network which are capable of receiving and/or are authorised to receive the identity and data of the constrained device. In such examples, a high degree of pre-programming may be achieved in the delegation of identity, which may reduce the need for multi-hop delegation and ensure there is always an authorised delegate available.

According to some embodiments, requesting another constrained device may comprise transmitting a multicast request to a group of constrained devices. In some examples, the group of constrained devices may be selected according to a delegation policy stored in the constrained device.

According to some embodiments, requesting another constrained device may comprise transmitting a broadcast request to all other constrained devices in the network.

According to some embodiments, the method may further comprise receiving a response to the request from a responding constrained device, and transferring the identity of the constrained device to the responding constrained device.

In some examples, the constrained device may thus await a response to the unicast, multicast or broadcast request before transferring identity and data. In the case of a broadcast request, the constrained device may await a response from a peer constrained device having suitable capabilities or authority to receive the identity and data.

According to some embodiments, the method may further comprise receiving responses to the request from multiple responding constrained devices, selecting at least one responding constrained device, and transferring the identity of the constrained device to the at least one selected responding constrained device. In such examples, the constrained device may select a responding device which fulfils certain criteria. In some examples, the device may be selected according to a delegation policy stored in the constrained device, which may specify capabilities required of a constrained device in order to transfer the identity of the device that will be entering sleep mode or is malfunctioning. Alternatively, the delegation policy may comprise one or more public keys corresponding to constrained devices authorised to act as delegates. Constrained devices responding to the request may sign their responses with a signature generated using their private keys. These signatures can then be verified to check if the signature in a received response corresponds to the one or more public keys in the delegation policy. According to some embodiments, the method may further comprise receiving a transfer confirmation from the other constrained device. In some examples, in the case of a broadcast transfer of constrained device identity, the method may further comprise checking for a transfer confirmation from a constrained device matching a delegation policy stored in the constrained device that is transferring its identity.

According to some embodiments, the method may further comprise entering a sleep mode following transfer of the identity of the constrained device. In some examples, the constrained device may await a transfer confirmation before entering sleep mode, and in the case of a broadcast transfer, may await transfer confirmation from an authorised or capable peer constrained device.

According to some embodiments, the method may further comprise awaking from a sleep mode and instructing the other constrained device to delete the identity of the constrained device. In some examples, the instruction may also apply to any data transferred to the other constrained device. In this manner unnecessary use of storage capacity in the other constrained device may be avoided.

According to some embodiments, the constrained device may comprise a sensor or sensors.

According to some embodiments, the constrained device may comprise an actuator or actuators. According to some embodiments, the network may comprise a delay tolerant network.

According to some embodiments, communication between constrained devices of the network may be effected via at least one of a cellular network, an optical network, a wired network, a wireless local area network, or via Radio Frequency Identification, RFID. Other communication means may also be envisaged.

According to some embodiments, transferring the identity of the constrained device to another of the constrained devices in the network may comprise explicitly communicating the identity of the constrained device to the other constrained device. According to some embodiments, transferring the identity of the constrained device to another of the constrained devices in the network may comprise implicitly communicating the identity of the constrained device to the other constrained device. Thus, in some examples in which the network is a static network, transmission of identity between constrained devices may be pre programmed according to a scheduled sleeping time of the devices.

According to another aspect of the present invention, there is provided a method for managing a constrained device which is one of a plurality of constrained devices within a network, each constrained device in the network having a device identity. The method comprises receiving an identity of another constrained device in the network, receiving a request directed to the received identity, and responding to the request.

In some examples, the request may be a data request submitted to the network or submitted directly to the received identity. In further examples, the method may further comprise receiving data from the other constrained device in addition to the device identity, and responding to the request may comprise replying to the request with the received data. According to some embodiments, the method may further comprise checking for a deletion policy associated with the received identity and, if a deletion policy is associated with the received identity, deleting the received identity at a time and in a manner in accordance with the deletion policy. According to some embodiments, the method may further comprise sending a transfer confirmation to the other constrained device on receipt of the identity of the other constrained device.

According to some embodiments, the method may further comprise receiving a request from the other constrained device to receive the identity of the other constrained device and responding to the request. In some examples, responding to the request may comprise responding with any one of device availability, programmed sleep schedule, device capabilities, a signature generated using the device private key and/or an indication of public keys held. According to another aspect of the present invention, there is provided a computer program product configured, when run on a computer, to carry out a method according to the first or second aspects of the present invention. According to another aspect of the present invention, there is provided a constrained device which is one of a plurality of constrained devices within a network, each constrained device in the network having a device identity. The constrained device comprises a detecting unit configured to detect that functionality of the constrained device will be reduced within a threshold period of time, and a transfer unit configured to transfer the identity of the constrained device to another of the constrained devices in the network.

According to another aspect of the present invention, there is provided a constrained device which is one of a plurality of constrained devices within a network, each constrained device in the network having a device identity. The constrained device comprises a receiving unit configured to receive an identity of another constrained device in the network, a request unit configured to receive a request directed to the received identity, and a response unit configured to respond to the request. According to another aspect of the present invention, there is provided a constrained device which is one of a plurality of constrained devices within a network, each constrained device in the network having a device identity. The constrained device comprises a processor and a memory, the memory containing instructions executable by the processor such that the constrained device is operable to detect that functionality of the constrained device will be reduced within a threshold period of time, and transfer the identity of the constrained device to another of the constrained devices in the network.

According to another aspect of the present invention, there is provided a constrained device which is one of a plurality of constrained devices within a network, each constrained device in the network having a device identity. The constrained device comprises a processor and a memory, the memory containing instructions executable by the processor such that the constrained device is operable to receive an identity of another constrained device in the network, receive a request directed to the received identity, and respond to the request. Brief description of the drawings

For a better understanding of the present invention, and to show more clearly how it may be carried into effect, reference will now be made, by way of example, to the following drawings in which:

Figure 1 illustrates a network architecture in an EPS/LTE network accommodating MTC communication; Figure 2 is a flow chart illustrating method steps in a method for managing a constrained device;

Figure 3 is a flow chart illustrating method steps in another method for managing a constrained device;

Figure 4 is a schematic representation of a constrained device and peer constrained devices;

Figure 5 is a schematic representation of implementation of a delegation policy;

Figure 6 illustrates a delegation process;

Figure 7 is a flow chart illustrating process steps in another example of method for managing a constrained device;

Figure 8 is a block diagram illustrating functional units in a constrained device;

Figure 9 is a block diagram illustrating functional units in another example of a constrained device; and

Figure 10 is a block diagram illustrating functional units in another example of a constrained device.

Detailed description Aspects of the present invention enable individual constrained devices within a network to act as delegates for other constrained devices in the network, receiving the identity of another constrained device and responding on behalf of that device to queries from client entities. As noted above, network connectivity in delay tolerant networks and constrained networks, that is networks including at least one constrained device, may be intermittent. Thus in many cases a constrained device will not have network connectivity immediately before a scheduled transition to sleep mode, and cannot therefore transfer its data to a mirror server. By transferring the device's identity to another constrained device within the device network, the device transitioning to sleep mode ensures that that identity remains available during the coming period of reduced functionality associated with a sleep mode. This delegation of identity may also be performed if a constrained device detects evidence of some malfunction within itself, transferring its identity to another device before the detected malfunction becomes critical.

The transferred identity of the sleeping or malfunctioning device may be used by its delegate to respond to queries addressed to the sleeping or malfunctioning device. Should the sleeping or malfunctioning device fail or become permanently unavailable, the last available information about the device may be passed to client or server entities by its delegate.

Figures 2 and 3 illustrate process steps in methods 100, 200 for managing a constrained device in accordance with aspects of the present invention. Figure 2 illustrates process steps conducted at a constrained device seeking to transfer its identity to another constrained device in the network. Figure 3 illustrates process steps conducted at a constrained device that is receiving an identity from another constrained device.

As discussed above, a constrained device is a device in which at least one of power, capacity, device complexity and/or network connectivity is subject to limitation. Networks of constrained devices are frequently deployed in the form of MTC sensor or sensor/actuator networks for example to monitor environmental conditions. Networks of constrained devices identify each constrained device within the network with a unique identifier. Every constrained device is aware of its own identity within the network and uses its identity when communicating with other devices in the network or with entities outside the network. Different communication technologies may be used for device to device communication within a constrained network. These technologies may include for example a cellular network, an optical network, a wired network, a wireless local area network, or Radio Frequency Identification, RFID. Device to device communication within the network may be direct or may be via a gateway or other intermediary. The following description uses the term peer constrained devices to refer to other constrained devices within a network which may be tasked to receive the identity of a subject constrained device. It will be appreciated that any one constrained device may be both a subject constrained device seeking to delegate its identity and a peer constrained device tasked to receive an identity.

Referring to Figure 2, in a first step 1 10 a constrained device (the delegating device) detects that its functionality will be reduced within a threshold period of time. This reduced functionality may be a consequence of a scheduled or unscheduled transition to a sleep mode, for example as part of an energy saving protocol followed by the device. In such cases, the threshold period of time may be determined in advance based upon network configuration in order to allow sufficient time to identify a suitable peer device and transfer identity to the peer device before the transition to sleep mode. In other examples, the detected imminent reduction in functionality may be a consequence of a malfunction within the delegating device. The device may detect evidence of a malfunction within itself, which malfunction may impede its normal operation. The device may therefore take steps to transfer its identity before the malfunction becomes critical. In such cases, the threshold time period may be determined by the nature of the detected malfunction. After detecting that functionality will be reduced within a threshold period of time, the delegating constrained device then proceeds, at step 130, to transfer its identity to another constrained device in the network (the delegate device). This peer constrained device may first be identified by the delegating constrained device through a request and response process, or the identity may be transferred without such a request and response process, as discussed in further detail below. In some examples, the delegating device may also transfer some or all of its data to the delegate device, along with its identity. Such data might for example include latest sensor readings in the case of a sensor network. The transferred data may enable the delegate device to satisfy information requests addressed to the delegating device during the time period when the delegating device is unavailable. Figure 3 illustrates process steps conducted at a delegate constrained device. In a first step 250, the delegate constrained device receives the identity of another constrained device in the network (the delegating device). Following receipt of the identity, the delegate device receives, at step 260, a request directed to the identity which it has received. The delegate device then responds to that request at step 270 on behalf of the device whose identity it has received. In this manner, a response may be received by a client entity to requests directed to a constrained device which is not currently available, as a result of being in sleep mode or suffering a malfunction. The transfer of identity conducted at step 130 of the method of Figure 2 is referred to in the following discussion as a delegation of identity. The delegation may be a "full identity" delegation or a "care of identity" delegation, depending upon the requirements of the delegating device and its mode of operation. In full identity delegation, the delegate device takes full control of the transferred identity and responds to queries on its behalf without any indication that the identity has been transferred. A requesting entity receiving a reply from a full delegation delegate would be unable to distinguish between a reply from the delegate and a reply from the original identity owner. Full identity delegation may thus be used in cases where the requesting entity does not need to know the sender of the requested information. In such cases, the granularity of query replies is on the system level as opposed to the individual device level. An example implementation for full identity delegation might be a sensor network in which queries are directed to the network in general but responses to such queries may involve data generated by a single sensor. Care of identity delegation ensures that a requesting entity is informed by the delegate that the information provided is sent on behalf of the original owner of the identity. This delegation mode may be used when it is important for the requesting entity to know which device is generating the information and which device is sending the information. The tracking of original identity owner may be important for system deployment in some situations. For example data received from an original identity owner may be considered more valuable than data from delegated peers, as data from an original identity owner gives additional information including for example the fact that the original identity owner is functioning and its up to date location. Each of the above delegation modes enables useful information to be provided by a network of constrained devices to a client entity, regardless of whether an original owner of a queried identity is functional, sleeping or malfunctioning. The delegation mode selected for individual deployments or for individual delegations may be selected according to a particular use case and deployment scenario. The identity and any accompanying data of a single constrained device may in some cases be delegated to multiple different peer constrained devices. The number of peers to whom an identity and data are delegated may be determined for example by how sensitive or critical the identity or data to be transferred is and/or by the number of available peer devices who can act as delegates. Transferring identity and data to multiple peers introduces redundancy into the process, increasing the chances that the data will be available when requested by an outside entity. Figure 4 illustrates a single sensor S transferring its identity to three peer constrained devices A, B and C. Each peer constrained device receives the identity of sensor S and some part of the data stored on sensor S. In some cases, all peers may receive the same data, ensuring redundancy as discussed above. In the illustrated example, different data is transferred to each peer, with peer A receiving information X, peer B receiving information Y and peer C receiving information Z. Following the transfer, if a request is received by the network for data associated with the transferred identity, different protocols may be followed by the delegate peers. In one example, each of peers A, B and C may respond to the request if they are able to satisfy it. For example, if the request is for any data held by the transferred identity, then each of peers A, B and C respond with the information they have received from the sensor S. However, if the request specifically identifies information Y, then only peer B may respond, as only peer B is in a position to satisfy the request. In an alternative example, each of the delegates may respond regardless of whether the data they hold is corresponds to the specific request received from the client entity. Delegates unable to satisfy the request may respond with an indication that they are unable to satisfy the request, or with an indication of the data that they hold. In this manner, should a request be made for data that none of the delegates is holding, the client entity will receive a response informing them that the request cannot be satisfied. If all delegates receive the same data, then multiple duplicated responses may be received to a single request. Such responses may be filtered at a network gateway or received and sorted by the requesting entity.

In some examples, different peers may be selected to receive different data on the basis of the capabilities of the different peers, their security capabilities and the importance of the data to be transferred. For example, critically important data may be transferred to a peer that is scheduled to be awake for a long period of time, that has high reliability or that satisfies high security requirements. Less critical data may be delegated to other peers. In this manner, a degree of load sharing may be established, with no one peer receiving all of the data from a delegating device. It may be envisaged that the most reliable peers may be highly in demand to act as delegates, and thus only the most critical information from a delegating peer may be transferred to such a delegate, with less critical information being transferred to other, less solicited peers. It may be envisaged that a peer constrained device D that is acting as a delegate for another constrained device E, detects imminent reduced functionality in itself. In such cases the peer device D may transfer both its own identity and data, and the identity and data that it is holding for the other device E to a third peer device F before entering a sleeping mode or otherwise ceasing to function. This "multi-hop" delegation ensures that an identity and data remain with an awake and functioning constrained device until the original owner of the identity and data resume functioning, or until some other condition is satisfied, as discussed in further detail below. It will be appreciated that the delegation scheme in a network may quickly become highly complicated once multiple delegations between different peer devices have taken place. A security delegation policy may be implemented to avoid dead-ends in the delegation structure.

Following delegation and a subsequent period of time in a sleep mode, a device that has not suffered malfunction will wake up, re-entering an active mode. At this point, the device may request its identity back from its delegate or delegates, or may inform its delegate or delegates about its new awake status, and in some examples about its next scheduled transition to sleep mode. In the event that a device does not awaken, for example following a malfunction, the device's delegates may be triggered to inform a network administrator or network management node that the device has not reawakened. Subsequent treatment of delegated identity and data, for example when the original owner of the identity and data enters or fails to enter an awake mode, is discussed in further detail below.

The process by which a peer is selected to act as a delegate, and that by which identity and data are transferred, may vary according to the nature of the network and the requirements of individual constrained devices. In static networks, the entire delegation process may be pre-programmed, with delegates selected such that they will be awake for the entire duration of the sleep period of the device for which they are to act as a delegate. This approach allows considerable pre-planning and control but does not allow for unplanned sleep periods or malfunctions, which, as discussed above, may be very common for devices in extreme environments. In order to introduce some element of flexibility, a hierarchy of suitable peers to act as delegates may be stored within each constrained device. This may be stored for example in the form of a prioritised list or table, as illustrated in Figure 5. This table may be transferred to delegate nodes in addition to identity and data, so dictating how the delegate is allowed to further pass on the identity and data in the event of multi-hop delegation. This approach may again be particularly suited to relatively static networks.

Referring to Figure 5, on detecting imminent reduced functionality, the sensor S determines that it should transfer its identity, and in some examples its data, to a delegate peer. The sensor identifies the highest priority peer from the list, peer X in the illustrated example, and attempts to secure that peer as a delegate. In some examples, the sensor S may initially request the peer X as a delegate and await a response before transferring its identity and data. In other examples, the sensor may proceed directly with attempting to transfer its identity and data, and await an acknowledgement, in the absence of which it will assume that the desired peer is unavailable. If, as in the illustrated example, the first choice peer is unavailable, for example because it is in sleep mode, is malfunctioning, or simply rejects the request, this will be apparent by the lack of a response to the delegate request, by a negative response, or by the lack of an acknowledgement to the attempted identity and data transfer. In this case, the sensor S then identifies the next peer on the list of potential delegates, in the illustrated example peer Y, and attempts to secure that peer as a delegate. As discussed, this may involve an initial request and response process or the sensor S may simply proceed directly with attempting to transfer its identity and data and await an acknowledgement. In the illustrated example, peer Y is available and receives the identity and data of the sensor S. In addition to the identity and data, peer Y also receives the delegation policy table. If peer Y later needs to enter sleep mode or detects malfunctioning before the sensor S is able to take back its identity and data, peer Y will follow the received delegation policy table for sensor S and seek to transfer the identity and data of sensor S to peer X. If peer X is unavailable, then peer Y will attempt to transfer the identity and data to peer Z. If peer Z is also unavailable then peer Y will simply enter sleep mode without transferring the identity and data. This represents a dead-end within the delegation policy.

If the sensor S delegated its identity prior to entering sleep mode, then, assuming it does not suffer some malfunction or damage while in sleep mode, it will at some later time transition back to an awake mode and seek to recover its identity or inform its delegate(s) of its new status. The sensor S contacts each of the peers in its delegation policy table in turn until it identifies the current holder of its identity. While the predefined hierarchical policy offers certain advantages in terms of planning and control, it is still unable to react efficiently to the many changes that may occur in dynamic networks, and it may also result in a single constrained device having to contact multiple peers before it located an available peer and successfully transfers its identity and data. This potentially heavy signalling load can have implications for device power, particularly in the case of wireless device to device communication, which is a relatively high consumer of energy.

In another example, the pre-defined policy table or list of Figure 5 may be replaced with a multicast group of peer constrained devices which are authorised to act, or are capable of acting, as delegates for a particular constrained device. In this manner, when a constrained device needs to wants to delegate its identity and data, it can send out a request to the multicast group, the multicast channel ensuring that only valid potential delegates will get the request. The multicast channel may in some examples be used for negotiating the delegation of the identity and data, for example using some prioritization with respect to which peer is the preferred peer for handling the device's data or a part of the device's data. The multicast channel may thus be used for locating a suitable peer, with which the device then performs the handover of identity and data via a unicast transmission. In other examples, the device may send its identity and data directly over the multicast channel and wait for acknowledgements from at least one peer within the multicast group.

The use of a multicast group offers a reduction in signaling load compared to a predefined table, as a single delegate request or initial transfer may reach all potential delegates. A constraint of this approach is that the routers in the system need to maintain multicast state. This could pose challenges for example in a sensor network in which the routers also act as sensors and have limited resources. In still further examples, a broadcast transmission may be used, either for requesting delegates or for identity and data transmission. If all peers are suitable potential delegates, a constrained device may simply broadcast its identity and data to all devices and await at least one acknowledgement to be sure that the identity and data have been accepted, and thus that a delegate has been activated. This approach has the advantages of simplicity and redundancy, with the identity and data being received by multiple peers in a single broadcast. Alternatively, for example if redundancy is not required, a request may be broadcast, with a unicast transmission used to transfer identity and data to the first positively responding peer. Broadcast transmission may also be used when only a subset of peers are suitable delegates. In one arrangement, a request for delegates may be broadcast by a constrained device. The device may then wait for a positive response from a peer device that is suitable to act as a delegate before transferring identity and data to the first suitable responding peer via a unicast transmission. Alternatively, the constrained device may broadcast its identity and data to all peers but await an acknowledgement from a suitable, trusted peer before entering sleep mode.

Broadcast transmission offers advantages in that no multicast channels need to be maintained. Broadcast transmission also offers the greatest degree of flexibility, facilitating tailored selection of delegates. For example, a constrained device having several separate items of data to transfer in addition to its identity may broadcast a request for delegates. The received responses may include device capabilities and authorities in addition to device identities for all peer devices which received the broadcast request, are currently awake, and have capacity to receive the identity and data. The delegating device may then select from amongst the responding peer devices those devices most suitable for the individual items of data. A highly trusted peer may be selected for critical data, with less reliable peers selected for less important data. This arrangement enables the maximum flexibility for constrained devices to select suitable peers, taking account of evolution within the network and device availability at any given time.

In still further examples, a combination of the above approaches may be used. For example a device might use a delegation policy table to identify a delegate and transfer data. However, when transitioning back to an awake mode after a period of reduced functionality, the device may simply broadcast its new awake status to all peer devices, knowing that the delegate device will receive the broadcast.

The requirements for a suitable delegate for any given constrained device may include reliability, scheduled awake periods, security capabilities etc. Such characteristics may be taken into account when establishing a pre-defined delegation list or table, or a multicast group, or may be communicated to a requesting node in answer to a request for delegates. In other examples, each constrained device may have a private key, and may also hold a list of public keys corresponding to peers which are authorised to act as its delegates. Whatever the means used for identifying suitable delegates, the means may be transferred to the delegate in addition to identity and data, in order to facilitate multi-hop delegation. Thus the pre-defined delegation table, the identity of a multicast group, the required characteristics or the public keys of authorised delegates may be passed to a delegate, ensuring that the requirements for suitable delegates are respected in subsequent transfers of the identity and data.

In order to avoid unnecessary use of storage in constrained devices, it may be desirable to manage the treatment of transferred identities and data in delegate devices, for example via active or passive deletion policies. According to an active deletion policy, a delegating node may contact all of its delegates on re-entering an awake mode, informing its delegates that it is now awake and instructing them to delete the delegated identity and data. Active deletion may be desirable for example in cases of important data, where it is preferred to maintain the data with an active device under all circumstances. As an alternative option, passive deletion may involve setting a trigger for deletion of the identity and/or data in the delegate node, regardless of the status of the original owner of the identity and data. The trigger may be a time threshold or may be a threshold number of requests from client entities directed to the delegated identity and which have been satisfied by transfer of the delegated data to the client entity. The threshold number of satisfied requests may be as low as one for data of low importance, or may be much higher for more important data. In some cases a passive deletion policy may dictate different actions for identity and data, for example instructing deletion of data after at least one successful transfer to a client entity, but maintenance of the identity and some basic metadata, for example informing the requesting entity that the device of the requested identity is currently sleeping and will be available at a specific time. In some situations, data transferred to a delegate node may be of critical importance to the network or other entities. It is therefore desirable that this data always be stored by a device that is awake. Before a peer acting as a delegate for the data enters a sleep mode, it transfers the critical data to an awake device and may in some examples remove the critical data from its own database. This can be achieved by having each device that is going to sleep handover all the data it is storing to a device that is awake. This means that both the device's own identity and data, and all peer identities and data that the device is currently storing, are transferred to the new delegate or delegates. The process of selecting which peer to transfer the data to and the actual transfer may follow any of the example processes discussed above but should respect the delegation policy of the original owner of the critical data, transferred to the delegate along with the critical data and its associated identity. Having transferred the critical data and identity to another device, the peer entering sleep mode may remove all but its own data from memory before entering sleep mode. Alternatively, the data could be deleted when the device wakes up. When the device wakes up it will have its own data and there will be at least one copy of the data at some other awake peer. In the event that that the device cannot find an acceptable peer to transfer the critical data to, the device may retain the data when entering sleep mode. In some cases, there is a possibility that a delegate that is still holding an identity and data for a sleeping peer is itself sleeping when the original owner of the identity and data wakes up. In this circumstance, the original owner of the identity and data will not be able to inform the sleeping delegate that it is awake and can itself continue to maintain the identity and data. A requesting entity or network gateway may then receive multiple responses to a request appearing to be from the same entity, i.e. responses from the original identity owner and from those of the original owner's former delegates that were not awake when the original owner retook control of its identity. One way to address this issue is to attach a timestamp or sequence number to data. In this manner, a gateway or requesting entity may distinguish between multiple responses from the same identity on the basis of the timestamp or sequence number, the most recent timestamp or sequence number being associated with the most up to date information.

In many situations, it may be desirable to authenticate data that is transferred, for example by signing data before it is transferred to a delegate. Figure 6 illustrates one example of how the authentication of data may be handled. In the illustrated example, a sensor S is transferring its identity and data to a peer X. In a first step 302, the sensor S signs its data, for example the latest sensor reading, and applies a timestamp or sequence number to the data. The timestamp or sequence number may also be signed, such that the signature is applied to the combination of data and timestamp or signature. The data is associated with an identifier of the owner of the data for later integrity checking. At step 304, the sensor transfers the signed data and its identity, together with any other data and identities it is currently holding, to peer X. The sensor S then enters sleep mode at step 306. Either before entering sleep mode or after waking up, the sensor S may delete all data other than its own, as the data is now the responsibility of an awake node. At step 308, the sensor wakes up. If the sensor has suffered no malfunction during the sleep mode, the sensor will still have its own data but there will also be at least one duplicate of the data in peer X. In order to avoid unnecessary consumption of memory, and assuming no redundancy is desired, the duplicate data may be deleted. The sensor S therefore transmits a message at step 310 instructing peer X to discard the data stored on behalf of the sensor S. The message sent at step 310 may be a signed message that identifies the sensor S and includes a later timestamp or sequence number than that associated with the duplicate data stored on peer X. The sensor S may also update the sequence number stored locally with the data. On receipt of the signed message, the delegate peer X verifies that it is sent by the original owner of the data, via the signature, and that the message is fresh, via the timestamp or sequence number. Assuming the verification is successful, the peer X deletes the data in step 312. If the sensor S is corrupted during the sleep such that it no longer has its own data, it will not have the associated timestamp or sequence number and will not be able to delete it from the delegate peer X. The data thus survives under the responsibility of peer X and any awake node to which peer X delegates.

Figure 7 is a flow chart illustrating an example process in a constrained device, which process demonstrates some of the above discussed options for selection of delegates, transfer of data, and deletion of data. The process illustrated in Figure 7 shows one way in which the process steps of the method 100 of Figure 2 may be subdivided and supplemented to suit a particular operating situation. Figure 7 illustrates an example in which delegates are requested before a transfer of identity and data is made. However, the possibility of later delegate selection via a check on acknowledgements is also discussed, for example if identity and data transfer are made via a broadcast transmission without first requesting delegates. Referring to Figure 7, in a first step 1 10a, a constrained device checks whether or not evidence of a fault or malfunction has been detected within itself. If a fault has been detected, the device moves directly to step 1 12. If no fault is detected, the device checks in step 1 10b whether or not a transition to sleep mode is imminent, for example whether a scheduled transition time to sleep mode is within a threshold time limit from the current time. If sleep is not imminent, the device returns to step 1 10a, checking for a fault. If sleep is imminent, the device proceeds to step 1 12. At step 1 12, the device sends a request to peer devices to act as delegates. As discussed above, this may be via a unicast, multicast or broadcast transmission, and may involve requesting only availability, or may involve additionally requesting capabilities or authorities of the peer devices. In further examples the request may be signed with a private key, such that authorised devices having the corresponding public key may verify the signature. In still further examples, the request may include an indication that responding devices should sign their response. In this manner the device may check the signed responses against a list of public keys for authorised devices. The device then checks at step 1 14 whether at least one response has been received to the request. If a response has been received, the device then selects delegates at step 1 16. This selection may be informed by delegation policy 1 18, as discussed above.

Having selected a suitable delegate or delegates, the constrained device then checks, at step 120, whether or not it is currently acting as a delegate for another constrained device in the network. If the constrained device is not currently acting as a delegate, it proceeds directly to identity and data transfer in step 130. If, however, the device is currently acting as a delegate for another constrained device, the constrained device first checks, in step 122, whether the peer device or devices selected in step 1 16 are authorised or suitable to act as delegates for the sleeping peer, for which the subject constrained device is currently acting as a delegate. If the selected peer or peers are not suitable or authorised to act as delegate for the sleeping peer, the device returns to step 1 16 to select additional peers that are authorised to receive the identity for which it is currently acting as a delegate. This may involve sending a new request for delegates, returning to step 1 12. The originally identified delegates may receive the device's own identity and data, and the additional delegates may receive the identity and data for which the device is currently acting as a delegate. Once suitable peers have been selected both for the subject constrained device and for any identities that the device is currently holding as a delegate, the device proceeds to step 130 and transfers its identity and data, together with any identities and data that it is holding for other devices, to the selected peer or peers. In step 132, the device checks for an acknowledgement of the transfer. The device may consult delegation policy 134 at this stage, for example if the request, response and selection steps have not been conducted. In such cases, the device will consult the delegation policy 134 and await an acknowledgement of transfer from a peer that is authorised to receive the transferred identity and data.

On receipt of a suitable acknowledgement, the constrained device enters sleep mode at step 136. At step 138, the constrained device checks whether it is time to re-enter active mode. At step 140, the constrained device re-enters an active mode and at step 142 the constrained device instructs its delegates to delete its identity and data, now that the constrained device is no longer sleeping.

It will be appreciated that the process of Figure 7 is merely one example way in which some of the above discussed options for delegate selection, data transfer and data management may be implemented. Other implementations may be envisaged in accordance with the above disclosure.

Figure 8 illustrates functional units in a constrained device 400 which may execute the steps of the methods of Figures 2 and 7, for example according to computer readable instructions received from a computer program. The constrained device 400 comprises a detecting unit 452 and a communication unit 454. The constrained device 400 may further comprise an authentication unit 456, a timing unit 458, a selection unit 460 and a memory 462. The detection unit may comprise a malfunction detection unit 452a and a sleep timer 452b. It will be understood that the units are functional units, and may be realised in any appropriate combination of hardware and/or software.

The detecting unit 452 is configured to detect that functionality of the constrained device 400 will be reduced within a threshold period of time. The malfunction detection unit 452a within the detecting unit 452 is configured to detect evidence of a malfunction within the constrained device. The sleep timer 452b within the detecting unit 452 is configured to monitor programmed transitions to sleep mode for the constrained device. The communication unit 454 is configured to transfer the identity of the constrained device 400 to another of the constrained devices in the network, and may also be configured to transfer data held by the constrained device to the other constrained device within the network. The communication unit 454 may be configured to transfer the identity and data of the constrained device to a plurality of other constrained devices in the network and may be configured to transfer different data to different ones of the plurality of other constrained devices in the network according to at least one of importance of the data and capabilities of the plurality of other constrained devices. The communication unit 454 may also be configured to request another constrained device in the network to receive the identity of the constrained device, for example via a unicast, multicast or broadcast transmission. The communication unit 454 may also be configured to receive responses to such a request and to receive transfer confirmations or acknowledgements following identity and data transfer.

The constrained device may be configured to enter sleep mode following confirmation of identity transfer from the communication unit 454. On awaking from sleep mode, the communication unit may be configured to instruct peer constrained devices which have received the device identity to delete the identity. The communication unit 454 may be configured to communicate with other constrained devices via at least one of a cellular network, an optical network, a wired network, a wireless local area network, or via Radio Frequency Identification, RFID.

The selection unit 460 may be configured to select at least one peer constrained device in the network to receive the transferred identity and data. The selecting unit may select from among peer constrained devices responding to a request for delegates. The selecting unit may select on the basis of a delegation policy, which may be stored in the memory 462. The memory may also be configured to store a deletion policy and the identities and data of the constrained device 400 and of any other constrained devices for which the constrained device is acting as a delegate. The communication unit 454 may be configured to transfer either or both of the delegation or deletion policy with the identity and data of the device. The communication unit 454 may also be configured to transfer the identities and data of any other constrained devices for which the constrained device is acting as a delegate. The authentication unit 456 is configured to authenticate the source of the data held by the constrained device, for example by signing the data before it is transferred. The timer unit 458 is configured to apply at least one of a time stamp or a sequence number to the data held by the constrained device 400 before transferring the data.

The constrained device 400 may for example comprise a sensor or actuator, and may be comprised within a delay tolerant network.

Figure 9 illustrates functional units in a constrained device 500 which may execute the steps of the method of Figure 3, for example according to computer readable instructions received from a computer program. The constrained device 500 comprises a receiving unit 572, a request unit 576 and a response unit 578. The receiving, request and responding units may be comprised within a communication unit 554. It will be understood that the units are functional units, and may be realised in any appropriate combination of hardware and/or software.

The receiving unit 572 is configured to receive an identity of another constrained device in the network. The communication unit may be configured to send a transfer confirmation to the other constrained device on receipt of the identity. The receiving unit may also be configured to receive a request from the other constrained device to receive the identity of the other constrained device, and the communication unit 554 may be configured to respond to the request from the other constrained device.

The request unit 574 is configured to receive a request directed to the received identity, for example from a client or server. The response unit 576 is configured to respond to the request. The constrained device 500 may also comprise a memory configured to store the received identity. The constrained device 500 may further comprise a deletion unit configured to check for a deletion policy associated with the received identity and, if a deletion policy is associated with the received identity, to delete the received identity at a time and in a manner in accordance with the deletion policy.

Figure 10 illustrates an alternative example of a constrained device 600, which may implement the methods of Figure 2, 3 or 7 for example on receipt of suitable instructions from a computer program. Referring to Figure 10, the constrained device 600 comprises a processor 682 and a memory 684. The memory 684 contains instructions executable by the processor 682 such that the constrained device 600 is operative to conduct the steps described above in connection with any of the methods of Figure 2, 3 or 7.

Aspects of the present invention thus enable the continuing functioning of a device identity even when that device is experiencing reduced functionality. This is particularly advantageous for constrained devices operating in harsh environments, for which periods of time in low power states may be required in order to conserve energy, and for which malfunction and damage are highly likely within device operational lifetime. The possibility of losing critical information stored within a device is decreased by transferring device identity and data to a peer device before entering sleep mode or becoming unable to function. By transferring identity and data to a peer constrained device rather than transferring data to a mirror server, the issue of network connectivity is addressed, as peer-to-peer communication within the device network is more reliable than connectivity of the constrained device network with a public network such as the internet. The distributed nature of the solution ensures that no one device represents a single network point of failure, redundancy may be introduced to ensure that critical information is held by multiple peers, and so remains available for access.

The methods of the present invention may be implemented in hardware, or as software modules running on one or more processors. The methods may also be carried out according to the instructions of a computer program, and the present invention also provides a computer readable medium having stored thereon a program for carrying out any of the methods described herein. A computer program embodying the invention may be stored on a computer readable medium, or it could, for example, be in the form of a signal such as a downloadable data signal provided from an Internet website, or it could be in any other form.

It should be noted that the above-mentioned examples illustrate rather than limit the invention, and that those skilled in the art will be able to design many alternative embodiments without departing from the scope of the appended claims. The word "comprising" does not exclude the presence of elements or steps other than those listed in a claim, "a" or "an" does not exclude a plurality, and a single processor or other unit may fulfil the functions of several units recited in the claims. Any reference signs in the claims shall not be construed so as to limit their scope.

Claims

1 . A method (100) for managing a constrained device which is one of a plurality of constrained devices within a network, each constrained device in the network having a device identity, the method comprising:

detecting that functionality of the constrained device will be reduced within a threshold period of time (1 10); and

transferring the identity of the constrained device to another of the constrained devices in the network (130).

2. A method as claimed in claim 1 , wherein detecting that functionality of the constrained device will be reduced within a threshold period of time (1 10) comprises detecting at least one of:

a programmed transition to sleep mode for the constrained device within the threshold period of time (1 10b) ; or

evidence of a malfunction within the constrained device (1 10a).

3. A method as claimed in claim 1 or 2, further comprising transferring data held by the constrained device to the other constrained device in the network (130).

4. A method as claimed in claim 3, further comprising authenticating the source of the data held by the constrained device before transferring the data.

5. A method as claimed in claim 3 or 4, further comprising applying at least one of a time stamp or a sequence number to the data held by the constrained device before transferring the data.

6. A method as claimed in any one of the preceding claims, further comprising transferring the identity of the constrained device to a plurality of other constrained devices in the network (130).

7. A method as claimed in claim 6, further comprising transferring data held by the constrained device to the plurality of other constrained devices in the network (130).

8. A method as claimed in claim 7, further comprising transferring different data to different ones of the plurality of other constrained devices in the network.

9. A method as claimed in claim 8, wherein different data is transferred to different ones of the plurality of other constrained devices in the network according to at least one of importance of the data and capabilities of the plurality of other constrained devices.

10. A method as claimed in any one of the preceding claims, further comprising transferring an identity of a third constrained device in the network to the other constrained device in the network, wherein the identity of the third constrained device is stored in the constrained device following transfer to the constrained device from the third constrained device.

1 1 . A method as claimed in any one of the preceding claims, further comprising transferring a deletion policy for the identity to the other constrained device in the network.

12. A method as claimed in any one of the preceding claims, further comprising transferring a delegation policy to the other constrained device in the network.

13. A method as claimed in one of the preceding claims, further comprising requesting another constrained device in the network to receive the identity of the constrained device (1 12).

14. A method as claimed in claim 13, wherein requesting another constrained device (1 12) comprises transmitting a unicast request to a single constrained device.

15. A method as claimed in claim 13 or 14, wherein requesting another constrained device (1 12) comprises transmitting a multicast request to a group of constrained devices.

16. A method as claimed in any one of claims 13 to 15, wherein requesting another constrained device (1 12) comprises transmitting a broadcast request to all other constrained devices in the network.

17. A method as claimed in any one of claims 13 to 16, further comprising receiving a response to the request from a responding constrained device (1 14), and transferring the identity of the constrained device to the responding constrained device (130).

18. A method as claimed in claim 17, further comprising:

receiving responses to the request from multiple responding constrained devices

(1 14);

selecting at least one responding constrained device (1 16); and

transferring the identity of the constrained device to the at least one selected responding constrained device (130).

19. A method as claimed in any one of the preceding claims, further comprising receiving a transfer confirmation from the other constrained device (132).

20. A method as claimed in any one of the preceding claims, further comprising entering a sleep mode following transfer of the identity of the constrained device (136).

21 . A method as claimed in claim 20, further comprising awaking from a sleep mode (140) and instructing the other constrained device to delete the identity of the constrained device (142).

22. A method as claimed in any one of the preceding claims, wherein the constrained device comprises a sensor.

23. A method as claimed in any one of the preceding claims, wherein the network comprises a delay tolerant network.

24. A method as claimed in any one of the preceding claims, wherein communication between constrained devices of the network is effected via at least one of:

a cellular network;

an optical network;

a wired network;

a wireless local area network, or

via Radio Frequency Identification, RFID.

25. A method as claimed in any one of the preceding claims, wherein transferring the identity of the constrained device to another of the constrained devices in the network (130) comprises explicitly communicating the identity of the constrained device to the other constrained device.

26. A method as claimed in any one of the preceding claims, wherein transferring the identity of the constrained device to another of the constrained devices in the network (130) comprises implicitly communicating the identity of the constrained device to the other constrained device.

27. A method (200) for managing a constrained device which is one of a plurality of constrained devices within a network, each constrained device in the network having a device identity, the method comprising:

receiving an identity of another constrained device in the network (250);

receiving a request directed to the received identity (260); and

responding to the request (270).

28. A method as claimed in claim 27, further comprising:

checking for a deletion policy associated with the received identity; and if a deletion policy is associated with the received identity, deleting the received identity at a time and in a manner in accordance with the deletion policy.

29. A method as claimed in claim 27 or 28, further comprising sending a transfer confirmation to the other constrained device on receipt of the identity of the other constrained device.

30. A method as claimed in any one of claims 27 to 29, further comprising:

receiving a request from the other constrained device to receive the identity of the other constrained device; and

responding to the request.

31 . A computer program product configured, when run on a computer, to carry out a method according to any one of the preceding claims.

32. A constrained device (400) which is one of a plurality of constrained devices within a network, each constrained device in the network having a device identity, the constrained device (400) comprising:

a detecting unit (452) configured to detect that functionality of the constrained device will be reduced within a threshold period of time; and

a communication unit (454) configured to transfer the identity of the constrained device to another of the constrained devices in the network.

33. A constrained device which is one of a plurality of constrained devices within a network, each constrained device in the network having a device identity, the constrained device comprising:

a receiving unit (572) configured to receive an identity of another constrained device in the network;

a request unit (574) configured to receive a request directed to the received identity; and

a response unit (576) configured to respond to the request.

34. A constrained device (600) which is one of a plurality of constrained devices within a network, each constrained device in the network having a device identity, the constrained device comprising a processor (682) and a memory (684), the memory

(684) containing instructions executable by the processor (682) such that the constrained device is operable to:

detect that functionality of the constrained device will be reduced within a threshold period of time; and

transfer the identity of the constrained device to another of the constrained devices in the network.

35. A constrained device (600) which is one of a plurality of constrained devices within a network, each constrained device in the network having a device identity, the constrained device comprising a processor (682) and a memory (684), the memory (684) containing instructions executable by the processor (682) such that the constrained device is operable to:

receive an identity of another constrained device in the network;

receive a request directed to the received identity; and

respond to the request.