WO2013088323A2

WO2013088323A2 - Operation of wireless resource-constrained devices in ip networks

Info

Publication number: WO2013088323A2
Application number: PCT/IB2012/057125
Authority: WO
Inventors: Esko Olavi Dijk; Bozena Erdmann; Petrus Desiderius Victor Van Der Stok; Ludovicus Marinus Gerardus Maria Tolhuizen
Original assignee: Koninklijke Philips Electronics N.V.
Priority date: 2011-12-16
Filing date: 2012-12-10
Publication date: 2013-06-20
Also published as: WO2013088323A3

Abstract

The present invention relates to a method and an apparatus for operating resource-constrained wireless devices (10) in IP networks. A proxy node (20) translates a received unique identification (UID) of the wireless device (10) into an IP address of the destination device(s) (30) e.g. by table lookup or standard Domain Name System resolving. Then, the proxy node (20) sends a command in a standard message format embedded in the IP network's communication to one or more destination IP device(s) (30). A message from the proxy node (20) to the IP destination device(s) (30) may contain e.g. a transmission- specific value such as a sequence number unambiguously derived from a transmission- specific value received from the wireless device and a calculated IP source address of the wireless device (10).

Description

OPERATION OF WIRELESS RESOURCE-CONSTRAINED DEVICES IN IP

NETWORKS

FIELD OF THE INVENTION

The invention relates to an apparatus and method of operating a wireless resource-constrained device in an IP based network.

BACKGROUND OF THE INVENTION

Non- wired devices as part of larger control networks represent a ubiquitous trend in business, especially for building management systems. The independence from power and control wires provides freedom of placement, portability and reduces the cost of installation (no cable placement or drilling required). This is especially attractive for devices such as light switches, wireless remote controllers, movement detectors, light sensors, C0₂ sensors, temperature sensors, humidity sensors, etc. Because they are not connected with any wires, not even to a power supply, such devices should operate as low-power as possible to save battery or to enable operation on harvested energy.

Such non-wired devices may generate (harvest) their own energy, e.g. for control signaling or the like, and thus do not require any power supply, but may use some form of energy storage (capacitor, battery), to save the harvested energy. The pioneering technology for such wireless energy-harvesting devices was developed by EnOcean, as described for example in http://www.enocean.com/radio-technology/. ZigBee Green Power (ZGP) is the emerging standard (work in progress) for such wireless energy- constrained devices, interoperating with ZigBee networks according to the ZigBee 2007 standard, http://www.zigbee.org/Specifications/ZigBee/download.aspx, as described for example in ZigBee Alliance, NEW ZIGBEE GREEN POWER FEATURE SET REVEALED, 2009, https://docs.zigbee.org/zigbee-docs/dcn/09-5181.pdf. Within the Internet Engineering Task Force (IETF), the Internet Protocol version 6 (IPv6) suite is being amended by the

6L0WPAN Working Group for use on low-power, resource-constrained devices connected via low-bitrate wireless networks such as IEEE 802.15.4. This 6L0WPAN protocol is described in Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, "Transmission of IPv6 Packets over IEEE 802.15.4 Networks", RFC 4944, September 2007 and in Hui, J., Thubert, P., Compression Format for IPv6 Datagrams over IEEE 802.15.4-Based Networks, RFC 6282, September 2011 and Shelby, Z. et al, Neighbor Discovery Optimization for Low- power and Lossy Networks (6L0WPAN), draft-ietf-61owpan-nd, version 18 (work in progress), October 2011.

On top of 6L0WPAN, the IETF currently standardizes the Constrained Application Protocol (CoAP) described in Shelby et al, Constrained Application Protocol (CoAP), draft-ietf-core-coap, version 08 (work in progress), October 2011 , which offers a HTTP-compatible architecture for 6L0WPAN or other power- or bandwidth constrained IP networks. CoAP has the potential to become the standard protocol for application-level IP communication in the wireless building control domain. It is standardized within the

Constrained Restful Environments (CoRE) Working Group of IETF. It is to be noted that existing standardized data formats (e.g. ZigBee application profiles) can be carried by CoAP as well, which provides for a graceful transition of current standards to IP-based building control standards. All protocols operating in an IP network at higher layers than the Network Layer are from here on referred to as higher layer protocols. Examples of higher layer protocols are CoAP, HyperText Transfer Protocol (HTTP), Transmit Control Protocol (TCP), User Datagram Protocol (UDP) and Building Automation and Control Networks (BACnet). Packets of a higher layer protocols may in some configurations be carried as payload inside packets of another higher layer protocol, for example CoAP packets carried inside UDP packets.

Fig. 1 shows an example of a wireless resource-constrained device, i.e. an energy- harvesting light on/off switch (ZigBee Green Power Device (ZGPD)) 10, operating in a ZGP-enabled ZigBee network. The ZGPD 10 (ZGPD1) has been paired with a ZGP Sink device (ZGPS2) 30, e.g. light source or the like. Upon being toggled, the switch ZGPD 10, using the energy harvested from the mechanical toggling action, sends control commands (on/off), encapsulated in a message according to the Green Power Device Frame (GPDF) format. The GPDF format is different from the ZigBee Pro frame format. Proxy devices (ZGPPl and ZGPP2) 20 in the radio range of the ZGPD 10 will tunnel the received ZGPD commands in a regular ZigBee Pro frame format (ZF) to the destination, i.e. the ZGP Sink device (ZGPS2) 30, which executes the ZGPD command. The two proxy devices 20 (ZGPPl and ZGPP2) are not compulsory - it is just an example situation. The example shows that one or more proxy devices can tunnel the GPDF message.

Fig. 2 shows an exemplary regular C0AP/6L0WPAN protocol stack with two example applications, Appl and App2, both using CoAP. Both CoAP and 6L0WPAN define specific packet/frame formats that are used in the embodiments. These are not described in detail here but can be found in the corresponding IETF documents. The 6L0WPAN/C0AP standards make some basic assumptions on and impose requirements on nodes (where nodes can be either routers or hosts). Even though

6L0WPAN/C0AP is being developed for resource-restricted devices, some of these requirements would be hard or impossible to satisfy by native, standard-compliant

6L0WPAN/C0AP nodes which are energy- constrained, especially if energy-harvesting.

According to 6L0WPAN (RFC 4944), the source address (of 2B/8B) of a sending device is present in the MAC frame and nodes in a 6L0WPAN network share the same 802.15.4 PAN identification (ID) and use the same 802.15.4 RF channel. Furthermore, nodes in a 6L0WPAN network share the same link-layer security context (either no security or a specific 802.15.4 MAC security setting with corresponding symmetric key). Nodes participate in the 6L0WPAN Neighbor Discovery (ND) protocol described in Shelby, Z. et al. Neighbor Discovery Optimization for Low-power and Lossy Networks (6L0WPAN), version 18 (work in progress), October 2011. When nodes are sleepy (i.e. have recurring periods of sleep time) they can be programmed to wake at predefined times in order to refresh certain information as required by the 6L0WPAN-ND protocol. Nodes are reachable (unless they are asleep) i.e. IP packets can be routed to them. A node has an IPv6 address of 16B (or more than one) configured according to the rules as defined in IETF specifications RFC 4193, 4291, and 4944, which is typically unique within the context of use. In CoAP, a client knows which server to contact and makes the decision which CoAP server is the destination for a request. The CoAP server just executes received valid requests. Applications on nodes using multicast need to be by design well-behaved, i.e. they should not transmit more multicast traffic than the network can handle. This is required because there is no (or hardly any) congestion control done at the IP level or at CoAP level.

