KR20090030548A - Apparatus and method for controlling ieee 1394 bridge - Google Patents

Abstract

An IEEE 1394 bridge control device and a method thereof are provided to use not only a wired 1394 apparatus to which a network function defined in the IEEE 1394.1 standard but also an existing legacy 1394 apparatus in a wired/wireless 1394 network without an additional modification. An IEEE(Institute of Electrical and Electronics Engineers) 1394 bridge control device comprise a virtual node management unit(210) and a virtual node emulator(220). The virtual node management unit outputs the information about an searched legacy 1394 apparatus, and establishes the tree of a local bus including physical nodes which exist in the local bus and all virtual nodes which correspond to the searched legacy 1394 apparatus. The virtual node emulator registers information of the virtual nodes corresponding to each of the searched legacy 1394 apparatus, and generates a response packet to a request packet for a virtual node.

Description

Apparatus and method for controlling IEEE 1394 bridge

The present invention relates to an IEEE 1394 bridge controller and method, and more particularly, to an IEEE 1394 bridge controller and method for enabling the application of legacy 1394 devices in an IEEE 1394 network to which a bridge defined in the IEEE 1395.1 standard is applied. It is about.

The IEEE 1394 (hereinafter referred to as '1394') bridge was published in 2004 through the IEEE 1394.1 standard. This specification is for bridges supporting 1394 networking between bridge-aware 1394 devices. The 1394 devices connected to bridges supporting IEEE 1394 networking are bridge-portal devices and bridge-aware devices. Aware Device, and Legacy 1394 Device. The IEEE 1394.1 bridge is a device that connects two 1394 buses and consists of a pair of bridge portal devices connected to each bus.

1 shows a configuration of a conventional bridge portal device.

Referring to FIG. 1, a conventional bridge portal device includes a FIFO manager 110, a packet router 115, a portal controller 120, a time manager 125, a stream manager 130, a network manager 135, and a node. The controller 140, the CSR processor 145, the transport layer 150, the IEEE 1394 framework 155, the IEEE 1394 device driver 160, the IEEE 1394 link controller 165, and the IEEE 1394 PHY controller 170. do.

The FIFO management unit 110 performs a function of inserting and removing a packet through the bridge FIFO memory, and the packet is transferred to another bus by the operation of the FIFO management unit 110. The packet router 115 determines whether to route a packet by referring to a routing map, converts an ID of a remote packet to be transmitted to the outside, and transmits the packet through the IEEE 1394 framework 155. In addition, the packet router 115 performs ID conversion on a packet input from the outside through the IEEE 1394 framework 155 and transfers the packet to a legacy 1394 device connected to the IEEE 1394 bus 175. In addition, the packet router 115 measures the maximum forward time and generates a congestion event. In addition, the packet router 115 performs global asynchronous stream packet (GASP) routing and isochronous stream packet routing using 4 channel FIFO.

The portal controller 120 controls the registered portal information management and FIFO manager 135. In addition, the portal controller 120 manages a message request / response register and performs alpha / prime portal selection and service. The time manager 125 performs synchronization of the IEEE 1394 network time and calculates an end time of the packet. The stream manager 130 generates and controls stream information based on a connection management protocol (CMP) and processes a message for stream management. The network manager 135 generates a clan / net allocation map and manages a routing map. The node controller 140 performs registration and management of the IEEE 1394 node, and controls each component after receiving the bus reset signal BUS_RESET.

The control and status register (CSR) processor 145 controls register access according to the transmission of the IEEE 1394 standard, and manages a routine (call-back) for processing a transfer request for the address area of the bridge device. In addition, the CSR processor 145 calls a routine according to register access (read, write, lock, etc.) and manages register information added for the bridge controller.

The transport layer 150 actually manages the reading and writing of data. The IEEE 1394 framework 155 performs the same role as the hardware adaptation layer (HAL) and provides a common interface frame with the IEEE 1394 device driver 160. The IEEE 1394 device driver 160 controls the hardware of the IEEE 1394 link control unit 165 and the IEEE 1394 PHY control unit 170, and stores hardware FIFO information through direct memory access (DMA) according to a hardware event. Transfer the packet data in memory to the hardware FIFO, etc. The IEEE 1394 link control unit 165 is a hardware block that performs an IEEE 1394 link layer function and has a hardware FIFO buffer for receiving and transmitting 1394 packets. The IEEE 1394 PHY controller 170 is a hardware block that performs a function of the IEEE 1394 physical layer, and performs functions such as bus arbitration, self ID setting, and physical layer packet processing.

