1. Field of the Invention
The invention relates to communication networks and, more particularly, to a beacon for a star network, a sensor node in the star network, a method for initializing a gateway in the star network and a method for operating the star network.
2. Description of the Related Art
Production automation has very high quality requirements for wireless networks, in particular a very small guaranteed response time (node would like to send a datum, where datum is received by the recipient). Attempts are usually made to achieve this with a star-shaped network using a timeslot method, such as Time Division Multiple Access (TDMA). The central node of the network, i.e., the gateway, stipulates a superframe that contains the allocation of the timeslots to the individual sensor nodes. The necessary synchronization of the sensor nodes with the superframe is effected by periodically emitting beacons by the gateway as the start of each superframe. In order to meet the high time demands, as much status information as possible is stored implicitly so that the data packets are very small (see also M. Bahr, M. Vicari, L. Winkel: Proposal for Factory Automation, IEEE P802.15 Wireless Local Area Networks, document 15-09/0228r0, March 2009—hereinafter referred to as document, in which the smallest MAC packet is just 4 bytes in size for a byte of payload).
Such optimization, however, is achieved at the cost of flexibility. For a single fixed wireless star network in which the nodes always listen for the gateway beacons, i.e., are always on, and also never leave this network, i.e., no roaming of the sensor nodes occurs between various gateways, this works quite well.
However, there are also numerous application cases where these restrictions do not apply and somewhat greater flexibility is required. Firstly, to save energy, some sensor nodes switch themselves off and by doing so miss multiple beacons. Secondly, sensor nodes move through the radio areas of multiple star networks/gateways (roaming), for example, on a conveyor belt.
Using the current mechanisms as described in document referred to above, there are no self-organizing methods for this which can cope efficiently with it. Once a sensor node has not noticed a certain number of beacons or has switched to the area of a different gateway, severe disruptions in wireless data transmission can occur:
Added to this is the fact that in the Institute of Electrical and Electronic Engineers (IEEE) 802.15.4-2006 standard (IEEE 802: Part 15.4: Wireless Medium Access Control (MAC) and Physical Layer (PHY) Specifications for Low-Rate Wireless Personal Area Networks (WPANs), IEEE Std 802.15.4™-2006, September 2006—hereinafter referred to as document), which forms the basis for document [1] referred to hereinabove and for this invention, the interframe spacing (IFS), i.e., the minimum interval between two packets is very greatly increased in the case of MAC packets which are greater than 18 bytes: From 12 symbols (corresponding to 6 bytes) to 40 symbols (corresponding to 20 bytes). This is an enormous time loss that should if possible be avoided, i.e., the beacon should as a rule be ≦18 bytes on the MAC layer.
Star networks are a popular topology for wireless networks. There is always a central node (access point, coordinator, base station, gateway, etc.) with which the terminal devices (stations, clients, terminal devices, sensor nodes, etc.) communicate directly.
IEEE 802: Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications, IEEE Std 802.11™-2007, September 2007—hereinafter referred to as document [3]), defines a beacon for the access points so that WLAN stations can recognize these and can associate themselves with them. The structure of an IEEE 802.11 beacon is shown in
The individual fields of the structure shown in
IEEE 802.11 is based on the CSMA (carrier sense multiple access) method so that new devices also have an opportunity to transmit data. Even if the PCF is used, there is always a CSMA-based contention period.
Document [2] defines a “beacon-enabled” mode in which a superframe structure is defined which also provides timeslots (see
The beacon is periodically emitted by the coordinator and is used for synchronizing the devices associated with the coordinator, identifying the star network and describing the structure of the superframe.
The individual fields of the beacon shown in
In the contention access period in which access is regulated via CSMA, new devices can log on and apply for appropriate GTS. The length of the contention access period derives from the superframe specification transmitted in the beacon.
In document [1] mentioned in the introduction a star network with a timeslot method is defined, by means of which a very small delay is possible. A key feature is a very short MAC header (1 byte). The superframe is configured in explicit configuration modes, during normal operating mode this information is available in the nodes only implicitly. The central node is called a gateway, the devices connected in a star-shape are termed sensors or actuators.
The beacon contains very little information and actually serves only to indicate the mode and to synchronize the sensors with the superframe.
The individual fields of the beacon have the following meanings:
New devices cannot actually log on or send control packets to the gateway in normal operating mode. During the configuration modes it can be stipulated that management timeslots in which CSMA access applies are present at the start of the superframe. However, this configuration is not known to the new devices. As a result, they cannot use these management timeslots. The same is true of shared-group timeslots, in which CSMA access is also possible, but the configuration of the shared-group timeslots is not known to the new devices.
It is therefore an object of the invention to upgrade a beacon such that upon receipt of the beacon configurations of the star network can be differentiated, gateways can be differentiated, and new sensors or human-machine-interface (HMI) devices have the possibility of sending control packets to the gateway.
This and other objects and advantages are achieved in accordance with the invention that provides an upgraded beacon comprising configuration of the management timeslots, i.e., length of a base timeslot, and
Management timeslots are used in a superframe for transmitting configurations for the system. The management timeslots are always planned in pairs, where one management timeslot is available for each transmission direction (uplink/downlink). The management timeslots are arranged directly after the beacon. Access to the management timeslots is always performed based on the CSMA method. Depending on the application, the size of a configuration message may exceed the size of a base timeslot. It is therefore, where appropriate, necessary for the management timeslots to be longer than a base timeslot. Such a management timeslot is specified by the two parameters “Timeslot size” and “Number of base timeslots per management timeslot”
The gateway ID is an identifier for the gateway of a star network. It may be derived from the MAC address of the gateway, but does not have to be. The Gateway ID may, for example, be a random number, or be predefined by a network management system.
The gateway ID is also stored as an attribute of a star network configuration in the relevant sensor nodes. If a sensor node moves between multiple gateways, then it can select the appropriate configuration using the gateway ID transmitted in the beacon.
Without the gateway ID, the exact pathway, i.e., the exact order of star networks passed through, would have to be specified when roaming in order for appropriate configurations to be reloaded. If the sensor node moves along the wrong path and comes to a star network out of turn, there is the risk of data collisions and serious disruptions in data communication.
With the gateway ID, the sensor node can select the right configuration for the current gateway and as a result can move much more flexibly when roaming.
The above remarks on the gateway ID still assume that the current configuration in a defined star network does not change. With the configuration sequence number, a change in the configuration of a star network can also be recognized.
The configuration sequence number is primarily an identifier for a defined configuration of the star network. If the CSN from the beacon does not match the CSN stored as an attribute of the star network configuration in the sensor node, it can be assumed that the sensor node does not know the current configuration. In order to avoid data collisions and serious disruption to data communication in the star network, the sensor node must not then transmit according to its configuration but must wait until the next configuration cycle or obtain the current configuration of the gateway.
The design of the CSN as a sequence number makes it possible for the value range to be exploited to the maximum for different configurations. Each new configuration cycle of the star network increases the CSN on the gateway by 1. In this way, certain chronological interrelations of the configurations can also be derived if needed.
This new information can be positioned very variably in terms of size and sequence in the beacon without the functionality being changed. A favored structure of the beacon in accordance with the invention is depicted in
The individual fields of the beacon in accordance with the invention shown in
The variant with an offset that corresponds to the total overhead of a packet (here 9) yields the greatest number of possible base timeslots, as well as the longest. In order to be able to decide more effectively on the length of the interframe spacing (12 or 40 symbols), the comparison should be executed somewhat differently: tss≦18-3, i.e. tss≦15.
The preferred variant is a calculation using the length of the MAC packet (middle variant), as this calculation can also be applied to different variants of the PHY layer and simplifies the calculation of the interframe spacing to be used.
The data structure in the sensor node for storing the configuration must be extended by two attributes: gateway ID and configuration sequence number (CSN). In addition, it is advantageous if the data structure is organized as a list or a field that can store k≧1 configurations (see
Rules for Using the Invention
When the gateway is initialized, a value for the gateway ID and the start value of the configuration sequence number (CSN) must also be defined.
In a star network as defined in document [1], there are three transmission modes which stand for various stages of configuration and operation (see
Discovery mode serves to “discover” all the sensor nodes in range of the gateway. The superframe consists only of beacon and the two management timeslots (downlink/uplink). It is therefore important that the inventive extension of the beacon for configuring the management timeslots is contained in the beacon so that the (new) sensor nodes can correctly compete for access to the transmission medium. In discovery mode, the configuration sequence number does not need to be contained in the beacon and/or does not need to be evaluated.
In configuration mode, the gateway transmits to all the sensor modes discovered in discovery mode the configuration valid for them. The superframe consists only of beacon and the two management timeslots (downlink/uplink). It is therefore important that the inventive extension of the beacon for configuring the management timeslots is contained in the beacon so that the (new) sensor nodes can correctly compete for access to the transmission medium. In this mode, the configuration sequence number must be contained in the beacon. It identifies the configuration of the star network which is currently being communicated to the sensor node. For each new configuration, the configuration sequence number has to be increased by 1. A new configuration is often found, but not necessarily when a switch is made to configuration mode. Since a change of the CSN means that all the sensor nodes have to receive a new configuration before they can take part in communication in the star network again, the CSN should be increased only when there is a quantitatively different configuration leading to conflicts with the existing configuration. If an available timeslot which, however, it is guaranteed, is not being used under the old configuration, is assigned in the new configuration to a sensor node, the CSN does not need to be increased as no conflicts in the data transmissions can occur.
In normal operating mode (online mode), a beacon as shown in
Upon receiving a beacon, the following algorithm is executed. Here “B_<field>” means the corresponding field from the beacon, and “SN_<field>_i” the corresponding attribute from the sensor node having the index i.
In order to shorten the processing time of a beacon, gateway ID and CSN from the beacon can first be compared with the corresponding attributes of the configuration last use (second algorithm). In this way, the entire list does not always have to be searched though. This can be implemented by a pointer to the relevant entry in the list of configurations or by a special data structure which contains the configuration last used and if required copies this in. The above algorithm then changes as follows:
The method of the invention principally comprises an extended beacon format, an extended data structure for storing the current configuration in the sensor node, and rules as to how the new information in the beacon frame should be used.
The transmission of the configuration of the management timeslots (length of the two management timeslots), which is determined from the two pieces of information transmitted, i.e., length of a base timeslot and number of base timeslots used per management timeslot, thus provides the sensor nodes with a range for which, after receiving the beacon, they know the configuration parameters and can therefore transmit control information arranged there. This is particularly important for new sensor nodes which have not yet been configured, for operating in discovery and in configuration mode and for sensor nodes which no longer have the current configuration and specifically want to request the current configuration for themselves from the gateway. The management timeslots with configuration transmitted in the beacon also support the use of HMI devices (HMI—human machine interface), such as portable panels, PDAs or notebooks which only occasionally have to be integrated in the star network for control and monitoring tasks.
Transmission of the gateway ID allows the unique assignment of a beacon to a gateway and thus to a star network. This makes it possible to distinguish different star networks. This enables the efficient and flexible roaming of sensor nodes.
Transmission of the configuration sequence number (CSN) for the current configuration makes it possible, together with the gateway ID, to recognize changes in the configuration of a star network even if the sensor node has not received all the beacons, i.e., may have missed a configuration cycle. This capacity to recognize an altered configuration supports roaming, as a sensor node is normally located for a longer period of time at other gateways. It also enables energy-saving by switching off the radio interface for a longer period. If a sensor node has no data to transmit, it can “go to sleep”. While it can wake up for each of the beacons and then receive these and then go to sleep again until the next beacon. Due to the CSN, however, it no longer needs to receive even this. By comparing the gateway ID and CSN, the sensor can determine whether it is still at the right gateway and whether it still has the current configuration. In this way, the sensor can determine whether it can send data without problems.
Despite the new additional information, the beacon in the preferred exemplary embodiment shown in
The extended data structure on the sensor node permits the storage of configurations for multiple gateways, an important prerequisite for roaming, as well as the newly introduced attributes of a configuration (gateway ID and CSN).
The rules for using the new information from the beacon enable the efficient support of roaming and energy-saving.
Other objects and features of the present invention will become apparent from the following detailed description considered in conjunction with the accompanying drawings. It is to be understood, however, that the drawings are designed solely for purposes of illustration and not as a definition of the limits of the invention, for which reference should be made to the appended claims. It should be further understood that the drawings are not necessarily drawn to scale and that, unless otherwise indicated, they are merely intended to conceptually illustrate the structures and procedures described herein.
Further features and advantages of the invention will emerge from an exemplary embodiment that will be explained below with the aid of the drawings, in which:
For the exemplary embodiment, the simplified wireless communication network shown in
The corresponding superframe configurations of the gateways and sensor nodes at the various times used in the exemplary embodiment are indicated in tabular form in
During the configuration at time t0, which is not examined in detail here, the sensor nodes receive the corresponding superframe configurations communicated to them. Determination of the current configuration is not yet necessary at this point in time t0, as it is only during operation that it is necessary to know the configuration currently being used.
The production automation network now goes into operation, and the sensor nodes are located at time t1 at the positions shown in
Sensor node S now moves on the conveyor belt through the radio ranges of the gateways A, B and C. At time t2, sensor node S switches from gateway C to gateway B. Sensor node S now receives the first beacon from gateway B. In accordance with the second algorithm, S compares the gateway ID (“B”) contained in the beacon with its current configuration (step 2). There is not a match, as the gateway IDs are not the same (B≠C). Therefore, the process continues with step 3 in which the list of configurations is gone through and it is checked whether there is a corresponding configuration for the values from the beacon. That is the case here (B=B and 155=155). Sensor node S now uses this configuration.
At time t3, sensor node S switches from gateway B to gateway A. Sensor node S now receives the first beacon from gateway A. In accordance with the second algorithm, S compares the gateway ID (“A”) contained in the beacon with its current configuration (step 2). There is not a match, as the gateway IDs are not the same (A≠B). Therefore, the process continues with step 3 in which the list of configurations is processed sequentially and it is checked whether there is a corresponding configuration for the values from the beacon. That is the case here (A=A and 216=216). Sensor node S now uses this configuration.
Sensor node S switches at time t4 from gateway A to gateway B, and at time t5 from gateway B to gateway C. At both times, the same algorithmic steps proceed as already described for times t2 and t3. The circuit of the sensor node S is now complete, and it continues by switching again from gateway C to gateway B as at time t2.
After a certain time of this normal operating mode, sensor P switches off its radio module for an extended period to save electricity. While sensor P is sleeping, a new sensor node N additionally comes into the network at time t6. It is in the radio range of gateway C, which now communicates to the sensor nodes in its range (including sensor node S) a new configuration with CSN=75 that contains the new sensor node N. Sensor node P “sleeps through” this new configuration.
At time t7, sensor node P switches its radio module on again and receives the first beacon from gateway C (see
The received gateway ID and configuration sequence number are compared with corresponding values of a current configuration of a respective sensor node, as indicted in step 1420.
If a sensor node establishes that a match has not occurred, configurations stored in the respective sensor node are then searched to ascertain whether there is an appropriate configuration for the gateway ID and the configuration sequence number and the appropriate configuration is used if there is an appropriate configuration for the gateway ID and the configuration sequence number, as indicated in step 1430.
Thus, while there have shown and described and pointed out fundamental novel features of the invention as applied to a preferred embodiment thereof, it will be understood that various omissions and substitutions and changes in the form and details of the devices illustrated, and in their operation, may be made by those skilled in the art without departing from the spirit of the invention. For example, it is expressly intended that all combinations of those elements and/or method steps which perform substantially the same function in substantially the same way to achieve the same results are within the scope of the invention. Moreover, it should be recognized that structures and/or elements and/or method steps shown and/or described in connection with any disclosed form or embodiment of the invention may be incorporated in any other disclosed or described or suggested form or embodiment as a general matter of design choice. It is the intention, therefore, to be limited only as indicated by the scope of the claims appended hereto.
Number | Date | Country | Kind |
---|---|---|---|
10-2009-020-206.4 | May 2009 | DE | national |
10-2009-048.303.9 | Oct 2009 | DE | national |
This is a U.S. national stage of application No. PCT/EP2010/056248 filed 7 May 2010. Priority is claimed on German Application No. 10 2009 020 206.4 filed 7 May 2009 and German Application No. 10 2009 048 303.9 filed 5 Oct. 2009, the contents of which are incorporated herein by reference in their entirety.
Filing Document | Filing Date | Country | Kind | 371c Date |
---|---|---|---|---|
PCT/EP10/56248 | 5/7/2010 | WO | 00 | 11/7/2011 |