DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS

[0063] Hereinafter, the embodiments of the invention will be explained with reference to the attached drawings.

[0064] (First Embodiment)

[0065] The invention is adopted to, e.g., a network system 100 shown in FIG. 1 .

[0066] As shown in FIG. 1 , the system 100 includes a portable video camera 101 usable in a home and outside, a home station 102 provided in the home, a TV monitor 103 for a living room, a digital video tape recorder (simply referred as VTR hereinafter) 104 , and a personal computer (simply referred as PC hereinafter) 105 .

[0067] The system 100 uses a home bus (IEEE 1394-1995 interface (high performance serial bus) as digital I/F: hereinafter referred as 1394 serial bus) for connecting together respective digital equipments (home station 102 , living room TV monitor 103 , PC 105 and VTR 104 ) in the home.

[0068] The portable video camera 101 has a PHS function, and thus transmits video data obtained by taking a subject and reproduction video data stored in the body to the home station 102 . At this time, the data transmission is performed by wireless data communication (transfer) according to a PIAFS communication protocol (referred as PIAFS protocol hereinafter) developed on extension and public modes of the PHS.

[0069] The home station 102 receives the video data from the portable video camera 101 , and transmits it to the living room TV monitor 103 , the PC 105 or the VTR 104 through the 1394 serial bus.

[0070] Thus, later described in detail, the video data obtained by the camera 101 can be displayed on a screen of the monitor 103 , the PC 105 or the VTR 104 .

[0071] Further, for example, the video data reproduced by the VTR 104 is transmitted to the home station 102 through the 1394 serial bus.

[0072] The home station 102 which received the video data from the VTR 104 transmits it to the portable video camera 101 , by the wireless data communication according to the PIAFS protocol.

[0073] Thus, later described in detail, the video data obtained by the VTR 104 can be displayed on an LCD (liquid crystal display) of the video camera 101 or stored inside the camera 101 .

[0074] As explained above, in this system 100 , since the 1394 serial bus is used as the digital interface for connecting the respective equipments, outline of the 1394 serial bus will be initially explained.

[0075] Further, since PIAFS protocol is used for the wireless data communication with the portable video camera 101 , outline of the PIAFS protocol will be previously explained.

[0076] [Outline of 1394 Serial Bus]

[0077] With the development of home-use digital VTR and DVD (digital video disk), there is being required to support the transfer of data of a large amount such as video data or audio data (integrally called as AV data hereinafter) on real-time basis. For transferring such AV data on real-time basis, fetching such data into a PC (personal computer) or effecting transfer to other digital equipment, there is required an interface capable of high-speed data transfer with required transfer functions. For this purpose there has been developed the 1394 serial bus.

[0078] FIG. 2 shows an example of the network system constituted with the 1394 serial buses.

[0079] The system contains plural digital equipment A, B, C, D, E, F, G and H, and a twisted pair cable of the 1394 serial bus is used for making connections A-B, A-C, B-D, D-E, C-F, C-G and C-H.

[0080] As examples of the digital equipment A to H, a PC, a digital VTR, a DVD player, a digital camera, a hard disk, a monitor and the like are provided.

[0081] The connections among the digital equipment are a mixture of daisy chain connection and node branched connection, and the connections can be with high flexibility. The digital equipment A to H are respectively given specific ID's, which are mutually recognized to constitute a single network within the range of connection by the 1394 serial buses.

[0082] For example, since the unified network can be constituted by merely connecting each of the digital equipment with a 1394 serial bus cable (daisy chain connection), each equipment performs the function of relaying, thereby constituting the single network.

[0083] Further, since the 1394 serial bus corresponds to a plug and play function (automated mechanism on the interruption signal and the setting of I/O port address), there is automatically executed the recognition of the equipment and the connection status thereof when the cable is connected to the equipment.

[0084] For this reason, in the network system as shown in FIG. 1 , when an arbitrary equipment is deleted therefrom or newly added thereto, a bus resetting is automatically executed to reset the network configuration and the configuration of the network is constructed anew. This function allows to always set and recognize the current configuration of the network.

[0085] Also it has data transfer rates 100/200/400 Mbps, and an equipment having the higher transfer rate supports the lower transfer rate for achieving compatibility.

[0086] There are provided two data transfer modes, namely “isochronous transfer mode (ATM)” for transferring asynchronous data (hereinafter referred as async data) such as control signals, and “isochronous transfer mode” for transferring isochronous data (hereinafter referred as iso data) such as real-time AV data.

[0087] The async data and iso data are mixedly transferred within a predetermined communication cycle (usually 125 ps/cycle) after the transfer of a cycle start packet (CSP) indicating the start of a cycle and with priority given to the transfer of the iso data.

[0088] FIG. 3 shows the components constituting the 1394 serial bus.

[0089] As shown in FIG. 3 , the 1394 serial bus has a layer (hierarchic) structure.

[0090] There are provided a cable for the 1394 serial bus, of which connector is connected to a 1394 connector port.

[0091] On the 1394 connector port, a hardware portion (or hardware) including a physical layer and a link layer 812 .

[0092] The hardware is substantially constituted by an interface chip, in which the physical layer executes controls related to the encoding and to the connector, while the link layer executes controls related to the packet transfer and the cycle time.

[0093] On the hardware, a firmware portion (or firmware) including a transaction layer and a management layer is positioned.

[0094] The transaction layer manages the data to be subjected to transfer (transaction), and issues commands such as read, write and lock. The management layer manages the connection status and ID of the connected equipment, thereby managing the configuration of the network.

[0095] These hardware and firmware practically constitute the 1394 serial bus.

[0096] On the firmware, a software portion (or software) including an application layer is positioned.

[0097] The application layer is variable depending on the software to be used, and defines how the data are to be transferred in the interface by a protocol such as AV protocol.

[0098] FIG. 4 shows the address space of the 1394 serial bus.

[0099] Each equipment (node) connected to the 1394 serial bus is always given a 64-bit address specific to such node. Such address is stored in a memory of the node, so that the node address of own or another node can be always confirmed, and there can be executed communication designating the partner.

[0100] The addressing of the 1394 serial bus is based on the IEEE 1212 standard, and the initial 10 bits are used for designating the bus number, while the next 16 bits are used for designating the node ID number, and the remaining 48 bits are an address width given to the equipment, usable as a specific address space. The last 28 bits are used as a specific data area, for storing information for identifying each equipment or designating the condition of use.

[0101] The 1394 serial bus technique is principally constructed as explained in the foregoing.

[0102] In the following there will be given a more detailed explanation on the technique featuring the 1394 serial bus.

[0103] [Electric Specification of the 1394 Serial Bus]

[0104] FIG. 5 is a cross-sectional view of the 1394 serial bus cable.

[0105] As shown in FIG. 5 , the 1394 serial bus contains two sets of twisted pair signal lines and a power supply line, thereby enabling power supply to a equipment not provided with power source therein or showing a voltage lowering because of a failure.

[0106] The voltage of the DC power supplied from the power supply line is 8V to 40V, and the maximum DC current thereof is defined 1.5A.

[0107] [DS-Link Encoding]

[0108] FIG. 6 is a timing chart for explaining the DS-link (data/strobe link) encoding method for the data transfer format employed in the 1394 serial bus.

[0109] The DS-link encoding method employed therein is suitable for high-speed serial data communication, which requires two signal lines. One of the twisted pair signal lines is used for transmitting the main data and the other is used for transmitting strobe signal. Therefore, the receiving side can reproduce the clock signal by forming the exclusive logic sum (exclusive OR) of the communicated data and the strobe signal.

[0110] As above, the DS-link encoding method has various advantages such as a higher transfer efficiency in comparison with other serial data transfer methods, a smaller circuit magnitude of the controller LSI because the PLL (phase-locked loop) circuit can be dispensed with, and a lower electric power consumption by maintaining the transceiver circuit of each equipment in the sleep state because it is unnecessary to send information indicating the idle state in the absence of the data to be transferred.

