WO2006089756A1 - Distributed network system with hierarchical management of resources - Google Patents

Abstract

Disclosed is a digital network for communication between a plurality of devices. Network devices have source for transmitting data on the network and sinks for receiving data from the network. Hierarchical prioritized managers manage connections between sources and sinks. Before setting up a connection they first query a negotiation administrator to get the right for negotiating with other managers and setting up connections. When all other managers having higher priorities also have granted the connection, the manager connects sources and sinks.

Description

Distributed Network System with Hierarchical Management of Resources

Technical field

The invention relates to a distributed network system which connects a broad variety of electronic devices in a house by a common network.

Prior art

In modern multi-media networks for homes several devices are connected together. Such devices can be complex multimedia devices like TV sets or DVD players. They can also be less complex devices like temperature controllers or even very simple devices like ja- lousie actuators, or light switches. All these devices are connected together by a common network.

A common standard for multi-media networks is the HAVI standard. A home network based on this standard is disclosed in EP 1 044 536 Al. This standard describes different nodes with different capabilities from simple *Base nodes" to complex *full nodes" . A disadvantage is that even the relatively simple "Base nodes" require complex and expensive interface hardware to communicate with other nodes. Furthermore there is no satisfactory mechanism for resolu- tion of resource conflicts as described in the following scenario: A first home inhabitant is listening to some music in the bathroom. In the kitchen is another person, who uses the intercom to call the bathroom. During this conversation a phone call arrives. There are now three applications - Music, Intercom and Phone - which require access to the speakers in the bathroom. Now the applications influence each other. The application Music is influenced by the application Intercom. Both are again influenced by the application Phone . The resource conflict can only be resolved by a "Full AV node" which, can act as a master controller, e.g. a central resource manager. Therefore a very complex central controller is required.

In the example home, we have to expect that the intercom might be from a different manufacturer than the DVD player. Furthermore the DVD player may have been added to the network at a later time after installation of the network. This leads to the problem how the applications can influence each other in a meaningful way, when they were unknown to each other at construction time. A solution is also provided in EP 1 044 536 Al by using an intelligent update method for updating the system by retrieving updated software. Often an import of software cannot be ^'accepted for reliability and stability reasons or simply because some devices are not updateable. Further- more the intelligent updating mechanism requires at least one complex "Full node" .

Disclosure of the invention

The invention is based on the problem of providing a network system which can connect a broad variety of different electronic devices, providing full Plug and Play functionality, working without any central units, and which can easily be implemented within devices, therefore requires only a low amount of memory and CPU power. Fur- thermore it should be compatible to the MOST standard.

One inventive solution to this problem is defined in the independent claims. Improvements of the invention are the subject matters of the dependent claims .

The invention relates to a network comprising the components for hierarchical resource management, a device manger therefore and a procedure for managing resources in a network.

The invention is based on a decentralized network concept. Most ap- plications in an inventive digital multimedia network (Phone, Intercom, etc) comprise software. The application does the following: - Query for available sources and sinks. Therefore the network needs to be scanned. From each device certain capability and status information need to be retrieved.

- Connect sources to sinks (e.g. connect the tuner to the ampli- fier) .

- Control sources, and sinks (e.g. change the radio station at the tuner, adjust the volume at the amplifier, etc.) .

For scanning and controlling, the application needs a control chan- nel to each source and each sink (fig. 3) .

The part of the application connecting sources and sinks is called the manager. Preferably the manager provides a standardized interface to the application. Each manager is responsible for his own connections. A manager e.g. must not start a source streaming ^'without having a sink to consume the stream. Also a manager must not stop a source streaming, if there^' is still a sink connected. Furthermore connections can only be established by managers. This means that a source never starts streaming by itself, this is al- ways initialized by a manager, and a sink never starts consuming data by itself, this is also always initialized by a manager.

The sources, sinks and the manager can be spread out over different devices, but they also can be combined in some devices or even in one device.

The introduction of managers into a system's model is the first step to make applications visible to each other. Once they can address each other, they will be able to negotiate access to shared resources.

In addition at least one profiler may be provided. Furthermore at least one but preferably exactly one negotiation administrator may be provided (fig. 7) . All these enhance the network functionality although the network is also functioning without these devices. All these can be implemented in any device as well as in simple micro- controllers as they do not need much memory or much computing power compared to the prior art, which is e.g. implemented on a JAVA console or may also be implemented as software on a Personal Computer.

In another embodiment, for resolution of conflicting states priority levels are assigned to the managers. Preferably the highest priority belongs to the negotiation administrator, which assigns access rights to all other managers. The negotiation administrator may be part of any manager or application. Preferably the manager having the highest priority is selected as the negotiation administrator. Priority levels below are assigned to managers according to the importance of the applications. Even the managers of different instances of an application should have different priorities . The lowest priority levels are assigned to the devices . All managers may have the same priority (fig. 8) .

In general there may be assigned any^' priority level to any device and any manager, even for negotiation administrators and profilers. This allows a very detailed adjustment of the behavior of the net- work. For example a fire alarm might be set on top of the negotiation administrator as described before. This permits a high priority fire alarm having immediate access to all resources.

This hierarchy model has several advantages. If a manager is taken out of the system, the order of the remaining managers does not change. Furthermore Priority Levels can be changed dynamically. So the user in the bathroom could select, that for the next hour, the music is more important than the phone. Finally no invalid setups are possible. This becomes very important for Plug and Play Sys- terns, where devices might be plugged in, which manager's have any priority level set.

Potential conflicts caused by managers having the same priority might be solved by assigning priorities according to the node posi- tion of a device. If there are several applications within a node the instance ID or any other physical or logical address could be used. This mechanism should not change the basic priority order, but adjust the priority of managers previously having the same priority in relation to each other.

5 For adjustment the settings may be altered by the user. After assigning a unique priority to each manager a priority chain is obtained.

For connecting sinks to sources, managers have to follow a certain 10 protocol. It is not is not allowed to connect sources directly to sinks, if there is more than one manager in a system. The preferred connection procedure comprises the following basic steps:

1. Get the right to negotiate source and sink access.

15 2. Request the wanted set of connections from higher prioritized managers .

3. Publish granted connections- to all managers.

4. Get required network bandwidth.

5. Establish connections.

20 6. Release the right to negotiate source and sink access.

These basic steps are described in detail below.

^! 1. Get the right to negotiate source and sink access.

25

In a bigger network, two applications might simultaneously start to plan new connections between sources and sinks. A typical case might be that a phone call arrives at the same moment when the user presses the play button at the DVD player. If now the managers of

30 both applications start to negotiate the access to the needed resources with the other available applications parallel, the result could easily become unpredictable, since the two managers could confuse each other. Therefore according to the invention the right of negotiating access to needed resources is serialized. Under the

35 assumption, that even in big systems, simultaneities will occur very seldom and that negotiating access to sources and sinks will usually take only a few milliseconds, this is no real constraint.

In another embodiment of the invention at one time, only one man- ager is allowed to negotiate access to sources and sinks.

In another embodiment, if an application's manager gets the right to negotiate the access to some sources and sinks it does not mean, that the manager gets the right to access already the sources and sinks. It means only that the manager may negotiate the access with the other installed managers, which might want to use these sources and sinks by their own.

In a real Plug and Play system according to the invention there is preferably no central point by definition (fig. 11) . Therefore one negotiation administrator is selected from all managers . So each managers should have the ability to take over the role of the negotiation administrator, when selected.

In another embodiment one of the network's managers has to be selected to do this job. According to the invention this is the manager with the highest priority level . During startup each manager scans the network, to find out, which of the manager is the one with the highest priority level. This manager now performs the function of the negotiation administrator. If this manager is unplugged during runtime, the next higher manager takes over and so on.

In an alternative embodiment the negotiation administrator may be a discrete physical or logical unit.

Before a manager starts to negotiate, it requests, the right to do this from the negotiation administrator, which is the manager with the highest priority level. If this manager already granted the right to another manager, it rejects the request. The calling manager waits a predetermined time, preferably 20 ms, or a randomly or dynamically assigned time, then retries. If no other manager holds the right to negotiate, the calling manager gets this right.

After a manager has negotiated, it returns the right to the nego- 5 tiation administrator. This one then can pass it to another manager if requested.

2. Reguest the wanted set of connections from higher prioritized managers .

10

In another embodiment, after an application's manager got the right to negotiate it's planned set of connections, it has to request these connections from higher prioritized managers. Therefore it passes a connection request to the manager with the next higher

