top - download
⟦6ec634ecb⟧ Wang Wps File
Length: 61688 (0xf0f8)
Types: Wang Wps File
Notes: FIX/1154/PSP/0107
Names: »3163A «
Derivation
└─⟦ea7460488⟧ Bits:30006136 8" Wang WCS floppy, CR 0270A
└─ ⟦this⟧ »3163A «
WangText
…0b……00……00……00……00…C…0a……00……00…C…0b…C…0e…C…02…C…06…B…0c…B…00…B…06…A…0b…A…0e…A…02…A…05…@…08…@…0b…@…0d…@…0e…@…0f…@…00…@…01…@…05…@…06…?…09…?…0d…?…0e…?…02…?…06…?…07…>…08…>…0a…>…00…>…05…>…07…=…08…=…09…=…0d…=…00…=…01…= =…05…<…09…<…86…1
…02… …02… …02…
…02…FIX/1154/PSP/0107
…02… JL/821215…02……02…
NODAL SWITCH SUBSYSTEM (NSS)
…02……02…FK 7809
…06…W …02… …02… …02… …02… …02…
3.3.6.3.4.4 ̲D̲a̲t̲a̲ ̲U̲s̲e̲r̲
status report ::=
status code ; byte # 0
jack # ; - # 1
secondary route ; - # 2
irrelevant ; - # 3
- ; - # 4
- ; - # 5
- ; - # 6
- ; - # 7
- ; - # 8
- ; - # 9
- ; - #10
- ; - #11
- ; - #12
- ; - #13
- ; - #14
secondary route selected ; - #15
status code ::= #05
jack # ::= 1/2/3/4
secondary route ::= boolean
secondary route selected ::= boolean
3.3.6.3.4.5 R̲e̲d̲ ̲C̲r̲y̲p̲t̲o̲
garbling report ::=
garbling report ; byte # 0
garbling ; - # 1
irrelevant ; - # 2
- ; - # 3
- ; - # 4
- ; - # 5
- ; - # 6
- ; - # 7
- ; - # 8
- ; - # 9
- ; - #10
- ; - #11
- ; - #12
- ; - #13
- ; - #14
- ; - #15
transmission report ::=
transmission report ; byte # 0
from-node ; - # 1
to-node ; - # 2
trunk serial # ; - # 3
no. of frames trans, LSB ; - # 4
- - - MSB ; - # 5
no. of frames retrans,LSB ; - # 6
- - - MSB ; - # 7
soft trunk failure,
frame discarded, not used ; - # 8
irrelevant ; - # 9
- ; - #10
- ; - #11
- ; - #12
- ; - #13
- ; - #14
- ; - #15
garbling report ::= #05
tramsmission report ::= #06
from-node ::= letter
to-node ::= letter
trunk serial # ::= digit
no. of frames (re-)
transmitted ::= integer
soft trunk failure ::= boolean
garbling ::= boolean
3.3.6.3.4.6 B̲l̲a̲c̲k̲ ̲C̲r̲y̲p̲t̲o̲
status report ::= empty
3.3.6.4 N̲e̲i̲g̲h̲b̲o̲u̲r̲ ̲N̲o̲d̲e̲ ̲S̲u̲p̲e̲r̲v̲i̲s̲i̲o̲n̲
Every 3 minutes each node transmits a socalled MICK
control message to each of its neighbour nodes
connected by an open trunk.
Like all other messages the MICK is acknowledged by an ACK from the neighbour.
Having received a MICK control message from a neighbour the node returns a socalled MACK
control message.
Also the MACK is acknowledged by an ACK.
The level of precedence is super flash for the MICK as well as for the MACK. The length is
only 18 bytes.
If a message (a MICK,MACK as any other control- or narrative message) has not been acknowledged
by an ACK after having being retransmitted, the neighbour is reported failed.
The reason for introducing the MICK control message is that a long message my be attempted
to be transmitted to a failed node. If more than 3 packets long (the window of the Packet
Handler) the message timer will not be started, and the failed neighbour will not be detected.
However, a short message like a MICK of its own highest level of precendence will get its
timer started.
But the MICK shares the superflash level with other messages like ACK and NACK; so it could
happen that 3 ACK…08…s or NACK…08…s had beem attempted to be transmitted to a failed neighbour; because
ACK/NACK…08…s don…08…t start a timer, the failed neighbour would not de detected. That is the reason
why the MACK is introduced.
The Neighbour Node Supervision could have been performed on the Packet Level.
3.3.6.5 S̲t̲a̲r̲t̲,̲ ̲R̲e̲s̲t̲a̲r̲t̲,̲ ̲C̲h̲e̲c̲k̲p̲o̲i̲n̲t̲s̲
During s̲t̲a̲r̲t̲:
- a KERNEL-message is sent to the TIMER process for starting the 1 hour timer.
- a KERNEL-message is sent to the TIMER process for starting the 30 s timer.
- the LTUX' are configured.
During r̲e̲s̲t̲a̲r̲t̲:
- a KERNEL message is sent to the TIMER process for starting the 1 hour timer.
- a KERNEL message is sent to the TIMER process for starting the 30 s timer.
- the LTUX' are configured.
- the Packet Handler is asked to restart each former open trunk.
- the Transport Station is asked to reroute each message in the Outbound Message Buffer.
A positive c̲h̲e̲c̲k̲p̲o̲i̲n̲t̲ is made each time a message generated by the module is put into the
TRP-Q. The Nodal Data File is updated each time, the Nodal Data is changed.
3.3.6.6 F̲u̲n̲c̲t̲i̲o̲n̲s̲
When the 30 s timer expires the LTUX…08… are polled.
Every 3 minutes a MICK control message is sent to each neighbour connected by an open trunk,
if a MACK was received on the previous MICK.
Each hour the Statistics and the Hourly Report are filled and forwarded to both SCC…08…s.
On request the Local Network Status Report (LNSR) is sent to both SCC…08…s.
An Alarm: "Trunk-Queue Threshold Exceeded, on/off", "Crypto Garbling" or "Orbiting Narrative
Message" is reported by forwarding the LNSR.
When a LTUX responds the polling, the status report is investigated. In case of hard or soft
trunk failure, NPDN call-up or close-down or change to secondary data-user route the LNSR
is filled and forwarded; also the Nodal Data File is updated.
A "Neighbour Node Failure" is reported by forwarding a LNSR and updating the NDF. The Transport
Station is asked to reroute messages for that neighbour, and MTCB…08…s and IMF-areas for messages
partly received from the neighbour are released. A control message is sent to the MEDE-supervisor.
When a data-user route should be changed to the primary, a command is output to the LTUX
in question, the NDF is updated, and the LNSR is forwarded.
In case of normal, alternate-1 or alternate-2 date-user configuration the LTUX' are reconfigured
regarding a possible NPDN call.
A NPDN call-up or close-down is performed by outputting the proper command to the LTUX-NPDN.
After a successful call-up the NDF is updated, the LTUX' are reconfigured, the LNSR is forwarded
and a control message is sent to the MEDE…08…s supervisor.
When a trunk is asked to be opened, the command is output to the LTUX-TRUNK, -NPDN or -TRANS
and the Packet Handler is asked to restart the trunk. Being restarted, the MEDE…08…s supervisor
is informed, the message counters are reset, the NDF is updated, and the LNSR is forwarded.
When a trunk is asked to be closed, the command is output to the LTUX-TRUNK, -NPDN, or -TRANS,
the NDF is updated and the Packet Handler is asked to restop the trunk. Being stopped the
MEDE…08…s supervisor is informed, the Transport Station is asked to reroute messages for the
trunk, and MTCB…08…s and IMF-areas for messages partly received from the trunk are released.
3.3.6.7 O̲p̲e̲r̲a̲t̲i̲o̲n̲s̲
The format of the operations received are:
3.3.6.7.1 O̲p̲e̲r̲a̲t̲i̲o̲n̲s̲ ̲f̲o̲r̲ ̲t̲h̲e̲ ̲S̲e̲m̲a̲p̲h̲o̲r̲e̲:̲ ̲M̲O̲N̲
T̲i̲m̲e̲r̲
State: Time Elapsed
Semaphores: MON
Op( 5, 4): Event Module
- ( 7, 6): 0 ,TO-TIM
- ( 9, 8): Timer Ident
- (11,10): 0 ,0
R̲e̲p̲o̲r̲t̲s̲
State: Request for Local Network Status Report
Semaphore: MON
Op( 5, 4): Control Module
- ( 7, 6): 0 ,TO-REQ
- ( 9, 8): 0 ,0
- (11,10): 0 ,0
State: Trunk Failure
Semaphore: MON
Op( 5, 4): Transport Station, Packet Handler or Monitoring Module
- ( 7, 6): Neighbour, TO-RTF
- ( 9, 8): Entry #, Trunk Ser #
- (11,10): on/off, soft/hard
State: Node Failure
Semaphore: MON
Op( 5, 4): Transport Station or Monitoring Module
- ( 7, 6): Neighbour, TO-RNF
- ( 9, 8): 0 ,Trunk Ser #
- (11,10): 0 ,0
State: Trunk Queue Threshold Exceeded, on
Semaphore: MON
Op( 5, 4): Transport Station
- ( 7, 6): Neighbour,TO-RTT
- ( 9, 8): 0 ,Trunk Ser #
- (11,10): on ,0
State: Trunk Queue Threshold Exceeded,off
Semaphore: MON
Op( 5, 4): Packet Handler
- ( 7, 6): Neighbour, TO-RTT
- ( 9, 8): 0 ,Trunk Ser #
- (11,10): off ,0
State: Crypto Garbling
Semaphore: MON
Op( 5, 4): Monitoring Module
- ( 7, 6): 0 ,TO-RCF
- ( 9, 8): 0 ,0
- (11,10): 0 ,0
State: Orbiting Message
Semaphore: MON
Op( 5, 4): Transport Station
- ( 7, 6): 0 ,TO-ROM
- ( 9, 8): 0 ,0
- (11,10): 0 ,0
State: Command Error
Semaphore: MON
Op( 5, 4): Control Module
- ( 7, 6): Neighbour,TO-RCE
- ( 9, 8): 0 ,Trunk Ser #
- (11,10): Call-up/Close-down,0
State: LTUX Report
Semaphore: MON
Op( 5, 4): Event Module
- ( 7, 6): 0 , TO-RER
- ( 9, 8): CC
- (11,10): LTUX-type, LTUX-entry
C̲o̲n̲f̲i̲r̲m̲a̲t̲i̲o̲n̲
State: Trunk Opened
Semaphore: MON
Op( 5, 4): Packet Handler
- ( 7, 6): Neighbour,TO-RTO
- ( 9, 8): 0 ,Trunk Ser #
- (11,10): 0 ,NPDN
State: Trunk Closed
Semaphore: MON
Op( 5, 4): Packet Handler
- ( 7, 6): Neighbour,TO-RTC
- ( 9, 8): 0 ,Trunk Ser #
- (11,10): 0 ,NPDN
C̲o̲n̲t̲r̲o̲l̲
State: Primary Route
Semaphore: MON
Op( 5, 4): Control Module
- ( 7, 6): Data user #,TO-CPR
- ( 9, 8): Device #,Jack #
- (11,10): 0 ,0
State: LTUX Configuration
Semaphore: MON
Op( 5, 4): Control Module
- ( 7, 6): State ,TO-CCF
- ( 9, 8): 0 ,0
- (11,10): 0 ,0
State: MICK/MACK
Semaphore: MON
Op( 5, 4): Control Module
- ( 7, 6): Neighbour,TO-CMM
- ( 9, 8): 0 ,Trunk Ser #
- (11,10): 0 ,MICK/MACK
State: Open Trunk
Semaphore: MON
Op( 5, 4): Control Module
- ( 7, 6): Neighbour,TO-COT
- ( 9, 8): 0 ,Trunk Ser #
- (11,10): Entry #,NPDN
State: Close Trunk
Semaphore: MON
Op( 5, 4): Control Module or Monitoring Module
- ( 7, 6): Neighbour,TO-CCT
- ( 9, 8): 0 ,Trunk Ser #
- (11,10): Entry #,NPDN
State: NPDN Call-up
Semaphore: MON
Op( 5, 4): Control Module
- ( 7, 6): Neighbour,TO-CCU
- ( 9, 8): 0 ,Trunk Ser #
- (11,10): Call no.
State: NPDN Close-down
Semaphore: MON
Op( 5, 4): Control Module
- ( 7, 6): Neighbour,TO-CCD
- ( 9, 8): 0 ,Trunk Ser #
- (11,10): Call No.
3.3.6.7.2 O̲p̲e̲r̲a̲t̲i̲o̲n̲s̲ ̲f̲o̲r̲ ̲t̲h̲e̲ ̲S̲e̲m̲a̲p̲h̲o̲r̲e̲:̲ ̲M̲O̲N̲D̲
State: LTUX Command Response
Semaphore: MOND
Op( 5, 4): Event Module
- ( 7, 6): 0 ,TO-CR
- ( 9, 8): CC
- (11,10): LTUX-Type,LTUX-No
State: Disc Output
Semaphore: MOND
Op( 5, 4): Event Module
- ( 7, 6): 0 , TO-OUT
- ( 9, 8): CC
- (11,10): Ref (BLE)
FIG. 3.3.6.8-1
THE MONITORING MODULE COROUTINE:
MAIN LOOP
FIG:
FIG. 3.3.6.8-2:
THE MONITORING MODULE
COROUTINE: INITIALIZATION
FIG. 3.3.6.8-3:
THE MONITORING MODULE ̲COROUTINE
FUNCTIONAL DIAGRAM
0. RE-START TRUNK ON LEVEL 3: SIGNAL TO THE PACKET HANDLER.
1. RE-STOP TRUNK ON LEVEL 3.
2. EMPTY TRUNK-QUEUE.
3. RESET PACKET COUNTERS (S THROUGH R) AND
RESET "SERI" & "SERO"(S THROUGH R).
4. RELESE MTCB's AND IMF…08…s FOR INBOUND-MSGS ON THE
TRUNK.
5. REROUTE OUTBOUND-MSGS ON THE TRUNK.
6. UPDATE NODAL-DATA.NPDN-TABLE.
7. UPDATE NODAL-DATA.TRUNK-TABLE.
8. WRITE NDF.
9. OUTPUT COMMAND TO LTUX.
10. RECONFIGURE LTUX.
11. FILL CTR-MSG FOR THE MEDE.
12. FORWARD CTR-MSG TO THE MEDE.
13. UPDATE "LOCAL-NETWORK-STATUS-REPORT".
14. FORWARD "LOCAL-NETWORK-STATUS-REPORT" TO THE SCC's.
15. UPDATE ROUTING-TABLE.
FIG. 3.3.6.8-4
THE MONITORING MODULE COROUTINE
TRUNK SUPERVISION
LEGEND
FIG. 3.3.6.8-5:
MONITORING MODULE
LTUX REPORT FROM
TRUNK…08…s AND NPDN
3.3.6.9 S̲i̲z̲e̲
The size of the code is 2537 instructions.
The necessary data area occupies 581 words.
3.3.6.10 T̲i̲m̲i̲n̲g̲
About 120 instructions on average are executed for processing an event corresponding to a
CPU-time of 0.3 ms.
On average the disc is accessed once per event corresponding to a CPU-time of 3.2 ms.
The MTCB-monitor is called 3 times of 0.2 ms, or 0.6 ms per message, and QACCESS is called
once, which requires a CPU-time of 0.2 ms.
3.3.7 T̲h̲e̲ ̲C̲o̲n̲t̲r̲o̲l̲ ̲M̲o̲d̲u̲l̲e̲
3.3.7.1 I̲n̲t̲r̲o̲d̲u̲c̲t̲i̲o̲n̲
The Control Module receives control messages sent to the node from the supervisor of the
active SCC or from the supervisor of the local MEDE.
Control messages for the Control Module are put into the Control Queue by the Transport Station,
cfr. fig. 3.3.7.1-1.
ACK/NACK messages sent to the node from its neighbour nodes are n̲o̲t̲ sent to the Control Module,
but entirely handled by the Transport Station.
Control of the LTUX…08… is passed over to the Monitoring Module.
3.3.7.2 M̲e̲s̲s̲a̲g̲e̲s̲ ̲R̲e̲c̲e̲i̲v̲e̲d̲
The Control Module receives messages from the SCC, from the local MEDE, and from the neighbour
NSS…08…. A detailed description is given in ref: (4).
The messages from the S̲C̲C̲ are:
- Set Retransmission Threshold
- Set Trunk Queue Threshold
- Routing Table
- Open/Close Trunk
- Change to Primary Data-User Route
- Request for Local Network Status Report
The messages from the local M̲E̲D̲E̲ are:
- Local Routing Table
- NPDN Call-up/Close-down
- Open/Close Trunk
- Data-User Reconfiguration
The messages from the neighbour N̲S̲S̲…08… are:
- MICK…08…s and MACK…08…s
FIG. 3.3.7.1-1:
THE CONTROL MODULE
3.3.7.3 S̲t̲a̲r̲t̲,̲ ̲R̲e̲s̲t̲a̲r̲t̲,̲ ̲C̲h̲e̲c̲k̲p̲o̲i̲n̲t̲s̲
During s̲t̲a̲r̲t̲:
- a "Node Start" operation is signalled to the Monitoring Module
During r̲e̲s̲t̲a̲r̲t̲:
- A "Node Restart" operation is signalled to the Monitoring Module
A negative c̲h̲e̲c̲k̲p̲o̲i̲n̲t̲ is made when a message is removed from the CTR-Q. The Nodal Data File
is updated, when the Routing Table is updated.
3.3.7.4 F̲u̲n̲c̲t̲i̲o̲n̲s̲
A possible element in the CTR-Q is signalled from the Event Module. If the queue is non-empty,
the MTCB of the first element is read, the message is input from the disc, and the queue-element,
the MTCB and the file are released.
The threshold is set for a "Set Retransmission Threshold"- or a "Set TRK-Q Threshold" control
message.
A new Routing Table is stored, and the NDF is updated.
In the cases mentioned below, where LTUX-Supervision is required, the control information
is passed to the Monitoring Module by signalling an operation, after a syntactical check
has been performed:
o NPDN Call-up/Close-down
o Open/Close Trunk
o Change to Primary Data-User Route
o Data-User Reconfiguration.
Also a request for a Local Network Status Report and a MICK or MACK is signalled to the Monitoring
Module.
3.3.7.5. O̲p̲e̲r̲a̲t̲i̲o̲n̲s̲
The format of the operations received are:
State: Message in CTR-Q/TRP-Q
Semaphore: CTRL
Op( 5, 4) : Event Module
- ( 7, 6) : 0 ,TO-INT
- ( 9, 8) : 0 ,0
- (11,10) : 0 ,0
State: Disc I/O
Semaphore: CTRD
Op( 5, 4): Event Module
- ( 7, 6): 0 ,TO-INT
- ( 9, 8): CC
- (11,10): Ref (BLE)
FIG.3.3.7.6-1:
THE CONTROL MODULE
FIG. 3.3.7.6-2:
THE CONTROL MODULE
INITIALIZATION
3.3.7.7 S̲i̲z̲e̲
The size of the code is 713 instructions.
The necessary data area occupies 39 words.
3.3.7.8 T̲i̲m̲i̲n̲g̲
About 120 instructions are executed in average for processing a control message corresponding
to a CPU-time of 0.3 ms.
The disc is accessed once per control message corresponding to a CPU-time of 3.2 ms.
The MTCB-monitor is called twice of 0.2 ms.
QACCESS is called twice of 0.2 ms.
3.3.8 T̲h̲e̲ ̲E̲v̲e̲n̲t̲ ̲M̲o̲d̲u̲l̲e̲
3.3.8.1 I̲n̲t̲r̲o̲d̲u̲c̲t̲i̲o̲n̲
The Event Module receives external events, i.e. system answers from the Disc Driver and the
TDX Driver, answers from the Timer- and Checkpoint Process, and signals from QACCESS. Having
received an event, it is analysed and signalled to an appropriate coroutine within the Transport
Station, Packet Handler, Control Module or Monitoring Module. Initiating disc- or trunk
I/O the transfer ident is reported to the Event Module; this is done by storing the ident
in the I/O- Transfer Table.
An external event is waited for only when the NSS has nothing else to do, i.e. there are
no coroutines in the Ready Queue. Therefore the call of "WAIT-OPERATIONS" is the very main-waiting
point of the NSS.
3.3.8.2 E̲v̲e̲n̲t̲ ̲F̲o̲r̲m̲a̲t̲
A s̲y̲s̲t̲e̲m̲ ̲a̲n̲s̲w̲e̲r̲ is received when disc-I/O or LTUX-I/O is completed. The transfer-identification
and the completion code are return parameters from wait-operations.
An a̲n̲s̲w̲e̲r̲ is received from the Checkpoint Process or from the Timer Process. During test
it may be received from the TDX-Simulator. The message-answer identification is a return
parameter from wait-operations. The answer from the Checkpoint Process contains a completion
code; the answer from the Timer Process contains the timer identifiction.
A s̲i̲g̲n̲a̲l̲ means that QACCESS has stored a message in the CTR-Q or in the remote- or local-queue
of the TRP-Q.
3.3.8.3 S̲e̲m̲a̲p̲h̲o̲r̲e̲s̲ ̲a̲n̲d̲ ̲O̲p̲e̲r̲a̲t̲i̲o̲n̲s̲
The Event Module doesn't receive any operations itself. However, triggered by external events
it generates operations which are signalled to other coroutines of the NSS.
After a system answer the I/O-Transfer Table (see ch. 3.4.5.1) is scanned for the transfer-identification;
the semaphore and the type of operation are found from the entry of the table. The type,
the LTUX-type, the entry-no, and the completion code are put into the operation before being
signalled to the semaphore.
After an answer from the Checkpoint Process the Message/Answer Table (see ch. 3.4.5.2) is
scanned for the message/answer identification; the semapore and the type of operation are
found from the entry of the table. The type and the completion code are put into the operation
before being signalled to the semaphore.
After an answer from the Timer Process a type and the timer identification is put into the
operation. A message timer is signalled to the Transport Station, other timers are signalled
to the Monitoring Module (30 s, 1 hour).
After a signal an operation is signalled to the Control Module as well as the Transport Station
3.3.8.4 S̲t̲a̲r̲t̲,̲ ̲R̲e̲s̲t̲a̲r̲t̲,̲ ̲C̲h̲e̲c̲k̲p̲o̲i̲n̲t̲s̲
No special handling is performed during s̲t̲a̲r̲t̲ or r̲e̲s̲t̲a̲r̲t̲.
No c̲h̲e̲c̲k̲p̲o̲i̲n̲t̲i̲n̲g̲ is performed.
3.3.8.5 F̲u̲n̲c̲t̲i̲o̲n̲s̲
External events are received by the Coroutine Monitor call:
WAIT-OPS
which means that external events are not served until all internal event have been processed.
FIG. 3.3.8.6-1:
THE EVENT MODULE
MAIN LOOP
FIG. 3.3.8.6-2
THE EVENT MODULE
INITILIZATION
3.3.8.7 S̲i̲z̲e̲
The size of the code is approximately 199 intructions.
The necessary data area occupies approximately 29 words.
3.3.8.8 T̲i̲m̲i̲n̲g̲
About 40 instructions are executed in average for processing an external event corresponding
to a cpu-time of app. 0.1 ms.
3.3.9 T̲h̲e̲ ̲S̲t̲a̲r̲t̲i̲n̲g̲ ̲M̲o̲d̲u̲l̲e̲
3.3.9.1 S̲t̲a̲r̲t̲/̲R̲e̲s̲t̲a̲r̲t̲
The Starting Module contains the main entry point of the NSS. Therefore this module executes
the very first instructions during a start as well as during a restart.
There are two differences only in this module between a start and a restart situation:
First when the Nodal Data File is input during a start the virgin segment #1 is read. During
a restart, however, the current data of segment #0 is input to the Nodal Data.
Second the Outbound Message Buffer is reset to a completely empty buffer during a start.
During a restart the current data of the Checkpoint File is input to the Outbound Message
Buffer.
3.3.9.2 F̲u̲n̲c̲t̲i̲o̲n̲s̲
The Nodal Data File is opened and input as described in ch. 3.3.9.1.
The Jack File is opened and input.
The Checkpoint File is opened. The Outbound Message Buffer is either reset or filled with
the Checkpoint File as described in ch. 3.3.9.1.
The MTCB-Monitor is initialized.
The Coroutine Monitor is initialized.
Finally the Starting Module is stopped.
3.3.9.3 O̲p̲e̲r̲a̲t̲i̲o̲n̲s̲
None…86…W …02… …02… …02… …02…
FIG. 3.3.9..4-1:
THE RECOVERY MODULE
3.3.9.5 S̲i̲z̲e̲
The size of the code is 232 instructions.
The necessary data are occupies 47 words.
3.3.9.6 T̲i̲m̲i̲n̲g̲
About 200 intructions are executed for start and restart corresponding to CPU-time of 0.4
ms.
3.3.10 T̲h̲e̲ ̲C̲h̲e̲c̲k̲p̲o̲i̲n̲t̲i̲n̲g̲ ̲R̲a̲t̲e̲
3.3.10.1 N̲a̲r̲r̲a̲t̲i̲v̲e̲ ̲M̲e̲s̲s̲a̲g̲e̲s̲
The simplified flow model shown in fig. 3.3.10-1 assumes:
- no messages to/from the SIP.
The positive checkpointing rate from the NSS, the MDS and the SIP is seen to be:
CRPOS…0f…n…0e…(NSS+MDS+SIP)=DEST…0f…n…0e…+OUT-GEN…0f…n…0e…+OUT…0f…n…0e… (1)
and from the NSS alone:
FIG. 3.3.10.1-1:
THE FLOW OF NARRATIVE MSGS.
CRPOS…0f…n…0e…(NSS) = DEST…0f…n…0e…+OUT-GEN…0f…n…0e…+OUT…0f…n…0e…-ORIG…0f…n…0e… (2)
The negative checkpointing rate from the NSS, the
MDS and the SIP is seen to be :
CRNEG…0f…n…0e…(NSS+MDS+SIP) = DEST…0f…n…0e…+OUT-GEN…0f…n…0e…+OUT…0f…n…0e… (3)
so from (1) and (3) is found during steady state:
CRPOS…0f…n…0e…(NSS+MDS+SIP) = CRNEG…0f…n…0e…(NSS+MDS+SIP) (4)
From the NSS alone one finds:
CRNEG…0f…n…0e…(NSS) = OUT-GEN…0f…n…0e…+OUT…0f…n…0e… (5)
The checkpointing rate for narrative messages initiated by the NSS is now easily found from
(2) and (5):
CR…0f…n…0e…(NSS) = CRPOS…0f…n…0e…(NSS) + CRNEG…0f…n…0e…(NSS) =
DEST…0f…n…0e…+4* OUT-2 GEN…0f…n…0e…-ORIG…0f…n…0e… (6)
3.3.10.2 C̲o̲n̲t̲r̲o̲l̲ ̲M̲e̲s̲s̲a̲g̲e̲s̲
The experiences until now seems to show that the (idle) load of control messages equals the
busy hour load of narrative messages.
Supposing that control messages are neither generated nor deleted by the NSS the checkpointing
rate will be:
CRPOS…0f…c…0e…(NSS) = CRPOS…0f…n…0e…(NSS) (7)
From (4) is found:
CRPOS…0f…c…0e…(NSS+MDS+SIP)=CRNEG…0f…c…0e…(NSS+MDS+SIP) (8)
and from the NSS alone:
CR…0f…c…0e…(NSS) = CR…0f…n…0e…(NSS) (9)
3.3.10.3 T̲o̲t̲a̲l̲ ̲R̲a̲t̲e̲
The total checkpointing rate initiated by the NSS is found from (6) and (9):
CR(NSS) = CR…0f…n…0e…(NSS)+CR…0f…c…0e…(NSS) =
2* DEST…0f…n…0e…+8* OUT…0f…n…0e…-4 * GEN…0f…n…0e…-2* ORIG…0f…n…0e…
For an average node during busy hour one finds:
…0e… ̲ ̲ ̲ ̲ ̲ ̲ ̲…0f…=…0e… 1̲
…0e…CR(NSS)…0f… 8 all nodes(2 DEST…0f…n…0e…+8 OUT…0f…n…0e…-4 GEN…0f…n…0e…-2 ORIG…0f…n…0e…)=
i.e. (cfr.ch. 3.6.2.1):
̲ ̲ ̲ ̲ ̲ ̲…0f…=…0e… 1̲
CR(NSS) 8 (2…0e….…0f… 1.720+8…0e….…0f… 1.970-4…0e….…0f… 0.972-2…0e….…0f… 0.748)
or
CR(NSS) = 1.7 Checkpoints (10)
From (4) and (8) is found:
CRPOS(NSS+MDS+SIP) = CRNEG(NSS+MDS+SIP) (11)
This steady-state result is n̲o̲t̲ affected by removing the basic assumptions:
- Messages to and from the SIP will donate exactly as many positive as negative checkpoints
in the SIP-Queue as well as in the Transport Queue.
- Control messages generated and deleted by the NSS will donate exactly as many positive
as negative checkpoints.
3.3.11 T̲i̲m̲e̲r̲s̲ ̲a̲n̲d̲ ̲R̲e̲t̲r̲a̲n̲s̲m̲i̲s̲s̲i̲o̲n̲s̲
3.3.11.1 T̲h̲e̲ ̲L̲i̲n̲k̲ ̲L̲e̲v̲e̲l̲
If a frame has not been acknowledged, when the timer T…0f…HDLC…0e… expires, the HDLC protocol implemented
in the red CRYPTO-LTUX will retransmit the frame up to a maximum of N…0f…HDLC…0e… times.
The transmission time of a frame of max. size 512 data bytes on a transmission line of 1200
bit per s is:
t…0f…p…0e… =(512+6+170) 8/1200 = 4.6 s
regarding headers, bit stuffing and SYNC-characters.
It must be fulfilled that:
T…0f…HDLC…0e… t…0f…p…0e… + t…0f…p…0e…
therefore
T…0f…HDLC…0e… = 15 s.
The max.no. of retransmissions has been set to:
N…0f…HDLC…0e… = 2.
3.3.11.2 T̲h̲e̲ ̲P̲a̲c̲k̲e̲t̲ ̲L̲e̲v̲e̲l̲
No retransmission is performed on the packet level.
3.3.11.3 T̲h̲e̲ ̲M̲e̲s̲s̲a̲g̲e̲ ̲L̲e̲v̲e̲l̲
If a message has not been acknowledged, when the timer T…0f…MSG…0e… expires, the message protocol
implemented in the Transport Station will retransmit the message up to a maximum of N…0f…MSG…0e…
times.
The timer is started when the Packet Handler starts transmission of the last packet of the
message.
The transmission time of the last packet incl. possible HDLC retransmissions is
t…0f…M…0e… T…0f…HDLC…0e… . (1+N…0f…HDLC…0e…) = 15 3 = 45 s T…0f…MSG…0e…
Therefore
T…0f…MSG…0e… = 50 s.
The max. no. of retransmissions has been set to:
N…0f…MSG…0e… = 3
3.3.11.4 T̲h̲e̲ ̲N̲e̲t̲w̲o̲r̲k̲ ̲L̲e̲v̲e̲l̲
If a MICK control message or another message has not been acknowledged nor nacknowledged,
when the timer T…0f…MSG…0e… expires, the message protocol implemented in the Transport Station will
retransmit the message up to a maximum of (N…0f…MSG…0e…-2) times.
If the timer expires also after the max. no. of retransmissions, the neighbour node is supposed
to be failed.
A MICK control message is generated by the Monitoring Module. The period is determined by:
T…0f…n…0e… T…0f…MSG…0e… .(N…0f…MSG…0e… - 2+1) = 100 s
so
T…0f…n…0e… = 180 s.
A failed neighbour will therefore in average be detected after:
̲ ̲ ̲
t…0f…n…0f…f…0e……0e…= 0.5 T…0f…n…0e…+T…0f…MSG…0e….(N…0f…MSG…0e…-1)=0.5 180+50 2 or
̲ ̲ ̲
t…0f…n…0f…f…0e……0e…= 190 s.
3.3.12 O̲p̲e̲n̲/̲C̲l̲o̲s̲e̲ ̲T̲r̲u̲n̲k̲
Each trunk in the FIKS network may be individually opened and closed. This is also true
for the TRANS connection between a SCC and its collocated node.
Before a trunk is opened the two nodes must be physically connected, and power must be switched
on the LTUX-TRUNK/TRANS and a possible modem in both ends.
When a trunk is o̲p̲e̲n̲e̲d̲ the most important things to happen are:
- Packet- and message counters are reset.
- Message traffic is allowed to flow on the trunk
An open trunk may be c̲l̲o̲s̲e̲d̲.
The items mentioned below are done:
- Message traffic is not allowed to flow on the trunk. Restart packets on level 3, however,
will flow before the trunk is reopened.
- The Trunk-Queue is emptied for empty packets.
- Outbound messages routed for that trunk (and not yet acknowledged from the neighbour)
are rerouted.
- Inbound messages partly received are released.
It is seen that the Data User traffic is not influenced by the opening and the closing of
trunks.
The basic principles behind opening and closing a trunk- or trans-connection are:
- The control message (open- or close-trunk) from the supervisor is forwarded to one
node only of a pair.
This is necessary because often the SCC will be connected only to one of the nodes.
Example: OPEN QK1.
- A trunk is opened simultaneously in both directions, and also closed in both directions.
This is because a trunk is a full duplex connection.
It means that the NSS in both ends must know that the trunk is being opened/closed.
- Outbound messages routed for a trunk- or trans-connection being closed (and not yet
acknowledged from the neighbour) are attempted to be rerouted via another trunk.
- Inbound messages only partly received have their resources released.
This mechanism is also used when a trunk is disconnected.
When power is switched on a LTUX-TRUNK it tries to synchronize with its neighbour until this
happens.
When an open-trunk command is sent from the NSS to a LTUX-TRUNK one of the belowmentioned
situations will exist:
- the power of the LTUX-TRUNK is OFF. It will not answer, and a timer will run out.
- the power of the LTUX-TRUNK is ON, but on the neighbour LTUX it is not, so they are
not in synchronism, and it will return the answer: "disconnected".
- the power of the LTUX-TRUNK is ON, and it is synchronized with its neighbour LTUX.
The answer "closed" will be returned to the NSS.
FIG. 3.3.1.2-1:
OPEN TRUNK
FIG. 3.3.1.2-2:
OPEN TRANS
FIG. 3.3.1.2-3:
CLOSE TRUNK
FIG. 3.3.1.2-4:
CLOSE TRANS
3.3.13 N̲P̲D̲N̲ ̲C̲a̲l̲l̲-̲u̲p̲ ̲a̲n̲d̲ ̲C̲l̲o̲s̲e̲-̲d̲o̲w̲n̲
A disconnected trunk may be replaced by an NPDN - connection. Each of the 8 nodes has its
own two-digit call number, so a node can n̲o̲t̲ be involved in more than one NPDN call; therefore,
at a given instant a maximum of 4 NPDN connections may be established.
A connection may be dialed up from any of the two MEDE…08…s. As shown in the figure overleaf
the control-message from the MEDE is received by the Control Module. After a check the call
is signalled to the Monitoring Module, which activates the LTUX-NPDN. Having established
the connection the LTUX in both ends informs the Monitoring Module, which returns a control
message to the MEDE. The state is changed from disconnected to closed.
The connection is closed down in an analogous way.
After calling-up the NPDN connection may be opened and closed like an ordinary trunk.
Meanwhile, the original trunk may be connected, and its state will then change to closed.
However, it cannot be opened until the NPDN connection has been closed down.
FIG. 3.3.1.3-1:
NPDN CALL-UP
FIG. 3.3.1.3-2:
NPDN CLOSE-DOWN
3.4 D̲a̲t̲a̲ ̲O̲r̲g̲a̲n̲i̲z̲a̲t̲i̲o̲n̲
3.4.1 L̲e̲v̲e̲l̲s̲ ̲o̲f̲ ̲D̲a̲t̲a̲
For the sake of readability of the NSS listing and for the sake of minimizing the storage-and
time-consumption during assembly the data are organized in a hierachical structure as shown
in the figure overleaf.
In the subsequent chapters, however, the kind of data structure: file, queue, buffer etc.,
will be followed rather than the hierachical structure.
FIG. 3.4.1-1:
LEVELS OF DATA
3.4.2 T̲h̲e̲ ̲D̲a̲t̲a̲ ̲B̲a̲s̲e̲s̲
3.4.2.1 T̲h̲e̲ ̲P̲r̲e̲p̲a̲r̲a̲t̲i̲o̲n̲ ̲D̲a̲t̲a̲ ̲B̲a̲s̲e̲
The P̲r̲e̲p̲a̲r̲a̲t̲i̲o̲n̲ ̲D̲a̲t̲a̲ ̲B̲a̲s̲e̲ ̲P̲D̲B̲ is described in the FIKS Data Interface Reference.
The PDB contains some of the messages of the Transport-Queue, namely outgoing messages originating
from the MEDE of the type S̲P̲E̲C̲A̲T̲.̲
3.4.2.2 T̲h̲e̲ ̲H̲i̲s̲t̲o̲r̲i̲c̲a̲l̲ ̲D̲a̲t̲a̲ ̲B̲a̲s̲e̲
The H̲i̲s̲t̲o̲r̲i̲c̲a̲l̲ ̲D̲a̲t̲a̲ ̲B̲a̲s̲e̲ ̲H̲D̲B̲ is described in the FIKS Data Interface Reference.
The HDB files contain some of the outgoing messages of the Transport Queue, i.e. messages
originating from the MEDE, not of the type SPECAT.
3.4.2.3 T̲h̲e̲ ̲I̲n̲t̲e̲r̲m̲e̲d̲i̲a̲t̲e̲ ̲M̲e̲s̲s̲a̲g̲e̲ ̲F̲i̲l̲e̲
The Intermediate Message File (IMF) is a p̲e̲r̲m̲a̲n̲e̲n̲t̲ file on the fix-head disc of a NODE/MEDE.
The IMF contains all inbound messages and all NSS generated messages (for the network as
well as for the local MEDE).
The necessary size of the file will vary from node to node, dependant on the busy hour load
of the node in question. For convenience, however, the s̲i̲z̲e̲ ̲i̲s̲ ̲f̲i̲x̲e̲d̲, see chapter 3.4.2.3.1.
The file is used for t̲e̲m̲p̲o̲r̲a̲r̲y̲ ̲s̲t̲o̲r̲a̲g̲e̲ of messages. The average storage time is app. 50
seconds (see ch. 3.4.2.3.1).
Regarding the fixed size of the file and the necessity of fast access during heavy load,
the file organization is socalled "contiguous".
At f̲i̲l̲e̲ ̲c̲r̲e̲a̲t̲i̲o̲n̲ at system generation time the IMF is entirely filled with pseudo data just
to fix its size.
The IMF is a̲c̲c̲e̲s̲s̲e̲d̲ from several processes in parallel (NSS, MDS, SIP).
The file is divided into message areas of 9216 bytes (= 18 segments) big enough for a messge
of maximum length, incl. the binary header, see fig. 3.4.2.3-1.
The b̲l̲o̲c̲k̲s̲i̲z̲e̲ equals the m̲a̲x̲i̲m̲u̲m̲ ̲p̲a̲c̲k̲e̲t̲ ̲s̲i̲z̲e̲: 5̲1̲2̲ ̲b̲y̲t̲e̲s̲.
Inbound packets are written in the file in a d̲i̲r̲e̲c̲t̲ manner: Packets from several messages
are mixed on the input trunks, but written message-wize in the file.
After having initiated an I/O-transfer, the process must n̲o̲t̲ ̲b̲e̲ ̲s̲u̲s̲p̲e̲n̲d̲e̲d̲, because other
coroutines of the process need to be active.
FIG. 3.4.2.3-1:
THE IMF
3.4.2.3.1 T̲h̲e̲ ̲S̲i̲z̲e̲ ̲o̲f̲ ̲t̲h̲e̲ ̲I̲M̲F̲
A message area of the IMF for a relay message is reserved from the time when the first packet
is well received by the Transport Station until the receipt of an ACK from the next node
for the entire message.
Taking a relay message as a typeical example this period of time may be divided into:
a. Receipt of first packet - receipt of last packet.
b. Receipt of last packet - message put into Transport Queue
c. Message in Transport Queue.
d. Removal from Transport Queue - Insertion into Trunk Queue
e. Insertion into Trunk Queue - first packet out of Trunk Queue.
f. First packet out of Trunk Queue - last packet sent.
g. Last packet sent - receipt of acknowledge for the message.
The periods of time are calculated in this way:
a. Without priority of messages the transmission time during busy hour is 2.60…0e….…0f… 4.9 =
13 s for narrative messages; assuming that the transmission time is independent of
precedence level, the time is set to 1̲3̲ ̲s̲.
b. The time is much less than 1 sec., so it is set to 0̲ ̲s̲.
c. The average waiting time in the Transport Queue (excl. the Delay Queue) is 0̲ ̲s̲.
d. The time is much less that 1 sec., so it is set to 0̲ ̲s̲.
e. The average waiting time in (the Delay Queue and) the Trunk Queue is 2̲0̲ ̲s̲e̲c̲.
f. 1̲3̲ ̲s̲., cfr. item a.
g. The time is set to 4̲ ̲s̲.
So the message area of the IMF is reserved in average:
t…0f…i…0e… = 50 s
The average inbound trunk traffic during busy hour equals the average outbound trunk traffic
(excl. ACK/NACK…08…s):
IN…0f…n…0e… 2 1.97 2
m …0f…=…0e… ̲ ̲ ̲ ̲ ̲ ̲ ̲ …0f…=…0e… ̲ ̲ ̲ ̲ ̲ ̲ ̲
18 2
T…0f…n…0e…
…0f…n…0e…
or
m = 0.11 nar. and ctr. msgs per trunk per second
see fig. 3.6.2.1-3.
Three independent dimension criteria determine the size of the IMF:
o Avoidance of "reassembly lockup"
o Busy minute load
o Build-up of messages for failed neighbours
Below is shown that fulfilling the busy minute load, the IMF size will also fulfill the two
other criteria.
The first dimensioning criterion is very important: to avoid "̲r̲e̲a̲s̲s̲e̲m̲b̲l̲y̲ ̲l̲o̲c̲k̲u̲p̲". This dangerous
lockup could occur if the IMF is so small that it can not contain one message per precedence
level per input trunk. Supposing that a message of lowest precedence level is being received
on each input trunk of a node, but before transmission of the last packet the transmissions
are all aborted by messages of a precedence level next to the lowest; the transmissions of
these messages are also aborted etc., and sooner or later the entire IMF is reserved by unfinished
messages, and the node is congested.
Therefore the minimum size of the IMF is:
I…0f…1…0e… = T NPL
for ex.:
I…0f…1…0e… = 7 7 = 49 areas for node K
The second dimension criteria: "busy minute load" says that the IMF must accumulate at least
3 times busy hour load (see (2) below):
I…0f…2…0e… = m T t…0f…i…0e… 1̲/̲2̲+̲T̲ 3
1+T
f. ex.:
I…0f…2…0e… = 0.11 7 50 0.94 3 = 108 areas for node K.
The third dimension criteria tells that the IMF must be big enough for the build-up of messages
for neighbours which are failed, but not yet detected as failed:
Suppossing that N neighbours are failed almost simultaneously, then the number of messages
on the IMF is the sum of messages for active neighbours, for failed neighbours and for the
N/M itself:
I = m (T-N) T̲-̲N̲ t…0f…i…0e… +
T+1
m (T-N) ̲N̲ ̲ t…0f…n…0e…/2 +
T+1
m (T-N) ̲1̲ ̲ t…0f…i…0e…/2
T+1
where t…0f…n…0e… means the average time for detection of a neighbour node failure. The small amount
of messages generated by the NSS itself is disregarded.
The expression may be written in this way:
I = 1̲ ̲m̲ ̲ -t…0f…n…0e… -2t…0f…i…0e… N…0e…2…0f…+ T(t…0f…n…0e…-4t…0f…i…0e…)-t…0f…i…0e… N+T 1+2Tt…0f…i…0e… (1)
2 T+1
For N = 0 one gets the busy hour size:
I…0f…o…0e… = M T t…0f…i…0e… ̲ ̲+̲T̲ (2)
1+T
Differentiating (1) with respect to N gives:
d̲I̲ …0f…=…0e… 1̲ ̲m̲ ̲ -2 t…0f…n…0e… - 2 t…0f…i…0e… N+T t…0f…n…0e… -4t…0f…i…0e… -t…0f…i…0e… (3)
dN 2 T+1
Setting d̲I̲ …0f…=…0e… 0 one gets:
dN
2N…0f…m…0e… t…0f…n…0e… - 2t…0f…i…0e… = T t…0f…n…0e… - 4t…0f…i…0e… -t…0f…i…0e…
or
N…0f…m…0e… = …0e… t…0f…n…0e…-4t…0f…i…0e… -t…0f…i
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
2 t…0f…n…0e… -2t…0f…i…0e… (4)
From (1) and (4) is found the extremum:
I…0f…m…0e… = m (T t…0f…n…0e… + t…0f…i…0e…)
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
8 (T +1)(t…0f…n…0e… - 2t…0f…i…0e…) (5)
In fig. 3.4.2.3.1-1 is shown I versus N for various values of t…0f…n…0e…. They show that the present
value for t…0f…n…0e… = 190 s is n̲o̲t̲ critical. By multiplying this curve by 3 one gets the curve
I…0f…3…0e….
The conclusion is that to resist failed neighbours during busy minute the IMF size must be
at least 108 areas in node K. For convenience, however, it is installed with equal size
in each node:
I = 112 message areas = 2016 segment.
FIG. 3.4.2.3.1-1:
MINIMUM SIZE OF THE IMF
TO RESIST FAILED
NEIGHBOURS DURING
BUSY MINUTE AND BUSY HOUR.
3.4.2.4 T̲h̲e̲ ̲N̲o̲d̲a̲l̲ ̲D̲a̲t̲a̲ ̲F̲i̲l̲e̲
The N̲o̲d̲a̲l̲ ̲D̲a̲t̲a̲ ̲F̲i̲l̲e̲ ̲N̲D̲F̲ fig. 3.4.2.4-1 is described in the FIKS Data Interface Reference.
It contains information about the local network and the node configuration necessary for
start and restart. During operation it is maintained by the NSS, so it will be updated ready
for restart.
The NDF consists of 2 segments:
o segment #1 contains the virgin NDF, which is input during a start condition.
It was generated during system generation time, and it is never updated.
o segment #0 contains the NDF, which is input during a restart condition. It is updated
currently, when any of the Nodal Data is changed.
FIG. 3.4.2.4-1:
NODAL DATA FILE
3.4.2.5 T̲h̲e̲ ̲J̲a̲c̲k̲ ̲F̲i̲l̲e̲
The J̲a̲c̲k̲ ̲F̲i̲l̲e̲ contains the device number and the jack number of each Data User of a node.
It is described in the FIKS Data Interface Reference.
The file is read into the Jack Table during initialization (start as well as restart).
An example of the Jack File (for node K) is shown overleaf.
NODE K
3.4.2.6 T̲h̲e̲ ̲C̲h̲e̲c̲k̲p̲o̲i̲n̲t̲ ̲F̲i̲l̲e̲
The NSS Checkpoint File or the Outbound Message File is shown overleaf.
It is currently updated by dumping the OMB.
During a start it is reset; during a restart it is input as left before crash.
The size is:
1 + (T + 1) NPL MW OMBFL =
1 + (T + 1) 70 words
FIG. 3.4.2.6-1:
OUTBOUND MESSAGE FILE
3.4.2.7 T̲h̲e̲ ̲L̲T̲U̲X̲ ̲C̲o̲n̲f̲i̲g̲u̲r̲a̲t̲i̲o̲n̲ ̲F̲i̲l̲e̲s̲
The LTUX Configuration Files consist of three sets of binary files on the disc:
- files for normal network configuration
- - - alternate (1) network -
- - - - (2) network -
A set of files is output by the NSS to the LTUX…08… during:
- start
- restart
- reconfiguration
- calling-up an NPDN connection.
- closing-down an NPDN connection.
3.4.3 Q̲u̲e̲u̲e̲s̲
The queues accessed by the NSS are:
- The Transport Queue (TRP-Q)
- The Control Queue (CTR-Q)
- The MDS Queue (MDS-Q)
- The CIP Queue (CIP-Q)
- The SIP Queue (SIP-Q)
- The Trunk Queue (TRK-Q)
- The Purge Queue (PGE-Q)
They are shown on fig. 3.3.1-1 and they are all described in the subsequent chapters.
3.4.3.1 Q̲u̲e̲u̲e̲ ̲L̲e̲n̲g̲t̲h̲s̲ ̲a̲n̲d̲ ̲W̲a̲i̲t̲i̲n̲g̲ ̲T̲i̲m̲e̲s̲
Before calculating the average queue length and the average waiting time of the Transport
Queue, the Control Queue, the MDS Queue, the SIP Queue, and the Trunk Queue some assumptions
are made.
It is assumed that t̲h̲e̲ ̲a̲r̲r̲i̲v̲a̲l̲ ̲o̲f̲ ̲q̲u̲e̲u̲e̲ ̲e̲l̲e̲m̲e̲n̲t̲s̲ ̲ ̲i̲s̲ ̲a̲ ̲P̲o̲i̲s̲s̲o̲n̲ ̲p̲r̲o̲c̲e̲s̲s̲. This is a fairly
good approximation for the Transport-, the Control-, the MDS-, and the SIP-Queue for which
the queue elements are messges. For the Trunk Queue, however, the queue elements are packets
of chopped messages; therefore the assumption may be a little optimistic.
Further it is assumed that t̲h̲e̲ ̲s̲e̲r̲v̲i̲c̲e̲ ̲t̲i̲m̲e̲s̲ (the processing time of a queue element) a̲r̲e̲
̲e̲x̲p̲o̲n̲e̲n̲t̲i̲a̲l̲l̲y̲ ̲d̲i̲s̲t̲r̲i̲b̲u̲t̲e̲d̲.
If a̲ ̲i̲s̲ ̲t̲h̲e̲ ̲a̲v̲e̲r̲a̲g̲e̲ ̲n̲u̲m̲b̲e̲r̲ ̲o̲f̲ ̲q̲u̲e̲u̲e̲ ̲e̲l̲e̲m̲e̲n̲t̲s̲ ̲a̲r̲r̲i̲v̲i̲n̲g̲ ̲p̲e̲r̲ ̲t̲i̲m̲e̲ ̲u̲n̲i̲t̲, and 1̲/̲b̲ ̲i̲s̲ ̲t̲h̲e̲ ̲a̲v̲e̲r̲a̲g̲e̲
̲s̲e̲r̲v̲i̲c̲e̲ ̲t̲i̲m̲e̲, then the a̲v̲e̲r̲a̲g̲e̲ ̲n̲u̲m̲b̲e̲r̲ ̲K̲ ̲o̲f̲ ̲e̲l̲e̲m̲e̲n̲t̲s̲ ̲i̲n̲ ̲t̲h̲e̲ ̲q̲u̲e̲u̲e̲ ̲i̲s̲
K…0f…=…0e… a…0e…2…0f… …0f…=…0e… 8…0e…2…0f…
…0e… ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
…0f… b(b-a) 1-8
and t̲h̲e̲ ̲a̲v̲e̲r̲a̲g̲e̲ ̲w̲a̲i̲t̲i̲n̲g̲ ̲t̲i̲m̲e̲ ̲W̲ ̲i̲n̲ ̲t̲h̲e̲ ̲q̲u̲e̲u̲e̲ is
W …0f…=…0e… ̲ ̲ ̲a̲ ̲ ̲ ̲
b(b-a)
the u̲t̲i̲l̲i̲z̲a̲t̲i̲o̲n̲s being
s …0f…=…0e…\ ̲ ̲a̲ ̲ ̲
b
No overload requires
a b.
3.4.3.2 T̲h̲e̲ ̲T̲r̲a̲n̲s̲p̲o̲r̲t̲ ̲Q̲u̲e̲u̲e̲
3.4.3.2.1 R̲e̲q̲u̲i̲r̲e̲m̲e̲n̲t̲s̲
The T̲r̲a̲n̲s̲p̲o̲r̲t̲ ̲Q̲u̲e̲u̲e̲ (TRP-Q) is the N̲S̲S̲ ̲i̲n̲p̲u̲t̲ ̲q̲u̲e̲u̲e̲.
Consequently all messages, which should be r̲o̲u̲t̲e̲d̲ by the NSS for further transport through
the network or just for local distribution, are put into this queue.
This is done not only by the subsystems of the M̲E̲D̲E̲, the S̲I̲P̲, or the S̲C̲C̲, but also by the
N̲S̲S̲ itself. It is done for messages coming in from the network (relay-messages or r̲e̲m̲o̲t̲e̲-generated-messages),
and also for l̲o̲c̲a̲l̲-generated messages, i.e. messages generated by the local NODE, MEDE, SIP,
or SCC. This is valid for all main types of messages: narrative, control incl. ACK, NACK,
MICK and MACK…08…s.
Messages, which should be d̲e̲l̲a̲y̲e̲d̲ by the NSS due to flow control, are also put into the Transport
Queue. F̲l̲o̲w̲ ̲c̲o̲n̲t̲r̲o̲l̲ means that the number of messages of a particular precedence level transmitted
on a particular trunk and not yet acknowledged should not exceed a certain limit (the window).
A message of a higher l̲e̲v̲e̲l̲ ̲o̲f̲ ̲p̲r̲e̲c̲e̲d̲e̲n̲c̲e̲ must be routed before a message of lower level
of precedence on a particular trunk.
Within the same level of precedence a delayed message must be (attempted to be) routed before
a remote generated message; a remote generated message must be routed before a local generated
message. This "̲t̲r̲a̲f̲f̲i̲c̲ ̲c̲o̲n̲t̲r̲o̲l̲"̲ works against a congestion situation: within a precedence
level no new traffic is taken into the network before old traffic is processed; and no traffic
is receivead from a neighbour node before delayed traffic has been transmitted. However,
a remote generated ACK for this node must be processed before delayed traffic.
Further, the delay of a message of higher level of precedence m̲u̲s̲t̲ ̲n̲o̲t̲ ̲p̲r̲e̲v̲e̲n̲t̲ the routing
of a message of lower level of precedence; the reason is that the latter may be transmitted
by another trunk.
A non-empty queue of delayed messages must not keep the NSS unnecessarily busy stealing CPU
time from other processes and other co-routines.
3.4.3.2.2 D̲e̲s̲i̲g̲n̲
The Transport Queue: T̲R̲P̲-̲Q̲ consists of:
o the D̲e̲l̲a̲y̲-̲Q̲u̲e̲u̲e̲
for delayed messages (remote or local generated)
o the R̲e̲m̲o̲t̲e̲-̲Q̲u̲e̲u̲e̲
for remote-generated messages
o the L̲o̲c̲a̲l̲-̲Q̲u̲e̲u̲e̲
for local-generated messages
Each of these 3 queues consists of 7 sub-queues, one for each l̲e̲v̲e̲l̲ ̲o̲f̲ ̲p̲r̲e̲c̲e̲d̲e̲n̲c̲e̲, see fig.
3.4.3.2.2-1.
The Transport Queue may also be shown as in fig. 3.4.3.2.2-2, where the sub-queues are ordered
by the level of precedence. When scanned by the NSS this is done from the left to the right.
It should be emphasized that this is done to the f̲a̲r̲ ̲r̲i̲g̲h̲t̲, also when one or more messages
are found in the subqueues before the lowest subqueue is scanned. For superflash msgs (f.ex.
ACK…08…s) the Remote Queue is scanned before the Delay-Queue.
The NSS is a̲w̲a̲i̲k̲e̲d̲ e̲a̲c̲h̲ ̲t̲i̲m̲e̲ a message is put into the Remote - or the Local-Queue, a̲l̲s̲o̲
̲w̲h̲e̲n̲ ̲t̲h̲e̲ ̲T̲R̲P̲-̲Q̲ ̲a̲l̲r̲e̲a̲d̲y̲ ̲c̲o̲n̲t̲a̲i̲n̲s̲ ̲m̲e̲s̲s̲a̲g̲e̲s̲, for example in the Delay-Queue.
However, when a message is put into the Delay-Queue the NSS is n̲o̲t̲ awaiked, because it would
then be awaiked by itself.
FIG. 3.4.3.2.2-1:
THE TRANSPORT QUEUE
R D L D R L D R L D R L D R L D R L D R L
S F Y O P M R
LEGEND : D: Delay - Queue
R: Remote - Queue
L: Local - Queue
S: Superflash
Z: Flash
Y: Rush
O: Immediate
P: Priority
M: Quick
R: Routine
FIG. 3.4.3.2.2-2:
THE TRANSPORT QUEUE
3.4.3.2.3 U̲s̲a̲g̲e̲
The number of messages (incl. ACK/NACK's) put into the r̲e̲m̲o̲t̲e̲ ̲o̲r̲ ̲l̲o̲c̲a̲l̲ ̲q̲u̲e̲u̲e̲ of the Transport
Queue is (ch. 3.6.2.1):
a = OUT or
a = 1.23 messages/s
for Node K, which is the Node of highest load.
The service time of the output submodule of the Transport Station is app. 10 ms per message,
so:
b = 100 messages/s.
Therefore the average queue length is:
K a…0e…2…0e… 0.67…0e…2…0f… 0.1 10…0e…-3…0f… elements
…0f…=…0e… ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ …0f…=…0e… ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ …0f…=…0e…
b(b-a) 100(100-0.67)
and the average waiting time is:
W a 0.67 …0f…=…0e…0.1 10…0e…-3…0f… sec.
…0f…=…0e… ̲ ̲ ̲ ̲ ̲ ̲ ̲…0f…=…0f… ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
b(b-a) 100(100-0.67)
The calculations above are valid only during steady state. During rerouting conditions (node
restart, hard trunk failure etc) the remote and local queue may be longer, and especially
the d̲e̲l̲a̲y̲ ̲q̲u̲e̲u̲e̲ which is an extension of the Trunk Queue may grow.
3.4.3.3. T̲h̲e̲ ̲C̲o̲n̲t̲r̲o̲l̲ ̲Q̲u̲e̲u̲e̲
The Control Queue (CTR-Q) is the input queue of the Control Module.
The queue elements of the CTR-Q are MTCB pointers of control messages for the NSS.
I should be noticed that ACK/NACK control messages are n̲o̲t̲ put into the CTR-Q. They are processed
by the Transport Station.
A queue element is put into the CTR-Q by the Transport Station and taken out of the queue
by the Control Module.
The number of ingoing control messages (except for ACK/NACK) is:
a 0.1 msgs/s.
The service time of the Control Module is determined by:
b = 100 msgs/s.
The average queue length is:
a 2 -6
̲ ̲a̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲0̲.̲1̲ ̲ ̲ ̲ ̲ ̲ ̲ 1 10
K= elements
b(b-a) 100(100.0.0)
The average waiting time is:
-6
̲ ̲a̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲0̲.̲1̲ ̲ ̲ ̲ ̲ ̲ ̲ 10 10
W= sc
b(b-a) 100(100-0.1)
3.4.3.4 T̲h̲e̲ ̲M̲D̲S̲ ̲Q̲u̲e̲u̲e̲
The MDS Queue is the queue to the MEDE (and for narrative messages also to the SIP); so this
queue is found on A,B,E,F,H,K,L and N.
It consists of 7 subqueues: one per precedence level.
The elements are put into the queue by the Transport Station, and taken out from the queue
by the MDS.
3.4.3.5 T̲h̲e̲ ̲C̲I̲P̲ ̲Q̲u̲e̲u̲e̲
The CIP Queue is the queue to the SCC, i.e. it is found only on P and Q.
It consists of 7 subqueues: one per precedence level.
The elements are put into the queue by the Transport Station, and taken out from the queue
by the SCC.
3.4.3.6 T̲h̲e̲ ̲S̲I̲P̲ ̲Q̲u̲e̲u̲e̲
The SIP Queue is the queue to the SIP on the collocated N/M: E and K.
It consists of 7 subqueues : one per precedence level.
The elements are put into the queue by the Transport Station, and taken out from the queue
by the SIP.
3.4.3.7 T̲h̲e̲ ̲T̲r̲u̲n̲k̲ ̲Q̲u̲e̲u̲e̲
There exists one Trunk Queue (TRK-Q) per trunk inside the NSS. A TRK-Q contains pointers
of packets of messages routed on the trunk waiting for transmission.
A TRK-Q consists of 7 subqueues: one per precedence level. Furthermore there exists one
general semaphore per trunk: PHG (t), which is used for announcement of an operation, see
below. Also see fig.3.4.3.7-1.
The packet pointers are stored in the TRK-Q by the Transport Station, when a message has
been routed and chopped into packets.
When the packet has been transmitted by the Packet Handler, the pointer is removed from the
queue.
The queue head is a semaphore: TRK-Q (t,p). A queue element is a long operation, see fig.3.4.3.7-2.
Therefore, this queue is processed by the Coroutine Monitor, not by QACCESS.
The messages (and so the packets) are stored on disc, so the operation is merely a pointer
to a packet. However, for an ACK or NACK, the operation contains the ACK/NACK itself.
FIG. 3.4.3.7-1:
THE TRUNK-QUEUE
word # byte # not ACK/NACK ACK/NACK
0 1 - 0 SUCC SUCC
1 3 - 2 PREC PREC
2 5 - 4 ref TS
MTCB-INDEX
3 7 - 6 not
ACK/NACK OUTPUT ACK/NACK OUTPUT
4 9 - 8 DTG DTG
5 11 - 10
6 13 - 12 FIRST PACKET/ FIRST PACKET/
MORE DATA MORE DATA
7 15 - 14 not used not used
8 17 - 16 M M ACT.
T T PREC.
9 19 - 18 ORBIT ORBIT
10 21 - 10 ROUTING CNT ROUTING CNT
MASK MASK
11 23 - 22 LENGTH OF PACKET LENGTH OF PACKET
12 25 - 24 BYTE OFFSET ACK/ TYPE
NACK
13 27 - 26 = not used ORIGIN-
ATOR
14 29 - 28 NOTE-TO-NODE NOTE-TO-NODE LOG TRK
SERIAL # 0 SERIAL # CH# SER#
FIG. 3.4.3.7-2:
OPERATIONS OF THE TRUNK-QUEUE
At first we consider a traffic of narrative messages only. During busy hour the load of each
trunk is 8 =75% in average. Considering o̲n̲e̲ ̲t̲r̲u̲n̲k̲ the queue length will not exceed:
8…0e…2…0f… 0.75…0e…2…0f… 2.25 narative msgs/trunk
K…0f…=…0e… ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ …0f…=…0e… ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ …0f…=…0e…
1 - 8 1-0.75
T̲h̲e̲ ̲s̲e̲r̲v̲i̲c̲e̲ ̲t̲i̲m̲e̲ ̲i̲s̲ ̲d̲e̲t̲e̲r̲m̲i̲n̲e̲d̲ ̲b̲y̲ ̲t̲h̲e̲ ̲t̲r̲a̲n̲s̲m̲i̲s̲s̲i̲o̲n̲ ̲t̲i̲m̲e̲.
The bandwidth is 1200 Baud, and the average message length is 1000 characters, so for all
precedence levels:
b…0f…n =…0e…1̲2̲0̲0̲/̲8̲ = 0.15 narr.msgs./s or 0.39 packets/s.
1000
The average no. of packets per narrative message is 2.60 (appendix 7.1).
The No. of narrative messages arriving is
a…0f…n…0e… = 8 b…0f…n…0e… = 0.75 0.15 or
a…0f…n =…0e…0.1125 narr.msgs./s or 0.29 narr.pcks/s.
The waiting time is:
…0e…a…0f…n \ 0.1125 = 20 s.
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
b…0f…n…0e…(b…0f…n…0e…-a…0f…n…0e…) 0.15 (0.15-0.1125)
In average over all nodes the number of outgoing control messages equals the number of outgoing
narrative messages.
The number of ACK/NACK…08…s equals the number of narrative messages plus the number of control
messages.
By adding control messages:
a…0f…c …0e…0.1125 3 control msg/s or 0.34 packet/s
the waiting time will only increase slightly:
W̲ ̲ ̲2̲0̲ ̲s̲
because the message length is only appr. 25 characters, so the service time is determined
by:
b…0f…c…0e… = 6 control msgs/s or 6 packets/s.
The queue length, however, will be a little more than four times the previous length, so
for an average trunk in an average node during busy hour load:
K …0f… …0e…2.25 2.60 + 3 2.25 1 or
K 1̲2̲.̲6̲ ̲p̲a̲c̲k̲e̲t̲s̲/̲t̲r̲u̲n̲k̲.
Using a safety factor 2.5, the maximum trunk queue will be:
3̲2̲ ̲p̲a̲c̲k̲e̲t̲s̲ ̲p̲e̲r̲ ̲t̲r̲u̲n̲k̲ ̲
Congestion will assumed to be present or non-present, respectively in the neighbour node,
if:
Trunk Queue length upper threshold or
Trunk Queue length lower threshold
The upper limit of congestion = 25 packets per trunk.
The lower limit of congestion = 22 packets per trunk, tentatively.
3.4.3.8 T̲h̲e̲ ̲P̲u̲r̲g̲e̲ ̲Q̲u̲e̲u̲e̲
The Purge Queue is a queue of "special handling" messages, which must be purged before final
release.
Such messages are enqueued for example by the Transport Station having received an acknowledgement
from the next node.
The purging is performed by the Purge Process.
3.4.3.9 R̲e̲s̲e̲r̲v̲a̲t̲i̲o̲n̲ ̲o̲f̲ ̲Q̲u̲e̲u̲e̲ ̲E̲l̲e̲m̲e̲n̲t̲
Below are listed the cases, where the NSS attempts to reserve a queue element by calling
the QACCESS procedure WRITE-ELEMENT.
Each case is given either a high priority: enqueuing will decrease the present NSS load,
or a low priority: enqueuing will increase the present NSS load.
The actual reservation is performed with the priority listed.
T̲r̲a̲n̲s̲p̲o̲r̲t̲-̲S̲t̲a̲t̲i̲o̲n̲,̲ ̲I̲n̲b̲o̲u̲n̲d̲
1. CTR-Q: Non-orbiting ctr-msg for this NSS. L
2. - : Orbiting - - - - -
3. TRP-Q: Non-orbiting narr-msg. for another N/M. L
4. - : - - ctr - - - - L
5. - : ACK/NACK from this NSS for another N/M. L
6. - : - / - from network. H
7. PGE-Q: Purging inboung "specat" msg H
8. SIP-Q: Non-orbiting narr-msg for this SIP. L
9. MDS-Q: Non-orbiting narr-msg for this MEDE. L
10. - : - - ctr - - - L
11. - : Orbiting narr-msg for another MEDE. L
12. - : - ctr. - - - L
T̲r̲a̲n̲n̲s̲p̲o̲r̲t̲-̲S̲t̲a̲t̲i̲o̲n̲,̲ ̲O̲u̲t̲b̲o̲u̲n̲d̲
1. CTR-Q: Ctr-msg for this NSS H
2. TRP-Q: Delay of narr/ctr-msg (flow control) H
3. - : N/M-Restart: Emptying of "Outbound Msg. Buffer" H
4. PGE-Q: Purging msg. in TRP-Q H
5. - : - - -"Outbound Msg. Buffer" H
6. SIP-Q: Msg. for this SIP H
7. - : SCC "not available" H
8. MDS-Q: Msg for this MEDE H
9. - : MEDE "not available". H
M̲o̲n̲i̲t̲o̲r̲i̲n̲g̲ ̲M̲o̲d̲u̲l̲e̲
1. TRP-Q: Report for SCC or MEDE Supervisor,
MICK/MACK H
3.4.4. B̲u̲f̲f̲e̲r̲s̲
3.4.4.1 T̲h̲e̲ ̲P̲o̲o̲l̲ ̲o̲f̲ ̲P̲a̲c̲k̲e̲t̲ ̲B̲u̲f̲f̲e̲r̲s̲
The pool contains a number of buffers; each buffer may contain a̲ ̲p̲a̲c̲k̲e̲t̲ of maximum size i̲n̲c̲l̲.̲
̲t̲h̲e̲ ̲p̲a̲c̲k̲e̲t̲ ̲h̲e̲a̲d̲e̲r̲ and the trunk id.: 3 + 3 + 512 bytes, see fig.
3.2.4-3.
The buffers are used for inbound as well as outbound packets. Inbound packets are stored
by the TDX-driver and removed by the Transport Station. Outbound packets are stored by the
Packet Handler and removed by the TDX-driver.
The number of buffers taken from the pool each second is for an average node (cfr. ch. 3.6.3.1):
(IN…0f…n…0e… 2.60+OUT…0f…n…0e… 2.60+IN…0f…c…0e… 1+UT…0f…c…0e… 1)/ 8=
all nodes
IN…0f…n…0e… (2.60+2.60+3+3)/8 = 2.76 buffer/s.
all nodes
In node E and K 4 buffers (2 buffers in the remaining nodes) are permanently reserved for
input.
In average an output buffer is reserved for a period of time necessary for accessing the
disc and for transmission to the red LTUX (the buffer need not to be reserved during the
remaining part of the transmission of the packet) i.e. app. 100 ms. Using a safety factor
of 8, the necessary pool size for output buffers is:
2.76/2 0.100 8 = 1.1 packets.
The pool size is set to:
Node E and K: 8 buffers of 518 bytes.
other nodes: 4 buffers of 518 bytes.
FIG. 3.4.4.1-1:
THE POOL OF PACKET BUFFERS
3.4.4.2 T̲h̲e̲ ̲C̲y̲c̲l̲i̲c̲ ̲I̲n̲p̲u̲t̲ ̲B̲u̲f̲f̲e̲r̲
The Cyclic Input Buffer consists of a cyclic ordered sub-buffer for each logical channel
(i.e. per trunk per precedence). The length of such a sub-buffer equals the window size,
i.e. 1-7 (packet pointers); at present the window size equals 3; for each input packet is
stored a packet pointer containing:
- the starting address of the packet in the pool (relative to the start of the pool).
- the actual packet length (No. of bytes).
- the more-data bit.
The pool is located in memory, see fig. 3.4.4.2-1.
The packet pointer is stored by the Packet Handler, when a packet is received from one of
the trunks via the TDX-driver and the I/O-system. The pointer is released, when the packet
has been checked and written on the disc by the Transport Station.
The size of the buffer is:
No. of words per packet pointer
No. of packet pointers per precedence (=window size)
No. of precedence levels per trunk
No. of trunks (leased or switched) for the node =
(T + 1) NPL PW CIBFL=
3 3 7 (T + 1) words or
S̲i̲z̲e̲ ̲o̲f̲ ̲C̲y̲c̲l̲i̲c̲ ̲I̲n̲p̲u̲t̲ ̲B̲u̲f̲f̲e̲r̲ ̲=̲ ̲6̲3̲ ̲ ̲N̲o̲.̲ ̲o̲f̲ ̲t̲r̲u̲n̲k̲s̲ ̲(̲w̲o̲r̲d̲s̲)̲
The current state of each sub-buffer is specified by FIRST-OCCUPIED and FIRST-FREE,see fig.3.4.4.2-1.
FIG. 3.4.4.2-1:
CYCLIC INPUT BUFFER
cib(O..T,S..R,O..(PW-1),1..CIBFL)
