METHOD AND CONTROLLER FOR CONTROLLING AT LEAST ONE LOAD

Embodiments of the present invention relate to a method and a device for controlling at least one load.

Home control (which may also be referred to as home automation) and industry control (which may also be referred to as industry automation) is becoming more and more popular. Home control may include control of lighting, heating, air conditioning, security systems, home entertainment, and the like. Industry control may include control of machines, control of access to certain areas in a facility, or the like. In each case, the control system includes a controller and at least one load (actor) coupled to the controller. The at least one load my include one of a light, a thermostat, an air condition, a door lock, a machine, or the like.

Different busses or communication protocols exist for the communication between the controller and the at least one load, such as 6LoWPAN (Ipv6 over Low Power WPAN (Wireless Personal Area Network)), Z-Wave, ZigBee, EnOcean, or KNX. 6LoWPAN, Z-Wave, ZigBee, and EnOcean are wireless communication protocols that use the ISM (Industrial Scientific Medical) and SRD (Short Range Devices) frequency bands. KNX may use a wired or a wireless network infrastructure in the ISM band.

The growing popularity of home and industry control systems may result in home control systems with a large number of loads. Especially in those cases where the loads are controlled using a wireless communication protocol this may cause interference problems. Further, loads that can be controlled using one of the protocols usually are not compatible with other protocols. Thus, it may become necessary to install two or more home control systems based on different technologies in one home, with each of these systems including one dedicated controller.

The problem underlying the present invention is to provide an improved method and an improved controller for controlling at least one load, in particular a load in a home control system.

This problem is solved by a method in accordance with claim 1, and by a controller in accordance with claim 12.

A method according to one embodiment includes, in a heterogeneous wireless capillary network which comprises a plurality of wireless capillary subnetworks, detecting by a controller a collision in a communication in one of the plurality subnetworks. The method further includes, upon detecting such collision, at least one of changing by the controller a mode of operation in a communication in another one of the plurality of subnetworks, changing by the controller a mode of operation in a communication in another communication network controlled by the controller that is unrelated to the wireless capillary network, and changing by the controller a mode of operation of a radio device configured to communicate with the controller outside the capillary network.

A controller according to one embodiment is configured to detect a collision in a communication in one of a plurality of capillary subnetworks forming a capillary network. The controller is further configured, upon detecting such collision, to at least one of change a mode of operation in a communication in another one of the plurality of subnetworks, change a mode of operation in a communication in another communication network controlled by the controller that is unrelated to the wireless capillary network, and change a mode of operation of a radio device configured to communicate with the controller outside the capillary network.

Examples are explained below with reference to the drawings. These drawings serve to illustrate certain principles, so that only aspects necessary for understanding these principles are illustrated. The drawings are not to scale. In the drawings the same reference characters denote like features.

FIG. 1 shows one embodiment of a conventional home control system;

FIG. 2 shows one embodiment of a home control system that includes a controller according to one embodiment;

FIG. 3 schematically illustrates how one controller may interact with several mobile devices (user equipment) and several loads (managed devices);

FIG. 4 shows one embodiment of the controller based on a layered model;

FIG. 5 illustrates one embodiment of the mapping layer;

FIG. 6 illustrates one embodiment of a message format used in the controller;

FIG. 7 shows a flowchart which illustrates one way of communication between one user equipment and one managed device through the controller;

FIG. 8 illustrates one embodiment of a communication between the controller and one load;

FIG. 9 illustrates different embodiments of collision management scenarios performed by the controller; and

FIG. 10 shows a flowchart which illustrates one way of operation of the controller for resolving a collision.

In order to ease understanding of embodiments of the invention, FIG. 1 schematically illustrates one embodiment of a conventional automation system. Just for the purpose of illustration, this automation system is a home automation system. Nevertheless, the method and the operation of the controller explained below is independent of the specific type of automation system, so that the method and the controller may be used in any other kind of automation system, such as an industry automation system as well.

Referring to FIG. 1, the system includes a plurality of loads 11-18, 21-22, 31-32 that can be remotely controlled via communication busses 10, 20, 30. These loads will also be referred to as managed devices in the following. Examples of these loads include radiators 11, 12, lights 13, 14, 21, 33, blinds 15, 16, a solar system 17, a central heating system 18, an entertainment system 22, a washing machine 31, or a laundry dryer 32. In the system shown in FIG. 1, there are three different communication busses, wherein each of the plurality of loads is coupled to one of these busses 10, 20, 30. Each of these busses 10, 20, 30 and the loads 11-18, 21-22, 31-32 coupled thereto are part of one control system, wherein each of these control systems includes an individual controller 1, 2, 3 coupled to the respective bus 10, 20, 30. Each of these controllers 1, 2, 3 allows a user to remotely control the loads coupled to the respective bus 10, 20, 30. More particularly, each of these controllers allows a user to remotely control an actor integrated in the respective load. For example, the actor is an electronic switch that switches on or off a light, an electronic valve that controls the flow of hot water through a radiator, an actor that operates an electric motor of a blind, etc.

The individual busses 10, 20, 30 may support a wireless communication protocol, such as 6LoWPAN (IPv6 over Low power Wireless Personal Area Network), Z-Wave, ZigBee, EnOcean, or WLAN (Wireless Local Area Network) e.g., Wi-Fi), or a wired communication protocol such as KNX. For example, a first communication bus 10 shown in FIG. 1 is a KNX bus, and a first controller 1 coupled to the first bus 10 is a KNX controller, a second bus 20 is a Z-wave or ZigBee bus, and a second controller 2 coupled to the second bus 20 is a Z-wave or ZigBee controller, and a third bus 30 is a Wi-Fi bus, and a third controller 3 coupled to the search bus 30 is a Wi-Fi controller.