15 priority level. If this manager does not refuse this connection request, this manager passes it again to the manager with the next higher priority level and so on. If no manager is above to which the connection request, can be passed to, the request is passed back to the calling manager, which finally gets access to the sinks and

20 sources and then establishes the connection (fig. 12). This procedure is independent from the types of managers. There may be managers queried first, as they have the next higher priorities. If available, a profiler may be queried later, as it has a higher pri-

' ority.

25

Before passing a request to the manager with the next higher priority level or back to the calling manager, any manager could modify the request. It might add or remove resources or modify parameters. By doing this access to resources which are used by a higher pri-

30 oritized application may be restricted or even denied (fig. 12).

In another embodiment a source might be routed over additional applications. This might be used to chain in additional devices like an audio equalizer. For doing this the source is connected to the 35 audio equalizer's sink and the audio equalizer's source is connected to the final sink. In another embodiment a flag may be provided within a request, preventing modification of the request. This flag can be set by the calling manager. If a request cannot be granted without modifica- tion, it will then be refused.

In a further embodiment at least one profiler is provided, which adapts the requests according to profiles. Such profiles may be predetermined and/or set by a user or dynamically assigned upon configuration changes of the network or dependent of parameters of network devices. Profiler are also represented by a manager. Typically profiler's managers have a high priority (fig. 13).

In another embodiment of the invention at least one virtual device as virtual source and/or virtual sink is provided. These virtual devices are generated by software to permit a connection with other real or virtual devices (figures 14 and 15).

3. Publish granted connections to all managers.

To avoid conflicts with already existing connections owned by lower prioritized managers, each granted connection is published to the lower prioritized managers. This is done by the calling manager sending a list containing the connections to the manager with the lowest priority. From there it is passed upwards the priority chain. Managers, which have setup connections themselves using the listed sources or sinks, release these connections, unless the sources or sinks accept multiple connections before passing on the list to the next higher manager. Once the highest prioritized man- ager receives the publishing telegram, it tells the calling manager that publishing has been finished (figures 16, 17) .

4 . Get required network bandwidth .

In another preferred embodiment means for freeing network resources are provided for allocating network bandwidth with a channel being able to transport data for a requested connection. If an application's manager can not get the required network resources, to build a connection, it can request from lower prioritized managers to release their used network resources. To cause the system's lowest prioritized manager to release it's resources, this request is sent to the lowest manager in the priority chain. If this manager allocates these resources, it frees them and confirms the resources availability to the calling manager (fig. 24, 25) . If a device manger, which has been requested to free network re- sources only holds a part of the requested resources, it frees as much of the requested resources as possible and then forwards the remaining request to the next manager. An improved method of freeing spread resources from the managers with the lowest possible priorities comprises the following steps: . ^■ '

1. The calling manager sends a freeing request to the manager with the lowest priority. The freeing request contains a flag, which tells managers not to. free any resources, if they can not cover the whole request. 2. If a manager can cover the whole request, it frees the requested resources and confirms the availability to the calling manager. 3. If a manager can not cover the whole request and the *don't free parts"-flag is set, a manager adds the amount it could contribute to a field reserved for this purpose in the Freeing Request. If this "spread resource found"-field reaches 100%, the "don't free parts"-flag is removed and the request is passed back to the manager with the lowest priority.

4. If the request returns to the calling manager, the subordinate managers do not have the requested amount of the resource to free. Thus the manager has to cancel connecting.

5. If a manager gets the Freeing request without the "don't free parts"-flag not set it checks if the "spread resource found"- field minus it's own part if above or equal to 100%. If it is, it passes the request upwards without freeing anything. 6. Otherwise it frees it's allocated resources, removes the freed part from the requests amount and passes the request upwards, if it is not completely fulfilled.

A freeing request comprises the following information fields: — Type of resource requested to be freed

- Amount of resource to be freed

- A ^βdon't free parts"-flag

- A "spread resource found"-field

- A "spread resource freed" -field

5. Establish connections .

According to the invention application data is only transmitted via connections. Basic network transfer modes like asynchronous appli- cation data via Application Message Service and Packet Data Transfer as they are for example defined in the MOST standard cannot be used directly. For setting up connections, sources, sinks and network bandwidth are required. This is a unique mechanism which is independent of type of transfer like via asynchronous or synchro- nous channels. For example in MOST networks Function blocks are defined for different types of asynchronous application data. Connections are exclusively established by resource managers, independent from the type of the resources .

In a further embodiment means for tunneling frames of a different network type are provided. For the case, the inventive network is based on the MOST standard, alternate frames like Ethernet or others may be tunneled through the MOST network. For this purpose alternate network type source and sink function blocks have to be specified. A possible alternate network Bridge device would contain both function blocks. Beside this, the device would contain an alternate network Application. The alternate network Application's manager would scan the inventive network for alternate sinks and sources and try to connect it's local source to the alternate sinks and the local sink to the alternate sources. This is more effort than just to broadcast incoming alternate frames, but it offers several advantages: multiple separated and independent alternate networks can be built on a single inventive network. Furthermore a rights management can be added to the system, which regulates al- ternate network tunneling for each alternate network node.

In another embodiment the network is configured to have at least one set of parallel connections.

In a further embodiment of the invention at least one of the connection types unicast, broadcast and groupcast are supported. The sending of application data via messages from a single source 'to a single sink is called unicast. If a source is sending the same .data in N frames to N sinks, this are N unicasts. In a network, where N nodes are connected to each other by unicast,

Cfunicast connections are required, where Cf= ^'- . This number

^{2 •} • . ² 2{N-2)\ increases tremendously with an increasing N. Hundred PCs would al- ^' ready need 4950 connections. A system would run soon into bandwidth limitations if unicast would be used to realize the connections. In case of a broadcast, a source is sending a frame only once. The frame then is received by all connected sinks . A connection request, which is passed from manager to manager can contain a broad- cast address as a sink.

A groupcast is a broadcast to a group of devices. It could be a big advantage, if groups could be built dynamically like this is done in TCP/IP's multicast. A good example of this advantage we get if we imagine a single inventive network, which tunnels two discrete Ethernets. In this case, each Ethernet could build an own group of senders/receivers. To give all Ethernet devices the same group ad- dress wouldn't be enough. Two different group addresses are required to build two groups of Ethernet devices .

Another embodiment comprises a procedure for obtaining group addresses. The assignment of a group address to sources and sinks will be done by the application's managers. Therefore a strategy is needed, how a manager can find a free unused group address. Since a central instance for administration is missing, the managers have to negotiate group addresses by themselves. Therefore a manager, which requires a free group address sends a Group Address Request to the lowest manager in the priority chain. The request contains a group address, which is estimated to be free by the calling manager. This request is passed upwards the priority chain until a manager is reached, which already uses the group address. This manager informs the calling manager, that it's request is rejected. If no manager rejects the Group Address Request, the highest manager in the priority chain confirms the request. Now the group address can be assigned to the sources and sinks by the calling manager (fig. 23) .

6. Release the right to negotiate^' source.and sink access.

Another embodiment of an inventive network comprises means for releasing connections. If an existing connection is released, this ■ might cause a row of decisions, which have to be made up. If the user e.g. was listening music before a phone call came in, music should become hearable again once the phone call is finished. Requests towards disconnecting sources from sinks are:

— If the last connection from a sink to a source is released, the source should stop streaming. Otherwise resources are occupied by sources, even if no user consumes their streams.

— If one of multiple connections between a source and a sink is released, the other connections should stay.

— Once a connection is released from a manager, other managers should be informed to be able to negotiate, which manager is next to get access to these resources.

In a further embodiment, to release a connection, a manager sends a Connection Release Request to the highest prioritized manager. From there it is passed from device manger to manager down the priority chain. If a manager plans to take over a sink or a source out of this connection it marks this in the Connection Release Request. Once marked, a lower prioritized manager knows, that it will not get access to the resource. If a listed connection is still used by another application, it's manager marks that as well. The manager with the lowest priority passes the Connection Release Request back to the requestor. All resources, which are not marked for further use, are de-allocated by the manager.

In a further embodiment means for stopping applications are provided. A scenario would be that a user wants to stop all audio sinks from playing music. There might be several audio selection managers spread over different rooms, which connected sources to amplifiers. To make it possible that a user, a manager or any other process or device can switch off applications, at least one manager is provided, which exposes an interface, over which it can be told ■ to return to the state, the application had/ after the' system has been started up. By this an application can be built, which itself controls groups of applications. Over this interface also an argument should be passed, which, describes, which type of applications shall return to startup status. Examples for application types are: - Multimedia (Amplifiers & Speakers, TVs, DVD, CD, STP, etc.)

