US20050165965A1 - Methods for communication in a multi-cluster network, device for connection to a network of clusters and bridge for connecting clusters - Google Patents

Methods for communication in a multi-cluster network, device for connection to a network of clusters and bridge for connecting clusters Download PDF

Info

Publication number
US20050165965A1
US20050165965A1 US10/510,536 US51053604A US2005165965A1 US 20050165965 A1 US20050165965 A1 US 20050165965A1 US 51053604 A US51053604 A US 51053604A US 2005165965 A1 US2005165965 A1 US 2005165965A1
Authority
US
United States
Prior art keywords
portal
bridge
cluster
network
devices
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Abandoned
Application number
US10/510,536
Other languages
English (en)
Inventor
Jean-Baptiste Henry
Guillaume Bichot
Joel Sirot
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Thomson Licensing SAS
Original Assignee
Thomson Licensing SAS
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Thomson Licensing SAS filed Critical Thomson Licensing SAS
Assigned to THOMSON LICENSING S.A. reassignment THOMSON LICENSING S.A. ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: SIROT, JOEL, BICHOT, GUILLAUME, HENRY, JEAN-BAPTISTE
Publication of US20050165965A1 publication Critical patent/US20050165965A1/en
Abandoned legal-status Critical Current

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/40—Bus networks
    • H04L12/40052—High-speed IEEE 1394 serial bus
    • H04L12/40091—Bus bridging
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F13/00—Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
    • G06F13/38—Information transfer, e.g. on bus
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/2803—Home automation networks
    • H04L12/2805—Home Audio Video Interoperability [HAVI] networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/2803—Home automation networks
    • H04L12/2807—Exchanging configuration information on appliance services in a home automation network
    • H04L12/2809—Exchanging configuration information on appliance services in a home automation network indicating that an appliance service is present in a home automation network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/2803—Home automation networks
    • H04L12/283—Processing of data at an internetworking point of a home automation network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/40—Bus networks
    • H04L12/40052—High-speed IEEE 1394 serial bus
    • H04L12/40117—Interconnection of audio or video/imaging devices
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/46—Interconnection of networks
    • H04L12/4604—LAN interconnection over a backbone network, e.g. Internet, Frame Relay
    • H04L12/462—LAN interconnection over a bridge based backbone
    • H04L12/4625—Single bridge functionality, e.g. connection of two networks over a single bridge
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/14—Session management
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/40—Network security protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/329—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the application layer [OSI layer 7]