The coexistence of several independent home control systems may cause different problems. First, each system requires its own controller, such as controllers 1, 2, 3 illustrated in FIG. 1. Second, interference problems may occur when there are two ore more wireless systems that use the same frequency bands, such as the ISM (Industrial Scientific Medical) and SRD (Short Range Devices) bands used by 6LoWPAN, Z-Wave, ZigBee, and EnOcean. Third, interference problems may occur between loads of one wireless control system and mobile devices, such as mobile phones, using neighboring frequency bands. For example, in Europe, the LTE (Long Term Evolution) band 20 is close to the SRD band that 6LoWPAN, Z-Wave, ZigBee, or EnOcean control systems use. Fourth, interference problems may occur between loads of one wireless control system such as, for example, 6LoWPAN, and loads of another wireless control system such as, for example, Z-Wave, using the same or adjacent frequency bands.

Thus, it is desirable to have one controller for loads supporting different types of communication protocols, such as 6LoWPAN, Z-Wave, ZigBee, EnOcean, Wi-Fi, KNX, or even CAN (Controller Area Network). The latter may be used in a car.

FIG. 2 schematically illustrates one embodiment of a control system that includes a plurality of loads 11-18, 21-22, 31-33 each coupled to one of three different busses 10, 20, 30, and one controller 4 configured to control the individual loads via the busses they are connected to. Like the automation system illustrated in FIG. 1, the automation system shown in FIG. 2 is a home automation system. However, this is only an example. The principles explained below are independent of the specific type of automation system and may be used in an industry automation system as well.

Referring to FIG. 2, the controller 4 is configured to communicate with a mobile computing device 5. The mobile computing device 5 (that will be briefly be referred to as mobile device in the following) may be implemented as a conventional mobile device, such as a mobile phone (smartphone), a tablet computer, a notebook computer, or the like. The mobile device 5 shown in FIG. 2 (as well as the mobile devices 5, 5₂, 5_Nshown in FIG. 3) in accordance with standardization, in particular 3GPP, will also be referred to as user equipment (UE) in the following. A communication channel between the controller 4 and the user equipment 5 is, for example, a wireless communication channel, such as a communication channel using a Wi-Fi communication protocol. The controller 4 may be mounted inside a building, such as a home, or a factory, and a user may remotely control the individual loads from the user equipment 5 via the wireless channel between the user equipment 5 and the controller 4, the controller 4, and the individual busses 10, 20, 30 between the controller 4 and the individual loads. In other words, the user equipment 5 may communicate with each of the loads through the controller 4.

The busses 10, 20, 30 are schematically illustrated by lines in FIG. 2. However, this does not imply that the individual busses include communication lines. Moreover, these busses 10, 20, 30 may be implemented as wireless busses. Referring to FIG. 3, the controller 4 is not restricted to manage communication between only one mobile device 5 (user equipment, UE) and the loads (managed devices, MD). Instead, the controller 4 can be configured to manage a communication between several mobile devices 5, 5₂, 5_nand the individual loads. Although FIG. 3 only shows three loads, the controller 4 is not restricted to control only three loads. According to one embodiment, the controller is configured to manage access rights such that the type of communication (inter-action) between one mobile device and the individual loads can be different for the individual loads. In particular, the controller 4 may grant different rights of interaction with the managed devices 11, 21, 31 to the individual mobile devices 5, 5₂, 5_n. Some examples of this are explained in the following.

According to one embodiment, the managed devices 11, 12, 31 are subdivided into different groups and the controller 4 is configured to assign the individual groups to the mobile devices 5, 5₂, 5_nso that each mobile device 5, 5₂, 5_ncan only interact with the managed devices of the assigned group(s). For example, the controller 4 may be configured to allow mobile device 5 only to communicate with managed device 11 (which forms a first group), to allow mobile device 5₂only to communicate with managed device 21 (which forms a second group), while it allows mobile device 5_nto communicate with each of the managed devices 11 (which form a third group).

“To grant different rights of interaction” may also include that in those cases in which different types of interaction are possible the controller is configured to assign each mobile device 5, 5₂, 5_nallowed types of interaction so that each mobile device can only interact with the individual managed devices based on the assigned types of interaction. For example, one or more of the mobile devices 5, 5₂, 5_nmay only have the right to receive status information from one managed device, while another one of the mobile devices may have the right to receive status information from the respective managed device and to control (by sending instructions) the respective managed device.

Referring to FIG. 3, the mobile devices 5, 5₂, 5_n, are not restricted to communicate with the controller. Instead, the mobile devices may additionally be coupled to a network which is referred to a public cloud 59 in FIG. 3. The public cloud 59 may include any type of conventional mobile communication network and resources, such as data bases, connected thereto. Examples of those conventional network include, but are not restricted to, networks supporting 2G, 3G, 4G, Wi-Fi, and LTE communication protocols.

According to one embodiment, the controller 4 is also configured to be coupled to the public cloud 59. From the public cloud 59 the controller may receive software updates, or software required to manage the managed devices 11, 21, 31. Additionally or alternatively the controller 4 may be coupled to a private cloud. The private cloud 58 may be linked to the controller through LAN or Wi-Fi and may be operated as private cloud within a local area network. Hence this private cloud provides a higher privacy and better security protection than the public cloud 59. The clouds 58, 59 may provide information about user, configuration, and device libraries, and they may act as persistent data storage, aggregation and processing entities. Furthermore, user scenarios may require support from backbone systems like complex pattern recognition and predictive maintenance.

The controller 4 can be implemented as a programmable device that includes at least one CPU (Central Processing Unit), a memory, and at least one communication interface. According to one embodiment, the controller has a basic architecture corresponding to an architecture (mobile architecture) of a mobile phone, or a tablet computer. However, the controller 4 may include communication interfaces that are usually not available on a mobile phone. That is, the controller 4 may support communication protocols that are usually not supported by a mobile phone. For example, a modern mobile phone supports 2G, 3G, and LTE communication protocols and Wi-Fi, but does not support communication protocols required to communicate with loads in a home or factory automation system, such as loads supporting 6LoWPAN, Z-Wave, ZigBee, EnOcean, or KNX protocols.