— Communication (Phone, Intercom, LAN, Internet, etc.)

— House technique (Heaters, Lights, etc.)

— Alarm Systems

In a further embodiment means for garbage collection are provided. It might happen, that an application does not de-allocate unused resources. A reason could be a software bug or that a device has been unplugged suddenly, without having the chance to release used resources. In smaller systems a user probably wouldn't recognize that, because once the resource is used and then released by another application the resource leak is eliminated. Thus no garbage collection has to be done in smaller systems at all. In big systems, having many resources, numerous resource leaks could lead to bandwidth limitations. Thus a garbage collector is provided to increase the overall system stability. It comprises a garbage collect application. This garbage collect application's manager preferably has the lowest possible priority. It from time to time sends a Connection Release Request, which contains all connected resources to the highest prioritized manager. If there is still an application, which uses the resource, it's manager will mark it as "still used" in the Connection Release Request. If a resource is not used anymore, the garbage collection manager can safely release the resource.

In another embodiment default priority levels for managers are as- signed by the device manufacturers to defined applications to manage standard device interdependency. Preferably all manufacturers would assign the same group of applications the same priority for their managers. So all DVD players would have the same priority. Exemplary priorities would be:

Fire Alarm System 99

Negotiation administrator 90 Profiler 70

Phone 60 Intercom 50

A/V Selection 20

If such priority levels are assigned, small home networks usually would not require any manual configuration. Middle-sized systems could be configured by HMI, while large networks could be configured by specialists during installation and at run-time. If one or more managers have the same priority level, they are sorted by their node position. If at one device, more than one manager exists with the same priority level, they are sorted by their instance ID (fig. 9) .

A network according to the inventive concept can be very simple. It can consist of only a few devices like a TV, a DVD player or a light switch and Light actuator (relay, electronic switch) . This permits setting up a network with very small initial costs. Later the network can be upgraded to a very complex network connecting all devices in a house. Furthermore an inventive network can be used in offices, plants, hospitals, cars, aircrafts, boats and any combinations thereof. It even permits connecting different networks together like the network from a car together with the network of a house.

In a further embodiment at least one human machine interface (HMI) is provided. HMIs are accessed by applications which are delivered within the devices.

In another embodiment the HMI comprises at least one display. Such a display can be treated as a sink. Compared to a speaker it consumes graphical data. As other sinks, the display does not need a special logic. It just has to offer an interface or a function block, which allows to pass delivered data.

According to the multitude of multimedia applications we know today, depending on the application, graphical data will be passed in very different formats: • Video Streams in MPEGl/2/4, Windows WMV, etc.

• Pictures in BMP, GIF, JPEG, PNG, etc.

• Script based data like HTML, Java, Macromedia Flash, etc.

• Command based data (e.g. draw a circle, fill circle with color, etc.)

Even a mix of formats has to be foreseen. The Device model is invariant towards new graphical formats .

Regarding these formats, it is obvious, that different formats need different delivery paths. For example graphical data, which may be delivered only once, like HTML. This kind of graphical data will be transmitted over the network's asynchronous channel. Compared to that a video stream has to be delivered continuously. Thus a synchronous or an isochronous channel is an optimal delivery path. In a further embodiment the HMI comprises at least one interaction control. Interaction controls allow the user to interact with devices on the network. They may comprise at least one of a Button, a Wheel, a Wheel knob, a Ribbon Controller, a Mouse, a Keyboard, a 5 Touch Panel, a Remote Control, a Voice input. Some of these interaction controls might be bound to certain functionalities, like the increment/decrement buttons at a radiators thermostat, the audio shuttle's buttons, etc. Other ones like the buttons of a graphical display will change their meanings, according to the display's con- 10 tent.

Basically the interaction controls can be divided into three groups :

1. Hardware related, like the eject button of a DVD Player. The •15_.-■^•.;^• meaning of these interaction controls -are unchangeable. Even if ^• they can cause changes in the system, which might lead via notifications to a change of one ore more displays, they are not addressable via the inventive network. Therefore they can be ignored for any further considerations .

20 2. Function related. For example a little device, which consists only an increment/decrement button may be distributed all over the house. Aside the radiator, to control the temperature, aside the lights' switches to control brightness, etc. Each time, one ¹ of the buttons is pressed, the same functionality is called. It 25 has been configured once and does not change over a long period. A speech command is another good example. It is configured once and stays for a long period. It might be changed if the owner of the house changes, but than again it will stay stable for quite a while.

30 3. Context related. The meaning of the interaction control is changing quickly over the time. It is depending on the current context, e.g. of the according display. There might be cases where a button doesn't cause an action at all.

The model for these devices must be independent of the type and 35 number of interaction controls. HMIs may have various combinations of displays and interaction controls. Examples are:

- A HMI, which has only interaction controls

- A HMI, which is just a display — A HMI, which is composed of a display and a set of interaction controls

A HMI will be used by different applications to become visible. During that usage, the HMI is representing the application. HMI may represent applications as described below:

Device based - this is used in devices, which won't share their display and controls with other applications found in the network. An example could be a network radio device. On a simple display/ an audio source can be selected. ^'This could e.g. be a file^" form^' a media server's content. The HMI is^' completely bound to the device's application. No other application can connect to the HMI to interact with the user. The application using the display scans the network for available resource, which can be used by it.

Another example is an application running on a PC, which does exactly the same as the device network radio. In this case, the application uses the PC's display and interaction controls, without sharing these resources with other applications found in the net- work.

Since device based HMIs are not visible to the network they are not relevant for the system's Plug & Play behavior. Thus they can be neglected for further considerations. Such device based HMI 's con- tain no function block for their HMI.

Command based - within the command based strategy, the application, which wants to be represented, uses commands. These commands are mainly sent from the application to the HMI, but also the other way round. Commands are used to — Query the displays capabilities (its graphical, resolution, color depth, number of function keys, etc.)

— Request the display to perform graphical operations (render text, draw a circle, draw a line, etc.) - Get interaction results (user pressed function button, user clicked at a position, etc.)

GDI, XWindows or MOST's automotive function block "graphical display" are typical command based representations .

Descriptor based - within this strategy, an application delivers a descriptor to an HMI. This descriptor contains information about the application's menu and the state variables, which can be changed within certain ranges . The descriptor does not give any concrete information, how the graphical representation at the dis- play has to look like. It only tells the necessary components, the user will need to control the application in a meaningful way.

A descriptor for an application, which for example allows to select an audio source and to control the volume could look like this:

{ var enum Source range { none, CD, Tuner, iPod } value { Tuner }

var uint Volume range { 0,255 } steps { 1 } value { 80 } }

The visible representation of the descriptor is completely done by the HMI. Typical displays are shown in figures 29, 30 and 31. Even the HMI in fig. 31 is enough to represent the example script. Browser based - the browser based strategy is kind of a mixture of the command based and the descriptor based strategy. Instead of delivering a descriptor, the represented application delivers HTML, JAVA, etc. code. This code contains commands, how the graphical representation has to look like. The HMI is a browser, which interprets the code and tries to render it optimally. The interaction is also regulated by the code. If the HTML e.g. contains a button, which is pressed at the HMI, this causes a HTTP request from the HMI to the represented application. Examples for standards using this strategy are UPnP and MHP. Instead of HTML, JAVA and HTTP other mechanisms could be used.

The following table compares the previous explained strategies .

In another embodiment each network enabled HMI provides at least a function block for descriptor based representation. As shown above, there might be many different HMI devices, which offer different abilities . Keeping the requirement that beside graphical HMIs also HMIs without display and alphanumeric HMIs shall be supported, and taking into account that command based representation might be to complex for simple devices, the descriptor based representation should be supported by each HMI. This will lead to a minimum of concordance between all HMIs and applications can become represented at each HMI. On the other hand side, each manager will need the corresponding functions within it's function block for receiving the HMI 's interaction events (fig. 32).

Use cases in which HMIs are involved, divided by actuators are:

User at the HMI

- Select an application — Walk through the applications menu

- Change application's parameters/properties

- Call application's methods

Application - Popup at one or more displays caused by events (e.g. a phone/intercom call is arriving)

- Render to one or more displays

