WO2013030765A2 - Control unit and method for managing multicast groups in a wireless network - Google Patents

Abstract

For providing a convenient and intuitive user interface for managing multicast groups in a wireless network with a plurality of nodes (10), thus improving the user convenience and speed in managing large-scale wireless networks, a control unit and a method are provided, wherein one or more network elements of at least one predefined network layer (L1, L2) selected by a user are displayed and at least one network element of the displayed network layer (L1, L2) is assigned to or removed from a multicast group based on a user input, wherein a network element is a node (10) and/or a group of nodes (10).

Description

CONTROL UNIT AND METHOD FOR MANAGING MULTICAST GROUPS IN A WIRELESS NETWORK

FIELD OF THE INVENTION

The invention relates to a control unit and a method for managing multicast groups in a wireless network. BACKGROUND OF THE INVENTION

Recently, wireless mesh networks attract more and more attention, e.g. for remote control of illumination systems, building automation, monitoring applications, sensor systems and medical applications. In particular, a remote management of outdoor luminaires, so-called telemanagement, becomes increasingly important. On the one hand, this is driven by environmental concerns, since telemanagement systems enable the use of different dimming patterns, for instance as a function of time, weather conditions and season, allowing a more energy-efficient use of the outdoor lighting system. On the other hand, this is also driven by economical reasons, since the increased energy efficiency also reduces operational costs. Moreover, the system can remotely monitor power usage and detect lamp failures, which allows for determining the best time for repairing luminaires or replacing lamps.

Current radio-frequency (RF) based wireless solutions use either a star network topology or a mesh network topology. In a star network, a control center has a direct wireless communication path to every node in the network. However, this typically requires a high-power/high-sensitivity base-station-like control center to be placed at a high location (e.g. on top of a building), which makes the solution cumbersome to deploy and expensive. In a mesh network, the plurality of nodes does in general not communicate directly with the control center, but via so-called multi-hop communications. In a multi-hop communication, a data packet is transmitted from a sender node to a destination node via one or more intermediate nodes. Nodes act as routers to transmit data packets from neighboring nodes to nodes that are too far away to reach in a single hop, resulting in a network that can span larger distances. By breaking long distances in a series of shorter hops, signal strength is sustained. Consequently, routing is performed by all nodes of a mesh network, deciding to which neighboring node the data packet is to be sent. Hence, a mesh network is a very robust and stable network with high connectivity and thus high redundancy and reliability.

In the prior art, mesh network transmission techniques can be divided in two groups: flooding-based and routing-based mesh networks. In a flooding-based mesh network, all data packets are forwarded by all nodes in the network. Therefore, a node does not have to make complicated routing decisions, but just broadcasts the data packet. By these means, the technique is quite robust. However, in large networks, the data overhead due to forwarding impacts the overall achievable data rate. Moreover, collisions of data packets are more likely to occur, further reducing the overall performance. Hence, the main problem of this solution is the scalability. Routing-based mesh networks can be further divided into proactive and reactive schemes. In proactive routing-based mesh networks, all needed network paths are stored in routing tables in each node. The routing tables are kept up to date, e.g. by sending regular beacon messages to neighboring nodes to discover efficient routing paths. Although the data transmission is very efficient in such kind of network, the scalability is still low, since in big networks, the proactive update of the routing tables consumes large parts of network resources. Moreover, the routing tables will grow with the scale of the network. In addition, the setup of the network requires time and resources in order to build up the routing tables. Reactive schemes, in contrast, avoid the permanent overhead and large routing tables by discovering routes on demand. They use flooding to discover network paths and cache active routes or nodes. When routes are only used scarcely for single data packets, flooding the data packets instead of performing a route discovery might be more efficient. If routes are kept long enough to avoid frequent routing, reactive schemes degenerate to proactive schemes. An example for a reactive routing-based mesh network protocol is used in ZigBee. However, the main problem of this protocol scheme is still the scalability of the network.

For controlling a large number of nodes, efficient communication methods such as multicasting are indispensable to achieve the required scalability. Multicasting does refer to the transmission of a data packet to several (but not all) destination nodes. Thus, only one multicast data packet is required, instead of transmitting a data packet to each destination node separately. In general, a multicast data packet includes a multicast group address or identity corresponding to a predefined multicast group comprising several nodes. However, although multicasting is a known concept, previous approaches do not take key parameters into account, e.g. geographical and context characteristics of network nodes, when defining multicast groups during a commissioning phase of the system. In particular, for large sensor or actuator networks, such as lighting systems for illuminating streets or other public grounds, these features are intrinsic for the function and controlling. For example, luminaire nodes of a lighting system, which are located in the same street, will very likely share identical control requirements.

