top - download
⟦0b81e1298⟧ Wang Wps File
Length: 39103 (0x98bf)
Types: Wang Wps File
Notes: FIX/1154/PSP/0107
Names: »3143A «
Derivation
└─⟦507b19fd6⟧ Bits:30006135 8" Wang WCS floppy, CR 0282A
└─ ⟦this⟧ »3143A «
WangText
…07……00……00……00……00…G…02……00……00…G
G…07…F…0a…F…0d…F…0e…F…0f…F…00…F…01…F…02…F
F F…05…E…09…E…0d…E…02…E…06…E…07…D…08…D…0a…D…0b…D…0d…D…02…D D…05…C…0a…C…0e…C
C…06…C…07…B…08…B…09…B…86…1 …02… …02… …02…
…02…FIX/1154/PSP/0107
…02… JL/821210…02……02…
NODAL SWITCH SUBSYSTEM (NSS)
…02……02…FK 7809
3.3.4.3.2 O̲p̲e̲r̲a̲t̲i̲o̲n̲s̲
State: Packet In Trunk Queue
Semaphore: PHGSEM (Trunk)
Op( 5, 4): TRANSPORT STATION
- ( 7, 6): 0, PACKET READY
- ( 9, 8): 0,0
- (ll,10): 0,0
State: PREV P(R) Update from Inbound Packet Hdl.
Semaphore: PHGSEM (Trunk)
Op( 5, 4): Packet Handler
- ( 7, 6): 0, TO-PREC
- ( 9, 8): Logical Channel No. (Prec.), 0
- (11,10): 0,0
State: Restart Request from Monitoring Module
Semaphore: PHGSEM (Trunk)
Op( 5, 4): Monitoring Module
- ( 7, 6): Neighbour, TO-RESTART
- ( 9, 8): 0, Trunk Serial No.
- (11,10): 0, NPDN
State: Restart Confirmation from Inbound P.H.
Seamphore: PHGSEM (Trunk)
Op( 5, 4): Packet Handler
- ( 7, 6): 0, X2RSCC
- ( 9, 8): 0,0
- (11,10): 0,0
State: "Send RR-Packet" Request from Inbound P.H.
Semapore: PHGSEM (Trunk)
Op( 5, 4): Packet Handler
- ( 7, 6): 0, TO-CRR
- ( 9, 8): Precedence,0
- (11,10): 0,0
State: Request for Transmission of "Reset" Packet
Semaphore: PHGSEM (Trunk)
Op( 5, 4): Packet Handler
- ( 7, 6): 0, TO-CRS
- ( 9, 8): 0, Precedence
- (11,10): 0,0
State: "Trunk Non-Busy" Signalled from TRANS/CRYPTO
Semaphore: PNBSEM (Trunk)
Op( 5, 4): Packet Handler
- ( 7, 6): 0,0
- ( 9, 8): 0,0
- (11,10): 0,0
State: Disc Input Complete
Semaphore: PHOSEM (Trunk)
Op( 5, 4): Event Module
- ( 7, 6): 0, TO-INT
- ( 9, 8): 0, Completion Code
- (11,10): 0, Ref (BLE)
3.3.4.3.3 P̲r̲o̲c̲e̲s̲s̲i̲n̲g̲
In fig. 3.3.4.3.3-2.0 is shown the flowchart of the outbound packet handling per trunk; in
other words one incarnation of the coroutine per trunk (leased as well as NPDN) is running.
When a new P(R) for a particular logical channel is signalled from the Inbound Packet Handling
Coroutine, this logical channel is again allowed to attempt transmission of a packet. This
may have been stopped, if all packet sequence numbers of the window were used.…86…W …02…
…02… …02… …02… …02…
FIG. 3.3.4.3.3.-2.0:
OUTBOUND PACKET HANDLER…86…W …02… …02… …02… …02… …02…
FIG 3.3.4.3.3-2.1…86…W …02… …02… …02… …02… …02…
FIG. 3.3.4.3.3-2.2-1…86…W …02… …02… …02… …02… …02…
FIG. 3.3.4.3.3-2.2-2…86…W …02… …02… …02… …02… …02…
FIG. 3.3.4.3.3-2.2-3…86…W …02… …02… …02… …02… …02…
FIG. 3.3.4.3.3-2.3
PROCEDURE X2SCTR…86…W …02… …02… …02… …02… …02…
FIG. 3.3.4.3.3 - 2.4
PROCEDURE X2SRSP…86…W …02… …02… …02… …02… …02…
FIG. 3.3.4.3.3 - 2.5
PROCEDURE ETRKQ…86…W …02… …02… …02… …02… …02…
A packet buffer is reserved from the pool; and the packet is read from the disc into the
buffer:
init-read-bytes (file-descr., fileaddr, buffer,trfid,cc),
store trfid in disc transfer table;
wait-chained (pho)
For the first packet of a message the routing mask, the Node-to-Node serial No. and the orbit
counter are copied into the binary header.
The trunk-id as well as P(S), P(R), and M are stored in the packet header. The starting address
and the length of the packet in the buffer are stored in the short operation, which is used
to signal the packet to the Packet Output Coroutine.
A timer for the message is started at transmission of last packet. The timerident. is set
to: Node-to-Node Serial # 6 + Log. channel # 3 + Trunk Ser #.
3.3.4.3.4 S̲i̲z̲e̲
The size of the code is approximately 620 instructions.
The necessary data are occupies approximately 75 x No. of trunks words.
3.3.4.3.5 T̲i̲m̲i̲n̲g̲
About 850 instructions are executed for processing a packet of one outbound message, corresponding
to a cpu-time of 1.9 ms.
One discaccess is performed for reading an outbound packet, which corresponds to a cpu-time
of 3.2 ms.
3.3.4.4 P̲a̲c̲k̲e̲t̲ ̲-̲ ̲I̲/̲O̲
3.3.4.4.1 F̲u̲n̲c̲t̲i̲o̲n̲s̲
The Packet-I/O communicates with the red TDX-bus (packets to and from the trunks) via t̲h̲e̲
̲A̲M̲O̲S̲ ̲I̲/̲O̲-̲s̲y̲s̲t̲e̲m̲ ̲a̲n̲d̲ ̲t̲h̲e̲ ̲T̲D̲X̲-̲d̲r̲i̲v̲e̲r̲.
For all trunks (leased as well as NPDN) there is a common input coroutine, a common output
coroutine and a common data log-line. This log-line is also used for input of trunk status:
Busy/non-busy per trunk.
The maximum number of trunks is 7̲ ̲l̲e̲a̲s̲e̲d̲ ̲t̲r̲u̲n̲k̲s̲ and 1 N̲P̲D̲N̲ ̲t̲r̲u̲n̲k̲;̲ the latter will temporarily
be called up for substitution of a leased trunk.
A possible TRANS connection has its own input- and output coroutines and its own data log
line.
When the packet has been input, the packet format is checked and a possible catastrophic
failure results in a termination of the NSS process. The packet starting address and the
packet length are reported to the Inbound Packet Handling Coroutine for the trunk.
The trunk status (busy, non-busy) is input when changed via the log-line. The non-busy status
is signalled to the proper Outbound Packet Handling Coroutine.
3.3.4.4.2 O̲p̲e̲r̲a̲t̲i̲o̲n̲s̲
State: Packet Ready from LTUX-CRYPTO-RED/LTUX-TRANS
Semaphore: PISEM
Op ( 5, 4): Event Module
- ( 7, 6): 0, TO-INT
- ( 9, 8): 0, Completion Code
- (11,10): 0, Ref (BLE)
State: Wait for Completion of Output to LTUX Device
Semaphore: PCSEM
Op ( 5, 4) : Event Module
- ( 7, 6) : 0, TO-OUT
- ( 9, 8) : 0, Completion Code
- (11,10) : 0, Ref (BLE)
State: Packet Ready for Transmission on LTUX Device
Semaphore: POSEM
Op ( 5, 4) : Packet Handler
- ( 7, 6) : O, TO-PRDY
- ( 9, 8) : Buffer Address
- (11,10) : Packet Length…86…W …02… …02… …02… …02… …02…
The log-lines and their subdevices are shown in fig. 3.3.6.1-2.
The log-lines are created by the Monitoring Module at initialisation time.
The red TDX-bus is shared with MEDE Software for communication with terminals.
3.3.4.4.3 P̲r̲o̲c̲e̲s̲s̲i̲n̲g̲
3.3.4.4.3.1T̲h̲e̲ ̲I̲n̲p̲u̲t̲ ̲C̲o̲r̲o̲u̲t̲i̲n̲e̲
The Input Coroutine (one incarnation driving LTUX CRYPTO RED (TRUNKS/NPDN), and one incarnation
driving LTUX TRANS) reserves a free packet buffer from the pool (the pool is so designed
that there will always be one free; ch. 3.4.4.1) and initiates input by sending the buffer
address to the I/O-system:
init-read-bytes
(log-line-id, fileaddr, buffer; trfid, cc);
wait-chained (PISEM).
The coroutine is shown in fig. 3.3.4.4.3.1-1.0 and -1.1.…86…W …02… …02… …02… …02… …02…
FIG: 3.3.4.4.3.1-1.0
PACKET INPUT COROUTINE…86…W …02… …02… …02… …02… …02…
FIG: 3.3.4.4.3.1-1.1
PROCEDURE SETUPREAD…86…W …02… …02… …02… …02… …02…
3.3.4.4.3.2 T̲h̲e̲ ̲O̲u̲t̲p̲u̲t̲ ̲C̲o̲r̲o̲u̲t̲i̲n̲e̲
When a packet is ready for transmission (short operation signalled to semaphore POSEM) the
output is initiated:
init-append-bytes
(log-line-id, fileaddr,buffer;trfid,cc);
wait-chained (PCSEM);
When the transmission is finished the packet buffer is released and the next packet is awaited.
The coroutine is shown in fig. 3.3.4.4.3.2-1.0.…86…W …02… …02… …02… …02… …02…
FIG. 3.3.4.4.3.2-1.0
PACKET OUTPUT COROUTINE…86…W …02… …02… …02… …02… …02…
3.3.4.4.4 S̲i̲z̲e̲
The size of the code is 305 instructions.
The necessary data area occupies approximately 150 words.
3.3.4.4.5 T̲i̲m̲i̲n̲g̲
About 150 instructions are executed for processing a packet of an inbound message, corresponding
to a cpu-time of 0.3 ms.
For an outbound packet the corresponding numbers are 130 instructions and 0.3 ms.
3.3.5 T̲h̲e̲ ̲T̲r̲a̲n̲s̲p̲o̲r̲t̲ ̲S̲t̲a̲t̲i̲o̲n̲ ̲M̲o̲d̲u̲l̲e̲
3.3.5.1 G̲e̲n̲e̲r̲a̲l̲ ̲M̲e̲s̲s̲a̲g̲e̲ ̲H̲a̲n̲d̲l̲i̲n̲g̲
3.3.5.1.1 I̲n̲t̲r̲o̲d̲u̲c̲t̲i̲o̲n̲
The Transport Station Module and its surroundings are shown on fig. 3.3.5.1.1-1. Packets
received from the Packet Handler are assembled into entire messages, and the node-to-node
message control and the orbit control are performed.
Messages for the node itself are sent to the Control Module, messages for the MEDE or SIP
are sent to the MDS, and transit messages are put into the Transport Queue (Inbound Routing).
The messages are routed (Outbound Routing), and multi-address messages are copied if necessary.
Congestion control is performed by examining the Trunk Queue length. Finally outbound packets
are disassembled into packets.
The Transport Station is divided into TS-IN (one coroutine per trunk) for inbound message
transport, and TS-OUT (one coroutine common to all trunks) for outbound message transport.
3.3.5.1.2 P̲r̲o̲t̲o̲c̲o̲l̲
According to the message switching philosophy the transport of an e̲n̲t̲i̲r̲e̲ ̲m̲e̲s̲s̲a̲g̲e̲ ̲i̲s̲ ̲c̲o̲n̲t̲r̲o̲l̲l̲e̲d̲
̲f̲r̲o̲m̲ ̲n̲o̲d̲e̲-̲t̲o̲-̲n̲o̲d̲e̲. This control must be performed on a level above the packet level, i.e.
is in the Transport Station.…86…W …02… …02… …02… …02… …02…
FIG: 3.3.5.1.1-1:
THE TRANSPORT STATION…86…W …02… …02… …02… …02… …02…
The messages transmitted from one node to another are n̲u̲m̲b̲e̲r̲e̲d̲ ̲i̲n̲ ̲s̲e̲q̲u̲e̲n̲t̲i̲a̲l̲ ̲o̲r̲d̲e̲r̲ by the
sending node. The receiving node checks that the messages are r̲e̲c̲e̲i̲v̲e̲d̲ ̲s̲t̲r̲i̲c̲t̲l̲y̲ ̲i̲n̲ ̲t̲h̲a̲t̲
̲s̲e̲q̲u̲e̲n̲t̲i̲a̲l̲ ̲o̲r̲d̲e̲r̲.
Regarding multiple trunks and precedence levels it is seen that t̲h̲e̲ ̲s̲e̲r̲i̲a̲l̲ ̲n̲u̲m̲b̲e̲r̲i̲n̲g̲ ̲m̲u̲s̲t̲
̲b̲e̲ ̲p̲e̲r̲f̲o̲r̲m̲e̲d̲ ̲p̲e̲r̲ ̲t̲r̲u̲n̲k̲ ̲p̲e̲r̲ ̲p̲r̲e̲c̲e̲d̲e̲n̲c̲e̲ ̲l̲e̲v̲e̲l̲, only in this case the proper order is guaranteed
under not-erroneous circumstances.
Consequently it must be d̲e̲t̲e̲r̲m̲i̲n̲e̲d̲ ̲b̲y̲ ̲t̲h̲e̲ ̲T̲r̲a̲n̲s̲p̲o̲r̲t̲ ̲S̲t̲a̲t̲i̲o̲n̲ ̲w̲h̲i̲c̲h̲ ̲t̲r̲u̲n̲k̲ ̲s̲h̲o̲u̲l̲d̲ ̲b̲e̲ ̲u̲s̲e̲d̲ ̲b̲y̲
̲a̲ ̲m̲e̲s̲s̲a̲g̲e̲ to a neighbour node.
Immediately after transmission (#0) of a message the sending node starts a t̲i̲m̲e̲r̲. (In fact
this is not done by the Transport Station, but by the Packet Handler Module transmitting
the last packet).
For each message correctly recieved an A̲C̲K̲ with the serial no. is returned. Messages received
twice (duplet due to restart) are cancelled; however, they are acknowledged, see fig. 3.3.5.1.2-1.
If a message is incorrectly received (packets are missing, or even entire messages are missing;
the message number is said to be out-of-sequence), a N̲A̲C̲K̲ with the wanted serial no. is returned.
DUPLETS EXPECTED NO. OUT-OF-SEQ
256,..., 511 0 1,..., 255
257,..., 0 1 2,..., 256
258,..., 1 2 3,..., 257
259,..., 2 3 4,..., 258
260,..., 3 4 5,..., 259
261,..., 4 5 6,..., 260
262,..., 5 6 7,..., 261
263,..., 6 7 8,..., 262
264,..., 7 8 9,..., 263
511,..., 254 255 256,..., 510
0,..., 255 256 257,..., 511
1,..., 256 257 258,..., 0
251,..., 506 507 508,..., 250
252,..., 507 508 509,..., 251
253,..., 508 509 510,..., 252
254,..., 509 510 511,..., 253
255,..., 510 511 0,..., 254
FIG. 3.3.5.1.2-1:
EXPECTED AND ACTUAL NODE-TO-NODE SERIAL NOS:
MESSAGE DUPLETS AND MESSAGES OUT-OF-SEQUENCE…86…W …02… …02… …02… …02…
If the sender does not receive an ACK within a limited time (which means the receipt of a
N̲A̲C̲K̲ ̲o̲r̲ ̲t̲i̲m̲e̲r̲), the message is r̲e̲t̲r̲a̲n̲s̲m̲i̲t̲t̲e̲d̲ up to a maximum of 3 times (transmission # 1,2,3).
It is emphasized that message control is performed on each individual copy of a multiaddress
message.
A message retransmitted 3 times without being acknowledged is transferred to the local MEDE-supervisor
or rerouted dependent on its destination. A node failure (after time-outs) or a hard trunk
failure (after NACK…08…s) is reported to the Monitoring Module.
When a trunk or a node becomes available after a failure or a restart, the transmission may
be restarted after the trunk has been opened.
3.3.5.1.3 T̲y̲p̲e̲s̲ ̲o̲f̲ ̲M̲e̲s̲s̲a̲g̲e̲s̲
As seen from the NSS there exist the types of messages mentioned below:
- narrative messages
- control messages
The control messages consist of:
- ACK…08…s and NACK…08…s
- MICK…08…s and MACK…08…s
- messages interchanged between the NSS…08…, the SCC…08…s
and the MEDE…08…s.
The ACK…08…s and NACK…08…s have been described in the previous chapter 3.3.5.1.2.
The MICK…08…s and MACK…08…s are used for supervision of neighbour nodes; they are described in chapter
3.3.6.1.4.
Control messages for the NSS (network- and data user control) are described in ch. 3.3.7.1.2
(the Control Module: Message Format).
Control messages for the SCC…08…s and the MEDE…08…s (statistics, reports, confirmations) are described
in ch. 3.3.6.1.2 (the Monitoring Module: Message Format).
The general lay out of the messages are shown in fig. 3.3.5.1.3-1.
A message is represented in memory by an MTCB the lay-out of which is shown in fig. 3.3.5.1.3-2.
The MTCB-blocks are shown in fig. 3.3.5.1.3-3.…86…W …02… …02… …02… …02…
FIG: 3.3.5.1.3-1:
NARRATIVE-AND
CONTROL MSGS…86…W …02… …02… …02… …02…
FIG: 3.3.5.1.3-2:
MTCB…08…s…86…W …02… …02… …02… …02…
FIG: 3.3.5.1.3-3:
MTCB-BLOC…08…s…86…W …02… …02… …02… …02…
3.3.5.1.4 S̲e̲m̲a̲p̲h̲o̲r̲e̲s̲/̲Q̲u̲e̲u̲e̲s̲ ̲b̲e̲t̲w̲e̲e̲n̲ ̲S̲u̲b̲m̲o̲d̲u̲l̲e̲s̲
The only queue common to TS-IN and TS-OUT is the Transport Queue (fig. 3.3.5.1.4-1).…86…W
…02… …02… …02… …02…
FIG. 3.3.5.4.1-1:
SEMAPHORES AND QUEUES…86…W …02… …02… …02… …02…
3.3.5.1.5 U̲s̲e̲-̲C̲o̲u̲n̲t̲e̲r̲s̲ ̲a̲n̲d̲ ̲M̲e̲s̲s̲a̲g̲e̲ ̲P̲r̲o̲c̲e̲s̲s̲i̲n̲g̲
In this chapter is given examples of processing of messages in the Transport Station and
the current changes of the File Use Count and the MTCB Use Count.
…02… USE-COUNT
FILE MTCB
P̲r̲e̲p̲a̲r̲a̲t̲i̲o̲n̲ ̲o̲f̲ ̲a̲ ̲N̲e̲w̲ ̲M̲e̲s̲s̲a̲g̲e̲,̲ ̲o̲r̲
R̲e̲c̲e̲i̲p̲t̲ ̲o̲f̲ ̲a̲ ̲M̲e̲s̲s̲a̲g̲e̲ ̲f̲r̲o̲m̲ ̲a̲ ̲
N̲e̲i̲g̲h̲b̲o̲u̲r̲
0 0
CREATE MTCB 0 1
FILL MTCB
CREATE FILE 0 1
WRITE MSG. ON DISC
PUT MSG INTO TRP-Q 1 2
RELEASE FILE 1 0
RELEASE MTCB 2 1
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
MSG IN TRP-Q 0 1
C̲r̲e̲a̲t̲i̲o̲n̲ ̲a̲n̲d̲ ̲F̲o̲r̲w̲a̲r̲d̲i̲n̲g̲ ̲A̲C̲K̲/̲N̲A̲C̲K̲
0
CREATE PSEUDO MTCB 0 1
FILL MTCB
PUT ACK/NACK INTO TRP-Q 1 2
RELEASE PSEUDO MTCB 2 1
READ ACK/NACK IN TRP-Q
READ PSEUDO MTCB
PUT ACK/NACK INTO TRK-Q
DELETE ACK/NACK FROM TRP-Q 1 0
XMIT ACK/NACK 0…86…W …02… …02…
…02… …02…
F̲o̲r̲w̲a̲r̲d̲i̲n̲g̲ ̲a̲ ̲M̲e̲s̲s̲a̲g̲e̲ ̲t̲o̲ ̲a̲ ̲N̲e̲i̲g̲h̲b̲o̲u̲r̲
MSG IN TRP-Q 0 1
READ MSG IN TRP-Q
READ MTCB
PUT MSG INTO TRK-Q AND OMB (RES.MTCB) 1 2
DELETE MSG FROM TRP-Q 2 1
RESERVE MTCB 1 2
GET FILE 0 1
XMIT MSG
RELEASE FILE 1 0
RELEASE MTCB 2 1
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
MSG IN OMB 0 1
The MTCB USE-COUNT equals C if instead C copies are xmitted (via C trunks).
R̲e̲c̲e̲i̲p̲t̲ ̲o̲f̲ ̲A̲C̲K̲/̲N̲A̲C̲K̲ ̲f̲r̲o̲m̲ ̲a̲ ̲N̲e̲i̲g̲h̲b̲o̲u̲r̲
0
CREATE PSEUDO-MTCB 0 1
FILL PSEUDO-MTCB
PUT ACK/NACK INTO TRP-Q 1 2
RELEASE MTCB 2 1
READ ACK/NACK IN TRP-Q
READ MTCB
DELETE ACK/NACK IN TRP.Q 1 0
P̲r̲o̲c̲e̲s̲s̲i̲n̲g̲ ̲a̲n̲ ̲A̲C̲K̲ ̲r̲e̲c̲e̲i̲v̲e̲d̲ ̲f̲r̲o̲m̲ ̲a̲ ̲N̲e̲i̲g̲h̲b̲o̲u̲r̲
MSG IN "OMB" 0 C
READ MSG IN "OMB"
READ MTCB
RELEASE MTCB C C-1
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
MSG IN "OMB" 0 C-1
P̲r̲o̲c̲e̲s̲s̲i̲n̲g̲ ̲a̲ ̲N̲A̲C̲K̲ ̲o̲r̲ ̲T̲I̲M̲E̲R̲,̲ ̲w̲h̲e̲n̲
N̲o̲.̲ ̲o̲f̲ ̲R̲e̲t̲r̲a̲n̲s̲m̲i̲s̲s̲i̲o̲n̲ ̲M̲a̲x̲.
MSG IN "OMB" 0 C
READ MSG IN "OMB"
READ MTCB
PUT MSG INTO TRK-Q
RESERVE MTCB C C+1
GET FILE 0 1
XMIT MSG
RELEASE FILE 1 0
RELEASE MTCB C+1 C
MSG IN "OMB" 0 C
P̲r̲o̲c̲e̲s̲s̲i̲n̲g̲ ̲a̲ ̲N̲A̲C̲K̲ ̲o̲r̲ ̲T̲I̲M̲E̲R̲,̲ ̲w̲h̲e̲n̲
N̲o̲.̲ ̲o̲f̲ ̲R̲e̲t̲r̲a̲n̲s̲m̲i̲s̲s̲i̲o̲n̲ ̲=̲ ̲M̲a̲x̲.
MSG IN "OMB" 0 C
READ MSG IN "OMB"
READ MTCB
PUT MSG INTO TRP-Q,MDS-Q OR SIP-Q C C+1
RELEASE MTCB C+1 C
MSG IN QUEUES/"OMB" 0 C…86…W …02… …02… …02… …02…
3.3.5.1.6 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̲ the reset OMB is stored in the Checkpoint File.
At r̲e̲s̲t̲a̲r̲t̲ the Transport Queue is filled with the messages for which the NSS is responsible,
i.e. the messages checkpointed in the Checkpoint File.
A message pointer is c̲h̲e̲c̲k̲p̲o̲i̲n̲t̲e̲d̲ when put into
- the TRP Queue
- the CTR Queue
- the MDS Queue
- the SIP Queue
- the PGE Queue
- the Buffer of Outbound Msgs.
It is removed from the checkpointed area when removed from:
- the TRP Queue
- the CTR Queue
- the Buffer of Outbound Msgs.
(ACK received or max. No. of retransmissions performed)
3.3.5.2 I̲n̲b̲o̲u̲n̲d̲ ̲M̲e̲s̲s̲a̲g̲e̲ ̲T̲r̲a̲n̲s̲p̲o̲r̲t̲
3.3.5.2.1 F̲u̲n̲c̲t̲i̲o̲n̲s̲
T̲h̲e̲ ̲i̲n̲b̲o̲u̲n̲d̲ ̲s̲u̲b̲m̲o̲d̲u̲l̲e̲ of the Transport Station receives packets from the Packet Handler Module,
the packets themselves being stored in input buffers; pointers of the packets are stored
in the C̲y̲c̲l̲i̲c̲ ̲I̲n̲p̲u̲t̲ ̲B̲u̲f̲f̲e̲r̲ (per trunk per precedence).
According to the level of precedence the packets are assembled into messages, and written
on the disc in the IMF. The entire message including the binary header is stored.
These pieces of information extracted from the binary header) are written in an MTCB:
- Node-to-node serial no.
- Routing mask
- Main type
- Precedence
- Orbit counter
- Length of message
- Pointer of message
After a restart of the sending neighbour messages may be received twice; a message already
received is cancelled. The node-to-node message protocol is performed, i.e. for a message
(except for ACK/NACK) correctly received an ACK control message is returned to the sending
node, otherwise (e.g. missing packets) a NACK is returned.
Accepted messages are treated in this way (Inbound Routing):
- an orbiting ACK/NACK control message for this node is put into the Transport Queue
- an orbiting ACK/NACK control message for another node is deleted
- a non-orbiting ACK/NACK control message (for this or another node) is put into the Transport
Queue
- an orbiting control message (other than ACK/NACK) for this node is put into the CTR-Queue
- an orbiting control message (other than ACK/NACK) not for this node is put into the MDS-Queue
- a non-orbiting control message (other than ACK/NACK) for this node is put into the CTR-Queue
- a non-orbiting control message (other than ACK/NACK) for this MEDE or SIP is put into
the MDS or SIP Queue respectively
- a non-orbiting control message (other than ACK/NACK) for another N/M is put into the
Transport Queue
- an orbiting narrative message is put into the MDS-Queue
- a non-orbiting narrative message for this MEDE or SIP is put into the MDS-Queue
- a non-orbitintg narrative message for another MEDE is put into the Transport-Queue…86…W
…02… …02… …02… …02…
If the trunk is opened, closed or disconnected or if the neighbour has failed this is signalled
from the Monitoring Module. The IMF-area and the MTCB for each message (of any precedence
level) not fully received are released.
If one or more packets are missing this is signalled from the Packet Handler. The IMF-area
and the MTCB are released, and a NACK is returned.
3.3.5.2.2 O̲p̲e̲r̲a̲t̲i̲o̲n̲s̲
The format of the operations received are:
State: Packet Ready
Semaphore: TS (t)
Op( 5, 4): Packet Handler
- ( 7, 6): 0 , TO-PRDY
- ( 9, 8): First occ,Prec.level
- (11,10): 0,0
State: Trunk Opened, Closed or Disconnected
Semaphore: TS (t)
Op( 5, 4) : Monitoring Module
- ( 7, 6) : Neighbour, TO-RTF
- ( 9, 8) : 0 , Trunk ser #
- (11,10) : Entry#,0
State: Packets Missing
Semaphore: TS (t)
Op( 5, 4): Packet Handler
- ( 7, 6): Prec.level, TO-RPM
- ( 9, 8): 0 ,0
- (11,10): 0 ,0
State: Disc Output
Semaphore: TSID (t)
Op( 5, 4): Event Module
- ( 7, 6): 0 , TO-OUT
- ( 9, 8): CC
- (11,10): Ref (BLE)…86…W …02… …02… …02… …02…
3.3.5.2.3 P̲r̲o̲c̲e̲s̲s̲i̲n̲g̲
FIG. 3.3.5.2.3-1:
TS-IN
MAIN LOOP…01……86…W …02… …02… …02… …02…
FIG. 3.3.5.2.3-2:
TS-IN
INITIALIZATION…86…W …02… …02… …02… …02…
FIG. 3.3.5.2.3-3:
TS-IN
PROCESS PACKET…86…W …02… …02… …02… …02…
FIG. 3.3.5.2.3-4:
TS-IN
FINISH…86…W …02… …02… …02… …02…
FIG. 3.3.5.2.3-5:
TS-IN
PROC.FIRST-PACKET…86…W …02… …02… …02… …02…
FIG. 3.3.5.2.3-6:
TS-IN
PROCEDURE NACK-ACK…86…W …02… …02… …02… …02…
3.3.5.2.4 S̲i̲z̲e̲
The size of the code is 1218 instructions.
The necessary data area occupies 206 - 770 words depending on the number of trunks.
3.3.5.2.5 T̲i̲m̲i̲n̲g̲
About 1500 instructions are executed for processing the packets of an inbound message, corresponding
to a cpu-time of 3.3 ms.
The disc is accessed in the average 2.6 times (appendix 7.1) per message corresponding to
a cpu-time of 8.3 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.5.3 O̲u̲t̲b̲o̲u̲n̲d̲ ̲M̲e̲s̲s̲a̲g̲e̲ ̲T̲r̲a̲n̲s̲p̲o̲r̲t̲
3.3.5.3.1 F̲u̲n̲c̲t̲i̲o̲n̲s̲
A possible element in the Transport Queue is signalled from the Event Module.
The o̲u̲t̲b̲o̲u̲n̲d̲ ̲s̲u̲b̲m̲o̲d̲u̲l̲e̲ of the Transport Station empties the Transport Queue according to
precedence; within a precedence level delayed messages are given a higher priority than messages
in transit and messages in transit are given a higher priority than local generated messages
(generated by the NSS, the MEDE or a collocated SIP). For messages generated locally the
orbit counter is set to its initial value; the value is stored into the MTCB.
Each message is routed (Outbound Routing), i.e. from the routing table is found the best
neighbour node according to the destination of the message. The Monitoring Module informs
the Transport Station about trunk- and neighbour node status. If the node found is not available
or the Trunk Queue is overloaded (and a new routing table has not yet been received) the
secondary (tertiary) is found. Necessary copying and routing mask justification is performed
for multiaddress messages, see fig.3.3.5.3.1-1.
The receipt of an ACK-control message means that the pointer of the message unacknowledged
until now is released. A possible "special handling" message, which must be purged before
release, is put into the Purge Queue. NACK means retransmission up to a maximum of 3 times.
FIG. 3.3.5.3.1-1:
COPYING OF MULTIADDRESS
MSGS…86…W …02… …02… …02… …02…
The message is supplied with a serial number for the node-to-node message control. Then
it is disassembled into packets, and a queue element per packet is put into the T̲r̲u̲n̲k̲ ̲Q̲u̲e̲u̲e̲
according to the precedence level. The message pointer is put into the Buffer of Outbound
Messages.
Control messages for the present node are put into the Control Queue.
Information about normal and erroneous situations is given to the Monitoring Module:
- SCC-statistics: - Trunk Queue Length
- Trunk load (No. of chars.)
- SCC one-hour reports:- Trunk load
- SCC-reports: - Trunk Queue Threshold-alarm on/off
- Trunk failure
- Node failure
- MEDE-reports: - Hard trunk failure
- Node failure
The Trunk Queue Threshold-alarm on/off situations are determined in this way:
The Trunk Queue Length is the sum of the No. of queue elements (packets) in the 7 precedence
queues for a trunk.
When the length exceeds an upper limit an alarm is reported by the Trnsport Station via the
Monitoring Module. The first time the length decreases below a lower limit after an alarm,
the alarm is cancelled; this is done by the Packet Handler.
A Trunk Queue threshold alarm indicates a congestion situation in the neighbour node.
Congestion in a node may be recognized by the growth of the Transport Queue of the node,
and the growth of the Trunk Queue of its neighbour nodes beyond some limit.
If the trunk is disconnected, closed or opened, or if the neighbour has failed the messages
are rerouted, i.e. they are moved from the Outbound Message Buffer to the TRP-Q.
3.3.5.3.2 M̲e̲s̲s̲a̲g̲e̲ ̲R̲o̲u̲t̲i̲n̲g̲
The Outbound Routing of messages is described in this section.
The information about non-availability of nodes and trunks is sent by control messages from
the nodes to the SCC.
Each node receives a routing table from the SCC (as shown on fig. 3.3.5.3.2-1) each time
the topology or the long term delays have been changed. Congestion will not produce new
routing tables, but merely involve alternate routing in the neighbour nodes. The table contains
a primary, secondary and tertiary neighbor, because it must be possible to perform routing
also in the period of time from such changes occur until new tables are generated and ditributed.
It must be pointed out that in a period of time where the routing in the individual nodes
is based on different information about the network, oscillations and loopings of messages
may occur. The reasons may be:
- two nodes may disaggree about the availabbility of a trunk or a node.
- congestion in a neighbour node
- the information about topology and delay needs some time to spread out through the network,
i.e. the routing tables arrive at different times at different nodes.…86…W …02… …02…
…02… …02… …02… …02…
FIG. 3.3.5.3.2-1:
THE ROUTING TABLE
(NODE K)…86…W …02… …02… …02… …02… …02… …02…
The SCC routing algorithm ensures that when using the s̲a̲m̲e̲ knowledge of the network, then
the nodes agree about the optimum route.
The amount of oscillations and loopings of messages in the network will be controlled by
the "Orbit Counter" of each message. The counter is a part of the binary header. When entering
the network it is preset to 20; it is reduced by one, when passing a node; reaching 0 a narrative
message is transferred to the supervisor of the node/MEDE.
An orbiting ACK/NACK/MICK/MCK is deleted.
The SCC is informed about the orbiting narrative messages.
In this way some small amount of oscillations and loopings is tolerated.
Trunk - or node failures may separate the network into two or more minor networks, so messages
may be locked out from their destination. In this situation messages are routed to the local
MEDE supervisor.
A message retransmitted from a node to its neighbour node 3 times without success is transferred
to the supervisor of the NODE/MEDE.
Several copies of a message may be delivered to the MEDE. The reasons may vary, and the deliveries
may occur independantly of each other and at different moments.
The reasons may be:
o the MEDE is a destination of the message-copy.
o the message copy is oscillating or looping inside the network.
o the destination of the message copy is cut off the network.
In the last case a pseudo-MTCB is created and filled.
Whatever the reason is, the (real or pseudo) MTCB is put into the MDS-Q.
3.3.5.3.3. O̲p̲e̲r̲a̲t̲i̲o̲n̲s̲
The format of the operations received are:
State: Message in TRP-Q/CTR-Q
Semaphore: TSO
Op( 5, 4): Event Module
- ( 7, 6): 0 , TO-INT
- ( 9, 8): 0 , 0
- (11,10): 0 , 0
State: Time Elapsed
Semaphore: TSO
Op( 5, 4): Event Module
- ( 7, 6): 0 ,TO-TIM
- ( 9, 8): Timer Ident
- (11,10): 0 , 0
State: Trunk Opened, Closed or Disconnected
Stemaphore: TSO
Op( 5, 4): Monitoring Module
- ( 7, 6): Neighbour, TO-RTF
- ( 9, 8): 0 , TRUNK SER #
- (11,10): Entry#, 0
State: Disc Output
Semaphore: TSOD
Op( 5, 4): Event Module
- ( 7, 6): 0 ,TO-OUT
- ( 9, 8): CC
- (11,10): Ref (BLE)…86…W …02… …02… …02… …02… …02… …02…
3.3.5.3.4 P̲r̲o̲c̲e̲s̲s̲i̲n̲g̲
FIG. 3.3.5.3.4-1:
TS-OUT
MAIN-LOOP…86…W …02… …02… …02… …02… …02… …02…
FIG. 3.3.5.3.4-2:
TS-OUT
INITIALIZATION…86…W …02… …02… …02… …02… …02… …02…
FIG. 3.3.5.3.4-3:
TS-OUT
PROC. PROCESS-MESSAGE…86…W …02… …02… …02… …02… …02… …02…
FIG. 3.3.5.3.4-4
TS-OUT
PROC. NACKTIM…86…W …02… …02… …02… …02… …02… …02…
FIG. 3.3.5.3.4-5:
PROCEDURE RE-XMIT…86…W …02… …02… …02… …02… …02… …02…
FIG. 3.3.5.3.4-6:
PROF. ROUTING
TS-OUT…86…W …02… …02… …02… …02… …02… …02…
FIG. 3.3.5.3.4-7
TS-OUT
SWITCHING…86…W …02… …02… …02… …02… …02… …02…
FIG. 3.3.5.3.4-8
PROC. FASTEST-TRUNK…86…W …02… …02… …02… …02… …02… …02…
3.3.5.3.5 S̲i̲z̲e̲
The size of the code is 1667 instructions.
The necessary data are occupies 185-197 words.
3.3.5.3.6 T̲i̲m̲i̲n̲g̲
About 2500 instructions are executed for processing one message, which corresponds to a cpu-time
of 5.5 ms.
The MTCB-monitor is called twice (three times for a message copy) of 0.2 ms.
QACCESS is called twice for outbound messages, except for message copies. For messages for
the SIP, QACCESS is called 3 times of 0.2 ms each.
3.3.6 T̲h̲e̲ ̲M̲o̲n̲i̲t̲o̲r̲i̲n̲g̲ ̲M̲o̲d̲u̲l̲e̲
3.3.6.1 I̲n̲t̲r̲o̲d̲u̲c̲t̲i̲o̲n̲
The Monitoring Module monitors the normal as well as the erroneous states of the node and
the network local to the node.
Reports are sent to the supervisors of the MEDE and the SCC. The latter also receives statistics
and hourly reports.
The Monitoring Module is the supervisor of the LTUX'; therefore also some LTUX control is
performed by the Module.
Errors, confirmations and control is signalled to the Monitoring Module via the MON-Semaphore,
see fig. 3.3.6.1-1.
Messages generated are put into the TRP-Q. Each message for the SCC is forwarded to P as
well as to Q; in this way a copy is also made for a standby SCC.
The interface to the LTUX…08… is shown in fig. 3.3.6.1-2. Longlines for LTUX configuration,
monitoring and control are created via the I/O-System, the TDX-driver, and the HOST I/F.…86…W
…02… …02… …02… …02… …02… …02…
FIG. 3.3.6.1-1:
THE MONITORING MODULE…86…W …02… …02… …02… …02… …02… …02…
FIG. 3.3.6.1-2:
LOGLINES…86…W …02… …02… …02… …02… …02… …02…
3.3.6.2 M̲e̲s̲s̲a̲g̲e̲s̲ ̲G̲e̲n̲e̲r̲a̲t̲e̲d̲
The Monitoring Module generates messages for the SCC…08…s, for the local MEDE, and for the neighbour
NSS…08…. A detailed description if given in ref.(4).
The messages for the S̲C̲C̲…88…s̲ are:
- Statistics, which is sent each hour.
- Hourly Report, which is sent each hour.
- Local Network Status Report, which is sent each time its contents is changed, and
on request.
see fig. 3.3.6.2-1 and -2.
The messages for the l̲o̲c̲a̲l̲ ̲M̲E̲D̲E̲ are:
- hard and soft trunk failure
- neighbour node failure
- trunk opened/closed
- NPDN call-up/close-down
The messages for the n̲e̲i̲g̲h̲b̲o̲u̲r̲ NSS…08… are:
- MICK…08…s and MACK…08…s
FIG. 3.3.6.2-1:
REPORTS FOR THE SCC…08…s…86…W …02… …02… …02… …02… …02… …02…
FIG. 3.3.6.2-1:
REPORTS FOR THE SCC…08…s…86…W …02… …02… …02… …02… …02… …02…
Note that for hard trunk errors the trunk is not used by the NSS, and new Routing Tables
supposing the trunk to be disconnected are distributed. When the error is repaired, the
failure is reported off.
For a soft error the trunk will still be used, because the error is supposed to be transient.
Therefore the error will not be reported off.
3.3.6.3 L̲T̲U̲X̲ ̲S̲u̲p̲e̲r̲v̲i̲s̲i̲o̲n̲
The LTUX Supervision covers:
- commands to
- command-responses from
- status requests to
- status-reports from
the LTUX'.
The LTUX…08…s are of the belowmentioned types:
- TRANS
- TRUNK
- NPDN
- DATA USER
- CRYPTO
Supervisory information is transferred between the Monitoring Module and the LTUX in question
via a logline connecting subdevice #2 as shown in fig. 3.3.6.1-2.
3.3.6.3.1 C̲o̲m̲m̲a̲n̲d̲s̲
Command ::=
Command code ;byte #0
Command Data 1 ; - #1
Command Data 2 ; - #2
Command Data 3 ; - #3
Command Data 4 ; - #4
L̲T̲U̲X̲ C̲O̲M̲M̲A̲N̲D̲ -̲ ̲C̲O̲D̲E̲ -̲D̲A̲T̲A̲1̲ -̲D̲A̲T̲A̲2̲ -̲D̲A̲T̲A̲3̲ -̲D̲A̲T̲A̲4̲
TRANS empty
TRUNK Open Trunk TLCOT ::=#87 irrel irrel
- Close Trunk TLCCT ::=#89 irrel irrel
NPDN Call-up TLCCU ::=#84 MSD LSD calling node trunk ser#
- Close-down TLCCD ::=#86 MSD LSD
- Open Trunk TLCOT ::=#87 irrel irrel
- Close Trunk TLCCT ::=#89 irrel irrel
DATA USER Prim. Route TLCPR ::=#8B jack# irrel
CRYPTO empty
jack # :: =1/2/3/4
calling node ::= letter
trunk ser # ::= digit
3.3.6.3.2 C̲o̲m̲m̲a̲n̲d̲ ̲R̲e̲s̲p̲o̲n̲e̲s̲
Command Response ::=
response code ; byte #0
completion code ; - #1
irrel. ; - #2
irrel. ; - #3
…02…L̲T̲U̲X̲ C̲O̲M̲M̲A̲N̲D̲ R̲E̲S̲P̲O̲N̲S̲E̲ ̲C̲O̲D̲E̲ C̲O̲M̲P̲L̲E̲T̲I̲O̲N̲ ̲C̲O̲D̲E̲
TRANS empty
TRUNK Open Trunk #20 0:OK; 1:not OK
- Close Trunk #20 0
NPDN Call-up #20 0:OK; 1:not OK
- Close-down #20 0
- Open Trunk #20 0:OK ;1:not OK
- Close trunk #20 0
DATA USER Primary Route #20 0
CRYPTO empty
3.3.6.3.3 S̲t̲a̲t̲u̲s̲ ̲R̲e̲q̲u̲e̲s̲t̲s̲
Status Request ::=
command code ; byte #0
command data 1 ; - #1
command data 2 ; - #2
command data 3 ; - #3
command data 4 ; - #4
L̲T̲U̲X̲ C̲O̲M̲M̲A̲N̲D̲ -̲ ̲C̲O̲D̲E̲ - D̲A̲T̲A̲1̲ -̲D̲A̲T̲A̲2̲ -̲D̲A̲T̲A̲3̲ -̲D̲A̲T̲A̲4̲
TRANS empty
TRUNK Status Req. TLCSR
NPDN - - TLCSR
DATA USER - - TLCSR jack #
CRYPTO,RED - - TLCSR garbling rep
- , - - - TLCSR transm.rep fm node to node trk-ser#
CRYPTO,BLK empty
TLCSR ::= #8E
garbling report ::= #05
transmission report ::= #06
3.3.6.3.4 S̲t̲a̲t̲u̲s̲ ̲R̲e̲p̲o̲r̲t̲s̲
3.3.6.3.4.1 T̲r̲a̲n̲s̲
status report ::= empty
3.3.6.3.4.2 T̲r̲u̲n̲k̲
status report ::=
status code ; byte# 0
trunk failure status ; - # 1
trunk status ; - # 2
irrelevant ; - # 3
- ; - # 4
- ; - # 5
trunk status changed ; - # 6
trunk failure changed ; - # 7
irrelevant ; - # 8
- ; - # 9
- ; - #10
- ; - #11
- ; - #12
0 ; - #13
0 ; - #14
0 ; - #15
status code ::= #05
trunk failure status . bit 0 ::= hard failure on
trunk status ::=
1 ; disconnected
2 ; closed
3 ; open
trunk failure changed . bit 0 ::= transient failure
trunk failure changed . bit 1 ::= hard failure change
trunk status changed ::= boolean
transient failure ::= boolean
hard failure on ::= boolean
hard failure change ::= boolean
3.3.6.3.4.3 N̲P̲D̲N̲
status report ::=
status code ; byte # 0
trunk failure status ; - # 1
trunk status ; - # 2
irrelevant ; - # 3
- ; - # 4
- ; - # 5
trunk status change ; - # 6
trunk failure change ; - # 7
irrelevant ; - # 8
- ; - # 9
- ; - #10
- ; - #11
- ; - #12
NPDN call from neighbour ; - #13
calling neighbour ; - #14
trk serial# ; - #15
status code ::=#05
trunk failure status . bit 0 ::= hard failure on
trunk status ::=
1 ; disconnected (NPDN closed down)
2 ; closed (NPDN called up)
3 ; open ( - - -)
trunk failure change. bit 0 ::= transient failure
- - - . bit 1 ::= hard failure change
trunk status changed ::= boolean
transient failure ::= boolean
hard failure on ::= boolean
hard failure change ::= boolean
NPDN call from neighbour ::= boolean
calling node ::= letter
trunk serial # ::= digit