Most of the items listed above concern the access to a HMI. As al- ready mentioned, a HMI might have several sinks to which sources can be connected. A DVD player could be such a source. Beside this, each application within the network is a possible source, if it wants to offer the user the possibility of interaction to control the application. Thus, also applications need to be sources as well (fig. 34) . There might be a competition between several applications to display something. In case of a simple display, which does not support windows, if one application connects to the display, another application has to be disconnected. To organize this competition the same mechanism as for any other sink are used (fig. 35) .

In another embodiment, to enable the system to support complex profiling and rights administration, a manager, which gets a connection request from another manager to a HMI can change either the connection request or the descriptor. These changes have to stay in certain borders. As an example, it can be cut down, ranges of values can be diminished, or variables can be removed, (fig. 36) .

In another embodiment a HMI provides its own application. Usually a HMI device, which has a display will offer the user a menu, which lists all available applications. The user then can select one of' them for interaction. In our terms, a HMI is composed of one ore more sinks for graphical data and interaction. By definition it does not need to have an own application's manager. Thus we can imagine circumstances, that no application's manager wants to connect to the HMI. To cover this situation, the HMI device should bring along it's own manager. If no other manager is connected to the HMI, it connects and offers the user e.g. a menu over all available application's managers. If the user selects one, the HMI 's manager advises the selected manager to connect to the HMI (fig. 37, 38) .

In a further embodiment at least one HMI being capable of rendering video, graphics etc. provides additional function blocks besides the function block, which accepts a representation descriptor. If an application wants to render video, it will scan the network for HMIs with the corresponding decoder function block. If found it connects a source to that sink. The same procedure is done for other formats. This strategy keeps an inventive network open for future formats (fig. 39) . In case that a HMI has interaction controllers, events occurring though the user's input have to be announced to the application, which is currently connected to the HMI. How this communication between a HMI 's sink and the connected application looks in detail will very much depend on the format or in other words on the type of function block, the sink is. A typical video sink will probably have no interaction at all. A command based sink might send events like "Mouse Move", "Mouse Click", etc. These details will all be clarified in the target specifications of those function blocks. The descriptor based representation should be supported by all HMIs and all applications.

In the example script below, an application, offers two variables, the "Source" and the "Volume". The HMIs can read from the script in which borders those variables can be changed.

var enum Source range { none, CD, Tuner, iPod } value { Tuner }

var uint Volume range { 0,255 } steps { 1 } value { 80 }

}

How the user interaction is taking place is now completely done by the HMI device. There could be buttons, wheels, a speech detection, etc. Once the user changed a variable, the HMI calls the connected application, telling the variable and it's new value.

A further improvement is, to have a MAC Address within each network interface controller chip. In this document the terms "network" and "bus" are used as equivalents .

The term "device" refers to any kind of electronic device connected 5 to the network like a TV, a DVD player, a light switch or a Light actuator. In the object oriented model the term device is also used for a function block of a device or its source or sink. This is because several function blocks can be contained in a single device.

10 The term "application" means software being implemented on a device. An application may communicate with an/or control any other device or application.

The term "MOST" refers to the MOST®-standard as defined by the MOST 15 • cooperation. in. the "MOST Specification" revision 2.4 dated 05/2005, which is included herein by reference.

A "function block" is a functional entity on the application level within a device. A radio device may contain the function blocks 20 tuner, amplifier and CD player. There may be further function blocks for special purposes like network connectivity or diagnosis. Each function block contains a number of single functions. For example, a CD player has functions like Play, Stop, Eject and Time ⁾ played. To make a function accessible from outside, the function 25 block provides a function interface, which represents the interface between the function in a function block and its usage in another function block.

The term "source" relates to a source of data, preferably synchro- 30 nous data, it is normally represented by a function block.

The term "sink" relates to a sink of data, preferably synchronous data, it is normally represented by a function block.

35 The term "resource" refers to an abstract description of the network. It comprises sources, sinks and network bandwidth. 5

PAGE INTENTIONALLY LEFT BLANK

Description of drawings

The invention will be described in the following by exemplary embodiments, without any restriction of the general inventive idea, with reference to the drawings wherein:

Fig. 1 illustrates a typical application of a network according to the invention.

Fig. 2 illustrates some typical network topologies Fig. 3 shows a manager (management logic) scanning the network. Fig. 4 shows a manager sending control messages to some of the network's sources and sinks. Fig. 5 shows connected sources and sinks. Fig. 6 shows an example of an audio shuttle. Fig. 7 shows a more complex network, where a group of managers are controlling several sources and sinks.

Fig. 8 shows the ■ previous model with assigned priorities.^' Fig. 9 shows a configuration with two possibly conflicting audio shuttles . Fig. 10 shows a configuration with two audio shuttles and unique priorities . Fig. 11 shows the process of getting the right to negotiate source and sink access.

Fig. 12 shows an exemplary connection request procedure. Fig. 13 shows a request which is modified by a profiler.

Fig. 14 shows the model of a system with a speech recognition software and a microphone .

Fig. 15 shows the model of fig. 14 together with a virtual sink. Fig. 16 shows a scenario with a source which only can be connected to a single sink.

Fig. 17 shows a scenario of fig. 16 with a new link Fig. 18 shows a point to point connection Fig. 19 shows a point to multi point connection Fig. 20 shows a multi point to point connection Fig. 22 shows a parallel connection between a tuner and a speaker Fig. 23 shows how group addresses for groupcasts are obtained Fig. 24 shows freeing of resources Fig. 25 shows alternate freeing of resources Fig. 26 shows a first strategy for freeing spread resources Fig. 27 shows an improved strategy for freeing spread resources Fig. 28 shows display receiving graphical data via different paths Fig. 29 shows alphanumerical representation of data in a display Fig. 30 shows graphical representation of data in a display Fig. 31 shows a simple HMI without display Fig. 32 shows examples of differently equipped HMIs Fig. 33 shows dataflow between manager and a descriptor based HMI Fig. 34 shows a manager accessing a HMI Fig. 35 shows managers in competition for a HMI

Fig. 36 shows change of a Descriptor during requesting a connection to a HMI Fig-..37 shows a HMI ' s manager to select ^• Intercom' s manager for interaction

Fig. 38 shows an Intercom's manager connected to HMI Fig. 39 shows a HMI with multiple sinks Fig. 40 shows a network with amplifier and passive speakers Fig. 41 shows the model of a network with amplifier and passive speakers

Fig. 42 shows a network with amplifier, passive speakers and HMI Fig. 43 shows the model of a network with amplifier, passive speakers and HMI Fig. 44 shows a network with active speakers

Fig. 45 shows the model of a network with active speakers

Fig. 46 shows a network with added microphones

Fig. 47 shows the model of a network with added microphones

Fig. 47 shows how the insertion of a device can change the rela- tionship between devices.

Fig. 1 illustrates a typical application of a network according to the invention. The house 400 comprises several rooms, each being equipped with at least a speaker 411 and a microphone 410. In the Garage 401 further means like a wireless bridge for MOST 413 for communications with the car 412 are provided. Therefore the house's network is preferably compatible with the car's network system like MOST.

In the Heater Room 402, the heater 415 and the air conditioning 414 system's device controllers are connected to the network. At the displays distributed over the house, information can be retrieved like current temperatures, the energy consumption, how long the oil tank will still last, etc. The devices can also be remote controlled. They can be switched on and off, temperatures can be set and so on. In the Server Room 403 there is a PC located, which acts as the house's server 416. It has connections to the Internet (WWW) and to the telephone network (ISDN) . In combination with the room's microphones and speakers phone calls can be made everywhere ^' in the house. The general phone book is managed by the server- as well. Naturally all > other PCs" and Laptops in the house can surf via the . server in the Internet. The server holds an audio file collection and acts as audiσ player in the network. It also delivers a selection -of the audio files to the car's audio system. During the night, the server is assumed to be switched off by a hardware timer. Since the network according to the invention does not need a central PC, the remaining devices continue working properly. At the front door 422, a network intercom is installed. It is composed of a camera 421 a microphone a speaker and a bell button.

During working in the kitchen 405 an audio stream can be heard by using the MOST Audio Shuttle 420. Of course we also can make phone calls, talk to persons in other rooms, etc.

In the living room 404, we find a common TV 417. It is connected to a network HMI to TV Box, which is delivered with a remote control.

Network HMI to TV makes a common TV to a full network HMI. All available video streams can be seen while controlling the whole network System via comfortable menus. If a source is selected, which contains audio the amplifier is used instead of the TV's speakers .