Moreover, the creation of a multicast group is commonly performed during commissioning of the system by allocating a multicast group identity to the individual nodes. Therefore, multicast groups are predefined and cannot simply be modified. In addition, even in prior art networks, in which it is possible to create new multicast groups, existing selection methods and user interfaces are hardly developed. In particular, common selection methods are rather thought to choose elements within an area described by a basic geometric shape, such as a square or a circle. However, since most of the desired multicast groups in lighting telemanagement systems are streets or groups of streets that the user wants to control as a whole, this approach does not fit the needs of a user. For instance, selecting "Diagonal Street" in Barcelona with such simple geometric shapes will be impossible without selecting all other streets and alleys close to it. Thus, with common user interfaces and methods, allocating streets to a new multicast group and subsequently configuring its configuration is a very cumbersome and time-consuming task.

SUMMARY OF THE INVENTION

In view of above disadvantages and problems in the prior art, it is an object of the present invention to provide a control unit and a method for providing a convenient and intuitive user interface for managing multicast groups, thus improving the user convenience and speed in managing large-scale wireless networks.

The invention is based on the idea of simplifying the selection of network elements, such as network nodes or predefined groups of nodes, for managing multicast groups by means of a layered representation of the network. Here, managing a multicast group may include at least one of creating, modifying, configuring and controlling the multicast group. Thus, the network may be divided into several network layers, which include at least one network element. Network elements may be selected successively from the different network layers. For instance, a certain network layer among the plurality of network layers may be activated according to a user selection and then displayed. From the active network layer, one or more network elements may be selected based on a user input, e.g. for creating a new multicast group or modifying an already existing multicast group. Of course, also more than one network layer may be selected for being displayed, so that network elements of several displayed network layers may be selected at once. By means of such a simplified and flexible visualization of the network based on network layers, the selection process of single network elements among a plurality of network elements for creating and/or modifying a multicast group becomes more convenient and faster, thus simplifying also the controlling and managing of the multicast group. Hence, the use of multicast data packets is improved, thus simplifying the control and management of network elements in a large-scale network and increasing the user convenience, e.g. when providing a software update or when re-configuring parts or all of the network. Moreover, multicast groups can be defined easily on demand, so that the communication via multicast groups in the network is more flexible.

According to one aspect of the present invention, a control unit for creating and/or modifying a multicast group in a wireless network is provided. The control unit is adapted to display one or more network layers based on a user selection, the network layer comprising at least one network element. The control unit is further adapted to add and/or remove at least one network element of the displayed network layer(s) to/from a new or an already existing multicast group based on a user input. Here, a network element may be a single node and/ or a predefined group of nodes, e.g. a simple multicast group or the like. By these means, a user may activate one or more network layers for being displayed and select successively or layer-per-layer network elements from the respective network layers for being added/removed to/from the multicast group. Thus, the control unit provides a user interface enabling a layered selection process for defining multicast groups in wireless networks. This way, the user convenience and the ease-of-use of managing multicast groups even in large-scale networks are improved.

In a preferred embodiment, the network nodes are allocated to groups based on a spatial distribution of the nodes along predefined paths. For instance, in the example of a street lighting system or an indoor lighting system for large buildings, such groups may correspond to corridors, rooms, streets, roads, squares or parks or the like. The groups may be displayed as network elements according to the selected network layer. By these means, the selection process can be further simplified and accelerated.

In one embodiment, a network layer is creatable by a user, e.g. at least one of the plurality of network layers is user-defined. For this, the control unit may be adapted to associate network elements to a new network layer based on a corresponding user input. Hence, a user may allocate at least one network element based on at least one of the below- described features of the network element. Possibly, the network elements of a network layer may correspond to the network elements of a particular multicast group, i.e. a network layer corresponds to a multicast group. Additionally or alternatively, the control unit may be adapted to merge several network layers to one new network layer, e.g. while keeping the network layers as well, thus creating a new network layer from the combination.

Alternatively, at least some of the network layers used for the combination may be deleted after creating this combined network layer. Enabling the creation or definition of new network layers based on a user input further increases the user convenience of the layer-based visualization of the network. Alternatively or additionally, at least one network layer may be predefined, e.g. defined during the set-up of the network. Preferably, network elements are included in a predefined network layer based on at least one of the below-described features of the network element.