The bridge recognition device is a 1394 device that recognizes a 1394 network, and may be a device such as a 1394 DV camcorder, 1394 D-VHS, 1394 D-TV, 1394 D-STB (Set-Top Box). Legacy 1394 devices are devices without the IEEE 1394.1 bridge specification. Local bus communication is only possible in current 1394 networks that do not employ a 1394 bridge, even if a 1394 network is configured. Legacy 1394 devices do not participate in configuring a 1394 network with a bridge, and because they do not have the ability to know and access remote devices, legacy 1394 devices cannot access other devices (remote devices) within the 1394 network outside the local bus. Do.

 Meanwhile, with the development of wireless technology, ultra wideband (UWB) technology, which has a transmission bandwidth provided by a 1394 bus, has been developed, and attempts to combine the technology of transmitting wired to high speed with wireless. In particular, audio / video (AV) devices are devices that transmit and receive large amounts of digital streaming data, and are based on 1394 or USB (Universal Serial Bus), which can be used simultaneously in wired and wireless environments. This is required.

An object of the present invention is to provide an IEEE 1394 bridge control apparatus and method for enabling the existing legacy 1394 device to which the IEEE 1394.1 bridge standard is not applied in a wired / wireless 1394 network without any modification.

The technical problem to be achieved by the present invention is to record a program for executing the IEEE 1394 bridge control method in a computer that allows the legacy legacy 1394 device to which the IEEE 1394.1 bridge standard is not applied in a wired / wireless 1394 network without any modification. To provide a computer-readable recording medium.

The IEEE 1394 bridge controller according to the present invention for solving the above technical problem, the legacy 1394 device retrieved by searching for a legacy 1394 device on the other bus in the direction and the other bridge portal device connected to one IEEE 1394.1 bridge A virtual node manager configured to output information about the network and to set a tree of a local bus including both a physical node existing on a local bus and a virtual node corresponding to the found legacy 1394 device; And register and manage information of a virtual node corresponding to each discovered legacy 1394 device based on the information on the discovered legacy 1394 device, and request a packet for the virtual node originating from a physical node present in the local bus. And a virtual node emulator for generating a response packet.

The IEEE 1394 bridge control method according to the present invention for solving the above technical problem, the other bridge portal device connected to one IEEE 1394.1 bridge and the legacy 1394 device on the other bus in the direction of the registration; Setting up a tree of the local bus including all physical nodes present on the local bus and virtual nodes corresponding to the discovered legacy 1394 devices; If the source of the request packet destined for the registered virtual node is a physical node existing on the local bus, the address of the request packet is translated into a global address and then transmitted to a remote physical node existing on another bus corresponding to the virtual node. And discarding the request packet if the source of the request packet destined for the registered virtual node is a remote node existing on another bus; And converting the response packet received from the remote physical node into a form in which the virtual node corresponding to the remote physical node responds and providing the packet to the physical node in the local bus that is the source of the packet.

According to the IEEE 1394 bridge control apparatus and method according to the present invention, in the 1394 network to which the wireless 1394 and IEEE 1394 bridge is applied, the existing legacy 1394 device as well as the wired 1394 device to which the network function defined in the IEEE 1394.1 standard is added is modified separately. Can be used on wired / wireless 1394 networks without

Hereinafter, with reference to the accompanying drawings will be described in detail a preferred embodiment of the IEEE 1394 bridge controller and method according to the present invention.

2 is a diagram showing the configuration of a preferred embodiment of the IEEE 1394 bridge control apparatus according to the present invention.

Referring to FIG. 2, the IEEE 1394 bridge controller according to the present invention corresponds to the existing bridge portal device shown in FIG. 1 and is provided over a bridge to allow a remote legacy 1394 device to be accessed from a physical node in a local bus. The virtual node manager 210 and the virtual node emulator 220 are added to components of the existing bridge portal device to register and emulate a legacy 1394 device on another bus of the virtual node. In this case, since the configuration and operation of other components are the same as those described with reference to FIG. 1, the following description only describes the configuration and operation of the newly added virtual node manager 210 and the virtual node emulator 220.