A graphical network HMI can visualize any graphical content via the TV screen. Video can be displayed full screen or in a window. The

Laptop 418 is connected via the network WLAN Bridge 419 to the net- work. It could also act as network HMI. It is of course connected to the Internet via the server.

The bedroom 407 is equipped with a TV 424. It can be directly plugged into the network ring and decode all available video streams. It acts also as network HMI and offers e.g. a menu, which allows us to set an alarm, which will awake the user in the morning.

The bathroom 406 has beside the common intercom devices microphone and speaker a waterproof flat panel display 423, which is embedded into the wall. Like the bedroom's TV this is a network HMI, which gives the optimum connection to the overall functionality, but it is build by a different manufacturer. Instead of a remote control, this display is controlled by a touch panel. The nursery 408 has an old TV 425 and a network HMI to TV, which has during special hours access to some of the offered TV stations. Other stations cannot be seen. A game console (PS2) is connected to the network HMI to TV. Also a camera 426 is provided. ^• In the Hobby Room 409 there are a keyboard (piano) 428, a sampler and some synthesizers (moog) . All those devices are connected via a network Audio/MIDI Bridge. The PC 427 in the room acts as multi track recorder, audio mixer and sequencer. It is. connected via a network PCI board. Legacy music equipment is connected via an audio mixer, which offers a network interface. Other musicians may bring their own instruments and connect them to the network. Thus the number of devices changes dynamically. Full Plug and Play functionality is required.

Figure 2 illustrates some typical network topologies which could be used together with the invention, although the invention is not limited to these topologies. To get a smooth working system, preferably a sub ring or subnet is provided in each room. Then the distortion caused by plugging/unplugging is only hearable in the room, where this is done. Other rooms are not affected. In a Ring Topology (left) several sub rings SR consisting of nodes (hatched) are connected via a Repeater to a central ring. In the Star Topology (center) , the sub rings are connected to a central HUB. The ring topology and the star topology are nearly the same. In the star topology, the ring topology's repeaters are all tied together in a single device, the HUB. In a Daisy Chain (right), each node N has two in/out pairs. The first and last nodes of a chain terminate respectively close the ring. All topologies can be combined according to the local needs . To enhance the network performance and size, subrings or subnets may be interconnected by switches .

Figure 3 shows in an object orientated model a manager (management logic) 150 scanning the network. It contacts each source 101, 102, 103 of N sources and each sink 110, 111, 112 of M sinks and retrieves a plurality of information. On basis of this information a manager decides, which sources and sinks will be relevant for fur- ther-work. An application could do the scanning e.g. once at startup time, each time the number of nodes in the network changed, or in regular or random intervals. In any case, a manager is at any time allowed, to query information from a source or a sink.

Figure 4 shows a manager 150 sending control messages to the network's source_2 102, sink_l 110 and sink_2 111, which lead to a state change of these sources and sinks.

Figure 5 shows source_2 102 connected to sink_l 110 and sink_2 111. When at least one sink is connected to at least one source, data can be transmitted. This could not only be synchronous data, like audio or video streams, but any other type of data. A good example for asynchronous data transmission could be an Ethernet connection between two PCs. Specifically MOST connections are quite different from other connections e.g. a TCP connection. For example, on MOST transmission is connectionless, which means that on the network layer the source does not recognize if the sink disappears and vice versa. Thus each manager is responsible for his own connections. A manager must not start a source streaming without having a sink to consume the stream. Also a manager must not stop a source stream- ing, if there is still a sink connected. If there is neither a source nor a sink, no data is transmitted over the network.

Figure 6 shows an example of an audio shuttle. Via the audio shut- tie's buttons, the user controls two applications: 1. Selecting a source for listening music, 2. Using the intercom. For each of both applications, a manager is provided. The managers Audio source selection 160 and intercom 162 control the available sources Micro_In (microphone) 120 and Aux__In (auxiliary input) 122, and the sinks speaker 130 and Aux_0ut 132. According to the user's selection, sources and sinks will be connected. In the figures managers have a prefix 'M' before their names.

Figure 7 shows schematically a more complex network comprising dif- - ferent devices-¹100 having sources and sinks -like speaker 13.0/ mi- ^{■ ■} crophone 120, Auxin 122 (auxiliary source input), camera 124, HMI 139 (Human Machine Interface), tuner 125. In between a group of managers 150 are controlling these sources and. sinks. These managers comprise managers for audio source selection 160, Intercom 162, Phone 165, home automation 166 and AV source selection 164. Furthermore a profiler 171 and a negotiation administrator 170 are provided.

Figure 8 shows a similar model like the previous one with assigned priorities. A first step to regulate the switching of streams is the introduction of priorities. If a stream is consumed at a sink and another stream arrives with a higher priority, the stream is switched or mixed in. If the priority is smaller, the arriving stream is ignored. If e.g. the person in the bath wouldn't like to be disturbed anymore, he could select the highest priority for the application Music.

Priorities could also handle conflicts, which result from a lack of resources, if there e.g. isn't enough bandwidth to transmit a phone call, etc. If each manager in a house would connect sources with sinks without informing other managers, it might end up in chaos. On the one hand a high level of automation is required. So the music may start automatically to play if a new CD is inserted into the CD player. On the other hand, this automation could lead to conflicts. So the phone call might disappear, if the CD is changed. To prevent this, 5 a structured access to the sources and sinks is required. This is done by assigning priorities. The managers for intercom 162 and phone 165 have the highest priority of all managers. Below is the audio source selection manager 160. Below this is the HMI manager 167. All devices themselves, like speaker 130, microphone 120, 10 Auxin 122, camera 124, HMI 139 and a graphical display 139 are on a common priority level further below the managers . On top of the managers are the negotiation administrator 170 and below this the profiler 171.

15 Figure' 9.shows "a configuration with two possibly conflicting audio shuttles.- There are manager intercom_l 162 and manager intercom_2 163 at the same level^' on top of the managers Au- dio_source_selection_l 160 and audio_source_selection_2 161. The only indefiniteness in this model comes from the fact that the ex-

20 istence of managers with the same priority level is allowed. This can be fixed by an additional rule: If one or more managers have the same priority level, they are sorted by their node position. If at one node, more than one manager exists with the same priority

^! level, they are sorted by their instance ID.

25

Figure 10 shows a configuration with two audio shuttles and unique priorities derived from the previous configuration. Adjustment is done by setting the priority level 180 of the managers Intercom_l 162 above Intercom_2 163 and Audio_Selection_l 160 (audio selection

30 is equivalent to audio source selection) above Audio_Selection_2

161 maintaining the basic order of intercoms being above audio selections. Now the previous pyramid structure has been converted to a linear chain of priorities.

35 Figure 11 shows the process of getting the right to negotiate source and sink access . The managers show are arranged from left to right with increasing priority. In a first step manager_2 151 requests 181 the right to negotiate from the negotiation administrator, which is comprised in manager_4 154, the manager with the highest priority. This is then confirmed 182 by the negotiation ad- rαinistrator, manager_4 154.

Figure 12 shows the connection request procedure of the previous example with two Audio Shuttles in a house. If the application's manager Audio_Selection_l 160 wants to establish a connection be- tween Aux_In_2 123 and Speaker_l 130, a request 181 is made to the manager Intercom_2 163, from there a request 181 is made to the manager Intercom_l 162 and from there a confirmation is sent back to the manager Audio_Selection__l 160. If there is an open intercom connection, managers Intercom_l or Intercom_2 could refuse the in- coming connection request. Thus an intercom connection always stays undisturbed from the Audio Source Selection manager. In the example above, no intercom connection is open and the request is positively passed back to the calling manager. Now the manager can cause the Aux_In_2 source 123 to allocate bandwidth and to start streaming. Once that is done, the speaker is called to consume the stream.

