top - download
⟦ec8efb4e6⟧ Wang Wps File
Length: 83432 (0x145e8)
Types: Wang Wps File
Notes: FIX/1000/PSP/0038
Names: »3899A «
Derivation
└─⟦a0a781934⟧ Bits:30006149 8" Wang WCS floppy, CR 0333A
└─ ⟦this⟧ »3899A «
WangText
"…00……00……00……00…<…02……00……00…<
;…0c…;
; ;…05…;…06…;…07…:…08…:…0c…:…0d…:…0e…:…06…9…0e…9…06…8…0c…8 7…08…7…09…7…0a…7…01…7…07…6…0c…6 6…05…5…0d…5 4…0c…4…01…4…07…3…0f…3…00…3…07…2…0c…2…0d…2…0e…2…0f…2…86…1
…02… …02… …02…
3899A/AML…02…FIX/1000/PSP/0038
…02… LU/850529…02……02…
FIKS SYSTEM SPECIFICATION
…02…CAH/830802…02… FK7809…0f…
5 F̲I̲K̲S̲ ̲T̲D̲X̲-̲S̲Y̲S̲T̲E̲M̲
The FIKS TDX-system may be understood as a front-end
system for the host computer. The system consists
of a number of micro-processors, taking care of all
the low level activities such as character collection
from terminals and communication lines, character conversion
(ITA 5 to ITA 2 and vice versa), flow control and communication
line control. These tasks are all quite simple but
must be performed very frequently and for a number
of devices. Thus the load on the host computer would
be considerable if these tasks were not left for the
front-end micro-processors. The TDX-system ensures
that the host computer only need to consider message
packets and commands.
Another function supported by the TDX-system is the
data-user traffic. The data-user system is used for
transparent data transfer from one node to another
In case of error on the communication line an automatic
switch is made to an alternative route. The whole
data-user system in FIKS is working without the use
of the host computer, data are passed from micro-processor
to micro-processor, directly via the TDX-bus. The
only task of the host computer, with respect to the
data-user system, is that of initialization and control/supervision.
A typical layout of a FIKS TDX-system is shown in Figure
5-1. The RED TDX-bus handles unencrypted information,
the BLACK TDX-bus only handles encrypted information.
The LTUX-TELE and LTUX-VDU assembles terminal input
to packets of maximum 69 characters and transfers these
to the active CR8O branch through the corresponding
RED HOST I/F. Only one branch must be active at a
time. Output for the terminals (messages and prompts)
are forwarded as packets to the LTUX, passing the RED
HOST I/F. The LTUX outputs the characters one by one.
When a message has to be transferred to a neighbour
node it is first delivered to the LTUX-CRYPTO/RED (through
the RED HOST I/F). This LTUX controls the encryption
of the message in the BID 1000 unit. The LTUX-CRYPTO/BLACK
forwards the encrypted message to the LTUX-TRUNK connecting
to the specified neighbour node. The LTUX-TRUNK then
transmit the message.
The BLACK HOST I/F is not used for any kind of message
transfer. It is used for the initialization of the
BLACK TDX-bus and for the status monitoring of the
devices on the black bus.
The optical reciever/transmitter shown is used to prevent
electromagnetic radiation when carrying the BLACK TDX-bus
outside the screened cage. The optical system is dualized
to improve system availability.
Two TDX-controllers are connected to each TDX-bus.
The watchdog processor determines which one to be
active. In case of error an automatic switch is made
to the stand-by controller.
The TDX-controllers receive their clock-signals from
two TDX-frequency units. The TDX-system clock is generated
from these clock-inputs. In the LTUX-TRUNK and LTUX-DATA-USER
the TDX-system clock is used as clock for input and
output of data. The TDX-frequency unit is a rubidium
controlled frequency standard providing an extremely
stable clock for the system (long term stability =
1 * 10…0e…-11…0f…/month). This stability is necessary to ensure
that data clocked in at one node are clocked out at
the same rate at another node, otherwise data will
accumulate or lack in the system.
An overview of the LTUX-types used in FIKS is shown
in Figure 5-2. Note that the LTUX-AUDIO and the LTUX-DISPLAY
is implemented as one LTUX, called LTUX-AUDIO/DISPLAY.
This LTUX is only used at the system control center
(SCC). The LTUX-TRANS is used to connect the system
control center and the collocated node/mede.
In Figure 5-3 is shown the TDX-system of an SCC, in
Figure 5-4 is shown the TDX-system of a NODE/MEDE.
Figure 5-1…01…FIKS TDX-System
Figure 5-2…01…FIKS LTUX-Types - Cross Reference Table
Figure 5-3…01…FIKS SCC Processor
Figure 5-4…01…FIKS Dual Node/Mede Processor
Figure 5-4…01…FIKS Site 6 Node B/Mede B6
5.1 I̲N̲T̲E̲R̲A̲C̲T̲I̲V̲E̲ ̲T̲E̲R̲M̲I̲N̲A̲L̲ ̲S̲U̲P̲P̲O̲R̲T̲
Two LTUX…09…s are defined in this group: LTUX-VDU and
LTUX-TELE. The LTUX…09…s are connected to the RED TDX-bus
and information is transferred between the LTUX and
the red HOST I/F. The LTUX…09…s are used to off-load the
CR80 host computer for the character - by - character
processing. The data formats used between the LTUX…09…s
and the CR80 are shown in Figure 5.1-1.
5.1.1 L̲T̲U̲X̲-̲V̲D̲U̲
The LTUX-VDU supports two terminals NEWBURY model 7009
with special firmware developped for FIKS. A receive
only printer is connected to each VDU as a slave printer.
The LTUX controls the data transfer and conduct output
data for upper screen, lower screen or ROP, depending
on which TDX subdevice no. information was received
at. The VDUs are connected to back-panel JACK 1 and
JACK 2.
Table 5.1.1-1 shows the usage of the different TDX-subdevices.
Figure 5.1-1…01…FIKS Data Formats
Figure 5.1-1…01…FIKS Data Formats
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲
^ TDX ^
^
^̲ ̲S̲u̲b̲d̲e̲v̲.̲ ̲N̲o̲.̲ ̲ ̲ ̲^̲ ̲ ̲ ̲D̲e̲s̲t̲i̲n̲a̲t̲i̲o̲n̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲^̲
^ ^
^
^ 2 ^ JACK 1: control
^
^ 3 ^ upper screen
^
^ 4 ^ lower screen
^
^ 5 ^ ROP
^
^̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲^̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲^̲
^ ^
^
^ 6 ^ JACK 2: control
^
^ 7 ^ upper screen
^
^ 8 ^ lower screen
^
^ 9 ^ ROP
^
^̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲^̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲^̲
Table 5.1.1-1…01…TDX-Subdevice Usage, LTUX-VDU
The subdevice used for control is only used for input
to the CR80. The subdevice is used for the function
keys 'next page', 'end of message' and 'cancel'.
Baud rate is set up during initialization (boot or
switch over). 300, 600, 1200 and 2400 bps may be used.
Jack 1 and Jack 2 must be assigned the same band rate.
Typical baud rate used is 1200 bps.
5.1.2 L̲T̲U̲X̲-̲T̲E̲L̲E̲
The LTUX-TELE supports up to 4 teletype terminals.
The LTUX converts outgoing data from ITA 5 to ITA
2 alphabet, and ingoing data from ITA 2 to ITA 5.
Only two subdevices are used per terminal, one for
inbound and outbound data and one for control information
(inbound only). The control informations are:
R: Rubout
C: Cancel
N: End of message
Subdevice usage is shown in table 5.1.2-1.
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲
^ TDX
^
^̲ ̲S̲u̲b̲d̲e̲v̲.̲ ̲N̲o̲.̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲D̲e̲s̲t̲i̲n̲a̲t̲i̲o̲n̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲^̲
^
^
^ 2 JACK 1 control in
^
^ 3 text in and out
^
^̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲^̲
^
^
^ 4 JACK 2 control in
^
^ 5 text in and out
^
^̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲^̲
^
^
^ 6 JACK 3 control in
^
^ 7 text in and out
^
^̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲^̲
^
^
^ 8 JACK 4 control in
^
^ 9 text in and out
^
^̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲^̲
Table 5.1.2-1…01…TDX-Subdevice Usage, LTUX-TELE
Baud rate is set up during initialization (boot and
switch over). Jack 1 and Jack 2 must be assigned the
same baud rate and so must Jack 3 and Jack 4. 50,
75, 100, 110, 150, 165, 200 and 300 bps. may be used
depending on actual terminal type.
5.2 M̲E̲S̲S̲A̲G̲E̲ ̲C̲R̲Y̲P̲T̲O̲ ̲A̲N̲D̲ ̲T̲R̲A̲N̲S̲F̲E̲R̲ ̲S̲U̲B̲S̲Y̲S̲T̲E̲M̲
The basic purpose of this subsystem is to be able to
share one CRYPTO unit between a number of trunks (up
to 7). The advantage of this is mainly economical
since the BID 1000 is very expensive. The disadvantage
is that a malfunctionating BID 1000 will disturb all
trunks connected to the node. To meet this problem
the system is configured with a stand-by unit which
may be switched in on-line. Totally in FIKS 16 BID
1000 units will be needed instead of 36 (2 per trunk).
Another feature in the subsystem is the X25.2 protocol
implemented in the LTUX-CRYPTO/RED. This supports
the NSS with a virtually error free transmission line.
To get an overview of the protocols in the subsystem,
please refer to Figure 5.2-1.
A short description of the protocols will be given
below.
- X25 level 4. Implemented as specified in ISO…09…s
OSI model. Controls the message routing, split
messages in packets of 512 bytes and assemble incomming
packets to messages. For details please refer
to NSS product specification (FIX/1154/PSP/0107).
- X25 level 3. Implemented as specified in ISO…09…s
OSI model. Controls the transmission of packets
and check the packet sequence numbers. Flow control
features are implemented. For details please refer
to NSS product specification (FIX/1154/PSP/0107).
- DMA. Direct memory access transfer via CR80 main
bus from CR80 RAM to RED HOST I/F and vice versa.
- TDX (red). CR standard TDX-protocol. Message
packets are transferred between RED HOST I/F and
LTUX-CRYPTO/RED, subdevice 3.
- X25 level 2. Supports an error free transmission
line for the above protocol levels. Retransmission
is tried twice before giving up. Incomming packets
are checked by a CRC-16 polynomia.
- CRYPTO multiplex. Half-duplex protocol multiplexing
1-7 channels through the BID 1000 CRYPTO unit.
Each trunk has its own channel no. connecting
in the black LTUX to the TDX-subdevice no. of the
corresponding logical line on the black TDX-bus.
- TDX (black). Used to connect the LTUX-TRUNKS with
the LTUX-CRYPTO/BLACK. One logical line is defined
per trunk. At the LTUX-TRUNK, subdevice no. is
3, at the LTUX-CRYPTO/BLACK each trunk has its
own subdevice no. (3 + CRYPTO channel no.).
- Low delay byte multiplex protocol. Multiplexes
message traffic and up to 15 data user channels
on the same trunk. Error detection and correction
(EDC) features are implemented. Data users are
allowed to use 6000 bps. Excess bandwidth are
used for message traffic.
To illustrate the message transfer a message packet
will now be followed from NSS. Figures 5.2-1 and 5.2-2
illustrate the principles.
When the packet handler receives a packet from the
transport station the trunk-ID of the wanted trunk
is added together with an X25.3 header:
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲
^̲ ̲F̲M̲ ̲^̲ ̲T̲O̲ ̲^̲ ̲N̲O̲ ̲^̲ ̲ ̲ ̲^̲ ̲ ̲ ̲^̲ ̲ ̲ ̲^̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲^̲
TRUNK-ID X25.3 header max 512 data bytes
The NSS uses an init-append operation to transmit packet
to LTUX-CRYPTO/RED, subdevice 3.
The LTUX-CRYPTO/RED converts the trunk-ID to a CRYPTO
channel no., by use of the message CRYPTO system conversion
table. This table is loaded to the CRYPTO-LTUX…08…s during
initialization. The packet is extended with X25.2
information (1 byte) and is queued for transmission
on actual channel.
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲
^̲ ̲ ̲ ̲^̲ ̲ ̲ ̲^̲ ̲ ̲ ̲^̲ ̲ ̲ ̲^̲ ̲ ̲ ̲^̲ ̲ ̲ ̲^̲ ̲ ̲ ̲^̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲^̲
X25.2 Packet received from NSS
control
When the actual channel has turn the packet is transmitted.
A number (8-12) of sync. bytes (#7E) are inserted
in front of packet to ensure proper synchronization
when packet is received in the remote LTUX-CRYPTO /RED.
Too, CRC-16 bytes and end of block (#7F) are added
to the end. Finally bitstuffing is added during transmission.
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲
^̲ ̲ ̲ ̲ ̲ ̲ ^̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲^̲ ̲ ̲ ̲ ̲^̲ ̲ ̲ ̲ ̲^̲
̲ ̲ ̲ ̲^̲
8-12 sync. Packet with bit- CRC-16 End
bytes stuffing (With bit of
stuffing)
block
flag
When the packet passes through the BID 1000 CRYPTO
a CRYPTO sync. pattern and a key select code is added,
totally 280 bits = 70 bytes.
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲
^̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲^̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲^̲
CRYPTO SYNC. & Packet with sync. bytes, X25,2 and
key select. X25.3 control, trunk-ID, CRC-16 bit
stuffing and end of block flag.
Total packet length will now be up to 719 bytes (worst
case bit stuffing).
The LTUX-CRYPTO/BLACK uses the CRYPTO CHANNEL no. to
determine the TDX-subdevice to use for transmission
on the BLACK TDX-bus (subdevice: = CRYPTO channel +
3). The LTUX-BLACK cannot read the TRUNK-ID from the
bit-stuffed, encrypted message. The packet is forwarded
for transmission on the black TDX-bus.
During initialization of system (file LCFBN02, ref.
section 5.5) logical lines are defined between the
subdevices of the LTUX-CRYPTO/BLACK and the corresponding
LTUX-TRUNKs. This guarantees a one - to - one connection
between CRYPTO channel no. and used trunk-line.
In the LTUX-TRUNK the message is transmitted by the
low delay byte multiplex protocol to the remote LTUX-TRUNK.
From the LTUX-TRUNK (remote) the message is now transferred
to the LTUX-CRYPTO/BLACK, using the BLACK TDX-bus.
In the BLACK LTUX the message is queued for transmission
to the RED LTUX using the multiplex protocol. However,
when transmitting from BLACK to RED there is no need
for waiting for the actual channel number to occur
since the LTUX-CRYPTO/RED can determine the origin
TRUNK-ID directly from the packet header (packet is
now decrypted). If CRC-16 check and X25.2 protocol
byte is accepted packet is forwarded for the NSS via
the RED TDX-bus. X25.2 control byte and CRC-bytes
are stripped off. A packet acknowledge (level 2) is
returned for the originator (LTUX-CRYPTO/RED).
…01…Figure 5.2-1…01…Protocols In Message
CRYPTO And Transfer System
Figure 5.2-2…01…Message CYRPTO And…01…Transfer System
5.3 D̲A̲T̲A̲ ̲U̲S̲E̲R̲ ̲S̲W̲I̲T̲C̲H̲ ̲S̲U̲B̲S̲Y̲S̲T̲E̲M̲
This section describes the system design of the Black
TDX System in FIKS, i.e. the interfaces to Host computers,
interfaces to the black LTUXes for data users, interfaces
to trunk LTUXes and interface to the DOLCE LTUX.
This section also contains a description of the system
of data user LTUXes and Trunk LTUXes which make up
the data switching elements of the FIKS Node, the Data
User Switch System. This covers means for selecting
data user routes, primary and secondary, the data user
traffic on the TDX busses, the delays on data user
traffic.
The realization of multipoint connections is covered
for the TOSCA RING data user. For FLYPEP the Computer
Access verification mechanism i described. The muliplexing
of data users and message traffic on the internodal
trunks is described in this section as well as the
internodal communication line protocol.
Data user route selection is described both for trunk
LTUXes and Data User LTUXes.
The Data User LTUXes are categorized as Synchronous,
Asynchronous, FLYPEP-terminal I/F, and FLYPEP computer
I/F.
The Black TDX Bus System in each FIKS Node includes
a site dependent Data Switch System Configuration.
The purpose of this System is to receive data from
data User LTUXes, or from internodal trunk LTUXes,
and transmit these data to other data User LTUXes via
internodal trunk LTUXes in accordance with data interchange
strategy loaded into the LTUXes involved. Each LTUX
must know the part of the strategy which is relevant
for the data is carries.
5.3.1 C̲o̲m̲p̲o̲n̲e̲n̲t̲s̲
Data Switch System is present in each of the 8 possible
nodes. Presently 18 trunk lines interconnect these
nodes. It is required that each node shall be able
to interconnect up to 7 internodal trunks.
The worst case Data Switch System is that in Node K
as per Requirements Specification, issue 5. The configuration
of Node K is being considered dimensioning with respect
to TDX Bus load and complexity.
The components of the Data Switch System are: The
trunk LTUXes (LTUX-TRUNK and LTUX-NPDN), and the data
user LTUXes (LTUX-SYNC, LTUX-ASYNC, LTUX-FLYPEP/TERM,
and LTUX-FLYPEP/COMP).
- T̲r̲u̲n̲k̲ ̲L̲T̲U̲X̲
Overview of LTUX-TRUNK and LTUX-NPDN functions:
Multiplexing of data user and message traffic;
communication of data user traffic to other trunk
LTUXes and other data user LTUX. Trunk Failure
reporting to Host computer and to connected data
users.
The trunk LTUXes are implemented on LTUX-M hardware.
- D̲a̲t̲a̲ ̲U̲s̲e̲r̲ ̲L̲T̲U̲X̲
Overview of Data User LTUX functions.
Receive and transmit data on data user communication
line as well ad TDX bus. Recognize data user activation/deactivation
on comline interface and report to connected trunk
and/or data user LTUX.
The data user LTUXes are of the LTUX-S hardware
type.
5.3.2 D̲a̲t̲a̲ ̲U̲s̲e̲r̲ ̲R̲o̲u̲t̲e̲s̲
The Data User Routes are determined by the following
limiting factors, summarized from the FIKS Requirements
Specification.
There shall be a set of normal, primary and secondary
routes for the FIKS data users. Further it shall be
possible to load to other route configurations, named
the alternate 1 and alternate 2 configurations.
The routes shall be selected by AMC in accordance with
the following rules from the Requirements Specification:
- Up to 15 data routes may be assigned to an internodal
trunk.
- Up to 6000 bps may be in operation at any one time.
- LINK one and TOSCA Ring data routes must pass no
more than one intermediate node.
- No data route with a totally allowed delay of
500 ms must pass more than two intermediate trunks.
- No data route whatsoever shall pass through more
than 4 intermediate trunks.
5.3.3…02…D̲a̲t̲a̲ ̲U̲s̲e̲r̲ ̲P̲r̲o̲t̲o̲c̲o̲l̲s̲
To manage the transfer of data user traffic, including
the enabling, disabling and synchronization of discontinuous
data users, 6 protocols arranged i 4 levels, plus 2
electrical levels, have been identified. They are:
Acronym Data
switch
level
1 Data User Plug Protocol DUP level
5
2 Data User Routing Protocol DUR level
4
3 Data User Multiplex Protocol DUM level
3
4 Data Transfer on TDX TDX level
2
5 Electrical TDX bus interface TDE level
1
6 Low Delay Multiplex Protocol LDM level
3
7 Low Delay Block Protocol LDB level
2
8 Trunk Electrical level V V24/V28 level
1
9 Trunk Electrical level X X21/V10 level
1
As seen there are several protocols which are located
on the same protocol level, e.g. all electrical interfaces;
the TDX transfer protocol (4) and the Trunk line protocol
(7); the Data User Multiplex protocol (3) and the
Low Delay Byte Multiplex protocol (6).
The different protocols on the same levels are used
in different places, e.g. the electrical interfaces.
The TDX multiplex protocol (3) is mapped into the
LDM protocol (6) within the trunk LTUX. The reason
for having both protocols is that the first (3) is
very simple to handle since it can assume errorfree
transmission via the TDX Bus, while the other, the
LDM is more efficient, and necessary on the internodal
trunk lines, where there are specific requirements
as to line efficiency and where errorfree transmission
is not supported by any lower protocol layer. In Figure
5.3.3 is shown how the protocol levels are distributed
in the FIKS Data User Network.
The protocol levels 6 and 7 named LDM and LDB are named
the Low Delay Byte Multiplex Protocol, when considered
as a single unit (LDBM). This combined protocol is
referred to in later sections.
Figure 5.3.3-1…01…FIKS DATA USERS…01…PROTOCOL LEVELS AND LOCATIONS
D̲a̲t̲a̲ ̲U̲s̲e̲r̲ ̲P̲l̲u̲g̲ ̲P̲r̲o̲t̲o̲c̲o̲l̲ (DUP): This protocol is the
highest level of control of the data user traffic.
It optionally includes the controls necessary to start
and stop discontinuous and Flypep data streams. Special
synchronization means are included for set up of data
user connections, which require small delay variation
in the link set up (LINK1).
The DUP Protocol does not recognize but one connection
through the network, either working or not (the primary
and secondary connections for data users are handled
by the next lower level, the DUR protocol.
The DUP Protocol and the next lower protocol the Data
User Routing Protocol uses a common block format for
representation of the protocol elements, named the
High Level Protocol Format, HLP.
D̲a̲t̲a̲ ̲U̲s̲e̲r̲ ̲R̲o̲u̲t̲i̲n̲g̲ ̲P̲r̲o̲t̲o̲c̲o̲l̲ (DUR): This protocol provides
for the DUP, a connection to the trunk LTUX which is
part of the primary or the alternate data user connection,
respectively. The DUR contains and maintains information
regarding the primary and alternate connection status.
The DUR is responsible for reporting to the Host computer,
i.e. the CR80, any required status report; also, the
DUR shall be able to receive from the Host computer
commands to update the data user connection…09…s status
and to update if data routing tables (the Data Routing
Table (DRT) specifies where the primary and alternate
data connections go.
D̲a̲t̲a̲ ̲U̲s̲e̲r̲ ̲M̲u̲l̲t̲i̲p̲l̲e̲x̲ ̲P̲r̲o̲t̲o̲c̲o̲l̲ (DUM): This protocol
provides multiplexing of up to 16 routes each of which
can transfer up to 16 different types of information
blocks. This DUM protocol is supported by the TDX
bus connection protocol, which is implemented as system
firmware in the LTUXes so that the TDX Bus Protocol
is the link level protocol while the DUM Bus protocol
corresponds to Packet level protocol in the sense that
it multiplexes data strings from independent sources
onto the same standard connection.
D̲a̲t̲a̲ ̲U̲s̲e̲r̲ ̲T̲D̲X̲ ̲P̲r̲o̲t̲o̲c̲o̲l̲ (TDX): This protocol is the
standard TDX bus protocol for data and control transfer
between LTUX devices via the TDX serial bus. One or
more DUR-protocol blocks are enveloped by each TDX
frame.
L̲o̲w̲ ̲D̲e̲l̲a̲y̲ ̲M̲u̲l̲t̲i̲p̲l̲e̲x̲ ̲P̲r̲o̲t̲o̲c̲o̲l̲ (LDM): This protocol
is used on the internodal trunks lines to distinguish
between up to 15 different independent data user- and
one message route. The LDM protocol gives a denser
packing of information than does the HLP Format. The
Low Delay Multiplex Protocol is the higher of the two
levels included in the Low Delay Byte Multiplex protocol.
This protocol presents data transfer and control transfer
requests and expects a transfer facility to be provided.
L̲o̲w̲ ̲D̲e̲l̲a̲y̲ ̲B̲l̲o̲c̲k̲ ̲P̲r̲o̲t̲o̲c̲o̲l̲ (LDB): This protocol is the
lower of two levels included in the LDBM protocol.
It takes care of the blocking of trunk traffic into
fixed length blocks.
This protocol part also takes care of the channel change
procedures, the purpose of which are to provide agreement
on, which data users are to be included or data users
currently in operation are to be deleted from an internodal
trunk.
T̲r̲u̲n̲k̲ ̲E̲l̲e̲c̲t̲r̲i̲c̲a̲l̲ ̲P̲r̲o̲t̲o̲c̲o̲l̲s̲ (TEP): There are two electrical
level protocols specified for the FIKS trunk LTUXes,
V24/V28 and X21. The first is used on the leased trunk
connection which constitutes the normally used network
connections. The latter, the X21 interface, is used
on LTUXes which substitute normal trunk connections
by callups via the NPDN.
5.3.4 D̲e̲d̲i̲c̲a̲t̲e̲d̲ ̲F̲I̲K̲S̲ ̲p̲r̲o̲t̲o̲c̲o̲l̲s̲
Several data- and control reprensentation formats are
used for data user traffic in the FIKS network. Of
these, two are of special interest, inasmuch they are
defined for the sole purpose of handling the FIKS data
users with their special requirements.
The first is the H̲i̲g̲h̲ ̲L̲e̲v̲e̲l̲ ̲P̲r̲o̲t̲o̲c̲o̲l̲ ̲F̲o̲r̲m̲a̲t̲. This
is employed by the Data User Protocol levels 4 and
5. The other is the LDBM Format, used on the internodal
trunks for multiplexing of data and control in an efficient
manner on the trunk lines.
The remaining representations are the TDX packet and
frame formats used on level 2; and the HDLC format
used on X25 level 2. Descriptions of these representations
can be found elsewhere and shall not be repeated here.
H̲i̲g̲h̲ ̲L̲e̲v̲e̲l̲ ̲P̲r̲o̲t̲o̲c̲o̲l̲ ̲
A blocked representation of data and control information
is employed. A block comprises a header byte followed
by a number of data- or control bytes. Each Block
contains data or control belonging to a single data
user. The number of bytes following is a function
of the block type, specified in the header, and the
data rate of the data user.
The header byte includes a subchannel code and a format
code. The subchannel code specifies within a TDX connection
an independent datastream, of which up to 16 may be
multiplexed inside a TDX connection. The format code,
also contained in the header byte, specifies the type
of the block. There may also be up to 16 different
block types, see the block type lists overleaf.
The Data User Plug (DUP) protocol, level 5, and the
Data User Routing Protocol, level 4, map this common
set of HLP block types into 2 different event sets,
since the protocol put emphasis on different functions.
L̲D̲M̲ ̲F̲o̲r̲m̲a̲t̲
The Low Delay Multiplex Format enables a number of
data users to have independent traffic flowing simultaneously
on the same trunk line. For efficiency minimum overhead
information is being used in this format which is used
on the communication lines. The format assumes that
it works with a predefined multiplex scheme, i.e. the
position of the current data users within a multiplex
block is predefined and known in both ends of the communication
line.
D̲a̲t̲a̲ ̲R̲e̲p̲r̲e̲s̲e̲n̲t̲a̲t̲i̲o̲n̲ ̲C̲o̲n̲v̲e̲r̲s̲i̲o̲n̲
Conversion from the HLP Format to the LDB-Format and
vice versa takes place in the trunk LTUXes since they
are the devices which are using both representations.
T̲h̲e̲ ̲d̲a̲t̲a̲ ̲b̲l̲o̲c̲k̲s̲ of implicit …0e…*…0f… length in the HLP representation
are broken up into data byte sequences of (another)
implicit …0e…*…0f… length. The data byte sequences are then
multiplexed with, i.e. grouped together with, sequences
of bytes from other data users, in an LD-block. When
going from the trunk LTUX and to the TDX bus the opposite
conversion takes place.
* implicit here means: a function of the data rate
5.3.5 D̲a̲t̲a̲ ̲F̲l̲o̲w̲ ̲t̲h̲r̲o̲u̲g̲h̲ ̲t̲h̲e̲ ̲P̲r̲o̲t̲o̲c̲o̲l̲s̲
In this section is described how data and control for
a data user route is passed through the different protocols
in the FIKS network.
First consider a block of control information which
has been generated in a Data User LTUX at a, see Figure
above, and which is bound for f, the destination data
user LTUX. This control block is formatted according
to the HLP format.
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲
^ FOR ^ USER ^ INFORMATION
^
^̲ ̲M̲A̲T̲ ̲ ̲ ̲^̲ ̲C̲O̲D̲E̲ ̲ ̲^̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲^̲
Header
The block is passed to the routing protocol which determines
the destination queue for this block, out of the two
possible queues, the primary and the secondary. The
block is packed into a TDX protocol frame, either alone
or together with other blocks passing the same queue.
By means of the TDX protocol the block is transferred
to the trunk LTUX (b). Here the control block will
be included in the next free LD Block, i.e. the next
LD Block which is not occupied by other control information,
and eventually passed to trunk. c. Finally the control
block ends up in the data user LTUX f where the information
is interpreted and as positive acknowledgement returned
to the originator.
The header information is processed, i.e. read and
changed for each LTUX it passes: The User code is
changed. The Format code is not. The User is local
and meaningful only between one pair of LTUXes. This
requires that where the block is passing from one LTUX
pair to another, this representation must be changed.
Each LTUX, hence, must contain conversion information
between the user codes used for the same data user
connection on adjacent LTUX-LTUX pairs.
Secondly consider a block of data which has been generated
in a Data User LTUX, at point a and which is bound
for point f, the destination data user LTUX. This
data block is formatted as the control block shown
above. The block is passed through the network without
error correction. However, initially the data user
route that it passes has been checked out - trunk by
trunk before the data were allowed to pass it.
Figure 5.3.5 shows the formats involved in passing
data and control from a TDX frame to an internodal
trunk and vice versa. The Up most TDX Bus Frame may
contain information from several data users passing
between a certain pair of LTUXes. Both data and control
may be passed through the same TDX frame. The DUM
protocol recognizes and separates the data for different
data routes. The separated data are then packed into
fixed length LD-Blocks on the internodal trunks, shown
lowest.
The blocks sent on the internodal trunks are sent at
regular intervals so that bit synchronism is maintained
continuously. In order to compensate for clock frequency
differences between the communication line clock for
the trunks and the highly stable clocks provided for
the synchronous data users, the gross utilization of
each internodal trunk shall be a few % less than the
totally available bandwidth obtained by adjusting the
utilization of the trunk by sending dummy control frames
in cases of vacancy in the trunk bandwidth.
Figure 5.3.5-1…01…FIKS Data Users Data & Control Representation…01…Trunk LTUX
Asynchronous data users which neither have stable clocks
nor exhibit continuous operation, once started, shall
operate with a blocked format. Each block shall consist
of a header byte followed by a fixed number of information
bytes. The header byte shall contain forwardly error
corrected information regarding the contents of the
associated data information.
The following data user groups need special attention
since they are dimensioning factors in the FIKS TDX
design:
L̲I̲N̲K̲ ̲1̲
Link 1 is a synchronous point-to-point data user.
This user has been dimensioning for the set up delay
variation. +/- 200 ms is required.
T̲O̲S̲C̲A̲ ̲R̲i̲n̲g̲
TOSCA Ring Conference network is a synchronous data
user. The conference network is connected as point-to-point
connections between any possible pair of TOSCA sites
of which there are four. This is due to the delay
requirements on this data user (1.5 s round trip).
I̲n̲t̲e̲l̲ ̲6̲
Intel 6 is a synchronous point-to-point data user.
It is dimensioning with respect to total delays of
500 ms since it is the only data user with three hops.
5.3.6 M̲e̲s̲s̲a̲g̲e̲ ̲T̲r̲a̲f̲f̲i̲c̲ ̲o̲n̲ ̲T̲r̲u̲n̲k̲s̲
Message traffic is passed directly to the trunk LTUXes
from the LTUX-CRYPTO/BLACK and included in the message
channel of the LD Block in accordance with the specified
message channel bandwidth (i.e. 1200 bps initially).
Message and control shares a total of at least 1800
bps, so in order to provide 1200 bps to message traffic
the control should not exceed 600 bps in average.
5.3.7 T̲h̲e̲ ̲D̲a̲t̲a̲ ̲U̲s̲e̲r̲ ̲R̲o̲u̲t̲e̲ ̲R̲e̲c̲o̲r̲d̲s̲
For each Data User Route, primary or secondary which
passes through an LTUX, the LTUX shall have a Data
User Route Record. This shall include the following
information:
1 Global Data User identification
2 Global Data User Route identification
4 User code, one code for each LTUX pair involved
5 Block length used for Data Transfers
6 Protocol status information
Each Data User Route Record describes a one way (simplex)
connection.
There are two types of these records, the end point
data user LTUX uses the Data Route End Record, DRER,
the trunk LTUX uses the Data Route Trunk Record, DRTR.
The Data Route Records are related to a data user…09…s
primary and secondary routes as shown in Figure 5.3.7.
The Data Route End Records are located in the Data
User LTUXes. They describe the relation between Hardware
SIO units and TDX Bus entry Queue. Further they contain
information on how to block the data transferred.
See Figure 5.3.7.
Figure 5.3.7-1…01…Data Route Records
Figure 5.3.7-2…01…Data Route End Records
Figure 5.3.7-3…01…Data Route Trunk Records
The Data Route Trunk Records are located in TRUNK LTUXes.
They describe the relation between data channels on
the trunk and data channels on the TDX Bus. Primary
and secondary routes are not distinguished on the trunks,
so the DRTRs contain information on how to map a TDX
data channel into a trunk data channel. See Figure
5.3.7
The contents of the Data Route Records is described
in the interface section for the black TDX system.
5.3.8 D̲a̲t̲a̲ ̲U̲s̲e̲r̲ ̲P̲r̲o̲t̲o̲c̲o̲l̲s̲,̲ ̲d̲e̲t̲a̲i̲l̲e̲d̲ ̲d̲e̲s̲c̲r̲i̲p̲t̲i̲o̲n̲
This section contains a detailed description of the
data user related protocols used in FIKS. For protocols
which are already a standard product a reference to
the description of the standard protocol is included
instead. In the later module product specifications,
however, interfaces to these standard protocols must
be specified, either standard or special for FIKS.
5.3.8.1 D̲a̲t̲a̲ ̲U̲s̲e̲r̲ ̲P̲l̲u̲g̲ ̲P̲r̲o̲t̲o̲c̲o̲l̲
This protocol handles the service against the data
user terminal plugs. This protocol is ultimately responsible
for giving a service to the data users which fulfill
the functional requirements for the data user handling.
The operation of the plug control can be described
narratively as follows:
When an activation request appears at a data user
interface (105 on a DCE entry, 109 on a DTE entry
to the FIKS network), the LTUX shall start sampling
and accumulation of the incoming data, within certain
time limits determined as 10 ms for TOSCA users
at a DTE entry, 50 ms for other users at a DTE
entry and 250 ms for all users at DCE entries to
the FIKS network. When data sampling starts on
a DCE entry 106 shall be raised to indicate that
sampling has commenced. As soon as possible the
plug protocol issues an activation Request to the
route Protocol level.
The activation Request is brought forth to the
data user LTUX in the other end. The plug protocol
in the other end shall synchronize a timer upon
the activation Request in order to know when to
start transmission of data. This is needed for
the LINK 1 data user group and is recommended for
all data users with a total allowed delay of 0.5
seconds.
For data users which have no special delay variation
requirement the activation Request command need
not be issued. When the data have been accumulated
they may be forwarded without prior notice. This
is possible for all the data user groups with a
total allowed delay of 2 seconds.
For details concerning the FLYPEP data users, please
see the FLYPEP LTUX descriptions.
When a predetermined number of bytes have been accumulated
by the Plug Protocol, a data block in the HLP format
is formed and issued to the Routing Protocol.
The Data User Plug Protocol is divided into an input
part and an output part. First the input part is described.
Input is defined as data from a Data Terminal going
into the FIKS network, entering at a DCE or DTE interface.
The following commands are recognized at the input
part:
- Activation Request ACR
- Deactivation Request DAR
- Forward X bytes of data FXB
- Reset RST
The Data Plug Protocol assumes an error free route
at its disposal.
Note: The Open command shall send a " reset" command
to the Plug Protocol.
Data Plug Protocol, Input Part.
The Output part of the Data Plug Protocol handles output
of data from the FIKS network to a Data User Terminal
via a DCE or DTE interface.
The following commands are recognized at the output
part:
- Activation Request ACR
- Deactivation Request DAR
- Forward X bytes FXB
The Data Plug Protocol assumes to have an error free
route at its disposal.
Data Plug Protocol, Output part is DTE.
Note: The FLYPEP/TERM protocol is not incorporated
in the state diagram. Please refer to the
FLYPEP LTUX descriptions
Data Plug Protocol, Output Part is DCE.
Note: The FLYPEP operation is not included.
Please refer to the FLYPEP LTUX descriptions.
…01…FIKS TDX, Data Switch…01…Data User Controls
5.3.8.2 D̲a̲t̲a̲ ̲U̲s̲e̲r̲ ̲R̲o̲u̲t̲i̲n̲g̲ ̲P̲r̲o̲t̲o̲c̲o̲l̲
The Data User Routing Protocol is represented both
in the data user LTUXes and in the intermediate trunk
LTUXes. In the data LTUXes the routing protocol selects
which route, primary or secondary is to be used by
the higher level Data User Plug Protocol. In the intermediate
trunk LTUXes the routing protocol is present in as
much as it monitors the trunk availability and sends
a report to the involved LTUXes (a MTR command) that
the trunk is missing.
I̲n̲p̲u̲t̲ ̲P̲a̲r̲t̲ ̲D̲a̲t̲a̲ ̲U̲s̲e̲r̲ ̲L̲T̲U̲X̲e̲s̲
The following primitives are recognized:
1 Forward Data Bytes FXB
2 Forward Control ACR/DAR
3 Missing Trunk MTR
4 Reset Route (to primary) RSP
The input part always selects the best current connection
according to its connection information in the DLER.
The connections possible are primary, secondary, none.
I̲n̲t̲e̲r̲m̲e̲d̲i̲a̲t̲e̲ ̲T̲r̲u̲n̲k̲s̲ ̲I̲n̲p̲u̲t̲
The intermediate trunk LTUXes are involved in the routing
protocol. In case the trunk line becomes unavailable,
a report to this effect shall be sent against the source
LTUXes which have routes passing through the trunk.
The following primitives are recognized:
1 Forward Data FXB
2 Forward Control ACR/DAR
3 Missing Trunk MTR
4 Available Trunk ATR
The trunk LTUX forwards data and control passed to
it, as far as possible. However, when the associated
trunk line becomes unavailable, the trunk LTUX generates
an MTR command to all the data user source LTUXes which
have primary or secondary routes passing through the
trunk. The MTR command is not generated as a result
of any other event than unavailable trunks, i.e. not
because of data user bandwidth overflow.
The following states in this function are recognized.
O̲u̲t̲p̲u̲t̲ ̲p̲a̲r̲t̲ ̲D̲a̲t̲a̲ ̲U̲s̲e̲r̲ ̲L̲T̲U̲X̲
The output part of the DUR handles the traffic from
the network to the end point data user, both the data
traffic and the control traffic.
The following primitives are recognized:
1 Forward Data Bytes FXB
2 Forward Control ACR/DAR
Data and control will be forwarded when coming from
either route, primary or secondary.
D̲A̲T̲A̲ ̲U̲S̲E̲R̲ ̲R̲O̲U̲T̲I̲N̲G̲ ̲P̲R̲O̲T̲O̲C̲O̲L̲ ̲F̲O̲R̲M̲A̲T̲S̲ ̲I̲N̲ ̲H̲L̲P̲ ̲H̲E̲A̲D̲E̲R̲
̲ ̲7̲ ̲,̲ ̲6̲ ̲,̲ ̲5̲ ̲,̲ ̲4̲ ̲,̲ ̲3̲ ̲,̲ ̲2̲ ̲,̲ ̲1̲ ̲,̲ ̲0̲ ̲,̲ ̲ ̲
^̲ ̲F̲O̲R̲M̲A̲T̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲^̲ ̲U̲S̲E̲R̲ ̲C̲O̲D̲E̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲^̲
^̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ^
^̲ ̲1̲ ̲ ̲ ̲0̲ ̲ ̲ ̲0̲ ̲ ̲ ̲0̲ ̲^̲ ^ Available
trunk
^̲ ̲1̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲1̲ ̲^̲ ^ Missing trunk
^̲ ̲1̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲1̲ ̲ ̲ ̲0̲ ̲^̲ ^
^̲ ̲1̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲1̲ ̲ ̲ ̲1̲ ̲^̲ ^
^̲ ̲1̲ ̲ ̲ ̲1̲ ̲ ̲ ̲0̲ ̲ ̲ ̲0̲ ̲^̲ ^ Spare
^̲ ̲1̲ ̲ ̲ ̲1̲ ̲ ̲ ̲0̲ ̲ ̲ ̲1̲ ̲^̲ ^
^̲ ̲1̲ ̲ ̲ ̲1̲ ̲ ̲ ̲1̲ ̲ ̲ ̲0̲ ̲^̲ ^
^̲ ̲1̲ ̲ ̲ ̲1̲ ̲ ̲ ̲1̲ ̲ ̲ ̲1̲ ̲^̲ ^
^̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲^̲
D̲a̲t̲a̲ ̲U̲s̲e̲r̲ ̲R̲o̲u̲t̲e̲ ̲S̲w̲i̲t̲c̲h̲i̲n̲g̲,̲ ̲a̲ ̲s̲u̲m̲m̲a̲r̲y̲
The Data User Network must automatically select the
secondary route when the primary has failed. The selection
shall be done in the source data user LTUX. In order
to determine that a route has broken, i.e. has become
disabled, such an occurance when detected by any intermediate
trunk LTUX is reported back to the data user source
LTUX in order for the switch to be executed. A positive
report is returned from any trunk LTUX which cannot
forward the data received. Hence, the Data User Routing
Protocol is represented in all LTUXes which handle
data user but the tasks to be executed by the end point
data user LTUXes are different from those carried out
in the trunk LTUXes.
Consider Figure 5.3.8.2-1 overleaf. Assume that data
are flowing from A to K via Node B, as the primary
route. The trunk line between B and K breaks. Trunk
LTUX Bk detects this and sends a report to any source
LTUX for this trunk. One of them is the trunk LYUX
Ba. The trunk LTUX Ba forwards a control block to
trunk LTUX Ab indicating all the data users which are
affected by the error on trunk Bk, both primary and
secondary routes.
Figure 5.3.8.2
5.3.8.3 L̲D̲B̲M̲ ̲P̲r̲o̲t̲o̲c̲o̲l̲s̲,̲ ̲i̲n̲t̲r̲o̲d̲u̲c̲t̲i̲o̲n̲
The LDBM protocol handles the data user- and message
traffic on internodal trunks. The following describes
the traffic on one internodal trunk line.
There is one message c̲h̲a̲n̲n̲e̲l̲. There are 15 channels
for data traffic the so called data channels. There
is one channel for control. The control channel is
used for basic synchronization and for interchanging
of configuration updates with respect to the data channels.
The message channel and the control channel share
a total bandwidth of 1800 baud. The data channels
share a total bandwidth of 6000 baud.
All data channels carry point-to-point simplex discontinuous
traffic as seen from the trunk LTUX. Each data channel
may have allocated a bandwidth of 300, 600, 1200 og
2400 bps. When the data channel is active it will
have one of the above-mentioned bit rates at its disposal.
When a data channel becomes activated, positive verification
of the activated channel is obtained. Before the data
channel configuration is updated there is the following
condition to be fulfilled when activating a channel
over a internodal trunk line: The total available
bandwidth for data channels shall not exceed 6000 bps.
If a data channel needs activation, there must be
space for it within this limit or else the activation
will not be effectuated on this trunk. This means
that the activation request shall proceed but no data
shall be allowed before other data channels cease operation.
The strategy by which newly activated channels get
bandwidth in case of over-demand is by priority.
The updating of the data channel configuration is carried
out as follows: The trunk LTUX receives a request
to activate or deactivate o̲n̲e̲ data channel. A channel
change request (control) is sent to the far end. The
far end shall acknowledge the request. If no response
within a time limit t…0f…c…0e… , the request is repeated.
N…0f…c…0e… times the request may be repeated. Then a hard
error is declared.
Once having received validly an acknowledgement the
new data channel configuration is announced by a change
of sync. pattern phase (i.e. changing to another set
of sync. patterns). The sync. patterns are so designed
as to correct up to 2 bit errors within an 8 bit sync.
frame by means of a forward error correction scheme.
In this way the transmitter specifies exactly when
the actual change in the data channel configuration
takes place without (normally) disturbing the data
channel traffic itself.
D̲a̲t̲a̲ ̲U̲s̲e̲r̲ ̲M̲u̲l̲t̲i̲p̲l̲e̲x̲ ̲P̲r̲o̲t̲o̲c̲o̲l̲
The Data User Multiplex Protocol rules the multiplexing
and demultiplexing of data user traffic over one LTUX-LTUX
connection via one TDX-bus. The high level Protocol
Format is employed. There is no reset or retransmission
facility in the protocol. All it does is to multiplex
and demultiplex independent data user traffic streams.
The method is block multiplexing. Please refer to
the HLP-Format description, section 5.3.4.
The input part of the DUM Protocol fills in the user
code in each HLP Header. The output part interpretes
the user code of the HLP Header. The input part groups
together the HLP Blocks bound for the same LTUX in
TDX bus frames. The output part demultiplexes the
contents of TDX frames into one or more HLP Blocks.
L̲o̲w̲ ̲D̲e̲l̲a̲y̲ ̲B̲l̲o̲c̲k̲ ̲P̲r̲o̲t̲o̲c̲o̲l̲
The low Delay Block Protocol is used between LTUXes
over internodal trunks on leased as well as NPDN connections.
Once set up the protocol transmit blocks with fixed
length each block being preceeded with one of several
possible synchronization patterns.
The blocks are divided into three different parts the
data user part and the mutually exclusive control-
and message part. Control information sent via the
internodal trunks is checked for errors and retransmitted
in case of error block by block. Message traffic is
error detected and corrected by the X25 level 2 protocol
running in the LTUX-CRYPTO/RED.
Figure 5.3.8.3-1…01…FIKS TRUNK LTUX…01…Message & Data Traffic
L̲o̲w̲ ̲D̲e̲l̲a̲y̲ ̲B̲l̲o̲c̲k̲ ̲F̲o̲r̲m̲a̲t̲
The Low Delay Block (LDB) format is basically of fixed
length. Each block consists of a header byte (sync.
byte) and a fixed number of information bytes. Se
Figure 5.3.8.3-1.
T̲h̲e̲ ̲S̲y̲n̲c̲.̲ ̲H̲e̲a̲d̲e̲r̲
The header is basically used for synchronization and
for verification of synchronization maintenance. Further
it has been determined that the synchronization pattern
of 8 bits may during operation carry information corresponding
to 2 bits (i.e. 4 combinations) and yet be able to
forward correct up to 2 bits errors. The sync. byte
informs about data user configuration changes and about
message/control contents in the block.
The combinations are in short:
1 Control included, Data User State 0
2 Message info. included, Data User State 0
3 Control included, Data User State 1
4 Message info. included, Data User State 1
The Control Field contains information on changes in
the data user traffic pattern: The High Level, Protocol
Format applies.
The message information is encrypted message packet
received from the LTUX-CRYPTO/BLACK.
The Data User configuration number relates to two possible
states in which the data user configuration may be.
When a data user is taken out or inserted in the block,
first a handshake to this effect takes place. Then
the transmitter toggles this bit of information and
includes it in all the blocks following with the new
data user configuration.
Data User channels down to 300 bps are supported.
This implies that when LD Blocks of 32 bytes are used
on 9600 bps channels then a 300 bps user shall only
have one byte in every LD-Block. In case of baud rates
lower than 300 bps trunk bandwidth is not used optimal.
U̲n̲d̲e̲t̲e̲c̲t̲e̲d̲ ̲E̲r̲r̲o̲r̲s̲ ̲i̲n̲ ̲S̲y̲n̲c̲.̲ ̲P̲a̲t̲t̲e̲r̲n̲
The sync. pattern is 8 bits long. The bit error rate
anticipated is 1 in 10…0e…5…0f… bits. In the following is
calculated the probability of having 0, 1, 2, 3 bit
errors in a sync. byte. Based on these calculations
a decision shall be made, as to the number of bits
which shall be forward detectable and correctable in
the sync. pattern.
S = probability that any bit is erroneous
1-S = probability that any bit is correct
(1-S)…0e…8…0f… = probability that all 8 bits are correct
1-(1-S)…0e…8…0f… = probability that not all 8 bits are
correct, i.e. that there are one or more
errors in the sync pattern
(…0e…8…0f…) S…0e…n…0f…(1-S)…0e…8-n…0f… = probability of exactly n bit
…0e…n…0f… errors in 8 bits
On the page overleaf is shown the probability figures
for n = 1,2,3,4. As an expression of n or more bit
errors, the exactly-n-errors figure is a good approximation.
S̲y̲n̲c̲.̲ ̲P̲a̲t̲t̲e̲r̲n̲ ̲e̲r̲r̲o̲r̲ ̲f̲r̲e̲q̲u̲e̲n̲c̲y̲
In the previous section the probability of errors in
the sync. pattern was calculated for various numbers
of errors. In order to decide how many bit errors
shall be detectable and correctable the frequency in
occurrences per second shall be calculated for 1,2,3,
and 4 bit errors. The sync. pattern occurs per 16
bytes, i.e. once per 128 bits. On a 9600 bps channel
the sync. pattern rate becomes:
sync. pattern rate: 9̲6̲0̲0̲ …0f…= 75/s…0e…
128
The average time interval between n bit errors is shown
in the tables overleaf. Note that the error rate is
taken as the reciprocal of the probability.
One error occurs as seen avr. every 166 seconds, i.e.
every 2,7 minutes.
Two errors occur every 4,7622.10…0e…6…0f… sec. or:
…0f…6…0e…
4̲,̲7̲6̲2̲2̲.̲1̲0̲ ̲ ̲s̲e̲c̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ …0f…= 55 days…0e…
60 sec/min 60 min/hr 24 hr/dy
This was on a single trunk. There are 18 trunks in
the FIKS network. This means that in average over
the entire FIKS network a 3 error occurrence in an
8bit sync. pattern will be every
7̲5̲5̲0̲.̲4̲ …0f…= 419 years…0e…
18
Judging from these calculations it appears acceptable
that 3 error occurrences will cause undetectable errors
while 2 errors and one error occurrence shall be detectable
and correctable.
S̲Y̲N̲C̲.̲ ̲P̲a̲t̲t̲e̲r̲n̲ ̲C̲o̲m̲b̲i̲n̲a̲t̲i̲o̲n̲s̲
An 8 bit synchronization is to be used. It has been
decided that 2 bit errors within the sync. pattern
shall be detected and corrected. How many combinations
can be forwarded within this 8n bit sync. byte?
In the following is determined the number of combinations
necessary to point out 0,1,2 errors in an 8 bit byte:
0 errors …0e…8…0f… 1 code
…0e…0…0f…
1 error …0e…8…0f… 8 codes
…0e…1…0f…
2 errors …0e…8…0f… 28 codes
…0e…2…0f… ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
…0e…37 codes…0f…
========
To specify 37 different codes 6 bits are necessary.
This leaves 2 bits for information, i.e. four codes.
S̲y̲n̲c̲.̲ ̲P̲a̲t̲t̲e̲r̲n̲ ̲C̲o̲d̲e̲s̲
As mentioned above it shall be possible to forward
four codes in an 8 bit pattern while providing error
detection and correction of up to 2 bits within these
8 bits. For this to be possible the minimum bit distance
must be more than the double of 2 bits, i.e. at least
5 bits. The pattern hence shall be selected so as
to obtain this bit distance. A sample set is:
1 00000000 …0f…5…0e…
2 00011111 5 3
11111000
…0f…5…0e…
5
…0e…6…0f…
…0e…6…0f…
4 11100111
Another set is shown below
1 10001001 89
2 10010110 96
3 01110001 71
4 01101110 6E
The bit distances are as in the prior set.
This combination is suggested for the LDB
Protocol…09…s synchronization bytes.
L̲o̲w̲ ̲D̲e̲l̲a̲y̲ ̲B̲y̲t̲e̲ ̲M̲u̲l̲t̲i̲p̲l̲e̲x̲ ̲P̲r̲o̲t̲o̲c̲o̲l̲ ̲D̲e̲s̲c̲r̲i̲p̲t̲i̲o̲n̲
The LDBM Protocols are governed by the following events
in the form om control blocks.
1 Restart Request
2 Data Channel Change Request
3 Restart Acknowledge
4 Data Channel Change Acknowledge
5 Missing trunk
6 Status/Dummy
and the following events in forward error corrected
information:
Data Channel State 0
Data Channel State 1
Control included in Low Data Block
Message Data included in Low Delay Block
L̲D̲B̲ ̲P̲r̲o̲t̲o̲c̲o̲l̲ ̲N̲a̲r̲r̲a̲t̲i̲v̲e̲
The purposes of the Low Delay BLock Protocol are:
1 Maintenance of up to 15 data channels
2 Activating and deactivating data channels under
CRC-control
3 Allowing for message traffic whenever control
information is not exchanged
4 Comply with required bandwidth allocations
for data channels as well as message traffic
The LDBM protocol restart may be initiated from either
side. During restart both sides synchronize on a 16
bit synchronization pattern. Once synchronized on
bytes no further bit hunting takes place. The 8 bit
sync. patterns located in the beginning of each LD-Block
must be found in its right position continuously or
a restart will be initiated.
After a reset the internodal trunk must be declared
open to all data user LTUXes which have data flowing
through it either primarily or secondarily. Similarly
a trunk cannot loose synchronization without being
declared not available. Whenever one of the directions
losses synchronization a Restart Request is issued
and the trunk is declared in both directions until
synchronization is regained.
Once brought in synchronization the Sync. 1,2,3,4 characters
precede LD-Blocks of equal length.
The contents of the LD-Blocks are limited as follows:
Message data shall have a bandwidth of 1200 bps.
The message bandwidth shall be reconfigurable to another
value. Similarly, data channels shall have allocated
totally a bandwidth of initially 6000 bps. These bandwidth
limits are named the message bandwidth and the data
bandwidth, respectively. Control information when
present takes up the bandwidth normally occupied by
message traffic since the data user part must remain
as is until changes by the data channel procedure.
If data traffic do not occupy 6000 bps exessive bandwidth
is automatically allocated for message traffic.
C̲h̲a̲n̲n̲e̲l̲ ̲C̲h̲a̲n̲g̲e̲ ̲P̲r̲o̲c̲e̲d̲u̲r̲e̲s̲
The initiative to change a data channel shall always
come from the data source. A control block is inserted
in the LD-Block to specify which data channel is to
be inserted or deleted, respectively. The control
block has included a CRC-residue and a validity check
is executed in the receiving trunk. If valid the block
is reacted upon and an acknowledgment is returned.
After…86…1 …02… …02… …02… …02…
the acknowledgment has been received the sender shall
change the data channel state, toggle in the next LD
Block to be forwarded. When the receiver sees the
new toggle state presented in the LD Block it knows
that this LD Block and the following contain the new
data channel configuration, The Control Block presenting
the data channel update request shall also specify
the new state of the toggle to be switched to, this
state must be the opposite state of the present.
There is no guarantee that after having issued a channel
change request which has been orderly acknowledged
a data source will issue a valid LD Block according
to this new configuration. If namely a new channel
change requirement occurs immediately following the
former a new Change Request may follow in the next
block and if at the same time an error burst of more
than two bits occurs in the only LD Block occurring
in that configuration state, it will never be recognized
by the receiver. However, this does not affect the
consisstency of the protocol since all change Requests
are acknowledged - and n̲o̲ ̲n̲e̲w̲ Change Request can be
issued before the former was validly acknowledged.
This also means that the data channel source must
retransmit not-acknowledged or timed-out Change Requests.
This has to be done N times or a restart of the entire
trunk connection must take place. It is not allowed
to ignore a Change Request once issued and issue another
more up-to-date request.
T̲h̲e̲ ̲i̲n̲t̲e̲r̲n̲o̲d̲a̲l̲ ̲T̲r̲u̲n̲k̲ ̲P̲r̲o̲t̲o̲c̲o̲l̲ ̲f̲r̲o̲m̲ ̲a̲ ̲n̲e̲t̲w̲o̲r̲k̲ ̲p̲o̲i̲n̲t̲
̲o̲f̲ ̲v̲i̲e̲w̲
In the FIKS network the SCC…09…s have the ability to send
commands to the nodes via the internodal trunks. However,
this is only possible as long as the trunks are operational.
The nodes themselves must be able to keep alive (i.e.
operational) the trunks and able to transmit SCC commands
to trunks. Seen from the internodal trunks there is
no difference between SCC commands and narrative message
traffic. Hence the internodal trunk system must on
its own keep the internodal trunks available for message
traffic. It will then be up to the NSS to send or
not send message traffic on it.
D̲a̲t̲a̲ ̲t̲r̲a̲f̲f̲i̲c̲ ̲c̲a̲n̲n̲o̲t̲ ̲b̲e̲ ̲o̲p̲e̲n̲e̲d̲ ̲o̲r̲ ̲c̲l̲o̲s̲e̲d̲ ̲e̲x̲c̲e̲p̲t̲ ̲b̲y̲ ̲i̲s̲s̲u̲i̲n̲g̲
̲a̲ ̲n̲e̲w̲ ̲d̲a̲t̲a̲ ̲u̲s̲e̲r̲ ̲R̲o̲u̲t̲e̲ ̲C̲o̲n̲f̲i̲g̲u̲r̲a̲t̲i̲o̲n̲ ̲f̲r̲o̲m̲ ̲e̲a̲c̲h̲ ̲N̲o̲d̲e̲…89…s̲
̲d̲i̲s̲k̲ ̲s̲t̲o̲r̲a̲g̲e̲.
SUMMARY: The LTUX-TRUNK shall always try to keep its
internodal trunk available to any traffic data as well
as message.
An internodal trunk may, due to physical unavailability,
be declared (logically) unavailable. Without becoming
physically available no trunk can be logically available.
(The LTUX-TRUNK is responsible for keeping its internodal
trunk physically available. A (SCC-) command may declare
a trunk logically available and therefore available
to message traffic.
Also a SCC command is necessary to let a data user
get onto a primary route which has been ceased due
to trunk unavailability whether logical or physical.
R̲e̲s̲t̲a̲r̲t̲ ̲R̲e̲q̲u̲e̲s̲t̲
The Restart block format is as follows:
2 Sync. bytes
1 Byte command + Master Slave designation
2 Bytes, channel inclusion Mask. This specifies
which channels shall be considered active at present
2 Bytes, CRC
Sync. character shall be sync. for control in either
state.
R̲e̲s̲t̲a̲r̲t̲ ̲A̲c̲k̲n̲o̲w̲l̲e̲d̲g̲m̲e̲n̲t̲
The format is as follows:
1 Byte command
2 Bytes channel inclusion Mask resulting
2 Bytes CRC
The Restart acknowledgment returns the channel inclusion
Mask. The returned Mask might be different from the
requested inclusion Mask, if the requestor was a slave
to the acknowledger.
D̲a̲t̲a̲ ̲C̲h̲a̲n̲n̲e̲l̲ ̲C̲h̲a̲n̲g̲e̲ ̲R̲e̲q̲u̲e̲s̲t̲
The channel change request format is as follows:
1 Byte command + channel identification
2 Bytes CRC
The Sync. character shall be sync. for control in either
state.
When channel id = F…0f…16…0e… is selected this command to prolong
or reduce the length of the next lD Block with message
contents. All Blocks until acknowledgment is received
shall be sent with control contents. The purpose of
this mechanism is to adjust for difference in clock
rate between trunk line clock and the stable data user
clock.
D̲a̲t̲a̲ ̲C̲h̲a̲n̲n̲e̲l̲ ̲C̲h̲a̲n̲g̲e̲ ̲A̲c̲k̲n̲o̲w̲l̲e̲d̲g̲m̲e̲n̲t̲
The change acknowledgment format is as follows:
1 Byte command + next state designation
2 Bytes CRC
The next state to be switched to shall be reported
back to the change requested, in order for him to check
if state change agreement is being maintained.
M̲i̲s̲s̲i̲n̲g̲ ̲T̲r̲u̲n̲k̲ ̲R̲e̲p̲o̲r̲t̲
Format:
1 Command byte
2 CRC bytes
These reports are passed transparently by the LDBM
protocol.
S̲t̲a̲t̲u̲s̲/̲D̲u̲m̲m̲y̲ ̲R̲e̲p̲o̲r̲t̲
Format:
1 byte Command
2 bytes CRC
This report is issued whenever space is available on
the trunk line within the previously described LD-Block
Format.
5.3.8.4 M̲e̲s̲s̲a̲g̲e̲ ̲T̲r̲a̲f̲f̲i̲c̲ ̲H̲a̲n̲d̲l̲i̲n̲g̲
The Message Traffic being transmitted via the internodal
trunks within the LD Block Byte Multiplexing scheme
has been HDLC frame processed before being entered
into LD-Blocks.
The HDLC processing is carried out on message traffic
going into or out of an internodal trunk. No message
traffic is relayed transparently, as is data user traffic.
The message traffic between the LTUX-CRYPTO/BLACK and
the LTUX-TRUNK or LTUX-NPDN is governed by the TDX-protocol.
The message traffic byte stream is included in LD Blocks,
typically 2-3 bytes at a time, whenever control bytes
are not occupying the shared control/message bandwidth
in the LD Blocks.…86…1 …02… …02… …02… …02…
5.3.8.5 D̲a̲t̲a̲ ̲U̲s̲e̲r̲ ̲T̲r̲a̲f̲f̲i̲c̲ ̲H̲a̲n̲d̲l̲i̲n̲g̲
All data channels going via the internodal trunks may
be activated or deactivated at any time, i.e. all data
channels are considered discontinuous. When a data
channel activation or deactivation is announced to
a LTUX via the TDX bus in the HLP-Format, a channel
change request is forwarded. The data received on
the channel until the channel is available are buffered
until n characters have been accumulated. From this
time and on the oldest information is overridden (a
FIFO buffer of length n is maintained). The buffer
length shall be so as to support buffering of all characters
during a n̲o̲r̲m̲a̲l̲ change request - acknowledgment cycle.
By normal is meant a cycle in which neither the request
nor the acknowledgment need retransmission. The normal
request - ack cycle has a maximum length of 5 x 14
ms = 70 ms, so the FIFO buffer shall support buffering
of at least 70 ms worth of traffic. For example, on
a 1200 bps line this corresponds to 11 chars. and on
a 2400 bps line, 22 characters. Bitrates excess of
2400 bps are not supported.
The LDB Protocol can only have one request for change
outstanding at any one time so there is the upper limit
of approximately 14 channel change requests per second.
Another limiting factor is that only 600 bps is allocated
average for control. Each change takes in its normal,
i.e. non erroneous condition 8 chars of 8 bit each.
This corresponds to 9 channel change requests
per second.
So the service limits which can be given the data users
with respect to change requests are:
1) 9 channel changes/second max.
2) No 2 change request may coincide in order to be
considered normal. (Only normal change requests
are prevented from loosing data during the channel
activation period).
5.3.8.6 T̲r̲u̲n̲k̲ ̲E̲l̲e̲c̲t̲r̲i̲c̲a̲l̲ ̲l̲e̲v̲e̲l̲ ̲p̲r̲o̲t̲o̲c̲o̲l̲ ̲V̲2̲4̲
A driver function shall be provided which handles leased
lines in accordance with the CCITT V24 specification
using the circuits specified in the FIKS Requirements
spec. issue 5.
5.3.8.7 T̲r̲u̲n̲k̲ ̲E̲l̲e̲c̲t̲r̲i̲c̲a̲l̲ ̲l̲e̲v̲e̲l̲ ̲p̲r̲o̲t̲o̲c̲o̲l̲ ̲X̲2̲1̲
A driver function shall be provided which handles NPDN
lines in accordance with the CCITT X 21 specification
using the dircuits specified in the FIKS Requirements
spec. issue 5.
5.3.9 D̲a̲t̲a̲ ̲U̲s̲e̲r̲ ̲D̲e̲l̲a̲y̲s̲
Several occurrences affect the data user traffic delays
through the network. The accumulation of data user
bytes into blocks before forwarding introduces accumulation
delays, DAD. Data is accumulated before forwarding
in every LTUX the data user traffic passes.
The transmission of data user traffic takes place at
finite speeds, and each transmission involved adds
a delay component onto the total traffic. The factor
considered is transmission delay DTD.
D̲a̲t̲a̲ ̲a̲c̲c̲u̲m̲u̲l̲a̲t̲i̲o̲n̲ ̲D̲e̲l̲a̲y̲s̲
These delays are determined from the data speed into
the accumulator, and the amount of data accumulated,
see calculations overleaf.
D̲a̲t̲a̲ ̲U̲s̲e̲r̲ ̲D̲e̲l̲a̲y̲ ̲C̲a̲l̲c̲u̲l̲a̲t̲i̲o̲n̲s̲
In this section sample calculations are made of the
different data users which are dimensioning due to
some unique characterestics. The considered data user
groups are: LINK 1 which has very low delay variation.
Intel 6 which has 3 hops and 0.5 sec allowable delay.
TOSCA RING which functions as a multidrop network.
L̲I̲N̲K̲ ̲1̲ ̲D̲E̲L̲A̲Y̲ ̲V̲A̲R̲I̲A̲T̲I̲O̲N̲
LINK ONE reaches over two hops. The delay variation
shall be within +/- 200 ms:
The Data accumulation delay is determined by the baudrate
1200 bps and the accumulated blockage of 4 chars to
DAD = ̲ ̲4̲ ̲ ̲ …0f…=…0e… …0f…26 ms…0e…
1̲2̲0̲0̲ ̲
8
The LTUX is sampled every 13 ms so the delay variation
out of the data user LTUX and to the first trunk is
DLD = -0 + 13 ms.
Once having reached the trunk LTUX, the delay variation
to get onto the next LD Block is determined by the
length of the LD Blocks. The duration of an LDB Block
32 bytes at 9.6 kbps or:
T…0f…LD…0e… …0f…=…0e… 32 ̲b̲y̲t̲e̲s̲ ̲*̲ ̲8̲ ̲b̲i̲t̲s̲/̲b̲y̲t̲e̲ …0f…= 13,2 ms…0e…
9,6 Kbps
The LD-Block entry delay variation thus becomes:
(Trunk entry delay)
TED = -0 + 13,2 ms
Note that the transmission delay is fixed and does
not add to the delay variation.
The delay variation for entering the TDX Bus from a
trunk LTUX is rather low due to the bandwidth allocated.
Each trunk has allocated at least 4 x 9,6 kbps which
corresponds to 38,4 kbps or one poll every 3,3
ms. This results in a delay variation of (Trunk Exit
Delay):
TDX = -0 + 3,3 ms
Figure 3.2.2.2.2.2-3…01…LINK ONE DELAY COMPONENTS
Each LTUX is assumed to introduce some unpredictable
delays, L̲TUX R̲eaction D̲elays. An estimate is averaged
over the 6 LTUXes involving 2 ms per LTUX or 12 ms
maximum; thus yielding a LRD variation per LTUX of
LRD = -0 + 2 ms
For each trunk line to be entered a channel change
sequence including a request and a confirmation must
be carried out before the data can pass the particular
trunk. As stated specifically, errors in these control
sequences shall not be taken into account in the calculation
of the contractual delays.
The channel change sequence delays can be described
as follows:
A TED will elapse for the change request to enter the
trunk line, a CXD will elapse for the request to get
transmittet. Another TED will elapse for the confirmation
to be returned and another CXD will elapse for the
request to be transmitted. The CXD, the control transmit
Delay is determined by: 4 bytes block length at 9.6
kbps or CXD = 3.3 ms.
The channel change delay, when no errors occur ACD
becomes:
ACD = 2 …0e…*…0f… TED + 2 …0e…*…0f… CXD + 2 …09… LRD
= 2 …09… 6.6 ms + 2 …09… 3.3 ms
+ 2 + 2 ms = 23.8 ms
This figure contains 17.2 ms variable and 3.3 ms fixed
delay
CDV = 17.2 ms
CFD = 6.6 ms
The accumulated delay and delay variation may now be
calculated
ADV…0f…L1…0e… = DLD + 2 * (TED+TDX) + 6 * LRD
+ CDV * 2
= (13 + 2 * (6.6+3.3) + 6 * 2 + 17.2 * 2) ms
= 7̲9̲.̲2̲
̲m̲s̲
AFD…0f…L1…0e… = DAD + TTD * 2 + CFD * 2 …0e…X)…0f…
= 26 ms + 2 * 6.6 ms = 3̲9̲.̲2̲
̲m̲s̲
AD…0f…L1…0e… = ADV…0f…L1…0e… + AFD…0f…L1…0e…
= 79.2 ms + 39.2 ms = 1̲1̲8̲.̲4̲
̲m̲s̲
The delay figures above refer to delays of the LINK
1 data through the network. However, the delay and
delay variation for a change request which is sent
through the network without control block errors neither
on the TDX Bus nor the internodal trunk lines is smaller
since the DAD and the CDV contributions disappear.
Total Control delay:
TCD…0f…L1…0e… = AD…0f…L1…0e… -(DAD + 2 …0e…*…0f… CDU)
= ll8.4 ms - (26 ms + 34.4) ms = 5̲7̲.̲4̲ ̲m̲s̲
X) The CFD …0e…*…0f… 2 is overlapped by the DAD since it shall
occur s̲i̲m̲u̲l̲t̲a̲n̲e̲o̲u̲s̲l̲y̲.
The total control delay variation for LINK 1 TCV…0f…L1…0e…
becomes:
TCV…0f…L1…0e… = ADV…0f…L1…0e… - 2 [ CDV
= 79.2 ms - 34.4 ms = 4̲4̲.̲8̲ ̲m̲s̲
I̲N̲T̲E̲L̲ ̲6̲ ̲T̲O̲T̲A̲L̲ ̲D̲E̲L̲A̲Y̲
The intel 6 data group shall not pass more than two
intermediate nodes, i.e. not be passed over more than
3 hops. The total delay allowed for intel 6 is 500
ms.
A formula for the Accumulated delay through a specified
number of intermediate trunks is:
AD…0f…DU…0e… = DAD + HOP# (TED+TDX+ACD)
+ LTUX# …0e…*…0f… LRD + DLD
Where HOP# is the number of intermediate hops and LTUX#
is the number of involved LTUX devices.
In the case of Intel 6 the following figures apply:
DAD = 26 ms
HOP# = 3
TED = 6.6 ms
TDX = 3.3 ms
ACD = 23.8 ms
LTUX# = 8
DLD = 13 ms
LRD = 2 ms
AD…0f…16…0e… = (26 + 3(6.6+3.3+23.8)+8…0e…*…0f…2+13) ms =
1̲5̲6̲.̲1̲ ̲m̲s̲
T̲O̲S̲C̲A̲ ̲R̲I̲N̲G̲,̲ ̲M̲u̲l̲t̲i̲d̲r̲o̲p̲ ̲C̲o̲n̲n̲e̲c̲t̲i̲o̲n̲
The TOSCA has 2 intermediate hops maximum, hence the
data user routing as sketched below:
Whatever is transmitted shall be transmitted to all
the other 3 Ring sites.
Whatever is received from any of the 3 other sites
shall be FIFO buffered in each data user LTUX.
The difference between the total LINK 1 delay and the
TOSCA Ring delay occurs in the LDL…0f…TR…0e… which is 3 times
as big as for LINK 1 since 3 poll sequences must elapse
before all 3 multidrop branches have been served.
The figures for the TOSCA Ring therefore will be about
26 ms bigger than the LINK 1 figures, both for variable
and accumulated values.
Hence
AD…0f…TR…0e… = AD…0f…L1…0e… + DLD…0f…TR…0e… - DLD…0f…L1…0e…
= 118.4 ms + (39.9-13.3) ms = 1̲4̲5̲ ̲m̲s̲
5.4 S̲C̲C̲ ̲S̲P̲E̲C̲I̲F̲I̲C̲ ̲L̲T̲U̲X̲S̲
The System Control Centers (SCC…09…s) may be considered
as two specialized nodes in the network. They only
connect to one other node, the collocated node. Further
each SCC is situated close to (within same screened
cage) the collocated node/mede. Because of this the
connection between the SCC and the collocated node/mede
need not to use modems and crypto equipment. The connection
is implemented as a simple V24-cable. Due to the very
short distance transmission errors are very unlikely
to occur and retransmissions on message level (X25.4)
will suffice X25.2 protocol are thus omitted. The
connection is controlled by a special LTUX, called
the LTUX-TRANS.
At the SCC two special terminals are defined. The
colour TV monitor and the audio alarm. The colour
TV is used to indicate the current state of the network
as known by the SCC and the audio alarm is used to
note the SCC operator about events of special importance
to the network.
5.4.1 L̲T̲U̲X̲-̲T̲R̲A̲N̲S̲
In the FIKS network two SCCs will exist. One is collocated
with Node E and the other with Node K. The connection
between the SCC and the collocated Node/MEDE is a 9,6
Kbps full duplex data link. The link will be situated
in red area and data passing are non-ecrypted.
The interface to the communication link is standard
V24. The link is connected to back panel JACK 3.
One back panel (Node/MEDE resident) must be a DCE panel,
and one (SCC resident) must be a DTE panel. At both
panels a test printer may be connected to JACK 1.
The LTUX-TRANS support one 9,6 Kbps full duplex communication
link. Data is transferred in HDLC packets with 16
bit CRC check at end of each packet. Only packets
without CRC-error are transferred to the HOST computer.
The V24 signalling used is shown overleaf.
The communication between the LTUX-TRANS and the NSS
is similar to that between the LTUX-CRYPTO/RED and
the NSS, i.e. packet are output to/read from LTUX,
subdevice no. 3. Maximum packet size is 518 bytes
with the format below:
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲
^̲ ̲F̲M̲ ̲^̲ ̲T̲O̲ ̲^̲ ̲N̲O̲ ̲^̲ ̲ ̲ ̲^̲ ̲ ̲ ̲^̲ ̲ ̲ ̲^̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲^̲
TRUNK-ID X25.3- 0-512 data bytes
header
Trunk-ID will be one of the four KQ1, QK1, EP1, PE1,
depending on location. As mentioned above the X25.2
protocol has been omitted. In case of CRC error packet
is discarded and recovery is left for higher level
protocols.
The LTUX-TRANS is initialized during start and restart.
Figure 5.4.1-1…01…HDLC-DRIVER…01…V24 - Line Signalling
5.4.2 L̲T̲U̲X̲-̲A̲U̲D̲I̲O̲/̲D̲I̲S̲P̲L̲A̲Y̲
This LTUX controls the colour display and the audio
alarm. Data received at subdevice no. 2 are output
at JACK 1 at 9600 bps. No conversion of data are performed.
Data is only output if V24 line 108, data terminal
ready, is high (active).
At subdevice no. 3 turn on and turn off commands are
received. The audio alarm is turned on/off accordingly,
by use of V24 line 109 (data carrier detect).
No data are forwarded from the LTUX-AUDIO/DISPLAY to
the CR80.
5.5 T̲D̲X̲-̲S̲Y̲S̲T̲E̲M̲ ̲I̲N̲I̲T̲I̲A̲L̲I̲Z̲A̲T̲I̲O̲N̲
The initialization of the TDX-system includes the definition
of the logical lines used between the CR80 HOST I/F
and the LTUXes and between pairs of LTUXes. Also some
information are down-line loaded to the LTUXes. This
may be baud rate, routing tables conversion tables
etc.
The kind of initialization needed depend on the actual
(assumed) state of the system. 5 states are recognized:
- Start. The whole TDX-system may have been
switched off.
- Switch over/restart. An automatic switch over
has ocurred, the TDX-system has not been powered
off. The restart situation is similar to the
switch over but is operator controlled.
- Black reconfiguration. Initializes the black
TDX-system as if system has been powered off.
New data user routes may be specified. Reconfiguration
is operator activated (DUR-Data User Reconfiguration).
- NPDN-call-up. An LTUX-TRUNK is replaced by
the LTUX-NPDN. The LTUX-TRUNK is closed and
the LTUX-NPDN is initialized as for power-up,.
except for the connection to the BLACK HOST
I/F.
- NPDN-close-down. The connections from the
LTUX-NPDN are closed (except the one for the
BLACK HOST I/F). The original LTUX-TRUNK is
initialized as after power-up.
In the following sections the different situations
are treated more detailed.
The information needed for the initialization are read
from the LTUX-configuration files by use of the LCFH-monitor
(ref. FIX/1000/USM/0001 LCFGEN user…09…s manual and FIX
1256/PSP/0055 LCFH monitor PSP). An overview of the
files defined are shown overleaf.
5.5.1 S̲t̲a̲r̲t̲
In this situation both the RED and the BLACK TDX-system
must be initialized completely. To initialize the
LTUXes connected to terminals (LTUX-VDU, LTUX-TELE,
and LTUX-AUDIO/DISPLAY) the following files are used:
LCFRJ01, LCFRR01, LCFRT01, LCFRU01, LCFRC01
These files defines the logical channels needed for
the actual terminal configuration and specifies the
baud rate of the terminals.
To initialize the message CRYPTO-system (LTUX-CRYPTO/RED,
LTUX-CRYPTO/BLACK, and LTUX-TRUNKS) the following
files are used:
LCFRN02, LCFBN02
The files connect the LTUX-CRYPTO/RED to the RED HOST
I/F, loads the message CRYPTO conversion table to both
the RED and the BLACK LTUX, and initializes the logical
channels needed between the LTUX-CRYPTO/BLACK and the
LTUX-TRUNKS.
If an LTUX-TRANS is present it is initialized by use
of the file:
LCFRN02
This applies for the SCC as well as for the collocated
NODE/MEDE. The LTUX-TRANS is connected to the RED
HOST I/F and loaded with a "TRUNK-ID".
The data user subsystem (LTUX-TRUNKS, LTUX-DATA-USERS
and LTUX-NPDN) is initialized by use of the files:
LCFBN03, LCFBN04
All the LTUXes in the subsystem are connected to the
BLACK HOST I/F. This is done to support the NSS supervision
of the system. A number of LTUX-LTUX connections are
initialized too. LTUX-TRUNK to LTUX-TRUNK connections
support data user traffic in transit, LTUX-TRUNK to
LTUX-DATA-USER connections support data users at the
origin/final destination.
The LTUX-TRUNKS are loaded with the data route trunk
records corresponding to the actual data user configuration
specified.
The LTUX-DATA-USERS are loaded with the data route
end records corresponding to the actual data user configuration.
Also the LTUX-DATA-USERS are loaded with the actual
baud rates of the connected users.
The LTUX-NPDN are only connected to the BLACK HOST
I/F since this LTUX are used for back-up purposes.
5.5.2 S̲w̲i̲t̲c̲h̲ ̲o̲v̲e̲r̲/̲r̲e̲s̲t̲a̲r̲t̲
The TDX-system is assumed not to be powered off. An
important requirement is that the data user traffic
must continue with no disturbtion from the switchover
at all. This leads to an initialization of all connections
between LTUXes and any of the two HOST I/Fs red og
black. The LTUX-LTUX-connections on the black TDX-system
must not be initialized since this will cause a break
in the data user traffic. The files used are:
LCFRJ01, LCFRR01, LCFRT01, LCFRU01, LCFRC01,
LCFRN02, LCFBN03
5.5.3 B̲l̲a̲c̲k̲ ̲R̲e̲c̲o̲n̲f̲i̲g̲u̲r̲a̲t̲i̲o̲n̲
This type of initialization is used in two situations.
If the data user configuration has to be changed or
if the black TDX-system has been powered off (eventually
partly e.g. only one crate) for module exchange. In
both cases the initialization is activated by the DUR
n command where n is the configuration number (1-3).
The BLACK TDX-System is totally reinitialized i.e.
all LTUX-LTUX connections are setup both for message
traffic (between LTUX-CRYPTO/BLACK and LTUX-TRUNKS)
and for data traffic (between LTUX-TRUNKS and LTUX-DATA-USERS
and LTUX-TRUNK - LTUX-TRUNK connections). Also data
route trunk records, data route end records and SIO
setup records are loaded to LTUX-TRUNKS and LTUX-DATA-USERS.
The LTUX-CRYPTO/BLACK is loaded with the message CRYPTO
system conversion tables. New connections are setup
between the BLACK HOST I/F and LTUX-TRUNKS, LTUX-DATA-USERS
and LTUX-NPDN. The connections previously defined
are dismantled by the NSS. The files used are:
LCFBN02, LCFBN03, LCFBN04
5.5.4 N̲P̲D̲N̲ ̲-̲ ̲C̲a̲l̲l̲-̲U̲p̲
This initialization is used when a LTUX-TRUNK has to
be replaced by the LTUX-NPDN. The LTUX-NPDN is initialized
exactly as the LTUX-TRUNK it replaces, both with respect
to inter LTUX-connections concerning message traffic
and those connections concerning data traffic. Also
data route trunk records of actual trunk are loaded.
The connection LTUX-NPDN to BLACK HOST I/F is assumed
to be available. Finally all connections defined for
the original LTUX-TRUNK are closed. This is done to
avoid interference of garbled data from a failed trunk.
Only one file is used, the actual no. depend on the
LTUX-TRUNK to replace. The possible files are:
LCFBN05-LCFBN11
5.5.5 N̲P̲D̲N̲ ̲C̲l̲o̲s̲e̲-̲D̲o̲w̲n̲
This initialization is used when a NPDN connection
is replaced by the original LTUX-TRUNK.
First the connection defined for the LTUX-NPDN is
closed. Next the LTUX-TRUNK is initialized as after
power-off. All LTUX-LTUX connections (both for message
and data traffic) are set up and the connection LTUX-TRUNK
to BLACK HOST I/F is initialized. The old connection
is dismantled by the NSS. Data route trunk records
are loaded.
Only one file is used, the actual no. depend on the
LTUX-TRUNK which is to be used.
The possible files are:
LCFBN12-LCFBN18