The IEEE 1394 bridge controller according to the present invention introduces the concept of a virtual node so that the legacy 1394 device can recognize the remote device, giving the remote device beyond the bridge a virtual physical node ID as if it were a local node in the local bus. Service. A device to which a virtual physical node ID is assigned is called a virtual node. When a virtual node is accessed, a remote physical device corresponding to the virtual node is accessed to reflect the result. Access to virtual nodes is available only to physical local nodes.

The virtual node manager 210 is a legacy 1394 on a different bus connected in that direction with another bridge portal device that is internally connected to the bridge portal device to which the virtual node manager 210 belongs in the IEEE 1394.1 bridge device. Search for a device. If one or more legacy 1394 devices are found, the virtual node manager 210 transmits information about the device to the virtual node emulator 220. When the node is registered as a virtual node by the virtual node emulator 220, the virtual node manager 210 "ENABLEs" the function of the virtual node emulator 220 and forcibly resets the local bus (BUS_RESET). Generate a signal. If the virtual node emulator 220 is "ENABLE", the virtual node manager 210 performs a self-ID packet forwarding procedure by a bus reset signal, thereby bridging the virtual node to a virtual port of the bridge portal device. Virtual nodes as well as physical nodes in the portal are simultaneously involved in the tree configuration of the local bus. Therefore, the self-ID packet generated in the bridge portal device at this time includes all the self-ID packet information of the virtual node registered in the virtual node emulator 220 of the bridge portal device.

When the bus reset is completed by performing tree setting of the physical node and the virtual node, when the portal control unit 120 of the bridge portal device collects information of all nodes including the virtual node in the local bus and processes the packet, The virtual packet serviced by the bridge portal device is a request packet from the local bus (a request packet where both the source bus ID and the destination bus ID are 0x3FF and the destination node ID refers to the node ID of the virtual node). 220 is not transmitted to the packet router 115 of the bridge portal device. Also, any request packets received from other bridge portal devices connected to the same IEEE 1394.1 bridge as the bridge portal device are discarded. These rules extend to virtual nodes served by the bridge portal device as well as to other virtual nodes within the local bus.

The virtual node emulator 220 registers information about the virtual node received from the virtual node manager 210 and is "ENABLE" by the virtual node manager 210. When power is first applied to the IEEE 1394.1 bridge, the virtual node management function of the virtual node emulator 220 is driven in a "DISABLE" state. In addition, the virtual node emulator 220 registers and services a separate CSR register that knows whether the virtual node is a virtual node in order to identify the virtual node in the local bus. In this case, the virtual node emulator 220 generates a response packet only for request packets originating from the local bus. When the bus reset of the bridge portal device is complete, the virtual node emulator 220 collects information of all local nodes and further accesses this information to identify whether it is a virtual node in the local bus. In addition, the virtual node emulator 220 receives a packet required from a physical node in the local bus, converts it into a global packet, and then delivers the packet to a remote node that actually exists, and sends the response packet received from the remote node back to the virtual node. Switch to the response form and provide it to the source of the packet.

When the virtual node emulator 220 accesses the PLUG information in the "CONNECTION" mode to support the AV device, the "JOIN request message" according to the streaming connection management rule of the IEEE 1394.1 bridge standard. ) And generate it to the remote physical node. When the response is normal, the plug information is updated to provide the corresponding response packet to the packet's source. In addition, when the virtual node emulator 220 accesses the plug information in the "DISCONNECTION" mode to support the AV device, the "LEAVE request message" according to the streaming connection management rule of the IEEE 1394.1 bridge standard. Remove the streaming connection between the remote physical nodes, if the streaming connection is normally removed, update the plug information and provide the corresponding response packet to the source of the packet.

If an error (transmission error, bus error, physical node non-existence, etc.) occurs while the virtual node emulator 220 performs the service of the virtual node, the virtual node manager 210 rechecks the actual physical node of the serviced virtual node. Check if there is one, and if it does not exist, perform the virtual node removal procedure. The virtual node emulator 220 performs a disconnection procedure in the "CONNECTION" mode according to the plug information currently set in the virtual node emulator 220 to discard the virtual node. Delete the information of the virtual node. After the virtual node information is deleted, the virtual node manager 210 generates a local bus reset signal and transmits to the virtual node emulator 220 that the virtual node in the local bus has been deleted.

3 is a flowchart illustrating a procedure of registering a virtual node in the IEEE 1394 bridge device according to the present invention.