Figure 13 shows a request which is modified by a profiler. Due to passing a connection request from manager to manager, a higher lev- eled manager has the possibility to modify a request. Here the man- ager audio source selection 160 sends a connection request 181 to the profiler 171. Here the connections CD to speaker left 183, CD to speaker right 184, CD to subwoofer 185 are requested. If the Profiler wants to prohibit the use of the subwoofer during the evening hours, it simply removes the subwoofer from incoming connec- tion requests. The part, in which the connection of the other speakers is handled stays untouched. It therefore returns a confirmation message 182 granting the connections CD to speaker left 186, CD to speaker right 187. This feature could also be used, to route a source over additional applications, before passing it to the sink. An audio equalizer could e.g. be chained in. Figure 14 shows the model of a system with a PC connected running a software package for speech recognition. The speech recognition uses a microphone in a room. Since there is no sink in the system, the speech recognition manager 168 cannot connect the microphone 120 to anything. This problem is solved by the speech recognition software 179 by exporting the function block Amplifier to the system, a typical function block of a sink. This virtual Amplifier 137 now can be connected to the microphone as shown in figure 15. If another application's manager than the speech recognition manager tries to connect the device to anything, it can refuse this request. So this virtual device cannot interfere with other applications. By the same way virtual sources may be generated.

Figure 16 shows a scenario with a source 101 which only can be con- - ^•■^•nected'to a single sink. This source 101 has been connected to the active sink_l 110 in the past by an unknown manager. If now another manager 150 connects this -source to another sink (here Sink_2 111) , as shown in figure 17, the primary sink_l 110, which is still in an active state does not get any more (valid) data from the source 101. The manager 150 does not know about Sink_l, since it is not part of it's application. Thus Sink_l is not informed to stop consuming the data from the source before the connection to Sink_2 is realized. If Sink_l is an Amplifier, random noise could become hearable . Such effects can only occur if a source or a sink is al- ready in use and this source or sink does not support multiple connections. In this case a manager has to inform all other managers before it establishes a connection. Then the manager, which owns this critical connection has the chance to disconnect it. Later, when the manager is informed, that the resource has been released again, it might try to connect again, by sending a connection request.

Figures 18 - 21 show different types of connections between source (s) and sink(s) which can be used for synchronous transport. In fig. 18 a connection with source_l 101, which allocated a synchronous channel and stream on that channel connected to sink 1 111, which consumes the stream is shown. More than one synchronous connection can have the same source as shown in fig. 19. In this case all sinks from sink_l 110 to the m-th sink_M 112 consume the same stream, which is provided from the source. This could be the case if multiple TVs in a house show the same video channel. Finally one sink, here shown as sink_l 110 might consume several data streams from source_l 101 to the n-th source_N 103, like a amplifier, which mixes two incoming audio streams to one hearable. Similar types of connections can be used for asynchronous transport. In addition N-to-M connections can be used as shown in fig. 21. Here some of the n sources are connected to some of the M sinks. There may be exceptions, like applications using Peer-To-Peer protocols which require a one to one relation between a source and a sink.

In Figure 22 a parallel connection between a tuner 125 and' a speaker 130 is shown. In an exemplary sleeping room there are the application alarm clock and the application audio selector. In' the morning the alarm clock manager 169 connects the tuner source 125 with the speaker 130 at the set alarm time. A typical case may be that the user awakes before the alarm starts and selects the radio using the audio selector. A few minutes later the alarm tries to start. It will send a connection request up to higher prioritized managers. If none insists, the connection is granted. The tuner is requested to allocate a synchronous channel and to start streaming. The speaker is requested to consume the stream. From a logical point of view, there now are two parallel connections (straight lines) between the tuner and the speaker. The dotted lines symbolize the communication between managers and source and sink for setting up or releasing connections. In any case, when the alarm clock requests the tuner to start streaming, it should return, that it is doing so already. The same should apply for the speaker. In case of the alarm clock, the manager could decide, that it's job to awake the user is therewith done. In other cases it might be useful for a manager to address this logical connection like if the connection has just been switched. Since this finally depends on the application itself, parallel connections should be supported. If parallel connections are combined with 1-to-N and N-to-1 connections, very complex connection scenarios can occur.

Figure 23 shows how group addresses for groupcasts are obtained. manager_3 requests 190 a free group address starting with the lowest priority manager, manager__l in the priority chain. Since none of the managers rejects the request, it is confirmed 189 by man- ager_4, which is the highest manager in the priority chain to man- ager_3. To prevent false addressing, a device should not have as- signed any group address after startup. If a manager closes a connection, the involved devices should be removed from the corresponding group. The above algorithm also works, if devices can be members in more than one group. In the figures 23 to 27 the priority of the managers is increasing from left to right. ^■ . ^• -, . . ^{■ ■}

Figure 24 shows how resources can be freed. In this example, man- ager_3 requests 191 manag^'er_l, to free resources. Since Manager_l allocates these resources, it frees them and confirms 189 the availability back to Manager_l, which now can establish the planned connection. If a manager, which has been requested to free network resources doesn't allocate those resources, it simply passes the request further upwards the priority chain (Fig. 25) In this example Manager_l forwards 192 the freeing request to Manager_2. Man- ager_2 frees and confirms 189 to Manager_3.

Figure 26 shows a first strategy for freeing spread resources. Man- ager_3 153 requests to free a network resource. Manager_l 151 allocates 20% of the requested resource and frees it. The remaining request is forwarded 192 to Manager_2. Since Manager_2 does not allo- cate anything of this resource, it forwards 192 the request upwards. Since there is still not enough of the requested network resource, Manager_3 fails to start it's application. Thus Manager_l has freed the allocated resources unnecessarily.

Figure 27 shows an improved strategy for freeing spread resources. Manager_3 requests a network resource from Manager_l . Manager_l only holds 20% of this resource and frees it, by releasing it's connections. The remaining 80% it requests from Manager_2 by forwarding 192 the changed Freeing Request. Manager (2) would have 100% of the requested resource. To get the remaining 80% it has to re- lease all it's connections. Then it confirms to Manager_3. In best case Manager_l would have continued undisturbed, since it would have been enough, if Manager_2 would have given it's resources to Manager_3.

Figure 28 shows a display receiving graphical data via different paths. The exemplary data frame 193 received from the network contains two types of information for the display:

— A graphical command 196 to render a circle 188. A graphical command is transmitted only once in a packet 194. Therefore graphi- cal commands will usually consume only a few bytes on the network.

- Video data is transmitted in a compressed stream 197, like MPEG2. A synchronous channel is used for transmission. With each data frame 195 a portion of the stream is received. The stream is de- coded by the display's video decoder and rendered to the according video port. In case of an embedded solution, the decoder could be a chip. If a PC is used as a display, a software decoder could be used.

Figure 29 shows alphanumerical representation of data in a display. An alphanumeric HMI can create an alphanumeric representation out of a descriptor, showing a simple menu and the values in form of text and numbers. The interaction could be done using some buttons, which are located underneath the HMI 's display. In this example the user can select from the sources: none, which means that no source is connected, CD player, Tuner and iPod. Additionally the volume can be set in form of two digit number.

Figure 30 shows graphical representation of data in a display. A graphical display could create a more complex representation, where the volume or other parameters could be changed by a slider con- trol . In this case the interaction could be done by a mouse or a touch panel .

Figure 31 shows a simple HMI without display. This HMI has only two buttons with each an arrow up and an arrow down and two other buttons, one with a '+' and the othe r with a '-^x sign. Even a HMI without a display, which comprises only some buttons, would still be enough to select an audio source and to set the volume.

Figure 32 shows examples of differently equipped HMIs. Each HMI has at least a descriptor 200. Some very simple HMIs 220 like remote controls, alphanumerical HMIs or sensing devices only need such a descriptor. Other HMIs 221 like Television sets (TV) or set top boxes (STB) would have an additional video sink 201. Mobile phones or PDAs might ^•• have a additional script sink 202 and a picture .-sink 203 in addition to their descriptor. PCs, high end STBs or game consoles 223 may have additional video sinks/sources 201 and command sinks/sources 204.

Figure 33 shows dataflow between a manager and a descriptor based HMI. A manager 150 can connect 206 to a descriptor based HMI 205. This connection will be confirmed 207 by the HMI. Then the manager delivers a descriptor 208 to the HMI. When the HMI starts representing the descriptor and the HMI or a user interacts, the accord- ing events 209 are sent to the manager.

Figure 34 shows a manager 150 accessing a HMI 139. A device manger is also a possible source, if it wants to offer the user the possibility of interaction to control the manager's application.

Figure 35 shows two managers in competition for a HMI. Manager_l 151 has a lower priority level than manager_2 152. If manager_l requests to connect to the HMI 139 it has to make a connection request 192 to manager_2 (fig. 35a) . Once the request is confirmed 206, manager_l connects (fig. 35b) . This connection procedure ensures, that an application with a low priority level only gets ac- cess to the display, if no more important application needs the HMI currently.

If a manager has function related HMIs, it will connect to them during system startup. Which HMIs are related, is part of the managers' configuration. This configuration has to be done at installation time.