Definitions

  • the invention concerns methods for communication in a multi-cluster network, for example based on but not limited to HAVi clusters, as well as devices in such a network and bridge devices for connecting clusters.
  • HAVi standing for Home Audio/Video interactive—is currently defined (version 1.1 released on May 15th, 2001) on the IEEE 1394 bus (version of 1995 enhanced by the version of 2000) and consequently inherits the limitations of IEEE 1394.
  • One limitation is the use of a single cluster network.
  • HAVi network is difficult to deploy over an entire house, although a home network should typically connect all devices in a home. It is desirable to connect several distinct HAVi clusters.
  • the present application describes bridge devices and network devices, in particular the software components that are implemented in these devices and their interaction in a multi-cluster environment.
  • the invention concerns a bridge device comprising at least two interfaces for interfacing respective clusters of network devices in a network wherein said bridge device comprises at least two interface portals for connecting clusters, characterized in that the bridge device comprises for each portal a first software component for receiving from an internal client requests for device describing configuration memory data of at least one network device, said first software component being adapted to retrieve device describing data from other devices through a function call of a similar software component in the other devices.
  • the first software component is adapted to retrieve data for a remote cluster device without similar software component through a function call to a similar software component of a bridge device on the path to the remote cluster device.
  • the first software component is adapted to retrieve data for a device without similar software component on the same cluster as itself by issuing a medium dependent request message to the device.
  • the first software component is adapted to maintain at least one of:
  • the first software component is adapted to monitor changes in the device describing data of devices devoid of a first software component on its portals local cluster and to generate corresponding device describing data change events on the clusters connected to other portals of the bridge device.
  • the bridge device further comprises for each portal a second software component for interfacing the portal's other software components of the respective portal with the portal cluster's communication medium, said second software component comprising an application programmable interface of which at least certain methods are globally accessible to software components of other devices of the network, for remotely accessing the communication medium.
  • the globally accessible methods comprise at least one among write, read, lock, enroll, drop, indication.
  • the bridge device further comprises for each portal a third software component for maintaining a list of all devices on all clusters of the network.
  • the third software component is adapted to generate, upon detection of a change on any cluster of the network, a first event informing software components of its portal of the nature of the change.
  • the third software component is adapted to generate a second event for informing the third software components of other portals only of the state of the event-issuing portal's a remote device list.
  • the second event comprises a potentially incomplete list of remote devices compared to the event-issuing portal, i.e. devices reachable through the co-portals of the event-issuing portal.
  • the third software component is adapted to generate a third event for informing the third software components of all devices on the cluster that the hosting portal's remote device list is stable.
  • the third event comprises a complete list of remote devices compared to the event-issuing portal, i.e. devices reachable through the co-portals of the event-issuing portal.
  • each portal comprises a fourth software component for forwarding to co-portals event messages detected on a portal's local cluster.
  • each portal comprises a fifth software component for receiving, on one of the bridge's clusters, a request from a fifth software component of another device, and means for forwarding said request to fifth software elements on its other clusters, with the initial requester's identifier as source address, and for forwarding the non-concatenated responses to this request back to initial requesting device.
  • each portal comprises a fifth software component for receiving, on one of the bridge's clusters, a request from a fifth software component of another device, and means for forwarding said request to fifth software elements on its other clusters, wherein the source address of the forwarding portal is added as a parameter to the forwarded request by the forwarding portal, for receiving and concatenating responses to the forwarded request and for forwarding the concatenated responses to this request back to the initial requesting device.
  • said means for forwarding said request are adapted to use a first message type for forwarding the request to fifth software elements of bridge devices and a second message type for forwarding the request to fifth software elements of non bridge devices, wherein the identifier of the forwarding portal is a parameter in the first message and not in the second message.
  • each portal comprises a fifth software component for receiving, on one of the bridge's clusters, a request from a fifth software component of another device, and means for forwarding said request with the initial requester's identifier as source address to fifth software elements on its other clusters, for intercepting responses to this forwarded request, for concatenating the contents of these responses and for sending a single concatenated response to the initial request back to the initial requesting device.
  • the bridge device comprises means for converting the transport type of packets between the communication mediums of its clusters.
  • each portal comprises a sixth software element for establishing connection segments on local clusters for a connection crossing the bridge upon reception of a connection establishment request from a sixth software element of another device.
  • the sixth software element of a portal is adapted to establish a connection on its local cluster and of informing a next portal of its local cluster to carry out the next segment establishment on the path to a connection end device.
  • Another object of the invention is a device for connection to a cluster in a multi-cluster network, wherein clusters are connected through bridge devices, each bridge device comprising at least two cluster interfaces, wherein each interface is considered as a network device on its respective cluster characterized in that the network device comprise a first software component for receiving from an internal client requests for device describing configuration memory data of at least a second device, said first software component being adapted to retrieve device describing data from the at least one other device through a function call of a similar software component in the at least one device.
  • the first software component is adapted to retrieve data for a remote cluster device without similar software component through a function call to a similar software component of a bridge device on the path to the remote cluster device.
  • the first software component is adapted to retrieve data for a second device without similar software component on the same cluster as itself by issuing a medium dependent request message to the second device.
  • the first software component is adapted to maintain at least one of:
  • the device further comprises a third software component for maintaining a list of all devices on all clusters of the network, wherein said third software component comprises means for retrieving remote device lists from portals connected to its local cluster, and for concatenating the remote device lists with a local cluster device list.
  • the third software component is further adapted to maintain in the network device list an indication of the closest portal on the path for a remote device compared to the device's own local cluster.
  • the device comprises a fifth software component for receiving from a local client, a request for a list of remote software elements and for forwarding said request to fifth software elements of devices of the local cluster only.
  • the device comprises a sixth software element including an application programmable interface for clients of the same device, adapted to receive a request for establishing a connection between a sink device and a source device, said sixth software element being adapted to determine, on the path between the source and the sink device, the portal closest to the source device on the path to the sink device, and for sending an appropriate request to that portal for establishing the connection on its local clusters and for propagating this request to other appropriate portals on the path.
  • a sixth software element including an application programmable interface for clients of the same device, adapted to receive a request for establishing a connection between a sink device and a source device, said sixth software element being adapted to determine, on the path between the source and the sink device, the portal closest to the source device on the path to the sink device, and for sending an appropriate request to that portal for establishing the connection on its local clusters and for propagating this request to other appropriate portals on the path.
  • a portal of a bridge is also a device on its local cluster.
  • Another object of the invention is a method for discovering devices in a network comprising at least two device clusters and at least one bridge, wherein at least two clusters are connected by a bridge, each bridge comprising at least two interface portals for connection to respective clusters, said process comprising the steps of:
  • the method further comprises the step of making a bridge passing to messages destined to a given device if it is on the shortest path to that device.
  • the shortest path is the path with the lowest number of portals to be crossed.
  • Another object of the invention is a method for establishing a connection between a source device and a sink device in a network comprising a plurality of device clusters connected by bridge devices, wherein each bridge device comprises interface portals for connection to clusters, said method being characterized, by the steps of:
  • FIG. 1 is diagram of a multi-cluster HAVi network
  • FIG. 2 is a diagram of a HAVi-HAVi bridge
  • FIG. 3 is a diagram of a network illustrating the different cases of use of the SddManager
  • FIG. 4 is a diagram of a multi-clustered HAVi network showing examples of use of the CMM
  • FIG. 5 is a diagram illustrating the sending of a message through a bridge
  • FIG. 6 is a diagram representing an event posting algorithm
  • FIG. 7 is a diagram representing a traffic improvement for registries
  • FIG. 8 is a diagram representing a request/response algorithm for bridge Registries
  • FIG. 9 is a diagram of a prior art HAVi stream connection model:
  • FIG. 10 is a diagram illustrating multi-clustered stream building
  • FIG. 11 is a diagram of a multi-cluster network illustrating an alternative route for data
  • FIG. 12 is a diagram of the software architecture of a HAVi bridge aware device
  • FIG. 13 is a diagram of a multi-cluster network illustrating the local discovery process
  • FIG. 14 is a diagram of a multi-cluster network illustrating first remote list update on leaves bridges
  • FIG. 15 is a diagram of a multi-cluster network illustrating the bridge network managers interaction
  • FIG. 16 is a diagram illustrating the process for building the Network Manages global list
  • FIG. 17 is a diagram of a multi-cluster network illustrating a client call on the Network Manager
  • FIG. 18 is a diagram of a multi-cluster network illustrating the concept of remote lists
  • FIG. 19 is a diagram illustrating the connection of a new device
  • FIG. 20 is a diagram illustrating the propagation of an updated remote list
  • FIG. 21 is a diagram of the local discovery process in a network with a loop
  • FIG. 22 is a diagram illustrating the process according to which portals request remote lists
  • FIG. 2 is a diagram illustrating the process of portal update with incomplete remote lists
  • FIG. 24 is a diagram illustrating the sending of an incomplete remote list using an event
  • FIG. 25 is a diagram of a network comprising two HAVi clusters and a bridge using a GUID proxy technique.
  • FIG. 25 is an example of a network formed by two HAVi clusters linked by a bridge device.
  • Devices and sub-devices or functions are represented by software elements, called respectively Device Control Modules (DCMs) and Functional Component Modules (FCMs).
  • DCMs Device Control Modules
  • FCMs Functional Component Modules
  • GUID stands for global unique identifier.
  • a GUID uniquely identifies an IEEE 1394 device.
  • the devices on one side of the bridge will not be recognized by devices on the other side, because they are not visible at the IEEE 1394 level.
  • a controller on one side will not be able to use a target on the other side.
  • the bridge device builds representations of the DCMs and FCMs of one side to expose them as DCMs and FCMs on the other side, as proxy elements of the real Software Element they are representing.
  • real DCMs and FCMs are represented with their SEID (Software Element ID).
  • SEID Software Element ID
  • the SEID is the combination of the GUID (an example being indicated at the bottom of each device) and of a number unique inside this device.
  • proxy SEs Software Elements
  • a controlling application can control real target devices behind the bridge through its proxy SEs.
  • the present embodiment of the invention will be based on portals and bridges using GUID proxies.
  • the invention is however not limited to this particular case.
  • HAVi 1.1 is based on IEEE 1394
  • the clusters of the present embodiment may be based on other network technologies, and in particular on Internet Protocol (IP) or wireless technologies (IEEE 802.11, Hiperlan 2 . . . ).
  • IP Internet Protocol
  • this flexibility is achieved—as an example—by the use of the GUID proxy technique.
  • the latest HAVi version available at the priority date of the present application is the version 1.1.
  • HAVi 1.1 does not describe bridges, so if a HAVi 1.1 device is connected to a multi-cluster network, it will not be aware of any bridge.
  • the present application first describes a HAVi bridge device, followed by a description of a HAVi bridge aware device, i.e. a device being able to draw upon the bridge device's resources and to communicate with it. Such a device may be required since the bridge is not transparent to HAVi 1.1 devices.
  • FIG. 1 represents a network comprising three clusters 101 to 103 , interconnected in a serial fashion by two bridges 104 and 105 .
  • Cluster 101 is based on IEEE 1394
  • cluster 102 is based on IP technology
  • cluster 103 is a wireless network based for example on IEEE 802.11.
  • the devices on cluster 102 can for example be HAVi devices, or UPnP devices for which the bridges manage HAVi proxy representations.
  • a principle of the GUID-proxy solution according to the present embodiment is to announce, on a local cluster, the GUIDs of devices that are located outside of the local cluster, so that local HAVi devices gain knowledge of their existence.
  • this device is addressable by a HAVi software element because the Messaging System knows in its internal table to which device it has to send a HAVi message.
  • a HAVi message is sent to a remote device, it's destination address is that of the proxy GUID.
  • the messages from the HAVi middleware and the HAVi applicative modules (DCMs, FCMs, applications) based on a proxied GUID are appropriately passed on by the bridges.
  • FIG. 2 The software architecture of a HAVi-HAVi bridge is depicted in FIG. 2 . It is composed of two portals according to the present embodiment, although more than two portals are possible. Each portal is connected to a HAVi cluster (for example an IEEE 1394-1995 bus) and is an addressable entity on its cluster. A complete HAVi stack runs on the bridge. Whether a HAVi module simulates two instances of itself or whether two separated modules run at the same time for the same functionality is implementation dependent. In FIG. 2 , only one messaging system is represented, although functionally speaking there is one per portal. A Software Element—and the messaging system is a Software Element—is addressed with the GUID of the node it resides in, and each portal possesses its own GUID.
  • a Software Element and the messaging system is a Software Element—is addressed with the GUID of the node it resides in, and each portal possesses its own GUID.
  • the Self Describing Device data is a means for a HAVi device to provide information about itself to other devices (type of device, capability, version etc . . . ).
  • the SDD is part of the configuration rom (which contains other information, such as the GUID) of the IEEE 1394 HAVi device and is read by the other devices using direct IEEE 1394 Read transactions.
  • the software element can access the SDD data of a HAVi device using the Messaging System.
  • an appropriate application specific interface is defined in the HAVi stack.
  • the SddManager is a new system software element that has similarities with the Registry in the sense that it locally handles requests for SDD data and collects responses from distant SddManagers, with the difference that a Registry exists on all devices with intermediate functionality (IAV) and full functionality (FAV), whereas a SddManager is implemented on any bridge aware HAVi device according to the present embodiment.
  • a bridge aware device is of the FAV or IAV type (Full A/V device or Intermediate A/V device).
  • No SddManager is present on a HAVi 1.1 or lower version device. Thus, devices with an SddManager will cohabit on the same cluster with devices devoid of SddManager.
  • a client application or software element in a HAVi device will preferably call its local SddManager for all requests, and the local SddManager will take care of collecting all information (sending query to other SddManagers and/or doing local low-level operations). If no local SddManager is present on the device, then the client will have to obtain the information through other means. In this latter case, the client is running on a HAVi-1.1 device that has no bridge knowledge. It can then access only local IEEE 1394 cluster devices.
  • a client executes the following process to retrieve SDD data: if(local SddManager exists) (301,302,303) call the local SddManager else //(i.e. the device is not a bridge aware device) (304) use local API (e.g. CMM1394) to retrieve the SDD data of the local cluster device // it can be only the local cluster here
  • local API e.g. CMM1394
  • a client application is preferably adapted to function both on a device with an SddManager and on a device without an SddManager.
  • an SddManager caches SDD data information he obtains from events notified by other SddManagers. This allows reducing traffic on the network and reducing response time from an SddManager to a client when a request is made.
  • the caching is thus centralized in the SddManager and has not to be done redundantly by several clients of the same device.
  • the following process is carried out: if(query from a client concerns local data only (i.e. in the same device)) send response else if(remote SddManager exists for the target device to be queried) (301) call the remote SddManager else if(target device is on the local cluster) (303) use local API (e.g. CMM1394) to retrieve the SDD data else //i.e. the target device is not bridge aware and not on the local cluster (302) call the SddManager of the bridge exit portal
  • the SddManager first checks whether the target device for which the SDD data is to be retrieved contains an SddManager and in that case calls the target's SddManager. Else (i.e. the target device does not have an SddManager), it checks whether the target device is on the local cluster and uses a local API such as the Communication Media Manager to retrieve the data (e.g. CMM1394 for IEEE1394). For remote non-bridge aware target devices, the request is forwarded to the SddManager of the exit portal of the local cluster.
  • a local API such as the Communication Media Manager to retrieve the data (e.g. CMM1394 for IEEE1394).
  • the SddManager provides the following services: Comm Service Type Locality Access SddManager::GetSddData M global All SddDataChanged E global SddManager (all)
  • DeviceProfile ⁇ DeviceClass deviceClass; boolean withDcmManager; boolean withStreamManager; boolean withResourceManager; boolean withDisplayCapability; boolean deviceActive; boolean bridge; ⁇ ; Description
  • the deviceClass parameter gives the type of the device (FAV, IAV . . . ).
  • the withXxxManager booleans are True if the module is present in the device.
  • withDisplayCapability indicates for an IAV whether a DDI Controller is present or not, and for a FAV if a DDI controller and a level2 UI (user inteface) are present.
  • the deviceActive boolean is True if the device is active.
  • the bridge parameter specifies whether the device is a bridge or not.
  • Model ⁇ ModelId modelId //defined in HAVi-1.1 p200 DeviceModel modelText; //defined in HAVi-1.1 p149 ⁇ ; Description
  • This structure contains information about the DCU.
  • the fields are as defined by the HAVi-1.1 specification in section 9.10.7 p460.
  • This structure provides information about the HAVi device. It is basically the same information as in the IEEE 1394 configuration ROM SDD part of the HAVi-1.1 specification. For detailed information on the fields, see HAVi-1.1 specification section 9. Note that a bit is added in the device profile, the bridge bit, represented by the bridge boolean in the deviceProfile structure. This piece of data is used to indicate whether the HAVi device is a bridge or not. Note also that the dcmProfile and dcmReference are valid fields only for BAV devices.
  • the SddManager uses the following event:
  • This event is used to notify the devices on the network of a change in the SDD data of the device specified by the GUID.
  • a device hosting an SddManager can provide this event for its local SDD data.
  • a bridge device can provide the event for the SDD data of a remote device with no SddManager, by detecting the SDD data change on the portal local to the device (e.g. through multicast messages for an IP cluster) with changed SDD and transmitting the information to the SddManaqers of its other portals.
  • a device without SDDManager can be e.g. a HAVi 1.1 device such as a basic (BAV) nonIEEE 1394 device.
  • BAV basic
  • LAV legacy device
  • IEEE 1394 configuration ROM enhancement is carried out as follows:
  • This HAVi_Device_Profile is a 24 bits immediate value (as specified by IEEE 1212) field of the IEEE 1394 configuration Rom that already comprises:
  • the HAVi_Bridge is a 1-bit immediate value specifying for IAV/FAV devices whether this device is a HAVi bridge or not. For a BAV this bit shall be 0. HAVi_Bridge value Meaning 0 is not a bridge 1 is a bridge
  • the APIs of the CMM of a bridge are, according to the embodiment, globally accessible for at least some of their APIs/methods, instead of being accessible only to software elements of the host device (i.e. local accessibility). This is valid for each type of CMM.
  • CMM1394 IEEE 1394 based devices
  • CMMIP IP-based devices
  • the CMM1394 API becomes: Access by/For Comm events: Sent by Service Type Locality (destination) Cmm1394::GetGuidList M local All Cmm1394::Write M local Trusted global in bridges Cmm1394::Read M local Trusted global in bridges Cmm1394::Lock M local Trusted global in bridges Cmm1394::EnrollIndication M local Trusted global in bridges Cmm1394::DropIndication M local Trusted global in bridges ⁇ Client>::Cmm1394Indication MB local CMM1394 (trusted) global in bridges NewDevices E local CMM1394 (all) GoneDevices E local CMM1394 (all) NetworkReset E local CMM1394 (all) GuidListReady E local CMM1394 (all)
  • the process used by the HAVi SE is:
  • FIG. 4 shows an example, in which the software element of the device having its GUID equal to 1 instructs the remote CMMIP of the bridge to send an IP message to the remote IP device having GUID equal to 3.
  • a Network Manager software element is created to provide information about all the devices connected to the entire HAVi network.
  • a CMM provides the list of the GUIDs connected to its local cluster.
  • the Network Manager is able to give the list of GUIDs of the entire multi-clustered network, including the local cluster.
  • the NetDeviceInfo structure provides information about a device whatever its location in the network, i.e. it provides the GUID itself, the number of hops to reach it (used by Network Managers to solve loop issues as explained later), the GUID of the nearest portal to reach this device and the type of the cluster it is connected to.
  • the last two items allow a client to reach the CMMXXX on this nearest portal to access the low-level features of the remote cluster and send low-level messages to the remote device.
  • the RemoteNetworkState provides information on the state of the remote network behind a portal (i.e. the clusters behind the portal comprising the network manager).
  • STABLE means that the remote cluster device lists of the portals are stable and the other Network Managers can rely on them.
  • CHANGING means that the remote lists are still subject to modifications.
  • FINAL means that the remote lists of the portal should be stable but that a confirmation is needed by the other portals of the cluster (see the behaviour discovery process for more details).
  • This API returns the list of all devices on the entire network, split into an active device list and an inactive device list.
  • the information about each device is contained in NetDeviceInfo structures. This gives the GUID of the device, the GUID of the nearest portal to reach it, and the type of cluster it is attached to.
  • the SE retrieves the GUID 3 , sees that its cluster is IP-based, and that the nearest portal to reach it is the GUID 6 , so it can now send a CmmIp:: Send HAVi message to the CMMIP of the device having its GUID equal to 6.
  • This API returns the list of all reachable devices on the network behind the bridge comprising the Network Manager, split into in a list of active devices and a list of inactive devices (an active device being a device ready to receive messages, HAVi for IAV and FAV, private for BAV, as specified by the SDD data of a device).
  • the information about each device is contained in the NetDeviceInfo structure. This gives the GUID of the device, the GUID of the exit portal to reach it, the number of hops, the nearest portal and type of cluster it is attached to.
  • the access to this API is restricted to Network Managers. It is used by the Network Manager of a device (bridge or not) to query the remote device list of a bridge device, and consequently to build its internal table and solve loop issues.
  • the API is made available to other software elements as well.
  • This API provides complete information on a given network device.
  • the Network Manager returns the NetDeviceInfo structure.
  • Network Manager events are as follows, according to the embodiment:
  • RemoteNetworkUpdated is a global event for Network Managers only. This event is generated when the Network Manager has detected a change in the part of the network he is proxying for its local cluster, and when the network is considered as stable (contrary to the next event, which is sent to bridge Network Managers only and which is used when the state of lists is not yet stable). This can happen because of a change on the Network Manager co-portal cluster or because of a change forwarded by a bridge connected to its co-portal. During the reconfiguration time, the Network Manager may return NetworkManager::ENOT_READY for NetworkManager::GetRemoteDeviceList API until RemoteNetworkUpdated.
  • activeRemoteDeviceList and nonactiveRemoteDeviceList contents are same as defined in NetworkManager::GetRemoteDeviceList API.
  • the changedDevices, goneDevices and newDevices fields provide only the GUID because the gone devices were known in the old device list and the new and changed devices are provided with complete information in the new device lists.
  • RemoteNetworkChanged is a global event destined to Network Managers of bridge devices only. It is the same as the RemoteNetworkUpdated event but this one is used by Network Managers in bridge devices during their reconfiguration steps. During these steps, several events may be generated before a stable network state is reached (especially if loops are present). This avoids sending to bridge aware devices messages that won't be used because the network is not stabilized yet. Meaning of the fields is the same as for the RemoteNetworkUpdated event.
  • the aim is to discover all the devices connected to the HAVi network. Once this is done the ‘remote’ device lists in each portal give the information about which devices are reachable through themselves. While the IEEE 1394.1 topology opens loops by muting a bridge, the behavior regarding loops is different in this embodiment.
  • a bridge may be passing for certain paths but not for others, so when a loop exists, the bridges will not be totally muted but they will offer GUIDs in their remote list if they are on a particular path to the devices identified by these GUIDS. Whether a bridge is passing or not is decided based on certain criteria as explained below. In the present example, the number of hops reflects the number of portals to cross in order to reach the destination and not the number of bridges.
  • the basic discovery process is as follows:
  • Each local cluster carries out its own local discovery process.
  • the discovery process for an IEEE 1394 cluster is based on the IEEE 1394 Bus Reset inducing topology information dissemination using ‘selfID’ packets.
  • the CMM1 394s read the configuration rom of all nodes to to obtain their GUIDs.
  • the SDD data is read (if present) to obtain HAVi-defined information about the connected devices.
  • the discovery process for an IP cluster is based on multicast announcement packets.
  • the CMMIPs build their GUID list based on these announcements, which occur e.g. when a new device is connected to the cluster.
  • the SDD data are also contained is those packets.
  • the Network Managers start to query each other.
  • HAVi SEs call the NetworkManager::GetNetDeviceList API of their local Network Manager.
  • the ENOT_READY error may be returned and the client will have to wait.
  • the steps 1 and 2 are in fact done in parallel, so a mechanism is proposed to avoid dead lock issues.
  • the device list building process progresses from the leave clusters to the root cluster of the topology (at least for a network without loops).
  • G2.1 No new bridges keep the previous state and update the co-portal if STABLE state.
  • G2.2 New bridges check for duplicate GUIDs between the new local list and the old remote list (may e.g. happen when a new bridge allows a shorter route than the old topology).
  • G2.2.2 No duplicate GUIDs go to FINAL state and ask for remote list of new portals.
  • C1 When receiving an ENOT_READY error response from a portal of the cluster, update the co-portal with an incomplete list (it will be at least the local cluster's list) if something has changed since the last update and if not S3. Wait a certain amount of time for an event from the portal and ask again for remote list if no event has been received.
  • C3.1 Duplicate GUIDS go to FINAL state, remove duplicate GUIDs (hops rule G3), and send FINAL event on the cluster.
  • C3.2 No duplicate GUIDs send CHANGING event on the cluster if not S4.
  • the above process includes steps to ensure through—if necessary—an iterative processing that redundant path conflicts are properly resolved.
  • the three possible states—Changing, Stable and Final are defined.
  • the information regarding these states is propagated using the RemoteNetworkState data structure in the RemoteNetworkChanged event.
  • a time out process is implemented in this discovery process in order to avoid having slower bridges flooded by a large amount of events from the others bridges before being able to reply.
  • a HAVi message is sent from a Software Element to another Software Element.
  • a Software Element is identified by a SEID (Software Element Identifier). This SEID is composed of the GUID of the device in which the Software Element resides and of a swHandle unique within the device.
  • the header of a HAVi message contains the destination SEID and the source SEID.
  • the bridge device does not modify a HAVi message (what we call here HAVi message does not contain the TAM header).
  • the destination SEID, source SEID, protocol type, message type, message number, message length and message body fields are kept identical.
  • the Messaging System will, however, route the message to the destination. To do so, when a Messaging System in a bridge receives a HAVi message on a cluster, it looks at the destination SEID and more precisely the GUID contained in this SEID. If this GUID is its own GUID, then this message is for an internal SE and it delivers it. If this GUID is present in its remote GUID list, then it forwards the message to its co-portal (or the appropriate co-portal should there be more than one co-portal). The co-portal will then send this message to the corresponding destination device (regarding its internal table). This device can be the final destination device or the next bridge on the path.
  • a ‘simple’ message (i.e. no acknowledgment requested) is just sent and no acknowledge is required.
  • a ‘reliable’ message is sent, and the caller is blocked until the positive or negative acknowledgment (Ack or Nack) is received. This is true for the initial sender, the Messaging Systems in the bridges on the path just forward the messages (initial message, Ack or Nack messages).
  • the Messaging System of the device with GUID 1 sends the message to the bridge portal (device with GUID 5 ).
  • the Messaging System of the bridge looks at the destination SEID and more precisely the GUID contained in this SEID, and deduces that this message is for a device of its remote list. It then forwards the HAVi message to its co-portal, which in turn sends it to the device with GUID 3 (see FIG. 5 ).
  • the Acknowledge response is then sent from the device with GUID 3 through the bridge to the device with GUID 1 .
  • Event Manager::PostEvent API When a SE is sending an event (with the EventManager::PostEvent API), the Event Manager is posting it on its local cluster only (with the EventManager::ForwardEvent API). The Event Manager of a bridge which receives an event from another Event Manager will forward it to its co-portal. The co-portal will then send this event to its cluster (with the EventManager::ForwardEvent API), etc.
  • the rule for a portal's Event Manager to forward or not an event to its co-portal is whether or not the GUID of the original poster exists in the remote list of its co-portal.
  • the GUID of the original poster is given as parameter in the ForwardEvent message.
  • the posterSeid parameter is the SEID of the original SE which posted the event to its local Event Manager.
  • the GUID contained in this SEID gives the GUID of the device the SE resides in. This GUID is used by a portal to decide if it forwards the event or not.
  • FIG. 6 shows the basic process for event posting on a multi-clustered network.
  • the event posted from a SE in the device having GUID 3 is forwarded by the Event Manager of the device having GUID 3 to all Event Managers of its cluster.
  • the portals then forward this event to the remote cluster as soon as the GUID of the poster is in the remote list of their co-portal (that is why the portal 6 does not forward it to the portal 5 ).
  • the portals then forward this event to the Event Managers on their clusters except for the non BA-devices (that is why the device 2 does not receive this event).
  • the “global” parameter of the PostEvent API is modified as follows. Currently it is defined as a boolean indicating whether the event is local to the device or global to the HAVi network. This boolean is replaced by an ‘enum’ structure as follows:
  • the PostEvent API is left unchanged.
  • a Registry query request (Registry::GetElement or Registry::MultipleGetElement) is sent by an SE to a Registry.
  • the basic process is for an SE to query its local Registry, and the latter will then forward the query to all other Registries on the HAVi network.
  • a Registry receives a query from a remote node, it just answers to the query after having searched its own database.
  • a Registry receiving a query from a remote node will answer searching its own database, except for the Registries in the bridge devices.
  • the basic process remains for an SE to query its local Registry, which will forward the request to all the Registries on the network. This is detailed hereafter.
  • the Registry of a portal naturally forwards the requests coming from Registries of its cluster to the Registry of its co-portal. But it will do it only if the GUID of the initial sender of the request is present in the remote list of its co-portal (i.e. its co-portal is on the reverse path to the initial sender). As before, this avoids sending the message over different paths to the same destination. If this initial GUID is not in the remote list of its co-portal, then the request will not be forwarded. This can happen with topology loops. In this case, its co-portal will receive the request via the bridge on its cluster which proxies the initial GUID (so by another route).
  • the Registry of a bridge does not forward the requests from Registries of non BA-devices. Those devices have no knowledge of the remote GUIDs, so would not be able to send messages to a remote SEID (the basic query to a Registry returns a SEID, which comprises the GUID).
  • the Registry of the co-portal can then forward the request to the other Registries on its cluster, including other bridges.
  • the Registry request is consequently sent on the entire network.
  • the Registry of a BA-device sends its query only to its cluster, so the Registry communication between clusters is controlled by the Registries themselves (‘Cluster separation’).
  • Cluster separation a three-bridges loop network is shown with the Network Manager lists (local and remote).
  • the basic process is as follows: the initial Registry (device GUID 1 ) sends the query to all Registries on the entire network. The number of HAVi messages sent on the first cluster is then nine (since there are nine registries on the network), one for each Registry. On the other clusters this number decreases, since not all messages are forwarded by all bridges.
  • the initial Registry (GUID 1 ) sends the query to all Registries of its own cluster only.
  • the number of HAVi messages on this first cluster is now three.
  • the Registries of the bridge repeat this operation with the clusters of their co-portals (but only if the initial sender GUID 1 is present in the remote list of their co-portal: that is why the portal having GUID 7 does not forward it to the portal having GUID 8 ).
  • Registries in portals create one single response by merging all the responses of their co-portal cluster Registries. Furthermore, in this example every device is reachable through one bridge, but when several bridges are chained the number of redundant HAVi messages becomes huge in the clusters near the initial sender.
  • the initial Registry queries all the Registries on its cluster. This reduces the overall traffic for requests. Then the Registries in the bridges forward the request.
  • the source SEID of the HAVi message has to be the one of the initial sender (if this source SEID is changed, then a query in a loop network will have no end, because of the route management chosen for the Network Manager behaviour). But then all the Registries in the network will respond to the initial requester and this one will receive more responses than it has sent queries, which might not be understood. This is why according to the present embodiment, the initial requester receives responses from Registries of its local cluster only.
  • the Register::GetElement API is modified. A new parameter is added to include the information about the SEID of the initial requester.
  • the API becomes: Status Registry::GetElement( in SEID initialRequester, in SimpleQuery query, out sequence ⁇ SEID> seidList)
  • a portal of a bridge receiving this message knows if it has to forward or not the query to its co-portal based on the GUID contained in the SEID of this initial requester parameter.
  • the traffic improvement is done for responses.
  • the bridge when forwarding the request to its remote cluster, has to send HAVi 1.1 messages to HAVi 1.1 devices and this new message to BA-devices (based on the version field of the SDD of each device). Those requests are new ones, with the source SEID of the bridge (and not of the initial requester anymore).
  • the portal will collect all the responses sent to it (because it is the source SEID of the request) and merge them into one SEID list that it will send to it's the inital requester (the device it originally received the request from).
  • non-bridge Registries do not use the identification of the initial requester. This information is only useful for Registries of bridge devices, in order to decide whether to forward the request or not to the remote cluster.
  • Another variant consists in extending the Register's API with a new method call dedicated to bridge devices. A bridge aware registry would use this call for portal registries.
  • the called bridge device then has knowledge of the identity of the initial requester.
  • Non-bridge devices receive the normal GetElement call. Both calls contain the source SEID of the bridge, not the initial requester's SEID.
  • the bridge When the bridge has received all the responses from the Registries, it merges them into one SEID list and responds to the ForwardGetElement call it initially received.
  • Variant three has the advantage to enable synchronization between the bridges.
  • FIG. 8 gives an example of the interactions for a GetElement call using the third variant.
  • the initial sender sends a GetElement request to its local Registry.
  • the local Registry then forwards this GetElement request to the other Registries on its local cluster.
  • the Registry of a bridge receives this request, it transmits it to its co-portal Registry (provided the GUID contained in the source SEID be in the remote list of this co-portal). This is then considered as a new request.
  • This new request is sent to the Registries on the cluster of the co-portal.
  • the GetElement is sent to non bridge devices, and the ForwardGetElement is sent to the bridge devices. The process is reiterated if other bridges are present on this cluster.
  • the SEID list is merged by the bridge devices:
  • the known HAVi Stream Manager is a system software element that permits establishing of stream connections.
  • a stream connection associates a source functional component element and a sink functional component (consequently the associated source, and a sink device) and guarantees the availability of the required resources. These resources may be channel, bandwidth, etc.
  • FIG. 9 shows the stream connection model specified by HAVi. Two functional components are inter-connected. An internal connection between a functional control module and a device control module (FCM/DCM) has been made in each associated device. A device connection has been made between associated devices (the two Full A/V devices of FIG. 9 ). The logical connection is at the HAVi level (i.e. between software elements) while the physical connection involves the real equipments (those represented by DCMs/FCMs at the logical level).
  • a stream may be sent between the source and the sink.
  • each application that wants to create a stream connection shall use its local Stream Manager (i.e. the Stream Manager located in the same device).
  • a functional component is represented somewhere in the network by a FCM (Functional Component Module) as the device is represented somewhere in the network by a DCM (Device Control Module).
  • FCM Field Component Module
  • DCM Device Control Module
  • the TargetId the GUID of the device where the functional component (not the FCM) is located and an index to the component within the device.
  • the plug direction in or out.
  • the plug number if the functional component manages several plugs.
  • the Stream Manager uses the services of the DCM to realize the internal connection (i.e. the connection within the device). To operate the DCM module, the Stream Manager uses HAVi messages. Therefore, the way to establish an internal connection does not depend on the medium's technology (e.g. IEC61883/IEEE1394).
  • the Stream Manager uses the services of its link layer (e.g. IEC1883 CMP protocol) to set up the device stream connection.
  • link layer e.g. IEC1883 CMP protocol
  • the process for multi-clustered streams is as follows:
  • a client uses its local Stream Manager. This local Stream Manager is entirely responsible for this stream.
  • the Stream Manager local to the client may not be on the same cluster as the source and/or sink devices. Furthermore, it may not be aware of the medium technology used for the source and/or sink device. Thus the basic principle is to make the Stream Managers on the path collaborate.
  • the client For simple mono-cluster streams, the client is able to specify transport type, transmission format, channel and plugs to be used by the Stream Manager. For multi-clustered streams, it is not realistic to think that the client can choose all those parameters for every cluster the stream will cross (the aim is to be able to have a medium technology that the client is not aware about at all). So the client has just to specify the bandwidth policy (static or dynamic) and the stream type (which is unique on the stream). Then the Stream Managers are responsible for all the transport issues.
  • Broadcast streams in HAVi are set up with the Stream Manager SprayOut and TapIn APIs.
  • a Stream Manager when a Stream Manager receives a local call on those APIs and the targeted device is remote (i.e. not on the local cluster), it will forward this call to the Stream Manager of the nearest portal connected to the targeted functional component (the device). This Stream Manager will then perform the broadcast connection, but this connection will be only local to the remote cluster. So broadcast streams do not cross bridges, but can be controlled remotely.
  • This API allows a client to request the creation of a stream on the multi-cluster HAVi network.
  • the source device and the sink device are not necessarily on the same medium type.
  • the only parameter which has to be the same for the source and sink is the stream type.
  • Stream type can be converted but this would be done in a converter module (e.g. a Converter FCM with an input for one stream type and an output for another different stream type).
  • Transport type conversion is carried out by bridges.
  • a bridge connecting two different medium technologies is able to convert the transportation type of streams and messages from one type to the other.
  • the client does not take care of the transport type(s), the transmission format(s) and the channel(s) used for this multi-clustered connection. This will be handled by the Stream Managers of the bridges on the path of the stream.
  • This API is used between Stream Managers in bridges to build the connection across at least one cluster.
  • the dynamicBw, source and sink parameters are copied from the original MultiClusterFlowTo method call. They are used by the Stream Managers of portals to determine to which portals on the path they need to send the stream.
  • the streamType parameter identifies the type of the stream. This type is unique for the whole stream, as it is not influenced by the transport used to carry the stream.
  • a stream changing its stream type e.g. from DV to MPEG2
  • will go through a converter e.g. FCM converter
  • the FCM converter being the sink for the first stream and the source for the converted stream.
  • the “segment” parameters identify the parameters used on the current (i.e. local to the targeted Stream Manager) segment of the stream. This is useful for the Stream Manager of the portal receiving this call to obtain all the information on the connection established on its segment, to connect it internally to its co-portal.
  • the connId parameter is filled in by the initial Stream Manager, and it is used by portal Stream Managers on the stream path to “attach” their segment stream to the multi-clustered stream.
  • a multi-clustered stream will be initiated by the Stream Manager local to the client, and owned by it, as in HAVi-1.1 (“own” is in the sense of present in its Local Connection Map).
  • This Stream Manager will be named the “initial” Stream Manager. It forwards the call to the Stream Manager of the nearest portal of the targeted functional component (the device) on the path to the sink device. Consequently, the Stream Manager of a portal can receive local calls (by local clients) and remote calls (by remote Stream Managers).
  • This portal's Stream Manager is in charge of making the connection on the cluster with the targeted source functional component, and the Stream Manager of its co-portal the connection on the next cluster on the stream path. If the stream crosses other bridges, the co-portal Stream Manager will then send a HAVi message to the Stream Manager of the next bridge on the stream path, with all necessary information, so that this next bridge Stream Manager can forward the connection internally to its co-portal, which will make the connection on its cluster, etc. On each segment, the appropriate Stream Manager will call APIs of DCMs to perform the choice of transport parameters, those DCMs can be the ones of the source and sink devices, but also of the bridges on the path.
  • the building of the connection may involve Stream Managers of both source and sink end points (portal or device).
  • the process diagram is as illustrated by FIG. 10 .
  • a HAVi-1.1 device cannot drop a stream established by a remote Stream Manager, because it does not even see it. It may be able to drop a multi-clustered stream owned by a Stream Manager on its cluster (even if it does not understand the source and/or sink for this stream).
  • connection establishment could be done not from the source to the sink, but from the sink to the source.
  • the dynamic bandwidth allocation can still be managed on multi-clustered streams. If the dynamicBw boolean parameter is set to True in the MultiClusterFlowTo API, then the DCM source is responsible for reallocating the resource on its cluster. It then sends the BandwidthRequirementChanged event. This event is caught by the Stream Manager responsible for the next segment on the path. This Stream Manager reallocates bandwidth if required etc. If the dynamicBw boolean parameter is set to False in the MultiClusterFlowTo API, then a change in the required bandwidth for the stream may put the stream in failure mode (as described in HAVi-1.1).
  • Stream connection error handling is carried out as follows: When a connection cannot be established on one segment during the building process, the Stream Manager will send back the OnThePath message with the failure reason in the Status return value. The connection is then removed, segment by segment up to the initial Stream Manager, which warns its client, or takes an “alternative path” if available (see below).
  • the Stream Manager on this segment responsible for the connection sends a MultiClusterConnectionDropped event caught by the initial Stream Manager, and this one is responsible for dropping the stream, or trying to keep it alive through an “alternative path”.
  • the initial Stream Manager is retrievable through the connId parameter of the OnThePath API. This connId parameter gives access to the mgr parameter, which is the SEID of the initial Stream Manager.
  • the Stream Managers on the B type cluster decide not to translate the transport type of the stream (e.g. 1394 over IP).
  • the stream will then be encapsulated on the cluster B. This can be useful for performance reasons. But as soon as a sink device is added to this stream on the cluster B, the stream will be translated, so that the renderer on medium technology B can display the stream. So then a A->B translation will be done for cluster B, and then a B->A translation for the target A type cluster.
  • the Stream Manager can provide the list of all HAVi streams running on the HAVi network, using so-called connection maps. This is done with the GetGlobalConnectionMap API. It works in a way similar to that of the Registry::GetElement. As before, due to the loop resolution process defined by the Network Managers, there is a need for a new parameter to forward this query to the Stream Managers of other clusters, in order to reduce traffic.
  • the proposed API is: Status StreamManager::ForwardGetGlobalConnectionMap( in SEID initialRequester, out sequence ⁇ Connection> list)
  • the initialRequester parameter allows a portal to know whether it has to forward this request to its co-portal or not.
  • the local connection maps of each Stream Manager are gathered by the portal Stream Managers, and are finally sent back to the initial requesting Stream Manager.
  • the Stream Manager of a bridge receiving the GetLocalConnectionMap from a device on its cluster acts differently depending on the caller's identity as derived from its SEID:
  • the caller is not a Stream Manager. This means that a SE wants to know its local connection map. The local connection map only is sent in reply.
  • the caller is a Stream Manager in a HAVi-1.1 device (i.e. non bridge aware). Again, only the local connection map is sent in reply.
  • the caller is a Stream Manager in a BA-device.
  • the request is forwarded to the co-portal (if forwarding rules are fulfilled), and the co-portal Stream Manager will send a GetLocalConnectionMap to all the Stream Managers of its cluster and a ForwardGetGlobalConnectionMap to the Stream Managers of the other portals connected to its cluster.
  • ConnectionType enumerated
  • connectionId structure the mgr field identifying the Stream Manager responsible for the stream on the specified cluster
  • the resource manager should not be affected by the bridges.
  • the Sdd Manager of a BA-device will be in charge of retrieving the SDD data of any device on the entire HAVi network. This will be done accessing remote Sdd Managers or performing local low-levels calls.
  • the CMM is responsible for enabling access to the low-level local cluster. So the CMM still provides a GetGuidList API, giving back the list of all GUIDs on the local cluster. And it provides a way to send/receive low-level messages on this cluster.
  • the CMM1394 is specified in the HAVi-1.1 document.
  • HAVi Software Element Types in addition to those existing in HAVi 1.1. are defined below. TABLE 11 ATT_SE_TYPE System HAVi Software Element Type Value Trusted Element SDD_MANAGER 0x0000 0007 yes yes NETWORK_DEVICE — 0x0000 0008 yes yes MANAGER
  • HAVi SEIDs according to the present embodiment are as follows: TABLE 12 Software Element HAVi Software Element Type Handle SDD_MANAGER 0x0007 NETWORK_DEVICE_MANAGER 0x0008 COMMUNICATION_MEDIA_MANAGER_IP 0x0009
  • HAVi API Codes are as follows. TABLE 13 HAVi API Name API Code SddManager 0x0017 NetworkManager 0x0018 CmmIp 0x0019
  • HAVi Error Codes for the SddManager and the NetworkManager are as follows: TABLE 15 HAVi Error Name API Code Error Code SddManager::ENOT_READY 0x0017 0x0080 SddManager::EUNKNOWN_GUID 0x0017 0x0081 SddManager::ELAV 0x0017 0x0082 NetworkManager::ENOT_READY 0x0018 0x0080 NetworkManager::EUNKNOWN_GUID 0x0018 0x0081 CmmIp::ENOT_READY 0x0019 0x0080 CmmIp::EUNKNOWN_GUID 0x0019 0x0081 CmmIp::EUNKNOWN_GUID 0x0019 0x0081 CmmIp::EUNKNOWN_GUID 0x0019 0x0081 CmmIp::EUNKNOWN_IP_ADDRESS 0x0019 0x
  • FIG. 18 illustrates the interaction of Network Managers during a complete network building process. All devices are first turned off, and then turned on at the same time, so the discovery is made in parallel for each device. For the bridge Network Managers, the Local and the Remote list constitution is described.
  • a client SE can ask its local Network Manager for the global list of devices on the entire network.
  • the portals then send out this incomplete remote list with the RemoteNetworkChanged event, as shown in FIG. 24 .
  • This event is for Network Managers of bridges only and specifies clearly that the list is not in a stable state (while RemoteNetworkUpdated is a final stable list).

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Automation & Control Theory (AREA)
  • Theoretical Computer Science (AREA)
  • Multimedia (AREA)
  • Computing Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Security & Cryptography (AREA)
  • Software Systems (AREA)
  • Small-Scale Networks (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Information Transfer Between Computers (AREA)
US10/510,536 2002-04-09 2003-04-09 Methods for communication in a multi-cluster network, device for connection to a network of clusters and bridge for connecting clusters Abandoned US20050165965A1 (en)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
EP02290890 2002-04-09
EP02290890.9 2002-04-09
PCT/EP2003/004694 WO2003085892A2 (en) 2002-04-09 2003-04-09 Methods for communication in a multi-cluster network, device for connection to a network of clusters and bridge for connecting clusters

Publications (1)

Publication Number Publication Date
US20050165965A1 true US20050165965A1 (en) 2005-07-28

Family

ID=28686012

Family Applications (1)

Application Number Title Priority Date Filing Date
US10/510,536 Abandoned US20050165965A1 (en) 2002-04-09 2003-04-09 Methods for communication in a multi-cluster network, device for connection to a network of clusters and bridge for connecting clusters

Country Status (8)

Country Link
US (1) US20050165965A1 (ja)
EP (1) EP1493250A2 (ja)
JP (1) JP2005522913A (ja)
KR (1) KR20040097296A (ja)
CN (1) CN1647455A (ja)
AU (1) AU2003240599A1 (ja)
MX (1) MXPA04009873A (ja)
WO (1) WO2003085892A2 (ja)

Cited By (22)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20050071510A1 (en) * 2003-09-29 2005-03-31 Nokia Corporation Transport layer communication
US20060218353A1 (en) * 2005-03-11 2006-09-28 Interdigital Technology Corporation Method and apparatus for implementing path-based traffic stream admission control in a wireless mesh network
US20070005735A1 (en) * 2005-05-24 2007-01-04 Wistron Corp. UPnP cluster systems and methods
US7251703B1 (en) * 2004-02-27 2007-07-31 Entropic Communications, Inc. Method of time stamping to enable device bridging over dissimilar buses
GB2436627A (en) * 2006-03-29 2007-10-03 Bridgeworks Ltd Message handling using a wrapper
US20070249374A1 (en) * 2006-04-21 2007-10-25 Lucent Technologies Inc. Method for controlling delivery of short messages in wireless network
US20080064396A1 (en) * 2006-09-07 2008-03-13 Technology, Patents & Licensing, Inc. Device Registration Using a Wireless Home Entertainment Hub
US20080066123A1 (en) * 2006-09-07 2008-03-13 Technology, Patents & Licensing, Inc. Inventory of Home Entertainment System Devices Using a Wireless Home Entertainment Hub
US20080065238A1 (en) * 2006-09-07 2008-03-13 Technology, Patents & Licensing, Inc. Presentation of Still Image Data on Display Devices Using a Wireless Home Entertainment Hub
US20080061578A1 (en) * 2006-09-07 2008-03-13 Technology, Patents & Licensing, Inc. Data presentation in multiple zones using a wireless home entertainment hub
US20080066094A1 (en) * 2006-09-07 2008-03-13 Technology, Patents & Licensing, Inc. Control of Data Presentation in Multiple Zones Using a Wireless Home Entertainment Hub
US20080066118A1 (en) * 2006-09-07 2008-03-13 Technology, Patents & Licensing, Inc. Connecting a Legacy Device into a Home Entertainment System Useing a Wireless Home Enterainment Hub
US20080069319A1 (en) * 2006-09-07 2008-03-20 Technology, Patents & Licensing, Inc. Control of Data Presentation Using a Wireless Home Entertainment Hub
US20080068152A1 (en) * 2006-09-07 2008-03-20 Technology, Patents & Licensing, Inc. Control of Data Presentation from Multiple Sources Using a Wireless Home Entertainment Hub
US20080209536A1 (en) * 2003-01-23 2008-08-28 Ingo Hutter Updating Parameters in a Bridged Multistandard Home Network
US7428222B1 (en) * 2003-02-28 2008-09-23 Entropic Communications Inc. Method of bus configuration to enable device bridging over dissimilar buses
US20090024774A1 (en) * 2007-07-18 2009-01-22 Samsung Electronics Co., Ltd. Network bridge device and bus reset control method thereof
US20090257416A1 (en) * 2008-04-09 2009-10-15 Ubiquisys Limited Access point
US20100284417A1 (en) * 2007-10-04 2010-11-11 Robby Gurdan Data stream router
CN102916864A (zh) * 2012-11-02 2013-02-06 上海电机学院 一种以太网桥及其智能链接方法
US10785134B2 (en) * 2015-11-18 2020-09-22 Adobe Inc. Identifying multiple devices belonging to a single user
US11275789B2 (en) * 2017-07-12 2022-03-15 Groupon, Inc. Method, apparatus, and computer program product for inferring device rendered object interaction behavior

Families Citing this family (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2005293358A (ja) * 2004-04-01 2005-10-20 Seiko Epson Corp 出力デバイス及び入力デバイス
US20080098141A1 (en) * 2004-07-20 2008-04-24 Kinya Ohno Bridge and Transmitting Apparatus, and Information System
US20060274743A1 (en) 2005-06-06 2006-12-07 Alper Yegin System and method for a mobile device to learn information about the access networks within its neighborhood
EP1889402B1 (en) * 2005-06-06 2011-01-05 Samsung Electronics Co., Ltd. Server, methods and computer-readable media for discovering neighbor networks in a mobile station
WO2008121032A1 (en) * 2007-03-29 2008-10-09 Telefonaktiebolaget Lm Ericsson (Publ) Media stream setup in a group communication system
EP2009845A1 (en) 2007-06-07 2008-12-31 Thomson Licensing Method and apparatus for error messaging in a multimedia network
CN101779198B (zh) * 2007-08-15 2013-02-13 思科技术公司 用于桥接网络中的流预留的方法、节点和系统
EP2045969A1 (en) * 2007-10-04 2009-04-08 U-MAN Universal Media Access Networks GmbH Data stream router
US20100235523A1 (en) * 2009-03-16 2010-09-16 Robert Garcia Framework for supporting multi-device collaboration

Citations (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20010032273A1 (en) * 2000-02-23 2001-10-18 Cheng Doreen Yining Architecture of a bridge between a non-IP network and the web
US20010047431A1 (en) * 2000-02-09 2001-11-29 Eytchison Edward B. HAVi-VHN bridge solution
US6349352B1 (en) * 1998-01-06 2002-02-19 Sony Corporation Of Japan Home audio/video network with both generic and parameterized device control
US20020073244A1 (en) * 2000-12-13 2002-06-13 Davies Nigel Andrew Justin Method and an apparatus for the integration of IP devices into a HAVi network
US20020087964A1 (en) * 2000-12-28 2002-07-04 Gateway, Inc. System and method for enhanced HAVi based device implementation
US6618764B1 (en) * 1999-06-25 2003-09-09 Koninklijke Philips Electronics N.V. Method for enabling interaction between two home networks of different software architectures
US6954467B1 (en) * 1999-09-07 2005-10-11 Koninklijke Philips Electronics N.V. Clustered networked devices
US20060036750A1 (en) * 2004-02-18 2006-02-16 Patrick Ladd Media extension apparatus and methods for use in an information network

Patent Citations (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6349352B1 (en) * 1998-01-06 2002-02-19 Sony Corporation Of Japan Home audio/video network with both generic and parameterized device control
US6618764B1 (en) * 1999-06-25 2003-09-09 Koninklijke Philips Electronics N.V. Method for enabling interaction between two home networks of different software architectures
US6954467B1 (en) * 1999-09-07 2005-10-11 Koninklijke Philips Electronics N.V. Clustered networked devices
US20010047431A1 (en) * 2000-02-09 2001-11-29 Eytchison Edward B. HAVi-VHN bridge solution
US20010032273A1 (en) * 2000-02-23 2001-10-18 Cheng Doreen Yining Architecture of a bridge between a non-IP network and the web
US20020073244A1 (en) * 2000-12-13 2002-06-13 Davies Nigel Andrew Justin Method and an apparatus for the integration of IP devices into a HAVi network
US20020087964A1 (en) * 2000-12-28 2002-07-04 Gateway, Inc. System and method for enhanced HAVi based device implementation
US20060036750A1 (en) * 2004-02-18 2006-02-16 Patrick Ladd Media extension apparatus and methods for use in an information network

Cited By (79)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20080209536A1 (en) * 2003-01-23 2008-08-28 Ingo Hutter Updating Parameters in a Bridged Multistandard Home Network
US7865622B2 (en) * 2003-01-23 2011-01-04 Thomson Licensing Updating parameters in a bridged multistandard home network
US7428222B1 (en) * 2003-02-28 2008-09-23 Entropic Communications Inc. Method of bus configuration to enable device bridging over dissimilar buses
US20050071510A1 (en) * 2003-09-29 2005-03-31 Nokia Corporation Transport layer communication
US7251703B1 (en) * 2004-02-27 2007-07-31 Entropic Communications, Inc. Method of time stamping to enable device bridging over dissimilar buses
US20060218353A1 (en) * 2005-03-11 2006-09-28 Interdigital Technology Corporation Method and apparatus for implementing path-based traffic stream admission control in a wireless mesh network
US20070005735A1 (en) * 2005-05-24 2007-01-04 Wistron Corp. UPnP cluster systems and methods
GB2436627A (en) * 2006-03-29 2007-10-03 Bridgeworks Ltd Message handling using a wrapper
US8090876B2 (en) * 2006-03-29 2012-01-03 Bridgeworks Limited Message handling by a wrapper connected between a kernel and a core
US20070288568A1 (en) * 2006-03-29 2007-12-13 Bridgeworks Limited Message handling by a wrapper connected between a kernel and a core
GB2436627B (en) * 2006-03-29 2011-04-20 Bridgeworks Ltd Message handling
US20070249374A1 (en) * 2006-04-21 2007-10-25 Lucent Technologies Inc. Method for controlling delivery of short messages in wireless network
US9363105B2 (en) * 2006-04-21 2016-06-07 Alcatel Lucent Method for blocking spam short messages in wireless network
US8005236B2 (en) 2006-09-07 2011-08-23 Porto Vinci Ltd. Limited Liability Company Control of data presentation using a wireless home entertainment hub
US8607281B2 (en) * 2006-09-07 2013-12-10 Porto Vinci Ltd. Limited Liability Company Control of data presentation in multiple zones using a wireless home entertainment hub
US20080066120A1 (en) * 2006-09-07 2008-03-13 Technology, Patents & Licensing, Inc. Data Presentation Using a Wireless Home Entertainment Hub
US20080065233A1 (en) * 2006-09-07 2008-03-13 Technology, Patents & Licensing, Inc. Audio Control Using a Wireless Home Entertainment Hub
US20080061578A1 (en) * 2006-09-07 2008-03-13 Technology, Patents & Licensing, Inc. Data presentation in multiple zones using a wireless home entertainment hub
US20080065247A1 (en) * 2006-09-07 2008-03-13 Technology, Patents & Licensing, Inc. Calibration of a Home Entertainment System Using a Wireless Home Entertainment Hub
US20080066124A1 (en) * 2006-09-07 2008-03-13 Technology, Patents & Licensing, Inc. Presentation of Data on Multiple Display Devices Using a Wireless Home Entertainment Hub
US20080066094A1 (en) * 2006-09-07 2008-03-13 Technology, Patents & Licensing, Inc. Control of Data Presentation in Multiple Zones Using a Wireless Home Entertainment Hub
US20080066122A1 (en) * 2006-09-07 2008-03-13 Technology, Patents & Licensing, Inc. Source Device Change Using a Wireless Home Entertainment Hub
US20080066118A1 (en) * 2006-09-07 2008-03-13 Technology, Patents & Licensing, Inc. Connecting a Legacy Device into a Home Entertainment System Useing a Wireless Home Enterainment Hub
US20080065235A1 (en) * 2006-09-07 2008-03-13 Technology, Patents & Licensing, Inc. Data Presentation by User Movement in Multiple Zones Using a Wireless Home Entertainment Hub
US20080066093A1 (en) * 2006-09-07 2008-03-13 Technology, Patents & Licensing, Inc. Control of Access to Data Using a Wireless Home Entertainment Hub
US20080071402A1 (en) * 2006-09-07 2008-03-20 Technology, Patents & Licensing, Inc. Musical Instrument Mixer
US20080069319A1 (en) * 2006-09-07 2008-03-20 Technology, Patents & Licensing, Inc. Control of Data Presentation Using a Wireless Home Entertainment Hub
US20080069087A1 (en) * 2006-09-07 2008-03-20 Technology, Patents & Licensing, Inc. VoIP Interface Using a Wireless Home Entertainment Hub
US20080068152A1 (en) * 2006-09-07 2008-03-20 Technology, Patents & Licensing, Inc. Control of Data Presentation from Multiple Sources Using a Wireless Home Entertainment Hub
US20080141316A1 (en) * 2006-09-07 2008-06-12 Technology, Patents & Licensing, Inc. Automatic Adjustment of Devices in a Home Entertainment System
US20080141329A1 (en) * 2006-09-07 2008-06-12 Technology, Patents & Licensing, Inc. Device Control Using Multi-Dimensional Motion Sensing and a Wireless Home Entertainment Hub
US20080150704A1 (en) * 2006-09-07 2008-06-26 Technology, Patents & Licensing, Inc. Data Presentation from Multiple Sources Using a Wireless Home Entertainment Hub
US11968420B2 (en) 2006-09-07 2024-04-23 Rateze Remote Mgmt Llc Audio or visual output (A/V) devices registering with a wireless hub system
US11729461B2 (en) 2006-09-07 2023-08-15 Rateze Remote Mgmt Llc Audio or visual output (A/V) devices registering with a wireless hub system
US20080066117A1 (en) * 2006-09-07 2008-03-13 Technology, Patents & Licensing, Inc. Device Registration Using a Wireless Home Entertainment Hub
US7920932B2 (en) 2006-09-07 2011-04-05 Porto Vinci, Ltd., Limited Liability Co. Audio control using a wireless home entertainment hub
US20080065232A1 (en) * 2006-09-07 2008-03-13 Technology, Patents & Licensing, Inc. Remote Control Operation Using a Wireless Home Entertainment Hub
US20110150235A1 (en) * 2006-09-07 2011-06-23 Porto Vinci, Ltd., Limited Liability Company Audio Control Using a Wireless Home Entertainment Hub
US20080065238A1 (en) * 2006-09-07 2008-03-13 Technology, Patents & Licensing, Inc. Presentation of Still Image Data on Display Devices Using a Wireless Home Entertainment Hub
US20080066123A1 (en) * 2006-09-07 2008-03-13 Technology, Patents & Licensing, Inc. Inventory of Home Entertainment System Devices Using a Wireless Home Entertainment Hub
US8146132B2 (en) 2006-09-07 2012-03-27 Porto Vinci Ltd. Limited Liability Company Device registration using a wireless home entertainment hub
US8307388B2 (en) 2006-09-07 2012-11-06 Porto Vinci Ltd. LLC Automatic adjustment of devices in a home entertainment system
US8321038B2 (en) 2006-09-07 2012-11-27 Porto Vinci Ltd. Limited Liability Company Presentation of still image data on display devices using a wireless home entertainment hub
US11570393B2 (en) 2006-09-07 2023-01-31 Rateze Remote Mgmt Llc Voice operated control device
US11451621B2 (en) 2006-09-07 2022-09-20 Rateze Remote Mgmt Llc Voice operated control device
US8421746B2 (en) 2006-09-07 2013-04-16 Porto Vinci Ltd. Limited Liability Company Device control using multi-dimensional motion sensing and a wireless home entertainment hub
US11323771B2 (en) 2006-09-07 2022-05-03 Rateze Remote Mgmt Llc Voice operated remote control
US20080065231A1 (en) * 2006-09-07 2008-03-13 Technology, Patents & Licensing, Inc User Directed Device Registration Using a Wireless Home Entertainment Hub
US8634573B2 (en) 2006-09-07 2014-01-21 Porto Vinci Ltd. Limited Liability Company Registration of devices using a wireless home entertainment hub
US8704866B2 (en) 2006-09-07 2014-04-22 Technology, Patents & Licensing, Inc. VoIP interface using a wireless home entertainment hub
US8713591B2 (en) 2006-09-07 2014-04-29 Porto Vinci LTD Limited Liability Company Automatic adjustment of devices in a home entertainment system
US8761404B2 (en) 2006-09-07 2014-06-24 Porto Vinci Ltd. Limited Liability Company Musical instrument mixer
US8776147B2 (en) 2006-09-07 2014-07-08 Porto Vinci Ltd. Limited Liability Company Source device change using a wireless home entertainment hub
US8923749B2 (en) 2006-09-07 2014-12-30 Porto Vinci LTD Limited Liability Company Device registration using a wireless home entertainment hub
US8935733B2 (en) 2006-09-07 2015-01-13 Porto Vinci Ltd. Limited Liability Company Data presentation using a wireless home entertainment hub
US8966545B2 (en) 2006-09-07 2015-02-24 Porto Vinci Ltd. Limited Liability Company Connecting a legacy device into a home entertainment system using a wireless home entertainment hub
US8990865B2 (en) 2006-09-07 2015-03-24 Porto Vinci Ltd. Limited Liability Company Calibration of a home entertainment system using a wireless home entertainment hub
US9003456B2 (en) 2006-09-07 2015-04-07 Porto Vinci Ltd. Limited Liability Company Presentation of still image data on display devices using a wireless home entertainment hub
US9155123B2 (en) 2006-09-07 2015-10-06 Porto Vinci Ltd. Limited Liability Company Audio control using a wireless home entertainment hub
US9172996B2 (en) 2006-09-07 2015-10-27 Porto Vinci Ltd. Limited Liability Company Automatic adjustment of devices in a home entertainment system
US9185741B2 (en) 2006-09-07 2015-11-10 Porto Vinci Ltd. Limited Liability Company Remote control operation using a wireless home entertainment hub
US9191703B2 (en) 2006-09-07 2015-11-17 Porto Vinci Ltd. Limited Liability Company Device control using motion sensing for wireless home entertainment devices
US9233301B2 (en) 2006-09-07 2016-01-12 Rateze Remote Mgmt Llc Control of data presentation from multiple sources using a wireless home entertainment hub
US9270935B2 (en) 2006-09-07 2016-02-23 Rateze Remote Mgmt Llc Data presentation in multiple zones using a wireless entertainment hub
US9319741B2 (en) 2006-09-07 2016-04-19 Rateze Remote Mgmt Llc Finding devices in an entertainment system
US20080064396A1 (en) * 2006-09-07 2008-03-13 Technology, Patents & Licensing, Inc. Device Registration Using a Wireless Home Entertainment Hub
US9386269B2 (en) 2006-09-07 2016-07-05 Rateze Remote Mgmt Llc Presentation of data on multiple display devices using a wireless hub
US9398076B2 (en) 2006-09-07 2016-07-19 Rateze Remote Mgmt Llc Control of data presentation in multiple zones using a wireless home entertainment hub
US10277866B2 (en) 2006-09-07 2019-04-30 Porto Vinci Ltd. Limited Liability Company Communicating content and call information over WiFi
US10523740B2 (en) 2006-09-07 2019-12-31 Rateze Remote Mgmt Llc Voice operated remote control
US10674115B2 (en) 2006-09-07 2020-06-02 Rateze Remote Mgmt Llc Communicating content and call information over a local area network
US11050817B2 (en) 2006-09-07 2021-06-29 Rateze Remote Mgmt Llc Voice operated control device
US20090024774A1 (en) * 2007-07-18 2009-01-22 Samsung Electronics Co., Ltd. Network bridge device and bus reset control method thereof
US8571045B2 (en) * 2007-10-04 2013-10-29 U-Man Universal Media Access Networks Gmbh Data stream router
US20100284417A1 (en) * 2007-10-04 2010-11-11 Robby Gurdan Data stream router
US20090257416A1 (en) * 2008-04-09 2009-10-15 Ubiquisys Limited Access point
CN102916864A (zh) * 2012-11-02 2013-02-06 上海电机学院 一种以太网桥及其智能链接方法
US10785134B2 (en) * 2015-11-18 2020-09-22 Adobe Inc. Identifying multiple devices belonging to a single user
US11275789B2 (en) * 2017-07-12 2022-03-15 Groupon, Inc. Method, apparatus, and computer program product for inferring device rendered object interaction behavior

Also Published As

Publication number Publication date
JP2005522913A (ja) 2005-07-28
MXPA04009873A (es) 2004-12-07
WO2003085892A3 (en) 2004-03-04
EP1493250A2 (en) 2005-01-05
WO2003085892A2 (en) 2003-10-16
CN1647455A (zh) 2005-07-27
KR20040097296A (ko) 2004-11-17
AU2003240599A1 (en) 2003-10-20

Similar Documents

Publication Publication Date Title
US20050165965A1 (en) Methods for communication in a multi-cluster network, device for connection to a network of clusters and bridge for connecting clusters
KR100636380B1 (ko) 이종의 홈네트워크 미들웨어상에 접속해 있는 홈디바이스들간의 상호 연동을 위한 홈네트워크 범용미들웨어 브릿지 시스템 및 그 방법
US7085814B1 (en) Data driven remote device control model with general programming interface-to-network messaging adapter
Moon et al. Design of a universal middleware bridge for device interoperability in heterogeneous home network middleware
KR20020035645A (ko) 서버를 기초로한 다수 표준의 홈 네트워크 브리징
KR20020005771A (ko) ＵＰｎＰ 서브-네트워크와 ＨＡＶｉ 서브-네트워크를브릿징하는 방법 및 상기 방법을 구현하기 위한 장치
JPH11317751A (ja) 識別情報提供方法及び識別情報提供装置
WO2002051067A2 (en) Plug and play enabling device for heterogeneous networks of slave devices
CN1600001A (zh) Havi－upnp桥接
US20050078679A1 (en) Methods for establishing a connection between a first and a second device over a bridge connecting a havi-subnetwork to another subnetwork
US7933999B2 (en) Method and device for controlling HAVi standard devices by device control modules of an OSGi platform
US20060031570A1 (en) Network establishment and management protocol
JP4443225B2 (ja) ブリッジを有する通信ネットワークにおける接続を管理する方法及び装置
JP2005510181A (ja) ブリッジ装置を用いてＨＡＶｉクラスタとＩＰクラスタを接続する方法及び関連したブリッジ装置
KR100917287B1 (ko) 브릿지 디바이스를 포함하는 네트워크의 관리 방법 및 브릿지 디바이스
KR100689111B1 (ko) 통신 네트워크내의 객체관리 방법 및 이를 구현하는 장치
Kim et al. Internet home network electrical appliance control on the internet with the UPnP expansion
JP4163952B2 (ja) 通信システムにおけるコネクションの制御方法並びに該方法用の通信システム
KR100455123B1 (ko) ＵＰｎＰ 기반의 네트워크 시스템의 제어 메시지멀티캐스트 방법 및 장치
KR101134791B1 (ko) 이기종 네트워크 및 이기종 디바이스를 지원 가능한 다중 에이전트 기술에 기반한 홈 네트워크 시스템 및 홈 게이트웨이
KR101006920B1 (ko) 서브네트워크의 서비스 동적 상태 반영 방법
Metwly Common application programming interface architecture bridge for connecting heterogeneous home computing middleware.
Ishikawa et al. Peer-to-peer networking platform and its applications for mobile phones
Kim et al. Seamless network bridge for supporting interoperability upnp-zigbee
Kim et al. Home Network Electrical Appliance Control With The UPnP Expansion

Legal Events

Date Code Title Description
AS Assignment

Owner name: THOMSON LICENSING S.A., FRANCE

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:HENRY, JEAN-BAPTISTE;BICHOT, GUILLAUME;SIROT, JOEL;REEL/FRAME:016372/0375;SIGNING DATES FROM 20040903 TO 20040905

STCB Information on status: application discontinuation

Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION