Multiplex communications – Pathfinding or routing – Switching a message which includes an address header
Reexamination Certificate
1999-12-28
2004-04-27
Rao, Seema S. (Department: 2666)
Multiplex communications
Pathfinding or routing
Switching a message which includes an address header
C725S074000, C370S466000, C370S463000
Reexamination Certificate
active
06728244
ABSTRACT:
BACKGROUND OF THE INVENTION
1. Field of the Invention
The present invention relates to a communication node for realizing data transfer between interconnected different networks by identifying packets on each network, managing correspondences of packets between different networks, and converting packets.
2. Description of the Background Art
In recent years, a new specification of serial bus called IEEE 1394 that has been developed as a next generation version of SCSI (Small Computer System Interface) is attracting much attention. The IEEE 1394 bus is capable of connecting a plurality of terminals in daisy chain or star connection and transfer wideband data in excess of 100 Mbps. Also, it has a major feature that it is possible to transmit both asynchronous data and isochronous data on the same cable.
For this reason, even though the IEEE 1394 was originally developed as a next generation version of SCSI, there are increasing trends to use the IEEE 1394 as a cable for connecting AV devices. Namely, there is a proposition that the large capacity data such as image and speech information that are conventionally transferred by analog signals between AV devices can be transferred by digital signals using the isochronous data transfer function of the IEEE 1394. The IEEE 1394 is very attractive because it also has a function for connection to digital devices such as PC using the asynchronous data transfer function, in addition to the function for large capacity real time data transfer between AV devices.
As such, the IEEE 1394 has both the AV data transfer function and the data communication function, so that it is now regarded as the most promising candidate medium for home networks. Already, protocols such as a control protocol for controlling AV devices connected by the IEEE 1394 bus and a protocol for resource reservation on the IEEE 1394 bus have been specified, so that the basic framework for utilizing the IEEE 1394 bus as the home network has been nearly completed.
In addition, discussions of a scheme for extending transfer of AV data transferred on the IEEE 1394 to a radio environment have also started. In particular, it has been specified that the IEEE 1394 will be utilized for re-distribution of broadcast type services within homes, such as transfer of image information broadcast by digital satellite broadcasting or digital terrestrial broadcasting that is expected to start providing services in near future, through the IEEE 1394 bus to a radio network. In this case, factors required for the radio network include a capability to realize a transmission rate exceeding 10 Mbps, a use of wavelength that can penetrate through walls of homes, and a potential for keeping its cost low.
Currently, in Japan, a proposition to allow free use of radio frequencies in 5 GHz band which is a frequency band that can satisfy these requirements has been made by the Ministry of Posts and Telecommunications, and concrete forms of utilization of the 5 GHz band have been discussed by ARIB (Association of Radio Industries and Business), where topics of discussions include a form of utilization in homes. However, the radio LAN has already been designated as the basic form of utilization of this 5 GHz band radio frequencies, so that the specification under discussion is also based on IEEE 802.11 (see IEEE Standards for “Wireless LAN Medium Access Control (MAC) and Physical layer (PHY) Specification”, for example) which is the standard specification of the radio LAN.
In the case of connecting the IEEE 1394 bus and the radio network, whether or not protocols for AV control that are designed to be executed on the IEEE 1394 bus can really be executable on the radio network may pose a problem. One of the features of the IEEE 1394 bus is that its data transfer is based on a combination of request and response. In contrast, in the radio LAN such as the IEEE 802.11, a MAC protocol such as CSMA/CA (Carrier Sense Multiple Access with Collision Detection) is basically used so that there is no guarantee that it is possible to realize the data transfer based on a combination of request and response.
Also, in the case of carrying out the AV data transfer on the IEEE 1394 bus, it is also necessary to execute the AV/C protocol (see AV/C Digital Interface Command Set General Specification, IEEE 1394-1995, for example) which is the control protocol for the IEEE 1394. This AV/C protocol basically presupposes execution on the IEEE 1394, so that its transfer protocol for control commands (such as “play”, “stop”, “fast forward” commands, for example) also requires execution of a command transmission and a response reception as one set.
FIG. 1
shows an outline of the AV/C protocol execution sequence.
The command/response in the AV/C protocol are required to be transferred by Write_Request packets of the IEEE 1394, so that Write_Request packets are used for transfer of an AV/C command from a Controller node
1001
to a Target node
1003
and transfer of an AV/C response from the Target node
1003
to the Controller node
1001
shown in FIG.
1
.
Also, the AV/C protocol requires transmission of commands to functional elements in the Target node
1003
(VTR Sub Unit
1031
and Tuner Sub Unit
1032
in
FIG. 1
) so that an FCP (Function Control Protocol) frame for carrying the AV/C command is allocated with a field for describing an identifier for identifying a destination functional element.
In addition, a processing time since the Target node
1003
received the AV/C command until the processing corresponding to the received command is executed and the AV/C response is returned to the Controller node
1001
is within 100 msec.
FIG. 2
shows packet formats in the case of transferring AV control commands defined in the AV/C protocol on Asynchronous packets on the IEEE 1394 (see ISO-IEC 61883, for example).
On the IEEE 1394 bus, a device to be controlled that received the AV/C command is required to return a header information of the FCP frame of the received AV/C command without any change to a controlling device that has transmitted the AV/C command, in order to establish a correspondence between the AV/C command and its response. In this way, the controlling device can determine an AV/C command transmitted by the own device that corresponds to the received AV/C response.
As mentioned above, in the case of extending transfer of AV data transferred on the IEEE 1394 bus to the radio network, it is also necessary to execute the above described AV/C protocol on the radio network. However, in this case, it is also necessary to execute the packet conversion processing for packets that are transferring AV/C commands at a connection point (such as a base station node (or access point)) between these networks.
For this reason, if the correspondence between the AV/C command that is transmitted via the base station node and the AV/C response that is received at the base station node is not known, it becomes impossible to determine a node on the IEEE 1394 bus to which the received AV/C response is to be transferred. In particular, in the current specification of the IEEE 802.11, no function for uniquely specifying such correspondences between commands and responses at a network level is defined. Consequently, when the AV/C command is transmitted from the base station node (Coordination Point) in the IEEE 802.11 network to the IEEE 802.11 terminal, there is a problem in that it is impossible to identify the earlier transmitted AV/C command which corresponds to the later received AV/C response.
As described, in an attempt to merge a network in which the data transfer is based on a combination of request and response such as the IEEE 1394 bus on which the AV/C protocol is executed with a network in which the data transfer is not based on a combination of request and response such as the IEEE 802.11, there is a problem that, even when there is a need to manage a correspondence between transfer data from a node on the former network to the latter network and transfer data from a node on the latter network to the former network, it has been
Jagannathan Melanie
Kabushiki Kaisha Toshiba
Oblon & Spivak, McClelland, Maier & Neustadt P.C.
Rao Seema S.
LandOfFree
Communication node for enabling interworking of network... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Communication node for enabling interworking of network..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Communication node for enabling interworking of network... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3221293