Figure 36 shows change of a Descriptor during requesting a connec- tion to a HMI. Assuming The owner of a house does not want the children to listen music with a higher volume than 80% of the amplifier's maximum power. Thus he configures his profiler application, which runs on his server. Whenever the AV selector 164 in the children's room connects the HMI, the profiler 171 changes the AV selector's descriptor from- ^{: ■}

{ var enum Source range { none, CD, Tuner, iPod } value { Tuner }

var uint Volume range { 0,255 } steps { 1 } value { 80 }

}

to

{ var enum Source range { none, CD, Tuner, iPod } value { Tuner }

var uint Volume range { 0,204 } steps { 1 } value { 80 }

Now the maximum volume, which can be selected at the children's HMI is 80% of the real possible maximum.

Figure 37 shows the application 167 of HMI 139 to select Intercom 162 for interaction. This is the first of two states. First, the HMI 167 is connected 213 to the HMI 's sinks or sources 141. It offers a menu, from which the user selected the Intercom. So the HMI ' s manager informs the Intercom's manager to connect to the HMI.

Figure 38 shows the second state, where the Intercom's manager is ^■ connected 213 to_. the HMI ' s sinks "^'or sources 141.

Figure 39 shows a HMI with multiple sinks in a STB 126. Descrip- tor_based_HMI 205 accepts 213 representation descriptors, the other, video_sink 140, accepts video stream data 216. In the exam- pie the application AV_select 164 for selecting an AV source 127 is currently connected to the representation sink. To start streaming, it connects 214, 215 the video sink with the video source.

Figure 40 shows a network with amplifiers 255 and passive speakers 250. This network is part of a scenario to demonstrate the inventive concept. It comprises a home which has a high end audio system installed. No other network devices are installed yet, but of course the system should be expandable in the future. There are three differently equipped rooms, one with only a single speaker (Mono) 252, one with two speakers (Stereo) 253 and one room with five speakers (Surround) 254. We assume a multitude of audio sources 251, which might deliver different audio streams in terms of encoding, number of channels, sample width, sample rate, etc. Naturally there are a lot of possible setups to realize such a sys- tern. The most important ones are shown. In the first setup there is an amplifier 255 in each room. To the amplifier, passive speakers are connected via copper wires (straight lines) . The localization of the speakers is done at last during connecting them to the amplifier. The HMI 256 to control the ampli- fier 255 is part of the device. In our interaction model thus the HMI is device based. Now each amplifier scans the network (dashed lies) for active audio streams, which can be decoded. The result of this query is offered the user through the proprietary HMI. Once the user selects one of those streams, the amplifier plays it.

Figure 41 shows the model of a network with amplifier and passive speakers as from the previous figure. There are three amplifiers, Amplifier_l 271 to Amplifier_3 273. The HMI in each amplifier remains invisible to the network since it is device based. Only two function blocks per amplifier are exported. The function; block Audio Selection (Audio Selection_l, Audio Selection_2 , Audio Selec- tion_3 ) is an application's manager. It scans the network for all appropriate sources, which can be connected to the local, sink. The sink is exported to the network by the function block Amplifier (Amplifier_l 271, Amplifier_2 272 , Amplifier_3 273) . As long as no other manager is in the system, which has a higher priority level, the Audio Selection Managers can connect any available source without further considerations.

Figure 42 shows a network with amplifiers 255, passive speakers 250 and HMIs 139. This is the previous setup, but enhanced by one central intercom device 257 and one microphone plus HMI for each room. We assume the HMI is just a button. If pressed, all other rooms are paged.

Figure 43 shows the model of a network with amplifier, passive speakers and HMI as from the previous figure. For each room's microphone there is a function block Microphone (Micro_l 268, Micro_2 269, Micro_3 270) and a function block HMI (HMI_1 260, HMI_2 261. HMI_3 262) . During intercom's installation, the configuration is set up. Three rooms are defined and the according devices are grouped. Each intercom group consists of an amplifier, a microphone and a function related HMI. Whenever the system starts up, the intercom connects itself automatically to each HMI.

Assuming the user is now listening music in one or more rooms and somebody presses an intercom button in one another room, the HMI sends the according notification message. The intercom's manager then tries to connect the paged room's amplifiers to the sender's microphone. Since there is no manager with a higher priority level, this can be done immediately. If a user in one of the paged rooms uses the hardware related HMI at the amplifier during an intercom is open, the amplifier's audio selection manager requests to connect the amplifier to the selected source at the higher priority leveled intercom manager. Since the intercom manager knows, that there is an' open' intercom connection, it refuses the request. Thus intercom stays undisturbed and that is exactly what we wanted.

Figure 44 shows a network with active speakers, based on the previous setup, but with different hardware components. Now active speakers 250 are used. They are connected directly to the network (dashed line) . No copper wiring for analog audio is needed. As HMI there is an independent device 139 in each room. It is composed of an alphanumeric display and a few buttons .

Figure 45 shows the model of a network with active speakers according to the previous figure. The device also contains the invisible software to do the audio selection. During installation, the localization is done at each HMI device. For the audio selection, the relevant speakers and their positions are announced. Since all devices are now network devices there are a lot more function blocks within the system's model. Beside the function blocks for the audio sources, there is one function block amplifier for each speaker. Each HMI device exports two function blocks, one for the HMI and one for the audio selection. Again each audio selection manager scans the network for available devices and offers the result through it's HMI. Depending on the speakers' capabilities, it also offers menu items to set the balance, do the equalization, etc.

Since every audio selection manager only tries to connect to it's device's HMI, there is no competition for the HMIs as sinks.

Figure 46 shows a network based on the previous setup, but with a microphone added to each room. Once the intercom device is installed, the setup utility becomes visible at the already installed display. This happens as follows: By default the priority level of the intercom is higher than the audio selection. Thus the intercom can connect the display whenever it wants. During the intercom's setup, the user is grouping devices to intercom rooms.

Figure 47 shows a model of the network of the previous figure . Each room got the additional function block Microphone. Beside this one manager for the intercom has been added. The connection of sources and sinks is done as in the example before. Since the intercom has a higher priority level, it always can connect whatever it wants. The audio selection manager now has to make a connection request at the intercom manager before connecting. Since the HMI offers also a little display, much more intercom actions are possible, like a room to room connection, the listening in to a room (baby phone) .

List of reference numerals

5 100 Device: (general)

101 Device: Source_l

102 Device: Source_2

103 Device: Source_N

110 Device: Sink_l

10 111 Device: Sink_2

112 Device : Sink_M

120 Device: Microphone_In_l

121 Device: Microphone_In_2

122 Device: Aux_In_l

15 123 Device : Aux_In_2

124 Device: Camera

125 Device : Tuner

126 Device; Set Top Box (STP)

127 Device: Video source

20 130 Device: Speaker_l

131 Device: Speaker_2

132 Device: Aux Out_l

133 Device : Aux Out_2

) 134 Device: Amplifier_l

25 135 Device : Amplifier_2

136 Device: Amplifier_3

137 Device: Virtual_amplifier

138 Device : Graphical_Display

139 Device: HMI

30 140 Device: Video sink

141 Device: HMI sink/source

150 Manager (general)

151 Manager_l

152 Manager_2

35 153 Manager_3

154 Manager_4 160 Manager: Audio_Source_selection_l

161 Manager: Audio_Source_selection_2

162 Manager: Intercom_l

163 Manager: Intercom_2 164 Manager: AV_Source_selection

165 Manager: phone

166 Manager: Home_automation

167 Manager: HMI

168 Manager: Speech_recognition 169 Manager: Alarm clock

170 Negotiation administrator

171 Profiler

179 Speech recognition software

180 Priority level 181 '■ .Request right to negotiate

182 Confirm right to negotiate

183 Request CD to speaker left

184 Request CD to speaker right

185 Request CD to subwoofer 186 Grant CD to speaker left

187 Grant CD to speaker right

188 Graphic representation of a Circle

189 Confirm availability 190 Request group address 191 Release network resource

192 Forward request

193 Data frame

194 Packet data

195 Stream data 196 Draw circle

197 Video stream

198 Display area

199 Image of video stream

200 Descriptor (general) 201 Descriptor video

202 Descriptor script 203 Descriptor picture

204 Descriptor command

205 Descriptor based HMI

206 Connect 207 Confirm connection

208 Pass descriptor

209 Interaction events

210 Forward descriptor