According to the IP end-to-end principle, intermediate routing nodes do not parse/adapt the payload of IP packets, apart from updating the IP header (e.g. decreasing a hop count), according to the rules of the routing protocol in use. Nor do the intermediate routing nodes provide duplicate packet filtering.

The future 6L0WPAN/C0AP networks shall also benefit from the convenient control provided with the resource-constrained devices as mentioned above. However, IETF/ 6L0 WP AN/ CoAP currently does not define a "ZGP like" functionality. ZGP or EnOcean are independent protocol solutions, not complying even with the basic

6L0WPAN/C0AP requirements: in the frame format transmitted by them, the IEEE source address (8B) may not be present, and an IP source address is not present, either. Both ZGPD and EnOcean devices are programmed with a standard-unique ID (of 4 bytes) but do not have an IPv6 address.

Also in case of energy-constrained, especially energy-harvesting, IP-enabled devices, the IEEE source address (8B) may not be present; a routable IP source address may not be present; security use at MAC level may be skipped - to reduce frame length, frame processing or because appropriate data (e.g. network prefix, security context) was not configured. Such energy-constrained, especially energy-harvesting, IP-enabled devices do not know a priori which destination (e.g. CoAP server) to contact; configuring them with this information may be cumbersome and requires re-configuration in case of changes. They cannot be assumed to sleep and wake-up predictably, due to energy constraints; they may be unable to participate in the 6L0WPAN-ND protocol because they do not necessarily support bidirectional communication. By their energy-constrained nature, they are unlikely to generate too much traffic. Yet, care must be taken that the forwarding of their packets is not too traffic-intensive.

SUMMARY OF THE INVENTION

It is an object of the present invention to provide a method and apparatus for operating a wireless resource-constrained, and especially energy- constrained device, such as a ZGPD, EnOcean, or energy-constrained IP -based device, in an IP based network, so that a command generated by the wireless device can reach the IP based destination (e.g.

C0AP/6L0WPAN destination device(s)).

This object is achieved by an apparatus as claimed in claim 1, by a proxy node as claimed in claim 7, by a network node as claimed in claim 8, by a method as claimed in claim 9, and by a computer program product as claimed in claim 15.

Accordingly, a message from the wireless resource-constrained device (e.g.

ZGPD) can be routed over the IP -based network (e.g. 6L0WPAN network) that may contain many intermediate IP based network nodes. In one embodiment, the proposed solution provides functionality such that existing wireless resource-constrained devices (e.g. ZGPDs) can be used directly in IP networks. Thus, minimal time and money have to be spent on new standardization or new low-power device design/manufacturing efforts when control systems make the move towards IP-based networks in the future. The proposed solution provides the benefit that no changes are required to the existing implementations/standards for wireless resource-constrained device (e.g. ZGP, EnOcean) or to the 6L0WPAN or 6L0WPAN/C0AP stack for implementation, while a network-efficient solution is achieved. In another embodiment, an IP-based resource-constrained device can be used directly in IP networks, with minimum impact on the 6L0WPAN or 6L0WPAN/C0AP stack and network operation. The proposed routing or forwarding works also on legacy intermediate IP devices (e.g.

devices not aware of the resource-constrained devices or the proposed proxy solution), so that the destination devices such as lamps or other actuators can also be legacy devices (e.g. not aware of the resource-constrained devices and the proposed proxy solution).

More specifically, there is no need for the resource-constrained device to have and/or send an IP-routable identifier, such as a routable IPv6 address. It is not required for the resource-constrained device to discover the proxies or for the user to pair the resource- constrained device to one or more proxy devices. Instead, proxies can be automatically used if they are in the radio range of the resource-constrained device. Proxy redundancy may be utilized for more robust propagation of the resource-constrained device's event or command to IP destination(s).

Furthermore, programming and pairing are impractical for a resource- constrained device due to its highly constrained energy resources. Limiting the necessary configuration of the resource-constrained device and making the forwarding solution robust and self-configuring eliminates the need for manual user intervention (re-commissioning) in case the resource-constrained device is moved, the propagation conditions change, or some configuration parameters (like e.g. network identifiers or self-assigned addresses) change, or the to-be-controlled group of destination devices gets redefined.

An overall advantage of the proposed solution is that the resource-constrained device does not need to participate in the maintenance communication of the 6L0WP AN/IP network it communicates with, which simplifies its stack and drastically reduces its energy requirements, while on the other hand the proposed solution reaps the benefits of an IP network for the system as a whole (e.g. use of standard/off-the-shelf components and protocols, scalability). One example of such maintenance communication is the 6L0WPAN- ND protocol.

As an additional advantage, duplicate message rejection can be achieved at the destination device(s) using standard higher layer protocols on top of IP, such as CoAP.

Furthermore, the wireless resource-constrained device does not need to know the destination device(s) or required communication mode (multicast, unicast, broadcast) so that there is no need to program/commission this device with that information. Thus, the mapping between wireless resource-constrained device and destination(s) can be changed flexibly. Also, single as well as multiple destinations (reached via IP multicast and/or serial IP unicast) are readily supported.

As already mentioned, existing wireless resource-constrained devices, such as ZGPD or EnOcean energy-harvesting devices, can be directly integrated (typically without any hardware/software changes) into a non-ZGP-aware 6L0WPAN or other IP based network that works with standardized IETF-defined protocols. It is however noted that "non-ZGP- aware" does not apply to the proxies, which have to be enabled to understand the received special frame format from the wireless resource-constrained devices.

According to a first aspect, the unique identification information as sent by the wireless resource-constrained device may be used to obtain the destination information for the forwarded message, consisting of one or multiple destinations, by means of derivation, translation by an internal database or table lookup, external database or table lookup or by a database resolving operation, e.g. DNS (Domain Name System) or CoRE (Constrained RESTful Environments) Resource Directory (RD) query. In a more specific example, at least one routable IP destination address may be obtained from both the unique identification information and the first command.

According to a second aspect that can be combined with the first aspect, an IP source address may be looked-up or resolved or derived from a set of pre-defined parameters including the unique identification information and an IP prefix, and the IP source address may be specified in the IP packet that carries the command embedded in a higher layer protocol packet. The forwarded message comprises said IP packet.

According to a third aspect that can be combined with at least one of the first and second aspects, a first transmission-specific value may be present in the message as sent by the wireless resource-constrained device, and a second transmission-specific value for the forwarded message can be derived from the first transmission-specific value or from a combination of the first transmission-specific value with the unique identification

information present in the message as sent by the wireless resource-constrained device.

