Abstract:
A machine implemented method of server initiated registration of a remote device with a second server when the remote device is provisioned or pre-provisioned for registration with a first server, the method comprising: transmitting a bootstrap message from a bootstrap server to the first server, the bootstrap message comprising instruction for registration of the remote device with the second server; receiving the bootstrap message at the first server; sending, from the first server, the bootstrap message to the remote device; and registering the remote device with the second server.

Description:
RELATED APPLICATION 
       [0001]    The present application claims priority to GB Application No. 1513750.8 filed Aug. 3, 2015, which is hereby incorporated herein in its entirety by reference. 
       TECHNICAL FIELD 
       [0002]    The present techniques relate, in general, to a server initiated method of registration of a remote device or devices with a second server when the remote device or devices have already been registered with or are pre-provisioned to register with a first server. The present techniques include, where necessary, de-registering the remote device from the first server. 
       BACKGROUND ART 
       [0003]    The Internet of Things encompasses devices and networks that are IP-enabled and Internet-connected, along with the Internet services monitoring and controlling those devices. Such IP-enabled devices connected to the internet may be termed data processing devices, end nodes, remote devices or Internet of Things (IoT) devices and include sensors, machines, active positioning tags, radio-frequency identification (RFID) readers and building automation equipment to name but a few. Data exchange between programs, computers and Machine-to-Machine (M2M) is a vital element of the Internet of Things and different programs, computers and processors are used in different environments. 
         [0004]    The Wireless Embedded Internet is a subset of the Internet of Things and is generally represented by resource-limited embedded devices, often battery powered and connected by low-power, low-bandwidth wireless networks to the Internet. 
         [0005]    An example of a network technology where Machine-to-Machine (M2M) communication is widely applied is a low-power wireless network, such as an IEEE 802.15.4 based embedded and sensor network. More recently, as M2M devices have become IP enabled, systems have become more open by using IP as a networking protocol. 
         [0006]    Following the introduction of IEEE 802.15.4 other standards were developed to standardize an IP adaption for such wireless embedded links. For example, the IPv6 over Low Power Wireless Standard (6LoWPAN) is a set of standards which enable the efficient use of IPv6 over low-power, low-rate wireless networks on simple embedded devices through an adaption layer and the optimization of related protocols. 
         [0007]    The Open Mobile Alliance Lightweight LWM2M is a standard applicable to  6 LoWPAN and is focussed on constrained cellular and M2M devices. A Lightweight Machine-to-Machine (LWM2M) Bootstrap process is used to provide mandatory information through the Bootstrap Interface for remote devices so that they can perform registration with one or more servers. Registration assigns a remote device to a cloud based server to access applications across a domain. A domain may be a logical grouping of devices and when the domain is exported to Domain Name System (DNS), then the domain value normally equates to the DNS domain name. 
         [0008]    Techniques described herein provide additional features to the LWM2M Bootstrap process. 
       SUMMARY OF THE INVENTION 
       [0009]    In a first aspect present techniques provide a machine implemented method of server initiated registration of a remote device with a second server when the remote device is provisioned or pre-provisioned for registration with a first server, the method comprising: transmitting a bootstrap message from a bootstrap server to the first server, the bootstrap message comprising instruction for registration of the remote device with the second server; receiving the bootstrap message at the first server; sending the bootstrap message from the first server to the remote device; and registering the remote device with the second server. 
         [0010]    In a second aspect, the present techniques provide a machine implemented method of server initiated registration of a remote device with a second server when the remote device is provisioned or pre-provisioned for registration with a first server, the method comprising: receiving a bootstrap message at the first server, the bootstrap message comprising at least the location of the second server; sending, from the first server, the bootstrap message to the remote device; and communicating between the remote device and the first server to cause the remote device to register with the second server. 
         [0011]    In this way, a bootstrap server may successfully cause a remote device to register with a server using another server as a proxy server. 
         [0012]    Techniques may include transmitting the bootstrap message from a bootstrap server to the first server. This may be a chosen method if the bootstrap server comprises the information to be transmitted otherwise the information may be delivered to the first server from other sources. 
         [0013]    Prior to transmitting the bootstrap message from the bootstrap server to the first server, the method may include transmitting the bootstrap message from the bootstrap server to the remote device, the bootstrap server and the remote device failing to establish a successful connection. In response to a failed connection between bootstrap server and remote device, the present techniques provide a way for successful bootstrapping to be completed. The bootstrap server may broadcast its bootstrap message, which may be useful if the bootstrap server does not know the address of a first server. In order to reduce network traffic, the bootstrap server may store multiple bootstrap messages and transmit the multiple bootstrap messages to the first server in one bulk message. The bootstrap message may comprise instruction for the remote device to bootstrap with the bootstrap server, which may be desirable if, for example, the bootstrap server has a higher level of trust with the remote device or if it is not wanted to send complete bootstrapping information to the remote device via a second server. When bootstrapping with the bootstrap server, the bootstrap server returns a bootstrap message to the remote device comprising at least the address of the second server. Alternatively, the bootstrap message comprises instruction for the remote device to bootstrap with the second server, the bootstrap message comprising at least the address of the second server. 
         [0014]    Prior to registering the remote device at the second server, the method may include de-registering the remote device from the first server. In order to manage and reduce network traffic, the first server may receive a plurality of bootstrap messages and queue the plurality of bootstrap messages in a memory store. Such a technique may enable the bootstrap message to be sent to the remote device in response to a communication from the remote device to the first server. In a mesh network, such a low power, wireless network the remote device, the first device and the second server may be nodes in a peer network and the remote device may be an Internet of Things device. 
         [0015]    In a third aspect, present techniques provide a machine implemented method of server initiated registration of a remote device with a second server when the remote device is provisioned or pre-provisioned with a first server, the method comprising: receiving a bootstrap message from the first server at the remote device, the bootstrap message comprising instruction for registration of the remote device with the second server; and registering the remote device with the second server. The remote device can therefore be bootstrapped with a second server. The bootstrap message may comprise instruction for the remote device to bootstrap with the bootstrap server in which case the remote device receives a bootstrap message from the bootstrap server comprising at least the address of the second server; or the bootstrap message may comprise instruction for the remote device to bootstrap with the second server, in which case the bootstrap message comprises at least the address of the second server. Further, prior to registering the remote device at the second server, the method may include de-registering the remote device from the first server. 
         [0016]    In a fourth aspect, present techniques provide a machine implemented method of server initiated registration of a remote device with a second server when the remote device is provisioned or pre-provisioned for registration with a first server, the method comprising: transmitting a bootstrap message from a bootstrap server to the first server; receiving the bootstrap message at the first server, the bootstrap message comprising instruction for the remote device to carry out registration; sending the bootstrap message from the first server to the remote device; and registering the remote device with the second server. 
         [0017]    In a fifth aspect, present techniques provide a machine implemented method of server initiated registration of a remote device with a second server when the remote device is provisioned or pre-provisioned with a first server, the method comprising: receiving a bootstrap message from the first server at the remote device, the bootstrap message comprising instruction for registration of the remote device; and registering the remote device with the second server. 
     
    
     
       BRIEF DESCRIPTION OF DRAWINGS 
         [0018]    Embodiments will now be described, by way of example only, and with reference to the accompanying drawings of which: 
           [0019]      FIG. 1  is a schematic diagram of a LWM2M deployment scenario; 
           [0020]      FIG. 2  is a schematic diagram of a LWM2M architecture with Server and Client; 
           [0021]      FIG. 3  is a schematic diagram of a LWM2M object model; 
           [0022]      FIG. 4  is a schematic diagram of a client initiated bootstrap ( FIG. 4 a   ) and a server initiated bootstrap ( FIG. 4 b   ); 
           [0023]      FIG. 5  is a schematic diagram of a bootstrap process to assign a new LWM2M server for a single remote device in a non-queue mode; 
           [0024]      FIG. 6  is a schematic diagram of a bootstrap process to assign a new LWM2M server for a single remote device in a queue mode; 
           [0025]      FIG. 7  is a schematic diagram of a bootstrap process to assign a new LWM2M server for a single remote device where the remote device is instructed to connect to the bootstrap server to receive the bootstrap information; 
           [0026]      FIG. 8  is a schematic diagram of a bootstrap process to assign a new LWM2M server for a single remote device where the remote device has not yet been registered with its assigned LWM2M server; 
           [0027]      FIGS. 9 and 10  are schematic diagrams of a bootstrap process to assign another LWM2M server for a single remote device; and 
           [0028]      FIG. 11  is a schematic diagram of a bootstrap process when first registration occurs with a newly assigned LWM2M server. 
       
    
    
     DETAILED DESCRIPTION 
       [0029]    Referring to  FIG. 1  a deployment scenario for an M2M remote device  10  is shown across a range of market segments from streetlights and electric meters to home and building automation. The remote devices  10  may interface  12  with a LWM2M server  16  based on open IETF standards such as Constrained Application Protocol (CoAP) over a low-power wireless network. One such low-power wireless network is an IEEE 802.15.4 based embedded and sensor network using IPv6 over Low Power Wireless Standard (6LoWPAN)  14 . The LWM2M server  16  can interface with the wider world-wide web network  18  enabling deployment of M2M applications from a private server, private cloud or public cloud environment  19 . 
         [0030]      FIGS. 2 and 3  show the LWM2M architecture  20  which technically defines the application layer communication protocol for use between a client  22  on the M2M remote device  10  and server software on a LWM2M server  16 . The client  22  resides on the device  10  and is integrated as a software library or a built-in function of a module or device  10 . The server  16  is located in a private or public data center and can be hosted by the M2M Service Provider, Network Service Provider or Application Service Provider. Four logical interfaces are defined between the server and client, namely bootstrapping  24  being pre-provisioned or client/server initiated; registration  26  to register the client  22  and its objects  50 ; object/resource access or device management  28  to enable server  16  access to an Object  50  or resource  48 ; and information reporting  30  for notifications with new resource  48  values. 
         [0031]    The LWM2M protocol stack  32  uses the Constrained Application Protocol (CoAP)  34  as the underlying transfer protocol over User Datagram Protocol (UDP) and Short Message Server (SMS) bearers  36 . The CoAP protocol  34  defines the message header, request/response codes, message options and retransmission mechanisms. The CoAP protocol  34  is an alternative to HTTP for Representational State Transfer (RESTful) Application Programming Interfaces (APIs) on resource-constrained devices  10  and supports the methods of GET, POST, PUT, DELETE, which can be mapped to those of HTTP. Unlike HTTP, CoAP messages are exchanged asynchronously between CoAP end-points over a datagram-oriented transport such as UDP. CoAP messages are encoded in a binary format allowing functionality to start with a 4-byte overhead. LWM2M defines the UDP Binding with CoAP as mandatory whereas the SMS Binding with CoAP is optional, which in effect means that LWM2M client  22  to server  16  interaction may occur both via SMS and UDP  36 . 
         [0032]    The LWM2M architecture  20  use security protocols to secure communications between client  22  and server  16  using a Datagram Transport Layer Security (DTLS)  38 . DTLS  38  is used to provide a secure channel between the LWM2M server  16  and the LWM2M client  22  for all efficient payloads  40 . The efficient payloads  40  can be plain text for individual resources and Binary TLV or JSON for resource batches (Object or Resource Arrays). DTLS  38  security modes include both pre-shared key and public key technology to support embedded devices  10 . 
         [0033]    M2M application  42  developers can manage the devices  10  remotely through a M2M web application  44  and a M2M device management application  46 . 
         [0034]    Referring to  FIG. 3 , the client  22  illustrated in  FIG. 2  is shown in more detail. Each piece of information made available by the LWM2M client  22  is a Resource  48 . A Resource  48  is a piece of information that can be read, written or executed and is accessed with URIs: 
         [0035]    /{Object ID}/{Object Instance]/[Resource ID}, for example /3/0/1 (Device Object, Manufacturer Resource). 
         [0036]    The Resources  48  are further logically organized into Objects  50 . Each LWM2M client  22  can have any number of Resources  48 , each of which belongs to an Object  50 . For example, a Firmware Object  52  may contain all the Resources  54  used for firmware update purposes. 
         [0037]    Although not shown in  FIG. 3 , a set of objects for device management purposes include: 
         [0038]    Security object to handle security aspects between management servers  16  and the client  22  on the device  10 ; 
         [0039]    Server object to define data and functions related to the management server  16 ; 
         [0040]    Access control object to define for each of several permitted management servers  16  the access rights the servers  16  have for each data object on the client  22 ; 
         [0041]    Device object to detail resources on the M2M device  10  related to device  10  specific information; 
         [0042]    Location object to group those resources that provide information about the current location of the M2M device  10 ; 
         [0043]    Connectivity object to group together resources on the M2M device  10  that assist in monitoring the status of a network connection; and 
         [0044]    Connection statistics object to group together resources on the M2M device  10  that hold statistical information about an existing network connection. 
         [0045]    As an example, the device object allows remote retrieval of device information such as manufacturer, model, power information, free memory and error information. Furthermore the device object provides a resource for initiation of a remote reboot or factory reset. 
         [0046]    As discussed in more detail with reference to  FIG. 4 , the LWM2M standard defines a provisioning and bootstrapping  24  functionality that allows the server  16  to manage the keying, access control and configuration of the device  10  to enroll with the server  16 . The LWM2M Bootstrap server is used to provide information through the Bootstrap Interface  24  for client  22  so that the client  22  can perform its registration with one or more servers  16 . After the bootstrap sequence, the client  22  has a server account and optionally some other object instances such as Access Control or Connectivity Object. 
         [0047]    Bootstrapping for complete provisioning and key management may be pre-configured bootstrapping such as from Flash; smart card bootstrapping such as from a SIM card or use of a bootstrap server for initial setup or re-configuration and keying in the modes client-initiated bootstrapping and server-initiated bootstrapping. 
         [0048]    In its most simplified form as shown in  FIG. 4 a    a client initiated bootstrap comprises a request for bootstrap for a remote device at step  60  from a LWM2M client  62 . In response, a LWM2M bootstrap server  64  provides a provision of LWM2M server objects  66  to the LWM2M client  62 . Typically, a bootstrap server  64  gives a device server&#39;s information according to OMA LWM2M. These may include the address, such as the IP address, the security mode of the device server or the address only. 
         [0049]    Referring to  FIG. 4 b    a server initiated bootstrap comprises a provision of LWM2M server objects  66  only from LWM2M bootstrap server  64  to LWM2M client  62 . 
         [0050]    A remote device may be pre-provisioned with information of an assigned server or it may receive information of an assigned server as part of the bootstrapping process. In either case it may be desirable to assign a remote device to another server so that the remote device will register with that different cloud based server. The another server may be in addition to, or in place of, the first server. 
         [0051]    In both these cases, prior art techniques require that the bootstrap server needs to be able to connect to the remote device in order to provision the remote device with new information including at least the address of the another server. 
         [0052]    Techniques disclosed herein address those cases where the bootstrap server cannot connect to the remote device. This may be because the bootstrap server does not know the remote device&#39;s address, perhaps because the address has changed since the initial bootstrapping and provisioning. Further, the remote device may be switched-off or asleep causing a communication time-out, or the remote device may be inaccessible for being protected behind a firewall or Network Address Translator (NAT). Present techniques also address those cases where the remote device is pre-provisioned with an assignment of a server and needs to be re-provisioned with another server in addition to or in place of the server. 
         [0053]    Further techniques and embodiments will now be described with reference to  FIGS. 5 to 10 . Throughout the following description, like references shall be used to describe like parts and process steps. 
         [0054]      FIG. 5  is a schematic diagram of a bootstrap process to assign a new LWM2M server for a single remote device in a non-queue mode according to present techniques. 
         [0055]    The bootstrap process includes a remote device  70 , a bootstrap server  72 , a LWM2M server  74  and a new LWM2M server  76 . At step  78  a server initiated bootstrap is initiated and the bootstrap server  72  attempts to connect to the remote device  70 . The bootstrap server  78  fails at step  80  to connect to the device  70 . The bootstrap server  78  then attempts to connect with the LWM2M server  74  at step  82  and upon establishing a successful connection delivers the bootstrap information to the LWM2M server  74 . Since the LWM2M server  74  has previously been provisioned with the remote device  70 , the LWM2M server  74  is able to connect to the remote device  70  and deliver the bootstrap information to the remote device  70  at step  84 . Upon receiving the bootstrap information the remote device de-registers with the LWM2M server  74  at step  86  and at step  88  registers with new LWM2M server  76 . 
         [0056]      FIG. 6  is a schematic diagram of a bootstrap process to assign a new LWM2M server for a single remote device in a queue mode according to present techniques. 
         [0057]    The bootstrap process includes the remote device  70 , the bootstrap server  72 , the LWM2M server  74  and the new LWM2M server  76 . At step  78  a server initiated bootstrap is initiated and the bootstrap server  72  attempts to connect to the remote device  70 . The bootstrap server  78  fails at step  80  to connect to the device  70 . The bootstrap server  78  then attempts to connect with the LWM2M server  74  at step  82  and upon establishing a successful connection delivers the bootstrap information to the LWM2M server  74 . The LWM2M server  74  has previously been provisioned with the remote device  70  and so the LWM2M server  74  is able to connect to the remote device  70  and deliver the bootstrap information to the remote device  70 . Rather than deliver the bootstrap information to the remote device  70  immediately, the bootstrap information is queued by the LWM2M server  74  in step  90 . An ability to queue the bootstrap information may be useful if the remote device  70  is only periodically awake and during the time when the remote device  70  is powered down, it may not be possible for the LWM2M server  74  to connect to the remote device  70 . The remote device  70  may also only periodically connect to the network. For example, a remote device  70  programmed as a rain sensor may power up only periodically when internet connection is available or when a certain amount of rain data has been accumulated. Therefore, at step  92 , the remote device  70  sends a message, which may be in the form of data information, to the LWM2M server  74 . Upon receipt of the message from the remote device  70  the LWM2M server  74  sends the queued bootstrap information to the remote device  70 , step  94 . Upon receiving the bootstrap information the remote device de-registers with the LWM2M server  74  at step  86  and at step  88  registers with new LWM2M server  76 . 
         [0058]      FIG. 7  is a schematic diagram of a bootstrap process to assign a new LWM2M server for a single remote device where the remote device is instructed to connect to the bootstrap server to receive the bootstrap information according to present techniques. 
         [0059]    The bootstrap process includes the remote device  70 , the bootstrap server  72 , the LWM2M server  74  and the new LWM2M server  76 . At step  78  a server initiated bootstrap is initiated and the bootstrap server  72  attempts to connect to the remote device  70 . The bootstrap server  78  fails at step  80  to connect to the remote device  70 . At step  96 , a message from the bootstrap server  72  to the LWM2M server  74  is sent, which comprises instructions that the remote device  70  may (in the sense that the remote device should or must) bootstrap with the bootstrap server  72  in the form of a bootstrap request. At step  98 , the bootstrap request is sent from the LWM2M server  74  to the remote device  70  and upon receiving the bootstrap request the remote device connects to the bootstrap server  72  (step  100 ) and receives bootstrap information from the bootstrap server  72  (step  102 ). Upon receiving the bootstrap information the remote device de-registers with the LWM2M server  74  at step  86  and at step  88  registers with new LWM2M server  76 . 
         [0060]      FIG. 8  is a schematic diagram of a bootstrap process to assign a new LWM2M server for a single remote device where the remote device has not yet been registered with its assigned LWM2M server  76 . The remote device  70  may, for example, have been pre-provisioned to connect to a LWM2M server  76  and may have not yet been switched on or may be in the property of the manufacturer or distributor. 
         [0061]    The bootstrap process includes the remote device  70 , the bootstrap server  72 , the LWM2M server  74  and the new LWM2M server  76 . At step  78  a server initiated bootstrap is initiated and the bootstrap server  72  attempts to connect to the remote device  70 . The bootstrap server  78  fails at step  80  to connect to the remote device  70 . The bootstrap server  78  then attempts to connect with the LWM2M server  74  at step  82  and upon establishing a successful connection delivers the bootstrap information to the LWM2M server  74 . However, at step  104  the LWM2M server  74  cannot find the remote device  70  because the remote device  70  has not yet completed its first bootstrapping and provisioning steps to connect to the LWM2M server  74 . According the LW2M2M server queues the bootstrap information at step  106 . 
         [0062]    When the remote device  70  is activated it should follow known bootstrapping and provisioning steps in order to arrive at a step of registration  108  with its assigned L2M2M server  74 . Although the registration  108  is successful, the L2M2M server replies with the queued bootstrap information at step  110 . Upon receiving the bootstrap information the remote device  70  de-registers with the LWM2M server  74  at step  86  and at step  88  registers with new LWM2M server  76 . 
         [0063]      FIGS. 9 to 10  are schematic diagrams of a bootstrap process to assign another LWM2M server for a single remote device. The another LWM2M server may be in addition to the existing assigned LWM2M server or may be in replace of the existing assigned LWM2M server. 
         [0064]    Referring to  FIG. 9 , the bootstrap process includes a remote device  70 , a bootstrap server  72 , a LWM2M server  74  and a new LWM2M server  76 . At step  78  a server initiated bootstrap is initiated and the bootstrap server  72  attempts to connect to the remote device  70 . The bootstrap server  78  fails at step  80  to connect to the device  70 . The bootstrap server  78  then attempts to connect with the LWM2M server  74  at step  82  and upon establishing a successful connection delivers the bootstrap information to the LWM2M server  74 . 
         [0065]    The LWM2M server  74  has either previously been provisioned with the remote device  70  and so knows the address of the remote device  70  because it is registered with the remote device  70  or has not yet been provisioned with the remote device  70  but has been provided with a list of device identifications and addresses by a third party (which could be the bootstrap server  72 ). 
         [0066]    In either scenario, the LWM2M server  74  is able to connect to the remote device  70  and deliver the bootstrap information to the remote device  70  at step  84 . Upon receiving the bootstrap information the remote device registers with new LWM2M server  76  at step  88 . No de-registration step  86  is required because either the remote device  70  has not yet registered with the LWM2M server  74  or is registering the new LWM2M server  76  in addition to the L2M2M server  74 . 
         [0067]    Referring to  FIG. 10 , and at step  104 , the LWM2M server  74  cannot find the remote device  70  because the remote device  70  has not yet completed its first bootstrapping and provisioning steps to connect to the LWM2M server  74 . According the LW2M2M server queues the bootstrap information at step  106 . 
         [0068]    When the remote device  70  is activated it should follow known bootstrapping and provisioning steps in order to arrive at a step of registration  108  with its assigned L2M2M server  74 . If the registration  108  is successful, the L2M2M server replies with the queued bootstrap information at step  110  and at step  88  registers with new LWM2M server  76  in addition to the LWM2M server  74 . If the registration is not successful then the L2M2M server may still reply with the queued bootstrap information at step  110  and at step  88  the remote device  70  may register with new LWM2M server  76 . No de-registration step  86  is required as described with reference to  FIG. 8 . 
         [0069]    Referring to  FIG. 11 , the bootstrap server  78  fails at step  80  to connect to the remote device  70 . At step  96 , a message from the bootstrap server  72  to the LWM2M server  74  is sent, which comprises instructions that the remote device  70  may (in the sense that the remote device should or must) bootstrap with the bootstrap server  72  in the form of a bootstrap request. At step  98 , the bootstrap request is sent from the LWM2M server  74  to the remote device  70  and upon receiving the bootstrap request the remote device connects to the bootstrap server  72  (step  100 ) and receives bootstrap information from the bootstrap server  72  (step  102 ) causing the remote device  70  to register with the new LWM2M server  76 . No step  86  of de-registration is needed as described with reference to  FIG. 7 , because the remote device has not registered with the L2M2M server  74 . 
         [0070]    Accordingly, present techniques extend OMA LWM2M specification server initiated bootstrap to go through a LWM2M server. Such an approach allows bootstrapping to occur even when remote devices are located behind a network address translator and/or Firewall which blocks the direct connection from a bootstrap server to the devices. A bootstrap server may also fail to connect to a remote device when the remote device changes its IP address, which may occur in an all peer network such as a mesh network using in  6 LoWPAN. 
         [0071]    While techniques have been described for a single remote device, it will be appreciated by one skilled in the art that present techniques can be applied to multiple remote devices. In all cases, a bootstrap message or information may be verified and signed by the bootstrap server by way of example using a private key digital certificate. Where bootstrap information is provided, a bootstrap message may contain a multiple parameter in aggregate format like Type, Length and Value (TLV). In other cases, where the message is a request for bootstrap with the bootstrap server then a simple request for bootstrap need only be provided. 
         [0072]    While techniques illustrate how bootstrapping may be initiated when the bootstrap server cannot connect to the remote device, it will be appreciated that if the bootstrap server can connect to the remote device, it may choose not to and so may delegate the provisioning of the bootstrap information to the LWM2M server using the techniques described herein. 
         [0073]    Those skilled in the art will appreciate that while the foregoing has described what is considered to be the best mode and where appropriate other modes of performing present techniques, the present techniques should not be limited to the specific configurations and methods disclosed in this description of the preferred embodiment. Those skilled in the art will recognise that present techniques have a broad range of applications, and that the embodiments may take a wide range of modifications without departing from the any inventive concept as defined in the appended claims.