FIG. 4 illustrates one embodiment of the controller 4 based on an OSI (Open Source Interconnection) Model.

Referring to FIG. 4, the controller 4 includes a first communication interface (that may also be referred to as side A interface) for communication with the mobile device(s) 5, 5₂, 5_n, the private cloud 58, and the public cloud 59. The first interface may partially be implemented inside a processor hardware 47 and may be fully integrated. The first interface may also include one or more modems. Further, the first interface may include one or more antennas 48 which may contain transceiver and power amplifiers for a modem. The modem may contain, for example, a Wi-Fi interface and/or a 3GPP interface including LTE, 3G, 2G. The modem may further contain a MAC (Media Access Control), a base band (BB) processing unit, and a physical transmission unit. The physical transmission unit may be a discrete radio frequency (RF) transceiver and a dedicated power amplifier with the related antennas.

Referring to FIG. 4, the controller 4 further includes at least one second interface 42 (that may also be referred to as side B interface, or managed devices (MD) interface) for communication with the at least one load (managed device).

The second interface 42 in the controller 4 may contain a plurality of communication interfaces, with each of these communication interfaces supporting at least one radio transmission protocol and serving one capillary network technology. In the present context, a capillary network is considered any type of network which uses a short range wireless or wired access technology such as, for example, 6LoWPAN, ZigBee, Z-Wave, or EnOcean. In the present case, the controller 4 and the managed devices form a heterogeneous capillary network. This network may include a plurality of homogeneous capillary subnetworks, wherein each of the communication interfaces handles the communication between the controller 4 and the managed devices in one capillary subnetwork. The subnetworks can be different in the type of transmission protocols used for the communication within the individual subnetworks.

The at least one second interface is configured to send instructions from a system application 43 (Application Layer) running on the controller 4 to the at least one load (managed device), and to receive messages from the load and to forward the message to the system application 43. The system application communicates with the first interface 48 and the at least one second interface 42 through a mapping layer 44 and an application framework 45. The operating system 46, and a processor hardware (CPU) 47, support and complete the system.

The application framework 45 may be, for example, a Google™ Android™ framework.

The operating system (OS) may include a hardware abstraction layer (HAL), and an operating system kernel (which are not illustrated in FIG. 4). One example of the operating system of the controller 4 is Linux. The controller may further include a configuration library, a user library, and a device library. Elements of a user, device and/or configuration library may be implemented in a secure element. The secure element is shown as part of security 49 in FIG. 4.

Referring to FIG. 4, the controller further contains a user interface 41 which may be realized as HDMI and graphical controller interface to monitor the controller 4 and the entire system. In an embodiment herein, the user interface 41 includes other external audio and/or video interfaces that allow connection of external screen or loudspeaker to provide status information on the controller 4, or touch screen (not shown) to interact with the controller 4, and possible USB and SD Card interfaces to facilitate physical data transfer to and from the controller 4.

Referring to FIG. 4, optionally, the controller 4 may include a secure element and NFC (Near Field Communication) interfaces that may be used to communicate with the at least one mobile device 5, 5₂, 5_n, and can be utilized to communicate with managed devices. This is explained in further detail herein below.

Besides the system application 43 and the mapping layer 44 which provide for the communication between the at least one mobile device 5, 5₂, 5_nand the at least one managed device 11, 21, 31, other applications may run on the controller 4. Other applications that may run are standard applications, such as calendars.

According to one embodiment, the controller 4 communicates with the at least one managed device via the second interface 42, in particular via the communication interfaces in the second interface 42, in accordance with one of the currently known home or industry automation protocols, such as 6LoWPAN, Z-Wave, ZigBee, KNX, in particular KNX-RF, or EnOcean. 6LoWPAN, Z-Wave, ZigBee, and EnOcean are wireless communication protocols, while KNX may include a wired or a wireless communication protocol.

The loads communicate with the controller 4 through their respective radio interfaces. Referring to the above, the controller 4 and the loads form a so-called heterogeneous capillary network, wherein those loads which are connected to one communication interface of the second interface and the controller 4 form a capillary subnetwork. In this capillary network the controller 4 and the loads communicate using short-range radio technologies. Examples of those short-range radio technologies include, for example, Wi-Fi and the radio technologies underlying 6LoWPAN, Z-Wave, ZigBee, or EnOcean.

The at least one mobile device 5, 5₂, 5_ncommunicates with the controller 4 through the first communication interface 48. For communicating with the mobile device the controller 4 may use the same radio technologies used for communicating with the at least one load, such as Wi-Fi. According to one embodiment, one of the capillary subnetworks uses the same radio technology, such as Wi-Fi. According to another embodiment, for communicating with the user equipment 5, 5₂, 5_N, the controller uses a radio technology different from the radio technologies used by the individual capillary sub-networks.

The controller 4 may have a user interface 41, but not necessarily needs a user interface, because interaction between the controller 4 and a user is also per-formed through the mobile device 5 that includes a conventional user interface, such as a touch screen, or a speech input. The system application 43 running on the controller 4 can be installed (and updated) via the mobile device 5 through the communication channel between the mobile device 5 and the controller 4.

According to one embodiment, the controller 4 is configured to register the mobile device 5, and to accept commands from the mobile device 5 only after the mobile device 5 has been registered. A command transmitted from the mobile device 5 to the controller 4 is, for example, a command to control one of the loads (managed devices) coupled to the controller 4 through the second interface 42.

Referring to the above, the controller 4 may include an NFC (Near Field Communication) interface, and a secure element. In this case, registering the mobile device 5 with the controller may include a pairing of the controller 4 and the mobile device 5 using a NFC interface as part of the security 49 in FIG. 4 in the controller and a corresponding NFC interface (not shown) in the mobile device 5. For this, the mobile device 5 is to be brought in close proximity to the controller 4 so that a communication between the controller 4 and the mobile device 5 through the NFC interface can be started. Pairing of the controller 4 and the mobile device 5 may include security mechanisms, like mutual authentication and asymmetric key exchanges. After such pairing has been completed, the mobile device 5 is registered in the controller 4, so that the controller 4 will then accept a communication with the mobile device 5 through the first communication interface 48. Instead of NFC, also other technologies for device pairing can be used that provide a short distance communication.