According to a fourth aspect that can be combined with any of the first to third aspects, an IP source address may be looked up or resolved or the IP source address may be derived from a set of pre-defined parameters including the unique identification information and a prefix of an IP address, and the IP source address may be specified in an IP packet that carries the format of the higher layer protocol.

According to a fifth aspect that can be combined with any of the first to fourth aspects, a value derived from the first or second command may be stored in the destination device in a local storage and may be made available for retrieval by at least one other device that uses an application protocol of said IP based network to retrieve the stored value.

In a further aspect of the present invention a computer program for performing the above method may be provided, wherein the computer program comprises code means for causing an apparatus to carry out the steps of the above method when the computer program is run on a computer device controlling the apparatus.

It shall be understood that a preferred embodiment of the invention can also be any combination of the dependent claims with the respective independent claim.

These and other aspects of the invention will be apparent from and elucidated with reference to the embodiments described hereinafter.

BRIEF DESCRIPTION OF THE DRAWINGS

In the following drawings:

Fig. 1 shows a schematic network architecture of a conventional ZGP system with a wireless resource-constrained device according to

ZGP specification, ZGPD;

Fig. 2 shows an example of a C0AP/6L0WPAN protocol stack;

Fig. 3 shows a sequence diagram of a DNS look-up scenario with two proxies and one destination according to a first embodiment; Fig. 4 shows a sequence diagram of a scenario with two proxies with cached DNS information and one destination according to a second embodiment; and

Fig. 5 shows a flow diagram of a routing or forwarding operation according to a sixth embodiment.

DETAILED DESCRIPTION OF EMBODIMENTS

The following embodiments show how wireless resource-constrained devices can be incorporated into a network of nodes using the C0AP/6L0WPAN IP stack.

According to some embodiments, a wireless resource-constrained device (e.g. ZGPD according to the ZGP standard or an EnOcean-based) initiates a wireless data transmission in the frame format of the wireless resource-constrained device (e.g. in case of ZGPD, GPDF) that includes its unique ID 'UID' (which is not an IPv6 source address, e.g. 4 bytes in case of ZGP) plus a transmission-specific value such as a sequence number, but not any IP destination information. One or more nodes called proxies in the radio range of the wireless resource-constrained device, receive the wireless transmission, if the proxy is configured to receive the frame format of the wireless resource-constrained device. A proxy also includes an IP stack, typically a 6L0WPAN stack, for reception/transmission of IP packets, typically in the 6L0WPAN frame format. Typically, to save costs, the proxy may use the same radio hardware (e.g., in case of ZGPD: IEEE 802.15.4) for the two functions stated above, and have a technique to differentiate between the two frame formats, as known in the art.

One or more of these proxies obtain an IP address of the destination device(s) for the UID by means of derivation (e.g. applying a pre-defined IP multicast prefix to the UID), internal/external database lookup or table lookup, or by protocol like standard Domain Name System (DNS or Multicast DNS (mDNS) or DNS-based Service Discovery (DNS- SD)) resolving or a Co RE Resource Directory (RD) query as described in Z. Shelby and S. Krco, CoRE Resource Directory, IETF Internet Draft draft-shelby-core-resource-directory (work in progress), version 02, October 2011. The proxie(s) that successfully resolved the UID send one or more messages using a higher layer protocol over an IP/6L0WPAN network (e.g. the CoAP protocol). In each message the IP Destination field inside the IP/6L0WPAN packet header is set to the IP address obtained above and each message may contain a transmission-specific value, preferably derived from the transmission-specific value in the frame format of the wireless resource-constrained device. Into the IP source address field of the IPv6 header or the corresponding compressed field of the 6L0WPAN header an IP source address is placed calculated based on at least the UID, or UID and an IPv6 prefix, or looked up in one of the ways described above, e.g., by DNS or internal/external database or table lookup. Furthermore, the message payload contains a representation of the initial command that was present in the above wireless resource-constrained device frame, which may be a verbatim copy of the command data or a translation of the initial command to another standard format.

A destination device (or more destination devices) receives the message from the proxie(s) and optionally checks that the message is not a duplicate using the transmission specific value, if present, and the IP source address and the source port (e.g. UDP port for CoAP), before executing the command (with optional checking of security policies and local pairing information prior to execution).

Thus, existing wireless resource-constrained devices can be applied without modifications in IP-based, e.g. 6L0WPAN, networks. De-duplication may be required for certain application functionality. The following embodiment describes de-duplication in case the CoAP protocol is used for communication between proxy and destination(s). To prevent the duplicate forwarded packets from being executed, the Message ID (MID) field of the CoAP packet header can be filled with a value derived from the GPDF sequence number, or a value supplied by the resolution mechanism, such that the same value can be generated by multiple proxy nodes independently. The IP source address can be generated by multiple proxy nodes

independently, based on the UID and an IP prefix known to the proxy, even though not all information for generating this IP address is present in the GPDF transmission. Then, the destination filters incoming CoAP-over-UDP messages based on both of those derived values and based on the (UDP) source port. The destination IP address may also be generated by multiple proxy nodes independently, even though not all information for generating this IP address is present in the GPDF transmission. The UID of the wireless resource-constrained device, e.g. the four-byte SrcID of the ZGPD, can be translated to an ASCII (American Standard Code of Information Interchange) compliant format, for use as input to a DNS/RD query, in order to translate UID to a unicast or multicast IP address. This achieves zero- configuration for the proxies, the destinations and the wireless resource-constrained devices as only standard DNS configuration or alternatively CoRE Resource Directory configuration is needed, and basic configuration of the wireless resource-constrained devices for the operational network (e.g. configuring the wireless resource-constrained devices onto the operational radio channel being sufficient, and optionally configuring security parameters).

According to some other embodiments, a destination device that receives the message Mp from a proxy (containing e.g. as part of the command information about a sensor event) may not itself act on the command but will store a value derived from the command in a local storage. Other IP-based devices may then query the destination device for the present value, past values, or statistics thereof. For example the destination device could offer access to these values via the CoAP protocol as a CoAP server, where CoAP clients interested in this information contact the CoAP server via its known URL or IP address. Advantageously, the interested clients can fetch the latest sensor data at any time without having to be aware of the resource-constrained nature of the sensor and its possibly unpredictable sleep periods. According to some other embodiments, an IP-based wireless resource-constrained device is proposed. Such wireless resource-constrained device supports some of the IP protocol layers, but cannot fully comply with IP requirements, e.g. 6L0WPAN/6L0WPAN-ND/C0AP requirements. It initiates a wireless data transmission in IP frame format that includes its UID, which may be e.g. an IEEE address or link-local IPv6 address or auto-configured global IP address, but not necessarily a routable IPv6 address. Furthermore, this IP packet contains an IP destination address which may be a routable or non-routable IP address, e.g., respectively a site-local IPv6 multicast address or a link-local IPv6 multicast address.

However, the IP destination address of this IP packet in these cases is not the IP address of the intended destination(s) of the command issued by the wireless resource-constrained device because the wireless device was not previously configured with this information. The IP destination address in said IP packet may be an IP multicast address that is the same for all wireless devices, or it may be an address that identifies the category of sensor information that the wireless device is producing, or it may be an address that includes or encodes the UID or portions thereof. Further, the packet may include a transmission-specific value such as a MAC sequence number, or CoAP Message ID (MID). One or more IP nodes in the radio range of the IP-based wireless resource-constrained devices, receive the wireless

