阅读说明：本技术 用于数据传输的扩展协议帧 (Extended protocol frame for data transmission ) 是由 A·沃斯 E·拉尔法斯 于 2013-12-11 设计创作，主要内容包括：将数据帧从源设备发送到目标设备,其中,源设备和目标设备使用协议,所述协议定义了用于轮询未决数据的请求命令帧,包括以下步骤：在源设备中获得要被发送到目标设备的数据；在目标设备处产生用于轮询对于源设备未决的数据的请求命令帧；将要发送的数据分配在请求命令帧中；以及将具有要被发送的分配数据的请求命令帧发送到目标设备。(Transmitting a data frame from a source device to a target device, wherein the source device and the target device use a protocol defining a request command frame for polling pending data, comprising the steps of: obtaining, in a source device, data to be transmitted to a target device; generating, at the target device, a request command frame for polling data pending for the source device; distributing data to be transmitted in a request command frame; and transmitting a request command frame having the allocation data to be transmitted to the target device.)

1. A method of transmitting a data frame from a source device to a target device, wherein the source device and the target device use a protocol defining a request command frame for polling for pending data, the method comprising the steps of:

-storing pending data to be sent to the source device in the target device;

-receiving a request command frame from the source device for polling the pending data;

-in response to receiving the request command frame, sending the pending data to the source device; and

-extracting allocation data to be sent from the source device to the target device from the received request command frame.

2. The method according to claim 1, further comprising the step of processing the extracted allocation data and/or forwarding the extracted allocation data to a central entity.

3. A method according to claim 1 or 2, wherein the allocation data is extracted from the message overhead of a received request command frame.

4. A method according to claim 1 or 2, wherein the allocation data is extracted from a received request command frame following a command frame identifier and a message overhead of the request command frame.

5. A method according to claim 4, comprising the step of determining whether allocation data follows the command frame identifier in a received request command frame.

6. The method according to any of claims 1 to 5, wherein the structure of the frame is compatible with the IEEE802.15.4 standard or related implementations.

7. A method of transmitting a data frame from a source device to a target device, wherein the source device and the target device use a protocol defining a request command frame for polling for pending data, the method comprising the steps of:

-obtaining, in the source device, data to be transmitted to the target device;

-generating a request command frame at the target device for polling data pending for the source device;

-allocating data to be transmitted in said request command frame; and

-transmitting the request command frame with allocation data to be transmitted to the target device.

8. The method of claim 7, further comprising the step of waiting to receive the pending data in response to sending the request command frame.

9. The method of claim 8, further comprising the step of setting the source device to a power saving mode after determining that no pending data needs to be received or that the pending data has been received.

10. The method according to any of claims 7 to 9, wherein the step of generating the request command frame is triggered by an interval or timer expiration.

11. The method according to any of claims 7 to 10, wherein the step of generating the request command frame is triggered by the occurrence of an event.

12. A method according to any one of claims 7 to 11, wherein the data to be transmitted is allocated in the message overhead of the request command frame.

13. A method according to any one of claims 7 to 11, wherein the data to be transmitted is appended to the message overhead and command frame identifier of the request command frame.

14. The method according to any of claims 7 to 13, wherein the structure of the frame is compatible with the IEEE802.15.4 standard or related implementations.

15. A target device for receiving data frames from a source device, wherein the source device and the target device use a protocol defining a request command frame for polling pending data, the target device being configured to:

-storing pending data in the target device to be sent to the source device;

-receiving a request command frame from the source device for polling the pending data;

-in response to receiving the request command frame, sending the pending data to the source device; and

-extracting from the received request command frame allocation data to be sent from the source device to the target device.

16. The apparatus of claim 15, further adapted to carry out the method of any one of claims 2 to 6.

17. The apparatus of claim 15 or 16, comprising a processing unit and a memory unit, the memory unit storing code to configure the processing unit to implement the functions of the apparatus.

18. The apparatus according to any one of claims 15 to 17, comprising a communication unit for establishing communication over a shared channel.