Via the first communication interface 48 the controller 4 may receive the application to be installed on the controller 4, and, after the application has been installed, commands for controlling individual loads (managed devices) coupled to the controller. In this connection it should be noted that “a load coupled to the controller 4” is a load that is configured to be addressed (controlled) by the controller 4 through the second interface. If one of the communication interfaces within the second interface is an interface for a wired connection, such as a KNX interface, the load may physically be coupled to the interface through a wired communication bus. However, in case the interface is a wireless interface the load is coupled to the interface “over the air”. In the following, for the purpose of explanation it is assumed that the individual loads 11, 21, 31 are coupled to the controller 4 over the air.

Each of the loads 11, 21, 31 includes a radio device which acts as a radio interface and provides the wireless communication between the controller 4 and the respective load. The data transmitted between the controller 4 and the load through the radio interface is dependent on the specific type of load. For example, if the load is an electric light the data transmitted from the controller 4 to the load may include switching instructions that switch on or off the light, and the date transmitted from the load to the controller 4 may include status information. Those status information may include, e.g., light on, light off, or light defect. Of course, the information transmitted between the controller and the load are more complex when the load is a complex electronic device or system, such as, for example, a robot in an industry automation system.

In the communication between the controller 4 and the loads 11, 21, 31 collisions may occur. These collisions may have several reasons. First, referring to the explanation above, known wireless communication protocols for home or industry automation applications use the same or overlapping frequency bands so that interference problems may occur in a conventional system (capillary networks). Second, the frequency band (e.g., ISM or SRD bands) of these wireless communication protocols may be adjacent to frequency bands of other wireless communication systems. For example, the SRD 868 MHz band used in Europe is adjacent the LTE band 20 that may be used by user equipment (capillary networks, cellular, and LAN networks). Third, interference or overlaps between Wireless LAN (e.g., Wi-Fi), Personal Area Networks (e.g., Bluetooth), and capillary networks (e.g., 6LoWPAN, ZigBee) do exist in the 2.45 GHz band (capillary networks and Wi-Fi).

According to one embodiment, the controller 4 is configured to perform a collision management that prevents an interference of the loads 11, 21, 31 controlled by the controller 4, and that prevents or at least reduces an interference between those loads 11, 21, 31 and the mobile device 5. The aforementioned first, second and third cases describe heterogeneous interference scenarios. This is explained below.

According to one embodiment, the collision management is performed in the mapping layer 44 of the controller 4. In another embodiment, collision management involves other elements of the system. In some cases, collision management may interact with system applications 43, the second interface 42, and security 49.

Referring to FIG. 5, the mapping layer may include an interpreter 441. The interpreter 441 is configured to map (translate, interpret) a message format of messages received from the at least one mobile device 5, 5₂, 5_nto a message format that can be interpreted (understood) by the at least one managed device 11, 21, 31. Referring to the explanation above, different types of managed devices which may use different types of radio technologies can be coupled to the controller 4, wherein each of these different radio technologies uses different message formats. The interpreter inside the controller 4 also maps a message format of a message received from the at least one load to a message format that can be understood by the at least one mobile device. The interpreter 441 may interact with the system application 43.

The mapping layer 44 further includes a router 442 which is configured to correctly route messages from the at least one mobile device to the at least one load, and vice versa. That is, the mapping layer 44 acts as a switch that is configured to route messages between one or more user equipment(s) coupled to the first interface 48 and one or more managed device(s) coupled to the second interface 42.

In addition, the mapping layer 44 includes a collision manager 443. The collision manager 443 is configured to control all communication coordinated by the controller 4, between the at least one user equipment 5, 5₂, 5_n, at least one load 11, 21, 31, and the private cloud 58 and public clouds 59, such that collisions are avoided and, if a collision has occurred and is detected, that the collision is resolved. This is explained in greater detail herein below.

Before going into detail on the functionality of the collision manager 443, the functionality of the interpreter is briefly explained with reference to FIG. 6 which illustrates a message format that may be used by the controller 4 and/or the mobile device(s) 5, 5₂, 5_nto provide messages to the managed devices 11, 21, 31. Referring to the above, those messages may include instructions (commands) and/or data. In the embodiment shown in FIG. 6, the messages include an LWM2M (Light Weight M2M (Machine To Machine)) message format on top of a CoAP (Constrained Application Protocol) message format. This message format will be referred to as CoAP/LWM2M message format in the following. Of course, any appropriate message format may be used, provided it is consistent with the functionality described herein.

Referring to FIG. 6, the CoAP/LWM2M message format includes a header with a version field VER, indicating the version of the format used in the message. A receiving device may need to know the format version of a received message in order to be able to properly parse the message. The header may also include a type field TYPE, indicating to the receiver the type of data being sent (e.g., command, inquiry, acknowledgement, etc.), and may include a token length field TKL indicating the length of an optional token. In some cases, it may be advantageous to include tokens with messages as additional markers. For example, in a communication in which one device, such as one mobile device 5, 5₂, 5_n, sends a message including a request (request message) to another device, such as one of the managed devices 11, 21, 31, the requesting device may include a specific token in the request message and the responding device may include the same token in the message including the response (response message) to ensure greater integrity. In instances where a token is not used, the token length TKL may be set to zero.

The CoAP/LWM2M message header may also include a code field CODE indicating a type (content) of the message and, therefore, indicating how the receiver may process the message. Furthermore, a message identification field MSG ID may be included in the header. The content of this field may be used for cryptography purposes.

Following the header, the message includes the token if there is any, that is, if the token length field TKL is not zero. Additionally, the message includes LWM2M options and the payload. The options may include information which instruct the receiver how to handle the data included in the payload. For example, if the receiver can have different operation modes, the data included in the options field may set the mode of operation of the receiver, while the data included in the payload field may include commands/instructions the receiver processes in the respective mode of operation.