Preferably, the network layers may be defined based on one or more features of the respective network elements, such as a type of a node, a hardware and/or software version of a node, or a certain function of a node, a proximity to a particular type of buildings or structure, e.g. monuments or bridges, or the like. For instance, at least one network element of the network may be allocated to a particular network layer based on an importance level of the network element. Thus, in the example of a street lighting system, a street group may be associated to a network layer based on the importance, the size, the frequency of use and/or the number of luminaire nodes located in the street. Hence, luminaire nodes included in street groups relating to main streets may have high importance level and may be thus allocated to a network layer with high importance, whereas street groups of one- ways may be defined to have low importance and may be allocated to a network layer with low importance. In particular, a network layer may be defined based on at least one of a parameter of the network element, a context feature of the network element, a relation to other network elements, a geometric pattern and a grid selection. Parameters of a network element may relate to a hardware/software version or configuration of the network element. A parameter may also include certain characteristics inherent to the network element, e.g. the direction of a street group extending from north to south. In contrast, context features may relate to relative features influenced by the position or function of the network element in the network and/or in the network surroundings. For instance, in the picture of an outdoor lighting system, a context feature may correspond to a street, in which the luminaire node is put up, or to the function of the luminaire node as a collector node. The context feature may also relate to an importance level or it may be based on metadata loaded from the internet or other sources, e.g. the node being in the neighborhood of a hospital, monument, bridge, park or route of public transportation or the like. Alternatively or additionally, a feature of a network element may relate to a pattern, a grid selection and/or a relation of the respective network element to previously defined network elements. For instance, a relation may require a proximity to previously defined network elements, e.g. for selecting all street groups, which have a direct junction with previously defined and/or selected streets/groups. This may relate to a function for growing a selection of network elements from a previously activated network layer or from a previously selected network element. Another example for a relation is the selection of nodes or groups within areas, which are surrounded by previously defined groups, as for instance all street groups, which lie within an area delimited by certain other street groups. This may be denoted as a "fill-in" function of the user interface. In a further example for a relation, a geographic direction or a direction on the map relative to one or more network elements to be specified may be selected. For instance, a user may select all streets south of the main street or left from the main street. Likewise, the relation may include a certain distance from a specified point, e.g. a physical distance, a hop distance or any other routing distance. Thus, a user may select all luminaire nodes within a hop distance of two from a collector node. Hence, the relation feature may relate to a relative position of the node. Of course, also absolute positions may be used for selecting one or more network elements for defining a network layer. Moreover, a pattern feature of a network element may relate to a geometric pattern, e.g. every second node of an area or street, whereas a grid selection may select network elements, which are distributed in form of a grid, e.g. streets of a city with crossings at right angles.

Preferably, network layers are non-overlapping, i.e. network elements are preferably associated to exactly one network layer. However, in some networks, it may also be advantageous that network layers overlap. Then, network elements may be associated to more than one network layer. By these means, a user can select a view of the network, in which only main streets or areas of the network layer with high importance is shown. This simplifies a selection of single streets or network elements for creating or modifying multicast groups.

In one embodiment, the control unit may be able to assign network elements of different network layers to the same multicast group, thus enabling cross-layer selection or layer independent selection. Thus, a multicast group may comprise network elements of different network layers. In a preferred embodiment, network layers may be successively displayed based on a user input and network elements corresponding to the respective network layer may be selected successively, i.e. layer per layer. Thus, the multicast group may be extended by at least one network element of at least one other predefined network layer, which is displayed subsequently to another network layer.

Preferably, the multicast group of selected network elements is configured based on a user input. Thus, the network nodes comprised in the multicast group are provided with configuration information, e.g. by transmitting a multicast data packet. In case of a lighting system, the configuration may correspond to adjust dimming patterns, lighting schedules, and other functionalities.

Preferably, the user interface also provides selection tools for refining a selection and/or for achieving an efficient configuration replication in the network. For this, the control unit may be adapted to perform at least one operation of the set theory with multicast groups, such as union, intersection, set difference, complement, symmetric difference or the like. In this way, sub-groups or super-groups may be created, e.g. in form of a compound multicast group, and the management of multicast groups becomes more flexible. Additionally or alternatively, the control unit may be adapted to copy a

configuration of one multicast group and apply it to at least one other multicast group and/or a subset of this other multicast group, thus providing efficient means for configuring the network.

Moreover, for refining a selection, a group and/or a multicast group, network elements may be selectable based on at least one condition input by a user. Thus, all network elements within a group, multicast group and/or network layer that fulfill the condition are selected. In one embodiment, the control unit may have a plurality of predefined conditions stored and these predefined conditions may be selectable for a user. Additionally or alternatively, a condition may also be definable by a user, i.e. drafted and input by a user. The condition may include at least one feature of a network element, such as a parameter of the network element, a context feature of the network element, a relation to other network elements, a geometric pattern and a grid selection as described above.