19. The device according to any of claims 15 to 18, comprising an internal power source, preferably any of a battery, a rechargeable battery, a solar cell.

20. The device of any of claims 15 to 19, further configured as a data collection device as part of a distributed data acquisition apparatus and configured to transmit frames to a data acquisition unit.

21. A source device to transmit a data frame to a target device, wherein the source device and the target device use a protocol defining a request command frame for polling pending data, the source device being configured to:

-obtaining data to be sent to the target device;

-generating a request command frame at the target device for polling data pending for the source device;

-allocating data to be transmitted in said request command frame; and

-transmitting the request command frame with allocation data to be transmitted to the target device.

22. The apparatus of claim 21, further adapted to carry out the method of any one of claims 8 to 14.

23. A device according to claim 21 or 22, comprising a processing unit and a memory unit, the memory unit storing code for configuring the processing unit to implement the functions of the device.

24. The apparatus according to any of claims 21 to 23, comprising a communication unit for establishing communication over a shared channel.

25. A device according to any of claims 21 to 24, comprising an internal power source, preferably any of a battery, a rechargeable battery, a solar cell.

26. The device of any of claims 21 to 25, further configured as a data acquisition device as part of a distributed data acquisition apparatus, the data acquisition device comprising a sensor unit for acquiring data and configured to receive frames from a data collection unit.

27. A system for distributed data acquisition comprising at least one device according to any one of claims 15 to 20 and at least one device according to any one of claims 21 to 26.

Technical Field

The invention relates to the field of data transmission between a source device and a target device, wherein the devices employ a protocol defining a request command frame. In particular, the present invention relates to a method of transmitting a data frame, and a corresponding device configured to transmit a data frame. More particularly, the present invention relates to the field of distributed data collection as part of facility management.

Background

There are many established protocols for data exchange and communication. Some protocols are adapted to the specific characteristics of the communication channel employed, as the protocol specifies, among other things, consideration of the data rate of the channel, whether the channel is shared, the length of the channel, the physical implementation (e.g., wired or wireless transmission), the radio frequency bandwidth, and the like. Protocols and provisions for local wireless communication include, for example, EnOcean (TM), Dash7(TM), OneNet (TM), ANT (TM), Bluetooth (TM), Z-wave (TM), Zigbee (TM), WirelessHart (TM), 6LoWPAN (TM), Miwi (TM), IEEE802.15.4, IEEE802.11(WiFi), and others.

In general, a protocol defines a number of data units that represent the minimum amount of information to be sent over each channel. Such units are called "packets", "telegrams" or "frames". In the context of the present disclosure, the term "frame" shall denote such information units as defined by the respective protocol under consideration. Furthermore, a frame with addressing and/or routing information is typically provided, so that any entity receiving the frame can in principle decide whether the received frame is addressed to this entity.

In addition to implementing protocols, there is a wide range of standard hardware to facilitate actual communication. For example, a module may be used to communicate based on one or more protocols such that the protocols and communication capabilities need not be repeatedly implemented in a given application. The modules often feature some kind of interconnectivity to facilitate cooperation with applications. In other words, by relying on standardized modules for enabling communication, people can concentrate on such applications. Thus, protocols and communication functions need not be explicitly included in such applications.

While the adoption of standardized protocols and corresponding hardware, either in the form of the aforementioned modules or as a built-in function of an Integrated Circuit (IC), offers advantages in terms of simplicity, reliability and cost, the use of standard "devices" implies respective limitations and constraints from the chosen standard solution. As a result, on the one hand, the selected protocol can be substantially advantageous for implementation (low circuit complexity, high reliability, low unit cost, etc.), but on the other hand, at the same time, strict constraints are imposed.

