US20070127470A1 - Interface link layer device to build a distributed network - Google Patents
Interface link layer device to build a distributed network Download PDFInfo
- Publication number
- US20070127470A1 US20070127470A1 US11/674,468 US67446807A US2007127470A1 US 20070127470 A1 US20070127470 A1 US 20070127470A1 US 67446807 A US67446807 A US 67446807A US 2007127470 A1 US2007127470 A1 US 2007127470A1
- Authority
- US
- United States
- Prior art keywords
- portal
- data
- destination
- data bus
- bus
- 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
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]
- H04L12/40—Bus networks
- H04L12/40052—High-speed IEEE 1394 serial bus
- H04L12/40058—Isochronous transmission
-
- 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
-
- 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
- H04L12/2832—Interconnection of the control functionalities between home 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
-
- 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/40097—Interconnection with other 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/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
- H04L12/00—Data switching networks
- H04L12/64—Hybrid switching systems
- H04L12/6418—Hybrid transport
-
- 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/08—Protocols for interworking; Protocol conversion
-
- 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/2838—Distribution of signals within a home automation network, e.g. involving splitting/multiplexing signals to/from different paths
-
- 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/40071—Packet processing; Packet format
-
- 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
Definitions
- the present invention relates to an interface link layer device which builds the core of an interface portal of an interface to which a network bus can be connected for the purpose of building a distributed network by at least one other network bus which is respectively connected to another interface portal of the same interface.
- FIG. 16 shows a coaxial interface between two IEEE1394 serial bus systems which is existing according to the prior art and for example described in the EP 0 848 568 A1 in a similar manner.
- An IEEE1394 serial bus 32 with three IEEE1394 serial bus nodes 36 is connected to a first coaxial interface portal 31 which communicates via a coaxial interface, i. e. a coaxial cable 33 , with a second coaxial interface portal 34 to which a second IEEE1394 serial bus 35 is connected which builds a network with two further IEEE1394 serial bus nodes 37 .
- Each of the IEEE1394 serial bus nodes 36 has a different node identifier as well as each of the further IEEE1394 serial bus nodes 37 .
- each of the first and second IEEE1394 serial busses 32 and 35 has a different bus identifier.
- the node identifiers and the bus Identifiers are assigned according to the IEEE1394 standard. Therewith, the combination of node identifier and bus identifier assigns a unique identifier to each of the serial bus nodes, even if one of the serial bus nodes 36 and one of the further serial bus nodes 37 has the same node identifier.
- Both IEEE1394 serial bus systems are independent from each other, but they can communicate through the coaxial interface portals and the coaxial interface.
- FIG. 17 shows a multiportal system in which three interface portals 31 , 34 and 38 are connected to one coaxial cable. Each of the interface portals 31 , 34 and 38 is connected to an IEEE1394 serial bus having a different bus identifier.
- each interface portal is built by a RF/1394 converter that is connected to a coaxial cable on one side and to an IEEE1394 bus on the other side.
- Said RF/1394 converter converts all incoming data from the IEEE1394 bus into an RF-signal output to the coaxial cable and vice versa converts all incoming RF-signals into data packets output to the connected IEEE1394 serial bus.
- the RF/1394 converter basically comprises a RF-modulator/demodulator, a link layer device and an IEEE1394 physical layer device.
- the link layer device Since in this case in the uplink channel basically all data packets received on the IEEE1394 serial bus are just set into another format and transmitted as RF-signal on a coaxial cable and vice versa in the downlink channel all incoming RF-signals are converted into data packets output to the IEEE1394 serial bus the link layer device has not to fulfill complicated tasks, but it only secures the timing requirements for the IEEE1394 serial bus.
- an interface link layer device that is connected to a first data bus and via a transmission path to at least one other interface link layer device that is respectively connected to a respective second data bus is characterized by uplink means to accept a data packet having a predetermined destination different to the interface link layer device itself from the first data bus and to transmit it via said transmission path to one of said other interface link layer devices that is serving said predetermined destination, and downlink means to output a data packet directly received via said transmission path from one of said at least one other interface link layer devices to a predetermined destination on the first data bus.
- This interface link layer device is defined in independent claim 1 . Preferred embodiments thereof are respectively defined in the dependent subclaims 2 to 33 .
- every data bus that builds a part of a distributed network is connected with an interface portal that comprises as its core an interface link layer device according to the present invention that directly communicates with all other interface link layer devices that are working according to the present invention and that build respectively the core of a respective interface portal respectively connected to a data bus building a respective other part of said distributed network.
- a data packet having a certain destination identifier is only delivered into such parts of the distributed network that comprise a receiver of this data packet.
- Such a distribution is preferably conducted on basis of the destination identifier, i. e. the destination identifier comprises not only the node identifier of the respective destination node, but also the parts of the distributed network in which said respective node is located, e. g. a bus identifier of the network bus serving said part of the distributed network.
- this inventive method which is defined in independent claim 34 is applicable to a distributed network that is set up according to the present invention so that data channels are set up from every part of the distributed network to every other part thereof to allow a communication from one part of the distribution network to a predetermined other part thereof that is defined in independent claim 35 .
- a preferred embodiment of such a distributed network is defined in dependent claim 36 .
- the present invention is used in an environment as described in the EP 0 848 568 A1, i. e. interconnects one or more separate IEEE1394 serial busses via coaxial interfaces, but it is also applicable to any other distributed network that is build through the interconnection of several individual networks respectively distributing data packets according to a predetermined standard to one distributed network.
- the individual networks need not all to work according to the same standard, i.e. the interface build with interface link layer devices according to the present invention can also interconnect networks working according to different standards.
- FIG. 1 shows an interface link layer device according to a preferred embodiment of the present invention
- FIG. 2 shows the inserting of an IEEE1394 serial bus packet with less than 180 bytes into a 204 byte MPEG 2 frame
- FIG. 3 shows the separating of an IEEE1394 serial bus packet with less than 180 bytes from a 204 byte MPEG 2 frame
- FIG. 4 shows the fragmentation of a large serial bus packet before the transmission over a coaxial cable
- FIG. 5 shows the defragmentation of a large serial bus packet after its transmission over the coaxial cable
- FIG. 6 shows the acknowledge handling for asynchronous packets according to a first example
- FIG. 7 shows the acknowledge handling for asynchronous packets according to a second example
- FIG. 8 shows the acknowledge handling for asynchronous packets according to a third example
- FIG. 9 shows the acknowledge handling for asynchronous packets according to a fourth example
- FIG. 10 shows a simplified distributed network using a coaxial cable
- FIG. 11 shows another simplified distributed network using a coaxial cable
- FIG. 12 shows an additional function unit for an interface link layer device according to the present invention.
- FIG. 13 shows a ring channel assignment of a distributed network with three connected IEEE1394 serial busses
- FIG. 14 shows a semi-hyper cube channel assignment of a distributed network with three connected IEEE1394 serial busses
- FIG. 15 shows a full-hyper cube channel assignment of a distributed network with three connected IEEE1394 serial busses
- FIG. 16 shows a distributed network with two IEEE1394 serial busses connected via a coaxial interface according to the prior art.
- FIG. 17 shows the interface part of a distributed network with three IEEE1394 serial busses that are interconnected via a coaxial interface according to the prior art.
- the interface link layer device also builds the core of a respective interface portal that connects a network bus to an interface of a distributed network, for the sake of simplicity the respective physical layer devices interconnected inbetween the interface link layer device and the respective physical network bus and transmission path are omitted in the description.
- the interface link layer devices according to the present invention might also include the standard featurs, e.g. according to the IEEE1394 standard, that are not mentioned in the following.
- the interface link layer device according to the present invention might be adapted to accept asynchronous packets with a destination identifier that is equal to the node identifier of the NODE_IDS register within its control and status registers as defined in the IEEE1394 specification, i.e. asynchronous packets that are addressd to the interface link layer device itself, and might also be adapted to insert asynchronous packets on its IEEE1394 bus, e. g. as response to such packets addressed to the interface link layer device itself.
- the exemplary embodiment described in the following shows the connection of two or more IEEE1394 serial busses 2 , 5 by a coaxial interface, i. e. by a coaxial cable 3 .
- a coaxial interface i. e. by a coaxial cable 3 .
- Such a system can for example be used in a home network environment in which individual IEEE1394 serial bus systems are installed in different rooms of a house and are interconnected via existing coaxial cables so that for example a video tape reproduced by a video recorder in one room of the house can be watched on a television set in another room of said house, as it is described in the EP 0 848 568 A1.
- the data packets carrying said video film are only transmitted to a predetermined television set in a predetermined room, i. e. to a predetermined node within a predetermined part of the distributed network, and not broadcasted through the whole network.
- an interface link layer device which is shown in FIG. 1 comprises an uplink section, a downlink section and an acknowledge/response section.
- the uplink section accepts data packets having predetermined destinations which are different to the interface link layer device 1 itself, i.e. the interface portal comprising the interface link layer device 1 , from a first data bus 2 and to transmit those data packets via a transmission path 3 , that might be a coaxial cable, to predetermined other interface link layer devices 4 respectively serving one of said predetermined destinations.
- the uplink section comprises a first register 12 which stores all allowed predetermined destinations, i. e. all destination identifiers of devices that can be reached through the coaxial cable and that are connected to another part of the distributed network, and a second register 15 which stores all data channel numbers set-up inbetween two nodes of the distributed network, i.e. inbetween two nodes located in different parts of the distributed network.
- the destination identifier Preferably not the destination identifiers themself, but only the bus identifier is stored and checked that defines a bus building one other part of the distributed network.
- a control section 11 monitors all asynchronous data packets that are received from the IEEE1394 serial bus 2 , compares their bus and/or node identifier with the bus and/or node identifiers stored in the first register 12 and opens or closes a switch 10 to lead an incoming asynchronous data packet to the further processing stages or to discard it depending on whether or not the destination identifier of the incoming packet matches with a destination identifier stored in the first register 12 .
- control section monitors all isochronous data packets that are received from the IEEE1394 serial bus 2 , compares their channel number with the channel number stored in the second register 15 and opens or closes said switch 10 to lead an incoming isochronous data packet to the further processing stages or to discard it depending on whether or not the channel number of the incoming packet matches with a channel number stored in the second register 15 .
- the first register 12 is preferably a BUS_ENABLE register which is a bitmap that represents whether or not transaction requests and responses are forwarded by the interface. For example, if bit 2 is set to one in the BUS_ENABLE register, the interface link layer is enabled to accept asynchronous data packets with a bus identifier of 2. If this bit is not set, the interface link layer device denies the packet as described above.
- the second register 15 is preferably a STREAM_CONTROL register which is similar organized as the first register 12 and has a corresponding function.
- the interface link layer device independently from this invention the interface link layer device always accepts data packets which destination identifier matches with its own node identifier, as every standard interface link layer device does.
- FIG. 2 shows the inserting of an IEEE1394 serial bus packet with a maximum of 180 bytes into a 204 byte frame according to the MPEG 2 standard.
- the IEEE1394 serial bus packet including its header, payload and cyclic redundancy code CRC is inserted as data block or part of the data block into one 204 byte frame according to the MPEG 2 standard. If the whole IEEE1394 serial bus packet comprises less than 180 bytes, i. e. less than the data block of the MPEG 2 frame, some stuff bytes will be added to fill this datablock.
- the whole MPEG 2 frame including its header, its data block which comprises the header, the payload and the cyclic redundancy code of the IEEE1394 serial bus packet and some stuff bytes, as well as a 16 byte Reed Solomon parity or another error detection/correction code is transmitted via the coaxial cable.
- FIG. 3 shows an example in which an IEEE1394 serial bus packet of 732 bytes in total, i. e. including header, payload and cyclic redundancy code is transmitted within four 204 byte frames according to the MPEG 2 standard on the coaxial cable which each consists of a 8 byte header, a 180 byte data block and a 16 byte Reed Solomon parity.
- the packetizer 13 is connected to said STREAM_CONTROL register 15 which stores beside the channel number of each isochronous channel the payload which defines the maximum number of quadlets that may be transmitted in a single isochronous packet and which corresponds to the data rate. This data is used by the packetizer 13 to properly set-up an isochronous channel according to the MPEG 2 standard on the coaxial cable 3 . Furtheron, the packetizer 13 is connected to a third register, namely a BANDWIDTH_AVAILABLE register which provides the available bandwidth on the coaxial cable 3 so that the packetizer 13 can check whether there is enoughbandwidth in case a new isochronous channel should be set-up or an asynchronous packet should be transmitted.
- a third register namely a BANDWIDTH_AVAILABLE register which provides the available bandwidth on the coaxial cable 3 so that the packetizer 13 can check whether there is enoughbandwidth in case a new isochronous channel should be set-up or an asynchronous packet should be transmitted.
- a further element of the uplink section is a fourth register 17 , namely an INTERFACE_CONTROL register which includes the node identifier of the interface link layer device connected to the other side of the distributed network, i.e. the other side of the coaxial cable 3 , and an Enable Bit to allow the direct routing of asynchronous packets through the coaxial cable 3 .
- the data packets to be output on the downlink channel(s) of the IEEE1394 serial bus 2 through the interface link layer device 1 are received through the connected transmission channel 3 from another interface link layer device 4 by the downlink section of the interface link layer device 1 .
- said data packets get repacked by a packet separator 20 into the IEEE1394 format which has a reverse operation in comparison with the packetizer 13 of the uplink section.
- the packet separator 20 takes the header, the payload and the cyclic redundancy code which belong to the IEEE1394 serial bus packet from the data block of the MPEG 2 frame and discards the stuff bytes which have been added by the packetizer 13 of the other interface link layer device 4 .
- the case that the IEEE1394 serial bus packet has a length of more than 188 bytes and needs a defragmentation after transmitting over the coaxial cable is shown in FIG. 5 .
- the IEEE1394 serial bus packet has a total length of 752 bytes and is therefore transmitted in the data blocks of 4 MPEG 2 frames.
- the data blocks of these 4 frames carry the header the payload and the cyclic redundancy code of the IEEE1394 serial bus packet which gets assembled in the packet separator 20 and distributed via the downlink channel(s) of the IEEE1394 serial bus 2 .
- the packetizer 13 Since the packetizer 13 adds stuff bytes to fill each data block of the 204 byte MPEG 2 frame and in case that there are no IEEE1394 packets to transmit via the coaxial cable a data block of the 204 byte MPEG frame consists only of stuff bytes the packet separator 20 receives a constant data stream from which the IEEE1394 packets get separated. As described above, divided IEEE1394 packets will be put together again and then, if not addressed to the outbound portal, i. e. the interface link layer device 1 itself, will be transmitted by the downlink section within the interface link layer device 1 to the connected IEEE1394 serial bus 2 to the destination node.
- the interface link layer device discards the complete packet. Also, if an error occurs during transmission via the coaxial cable the packet will be discarded. In these cases a device which waits for said packet, since it has requested a certain transaction, generates a split timeout error which is an indicator that the certain transaction should be requested again.
- the minimum timeout value for a split timeout is 100 ms.
- the downlink section comprises a channel number assignment unit 21 that assigns a new channel number to isochronous packets which origin in a channel of the data bus that hosts the originator of said packets which channel number is already occupied for another data stream within the IEEE1394 serial bus 2 that is connected to the interface link layer device 1 and serves the receiver of said packets.
- the interface link layer device does not just forward incoming acknowledge packets to their destination, but sets up an own acknowledgement and response strategy. Therefore, acknowledge packets that are received via the IEEE1394 serial bus 2 are not just forwarded through the coaxial cable 3 to the interface link layer device connected to the network bus to which the destination device is connected, but the incoming acknowledge packet gets analysed by said interface link layer device which then decides which kind of action, i. e. acknowledgement and/or response is necessary to which device.
- the acknowledge/response section of the interface link layer device 1 comprises an acknowledge code generator 18 that serves the inbound behaviour and a response packet generator 19 that serves the outbound behaviour.
- the acknowledge code generator 18 receives all accepted data packets through the uplink channel(s) of the IEEE1394 serial bus 2 and generates appropriate acknowledge codes to be output on the downlink channel(s) of the IEEE1394 serial bus 2 . Therefore, according to the present invention, an acknowledge code is not only generated when a packet which is to be transmitted to another part of the distributed network, i. e. another IEEE1394 serial bus, through the coaxial cable 3 reaches its destination, but also when such a packet reaches the inbound portal, i. e. the inter-face link layer device 1 , of the transmission channel, i. e. the coaxial cable 3 .
- the response packet generator 19 that monitors the uplink and downlink channel(s) of the connected IEEE1394 serial bus 2 generates an appropriate response packet to be output with an appropriate speed to a particular destination device via the coaxial cable 3 in case a request was transmitted to the connected IEEE1394 serial bus 2 and a corresponding acknowledge code is received from the connected IEEE1394 serial bus 2 .
- the acknowledge code generator 18 sends an acknowledge to the originator of a packet received via the connected IEEE1394 serial bus 2 for each accepted asynchronous packet that is either addressed to the node controller of the interface link layer device 1 or to a node on the other side of the coaxial cable 3 , e.g. a node connected to another IEEE1394 serial bus 5 within the distributed network.
- the following table 1 gives an overview about the outbound behaviour of the interface link layer device concerning the acknowledge.
- a “-” sign within the table indicates that the respective content does not matter, but differs from 3F or 3FF.
- 3 F and 3 FF are hexadecimal values which are reserved within the IEEE 1394 standard for special purposes.
- the Enable Bit is located in the INTERFACE_CONTROL register 17 , as stated above.
- Enable Destination Source Bit Bus ID PHY ID Bus ID Action 3FF or — — Local packet.
- Acknowledge Node_IDS.bus_ID per IEEE1394-1995 standard. 0 Neither 3FF nor — — Routing disabled.
- Ignore Node_IDS.bus_ID packet no Acknowledge. 1 — — 3FF Unable to route.
- Ignore packet no acknowledge. 1 3FF 3F Not 3FF Global broadcast.
- Forward packet no acknowledge. 1 Neither 3FF nor — Node_IDS.bus_ID Remote packet origination. Forward packet according to BUS_ENABLE, transmit ack_pending or ack_complete.
- Node_IDS.bus_ID Neither 3FF nor Remote packet in transit.
- Node_IDS.bus_ID Forward packet and transmit ack_pending or ack_complete. All other combinations Unable to route. Ignore packet, no acknowledge
- the generated acknowledge code depends on the destination identifier, the transaction code and the cyclic redundancy code of an incoming packet. If a received packet is a request and to be routed through the interface, the acknowledge code generator 18 always generates an acknowledge code that indicates a pending action, e. g. ack_pending, for the indicator of the request. In case of an error the acknowledge code generator 18 generates a data error acknowledgement, e. g. ack_data_error, and an acknowledgement that indicates a completed action will be generate in case the received packet is a response packet without any errors, e. g. ack_complete. This behaviour of split transactions is necessary, since in most cases there would be no unified transaction possible over interfaces for time reasons, because the originator of a packet expects an acknowledge code for this packet within a certain time limit, e.g. 50 ms.
- a certain time limit e.g. 50 ms.
- the outbound behaviour is controlled by the response packet generator 19 . Every time an asynchronous packet, i.e. a request packet, was transmitted through the coaxial cable to a predetermined destination on the connected IEEE1394 serial bus the incoming corresponding acknowledge packet is received by the response packet generator 19 from the connected IEEE1394 serial bus 2 and it is decided whether or not an appropriate response is output via the coaxial cable 3 to the originator of a request that has triggered the acknowledge, as shown in the following table 2.
- Name (incoming acknowledgement) Action ack_complete Request: Transmit the appropriate response packet. Response: No action. ack_pending ack_busy_X
- the bridge abandons retry attempts: ack_busy_A Request: Transmit the appropriate response packet.
- ack_data_error Request Transmit the appropriate response packet.
- ack_type_error Response No action.
- the response packet generator 19 monitors all accepted acknowledge packets that are incoming via the connected IEEE1394 serial bus 2 to provide an appropriate response packet as an asynchronous response packet for the originator of the request packet. Furtheron, the response packet generator 19 has to monitor all request packets output to the connected IEEE1394 serial bus 2 . To monitor all incoming and outgoing packets the response packet generator 19 stores different components of the asynchronous packet header, e.g. the source and destination of a packet, the source as new destination and the destination as new source.
- the appropriate response packet will only be generated by the response packet generator 19 if the asynchronous packet transmitted via the coaxial cable 3 to a predetermined destination on the connected IEEE1394 serial bus 2 was a write request and the response packet generator 19 received an acknowledge that indicates a completed action from the predetermined destination, i.e. the receiver of said request.
- the receiver of the asynchronous packet has to create the appropriate response packet which will be forwarded by the other interface link layer device 4 through the coaxial cable 3 to the interface link layer device that is connected to the IEEE1394 serial bus serving the originator of the corresponding request packet.
- FIGS. 6 to 9 respectively show an example in which a first IEEE1394 node 6 is connected via a first IEEE1394 serial bus 2 to a first interface link layer device according to the present invention which is connected through a coaxial cable 3 to a second interface link layer device 4 according to the present invention that is connected to a second IEEE1394 serial bus 5 which serves a second IEEE1394 node 7 .
- the first node 6 distributes in a first step S 61 a request to the second node 7 on the first serial bus 2 it is connected to. Such a request is send as an asynchronous packet.
- a second step S 62 the first interface link layer device 1 receives that request and accepts it, since the identifier of the second node 7 is stored in its first register 12 , i. e. the BUS_ENABLE register.
- the acknowledge code generator 18 of the first interface link layer device 1 transmits an acknowledgement indicating a pending action, i.e. ack_pending, to the first node 6 and tranfers the request via the coaxial cable 3 to the second interface link layer device 4 according to the MPEG 2 standard.
- a third step S 63 the second interface link layer device 4 receives the request, repacks it with its packet separator 20 and transmits it via the connected second serial bus 5 to the second node 7 .
- the second node 7 indicates in a fourth step S 64 a completed action with an acknowledgement, i.e. ack_complete, directed to the requesting first node 6 .
- This acknowledgement code is distributed on the second serial bus 5 which is connected to the second node 7 .
- the second interface link layer device 4 receives and accepts the acknowledge packet from the second node 7 , since its destination identifier is stored in its first register 12 , i.e. its BUS_ENABLE register.
- the response packet generator 19 of the second interface link layer device 4 generates an appropriate response packet and transmits it via the coaxial cable 3 to the first interface link layer device 1 which distributes it after an appropriate repacking with its packet separator 20 to the first node 6 via the first serial bus 2 in a sixth step S 66 .
- the first node 6 sends an completed action acknowledgement code to the second node 7 via the connected first serial bus 2 which is received and accepted by the first interface link layer device 1 which accepts and discards it and therewith finalizes the action.
- the first node 6 distributes in a first step S 71 a request to the second node 7 on the first serial bus 2 it is connected to as an asynchronous packet.
- the first interface link layer device 1 receives that request and accepts it, since the identifier of the second node 7 is stored in its first register 12 , i. e. the BUS_ENABLE register.
- the acknowledge code generator 18 of the first interface link layer device 1 transmits an acknowledgement indicating a pending action, i.e. ack_pending, to the first node 6 and tranfers the request via the coaxial cable 3 to the second interface link layer device 4 according to the MPEG 2 standard.
- a third step S 63 the second interface link layer device 4 receives the request, repacks it with its packet separator 20 and transmits it via the connected second serial bus 5 to the second node 7 .
- the second node 7 indicates in a fourth step S 74 a pending action with an acknowledgement, i.e. ack_pending, directed to the requesting first node 6 .
- This acknowledgement code is distributed on the second serial bus 5 which is connected to the second node 7 .
- the second node 7 generates a response to the request received in the third step S 73 that is directed to the requesting first node 6 .
- This response is distributed on the second serial bus 5 which is connected to the second node 7 and received and accepted by the second interface link layer device 4 , since its destination identifier is stored in its first register 12 , i.e. its BUS_ENABLE register.
- the acknowledge code generator 18 of the second interface link layer device 4 transmits an acknowledge code indicating a completed action, i.e ack_complete, to the second node, since the second interface link layer device has received the response without any errors.
- the second interface link layer device 4 Since the response, which indicates a completed action, is no acknowledge code the second interface link layer device 4 transmits said packet after repacking by its packetizer 13 via the coaxial cable 3 to the first interface link layer device 1 which distributes it after an appropriate repacking with its packet separator 20 to the first node 6 via the first serial bus 2 in a seventh step S 77 .
- the first node 6 sends an completed action acknowledgement code to the second node 7 via the connected first serial bus 2 which is received and accepted by the first interface link layer device 1 which accepts and discards it and therewith finalizes the action.
- the timeout value of the first node 6 to wait from the received ack_pending acknowledgement to the response should be set >100 ms.
- the first node 6 distributes in a first step S 81 a request to the second node 7 on the first serial bus 2 it is connected to as an asynchronous packet.
- a second step S 82 the first interface link layer device 1 receives that request and accepts it, since the identifier of the second node 7 is stored in its first register 12 , i. e. the BUS_ENABLE register.
- the acknowledge code generator 18 of the first interface link layer device 1 transmits an acknowledgement indicating a pending action, i.e. ack_pending, to the first node 6 and tranfers the request via the coaxial cable 3 to the second interface link layer device 4 according to the MPEG 2 standard.
- a third step S 83 the second interface link layer device 4 receives the request, repacks it with its packet separator 20 and transmits it via the connected second serial bus 5 to the second node 7 .
- the second node 7 indicates in a fourth step S 84 that it is busy with an acknowledgement, i.e. ack_busy, directed to the requesting first node 6 .
- This acknowledgement code is distributed on the second serial bus 5 which is connected to the second node 7 .
- the second interface link layer device 4 receives and accepts the acknowledge packet from the second node 7 , since its destination identifier is stored in its first register 12 , i.e. its BUS_ENABLE register.
- the response packet generator 19 of the second interface link layer device 4 generates an appropriate response packet and transmits it via the coaxial cable 3 to the first interface link layer device 1 which distributes it after an appropriate repacking with its packet separator 20 to the first node 6 via the first serial bus 2 in a sixth step S 86 .
- the first node 6 sends an completed action acknowledgement code to the second node 7 via the connected first serial bus 2 which is received and accepted by the first interface link layer device 1 which accepts and discards it and therewith finalizes the action.
- the first node 6 distributes in a first step S 91 a request to the second node 7 on the first serial bus 2 it is connected to as an asynchronous packet.
- a second step S 92 the first interface link layer device 1 receives that request and accepts it, since the identifier of the second node 7 is stored in its first register 12 , i. e. the BUS_ENABLE register.
- the acknowledge code generator 18 of the first interface link layer device 1 transmits an acknowledgement indicating a pending action, i.e. ack_pending, to the first node 6 and tranfers the request via the coaxial cable 3 to the second interface link layer device 4 according to the MPEG 2 standard.
- a third step S 83 the second interface link layer device 4 receives the request repacks it with its packet separator 20 and transmits it via the connected second serial bus 5 to the second node 7 .
- the second node 7 indicates in a fourth step S 84 a data error with an acknowledge code, i.e. ack_data_error, directed to the requesting first node 6 .
- This acknowledgement code is distributed on the second serial bus 5 which is connected to the second node.
- the second interface link layer device 4 receives and accepts the acknowledge packet from the second node 7 , since its destination identifier is stored in its first register 12 , i.e. its BUS_ENABLE register.
- the response packet generator 19 of the second interface link layer device 4 generates an appropriate response packet and transmits it via the coaxial cable 3 to the first interface link layer device 1 which distributes it after an appropriate repacking with its packet separator 20 to the first node 6 via the first serial bus 2 in a sixth step S 86 .
- the first node 6 sends an completed action acknowledgement code to the second node 7 via the connected first serial bus 2 which is received and accepted by the first interface link layer device 1 which accepts and discards it and therewith finalizes the action.
- the interface link layer device which is connected to a respective IEEE1394 serial bus and a respective coaxial cable through respective physical layer devices provides accepted packets that should be transmitted via the interface as complete packets to the coaxial cable.
- a complete packet consists of the header, the data block and the cyclic redundancy codes.
- the transmission of the complete packet through the coaxial cable 3 is necessary, because the corresponding interface link layer device connected to another network bus of the distributed network needs the information of the packets for the transmission on said other serial bus.
- the interface link layer device according to the present invention introduced the concept that not all packets have to be transmitted via the interface, since an appropriate acknowledge code and response code generation of the interface link layer device itself is introduced.
- Such arrangements comprise one first IEEE1394 serial bus 2 which can have any number of controller nodes 6 connected. This is called the multidevice side.
- first IEEE1394 serial bus 2 which can have any number of controller nodes 6 connected. This is called the multidevice side.
- FIG. 10 there are two IEEE1394 serial bus nodes 6 and one interface link layer device 1 (which is also a node within the IEEE1394 system) connected to the first IEEE1394 serial bus 2 .
- a second IEEE1394 serial bus 5 Via a coaxial cable 3 and a second interface link layer device 4 there is connected a second IEEE1394 serial bus 5 .
- this second IEEE1394 serial bus 5 is allowed to have only one single IEEE1394 serial bus node 7 connected. This is called the single-device side.
- the interface link layer device 1 looks like the single IEEE1394 serial bus node 7 connected to the first interface link layer device 1 via the coaxial interface 3 , the second interface link layer device 5 and the second IEEE1394 serial bus 5 .
- FIG. 10 shows also the node identifiers of all serial bus nodes connected to both IEEE1394 serial busses 2 and 5 which are automatically assigned after a bus reset.
- the multi-device side comprises two controller nodes 6 , one has a node ID 0 and the other has a node ID 2 .
- the first interface link layer device 1 connected to the first IEEE1394 serial bus 2 has a node ID 1 .
- the single-device side is build by a controller node 7 having a node ID 0 and the second interface link layer device 4 having a node ID 1 .
- the destination node ID within asynchronous packets of a controller node 6 connected to the first IEEE1394 serial bus 2 to the single-device side has to be changed from the node ID of the first interface link layer device 1 on the multi-device side, 1 in FIG. 10 , to the node ID of the single controller node 7 on the single device side, 0 in FIG. 10 .
- the source node ID remains unchanged for this communication direction.
- the source node ID has to be changed from the node ID of the single controller node 7 , 0 in FIG. 10 , to the node ID of the interface link layer device 1 on the multi-device side, 1 in FIG. 10 .
- the destination ID remains unchanged for this communication direction.
- a possible implementation can be realized by providing two additional registers within the second interface link layer device 4 of the single-device side.
- the first additional register stores the node ID of the first interface link layer device 1 on the multi-device side and the second additional register stores the node ID of the single controller node 7 on the single-device side.
- the second interface link layer device 4 has then to replace the destination node identifier before sending a packet to the second IEEE1394 serial bus 5 using the value of the second additional register and to replace the source node identifier using the value of the first register before sending a packet to the coaxial cable 3 .
- the first interface link layer device 1 connected to the multi-device side requires only the modification to forward packets directed to itself through the coaxial cable to the second interface link layer device, i.e. to forward packets with destination node identifiers that are identical to its own node identifier.
- the second interface link layer device 4 on the single-device side has to operate in a special mode, because it has to accept and forward packets with destination node identifiers that are not identical to its own node identifier.
- FIG. 11 shows an example where two separate single remote nodes 7 A, 7 B are connected to a coaxial cable network 3 .
- two first interface link layer devices 1 A, 1 B are required on the multidevice side, i. e. connected to the first IEEE1394 serial bus 2 , which respectively communicate with a corresponding second interface link layer device 4 A, 4 B through the coaxial cable 3 which is in turn connected to a respective single remote node 7 A, 7 B through a respective second IEEE 1394 serial bus 5 A, 5 B.
- FIGS. 13 to 15 show that more than two interface link layer devices can be connected to the coaxial cable 3 similar to the distributed prior art network shown in FIG. 17 . It is shown that three interface link layer devices are connected to one coaxial cable 3 , namely a first interface link layer device 1 , a second interface link layer device 4 and a third interface link layer device 8 . Every interface link layer device is also connected to a respective IEEE1394 serial bus and each of these IEEE1394 serial busses has been assigned a different bus identifier.
- a bi-directional communication between all busses is enabled and data that is not needed on a certain IEEE1394 serial bus will not be seen there.
- channels are assigned in frequency division multiplex with every channel occupying a certain bandwidth so that a large number of channels is simultaneously available.
- an additional function unit as shown in FIG. 12 and described in the following can be implemented inside an interface link layer device according to the present invention.
- the downstream path from the coaxial cable 3 to the interface link layer device and the upstream path from the interface link layer device to the coaxial cable 3 can be connected if necessary by a first additional switch 16 a which is controlled by the controller 11 which is additionally connected to the downstream path.
- Asynchronous IEEE1394 packets taking this route will not be seen on the IEEE1394 serial bus this interface link layer device is connected to, since a second additional switch 16 b which is also controlled by the controller 11 and which connects the downstream path with the packet separator 20 is open in this case.
- the controller 11 monitors the incoming downstream packets to control the first and second additional switches 16 a and 16 b according to the destination address of the packet.
- the switch position shown in FIG. 12 in which the first additional switch 16 a is open and the second additional switch 16 b is closed indicates the case when a packet is destined to the IEEE1394 serial bus this interface link layer device is a member of. As described above, the first additional switch 16 a will close and the second additional switch 16 b will open for packets destined to other bus numbers.
- such a functionality can alternatively also be included in the packet separator 20 which needs then a connection to the upstream path, e.g. directly or via the packetizer 13 , and in order to know how to distribute the received packets also to the controller 11 .
- FIG. 13 shows a ring channel assignment for the distributed IEEE1394 serial bus network according to which the data links between all the interface link layer devices connected to the coaxial cable 3 are arranged in a ring.
- every interface requires one transmission and one reception channel.
- the first interface link layer device 1 transmits on channel 1 and receives on channel 3
- the second interface link layer device 4 transmits on channel 2 and receives on channel 1
- the third interface link layer device 8 transmits on channel 3 and receives on channel 2 .
- n interfaces n channel on the coaxial cable are required. With this channel assignment there is no need to re-configure the data links on the coaxial cable 3 on the fly.
- FIG. 14 shows a semi-hyper-cube channel assignment for the distributed IEEE1394 serial bus network which assures a data link from every interface link layer device to every other interface link layer device. To save channels every interface link layer device transmits on just one channel via the coaxial cable 3 and reception is done on all the other channels used for transmission by the other interface link layer devices.
- the first interface link layer device 1 transmits on channel 1 and receives on channels 2 and 3
- the second interface link layer device 4 transmits on channel 2 and receives on channels 1 and 3
- the third interface link layer device 8 transmits on channel 3 and receives on channels 1 and 2 .
- every interface link layer device requires one transmission and (n ⁇ 1) reception channels in case of n interface link layer devices. Therefore, n channels on the coaxial network are required. If said data links are desired, one interface link layer device must have (n ⁇ 1) front end modules. Therefore, it is desirable to have a dynamic channel assignment scheme.
- FIG. 15 shows the full-hyper-cube channel assignment for the distributed IEEE1394 serial bus network which assures a data link from every interface link layer device to every other interface link layer device.
- the full-hypercube channel assignment one transmission and one reception channel are set up inbetween each two interface link layer devices. Therefore, the additional functionality of the interface link layer device 1 as shown in FIG. 12 and described in connection therewith is not necessary.
- the first interface link layer device 1 transmits on channel 1 to the second interface link layer device 4 and on channel 2 to the third interface link layer device 8 , and receives on channel 3 from the second interface link layer device 4 and on channel 5 from the third interface link layer device 8 .
- the second interface link layer device 4 transmits on channel 3 to the first interface link layer device 1 and on channel 4 to the third interface link layer device 8 , and receives on channel 1 from the first interface link layer device 1 and on channel 6 from the third interface link layer device 8 .
- the third interface link layer device 8 transmits on channel 5 to the first interface link layer device 1 and on channel 6 to the second interface link layer device 4 , and receives on channel 2 from the first interface link layer device and on channel 4 from the second interface link layer device 4 .
- every interface link layer device requires (n ⁇ 1) transmission and (n ⁇ 1) reception channels. Therefore, for n interface link layer devices n ⁇ (n ⁇ 1) channels on the coaxial cable 3 are required.
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Automation & Control Theory (AREA)
- Computing Systems (AREA)
- Computer Security & Cryptography (AREA)
- Small-Scale Networks (AREA)
- Information Transfer Systems (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
An interface link layer device (1) of an interface which allows the interconnection of different networks to build a distributed network according to the present invention routes complete data packets directly to another interface link layer device (1) that serves the destination via uplink means (10, 11, 12, 13, 14, 17) to accept a data packet from a first data bus (2) that has a predetermined destination on a second data bus and to transmit it via said transmission path (3) to said other interface link layer device (1), and downlink means (20, 21) to output data packets received via said transmission path (3) from one other interface link layer device (1) to a predetermined destination on the first data bus (2). Furtheron, the interface link layer device according to the present invention introduces the concept that not all packets have to be transmitted via the interface on basis of an appropriate acknowledge code and response packet generation of an acknowledge/response means (18, 19) included in the interface link layer device. The present invention is in particular applicable to build up a disrtibuted network on basis of several IEEE 1394 networks that are interconnected via an interface consisting of a coaxial cable.
Description
- The present invention relates to an interface link layer device which builds the core of an interface portal of an interface to which a network bus can be connected for the purpose of building a distributed network by at least one other network bus which is respectively connected to another interface portal of the same interface.
-
FIG. 16 shows a coaxial interface between two IEEE1394 serial bus systems which is existing according to the prior art and for example described in theEP 0 848 568 A1 in a similar manner. An IEEE1394serial bus 32 with three IEEE1394serial bus nodes 36 is connected to a firstcoaxial interface portal 31 which communicates via a coaxial interface, i. e. acoaxial cable 33, with a secondcoaxial interface portal 34 to which a second IEEE1394serial bus 35 is connected which builds a network with two further IEEE1394serial bus nodes 37. Each of the IEEE1394serial bus nodes 36 has a different node identifier as well as each of the further IEEE1394serial bus nodes 37. Furtheron, each of the first and second IEEE1394serial busses serial bus nodes 36 and one of the furtherserial bus nodes 37 has the same node identifier. Both IEEE1394 serial bus systems are independent from each other, but they can communicate through the coaxial interface portals and the coaxial interface. -
FIG. 17 shows a multiportal system in which threeinterface portals interface portals - As mentioned above, such systems are described in
EP 0 848 568 A1 according to which each interface portal is built by a RF/1394 converter that is connected to a coaxial cable on one side and to an IEEE1394 bus on the other side. Said RF/1394 converter converts all incoming data from the IEEE1394 bus into an RF-signal output to the coaxial cable and vice versa converts all incoming RF-signals into data packets output to the connected IEEE1394 serial bus. To fulfill this task the RF/1394 converter basically comprises a RF-modulator/demodulator, a link layer device and an IEEE1394 physical layer device. Since in this case in the uplink channel basically all data packets received on the IEEE1394 serial bus are just set into another format and transmitted as RF-signal on a coaxial cable and vice versa in the downlink channel all incoming RF-signals are converted into data packets output to the IEEE1394 serial bus the link layer device has not to fulfill complicated tasks, but it only secures the timing requirements for the IEEE1394 serial bus. - However, according to this prior art many resources are wasted, since all data packets that are available as RF-signals on the coaxial cable as well as all data packets that are present on any one of the IEEE1394 serial busses are distributed within the whole network.
- Therefore, it is the object of the present invention to provide an interface link layer device that enables the interconnection of different networks to one distributed network while saving resources on said network.
- Therefore, an interface link layer device according to the present invention that is connected to a first data bus and via a transmission path to at least one other interface link layer device that is respectively connected to a respective second data bus is characterized by uplink means to accept a data packet having a predetermined destination different to the interface link layer device itself from the first data bus and to transmit it via said transmission path to one of said other interface link layer devices that is serving said predetermined destination, and downlink means to output a data packet directly received via said transmission path from one of said at least one other interface link layer devices to a predetermined destination on the first data bus.
- This interface link layer device according to the present invention is defined in
independent claim 1. Preferred embodiments thereof are respectively defined in thedependent subclaims 2 to 33. - Therewith, according to the present invention every data bus that builds a part of a distributed network is connected with an interface portal that comprises as its core an interface link layer device according to the present invention that directly communicates with all other interface link layer devices that are working according to the present invention and that build respectively the core of a respective interface portal respectively connected to a data bus building a respective other part of said distributed network. With such a configuration according to the present invention a data packet having a certain destination identifier is only delivered into such parts of the distributed network that comprise a receiver of this data packet. Such a distribution is preferably conducted on basis of the destination identifier, i. e. the destination identifier comprises not only the node identifier of the respective destination node, but also the parts of the distributed network in which said respective node is located, e. g. a bus identifier of the network bus serving said part of the distributed network.
- Therewith, this inventive method which is defined in
independent claim 34 is applicable to a distributed network that is set up according to the present invention so that data channels are set up from every part of the distributed network to every other part thereof to allow a communication from one part of the distribution network to a predetermined other part thereof that is defined inindependent claim 35. A preferred embodiment of such a distributed network is defined independent claim 36. - Preferably, the present invention is used in an environment as described in the
EP 0 848 568 A1, i. e. interconnects one or more separate IEEE1394 serial busses via coaxial interfaces, but it is also applicable to any other distributed network that is build through the interconnection of several individual networks respectively distributing data packets according to a predetermined standard to one distributed network. Of course, the individual networks need not all to work according to the same standard, i.e. the interface build with interface link layer devices according to the present invention can also interconnect networks working according to different standards. - The present invention and its embodiments will be better understood from a detailed description of an exemplary embodiment thereof taken in conjunction with the accompanying drawings, wherein
-
FIG. 1 shows an interface link layer device according to a preferred embodiment of the present invention; -
FIG. 2 shows the inserting of an IEEE1394 serial bus packet with less than 180 bytes into a 204byte MPEG 2 frame; -
FIG. 3 shows the separating of an IEEE1394 serial bus packet with less than 180 bytes from a 204byte MPEG 2 frame; -
FIG. 4 shows the fragmentation of a large serial bus packet before the transmission over a coaxial cable; -
FIG. 5 shows the defragmentation of a large serial bus packet after its transmission over the coaxial cable; -
FIG. 6 shows the acknowledge handling for asynchronous packets according to a first example; -
FIG. 7 shows the acknowledge handling for asynchronous packets according to a second example; -
FIG. 8 shows the acknowledge handling for asynchronous packets according to a third example; -
FIG. 9 shows the acknowledge handling for asynchronous packets according to a fourth example; -
FIG. 10 shows a simplified distributed network using a coaxial cable; -
FIG. 11 shows another simplified distributed network using a coaxial cable; -
FIG. 12 shows an additional function unit for an interface link layer device according to the present invention; -
FIG. 13 shows a ring channel assignment of a distributed network with three connected IEEE1394 serial busses; -
FIG. 14 shows a semi-hyper cube channel assignment of a distributed network with three connected IEEE1394 serial busses; -
FIG. 15 shows a full-hyper cube channel assignment of a distributed network with three connected IEEE1394 serial busses; -
FIG. 16 shows a distributed network with two IEEE1394 serial busses connected via a coaxial interface according to the prior art; and -
FIG. 17 shows the interface part of a distributed network with three IEEE1394 serial busses that are interconnected via a coaxial interface according to the prior art. - Although the interface link layer device according to the present invention also builds the core of a respective interface portal that connects a network bus to an interface of a distributed network, for the sake of simplicity the respective physical layer devices interconnected inbetween the interface link layer device and the respective physical network bus and transmission path are omitted in the description.
- Furtheron, the following description refers only to features that are not present in standard link layer devices. Of course, the interface link layer devices according to the present invention might also include the standard featurs, e.g. according to the IEEE1394 standard, that are not mentioned in the following. For example, the interface link layer device according to the present invention might be adapted to accept asynchronous packets with a destination identifier that is equal to the node identifier of the NODE_IDS register within its control and status registers as defined in the IEEE1394 specification, i.e. asynchronous packets that are adressed to the interface link layer device itself, and might also be adapted to insert asynchronous packets on its IEEE1394 bus, e. g. as response to such packets addressed to the interface link layer device itself.
- The exemplary embodiment described in the following shows the connection of two or more IEEE1394
serial busses coaxial cable 3. Such a system can for example be used in a home network environment in which individual IEEE1394 serial bus systems are installed in different rooms of a house and are interconnected via existing coaxial cables so that for example a video tape reproduced by a video recorder in one room of the house can be watched on a television set in another room of said house, as it is described in theEP 0 848 568 A1. In contrast to the system described in this document according to the present invention the data packets carrying said video film are only transmitted to a predetermined television set in a predetermined room, i. e. to a predetermined node within a predetermined part of the distributed network, and not broadcasted through the whole network. - To facilitate this an interface link layer device according to a preferred embodiment of the present invention which is shown in
FIG. 1 comprises an uplink section, a downlink section and an acknowledge/response section. - The uplink section accepts data packets having predetermined destinations which are different to the interface
link layer device 1 itself, i.e. the interface portal comprising the interfacelink layer device 1, from afirst data bus 2 and to transmit those data packets via atransmission path 3, that might be a coaxial cable, to predetermined other interfacelink layer devices 4 respectively serving one of said predetermined destinations. To filter such data packets the uplink section comprises afirst register 12 which stores all allowed predetermined destinations, i. e. all destination identifiers of devices that can be reached through the coaxial cable and that are connected to another part of the distributed network, and asecond register 15 which stores all data channel numbers set-up inbetween two nodes of the distributed network, i.e. inbetween two nodes located in different parts of the distributed network. - Preferably not the destination identifiers themself, but only the bus identifier is stored and checked that defines a bus building one other part of the distributed network.
- A
control section 11 monitors all asynchronous data packets that are received from the IEEE1394serial bus 2, compares their bus and/or node identifier with the bus and/or node identifiers stored in thefirst register 12 and opens or closes aswitch 10 to lead an incoming asynchronous data packet to the further processing stages or to discard it depending on whether or not the destination identifier of the incoming packet matches with a destination identifier stored in thefirst register 12. Furtheron, the control section monitors all isochronous data packets that are received from the IEEE1394serial bus 2, compares their channel number with the channel number stored in thesecond register 15 and opens or closes said switch 10 to lead an incoming isochronous data packet to the further processing stages or to discard it depending on whether or not the channel number of the incoming packet matches with a channel number stored in thesecond register 15. - The
first register 12 is preferably a BUS_ENABLE register which is a bitmap that represents whether or not transaction requests and responses are forwarded by the interface. For example, ifbit 2 is set to one in the BUS_ENABLE register, the interface link layer is enabled to accept asynchronous data packets with a bus identifier of 2. If this bit is not set, the interface link layer device denies the packet as described above. Thesecond register 15 is preferably a STREAM_CONTROL register which is similar organized as thefirst register 12 and has a corresponding function. Of course, as mentioned above, independently from this invention the interface link layer device always accepts data packets which destination identifier matches with its own node identifier, as every standard interface link layer device does. - The accepted IEEE1394 packets which should be transmitted via the coaxial cable to another part of the network are received by a
packetizer 13 that repacks them into a data format suitable for the transmission channel, i. e. the transmission via the coaxial cable. Such a repacking is shown in detail in the following in connection withFIGS. 2 and 3 .FIG. 2 shows the inserting of an IEEE1394 serial bus packet with a maximum of 180 bytes into a 204 byte frame according to theMPEG 2 standard. Since it is possible to transmit a data block of 180 bytes in the first packet of a section according to theMPEG 2 standard, the IEEE1394 serial bus packet including its header, payload and cyclic redundancy code CRC is inserted as data block or part of the data block into one 204 byte frame according to theMPEG 2 standard. If the whole IEEE1394 serial bus packet comprises less than 180 bytes, i. e. less than the data block of theMPEG 2 frame, some stuff bytes will be added to fill this datablock. Then thewhole MPEG 2 frame including its header, its data block which comprises the header, the payload and the cyclic redundancy code of the IEEE1394 serial bus packet and some stuff bytes, as well as a 16 byte Reed Solomon parity or another error detection/correction code is transmitted via the coaxial cable. - If, on the other hand a large serial bus packet should be transmitted over the
coaxial cable 3 which has more than 180 bytes in total, a fragmentation has to be performed before it is transmitted over thecoaxial cable 3. Such a fragmentation is shown inFIG. 3 .FIG. 3 shows an example in which an IEEE1394 serial bus packet of 732 bytes in total, i. e. including header, payload and cyclic redundancy code is transmitted within four 204 byte frames according to theMPEG 2 standard on the coaxial cable which each consists of a 8 byte header, a 180 byte data block and a 16 byte Reed Solomon parity. - As can be seen in
FIG. 1 , thepacketizer 13 is connected to saidSTREAM_CONTROL register 15 which stores beside the channel number of each isochronous channel the payload which defines the maximum number of quadlets that may be transmitted in a single isochronous packet and which corresponds to the data rate. This data is used by thepacketizer 13 to properly set-up an isochronous channel according to theMPEG 2 standard on thecoaxial cable 3. Furtheron, thepacketizer 13 is connected to a third register, namely a BANDWIDTH_AVAILABLE register which provides the available bandwidth on thecoaxial cable 3 so that thepacketizer 13 can check whether there is enoughbandwidth in case a new isochronous channel should be set-up or an asynchronous packet should be transmitted. - A further element of the uplink section is a
fourth register 17, namely an INTERFACE_CONTROL register which includes the node identifier of the interface link layer device connected to the other side of the distributed network, i.e. the other side of thecoaxial cable 3, and an Enable Bit to allow the direct routing of asynchronous packets through thecoaxial cable 3. - The data packets to be output on the downlink channel(s) of the IEEE1394
serial bus 2 through the interfacelink layer device 1 are received through the connectedtransmission channel 3 from another interfacelink layer device 4 by the downlink section of the interfacelink layer device 1. Within said downlink section said data packets get repacked by apacket separator 20 into the IEEE1394 format which has a reverse operation in comparison with thepacketizer 13 of the uplink section. - As it is shown in
FIG. 4 for the case that an IEEE1394 serial bus packet with less than 188 bytes gets separated from anincoming MPEG 2 frame which has 204 bytes thepacket separator 20 takes the header, the payload and the cyclic redundancy code which belong to the IEEE1394 serial bus packet from the data block of theMPEG 2 frame and discards the stuff bytes which have been added by thepacketizer 13 of the other interfacelink layer device 4. The case that the IEEE1394 serial bus packet has a length of more than 188 bytes and needs a defragmentation after transmitting over the coaxial cable is shown inFIG. 5 . In the shown case the IEEE1394 serial bus packet has a total length of 752 bytes and is therefore transmitted in the data blocks of 4MPEG 2 frames. - The data blocks of these 4 frames carry the header the payload and the cyclic redundancy code of the IEEE1394 serial bus packet which gets assembled in the
packet separator 20 and distributed via the downlink channel(s) of the IEEE1394serial bus 2. - Since the
packetizer 13 adds stuff bytes to fill each data block of the 204byte MPEG 2 frame and in case that there are no IEEE1394 packets to transmit via the coaxial cable a data block of the 204 byte MPEG frame consists only of stuff bytes thepacket separator 20 receives a constant data stream from which the IEEE1394 packets get separated. As described above, divided IEEE1394 packets will be put together again and then, if not addressed to the outbound portal, i. e. the interfacelink layer device 1 itself, will be transmitted by the downlink section within the interfacelink layer device 1 to the connected IEEE1394serial bus 2 to the destination node. - If a predetermined bit in the header of a frame indicates a transport error the interface link layer device discards the complete packet. Also, if an error occurs during transmission via the coaxial cable the packet will be discarded. In these cases a device which waits for said packet, since it has requested a certain transaction, generates a split timeout error which is an indicator that the certain transaction should be requested again. The minimum timeout value for a split timeout is 100 ms.
- As described above, in case of asynchronous packets the header is necessary to identify the source, the destination and the transaction type of the packet. For isochronous packets, on the other hand, there is no guarantee to be transmitted within the same channel number from the outbound portal. Therefore, the downlink section comprises a channel
number assignment unit 21 that assigns a new channel number to isochronous packets which origin in a channel of the data bus that hosts the originator of said packets which channel number is already occupied for another data stream within the IEEE1394serial bus 2 that is connected to the interfacelink layer device 1 and serves the receiver of said packets. - As described hereinafter in connection with FIGS. 6 to 9 the interface link layer device according to the present invention does not just forward incoming acknowledge packets to their destination, but sets up an own acknowledgement and response strategy. Therefore, acknowledge packets that are received via the IEEE1394
serial bus 2 are not just forwarded through thecoaxial cable 3 to the interface link layer device connected to the network bus to which the destination device is connected, but the incoming acknowledge packet gets analysed by said interface link layer device which then decides which kind of action, i. e. acknowledgement and/or response is necessary to which device. - To properly set-up an acknowledge and response strategy the acknowledge/response section of the interface
link layer device 1 according to the present invention comprises an acknowledgecode generator 18 that serves the inbound behaviour and aresponse packet generator 19 that serves the outbound behaviour. - The acknowledge
code generator 18 receives all accepted data packets through the uplink channel(s) of the IEEE1394serial bus 2 and generates appropriate acknowledge codes to be output on the downlink channel(s) of the IEEE1394serial bus 2. Therefore, according to the present invention, an acknowledge code is not only generated when a packet which is to be transmitted to another part of the distributed network, i. e. another IEEE1394 serial bus, through thecoaxial cable 3 reaches its destination, but also when such a packet reaches the inbound portal, i. e. the inter-facelink layer device 1, of the transmission channel, i. e. thecoaxial cable 3. - The
response packet generator 19 that monitors the uplink and downlink channel(s) of the connected IEEE1394serial bus 2 generates an appropriate response packet to be output with an appropriate speed to a particular destination device via thecoaxial cable 3 in case a request was transmitted to the connected IEEE1394serial bus 2 and a corresponding acknowledge code is received from the connected IEEE1394serial bus 2. - As mentioned above, the acknowledge
code generator 18 sends an acknowledge to the originator of a packet received via the connected IEEE1394serial bus 2 for each accepted asynchronous packet that is either addressed to the node controller of the interfacelink layer device 1 or to a node on the other side of thecoaxial cable 3, e.g. a node connected to another IEEE1394serial bus 5 within the distributed network. The following table 1 gives an overview about the outbound behaviour of the interface link layer device concerning the acknowledge. A “-” sign within the table indicates that the respective content does not matter, but differs from 3F or 3FF. 3F and 3FF are hexadecimal values which are reserved within theIEEE 1394 standard for special purposes. The Enable Bit is located in theINTERFACE_CONTROL register 17, as stated above.Enable Destination Source Bit Bus ID PHY ID Bus ID Action — 3FF or — — Local packet. Acknowledge Node_IDS.bus_ID per IEEE1394-1995 standard. 0 Neither 3FF nor — — Routing disabled. Ignore Node_IDS.bus_ID packet, no Acknowledge. 1 — — 3FF Unable to route. Ignore packet, no acknowledge. 1 3FF 3F Not 3FF Global broadcast. Forward packet, no acknowledge. 1 Neither 3FF nor — Node_IDS.bus_ID Remote packet origination. Forward packet according to BUS_ENABLE, transmit ack_pending or ack_complete. Node_IDS.bus_ID Neither 3FF nor Remote packet in transit. Node_IDS.bus_ID Forward packet and transmit ack_pending or ack_complete. All other combinations Unable to route. Ignore packet, no acknowledge - It can be seen that the generated acknowledge code depends on the destination identifier, the transaction code and the cyclic redundancy code of an incoming packet. If a received packet is a request and to be routed through the interface, the acknowledge
code generator 18 always generates an acknowledge code that indicates a pending action, e. g. ack_pending, for the indicator of the request. In case of an error the acknowledgecode generator 18 generates a data error acknowledgement, e. g. ack_data_error, and an acknowledgement that indicates a completed action will be generate in case the received packet is a response packet without any errors, e. g. ack_complete. This behaviour of split transactions is necessary, since in most cases there would be no unified transaction possible over interfaces for time reasons, because the originator of a packet expects an acknowledge code for this packet within a certain time limit, e.g. 50 ms. - The outbound behaviour, on the other hand, is controlled by the
response packet generator 19. Every time an asynchronous packet, i.e. a request packet, was transmitted through the coaxial cable to a predetermined destination on the connected IEEE1394 serial bus the incoming corresponding acknowledge packet is received by theresponse packet generator 19 from the connected IEEE1394serial bus 2 and it is decided whether or not an appropriate response is output via thecoaxial cable 3 to the originator of a request that has triggered the acknowledge, as shown in the following table 2.Name (incoming acknowledgement) Action ack_complete Request: Transmit the appropriate response packet. Response: No action. ack_pending ack_busy_X The bridge abandons retry attempts: ack_busy_A Request: Transmit the appropriate response packet. ack_busy_B Response: No action. ack_data_error Request: Transmit the appropriate response packet. ack_type_error Response: No action. - Therefore, the
response packet generator 19 monitors all accepted acknowledge packets that are incoming via the connected IEEE1394serial bus 2 to provide an appropriate response packet as an asynchronous response packet for the originator of the request packet. Furtheron, theresponse packet generator 19 has to monitor all request packets output to the connected IEEE1394serial bus 2. To monitor all incoming and outgoing packets theresponse packet generator 19 stores different components of the asynchronous packet header, e.g. the source and destination of a packet, the source as new destination and the destination as new source. - It can be seen that the appropriate response packet will only be generated by the
response packet generator 19 if the asynchronous packet transmitted via thecoaxial cable 3 to a predetermined destination on the connected IEEE1394serial bus 2 was a write request and theresponse packet generator 19 received an acknowledge that indicates a completed action from the predetermined destination, i.e. the receiver of said request. For read requests and lock requests the receiver of the asynchronous packet has to create the appropriate response packet which will be forwarded by the other interfacelink layer device 4 through thecoaxial cable 3 to the interface link layer device that is connected to the IEEE1394 serial bus serving the originator of the corresponding request packet. - FIGS. 6 to 9 respectively show an example in which a
first IEEE1394 node 6 is connected via a first IEEE1394serial bus 2 to a first interface link layer device according to the present invention which is connected through acoaxial cable 3 to a second interfacelink layer device 4 according to the present invention that is connected to a second IEEE1394serial bus 5 which serves asecond IEEE1394 node 7. - In the first example shown in
FIG. 6 , thefirst node 6 distributes in a first step S61 a request to thesecond node 7 on the firstserial bus 2 it is connected to. Such a request is send as an asynchronous packet. In a second step S62 the first interfacelink layer device 1 receives that request and accepts it, since the identifier of thesecond node 7 is stored in itsfirst register 12, i. e. the BUS_ENABLE register. Additionally, the acknowledgecode generator 18 of the first interfacelink layer device 1 transmits an acknowledgement indicating a pending action, i.e. ack_pending, to thefirst node 6 and tranfers the request via thecoaxial cable 3 to the second interfacelink layer device 4 according to theMPEG 2 standard. In a third step S63 the second interfacelink layer device 4 receives the request, repacks it with itspacket separator 20 and transmits it via the connected secondserial bus 5 to thesecond node 7. Thesecond node 7 indicates in a fourth step S64 a completed action with an acknowledgement, i.e. ack_complete, directed to the requestingfirst node 6. This acknowledgement code is distributed on the secondserial bus 5 which is connected to thesecond node 7. In the next fifth step S65 the second interfacelink layer device 4 receives and accepts the acknowledge packet from thesecond node 7, since its destination identifier is stored in itsfirst register 12, i.e. its BUS_ENABLE register. Theresponse packet generator 19 of the second interfacelink layer device 4 generates an appropriate response packet and transmits it via thecoaxial cable 3 to the first interfacelink layer device 1 which distributes it after an appropriate repacking with itspacket separator 20 to thefirst node 6 via the firstserial bus 2 in a sixth step S66. Finally, in the seventh step S67, thefirst node 6 sends an completed action acknowledgement code to thesecond node 7 via the connected firstserial bus 2 which is received and accepted by the first interfacelink layer device 1 which accepts and discards it and therewith finalizes the action. - In the second example shown in
FIG. 7 , thefirst node 6 distributes in a first step S71 a request to thesecond node 7 on the firstserial bus 2 it is connected to as an asynchronous packet. In a second step S72 the first interfacelink layer device 1 receives that request and accepts it, since the identifier of thesecond node 7 is stored in itsfirst register 12, i. e. the BUS_ENABLE register. Additionally, the acknowledgecode generator 18 of the first interfacelink layer device 1 transmits an acknowledgement indicating a pending action, i.e. ack_pending, to thefirst node 6 and tranfers the request via thecoaxial cable 3 to the second interfacelink layer device 4 according to theMPEG 2 standard. In a third step S63 the second interfacelink layer device 4 receives the request, repacks it with itspacket separator 20 and transmits it via the connected secondserial bus 5 to thesecond node 7. Thesecond node 7 indicates in a fourth step S74 a pending action with an acknowledgement, i.e. ack_pending, directed to the requestingfirst node 6. This acknowledgement code is distributed on the secondserial bus 5 which is connected to thesecond node 7. Therafter, in a sixth step S76, thesecond node 7 generates a response to the request received in the third step S73 that is directed to the requestingfirst node 6. This response is distributed on the secondserial bus 5 which is connected to thesecond node 7 and received and accepted by the second interfacelink layer device 4, since its destination identifier is stored in itsfirst register 12, i.e. its BUS_ENABLE register. The acknowledgecode generator 18 of the second interfacelink layer device 4 transmits an acknowledge code indicating a completed action, i.e ack_complete, to the second node, since the second interface link layer device has received the response without any errors. Since the response, which indicates a completed action, is no acknowledge code the second interfacelink layer device 4 transmits said packet after repacking by itspacketizer 13 via thecoaxial cable 3 to the first interfacelink layer device 1 which distributes it after an appropriate repacking with itspacket separator 20 to thefirst node 6 via the firstserial bus 2 in a seventh step S77. Finally, in the eighth step S78, thefirst node 6 sends an completed action acknowledgement code to thesecond node 7 via the connected firstserial bus 2 which is received and accepted by the first interfacelink layer device 1 which accepts and discards it and therewith finalizes the action. - The timeout value of the
first node 6 to wait from the received ack_pending acknowledgement to the response should be set >100 ms. - In the third example shown in
FIG. 8 , thefirst node 6 distributes in a first step S81 a request to thesecond node 7 on the firstserial bus 2 it is connected to as an asynchronous packet. In a second step S82 the first interfacelink layer device 1 receives that request and accepts it, since the identifier of thesecond node 7 is stored in itsfirst register 12, i. e. the BUS_ENABLE register. Additionally, the acknowledgecode generator 18 of the first interfacelink layer device 1 transmits an acknowledgement indicating a pending action, i.e. ack_pending, to thefirst node 6 and tranfers the request via thecoaxial cable 3 to the second interfacelink layer device 4 according to theMPEG 2 standard. In a third step S83 the second interfacelink layer device 4 receives the request, repacks it with itspacket separator 20 and transmits it via the connected secondserial bus 5 to thesecond node 7. Thesecond node 7 indicates in a fourth step S84 that it is busy with an acknowledgement, i.e. ack_busy, directed to the requestingfirst node 6. This acknowledgement code is distributed on the secondserial bus 5 which is connected to thesecond node 7. In the next fifth step S85 the second interfacelink layer device 4 receives and accepts the acknowledge packet from thesecond node 7, since its destination identifier is stored in itsfirst register 12, i.e. its BUS_ENABLE register. Theresponse packet generator 19 of the second interfacelink layer device 4 generates an appropriate response packet and transmits it via thecoaxial cable 3 to the first interfacelink layer device 1 which distributes it after an appropriate repacking with itspacket separator 20 to thefirst node 6 via the firstserial bus 2 in a sixth step S86. Finally, in the seventh step S87, thefirst node 6 sends an completed action acknowledgement code to thesecond node 7 via the connected firstserial bus 2 which is received and accepted by the first interfacelink layer device 1 which accepts and discards it and therewith finalizes the action. - In the fourth example shown in
FIG. 9 , thefirst node 6 distributes in a first step S91 a request to thesecond node 7 on the firstserial bus 2 it is connected to as an asynchronous packet. In a second step S92 the first interfacelink layer device 1 receives that request and accepts it, since the identifier of thesecond node 7 is stored in itsfirst register 12, i. e. the BUS_ENABLE register. Additionally, the acknowledgecode generator 18 of the first interfacelink layer device 1 transmits an acknowledgement indicating a pending action, i.e. ack_pending, to thefirst node 6 and tranfers the request via thecoaxial cable 3 to the second interfacelink layer device 4 according to theMPEG 2 standard. In a third step S83 the second interfacelink layer device 4 receives the request repacks it with itspacket separator 20 and transmits it via the connected secondserial bus 5 to thesecond node 7. Thesecond node 7 indicates in a fourth step S84 a data error with an acknowledge code, i.e. ack_data_error, directed to the requestingfirst node 6. This acknowledgement code is distributed on the secondserial bus 5 which is connected to the second node. In the next fifth step S85 the second interfacelink layer device 4 receives and accepts the acknowledge packet from thesecond node 7, since its destination identifier is stored in itsfirst register 12, i.e. its BUS_ENABLE register. Theresponse packet generator 19 of the second interfacelink layer device 4 generates an appropriate response packet and transmits it via thecoaxial cable 3 to the first interfacelink layer device 1 which distributes it after an appropriate repacking with itspacket separator 20 to thefirst node 6 via the firstserial bus 2 in a sixth step S86. Finally, in the seventh step S87, thefirst node 6 sends an completed action acknowledgement code to thesecond node 7 via the connected firstserial bus 2 which is received and accepted by the first interfacelink layer device 1 which accepts and discards it and therewith finalizes the action. - It can be seen that according to the present invention the interface link layer device which is connected to a respective IEEE1394 serial bus and a respective coaxial cable through respective physical layer devices provides accepted packets that should be transmitted via the interface as complete packets to the coaxial cable. Such a complete packet consists of the header, the data block and the cyclic redundancy codes. The transmission of the complete packet through the
coaxial cable 3 is necessary, because the corresponding interface link layer device connected to another network bus of the distributed network needs the information of the packets for the transmission on said other serial bus. Furtheron, the interface link layer device according to the present invention introduced the concept that not all packets have to be transmitted via the interface, since an appropriate acknowledge code and response code generation of the interface link layer device itself is introduced. - Since according to the present invention not all, but only selected data packets are distributed via the coaxial interface it is in a special arrangement possible to “hide” the coaxial interface to the IEEE1394 bus to which it is connected. An example for such an arrangement is shown in
FIG. 10 . - Generally, such arrangements comprise one first IEEE1394
serial bus 2 which can have any number ofcontroller nodes 6 connected. This is called the multidevice side. In the example shown inFIG. 10 there are two IEEE1394serial bus nodes 6 and one interface link layer device 1 (which is also a node within the IEEE1394 system) connected to the first IEEE1394serial bus 2. - Via a
coaxial cable 3 and a second interfacelink layer device 4 there is connected a second IEEE1394serial bus 5. According to this embodiment of the invention to “hide” thecoaxial interface 3 to thefirst IEEE1394 bus 2 this second IEEE1394serial bus 5 is allowed to have only one single IEEE1394serial bus node 7 connected. This is called the single-device side. - To “hide” the
coaxial interface 3 it is neccessary that acontroller node 6 on the mulit-device side is not aware of the interface. This can be achieved since the interfacelink layer device 1 looks like the single IEEE1394serial bus node 7 connected to the first interfacelink layer device 1 via thecoaxial interface 3, the second interfacelink layer device 5 and the second IEEE1394serial bus 5. -
FIG. 10 shows also the node identifiers of all serial bus nodes connected to both IEEE1394serial busses controller nodes 6, one has anode ID 0 and the other has anode ID 2. The first interfacelink layer device 1 connected to the first IEEE1394serial bus 2 has anode ID 1. The single-device side is build by acontroller node 7 having anode ID 0 and the second interfacelink layer device 4 having anode ID 1. - In order to make the communication work the destination node ID within asynchronous packets of a
controller node 6 connected to the first IEEE1394serial bus 2 to the single-device side has to be changed from the node ID of the first interfacelink layer device 1 on the multi-device side, 1 inFIG. 10 , to the node ID of thesingle controller node 7 on the single device side, 0 inFIG. 10 . The source node ID remains unchanged for this communication direction. - Further, in asynchronous packets from the single-device side to the multi-device side the source node ID has to be changed from the node ID of the
single controller node FIG. 10 , to the node ID of the interfacelink layer device 1 on the multi-device side, 1 inFIG. 10 . The destination ID remains unchanged for this communication direction. - A possible implementation can be realized by providing two additional registers within the second interface
link layer device 4 of the single-device side. The first additional register stores the node ID of the first interfacelink layer device 1 on the multi-device side and the second additional register stores the node ID of thesingle controller node 7 on the single-device side. The second interfacelink layer device 4 has then to replace the destination node identifier before sending a packet to the second IEEE1394serial bus 5 using the value of the second additional register and to replace the source node identifier using the value of the first register before sending a packet to thecoaxial cable 3. In this implementation the first interfacelink layer device 1 connected to the multi-device side requires only the modification to forward packets directed to itself through the coaxial cable to the second interface link layer device, i.e. to forward packets with destination node identifiers that are identical to its own node identifier. Furthermore, the second interfacelink layer device 4 on the single-device side has to operate in a special mode, because it has to accept and forward packets with destination node identifiers that are not identical to its own node identifier. - Of course, this embodiment to “hide” the coaxial interface is not limited to a distributed network with only one pair of coaxial interfaces.
FIG. 11 shows an example where two separate single remote nodes 7A, 7B are connected to acoaxial cable network 3. To achieve such a “hiding” of two separate single remote nodes two first interface link layer devices 1A, 1B are required on the multidevice side, i. e. connected to the first IEEE1394serial bus 2, which respectively communicate with a corresponding second interface link layer device 4A, 4B through thecoaxial cable 3 which is in turn connected to a respective single remote node 7A, 7B through a respectivesecond IEEE 1394serial bus 5A, 5B. - As described in
EP 0 848 568 A1 there are different solutions for the transmission of digital data via the coaxial cable, e. g. as a QPSK or a QAM-signal, of course, all these and other methods can be applied to an interface link layer device according to the present invention. - FIGS. 13 to 15 show that more than two interface link layer devices can be connected to the
coaxial cable 3 similar to the distributed prior art network shown inFIG. 17 . It is shown that three interface link layer devices are connected to onecoaxial cable 3, namely a first interfacelink layer device 1, a second interfacelink layer device 4 and a third interfacelink layer device 8. Every interface link layer device is also connected to a respective IEEE1394 serial bus and each of these IEEE1394 serial busses has been assigned a different bus identifier. - According to the present invention a bi-directional communication between all busses is enabled and data that is not needed on a certain IEEE1394 serial bus will not be seen there. As stated above within the coaxial cable or a coaxial network consisting of several coaxial cables channels are assigned in frequency division multiplex with every channel occupying a certain bandwidth so that a large number of channels is simultaneously available.
- In order to achieve availability of the data packets within the
coaxial cable 3 to all interface link layer devices while not setting-up two channels between every possible pair of interface link layer devices, i. e. while not setting-up a full-hyper-cube channel assignment as shown and described in connection withFIG. 15 , but setting-up e. g. a ring channel assignment, while not generating superfluous bus traffic on the attached IEEE1394 serial busses, an additional function unit as shown inFIG. 12 and described in the following can be implemented inside an interface link layer device according to the present invention. - The downstream path from the
coaxial cable 3 to the interface link layer device and the upstream path from the interface link layer device to thecoaxial cable 3 can be connected if necessary by a firstadditional switch 16 a which is controlled by thecontroller 11 which is additionally connected to the downstream path. Asynchronous IEEE1394 packets taking this route will not be seen on the IEEE1394 serial bus this interface link layer device is connected to, since a secondadditional switch 16 b which is also controlled by thecontroller 11 and which connects the downstream path with thepacket separator 20 is open in this case. - The
controller 11 monitors the incoming downstream packets to control the first and secondadditional switches FIG. 12 in which the firstadditional switch 16 a is open and the secondadditional switch 16 b is closed indicates the case when a packet is destined to the IEEE1394 serial bus this interface link layer device is a member of. As described above, the firstadditional switch 16 a will close and the secondadditional switch 16 b will open for packets destined to other bus numbers. - In case of isochronous packets, it is possible to send these both to the IEEE1394 serial bus the interface link layer device is connected to and through the upstream path to the next or other interface link layer devices on the
coaxial cable 3. In this case bothadditional switches - Of course, such a functionality can alternatively also be included in the
packet separator 20 which needs then a connection to the upstream path, e.g. directly or via thepacketizer 13, and in order to know how to distribute the received packets also to thecontroller 11. -
FIG. 13 shows a ring channel assignment for the distributed IEEE1394 serial bus network according to which the data links between all the interface link layer devices connected to thecoaxial cable 3 are arranged in a ring. For the ring channel assignment every interface requires one transmission and one reception channel. InFIG. 13 the first interfacelink layer device 1 transmits onchannel 1 and receives onchannel 3, the second interfacelink layer device 4 transmits onchannel 2 and receives onchannel 1 and the third interfacelink layer device 8 transmits onchannel 3 and receives onchannel 2. For n interfaces n channel on the coaxial cable are required. With this channel assignment there is no need to re-configure the data links on thecoaxial cable 3 on the fly. -
FIG. 14 shows a semi-hyper-cube channel assignment for the distributed IEEE1394 serial bus network which assures a data link from every interface link layer device to every other interface link layer device. To save channels every interface link layer device transmits on just one channel via thecoaxial cable 3 and reception is done on all the other channels used for transmission by the other interface link layer devices. InFIG. 14 the first interfacelink layer device 1 transmits onchannel 1 and receives onchannels link layer device 4 transmits onchannel 2 and receives onchannels link layer device 8 transmits onchannel 3 and receives onchannels - For such a semi-hyper-cube channel assignment every interface link layer device requires one transmission and (n−1) reception channels in case of n interface link layer devices. Therefore, n channels on the coaxial network are required. If said data links are desired, one interface link layer device must have (n−1) front end modules. Therefore, it is desirable to have a dynamic channel assignment scheme.
-
FIG. 15 shows the full-hyper-cube channel assignment for the distributed IEEE1394 serial bus network which assures a data link from every interface link layer device to every other interface link layer device. In the full-hypercube channel assignment one transmission and one reception channel are set up inbetween each two interface link layer devices. Therefore, the additional functionality of the interfacelink layer device 1 as shown inFIG. 12 and described in connection therewith is not necessary. InFIG. 15 the first interfacelink layer device 1 transmits onchannel 1 to the second interfacelink layer device 4 and onchannel 2 to the third interfacelink layer device 8, and receives onchannel 3 from the second interfacelink layer device 4 and onchannel 5 from the third interfacelink layer device 8. The second interfacelink layer device 4 transmits onchannel 3 to the first interfacelink layer device 1 and onchannel 4 to the third interfacelink layer device 8, and receives onchannel 1 from the first interfacelink layer device 1 and onchannel 6 from the third interfacelink layer device 8. The third interfacelink layer device 8 transmits onchannel 5 to the first interfacelink layer device 1 and onchannel 6 to the second interfacelink layer device 4, and receives onchannel 2 from the first interface link layer device and onchannel 4 from the second interfacelink layer device 4. - In a distributed network with n interface link layer devices every interface link layer device requires (n−1) transmission and (n−1) reception channels. Therefore, for n interface link layer devices n·(n−1) channels on the
coaxial cable 3 are required.
Claims (24)
1. A portal for communicating data in-between a source node and a destination node, the portal being connected to the source node via a first serial data bus and connected to a second portal through a transmission path, the second portal being connected to the destination node via a second serial data bus, the portal comprising;
means for receiving asynchronous packets corresponding to a request action from said first node and for monitoring all of said received asynchronous packets;
means for deciding whether a destination ID assigned to said received asynchronous packet corresponds to a destination ID identifying said destination node or said second serial data bus;
means for forwarding or discarding said asynchronous packets and for transmitting acknowledgements so that if said destination ID of the received asynchronous packet corresponds to said destination ID identifying said destination node or said second serial data bus, the received asynchronous packet is forwarded to said second portal and a pending acknowledgement indicating a pending action is transmitted to said source node, and else if said destination ID of the received asynchronous packet is different from said destination ID identifying said destination node or said second serial data bus, the received asynchronous packet is discarded.
2. Portal according to claim 1 , wherein said means for receiving asynchronous packets is further adapted for receiving asynchronous packets corresponding to a response action, and
said means for forwarding or discarding said asynchronous packets and for transmitting said acknowledgements transmits a completed acknowledgement for indicating a completed action, If a packet corresponding to said response action is received by as-id means for receiving asynchronous packets.
3. A portal for communicating data In-between a source node and a destination node, the portal being connected to a second portal through a transmission path, said second portal being connected to said source node via a first serial data bus and said portal being connected to said destination node via a second serial data bus, the portal comprising:
means for receiving asynchronous packets corresponding to a response action from said destination node and for monitoring all of said received asynchronous packets;
mean for deciding whether a destination ID assigned to said received asynchronous packet corresponds to a destination ID identifying said source node or said destination first serial data bus;
means for forwarding or discarding said asynchronous packets and for transmitting acknowledgements so that if said destination ID of the received asynchronous packet corresponds to said destination ID identifying said source node or said destination first serial data bus, the received asynchronous packet is forwarded to said second portal and for transmitting a completed acknowledgement indicating a completed action is transmitted to said destination node, and else if said destination ID of the received asynchronous packet is different from said destination ID identifying said source node or said source bus, the received asynchronous packets is discarded.
4. Portal according to claim 3 , wherein said means for receiving asynchronous packets is further adapted for receiving asynchronous packets corresponding to a request action, and
said means for forwarding or discarding said asynchronous packets and for transmitting acknowledgements transmits a pending acknowledgement for indicating a pending action, if a packet corresponding to a request action is received by said means for receiving asynchronous packets.
5. A transaction device for routing asynchronous packets in-between two nodes which are provided in two serial data bus networks, the transaction device comprising:
means for receiving asynchronous packets corresponding to a request or response action from one of said nodes via a serial data bus;
means for routing the received asynchronous packets from one to the other serial data bus network through a transmission path;
wherein said routing means, when said routing means receives said request action, transmits a pending acknowledgement for indicating a pending action to the one node via said serial data bus and forwards said request action to the other node through said transmission path, and when said routing means receives said response action, said routing means transmits a completed acknowledgement for indicating a completed action to the one node via said serial data bus and forwards said response action to the other node through said transmission path.
6. A portal for routing asynchronous packets in-between two IEEE1394 serial bus networks, the portal comprising:
means for monitoring all incoming asynchronous packets and for filtering asynchronous packets to be forwarded to the other IEEE1394 serial bus network from said all incoming asynchronous packets;
means for forwarding the filtered asynchronous packets to said other IEEE1394 serial bus network1 and for transmitting an acknowledgement when said asynchronous packets are forwarded to said other IEEE1394 serial bus network and for discarding the unfiltered asynchronous packets.
7. A portal for routing asynchronous packets in-between at least two IEEE1394 serial bus networks, the portal comprising:
means for monitoring all incoming asynchronous packets of one of said IEEE 1394 serial bus networks;
means for forwarding asynchronous packets to the other IEEE1394 serial bus network if said asynchronous packets to be forwarded have a destination m Identifying the other IEEE 1394 serial bus network or a node provided in said other IEEE1394 serial bus network; and
means for selectively transmitting an acknowledgement indicating a pending action or a completed action to a node of said one IEEE1394 aerial bus network in response to a request action and response action, respectively, originating from said node.
8. A portal connected to a first data bus and via a transmission path to at least one other portal that is connected to a respective second data bus of a plurality of second data buses, comprising:
an uplink section adapted to accept a data packet from the first data bus that has a predetermined destination or that has a channel number of a data channel that leads from the first data bus to one of said respective second data busses and to transmit said data packet via said transmission path to said other portal serving said predetermined destination;
a downlink section adapted to output data packets received via said transmission path from one of said at least one other portal to a predetermined destination on the first data bus; and
an acknowledge code generator adapted to generate and send an acknowledgement to an originator of a data packet accepted from the data bus the portal is connected to.
9. A portal connected to a first data bus and via a transmission path to a coportal that is connected to a respective second data bus of a plurality of second data buses, comprising
a register adapted to store at least one destination ID of at least one predetermined destination:
a controller adapted to accept a data packet from the first data bus that has a predetermined destination ID stored in said register and to transmit it via said transmission path to said co-portal serving said predetermined destination;
a downlink section adapted to output data packets received via said transmission path from said co-portal to a predetermined destination on the first data bus; and
an acknowledge code generator adapted to generate and send an acknowledgement to an originator of a data packet accepted from the data bus the portal is connected to.
10. A portal connected to a first data bus and via a transmission path to a coportal that is connected to a respective second data bus of a plurality of second data buses, comprising:
a register adapted to store at least one channel number of a data channel that leads from the first data bus to one of said respective second data busses;
a controller adapted to accept a data packet from the first data bus that has a channel number of a data channel stored in said register and to transmit it via said transmission path to said co-portal serving said predetermined destination;
a downlink section adapted to output data packets received via said transmission path from said co-portal to a predetermined destination on the first data bus; and
an acknowledge code generator adapted to generate and send an acknowledgement to an originator of a data packet accepted from the data bus the portal is connected to.
11. A portal connected to a first data bus and via a transmission path to a co portal that is connected to a respective second data bus of a plurality of second data buses, comprising:
a first register adapted to store at least one destination ID of at least one destination;
a second register adapted to store at least one channel number of a data channel that leads from the first data bus to one of said respective second data busse;
a controller adapted to accept a data packet from the first data bus that has a predetermined destination stored in said first register or that has a channel number of a data channel stored in said second register and to transmit it via said transmission path to said co-portal serving said predetermined destination;
a downlink section adapted to output data packets received via said transmission path from said co-portal to a predetermined destination on the first data bus; and
an acknowledge code generator adapted to generate and send an acknowledgement to an originator of a data packet accepted from the data bus the portal is connected to.
12. A portal connected to a first data bus and via a transmission path to at inst one other portal that is connected to a respective second data bus of a plurality of second data buses, comprising:
an uplink section adapted to accept a data packet from the first data bus that has a predetermined destination or that has a channel number of a data channel that leads from the first data bus to one of said respective second data busses and to transmit it via said transmission path to said other portal serving said predetermined destination, wherein said data packet corresponds to a request;
a downlink section adapted to output data packets received via said transmission path from one of said at least one other portal to a predetermined destination on the first data bus; and
an acknowledge code generator adapted to generate an acknowledgement of ack_pending to be sent to the originator of a data packet accepted from the data bus the portal is connected to.
13. A portal connected to a first data bus and via a transmission path to at least one other portal that is connected to a respective second data bus of a plurality of second data buses, comprising:
an uplink section adapted to accept a data packet from the first data bus that has a predetermined destination or that has a channel number of a data channel that leads from the first data bus to one of said, respective second data bus and to transmit it via said transmission path to said other portal serving said predetermined destination, wherein said data packet corresponds to a response;
a downlink section adapted to output data packets received via said transmission path from one of said at least one other portal to a predetermined destination on the first data bus; and
an acknowledge code generator adapted to generate an acknowledgement of ack_complete to be sent to the originator of a data packet accepted from the data bus the portal is connected to.
14. A portal connected to a first data bus and via a transmission path to at least one other portal that is connected to a respective second data bus of a p1w-aRty of second data buses, comprising:
an uplink section adapted to accept a data packet from the first data bus that has a predetermined destination or that has a channel number of a data channel that leads from the first data bus to one of said respective second data busses and to transmit it via said transmission path to said other portal serving said predetermined destination, wherein said data packet corresponds to a request or to a response;
a downlink section adapted to output data packets received via said transmission path from one of said at least one other portal to a predetermined destination on the first data bus; and
an acknowledge code generator adapted to generate an acknowledgement to be sent to the originator of a data packet accepted from the data bus the portal is connected to, wherein, if said data packet corresponds to a request, said acknowledgment is equal to ack_pending, and if said data packet corresponds to a response, said acknowledgement is equal to ack_complete.
15. A portal connected to a first IZKE13O4 serial bus network and via a transmission path to a co-portal that is connected to a respective IEEE1SQ4 serial bus network, comprising:
an uplink section adapted to accept a data packet from the first IEEEZS94 serial bus network that has a predetermined destination or that has a channel number of a data channel that leads from the first IEEE1394 serial bus network to one of said respective second IEEE1394 serial bus network and to transmit it via said transmission path to said co-portal serving said predetermined destination, wherein said data packet corresponds to a request or to a response;
a downlink section adapted to output data packets received via said transmission path from said co-portal to a predetermined destination on the first IEEE1394 serial bus network; and
an acknowledge code generator adapted to generate an acknowledgement to be sent to the originator of a data packet accepted from the serial bus network the portal is connected to, wherein, if said data packet corresponds to a request, said acknowledgement is equal to ack_pending, and if said data packet corresponds to a response, said acknowledgement is equal to ack_complete.
16. A portal connected to a first data bus and via a transmission path to at least one other portal that is connected to a respective data bus of a plurality of second data busses, comprising;
uplink means to accept a data packet from the first data bus that has a predetermined destination or that has a channel number of a data channel that leads from the first data bus to one of the respective second data bus and to transmit it via said transmission path to said other portal serving said predetermined destination; and
downlink means to output data packets received via said transmission path from one of said at least one other portal to a predetermined destination on the first data bus,
wherein said uplink means comprise a first register that reflects destination identifiers which will be accepted, and
wherein said destination identifier is a bus identifier of said respective second data bus and said first register comprises a bus enable register identifying said respective second data bus that is serving said predetermined destinations.
wherein said uplink means comprises a packetizer that is able to repack data packets received from the first data bus into a format of the transmission path that is different to the format of the first data bus.
17. A portal connected to a first data bus and via a transmission path to at least one other portal that is connected to a respective data bus of a plurality of second data busses, comprising:
uplink means to accept a data packet from the first data bus that has a predetermined destination or that has a channel number of a data channel that leads from the first data bus to one of the respective second data bus and to transmit it via said transmission path to said other portal serving said predetermined destination; and
downlink means to output data packets received via said transmission path from one of said at least one other portal to a predetermined destination on the first data bus,
wherein said uplink means comprise a first register that reflects destination identifiers which will be accepted, and
wherein said destination identifier is a bus identifier of said respective second data bus and said first register comprises a bus enable register identifying said respective second data bus that is serving said predetermined destinations,
wherein said downlink means comprises a packet separator that is able to repack data packets received from the transmission path into a format of the first data bus that is different to the format of the transmission path.
18. A portal adapted to communicate data in-between a source node and a destination node, the portal being connected to the source node via a first serial data bus and connected to a second portal through a transmission path, the second portal being connected to the destination node via a second serial data bus, the portal comprising:
an uplink section adapted to receive asynchronous packets corresponding to a request action from said first node and to monitor all of said received asynchronous packets; and
a controller adapted to decide whether a destination ID assigned to said received asynchronous packet corresponds to a destination ID identifying said destination node or said second serial data bus, and further adapted to forward or discard said asynchronous packets; and
an acknowledge code generator adapted to transmit acknowledgements so that if said destination ID of the received asynchronous packet corresponds to said destination ID identifying said destination node or said second serial data bus, the received asynchronous packet is forwarded to said second portal and a pending acknowledgement indicating a pending action is transmitted to said source node, and else if said destination II) of the received asynchronous packet is different from said destination ID identifying said destination node or said second serial data bus, the received asynchronous packet is discarded.
19. Portal according to claim 18 , wherein said uplink section is further adapted to receive asynchronous packets corresponding to a response action, and
said acknowledge code generator transmits a completed acknowledgement for indicating a completed action, if a packet corresponding to said response action is received by said uplink section.
20. A portal adapted to communicate data in-between a source node and a destination node, the portal being connected to a second portal through a transmission path, said second portal being connected to said source node via a first serial data
bus and said portal being connected to said destination node via a second serial data bus, the portal comprising:
an uplink section adapted to receive asynchronous packets corresponding to a response action from said destination node and to monitor all of said received asynchronous packets;
a controller adapted to decide whether a destination ID assigned to said received asynchronous packet corresponds to a destination ID identifying said source node or said destination first serial data bus; and further adapted to forward or discard said asynchronous packets; and
an acknowledge code generator adapted to transmit acknowledgements so that if said destination ID of the received asynchronous packet corresponds to said destination ID identifying said source node or said destination first serial data bus, the received asynchronous packet is forwarded to said second portal and for transmitting a completed acknowledgement indicating a completed action is transmitted to said destination node, and else if said destination ID of the received asynchronous packet is different from said destination ID Identifying said source node or said source bus, the received asynchronous packets is discarded.
21. Portal according to claim 20 , wherein said uplink section is further adapted to receive asynchronous packets corresponding to a request action, and
said acknowledge code generator transmits a pending acknowledgement for indicating a pending action, if a packet corresponding to a request action is received by said uplink section.
22. A transaction device adapted to route asynchronous packets in-between two nodes which are provided in two serial data bus networks, the transaction device comprising:
an uplink section adapted to receive asynchronous packets corresponding to a request or response action from one of said nodes via a serial data bus;
a controller adapted to route the received asynchronous packets from one to the other serial data bus network through a transmission path, wherein said controller, when said controller receives said request action, transmits a pending acknowledgement for Indicating a pending action to the one node via said serial data bus and forwards said request action to the other node through said transmission path, and when said controller receives said response action, said controller transmits a completed acknowledgement for indicating a completed action to the one node via said serial data bus and forwards said response action to the other node through said transmission path.
23. A portal adapted to route asynchronous packets In-between two IEEE 1594 serial bus networks, the portal comprising:
a controller adapted to monitor all incoming asynchronous packets and to filter asynchronous packets to be forwarded to the other IEEE1394 serial bus network from said all incoming asynchronous packets:
a downlink section adapted to forward the filtered asynchronous packets to said other IEEE1394 serial bus network, and to transmit an acknowledgement when said asynchronous packets are forwarded to said other IEEE1394 serial bus network, and further adapted to discard the unfiltered asynchronous packets.
24. A portal adapted to route asynchronous packets in-between at least two IEEE1394 serial bus networks, the portal comprising:
a controller adapted to monitor all incoming asynchronous packets of one of said IEEE 1394 serial bus networks;
a downlink section adapted to forward asynchronous packets to the other IEEE1394 serial bus network if said asynchronous packets to be forwarded have a destination ID identifying the other IEEE 1394 serial bus network or a node provided in said other IEEE 1394 serial bus network; and
an acknowledge code generator adapted to selectively transmit an acknowledgement indicating a pending action or a completed action to a node of said one IEEE 1394 serial bus network in response to a request action and response action, respectively, originating from said node.
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US11/674,468 US20070127470A1 (en) | 1999-12-30 | 2007-02-13 | Interface link layer device to build a distributed network |
Applications Claiming Priority (4)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
EP99126221A EP1113626B1 (en) | 1999-12-30 | 1999-12-30 | Interface link layer device to build a distributed network |
EP99126221.3 | 1999-12-30 | ||
US09/751,882 US7180904B2 (en) | 1999-12-30 | 2000-12-29 | Interface link layer device to build a distributed network |
US11/674,468 US20070127470A1 (en) | 1999-12-30 | 2007-02-13 | Interface link layer device to build a distributed network |
Related Parent Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US09/751,882 Continuation US7180904B2 (en) | 1999-12-30 | 2000-12-29 | Interface link layer device to build a distributed network |
Publications (1)
Publication Number | Publication Date |
---|---|
US20070127470A1 true US20070127470A1 (en) | 2007-06-07 |
Family
ID=8239777
Family Applications (3)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US09/751,882 Expired - Fee Related US7180904B2 (en) | 1999-12-30 | 2000-12-29 | Interface link layer device to build a distributed network |
US11/674,468 Abandoned US20070127470A1 (en) | 1999-12-30 | 2007-02-13 | Interface link layer device to build a distributed network |
US11/675,769 Abandoned US20070133404A1 (en) | 1999-12-30 | 2007-02-16 | Interface link layer device to build a distributed network |
Family Applications Before (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US09/751,882 Expired - Fee Related US7180904B2 (en) | 1999-12-30 | 2000-12-29 | Interface link layer device to build a distributed network |
Family Applications After (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US11/675,769 Abandoned US20070133404A1 (en) | 1999-12-30 | 2007-02-16 | Interface link layer device to build a distributed network |
Country Status (4)
Country | Link |
---|---|
US (3) | US7180904B2 (en) |
EP (1) | EP1113626B1 (en) |
JP (1) | JP2001223733A (en) |
DE (1) | DE69940781D1 (en) |
Cited By (10)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US10039113B2 (en) | 2016-03-28 | 2018-07-31 | Bank Of America Corporation | Intelligent resource procurement system based on physical proximity to related resources |
US10038607B2 (en) * | 2016-06-17 | 2018-07-31 | Bank Of America Corporation | System for aggregated machine-initiated resource distribution |
US10063438B2 (en) | 2016-03-28 | 2018-08-28 | Bank Of America Corporation | Security implementation for resource distribution |
US10080132B2 (en) | 2016-03-28 | 2018-09-18 | Bank Of America Corporation | System for adaptation of multiple digital signatures in a distributed network |
US10103936B2 (en) | 2016-06-21 | 2018-10-16 | Bank Of America Corporation | Computerized resource reallocation system for transferring resource blocks based on custodian event |
US10127400B2 (en) * | 2016-09-26 | 2018-11-13 | Bank Of America Corporation | Control device for aggregation and distribution of machine-initiated resource distribution |
US10135817B2 (en) | 2016-03-28 | 2018-11-20 | Bank Of America Corporation | Enhancing authentication and source of proof through a dynamically updatable biometrics database |
US10334462B2 (en) | 2016-06-23 | 2019-06-25 | Bank Of America Corporation | Predictive analytics for resource development based on information communicated from inter-related communication devices |
US10439913B2 (en) | 2016-07-01 | 2019-10-08 | Bank Of America Corporation | Dynamic replacement and upgrade of existing resources based on resource utilization |
US10796253B2 (en) | 2016-06-17 | 2020-10-06 | Bank Of America Corporation | System for resource use allocation and distribution |
Families Citing this family (20)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
EP1133108A1 (en) * | 2000-03-07 | 2001-09-12 | Sony International (Europe) GmbH | Interface link layer device for long delay connections |
EP1199840A1 (en) * | 2000-10-19 | 2002-04-24 | THOMSON multimedia | Method for connecting an IEEE1394 remote device to a cluster of IEEE1394 devices through a wireless link |
EP1393571A1 (en) * | 2001-04-20 | 2004-03-03 | General Instrument Corporation | Ip data encapsulation and insertion using a broadband transport multiplexer |
EP1263172A3 (en) * | 2001-05-29 | 2002-12-18 | Thomson Licensing S.A. | Method for managing resources of a link in a communication network |
EP1307005A1 (en) | 2001-10-25 | 2003-05-02 | Sony International (Europe) GmbH | Programmable interface link layer device |
US7171506B2 (en) | 2003-11-17 | 2007-01-30 | Sony Corporation | Plural interfaces in home network with first component having a first host bus width and second component having second bus width |
IL159838A0 (en) | 2004-01-13 | 2004-06-20 | Yehuda Binder | Information device |
DE102004062034A1 (en) * | 2004-12-23 | 2006-07-13 | Robert Bosch Gmbh | Repeater node for a network |
US7797607B2 (en) * | 2005-12-27 | 2010-09-14 | Lg Electronics, Inc. | DTV transmitter and method of coding main and enhanced data in DTV transmitter |
US7380044B1 (en) * | 2006-04-17 | 2008-05-27 | Francesco Liburdi | IEEE 1394 to coaxial cable adapter |
US8451860B2 (en) * | 2007-02-08 | 2013-05-28 | The Boeing Company | Low-weight hybrid deterministic highspeed data bus |
EP2210372B1 (en) | 2007-10-04 | 2011-04-13 | U-MAN Universal Media Access Networks GmbH | Digital multimedia network with hierarchical parameter control protocol |
US8161188B2 (en) * | 2008-05-04 | 2012-04-17 | Check Point Software Technologies, Ltd | Devices and methods for providing network access control utilizing traffic-regulation hardware |
US7957400B2 (en) * | 2009-03-26 | 2011-06-07 | Terascale Supercomputing Inc. | Hierarchical network topology |
US20100250784A1 (en) * | 2009-03-26 | 2010-09-30 | Terascale Supercomputing Inc. | Addressing Scheme and Message Routing for a Networked Device |
JP5411612B2 (en) * | 2009-07-29 | 2014-02-12 | アルパイン株式会社 | Communication device |
US20120173851A1 (en) * | 2010-12-30 | 2012-07-05 | International Business Machines Corporation | Mechanism for maintaining dynamic register-level memory-mode flags in a virtual machine system |
JP5900198B2 (en) * | 2012-07-06 | 2016-04-06 | 株式会社オートネットワーク技術研究所 | COMMUNICATION SYSTEM, RELAY DEVICE, AND COMMUNICATION DEVICE |
US9389765B2 (en) * | 2013-03-12 | 2016-07-12 | Google Inc. | Generating an image stream |
US9712442B2 (en) * | 2013-09-24 | 2017-07-18 | Broadcom Corporation | Efficient memory bandwidth utilization in a network device |
Citations (25)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US584771A (en) * | 1897-06-22 | Louis delettrez | ||
US4228498A (en) * | 1977-10-12 | 1980-10-14 | Dialog Systems, Inc. | Multibus processor for increasing execution speed using a pipeline effect |
US4926422A (en) * | 1987-11-04 | 1990-05-15 | Selenia Spazio S.P.A. | On-board switching controller for a satellite with on-board switching |
US5452291A (en) * | 1993-11-30 | 1995-09-19 | Panasonic Technologies, Inc. | Combination brouter and cluster controller |
US5627836A (en) * | 1995-01-31 | 1997-05-06 | Bell Atlantic Network Services, Inc. | VPI/VCI administration |
US5668810A (en) * | 1995-04-26 | 1997-09-16 | Scientific-Atlanta, Inc. | Data transmission protocol method and apparatus |
US5768539A (en) * | 1994-05-27 | 1998-06-16 | Bell Atlantic Network Services, Inc. | Downloading applications software through a broadcast channel |
US6014381A (en) * | 1996-09-13 | 2000-01-11 | Sony Corporation | System and method for distributing information throughout an aircraft |
US6032261A (en) * | 1997-12-30 | 2000-02-29 | Philips Electronics North America Corp. | Bus bridge with distribution of a common cycle clock to all bridge portals to provide synchronization of local buses, and method of operation thereof |
US6081533A (en) * | 1997-06-25 | 2000-06-27 | Com21, Inc. | Method and apparatus for an application interface module in a subscriber terminal unit |
US6122255A (en) * | 1996-04-18 | 2000-09-19 | Bell Atlantic Network Services, Inc. | Internet telephone service with mediation |
US6202103B1 (en) * | 1998-11-23 | 2001-03-13 | 3A International, Inc. | Bus data analyzer including a modular bus interface |
US20010043731A1 (en) * | 1997-04-04 | 2001-11-22 | Masamichi Ito | Data communication apparatus, method and system and programs for data communication process stored in computer readable storage medium |
US6377276B1 (en) * | 1998-06-18 | 2002-04-23 | Sony Corporation | Bitmap animation of on-screen-display graphics over a distributed network and a clipping region having a visible window |
US6389496B1 (en) * | 1998-01-29 | 2002-05-14 | Nec Corporation | Bridge including portals with ability to redefine network topology |
US6411276B1 (en) * | 1996-11-13 | 2002-06-25 | Immersion Corporation | Hybrid control of haptic feedback for host computer and interface device |
US6457152B1 (en) * | 1998-10-16 | 2002-09-24 | Insilicon Corporation | Device and method for testing a device through resolution of data into atomic operations |
US6477179B1 (en) * | 1997-05-09 | 2002-11-05 | Sony Corporation | Data receiving device and data receiving method |
US6553440B1 (en) * | 1998-12-24 | 2003-04-22 | Nec Corporation | Data transfer equipment for connecting a SCSI interface to an IEEE 1394 interface |
US6611892B1 (en) * | 1999-09-10 | 2003-08-26 | Matsushita Electric Industrial Co., Ltd. | Network bus bridge and system |
US20030188081A1 (en) * | 2002-03-28 | 2003-10-02 | Nec Engineering, Ltd. | Local bus bridge |
US6631415B1 (en) * | 1999-03-19 | 2003-10-07 | Sony Corporation | Method and system for providing a communication connection using stream identifiers |
US6747979B1 (en) * | 1998-10-27 | 2004-06-08 | Hewlett-Packard Development Company, L.C. | Method and apparatus for bridging between networks |
US6751221B1 (en) * | 1996-10-04 | 2004-06-15 | Kabushiki Kaisha Toshiba | Data transmitting node and network inter-connection node suitable for home network environment |
US6754185B1 (en) * | 1999-09-27 | 2004-06-22 | Koninklijke Philips Electronics N.V. | Multi link layer to single physical layer interface in a node of a data communication system |
Family Cites Families (23)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5327426A (en) * | 1991-09-27 | 1994-07-05 | Echelon Corporation | Method and apparatus for preventing unnecessary retransmission of messages in a networked messaging system |
DE69520378T2 (en) * | 1994-03-09 | 2001-10-31 | Matsushita Electric Industrial Co., Ltd. | Data transmission system and method |
JP3271493B2 (en) * | 1995-09-26 | 2002-04-02 | ヤマハ株式会社 | Network and data transmission method |
US5991520A (en) * | 1996-02-02 | 1999-11-23 | Sony Corporation | Application programming interface for managing and automating data transfer operations between applications over a bus structure |
SG77135A1 (en) * | 1996-04-26 | 2000-12-19 | Texas Instruments Inc | Method and system for assigning a channel number to a received data packet |
JPH09331340A (en) * | 1996-06-10 | 1997-12-22 | Toshiba Corp | Bus bridge |
US5847771A (en) * | 1996-08-14 | 1998-12-08 | Bell Atlantic Network Services, Inc. | Digital entertainment terminal providing multiple digital pictures |
US5973722A (en) * | 1996-09-16 | 1999-10-26 | Sony Corporation | Combined digital audio/video on demand and broadcast distribution system |
JP3719789B2 (en) * | 1996-10-04 | 2005-11-24 | 株式会社東芝 | Communication terminal device and relay device |
US6332159B1 (en) * | 1996-12-04 | 2001-12-18 | Canon Kabushiki Kaisha | Data communication system, apparatus and controlling method thereof |
JPH10174073A (en) | 1996-12-11 | 1998-06-26 | Sony Corp | Transmitter and transmission method |
JP3561107B2 (en) * | 1997-01-09 | 2004-09-02 | 株式会社東芝 | Network connection device |
JPH10229410A (en) * | 1997-02-14 | 1998-08-25 | Canon Inc | Data processor, electronic device, and communication system |
JPH10308764A (en) * | 1997-03-06 | 1998-11-17 | Toshiba Corp | Inter-network connector, equipment and method for communication |
US6073266A (en) * | 1997-04-16 | 2000-06-06 | Ericsson, Inc. | Cebus data link layer proxy |
JP3927647B2 (en) * | 1997-04-21 | 2007-06-13 | キヤノン株式会社 | Information processing apparatus, information processing method, and information processing system |
JP3171241B2 (en) * | 1998-03-06 | 2001-05-28 | 日本電気株式会社 | Communication method |
TW432840B (en) * | 1998-06-03 | 2001-05-01 | Sony Corp | Communication control method, system, and device |
US7013354B1 (en) * | 1998-10-05 | 2006-03-14 | Canon Kabushiki Kaisha | Channel protocol for IEEE 1394 data transmission |
US6167471A (en) * | 1998-10-14 | 2000-12-26 | Sony Corporation | Method of and apparatus for dispatching a processing element to a program location based on channel number of received data |
FR2786355B1 (en) * | 1998-11-25 | 2001-01-12 | Thomson Multimedia Sa | METHOD FOR MANAGING BANDWIDTH IN A COMMUNICATION NETWORK INCLUDING A WIRELESS LINK |
US6539450B1 (en) * | 1998-11-29 | 2003-03-25 | Sony Corporation | Method and system for adjusting isochronous bandwidths on a bus |
US6728821B1 (en) * | 1999-11-29 | 2004-04-27 | Sony Corporation | Method and system for adjusting isochronous bandwidths on a bus |
-
1999
- 1999-12-30 DE DE69940781T patent/DE69940781D1/en not_active Expired - Fee Related
- 1999-12-30 EP EP99126221A patent/EP1113626B1/en not_active Expired - Lifetime
-
2000
- 2000-12-28 JP JP2000403405A patent/JP2001223733A/en active Pending
- 2000-12-29 US US09/751,882 patent/US7180904B2/en not_active Expired - Fee Related
-
2007
- 2007-02-13 US US11/674,468 patent/US20070127470A1/en not_active Abandoned
- 2007-02-16 US US11/675,769 patent/US20070133404A1/en not_active Abandoned
Patent Citations (25)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US584771A (en) * | 1897-06-22 | Louis delettrez | ||
US4228498A (en) * | 1977-10-12 | 1980-10-14 | Dialog Systems, Inc. | Multibus processor for increasing execution speed using a pipeline effect |
US4926422A (en) * | 1987-11-04 | 1990-05-15 | Selenia Spazio S.P.A. | On-board switching controller for a satellite with on-board switching |
US5452291A (en) * | 1993-11-30 | 1995-09-19 | Panasonic Technologies, Inc. | Combination brouter and cluster controller |
US5768539A (en) * | 1994-05-27 | 1998-06-16 | Bell Atlantic Network Services, Inc. | Downloading applications software through a broadcast channel |
US5627836A (en) * | 1995-01-31 | 1997-05-06 | Bell Atlantic Network Services, Inc. | VPI/VCI administration |
US5668810A (en) * | 1995-04-26 | 1997-09-16 | Scientific-Atlanta, Inc. | Data transmission protocol method and apparatus |
US6122255A (en) * | 1996-04-18 | 2000-09-19 | Bell Atlantic Network Services, Inc. | Internet telephone service with mediation |
US6014381A (en) * | 1996-09-13 | 2000-01-11 | Sony Corporation | System and method for distributing information throughout an aircraft |
US6751221B1 (en) * | 1996-10-04 | 2004-06-15 | Kabushiki Kaisha Toshiba | Data transmitting node and network inter-connection node suitable for home network environment |
US6411276B1 (en) * | 1996-11-13 | 2002-06-25 | Immersion Corporation | Hybrid control of haptic feedback for host computer and interface device |
US20010043731A1 (en) * | 1997-04-04 | 2001-11-22 | Masamichi Ito | Data communication apparatus, method and system and programs for data communication process stored in computer readable storage medium |
US6477179B1 (en) * | 1997-05-09 | 2002-11-05 | Sony Corporation | Data receiving device and data receiving method |
US6081533A (en) * | 1997-06-25 | 2000-06-27 | Com21, Inc. | Method and apparatus for an application interface module in a subscriber terminal unit |
US6032261A (en) * | 1997-12-30 | 2000-02-29 | Philips Electronics North America Corp. | Bus bridge with distribution of a common cycle clock to all bridge portals to provide synchronization of local buses, and method of operation thereof |
US6389496B1 (en) * | 1998-01-29 | 2002-05-14 | Nec Corporation | Bridge including portals with ability to redefine network topology |
US6377276B1 (en) * | 1998-06-18 | 2002-04-23 | Sony Corporation | Bitmap animation of on-screen-display graphics over a distributed network and a clipping region having a visible window |
US6457152B1 (en) * | 1998-10-16 | 2002-09-24 | Insilicon Corporation | Device and method for testing a device through resolution of data into atomic operations |
US6747979B1 (en) * | 1998-10-27 | 2004-06-08 | Hewlett-Packard Development Company, L.C. | Method and apparatus for bridging between networks |
US6202103B1 (en) * | 1998-11-23 | 2001-03-13 | 3A International, Inc. | Bus data analyzer including a modular bus interface |
US6553440B1 (en) * | 1998-12-24 | 2003-04-22 | Nec Corporation | Data transfer equipment for connecting a SCSI interface to an IEEE 1394 interface |
US6631415B1 (en) * | 1999-03-19 | 2003-10-07 | Sony Corporation | Method and system for providing a communication connection using stream identifiers |
US6611892B1 (en) * | 1999-09-10 | 2003-08-26 | Matsushita Electric Industrial Co., Ltd. | Network bus bridge and system |
US6754185B1 (en) * | 1999-09-27 | 2004-06-22 | Koninklijke Philips Electronics N.V. | Multi link layer to single physical layer interface in a node of a data communication system |
US20030188081A1 (en) * | 2002-03-28 | 2003-10-02 | Nec Engineering, Ltd. | Local bus bridge |
Cited By (11)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US10039113B2 (en) | 2016-03-28 | 2018-07-31 | Bank Of America Corporation | Intelligent resource procurement system based on physical proximity to related resources |
US10063438B2 (en) | 2016-03-28 | 2018-08-28 | Bank Of America Corporation | Security implementation for resource distribution |
US10080132B2 (en) | 2016-03-28 | 2018-09-18 | Bank Of America Corporation | System for adaptation of multiple digital signatures in a distributed network |
US10135817B2 (en) | 2016-03-28 | 2018-11-20 | Bank Of America Corporation | Enhancing authentication and source of proof through a dynamically updatable biometrics database |
US10524268B2 (en) | 2016-03-28 | 2019-12-31 | Bank Of America Corporation | Intelligent resource procurement system based on physical proximity to related resources |
US10038607B2 (en) * | 2016-06-17 | 2018-07-31 | Bank Of America Corporation | System for aggregated machine-initiated resource distribution |
US10796253B2 (en) | 2016-06-17 | 2020-10-06 | Bank Of America Corporation | System for resource use allocation and distribution |
US10103936B2 (en) | 2016-06-21 | 2018-10-16 | Bank Of America Corporation | Computerized resource reallocation system for transferring resource blocks based on custodian event |
US10334462B2 (en) | 2016-06-23 | 2019-06-25 | Bank Of America Corporation | Predictive analytics for resource development based on information communicated from inter-related communication devices |
US10439913B2 (en) | 2016-07-01 | 2019-10-08 | Bank Of America Corporation | Dynamic replacement and upgrade of existing resources based on resource utilization |
US10127400B2 (en) * | 2016-09-26 | 2018-11-13 | Bank Of America Corporation | Control device for aggregation and distribution of machine-initiated resource distribution |
Also Published As
Publication number | Publication date |
---|---|
US7180904B2 (en) | 2007-02-20 |
US20070133404A1 (en) | 2007-06-14 |
EP1113626B1 (en) | 2009-04-22 |
EP1113626A1 (en) | 2001-07-04 |
DE69940781D1 (en) | 2009-06-04 |
JP2001223733A (en) | 2001-08-17 |
US20010026557A1 (en) | 2001-10-04 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US7180904B2 (en) | Interface link layer device to build a distributed network | |
US7822037B2 (en) | Apparatus for the reduction of uplink request processing latency in a wireless communication system | |
US6445711B1 (en) | Method of and apparatus for implementing and sending an asynchronous control mechanism packet used to control bridge devices within a network of IEEE STD 1394 serial buses | |
EP0924901B1 (en) | Gigabit ethernet interface to synchronous network (Sonet) ring | |
EP0788692B1 (en) | Method for assigning priority to traffic between local area networks interconnected via a backbone network | |
US6278708B1 (en) | Frame relay access device with user-configurable virtual circuit bundling | |
US20020085567A1 (en) | Metro switch and method for transporting data configured according to multiple different formats | |
WO2001086454A2 (en) | System having a meshed backplane and process for transferring data therethrough | |
US5533017A (en) | Line interface device for fast-packet switching network | |
WO2008119221A1 (en) | A data packet exchange method, device and circuit board | |
US7773501B2 (en) | Label assignment algorithm with receive-side processing implementation | |
US20010006520A1 (en) | Data Communications | |
JP2000349806A (en) | Network having several network clusters for radio transmission of packet | |
KR20020096048A (en) | Method for isochronous data transport over a wireless network | |
EP1210797B1 (en) | Method and apparatus for the reduction of upstream request processing latency in a cable modem termination system | |
CN115021875A (en) | Method and related apparatus for determining transmission time slot | |
US7701976B2 (en) | Communications system with segmenting and framing of segments | |
JP6029329B2 (en) | Synchronous network switch | |
WO1998043392A1 (en) | Method and apparatus for interconnecting control networks with time division multiplexing link | |
CN111786718A (en) | Satellite optical network management and control plane signaling transmission method based on AoS insertion service | |
JP2008294851A (en) | Pon system | |
JP3494264B2 (en) | Satellite line connection interface device | |
RU2277302C2 (en) | Method for remote collective control over digital television system | |
US20030118017A1 (en) | Method for assigning transmitting grants | |
KR20010058247A (en) | Hybrid Multiplexing Method for circuit and packet switched traffic |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
STCB | Information on status: application discontinuation |
Free format text: ABANDONED -- FAILURE TO PAY ISSUE FEE |