[0111] [Bus Resetting Sequence]

[0112] In the 1394 serial bus, each connected equipment (node) is given a node ID and is recognized as a constituent of the network.

[0113] For example, when it becomes necessary to recognize the network configuration anew by a change in the network configuration, for example a change in the number of nodes by deletion or addition of a node or by an on/off operation of the power supply, each node detecting such change transmits a bus resetting signal on the bus, thereby entering a mode for recognizing the new network configuration.

[0114] The detection of the change is achieved by detecting a change in the bias voltage on the 1394 port board (shown in FIG. 3 , and merely referred as connector port hereinafter).

[0115] Receiving the bus resetting signal from a node, the physical layer ( FIG. 3 ) of each node simultaneously transmits the generation of bus resetting to the link layer ( FIG. 3 ) and also transmits the bus resetting signal to other nodes. The bus resetting is activated after the bus resetting signal is detected by all the nodes.

[0116] The bus resetting is activated by a hardware detection such as the insertion or extraction of a cable or an abnormality in the network, or by a direct command to the physical layer ( FIG. 3 ) for example from a host equipment according to the protocol. The data transfer is interrupted with the activation of bus resetting and is restarted, after the bus resetting, under the new network configuration.

[0117] [Node ID Determination Sequence]

[0118] As described above, after the bus resetting, the nodes enter an operation of giving ID's thereto for constructing the new network configuration. The general sequence from the bus resetting to the node ID determination will be explained with reference to flow charts shown in FIGS. 7, 8 and 9 .

[0119] The flow chart in FIG. 7 shows a series of bus operations from the generation of bus resetting to the determination of node ID whereupon the data transfer is enabled.

[0120] In FIG. 7 , initially constantly monitors the generation of a bus resetting in the network (step S 101 ). When a bus resetting is generated for example by a power on/off operation of the node, it executes declaration of the parent-child relationship between the directly connected nodes in order to know the connection status of the new network (step S 102 ).

[0121] When the parent-child relationship is determined among all the nodes in a step S 103 , a step S 104 determines a root. The declaration of the parent-child relationship in the step S 102 is executed and the root is not determined, until the parent-child relationship is determined among all the nodes.

[0122] After the root determination in the step S 104 , it executes a node ID setting operation for giving ID to each node (step S 105 ).

[0123] The node ID setting operation in the step S 105 is repeated with a predetermined order of nodes, until all the nodes are given ID's (step S 106 ).

[0124] When the step S 106 identifies the completion of ID setting in all the nodes, the new network configuration is recognized by all the nodes to enable data transfer among the nodes, and it executes the data transfer (step S 107 ). In the state of the step S 107 , there is again entered the mode of monitoring the generation of bus resetting, and, if a bus resetting is generated, the setting operations of the steps S 101 to S 106 are repeated.

[0125] The flow chart in FIG. 8 shows the detailed processes from the monitoring of the bus resetting (step S 101 ) to the root determination (step S 104 ), and the flow chart in FIG. 9 shows the detailed processes of the ID setting (steps S 105 , S 106 ).

[0126] Initially there will be explained the flow chart shown in FIG. 8 . When a bus resetting occurs (step S 201 ), the network configuration is once reset.

[0127] The step S 201 constantly monitors the generation of the bus resetting. Then in each equipment, a flag indicating that the equipment is a leaf (node), as a first step of the operation for re-recognizing the connection request of the network thus reset (step S 202 ).

[0128] Then each equipment checks the number of nodes to which the port of the equipment is connected (step S 203 ). According to the result indicating the number of ports, there is checked the number of undefined ports (for which the parent-child relationship is not determined) in order to start the declaration of the parent-child relationship (step S 204 ).

[0129] The number of ports checked in the step S 204 is equal to the number of undefined ports immediately after the bus resetting, but, the number of undefined ports varies with the proceeding of determination of the parent-child relationship.

[0130] Immediately after the bus resetting, the declaration of the parent-child relationship can be started only from a leaf. Being a leaf can be known from the confirmation of the number of ports in the step S 203 . The leaf declares, to a node connected thereto, that “the leaf itself is a child and the partner is a parent” (step S 205 ), and the sequence ends.

[0131] In a node having two or more ports in the step S 203 and recognized as a branch, the step S 204 identifies that the number of the undefined ports >1 immediately after the bus resetting, so that the node is given a branch flag (step S 206 ). Then it waits to receive the position as parent in the parent-child declaration from a leaf (step S 207 ).

[0132] The branch receiving the parent-child relationship declaration of the leaf in the step S 207 confirms the number of the undefined ports checked in the step S 204 , and, if the number of the undefined ports has become one, it can declare that “it is a child” in the step S 205 to the node connected to the remaining port. The branch having two or more undefined ports in the step s 204 in the second or subsequent cycle waits to receive the position as parent from a leaf or another branch in the step S 207 .

[0133] The declarations of the parent-child relationship is completed in the entire network when the number of the undefined ports checked in the step S 204 becomes eventually zero in a branch or exceptionally a leaf (because of a belated declaration of being a child), and the unique node having zero undefined port (being determined as the port of all the parents) is given a root flag (step S 208 ) and is recognized as a root (step S 209 ), and then the sequence ends.

[0134] Thus, there is completed the procedure from the bus resetting to the declarations of the parent-child relationship among all the nodes in the network.

[0135] Subsequently, in giving ID to the nodes, the ID setting can be initiated from a leaf. The ID setting is executed in the order of leaves, then branches and root, and in the increasing order of the node number starting from 0.

[0136] That is, in FIG. 9 , based on the data set in the flag FL, the flag information of the nodes, indicating leaves, branches and root and determined in the sequence are classified (step S 301 ).

[0137] If the result of the step S 301 is the leaves, it sets the number N (being a natural number) of the leaves present in the network (step S 302 ). Then, each leaf request an ID to the root (step S 303 ). In case of plural requests, the root executes an arbitration (step 304 ), and, it gives ID to a winning node and informs the losing nodes of the losing results (step S 305 ).

[0138] In a step S 306 , the leaf having failed to acquire ID issues the request for ID again, and the sequence is similarly repeated in the step S 303 .

[0139] On the other hand, the leaf having acquired ID transfers the ID information to all the nodes by broadcasting (communication from a node to unspecified plural nodes on the network) (step S 307 ). After the broadcasting of the ID information of a node, it decreases the number of the remaining leaves by one (step S 308 ).

[0140] After then, if a step S 309 identifies that at least one leaf remains, the sequence starting from the ID request in the step S 303 is repeated. When all the leaves have finally broadcast the ID information, the step S 309 identifies N=0, whereupon the ID setting shifts to branches (steps S 310 to S 317 ).

[0141] The ID setting for the branches is executed in a similar manner as in the case of leaves. At first it sets the number M (being a natural number) of the branches present in the network (step S 310 ). Then, each branch requests an ID to the root (step S 311 ).

[0142] In response, the root executes an arbitration (step S 312 ), and gives an ID number, next to the numbers already given to the leaves, to a winning node. The root informs the requesting branches with the ID information or the losing results (step S 313 ).

[0143] In a step S 314 , the branch having failed to acquire ID issues the request for ID again, and the sequence is similarly repeated in the step S 311 .

[0144] On the other hand, the branch having acquired ID transfers the ID information to all the nodes by broadcasting (step S 315 ). After the broadcasting of the ID information of a node, it decreases the number of the remaining branches by one (step S 316 ).

[0145] If a step S 317 identifies that at least one branch remains, the sequence starting from the ID request in the step S 311 is repeated. When all the branches have finally acquired the ID information, the acquired information is broadcasted, and the ID setting processes for the next root are executed (steps S 318 and S 319 ).