The CoAP/LWM2M message can be cryptographically protected for security reasons (e.g., for confidentiality, integrity, and authenticity protection, etc.). For that, the CoAP/LWM2M message can be encrypted in parts or in its entirety (e.g., by encrypting the complete message using a symmetric block cipher such as the Advanced Encryption Standard (AES), etc.). Apart from the encryption, optional descriptive security headers and footers can be added to the encrypted message. According to one embodiment, a datagram transport layer security DTLS can be used for cryptographic protection of the CoAP/LWM2M message.

Referring to the above, the mapping layer 44 may receive the CoAP/LWM2M format message from the at least one mobile device 5, 5₂, 5_n, converts the message to a format understood by the one of the managed devices 11, 21, 31 that is to receive the message, and routes the message to the managed device. In the other direction, the mapping layer receives a message from one of the managed devices, converts the message to the CoAP/LWM2M message format, and routes the message to the mobile device that is to receive the message. The “format understood” by the managed device is a format which is in accordance with the radio technology used by the managed device such as, for example, 6LoWPAN, ZigBee, Z-Wave, EnOcean, or Wi-Fi.

According to another embodiment, the mapping layer 44 does not convert the messages to and from the managed devices itself but triggers the message conversion to be performed in the second interface 42 (see FIG. 4).

According to another embodiment, the messages contain an additional custom header and/or footer. Without restricting the generality of the foregoing, the custom header can contain complementary address, status, error and processing information (e.g., internal source and/or destination reference addresses, message prioritization flags, content descriptors, internal processing directives, etc.). Such additional information may then be used in the mapping layer 44, the second interface (managed device communication modules) 42, in embedded software running in dedicated hardware components for managed device communication modules, as well as in other components and layers where the processing of the messages with the custom header and/or footer may be of interest.

FIG. 7 shows a flow diagram 150 which illustrates one embodiment of a process performed by the mapping layer 44 in connection with providing a message to one of the managed devices 11, 21, 31. Referring to FIG. 7, processing begins at a first step 152 where the mapping layer 44 receives a message to be forwarded to one of the managed devices 11, 21, 31. Referring to the above, this message may be a message received from one of the mobile devices 5, 5₂, 5_n. However, this is only an example. According to another embodiment, the message is a message which is internally generated in the controller 4 and, more specifically, in the mapping layer 44 upon request of a system application 43. Those messages internally generated in the controller 4 may be used to regularly poll the managed devices 11, 21, 31 in order to find out their status of operation.

Following the receiving step 152 is a test step 154 where it is determined if the destination network is active, that is, if a communication with the desired managed device is possible. Referring to the above, the capillary network including the managed devices may include several capillary subnetworks with each of these subnetworks employing one radio technology such as, e.g., 6LoWPAN, ZigBee, Z-Wave, EnOcean, or Wi-Fi. The destination network may be one of these subnetworks. According to one embodiment, each subnetwork registers with the controller 4 during initialization. If it is determined at the test step 154 that the destination network is not active, then control transfers from the test step 154 to an error processing step 156 where error processing is performed.

This error processing may include any appropriate error handling mechanism such as, for example, returning a message indicating the error to the mobile device from which the message was received in step 152.

If it is determined in step 154 that the destination network is active, then control transfers from step 154 to a transmission check step 158 where it is determined if the transmission is allowed. In some embodiments, there may be restrictions for messages, including security restrictions based on the source and destination of the messages. For example, a certain one of the mobile devices 5, 5₂, 5_nmay not be allowed to send a message of a certain type to a certain one of the managed devices 11, 21, 31. If it is determined at the test step 158 that the transmission is not allowed, then control transfers from the step 158 to the step 156, discussed above, where error processing is performed. In some embodiments, the specific error processing performed at the step 156 may depend upon the type of error so that, for example, the processing performed at the step 156 when the network is not active registered is different from the processing performed at the step 156 when transmission is not allowed. After the error processing step 156, the process 150 terminates.

If it is determined at step 158 that transmission is allowed, then control transfers from step 158 to a step 162 where it is determined if conversion is needed. There may be cases in which the native format of the message received at step 152 has the same format used by the destination managed device. For example, the message received at step 152 may have the CoAP/LWM2M format and the managed device which is to receive the message may also use this format. In this case, conversion may not be necessary. However, if, for example, the message has the CoAP/LWM2M format and the managed device which is to receive the message uses, for example, the ZigBee network protocol, then conversion of the message from the CoAP/LWM2M format to the ZigBee format may be necessary.

If it is determined at the step 162 that conversion is needed, then control transfers from the test step 162 to step 164 where the conversion is performed. Following step 164, or following step 162 if conversion is not needed, the message, in step 166, is sent to the receiving managed device via the destination network that includes the managed device. Following step 166, processing is complete.

Before going into further detail on the collision management performed by the mapping layer 44, one way of how a mobile device may communicate with one of the loads (managed devices) through the controller 4 is illustrated in FIG. 8. FIG. 8 schematically illustrates a signal communication between the controller 4, the mobile device 5 and one load. Referring to the above, the controller 4 may control a plurality of loads. However, for the purpose of explanation only one of these loads is schematically illustrated in FIG. 8. Further, although there may be several mobile devices (user equipment), only one of these mobile devices is shown in FIG. 8.

According to one embodiment, the controller 4 is configured to transmit a message through the second interface 42 to the load and waits for the load to acknowledge the message. The message may be a conventional message in a format understood by the load and controls the load. Examples of this message include a command to switch on/switch off when the load is a light, a command to open/close when the load is a blind, a command to increase/decrease the temperature when the load is a radiator, or even more complex commands when the load is a more complex system, such as a central heating system, a solar system, or a home entertainment system in a home automation system, a robot, an assembly line, or a door control system in an industry automation system to mention only some examples of more complex loads. Referring to the above, the message sent from the controller 4 to the load can be initiated by the mobile device 5 (as shown in FIG. 8), or can be initiated by the controller itself (as explained above). In the first case, a user may use an application running on the mobile device 5 to identify the load that is to be controlled, and to select a certain functionality the load is to perform. The mobile device 5 transmits the corresponding information to the controller via the first interface 48, and the controller 4 controls the load selected by the user through the second interface 42.