transmission. These may be proxy nodes, configured to receive and forward this frame format. They may also be regular 6L0WPAN router nodes (6LRs), configured to route IP multicast packets in a standard way according to the multicast protocol that is active on the respective node. They may also be regular 6L0WPAN nodes, configured to tunnel the received frame format to the proxy nodes.

One or more of these proxies obtain a routable IP address of the destination device(s) for the UID by means of derivation (e.g. applying a pre-defined/network-specific prefix in combination with a value derived from unique address part supplied in the UID), internal/external database lookup or table lookup, or by standard mechanisms like Domain Name System (DNS or Multicast DNS (mDNS) or DNS-based Service Discovery (DNS- SD)) resolving or Resource Discovery. The proxie(s) that successfully resolved the UID send one or more messages using an IP/6L0WPAN protocol stack, in the format of a higher layer application protocol, as supplied by the wireless resource-constrained device or as appropriate for this particular network (e.g. the CoAP protocol). In each message the IP Destination field is set to the IP address obtained above and each message may contain a transmission-specific value, preferably derived from or copied verbatim from the

transmission-specific value in the frame of the wireless resource-constrained device. Into the Source address field of the IPv6 header or the corresponding compressed field of the

6L0WPAN header an IP source address is placed calculated based on at least the UID, or UID and an IPv6 prefix, or looked up in one of the ways described above, e.g., by DNS, RD or internal/external database or table lookup. Furthermore, the message payload contains a representation of the initial command that was present in the above GPDF frame, which may be a verbatim copy of the command data or a translation of the initial command to another standard format.

A destination device (or more destination devices) receives the message from the proxie(s) and optionally checks that the message is not a duplicate using the transmission specific value, if present, and if that is present also using the IP source address and UDP source port, before executing the command (with optional checking of security policies and local pairing information prior to execution). The derivable data may also be generated by multiple proxy nodes independently, even though not all information for generating this derivable data is present in the transmission of the wireless resource-constrained device.

According to some further embodiments, the IP destination device can perform some of all of the steps including receiving the wireless transmission in the frame format of the wireless resource-constrained device, resolving the at least one destination IP address, resolving the source IP address, deriving the transmission-specific value, and sending a derived command in the application level protocol, for internal use in said destination device and/or for forwarding to other destination devices.

Fig. 3 shows a sequence diagram of a scenario with two proxies (P) 22 and one destination IP node 30 according to a first embodiment. Here, by means of example, the wireless energy-constrained device 10 is a ZGPD, according to the ZGP specification, and the proxies are 6L0WPAN/C0AP nodes that also support the ZGP protocol. A DNS server 40 is used to look up the destination IP address because the proxies 22 do not store this information (yet) in their internal cache.

Initially, in step 30 a user presses or activates the switch of a ZGPD 10, e.g., in order to switch on or off a light source. In step S31, the ZGPD 10 initiates a wireless data transmission in GPDF format, defined here as message Mz, that includes a command Cz, a UID of the ZGPD and a transmission-specific value Sz. However, the message M_z does not contain any IP destination information. Sz may be a sequence number but may be generated in other ways too. The message Mz may consist of one IEEE 802.15.4 radio frame; it may be repeated for increased reliability.

One or more of the proxies 22 that are in the radio range of the ZGPD 10 receive the message M_z. The proxies 22 are configured to allow wireless reception of packets in at least two frame format standards (without knowing beforehand which format it will receive next), specifically at least GPDF format and 6L0WPAN frame format. The proxies 22 check the first two bits of the MAC Protocol Datagram Unit (MPDU) to distinguish between the two distinct frame formats: the value of "ObOO", typically used for those bits by Data GPDF corresponds to a forbidden header type in 6L0WPAN (NALP - Not a LoWPAN frame). One or more of the proxies 22 that received Mz translates the UID into an IP address of the destination device(s) by DNS resolving in respective steps S32A and S32B, which may be standard DNS resolving, mDNS resolving, CoRE RD based resolving, DNS-SD based resolving, or some combination or selection of the previous depending on node and/or network state. The DNS server 40 replies in steps S33A and S33B with an AAAA record containing the IPv6 address of the destination IP node 30. It is to be noted that potential intermediate hops in the network between any nodes are not shown in this schematic diagram - only the end-to-end communication. It is further noted that the destination IP address may be a unicast IPv4/IPv6 address, a broadcast IPv4 address, or a multicast IPv6 address. In a 6L0WPAN network it should be an IPv6 address.

The DNS resolving could potentially lead to multiple IP addresses linked to one UID. In that case the next steps are repeated for each resolved destination IP address. The proxie(s) 22, that successfully resolved the UID, send in steps S35A and S35B a message M_P using a protocol on top of IP/6L0WPAN, e.g. CoAP. The IP destination(s) in the message M_P are set to the IP address obtained in steps S33A and S33B, respectively.

Furthermore, in the message M_P a transmission-specific value Sp is used, e.g. a sequence number, which is calculated from Sz only or from both Sz and UID combined. This calculation may optionally use some value (state) stored in the proxy 22 or DNS 25 as well, as long as the resulting calculated Sp is the same in all proxies 22. For the specific case of the CoAP protocol the value Sp may be a CoAP Message ID (MID) field which is a 16-bit integer. For example, to create the 16-bit MID, the 8-bit value of the MAC header sequence number field of the 802.15.4-based GPDF is pre-padded with 0x00 or with a value supplied by the look-up/resolution mechanism.

Furthermore, an IP source address may be specified in the message M_Pi which may either be calculated in steps S34A and S34B, respectively, from a set of parameters known to all proxies 22, where this set of parameters includes UID and an IPv6 prefix. This IP address can be interpreted as a "faked IP address" because the IP address of the wireless resource constrained device ZGPD 10 is constructed by the proxy 22 on behalf of the wireless resource constrained device ZGPD 10. The real wireless resource constrained device (ZGPD) does not even have an IP address stored inside - but conceptually it has one assigned. Alternatively, or in addition to the previous, the IP source address may be looked up from an internal or external database or table, or using DNS, mDNS, CoRE RD or DNS- SD.

The message Mp contains a command CM which is either equal to the initial command Cz or is a translation of Cz to another representation performed by software in the proxy 22, where CM is generated the same in all proxies 22. Preferably, said application protocol format of the CM is readily understood by the destination(s).

Finally, the IP destination node(s) 30 receives the message Mp and checks for message duplication using the value Sp combined with IP source address and optionally UDP source port of Mp. Specifically for CoAP communication in the CoAP NoSec mode, the optional message duplication check at a destination involves comparison of Sp, IP source address and UDP/CoAP source port as specified in the CoAP specifications. If the message Mp is not a duplicate, as in step S35 A, it is accepted and passed to the application which then executes the command CM embedded inside M_P (e.g. switch a light) in step S36. Otherwise, if the message M_P is determined to be a duplicate, as in step S35B, it is discarded in step S37.