[0146] When the ID acquisition mode for the branches is terminated, in this state the root only has not acquired the ID information. Thus, the root sets the smallest ungiven number as its own ID number (step S 318 ), and it broadcasts the ID information of the root (step S 319 ).

[0147] It should be noted that the ID setting processes for this root are executed even if the result in the step S 301 indicates the root. Thus, in the above flow charts, there is completed the procedure after the determination of the parent-child relationship to the ID setting for all the nodes.

[0148] In the following there will be explained, as an example, the operations in an actual network shown in FIG. 10 .

[0149] FIG. 10 shows a hierarchic structure in which nodes A and C are directly connected under a root node B, while a node D is directly connected under the node C, and nodes E, F are connected under the node D. In the following there will be given an explanation on such hierarchic structure and the procedure of determining the root node and the node ID's.

[0150] After bus resetting, there is executed the declaration of the parent-child relationship between the directly connected ports of the nodes, in order to recognize the connection status of the nodes. In the parent-child relationship, the parent side assumes a higher position and the child side assumes a lower position in the hierarchic structure.

[0151] After the bus resetting in the configuration of FIG. 10 , the parent-child declaration is at first executed by the node A.

[0152] Basically, the parent-child declaration can be started from a node having connection only at a port thereof (such node being called a leaf). Such node can identify that it has the connection at one port only and-can therefore known that it constitutes an end of the network, and the parent-child relationship is determined from a fast reacting one among such leaves. Thus the port of the side declaring the parent-child relationship (namely node A in the connection A-B) is set as a child, and the port of the partner (node B) is set as a parent. Thus in the connections A-B, E-D and F-D there are respectively determined a child and a parent.

[0153] Then the procedure shifts to an upper level, and the parent-child relationship declaration to an further higher level starting from the nodes, among those having port with plural connections (such node being called a branch), having received the parent-child declaration from other nodes.

[0154] In FIG. 10 , the node D, after the determination of the parent-child relationship in D-E and D-F, declares the parent-child relationship to the node, whereby the nodes D, C are respectively determined as a child and a parent in the connection D-C.

[0155] The node C, having received the parent-child declaration from the node D, declares the parent-child relationship to the node B connected to another port, whereby the nodes C, B are respectively determined as a child and a parent in the connection C-B.

[0156] As a result the hierarchic structure shown in FIG. 10 is determined, and the node B finally becoming the parent in all the connected ports is determined as the root node.

[0157] There exists only one root within a network configuration. In the configuration shown in FIG. 10 the node B is determined as the root node, but the root node may shift to another node if the node B, having received the parent-child declaration from the node A, executes the parent-child declaration to another node at an earlier timing. Thus depending on the timing of declaration, any node may become the root node, and the root node is not fixed in a given network configuration.

[0158] After the determination of the root node, there is entered the mode of determining the node ID. Each of all the nodes informs all other nodes of the determined self ID (broadcasting function).

[0159] The self ID information contains the self node number, information on the connecting position, number of ports, number of connected ports, information on the parent-child relationship of each port, and the like.

[0160] The node ID assignment can be initiated from the nodes having connection only at a port (namely leaves), and the node numbers are assigned in the order of 0, 1, 2, among such leaves. The node having acquired the node ID transmits the information including the node number to other nodes by broadcasting. Thus such ID number is recognized as “already assigned”.

[0161] When all the leaves have acquired the self node ID's, ID numbers succeeding to those assigned to the leaves are then assigned to the branch nodes. As in the case of leaf, branches having acquired the node ID number broadcast the node ID information in succession, and the root node at last broadcasts the self ID information. Consequently the root node always has the largest node ID number.

[0162] In this manner the node ID assignment is completed for the entire hierarchic structure, whereby the network configuration is reconstructed and the bus initialization is completed.

[0163] [Bus Arbitration]

[0164] In the 1394 serial bus, an arbitration for the bus use right is always executed prior to the data transfer. The 1394 serial bus is a logic bus-type network in which the same signal is transmitted to all the equipment in the network by the relaying function of each connected equipment, the arbitration is indispensable for avoiding packet collision. Through such arbitration, only one node can execute transfer at a given time.

[0165] FIGS. 11A and 11B are the views for explaining the arbitration. That is, the arbitration procedure will be explained with reference to FIG. 11A showing the operation of requesting the bus use right and FIG. 11B showing the operation of permitting the bus use right. When the arbitration is initiated, a node or each of plural nodes issues a request for the bus use right to the parent node. In FIG. 11 A, the nodes C and F issue the requests respectively to the parent nodes B and A.

[0166] In response, the parent node (node A in FIGS. 11A and 11B ) issues (or relays) the request for the bus use right to a parent node. The request is finally delivered to the arbitrating root. In FIG. 11 A, the node A received the request from the node F requests the bus use right to the parent node F. Namely, the node A interrupts the request of the bus use right of the node F.

[0167] Receiving the request for the bus use right, the root node determines the node by which the bus is to be used. The arbitrating operation is executed only by the root node, and the permission to use the bus is given to the winning node in the arbitration. FIG. 11B shows a state in which the permission is given to the node C while the use by the node F is refused. A DP (data prefix) packet is transmitted to the losing node, indicating the refusal of the request. The request for the bus use right from the refused node has to wait until the next arbitration.

[0168] On the other hand, the node having won the arbitration and acquired the permission for using the bus can thereafter start the data transfer.

[0169] The flow of the arbitration will be explained with reference to flow charts shown in FIG. 12 .

[0170] In order that the node can initiate the data transfer, the bus has to be in the idle state. In order to recognize that the bus is currently empty after the completion of the preceding data transfer, there is predetermined an idle time gap length (for example subaction gap) for each transfer mode, and each node judges that it can start its transfer after the lapse of such time gap.

[0171] It discriminates whether a predetermined gap length is obtained corresponding to the data to be transferred such as the async data or iso data (step S 401 ). The sequence waits until the predetermined gap length is obtained, since the bus use right required for starting the data transfer cannot requested unless such gap length is obtained.

[0172] The predetermined gap length is obtained in the step S 401 , it discriminates whether data to be transferred are present (step S 402 ), and, if present, it issues a request for the bus use right for securing the bus to the root (step S 403 ). The signal representing the request for the bus use right is transmitted through the nodes in the network as shown in FIG. 11 A and eventually delivered to the root.

[0173] If the step S 402 identifies absence of data, the sequence remains in the waiting state.

[0174] Then, if the root receives at least a request for the bus use right issued in the step S 403 (step S 404 ), the root checks the number of the nodes having issued the request (step S 405 ).

[0175] If the step S 405 identifies that the node number = 1 (request issued from only one node), the permission to use the bus is to be given to such node immediately thereafter (step S 408 ).

[0176] On the other hand, if the step S 405 identifies the node number >1 (requests issued from plural nodes), the root executes an arbitration for selecting one node for giving the permission (step S 406 ). This arbitration is conducted in such fair manner that the permissions are not given to a particular node but uniformly given to all the nodes (i.e., fair arbitration).

[0177] Then, the root classifies, among the plural nodes having issued the request in the step S 403 , a winning node that has acquired the permission by the arbitration and other losing nodes (step S 407 ).

[0178] The root sends a permission signal to the single node that has acquired the permission as the result of the arbitration or without the arbitration in case the node number=1 (step S 408 ), and the node having received the permission signal immediately initiates the transfer of the data (packet) to be transferred. After the data transfer is completed, the flow returns to the step S 401 .

[0179] The root also sends, in a step S 409 , the aforementioned DP packet indicating the loss in the arbitration to the node which has failed to acquire the permission in the arbitration (step S 409 ). The node which has received the DP packet returns to the step S 401 in order to issue again the request for the bus use right for data transfer, and waits until the predetermined gap length is obtained in the step S 401 .

[0180] [Asynchronous (Non-Sync) Transfer]

