top - metrics - download
⟦22054e7e9⟧ Wang Wps File
Length: 59461 (0xe845)
Types: Wang Wps File
Notes: FIX/1160/PSP/0091 II
Names: »3150A «
Derivation
└─⟦ea7460488⟧ Bits:30006136 8" Wang WCS floppy, CR 0270A
└─⟦this⟧ »3150A «
WangText
/…05….…08….…09….…0d….…02….…06…+…09…+…0a…+…0f…+ *…0a…*…0f…* )…09…)…0e…)…00…)…06…(…0a…(…0b…(…86…1
…02…
…02…
…02…
…0f…3150A/bna…02…FIX/1160/PSP/0091
…02…REV/850301…02……02…#
INTER SCC HANDSHAKING
PROCESSES PSP
…02…Issue 1…02…FK 7809…0e…
---------------------------------------
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 TSA X
T AT X
A A X
T TAS X
E AR X
RT X
-----------------------------------------------
Table 3.3.2.3.2.2.2-6…01…CWDSM Encoding
A5. Outbound CWD…0f…C…0e… Status Report Encoding
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
The Status Report sent from CWD to the collocated
SIP Watch Dog (SWD…0f…C…0e…) contains two parameters:
o Local NICS-TARE Link Status (N/T…0f…C…0e…)
o CWD to SWD…0f…C…0e… State Message.
The N/T…0f…C…0e… is retrieved from NICS-TARE Status Reports
received via the CIP Protocol Machine, and is intended
for the remote SCC Supervisor.
The CWD to SWD…0f…C…0e… State Message is generated from
the CWD State Parameter and contains CIP Operational
Status and the SCC supervisor Requests and Responses
to the SCC Watch Dog/Remote SCC supervisor.
The CWD State Parameters to CWD to SWD…0f…C…0e… State Message
conversion is defined in Table 3.3.2.3.2.2.2-6.
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…0f…R…0e…, 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…, SCC…0f…R…0e… Status)
"ENQUEUE" (PMTCB, CM Queue)
END IF
RETRIEVE (SWD…0f…C…0e… State Message)
'Calculate New State'
STATE: = CSSET STATE (CWDSP, 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 decoded 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 contents 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, which is executed each time
the entry applies. If (-) then no action is
required.
o An asterix (*) in the centerfield indicates
that a CIP Operational Mode change takes place.
B1.2 Action Procedures/Message Texts
A1. BEGIN
"Send NSC-report including SCC…0f…C…0e…- & SCC…0f…R…0e…-states
and possible supervisor-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 response-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 State Event Table is a two dimensional
array, where each element holds a state and
optional 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 described in COSET Narrative Table, Table
3.3.2.3.2.2.2-7B.
Table 3.3.2.3.2.2.2-7A…01…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 a transition 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.
--------------------------------------------------------
Table 3.3.2.3.2.2.2-7B…01…COSET Narratives
--------------------------------------------------------
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.
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.
--------------------------------------------------------
Table 3.3.2.3.2.2.2-7B…01…COSET Narratives
--------------------------------------------------------
Entry Comments
No.
--------------------------------------------------------
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 timeouts, 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)
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 dimensional
array, where its entry holds a state- and/or
a message designator.
State is retrieved 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…01…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… has 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. This 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 in progress.
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 passive state.
20 Invalid state. The CWD has entered transition
from stand-by to active on his own account;
go offline.
--------------------------------------------------------
Table 3.3.2.3.2.2.2-8B…01…CSSET Narratives
--------------------------------------------------------
Entry Comments
No.
--------------------------------------------------------
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.
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 20; also cancel 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. Also cancel request.
31 Please, refer to 19.
32 Please, refer to 20.
33 Supervisor accepted to go active, but too late.
Notify him.
--------------------------------------------------------
Table 3.3.2.3.2.2.2-8B (cont.'d)
--------------------------------------------------------
Entry Comments
No.
--------------------------------------------------------
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 SCC…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 entered active state
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.
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 granted.
46 Transition to stand-by granted, but remote
supervisor or SCC Watch Dog immediately after
that request the supervisor to go active again.
(This must be forwarded to supervisor in state
16).
--------------------------------------------------------
Table 3.3.2.3.2.2.2-8B (cont.'d)
--------------------------------------------------------
Entry Comments
No.
--------------------------------------------------------
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. This 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 initialize 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.
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.3
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 (SUPTIM)
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; 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 is CSKRTIMO.
When SCKRTIM expires a call is made to procedure
SCSKAM to provide for the transmission of the
Keep Alive Message.
SCKRTIM is in turn 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 is TIMRQL.
When REPTIM expires a call is made to procedure
XNSCREP to provide for the transmission of
the NSC-report.
REPTIM is in turn 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 (CSSKRTIM= 0, 'Release KAM'
THEN
CALL "SCSKAM"
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
…86…1 …02… …02… …02… …02…
6. 'COMMAND = Stop SKATIM'
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
Procedure Send CIP/SIP…0f…C…0e… Keep-Alive-Message (SCSKAM)
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲
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)
"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 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
in 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̲i̲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.
Figure 3.3.3.2-1…01…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̲g̲i̲c̲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,
one 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, the
Anti Message will be enqueued at the SPM and await
the arrival of the message and cancel it when it
appears. Messages may arrive in any order at the
active & stand-by SPM.
ACK's from the CPM and Anti ̲Messages from SPM are
piggybacked 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 returns 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. This is done
by CPM alone.
An example is shown in Figure 3.3.3.2-2.
MSG(ID1): For conversion
MSG(ID2): Converted
MSG(NT1): To NICS-TARE
MSG(NT2): From NICS-TARE
Figure 3.3.3.2-2…01…SPM & CPM Message Exchange
SPM immediately ACK's incoming messages on whatever
logical channel they may arrive. CPM on the other
hand recognizes 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.
This makes 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, and 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; they 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 channels 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 damage of 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 N̲M̲P̲M̲ ̲S̲u̲b̲m̲o̲d̲u̲l̲e̲s̲ ̲S̲P̲M̲ ̲a̲n̲d̲ ̲C̲P̲M̲
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 message 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 message for SIP Operational Mode update.
2) AMOS messages 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 to 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
Overview of SPM Environment
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) SPM Timer (SPMTIM)
A visual table of contents is provided in Figure 3.3.3.3.1.1-2.
Figure 3.3.3.3.1.1-2…01…SPM Visual Table of Contents
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 message from SIP Watch Dog
o Timer Interrupt
o Narrative Message from FIKS
o Control Message 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 message 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 message from the SCC, i.e.:
a) Message received from NICS-TARE
b) Message returned from "Message Service",
i.e. a) and b) above
v) Keep Alive Message from:
a) Collocated CIP
b) Remote SIP
The event 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 Monitoring & Control (SPMM&C)
o Outbound Narrative Message Processing (ONMP)
o Inbound Anti Message Processing (IAMP)
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
process is illustrated in Figure 3.3.3.3.1.2.1-1.
1) SWD…0f…R…0e… and CWD…0f…C…0e… Status Reports
2) Timer Interrupt
3) SWD…0f…C…0e… Mode Control Message
4) Inbound Narrative Messages from FIKS & SCC
5) Outbound Anti Messages
6) Outbound Narrative Messages to SCC
7) CPM Acknowledgements
8) Sync Messages
9) Inbound Narrative Messages from SCC to FIKS
Figure 3.3.3.3.1.2.1-1…01…SPM Event-distribution
A1. A̲M̲O̲S̲-̲M̲e̲s̲s̲a̲g̲e̲ ̲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 other events.
SPMOPM may be in one of 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̲
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) SIP…0f…R…0e…-Keep-Alive-Message
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
A SIP…0f…R…0e…KAM always contains a SWD…0f…R…0e… Status Report,
which is retrieved and forwarded 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) CIP…0f…C…0e…-Keep-Alive-Message
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
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 CIP…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 = SIGNAL'
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 ("DMSG, CH #)
END IF
2. 'Inbound Channel'
IF (SPM Operational Mode = Input Active)
THEN
CALL "INMP" (MSG, CH #)
ELSE
Release (MSG, SDQ)
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 Message (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, CH #)
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) contained 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- CH2 Message to NICS-TARE O
I
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…01…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". This 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̲ ̲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 SPMM&C performs the following functions:
o Control of the operational mode of the SIP
Protocol Machine (SPM) as commanded 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 message 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; it 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-sequence number's are cleared and the 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
sequence number updated (channel 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 all unacknowledged
messages are 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 in "Hunt Mode" a received sync sequence
number in 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 sequencenumber,
and when this is found, SPM exits "Sync Mode" and
sets 'Output Active'.
A call is made to "Dispatch Msg" (DMSG 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 SPMTIM (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…C…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 a 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 in the same way by ONMP. This means that
the connection between an outgoing message for
conversion and the corresponding incoming converted
message is n̲o̲t̲ recognized by SPM, but is alone
managed by the CIP-Protocol Machine (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 the "Anti-message" as well as the
messages themself are released (Message/Anti Message).
Otherwise the message is enqueued in the Pending
Message Queue for the 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 called only 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
from 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
delivered 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)
Increment 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̲P̲M̲-̲A̲C̲K̲-̲P̲r̲o̲c̲e̲s̲s̲i̲n̲g̲ ̲ ̲(̲C̲P̲M̲A̲P̲)̲
A. N̲a̲r̲r̲a̲t̲i̲v̲e̲:̲
Procedure CPMAP is called by "SPMED" when a CPM
acknowledgement is encountered. The CH # and MSG
ID designating the message(s) acknowledged are
validated and handed over by SPMED.
CPMAP is called only 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 (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, 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 number (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 conversion, 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)
Create-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; they are sent
from the active SPM whenever 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 roles
played by "Anti Messages" and messages, respectively.
The AMSG is, by a call to "FILTERID" 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 is to detect when a sync
message has failed to appear within a predefined
time interval (SYNTIM preset value TIMSSYN) 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 is 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.8.1
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
employed by the SPM output channels, all with the
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 an element 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, the element's "lifetime" is 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 Messages
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 enqueued in N/M queue by the MSS
4) Command/Response/ACK enqueued in NC queue by MSS.
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 & Control (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).
A visual table of contents is provided in Figure 3.3.3.3.2.1-1.
Figure 3.3.3.3.2.1-1…01…CPM Visual Table of Contents
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 from 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) Command messages 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 Interrupts 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.
1) a) Sync Messages
b) CWD Channel Control
c) MSS Responses/Reports
d) MSS Commands
2) SWD…0f…C…0e… Status Reports
3) Control Messages from NSC to FIKS
4) Outbound Messages from MSS
5) Outbound Messages Returned by NSS
6) SPM…0f…C…0e…- and MSS Acknowledgements
7) Inbound Messages for Message Service
8) Network Report from FIKS to NSC
9) Messages to MSS
Figure 3.3.3.3.2.2.1-1…01…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̲
One type of commands may be issued by CWD to CPM:
o CPM Operational 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 Message, and which forwards commands
to the MSS.
CPM Operational Mode, on the other hand, controls
the message distribution function performed, and
may be in one of 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̲u̲e̲u̲e̲
A narrative message is classified in accordance
to the ANO number(s) stored in the message; it
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 number (CH #) is retrieved
by a call to "INNMSG"; it is by CPMM&ED recognized
as (ref. 3.3.3.3.2.2.1.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̲
Inbound narrative messages are forwarded to the
MSS subsystem, only if CPM Operational Mode is
active, and are otherwise dequeued from MDQ and
released.
Inbound narrative messages are of the following
classes:
o Messages for SMF/ACP Conversion
o Messages for ACP/SMF Conversion
o Messages for Transmission to FIKS
The logical channel number (CH #) returned by "INNMSG"
(ref. 3.3.3.3.1.2.1.1) classifying the message,
is stored in the message reference (MTCB) which
is enqueued in the proper 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̲
Outbound narrative messages encountered in MDQ
are messages, originally received from the MSS,
and enqueued in TQ for transmission to FIKS, but
returned to the MD 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 by delivering the message to the procedure "Intercept".
These messages must be accounted for by call of
the procedure "NMACKP".