Fig. 4 shows a sequence diagram of a similar scenario, e.g. later in time, according to a second embodiment, where DNS lookup is not performed, because the needed information is cached in the proxies (P) 22, either from a previous operation (e.g. as in the scenario just shown above), or by pre-configuration, or by other means. Also here, by means of example, the wireless energy-constrained device 10 is a ZGPD, according to the ZGP specification, and the proxies are 6L0WPAN/C0AP nodes that also support the ZGP protocol.

In step S40, the user activates the switch of the ZGPD 10 which then broadcasts the message M_z in step S41. The proxies (P) 22 receive the message M_z and read the IP destination address from their internal cache or internal/external tables/databases in steps S42A and S42B, respectively. Additionally, they calculate the IP source address in steps S43A and S43B, respectively, as explained in the above steps S34A and S34B. The remaining steps S44A, S44B, S45 and S46 correspond to the above steps S35A, S35B, S36 and S37, respectively.

In the embodiments, the proxies 22 need to receive both 6L0WPAN 802.15.4 frames and GPDF 802.15.4 frames, preferably using only one IEEE 802.15.4 radio module to save cost.

The ZGPD should transmit on the same radio frequency (RF) channel as the proxies are receiving. For a proxy with two radio modules inside, different channels may be chosen for the ZGP and the 6L0WPAN radio traffic. For a proxy with a single radio module (e.g. for cost reasons), the same channel must be used for both the ZGP and 6L0WPAN radio traffic.

Translating a ZGPD UID into an IP address of destination(s) could be done using internal tables in all proxy nodes (which are set during a commissioning phase or with special table population commands sent to these nodes during normal operation). Also, the proxies could consult external tables (e.g. from a database), or use a combination of those methods. A combination of the above with DNS resolving is also possible e.g. a policy "if not in cache, then use DNS". For implementation strategies for commissioning in building control applications, and use of DNS-based Service Discovery (DNS-SD), refer to IETF I-D van der Stok, P. and K. Lynn: "CoAP Utilization for Building Control", draft-vanderstok- core-bc, version 05 (work in progress), October 2011.

It is noted that DNS supports 63 octets or less for a label, and at least all visible ASCII characters can be used according to the IETF specification RFC 1035. Hence a ZGPD UID, that is 4 bytes long, can be easily stored in various possible encoding formats in a DNS record stored on a DNS server. For example, a translation from a 4 bytes ZGPD UID to an 8-byte ASCII HEX representation such as the ASCII string "3FB907A1" for a UID hexadecimal 0x3FB907Al is one option. But any other representation method would do as well.

Advantageously, resolve results like e.g. from DNS or mDNS could be cached by the proxies to obtain an overall faster response time e.g. for lighting control applications involving energy-harvesting switches.

If the CoAP protocol is used on top of 6L0WPAN to carry commands to destinations, the destination(s) then typically include(s) a CoAP server. A CoAP server that implements de-duplication considers the Message ID (MID), an unsigned 16-bit integer, plus the IP source address (to identify the generator of the MID), and the UDP/CoAP source portfor duplicate rejection. So, if the CoAP server receives a request with a MID that it has seen from the same IP source from the same port, it will discard the request as a duplicate. The CoAP message may be sent confirmable or non-confirmable both with MID for message de-duplication purposes. If the transmission-specific value from the GPDF is known to follow a function which makes the value for transmission N predictable, given the value for transmission N-l (e.g. incremented or decremented values), the transmission-specific value generated by the proxies can also be made following an equally predictable mathematical function, such that the destinations and - if required, also the proxies - may only store the last received value. If a native payload of the wireless resource-constrained device frame is received by the destination, thanks to direct reception or forwarding, the de-duplication can be performed based on transmission-specific value included in the payload, if any.

However, a forwarding proxy cannot use its own IP address as source because in that case, a single ZGPD message that is forwarded by multiple Proxies would result in messages with different IP source addresses. This would cause the command in the ZGPD message to be unintentionally executed multiple times, because in that case duplicate rejection at the destination would not be applied. For example a destination may receive multiple messages M_P in that case with different IP source addresses, all triggered by the same ZGPD message M_z, which would cause a command C_M in M_P to be executed multiple times unintentionally.

But using the ZGPD's IP address is also not directly possible - the ZGPD does not include an IP address in the message M_z it sends since it is unaware of the existence of IP/6L0WPAN. Hence a solution is that an IP Source address is "faked" or inferred by a proxy before it transmits the message Mp in response to receiving Mz. For duplicate rejection at the destination(s) it is important that all proxies that send a message Mp in response to an Mz use the same IP source address in their message Mp.

The following options can be used to calculate a "fake" IP source address based on different input parameter sets.

Based on UID and a predefined IP prefix the proxy can construct an IP address by applying a predefined method on the received UID of the ZGPD. The resulting IP address may be e.g. a link-local IP address. In this case the link-local prefix for IPv6 may be

"FE80::/10". However, link- local addresses are preferably avoided as they are non-routable. Alternatively, an unique local address (ULA) according to IETF specification RFC 4193 based on a well-known prefix, or a general global address based on a well-known prefix may be used.

Based on the UID and a dynamically allocated IP prefix, the proxy can construct an IP address using the UID and an IP prefix (e.g. a network- wide preset IP prefix or one obtained previously from a 6L0WPAN Border Router (6LBR) via 6L0WPAN-ND).

Based on DNS, mDNS or DNS-SD information, such as an IP address found via DNS query using the UID or a processed version of the UID in the query string. In the

DNS-SD case, the UID may be included in, or used as, a service instance identifier in a DNS- SD query. This allows to resolve the "fake" IP address of the ZGPD via DNS, even though the ZGPD itself does not store this IP address. Based on the UID and the transmission-specific value Sz, the proxy can construct an IP address taking into account the current value Sz which may be a sequence number. This gives an IP address that varies with each subsequent transmission of the ZGPD. It provides the destination(s) with the illusion that each message/command from a ZGPD device seems to be coming from another ZGPD device. Additionally, the IP prefix could be used when constructing an IP address in this manner.

It is noted that the "IP prefix" in above options should be a prefix that is the same for all Proxies that can receive a GPDF transmission of any given ZGPD in the system. This is to guarantee that "fake" IP source addresses are always calculated the same way by all proxies that received a GPDF transmission.

Typically a prefix for IPv6 addresses is assigned by network administration procedures. This may be a globally unique prefix or one valid for the local site only. The 6L0WPAN-ND protocol defines how a prefix can be distributed to all nodes in a 6L0WPAN network, originating from a 6LBR. Nodes may use this prefix to configure their own IP address. Hence in a typical case (after ND initialization has taken place) a proxy according to some embodiments will know this prefix. From then on, the proxy can use this prefix in "fake" IP address generation for a ZGPD. One method to generate the "fake" IP Source address is: IPv6 Source Address := <IPv6-network-prefix>::<ZGP-chosen- prefix>:<UID> where < IPv6-network-prefix> is the prefix mentioned above and should comply to the IETF specification RFC 4291 and is hence specific to the subnet where a 6LBR is connected to. The prefix size may vary though a typical value is up to 64 bits. If shorter, it may be zero-padded until 64 bits. <ZGP-chosen-prefix> is a 32-bit value to be chosen e.g. agreed by standardization or chosen for a specific installation site or building, as long as the resulting IP address satisfies the requirements of the IETF specification RFC 4291. Finally <UID> is the 32-bit ZGPD unique ID.