[0181] FIG. 13 shows phases in time of the asynchronous transfer, in which the initial subaction gap indicates the idle state of the bus. When this idle time reaches a predetermined value, the node wishing the data transfer judges that the bus is available and enters the arbitration process for acquiring the bus use right.

[0182] When the bus use right is acquired in the arbitration, the data transfer is executed in a packet format. After the data transfer, the receiving node completes the transfer by returning an acknowledgment code “ack” indicating the result of reception or sending a response packet, after a short gap called “ack gap”. The “ack” code consists of 4-bit information and 4 check sum bits, including information indicating whether the transfer is successful or pending or the line is busy, and is immediately returned to the transmitting node.

[0183] FIG. 14 shows an example of the packet format for the asynchronous transfer. The packet consists of a data portion, CRC (cyclic redundancy check) data for error correction and a header, which contains, as shown in FIG. 14, a destination node ID, a source node ID, a transfer data length and various codes.

[0184] The asynchronous transfer is a one-to-one communication from the source node to the destination node. The packet transferred from the source node is delivered to all the nodes in the network, but is disregarded in the nodes different in address and is read by the only one node of the address.

[0185] [Isochronous (Sync) Transfer]

[0186] The isochronous transfer is a synchronized transfer. The isochronous transfer, constituting the most important feature of the 1394 serial bus, is particularly suitable for transfer of the data requiring real-time transfer, for example multi-media data such as video image data or audio data.

[0187] In contrast to the asynchronous transfer in the one-to-one form, the isochronous transfer is conducted from the transferring source node to all other nodes uniformly by the broadcasting function.

[0188] FIG. 15 shows phases in time of the isochronous transfer. The isochronous transfer is executed on the bus at a constant interval, which is called the isochronous cycle and is selected as 125 μs. A cycle start packet (CSP) indicates the start time of the isochronous cycle, thus adjusting the time in each node. The cycle start packet is transmitted by a node called cycle master, which transmits the cycle start packet indicating the start of a cycle, after the lapse of a predetermined idle time (subaction gap) following the end of transfer in the immediately preceding cycle. Thus the cycle start packets are transmitted with an interval of 125 ps.

[0189] As indicated by channels A, B and C in FIG. 15 , the packets of plural kinds within a cycle are respectively given channel ID's and can be distinguished in the transfer. Consequently the real-time simultaneous transfers among plural nodes are made possible, and the receiving node fetches the data of a desired channel ID only.

[0190] The channel ID does not indicate the address of the destination but merely gives a logic number to the transferred data. Consequently any packet is transmitted by broadcasting from a source node to all other nodes.

[0191] Prior to the isochronous packet transfer, there is executed an arbitration as in the case of asynchronous transfer. However, in the isochronous transfer, which is not the one-to-one transfer, there is no acknowledgment code.

[0192] The isochronous gap (iso gap) shown in FIG. 15 indicates an idle time required for confirming the availability of the bus, prior to the start of the isochronous transfer. When this idle time lapses, the node wishing the isochronous transfer judges that the bus is available and can enter the arbitration prior to the data transfer.

[0193] FIG. 16 shows an example of the packet format for the isochronous transfer. The packet divided in each channel consists of a data portion, CRC (cyclic redundancy check) data for error correction and a header, which contains a transfer data length, a channel number, various codes and an error correcting CRC data.

[0194] [Bus Cycle]

[0195] On the actual 1394 serial bus, the asynchronous transfer and the isochronous transfer can be present in mixed manner. FIG. 17 shows phases in time of the transfer state on the bus wherein the asynchronous transfer and the isochronous transfer are present in mixed manner.

[0196] The isochronous transfer has the higher priority than the asynchronous transfer, because, after the cycle start packet, the isochronous transfer can be activated with a shorter gap length (isochronous gap) of the idle period than the gap length (subaction gap) required for activating the asynchronous transfer. Therefore the isochronous transfer is executed preferentially to the asynchronous transfer.

[0197] In a general bus cycle shown in FIG. 17 , the cycle start packet is transferred from the cycle master to other nodes at the start of a cycle #m. In response each node executes time adjustment, then the node wishing the isochronous transfer enters arbitration after waiting for the predetermined idle period (isochronous gap) and then transfers the packet. In FIG. 17 , the isochronous transfer is executed in succession in the channels e, s and k.

[0198] The sequence from the arbitration to the packet transfer is repeated for the number of assigned channels to complete the isochronous transfer in the cycle #m, and the asynchronous transfer is then enabled.

[0199] When the idle time reaches the subaction gap required for the asynchronous transfer, the node wishing the asynchronous transfer judges that it can enter the arbitration.

[0200] However, the asynchronous transfer is enabled only if the subaction gap required for activating the asynchronous transfer can be realized within the period from the end of the isochronous transfer to the time (cycle synch) for transferring the next cycle start packet.

[0201] The cycle #m shown in FIG. 17 executes isochronous transfer of 3 channels and asynchronous transfer of 2 packets (packets 1 and 2) including the acknowledgments. The cycle #m ends after the asynchronous packet 2 because there is reached the time (cycle synch) for starting the cycle #m+1.

[0202] However, if the time (cycle synch) for starting the next cycle is reached in the course of an isochronous or asynchronous transfer, such transfer is not interrupted but the cycle start packet of the next cycle is transmitted in the idle time after the end of such transfer. Thus, if a cycle continues in excess of 125 μs, the next cycle is made correspondingly shorter than 125 μs. In this manner the isochronous cycle can be made longer or shorter, taking 125 μs as the standard.

[0203] However, the isochronous transfer, if requested, is always executed in every cycle in order to maintain the real-time transfer, while the asynchronous transfer may be delayed to the next or subsequent cycle in case the cycle time is shortened. The cycle time, including information on such delay, is managed by the cycle master.

[0204] In the foregoing, there has been summarized the functions of the IEEE 1394 serial bus.

[0205] Subsequently, the outline of the PIAFS protocol will be explained.

[0206] [Outline of PIAFS Protocol Technique]

[0207] “PIAFS” represents PHS Internet Access Forum Standard which provides the transfer control procedure for realizing high-quality data transfer by using 32 Kbits/sec unrestricted digital bearer. The transfer control procedure (PIAFS procedure) will be explained with reference to FIG. 18 .

[0208] In FIG. 18 , the high level protocol represents the protocol depending on application program such as facsimile communication, PC communication and Internet communication. The physical layer represents the layer for converting the signal format output in the procedure into the form suitable for the physical line.

[0209] The PIAFS procedure between the high level protocol and the physical layer includes an in-band negotiation procedure and an ARQ transfer control procedure. The in-band negotiation procedure is the procedure in which end-to-end negotiation is performed before establishment of data link and one of plural data link protocols is selected in order to be able to cope with ulterior image transfer and future new transfer system. The ARQ transfer control procedure is the error control procedure corresponding to the layer 2 in the PHS communication phase.

[0210] Hereinafter, the PIAFS protocol will be explained in more detail.

[0211] [In-Band Negotiation Procedure]

[0212] FIG. 19 shows the in-band negotiation.

[0213] As shown in FIG. 19 , the in-band negotiation part selects one of a data transfer protocol, a real-time protocol and a future protocol on the basis of the in-band negotiation.

[0214] FIG. 20A shows the frame structure of the in-band negotiation.

[0215] In FIG. 20 A, “FI” is used to discriminate whether there is the negotiation frame or the negotiation frame including a sync function.

[0216] “DATA LENGTH” represents the data lengths of “SYNC” to “P 1 , P 2 , . . . , Pn” in number of bytes. For example, if n=2 and thus the data length is “SYNC” to “P 2 ”, the data length=12 (bytes) is set.

[0217] “SYNC” is used to establish frame sync (or frame synchronization). The detection condition is that all the bits are coincident (no error tolerance).

[0218] “NEGOTIATION CLASSIFICATION” is used to represent classification of “REQUEST” (negotiation request to partner station), “RECEPTION” (reception response to negotiation request) and “REFUSAL” (refusal response to negotiation request).