Referring to FIG. 3, the virtual node manager 210 is connected to the bridge portal device to which the virtual node manager 210 belongs in the IEEE 1394.1 bridge device in the direction of another bridge portal device internally connected to the IEEE 1394.1 bridge device. The legacy 1394 device on another bus is searched for (S300). Next, the virtual node manager 210 transmits the detected information about the legacy 1394 device to the virtual node emulator 220, and the virtual node emulator 220 separately transmits information on the virtual node received from the virtual node manager 210. Is registered in the CSR register (S310). When the node is registered as a virtual node by the virtual node emulator 220, the virtual node manager 210 "ENABLEs" the function of the virtual node emulator 220 and forcibly resets the local bus (BUS_RESET). Generate a signal (S320). When the bus reset of the bridge portal device is completed, the virtual node emulator 220 collects information of all local nodes, and further accesses this information to identify whether the virtual node in the local bus (S330). Next, the virtual node manager 210 performs a tree configuration of the local bus by simultaneously participating in not only the physical node in the bridge portal but also the virtual node in a form in which the virtual node is connected to the virtual port of the bridge portal device (S340).

4 is a flowchart illustrating a packet processing process after registration of a virtual node is completed in the IEEE 1394 bridge device according to the present invention.

Referring to FIG. 4, the IEEE 1394 bridge device according to the present invention collects information of all nodes including a virtual node in a local bus and performs different operations depending on the origin of a packet destined for the virtual node when processing a packet. . If the source of the request packet destined for the virtual node is a physical node existing on the local bus of the bridge portal device (S400), the portal controller 120 transmits all of the request packets to the virtual node emulator 220 (S410). ). The virtual node emulator 220 receives the required packet from the physical node in the local bus, converts it into a global packet, and then transfers the packet to a remote node that actually exists (S420). Next, the virtual node emulator 220 converts the response packet received from the remote node into a form in which the virtual node responds and provides the packet to the source of the packet (S430). On the contrary, when a request packet destined for a virtual node is received from a node of another bridge portal device connected to the same IEEE 1394.1 bridge as the bridge portal device (S400), the portal controller 120 discards all the request packets (S400). S440).

5 is a flowchart illustrating a packet processing procedure of a virtual node emulator for each mode for supporting an AV device in the IEEE 1394 bridge device according to the present invention.

Referring to FIG. 5, when the virtual node emulator 220 accesses the PLUG information in the "CONNECTION" mode to support an AV device (S500), the streaming node management rule of the IEEE 1394.1 bridge standard is applied. In operation S510, a "join request message" is generated and transmitted to the remote physical node. If the response from the remote physical node is normal (S520), the virtual node emulator 220 updates the plug information and provides a corresponding response packet to the source of the packet (S530). On the contrary, if an error (transmission error, bus error, physical node non-existence, etc.) occurs during the service for the virtual node (S520), the virtual node manager 210 re-checks the physical node corresponding to the serviced virtual node. Check the presence (S540). If the physical node corresponding to the virtual node does not exist (S550), the virtual node manager 210 is accessing the plug information in the "CONNECTION" mode, by performing a disconnection procedure to discard all packets in the transmission operation The virtual node emulator 220 deletes the information of the virtual node (S560). After the virtual node information is deleted, the virtual node manager 210 generates a local bus reset signal and transmits to the virtual node emulator 220 that the virtual node in the local bus has been deleted (S570). In contrast, if a physical node corresponding to the virtual node exists (S550), it is determined that a transmission error, a bus error, etc. has occurred, and an error processing procedure corresponding to the corresponding error is performed (S580).

On the other hand, if the plug information is being accessed in the "DISCONNECTION" mode (S500), the virtual node emulator 220 generates a "LEAVE request message" according to the streaming connection management rule of the IEEE 1394.1 bridge standard. To remove the streaming connection between the remote physical nodes (S590). If the streaming connection is normally removed, the virtual node emulator 220 updates the plug information and provides a corresponding response packet to the source of the packet (S600).

As described above, the IEEE 1394 bridge control apparatus and method according to the present invention provides a bridge control technology capable of transmitting / receiving AV streaming data through a 1394 network between legacy 1394 devices in a 1394 network in which wired / wireless 1394 are mixed. The present invention relates to a technology in which an AV device on a remote 1394 bus is registered as a virtual node (virtual node) in the local bus so that a real local device in the local bus can access the remote AV device through the virtual node. This bridge control technology, which is not supported by the previously published IEEE 1394.1 bridge specification, is essential for using existing legacy 1394 devices in future wired / wireless 1394 networks.