Besides the example above, another embodiment is to resolve the ZGPD UID into an IP source address using DNS. One way to do this is to perform a DNS Query e.g. on the host with name "ZGPDxxxxxxxx" where "xxxxxxxx" represents a string containing a hexadecimal notation encoding of the UID. E.g. UID hexadecimal 0x12345678 becomes string "ZGPD12345678". The DNS AAAA record in response to the DNS Query then provides the IPv6 address of that ZGPD. It is assumed that in a commissioning phase, all used ZGPD IDs have been programmed into DNS in this manner. Optionally, a proxy may cache a number of UID to IP address mappings, for decreased latency of the destination reacting to a ZGPD event and/or limiting the amount of traffic generated by the discovery. The decision to cache a certain ZGPD information may be based on a number of criteria, including: most important devices (according to some criteria), certain device types, certain application types, devices most sensitive to delay, the most frequently communicating devices, devices recently proxied for, the lifetime (TTL field) of a DNS record, etc.

To avoid confusion, note that an IP destination address (besides the IP source address) may also be looked up in this manner using DNS. The constructed host names used for lookup in that case need to differ, e.g. a DNS query for host name "ZGPSxxxxxxxx" to lookup the ZGPD IP source address and "ZGPDxxxxxxxx" to look up the IP destination address.

In a third embodiment, the wireless resource-constrained device sends an IP- protocol packet, according to the IP/UDP/CoAP protocol stack. It can e.g. be IEEE 802.15.4 radio frame with 6LoWPAN-defmed IP header compression or 802.11 frame, with or without 6L0WPAN compression applied. The device provides either a non-routable multicast IP address or a routable multicast IP address as the destination address in the IP packet. In case of a non-routable link-local multicast address the destination address can take e.g. the following format: FF02: :2: 1. In case of a routable multicast IP address it may be a site-local multicast address such as e.g. FF05::2: 1. Furthermore, the device may provide typically a non-IP-routable source address, such as a link-local unicast IP address, which is then typically auto-configured based on the device's 802.15.4 16-bit address or IEEE EUI-64 address. If the device provides a non-link-local unicast IP source address, this is typically auto-configured based on the device's IEEE EUI-64 address or another built-in UID, combined with an IP prefix, other than FE80::/10, stored in the firmware of the device. Such an IP address is routable in the sense that it can be forwarded by IP routers over multiple hops. The proxies receive this transmission, either directly or forwarded by devices such as 6L0WPAN Routers (6LRs) in the radio range of the wireless resource-constrained device, are able to derive a routable IP destination address for the one or multiple unicast and/or multicast destinations, by means of derivation, or internal or external lookup, as described in detail in the previous embodiments. Similarly, the proxies may provide a routable IP source address, either, e.g. if de-duplication is required, equal for all proxies - by means of derivation, or internal or external lookup-, or if de-duplication based on IP source address is not required, by providing the IP address of the proxy itself as the IP source address, as described in detail in the previous embodiments. The CoAP protocol request Options and/or payload can be copied verbatim, or extended with transmit options, as known to the proxy by pre-configuration or table lookup.

In some embodiments, the GPDF frame format according to ZGP specification is assumed for the wireless resource-constrained device to proxy data transmission. In another embodiment, EnOcean frame format can be used for this. In yet another embodiment, other low-power wireless non-IP protocols can be used. In yet further embodiments, IP-based communication can be used by the wireless resource-constrained device. Further, in some embodiments, the proxies use the CoAP message format included in the payload of a

6LoWPAN-compressed User Datagram Protocol (UDP)/IP datagram forwarded to the destination.

Alternative embodiments for the proxy to destination(s) IP communication include HTTP request format as a payload inside a 6LoWPAN-compressed TCP/IP packet, HTTP request format as a payload inside a regular IPv4 or IPv6 TCP/IP packet, CoAP message format as a payload inside a 6LoWPAN-compressed TCP/IP packet, or CoAP message format as a payload inside a regular IPv4 or IPv6 TCP/IP or UDP/IP packet. For TCP/IP communication typically a proxy would select the source IP address for message M_P as equal to its own IP address, since TCP involves a bidirectional handshake that makes it non-obvious to reliably use a "faked" or generated IP source address. However, specific embodiments using TCP/IP are possible in which one or more proxies generate an IP address on behalf of a wireless resource-constrained device and temporarily configure this IP address as one of their own, in order to facilitate TCP/IP communication with destination(s).

For the contents of the HTTP or CoAP message, i.e. its request parameters and its payload, there are again various embodiments, such as ZigBee application profile format inside the HTTP or CoAP payload, a to-be-defined lighting control format that uses a RESTful web service with predefined GET/PUT operations conveyed over HTTP or CoAP, or application level commands according to the wireless resource-constrained device's protocol tunnelled to destination devices in a HTTP or CoAP payload. Destination devices in this case should understand the tunnelled format.

According to a fourth embodiment, a proxy detects whether a destination IP device understands native commands sent by wireless resource-constrained device and if so, tunnels the those command to the destination. If not, the command from the wireless resource-constrained device is first converted into an equivalent command encoded in the IP protocol of choice understood by destination devices, e.g. a CoAP request uniform resource indicator (URI) and CoAP payload (in some way programmed into the proxy) before being sent to the destination. One possible way to detect whether a destination supports the application level commands according to the wireless resource-constrained device's protocol commands (e.g. the ZGPD commands according to ZGP specification), is to query the destination device's capabilities using a CoAP request on its ".well-known/core" uniform resource indicator (URI). If supported, this query would yield a description in the CoAP Link Format as described in Z. Shelby, CoRE Link Format, draft-ietf-core-link-format, version 09 (work in progress), November 201 1 from which the level of wireless resource-restricted device/protocol support can be deduced. Alternatively, a proxy may use DNS-SD or CoAP Resource Directory (RD) functions to query the destination device's capabilities. Further, the DNS or RD can provide information about further optional features of the proxy-destination communication, e.g. the need for de-duplication and thus choice of transmission-specific value and IP source address for the forwarded frame.

According to a fifth embodiment, a proxy sends messages Mp from one and the same wireless resource-constrained device to different destination devices or groups of devices, where the destination address(es) are selected based on presence of specific commands or parameters in the message Mz from the wireless device. The proxy may resolve a destination using DNS using the wireless device's UID as before with in addition using a suitable representation of a command or parameter derived from MZ. For example, the message MZ may contain a one-byte command field as possible e.g n resource-constrained device implementing the ZGP standard. This command field may be used in a subsequent DNS address resolution as follows: the proxy queries DNS for hostname