[0219] “P 1 , P 2 , . . . , Pn” is used to represent the classification of the protocol. For example, “P 1 ” represents the data transfer protocol, and the “P 2 ” represents the real-time protocol.

[0220] “FCS” is used to detect a frame error in accordance with ITU-T Recommendation V4.2 CRC-32.

[0221] “OPTION” has such a structure as shown in FIG. 20B if “FI” represents the negotiation frame including the sync function.

[0222] The negotiation procedure is as follows.

[0223] (1) The data link starting side (also called as control starting side) sets the usable protocols to the negotiation frames “P 1 to Pn” in the priority order, sets “REQUEST” to “NEGOTIATION CLASSIFICATION”, and sends them to the partner station. Then the data link starting side starts a waiting timer for “REQUEST”, and continuously sends the “REQUEST” setting frame until “REQUEST” is received from the partner station.

[0224] If there is only one usable protocol, only “P 1 ” is used. On the other hand, if there are the plural usable protocols, “P 1 , P 2 , . . . , Pn” are used according to the priority order, and “FI” is set to the negotiation frame including the sync function. The “OPTION” area in this case accords to the structure shown in FIG. 20B .

[0225] (2) The data link started side (i.e., side to which data link is started) (also called as control started side) selects only one usable protocol in the requested priority order, from the usable protocols indicated by the reception frame “P 1 to Pn”. Concretely, if the requested first-priority protocol is usable at the control started side, such the first-priority protocol is selected. On the other hand, if the first-priority protocol is unusable and the second-priority protocol is usable, such the second-priority protocol is selected.

[0226] (3) The control started side sets the protocol selected in the above procedure (2) to “P 1 ”, sets “RECEPTION” to the frame “NEGOTIATION CLASSIFICATION”, and continuously sends them to the control starting side.

[0227] At this time, if the protocol (i.e., selected protocol) set to “P 1 ” is the data transfer protocol, “FI” is set to the negotiation frame including the sync function. The “OPTION” area in this case accords to the structure shown in FIG. 20B .

[0228] (4) If the “RECEPTION” setting frame is received from the partner station, the control starting side stops a waiting timer for “RECEPTION”, selects the protocol indicated by the reception frame “P 1 ”, and ends the negotiation. Then the control starting side establishes the data link. If “FI” of the received frame is the negotiation frame including the sync function, the ARQ frame sync and RTF measurement end.

[0229] (5) If the control started side does not have the usable protocol indicated by the reception frame “P 1 to Pn”, nothing is set to “P 1 to Pn” and “REFUSAL” is set to “NEGOTIATION CLASSIFICATION”. Then the control started side continuously sends them to the control starting side.

[0230] If the control starting side receives the “REFUSAL” setting frame, it stops the “RECEPTION” waiting timer and releases the physical link.

[0231] (6) If competition occurs in the negotiation, i.e., if both sides are the control starting sides and the protocols resulted from the negotiation are incoincident, it can be recognized that these sides become incoincident with each other. Thus, the data link is not started, but the negotiation is again started.

[0232] [ARQ Transfer Control Procedure]

[0233] FIG. 21 shows the structure of the sync frame to be transmitted and received in the ARQ transfer control. The sync frame shown in FIG. 21 is the frame to be sent for frame sync. As the sync frame, there are three kinds of frames, i.e., sync request, sync reception and sync refusal classified in “SYNC CLASSIFICATION” area shown in FIG. 20B .

[0234] FIG. 22 shows the structure of the control frame, and FIG. 23 shows the structure of the data frame.

[0235] In these drawings, “FI” is used to discriminate whether there is the negotiation frame, the negotiation frame including the sync function, the sync frame, the control frame or the data frame.

[0236] “FFI” is “Feed Forward Information” and represents the frame number in the ARQ transfer control.

[0237] “FBI” is “Feed Back Information” and represents the request frame number in the ARQ transfer control.

[0238] “CONTINUOUS FRAME DISCRIMINATION BIT” represents whether continuous frame exists in the control frame and the data frame.

[0239] “DATA LENGTH” represents the range from the true data length to “FCS” in which available data exists, in the unit of bytes. “DATA LENGTH” in the sync request or the sync reception is “8”, and “DATA LENGTH” in the sync refusal is “9”. Further, “DATA LENGTH” in the control frame (continuous frame) represents the control information field for each frame.

[0240] “SYNC” is used to establish frame sync. The detection condition is that all the bits are coincident (no error tolerance).

[0241] “CONTROL INFORMATION” is transferred by the control frame. In the transfer system, every time the control frame is transmitted, reception confirmation of the frame is expected by the control frame reception side.

[0242] “FCS” is used to detect the frame error in accordance with ITU-T Recommendation V4.2 CRC-32.

[0243] The area next to “SYNC” accords to the structure shown in FIG. 20B . In this area ( FIG. 20B ), “SYNC CLASSIFICATION” is set with “SYNC RECEPTION” as the response when the control starting side receives “SYNC REQUEST”, and the frame of this reception is sent. If the data link is impossible, “SYNC REFUSAL” is set, and the frame of this refusal is sent. If the “SYNC REQUEST” transmission side receives “SYNC REFUSAL” as the response, sending of the “SYNC REQUEST” setting frame is stopped.

[0244] “COMMON ORDER NUMBER” represents the numbers independently counted by the control starting side and the control started side. Every time the “SYNC REQUEST”, “SYNC RECEPTION” and “SYNC REFUSAL” setting frames are sent, the number is increased one by one from sending start of “SYNC REQUEST”. Then if the result of increment exceeds “255”, the number is returned to “1” and then the increment restarts. Such “COMMON ORDER NUMBER” is used for the RTF measurement, and its initial value is “1”.

[0245] “SAME ORDER NUMBER” represents the number incremented one by one from sending start of “SYNC RECEPTION” and “SYNC REFUSAL”. If the result of increment exceeds “255”, the number is returned to “1” and then the increment restarts. Such “SAME ORDER NUMBER” is used for the RTF measurement, and its initial value is “1”. However, “SAME ORDER NUMBER” for “SYNC REQUEST” is fixed to be “1”.

[0246] “CONFIRMATION RESPONSE NUMBER” is to set “COMMON ORDER NUMBER” of the initially received “SYNC REQUEST” setting frame. Such setting is performed when “SYNC RECEPTION” or “SYNC REFUSAL” is set to send this frame. Such “CONFIRMATION RESPONSE NUMBER” is also used for the RTF measurement, and “CONFIRMATION RESPONSE NUMBER” in “SYNC REQUEST” is fixed to be “1”.

[0247] “SYNC REFUSAL REASON DISPLAY” is to set predetermined information at the “SYNC REFUSAL” setting frame sending when response is impossible for some reasons although “SYNC REQUEST” has been received.

[0248] The sync frame, the control frame and the data frame including the above areas are sequentially sent from most significant bit (MSB) toward least significant bit (LSB).

[0249] FIG. 24 shows coding of “CONTROL INFORMATION” of the control frame shown in FIG. 22 .

[0250] In FIG. 24 , “CONTROL INFORMATION CLASSIFICATION IDENTIFIER” represents request, notification, reception (of request), refusal (of request), response (to notification), continuous frame transmittable and the like.

[0251] “SEQUENCE NUMBER” represents by the modulo 16 the sequence number of which contents are indicated by “CONTROL INFORMATION CLASSIFICATION IDENTIFIER”, and discriminates the correspondence between the control information (request and notification) sent from the started side and the reception confirmation number (reception, refusal, response continuous frame transmittable) sent from the started side.

[0252] “CONTROL INFORMATION CONTENT IDENTIFIER” is to discriminate the contents of the information indicated by the modulo 3 or lower. In this area, the discrimination information such as the control information (communication parameter setting) concerning data link establishment, the in-communication control information (ARQ parameter setting), the control information (data link release) concerning data link release, and other control information (user control information) are stored.