In one embodiment, multiple layers that are activated at the same time are visually differentiated, e.g. by color, etc.. Thus, a user may easily recognize, which network element belongs to which network layer. In case that the network layer is defined based on certain features of therein included network elements, the features of the network elements are thus visualized. Furthermore, he display of the selected network layer(s) may be based on a spatial distribution of the network elements included in the selected network layer(s) within the network. Thus, the selected network layer may be displayed such that the spatial arrangement of the included nodes or groups is visible. Hence, the network elements included in the selected network layer may be displayed based on their spatial distribution within the network area or on their membership in a specified group. Here, it may be selectable whether the single nodes included in a group are displayed or whether the group is displayed without details about the node distribution therein. Alternatively or additionally, the selected network layer may be displayed in overlay with a graphic representation of the surroundings of the network, e.g. an illustration of the area or building, in which the network is set up, such as a city map, a road map, a plant layout, a floor plan or the like. By these means, the user interface becomes more intuitive and the user convenience is further increased. Alternatively or additionally, the network elements included in the selected network layers are displayed as a list, possibly with all features and parameters thereof. This database-like view provides a detailed overview over the network elements included in the selected network layers.

Possibly, the above-described display modes may also be selectable for displaying one or more multicast groups. This may be advantageous for checking the elements of a multicast group after its creation or modification. Furthermore, the control unit may be adapted to set a type of the multicast group. The classification of the multicast group for determining the type thereof may be performed automatically by the control unit or may be based on a user input, e.g. by selecting among a plurality of predefined types or by defining a new type. By classifying the multicast groups, finding, organizing and identifying multicast groups is simplified. Possibly, a preset or user-defined configuration may be applied to the multicast group based on its type. In the example of a street lighting system, a route may be defined as a multicast group and the type of the route may be set to, for instance, pedestrian, emergency, public transportation or the like. This may then be assigned to a network layer. In this case, the control unit may be adapted to apply a predefined configuration to the route either automatically or based on a user input.

In a further embodiment, which may also be realized independently from the embodiments above, at least one node of a wireless network may have at least one dynamic configuration, preferably in addition to a static configuration. The static configuration may be used for static or normal operation and the dynamic or interactive configuration may be used for operation in a certain situation upon activation. Possibly, the node may be configured to have more than one dynamic configuration, e.g. depending on an external situation such as an accident, emergency route or public transportation. For instance, the dynamic configuration may be activated by wireless interaction between the node and a moving object, such as a tramway, ambulance or police car. This may be realized using beacons, which are sent by the moving object and received by a node. Preferably, the beacons are receivable within a limited predetermined range, so that only nodes nearby are switched to their dynamic configuration. However, the dynamic configuration may also be activated remotely, from a user interface, a control center or other backend entity. By these means, the operation of the nodes may be adapted to external circumstances, thus improving the performance of the network.

In a further embodiment, the control unit is adapted to simulate a configuration of a created or modified multicast group, of at least one selected network layer and/or of the whole network. The simulation is displayed to a user, so that the user can easily decide, whether the configuration has the intended effects. The control unit may be able to zoom in and out of certain areas of the network and may even allow a change of perspective.

Preferably, the control unit may consider at least one ambient condition for the simulation, as in the example of an outdoor lighting system, season, weather, daytime or geographic position of the network. For instance, the configuration of a street lighting system of a city can be simulated for foggy winter days or for summer nights. Thus, a user gets a realistic impression of the configuration of the outdoor lighting system and can check, whether the configuration is correct for all relevant ambient conditions.

In a preferred embodiment of the present invention, at least one node of the network is a luminaire node of a lighting system. Preferably, the luminaire nodes are grouped based on their position, for instance luminaire nodes belonging to the same street are allocated to the corresponding street group. In another example, the network may correspond to an indoor lighting system, so that the luminaire nodes may be grouped based on their position in corridors, rooms and the like. In general in the embodiments of the present invention, (multicast) groups may be defined independently from each other, i.e. they may overlap.

According to a further aspect of the present invention, a system is provided using any one of the above-described embodiments for a control unit according to the present invention. Preferably, the system is applied to a lighting system, such as an indoor or outdoor lighting system. However, the system and/or the control unit according to the present invention may also be applicable in sensor or actuator networks.

According to another aspect of the present invention, a method is provided for managing a multicast group in a wireless network, the network having a plurality of nodes and the method comprising steps of displaying at least one network layer based on a user selection, wherein the network layer includes at least one network element, and

assigning/removing at least one network element of the displayed network layer to/from a multicast group based on a user input. The network element may be a node and/or a group of nodes. The method according to the present invention may be adapted to be performed by a control unit according to the present invention. Also, the method according to the present invention may be modified according to one of the above-described embodiments for a control unit according to the present invention.

BRIEF DESCRIPTION OF THE DRAWINGS

In the figures:

Figure 1 illustrates an example of a wireless mesh network;

Figure 2A illustrates an overlay of different network layers according to the present invention, while Figures 2B and 2C illustrate the respective network layers of Figure 2A;

Figure 3 shows a flow chart of a method for managing a multicast group according to the present invention; and

Figure 4 illustrates a multicast group corresponding to a route of public transportation according to the present invention.

DETAILED DESCRIPTION

Preferred applications of the present invention are actuator networks, sensor networks or lighting systems, such as outdoor lighting systems (e.g. for streets, parking lots and public areas) and indoor lighting systems for general area lighting (e.g. for malls, arenas, hospitals, parking decks, stations, tunnels etc.). In the following, the present invention will be explained further using the example of an outdoor lighting system for street illumination, however, without being limited to this application. In the field of lighting control, the telemanagement of outdoor luminaires via radio-frequency network technologies is receiving increasing interest, in particular solutions with applicability for large-scale installations with segments of above 200 luminaires.

In Figure 1, a typical network with mesh topology is shown. A plurality of nodes 10 (N) are connected one to another by wireless communication paths 40. Some of the nodes 10 function as collector nodes 50 (N/DC), which receive data packets from the surrounding nodes 10 via single-hop or multi-hop transmissions and transmit them to a control center 60 and vice versa. Thus, the collector nodes 50 may operate in the manner of gateways between the nodes 10 and the control center 60. Optionally, the collector nodes might act as control center themselves. The wireless communication paths 40 between the nodes 10 and collector nodes 50 may be constituted by RF transmissions, while the connection 70 between the collector nodes 50 and the control center 60 may make use of the Internet, mobile communication networks, radio systems or other wired or wireless data transmission systems. Therefore, the nodes 10 and the collector nodes 50 comprise a transceiver for transmitting or receiving data packets via wireless communication paths 40, e.g. via RF transmission. Since RF transmissions do not require high transmission power and are easy to implement and deploy, costs for setting up and operating a network using the device can be reduced. This is especially important for large RF networks, e.g. a RF telemanagement network for lighting systems. However, the data packet transmission may alternatively use infrared communication, free-space-visible-light communication or powerline communication. In the following, data packet transmitted from a node 10 to the collector node 50 are referred to as uplink data packets, whereas data packets transmitted from the collector node 50 to one or more nodes 10 are denoted downlink data packets.

Moreover, when a data packet is addressed to all nodes 10 of the network, this is referred to as broadcasting, whereas a data packet directed to a group of nodes 10 is called a multicast or groupcast data packet. A data packet directed to a single node 10 is denoted a unicast data packet.

In a telemanagement system for lighting control, the number of luminaire nodes 10 is extremely high. Hence, the size of the network is very large, especially when compared to common wireless mesh networks, which typically contain less than 200 nodes. In addition, the nodes 10 typically have limited processing capabilities due to cost

considerations, so that processing and memory resources in the luminaire nodes 10 will be limited. Thus, communication protocols for transmitting data packets between single nodes 10 should consider the limited resources for efficient and fast data packet transmission.

Furthermore, compared to other so-called ad-hoc mesh networks, the telemanagement system for an outdoor lighting control network is stationary, i.e. the nodes 10 do not move.

Nevertheless, it may be required to flexibly define addressee groups of destination nodes, e.g. due to changing requirements. In a lighting system, all nodes 10 may be connected to mains power. Consequently, network changes will be mainly due to a changing environment, e.g. due to traffic. If the nodes 10 are stationary, the physical positions of the nodes 10, for instance GPS coordinates, may be known in the system, enabling geographic or position- based routing. Furthermore, telemanagement of an outdoor lighting system does not require a high data throughput. That means that a large part of the data traffic consists of time- uncritical data packets, e.g. status report data, statistical data, schedule updates or the like. Moreover, in a lighting system such as a street lighting system, communication is very asymmetric. Most of the traffic is generated by the luminaire nodes 10, e.g. reporting their status, their dimming profile, sensor values or power usage to the control center 60. The other traffic consists of control commands from the control center 60 to the different nodes 10, e.g. for adjusting a dimming pattern or switching on/off lamps. The traffic from the control center 60, or data collector 50, to the nodes 10 consists of 1 :N traffic, either in unicast, multicast or broadcast mode. Preferably, nodes 10 that often require the same data transmission are grouped as a multicast group. Thus, data for the nodes 10 of this multicast group is transmitted as a multicast data packet. This way, a control center 60 or a collector node 50 can communicate with several nodes 10 of a multicast group by means of a multicast transmission instead of addressing each node separately using unicast transmissions.