Wherein the standard protocol may define a strict order in which data exchange needs to be performed. For example, the IEEE802.15.4 standard (and related implementations) provides for so-called request command frames that are used to poll for pending data. In this way, the receiving entity (device) may be powered down or in an idle state while the sending entity (device) generates or accumulates data to be sent to the receiving entity. This pending data may then be polled by the receiving entity by sending a request command frame to the sending entity. As a result, the receiving entity can independently decide when to receive any pending data, and thus does not have to be "online" all the time. Conversely, the receiving device may save power when it decides that it does not have to receive any pending data at the moment.

Meanwhile, distributed data collection is becoming more and more common in various environments, such as scientific research, industrial equipment, network management, facility management, and the like. With the advent of the so-called "internet of things," distributed standalone devices or applications come online in order to collect local information, possibly process it, and forward or send the collected data to some central entity for further processing and/or evaluation.

For example, sensor devices measure the use of resources (e.g., water, electricity, soap, etc.) in a facility. The collected information may then be collected by some means that communicates to the individual sensor devices. It is desirable that all such devices operate reliably, be inexpensive to manufacture, and have low power consumption (e.g., the latter allowing for battery-powered stand-alone devices). Although the above object can be achieved by employing standard protocols and corresponding hardware, the selected protocol then limits the number of addressable devices possible, since the address space of the selected protocol does not allow a sufficient number of unique addresses and thus device identifiers to be defined.

Therefore, there is a need in various environments to allow application implementation by means of standard equipment. At the same time, however, there is a need to further reduce the power consumption of the devices involved. Especially considering distributed data acquisition devices, which are only provided with limited power resources and where it is desirable to reduce maintenance (e.g. replacing or recharging batteries) to a minimum. In particular, there is a need to further improve standardized protocols and corresponding hardware for power efficiency.

Disclosure of Invention

The mentioned problems are solved by the subject matter of the independent claims. Further preferred embodiments are defined in the dependent claims.

According to one aspect of the present invention, there is provided a method of transmitting a data frame from a source device to a target device, wherein the source device and the target device use a protocol defining a request command frame for polling for pending data, the method comprising the steps of: storing pending data to be sent to the source device in the target device; receiving a request command frame for polling pending data from a source device; transmitting the pending data to the source device in response to receiving the request command frame; and extracting allocation data to be transmitted from the source device to the target device from the received request command frame.

According to another aspect of the present invention, there is provided a method of transmitting a data frame from a source device to a target device, wherein the source device and the target device use a protocol defining a request command frame for polling for pending data, the method comprising the steps of: obtaining, in a source device, data to be transmitted to a target device; generating, at the target device, a request command frame for polling data pending for the source device; distributing data to be transmitted in a request command frame; and transmitting a request command frame having the allocation data to be transmitted to the target device.

According to another aspect of the present invention there is provided a target device for receiving a data frame from a source device, wherein the source device and the target device use a protocol defining a request command frame for polling pending data, the target device being configured to: storing pending data in the target device to be sent to the source device; receiving a request command frame for polling pending data from a source device; transmitting the pending data to the source device in response to receiving the request command frame; and extracting allocation data to be transmitted from the source device to the target device from the received request command frame.

According to another aspect of the present invention there is provided a source device for transmitting a data frame therefrom to a target device, wherein the source device and the target device use a protocol defining a request command frame for polling pending data, the source device being configured to: obtaining data to be sent to a target device; generating, at the target device, a request command frame for polling data pending for the source device; distributing data to be transmitted in a request command frame; and transmitting a request command frame having the allocation data to be transmitted to the target device.

According to another aspect of the present invention, there is provided a system for distributed data acquisition, the system comprising at least one source device of any of the disclosed embodiments and at least one target device of any of the disclosed embodiments.

Drawings

Embodiments of the present invention will now be described for a better understanding of the inventive concepts, without being considered to be limiting thereof, with reference to the accompanying drawings, in which:

FIG. 1A shows a schematic diagram of a data acquisition system comprising a central entity, data collection means and data acquisition means, and implementing data frame transmission, according to an embodiment of the invention;

FIG. 1B shows a schematic diagram of an exemplary data collection unit implementing data frame transmission according to another embodiment of the present invention;