[0253] FIG. 25 shows the contents of the control information (communication parameter setting) concerning data link establishment.

[0254] The messages of communication parameters are to set the communication parameter in the above transfer system, and initially sent from the control starting side when the communication by the ARQ transfer control starts.

[0255] In FIG. 25 , the octet 3 represents “ARQ data transfer protocol version”, and thus the protocol version concerning the data transfer in the ARQ transfer control is notified. This “ARQ data transfer protocol version” can be end-to-end negotiated. For example, if there are the plural protocol versions, the lower version is selected and set in the negotiation.

[0256] The octet 4 represents “ARQ control information transfer protocol version”, and thus the protocol version concerning the control information transfer in the ARQ transfer control is notified. This “ARQ control information transfer protocol version” includes protocol regulation concerning a sync system of the ARQ transfer control. Further, also the “ARQ control information transfer protocol version” can be end-to-end negotiated. If there are the plural protocol versions, the lower version is selected and set in the negotiation.

[0257] The octet 5 represents “measured RTF value”, and thus the RTF value measured is notified by the sync frame exchange in the ARQ control transfer.

[0258] The octet 6 represents “data compression identifier”, and thus a data compression system in case of performing the data communication by the ARQ transfer control is designated. Also, the “data compression identifier” can be end-to-end negotiated.

[0259] The octet 7 represents “total number of codes”, i.e., the parameter P 1 of the data compression system (V42.bis).

[0260] The octet 8 represents “maximum character string length”, i.e., the parameter P 2 of the data compression system (V42.bis).

[0261] The octet 9 represents “frame length”, and thus the frame length in the ARQ transfer control can be set. Also, the “frame length” can be end-to-end negotiated.

[0262] The octet 10 represents “maximum frame number”, i.e., the modulo number. The “maximum frame number” is set by the initial negotiation.

[0263] The octet 73 represents “reception result/refusal reason (reason display)”. In this octet, “reception result” is the reception result of the request message in the reception message. For example, as “reception result”, there are “all setting possible”, “partial setting possible” and the like. Further, “refusal reason” is the reason for refusing the request message in the refusal message. For example, as “refusal reason”, there are “description error”, “setting impossible” and the like.

[0264] FIG. 26 shows the contents of the in-communication control information (ARQ parameter setting).

[0265] The in-communication control information is used to measure the RTF at the control starting side every time the ARQ sync starts and to notify the measured RTF after the ARQ sync completion from the control starting side to the started side, during the data communication by the ARQ transfer control.

[0266] FIG. 27 shows the contents of the control information (data link release) concerning the data link release.

[0267] In FIG. 27 , in the “reception result/refusal reason (reason display)”, for example, “normal release”, “normal release and data link continuity prohibition”, “DTE busy”, “temporary obstacle”, “request parameter setting nonrecognition”, “request parameter current setting impossible”, “unprovided parameter designation” and the like are set.

[0268] FIG. 28 shows the contents of other control information (user control information).

[0269] The information is to transmit the user information. The contents of the information field is not at all restricted, and the user information can be freely used by the user. However, if the request of incomprehensible user information is received, the refusal with the setting impossible reason is sent. Even if the notification of incomprehensible user information is received, it is necessary to send the response to such the notification.

[0270] FIG. 29 shows the contents of the continuous frame transmission possible information.

[0271] In the frame of which “control information classification” has been set with “request” or “notification”, the information is to enable the continuous frame transmission to the control frame transmission side.

[0272] The operation sequence of the ARQ transfer control by the sync frame, the control frame and the data frame is as follows.

[0273] (1) Link Establishment

[0274] <Control Starting Side>

[0275] In this sequence, if there is the communication request from the high-level module, the negotiation frame (negotiation classification: request, sync function existing, sync request) is initially sent so as to establish the ARQ frame sync. After then, a sync reception waiting timer is started, to detect the negotiation frame (negotiation classification: reception, sync function existing, sync reception) from the partner. In case of time-out, failure of the transmission request is notified to the high-level module. If the negotiation frame (negotiation classification: reception, sync function existing, sync reception) from the partner is detected, it is considered that the sync is given. Thus, the sync reception waiting timer is stopped, initial setting to an internal parameter or the like is performed, and the negotiation of the communication parameter is performed. The link establishment is completed at normal completion of the negotiation, the communication request establishment is notified to the high-level module, and it enters into the in-communication state. If the negotiation of the communication parameter is not normally completed due to parameter incoincidence or the like, the communication request failure is notified to the high-level module.

[0276] <Control Started Side>

[0277] If the negotiation frame (negotiation classification: request, sync function existing, sync request) from the control starting side is detected, the negotiation frame (negotiation classification: reception, sync function existing, sync reception) is sent. After then, the sync reception after-transmission timer is started to detect the control frame (request) from the partner. In case of time-out, the sync establishment failure is notified to the high-level module. If the control frame (request) from the partner is detected, it is considered that the sync is given. Thus, the sync reception after-transmission timer is stopped, initial setting to an internal parameter or the like is performed, and the negotiation of the communication parameter is performed. The link establishment is completed at normal completion of the negotiation, the sync establishment is notified to the high-level module, and it enters into the in-communication state. If the negotiation of the communication parameter is not normally completed due to parameter incoincidence or the like, the sync establishment failure is notified to the high-level module.

[0278] (2) Link Release

[0279] <Control Starting Side>

[0280] In this sequence, if there is the release request from the high-level module or the internal release request, the control frame (data link release) is initially sent so as to request the link release. After then, a confirmation waiting timer is started to detect the response confirmation frame from the partner. In case of time-out, it is considered that the link is released. Thus, the link release is notified to the high-level module, and the communication ends. If the response confirmation frame from the partner is detected, it is considered that the link is released. Thus, the confirmation waiting timer is stopped, the link release is notified to the high-level module, and the communication ends.

[0281] <Control Started Side>

[0282] If the link release is possible, the side which received the control frame for requesting the link release continuously sends the response confirmation frame to the control frame “K” times. Then the control started side notifies the link release to the high-level module, and the communication ends.

[0283] (3) Frame Sync and RTF Measurement Method

[0284] When the initial sync/re-sync sequence starts, the control starting side sends the sync request. The control started side is in the state for waiting the sync request, and transmits the sync reception to the control starting side after receiving the frame. If the response is impossible for some reasons although the sync request is received, the sync refusal as well as the sync refusal reason display is transmitted. The sync frame is detected on condition that “SYNC coincident”, “FI confirmation” and “CRC no error” are satisfied. The sync sequence is started on condition that (a) data link start time, (b) ARQ reception frame continuous FCS error detection time, and (c) the sync frame reception time during transmission of the control frame or the data frame are satisfied. Further, if a terminal station apparatus can monitor the state of a mobile station (PS), it is possible to start the sync sequence when the information channel (TCH) is switched and the hand-off ends.

[0285] (3-1) Initial Sync Sequence

[0286] For the initial sync of the ARQ frame, the negotiation frame (including sync frame function) is used. FIG. 30 shows the ARQ sync sequence. The ARQ frame initial sync establishment method accords to the following.

[0287] <Step 1>

[0288] The control starting side sends the negotiation frame (negotiation classification: request, sync function existing, sync request) and also starts the sync reception waiting timer. Then “COMMON ORDER NUMBER” in the option area is incremented one by one from the negotiation frame (negotiation classification: request, sync function existing, sync request) sending start time. In the negotiation frame (negotiation classification: request, sync function existing, sync request), “SAME ORDER NUMBER” and “CONFIRMATION RESPONSE NUMBER” in the option area are fixed to “1”.

[0289] <Step 2>

