top - download
⟦ecc27187e⟧ Wang Wps File
Length: 81590 (0x13eb6)
Types: Wang Wps File
Notes: CPS/SDS/033
Names: »1930A «
Derivation
└─⟦4e9382203⟧ Bits:30006097 8" Wang WCS floppy, CR 0150A
└─ ⟦this⟧ »1930A «
WangText
G…07…F…0a…F…0d…F…00…F…05…E…0a…E…0e…E D…08…D…0c…D…0d…D…02…C…08…C…0d…C…02…C…07…B…0d…B…02…B…05…A…09…A…0d…A…02…A @…0a…@…0e…@…01…@ ?…0a…?…0f…?
?…06…>…0a…>…0e…>…01…> >…05…=…0a…=…0b…=…00…=…05…=…06…<…0a…<…00…< …86…1
…02…
…02…
…02…
…02…CPS/SDS/033
…02…KNB/831101…02…
TRAFFIC
HANDLING
DETAILED
DESIGN
SPECIFICATION ISSUE
1 CAMPS
1̲ ̲ ̲G̲E̲N̲E̲R̲A̲L̲
1.1 P̲U̲R̲P̲O̲S̲E̲ ̲A̲N̲D̲ ̲S̲C̲O̲P̲E̲
The package specification for the Traffic Handling
Package (CPS/SDS/033) is written to fulfil the following
objectives:
a) To provide detailed definition of the package functions
and software architecture.
b) To provide user operational and development personnel
details of the ongoing analysis.
c) To define in detail the interfaces with other packages
and to describe their facilities.
The Traffic Handling Package provides functions for
message reception and transmission (level 4), ACPl27
analysis of incoming messages, Routing and ACPl27-conversion
of outgoing messages.
This document contains the complete design of the Traffic
Handling Package to a level sufficient for a programmer
to start coding with a minimum of design effort of
the architecture.
1.2 A̲P̲P̲L̲I̲C̲A̲B̲L̲E̲ ̲D̲O̲C̲U̲M̲E̲N̲T̲S̲ ̲A̲N̲D̲ ̲P̲R̲O̲J̲E̲C̲T̲ ̲R̲E̲F̲E̲R̲E̲N̲C̲E̲S̲
1.2.1 A̲p̲p̲l̲i̲c̲a̲b̲l̲e̲ ̲d̲o̲c̲u̲m̲e̲n̲t̲s̲
The following documents are applicable to the Traffic
Handling Package Design Specification.
Contract Document
Contract No. CE 80-9009-INF
CAMPS System Requirements
CPS/210/SYS/0001
User Procedure,
doc. no. CPS/230/ICD/0001
Supervisor Commands and Procedures
CPS/230/ICD/0002
ACP127 NATO Supp. 3 Procedures
CPS/230/ICD/0003
NICS/TARE
CPS/ICD/004
SCARS II
CPS/ICD/005
ACE CCIS
CPS/ICD/006
TRC, Point-to-Point Connection
CPS/ICD/007
CAMPS System Design Specification,
doc. no. CPS/SDS/001.
CAMPS Data Base Design Document,
doc. no. CPS/DBD/001
CAMPS Software Interface Control Document,
doc. no. CPS/ICD/009
1.2.2 R̲e̲f̲e̲r̲e̲n̲c̲e̲ ̲D̲o̲c̲u̲m̲e̲n̲t̲s̲
D̲O̲C̲U̲M̲E̲N̲T̲ ̲N̲A̲M̲E̲
CAMPS System Functions
CPD/SDS/024
Message Management
CPS/SDS/025
Table Management
CPD/SDS/026
Input/Output Control
CPS/SDS/028
System Status and Control
CPS/SDS/029
Storage and Retrieval
CPS/SDS/030
Statistics
CPS/SDS/03l
Logging
CPS/SDS/032
Message Distribution
CPS/SDS/034
Supervisor VDU
CPS/SDS/035
Supervisor Printer
CPS/SDS/036
MDCO VDU
CPS/SDS/037
MSO VDU
CPS/SDS/038
USER VDU
CPS/SDS/039
OCR
CPS/SDS/040
Printer
CPS/SDS/04l
1.2.3 P̲r̲o̲j̲e̲c̲t̲ ̲R̲e̲f̲e̲r̲e̲n̲c̲e̲s̲
The following documents are listed for reference purposes
only. The listing does not constitute the contents
of the documents as Systen Requirements but is intended
to serve the Contractor in providing supplementary
information in cases of interpretation of the requirements
specifically stated in System Requirements Specification:
ACP131, Jul. 74
ACP117, SEPT. 1977, ACP117 Supp. 16. Dec. 79
ACP121, Supp. 17. Jan. 1970, 121E Jul. 1970
ACP100, NATO SUPP, 1E May 1978
ACP127, NATO SUPP. 3 May 1973, 127 (E) OCT 74
NASIS-APP.3 JAN 1978
1.3 T̲E̲R̲M̲S̲ ̲A̲N̲D̲ ̲A̲B̲B̲R̲E̲V̲I̲A̲T̲I̲O̲N̲S̲
1.3.1 T̲e̲r̲m̲s̲
Channel designator Identification of an external
channel.
Checkpoint Point from which restart/recovery
can take place.
Circuit CAMPS to node connection
for the appropriate Network.
A circuit may consist of
one or more channels.
Close-down Action taken to bring processing
within the system or a part
thereof to a stop - can be
either an ordered sequence
of steps or an abrupt termination.
External Channel A channel in a telegraph
circuit or non telegraph
circuit consisting of an
input and an output channel.
Initialization The definition in the CPS/SDS/001
and subsequent documents
is described as follows:
Brings the system from cold
or dead start into operational
use. No recovery actions
are included.
Message Distribution Denotes the total group of
Control Function commands/procedures which
may be performed from a VDU
with Message Distribution
Control capability.
Message Service Denotes the total group of
Function commands/procedures which
may be performed from a VDU
with Message Service capability
Message View A subset of fields within
a message.
Non Telegraph CCIS and SCARS
Circuit
Plain Language The PLA representing a
Address Headquarter
Process Execution of a specific program
operating on a specific set
of data.The active components
of the system to which security
and process control as well
as resource management is
applied.
Queue Process communication tool
within CSF.
Queue Element The elements which can be
in a queue.
Queue Monitor The part of CSF supplying
Queue facilities.
Restart Reestablishes the dynamic
behaviour of the system based
upon recovered data.
Recovery Reestablishes continuity
in memory and file contents.
Subqueue Part of a Main Queue
Supervisor Person located at supervisor
terminals in CAMPS central
equipment room
Supervisor's Person with responsibility
for
Assistant special Message Service
Stand-alone device Medium speed teleprinter,
low speed teleprinter (PTP,PTR,
ROP) OCR, PTR, and PTP.
Start up Includes all aspects of initialization,
recovery and restart.
Switchover Relates to a dualized configuration
containing an active and
a stand-by device into active
state and the other active
device off-line.
System Parameter A simple variable, holding
part of the system state,
and controlled by TMP.
Telegraph circuit NICS TARE, Point-to-Point
and TRC.
Terminal VDU, Medium Speed Teleprinter,
Low Speed Teleprinter, Line
Printer, PTP/PTR and OCR.
Terminal Position VDU and associated (shared)
ROP.
User a) Person with responsibility
for input and output
of messages.
b) Person located at the
user terminals in the
staff cells.
1.3.2 A̲b̲b̲r̲e̲v̲i̲a̲t̲i̲o̲n̲s̲
AAS ACP127 Analysis Subpackage
ACP127 ALLIED Communication Procedures No. 127
ACS ACP127 Conversion Subpackage
AIG Address Indicator Group
ANQ Analysis Queue
ASM Abbreviated Service Message
CAMPS Computer Aided Message Processing System
CCQ Channel Command Queue
CCIS Command & Control Information System
CIF CAMPS Information Field
CIQ Circuit Queue
COQ Conversion Queue
CPS CAMPS
CSF CAMPS System Functions
CTS Cosmic Top Secret
DTG Data Time Group
EMF External Message Format
EOLF End of Line Feed
EOPF End of Page Function
EOTF End of Transmission Function
FIFO First In, First Out
FL Format Line
HQ Headquarters
ICD Interface Control Document
IMF Internal Message Format
IOC Input/Output Control Package
ITS Incoming Transport Subpackage
LOG Log and Accountability Package
MCQ MDCO Queue
MDCO Message Distribution Control
MDP Message Distribution Package
MSO Message Service Operator
MSQ Message Service Queue
NA Not Applicable
NICS Nato Integrated Communication System
OTS Outgoing Transport Subpackage
PLA Plain Language Address
PLA# Plain Language Address Reference Number
PTP Paper Tape Puncher
PTR Paper Tape Reader
P-to-P Point-to-Point
QEL Queue Element
SAR Storage and Retrieval
SCARS Status Control and Reporting System
SCD Staff Cell Designator
SDS System Design Specification
SFM Storage and File Management Package
SIC Subject Indicator Code
SOTF Start of Transmission Function
SRS System Requirements Specification
SSC System Status and Control
SSN Station Serial Number
STP Statistic Package
SVC Service Message
TARE Telegraph Automatic Relay Equipment
TCS Transport Control Subpackage
TD Terminal Designator
TEP Terminal Package
THP Traffic Handling Package
TI Transmission Identification
TMP Table Management Package
TOC Time of Occurrence
TRS Transport Subpackage
TSN Transmission Serial Number
2̲.̲ ̲S̲U̲M̲M̲A̲R̲Y̲ ̲O̲F̲ ̲R̲E̲Q̲U̲I̲R̲E̲M̲E̲N̲T̲S̲
2.1 P̲A̲C̲K̲A̲G̲E̲ ̲D̲E̲S̲C̲R̲I̲P̲T̲I̲O̲N̲
The Traffic Handling Package provides the functions
for Transport, ACP127-analysis, Routing and ACP127
-conversion of messages.
Incoming messages are received via external channels
(NICS TARE, TRC/Point-to-Point, SCARS and CCIS) and
transported to analysis for subsequent internal distribution.
Outgoing messages are received from other Packages
for routing, conversion and transport for transmission
via above mentioned external channels.
The functions for handling of complete messages related
to PTR/PTP are also provided within this Package.
The Interfaces of the Traffic Handling Package are
as depicted in figure 2.1-1. The chart illustrates
the environment of this package and inter-relationships
between external/internal interfaces.
FIGURE 2.1-1…01…TRAFFIC HANDLING PACKAGE
a) E̲x̲t̲e̲r̲n̲a̲l̲-I̲n̲t̲e̲r̲f̲a̲c̲e̲s̲
NICS TARE
TRC/Point-to-Point
SCARS
CCIS
PTR
PTP
Low speed Teleprinters operating as PTR or PTP.
b) I̲n̲t̲e̲r̲n̲a̲l̲-I̲n̲t̲e̲r̲f̲a̲c̲e̲s̲
Message Distribution Package (MDP)
Terminal Package (TEP)
Log Package (LOG)
Statistics Package (STP)
Storage and Retrieval (SAR)
Table Management (TMP)
CAMPS System Functions (CSF)
Message Management (MMS)
Input/Output Control (IOC)
System Status and Control (SSC)
2.2 P̲A̲C̲K̲A̲G̲E̲-F̲U̲N̲C̲T̲I̲O̲N̲S̲
The functions performed by this package will in the
following two sections (2.2.1 and 2.2.2) be described
in the main functions under normal operation and the
more special functions performed under more specific
circumstances.
2.2.1 M̲a̲i̲n̲-F̲u̲n̲c̲t̲i̲o̲n̲s̲
The main functions performed during normal operation
are:
a) Reception Procedures
b) ACP127-analysis
c) Routing
d) ACP127-conversion
e) Transmission Procedures
f) Transmission Control Procedures
The terms used under a, e and f are corresponding to
- Incoming Transport (a)
- Outgoing Transport (e)
- Transport Control (f)
2.2.1.1 R̲e̲c̲e̲p̲t̲i̲o̲n̲ ̲P̲r̲o̲c̲e̲d̲u̲r̲e̲s̲
The functions associated to Reception Procedures are:
- Assembling of format-lines into messages in ACP127-format
or CCIS E1-format
- Channel Discontinuity Procedures
- Tolerance Control for detection of garble characteristics.
The received messages are considered as incoming from
the external networks NICS TARE, TRC, Point-to-points
and the external systems SCARS and CCIS.
Under reception procedures are also considered input
via the dedicated PTR or Low Speed Teleprinters operating
like PTR's. These messages are entered into complete
ACP127-format and mainly considered as outgoing messages.
The messages described are always directed for ACP127-analysis.
2.2.1.2 A̲C̲P̲1̲2̲7̲ ̲A̲n̲a̲l̲y̲s̲i̲s̲
The functions of ACP127-analysis are:
- Handling of errors detected during Reception Procedures
involving a message.
- Format-Line detection and control
- Message Type Determination
- Relaying
- ASM-Handling
- Handling of messages received in CCIS E1-format
- Flash acknowledge
- Consistency Control
- Internal Format Conversion
After ACP127-analysis a message might be directed to
a message service position for:
- Garble Correction
- Message Inspection
Otherwise the message will be directed to its proper
destinations into CAMPS according to the message type.
2.2.1.3 R̲o̲u̲t̲i̲n̲g̲
The functions of routing are:
- Selection of Routing Indicators related to PLA's
or AIG's (entered during Message Prepare) in accordance
with message classification.
- Circuit allocation in accordance with channel availability
and classification on basis of related Routing
Indicator.
- Message Service Invocation for RI-assignment in
case above described functions fail.
- Automatic release of complete entered messages.
During Routing the PTP will be selected as "circuit"
for plaindress messages of type Crypto Security and
in accordance with MSO-decision where no RI with proper
classification can be found.
Local PLA's will also be detected, and cause local
distribution.
2.2.1.4 A̲C̲P̲1̲2̲7̲-̲C̲o̲n̲v̲e̲r̲s̲i̲o̲n̲
The messages received for ACP127-conversion are messages
that have been routed.
The functions of ACP127-conversion are:
- Formatting of FL2 and FL3 of complete entered messages.
- Formatting of Supervisor prepared Service Messages
- Conversion and formatting of user prepared messages
into complete ACP127-format.
- Separation into sections if applicable for that
message
- Preparation of separate transmissions in case multiple
routes or limit exceeded on RI's.
- Insert of ZEN in front of PLA's where multiple
routes are applicable.
The messages are after conversion forwarded to transmission
upon a channel indicated via the circuit selected under
Routing. A message containing Local PLA's will, however,
be directed for local distribution
2.2.1.5 T̲r̲a̲n̲s̲m̲i̲s̲s̲i̲o̲n̲ ̲P̲r̲o̲c̲e̲d̲u̲r̲e̲s̲
The functions of Transmission Procedures are:
- Formatting of FL1
- Formatting of Pilots upon automatic or Supervisor
intiated retransmissions (reruns)
- Preemption for transmission of flash message where
applicable.
- Delivery of format-lines for transmission including
insert of formal parameters.
To the Transmission Procedures are also considered
the functions for punch on a PTP; the first two functions
described are then slightly different, but still relevant.
A transmitted message will after successful transmission
be taken care of by the Transmission Control Procedures,
if the message shall be acknowledged.
2.2.1.6 T̲r̲a̲n̲s̲m̲i̲s̲s̲i̲o̲n̲ ̲C̲o̲n̲t̲r̲o̲l̲ ̲P̲r̲o̲c̲e̲d̲u̲r̲e̲s̲
The functions of the Transmission Control are:
- Automatically Generation of ASMs of the type channel
continuity, channel number reset etc. upon timer-event.
- Time-out control and initialization of retransmissions
or supervisor reports upon that event.
- Generation of flash acknowledge ASM, Identical
Character ASM etc. upon request via a command.
- Initiate channel open and close (via command) by
generation of an ASM or at receipt of such ASM.
2.2.2 F̲u̲n̲c̲t̲i̲o̲n̲a̲l̲ ̲R̲e̲s̲p̲o̲n̲s̲i̲b̲i̲l̲i̲t̲i̲e̲s̲
The more special functional responsibilities provided
by the THP, will in the following sections be specified.
2.2.2.1.1 I̲n̲i̲t̲i̲l̲i̲z̲a̲t̲i̲o̲n̲,̲ ̲C̲l̲o̲s̲e̲ ̲D̲o̲w̲n̲ ̲a̲n̲d̲ ̲R̲e̲s̲t̲a̲r̲t̲
The Analysis and Conversion Processes will during
initialization perform the following functions:
- accept configuration parameters from SSC
- initialize data areas
- report subprocess identification to CSF.
The transport processes will perform the same functions
described above, but the initialization of data-areas
is transport-type depending and may include more subprocesses
with individual initialization of coroutines and semaphores.
After initialization the Analysis and Conversion Processes
will be running immediately, while the transport subprocesses
will wait for an individual start-command from SSC;
(see principle section 2.2.2.l.3 as for Restart) this
command will follow an initialization always; the individual
transport subprocesses will then wait for reception
of an incoming channel open ASM before transmission
of messages begins (open of outgoing channel), and
upon a supervisor command for open of the incoming
channel before reception of incoming messages can be
expected - the last described procedures do not include
SCARS, CCIS, PTR and PTP, which will be running immediately
after initialization.
2.2.2.1.2 C̲l̲o̲s̲e̲ ̲D̲o̲w̲n̲
Close Down of the Analysis and the Conversion Processes
will be done immediately after reception of the SSC-command;
this command is detected when the message during analyses
or conversion is finished (if any).
To the Transport Processes are associated two SSC-commands
for Close Down and an individual stop-command:
- Init Close Down
- Final Close Down
- Stop
These commands are detected immediately and may result
in termination of the message during transmission or
reception.
a) I̲n̲i̲t̲ ̲C̲l̲o̲s̲e̲ ̲D̲o̲w̲n̲
No more messages will be transmitted after the
message presently under transmission; no influence
on reception of messages.
b) F̲i̲n̲a̲l̲ ̲C̲l̲o̲s̲e̲ ̲D̲o̲w̲n̲ ̲o̲r̲ ̲S̲t̲o̲p̲
If necessary the messages under transmission and
reception will be terminated (preempted/halted)
and the following functions executed:
- transmission of incoming channel Close ASM
(no change of own incoming status).
- close of outgoing channel
- checkpointing of channel status
- empty circuit-queue
- disconnect from logical channel
2.2.2.1.3 R̲e̲s̲t̲a̲r̲t̲
Restart of the analyses and conversion processes is
the same as initialization. A transport subprocess
is restarted via a START-command from SSC; the following
is then executed:
- connect to logical channel
- read of channel profile associated to that
logical channel.
- read of associated channel status parameters.
- transmission of either a channel OPEN ASM or
channel CLOSE ASM depending on the incoming
channel status.
2.2.2.2 C̲h̲e̲c̲k̲p̲o̲i̲n̲t̲i̲n̲g̲ ̲a̲n̲d̲ ̲R̲e̲c̲o̲v̲e̲r̲y̲
2.2.2.2.1 C̲h̲e̲c̲k̲p̲o̲i̲n̲t̲i̲n̲g̲
a) I̲n̲c̲o̲m̲i̲n̲g̲ ̲M̲e̲s̲s̲a̲g̲e̲
After reception of the EOTF, an incoming message
will be checkpointed.
When the message has been succesfully analyzed
it will be checkpointed again.
b) O̲u̲t̲g̲o̲i̲n̲g̲ ̲M̲e̲s̲s̲a̲g̲e̲
After conversion from the IMF to EMF (ACPl27-format
mostly), the outgoing message is checkpointed.
When the message has been transmitted it will be
checkpointed again.
2.2.2.2.2 R̲e̲c̲o̲v̲e̲r̲y̲
a) I̲n̲c̲o̲m̲i̲n̲g̲ ̲M̲e̲s̲s̲a̲g̲e̲
An incoming message which has not been completely
analyzed or not been delivered to all internal
destinations after analyzes, will be analyzed again.
b) O̲u̲t̲g̲o̲i̲n̲g̲ ̲M̲e̲s̲s̲a̲g̲e̲
As for incoming messages, outgoing messages not
completely routed and converted will be converted
again. Messages for transmission will be transmitted
again with a suspected duplicate pilot, if it is
marked with a recovery flag.
2.2.2.3 E̲r̲r̲o̲r̲ ̲D̲e̲t̲e̲c̲t̲i̲o̲n̲ ̲a̲n̲d̲ ̲E̲r̲r̲o̲r̲ ̲H̲a̲n̲d̲l̲i̲n̲g̲
THP will perform two types of error handling:
- data error handling
- processing error handling
a) D̲a̲t̲a̲ ̲E̲r̲r̲o̲r̲ ̲H̲a̲n̲d̲l̲i̲n̲g̲
If a QEL fetched via a THP-queue is not in accordance
with the QEL/View-type specified for THP-interfaces
(ref.CPS/ICD/009), the QEL (maybe
referencing a message-view) will be sent to the
GAQ-queue served by SSC; there the contents of
the QEL will be dumped at the operator position.
The THP-process will then continue its processing
with the next QEL (message).
b) P̲r̲o̲c̲e̲s̲s̲i̲n̲g̲ ̲E̲r̲r̲o̲r̲ ̲H̲a̲n̲d̲l̲i̲n̲g̲
This type of Error Handling is associated to system-calls.
If an unexpected completion-code is returned from
a system call, SSC will be notified with resulting
retirement of the process.
The unexpected completion-code, the call-type and
the register-contents will be dumped at the operator
position.
2.2.2.4 I̲n̲t̲e̲g̲r̲i̲t̲y̲ ̲o̲f̲ ̲O̲p̲e̲r̲a̲t̲i̲o̲n̲
For an incoming Message, THP will validate all Format
lines and adjust acceptable deviations of an ACP127
- or CCIS E1 - formatted message in order to ensure
the integrity of future operations.
For user prepared outgoing messages all data are assumed
having been validated during preparation.
For complete messages entered from a PTR, and service
messages entered by the Supervisor certain transactions
will be validated. (e.g. routing indicators)
2.2.2.5 D̲a̲t̲a̲ ̲C̲o̲l̲l̲e̲c̲t̲i̲o̲n̲
The following Data Collection will be provided by THP
- Collection of Statistics
- Collection of Retrieval keys
- Collection of Log information
- Reports to Supervisor
THP will collect statistics on the following objects:
- Incoming message
- Invalid incoming message
- Outgoing message
- Channel open/close
THP will collect Retrieval keys on the following objects:
Incoming valid message after analysis
Outgoing message after transmission
Automatically released outgoing message
THP will collect log information on the following objects:
Incoming message
Invalid incoming message
Outgoing message
Channel discontinuity
PTP
THP will generate the following Supervisor Reports:
-Warning Reports
-Channel Reports
2.2.2.6 S̲e̲c̲u̲r̲i̲t̲y̲
When an incoming message is received on a circuit it
will automatically be assigned an access classification
(Queue Profile) equal to the circuit classification.
THP will during the analysis of the message identify
the message classification, and change the access attributes
in accordance with the classification of the message
(if lower); if higher the message is rejected to MSO.
For an outgoing message the RIs are selected in accordance
with the message classifications; before forwarding
the message to transmission, the classification of
the circuit will be compared with the message classification.
If no RI and circuit with proper classification exists,
the message will be sent to an MSO position for re-assignment
with a notification.
Messages having been "cleared" will as outgoing be
considered unclassified, and as incoming minimum confidential.
The considered classifications will be the ones used
during the processing of the message in accordance
with access control through CAMPS; the originally assigned
classification will remain unchanged. THP will in accordance
with this procedure change the classification attributes,
enabling the message to be transmitted.
2.3 C̲H̲A̲R̲A̲C̲T̲E̲R̲I̲S̲T̲I̲C̲S̲
2.3.1 T̲i̲m̲i̲n̲g̲
2.3.1.1 T̲h̲r̲o̲u̲g̲h̲p̲u̲t̲ ̲T̲i̲m̲e̲
The throughput time is for an incoming message from
the time where EOTF is detected until the time where
the message is delivered to either MDP, TEP or punched
at a PTP.
The throughput time is for an outgoing message from
the time where the message is queued to ACP127-conversion
until the time for start of transmission.
The throughput time for a message of average length
(= 1500 characters) with 7 PLA's and 5 RI'S will in
the following be specified.
The CPU time specified for CSF and TMP calls is without
FMS time for disk accesses.
a) I̲n̲c̲o̲m̲i̲n̲g̲ ̲T̲r̲a̲n̲s̲p̲o̲r̲t̲
Direct CPU = 30 ms
20 IOC calls * 20 ms = 400 ms
(using a 80 bytes buffer)
l2 CSF calls * 20 ms = 2̲4̲0̲ ̲m̲s̲
Total CPU: = 670 ms
======
Write message = 3 access
Read field(sector boundary) = l -
Checkpointing = ̲ ̲l̲ ̲ ̲ ̲-̲ ̲
̲ ̲ ̲ ̲
Total Disk-access: = 5 accesses
= ============
b) A̲n̲a̲l̲y̲s̲i̲s̲
Direct CPU = 60 ms
l8 CFS calls * 20 ms = 360 ms
l5 TMP calls * 20 ms = 3̲0̲0̲ ̲m̲s̲
Total CPU: = 720 ms
= ======
Read message = l access
Write message = l -
Table-search (l AIG + l PLA) = 2 -
Checkpointing = ̲ ̲l̲ ̲ ̲ ̲-̲ ̲
̲ ̲ ̲ ̲
Total Disk-access: = 5 accesses
============
c) C̲o̲n̲v̲e̲r̲s̲i̲o̲n̲
cl) F̲i̲r̲s̲t̲ ̲C̲o̲n̲v̲e̲r̲s̲i̲o̲n̲:̲
Direct CPU = 50 ms
l0 CSF calls * 20 ms = 200 ms
20 TMP calls * 20 ms = 4̲0̲0̲ ̲m̲s̲
Total CPU: = 650 ms
======
Read Message = l access
Write Message = l -
Table search (7 * pla/ref
in one access) = 7 -
Checkpointing = ̲ ̲2̲ ̲ ̲ ̲-̲ ̲
̲ ̲ ̲ ̲
Total disk-access: = ll accesses
===========
c2) A̲d̲d̲i̲t̲i̲o̲n̲a̲l̲ ̲C̲o̲n̲v̲e̲r̲s̲i̲o̲n̲ ̲(̲p̲e̲r̲ ̲c̲i̲r̲c̲u̲i̲t̲)̲
Direct CPU = 20 ms
4 CSF calls * 20 ms = ̲ ̲8̲0̲ ̲m̲s̲
Total CPU = l00 ms
=======
Write Message = l access
Checkpointing = ̲ ̲ ̲l̲ ̲ ̲-̲ ̲
̲ ̲ ̲ ̲ ̲ ̲
Total disk-access = 2 accesses
=============
d) O̲u̲t̲g̲o̲i̲n̲g̲ ̲T̲r̲a̲n̲s̲p̲o̲r̲t̲
Direct CPU = 20 ms
20 IOC calls * 20 ms = 400 ms
(using a 80 bytes buffer)
12 CSF calls * 20 ms = 240 ms
1 TMP calls * 20 ms = ̲ ̲2̲0̲ ̲m̲s̲
Total CPU: = 700 ms
=======
Read message = 3,5 access
Checkpointing = ̲l̲,̲o̲ ̲-̲ ̲ ̲
̲ ̲ ̲ ̲
Total Disk-acces: = 4,5 accesses
=============
2.3.l.2 R̲e̲s̲p̲o̲n̲s̲e̲ ̲T̲i̲m̲e̲
Response time estimates are for THP related to Message
Service assistance; after each type of assistance a
completion is returned to the MSO invoked (acknowledgement
or message for further assistance).
Provided that a disk-access takes 50 ms, the analysis
of an incoming average message will take 1 second without
interrupts.
Under the same conditions as above, the conversion
of an outgoing average message resulting in 2 transmissions
will take l,5 seconds.
Because messages returned from MSO-assistance are processed
before other messages, the response time, taking into
account the message at that moment being analyzed or
converted, are:
Incoming MSO = 2 seconds
Outgoing MSO = 3 seconds
Above estimated figures are without system-interrupts.
2.3.l.3 P̲r̲i̲o̲r̲i̲t̲i̲e̲s̲ ̲i̲m̲p̲o̲s̲e̲d̲ ̲b̲y̲ ̲I̲n̲p̲u̲t̲
THP will process incoming messages in the sequence
of arrival independent of the message precedence, but
after analysis, queue the message for distribution
by precedence.
Outgoing messages will be processed after the same
principles during conversion, but be queued for transmission
by precedence.
Messages reentered from MSO-assistance will be processed
before all other messages.
Commands will be executed before messages.
2.3.2 T̲h̲r̲o̲u̲g̲h̲p̲u̲t̲
The THP shall support the following throughput (in
busy minute, busy hour, 24 hour period)
30,600…0e…x)…0f…,3000 Incoming messages for analysis
6,180…0e…xx)…0f…,900 Outgoing messages for conversion
x) incl. 15 comments but not 150 VDU-pages
xx) incl. VDU-pages and 15 comments
2.3.3 F̲l̲e̲x̲i̲b̲i̲l̲i̲t̲y̲
In general the software structure of THP has been built
up after structured methods, which in itself makes
the package flexible to maintain and makes it easy
to incorporate new software.
Especially, the structure of the ACP127-analysis shall
be emphazised. The logic related to that processing
is of very complex nature, where future changes to
requirements have been foreseen by developing an analysis
guide table; one for messages in ACP127 format and
one for messages in CCIS E1 format.
The ACP127-conversion software can be expanded to convert
any message format.
The transport software has been structured in a manner
where only the top level software shall be changed
in order to create a new transport process type.
2.3.4 A̲c̲c̲u̲r̲a̲c̲y̲ ̲a̲n̲d̲ ̲V̲a̲l̲i̲d̲i̲t̲y̲
THP has no requirements to accuracy for incoming messages.
Any piece of data will be accepted; should a piece
of data, however, turn out not to be one of the acceptable
formatted message types, it is the responsibility of
THP to reject such data (e.g. garble correction).
Messages sent to ACP127-conversion as outgoing from
a release position has to be accurate; no check for
validity will be performed for such messages because
they are expected to be proper validated by TEP before
the release. Abbreviated and normal service messages
entered from a supervisor position will be accepted
with certain erroneous data-elements for ACP127-conversion
(e.g. unknown routing indicators)
3̲ ̲ ̲E̲N̲V̲I̲R̲O̲N̲M̲E̲N̲T̲
3.1 E̲Q̲U̲I̲P̲M̲E̲N̲T̲
3.2 S̲O̲F̲T̲W̲A̲R̲E̲
3.2.1 S̲y̲s̲t̲e̲m̲ ̲S̲o̲f̲t̲w̲a̲r̲e̲
The system software used by this package is the software
included in the following packages:
- CSF
- IOC
- SSC
3.2.2 D̲e̲v̲e̲l̲o̲p̲m̲e̲n̲t̲ ̲S̲u̲p̲p̲o̲r̲t̲ ̲S̲o̲f̲t̲w̲a̲r̲e̲
The software used for development of this package is
the software supported by the Support Software Package.
3.3 I̲N̲T̲E̲R̲F̲A̲C̲E̲S̲
3.3.1 E̲x̲t̲e̲r̲n̲a̲l̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲s̲
The Traffic Handling package interfaces via IOC the
following external Systems, Telegraph Circuits and
Devices:
a) N̲I̲C̲S̲ ̲T̲A̲R̲E̲
Ref. CPS/230/ICD/0004
b) S̲C̲A̲R̲S̲
Ref. CPS/230/ICD/0005
c) C̲C̲I̲S̲
Ref. CPS/230/ICD/0006
d) T̲R̲C̲/̲P̲o̲i̲n̲t̲-̲t̲o̲-̲P̲o̲i̲n̲t̲
Ref. CPS/230/ICD/0007
e) P̲T̲R̲
f) P̲T̲P̲
g) L̲o̲w̲ ̲S̲p̲e̲e̲d̲ ̲T̲e̲l̲e̲p̲r̲i̲n̲t̲e̲r̲
3.3.2 P̲a̲c̲k̲a̲g̲e̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲s̲
In the following the package interfaces with other
application packages and SSC will be identified (except
system-interfaces to CSF and IOC)
Ref. figure 2.1.1 for overview.
3.3.2.1 I̲n̲t̲e̲r̲f̲a̲c̲e̲ ̲M̲D̲P̲
- Incoming messages for local distribution
- Outgoing messages for local distribution.
3.3.2.2 I̲n̲t̲e̲r̲f̲a̲c̲e̲ ̲T̲E̲P̲
a) T̲E̲P̲ ̲t̲o̲ ̲T̲H̲P̲
- Outgoing released messages for routing and
conversion
- Supervisor prepared service messages for conversion.
- Supervisor initiated rerun.
- Supervisor initiated channel control
- Comments and VDU-pages for distribution to
SCARS/CCIS
- Reenterings from message service
- Supervisor initiated readdressal
b) T̲H̲P̲ ̲t̲o̲ ̲T̲E̲P̲
- Incoming service messages to be printed at
the supervisor position.
- Reports to be printed at the supervisor position.
- Message service invocation for:
Garble Correction
Message Inspection
3.3.2.3 I̲n̲t̲e̲r̲f̲a̲c̲e̲ ̲S̲A̲R̲
Delivery of retrieval-keys associated with incoming
(messages before conversion to internal format) and
after conversion to external format for outgoing messages.
3.3.2.4 I̲n̲t̲e̲r̲f̲a̲c̲e̲ ̲L̲O̲G̲
- Incoming message logs (valid and invalid)
- Outgoing message logs
- Channel Discontinuity log
3.3.2.5 I̲n̲t̲e̲r̲f̲a̲c̲e̲ ̲S̲T̲P̲
- Statistics incoming message
- Statistics outgoing message
- Statistics channel availability
3.3.2.6 I̲n̲t̲e̲r̲f̲a̲c̲e̲ ̲T̲M̲P̲
The following parameters and tables controlled by TMP
are used by this package:
- AIG-table
- PLA-tables
- RI-tables
- Circuit table
- Channel Profiles
- ACP127 parameters
- Global Number Series (TSN + SSN)
- Network table
- Connectivity table
- Channel Status table
- Device Profile…86…1 …02… …02… …02… …02…
3.3.2.7 I̲n̲t̲e̲r̲f̲a̲c̲e̲ ̲S̲S̲C̲
SSC interfaces THP for close-down and start-up
(= Initialization).
The Transport subpackage is interfaced with a start
and stop-command associated to individual channels,
too.
3.4 F̲U̲N̲C̲T̲I̲O̲N̲S̲ ̲M̲A̲I̲N̲T̲A̲I̲N̲E̲D̲ ̲B̲Y̲ ̲O̲T̲H̲E̲R̲ ̲P̲A̲C̲K̲A̲G̲E̲S̲
The functions maintained by other packages are the
functions related to the operating system.
a) C̲A̲M̲P̲S̲ ̲S̲y̲s̲t̲e̲m̲ ̲F̲u̲n̲c̲t̲i̲o̲n̲s̲ ̲(̲C̲S̲F̲)̲
- Checkpointing
- Control of access rights related to queues
- Timer functions
- Access and access control to files (messages)
- Automatic deletion of CTS and atomal messages.
b) I̲n̲p̲u̲t̲/̲O̲u̲t̲p̲u̲t̲ ̲C̲o̲n̲t̲r̲o̲l̲ ̲(̲I̲O̲C̲)̲
- Access to external channels and devices
4̲ ̲ ̲P̲A̲C̲K̲A̲G̲E̲ ̲D̲E̲S̲I̲G̲N̲
4.1 P̲A̲C̲K̲A̲G̲E̲ ̲O̲V̲E̲R̲V̲I̲E̲W̲
In overview the Traffic Handling Package consists of
3 main areas with completely different functional capabilities:
- ACP127 analysis
- ACP127 conversion
- Transport
The transport functions consist of 3 subfunctions:
- Outgoing Transport
- Transport Control
- Incoming Transport
As shown in figure 4.1-1 the Traffic Handling Package
has been separated into the following subpackages:
1) ACP127 Analysis Subpackage(AAS)
2) ACP127 Conversion Subpackage(ACS)
3) Transport Subpackage(TRS)
4) Transport Control Subpackage(TCS)
5) Incoming Transport Subpackage(ITS)
6) Outgoing Transport Subpackage(OTS)
FIGURE 4.1-1…01…PACKAGE OVERVIEW
4.1.1 F̲U̲N̲C̲T̲I̲O̲N̲A̲L̲ ̲S̲P̲E̲C̲I̲F̲I̲C̲A̲T̲I̲O̲N̲
In the following the functions associated to the groups
specified in package overview, will be identified.
- ACP127 Analysis Functions
- ACP127 Conversion Functions
- Transport Functions
The Transport Functions associated with the following
transport types will be described separately in section
4.2.3.l
- NICS TARE Transports
- TRC/Point-to-point Transports
- SCARS/CCIS Transports
- PTR Transport
- PTP Transport
At last the common functions identified between the
subpackages will be specified.
4.1.1.1 A̲C̲P̲1̲2̲7̲ ̲A̲n̲a̲l̲y̲s̲i̲s̲ ̲F̲u̲n̲c̲t̲i̲o̲n̲s̲
The main functions associated to ACP127-analysis are
as depicted in figure 4.1.1.1-1.
Messages to be analysed are received as:
1) Incoming messages via NICS TARE, TRC/Point-to-point
or SCARS/CCIS.
2) Complete outgoing messages via low speed teleprinters
(operating as PTR's)
3) Complete outgoing or incoming messages entered
via the dedicated PTR.
The above described types received for analysis, forms
3 analysis types with individual and common functions
as well.
Fig 4.1.1.1-1 FUNCTIONS ACP 127-ANALYSIS
A separate description of individual and common functions
between the analysis-types will be specified in section
4.2.1.
In general the function of ACP127 analysis are:
a) Initiate the analysis corresponding to the type
(incoming, complete or PTR analysis)
- set up analysis guide table
- determination of message type.
b) Error Handling
- errors during transport
- unknown message type
c) Format line detection and control of incoming messages
received in CCIS E1 format.
- Garble and E1-pilot detection
- Handling of Comments, VDU pages, messages for
coordination, messages for release and released
messages.
d) Format line detection and control of messages in
ACP127 format plus messages in SCARS/CCIS E1 format
from FL5.
- Garble, Pilot, readdressal and relay detection.
- Relaying and handling of incoming ASM's.
e) Flash acknowledge procedures for incoming messages.
f) Internal format conversion, e.g. conversion to
E1-format for incoming messages.
g) Log, statistics and retrieval keys for incoming
messages.
h) Determine to where the message shall be directed
after analysis.
4.l.l.2 A̲C̲P̲1̲2̲7̲ ̲C̲o̲n̲v̲e̲r̲s̲i̲o̲n̲ ̲F̲u̲n̲c̲t̲i̲o̲n̲s̲
The main functions associated to ACP127-conversion
are as depicted in fig. 4.l.l.l.l-2.
Outgoing messages are received in the internal message
format as:
- User prepared Plaindress, Plaindress-Data, SC-Comments
and VDU-pages for conversion.
- Supervisor prepared service message for conversion.
- Supervisor retrieved plaindress message for readdressal.
- Supervisor retrieved complete message for rerun.
- Complete outgoing message for conversion
(via analysis).
- Complete incoming message for relaying
(via analysis)
- Complete message for rerouting
(via outgoing transport)
The difference between complete and prepared messages
are in general:
- a complete message contains pre-selected RI's;
the prepared message does not.
- a complete message is not sectioned, because it
is entered in sections.
- a complete message cannot be cleared during RI-assignment;
this should be done when entering the message.
Fig. 4.1.1.1-2 FUNCTIONS ACP127-CONVERSION…86…1 …02… …02… …02… …02…
a) R̲o̲u̲t̲i̲n̲g̲ ̲F̲u̲n̲c̲t̲i̲o̲n̲s̲
l) Allocation of circuit to SCARS/CCIS comments
and VDU-pages based on SCD.
2) Exemption of RI's not to be used when a message
is received for relaying, rerouting or rerun.
3) Allocation of circuits associated to preselected
RI's of an complete entered message and a supervisor
prepared (not plaindress) Service Message.
4) Selection of RI's among up to 4 alternatives
associated to an PLA/AIG of Camps prepared
messages in plaindress, and released messages
received from CCIS.
If above described functions cannot be fulfilled
due to:
- too low RI-classification
- too low Circuit-classification
- Circuit not available,
the message is sent to MSO for RI-assignment.
b) F̲o̲r̲m̲a̲t̲t̲i̲n̲g̲ ̲F̲u̲n̲c̲t̲i̲o̲n̲s̲
l) Formatting of FLC and FLD1 of all messages
bound for CCIS, and formatting of SC-Comments
and VDU-pages into SCARS/CCIS E1 format.
2) Formatting of the header preamble part of a
message in ACP127-format (FL2-FL4) including
regeneration of a pilot (FLA-FLC) if the message
was received with such.
3) Formatting of the header part containing addresses
of a message in ACP127-format (FL1-FL10) including
formatting of the format-lines of a readdressed
message.
4) Formatting of the text preamble part of an
Camps originated message of plaindress-type
(FL12A-FL12E).
c) T̲r̲a̲f̲f̲i̲c̲ ̲S̲e̲p̲a̲r̲a̲t̲i̲o̲n̲ ̲F̲u̲n̲c̲t̲i̲o̲n̲s̲
l) Separation in more sections (= transmissions)
when too long camps originated
PLAINDRESS OR PLAINDRESS ̲SERVICE.
2) Separation in more transmissions when the RI's
of FL2
- associates to multiple circuits
- exeeds 200
if this occurs, the operating signal "ZEN"
will be inserted in front of the not involved
PLA's of FL7/FL8 in each transmission.
Should the message for transmission carry the special
handling designator CRYPTO SECURITY or have been assigned
an punch-instruction during RI-assignment by MSO, the
message will be sent to the dedicated PTP for punch
instead of transmission.
4.l.l.3 T̲r̲a̲n̲s̲p̲o̲r̲t̲ ̲F̲u̲n̲c̲t̲i̲o̲n̲s̲
In principle the transport functions form is a circle
around the ACP127-analysis and the ACP127-conversion
functions.
Example:
Complete entered message via a PTR
l) The message is transported to ACP127 analysis.
2) After analysis the message is directed for ACP127
conversion.
3) Having converted the message it is again delivered
to transport for transmission to maybe NICS TARE.
In order to make the transport functions more simple
to overview, 3 subpackages have been identified all
containing functions that cross the transport-types.
These functions are detailed described in section 4.2.4,
4.2.5 and 4.2.6.
The main functions associated to Transport are depicted
in fig. 4.l.l.l.l-3.…86…1 …02… …02… …02… …02…
Fig. 4.1.1.1.1-3 FUNCTIONS TRANSPORT
a) T̲r̲a̲n̲s̲p̲o̲r̲t̲ ̲C̲o̲n̲t̲r̲o̲l̲
l) Control of the outgoing transport for start
transmission, stop transmission, preemption
or send automatic ASM.
Control of the incoming transport for stop
reception and start reception.
2) Procedures associated to internal THP commands
(from analysis) when arrival of:
- channel open ASM
- channel close ASM
- channel Test ASM
- channel Test Reply ASM
- channel Number Check ASM
- Flash Acknowledge
- Message with precedence flash
3) Procedures associated to external THP commands
of type:
- stop incoming traffic
- start incoming traffic
- close-down
- stop external channel
- open external channel
4) Time-out procedures for flash acknowledgement,
transaction acknowledge and channel continuity.
b) I̲n̲c̲o̲m̲i̲n̲g̲ ̲T̲r̲a̲n̲s̲p̲o̲r̲t̲
l) Communication with IOC for reception of data-frames.
2) Assembling of the data-frames into messages.
3) Procedures associated to reception errors
- halted message
- preempted message
- l40 identical characters
- too long message
- too long line
- TSN discontinuity FL1
4) Detection of certain characteristic Format-lines
and removal of BT,
page-identifications and EOTF.
c) O̲u̲t̲g̲o̲i̲n̲g̲ ̲T̲r̲a̲n̲s̲p̲o̲r̲t̲
l) Communication with Transport Control
(ref. 4.l.l.3.a1).
2) Forward data frames to IOC for transmission
derived from message fetched in a circuit-queue
or selfgenerated automatic ASM.
3) Generation and insertion of the following data-elements
to each message where applicable:
- FL1 with TI
- Pilot(suspected dublicate)
- FL11 and FL13 (BT)
- FL14 and FL15 (GR and SSN)
- FL16 (NNNN)
4) Generation and transmission of an ASM as specified
by transport control.
4.l.l.4 C̲o̲m̲m̲o̲n̲ ̲F̲u̲n̲c̲t̲i̲o̲n̲s̲
The common funtions identified are mainly within a
subpackage. The common functions will therefore be
described under subpackage specification for that subpackage.
The remaining common function between the subpackages
of THP can be located at a very low level.
These are auxiliary functions like
- Convert binary to ASCII
- Compare String
4.l.2 S̲o̲f̲t̲w̲a̲r̲e̲ ̲S̲t̲r̲u̲c̲t̲u̲r̲e̲
The external environment for THP consists of circuits
and channels. A circuit is a group of similar channels.
Figure 4.l.2-2 shows the process and queue structure
for THP. Figure 4.l.2-l shows the general software
and queue structure for a circuit. Each channel is
managed by a transport process. Messages to be transmitted
on a circuit it sent to a circuit queue, which is shared
by the transport processes belonging to the circuit.
Each transport process has further a private command
queue where it can receive commands from SSC, timer
events etc. The number of external channels may be
up to 32.
An overview of the Traffic Handling structure is depicted
in fig. 4.2.l-3.
This drawing illustrates the break-down into processes
and coroutines.
There are:
a) Analysis Process
b) Conversion Process
c) Transport Processes each consisting of one
- Transport Control Coroutine
- Incoming Transport Coroutine (not PTP)
- Outgoing Transport Coroutine (not PTR)
The break-down into modules is specified in the subpackages
(ref. 4.2.l.l, 4.2.2.l, 4.2.3.l,
4.2.4.l, 4.2.5.l and 4.2.6.l).
4.l.2.l A̲n̲a̲l̲y̲s̲i̲s̲ ̲Q̲u̲e̲u̲e̲
The analysis queue consists of 4 subqueues in the following
arrangement:
- First subqueue is dedicated commands from SSC (close-down).
- Second subqueue is used for reentering of messages
from a MSO-position after garble-correction or
message-inspection.
- Third subqueue is the ordinary message-queue where
an Incoming Transport will deliver a received incoming
message.
- Fourth subqueue is dedicated log completion acknowledgement
and used after collection of an incoming message
log.
The access-profile of the analysis queue is set to
maximum capabilities.
4.l.2.2 C̲o̲n̲v̲e̲r̲s̲i̲o̲n̲ ̲Q̲u̲e̲u̲e̲
The conversion queue consists of 3 subqueues in the
following arrangements:
- First subqueue is dedicated commands from SSC (close-down).
- Second subqueue is used for rentering of messages
from a MSO-position after RI-assignment and entering
of service messages from a supervisor position.
- Third subqueue is for all other messages for conversion.
The access-profile of the conversion queue is set to
maximum capabilities.
4.l.2.3 C̲h̲a̲n̲n̲e̲l̲ ̲a̲n̲d̲ ̲C̲i̲r̲c̲u̲i̲t̲ ̲Q̲u̲e̲u̲e̲s̲
a) C̲i̲r̲c̲u̲i̲t̲ ̲Q̲u̲e̲u̲e̲
A circuit queue has 6 subqueues corresponding to
6 precedence levels. It is shared by the transport
processing of the circuit. If the circuit consists
of a single channel, there is flash preemption.
If there is more than one channel, flash preemption
will not take place.
Messages are sent to the circuit queue by ACP127
conversion. When a flash message is sent to a single-channel
circuit, a flash notification will be sent to the
channel command queue as well.
b) C̲h̲a̲n̲n̲e̲l̲ ̲C̲o̲m̲m̲a̲n̲d̲ ̲Q̲u̲e̲u̲e̲
A Channel Command Queue consists of two subqueues.
- The primary subqueue is for commands that requires
no resources and of type upon which immediate action
can or shall be taken (stop traffic, preempt message
etc.).
- The secondary subqueue is for commands that requires
some resources. (send flash acknowledge, send test
reply etc.).
The access-profile for Circuit and Command Control
Queues are equal to the Circuit Classification. All
special handling categories are included.
c) P̲u̲n̲c̲h̲ ̲Q̲u̲e̲u̲e̲s̲
To the dedicated punch is associated a "circuit-queue"
and a "command-control-queue" as described above.
The access-profile for the Punch Queues are to maximum
capabilities.…86…1 …02… …02… …02… …02…
Fig. 4.1.2-2…86…1 …02… …02… …02… …02…
Fig. 4.1.2-2 OVERVIEW TRAFFIC HANDLING STRUCTURE
4.l.3 D̲a̲t̲a̲ ̲F̲l̲o̲w̲ ̲a̲n̲d̲ ̲C̲o̲n̲t̲r̲o̲l̲ ̲L̲o̲g̲i̲c̲
The Data Flow and Control Logic of the Traffic Handling
Package is closely related to the message flow of CAMPS
and especially with the handling of messages in ACP127-format;
for details concerning message types, specific format-lines
and parameters contained in these, ref. CPS/ICD/003.
The descriptions in this section will concentrate on
this message flow and the cooperation between the THP-subpackages
involved.
4.l.3.l M̲e̲s̲s̲a̲g̲e̲ ̲F̲l̲o̲w̲
The message flow will in the following be illustrated
and described in general cases/pictures; the purpose
is to provide a general understanding of the mechanisms
involved in message processing - not to supply a complete
detailed flow showing all possible situations and interfaces.
The drawings and the cases illustrated are kept simple;
special procedures are added to the flow where convenient,
but some of these procedures could just as well have
been described in another drawing illustrating the
flow of a different message type.
4.l.3.l.l O̲u̲t̲g̲o̲i̲n̲g̲ ̲E̲n̲c̲r̲y̲p̲t̲e̲d̲ ̲M̲e̲s̲s̲a̲g̲e̲
See flow fig. 4.l.3.l-l.
Special procedures: Flash procedure with ZGC FL4.
l) PLAINDRESS with special handling = CRYPTO SECURITY
from releasing officer or PLAINDRESS with punch-instruction
reentered from message service after RI-assignment.
2) MDP for local distribution based upon SCD and local
PLA (if any).
3) After conversion to ACP127-format queuing to dedicated
PTP with instruction for insert of "Dummy FL1"
(SOTF only).
4) If Flash precedence, FLASH ̲NOTIFICATION to PTP-transport-controller.
5) Preemption command to PTP-outgoing-transport
6) PTP log
7) Punched tape for off-line encryption
8) Reentering of new papertape with a message in CODRESS
OR PLAINDRESS ̲ENCRYPTED ACP127-format via the dedicated
PTP.
9) Analysis of the encrypted message
l0) Determined to be an outgoing message because of
incomplete FL1.
11) Again conversion to ACP127-format, but this time
the routing succeeds because the message is now
UNCLASSIFIED.
12) If Flash precedence, FLASH ̲NOTIFICATION to the
transport-controller.
13) Preemption Command to the outgoing Transport.
14) Statistics and Log outgoing message after transmission.…86…1
…02… …02… …02… …02…
Fig 4.1.3.1-1
4.l.3.l.2 I̲n̲c̲o̲m̲i̲n̲g̲ ̲E̲n̲c̲r̲y̲p̲t̲e̲d̲ ̲M̲e̲s̲s̲a̲g̲e̲
See flow fig. 4.l.3.l-2
Special procedures: Relaying
1) Incoming unidentified message received via an external
channel.
2) Incoming message Log and statistics.
3) If relay-instructions and received from NICS ̲TARE
or TRC/Point-to-point queuing to conversion for
relaying as CODRESS or PLAINDRESS ̲ENCRYPTED.
If received from SCARS and external RI's FL2, then
same procedure and message-types.
If received from CCIS and already released, then
the message-type for conversion is SC ̲PLAINDRESS
̲ENCRYPTED (selective routing).
4) After relaying or conversion the message is queued
for transmission as CODRESS or PLAINDRESS ̲ENCRYPTED.
5) Outgoing message Log and statistics.
6) Queuing to dedicated PTP with the message-type
determined during analysis
7) PTP Log
8) Off-line decryption using the punched tape.
9) Reentering in ACP127-format using the tape after
off-line decryption.
l0) Analysis of the message determined to be incoming
because of complete FL1, and of type PLAINDRESS
even if FL10 with "GR(SB)" is present.
11) Storage as an incoming message
12) MDP for incoming message distribution based on
HQ/SIC.…86…1 …02… …02… …02… …02…
Fig. 4.1.3.1-2
4.l.3.l.3 C̲o̲m̲p̲l̲e̲t̲e̲ ̲O̲u̲t̲g̲o̲i̲n̲g̲ ̲M̲e̲s̲s̲a̲g̲e̲
See flow fig. 4.l.3.l-3
1) Entering of an off-line prepared papertape containing
a complete formatted message in ACP127; the message
contains dummy-values for SOTF, DTG, SSN and Filing-time
(=VZCZC, any legal DTG, 0000 and any legal filing-time).
2) The unidentified message is queued for analysis
if SOTF and EOTF has been detected - otherwise
a report is sent to the Supervisor Printer.
3) If the message-type could not be determined or
some analysis-errors were detected, the message
is sent for garble-correction.
4) Reentering of the UNIDENTIFIED message after garble
correction.
5) After successful analysis the message is forwarded
to conversion with its determined message-type,
and an automatic release indication.
6) Storage of the automatic released message.
7) Queuing for transmission
8) Outgoing message Log and Statistics.
Storage of outgoing message.…86…1 …02… …02… …02…
…02…
Fig. 4.1.3.1-3
4.l.3.l.4 I̲n̲c̲o̲m̲i̲n̲g̲ ̲P̲l̲a̲i̲n̲d̲r̲e̲s̲s̲ ̲M̲e̲s̲s̲a̲g̲e̲
See flow fig. 4.l.3.l-4
Special procedures:
- more than 140 consecutive identical characters
- Partly misrouted
1) The message received via a TRC/Point-to-point channel
contains 140 identical characters. The message
is terminated by detect of this and a report sent
to the Supervisor Printer.
2) Command to Transport Controller.
3) If required by system parameters the outgoing transport
is instructed to generate and transmit an Identical
Character ASM.
4) Outgoing Log and statistcs of generated ASM.
5) Unidentified message for analysis with reception-notification
= IDENTICAL ̲CHARACTERS.
6) Incoming invalid Log and statistics using the reception-error
as problem-code.
7) Message Service for garble correction
8) Reentering from grable correction.
9) Incoming Log, statistics and storage.
l0) MDP for distribution based on HQ/SIC
11) Because FL2 contained an not local RI and the message
has been inspected by MSO it is assumed that the
message is misrouted (MSO would have removed the
not local RI otherwise) and it is queued for conversion.
12) After conversion queuing for transmission.
13) After transmission outgoing message Log, statistics
and storage.…86…1 …02… …02… …02… …02…
Fig. 4.1.3.1-4
4.l.3.l.5 I̲n̲c̲o̲m̲i̲n̲g̲ ̲D̲a̲t̲a̲ ̲M̲e̲s̲s̲a̲g̲e̲s̲
See flow fig. 4.l.3.l-5
Special procedures:
- TSN Lower than expected
- Repeated garble correction
- Flash acknowledgement
1) Discontinuity Log because of lower TSN of FL1 than
expected (same procedure applies for missing TSN).
2) Supervisor Report too low TSN
3) Unidentified message for analysis with reception-notification
= TI ̲INSPECTION.
4) Invalid message Log and statistics using the reception
̲notification as problem-code.
5) Message Service for inspection via the Common Incoming
MSO-queue;
- the incoming MSO will try to retrieve a message
using the TI of FL1; if he succeeds and the
message is identical to the one for inspection,
he will kill the message inspected.
6) The message is reentered to analysis without changes
(not possible during inspection).
7) Some analysis-errors are again detected; invalid
message Log and statistics with the reason UNKNOWN
̲MESSAGE ̲TYPE or ANALYSIS ̲ERROR.
8) Incoming Message Service for Garble Correction
to the same position as for inspection.
9) Reentering of the message after garble correction.
10) Incoming Log, statistics and storage
11) Because message of procedure flash (ZGC not detected
as the first operating signal of FL4) a command
= SEND ̲FLASH ̲ACK is forwarded to the transport
controller.
12) Command to outgoing transport to generate and transmit
the FLASH ̲ACK
13) Outgoing Log and statistics of the automatic generated
ASM
14) MDP for distribution of the Data-message based
on HQ/SIC.…86…1 …02… …02… …02… …02…
Fig. 4.1.3.1-5
4.l.3.l.6 I̲n̲c̲o̲m̲i̲n̲g̲ ̲S̲e̲r̲v̲i̲c̲e̲ ̲M̲e̲s̲s̲a̲g̲e̲
See flow fig. 4.l.3.l-6
Special Procedures:
- TSN higher than expected
- Pilot inspection
- External distribution
1) Discontinuity Log because of higher TSN of FL1
than expected.
Expected TSN reset to the received TSN.
2) Supervisor Report too high TSN
3) Unidentified message received from NICS ̲TARE or
TRC/Point-to-point for analysis (no reception-errors
attached).
4) No errors detected during analysis, but a pilot
has been detected.
Invalid message Log and statistics with reason
= PILOT ̲DETECTED.
5) Message Service for inspection,
- The incoming MSO will try to retrieve a message
using DTG, SSN and TOC; if he succeeds and
the message is identical to the one for inspection,
he will kill the message inspected.
6) The message is reentered as received from analysis.
7) Incoming Log, statistics and storage.
8) The Service Message of type PLAINDRESS ̲SERVICE,
ABB ̲PLAINDRESS ̲SERVICE or ASM (not recognized for
automatic internal handling) is queued for print-out
at the Supervisor position.
9) Because an SCARS RI is detected in FL2, the message
is forwarded to conversion for external distribution.
10) Queuing for transmission
11) Outgoing Log, statistics and storage…86…1 …02…
…02… …02… …02…
Fig. 4.1.3.1.6
4.l.3.1.7 I̲n̲c̲o̲m̲i̲n̲g̲ ̲M̲e̲s̲s̲a̲g̲e̲ ̲f̲r̲o̲m̲ ̲C̲C̲I̲S̲
See flow fig. 4.l.3.l-7
Special procedures:
- Transaction acknowledgement
- Handling of messages for coordination,
for release, comments and VDU-pages.
1) Having received EOTF of the incoming message from
CCIS, the Incoming Transport gives the command
SEND ̲TRANSACTION ̲ACK to the Transport Controller.
2) The Send-Transaction-Command is forwarded to the
outgoing Transport, who will actually generate
the transaction and transmit it.
3) The received unidentified message is queued for
analysis.
4) During analysis the message-type may be determined
as following, and data-collection performed accordingly:
SC ̲PLAINDRESS; Log, statistics and Storage
SC ̲PLAINDRESS ̲DATA; log, statistics and storage
SC ̲COMMENT; Log statistics and storage
SC ̲VDU ̲PAGE; Log and statistics
5) After analysis (and possible MSO-invocations for
Inspection/Garble-correction) the message is forwarded
to the following destinations inside CAMPS:
- SC ̲PLAINDRESS, SC ̲PLAINDRESS ̲DATA and SC ̲COMMENT
to MDP for distribution using SCD.
- SC ̲VDU ̲Page to UMAM (TEP) for storage in the
VDU-page data base.
- In addition, if any SCD also to MDP for distribution.
The Plaindress or Data Message delivered to MDP
might be for coordination or for release; when
these activities have been performed, the message
will leave Camps as an ordinary Camps originated
message (through Conversion).
The procedures for an already released message
received from CCIS is to forward the message directly
for conversion with the message-type determined
during analysis; the message type is kept as a
signal for selective routing procedures to be involved.…86…1
…02… …02… …02… …02…
Fig. 4.1.3.1-7
4.l.3.l.8 O̲u̲t̲g̲o̲i̲n̲g̲ ̲P̲l̲a̲i̲n̲d̲r̲e̲s̲s̲ ̲M̲e̲s̲s̲a̲g̲e̲
See flow fig. 4.l.3.l-8
Special procedures:
- Circuit classification too low
- RI-assignment and Clear.
1) The message prepared at a user position is entered
to Conversion after release.
2) An RI associated to a PLA is selected with proper
classification - however the circuit classification
is too low; this inconsistency is reported to the
Supervisor.
3) The message is forwarded to the outgoing MSO for
RI-assignment.
4) The MSO decides to CLEAR the message, assigns a
CLEAR ̲INSTRUCTION and reenters the message for
conversion.
5) Now the routing succeeds, and the message is sent
for local distribution based on local SCD/Local
PLA (if any) in the Internal Message Format
6) Also the message is forwarded for transmission
in as many copies necessary to include all destinations.
7) Outgoing Log, statistics and storage of each transmitted
message.…86…1 …02… …02… …02… …02…
Fig. 4.1.3.1-8
4.l.3.l.9 O̲u̲t̲g̲o̲i̲n̲g̲ ̲S̲e̲r̲v̲i̲c̲e̲ ̲M̲e̲s̲s̲a̲g̲e̲
See flow fig. 4.l.3.l-9
Special procedures:
- RI-validation (unknown RI)
- RI-assignment (too low RI-class).
- Flash message transmitted
1) The Service Message of type ASM or Abbreviated
plaindress is entered from a Supervisor position
for conversion.
- the message is prepared using RI's opposite
to an PLAINDRESS ̲SERVICE where PLA's have been
used.
2) During Routing procedures an unknown RI is detected;
the message is therefore returned to the drafter
(Supervisor) for correction.
3) Supervisor reenters the service message having
corrected the RI.
4) The RI selected by Supervisor is now known, but
the classification of the route too low, so the
expert in this area - the outgoing MSO - takes
over the responsibility.
5) The message is reentered from RI-assignment by
MSO; possiblely with an relay-instruction forcing
the message to be transmitted on another circuit,
where this receiver will forward the message to
its original destination.
6) Storage of the automatic released Service Message.
7) Queuing for transmission
8) Because message of flash precedence, FLASH ̲NOTIFICATION
to the Transport Controller.
9) Preemption command to the Outgoing Transport.
10) Outgoing Log, statistics and storage after transmission.
11) If no flash-acknowledge ASM has been received within
a specified time, a report is sent to the Supervisor
Printer and the message dismantled.
12) An unidentified message is received and queued
for analysis.
13) The message-type is determined to be an ASM, and
the ASM-type to be an Flash-acknowledge.
- Incoming Log, statistics and storage.
14) Report to the Transport Controller:
FLASH ̲ACK ̲RECEIVED.
- If the timer had run out, the ASM will be sent
to the Supervisor Printer, otherwise the timer
stopped.…86…1 …02… …02… …02… …02…
Fig. 4.1.3.1-9
4.l.3.l.l0 O̲u̲t̲g̲o̲i̲n̲g̲ ̲C̲o̲m̲m̲e̲n̲t̲ ̲o̲r̲ ̲V̲D̲U̲-̲p̲a̲g̲e̲
See flow fig. 4.l.3.l-l0
Special procedures:
- Transaction acknowledgement
- Retransmission
1) The comment or VDU-page is forwarded to Conversion
directly from the Prepare-position inside CAMPS.
2) After conversion to the SCARS/CCIS E1-format an
acknowledgement is returned to the drafter
(Positive = ACK)
(Negative = Message)
3) The message is queued for transmission to SCARS
and/or CCIS.
4) Outgoing Log and statistics of each transmission
or attempt of such
5) The outgoing transport waits for arrival of an
Transaction acknowledgement,
- if this does not arrive within specified time,
the message is retransmitted with a suspected
message-type indicator.
- if maximum of allowed retransmission has been
reached, a report is sent to the Supervisor
Printer.
6) But an transaction acknowledgement arrives; the
Incoming Transport reports this to the Transport
Control.
7) The Transport Control releases the Outgoing Transport
from its waiting-point and the next message can
be transmitted.…86…1 …02… …02… …02… …02…
Fig. 4.1.3.1-10
4.l.3.l.ll R̲e̲a̲d̲d̲r̲e̲s̲s̲e̲d̲ ̲R̲e̲r̲u̲n̲ ̲a̲n̲d̲ ̲R̲e̲r̲o̲u̲t̲i̲n̲g̲
See flow fig. 4.l.3.l-ll
Special procedures:
- Close outgoing traffic
R̲e̲a̲d̲d̲r̲e̲s̲s̲a̲l̲
1) A message of type PLAINDRESS or PLAINDRESS ̲SERVICE
is entered to Conversion FOR ̲READDRESSAL.
2) The message for readdressal is formatted into a
readdressed format and sent to storage due to automatic
release.
3) The readdressed message is queued for transmission.
4) Outgoing Log, statistics and storage.
R̲e̲r̲u̲n̲
5) Supervisor forwards a message to Conversion for
Rerun.
- An instruction to format a suspected duplicate
pilot is also assigned the message.
6) The message is queued for transmission and would
be transmitted with a suspected duplicate pilot
if not:
C̲l̲o̲s̲e̲ ̲o̲u̲t̲g̲o̲i̲n̲g̲ ̲T̲r̲a̲f̲f̲i̲c̲
7) An unidentified message arrives for analysis.
8) The unidentified message is determined to be an
ASM and the ASM-type to be a Channel Close.
- Incoming Log, statistics and storage
9) The Transport Controller receives the command CHANNEL
̲CLOSE ̲RECEIVED.
10) The status of the outgoing channel is set to closed
and a Report sent to the Supervisor Printer
R̲e̲r̲o̲u̲t̲i̲n̲g̲
11) If the channel closed for traffic was the last
available in that circuit, the Outgoing Transport
is instructed to clear the circuit-queue.
12) This is done by transferring all messages waiting
for transmission to Conversion for Rerouting
(the message for Rerun).
13) Conversion checks the circuit availability once
more (might be available if just a switch-over),
but fails and sends the message for RI-assignment.
(NO ̲CHANNEL ̲AVAILABLE)
14) MSO assigns an alternative RI and reenters the
message.
15) The message is queued for transmission upon another
circuit.
16) Where it will be transmitted with the pilot required
in this case
- outgoing Log, statistics and storage…86…1
…02… …02… …02… …02…
Fig. 4.1.3.1-11
4.l.3.l.12 C̲h̲a̲n̲n̲e̲l̲ ̲C̲h̲e̲c̲k̲
See flow fig. 4.l.3.l-l2
The purpose of the Channel Check messages are to check
the channel-availability when no other traffic is running.
Two types of channel check exists:
- the continuity (NICS ̲TARE,SCARS and CCIS)
- the selfaddressed (TRC/Point-to-point)
The continuity channel check is transmitted by both
systems periodically, and thereby also expected periodically.
The selfaddressed channel check is after transmission
expected to return to the transmitting system again.
O̲u̲t̲g̲o̲i̲n̲g̲ ̲C̲o̲n̲t̲i̲n̲u̲i̲t̲y̲
1) No incoming traffic has been running within a specified
time, so the Transport Controller instructs the
Outgoing Transport to generate and transmit a Continuity
ASM.
2) Log and statistics of the automatic generated Continuity
ASM after transmission
- reset of timer for next Continuity
- any message transmitted causes a reset of above
timer.
I̲n̲c̲o̲m̲i̲n̲g̲ ̲C̲o̲n̲t̲i̲n̲u̲i̲t̲y̲
3) In case no traffic has been received on the incoming
channel within a specified time, Supervisor receives
a report.
4) Any message arriving causes a reset of the incoming
channel check timer.
5) An unidentified message for analysis, turns out
to be an incoming continuity ASM.
6) Incoming Log, statistics and storage; the message
is dropped because it already has fulfilled its
purpose (re.4).
O̲u̲t̲g̲o̲i̲n̲g̲ ̲S̲e̲l̲f̲a̲d̲d̲r̲e̲s̲s̲e̲d̲
7) No traffic has been running within a specified
time, so the Transport Controller instructs the
Outgoing Transport to generate and transmit a selfaddressed
Channel Check.
8) Log and statistics after transmission of the Selfaddressed
Channel Check.
A timer is set-up for return of the ASM.
9) The not yet identified Selforiginated Channel Check
arrives and is queued for analysis.
10) The message-type is determined
- incoming Log, statistics and storage
11) The Transport Control causing all this is notified
of the arrival of an Selfaddressed Channel Check.
- had the timer run out; the ASM will be sent
to the Supervisor Printer.
I̲n̲c̲o̲m̲i̲n̲g̲ ̲S̲e̲l̲f̲a̲d̲d̲r̲e̲s̲s̲e̲d̲
12) A not yet identified selfaddressed Channel Check
arrives and is queued for analysis.
13) Incoming Log, statistics and storage after the
type is determined to be an incoming, not Selforiginated
Channel Check.
14) The Non-Selforiginated Channel Check is sent to
conversion as a normal complete message.
15) Queued for transmission
16) Outgoing Log, statistics and storage after transmission.…86…1
…02… …02… …02… …02…
Fig. 4.1.3.1-12
4.l.3.l.l3 C̲h̲a̲n̲n̲e̲l̲ ̲O̲p̲e̲n̲ ̲S̲e̲q̲u̲e̲n̲c̲e̲s̲
See flow fig. 4.l.3.l-l3
This example illustrates a channel opening procedure
on a Telegraph Circuit from Initialization until complete
running state.
1) Start-up of a Transport Subprocess
(= initialization) via SSC.
2) Start external channel command from SSC(operator)
3) Connect to logical incoming channel; incoming transport
ready to receive messages even if the channel is
closed (will send warning reports to the Supervisor
Printer if any arrives).
4) Correct to logical outgoing channel; the Outgoing
Transport is instructed to send status = state
of the incoming channel.
5) The state of the incoming channel is in this example
closed, so the message generated is an Channel
Close ASM.
Log and statistics after transmission.
6) Supervisor wants to open for incoming traffic and
sends a command to the Transport Control.
7) The Outgoing Transport is instructed to send the
Channel Opening ASM and the status of the incoming
channel is set to open.
8) Log and Statistics of the transmitted Channel Open
ASM.
9) Report to Supervisor Printer
- incoming channel opened for traffic.
10) A Channel Test ASM arrives
11) Incoming Log, statistics and storage
12) The quality of the Test message is examined and
the result (ZBZ1,4 or 5) sent to the Transport
Controller together with the command SEND ̲TEST
̲REPLY.
13) If the test-result was ZBZ1, the incoming channel
would be closed again (plus report to supervisor)
but in this case the result is ZBZ5, and the outgoing
Transport is instructed to transmit a Channel Test
Reply ASM.
14) Outgoing Log and statistics after transmission
of the Test Reply ASM.
15) A Channel Open ASM arrives
16) Incoming Log, Statistics and storage
17) The Transport Control is informed with CHANNEL
̲OPEN ̲RECEIVED.
18) The outgoing channel status is set to open and
Supervisor receives a report.
19) Messages are queued for transmission from conversion.
20) The Outgoing Transport is instructed to transmit
a Channel Test ASM.
21) Log and statistics of the Channel Test ASM after
transmission.
22) Arrival of a Channel Test Reply ASM
23) Incoming Log, statistics and storage
24) The result contained in the Reply is forwarded
to the Transport Control (TEST ̲REPLY ̲RECEIVED)
- If the Transport Control is a ZBZ1, the outgoing
channel is closed again and Supervisor informed.…86…1
…02… …02… …02… …02…
Fig. 4.1.3.1-13
4.l.3.l.l4 C̲h̲a̲n̲n̲e̲l̲ ̲N̲u̲m̲b̲e̲r̲ ̲C̲h̲e̲c̲k̲
See flow fig. 4.l.3.l-l4
S̲p̲e̲c̲i̲a̲l̲ ̲P̲r̲o̲c̲e̲d̲u̲r̲e̲s̲:̲
- Incoming preempted message
The Channel Number Check procedures are activated when
a TSN is reset (daily or wrap ̲around).
1) A message is queued for analysis.
- the message has TSN = 001 in FL1.
- the preemption sequence ZPH has been detected during
reception procedures; this information follows
the message.
2) Because the incoming message is preempted it is
accounted in the invalid message log and statistics
whereafter it is dropped.
3) From the Incoming Transport, who detected the FL1
with TSN = 001, the command SEND ̲TSN ̲CHECK and
the value of the previous TSN is sent to the Transport
Control.
4) The Transport Control instructs the Outgoing Transport
to generate and transmit a Channel Number Check
ASM.
5) Outgoing Log and statistics of the transmitted
Channel Number Check ASM.
6) A message is queued for transmission.
7) Log, statistics and storage of the transmitted
message,
- the message transmitted contained TSN = 001
of FL1 (generated by the Outgoing Transport)
so a timer is set-up for expected arrival of
an Incoming Channel Number Check ASM.
8) If the timer runs out, a report is sent to the
Supervisor Printer.
9) An yet unidentified message arrives for analysis.
10) The message is identified as a Channel Number Check
ASM.
- Log, statistics and storage.
11) The channel Number Check ASM is sent for printout
on the Supervisor Printer.
12) And the Transport Controller receives the result
of the Channel Check ASM, which is the last used
outgoing TSN from Camps before the reset.
(Command = TSN ̲CHECK ̲RECEIVED).
13) The Transport Control stops the timer, compares
the TSN used before reset with the TSN delivered
from analysis; if inconsistency a Report is sent
to the Supervisor Printer.…86…1 …02… …02… …02… …02…
Fig. 4.2.1.3.1-14
4.l.3.2 M̲e̲s̲s̲a̲g̲e̲ ̲C̲o̲n̲t̲r̲o̲l̲
Between the Subpackages of THP exists an somewhere
intensive cooperation in order to control the message
flow.
These functional interfaces are mainly between:
- The Transport Subpackages (ref.4.2.3.3)
- Incoming Transport and Analysis (ref. 4.l.3.2.l)
- Analysis and Conversion (ref. 4.l.3.2.2)
- Conversion and Outgoing Transport (ref. 4.l.3.2.3)
4.l.3.2.l I̲n̲c̲o̲m̲i̲n̲g̲ ̲T̲r̲a̲n̲s̲p̲o̲r̲t̲ ̲a̲n̲d̲ ̲A̲n̲a̲l̲y̲s̲i̲s̲
The functions shared between the Incoming Transport
Subpackages and the Analysis Subpackage are:
- reception error handling
- message type determination
a) R̲e̲c̲e̲p̲t̲i̲o̲n̲ ̲E̲r̲r̲o̲r̲ ̲H̲a̲n̲d̲l̲i̲n̲g̲
During Reception procedures the Incoming Transport
detects the following errors of an incoming message:
- Too long Line (not text-part of Data-message)
- No EOTF
- Missing BT (first BT found but not the second)
- Oversized MSG (more than 12.000 char.)
- Halted MSG
- 140 Identical Characters
- Preempted message
- Block Error (SCARS/CCIS)
If an reception error has been detected, the associated
reception-error-code is forwarded with the message
to analysis. The Analysis Subpackages will then account
for the invalid message in the incoming Log and statistics,
and possible forward the message for garble correction
at an Incoming MSO position.
Another type of reception error handling is the TI-inspection;
the Incoming Transport Subpackage is responsible for
analysis of FL1 because it maintains the next expected
TSN and therefore also reports discontinuities concerning
the actual received TSN and the expected TSN; whatever
is wrong with the TI (missing designator, too low TSN
etc.) this is indicated in the error-list of the ACP-Parameter
̲field; the actual message sent for analysis always
contains a valid TI of FL1.
The principle of TI-inspection is as explained for
other reception-errors except that the Incoming MSO
will receive the message for Inspection.
b) M̲e̲s̲s̲a̲g̲e̲ ̲T̲y̲p̲e̲ ̲D̲e̲t̲e̲r̲m̲i̲n̲a̲t̲i̲o̲n̲
When a message shall be analyzed by the Analysis Subpackage
the message type is determined before the actual analysis
starts; this message type determination is primary
based upon detection of certain format-lines during
Reception procedures by the Incoming Transport Subpackage;
these are:
There are:
- FL 3 (DE) "Garbled?
- FL6 (FM) Plaindress?
- FL10 (GR) Encrypted?
The presence of these format lines are indicated via
an offset in the ACP ̲Parameter-Field.
Also the contents of FL14 and/or FL15 is collected
in the ACP-parameter-field. This is the Group Count
value and the validation SSN.
The validation SSN is used during analysis for consistency
check FL3/FL15.
The Incoming Transport Subpackage will separate the
header and text into two fields based on detection
of FL11 and FL13 (BT) and remove page-identifications
before storage; the advantage is, that an analysis
of the text is unnecessary, because the text is ready
for display or print.
4.1.3.2.2 A̲n̲a̲l̲y̲s̲i̲s̲ ̲a̲n̲d̲ ̲C̲o̲n̲v̲e̲r̲s̲i̲o̲n̲
Between the Analysis Subpackage and the Conversion
Subpackage are only minor shared functions related
to,
- automatic release
- routing information.
It is the responsibility of the Conversion Subpackage
to release complete messages entered via a normal PTR
automatically before transmission; the conversion subpackage
does not know the originating source, but the Analysis
Subpackage does and therefore indicates an automatic
release via the QEL-information.
Because RI's, PLA's and AIG's of an incoming message
are validated by the Analysis Subpackage, the information
necessary to route the message, in case it should be
relevant, is automatically extracted. Therefore the
Analysis Subpackage writes this validation-result into
the PLA ̲RI ̲FIELD for use during Routing procedures.
4.1.3.2.3 C̲o̲n̲v̲e̲r̲s̲i̲o̲n̲ ̲a̲n̲d̲ ̲O̲u̲t̲g̲o̲i̲n̲g̲ ̲T̲r̲a̲n̲s̲p̲o̲r̲t̲
The functions shared between the Conversion Subpackage
and the Outgoing Transport Subpackage are,
- formatting of pilot
- formal parameter insertion
- data collection
Should a message during transmission be preempted in
the favour of a message waiting for transmission with
flash precedence (as an example), the message preempted
shall when transmitted again be preceeded with a suspected
duplicate pilot; therefore it is convenient to let
the outgoing transport format all pilots.
To achieve this easily, the Conversion Subpackage will
point out the format-lines of the header necessary
to generate the pilot via offsets in the ACP-parameter.field;
these are:
- offset FL3
- offset FL4
- offset FL5
If a message shall be preceeded with a pilot due to
reasons not known to the Outgoing Transport (RERUN),
this is indicated via the QEL-information.
The message queued for transmission is separated in
upto 3 message-fields.
- The header field
- The text-preamble field
- The text field
The Header is without FL1, because it is the responsibility
of the Outgoing Transport to generate this format line
due to the individual TI of each outgoing channel.
In order to complete the formatting, the outgoing Transport
will insert the following formal parameters in the
message,
- BT (FL11 and FL13)
- Group Count (FL14)
- SSN (FL15)
- EOTF
- Paging
The BT's are inserted automatically if a text-field
is transmitted.
Group Count and SSN is appended if text had been transmitted
and the parameters are available in the ACP-parameter
field.
EOTF is standard end-sequence of the transmission.
If the message is a subject for paging, this is indicated
via the QEL-information and the information necessary
to fulfill this placed in the ACP-parameter field.
(station-ID and classification.)
When a message has been transmitted it shall finally
be logged as outgoing and statistics delivered ; the
information necessary for this data-collection is supplied
by the Conversion Subpackage via the ACP-parameter
field.
4.l.4 C̲o̲m̲m̲o̲n̲ ̲P̲a̲c̲k̲a̲g̲e̲ ̲D̲a̲t̲a̲
The following data-elements associated to classification
and precedence are used during analysis of an incoming
message and during conversion of an outgoing message.
Subpackages: AAS, ACS and OTS
C̲o̲n̲s̲t̲a̲n̲t̲s̲
MAX ̲RI = 200
MAX ̲PLA = 250
MAX ̲CLASS ̲WORD ̲SIZE = 32
MAX ̲SPEC ̲WORD ̲SIZE = 16
MAX ̲CLASS ̲WORD = 6
MAX ̲SPEC ̲WORD = 5
CLEAR = MAX ̲CLASSIFICATION + 1;
MAX ̲SYS ̲ID = 3
T̲y̲p̲e̲s̲:̲
CLASS ̲WORD ̲TYPE: ARRAY(1..MAX ̲CLASS ̲WORD ̲SIZE)
OF CHAR
SPEC ̲WORD ̲TYPE: ARRAY(1..MAX ̲SPEC ̲WORD ̲SIZE)
OF CHAR
SPECIAL HANDLING = (NO ̲SPEC
ATOMAL
DATA ̲MSG
CRYPTO ̲SECURITY
EXCLUSIVE
NATIONAL)
TRAFFIC ̲SUBQUEUE ̲TYPE = (MAIN
COMMAND
RESPONSE
TRAFFIC
LOG ̲COMP)
TCS ̲SUBQUEUE ̲TYPE (TCS ̲MAIN
PRIMARY
SECONDARY)
COMPLETION TYPE = (O ̲K, NOT ̲OK,OK ̲EOLN,
NOT ̲OK ̲EOLN)
DYN ̲STA ̲TYPE = (DYNAMIC, STATIC)
BIT ̲TYPE = BIT-,.....,BIT15)
V̲a̲r̲i̲a̲b̲l̲e̲s̲:̲
CLASS ̲WORD ARRAY(1..MAX ̲CLASS ̲WORD)
OF CLASS ̲WORD ̲TYPE
SPEC ̲WORD: ARRAY(1..MAX ̲SPEC ̲WORD)
OF SPEC ̲WORD ̲TYPE
CLASS ̲WORD ̲LENGTH: ARRAY(1..MAX ̲CLASS ̲WORD)
OF INTEGER
SPEC ̲WORD ̲LENGTH: ARRAY(1..MAX ̲SPEC ̲WORD)
OF INTEGER
CLASS ̲PROSIGN: ARRAY(1..MAX ̲CLASSIFICATION)
OF CHAR
SPEC ̲PROSIGN: ARRAY(1..MAX ̲SPEC ̲HANDL)
OF CHAR
PREC ̲PROSIGN: ARRAY(1..MAX ̲PRECEDENCE)
OF CHAR
SYS ̲ID ̲PROSIGN: ARRAY(1..MAX ̲SYS ̲ID)
OF CHAR
V̲a̲r̲i̲a̲b̲l̲e̲ ̲I̲n̲i̲t̲i̲a̲l̲i̲z̲a̲t̲i̲o̲n̲
CLASS ̲WORD(1) = NATO UNCLAS
CLASS ̲WORD(2) = N A T O R E S T R I C T E D
CLASS ̲WORD(3) = N A T O C O N F I D E N T I A
L
CLASS ̲WORD(4) = N A T O S E C R E T
CLASS ̲WORD(5) = C O S M I C T O P S E C R E T
CLASS ̲WORD(6) = CLEAR
CLASS ̲LENGTH (1) = 11
- (2) = 27
- (3) = 31
- (4) = 19
- (5) = 29
- (6) 5
SPEC ̲WORD(1) = ATOMAL
SPEC ̲WORD(2) = DATA MESSAGE
SPEC ̲WORD(3) = CRYPTO SECURITY
SPEC ̲WORD(4) = EXCLUSIVE
SPEC ̲WORD(5) EYES ONLY
SPEC ̲WORD ̲LENGTH (1) = 6
- (2) = 12
- (3) = 15
- (4) = 9
- (5) = 9
CLASS ̲PROSIGN = 'URCST'
SPEC ̲PROSIGN = 'LDYPP'
PREC ̲PROSIGN = 'ZZOPPR'
SYS ̲ID ̲PROSIGN = 'CSA'
L̲a̲y̲o̲u̲t̲
Common to all subpackages of THP is the Traffic Mask
contained in the QEL-information.
The specific use of this traffic-mask is explained
in sections 4.2.x.5 for each subpackage.
See general layout fig. 4.l.4.-1
Fig. 4.1.4-1
C̲o̲m̲m̲o̲n̲ ̲P̲a̲c̲k̲a̲g̲e̲ ̲P̲r̲o̲c̲e̲d̲u̲r̲e̲s̲
The common THP-procedures are mainly auxillary procedures
which may or may not be included in the common Camps
Library.
The auxillary procedures needed are:
- Convert binary to ASCII
- Convert ASCII to binary
- Compare String
- Move String
These procedures are referenced in the specific subpackage
design and will be transferred to this section or the
common Camps Library during the coding-phase.
No common procedures have been developed during the
coding phase.
4.l.6 G̲l̲o̲b̲a̲l̲ ̲D̲a̲t̲a̲ ̲E̲l̲e̲m̲e̲n̲t̲s̲
THP communicates with other packages by use of the
Internal Message Format (ref. CPS/DBD/001 section 10.1).
The internal communication between THP subpackages
is in the External Message Format (ref. CPS/DBD/001
section 10.2).
For data elements used in communication with CSF/IOC
and TMP ref. CPS/DBD/001. section 4.
4.l.7 I̲n̲t̲e̲r̲f̲a̲c̲e̲s̲
4.l.7.l E̲x̲t̲e̲r̲n̲a̲l̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲s̲
N̲I̲C̲S̲ ̲T̲A̲R̲E̲
Ref. CPS/230/ICD/0004
S̲C̲A̲R̲S̲
Ref. CPS/230/ICD/0005
C̲C̲I̲S̲
Ref. CPS/230/ICD/0006
P̲T̲R̲
P̲T̲P̲
L̲O̲W̲ ̲S̲P̲E̲E̲D̲ ̲T̲E̲L̲E̲P̲R̲I̲N̲T̲E̲R̲S̲
4.l.7.2 P̲a̲c̲k̲a̲g̲e̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲s̲
The interfaces between THP and
- Message Distribution Package (MDP)
- Storage and Retrieval Package (SAR)
- Log Package (LOG)
- System Status and Control (SSC)
are described in CPS/ICD/009 in the following sections:
THP to MDP ref. 5.l.l
TEP to THP ref. 5.2.l
THP to TEP ref. 5.2.2.
THP to SAR ref. 5.3.l
LOG to THP ref. 5.4.l
THP to LOG ref. 5.4.2
THP to/from SSC ref. 4.2.l.4
4.l.7.3 S̲u̲b̲p̲a̲c̲k̲a̲g̲e̲s̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲s̲
The Interfaces between the THP-subpackages:
- Analysis Subpackage (AAS)
- Conversion Subpackage (ACS)
- Transport Subpackage (TRS)
are described in CPS/ICD/009 in the following sections:
TRS to AAS ref. 5.6.l
AAS to TRS ref. 5.6.2
AAS to ACS ref. 5.6.3
ACS to TRS ref. 5.6.4
TRS to ACS ref. 5.6.6