In fig. 2A-C, a section of a street illumination system is shown for illustrating the management of multicast groups by the example of multicast group creation. In a street illumination system, most of the luminaire nodes 10 are arranged along paths, such as streets, trails in parks, subways and the like, and are often grouped accordingly. In fig. 2A, the spatial distribution of luminaire nodes 10 and of the street groups R and r within the network is illustrated. The luminaire nodes 10 are either positioned along main streets or avenues R or smaller roads r and are grouped into a corresponding street group R or r. For managing a large wireless network such as a street lighting network, a control unit provides a layered network description, wherein the nodes 10 or given groups of nodes 10 are associated to different network layers according to their importance. In the example shown, all avenues R belong to the network layer of level LI being the most important level and, thus, all luminaire nodes 10 included in the street groups R are also associated to the network layer LI . Here, the roundabout or crossing C is also associated to the network layer LI . The small roads r and the corresponding luminaire nodes 10, however, belong to the network layer L2. It becomes clear with fig. 2A that it is difficult to select a whole street R or r without selecting luminaire nodes 10 belonging to a different street. Moreover, in general, a street does not have a simple geometric shape, such as a straight line, but may wind between the building blocks of a city. Thus, it is difficult to select luminaire nodes 10 of one street by drawing a circle or rectangle using a computer mouse or other simple input means. Therefore, according to the present invention, the control unit, e.g. of a segment controller or control center 60, enables a user to select one or more network layers, which are then displayed separately, and to select single nodes 10 or whole groups from the selected network layer. For instance, as shown in fig. 2B, if a user selects the network layer LI, the network layer LI is displayed alone. Here, only the street groups are displayed, without the included luminaire nodes 10. However, it may be selectable for a user to additionally show the single nodes 10. Then, the user selects any of the avenues R or the crossing C. For this, the user may simply use the mouse to select avenues R relevant for this level LI, e.g. by selecting them in a given drawn square, clicking thereon or even selecting a single luminaire node 10 of a particular avenue R. Possibly, the control unit can automatically extend the selection to include the complete avenue R, when the latter only lies partially within the drawn square or when a single node 10 is selected. The selection is marked, e.g. highlighted or the like. Preferably, the user starts with the most important level, i.e. with network layer LI. After selecting the luminaire nodes 10 or avenues R of the network layer LI, the user can either stop selecting or continue with another network layer for extending the actual selection. Thus, if the user activates the network layer L2 including the small roads r, the control unit switches to the display of the network layer L2, as shown in fig. 2C. Of course, all these processes can be performed likewise, when removing a network element from a multicast group for modifying a multicast group.

In fig. 3, a method for managing multicast groups in a wireless network is shown. In step S10, the control unit provides a selection menu for selecting a network layer. The user can select one or more network layers for being displayed. Additionally, the user can select, whether to display the single luminaire nodes 10 of the selected network layers or whether to show the street groups r or R and omit nodes 10, which are included in the groups, in order to simplify the displayed view further. In the next step S20, the network elements, i.e. the nodes 10 or groups R or r, of the selected network layers are displayed. If the user has selected no network layer, the control may display all network layers, e.g. as shown in fig. 2A. In step S30, the user selects single network elements, i.e. single luminaire nodes 10 or street groups R or r, to be added to or removed from a multicast group. In other words, the control unit creates a new multicast group or modifies an existing multicast group based on a user input. After having finished the selection process at the displayed network layer, the user may decide to continue the selection process by successively selecting lower or higher network layers. This is indicated by the dashed arrow connecting step S30 with step S10 in fig. 3. As shown in fig. 2, the control unit displays the network in a map-based layered visualization, in which streets are allocated to different network layers of the system. Moreover, the view shown in fig. 2A may be displayed in overlay with a map of a city, or on a floor plan or building plan, if the lighting system is an indoor lighting system. In addition to the map-based visualization of the network, the control unit also displays a list of network layers, from which the user can activate a number of them. As explained above, the activated network layers are then displayed, while the non-selected network layers disappear from the view. If more than one network layer is displayed, the different network layers can be visualized using different colors, line types or symbol sizes or the like. Another possible visualization mode of the network is a database-like visualization, in which each luminaire node 10 of the active network layer is listed in a table, preferably together with its respective features. Preferably, the user can select between the different views.

Possibly, the control unit provides selection tools in order to further simplify the selection process. For instance, the control unit can offer a menu comprising selection tools such as set operations, e.g. combine two selections, select the difference of two selections, select the complement of a selection, intersect two selections and so on.