According to one embodiment, the controller 4 schedules the messages to be transmitted to the individual loads. That is, in order to avoid interferences, the controller waits to start a communication with a load until a communication with a load addressed before has been terminated.

Referring to FIG. 8, the controller 4 may be configured to re-transmit a message to the load when the load has not acknowledged the message sent before. In the embodiment shown in FIG. 8, the load acknowledges the message after the message has been retransmitted. In this case, the controller 4 may start a new communication with the same load (to transmit a new command, for example) or with another one of the loads coupled to the controller 4. However, there may be scenarios in which the controller 4 needs to re-transmit the message more than once before the load acknowledges the message. In those cases, a time limit may be set, so that the controller 4 stops re-transmitting the message when a predefined time period has lapsed without the load having acknowledged the message. Additionally or alternatively, the number of re-transmissions may be limited to a predefined number. There may even be scenarios in which the communication fails, that is, in which the load does not acknowledge the message after the predefined number of re-transmissions (re-tries).

In particular in those cases, in which the controller 4 uses a wireless communication protocol, the reason for the controller 4 not to receive an acknowledge from the load may be interference problems with other devices (not shown in FIG. 8) using the same frequency band as the wireless communication protocol used by the controller 4 to communicate with the load. The device interfering with a communication between the controller 4 and the load may be the mobile device 5 the controller 4 communicates with, or other loads coupled to the controller. For example, the controller 4 may use the SRD (Short Range Device) band to communicate with several loads, and the mobile device 5 may use the neighboring LTE 20 band.

In order to be able to resolve collisions, the controller 4 is configured to detect collisions (interferences). This may include the verification of message integrity and authentication codes. This may also include a measurement of the quality of transmission between the controller 4 and one load. In particular, the controller may measure the signal quality of signals received from the at least one load. For example, a collision is detected when the signal quality is below a predefined threshold (which is equivalent to the bit error rate being above a predefined threshold). According to one embodiment, collision detection, like the resolution of collisions is performed by the mapping layer 44 (see FIG. 5).

According to another embodiment, re-transmissions that are required in order to receive an acknowledge from a load are statistically evaluated. In this case, a collision may be detected when an average number of retransmissions reaches (or is a above) a predefined threshold.

Optionally, the detection of a collision also involves an analysis in the mobile device 5. In this embodiment, the controller 4 triggers the mobile device 5 to analyze the most recent communication transfers by the mobile device 5. “Most recent communication transfers” in this connection may include communication transfers within several seconds up to several minutes before the mobile device 5 was triggered by the controller 4 to analyze the communication transfers. The analysis of the communication transfers may include analyzing bit error rates and/or quality levels of the communication transfers. The mobile device 5 then returns the results of the analysis to the controller 4. Besides the information on the quality of the most recent communication transfers, those results may include information on the communication protocols used in connection with the most recent communication transfers, such as Wi-Fi, LTE, 3G, 2G, Bluetooth, or the like.

According to one embodiment, before the controller 4 triggers the mobile device 5 to perform the analysis explained before, the controller 4 is configured to interrupt communication with those loads that use communication channels (communication protocols) that may interfere with the communication between the controller 4 and the mobile device 5. For example, when the first interface 48 uses a Wi-Fi protocol for communication with the mobile device 5, all wireless communication between the controller 4 and the loads are interrupted that may interfere with the communication between the controller 4 and the mobile devices 5. This is to make sure that the mobile device 5 safely receives the command that triggers the mobile device 5 to perform the analysis.

Based on the collision detection performed by the controller 4, and optionally based on the analysis performed by the mobile device 5, the controller 4 is configured to resolve possible collisions. According to one embodiment, the controller 4 is configured to re-route a message to a load after a collision has been detected. Re-routing the message may include transmitting the message to a desired load, such as the load illustrated in FIG. 8, via another load (not shown in FIG. 8). If, for example, the load is located more spaced apart from the controller 4 than the other load, then transmitting the message to the other load, and transmitting the message from the other load to the load may increase the signal quality and may therefore make the communication between the controller 4 and the second load more robust. That is, messages from the load, such as acknowledgements, are transmitted to the controller 4 via the other load when the controller 4 has initiated a re-routing of messages in order to avoid collision.

According to one embodiment, the controller 4 includes a configuration library that includes information on how the system with the controller 4 and the network with the loads is configured. In particular, the configuration library may include information on how the individual loads are spatially and logically arranged in the system. Additionally, the controller 4 may include a device library that includes specific information on the individual loads used in the system. For example, the device library may include information on whether a specific load has a functionality to act as a relay that can receive messages from the controller 4 and forward these messages to another load, such as the load shown in FIG. 8. According to one embodiment, the configuration library and the device library are integrated in the controller 4. Alternatively, the configuration library and the device library are located in an external storage device, such as in one of the clouds 58, 59, the controller 4 has access to.

In the collision resolution explained before, the controller maintains the same radio technology such as, e.g., one of 6LoWPAN, ZigBee, Z-Wave, or EnOcean, to communicate with the load and tries to avoid/resolve collision by suitably scheduling the communication, re-transmitting the message, re-routing the message, or the like. This type of collision resolution will be referred to as homogeneous collision management (homogeneous collision resolution) in the following.