"ZGPD<CMD><UID>" where <CMD> stands for a two-character hexadecimal string representation of the single command byte e.g. "81" for command byte 129, and <UID> stands for a string representation of the UID of the wireless device as explained for previous embodiments. Now, the configuration stored in DNS can be set such that different commands from the wireless device (in the example a ZGPD) can be translated to different destinations or sets of destinations to which to forward the resulting command. This has the benefit of allowing a more flexible configuration of e.g. a lighting system. One example wireless resource-constrained device in this context may be an energy-harvesting multi-button panel, where each button is mapped to a different command byte, and hence each button on the panel can be configured to control a different IP-controlled luminaire. In the functionality or software of the proxies, proxy nodes or proxy devices, minor additions are needed if a standard C0AP/6L0WPAN capable 802.15.4 wireless node is taken as a basis. More specifically, such functionalities or software features comprise an ability to receive and parse the frame format of the wireless resource-constrained device (e.g. GPDF in case of ZGPD), a function to map the UID of the wireless resource-constrained device (e.g. the ZGP SrcID) into a destination IP address and to a source IP address according to the above embodiments, a function to derive the transmission-specific value for inclusion in the IP packet from the frame format of the wireless resource-constrained device, or an optional software function to derive from application layer commands according to the wireless resource-constrained device's protocol equivalent IP commands or higher layer protocol commands such as "xyz-over-IP" or "xyz-over-CoAP" commands where xyz stands for a higher layer protocol, typically a selected application profiles standard such as ZigBee, ZigBee Home Automation, ZigBee Building Automation or ZigBee Light Link. The last function is marked optional, because another option is doing no translation. If there is no translation, the CoAP protocol can be used to tunnel end-to-end the "application level" commands that were sent by the wireless resource-constrained device. In this case, destination devices need to understand this application level protocol of the wireless resource-constrained device. Another function to be supported by the proxy is the dual reception of 6L0WPAN and wireless resource-constrained device radio frames. This means first that channel assignment should be the same in case a single-radio -receiver proxy is used. Second, if either 6L0WPAN or wireless resource-constrained device's protocol or both use link-layer (e.g. 802.15.4 or 802.1 1) security there are some additional issues as explained in the security section below.

To the 6L0WPAN/C0AP software stack of Fig. 2 a few changes are required at most, in order for the stack to be used in a proxy. First, it needs to be able to co-exist with a "second stack" that receives wireless resource-constrained device's transmissions. In a typical implementation, a "frame classifier" component is introduced which determines the frame type of each received RF frame and then offers the frame to either the first or the second stack. Second, the stack should preferably support dynamic changing of the IP source address for IP packets sent, where the IP source address set is not necessarily an IP address of the proxy itself. Third, DNS client functionality or mDNS functionality and/or DNS-SD functionality can optionally be added (if not already present in the stack) if respectively DNS, mDNS or DNS-SD querying and/or address resolution is used in the proxy. The additions described above do not interfere with the C0AP/6L0WPAN standards and are completely backward compatible.

Because multiple proxy nodes may be present, each proxy node receiving a wireless resource-constrained device's transmission may - for robustness - need to transmit an IP multicast message to a group of destination devices, in case a destination is defined by a multicast IPv6 addresses. If several proxy nodes do this at the same time, the risk of network congestion is real. Thus, a mechanism by which duplicate IP multicast transmissions by proxies are suppressed is needed. For example, if a proxy observes that a neighbour proxy already sent a multicast (CoAP) message M_P based on a wireless resource-constrained device's protocol message M_z, it suppresses its own scheduled transmission M_P. An analogous mechanism can be used to suppress unicast transmissions from the proxies.

A first mechanism to achieve this for multicast destinations is for each proxy node to monitor local radio transmissions for any IP multicast packets Mp that have as a IP Source address a "faked" IP address of a ZGPD, for which the proxy has also received the corresponding wireless resource-constrained device's transmission M_z. If the proxy does see such an IP multicast packet, it can cancel its own scheduled multicast transmission Mp if that was still not sent. This mechanism can only work in cases where "fake" IP address generation is used by proxies.

A second mechanism for a proxy that receives a wireless resource-constrained device's transmission Mz is to first transmit a special multicast IP message M_CG to a link- local destination e.g. an "all proxies" multicast address or an "all nodes" multicast address. This mechanism could indicate an intention of the proxy to further forward an IP multicast message M_P based on the received wireless resource-constrained device's transmission M_z. Once another proxy node has seen one or two of such special messages M_CG referring to M_P, and it hasn't yet sent its own message M_CG, it may decide to cancel its own IP multicast message M_P transmission triggered by the wireless resource-constrained device's

transmission Mz.

Fig. 5 shows a flow diagram of a forwarding or routing procedure according to a sixth embodiment, where a central concentrator/controller node is introduced.

In step SI 10, a wireless resource-constrained device, e.g. a ZGPD, initiates a wireless data transfer (i.e. message M_z), which contains a unique ID (UID) of the device as well as a sequence number Sz, but not any destination information. In step SI 20, one or more proxy nodes in the radio range of the ZGPD receive the Mz. Then, in step SI 30, the one or more of the proxies that received the Mz tunnel it to a known concentrator/controller node, wherein the tunnel transport is given a sequence number (e.g. CoAP Message ID) Sp which is calculated from the sequence number Sz of the message M_z. In step S140, the

concentrator/controller node translates or (DNS-)resolves the UID into an/a set of IP network address(es) and translates the Mz into an IP message Mp with the right command. Finally, in step SI 50, the concentrator/controller node sends a message M_P using a standard

IP/6L0WPAN protocol (such as CoAP) with the destination field set to a resolved IP address and the source field set to a calculated IP source address, optionally repeating this step S150 for other IP addresses in case multiple IP addresses were obtained in the previous step.

The advantage of the fourth embodiment over the previous embodiments is that the information about the address and functionality translation is only present in one central place, which makes its maintenance easier and accuracy higher. Also, it may relieve the destination devices from storing in memory or non- volatile memory (NVM) any information as to their group membership/control relationships, which again makes maintenance of this information easier and more reliable.

In networks with link- layer security, if 6L0WPAN frames and wireless resource-constrained device's frames are secured in different ways or one of both is not secured and the other is, the radio hardware must support receiving both transmission types at the same time without mode switching. If secured transmission is used by the wireless resource-constrained device, the proxies receiving the transmission may need the security context in order to decode and/or verify the transmission. This can be realized in various ways, such as internal table or database lookup (in which case a proxy needs to be configured first with this security information) or by external table or database lookup, CoRE Resource Directory query, or DNS-SD query (in these cases the external entity used needs to be configured with the security information). Alternatively, in a specific embodiment end-to-end security from the wireless resource-constrained device to destination device(s) can be provided, and thus the security verification can be delegated to the destination, in which case the protected payload, including some security-relevant parts of the message like the frame counter or the Message Integrity Code (MIC), if present, may need to be forwarded by the proxies to the destination.

Another form of security that may be used in a C0AP/6L0WPAN network is