211 Confirm descriptor 212 Interaction Manager-Manager

213 Interaction Manager-Device_l

214 Interaction Manager-Device_2

215 Interaction Manager-Device_3

216 Interaction Device-Device 220 Device Type 1 ■

221 Device Type 2

^' 222 Device Type 3

223 Device Type 4

250 Speaker 251 Audio Sources

252 Room with mono sound

253 Room with stereo sound

254 Room with surround sound 255 Devices Amplifier (Network) 256 Manager: HMI

257 Manager: interconnect

260 Descriptor based HMI_1

261 Descriptor based HMI_2

262 Descriptor based HMI_3 263 Manager: Audio selection_l

264 Manager: Audio selection_2

265 Manager: Audio selection_3

266 Manager: Intercom

267 Devices: External sources 268 Device: Microphone_l

269 Device: Microphone_2 270 Device: Microphone_3

271 Device: Amplifier_l

272 Device: Amplifier_2

273 Device: Amplifier_3

274 Device: Amplifier_4

275 Device: Amplifier_5

276 Device: Amplifier_6

277 Device: Amplifier_7

278 Device: Amplifier_8

362 Application: Intercom

364 Application: AV_Select

365 Application: Phone

367 Application: HMI

400 House

401 Garage

402 Heater room

^• 403 Server room

404 Living room

405 Kitchen

406 Bathroom

407 Bedroom

408 Nursery

409 Hobby room

410 Microphone

411 Speaker

412 Car

413 Wireless bridge

414 Air conditioner

415 Heater

416 Server

417 TV

418 Laptop

419 WLAN Bridge

420 Audio shuttle

421 Camera

422 Front door 423 Flat panel display

424 TV

425 TV

426 Camera

427 PC

428 Keyboard

Claims

Patent Claims

1. Digital network for communication between a plurality of de- vices, comprising

- at least one device having a source for transmitting data on the network, and

- at least one device having a sink for receiving data from the network, - at least one device having an application to communicate with and/or control any other device or application, and data is only transferred from sources to sinks by means of connections between sources and sinks, characterised by at least one application having a manager for management of devices, being configured for

- selecting at least one source and at least one sink to be connected,

- connecting at least one selected source to at least one se- lected sink, all managers having assigned priorities, and at least one manager being configured

- for negotiating with other managers having a higher priority and requesting the right to specifically connect selected sources and sinks, and

- limiting the selection of sources and sinks specifically to those sources and sinks, for which a connection was granted by the other managers before connecting or controlling at least one selected source to at least one selected sink.

2. Digital network according to claim 1, characterised by the manager's priorities being unique to each manager.

3. Digital network according to any one of the preceding claims, characterised by at least one manager being configured for

— querying for available sources and sinks on the network, - retrieving status information from selected devices.

4. Digital network according to any one of the preceding claims, characterised by at least one manager being configured for further limiting its selection according to limited grant of network bandwidth by at least one other manager.

5. Digital network according to any one of the preceding claims, characterised by at least one manager being configured for negotiating with preferably all other managers having a higher priority.

6. Digital network according to any one of the preceding claims, characterised by at least one manager having

— means for identifying the manager having the lowest priority,

— means for identifying the manager having the highest priority, — means for querying all managers in a chain according to their priorities starting with the highest and/or lowest priority and/or the priority of a specified manager,

— means for accessing sinks or sources exclusively after querying all managers having higher priorities to grant access to these sinks or sources.

7. Digital network according to any one of the preceding claims, characterised by at least one negotiation administrator being provided to as- sign the right for connecting selected sources to selected sinks for selected managers, and at least one manager being configured for requesting the right to connect sources and sinks from the at least one negotiation administrator, before connecting or controlling at least one selected source to at 5 least one selected sink, and this manager being further configured to release the right to connect sources and sinks to the at least one negotiation administrator.

8. Digital network according to claim 6, 10 characterised by at least one manager being configured to take over the role of a negotiation administrator, preferably when it has assigned the highest priority in the network.

^~15

9. Digital network according to any one of the preceding claims,. characterised by

^• at least one manager being configured for adding at least one sink and/or source and/or chaining in at least one additional- device upon information received from at least one other man-

20 ager.

10. Digital network according to any one of the preceding claims, characterised by

25 at least one manager being configured for publishing the established connection to lower prioritized mangers after having received grant of a connection or after having connected at least one source and at least one sink.

30 11. Digital network according to any one of the preceding claims, characterised by virtual sources and/or virtual sinks are provided for devices which do not have sources or sinks for being connected by 35 other devices.

12. Digital network according to any one of the preceding claims, characterised by at least one manager being configured for releasing a connec- tion by

- sending a release request to the highest prioritized manager, from where it is passed down to other managers with decreasing priority, and where each device manger marks still required sources and sinks, - de-allocating all not marked sources and sinks.

13. Digital network according to any one of the preceding claims, characterised by at -least . one device having a profiler, which adapts the requests according to previously defined profiles.

14. Digital network according to any one of the preceding claims , characterised by at least one garbage collection manager being provided to release unused connections and said garbage collection manager preferably having the lowest priority in the network and preferably sending connection release requests to all connected resources.

15. Digital network according to any one of the preceding claims , characterised by at least one HMI being provided with descriptor based access.

16. Digital network according to any one of the preceding claims , characterised by at least one means for tunneling frames of a different network type being provided containing function blocks of an alternate network source and an alternate network sink.

17. Digital network according to any one of the preceding claims, characterised by at least one manager being configured for finding a free group address for groupcast by - generating a group address which is estimated to be free,

- requesting this address from other managers with increasing priority,

- • assign the group address to sources and sinks after the manager with the highest priority has confirmed the address, - generate another group address and start again with request-^' ing this from other managers or abort, if any manager has rejected the request.

18. Method for freeing of network resources in a network ac- cording to any of the previous claims, characterised by comprising the steps of

- sending a freeing request by calling manager to the manager with the lowest priority. The freeing request contains a flag, which tells managers not to free any resources, if they can not cover the whole request.

- If a manager can cover the whole request, it frees the requested resources and confirms the availability to the calling manager . - If a manager can not cover the whole request and the *don't free parts"-flag is set, a manager adds the amount it could contribute to a field reserved for this purpose in the Freeing Request. If this "spread resource found" -field reaches 100%, the "don't free parts"-flag is removed and the request is passed back to the manager with the lowest priority. — If the request returns to the calling manager, the subordinate managers do not have the requested amount of the resource to free. Thus the manager has to cancel connecting.

— If a manager gets the Freeing request without the "don't free parts"-flag not set it checks if the "spread resource found"-field minus it's own part if above or equal to 100%. If it is, it passes the request upwards, to a manager with a higher priority, without freeing anything.

— Otherwise it frees it's allocated resources, removes the freed part from the requests amount and passes the request upwards, if it is not completely fulfilled.

19. Manager for Digital networks for communication between a plurality of devices, characterised by the manager having assigned a priority and being configured for

— querying for available sources for transmitting data on the network and sinks sink for receiving data from the network on the network,

— retrieving status information from selected devices,

— selecting at least one source and at least one sink to be connected,

— negotiating with other managers having a higher priority and requesting the right to specifically connect selected sources and sinks, and

— limiting the selection of sources and sinks specifically to those sources and sinks, for which a connection was granted by the other managers - connecting at least one selected source to at least one selected sink.

20. Method for managing network devices in networks for communication between a plurality of devices, characterised by comprising the steps of

— assigning priorities to all managers, wherein the priorities assigned are preferably unique to each manager,

— querying for available sources for transmitting data on the network and sinks sink for receiving data from the network on the network by at least one manager,

— retrieving status information from selected devices by the manager (s) ,

— selecting at least one source and at least one sink to be connected by the manager (s),

— connecting at least one selected source to at least one selected sink,

— negotiating with other managers having a higher priority and . .-.requesting the right to specifically connect selected sources and sinks by the manager (s),

— limiting the selection of sources and sinks specifically to those sources and sinks, for which a connection was granted by the at least one negotiation administrator by the manager (s) , - connecting at least one selected source to at least one selected sink by the manager (s) .

21. Method according to claim 20, characterised by further comprising the steps of

— requesting the right to negotiate with other managers from at least one negotiation administrator, before negotiating with other managers.

22. Method according to any one of claims 20 - 21, characterised by further comprising the steps of releasing unused connections by at least one garbage collection manager, wherein said garbage collection manager prefera- bly has the lowest priority in the network.