According to one embodiment, the controller 4 is not only configured to manage (detect and resolve) collisions by taking actions in the same radio technology, but is configured to manage (detect and resolve) collisions occurring in the communication with one load that communicates with the controller in one radio technology by taking actions in the communication with another load that communicates with the controller in another radio technology or through another interface (of the same or different radio technology). According to another embodiment, the controller 4 is also configured to manage (detect and resolve) collisions occurring in the communication with one load that communicates with the controller in one radio technology by taking actions in communication interfaces on the controller or on external entities connected to the controller that do or do not communicate with loads but may also perform other non-specific communication tasks, such as network management functionality or other data transmissions not related to the loads. Such collision management will be referred to as heterogeneous collision management in the following.

An overview of the different types of collision management that may be performed by the mapping layer 44 is shown in FIG. 9. Referring to FIG. 9, the collision management may include a homogeneous collision management 451 (homogeneous resolution). Here, “INTRA-IF” means that for resolving a collision occurring in one radio technology means are taken in the same radio technology (the same radio interface (IF)). In other words, if a collision is detected in one of the capillary subnetworks, the controller 4 takes means to resolve the collision in the same capillary subnetwork.

The heterogeneous management 452 (heterogeneous resolution) may include two different types of collision management, the inter-interface (INTER-IF 453) and extra-interface (EXTRA-IF 454) collision management.

The INTER-IF 453 contains methods to resolve collisions by analyzing two or more communication interfaces on the controller and changing the communication interface configurations of at least one of these interface on the controller 4. The analyzed two or more communication interfaces may include the first interface and the second interface, but may also include communication interfaces in the second communication interface. That is, upon detection of a collision in one of the subnetworks controlled by the second interface, the mode of operation in the networks controlled by the first interface or in at least one of the other subnetworks may be changed. In other words, INTER-IF 453 may include changing by the controller a mode of operation in a communication in another one of the plurality of subnetworks, or changing by the controller a mode of operation in a communication in another communication network on the controller (or controller by the controller) that is unrelated to the wireless capillary network.

The EXTRA-IF 454 contains methods to resolve collisions by analyzing and/or changing at least one interface that is external to the controller 4. That is, an interface which may communicate with the controller through a network outside the capillary network controlled by the second interface. For example, EXTRA-IF 454 may include changing the mode of operation of the mobile device 5, or of another radio device connected to the controller 4. An example of such other radio devices includes a Wi-Fi access point that the controller may use to access one of the clouds. “Changing the mode of operation” may include changing the Wi-Fi configuration of the mobile device or the other radio device when the controller 4 and the mobile device use Wi-Fi to communicate with each other.

Re-routing of messages may be suitable in order to avoid or reduce collisions if the collisions do not result from the mobile device 5, or when analysis data from the mobile device 5 are not available. In case the analysis data show that the collision detected by the controller 4 result from the mobile device 5, the controller 4 may be configured to cause the mobile device 5 (user equipment) to change its mode of radio operation in order to avoid or resolve those collisions. This mode of radio operation may be the mode of radio operation the mobile device 5 (user equipment) uses in the communication with the controller 4, but may also be the mode of operation the mobile device uses in a communication different from the communication with the controller 4 such as, for example, in a communication with another radio device and/or with a cloud. Those changes in the operation are part of EXTRA-IF 454 collision management and may include, but are not restricted to:

a) A technology migration. That is, the controller 4 may cause the mobile device 5 to use another communication protocol and/or technology. Examples of different communication protocols that may be used for communication between the mobile device 5 and the controller 4 are Wi-Fi, LTE, HSPA (3G), and GSM (2G). According to one embodiment, the type of communication between the mobile device 5 and the controller 4 is chosen based on a priority list. That is, each of these different protocols is given a unique order number that indicates its priority. Communication between the mobile device 5 and the controller 4 begins with the protocol that, based on the order number, has the highest priority. In case communication between the controller 4 and the at least one load fails, communication between the controller 4 and the mobile device may switch to a communication protocol with a lower priority. If the communication between the controller 4 and the at least one load again fails the communication between the controller 4 and the mobile device may switch to the communication protocol with the next lower priority, and so on.

b) A change of the used frequency band. If, for example, the mobile device 5 is currently using an LTE band that possibly interferes with the frequency bands used by the controller 4 to communicate with the loads, the controller 4 may cause the mobile device 5 to change to another LTE frequency band. Similarly, if the mobile device 5 is using Wi-Fi to communicate with the controller 4 or an another device and communication between the controller 4 and the at least one load fails the controller 4 may cause the mobile device 5 to switch to a different frequency band within the Wi-Fi frequency spectrum.

c) A change of the transmission parameters of the mobile device. That is, the controller 4 may cause the mobile device 5 to reduce transmission rates, to use single carrier transmission instead of multicarrier transmission, or the like.

d) Further, the controller 4 may cause the mobile device 5 to report transmission gaps to the controller 4. The controller 4 may then use those transmission gaps to communicate with the loads coupled to the controller 4.

Modern mobile frameworks (such as Android™) on mobile devices enable an application running on the mobile device to change the operation mode of the mobile device in at least one of the ways a)-d) explained above. That is, the application running on the mobile device 5 that can be used by a user to control the individual loads via the controller 4, may also be used by the controller 4 to change the operation of the mobile device in case a collision caused by the mobile device 5 has been detected.

The controller 4 can be configured to re-send the message to a desired load after the mobile device has changed its mode of operation. The mobile device 5 may send a confirmation message confirming a change of the mode of operation to the controller 4, which then may re-send the message to the load.

In a typical industry or home environment, the controller 4 may far more often perform INTER-IF collision management. Typical cases for INTER-IF collision management may include but are not limited to:

aa) A technology migration. That is, the controller 4 may internally switch from one communication protocol and/or technology to another communication protocol and/or technology. Examples of different communication protocols that may be used for communication controller 4 and the loads 11, 21, 31 are Wi-Fi, ZigBee, Z-Wave, 6LoWPAN and EnOcean. For instance, if a load supports multiple communication technologies and if a collision in the communication with this load has been detected, the controller 4 may switch to another technology supported by the load to avoid or resolve collisions.