[0290] If the control started side receives the negotiation frame (negotiation classification: request, sync function existing, sync request), it sends the negotiation frame (negotiation classification: reception, sync function existing, sync reception) and also starts the sync reception after-sending timer. Then “COMMON ORDER NUMBER” and “SAME ORDER NUMBER” in the option area are incremented one by one from the negotiation frame (negotiation classification: request, sync function existing, sync reception) sending start time. In the negotiation frame (negotiation classification: reception, sync function existing, sync reception), “COMMON ORDER NUMBER” in the option area added to the negotiation frame (negotiation classification: request, sync function existing, sync request) from the control starting side and initially received at the control started side is copied and written into “CONFIRMATION RESPONSE NUMBER” in the option area.

[0291] <Step 3>

[0292] If the control starting side receives the negotiation frame (negotiation classification: reception, sync function existing, sync reception), the ARQ sync is given, and the control starting side stops the sync reception waiting timer. At the same time, it is possible to measure the RTF, and the communication parameter is negotiated.

[0293] <Step 4>

[0294] If the control frame (request) from the partner is detected, the control started side considers that the sync is given, and thus stops the sync reception after-sending timer, whereby the communication parameter is negotiated.

[0295] <Step 5>

[0296] In case of time-out of the sync reception waiting timer or the sync reception after-sending timer, the ARQ sync establishment fails, and the high-level module is notified of the data link establishment failure.

[0297] <Step 6>

[0298] If competition of the data links occurs, the process from the partner starting side is preceded. Namely, if the sync request from the partner is received during the sync request transmission, transmission of own sync request is stopped, and the process to the sync request from the partner starting side is performed.

[0299] (3-2) Re-Sync Sequence

[0300] As described above, during the communication, (b) when the ARQ reception frame continuous FCS error detection is performed, (c) when the sync frame is received during the transmission of the control frame or the data frame, or when the information channel (TCH) is switched and the hand-off ends while the terminal station apparatus can monitor the state of the movable station (PS) by the terminal station apparatus, the re-sync is performed. The sync frame is used for the ARQ frame re-sync.

[0301] Initially, the control starting side establishes the ARQ sync according to the following.

[0302] <Step 1>

[0303] The control starting side sends the sync frame (sync request) and also starts the sync reception waiting timer to detect the sync frame (sync reception) from the partner. Then “COMMON ORDER NUMBER” is incremented one by one from the sync frame (sync request) sending start time. In the sync request, “SAME ORDER NUMBER” and “CONFIRMATION RESPONSE NUMBER” are fixed to “11”.

[0304] <Step 2>

[0305] If the control started side receives the sync frame (sync request), the ARQ sync is established, and the sync reception waiting timer is stopped. At the same time, it becomes possible to measure the RTF, and thus the ARQ parameter is negotiated.

[0306] <Step 3>

[0307] In case of time-out of the sync reception timer, the ARQ sync establishment fails, whereby the sync establishment failure is notified to the high-level module.

[0308] On the other hand, the control started side establishes the ARQ sync according to the following.

[0309] <Step 1>

[0310] As described above, (b) when the ARQ reception frame continuous FCS error detection is performed, and (c) when the sync frame is received during the transmission of the control frame or the data frame, the sync request waiting timer is started to wait the sync frame from the partner station.

[0311] <Step 2>

[0312] If the sync frame (sync request) is received from the partner station, the sync request waiting timer is stopped. At the same time, the sync reception after-sending timer is started, and the sync frame (sync reception) is sent. Then “COMMON ORDER NUMBER” and “SAME ORDER NUMBER” are respectively incremented one by one from the sync frame (sync reception) sending start time. Further, “COMMON ORDER NUMBER” added to the sync frame (sync request) from the control starting side and initially received at the control started side is copied and written into “CONFIRMATION RESPONSE NUMBER”.

[0313] <Step 3>

[0314] If the control frame (request) from the partner station is detected, it is considered that the sync can be given. Thus, the sync reception after-sending timer is stopped, and the ARQ parameter is negotiated.

[0315] <Step 4>

[0316] In case of time-out of each timer, the ARQ sync establishment fails, and the sync establishment failure is notified to the high-level module.

[0317] If both the stations operate as the control starting side, it is possible to occur the competition of the sync frame (sync request) even at the ARQ frame re-sync starting time. Even in this case, the process from the partner starting side is preceded. That is, if the sync request is received from the partner during the sync request transmission, the transfer of own sync request is stopped, and the process for the sync request from the partner starting side is performed.

[0318] (3-3) RTF Measurement Method

[0319] The RTF value is the parameter for defining an frame interval until the re-sending is performed. That is, a response delay time is measured every call connection, and the measured value is set as the RTF value. The RTF value is measured at the control starting side, and then notified to the control started side with the control frame after the sync is established. The control started side measures the RTF value according to the following.

[0320] <Step 1>

[0321] At the time when the sync reception from the control started side is received, following values are detected.

[0322] (α) “COMMON ORDER NUMBER” added to currently sent sync request/sync reception

[0323] (β) “SAME ORDER NUMBER” attached to the sync reception from the partner station

[0324] (γ) “CONFIRMATION RESPONSE NUMBER” attached to the sync reception from the partner station

[0325] <Step 2>

[0326] The RTF value is calculated and set by the following equation.

RTF={α+ 510−(β+γ)} mod 255+2+ N

[0327] In the equation, the constant N is assumed as “2” in this case.

[0328] <Step 3>

[0329] If “RTF−N≦2” and “60≦RTF−N”, the data link release sequence starts.

[0330] <Step 4>

[0331] The RTF value calculated (or measured) in the step 2 is notified to the control started side by the control frame.

[0332] (3-4) ARQ Frame Refusal Sequence

[0333] In the case where the sync request has been received, if the response is impossible for some reasons, the sync refusal (refusal reason) is set at “REASON DISPLAY” instead of the sync reception, and the set reason is continuously transmitted L times. In order to simplify the process of the ARQ sync process unit, the processes same as those in the sync reception are performed for “COMMON ORDER NUMBER”, “SAME ORDER NUMBER” and “CONFIRMATION RESPONSE NUMBER”. It is assumed that the value of “L” is “20”.

[0334] If the control starting side received such the sync refusal frame, it stops the sync request transmission and the sync reception waiting timer. Then the data link establishment failure is notified to the high-level module.

[0335] (4) Control Signal System

[0336] (4-1) Control Information Transfer System

[0337] The control information sent from the control starting side is “request” and “notification”. If “REQUEST” is permitted, “reception” is issued as the reception confirmation. On the other hand, if “request is not permitted, “refusal” is issued as the reception confirmation. Further, the reception confirmation “response” is corresponding to “notification”. The control information transfer system in this case is the system in which the control frame reception confirmation of the reception/response/refusal/continuous frame transmittable (hereinafter called as confirmation frame) from the control started side is expected as the response every time the request/notification control frame is sent from the control starting side.

[0338] If the control frame sending is requested, the control starting side preferentially sends the control frame even if there is the data to be sent. Then the control starting side repeatedly sends the control frame of the identical contents until the confirmation frame is received. In case of continuously sending the control frame, the control starting side waits the reception of the confirmation frame and then sends the next control frame.

[0339] In order to discriminate the control frames continuously sent, the sequence number is provided for the control information. Therefore, the control started side returns to the control starting side the sequence number attached to the control information sent from the control starting side, so that the control starting side can discriminate which control frame the confirmation frame corresponds to. The number of modulo of the sequence number at this time is assumed as “16”, and the sequence number is independent in end-to-end state. The initial value of the sequence number at the starting time is “0”.

[0340] The control starting side receives the confirmation frame and then sends the data frame if there is no control information to be continuously sent. The control started side can confirm that the confirmation frame has reached the partner, by receiving the control frame of the incremented sequence number or receiving the data frame. Until that time, the control started side continues to send the confirmation frame even if there is the data to be sent.

[0341] FIG. 31 shows an example of the above-described control frame transmission/reception sequence.