Datagram Transport Layer Security (DTLS) according to the IETF specification RFC 4347 which can be applied to CoAP as described in the CoAP base specification draft-ietf-core- coap. This will secure the IP communication from proxy to destination(s). The above embodiments can be applied in any wireless lighting control systems (office, retail, home and others) with wireless resource-constrained switches, sensors or controls, building control systems with wireless sensors (temperature, presence, humidity, light level, etc.), or any other IP-based system that may benefit from very low-power transmitting (sensing/control) devices. For example, future outdoor lighting systems based on IP networking that use energy-harvesting easy-install "satellite sensors" near lamp posts that report to the nearest lamp post.

The wireless energy-constrained devices can be user-actuated devices using event-based communication, as described by the example of the energy-harvesting switch, harvesting the energy of button push/toggling (e.g. by means of electro -mechanical energy harvester such as magnet moving with respect to coil, piezo-electrical element, step motor, etc.). They can be devices harvesting environmental energy, e.g. of incident light, movement, vibration, temperature difference, electro-magnetic field, e.g. allowing for timer-based and/or measured physical phenomenon-based communication, e.g. solar-powered occupancy sensor. They can further be very energy-constrained battery-operated devices, very memory- and/or processing power constrained devices, preventing them from implementing the entire IP or 6L0WPAN protocol suite, or any combination of the above.

Other variations to the disclosed embodiments can be understood and effected by those skilled in the art in practicing the claimed invention, from a study of the drawings, the disclosure, and the appended claims.

To summarize, the present invention relates to a method and apparatus for operating wireless resource-constrained devices in IP networks, in particular ZGPDs according to the ZGP specification, in 6L0WPAN wireless IP networks, in particular where IP nodes implement CoAP. A proxy node translates a received unique ID of the wireless device into an IP address of the destination device(s) by table lookup or standard Domain Name System resolving. Then, the proxy node sends a command in a standard message format embedded in the IP network's communication to one or more destination IP device(s). A message from the proxy node to the IP destination device(s) may also contain one or more of a transmission-specific value such as a sequence number unambiguously derived from a transmission- specific value received from the wireless device and a calculated IP source address of the wireless device. Thus, one transmission of the wireless device may lead to one or more proxy messages with identical IP source address and transmission- specific value. Thereby, existing wireless resource-constrained devices can be used as-is in IP networks without requiring new specifications or changes to the existing wireless devices. Without limiting the applicability of the invention, a transmission can also encompass a number of re-transmissions at various protocol layers, from physical to application layers, with/without observation of typical wireless protocol mechanisms, like e.g. Clear Channel Assessment (CCA), Carrier-Sense Multiple Access with Collision

Avoidance (CSMA/CA) or Inter-Frame Spacing (IFS) in case of IEEE802.15.4 radio.

Specifically, the wireless resource-constrained devices may be sending multiple copies of the same frame on the MAC level, without using the MAC channel access/MAC

acknowledgement mechanisms; and the duplicates may be filtered out at low- or high protocol level by the proxies, by the resolution mechanisms and/or by the destination devices.

Any calculations, processing and/or control functions of the described embodiments can be implemented as program code means of a computer program and/or as dedicated hardware. The computer program may be stored/distributed on a suitable medium, such as an optical storage medium or a solid-state medium, supplied together with or as part of other hardware, but may also be distributed in other forms, such as via the Internet or other wired or wireless telecommunication systems.

In the claims, the word "comprising" does not exclude other elements or steps, and the indefinite article "a" or "an" does not exclude a plurality.

A single processor or other unit may fulfill the functions of several items recited in the claims. The mere fact that certain measures are recited in mutually different dependent claims does not indicate that a combination of these measures cannot be used to advantage.

Claims

CLAIMS:

1. An apparatus for enabling operation of a wireless resource-constrained device (10) in an Internet Protocol, IP, based network, said apparatus being adapted:

to receive from said wireless resource-constrained device (10) a first message with a unique identification information and a first command;

to obtain from said unique identification information at least one routable IP destination address, whereby said routable IP destination address is at least one of a unicast IP address corresponding to a destination device (30) or a multicast IP address corresponding to a group of destination devices; and

to send at least one command derived from said first command embedded in a higher layer protocol packet embedded in an IP packet of said IP based network to said at least one routable IP destination address.

2. The apparatus according to claim 1, wherein said apparatus is adapted to obtain said routable IP destination address based on said unique identification information by derivation, a look-up operation, or a resolving operation.

3. The apparatus according to any of claim 1 or 2, wherein said apparatus is adapted to derive a first transmission-specific value from said received message and to add to said IP packet a second transmission-specific value derived from said first transmission- specific value or from a combination of said first transmission-specific value with said unique identification information.

4. The apparatus according to any of claims 1 to 3, wherein said apparatus is adapted to look-up or resolve an IP source address or to derive said IP source address from a set of pre-defined parameters including said unique identification information and an IP prefix, and to specify said IP source address in said IP packet that carries said second command embedded in said higher layer protocol packet.

5. An apparatus according to any of claims 1 to 4, wherein said apparatus is adapted to receive a message from said wireless resource-constrained device (10) in the format of an IPv6 multicast packet, especially in a 6L0WPAN packet format.

6. An apparatus according to any of claims 1 to 5, wherein said apparatus is adapted to obtain at least one routable IP destination address from both said unique identification information and said first command.

7. A proxy node of an Internet Protocol, IP, based network, said proxy node (20) comprising an apparatus according to any of the preceding claims.

8. A network node of an Internet Protocol, IP, based network, said network node comprising an apparatus according to any of claims 1 to 6 for sending the at least one command to an IP end-point on said network node or for forwarding it to another network node.

9. A method of operating a wireless resource-constrained device (10) in an Internet Protocol, IP, based network, said method comprising:

receiving from said wireless resource-constrained device (10) a first message with a unique identification information and a first command;

obtaining from said unique identification information at least one routable IP destination address, whereby said routable IP destination address is at least one of a unicast IP address corresponding to a destination device (30) or a multicast IP address corresponding to a group of destination devices; and

sending at least one second command derived from said first command embedded in a higher layer protocol packet embedded in an IP packet of said IP based network to said at least one destination address.

10. The method according to claim 9, further comprising look-up or resolution of an IP source address or derivation of said IP source address from a set of pre-defined parameters including said unique identification information and an IP prefix, and specifying said IP source address in an IP packet that carries said higher layer protocol packet.

11. The method according to claim 9 or 10, wherein said first message comprises an IEEE 802.15.4 radio frame, an IEEE 802.11 radio frame or an EnOcean radio frame.

12. The method according to claim 9, 10 , or 11, wherein said first message comprises a wireless data transmission in a Green Power Device Frame, GPDF, format, a GPDF frame format carrying a specific higher layer protocol packet, or an EnOcean frame format.

13. The method according to any of claims 9 to 12, wherein said higher layer protocol is the IETF Constrained Application Protocol, CoAP.

14. The method according to any of claims 9 to 13, further comprising storing in said destination device (30) a value derived from said first or second command in a local storage and making it available for retrieval by at least one other device that uses a higher layer protocol of said IP based network to retrieve said stored value.

15. A computer program product comprising code means for producing the steps of method claims 9 to 14 when run on a computing device.