top - download
⟦6557956e1⟧ Wang Wps File
Length: 71471 (0x1172f)
Types: Wang Wps File
Notes: FIX/1000/PSP/038 sec 4.2
Names: »5199A «
Derivation
└─⟦e48583e73⟧ Bits:30006141 8" Wang WCS floppy, CR 0514A
└─ ⟦this⟧ »5199A «
WangText
…00……00……00……00……00…&…0a……00……00…&…0b…&…0e…&…0f…&…05…%…0b…%…0c…%…0d…%…05…%…06…$…0b…$…0c…$…00…$…01…$…05…$…06…#…0a…#…0b…#…01…#…06…"…0b…"…0c…"…0d…"…00…"…01…"…02…"
!…0a…!…0b…!…02… …09… …0f… …01… …02…
…1f……08……1f……0d……1f……02……1f……07……1e……0d……1e… …1d……0a……1d……86…1 …02… …02… …02…
…0f… 5199A/bna…02…FIX/1000/PSP/0038
…02…MLA/850529…02……02…
FIKS SYSTEM SPECIFICATION
…02……02…FK 7809…0e…
4.2 S̲Y̲S̲T̲E̲M̲ ̲C̲O̲N̲T̲R̲O̲L̲ ̲C̲E̲N̲T̲E̲R̲ ̲(̲S̲C̲C̲)̲
The SCC is the system which performs centralized supervision
and control of the overall FIKS network. Two SCC's
are provided to the FIKS network which consists of
8 NODE/MEDEs.
The SCC supports also the interchanges of message traffic
between the FIKS and the NICS-TARE network. Further,
the SCC may perform (off line) S/W maintenance.
The total SCC software package is shown in Figure 4.2.a.
Figure 4.2.a
SCC application subsystems perform the functions allocated
to the on-line SCC. The application software is supported
by a set of FIKS Executive functions that are common
to the NODE/MEDES and the SCC.
The off-line function of the SCC supplies the following
tools for S/W maintenance.
- Assembler
- Source File Editor
- Debugging Program
- Swell Compiler
The use of these facilities are described in the respective
manuals. Further, the functions
- Statistic File Dump Utility
- File Initialization
- System Generation
- Off-line Diagnostic
are supported off-line.
The executive at the SCC is generally equal to the
executive at the NODE/MEDEs with some few modification
and addition which are included in this chapter.
4.2.1 S̲C̲C̲ ̲S̲y̲s̲t̲e̲m̲ ̲O̲v̲e̲r̲v̲i̲e̲w̲ ̲(̲o̲n̲-̲l̲i̲n̲e̲ ̲S̲C̲C̲)̲
The System Control Center (SCC) has two primary functions:
a) Centralized supervision and control of the FIKS
network.
b) Provide message interface between FIKS and NICS-TARE.
The NICS-TARE interface includes routines for message
format conversion from SMF to ACP127 and vice versa.
The conversion routines are also used to convert internal
FIKS messages from ACP127 to SMF format or vice versa.
After conversion these messages asre returned to the
FIKS network.
4.2.1.1 S̲C̲C̲ ̲H̲a̲r̲d̲w̲a̲r̲e̲ ̲O̲v̲e̲r̲v̲i̲e̲w̲
Two SCC hardware systems are included in FIKS:
The two systems are attached to two different NODE/MEDEs,
and they will act as backup for each other.
Therefore, the individual SCC system does not have
dualized equipment.
The SCC is equipped with the following terminals:
A. 3̲ ̲V̲D̲U̲'̲s̲
Used interactively in the on-line mode.
The VDU is of the same type as used at the MEDEs.
The screen is handled as two logically seperate
units where the 3 top lines contain queue status
information. The remaining part of the screen is
operated as a normal VDU screen. In the off-line
mode the VDU is used as an input/output device.
B. R̲e̲c̲e̲i̲v̲e̲ ̲O̲n̲l̲y̲ ̲P̲r̲i̲n̲t̲e̲r̲s̲ ̲(̲R̲O̲P̲)̲
The R.O. teleprinters are electrically connected
to the VDU's. In on-line mode they function as
output devices for the log print and printout requested
as part of a supervisor procedure. In the off-line
mode they act as an alternative output device to
the VDU.
C. A̲u̲d̲i̲o̲ ̲A̲l̲a̲r̲m̲s̲
This is only used on-line for creating an audible
alarm when reports of alarm condition are received
at the SCC.
D. C̲o̲l̲o̲u̲r̲ ̲T̲V̲ ̲M̲o̲n̲i̲t̲o̲r̲
The colour TV monitor is being used to display
the network status. This is only used on-line.
4.2.1.2 S̲C̲C̲ ̲S̲o̲f̲t̲w̲a̲r̲e̲ ̲O̲v̲e̲r̲v̲i̲e̲w̲
The SCC functions are allocated to 5 application subsystems
shown in Figure 4.2.1.2.a.
Figure 4.2.1.2.a
SCC Application Subsystem
Figure 4.2.1.2.b shows the the logical interfaces between
the rest of the FIKS network and the SCC subsystems
and the interrelationship between the SCC subsystem.
The following serves as an explanation to Figure 4.2.1.2.b.
a. T̲h̲e̲ ̲N̲e̲t̲w̲o̲r̲k̲ ̲S̲u̲p̲e̲r̲v̲i̲s̲i̲o̲n̲ ̲a̲n̲d̲ ̲C̲o̲n̲t̲r̲o̲l̲ ̲S̲u̲b̲s̲y̲s̲t̲e̲m̲ ̲(̲N̲S̲C̲)̲
receives and processes control messages from NODE/MEDEs
and the standby SCC. Control messages are printed
on the log printer. Control messages containing
status change information are stored on disc.
The NSC will analyse control message header and
based on the type display an alarm, alert or notice
to the SCC supervisor. The NSC will also update
network starus tables and the colour TV display,
The NSC will communicate interactively with supervisor
VDU's via the Interactive terminal Monitor (not
shown on diagram). The NSC will handle commands
for display of status table information, routing
calculations and creation of network commands.
Outgoing network commands are logged on log printer.
b. N̲e̲t̲w̲o̲r̲k̲ ̲S̲t̲a̲t̲i̲s̲t̲i̲c̲s̲ ̲S̲u̲b̲s̲y̲s̲t̲e̲m̲ ̲(̲N̲E̲S̲)̲
The NES collects and stores statistical reports
from the NODE/MEDE on-line. A 24 hour MEDE statistic
(i.e. message flow statistic) is generated for
each MEDE on supervisor's request and send to the
appropriate MEDE. Statistical datas collected on-line
not belonging to the message flow statistic may
be dumped (on-line) to floppy disc.
c. M̲e̲s̲s̲a̲g̲e̲ ̲S̲e̲r̲v̲i̲c̲e̲ ̲S̲u̲b̲s̲y̲s̲t̲e̲m̲ ̲(̲M̲S̲S̲)̲
The MSS receives narrative SMF messages from the
NODE/MEDEs with NATO Addresses (ANO's). The MSS
converts messages to ACP127 format before transmission
to NICS-TARE. Messages from NICS-TARE are converted
to SMF format before being forwarded to the FIKS
network. The MSS also receives non-NATO messages
from FIKS for conversion from SMF to ACP127 or
vice versa. These messages are returned to the
FIKS originator address after conversion.
Figure 4.2.1.2.b
FIKS System Overview
If a message cannot be processed automatically
by MSS because of problems with conversion or addressing,
this is to be handled by the MSS Intercept function.
d. N̲I̲C̲S̲-̲T̲A̲R̲E̲ ̲S̲u̲b̲s̲y̲s̲t̲e̲m̲ ̲N̲T̲S̲
This subsystem controls the communication with
the NICS-TARE system. This includes the communication
protocol handling (i.e. LITSYNC protocol), the
message transmission and reception.
e. I̲n̲t̲e̲r̲-̲S̲C̲C̲ ̲H̲a̲n̲d̲s̲h̲a̲k̲i̲n̲g̲ ̲S̲u̲b̲s̲y̲s̲t̲e̲m̲ ̲(̲I̲S̲H̲)̲
This subsystem handles the SCC-SCC monitoring and
synchronization. Further, it receives all messages
which are destinated fdor the SCC or the NICS-TARE.
The messages received asre delivered either to
the NSC (control messages) or the MSS (narrative
messages).
4.2.1.3 S̲C̲C̲ ̲E̲x̲t̲e̲r̲n̲a̲l̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲s̲
The SCC has two physical external interfaces, one to
the collocated NODE/MEDE and one to the NICS-TARE.
4.2.1.3.1 S̲C̲C̲ ̲-̲ ̲C̲o̲l̲l̲o̲c̲a̲t̲e̲d̲ ̲N̲/̲M̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲
4.2.1. H̲a̲r̲d̲w̲a̲r̲e̲ ̲I̲/̲F̲
3.1.1
The SCC is attached to the collocated NODE/MEDE via
one LTUX connected to the red TDX bus as shown in Figure
4.2.1.3.1.a.
Figure 4.2.1.3.1.a
Connection SCC-collocated NODE/MEDE
The SCC is attached to the red TDX bus. Data to the
SCC will not be encrypted. The SCC is handled by the
node as another node.
4.2.1. S̲o̲f̲t̲w̲a̲r̲e̲ ̲I̲/̲F̲
3.1.2
The software interface between the collocated NODE/MEDE
and the SCC is implemented via the Nodal Switch Subsystem
(NSS) which implies that the SCC is seen as a node.
The SCC software interfacing to the NSS, i.e. the Inter-SCC
Handshaking subsystem (ISH), is hereby implemented
partly in the collocated N/M and partly in the SCC
processor.
The ISH encloses a number of functions, which are implemented
as a SCC Interface Process (SIP) at the collocated
NODE/MEDE and as a collocated N/M Interface Process
(CIP) at the SCC.
The logical Interface is illustrated in Figure 4.2.1.3.1.b
and the functional Interface is illustrated in Figure
4.2.1.3.1.c. The message interface flows are as follows:
Figure 4.2.1.3.1.b
Logical Connection SCC - Collocated NODE/MEDE
N̲S̲S̲ ̲-̲ ̲S̲I̲P̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲
When the SCC processor is off-line, i.e. the link between
the collocated NODE/MEDE and the SCC is inactive, the
NSS at the collocated NODE/MEDE sees the SIP as the
SCC.
The NSS will in this case deliver all messages having
SCC or NICS-TARE as destination to the SIP. In the
case where the SCC processor is on-line, i.e. the link
between the collocated NODE/MEDE and the SCC is active,
the SIP is used as an addressable element in the network
for the purpose of supporting the SCC initialization
at start-up and restart. Based upon this, the NSS interfaces
to the SCC via the SIP. Figure 4.2.1.3.1.c illustrates
that the collocated MEDE interfaces through the NSS
interface.
Figure 4.2.1.3.1.c
NSS (collocated N/M) - SIP (SCC) Interface
A: N̲a̲r̲r̲a̲t̲i̲v̲e̲ ̲M̲e̲s̲s̲a̲g̲e̲ ̲F̲l̲o̲w̲
As seen on Figure 4.2.1.3.1.d, the narrative messages
exchanged between the SCC(CIP) and the FIKS network
are controlled by the Active SIP.
I: S̲I̲P̲ ̲Q̲u̲e̲u̲e̲s̲
Narrative messages destinated for the SCC are
routed to both SIP's (1). The SIP enqueues
the message in a local SIP queue (2). The messages
(bound for SCC) are sent to the SCC one-by-one
(3), (7), but kept in the SIP queue until the
message is either successfully transmitted
to NICS-TARE, or the converted message is safely
back in the FIKS network, or the message is
enqueued for intercept. When a message is removed
from the Active SIP queue, an Acknowledge is
sent to the stand-by SIP(4) in order to synchronize
the two SIP queues.
Figure 4.2.1.3.1.d
Functional Narrative Message Flow
II: I̲n̲t̲e̲r̲n̲a̲l̲ ̲C̲o̲n̲v̲e̲r̲s̲i̲o̲n̲ ̲F̲u̲n̲c̲t̲i̲o̲n̲
Messages for conversion are received by CIP
(7) and sent to the conversion module (8).
I̲F̲ ̲C̲O̲N̲V̲E̲R̲S̲I̲O̲N̲ ̲I̲S̲ ̲O̲K̲:
The conversion module sends the converted message
back to CIP (9), which sends the message to
distribution on the FIKS network with a copy
to SIP (5).
The converted message, received by SIP, is
acknowledged (ACK5) (the SIP discards all received
copies (5), after ACK5 is sent).
CIP being the module knowing the correlation
between the original message (7) and the converted
message (5) now sends an acknowledge to SIP
(ACK7) in order for the SIP to delete the original
message from the SIP queue.
I̲F̲ ̲C̲O̲N̲V̲E̲R̲S̲I̲O̲N̲ ̲E̲R̲R̲O̲R̲:
The conversion module queues the original message
to the Intercept Queue (IQ) (13) and checkpoints
the MTCB in IQ.
An acknowledge on the original message is sent
to CIP (ACK13) which is used directly to acknowledge
the original in the SIP queue (ACK7).
A̲F̲T̲E̲R̲ ̲C̲O̲R̲R̲E̲C̲T̲E̲D̲ ̲C̲O̲N̲V̲E̲R̲S̲I̲O̲N̲ ̲E̲R̲R̲O̲R̲:
The original (but corrected) message is sent
back for conversion (14) without removing it
from IQ. Unless a second conversion error occurs,
the converted message is sent back to CIP (9)
and FIKS/SIP (5). The SIP acknowledges the
converted message (ACK5) and CIP (knowing the
origin) uses the acknowledge to delete the
original from the checkpointed IQ (ACK14).
III: N̲I̲C̲S̲-̲T̲A̲R̲E̲ ̲M̲e̲s̲s̲a̲g̲e̲ ̲F̲u̲n̲c̲t̲i̲o̲n̲ ̲O̲u̲t̲g̲o̲i̲n̲g̲
The outgoing NICS-TARE message is received
by CIP (7) and sent for conversion-transmission
to the NICS-TARE network (10).
I̲F̲ ̲C̲O̲R̲R̲E̲C̲T̲ ̲C̲O̲N̲V̲E̲R̲S̲I̲O̲N̲-̲T̲R̲A̲N̲S̲M̲I̲S̲S̲I̲O̲N̲:
The NT message function queues the original
outgoing NICS-TARE message to IQ and checkpoints
the MTCB. An acknowledge (ACK10), (ACK7) is,
like in the previous case, sent to release
the message from the SIP queue.
A̲F̲T̲E̲R̲ ̲C̲O̲R̲R̲E̲C̲T̲E̲D̲ ̲E̲R̲R̲O̲R̲ ̲I̲N̲ ̲O̲U̲T̲B̲O̲U̲N̲D̲ ̲M̲E̲S̲S̲A̲G̲E̲:
The NT message function gets a copy of the
corrected message fdrom IQ (14). After successful
conversion-transmission an acknowledge is,
as in the two other cases, sent back to CIP
(ACK10).
CIP, reading the origin of the message in the
MTCB, uses this acknowledge to release the
original message from IQ (ACK14).
IV: N̲I̲C̲S̲-̲T̲A̲R̲E̲ ̲M̲e̲s̲s̲a̲g̲e̲ ̲F̲u̲n̲c̲t̲i̲o̲n̲ ̲I̲n̲c̲o̲m̲i̲n̲g̲
All messages received from NICS-TARE are queued
and checkpointed in NT-INQ (12).
I̲F̲ ̲C̲O̲N̲V̲E̲R̲S̲I̲O̲N̲ ̲T̲O̲ ̲S̲M̲F̲ ̲I̲S̲ ̲O̲K̲:
The SMF message is sent to CIP (11) for distribution
and to FIKS network with a copy to SIP (5).
SIP sends back an acknowledge (ACK5).
CIP uses this acknowledge to release the message
from NT-INQ (ACK11).
I̲F̲ ̲C̲O̲N̲V̲E̲R̲S̲I̲O̲N̲ ̲T̲O̲ ̲S̲M̲F̲ ̲F̲A̲I̲L̲S̲:
the NT message function will, if conversion
errors, store a copy of the received message
in IQ and checkpoint the MTCB.
An acknowledge on the intercepted message,
still present in NT-INQ, is sent to CIP (ACK15)
for the CIP to release the message from NT-INQ
(ACK11).
A̲F̲T̲E̲R̲ ̲C̲O̲R̲R̲E̲C̲T̲E̲D̲ ̲E̲R̲R̲O̲R̲ ̲I̲N̲ ̲I̲N̲B̲O̲U̲N̲D̲ ̲M̲E̲S̲S̲A̲G̲E̲:
The corrected source message is copied from
IQ to NT message function (14) and again stored
in NT-INQ without being checkpointed.
After successful conversion to SMF, the message
is sent to CIP (11), with a parameter in the
MTCB telling CIP that the message source is
checkpointed in IQ and not NT-INQ.
The same parameter is sent with the message
to SIP (5) and comes back in the acknowledge
(ACK5). This enables CIP to release the original
still stored in IQ (ACK14).
B: C̲o̲n̲t̲r̲o̲l̲ ̲M̲e̲s̲s̲a̲g̲e̲ ̲F̲l̲o̲w̲
The flow of the different control messages are
illustrated in Figure 4.2.1.3.1.e to g.
Figure 4.2.1.3.1.e
Control Message Control from NODE/MEDE(s) to SCC
Figure 4.2.1.3.1.f
Control Message Flow from SCC to NODE/MEDE
L̲e̲g̲e̲n̲d̲ ̲f̲o̲r̲ ̲F̲i̲g̲u̲r̲e̲ ̲4̲.̲2̲.̲1̲.̲3̲.̲1̲.̲g̲
1) Control message created by the NSC.
2) The message is written to the TSF.
3) And the message is enqueued in the NSS input queue
(transport queue).
4) The message is transported to the collocated NODE/MEDE.
5) The message is transported to the standby SCC's
collocated NODE/MEDE.
6) If the SCC processor is not on-line (i.e. the link
is inactive) the message is intercepted.
7) The message is transported to the SCC and
8) The message is enqueued at the CIP queue.
9) The CIP detect that it is a control message and
deliver to the NSC.
10) The NSC reads the message and displays the alarm,
alert or notice.
Figure 4.2.1.3.1.g
Control Message Flow from Active to Stand-by SCC
4.2.1.3.2 S̲C̲C̲ ̲-̲ ̲N̲I̲C̲S̲-̲T̲A̲R̲E̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲
The physical interface to NICS-TARE is shown below:
Figure 4.2.1.3.b
Connection SCC-Remote Tare
Seen from NICS-TARE the SCC behaves like a Medium Speed
Message User Terminal (MSUT).
The software interface is implemented via the LITSYNC
protocol and a LTU driver.
4.2.1.4 G̲e̲o̲g̲r̲a̲p̲h̲i̲c̲a̲l̲ ̲B̲a̲c̲k̲-̲u̲p̲
As seen on Figure 4.2.1.4-1 the Active SCC (connected
to NODE/MEDE K) is backed up by a stand-by SCC (connected
at NODE/MEDE E).
The active/stand-by states can be reversed as described
in Section 4.2.1.4.3/4. Disregarding the state of the
SCC's, the FIKS NETWORK AND NODE/MEDE E and K always
send control messages to both SCC's C1 and C2.
Narrative messages are always sent to the two SIP's
S and Z (N1).
The SIP will be either in a stand-by or active state
and process accordingly as described in the Sections
4.2.1.4.1/2.
The two SIP's communicate continuously by means of
"keep alive" control messages (K2). The CIP's and the
SIP's communicate continuously by means of "keep alive"
control messages (K1), (K3).
The "keep alive" messages are used to inform each other
(SIP/CIP) about the state of the SIP/CIP sending the
message. The SIP and CIP can be in one of the two states:
active or stand-by.
An internal state/event logic in each SIP/CIP is responsible
in maintaining a stable state where one set SIP-CIP
is active and one set SIP-CIP is stand-by.
The transition from stand-by to active or reverse,
can only be activated by operator commands (01), (02)
(see Section 4.2.1.4.3), or system failures in one
of the SCC's or one of the SIP-NODE/MEDE (see Section
4.2.1.4.4).
The "keep alive" messages are also used for transfer
of SCC status and NICS-TARE link status from one SCC
to another SCC and vise versa.
Figure 4.2.1.4-1
SCC Back-up Functions
4.2.1.4.1 A̲c̲t̲i̲v̲e̲ ̲S̲C̲C̲ ̲F̲u̲n̲c̲t̲i̲o̲n̲s̲
A: N̲a̲r̲r̲a̲t̲i̲v̲e̲ ̲M̲e̲s̲s̲a̲g̲e̲ ̲P̲r̲o̲c̲e̲s̲s̲i̲n̲g̲
Narrative messages received by SIP(Z) are stored
locally and sent to the active CIP(Q) one by one
(N2). The messages sare sent to NICS-TARE (N3),
(N4) or converted (N3), (N6) and returned for distribution
on the Fiks network (N7) and (N8).
The active SIP sends acknowledges (A1) on previously
received messages (N1), when they are processed
and safely back in the Fiks network.
Messages coming in from NICS-TARE (N5), (N6) are
also distributed to the Fiks network (N7), (N8).
See Section 4.2.1.3.1.1 for a detailed description
on narrative message handling between collocated
NODE/MEDE and SCC.
B: C̲o̲n̲t̲r̲o̲l̲ ̲M̲e̲s̲s̲a̲g̲e̲ ̲P̲r̲o̲c̲e̲s̲s̲i̲n̲g̲
Control messages received by collocated NODE/MEDE
(C1) are directly rerouted to CIP(C2) and sent
for processing at the active SCC(C3). Network control
messages generated at the active SCC (O1), (C4)
are distributed directly to the Fiks network (C5),
(C6). Network status is displayed for operator
(01).
4.2.1.4.2 S̲t̲a̲n̲d̲-̲b̲y̲ ̲S̲C̲C̲ ̲F̲u̲n̲c̲t̲i̲o̲n̲s̲
A: N̲a̲r̲r̲a̲t̲i̲v̲e̲ ̲M̲e̲s̲s̲a̲g̲e̲ ̲P̲r̲o̲c̲e̲s̲s̲i̲n̲g̲
Narrative messages received by SIP(S) (N1), are
all stored locally, and released again based upon
the acknowledges received from the active SIP(A1).
This enables the stand-by SIP to maintain a message
queue (as found at the stand-by SIP), which is
always ready for a transition to active state.
B: C̲o̲n̲t̲r̲o̲l̲ ̲M̲e̲s̲s̲a̲g̲e̲ ̲P̲r̲o̲c̲e̲s̲s̲i̲n̲g̲
All control messages sent to the stand-by SCC (C1),
(C2), are queued to the network supervision function
(C3), where the messages are processed and network
status is displayed for operator. The operator
at the stand-by SCC cannot send any network control
messages.
4.2.1.4.3 C̲o̲n̲t̲r̲o̲l̲l̲e̲d̲ ̲S̲w̲i̲t̲c̲h̲o̲v̲e̲r̲
A controlled switchover can only be initiated from
the active SCC operator, which enters a command requesting
to go from active to stand-by. This request is by means
of the "keep alive" messages K1, K2, K3 transferred
to the stand-by SCC where it results in a "go active"
message to be printed to the operator.
Only if the operator at the stand-by SCC enters a command,
accepting to go from stand-by to active, will the SIP/CIP
state logic execute the transition, open the narrative
message function at the new active SCC and close the
function at the old active SCC.
4.2.1.4.4 E̲m̲e̲r̲g̲e̲n̲c̲y̲ ̲S̲w̲i̲t̲c̲h̲o̲v̲e̲r̲
A switchover is performed automatically if the stand-by
SIP/CIP state logic experiences problems in the active
SIP/CIP.
The switchover is initiated if "keep alive" messages
from the active SIP/CIP is missing or the status reported
unexpectedly changes from active to stand-by.
The operator at the stand-by SCC experiences an emergency
switchover the same way as a controlled switchover
(by a "go active" printout).
Only the network status displayed, will enable the
operator to see the reason for the "go active" message.
Only after the operator enters a command to go from
stand-by to active, will the stand-by SIP/CIP change
to active state and process messages accordingly.
4.2.1.4.5 S̲t̲a̲r̲t̲-̲u̲p̲
After a boot start of CIP (SCC start/restart) and SIP
(NODE/MEDE, start/switchover), both programs execute
in the stand-by state.
A: M̲i̲s̲s̲i̲n̲g̲ ̲"̲K̲e̲e̲p̲ ̲A̲l̲i̲v̲e̲"̲ ̲M̲e̲s̲s̲a̲g̲e̲s̲
If "keep alive" message is not received from the
"other" SIP/CIP within a certain time limit, then
a "go active" message is sent to the operator.
B: "̲K̲e̲e̲p̲ ̲A̲l̲i̲v̲e̲"̲ ̲M̲e̲s̲s̲a̲g̲e̲ ̲w̲i̲t̲h̲ ̲S̲t̲a̲n̲d̲-̲b̲y̲ ̲S̲t̲a̲t̲u̲s̲
If "keep alive" messages are received but the messages
report that the "other" SIP/CIP is stand-by, then
a "go active" command is sent to the operator.
C: "̲K̲e̲e̲p̲ ̲A̲l̲i̲v̲e̲"̲ ̲M̲e̲s̲s̲a̲g̲e̲ ̲w̲i̲t̲h̲ ̲A̲c̲t̲i̲v̲e̲ ̲S̲t̲a̲t̲u̲s̲
If "keep alive" messages are received and an active
status is reported from the "other" SIP/CIP, then
the stand-by state is maintained.
4.2.1.4.6 N̲a̲r̲r̲a̲t̲i̲v̲e̲ ̲M̲e̲s̲s̲a̲g̲e̲ ̲S̲e̲r̲v̲i̲c̲e̲ ̲C̲o̲n̲t̲r̲o̲l̲
The narrative message functions at the SCC can be categorized
as follows:
I: Internal Conversion
II: NICS-TARE Outgoing
III: NICS-TARE Incoming
The internal conversion and NICS-TARE outgoing message
traffic is controlled by the active SIP. The service
is opened when the SCC state changes from stand-by
to active, and closed when the SCC state changes from
active to stand-by.
The incoming NICS-TARE message traffic is closed/opened
with a NICS-TARE link close/open command, issued by
the operator.
Messages received from NICS-TARE (link open), when
the SCC is in stand-by mode (message service closed),
is queued to the intercept queue and checkpointed.
4.2.1.5 C̲o̲n̲t̲r̲o̲l̲ ̲M̲e̲s̲s̲a̲g̲e̲ ̲C̲h̲a̲r̲a̲c̲t̲e̲r̲i̲s̲t̲i̲c̲s̲
Control messages are short messages exchanged between
a) SCC and the nodes
b) SCC and the MEDEs
c) The two SCC's
The purpose of the messages is to carry controlling
and monitoring information.
4.2.1.5.1 F̲o̲r̲m̲a̲t̲
The transmission format of control messages is as shown
in Figure 4.2.1.5.1-1.
Figure 4.2.1.5.1-1
Transmission Format of Control Messages
The routing header contains information used by routing
of the message through the network.
The control message contains as a standard the fields
shown in the figure overleaf.
WORD* BYTE*
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
0 NODE-TO-NODE Res by NSS
1 0
SERIAL NO.
1 Res.by NSS MAIN PRECEDENCE
3 2
TYPE
2 j i n g f e d c b d ORBIT
5 4
R O U T I N G COUNTER
3 t y x w v u t s r q p o n m l k
7 6
M A S K
4 MESSAGE LENGTH
9 8
(no. of bytes)
5 CATEGORY TYPE
11 10
6 spare ORIGINATOR
13 12
7
15 14
8 DATE TIME GROUP
17 16
CONTROL INFORMATION
Control Message
other than ACK/NACK
The precedence code in the routing header is used for
routing through the network, which means used for appropriate
queuing by the nodal switch subsystem. Based on the
type the receiving subsystem, Network Supervision and
Control, will queue the message as an alarm, alert,
notice hourly report or statistic report to the supervisor.
4.2.1.5.2 P̲r̲e̲c̲e̲d̲e̲n̲c̲e̲
Control messages fall into three precedence groups:
Group a: Special precedence above flash (S)
This precedence is reserved for the NSS
subsystem.
Group b: Flash precedence (Z)
To this group belong all control messages
carrying:
- SCC/SCC control messages
- Node failure reports
- Routing tables
- Crypto failure alerts
- N/M out/in operation alert
- Switchover/Recovery N/M alerts
- Trunk error rate exceeded report
- Table updates (USP)
- Data user route change
- NPDN status change report
- Orbiting message report
- Trunk alarms
Group c: Normal (Routine) precedence (R)
Normal precedence levels are used for less
time urgent control message aa:
- Hourly reports
- Statistical reports
- Less important status changes
- Diagnostic
- Message orbiting report
- Network command from SCC (e.g. open/close
trunk)
- Table updates (USP/RDF)
4.2.1.5.3 C̲o̲n̲t̲r̲o̲l̲ ̲M̲e̲s̲s̲a̲g̲e̲ ̲C̲r̲e̲a̲t̲i̲o̲n̲
A control message will always be created either by
a supervisory function subsystem SFS in MEDE, by the
nodal switch subsystem in a node or at the System Control
Center (SCC). The destination of a control message
will be one of the three subsystems.
4.2.1.5.4 C̲r̲e̲a̲t̲i̲o̲n̲ ̲a̲t̲ ̲N̲O̲D̲E̲/̲M̲E̲D̲E̲s̲
A control message may be created based on an event,
internal timer interrupt or a supervisor command.
Event initiated control message:
a) Equipment errors
b) Status changes
c) Diagnostic result as response to SCC on request
for on-line diagnostic
d) Table up-date report
Timer initiated control messages:
a) Periodic statistical summary to SCC
b) Periodic status report to SCC (hourly reports)
4.2.1.5.5 C̲r̲e̲a̲t̲i̲o̲n̲ ̲a̲t̲ ̲S̲C̲C̲'̲s̲
While the primary message creation at NODE/MEDE are
event initiated status and error messages, the primary
message creation at the active SCC is supervisor initiated
network commands.
Yet the above mentioned categories of initiation also
exist in the SCC.
Timer initiated control message.
a) Stand-by SCC keep alive messages (periodically)
Supervisor initiated control messages:
a) Network commands
b) N/M table up-date
c) Request to N/M for status report return
d) SCC to SCC transition control
4.2.1.5.6 C̲o̲n̲t̲r̲o̲l̲ ̲M̲e̲s̲s̲a̲g̲e̲ ̲F̲l̲o̲w̲
Control messages may flow:
a) Between a node and the SCC:
The NSS at a node creates a control message and
enqueues it in its own queue for outgoing messages.
The destination of the control message is the SCC,
i.e. the ISH-CIP.
The control message is destined for both SCC's.
The the SCC the ISH detects that the message is
a control message and delivers the message to the
NSC via the CM queue (Control Message queue).
The action taken on the message depends on the
control message type and includes:
1. Display of the Alarm/Alert/Notice on the SCC
supervisor VDU and if the message reports an
Alarm, display it on the TV-DISPLAY and activation
of the Audible alarm.
2. Logging on log printer
3. Routing table up-date
4. Storage of statistical data
5. Up-date of the Network Status File (NSF)
b) Between a MEDE and the SCC:
The flow of a control message between a MEDE and
the SCC is executed in the same way as between
the node and the SCC with the following exception:
- The control message is created by the SFS which
enqueues the message in the NSS queue fdor
outgoing messages.
The action taken by the SCC (NSC) on control messages
from a MEDE (SFS) depends on the type of the control
message and includes:
1. Display of the Alarm/Alert/Notice on the SCC
Supervisor VDU and if the message reports a
status change of a N/M, display it on the TV-DISPLAY
and activate the Audible Alarm.
2. Logging on log printer
3. Storage of statistical data.
c) Between the two SCC's:
The SCC (NSC) creates a control message and enqueues
it at the NSS (at the SCC) queue for outgoing messages.
The NSS transports it to the SCC where it is delivered
to the CIP. The CIP now deliver the message to
the NSC. Keep alive messages between the SCC's
are solely handled by the CIP, crested and processed,
which implies that the SCC-SCC protocol is handled
by the CIP.
4.2.1.6 R̲e̲s̲t̲a̲r̲t̲/̲R̲e̲c̲o̲v̲e̲r̲y̲
In order to be able to restart the SCC after an off-line
session or an emergency close-down, all MTCB's describing
narrative message data only existing at the SCC are
written into an MTCB-checkpoint file.
At SCC system build time the MTCB-checkpoint file is
created to be able to contain all MTCB's in the MTCB
pool. Any time a narrative message is found only to
exist the SCC, the MTCB associated with the message,
is written into the checkpoint file and the entry used
in the file will be set in an active state. When the
message has left the SCC, then the active MTCB in the
checkpoint file is set inactive. Messages residing
at the SIP is not checkpointed.
At SCC start-up time (initially start-up or after off-line
or emergency shut-down) the MTCB checkpoint file is
searched for active MTCB's.
All active MTCB entries will be read and used to reestablish
the MTCB queues describing the narrative messages residing
at the SCC (IQ, CQ1) in order to be able to restart
message processing from the start of any message residing
in the SCC of the time of SCC close-down. Messages
residing at SIP at collocated N/M are retransmitted
to SCC at restart time.
4.2.1.7 E̲x̲e̲c̲u̲t̲i̲v̲e̲ ̲S̲o̲f̲t̲w̲a̲r̲e̲
The on-line software common to all subsystems at the
SCC includes the following: (CR80 AMOS excluded)
- Interactive Terminal Monitor (ITM)
- MTCB Monitor
- QACCESS Monitor
- TV-Monitor Handler
which are described in the following sections.
4.2.1.7.1 I̲n̲t̲e̲r̲a̲c̲t̲i̲v̲e̲ ̲T̲e̲r̲m̲i̲n̲a̲l̲ ̲M̲o̲n̲i̲t̲o̲r̲
The Interactive Terminal Monitor (ITM) at the SCC is
the same as used at the NODE/MEDEs with the following
few modifications:
- The ITM executes the Interactive part of the NSC,
NES and the MSS.
- The ITM executes only commands related to the functions
covered by these subsystems.
- The NODE/MEDE supervisor function (i.e. block terminal
etc.) are not implemented.
- The queue status line display displays only the
following (common) queues:
- Conversion Queue(CQ). The queue contains the
number of messages queued for conversion.
- NICS-TARE Queue (NT). The queue contains the
number of messages queued for NICS-TARE.
- NODE/MEDE Queue (NM). The queue contains the
number of messages queued for the FIKS network.
- Alarm/Alert/Notice Queue (AL). The queue contains
the number of Alarms/Alert/Notice queued for
the Supervisor/Supervisor assistant.
- Line Printer Queue (LP). The queue contains
the number of messages which are queued for
printing (LOG, REP or AUX).
- Intercept Queue (IC). The queue contains the
number of messages queued for Intercept.
- By terminal input error the ITM (only) displays
an error and return to PROC level.
- No checkpointing.
No recovery function is supported which implies
that terminals will, after a restart, have logged-off
status.
4.2.1.7.2 M̲T̲C̲B̲ ̲M̲o̲n̲i̲t̲o̲r̲
The MTCB monitor used at the NODE/MEDEs described in
sec. 4.3.2 is also implemented at the SCC's. Hereby
it is used to support the communication between the
SCC subsystems. The files referenced by a MTCB are
the IMF, TSF, SMF or the AMF.
4.2.1.7.3 Q̲A̲C̲C̲E̲S̲S̲ ̲(̲a̲t̲ ̲t̲h̲e̲ ̲S̲C̲C̲)̲
The QACCESS monitor at the SCC is the same as used
at the NODE/MEDEs described in sec. 4.3.1 but only
the SCC queues are supported.
4.2.1.7.4 T̲V̲-̲M̲o̲n̲i̲t̲o̲r̲ ̲H̲a̲n̲d̲l̲e̲r̲
The TV-monitor handler supports output on the colour
TV-monitor.
The handler will hereby have a network graph pre-described
in form of element descxriptors. An element descriptor
describes an element which may be
- A trunk
- A NODE/MEDE
- A N/T link
- A SCC
The element descriptors are used by TV-monitor updates
together with a colour code to identify a status change.
The network graph is illustrated overleaf:
TV Screen Layout
FIKS Net Work Status
4.2.1.8 S̲C̲C̲ ̲O̲f̲f̲-̲l̲i̲n̲e̲ ̲F̲u̲n̲c̲t̲i̲o̲n̲
The off-line software at the SCC includes the following:
(CR80 AMOS and CR80 system utilities excluded).
- Off-line statistic's
- File initialization
- FIKS system generation
- Off-line diagnostic
4.2.1.8.1 O̲f̲f̲-̲l̲i̲n̲e̲ ̲S̲t̲a̲t̲i̲s̲t̲i̲c̲
The off-line operator may activate a procedure to dump
the statistical file fdrom sloppy disc to mass storage.
4.2.1.8.2 F̲i̲l̲e̲ ̲I̲n̲i̲t̲i̲a̲l̲i̲z̲a̲t̲i̲o̲n̲
All files containing initial data are initialized at
the SCC.
Generally files are first initialized at the SMD disc
from where they are copied to a floppy disc. The floppy
disc are then to be used by a NODE/MEDE site generation
or an SCC system generation.
Generation of files are executed by the following modules:
- RDF(Routing Directory File) generation module,
which generates the RDF common to all NODE/MEDEs
and SCC's.
- NDF (Nodal Data File) generation module, which
generates the NDF. The NDF file is NODE/MEDE specific.
- TMF (Test Mask File) generation module, which generates
the TMF. The TMF file is NODE/MEDE specific.
- USP (User Security Profile) generation module,
which generates the USP file. By generation of
this NODE/MEDE specific file, the SCC Supervisor
Security Profile (SSP) file is automatically generated.
The SSP is generated as an extract of the USP's.
- ADF (Address File) generation module, which generates
the ADF. The ADF is SCC specific.
- NSF (Network Status File) generation module, which
generates the NSF. The NSF is SCC specific.
4.2.1.8.3 F̲I̲K̲S̲ ̲S̲y̲s̲t̲e̲m̲ ̲G̲e̲n̲e̲r̲a̲t̲i̲o̲n̲
A System Generation (SYSGEN) takes place on the SMD
disc at the SCC. The generated system is for each NODE/MEDE
and SCC is copied to floppy disc's and then distributed
to the appropriate NODE/MEDEs and SCC's for site generation.
4.2.1.8.4 O̲f̲f̲-̲l̲i̲n̲e̲ ̲D̲i̲a̲g̲n̲o̲s̲t̲i̲c̲
The off-line diagnostic program is able to detect fault
by checking of equipment modules and by analysis of
test results, which isolate fault to replaceable hardware
module.
The off-line Maintenance and Diagnostics (M+D) program
contains the following submodules:
Central Processing Unit Test (CPU), Random Memory Test
disc test and a simple functional test of TDX bus communication.
The off-line diagnostics programs are controlled from
a KSR ACCII terminal connected to the SCM module.
4.2.2 N̲e̲t̲w̲o̲r̲k̲ ̲S̲u̲p̲e̲r̲v̲i̲s̲i̲o̲n̲ ̲a̲n̲d̲ ̲C̲o̲n̲t̲r̲o̲l̲ ̲S̲u̲b̲s̲y̲s̲t̲e̲m̲
4.2.2.1 F̲u̲n̲c̲t̲i̲o̲n̲
The NSC subsystem implements those functions which
help the active SCC supervisor to execute network supervision
and control.
The following functions are recognized:
- Incoming Message Processing.
From FIKS NODE/MEDEs monitoring information is
received and treated about errors, status changes
and statistical record.
- Network Commanding.
To the FIKS network commanding is forwarded to
initiate change of network status or on-line diagnostics.
- Routing Table Handling.
Calculation and distribution of new routing tables
to the FIKS network.
- File Handling.
Up-date and distribution of updates of the Address-
and Security files to the FIKS MEDEs.
- SCC Control.
By local SCC control as will as control of the
remote SCC by switchover from the active to the
stand-by SCC.
- Print Handling.
Print of log information and print of output which
is requested as a part of a supervisor procedure
on one of the VDU connected RO printer.
- Initialization.
Initialization of the network status file and initialization
of the TV-display.
4.2.2.2 S̲u̲b̲s̲y̲s̲t̲e̲m̲ ̲B̲l̲o̲c̲k̲ ̲D̲i̲a̲g̲r̲a̲m̲
Figure 4.2.2.2-1 illustrates the flow of the data and
control for each NSC function.
a) Incoming Message Processing.
1. Message is transported from the collocated
NODE/MEDE to the SCC.
2. The CIP enqueues the message at the NSC input
queue.
3. The NSC treats the incoming message and
4. enqueue the message for logging and if Alarm/Alert
flag the condition on the supervision terminal
and eventually creates audible alarm and up-date
the status of the TV-monitor.
5. If status change up-date of network status
table.
b) Network Commanding.
1. Enter the supervision procedure to enter a
network command.
2. NSC processes the command based on command
table and event.
2a. Delay table up-date.
3. The command is queued for logging
4. and written to the disc (as control message).
5. The command is enqueued (Nn queue).
c) Routing Table Calculation.
1. Enter supervisor command for up-dating the
delay table.
2. The NSC uses the delay table for calculation
of new routing tables.
3. The routing tables are up-dated and the event
is queued for logging.
4. The message is written on the disc and enqueued
in the NM queue.
d) File Handling.
1. Entering of supervision command for up-date
of the file.
2. File up-date.
3. The up-date is queued for logging.
4. The message is written on the disc and enqueued
in the NM queue.
e) Print Handling.
1. The NSC enqueues by means of QACCES a message
to be printed to one of the print queues, i.e.
Alarm/Alert/Notice, LP1, LP2, LP3 queues.
2. The HSP dequeues the message and read the message
to be printed from disc and format it.
3. The message is printed.
f) Initialization.
1. Load system tables network status table.
2. Initialize the TV-display.
3. Log event.
Figure 4.2.2.2-1a
Network Commanding. Block Diagram
Figure 4.2.2.2-1b
File Handling. Block Diagram
Figure 4.2.2.2-1c
Print Handling. Block Diagram
Figure 4.2.2.2-1d
Initialization. Block Diagram
4.2.2.3 D̲e̲s̲i̲g̲n̲ ̲O̲v̲e̲r̲v̲i̲e̲w̲
The function covered in the NSC subsystem are communicating
interactive to the supervisors and non-interactive
network monitoring.
The non-interactive network monitoring is only implementing:
- Incoming message processing
- SCC control message processing
- Routing table calculations
- Print handling
- File Handling
The interactive communication is designed to execute
under control of the Interactive Terminal Monitor (TEPINT).
The interactive functions cover:
- Network command
- Table up-date
- File handling
- SCC control (SCC switchover)
- Routing table calculation
4.2.2.3.1 I̲n̲c̲o̲m̲i̲n̲g̲ ̲C̲o̲n̲t̲r̲o̲l̲ ̲M̲e̲s̲s̲a̲g̲e̲ ̲P̲r̲o̲c̲e̲s̲s̲i̲n̲g̲
Incoming control messages are messages coming from
the NODE/MEDEs or the SCC. The message carrying:
- Report (from the NODE/MEDEs)
- Statistic (from the NODE/MEDEs)
- Keep alive messages (from the stand-by SCC)
- Messages related to a SCC mode change
R̲e̲p̲o̲r̲t̲
Reports are messages sent from the NODE/MEDEs. They
are sent immediately on the event described in the
control message. The message will result in an action
at the SCC. The action depends on the type as described
in the following:
T̲y̲p̲e̲ ̲ ̲ ̲ ̲^̲ ̲ ̲ ̲A̲c̲t̲i̲o̲n̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲
^
Alarm ^ a. Set audible alarm
^ b. Display on supervisor VDU
^ c. Display on Colour TV Display
^ d. Print on log printer.
^
Alert ^ a. Display on Supervisor assistant VDU
^ b. Print on log printers
^
Notice ^ a. Print on log printer.
Network status change information will automatically
cause up-date of the network status table.
S̲t̲a̲t̲i̲s̲t̲i̲c̲s̲
The statistics (delivered once an hour) will be delivered
to the NES. Before delivery, a notification is written
to the log-printer.
S̲w̲i̲t̲c̲h̲o̲v̲e̲r̲ ̲R̲e̲q̲u̲e̲s̲t̲
This message, which is received by the stand-by SCC,
causes a notification to be printed and the horn to
sound. The stand-by SCC may now enter interactively
a command to change his status from stand-by to active.
This causes that an acknowledgemnet is sent to the
requesting SCC.
4.2.2.3.2 N̲e̲t̲w̲o̲r̲k̲ ̲C̲o̲m̲m̲a̲n̲d̲i̲n̲g̲
The network commanding creates a command for the network
which causes some kind of status change in one or more
NODE/MEDE. The commands may be:
- Open/close trunk
- Set trunk queue threshold
- Change data user from secondary path to primary
path
- Set retransmission rate on a trunk
or it may be a request for on-line diagnostic.
4.2.2.3.3 R̲o̲u̲t̲i̲n̲g̲ ̲T̲a̲b̲l̲e̲ ̲C̲a̲l̲c̲u̲l̲a̲t̲i̲o̲n̲
The calculation of the routing tables for the FIKS
network takes place on the basis of a delay table.
A delay table is a table containing the delayes, i.e.
the time used, for message transmission from one node
to another.
The f̲e̲a̲s̲i̲b̲l̲e̲ ̲r̲o̲u̲t̲e̲s̲ depend of course on the current
network to̲p̲o̲l̲o̲g̲y̲, i.e. on the available n̲o̲d̲e̲s̲ ̲a̲n̲d̲ ̲t̲r̲u̲n̲k̲s̲.
The connectivity of a route depends on the d̲e̲l̲a̲y̲ of
nodes and trunks; for a node or trunk not available
the delay may be set to infinite.
Consequently to calculate the connectivity it is necessary
to know the delay per node per trunk.
A n̲o̲d̲e̲ ̲i̲s̲ ̲n̲o̲t̲ ̲a̲v̲a̲i̲l̲a̲b̲l̲e̲ (the nodal delay is infinite
large), when:
- its own queue exceeds an upper limit, to avoid
congestion. The node is available when the queue
is shorter than some lower limit. There must be
some hysteresis to avoid oscillations.
- its neighbour nodes do not receive any reply in
the node-to-node message control.
- It is set out of service by the SCC supervisor
and it will be available when put into service
by the supervisor.
- any of its nodes do not declare the trunk for open
- any of its nodes do not detect the power or the
carrier. It is available when both nodes detect
the power and the carrier.
A t̲r̲u̲n̲k̲ ̲i̲s̲ ̲n̲o̲t̲ ̲a̲v̲a̲i̲l̲a̲b̲l̲e̲ (the transmission time is
infinite large), when:
- any of its nodes detect too many retransmissions.
It is available when put into service by the SCC
supervisor.
- taken out of service by the SCC supervisor.
The information about the availability of nodes and
trunks is sent by c̲o̲n̲t̲r̲o̲l̲ ̲m̲e̲s̲s̲a̲g̲e̲s̲ from the nodes to
the SCC.
The SCC contains a D̲e̲l̲a̲y̲ ̲T̲a̲b̲l̲e̲ containing the delay
for each node-trunk of the network (Fig. 4.2.2.3.3-1).
The delayes are based on experience from "B̲u̲s̲y̲ ̲H̲o̲u̲r̲
̲L̲o̲a̲d̲". Concerning the topology the table is loaded
with the default delay 10.
More experience may cause the operator of the SCC to
change the delays.
The routing algorithm is executed by the SCC when the
Delay Table has been changed, due to changes of topology
or delay; the output is a R̲o̲u̲t̲i̲n̲g̲ ̲T̲a̲b̲l̲e̲ for each node
generated in this way: For a given node the routing
algorithm runs through possible routes to each destination.
For each route the delay is found simply by adding
the delays found in the Delay Table. For each destination
the route with the smallest delay (or highest connectivity)
is chosen.
The calculation is repeated successively with each
trunks to the neighbour node found d̲i̲s̲c̲o̲n̲n̲e̲c̲t̲e̲d̲; the
calculation is repeated once more with t̲h̲e̲s̲e̲ ̲t̲r̲u̲n̲k̲s̲,̲
̲t̲o̲o̲ ̲d̲i̲s̲c̲o̲n̲n̲e̲c̲t̲e̲d̲. The three results, which are called
the p̲r̲i̲m̲a̲r̲y̲, s̲e̲c̲o̲n̲d̲a̲r̲y̲ and t̲e̲r̲t̲i̲a̲r̲y̲ trunk are stored
in the R̲o̲u̲t̲i̲n̲g̲ ̲T̲a̲b̲l̲e̲ (Fig. 4.2.2.3.3-2) which is forwarded
to the node by a control message. So the routing is
a̲d̲a̲p̲t̲i̲v̲e̲, because not only the current changes of the
network topology, but also the average load (as well
as a possible overload) are taken into consideration,
when the routing algorithm is executed.
The routing result of the algorithm contains the three
alternate results per destination as mentioned above,
despite the fact that it is run when the topology is
changed (power carrier, transmission error, reply,
commands from SCC-supervisor, active SCC) and when
the delay is changed (SCC-supervisor). The reason is
that it must be possible to perform routing also in
the period of time when the algorithm is executed,
i.e. from some changes occur until new Routing Tables
are calculated and distributed.
Delay Table of the SCC (Normal Contents).
The delays are expressed in No. of time units.
Figure 4.2.2.3.3-1
Delay Table. Initial Contents
Figure 4.2.2.3.3-2
Routing Table for node K
4.2.2.3.4 F̲i̲l̲e̲ ̲H̲a̲n̲d̲l̲i̲n̲g̲
The interactive up-date of files includes up-dates
of the:
- Routing Directory File
- Supervisor Security Profile File
The changed entries are automatically distributed to
the MEDEs in the FIKS system. In the MEDEs the Supervisory
Function Subsystem executes the actual up-date which
includes up-date of the respective files, i.e.:
- Routing Directory File (RDF)
- User Security Profile File (USP)
and in case of RDF file also up-date of incore tables.
Any up-dates are forwarded to the MEDEs as control
messages following the up-date of the SCC disc and
in core table. Further, the SCC Routing indicator to
address number table (part of the address file) can
be on-line up-dated.
All on-line table up-dates assume changes of existing
records. In case of add of a record, the table must
be reorganized off-line.
R̲o̲u̲t̲i̲n̲g̲ ̲D̲i̲r̲e̲c̲t̲o̲r̲y̲ ̲F̲i̲l̲e̲ ̲(̲R̲D̲F̲)̲ ̲U̲p̲-̲d̲a̲t̲e̲s̲
RDF up-dates at the SCC are always sent to all NODE/MEDEs
for up-date of the local RDF's. There are two table
updates which may take place, namely:
- AIG table up-date
- ANO table up-date
A̲I̲G̲ ̲T̲a̲b̲l̲e̲ ̲U̲p̲-̲d̲a̲t̲e̲
By this a record containing up to 275 ANO's may be
updated. The result will be a disc (permanent) up-date
and an up-date of the AIG existence map (in core table).
A̲N̲O̲ ̲T̲a̲b̲l̲e̲ ̲U̲p̲-̲d̲a̲t̲e̲
A record containing the English and Danish plain text
address may be up-dated as well as the terminal- identification.
Hereby, only terminal-identification already known
to the system may be used. An up-date at the SCC results
in a permanent up-date (on disc) of the plain text
table and the terminal-identification table, and up-date
of ANO existence map and ANO in core table.
S̲u̲p̲e̲r̲v̲i̲s̲o̲r̲ ̲S̲e̲c̲u̲r̲i̲t̲y̲ ̲P̲r̲o̲f̲i̲l̲e̲ ̲F̲i̲l̲e̲ ̲(̲U̲S̲P̲)̲ ̲U̲p̲-̲d̲a̲t̲e̲
By up-date of this file the changes are only sent to
the MEDE concerned. At the MEDE the SFS up-dates the
USP file according to the change sent.
Only Supervisor Security Profile records are up-dated
and sent to the MEDE:
A̲d̲d̲r̲e̲s̲s̲ ̲F̲i̲l̲e̲ ̲(̲A̲D̲F̲)̲ ̲U̲p̲-̲d̲a̲t̲e̲
Up-dates on the ADF is only performed at the active
SCC. The only table to be up-dated is the RIA (Routing
indicator to ANO). An up-date is performed on disc
and in core.
4.2.2.3.5 S̲C̲C̲ ̲C̲o̲n̲t̲r̲o̲l̲
The SCC control, i.e. control of the backup SCC, takes
place by means of a supervisor procedure. The procedure
handles the controlled switchover from the active SCC
to the stand-by.
By this a control message is sent to the stand-by SCC
requesting initiating a switchover procedure. The actual
procedure has first taken place when the backup SCC
has sent an acknowledgement that it has taken over
responsibilities.
4.2.2.3.6 R̲e̲s̲t̲a̲r̲t̲/̲R̲e̲c̲o̲v̲e̲r̲y̲
By a restart the NSC runs its initialization sequence
whereby the network status table and the TV-display
table are initialized.
4.2.2.3.7 Q̲u̲e̲u̲e̲s̲
The following queues are accessed by the NSC:
- C̲M̲ ̲q̲u̲e̲u̲e̲ which is the NSC input queues and it contains
control messages received from the NODE/MEDE or
the SCC.
An entry in this queue causes an activation of
the NSC.
- A̲L̲ ̲q̲u̲e̲u̲e̲ which is the Alarm/Alert/Notice queue.
The queue is a NSC internal queue used for printing
and Alarm/Alert/Notice report on the log-printer.
An entry in this queue causes an activation of
the print module.
- L̲P̲ ̲q̲u̲e̲u̲e̲ which is the line printer queue.
Print-out which is the result of a terminal operator
request is queued here. A LP queue exists for each
terminal defined.
An entry in this queue causes an invocation of
the print module. A print-out from the LP queue
has lower priority than a print-out from the AL
queue
- N̲S̲ ̲q̲u̲e̲u̲e̲ is the network statistic queue.
The queue is a NSC output queue and contains statistical
reports received by the NSC from the NODE/MEDE
and after processing enqueued the NS queues.
4.2.2.3.8 F̲i̲l̲e̲s̲
The files used by the NSC are the following:
- S̲u̲p̲e̲r̲v̲i̲s̲o̲r̲ ̲S̲e̲c̲u̲r̲i̲t̲y̲ ̲P̲r̲o̲f̲i̲l̲e̲ ̲F̲i̲l̲e̲ ̲(̲U̲S̲P̲)̲
The file contains the Security Profile of the SCC
supervisors and the NODE/MEDE supervisors.
- R̲o̲u̲t̲i̲n̲g̲ ̲D̲i̲r̲e̲c̲t̲o̲r̲y̲ ̲F̲i̲l̲e̲ ̲(̲R̲D̲F̲)̲
The RDF contains information to be used in routing
and distribution of messages. The RDF is organized
as a dirctory file with the following tables:
- ANO table
- AIG table
- Terminal table
- Address table
- I̲n̲-̲b̲o̲u̲n̲d̲ ̲M̲e̲s̲s̲a̲g̲e̲ ̲F̲i̲l̲e̲ ̲(̲I̲M̲F̲)̲
The NSS will use the IMF for incoming messages
(control and narrative messages).
- T̲e̲m̲p̲o̲r̲a̲r̲y̲ ̲S̲t̲o̲r̲a̲g̲e̲ ̲F̲i̲l̲e̲ ̲(̲T̲S̲F̲)̲
The TSF is a directory file organized with one
named file per message. The TSF contains messages
of the SCC queues, namely the messages with the
SCC as destination, and origination for the case
IMF overload. It further contains control messages
created at the SCC, and it is also used for incoming
messages.
- R̲o̲u̲t̲i̲n̲g̲ ̲I̲n̲d̲i̲c̲a̲t̲o̲r̲ ̲F̲i̲l̲e̲ ̲(̲R̲I̲A̲)̲
RIA table, which holds the correspondance between
a Routing indicator and a FIKS ANO. The RIA table
is the only table accessed by the NSC for on-line
table handling purposes.
- N̲e̲t̲w̲o̲r̲k̲ ̲S̲t̲a̲t̲u̲s̲ ̲F̲i̲l̲e̲ ̲(̲N̲S̲F̲)̲
The file holds 4 tables namely:
- Network delay table.
This table contains informatin about transmission
delay from one node to another node for the
entire network.
- Trunk status table.
The table contains the following information
about each trunk group:
- Trunk opened/closed
- Trunk failed/OK
- NPDN/trunk connection
- Number of trunks in group (i.e. between
two nodes)
- Transmission delay
- Routing table.
The table contains the current routing table
for each node in the network.
- Trunk group number table.
The table holds the trunk group number for
each connection between two nodes.
The node-id of the two nodes is used as handle.
The tables are maintained automatically (e.g. trunk
failure report) or by an operator procedure (e.g. up-date
delay factors) by the means of the NSC.
4.2.2.4 V̲i̲s̲u̲a̲l̲ ̲T̲a̲b̲l̲e̲ ̲o̲f̲ ̲C̲o̲n̲t̲e̲n̲t̲s̲
Figure 4.2.2.4-1 provides a visual table of the two
functional categories which comprise the NSC.
4.2.2.5 S̲u̲b̲s̲y̲s̲t̲e̲m̲ ̲O̲v̲e̲r̲v̲i̲e̲w̲ ̲H̲I̲P̲O̲ ̲D̲i̲a̲g̲r̲a̲m̲
Figure 4.2.2.5-1 provides an overview of the functions
covered in the NSC.
Figure 4.2.2.4-1
Visual Table of Contents
Figure 4.2.2.5-1a
Subsystem Overview HIPO Diagram
Figure 4.2.2.5-1b
Subsystem Overview HIPO Diagram
4.2.3 N̲e̲t̲w̲o̲r̲k̲ ̲S̲t̲a̲t̲i̲s̲t̲i̲c̲ ̲S̲u̲b̲s̲y̲s̲t̲e̲m̲
4.2.3.1 F̲u̲n̲c̲t̲i̲o̲n̲s̲
The Network Statistic Subsystem (NES) at the SCC provides
the functions:
- Statistical data collection and storage.
- Generation (on-request) of the MEDE 24 hour statistic.
- On-line dump (on-request) of the statistic file
to floppy disc.
4.2.3.2 S̲u̲b̲s̲y̲s̲t̲e̲m̲ ̲B̲l̲o̲c̲k̲ ̲D̲i̲a̲g̲r̲a̲m̲
Figure 4.2.3-1 illustrates the flow of data and control
for each of the three functions supported by the NES.
The block diagram depicts that the NICS-TARE Subsystem
(NTS) and the Network Supervision and Control Subsystem
(NSC) place an entry - pointing at a statistics record
area - in the input queue for the NES.
The check input module extracts the originator-ID,
DTG and type from the statistics record. Based upon
this informatin the storage module (3) saves the statistics
record on the statistics file by accessing the input/output
system IOS (4).
The calculate statistic module is involved on terminal
operator request. It retrieves the MEDE statistic information
from the statistic file (5) and generate the MEDE statistic.
The MEDE statistic is distributed to the appropriate
MEDEs (6).
A terminal operator requests an on-line dump of the
statistic file (7). The statistic file is copied from
the MMD to the floppy disc (8) - (9).
Figure 4.2.3-1
Network Statistics Subsystem, Block Diagram
4.2.3.3 D̲e̲s̲i̲g̲n̲ ̲O̲v̲e̲r̲v̲i̲e̲w̲
The Network Statistic Subsystem (NES) collects statistical
data on an hourly basis. All statistical data are stored
on a disc file which in a cyclic matter contains statistical
data records of up to the last 48 hours.
The NES provides the facility of generating a 24 hour
MEDE statistic. Further, it is possible to dump the
statistical file to a floppy disc file.
S̲t̲a̲t̲i̲s̲t̲i̲c̲ ̲d̲a̲t̲a̲ ̲c̲o̲l̲l̲e̲c̲t̲i̲o̲n̲ ̲a̲n̲d̲ ̲s̲t̲o̲r̲a̲g̲e̲
The Network Statistic Subsystem (NES) receives once
per hour statistical data records from two sources
as illustrated in Figure 4.2.3-2.
- Control messages containing statistical records,
whose contents originate from NODE/MEDEs and are
received indirectly from the Network Supervision
and Control (NSC). The control messages may originate
from:
- a NODE
- a MEDE
- Statistical records from the message service subsystem
(MSS).
The received records are stored on a statistics file
(see Table 4.2.3-1), which contains the latest 48 hours
statistics in a cyclic manner.
Each record contains the following information:
- Statistic type
- Length of record
- Statistic data.
Table 4.2.3-1
Network Statistics Subsystem
Statistics File Layout
Design Overview
2̲4̲ ̲H̲o̲u̲r̲ ̲M̲E̲D̲E̲ ̲S̲t̲a̲t̲i̲s̲t̲i̲c̲ ̲G̲e̲n̲e̲r̲a̲t̲i̲o̲n̲
This statistic is generated on-line when the supervisor
activates the procedure.
The statistic contains information about the released
and received messages for each NODE/MEDE, and cover
the traffic for the preceeding day from 00.00 - 24.00
hour.
The statistic are after generation automatically distributed
to the appropriate NODE/MEDE (AX queue).
D̲u̲m̲p̲ ̲o̲f̲ ̲S̲t̲a̲t̲i̲s̲t̲i̲c̲a̲l̲ ̲F̲i̲l̲e̲ ̲t̲o̲ ̲F̲l̲o̲p̲p̲y̲ ̲D̲i̲s̲c̲
The statistical file is dumped (on-line) to a floppy
disc file when the supervisor activates the dump procedure.
This causes a copy of the statistical data record from
the preceding day (00.00 - 24.00 hour) to be produced.
Figure 4.2.3-2
Network Statistics, Design Overview
4.2.3.4 V̲i̲s̲u̲a̲l̲ ̲T̲a̲b̲l̲e̲ ̲o̲f̲ ̲C̲o̲n̲t̲e̲n̲t̲s̲
Figure 4.2.3-3 provides a visual table of contents
of the three functional categories that comprise the
NES.
Figure 4.2.3-3
Network Statistics, Table of Contents
4.2.3.5 S̲u̲b̲s̲y̲s̲t̲e̲m̲ ̲O̲v̲e̲r̲v̲i̲e̲w̲ ̲H̲I̲P̲O̲ ̲D̲i̲a̲g̲r̲a̲m̲
Figure 4.2.3-4 provides an overview of the functions
covered in the NES.
Table 4.2.3-2 contains an extension of the HIPO diagram.
It defines the statistics information received from
MEDEs, NODEs and the NICS-TARE subsystem.
Figure 4.2.3-4
S̲t̲a̲t̲i̲s̲t̲i̲c̲a̲l̲ ̲D̲a̲t̲a̲ ̲c̲o̲l̲l̲e̲c̲t̲e̲d̲ ̲a̲n̲d̲ ̲s̲t̲o̲r̲e̲d̲ ̲o̲n̲ ̲S̲t̲a̲t̲i̲s̲t̲i̲c̲
̲F̲i̲l̲e̲ ̲b̲y̲ ̲t̲h̲e̲ ̲N̲E̲S̲
- NICS-TARE Message Flow.
- Number of incoming messages (from NICS) per
precedence per hour.
- Number of outgoing messages (to NICS) per precedence
per hour.
- ACP Format Conversions.
- Number of messages converted from ACP to SMF.
- Average message delay to and from NICS-TARE,
i.e. DTG of oldest message in the NICS-TARE
and conversion queue.
- Number of messages converted from SMF to ACP.
- Number of messages in error on conversion per
precedence.
M̲E̲D̲E̲ ̲S̲t̲a̲t̲i̲s̲t̲i̲c̲s̲
- Message Flow.
- Messages released, i.e. class/precedence/No.
of messages/NO. of ANO's/total No. of characters.
- Messages received (from the trunk), i.e. class/precedence/No.
of messages/total No. of characters.
- Security Statistics.
- Number of security profiles up-dates (changed/added/deleted).
S̲t̲o̲r̲a̲g̲e̲ ̲(̲H̲D̲B̲)̲ ̲S̲t̲a̲t̲i̲s̲t̲i̲c̲s̲
The DTG of the oldest message in the HDB per MEDE (per
hour) is collected.
M̲e̲s̲s̲a̲g̲e̲ ̲F̲l̲o̲w̲ ̲S̲t̲a̲t̲i̲s̲t̲i̲c̲s̲
The NES collects statistical data for the following:
a) Queue-length of the message queues in the MEDE
categorized by precedence per MEDE.
b) Number of mutilated messages per MEDE
c) DTG of oldest message in print queue per precedence
per MEDE.
N̲o̲d̲e̲/̲T̲r̲u̲n̲k̲ ̲S̲t̲a̲t̲i̲s̲t̲i̲c̲s̲
- Message Flow.
- Number of frames transmitted per trunk per
hour.
- Trunk message load in characters per hour.
- Trunk queue length per precedence per hour.
- The DTG of the oldest message in trunk queue
per precedence per node.
M̲a̲i̲n̲t̲e̲n̲a̲n̲c̲e̲ ̲S̲t̲a̲t̲i̲s̲t̲i̲c̲s̲
The following events are collected:
a) Trunk circuit outage
b) Trunk circuit back in service
S̲e̲c̲u̲r̲i̲t̲y̲
Following events per Crypto Unit per MEDE:
- Crypto failure (on/off)
Network Statistics Subsystem (NES)
Extension of Overview HIPO Diagram.
Table 4.2.3-2
4.2.4 M̲e̲s̲s̲a̲g̲e̲ ̲S̲e̲r̲v̲i̲c̲e̲ ̲S̲u̲b̲s̲y̲s̲t̲e̲m̲ ̲(̲M̲S̲S̲)̲
Messages entered at user terminal are generated and
stored in Simplified Message Format (SMF). All messages
delivered to local users shall be in SMF. At the SCC,
message may be translated to the format specified in
Allied Communication Publication - ACP127 NATO.SUPP.
3. Messages in SMF, although in an abbreviated form
must contain sufficient information for translation
to ACP127 format.
Incoming messages from NICS-TARE and messages form
Naval Radio sites are received in ACP127 message format.
These messages must be converted to SMF prior to delivery
to FIKS terminals.
4.2.4.1 F̲u̲n̲c̲t̲i̲o̲n̲s̲
This section describes the system of the MSS. This
may be devided into two main functions, namely:
- Message conversion
- Message intercept
M̲e̲s̲s̲a̲g̲e̲ ̲C̲o̲n̲v̲e̲r̲s̲i̲o̲n̲
Messages from FIKS to NICS-TARE and vice versa are
converted to the appropriate format. Further, messages
are on request converted, from SMF to ACP127 format
and vice versa, and distributed within FIKS.
1. Receive an ACP127 message from NICS-TARE. Convert
it to a SMF message and deliver the converted message
to the NSS at the SCC for further distribution
on the FIKS network. If conversion shows up to
be impossible, the message shall be queued for
intercept handling.
2. Receive a SMF message from the FIKS network, convert
it to an ACP127 message and deliver it to the NECS-TARE
interface for further distribution. If conversion
shows up to be impossible, the message shall be
queued for intercept handling.
3. Receive an ACP127 message from the FIKS network.
This message shall be the text part of an SMF envelope.
The ACP127 message is converted to a SMF message
and sent to the NSS for further distribution on
the FIKS network, based upon the addresses in the
ACP127 message. Conversion errors lead to interception
as above.
4. Receive a SMF message from the FIKS network and
convert it to an ACP127 message. The converted
message is put into a SMF envelope and returned
to the originator (via the FIKS network). Intercept
in case of errors..
In the above mentioned cases statistical information
about the conversion is collected and transferred to
the network statistics module (NES).
When the SCC changes its mode from stand-by to active,
the MSS will start processing the "next" message from
its input queue. After processing and transmission
of a message an acknowledgement identifying the message
will be forwarded to the ISH subsystem for message
synchronization purposes.
When the SCC changes its mode from active to stand-by,
the MSS is informed to stop processing.
M̲e̲s̲s̲a̲g̲e̲ ̲I̲n̲t̲e̲r̲c̲e̲p̲t̲
This module is used to correct intercepted messages
which during conversion (ACP127 - SMF) showed up to
be erroneoues. The message is corrected manually by
the intercept operator and is then returned to the
conversion module. The correction procedure uses a
subset of standard EDIT commands.
The above module is activated through the Interactive
Terminal Monitor (TEPINT) at the SCC.
4.2.4.2 S̲u̲b̲s̲y̲s̲t̲e̲m̲ ̲B̲l̲o̲c̲k̲ ̲D̲i̲a̲g̲r̲a̲m̲
A survey over the whole conversion subsystem is given
in Figure 4.2.4.2-1 showing the used files and queues.
The numbers shown on the interface diagram indicate
the following operations:
1. Element is written to conversion queue
(SMF - ACP external/internal, ACP - SMF internal)
2. Write element to conversion queue No. 1
(ACP - SMF external)
3. Write element to appropriate conversion queue
after intercept.
4. Read element from conversion queue.
4a. Delete element in conversion queue
4b. Read element from conversion queue
4c. Delete element in conversion queue
5. Read element from intercept queue (IC)
5a. Delete element in intercept queue
6. Write element to NODE/MEDE queue (NM)
7. Read element from NM
7a. Delete element in NM
8. Write element to network statistics queue (NS)
9. Read element from NS
9a. Delete element in NlS
10. Write element in NICS/TARE queue (NT)
11. Read element from NT
11a. Delete element in NT
12. Write element to intercept queue.
4 block diagrams, illustrating each of the 4 different
conversion cases, follow the survey.
- ACP127 -- SMF external
- ACP127 -- SMF internal
- SMF -- ACP127 external
- SMF -- ACP127 internal
The block diagram is shown in Figure 4.2.4.2-2, part
1 to 4.
Figure 4.2.4.2-1
ACP127 - SMF Interface Diagram
Figure 4.2.4.2-2.1
ACP127 - AMF External Conversion, Block Diagram
Figure 4.2.4.2-2.2
ACP127 - SMF Internal Conversion, Block Diagram
Figure 4.2.4.2-2.3
SMF - ACP127, External Conversion, Block Diagram
Figure 4.2.4.2-2.4
SMF - ACP127, Internal Conversion, Block Diagram
S̲u̲b̲s̲y̲s̲t̲e̲m̲ ̲B̲l̲o̲c̲k̲ ̲D̲i̲a̲g̲r̲a̲m̲ ̲(̲I̲n̲t̲e̲r̲c̲e̲p̲t̲)̲
Figure 4.2.4.2-3 shows a block diagram of the intercept
procedure. The file "original msg. file" is the file
that contains the original erroneoues message, that
is one of the files IMF, SMF or AMF (ACP127 message
file).
Figure 4.2.4.2-3
Intercept Procedures, Overview Block Diagram
4.2.4.3 D̲e̲s̲i̲g̲n̲ ̲O̲v̲e̲r̲v̲i̲e̲w̲
Below a short outline of the design of the different
modules is given.
1. C̲o̲n̲v̲e̲r̲s̲i̲o̲n̲ ̲c̲o̲n̲t̲r̲o̲l̲
This module is activated upon arrival of a message
in the conversion queue (i.e. the MSS input queue).
The message is always enqueued either by the NICS-TARE
Subsystem (NTS) or the ISH Subsystem. Three types
of conversion of FIKS messages are provided.
- SMF to ACP127.
The SMF message is converted to a full formatted
ACP127 message, enqueued in the NT queue for
onward processing by the NTS.
- SMF to ACP127 (FIKS Internal Conversion).
A conversion of this type causes a pseudo ACP127
message to be generated. A pseudo ACP127 message
means that a real ACP127 message is enclosed
in a SMF for routing within the FIKS network.
The converted message is enqueued for the ISH.
- "ACP127" to SMF (FIKS Internal Conversion).
An "ACP127" message means here an ACP127 message
enclosed in a SMF envelope. A real SMF message
is the result of this conversion whereby the
SMF envelope is stripped off. The converted
message is enqueued for the ISH, subsequentially
followed by a dequeuing of the message from
the conversion queue.
Only the type of NICS-TARE messages is converted
by the MSS, namely:
- ACP127 format to SMF.
A real ACP127 format message, having the FIKS
record format, is converted to a real SMF message.
The converted message is enqueued for the ISH,
subsequentially followed by dequeuing the message
from the conversion queue.
2. E̲n̲v̲e̲l̲o̲p̲e̲ ̲G̲e̲n̲e̲r̲a̲t̲o̲r̲
This module generates a SMF envelope prior to an
internal conversion of a SMF pressage to an ACP127
formatted message. The envelope shall be used to
enclose the converted ACP127 message whereby the
SMF header information is copied form the original
SMF header.
A message of this is by distribution returned to
the originator.
3. S̲M̲F̲ ̲-̲ ̲A̲C̲P̲1̲2̲7̲
This module performs the conversion from SMF to
ACP127. Conversion is mainly based on informtion
achieved from the binary header and the address
list. Address conversion is performed by use of
tables (read from RIA and RDF).
The detailed conversion rules are described in
ref. 1, section 3.1.1.3.2.4.3.1.
Following SMF information which by conversion leads
to intercept (i.e. the message will be enqueued
in the IC queue).
- The message is of type: specat.
- The message is highly classified.
- The Nato ANO or the Nato plain text addresses
cannot be recognized.
4. A̲C̲P̲1̲2̲7̲ ̲-̲ ̲S̲M̲F̲
This module performs the conversion ACP127 - SMF.
Conversion of this type of message means that ACP127
message is enclosed in a SMF envelope. The addresses
in the "SMF" formatted message is hereby Routing
Indicator (RI) converted by use of the RIA table
to FIKS ANO. The RI is taken from the ACP127 message
line 2. The precedence and classification in the
"SMF" message is extracted from the ACP127 format
line 2 and 4.
Errors. such as illegal addresses and missing lines,
lead to intercept, and the conversion is stopped.
5. I̲n̲t̲e̲r̲c̲e̲p̲t̲ ̲M̲o̲d̲u̲l̲e̲
This module is called when an intercepted message
is to be corrected and sent for repeated conversion.
The module uses the edit commands accept replace,
delete and insert. The intercept queue is displayed
on the VDU, upper screen.
After entering the intercept procedure, the element
causing the intercept and the cause code is displayed.
The reference to the message is passed on to the
EDIT module which controls the very correcting
procedure. The module reads the original message
in blocks and writes it on the temporary edit file
together with additions/except for deletions. When
the whole message is processed, the original message
file is overwritten with the temporary edit file
and control is returned to the intercept module.
The element received in the intercept queue is
a reference to the original message file, that
is either the IMF, SMF or the AMF (ACP127 message
file).
When intercept (edit) is finished, an entry is
placed in the conversion queue. In case that it
is not possible to correct the message, the intercept
operator may print the message on his ROP and hereby
delete the message.
The intercept procedure is called from the interactive
terminal monitor, TEPINT, when the command "INT"
is given.
4.2.4.3.1 Q̲u̲e̲u̲e̲s̲
The interaction of the different modules is controlled
by the use of queues. There will be 4 different queues
corresponding to the following states:
- CQ Conversion Queue
- IC Wait for Intercept
- NT Wait for Transmission to NICS-TARE
- NM Wait for Transmission to NODE/MEDE
The queues are served on a first-in first-out basis.
The elements in the queues contain a reference to a
message stored on disc.
4.2.4.3.2 F̲i̲l̲e̲s̲
The message service subsystem uses the following files:
- IMF Inbound Message File. Contains messages
received from collocated NODE/MEDE.
- AMF ACP127 Message File. Contains messages
to/from NICS-TARE.
- RIA Address File. Contains address conversion
labels used by the ACP127 - SMF conversion
modules.
- SMF SMF Message File. Contains SMF messages
for the collocated NODE/MEDE.
- RDF Routing Directory File as used at the NODE/MEDE.
Contains address conversion labels used
by the SMF - ACP127 conversion module.
4.2.4.4 H̲I̲P̲O̲ ̲O̲v̲e̲r̲v̲i̲e̲w̲
A HIPO overview showing the execution sequence in the
MSS subsystem is shown overleaf.
HIPO Overview
HIPO Overview
HIPO Overview
HIPO Overview