Moreover, a grid selection is possible, wherein the control unit selects network elements following a grid distribution, e.g. streets with crossings at right angles or the like. This is in particular useful in lighting systems for cities or large buildings. Moreover, the selection may be based on parameters of the luminaire nodes 10, such as parameters of the hardware, e.g. 60W lamp etc., or the software, e.g. software version number etc., or the configuration, e.g. luminaire nodes 10, which are also switched on during daytime. Furthermore, the user can select network elements having a certain context feature, for instance, relating to the neighborhood of the network element or its function in the network or based on metadata, which can be loaded from the Internet or other sources. Such metadata can include information about monuments, parks, hospitals, etc. Possibly, the metadata are categorized, so that the user can make a fast and easy selection of a given category. An example for a selection based on a context feature is to select all luminaire nodes 10, which are close to a crossing C, or all luminaire nodes 10, which operate as a collector node 50 in the network. Another important selection tool are relation conditions. A relation condition may select all nodes 10 of the active network layer(s) or of a selected group(s), which fulfill a given relation. For instance, a user can select to fill in the network layer of the previous level LI, so that all roads r of the network layer L2 are selected, which are delimited by the selected avenues R of the network layer LI . This is advantageous, since urban districts are often confined by large avenues. Thus, this selection tool provides means for easy selection of an urban district. Similarly, a relation condition can be provided as "grow previous level", wherein roads r from the network layer L2 are selected that have a direct junction with the avenues R previously selected from the network layer LI . Moreover, a direction may be selected in order to select streets following a given direction, e.g. north-south or diagonal on the map or the like. Likewise, a direction relative to a particular point in the network can be defined, e.g. in order to select all luminaire nodes 10, which are left on the map with respect to a particular avenue R. Furthermore, a relation condition can define network elements having a certain distance to a particular point in the network. For instance, the user can grow the selection of luminaire nodes by a number of hops indicating the routing distance to the nearest data collector node 50. Also, the user can define a pattern, e.g. a geometric pattern or a functional pattern. An example for a geometric pattern includes selecting every second luminaire node 10, while an example for a functional pattern includes selecting one lamp at light intensity 100% and another lamp at light intensity 80%. All these and similar selection tools can be applied to a selection or multicast group for refinement. For instance, if the user has selected a street group r, he can further select luminaire nodes 10 out of this selected group r by applying any of the above-described selection tools. However, the selection tools can also be applied to a whole network layer in order to select network elements from this network layer.

A network layer can either be predefined or created by a user. In order to create a new network layer, any of the above-described selection tools can be used for selecting network elements. Hence, a user can define one or more features of network elements, which should be included in the new network layer. Moreover, any operation of the set theory can be applied to existing network layers for creating new user-defined network layers. For instance, the user can combine two network layers to a new network layer, while either keeping the two network layers or deleting one or both of them.

In addition, the control unit may be capable of defining routes consisting of street groups r or R, parts thereof and/or of single luminaire nodes 10. The setup of routes can be helpful in many different cases, such as emergency situations or public transportation. The control unit can provide a special menu for route setup, so that the user can create a multicast group of the type "route" for a particular purpose. The route creation may be performed according to any of the processes described before. For instance, the user can select network elements for being included in the route as described for the creation or modification of a multicast group. Moreover, the user may select the type of the route, e.g. by selecting between several predefined types of route, such as a bus route, an emergency route or a pedestrian route, or by defining a type of route himself. The control unit can apply a predefined configuration to this route-type multicast group automatically or based on a user input. For instance, in some situations, a special illumination may be required or it may be desirable to check the state of the system or to retrieve information. One example for a route- type multicast group is shown in fig. 4, wherein the route corresponds to a bus route p with a bus stop at the crossing C. The luminaire nodes 10 of the bus route p can be configured such that they switch to brighter illumination based on a bus schedule. Possibly, alternative routes can be configured to be used, if the primary route fails. For instance, if a route fails during an emergency, so that an ambulance driving along that route has to take another route, the light setting of the lamps in the alternative route would be activated, thus showing the ambulance the way. This feature may also be based on traffic report.