FIG. 1C shows a schematic diagram of an exemplary data acquisition unit implementing data frame transmission according to another embodiment of the present invention;

fig. 2 shows a possible implementation of data frame transmission in a data collection device and a data acquisition device arranged in a facility according to another embodiment of the invention;

FIG. 3A is a diagram illustrating a conventional request command frame;

FIG. 3B is a diagram illustrating a request command frame according to another embodiment of the invention;

FIG. 3C is a diagram illustrating a request command frame according to another embodiment of the invention;

FIG. 4 shows a schematic diagram of a sequence of frames between a source device and a target device according to another embodiment of the invention; and

fig. 5A and 5B show a flow chart of a method embodiment of the present invention.

Detailed Description

Fig. 1A shows a schematic diagram of a data acquisition system according to an embodiment of the invention, comprising a central entity, data collection means and data acquisition means, and implementing data frame transmission. In particular, the data acquisition system according to the present embodiment comprises a central entity 10, data acquisition means in the form of one or more data acquisition units 30, 30 ', and data acquisition means in the form of one or more data acquisition units 40, 40'. The central entity 10 may exchange data with the data collection units 30, 30' using some kind of network or network system 20, which network or network system 20 may comprise the internet, one or more enterprise networks, and/or a public network, such as a telephone or mobile communication network.

By way of example, a first link 91 couples the central entity 10 to the internet 20 and a second link 92 couples the at least one data collection unit 30 to the internet 20. As other examples, the link 92 between the data collection unit 30 and the network 20 may be a direct internet connection or a collimated internet connection, for example via a DSL or LAN line. Furthermore, wireless data transmission may also be employed, so that the data collection devices 30, 30' communicate via an air interface (GSM, UMTS, WLAN, WiFi, WiMaX, etc.) to a mobile communication network or respective access point and thereby to the network 20.

Optionally, one or more data collection units 30' of the data collection apparatus may be coupled to the network 20 through one or more intermediate data collection levels (levels). One way is to implement an optional hierarchical device 50 between the data collection unit and the network 20. Such optional hierarchy devices (units) may in turn collect, process and/or forward data from one or more data collection units 30' to or from the network 20 or between the networks 20. For example, the optional level device 50 may be provided at a building level, a regional level, a department level, a floor level. In this manner, the corresponding level devices 50 collect, process and/or forward data to and from the data collection devices 30' respectively disposed in an area, a building, a department or a floor.

The data acquisition means is in the form of at least one data acquisition unit 40 arranged at a corresponding position for acquiring data (collecting information). This data may be collected through the use of one or more sensors configured to convert some physical number (configuration) into a value suitable for transmission over a communication network. The physical numbers may include any measurable quantity such as temperature, illumination, time and date, air pressure, humidity, current, voltage, resistance, etc. In particular, the measured numbers may reflect some equipment states, such as consumption, filling, expiry date, etc. For example, the barrier may employ a light source and a light sensor that measures the intensity of illumination to determine the fill level of the dispenser (dispenser) or waste bin. Other suitable concepts that may be sensed by means of physical numbers include infrared detection, ultraviolet detection, Radio Frequency (RF) detection, ultrasonic detection, and the like.

According to the present embodiment, one individual data collection unit 40 communicates with at least one data collection unit 30 via a wireless link 93 (e.g., a radio or infrared link), which may conform to one or more applicable and previously described standards and protocols. As a specific example, the wireless link 93 may be implemented by the IEEE802.15.4 standard (or related implementations) that provides a request command frame for polling for pending data, or in a manner that the structure of the frame used is compatible with the IEEE802.15.4 standard or related implementations.

The specific manner of data frame transmission in the present embodiment will now be described in more detail with reference to fig. 1B and 1C. Specifically, fig. 1A shows a schematic diagram of an exemplary data collection unit 30 as one possible implementation of a target device using data frame transmission according to the present embodiment, and fig. 1C shows a schematic diagram of an exemplary data acquisition unit 40 as one possible implementation of a source device using data frame transmission according to the present embodiment.