The invention can also be embodied as computer readable code on a computer readable recording medium. Computer-readable recording media include all types of recording devices that store data that can be read by a computer system. Examples of computer-readable recording media include ROM, RAM, CD-ROM, magnetic tape, floppy disk, optical data storage, and the like, and may also be implemented in the form of a carrier wave (for example, transmission over the Internet). Include. The computer readable recording medium can also be distributed over network coupled computer systems so that the computer readable code is stored and executed in a distributed fashion.

Although the preferred embodiments of the present invention have been shown and described above, the present invention is not limited to the specific preferred embodiments described above, and the present invention belongs to the present invention without departing from the gist of the present invention as claimed in the claims. Various modifications can be made by those skilled in the art, and such changes are within the scope of the claims.

1 is a view showing the configuration of a conventional bridge portal device,

2 is a diagram showing the configuration of a preferred embodiment of the IEEE 1394 bridge controller according to the present invention;

3 is a flowchart illustrating a procedure of registering a virtual node in an IEEE 1394 bridge device according to the present invention;

4 is a flowchart illustrating a packet processing process after registration of a virtual node is completed in the IEEE 1394 bridge device according to the present invention;

5 is a flowchart illustrating a packet processing procedure of a virtual node emulator for each mode for supporting an AV device in the IEEE 1394 bridge device according to the present invention.

Claims (7)

An IEEE 1394 bridge controller for supporting a network between IEEE 1394 devices recognizing an IEEE 1394 bridge, Searches for legacy 1394 devices on other buses in that direction and other bridge portal devices connected to one IEEE 1394.1 bridge, outputs information about the discovered legacy 1394 devices, physical nodes on the local bus, and the discovered legacy 1394 devices. A virtual node manager configured to set a tree of a local bus including all virtual nodes corresponding to the device; And Registers and manages information of a virtual node corresponding to each discovered legacy 1394 device based on the information on the discovered legacy 1394 device, and responds only to a request packet for the virtual node originating from a physical node present in the local bus. IEEE 1394 bridge controller comprising a; virtual node emulator for generating a packet. The method of claim 1, The virtual node manager, when the registration of the virtual node by the virtual node emulator is completed, "Enabling" the function of the virtual node emulator (IEABLE), characterized in that to initialize the local bus. The method of claim 1, The virtual node emulator converts an address of a packet destined for a virtual node received from a physical node in the local bus into a global address, and then transmits the address to a remote physical node existing in another bus corresponding to the virtual node. And converting the response packet received from the remote physical node into a form in which the virtual node corresponding to the remote physical node responds, and providing the response packet to the physical node in the local bus which is the source of the packet. The method of claim 1, If an error occurs in the packet transmission and reception corresponding to the virtual node by the virtual node emulator, the virtual node manager checks the existence of a physical node corresponding to the virtual node, and the physical node is removed from another bus. And confirming that the virtual node emulator deletes the information of the virtual node after performing the disconnection procedure. An IEEE 1394 bridge control method for supporting a network between IEEE 1394 devices recognizing an IEEE 1394 bridge, Searching for and registering a legacy 1394 device on the other bus in the direction with another bridge portal device connected to one IEEE 1394.1 bridge; Setting up a tree of the local bus including both physical nodes present on the local bus and virtual nodes corresponding to the discovered legacy 1394 devices; If the source of the request packet destined for the registered virtual node is a physical node existing on the local bus, the address of the request packet is translated into a global address and then transmitted to a remote physical node existing on another bus corresponding to the virtual node. And discarding the request packet if the source of the request packet destined for the registered virtual node is a remote node existing on another bus; And And converting a response packet received from the remote physical node into a form in which the virtual node corresponding to the remote physical node responds, and providing the response packet to a physical node in the local bus that is the source of the packet. IEEE 1394 Bridge Control Method. The method of claim 5, If an error occurs while performing packet transmission / reception corresponding to the virtual node, the virtual node manager checks whether a physical node corresponding to the virtual node exists, and if it is confirmed that the physical node has been removed from another bus, disconnection procedure. And deleting the information of the corresponding virtual node in the virtual node emulator after performing the operation. A computer-readable recording medium having recorded thereon a program for executing the IEEE 1394 bridge control method according to claim 5 or 6.

Images