bb) A change of the used frequency band and/or channels. According to one embodiment, the type of communication between the controller 4 and the loads 11, 21, 31 is modified through altering transmit parameters of the capillary networks such as utilized bands and channels if supported by the managed device. Similarly, if the controller 4 is using Wi-Fi to communicate with another device and communication between the controller 4 and the at least one load fails the controller 4 may switch to a different frequency band within the Wi-Fi frequency spectrum.

cc) A change of the transmission parameters of the controller and the loads where the controller reduces the bandwidth and the utilized channels and creates guard-bands within given frequency bands to allow coexistence of two technologies in one given band. For example, ZigBee, 6LoWPAN and Wi-Fi may use the same frequency band, the 2.45 GHz ISM band. For the purpose of explanation it is assumed that a first subnetwork uses one of these technologies and a second subnetwork uses another one of these technologies. If, for example the communication between the controller and one load in the first subnetwork fails, the controller may reduce the bandwidth of the frequency band used for communication in the second subnetwork in order to create a guard-band. In this connection, also the bandwidth in the first subnetwork may be reduced. The bandwidth reduction in this case can be achieved by deliberately restricting communication to disjunct subsets of channels while excluding certain channels in the communication to serve as guard bands.

dd) Further, the controller 4 may coordinate its internal interfaces (in the first interface 48 and the second interface 42) to establish transmission gaps. If, for example, communication between the controller 4 and one load in a specific subnetwork fails (i.e., a collision occurred), the controller 4 may create transmission gaps in its other interfaces. The controller 4 may then use those transmission gaps to communicate with the load in the subnetwork where the collision occurred.

ee) The controller may utilize LTE or other 3GPP communication to the public cloud 59 to communicate instead of using a connection via a local Wi-Fi gateway.

ff) The controller may re-schedule and/or change the priority of the transmission of messages to the individual loads. This may include that the controller 4 detects time gaps in which a probability of collisions is reduced, and transmits messages to the loads in those time gaps.

gg) The controller 4 may repeatedly transmit a dummy message to one load and may analyze the signal quality of the communication with this load in order to detect those time gaps in which a communication is possible.

According to another embodiment, the controller 4 is configured to use redundancy technologies and/or error correction methods in the communication with the individual loads. Those redundancy technologies and/or error correction methods increase the robustness of the communication with the individual loads. Conventional channel coding methods such as the use of a parity bit, cyclic redundancy checks, to mention only some, are used in order to increase the robustness of the communication and are already commonly used for such purposes. The heterogeneous methods add additional techniques and methods to manage collisions in heterogeneous environments where the conventional methods fail or produce suboptimal results.

Referring to FIG. 9, collision management 443 may further include the detection and mitigation of intrusion and attack attempts (e.g., denial of service attacks) of loads which are either not authorized or malfunctioning. For example, a not authorized or malfunctioning load may generate communications which cause such a significant workload in the controller 4 that the functionality of the overall system is at risk. Such attacks may cause big harm to the entire system.

For instance, those loads with limited security can be monitored through heuristics that take into account the ratios between transmit (TX) and receive (RX) messages, TX and retransmit messages (RTX), and the load history profiles to identify suspicious variations.

Referring to the above, the mapping layer 44 may be configured to perform different types of collision management (collision detection and resolution). According to one embodiment, the mapping layer may change the type of collision management based on whether one type of collision management was successful or not. This is explained with reference to FIG. 10.

Referring to FIG. 10, the mapping layer is configured to detect (measure) if a collision in the communication with one of the loads has occurred. For this, one of the collision detection methods explained above may be performed. If a collision has been detected, the mapping layer 44 may take one of the homogeneous or heterogeneous resolution scenarios in order to successfully communicate with the load. If the selected scenario resolves the collision the collision management for the present communication ends. If not and if a maximum number MAX_TRIES of tries to communicate with the load has not been reached, the mapping layer changes to another resolution scenario, and again measures if a collision has occurred. This proceeds until the collision has been resolved or until the maximum number of tries has been reached.

It should be noted, that the controller 4 explained herein before is not restricted to be used in connection with a home control (home automation) system. Instead, this controller may also be used in industrial environments, or even in cars. A controller 4 used in a car may include an interface for communication with loads coupled to a CAN (Controller Area Network) bus.

Referring to the explanation above, the controller 4 may be programmed using a mobile device 5. That is, a computer program (software code) may be installed on the controller by the mobile device. The mobile device 5 may have a conventional mobile device architecture and a conventional operating system, such as Android (by Google™) or iOS (by Apple™). In this case, the mobile device 5 may receive the application to be used on the mobile device 5 and on the controller 4 in a conventional way, from an application store, such as Google Play. Thus, an existing ecosystem can be used for obtaining the application that runs on the controller.

Summarizing the above, A controller according to one embodiment includes a wireless first communication interface (ANTENNA 48, FIG. 4), and at least one second communication interface (MD COMM. 42, FIG. 4). The controller 4 is configured to communicate with at least one mobile device through the first interface, and to communicate with at least one load through the at least one second interface, and wherein the controller is able to detect and resolve collisions in the communications. Such collisions are heterogeneous collisions if they occur between different communication interfaces and/or standards. Collisions are homogeneous if they occur within a specific communication interface. Collisions may occur between loads controlled through the controller, and between loads controlled through the controller and external entities. Collisions may include communication interference scenarios, including interference caused by adjacent or overlapping frequency bands. Collisions further may include attack patterns where loads are simulated and collisions arbitrarily caused or provoked.

A method according to one embodiment includes communicating by a controller with a mobile device through a first interface, and with at least one load through at least one second interface, and detecting by the controller a collision in the communication between the at least one load and the controller.

The methods disclosed herein for heterogeneous collision management are different from conventional cellular in-band solutions, which in the method (system) disclosed herein are part of homogeneous collision management.

METHOD AND CONTROLLER FOR CONTROLLING AT LEAST ONE LOAD

Information

Publication Number

Date Filed

Date Published

Inventors

CPC

International Classifications

Abstract

Description

Claims

Priority Claims (1)

PCT Information