The exemplary data collection unit 30 shown in fig. 1B includes a processing unit 302, a storage unit 301, and a communication unit 303. The memory unit 301 may store computer instruction code that may be executed on the processing unit 302 in order to implement the functional and method embodiments of the present invention. The communication unit 303 comprises a wireless communication device that facilitates data exchange and communication towards one or more associated data acquisition units 40, 40' via respective links 93. Note that link 93 may be allocated on a separate channel or all on a shared channel in the sense that more than one data acquisition unit 40 receives a frame, although the frame is addressed to only one particular data acquisition unit (e.g., data acquisition unit 40'). With respect to the link 92, data communication to the network 20 may be accomplished, for example, via a wireless link to the hierarchy 50, which hierarchy 50 in turn has a DSL or LAN connection to the internet 20.

The storage unit 301 stores computer instruction code executable on the processing unit 302 to implement a method of transmitting data frames from the data acquisition unit 40 as a source device to the data collection unit 30 as a target device, wherein said units use a protocol defining request command frames for polling pending data, such as the IEEE802.15.4 standard or a related implementation, or a frame structure compatible therewith. In particular, the storage unit 301 stores code for implementing the storage of pending data to be sent to the data acquisition unit 40. By storing this pending data, the data acquisition unit 40 need not always be "online" and may decide for itself when to receive the pending data (e.g., when the unit 40 needs to be powered up anyway for other reasons). Further, the stored code implements receiving a request command frame from data acquisition unit 40 for polling pending data, and in response to receiving the request command frame, sending the pending data to data acquisition unit 40.

According to an embodiment of the invention, the code also implements extraction of the allocation data to be sent from the data acquisition unit 40 to the data collection unit 30 from the received request command frame. In this way, not only is pending data polled by the data acquisition unit 40, but allocation data destined for the data collection unit is sent in a frame at the same time. Thus, the data collection unit may save more power as it may wait until allocation data, such as collected sensor measurement data, needs to be sent to the data collection unit 30 and thereby poll for any pending data at the same time.

The exemplary data acquisition unit 40 shown in fig. 1C comprises a processing unit 402, a storage unit 401 and a communication unit 403. The memory unit 401 may store computer instruction code that may be executed on the processing unit 402 in order to implement the functional and method embodiments of the present invention. The communication unit 403 may optionally include a wireless communication device that facilitates the exchange and communication of data towards the associated data collection unit 30. Also, preferably, the communication towards the associated data acquisition unit may be implemented as described in connection with link 93.

As a data acquisition unit, it further comprises a sensor unit 404 configured to acquire desired data, for example by measuring one or more numbers of interest. The sensor unit 404 may for this reason employ sensor devices, current/voltage sources, light sources, threshold circuits, analog-to-digital converters, averaging circuits, filter circuits, etc. In particular, the storage unit 401 stores computer instruction code that can be executed on the processing unit 402 to receive data (frames) from and transmit data to the associated data collection unit.

For example, a frame from an associated data collection unit (downlink) may include configuration data and/or instructions that set any of acquisition interval, acquisition accuracy, number selection (i.e., what number to acquire), set the unit to a powered on, powered off, or idle state, set a transmission interval, and so forth. On the uplink, the data collection unit may report collected data and/or status information (e.g., operational status, possible faults, remaining battery/power resources, etc.) back to the associated data collection unit.

The storage unit 401 stores computer instruction code which can be executed on the processing unit 402 in order to implement an embodiment of the invention, i.e. to send data frames from the data acquisition unit 40 as source device to the data collection unit 30 as target device, wherein said units also use a protocol defining request command frames for polling pending data, such as the ieee802.15.4 standard or a related implementation, or a frame structure compatible therewith. In particular, the storage unit 401 stores code for implementing the obtaining of data to be sent to the data collection unit 30, which data may be any of collected sensor measurement data, status data, still active messages, etc. The code also implements generation of a request command frame at the data collection device 40 for polling the data collection unit 40 for pending data in the sense that the data collection device 40 can store (buffer) any data to be sent to the data collection unit 40.

