uPD72305 (LAP-D)

This LSI complies with ITU-T Recommendations I.430, I.440, and I.441, but does it comply also with ETS 300 012 and 125 (European standards)?
If it does not comply with ETS, is there any other part comply with?

The uPD72305 complies with CCITT Recommendations I.440 and 441 (FY1986 version).
The uPD98201 complies with CCITT Recommendation I.430 (FY1986 version).

However, ETS 300 012 and 125 (European standards) compliance was not a point we had in mind at the time of development.
Thus, whether these products comply with these European standards is not known.

We do not have products that comply with ETS 300 012 and 125 (European standards).

The User's Manual states that if the number of transactions with an empty layer 2 is 10H or lower, this is reported, but what exactly is this number of transactions?

The transactions in question are unprocessed communication tasks.
Since it is actually physically impossible for the communication processing states to be all stored in the internal memory of the uPD72305, the contents of the unprocessed tasks are temporarily stored in the work memory.

The capacity of this area is determined by the NTR parameter in the memory area setting command.

Normally, a value of 20H or higher is set to NTR and every time the number of unprocessed tasks increases, this area diminishes, and when the remaining free area becomes 10H or lower, the Layer 2 Transaction Busy status occurs.

When does Layer 2 Transaction Busy occur?

This state occurs when unprocessed tasks that exceed the processing capability of LAP-D F/W in the uPD72305 (processing tasks such as RR transmission or reception processing of each link, command execution, and status report processing) occur and NTR becomes 10H or lower.

Is there a way to intentionally cause the Layer 2 Transaction Busy state?

Make the number of NTR 20H or lower (however, there is no meaning in making the number of NTR 10H or lower).

Moreover, the Layer 2 Transaction Busy state can be caused by creating an environment in which unprocessed communication tasks can easily occur, using for example the method of stopping RR transmission from the remote station and increasing unprocessed transmission frame processing, the method of lowering the system CLK frequency in order to lower the F/W processing capability itself, the method of increasing the number of logical links, or the method of reducing parameters such as T200 and T203 (However, if T200 and T203 are set to 0, the timeout processing itself does not occur, so 0 is not a workable value).

This question concerns the local station busy generation command.
Is the following recognition correct?

The local station busy generation command can be transmitted from the host processor only.
(The LAPD controller does not autonomously transmit this command.)

Yes, that is correct.

This question concerns the local station busy generation command.
Is the following recognition correct?
The local station busy generation command is valid only for the specified SAPI and CES (TEI) links.
RNR is not transmitted to an unspecified CES in the same SAPI.

Yes, that is correct.

Following transmission of the local station busy generation command, is RNR with F = 0 transmitted regardless of whether or not there is a command signal from the remote station?

RNR is transmitted only once following command output.
Thereafter, the receive command is analyzed and RNR is transmitted if required.

What happens when the host processor goes down (runaway, etc.) during communication when at least 1 link has been set and communication with the LAPD controller becomes impossible?

1) Command frame reception  

When there is availability in status table/receive buffer address table

 

When there is no availability in status table/receive buffer address table

2) Response frame reception  

When there is availability in status table/receive buffer address table

 

When there is no availability in status table/receive buffer address table

3) Processing for commands remaining in command table  

Is status report possible? (when there is/is not status table availability)

While there are available resources, no matter what happens to the higher host, normal operation is performed as long as there are available resources. And when resource availability stops, in the case of the command table, command execution stops.

In the case of the status table, internal status discarding is performed.
And in the case of I frame reception, I frame discarding is performed.

I would like to confirm a few things regarding the TWAT command of LAP-B (uPD72305).
The User's Manual states that this command is used to set the Layer 1 monitoring operation, in which the timer stops when a transmission is completed.

I believe that when timeout occurs, this indicates that transmission did not end normally.
Is it correct to assume, that in addition to layer 1 synchronization not having been established, the causes can also be the following?
 1) Failure of layer 1 control LSI
 2) Failure of LAPD itself

Is it correct to assume that when timeout occurs, it is not possible to determine whether the timeout was caused by circuit disturbance or by failure?

As you say, it is not possible to determine the cause of the failure.
With regard to the timer function, the timer starts when sending frames and stops when a transmission is completed in the Layer 1 monitoring operation state.

If, following the start of frame transmission, timeout occurs for some reason before frame transmission ends, the "transmission timeout" status is reported.

Although the state you describe is included among the factors that cause such a timeout, it does not by itself cause timeout.
For example, even if the layer 1 control LSI has failed, there are also cases when TxRDY is kept in the Low level as is, depending on the nature of the failure.

There is no definition that explains failures of LAP-D itself.
Given this situation, when this status occurs, the cause(s) must be analyzed in the upper layer through loopback test, layer 1 control LSI status read, etc.