[0342] As shown in FIG. 31 , initially, the control starting side sends the request (0) (step S 1 ), and the control started side sends the reception (0) to the request (0) (step S 2 ).

[0343] Subsequently, the control starting side receives the reception (0) (step S 3 ) and thus sends the next request (1) (step S 4 ). If the control starting side receives the reception (1) for the request (1), it sends the data because there is no request to be sent (step S 5 ).

[0344] Subsequently, since the control started side can confirm that the reception (1) has been sent in the step S 5 , it sends the control frame of the request (0) to be transmitted (step S 6 ). Then the control starting side sends the reception (0) to the request (0) (step s 7 ).

[0345] If the control frame competition with the partner occurs, the control frame from the partner is preceded. That is, if the control frame “request” or notification” is received while own side is transmitting the control frame, the own side stops sending the control frame and performs the control process to the frame “request” or “notification”. Then the own side returns the confirmation frame.

[0346] If the ARQ re-sync process is started during the transfer of the control frame, the control frame is transferred after the ARQ re-sync is completed. In this case, the control information and the sequence number transmitted before the ARQ sync process are stored.

[0347] Further, if the competition of the control frame occurs during the continuous frame transmission, the same process as above is performed.

[0348] FIG. 32 shows an example of the sequence in the case where the ARQ re-sync process starts during the control frame transfer.

[0349] In FIG. 32 , the ARQ re-sync process starts when the control started side intends to send the reception (3) to the request (3). Therefore, the control started side interrupts the sending of the reception (3), and restarts such the sending after the ARQ re-sync process ends.

[0350] In this case, the “control information” may extend over the plural control frames. If so, the fact that the continuous frames exist is indicated by “continuous frame discrimination bit”. As the process to “request” (continuous frame existing), there are the following two cases.

[0351] In the first case, as shown in FIG. 33 , the control started side sends the response “continuous frame transmittable” to “request” (continuous frame existing), and collectively performs the processes after receiving all “request”. The control started side indicates the processed result (reception/refuse) to the final frame (no continuous frame).

[0352] In the second case, as shown in FIG. 34 , the control started side independently processes each “request”. When the control continues (continuous frame existing), if the control starting side receives “refuse” from the control started side, it ends the control. The control started side collectively performs the processes to “notification” (continuous frame existing) and sends the response “continuous frame transmittable” to “notification” (continuous frame existing).

[0353] To “reception”, the contents of the significant information of “request” are copied and returned. However, it is possible that the response is sent to “reception” even if the partial parameter is not permitted. Such a fact is shown as the reception result at the final octet of “reception”.

[0354] For example, FIG. 35 shows “version information” set by the communication parameters. This information can be negotiated. If the requested side (i.e., control started side) can not provide the protocol of the requested version, it returns the providable version to the requesting side (i.e., control starting side). If the communication is possible with the changed version, the requesting side (control starting side) continues the communication as it is. On the other hand, if the communication is impossible (i.e., requesting side having no protocol of changed version), the data link is released. If the requested side (control started side) can not permit the negotiation-impossible parameter, such the side sends “refusal”. In this “refusal”, all the fields of the corresponding parameter are set with “1” to clearly indicate the refused requested parameter.

[0355] The final octets in “request”, “notification”, “response” and “continuous frame transmittable” are all assumed as “1”.

[0356] The confirmation frame waiting timer is 10 seconds equally for the request and notification frames. In case of time-out of this timer, the data link is released. If the ARQ re-sync process is started during the control frame transfer, this timer is reset (i.e., once stopped and the started again).

[0357] Hereafter, if the control information contents in the control frame are added and thus the control information impossible to be recognized by the own station is received, the contents of this control information are not considered as the significant information and thus discarded. However, even if all the significant information are settable, the result of the reception is made partially settable. This process is the same as that for “REQUEST” (continuous frame existing). At the time when the control started side discriminates that there is no significant information in the continuous frame, it executes the process to the request.

[0358] (4-2) Communication Parameter Negotiation

[0359] In order to set the communication parameter usable on both the control starting side and the control started side, the parameter in “communication parameter setting” or “ARQ parameter setting” is transferred by the control frame, and subjected to end-to-end negotiation. If the negotiation fails, the data link is released because the connection is impossible. In the communication parameter setting, the negotiation possible parameters are “ARQ data transfer protocol version”, “ARQ control information transfer protocol version”, “measured RTF value”, “data compression system identifier”, “total number of codes (P 1 )”, “maximum character string length (P 2 )”, “frame length” and “maximum frame number”. On the other hand, in the ARQ parameter setting, the negotiation possible parameter is “measured RTF value”.

[0360] FIG. 36 shows an example of the sequence succeed in the communication parameter setting without changing the parameter.

[0361] If the negotiation competition occurs, the control starting side previously stores the parameters request by itself. After then, at the time when the communication parameter is received from the partner, the received parameter and the parameter sent to the partner by itself are compared with each other according to the negotiation rule, so as to select (or set) the low-level parameter. In FIG. 36 , the parameter of which level (protocol version 1) is lower than the requested level (protocol version 2) is set as a result of the negotiation, and the communication parameter setting ends.

[0362] (5) Data Frame Retransmission Control System

[0363] (5-1) Process at Data Transmission Side (FFI Determination Process)

[0364] For the error control in the data frame, an SR (selective repeat type) ARQ for retransmitting only the error frame is used. The flow control is absorbed by the ARQ data frame process unit.

[0365] If the continuous frame error is detected equal to or larger than the defined times, the ARQ re-sync process starts. Further, in order to effectively realize transmission number feedback type SR ARQ in the limited buffer, the last one byte of “user data area” in the data frame is used to manage the modulo. “FFI” represents frame numbers “1 to M”, and “FBI” represents request frame numbers “1 to M”.

[0366] (5-2) Process at Data Transmission Side

[0367] The increment is started from the currently requested frame (represented by “FBI”) and repeated maximumly up to the outstanding frame. However, if there is the data of M (maximum frame number) frames to be transmitted does not exist, only the frames in which the data exist are transmitted.

[0368] During the above repetition, the frame requested by “FBI” is transmitted. However, “FBI” in “RTF” is ignored. The RTF value is measured at the same time when the ARQ frame sync is established.

[0369] If there is no data to be sent, the frame in which “FFI=0” and “data length=0” is sent.

[0370] The outstanding frame is the frame which can be transmitted without waiting the transmission confirmation from the reception side, and the upper limit of this frame is called as the maximum outstanding frame. It is satisfied the relation that “the number of maximum outstanding frames (M)”=“the number of modulo−1”.

[0371] (5-3) Process at Data Reception Side (FBI Determination Process)

[0372] The error frame in “FCS” is discarded.

[0373] The oldest not-received frame number is written into the feedback information (FBI) as the request frame.

[0374] If there is the flow control request due to the DTE reception process delay, update of the request frame number is not performed. The contents of “FBI” are not changed until a buffer-full state is released, whereby the advance of the ARQ protocol is suppressed.

[0375] Among the reception data frames, the frame of “FFI=0” and the frame discriminated as the same frame by the reception comparison are discarded without “FBI”.

[0376] FIG. 37 shows an example of the case where only the error frame is sent again.

[0377] As shown in FIG. 37 , if the frame of which number is “FFI=4” at the data transmission side is not transferred due to a transfer path error, the data reception side continues to send the frame of which request frame number is “FBI=4” until the frame of which frame number is “FFI=4” is received. After “RTF” (response delay time) elapses, the frame of which frame number is “FFI=4” is transmitted again.

[0378] FIG. 38 shows an example of the case where the frame sending is repeated up to the maximum outstanding frame. In this example, the frame is represented by “frame (#modulo number, frame number).

[0379] If the frame (#1, 4) is the oldest frame of which transmission confirmation is not yet given, the transmission side sequentially sends the frames (#1, 5), (#1, 6), . . . , (#1, M), (#2, 1), (#2, 3), . . . . Then af