According to an embodiment of the invention, the code also implements the allocation of data to be transmitted in a request command frame and the transmission of the request command frame with the allocation data to be transmitted to the data collection device 40. In this way, the data collection unit 40 may decide for itself when to poll the pending data from the data collection device 30. For example, the data acquisition unit 40 may wait until the report of measured sensor data expires (e.g., given by a time interval or triggered by an event), resulting in the data acquisition unit 40 needing to be powered up in some manner to enable transmission of the data. In this case, the data acquisition unit may combine the report data with the poll pending data by allocating the data into a request command frame.

As a result, not only the data acquisition unit 40, but also the data collection unit 30 can save more power because both tasks are completed with one frame. Note that, in general, allocating data into a request command frame and transmitting this frame is still more power efficient than transmitting two separate dedicated frames due to the format and addressing overhead (addressing overhead) of each frame. Furthermore, in addition to more efficient use of available power resources, radio resources are also used more efficiently. Instead of two or more frames, only one frame is advantageous for two purposes. In this way, interference and emissions are further reduced.

It should also be noted that a fully bi-directional data exchange is possible between the central entity 10 on the one hand and one individual data acquisition unit 40, 40' on the other hand. In particular, the central entity 10 may send data to a particular data collection unit 40' via link 91, network 20, link 92, associated data collection unit 30 and link 93. Similarly, the individual data collection units 40' may transmit data back to the central entity 10 via link 93, the associated data collection unit 30, link 92, network 20 and link 91. As an example, data in the downlink, i.e. in the direction from the central entity 10 to the data acquisition units, may comprise configuration data, while data in the uplink, i.e. in the direction from one data acquisition unit to the central entity 10, may comprise sensor data representing locally acquired data in a format suitable for transmission and further processing.

Fig. 2 shows a possible implementation of data frame transmission in a data collection device and a data acquisition device arranged in a facility, in particular a managed facility in the form of a toilet 1, according to another embodiment of the invention. Restroom 1 has several locations from which consumables may be dispensed, including waste bin 41, toilet paper dispenser 42, hand sanitizer dispenser 43, and towel dispenser 44. During use in a restroom, cleaning composition dispenser 43, wipe dispenser 44, and toilet paper dispenser 42 may be depleted and waste bin 41 may be filled.

In a conventional facility management scenario, a maintenance person or team would periodically check toilet 1, including checking the height in dispensers 43, the amount of wipes in wipe dispensers 44, the amount of toilet paper in toilet paper dispensers 42, and the height of waste in each waste bin 41. The maintenance person can make a decision as to whether any one resource is likely to need replenishment during the period before its next scheduled maintenance visit, and he can replenish those resources that are deemed to need such replenishment, as long as the staff has sufficient consumables on the maintenance cart. The maintenance personnel can also empty the waste tank 41 as long as the personnel have sufficient space of remaining capacity for waste on the maintenance trolley. If there is insufficient capacity space or remaining resources on the cart for waste, the staff may not replenish the resources or may adjust their route to re-replenish the cart to a central storage point before continuing.

In this embodiment the toilet 1 in fig. 2 further comprises a data collection unit 31, e.g. the unit described as unit 30, 30' in connection with the other embodiments. The data collection unit 31 has an associated data acquisition unit in each of the dispenser/waste bins 41-44. In particular, these data acquisition units measure the towel, toilet paper and soap consumption and the filling of the waste bin 41, respectively, in order to report this acquired data back to the central entity for facility management via the data collection unit 31. This data is sent on the uplink towards the central entity.