In a preferred embodiment, one or more nodes 10 or a group of nodes 10 are configured for a dynamic operation different from a static operation. Thus, the nodes 10 are switchable from the static operation to the dynamic operation in response to a certain event. Here, the static operation corresponds to the normal or default operation of the luminaire nodes 10, while the luminaire nodes 10 can be switched to the dynamic operation mode having different operation properties than in the static operation mode. Such a switching event includes e.g. receiving a beacon sent from a passing object, such as a police car, an ambulance or public transportation. For instance, a luminaire node 10 can be switched to dynamic operation mode by wireless interaction with a mobile object, such as a car. This wireless interaction may include the moving object broadcasting beacons, which are received by luminaire nodes 10 nearby. When applying a dynamic and static configuration to a route- type multicast group, e.g. to a bus route, the luminaire nodes 10 on the route receiving beacons from the bus will adapt their light settings according to the dynamic configuration. Hence, when the bus approaches a luminaire node 10 of the route p, the luminaire node 10 receives the beacons broadcasted by the bus and switches from a basic illumination to a brighter illumination. By these means, the route of public transportation can be dynamically configured, thus optimizing the controversial parameters of energy efficiency and illumination. Possibly, all luminaire nodes 10 have a static operation mode and a dynamic operation mode and can be switched upon receiving beacons from a mobile object. Even further, several dynamic configurations can be set, e.g. differing between beacons received from a bus or other public transportation, from a police car or an ambulance.

Furthermore, the control unit can provide a visualization of the created or modified multicast groups and the setup of the network. For this, the control unit simulates and displays the configuration of the network. In the example of a lighting system, the control unit simulates the achieved light levels of the street lighting system. In order to adapt the simulation to various ambient conditions, the user can specify at least one of season, daytime, weather and a geographic position of the network. Moreover, the control unit can show the simulated view of the network from different perspectives. Based on the result of the simulation, the user can accept the setup of the network or modify his design decisions. Therefore, according to the present invention, a control unit and a method for user interface are provided, simplifying the management of multicast groups in a large wireless networks by means of a layered network representation. This greatly improves the ease of use and speed when remotely managing large-scale wireless networks, such as outdoor lighting systems. Moreover, selection tools are also proposed for, among other purposes, refining a selection and achieving efficient configuration replication in the network. In addition, information visualization and behavior simulation of the network help user to confirm the achieved effects of the network configuration.

Claims

CLAIMS:

1. A control unit for managing a multicast group in a wireless network with a plurality of nodes (10), the control unit being adapted to:

display one or more network elements of at least one network layer (LI, L2) that is selected by a user; and

assign or remove at least one network element of the displayed network layer

(LI, L2) to or from a multicast group based on a user input;

wherein a network element is a node (10) and/or a group of nodes (10).

2. The control unit according to claim 1, wherein at least one of the network layers is created based on a user input and/or is predefined.

3. The control unit according to claim 1 or 2, wherein a network element is allocated to a network layer (LI, L2) based on an importance level and/or on features of the respective network elements.

4. The control unit according to any one of the preceding claims, wherein the control unit is adapted to assign or remove network elements of different network layers to or from the multicast group, at least some of the network layers being successively displayed according to a user selection.

5. The control unit according to any one of the preceding claims, wherein the network elements of the selected network layer (LI, L2) are displayed based on a spatial distribution of the network elements within the network and/or wherein the network elements of the selected network layer (LI, L2) are displayed in overlay with an illustration of the network area and/or wherein the network elements of the selected network layer (LI, L2) are displayed as a list.

6. The control unit according to any one of the preceding claims, wherein the control unit is adapted to select network elements out of a group and/or multicast group and/or a within one or more selected network layers according to at least one condition of the respective network element based on a user input.

7. The control unit according to claim 6, wherein the condition includes at least one of a parameter of a network element, a context feature of a network element, a relation to other network elements, a geometric pattern and a grid selection.

8. The control unit according to any one of the preceding claims, wherein the control unit is adapted to perform at least one operation of the set theory with multicast groups and/or to copy a configuration of one multicast group and apply the configuration to at least one other multicast group.

9. The control unit according to any one of the preceding claims, wherein the control unit is adapted to determine a type of the multicast group based on a user input and/or to apply a configuration to the multicast group based on a user-defined type of the multicast group.

10. The control unit according to any one of the preceding claims, wherein the control unit is adapted to apply a dynamic configuration to a node (10), wherein the dynamic configuration is activated by a wireless interaction between a moving object and the node (10).

11. The control unit according to any one of the preceding claims, wherein the control unit is adapted to simulate a configuration of one or more multicast groups and to display the simulation.

12. The control unit according to claim 11, wherein the control unit is adapted to simulate the configuration depending on at least one ambient condition.

13. The control unit according to any one of the preceding claims, wherein at least one node (10) of the network includes a luminaire node (10) of a lighting system.

14. The control unit according to claim 13, wherein the luminaire nodes (10) are allocated to groups corresponding to their position.

15. A method for managing a multicast group in a wireless network with a plurality of nodes (10), the method comprising the steps of:

displaying one or more network elements of at least one network layer, which is selected by a user; and

assigning or removing at least one network element of the displayed network layer (LI, L2) to or from a multicast group based on a user input;

wherein a network element is a node (10) and/or a group of nodes (10).