top - download
⟦092f149a9⟧ Wang Wps File
Length: 56820 (0xddf4)
Types: Wang Wps File
Notes: FIX/1160/PSP/0091
Names: »3150A «
Derivation
└─⟦0f96917ac⟧ Bits:30006134 8" Wang WCS floppy, CR 0287A
└─ ⟦this⟧ »3150A «
WangText
F…07…E…0a…E…0d…E…0f…E…02…E
E…07…D…0b…D…0e…D…01…D…02…D…06…C…09…C…0d…C…01…C…05…B…08…B…0c…B…00…B B…07…A…0a…A…0d…A…01…A…02…A…06…@…0b…@…0c…@…02……86…1
…02…
…02…
…02…
…02…FIX/1160/PSP/0091
…02…APE/890606…02……02…184
INTER
SCC
HANDSHAKING
PROCESSES
PSP
…02…REV/850301…02…FK
7809
CWD to SWD State Message
---------------------------------------
O S ST AT A TAS
C U X
W O X
D OT X
S X
ST X
S TAS X
T AT X
A X
T TAS X
E AR X
RT X
-----------------------------------------------
…01…Table 3.3.2.3.2.2.2-6, CWDSM Encoding
B. P̲r̲o̲g̲r̲a̲m̲ ̲C̲W̲D̲C̲&̲S̲P̲:̲
BEGIN
IF (EVENT = SWD…0f…C…0e… ̲State ̲Report)
THEN
'Reset SIP…0f…C…0e…KAM Absence timer'
CALL "CWDTIM" (Reset ̲SKATIM)
RETRIEVE N/T R, (SCC…0f…R…0e… ̲Status)
IF (N/T…0f…R…0e…, SCC…0f…R ̲…0e…Status Changed)
THEN
"CREATE" (PMTCB, N/T…0f…R…0e… ̲Status)
"Enqueue" (PMTCB, CM ̲Queue)
END IF
RETRIEVE (SWD…0f…C ̲State ̲Message)
'Calculate New State'
STATE: = CSSET ̲STATE 8CWDSP; SWDSM)
'Get Action'
ACTION:= SSET ̲Action (CWDSP, SWDSM)
'Get Message Text'
TEXT:CSSET ̲TEXT (CWDSP; SWDSM)
ELSE (EVENT = COMMAND/OPCMD or Timeout/TO)
'Calculate ̲New-State'
STATE:= COSET STATE (CMDSP, EVENT)
'Get ̲Action'
ACTION:= COSET ̲ACTION (CMDSP, EVENT)
'Get Message Text'
TEXT:= COSET ̲TEXT (CMDSP, EVENT)
END IF
CIP ̲Operational ̲Mode:= State ̲Group (CWDSP)
"GENERATE" (CWD to SWD…0f…C…0e… State Report)
"RESERVE ̲CRITICAL ̲REGION"(SIP…0f…C…0e… ̲Mailbox)
MAIL (CWD to SWD…0f…C…0e… State Report)
"RELEASE ̲CRITICAL ̲REGION" (SIP…0f…C…0e… ̲Mailbox
'Execute Action'
CALL "ACTION"
'Prompt Supervisor'
"CREATE" (PMTCB, TEXT)
"ENQUEUE" (PMTCB, CM ̲Queue)
END
B1. S̲t̲a̲t̲e̲ ̲E̲v̲e̲n̲t̲ ̲T̲a̲b̲l̲e̲s̲
B1.1 I̲n̲t̲r̲o̲d̲u̲c̲t̲i̲o̲n̲
The COSET and CSSET State ̲Event ̲Tables, defined in Table 3.3.2.3.2.2.2-7A and Table
3.3.2.3.2.2.2-8A, are docoded as follows:
Entry. Message
No. No.
(*)
New ̲ Action
State No.
o "Entry No." is referenced in the State ̲Event ̲Comment tables, appended to each State
̲Event ̲Table.
o "New State" is the menomonic for the CWD ̲State ̲Value, and the CWD ̲State ̲Parameter
is updated accordingly. If the content is (-) no CWD state change is required.
o "Message No." is a reference to the Message Text printed on the event-log printer
and defined in B1.2.
o "Action No." is a reference to an action procedure defined in B1.2 and executed each
time the enty applies. If (-) then no action is required.
o A star (*) in the centerfield indicates that a CIP ̲Operational ̲Mode change takes
place.
B1.2 Action Procedure/Message Texts
A1. BEGIN
"Send NSC-report including SCC…0f…C…0e…- & SCC…0f…R…0e…-states
and possible supsrvisor-message"
END
A2. BEGIN
"Change CWDSP"
"Send CIP/SIP Keep Alive Message"
END
A3. BEGIN
"Change CWDSP"
"Send CIP/SIP Keep Alive Message"
"Send NCS-report"
END
A4. BEGIN
"Change CWDSP"
"Send NSC-report"
"Send AMOS message to CPM with CIP Operational
Mode Update"
"Stop Timers"
"Send CIP/SIP Keep Alive Message"
END
A5. BEGIN
"Change CWDSP"
"Send CIP/SIP Keep Alive Message"
"Send NCS-report"
Send AMOS message to CPM with CIP Operational
Mode Update"
END
A6. BEGIN
"Change CWDSP"
Send CIP/SIP Keep Alive Message"
Send NSC-report"
Send AMOS Message to CPM with CIP Operational
Mode Update"
"Start Timers"
END
A7. BEGIN
"Send NSC-report"
"Start response-timer"
END
A8. BEGIN
"Change CWDSP"
"Send NSC-report
END
A9. BEGIN
"Change CWDSP"
"Send NSC-report"
Start responce-timer"
END
A 10. BEGIN
"Change CWDSP"
"Send NSC-report"
"Start response-timer"
"Send CIP/SIP Keep Alive Message"
END
M̲e̲s̲s̲a̲g̲e̲s̲ ̲t̲o̲ ̲S̲u̲p̲e̲r̲v̲i̲s̲o̲r̲ ̲o̲n̲ ̲E̲v̲e̲n̲t̲-̲l̲o̲g̲ ̲p̲r̲i̲n̲t̲e̲r̲
M1: "OFF ̲LINE"
M2: "BUSY"
M3: "INVALID COMMAND"
M4: "STAND-BY"
M5: "ACTIVE"
M6: "REQUEST CANCELLED"
M7: "COMMAND REJECTED"
M8: "GO ̲ACTIVE"
M9: RESPONSE ̲TIMEOUT"
M10: "REJECTED ̲BY ̲REMOTE ̲SUPERVISOR"
B1.3 C̲W̲D̲S̲P̲/̲O̲P̲C̲M̲D̲ ̲S̲t̲a̲t̲e̲/̲E̲v̲e̲n̲t̲ ̲T̲a̲b̲l̲e̲ ̲(̲C̲O̲S̲E̲T̲)̲
The COSET Stae ̲Event ̲Table is a two dimentional array, where each element holds a
State and optional a Action ̲and/or Message Designator.
State is retrieved by a call:
STATE:= COSET ̲STATE (STATE, EVENT)
Action is retrieved by a call:
ACTION:= COSET ̲ACTION (STATE, EVENT)
Message Text is retrieved as:
TEXT.= COSET ̲TEXT (STATE, EVENT)
COSET is defined in Table 3.3.2.3.2.2.2-7A and descibed in COSET ̲Narrative ̲Table,
Table 3.3.2.3.2.2.2-7B
Table 3.3.2.3.2.2.2-7A, CWDSP/OPCMD State Event Table
Entry Comments
No.
--------------------------------------------------------
1 SCC is already off-line. Command OK.
2 Transition to off-line already in progress. the second "GO" command has been issued
before completion of the first "GO and is ignored.
3-5 Initiate transition to off-line
6 SCC is in atransition state from stand-by to active.
Since the "GO" command is not valid in the active mode, the command can't be validated
or executed until the transition is completed (SCC Busy)
7-10 Invalid command in active state. The command is rejected.
11 Transition to stand-by performed.
12-14 SCC already stand-by. Command OK.
15 A request to go active is rejected by the supervisor. Command OK.
Entry Comments
No.
--------------------------------------------------------
16 SCC has accepted a request to go active, and the transition may be in progress. The
"GA"command has not yet been completed, why the "GS" command is rejected (SCC Busy).
17 The SCC Supervisor forwards a request to the remote SCC Supervisor to go active.
Command OK.
18 The switchover request is already in progress,but not yet completed. Command OK.
19 The SCC Supervisor rejects that he cancelled a switchover request in progress. Repeat
the request to go active to the remote SCC Supervisor.
Table 3.3.2.3.2.2.2-7B, COSET Narratives
Entry Comments
No.
--------------------------------------------------------
20 Same as 18, besides a response timeout has just occured. Issue the request once more.
21-24 The stand-by SCC may only go active if so requested by the active SCC Supervisor.
Invalid command.
25 The Supervisor accepts to go active.
26 The Supervisor repeats the accept to go active. CWD…0f…C…0e… goes on announcing it.
27 SCC is already active. Command OK.
28-30 The Supervisor prefers to cancel the request to the remote SCC to go active.
31 Timeout ignored, since no command in progress.
32 Off-line Acknowledgement from SWD…0f…C…0e… has timed out. SCC Supervisor has authority to
go off-line anyhow.
33-37 Please, ref. to 31.
38 Remote SCC Supervisor response timeout, to go active request. CWD…0f…C…0e… asks for SWD…0f…C…0e…
authorization to go active.
39-40 Please, ref. to 31
Table 3.3.2.3.2.2.2-7B (cont.'d)…86…W …02… …02… …02… …02… …02… …02… …02…
B1.4 C̲W̲D̲S̲P̲/̲S̲W̲D̲S̲M̲ ̲S̲t̲a̲t̲e̲/̲E̲v̲e̲n̲t̲ ̲T̲a̲b̲l̲e̲ ̲ ̲(̲C̲S̲S̲E̲T̲)̲
The CSSET State ̲Event ̲Table is a two dimentional array, where its entry holds a State-
and/or a Message Designator.
State is retrieved by as:
STATE:= CSSET ̲STATE (STATE, EVENT)
Action is retrieved by a call:
ACTION:= CSSET ̲ACTION (STATE, EVENT)
Message is retrieved as:
TEXT.= CSSET ̲TEXT (STATE, EVENT)
The CSSET is defined in Table 3.3.2.3.2.2.2-8A and appended a CSSET ̲Narrative ̲Table,
Table 3.3.2.3.2.2.2-8B
Table 3.3.2.3.2.2.2-8A, CSSET State/Event Table
Entry Comments
No.
--------------------------------------------------------
1-6 CWD ignores SWD…0f…C…0e… ̲State ̲Messages while off-line
7 SIP…0f…C…0e… failures. Don't await off-line acknowledgement but go directly off-line
8 Off-line transition acknowledged. Go off-line.
9-10 SWD…0f…C…0e… hs not yet encountered the "notice" of CWD going off-line
11-12 A failure has occured, CWD…0f…C…0e… is restarted, and operation prefers to go off-line. That
has not yet been observed by SWD…0f…C…0e….
13 CIP isolated. Must wait alive signals from SWD…0f…C…0e….
14 SWD…0f…C…0e… not yet observed that SCC has returned to stand-by.
15 "Stationary" State stand-by. No command, responses or requests are inprogress.
16 SWD…0f…C…0e… or remote SCC Supervisor requests Supervisor to go active. Forward the message.
17-18 CIP…0f…C…0e… Failure has occured, which has not yet been observed by SWD…0f…C…0e….
19 SWD…0f…C…0e… failures. Enter passiv state.
20 Invalid state. The CWD has entered transition from stand-by to active, on his own
account; go offline.
21 Supervisor's rejection to go active has been observed. Stop announcing it.
22 SWD…0f…C…0e… has not yet observed that Supervisor rejects to go active. Go on announcing
it.
Table 3.3.2.3.2.2.2-8B, CSSET Narratives
Entry Comments
No.
--------------------------------------------------------
23-24 Invalid state. CWD…0f…C…0e… has failed and has entered transition from stand-by to active
on its own account. Go standby. and wait for SWD…0f…C…0e… to synchronize.
25 Request to go active is obsolete because of SWD…0f…C…0e… failure.
Notify Supervisor and return to passive state.
26 Refer to except 26 also cancels request.
27 Request to go active is cancelled (response timeout).
Notify Supervisor.
28 Request to go active still in progress.
29-30 Please, refer to 23-24. Except 29-30 also cancels request.
31 Please, refer to 19.
32 Please, refer to 20.
33 Supervisor accepted to go active, but too late.
Notify him.
34 SWD…0f…C…0e… has not yet observed that CWD…0f…C…0e… is ready to go active.
35 SWD…0f…C…0e… has observed and approved that CWD…0f…C…0e… goes active.
36 Invalid state SWD…0f…R…0e… has reported ACC…0f…R…0e… unable to go active without being requested.
Go active.
37 Please, refer to 19.
38 Invalid state. CWD…0f…C…0e… has ent3red active without SWD…0f…C…0e… approval. Go offline.
39 SWD…0f…C…0e… "commands" the CWD…0f…C…0e… to go stand-by either caused by a SWD…0f…C…0e… failure or "System
Control Center" integrity violation, observed by the SCC Watch Dog.
Table 3.3.2.3.2.2.2-8B (cont.'d)
Entry Comments
No.
--------------------------------------------------------
40 SWD…0f…C…0e… failure has occured. SWD…0f…C…0e… commands the CWD…0f…C…0e… to initiate restart.
41 "Stationary" active state. No command, requests or responses are in progress.
42 CWD…0f…C…0e… has observed that switchover was declined.
43 Please, refer to 19.
44 Please, refer to 20
45 Request to go stand-by is grated.
46 Transition to stand-by granted, but remote supervisor or SCC Watch dog immediately
after that request the Supervisor to go active again.
(That must be forwarded to supervisor in state 16).
47 SWD…0f…C…0e… not yet answered the request to go stand-by.
48 The transition to stand-by is declined, return to active.
49 Supervisor tries to return to active, after issuing a request to go stand-by. That
is made impossible by SWD…0f…C…0e… failure.
50 Invalid state, refer to 20.
51 Permission to return to active is not granted.
52 SWD…0f…C…0e… failure has occured. SWD…0f…C…0e… "commands" CWD…0f…C…0e… to init restart.
53 Permission to return to active granted.
54 The local Supervisor cancels the request to go stand-by at the same time as the request
is rejected by SWD…0f…C…0e…/Remote Supervisor.
Table 3.3.2.3.2.2.2-8B (cont.'d)
Entry Comments
No.
--------------------------------------------------------
55 Please, refer to 19.
56 Invalid state. The CWD…0f…C…0e… has entered active state without SWD…0f…C…0e… authorization. Go offline.
57 Request to go stand-by granted simultanuously with response timeout.
58 As 57, but remote Supervisor/SWD…0f…C…0e… requests the Supervisor to go active again (via
state 16)
59-60 Response timeout occured.
Table 3.3.2.3.2.2.2-8B (cont.'d)
3.3.2.3.2.2.2
P̲r̲o̲c̲e̲d̲u̲r̲e̲ ̲C̲W̲D̲-̲T̲i̲m̲e̲r̲ ̲ ̲(̲C̲W̲D̲T̲I̲M̲)̲
A. N̲a̲r̲r̲a̲t̲i̲v̲e̲.̲
The CWD ̲Timer constitutes four separate timers, identified as:
1) SIP…0f…C…0e…KAM Absence Timer (SKATIM)
2) CIP/SIP…0f…C…0e…KAM Release Timer (CSKRTIM)
3) Response Timeout Timer (SUP)
4) NSC-report Release Timer (REPTIM)
SWDTIM is invoked by CWDED when a Timer ̲Interrupt is encountered by the CWD Process,
and is used to drive the above mentioned timers.
CWDTIM maintains these timers, as commanded by the procedures CWDC&SP and SCSKAM, and
when a timer expires a predefined action is performed. The purpose and maintenance of
these timers are as follows:
A1. S̲K̲A̲T̲I̲M̲ ̲T̲i̲m̲e̲r̲
The purpose of SKATIM is to detect when a SIP…0f…C…0e… ̲Keep ̲Alive ̲Message has failed to appear
within a predefined time interval (SKATIM preset value 20SKATIMO) which is interpreted
as a failure of SIP…0f…C…0e….
If the SKATIM expires a 'Pseudo' SIP…0f…C…0e… ̲Status ̲Report is generated with SWD…0f…C…0e… Status
"Undefined" and forwarded to procecdure CWDC&SP.
SKATIM is commanded preset by CWDC&SP each time a SWD…0f…C…0e… Status Report is received.
A2. C̲S̲K̲R̲T̲I̲M̲ ̲T̲i̲m̲e̲r̲
The CSKRTIM serves to trigger the release of CIP/SIP…0f…C…0e… ̲Keep ̲Alive ̲Messages with regular
intervals. SCKRTIM preset value CSKRTIMO.
When SCKRTIM expires a call is made to procedure SCSKAM to provide for the transmission
of the Keep ̲alive ̲Message.
SCKRTIM is in return preset by SCSKAM each time a Keep ̲Alive ̲Message has been released.
A3. S̲U̲P̲T̲I̲M̲ ̲T̲i̲m̲e̲r̲
The SUPTIM Timer is started by CWDC&SP each time the Supervisor has issued a request
to the "System Control Center" and defines response timeout elapse time (SUPTIMO).
When RESPTIM expires, CWDC&SP is called and if no response has been received until
then, a response timeout has occured.
A4. R̲E̲P̲T̲I̲M̲ ̲T̲i̲m̲e̲r̲
The REPTIM Timer is used to trigger the release of NSC-report with regular intervals.
REPTIM preset value TIMRQL.
When REPTIM expires a call is made to procedure XNSCREP to provide for the transmission
of the NSC-report.
REPTIM is in return preset by XNSCREP each time an NSC-report has been sent.
B. P̲r̲o̲g̲r̲a̲m̲ ̲C̲W̲D̲T̲I̲M̲:̲
BEGIN
CASE ̲OF̲EVENT/COMMAND (1,2,3,4,5,6,7,8,9)
1. 'EVENT = Timer ̲Interrupt'
'Run Timers'
SKATIM:= SKATIM-1
SUPTIM:= SUPTIM-1
CSKRTIM:= CSKRTIM-1
REPTIM:= REPTIM-1
IF (SKATIM = 0 'SKATIM expired')
THEN
CREATE and Send Pseudo Status report
SWD…0f…C…0e… ̲Status:= Undefined
N/T…0f…R…0e… ̲Status:= Undefined
SCC…0f…R…0e…-Status:= Undefined
CALL "CWDC&SP" (SWD…0f…C…0e… ̲Status ̲Report)
END IF
IF (SUPTIM= 0, 'Response Timeout')
THEN
CALL "CWDC&SP" (Timeout)
END IF
IF (REPTIM =0,'REPTIM expired')
THEN
CALL "XNSCREP" (release NSC-report)
END IF
2. 'COMMAND = Preset SKATIM'
SKATIM:= SKATIM0
3. 'COMMAND = Preset SUPTIM'
SUPTIM:=SUPTIM0
4. 'COMMAND:= Preset CSKRTIM'
CSKRTIM:= CSKRTIM0
5. 'COMMAND = Preset REPTIM'
REPTIM:= TIMRQL
6. 'COMMAND = Stop SJATIM'
SKATIM:= 0
7. 'COMMAND = Stop SUPTIM'
SUPTIM:= 0
8: 'COMMAND = Stop CSKRTIM'
CSKRTIM:= 0
9: 'COMMAND = stop REPTIM'
REPTIM:= 0
END CASE
END
3.3.2.3.2.2.4
P̲r̲o̲c̲e̲d̲u̲r̲e̲ ̲S̲e̲n̲d̲ ̲C̲I̲P̲/̲S̲I̲P̲…8f…C̲…8e…-̲K̲e̲e̲p̲-̲A̲l̲i̲v̲e̲-̲M̲e̲s̲s̲a̲g̲e̲ ̲(̲S̲C̲S̲K̲A̲M̲)̲
A. N̲a̲r̲r̲a̲t̲i̲v̲e̲:̲
Procedure SCSKAM is invoked by the CWD ̲timer, when
the KAM release time expires, and a Keep ̲Alive
̲Message has to be transmitted.
The data mailed in the SIP…0f…C…0e… ̲Mailbox by CWDED, CWDC&SP
and the CPM submodule are retrieved and piggybacked
in the Keep ̲Alive ̲Message transmitted.
B. P̲r̲o̲g̲r̲a̲m̲:̲
BEGIN
"RESERVE ̲CRITICAL ̲REGION" (SIP…0f…C…0e… ̲Mailbox)
Retrieve Mail (data)
"RELEASE ̲CRITICAL ̲REGION" (SIP…0f…C…0e… ̲Mailbox)
"WRITE" (SIP…0f…C…0e… ̲Keep ̲Alive ̲Message)
"Add SCVL-records/data to tail of message, ref.7
"ENQUEUE" (SIP…0f…C…0e…KAM, TQ)
CALL "CWDTIM" (Preset CSKRTIM)
END
3.3.2.3.2.2.5
P̲r̲o̲c̲e̲d̲u̲r̲e̲ ̲T̲r̲a̲n̲s̲m̲i̲t̲ ̲N̲S̲C̲ ̲r̲e̲p̲o̲r̲t̲ ̲(̲X̲N̲S̲C̲R̲E̲P̲)̲
A. N̲a̲r̲r̲a̲t̲i̲v̲e̲:̲
Procedure XNSCREP is invoked when:
o REPTIM expires and CWDTIM signals this to XNSCREP
o CWDC&SP encounters an Action-procedure including a transmission of NSC-report.
B. P̲r̲o̲g̲r̲a̲m̲:̲
BEGIN
"RESERVE CRITICAL REGION"(SIP…0f…C…0e… Mailbox)
Retrive Mail (Data)
"RELEASE CRITICAL REGION" (SIP…0f…C…0e…Mailbox)
"WRITE" (Pseudo MTCB, NSC-report)
"ENQUEUE" (Pseudo MTCB, CM-queue)
CALL "CWDTIM" (Preset REPTIM)
END
3.3.3 N̲a̲r̲r̲a̲t̲i̲v̲e̲-̲M̲e̲s̲s̲a̲g̲e̲-̲P̲r̲o̲t̲o̲c̲o̲l̲-̲M̲a̲c̲h̲i̲n̲e̲ ̲ ̲(̲N̲M̲P̲M̲)̲
3.3.3.1 I̲n̲t̲r̲o̲d̲u̲c̲t̲i̲o̲n̲
The ISH Narrative ̲Message ̲Protocol ̲Machine consists of four programs/processes at the two
SCC's and the collocated N/M's, CIP ̲Protocol ̲Machines & SIP ̲Protocol ̲Machines.
By handshaking, these protocol machines provide the end to end control required by FIKS,
for messages sent to the SCC for Message Service.
A brief description of the Narrative ̲Message ̲Protocol ̲Machine functional capabilities is
provided in Section 3.3.3.2, as an introduction to the detailed design n Section 3.3.3.3.
3.3.3.2 N̲M̲P̲M̲ ̲S̲u̲m̲m̲a̲r̲y̲ ̲D̲e̲s̲c̲r̲i̲p̲t̲i̲o̲n̲
A. P̲e̲r̲f̲o̲r̲m̲e̲d̲ ̲F̲u̲n̲c̲t̲o̲n̲s̲:̲
The NMPM performs the following functions:
o Maintain "Message Service System" Reliability
o Forward messages from FIKS to Message Service at the SCC
o Return messages from Message Service to FIKS
The NMPM configuration and environment is depicted in Figure 3.3.2.3.-1 below.
Figure 3.3.3.2-1, NMPM Configuration & Environment
B. N̲a̲r̲r̲a̲t̲i̲v̲e̲ ̲M̲e̲s̲s̲a̲g̲e̲ ̲P̲r̲o̲t̲o̲c̲o̲l̲
The elements & procedures of the protocol, employed by NMPM, are as follows:
B1. P̲r̲o̲t̲o̲c̲o̲l̲ ̲E̲l̲e̲m̲e̲n̲t̲
i) L̲o̲c̲i̲a̲l̲ ̲C̲h̲a̲n̲n̲e̲l̲ structure, defined by ANO's in the narrative messages from FIKS.
ii) N̲a̲r̲r̲a̲t̲i̲v̲e̲ ̲S̲M̲F̲ ̲M̲e̲s̲s̲a̲g̲e̲s̲
iii)A̲n̲t̲i̲-̲M̲e̲s̲s̲a̲g̲e̲s̲ ̲exchanged between the two SIP ̲
protocol ̲Machines for message synchronization (refer to B2).
iv) T̲r̲a̲n̲s̲m̲i̲s̲s̲i̲o̲n̲ ̲A̲C̲K̲'̲s̲ for messages transmitted to/received from NICS-TARE:
v) P̲e̲r̲f̲o̲r̲m̲a̲n̲c̲e̲ ̲A̲C̲K̲'̲s̲ ̲for Message Service performed to FIKS.
vi) S̲y̲n̲c̲-̲M̲e̲s̲s̲a̲g̲e̲s̲ for start and reset of inbound and outbound logical channels.
vii) S̲t̲a̲n̲d̲-̲b̲y̲ ̲&̲ ̲A̲c̲t̲i̲v̲e̲ ̲O̲p̲e̲r̲a̲t̲i̲o̲n̲ ̲of the SIP ̲
Protocol ̲Machine.
B2. G̲e̲n̲e̲r̲a̲l̲ ̲P̲r̲o̲c̲e̲d̲u̲r̲e̲ ̲D̲e̲s̲c̲r̲i̲p̲t̲i̲o̲n̲
When the "Message ̲Service ̲System" is open for FIKS, open SIP ̲ and one CIP ̲Protocol ̲Machine
is active.
Messages from FIKS for message service, are transmitted to both the active and stand-by
SPM.
Messages at the stand-by SPM are back-up for messages in progress at the "Message ̲Service
̲System" and will remain there until a "Performance ACK" has been encountered by the active
SPM. The active SPM then forwards an "Anti ̲Message" to the stand-by SPM that will "annihilate"
the corresponding message if it is recognized at the SPM. Otherwise, will the Anti ̲Message
be enqueued at the SPM and await the arrival of the message and cancel it when it appears.
Messages may arrive in different order at the active & stand-by SPM.
ACK's from the CPM and Anti ̲Messages from SPM are piggy backed in CIP ̲ and SIP ̲Keep ̲Alive
̲Messages, respectively.
Messages sent to Message ̲Service from FIKS i.e. SMF/ACP or ACP/SMF conversion, are not
acknowledged by the SPM, until the Message Service has been performed and the message
return to FIKS.
SPM performs the acknowledgemnet to CPM on behalf of FIKS.
The SIP ̲Protocol ̲Machine does not recognize the correlation between a message for conversion
and the corresponding converted message. That is done by CPM alone.
An example is shown in Figure 3.3.3.2-2 below.
Figure 3.3.3.2.2-2 SPM & CPM Message Exchange
SPM immediately ACK's incoming message on whatever logical channel that may arrive. CPM
on the other hand recognize converted messages. A cross reference between old ID (ID1)
and new ID (ID2) is maintained by CPM and the acknowledgement of the original received
message (ID1) withheld until the converted message (ID2) is acknowledged by SPM.
That make CPM realize the acknowledgement.
B3. L̲o̲g̲i̲c̲a̲l̲ ̲C̲h̲a̲n̲n̲e̲l̲ ̲S̲t̲a̲r̲t̲/̲R̲e̲s̲t̲a̲r̲t̲
When the logical channel between SPM and CPM is to be (re)opened, all messages left over
from a prior active session, has to be removed; the channel resynchronized. That is performed
by means of Sync ̲Messages (ref. B1, vi).
SPM and CPM exchange Sync ̲Seq ̲No. via Status ̲Reports, piggybacked in Keep ̲Alive ̲Messages,
and are used by SPM and CPM to recognize Sync ̲messages enqueued by CPM and SPM, respectively.
The Sync ̲Message is a label in the stream of incoming messages to CPM and SPM that signals
start of a new session. Prior messages are obsolete. CPM and SPM enters hunt mode, and
start normal operation as soon as the hunted Sync ̲Message is encountered. The channels
are In ̲Sync.
B4. S̲C̲C̲ ̲S̲w̲i̲t̲c̲h̲o̲v̲e̲r̲
When SCC switchover takes place, either caused by SCC failure or because the Supervisor
decides so, the stand-by protocol machine will go active.
Prior to that, all logical channel must be resynchronized. When active, the SPM will
start transmitting the oldest message, not yet released by an Anti ̲Message from the remote
SPM.
B5. S̲p̲e̲c̲i̲a̲l̲ ̲P̲r̲o̲v̲i̲s̲i̲o̲n̲s̲
Messages queued for intercept at the "Message Service System" are checkpointed and acknowledged
to FIKS to maintain message continuity on the logical channels.
Messages intercepted will appear as SCC source messages to FIKS.
C. N̲M̲P̲M̲ ̲H̲i̲g̲h̲l̲i̲g̲h̲t̲s̲
o Logical channel structure that allows simultanously service or messages to NICS-TARE
and messages for conversion.
o ACK's piggybacked in Keep ̲Alive ̲Messages will be constantly repeated, and may be
lost without any damages to the NMPM.
o Narrative Message back-up at collocated N/M to avoid that messages are trapped at
a defect SCC.
3.3.3.3.1
S̲I̲P̲ ̲P̲r̲o̲t̲o̲c̲o̲l̲ ̲M̲a̲c̲h̲i̲n̲e̲ ̲S̲u̲b̲m̲o̲d̲u̲l̲e̲ ̲ ̲(̲S̲P̲M̲)̲
3.3.3.3.1.1
S̲P̲M̲ ̲S̲u̲m̲m̲a̲r̲y̲ ̲D̲e̲s̲c̲r̲i̲p̲t̲i̲o̲n̲
The SPM submodule performs the following functions:
1) Handshaking with CPM to open the Narrative Message Link to the SCC
2) Receive and forward messages from FIKS to the collocated SCC
3) Acknowledge incoming messages from the SCC on behalf of FIKS
4) Receive and unpack SIP ̲and CIP ̲Keep ̲Alive ̲Messages
5) Interchange of Anti ̲Messages with remote SPM for message synchronization.
6) Delivery of oldest dtg in queues to CPM, for statistical purposes.
The SPM is invoked when:
1) An AMOS letter is received from SIP Watch Dog
2) Messages are enqueued in SDQ by the NSS
3) A Timer ̲Interrupt is encountered
An overview of the SPM environment is depicted in Figure 3.3.3.3.1.1-1.
1) AMOS Letter for SIP ̲Operational ̲Mode update
2) AMOS Letters containing events retrieved from CIP…0f…C…0e…/SIP…0f…R…0e… ̲Keep ̲Alive ̲Messages, i.e.
a) CWD…0f…C…0e… ̲Status ̲Reports
b) SWD…0f…R…0e… ̲Status ̲Reports
3) Narrative and Control Messages from FIKS network:
a) Narrative Messages from FIKS to the SCC
b) Narrative Messages from the SCC
c) Keep ̲Alive ̲Messages from CIP…0f…C…0e…
d) Keep ̲Alive ̲Messages from SIP…0f…R…0e…
4) Timer ̲Interrupt
5) Narrative and Control Messages to FIKS network:
a) Narrative Messages the SCC
b) Keep ̲Alive ̲Messages to SIP…0f…R…0e…
c) Keep ̲Alive ̲Messages to CIP…0f…C…0e…
6) Anti ̲Messages to SIP…0f…R…0e…
7) ACK's to CIP Protocol Machine (CPM)
Figure 3.3.3.3.1.1-1 (cont.'d)
The SPM is implemented as one CR80 Process, and a program module, which consists of the following
procedures:
1) SPM ̲Event ̲Distribution (SPMED)
2) SPM ̲Monitoring & Control (SPMM&C)
3) Outbound ̲Narrative ̲Message ̲Processing (ONMP)
4) Dispatch ̲Message (DMSG)
5) CPM ̲Ack ̲Processing (CPMAP)
6) Inbound ̲Anti ̲Message ̲Processing (IAMP)
7) Inbound ̲Narrative-Message ̲Processing (INMP)
8) In-Narrative-Message
9) SPM Timer Process (SPMTIM)
A visual table of content is provided in Figure 3.3.3.3.1.1-2
figure 3.3.3.3.1.1-2, SPM Visual Table of Content
3.3.3.3.1.2 S̲P̲M̲ ̲D̲e̲t̲a̲i̲l̲e̲d̲ ̲D̲e̲s̲i̲g̲n̲
3.3.3.3.1.2.1
P̲r̲o̲c̲e̲d̲u̲r̲e̲ ̲S̲P̲M̲-̲E̲v̲e̲n̲t̲-̲D̲i̲s̲t̲r̲i̲b̲u̲t̲i̲o̲n̲ ̲ ̲(̲S̲P̲M̲E̲D̲)̲
A. N̲a̲r̲r̲a̲t̲i̲v̲e̲:̲
SPM Event ̲Distribution is invoked, when an external event is received by the spm process,
i.e.
o AMOS messages from SIP Watch Dog
o Timer Interrupt
o Narrative Messages from FIKS
o Control Messages from FIKS
The event is decoded and validated, and if not recognized an error is reported. Events
recognized by SPMED are:
i) Operational Mode Control message from SIP Watch Dog (SWD)
ii) Timer Interrrupt to run the timers (syntim & RQLTIM)
iii)Narrrative Messages for Message ̲Service at the
SCC, i.e.:
a) SMF to ACP Conversion
b) ACP to SMF Conversion
c) Transmission to NICS-TARE
iv) Narrative Messages from the SCC, i.e.:
a) Messages receivedfrom NICS-TARE
b) Messages returned from "Message Service", i.e. a) and b) above
v) Keep ̲Alive ̲Messages from:
a) Collocated CIP
b) Remote SIP
The respectively even types are validated in accordance to SPM ̲Operational ̲Mode and the
onward event processing is performed by a call to one of the following procedures:
o SPM Timer Process (SPMTIM)
o SPM ̲Monitor & JControl (SPMM&C)
o Outbound ̲Narrative ̲Message ̲Processing (ONMP)
o Inbound ̲Anti ̲Message ̲Processing (OAMP)
o Inbound ̲Narrative ̲Message ̲Processing (INMP)
o CPM ̲ACK ̲Processing (CPMAP)
o In-Narrative-Message (INNMSG)
A detailed description of each event is provided in the following subsections, and the
event distribution is illustrated in Figure 3.3.3.3.1.2.1-1.
Figure 3.3.3.3.1.2.1-1, SPM Event-distribution
A1. A̲M̲O̲S̲-̲L̲e̲t̲t̲e̲r̲s̲ ̲f̲r̲o̲m̲ ̲S̲I̲P̲-̲W̲a̲t̲c̲h̲ ̲D̲o̲g̲/̲S̲P̲M̲-̲O̲p̲e̲r̲a̲t̲i̲o̲n̲a̲l̲-̲M̲o̲d̲e̲
This event is handled by "SPMM&C" (ref.3.3.3.3.1.2)
and controls the SPM ̲Operational ̲Mode (SPMOPM), used for validation of ther events.
SPMOPM may be in four states:
O: Off-line
S: Stand-by
H: Hunt
A: Active
State O and S correspond to the global SIP-Operational ̲Mode state O and S (ref. 3.3.2.3.1.2.2-A1),
while both state "H" and "A" are SIPOPM "A" states.
State "H" is entered on start and restart of the inbound channels from the SCC, i.e.
when the SCC goes active.
A2. T̲i̲m̲e̲r̲-̲I̲n̲t̲e̲r̲r̲u̲p̲t̲
This event is forwarded to "SPMTIM" for use when running the timers (SYNTIM & RQLTIM).
A3. N̲a̲r̲r̲a̲t̲i̲v̲e̲ ̲M̲e̲s̲s̲a̲g̲e̲
A Narrative Message is classified in accordance to the ANO number(s), stored in the message,
and makes the logical channels employed by the SCC Protocol Machine.
The logical channel No. (CH #) is retrieved by a call to "INNMSG" and is by "SPMED" recognized
as:
i) An Outbound Message Channel (to the SCC)
ii) An Inbound Message Channel (from the SCC)
Outbound messages are unconditionally delivered to the procedure "ONMP".
Inbound messages are only delivered to the procedure "INMP" if SPM ̲Operational ̲Mode is
active. Otherwise, inbound messages are released from the SIP ̲Distribution ̲Queue (SDQ).
A4. C̲o̲n̲t̲r̲o̲l̲ ̲M̲e̲s̲s̲a̲g̲e̲s̲
The only control messages recognized by SPMED are Keep ̲Alive ̲Messages from either the
remote SIP…0f…R…0e… or the collocated CIP…0f…C…0e…, or Sync Messages.
Keep ̲Alive ̲Messages may carry several events, which depend on SPM ̲Operational ̲Mode.
i) S̲I̲P̲…8f…R̲…8e…-̲K̲e̲e̲p̲-̲A̲l̲i̲v̲e̲-̲M̲e̲s̲s̲a̲g̲e̲
A SIP…0e…R…0e…KAM always contains a SWD…0f…R…0e… ̲Status ̲Report, which is retrieved and frowarded to the
SWD…0f…C…0e… ̲Submodule by means of an AMOS ̲message.
If SPM ̲Operational ̲Mode is hunt or active, a SIP…0f…R…0e… ̲KAM may in addition carry up to one
"Anti ̲Message" per outbound logical channel.
These "Anti ̲Messages" are retrieved one after another delivered to the procedure "IAMP".
ii) C̲I̲P̲…8f…C̲…8e…-̲K̲e̲e̲p̲-̲A̲l̲i̲v̲e̲-̲M̲e̲s̲s̲a̲g̲e̲
A CIP…0f…C…0e…KAM always contains a CWD…0f…C…0e… ̲Status ̲report, which is retrieved from the KAM and forwarded
to the SWD…0f…C…0e… ̲submodule, by means of an AMOS message.
If SPM ̲Operational ̲Mode is active, the DIP…0f…C…0e…KAM may in addition contain up to one CPM
̲ACK per inbound logical channel, which are retrieved and one after another delivered
to the procedure "CPMAP".
iii)S̲y̲n̲c̲ ̲M̲e̲s̲s̲a̲g̲e̲s̲
Sync Messages are unconditionally delivered to procedure "SPMM & C".
B. P̲r̲o̲g̲r̲a̲m̲:̲
REPEAT
"WAIT ̲EVENT" (EVENT)
CASE ̲OF ̲EVENT (1,2,3)
1. 'EVENT = AMOS Message
CALL "SPMM&C"
2. 'EVENT = Timer ̲Interrupt
CALL "SPMTIM"
3. 'EVENT = jSIGNAL'
REPEAT UNTIL SDQ Empty
Retrieve ̲MSG (SDQ, MSG)
IF MSG ̲TYPE = Narrative ̲Message)
THEN
"INNMSG" (MSG, CH #)
CASE ̲OF ̲TYPE (CH #) (1,2,3)
1. 'Outbound ̲Channel'
CALL "ONMP" (MSG, CH #)
IF (SPM Operational Mode = Output ACTIVE
THEN
CALL ("MSG, CH #)
END IF
2. 'Inbound ̲Channel'
IF (SPM ̲Operational ̲Mode = Input Active)
THEN
CALL "INMP" (MSG, CH #)
ELSE
Release (MSG, SDQ9
END IF
3. 'ELSE'
"REPORT ̲ERROR" (Unknown ̲Channel)
END CASE
ELSE (MSG ̲TYPE = Control ̲Message)
CASE ̲OF ̲CTRL ̲MSG (1,2,3,4)
1. 'Sync Message'
CALL 'SPMM&C'
2. 'SIP…0f…R…0e… ̲Keep ̲Alive ̲Message'
Retrieve SWD…0f…R…0e… ̲Status ̲Report
"Send AMOS (SWD…0f…R…0e… ̲Status ̲Report)
"Wait Answer"
IF (SIP ̲Operational ̲Mode = Stand-by
THEN
FOR (All ̲Anti ̲MSG's in SIP…0f…R…0e… ̲KAM)
DO
Retrieve AMSG (ID, C #)
CALL "IAMP" (AMSG, ID, CH #)
END DO
END IF
3. 'CIP…0f…C…0e… ̲Keep ̲Alive ̲Message'
Retrieve CWD…0f…C…0e… ̲Status ̲Report
"Send AMOS Message (CWD…0f…C…0e… ̲Status ̲Report)
"Wait Answer"
IF (SPM-Operational ̲Mode = Active)
THEN
FOR (All ̲CPM ̲ACK' s in KAM)
DO
Retrieve CPM ̲ACK (ID, CH #)
CALL "CPMAP" (ID, CH #)
END DO
END IF
4. 'ELSE'
"REPORT ̲ERROR" (Unknown ̲Control ̲MSG)
END CASE
END IF
END REPEAT
END CASE
END REPEAT
3.3.3.3.1.2.1.1
S̲u̲b̲r̲o̲u̲t̲i̲n̲e̲ ̲"̲I̲N̲N̲M̲S̲G̲"̲ ̲ ̲(̲M̲S̲G̲,̲ ̲C̲H̲ ̲#̲)̲
A. N̲a̲r̲r̲a̲t̲i̲v̲e̲:̲
"INNMSG" is called by "SPMED" and "CPMED" (ref. 3.3.3.3.2.2.1) when a Narrative ̲MSG has
been encountered to make out to which logical channels, the message belongs.
The ANO(s) contined in the message is the logical channel designator, and assigned as
shown in Table 3.3.3.3.1.2.1.1-1.
ANO Logical TYPE
CH # SPM CPM
--------------------------------------------------------------------
X003 CH1 Messages for conversion ACP/SMF O * I
X004 CH0 Messages for conversion SMF/ACP O I
X005-X255 CH2 Message to NICS-TARE O I
T,U,V,WOOO-
255
S/Z 203 CH4 Converted Message ACP/SMF I O
S/Z 204 CH3 Converted Message SMF/ACP I O
S/Z 205 CH5 Messages from NICS-TARE I O
S/Z 206 CH6 SCC Intercepted Message I O
*) O: Outbound, I: Inbound,
Table 3.3.3.3.1.2.1.1.-1, Logical Channels
"INNMSG" scans through the ANO list in the message handed over, to search for an ANO
designating a logical channel.
The v̲e̲r̲y̲ ̲f̲i̲r̲s̲t̲ recognized, will be used as channel designator, and the remaining ANO's
will be ignored by "INNMSG". That means that if the ANO List contains elements, which
point to more than one logical channel, only the first will be used and returned to the
caller.
If no ANO's are recognized it is assumed that a CH2 ANO is contained in an AIG.
B. P̲r̲o̲g̲r̲a̲m̲:̲
BEGIN
REPEAT UNTIL (ANO recognized) or (All ANO's done)
Read ̲Next ̲ANO
IF (ANO recognized)
THEN
CH #:= CHANNEL (ANO)
EXIT
END
END REPEAT
CH #:= CH2
END
3.3.3.3.1.2.2
P̲r̲o̲c̲e̲d̲u̲r̲e̲ ̲j̲S̲P̲M̲ ̲M̲o̲n̲i̲t̲o̲r̲i̲n̲g̲ ̲&̲ ̲C̲o̲n̲t̲r̲o̲l̲ ̲ ̲(̲S̲P̲M̲M̲&̲C̲)̲
A. N̲a̲r̲r̲a̲t̲i̲v̲e̲:̲
Procedure SP;;&C performs the following functions:
o Control the operation mode of the SIP Protocol Machine (SPM) as command by CIP Watch
Dog
o Channel Synchronization upon opening of the logical channels to CPM (SCC)
SPMM&C is invoked by "SPMED" when:
o An AMOS letter from SWD is encountered
o An Inbound Sync. Message is received
A1. S̲W̲D̲ ̲M̲o̲d̲e̲ ̲C̲o̲n̲t̲r̲o̲l̲ ̲C̲o̲m̲m̲a̲n̲d̲
This command is received from SWD each time a SIP ̲Operational ̲Mode change has taken place
and is a command to SPM to operate in accordance to the current SCC status.
The only state changes of interest here are Stand-by to Active and Active to Stand-by.
i) S̲t̲a̲n̲d̲b̲y̲ ̲t̲o̲ ̲A̲c̲t̲i̲v̲e̲
All ACK-seq.no.'s are cleared and CIP…0f…C…0e… ̲Mailbox is reset.
The SPM enters "Hunt Mode" (ref. 3.3.3.3.1.2.1-A1) and "Sync Mode).
In order to reopen the logical channels to/from CPM a SYNC. Message is transmitted to
CPM with sync.seq.no. updated. (Chamel synchronization).
The sync timer is started upon transmission.
ii) A̲c̲t̲i̲v̲e̲ ̲t̲o̲ ̲S̲t̲a̲n̲d̲-̲b̲y̲
The SPM stops operating the inbound logical channel as soon as the collocated SCC goes
standby. All inbound narrative messages from the SCC are discarded by "SPMED" and no
provision is required by SPMM&C.
On the outbound logical channels are all unacknowledged messages returned from the "Transmitted
̲MSG ̲Q" to the "Pending ̲MSG ̲Q" and these channels will from now on function as back-up
for the corresponding channels at the active SPM.
iii)While "Hunt Mode" a received Sync. Seq.No. is a
Sync. Message will be returned to CPM in a Keep Alive Message by mailing in CIP…0f…C…0e… Mailbox
for SWD to transmit, and then SPM exits from "Hunt Mode", and sets 'Input Active'.
iv) While in "Sync Mode" a received Keep Alive Message is checked for the correct sync.seq.no.,
and when this is found, SPM exists "Sync Mode" and sets 'Output Active'.
A call is made to "Dispatch Msg" (DSMG 3.3.3.3.1.2) and the SPM outbound channels are
active.
The sync timer is stopped when this has occured.
B. P̲r̲o̲g̲r̲a̲m̲
BEGIN
CASE ̲OF ̲EVENT (1,2,3,)
1. 'SWD Mode ̲Control ̲Command'
IF (SIP ̲Operational ̲Mode CMD = Active)
THEN
'Clear all ACK.seq.no's
'Clear CIP…0f…C…0e… Mailbox'
'Enter Hunt Mode on inbound channels'
'Enter Sync Mode'
Retrieve Sync ̲Seq No.. CMD
SPM ̲Operational ̲Mode:= HUNT + SYNC (Sync ̲Seq ̲No. CMD
'Initiate resynchronization of outbound
channels'
"CREATE ̲SYNC ̲MESSAGE" (Sync ̲Seq ̲No)
"ENQUEUE" (Sync ̲MSG, TQ)
'Start Sync. timer'
CALL SPMTIM (PSYNTIM)
ELSE (SIP ̲Operational ̲Mode. CMD= Stand-by)
'Close Inbound channels'
SPM ̲Operational ̲Mode:= Stand-by
'Reset Outbound Channel to Stand-by'
FOR (All Outbound Channels)
DO
REPEAT (While TMQ (CH #) non-empty)
"DEQUEUE" (MSG, TMQ (CH #))
"ENQUEUE" (MSG, PMQ (CH #))
END REPEAT
END DO
'Stop Sync. timer'
CALL SPMTIM (SSYNTIM)
END IF
2. 'Sync.Seq.No. received' (In Keep Alive Msg.)
IF (Sync.Seq.No. HUNT = SYNC.SEQ.No. MSG)
THEN
SPM Operational Mode:= Output Active
'Exit Sync Mode'
'Stop Sync timer'
CALL SPEMTIM (SSYNTIM)
FOR (All Outbound Channels)
DO
CALL "DISPATCH MSG" (DMSG)
END DO
END IF
3. 'Sync. Message received'
IF (SPM Operational Mode = Active)
THEN
'Exit Hunt Mode'
SPM Operational Mode:= Input Active 'Mail Sync.Seq.No.' (In CIP…0f…jC…0e… Mailbox)
END IF
END CASE
END
3.3.3.3.1.2.3
P̲r̲o̲c̲e̲d̲u̲r̲e̲ ̲O̲u̲t̲b̲o̲u̲n̲d̲-̲N̲a̲r̲r̲a̲t̲i̲v̲e̲-̲M̲e̲s̲s̲a̲g̲e̲-̲P̲r̲o̲c̲e̲s̲s̲i̲n̲g̲ ̲ ̲(̲O̲N̲M̲P̲)̲
A. N̲a̲r̲r̲a̲t̲i̲v̲e̲:̲
Procedure ONMP is called by "SPMED" whenever a narrative message for transmission to
the SCC is encountered.
It is new message for Message ̲Service at the SCC.
ONMP is employed by the three logical channels from FIKS to the SCC, and the one in question
is pointed out by the channel no (CH #), validated and handed over by SPMED. The logical
channels recognized by ONMP are:
C̲H̲ ̲#̲ ̲ M̲n̲e̲m̲o̲n̲i̲c̲ M̲e̲s̲s̲a̲g̲e̲ ̲D̲e̲s̲c̲r̲i̲p̲t̲i̲o̲n̲
CH0 CHSAC SMF to ACP Conversion
CH1. CHASC ACP to SMF Conversion
CH2 CHFIN FIKS to NICS-TARE
All outbound channels from FIKS to the SCC are
handled into the same way by ONMP. That means that the connection between an outgoing
message for conversion and the correspondent incoming converted message is n̲o̲t̲ recognized
by PM, but is alone managedby the CIP-Protocol ̲Module (CPM).
The processing performed is determined by SIP ̲Operational ̲Mode (STAND-by/Active).
A1. N̲e̲w̲ ̲M̲e̲s̲s̲a̲g̲e̲ ̲ ̲(̲S̲t̲a̲t̲u̲s̲ ̲=̲ ̲O̲K̲)̲
The message is, by a call to"FILTERID", compared to the "Anti ̲Messages" (AMSG) currently
queued on that channel. If a match is found (with respect to MSG ̲ID) then both the "Anti-message"
and the messages themself are released (Message/Anti ̲Message)
Otherwise the message is enqueued in the Pending ̲Message ̲Queue for that channel and remains
here until transmitted to the SCC by either local or remote SPM.
B. P̲r̲o̲g̲r̲a̲m̲:̲
BEGIN
CALL "FILTERID" (Anti ̲MSG ̲Q, MSG ̲ID)
IF (Anti ̲MSG (MSG ̲ID) is found)
THEN
Release anti ̲MSG
Release Message
ELSE
Enqueue (MSG, Pending ̲MSG ̲Q)
END IF
END
3.3.3.3.1.2.4
P̲r̲o̲c̲e̲d̲u̲r̲e̲ ̲D̲i̲s̲p̲a̲t̲c̲h̲-̲M̲S̲G̲ ̲ ̲(̲C̲H̲ ̲#̲)̲ ̲ ̲(̲D̲M̲S̲G̲)̲
A. N̲a̲r̲r̲a̲t̲i̲v̲e̲:̲
Procedure DMSG is only called when SIP-̲Operational ̲Mode is active, and then by "CPMED"
when a message has been enqueued in the Pending ̲Message ̲Queue, or by "CPMAP" when a message
has been released fron the "Transmitted ̲Message ̲Queue" (TMQ).
DMSG performs the delivery of messages to the NSS for transmission when messages are
pending and the channel is available for transmission.
The channel is available if less than "MAXTRANSMIT" messages are awaiting CPM acknowledgement
(MAX-TRANSMIT = 1) Otherwise the channel is "busy" and no further transmissions will
take place until at least one message in TMQ is released by a CPM acknowledgement.
The processing is as follows:
While a message is pending in PMQ and the channel is available, the oldest message in
PMQ is dequeued
from PMQ and enqueued in TMQ and at the same time deliverd to the NSS in the Transport
Queue (TQ).
B. P̲r̲o̲g̲r̲a̲m̲.̲
BEGIN
REPEAT UNTIL ((CHANNEL ̲BUSY) or (PMQ empty))
Dequeue (Pending ̲MSG ̲Q, MSG)
Enqueue (Transmitted ̲MSG ̲Q, MSG)
Enqueue (TQ, MSG)
Intercrement Transmitted ̲MSG ̲Count
IF (Transmitted ̲MSG ̲Count-MAXTRANSMIT)
THEN
CHANNEL ̲BUSY:= TRUE
END IF
END REPEAT
END
3.3.3.3.1.2.5
P̲r̲o̲c̲e̲d̲u̲r̲e̲ ̲C̲M̲P̲-̲A̲C̲K̲-̲P̲r̲o̲c̲e̲s̲s̲i̲n̲g̲ ̲ ̲(̲C̲M̲P̲A̲P̲)̲
A. N̲a̲r̲r̲a̲t̲i̲v̲e̲:̲
Procedure CMPAP is called by "SPMED" when a CPM ̲Acknowledgement is encountered. The CH
# and MSG ̲ID designating the message(s) acknowledged, is validated and handed over by
SPMED.
CMPAP is only called when SIP ̲Operational ̲Mode is active.
A CPM acknowledgement may be an acknowledgement of up to "MAXTRANSMIT" messages, received
by CPM (ref. 3.3.3.3.1.2.4).
The processing is as follows:
The Transmitted ̲Message ̲Queue (TMQ) is searched for the message, with the same MSG ̲ID,
as received in the acknowledgement.
If the message is found, it is dequeued from TMQ and released, along with all older messages
held in TMQ.
For each message dequeued from TMQ, a corresponding "Anti ̲Message" (same MSG ̲ID) is
mailed in the SIP ̲Mailbox. SIP ̲Mailbox overflow may occur, and in that case a Delivery
request is immediately sent to the SIP ̲Watch ̲Dog (SWD) before the remaining "Anti-messages"
are mailed.
B. P̲r̲o̲g̲r̲a̲m̲:̲
BEGIN
CALL "SEARCHBUF" (Transmitted ̲MSG ̲Q (CH # MSG ̲ID)
IF (Message (MSG ̲ID) is found)
THEN
FOR (Oldest ̲MSG) until (MSG ̲ID))
DO
IF (SIP Mailbox Overflow)
THEN
REPEAT Send AMOS Signal (Delivery ̲Request)
Until (No SIP Mailbox overflow)
END IF
Get ̲MSG ̲ID (MSG)
Creat ̲Anti ̲MSG (MSG-̲ID)
"RESERVE ̲CRITICAL ̲REGION" (SIP ̲Mailbox)
Mail Anti ̲MSG (MSG ̲ID) in SIP ̲Mailbox
"RELEASE ̲CRITICAL ̲REGION" (SIP ̲Mailbox)
Dequeue (MSG, TMQ)
Release MSG
END DO
END IF
END
3.3.3.3.1.2.6
P̲r̲o̲c̲e̲d̲u̲r̲e̲ ̲I̲n̲b̲o̲u̲n̲d̲-̲N̲a̲r̲r̲a̲t̲i̲v̲e̲-̲M̲e̲s̲s̲a̲g̲e̲-̲P̲r̲o̲c̲e̲s̲s̲i̲n̲g̲ ̲ ̲(̲I̲N̲M̲P̲)̲
A. N̲a̲r̲r̲a̲t̲i̲v̲e̲:̲
Procedure INMP is called by "SPMED" when a narrative message from the SCC is encountered,
and while SIP ̲Operational ̲mode is active. SIP is actually not a recipient of narrative
messages from the SCC.
The only purpose of sending narrative messages to SIP is to have SPM, on behalf of FIKS,
perform the acknowledgement of received messages.
INMP is employed by four logical channels from the SCC to FIKS, and the channel currently
served is designated by the channel no. (CH #) validated and handed over by SPMED.
the logical channels recognized by INMP are:
C̲H̲ ̲#̲ M̲n̲e̲m̲o̲n̲i̲c̲ M̲e̲s̲s̲a̲g̲e̲ ̲D̲e̲s̲c̲r̲i̲p̲t̲i̲o̲n̲
CH3 CHSAO SMF to ACP Conversion Object
CH4 CHASO ACP to SMF Conversion Object
CH5 CHNTF NICS-TARE to FIKS
CH6 CHIFM Intercepted FIKS Messages
All inbound channels are processed in the same way, i.e. a converted message is n̲o̲t̲ related
to the original message sent from FIKS to the SCC for cenversion, but handled as if it
was a message received from a SCC located message source.
INMP processing of incoming narrative messages is as follows:
The MSG ̲ID is retrieved from the message, and written into the acknowledgement created.
The acknowledgement is mailed in the CIP ̲Mailbox, and the message is released.
B. P̲r̲o̲g̲r̲a̲m̲:̲
BEGIN
Retrieve ̲MSG ̲ID (MSG, MSG ̲ID)
Creat-ACK (MSG ̲ID, CH #)
RESERVE ̲CRITICAL ̲REGION (CIP ̲Mailbox)
Mail ACK in CIP ̲Mailbox
RELEASE ̲CRITICAL ̲REGION (CIP ̲Mailbox)
Release ̲MSG
'Make SWD mail ACK'
'Send AMOS signal
END
3.3.3.3.1.2.7
P̲r̲o̲c̲e̲d̲u̲r̲e̲ ̲I̲n̲b̲o̲u̲n̲d̲-̲A̲n̲t̲i̲-̲M̲e̲s̲s̲a̲g̲e̲-̲P̲r̲o̲c̲e̲s̲s̲i̲n̲g̲ ̲ ̲(̲I̲A̲M̲P̲)̲
A. N̲a̲r̲r̲a̲t̲i̲v̲e̲:̲
Procedure IAMP is called by "SPMED" when an "Anti ̲Message" (AMSG) is encountered.
The AMSG's are used for message synchronization between the stand-by and active SPM,
and is sent from the active SPM wehnever a message has been transmitted and properly
acknowledged.
It signals to the stand-by SPM that the message designated by the AMSG may be released.
Messages for message service at the SCC are simultaneously transmitted to the active
and stand-by collocated N/M SIP's, but is not necessarily received in the same order
by both SIP's (network delay).
It could happen that an "Anti-Message" arrives to the stand-by SIP, before the corresponding
message is received. In that case the AMSG must be stored and wait for the arrival of
the message.
The processing of "Anti ̲Messages" is similar to the processing of narrative messages
by ONMP (ref. 3.3.3.3.1.2.3) with the interchange of the parts played by "Anti Messages"
and messages, respectively.
The AMSG is, by a call to "FILTRID" compared to the pending messages, currently held
in PMQ.
If a message with identical MSG ̲ID is found, the AMSG is released, and the message dequeued
from PMQ and released. Otherwise is the AMSG enqueued in the "Anti ̲Message ̲Queue" (AMQ)
for that channel.
B. P̲r̲o̲g̲r̲a̲m̲ ̲ ̲O̲A̲M̲P̲ ̲ ̲(̲M̲S̲G̲-̲I̲D̲,̲ ̲ ̲C̲H̲ ̲#̲)̲:̲
BEGIN
"FILTERID" (Pending ̲MSG ̲Q (CH #)) (MSG ̲ID)
IF (MSG (MSG ̲ID) is found)
THEN
DEQUEUE (MSG, Pending ̲MSG ̲Q (CH #))
Release MSG
Release AMSG
ELSE
ENQUEUE (AMSG, Anti ̲MSG ̲Q (CH #))
END IF
END
3.3.3.3.1.2.8
P̲r̲o̲c̲e̲d̲u̲r̲e̲ ̲ ̲S̲P̲M̲ ̲T̲i̲m̲e̲r̲ ̲ ̲(̲S̲P̲M̲T̲I̲M̲)̲
A. N̲a̲r̲r̲a̲t̲i̲v̲e̲:̲
The SPM Timer constitutes two separate timers, identified as:
1) Sync. Message timer (SYNTIM)
2) Queue length Release timer (RQLTIM)
SPMTIM is invoked by SPMED when a Timer Interrupt is encountered by the SPM Process, and
is used to drive the above mentioned timers.
SPMTIM maintains these timers, as commanded by the procedure SPMM&C, and when a timer expires
a predefined action is performed.
The purpose and maintenance of these timers are as follows:
A1. S̲Y̲N̲T̲I̲M̲ ̲T̲i̲m̲e̲r̲
The purpose of SYNTIM us to detect when a Sync.Message has failed to appear within a
predefined time interval (SYNTIM preset value TIMESSYN) which will result in an update
of Sync. seq.no. and a new transmission of a Sync.Message.
This in turn results in a restart of SYNTIM.
A2. R̲Q̲L̲T̲I̲M̲ ̲T̲i̲m̲e̲r̲
The RQLTIM serves to trigger the collecting of queuelengths pr CH # and oldest DTG of
messages waiting to be converted at SCC. The collected data are copied into the CIP…0f…C…0e…
Mailbox for transmission to CPM at collocated SCC. This done by call of subroutine MAILQL.
RQLTIM is in return preset by MAILQL each time collection has been performed.
B. P̲r̲o̲g̲r̲a̲m̲ ̲ ̲S̲P̲M̲T̲I̲M̲:̲
BEGIN
CASE OF EVENT/COMMAND (1,2,3,4,5)
1. 'Event = Timer Interrupt'
'Run Timers'
SYNTIM:= SYNTIM-1
RQLTIM:= RQLTIM-1
IF (SYNTIM= O 'SYNTIM expired')
THEN
CALL "SPMM&C" (Send Sync.Message)
END IF
IF (RQLTIM =O'RQLTIM expired')
THEN
'Mail Queue length'
CALL MAILQL-Subroutine
END IF
2. 'COMMAND= Preset SYNTIM'
SYNTIM:= TIMSSYN
3. 'COMMAND= Preset RQLTIM
RQLTIM:= TIMRQL
4. 'COMMAND= Stop SYNTIM'
SYNTIM:=0
5. 'COMMAND= Stop RQLTIM'
RQLTIM:=0
END CASE
END
3.3.3.3.1.2.9
S̲u̲b̲r̲o̲u̲t̲i̲n̲e̲ ̲F̲I̲L̲T̲E̲R̲I̲D̲ ̲ ̲(̲Q̲U̲E̲U̲E̲;̲ ̲I̲D̲)̲
A. N̲a̲r̲r̲a̲t̲i̲v̲e̲:̲
FILTERID operates on queues and queue elements same data structure:
o Transmitted ̲Message ̲Queue (TMQ)
o Pending ̲Message ̲Queue (PMQ)
o Anti ̲Message ̲Queue (AMQ)
The purpose of "FILTERID" is to search for a specific element identified by "ID" in
the queue designated by "QUEUE".
"FILTERID" is called by:
o ONMP to search for anelement in AMQ
o CPMAP to search for an element in TMQ
o IAMP to search for an element in PMQ
Each queue element in AMQ, TMQ and PMQ has upon enqueueing been allowed a certain "Lifetime",
which thereafter is maintained by "FILTERID".
The processing performed by "FILTERID" is as follows:
If the queue is non-empty the first (oldest) element is inspected to see whether an element
̲ID is identical to the "ID" searched for, and if so, the reference to that element is
returned to the caller.
Otherwise, is the element's "Lifetime" decremented, and if expired, dequeued and released
in accordance with type, i.e. Anti ̲Messages are discarded and messages are enqueued in
the N/M supervisors distribution queue (DT).
The queue is scanned, until all elements are inspected or an "ID" match is detected.
B. P̲r̲o̲g̲r̲a̲m̲ ̲ ̲S̲E̲A̲R̲C̲H̲-̲Q̲U̲E̲U̲E̲ ̲ ̲(̲Q̲U̲E̲U̲E̲,̲ ̲I̲D̲)̲
BEGIN
REPEAT UNTIL (ID ̲Match) or (All elements done)
Retrieve (ELEMENT, Queue)
IF (ELEMENT.ID = ID)
THEN
FOUND:= TRUE
ELSE
Decrement ELEMENT.LIFETIME
IF (ELEMENT.LIFETIME= 0)
THEN
DEQUEUE (ELEMENT, QUEUE)
IF (ELEMENT.TYPE = ANTI ̲MESSAGE)
THEN
Release ELEMENT
ELSE
ENQUEUE (ELEMENT.MTCB, DT ̲Queue)
END IF
END IF
END IF
END REPEAT
END
3.3.3.3.2 C̲I̲P̲ ̲P̲r̲o̲t̲o̲c̲o̲l̲ ̲M̲a̲c̲h̲i̲n̲e̲ ̲(̲C̲P̲M̲)̲
3.3.3.3.2.1
C̲P̲M̲ ̲S̲u̲m̲m̲a̲r̲y̲ ̲D̲e̲s̲c̲r̲i̲p̲t̲i̲o̲n̲
The CPM submodule performs the following functions:
1) Handshaking with SPM to open the Narrative Message Channels to the SCC
2) Receive/Forward messages to/from the SCC from/to FIKS
3) "Performance ̲ACK" of "Message Services" performed for FIKS (Message Conversion)
4) Acknowledgement of messages from/to FIKS transmitted/received to/from NICS-TARE
5) SCC Internal Message Distribution of messages to/from FIKS
6) Receive and unpack SIP…0f…C…0e… ̲Keep ̲Alive ̲Message
The CPM is invoked when:
1) AMOS Message from CIP Watch Dog is encountered
2) Message enqueued in MDQ by the NSS for internal SCC distribution
3) Message winqueued in N/M queue by the MSS
4) Command/Response/ACK enqueued in NC queue by MSS
An overview of the CPM environment is depicted in Figure 3.3.3.3.2.1-1.
The CPM submodule is implemented as one CR80 process and a program module which consists
of the following procedures:
1) CPM Message & Event Distribution (CPMM&ED)
2) CPM monitoring & Contorl (CPMM&C)
3) Narrative Message Accounting (NMACT)
4) Outbound ̲Stuck ̲Message ̲Processing (OSTMP)
5) Narrative ̲Message ̲ACK ̲Processing (NMACKP)
6) In Narrative Message (INNMSG)
7) Inbound Narrative Message Processing (INMP)
8) CPM timer Process (CPMTIM)
Figure 3.3.3.3.2.1-2, CPM Visual Table of content
3.3.3.3.2.2 C̲P̲M̲ ̲D̲e̲t̲a̲i̲l̲e̲d̲ ̲D̲e̲s̲i̲g̲n̲
3.3.3.3.2.2.1 P̲r̲o̲c̲e̲d̲u̲r̲e̲ ̲C̲P̲M̲ ̲M̲e̲s̲s̲a̲g̲e̲ ̲&̲ ̲E̲v̲e̲n̲t̲ ̲D̲i̲s̲t̲r̲i̲b̲u̲t̲i̲o̲n̲ ̲ ̲(̲C̲P̲M̲M̲&̲E̲D̲
A. N̲a̲r̲r̲a̲t̲i̲v̲e̲:̲
CPM Message & Event Distribution is invoked, when an external event is encountered by
the CPM process, i.e.:
o AMOS Message Received
o Message enqueued in MDQ Queue
o Message enqueued in NM Queue
o Message enqueued in NC Queue
o Timer Interrupt (AMOS Answer)
"CPMM&ED" performs both the external and internal message distribution of messages to/from
FIKS from/to the SCC, and the CPM internal event distribution.
In other words, CPMM&ED provides the message distribution function within the SCC, of
narrative and control messages received form FIKS and delivered in the MDQ queue by the
NSS.
Messages and event encountered by the CPM process are validated by CPMM&ED and an error
reported, if not recognized.
Events recognized by CPMM&ED are:
i) Comamnd letters from CIP Watch Dog
ii) Inbound Narrative Messages for Message Service at the SCC
iii) Sync-Messages
iv) SIP…0f…C…0e…Keep ̲Alive ̲Messages
v) FIKS to NSC Control Messages
vi) Outbound Messages returned from Message ̲Service
vii) Control Messages from NSC to FIKS
viii) NICS-TARE Transmission ACK's
ix) Reports & Responses from MSS
x) Timer Interrupt to run the timer (SYNTIM)
Events are validated in accordance to CPM ̲Operational ̲Mode (ref. A1) and processed and distributed
by CPMM&ED to one of the following procedures:
o CPM Timer Process (CPMTIM)
o CPM Monitoring & Control (CPMM&C)
o Narrative ̲Message ̲Accounting (NMACT)
o Intercept Narrative Message (INTERCEPT)
o Narrative ̲Message ̲ACK ̲Processing (NMACKP)
o Inbound Narrative Message Processing (INNMSG)
The event distribution is depicted in Figure 3.3.3.3.2.2.1-1, and a detailed description
of each case is provided in the following subsections.
Figure 3.3.3.3.2.2.1-1, CPM EVENT-distribution
A1. A̲M̲O̲S̲ ̲L̲e̲t̲t̲e̲r̲ ̲f̲r̲o̲m̲ ̲C̲I̲P̲ ̲W̲a̲t̲c̲h̲ ̲D̲o̲g̲/̲C̲P̲M̲-̲O̲p̲e̲r̲a̲t̲i̲o̲n̲a̲l̲-̲M̲o̲d̲e̲
Two types of commands may be issued by CWD to CPM:
o CPM Oplerational ̲Mode Control
All commands are delivered to CPMM&C (ref. 3.3.3.3.2.2) which maintains the CPM ̲Operational
̲Mode in accordance to the CIP ̲Operational ̲Mode change reported in the CWD Command letter
and forward commands to the MSS.
CPM ̲Operational ̲Mode, on the other hand, controls the message distribution function performed,
and may be in four states:
O: Off-line
S: Stand-by
H: Hunt
A: Active
States "O" and "S" correspond to the CIP ̲Operational-Mode states "O" and "S", while both
states "H" and "A" are CIPOPM "A" states.
State "H" is entered on start and restart of the inbound narrative message channel from
FIKS, i.e. whenever the SCC goes from non-active to active.
A2. N̲a̲r̲r̲a̲t̲i̲v̲e̲ ̲M̲e̲s̲s̲a̲g̲e̲s̲ ̲f̲r̲o̲m̲ ̲M̲D̲Q̲-̲Q̲u̲e̲u̲e̲
A Narrative Message is classified in accordance to the ANO number(s), stored in the message,
and which makes the logical channel structure employed by the SCC Protocol Machine for
the exchange of narrative messages between FIKS and the SCC.
The logical channel No. (CH #) is retrieved by a call to "INNMSG", and is by CPMM&ED
recognized as (ref. 3.3.3.3.2.2.2.1):
o An Inbound Message Channel (from FIKS)
o An Outbound Message Channel (to FIKS)
i) I̲n̲b̲o̲u̲n̲d̲ ̲N̲a̲r̲r̲a̲t̲i̲v̲e̲ ̲M̲e̲s̲s̲a̲g̲e̲s̲
Inbound Narrative Messages are only forwarded to the MSS subsystem, if CPM ̲Operational
̲Mode is active, and are otherwise dequeued from MQD and released.
Inbound Narrative Messages are the following classes:
o Messages for SMF/ACP Conversion
o Messages for SCP/SMF Conversion
o Messages for Transmission to FIKS
The logical channel No. (CH #) returned by "INNMSG" (ref. 3.3.3.3.1.2.1.1) and classifying
the message in the respect, is stored in the message reference (MTCB) which is enqueued
in the respectively MSS queue CQ2, CQ3 or CQ4 for onward processing by the MSS.
(Notice that the receipt of narrative messages is not acknowledged by CPM to SPM until
a message has been transmitted to NICS-TARE or converted and returned to SPM. The CPM
ACK's are actually Performance ̲Acknowledgement).
ii) O̲u̲t̲b̲o̲u̲n̲d̲ ̲N̲a̲r̲r̲a̲t̲i̲v̲e̲ ̲M̲e̲s̲s̲a̲g̲e̲s̲
Outbound Narrative Messages encountered in MDQ are messages, originally received from
the MSS, and enqueued in TQ for tansmission to FIKS, but returned to the MDQ queue by
the NSS because of trunk-error.
These "Stuck ̲Messages" can not be requeued in TQ, but require that special provisions
are made to maintain message continuity. That is taken care of the delivery of the message
to the procedure "Intercept".
These messages must be accounted for by call of the procedure "NMACKP".