More generally, however, embodiments of the invention may also be applied to any type of facility management where large-scale management of the use of consumables and their supply is required. For example, large organizations such as corporations, institutions, and the like provide public facilities for use by, for example, employees, visitors, and other personnel. In the case of a commercial establishment, such facilities may include not only washrooms as shown in connection with fig. 2, but also conference rooms, document preparation stations, food preparation stations, maintenance stations, local supply warehouses, and other similar facilities.

Each facility may be associated with a storage or distribution point, where the consumable items to be used in and around the facility may be stored for use, and where the discarded consumable items may be stored for disposal. In the case of a toilet, such storage points may include toilet paper dispensers, hand sanitizer or antiseptic gel dispensers, trash cans, and sanitary dispensers. In the case where the facility is a document preparation center, the storage points may include paper storage points, ink cartridge storage points, stationery storage points, and the like. Where the facility is a maintenance area, the storage points may include storage points for different components, for maintenance and cleaning compounds, and for example hand sanitizer dispensers and paper towel dispensers. Such sites typically provide resources to users of the facility. In particular, the resource may be a consumable or may be a space for storing used consumables and/or garbage. In each case, the resources may be exhausted by users of the facility.

Such management can present considerable organizational and logistical challenges and is heavily dependent on the experience of the managers and workers. Such challenges include ensuring that each facility is viewed on a sufficiently regular basis to assess the resource requirements of each location in the facility and, optionally, replenish and/or empty the location. Other challenges include ensuring that facilities are maintained in proper condition without providing a very large area for storage of waste or keeping a large inventory of consumables in the facilities themselves, on supply carts, or at a central location. Finally, a significant challenge is to manage the facility in a manner that enables responses to exceptional events that result in the sudden depletion of one or more resources or the sudden accumulation of waste.

For these applications, the present embodiment may provide an advantageous solution, since the distributed data acquisition arrangement may be provided in a generally efficient manner. In particular, due to the use of standardized communication solutions, embodiments of the present invention are able to provide cost-effective and reliable devices (data collection devices and data collection devices) and interoperability and, at the same time, allow more efficient use of the available power resources at the equipment involved. In addition, interference and radio frequency emissions may be further reduced by reducing the amount of frames exchanged over the air interface during normal operation.

Fig. 3A shows a schematic diagram of a conventional request command frame, and in particular, the request command frame 70 includes a frame overhead 701 and a command frame identifier 702. The command frame identifier 702 may store a value that characterizes the frame 70 as a request command frame. In this manner, any receiving entity can identify frame 70 as a request command frame in order to initiate all operations and processing required by the respective standard.

In the example of the IEEE802.15.4 standard (and related embodiments or frame structures compatible therewith), the frame overhead 701 may include a variable number of octets (bytes), including so-called MHR fields, such as a frame control field, a sequence number field, an addressing field, and so forth. Further, the command frame identifier 702 may specify a particular value, such as a hexadecimal value of 0x04, which is one way to identify the frame 70 as a request command frame.

Fig. 3B shows a schematic diagram of a request command frame according to another embodiment of the invention. The request command frame 71, similar to the frame 70 described in connection with FIG. 3A, includes a frame overhead 701' and a command frame identifier 702. According to this embodiment, the request command frame overhead 701' is modified to also include the allocated data 710. This may be achieved by taking unused data in the frame overhead or by extending the size of the overhead 701' relative to the overhead 701 of the frame 70. One possibility is to use the unused addressing field of the MHR field or to add arbitrary data to a field with variable length. For example, the allocated data may be appended in the form of an additional addressing field, as such an addressing field may have a variable octet (byte) length.

Fig. 3C shows a schematic diagram of a request command frame according to another embodiment of the invention. The request command frame 72 likewise includes a frame overhead 701 and a command frame identifier 702. According to this embodiment, the allocated data is added to the frame, for example at the end of the command frame identifier 702. In this manner, the allocated data may have a variable, almost unlimited length, as the data 710 follows the standard configuration of the overhead 701 and command frame identifier 702. In this way, any employed device need only be configured to check whether the allocated data 710 is included in the request command frame 72 by simply listening (receiving) for any other data after the command frame identifier 702 has been received. As a result, modifications to existing devices and implementations may remain very small. At the same time, however, the advantages of the disclosed embodiments may still be obtained.

Fig. 4 shows a schematic diagram of a sequence of frames between a source device and a target device according to another embodiment of the invention. In this embodiment, the source device is a data acquisition unit 40 as disclosed and described in connection with the other embodiments, and the target device is a data collection unit 30 as also disclosed in connection with the other embodiments. During the silent period 91, the data acquisition unit 40 is in a power saving or idle mode, or focuses its resources on acquiring and collecting sensor data or detecting any events. During said silent period 91 any means for performing radio communication (e.g. via link 93 as disclosed in connection with fig. 1A) may be powered down or set to a power saving mode, since no communication, data and frame exchange will take place.

At some point in time, data acquisition unit 40 decides to report data back to data collection unit 30 and, at the same time, requests any pending data. For this purpose, the data acquisition unit 40 generates a request command frame and allocates in this frame any data to be sent to the data collection unit 30. This so generated request command frame is sent to the data collection unit 30 in 92. Data collection unit 30, in turn, receives the request command frame and determines whether any data is pending for data acquisition unit 40. Thus, the data collection unit 30 sends an acknowledgement message at 93, which includes some notification, for example in the form of setting a frame pending flag, if there is pending data for the data acquisition unit 40. If data is indeed pending, this data is sent from the data collection unit 30 to the data acquisition unit 40 at 94. Since the data acquisition unit 40 has completed all necessary tasks, i.e. reporting data to the data collection unit 30, and at the same time receiving any pending data, the unit 40 may return to the silent state 91.

Fig. 5A shows a flow chart of a method embodiment of the present invention. This method embodiment is directed to implementing transmission of a data frame from a source device to a target device, wherein the source device and the target device use a protocol that defines a request command frame (e.g., IEEE802.15.4 and related implementations, or frame structures compatible therewith) for polling for pending data. The method embodiment includes step S11 of storing pending data to be sent to the source device in the target device. This data may be, for example, configuration data (acquisition interval, acquisition accuracy, power saving mode, request to report on the level of remaining power resources, etc.) obtained from some central entity to be forwarded to the source device in order to configure its operation and behavior.

In step S12, a request command frame for polling pending data is received from the source device. If there is indeed pending data, this pending data is sent to the source device in response to receiving the request command frame in step S14. If no data is pending, a simple acknowledgement message may be sent with some indicator to inform the source device that no data is pending and that the source device may therefore return to some kind of power saving mode or idle mode. In step S13, any allocation data to be transmitted from the source device to the target device is extracted from the received request command frame. Note that the illustrated order of steps S13 and S14 may be arranged in any suitable manner, e.g., such that also (optional) step S14 is performed before step S13.

Fig. 5B shows a flow chart of a method embodiment of the present invention. This method embodiment is directed to transmitting a data frame from a source device to a target device, wherein the source device and the target device use a protocol that defines a request command frame for polling for pending data (as in IEEE802.15.4 and related embodiments, or frame structures compatible therewith). The method embodiment comprises a step S21 of obtaining data in the source device to be sent to the target device. This may include, for example, collecting, processing or storing sensor measurement data to be reported to a data collection unit and further to some kind of central entity.

In step S22, a request command frame for polling data pending for the source device is generated at the target device. Preferably, step S22 and subsequent steps may be initiated in response to a determination that the data obtained in step S21 needs to be transmitted, for example, when some acquisition/reporting interval has expired and/or an event related to the acquired measurement data occurs (e.g., the measurement values satisfy some condition with respect to a predetermined threshold). In step S23, the data to be transmitted is allocated in the request command frame, and in step S24, the thus-generated request command frame with the allocation data to be transmitted is transmitted to the target device. If there is indeed pending data, this data may be received in optional step S25.

While specific embodiments have been described, these are only intended to provide a better understanding of the invention as defined by the independent claims and should not be taken as limiting.