SOC_OPG_v3_23_1

HUGHESNETWORK SYSTEMS LTD

A Hughes Electronics Company

Domestic L-Band Mobile Data Service

OPERATOR GUIDE

System Operator Console

for Telecomunicaciones De Mexico

Reference: A4-OPG-003076

Date: 17th July 2001

Issue: 3.23

Status: Accepted

Hughes Network Systems Limited Telephone +44 1908 221122Saxon Street Facsimile +44 1908 221127Milton Keynes MK14 6LDUnited Kingdom

Copyright Hughes Network Systems Ltd 2001

A4-OPG-003076 System Operator ConsoleIssue 3.23 - Accepted17th July 2001

The contents of this document are proprietary to HNS Limited and cannot be disclosed,duplicated, reproduced or used in part or in whole for any purpose other than in connec-tion with the associated binding contract between HNS Limited and the recipient. Thisrestriction does not apply to information in this document if it is obtainable from anothersource without breach of this notice.

Document Source: TCM TEAM: DOC, TCM LIBRARY: [OPG], TCM VERSION: OPG_V4.0

To generate document: @OPG0

[opg0.mss]

System Operator Console A4-OPG-003076Issue 3.23 - Accepted

17th July 2001


REVISION HISTORY

Issue Status Date Author Change References

3.10a For Review 29-Jan-1998 M.J.Williams SCR568 - New AutobillingReferences to Inmarsat call record tapesremoved for non-Inmarsat customers.

3.10b For Review 13-Feb-1998 M.J.Williams Review comments added.

3.11a For Review 5-Mar-1998 M.J.Williams Four OR text reinstated for Telstra.

3.11 Accepted 18-Mar-1998 M.J.Williams

3.12a For Review 10-June-1998 M.J.Williams SPR 24228 - Stopping PADRSPR 25959 Autobilling file name in existingAMSC formatClarifications added to Autobilling chapterSPR 25961 new CCC - 845 - addedSPR 25994 new MDIR event - 82 - added

3.13a For Review 2-Feb-1999 M.J.Williams Inm CN 126 and CP 127Inmarsat Service Providers.

3.14a For Review 17-Mar-1999 M.J.Williams New billing, CSV o/p,and DNID Tracking addedMinor changes and corrections.

3.14 Accepted 19-Mar-1999 M.J.Williams SOCV diagrams and Chapter 16do not yet fully reflect applied changesWill be updated as soon as possible.Chapters 4 (SOCV diagrams) and 16(New Billing) have now been completed

3.15 Accepted 30-Mar-1999 M.J.Williams 3.13a now accepted as 3.15

3.16a For Review 28-Apr-1999 M.J.Williams SPR20671 - Auto housekeepingfor TelstraNew SUD displays for AMSC

3.16 Accepted 11-June-1999 M.J.Williams Accepted for Telstra

3.17a For Review 21-Sep-1999 M.J.Williams REL80110 - New billingData banner suppressionSPR26092, number of addresses in P/NDN

3.17 Accepted 22-Sep-1999 M.J.Williams Accepted for Italy

3.18a Draft 06-Oct-1999 M.J.Williams REL80111\2New billing for OTEBilling file name changes for Telstra

3.18 Accepted 26-Oct-1999 M.J.Williams Accepted for Italy

3.19a For review 05-April-2000 M.J.Williams REL80120\2


17th July 2001

E-mail and ordered delivery texts added

3.19 Accepted 14-April-2000 M.J.Williams Ordered delivery text reviewed

3.20a For review 23-Aug-2000 M.J.Williams DNID polling alarm

3.20b For review 17-Oct-2000 M.J.Williams FAX modem data re-inserted forTelstra only

3.20 Accepted 27-Oct-2000 M.J.Williams (Customer name changed to Station 12).

3.21a For review 18-Dec-2000 M.J.Williams SPR 26315 - Clarification on use of markersand << in banners (Appendix G)SPR 26322 New MCM event 123’No TDM at NCS’

3.21b For review 12-Feb-2001 M.J.Williams SPR 26313. Extend 26315 to cover FAX

3.21 Accepted 13-Feb-2001 M.J.Williams Review comments added

3.22a For review 27-Feb-2001 M.J.Williams SPR 26333 - Actions to manageVAXoperator log files (Chapter 12)Note referring to this added toPRC event 70 in Chapter 11SUD/SOC descriptions extended for Mexico

3.22b For review 7-Mar-2001 M.J.Williams SUD descriptions re-instated for ItalySignature sheet and early revisionhistories removed.

3.22 Accepted 20-Mar-2001 M.J.Williams Description for XCCC event 33 correctedin chapter 11. Document now issued as’Accepted’. Signatures not required

3.23a For review 21-Jun-2001 M.J.Williams SPR 26376, include descriptions forXCCC event 34-36 in chapter 11.Enable new SUDs for TDM 3.23

Accepted 17-JUL-2001 M.J.Williams

3.24a For review 09-Apr-2002 M.J.Williams SPR 26461, Six new PRC eventsin chapter 11. Customer names updated

3.24 Accepted 24-Apr-2002 M.J.Williams

3.25a For review 25-July-2002 M.J.Williams CN131/134/135 details added forcustomers taking these enhancements.Chapters affected:7, 8, 9 and 11

3.25b For review 12-Aug-2002 M.J.Williams GAB review comments (1-4) incorporatedDoc. now pending final comments from team.

4.0 Accepted 10-Jan-2005 M.J.Franklin CN: 137. Covert Security Alerts

Change bars indicate all changes subsequent to Issue V3.22 of this document


Reporting Issues with this Document

Any errors or omissions found in this document should be reported to HNS by means of aCustomer Service Problem Report (CSPR). This method may also be used to raise any sugges-tions for future releases. The procedure for raising an CSPR is explained in Appendix F of thismanual.


17th July 2001

Referenced and Related Documents

Reference:

1. Inmarsat-C SDMIdentity: Issue: 2.0

2. System ManualIdentity: A4-OMM-003076 Issue: 3.0

3. Channel Unit Operations and Maintenance ManualIdentity: 8016264C Issue: 1.1

4. Billing Tape FormatsIdentity: A4-IFD-003076-7 Issue: 3.3

5. Customer Release Configuration GuideIdentity: A4-SCG-003076-1 Issue: 3.6

6. Zetafax User GuideIdentity: Issue: 3.0


i

Table of Contents

REVISION HISTORY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Reporting Issues with this Document . . . . . . . . . . . . . . . . . . . . . . .

New Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1. INTRODUCTION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-1

2. PRINCIPLES OF THE SOC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-1

2.1. Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-12.2. Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-12.3. Screen Areas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-32.4. Operating System Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-42.5. Use of Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-42.6. Keyboard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-62.7. Implementation of Database Changes . . . . . . . . . . . . . . . . . . . . . . 2-62.8. Processing Time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-82.9. Screen Blanking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-9

3. GUIDE TO THE SOC FORMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-1

3.1. General Structure of the Forms . . . . . . . . . . . . . . . . . . . . . . . . . . 3-13.2. Types of Forms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-13.3. Function Keys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-13.4. Fields on SOC Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-33.5. Help . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-43.6. How to Use a Form . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-43.7. Menu of Forms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-5

4. GUIDE TO THE SOC VIEWER . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-1

4.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-14.2. Format of Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-14.3. Database Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-24.4. Accessing the SOC Viewer . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-34.5. Menu Details : Online Processing . . . . . . . . . . . . . . . . . . . . . . . . 4-34.6. Menu Details : Offline Processing . . . . . . . . . . . . . . . . . . . . . . . . 4-54.7. Use of Control Characters . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-5

5. OPERATOR LOGON/OFF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-1

6. TERRESTRIAL INTERFACES . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-1

6.1. Configuring the Terrestrial Interfaces . . . . . . . . . . . . . . . . . . . . . . . 6-16.2. Structure of the Terrestrial Interface Forms . . . . . . . . . . . . . . . . . . . . 6-16.3. Forms for Trunk Telex Circuits . . . . . . . . . . . . . . . . . . . . . . . . . . 6-26.4. Telex Line Failures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-86.5. PSDN Line Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-86.6. General PSDN Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-106.7. PSDN Line Failures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-126.8. PSTN Interface for Facsimile . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-13

6.8.1. FAX Route SOC Forms . . . . . . . . . . . . . . . . . . . . . . . . . . 6-136.8.2. FAX PC SOC Forms . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-15


17th July 2001

ii

6.8.3. FAX Statistics SOC Forms . . . . . . . . . . . . . . . . . . . . . . . . 6-166.8.4. FAX Banner Configuration . . . . . . . . . . . . . . . . . . . . . . . . 6-186.8.5. FAX Banner Access . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-186.8.6. FAX Banner Formats . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-19

6.9. PSTN Interface for Asynchronous Access . . . . . . . . . . . . . . . . . . . . 6-20

7. SATELLITE INTERFACE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-1

7.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-17.2. LES Forms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-27.3. Satellite Generation Change . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-77.4. Physical Channel Units . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-8

7.4.1. Channel Unit Rack Forms . . . . . . . . . . . . . . . . . . . . . . . . 7-87.4.2. Channel Unit Rack Failures . . . . . . . . . . . . . . . . . . . . . . . . 7-97.4.3. Satellite Loop Delay Detection . . . . . . . . . . . . . . . . . . . . . . 7-107.4.4. Channel Unit Chassis . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-107.4.5. Channel Unit Backplane Failure . . . . . . . . . . . . . . . . . . . . . 7-127.4.6. Physical Channel Unit Forms . . . . . . . . . . . . . . . . . . . . . . . 7-137.4.7. Channel Unit Module Failures . . . . . . . . . . . . . . . . . . . . . . 7-14

7.5. Logical Channel Units . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-147.6. TDM Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-157.7. Spare Pools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-187.8. Spot Beams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-207.9. Changing the Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-20

7.9.1. Changing the Configuration of TDM Groups . . . . . . . . . . . . . . . 7-207.9.2. Adding Channel Units to the System . . . . . . . . . . . . . . . . . . . 7-207.9.3. Logical Channel Unit Addition and Deletion . . . . . . . . . . . . . . . 7-227.9.4. Procedure for Defining and Deleting Sparing Pools and TDM Groups . . 7-24

7.10. Satellite Side Operational Procedures . . . . . . . . . . . . . . . . . . . . . . 7-267.10.1. Channel Unit Startup Sequence . . . . . . . . . . . . . . . . . . . . . 7-267.10.2. Network Failures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-277.10.3. RF Equipment Failure . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-277.10.4. Channel Activity Monitoring . . . . . . . . . . . . . . . . . . . . . . . . 7-277.10.5. Internal Timers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-28

8. MESSAGE HANDLING . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-1

8.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-18.2. How Messages Pass Through the System . . . . . . . . . . . . . . . . . . . . 8-2

8.2.1. Shore to Mobile Messages . . . . . . . . . . . . . . . . . . . . . . . . 8-28.2.2. Mobile to Shore Messages . . . . . . . . . . . . . . . . . . . . . . . . 8-68.2.3. Messages between Inmarsat-C Mobiles . . . . . . . . . . . . . . . . . 8-98.2.4. Address Validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-98.2.5. Presentation Code Validation . . . . . . . . . . . . . . . . . . . . . . . 8-118.2.6. Message Delivery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-118.2.7. Message Cancellation . . . . . . . . . . . . . . . . . . . . . . . . . . 8-128.2.8. Delivery of Messages by Facsimile . . . . . . . . . . . . . . . . . . . . 8-14

8.3. Setting Up the Message Handling Database . . . . . . . . . . . . . . . . . . . 8-148.3.1. Routing Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-148.3.2. Examples of Routing Table Entries . . . . . . . . . . . . . . . . . . . . 8-168.3.3. Routing for Mobile Originated Messages . . . . . . . . . . . . . . . . . 8-188.3.4. Routing for Messages to Mobiles . . . . . . . . . . . . . . . . . . . . . 8-208.3.5. Call Completion Codes . . . . . . . . . . . . . . . . . . . . . . . . . . 8-208.3.6. Alert Routing Strategy . . . . . . . . . . . . . . . . . . . . . . . . . . 8-21


iii

8.3.6.1. Maritime Distress Routing . . . . . . . . . . . . . . . . . . . 8-218.3.7. Land Mobile Alerts . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-228.3.8. Special Access Codes . . . . . . . . . . . . . . . . . . . . . . . . . . 8-238.3.9. Information for Setting Up Special Access Codes . . . . . . . . . . . . 8-248.3.10. Messages to the LES . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-258.3.11. Delivery Notifications . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-25

8.4. How to Find Out About Messages . . . . . . . . . . . . . . . . . . . . . . . . 8-278.4.1. Distress Message Contents . . . . . . . . . . . . . . . . . . . . . . . . 8-278.4.2. Message Status Enquiry . . . . . . . . . . . . . . . . . . . . . . . . . 8-288.4.3. Message Queues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-298.4.4. Message Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-308.4.5. Message Queue Analysis . . . . . . . . . . . . . . . . . . . . . . . . . 8-328.4.6. Call Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-37

8.5. System Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-408.5.1. Text Information SUD . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-408.5.2. Bar Graph SUD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-418.5.3. Call Completion SUD . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-428.5.4. User Interface Response SUD . . . . . . . . . . . . . . . . . . . . . . 8-438.5.5. Queue Counts by Individual Routes . . . . . . . . . . . . . . . . . . . 8-438.5.6. Delivery Rate by Route SUD . . . . . . . . . . . . . . . . . . . . . . . 8-438.5.7. TDM_Summary Display SUD . . . . . . . . . . . . . . . . . . . . . . . 8-448.5.8. Call Count SUD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-448.5.9. Forced Clear Counts SUD . . . . . . . . . . . . . . . . . . . . . . . . 8-458.5.10. Statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-45

8.6. Message Records . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-458.6.1. Online Call Records on SOC Forms . . . . . . . . . . . . . . . . . . . 8-468.6.2. Online Call Record Reports . . . . . . . . . . . . . . . . . . . . . . . . 8-488.6.3. Report Presentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-488.6.4. Message Status Reports . . . . . . . . . . . . . . . . . . . . . . . . . 8-498.6.5. DNID Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-508.6.6. ENID Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-508.6.7. Log File Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-50

8.7. Recovery from Failures in Message Handling . . . . . . . . . . . . . . . . . . 8-508.7.1. Satellite Call Failures . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-518.7.2. Terrestrial X.25 Calls Failing . . . . . . . . . . . . . . . . . . . . . . . 8-538.7.3. All outgoing telex calls failing . . . . . . . . . . . . . . . . . . . . . . . 8-538.7.4. All incoming telex calls failing . . . . . . . . . . . . . . . . . . . . . . . 8-558.7.5. Telex line stuck in retest or bothway busy . . . . . . . . . . . . . . . . 8-55

9. USER SERVICES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-1

9.1. Mobiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-19.1.1. Mobile Life Cycle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-19.1.2. Information Available . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-19.1.3. Defining a Mobile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-49.1.4. Barring of Mobiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-5

9.1.4.1. Barring all the Mobiles . . . . . . . . . . . . . . . . . . . . . 9-59.1.4.2. Unbarring Site Mobiles . . . . . . . . . . . . . . . . . . . . . 9-69.1.4.3. Automating the Barring and Unbarring of Mobiles . . . . . . . 9-6

9.1.5. Maintaining the Mobile List . . . . . . . . . . . . . . . . . . . . . . . . 9-79.2. Management of Registered Users and ISPs . . . . . . . . . . . . . . . . . . . 9-7

9.2.1. Management of General Services for Registered Users . . . . . . . . . 9-79.2.2. Management of EGC Services for Registered Users . . . . . . . . . . . 9-10


17th July 2001

iv

9.2.3. Management of Polling Services for Registered Users . . . . . . . . . . 9-119.2.4. Management of Data Reporting Services for Registered Users . . . . . 9-119.2.5. Management of Mobile Services for Registered Users . . . . . . . . . . 9-12

9.3. Displaying Information Regarding Registered Users . . . . . . . . . . . . . . . 9-129.4. Download of ENIDs and DNIDs to Mobiles . . . . . . . . . . . . . . . . . . . . 9-159.5. Password Update . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-179.6. Superuser Password for the Operator . . . . . . . . . . . . . . . . . . . . . . 9-179.7. Data Reporting File Management . . . . . . . . . . . . . . . . . . . . . . . . . 9-179.8. Performance Verification Tests . . . . . . . . . . . . . . . . . . . . . . . . . . 9-18

10. SYSTEM CONTROL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-1

10.1. Background Applications Processors . . . . . . . . . . . . . . . . . . . . . . . 10-110.1.1. BAP Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-110.1.2. BAP Switchover Process . . . . . . . . . . . . . . . . . . . . . . . . . 10-210.1.3. Manually Controlled BAP Switchover . . . . . . . . . . . . . . . . . . . 10-610.1.4. BAP Failure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-710.1.5. System Time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-7

10.1.5.1. Setting the Time on the VAX Clock . . . . . . . . . . . . . . 10-710.2. Front End Processors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-8

10.2.1. Telex and CU FEP Management . . . . . . . . . . . . . . . . . . . . . 10-810.2.2. Telex and CU FEP Manually Controlled Switchover . . . . . . . . . . . 10-1110.2.3. Telex, CU FEP and DEMSA Failure . . . . . . . . . . . . . . . . . . . 10-1110.2.4. Recommended Dip Switch Settings for On-site FEPs . . . . . . . . . . 10-1210.2.5. DEMSA Management . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-13

10.3. System Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-1310.3.1. Security of Software . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-1310.3.2. Operational Recovery from Disk Failure . . . . . . . . . . . . . . . . . 10-1410.3.3. Security of Online Configuration Data . . . . . . . . . . . . . . . . . . 10-1410.3.4. Online System Checks . . . . . . . . . . . . . . . . . . . . . . . . . . 10-1510.3.5. VMS security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-16

10.4. Alarms and Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-1610.4.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-1610.4.2. Notification of Alarms . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-1710.4.3. Summary Display on the SOC . . . . . . . . . . . . . . . . . . . . . . 10-1710.4.4. Alarm Summary Display . . . . . . . . . . . . . . . . . . . . . . . . . 10-1810.4.5. Event Displays . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-2010.4.6. Action on Receipt of Distress Alarms . . . . . . . . . . . . . . . . . . . 10-2210.4.7. Action on Receipt of Land Alert Events . . . . . . . . . . . . . . . . . . 10-2310.4.8. Action on Occurrence of other Alarms . . . . . . . . . . . . . . . . . . 10-2310.4.9. Event Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-2310.4.10. 10-24

Alarm (or Event) Printer . . . . . . . . . . . . . . . . . . . . . . . . . .10.5. Report Printer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-2510.6. Other Status Indications in the System . . . . . . . . . . . . . . . . . . . . . . 10-2510.7. Reporting Faults . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-2710.8. Test Message Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-2810.9. ACSE Identifier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-2810.10. 10-28

The Operator as a PSDN subscriber . . . . . . . . . . . . . . . . . . . . . . .10.11. 10-29

Access by HNS for Fault Investigation . . . . . . . . . . . . . . . . . . . . . .


v

11. EVENT MESSAGES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-1

11.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-111.2. Event Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-411.3. Call Failures on the Satellite Side . . . . . . . . . . . . . . . . . . . . . . . . . 11-6711.4. Channel Unit Failure Event Filtering . . . . . . . . . . . . . . . . . . . . . . . 11-76

12. OPERATING SYSTEM ACCESS . . . . . . . . . . . . . . . . . . . . . . . . . . 12-1

12.1. Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-112.2. Access Mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-112.3. BAP Operations Facility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-212.4. When to Restart the System . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-412.5. Hardware Initialization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-412.6. Types of Software Startup . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-5

12.6.1. Warm Start . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-512.6.2. Cold Start . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-512.6.3. Monitoring the Progress of Startup . . . . . . . . . . . . . . . . . . . . 12-6

12.7. Stopping a Processor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-612.8. Stopping a System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-612.9. Starting the SOC Terminal . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-612.10. 12-7

Performing a Standalone Backup of a System Disk (BAP or SOC) . . . . . . .12.11. 12-9

Backing up a System Disk Whilst the LES is Still Live . . . . . . . . . . . . . .12.12. 12-10

Disk Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12.12.1. 12-10

Monitoring Disk Status . . . . . . . . . . . . . . . . . . . . . . . . . .12.12.2. 12-11

Disk Failure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12.12.3. 12-11

Disk Space Exhaustion . . . . . . . . . . . . . . . . . . . . . . . . . .12.12.4. 12-11

System Disk Space Exhaustion . . . . . . . . . . . . . . . . . . . . . .12.12.5. 12-11

Operator log files . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12.12.5.1. 12-12

Procedure to manage operator log files . . . . . . . . . . . .12.13. 12-13

Disaster Recovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

13. ONLINE REPORTS AND STATISTICS . . . . . . . . . . . . . . . . . . . . . . . 13-1

13.1. Online Statistics Printouts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-113.2. Online Logfile Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-3

13.2.1. Call Records . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-313.2.2. Distress Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-313.2.3. Event Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-413.2.4. Operator message . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-4

13.3. Online Database Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13-4

14. OFFLINE PROCESSING . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-1

14.1. Functions Performed Offline . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-1


17th July 2001

vi

14.2. Access to the Offline Functions . . . . . . . . . . . . . . . . . . . . . . . . . . 14-214.3. Tapes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-214.4. Disks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-314.5. File Naming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-314.6. Routine Procedures for Processing Offline Records . . . . . . . . . . . . . . . 14-3

14.6.1. Automatic Processing of Offline Records . . . . . . . . . . . . . . . . . 14-914.7. Off-line Database Housekeeping . . . . . . . . . . . . . . . . . . . . . . . . . 14-914.8. Abnormal Processing of Records . . . . . . . . . . . . . . . . . . . . . . . . . 14-914.9. Tape Combining . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-1014.10. 14-11

Log-File List Generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14.11. 14-11

Offline Report Generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14.11.1. 14-13

Statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14.11.2. 14-15

Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14.11.3. 14-15

Distress . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14.11.4. 14-16

Call Records . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14.11.5. 14-20

Default Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

15. OPERATOR CONTROL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-1

15.1. Administration of Operators . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-115.2. Changing Passwords . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15-1

16. GUIDE TO AUTOBILLING . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-1

16.1. INTRODUCTION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-116.1.1. Use of OFDB - precautions . . . . . . . . . . . . . . . . . . . . . . . . 16-1

16.2. FASTER BILLING . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-216.3. AUTOBILLING . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-3

16.3.1. Billing process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-416.3.2. Billing setup procedure . . . . . . . . . . . . . . . . . . . . . . . . . . 16-416.3.3. Billing housekeeping procedure . . . . . . . . . . . . . . . . . . . . . 16-5

16.3.3.1. Lock/Unlock billing . . . . . . . . . . . . . . . . . . . . . . . 16-516.3.4. Account name and password changes . . . . . . . . . . . . . . . . . . 16-6

16.4. Manual Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-716.4.1. Manual billing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-7

16.5. SOCV ACCESS AND BILLING SET UP . . . . . . . . . . . . . . . . . . . . . 16-816.5.1. Autobilling Main menu . . . . . . . . . . . . . . . . . . . . . . . . . . 16-816.5.2. Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-8

16.5.2.1. Autobilling Configuration . . . . . . . . . . . . . . . . . . . . 16-816.5.2.2. CSV File Operation Configuration . . . . . . . . . . . . . . . 16-10

16.5.3. Start Auto billing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-1016.5.3.1. Start times . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-11

16.5.4. Performing the Manual Operations . . . . . . . . . . . . . . . . . . . . 16-1316.5.4.1. Manual Billing . . . . . . . . . . . . . . . . . . . . . . . . . 16-13

16.5.5. Housekeeping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-1416.5.5.1. Housekeeping with no OFDB processing . . . . . . . . . . . 16-1616.5.5.2. Housekeeping with OFDB processing . . . . . . . . . . . . . 16-16


vii

16.5.6. Auto Housekeeping . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-1916.5.6.1. Tape drive precautions during auto housekeeping . . . . . . . 16-2016.5.6.2. Billing start time restrictions . . . . . . . . . . . . . . . . . . 16-2016.5.6.3. Restarting billing . . . . . . . . . . . . . . . . . . . . . . . . 16-20

16.6. FILES UTILISED BY ADVANCED BILLING . . . . . . . . . . . . . . . . . . . 16-2116.6.1. User Journal file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-21

16.6.1.1. Auto Billing User Journal updates . . . . . . . . . . . . . . . 16-2116.6.1.2. Auto housekeeping journal entries . . . . . . . . . . . . . . . 16-2216.6.1.3. Manual billing user journal updates . . . . . . . . . . . . . . 16-23

16.6.2. System Journal file . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-2416.6.3. Carryover files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-24

16.6.3.1. Auto Billing Carry Over files . . . . . . . . . . . . . . . . . . 16-2416.6.3.2. Manual Billing Carry Over files . . . . . . . . . . . . . . . . . 16-25

16.7. ALARMS AND EVENTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-2616.8. OPERATOR PROCEDURES . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-27

16.8.1. Starting billing for first time . . . . . . . . . . . . . . . . . . . . . . . . 16-2716.8.2. Changing configuration parameters . . . . . . . . . . . . . . . . . . . 16-2716.8.3. Changing ’copy’ or ’partner’ node passwords . . . . . . . . . . . . . . . 16-27

16.8.3.1. Auto Billing . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-2716.8.4. Changing Start Time . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-2816.8.5. System backups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-28

16.9. ERROR RECOVERY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-2916.9.1. General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-2916.9.2. Billing has (been) halted . . . . . . . . . . . . . . . . . . . . . . . . . 16-2916.9.3. Autobilling continues, use of manual billing . . . . . . . . . . . . . . . . 16-30

A. EQUIPMENT SWITCH SETTINGS . . . . . . . . . . . . . . . . . . . . . . . . . . A-1

A.1. DEC Equipment Switches . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-1A.2. Channel Unit Equipment Switches . . . . . . . . . . . . . . . . . . . . . . . . A-2A.3. Other Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-3

B. REGISTERED USER DETAILS . . . . . . . . . . . . . . . . . . . . . . . . . . . B-1

C. GUIDE TO USING THE FAX PC . . . . . . . . . . . . . . . . . . . . . . . . . . . C-1

C.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C-1C.2. Taking a Fax PC Out Of Service . . . . . . . . . . . . . . . . . . . . . . . . . C-1C.3. Shutting Down Fax PC Machines . . . . . . . . . . . . . . . . . . . . . . . . . C-2C.4. Installing a New Fax PC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C-2C.5. Starting Up Fax PC Machines . . . . . . . . . . . . . . . . . . . . . . . . . . C-2C.6. Bringing a Fax PC Into Service . . . . . . . . . . . . . . . . . . . . . . . . . . C-2C.7. PC Fax Trouble Shooting Hints . . . . . . . . . . . . . . . . . . . . . . . . . . C-3C.8. Fax PC Software Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C-3

D. GUIDE TO SETTING UP ASYNCHRONOUS COMMUNICATIONS . . . . . . . . . D-1

E. CALL COMPLETION CODES . . . . . . . . . . . . . . . . . . . . . . . . . . . . E-1

F. CUSTOMER SERVICE PROBLEM REPORT . . . . . . . . . . . . . . . . . . . . F-1

G. GLOSSARY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . G-1

Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1


i

List of Figures

2-1 SOC Screen Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-22-2 SOC Keyboard - LA401 . . . . . . . . . . . . . . . . . . . . . . . . . . 2-73-1 SOC Forms Menu Tree 1/2 . . . . . . . . . . . . . . . . . . . . . . . . 3-63-2 SOC Forms Menu Tree 2/2 . . . . . . . . . . . . . . . . . . . . . . . . 3-74-1 SOC Viewer Main Menu . . . . . . . . . . . . . . . . . . . . . . . . . . 4-44-2 SOC Viewer On-Line Processing Menu Tree 1/5 . . . . . . . . . . . . . 4-64-3 SOC Viewer On-Line Processing Menu Tree 2/5 . . . . . . . . . . . . . 4-74-4 SOC Viewer On-Line Processing Menu Tree 3/5 . . . . . . . . . . . . . 4-84-5 SOC Viewer On-Line Processing Menu Tree 4/5 . . . . . . . . . . . . . 4-94-6 SOC Viewer On-Line Processing Menu Tree 5/5 . . . . . . . . . . . . . 4-104-7 SOC Viewer Off-Line Processing Menu Tree 1/3 . . . . . . . . . . . . . 4-114-8 SOC Viewer Off-Line Processing Menu Tree 2/3 . . . . . . . . . . . . . 4-124-9 SOC Viewer Off-Line Processing Menu Tree 3/3 . . . . . . . . . . . . . 4-134-10 SOC Viewer Autobilling Menu Tree . . . . . . . . . . . . . . . . . . . . 4-148-1 Telex Access Mechanisms . . . . . . . . . . . . . . . . . . . . . . . . . 8-38-2 TSAP3 : Telex Registered User Access . . . . . . . . . . . . . . . . . . 8-48-3 TSAP4 : Telex Unregistered Message Status Enquiry . . . . . . . . . . . 8-58-4 Mobile to Shore Message Flow . . . . . . . . . . . . . . . . . . . . . . 8-78-5 Message Delivery cycle . . . . . . . . . . . . . . . . . . . . . . . . . . 8-138-6 Delivery Notifications to Registered Terrestrial Users . . . . . . . . . . . 8-268-7 Ordinary Message Lifecycle . . . . . . . . . . . . . . . . . . . . . . . . 8-358-8 EGC Message Lifecycle . . . . . . . . . . . . . . . . . . . . . . . . . . 8-368-9 Call Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-388-10 Recovery Procedure when Satellite Calls Are Failing . . . . . . . . . . . 8-528-11 Recovery Procedure when X.25 Calls Are Failing . . . . . . . . . . . . . 8-548-12 Recovery Procedures for Failure of Outgoing Telex Calls . . . . . . . . . 8-568-13 Recovery Procedures for Failure of Incoming Telex Calls . . . . . . . . . 8-578-14 Recovery Procedure when Telex Lines Stuck in Retest or Bothway Busy . 8-589-1 Mobile State Life Cycle . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-29-2 Mobile List Display Selection . . . . . . . . . . . . . . . . . . . . . . . . 9-39-3 Registered User Summary Display Selection . . . . . . . . . . . . . . . 9-149-4 Registered User Full Display Selection . . . . . . . . . . . . . . . . . . 9-1510-1 BAP Process State Control . . . . . . . . . . . . . . . . . . . . . . . . 10-310-2 FEP Process State Control . . . . . . . . . . . . . . . . . . . . . . . . . 10-1011-1 Sample Event Printer Output . . . . . . . . . . . . . . . . . . . . . . . . 11-214-1 Offline Database Life Cycle . . . . . . . . . . . . . . . . . . . . . . . . 14-516-1 Housekeeping where OFDB processing is not required . . . . . . . . . . 16-1716-2 Housekeeping where OFDB processing is required . . . . . . . . . . . . 16-18


i

List of Tables

8-1 Destination Networks and Address Extensions . . . . . . . . . . . . . . 8-89-1 Settings used to select NDN and PDN functions . . . . . . . . . . . . . . 9-109-2 Example extract from the Operator Register . . . . . . . . . . . . . . . . 9-1610-1 Master BAP - response to BAPOP SHOW STATE command . . . . . . . 10-410-2 Standby BAP - response to BAPOP SHOW STATE command . . . . . . 10-514-1 Default Report Names, File Names and References . . . . . . . . . . . 14-21


17th July 2001

ii


1

New Features

In V3.23 of the SOC Operator Guide for Teleconunicaciones de mexico

The major changes made and new features introduced since the last issue are:

• Chapter 8 - New SUD form descriptions. (Omitted from 3.22)

• Chapter 11 - New events/notes added. XCCC 34, 35 and 36

Other minor changes may be identified by the change bars.

Introduction A4-OPG-003076Issue 3.23 - Accepted

17th July 2001

2

A4-OPG-003076 IntroductionIssue 3.23 - Accepted17th July 2001

1-1

Chapter 1

INTRODUCTION

This manual describes how the operator can use the System Operator Console (SOC) to controlthe ACSE. The principle tasks performed are concerned with :

• the operation of the ACSE equipment

• the configuration of the terrestrial and satellite interfaces

• control of the mobile and registered user database

• advice to mobiles on the operation of the service

• distress call monitoring

• analysis of system performance

• preparation of billing tapes

The ACSE System Manual describes how the SOC fits into the man-machine interface for controlof the system and has distinguished the functions performed on the SOC from those on theOperating System Console.

This guide is structured as follows :

Chapter 2 outlines how the SOC works, how the display is made up and how the keyboard isused.

Chapter 3 describes the uses and structure of the SOC forms and gives the complete menu offorms.

Chapter 4 describes SOC viewer and gives its menu

Chapter 5 describes operator logon and logoff

Chapter 6 describes the ACSE terrestrial interfaces, showing how these interfaces can bemonitored and controlled.

Chapter 7 describes the ACSE satellite interface, showing how this interface can be monitoredand controlled.

Chapter 8 describes message handling - how the routing through the system is configured andhow address translations are set up. It also describes the reports available and shows howproblems can be investigated.

Chapter 9 describes user services - how to configure mobile and registered users of the system.

Chapter 10 shows how the equipment itself is controlled.

Chapter 11 describes the event messages generated and shows the action which should betaken when an event is reported.

Chapter 12 shows how to access the operating system.

Introduction A4-OPG-003076Issue 3.23 - Accepted

17th July 2001

1-2

Chapter 13 describes the online statistics available.

Chapter 14 describes offline processing, and shows how offline reports are prepared, how back-ups are made for the data collected and how billing tapes are prepared via the offline database.

Chapter 15 describes the SOC forms which can be used for monitoring and controlling SOC formaccess by the operators.

Chapter 16 describes the autobilling process which, though accessed via offline processing, doesnot require access to the offline database.

Appendix A shows the standard switch settings for the equipment. This should be used to en-sure that any replacement equipment is correctly configured.

Appendix B shows the details relating to registered users which must be available before suchusers are added to the system.

Appendix C contains a guide to using the FAX PC interface (where configured)

Appendix D lists the call completion codes.

Appendix E describes how faults are reported to HNS Ltd.

There is an index which can be used to locate required subjects. This is in alphabetical order, butonly for the first 10 characters of each word.

This guide assumes familiarity with the ACSE equipment and a general understanding of the useof DEC processors.

The SOC software must be loaded before it can be used. In normal operation, the equipmentshould be left operational so that it is available whenever needed.

[opg1.mss]

A4-OPG-003076 SOC ScreenIssue 3.23 - Accepted17th July 2001

2-1

Chapter 2

PRINCIPLES OF THE SOC

2.1 Structure

The SOC uses a DEC 4000 series Workstation with a colour (or black and white) monitor andkeyboard, running the Motif windowing system.The displays combine a fixed status summary witha selection of text displays used to show detailed status and to guide the operator to inputparameters on the keyboard.

A mouse pointing device is also provided. This is used to initially select the desired display. It mayalso be used within certain regions of the screen for selection options. Where the mouse has afunction it causes a box to appear round the object pointed at e.g. the message window in theBanner area. To select an option, highlight it and press the left button on the mouse.

2.2 Screen

The SOC screen, as shown in figure 2-1, has a fixed basic structure, onto which a window (orseveral windows) can be called up. The fixed structure is divided into three separate areas asfollows :

• banner to show the time and date, summary alarm status, BAP connection detailsand the latest alarm.

• display area

• function key display

Windows can be created on the screen for interactive operations. Various displays are availableand are called up using mouse and/or function keys. Data can be input using the keyboard. Onlysome of the displays are needed in the day to day operation of the equipment; others are used toset parameters which only need to be changed either infrequently or on initial configuration of theequipment. There are therefore two types of display :

• SOC Forms which allow the operator to view information and, where appropriate,change it online.

• SOC Viewer which is used to display reports and to access the database to makeinfrequent changes. This also acts as the access to the Offline processing functionssuch as reporting and billing tape preparation. In effect, the SOC Viewer gives directaccess to the BAP. This method of access can also be used from a standard DECVT series terminal.

Both of these have different methods of access as described below.

A window is also used to display important system messages concerned with the operation ofthe processors. These appear with a red background and show, for instance:

Date and time - Connection established to BAPB - which is Master

The Motif window is able to contain 5 lines of messages, so that when a new message arrives itcauses the existing messages to scroll up the screen, and removes the sixth oldest message. It isnot possible to delete this window, but it can be shrunk to an icon by positioning the mouse on the

SO

C S

creenA

4-OP

G-003076

Issue 3.23 - Accepted

17th July 2001

2-2 Use this area to open windows:

SYSTEM USAGE DISPLAY

Function Keys

Message Line

Distress

Undelivered Distress

BAP FEP ARB TLX X25 CU SOC ISL NET X400 Other

Urgent

Semi Urgent

Minor

LOGO

LES Identity

Ocean Regions

BAP Connections

Figure 2-1.

SO

C S

creen Structure


2-3

minimize button at the right side of the top boundary box to the window.

2.3 Screen Areas

The Banner area is divided into three parts as shown. On the left, the administration’s logo isdisplayed and time and date shown.

Note: the time and date may be entered by the operator as part of the system start-up sequencefollowing booting up the SOC, but if it differs by more than a few seconds from the time in theMaster BAP, it will take its time from the BAP.

In the centre alarms (described in section 3) are summarized in a matrix, while on the right there isan indication of :

• the ACSE identity

• the ocean regions served - IOR.

• BAP connections - whether or not the BAP is in communication with the SOC - andBAP states - master, standby, idle or unknown.

• The message window which displays in plain text the latest alarm, as soon as it oc-curs. If several alarms occur in quick succession, details can be found in a SOCform. When the mouse points to this area, it is highlighted. If the left button on themouse is pressed, the current message disappears and is replaced by the previousmessage. If there are no more messages to be displayed, the message NoBroadcast Messages Outstanding appears.

Due to the order in which screen update requests are processed by the DEC operating system,the BAP connections and BAP states portion of the Banner area may occasionally display connec-tion messages superimposed.

A refresh of this area can be forced by repositioning it centrally at top of screen at correct size bymoving the window off left hand edge of screen, iconising it and deiconise it again. The windowshould then be repositioned centrally. (See section 2.5 for operations on windows.)

The display area is used to show information selected by the operator, who creates one or morewindows for this purpose. Section 2.5 describes the use of windows. A default display in this areais provided by the System Usage Display which shows occupancy and capacity details of theequipment and is updated every 30 seconds, as described in section 8.5. This display is per-manently available, but can be iconised to remove it from the screen.

The function key icon line of the screen shows functions allocated to the function keys on thekeyboard.

The keys shown consist only of those available for all screens, i.e. Help, Abort/Refresh, Jump,Move, Menu and Main Menu. Functions can only be selected by pressing the appropriate key,except in the case of the Jump and Move keys, where after the list of options is displayed, theoperator uses the mouse to select which form is required.

In addition all the keys specific to the screen are included in the top two lines of that screen.Function keys are only used in SOC Forms, not in the case of SOC Viewer.

SOC Screen A4-OPG-003076Issue 3.23 - Accepted

17th July 2001

2-4

2.4 Operating System Messages

One of the facilities of the SOC workstation is the ability to display messages initiated by theoperating system e.g. DECNET failures. This will result in the top half of the screen being blankedwith SOC windows being forced down the screen. It is possible to return to the original displayusing the

and function keys. Alternatively it is possible when configuring the workstation for thisCTRL F2display not to be automatically given, in which case it is still possible to view operating systemmessages by toggling the said key.

2.5 Use of Windows

The SOC uses Windows, each window supporting a single application, e.g. SOC form or SOCViewer session. The operator can switch backwards and forwards between two or more windowsby using the mouse to point to the desired window and clicking the left button. Note if a windowcompletely covers another window, it must firstly be re-positioned using the Mouse facilities, inorder to access the window being covered.

Note: The mouse pointer could appear to be lost, if moved beyond the edge of the SOC screen.Assuming that the pointer shape has not been changed from the default, which is an arrow point-ing to the top left corner of the screen, dragging the mouse repeatedly from right to left will bringthe pointer back on to the screen.

Before the first window is created the entire screen will be blank, except for a box which containsUsername and Password. The Operator should enter the appropriate values, normally the user-name is SOCSYS with the password initially set to SOCSYS. This will cause a Session Managerwindow to be created. This can be then be iconised. Following the creation of the SessionManager the operator can thereafter create windows.

Note: the Session Manager window must not be deleted as this is required in order to producefurther SOC forms.

To call up a window, position the cursor on the plain background outside any display areas andclick the left button on the mouse. A small window will be displayed showing:

Create SOC form windowCreate new VT200 windowNext SUD displayPrevious SUD displayHold current SUD displayRelease SUD display

The SUD options are described in section 8.5.

Before any SOC application can run the SOC must first be started through Create new VT200window and following the procedure in section 12.9. This will result in the creation of the SOCscreen, as shown in figure 2-1.

The options available are:

Create SOC form window : this causes a window to be created from which the operator is invitedto login to the SOC. Once logged in the operator has access to the SOC forms which are availableto the logged in user. The forms are accessed through a menu structure, detailed in chapter 3.


2-5

Create new VT200 window : this allows the operator to access either of the BAPs in order to runSOC Viewer, which is also accessed via a menu structure, as detailed in chapter 4. This alsoallows the operator access to the SOC System account, needed if the SOC application is notrunning, see section 12.9.

At the top of the SOC form there is a menu bar with a number of symbols. This enables certainoperations for that form. These are supplied as part of the Motif windowing system. An explanationof these symbols is given in the manufacturers handbook which accompanies the SOC.

Note: using key sequences not described in this Operator’s Guide for particular operations shouldeither not be undertaken or undertaken with caution. For example if the "Restart" option from the"Workspace" menu is selected whilst the SOC is running, this could result in the SOC hanging,necessitating a SOC reboot.

So for most interactive operations, the basic access can be represented by

Initial choice (as shown above)||

+-----------------------+| |

Create SOC Create new VT200form window window

| |SOC Forms access SOC Viewer access

| || |

Menu as described in Menu as described inChapter 3 Chapter 4

Up to four SOC form windows can be open simultaneously. The current window is selected bylocating the pointer in the desired window and pressing the left button on the mouse. More thanone SOC Viewer or VT200 window may also be used at a time. It must be noted that the perfor-mance of the workstation will reduce as more windows are opened. The active window on thescreen is the one containing the flashing cursor. All user input will be confined to the windowcontaining the flashing cursor.

Windows can be moved about the screen but should be kept wholly within the outside borders ofthe window area. Windows are moved by using the mouse to select the title bar; keep the buttonon the mouse depressed and move the mouse to drag the window to the desired position on thescreen. A number of facilities specific to the windowing system of the SOC also relate to windowcontrol. For further details of these features refer to the manufacturers handbook which accom-panies the SOC.

Windows can be reduced to icons by pointing the mouse to the minimize button at the right side ofthe top boundary box to the window. The windows are still active but there is no screen output ofthe information, allowing the operator to clear the screen of unwanted displays. It is possible toremove a window permanently using the exit command from the File selection menu on the leftcorner of the second top boundary box. Also, to remove a window used for SOC Viewer orOperating System access, all that is required is to LOGOUT. To restore a window from an icon,select the icon with the mouse and double-click the left button.

Note: the function keys only apply to, and are only operative on, the current window.

The mouse has no function within any SOC form or SOC Viewer window. Once the SOC formapplication is running the mouse can be used to select an option from the "Jump" menu. It should


17th July 2001

2-6

be noted that if a mouse is faulty, it is still possible to use all the commands of the SOC with theappropriate function and cursor keys, as described in the SOC manufacturer’s handbook.

2.6 Keyboard

The keyboard is illustrated in figure 2-2 and consists of

• function keys along the top. to have preset functions and to are usedf1 f5 f6 f20as defined later in this Guide

• "qwerty" keyboard

• cursor movement keys and special keys - of the special keys, only the andHelp Doare usedRemove

• numeric keypad

Special points to note are

• - Hold Screen - key on the top left will freeze the screen and should be used withf1care. The green LED above the key is illuminated as an indication that theF3screen is held. To remove the hold condition, press key again. Do not leavef1Hold enabled while using other keys .

• Where the window contains a number of fields which must be filled in, use the keyswith the arrows towards the right of the keyboard. The key on the left can alsoTabbe used to move to the next field.

• The is used to effect an inputEnter

• To delete an entry, use the key to the top right of the qwerty section.Delete

• If confirmation is requested, this must be positive be entering ’Y’. Just pressingwill be taken as ’N’.Return

• The numeric keypad is not used - use the numbers in the qwerty section instead.

2.7 Implementation of Database Changes

Many interactive operations cause changes in the system’s database and the operator should ap-preciate how those changes are implemented in order to follow the reaction of the system to com-mands.

When a SOC form is selected, some information is usually displayed; more can often be obtained.Fields where information can be entered are highlighted.

The system performs checks on parameters entered via the keyboard. Some parameters arechecked immediately and can be rejected if wrong; the operator is then asked to enter an accept-able value. Checks which require access to the database are only made when all the data isentered. If the checks fail, a message is given to the operator, who must repeat the whole entryprocess.

Once all changes are validated by the system, they become operational as soon as possible.


2-7

Figure 2-2.

SO

C K

eyboard - LA401

newkey.eps


17th July 2001

2-8

When the SOC Viewer is used, the information is obtained from the database in the system.Displays show the latest information at the time of the request. When the SOC viewer is used tomake changes to the database, these changes have to be read into the online system. In manycases this is effected by switching BAPs or restarting the system.

2.8 Processing Time

Because the SOC is a processor in its own right and needs to communicate with the BAPs toobtain data in most cases, it may occasionally take a few seconds to produce the display or, inparticular, to execute a command. During this time, a message is displayed in the same windowadvising the operator that processing is in progress.

The operator should give the system time to work and not enter further commands until theinitial one has been completed. Any subsequent commands are queued up and will be ex-ecuted in turn; the result may be that the operator is unsure of all the actions which have beentaken.


2-9

2.9 Screen Blanking

In order to prolong the life of the screen, it is automatically blanked after a timeout. Touching anykey, or moving the mouse, restores the display. The timeout can be set by the operator (from theSet up Workstation option), but it is recommended that the default setting of 15 minutes beretained.

[opg2.mss]

Guide to the SOC Forms A4-OPG-003076Issue 3.23 - Accepted

17th July 2001

2-10

A4-OPG-003076 Guide to the SOC FormsIssue 3.23 - Accepted17th July 2001

3-1

Chapter 3

GUIDE TO THE SOC FORMS

3.1 General Structure of the Forms

Each form has a name which exists in the title bar at the head of the form and is used in allreferences to the form in the menus, etc.

Fields in a form are used both to display information to the operator and as a vehicle by which theoperator enters information. Some fields are therefore read only; some require an entry andothers can be modified by the operator.

There is some overlap between the information available in different forms to provide a logicaldisplay of related data. There are also cases where control functions appear in more than oneform; this is to allow different levels of access restriction while at the same time linking relevantcontrol fields in an ordered fashion.

3.2 Types of Forms

Forms are categorized as follows :

• Menus show a group of forms which may be selected using the mouse or keyboard.

• Summary Displays show a limited range of details of a number of entities.

• Full Displays show full details about a single entity.

• Definitions show all the parameters for a specific item and can be used to configureall those parameters.

• Management forms are used to change operational states, e.g. in service and out ofservice. An initial state will have been associated with the relevant item using aDefinition form or will have been predefined in the database.

3.3 Function Keys

The function keys are allocated specifically for each form, but the same function is usually al-located to the same key. These functions have the following meanings:

• : to add a new entity with the given parameters to the database, for instance addAdda new circuit.

• : to delete an entity with the given parameters to the database, for instanceDeletedelete an existing circuit.

• (beside the numeric keypad) : confirms and executes the transaction. TheEnterupdated parameters will then, and only then, be operational.

• : to select the first page of a multi-page output, such as alarms.First Page

• : to change the parameters shown in the display. The information must firstModifybe called up using the function.Show


17th July 2001

3-2

• : to select the next page of a multi-page output, such as alarms.Next Page

• : to select the previous page of a multi-page output, such as alarms.Prev Page

• : will show the current state of the entity selected; it is a snapshot of the infor-Showmation held. Once a display is produced, it is not updated even if the relevantparameters in the system database alter. Pressing this key is one way to fetch thelatest data from the database in the BAPs.

The normal sequence of operations is therefore :

• indicate the desired function : press , or as appropriateAdd Modify Show

• enter the new information

• confirm and execute the changes : press Enter

Function keys are assigned to specific functions according to the type of form and the details areshown against each form.

Where they are used, f13 - f20 have the following meaning :

• : Erase field - delete the contents of the current field.f13

• : Previous field - move to the previous field within the form displayed.f14

• : Help - takes the operator into the online Help facility.f15

• : Abort - cancel the request operation and re-enter the current form.f16

• : Jump - brings up the direct access list from which any form may be selected.f17The mouse MUST be used to select one before any other function key is pressed. Ifthe operator decides not to proceed with the change, use the last line Exit from thisMenu to return to the previous form.

• : Move - brings up the Menu window, from which another form may be selected.f18The mouse must be used to select one or EXIT before any other function key ispressed.

• : Menu - go to the menu from which the present form was selected, or the parentf19menu if a menu is currently selected.

• : Main Menu - go back to the top-level menu.f20


3-3

Program function keys - on the right hand side of the keyboard - are used as follows :

• : Gold - combines with another key to perform a specific function.pf1

• : Help - another way of accessing the online help facility.pf2

• : Hardcopy - causes the current form to be printed out (if printer attached).pf4

The following keys on the keyboard are also used in the specific way shown :

• : Moves the cursor to the next field.Down arrow

• : completes the data entry in a particular boxed region of the formEnter

• + : moves the cursor out of a scrolled region to the next fieldpf1 Down arrow

• + : moves the cursor out of a scrolled region to the previous fieldpf1 Up arrow

• : moves the cursor one position to the left within the current fieldLeft arrow

• : moves the cursor to the next fieldReturn

• : moves the cursor one position to the right within the current fieldRight arrow

• : moves the cursor to the next fieldTab

• : moves the cursor to the previous field.Up arrow

• : has the effect of refreshing the SOC screen display.Ctrl-w

Several keys are not used for any forms; if pressed the bleeper will sound.

For certain SOC forms not all of a display can be seen on a single screen. The operator canhowever access the data in those fields which are not visible by scrolling down and up the displayusing the and keys.Down arrow Up arrow

3.4 Fields on SOC Screen

Each field in a form has a specific maximum size and can only accept defined characters. Also, inmany instances checks are made that only a limited range is accepted.

Avoid using the "’" character when modifying fields which are part of the SOC display as this mayproduce errors in the Sybase data server which may lead to corruption of data.

Date fields use the format ’DD-MMM-YYYY hh:mm:ss’, where :-

DD Day (1..31),MMM Month (JAN,FEB,MAR,APR,MAY,JUN,JUL,AUG,SEP,OCT,NOV,DEC),YYYY Year (1901..2099),hh hours (0..23),mm minutes (0..59),ss seconds (0..59).


17th July 2001

3-4

3.5 Help

Help is available at successive levels. Pressing the key the first time displays information onHelpthe current field in the system response line. A second press of the displays a help formHelpcorresponding to the current form. Pressing help a third time gives general help information. Afinal press of the key returns the operator to the form which is being worked on. Note that select-ing brings up a fixed text and therefore advice on any selections possible is not tailored toHelpparticular applications; for instance when selecting an ocean region, the help screen will presentall possible ocean regions rather than the ones served by the LES.

3.6 How to Use a Form

The operator selects the desired form from a menu by pressing the appropriate function key.

The form is then displayed and, if necessary, the operator should enter in any compulsory fieldsand then press the key. If more than one page of information is available, ,Show First Page

and keys are available to scan through the pages. In some cases, morePrev Page Next Pageinformation is available by using the and keys.Up Arrow Down Arrow

For new entries, use the to check that there is no existing entry, press the key andShow Addenter the details in the each section of the form in turn. Press the when all the details areEntercorrect; the data will then be transferred to the system database.

Where it is desired to modify information, the existing data should be called up with the .ShowPress the key, enter the new data and then press the key, which is needed to bringModify Enterthe revised configuration into use.

The system performs checks on the data entered by the operator. Where an entry is rejected, thereason is shown on the form.

Should the operator wish to terminate a transaction without effecting a change, the key canAbortbe used, where this is provided.

The operator can return to either the main menu or the menu immediately higher in the structureusing function keys 19 (where appropriate) and 20 for the main menu. The andJump Movekeys can also be used to access the complete list of forms.

Many forms have a one or more selection fields which qualify the information displayed. Somemust be filled in, for example where there is an action to be performed, but others can be leftblank, for example where a display is being called up. In general, the display will appear quicker ifthere are fewer qualifications entered since each qualification adds to the time taken to processthe selection.


3-5

3.7 Menu of Forms

The full SOC Form menu structure is shown in figures 3-1 and 3-2.The function keys to makeselections are included. Where a function key is in parenthesis () then the following form will beselected from a SOC form rather than a menu. The initial selection of forms from the Main Menuconsists of the following :

• Operator Logon for the operator to log on and off the system

• Terrestrial Interfaces for the control of interfaces such as telex and X.25

• Satellite Interfaces for control of the channel units

• Message Handling for information on routing, address control and messaging.

• User Services for registered and mobile user details.

• System Control for equipment control, alarms and events.

• Operator Control for monitoring and controlling operator SOC form access.

[opg3.mss]

Guide to the S

OC

View

erA

4-OP

G-003076


17th July 2001

3-6

Terrestrial Interfaces Menu

Satellite Interface Menu

User Services Menu

Main Menu

Operator LogonTerrestrial Interfaces MenuSatellite Interface MenuMessage Handler MenuUser Services MenuSystem Control MenuOperator Menu

Refer toOnline Processing

Menu Tree 2/2

Special Access Code MenuRegistered Users MenuMobile Users MenuData Reporting Menu

Data Reporting Menu

Special Access Code Menu

Registered Users Menu Mobile Users Menu

Message Handler Menu

System Control MenuOperator Menu

Message Routing andDestination Menu

Message Details Menu

Message Display Menu

Data Report File DisplayData Report File Management

Special Access Code DisplaySpecial Access Code Route DefinitionSpecial Access Code Function DefinitionSpecial Access Code Address Definition

Registered User DisplayRegistered User DefinitionRegistered User EGC DefinitionRegistered User Polling DefinitionRegistered User Data Report Definition

Mobile DefinitionMobile ManagementMobile List ManagementTest Mobile DefinitionInitiate PVT Test

Message Routing and Destination MenuCall Record Summary DisplayMessage Details MenuMessage Display Menu

BAP ManagementFEP ManagementDEMSA ManagementAlarm Summary DisplayEvent Summary Display

Change PasswordOperator DefinitionOperator DisplayAccess Group Definition

Terrestrial Routing DisplayTerrestrial Routing DefinitionLand Mobile Alert Destination DisplayLand Mobile Alert Destination DefinitionMaritime Distress Destination Definition

Message Details Summary DisplayMessage Queue Summary Display

Message Status Summary DisplayDistress Message Summary Display

Call Record Full ICR Display

Call Record Full DCR Display

Message Details Full GeneralDisplay

Message Details Full Specific Display (DN, EGC, Poll, DR)

Message Status Full Display

Distress Message Full Display

Alarm Management

Event Full Display

Refer toOnline Processing

Menu Tree 2/2

Figure 3-1. SOC Forms Menu Tree 1/2

[scmex1.eps]

A4-O

PG

-003076G

uide to the SO

C V

iewer


17th July 2001

3-7

SCMEX.VSD

From Main Menu Satellite General Menu

Satellite Parameter Definition Spot Beam Definition Satellite Reattempt Table

Satellite Station Menu

LES Definition LES Management LES Summary

Satellite Equipment Menu

Channel Unit Rack Management Channel Unit Rack Status Summary Channel Unit Rack Chassis Definition Channel Unit Rack Chassis Status Summary Channel Unit Rack Summary

Satellite Physical Channel Menu

Physical Channel Unit Definition Physical Channel Unit Management Channel Unit Spare Pool Definition Channel Unit Spare Pool Status Summary

Satellite Logical Channel Menu

Msg Rx Logical Channel Unit Definition Sig Rx Logical Channel Unit Definition TDM Rx Logical Channel Unit Definition TDM Tx Logical Channel Unit Definition

Terrestrial Interface Menu

Telex Trunk Menu TNIC Menu Telex Reattempt Menu X25 Line Management X25 Reattempt FAX Menu

Telex Trunk Menu

Telex Trunk Circuit Display Telex Trunk Circuit Definition Telex Trunk Circuit Management Telex Trunk Management

TNIC Menu

TNIC Display TNIC Definition

FAX Menu

FAX Route Display FAX Route Definition FAX Route Management FAX PC Display FAX PC Definition FAX PC Management FAX Route Statistics FAX PC Statistics FAX Modem Statistics

Satellite TDM Group Menu

TDM Group Definition TDM Group Management TDM Group Summary

Satellite Interface Menu

Satellite General Menu Satellite Station Menu Satellite Equipment Menu Satellite Physical Channel Menu Satellite Logical Menu Satellite TDM Group Menu

Figure 3-2. SOC Forms Menu Tree 2/2

[scmex2.eps]

Guide to the SOC Viewer A4-OPG-003076Issue 3.23 - Accepted

17th July 2001

3-8

A4-OPG-003076 Guide to the SOC ViewerIssue 3.23 - Accepted17th July 2001

4-1

Chapter 4

GUIDE TO THE SOC VIEWER

4.1 Introduction

The SOC Viewer provides access to the database in the ACSE to set some configuration data andto obtain reports from the log file.

The SOC Viewer has two basic modes of operation, as shown in Figure 4-1:

• online access to the system to view the real time operation and access the database.

The menu structure for online access is shown in Figures 4-2, 4-3, 4-4, 4-5 and 4-6.

• offline access for post processing of data for reports and billing.

The menu structure for offline access is shown in Figures 4-7, 4-8, and 4-9.

Two database access methods are provided to the online system:-

• Reports show fixed details for a particular subject and are equivalent to the ’display’class of forms. The operator enters a set of selection parameters and the related in-formation is fetched from the database or log files and displayed.

• Database Access is used to input new configurations into the database and can alsodisplay the related information already contained in the database. For new orchanged data, the operator enters inputs against a string of prompts. These are thenentered into the database after passing validation checks.

Some software processes read the data directly from the database whenever it isused, and in these cases updates are effective immediately. Other processes readfrom the database on initialization only, and in such cases changes are implementedwhen the online software is restarted or as a result of switchover.

Warning: Except in the case of Call Completion Code and Event definitions, when-ever SOC Viewer options are invoked which arise from the Database Access Menu ,(see Figures 4-3, 4-5 and 4-6), which also result in a change to the database con-figuration, a BAP switchover or system restart will be needed for the changes to be-come fully effective.

Changes not involving the Database Access Menu will come into effect immediately.

The online options from the SOC Viewer menu can only be accessed from the Master BAP, whilstthe offline options will be available from both Master and Standby BAPs, although a warning willbe given whenever an offline option is invoked from the Master BAP. It is recommended that of-fline options be invoked from the Standby BAP in order to cause minimum degradation in perfor-mance to the online system.

4.2 Format of Reports

Reports can be generated either as part of online processing or offline processing. The followinggeneral points apply to reports generated as part of online processing:

For many reports, qualifiers, such as a circuit number, must be entered. The operator should

Guide to the SOC Viewer A4-OPG-003076Issue 3.23 - Accepted

17th July 2001

4-2

enter the value and press or, if no qualifier is required, just press . Each qualifierReturn Returnappears separately on the screen, in turn. Once a choice has been made and pressed, itReturncannot be altered, although it is visible on the screen. If the operator decides that he has madethe wrong choice, he should return to the menu and select the report again. It is useful to make adouble check that all the selections are correct.

Some reports cannot be fitted into the screen; in these cases, they are paged and the display canbe scrolled using the and keys to be found on the right-hand side ofPrev Screen Next Screenthe keyboard.

Options generally exist whereby reports are displayed or can be sent to the Report Printer onrequest. Qualifiers shown at the top of each report.

When a report has been inspected, press .f10

4.3 Database Access

Database access using SOC Viewer is arranged in a similar way to SOC Forms, with a menustructure for successive choices to reach the desired function. However, it is only possible to goup and down the menu tree, not to jump directly from one function to another.

Once the desired subject has been selected, the operator is then given as choice of actions suchas :

M Modify

A Add

D Delete

S Show

X Exit

The operator should enter the selection and press .Return

Selecting Show gives a display of all the relevant parameters.

Selecting Modify brings up each line of the display in turn. The operator can either :

• retain an existing entry by simply pressing orReturn

• enter a new value and then press .Return

Help is available at all stages, showing the entry options available.


4-3

4.4 Accessing the SOC Viewer

Access is via the VT200 option on the SOC pop up menu. Select Create a new VT200 Windowwith the mouse and press on the left button of the mouse. A prompt for a username is given; theresponse required is

Welcome to SOC Viewer

Username : SOCV

The display changes to

Which node do you require?((M)aster, (S)tandby,BAP(A),BAP(B) or F10 to exit) [M]:

The default selection is Master, as indicated by the [M] above. If an invalid selection is entered,the user is advised and asked again for the selection.

Choose the Master for all online processing and, in normal circumstances, choose the Standby foroffline processing. However, ’offline’ processing can also be performed on the master but, if thismode is used, performance will be degraded. A warning appears on the screen if this is at-tempted. Online processing cannot be performed on the standby and any attempt to select onlineprocessing on the standby will be rejected.

The welcome banner is then presented with the date and time of last logon; this changes to thetop level menu selection as shown in figure 4-1, after a few seconds.

The user should make a selection by number or use to return to the parent of the current menuEor to return to the top level of the menu and then press on the keyboard.M Return

The user may also access the SOC viewer on either of the BAPs. The procedure is the same asfor the SOC access, except the username is BAPV . The operator must also ensure that thedesired BAP is being accessed, as there is no prompt for the node.

Online Processing gives access to the data currently held in the system. It allows the operator tomanage the alarm printer and move data files between the database, the hard disk and tape and itsets the parameters for statistics collection. The menu is shown in figures 4-2, 4-3, 4-4, 4-5 and4-6.

Offline Processing is used to manage the closed log files and to abstract data from them. It isalso used for the preparation of billing tapes and, where applicable, call record tapes. The menuis shown in figures 4-7, 4-8 and 4-9.

When Exit is selected, the operator is taken one step back up the menu tree. At the top level, thechoice is to exit SOC Viewer, and the user will be asked to confirm this choice. Answering Yes willresult in the terminal window being logged out and deleted.

4.5 Menu Details : Online Processing

Within the online processing the following selections can be made

• run reports can be obtained showing selected information from the database. This ispresented in the form of a scrolling window. The information for these reports is ob-

Guide to the S

OC

View

erA

4-OP

G-003076


17th July 2001

4-4

Main MenuLevel 0

1. Online Processing2. Offline Processing3. Exit

1

2

Online Processing MenuLevel 1

Refer toOnline Process ing

Menu Tree 1/4

Offline Processing MenuLevel 1

Refer toOff line Process ing

Menu Tree 1/3

1

2

Figure 4-1. SOC Viewer Main Menu

[svmain.eps]


4-5

tained from the online system, from the logfiles which are currently open.

• log file management of the log files which collect data from the online software

• alarm printer management controls the alarm printers.

• database management provides means to dump the database to disk and to backupa dump to tape.

• statistics reports management controls the parameters used to produce statisticsreports. Statistics output is in the same form as log file reports.

• statistics reports print management which controls the printing of reports

• database access for inspecting and making changes to the database.

• message handler management to provide a dynamic display of the status of allmessages in and out of the LES.

• X.25 access to enable X.25 access to the LES.

The menus are shown in Figures 4-2, 4-3, 4-4, 4-5 and 4-6. Note that where processor restart isnecessary, the selection is shown in shaded characters. Parameters can be viewed at any time.

OTC_SVONL1.EPS;1

4.6 Menu Details : Offline Processing

Offline processing is a background task which manages and accesses closed log files. Its usesinclude the preparation of billing record tapes and statistical analysis of traffic in the system.

When selection criteria is prompted for off-line reports, default values are often displayed. This isindicated in the menu diagrams with inclusion of a colon.

The menus are shown in Figures 4-7, 4-8, and 4-9.

4.7 Use of Control Characters

Warning: It is best to restrict use of control codes whilst in SOC Viewer to those which have aspecified use, e.g. . Avoid using the key, unless exiting from an editor, since itReturn Ctrl-zcould give rise to undesirable effects, such as aborting software programs and transferring controlup a level or two in the menu tree.

[opg4.mss]

Operator Logon/off

A4-O

PG

-003076Issue 3.23 - A

ccepted17th July 2001

4-6

Online Menu - Level 1

1. Run Reports 2. Log File Management 3. Alarm Printer Management 4. Database Management 5. Statistics Report Print Management 6. Statistics Report Print Management 7. Database Access Menu 8. Message Handler Management 9. X25 Access E. Exit

Reports Menu - Level 2

1. Run Online Database Reports 2. Run Online Log File Reports 3. Run Online PADR Reports 4. Run Online CRM Log File Reports M. Return to Main Menu E. Exit

LFM Management

1. Close The Current Log File 2. Show Directory of all Logfiles on Disk 3. Show Summary of Logfile Disk Usage 4. Exit

Online Database Reports Menu - Level 3

1. Trunk Telex Route Display 2. Subscriber Telex Route Display 3. Message Status Report 4. DNID Report 5. ENID Report 6. Country Code Display 7. PVT Results Report 9. More Options [Page 2 of 3] M. Return to Main Menu E. Exit


1. X25 Route Display 2. X25 Line Display 3. X25 Channel Display 4. X400 Address Translation Display 9. More Options [Page 3 of 3] M. Return to Main Menu E. Exit


1. Address Extension Display 2. Ocean Region Address Display 3. Call Completion Call Display 4. Mobile List Display 5. Registered User Full Display 6. Registered User Summary Display 7. Inmarsat MES Status Report 9. More Options [Page 1 of 3] M. Return to Main Menu E. Exit

Online Log File Reports Menu - Level 3

Refer to Menu Tree 3/5

Alarm Print Management

1. Suspend Printing 2. Resume Printing from point of print suspension 3. Resume Printing from end of log 4. Display printer states 5. Take distress monitor offline 6. Put distress monitor online 7. Put distress monitor online from a given time 8. Exit

Database Management - Level 2

1. Directory of Archives 2. Archive Database Configuration 3. Restore Database Configuration 4. Copy Archives To Tape 5. Copy Archives From Tape 6. Delete Archives M. Return to Main Menu E. Exit

PADR Not supported on this system

Database Access Menu - Level 2

Refer to Menu 2/5

Statistics Reports Management

1. Set a single component statistics logging interval 2. Set all components statistics logging intervals 3. Switch off statistics logging for a component 4. Switch off statistics logging for all components 5. Display statistics logging intervals 6. Log all component statistics 7. Log named components statistics X. Exit

Statistics Report Print Management

1. Display all statistics report names and print states 2. Set a single statistics report print state 3. Set all statistics report print states X. Exit

1

1

1

1

2

2

2

2

3

3

3

3

4

4

5

5

6

6 7

7

9

9

9

9

9

9

Figure 4-2. SOC Viewer On-Line Processing Menu Tree 1/5

[svonl1.eps]

A4-O

PG

-003076O

perator Logon/offIssue 3.23 - A


4-7

Database Access MenuLevel 2

Telex Database Access MenuLevel 3

X25 Database Access MenuLevel 3

X400 Database Access MenuLevel 3


Message Handler Database Access Menu - Level 3

User Service Database Access Menu - Level 3


1. Telex Database Access2. X25 Database Access3. X400 Database Access4. Message Handler Database Access5. User Services Database Access6. FAX Database AccessM. Return to Main MenuE. Exi t

1. X25 General Definition2. X25 PAD Parameters Definition3. X25 Reattempt Table4. X25 Route Definition5. X25 Line Definition6. X25 Channel DefinitionM. Return to Main MenuE. Exit

1. Ocean Region Address Definition2. NDN Spi l l -Out Destination Definition3. Country Code DefinitionM. Return to Main MenuE. Exit

1. ACSE ID Defin ition2. Cal l Completion Code Definition3. Event Definition4. Inmarsat-C Timeout Entry Defini tion5. Inmarsat-C Constant Entry Definition6. Mobi le Deletion7. Change Superuser PasswordM. Return to Main MenuE. Exi t

ACSE ID Def in it ion Menu

Call Completion Code Def Menu

Event Defin it ion

Inmarsat-C Timeout Ent ry Defn Menu

Inmarsat -C Cons tan t En t r y Defn Menu

S. Show the ACSE IDM. Modify the ACSE IDX. Exi t Menu

S. Show the Cal l Status Text for a CCCM. Create / Update the Call Status Text for a CCCX. Exi t

S. Show database entryM. Modi fy database entryX. Exi t Menu

S. Show Database EntryM. Modi fy Database EntryX. Exi t Menu

S. Show Database EntryM. Modify Database EntryX. Exi t Menu

Ocean Region Address Defin ition Menu

NDN Spil l-Out Dest Def init ion Menu

Count ry Code Defin it ion Menu

A. Add database entryD. Delete database entryS. Show database entryM. Select entry with matchU. Modify database entryX. Exi t

S. Show database EntryX. Exi t Menu

S. Show NDN AddressM. Modi fy NDN AddressX. Exit Menu

X25 Route Def in it ion Menu

S. Show Database EntryA. Add Database EntryM. Modify Database EntryD. Delete Database EntryX. Exi t Menu

A. Add database entryD. Delete database entryS. Show database entryM. Modi fy database entryX. Exi t Menu

X25 Channel Defin it ion Menu

A. Add database entryD. Delete database entryS. Show database entryX. Exi t Menu

X25 L ine Def in i t ion Menu

X25 General Def in it ion Menu

X25 Profi le Def ini t ion Menu X25 In teractive PAD Para Definit ion

S. Show X25 Detai l sM. Modi fy X25 Detai l sX. Exi t Menu

I. Show/Modify Interactive PAD Profi le TableF. Show/Modify Fi le Transfer PAD Profi le TableX. Exit Menu

S. Show PAD Profi le TableM. Modify PAD Profi le Table

12345

543

21

5

4

3

2

1

1

3

1

2

3

3

4

5

3

5

6

54

3

1 I

F

2

1

22

F ro mOnl ineMe nuLevel 1

2

FAX Database Access MenuLevel 3

1. Add a new FAX Banner defin ition2. Modify an existing FAX Banner defin ition3. Delete an existing FAX Banner defin ition4. List Al l existing FAX Banner defini tionfi lesM. Return to Main MenuE. Exi t6

6

6

4

X25 Reat temp t Tab le Men u

S. Show table entryM. Modi fy table entryX. Exit menu

X25 Fi le Transfer PAD Para Def in it ionS. Show PAD Profi le TableM. Modify PAD Profi le Table

7

Mobile DeletionM. Delete Mobile From DatabaseX. Exit

6

6


[svonl2.eps]

Operator Logon/off

A4-O

PG

-003076Issue 3.23 - A


4-8

Online Log File Reports MenuLevel 3

Report Viewing Menu - Level 4

View Log File Reports - Level 4

1. Summary Message Report2. Summary Statistics Report3. LES to Mobile Message Report4. Mobile to LES Message Report5. Poll Message Report6. EGC Message Report7. DNID Retrieval Message Report8. Data Report Report9. DNID Handler Report10. Distress Report11. Events Report12. Operator Message Report13. More Options [Page 2 of 2]E. Exit

1. Grade of Service Report2. Mobile Login/Logout Report3. More Options [Page 1 of 2]E. Exit

1. Generate Log File Reports2. Print Log File Reports3. View Log File ReportsM. Return to Main MenuE. Exit Call Record Reports Menu

Report Process Main Menu

Report Process Printing Menu

1. Summary and Statistics Message Report2. LES to Mobile Message Report3. Mobile to LES Message Report4. Poll Message Report5. EGC Message Report6. DNID Retrieval Report7. Data Report Report8. DNID Handler Report9. Mobile Login/Logout Report0. Exit Menu

C. Generate Report on Call RecordsD. Generate Report on Distress MessagesE. Generate Report on Event MessagesG. Generate Report on Grade of ServiceO. Generate Report on Operator MessagesX. Exit Report Process

A. Print RP Summary Report B. Print RP Summary Stats Report C. Print LES to MES ReportD. Print MES to LES ReportE. Print Poll ReportF. Print EGC ReportG. Print Data Retrieval ReportH. Print Data Report ReportI. Print DNID Handler J. Print Distress Message ReportK. Print Event Message ReportL. Print Operator Message ReportM. Print Grade of Service ReportN. Print Mobile Login/Logout ReportX. Exit

33

13

13

3

2

1

1

C

C3

FromReports Menu

2

2

Level 2

:


[svonl3.eps]

A4-O

PG

-003076O



4-9

Telex Database Access MenuLevel 3

1. Telex Leased Line Database Access2. Telex Subscriber Signalling Database Access3. Telex Trunk Database AccessM. Return to Main MenuE. Exit

Telex Subscriber Signalling Database MenuLevel 4

Telex Trunk Database AccessLevel 4

1. Telex Trunk DefinitionM. Return to Main MenuE. Exit

Telex Trunk Route Definition

A. Add database entryD. Delete database entryM. Modify database entryS. Show database entryX. Exit Menu

Telex LL Database Access MenuLevel 4

Telex LL Definition

Telex LL Route Definition

Telex LL Circuit Definition

1. Telex LL Definition2. Telex LL Route Definition3. Telex LL Circuit DefinitionM. Return to Main MenuE. Exit

Not yet available



21

123

12

3

From DatabaseAccess Menu

1

Level 2

1. Telex Subscriber Signalling Definition2. Telex Subscriber Signalling Route Definition3. Telex Subscriber Signalling Circuit DefinitionM. Return to Main MenuE. Exit

Telex Subscriber Signalling Definition

S. Show the DVR SCVFM. Modify the DVR SCVFX. Exit Menu

3

3

1

1

Telex Subscriber Signalling Route DefnA. Add database entryD. Delete database entryM. Modify database entryS. Show database entryX. Exit

Telex Subscriber Signal Circuit Defn

A. Add database entryD. Delete database entryM. Modify database entryS. Show database entryX. Exit

2

3

2

2

3

1

1

1

NOTE:= BAP SWITCHOVER OR RESTART REQUIRED TO EFFECT CHANGE


[svonl4.eps]

Operator Logon/off

A4-O

PG

-003076Issue 3.23 - A


4-10

X400 Database Access Menu

1. X400 Parameters2. X400 Route Definition3. X400 Mailbox Definition4. X400 Mailbox Management5. X400 Address Translation DefinitionM. Return to Main MenuX. Exit

From DatabaseAccess MenuLevel 2

X400 Parameters MenuS. Show X400 DetailsM. Modify X400 DetailsX. Exit Menu

X400 Route Definition MenuA. Add X400 Route DetailsD. Delete X400 Route DetailsS. Show X400 Route DetailsM. Modify X400 Route DetailsX. Exit Menu

X400 Mailbox Definition Menu

A. Add X400 Mailbox DetailsD. Delete X400 Mailbox DetailsS. Show X400 Mailbox DetailsM. Modify X400 Mailbox DetailsX. Exit Menu

X400 Mailbox Management MenuM. Modify X400 Mailbox DetailsS. Show X400 Mailbox DetailsX. Exit Menu

X400 Addr Trans Definition Menu

A. Add X400 Addr TransD. Delete X400 Addr TransS. Show X400 Addr TransM. Modify X400 Addr TransX. Exit Menu

12345

1

2

3

4

5

3

NOTE:= BAP SWITCHOVER OR RESTART REQUIRED TO EFFECT CHANGE


[svonl5.eps]

A4-O

PG

-003076O



4-11

Offl ine Processing MenuLevel 1

Defau lt Processing MenuLevel 2

Options MenuLevel 2

Housekeep ing MenuLevel 3

Offline Database Loader MenuLevel 3

Bi l l ing Data Generation MenuLevel 3

Lists Generation MenuLevel 3

Logfile Util it ies MenuLevel 4

Database Ut il it ies MenuLevel 4

Report Ut ili t ies MenuLevel 4

List Uti li t ies MenuLevel 4

Report Generation MenuLevel 3


1. Default Processing Menu2. Options Menu3. Start Offline Database Server4. Stop Offline Database ServerE. Exit

1. Housekeeping2. Database Load3. Bill ing Data Generation4. Report Generation5. Lists GenerationM. Return to Main MenuE. Exit

1. Log File Utilities2. Database Utilities3. Report Utilities4. List UtilitiesM. Return to Main MenuE. Exit

1. Do Default Housekeeping2. Do Default ProcessingM. Return to Main MenuE. Exit

1. Directory of Logfiles in Offline Area2. Delete Logfiles from Offline Area3. Archive Logfiles from Offline Area4. Restore Logfiles to Offline Area5. Directory of Logfiles in Online Area6. Copy Logfiles from Online to Offline Area7. Delete Copied Logfiles from Online Area 8. View Logfile Disk UsageM. Return to Main MenuE. Exit

1. Modify Logfile Specification 2. Modify Load Calls 3. Modify Load Distress4. Modify Load Events5. Modify Load Statistics6. Modify Load wi th CarryoverR. Run LoaderM. Return to Main MenuE. Exit

1. Generate Customer Billing Tape2. Generate Inmarsat Call Data Report Records Tape3. Generate and Mail EDIFACT Ticket4. Combine tapes5. Generate Customer Bill ing on Disk6. Automatic Bill ing7. Combine Disk FilesM. Return to Main MenuE. Exit

1. List Log File2. List Customer Billing Tape3. List Customer Billing Disk File4. List Inmarsat Call Data Report Records tapeM. Return to Main MenuE. Exit

1. Archive Offline Database2. Restore Offline DatabaseM. Return to Main MenuE. Exit

1. Directory of Reports2. View a Specific Report3. Print a Report4. Delete a ReportM. Return to Main MenuE. Exit

1. Directory of Lists 2. View a Specific List3. Print a List 4. Delete a ListM. Return to Main MenuE. Exit

From Main Menu

12

54

1

2

1

2

3

4

1

3

5

4

1

2

3

1

2

3

4

2

Level 0

::::::

Figure 4-7. SOC Viewer Off-Line Processing Menu Tree 1/3

[svofl1.eps]

Operator Logon/off

A4-O

PG

-003076Issue 3.23 - A


4-12

Report Generation MenuLevel 3

Distress Summary ReportLevel 4

Event Log ReportLevel 4

Call Record Reports MenuLevel 4

1. Default Reports2. Statistics Reports3. Call Record Reports4. Event Log Report5. Distress Summary ReportM. Return to Main MenuE. Exit

1. Modify Start Time and End Time 2. Modify Report Name R. Run ReportM. Return to Main MenuE. Exit



Statistics Reports MenuLevel 4

1. Channel Unit Chassis Stats Report2. Channel Unit Rack Stats Report3. ISL Link Layer Stats Report4. TDM Group Stats Report5. Call Completion Summary Report6. Mobile Call Summary Report7. Telex Route Stats ReportM. Return to Main MenuE. Exit

Channel Unit ChassisStatistics ReportLevel 5

1. Modify FEP Name 2. Modify Chassis ID 3. Modify Ocean Region 4. Modify Start Time and End Time 5. Modify Report Name R. Run ReportM. Return to Main MenuE. Exit

Channel Unit Rack Statistics ReportLevel 5

1. Modify FEP Name 2. Modify Ocean Region 3. Modify Start Time and End Time 4. Modify Report Name R. Run ReportM. Return to Main MenuE. Exit

ISL Link Layer Statistics ReportLevel 5

TDM Group Statistics ReportLevel 5

1. Modify FEP Name 2. Modify Ocean Region 3. Modify Start Time and End Time 4. Modify Report Name R. Run ReportM. Return to Main MenuE. Exit

1. Modify FEP Name 2. Modify Ocean Region 3. Modify TDM Group ID 4. Modify Start Time and End Time 5. Modify Report Name R. Run ReportM. Return to Main MenuE. Exit

Telex Route Stat ist ics ReportLevel 5

Mobi le Call Summary ReportLevel 5

Call Completion Summary ReportLevel 5

1. Modify Start Route Number and End Route Number 2. Modify Start Time and End Time 3. Modify Report Name R. Run ReportM. Return to Main MenuE. Exit

1. Modify Start Time and End Time 2. Modify Start Mobile Number and End Mobile Number 3. Modify Report Name R. Run ReportM. Return to Main MenuE. Exit

1. Modify Driver2. Modify Start Call Serial Number and End Call Serial Number 3. Modify Start Time and End Time 4. Modify Report Name R. Run ReportM. Return to Main MenuE. Exit

1234567

1

2

3

4

7

6

5

2

2

3

3

4

4

5

5

FromOptionsMenu

4

Level 2

:::

:::

:::::

:::::

::::::

::::::

:::::

:::::

::::::


[svofl2.eps]

A4-O

PG

-003076O



4-13

Call Record Reports Menu - Level 4

Call Record List Report - Level 5

LES Cal l Report - Level 5

MES Analysis Report - Level 5

Call Completion Summary Report - Level 5

All Call Statistics Report Level 5

All Mobiles Report - Level 5

EGC Call Report - Level 5

Performance Profi le Report Level 5

Driver Specific Call Completion Report - Level 5

1. Call Record List Report2. All Mobiles Report3. LES Call Report4. EGC Call Report5. MES Analysis Report6. Performance Profile Report7. Call Completion Code Summary Report8. Driver-Specific Call Completion Code Report9. All Call Statistics ReportM. Return to Main MenuE. Exit

1. Modify Start Time and End Time 2. Modify Start Completion Code and End Completion Code 3. Modify Call Direction 4. Modify Report Name R. Run ReportM. Return to Main MenuE. Exit


1. Modify Start Time and End Time 2. Modify TDM Frequency 3. Modify SIG Frequency 4. Modify Report Name R. Run ReportM. Return to Main MenuE. Exit

1. Modify Start Time and End Time 2. Modify Priority 3. Modify Report Name R. Run ReportM. Return to Main MenuE. Exit

1. Modify Start Time and End Time 2. Modify Direction 3. Modify Driver 4. Modify Call Nature 5. Modify Completion Code 6. Modify Origin 7. Modify Destination 8. Modify Report Type 9. Modify Report Name R. Run Report M. Return to Main MenuE. Exit

1. Modify Start Time and End Time 2. Modify Call Nature3. Modify Start Completion Code and End Completion Code 4. Modify Call Direction5. Modify Report NameR. Run ReportM. Return to Main MenuE. Exit

1. Modify Start Time and End Time 2. Modify Start Completion Code and End Completion Code 3. Modify Mobile Number 4. Modify Report Name R. Run ReportM. Return to Main MenuE. Exit

1. Modify Start Time and End Time 2. Modify Start Completion Code and End Completion Code 3. Modify Report Name R. Run ReportM. Return to Main MenuE. Exit

1. Modify Start Time and End Time 2. Modify Priority 3. Modify Report Name R. Run ReportM. Return to Main MenuE. Exit

From Report Generation Menu

4

6

8

2

4

6

8

1

3

5

7

9

1

3

5

7

9

3

- Level 32

:::::

::::::

:::

::::

::::::::::

:::::::

::::::

:::::

::::


[svofl3.eps]

Operator Logon/off

A4-O

PG

-003076Issue 3.23 - A


4-14

SVABOTC.VSD

4- Autobilling Configuration Level 5

1. Modify partner node name : 2. Modify billiing mode : 3. Modify billing interval : 4. Modify target node : 5. Modify target directory : 6. Modify delete after copy : 7. Modify billing error continue : 8. Modify copy error continue : 9. Modify copy user name :

M. Return to main menu E. Save changes and exit

5 - Housekeeping Menu Level 5

1. Backup log files 2. Delete backedup log files 3. Truncate journal files 4. Backup carry over files 5. Delete carry over files 6. View the journal file

M. Return to main menu E. Exit

S - Autobilling Start Level 5

1. Modify batch queue : 2. Modify start time : 3. Modify copy password : 4. Modify partner password : S. Submit billing :


R - Manual Billing Configuration Level 5

1. Modify Start time : 2. Modify End time : 3. Modify Run number : 4. Modify File I.D. : 5. Modify Billing file name : 6. Modify Log file directory : 7. Modify Carryover file : R. Run billing

M. Return to main menu E. Save changes and exit

Autobilling Main Menu Level 4

1. Show billing 2. Lock billing 3. Unlock billiing 4. Configure billing 5. Housekeeping 6. Stop billing 7. CSV Configuration Management 8. Old Automatic Billing S. Start billing R. Run manual billing


4

5

S

From Billing Data Generation menu, level 3 - '6. Automatic billing'

R

8 - Offline Automatic Billing Level 5

1. Start Date : 2. End Date : Load With Carryover : Load Calls : 3. Load Distress : 4. Load Events : 5. Load Statistics : 6. Archive Tape Drive : 7. Billing Tape Drive : 8. Billing Run Number : 9. Billing File ID : S. Start Autobilling E. Exit

7 - Auto CSV File Configuration Level 5

1. Auto CSV Generation Required : 2. Target Node name for Copy : 3. Target Directory for Copy : 4. Target Username : 5. Alter Target Password 6. Delete file after copy : G. Generate CSV File M. Return to main menu E. Save changes and exit

8

7

Figure 4-10. SOC Viewer Autobilling Menu Tree

[svaubill.eps]

A4-OPG-003076 Operator Logon/offIssue 3.23 - Accepted17th July 2001

5-1

Chapter 5

OPERATOR LOGON/OFF

An operator must log on to the system before using the SOC forms.

In practice, the operator is logging on to a window in which the forms are opened up. If more thanone window is required, logon must be performed for each window.

To log on, the operator selects the Create SOC form window option as described in section 2.5and is presented with the Operator Logon form. Enter name and password and then press thefunction key .Logon

Note: it is not possible to logon to a window which is already logged on.

To logoff the system, again choose the Operator Logon form, and press the function key.Logoff

Note: it is not possible to logoff from a window which is already logged off.

When the operator has logged off, the operator logon screen remains displayed on the screen.This can be removed by pressing the function key .Exit

Note: even if an operator is not logged on, it is possible to call up any of the SOC forms, but it isnot possible to display data in them. This facility is useful for training staff on the SOC.

For further description on the various types of SOC access, refer to Chapter 15.

[opg5.mss]

Terrestrial Interfaces A4-OPG-003076Issue 3.23 - Accepted

17th July 2001

5-2

A4-OPG-003076 Terrestrial InterfacesIssue 3.23 - Accepted17th July 2001

6-1

Chapter 6

TERRESTRIAL INTERFACES

6.1 Configuring the Terrestrial Interfaces

The terrestrial interfaces are used to set up calls between terrestrial subscribers and the ACSE.This section deals with configuration of all circuit switched paths, ie where there is a dedicatedconnection passing information in real time such as telex, PSDN (X25 and asynchronous) orPSTN.

Terrestrial interfaces are defined by

• route : a group of circuits going to the same destination, e.g. the InternationalSwitching Centre, and sharing the same characteristics, e.g. incoming traffic.

• circuit : a path for an individual call to the destination (in general the destination is thenext switching centre in this context).

In the case of telex and PSTN, the circuit corresponds to the physical interface to the ACSE.

In the case of the PSDN, packets are used. The physical connection is a line which carries anumber of virtual circuits which provide the connection.

The order of configuration is :

Route|

-------------------------| ||(telex and |(PSDN)| PSTN) || Line

Circuit |Virtual Circuit

This chapter shows only how to define routes and circuits. It is also necessary to relate routes tothe address information received from mobiles. This is described in chapter 8

6.2 Structure of the Terrestrial Interface Forms

The terrestrial set of forms is used to monitor the status of PSTN telex and PSDN circuits, to addnew ones to the system, to group them into routes, to control the operational state of each circuitand route, and to set operational parameters on them.

The software in the system has several drivers, one for each type of interface provided :

• trunk telex

• X.25 PSDN and asynchronous terminals.

• PSTN for facsimile delivery

This split between drivers is reflected in the menu structure which links the forms.

The drivers will be configured when the software is installed and the basic hardware configuration


17th July 2001

6-2

will then be entered into the database.

For PSDN lines, a DEC package is used to provide some levels of the interface functions. Thispackage is configured by the VMS Console and not the SOC. The configuration will have beenset up on installation.

6.3 Forms for Trunk Telex Circuits

Telex circuits can be used for all three terrestrial service access points (TSAP1, TSAP3 andTSAP4) as described in the System Manual.

Certain parameters are common to all trunk telex lines, regardless of which TSAP they are usedon. These parameters are set on the Telex Trunk Management form (SOC Forms - TerrestrialInterfaces - Telex Trunk).

The following information can be entered (the default values of timeouts are shown in brackets) :

• driver ACSE identity : this is the information included in the banner line of telex mes-sages sent out from the LES on the terrestrial side

• pseudo-mobile name : this is used by TSAP 1 only and sets the characters used inthe answerback given by the ACSE to incoming calls

• calling party answerback times for first WRU (default value 10s) and Post answerbackidle detect (300ms)

• no data received timeout (30s)

• guard periods for incoming (1s) and outgoing (2s) calls

• timeout for call connect reception (60s)

• enable trace on a nominated circuit. When the test circuit is used, events are raisedwhen it is selected for normal calls to advise the operator

• enable test on a nominated circuit. The nominated circuit will only accept mobile toshore calls from the test mobile. Note that if the test mobile originates a multi-address message, only the first address will be routed over the test circuit.

The only parameters which should be altered in normal operation are the trace and test functions.One circuit can be nominated as a trace circuit and one can be reserved for test use.

Remember to restore a test circuit to normal operation after use, since it cannot otherwisebe used for traffic.

When selecting a test circuit, ensure that there are other circuits available in the route to carrytraffic, i.e. that other circuits are equipped and that they are In Service. Otherwise, normal trafficwill cease on that route.

To configure telex circuits, routes must first be set up. Before adding a route, inspect what isalready set up in the system by call up the Trunk Telex Route Display (SOC Viewer - OnlineProcessing - Run Reports - Online Database Reports). Note: that routes and circuits aregenerally set up as part of system installation and it is envisaged that changes to route andcircuit set up will occur infrequently, if at all. Addition of new lines may be one reason forchanging the route/circuit configuration. Each route has a unique number within the ACSE, inde-pendent of the interface type, as detailed in section 8.3.1. Entries show the following details:


6-3

• route number - 1, 2, etc

• route name - this has no operational use but is a convenient method of reference.

• direction - incoming or outgoing

• answerback - presented by the ACSE on lines used for two-stage access and foroutgoing delivery notifications

(the answerback used for one-stage access and message delivery will be derivedfrom the number of the mobile involved - refer to the Telex User Interface documentfor further explanation)

To add a new route or amend certain route details, access the Telex Trunk Route Definition(SOC Viewer - Online Processing - Database Access - Telex Database Access - Telex TrunkDatabase Access). Routes are numbered from 1 - 16 and 33 - 49, 17 - 32 being reserved for Fax

Enter the following details :

• direction in which calls can be set up; no lines can operate as bothway circuits.

• answerback

• use of the route : distress, one or two stage access, registered traffic, status en-quiries.

One route is required for outgoing traffic and one route for each TSAP served by trunk lines in theincoming direction.

Individual circuits can also be configured in the system providing the routes have been first setup.As with routes, it is better to see what is already in the system by calling up the Telex TrunkCircuit Display (SOC Forms - Terrestrial Interfaces - Telex Trunk). The operator may optionallyspecify a route, otherwise all routes are displayed. Note: if more than one type of telex is usedthe equivalent display for the other telex types also needs to be invoked.

The possible states which a circuit can be in are :

• INS - In Service

• OOS - Out of Service

• OOS PENDING - the circuit will be placed Out of Service once the current call hascompleted

• RETEST - this occurs after a fault and is automatically performed to re-establishworking on the circuit.

• BACKWARD BUSY - an outgoing circuit which is busied from the distant end.

To add a new circuit or to modify an existing circuit access the Telex Trunk Circuit Definition(SOC Forms - Terrestrial Interfaces - Telex Trunk). This number is shown on the connector blockat the rear of the TIF rack where the circuits are connected to the external lines.

Enter the circuit number and press for :Show


17th July 2001

6-4

• the FEP pair name of the selected circuit

• the FEP port of the selected circuit

• the TIF rack identity is entered in the form of its location on the floor plan, e.g. A01 israck 01 in suite A

• the slot identity of the telex switch card is entered, numbering 1 to 16 (slot 0 is theCPU card)

• the direction in which the circuit is seized is entered - outgoing or incoming. (Bothwayis not valid.)

• the route number to which the circuit is allocated

• the set of timings used for auto retest are selected - either set ’A’ or set ’B’.

The FEP pair, port, rack and slot identities are fixed for each circuit. The operator must define thedirection of the circuit and the route. The direction should be the same as the route or, if the routeis ’bothway’, it can be set to either incoming or outgoing.

A circuit has a state in its own right, normally In Service. This can be seen on the Telex TrunkCircuit Management form (SOC Forms - Terrestrial Interfaces - Telex Trunk). Select the form,enter the circuit number and press to see the current state.Show

Press to put the circuit Out of Service immediately.FOS-all

Press to put the circuit Out of Service after any existing calls have maturedOOS-all

This form can give direct access to the Telex Circuit Definition form by pressing the key.Define

When a telex message is received using single-stage access, the originating telex network is iden-tified by its TNIC. The LES maintains a list of TNICs and associated F69 codes, for two purposes:

• to validate the received TNIC

• to route non-delivery notifications

These translations are listed on the TNIC Display (SOC Forms - Terrestrial Interfaces - TNICDisplay). This shows, for each F69 code, the name of the country and the TNIC itself.

Entries should only be made for countries which can route received telex messages automatically.No entry should be made for the Inmarsat TNIC of ’X’ (’X’ is the TNIC defined in CCITT Rec F69for Inmarsat).

To change an entry, access the TNIC Definition form (SOC Forms - Terrestrial Interfaces - TNICDefinition). Enter the name and F69 code which goes with the TNIC. (It is useful here to includeany network limitations such as TWX in the United States)

This data will normally only be changed if there is a corresponding change in the internationalrouting. The F69 code is a two or three digit number, the TNIC is one, two or three alpha-numericcharacter(s) and the country can be identified by a name of up to 20 letters.

For trunk circuits, the operator can select from two sets of Retest Intervals used when a circuit


6-5

goes faulty. These sets are

Set A Set BFirst phase selection 60 secs 72 secsSecond phase 5 mins 6 minsThird and subsequent phases 30 mins 36 mins

The set selected should be the opposite of that used in the switching centre at the other end of thetrunk lines and is effected using the Telex Trunk Circuit Definition (SOC Forms - TerrestrialInterfaces - Telex Trunk). In the first and second phases there will be up to five attempts to sendthe retest sequence, the interval between each attempt being that shown. For the third and sub-sequent phases the retest sequence will be sent at the intervals stated until such time the ex-change responds with a retest response which puts the line back into service or the operator putsthe line back into service.

If the message is not delivered, the ACSE will make multiple attempts at delivery, depending onthe reason for failure. The Telex Reattempt Table contains a list of failure codes against whichthe number of re-attempts and the frequency of those reattempts (in minutes). There will be a setof separate values for each type of telex supported (i.e. trunk, subscriber or leased). This can bemodified using Telex Reattempt (SOC Forms - Terrestrial Interfaces ) The default values are asfollows :

Failure Reason Attempts Interval

Absent subscriber/office closed 10 30Backward path signal 5 1BK cut off 5 1Congestion 20 10DER out of order 10 20INF subscriber not available call inf 5 1JFE office closed due to holiday 5 1MOM waiting 5 1NA correspondnce with sub not admitted 3 1NC no circuits 20 10NCH subscriber number has changed 1 1No service signal 5 15NP party is no longer a subscriber 5 2OCC subscriber is engaged 20 10Other service signal 5 1Unexpected answerback 2 1


17th July 2001

6-6

The following relationship exists between the above Failure Reasons and the Telex call comple-tion codes contained in Appendix E:

Call Completion Code No. Reattempt Reason

NC TLX Idle Timeout 500 No Service SignalNC TLX No Seize Confirm 501 NCNC TLX No PTS Received 501 NCFMT TLX Invalid Format 503 Other Service SignalNC TLX User Cleared 504 AbsentNC TLX User Cleared Awaiting COT 505 AbsentNC TLX User Cleared Awaiting COT Check 506 AbsentNC TLX User Cleared Awaiting Selection 507 AbsentNC TLX User Cleared Awaiting Selection Validation 508 AbsentNC TLX User Cleared Awaiting IC Answerback 509 AbsentNC TLX Circuit Fault 510 Other Service SignalOCC TLX Busy 511 OCCNC TLX Congested 512 NCABS TLX Absent 513 AbsentDER TLX Out Of Order 514 DERNC TLX No Circuits 515 NCNP TLX Not Permitted 516 NPNA TLX Not Admitted 517 NAOCC TLX Engaged 518 OCCINF TLX Unobtainable Call Info Service 519 INFMOM TLX Waiting 520 MOMJFE TLX Closed 521 JFEBK TLX Cut Off 522 BKUNK TLX Other Service Signal 523 Other Service SignalIAB TLX Unexpected Answerback 524 Unexpected AnswerbackDER TLX No Answerback 525 Unexpected AnswerbackIAB TLX Answerback Mismatch 526 Unexpected AnswerbackNC TLX Back Path Signals 527 Backward Path SignalNC TLX LES Failure 528 NCNC TLX Tape Stuck 529 Other Service SignalNC TLX Call Preempted By IC 530 Backward Path SignalNC TLX Outgoing Circuit Guarded 531 Other Service SignalNC TLX No Call Connect 532 Other Service SignalNC TLX No Clear Confirm 533 Other Service SignalNC TLX No RC TC 534 Other Service SignalNRT TLX No Further Retests Needed 535 Other Service SignalNA TLX Invalid Seize Combination 536 Other Service SignalNA TLX Invalid COT 537 Other Service SignalNA TLX Invalid COT COTC 538 Other Service SignalNA TLX No COT Sent 539 Other Service SignalNA TLX COT Not Permitted 540 Other Service SignalRTD TLX Incoming Retest Detected 541 Other Service SignalDER TLX Incoming Message Not Secured 542 Other Service SignalNA TLX No PIN 543 NPNP TLX Invalid PIN 544 NPNA TLX No WRU 545 NPNC TLX Invalid PTS 546 NPNC TLX Station Closed Awaiting Incoming Answerback 547 NPNC TLX Station Closed Awaiting Clear Confirm 548 NPNC TLX Station Closed 549 NPNCH TLX Number Changed 550 NCH


6-7

NC TLX OG Multi Addr 551 NPNC TLX NO OG CCT 552 NCNC TLX NO FREE OG CCT 553 NCNC TLX ENOUGH RETRIES 554 DERNC TLX MES AB Services 555 NCNC TLX CODT IF 556 NCNC TLX MDIR ROU IF 557 NCNC TLX MDIR DEL IF 558 NCNC TLX TLXIL IC IF 559 NCNC TLX TLXIC CRM I 560 NCNC TLX TESH IF 561 NCNC TLX SDA REGD USER IF 562 NCNC TLX ES PARSE ERR 563 NCNC TLX OVERSIZE MSG 564 BKNC TLX UNREG CONFIG ERR 565 NCNC TLX FEP INTRO 566 BKNC TLX OP FOS 567 BKNC TLX INV DESTN ADDR 568 NPNC TLX Delivery CRM Err 569 NCNC TLX Enter Reset 570 Other Service SignalNC TLX X Host Fault 571 Other Service SignalNC TLX Spare 572 NPNC TLX OL Silent Timeout 573 NCNC TLX TLXOL OC If 574 NCNC TLX BAD Msg 575 NCNC TLX Active To CallBusy 576 NCNC TLX Active To StatnClosed 577 NCNC TLX Active To CircFault 578 NCNC TLX Guard To CircFault 579 NCNC TLX OGSR To CircFault 580 NCNC TLX OGSR To StatnClosed 581 NCNC TLX OGSR To CallBusy 582 NCNC TLX Busy To CircFault 583 NCNC TLX Busy To TI OOS 584 NCNC TLX StatnClosed To TI OOS 585 NCNC TLX FEP Inactive 586 NCNC TLX Err Read TermChar 587 NCNC TLX LO Timeout MsgTXAck 588 NCNC TLX OL MsgFormatErr 589 NCNC TLX OL OC TIMEOUT 590 NCNC TLX OL LO TIMEOUT 591 NCNC TLX OL STOP BY LM 592 NCNC TLX OL HALTED 593 NCNC TLX IL LO TIMEOUT 594 NC

The caller signals end of text by the characters EOT. The LES then returns the time, date andmessage reference number. The LES does not expect to receive any characters after the EOT,but in some countries, the telex machines insert the answerback automatically. The LES has alimit on the number of characters which are allowed to follow the EOT; if this limit is exceeded, itreturns character T. The default limit is set at 6 characters; this limit can be changed on the PostEOT Character Limit Table (SOC Viewer - Online Processing - Database Access - TelexDatabase Access - Telex General Database Access). Set this limit to ’30’ if an answerback isexpected after EOT.


17th July 2001

6-8

6.4 Telex Line Failures

Failure in an outgoing circuit will be detected when a line seize does not result in proceed to send.The line will be placed in retest mode and an event recorded. This is classed as minor. The linecan be placed in maintenance state using the Telex Circuit Management form if there is persist-ent trouble with the line. It can then be tested using proprietary test equipment without carryingnormal traffic.

Failure in an incoming circuit would be detected at the Switching Centre.

[opg6_inc1.mss]

6.5 PSDN Line Configuration

To establish communications with the PSDN the operator must set up the Routes, Lines andVirtual Circuits (in that order). Changes need to be made at the SOC, the DEMSA unit and theexchange, at roughly the same time. Configuring the DEMSA units is achieved by running a DECConfiguration program; this is a separate task and normally help should be obtained from HNS.

Route numbers are allocated in a common series in the ACSE. See section 8.3.1 for details.

A PSDN route is set up using the X25 Route Definition (SOC Viewer - Online Processing -Database Access - X25 Database Access). The route numbers should be chosen globally for theACSE, as described in chapter 8; a separate route number is required for each DEMSA pair tocomply with the requirements of the DEC X25 software. Enter the route number and the following:

• network identity : of the X25 network to which the route is connected

• profile identity : of the X25 network to which the route is connected

• DEMSA pair name : identifies the DEMSA pair that will serve this route

A summary of these values is available on the X25 Route Display (SOC Viewer - OnlineProcessing - Run Reports - Online Database Reports).

X.25 lines, corresponding to the ports on the DEMSA units, are identified by an NUA. This isprovided by the PSDN so that both the ACSE and the PSDN identify each line in exactly the sameway. Each line must have a separate NUA. At the network end, group hunting should be employedso that the load is spread over the available lines.

Sub-addresses are also used on PSDN access. For normal PSDN registered user access, thesubaddress of ’00’ is recommended, either inserted by the terrestrial caller or by the packet net-work as a default address. This allows other subaddresses to be used for X400 access (if re-quired) and for access by HNS to the operating system for fault investigation.

They are set up in the ACSE using the X25 Line Definition (SOC Viewer - Online Processing -Database Access - X25 Database Access). Select the form, enter the route and line number.Then enter the:

• X.121 DTE address, i.e. the NUA by which the PSDN identifies the DTE at the ACSE

• port number - the physical port on the DEMSA, usually in the range SYN-0 to SYN-3.

Use the X25 Line Display (SOC Viewer - Online Processing - Run Reports - Online DatabaseReports) to show all those lines allocated in the system. The selection criteria is route number,values 50-99, or the default ALL. The display shows the route number, network identity, line and


6-9

current state.

Virtual circuits are configured using the X25 Channel Definition (SOC Viewer - OnlineProcessing - Database Access - X25 Database Access). Call up the form and enter the route, lineand virtual circuit (channel) number. The direction shows which way calls can be set up on thecircuit and can be :

• I : incoming

• O : outgoing

• B : Bothway

Virtual circuits numbers must be agreed with the PSDN network since they are used by both theLES and the connected PSDN switch to establish connections. A maximum of 32 virtual circuitscan be allocated to any one line and a maximum of 64 virtual circuits can be allocated in thesystem, e.g. if four lines are configured, each can have 16 virtual circuits.

It is recommended that there be a mixture of incoming, outgoing and bothway circuits to limit thechance of blocking. HNS will recommend the how the lines should be set up, and will normallyconfigure them as part of an initial installation.

Note: when altering the configuration of a line, or circuits associated with that line, the line mustbe set to Out of Service using the X25 Line Management SOC form.

The X25 Channel Display (SOC Viewer - Online Processing - Run Reports - Online DatabaseReports) shows the virtual circuits allocated to a line. Call up the form, enter the route and linenumber. The selection criteria is route number, values 50-99, where the default is ALL, and line,where the default is ALL. The display shows the route and line numbers, logical channel numberand direction.

X25 lines, but not virtual circuits, have a state which can be managed using the X25 LineManagement (SOC Forms - Terrestrial Interfaces ) form. The possible states are :

• Off

• On

• Shut (for maintenance)

• Pending off

• Pending on

• Pending shut

The operator can request the following states :

• Ins : In Service

• OOS : Out of Service

• Mnt : maintenance (this will prevent new calls being set up on the line and take it outof service when any existing calls have completed)


17th July 2001

6-10

To change a state, select the form, enter the route and circuit number, press the function key forthe desired state and press . If the circuit and route numbers are not known, they can beEnterfound using the X25 Route Display (SOC Viewer - Online Processing - Run Reports - Run OnlineDatabase Reports) and the X25 Line Display (SOC Viewer - Online Processing - Run Reports -Run Online Database Reports).]}

Note that when a line has failed, the operator must manually return it to In Service using thisform.

Note that the configuration of the line profile itself e.g. packet sizes, window sizes, number ofchannels is part of the installation process which involves using the DEC PSI software and is doneby HNS engineers.

6.6 General PSDN Parameters

This section deals with the controls available over PSDN call handling.

The X25 General Definition (SOC Viewer - Online Processing - Database Access - X25Database Access) is used to indicate the driver identity and to set timeouts for clearing a call andfor no data received. Call up the form and enter the new values.

The timeouts include :

• timeout for no data received - the ACSE has returned a prompt to the X25 caller butthe caller has not responded. This timeout is used at the set value once, a reminderis issued to the caller, and then a timeout of half this set value is used to repeat thereminder. If after a period of half the set value, the caller has still not responded, thecall is cleared. The aim of this sequence is to clear idle sessions on the X25 inter-face. This timeout also applies if a caller enters a response with no terminator (e.g.<CRLF>).

• time before clearing - used on outgoing calls to PSDN addresses. This is the time theACSE waits after the message has been delivered before the call is cleared.

For interactive operation, the ACSE downloads parameters which can be altered or inspectedusing X25 Interactive PAD Parameter Definition (SOC Viewer - Online Processing - DatabaseAccess - X25 Database Access - X25 Profile Definition). Call up this SOC Viewer option andenter the new values of the following parameters :

• Echo

• Data forwarding characters

• Data forwarding timeout

• Suppress data

• Padding after carriage return

• Line folding

• Line feed insertion

• Line feed padding


6-11

For file transfer, the same set of parameters can be independently set using the X25 File TransferPAD Definition (SOC Viewer - Online Processing - Database Access - X25 Database Access -X25 Profile Definition). Reattempt rates can be set, by using the X25 Reattempt form (SOCForms - Terrestrial Interfaces). The number of reattempts and their frequency (in minutes) for avariety of call failure reasons can be set. Select the form, and the existing values will be dis-played. Use to change settings for number of reattempts and interval. Example values areModifyas follows :

Reason Attempts Interval

ACCESS BARRED 3 1CALL COLLISION 20 10DTE INCOMPATIBLE CALL 2 1INTERNAL CAUSE 5 2LPE 1 1NETWORK CONGESTION 20 10NUMBER BUSY 10 5OUT OF ORDER 5 2PSDN PROTOCOL ERROR 1 0REMOTE DTE CLEAR 10 5RESET 5 2RESTART 5 2RPE 2 2TIME OUT ON NETWORK 5 2

The following relationship exists between X25 Call Completion codes, (see Appendix E) and theabove reattempt reasons. Note not all call completion codes are covered, since they relate toINCOMING call failures.

Call Completion Code No. Reattempt Reason

DER X25 Remote Procedure error 600 RPENA X25 Access Barred 601 ACCESS BARREDLPE X25 Local Procedure Error 602 LPENA X25 DTE Incompatible Call 603 DTE INCOMPATIBLE CALLNC X25 Call Collision 604 CALL COLLISIONNC X25 Restart Received 605 RESTARTNC X25 Reset Received 606 RESETNC X25 Network Timeout 607 NETWORK CONGESTIONNC X25 Network Timeout 607 TIME OUT ON NETWORKNC X25 Internal Cause 609 INTERNAL CAUSEDTE X25 User Cleared 610 REMOTE DTE CLEAROCC X25 Number Busy 611 NUMBER BUSYDER X25 Out Of Order 612 OUT OF ORDERABS X25 Not Obtainable 613 REMOTE DTE CLEARNA X25 Invalid Dest Address 615 DTE INCOMPATIBLE CALLNC X25 Network Shut 622 INTERNAL CAUSE

X25 Statistics (SOC Viewer - Offline Processing - Report Generation) provides a summary ofcurrent usage and shows, for a given time period, the number of incoming and outgoing calls foreach route.


17th July 2001

6-12

6.7 PSDN Line Failures

Any failure will be detected by the VAX PSI software and reported as an event. The X25 LineManagement SOC form can be used to see the current line state.

The line failure handling software assumes that most line failures are due to short and temporaryproblems on the line and that the line will recover from the failure within a few minutes. Therefore,when a problem is detected on a line, the line is not taken out of service, so that recovery by thenetwork provider is detected. The software will detect recovery by receiving an incoming call ormaking a successful delivery call.

All active lines within a route will be tried. If a delivery call fails on one line, the other lines (if any)will be tried.

Whenever line failure persists on all lines of a route, then the route is marked as unavailable sothat an alternative route can be used, if one exists. This covers cases where the line failurerecovery is not possible without operator corrective action.

DEMSA failures are detected separately and, if possible, a DEMSA switchover is initiated. Thiswill be notified to the operator by an event indicating a DEMSA failure followed by a DEMSAswitchover attempt.

The sequence of events when a delivery call fails due to line failure is:

1. An event will be raised indicating failure on the line. The line identifier will beprovided so that the line problem can be investigated by the operator. (See note 1.)

2. If there are other lines on the same route the call will be tried on those lines beforefailing the delivery attempt. If the delivery is successful on any of the alternative linesno further action is taken. If the delivery fails on all possible alternative lines, thedelivery attempt will be considered as failed. (The delivery will be reattempted ac-cording to the rules based upon settings in the X25 reattempt table.)

3. Consecutive delivery attempt failures due to line problems will be counted. If thiscount gets greater then a maximum failure allowed on the route (set to 10) then theroute will be marked as unavailable and no more deliveries will be attempted on theroute. However, incoming calls on an unavailable route will be accepted and willcause the route to be reset to available. This is because receiving an incoming callon a faulty line is a good indication that the line has recovered. The maximum num-ber of failures allowed on a route (10) ensures that enough time has been given forlines to recover.

4. When the route is marked as unavailable an event is raised to inform the operator.In this case the operator can make the route available by taking any of the lines forthe route Out of Service and back to In Service.

Note: when a line fails an event will be raised for each unsuccessful delivery attempt, but if theline stays in the failed condition for a long period, then the number of events generated would fillup the log files. To avoid this problem the number of events raised on the same line has beenreduced proportionally to the number of attempts, ie only the 1st, 3rd, 6th, 12th and 24th attemptsgenerate an event.


6-13

6.8 PSTN Interface for Facsimile

The Fax Interface is provided via PCs running application software on OS/2 and connected to theLES via Ethernet. The number of reattempts and reattempt interval for a message delivery is setby default to be 5 reattempts and 5 minutes reattempt interval respectively, although this can bechanged at the PC. From each PC there are up to 4 lines connected via modem to the PSTNnetwork, thus allowing for up to four simultaneous message deliveries per PC.

Any change to the attempt number or attempt interval on the PC must be duplicated in theparameters file for LESFAX. Log in to the BAP account (BAPSYS). Edit the parameters file byentering:

$ EDIT LESFAX_PARAMS

Amend the values of Number_Of_Attempts and Reattempt_Delay to reflect the values set on thePC. This allows the BAP software to predict the maximum delivery time for a message andgenerate events when delivery completion is overdue.

As with all other terrestrial interfaces, a route must be allocated for delivery of messages via Faxand the Fax PCs used must be associated with a Fax route. By convention, Fax route numbersare in the range 17 to 32.

A description of the operational procedures associated with the FAX PC together with a systemdescription, is contained in Appendix C.

6.8.1 FAX Route SOC Forms

The following FAX Route SOC forms, used to interrogate and manage the Fax routes, are ad-dressable from the Fax Menu of the Terrestrial Interfaces Menu :

• FAX Route Display form.

• FAX Route Definition form.

• FAX Route Management form.

The FAX Route Display (SOC Forms - Terrestrial Interfaces - Fax) provides a tabular listing of allthe Fax routes defined. Select the form and press ; use the andFirst Page Up arrow

to scroll around the display. The information displayed on each route consists of:Down arrow

• Route Number - A numeric identifier of a particular Fax route, in the range 1 to 999.

• Route Name - A text string naming a particular route.

• Current State - Current state of the Fax route. Possible values are In Service, Out OfService, Pending OOS and Shutdown.

• Num PCs - The number of PCs attached to a particular Fax route.

• Messages Waiting for PCs - The number of messages, in the shared area of theshadow disk, that have not yet been transferred to the local message queues on theFax PCs.

• Messages Waiting in PCs - The number of messages currently in the local messagequeues of the Fax PCs for this Fax route.


17th July 2001

6-14

• Message Waiting for BAP - The number of delivered messages that are awaitingprocessing of their delivery details by the BAP.

Access to the Definition and Management forms can be obtained directly by placing a Y in theleft-hand column and pressing or respectively.Define Manage

The FAX Route Definition (SOC Forms - Terrestrial Interfaces - Fax) allows individual routecharacteristics to be defined. Select the form, enter a Route Number (e.g. 18) and press .ShowThe following information will be displayed :

• Route Name - A text string naming a particular route.

• FAX Quality - A text string describing the quality of Faxes sent over this route.Possible values are Draft, Normal and High.

• Default Banner - Defines the banner used, including character font, e.g. Roman10 orSSerif10, and letterhead, for Faxes sent out on that route. Possible values areDEF_BANR only, which corresponds to a default provided by the system.

Definition files will have previously been provided for DEF_BANR, and these containinformation to be used by the FAX PC which determine the formatting information etc.to be associated with outgoing faxes for that route.

Details of how to modify and list the definition files are contained in Section 6.8.4 and6.8.5. Details of the format of the definition files are contained in Section 6.8.6.


The , and keys can be used to add new route entries and modify or deleteAdd Modify Deleteexisting entries. In addition, and give direct access to the FAX Route DisplayDisplay Manageand FAX Route Management forms.

The FAX Route Management (SOC Forms - Terrestrial Interfaces - Fax) is used to control theoperational state of the FAX Routes. Select the form, enter the required Route Number (e.g. 18)and press . The form shows :Show

• Number of PCs Connected - The number of PCs attached to a particular Fax route.



• Message Waiting for BAP - The number of delivered messages that are awaitingprocessing of their delivery details by the BAP. Number of PCs Connected


• Action Requested - Desired state of the Fax route. Possible values are In Service andOut Of Service.


6-15

To change the current state of the route to In Service or Out of Service, use or respec-INS OOStively. In addition and give direct access to the FAX Route Display and FAXDisplay DefineRoute Definition forms.

6.8.2 FAX PC SOC Forms

The following FAX PC SOC forms, used to interrogate and manage the Fax PCs, are addressablefrom the Fax Menu of the Terrestrial Interfaces Menu :

• FAX PC Display form.

• FAX PC Definition form.

• FAX PC Management form.

The FAX PC Display (SOC Forms - Terrestrial Interfaces - Fax) provides a tabular listing of allthe FAX PCs. Select the form, enter a Route Number or 0 for all routes, and press ;First Pageuse the and to scroll around the display. The following information will beUp arrow Down arrowdisplayed for each FAX PC :

• PC Identifier - A four character FAX PC identifier in the range PC_A to PC_Z.

• PC Nodename - A six character text string naming a particular PC.

• Route Number - The Fax route with which this Fax PC is associated.

• Current State - Current state of the Fax PC. Possible values are In Service, PendingOOS, Out Of Service, Contact Made, Contact Lost and Shutdown.




Access to the Definition and Management forms can be obtained directly by placing a Y in theleft-hand column and pressing or respectively.Define Manage


17th July 2001

6-16

The FAX PC Definition (SOC Forms - Terrestrial Interfaces - Fax) allows individual PC charac-teristics to be defined. Select the form, enter a PC identifier (e.g. PC_B) and press . TheShowfollowing information will be displayed :

• PC Nodename - A six character text string naming a particular PC.


• Current State - Current state of the Fax PC. Possible values are In Service, PendingOOS, Out Of Service, Contact Made, Contact Lost and Shutdown.

The , and keys can be used to add new PC entries and modify or deleteAdd Modify Deleteexisting entries.

Access to the Display and Management forms can be obtained directly by pressing orDisplayrespectively.Manage

The FAX PC Management (SOC Forms - Terrestrial Interfaces - Fax) is used to control theoperational state of FAX PCs. Select the form, enter a PC Identifier (e.g. PC_C) and press

. The following information will be displayed :Show





• Current State - Current state of the Fax PC. Possible values are In Service, PendingOOS, Out of Service, Contact Made, Contact Lost and Shutdown.

• Action Requested - Desired state of the Fax PC. Possible values are In Service andOut Of Service.

To change the state of this FAX PC to In Service or Out Of Service, use or respec-INS OOStively. In addition and are used to give direct access to the FAX PC Display andDisplay DefineFAX PC Definition forms respectively.

6.8.3 FAX Statistics SOC Forms

The following FAX SOC Statistics forms, used to obtain statistics information for a FAX Route, PCor modem, are addressable from the Fax Menu of the Terrestrial Interfaces Menu :

• FAX Route Statistics form.

• FAX PC Statistics form.

• FAX Modem Statistics form.


6-17

The FAX Route Statistics (SOC Forms - Terrestrial Interfaces - Fax) display provides the follow-ing information for a specified FAX route:

• Number of working modems on this route

• Number of failed modems on this route

• Number of successful calls on this route (Note 1)

• Number of failed calls on this route (Note 1)

• Calls waiting to retry after a send has failed

• Calls waiting to be converted (Note 2)

• Calls being converted (Note 3)

• Calls waiting for modem to become available (Note 4)

The FAX PC Statistics (SOC Forms - Terrestrial Interfaces - Fax) display provides the followinginformation for a specified FAX PC identifier:

• Number of working modems on this PC

• Number of failed modems on this PC

• Number of successful calls on this PC (Note 1)

• Number of failed calls on this PC (Note 1)

• Calls waiting to retry after a send has failed

• Calls waiting to be converted (Note 2)

• Calls being converted (Note 3)

• Calls waiting for modem to become available (Note 4)

The FAX Modem Statistics (SOC Forms - Terrestrial Interfaces - Fax) display provides the infor-mation for each of the four modems associated with a specified FAX PC identifier, in the form:

• Status of modem (e.g. error, idle, failed, offline)

• Send attempts which have:

• Failed to connect (Note 1)

• Failed after connection successful (Note 1)

• Current message details:

• DCR of current message

• Number of pages of current message


17th July 2001

6-18

Notes:

1. The number is taken from the time the PC was last reset.

2. These represent calls that have been passed to the PC from the BAP and are await-ing conversion into the appropriate FAX format.

3. These represent calls that have been passed to the PC from the BAP and are in theprocess of being converted into the appropriate FAX format.

4. These represent calls that have been passed to the PC from the BAP, have beenconverted into the appropriate FAX format, and now are waiting for a modem to be-come available in order to transmit the FAX to the PSTN network.

6.8.4 FAX Banner Configuration

A FAX delivered by the LES is composed of four parts.

• The status line - (see the FAX user interface definition)

• The Letterhead - background stationery (including graphics/logo)

• The textual banner information

• The message text as received from the mobile

These four elements are overlayed to create the finished FAX.

The letterhead is a Group 3 fine (G3F) format two page fax and may be either blank or include alogo on the first page. The Zetafax workstation program is used to create this file in conjunctionwith standard PC wordprocessing or Graphics packages. See the Zetafax User manual Reference[6] for details on creating and modifying letterhead files. Note that the LES Fax interface does notuse the full page coversheet also described in Reference [6].

The default Letterhead file used by the LES is contained in the PC file:

C:\ZETAFAX\SYSTEM\Z-LETTER\DEF_BANR.G3F

6.8.5 FAX Banner Access

Using FAX Database Access SOC Viewer - Online Processing - Database Access, options areprovided to:

• add - not supported

• modify

• delete - not supported

• list

the files which provide the FAX banner information for a given PIN.

The files are named according to the convention G3FAX-DEF_BANR-I_A5-<TYPE>, , where<TYPE> is one of SAC, DN or OTHER.


6-19

Note: if an attempt is made to invoke the add or delete options, a warning is given that this optionis not available, and access to these options is denied.

Using the modify option the operator can modify the contents of any of the existing files, i.e. thesystem default files.

Using the list option the operator can obtain a list of all the current banner files.

6.8.6 FAX Banner Formats

The system default banner file, corresponding to DEF_BANR, is provided on a per customerbasis, and is of the form:

%%[FONT:SSERIF10]%%[BOLD:ON]%%[XPOS:0]GLOBAL MOBILE TEXT - FAX%%[DOWN:51]%%[BOLD:ON]%%[XPOS:0]To%%[BOLD:OFF]%%[XPOS:142]<Dest_Addr>%%[BOLD:ON]%%[XPOS:412]From%%[BOLD:OFF]%%[XPOS:565]INMARSAT-C%%[DOWN:35]%%[BOLD:ON]%%[XPOS:412]Mobile No.%%[BOLD:OFF]%%[XPOS:565]<Orig_Addr>%%[DOWN:35]%%[BOLD:ON]%%[XPOS:412]Ocean Region%%[BOLD:OFF]%%[XPOS:565]<Ocean_Region>%%[DOWN:35]%%[BOLD:ON]%%[XPOS:0]Message%%[DOWN:16]%%[BOLD:ON]%%[XPOS:0]Reference No.%%[BOLD:OFF]%%[XPOS:142]<MRN>%%[BOLD:ON]%%[XPOS:412]Date%%[BOLD:OFF]%%[XPOS:565]<Date>%%[DOWN:35]%%[BOLD:ON]%%[XPOS:0]Total Pages%%[BOLD:OFF]%%[XPOS:142]%%[PAGES] (Including this page)%%[BOLD:ON]%%[XPOS:412]Time%%[BOLD:OFF]%%[XPOS:565]<Time> UTC%%[DOWN:43]%%[UNDERLINE:ON]%%[BOLD:ON]%%[XPOS:0]%%[DOWN:35]** Note 1 **%%[BOLD:OFF]%%[UNDERLINE:OFF]%%[LMARGIN:0]


17th July 2001

6-20

Notes:

1. This line contains 80 spaces. This is required in order to provide an underline for thewhole width of a fax page. The message text will follow this line.

2. The contents of the system default banner file represents the starting point for allother operator definable banner files, from which changes can be made accordingthe available options and banner requirement.

3. The meaning of the keywords contained between ’%%[’ and ’]’ are described in theZetafax User Guide, Appendix B, Reference [6].

4. Up to 50 markers, of the form ’<...>’, can be specified to the LES software. Thesecontain specific text that is translated by the LES software to values associated withthe particular message which is to be output via FAX. The ’specific text’ set used bythe LES currently comprises:

• <Dest_Addr> - Destination address (for Fax this will be a telephone number).

• <Orig_Addr> - Originator address (for Fax this will be a mobile number).

• <SAC> - Special Access Code.

• <Ocean_Region> - Will produce one of the following: Atlantic/West,Atlantic/East, Pacific, Indian or Unknown.

• <MRN> - Message reference number.

• <Date> - Will display the date in the form "dd month yyyy", e.g. 20 April1995.

• <Time> - Will display the time in the form "hh:mm UTC", e.g. 13:15 UTC.

• Date_Time - Will display the date and time in the form "yy-mm-dd/hh-mmUTC", e.g. 95-04-20/13-15 UTC.

5. Use of delimiters in free text.

• Free text (including the ’>’ character) can be placed at any point in a bannerdefinition.

• The character ’<’ must NOT be used on its own other than as the leadingdelimiter forming part of the defined marker text. The use of this character inisolation may cause the banner to fail.

• If a ’<’ character is required to be displayed as part of free text within the ban-ner, then two such characters must be used, with no separation, in the bannerdefinition thus: ’<<’. This will result in the output of a single ’<’.

[opg6_fax.mss]

6.9 PSTN Interface for Asynchronous Access

The LES provides an asynchronous interface to allow calls to/from a mobile to be made to/from anasynchronous terminal. The ACSE is connected via one of its asynchronous ports to aMicroTurbo PAD. This PAD has up to eight connections, configured either as incoming or out-


6-21

going, but not both ways, each linked to a CODEX modem to the PSTN network. The user’sterminal is linked with a compatible asynchronous modem into the PSTN network. Thus com-munication can be established.

In order to route messages from a mobile to an asynchronous terminal, specific settings are re-quired in the routing table. A special asynchronous route must be configured, ’60’ usually beingallocated for the purpose.

Calls from an MES to an asynchronous terminal are routed to the PSTN network via a PAD. Thus,routing must be specified to be via the PSDN network, but with the address extension set to avalue such that translation by the message handler software will cause routing to be via theDEMSA connection into the MicroTurbo PAD. Generally, to achieve this the PSDN address exten-sion should begin with ’9’.

For calls from an asynchronous terminal to an MES, the LES interface is similar to that for thePSDN interface, the difference being the network used to make the connection. The formeremploys the PSTN network whereas the latter employs the PSDN network. In the asynchronouscase it is necessary to connect to the LES’s PSTN number, and providing a line into the LES isavailable and modems are compatible, a connection is made. In the PSDN case it is necessary toconnect to the LES’s X.121 address. Both types of connection are made into the LES’s DEMSAs.

A description of the operational procedures associated with setting up asynchronous communica-tion plus some guidance to use, is contained in reference [5].

[opg6_async.mss]

[opg6.mss]

Satellite Interfaces A4-OPG-003076Issue 3.23 - Accepted

17th July 2001

6-22

A4-OPG-003076 Satellite InterfacesIssue 3.23 - Accepted17th July 2001

7-1

Chapter 7

SATELLITE INTERFACE

7.1 Overview

The satellite forms control configuration of the ACSE hardware on the satellite side. Therefore thissection covers configuration of the channel units.

While there are some forms dealing with the common hardware, such as the channel unit rack, themajority of control is at the level of the channel unit.

To adequately describe the system, there are two views of channel unit :

• the physical channel unit (PCU) , which is the hardware

• the logical channel unit (LCU) , which defines a particular function applied to a givenchannel

The LES is free to allocate each function to the hardware and can switch the operation from onephysical unit to another with only a minimal interruption to traffic while the channel resynchronizes- this can still take a few TDM frames. This is how redundancy works in the channel units.Groups of operational channel units, ie the hardware, are associated with a spare in a ’sparingpool’ which is designated by the operator.

The SOC operator is responsible for entering details of the physical channel unit, ie whathardware is equipped in which position.

Physical hardware consists of :

• channel unit racks - one per ocean region, including the equipment in the SDAP chas-sis. Identified by the ocean region : AOR, WOR, IOR or POR.

• channel unit chassis - up to three per rack, each with capacity for 16 channel units.Identified by the chassis number - this is defined in the Channel Unit ChassisDefinition and may or may not be the same as the number of the chassis in theChannel Unit Maintenance Manual, Reference [3].

• physical channel units - each unit is either a modulator or a demodulator. Channelunits are number 0 - 15 within each chassis.

Logical assignments are

• satellite parameters - first, second or third generation

• Domestic satellites are compatible to second generation satellites logical channelunits (LCU) - to describe the functions performed on a particular channel, ie TDM,MSG or SIG

• channel unit sparing pools - to provide redundancy of the hardware

• TDM groups - to associate TDM, MSG and SIG channel units for operational use

• LES identities - a unique value exists for each satellite that is served


17th July 2001

7-2

The association between logical and physical channels is in several groups, within each of whichany logical channel can be associated with any physical channel unit.

Physical Logical

C-band transmit TDM

L-band receive TDM

C-band receive SIG, MSG

Note: The terms C-band and L-band are consistently used in this document to denote distinctbandwidths used for satellite transmission. For domestic satellites the equivalent Ku-Band is usedinstead of C-band. Further details of the applicable satellite bandwidths are to be found in theSystem Manual, Ref.[2].

For redundancy, there are more physical channel units than logical channels. The spare units areallocated to pools of active units, so that they can be configured with operational parametersautomatically by the software in the event that an operational unit has failed. As a minimum, onepool is required for each IF interface.

For message transfer, the TDM, MSG and SIG channels are grouped into TDM groups, each con-taining one TDM channel (modulator and demodulator) and a number of MSG and SIG channels.Up to 20 MSG and 20 SIG logical channels can be configured per Ocean Region; remember thatthere is also a physical maximum of 48 channel units of all types per Ocean Region.

Operationally, the satellite network requires precise alignment of the frame boundaries on theTDM, signalling and message channels, as specified in ref 1. To co-ordinate the timings, theACSE has to determine the time taken for a transmission to the satellite and back again. Basedon this timing, it knows when to expect data on the signalling and message channels. This timingis derived in the TDM demodulator, and the visual indicators which show that synchronization isestablished in the TDM demodulator are important when checking that the equipment is opera-tional.

The system is designed so that one, and only one, TDM demodulator is used to determine theloop timing for all the channel units that communicate with one physical satellite. The operatorhas to indicate the position of the demodulator on the TDM Rx Logical Channel Unit Definitionform. The system will automatically transfer that timing control to the standby demodulator shouldredundancy switchover take place.

The chosen demodulator should take into account the possibility of spot beam . If there is onlyone TDM group in the system, no choice is involved. If spot beam working is in use, thedemodulator can only be tuned to a modulator in the global beam or in a beam illuminating theearth station.

If multiple TDM groups are provided, one group at least should be permanently assigned and thatgroup should have a demodulator used for loop timing detection.

7.2 LES Forms

Two forms provide an overview of the operational state of the LES - LES Summary and LESManagement .

The LES Summary form (SOC Forms - Satellite Interfaces - Satellite Station) summarizes thestate of the LES with respect to all the Ocean Regions it serves. Select the form and press Showfor a tabular display which shows the following for each Ocean Region.


7-3

• current mode

• ISL status as Up or Down. This will always be set to Down as there are no ISLs,since the LES operates without an NCS.

• Number of permanent TDM channels, followed by combined number of associatedSIG and MSG channels

• Number of demand assigned TDM channels, - (not used)

• Number of busy mobiles- ie those receiving or sending messages to the LES at theselected time.

The LES Management form (SOC Forms - Satellite Interfaces - Satellite Station) shows furtherdetails of the operational status of the system. Call up the form, enter the Ocean Region and press

. The form shows:Show

• current mode : normal or standalone. This will always be set to standalone since theLES operates without an NCS.

• T15 : this is the time which the LES waits for MES unreserved access to the MESsignalling channel. The default value is 19.5s. See ref 1 for further explanation.

• Base apparent signal strength : this is used as a measurement base whenPerformance Verification Tests are performed. See ref 1. A value of 16db less orgreater than this value will be deemed outside acceptable tolerances.

• ISL status : up or down. This will always be set to Down.

• the number of permanent TDM groups

• the number of permanent channels

• the number of assigned TDM groups - (not used)

• the number of assigned channels - (not used)

• the number of busy MESs - ie those receiving or sending messages to the LES at theselected time

• the number of pending TDM requests to the NCS - (not used)

• indication in the bulletin board on the state of the terrestrial links - set to indicateopen.

Enter the desired state and press . Such action will stop all mobile to shore messag-Modifying. All the other parameters on the bulletin board are controlled via the LES Definition form,since they can be set individually on each TDM group. As noted below, it is necessary to take theTDM group out of service before the transmitted data changes.

Several forms are used to configure the satellite interface.

The characteristics of the LES itself are defined using the LES Definition form (SOC Forms -Satellite Interfaces - Satellite Station). Select the form, enter the Ocean Region and press .Show


17th July 2001

7-4

This form controls information on the TDM Bulletin Board and the information will be broadcastwhen the next TDM is assigned.

A separate form has to be completed for each Ocean Region served by the ACSE. The formshows :

• the LES number. This number is set up when the system is first installed and cannotbe modified in the field.

• the number of TDM groups equipped in the channel unit rack for that Ocean Region

• the information which appears in the TDM Channel Bulletin Board (ref 1) as listedbelow with their default values. All these parameters will normally not change:

• Distress alerting - yes

• Land mobile alerts - yes

• Safetynet traffic - yes

• Standard-C traffic - set to yes once the LES is permitted to handle traffic

• Store and forward service - yes

• Aero-C service - no

• Half-duplex - fixed at no until this service is included in the software

• Full-duplex - fixed at no until this service is included in the software

• Closed network - yes

• Fleetnet traffic - yes

• Prefixed store and forward - fixed at no until this service is included in thesoftware

• satellite generation - first, second or third - which sets the speed on the MessageChannels and Signalling Channels. See section 7.3 for the actions needed when thesatellite is changed from one generation to another.

• satellite operational - normally set to yes but can be set to no if the satellite, or the RFequipment which transmits the signal to it, is going out of service for any reason.

• Number of retries - this field has been largely superseded by the Satellite ReattemptTable described below. If, however, a call completion code were to exist which doesnot have an entry in the Satellite Reattempt Table , then this value will be used asthe number of times further attempts are made to establish a call before giving up.

To modify an existing set of data, press , enter the new data and press . This altersModify Enterthe database but not the actual bulletin board transmitted until a new TDM request is made.Therefore to bring the values into use, force the TDM group Out of Service and bring it back intoservice using the TDM Group Management form.

The number of attempts made to deliver a message to a mobile can be configured by the operator


7-5

according to the failure reason for delivery using the Satellite Reattempt form (SOC Forms -Satellite Interface - Satellite General).

Select the form and press for the current settings, which consists of :Show

• Call Completion Code - fixed text

• Retry Count - range 0 - 20. Note that the first attempt does not count in this entry andthe total number of attempts is thus one more that the entry.

• Retry Interval - range 0 - 1440 in minutes

At present, 40call completion codes are used, but the form has capacity for up to 100 (800 - 839from a range of 800-899). Use the and to see the whole display.Next Page Previous PageWhen the form is selected, the first page is automatically displayed. It is not possible to add, orremove entries from the list, using the SOC. Modifications can be made to more than one comple-tion code at a time.

The maximum period during which retries may be attempted is the retry interval multiplied by thenumber of retries. This has a maximum of 3 days; this is the longest time a call is allowed toremain in the system.

If errors are made in entering data, only the last error that occurred can be reported. However ifinvalid modifications occur, then the entries in error will all be set to fixed values of Retry Count =20 and Interval = 200 mins so that they can be identified and corrected.

The following values are recommended.


17th July 2001

7-6

Call Completion Code Number Retry Retrycount Interval

CCC_SD_Failed 800 0 0CCC_SD_Mobile_Absent 801 0 0CCC_SD_Aborted_By_Operator 802 0 0CCC_SD_Call_Failed_Due_To_Alert 803 5 5CCC_SD_Invalid_Address_In_Message 804 0 0CCC_SD_Invalid_Address_Format 805 0 0CCC_SD_Invalid_Message_Size 806 0 0CCC_SD_Invalid_Number_Of_Addresses 807 0 0CCC_SD_Invalid_Presentation 808 0 0CCC_SD_LES_Internal_Error 809 5 5CCC_SD_Mobile_Already_Commisioned 810 0 0CCC_SD_Mobile_Barred 811 0 0CCC_SD_Mobile_Busy 812 5 5CCC_SD_Mobile_Failed_To_Respond 813 5 15CCC_SD_Mobile_Forced_Clear 814 5 5CCC_SD_Mobile_Not_Commissioned 815 0 0CCC_SD_Mobile_Not_Logged_In_OR 816 0 0CCC_SD_Mobile_Not_Registered 817 0 0CCC_SD_Mobile_Responded_Incorrectly 818 5 5CCC_SD_Mobile_Response_Timeout 819 5 5CCC_SD_Mobile_Protocol_Error 820 5 5CCC_SD_NCS_Failed_To_Respond 821 5 15CCC_SD_NCS_Forced_Clear 822 0 0CCC_SD_Presentation_Conversion_Error 823 0 0CCC_SD_Protocol_Failure 824 5 5CCC_SD_Remote_Equipment_Failure 825 5 5CCC_SD_Resource_Limit_Exceeded 826 5 15CCC_SD_Satellite_Network_Failure 827 5 5CCC_SD_Service_Not_Provided 828 0 0CCC_SD_Call_Pending 829 5 10CCC_SD_Invalid_Les_ID 830 0 0CCC_SD_TDM_Not_Available 831 10 1CCC_SD_No_Message_status_Information 832 0 0CCC_SD_ITD_SD_Error_In_Outbound_Message 833 5 5CCC_SD_EGC_Transmission_Failed_By_NCS 834 1 2CCC_SD_EGC_Packet_Sequence_Error 835 1 2CCC_SD_Call_Cleared_By_System 836 1 5

CCC_SD_Distress_EGC_Interruption 837 3 5CCC_SD_Announcement_Failed_Due_To_Login 838 6 1CCC_SD_Call_To_Incorrect_Ocean_Region 839 6 0

The frequency translation between the IF and the RF interfaces in the earth station can vary. As aresult, the centre frequency of the channel units can be altered using the Satellite ParameterDefinition form (SOC Forms - Satellite Interfaces - Satellite General). This table shows the value,in kHz, corresponding to channel number zero (CN0), at the IF interface and can be derived asfollows.

The typical RF values of CN0 for each band are listed below.

Band RF of CN0

C-band uplink (first generation) 6392.5 MHzC-band uplink (second, third generation) 6405.0 MHz


7-7

C-band downlink (first generation) 4167.5 MHzC-band downlink (second, third generation) 3585.0 MHz

L-band downlink 1510.0 MHz

Note that the two values of C-bands relate to the actual satellite in use and therefore may bechanged .

The administration or designer of the up-converters and down-converters in the earth station willknow the frequencies at the IF interface which correspond to the above values or they will knowwhat the IF frequency of a given channel is, eg CN11000.

For the C-band uplink, enter the frequency, in kHz, corresponding to CN0. If the IF frequencysupplied corresponds to another channel number, use the formula :

f0 = fif - (channel number / 400)

where fif is the IF frequency of the given channel and f0 is the channel 0 IF frequency. The chan-nel number corresponds to the stated fif.

For the C-band and L-band downlink signals, enter the frequency in Hz corresponding to CN0 plus21400.0. This correction factor accounts for the functional difference between modulation anddemodulation. The corresponding formula for other specifications is :

f0 = fif - (channel number / 400) + 21400.0

The following values should be entered when the equipment is installed and only changed if thereare changes in the RF frequencies -

C-band TX CN0 40750.0 kHzC-band RX CN0 62150.0 kHzL-band RX CN0 62150.0 kHz

Select the form, enter the Ocean Region and press . The values of CN0 cannot be alteredShowfrom the SOC.

7.3 Satellite Generation Change

There are two functions which are different for first and second generation satellites :

• the speed on the MSG and SIG channels

• the RF frequency of channel number 0 (CN0).

These two parameters are not completely dependent; it is possible to operate with first generationchannel speeds on second generation satellites.

Third generation satellites have the features of a second generation satellite plus the additionalcapacity to support spot beam operation. As far as LES operation and the facilities of the MMI go,such satellites are still referred to as "second generation", even though full spot beam operationsare supported. The frequencies, firmware and demodulator boards for third generation satellitesare the same as for second generation.

See also Section 7.8.


17th July 2001

7-8

The channel rates are controlled by an entry in the LES Definition SOC form as noted above andalso by the precise hardware used in the demodulator module.

The RF translation is controlled by the Satellite Parameter Definition SOC form which is alsodescribed above.

To change between first and second generation operation, if required, the following steps must betaken.

• Change the firmware in the demodulator Channel Units which are used for Messagechannels only, including any standby units. The appropriate firmware is availablefrom HNS if required. The firmware is contained in i/cs U11, U12 and U13 as follows:

U11 1010973 - 0001C CS 8D8A First generation1012930 - 0001A CS 8A48 Second, Third generation

U12 1010972 - 0001C CS FA58 First generation1012929 - 0001A CS C7DF Second, Third generation

U13 1010971 - 0001C CS AE5E First generation1012928 - 0001A CS C06A Second, Third generation

• Change the parameters in the LES Definition SOC form

• Change the parameters in the Satellite Parameter Definition SOC form

Note that different part numbers are allocated to the demodulator boards as follows :

• part number 1010501-0001 for first generation

• part number 1010501-0002 for second and third generation

If for any reason it is necessary to return boards to HNS for repair, please ensure that the correctpart number is used.

If there is a mismatch on the MSG demodulator between the satellite generation for which it isequipped and the entry in the database, the hex display on the front of the channel unit will show’5’ and the red LED will be illuminated.

7.4 Physical Channel Units

7.4.1 Channel Unit Rack Forms

One rack is associated with each Ocean Region. Its identity is defined to the system by that of theFEPs driving it; these are defined using the LES Definition form (see above). The Channel UnitRack Management form (SOC Forms - Satellite Interfaces - Satellite Equipment) is used tospecify the FEP port connected to the SDAP on the channel unit rack - this is normally set to ’7’ -and summarizes the state of rack related items as follows :

• CU rack control line, connected to SDAP - In Service or Out of Service

• master timing module state (there are two per rack) - In Service or Out of Service

Each entity is shown as In Service or Out of Service and the operator can enter a desired state totake it Out of Service or put it back to In Service.


7-9

For an existing rack, select the form, enter the Ocean Region and press to view the currentShowstate. To alter a state, press , enter the desired values and press . The state changeModify Enterwill be advised on the message line. The key can also be pressed periodically for an up-Showdate of the status.

The Channel Unit Rack Status Summary form (SOC Forms - Satellite Interfaces - SatelliteEquipment) is used to display and control the states of all components of the rack. Select the form,enter the Ocean Region and press to view:Show

• CURC IF : the interface link between the processor and the alarm module. Thisshould show Up

• timing received - indicates if the TDM RX channel unit is successfully receiving theframe timing generated by the TDM TX unit with loopback via the satellite. Thisshould show Y for correct operation. If it shows a N, then there is a fault - see section7.4.3 for the action to take.

• rack status

• blower status

• power supply status

• master timing module current and desired status

• master timing module redundancy mode : manual or auto

• setting of the switch on the ASM which enables local manual control of the mastertiming modules - set this to Auto normally.

The Channel Unit Rack Statistics report (SOC Viewer - Offline Processing - Options - ReportsGeneration) provides details of faults on the rack over a specified period. The operator can enterthe interval start and stop times and is given details of the operation of the links between the FEPand the channel unit rack and faults on the MTMs, blowers and power supplies.

7.4.2 Channel Unit Rack Failures

A number of alarms can be generated from the channel unit rack from the common equipmentserving the channel units. This set of alarms does not include the channel units themselves,which are indicated as failures of the associated function, e.g. TDM.

Channel unit rack failures will be indicated as class CU on the SOC display. Acknowledge in thenormal way and then take the following action :

• power supply : the two units feed the rack in parallel. Failure in one should not inter-rupt the operation of the rack, which can be quickly confirmed by ensuring that dis-plays are still present on the front of the modules. See the Channel Unit Operationsand Maintenance Manual, Reference [3], for the replacement procedures. Manyfaults can be dealt with by replacement of the plug-in modules from the front of therack. Only a major fault requires the complete replacement of the unit and switchingpower off the rack.

• MTM : check that automatic switchover has taken place by observing the LEDs on theASM next to the MTM and replace the faulty unit with a spare one. Before insertingthe spare, check that the switch settings are as in the unit being removed. They


17th July 2001

7-10

should agree with the list in appendix A.

• Blowers : any one of the nine fans can fail and bring up the alarm. First of all check ifthe failure is one or all of the fans. There are 9 separate neon lights visible from theback of the fan tray to show which are working. If all fans have failed, immediateaction should be taken. The most likely cause would be a failure of the mains input -check the power supply fuse and the rear plug. If only one fan has failed it should bereplaced, but the rack will continue to operate normally. Follow the instruction in theChannel Unit Operation and Maintenance Manual for replacement, which should onlybe carried out once the necessary parts are to hand.

7.4.3 Satellite Loop Delay Detection

The correct operation of the detection of the satellite loop delay is essential to the operation of thesystem, and in particular to reception of packets on the message channels. The Channel UnitRack Status Summary form has an entry Timing Received which should show Y for correctoperation.

If an N is shown, check that the indications on the channel unit rack are correct, as indicated insection 10.6. Perform any re-initialization or replacement of modules to re-establish the correctoperation.

If the hardware appears to be operating correctly, check that the TDM modulator and TDMdemodulator are correctly configured at the SOC and in particular, that the TDM demodulator isconfigured to receive loop timing on the TDM Rx using the TDM Rx Logical Channel UnitDefinition SOC form.

7.4.4 Channel Unit Chassis

Within each rack, the Channel Unit Chassis Definition form (SOC Forms - Satellite Interfaces -Satellite Equipment) defines for each chassis equipped the FEP port to which each half is con-nected and also displays the physical connection to each slot on the IF interface. The FEP portnumbering is set up in the factory as follows :

Chassis Number FEP Port FEP Port(on SOC) left half right half

Bottom CU 5 1 2Middle CU 4 3 4Top CU 3 5 6SDAP - 7

Note: that port 0 is reserved for software fault finding.


7-11

The chassis number shown above must agree with the setting of the switch marked Tray Addresson the channel unit backplane. This switch should be set as follows :

Chassis number Bit 1 Bit 2 Bit 3 Bit 4on SOC

0 Down Down Down Down1 Up Down Down Down2 Down Up Down Down3 Up Up Down Down4 Down Down Up Down5 Up Down Up Down6 Down Up Up Down

Select the form, enter the Ocean Region and chassis number and either press to add a newAddchassis or for an existing one. To change entries, press , enter the new values andShow Modifypress . To delete a complete chassis, press . Note: that the allocation of FEP portsEnter Deletemust not be altered. When deleting entries, ensure that no PCUs are defined in the chassis.

For each slot, specify whether transmit or receive and whether C band or L band. Remember thatL band transmit is not used.

Note: The form shows slots 0-15 and is arranged in two halves. The top half shows slots 0-7allocated to one FEP port number, each slot with its own C or L band and TX or RX allocation.The bottom half shows slots 8-15 allocated to another port number, again each slot with its own Cor L ban and TX or RX allocation.

The form contains details reflecting the way the rack has been wired, ie

• modulator, part number 1010495 and identified by blue extraction levers

• demodulator, part number 1010501 and identified by orange extraction levers.

To alter an existing configuration, take the chassis concerned Out of Service whilst any changesare made. Some satellite down time will inevitably result.

The configuration set up can be inspected on the Channel Unit Chassis Status Summary form(SOC Forms - Satellite Interfaces - Satellite Equipment). Call up the screen, enter the OceanRegion and chassis number and press to see, for each slot number for that chassis, theShowport, PCU overall status, band, direction, channel type and logical channel identity.

The Channel Unit Chassis Statistics report (SOC Viewer - Offline Processing - Options - ReportGeneration) shows details for each slot of the statistics collected on a regular basis. Call up theform, enter the Ocean Region and chassis number and press . The start and stop times ofReturnthe report are given, together with the following details :

• slot number : in the chassis, numbered 0 to 15

• polls : the number of polls between the software in the channel unit controller and thechannel unit

• response timeouts : to polls from the software


17th July 2001

7-12

• received CRC errors : the number of responses to polls received by the software withcorruption, as detected by the sum check on the packets

• CU ups : the number of times the CU went to In Service

• CU downs : the number of times the CU went to Out of Service

• framing errors : applies to demodulators only and shows the number of framesreceived in error

• Demod RX CRC errors : the number of packets received by the demodulator witherrors, as detected by the error check on the packet itself.

• Demod RX carrier loss : the number of times the demodulator lost carrier. This ap-plies to TDM demodulators only.

7.4.5 Channel Unit Backplane Failure

Analysis of the possible modes of failure of the hardware indicates that most cases can becovered by the replacement of a faulty module. There are spares on site for modulators,demodulators, BIM, ASM, MTM and the cards on the CUC and TIF racks. One obvious exceptionis the CU chassis backplane. If this fails, the immediate recovery action is to concentrate all trafficon the second chassis (if provided). The Channel Unit Operations and Maintenance Manual,Reference [3], provides details of how to physically replace the backplane.

The following procedure shows how to move all equipment from chassis 4 (which is assumed tohave failed) to chassis 5 (which is assumed to be completely free). Note: this procedure is errorprone and should be exercised with extreme caution.

1. Arrange the IF connections between the CU slots and the splitter/combiners onchassis 5 to be identical to those on chassis A4, ie the links from A5/A18/A1,A5/A20/A1 and A5/A22/A1 to the connection above each CU slot should look iden-tical to those in chassis A4.

2. Remove the cables going to A5/A17/J3 and A5/A33/J3 and tie back out of the way

3. Set the DIP switch marked Tray Address on the backplane in A5 to be identical tothat in A4.

4. In order to prevent two chassis with the same address, set the DIP switch markedTray Address on the backplane in A4 to be identical to that which previously existedin A5.

5. Move all the channel units from A4 to the same slots in A5

6. Remove the cables from A4/A18/J2 to A5/A18/J1 and from A4/A32/J2 to A5/A32/J1.Tie them to the rack for future use.

7. Remove the plug from A4/A18/J1 and insert in A5/A18/J1. Remove the plug fromA4/A32/J1 and insert in A5/A32/J1.

The channel units now in chassis 5 should be automatically initialized and configured in the nor-mal manner. Details of the identities of all the positions in the channel unit racks are contained infigure 1-3 of the CU Operations and Maintenance Manual

If some cards are already equipped in chassis 5, it will be necessary to reconfigure channel units


7-13

from chassis 4 to chassis 5 in the database, using the relevant procedures for physical channelunits described in this chapter.

7.4.6 Physical Channel Unit Forms

A physical channel number and its allowed functions must be allocated to each physical slot that isto be used. This is done on the Physical Channel Unit Definition form (SOC Forms - SatelliteInterfaces - Satellite Physical Channel). Call up the form, enter the Ocean Region and PCU iden-tity and press , or as appropriate.Show Add Delete

The PCU identity is described by the chassis number and slot number separated by a dot, eg

5.14 is slot 14 on chassis 5

Once an entry is displayed, i.e. TX or RX and use as TDM, MSG or SIG, it can be modified bypressing , entering the new data and pressing . An existing channel unit must beModify Entertaken out of service before its characteristics are altered.

When new channel units are added, it will be necessary to alter both this table and the IF connec-tion to the module; the latter is the co-axial cable from the connector above the channel unit back-plane to the combiner/splitter behind the backplane. New channel units will be supplied with thiscable and details of where it should be installed.

Note that a PCU must be identified using the above form and the function before it can beAddadded to a sparing pool. Also, before deleting a PCU, ensure that there is no logical channelassigned to it.

For individual channel units, the Physical Channel Unit Management form (SOC Forms -Satellite Interfaces - Satellite Physical Channel) displays the following :

• band - C or L

• transmit or receive direction

• PCU overall status - Up or Down

• PCU status code

• PCU status type

• PCU software version, in the firmware (this is included for reference only and has nooperational function)

• PCU frame number - TDM frame number which counts sequentially from zero at mid-night

• logical channel unit details in the form of channel type (TDM, MSG or SIG) and LCUnumber

Select the form, enter the Ocean Region and PCU identity and press .Show

The operator can force the processor on the channel unit to re-initialise by pressing .Reset


17th July 2001

7-14

7.4.7 Channel Unit Module Failures

Failure in an individual module will result in a spare (if available) being automatically substitutedfor the failed module. It is helpful to understand the mechanism of failure detection to see how thesystem is affected when a failure occurs.

CU failure detection/redundancy works as follows :

1. The software in the CUC FEP polls the channel units (CUs) frequently. ReceiveCUs are polled several times a frame (8.64 seconds). Transmit CUs are polledwhen there is data to transmit, but would not be polled if there is no data.Additionally, one CU is polled for detailed status every frame, and this is done alter-nately for every CU on each half chassis. As an example, if there are 3 CUs in ahalf-chassis and there is no data to transmit, then it could take 3 frames or 25seconds to find out that CU has failed.

2. The CUC software generates an event immediately if

• the CU reports a bad status, or

• the CU does not respond to a poll (actually, the software immediately retriesone time for a response timeout in case the response was corrupted).

There is no delay or hysteresis in reporting these events.

3. The software records the event in the event logger immediately but waits for 60seconds before taking any redundancy action. This is done for two reasons:

• If a Transmit channel unit is isolated, it will be 60 seconds before that CUresets due to watchdog timeout. It is desirable to avoid programming anotherModulator to take over where there would be the possibility of two CUs radiat-ing the same carrier for a minute. Instead, there is a wait of 60 seconds to dothe redundancy in expectation that an isolated modulator will reset itself.

• It is undesirable to switch unnecessarily in case of temporary line problemsbetween the channel units and the CUC. If the CU comes back up before the60 seconds are up, then there is no redundancy switch performed.

There is a risk here that if there is a CU which keeps going up and down, it will notbe switched out by the redundancy control.

4. If any CU problem persists for 60 seconds, the software performs a CU redundancyconfiguration change.

In the specific case of failure of the TDM demodulator due to the loss of the input signal, the failurewill be reported as an event, but then the module will be reconfigured and will search for the cor-rect input signal. Therefore, although the input signal is not present, the module will report itsstatus as ’OK’.

7.5 Logical Channel Units

Logical forms are associated with functional types of channel units.

Association of logical and physical channel units is made in a series of Logical Channel UnitDefinition forms (SOC Forms - Satellite Interfaces - Satellite Logical Channel Menu)


7-15

There are forms for :

• MSG

• SIG

• TDM TX

• TDM RX

Logical channel units can only be defined once their spare pool identities are known. For eachform, enter the Ocean Region and the LCU identity and press . To delete an entry, pressShow

. To modify an entry, press , enter the new spare pool number and press .Delete Modify Enter

The system will automatically select a physical channel unit from that pool but the PCU can alsobe specified with this form if it is desired to force a first choice. The operator must ensure that thePCU is part of the spare pool identified.

The following additional information is available/required for individual LCU definition forms :

• TDM TX : the TDM group and the frequency allocated to this channel are displayed

• TDM RX : the operator must indicate whether or not the satellite loop delay timing isto be derived from the channel - this must be done for one, and only one, TDM RXchannel in the rack and must always be operational to bring up a TDM group.Choose a permanently assigned TDM group if possible. For the nominateddemodulator, enter Y against the question Frame Timing, for any other TDMdemodulator, enter N. This form also shows the TDM frequency allocated.

Note: that a channel unit can only be deleted if it is not assigned to a TDM group.

• MSG : the operator can set a limit on the number of frames (0 - 255) over which theACSE allocates message channel capacity in advance; this in practice will normallybe left at its greatest value (255) but can be used to limit the mobile to shore traffichandled by the LES. The TDM group and frequency allocated to the message chan-nel are displayed on this form.

Note: that before deleting a MSG channel, ensure that it is not assigned to a TDMgroup.

• SIG : the use of the channel can be restricted to any or one of store and forwardservice, closed user group or distress, and also if supported: pre-assigned datareporting, land alerting and aero-c. The TDM group and frequency allocated to thesignalling channel are displayed.

Note: that a channel can only be deleted when it is not assigned to a TDM group.

7.6 TDM Groups

For operational purposes, channel units are associated in TDM Groups, using the TDM GroupDefinition form (SOC Forms - Satellite Interfaces - Satellite TDM Group). The system has beendesigned currently for only one group for an Ocean Region. For each group, enter the OceanRegion and TDM group number and press for the following :Show

• type of operation : normal or standalone. As the LES is designed to operate withoutan NCS, this should always be set to standalone.


17th July 2001

7-16

• spot id : set to ’0’ to denote global spot used (which is the only one available with firstand second generation satellites

• request permanently : set to Y.

• 2-frame slots : the position of the 2/3 frame boundary in the signalling channels.

• randomizing interval : The number of frames (1-255) over which a mobile randomlypicks a new frame to transmit a repeated SIG packet, when the burst received bit hasnot been set for the original attempt.

This form will display the LCU identities of the TDM RX and all the MSG and SIG channels al-located to the group.

The contents of this form should only be changed when the TDM Group is Out of Service.

The details can then be changed by pressing , entering the new values and pressingModify.Enter

Note that and are not operational at present.Add Delete

TDM groups can be managed using the TDM Group Management form (SOC Forms - SatelliteInterfaces - Satellite TDM Group). Select the form, enter the Ocean Region and TDM group num-ber and press . The information shown is as follows :Show

• TDM group desired status - INS is normal

• TDM overall status - UP is normal (read only)All possible indicators are:

• DN:Initial,No activity pending, TDM has yet to be requested

• DN:Requested,Awaiting frequency allocation.

• DN:Await FEP,Awaiting FEP response.

• Up,No activity pending.

• Up: Pend rel,Pending release, at least one call in progress/about to be released.

• Up: Grace,An event has started a timer, TDM will be released if this is not resolved beforethe timer expires.

• DN: Released,TDM has been released, awaiting confirmation.

• DN:TDM down, no activity pending.


7-17

• TDM assignment status as follows (all fields except congested are read only):

• assignment time - (not used)

• assignment duration - 0 (not used)

• current duration - Permanent

• previous release time - (not used)

• congested - this reflects the state of the congestion bit in the bulletin board andshould always be set to N. Do not attempt to use this as the recovery actionrequires the FEP software to be restarted.

• TDM flow control can be achieved using the following:

• two separate values for the number of outbound and inbound calls allowed.

Only the value for the number for inbound calls can be modified by theoperator.

Setting these to 0 will stop all traffic. This mechanism should be used when it isdesired to stop traffic on the TDM, for instance to take it out of service to alterbulletin board parameters.

• min outbound - (default 1) is the minimum number the LES can reduce thenumber of outbound calls to when the TDM exceeds a pre-defined loadthreshold.

• max outbound - (default 56) is the maximum number the LES can increase thenumber of outbound calls to when the TDM falls below a pre-defined loadthreshold.

• Throttle in - (default 60) is the percentage of the current traffic load for thatTDM the system can reduce to when the system exceeds a pre-defined loadthreshold, within a two minute period.

• Throttle out - (default 25) is the percentage of the current traffic load for thatTDM the system can increase by when the system falls below a pre-definedload threshold, within a two minute period.

• LCU status of all the channel units in the group. Only the frequency code can bemodified by the LES operator. The following values are shown:

• LCU ID - duplicate number can appear if the channel type is different

• channel type - TDM TX, SIG RX, or MSG RX

• frequency code - of that channel

• desired state - INS or OOS

• LCU status - UP or DOWN

• PCU ID - ie the chassis and slot being used for the LCU


17th July 2001

7-18

• PCU status - UP or DOWN

Use the keys to scroll through the LCU display.Arrow

To modify the state and frequency code (applies in Restoration working only) press , enterModifythe new values and press .Enter

To change the flow control limits on the TDM, press , enter the new values and pressModify.Enter

Allocations of all the TDM groups can be viewed on the TDM Group Summary form (SOC Forms- Satellite Interfaces - Satellite TDM Group). Enter the Ocean Region and press for a listReturncorresponding to each of the associated TDM groups. For each entry the following information isshown:

• TDM group ID - 1, 2, 3 etc.

• TDM frequency - of the TDM TX channel

• Spot ID - 0 (global beam only supported)

• TDM group status - UP or DOWN

• No. of signal channels configured - 1, 2, 3 etc.

• No. of signal channels up - 1, 2, 3 etc.

• No. of message channels configured - 1, 2, 3 etc.

• No. of message channels up - 1, 2, 3 etc.

Statistics are shown on the TDM Group Statistics Report (SOC Viewer - Offline Processing -Options - Reports Generation). Select the report, enter the Ocean Region and press .ReturnThe display shows:

• collection interval

• TDM frames, packets, split packets and bytes

• for each signalling channel : one slot and multislot packets, slots acknowledged andnot acknowledged and continuation slots.

7.7 Spare Pools

For redundancy purposes, channel units are grouped together in one or other pool. As a minimum,all the channel units in a pool must share the same IF interface and be either modulators ordemodulators. There must be set of pools for each ocean region served. All the channel units inthe pool must be physically of the same type, and occupy the same channel unit rack. Separatepools are required for C-band up, C-band down and L-band down. Providing there is one sparechannel unit for each pool the LES will continue to function whenever an active channel unit fails,although not if two active units fail from the same pool.

Further separation can be designated if, for instance, it was desirable to maintain separate poolsfor TDM channel units. This is necessary in the case of modulators if the transmit levels on the


7-19

TDM channels are different, since the standby unit must be set to exactly the same level as theunit carrying traffic.

Use a separate pool number for each group of units, splitting transmit and receive directions, andthe bandwidths used. Thus the minimum recommended pooling arrangement for each oceanregion served is:

• TDM transmit (C-band uplink)

• TDM receive (L-band downlink)

• MSG and SIG receive (C-band downlink)

Additional pools are needed if there are more than ten units in any pool or if it is preferred to havea pool for each channel unit type.

The Channel Unit Spare Pool Definition form (SOC Forms - Satellite Interfaces - SatellitePhysical Channel) is used to designate these pools. The pool is identified by Ocean Region and anumber in the range 1-64 for each pool.

A textual name for each pool and the directions must be defined, whether transmit or receive, andthe function(s) allowed must be indicated. Then the physical identities of all the units in that poolmust be entered.

Select the form, enter the Ocean Region and spare pool number and press for an existingShowone, for a new one or to remove an existing one. To change an existing entry, pressAdd Delete

, enter the new parameters and press .Modify Enter

Note the following limitations :

• do not change the pool name

• before adding a PCU, ensure that it has been defined

• if deleting a PCU, ensure that it is not assigned to an LCU

Complete a separate form, using a separate pool identity number, for each pool needed.

A summary of the status of all the sparing pools for a Ocean Region can be seen by invoking theChannel Unit Spare Pool Status Summary form (SOC Forms - Satellite Interfaces - SatellitePhysical Channel). Call up the form, enter Ocean Region and press . The resultant displayShowprovides information for each pool that has been configured for that Ocean Region:

• number of the pool (1, 2, 3 etc.)

• textual name of the pool

• the allowed use of the pool: one of TDM, MSG, SIG, ANY.

ANY is used where the pool can serve more than one type of channel, eg MSG andSIG.

• direction : transmit or receive (Tx or Rx)

• PCUs configured : total available for use


17th July 2001

7-20

• PCUSs in service : total of logical channel units whose current state is In Service

• PCUs in use : total assigned to logical CUs

• PCUs available : total not currently assigned to a logical channel unit

• PCUs up : total working

• PCUs down : total faulty

7.8 Spot Beams

A separate TDM group will be associated with each spot beam. One TDM group, from which thesatellite loop timing is derived, must be equipped on the global beam or on a spot which il-luminates the LES.

Sets of IF interface will be required - one for the global beam, if used, and one each for each ofthe other spots served. At the physical level, channel units must be identified as either serving aglobal beam or a spot beam which corresponds to a specific geographical area.

The spot identity is entered on the TDM Group Definition form and must be set to ’0’ (signifyingthe global beam), as only global spot beam operation is supported.

The Spot Beam Definition form (SOC Forms - Satellite Interfaces - Satellite General) allows theoperator to see, for each spot, the number of TDM groups assigned and the number of TDMgroups in service.

The operator can see and also set the maximum number of TDMs which can be in service. Thisvalue should only be set when the maximum number of TDMs value has been previously set forthe corresponding Ocean Region using the LES Definition form. The total of all the maximumnumber of TDMs for all the spots associated with that Ocean Region must not exceed themaximum number of TDMs value.

7.9 Changing the Configuration

7.9.1 Changing the Configuration of TDM Groups

When the configuration of a TDM group has to be changed, it must be taken out of service beforethe changes are made. However, a TDM group can only be taken out of service when there areno calls pending. To achieve this state, the call limits on the outbound and inbound routes shouldbe set to ’0’ to stop any new calls being set up, using the TDM Group Management form. Whenall existing calls have matured, the TDM group can be taken Out of Service.

7.9.2 Adding Channel Units to the System

Assuming that the racks and chassis in the system are defined (this will be done at installation),the first step in adding channel units is to assign Physical Channel Unit IDs (PCU IDs). Thisspecifies the physical location of the cards within the channel unit rack and specifies how the cardwill be used (TDM/SIG/MSG/ANY). The format of the PCU identity is C.SS where C is the chassisid (1, 2, 3) and SS is the slot number (00-15).

Once the PCU identities have been defined, they can be entered into the sparing pools. At thisstage the spare pool type (TX/RX) and the allowed use (TDM/SIG/MSG/ANY) is specified. A shorttext description can also be supplied. Each of the cards which is to be included in the pool mustthen be listed using their PCU IDs.


7-21

When cards are addressed their PCU IDs are not used. Instead they are addressed by LogicalChannel Unit IDs (LCU IDs). This allows the exact position of the cards to be altered withoutaffecting how they are addressed. It also allows different physical cards to be addressed by thesame logical address.

LCU IDs have a particular channel kind associated with them so there is a separate set of ad-dresses for each channel kind and link direction, i.e. there are TDM RX LCU IDs, TDM TX LCUIDs, etc. All of these must be set up individually. LCU IDs are numbered 1 to 6 for each separatechannel kind and link direction.

When defining the LCU ID for a card, two separate sparing pools can be specified, using theappropriate Logical Channel Unit Definition form SOC Forms - Satellite Interfaces - SatelliteLogical Channel, one of:

• TDM Rx Logical Channel Unit Definition

• TDM Tx Logical Channel Unit Definition

• Msg Rx Logical Channel Unit Definition

• Sig Rx Logical Channel Unit Definition

Currently, only Sparing Pool ID 1 is used. Sparing Pool ID 2 is used for more complex configura-tions which are not yet supported. The PCU ID to be associated with this LCU ID is then specified.

Various other information can be specified when defining LCU IDs as described below:

• TDM LCU IDs:

• RX - The initial service state (INS,OUT) can be specified. The channel unitracks can be told to generate their own framing timing signals using their MTMsor to use another rack’s timing signals. The TDM frequency code can bespecified.

• TX - The initial service state (INS,OUT) can be specified.

• SIG LCU IDs:

• RX - The initial service state (INS,OUT) can be specified. The SIG channelservices can also be switched on or off, dependant on whether the services aresupported for the customer. The services are: Store and Forward, Closed-UserGroups, Distress Traffic, Aero C, PADR Reserved, Land Alerting. If a particularservice is not supported the corresponding flag will be permanently set to off.(Slotted ALOHA is always on since it is a standard feature of the protocol).

• MSG LCU IDs:

• RX - The initial service state (INS,OUT) can be specified. The Maximum MSGchannel allocation, which represents the number of frames into the future toallow message space to be reserved, can be specified, although the defaultvalue (100) is generally used..

Now the LCU IDs can be added to the TDM Group. TDM Groups are numbered in the same wayas LCU IDs - from 1 to 6. There can only ever be a maximum of 6 TDM Groups per OceanRegion. TDM Groups beyond Group 1 are either required for additional traffic capacity or to sup-


17th July 2001

7-22

port additional spot areas. Each TDM Group operates on a different frequency (specified by itsfrequency codes).

When defining the TDM Group, using the TDM Group Definition SOC form, the following can bespecified:

• Channel Type (STDALN/NORMAL), always set to STDALN

• Spot, (always set to GBL)

• Request permanently flag always set to Y

• Number of 2-frame slots (this is always 0, as any other value is currently unsupportedby the protocol)

• Randomizing interval (1-255, but is usually set to 8 by convention)

• TDM TX LCU ID (which must have the same corresponding frequency as that for thecorresponding TDM Group ID).

• The LCU IDs for all the SIG RX and MSG RX channels in that TDM group are listedafterwards

7.9.3 Logical Channel Unit Addition and Deletion

To add a new Logical SIG Channel, the steps are shown below. In this example SIG_02 inChassis 2, Slot 6 is defined

1. Select the Channel Unit Chassis Definition form:

• Enter the Ocean Region and Chassis ID (2).

• Press , followed by and then move the cursor to slot (6).Show Modify

• Type C, followed by RX, and then press .Enter

2. Select the Physical Channel Unit Definition form:

• Enter values for Ocean Region and then PCU ID (2.06).

• Press .Show

The message Record Does Not Exist will then be displayed.

• Enter the Ocean Region and press again.Add

• Enter RX in the RX/TX field, and SIG in the Allowed Use field, and then press.Enter

3. Select the Channel Unit Sparing Pool Definition form:

• Enter the Ocean Region, and the Sparing Pool ID (3, for SIGs), and thenpress .Show

• Press , and move cursor to down to the next available entry.Modify


7-23

• Enter the PCU address (2.06) and press .Enter

The PCU is now in the Sparing Pool.

4. Select the Logical SIG RX Channel Unit form:

• Enter the Ocean Region and the LCU ID (2), and press .Show

The message Record Does Not Exist will then be displayed.

• Enter the Ocean Region and the LCU ID (2) again, and press the .Add

• Enter the ID of the Sparing Pool used for SIGs (3) into the Sparing Pool 1field, and the PCU defined for the LCU (2.06) in the PCU ID field.

• Mark Desired State as INS, and Y for all the services and press .Enter

5. Select the TDM Group Management form:

• Mark the TDM as OUT (Out of Service).

6. Select the TDM Group Definition form:

• Enter the Ocean Region, and the TDM Group ID, and press followedShowby press .Modify

• Move the cursor down to where Logical SIGs are defined and enter new LCU(2).

• Press .Enter

This will result in SIG_02 being assigned to the TDM Group.


• Mark the TDM as INS (In Service).

The TDM will now be available with an additional return channel.

The steps to delete a Logical SIG Channel are shown below. In this example SIG_02 in Chassis2, Slot 6 will be deleted.


• Mark the TDM as OUT (Out of Service).

2. Select the TDM Group Definition form:

• Enter the Ocean Region, and the TDM Group ID, and then press fol-Showlowed by .Modify

• Move the cursor down to where Logical SIGs are defined and delete the LCU(2) (overwrite with spaces), and then press .Enter


17th July 2001

7-24

This will result in SIG_02 being removed from the TDM Group.

3. Select the SIG RX Logical Channel Unit form:

• Enter the Ocean Region and the LCU ID (2), and then press , followedShowby and then .Delete Enter

4. Select the Channel Unit Sparing Pool Definition form:

• Enter the Ocean Region, and the Sparing Pool ID (3, for SIGs), and thenpress , followed by .Show Modify

• Move cursor to the PCU address (2.06) and delete (overwrite with spaces),and then press .Enter

This will result in the PCU being no longer in the Sparing Pool.

5. Select the Physical Channel Unit Definition form:

• Enter the Ocean Region and the PCU ID (2.06), and then press , fol-Showlowed by and then .Delete Enter


• Mark the TDM as INS (In Service).

The TDM will now be available with one fewer return channel.

To Add or delete a logical MSG Channel the process is similar to that described above for a SIG,except that the Sparing Pool is 4, and when you use the Logical MSG RX Channel UnitDefinition form, there is a Max Allocations field, which is normally set to 100.

The above sequence for updating the forms must be adhered to, because functions on someforms require cross checking into other tables (forms) in the database. If operations are done outof sequence the operator will be usually be notified with an error message.

7.9.4 Procedure for Defining and Deleting Sparing Pools and TDM Groups

Defining sparing pools and TDM groups follows a logical progression of :

- CHASSIS- PHYSICAL- SPARING- LOGICAL- TDM

Note: that new TDM Groups cannot currently be added.

Changes to each level must be complete before changing the next level.

In more detail, the steps to define a sparing pool are :

1. Define each chassis using CU Chassis Definition .


7-25

2. Define each PCU ID for each card using Physical CU Definition .

3. Define each Sparing Pool using CU Spare Pool Definition .

4. Define each LCU ID using:

• TDM RX Logical CU Definition

• TDM TX Logical CU Definition

• SIG RX Logical CU Definition

• MSG RX Logical CU Definition

5. Define TDM Group using TDM Group Definition .

6. Define TDM Group frequency codes if in standalone mode using TDM GroupManagement .

7. Bring TDM Group into service using TDM Group Management .

The procedure for deleting a sparing pool and TDM group follows the progression :- LOGICAL- TDM- PHYSICAL- SPARING- CHASSIS

In detail the steps are :

1. Put TDM Group out of service using TDM Group Management .

2. Delete all LCU IDs in TDM Group using:

• TDM RX Logical CU Definition

• TDM TX Logical CU Definition

• SIG RX Logical CU Definition

• MSG RX Logical CU Definition

3. Delete TDM Group using TDM Group Definition .

4. Delete PCU IDs using Physical CU Definition .

5. Delete Sparing pools using CU Spare Pool Definition .

Notes:

1. The order of deletion is NOT the reverse order of definition.

2. Each level of object makes reference to another object which must be deleted after-wards and not before:


17th July 2001

7-26

• LCU IDs reference the TDM Group

• LCU IDs reference Sparing Pools

• Sparing Pools reference PCU IDs.

• PCU IDs. reference Chassis IDs.

7.10 Satellite Side Operational Procedures

7.10.1 Channel Unit Startup Sequence

When a channel unit is inserted in the rack or reset using either the Physical Channel UnitManagement form (SOC Forms - Satellite Interfaces - Satellite Physical Channel) or the switch onthe front of the channel unit, it performs a self-test sequence. The Hex display on the front of thechannel unit will indicate ’0’ at the start of this sequence and ’9’ after several seconds to indicatethat initialization is complete.

If the physical channel unit slot is configured in the database, the software will then proceed toconfigure the channel unit according to the information in the database - eg TDM. This configura-tion process takes several seconds more, but after no more than 30 seconds, the normal indica-tions shown in section 10.6 should be displayed.

If the channel unit remains at ’9’ or does not show the anticipated display, check the databaseusing the forms described in this section, to ensure that the correct information has been entered.Of course, if the position in the chassis was previously in use, no change should be necessary.But beware of the situation where a standby, in the appropriate spare pool, was switched intoservice. In this case, a newly installed channel unit may remain at 8.

When bringing into service a complete TDM group, the following sequence of events should beobservable on the channel unit rack.

1. Initially, TDM modulator displays ’9’ or ’8’ and the TDM demodulator, MSG and SIGmay display ’9’, ’8’ or their correct configurations. The lower LED on both MTMs willshow red. (The red LED on the BIMs will also be illuminated, but this only repeatsthe MTM indication.)

2. The TDM modulator is configured with the appropriate frequency and starts trans-mission. The display goes to ’E’ and the ’Carrier On’ LED is illuminated.

3. The TDM demodulator, MSG and SIG demodulators will be configured and indicate’A’, ’A’ and ’B’ respectively

4. The TDM signal is detected on the demodulator and the hex display goes to ’C’ forone frame (8.64 secs) and then to ’E’ (or ’D’ - this is equally valid), where it remains.With each frame, the ’Demod Lock’ LED flashes. The red LED on the MTMs isextinguished.

5. On the CU Rack Management form, the status of (CURC I/F is Up and the MTMTiming Received is Y. This static state will remain.

This start-up sequence is followed if at any time the TDM group is taken into and out of service (egFEP changeover).


7-27

7.10.2 Network Failures

Failures in the class NET can be in the TDM TX, TDM RX, MSG, or SIG channel units. At leastone TDM RX channel is provided, tuned to a TDM TX frequency so that the satellite loop timingcan be determined. The flashing of the Frame Detect LED on the front of the TDM RX unit every8.64 secs is a constant indication that the satellite path is functioning correctly.

If a failure is reported, first of all check whether it is an isolated failure. If all the channels sharingone IF interface fail at the same time, a common cause such as the RF chain is likely.

If the failure is isolated, the channel unit itself is the prime suspect. Replace the faulty unit. Thesystem should already have automatically substituted a standby. To check, determine the state ofthe spare pool by using the appropriate Logical Channel Unit Definition SOC form to find out thespare pool number and then use the Channel Unit Spare Pool Status Summary SOC form tocheck that there are now sufficient operational units in that pool, followed by checking this is thecase by using the respective LCU Definition SOC form.

7.10.3 RF Equipment Failure

Failure in the RF equipment is reported under the NET class on the summary display on the SOC.This alarm directly reflects the state of the input indication (on or off) from the RF equipment.Acknowledge the alarm and contact the staff responsible for the RF equipment to determine thecause of the failure. In the meantime, it is likely that the satellite interface will be non-operationalbut handling of messages on the terrestrial side will continue without interruption until the mes-sage queues are full.

7.10.4 Channel Activity Monitoring

The system monitors the activity on Message and Signalling channels and generates an alarm ifthe channel is inactive for a preset period. The timers provide an approximate measure of thetime during which there was no activity on the channel. Restart of activity on the channel is alsorecorded in the event log.

The timeout is set independently for the message and signalling channels as two groups. It is notset for each individual channel.

It is also possible to set the timers for PEAK and NON-PEAK hours, so that traffic differencesduring the day can be accommodated. In this context, PEAK is usually set for daytime and NON-PEAK to night time.

SIG PEAK -- 60 minutesMSG PEAK -- 65 minutesSIG Non PEAK -- 90 minutesMSG Non PEAK -- 90 minutes

PEAK 06:00 to 18:00Non PEAK 18:00 to 06:00

which represents timeout values of 60 minutes during the hours 06:00 UTC to 18:00 UTC and 90minutes during 18:00 UTC to 06:00 UTC on both channels.

These values are factory set.


17th July 2001

7-28

7.10.5 Internal Timers

The ACSE uses a number of internal timers which are normally configured during installation ofthe equipment but which can be altered by the operator. Do so only after careful considerationof the consequences.

The timers in the ACSE are listed below. The timeouts with numbers less than T100 are timeouts,defined in ref 1; other timeouts are specific to the LES.

Note: The timers specific to NCS and ISL links are not used.

T11, -- for MES to be deemed idle after contact with the CEST12, -- for MES announcement responseT13, -- for test request from MEST14, -- for NCS response to announcement or poll requestT15, -- for MES unreserved access to MES signalling channelT16, -- for MES messageT17, -- for MES reserved access to MES signalling channelT18, -- for MES test responseT19, -- for MES distress testT20, -- NCS timeoutT21, -- NCS timeoutT22, -- NCS timeoutT32, -- for NCS during distressT33, -- for MES to acquire TDMT34, -- for NCS in queued announcementT43, -- for LES during distress (ref 1. T33 at NCS)T44 -- for TDM assignment hold time (ref 1. T34 at NCS)

T100, -- for CUC response in Ship-Shore message transferT101, -- for CUC response in Shore-Ship message transferT102, -- for CUC response in PVT Test Result transferT103, -- Time to wait for an EGC AckT104, -- Time to wait for a response from the NCS to a pollT105, -- CUC, input message transfer timeoutT106, -- CUC, input retransmission timeoutT107, -- CUC, Acknowledgement response timeoutT108, -- CUC, Assignment response timeoutT109, -- CUC, database update intervalT110, -- Time to wait for ISL congestion to clearT111, -- SpareT112, -- SpareT113, -- SpareT114, -- SpareT115, -- SpareT116, -- SpareT117, -- SpareT118, -- Time before retrying with TDM Request after a TDM

-- Request Response indicating pending.T119, -- Timeout on TDM Request and TDM Release packet

-- responsesT120, -- Delay period before retrying outbound call

Recommended values are as follows (although some timers have been changed at particular in-stallations) :


7-29

Timeout Suggested value Timeout Suggested valueIdentity (seconds) Identity (seconds)

T11 130 T100 1200T12 120 T101 1200T13 0 T102 600T14 45 T103 30T15 195 T104 30T16 300 T105 30T17 30 T106 30T18 95 T107 30T19 420 T108 30T21 60 T109 30T22 60 T110 30T32 45 T111 30T33 25 T112 30T34 300 T113 30

T114 30T115 30T116 30T117 30T118 1200T119 90T120 300

To change a timer, the steps are :

1. Use the Inmarsat-C Timeout Entry Definition (SOC Viewer - Online Processing -Database Access - User Services Database Access).

2. Show the current entry for the timer by typing ’S’ followed by ’Tn’Return Return(where n is the number of the timer to be changed).

3. Modify the entry for the timer by typing ’M’ ’Tn’ ’requiredReturn Return Returncurrent value’ ’required default value’ ’Yes’ .Return Return Return

4. Repeat the and operations for each of the timers which requireShow Modifychanging.

5. Force a BAP switchover to bring the new values into use.

[opg7.mss]

Message Handling A4-OPG-003076Issue 3.23 - Accepted

17th July 2001

7-30

A4-OPG-003076 Message HandlingIssue 3.23 - Accepted17th July 2001

8-1

Chapter 8

MESSAGE HANDLING

8.1 Introduction

This chapter shows how messages are routed through the system. It also shows the operatorhow to find out about messages which the system is in the process of handling or has recentlyhandled.

Message routing is one of the principle functions of the ACSE. The operator has considerableflexibility to set up the rules to be used for routing messages between the satellite side and thevarious terrestrial networks and vice-versa.

The system is designed for sending message

• from shore to mobiles

• from mobiles to shore

• from mobiles to mobiles

Messages in this context include :

• store and forward messages

• data reports

• polls

• EGC messages

It is not possible to route messages from a terrestrial network back to any terrestrial network, but aterrestrially originated message can have the ACSE itself as the destination.

To perform message handling, the ACSE has to :

• validate the address

• determine the address required to forward the message to its destination - this isknown as address translation

• determine a route on which to send the message

The address translation process is necessarily complex in the mobile to shore direction sincethere is a variety of routes which can be used and it is often necessary to translate the addressreceived from the mobile into a different address (or at least alter the first few digits of the ad-dress). However, addressing is simpler for messages to mobilessince the terrestrial network splitsterrestrially originated telex messages into categories - unregistered message submission, regis-tered access and message status enquiries - which simplifies the processing which must be per-formed at the ACSE .

The ACSE uses Routes to associate a given address with a set of physical circuits which connectto, or towards, the desired destination. Physical circuits are associated with routes as described inchapter 6. Once the route has been determined from the initial address, the software driver for


17th July 2001

8-2

that interface can attempt to deliver the message.

Special arrangements are made for the routing of certain categories of messages. For exampledistress alerts and distress messages from mobiles are automatically routed to a preset address,i.e. the MRCC position, which also has a back-up address. Similarly land mobile alerts are routedto an address associated with the originating mobile, or if none specified to a default address.

8.2 How Messages Pass Through the System

8.2.1 Shore to Mobile Messages

In the terrestrial to mobile direction, the only routes available are :

• one or more ocean regions served by the ACSE

• the ACSE itself for registered access

• the ACSE itself for message status enquiries

The route is indicated by different addresses and interface mechanisms from the terrestrial net-work. Therefore, when a connection is set up to the ACSE, the ACSE already knows the route.The only exception is where more than one ocean region is served, in which case the mobile listshows the route to be taken by the message.

Basic parameters are set up in the system to indicate which ocean regions are served. Withineach satellite interface, channel unit hardware is configured as described in chapter 7.

Messages to mobiles reach the LES by various terrestrial interfaces and use the protocols foreach specific interface. It is important, however, to understand the different routes which areavailable. These are described in more detail in the System Manual, Reference [2], but are sum-marized here.

Three route types are available for telex subscribers as illustrated in figure 8-1 :

• TSAP1 - for single-stage unregistered access. The address presented to the LES isthat of the mobile itself, including the ocean region prefix for telex: 58<n>, where n =1 (AORE), 2 (POR), 3 (IOR), 4 (AORW), 0 (non-Inmarsat). This service is availableto any telex subscriber.

• TSAP3 - for registered user access to the enhanced services available over telex.The address used by the caller to reach the LES has no value at the LES. Once theuser is connected to the LES he follows a set pattern of interaction illustrated in figure8-2. The detailed dialogue is described in an appendix to the System Manual.

• TSAP4 - for enquiries on the status of messages submitted over TSAP1. The stepsfollowed are described in figure 8-3. (The status of messages from registered usersare obtained via TSAP3 access).

Additional routes of each type may be defined to access different networks or define differentcharacteristics.

A single route is used for access via each PSDN network used (usually one).

One or more routes for access via the PSTN from terminals using asynchronous modems. Onceconnected, the access is as for PSDN terminals except for minor differences in the manipulation of


8-3

Telex Subscriber

TelexSwitched Network

LES

TSAP1

Ocean Region

andMobile Number

TSAP3

No usefuladdress

information

TSAP4

No useful adddress

information

Outgoing

Telexmachine

Leased Line

Figure 8-1. Telex Access Mechanisms


17th July 2001

8-4

Connect toLES

PIN

Answerback check

LES gives prompts + caller responds as per Interface Descriptions

in System Manual

Final question is"Dialogue concluded?"

Connection cleared

Registered Telex TSAP3

Y

N

Figure 8-2. TSAP3 : Telex Registered User Access


8-5

Connect to LES

User suppliedMRN + Time

of acceptance

LES supplies status of message

Call cleared

TSA4 Message Status Enquiry

Figure 8-3. TSAP4 : Telex Unregistered Message Status Enquiry


17th July 2001

8-6

terminal characteristics.

The transactions via PSDN follow a similar pattern to that for telex registered users (Figure 8-2),since all PSDN subscribers are registered at the ACSE.

The LES does not offer access from PSTN facsimile terminals.

See section 8.2.6 for a description of message delivery.

8.2.2 Mobile to Shore Messages

Messages from mobiles reach the LES according to the protocols laid down in ref 1. For thepurposes of understanding how the ACSE handles messages, figure 8-4 shows the relevantsteps.

The mobile selects the LES it wants to send the message to and checks that it can use the LES,i.e. that at least one TDM group is in service at the LES, the service required is available from theLES and the congestion bit is not set. The mobile then sends a Request Packet to the LES. TheACSE checks that the mobile is acceptable and that the address information received is valid, i.e.the destination network is supported by the ACSE. The LES then sends a Logical ChannelAssignment and Time of Message to the mobile, telling it when the message can be sent and onwhich message channel.

The first message packet contains the full address, which the ACSE checks as follows :

• the part of the address which identifies the destination country (e.g. the DNIC onPSDN) is valid

• the address extension is valid (which includes those cases where no address exten-sion is required)

• the number of characters in the address is within valid limits

Each message packet received is checked for errors; retransmission of any corrupted packets isrequested. When the whole message has been received at the ACSE, an acknowledgement issent to the mobile, if it was requested at the beginning of the transaction, and the message isstored securely. The ACSE can then begin the process of delivering the message to therecipient(s).

The address presented by the mobile is not necessarily the same as the address passed on to theterrestrial network. For instance, the country code may have to be removed for messages to thecountry in which the LES is sited. It is also necessary to validate the country code received fromthe mobile.

Messages are delivered to :

• mobiles

• telex addresses, using an outgoing trunk telex route as shown in figure 8-1

• PSDN addresses, using the same X25 lines as used for terrestrial originated calls,although some virtual circuits on the PSDN links can be limited to traffic in either theincoming or outgoing direction.

• PSDN addressing may be used to access the PSTN network for calls to terminalshaving a dial up asynchronous modem.


8-7

Mobile to shore message

Mobile selectsLES

Request packeton SIG

LES checks for mobilein OR + Destination

network in SIG received in

"Logical channel assignment"or

"Time of message" sent to mobile

Message packets

LES checks address foraddress length and address

extension fields

Message receivedOK

Retransmission of failed packets requestedMessage acknowledged

(if requested) + stored

Y

N

Message readyfor delivery cycle

Figure 8-4. Mobile to Shore Message Flow


17th July 2001

8-8

• PSTN for facsimile

• the ACSE operator

Message delivery is attempted as soon as the message has been securely received from theoriginator.

The address information in the call announcement packet and in the beginning of the messagepacket is used to select a terrestrial route. Once a route has been selected, the routing infor-mation described in section 6 is used to route the message to a physical circuit.

The address information from a mobile consists of

• Destination network

• Address, the format varies according to the presentation code

• Address extension, for additional information in certain specific cases, according tothe presentation code

Refer to ref 1 for a definition of which destination network codes support address extension fields.Where address extension fields are allowed, they are configured for each LES according to theservices available in the terrestrial network. Table 8-1 lists some of the possibilities :

Destination Extension Typical Address ExtensionsNetwork Allowed and Notes

Telex no

PSDN no

PSTN yes T30 for Fax (group 3)supported

Vnn for Async (where nn is valid modem

communication standard).supported

CNID no (Also referred to as DNID)

SAC no Can be used for translation within ACSE

CSDN no (Not supported)

X400 no (Not supported)

Mobile Number no

Ocean Region no

Table 8-1. Destination Networks and Address Extensions


8-9

Note 1: that telex in the above case refers to the switched network.

The ACSE checks that the address extension presented by the mobile is valid.

There are some additional facilities for mobile to shore messages, i.e. :

• special access codes, where the ACSE database contains a translation from the codereceived from the mobile to the terrestrial address.

• maritime distress alerts and distress messages, which are routed to a preset address,or if this is busy or cannot be reached, to a preset backup address

• land mobile alerts, which are routed to preset addresses

• messages can be sent to destinations within the ACSE, e.g. a DNID file

For mobile to shore messages, the operator has the ability to control the following :

• Address validation

• Translation of each allowable combination of presentation code, address and addressextension as received from the mobile into a terrestrial route

• Ocean regions served by the LES

• Distress message handling, including the delivery addresses

• Address for undeliverable non-delivery notifications (otherwise known as the Spill-outAddress)

• Special Access Codes translations

Message delivery is attempted as soon as the message has been securely received from theoriginator.

8.2.3 Messages between Inmarsat-C Mobiles

In the case of mobile to mobile messages, the ocean region address contained in the mobile list isused to route the message to the appropriate ocean region, provided that ocean region is servedby the ACSE. If the mobile is in an ocean region not served by the ACSE , and if a telex formataddress has been supplied by the calling mobile, the message may be routed over the telex net-work. In general non telex addresses are not routed via the terrestrial network, and such mes-sages are therefore rejected. Whether or not mobile to mobile messages, where the destinationmobile is not in an ocean region served by the LES, are delivered, is dependant on the values inthe routing tables, and this is under the control of the operator.

8.2.4 Address Validation

Addresses are validated against a list held in the database. This list also shows which translationsare to be performed. Separate entries are required in the list for each terrestrial interface type -telex, PSDN , PSTN etc.

The country code definition is accessed through Country Code Definition (SOC Viewer - OnlineProcessing - Database Access - Message Handler Database Access). The operator is able toperform the following :


17th July 2001

8-10

• Add entries

• Delete entries

• Show entries

• Select an entry with a given match

• Modify entries

The address format is indicated as one of the following :

• TELEX_FORMAT

• PSDN_FORMAT

• PSTN_FORMAT

• SPECIAL_ACCESS_CODE_FORMAT

• MOBILE_NUMBER_FORMAT

• CSDN_FORMAT (not supported)

• X400_FORMAT (not supported)

• CNID_FORMAT

• OCEAN_REGION_FORMAT

• UNKNOWN_FORMAT

Only where TELEX_FORMAT, PSDN_FORMAT or PSTN_FORMAT is specified, does validationon the associated country code occur.

The underscore ’_’ must be entered, but either upper or lower case letters can be used.

The Delivery Driver should be selected (using upper or lower case letters) from :

• Type_B for delivery by trunk telex .

• X25 for PSDN

• X25 for asynchronous terminals connected to the PSTN but accessed by modemsconnected to the LES X25 interface via a PAD.

• G3FAX for delivery by facsimile over the PSTN

The need to specify the delivery driver in this way is to allow complete flexibility in the way trans-lations are performed.

The other entries required in this table are :

• Country code string - as received from the mobile


8-11

• Country code string length, i.e. the length of the above field

• Substitution string - the string which is to replace the received country code string.This field will be left blank in the majority of cases.

• Substitution string length, i.e. the length of the above field

• Extension string - to match the address extension field received from the mobile. Thisis a further qualifier for matching the address information as received from the mobilewith the translation to be performed. There is no equivalent in the address infor-mation passed on to the terrestrial network.

• Action substitution - set to true if the substitution string is to be used or false if nosubstitution is required.

If the country code is not to be passed on to the terrestrial network, set the substitution string asblank and the action substitution field to true.

Entries are required in this table for all valid addresses which can be received from the mobiles,for each of the terrestrial interfaces.

8.2.5 Presentation Code Validation

Rules governing whether or not routing is allowed for a given address format, message directionand presentation code are summarized in the System Manual, Reference [2].

8.2.6 Message Delivery

Messages for delivery are queued and dealt with in turn. If the first delivery attempt fails, a retrycycle is entered. The number and frequency of retries is variable, depending on the reason forfailure. For example, if a terrestrial address is busy, several repeat attempts can be made at shortintervals until delivery has been achieved. On the other hand, if the address is not valid, repeatattempts are not of any value.

If messages cannot be delivered after the retry sequence has been exhausted, a Non DeliveryNotification is sent to the originator. Section 8.3.11 shows how the address is derived. Similarly,mobiles and registered terrestrial users can choose to receive a Positive Delivery Notification. If anon-delivery notification cannot itself be delivered, typically this would be because a terrestrial ad-dress could not be ascertained, the non-delivery notification will be forwarded to a spill-outaddress. This is usually the ACSE operator, who should then take steps to advise the originator, ifpossible, by other means.

Messages queued on an active queue by the message scheduler will be periodically checked toensure that they are not stuck. Any message queued for a period greater than the default of 600seconds will be checked. If the time queued is greater than an expected maximum, a function ofthe message type and length, then an event is generated. See the MSCH events in chapter 11 fordetails of the event and any necessary operator actions.

On the satellite side, delivery may be delayed if an interruption occurs on the TDM channels, mes-sages will be held until the channels become available again. A factory set timeout, set to 1 hour,limits the time which such messages remain active in the system. Thereafter, they are discardedand a non-delivery notification sent to the originator.’}

Note: there is no NCS and no ISL link. Call announcements are made directly over the TDM.Internally, the LES still maintains a queue called the "ISL queue" for messages which are normally


17th July 2001

8-12

sent to the NCS for delivery, i.e. Polls, EGCs and delivery notifications.

Before delivery of messages to a terrestrial address, the ACSE checks to see if there is already amessage for that addressee which is in the course of being sent. If there is, the second messageis held in a queue, until the first message delivery is completed, in order to allow the first messagedelivery to be completed.

Message delivery can take place to one or more recipients. Figure 8-5 outlines the steps whichthe ACSE takes to deliver a message, whether it be to a mobile or a terrestial address, to a singlerecipient. The case of multiple-addressed messages is described later.

Message delivery starts when a complete message is stored securely in the system and is com-plete when either :

• a message has been sent to a mobile which has returned an acknowledgementpacket over the satellite

• a complete message has been delivered to the terrestrial recipient.

Since the ACSE is a store and forward system, it can make several attempts to deliver a mes-sage. If the first attempt succeeds, the fact is recorded in the database by entering the appropriateCall Completion Code.

If the delivery was not successful, the ACSE makes one or more repeat attempts, depending onthe failure cause in the first instance. In the particular case of maritime distress messages andalerts, the repeat attempt is made immediately, using the secondary address. The primary andsecondary MRCC addresses are defined using the Maritime Distress Destination Definitionform (SOC Forms - Message Handler - Message Routing).

Re-attempt tables are set according to the delivery network:

• Satellite Reattempt Table for delivery to mobiles

• X25 Reattempt Table for the PSDN

• Telex Reattempt Table for telex

• Fax reattempt settings (see section C.8).

In the case of multiple address messages , the steps in figure 8-5 are followed for each addressin turn. Delivery to the first address is tried and, whether successful or not, delivery to the nextaddress is immediately tried. A separate call completion code is entered for each address. Re-attempts, when necessary, will be tried after all addresses have been tried once. This cycle isrepeated until all attempts to all addresses are exhausted and call completion codes are enteredagainst each address.

8.2.7 Message Cancellation

The satellite protocol is not infallible and it is possible for messages to get stuck in the system.The messages currently in the system can be viewed on the Call Record Summary Display(SOC Forms - Message Handler.

Alarms will be raised if the system detects a suspected stuck message as discussed in section8.2.6 Message Delivery. Use the Call Record Summary Display form to confirm this (SOCForms - Message Handler Menu).


8-13

YES

NO

YES

YES NO

NO

SUCCESS

MESSAGE FOR DELIVERY

ATTEMPT DELIVERY

SEND NDN DELAY

TRANSACTION COMPLETE

MAKE ANOTHER ATTEMPT

?

PDN REQUESTED

SEND PDN

Figure 8-5. Message Delivery cycle


17th July 2001

8-14

If the message is a Satellite call, then it may be cancelled from the Call Record Full Display(Select the message by placing a ’Y’ in the left hand column and pressing to accessFull Generalthis display.) The messages can be cancelled by using the function key.Cancel

If the message is not actually stuck on the satellite, the cancel instruction will be rejected and theoperator advised. There are two possible causes of this rejection :

• the call is stuck on the terrestrial side because a circuit is locked up. In this case thecircuit should be cleared manually

• the handling of the call has been transferred from one part of the system to anotherwhile the operator was requesting information about it. In this case, check the sum-mary display again and repeat the instruction if the message is still shown as active.

This cancel function takes a few minutes to filter through the system and can be confirmed byreturning to the Call Record Summary Display and pressing .Summary

8.2.8 Delivery of Messages by Facsimile

Text messages (in IA5 only) which are addressed for delivery by facsimile are passed by theACSE to the FAX PC, which makes the PSTN connection to the called address(es) and performsthe transmission in facsimile format.

The FAX PC can handle up to four simultaneous transmissions, dependant on line availability,with a pre-set number of reattempts and reattempt interval in those cases where it is not possibleto send to the required FAX number.

The FAX PC will eventually report back to BAP the delivery status of the message.

The system can support up to four FAX PCs giving up to 16 simultaneous FAX deliveries.

opg8_inc3.mss

8.3 Setting Up the Message Handling Database

8.3.1 Routing Tables

The routing tables are the means by which the ACSE is configured to select the route on which agiven message will be transmitted.

In general, the translations required between the address from the mobile and the terrestrial routeare quite simple; for instance all normal telex calls will go to the international exchange. However,there will be exceptions to this and to support all the possible permutations of routing, a complexanalysis process in the software has been developed.

This analysis process is based on looking for those exceptions first; the forms which configure theanalysis reflect those exceptions. Some thought is therefore necessary to determine how theanalysis should take place before the configuration is entered in the database. Care should alsobe exercised when adding new routes; wherever possible a new route should be tried out as soonas it is added to the system and before any more routes are added.

Only valid addresses have translations, so there must be an entry for all valid addresses. Ingeneral, it is only necessary to enter a subset of the address, e.g. a route selection for all ad-dresses beginning ’581’ can be set up with one entry, as explained below.


8-15

Before any route translations are entered, they should all be listed and an offline record of themshould be retained.

Decide the order by determining the most precise exceptions first. This example should illustratethe principle.

Take the first three digits of the address as presented from the mobile with the routing to be asfollows:

111 directs the message to route 1112-119 directs the message to route 2120 onwards directs the message to route 3.

The most precise exception is the address for route 1, the next that for route 2. The followingentries made in the following order will achieve the desired result:

entry 1 111 ---> route 1entry 2 11 ---> route 2entry 3 all ---> route 3

It will be seen that only 3 entries are needed, not 999 as might otherwise be necessary.

If it was now desired to add a routing of:

112 to route 4,

the above should be changed to:

entry 1 111 ---> route 1entry 2 112 ---> route 4entry 3 11 ---> route 2entry 4 all ---> route 3

In fact, entries 1 and 4 could be in either order - if subaddress 112 is more likely than 111 then theordering of the entries 1 and 2 should be switched.

As stated before, the ordering of the entries is important. Therefore, if the new entry for sub-address 112 is to be inserted into the table, the operator will have to shuffle the existing entriesfurther down the table. This shuffling can be avoided if the following mechanism is adopted.

It is good practice to allow some sort of contingency for new entries to be added between existingones. This may be done by treating the table entry numbering like BASIC program line number-ing, that is to make the first entry 10, the second entry 20, the third 30, etc. If it is necessary toadd an entry between, say 10 and 20, number 15 could be used. This method is also recom-mended as it produces a table which may be more easy to read by the operator.

The whole table does not have to be linked together, in fact no links whatsoever are necessary.

An additional field, the next entry field, is provided to allow access to alternative routes for thesame subaddress match . Otherwise, the next entry field is given the same value as the entryitself.

The new entry could be inserted as follows :


17th July 2001

8-16

Before:

Entry Subaddress Next entry Routeentry 10 111 10 1entry 20 11 20 2entry 30 all 30 3

After:

Entry Subaddress Next entry Routeentry 10 111 10 1entry 15 112 15 4entry 20 11 20 2entry 30 all 30 3

The full benefit of this method may be observed if a secondary back-up route is introduced forsub-address 11 only, say route 5. In this case the table would changed to:

Entry Subaddress Next entry Routeentry 10 111 10 1entry 15 112 15 4entry 20 11 40 2entry 30 all 30 3entry 40 11 40 5

To summarize, the routing is performed on the minimum number of entries necessary by first look-ing at the most specific cases. The operator should now be able to set up the Terrestrial RoutingDefinition form as described in section 8.3.3.

8.3.2 Examples of Routing Table Entries

Example 1 : All Telex addresses being directed to route number 1

For the simple case of all Telex addresses being directed to route number 1, the entries requiredin the database are :

Address_Format "TELEX"Subaddress ""Subaddress_Offset 1Subaddress_Length 0Address_Ext ""Address_Ext_Offset 1Address_Ext_Length 0Entry_Index 1Next_Entry_Index 1Route_Number 1

The Next_Entry_Index is the same as the Entry_Index, so that this routing table entry is taken asbeing the end of the chain so far as alternate routing is concerned.

Example 2 : Two linked routes

The next entry index allows the operator to link entries together within the table and provides theability to support alternate routing. For example, if Telex messages should be delivered by X400primarily, but by Telex if no X400 routes were available, then the following two entries would berequired:


8-17


Route number 200 is an X400 route.


Getting back to the original example,

The Telex address 44351123+, is routed to route 1 because the subaddress length is set to zero,so this effectively says that no match is required for the address, and the same is true for theaddress extension as the address_ext_length is also set to zero.

Example 3 : Address discrimination

The routing table may be used to discriminate against certain addresses. Imagine that PSTNaddresses beginning with 0441908 get routed to route 10, ones beginning with 044 get routed toroute 11, and all others get routed to route 12 because the UK PSTN behave differently for Local(0441908) calls, National calls and International calls respectively. The PSTN table would needthree entries:

Address_Format "PSTN"Subaddress "0441908"Subaddress_Offset 1Subaddress_Length 7Address_Ext ""Address_Ext_Offset 1Address_Ext_Length 0Entry_Index 1Next_Entry_Index 1Route_Number 10 (Local route)

Address_Format "PSTN"Subaddress "044"Subaddress_Offset 1Subaddress_Length 3Address_Ext ""Address_Ext_Offset 1Address_Ext_Length 0


17th July 2001

8-18

Entry_Index 2Next_Entry_Index 2Route_Number 11 (National route)

Address_Format "PSTN"Subaddress ""Subaddress_Offset 1Subaddress_Length 0Address_Ext ""Address_Ext_Offset 1Address_Ext_Length 0Entry_Index 3Next_Entry_Index 3Route_Number 12 (International route)

Section 8.3.3 describes how these tables are set up in the system.

Example 4: DNID (CNID) addressed messages from mobiles

To ensure the correct routing of DNID addressed messages a Special Access Code ’DNID’ musthave been configured to point to a dedicated route, see Section 8.3.8.

The route used for the Special Access Code is normally ’999’, see Section 8.3.3. This route willrequire the following routing table entry:

Address_Format "CNID"Subaddress ""Subaddress_Offset 1Subaddress_Length 0Address_Ext ""Address_Ext_Offset 1Address_Ext_Length 0Entry_Index 1Next_Entry_Index 1Route_Number 999

Note 1: if the DNID number is not known by the LES, an NDN will be returned to the originatingmobile and the message is discarded.

Note 2: "Route_Number" represents the route used for all DNID addressed messages.

8.3.3 Routing for Mobile Originated Messages

Terrestrial routes are identified by an independent index in the range 1 to 999. Up to 256 routesmay be defined. This must be organised for the LES so that each route number is unique. Tosimplify tracking of the route numbers used, the following convention, which allows plenty ofcapacity for expansion, is suggested :

• Telex : routes 1 to 17

• PSTN : routes 18 to 49

• PSDN : routes 50 to 59

• PSTN (async) : routes 60 to 69


8-19

• CNID : route 999

• SAC : depends on terrestrial route following translation

Note: it is necessary when setting up the Message Handler routing tables to ensure that the routenumbers match those in the Terrestrial Driver configuration tables.

The operator is free to alter this in any way but care should be taken in selecting new route num-bers to ensure that duplication does not occur.

The Terrestrial Routing Definition form (SOC Forms - Message Handler - Message Routing) isused to enter the translation for mobile originated address information to route number. This formis indexed by the route number. An entry is required for each combination of address type andaddress extension field which the mobile can present and which the ACSE can handle. This formhas been specially designed to allow a number of different routes to be selected depending onanalysis not only of the presentation and address extension fields but also by analysis of the ad-dress itself.

It is possible to access this form directly, but it is safer if the Terrestrial Routing Display (SOCForms - Message Handler - Message Routing), which displays all the routes already set up, isaccessed first. This form can show all entries, or can be limited to a specific range. Also it ispossible to display data for specific address formats and routes. Call up the form, enter any ofthese fields and press to see the first ten entries. Use to see more entries,First page Next Pageif necessary. The use of each field is described below.

To add a new route, press ; to modify or delete an existing one, enter a ’Y’ in the left handDefinecolumn and press . This calls up the Terrestrial Routing Definition form. To add a newDefineentry, press , enter the data and press . To change an existing entry, enter the index,Add Enterpress , make the changes and press . To delete an entry, enter the index and pressShow Enter

. The operator will be asked to confirm this action by entering a ’Y’. If only return isDeletepressed, this will be taken as ’N’ and the change will not be made.

The entries on the Terrestrial Routing Definition form and Terrestrial Routing Display havethe following meanings:

• Entry index : For each routing use a separate entry index. Use the TerrestrialRouting Display to check the entry indices already in use before setting up a newroute. This index is used by the operator to keep track of all the routes configured inthe ACSE.

• Address format : as received from the mobile. Use one of the allowable ones asdescribed in Section 8.2.2.

• Subaddress : for analysis of part of the address field. This can be any number ofdigits from the address field and is used as a filter on the addresses to direct onlyselected ones to the route being entered. The subaddress filter does not need tostart at the first address; the subaddress offset field (below) can indicate the first digitto which the subaddress field applies. For example, enter ’581’ to direct only thosetelex numbers relating to mobiles in the Atlantic East Ocean Region to a particularroute. This field is not used for certain address formats.

• Subaddress Offset : the subaddress filter set in the field above can start at any digitin the address field, as indicated by this field.


17th July 2001

8-20

• Address extension : use this if the routing is dependent on any particular addressextension. This field is not used for certain address formats.

• Address extension offset : this is similar to the subaddress offset and points to thedigit in the address extension field where the routing conditions apply.

• Next entry : this is the link between entries which are alternatives. Normally this fieldwill have the same value as the Entry Index. If there is an alternative translation,enter the entry number of that alternative in this field.

• Route number : the internal index which is used by the appropriate driver to directthe message to a particular port.

The address extension fields which are allowed for each given address format may be displayedusing the Address Extension Display (SOC Viewer - Online Processing - Run Reports - OnlineDatabase Reports). All or a specific address format may be selected.

8.3.4 Routing for Messages to Mobiles

Ocean Region Address Definition (SOC Viewer - Online Processing - Database Access -Message Handler Database Access) defines the routing towards the satellite. Messages tomobiles can originate from the terrestrial network or from other mobiles. An entry is required inthis form for each of the terrestrial accesses, as listed at the beginning of this section, plus one foreach ocean region served by the LES. For each routing, this will show whether or not mobile orshore originated messages are allowed and the name of the destination ocean region. The CCITTocean region values are :

87n (PSTN)58n (Telex)111n (PSDN)

where n is Ocean Region (1 - AORE, 2 - IOR, 3 - POR, 4 - AORW, 0 - other)

Note: the only messages coming in from the PSTN network are from asynchronous terminals, butsince these are routed via the X.25 software the destination ocean region will be 111n (PSDN).

The routing set up can be viewed on the Ocean Region Address Display (SOC Viewer - OnlineProcessing - Run Reports - Online Database Reports).

8.3.5 Call Completion Codes

When a message is deemed to be complete, i.e. when it is delivered or the ACSE decides not tomake any further attempts to deliver it, a Call Completion Code is entered in the call records.Where a non-delivery notification is to be sent to the originator, this code is used to generate thetext of the message. The full set of codes configured in the system are listed in Appendix E.

Where a service code is received at the ACSE as the result of failure to deliver a message in theterrestrial network, the service code received is used to select the call completion code entered inthe call records.

Where the ACSE decides that a call has failed, the software chooses the most appropriate code toenter in the call record. The failure will match the text shown in Appendix E.

The operator is able to change the text shown against each reason code. However, such changeswill not alter the basis on which the software chooses the reason code, so only equivalent wordingto the original should be used. To alter a code, use the Call Completion Code Definition (SOC


8-21

Viewer - Online Processing - Database Access - User Services Database Access).

The codes set up, together with the corresponding text, can be inspected using the CallCompletion Code Report (SOC Viewer - Online Processing - Run Reports - Online DatabaseReports).

8.3.6 Alert Routing Strategy

Alerts (distress and land) will be routed according to the originating mobile number. Alerts frommobiles numbered in the range 48XXXXXXX to 49XXXXXXX will be routed to the Non-MaritimeDistress Destination (sometimes referred to as the Land Mobile Distress Destination) associatedwith that mobile. Unregistered land alerts will be allocated the number 480000000 and will be for-warded to the destination indexed by the NMDD. Alerts from maritime mobiles (numbered in therange 40XXXXXXX to 47XXXXXX) will be routed to the MRCC.

The Distress Message Summary Display (SOC Forms, Message Handler, Message Display)and Generate Report on Distress Messages (SOC Viewer -- Online Processing - Run Reports -Run Online Log File Reports - Generate Log File Reports) can be used to read the contents ofdistress alerts and messages which have been generated.

8.3.6.1 Maritime Distress Routing

The distress destination address is set up using the Maritime Distress Destination Definitionform (SOC Forms - Message Handling - Message Routing). Both a primary and secondary ad-dress, to be used in case the first address cannot be reached, can be configured. The addresscan be any telex or PSTN or PSDN address in the public network .

The destination is set by three fields :

• address format, Telex or PSTN or PSDN

• address, according to the selected format, which sets up the path to the destination

• address extension : for Telex and PSDN this field is currently left blank.

Call up the form and press to view the current definition. To change it, press , enterShow Modifythe data and press .Enter

If the primary route to the MRCC uses a dedicated trunk telex line, the entry in the MaritimeDistress Destination Definition will be that of a telex subscriber. It is then necessary to use therouting tables to ensure that that particular address is recognised and routed on the dedicateddistress route, as described in section 8.3.1.

In such a configuration, only the primary address should be set up via the dedicated route. Thesecondary address should use the normal route for mobile to shore traffic; any distress calls willbe handled with priority on it.

The Maritime Address should only be modified after consultation with the relevant au-thority handling distress traffic.

When a maritime distress alert/message arrives at the LES an event will be raised giving details ofthe alert/message. The delivery outcome (successful or unsuccessful) of the alert/message willalso be reported. The LES will first attempt to route the alert/message to the primary address, andif that address cannot be reached it will attempt to route to the secondary address. If the secon-dary address cannot be reached the LES will try again to route to the primary address. The LES


17th July 2001

8-22

will continue switching between the primary and secondary address until all the retry attempts forthe respective failure reasons have been exhausted.

The LES will not attempt to deliver a binary message to any Telex address, and this appliesequally to Maritime distress messages.

The LES will attempt to deliver all distress alerts/messages it receives, irrespective of the barredor logged in status of the sending mobile, and includes those mobiles for which address cannot bedetermined. In the case of of a distress message received from a mobile which is not logged intoany ocean region the LES will mark that mobile as logged in, although it must be noted that thiswill not be marked as logged in at the NCS.

8.3.7 Land Mobile Alerts

The Land Mobile Alert Destination Definition form (SOC Forms - Message Handling - MessageRouting) provides the addresses for each of these destinations. Call up the form, enter thedelivery code and press for a new entry. Then enter the address information and pressAdd

. The address is entered in the same format as used for maritime distress destinations, i.e.Enter

• address format, Telex or PSTN or PSDN

• address, according to the selected format, which sets up the path to the destination

• address extension, an optional field which corresponds to the address extension fieldin the mobile to shore address.

To view an existing entry, press . This can then be modified by pressing , enteringShow Modifythe changed data and pressing .Enter

To delete an entry, enter the delivery code and press .Delete

For land mobile alerts, up to 999 destinations are available, pre-set individually for each mobile. ADelivery Code is entered by the operator against relevant mobiles in the Mobile List as the link tothe destination.

The address corresponding to delivery code ’0’ has a special function. It is used both as an ad-dress for delivery of alert from mobiles which have no delivery code entered in the mobile list andit is also used when valid addresses cannot be reached. It is therefore recommended that theaddress be set so that messages are delivered to the LES operator.

All the destinations set up can be viewed on the Land Mobile Alert Destination Display (SOCForms - Message Handler - Message Routing). Call up the form and press for theFirst Pagefirst ten entries. Use to see other entries.Next Page

If the primary route to the MRCC uses a dedicated trunk telex line, the entry in the MaritimeDistress Destination Definition will be that of a telex subscriber. It is then necessary to use therouting tables to ensure that that particular address is recognised and routed on the dedicateddistress route, as described in section 8.3.1.

In such a configuration, only the primary address should be set up via the dedicated route. Thesecondary address should use the normal route for mobile to shore traffic; any distress calls willbe handled with priority on it.


8-23

8.3.8 Special Access Codes

Special Access Codes can be presented directly by the mobile to translate to any network addressor to access a leased line. The code itself consists of a 2-6 character string. A Special AccessCode may be used as a short code for mobile to shore addressing for :

• An Address

• A Terrestrial Route

• An LES Function

As a particular case, a Special Access Code is required internally in the ACSE to route MRCCmessages to a Leased Line. Such codes should be allocated so that they are not likely to be usedby mobiles in normal circumstances by, for example, using all the available digits.

The full configuration of Special Access Codes set up is shown on the Special Access CodeDisplay (SOC Forms - User Services - Special Access Code). Select the form, optionally enter thekind of code - function, route or address (described below), and press . Up to twelveFirst Pageentries are shown. Use to see more. The display shows the address to which theNext Pagemessage with the Special Access Code is to be delivered. The terms are explained below.

Special Access Codes are defined as one of three kinds, each with separate forms, all accessedvia SOC Forms - User Services - Special Access Code. Select one of the following forms, accord-ing to the kind required :

• Function , where the message is to be handled within the ACSE in a pre-set manner,e.g. test message

• Route is used for leased lines, i.e. where the destination is selected by the routealone and no further address information is required. Also it can be used for routingDNID addressed messages. The Special Access Code "DNID<space><space>" mustbe set up for the appropriate DNID route, normally ’999’, see Section 8.3.2.

• Address for a full address in the terrestrial network, i.e. where the message is to besent to a fixed address, for instance an organisation providing a weather forecast.

The Special Access Code Function Definition form allows the operator to select one of thefollowing :

• Oper_Msg - normally mapped onto special access code 33 (SAC33). The messagewhen received causes an event to be raised. The operator can later retrieve the mes-sage via the Operator Message Report (SOC Viewer - Online Processing - RunReports - Run Online Log File Reports - View Log File Reports - Operator MessageReport).

The operator can specify whether or not to include banner for outgoing delivery message (if ap-plicable).

Further fixed functions can be added with software enhancement.

Select the form, enter the Special Access Code and press to view any entries already setShowup. Press to change, enter the new value and press to make the change. If noModify Enterentry is present, press , enter the new value and press .Add Enter


17th July 2001

8-24

The Special Access Code Route Definition form (SOC Forms - User Services - Special AccessCode) allows the specification of a route number for the special access code. Also the operatorcan specify whether or not to include banner for outgoing delivery message (if applicable) andwhether or not presentation code validation rules for allowing routing to take place are is to befollowed (if applicable). Use , and in the same way as for the Function defini-Add Modify Deletetion above.

For routing to addresses in the terrestrial network, use the Special Access Code AddressDefinition form. The destination is expressed in the form

• address format - Telex or PSTN or PSDN or mobile_number.

Note: the Help information currently shows other possibilities; these cannot be usedand will be removed.

• raw address

• address extension

• include banner (Y or N depending if banner required for outgoing delivery message -if applicable)

• presentation code validation (Y or N depending if rules for routing with respect topresentation code for the corresponding address type is to be followed)

As a guide, the following are required :

• Telex - raw address

• PSTN - raw address and address extension (i.e. T30)

• PSDN - raw address

• Mobile - mobile number

Note that entries are required for all Special Access Codes, including those such as ’33’ which arelisted in the ref 1.

8.3.9 Information for Setting Up Special Access Codes

The information required to set up a Special Access code consists of the following :

• The SAC code - this will be decided by the administration. If the SAC is two charac-ters or less, then they should be digits, otherwise the SAC may be alphanumeric.

• The SAC kind - function, route or address

• For Address, the address format (Telex or PSTN or PSDN or mobile_number or DNIDthe raw address and the address extension, in the same format as a mobile wouldpresent such information.

• For Route, the route type (TER) and the route number (e.g. the route number of aleased line). Note that at present, it is possible for the user to specify a satellite routefor the mapping. No attempt should be made to set up this configuration.


8-25

• For Function, the current configurations are

• "OPER_MSG" which writes the message to the logfile - these messages maybe read by the operator by running an Operator Message Report report. Thisfacility is designed so that the operator may deal with such messages when heis able to; for instance messages can be received during the night and handledwhen staff are available during the day.

8.3.10 Messages to the LES

Messages may be sent from mobiles to the LES operator to request assistance in using the satel-lite services. These are addressed by Special Access Code ’33’. When the LES receives such acall, it is directed to a preset address which can be either :

• a terminal in the earth station, in which case the message will appear in the sameway as any other message to that address

• the SOC console, in which case an event - MDIR 100 - is raised to alert the operatorand the operator can then read the contents of the message using the OperatorMessage Report (SOC Viewer - Online processing - Run Reports - Run Online LogFile Reports - Generate Log File Reports). The report will be printed on the reportprinter.

8.3.11 Delivery Notifications

Once delivery is complete, a delivery notification can be sent to the originator. If a delivery fails anon-delivery notification (NDN) is always sent to:

• a mobile

• an un-registered terrestrial caller (provided the answerback can be decoded)

• a registered terrestrial user set up to receive NDNs (entered on the ACSE using theRegistered User Definition SOC form.)

A positive delivery notification (PDN) can also be sent to the originator if :

• the message came from a mobile, which requested the positive delivery notification -the PDN is sent to the mobile

• the message came from a registered terrestrial user who has PDN enabled and apre-set address, (entered in the ACSE using the Registered User Definition SOCform.)

Figure 8-6 illustrates the steps taken for registered terrestrial users. Note that an NDN is a subsetof a PDN, so a registered user would only be set up for either NDN or PDN reception. Thedelivery notification is only sent when delivery to all addresses is complete or when the deliveryretry cycle is complete.

For unregistered telex messages, the non-delivery notification is sent to an address obtained fromthe original message. For registered users, the address for delivery notifications is entered in theRegistered User Definition form.

For non-registered users, i.e. on telex only, the address is derived from the answerback. Theoperator must configure the translation using the TNIC Definition form (SOC Forms - TerrestrialInterfaces - Telex - TNIC) and can inspect the configuration using the TNIC Display (SOC Forms


17th July 2001

8-26

DELIVERYCOMPLETE

SEND PDN SENDNDN

PDNAUTHORISED

ADDRESSENABLED FOR

PDN

ADDRESSENABLED FOR

NDN ORPDN

COMPLETE

YES

YES YES

NO

ALLDESTINATIONS

WITH SUCCESS CALL COMPLETION

CODE

YES

NO

NO

NO

Figure 8-6. Delivery Notifications to Registered Terrestrial Users


8-27

- Terrestrial Interfaces - Telex - TNIC). In configuring the TNIC translation, the operator shouldonly make an entry for countries which can automatically route telex messages. The Inmarsatidentity of ’X’ should not be entered.

If it is impossible to obtain a meaningful address, or if it is not possible to deliver the deliverynotification, the notification is sent to a default address, set using NDN Spill-out DestinationDefinition (SOC Viewer - Online Processing - Database Access - Message Handler DatabaseAccess). To change the address, press , enter the new address and press .Modify Enter

Telex messages on single stage access will be routed to the spill-out position when :

• the received answerback does not match the F74 criteria.Note in particular that the ACSE cannot process three character TNICs.

• no answerback was received

• the received answerback matched the F74 criteria but the extracted TNIC is not in theTNIC/F69 conversion table.

When a telex message is routed to the spill-out position, the ACSE has taken all the action it can.Manual procedures are required for the LES staff to take whatever action is deemed appropriate.

8.4 How to Find Out About Messages

8.4.1 Distress Message Contents

A summary of distress messages is available, together with full details of individual messages.

The Distress Message Summary Display (SOC Forms - Message Handler - Message Display)shows up to ten messages. Select the form and enter the hours, counting backwards from thecurrent time, which are to be displayed. Press and then, if desired use theFirst page Next Pagekey, to view the following details :

• incoming call record serial number - used as an internal index

• message reference number - as given to the originator and recipient

• MES number

• message kind : mobile to shore, shore to mobile, mobile to mobile, EGC

• call completion code

• call status in text form

Note that because all distress messages are acknowledged, and the acknowledgement itself hasdistress priority, the acknowledgement message will appear in this display, with the same mes-sage reference number as the original distress.

To view an individual record in detail, place ’Y’ in the left-hand column of the summary display andpress to obtain the Distress Message Full Display (no direct access to this form). Be sureFullto select the original message and not the acknowledgement, which will not include the contentsof the message itself. The form shows the following :

• incoming call record serial number


17th July 2001

8-28

• message reference number

• forward and return MES identities

• MES number

• call input time

• EGC details


• delivery call record serial number

• call delivery time


• call status in text form

• raw destination address(es)

• message text, up to 4 lines of 128 characters each

EGC details apply only to EGC messages, while some of the other fields, such as the MESdetails, only apply to normal messages.

The forms described above are limited to showing 512 characters of text. If the distress messageexceeds that size, it will be necessary to use one of the following SOC Viewer options, dependingon the origination of the message, to obtain the rest of the message:

• Mobile Distress Message Report

• Terrestrial Distress Message Report

• EGC Distress Message Report

Use Generate Report on Distress Message (SOC Viewer - Online Processing - Run Reports -Run Online Log File Reports - Generate Log File Reports) to obtain the report.

8.4.2 Message Status Enquiry

Message status enquiries can be made by users on the delivery status of any message in thesystem up to at least 72 hours after it has been submitted. The Message Status SummaryDisplay (SOC Forms - Message Handling - Message Display) gives the operator the same infor-mation. Refer to section 8.4.6 for details of how to search for information about a particular mes-sage.

After selecting the form, the operator must enter the same information as a terrestrial user, i.e. :

• registered user PIN, where applicable


• submission time - within one hour


8-29

• select all (shore originated) messages or only undelivered ones

After pressing , the operator is shown a tabular display of call completion code, call statusShowand message kind, e.g. shore to mobile, mobile to shore, etc. for each destination address. Usethe scroll keys, and , to see the full page of up to 20 destinations. FurtherUp arrow Down arrowdetails for a single destination can be obtained by selecting the destination with a ’Y’ in the lefthand column and pressing to give the Message Status Full Display (not directly accessibleFullvia the menu) which shows :


• call status

• ocean region (destination, except mobile to terrestrial)

• message kind e.g. mobile originated

• delivery attempts

• delivery address

• for EGC messages, the number of completed and outstanding transmissions

8.4.3 Message Queues

There are several message queues in the system. Section 8.4.6 shows how the operator cananalyse the information presented.

The Message Queue Summary Display (SOC Forms - Message Handling - Message Details)summarizes the message queues by route. The operator can optionally specify :

• route identity and type

• ocean region

• queue type : time, token seize, selectable, active route, all queues. The qualifiersrepresent the successive locations in the system through which a message can beconsidered to pass.

Enter the required details and press for a tabular display of eleven entries, for activeFirst Pagemessages, showing the following :

• route identity

• route number

• ocean region

• spot identity (for future use)

• queue type



17th July 2001

8-30

• entry time

• scheduled delivery time

• priority : normal or distress

Use the command as needed for the rest of the data.Next Page

8.4.4 Message Details

Details of active messages within the system can be viewed on the Message Details SummaryDisplay (SOC Forms - Message Handling - Message Details). This is keyed by a number offields, all of which are optional, as follows :

• incoming call record number - start and finish

• message reference number - start and finish

• time of arrival - start and finish

• registered user identity - PIN

• message kind - mobile to shore, shore to mobile, mobile to mobile, NDN, PDN, EGC,Poll, data report, PVT request

• priority

• originator address

When all the required fields have been entered, press to obtain the following details :First Page

• incoming call record number

• time of arrival



• registered user PIN

• originators address

Use the scroll keys, arrow up and arrow down, to see the full page of 20 messages. Pressto see the next 20 messages.Next Page

To view all the details associated with a message, there are two forms, one of which is tailored toparticular types of message. Enter a ’Y’ in the left hand column and press either

• for the Message Details Full General Display or access directly (SOCFull GeneralForms - Message Handling - Message Details) or

• for the appropriate Message Details Full Specific Display or accessFull Specificdirectly (SOC Forms - Message Handling - Message Details)


8-31

These forms cannot be accessed directly via the menu

The Full General Display shows :


• time of arrival

• message kind


• registered user PIN (where applicable)

• origin route number and address

• whether or not it is a test message

• message priority - normal or distress

• delivery details - the following for up to 20 addresses:

• destination call serial number

• delivery time

• address format and destination address

• indication of the possibility of duplication

• number of delivery attempts

• number of delivery retries


The Full Specific displays are of four types, according to the type of message for :

• Message Details Full DN Display for positive and negative delivery notifications

• Message Details Full EGC Display for EGC messages to mobiles

• Message Details Full Polls Display for polls to mobiles

• Message Details Full DR Display for data reports from mobiles

All show the same origination details :


• time of arrival

• message kind



17th July 2001

8-32

• registered user PIN (where applicable)

• origination address

For DN, the delivery information is :

• original incoming call record number

• original time of arrival

• original message reference number

• whether or not the NDN included text

• whether or not there was the possibility of duplication or the original message

For EGC messages, the delivery details are :

• service code

• number of transmissions

• interval

• echo on or off

• repetition number

• message sequence number

For Polls , the details are

• acknowledgement required or not

• message sequence number

• poll command : program, initiate or stop for reserved or unreserved data reporting,define macro encoded message, data transmission or DNID download

For Data Reports the member number is shown.

From the Message Details Summary Display the operator can select any of the messages dis-played on a page and use to cancel the selected messages and generate anCancel (with NDN)NDN for each message cancelled, or to cancel the selected messages butCancel (without NDN)not to generate NDNs for the messages cancelled. Before the command is accepted the operatorwill be prompted with "Confirm message cancellation with NDN (Y/N)" or "Confirm message can-cellation without NDN (Y/N)". This facility is useful in that it provides an easy mechanism for rid-ding the system of unwanted messages.

8.4.5 Message Queue Analysis

A message is considered as being live within the system between the time it is received anddelivered, or in the case that the retry cycle is gone through without delivery success, the time thatthe system gives up attempting to deliver the message.


8-33

During the time the message is live, it is stored in one of four queues :

• Time Queue

• Token Seize Queue

• Selectable Queue

• Active Queue

If a route used to deliver the message can support multiply addressed messages (e.g. X400) thena single queue entry may have more than one destination (although there still may be multiplequeue entries for the message).

A delivery will only be resident on one of the above queues at any one time - however duplicationsmay be seen in the message reference numbers in queue entries, because messages addressedto more than one destination may have more than one queue entry.

The Time Queue is used to store deliveries which have not yet reached their schedule time i.e.they are due to be delivered in the future. These queue entries will remain on this queue until theirschedule time ’expires’. An example of such entries would be deliveries to a mobile being res-cheduled on the Time queue because the mobile is busy, or an EGC repetition being rescheduledto be delivered when the next transmission (or echo) is due.

The entries on this queue are ordered by the entry’s Schedule Time.

The Token Seize Queue is a queue where scheduled entries reside until the necessary process-ing resource (Token) has been allocated (Seized) to allow delivery to the delivery driver, e.g. telex,X25.

A delivery driver may only deliver a certain number of messages in parallel at any one time (i.e.there will only be a certain number of seizable tokens at any one time). Therefore if the number ofscheduled messages exceeds the number of parallel deliveries that may be made, then the mes-sages remaining to be delivered will wait on this queue until the delivery driver’s resources be-come free.

Entries in this queue are ordered by message priority and then by entry time within the samepriority i.e. the oldest distress message will be the first off the queue, and the youngest normalmessage will be the last off the queue. Note that the entry time should not be confused withschedule time; the entry time is the time when the message entered the system; the schedule timeis the time when the queue entry should leave the Time Queue, and is only relevant when theentry is on the Time Queue.

Because the Token Seize Queue could be extremely long, a route identifier must be provided asan additional selection parameter when viewing either the Token Seize Queue, or All QueueEntries.

The Selectable Queue is a queue where entries have the appropriate driver resource allocatedfor delivery, but the entries have not yet been collected by the delivery driver.

As an entry will reside on this queue for a very short time (less than half a second), it is unlikelythat any entries will be seen on this queue.

The order in which active entries are shown on this queue is not important, as at this stage allselectable deliveries will be made by the driver within approximately a second.


17th July 2001

8-34

The Active Queue is a queue where entries reside while the delivery driver is attempting todeliver the message (i.e. Active within the Delivery Driver). The queue entry will stay on the queuefor the duration of the delivery attempt.

Again, as with the Selectable Queue, the entries are not stored in any particular order.

The progress of a message through the system can be followed on the appropriate MessageQueue Entry Life-Cycle diagram, see figures 8-7 and 8-8.

An ordinary message will have the life-cycle, from a scheduling point of view, as shown in figure8-7.

An EGC message with repetitions will have the life-cycle, from a scheduling point of view, asshown in figure 8-8.

A delivery may be rerouted for a variety of reasons e.g. failure of a distress delivery attempt, aroute becoming available or unavailable. When the delivery gets rerouted, the message will bemoved from one route queue to another route queue (i.e. it will effectively ’jump’ routes). Note thatif a delivery gets rerouted from a route which handles multiply-addressed messages to one whichdoes not, then the number of queue entries for the delivery may increase.

The Message Handler Management facility (SOC Viewer - Online Processing - Message HandlerManagement) provides a message state monitor display, which shows in real time the changes instate undergone by messages as they pass through the Message Handler, which is the centralpart of the processing software.

The display shows the following :

• incoming call serial number


• message kind - e.g. terrestrial to mobile

• priority

• arrival time

• message text state - e.g. stored, deleted

• overall message status - e.g. awaiting delivery, dead

• the status of delivery of the message to each of the maximum of 20 addresses - e.g.awaiting delivery, delivery successful, delivery failed

Further columns give the originator address and route ID for each message. These are not dis-played on the screen normally because the screen is not wide enough but can be seen by press-ing followed by . Use followed by to return to the original display.Pf1 right arrow Pf1 left arrow

Message events (such as the assignment of a message reference number or the failure of adelivery) are saved in the message event history by the Message Handler process and theMessage Handler interfaces used by all driver processes. The state changes resulting from theseevents are recorded in the Message Handler message state record by a recorder task, and arereflected in the message state monitor display, providing an overview of message traffic.


8-35

DELIVERY BECOMES SCHEDULED

DRIVER DELIVERY RESOURCE ALLOCATED

DRIVER ATTEMPTING DELIVERY

REQUEUE ENTRY IF MOBILE DESTINATION AND MOBILE IS

BUSY TRANSMITTING

REQUEUEENTRY

TIME Q TOKEN SEIZE Q SELECTABLE Q ACTIVE Q

DELIVERY ATTEMPT FAILED


DELIVERY ATTEMPT SUCCEEDED

- REQUEUE (IF RETRY_COUNT > 0)

- DELETE ENTRY (IF RETRY_COUNT <= 0)

- ENTRY DELETED

OR

[mess_prog_1.eps]

Figure 8-7. Ordinary Message Lifecycle


17th July 2001

8-36

DELIVERY BECOMES SCHEDULED

DRIVER DELIVERY RESOURCE ALLOCATED

DRIVER ATTEMPTING DELIVERY

REQUEUE ENTRY IF MOBILE DESTINATION AND MOBILE IS

BUSY TRANSMITTING

REQUEUEENTRY

TIME Q TOKEN SEIZE Q SELECTABLE Q ACTIVE Q





- RESCHEDULE ENTRY FOR NEXT REPETITION/ECHO

- DELETE ENTRY IF NO MORE REPETITIONS/ECHOES

-- REQUEUE (IF RETRY_COUNT >0)

- DELETE ENTRY (IF RETRY_COUNT <= 0) AS AN EGC IS CANCELLED IF A REPETITION/ECHO DELIVERY FAILS

OR

[mess_prog_2.eps]

Figure 8-8. EGC Message Lifecycle


8-37

The messages for which message events have been recorded are displayed one per line. Thedisplay may be scrolled by pressing the arrow keys.

Further information regarding the use of the monitor may be found by pressing within thehelpfacility on SOC Viewer.

8.4.6 Call Analysis

This section shows how information on a particular call can be found in the system. Figure 8-9summarizes the steps.

The process would typically be necessary when a user contacts the LES to enquire about deliveryof a particular message. The starting point is therefore that the operator knows the messagereference number (MRN) and the time that was logged against the call (TOA - Time Of Arrival)and whenever appropriate and possible, the PIN of the user. In some cases, some of this infor-mation could be missing.

Details of the call may be found via SOC Forms, if the message is less than 72 hours old, or via aCall Record Report if it is more than 72 hours old. The Message Status Summary Display(SOC Forms - Message Handling - Message Display) is the key to finding messages less than 72hours. It can be used to go directly to the message details if the MRN and TOA are known andare correct, or it can be used to scan through all the possible messages which meet the givencriteria.

MRN and TOA known

If the MRN and TOA are both provided, then go to the Message Status Summary Display . EnterMRN, TOA - the operator does not need to fill in the PIN field. Use the ’ALL’ selection option.One of three things will happen:

• The LES is still attempting delivery of the message;

• The LES has completed message delivery (failure or success); or

• The message status could not be found.

If the status has been found, then a more in-depth view of the message status may be performedon a ’per-destination’ basis for the message by using the Message Status Full Display . Enter a’Y’ against the desired message and press . This will allow the operator to give a destination-Fullby-destination description of which deliveries succeeded, and which failed (and why they failed).

If the LES is still attempting delivery, then the message is still ’Active’ within the LES. All therelevant information which is available is shown on the Message Details Summary Display(SOC Forms - Message Handling - Message Details).

If the message status could not be found, then this means that either the MRN or TOA (or both)were incorrect or the message is older than 72 hours (and consequently it will have been deletedfrom the journal file if it was not a Cat B EGC). If the customer is not sure of the MRN or TOA,then either assume either the MRN to be correct or the TOA to be correct, and use the methoddescribed below. If the customer is really unsure, then follow the steps below first assuming theMRN is correct, and then assume the TOA is correct. The PIN used for the message submissionmay prove useful too - this should strictly be requested anyway to provide a level of security.

Only MRN or Only TOA Provided


17th July 2001

8-38

Message ReferenceNumber know (MRN)

+Time of acceptance

(TOA)

Message Status Summary Display

Completeddelivery

Message Status Full dislay - detailsfor each destination

Info already available on

Message StatusSummary Display

Still attemptingdelivery

Cannot Find

MRN or TOA wrong

Older than72 hours

Details not available.

Use Call RecordReport

Choose MRN or TOAwhichever is more likely

to be correct

Use as selectionto obtain Message

Full Display

If not Required message

Call Analysis

Choose anotherselection

Figure 8-9. Call Analysis


8-39

If the status could not be found and the message is thought to be active, the Message StatusSummary Display can be used with either the MRN or the TOA as the selection key - DO NOTUSE BOTH (this combination has already been proven to be incorrect). If the PIN was providedby the user, then just enter this as the selection field.

Call Record Report

The methods described above are usable up to 72 hours after message submission. All calls, etc.,are put in the log file, so after 72 hours the information must be retrieved from these log files. Theeasiest way is to perform a billing run and to see the billing records for the calls, but this can takesome time.

However, with the option to run manual billing under the new autobilling process, this no longerapplies. A manual billing run can be performed on immediately closed log files, using carryoverdata if required. Data can be extracted within minutes rather than hours as might previously havebeen the case.

If the requirement is to see details on a call where the approximate time of the call is known (withina range of plus or minus 1 hour) the appropriate log files can be listed.

A log file is created approximately every hour or 2048 entries, and given a name of the format:-

LOG_yyyymmdd_HHMMSS_Vn_mm.dat

e.g.

LOG_19920421_095914_V5_10.dat.

for 21 April, 1992, at 9.59 in the morning.

Offline access via SOC Viewer provides all the tools to extract the data.

Step 1:

Use Directory of Log Files (SOC Viewer - Offline Processing - Options - Housekeeping - Log FileUtilities).

Identify the log file(s) names required, if present, or else copy from on-line area or restore fromarchive using other options.

Step 2:

Use List Log Files (SOC Viewer - Offline Processing - Options - List Generation).

Specify the log file to be listed.Specify C for call records (other options allow other contents of log files to be extracted.)Specify the name for the list file.Specify the start time (can be defaulted unless known accurately)Specify the end time (can be defaulted unless known accurately)

The listing will the be generated.

Step 3:

Use either:


17th July 2001

8-40

• View List (SOC Viewer - Offline Processing - Options - Housekeeping - List Utilities)

• Print List (SOC Viewer - Offline Processing - Options - Housekeeping - List Utilities)

The list files can be quite big therefore the use of the view option is advised before printing. Thelist file should be deleted using the delete option before exiting.

Although this procedure will find the call records from a given log file an alternative is to use thewild card file specification ’*’ and the start and end times. This will take more processing time as alllog files that are visible to the lister will be searched, but may be easier if calls resulting from theoriginal message span more than one log file.

To search the list files for a key such as MRN would require use of the VMS editor facilities whichare beyond the scope of the HNS MMI facilities.

Note : to specify all log files use LOG*.dat. If this is done the lister will take a long time. If no startand end time are specified the resulting file could be HUGE. Some care is needed!

8.5 System Usage

The System Usage Display window gives a real-time indication of the traffic being handled andthe System Usage Statistics report provides a regular printout of traffic.

The System Usage Display window provides both graphical and numeric information as a defaultdisplay on the SOC. The display can be iconised if it is not wanted on the screen, but is notaccessed through the normal menu structure for SOC forms.

The display available is dependent on how the system is configured on installation. The systempresents each display in sequence at intervals between 1 and 86400 seconds, although it is in-advisable to have intervals of less than 30 seconds as this puts a heavy processing load on thesystem.

The operator can also exercise some control over the current SUD display, by left-clicking themouse on the background screen (as described in section 2.5). The choices that control the SUDare:

• Next SUD display

• Previous SUD display

• Hold current SUD display

• Release SUD display

Holding the display keeps the current display on view. While a single SUD display is being held, itwill continue to be updated, as will all the other (unseen) displays. The Release option is onlyused on a held display. The other two options are self explanatory. The display need not he heldbefore using the Next/Previous options (although it can be).

8.5.1 Text Information SUD

In the Text info display the information is in the form of tables.

The number of messages currently live in the system are shown.


8-41

The number of successful and failed deliveries in the last six minutes and last hour are shown.

For each of the TDM, ISL and Terrestrial queues the number of messages on each of the follow-ing queues are shown:

• Timed

• Token

• Select

• Active

• All of the above

A terrestrial summary gives the number of circuits (if applicable) or lines and the number in servicefor all the supported network types :

• Leased line (not used)

• Subscriber telex (not used)

• Trunk telex

• X25

• Fax

• X400 (not used)

A satellite summary is given which provides the following information for each of the supportedocean regions:

• Current mode

• ISL status (not used)

• Permanent TDMs

• Permanent channels

• Assigned TDMs

• Assigned channels Pending TDM requests (not used)

• Busy MESs

8.5.2 Bar Graph SUD

In the bar graph display the graphic information is in the form of a green bar which changes toyellow when the percentage exceeds 60% and red when exceeds 80%. Note that when the SOCis not connected to a BAP, no data is given in this display.

Each parameter is measured as a percentage of the capacity not free against the total capacityand therefore includes any capacity out of service in the occupied category.


17th July 2001

8-42

The following details are shown as percentage and graphically :

• occupancy of top three longest terrestrial queues, with route numbers

• occupancy of top five longest satellite queues, with route numbers

• occupancy of longest ISL queue . occupancy of total message queues

• telex circuit occupancy

• call record store occupancy

• message text blocks, used percentage

• log data store, used percentage

Note: The telex circuit occupancy is a percentage representing the average number of telex chan-nels occupied since the LES was last restarted. It cannot be taken as an instantaneous indicationof the telex usage.

The log data store gives a graphical indication of the percentage of available space currently usedfor the storage of log files. It is calculated as follows :

log data store = 100 * (T - L - F)/(T - L)

where T = total blocks on storage disksL = low water markF = free blocks on storage disks

The low water mark is the amount of disk space which is reserved for the Online Database andthe storage of message text and is therefore not available for use as log file storage.

8.5.3 Call Completion SUD

The call completion SUD display lists all CCCs raised in the last hour. The display shows eachCCC raised (by number) along with a count of how many times that CCC has been raised.

The queue count for individual routes display will show all routes by route type. 14 routes willbe shown in a given display, but the SUD will cycle through all routes as the display repeats itself.

The display shows:

• Route Type

• Route ID

• Timed (number of calls queued for retry)

• Token Seize (number of calls awaiting token)

• Active (number of calls being processed)

• Total (total number of calls)


8-43

8.5.4 User Interface Response SUD

The user interface response times display shows, for both the last six minutes and the last hour,the number of responses, and the average time of response, for:

• Message Submission

• EGC Submission

• Poll Submission

• Message Status Enquiry

• Message Cancellation

• DNID File Retrieval

The last hours call rates shows, for each route:

• Success (total calls)

• Retried (total calls)

• Failed (total calls)

• Average success delivery time

• Average final failure delivery time

8.5.5 Queue Counts by Individual Routes

The Queue Counts SUD form shows for each route type:

• Route ID

• Count of calls broken down into:

• Timed

• Token Seize

• Active

• Total

8.5.6 Delivery Rate by Route SUD

The Delivery Rates by Route system usage display shows, for each route, during both the lasthour and last 6 minutes:

• Successful Calls

• Failed Calls

• Mean Successful Delivery Time

• Mean Failure Delivery Time


17th July 2001

8-44

8.5.7 TDM_Summary Display SUD

The TDM Summary Display shows, for each TDM:

• Ocean Region

• TDM Id

• TDM Type

• Spot Id

• TDM Load

• Signal Load

• Message Channel Loading

• From Mobile Calls

• To Mobile Calls

• Total Calls

• Pended Calls

8.5.8 Call Count SUD

The Call Count system usage display shows the count in both the last sixty and last six minutesfor:

• Data Reports or DNID addressed messages:

• Immediate Forward

• Stored, not Forwarded

• Stored Only

• Failed

• DNID Downloads:

• Direct (Successful/Failed)

• Kermit (Successful/Failed)

• EGCs (Successful)

• Polls (Successful/Failed)

• From Mobile Calls (Successful/Failed)

• Terrestrial NDNs (Successful/Failed)

• Terrestrial PDNs (Successful/Failed)


8-45

• Satellite NDNs (Successful/Failed)

• Satellite PDNs (Successful/Failed)

• Message Status Enquiries:

• Satellite (Successful/Failed)

• Terrestrial (Successful/Failed)

8.5.9 Forced Clear Counts SUD

The Forced Clear Counts display shows packets broken down on a Failure Code basis for thelast six minutes and for the last hour.

• The screen lists up to 6 force clear types per TDM.

• The spots are displayed in alphabetical order.

• Spots with more than one TDM present the TDM groups in ascending order.

• TDM groups that have not transmitted any Force Clears do not appear on the SUD.

8.5.10 Statistics

For statistics the System Usage Statistics report is printed regularly (at intervals set by theoperator) on the report printer and provides the following current information :

• collection start and stop times

• blocks of message text store in use

• incoming and destination call records store in use

• details of queues by route : messages in and out, timed, ready, active and total mes-sages

• details of the oldest message in the queue : arrival, route number, ICR serial numberand message reference number

• message counts : successful and failed deliveries, positive and non-delivery notifica-tions, status enquiries, EGCs, polls, data reports, DNID addressed messages anddistress messages

8.6 Message Records

There are a series of online and offline forms and reports which show the messages beinghandled by the system and those which have been handled by the system. Online reports areavailable from the online database for messages not more than 72 hours old or those whosedetails are contained in the online logfiles.

Offline reports are obtained from logfiles loaded into the offline database and are described insection 14.11. This section describes the online reports.

Call records are of two types, corresponding to the half-calls processed by the system, i.e. acall/message coming in and one going out :


17th July 2001

8-46

• ICR : Incoming call record

• DCR : Delivery call record

8.6.1 Online Call Records on SOC Forms

Three forms are available for the inspection of call records, a summary and two detailed ones.

The Call Record Summary Display (SOC Forms - Message Handling) can be used to look at thecall records of active calls within the system. This displays an area of memory which is used tomaintain the active call record and hence, from time to time, it may be possible that ’Unknown’ callrecords are displayed if a delivery driver is in the process of writing to the call record. ’

The operator can use any of the following optional filters for the display :

• direction : incoming or outgoing

• driver : satellite, trunk telex, subscriber telex, leased telex, X.25

• call serial number : start and finish

• call direction : terrestrial to LES, LES to terrestrial, LES to mobile, mobile to LES

• call priority : normal or distress

• time of message : start and finish


Press to obtain :First Page

• active : yes or no

• direction : I for incoming, O for outgoing




• time message started


A full display of the call record can be obtained by selecting one record by placing a ’Y’ in the lefthand column and pressing .Full General

The two forms described below take a snapshot in time and therefore may only show part of thepicture. Default values may appear which do not relate to the final outcome of the call. However,the two forms are of value in detecting and clearing stuck calls.

For an incoming call, the Call Record Full ICR Display is obtained and for an outgoing call, theCall Record Full DCR Display will be shown. Both will show the following :


8-47

• active : yes or no

• direction : I for incoming, O for outgoing




• time message started


• call status text

• number of addresses

• follow-on count

• call volume - the number of bits in a message going out over the satellite or coming inover the satellite. This applies only to messages that actually go over the satellite.

For incoming calls , there is also

• origin network and address

• call nature


For outgoing calls , there is also

• ICR call serial number

• destination network : PSDN, Trunk Telex, Leased Line, PSTN, Satellite, MMI

• destination address

• delivery attempts

• last delivery attempt

• possible duplicate : yes or no

This form provides a means of cancelling messages which may have become stuck due to anerror in the satellite side protocols. After selecting either the Call Record Full ICR Display or theCall Record Full DCR Display for the stuck message, press . The operation will take 2 orCancel3 minutes to complete and can be confirmed by returning to the Call Record Summary Display .Note that this cancellation function only applies to messages on the satellite side. Attempts tocancel other messages will be rejected and the operator advised.


17th July 2001

8-48

8.6.2 Online Call Record Reports

The second type of report will use the online log files. These reports will list the Incoming CallRecords (ICRs) and Delivery Call Records (DCRs) that meet the specified criteria. The reportsgenerated from the message details tables of the database will operate substantially faster thanthe reports generated from the online log files.

The following call record reports are generated by searching the records in the online log files:

• Summary and Statistics Message Report

• LES to Mobile Message Report

• Mobile to LES Message Report

• Poll Message Report

• EGC Message Report

• DNID Retrieval Report

• Data Reports Report

• DNID Handler Report

8.6.3 Report Presentation

The reports are initiated and viewed using SOC Viewer. When a report is complete it is written toa file. In the case of database reports, this file is automatically edited using the DEC EDIT editor.For logfile reports, separate menu options are provided to view (and edit) or print the reports. Theeditor is a full function editor that will allow the operator to perform the following functions:

• Go to TOP of report ,PF1 5

• Go to BOTTOM of report ,PF1 4

• Use of the four scrolling arrow keys

• PREV screen

• NEXT screen

• Find (FIND or , )PF1 PF3

• Find next PF3

• Reverse (keypad 5)

• Forward (keypad 4)

• Print report from file , then ,PF1 W PF1 P

• Write report to new file

• Annotate the report


8-49

• Delete functions

• Cut and paste of text

The report width is fixed at 132 columns

8.6.4 Message Status Reports

These online reports are generated from the Message Details tables of the database. To generatethem use the Message Status Report (SOC Viewer - Online Processing - Run Reports - RunOnline Database Reports). The reports available are:

• LES to Mobile Message Report

• Poll Request Report

• EGC Request Report

• Mobile to LES Message Report

The reports can be used for messages originated by registered users, unregistered users andmobiles.

For the LES to Mobile Message Report the optional selection criteria are:

Start time defaults to earliest defined timeEnd time defaults to latest defined timeMessage reference number defaults to allPIN defaults to allDestination mobile number defaults to allAll messages or only those undelivered defaults to all messages.

The report consists of one line entries, ordered by message reference number which showdate/time of arrival, PIN (if registered user), destination mobile, ocean region, call completionstatus, explanation of the status and the number of delivery attempts of each message.

The selection criteria for the Poll Message Report and the output is identical to the LES toMobile Message Report except that delivery attempts do not apply and so are not displayed.

For the EGC Message Report , the optional selection criteria are:

Start time defaults to earliest defined timeEnd time defaults to latest defined timeMessage reference number defaults to allPIN defaults to allAll messages or only those undelivered defaults to all messages.

The report consists of one line entries, ordered by message reference number which showdate/time of arrival, PIN, EGC sequence number, ocean region, call completion status, explana-tion of the status, number of completed broadcasts and number of outstanding broadcasts foreach EGC message.

For the Mobile to LES Report , the optional selection criteria are:

Start time defaults to earliest defined time


17th July 2001

8-50

End time defaults to latest defined timeMessage reference number defaults to allOriginator mobile number defaults to allDestination type defaults to allAll messages or only those undelivered defaults to all messages.

The report consists of one line entries, ordered by message reference number which showdate/time of arrival, origination mobile number, destination format, destination address, callcompletion status, explanation of the status, number of delivery attempts.

The heading of each report shows the selection parameters as above, followed by the report itself.Use the and to scroll through the display.Up Arrow Down Arrow

To exit, press and type exit at the prompt.pf1 numeric 7

The operator is then invited to answer Yes or No as to whether the report is printed. The menu isthen re-displayed.

8.6.5 DNID Report

The DNID report is generated using the DNID Report option from (SOC Viewer - OnlineProcessing - Run Reports - Run Online Database Reports). The operator can select a range ofDNIDs or ALL DNIDs, one PIN or ALL PINs. The report shows the DNIDs, their PIN allocation andthe date/time allocated. The report also shows date/time DNID file overflowed (if applicable),number of lost reports and the file usage.

8.6.6 ENID Report

The ENID report is generated using the ENID Report option from (SOC Viewer - OnlineProcessing - Run Reports - Run Online Database Reports).The operator can select a range ofENIDs or ALL ENIDs, one PIN or ALL PINs. The report shows the ENIDs, their PIN allocation andthe date/time allocated.

8.6.7 Log File Reports

SOC Viewer provides means to generate, view and print logfile reports. To generate these reportsuse Generate Log File Reports (SOC Viewer - Online Processing - Run Reports - Run OnlineLog File Reports).

8.7 Recovery from Failures in Message Handling

This section describes how to overcome a problems with traffic handling. Some of the actionsdescribed are drastic, but may be necessary to restore traffic as quickly as possible in the cir-cumstances.

In the event of a complete failure of the system, a system restart will be necessary, as describedin section 10.1.1. Other scenarios involve the failure to handle traffic on one particular interface.

On the telex lines, possible failure scenarios are :

• all outgoing calls failing

• all incoming calls failing

• telex lines stuck in retest of bothway busy


8-51

8.7.1 Satellite Call Failures

Satellite calls may fail over a single TDM, a single rack or all racks. Figure 8-10 shows theoperator actions in the case of satellite call failures. The operator, when following the steps, willmake test calls to ascertain if the problem has been corrected at the appropriate points.

The operator actions are detailed in this section:

• Check hardware communications. In any case check all communications are inservice by noting any LES alarms and using external monitoring equipment, e.g.Sexton Analyser.

• Calls Failing on a Single TDM. Take the TDM group out of service, then return it intoservice. Use the TDM Group Management form (SOC Forms - Satellite Interface -Satellite TDM Group) to do this. Once the TDM group is back in service (this shouldtake approximately 30 seconds) the TDM can be tested.

• Calls Failing On A Single Rack. Switch the Channel Unit FEPs for the affected rackusing the FEP Management form (SOC Forms - System Control). This will cause allthe TDM groups associated with that rack to be initialized. Wait until the channel unitcards are all recovered (by checking the HEX display) before testing.

• Calls Failing On All Racks. There are several steps the operator can take to try andclear a failure with this symptom. After each step make test calls to ascertain if thesatellite interface is back in service. If not then proceed to the next step.

• Spare out the TDM Rx card, using the TDM Rx Logical Channel Definitionform (SOC Forms - Satellite Interface - Satellite Logical Channel Menu).

• Use the TDM Rx Logical Channel Definition form (SOC Forms - SatelliteInterface - Satellite Logical Channel Menu) to determine the frequency of theTDM Rx and so identify the TDM group. If the TDM Rx is displaying "A", thenspare out the TDM Tx card for the TDM that is generating timing. Use TDM TxLogical Channel Definition form (SOC Forms - Satellite Interface - SatelliteLogical Channel Menu).

• Switch the MTMs in the first channel unit rack. This is achieved using theManual Clock Select switch, described in Table 3.2 of reference [3].

• Check the elements of the RF chain, to ensure that signals are being receivedand transmitted to and from the satellite.

• If satisfied that none of the above steps have cleared the problem, then performa BAP switchover. This operation is described in section 10.1.2.

If the problem persists, then contact HNS.


17th July 2001

8-52

CHECK HARDWARE COMMS ETC.

TAKE CORRECTIVE ACTION

H/W OR COMMS FAILURE

TAKE TDM GROUP OOS

CALLS FAILING ON A SINGLE

TDM

BRING TDM GROUP BACK INTO SERVICE CALLS FAILING

ON ALL RACKS

WAIT FOR TDM TO RECONFIGURE

SWITCH CU FEPS

SPARE OUT TDM Rx CARD

CALLS STILL FAILING?

SPARE OUT TDM Tx CARD


SPARE OUT TDM Tx CARD

Yes

No

Yes

No

No

Yes


Yes

SWITCH BAPS


CHECK RF CHAIN CALLS STILL

FAILING? CONTACT HNS

SWITCH MTMs IN RACK 0

Yes


SATELLITE CALLS FAILING

FINISH

Yes

Yes

Yes

Yes

No

No

No

No

No


Yes

No

No

Figure 8-10. Recovery Procedure when Satellite Calls Are Failing


8-53

8.7.2 Terrestrial X.25 Calls Failing

The operator is limited in the influence possible over failing X.25 calls. If the calls are failing on theexternal network then the network service provider should be contacted. However there are stepsthat the operator can take to establish if the reason for message failure is within the ACSE, andthen either clear the problem or seek support.

The steps are shown as a flow diagram in figure 8-11. The steps described in this section refer tothis diagram. Where the operator checks that the DEMSAs are OK (back in service) the operatorshould be confident that X.25 calls are being successfully routed.

1. Access the DEMSA Management form SOC Forms - System Control Menu. If theform fails and a Time Out error appears on the SOC then there is a probable faultwith the X.25 driver and the problem should be reported to HNS.

2. Using the DEMSA Management form, check that the DEMSA pair(s) showingproblems have one DEMSA set as a master and all DEMSAs are INS. If the Masterappears to be in service, then go to stage 9, if not then stage 3.

3. Physically check the DEMSAs. They should be powered on with a moving LED dis-play at the rear. Generally, either neither or both DEMSAs will have failed (if themaster fails then the standby DEMSA should take over as master). If the DEMSAsappear to be physically working go to step 8.

4. Power cycle the DEMSAs. It will take several minutes for the DEMSAs to initialiseand be able to transmit traffic.

5. If the Master DEMSA fails to power up, and the problem is obviously hardware, thencall a field service engineer, if there is any doubt contact HNS.

6. If the Standby DEMSA fails to power up, and the problem is obviously hardware,then call a field service engineer, if there is any doubt contact HNS.

7. Check both DEMSAs are in service. if either is not, return to stage 2.

8. (Continued from step 3) Using the DEMSA Management form, attempt to bring theDEMSA(s) into service. Continue with these steps if this does not remedy theproblem.

9. After first ensuring both DEMSAs are running, switch the DEMSAs, as described insection 10.2.5. Continue with these steps if this does not remedy the problem.

10. Access the X25 Line Management form SOC Forms - Terrestrial Interfaces Menu.If the form fails and a Time Out error appears on the SOC then report the problem toHNS.

11. Check that each line is ON. If any are not then set them to ON. If any fail to do sothen call HNS.

12. Attempt to bring the DEMSAs into service using the DEMSA Management Form . Ifeither do not, or the master fails to start transmitting traffic, then call HNS.

8.7.3 All outgoing telex calls failing

Refer to figure 8-12. Take the lines out of service, using the Telex Trunk Circuit ManagementSOC form, perform a switchover of the TIC, using the FEP Management SOC form, and then put


17th July 2001

8-54

START

BRING UP DEMSA

MANAGEMENT

FORM TIME OUT

DEMSA INS

BRING UP X.25 LINE

MANAGEMENT

CHECK DEMSAs INS

DEMSAs FAILED

PHYSICALLY CHECK BOTH

DEMSAs

No

No

BRING DEMSA INS

DEMSA(S) OK

FORM TIME OUT

CHECK LINES ARE ON

LINE ON

ENABLE LINE

ALL LINES CHECKED

Yes LINES

OK

CONTACT HNS

No

No

Yes

Yes

No

Yes

Yes

Yes

1

1 Yes

1

POWER RESET DEMSAs

DEMSA MASTER POWER

OK

Yes

No

DEMSA STANDBY POWER

OK

BOTH DEMSAs

OK

Yes

FINISH

OBVIOUS H/W

FAULT

1

CONTACT FIELD SERVICE

No

No

Yes

No

SWITCH DEMSAs

DEMSA(S) OK

No

Yes

No

DEMSA(S) INS

Yes

No

Yes

1

No

Yes

FORM TIME OUT

Yes

No

BRING DEMSAs INS

No

Figure 8-11. Recovery Procedure when X.25 Calls Are Failing


8-55

the lines back into service. Make a test call to confirm that communication is re-established. Ifproblems are still being experienced, a BAP switchover may be necessary.

8.7.4 All incoming telex calls failing

Refer to figure 8-13. The actions are similar to the case of outgoing calls failing.

8.7.5 Telex line stuck in retest or bothway busy

Refer to figure 8-14. Use the Telex Trunk Circuit Management SOC form to take the affectedline out of service and then return it to service.

[opg8_inc2.mss]

[opg8.mss]

User Services A4-OPG-003076Issue 3.23 - Accepted

17th July 2001

8-56

INCOMINGTELEX CALLS

FAILING

MAKE ALL INCOMING

LINES OUT OF SERVICE

MAKE SINGLE INCOMING LINE

IN-SERVICE

MAKE ATEST CALL

CHECK SIGNALUSING LINEANALYSER

SWITCHTHE BAPS

REBOOTMASTER TIC

CHECK THEBAP SWITCH

STOP OLDMASTER

BAP

TELEX EXCHANGEPROBLEM

BRING ALLLINES

IN-SERVICE

SIGNALNO SIGNAL

SWITCHOKBAPS DO NOT

SWITCH

INCOMING TELEX CALLS FAILING RECOVERY PROCEDURES

RESTARTBAP

ic_fail.eps

Figure 8-12. Recovery Procedures for Failure of Outgoing Telex Calls

A4-OPG-003076 User ServicesIssue 3.23 - Accepted17th July 2001

8-57

OUT-GOING TELEX CALLS

FAIL

TAKE ALL LINES OUT OF

SERVICE

SWITCH TICS& PUT LINES IN-SERVICE

DO A TESTCALL

SWITCHTHE BAPS

CHECK THEBAP SWITCH

STOP OLDMASTER

BAP

REBOOTOLD MASTER

TIC

REBOOTMASTER TIC

O.K.

BADGOOD

SWITCHOKBAPS DO NOT

SWITCH

RESTARTBAP

OUTGOING TELEX CALLS FAILING RECOVERY PROCEDURES

og_fail.eps

Figure 8-13. Recovery Procedures for Failure of Incoming Telex Calls


17th July 2001

8-58

SELECT TELEX TRUNK

CIRCUIT DISPLAY

MAKE CIRCUIT IN SERVICE

MAKE CIRCUIT OUT OF

SERVICE

SELECT TELEX TRUNK

CIRCUIT MANAGEMENT

OK

Tlx_Fail.eps

Lines stuck in B/W busy or retest .

all lines OK

Figure 8-14. Recovery Procedure when Telex Lines Stuck in Retest or Bothway Busy


9-1

Chapter 9

USER SERVICES

9.1 Mobiles

9.1.1 Mobile Life Cycle

Before considering how the LES administers mobiles, it is useful to understand the whole life cycleof a mobile. This is illustrated in figure 9-1, which shows for completeness all the possible statesfrom the initial construction of the mobile to its use for in service. These states can be sum-marized as follows:

• build - where the serial number is allocated by the manufacturer and the forward andreturn identities are allocated by Inmarsat for all Inmarsat-C mobiles.

• installation - registration in the LES and commissioning tests (PVT) performed. Themobile can now be used in the network.

• Use - for making and receiving calls. During this time the mobile may be repeatedlyswitched on and off and may move from one ocean region to another. It may also gofaulty and have to be repaired.

Down the right hand side of figure 9-1, the entry in the mobile database at the LES is shown,together with the response sent to a terrestrial caller who addresses the mobile. In the case ofCall in progress, the response refers to that given to a second caller.

9.1.2 Information Available

The ACSE maintains a list of all mobiles registered in the system. The ACSE operator is respon-sible for adding mobiles to this list.

The complete mobile list can be very long - tens of thousands of entries - so a number of qualifiersare available. Where it is necessary to view a long list of mobiles, it is advisable to print this onthe report printer rather than attempt to view it on the SOC screen. The mobile list can be viewedon the Mobile List Display (SOC Viewer - Online Processing - Run Reports - Online DatabaseReports). The details of the output are shown below, together with the qualifiers, which for thisreport, are extensive. All the qualifiers are included in the report as a quick reminder of what wasselected.

• mobile number (qualifier)

• forward identity (qualifier)

• return identity (qualifier)

• mobile class

• answerback characters

• answerback parity

• spot in which logged (qualifier) [currently ’0’ as only global beam supported]

• logged into ocean region at present (qualifier)


17th July 2001

9-2

MOBILE DOES NOT EXIST

BUILT & ALLOCATED SERIAL No.

ALLOCATED MOB. NUMBER & FIDRID

ENTERED IN NCS DB

ENTERED IN LES DB

COMMISSIONED

LOGGED IN OR

CALL IN PROGRESS

NCS BARRED

LES BARRED

LOGGED OUT

POWERED OFF / FAULTY

POWER OFF

FAULTY & NOT RESPONDING

FAULTY & RESPONDINGFIXED

PO

WE

R O

N

LOG

IN /

DIS

TR

ES

S A

LER

T /

PA

SS

PV

T

DISTRESS MESSAGE / ALERT MES-LES

LES

UN

BA

RS

DIS

TR

ES

S A

LER

T

FAIL PVT

FA

IL 3

CO

NS

EQ

. PV

T's

DIS

TR

ES

S A

LER

T

NCS BARS

LES BARS

LOG OUT

POWER ON/ FIX

POWER DOWN/ FAULT

FA

ULT

MA

KE

CA

LL

AUTOMATICALLYLOGGED IN BY NCS

PASS PVT.

REG PKT. 'NOT COMMISSIONED'

INMARSAT

NETWORK

MANUFACTURE

LES DATABASE MOBILE STATUS SERVICE CODE (CN 95, F131)

NP

NP

NP

NA

OCC (call should complete as SUC when mobile becomes IDLE)

ABS

ABS

DER

DER

DER

SUPPORTED OR

UN-SUPPORTED OR

SUC

ABS

NOT COMMISSIONED,NOT IN OR

IN OR <REGION>, BUSY

NOT IN OR

IN OR <REGION>, BUSY or IDLE

IN OR <REGION>, IDLE

NCS BARRED, NOT IN OR

LES BARRED, NOT IN OR,or IN OR <REGION>, IDLE

ANYSTAGE

DE

CO

MM

ISS

ION

IDLE

or C

ALL

ED

(NO

RM

AL

or

DIS

TR

ES

S)

POWER DOWN

FIXED

DISTRESS NA

NORMAL NA

DISTRESS NA (IF NOT IN OR)DISTRESS SUC (IF IN OR)

NORMAL NA



MOBILE IS LOGGED INIMMEDIATELY

DISTRESS MESSAGE MES-LES

LES UNBARSLES BARS

DISTRESS MESSAGEMES-LES

DISTRESS ALERT

DISTRESS ALERT

NOT IN OR

NC

S B

AR

S

NC

S U

NB

AR

S

NOT REGISTERED

NOT REGISTERED

NOT REGISTERED

MOBILE REGISTEREDIMMEDIATELY

Figure 9-1. Mobile State Life Cycle


9-3

• commissioned (qualifier)

• barred (qualifier)

• busy (qualifier)

• last update to mobile list

• registered PIN (qualifier)

• ITA2 capability (Y/N)

• binary capability (Y/N)

• barred by LES operator (Y/N)

• land mobile alert destination delivery access code

Any qualifier can be left blank for all values or a range can be selected by entering part of anumber, followed by ’%’; for example to view all the mobiles beginning with 4931, enter ’4931%’ atthe mobile number prompt.

The screen display is shown in Figure 9-2. This needs to be viewed in 132 character mode, sopress .Do

Selection Criteria Values Default

Mobile Number 40000000-499999999 Default is ALL

Spot ID 0-255 Default is ALL

Current NCS Region 0-3 Default is ALL

Forward ID up to eight digits Default is ALL

Return ID up to eight digits Default is ALL

In Ocean Region Yes,No,Both Default is Both

Commissioned Yes,No,Both Default is Both

Barred Yes,No,Both Default is Both

Busy Yes,No,Both Default is Both

Regd User PIN eight characters Default is ALL

Figure 9-2. Mobile List Display Selection

A summary of the current activity on the system can be obtained through the Inmarsat MESStatus Report (SOC Viewer - Online processing - Run Reports - Online Database Reports).

This shows, at the time the report was generated a snapshot of current activity under the head-ings:


17th July 2001

9-4

• total number of MESs

• total number of MESs logged in

• total number of commissioned MESs

• total number of MESs pending commissioning

• total number of barred MESs

• total number of busy MESs

and for each ocean region

• number of MESs logged in

• number of barred MESs

• number of busy MESs

9.1.3 Defining a Mobile

The Mobile Definition form (SOC Forms - User Services - Mobile Users) is indexed by the mobilenumber (9 digits). Press to inspect current information, to remove an entry, orShow Delete Addto add an entry.

The form shows the following :

• forward and return identities, as built into the mobile at manufacture.

• class - 0 for EGC receive only, 1 for to and from mobile message transfer, 2 for com-bined EGC or message handling (switchable to ECG receive only) and 3 for separateEGC and message handling

• answerback - 4 characters (This field is optional)

• current station identity

• spot id into which it is logged (third generation satellite only)

• status - Y or N against each of in ocean region, commissioned, and busy

• last time mobile logged in/out

and the following defined by the LES operator :

• barred

• registered user PIN - the only PIN which can download ENID and DNID numbers tothe mobile. If the operator, in his capacity as a superuser, is the only person au-thorised to download ENIDs and DNIDs, this field should be left blank.

• presentation capabilities - ITA2 and data for the satellite side transmission path. Thedefault values are N and Y respectively.


9-5

• delivery access code - this is optional and is only for land mobiles. It specifies thedestination for non-maritime alerts.

If the operator wants to change the LES set data, press to access the the MobileModifyManagement form (SOC Forms - User Services - Mobile Users). This form is of the same struc-ture as the Mobile Definition form, in that the display is the same, but only allows entry for arestricted number of fields, i.e. those considered as LES managed:

• Barred

• Associated registered user PIN

• Presentation capabilities (ITA2 & Binary)

• Delivery access code (for land alert use)

Press again, enter the new data and press .Modify Enter

Warning : The operator may only modify a mobile’s definition when it is idle, i.e. when the busyflag is set to N. After a modification has been made, a should be performed to ensure thatShowthe changes have been made and that the mobile is still idle. If the mobile became busy whilst itsdefinition was being modified, any modifications made may then be lost.

If after having modified the mobile definition, and upon entering the change, a database messageappears to the effect that the data has not been successfully entered, it may be necessary torepeat the operation.

The reason for losing the change in the first place is that between the original show of data andentering the change that database entry has been modified because of satellite activity associatedwith that mobile.

9.1.4 Barring of Mobiles

The following procedures provide a quick mechanism for barring/unbarring selected mobiles in themobile list. It is assumed that this procedure would not normally be invoked in the case of normaloperation. It could be useful when the LES has been operating for a trial period with an incompletedatabase and it is necessary to resynchronize the mobile list.

The Mobile Set Barred flag determines whether a mobile is barred or not. When set to 1, the flagis taken as FALSE and the mobile is not barred. When set to 2, the flag is taken as TRUE and themobile is barred.

NOTE: If the mobile is busy when the LES operator bars or unbars it the change will not be af-fected until after the mobile has become idle.

9.1.4.1 Barring all the Mobiles

It is assumed that the BAP is not running but that the ONDB_SQL server is.

The following SQL will bar calls using the system barred flag or the ACSE barred flag :-

1> update Mobile set Barred = 22> Return1> exit


17th July 2001

9-6

or

1> update Mobile set Barred_by_ACSE = 22> Return1> exit

9.1.4.2 Unbarring Site Mobiles


Mobiles can be unbarred by using one of the following commands, depending on whether themobile was system barred or ACSE barred :-

1> update Mobile set Barred= 1 where Mobile_Number=xxxxxxxxx2> Return1> exit

or

1> update Mobile set Barred_by_ACSE= 1 where Mobile_Number=xxxxxxxxx2> Return1> exit

9.1.4.3 Automating the Barring and Unbarring of Mobiles


For simplicity the following assumes that the Barred_by_ACSE flag is to be used for the barring ofmobiles.

A SQL file can be generated to bar all the mobiles and then unbar those to be used on site. Atypical example might be :-

/* file to bar all mobile, then unbar site ones */update Mobile set Barred_by_ACSE = 2go

update Mobile set Barred_by_ACSE= 1 where Mobile_Number=491234567go

update Mobile set Barred_by_ACSE= 1 where Mobile_Number=491111111go

checkpointgo/* end of file for barring mobiles */

It should be noted that only two mobiles are illustrated above. The filename might typically beSITE_MOBILE_DEFS.SQL and the command to action the SQL file is :-

$ ondb_load SITE_MOBILE_DEFS.SQL


9-7

9.1.5 Maintaining the Mobile List

The operator can use the Mobile Definition form to repair single corrupted entries or set up testentries.

It is also possible to delete mobiles using the Mobile Deletion form (SOC Viewer - OnlineProcessing - Database Access - User Services Database Access - Mobile Deletion).

Regular back-ups of the mobile list will be made if the procedures described in section 10.3.1 arefollowed.

9.2 Management of Registered Users and ISPs

9.2.1 Management of General Services for Registered Users

The management of registered users is a significant part of the operation of the LES since it iden-tifies the users and ensures access security to enhanced services.

The registered user database as configured here will use information supplied to the ACSEoperator from elsewhere in the organisation.

To add a new user, follow the steps below. Use the same procedure to change the attributes ofan existing one.

Any changes made to the registered user database become effective at the next access made bythe user.

The information to complete these forms should be supplied to the operator by the administration.Appendix B shows the details necessary.

• Firstly use the Registered User Definition form to add the user to the system.

• Enter the users name and address and NDN/PDN information and then the list ofservices to which he has access.

• Complete the following forms for each of the services to which the user has access :

• EGC

• Polling

• Data Reporting Definitions

Depending on local arrangements, some form of acknowledgement may be necessary to confirmthat the user has been added to the database.

Registered users are defined in the system by the Registered User Definition form(SOC Forms -User Services - Registered Users). After entering the PIN allocated (the actual allocation is aseparate administrative function) the operator should press for a new entry or for anAdd Showexisting one. To change an existing one, can then be used. To delete an existing user,Modifypress .Delete

Note 1: Although no checks are made on the characters which make up a PIN, other than theyare alpha-numeric, it is advised that no new PIN is created which ends in ’X’. This is because ofthe special use of ’X’ in batch mode access by the terrestrial user and the conflict when both PINs


17th July 2001

9-8

<string>X and <string> exist.

Note 2: The Registered User Definition SOC form and the ones accessed directly from it (e.g.the EGC form) will automatically display the last set of relevant data giving in response to theoperator typing a PIN, provided that that data has not been altered in any way. This provides aquick reference to the information which is expected in each field but does not affect the operationof the form in any other way.

Note 3: DNID zero is allocated to the predefined ’SYSTEM’ PIN. The ’SYSTEM’ PIN should not bedeleted or unbarred.

The following General Information details relate to registered users:

• user name - up to 45 characters

• address - up to three lines of 30 characters each

• postal code - up to 15 characters

• country - up to 20 characters

• contact name and telephone number. The name could be different from the username, for example a person within a company, or ’as user name’ could be entered indefault.

Note 1: the fields which are part of ’General Information’ are only of use to the ACSE operator, forexample to assist system administration. These fields are not used for processing messages andfor that reason it is optional whether any of these to contain data.

Note 2: ’User Name’ can only be modified using the Registered User Definition SOC form butwill appear as read-only in the other Definition SOC forms.

Delivery Information for Non Delivery Notifications (NDNs) and Positive Delivery Notifications(PDNs). PDNs are generated once the delivery outcome of a message for all the destination ad-dressees is known, all deliveries are successful, and PDNs have been specified for that user.NDNs are generated instead of PDNs once the final delivery outcome of a message is known, ifone or more of the deliveries ended in failure, and NDNs have been specified for that user.Furthermore, for both PDNs or NDNs to be generated, a delivery notification address must be bespecified.

Users authorised for PDNs will automatically receive NDNs as well; it is not necessary to be au-thorised for NDNs on this form as these will be generated in the case of delivery failure regardless,providing the delivery address for notifications is set up. The following fields are optional, but it isrecommended that they are completed.

• address enabled for use for PDNs - set to Y or N according to whether the usershould be sent Positive Delivery Notifications.

• address enabled for use for NDNs - normally set to Y, but can be set to N.

• delivery address for notifications - this is in the same form as if the registered userwere addressed by a mobile, i.e. it consists of address format, address and addressextension fields. The following address formats are supported: Telex, PSTN, PSDN,Mobile Number, or Special Access Code (providing this translates to one of the pre-vious formats ). For PSTN delivery, ’T30’ must be entered in the address extensionfield, otherwise the field should be left blank.


9-9

Authorisation information , i.e. the services which the PIN owner is entitled to have access to,shown by entering Y or N against the following: For new users no defaults are provided, except fordistress priority messages N, so all these fields must be completed.

• User barred - (use if it is desired to temporarily bar a user but not remove the recordof that user from the database)

• Store and forward messages

• Message status enquiry

• Cancel messages

• Polling

• Data reporting

• EGC

• PDNs - see above

• Distress priority messages - (messages, not EGCs etc., from this user will be sent atdistress priority. For EGC messages, the user sets the priority by entering the ap-propriate C1 code during submission of the EGC message.)

• X25 NUA checking - not used (default N).

Info provider string - This string (21 characters), preceded by LES ID (3 characters) and ’,’ (1character) will precede the user entered ’free’ message text which is part of any Download/DeleteENID or Download Poll command which is originated by the user. The field will be right filled withspaces. See Section 9.4 for further description of this string.

Access Controls - these fields must be completed, except ’last update’.

• PIN for use with telex - set to Y if the registered user is to be allowed access via telex

• PIN for use with X25 - set to Y if the registered user is to be allowed access via PSDN

• Answerback - up to 18 characters. This is used to verify the identity of the caller. Ifthis field is left blank, the caller can supply any answerback; only leave this field blankif universal access is to be granted using this PIN.

• Password - to be entered initially by the operator as the same as the PIN; this issubsequently under control of the user. This is used for PSDN access only.

• Last update - the last time the user changed his password. A time limit can be set toforce the user to update his password at regular intervals as described in section 9.5.This field is read only.

Table 9-1 indicates the possible combinations of the settings used to select the NDN and PDNfunctions:


17th July 2001

9-10

PDN authorised Address enabled Address enabled Messageflag for NDNs for PDNs sent

N N N NoneN N Y Invalid selectionN Y N NDNN Y Y Invalid selectionY N N NoneY N Y PDNY Y N NDNY Y Y PDN

Table 9-1. Settings used to select NDN and PDN functions

Remember that PDNs include notifications of non-delivery and have the same format.

Further detail is required for each of the services and is shown on separate forms. These can beaccessed by function keys - , or .EGC Polling Data Reporting

Note: the ability to enable/disable the EGC, Polling and Data Reporting services is available fromthe Registered User Definition SOC form. The ability to enable/disable the EGC service is alsoavailable from the Registered User EGC Definition SOC form. The ability to enable/disable thePolling service is also available from the Registered User Polling Definition SOC form. Theability to enable/disable the Data Reporting services is also available from the Registered UserData Report Definition SOC form.

Using the Registered User NUA Definition SOC form (SOC Forms - User Services - RegisteredUsers), the operator may specify up to ten NUA addresses. A full NUA address consists of 14digits. One of these addresses must match that of the caller using the PIN in order to gain accessto the registered user services offered by the LES for that PIN. The operator may specify a partialNUA of less than 14 digits, which can be compared with corresponding digits if an NUA. The digitsspecified in a partial NUA are the most significant (i.e. leftmost) digits of the full NUA.

The least significant 2 digits of an NUA is the NUA subaddress. The PIN owner must include thesein the offered NUA, if the NUA defined at the LES also contains the subaddress.

To cause the LES to make NUA checks the X25 NUA checking flag must be set to Y using eitherthe Registered User NUA Definition SOC form or the Registered User Definition SOC form.

xxxxx

9.2.2 Management of EGC Services for Registered Users

For EGC services, use the Registered User EGC Definition form (SOC Forms - User Services -Registered Users).Against the PIN, the user name is shown and the operator must indicate by a Yor N which of the following services the user is allowed to originate:

• General call

• Group call

• Urgent Msg/Nav warn rec

• System message


9-11

• Coastal warning

• Shore to ship distress

• EGC system message

• Urgent Msg/Nav Warn circular

• NavArea warning/Met forecast

• Download group ID

• SAR coordination rectangular

• SAR coordination circular

• Chart correction

• Chart correction - fixed area

This form also allows up to 20 ENIDs which can be associated with that PIN to be set up.

9.2.3 Management of Polling Services for Registered Users

For Polling services, use the Registered User Polling Definition form (SOC Forms - UserServices - Registered Users). Against the PIN, the user name is shown and the operator mustindicate by a Y or N which of the following services the user is allowed to originate:

• Send unreserved report

• Program reserved

• Initiate reserved

• Stop reserved

• Program unreserved

• Initiate unreserved

• Stop unreserved

• Define macro encoded message

• Data transmission

• Download DNID

• Delete DNID

9.2.4 Management of Data Reporting Services for Registered Users

For Data Reporting Services use the Registered User Data Report Definition form (SOC Forms- User Services - Registered Users). The operator must configure a user to have a file of a givensize and one or more DNID numbers, up to a maximum of 20. The file size is an overall number


17th July 2001

9-12

to accommodate all the DNID numbers allocated to the user. Section 9.7 describes how the DNIDfile sizes can be determined. For each DNID number entered the following corresponding datamust also be set up:

• Randomizing Interval - used as part of the Satellite Driver Protocol associated withtime of arrival of DNIDs, enabling reports for different DNIDs to arrive at differenttimes, usually set (0 - 255) with relation to the size of the DNID group.

• Spot ID - ’000’ if global, else designated spot beam.

• Delivery Action - Select from:

• STO_ONLY, i.e. data is stored in a DNID file for future retrieval by the fileowner.

• FWD_ONLY, i.e. data is queued for immediate delivery to the correspondingX.121 address. If delivery is unsuccessful the data is discarded.

• FWD_OR_STO, i.e. as FWD_ONLY except that if delivery is unsuccessful thedata is stored in the DNID file for later retrieval.

• Route - Route used for immediate forwarding.

The route used must be a PSDN route as defined in section 8.3.3 and may be eitherthe normal delivery route (i.e. shared with the delivery of store and forward mes-sages) or a separate route set up and reserved for immediately forwarded DNIDreports.

• X121 Address - X.121 address used for immediate forwarding.

The X.121 address must be the full international address, beginning with the DNICused for international calls, as would be entered by a mobile user or foreign sub-scriber. The X.25 driver performs any address substitution required before connectingto the PSDN.

• Hold Time - Time circuit left open after last data report sent.

This time can be up to 99999 seconds, thus allowing semi-permanent circuits to beset up. The X25 driver’s normal delay before sending the clear packet acts as a min-imum Hold Time.

9.2.5 Management of Mobile Services for Registered Users

This facility is not available.

9.3 Displaying Information Regarding Registered Users

The operator can view the registered users configured in the system using the Registered UserDisplay (SOC Forms - User Services - Registered Users). This display is keyed to a user’s name.The operator should enter the name, in exactly the correct form matching upper and lower caseletters. As well as the PIN, this form shows a contact name and telephone number in case theoperator needs to call the user to handle a problem.

To provide more information, two reports are available :

• Registered User Summary - which summarizes the services assigned to the user


9-13

• Registered User Full Report - which provides a detailed breakdown for a given user.

The Registered User Summary Display (SOC Viewer - Online Processing - Run Reports -Online Database Reports) shows in tabular form the following details :

• PIN

• Barred - yes or no

• Name - plain text

and a ’Y’ or ’N’ against each entry to show the facilities as follows :

• POL : polling

• EGC : enhanced group calls

• DRP : data reporting

• SFM : store and forward messages

• MSE : message status enquiry

• CAN : cancel messages

• PDN : positive delivery notification

• the following EGC services

• GEN : general call

• GRP : group calls

• UMR : urgency message, NAV warning to rectangular area

• SYS : system message

• COW : coastal warning

• SSD : shore ship distress alert to circular area

• ESM : EGC system message

• MWC : urgency message, MET/NAV warning to circular area

• NAW : navarea warning

• DGI : download group identity

• SAR : SAR co-ordination to rectangular area

• SAC : SAR co-ordination to circular area

• CHC : chart correction service

• CHF : Chart correction service for fixed areas


17th July 2001

9-14

• the following Polling commands

• SUR : send unreserved report

• PRD : program reserved data reporting

• IRD : initiate reserved data reporting

• SRD : stop reserved data reporting

• PUD : program unreserved data reporting

• IUD : initiate unreserved data reporting

• SUD : stop unreserved data reporting

• DMM : define macro-encoded message

• MEM : send macro encoded message

• DTX : data transmission

• DLD : download DNID

• DEL : delete DNID

The selection criteria available in order to generate this display are shown in figure 9-3:


Registered user PIN 8 characters ALL

User barred Yes, No, Both Both

Figure 9-3. Registered User Summary Display Selection

The Registered User Full Display (SOC Viewer - Online Processing - Run Reports - OnlineDatabase Reports) is selected by PIN and shows all the details listed above on the SummaryReport, plus the following:

• full address of the registered user

• address for notification messages (non-delivery and positive delivery)

• ENIDs allocated to PIN

• DNIDs allocated to PIN together with details of file usage, any time for which the filehad overflowed and the number of data reports lost due to over full files

The selection criteria available in order to generate this display are shown in figure 9-4.


9-15


Registered user PIN 8 characters ALL

User barred Yes, No, Both Both

DNID 4 digits ALL

Figure 9-4. Registered User Full Display Selection

9.4 Download of ENIDs and DNIDs to Mobiles

ENIDs are allocated by Inmarsat on a Global basis, only those ENIDs that are allocated byInmarsat may be used.

DNIDs in the range 1-32767 may be allocated by an LES (note a dual ocean region LES uses onlyone range of numbers). DNIDs 32768 to 65535 are reserved for future use.

It is strongly advised that the LES operator maintain a separate register of all operations as-sociated with the allocation of ENIDs and DNID’s and the distribution to registered users andMobiles. It is not possible to retain this information on the ACSE in ENID or DNID order.

When a mobile is to be added or removed from a closed network identity, either for EGC (ENID) orPolling/Data Reporting (DNID), the fleet owner or service provider may contact the administrationand ask for the change to be made.

The achieve this the LES operator must generate either an Individual EGC Message for ENIDs oran Individual Poll for DNIDs to the mobile which is to receive the new identity or have one deleted.

The first 25 characters of the user entered ’free’ text field received by the mobile will be of theform:

<LES_ID>,<ORIGINATOR ID>

where:

LES_ID is a 3 character string which identifies the LES e.g. 202.ORIGINATOR_ID is a 21 character "Information provider" string which identifies the PIN user,

which is set up in the Registered User Definition SOC form, (see Section 9.2.1)This will automatically inserted by the LES just before any ’free’ text enteredby the operator.

Note that only IA5 is supported - the text cannot be sent in ITA2.

The following are suggested steps how the operator should download ENIDs and DNIDs tomobiles:

1. Allocate the required EGC or Polling services required for the user and enter thesedetails in the operator’s register. Note the Registered user’s Name and PIN.

2. Use the Registered User Definition SOC form to ensure that the registered user isenabled for the desired service(s) (if necessary).

3. Use the Registered User EGC Definition , Registered User Polling Definition and


17th July 2001

9-16

Registered User Data Reporting Definition SOC forms to further ensure that theservices available to the registered user are those required, and that ENIDs andDNIDs are correctly allocated to the user (if necessary).

4. Disable Download/delete ENID or DNID services on the appropriate Definition forms(not necessary but advised for operational reasons).

5. Log into the LES, via X.29, using the Registered user’s PIN together with theOperator’s superuser password, as discussed in Section 9.6. This overrides the ’au-thorise type’ checks in the registered user table, although ENIDs and DNIDs muststill first be allocated.

6. Select either the EGC or Polling function to download or delete the ENID/DNID tothe maximum number of mobiles allowed, ensuring that required parameters (espe-cially for Polling) are set as required by the registered user, including subaddress,member number and sequence.

7. Use the message status enquiry facility ensure that the delivery succeeded.

8. Repeat download/delete for all required mobiles.

9. Inform registered user of outcome, confirm for polling the last sequence numberused. If a delivery notification is generated it will go to the address shown in theRegistered User Definition SOC form.

Note: It is not possible to tell if the poll or the EGC have actually been received and processed bythe mobile (unless, for polls, an acknowledgement is requested).

A record of the downloads performed by the LES operator could be maintained in an OperatorRegister. The Operator Register could include information such as:

Field Example 1 Example 2 Example 3

Type ENID DNID DNID

ID 12345 23456 23456

PIN 12345678 abcdefgh abcdefgh

LES ID, Informationprovider

011,21_character_string



Date 29-SEP-1992 29-SEP-1992 29-SEP-1992

Time of operation 16:00:00.00 16:00:00.00 16:00:00.00

Mobile no 412345678 498765432 498765433

MRN 123450 123460 123470

CCC 50 50 50

Polling: Subaddressmember Sequence

000 000

001 002

001 001

Table 9-2. Example extract from the Operator Register


9-17

9.5 Password Update

The password used by registered users to gain access to the ACSE can be changed at will by theuser. The access is described in the X25 Interface Definition which is included as part of theSystem Manual, Reference [2].

The ACSE operator can set a parameter to force all registered users in the LES to update theirpasswords at a preset interval, in weeks. The software as initially installed has no entry, giving aninfinite expiry time. If it is desired to set a value, this must be done by directly accessing thedatabase. Log on to the BAP as described in section 12.2 and then use the following commandsin response to the prompts, shown in bold:

CES nnnn> ONDB

to get to the database SQL prompt. Insert these commands at the prompts

1> update Passwd_Expiry set Timestamp=getdate(),Passwd_Expiry_Limit=12> go

This is case sensitive. A value of 1 week expiry is illustrated. The maximum expiry period allowedis 255 weeks.

For an indefinite password expiry period, delete the Password Expiry entry from the database asfollows :-

1> delete Passwd_Expiry2> go

Exit from the SQL prompt by typing Exit.

Note: direct use of SQL should only be undertaken when absolutely necessary as in theseoperations all safeguards against causing database corruption, are removed.

9.6 Superuser Password for the Operator

The LES operator is able to use a Superuser password, sometimes referred to as Supervisorpassword, to perform certain privileged tasks, such as the downloading of ENIDs and DNIDs tomobiles. This password is set using Change Superuser Password (SOC Viewer - OnlineProcessing - Database Access - User Services).

9.7 Data Reporting File Management

Individual files are maintained at the ACSE for each user registered for the Data Reporting ser-vice. These files are identified by the DNID number used in the data report sent by the mobile.The files are set up as part of the registration process but the operator can inspect any file usingthe Data Report File Display (SOC Forms - User Services - Data Reporting).

The PIN of the registered user should be entered and pressed to bring the followingFirst Pagedetails on the screen :

• total number and size of reports

• total size of reports

• total free space


17th July 2001

9-18

• an indication if the file has overflowed

• time of last retrieval of data by the terrestrial owner

• number of reports in the file which have been downloaded

• number of reports in the file which have not been downloaded

• for each DNID owned by the registered user: the time and date of the earliest andlatest data reports together with the delivery route and the delivery action, i.e. auto-store, or immediate forwarding (with or without deletion if delivery attempt not suc-cessful)

Use for more information. If it is necessary to clear all the files displayed on theNext pagescreen, press . Alternatively, selective deletion can be achieved by pressingDelete all Manageto access the Data Report File Management SOC form.

Normally the contents of each Data Report file must be regularly checked and cleared by theowner. The operator can find out how many reports there are in the file by using the Data ReportFile Management form (SOC Forms - User Services - Data Reporting). Both the registered usersPIN and the relevant DNID number must also be entered by the operator. The operator can selectall reports of those between two specified times. The operator can also delete all the records in aDNID by pressing .Delete

The ACSE database reserves a total of 10 Mbyte of disk space for data report storage. This limitcan be increased in consultation with HNS Ltd.

Each registered user should be allocated a suitable maximum file size so that disk space is usedefficiently. Administrations may wish to charge for the amount of space used by each user;changes should only be made when this is taken into consideration.

Disk space for data reports is allocated on a registered user basis, using the Registered UserData Report Definition SOC form, in blocks of 500 bytes. For any one registered user, no morethan 1 Mbyte can be allocated. Each registered user can have up to 20 DNID numbers allocated;the system can handle a maximum of 2000 DNIDs.

9.8 Performance Verification Tests

The operator has a means of initiating these tests using the Initiate PVT form (SOC Forms - UserServices - Mobile Users). The operator must enter the mobile number and then press .Start

The results of a PVT will appear on the Event Printer when the tests are complete - this may takeseveral minutes. The results can then also be viewed on the Initiate PVT form.

[opg9.mss]

A4-OPG-003076 System ControlIssue 3.23 - Accepted17th July 2001

10-1

Chapter 10

SYSTEM CONTROL

This section describes how the operator controls the ACSE equipment itself.

10.1 Background Applications Processors

10.1.1 BAP Management

The BAP Management form (SOC Forms - System Control) is used to show the condition of thetwo BAPs in the system and to perform manual switchover from master to standby and vice versa.Separate commands, shown in section 12 are used to start or stop a BAP. For each BAP, theform shows :

• BAP Name : as configured when the system is set up

• Mode : see below

• Processor state : see below

• Interface status : UP or DOWN

This form is used by the operator to manually switch BAPs using the key.Switch

Processor modes are required to allow a pair of processors to behave as a redundant pair, i.e. theProcessor Modes allow the redundant processors to power-up, switch-over and stop in asynchronized manner. The possible processor modes are:-

• UNKNOWN - Processor not running LES software or being booted

• MASTER - Processor running LES software and taking traffic

• STANDBY - Processor running LES software, but not taking traffic

• IDLE - Processor running LES software, but unable to take traffic, i.e. it has beentaken out of service.

Each redundant processor in the system is composed of one or more processes. As well ashaving a mode, these processes have a state. The process state allows a processor to switcheach of its constituent processes from one mode to another in a synchronized manner. The pos-sible BAP processor states are:-

• UNKNOWN - Process not running or being booted

• INIT - Process initializing (without database access)

• DB_SYNC - Process initializing (with database access)

• SYNC - Process ready to run

• RUNNING - Process running

• END_RUNNING - Process stopping before a switch-over

System Control A4-OPG-003076Issue 3.23 - Accepted

17th July 2001

10-2

• FAILED - Process reported an error (switch-over should occur)

Processor modes and states are of interest at :

• system power up

• processor switch over

When considering the behaviour of the system at power up , it is best to consider processor modeand state separately. When a redundant pair of processors power-up, one processor will be in-structed to power-up in Master mode, and the other will be instructed to power-up in Standbymode. Each processor will then follow the state transitions as shown in the state transitiondiagram figure 10-1

A process may fail at any time; this is represented by the fact that the Fail state may be reachedfrom any other state (except unknown) when the LES software is running.

When considering a manual switch-over for a pair of redundant processes, it is useful to visual-ize two state transition diagrams next to each other - one which is currently in Master mode andRunning state, and the other which is in Standby mode and Running state. A switch-over isrepresented by the Master BAP moving from Master/Running to Standby/End_Running and theStandby BAP moving from Standby/Running to Master/End_Running. Each processor will gothrough the states shown to end up at Running, at which point traffic handling will resume. TheBAPs will then stay switched until the next transition from Running to End_Running is made.

When a fault occurs, i.e. a forced switchover , the master will make the transition to idle and thestandby will make the transitions shown above.

10.1.2 BAP Switchover Process

If a BAP switch is takes place, there will be an interruption to service lasting a matter of a fewminutes, the precise value being dependant upon the speed of the processor employed. It is alsoadvisable to complete any billing runs before switching BAPs, as there would be a performancedegradation on the new master BAP if billing is running.

Use the BAP Management form (SOC Forms - System Control) to effect the switchover, whichwill cause each BAP to transition through the states shown above in section 10.1.1. The progressof the switchover can be followed on each BAP using the BAPOP SHOW STATE commanddescribed in section 12.3. The final response to the BAPOP SHOW STATE command will be a listof tasks as illustrated in tables 10-1 and 10-2.

Note: The definitive list of tasks will vary according to what features are enabled at any given LESinstallation.

There are two types of switchover: the first is invoked using the key, where the MasterSwitchBAP becomes Standby and the Standby BAP becomes eventually becomes a Running Master.The second is invoked using the key, where the Master BAP fails and the Standby BAPFailbecomes eventually becomes a Running Master. In both cases the operator is prompted to con-firm whether or not the Switchover or Failover is to go ahead.


10-3

4-s1

;4P

RC

BA

P T

ask

Sta

te C

ontr

ol 12 3 4 5

6

7

Unk

now

nIn

it

DB

_Syn

c

Syn

c

Run

ning

End

_Run

ning

Fai

l

Mod

e C

hang

e E

ffect

ed

Figure 10-1. BAP Process State Control


17th July 2001

10-4

CES nnnn> BAPOP SHOW STATE

PRC Commanded Processor ProcessorReady Processor Mode Mode State SynchronizingTRUE MASTER MASTER RUNNING FALSE

Ind Task Name Intro- Current Desired Notify_On Respondedduced State State State_Change

1 APM_P_01 TRUE RUNNING RUNNING TRUE TRUE2 CUC_BAP_MSD__01 TRUE RUNNING RUNNING TRUE TRUE3 DCD_MGR_P_01 TRUE RUNNING RUNNING TRUE TRUE4 DIM_LINK_MGR_01 TRUE RUNNING RUNNING TRUE TRUE5 DIM_LINK_MGR_02 TRUE RUNNING RUNNING TRUE TRUE6 DIM_LINK_MGR_03 TRUE RUNNING RUNNING TRUE TRUE7 DIM_LINK_MGR_04 TRUE RUNNING RUNNING TRUE TRUE8 EM_P_01 TRUE RUNNING RUNNING TRUE TRUE9 ERRLOG_01 TRUE RUNNING RUNNING FALSE TRUE10 LESFAX_P_01 TRUE RUNNING RUNNING TRUE TRUE11 FCR_BAP_CONN_01 TRUE RUNNING RUNNING FALSE TRUE12 FDCD_EXT_MGR_01 TRUE RUNNING RUNNING TRUE TRUE13 FDCD_EXT_MGR_02 TRUE RUNNING RUNNING TRUE TRUE14 FDCD_EXT_MGR_03 TRUE RUNNING RUNNING TRUE TRUE15 FDCD_EXT_MGR_04 TRUE RUNNING RUNNING TRUE TRUE16 FEH_BAP_MAIN_01 TRUE RUNNING RUNNING TRUE TRUE17 IC_BAP_MSD_P_01 TRUE RUNNING RUNNING TRUE TRUE18 LFM_FILE_SER_01 TRUE RUNNING RUNNING TRUE TRUE19 MC_LOGGER_P_01 TRUE RUNNING RUNNING FALSE TRUE20 MCM_P_01 TRUE RUNNING RUNNING TRUE TRUE21 MDIR_P_01 TRUE RUNNING RUNNING TRUE TRUE22 PRC_EVENT_MO_01 TRUE RUNNING RUNNING FALSE TRUE23 PRC_HANDSHAK_01 TRUE RUNNING RUNNING TRUE TRUE24 PRC_PROC_STA_01 TRUE RUNNING RUNNING TRUE TRUE25 PRC_TASK_STA_01 TRUE RUNNING RUNNING TRUE TRUE26 RG_P_01 TRUE RUNNING RUNNING TRUE TRUE27 SCVFCC_DRIVE_01 TRUE RUNNING RUNNING TRUE TRUE28 SDC_MAIN_P_01 TRUE RUNNING RUNNING TRUE TRUE29 SM_P_01 TRUE RUNNING RUNNING TRUE TRUE30 SOI_SERVER_P_01 TRUE RUNNING RUNNING TRUE TRUE31 TBCC_DRIVER__01 TRUE RUNNING RUNNING TRUE TRUE32 TOKM_P_01 TRUE RUNNING RUNNING TRUE TRUE33 X4CC_DRIVER__01 TRUE RUNNING RUNNING TRUE TRUE34 XCCC_P_01 TRUE RUNNING RUNNING TRUE TRUE35 PADR_MAIN_P_01 TRUE RUNNING RUNNING TRUE TRUE36 SADINIT_01 FALSE RUNNING UNKNOWN FALSE FALSE

Table 10-1. Master BAP - response to BAPOP SHOW STATE command


10-5


PRC Commanded Processor ProcessorReady Processor Mode Mode State SynchronizingTRUE STANDBY STANDBY RUNNING FALSE

Ind Task Name Intro- Current Desired Notify_On Respondedduced State State State_Change

1 APM_P_01 TRUE RUNNING RUNNING TRUE TRUE2 CUC_BAP_MSD__01 TRUE RUNNING RUNNING TRUE TRUE3 DCD_MGR_P_01 TRUE RUNNING RUNNING TRUE TRUE4 DIM_LINK_MGR_01 TRUE RUNNING RUNNING TRUE TRUE5 DIM_LINK_MGR_02 TRUE RUNNING RUNNING TRUE TRUE6 DIM_LINK_MGR_03 TRUE RUNNING RUNNING TRUE TRUE7 DIM_LINK_MGR_04 TRUE RUNNING RUNNING TRUE TRUE8 EM_P_01 TRUE RUNNING RUNNING TRUE TRUE9 ERRLOG_01 TRUE RUNNING RUNNING FALSE TRUE10 LESFAX_P_01 TRUE RUNNING RUNNING TRUE TRUE11 FCR_BAP_CONN_01 TRUE RUNNING RUNNING FALSE TRUE12 FDCD_EXT_MGR_01 TRUE RUNNING RUNNING TRUE TRUE13 FDCD_EXT_MGR_02 TRUE RUNNING RUNNING TRUE TRUE14 FDCD_EXT_MGR_03 TRUE RUNNING RUNNING TRUE TRUE15 FDCD_EXT_MGR_04 TRUE RUNNING RUNNING TRUE TRUE16 FEH_BAP_MAIN_01 TRUE RUNNING RUNNING TRUE TRUE17 IC_BAP_MSD_P_01 TRUE RUNNING RUNNING TRUE TRUE18 LFM_FILE_SER_01 TRUE RUNNING RUNNING TRUE TRUE19 MC_LOGGER_P_01 TRUE RUNNING RUNNING FALSE TRUE20 MCM_P_01 TRUE RUNNING RUNNING TRUE TRUE21 MDIR_P_01 TRUE RUNNING RUNNING TRUE TRUE22 PRC_EVENT_MO_01 TRUE RUNNING RUNNING FALSE TRUE23 PRC_HANDSHAK_01 TRUE RUNNING RUNNING TRUE TRUE24 PRC_PROC_STA_01 TRUE RUNNING RUNNING TRUE TRUE25 PRC_TASK_STA_01 TRUE RUNNING RUNNING TRUE TRUE26 RG_P_01 TRUE RUNNING RUNNING TRUE TRUE27 SCVFCC_DRIVE_01 TRUE RUNNING RUNNING TRUE TRUE28 SDC_MAIN_P_01 TRUE RUNNING RUNNING TRUE TRUE29 SM_P_01 TRUE RUNNING RUNNING TRUE TRUE30 SOI_SERVER_P_01 TRUE RUNNING RUNNING TRUE TRUE31 TBCC_DRIVER__01 TRUE RUNNING RUNNING TRUE TRUE32 TOKM_P_01 TRUE RUNNING RUNNING TRUE TRUE33 X4CC_DRIVER__01 TRUE RUNNING RUNNING TRUE TRUE34 XCCC_P_01 TRUE RUNNING RUNNING TRUE TRUE35 PADR_MAIN_P_01 TRUE RUNNING RUNNING TRUE TRUE36 SADINIT_01 FALSE RUNNING UNKNOWN FALSE FALSE

Table 10-2. Standby BAP - response to BAPOP SHOW STATE command


17th July 2001

10-6

Note: Following the switchover, it is advisable to restart the old Master BAP since this will reset allthe software into a known state. This is necessary regardless of whether the key or theSwitch

key has been used.Fail

If the BAP that is to become Master takes greater than 10 minutes to attain the "Running" state, orthe "old" Master BAP shows any failed states, then use the STOPBAP command to stop the "old"Master. If the new Master still refuses to become MASTER RUNNING within 5 minutes of stop-ping the other BAP, then it too should be stopped using BAP STOP command. Once it hasstopped, as indicated using the BAPOP SHOW STATE command, restart it using the BAPOPSTART BAP ARBITER command. Then restart the other BAP using the same command.

Notes:

1. It is advised that a BAP switchover is not requested via the BAP Management SOCform in the case of a failure of one of the VMS processes running on the MasterBAP, because the failed process cannot be expected to respond correctly to a con-trolled switchover.

It is therefore recommended that a BAPOP STOP BAP command on the MasterBAP be performed when wishing to switch BAPs instead of requesting a switch viathe BAP Management SOC form. This has the added advantage of forcing theoperator to restart the old Master BAP (which is necessary in order to restart theVMS process which had previously failed).

2. Whilst a switchover is taking place the BAP mode and states displayed by the SOCwill not always be consistent with those obtained using BAPOP commands on theBAP.

10.1.3 Manually Controlled BAP Switchover

The operator can manually force switchover of the BAP using the BAP Management form (SOCForms - System Control). It is also possible to manually select the online BAP using the switch onthe front of the Arbiter card - the CPU card in the Arbiter Tray. The centre position is for Automaticswitchover, the upper position selects BAP A and the lower position selects BAP B. For normaloperation with automatic redundancy, leave the switch in the centre position. To force change-over, move the switch either up or down and keep it there for at least 40 seconds to ensureswitchover is forced.

The switch can also be used to prevent switchover by putting it in the position corresponding tothe online BAP.

When the switch is not in the centre position, the CAP3 LED flashes continuously as a reminder.

Remember to restore the switch to the centre position for redundant operation of thesystem .

If for any reason the CPU card in the Arbiter Tray has to be removed, or if it is faulty, automaticswitchover of the BAPs will be disabled. The online BAP will remain online, i.e. Master andStandby BAPs will remain so. However lines will switch to BAP A.

Therefore it will be necessary to ensure that the asynchronous lines from the Master BAP arecorrectly routed through the switches normally controlled by the Arbiter. To do this, access theswitch at the rear of the switchover tray, (situated on the PSU+Relay card on the Arbiter Tray, tothe left of the power supplies looking from the back of the rack). There are two switches towardsthe rear lower part of the card: the one nearest the rear of the rack should normally be in thecentre position but can be moved downwards to force the connection of BAP B. Similarly, moving


10-7

the other switch will force connection to BAP A, although it will not be necessary to take any actionif BAP A is Master.

Once the Arbiter has been restored to an operational state, ensure both switches are in the centreposition.

10.1.4 BAP Failure

When a BAP fails, switchover will take place to the standby unit and an alarm will be raised.Failure can be due either to a software problem or to a failure in the hardware.

First of all check that the power supply to the affected unit has not failed. On the BAPs, an orangelight should be visible in the bottom right hand corner of the front panel. If this indication is notpresent, check the supply circuit breakers. If the supply is working but the unit is still not opera-tional, it will be necessary to call the DEC service engineer.

If the unit is powered up, the next step is to try restarting the software; follow the steps outlined insection 12. For BAPs, use the BAPOP START BAP command. Once software load is complete,the unit will go to the Standby state.

If the unit fails to restart, call the DEC service engineer.

10.1.5 System Time

Note: Two mechanisms are available for setting system time, depending on the customers con-figuration. In both cases, the system time is distributed from the master BAP to the standby BAPand the online SOCs, such that there should not be a discrepancy between BAP and SOC timesof more than 2 - 3 seconds.

10.1.5.1 Setting the Time on the VAX Clock

The time which appears on the SOC and on event reports is derived by the BAP and is not ahighly accurate clock. For operational purposes of the system it is still desirable to keep the sys-tem clock roughly in line with real time so that frame 0000 occurs at midnight UTC.

Any drift which does occur will do so slowly. After several months, it is possible that the systemclock is one or two minutes adrift from real time. The following commands can be used to resetthe time but they involve BAP shutdown to put into effect. Therefore HNS recommends that theyare only used if time drifts by at least 5 minutes. The commands may also be used, if desirable,when the BAPs are stopped for any other reason.

To adjust the time on a running system, use the following procedure:

1. Stop both BAPS, by entering the command:

CES nnnn> BAPOP STOP BAP

on each BAP.

2. On both BAPs change the time on each BAP with the command:

CES nnnn> SET TIME=DD-MMM-YYYY:hh:mm:ss

Where (DD-MMM-YYYY:hh:mm:ss) is the current date and time, for example 26-SEP-1996:19:31:00, for 7:31pm on the 26th of September 1996.


17th July 2001

10-8

3. Restart both BAPS, by entering the command:

CES nnnn> BAPOP START BAP ARBITER

on each BAP.

4. Once the BAP startups are complete, the time has been set successfully. Thestatus of the BAPS as they restart, can be monitored with the command:


Sections 12.1 and 12.3 describe the commands shown above.

10.2 Front End Processors

10.2.1 Telex and CU FEP Management

The FEP Management form (SOC Forms - System Control) shows the condition of all the FEPs inthe system, with the exception of the X.25 DEMSAs which are handled separately. For each itshows :

• S : enter a ’Y’ in this column to activate the or soft key commands.Restrt Switch

• Name : as configured when the system is set up

• Mode : as for the BAP, shown above

• Processor state : init (initializing), sync (synchronizing), run (running) or unk (un-known)

• Service state : out (out of service) or ins (in service)

• Interface status : up or down.

The FEPs appear in a fixed order on this form as follows :

CUC1A AOR(West) - if not equipped, will show UnknownCUC1B AOR(West) - if not equipped, will show UnknownCUC2A AOR(East) - if not equipped, will show UnknownCUC2B AOR(East) - if not equipped, will show UnknownCUC3A POR - if not equipped, will show UnknownCUC3B POR - if not equipped, will show UnknownCUC4A IOR - if not equipped, will show UnknownCUC4B IOR - if not equipped, will show Unknown

TELEX FEP1A circuits 101-116TELEX FEP1B circuits 101-116TELEX FEP2A for circuits 117-132TELEX FEP2B for circuits 117-132TELEX FEPs for any further circuits equipped, in order.

Note that the numbering of the Channel Unit Controllers does not correspond to the numbering ofthe ocean regions.


10-9

This form is used by the operator to manually switch FEPs. To manually force switchover enter ’Y’in the left-hand column beside the name of either of the two FEPs and press . ToSwitch FEPsmanually restart a FEP, enter a ’Y’ alongside its name and press .Restrt FEP

Note: that in the case of channel unit FEPs, any switchover will discard existing calls set up onthe satellite side. The interruption to traffic handling can be minimized by setting the flow controlbits on the TDM Group Management form to zero before performing the switchover and thenreturning them to their original value after the switchover. However, if the switchover is inresponse to calls failing, then the switchover should be undertaken without changing the flow con-trol bits.

As with the BAP, each FEP processor is composed of one or more processes, each of which hasa state. The possible FEP processor states are :

• UNKNOWN - Process not running or being booted

• INIT - Process initializing

• SYNC - Process ready to run

• RUNNING - Process running

• FAILED - Process reported an error (switch-over should occur)

At power up, the processes will go through the states shown in figure 10-2.

When considering a manual switch-over for a pair of redundant FEPs, use the same techniqueas for the BAPs and visualize two state transition diagrams next to each other - one which iscurrently in Master mode and Running state, and the other which is in Standby mode and Runningstate. A switchover is represented by the Master FEP moving from Master/Running toStandby/Sync and the Standby FEP moving from Standby/Running to Master/Sync. The Syncstate allows the processor to align its databases and then move to Running, when traffic handlingis resumed.

When a fault occurs, i.e. a forced switchover , the master will make the transition to idle and thestandby will make the transitions shown above.

When a FEP switchover occurs, some disruption is caused to the satellite side interface and, as aresult, a number of alarms are raised. The switchover process will take a few seconds and theISL link will go out of service. As a result, the TDM group(s) will be reset - this can be observedon the channel units. The ISL will automatically come back into service and, assuming DemandAssigned mode is not in operation, the TDM group will then come back up. The process is com-plete once the loop timing on the TDM group is re-established and can be confirmed when theRed LEDs on the MTMs are extinguished. When Demand Assigned mode is in operation theTDM Modulator will show an ’8’ on its status indicator.

The following is a typical list of the alarms which may be raised during FEP switchover, listed asthey would appear in the Alarm Summary Display , i.e. in reverse sequence.

TDM Group Release acknowledgedTDM Group Release from NCSRoute has become unavailable - this refers to the TDM GroupISL Link FailedExternal alarm port off - there can be several appearance of this alarmControl rack power supply failed


17th July 2001

10-10

4-s2

;2P

RC

FE

P T

ask

Sta

te C

ontr

ol

12 3 4

5

Unk

now

nIn

it

Syn

c

Run

ning

Fai

l

Mod

e C

hang

eE

ffect

edO

rR

esyn

ch

Figure 10-2. FEP Process State Control


10-11

Processor mode change - master before switchoverFEP switchoverProcessor mode change - standby before switchover

10.2.2 Telex and CU FEP Manually Controlled Switchover

The operator can manually force switchover of any pair of FEPs using the FEP Management form(SOC Forms - System Control). Note that FEP switchover involves clearing down of calls inprogress.

If for any reason the CPU card in the Switchover Tray has to be removed, or if it is faulty, it isnecessary to ensure that the asynchronous lines from the online FEP are correctly routed throughthe switches normally controlled by the CPU. This is done by a manual switch accessed from therear of the switchover tray - it is situated on the PSU+Relay card on the Arbiter Tray, to the left ofthe power supplies (looking from the back of the rack). There are two switches towards the rearlower part of the card : both should normally be in the centre position but can be moveddownwards to force the connection of FEP B. The one nearer the back of the rack controls the lefthand half of the switchover tray and the further one from the back of the rack controls the righthand half of the switchover tray. The default when the CPU is removed is that FEPA is connected,so there is no need to take any action in this case.

The switches should only be operated when the CPU has been removed, but do so as quickly aspossible.

Once the CPU is ready to be replaced, put both switches back into the central position just beforere-inserting the CPU.

10.2.3 Telex, CU FEP and DEMSA Failure

When a FEP (including the DEMSA) fails, switchover will take place to the standby unit and analarm will be raised. Failure can be due either to a software problem or to a failure in thehardware.

When a forced switchover takes place, calls set up through the FEP will be cleared down.

First of all check that the power supply to the affected unit has not failed.

The switch on the front of the Telex FEPs should be illuminated.

The light on the front of the CUC FEPs should be illuminated.

On the DEMSAs, the indication is a Hex display on the rear of the units - this should show achanging pattern. If any of these indications is not present, check the supply circuit breakers,remembering that more than one FEP can be connected to the same circuit breaker. If the supplyis working but the unit is still not operational, it will be necessary to call the DEC service engineer.

If the unit is powered up, the next step is to try restarting the software. For FEPs, turn the poweroff and then on again after 5 seconds; the software will then be automatically reloaded. Similarly,for the DEMSA disconnect the power by removing the mains lead to the rear of the unit and recon-nect it.

If the unit fails to restart, call the DEC service engineer. If the fault is in one of the FEPs, advisethe engineer that the FEPs do not have any hard disk and that he should bring the appropriatediagnostic tools.

There are two types of FEP in common usage, the method for connection of a monitor depending


17th July 2001

10-12

on the type installed.

• CK-KA630-A distribution panel Rear 9 pin connection with 2 pole switch and tworotary controls

• Internal KA630CNF configuration board. Accessed by removing rear blanking panelsand seen at the top of the CPU card as a small plug in daughter board with a 10 poleDIP switch. A ten way ribbon cable terminated by a rectangular plug is required toconnect the monitor to this board.

A monitor (e.g. DEC VT320) can be connected to a FEP for diagnostic use

The interactive mode should not be used in normal operation of the equipment, but may be re-quired for fault finding. HNS will give specific instructions in such cases. When a monitor set tointeractive mode is powered up, the operator may need to select the language to be used at aprompt which appears on the monitor.

If both DEMSAs have been shut down (e.g. during a power failure) then once they have beenpowered back up the DEMSA tables must be recreated. To do this log in to the BAP and enter:

$ @SAD$EXE:SAD_UPDATE_DEMSA_FILE

This must be run before the BAPs are switched or restarted.

10.2.4 Recommended Dip Switch Settings for On-site FEPs

These settings are valid for FEP Model RTVax KA620-A with a KA630CNF Configuration board(console card) attached. For models with the rear controls and connector select the appropriatebaud rate for the terminal and connect using an appropriate cable.

There is a DIP switch on the KA630CNF daughter board which is used to select either interactiveor non-interactive use of the monitor. The normal settings, are shown in Appendix A.

The settings of the switches are as follows:

Switch Normal Interactive Function

1 Off (Up) Off (Up) Halt Disabled2 On (Down) On (Down) Console Port Baud Rate=96003 Off (Up) Off (Up) Console Port Baud Rate=96004 On (Down) On (Down) Console Port Baud Rate=96005 Off (Up) Off (Up) No language inquiry, no loopback tests6 Off (Up) Off (Up) No language inquiry, no loopback tests7 Off (Up) Off (Up) CPU arbitrates Q22 Bus interrupts e.g. DHQ118 Off (Up) Off (Up) CPU arbitrates Q22 Bus interrupts e.g. DHQ119 Off (Up) On (Down) Console enable if on10 Off (Up) Off (Up) If terminal connected, then terminal receive

If the interactive settings are used, the FEP will not automatically restart after power up.Do not leave these settings in place once the monitor has been removed.

[opga10_DIP]


10-13

10.2.5 DEMSA Management

The DEMSA Management form (SOC Forms - System Control) shows the condition of the X.25DEMSAs. For each it shows :

• S : enter a ’Y’ in this column to activate the soft key commands.Switch

• DEMSA Pair Name : as configured when the system is set up

• DEMSA Name : as configured when the system is set up

• Mode : master, standby or idle

• Current state : OUT (out of service), INS (in service) or FAI (failed)

• Desired service state : OUT (out of service) or INS (in service)

• Interface status : up or down.

To manually change state, enter ’Y’ in the left-hand column beside the name of either of the twoDEMSAs and press .Switch

To modify the service states, press to view the current status, then press . EnterShow modifythe desired state in the ’Desired service state’ column and press .Enter

If a DEMSA is in the Failed state, press , set the desired state to INS and press .modify enterThis operation must be performed manually by the operator.

Use this form to perform a manual switchover of the DEMSAs once a week to ensure that thestandby DEMSA is operational.

Note: it is possible to place the X25 Line to the MNT state, using the X25 Line Management form(SOC Forms - Terrestrial Interfaces). If a new or repaired DEMSA is added to the system, thisshould be introduced as Standby to a DEMSA which is already operating as Master. It should befirstly marked Out of Service on the DEMSA Management SOC form. When the DEMSA ispowered ON it requests a download of the "Router 2000" software (part of VAXPSI) from its Hostnode (one of the BAPs). As it takes on average 3 minutes for this software to load and startup, theStandby DEMSA should not be marked as In Service until it has been powered up for at least 3minutes. This is necessary to ensure that there will be no problem switching DEMSAs so thisadded DEMSA can become Master and be in a position to pass traffic.

Note: the X.25 software in the ACSE only polls DEMSAs that are marked as In Service, and onlypasses traffic to the Master DEMSA. The downloading of the "Router 2000" software is not underthe control the the ACSE X.25 application software, rather it is a function of the proprietaryVAXPSI software, which does not indicate when the download is complete. Therefore it is neces-sary to allow sufficient time for the Standby DEMSA to start up before setting it to be In Service byoperator command.

10.3 System Management

10.3.1 Security of Software

The operating software is held in the hard disks used by the processors and will normally continueto operate without any problems. Configuration data, also held on hard disk, is continually up-


17th July 2001

10-14

dated to contain the latest log files and the latest configuration.

As with any processing system, it is possible for the contents of the hard disks to become cor-rupted. For this reason, a secure copy of the application software should be maintained andregular backups taken of the configuration data.

The HNS installation team will leave, on tape, an Image Backup of the system disk and a dump ofthe database. These need to be kept current. If any Emergency Bug Fixes (EBFs) are applied tothe software, these must be retained at least until a new system disk dump is made.

The Image Backup is a complete copy of the system disk. It can be used to reload the systemdisk without going through the steps of loading the operating system, the DEC layered productsand the application software. Image backups are described in chapter eight of the VMS SystemManager’s Manual, published by DEC, order number AA-LA00A-TE, for VMS V5.0.

10.3.2 Operational Recovery from Disk Failure

If there is a hard failure of a disk which requires full reload, the following cases must be con-sidered.

• If there is a failure of one of the shadow disks, once the repair is made, adding thedisk back into the shadow set will restore the data on this disk, but this process willtake some time.

When a shadow-set member which was taken offline comes back on-line it performsa complete disk copy, as a background task. The catchup time for a disk to becomea full member of the shadow-set on RF71 disks has been measured at about 45minutes, but it depends on the actual volume of data to be copied.

The operator should be aware that during this recovery time, the system is effectivelystill in non-redundant mode.

• If both shadow disks fail, a most unlikely prospect since this is a dual failure, all cur-rent data will be lost. However, once a disk is repaired, the database can be reloadedfrom tape, using the latest dump, and the system can be restarted. There will be noway to replace the lost data.

• If a system disk is lost and the repair has been made, this disk can be reloaded bytaking loading the image backup tape followed by installing any EBFs that have beenreceived from HNSL since the last backup.

10.3.3 Security of Online Configuration Data

The configuration data required by the system is extensive and therefore means are provided toback it up and reload the backup. The configuration data covers a wide variety of user con-figurable parameters, from the hardware set up to the mobile lists.

Much of the configuration data will only change rarely, for instance the configuration of channelunit hardware will remain fixed for months or years. Other data is more dynamic; principally themobile list and the registered user list. Note that there is no data related to individual messages inthis configuration data.

Therefore, it is recommended that the archiving process should be performed at least once aweek as a regular function. In addition, a backup should be made if there is a significant changeto the registered user data base. Changes to the mobile list are anticipated to occur at a uniformrate.


10-15

Any updates to the mobile list and the registered user database which occurred between the timeof the archive was created and the time it is loaded must be entered manually. To archive thedatabase configuration, use Archive Database Configuration (SOC Viewer - Online Processing -Database Management). This process will take some time, typically 10 to 20 minutes. The SOCcan be used for other functions during this time and the window can be hidden but it should not bedeleted. A message will appear in the window when the operation is complete. The operatorshould then transfer this to tape using Copy Archive to Tape (SOC Viewer - Online Processing -Database Management - Copy Archive to Tape). The DAT cartridge drive (integral to the BAP) isrecommended for this archive in preference to the TU81 tape drive, but note that the some of thelater modern configurations have a TLZ06 cassette tape and a TSZ07 half inch tape.

This archive would only be used in case of a complete failure of both the disks in the shadow set.Assuming the software is running, to restore the database configuration, use Copy Archive fromTape (SOC Viewer - Online Processing - Database Management - Copy Archive From Tape). Thistransfers the archive to disk. Then load the configuration data in the individual files using RestoreDatabase Configuration (SOC Viewer - Online Processing - Database Management - RestoreDatabase Configuration). This process will take some time, but is faster than the archiving opera-tion. A message will appear in the window when the operation is complete.

Additional commands are provided in SOC Viewer - Online Processing - Database Managementto obtain a directory of archives on disk and to delete archives from the disk.

It is not necessary, or indeed useful, to retain these archive tapes for any length of time. However,to guard against failure during the transfer to tape, it is recommended that two sets of archivetapes be kept and that each is used alternately.

10.3.4 Online System Checks

This section describes the regular checks which must be performed to ensure that the equipmentprovides a satisfactory grade of service.

The operator must regularly ensure that the system is performing correctly and that sufficientmemory is available for the system to function correctly. These checks should be built in to thedaily routine of the operating staff.

The checks to be performed are :

• Ensure that messages are passing through the system , i.e. observing that thetraffic levels as monitored on the System Usage Display (the default display) goes upand down with time. It is good practice for all staff to keep an eye on this displaywhenever possible.

• Ensure that there is a recent copy of the system software held on tape . Anynew software releases must be retained on tape. In addition, a VMS backup of thesystem disk should made at least once every three emergency bug fixes applied.

• Regularly backup configuration databases. The configuration databases in thesystem, particularly the mobile list and the registered user database should beregularly backed-up so that in the event of a catastrophic failure of the disks, they canbe reloaded and the system restarted. These backups should be made once everytwo weeks. Details are shown in section 10.3.3.

• Regularly archive log files. The system can accumulate data at a fast rate; both theevent log and the call record log should be cleared on a daily basis to ensure thatsufficient memory is available for new data. Files are transferred to tape, from whichthey can be read for post-processing either to produce the data for the billing centre


17th July 2001

10-16

or for analysis of the event log (see section 14.6).

• Regularly check the offline database usage . Do not collect too many log files, alsoregularly delete unwanted files. The mechanism is described in section 14.11.

• Check for stuck messages. Regularly, e.g. daily, check for messages which arestuck on the satellite side, as described in section 8.2.7

• Check the Hardware as described in the Channel Unit Maintenance Manual,Reference [3].

• Switch DEMSAs once a week to ensure that the standby DEMSA is operational. Atpresent, there is no check on the standby machine. By regularly performing aswitchover, this will ensure that the standby is always available in case the onlinemachine fails. If when this regular switchover is performed, the previously standbyDEMSA is not operational, the system will automatically switch back to the workingDEMSA. If this is the case investigate and arrange for repair to the standby DEMSA.Use the DEMSA Management SOC form to perform the switchover.

10.3.5 VMS security

Access to the facilities provided by the DEC computer system is controlled by the designated sys-tem manager, who controls accounts, privileges, passwords and quotas using the appropriateVMS commands, as documented in the DEC System Manager documentation.

Access to the DEC computers is normally via the SOC workstation, although this access is usuallyrestricted to the SOC and SOC Viewer facilities. From the window used to start up the SOCapplication it is also possible to log into any intelligent device on the Ethernet, providing access isgranted. In general it is possible to do this by creating a window on the SOC, logging into one ofthe non captive SOC accounts, usually SOCSYS, followed by exercising the VMS command SETHOST <node name>. Access can also be attained from the VMS consoles.

Further restriction as to which of the SOC commands are available for a given operator is madeusing the forms available from (SOC Forms - Operator). Access to the system as a whole, ratherthan the specific ACSE operator facilities, can be made using the VMS command set, providing anaccount is set up for the user to use.

Outside access to the DEC computer system, other than for ACSE specific functions, can bemade via X.25. However, restriction to specified authorised users, e.g. HNS Ltd. for remote sup-port purposes, is controlled by modifying and running the latest version of the file:

CES nnnn> @SYS$MANAGER:PSI_Security.COM

This is generally done on project installation, under the control of HNS Ltd. engineers. Also, referto Section 10.11.

10.4 Alarms and Events

10.4.1 Definitions

The two terms alarms and events need to be carefully distinguished.

An event is an occurrence in the system which must be recorded. Some events require to bebrought to the attention of the operator and are therefore classed as alarms , until they are ac-knowledged by the operator. After that, information on them can only be found by examining theevent database.


10-17

So all alarms are also events but the reverse is not always true. Also alarms have only a transientexistence but events are preserved.

It is good operational practice to run the system with no alarm indications showing on the sum-mary alarm display on the SOC. At least once a day, all unacknowledged alarms should be inves-tigated and acknowledged.

When an event occurs in the system, it is analysed according to preset criteria and, if appropriate,an alarm is raised. The alarm is classified and this class is shown in the visual indication on thesummary alarm panel on the channel unit racks and, in more detail, in the banner area on theSOC screen. The indication on the channel unit rack can be connected to the earth station alarmcollection system.

There are SOC forms to display unacknowledged alarms and also to display, in summary and indetail, the event log.

Events can be printed out on the event printer. The operator can select which types of event areto be printed, but note that an event is printed both when it occurs and when it is acknowledged.

10.4.2 Notification of Alarms

Alarms will cause the buzzer on the channel unit rack to sound -

• continuous for distress, urgent alarms

• intermittently for semi-urgent and minor alarms

Alarms also may be repeated by the earth station alarm system and a visual indication is given onthe SOC screen.

Reset the buzzer by either :

• pressing the reset button on the front of the channel unit rack

• select the Alarm Summary Display form (SOC Forms - System Control) and press.Reset Audbl

10.4.3 Summary Display on the SOC

This shows unacknowledged alarms for various parts of the system and the level (of importance)of the alarm.

The top two lines are reserved exclusively for Distress messages - the top bar indicates un-delivered messages and the lower bar a distress message currently in the system.

The remaining three lines are in the form of a matrix with the level of the alarm :

• Urgent : potential loss of traffic

• Semi urgent : loss of redundant equipment

• Minor : other alarms or events which must be brought to the operator’s attention

and the class of the alarm on the horizontal axis

• BAP for those relating to the software or hardware in the Background Processors.


17th July 2001

10-18

Note that this covers only those alarms detected by the application software and notby the DEC software, such as the operating system.

• FEP for alarms in any of the Front End Processors. Again only those alarms detectedby the application software, not the DEC software, are detected.

• ARB for failures in the Arbiter module

• TLX for external failures in the telex circuits, such as a telex line going out of service.

• X25 for failures in the PSDN circuits.

• CU for failures in any of the channel unit racks, such as modulators, demodulators,etc. This does not cover external failures on the satellite side, except for those faultswhose source is not easy to pinpoint.

• SOC for failure indications from any of the workstations used for the MMI. This wouldalso be used if the operator was expected to attend to an event, such as the receipt ofa message to the LES operator from a mobile.

• NET for external failures in the satellite network, other than in the ISL link to the NCS.

• X400 for external failures in the X400 network. This is not currently used.

• Other for any other entities, e.g. FAX PC.

Note that some of these classes, e.g. X400, correspond to facilities which are not provided insome installations. Alarms in these categories will not be reported.

When the box is blank, no alarm condition exists. When an alarm occurs, the appropriate boxshows red. Once all alarms for that class and level have been acknowledged, the box returns toblank. Any subsequent alarm causes the box to change to red again.

It is important to remember that the summary alarm screen is also used to report events to theoperator. For instance, if a mobile wants to send a message to the LES, it can use the SpecialAccess code 33. When the message is received at the ACSE, it is routed to the event log and aMinor alarm raised under the SOC class. The SOC Viewer is then used to read the contents ofthe message which has been received.

The summary alarm display will continue to show red against the appropriate alarm until it is ac-knowledged. This should be done when the operator has, or is about to, deal with the problem.Keep the alarm indication on the SOC as a reminder that it must be handled but remember that aslong as the indication is there, any new alarms of the same classification will only be shown on themessage line, just below the alarm indication matrix, and by sounding the buzzer.

The operator should acknowledge alarms when he is satisfied that the cause is understood or hasdecided that there is no further need to keep this record of the fault. The information is in anycase retained in the event log.

10.4.4 Alarm Summary Display

When an alarm has occurred, it will be displayed on the message line and an indication will begiven on the summary alarm display. Once another event occurs, it will replace the message onthe message line. To view all reported alarms, use the Alarm Summary Display (SOC Forms -System Control).


10-19

The event class and alarm level can be specified to investigate a particular area or left blank tosee all alarms. The class - BAP, FEP, etc - are entered in the form that appears above the redalarm indicators on the screen. The alarm level is entered in the form :

• undel_distress

• distress

• urgent

• semi_urgent

• minor

Note: There is a level of events, info_only, but these should never appear in alarm displays.

Select the form and press for the following details. Use for the previousFirst Page Next Pagepage of alarms.

• sel - select for acknowledgement, see below

• time reported

• event class

• alarm level

• description - plain text, as appeared on the message line

• object - provides added information concerning the alarm

• seq num - event sequence number

To reset the buzzer, press at any time.Reset Audbl

The plain textual description is explained in Chapter 11.

Alarms can be acknowledged in either of two ways - bulk or individual.

To acknowledge all the alarms on the display, press .Bulk Ack

To acknowledge an individual alarm, select the alarm by a Y in the left hand column and press. This brings up the Alarm Management form which shows more details of the event. TheMan

operator can enter a comment on this form if it is useful for future fault analysis. To acknowledgethe alarm, press .Ack

There is a limit of 100 of the number of alarms which can be held in the system. If this limit isreached, the system will automatically acknowledge them. Details can then only be found bysearching the event displays. Auto-acknowledgement is performed on the oldest, least significantalarms first. The order of auto-acknowledgement is that all the alarms of one priority are clearedbefore any of the next highest priority. Therefore, if there a number of minor alarms, for example,all these will be acknowledged in preference to alarms of higher category. Similarly, if there are100 urgent and semi-urgent alarms in the system, and a minor alarm occurs, the minor alarmwould be immediately acknowledged.


17th July 2001

10-20

10.4.5 Event Displays

As well as the database, which holds information concerning the 100 most recent alarms, andwhich is used for the alarm displays, there are log files which hold information about all the eventsraised, both the events which are also alarms, i.e. of minor severity and above, and those whichare not, i.e. of information severity. Events entries can be interrogated for as long as log files arepresent in the on-line system. The process whereby log files are archived and deleted from theon-line system is described in Chapter 14.

The Event Summary Display (SOC Forms - System Control) allows access to this event infor-mation and provides a means for the operator to analyse the contents of the log. The operatormust specify the time from which the search is to be made (default is current time) and the numberof hours before that time (at least 1) to which the search is to be made.

Event Class, Alarm Level, Reporting Component and Event Sequence Number can also bespecified if selection is required on this basis, although it must be noted that the process of scan-ning the database for the required records can take a long time, perhaps of the order of minutes,in such cases. The Working indication will flash on the bottom left of the window while the infor-mation is being gathered.

Events are generated whenever the operator accesses a SOC form, unless this has beensupressed using Event Definition from the SOC Viewer. The operator may further specifywhether or not such events are shown in the Event Summary Display .

The order in which events appear corresponds to the order the details of the event are placed inthe event log. If the event is later on acknowledged as an alarm, an further entry will be placed inthe event log around the time the event was acknowledged. Thus the event will appear twice inthe display, although the time shown in the display will be the time raised, in both cases. Eventswill appear in the order there is an entry in the event log, with the most recent entry being shownfirst.

A page of events contains 8 events. Use the and to scroll through theNext Page Prev Pageevents.

The form’s selection criteria can be broken into two parts. The first group - Latest Time Reportedand Hours To Search - control where in the log to search and how long to search.

The second group (if used) - Event Class, Alarm Level, Reporting Component and EventSequence Number control which events are to be returned to the operator.

As an example of how best to use this display consider the following scenario: the system has logfiles for one week on it - this is approximately 168 log files. Today is Sunday. A BAP switchovertook place on Tuesday at 10 AM. The operator wishes to see urgent PRC events that happenedaround switch over. This can be done in two ways:

1. Select Reporting Component - PRC and Alarm Level - Urgent and then .first pageThe software would then search through all the log files for PRC Urgent events, per-haps taking several minutes to do so.

2. Alternatively, set Last Time Reported to 11 o’clock on Tuesday morning, Hours tosearch to 2, Reporting component to PRC and Alarm Level to Urgent. This wouldgive direct access to the log file of interest and then limit the search window to 2hours. The information should be displayed within a matter of seconds when thisselection is used.

Thus the hours to search can be used by itself to limit a search to a previous number of hours.


10-21

This is useful if the events you are interested in all occurred in the last n hours. The key to obtain-ing a quick response is not to use the second group of selection criteria without using the first.

The information provided in the display is as follows and in the following order, and should enablethe operator to understand what has caused the event, to distinguish one event from another andto separate cause and effect:

1. Acknowledge : identifies whether or not the event is an alarm which has previouslybeen acknowledged by the operator.

2. Time : shows the time the event is reported in the format:Day-Month-Year Hours:Minutes:Seconds (to 2 decimal places)

3. Event class : is used to locate the area of the system to which the event relates, asshown in the SOC banner summary alarm display. The event classes are as listedin section 10.4.3

4. Alarm level : (Severity on the Event Printer) shows the alarm indication for thisevent, if any. The following categories exist, in order of severity:

• UD : Undelivered distress - failure to deliver a distress message.

• D : Distress - receipt of a distress message.

• U : Urgent - major loss of traffic or degradation of the system.

• SU : Semi-urgent - minor loss of traffic or loss of redundant equipment.

• M : Minor - other minor failure, or recovery/new availability indication.

• I : Information only - may be logged and printed but gives no alarm indication.

5. Description : is the textual description of the event. There is a one to one correlationbetween the description text and the text for the corresponding group and eventnumber in Section 11.2.

6. Object : (Affected Object on the Event Printer) can usually be ignored as the infor-mation is displayed in a more digestible form under Supporting Data in the EventFull Display , shown below. (The same applies for Object Units in the Event FullDisplay .

7. Sequence Number : uniquely identifies the event within the system and can be usedto relate the information about a single event which appears on the this and the cor-responding full display and also that on the event printer. The numbers used arerecycled after 99999.

Note: in the corresponding output on the event printer there appears Processor field. This in-dicates which BAP reported the event - BAPA or BAPB, except in the case of events relating tothe satellite interface, where this column shows the Ocean Region to which the event relates.

To obtain further details for a particular event in one of the pages of the Event Summary Display ,place a Y in the select column, situated at the far left of the display, at the position the columnintersects the row which containing details of the event of interest, and press . This will resultFullin a screen which provides the associated Event Full Display .


17th July 2001

10-22

In addition to the information which has already been seen in the Summary display, the followingadditional information is to be found in the Full display:

1. Object units : see under Objects for the corresponding Summary display.

2. Reporting Component : (Group on the Event Printer) contains the name of thesoftware component which generated the event - see section 11.1 for a full list.(Along with the Event Number , this provides a unique reference to the nature of theevent).

3. Event Number : is a number in a group which indicates the nature of the event, seeSection 11.2.

4. System Action : shows what the system or the operator needs to do to recover fromthe fault. This is a short text field.

5. Supporting Data : provides additional details of the event. Relevant status infor-mation, collected at the time of the event, is usually displayed. See Section 11.2 foran explanation of the data provided, for the Reporting Component and EventNumber to which the event refers.

6. Printed : indicates whether or not the details for that event has been sent to theEvent Printer.

7. Acking Operator : (alarmable events only) is reserved for future use.

8. Time acked : (alarmable events only) is the time the operator acknowledged thatevent.

9. Comment : (alarmable events only) is the comment added (if any), by the operator,when the event was acknowledged

10.4.6 Action on Receipt of Distress Alarms

The operator should give highest priority to attending to any alarm classified as Distress orUndelivered Distress.

The prompt alarm buzzer will sound when a distress call is received in the system and visualindications will be given on the SOC screen and on the ASM on the Channel Unit Rack. Themessage itself is written to the event log and printed on the alarm printer.

Once all delivery attempts have been completed, a positive or negative delivery notification is writ-ten to the distress log and copied to the alarm printer.

The alarm level for distress alert/message related events will be normally be Distress, although incases where a delivery has been attempted, but failed, the alarm level will be UndeliveredDistress.

The contents of the distress alert/message can be viewed in the Distress Message LogfileReport , from SOC Viewer, as described in section 13.2, or the Distress Message SummaryDisplay from the SOC.

Once the operator is ready to attend to the distress call, reset the buzzer.

Then find out the state of the distress call - i.e. delivered or not delivered. This is indicated on theSOC screen.


10-23

If the message has been successfully delivered, it is unlikely that further action is required.Ensure that the message details have been printed on the event printer and acknowledge thealarm.

If a message has not been successfully delivered, it may be necessary to manually attemptdelivery. For mobile originated messages, direct contact should be made by telephone with theMRCC. For messages to mobiles, manual delivery to another LES may be necessary. See localinstructions for details.

10.4.7 Action on Receipt of Land Alert Events

Land Alerts are not considered as being at a distress priority and are not automatically alarmable.The implication is that there is normally no need for operator action. However, there are a numberof events associated with Land Alerts, and these are similar in form to those for distressalerts/messages.

With Land Alerts, similar text is included in the event as for the corresponding event for distressalerts/messages, including the word DISTRESS in the title DISTRESS DELIVERY RECORD, al-though subsequent text will state LAND MOBILE ORIGINATED ALERT.

10.4.8 Action on Occurrence of other Alarms

When an alarm occurs, the recommended procedure is as follows :

1. Reset the audible alarm by operating the button on the CU rack or by using theSOC.

2. Acknowledge the alarm on the SOC using the Alarm Summary Display . At thisstage, the operator has the opportunity to record, for future reference, commentsconcerning the fault by selecting the Alarm Management Display .

Note: after a pre-determined number of alarms are in the system without being ac-knowledged, these will be auto-acknowledged and a comment to that effect added.

3. Read the event message to determine the details

4. Use the Event Summary Display and Event Full Display to investigate theproblem and initiate the appropriate corrective. Section 11 explains the event dis-play.

5. Add any necessary comment to the event indication to record the recovery action

10.4.9 Event Management

Events are internally identified by a number of mnemonics. The operator can see what is set upusing the Event Definition (SOC Viewer - Online Processing - Database Access - User Services).This access can be used to change the information printed against events and also the classifica-tion of events, but note the warnings given against some of the fields below.

• event class - the grouping under which it appears on the banner area of the SOCscreen. It is recommended that HNS are consulted before this categorization ischanged.

• event severity - undelivered_distress, distress, urgent, semi_urgent, minor, info_only.It is recommended that HNS are consulted before this categorization is changed,since the operational procedures rely on the delivered settings of this field. See also


17th July 2001

10-24

the note below.

• description - the message which appears on the event line on the SOC

• supporting data format. Any non-English entries in this should not be changed asthey are used by the software. Please consult HNS before making changes to thisfield.

• logging enabled - TRUE or FALSE to make a permanent record on the event log

• printing enabled - TRUE or FALSE to print on the alarm printer

• system action - a free field to enter any actions which the operator should take. Thisfield is limited to 20 characters and is left blank by HNS, except for certain importantevents such as Distress.

Note that the event class is allocated on the following basis :

• Undelivered distress and distress are reserved for maritime distress alerts and mes-sages. It is important that these classifications are not changed.

• Urgent is used for any fault which can stop traffic handling, or has the potential to stoptraffic handling. This level indicates that the operator should take action as soon aspossible.

• Semi-urgent is used for any fault which can wait to be fixed. For example, faultswhich do not have to be fixed until specialized staff come on duty.

• Minor events are ones which should be noted and action only taken if they occurrepeatedly.

• Information only require no action to be taken for that specific event

10.4.10 Alarm (or Event) Printer

Note: Providing printing is enabled for at least one of the Alarm Printers, and the printer is opera-tional, all events generated will be output to the printer, both alarmable and non-alarmable events.

The current state - on line or off line - of each alarm printer can be viewed on the Alarm PrinterManagement form (SOC Viewer - Online Processing - Alarm Printer Management). This formallows the operator to control the print queues, as shown on the menu tree.

If a printer runs out of paper, it will automatically be changed to offline. Replace the paper anduse this form to put the printer back online.

Similarly, if the power is turned off to the printer for any reason, it will not recover automatically .An alarm will be raised on the SOC. When the power is restored, use this form to put the printerback on line.

When bringing a printer back online, the operator has two options - print from the current event orprint all missing events.

Normally the printer would not be placed offline. However, this action may be useful in excep-tional circumstances, for instance if a fault was causing repetitive alarms and it was desired tostop printing of these alarms.


10-25

10.5 Report Printer

Normally no action is required for the Report Printer other than to check that the paper is correctlyset in the printer and when low more paper is added. If the printer does run out of paper it may benecessary to re-start the print queue from the Master BAP VMS account:

CES nnnn> START/QUEUE REPORT$PRINTER

10.6 Other Status Indications in the System

There are a number of other indications of status in the system which can be used to check thatthe equipment is performing correctly or to assist in fault finding.

On the channel units there are LEDs to indicate the mode in which the channel unit is configuredand there is a status display. LEDs indicate the following

• ISL Modulator

• TDM Modulator

• ISL Demodulator

• TDM Demodulator

• Message Demodulator

• Signalling Demodulator

• Test

• Transmit Active - applies to modulators only

• Demodulator lock

• Alarm

Below these there is a Hex display which indicates a variety of conditions as detailed in theChannel Unit O&M Manual, Reference [3]. The normal indications are :

ISL Modulator E

TDM Modulator E

ISL Demodulator C, changing to D when a packet is received

TDM Demodulator E, with the Demod Lock LED flashing everyTDM frame (every 8.64 seconds)

Message Demodulator A, changing to C when a message is received.The Demod Lock LED is also illuminated duringthe time the message is received.

Signalling Demodulator B, changing to D when a packet is received.The Demod Lock LED is illuminated all the time.

Standby unit 8, indicating available to be switched in service


17th July 2001

10-26

to replace a failure. No mode LED illuminated

Ready 9, with no mode LED illuminated.When first powered up and before initialization.

Listing the above table in display code order, the status is :

Code Modulator Demodulator

0 Startup Startup8 Function disabled Function disabled9 Ready for initialisation Ready for initialisationA Carrier acquisitionB Unique word missedC Carrier lock (MSG and TDM)

Collision detected (SIG)D Burst detected (SIG)

Normal data enabled (TDM)E Normal Normal data ignored (TDM)

Note that if a channel unit is reconfigured from the SOC so that it is taken Out of Service, themode previously set will remain displayed on the channel unit. For example, if ’8’ was displayedand the unit is taken out of the sparing pool, the display will remain at ’8’. However the software isunable to allocate the channel unit.

On the ASM Modules , there is a repetition of the summary alarm status - Distress, urgent, semi-urgent and minor - together with an indication if communication with the BAP has failed (SCP LineFail). There is also an indication of which MTM is online.

On the MTM modules , there are two LEDs.

• TDM frame active - indicates that the MTM is generating the frame start signal. Notethat it is illuminated even when no TDMs are active, e.g. during demand assignment.

• summary alarm indication for rack timing - indicates when no frame start signal isreceived from the TDM Demodulator. If demand assignment mode is in operationand the primary TDM group is not operational, this LED will be illuminated, but noaction need be taken.

On the Channel unit rack power supplies there is a green LED for power on and a red LED forfaults.

On the BIMs on the rear of each channel unit chassis, there are three LEDs:

Online Green BIM online for distribution of timing- corresponds to the online MTM.The offline BIM still carries the multidroplink from the CUC FEP to the CUs

TDM Frame active Orange TDM timing receivedSummary alarm Red Repeats summary alarm on the MTMs

On the Arbiter and Switchover trays there is a series of indications as follows :

Arbiter card in position A5A0 on CUC rack


10-27

LES Indication

CAP0 Flashing - comms failure to BAP A or suspension of polling from BAP ACAP1 Flashing - comms failure to BAP B or suspension of polling from BAP BCAP2 Flashing - comms failure on BAP port which controls DEMSA switchCAP3 Flashing - Online BAP selected manually by switch on front of ArbiterA:1-8 ON - BAP A master, OFF - BAP B masterA:9-16 ON - DEMSA A master, OFF - DEMSA B master

CUC switch controller in position A4A0 in CUC rack

CAP0 Flashing - comms failure on link to BAP.CAP1 Not usedCAP2 Not usedCAP3 Not usedA:1-8 ON - CUC 1A master, OFF - CUC 1B masterA:9-16 ON - CUC 2A master, OFF - CUC 2B master

Telex switch controller in position A6A0 in TIF rack

CAP0 Flashing - comms failure on link 1 to BAP.CAP1 Flashing - comms failure on link 2 to BAP.CAP2 Not usedCAP3 Not usedA:1-8 ON - Telex FEP 1A master, OFF - Telex FEP 1B masterA:9-16 ON - Telex FEP 2A master, OFF - Telex FEP 2B master

On the Switchover tray power supplies there is a green neon to show that power is on. Thereare also six red LEDs on the PSU and Relay card, to the left of the left power supply. The LEDsare lit if there is a failure in any of the three outputs from each of the two supplies; It is important toensure that none of them are lit.

Three of the LEDs are immediately behind the black connector on the PSU and Relay card andare not directly visible. If any of these are lit, PSU ’A’ is faulty, i.e. the right hand PSU whenlooking at the back of the rack. The other three LEDs are at the other side of the card and indicatea failure in one of the outputs of PSU ’B’. The CUC and TIF rack manual contains further detailsof these indications and describes how to replace a suspect power supply. The switchover traycan still continue to function if one of these PSUs has failed.

On the DEC FEPs, the power switch is illuminated when power is on.

10.7 Reporting Faults

When a fault has occurred affecting either hardware or software it will be initially investigated bythe customer site staff. If it is a problem which requires HNS support (as opposed to other supporte.g. DEC service engineers) then the procedures for reporting problems to HNS must be followed.

This Customer Service Problem Report has been designed to convey this information. Fill inone of these forms for each event or failure and use continuation sheets if necessary. It may alsooften help if associated alarm printer outputs are attached.

Appendix F gives details of the form, how to fill it in and the procedures involved.


17th July 2001

10-28

10.8 Test Message Functions

A number of functions are built into the system for test purposes. The terrestrial interface formsinclude means of nominating a test circuit.

Note that the system will handle one call at a time as a test call. If a multi-address test call ismade, only the first address is treated as ’test’.

In a similar way, a mobile can be nominated as a ’test’ mobile. When this happens, any messageto or from the mobile is flagged in the system and traced. The operator is able to follow theprogress of this message. Only one mobile can be identified as ’test’ at any time.

The result of a circuit or mobile being nominated as ’test’ is that whenever a message originatesfrom or is destined to this circuit/mobile extra events are generated.

To identify a mobile as test, select the Test Mobile Definition form (SOC Forms - User Services- Mobile Users) and press . This will give the mobile number of the currently defined testShowmobile. To change it, press , enter the new number and press .Modify Enter

A Telex circuit can be designated as a test circuit using the Telex Trunk Management form (SOCForms - Terrestrial Interfaces - Telex).

Note that the factory default setting for the test mobile is 400000000, and this equates to nomobile. In order to designate a mobile to be a test mobile this must be modified to the appropriatemobile number. When no longer required the value should revert to 400000000.

10.9 ACSE Identifier

At the top of the SOC display, the ACSE is identified. This is configured using the ACSE IDDefinition (SOC Viewer - Online Processing - Database Access - User Services). The field can beup to 30 characters long.

10.10 The Operator as a PSDN subscriber

The operator can access the system as a PSDN subscriber. The principal uses of this access are:

• download of DNIDs and ENIDs to mobiles

• generation of responses to ’code 33’ messages from mobiles to the operator

• generation of test messages to mobiles

• inspection of data report files to assist in solving problems which users may have.

• loopback of messages from mobiles to the LES - this is of principal benefit duringtesting.

• simulating problems which users might encounter.

For test uses, the operator should be registered on the system with his own PIN. All servicesshould be enabled to the operator with the possible exception of distress related functions.

The operator is specifically identified as a privileged user and may be set up to be the only regis-tered user able to download group identities - ENIDs and DNIDs.


10-29

The operator, by virtue of his privileged position, can enter the PIN of any registered user. Thismethod is of use in investigating problems reported by users. A terrestrial users identity shouldnot be used for any transactions which generate call records and charges unless arrange-ments are made to credit the user.

Access is achieved through SOC Viewer on the online BAP using X25 Access (SOC Viewer -Online Processing - X25 Access). Using this form takes the operator straight to the PIN promptwhich greets a registered user accessing the system. The operator should then engage in exactlythe same dialogue as any terrestrial user and can therefore follow the instructions published forsuch users.

10.11 Access by HNS for Fault Investigation

HNS is able to access the ACSE for fault investigation. This is particularly valuable in ascertainingthe cause of software or database problems.

Access will only be made by arrangement with, and with the permission of, the staff at theLES.

The access is achieved by setting up a connection over the X25 interface, using a special sub-address which bypasses the normal PSDN user interface, to establish a direct connection with theVMS operating system. This form of access can be enabled and disabled by the ACSE operator.

There are three command files which can be used to set the security level for PSI access to VMSfrom remote machines. The command files are run by entering the appropriate file name shownbelow, from the VMS SYSTEM account, on the Operating System Consoles for both the Masterand Standby BAPs.

Three levels of security are available. This and the commands files to set them are as follows:

1. Stop all X25 calls to VMS

CES nnnn> @SYS$MANAGER:PSI_STOP_CALLS.COM

2. Stop all X25 call to VMS with exception of calls from HNS UK :

CES nnnn> @SYS$MANAGER:PSI_STOP_CALLS_BUT_HNS.COM

3. Allow every one to be able to login to VMS :

CES nnnn> @SYS$MANAGER:PSI_ALLOW_ALL_CALLS.COM

4. To set the site specific X25 access:

CES nnnn> @SYS$MANAGER:PSI_SECURITY.COM

The security level may be changed at any time by running the appropriate command file stan-dalone.

If HNS engineers are on-site, it is recommended that the security level is set to 2 above.

When on-site support is completed, the access level should be set to 1 above. Access by HNS willthen be made available when required by request to the operations staff at the site who will beresponsible for running the necessary command file to allow temporary access and for closing theaccess down when it is no longer required.


17th July 2001

10-30

The cooperation of staff on site to set the appropriate security level will be much appreciated byHNS staff at Milton Keynes investigating problems.

[opg10.mss]

A4-OPG-003076 Event MessagesIssue 3.23 - Accepted17th July 2001

11-1

Chapter 11

EVENT MESSAGES

11.1 Introduction

This chapter describes the details which are given when events are reported. Events are visible tothe operator by a combination of indications, i.e. :

• on the SOC Event Summary Display

• on the SOC Event Full Display

• on the Event Printer (also referred to as the Alarm Printer)

• from the Event report

The SOC forms are described in section 10.4.5 while an example of the Event Printer output isshown in figure 11-1.The information given consists of a textual description plus a range of supporting informationwhich should enable the operator to understand what has caused the event, to distinguish oneevent from another and to separate cause and effect.

The information falls into the following categories.

Sequence Number identifies the event uniquely within the system and can be used to relate theinformation about a single event which appears on the two displays and on the Event Printer.

Time shows the time the event is reported in the format dd-mmm-yyyy hh-mm-ss-tt

where: dd is day 1...31mmm is month JAN,FEB,MAR,APR,MAY,JUN,JUL,AUG,SEP,OCT,NOV,DECyyyy is year e.g. 1992hh is hour 00...23mm is minute 00...59ss is second 00...59tt is tick 00...99

Note that if the time appears as 1-Jan-1990, this is a default which is printed if the correct time isnot known by the report generator. This is a transitory condition which can be ignored.

Event class is used to locate the area of the system to which the event relates, as shown in theSOC banner summary alarm display. The event classes are described in section 10.4.3.

Note that some of these classes, e.g. FAX,X400, correspond to facilities which are not provided insome installations. Alarms in these categories will not be reported.

Note that events that refer to ISL, NCS , block updates, or TDM requests are not relevant to thisinstallation.

Severity on the Event Printer or Alarm level on the SOC forms shows what alarm indications aregenerated for this event, if any. The following severity categories exist, all of which apart from thelast are alarmable.

• Undelivered distress - failure to deliver a distress message.

Event M

essagesA

4-OP

G-003076


17th July 2001

11-2

++++++++++++++++++++++++++> EVENT <+++++++++++++++++++Seq. No. Time Class Severity Group, Evt. No., Processor Affected Object-------- ----------------------- ------- ---------- -------------------------- ---------------1342 16-DEC-1992 21:13:12:25 BAP INFO-ONLY #MCM_GROUP 27 IOR 403100420

Description : Call Initiated System Action : -------------------

Supporting Data:Ocean Region: 03 Mobile Number: 403100420 Msg Ref No: 238412 16-DEC-1992 21:16:56:21 LCU: TDM-01 Dir: LES-TO-MES

++++++++++++++++++++++++++> EVENT <+++++++++++++++++++Seq. No. Time Class Severity Group, Evt. No., Processor Affected Object-------- ----------------------- ------- ---------- -------------------------- ---------------1343 16-DEC-1992 21:16:58:36 BAP INFO-ONLY MCM_GROUP 27 IOR 403100420

Description : Call Completed System Action : -------------------

Supporting Data:Ocean Region: 03 Mobile Number: 403100420 Msg Ref No: 238412 16-DEC-1992 21:16:56:21 LCU: TDM-01 CCC: 50 Dir: LES-TO-MES

++++++++++++++++++++++++++> EVENT <+++++++++++++++++++Seq. No. Time Class Severity Group, Evt. No., Processor Affected Object-------- ----------------------- ------- ---------- -------------------------- ---------------1344 16-DEC-1992 21:17:43:10 CU INFO-ONLY SDC_GROUP 125 AOR 1. 1

Description : CU Summary Status System Action : -------------------

Supporting Data:Ocean Region: 01 Chassis ID: 1 Chassis Slot: 1 Status: OK Enabled: YES Data overun: NO Timing Lost: NO

++++++++++++++++++++++++++> EVENT <+++++++++++++++++++Seq. No. Time Class Severity Group, Evt. No., Processor Affected Object-------- ----------------------- ------- ---------- -------------------------- ---------------1345 16-DEC-1992 21:17:55:67 BAP INFO-ONLY APM_GROUP 1 BAPA

Description : Printer available System Action : -------------------

Supporting Data:Printer is now online and accessed via a LAT

Figure 11-1. Sample Event Printer Output


11-3

• Distress - receipt of a distress message.

• Urgent - major loss of traffic or degradation of the system.

• Semi-urgent - minor loss of traffic or loss of redundant equipment.

• Minor - other minor failure, or recovery/new availability indication.

• Information only - event which may be logged and printed but gives no alarm indica-tion.

Group on the printer and Reporting Component on the SOC displays describe the softwarecomponent which generated the event. The groups (which when displayed contain the suffix_GROUP) are:

• BAPS - BAP Supplementary

• APM - Alarm Printer Manager

• CRM - Call Record Manager

• DAC - Database Controller

• DIM - DEC Interface Manager

• DRH - Data Report Handler

• FDCD - FEP Data Change Distributer

• FAX - FAX Driver

• LFM - Log File Manager

• MAR - Message Archive and Retrieval

• MCM - Mobile Call Manager

• MDIR - Message Director

• MSCH - Message Scheduler

• PRC - Processor Redundancy Control

• SDC - Satellite Driver Control

• SOI - System Operator Interface

• TLX - Telex Driver

• XCCC - X25 Configuration Controller

Event Number is the number within a Group which together with the Group uniquely referencesthe type of event.

Processor indicates which one reported the event - BAPA or BAPB , except in the case of events

Event Messages A4-OPG-003076Issue 3.23 - Accepted

17th July 2001

11-4

relating to the satellite interface, where this column shows the Ocean Region to which the eventrelates: e.g. FP1, FP2, FP3 or FP4.

The information displayed under Affected Object on the printer and Object and Object Units onthe Event Full Display relates to the main item the event is concerned with e.g. Processor,Ocean Region. In many cases these details appear in a more digestible form under SupportingData, described below.

Description is the textual description of the event. There is a one to one correlation between thisand that for the corresponding group and event number, see Section 11.2.

System Action shows what actions the operator should take. This field is filled in only for certainspecific cases such as distress.

Supporting Data provides additional details of the event, such as ocean region identity or channelunit number. Any relevant status information collected at the time of the event is also displayed.

11.2 Event Details

The following sections describe the events generated by the LES in more detail and arecategorized according to Group and Event Number .

Also shown are brief details of the corrective action, where applicable. Where ’None’ is shown inthis field, it indicates that the operator does not need to take any specific action to correct a fault -either because the event does not relate to a fault or because, when there is a fault, another eventwill be raised and the action is described against that event.

Because of the complexity of the system, the corrective action is difficult to anticipate in manycases. Where several events occur at the same time, these should be analysed to determinewhich is the prime cause and which others are the result of that fault, before taking action.

The corrective action field for all distress related messages refers to local instructions, which it isassumed are issued at each LES to govern action in this important matter. In nearly all cases,distress events do not indicate a malfunction in the ACSE itself.

BAPS 01 Auto billing not running on partner node

Explanation: One of the two autobilling sessions running on the Master/Standby pair has reportedthe loss of its partner.

Supporting Data: None

Corrective action: Identify which session has failed by looking at the SYS$BATCH queues on eachBAP ($ SHOW QUEUE SYS$BATCH). On the BAP which has lost its billing batch job attempt todetermine the reason for the lack of billing (see chapter 16. Take corrective action and restartautobilling.

BAPS 02 An auto billing run has failed.

Explanation: Autobilling has failed to create billing files.


Corrective action: Identify which billing job has failed (billing will normally be run on the standbyBAP). Follow error recovery procedures detailed in section 16.9. This will depend on whether ornot "Billing Error Continue" had been selected during billing setup.


11-5

BAPS 03 Copy of billing file to target node has failed

Explanation: Autobilling has failed to copy billing files to the designated target node/directory.


Corrective action: Check decnet, ensure that the destination is visible from the BAP on which bill-ing is run and that write access has been granted. Check disk space. Follow error recoveryprocedures detailed in section 16.9. This will depend on whether or not the "Copy Error Continue"flag had been set during billing setup.

BAPS 04 Auto billing currently locked out

Explanation: An operator has elected to "Lock" billing and this is still in effect at a time when billingwas due to be performed.


Corrective action: Check for reason (if appropriate). Unlock as soon as possible to allow billing torun. Execute manual billing if required.

BAPS 05 Disk space short on ofdb$listdir

Explanation: Billing keeps a record of the largest billing file generated on the system to date. Analarm will be raised if the current available disk space is less than this figure.


Corrective action: Free up disk space

BAPS 06 Problem with partner node check password

Explanation: A billing process has encountered a problem in connecting to the partner node dueto a change in the password.


Corrective action: Check passwords. Restart autobilling if change is to be permanent. See section16.3.4

BAPS 10 Auto housekeeping run error.

Explanation: This is raised if there is a failure to complete an auto housekeeping request. Mostlikely as a result to write to tape or if a required file has been deleted or renamed after it has beencorrectly identified for housekeeping purposes.

Supporting data: A warning has been logged during the auto housekeeping run.Check OFDB$CACHE:User_Journal.Lis, BAP$ERROR:Auto_Billing*.LOG and output tape.

Corrective action: Correct the error and run manual backup/deletion.

APM 0 : Printer unavailable

Explanation: The event or report printer has become unavailable, for example because the paperhas run out.


17th July 2001

11-6

Supporting data: " Printer ’x’ has been closed due to a switchover " or" Printer ’x’ has been closed due to a printer failure " or" Printer ’x’ has been closed due to a user request"where ’x’ is the printer number.

Corrective action: if printer failed, obtain maintenance assistance.

APM 1 : Printer available

Explanation: The event or report printer has been restored to normal operation. This is initiated bythe operator.

Supporting Data: " Printer ’x’ is now online and accessed via a LAT " or" Printer ’x’ is now online "where ’x’ is the printer number.

Corrective action: none

CRM 10 : No call record buffers available

Explanation: Too many calls are currently in progress to allow another call record to be allocated:the maximum number of active call records (128) has been reached, or the call record buffer (128pages) is full.


Corrective action: This is is an unlikely occurrence; if situation persists, new traffic can besuspended by setting the congestion bit on the TDM channel or by taking incoming terrestrial cir-cuits out of service

DAC 0 : Database space warning threshold reached

Explanation: Database free space is becoming low. The operator set threshold has been passed.It is very unlikely that this should be reached without other warning messages, example : whereDNID space is used up. Database space is not related to disk usage as the space is allocatedwhen installed.

Corrective action: The action is to free up space, for example deleting DNID messages no longerrequired.

Supporting Data: None.

DAC 1 : Database space desperate warning threshold reached

Explanation: Database free space is becoming dangerously low. This is a more severe warningthan DAC 0.

Corrective action: See DAC0


DAC 2 : Database space exhaustion

Explanation: No space is left for the database. Traffic will be lost.

Corrective action: Take the action described in DAC 0 immediately. Also investigate why the ear-


11-7

lier warnings were ignored.


DAC 10 : Database Connections Alarm

Explanation: More than 10 DB connections held for over 5 minutes.

Corrective action: Call HNS.


DIM 10 : Link Up

Explanation: DECnet link restored.

Corrective action: No action required.

Supporting Data: The Affected Object identifies the processor for which the link is now up. Linkidentification (used for HNS diagnostics).

DIM 20 : Link Down

Explanation: The link from one processor to another is not operational.

Supporting Data: The Affected Object identifies the processor for which the link is down. Link iden-tification (used for HNS diagnostics).

Corrective action: No action directly connected with this event.

DRH 0 : Registered user data report file overflow

Explanation: A mobile has submitted a data report or a DNID-addressed message that cannot bestored because there is not enough space left in the registered user’s DNID file. The overflow flagis set, and the event is not raised again until it is cleared when more space is created by theoperator increasing the registered user’s quota, or the registered user deleting some of the DNIDfile’s contents.

Supporting Data: (For data report) PIN, DNID, member number, ocean region (UNK).

Corrective action: Registered user should clear old entries in the DNID file. If the problem occursrepeatedly for a particular user, the allocated file space can be increased, if this is agreed com-mercially with the customer.

Note: For FAX events.

Fax events FAX 100 - FAX 124 refer to delivery attempts. These events refer to the final deliveryattempt. It is feasible that previous delivery attempts may have failed (for the same or otherreasons).

The events FAX 100 - FAX 124 generate call completion codes 400 - 424 respectively. These aredescribed in Appendix E.

FAX 21 : FAX PC Now In Service

Explanation: Indicates that the quoted Fax PC is now available for message delivery and work


17th July 2001

11-8

may currently be in progress via this Fax PC.

Supporting Data: Fax PC Id and Fax PC Node Name.

Corrective action: No action is required.

FAX 22 : Fax PC Now Pending Out of Service

Explanation: Indicates that the quoted Fax PC is no longer available for message delivery.However messages already queued for this Fax PC in the WorkArea will be delivered.

The PC has been set to this state as the result of operator instruction that this Fax PC shouldbecome Out Of Service . The Fax PC will remain Pending Out Of Service until there are no moremessages or delivery details to be processed in the WorkArea (that is files suffixed by .SUB,.WPC or .FIN). Once all outstanding work has been handled the Fax PC will then be set to Out OfService .


Corrective action: This event is normally only raised as the result of operator intervention. No fur-ther action is required.

FAX 23 : FAX PC Now Out Of Service

Explanation: Indicates that the quoted Fax PC has no work outstanding or in progress and is notavailable for message delivery. This PC can now be safely shut down for upgrade or maintenancework.


Corrective action: No corrective action is required.

FAX 24 : Fax PC Now Contact Made

Explanation: The quoted Fax PC has now been successfully restarted. This is indicated by thepresence of a file named 00000000.SYN created by the Fax PC within the WorkArea (that is thedirectory on the ShadowSet allocated solely to this PC).


Corrective action: This event is for information only; no action is required.

FAX 25 : FAX PC Now Contact Lost

Explanation: This event indicates that the Fax PC is no longer correctly synchronizing with theLES. Typically this event will be raised because the LES could not find a synchronization file(11111111.SYN) within the WorkArea. It could also be raised because an unexpectedsynchronization file has found (a .SYN file other than 00000000.SYN or 11111111.SYN).


Corrective action: Examine the Zetafax Monitor and Startup.Cmd windows on the quoted FaxPC in order to determine the reason for failure. The Fax PC may need to be restarted once theproblem has been resolved.

FAX 26 : FAX PC Now Shut Down


11-9

Explanation: The LESFAX subsystem has received a request from the LES system to shutdownoperation. The Fax PC is no longer available for message delivery.

Supporting Data: Fax PC Id and FAX PC Node Name.

Corrective action: A shutdown is normally the result of operation intervention. No further action isrequired.

FAX 31 : FAX Route Now In Service

Explanation: Indicates that the quoted Fax route is now available for message delivery and mes-sages may currently being delivered on this route. A Fax route will always be In Service whilstthere is at least one Fax PC on that route which is In Service .

Supporting Data: Fax route number and route name.

Corrective action: This event is for information only; No further action is required.

FAX 32 : FAX Route Now Pending Out Of Service

Explanation: Indicates that the quoted Fax route is not available for message delivery. This routestate has been set as the result of operator instruction that the Fax PCs on this route shouldbecome Out Of Service . This route will remain Pending Out of Service until there are no moreFax PCs on this route which are either In Service or Pending Out Of Service . At that time theroute status will become Out Of Service .


Corrective action: This event is the result of operator intervention. No further action is required.

FAX 33 : FAX Route Now Out Of Service

Explanation: Indicates that the quoted Fax route has no work outstanding or in progress and is notavailable for message delivery. Fax PCs assigned to this route can now safely be shutdown formaintenance or upgrade work.


Corrective action: This event is normally raised as the result of operator intervention.

FAX 34 : FAX Route Now Shut Down

Explanation: The LESFAX subsystem has received a request from the LES system to shutdownoperation.


Corrective action: This event is normally only raised as the result of operator intervention. No fur-ther action is required.

FAX 100: Cannot Deliver Via This Route

Explanation: The Fax Driver is unable to deliver the specified message via the specified route asthe driver is unaware of the existence of this route.

Supporting Data: Message Reference Number and Route.


17th July 2001

11-10

Corrective Action: Check the preferred route for the fax driver and that this route is defined withinthe fax SOC forms.

FAX 101: No PC Available On This Route

Explanation: The Fax Driver is unable to deliver the specified message via the specified route asthe driver cannot find any PCs configured for this route.

Supporting Data: Message Reference Number and Route.

Corrective Action: Check that a PC is defined for this route within the fax SOC forms.

FAX 102: Failed To Secure Message To PC

Explanation: The Fax Driver is unable to deliver the specified message as the driver has beenunable to secure the message to the specified PC’s hard disk and hence the third party Zetafaxsoftware.

Supporting Data: Fax PC Id, Fax PC Node Name and Message Reference Number.

Corrective Action: It may be necessary to reinstall Pathworks on the BAP and/or the PC.

FAX 103: Bad Delivery File Returned By PC

Explanation: FAX is unable to process a delivery file correctly. The PC returns two files for everymessage: a .DEL file containing delivery attempt details and a .FIN file containing all other infor-mation. If either of these files cannot be processed then the .FIN file will be renamed to .BAD toenable the processing of other messages to continue. This situation may arise due to a PC return-ing an invalid file or a file being locked or corrupted.

Supporting Data: Fax PC Id, Fax PC Node Name and the .BAD filename.

Corrective Action: Do not delete the .BAD and corresponding .DEL file as these will be required toascertain the problem. Note. It is possible that the message was sent correctly, however it isadvisable to assume a failed delivery.

FAX 104: Path Not Found

Explanation: The PC communicates with the BAP via a shared disk area using Pathworks. If thisshared area cannot be accessed by both FAX and by the PC (using virtual drives D:and E:) thenthe PC is effectively useless. The specified PC will not be available for message delivery orproducing statistics.


Corrective Action: It may be necessary to reinstall Pathworks on the BAP and/or the PC.

FAX 105: PC Error, Forced PC OOS

Explanation: The Fax PC that was attempting to deliver the message has developed a problem. Itwas necessary to remove this PC from service so no more messages are routed to it. This PC willremain Out Of Service until the operator puts it back In Service.

Supporting Data: Fax PC ID and Fax PC Node Name

Corrective Action: Attempt to rectify the PC problem. It may be possible to do this by simply shut-


11-11

ting down and restarting the PC. The PC must then be put back into service using the relevantSOC form.

FAX 106: PC Error, Moved File to Another PC

Explanation: The Fax PC that was attempting to deliver the message has developed a problem.This message cannot be delivered by this PC so it has been re-directed to another PC on thesame route.

Supporting Data: Message filename, Source Fax PC ID, source Fax PC Node Name, destinationFax PC ID and destination Fax PC Node Name

Corrective Action: None. If further problems occur then the PC will be forced Out Of Service andanother Event will be raised.

FAX 110: Zetafax Cannot Access Control File

Explanation: The specified PC is unable to deliver the specified message as Zetafax cannot ac-cess the PC control file for this message, or the control file is invalid. Whilst a message is beingprocessed, both a control file and a data file will exist for this message in theZETAFAX\USERS\API\Z-OUT directory. These files are deleted by Zetafax on completion of mes-sage processing, not to be confused with the .FIN and .DEL files in the shared disk area which aredeleted by FAX when it processes the Zetafax delivery details.


Corrective Action: As the control file is normally deleted following the final delivery attempt thismay prove difficult to correct. However, check the ZETAFAX\USERS\API\Z-OUT directory to see ifthe file is still there and ensure that it is not locked.

FAX 111: Zetafax Cannot Access Message File

Explanation: The specified PC is unable to deliver the specified message as Zetafax cannot ac-cess the PC message file, or the message file is invalid. Whilst a message is being processed,both a control file and a data file will exist for this message in the ZETAFAX\USERS\API\Z-OUTdirectory. These files are deleted by Zetafax on completion of message processing, not to be con-fused with the .FIN and .DEL files in the shared disk area which are deleted by FAX when itprocesses the Zetafax delivery details.


Corrective Action: As the message file is normally deleted following the final delivery attempt thismay prove difficult to correct. However, check the ZETAFAX\USERS\API\Z-OUT directory to see ifthe file is still there and ensure that it is not locked.

FAX 112: PC Disk Full

Explanation: The specified PC is unable to deliver the specified message as there is insufficientspace on the PC hard disk for Zetafax to create the necessary message files.


Corrective Action: Free some space on the specified fax PC.

FAX 113: Zetafax Bad INI File


17th July 2001

11-12

Explanation: The specified PC is unable to deliver the specified message as Zetafax cannot ac-cess the Zetafax.INI file, or the Zetafax.INI file is invalid.


Corrective Action: Ensure that a ZETAFAX.INI file exists on the PC and that the AUTOEXEC.BATfile has the correct path set up so the file can be accessed.

FAX 114: Zetafax Cannot Convert Message

Explanation: The specified PC is unable to deliver the specified message as Zetafax cannot con-vert the message into the correct format. This could be caused by an invalid message.


Corrective Action: It may prove difficult to determine why a message conversion failed. If possibleexamine the contents of the failed message.

FAX 115: Zetafax Cannot Access Letterhead

Explanation: The specified PC is unable to deliver the specified message as Zetafax cannot ac-cess the letterhead for this message, or the letterhead file is invalid.

Supporting Data: Fax PC Id, Fax PC Node Name, Message Reference Number and Letterhead.

Corrective Action: Ensure that the specified letterhead exists, i.e. there is a corresponding G3F filein the C:\ZETAFAX\SYSTEM\Z-LETTER directory. Ensure that Zetafax has been set up correctlyand is aware of the existence of this letterhead. See Reference 6 for details on how to use theZetafax Setup program.

FAX 116: Zetafax Cannot Access Graphic

Explanation: The specified PC is unable to deliver the specified message as Zetafax cannot ac-cess a graphics file referenced within this message (or associated banner), or a graphics file isinvalid.


Corrective Action: Any graphic referenced within the message must have a corresponding G3F filein the C:\ZETAFAX\SYSTEM\Z-GRAPH directory. If a graphic is used, it will most likely be as partof the banner. In this case check that the banner file used for this message does not contain areference to a non-existent graphic.

FAX 117: Device Failed

Explanation: The specified message cannot be delivered by the specified PC due to the specifiedfax modem device being in a failed state. This device will remain in a failed state.

Supporting Data: Fax PC Id, Fax PC Node Name, Fax Modem Device COM Port Number andMessage Reference Number.

Corrective Action: Ensure that the device is configured correctly and that the device installed cor-responds to the device configured. See Reference 6 for details on how to use the Zetafax Setupprogram. It may be useful to test the modem device outside of the Zetafax environment usingstandard AT commands.


11-13

FAX 118: Device Busy

Explanation: The specified message cannot be delivered by the specified PC due to the specifiedfax modem device being busy.


Corrective Action: None necessary, in time the device should clear.

FAX 119: Device Offline

Explanation: The specified message cannot be delivered by the specified PC due to the specifiedfax modem device being offline (unavailable for sending).


Corrective Action: None necessary, in time the device should clear.

FAX 120: Device Invalid

Explanation: The specified message cannot be delivered by the specified PC due to the specifiedfax modem device being invalid. The device may be incompatible or configured incorrectly.


Corrective Action: Ensure that the device is configured correctly and that the device installed cor-responds to the device configured. See the reference 6 for details on how to use the ZetafaxSetup program.

FAX 121: No Device Available

Explanation: The specified message cannot be delivered due to the specified PC having no work-ing fax modem devices of the correct type.


Corrective Action: Ensure that the PC contains fax modem devices, that they are configured cor-rectly and that the device installed corresponds to the device configured. See Reference 6 fordetails on how to use the Zetafax Setup program.

FAX 122: Device Protocol Error

Explanation: The specified message cannot be delivered by the specified PC due to a seriouserror in communicating with the specified fax modem device.


Corrective Action: Ensure that the device is configured correctly and that the device installed cor-responds to the device configured. See reference 6 for details on how to use the Zetafax Setupprogram. It may be useful to test the modem device outside of the Zetafax environment usingstandard AT commands.


17th July 2001

11-14

FAX 123: Device Timeout

Explanation: The specified message cannot be delivered by the specified PC due to the specifiedfax modem device timing out.


Corrective Action: Ensure that the device is configured correctly and that the device installed cor-responds to the device configured. See reference 6 for details on how to use the Zetafax Setupprogram. It may be useful to test the modem device outside of the Zetafax environment usingstandard AT commands.

FAX 124: Device No Dial Tone

Explanation: The specified message cannot be delivered by the specified PC due to the specifiedfax modem device not detecting a dialtone when a call attempt was made. This indicates either afailure in the exchange or the connection to the exchange.


Corrective Action: Ensure that the device has the correct type of cable and is properly connectedto the PSTN. PSTN problems are beyond the scope of this document.

FDCD 10 : CU FEP configuration load requested

Explanation: Usually raised as part of CU FEP start-up or switchover. FEP requests its databasebe consistent with that of the BAP.

Supporting Data: FEP ID.

Corrective action: None

FDCD 11 : CU FEP configuration load initiated

Explanation: Earlier request for FEP configuration load has begun to be serviced.



FDCD 12 : CU FEP configuration load completed

Explanation: Earlier request for FEP configuration load has been successfully completed. No ac-tion required.



FDCD 13 : CU FEP configuration load failed

Explanation: Earlier request for FEP configuration load has failed. This will usually mean that theFEP will not be able to operate successfully.


11-15

Supporting data: FEP ID, Failure Reason.

Corrective action: Check the installation procedure for creating the FEP load file and that this iscorrectly pointed to. If this is information is correct, restart the FEP. If the event then re-occursperform a FEP switchover. If the event then occurs contact HNS.

LFM 0 : Log file space warning threshold reached (80%)

Explanation: 80% of the logfile space is full.


Corrective action: Take action to delete unwanted files and logfiles, i.e. use SOCV to move themto the Offline logfile area. Ensure that these files are first archived before deletion.

LFM 1 : Log file space critical warning threshold reached (95%)

Explanation: Log file space is almost exhausted.


Corrective action: Take urgent action to delete unwanted files and logfiles, i.e. use SOCV to movethem to the Offline logfile area. Ensure that these files are first archived before deletion. This isthe third warning.

LFM 2 : No log file space available, records being lost

Explanation: Take immediate steps to clear log file space. This warning only occurs after LFM 0,LFM 5 and LFM 1 in succession, so ascertain why action was not taken when these earlier warn-ings were issued.


LFM 3 : Synchronisation still in progress

Explanation: The two copies of the database are kept in synchronization by the disk shadowingmechanism. This event is raised to show that the two databases are still being synchronised.



LFM 5 : Log file space severe warning threshold reached (90%)

Explanation: 90% of the logfile space is full.


Corrective action: Take action to clear file and logfile space of unwanted files. This is the secondwarning.

LFM 6 : Synchronisation completed

Explanation: The databases have been synchronised



17th July 2001

11-16


LFM 7 : Synchronisation failure

Explanation: Synchronization of the databases failed.


Corrective action: Contact HNS.

MAR 10 : 80 percent of full service message file space used

Explanation: 80% of the message text space is now being used. The message text space isconfigured by default for 20 normal priority and 20 distress priority messages concurrently.


Corrective action: See MAR 30

MAR 20 : 90 percent of full service message file space used

Explanation: 90% of the message text space is now being used.



MAR 30 : First normal service token retracted

Explanation: The system is concurrently able to accept fewer than the configured maximum num-ber of maximum length normal priority messages, but is still able to accept the configured max-imum number of maximum length distress priority messages.


Corrective action: When token retracted events appear the operator should ascertain why mes-sages remain undelivered in the system, e.g. line failure, and remedy the condition, otherwise theLES will eventually have to reject messages.

MAR 40 : 80 percent of normal service tokens retracted

Explanation: The system is concurrently able to accept only 20% of the configured maximum num-ber of maximum length normal priority messages, but is still able to accept the configured max-imum number of maximum length distress priority messages.



MAR 50 : Normal service not available

Explanation: The system is no longer able to accept normal priority messages, but is still able toaccept the configured maximum number of maximum length distress priority messages. However,the space remaining is enough to store up to 65 times as many messages of average length (up to500 characters).


11-17



MAR 60 : First Distress Token Retracted

Explanation: The system is concurrently able to accept fewer than the configured maximum num-ber of maximum length distress priority messages.



MAR 70 : 50 percent of Distress Tokens Retracted

Explanation: The system is concurrently able to accept only 50% of the configured maximum num-ber of maximum length distress priority messages.



MAR 80 : 90 percent of Distress Tokens Retracted

Explanation: The system is able to accept only 10% of the configured maximum number of max-imum length distress priority messages.



MAR 90 : Distress Service not available

Explanation: The system is no longer able to accept distress priority messages.



MCM 1 : Ship Transfer Finite state machine protocol violation

Explanation: In exercising the protocols of ref 1 regarding interaction between LES and MES anevent occurs which is not allowed by the protocol.

Supporting Data: Ocean region, station number, mobile number, state (see ref 1), event (see ref1), message reference number, internal error code.

Corrective action: Possible protocol violations are documented in ref 1 and may be caused byMES, or satellite as well as LES problems. Generally the LES will continue to operate normallyafter this event.

MCM 2 : TDM Group Finite state machine protocol violation

Explanation: In the process of assigning TDM channels an event occurs not allowed by theprotocols defined in ref 1.


17th July 2001

11-18

Supporting Data: Ocean region, station number, TDM Group ID, TDM frequency, state (see ref 1),event (see ref 1).

Corrective action: If the TDMs do not become operational then refer to HNS Ltd.

MCM 3 : MES list update protocol error

Explanation: In performing a block update, from the NCS, to the MES list it was found that it wasnot possible to successfully complete all the updates.

Supporting Data: Ocean region, station number, state (see ref 1), event (see ref 1), last sequencenumber, update timer, timeout identity.

Corrective action: Refer to HNS Ltd.

MCM 8 : TDM Group Release Sent in DA Mode

Explanation: Request for TDM group release by LES, when in Demand Assigned mode, acceptedand acknowledged by the NCS.

Supporting Data: Ocean region, Spot ID, station number, TDM Group ID, request number.


MCM 9 : TDM Group Released Acked in DA Mode

Explanation: TDM release information from NCS, from Demand Assigned mode.

Supporting Data: Ocean region, Spot ID, station number, TDM Group ID, request number.


MCM 10 : TDM group requested from NCS

Explanation: LES request for TDM from NCS has been initiated.

Supporting Data: Ocean region, station number, TDM Group ID, request number, return channels.


MCM 11 : TDM group request timeout for NCS

Explanation: LES request for TDM from NCS has not been serviced in time allowed.

Supporting Data: Ocean region, station number, TDM Group ID, request number, return channels,attempt number, time waited.

Corrective action: The operator action should be to repeat the request. If the same event thenoccurs check the ISL link is operational. If it is then contact the NCS.

MCM 12 : TDM group request response from NCS

Explanation: TDM allocation received from NCS

Supporting Data: Ocean region, station number, TDM Group ID, request number, hold time, TDMfrequency, return channels.


11-19


MCM 13 : TDM Group Request rejected by the NCS

Not used.

MCM 14 : TDM Group Released from NCS

Explanation: Request for TDM group release by LES accepted and acknowledged by the NCS.

Supporting Data: Ocean region, station number, TDM Group ID, request number, hold time, TDMfrequency, return channels.


MCM 15 : TDM Group release timeout for NCS

Explanation: LES request for TDM group release from NCS has not been serviced in time allowed.

Supporting Data: Ocean region, station number, TDM Group ID, request number, attempt number,time waited.

Corrective action: The operator should repeat the release request. If the same event then occurscheck the ISL link is operational. If it is then contact the NCS.

MCM 16 : TDM Group Release Acked by the NCS

Explanation: TDM release information from NCS.

Supporting Data: Ocean region, station number, TDM Group ID, request number.


MCM 17 : TDM Group released because TDM Group overall status not UP

Explanation: See above.

Supporting Data: Ocean region, station number, TDM Group ID.

Corrective action: Need to check for any reason why the TDM Group was down e.g. FEP problem(usually also flagged by other events). The LES will also request the NCS to release the TDMgroup. Having checked the system is operating correctly re-request the TDM group from the NCS.

MCM 18 : TDM Group processing stopped because ISL status is not up

Not used.

MCM 19 : TDM Group Pending from the NCS

Not used.

MCM 21 : PVT Start

Explanation: Start of PVT indicated.

Supporting Data: Ocean region, station number, mobile number, message reference number.


17th July 2001

11-20


MCM 22 : PVT Successful

Explanation: Successful completion of PVT.

Supporting Data: Ocean region, station number, mobile number, message reference number,overall result, signal strength, distress test, forward attempt, return attempt, bber, test attempt.


MCM 23 : PVT Failed

Explanation: Unsuccessful completion of PVT.

Supporting Data: Ocean region, station number, mobile number, message reference number,overall result, signal strength, distress test, forward attempt, return attempt, bber, test attempt.

Corrective action: Only action possible is to contact mobile owner to inform him that the mobile isfaulty.

MCM 24 :Test call initiated

Explanation: A test call has been initiated by a mobile marked in the ACSE as a Test Mobile onthe SOC using the Test Mobile Definition form.

Supporting Data: Ocean region, mobile number, message reference number, start time, signalLUN, call direction.


MCM 25 : Test call completed

Explanation: Test call earlier initiated by a test mobile now completed.

Supporting Data: Ocean region, mobile number, message reference number, end time, callcompletion code, call direction, TDM/MSG LUN.


MCM 26 : Call initiated

Explanation: This relates to satellite call attempts only. If call logging is enabled, using the EventDefinition Form, this event is raised when a call to a satellite has been initiated.

The operator should consider carefully when to use this facility. It is normally only used in con-junction with MCM 27, for testing when the call rate is low.



MCM 27 : Call completed

Explanation: Logs end of call to/from mobile and call outcome. Use in conjunction with MCM 26 -


11-21

refer to that event for more details.

Supporting Data: Ocean region, mobile number, message reference number, start time, TDMLUN, call completion code, call direction.


MCM 28 : Call pended

Explanation: Call waiting to continue depending on resource availability.



MCM 29 : Call not Congested

Explanation: Call which earlier had been held up due to congestion now able to continue.



MCM 30 : Congestion on the TDM

Explanation: TDM is congested. Whilst this condition remains messages cannot be transmitted bythe LES using that TDM.

Supporting Data: Ocean region, station number, TDM group id.

Corrective action: Temporary relief can be obtained by putting incoming telex and PSDN lines outof service to limit shore to mobile traffic. When this event is raised frequently, additional TDMgroup capacity is required to be installed.

MCM 31 : Congestion cleared on the TDM

Explanation: Congestion on TDM, reported previously, now cleared.

Supporting Data: Ocean region, station number, TDM group id.

Corrective action: Put Telex and PSDN lines back in service if they were put out of service follow-ing corrective action for MCM 30.

MCM 35 : Congestion on the ISL

Not used.

MCM 36 : Congestion cleared on the ISL

Not used.

MCM 40 : Corrupted Distress Alert Received

Explanation: Distress Alert Packet received from the MES is corrupted but the operator is informed


17th July 2001

11-22

in order to initiate distress procedures.

Supporting Data: Ocean region, station number, mobile number, return id.

Corrective action: See local instructions relating to the handling of distress traffic.

MCM 41 : Corrupted Distress Message Received

Explanation: Distress message received from the MES is corrupted but the operator is informed inorder to initiate distress procedures.


Corrective action: See local instructions relating to the handling of distress traffic.

MCM 42 : Land Mobile Alert Packet Received

Explanation: Land Alert Packet received from the MES.


Corrective action: See local instructions relating to the handling of land mobile alerts.

MCM 43 : Land Mobile Alert Packet Received from Unregistered Mobile

Explanation: Land Alert Packet received from the MES, but mobile not contained in the LESMobile List.

Supporting Data: Ocean region, station number, mobile number (480000000), return id.

Corrective action: See local instructions relating to the handling of land mobile alerts.

MCM 50 : Data report received from an unknown CNID

Explanation: A data report has been received at the LES for a DNID not known by the LES. Thisreport will be deleted by the LES. Besides checking that the DNID is not be among those used bythe LES there is nothing further to be done.

Supporting Data: Ocean region, station number, DNID.

Corrective action: None for isolated incidences. If fault persists from a particular mobile, contactthe mobile owner to arrange for re-programming.

MCM 51 : Data report received for unknown LES ID

Explanation: A data report has been received at the LES for an LES ID which is not that of theLES. This report will be deleted by the LES. Besides checking that the LES ID is correctly set forthe LES there is nothing further to be done.

Supporting Data: Ocean region, station number.

Corrective action: None for isolated incidences. If fault persists from a particular mobile, contactthe mobile owner to arrange for re-programming.

MCM 60 : Standalone mode entrance complete


11-23

Explanation: This is generally reported when the LES enters Standalone mode as a result of theoperator using the LES Management SOC form.

Supporting Data: Ocean region.


MCM 61 : Standalone mode Exit complete

Explanation: This is generally reported when the LES leaves Standalone mode as a result of theoperator using the LES Management SOC form.

Supporting Data: Ocean region.


MCM 70 : Mobile login complete

Explanation: A mobile has logged into the LES.

Supporting Data: Mobile number, ocean region.


MCM 71 : Mobile logout complete

Explanation: A mobile has logged out from the LES.

Supporting Data: Mobile number, ocean region.


MCM 72 : Unable to add mobile to database, possible duplicate

Explanation: An attempt has been made to add a mobile to the MES list but that mobile numberalready exists, possibly with a different return/forward id.

Supporting Data: Ocean region, mobile number, return id, forward id.

Corrective action: If the new entry is the one desired then the old entry should first be removed.

MCM 73 : Block update request to NCS

Not used.

MCM 74 : Block start received from NCS

Not used.

MCM 75 : Timeout waiting for Block Start from NCS

Not used.

MCM 76 : Block End received from NCS

Not used.


17th July 2001

11-24

MCM 77 : Timeout waiting for Block End from NCS

Not used.

MCM 78 : Failure to update mobile in database

Explanation: An attempt to update a mobile entry in the database has resulted in error.

Supporting Data: Ocean region, mobile number, return id, forward id.

Corrective action: Correct the corrupt entry in the mobile list. Refer to section 9.1.5

MCM 80 : Signalling channel Inactive

Explanation: No activity on a signalling channel. See section 7.10.5 for details.

Supporting Data: Ocean region, LCU, slot, id.


MCM 81 : Message Channel Inactive

Explanation: No activity on a message channel. See section 7.10.5 for details.



MCM 82 : Signalling channel Active

Explanation: Activity once again on signalling channel. Only occurs after event MCM 80.



MCM 83 : Message Channel Active

Explanation: Activity once again on message channel. Only occurs after event MCM 81.



MCM 85 : Distress Message Assignment Request

Explanation: This is the first indication of a distress message received by the LES. The operatorshould be looking for further events indicating successful delivery of the message. If this does notoccur the operator should instigate the local procedure for handling distress.

Supporting Data: Ocean region, station number, mobile number (default), return id.

Corrective action: See local instructions for distress actions.

MCM 86 : Distress Alert Packet Received


11-25

Explanation: This is the first indication of a distress alert received by the LES. The operator shouldbe looking for further events indicating successful delivery of the alert. If this does not occur theoperator should instigate the local procedure for handling distress.

Supporting Data: Ocean region, station number, mobile number.


MCM 87 : Distress Alert Received from Unregistered Mobile

Explanation: As MCM 86 but where the mobile number cannot be determined.



MCM 88 : Distress Message Received from Unregistered Mobile

Explanation: As MCM 85 but where the mobile number cannot be determined.



MCM 90 : NCS failed to respond to a distress alert

Not used.

MCM 91 : NCS failed to respond to an EGC

Not used.

MCM 92 : NCS failed to respond to a TDM request

Not used.

MCM 93 : NCS failed to respond to a TDM release request

Not used.

MCM 94 : NCS failed to respond to an announcement request

Not used.

MCM 95 : NCS failed to respond to a Poll

Not used.

MCM 96 : The first TDM carrier in this OR has become active

Explanation: Raised as a result of the TDM group being brought into service, e.g. via the TDMGroup Management SOC form. Informs the operator that the TDM is now ready to broadcast mes-sages.

Supporting Data: Ocean region, station number, TDM group.


17th July 2001

11-26


MCM 97 : The last TDM carrier in this OR has become inactive

Explanation: Raised as a result of the TDM group being brought out of service, e.g. via the TDMGroup Management SOC form. Informs the operator that the TDM can no longer be used tobroadcast messages.

Supporting Data: Ocean region, station number, TDM group.

MCM 98 : TDM outbound limit reduction

Explanation: The load for that TDM has exceeded a pre-defined limit (usually set on installation,default 20) and has been reduced by a user defined amount (throttle in).

Supporting Data: Ocean region, TDM group, new level


MCM 99 : TDM Group outbound lower limit reached

Explanation: The load for that TDM has been reduced to the minimum level allowed by the sys-tem.



MCM 100 : The internal queue of MCM is full

Explanation: Raised as an internal warning of software problem.

Supporting Data: Ocean region, queue.

Corrective action: Switch BAPs and restart the new Standby. Report to HNS Ltd.

MCM 101 : TDM Group outbound limit increase

Explanation: The load for that TDM has fallen below a pre-defined limit (usually set on installation,default 20) and has been increased by a user defined amount (throttle out).



MCM 102 : Mobile failed to retune to a login ack frequency

Explanation: Raised as an internal warning when as a result of a mobile having attempted to login,and being told by the LES to retune to a different TDM, it attempts to login again using the sameTDM as before. The LES will allow this second attempt, but alerts the operator to advise him ofthis protocol violation.

Supporting Data: Ocean region, spot, mobile number.

Corrective action: Advise mobile owner to change mobile software to handle protocols correctly.


11-27

MCM 103 : Registration Update Request packet sent to the NCS

Explanation:

Supporting Data:Ocean Region: <WOR,AOR,POR,IOR>, Mobile Number: <490000000>OROcean Region: <WOR,AOR,POR,IOR>, Forward Id : <11223344>OROcean Region: <WOR,AOR,POR,IOR>, Return Id: <12345678>

Corrective action: None.

MCM 105 : MCM Failed to Create the Pending Event List Global Section

Explanation: The master BAP has failed to create the Pending Event List during startup.


Corrective action: Switch Baps.

MCM 120 : The MCM main input queue has become congested

Explanation: The number of packets in the MCM main input queue has reached a set maximumthreshold.

Supporting data: congested queue id

Corrective action: None. The number of packets allowed to enter the queue will be reduced and, innecessary, packets discarded until that queue is no longer congested.

MCM 121 : Main input queue congestion has now cleared

Explanation: Following the main input queue being marked as congested, the number of packetsin the queue has been reduced to a set lower threshold. The queue will now resume normaloperation.

Supporting data: Number of discarded packets.


MCM 122 :

This event reserved for future use

MCM 123: No TDM at NCS

Explanation: This will be generated in response to a call failing with CCC 831 (TDM not available)in a particular ocean region. The alarm will be raised for the first call to fail in this way (in the OR),but not for subsequent failures. The alarm will only be raised again once there has been a suc-cessful call and a call subsequently fails.

Supporting data: The NCS returned ’No TDM’ in response to an announce in <Ocean Region>.

Corrective action: Use the TDM Group Management form and the ’Release’ button. (This willcause the TDM to be released and then automatically requested immediately by the LES)


17th July 2001

11-28

Note: for all MDIR and MSCH events:-

• message ID - includes the message’s priority, message kind, message referencenumber, ICR call serial number, and originator raw address. If the specified messageis a delivery notification, the message ID also includes the original message’s mes-sage kind, message reference number, and ICR call serial number.

• delivery ID - includes the message ID, and the delivery’s destination number (its in-dex in the destination list for the message), destination raw address, and DCR callserial number.

• delivery status - includes the delivery’s current retry count, delivery attempt count,and call completion code.

• route ID - for satellite TDM routes, includes the ocean region, and spot beam ID; forsatellite ISL routes, includes the ocean region; and, for terrestrial routes, includes theroute number.

• Reload counts - includes the number of message details or delivery statusesselected to be fetched from the LES Database, and the number fetched so far.

• Bulk cancellation request - specifies which messages are to be bulk cancelled andthe request number.

• Bulk cancellation response - specifies how many messages will be or would havebeen bulk cancelled and the request number.

• Bulk cancellation summary - specifies how many messages actually were bulk can-celled and the request number.

• Bulk cancellation ID - specifies the ID of a message that was queued up to be bulkcancelled and the request number.

MDIR 2 : NDN not delivered and not spilled out

Explanation: An NDN could not be delivered to the registered user’s delivery notification address(for registered access) or the originator (for unregistered access and mobile originated messages),and could not be delivered to the spill-out position. The delivery information shown in the support-ing data relates to the last attempt to deliver the NDN to the spill-out position.

Supporting Data: Delivery ID, delivery status.

Corrective action: Investigate why delivery to the spill-out position was not possible, e.g. was it inservice, is it correctly defined in the NDN Spill-out Destination Definition form. Refer to local in-structions regarding delivery of NDNs by other means.

MDIR 3 : PDN not delivered and not spilled out

Explanation: A PDN could not be delivered to the registered user’s delivery notification address(for registered access) or the originator (for unregistered access and mobile originated messages),and could not be delivered to the spill-out position. The delivery information shown in the support-ing data relates to the last attempt to deliver the PDN to the spill-out position.

Supporting Data: Delivery ID, delivery status

Corrective action: Investigate why delivery to the spill-out position was not possible, e.g. was it in


11-29

service, is it correctly defined in the NDN Spill-out Destination Definition form. Refer to local in-structions regarding delivery of PDNs by other means.

MDIR 4 : Route has become available

Explanation: A delivery route has been made available to Message Handler by an output driver.

Supporting Data: Route ID.


MDIR 5 : Route has become unavailable

Explanation: A delivery route has been made unavailable to Message Handler by an output driver.


Corrective action: Check operation of the output driver, e.g. are all circuits in service.

MDIR 6 : Unable to route a delivery

Explanation: A destination address cannot be routed by Message Handler, probably because thecountry code or routing tables have not been configured correctly. The country code tables arenormally configured to ensure invalid destination addresses are rejected at the address validationstage, before routing is attempted. The delivery is given call completion code 901 (routing failed)and is considered to have failed.


Corrective action: check country code and routing tables.

MDIR 7 : Unable to reroute a delivery

Explanation: A destination address cannot be rerouted by Message Handler, possibly because thecountry code or routing tables have not been configured correctly, as for MDIR 6, but more prob-ably, because there is no further destination address for a delivery notification, in which caseMDIR 2 or 3 will also be raised. The delivery is given call completion code 902 (rerouting failed)and is considered to have failed.


Corrective action: for delivery notifications, see MDIR 2 or 3; otherwise, see MDIR 6.

MDIR 8 : MRCC route has become available

Explanation: An MRCC delivery route has been made available to Message Handler by an outputdriver.

Supporting Data: (Primary_only/Secondary_only/Primary_and_secondary), route ID.


MDIR 9 : MRCC route has become unavailable

Explanation: An MRCC delivery route has been made unavailable to Message Handler by an out-put driver.


17th July 2001

11-30

Supporting Data: (Primary_only/Secondary_only/Primary_and_secondary), route ID.

Corrective action: check equipment at MRCC, check connection to it.

MDIR 10 : 90 percent threshold route queue length exceeded

Explanation: 90% of the configured maximum number of deliveries queued for a route in MessageHandler (500 by default) has been reached.


Corrective action: check that all lines are in service. If the event is raised frequently, additionalcapacity may be needed.

MDIR 12 : Maximum queue length reached, Distress only accepted

Explanation: The configured maximum number of deliveries queued for a route in MessageHandler (500 by default) has been reached. The system is only able to accept distress messagesfor this route. However, delivery notifications are still generated for this route.



MDIR 17 : 50 percent of maximum messages exceeded

Explanation: 50% of the configured maximum number of deliveries in Message Handler (2000 bydefault) has been reached.











MDIR 30 : Maximum number of messages exceeded, Distress only accepted


11-31

Explanation: The configured maximum number of deliveries in Message Handler (2000 by default)has been reached. The system is only able to accept distress messages. However, deliverynotifications are still generated.



MDIR 40 : 110 percent of max messages exceeded, Distress still accepted

Explanation: The configured maximum number of deliveries in Message Handler (2000 by default)has been exceeded by 10%. The system is only able to accept distress messages. However,delivery notifications are still generated.



MDIR 50 : Reloading message details from LES Database

Explanation: Message Handler has started reloading the old message details from the LESDatabase, for the messages that were live when the Master BAP left Running state. This happensin parallel with handling new message details when the Master BAP reaches Running state untilall the old message details have been reloaded or an error occurs.

Supporting Data: Message details reload counts.


MDIR 51 : All message details reloaded from LES Database

Explanation: Message Handler has successfully reloaded all the old message details from the LESDatabase.



MDIR 52 : Not all message details reloaded from LES Database

Explanation: Message Handler has not successfully reloaded all the old message details from theLES Database. Delivery of the messages for which the message details could not be reloaded willnot be completed until corrective action is taken by HNS. The supporting data indicates how manymessage details were not reloaded, and thus whether the problem needs urgent attention.



MDIR 55 : Reloading delivery statuses from LES Database

Explanation: Message Handler has started reloading the old delivery statuses from the LESDatabase, for the messages that have been delivered remotely by the X.400 or Fax Drivers usingthird-party store-and-forward systems while their message details were not live in the Master BAP.


17th July 2001

11-32

This happens in parallel with handling new delivery statuses when the Master BAP reachesRunning state, once Message Handler has stopped reloading old message details from the LESDatabase, until all the delivery statuses have been reloaded or an error occurs. Then only newdelivery statuses will be handled. Before Message Handler has stopped reloading old messagedetails from the LES Database, new delivery statuses for messages that have been deliveredremotely are created in the LES Database, to be reloaded when their message details are live.

Supporting Data: Delivery statuses reload counts.


MDIR 56 : All delivery statuses reloaded from LES Database

Explanation: Message Handler has successfully reloaded all the old delivery statuses from theLES Database.



MDIR 57 : Not all delivery statuses reloaded from LES Database

Explanation: Message Handler has not successfully reloaded all the old delivery statuses from theLES Database. Although delivery of the messages for which the delivery statuses could not bereloaded may have been completed, generation of delivery notifications for them will not be com-pleted until corrective action is taken by HNS. This may happen if not all the old message detailswere reloaded from the LES Database. The supporting data indicates how many delivery statuseswere not reloaded, and thus whether the problem needs urgent attention or not.



MDIR 60 : Delivery call completion code text not found in LES Database

Explanation: The LES Database does not contain call completion code text for a code assigned toa delivery of a message for which Message Handler is generating a delivery notification. This is aconfiguration error.


Corrective action: contact HNS.

MDIR 70 : Non-actionable bulk message cancellation request received

Explanation: Message Handler has started counting the messages that would have been queuedup for cancellation in response to a non-actionable bulk cancellation request. The supporting dataspecifies which messages would have been bulk cancelled and the request number.

Supporting Data: Bulk cancellation request.

Corrective action: none.

MDIR 71 : Non-actionable bulk message cancellation request completed

Explanation: Message Handler has finished counting the messages that would have been queued


11-33

up for cancellation in response to a non-actionable bulk cancellation request. The supporting dataspecifies how many messages would have been bulk cancelled if the request had been actionableand the request number.

Supporting Data: Bulk cancellation response.


MDIR 75 : Actionable bulk message cancellation request received

Explanation: Message Handler has started queuing up the messages for cancellation in responseto an actionable bulk cancellation request. The supporting data specifies which messages are tobe bulk cancelled and the request number.

Supporting Data: Bulk cancellation request.


MDIR 76 : Actionable bulk message cancellation request queued up

Explanation: Message Handler has finished queuing up the messages for cancellation in responseto an actionable bulk cancellation request. The supporting data specifies how many messages willbe bulk cancelled and the request number.

Supporting Data: Bulk cancellation response.


MDIR 77 : Actionable bulk message cancellation request completed

Explanation: Message Handler has finished cancelling the messages queued up for cancellation inresponse to an actionable bulk cancellation request. The supporting data specifies how manymessages actually were bulk cancelled and the request number.

Supporting Data: Bulk cancellation summary.


MDIR 80 : Message bulk cancelled

Explanation: Message Handler has cancelled a message that was queued up for cancellation inresponse to an actionable bulk cancellation request. The supporting data specifies the ID of themessage that was cancelled and the request number.

Supporting Data: Bulk cancellation ID.


MDIR 81 : Message not bulk cancelled because delivery completed

Explanation: Message Handler has not cancelled a message that was queued up for cancellationin response to an actionable bulk cancellation request because delivery of the message was com-pleted before it could be cancelled. The supporting data specifies the ID of the message that wasnot cancelled and the request number.

Supporting Data: Bulk cancellation ID.


17th July 2001

11-34


MDIR 82 : Message cancelled by operator

Explanation: This event is used to record the details of an operator cancellation.

Supporting Data: MRN and submission time supplied for the cancellation criteria.


MDIR 100 : Message for operator received

Explanation: A message from a mobile addressed to the operator has been received and will bewritten to the operator message log.


Corrective action: The message can be printed on the report printer as described in section8.3.10.

MDIR 105 : Failed to log operator message

Explanation: An error occurred writing an operator message to the operator message log. Theoperator message will not appear in the SOC viewer online operator message report. This is veryunlikely.


Corrective action: take no action for isolated occurrences.

MDIR 135 : Failed to log distress message/alert or land mobile alert

Explanation: An error occurred writing a distress message, distress alert, or land mobile alert tothe distress message log. The distress message will not appear on the alarm printer, in the SOCdistress message forms, or in the SOC viewer online distress message report. This is very un-likely.

Supporting Data: Message ID.

Corrective action: See local instructions for handling distress.

MDIR 140 : Distress EGC message received

Explanation: An EGC distress message has been received and will be written to the distress mes-sage log. The distress message can be viewed on the alarm printer, in the SOC distress messageforms, or in the SOC viewer online distress message report.



MDIR 141 : Distress EGC delivery succeeded

Explanation: An EGC distress delivery has succeeded.



11-35


MDIR 142 : Distress EGC delivery attempt failed

Explanation: An EGC distress delivery attempt has failed. The delivery is being retried.



MDIR 143 : Distress EGC delivery failed

Explanation: An EGC distress delivery has failed.



MDIR 145 : Distress shore-originated message received

Explanation: A shore-originated distress message has been received and will be written to thedistress message log. The distress message can be viewed on the alarm printer, in the SOC dis-tress message forms, or in the SOC viewer online distress message report.



MDIR 146 : Distress shore-originated delivery succeeded

Explanation: A shore-originated distress delivery has succeeded.



MDIR 147 : Distress shore-originated delivery attempt failed

Explanation: A shore-originated distress delivery attempt has failed. The delivery is being retried.



MDIR 148 : Distress shore-originated delivery failed

Explanation: A shore-originated distress delivery has failed.



MDIR 150 : Distress mobile-originated message received

Explanation: A mobile-originated distress message has been received and will be written to thedistress message log. The distress message can be viewed on the alarm printer, in the SOC dis-


17th July 2001

11-36

tress message forms, or in the SOC viewer online distress message report.



MDIR 151 : Distress mobile-originated delivery succeeded

Explanation: A mobile-originated distress delivery has succeeded.



MDIR 152 : Distress mobile-originated delivery attempt failed

Explanation: A mobile-originated distress delivery attempt has failed. The delivery is being retried.



MDIR 153 : Distress mobile-originated delivery failed

Explanation: A mobile-originated distress delivery has failed.



MDIR 155 : Distress alert received

Explanation: A distress alert has been received and will be written to the distress message log.The distress message can be viewed on the alarm printer, in the SOC distress message forms, orin the SOC viewer online distress message report.



MDIR 156 : Distress alert delivery succeeded

Explanation: A distress alert delivery has succeeded.



MDIR 157 : Distress alert delivery attempt failed

Explanation: A distress alert delivery attempt has failed. The delivery is being retried.




11-37

MDIR 158 : Distress alert delivery failed

Explanation: A distress alert delivery has failed.



MDIR 160 : Land mobile alert received

Explanation: A land mobile alert has been received and will be written to the distress message log.The distress message can be viewed on the alarm printer, in the SOC distress message forms, orin the SOC viewer online distress message report.


Corrective action: See local instructions for handling land alerts.

MDIR 161 : Land mobile alert delivery succeeded

Explanation: A land mobile alert delivery has succeeded.



MDIR 162 : Land mobile alert delivery attempt failed

Explanation: A land mobile alert delivery attempt has failed. The delivery is being retried.



MDIR 163 : Land mobile alert delivery failed

Explanation: A land mobile alert delivery has failed.



MSCH 40 : Distress EGC delivery delayed

Explanation: An EGC distress delivery has been delayed in Message Handler for more than acertain period (45 seconds by default). Message Handler is waiting for the delivery time to expireor delivery route resources to become available.



MSCH 41 : Distress EGC delivery stuck active

Explanation: An EGC distress delivery has been in the active queue of the Message Scheduler forlonger than the maximum delivery time for the type of delivery route and the length of the mes-


17th July 2001

11-38

sage. The delivery may be stuck within the delivery driver.


Corrective action: See local instructions for handling distress. Contact HNS.

MSCH 42 : Distress EGC delivery unstuck

Explanation: An EGC distress delivery which may have been stuck within the delivery driver hasnow been dequeued from the Message Scheduler.



MSCH 45 : Distress shore-originated delivery delayed

Explanation: A shore-originated distress delivery has been delayed in Message Handler for morethan a certain period (45 seconds by default). Message Handler is waiting for the delivery time toexpire or delivery route resources to become available.



MSCH 46 : Distress shore-originated delivery stuck active

Explanation: A shore-originated distress delivery has been in the active queue of the MessageScheduler for longer than the maximum delivery time for the type of delivery route and the lengthof the message. The delivery may be stuck within the delivery driver.


Corrective action: See local instructions for handling distress. For deliveries to TDM routes, checkif a large number of active calls on the TDM is causing calls to be pended. If this does not explainthe event, contact HNS.

MSCH 47 : Distress shore-originated delivery unstuck

Explanation: A shore-originated distress delivery which may have been stuck within the deliverydriver has now been dequeued from the Message Scheduler.



MSCH 50 : Distress mobile-originated delivery delayed

Explanation: A mobile-originated distress delivery has been delayed in Message Handler for morethan a certain period (45 seconds by default). Message Handler is waiting for the delivery time toexpire or delivery route resources to become available.




11-39

MSCH 51 : Distress mobile-originated delivery stuck active

Explanation: A mobile-originated distress delivery has been in the active queue of the MessageScheduler for longer than the maximum delivery time for the type of delivery route and the lengthof the message. The delivery may be stuck within the delivery driver.



MSCH 52 : Distress mobile-originated delivery unstuck

Explanation: A mobile-originated distress delivery which may have been stuck within the deliverydriver has now been dequeued from the Message Scheduler.



MSCH 55 : Distress alert delivery delayed

Explanation: A distress alert delivery has been delayed in Message Handler for more than a cer-tain period (45 seconds by default). Message Handler is waiting for the delivery time to expire ordelivery route resources to become available.



MSCH 56 : Distress alert delivery stuck active

Explanation: A distress alert delivery has been in the active queue of the Message Scheduler forlonger than the maximum delivery time for the type of delivery route and the length of the mes-sage. The delivery may be stuck within the delivery driver.



MSCH 57 : Distress alert delivery unstuck

Explanation: A distress alert delivery which may have been stuck within the delivery driver hasnow been dequeued from the Message Scheduler.



MSCH 60 : Land mobile alert delivery delayed

Explanation: A land mobile alert delivery has been delayed in Message Handler for more than acertain period (45 seconds by default). Message Handler is waiting for the delivery time to expireor delivery route resources to become available.



17th July 2001

11-40


MSCH 61 : Land mobile alert delivery stuck active

Explanation: A land mobile alert delivery has been in the active queue of the Message Schedulerfor longer than the maximum delivery time for the type of delivery route and the length of themessage. The delivery may be stuck within the delivery driver.



MSCH 62 : Land mobile alert delivery unstuck

Explanation: A land mobile alert delivery which may have been stuck within the delivery driver hasnow been dequeued from the Message Scheduler.



MSCH 66 : Normal shore-originated delivery stuck active

Explanation: A normal shore-originated delivery has been in the active queue of the MessageScheduler for longer than the maximum delivery time for the type of delivery route and the lengthof the message. The delivery may be stuck within the delivery driver.


Corrective action: For deliveries to TDM routes, check if a large number of active calls on the TDMis causing calls to be pended. If this does not explain the event, contact HNS.

MSCH 67 : Normal shore-originated delivery unstuck

Explanation: A normal shore-originated delivery which may have been stuck within the deliverydriver has now been dequeued from the Message Scheduler.



MSCH 71 : Normal mobile-originated delivery stuck active

Explanation: A normal mobile-originated delivery has been in the active queue of the MessageScheduler for longer than the maximum delivery time for the type of delivery route and the lengthof the message. The delivery may be stuck within the delivery driver.


Corrective action: See MSCH 66.

MSCH 72 : Normal mobile-originated delivery unstuck

Explanation: A normal mobile-originated delivery which may have been stuck within the deliverydriver has now been dequeued from the Message Scheduler.


11-41



Note: For PRC events supporting data is normally included ONLY in the Affected Object field andNOT as part of Supporting Data in the event report.

PRC 1 : Arbiter failure

Explanation: Indicates a problem in the arbiter card.

Supporting Data: BAP.

Corrective action: If reported from only one BAP indicates a communication failure between theBAP and the arbiter, although the arbiter may have failed in such a way that it can only talk to oneBAP. If reported from both BAPs indicates a problem with the arbiter itself. In the latter caseautomatic switchovers will not be possible. Recovery actions include: check cabling and replace ifnecessary, reset arbiter, replace arbiter.

PRC 2 : Arbiter available

Explanation: Arbiter now functional.

Supporting Data: BAP.


PRC 10 : Switchover controller failure

Explanation: Unable to communicate with the switch controller card.

Supporting Data: Physical port.

Corrective action: If reported from only one BAP indicates a communication failure between theBAP and the switch controller, although the switch controller may have failed in such a way that itcan only talk to one BAP. If reported from both BAPs indicates a problem with the switch controlleritself. In the latter case automatic switchovers will not be possible. Recovery actions include:check cabling and replace if necessary, reset switch controller, replace switch controller.

PRC 11 : Switchover controller available

Explanation: Switchover card now functional.

Supporting Data: Physical port.


PRC 20 : FEP Switchover

Explanation: Switchover as a result of operator command or failure detected in master or masterFEP has rebooted.

Supporting Data: Name of new master FEP.



17th July 2001

11-42

PRC 21 : Master FEP failed

Explanation: Master FEP reports a failure.

Supporting Data: Name of master FEP.

Corrective action: Check power supply to FEP, restart the FEP. If fault persists, call DEC main-tenance.

PRC 22 : Standby FEP Failed

Explanation: Standby FEP reported a failure. The system will continue to operate normally butwith no backup should the master FEP fail.

Supporting Data: Name of standby FEP.

Corrective action: Check power supply to FEP, restart the FEP. If fault persists, call DEC main-tenance.

PRC 23 : Master FEP Up

Explanation: Information that the master FEP has successfully completed its startup sequenceand is now ready for use.



PRC 24 : Standby FEP Up

Explanation: Information that the standby FEP has successfully completed its startup sequenceand is now ready for use.

Supporting Data: Name of standby FEP.


PRC 25 : FEP Switch Unit Failure

Explanation: Failure in FEP switch card or communications with the card.


Corrective action: Check indications on switch controller card; if incorrect, try spare in the sameposition, then check cabling. If fault clears after a BAP switchover, call DEC maintenance tocheck the BAP port connected to the switch controller.

PRC 26 : FEP Switch Unit Up

Explanation: FEP switch unit now available.



PRC 27 : Unable to Switch FEP Lines


11-43

Explanation: Switchover card not responding.


Corrective action: Replace switchover card

PRC 28 : Arbiter switch set automatic

Explanation: Arbiter switch is now in the automatic position and can determine which BAP is to bemaster.



PRC 29 : Arbiter switch set manual (BAP-A/BAP-B)

Explanation: Arbiter switch is set manually so either BAP-A or BAP-B is master.


Corrective action: None, this is the result of manual action. But note that in this mode, the BAPsare operating non-redundantly.

PRC 30 : Shadow Disk Set Member Dismounted

Explanation: A member of the shadow disk set has been dismounted.

Supporting Data: Disk name.

Corrective action: None, this is the result of operator action.

PRC 31 : Shadow Disk Set Member Remounted

Explanation: A member of the shadow disk set has been remounted.


Corrective action: None, this is the result of operator action.

PRC 32 : Shadow Disk Set Member Catching up

Explanation: Following remounting of a member of the shadow disk set it has begun to copy overdata from the other member in order for the disks to contain the same data.



PRC 33 : Shadow Disk Set Member Synchronised

Explanation: Following beginning of synchronization with the other member of the shadow setafter a member has been remounted this event reports that the synchronization has now com-pleted.



17th July 2001

11-44


PRC 34 : All Shadow Disk Set Members Dismounted

Explanation: All members of the shadow disk set dismounted. Note that this will mean the LES willlose data which cannot be recovered and the LES will cease to function.


Corrective action: None - this is the result of operator action.

PRC 35 : Quorum Disk Dismounted

Explanation: Quorum Disk dismounted, i.e. removed from the disk configuration within the proces-sors.

Note: if the quorum disk is dismounted when one of the VAXes is not running, i.e. it is neitherMaster or Standby BAP, the cluster configuration will be lost and the system will be put out ofservice.



PRC 36 : Quorum Disk Remounted

Explanation: Quorum Disk Remounted.



PRC 37 : System Disk Unavailable

Explanation: System Disk Unavailable. This will either lead to a degradation of the system or aswitchover.


Corrective action: Call DEC maintenance.

PRC 38 : System Disk Available

Explanation: System Disk Available.



PRC 41 : Master BAP Failed

Explanation: Reported by the standby BAP when it detects the master BAP has failed.

Supporting Data: Name of master BAP.

Corrective action: Restart BAP. If fault persists, call DEC maintenance.


11-45

PRC 42 : Standby BAP Failed

Explanation: Reported by the master BAP when it detects the standby BAP has failed.

Supporting Data: Name of standby BAP.

Corrective action: Restart BAP. If fault persists, call DEC maintenance.

PRC 43 : Master BAP Up

Explanation: Master BAP reports it is now up and running.

Supporting Data: Name of master BAP.


PRC 44 : Standby BAP Up

Explanation: Standby BAP reports it is now up and running.

Supporting Data: Name of standby BAP.


PRC 45 : BAP switchover start

Explanation: Indicates start of a switchover either initiated by operator command or as a result offailure on the BAP.

Corrective action: None, for this event on its own.


PRC 46 : BAP to FEP handshake established

Explanation: Communication between BAP and FEP has once again been restored following anearlier failure. Event DIM 10 may occur before this.



PRC 47 : BAP to FEP handshake failed

Explanation: Indicates loss of communication between BAP and FEP. This will occur if after aperiod of 75 seconds no message has been received by the BAP (FEPs send a message to aBAP indicating it is alive on average every 15 seconds). Additional information will be found inevent DIM 20.


Corrective action: If the FEP has been rebooted, take no action. Otherwise restart the FEP.

PRC 48 : BAP handshake established

Explanation: Communication between the two BAPs, which had earlier been marked as failed,


17th July 2001

11-46

now established.



PRC 49 : Master BAP detects handshake failure

Explanation: The master BAP has sent a message to the standby BAP indicating it is ’alive’ buthas received no such message from the standby BAP.


Corrective action: Investigate the state of the DECNET link between the two BAPs. If OK checkthe standby BAP is running. If standby BAP not running start the standby BAP.

PRC 50 : Standby BAP detects handshake failure

Explanation: As PRC 49 but it is the master BAP that appears to have the problem.


Corrective action: Investigate the state of the DECNET link between the two BAPs. If OK checkthe standby BAP is running. If standby BAP not running start the standby BAP.

PRC 60 : Task Failed

Explanation: Indicates an item of software has failed. A switchover will usually occur if automaticswitchovers are enabled.

Supporting Data: Name of VMS process.

Corrective action: Check the current states of each task by using the BAPOP command ShowState. If the task has not restarted, restart the whole BAP.

PRC 61 : Processor Mode Change

Explanation: Reports a change in mode of a BAP or FEP processor. The modes are: UNKNOWN,IDLE, STANDBY and MASTER.

Supporting Data: Processor, from <mode>, to <mode>.

Corrective action: none for this event in its own right.

PRC 62 : Processor State Change

Explanation: Usually seen as part of the start-up sequence, switchover or failure. Reports statechange for master of standby BAP. The states are: UNKNOWN, INIT, DBSYNC, SYNC,RUNNING, END_RUNNING, FAILED.

Supporting Data: From <state>, to <state>.

Corrective action: none for this event in its own right.

PRC 64 : Task Restarted


11-47

Explanation: Task which failed earlier has restarted.

Supporting Data: Name of task.


PRC 65 : Processor shutdown

Explanation: Orderly shutdown initiated from BAP. Only the event relating to the standby BAP getsreported.

Supporting Data: BAP ID.


PRC 66 : Processor restarted

Explanation: Automatic start of a BAP which has previously failed.

Supporting Data: BAP ID.


PRC 67 : No FEP available for Master Operation

Explanation: The master FEP has failed but switchover is not possible because there is nostandby FEP.


Corrective action: Investigate the failure of both the FEPs. Try restarting each one. If FEPs con-tinue to fail with no other fault indication on the SOC, call DEC maintenance.

PRC 70 : System Disk Full

Explanation: Room is not available on the system disk. Each BAP has its own disk, so perfor-mance on the affected BAP will degrade and eventually not function.


Corrective action: Delete unwanted files from the system disk and restart the BAP.

NOTE: Refer to instructions given in section 12.12.5 for routine and emergency procedures formanagement of system disk space

PRC 71 : System Disk usage fallen below threshold

Explanation: Sufficient room has now been made available on the system disk for it now tooperate normally.



PRC 72 : Shadow set being rebuilt by merging


17th July 2001

11-48

Explanation: A situation has occurred earlier where one member of the shadow set has been of-fline and the system is causing the data from the other disk to be copied to it.



PRC 73 : Virtual Memory is low

Explanation: System resources are insufficient to allow the system to operate efficiently.


Corrective action: Restart the BAP.

PRC 74 : Virtual Memory is available

Explanation: The virtual memory low problem reported earlier has gone away.



PRC 110 : Database Transaction Log has Reached Warning Level

Explanation:

Supporting Data: Perform a BAP switch if recovery does not occur - PRC 111.


PRC 111 : Database Transaction Log Recovered

Explanation:



PRC 112 : Database size has reached Warning Level

Explanation: Database usage has exceeded the level defined by ’DB_SPACE_WARNING’ inPRC$EXE:PRC_CNTL_VALUES.INI



PRC 113 : Database size has recovered

Explanation: Database usage has dropped to below (<DB_SPACE_WARNING> -<DB_SPACE_HYSTERESIS>). Note ’DB_SPACE_HYSTERESIS’ defaults to 1000kb if notdefined in PRC$EXE:PRC_CNTL_VALUES.INI



11-49


PRC 114 : Database size has reached Critical Level

Explanation: Database usage has exceeded the level defined by ’DB_SPACE_CRITICAL’ inPRC$EXE:PRC_CNTL_VALUES.INI.


Corrective action: Try BAP Switch

PRC 115 : Database size is no longer critical

Explanation: Database usage has dropped to below (<DB_SPACE_CRITICAL> -<DB_SPACE_HYSTERESIS>). Note ’DB_SPACE_HYSTERESIS’ defaults to 1000kb if notdefined in PRC$EXE:PRC_CNTL_VALUES.INI. Database usage is still above the ’Warning’ level.



SDC 1 : Satellite FEP start up complete

Explanation: Satellite FEP start up complete. This is raised when the FEP becomes MASTERRunning. After that, the download of configuration data will start. Once this completes, the eventFEP download complete is raised.

Supporting Data:


SDC 11 : TDM Group Operational

Explanation: TDM Group in operation. This event can be filtered, as described in section 11.4.

Supporting Data: Ocean Region, TDM Group ID.


SDC 12 : TDM Group Not Operational

Explanation: TDM Group not in operation. Reason indicated in supplementary data. This eventcan be filtered, as described in section 11.4.

Supporting Data: Ocean Region, TDM Group ID, Supplementary Data. Supplementary Data com-prises a single digit in the range 0 - 5 whose meanings are:

0 - Run Status Not Online1 - No Frame Timing Reference2 - Inconsistent Configuration Data3 - TDM Modulator Not Operational4 - No Signalling Channels5 - TDM Reconfiguring

Corrective action: None for this event on its own, since it could be caused by NCS or operatoraction. Any failure would have another event identifying the cause more precisely.


17th July 2001

11-50

SDC 13 : TDM Group Deconfigured

Explanation: TDM group taken out of service.

Supporting Data: Ocean Region, Chassis ID, Chassis Slot.

Corrective action: Operator should release the TDM group and request allocation again from theNCS.

SDC 21 : Multidrop line Operational

Explanation: Now able to communicate with the channel units over the multidrop line.

Supporting Data: Ocean Region, Multidrop Line.


SDC 22 : No response on Multidrop line

Explanation: no acknowledgement received on the multidrop line between the channel unit con-trollers (satellite driver FEPs) and the channel units.


Corrective action: If only one multidrop line is affected, the possible causes are the BIM on the CUhalf-chassis, the RS-232 switch card for that line on the switchover tray in the CUC rack, or theassociated cabling. If all multidrop lines for one ocean region fail, the possible causes are ageneral failure in the switchover tray in the CUC rack or a general failure, e.g. all power, in thechannel unit rack. If only one channel unit is served by the multidrop line (i.e. only one operationalon the particular half-chassis), the cause could be in the channel unit itself.

SDC 23 : Multidrop line Deconfigured

Explanation: The multidrop line has been taken out of service by operator action.



SDC 31 : Physical CU has become operational

Explanation: Reported towards the end the CU start up sequence and indicates that the channelunit is now available to handle traffic. This event can be filtered, as described in section 11.4.



SDC 32 : Physical CU has been deleted

Explanation: This is raised when a physical channel unit is deleted using the Physical ChannelUnit Definition form.

Supporting Data:



11-51

SDC 33 : Physical CU has reported failure

Explanation: a channel unit has returned a response over the multidrop which indicates that it hasfailed. This event can be filtered, as described in section 11.4.


Corrective action: Check the HEX display on the front of the channel unit. If the fault indicates aninternal failure, change the module. If an external failure is indicated, check the source of thesignal. E.g. if a TDM demod has lost its input, check the TDM Mod; if an ISL demod has lost itsinput, contact the NCS.

SDC 34 : Physical CU failure has been detected

Explanation: The software is not able to communicate with a channel unit.


Corrective action: If this is reported for one channel unit only, the channel unit itself is most likelyat fault (isolated instances can be ignored). If a group of channel units in one half chassis arereported as faulty, communications over the multidrop line from the CUC FEP to the channel unitrack has been lost. This can be caused by a failure in the RS-232 switch card in the CUCswitchover tray in the CUC rack or in the BIM on the rear of the CU chassis.

SDC 41 : MTM is Online

Explanation: Master timing module online.

Supporting Data: Ocean Region, ALD Line Number.


SDC 42 : MTM Clock is OK

Explanation: MTM clock which had previously failed now ok.



SDC 43 : MTM Clock Failed

Explanation: Failure reported, via the ASM, of the master timing module.


Corrective action: Check MTM, and replace if necessary, as described in the Channel Unit RackMaintenance Manual.

SDC 44 : MTM Control switch changed to Auto Mode

Explanation: The manual/auto mode switch on the front of the ASM has been changed to Automode.



17th July 2001

11-52

Corrective action: None - this is a result of operator action

SDC 45 : MTM Control switch changed to Manual Mode

Explanation: The manual/auto mode switch on the front of the ASM has been changed to Manualmode.


Corrective action: None - this is a result of operator action

SDC 51 : Control Rack Power Supply OK

Explanation: Control Rack Power Supply which had earlier failed now ok.



SDC 52 : Control Rack Power Supply Failed

Explanation: May need to replace power supply.


Corrective action: Check input to power supply. Follow procedures defined in the Channel UnitMaintenance Manual.

SDC 61 : Control Rack Blower OK

Explanation: Control Rack Blower which had previously failed now OK.



SDC 62 : Control Rack Blower Failed

Explanation: One of the 6 blowers in the Channel Unit rack has failed.

Supporting Data: Ocean Region, Alarm Detector Line Number.

Corrective action: Check if any of the blowers are operational. If some are working, replacementof failed blower is necessary. (The rack can continue to operate with one failed blower for sometime, depending on the ambient temperature.) If no blowers are operational, check the powerwiring to the PSUs at the bottom of the rack. See the Channel Unit Maintenance Manual fordetails.

SDC 71 : Communications with Alarm Switchover module established

Explanation: Communications which had previously failed now established.

Supporting Data: Ocean Region.



11-53

SDC 72 : Communications with Alarm Switchover module failed

Explanation: No communications over the link from the channel unit controller to the ASM on thechannel unit rack.

Supporting Data: Ocean Region.

Corrective action: Check indication on ASM. If ’SCP fail’ LED is lit, the fault is either in the CUCFEP or the connection between the FEP and the ASM via the switchover tray. If the SCP fail LEDis not lit and the summary alarm indications agree with the display on the SOC, replace the ASM.

SDC 81 : ISL Link Operational

Not used.

SDC 82 : ISL Link has failed

Not used.

SDC 91 : TDM Timing CU is operational

Explanation: TDM Timing CU which had previously failed now operational.

Supporting Data: Ocean Region, TDM Group ID, Chassis ID, Chassis Slot, Signal Level,Signal/Noise Ratio.

Corrective actin : None

SDC 92 : TDM Timing CU has failed

Explanation: The TDM demodulator is unable to detect the framing pattern. This is transmittedfrom the associated TDM modulator, via the satellite.

Supporting Data: Ocean Region, TDM Group ID, Chassis ID, Chassis Slot, Signal Level,Signal/Noise Ratio.

Corrective action: Check that the TDM modulator is showing the correct indications. Check if theISL is operational - this shares the uplink and downlink chains.

SDC 101 : Signalling Channel Operational

Explanation: Signalling Channel was previously not operating now is. This event can be filtered,as described in section 11.4.

Supporting Data: Ocean Region, TDM Group ID, Signal Channel.


SDC 102 : Signalling Channel Not Operational

Explanation: Demodulator not operational. This event can be filtered, as described in section11.4.

Supporting Data: Ocean Region, TDM Group ID, Signal Channel, Extra Data.

Corrective action: Check Channel Unit display. If correct, take no further action. If incorrect,


17th July 2001

11-54

replace module.

SDC 103 : Signalling Channel Deconfigured

Explanation: That channel no longer part of the TDM group.

Supporting Data: Ocean Region, TDM Group ID, Signal Channel.


SDC 111 : PCU assigned to a LCU

Explanation: Physical channel unit now configured as SIG, MSG, TDM, or ISL (TX/RX) channel.This event is raised when a redundancy switchover takes place or when a TDM group is assigned.



SDC 112 : PCU deassigned from a LCU

Explanation: Physical channel unit no longer assigned a specific usage.



SDC 113 : LCU in service

Explanation: Logical Channel Unit now available for use.



SDC 114 : LCU out of service

Explanation: Logical Channel Unit no longer available for use.



SDC 115 : LCU taken out for maintenance

Explanation: The operator has taken an LCU out of service an put it in the maintenance state.



SDC 116 : LCU Undefined

Explanation: The operator has deleted the definition of an LCU.



11-55


SDC 117 : No unassigned PCU in the sparing pool

Explanation: All the channel units in the sparing pool assigned a specific use, i.e. SIG, MSG, TDM.

Supporting Data: Ocean Region, Pool ID, Pool Name.

Corrective action: Assign another PCU to the sparing pool

SDC 118 : PCU deleted from sparing pool

Explanation: Raised when PCU deleted from sparing pool using the Channel Unit Spare PoolDefinition SOC form.

Supporting Data: Ocean Region, Pool ID, Pool Name, Chassis ID, Chassis Slot.


SDC 119 : No PCUs are available to assign To LCU

Explanation: An attempt has been made to assign a physical channel unit to one of SIG, MSG,TDM, or ISL (TX/RX) but none are available.

Supporting Data: Ocean Region, Logical Channel Unit ID.

Corrective action: Obtain another PCU.

SDC 120 : No LCUs to assign to PCU

Explanation: This is raised if no LCU can be found when adding a PCU to a sparing pool.



SDC 121 : Spare PCU Found For LCU assignment (PCU ID)

Explanation: Successfully assigned a PCU to LCU.

Supporting Data: Ocean Region, Logical Channel Unit ID, Chassis ID, Chassis Slot.


SDC 122 : LCU Spare found For PCU (LCU ID)

Explanation: This is raised if an LCU is found when adding a PCU to a sparing pool. This is thecomplement of event SDC 120.

Supporting Data: Ocean Region, Logical Channel Unit ID, Chassis ID, Chassis Slot.


SDC 123 : ISL Demodulator has lost the carrier

Not used.


17th July 2001

11-56

SDC 124 : ISL Demod has acquired the carrier

Not used.

SDC 125 : CU Summary Status

Explanation: Report from a channel unit declaring its status.

Supporting Data: Ocean Region, Chassis ID, Chassis Slot, Status, Enabled Y/N, Data OverrunY/N, Timing Lost Y/N.

Corrective action: None - for record only.

SDC 130 : Timing TDM Rx Channel has been assigned a frequency

Explanation: The software will search for a frequency to assign the TDM Demodulator which isresponsible for the frame timing within the channel unit rack, if no frequency has been assigned,or if the TDM modulator has been de-assigned. This event indicates that the search has beensuccessful.

Supporting Data:


SDC 131 : Frequency of Timing TDM Rx Channel has changed

Explanation: The software will search for a frequency to assign the TDM Demodulator which isresponsible for the frame timing within the channel unit rack, if no frequency has been assigned,or if the TDM modulator has been de-assigned. This event indicates that the search has occurredand been successful.

Supporting Data:


SDC 132 : Frequency of Timing TDM Rx Channel has been deassigned

Explanation: The software will search for a frequency to assign the TDM Demodulator which isresponsible for the frame timing within the channel unit rack, if no frequency has been assigned,or if the TDM modulator has been de-assigned. This event indicates that the search has not beensuccessful.

Supporting Data:

Corrective action: This event should only be raised if the TDM Modulator is not assigned.

SDC 140 : Message Channel Operational

Explanation: Message channel previously not operational now is.

Supporting Data: Ocean Region, TDM Group ID, Message Channel.


SDC 141 : Message Channel Not Operational


11-57

Explanation: Message channel previously operational no longer is. (Confirm this by checkingchannel unit display.)



SDC 142 : Message Channel Deconfigured

Explanation: Message Channel has been taken out of the TDM group.



SDC 160 : External Alarm Port ON

Explanation: The ASM module on the channel unit rack monitors a number of places in the CUCand TIF racks, as indicated in the supporting data. This event is raised when the alarm conditionon any of these points is cleared.

Supporting Data: Ocean Region, one of the following:

"Control rack PSU OK" - this refers to the CU rack power supplies"Control rack blower OK" - this refers to the CU rack blower"CU S/O tray PSU OK","CU S/O tray Watchdog OK","Arbiter tray PSU OK","Arbiter tray Watchdog OK","Arbiter CPU Alarm Off","Telex S/O tray PSU OK","Telex S/O Watchdog OK"

The remaining data can be ignored.

Corrective action: None - this indicates that the alarm condition has cleared

SDC 161 : External Alarm Port OFF

Explanation: The ASM module on the channel unit rack monitors a number of places in the CUCand TIF racks, as indicated in the supporting data. This event is raised when the alarm conditionon any of these points is detected.

Supporting Data: Ocean region, one of the following:

"Control rack PSU OK" - this refers to the CU rack power supplies"Control rack blower OK" - this refers to the CU rack blower"CU S/O tray PSU failure","CU S/O tray Watchdog timeout","Arbiter tray PSU failure","Arbiter tray Watchdog timeout","Arbiter CPU Alarm On","Telex S/O tray PSU failure","Telex S/O Watchdog timeout"

The remaining data can be ignored.


17th July 2001

11-58

Corrective action: investigate the indicated fault and take action as described in the Channel UnitMaintenance Manual or the CUC and TIF Rack Maintenance Manual according to the location ofthe fault.

SOI 0 : SOC failure

Explanation: The connection from a BAP to a SOC workstation has been lost. Several watchdogprobe messages are expected from each workstation every minute. No probe messages havebeen received within one minute.


Corrective Action: Examine the workstation concerned to check if it has shutdown.

SOI 1 : SOC start up complete

Explanation: A connection has been established from a BAP to a SOC workstation.


Corrective Action: None

SOI 10 : SOC Form Request

Explanation: Every time a SOC form operation is requested by an operator this event is raised toindicate

Supporting Data: "SOI HAND ’x’.Form: ’y’,Function: ’z’ Data: "

where ’x’ = the number of the window that has requesteda SOC form.

’y’ = Current position in menu structure.’z’ = The operation being performed by the operator,

e.g Select, Modify etc.


SOI 20 : Attempt to exceed maximum number of SOC Logons

Explanation: Each SOC can have up to four windows open. This event is raised if an attempt ismade to exceed the maximum allowed number of SOC windows open. This is unlikely to occurand is a only transient situation.


Corrective Action: Wait a short amount of time and try to logon again. If it still occurs, removeunwanted windows.

TLX 0 : No Leased Line call connect signal received

Explanation: Other end did not respond to outgoing seize.

Supporting Data: Circuit number.

Corrective Action: Check equipment at other end of line.


11-59

TLX 1 : Clear confirmation was not received within the time required

Explanation: After a call, the clearing sequence from the far exchange was not completed.


Corrective Action: The most likely cause is that the circuit was backward busied after the callfinished.

TLX 2 : Station closed. (Leased Line No Clear Confirmation)

Explanation: A leased line has been held at third condition (0v) for greater than 50ms.



TLX 3 : Clear confirmation was received after no clear confirmation

Explanation: The line was returned to service after event TLX 1. Clear confirmation was receivedlater than expected.


Corrective Action: The circuit will most likely be backward busied, and events for that condition willprobably be raised at the same time as this event.

TLX 4 : Circuit busied for more than the limit defined

Explanation: The circuit has remained busy after a call has completed for more than the timedefined.


Corrective Action: Check distant end of circuit.

TLX 5 : Circuit no longer busied after limit exceeded

Explanation: The circuit has returned to service after event TLX 4



TLX 6 : Transmitted threshold number of retests has been exceeded

Explanation: A circuit has been in the retest state for a sufficient length of time for the limit oftransmitted retests to be exceeded.



TLX 7 : Retests reverted to normal since exceeded threshold occurred

Explanation: The circuit has returned to service after event TLX 6


17th July 2001

11-60



TLX 8 : The route is not available

Explanation: All the circuits on a route are out of service.

Supporting Data: route number.

Corrective Action: This could either be by operator action at the ACSE or by backward busying ofall the circuits from the far-end exchange.

TLX 9 : An Out of Service request has been completed

Explanation: An operator OOS or FOS request on the appropriate circuit management form hasbeen completed.



TLX 12 : Received threshold number of retests has been exceeded

Explanation: The retest sequence for telex circuits involves five attempts at either 60 or 72 secondintervals (set on the Telex Reattempt Table) followed by five attempts at 5 or 6 minute intervals,followed by an infinite number of attempts at 30 or 36 minute intervals. An alarm is raised after 10attempts.

Note: circuit remains in service throughout.


Corrective Action: Check equipment at far end of line.

TLX 13 : Retest threshold received, but circuit receiving normal call

Explanation: The circuit has returned to normal use after event 12.



TLX 14 : Terrestial FEP failure

Explanation: A TIC has failed.

Supporting Data: TIC number.

Corrective Action: Restart the TIC. If fault persists, call DEC maintenance.

TLX 16 : Terrestrial FEP switchover started

Explanation: A TIC switch has started.

Supporting Data: The TIC number.


11-61

Corrective Action: None for this event on its own.

TLX 17 : Terrestrial FEP switchover complete (Standby FEP now Master)

Explanation: A TIC switch has completed.

Supporting Data: The TIC number.

Corrective Action: None for this event on its own.

TLX 18 : Test call initiated over circuit

Explanation: For an outgoing test call, (a call originated by a test mobile), this event is raised whenthe line is seized. For an incoming call this event is raised when the selection information indicatesthat the call is to a test mobile.



TLX 19 : Test call connected (or MRN assigned over circuit)

Explanation: For an outgoing test call, this event is raised when the call connect signal is received.For an incoming call the event is raised when a MRN has been assigned to the call. This is at thepoint where an incoming answerback has been received.

Supporting Data: Circuit number and MRN.


TLX 20 : Test call completed over circuit

Explanation: The test call has been completed.

Supporting Data: Circuit number, MRN and call completion code.


TLX 21 : Severe protocol violation detection in the circuit

Explanation: A severe protocol violation has been detected on a telex circuit.

Supporting Data:

Corrective Action: Isolated incidences can be ignored, but repeated occurrences indicate a faulteither in the ACSE or in the equipment at the switching centre to which the circuit is connected.

TLX 22: Route is now available

Explanation: One or more circuits on a route have been brought back into service. Also raised onstartup and switchover.

Supporting Data: Route number.



17th July 2001

11-62

TLX 23 : Circuit is now in service and available

Explanation: INS request completed or automatic recovery from failure (e.g. TLX 21) completed.



UTL 1 : Utility message text pool exhausted.

Explanation:

Supporting Data:

Corrective Action: Contact HNS

XCCC 0 : Internal protocol error

Explanation: Dialogue error contravening X25 protocols. Action depends on reason code.

Supporting Data: Reason Code.

Corrective Action:

XCCC 1 : X25 configuration error

Explanation: Discrepancy between LES database and X25 hardware configuration. The support-ing data describes the nature of the configuration error. If a line error is detected XCCC 3 will beraised and, if available, an alternative line will be used.

Supporting Data: Data Item(s) Affected.

Corrective Action: Requires adjustment to the LES database as indicated in Supporting Data.

XCCC 3 : X25 line failed

Explanation: X25 call has failed due to failure in network.


Corrective Action: Action depends on reason code. In addition a DEMSA switchover sequencemay be initiated.

XCCC 4 : X25 line available

Explanation: Line which had previously failed now available for use.



XCCC 5 : No LCNs available

Explanation: Usually occurs in a load situation where for a period the system cannot handle anymore calls.


11-63

Supporting Data: Indicates whether incoming or outgoing.

Corrective Action:

XCCC 6 : DEMSA failure

Explanation: DEMSA has failed.

Supporting Data: DEMSA name and outcome of switchover attempt.

Corrective Action: Attempt to restart the DEMSA. If this is not successful, call out DECMaintenance.

XCCC 7 : DEMSA start up complete

Explanation: Appears when DEMSA is restarted.

Supporting Data: DEMSA name.

Corrective Action: No action

XCCC 8 : DEMSA switchover started

Explanation: Appears as a result of operator command or master failure.

Supporting Data: DEMSA pair name and which physical node in pair is to be master.

Corrective Action: No action for this event on its own.

XCCC 9 : DEMSA switchover complete

Explanation: Successful completion of DEMSA switchover sequence.

Supporting Data: DEMSA pair name and which physical node in pair is now master.

Corrective Action: No action

XCCC 10 : DTE not compatible

Explanation: One of the users connecting to the LES has an incompatible configuration to that ofthe LES e.g. maximum packet size.

Supporting Data: The supporting data depends on how the user’s configuration is incompatiblewith that of the LES. The returned message will be a brief description, followed by supporting datawhich may include: Diagnostic Code, Cause Code, Task ID, Remote DTE, DNID or Originator’sAddress.

Corrective Action: Contact user to arrange for change to his configuration.

XCCC 11 : PSDN network failure

Explanation: The network external to the LES has failed.

Supporting Data: Reason code.

Corrective Action: Contact PSDN network operator.


17th July 2001

11-64

XCCC 12 : Remote protocol error

Explanation: X25 call has failed due to failure in network. Unlike with "Internal protocol error" theproblem is at the end remote from the LES.


Corrective Action: Contact network operator and give him the reason code which is included in theevent.

XCCC 14 : Fatal internal error

Explanation: An unexpected occurrence has been detected in the LES software.

Supporting Data: Identity relating to location of failure.

Corrective Action: Perform switchover and then system restart if the system does not recover.Inform HNS.

XCCC 15 : X25 line out of service

Explanation: X25 line put out of service due to X25 problems detected.

Supporting Data: Physical Line ID.

Corrective Action: Check line, and check distant end. When satisfied that the fault no longer ex-ists, manually put the line back into service.

XCCC 16 : X25 Driver entered failed state

Explanation: A fatal error has occurred in the LES software, causing the X25 driver to fail and anautomatic BAP switchover to be initiated. Or, the X25 driver has been instructed to fail during aBAP switchover or BAP stop.

Supporting Data: Depends on failure.

Corrective Action: Check service is restored after the BAP switchover or restart.

XCCC 17 : X25 driver entered dbsync state

Explanation: Part of startup sequence. Indicates database has been synchronized.



XCCC 18 : X25 driver entered init state

Explanation: Part of startup sequence.



XCCC 19 : X25 driver entered ready state


11-65

Explanation: Part of startup sequence.



XCCC 20 : X25 driver entered Running state

Explanation: Part of startup sequence. Indicates X25 driver is now ready to accept calls.



XCCC 21 : X25 driver become Master

Explanation: X25 driver has just become Master



XCCC 22 : X25 driver entered Standby state

Explanation: X25 driver has just become Standby



XCCC 23 : X25 driver entered Idle state

Explanation: X25 driver has just entered the Idle state



XCCC 24 : No storage available

Explanation:



XCCC 25 : X25 driver entered End Running state

Explanation: Part of switchover sequence. Indicates old master no longer running.



XCCC 26 : Test Call Initiated


17th July 2001

11-66

Explanation: Call has been received to/from a test mobile.

Supporting Data: The text "Incoming Test Message".


XCCC 27 : Test Call Completed

Explanation: Call has been delivered to/from test mobile.

Supporting Data: Call Completion Code.


XCCC 28 : Immediate Forwarding Facility Congested

Explanation: All channels for the route are active.


Corrective Action: Provide more channels.

XCCC 29 : Immediate Forwarding Facility Congestion Cleared

Explanation: The previously reported congestion condition has now cleared.



XCCC 30 : Immediate Forwarding Channel Congested

Explanation: Cannot get through on specific channel.

Supporting Data: Route id, X121 address.


XCCC 31 : Immediate Forwarding Channel Congestion Cleared

Explanation: The previously reported congestion condition has now cleared.



XCCC 32 : Immediate Forwarding Delivery Failed

Explanation: Cannot get through to a specific routes. See also alarms 35 and 36

Supporting Data: Address.


XCCC 33 : Driver Memory Resource Shortage During DNID Retrieval


11-67

Explanation: Storage error exceptions occurring during DNID Retrievals indicate resourceshortages in the X.25 Driver process.


Corrective Action: Monitor Resource

XCCC 34 : Zero Length Message

Explanation: A banner file may be ’empty’

Supporting Data:

Corrective Action: Check Banner Defn.

XCCC 35 :Forward Only Immediate Forwarding Failed

Explanation: This alarm will be raised on the first delivery failure to a DNID for forward-only. Theexisting minor alarm ’32’ applies for forward-or-store). Once raised, no further failure alarms willbe raised for that DNID during the current ’outage’ Alarming is based on DNIDs, not destinationaddresses.

Supporting Data: Delivery address, DNID

Corrective Action: Check Remote DTE

XCCC 36 : Immediate Forwarding Succeeded

Explanation: This alarm will be raised indicating the first successful delivery following the raisingof alarm ’35’. After which, the first failure alarm (’32’ or ’35’) will be raised again if/when anotherfailure occurs.

Supporting Data: Delivery address, DNID

Corrective Action: None required

11.3 Call Failures on the Satellite Side

The supporting information associated with calls which fail on the satellite side contains furtherdetails which enable the operator to know exactly how the call failed. These details are shownunder two fields :

• state

• event

The call completion codes relevant are 800-899 for failures and 50-59 for success.

The following are the protocol states which can be shown :

STATE 1: The MES is not in the supported ocean region.

STATE 2: The MES is in the supported ocean region.

STATE 3: Wait (MES Assignment Request ISL packet received from NCS but LES iscongested).

STATE 4: Wait for congestion (MES Assignment Request SIG packet received but LES


17th July 2001

11-68

is congested).

STATE 6: The MES is in the supported region and an individual poll has been sent to theNCS.

STATE 61: Wait (TEST) (Waiting for MES during the Performance Verification Test)

STATE 62: Waiting for Distress Alert Test during the Performance Verification Test.

STATE 71: Wait for NCS (Announce) (Waiting for NCS during the Announcementroutine).

STATE 72: Wait for MES reply (Announce) (Waiting for MES during the Announcementroutine).

STATE 73: Waiting for NCS during the Announcement routine and Announcement hasbeen cancelled.

STATE 75: Wait for NCS (Distress) (Waiting for NCS during the Distress routine).

STATE 90: Waiting for CUC FEP during the Ship to Shore routine.

STATE 91: Waiting for CUC FEP during the Shore to Ship routine.

STATE 92: Waiting for CUC FEP during the Performance Verification Test routine.

The following are the events defined in the software (Ship Transfer Finite State Machine).

The notation is E <source> <identifier>, where <source> is single letter indicating the source of theevent. The values are as follows:

• N : NCS packet from ISL Control;

• S : MES Sig packet from CUC;

• T : Timeout;

• C : CUC Status Information;

• A : Activated Call from the message director;

• D : Demand Assignment event.

The following events are associated with incoming ISL packet received from the NCS:

EN01 - Commission RequestEN02 - Message Status RequestEN03 - MES Assignment RequestEN04 - MES Status RequestEN05 - Test RequestEN06 - MES StatusEN07 - RegistrationEN08 - DistressEN09 - MES Forced ClearEN10 - Distress AckENCS - General NCS packet

EN20 - TDM Request ResponseEN21 - TDM Release RequestEN22 - TDM Request Acknowledgement


11-69

The following events are associated with incoming MES SIG packet :

ES01 - Announcement ResponseES02 - Assignment ResponseES03 - ClearES04 - Distress AlertES05 - Distress Alert TestES06 - Forced ClearES07 - Message Status RequestES08 - Transfer Status RequestES09 - Assignment RequestES10 - Data ReportESIG - General SIG packet

The following are other events handled by MCM. These are not generally associated with anyparticular incoming packet.

ET01 - Timer 1 expiresET02 - Timer 2 expiresET03 - Timer 3 expiresET04 - Timer 4 expires

EC01 - CUC statistics indicate congestion clearedEC02 - CUC message receivedEC03 - CUC call status information

EA01 - MDir activates new ship bound callEA02 - MDir activates Individual Poll callEA03 - MDir activates Confirmation callEA04 - MDir activates Test Request call

ED01 - TDM being used for ship transferED02 - TDM released from ship transferED03 - TDM now operational

The error codes used are defined as seven digit values. In the case of a protocol errors, thevalues indicate the State and type of event that has been received.

Error Code = abbbbbbwhere

a=0 - No Errorbbbbbb=0 - No Error

a=1 - Specific Protocol Errorbbbbbb = ccdeef

wherecc=stated=1 N events (from ISL Control)d=2 S events (from CUC)d=3 T events (Timeouts)d=4 C events (CUC Status Information)d=5 A events (from Message Director)d=6 D events (Demand Assignment Event)ee=event number (general=99)f=error number


17th July 2001

11-70

a=2 - General Protocol Errorbbbbbb = error number

a=3 - CUC Errorbbbbbb = error number

Use the list below to determine the meaning of the error code.

No_Error := 0000000;

Pre-FSM State Errors

MCM_Input_Incorrect_Ocean_Region 1000011

State SS01 Errors - MES not in OR

MCM_SS01_EN01_MDIR_Error 1011011MCM_SS01_EN01_Already_Commissioned 1011012MCM_SS01_EN01_Mobile_Not_Registered 1011013MCM_SS01_EN03_SES_Not_Logged_In 1011031MCM_SS01_EN07_Unexpected_Status_In_Registration 1011071MCM_SS01_EN09_SES_Not_Logged_In 1011091MCM_SS01_ES09_Sub1_Cannot_Allocate_TDM_Group 1012091MCM_SS01_ES09_SES_Not_Logged_In 1012092MCM_SS01_ES09_Mobile_Not_Registered 1012093MCM_SS01_ES09_Mobile_Barred 1012094MCM_SS01_ES09_Sub2_Login_Failed_PVT 1012095MCM_SS01_EC01_Cant_Get_Event 1014011MCM_SS01_EA04_SES_Commissioned 1015041MCM_SS01_EA04_No_TDM 1015042MCM_SS01_EA04_No_Call 1015043MCM_SS01_EA04_Cannot_Allocate_TDM_Group 1015044MCM_SS01_EA04_No_SES 1015045MCM_SS01_EA04_Standalone 1015046MCM_SS01_EAIO_Not_In_OR 1015991

State SS02 Errors - MES is in OR

MCM_SS02_EN03_Bad_SES_Reply 1021031MCM_SS02_EN03_No_Pending_Event 1021032MCM_SS02_EN03_Announce_Fail 1021033MCM_SS02_EN03_Cannot_Allocate_TDM_Group 1021034MCM_SS02_EN03_Login_Failed_Announce 1021035MCM_SS02_EN03_Sub4_Login_Failed_Message 1021036MCM_SS02_EN05_Test_Req_MDIR_Err 1021051MCM_SS02_EN06_Unexpected_Mobile_Status 1021061MCM_SS02_EN07_Unexpected_Status_In_Registration 1021071MCM_SS02_ES09_Sub1_Cannot_Allocate_TDM_Group 1022091MCM_SS02_ES09_Sub2_Login_Failed_Message 1022092MCM_SS02_EC01_Cant_Get_Deferred_Event 1024011MCM_SS02_EA01_Sub2_Login_Failed_Message 1025010MCM_SS02_EA01_No_TDM_Deferred 1025011MCM_SS02_EA01_Cannot_Allocate_TDM_Group 1025012MCM_SS02_EA01_SUB1_Deferred_Mobile_Calling 1025013MCM_SS02_EA01_SUB1_Deferred_Mobile_Test 1025014MCM_SS02_EA01_Bad_SES_Reply 1025015


11-71

MCM_SS02_EA01_No_Pending_Event 1025016MCM_SS02_EA01_Announce_Fail 1025017MCM_SS02_EA01_Unsuccessful_Transfer 1025018MCM_SS02_EA01_Login_Failed_Announce 1025019MCM_SS02_EA04_PVT_Deferred_No_TDM 1025041MCM_SS02_EA04_No_Call_Record_For_PVT 1025042MCM_SS02_EA04_Cannot_Allocate_TDM_Group 1025043MCM_SS02_EA04_No_SES 1025044MCM_SS02_EA04_Standalone 1025045

State SS03 Errors - WAIT

MCM_SS03_EN06_Bad_Status 1031061MCM_SS03_EN07_Unexpected_Status_In_Registration 1031071MCM_SS03_EN08_NCS_Distress 1031081MCM_SS03_EN09_NCS_Forced_Clear 1031091MCM_SS03_ES04_Distress 1032041MCM_SS03_ES08_SES_Timeout 1032081

State SS04 Errors - WAIT for congestion

MCM_SS04_EN06_Bad_Status 1041061MCM_SS04_EN07_Unexpected_Status_In_Registration 1041071MCM_SS04_EN08_NCS_Distress 1041081MCM_SS04_EN09_NCS_Forced_Clear 1041091MCM_SS04_ES04_Distress 1042041MCM_SS04_ES06_Forced_Clear 1042061MCM_SS04_ES08_SES_Timeout 1042081MCM_SS04_ESIG_Bad_SES_Reply 1042991

SS06 Errors - MES in OR and an individual poll has been sent to the NCS

MCM_SS06_EN06_Not_In_OR 1061061MCM_SS06_EN07_Unexpected_Status_In_Registration 1061071MCM_SS06_EN08_NCS_Distress 1061081MCM_SS06_ES04_Distress 1062041MCM_SS06_ET03_NCS_Timeout 1063031

State SS61 Errors - Wait (TEST)

MCM_SS61_EN08_NCS_Distress 1611081MCM_SS61_EN06_Ship_Link_Lost 1611061MCM_SS61_EN07_Unexpected_Status_In_Registration 1611071MCM_SS61_ES04_Distress 1612041MCM_SS61_ES09_Ship_Shore 1612091MCM_SS61_ES09_Sub1_Login_Failed_PVT 1612092MCM_SS61_ET02_Timeout 1613021

State SS62 Errors - Wait for Distress Test (TEST)

MCM_SS62_EN07_Unexpected_Status_In_Registration 1621071MCM_SS62_EN08_NCS_Distress 1621081MCM_SS62_ES04_Distress 1622041MCM_SS62_ET02_Timeout 1623021

State SS71 Errors - Wait for NCS (Announce)


17th July 2001

11-72

MCM_SS71_EN06_Not_In_OR 1711061MCM_SS71_EN06_No_TDM 1711062MCM_SS71_EN07_Unexpected_Status_In_Registration 1711071MCM_SS71_EN08_NCS_Distress 1711081MCM_SS71_EN09_NCS_Forced_Clear 1711091MCM_SS71_ES04_Distress 1712041MCM_SS71_ES06_Forced_Clear 1712061MCM_SS71_ET03_NCS_Timeout 1713031

State SS72 Errors - WAIT for SES reply (Announce)

MCM_SS72_EN06_Bad_Status 1721061MCM_SS72_EN07_Unexpected_Status_In_Registration 1721071MCM_SS72_EN08_NCS_Distress 1721081MCM_SS72_ES04_Distress 1722041MCM_SS72_ES06_Forced_Clear 1722061MCM_SS72_ESIG_Bad_SES_Reply 1722991MCM_SS72_ET02_SES_Timeout 1723021

State SS73 Errors - WAIT for NCS Cancel (Announce)

MCM_SS73_EN06_Bad_Status 1731061MCM_SS73_EN07_Unexpected_Status_In_Registration 1731071MCM_SS73_EN08_NCS_Distress 1731081MCM_SS73_ES04_Distress 1732041MCM_SS73_ES06_Forced_Clear 1732061MCM_SS73_ET03_Cancel_Announce_Failure_After_Retries 1733031

State SS75 Errors - WAIT for NCS (Distress)

MCM_SS75_ET03_NCS_Timeout 1753031

State SS90 Errors - WAIT for CUC FEP (Mobile to Shore)

MCM_SS90_EN07_Unexpected_Status_In_Registration 1901071MCM_SS90_EN08_NCS_Distress 1901081MCM_SS90_EN09_NCS_Forced_Clear 1901091MCM_SS90_ES04_Distress 1902041MCM_SS90_ES08_Transfer_Status_Request 1902042MCM_SS90_ET01_No_Response_From_CUC 1903011MCM_SS90_ET02_No_Abort_Call_Report 1903021

State SS91 Errors - WAIT for CUC (Shore to Ship)

MCM_SS91_EN06_SES_Idle 1911061MCM_SS91_EN07_Unexpected_Status_In_Registration 1911071MCM_SS91_EN08_NCS_Distress 1911081MCM_SS91_EN09_NCS_Forced_Clear 1911091MCM_SS91_ES04_Distress 1912041MCM_SS91_ES08_Transfer_Status_Request 1912042MCM_SS91_ET01_No_Response_From_CUC 1913011MCM_SS91_ET02_No_Abort_Call_Report 1913021

State SS92 Errors - WAIT for CUC (TEST)

MCM_SS92_EN06_Unexpected_SES_Status 1921061


11-73

MCM_SS92_EN07_Unexpected_Status_In_Registration 1921071MCM_SS92_EN08_NCS_Distress 1921081MCM_SS92_ES04_Distress 1922041MCM_SS92_ES08_Transfer_Status_Request 1922042MCM_SS92_ET01_No_Response_From_CUC 1923011MCM_SS92_ET02_No_Abort_Call_Report 1923021MCM_SS92_EC03_Bad_CUC_Test_Res 1924031

General Errors

MCM_TEST_SUB2_Announcement 2000100MCM_TEST_SUB2_Login_Failed_Announce 2000101MCM_TEST_SUB2_Not_In_OR 2000200MCM_TEST_SUB2_Bad_SES_Reply 2000300MCM_TEST_SUB2_No_Pending_Event 2000400MCM_TEST_SUB3_Shore_Ship 2000500MCM_TEST_SUB6_Login_Failed_PVT 2000501MCM_Announce_No_Resource 2000600MCM_Bad_State_Event 2000700MCM_Ship_Link_Lost 2000800MCM_No_Resource 2000900MCM_Aborted_By_Operator 2001000

MCM_Internal_Error 2001200MCM_Invalid_Ship_Request 2001300MCM_Invalid_Msg_Size 2001400MCM_Invalid_Address_Format 2001500MCM_Invalid_Address_Extension 2001600MCM_No_Call_Record_For_Distress 2001700

MCM_ADV_Invalid_F69_Syntax 2010000MCM_ADV_Invalid_U80_Syntax 2010100MCM_ADV_Invalid_Mobile_Number_Syntax 2010200MCM_ADV_Unknown_Mobile_Number 2010300MCM_ADV_Invalid_Ocean_Region_Syntax 2010400MCM_ADV_Unknown_Ocean_Region 2010500MCM_ADV_No_Route_Available 2010600MCM_ADV_Invalid_PSTN_Country_Code 2010700MCM_ADV_Invalid_PSTN_Ext_Syntax 2010800MCM_ADV_Unknown_PSTN_Ext 2010900

MCM_ADV_Invalid_PSTN_Syntax 2011000MCM_ADV_Invalid_SAC_Syntax 2011100MCM_ADV_Unknown_SAC 2011200MCM_ADV_DNID_File_Overflowed 2011300MCM_ADV_Unsupported_Feature 2011400MCM_ADV_Telex_Not_Allowed 2011300MCM_ADV_X400_Not_Allowed 2011400MCM_ADV_Invalid_SAC_Address 2011500MCM_ADV_Invalid_NMDD_Address 2011600MCM_ADV_Invalid_CNID_Syntax 2011700MCM_ADV_Unknown_CNID 2011800MCM_ADV_Invalid_NTN_Syntax 2011900

MCM_ADV_Invalid_DNIC_Syntax 2012000MCM_ADV_Invalid_Presentation_Code 2012100


17th July 2001

11-74

MCM_ADV_Ocean_Region_Not_Supported 2012200MCM_ADV_Bad_Selection_Criteria 2012300MCM_ADV_Invalid_Route_Number 2012400MCM_ADV_No_CNID_Route_Available 2012500MCM_ADV_Mobile_Not_Commissioned 2012600MCM_ADV_Mobile_Barred 2012700MCM_ADV_Mobile_Barred_and_Logged_In 2012701MCM_ADV_Mobile_Not_Logged_In 2012800MCM_ADV_Unsupported_Country_Code 2012900

MCM_ADV_Not_Initialised 2013000MCM_ADV_Not_Supported 2013100MCM_ADV_Internal_Error 2013200MCM_ADV_Unknown_Error 2013300

MCM_MDIR_Message_Store_Full 2020000MCM_Message_Too_Long 2020100MCM_Zero_Length_Message_Request 2020200MCM_Illegal_Extension_Length 2020300MCM_Illegal_Address_Location 2020400MCM_Unknown_Service_Requested 2020500MCM_Service_Not_Supported 2020600MCM_Assignment_Not_Processed 2020700MCM_Add_Info_Not_Zero 2020800MCM_Unknown_Presentation_Code 2020900

MCM_Invalid_Presentation_Code 2021000MCM_Packet_Validation_Problem_1 2021100MCM_Packet_Validation_Problem_2 2021200MCM_Packet_Validation_Problem_3 2021300MCM_Packet_Validation_Problem_4 2021400MCM_Packet_Validation_Problem_5 2021500MCM_Packet_Validation_Problem_6 2021600MCM_Packet_Validation_Problem_7 2021700MCM_Cannot_Allocate_Msg_Ref_Num 2021800MCM_Cant_Store_Msg_To_MDIR 2021900

MCM_Cant_Send_Msg_To_MDIR 2022000MCM_No_PSTN_Addresses_In_Message 2022100MCM_Add_Info_Len_Invalid_For_PSTN_Addresses 2022200MCM_No_PSDN_Addresses_In_Message 2022300MCM_Add_Info_Len_Invalid_For_PSDN_Addresses 2022400MCM_Too_Many_Telex_Addresses 2022500MCM_Telex_Address_Too_Long 2022600MCM_No_Telex_Addresses_In_Message 2022700MCM_Telex_Message_Ends_Before_Addresses 2022800MCM_Zero_Length_Telex_Message 2022900

MCM_Zero_Length_Message 2023000MCM_Cant_Convert_IA5_To_IA5_Odd_Parity 2023100MCM_Cant_Convert_IA5_To_IA5_No_Parity 2023200MCM_Cant_Convert_ITA2_To_IA5_Odd_Parity 2023300MCM_Cant_Convert_ITA2_To_IA5_No_Parity 2023400MCM_Cant_Convert_IA5_To_ITA2 2023500MCM_No_Storage_For_Message 2023600MCM_Cannot_Allocate_Call_Record 2023700


11-75

MCM_Station_Record_Not_Found 2023800MCM_Station_Not_In_Service_Des_State 2023900

MCM_Station_Not_In_Service_Cur_State 2024000MCM_Station_Not_CES 2024100MCM_Mobile_Record_Not_Found 2024200MCM_Mobile_Not_Commissioned 2024300MCM_Mobile_Not_Logged_In 2024400MCM_Mobile_Barred_NCS 2024500MCM_Mobile_Barred_CES 2024600MCM_Terrestrial_Links_Not_Open 2024700MCM_ITA2_Presentation_From_Mobile_That_Should_Not_Handle_It 2024800MCM_Data_Presentation_From_Mobile_That_Should_Not_Handle_It 2024900

MCM_No_Call_Record_In_Shore_Ship_SDL_Subroutine 2025000MCM_No_Msg_Text_In_AST_In_Shore_Ship_SDL_Subroutine 2025100MCM_No_Call_Record_On_Getting_Outbound_Text 2025200MCM_Cannot_Read_Outgoing_Message_From_MDIR 2025300MCM_Cannot_Get_Msg_Text_For_Shore_Ship_Message 2025400MCM_Shore_Ship_Message_Too_Long 2025500MCM_Zero_Length_Message_From_MDIR 2025600

MCM_Error_Constructing_Distress_Alert 2026000MCM_Distress_Alert_From_Unsupported_OR 2026100MCM_Exception_In_Distress_Alert 2026200

LES Force clear codes

MCM_FC_CES_Timeout 2030100MCM_FC_SES_Protocol_Error_Detected 2030200MCM_FC_CES_Fatal_Hardware_Error_Detected 2030300MCM_FC_Operator_Forced_Clear 2030400MCM_FC_SES_Forced_Clear 2030500MCM_FC_CES_Protocol_Error_Detected 2030600MCM_FC_SES_Hardware_Error_Detected 2030700MCM_FC_SES_Timeout 2030800MCM_FC_Unrecognised_Presentation_Code 2030900MCM_FC_Invalid_Address 2031000MCM_FC_Destination_SES_Not_Commissioned 2031100MCM_FC_Destination_SES_Not_Logged_In 2031200MCM_FC_Destination_SES_Barred 2031300

MCM_NCS_Failed_To_Respond_To_TDM_Request 2040100MCM_NCS_Failed_To_Respond_To_TDM_Release 2040200MCM_Deleted_Operational_TDM_Group_Record 2040300MCM_Call_Failed_Due_To_FEP_Switchover 2041000MCM_Call_Failed_Due_To_BAP_Switchover 2041100

CUC FEP Errors

CUC_Mobile_Waiting_For_Clear 3000001CUC_Timeout 3000002CUC_Force_Clear_From_Mobile 3000003CUC_Local_Equipment_Failure 3000004CUC_Input_Data_Timeout 3000005CUC_Unable_To_Send_Ack 3000006


17th July 2001

11-76

CUC_Unable_To_Send_Assign 3000007CUC_Mobile_Response_Timeout 3000008CUC_Mobile_Out_Of_Seq 3000009CUC_Protocol_Failure 3000010CUC_Remote_Equipment_Failure 3000011

Pre-assigned Data Reporting error codes

MCM_PADR_Resp_Timeout 4000001

MCM_PADR_Reservation_Exists_For_Program 4000002This error code indicates a reservation that is already presentThis indicates an error in the Poll sent by the user

MCM_PADR_No_Reserved_Sig_Chan_Defined 4000003This error code indicates that no signalling channel exists.

MCM_PADR_No_Reservations_Available 4000004This error code says that the PADR could not find any reservations inthe cache

MCM_PADR_Internal_Exception 4000005This error represents an Internal Exception in PADR processing

MCM_PADR_Res_Not_Found_For_Repetition 4000006This error indicates that when a PADR poll was repeated, the originalreservation was not found

MCM_PADR_Res_Doesnt_Exist_For_Stop_Delete_CNID_Polls 4000007This indicates that the PADR reservation was not found when the stop orDelete CNID Polls were processed.

MCM_PADR_Unexpected_Status_Code 4000008This indicates an unexpected PADR status code

11.4 Channel Unit Failure Event Filtering

The software can filter out certain events associated with the channel units so that, if frequenttransitions from in-service to out-of-service and back again occur, the number of events presentedto the operator is limited.

Event filtering works on the following three pairs of events reported in respect of the channel units:

SDC 11 and SDC 12 - TDM group operational or non-operational

SDC 31 and SDC 33 - Physical CIU operational or non-operational

SDC 101 and SDC 102 - SIG channel operational or non-operational

When these changes are detected within the software, they are analysed to determine if the eventis to be reported to the operator or not.

All the occurrences of these events are stored and examined at a check interval - set to 60seconds.

A non-operational event without the appropriate operational event within this interval will generate


11-77

an event to the operator. Similarly, an operational event without a non-operational event duringthis time will generate an event to the operator. The interval over which this check is made is setto 5 minutes (default).

The filter also has limits on the number of transitions which may occur in a given interval before anevent is raised to the operator. For the SIG channel events, the event to the operator is raisedwhen there are 12 occurrences within 2 minutes. For the other two events, 5 occurrences in 5minutes are required.

[opg11.mss]

Operating System Access A4-OPG-003076Issue 3.23 - Accepted

17th July 2001

11-78

A4-OPG-003076 Operating System AccessIssue 3.23 - Accepted17th July 2001

12-1

Chapter 12

OPERATING SYSTEM ACCESS

12.1 Functions

The operator will need to access the VMS operating system in order to start and stop the applica-tion software and to change a limited number of parameters in the system. It is also possible tointerrogate the operational state of the application software. Further functions can be performedbut these are not necessary for the normal running of the equipment.

12.2 Access Mechanism

The operator is able to gain access to the operating system using either the VMS console directlyor the Create VT200 Window option on the SOC. The latter is only possible once the SOCworkstation is running.

When the Create VT200 Window option is selected, the initial user is requested to logon with themessage :

Welcome to <name of the SOC> VMS v....

Username:

The following information should be entered at the prompts shown in bold and pressed atReturnthe end of each entry.

Username: SET_HOST

Which node do you require? (F10 to exit) [default]: <node name>

where node name identifies the individual BAP, for example VAXA or VAXB. These names areallocated when the system is installed and the default appears as part of the prompt. Enter thedesired node name or press if the default is required.Return

Username: BAPSYS

Password: <password>

Note that the password is not echoed to the screen.

If the password is entered wrongly, the message

User authorisation failure

will appear. Press to go back to the Username prompt.Return

Several lines of text scroll up the screen - these can be ignored. Then the prompt CES nnnn>appears to indicate that access to the desired BAP has been gained. The entry ’nnnn’ is the firstfour letters of the node name, e.g. VAXA. This is used in the examples illustrated below.

At this level, commands are in Digital Command Language, (DCL) . Commands available are


17th July 2001

12-2

described in the DEC VMS User literature but such commands are not used in the operation of theACSE, except where specifically identified in this manual.

The DCL commands used in this section uses the following protocol:

Dnnn Indicates a disk drive e.g. $1$DIA1

Mnnn Indicates a magnetic media drive e.g. MUA0:

xxx Indicates the operator assigned label for a backup

Of particular interest is the BAP Operations Facility, an executable file which is included in theACSE software.

12.3 BAP Operations Facility

The BAP Operations Facility allows the operator to start and stop the BAP software and to performsimilar functions which must be executed at the level of the operating system.

Access to the BAP operations facility is gained by the DCL command BAPOP:

CES nnnn> BAPOP

The prompt will then change to:

BAPOP>

which signifies that the operator is now using the BAP Operations Facility.

Alternatively, if the subsequent commands are already known, they can be entered as string withthe BAPOP command, e.g.


which is equivalent to the sequence:

CES nnnn> BAPOPBAPOP> START BAP ARBITERBAPOP> EXITCES nnnn>

Once interaction with the BAP has been concluded, the operator should log off with the command:

CES nnnn> LOGOUT

This returns to the basic prompt:

Which node do you require (F10 to exit)[ default] :<node name>

Press to close the window.F10

The following commands are available:

HELP Information in plain text is available on all the commands listed below, i.e. thishelp is for the BAPOP facility.

DEINSTALL BAP Deinstalls BAP images from memory, i.e. removes the working copy of thesoftware from the dynamic memory in which it is normally held. This com-


12-3

mand is used when a new BAP software release is to be loaded onto the sys-tem. This command should only be used if the BAP images have been in-stalled in memory via INSTALL BAP or START BAP. The system must not berunning or in a startup state when images are deinstalled.

Format : BAPOP> DEINSTALL BAP

DO [DCL-string] This allows a DCL command to be executed from the BAPOP environment. Ifthe command contains a space, the command line must be enclosed withindouble quotes. For example, DO "SHOW TIME" will execute the DCL com-mand SHOW TIME.

EXIT This command takes the user out of BAPOP and returns to DCL, restoring theCES nnnn> prompt.

INSTALL BAP Installs BAP images from disk into dynamic memory as a prelude to opera-tional use. The BAP software must already have been installed onto the disk.This command is not normally used during system operation; START BAP willinstall images automatically.

Format : BAPOP> INSTALL BAP

QUIT This command returns the user to DCL. It is an alternative for EXIT.

SHOW BAP Displays operational status for the BAP system, including whether the systemis STARTED/STARTING or STOPPED, and the name of the current Onlinedatabase. If the BAP is STARTED, the mode and state of the processor willbe displayed. The user will also be prompted as to whether the current activeBAP processes should be listed; if this option is selected, all processes run-ning in the BAP user definable code group will be listed and their currentprocessing states and CPU and memory statistics shown.

Note that the disk number (e.g. $1$DIA1) shown in the response refers to thedisk on which the software was built and not to that on which it is running.This field can therefore be ignored.

Format : BAPOP> SHOW BAP

SHOW STATE Displays Processor State information. If the BAP is STARTED, the mode andstate of the processor will be displayed, followed by the list of processes thatwill be running on this processor, as well as their Current and Desired State.This is identical to SHOW PROCESS.

Format : BAPOP> SHOW STATE

SHOW PROCESS Displays Processor State information. If the BAP is STARTED, the mode andstate of the processor will be displayed, followed by the list of processes thatwill be running on this processor, as well as their Current and Desired State.This is identical to SHOW STATE.

Format : BAPOP> SHOW PROCESS

START BAP Starts the BAP applications software.

Format : BAPOP> START BAP [mode]

The optional field mode specifies the mode to be used on this processor. Thiscommand enables the operator to override the operation of the arbiter andoperate in the selected mode.

Valid modes are MASTER, STANDBY, IDLE, or ARBITER.

Normally select ARBITER. The processor assumes that the arbiter is presentand the BAP will abide by the mode chosen by the arbiter. This is the onlyway to implement fully automatic redundant operation of the two BAPs.

Only select MASTER and STANDBY when specifically instructed by HNS.


17th July 2001

12-4

The system should not be left in either of these modes for longer than neces-sary, since it would be operating non-redundantly; restart with ARBITER modeas soon as instructed.

The equivalent command from DCL is :


STOP BAP Stops the BAP applications software. Note that this will terminate all supportfor Standard-C operations by this BAP.

Format : BAPOP> STOP BAP

Only use this command when instructed to do so as part of a softwareupgrade, or if the BAP has to be stopped and restarted to cure aproblem - see below.

12.4 When to Restart the System

Any processor, either BAP or FEP, must be restarted when it has been repaired.

The only other time that a restart should be necessary is in the unlikely event that the softwarebecomes locked in a loop from which it cannot recover. If that happens, the first solution must beto switch over to the standby machine. This is performed on the SOC by selecting the BAPManagement , FEP Management or DEMSA Management form (SOC Forms - System Control),and forcing a switchover -

• for BAP switchover, use Switch

• for FEP switchover, select the desired FEP and use Switch

• for DEMSA switchover, select the desired DEMSA and use Switch

If this is necessary, then HNS should be informed, using the procedures outlined in Appendix F.

A processor can be restarted at any time but this is an operation which should only be undertakenafter proper assessment of the situation and only as a last resort.

12.5 Hardware Initialization

Initialization of the hardware takes place on power-up only.

The DEC equipment will automatically boot itself. A BAP will initialise provided the applicationsoftware is on disk. A FEP will initialise and communicate with one of the BAPs to requestdownload of its software.

Communication between the BAPs and the FEPs is over Ethernet. When a node is connected, itautomatically tries to communicate with other nodes which it knows about. Thus if a node is tem-porarily out of service, communication with it is quickly re-established when it is restored. If com-munication cannot be automatically re-established, the BAP itself must be restarted using BAPOPSTOP and BAPOP START.

The Channel unit hardware will go through its self-test automatically and then will request con-figuration from the processor. Initialization takes about 30 seconds to complete.


12-5

12.6 Types of Software Startup

There are two levels of software startup.

• Cold start , where the equipment is initially unpowered and the databases have to becreated.

• Warm start , where the application software has to be restarted.

A cold start will be performed when the equipment is first installed. This will include various ac-tivities undertaken by DEC staff to initialise the operating system. It should not be necessary everto repeat these actions thereafter; the only occasion would be if the equipment was being repairedby DEC, in which case their staff would undertake the work. The relevant instructions are nottherefore included in this manual.

Both cold and warm starts can take place on either the whole equipment or on part of it.Generally, failures during operation will only require the faulty equipment to be restarted when ithas been repaired; the online equipment will not be affected.

An important element of start-up is the synchronization of the databases. This is an automaticprocess, because of the disk shadowing mechanism used, but will take time - between 30 and 45minutes. Resynchronization is only required when power to the shadowed disks, which are in aseparate cabinet, is removed and reconnected.

The operator is provided with means of starting and stopping the system by accessing the operat-ing system.

12.6.1 Warm Start

In the warm start, only the application code is restarted. The operating system is left running.

To restart the application code on a BAP, use the VMS commands described in section 12.3. Thefollowing steps are automatically performed :

1. All software is started and initialized

2. New current log files are started

3. The restarted BAP establishes contact with the online BAP, if available.

4. The BAP establishes contact with each FEP.

5. When the databases are synchronised, the BAP is available for traffic and enters theStandby mode.

If there is no operational BAP when this process takes place, both BAPs should be started at thesame time. The Arbiter will promote one BAP to Master as soon as possible.

To restart a FEP, use the Restart FEP command on the FEP Management form.

12.6.2 Cold Start

For a cold start, the operating system must be started before the above warm start sequence isfollowed. This will normally be performed by a DEC Engineer.

A cold start is also necessary if a system disk fills up or fails. In this case, the BAP will have to be


17th July 2001

12-6

restarted by typing B on the VMS console at the >>> prompt.

12.6.3 Monitoring the Progress of Startup

Since starting the BAP takes some time, it is useful to be able to look at the progress of the startupsequence. Use the BAPOP SHOW STATE command to obtain the displays shown in figures 10-1and 10-2 which illustrate the progress being made.

12.7 Stopping a Processor

It is possible to stop a processor should this be necessary, e.g. for a software upgrade.

First of all the processor should be placed offline using the appropriate management form.

For a FEP turn off the power at the front panel switch. For a DEMSA disconnect the power cord atthe rear.

For a BAP use the BAPOP commands shown in section 12.3

12.8 Stopping a System

There will be occasions when it is necessary to stop the system completely, for example before asun outage (where communications with a satellite is temporarily lost due to its being in line withthe sun) or if work is planned on the RF equipment. Except in an emergency, this can be plannedin advance and measures can be taken to minimise interruption to service.

If the interruption is only to the satellite side of the system and if the processors and the terrestrialinterface remain operational, it is only necessary to advise mobiles, through an EGC message,that service will be interrupted. Terrestrially originated messages will be stored for transmissionuntil the satellite side is restored.

Before the interruption, the TDM groups and then the ISL should be taken out of service using theTDM Group Management and ISL Management forms.

If the interruption is more serious and involves stopping the processors , the mobile users shouldbe advised and the congestion bit set on the TDM Group Management form. The terrestrial in-coming circuits should also be busied. This will stop new traffic coming to the LES. A suitableperiod should be allowed for the delivery of messages held within the LES and then the satelliteside stopped as described above.

Once the traffic has been stopped, the processors may be stopped as described above.

12.9 Starting the SOC Terminal

The software needed to run the SOC must have first been loaded into the SOC workstation,usually via tape, and the system must have been booted such that the SOC application can nowrun. Access can be gained to the SOC in a similar way to the BAP. Use the Create VT200window option, as described in chapter 2, and at the prompt issue the commands as follows:

Username: SOCSYS

Password: <password>

Note that the password is not echoed to the screen.


12-7

Several lines of text are scrolled up the screen - ignore these - and the screen changes size.Then the prompt appears.

CES nnnn>

In this case, nnnn represents the first four letters of the name of the SOC. This prompt indicatesthat access has been gained to the SOC.

To start the SOC, now enter the command :

CES nnnn> STARTSOC

Similarly, the SOC can be stopped with the command

CES nnnn> STOPSOC

To exit this session, enter the command

CES nnnn> LOGOUT

The window will then disappear.

Note 1: it is recommended that this session is not logged out since it is required in order for SOCform windows to be created.

Note 2: it is possible to delete specific windows from this account, using the appropriate VMScommands, needed for example in the exceptional circumstances, where a window is no longeraccessible.

12.10 Performing a Standalone Backup of a System Disk (BAP or SOC)

This procedure is required primarily for the System Disk, since if backup were to take place whilstthe BAPs were in an operational state, a number of files would likely be opened and therefore notbacked up. System Disks need only be backed up after installing a new software release, beforeoperating with that release.

Warning: use of this procedure to backup the BAPs on a live LES is not recommended, since itcan prevent successful reformation of the VAX cluster.

Both BAPs must be in the shutdown state before either is booted under standalone backup, andneither must rebooted under VMS as a VAX cluster member until both are in the shutdown stateonce more.

Login to the operational account (BAPSYS/SOCSYS).

Stop all application software on the processor to be backed up:

BAPs: CES nnnn> STOPBAP or CES nnnn> BAPOP STOP BAP

SOCs: CES nnnn> STOPSOC

Deinstall shared images:

BAPs: CES nnnn> DEINSTALLBAP

SOCs: CES nnnn> DEINSTALLSOC


17th July 2001

12-8

Logout of the operational account.

Login to the SYSTEM account from a local terminal such as the VMS console.

Invoke the system shutdown procedure:

CES nnnn> @SYS$SYSTEM:SHUTDOWN

Answer the questions as follows:

How many minutes until final shutdown [0]: <CR>

Reason for shutdown [Standalone]: <CR>

Do you want to spin down the disk volumes [NO]? <CR>

Do you want to invoke the site-specific shutdown procedure [YES]? <CR>

Should an automatic system reboot be performed [NO]? <CR>

When will the system be rebooted [later]: <CR>

Shutdown options (enter as a comma-separated list):

REBOOT_CHECK Check existence of basic system files

SAVE_FEEDBACK Save AUTOGEN feedback information from this boot

Shutdown options [NONE]: REB,SAV

where <CR> means hit the Return key to accept the default shown.

When the following message appears at the end of the shutdown procedure:

SYSTEM SHUTDOWN COMPLETE - USE CONSOLE TO HALT SYSTEM

Press the Halt button.

• If the button is of the latching kind, generally mounted on the front of the processor, itshould be pressed twice, once to move the button in and then out again.

• If the button is of the non-latching kind, mounted on the rear of the processor, itshould be pressed once, holding it in for a moment.

Warning: if a BAP is being backed up, the other BAP must also be shutdown. Both BAPs can bebacked up at the same time, but neither must be rebooted under VMS until both are once more atthe console prompt.

Boot standalone backup - reference [5] describes how this is done on any particular VAX platform.

Enter the current date and time in response to the prompt.

Enter the backup command:

CES nnnn> BACKUP/IMAGE/VERIFY/LOG -CES nnnn>- Dnnn: Mnnn:xxx.SAV/REWIND/LABEL=xxx/IGNORE=LABEL


12-9

Usually the cartridge tape device name is MUA0 on BAPs (MKA500 or MKB500 on SOCs). It isrecommended to use the name of the disk device for the name of the saveset and volume label.E.g. if the disk is $1$DIA0 then the saveset can be DIA0.SAV and the volume label DIA0.

All files on the system disk will be listed as they are copied onto the tape. Once all files have beencopied the tape will be rewound and the verification pass will start. This will take a similar time tothe copy pass.

If the disk image is too big to fit on one tape then when the verification pass for the first tape iscomplete BACKUP will prompt for a second tape. Enter YES in response to the prompt indicatingthat the second tape is loaded into the drive. A copy pass followed by a verification pass will thenoccur for the second tape.

Note: Any tapes or cartridges used for backup must have been initialized on the same, or a com-patible drive before the backup. The tape label need not be that expected for the backup as theoperator is prompted for a new label.

Once all files on the system disk have been backed up BACKUP will report the process complete.It is possible to make a duplicate backup by entering YES at the prompt to continue. If this is notrequired then use the Halt button to return to the console prompt (>>>).

If a BAP is being backed up, ensure the other BAP is at the console prompt too.

Boot VMS:

>>> B

Login into the operational account (BAPSYS/SOCSYS).

Start the application software:

BAPs: CES nnnn> STARTBAP ARBITER or BAPOP START BAP ARBITER

SOCs: CES nnnn> STARTSOC

Logout of the operational account.

Notes:

1. If Standalone Backup will not boot then reboot VMS and enter the following com-mand from the SYSTEM account to create the necessary files:

CES nnnn> @SYS$UPDATE:STABACKIT

2. To restore an image backup, boot Standalone Backup as described above and enterthe following alternative BACKUP command:

CES nnnn> BACKUP/IMAGE/LOG Mnnn:xxx.SAV/LABEL=xxx Dnnn:

12.11 Backing up a System Disk Whilst the LES is Still Live

Enter the backup command:

CES nnnn> BACKUP/IMAGE/VERIFY/LOG -


17th July 2001

12-10

CES nnnn>- Dnnn: Mnnn:xxx.SAV/REWIND/LABEL=xxx -CES nnnn>- /IGNORE=(INTERLOCK,LABEL)

Usually the cartridge tape device name is MUA0 on BAPs (MKA500 or MKB500 on SOCs). It isrecommended to use the name of the disk device for the name of the saveset and volume label.E.g. if the disk is $1$DIA0 then the saveset can be DIA0.SAV and the volume label DIA0.

All files on the system disk will be listed as they are copied onto the tape. Once all files have beencopied the tape will be rewound and the verification pass will start. This will take a similar time tothe copy pass.

If the disk image is too big to fit on one tape then when the verification pass for the first tape iscomplete BACKUP will prompt for a second tape. Enter YES in response to the prompt indicatingthat the second tape is loaded into the drive. A copy pass followed by a verification pass will thenoccur for the second tape.

12.12 Disk Status

12.12.1 Monitoring Disk Status

Besides the messages which appear on the Alarm Printer and the messages which appear on theVMS console, informing the operator of a change in disk status or of potential or actual problemswith the disk(s), the operator can at any time, whilst VMS is running, exercise the following com-mand in order to ascertain the current status of the disks:

CES nnnn> SHOW DEVICE D

The resultant output will be of the form:

Device Device Error Volume Free Trans MntName Status Count Label Blocks Count CntDSA0: Mounted 0 USER01 166215 96 2DSA0: Mounted 0 USER02 157233 69 2$1$DIA0: (RIGEL0) Mounted 0 RIGEL_SYS 10911 239 2$1$DIA1: (RIGEL1) ShadowSetMember 0 (member of DSA0:)$1$DIA3: (RIGEL2) ShadowSetMember 0 (member of DSA1:)$1$DIA3: (RIGEL3) Mounted 0 QUORUM 45816 1 2$1$DIA4: (ORION4) ShadowSetMember 0 (member of DSA0:)$1$DIA5: (ORION5) ShadowSetMember 0 (member of DSA1:)$1$DIA6: (ORION6) Mounted 0 ORION_SYS 15114 1 2

The devices present will depend on the particular customer configuration. Note in particular thepresence of the system disks, whose Volume Labels will normally contain the suffix SYS, and theshadowset disks. The shadowset disk devices have the volume label member of DS nn, whereDSnn is the shadowset name, which itself appears as a virtual device.

The Device Status should be either Mounted or ShadowSetMember , any other state may in-dicate that the disk is not accessible. The Mnt Cnt should be equal to the number of VAX proces-sors clustered in the system. If a single disk is showing a lower mount count than the others, thenit will be unavailable on another node. If the Mnt Cnt is lower than expected for all disks, this mayindicate a VAX in the cluster has failed.

If the Device Status is Mounted and the number of Free Blocks is greater than 5000, then this willnormally indicate that the system disk is functioning normally. The shadowset disks should nor-mally have at least 50000 Free Blocks, and the related SOC System Usage display bar shouldfall short of the red zone. Anything other than this, take the remedial actions contained in this


12-11

manual, in particular in response to the associated events and VMS console warnings.

12.12.2 Disk Failure

If any disk shows a non-zero Error Count, a DEC service engineer should be called to investigatethe cause.

If the Master BAP system disk suffers a catastrophic failure and the processor halts, the StandbyBAP will assume the Master role when the normal handshaking between the Master BAP and thearbiter fails.

12.12.3 Disk Space Exhaustion

Should the number of free blocks on a disk become low the normal remedy will be to purge orremove unwanted files. Log files should only be removed using the procedures described inChapter 14.

12.12.4 System Disk Space Exhaustion

There are also safety mechanisms in operation, should the amount of free system disk spacebecome critically low. Both the LES software and VMS monitor the system disks, although nor-mally the LES software will act before VMS and halt the processor, initiating a switchover.

If VMS acts first due to a sudden exhaustion of system disk space, the LES software processeswill be suspended and will not be able to halt the processor, although operator access to VMS viathe VAX operator console should still be possible. In these circumstances, the Standby BAP willassume the Master role when the normal handshaking between the Master BAP and the arbiterfails. If the new Master BAP appears to hang during the switchover, halt the old Master BAPprocessor, or if it can be done quickly, free space on its system disk.

System disk space can be freed on a halted or suspended BAP from the other BAP. If systemdisk space is freed on a suspended BAP, VMS will automatically unsuspend the LES softwareprocesses and normal service will be resumed. Once system disk space has been freed on ahalted BAP it can be rebooted and the LES software restarted.

If there is still a problem contact the HNS customer support desk.

12.12.5 Operator log files

VMS maintains an operator log file on each BAP’s system disk. This separate from, and not underthe control of, the LES application. This file logs operating system activity and can contain usefulinformation in the event of system malfunction.

Without operator intervention, this data will be logged to a single file which may grow to a sig-nificant size over a period of a few months (dependant on system activity, 700 blocks per day hasbeen observed). Normally, this data may be discarded as unwanted. However a conflict may arisein the event that this file needs to be deleted when the data contained is relevant to a problemunder investigation.

It is recommended that this procedure described here, be run once each month and at a timewhen there has been no errors for two days or more - to ensure that no potentially useful data islost.

The operator should exercise restraint if log files of less than one month old are to be deleted asthese files contain records which may be of use when investigating system problems.


17th July 2001

12-12

Such recent files should not be deleted UNLESS every other course of action has been exhaustedin trying to free more disk space and a BAP failure imminent (i.e. purge all files delete unwantedfiles). Or else they should be copied elsewhere (to another disk or to tape).

To ascertain the current free space available on the system disk, use the command:

$ SHOW DEV SYS$SYSDEVICE

The size and date of all operator logs can be found from:

$ DIR SYS$MANAGER:OPERATOR.LOG/SIZ/DAT

12.12.5.1 Procedure to manage operator log files

MONTHLY:

OPCOM messages may be seen on screen during this procedure. These are of no significanceunless errors are reported.

Using an operator console: Ensure that reply is enabled:

$ REPLY/ENABLE

Close current log file and open another:

$ REPLY/LOG

(If reply is not required, then:

$ REPLY/DISABLE)

The size and date of all operator logs can be found from:

$ DIR SYS$MANAGER:OPERATOR.LOG/SIZ/DAT

It should be seen that a new log file has been created, thus making the previous version availablefor reading. All earlier versions may now be purged (assuming that they are no longer required),keeping the file just closed:

$ PURGE/LOG/KEEP=2 SYS$MANAGER:OPERATOR.LOG

FOR MAXIMUM SPACE:

Once all other possible options for freeing up disk space have been exhausted, including the dele-tion of earlier versions of this log file as described in the monthly procedure above, proceed asfollows.

Repeat the above procedure immediately. This will close the current log file and delete the pre-vious version.

If disk space is still inadequate, and deleting the now closed log file would release significantspace, then:

$ DELETE/LOG SYS$MANAGER:OPERATOR.LOG;-1

At this point there should only exist one log file, the size now being a few 10’s of blocks. No furtherspace gains can now be attained in this area.


12-13

12.13 Disaster Recovery

This section summarizes possible failures of the system that require file backups to have beenpreviously performed in order to enable disaster recovery. Note: many of these issues are ad-dressed elsewhere in this manual. In all cases it is assumed that disks or processors have beenrepaired or replaced before the operations listed are undertaken.

Point of Failure Site Backup HNS Backup

1. Single Points of Failure:

Total loss of any Restore image Backup Archived Tapes of theSystem Disks of the System Disk Software Release,

Sybase Installationand VMS Installationplus other layeredproducts

Loss of one Shadowset Disk Initialise and mount Phone HNS supportreplacement disk for reinstallation(Shadowset software of replacement diskwill cause anautomatic merge).

Loss of the Quorum Disk Restore Logfile Reinstall the OfflineBackup Database Sybase device

as defined by SystemDisk OFDB files

Loss of an entire BAP Restore Image Backup Archived Tapes of theincluding System Disk of the System Disk, Software Release,e.g. through fire Database dump backup Sybase Installation

and VMS Installation,plus other layeredproducts

Loss of an entire SOC Restore Image Backup Archived Tapes of SOCor SOC Disk e.g. through of the System Disk, Software Release andfire and SOC Software if SOC VMS Installation

on separate disk

2. Dual Points of Failure

Loss of both Shadowset disks Restore Database Dump Archived Onlinearchived to tape Database Dump

3. Total System Loss

Loss of all VAXes and disks Restore System Disk Archived Softwaredue to fire, water or Image Backup, Tape Release, VMS / Sybaseexplosion damage Backup of Database Installation. Archived

Dump, also logfiles Online Database DumpKept in separatebuilding/fire safe

Backup Frequency


17th July 2001

12-14

Note: the following is a suggested procedure. Customers should define theirown procedures to meet their particular circumstances.

Database Dump to tape Once a month (retain new registered users)

System Disk Image Backup For each new software release,or following the third EBF since a backup waslast made.

for both BAP and SOC

Logfile Backup Once a week

Note: HNS strongly advise that backups are stored either in firesafes or in a separate building tothe systems. The backed up data must not be lost in a catastrophe which also destroys the VAXsystems and their drives.

[opg12.mss]

A4-OPG-003076 Online StatisticsIssue 3.23 - Accepted17th July 2001

13-1

Chapter 13

ONLINE REPORTS AND STATISTICS

The LES gathers data relating to the activity of the system in the form of log files and in the onlinedatabase. Formatted displays or hard-copy printouts of this data is accessible to the user in theform of online reports and statistics, using the SOC Viewer.

Periodically, the data is transferred to the offline part of the system, where separate OfflineReports are available. These are described in section 14.11.

13.1 Online Statistics Printouts

The system collects a range of statistics. At the end of a given interval, which is operator con-figurable but has a default of 1 hour, they are transferred to the current open log file. The operatoris able to obtain an output of the statistics obtained from any of the log files in the online areaincluding the open log file.

There are two associated operator functions. Statistics Reports Management controls whetherstatistic data is logged for individual components from the raw data contained in the log files andat the interval at which logging takes place. Statistics Reports Print Management controlswhether the report for a particular component is output to a printer. The list of components whosestatistic data logging is controlled from Statistics Reports Management is a superset of thatwhose printout can be enabled/disabled from Statistics Reports Print Management . Statisticsfor certain components, namely EM and LFM, are required for HNS internal diagnostic use, andthere is no requirement to print this data out.

To control the preparation of data, use Statistics Reports Management (SOC Viewer - OnlineProcessing). The options available are :

• set a single components statistics logging interval

• set all components statistics logging intervals

• switch off statistics logging for a component

• switch off statistics logging for all components

• display statistics logging intervals

• log all component’s statistics, (i.e. switch them on for all components)

• log named component’s statistics

The interval over which data is collected can be altered with the above controls. The options forany field, except time, can be seen by selecting ’?’.

Use Statistics Reports Print Management (SOC Viewer - Online Processing) to control prin-touts. The options available are:

• display all statistics report names and print states

• set a single statistics report print state

• set all statistics report print states

Online Statistics A4-OPG-003076Issue 3.23 - Accepted

17th July 2001

13-2

Statistics are collected for the following:

• X25 : PSDN

• TLX : telex lines

• SYSTEM_USAGE

• CHANNEL_UNIT_RACK

• CHANNEL_UNIT_CHASSIS

• TDM_GROUP

• FAX : PSTN interface for facsimile delivery

• EM: event manager

• LFM: log file manager

To prepare the statistics for printing first modify the report interval by selecting the Set a SingleComponents Statistics Logging Interval or Set All Components Statistics Logging Intervalsoptions from (SOC Viewer - Online Processing - Statistics Reports Management).

The intervals at which statistics are collected is a minimum of 15 minutes and a maximum of 24hours. The original default value is 1 hour. It is advised not to generate outputs too often - once anhour should be sufficient, except where it is desired to study performance over a short period.

To determine the current values of the collection intervals, and modify these values, use DisplayStatistics Logging Intervals , followed by Log Named Component Statistics , both options from(SOC Viewer - Online Processing - Statistics Reports Management).

The operator will then be prompted with :

Do you wish to reset Y/N >

Confirmation is then requested :

Continue with these parameters? Y/N>

Enter Y to confirm or N to return to the menu. If Y is entered, the screen will show :

Operation was a successHit <CR> to continue

This will take the operator back to the menu.

Entering Yes will reset the interval counters at the current time; entering No will leave them un-changed. The report is then sent to the Report Printer after the interval period has elapsed, provid-ing printing has been enabled via Statistics Reports Print Management .

Note: that statistics for Event Manager and Log File Manager can only be viewed via the onlinelogfile reports described in Section 13.2.


13-3

13.2 Online Logfile Reports

The following reports are available via Generate Log File Reports (SOC Viewer - OnlineProcessing - Run Reports - Run Online Log File Reports) :

• Call records

• Distress messages

• Event messages

• Grade of Service

• Operator messages

When a report has been produced it can either be :

• viewed - use View Log File Reports (SOC Viewer - Online Processing - RunReports - Run Online Log File Reports)

• printed - use Print Log File Reports (SOC Viewer - Online Processing - RunReports - Run Online Log File Reports) and select the report.

13.2.1 Call Records

Several Call Record reports are available via Generate Report on Call Records (SOC Viewer -Online Processing - Run Reports - Run Online Log File Reports - Generate Log File Reports).These reports provide information about individual calls, such as time, message reference num-ber, origin, destination, call outcome. The following call record based reports are available:

1. Summary and Statistics Message

2. LES to Mobile Message

3. Mobile to LES Message

4. Poll Message

5. EGC Message

6. DNID Retrieval

7. Data Reports

8. DNID Handler

9. Mobile Login/Logout

13.2.2 Distress Messages

The Distress Message report is available via Generate Report on Distress Messages (SOCViewer - Online Processing - Run Reports - Run Online Log File Reports - Generate Log FileReports). This report provides comprehensive details of the distress messages processed by theLES.

Online Statistics A4-OPG-003076Issue 3.23 - Accepted

17th July 2001

13-4

13.2.3 Event Messages

The Event Message report is available via Generate Report on Event Messages (SOC Viewer -Online Processing - Run Reports - Run Online Log File Reports - Generate Log File Reports).This report summarizes the events for a given time, giving a full textual description. This printout isof use in studying the cause of a fault and should be added wherever relevant, to fault reportsreturned to HNS.

The following should be noted when selecting this report :

• Latest Event Time - this is a Date/Time field - all events in the report will be beforethis time. Note that this field must show a past time - do not enter a future time.

• Last N Hours - a report may process the N hours of events - this will be taken as Nhours preceding the Latest Event time, or N hours before the current time if the LatestEvent Time is not filled in. If this field is not filled in then all events preceding theLatest Event Time will be considered for the report (subject to the remaining selectioncriteria).

Note that at least one of the above fields must be entered.

• Alarm Level - This is the Alarm level of the events which will appear in the report.Possible entries are Distress, Undel_distress, urgent, semi_urgent, minor. If this is notfilled in then all alarm levels will be selected.

• Outstanding Events - If ’Y’ is entered, then only events which have not been acknowl-edged (either by the operator or automatically) will appear in the report.

• Event Source - This is a six character string that identifies the processor ID of theBAP reporting the event. If this is not filled in then events from either BAP will beconsidered for the report.

13.2.4 Operator message

This report provides details (including text) of messages from one or mobile sent to the operatorposition as a result of addressing the message to the operator using the designated special ac-cess code.

13.3 Online Database Reports

The following reports are available via SOC Viewer - Online Processing - Run Reports - RunOnline Database Reports:

• Trunk Telex Route

• Message Status

• DNID

• ENID

• Country Code

• PVT Results

• X25 Route


13-5

• X25 Line

• X25 Channel

• Address Extension

• Ocean Region Address

• Call Completion Code

• Mobile List

• Registered User Full

• Registered User Summary

• Inmarsat MES Status

These reports provide details of the contents of various elements of the LES online database.Further details of these reports are provided earlier in this document when discussing the as-sociated LES functions - use the index to locate the required information.

opg13.mss

Offline Processing A4-OPG-003076Issue 3.23 - Accepted

17th July 2001

13-6

A4-OPG-003076 Offline ProcessingIssue 3.23 - Accepted17th July 2001

14-1

Chapter 14

OFFLINE PROCESSING

14.1 Functions Performed Offline

This chapter describes the offline processing activities associated with billing, report generation,etc, which do not need to be performed as part of the on-line handling of traffic.

With the provision of the autobilling feature (see chapter 16), logfiles are no longer required to beloaded into the offline database for the purpose of billing. Mention of billing remains in this chapterfor reference only as billing can still be performed this way if ever desired. With the new billing,OFDB only has use for generating the offline reports.

Note that if any offline processing is to be performed on log files (listing, report generation orOFDB billing), then billing MUST be carried out on these logfiles BEFORE they are copied to theoffline area.

Reference to other billing support activities within this chapter are still valid, such as tape/file for-mats and tape combiner, all accessed as an offline activity, but not using OFDB.

The online system records details of the calls it processes and other system activity in data files,called log files; the log files are used as the input to the offline processing.

The primary functions performed offline are :

• to load the online system’s log files into a database (known as the Offline Database)

• to access the loaded Offline Database to generate the following output(s):

• customer billing record data (on tape or disk)

• to archive the logfiles and the offline database

• to generate reports, which fall into the following categories :

• Statistics. These reports summarize the performance of the LES over thespecified time span.

• Call records. These reports hold details of the calls that were made over thesystem over the specified time span.

• Events. These list events which were recorded, including all alarms which oc-curred in the system.

• Distress. Complete details of all distress calls.

In addition to these primary functions, there are a number of ancillary functions associated with theadministration of the files and database and the initialization and handling of tapes.

The associated terms should be clearly defined :

• the online system is the traffic handling software

• the offline system is software which is not concerned with traffic handling; thesoftware usually runs on the standby processor but this is not absolutely necessary,although the traffic handling capacity of the system would be impaired if this was notthe case.


17th July 2001

14-2

• log files are generated in the online system. A log file is closed after 1 hour or 2048entries, whichever occurs first. A new log file is then automatically started.

• the offline system contains log files, copied from the online system, and the offlinedatabase

Files in the offline system are not shadowed but are held on the Quorum disk. These files hold thefollowing sets of data :

• offline database

• offline reports

• offline lists

• offline area containing log files copied from the online area

The archiving procedures described must be performed regularly to ensure that no data is lost incases of disk corruption.

14.2 Access to the Offline Functions

The offline processing is accessed via the SOC Viewer. The menu structure for this is shown inchapter 4. Normally this will be executed on the STANDBY BAP. In the case of a switchover orwhere only one BAP is available the processing will be possible at much reduced priority on theMASTER BAP. A warning to the effect that traffic handling will be impaired will be issued if anattempt is made to execute the offline processing on the MASTER machine.

14.3 Tapes

There are two types of tape drives attached to each processor:

• half-inch free standing or rack mounted tape unit, e.g. TU81 or TSZ07

• DAT/Cartridge tape unit built into each BAP, e.g. TK70 or TLZ06

Note: the specific types of tapes is dependant upon individual customer configuration.

Since the DAT/Cartridge tapes are much smaller and also faster, it is recommended that this isused for tapes for internal use. Storage costs will be lower and the tapes themselves are morereliable.

When tapes are used for billing, the choice of tapes for the billing centre is at the discretion ofeach administration.

The operator is prompted for the desired tape drive whenever tape access is required.

Only the tape drives connected to the machine being used for processing can be used. If a tapedrive failure occurs in the machine being used, a BAP switchover should be arranged at a con-venient time so that the other tape drive can be used. When such a switchover takes place, theoffline database is automatically accessed by the new standby processor, so it is not necessary torepeat any of the steps described below.

Archive tapes are produced for both the logfiles and for the offline database. The logfiles are thesource and therefore the archive copies should be retained for as long as it might be necessary to


14-3

reconstruct billing outputs. The archives of the offline database do not need to be kept for so long,but do provide a quick means of recovering the records for one session.

A tape combining facility exists to merge two or more billing tapes to a new target one. This isprovided because a tape spool can hold a much larger quantity of data than is normally outputduring one run of the tape generator. The same facility can be used to duplicate a single tape,provided the same tape drive is used for original and copy. See section 14.9 for details of how touse this facility.

14.4 Disks

The offline database can be archived to disk rather than tape. The disk need not be local to theLES in case of catastrophe. The identity of the default archive disk is configured by HNS. Theoperator can specify another disk identity at the time of archiving, but must have write access tothat device for the archive to succeed.

14.5 File Naming

Logfiles held in the offline database are named as follows :

LOG_yyyymmdd_hhmmss_vn_m.DAT

where

LOG_ identifies that this is a log file - this field is always requiredyyyy represents the year, e.g. 1992mm represents the month, e.g. 06 for Junedd represents the day, e.g. 02 for the second day of the monthhhmmss represents time in hours, minutes and secondsvn_m represents the relevant major and minor software release e.g. v7_2A.DAT identifies the type of file. This field must be in the format shown.

The identity of the individual file does not always need to be entered by the operator. A wild card(*) can be used in its place to refer to all the files with the previous part of the identity, e.g. thesystem will accept LOG*.DAT (but *.DAT is not acceptable).

14.6 Routine Procedures for Processing Offline Records

The offline records follow a set processing pattern for archiving and the preparation of billing data,etc.

The frequency which these procedures should be performed depends on the data beinggenerated in the system. The limits can be considered as :

• daily - which puts an additional load on the staff but ensures that database usage isminimized and that back-ups are available for as much data as possible

• at least every eight days - which makes the operator workload manageable. Thiscould be split up as follows :

1. 1st to 8th of month

2. 9th to 16th of month

3. 17th to 24th of month


17th July 2001

14-4

4. 25th to end of month

The exact timetable can be adjusted as necessary to avoid particular days, such asweekends. Five runs may be needed in some months.

Initially, at least, following the eight-day routine will be adequate. The period of eight days waschosen as the nearest sub-multiple of a month. Any longer period should be avoided.

Normal processing is illustrated in figure 14-1 which references the various stages.

Note , the references below and elsewhere in this chapter to copying, archiving and deletion oflogfiles are only relevant as long as the new autobilling procedures (Chapter 16 are not used.Once autobilling is in use, then the housekeeping procedures described there should be followed.

The stages involved in off-line processing are :

1. Log files are generated automatically as part of the online processing of traffic.These have to transferred at regular intervals from the online area to the offline areaof data storage. Use Copy Logfiles from Online to Offline Area (SOC Viewer -Offline Processing - Options - Housekeeping - Log File Utilities).

The following messages may be displayed:

• Menu Occupied By Another User - Type <RETURN> - The Log file utilitiesmenu is already in use. Only one operator process at a time may access it.

• There is not enough space for the copy - Prior to transferring the log files, acheck is made to ensure there is adequate disk space on the target disk. Ifthis is encountered, the operator should ensure that the directoryOFDB$LOGDIR is empty before trying again.

• A reconciliation error has occurred - Following the copy to the offline area, acheck is made that every log file has a corresponding index file. If there is aninconsistency, then the first action should be to ensure that directoryOFDB$LOGDIR is empty, and then try the operation again. If the error per-sists then contact HNS.

2. Archive the logfiles that have just been copied into the offline area - this gives abackup of the raw data generated by the system. For instance, this is the source ofthe event log if at any time it is necessary to look at past events. Use ArchiveLogfiles from Offline Area (SOC Viewer - Offline Processing - Options -Housekeeping - Log File Utilities). Note that a separate tape is required each timean archive is made; if a tape which already contains information is used, the newinformation will over-write it.

3. Now read the logfiles into the offline database. Use Database Load (SOC Viewer -Offline Processing - Options. This brings up a range of parameters which can be setbefore the report is run. The parameters and their defaults are:

• Modify logfile spec [log*.dat] - this is set to LOG*.DAT in order to ensure thatall the log files in the offline area are processed.

Note 1: if [step 8] has been followed on the previous offline processing ses-sion, the only files in the offline area will be the ones to be processed.However, if files are present in that area which had previously been incor-


14-5

ARCHIVED LOGFILES

ARCHIVED DATABASE

BILLING TAPES

REPORTS

DELETED FILES

OFFLINE DATABASE

BILLING TAPE LISTING

8

8

1

3

2

4

5

(5)

6

7

Brackets indicates choice.

[log_file_billdsk.eps]

(ONLINE) LOG

FILES

(OFFLINE) LOG

FILES

Micro VAX

MASTER BAP

BILLING DATA

[log_file_billdisk.eps]

Figure 14-1. Offline Database Life Cycle


17th July 2001

14-6

porated into the offline database, the user would be warned that these fileshave been incorporated and they will not be incorporated again.

Note 2: the database load over a protracted period of time, dependant uponthe amount of data to be loaded, and can be several hours in the worst case.Only when the load is completed will the operator be returned to the menu.

If, whilst performing a database load, errors do occur then error messages willbe displayed on the screen. Similarly, information messages are displayedwhich show the files currently being processed. This gives a good indication ofhow far through the load the loader has got. The operator can use cursor keysto scroll through the messages. At the end of the load examine the followingfile using the editor:

OFDB$SCRATCHDIR:OFDB_LOADER_ERROR.LOG

If the errors contained in this file appear to be of a serious nature then raise aCSPR, see Appendix F for the procedure involved, ensuring that the contentsof this file are made available to HNS. It may then be necessary to load theoffline database from the archive and repeat the process of loading log files.

The following modify options (together with defaults) are provided:

• Load calls [true]

• Load distress [false]

• Load events [false]

• Load statistics [false]

• Load carry over [true]

This must to be set to true in order to ensure that any incomplete records fromthe previous billing period are included in that period’s processing. For the firstever database load, however, this value must be set to false.

If load carry over is set to false, this will cause the existing database to bedeleted before loading takes place.

In order to generate the various billing tapes only load calls are required to be set totrue. If, however, reports for other than calls are required, load events, load distressand load statistics also need to be set to true.

Note that a database load must be performed using a single logfile specifier; it is notpossible to load two days worth individually into the database using two separatelogfile specifiers and two separate Run Loader commands.

When the correct parameters are entered, select Run Loader to read the logfiles intothe offline database.

If the offline database server is not running a warning message will appear. Theoperator must use Start Offline Database Server (SOC Viewer - OfflineProcessing), if this proves to be the case.


14-7

4. The offline database is archived. This provides the backup for the regeneration ofbilling tapes if these tapes are ever lost or damaged. Use Archive OfflineDatabase (SOC Viewer - Offline Processing - Options - Housekeeping - DatabaseUtilities).

The database may be archived to either tape or disk, depending on which menuoption is selected. In either case the archive data is copied to disk (temporarily in thecase of archiving to tape). The SOCV displays the disk space available and theoperator is prompted whether to continue or quit.

If archiving to tape is selected then a separate tape is required each time an archiveis made; if a tape which already contains information is used, the new informationwill over-write it. This tape can be used in future as the fastest way to be able tore-produce billing tapes or reports from this time period.

If archiving to disk is selected then the operator is prompted for the directory intowhich the database is to be archived. The default is [OFDB$LISTDIR] on the defaultdisk. The operator can respond with a path to a separate disk (and system) usingthe syntax:

NODE::DISK:[DIRECTORY_PATH]FILENAME

Note: The above path is optional. If a separate NODE (i.e. another VAX system) isspecified then the archive may only be possible by including details of an account onthe remote system in the path. An account name (that has adequate access rights)and its password are inserted as follows:

NODE"account_name password "::DISK:[DIRECTORY_PATH]FILENAME

5. Customer Billing record tapes are generated and despatched from the earth station.The tapes contain records of all calls which are complete, i.e. the call record isreconciled, the ICR and all associated DCRs together describe calls for which thereare no outstanding deliveries. Use Billing Data Generation (SOC Viewer - OfflineProcessing - Options) and then the appropriate selection.

An alternative mechanism exists whereby customer billing information can beplaced in a file held on disk. If this facility is required, e.g. where files can bedirectly transferred to the billing centre, thus negating the need for tapes, then selectthe option Generate Customer Billing on Disk (SOC Viewer - Offline Processing -Options - Billing Data Generation) and follow the appropriate instructions.

The generated billing tape has a header record, holding the run number and filename specified in the command line when the Generate Billing Tape function isselected, as described above. The header record also holds a start time and endtime. If no start time was specified in the command line, then the header record starttime is the earliest start time that appears in the logfile data in the database. If noend time was specified in the command line, then the header record end time will bethe latest end time that appears in the logfile data in the database.

6. As soon as a billing tape has been produced, then it should be listed. This is in orderto ensure that the data has actually been copied to the tape. If the tape has not beencopied to successfully then the operator can reproduce the tape.

It is possible to obtain a listing of the customer tapes by invoking List CustomerBilling Tape from SOC Viewer - Offline Processing - Options - List Generation. Alisting of billing data archived to disk can be obtained from the same menu. An


17th July 2001

14-8

explanation of the contents of these tapes may be obtained from the Billing TapesFormats document, Reference [4] and Module 5 of reference [1].

7. Reports are generated as required: Use Report Generation (SOC Viewer - OfflineProcessing - Options - Report Generation) and then the appropriate selection.Alternatively select Default Reports from the same menu to produce all the relevantreports (this is described in section 14.11.5).

8. The final action should be to delete the billing files from the online and offline areas.This should only be performed once the operator is sure that the data has beencopied and billed correctly, ideally once there is proof of billing.

Delete the logfiles in the online area that have been copied to the offline area. UseDelete Copied Logfiles from Online Area (SOC Viewer - Offline Processing -Options - Housekeeping - Log File Utilities). Once this option is selected, as long asthere are files that qualify for deletion, the operator is prompted whether or not todelete files singly, delete all files, or quit the operation. The prompt is:

Delete filename - (Yes No All or Quit)

The system ensures that only logfiles which have been copied can be deleted.Using VMS to delete logfiles is NOT recommended since no checking for archivedstatus is performed before deletion.

Delete offline logfiles: Use Delete Logfiles from Offline Area (SOC Viewer - OfflineProcessing - Options - Housekeeping - Logfile Utilities). Use of VMS to delete thesefiles is not recommended.

Start again at step 1 for the next billing period.

Note 1: The process of transferring logfiles from the offline area into the offline database ensuresthe deletion from the offline database of all records which are no longer required, i.e. all reconciledand billed call records, if load with carry over is set to true. If load with carry over is set as false theexisting contents of the database will first be deleted.

Note 2: For customers who invoke this procedure on a weekly basis (say) but still wish for a fullset of reports it should be noted that the procedure could be very slow, depending upon the speedof the BAP processor, and may also use a large amount of diskspace. The recommended optionsare:

• follow the above procedure daily for billing and reports.

• follow the procedure weekly but use only for billing. (When loading the off-linedatabase, load only call record data but not events, distress and statistics data.)

Note 3: Steps 3,5,6 and 7 above can be run automatically by the operator using DefaultProcessing SOC Viewer - Offline Processing - Default Processing Menu. The billing data iscopied to tape only. However if used then the operator must ensure that all other steps are com-pleted successfully. This operation will also produce a full set of default reports as described insection 14.11.5. HNS recommends that, when supported, automatic processing of offline recordsis used.

Note 4: Log files in the offline database can be archived, listed, deleted and restored from tapeusing Default Housekeeping SOC Viewer - Offline Processing - Default Processing Menu. Thisminimizes operator involvement in these operations.


14-9

14.6.1 Automatic Processing of Offline Records

Automatic billing and archiving is not supported on the Mexico LES.

14.7 Off-line Database Housekeeping

Part of the installation procedure undertaken by HNS prior to starting up the ACSE is to configurewhich disk(s) that are to be used for offline processing and where the various files generated areto be stored. These are accessed via pre-determined disk logical names.

• Reports are stored in the area OFDB$REPORTDIR

• Lists are stored in the area OFDB$LISTDIR

• Log files are stored in the area OFDB$LOGDIR

• Temporary and diagnostic files are stored in the area OFDB$SCRATCHDIR

In the first three of these, unwanted files can be removed using SOC Viewer as has already beenindicated in the previous section, i.e.

• Delete a Report (SOC Viewer - Offline Processing - Options - Housekeeping - ReportUtilities)

• Delete a List (SOC Viewer - Offline Processing - Options - Housekeeping - ListUtilities)

• Delete Logfiles from Offline Area (SOC Viewer - Offline Processing - Options -Housekeeping - Logfile Utilities)

Unwanted files can be removed from the OFDB$SCRATCHDIR area using VMS commands:

• $ SHOW LOGICAL OFDB$SCRATCHDIR - shows the actual disk and directorydefined as OFDB$SCRATCHDIR. Note the disk identity (Characters to the left of thecolon ":").

• SHOW DEVICE DISK_ID - where DISK_ID is the disk noted above. The number offree blocks on the disk will be displayed.

• $ PURGE/LOG OFDB$SCRATCHDIR - removes all but the latest version of the filesin this area. This command is generally sufficient to keep this disk tidy.

• The OFDB$SCRATCHDIR area should have at least 100,000 blocks free before at-tempting to combine tapes.

14.8 Abnormal Processing of Records

The routine archiving of both the logfiles and the offline database means that recovery from afailure should be straight-forward. In principle, it is necessary to restart from the point of failure andrepeat the processing which would normally be done from that point.

No attempt should be made to perform abnormal processing until routine processing has com-pleted.

To create billing and report data for some period in the past, for which archived data is available.That data may be available on tape (which has to be fetched from storage and mounted on a


17th July 2001

14-10

compatible drive) or disk (which can be accessed directly). Either way the following steps must befollowed:

1. Ensure that the offline database is archived for the last billed run (if not done al-ready). Use Archive Offline Database to Tape or Archive Offline Database toDisk (SOC Viewer - Offline Processing - Options - Housekeeping - DatabaseUtilities).

2. Restore the database which was archived for the period previous to that where datahas been lost. Use Restore Offline Database from Tape or Restore OfflineDatabase from Disk (SOC Viewer - Offline Processing - Options - Housekeeping -Database Utilities).

3. Read the archived log files relating to the period of interest into the offline area. Loadthe archive tape onto the tape reader and then use Restore Logfiles to OfflineArea (SOC Viewer - Offline Processing - Options - Housekeeping - Logfile Utilities).

4. Load the log files into the offline database and produce tapes and reports as re-quired. Use Database Load (SOC Viewer - Offline Processing - Options), BillingData Generation (SOC Viewer - Offline Processing - Options - Billing DataGeneration) and Report Generation options (SOC Viewer - Offline Processing -Options).

5. Restore the database which was archived for the last billed run.

14.9 Tape Combining

In the particular cases of Billing tapes, it may be necessary to transfer the information on severaltapes onto one tape before it is sent off from the earth station.

This utility initialises a tape and writes onto it the contents of two or more other tapes. Optionally itmay be used to duplicate a single tape. The utility will only merge tapes of the same type, i.e. itwill only merge one billing tape with another.

If tapes for two ocean regions are combined, the identity assumed will be that of the first regionloaded.

Following these steps :

1. Use Combine Tapes (SOC Viewer - Offline Processing - Options - Billing DataGeneration). The user is prompted to load the output tape in the drive; this tape isthen initialized so ensure that there is no useful information on it before loading it.When the tape is loaded onto the tape drive, the operator is asked to enter the nameof the tape drive, e.g. ’MUA0’.

2. When the tape has been initialized, the operator is asked to remove the output tapeand load the first tape to be combined. When the tape is loaded, press , andReturnthe data will be read.

3. When all the data records have been loaded, the operator is prompted to mountanother tape containing further data. To use the utility as a copier, the operatorshould indicate here (by typing N) that no further tapes are to be loaded.

4. When the loading of all data records is complete, the operator is prompted to placethe newly initialized output tape in the drive to be used to store the combined datafile generated from the previous tape(s). Data will be automatically written to this


14-11

tape.

5. Mark the new output tape with the title and date it was created, so that it can beeasily identified in the tape storage rack.

The combined tape has a header record, holding the run number and file name specified whencombining the tape. The header record also holds a start time and end time. The header recordstart time is the earliest start time that appears in the files loaded from the previous tape(s). Theend time is the latest end time that appears in the files loaded from the previous tape(s).

14.10 Log-File List Generation

The operator is able to list the log files held in the offline area, files on tapes and billing dataarchived to disk. Use Lists generation (SOC Viewer - Offline Processing - Options) and then,with the appropriate tape loaded if necessary, select as desired option :

• Log files

• Customer billing tape

• Customer billing disk file

If for any reason, there is a problem with reading the tape, use the Quit option from this menu.

14.11 Offline Report Generation

Each report consists of a file holding formatted data, e.g. statistics or call records, which has beengenerated from the Offline Database.

Except when Default Reports are specified, the operator will be required to enter further detailspecifying the range of data to be processed (or else accept the system defaults). All reportprograms have parameters for the start time and end time of the required data.

Offline reports mostly display statistics produced by the LES online traffic system. These can beused to help highlight any long term problems e.g. due to lack of capacity.

Offline reports are obtained by a two stage process, i.e. :

• generate the report

• print or view the report

Use Report Generation (SOC Viewer - Offline Processing - Options) and then the desired selec-tion to generate the report, as shown on figure 4-8. The operator will be invited to set variousparameters, including the start and stop times, before running the reports. Only some parametersmust be set by the operator. For those parameters which are not set by the operator, the systemwill uses declared defaults which generally cause ALL the options to be used.

To print or view a report, use Report Utilities (SOC Viewer - Offline Processing - Options -Housekeeping - Report Utilities). Select Print a Report to obtain output on the designated reportprinter, and View a Report to display it on the SOC Viewer screen. This menu is used to delete areport once it is no longer required. Failure to regularly delete unwanted reports will result ingradual exhaustion of the available disk space.

The reports available are:


17th July 2001

14-12

• channel unit chassis statistics

• channel unit rack statistics

• ISL link layer statistics

• TDM group statistics

• call completion summary

• mobile call summary

• event log

• distress summary

• call record list

• all mobiles

• LES call (FROM and TO) ships

• EGC call

• MES analysis

• performance profile

• telex statistics

• driver statistics

These reports are additional to those available in the online system, described in section 13.3.

Each report has a file name. The initial settings are shown below and should be retainedwherever possible so that all staff know where to find the information.

Dates and Times are of the format MMM DD YYYY hh:mm:ss, where

DD = Day (1..31)MMM = Month (JAN,FEB,MAR,APR,MAY,JUN,JUL,AUG,SEP,OCT,NOV,DEC)YYYY = Year (1901..current year)hh = hours (0..23)mm = minutes (0..59)ss = seconds (0..59)

where a date is used without a time then the default time is midnight for the beginning of the datespecified.

The ’Start Time’ must be further in the past than the ’End Time’.


14-13

14.11.1 Statistics

The Channel Unit Chassis Statistics : CU_CHASSIS_STATS.RPT(SOC Viewer - Offline Processing - Options - Report Generation - Statistics Reports) providesstatistics on the performance of Channel Units.

The output shows, against each channel unit, the following in relation to the link between the CUCFEP and the channel unit (i.e. internal to the ACSE) :

FEP nameChassis IDOcean regionSlot numPolls Number of polls from the CUC to the channel unitResponse timeouts Number of times CU fails to respond to pollRX CRC errors Number of responses from CU with error, detected by

sumcheckTX CRC errors Number of CU received polls with error, detected by

sumcheckCU ups Number of times CU becomes availableCU downs Number of times CU becomes unavailable

and the following for TDM demods only which indicate the quality of the transmissions from theTDM modulator, over the satellite and back to the TDM demodulator :

Framing errors Number of times the demod fails to detect the framesequence in the signal

Dem RX CRC err Number of time the demod detects a CRC error onthe received signal

Dem RX car los Number of times the demod loses carrier

Note that some of the values in this report and similar ones are very large.

The Channel Unit Rack Statistics : CU_RACK_STATS.RPT (SOC Viewer - Offline Processing -Options - Report Generation - Statistics Reports) provides statistics on a channel unit rack.

The following is provided for the link between the CUC FEP and the ASM in the channel unit rackfor each FEP pair :

FEP nameOcean regionPolls Number of polls over the linkRX CRC errors Number of responses with errorsPort ups Number of ASM returns to servicePort downs Number of ASM failuresMissed frame timings Number of times ASM failed to report start of TDM frameStatus change messages Number of messages from ASM with change in the status

information which it reports (e.g. CU rack power supply)

and the following in relation to the Master Timing Modules :

Auto MTM switchovers Selected by the ASMManual MTM switchovers Front switch on MTMMTM-A ups Number of times MTM-A returns to serviceMTM-A downs Number of MTM-A failuresMTM-B ups Number of times MTM-B returns to service


17th July 2001

14-14

MTM-B downs Number of times MTM-B failures

Also the following in relation to the power supplies and blower on the rack :

Blower ups Number of times blower becomes workingBlower downs Number of times blower failsPower supply A ups Number of times power supply A becomes workingPower supply A downs Number of times power supply A failsPower supply B ups Number of times power supply B becomes workingPower supply B downs Number of times power supply B fails

The TDM Group Statistics : TDM_GROUP_STATS.RPT (SOC Viewer - Offline Processing -Options - Report Generation - Statistics Reports) provides information on the performance of eachTDM group.

For the TDM Modulator, the following is shown

FEP nameOcean regionTDM group IDFrames TX Number of transmitted framesPackets TX Number of transmitted packetsSplit packets Number of packets which span a frame boundaryBytes TX Number of bytes transmitted

For the signalling channel, the statistics are in tabular format showing :

FEP nameOcean regionTDM group IDLUN Logical channel unit numberOne-slot packets Number of packets contained in a single slotMulti-slot packets Number of packets contained in multiple slotsSlots acked Number of packets successfully receivedSlots nacked Number of packets not unsuccessfully receivedCont slots Number of slots where packet reception continues in the

same slot, but in the next frame

The Call Completion Summary Report : CALL_COMPLETION.RPT (SOC Viewer - OfflineProcessing - Options - Report Generation - Statistics Reports) gives details of number of calls andthe number as a percentage of the whole for each which produce a particular call completioncode. Distress calls are listed separately.

Selection criteria are :

• Start and end time

• Start and end serial number

• Driver

The output is in tabular format, with an entry for each call completion code which has at least onecall, consisting of the following data:

CCC Call completion codeCall Status Text Textual description


14-15

Number of CallsNumber of Calls as PercentNumber of DistressesNumber of Distresses as Percent

The Mobile Call Summary Report : MOBILE_CALL.RPT (SOC Viewer - Offline Processing -Options - Report Generation - Statistics Reports) provides statistics on the performance of mobileswhose identification numbers fall between a selected input range.

The output is in tabular format, with an entry for each mobile number for which there were calls:

Mobile NumNum of CallsRepeated PacketsNum of FailuresNum of Failures as Percent

The Telex Route Statistics : TELEX_ROUTE_STATS.RPT (SOC Viewer - Offline Processing -Options - Report Generation - Statistics Reports) provides statistics on the number of successfuland unsuccessful incoming and outgoing calls and times out of service, engaged and free, as apercentage, for one or all of the telex routes served.

The output is in tabular format, with an entry for each route employed by the telex driver:

Successful I/C CallsSuccessful O/G CallsUnsuccessful I/C CallsUnsuccessful O/G CallsTime OOSTime EngagedTime Free

14.11.2 Events

The Event Log Report : EVENT_LOG.RPT (SOC Viewer - Offline Processing - Options - ReportGeneration) gives a list of all the events for the duration specified. Any event that is repeatedmany times may highlight the need for investigation into its cause.

For each event, the following is given :

Date and time Of the eventClass BAP, FEP, etc, as listed in section 11.1Level Urgent, semi-urgent, as listed in 11.1Description Plain textComponent Reporting the event, as listed in 11.1Event number Corresponds to number given in section 11.2

14.11.3 Distress

Distress Message Summary Report : DISTRESS_SUMMARY.RPT (SOC Viewer - OfflineProcessing - Options - Report Generation) displays a summary list of distress messages. Foreach message the a selection from the following is given, depending on applicability. Separateentries are provided for message receipt and for message delivery:

Message ID e.g. MES Distress Receipt, EGC Receipt, Distress DeliveryMRN Message Reference Number


17th July 2001

14-16

Message Kind e.g. Mobile Originated, EGC, Terrestrial to MobileICR Incoming Call Record NumberDCR Delivery Call Record Number (if applicable)Fwd MES ID Forward MES ID (of mobile if applicable)Rtn MES ID Return MES ID (of mobile if applicable)EGC Details Type of EGC message (if applicable)Orig MES Originating MES (if applicable)Dest MES Originating MES (if applicable)Destination Destination address (if applicable)CCC Call Completion Code (if applicable)Call Input Time time message completely received (if applicable)Time of Arrival time message arrival detected (if applicable)Call Delivery Time time message delivered (if applicable)

14.11.4 Call Records

The Call Record List Report : CALL_RECORD_LIST.RPT (SOC Viewer - Offline Processing -Options - Report Generation - Call Record Reports) provides details of call records. The operatorcan filter the classes of call records reported on by supplying values to parameter or use thedefault ALL. Either a summary or detailed report can be generated.

Selection criteria are :

• Start and end time

• Direction: incoming or delivery

• Driver: e.g. X25, SAT

• Call Nature: e.g. message, NDN message or distress alert

• Completion Code: -1 to 999

• Origin: origin address

• Destination: destination address

• Report type: summary or detailed

The summary output gives a tabular summary, for each incoming and outgoing message consist-ing of the following data:

Serial Num Internal LES referenceMRN Message Reference NumberDirection incoming or deliveryDriver e.g. X25, SATCall Nature e.g. message, NDN message or distress alertCompletion Code -1 to 999Priority Normal or DistressRequest Received Time request received

The detailed output consists of the following data:

Serial Num Internal LES referenceMRN Message Reference NumberOriginal Network Network of message originator


14-17

Call Nature e.g. message, NDN message or distress alertDirection incoming or deliveryDriver e.g. X25, SATCall Origin Address of message originatorPriority Normal or DistressCCC Completion Code (-1 to 999)Call Destination Address of message destinationRequest Received Time request receivedStart of Message Time start of message receivedCompletely Received Time message completely received

The The All Mobiles Report : MES_TO_LES.RPT (from MES), LES_TO_MES.RPT (to MES)(SOC Viewer - Offline Processing - Options - Report Generation - Call Record Reports) givesdetails of all call records with call completion codes within a specified range, and transmitted eitherto or from mobiles, for a specified time period, as selected when the report is generated.

The output gives the following :

DateCALL REC ID Call record numberORIGIN ID Originator of message e.g. mobile number, X121 addressMESS REF NO Message reference numberDIRECTION To or from mobileCMP CDE Call completion codeCONFM DEL. Has delivery been confirmedTDM LUN TDM logical channel unit usedSIG LUN Logical signalling channel unit usedPACKETS MSG Number of packets in the messagePACKETS RPT Number of repeat packet transmissions necessaryACKNOWLEDGEREQUESTS TOT Total number of acknowledgement requestsACKNOWLEDGEREQUESTS FIRST Time of first acknowledgementACKNOWLEGEREQUESTS LAST Time of last acknowledgementMAX OFFSET FREQ Frequency offset of received signal from nominalMAX OFFSET TIME Time offset from nominal start of frameMIN SIG Signal to noise ratio

There are two reports for calls to and from mobiles :

• LES Call Report (from MES) : LES_CALL_FROM_MOBILE.RPT

• LES Call Report (to MES) : LES_CALL_TO_MOBILE.RPT

accessed by (SOC Viewer - Offline Processing - Options - Report Generation - Call RecordReports). These provide details of calls to or from MESs, of a specified call type, and withcompletion codes between a specified range.

Note: Some calls reported may be failed calls. If, as a result or cause of failure, any of the timesassociated with that call are invalid or have been corrupted, then the system earliest time will bedisplayed. This is 00:00 hours, 1st January 1901.

The information presented for the from mobile report is :

Date Date call made


17th July 2001

14-18

MRN Message reference numberCall Nature Type of message

e.g. message, non-preassigned data reportCCC Call completion codeAss Desc Assignment DescriptorAss Dest Destination Network requested by MESLen Length of message, in packetsSlot Slot used in signal channelFreq Frequency of message channel used (if applicable)Msg LUN Logical channel number of the message channel

used, if applicableAnnounce Time of announcementPending Time allocated for delivery of messageDestination Destination address (if applicable)Dest Ext Len Destination Extension LengthDestination Network Network used for deliveryMES Busy Time MES became busyMES Idle Time MES became idle

The information presented for the to mobile report is :

Date Date call madeMRN Message reference numberCall Nature Type of message

e.g. message, NDN message or distress alertCCC Call completion codeAss Resp CU Signalling channel used for assignment responseFrame Frames usedSlot Slot usedTDM LUN TDM logical channel unit number, if applicableSig LUN Signalling logical channel unit number, if applicableAnnounce Time of AnnouncementAssign Time of AssignmentPending Time allocated for delivery of messageDestination Destination address (if applicable)Packet Size Size of packetNum of Pkts Number of packetsNum of Repeated Pkts Number of repeated packetsMES Busy Time MES became busyMES Idle Time MES became idle

The EGC Call Report : EGC_CALL.RPT (SOC Viewer - Offline Processing - Options - ReportGeneration - Call Record Reports) gives details of all EGC type calls. The output gives the fol-lowing :

Date Date of EGCSerial Num Call record numberMRN Message reference numberOrigin Originator addressCreation Time of call creationPkts Number of Packets in EGC messageInterval EGC Repetition IntervalTX Maximum Maximum number of transmissionsTX Number Number of transmissions to dateService EGC Service (C2 code)Priority EGC Priority


14-19

EGC Address (C3 code - if applicable)

The MES Analysis Report : MES_ANALYSIS.RPT (SOC Viewer - Offline Processing - Options -Report Generation - Call Record Reports) gives an analysis of the performance a specified mobileover the specified time, specified range of call completion codes and for one or all mobiles, andshows :

Date Date call madeMRN Message reference numberSerial Num Call record numberMobile Mobile numberCall Nature Type of call

e.g. Message, NDN message or distress alertCCC Call completion codeDirection Direction of call, e.g. LES_TO_MESSig LUN Signalling channel logical channel numberFreq Frequency of signalling channelStart Time of start of callComplete Time of completion of callVolume Call VolumePkts Number of packetsRepeated Pkts Number of repeated packetsLCN Logical channel unitError Code Provides further detail of error (for HNS use)Ack Req Tot Total number of acknowledgement requestsS/N Signal to Noise ratio, see belowMax Freq Off Maximum and minimum frequency offsetMin - variation in frequency of received signal,

as described below.Max Time Off Maximum and minimum time offsetMin - variation in time of start of burst from mobile

as described belowMax Sig Lvl Maximum and minimum signal levelMin - variation in signal level from the mobile, in dB

as described below

Signal to noise value is a 16 bit direct measure of Eb/No from the TDM and SIG demodulators. Itis not measured on the MSG demodulator, since the relevant value has already been obtained onthe SIG demodulator. To convert to dB, use the formula :

Signal-to-noise {dB} = 10log(12800/signal-to-noise{value})

Frequency offset is a 16-bit signed 2’s complement value in steps of 1200/16384Hz, according tothe following formula :

Frequency offset Hertz+23211 to +32767 greater than 1700-23210 to +23210 Frequency offset x (1200/16384)-32768 to -23211 less than -1700

Timing offset measures the delay relative to the beginning of the slot, of the burst in quarter TDMsymbol units. This value is only measured by signalling channel demodulators. To calculate thetiming offset in msecs, divide the timing offset in quarter symbols by 4.8.

Signal level is a positive direct output from the demodulator. To convert to dBm, use the followingformula :


17th July 2001

14-20

Signal level dBm>16384 greater than -60dBm1024 to 16384 -60 + 20log(signal level/16384)<1024 less than -84dBm

The Call Completion Code Summary Report : CCC.RPT (SOC Viewer - Offline Processing -Options - Report Generation - Call Record Reports) shows for any specified range of call comple-tion codes and time period the number of calls, time of first occurrence, time of last occurrence,and percentage of the total number for each call completion code which was used.

The Driver Specific Call Completion Code Report : DRIVER.RPT (SOC Viewer - OfflineProcessing - Options - Report Generation - Call Record Reports) gives the number of successfuland failed calls, total calls and percentage success, both for incoming and outgoing calls, througheach of the satellite, telex, X25, X400, Fax drivers, plus sum for all drivers, for a specified priorityor all priorities. Also these totals are given for each of the FIVE most used call completion codes(incoming and outgoing) for all the drivers.

The All Call Statistics Report : ALL_STATS.RPT (SOC Viewer - Offline Processing - Options -Report Generation - Call Record Reports) gives the number of successful and unsuccessful calls,NDNs and PDNs through each of the supported terrestrial drivers, for a specified priority or allpriorities, in the period specified, for each of the destination networks which may specified in theassignment request packet from a mobile.

For each of Telex, PSTN, CSDN, PSDN, X400, CNID, SAC, Other, Mobile, Ocean, UnknownDestination networks as well as Totals of all these and percentage of all calls, for each of theTelex, X25, X400, Fax, Satellite and Totals of all these, are shown for the following :

Number of Messages Successfully deliveredNumber of Messages Failed to deliverNumber of NDN/PDN Successfully deliveredNumber of NDN/PDN Failed to deliverTotal Successfully deliveredTotal Failed to deliver

14.11.5 Default Reports

Reports utilities menu

The operator can automatically generate a suite of all reports, with default parameters, usingDefault Reports SOC Viewer - Offline Processing - Options - Report Generation. This writesreports, with filenames as shown in table 14-1. Reports can then be viewed, printed and deleted,using the options in the Reports Utilities Menu SOC Viewer - Offline Processing - Housekeeping.The reference column indicates where, in this manual, a description of the report exists.

[OPG14.mss]

A4-OPG-003076 Operator ControlIssue 3.23 - Accepted17th July 2001

14-21

Report Name File Reference

Call Completion Code Report CCC.RPT 14.11.4

Driver-Specific Call CompletionCode Report

DRIVER.RPT 14.11.4

All Statistics Report ALL_STATS.RPT 14.11.4

Channel Unit Chassis Stats Report CU_CHASSIS_STATS.RPT 14.11.1

Channel Unit Rack Stats Report CU_RACK_STATS.RPT 14.11.1

ISL Link Layer Stats Report ISL_LINK_LAYER_STATS.RPT 14.11.1

TDM Group Stats Report in TDM_GROUP_STATS.RPT 14.11.1

Event Log Report EVENT_LOG.RPT 14.11.2

Distress Summary Report DISTRESS_SUMMARY.RPT 14.11.2

Call Record List Report CALL_RECORD_LIST.RPT 14.11.4

Call Completion Summary Report CALL_COMPLETION.RPT 14.11.1

Mobile Call Summary Report MOBILE_CALL.RPT 14.11.1

Telex Route Stats Report TELEX_ROUTE_STATS.RPT 14.11.1

All Ships Report (MES to LES) MES_TO_LES.RPT 14.11.4

All Ships Report (LES to MES) LES_TO_MES.RPT 14.11.4

LES Call Report (From Mobile) LES_CALL_FROM_MOBILE.RPT 14.11.4

LES Call Report (To Mobile) LES_CALL_TO_MOBILE.RPT 14.11.4

EGC Call Report EGC_CALL.RPT 14.11.4

MES Analysis Report MES_ANALYSIS.RPT 14.11.4

Table 14-1. Default Report Names, File Names and References

Operator Control A4-OPG-003076Issue 3.23 - Accepted

17th July 2001

14-22

A4-OPG-003076 Operator ControlIssue 3.23 - Accepted17th July 2001

15-1

Chapter 15

OPERATOR CONTROL

15.1 Administration of Operators

The supervisor must configure operators names and initial passwords into the system using theOperator Definition form (SOC Forms - Operator). Select the form, enter the name and press

. For a new operator, enter the initial password and the access group (see below) and thenShowpress .Add

For an existing operator, the password and access group will be displayed. If a change is re-quired, press , enter the new value and then press to change or to removeModify Enter Deletethe operator from the system altogether.

A display of all the operators is available on the Operator Display form (SOC Forms - Operator).Select the form, optionally enter the access group number and press . An individualFirst Pageoperator’s entry can be accessed by placing a Y in the left hand column and pressing toSelectbring up the Operator Definition form.

Operator Access Groups are a means of defining which functions an operator can access. Up to15 groups - numbers 1 to 15 are valid, number 0 is reserved - can be defined and for each groupthe SOC forms and functions keys which they can use are identifiable. The access group againsteach operator is defined in the Operator Definition form described above. The functions for eachaccess group are defined in the Access Group Definition form (SOC Forms - Operator).

Select a form by entering the name of that form (up to 15 characters), together with an accessgroup number (1 to 15), and press . Against each of the applicable function keys, there willShowbe an entry of Y or N, according to whether the group should have access to that function or not.To change these settings, press and amend each entry as required. When all the entriesModifyare correct press . An extensive help is provided which gives the names of all the forms andEnterthe meaning to each of the function keys associated with that form.

One default access group (0) will be configured with access to all functions. This is strictlyreserved for HNS or system operator use when configuring the system. Initially all other accessgroups are configured as allowing all ’read’ type operations and disallowing all ’write’ type opera-tions.

15.2 Changing Passwords

The initial password is set up by the supervisor, as described in section 15.1 but each operatorcan change his password at any time thereafter by selecting the Change Password form (SOCForms - Operator). Enter the current name and password and then enter the new password twice -once against New password and then once against Confirm password. Finally press .Change

The password is limited to 8 characters.

[opg15.mss]

AutoBilling A4-OPG-003076Issue 3.23 - Accepted

17th July 2001

15-2

A4-OPG-003076 AutoBillingIssue 3.23 - Accepted17th July 2001

16-1

Chapter 16

GUIDE TO AUTOBILLING

16.1 INTRODUCTION

The Advanced billing process described here encompasses two enhancements to the way thatbilling operates when compared with the former billing process. The fundamental change is thatthe off-line database is no longer used for billing. Instead the log files are read and processedusing cached memory. Reconciliation is performed as soon as the corresponding parts of callsare found. In this way, there is no longer any need for repeated very large database searches andthus the execution time is considerably reduced. This enhancement is known as Faster billing.

The next change is in the way billing is run. Faster billing can be run in two ways. The first way isManual billing which simply makes one call to Faster billing with the set up required for this in-dividual billing run. The second way to run Faster billing is called Auto billing which is set up toallow billing to be configured to run repeatedly at a given interval of time (e.g. once per day). Anew set of menus have been provided within SOCV (offline) which control this.

This chapter provides the following information:

• The basic concepts of Advanced billing, covering ’faster’, ’auto’ and ’manual’ billing.• A description of the actions required to set up a billing run• A full description of each of the SOCV menus which support autobilling and manual

billing.• Journal output files.• List of related alarms and events.• A section on ’Operator Procedures’ presents simplified instructions for the sequence

to be followed when performing some of the more likely operator actions.• ’Error Recovery’ instructions to assist the operator in the event of errors being

reported - section 16.9 Autobilling error recovery.

16.1.1 Use of OFDB - precautions

If the customer wishes to generate offline database reports then the OFDB will need to be loaded.If no offline reports will ever be required then the offline database can be removed from the sys-tem.

NOTE Advanced Billing MUST be carried out on these logfiles BEFORE they are copied to theoffline area.

In addition, the online files should be archived, but not deleted, before copying to offline. This willensure that the billing run can be repeated at a later date, if necessary, by re-loading from archive.


17th July 2001

16-2

16.2 FASTER BILLING

Unlike the earlier method, billing no longer requires that the selected log file data be loaded intothe offline database. Instead, the call reconciliation is performed in cache The code that generatesthe billing records and writes them to disk (or tape) is unchanged. This gives a high level of con-fidence in the correct contents of the billing records.

The billing process reads the call records from the logfiles in the order they are logged. Datareports are billed directly as are ICRs that do not require a DCR for billing. ICRs that are billed inconjunction with DCRs are stored in local cache until their DCR is read from the log files. Once anICR has been reconciled with all of its DCRs it is removed from cache. At the end of a billing runthe ICRs that remain in cache are copied to a carry over file, to be used in the next billing run.Previously, having selected a DCR, billing would then search the WHOLE of the ICR table (in theloaded OFDB) for the associated ICR.

The earlier billing method would result in billing file entries based on a delivery initiation or comple-tion time whereas faster billing, as explained above, processes the data in the order that it wascreated. This will produce a change in the order that entries appear in the billing file when compar-ing the two billing methods. For calls that are a success the order will generally be the same. Forcalls that fail on final delivery they will appear later in the log. This fact should be noted if com-parisons are to be made between billing data generated by both methods.

Note that for any given billing run, the faster billing is likely to be 10 to 20 times quicker than forthe earlier billing.


16-3

16.3 AUTOBILLING

The autobilling function handles the periodic running of faster billing (already described above) . Itis responsible for the following operations:

• Health check of the partner node. Raises an alarm if billing is not running on thepartner node.

• Checks that the current BAP is in the correct mode to run billing.• Checks that the previous run of faster billing was a success. If not raise an alarm and

either continue or terminate.• Checks that the copy of the billing output was a success. If not raise an alarm and

either continue or terminate.• The locking of billing across both BAPs.

These terms are fully explained below.

The faster billing function is responsible for the extraction of the billing data directly from the logfiles.

Throughout this document reference is made to the start and end billing times. By this is meantthe time range to bill over, not the time any individual billing run was started or completed. Theterm autobilling run refers to the actual execution of Faster billing.

Access to the new autobilling is via the offline SOCV, using the existing autobilling option in theBilling Data Generation menu. Access to this point has not been changed.


17th July 2001

16-4

16.3.1 Billing process

Once started, billing will execute periodically at a period defined by the operator. On running itexecutes the following operations.

• Check that it is on the standby BAP.If not, check that the billing process exists on a batch queue on the standby BAPraising an alarm if not. On the standby BAP the reciprocal check will be run. Once abilling run has started it will continue to completion even if a BAP switch occurs mid-run. Before starting a new automatic billing run on the standby, a check will be madeto see if billing is already running (for example a manual run started by the operator orpost BAP switch billing not yet completed on the master) if so then it will reschedulethe next billing run.

• Maintain a journal file - OFDB$CACHE:User_Journal.LisAt the end of each billing run the billing subsystem will append the following infor-mation to the journal file on the shadow set.

• The name of the carryover file used at the start of the billing run.• Name of billing file produced.• The start and end times covered by the billing run.• A flag to show success or failure of the copy operation.

(A full list with explanation may be found in section 16.6.1)• Check that sufficient disk space exists if billing to disk (this can only be an estimate

based on the size of the largest output file).• Run billing covering the specified interval from the last ’end’ time.

On completion of billing

• Copy the billing file to the designated destination.• Delete the local version of the billing file (if the copy was a success AND ’Delete after

copy’ was requested at time of set up).• Write details of the billing run to the User_Journal file.• Write the time of the last run and the outcome to its own journal file.• Reschedule billing to run again in a user configured interval.

Alarms will be raised should the copying of the billing file fail. Remedial action is then taken by theoperators. The choices made during billing set up allow for billing to be either suspended or tocontinue if the billing file copy fails. See section 16.9 on error recovery.

Billing will leave the log files in the online area and the carry over files in the carryover area(OFDB$CACHE ). It is an operator task to backup these files on a periodic basis. These operationsshould be performed at a frequency dependant on disk space available.

The billing output file name will be of the following format:BILLING_YYYYMMDDHHMM.DAT

This may be found in OFDB$LISTDIR provided that the ’delete after (successful) copy’ option hadnot been requested during configuration.

16.3.2 Billing setup procedure

This section describes the basic requirements for setting up autobilling. Following sections givethe specific details required at each menu level.

Assuming that billing is not running, the operator must first define the configuration for billing


16-5

operation. This is a ’one off’ requirement for all autobilling sessions on each BAP. (See 16.5.2.1’Auto Billing Configuration’ below). It is here that the billing interval and ultimate destination of thebilling output files are defined. The settings are written to a data file which is read on initiation ofautobilling. However if any changes are required here, then auto billing does not need to be re-started for the changes to take effect. This configuration data is read every time a billing run starts.Hence any changes will be acted upon at the next scheduled billing run.

Having defined those parameters which are most likely to remain unchanged, the operator mustuse the ’Start Autobilling’ option (see 16.5.3 below) to define the remaining parameters includingthe start time for the autobilling run. Note that generally this start time should only need to beset/changed before the first ever auto billing run. Subsequently the start time will be taken to bethe end of the last billing run. This is stored in the file Journal.Lis and is read by the billing process.

It is here also that ’sensitive’ information for the Billing file operation such as the remote copynode’s password is entered, since, unlike the billing configuration details above, none of this infor-mation is written to file.

16.3.3 Billing housekeeping procedure

Once autobilling has been started, the operator must perform various housekeeping functions (see16.5.5 below). This will usually mean the backing up and deletion of old log, and carry over files,along with occasional journal file truncation. For this purpose, a ’Housekeeping’ menu has beenprovided within the autobilling area. This has been tailored to suit the auto billing procedures andshould therefore be used in place of the OFDB housekeeping facilities.

It will not be possible to delete logfiles from the online area unless both the following are true:

• The log files have been backed up to tape.• The logfiles have been billed at least once.

With the exception of journal file truncation, any or all of the above procedures may be performedautomatically on completion of each billing run. In addition, provided that two tape drives are avail-able, the latest billing output can also be copied to tape. See section 16.5.6 below for full details

16.3.3.1 Lock/Unlock billing

Under certain circumstances it will be desirable to lock out or prevent billing from taking place.The most likely occasion for this is when preparing the standby BAP for a new installation and/ortaking backups of system or quorum disks. It should be remembered that billing is not dependanton having the host BAP running. Therefore in order to prevent unnecessary file changes duringthis period, billing should be ’locked’.

On ’unlocking’ billing, generation of the ’missing’ billing data files will commence within oneminute. The billing process will be aware of the excess of un-billed log files (by virtue of thegreater time span of these files). In this case, in order that the billing centre does not becomeoverloaded with an unusually large file, billing will be performed in as many steps of the desiredtime span as required to clear the backlog. This will result in two or more files being produced ofthe same size and content as if there had been no pause.

The operator must, of course, ensure that the lock out is not of such duration as to allow the diskto fill with new log files before the earliest logs can be billed, archived and deleted.


17th July 2001

16-6

16.3.4 Account name and password changes

It should be remembered that to run correctly, auto billing requires that the account names andpasswords be defined for both the partner BAP node and the remote target nodes for Billingoperations. If any of these are changed for reasons of security or for the purpose of granting HNSaccess to part of the system, then errors will occur. Section 16.5.3 shows where these passwordsare defined for use by autobilling. Section 16.5.5.2 indicates how to alter the target node’spassword for the CSV file copy operation.

In the event of a BAP account password change, then an alarm will be raised by auto billing to thiseffect. However billing will still be able to continue normally though will not be able to detect theloss of the autobilling batch job on the offending partner BAP.

A remote node password change is more problematical. The billing data from the run detecting thechange will be preserved locally but will not have been copied. The autobilling run may, or may notcontinue, depending on the setting of the ’Copy error continue’ flag, chosen at startup.

See section 16.8 for outline procedure to change password settings for billing. Section 16.5.2.1covers the setting of the ’Copy error continue’ flag. Section 16.9 gives instructions for errorrecovery instructions


16-7

16.4 Manual Operations

16.4.1 Manual billing

Access to this facility is via the Auto billing main menu in SOCV.

The manual billing facility is provided to allow the user to run billing on some historic log files andshould only be considered for use in exceptional circumstances. Housekeeping has been con-figured to backup and delete files based on the latest autobilling run times. Excessive use ofmanual billing rather than autobilling may result in complications for the operator and incompletehousekeeping. Manual billing does not effect the auto billing carry over files.

The carry over file name needs to be specified. Only the ICR carry over name is required. TheDCR one will be derived from the ICR name. Note that the carry over files used are not affected bythe manual billing run. They are also copied to files of the name:

• Ofdb$cache:manual_YYYYMMDDHHMM.dat• Ofdb$cache:dcr_manual_YYYYMMDDHHMM.dat

At the end of the manual billing run the following files will contain the carry over information result-ing from the completed billing run:

• Ofdb$cache:manual.dat• Ofdb$cache:dcr_manual.dat

Note also that these carry over files are also covered by the housekeeping functions for backupand delete of carry over files.

The output file may be found in OFDB$LISTDIR. The name is operator definable but defaults to’New_Billing.DAT’

See section 16.6 for details on user journal file entries and carry over files.

See section 16.9 for details on the use of manual billing for error recovery from auto billing.


17th July 2001

16-8

16.5 SOCV ACCESS AND BILLING SET UP

16.5.1 Autobilling Main menu

Access to this menu is via the offline SOCV option 6 ’Automatic billing’ in the Billing DataGeneration menu. Access to this point has not been changed.

See figures 4-7 SOC Viewer Off-Line Processing Menu Tree 1/3 and 4-10 SOC Viewer AutobillingMenu Tree for the SOC viewer access.

The following billing functions are available at this level. (Those items in capitals generate furthermenus).

1. Show if billing is currently running.

2. Lock out billing

3. Unlock billing.

4. CONFIGURE AUTO BILLING

5. Access to the HOUSEKEEPING functions

6. Stop Auto billing

S. START AUTO BILLING

R. RUN MANUAL BILLING

The function to lock and unlock billing will allow the operator to lock out billing while other activitiesare being carried out i.e the backup of log files.

The menu will show the billing state as ’AUTOACTIVE’ if billing is running on same node, or’PARTNERACTIVE’ if running on partner node (here, running refers to the actual generation ofbilling data at a time requested by the operator). ’LOCKED’ if billing has been locked out by theoperator and ’INACTIVE’ if billing is not running. NOTE: Should the display show that billing is’active’ at a time when it is known that no billing session is due, or even when all billing (on currentnode) has been stopped, then use of ’Lock’ and ’Unlock’ will correct this setting.

The menu also shows the curent state of the submitted billing jobs and will confirm whether billinghas been initiated, is executing or is holding and the time it will run.

16.5.2 Configuration

16.5.2.1 Autobilling Configuration

In order to run autobilling, the following setup parameters must be defined

1. Modify Partner node nameIn order to ensure that autobilling continues after a BAP switch, the billing processmonitors its partner node for the continuing existence of the corresponding processthere. In the event that this is not found, then an alarm will be raised. The softwarewill calculate the partner node name directly, this being the name of the other BAP ina redundant pair. The user may over write this value if required.


16-9

2. Modify Billing modeThe billing mode may be STANDBY or EITHER. Ordinarily, this value should be setto STANDBY. The billing mode defines the status that a BAP must have in order toallow billing to run on that BAP. This refers to the Master/Standby mode. Setting themode to STANDBY will mean that billing will always switch to run on the standbypartner so that billing is never performed on a master BAP. If set to either then billingwill be performed irrespective of the BAP status. Note ’EITHER’ must only bespecified if and when one and only one autobilling process is running, for examplewhen the standby BAP is down for upgrade otherwise billing may be performedtwice whenever the ’either’ BAP is master.

3. Modify Billing intervalThe billing interval time for each billing run. It will accept any valid delta time. Theformat for this is:DDDD-HH:MM:SS.CCThe ’DDDD-’ and ’.CC’ are optionalExamples of likely intervals ;

Required Interval Specification for Billing Interval1 day 1-00:00:00.001 week 7-00:00:00.002 weeks 14-00:00:00.00

Note: If an interval of less than one day is specified then due to the naming conven-tion adopted by Auto Billing the two ( or more ) file names will be identical.Differentiate between them using the VMS DIRECTORY /DATE command

4. Modify Target nodeThe target node is the DECNET node name that the user may wish to have thebilling files copied to. If it is set to DONT_COPY then no copying of the billing fileswill take place.

5. Modify Target directoryTarget directory is the full path on the target node where the file is to be copied to.

6. Modify Delete after copyIf this flag is set true then the billing file will be deleted after it is copied to the targetnode.Note: If ’Modify Target node’ has been set to ’DONT_COPY’, then this flag shouldbe set to ’FALSE’.

7. Modify Billing error continueBilling error continue. If this is set true then the billing will continue even if an erroroccurs. This will normally mean that the autobilling sequence will continue after thepredefined interval, leaving the operator to manually correct the current fault. Thisoption should be used with caution.

8. Modify Copy error continueCopy Error Continue. If this is set true then the billing process will continue even if acopy of the billing file failed.

9. Modify Copy User nameThis is the name of an account with write privilege for the target directory.


17th July 2001

16-10

16.5.2.2 CSV File Operation Configuration

1. Auto CSV Generation requiredBy default this is FALSE. If set to TRUE then each time an Auto Billing Run ex-ecutes it will create a CSV file from the billing file output. If left as FALSE then themanual CSV file option can be used to provide these files when required.

2. Target Node name for CopyThis option is only applicable to CSV files created during Auto Billing Runs. Thetarget node is the DECNet node name that the user may wish to have the CSVoutput file copied to. If it is set to DONT_COPY then no copying of the CSV file willtake place.

3. Target Directory for CopyThis option is only applicable to CSV files created during Auto Billing Runs. This isthe Directory path on the remote node to which the CSV file is to be copied.

4. Target Username.This option is only applicable to CSV files created during Auto Billing Runs. This isthe User name of the account to which the CSV file is to be copied.

5. Alter Target PasswordThis option is only applicable to CSV files created during Auto Billing Runs. Unlikethe other options this one is not displayed directly on the menu for security reasons.This is the password of the account to which the CSV file is to be copied. Tochange it select this option. When altered it is written in an encrypted format to theconfiguration file. It appears nowhere in a Human readable form.

6. Delete File after CopyThis option is only applicable to CSV files created during Auto Billing Runs. If this isset to TRUE then once the CSV File has been transferred successfully to the remotenode the local copy will be deleted. If the operator has so configured the CSVprocess to not copy the local CSV file then this delete operation will not be per-formed.

G. Generate CSV FileAn option to manually generate the CSV File. Selecting this option the useris prompted for the Full Directory Path and then file name of the Billing FileOutput from which the CSV file is to be generated. The CSV file will becreated in the OFDB$LISTDIR directory with a file name as that of the billingfile but with a .CSV extension

16.5.3 Start Auto billing

Start auto billing allows the user to enter the start time of Autobilling and the required passwordand then starts it as a batch job. On selecting the start auto billing function the user will bepresented with the following SOCV form menu list.

1. Modify Batch queueDefines which batch queue to run the autobilling job on. This is defaulted toSYS$BATCH

2. Modify Start timeStart Time is the time the user wishes the first billing run should run from. Seesection 16.5.3.1 regarding start times.


16-11

3. Modify Copy passwordThe copy password is the password for the account to which the billing file is to becopied on the target node. The account has the ’User name’ defined in the autobill-ing configuration section above. Once typed in , this will not be displayed again.The password is encrypted before being used as a batch job parameter, this is thendecoded before being used.

4. Modify Partner passwordThe partner password is the password of BAPSYS on the MASTER node.The password is encrypted before being used as a batch job parameter, this is thendecoded before being used

5. Submit billing

Note, should the passwords be changed (at the remote nodes) then autobilling will need to berestarted using the new passwords.

16.5.3.1 Start times

Before contemplating changes to start times one ANY live system, the following note should beunderstood.

When Advanced Billing was installed for the first time on an LES, the OFLN database con-verter should have been run, thus creating the initial carry over files. If carry over is to beused, these files MUST be kept up to date. In other words from the creation of the initialcarry over files, Advanced Billing MUST always be run over CONTIGUOUS periods, with theinitial start time being set to the end of the period covered by LAST ’old billing run’. Thesecontiguous Advanced Billing runs can be performed either by Auto or Manual Billing (bothof which utilise Faster Billing), though Auto Billing is recommended.

In the event that billing has not been run before ON THIS BAP PAIR, or, to be more accurateOFDB$CACHE:JOURNAL.LIS does not exist (the operator could/may have deleted it), then adefault start time is presented. This is calculated as being the start of the day of ’current time’ -’interval’ - 5 minutes, where the interval is as has been defined under the configuration option. The’5 minutes’ provides a margin to allow for the final entries during the ’interval’ to be written to file.This therefore represents the latest full interval, starting on a day boundary, that can be billedimmediately. The ’day boundary’ has been provided in order to assist the operator in the followingways:

• To reduce operator typing by calculating the most recent start time from which a fullinterval, starting on a day boundary, can be billed.

• To present an example of the format for the time representing the start of the day.

However, for reasons explained above, it is strongly suggested that the start time for the first bill-ing run on a ’live’ system be that of the end of the last ’old’ billing run. If this start time does notcoincide with the required time for the auto billing runs, the operator may wish to adjust the ’inter-val’ until the start time coincides with a desired time. In this way contiguous billing runs will bemaintained.

If a valid journal file is found (i.e. billing has been run before), then the last line in this file willindicate the end time of the last billing run on this BAP pair (the journal file is common to bothBAPs). It is assumed that, in normal circumstances, a contiguous set of billing runs will be re-quired, hence the last end time will be extracted from the journal and offered as the next start time.The operator may change this if required, but for any such change the operator will be warned ofthe consequences and be asked to confirm the change. This will then be written, immediately, to


17th July 2001

16-12

the journal file.

The operator may of course provide any other start time he wishes. The acceptance of the offeredstart times is in no way compulsory, they are provided in the first case as a ’helpful’ suggestion,and in the second as a reminder as to the end time of the previous billing run. If changes aremade to the ’journaled’ start time, then a reminder that this MAY result in skipped or duplicatedbilling will be displayed. This is primarily there as a safeguard against the operator entering er-roneous start times (i.e. thinking that of the previous end time was, for example, 00:00, he mightenter 00:01 as the next start time, this would be WRONG). In the event that the operator doesindeed wish to shift the start times, then the warning may be safely ignored on the assumption thatthe consequences are understood.

If the specified time is less than ’interval’ + 5 minutes in the past, then this will be accepted, butbilling will not run until 5 minutes after the completion of the first ’interval’ period following theentered start time.

If the specified time is more than ’interval’ + 5 minutes in the past, then billing will commenceimmediately, and create a full set of output files for every full ’interval’ period following the giventime.

The SOCV menu will change to reflect the source of the displayed start time. The text options are:

• Modify DEFAULTED start time :• Modify JOURNAL start time :• Modify ENTERED start time :

These indicate whether the time has been calculated where no journal exists, or extracted fromthe current journal entry, or has subsequently been modified by the operator

NOTE:Changes may be made to the start time even if billing has not been stopped. The operatorwill have been warned of the existence of a billing batch job before reaching this point. There aretwo possible outcomes which should be borne in mind when changing these times if billing has notbeen stopped.

1. Billing is active (on either node)In this case, there is a possibility that the billing process has yet to make its entriesin the journal file. If this happens, then changes made by the operator will not befound at the next billing run. It is recommended that the start time should not bealtered in a period when Billing may be active.

2. Billing is holding (on either node)At the next scheduled billing time (i.e. 5 minutes after the original start time plusinterval), auto billing will run, based on the new start time. It will create a full set ofoutput files for every full ’interval’ period following the new start time. If there are nofull periods (i.e. new start time, plus interval plus 5 minutes is not in the past) thenthe next billing run will be rescheduled for 5 minutes after the first full interval.


16-13

16.5.4 Performing the Manual Operations

16.5.4.1 Manual Billing

The run manual billing is provided to allow the user to run a billing on historic log files. This willcreate a special entry in the user journal (see 16.6.1.3 below) but will not affect the normal car-ryover file. The following commands and options are provided to enable the operator to (re)createa billing file at will.

1. Modify Start TimeThe start time is defaulted to the start of the previous day (or to be more precise -the start of the day previous to 5 minutes ago, since the 5 minute buffer is required).The operator may enter any other valid time that he wishes.

2. Modify End timeThe end time is defaulted to one day after the start time. The operator may enter anyother valid time that he wishes.

3. Modify Run NumberRun Number, as stored in the billing tape header, is set to 00001 by default

4. Modify File IDFile ID set to CBTAPE by default and stored in the billing tape header.

5. Modify Billing File NameThe FULL file name is the name - full path - of the disk file to contain this billing run.If omitted it will be defaulted to:OFDB$LISTDIR:NEW_BILLING.DAT

6. Modify log file directoryThe source directory defaults to BAP$LOG and points to the location of the logfilesto be used.

7. Modify carry over fileThe carry over file name needs to be specified. This should not be the same as thecurrent system carry over file. Only the ICR carry over name is required. The DCRone will be derived from the ICR name.

8. Run billing


17th July 2001

16-14

16.5.5 Housekeeping

The housekeeping menu aims to bring all the housekeeping functions associated with Advancedbilling together under one menu. Housekeeping should NOT be performed when a billing sessionis ACTIVE or is imminent. These procedures replace the existing OFDB housekeepingprocedures. The menu takes the form:

A full description of each each option available from this menu is given after the summary shownbelow.

1. Backup/Copy billing files2. Backup log and carryover files3. Delete backed up log and/or carryover files4. Restore backed up log and carryover files5. View the Journal file6. Truncate journal/Delete history file

C. Configure Auto Housekeeping

1. Backup/Copy billing files.Two options are available here, either to COPY files to tape, or to BACKUP to a’save set’ on tape. The operator will be asked to specify the destination tape drive,however, if only one drive is found, then this will be selected by default.

If COPY is selected, then a further option will be offered, to APPEND data to anexisting set of files on a tape, or to INITIALISE a new (or recycled) tape, overwritingany files which may be there already.

If SAVE is selected, the the tape will be initialised before creating the save set.

2. Backup log and carryover files.All log files (with indices) created before the end time for the last billing run will bebacked up. If this includes the latest log file, the operator will be asked to retry later.If there are no log files to backup, then the operator will be informed. The tape labelwill be set to the last end time/date (no hyphens) .SAV.Logfiles will be backed up even if the last billing run was a failure.

The backing up of the carryover files will backup all the ICR and DCR carry overfiles. Note that this does not include the ’current’ carryover files which will be usedas input for the next auto billing run. This means that restoring carryover files fromtape will not affect the next billing run. See section 16.6.3 for more details.

The name for the save set will be based on the END time of last billing run.Carry over files will be backed up, even if the last billing run was a failure.

3. Delete backed up log and/or carryover files.The operator can specify number of days ’X’ in the past for deletion. Only those logfiles last modified before midnight ’X’ days in the past will then be deleted (i.e. filesopened before midnight, but not closed until the next day will not be included). If thisincludes the latest log file, then the operator will be asked to retry later. If no log filesfall in the above categories, then the operator will be informed. Only previouslybacked up files will be deleted.If any OFDB processing of these logfiles is required (report generation etc) then theymust have been copied to the offline area BEFORE this step is performed. See16.5.5.2 below.


16-15

As for log files, the operator can select to delete carry over files created before mid-night for a specified number of days in the past.

4. Restore backed up log and carryover files.Restoration of either or both sets of files may be selected here. Carryover files willbe restored to OFDB$CACHE, but the operator can specify the destination requiredfor the log files (defaulted to BAP$LOG).

The operator must check that sufficient disk space is available before restoring logfiles.

This routine will handle tapes created under earlier releases where log and car-ryover files were backed up to different tapes, and will restore the files as ap-propriate to the tape inserted.

5. View the Journal fileThe option to view the user journal file (ofdb$cache:user_journal.lis) will giveoperators access to the user journal file from SOCV

6. Truncate journal/Delete history fileAs the journal files can grow large the system allows the journal files to be deleted.This operation will create a new empty user journal file (ofdb$cache:user_journal.lis)and delete the old one. The new system journal file (ofdb$cache:journal.lis) will con-tain the last entry from the old journal file.Truncating the current journal will append the contents of the old journal files(Journal.Lis and User_Journal.Lis) to a separate history file ’Journal_History.Lis’.

Before truncating, the operator will be offered the option to delete all existing historyfiles.

C. Configure Auto HousekeepingThis option sets up the auto housekeeping details and is described in section,16.5.6, below.

Auto housekeeping performs these housekeeping functions which need to becarried out regularly, normally after each billing run and will permit almost fullyautomated billing.

Depending on whether or not any offline processing is to be performed on the LES log files, one oftwo housekeeping philosophies should be followed. These are described in sections 16.5.5.1 and16.5.5.2 below.


17th July 2001

16-16

16.5.5.1 Housekeeping with no OFDB processing

If, as is likely to be the usual case, no offline processing (log file reports etc) is to be performed onthe current batch of log files then the simple housekeeping procedures shown in figure 16-1 belowshould be followed.

There are four steps to this, after creating the billing data from selected log files (performedautomatically), all are accessed via the autobilling SOCV menus

1. Backup carry over files.2. Delete carry over files.3. Backup billed log files.4. Delete log files that have been backed up.

All these actions can be performed automatically, see section 16.5.6.

16.5.5.2 Housekeeping with OFDB processing

In the event that any offline processing is to be performed, then the following housekeepingprocedures should be performed for the relevant files after creating the billing data from selectedlog files (performed automatically or manually).

1. Backup carry over files2. Delete carry over files3. Backup (but do NOT delete) billed log files.4. Use SOCV housekeeping menu to copy required logfiles to the offline area. AFTER

they have been processed by autobilling.This, and the following steps, uses the housekeeping system accessed from SOCV,level 2, as shown in figure 4-7 SOC Viewer Off-Line Processing Menu Tree 1/3

5. Load these files from the offline area into OFDB.6. Carry out required OFDB processing.7. Delete copied (billed) files from online area.8. Delete copied (billed) files from offline area.


16-17

[Autobil]

REPORTS

DELETED FILES

ARCHIVED CARRYOVER

FILES

1

Micro VAX

MASTER BAP

(ONLINE) LOG

FILES

2 3

4

BILLING FILES

DELETED CARRY- OVER FILES

ARCHIVED LOGFILES

5 AUTO

BILLING

CARRY- OVER FILES

Figure 16-1. Housekeeping where OFDB processing is not required

[autobil.eps]


17th July 2001

16-18

[AbilONDB]

REPORTS

OFFLINE DATABASE

DELETED FILES

OFFLINE LOG

FILES

(ARCHIVE DATABASE)

1

2

3

4

5

6

7

8 BILLING ESSENTIALS

(ONLINE) LOG

FILES

Micro VAX

MASTER BAP

BILLING FILES

ARCHIVED CARRYOVER

FILES DELETED CARRY- OVER FILES

ARCHIVED LOGFILES

9

AUTO BILLING

CARRY- OVER FILES

3

Figure 16-2. Housekeeping where OFDB processing is required

[AbilOFDB.eps]


16-19

16.5.6 Auto Housekeeping

Those housekeeping functions regularly carried out after each billing run may be automated usingthis option. These being:

1. Copy, to tape, the billing output file produced by the current billing run just com-pleted.

2. Backup, to tape, the log and carryover files involved in the last billing run, plus anyothers not already backed up.

3. Delete backed up log files older than a specified number of days.

4. Delete backed up carryover files older than a specified number of days.

To make full use of this facility, two tape drives will need to be available at the time of each billingrun as each tape is initialised prior to processing. In the case that only one drive is available, thenonly one of the tape options should be specified and the other operation performed manually. Itremains the responsibility of the operator to change the destination tapes after each billing run.

Any changes made and saved using the auto housekeeping configuration menu, will be acted onin the next billing run. There is no requirement to stop billing to pick up any changes made here.

The information entered here is stored in BM$EXE:BM_AHK_CONFIG.DAT

The status of each stage of housekeeping will be logged in the existing User_Journal.Lis.Examples of successful and incomplete housekeeping entries are shown in section 16.6.1.2below.

An alarm will be raised in case of failures during autohousekeeping.

Configuration details required are:

1 Select Billing Tape Drive :2 Select Backup Tape Drive :3 Delete Logfiles older than :4 Delete C/O files older than :5 Reset auto housekeeping

For 1 and 2, the operator may enter any available tape drive name. To deselect a tape drive,entering ’Q’uit when asked for the name will result in ’DONT_COPY’ being displayed against theoption, and no copy will take place.

The specification of a tape drive is all that is required to enable the appropriate copy/backup ac-tion.

If the same drive name is entered in both cases, then when the first operation (billing o/p) hascompleted, the tape will be ejected and the log and carryover file backup will fail.

Similarly, if no deletions are required, then ’return’ will enter the default ’DONT_DELETE’

If all options are set to ’DONT_...’, then

• No backups will be performed

• No deletions will be performed


17th July 2001

16-20

• Option ’5’ above will be replaced by :’NoAuto housekeeping has been requested’

Once a valid action is specified, then option 5 becomes available again. Selecting this option (5),will set both drives to ’DON’T_COPY’ and both durations to ’DON’T_DELETE’, thus offering asimple way to suspend auto housekeeping.

16.5.6.1 Tape drive precautions during auto housekeeping

Note: The tape drive(s) are freely available for other uses (manual backups and copying) at alltimes EXCEPT for the duration of auto housekeeping immediately following each billing run. Theoperator MUST be aware of these times and ensure that:

• ALL manual tape operations are complete

• Blank tapes (or those to be ’recycled’) are inserted in each auto housekeeping driveand are write enabled.

The duration of the auto housekeeping process will depend on the volume of calls/size of log filesbeing processed. Throughout this period, billing will remain ’locked’ as indicated by the ’ACTIVE’display in the auto billing main menu. Once billing has gone ’INACTIVE’ then the tape drives be-come available for general use again until the next billing run.

16.5.6.2 Billing start time restrictions

To enable successful autohousekeeping, it is strongly recommended that the billing start timeshould be set on an hourly boundary (i.e. XX:00). This will mean that the last log file involved inthe latest billing run will be closed when autohousekeeping is performed. Successful backup willthen be possible.

16.5.6.3 Restarting billing

If for some reason, auto billing is being restarted with a start time and interval such that multiplebilling runs will be performed, it is recommended that auto housekeeping be disabled (reset) be-fore starting billing. Once the billing runs are back up to date, (i.e. the next scheduled billing run isin the future), then manual housekeeping should be used to cover the ’catch up’ period. When thishas been completed, then auto housekeeping may be enabled for future auto billing runs.


16-21

16.6 FILES UTILISED BY ADVANCED BILLING

16.6.1 User Journal file

16.6.1.1 Auto Billing User Journal updates

The user journal gives a breakdown of the billing runs carried out on the system. The informationincluded in the user journal is the start and end time of the billing run. The statistics collectedduring the billing run. The success or failure of the billing run and copying of the output file.

The user journal contains an entry for each billing run. An example of which is shown below. Anexample entry of a user journal file (ofdb$cache:user_journal.lis):An example entry of a User_Journal file:***************************** END OF BILLING RUN ****************************

Billing run started for range : 27-JAN-2000:00:00 to 28-JAN-2000:00:00The disk billing file is : OFDB$LISTDIR:BILLING_200001270000.DATDisk space ample currently : 124983The ICR carry over file Copied to : OFDB$CACHE:Carry_Over_200001270000.DATThe DCR carry over file copied to : OFDB$CACHE:DCR_Carry_Over_200001270000.DATBilling started at : 28-JAN-2000 00:05:14.96The billing run was a : SUCCESS

Billing completed at : 28-JAN-2000 00:11:05.15Call counts from the billing runCurrent ICRs in cache 0 Peak ICRs in cache 1 Number of cache over flows 0ICRs read from the Cache 1 Unreconciled DCRs 0 ICR retrieves 0ICR only billing 0 DCRs billed 1 Data reports billed 0ICRs cancelled 0 ICRs not loaded 0

Failed DCR reconciliations were :end of DCR reconciliation failuresUser does not want billing to be copied to another node***************************** END OF BILLING RUN ****************************

The following list explains each of the above lines/blocks of data by reference to its line ’number’.

1. The time range for this particular billing run.2. Name and full path of the billing on disk file created by this run3. Disk space available on the target disk. Billing keeps a record of the largest billing

file generated on the system. If the current available disk space is less than thisfigure an alarm will be raised.

4. ICR carry over file.If a user needed to repeat this billing run he would have to use this and the DCRcarry over files. See section 16.9 for instructions on this recovery.

5. DCR carry over6. The time the billing run started execution on the VAX.7. Exit status of the billing run. This will indicate either SUCCESS or or a message and

error code if it failed or cache overflowed (see point 9 below if cache overflows arereported).

8. Time of completion.9. The next block of data contains the statistics recorded by the billing software during

the billing run. They have the following meanings:

• Current ICRs in cache.Number of ICRs in the ICR cache at the end of the billing run.

• Peak ICRs in cache.Largest number of ICRs in cache during this billing run.

• Number of cache overflows.The number of times an attempt to place a CR in cache failed due to thecache being full. If this value is greater than 0 then the size of the cacheMUST be increased AND the billing run redone.

• ICRs read from the Cache.The number of ICRs that have been matched with a DCR for billing.

• Unreconciled DCRs.The number of DCRs in the DCR cache. These are DCRs that could not findtheir ICR in the CACHE. The DCR cache is periodically checked to attempt to


17th July 2001

16-22

match ICRs and DCRs. This value shows the number of DCRs that will becarried over to the next billing run.

• ICR retrieves.It is possible, via a control flag, to get the billing software to search the logfiles for a missing ICR. This value records the number of times this is done.Due to the overhead this functionality is switched off by default.

• ICR only billing.Number of ICRs billed by themselves either due to call nature of call comple-tion code.

• DCRS billed.The number of attempted DCR billing operations = Success (ICRs read fromthe Cache) + Pended ( Unreconciled DCRs )

• Data reports billed.Number of data reports billed.

• ICRs cancelled.Number of ICRs removed from the cache due to the call being cancelled bythe operator.

• ICRs not loaded.Number of ICRs in the carry over file that were not loaded.

10. The next block contains a list (if any) of DCRs that are not being carried over. Theinformation (ICR number, DCR number, driver and CCC) will allow the operator totrack down the problem.

11. The final entry in the journal is the status of the billing file copy, or a message in-dicating that the user did not want the billing file to be copied.

Note that if the Operator forces a change to the start time when an auto billing run has alreadyperformed, the details will be written to the User Journal. This entry will appear as below.************** Billing has been (re)started by the operator ***************End time of last billing run was : 13-JAN-2000:00:32Start_Time requested by operator is : 12-JAN-2000:00:32:00.00************** End of operator update information *************************

16.6.1.2 Auto housekeeping journal entries

Entries will be made in the User_Journal immediately following the entries for the billing run whichtriggered the housekeeping.

Any failures will result in an alarm so that the operator is prompted to check the User_Journal andrectify the problem.

These examples are not exhaustive, but represent the most likely entries to be seen.

• ***************************** HOUSEKEEPING ***************************OFDB$LISTDIR:BILLING_200001270000.DAT copied to MKA500:************************* End of Housekeeping ************************

Here only one tape drive had been specified, for billing data to be copied to. The’backup’ drive was set to ’DONT_COPY’ and both delete options set to’DONT_DELETE’

• ***************************** HOUSEKEEPING ***************************Unable to open destination tape MKA500: - BILL1************************* End of Housekeeping ************************

As above, with but no tape in the defined drive.


16-23

• ***************************** HOUSEKEEPING ***************************OFDB$LISTDIR:BILLING_200001270000.DAT copied to MKA500:Status of Log and Carryover file backup is:

SUCCESSDeleting (already backed up) log files last modified before 27-APR-1999************************* End of Housekeeping ************************

Same tape options as for the previous examples (but with tape inserted), togetherwith valid entries for both delete options.

• **************************** HOUSEKEEPING ****************************OFDB$LISTDIR:BILLING_200001270000.DAT copied to MKA500:Status of LOG and Carryover file backup is :

SUCCESSDeleting (already backed up) log files last modified before 23-APR-1999Looking for backed up Carryover files created before 23-APR-1999Carryover file(s) found and deleted************************* End of Housekeeping ************************

As above, but now with a drive specified for backup. This is the normal successfulcompletion entry if all options are taken.

• **************************** HOUSEKEEPING ****************************OFDB$LISTDIR:BILLING_200001270000.DAT copied to MKA500:Status of LOG and Carryover file backup is:FAILURE - Billing run not on hourly boundary

There are no (backed up) log files to delete.NO Carryover files found for deletion************************* End of Housekeeping ************************

As above, billing was successful, hence the logged copy of the ’.DAT’ file, but allother steps have resulted in no action.In this case, the last billed log file was still open at time of housekeeping consequentlyno log files have been backed up

In addition, in the case of certain failures, additional information will be logged indicating the pointat which the error occurred.

16.6.1.3 Manual billing user journal updates

Every time a manual billing run is carried out a reduced set of information is added to the journalfile:***************************** END OF BILLING RUN ****************************

MANUAL billing run started for range 15-JAN-2000 10:00 to 15-JAN-2000:10:30The disk billing file is OFDB$LISTDIR:NEW_Billing.DATThe billing run was a successCall counts from the billing runCurrent ICRs in cache 0 Peak ICRs in cache 1 Number of cache over flows 0ICRs read from the Cache 1 Unreconciled DCRs 0 ICR retrieves 0ICR only billing 0 DCRs billed 1 Data reports billed 0ICRs cancelled 0 ICRs not loaded 0************************** END OF MANUAL BILLING RUN *************************

The entries here are similar to those for the auto billing user journal entries.


17th July 2001

16-24

16.6.2 System Journal file

The (System) Journal file, ofdb$cache:journal.lis, is only written to by auto billing. It provides abreakdown of the auto billing runs carried out on the system. At the end of each auto billing runthe following details are written to this file (a single line entry for each run): the start and end timeof the billing run, the success/failure status of the billing run and the copy to the remote node.

The only other way that this file will be altered, is if the operator wishes to make a change to thestart time. In this case the requested update will be reflected in the journal file with a dummy entrygiving the new start time to be picked up on the next auto billing run.

16.6.3 Carryover files

For most types of calls through the LES there are two parts, incoming and delivery. Since the LESis a store and forward system these two parts may occur with some time between the them. Theinformation relating to the incoming part of a call is recorded in the LES Log files as an IncomingCall Record (ICR). The information relating to the delivery part of a call is recorded in the LES Logfiles as a Delivery Call Record (ICR).

The job of (faster) billing is to reconcile (i.e. match together) the ICRs with the relevant DCRs.

At the end of a particular billing run there will be calls which the ICR has been recorded, but thematching DCR(s) have not yet all been found. For this reason the ICR must be carried over. Sothe ICR carry over file contains any such ICRs. The next billing run will read in the carried overICRs so they can be reconciled. Without this it would not be possible to bill the correspondingDCRs.

Note that under obscure conditions it is possible for a DCR to be logged before the correspondingICR and for this reason a DCR carry over file is also required.

When Advanced billing is installed, the offline database converter will generate the first carry overfiles. If carry over is required, it is important that the first auto billing run is contiguous with the timeof the last billing run.

All carry over files are placed in ofdb$cache.

16.6.3.1 Auto Billing Carry Over files

At the start of each auto billing run, the current carry over files are copied to files with the currentstart time included in the file name as follows:

From ToCarry_Over.Dat Carry_Over_YYYYMMDDHHMM.Dat

e.g. Carry_Over_200001270000.DATDCR_Carry_Over.Dat DCR_ Carry_Over_YYYYMMDDHHMM.Dat

These files are used to keep a record of the carry over files used for auto billing runs and will bebacked up and deleted by the housekeeping functions.

The current carry over files (Carry_Over.Dat and DCR_Carry_Over.Dat) are then read in by fasterbilling and then deleted.

At the end of the billing run, after the billing output file has been created, then new carry over filesare created (Carry_Over.Dat and DCR_Carry_Over.Dat).


16-25

16.6.3.2 Manual Billing Carry Over files

When setting up the parameters for a manual billing run the carry over file name must be specified(the DCR name is derived from the ICR file name.

The specified carry over files are copied to:

Manual.DatDCR_Manual.Dat

(these are the files used by manual billing).

The specified carry over files are also copied to:

Manual_<YYYYMMDDHHMM>.DatDCR_Manual_<YYYYMMDDHHMM>.Dat

These files are used to keep a record of the carry over files used for manual billing runs and willbe backed up and deleted by the housekeeping functions.

The current carry over files (Manual.Dat and DCR_Manual.Dat) are then read in by faster billingand then deleted.

At the end of the billing run, after the billing output file has been created, then new carry over filesare created (Manual.Dat and DCR_Manual.Dat).

Note that if a manual billing run is performed because an auto billing run has failed, the resultantcarry over files will need to be copied so that they will be picked up be auto billing (see section16.9 below).


17th July 2001

16-26

16.7 ALARMS AND EVENTS

The following five alarms of Group ’BAPS_GROUP’ and Class ’BAP’ are now added to the onlineDB. The suggested corrective actions are given in each case.

• Auto billing not running on partner node.Check User Journal & restart billing.

• An auto billing run has failed.Check User Journal. Rectify problem & restart billing if option set to stop billing on afailure condition

• Copy of billing file to target node has failed.Check User Journal. Check DECnet. Manually copy file when problem rectified. If theoption is set to stop billing on a copy error, then auto billing will need to be restarted.

• Auto billing currently locked out.Check for reason.

• Disk space short on OFDB$LISTDIR.Free up disk space

• Problem with partner node check passwordCheck password.

• Auto housekeeping run error.A warning has been logged during the auto housekeeping run. CheckOFDB$CACHE:User_Journal.Lis, BAP$ERROR:Auto_Billing*.LOG and output tape.Correct the error and run manual backup/deletion.


16-27

16.8 OPERATOR PROCEDURES

All the instructions below start from the autobilling main menu, (see section 16.5.1 above).

It is suggested that the standby sessions always be started first, as it is on the standby nodewhere billing will run and it is this session which will maintain the journal files. It is though thejournal file that both BAPs remain in sync. The operations detailed below do not need to be per-formed simultaneously on each BAP. The only proviso being that, assuming that the changes arerequired to be put into effect, each BAP should be (re)started before the next scheduled billingsession.

16.8.1 Starting billing for first time

1. Select ’Configure autobilling’ - option 4 (Now see section 16.5.2.1)

2. Ensure that all parameters are set to desired values.

3. Exit to autobilling main menu

4. Go to Start Auto billing menu - option S. (See section 16.5.3)


6. Submit billing - option S

NOTE: This must be performed on both BAPs and the same values should be used for both. Anydifferences entered on one node after the other node had been set up, are likely to result in con-fusion.

16.8.2 Changing configuration parameters

Note: changes here need to be made on BOTH BAPs. Assuming that it is not close to the time ofa scheduled billing run it is safe to make any such changes without stopping or locking billing. Thechanges will be picked up at the next scheduled run. However if the billing interval has beenchanged, billing should be stopped and restarted in order to schedule the next run at the correcttime.

1. Select ’Configure autobilling’ - option 4 (Now see section 16.5.2.1)


3. Exit to autobilling main menu

16.8.3 Changing ’copy’ or ’partner’ node passwords

16.8.3.1 Auto Billing

Billing MUST be stopped and re-started in order to apply these changes. This must be performedon BOTH BAPs.

1. Stop billing on BOTH BAPs - option 6

2. Ensure that billing is not locked - (Use option 3 to unlock if required).

3. Go to Start Auto billing menu - option S. (Now see section 16.5.3)


17th July 2001

16-28

4. Change the password - option 3 (or 4)

5. RE-ENTER the other, unchanged password - option 4 (or 3)

6. Submit billing (accepting offered start time to ensure contiguous billing) - option S

For continued successful billing, these changes should be made between billing runs at the sametime as the change is made on the target node.

16.8.4 Changing Start Time

See section 16.5.3.1 for details on the start time and making changes to it. Do not perform thisprocedure if billing is currently being performed.

This must be done on BOTH BAPs.

1. Stop billing on both BAPs - option 6

2. Ensure that billing is not locked - (Use option 3 to unlock if required).

3. Go to Start Auto billing menu - option S. (Now see section 16.5.3)

4. Modify the start time - option 2

5. RE-ENTER the passwords - options 3 and 4

6. Submit billing - option S

16.8.5 System backups

In order to minimise the possibility of disruption in the event of any delay in completing the back-ups, it might be better to start backups immediately after the end of a billing run (check the batchqueue for billing jobs, ’executing’ or holding’)

1. Lock billing (both BAPs) - Option 2

2. Perform backups

3. Unlock billing (both BAPs) - Option 3


16-29

16.9 ERROR RECOVERY

16.9.1 General

For details of the User_Journal referred to below, see section 16.6.1

Discover/correct problem (disk space, link to remote node, missing file, password change etc).The alarms and user_journal filewill provide adequate information as to the nature of the problem

Note that if there are no alarms and no entries in the user journal associated with the problem, thebatch log file should be checked to see if billing has failed with an unexpected reason. See file:

BAP$ERROR:AUTO_BILLING_<Node_Name>.LOG

If billing will not start, or remains ’active’ for more than the usual length of time without producingany output, use the autobilling main menu to lock and then unlock billing.

For an alarm raised as a result of a partner node password change, then, if the change is tem-porary (for example to allow HNS access), then no further action need be taken. If the change ispermanent, then the autobilling process which raised the alarm must be restarted using the newpassword in the set-up.

If the error was in copying the billing file to the required destination, then manually copy the billingfile to the required destination once the problem has been corrected (or deliver the file by an alter-nate method if urgent). If the copy error continue flag has been set to ’CONTINUE’, then the billingprocess will continue as normal at the next scheduled time. If not, then autobilling will need to berestarted.

The billing output file can be found in OFDB$LISTDIR:

If the failure to copy the billing output file was as a result of a password change at a remote node,then autobilling will need to be restarted on both LES BAPs using the new password.

See section 16.8 for outline procedure to change password settings for billing.

16.9.2 Billing has (been) halted

In the event of any other error which results in no billing files being produced, then, if autobillinghas been configured to halt on an error (or has subsequently been halted by the operator) then theuser should carry out the following steps:

• Discover/fix the root of the problem.

• Extract the following information from the last entry in the user_journal.

• Start time for the billing run• The file name that the ICR carry over data was copied to.

It will be in the formOFDB$CACHE:Carry_Over_<Date/Time>.DAT.Where the time stamp in the file name matches the start time of the billing run.

• The file name that the DCR carry over data was copied to.It will be in the formOFDB$CACHE:DCR_Carry_Over_<Date/Time>.DAT.Where the time stamp in the file name matches the start time of the billing run.


17th July 2001

16-30

• From the VMS prompt, copy the saved ICR carry over file to:OFDB$CACHE:Carry_Over.DAT

• From the VMS prompt, copy the saved DCR carry over file to:OFDB$CACHE:DCR_Carry_Over.DAT

• Goto the SOC viewer start autobilling option. For the start time enter the start timetaken for the journal. Then start auto billing.

16.9.3 Autobilling continues, use of manual billing

If autobilling has been configured to carry on after a failure then the following actions are require.

• Lock billing from the autobilling main menu.• Extract the following information from the last failed entry in the user_journal.

• Start time for the billing run

• End time for the billing run

• The file name that the ICR carry over data was copied to. It will be in the form:OFDB$CACHE:Carry_Over_<Date/Time>.DAT.Where the time stamp in the file name matches the start time of the billing run.

• Run manual billing from the autobilling main menu setting the following values

• Modify start time to be the start time taken from the journal file.• Modify end time to be the end time taken from the journal file• Modify the carry over file to be the ICR carry over file name taken from the

journal file with directory logical removed.

• Then run manual billing. Taking a note of the output file name.• Manually copy the billing output file to the required destination.• Assuming that the carry over files that result from this manual billing run are now re-

quired for auto billing, perform the following from a BAPSYS session.

• Copy ofdb$cache:Manual.dat ofdb$cache:Carry_Over.dat /log• Copy ofdb$cache:DCR_Manual.dat ofdb$cache:DCR_Carry_Over.dat /log

This will copy the two manual carry over files to be the current auto billing carry overfiles.

• Unlock billing from the autobilling main menu.

[opg16.mss]

A4-OPG-003076 Switch SettingsIssue 3.23 - Accepted17th July 2001

A-1

Appendix A

EQUIPMENT SWITCH SETTINGS

This appendix describes the various equipment switches and their recommended settings.

A.1 DEC Equipment Switches

The normal operational settings of the DEC equipment is as follows.

Component Switch Setting

BAP none

FEP DHQ11 switch E19 bits 1, 6, 9 ONin TIF rack In addition set bit 10 ON on second board(DHV mode) switch E11 bits 1, 4, 5, ON

In addition set bit 8 ON on second board

FEP CPU Rear Console One 3-position switch (on top) and two dial(TIF) control switches (below) control console interfaceMonitor (CK-KA630-A) and automatic reboot option.Connection

1) 3-position switch - set to bottomsetting (circle with dot above).

2) Middle dial - set to top setting (arrow)3) Bottom dial - set to e.g. 19200

OR

FEP CPU DIL switch For normal operation or non-interactive(TIF) adjacent to monitoring, switches 2,4 down (= On),Monitor monitor connection all other switches up (= Off)Connection on KA630CNF For interactive monitoring, see section 10.2.4

FEP nonein CUC rack

DEMSA none

LA210 DIL switch 1 bit 6 up, all others downPrinter DIL switch 2 bits 1, 3, 4, 8 up, all others down

Switch Settings A4-OPG-003076Issue 3.23 - Accepted

17th July 2001

A-2

A.2 Channel Unit Equipment Switches

Ensure that any replacement modules are set as shown below.


Modem Chassis Tray Address Chassis ID as configured on theChannel unit chassis definition screen.See section 7.4.4.

ASM S1-Toggle Center - Auto MTM selection enabledS2-Toggle Press for manual reset; returns to

correct position automatically.

S3-DIL switchbit 1 0 (not Open) - SCP Frame Sync enabledbit 2 0 (not Open) - CU Frame Sync enabledbit 3 0 (not Open) - not usedbit 4 0 (not Open) - Debugger Disabledbit 5 0 (not Open) - Enable SCP Timeout

Audible Alarmbits 6-8 1,0,0 (6 Open, 7, 8 Closed)

SCP Timeout Value. Bit 6 is thelow order bit, and bit 8 is thehigh order bit, giving a range ofvalues of 0-7. All zeros disablesthe timeout. 1-7 ranges from 20to 140 seconds in 20 secondincrements. The default 1,0,0for switches 6,7,8 gives a valueof 1, which corresponds to a 20second SCP Timeout Value.

Jumpers have these functions when in A or B position, i.e. the opposite letteris visible.

W1-Jumper A - Manual reset enabledW2-Jumper A - Relay test disabledW3-Jumper B - Speaker output enabledW4-Jumper A - Watch dog timeout enabled

MTM Toggle Used to set frame number zero atmidnight. Press a few secondsbefore midnight and release exactlyat midnight.

MTM W1-Jumper Include/exclude satellite loop delayin frame timing. For satellitethe link should be in the left handposition and ’B’ visible. Placein right hand position for in-station loopback only.

Link J3-J4 Install for internal oscillator.

MOD S1-DIL switch 1-8 Normally ON.Leave ON for normal operation

A4-OPG-003076 Switch SettingsIssue 3.23 - Accepted17th July 2001

A-3

When OFF, used as follows:1 - not used2 - BER Test Mode3 - Slot Number Hex Display4 - Debugger Enable5 - Transmit Disable6 - Multidrop Timer Disable7 - Multidrop Max Msg Size

(1000 off/512 on)8 - ISL Test Mode

S2-Toggle Press for manual reset; returns tocorrect position automatically.

S3-Toggle Down - enable transmit

The Modulator will not function with any of the DIL switch bits 2, 5 and 8 set to OFF.

DEM S1-DIL Switch 1-8 All should be normally ON.Leave ON for normal operationWhen OFF, used as follows:

1 - Force Collision Detect Flag2 - TDM Data Mode3 - Slot Number Hex Display4 - Debugger Enable5 - Not used6 - Multidrop Timer Disable7 - Multidrop Max Msg Size

(1000 off/512 on)8 - Displays frame number

S2-Toggle Press for manual reset; returns tocorrect position automatically.

S3-DIL switch 1,2,3 open, 4 closed - Sets T0 Valuefor slot timing.

W1-Jumper 1-2 - Enable DSP ClockW2-Jumper 1-2 - Vector Signal Processor Start

State Lookup Page (with W3 & W4)W3-Jumper 1-2 - Vector Signal Processor Start

State Lookup Page (with W2 & W4)W4-Jumper 1-2 - Vector Signal Processor Start

State Lookup Page (with W2 & W3)

A.3 Other Components


Arbiter tray CPU Front panel Centre for autoUp to select BAP A as masterDown to select BAP B as master

Rotary Switch Arrow pointing to 4 : Arbiterin centre of board

CU and Telex Front panel Not usedSwitchover traysCPU Rotary Switch Arrow pointing to 8 : Switch Controller

in centre of board

Switch Settings A4-OPG-003076Issue 3.23 - Accepted

17th July 2001

A-4

Arbiter tray PSU/relay card Centre for autoSee note Switch nearest Up to connect BAPA

front of rack Down to connect BAPB

Arbiter tray PSU/relay card Centre for autoSee note Switch nearest Up to connect DEMSA-A

rear of rack Down to connect DEMSA-B

CU Switchover tray PSU/relay card Centre for autoSee note Switch nearest Up to connect CUC1A

front of rack Down to connect CUC1B

CU Switchover tray PSU/relay card Centre for autoSee note Switch nearest Up to connect CUC2A

rear of rack Down to connect CUC2B

Telex Switchover PSU/relay card Centre for autotray Switch nearest Up to connect TIC1ASee note front of rack Down to connect TIC1B

Telex Switchover PSU/relay card Centre for autotray Switch nearest Up to connect TIC2ASee note rear of rack Down to connect TIC2B

Alarm Printer Auto/Manual Auto (up)Normal/Self Test Normal (up)Letter/Draft Draft (down)Online/Offline Online (up)

Note : the switches on the PSU/relay card must only be used when the CPU card (in slot 0) of thesame tray is removed.

[opga1.mss]

A4-OPG-003076 Registered User DetailsIssue 3.23 - Accepted17th July 2001

B-1

Appendix B

REGISTERED USER DETAILS

This appendix lists all the details about registered users which need to be available before a regis-tered user can be added to the ACSE database. Section B describes the uses of the fields.

The key to the form - must be completed.

PIN Personal identity number, up to 8 alphanumeric characters,no spaces.

General information; optional and required for reference purposes only

User name Plain text, up to 45 characters, any formatAddress, line 1 Plain text, up to 30 characters, any formatAddress, line 2 Plain text, up to 30 characters, any formatAddress, line 3 Plain text, up to 30 characters, any formatPostal code Plain text, up to 15 characters, any formatCountry Plain text, up to 20 characters, any formatContact name Plain text, up to 45 characters, any formatContact tel Up to 20 numbers, as dialled from the earth station

Delivery Information for NDNs - complete if NDNs are to be sent to the user

Address format up to 13 characters, telex, PSDN, PSTN, mobileAddress up to 69 characters, format as in section 8.3.11Address extension up to 4 characters, format as in section 8.3.11Enabled for useas NDN or PDN Yes or No

Authorisation information, summarizing the registered services available to this user -complete all these fields.

Store & forward messages normally set to YesMessage status enquiry normally set to YesCancel messages Yes or NoPolling Yes or NoData reporting Yes or NoEGC Yes or NoDistress priority messages Yes or NoPIN for use with telex Yes or NoPIN for use with X25/X400 Yes or No

Password 6 - 10 characters, initially set by operatorAnswerback 13 characters, numbers and upper case letters only PDNYes or No

Registered User Details A4-OPG-003076Issue 3.23 - Accepted

17th July 2001

B-2

EGC definition, to be completed if EGC shown as Yes in authorisation information above.

Show the individual EGC services authorised to this user by their EGC Service code (C3) asdefined in the reference [1] M5 S9.3.3 and the service type - System, SafetyNET or FleetNET.

Type Use0 System General call2 FleetNET Group call4 SafetyNET Urgency message, NAV warnings to rectangular area11 System System message12 SafetyNET Coastal warning14 SafetyNET Shore to ship distress alert to circular area23 System EGC system message24 SafetyNET Urgency message, MET/NAV warnings to circular area31 SafetyNET NavArea warning or MET forecast33 System Download ENID (See section 9.4)34 SafetyNET SAR coordination to rectangular area44 SafetyNET SAR coordination to circular areas72 FleetNET Chart correction service74 SafetyNET Chart correction fixed area

Polling definition, to be completed if Polling shown as Yes in authorisation informationabove

Show the individual poll commands which the user can issue corresponding to the Command typedescribed in reference [1] M3 Supplement 2 para 4.4.4.2.

Code Use0 Send unreserved data report1 Program reserved2 Initiate reserved3 Stop reserved4 Program unreserved5 Initiate unreserved6 Stop unreserved7 Define macro encoded message8 Macro encoded message9 Data transmission10 Download DNID (See section 9.4))11 Delete DNID (See section 9.4))

Data Reporting definition, to be completed if Data Reporting shown as Yes in authorisationinformation above

Set the data report file size in bytes, a 7 digit number, with a maximum of 1,000,000. This is themaximum space allocated to that user for any DNIDs which are authorised.

Enter the DNID numbers to which he can have access. Up to twenty DNIDs can be allocated toone PIN.

[opga2.mss]

A4-OPG-003076 Guide to using the FAX PCIssue 3.23 - Accepted17th July 2001

C-1

Appendix C

GUIDE TO USING THE FAX PC

C.1 Overview

This guide is intended to provide a brief overview of the use of the FAX PC, plus some troublesh-ooting hints.

Further details are provided in reference [5].

A further description of the facilities associated with the Zetafax software running on the PC iscontained in the Zetafax User Guide, Appendix B, Reference [6].

A Fax message transmission takes the following path through the LES system :

1. The Message Director software queues up Fax messages to be processed by theLESFAX software.

2. LESFAX process will create a text file suffixed with .SUB for each Fax message thatit receives. This file is created in "Zetafax API submit file" format and is placed into acommon work area on the ShadowDisk. This work area is shared between theLESFAX and PCFAX processes, shared directory access being provided by theDigital Pathworks software.

3. As part of its startup procedure the Fax PC will initiate the PCFAX process which willperiodically search for .SUB messages within the shared disk area. PCFAX isresponsible for converting .SUB files into .WPC files and submitting them to Zetafaxvia the Zetafax API interface.

4. The third party Zetafax software receives Fax messages from the PCFAX softwareand is responsible for ensuring that these messages are successfully delivered. TheZetafax software is responsible for driving up to four Fax modems, and a maximumof eight messages can be queued within the Fax PC awaiting transmission. (Notethat this value of eight is set within PCFAX and currently it is not user configurable).

5. PCFAX will periodically interrogate the Zetafax API interface for successful and un-successful Fax message deliveries. Once final delivery status is determined PCFAXwill create a file suffixed by .DEL, within the common work area, containing deliverydetails. In addition the associated .WPC file will be renamed to .FIN to indicate thatPCFAX has finished with the message.

6. LESFAX will periodically scan the common work area for files suffixed with .FIN. Theassociated .DEL file is then read and a delivery call record is logged. Delivery detailsare returned to Message Director and finally the processed .FIN and .DEL files aredeleted.

C.2 Taking a Fax PC Out Of Service

The following procedure should be followed in order to take a Fax PC out of service, for examplefor routine maintenance.

• From the FAX PC Display form on the SOC determine the current state of the Fax PCin question.

• If the Fax PC is not in Out Of Service state, then from the FAX PC Management form

Guide to using the FAX PC A4-OPG-003076Issue 3.23 - Accepted

17th July 2001

C-2

request that the PC state become OOS. If the PC has no calls in progress then itshould now become OOS. But if there are still fax calls in progress then the Fax PCshould now be Pending OOS. Wait for the PC to become OOS.

• Now maintenance can be performed on the PC. If a modem card is to be removedthen follow the section Placing a Fax Modem Card Out of Service.

C.3 Shutting Down Fax PC Machines

The Fax PCs should never be shutdown simply by turning off the power. This could potentiallyresult in hard disk problems. The correct and safe procedure is to double-right click on the OS/2desktop and select the ’Shut-Down...’ option. Then respond with OK to any warnings about clos-ing down sessions and windows containing active programs. The machine can be powered offonce the shutdown procedure has completed.

Occasionally the OS/2 shutdown sequence will not complete. If this occurs then just invoke shut-down again. If the system still won’t shutdown then close any open windows manually (left click ontop left of menu bar and select "Close" for any active windows) and then Control-Alt-Delete andwait a few seconds before powering off the PC.

C.4 Installing a New Fax PC

The following procedure should be followed in order to install a new Fax PC. It is assumed thatthe PC has already been configured to be a Fax PC and that the PC is known to Pathworks on theBAP, in accordance with the LES Configuration Document.

• From the FAX PC Definition form add a new entry for the PC. The PC nodenameshould be the same as the name quoted to Pathworks and NCP during PC configura-tion. The current state should be set to OOS.

C.5 Starting Up Fax PC Machines

When the Fax PC is restarted a number of devices drivers are loaded, OS/2 will be started andtwo Fax windows will start up automatically.

The first of these Fax windows is titled "STARTUP.CMD" and should list the loading of Pathworks,LAN Requester and LAN Server. These should all start successfully. During this stage if a Loginwindow for the LAN Server appear then click on "Cancel" to remove it. Next drives D: and E:should be redirected to the work area on the Vax nodes. Finally the PCFAX software shouldinitialise. It is responsible for starting up the Zetafax Server and will create a file 00000000.SYN inthe workarea to indicate to the LES that it has started. LESFAX acknowledges PCFAX by remov-ing this synchronization file. When PCFAX detects the file removal it will complete its’ initializationand begin scanning the workarea for Fax messages to process. In addition PCFAX periodicallycreates a heartbeat file (11111111.SYN) in the workarea to indicate to LESFAX that it is still run-ning. LESFAX is responsible for periodically deleting this file.

The second of these windows is titled "Zetafax Monitor". It should report messages from theZetafax Server. Initially the current Zetafax licence details are reported. Then the Server enters its’initialization sequence. Old Zetafax logfiles are removed, communication is established with theFax modem cards and the messages "Server started" and "Initialization complete" should appear.

C.6 Bringing a Fax PC Into Service

The following procedure should be followed in order to bring a Fax PC into service, for examplefollowing routine maintenance.

A4-OPG-003076 Guide to using the FAX PCIssue 3.23 - Accepted17th July 2001

C-3

• Reboot the Fax PC and ensure that it restarts correctly - by checking the OS/2 win-dows STARTUP.CMD and Zetafax Monitor to ensure that no errors are reported.The Fax software on the PC should now be waiting for synchronization with the BAP.

• From the FAX PC Management form on the SOC request that the PC in questionbecome In Service. The PC state should change from OOS to INS as contact is es-tablished between the Fax PC and the BAP.

C.7 PC Fax Trouble Shooting Hints

To determine the state of the Fax PC examine the following :

1. The Zetafax Monitor window gives a good indication of the status of Zetafax. Anymessages currently queued for Zetafax will be listed here together with their currentstatus :

SENDING Message is currently transmitting to the quoted Fax number.

CONNECTING Zetafax is currently dialling the quoted Fax number.

WAITING Message is held waiting for transmission. This may be becausethe Fax number was engaged earlier and the message trans-mission is to be reattempted, or it may be because all themodem cards on the Fax PC are currently in use.

Zetafax maintains a simple text file of all messages logged by the Zetafax Serverduring the current run: (C:\ZETAFAX\SERVER\Z-DB\SERVER.LOG) This file keepsgrowing whilst Zetafax Server is running and is cleared down each time the ZetafaxServer is restarted.

2. The STARTUP.CMD window will give a good indication of the start of the PCFAXsoftware and the underlying software upon which it is dependent.

3. If a problem is suspected with one of the Fax modem cards then the status of thesecards can be determined from the Zetafax Workstation program:

• Double left click on Zetafax icon, from the OS/2 desktop.

• Double left click on the Zetafax Workstation icon.

• Left click on Status and select Server.

• From this Server status window determine the status of fax devices.

4. Chronological event logs of significant events are maintained in a series of log files(of the form: C:\ZETAFAX\SERVER\Z-DB\Z-YYMMDD.LOG) These can besearched via the Zetafax Workstation log menu.

C.8 Fax PC Software Notes

The period for which the Zetafax Server will maintain the event logs is configurable within the fileC:\ZETAFAX\SYSTEM\Z-DB\SETUP.INI. The directive is within the [OPTIONS] section as :

LogKeepDays: <days> { Default: 0 days i.e. no logging }

The transmission retry period and the number of retransmission attempts are also configurablewithin this file under the [QUEUEMAN] section as :

SendRetryWait: <seconds> { Default: 5 minutes }

Guide to using the FAX PC A4-OPG-003076Issue 3.23 - Accepted

17th July 2001

C-4

SendTries: <count> { Default: 5 attempts }

The Zetafax server will submit each new message to the next available (i.e. Configured and Idle)modem by incrementing the modem number from the last modem that was used, wrapping backto the first modem when all modems have been used. If a message cannot be delivered by thedesignated modem the message will be submitted to another modem until either delivery is suc-cessful or the maximum number of delivery attempts is reached. This ensures that all availablemodems will attempt to deliver a message before a failure is registered and that failure of a singlePSTN line or Modem does not cause messages to fail.

[opga3.mss]

A4-OPG-003076 Guide to Setting Up Asynchronous CommunicationsIssue 3.23 - Accepted17th July 2001

D-1

Appendix D

GUIDE TO SETTING UP ASYNCHRONOUS COMMUNICATIONS

This is now more fully described in the Configuration Guide, 5.

Call Completion Code List A4-OPG-003076Issue 3.23 - Accepted

17th July 2001

D-2

A4-OPG-003076 Call Completion Code ListIssue 3.23 - Accepted17th July 2001

E-1

Appendix E

CALL COMPLETION CODES

This list below shows the completion codes which are configured initially. This information is ex-tracted from the software files and is therefore in the format :

CCC "Text " Text_LenICR DCR DESCRIPTION

where:CCC is the call completion codeText_Len is the length of the text between " " in the first line of each entry.ICR - ’yes’ below this indicates that the CCC will be entered in the incoming call recordDCR - ’yes’ below this indicates that the CCC will be entered in the delivery call record

Where appropriate, only the CCC and description are shown below.

In some cases, there is no entry in either the ICR or the DCR. This arises when the CCC isgenerated at a stage in the call where no call record has been created.

NOTE: Any FAX Call Completion Calls refer to the final attempt. It is feasible that previous deliveryattempts may have failed (for the same or other reasons).

The list below is indexed by the call completion code.

-1 "UNK Unknown " 11ICR DCR DESCRIPTIONno no Initial CCC set by input driver - changed to ITD by MDir

if routed successfully, to failure CCC if not

0 "SUC Call Success " 16ICR DCR DESCRIPTION

1 "SUC Unconfirmed by user"ICR DCR DESCRIPTION

2 "SUC Unconfirmed by oper "ICR DCR DESCRIPTION

3 "SUC Unconfirmed on expiry set by user "ICR DCR DESCRIPTION

4 "SUC Unconfirmed on expiry set by oper "ICR DCR DESCRIPTION

5 "SUC Unconfirmed on expiry set by system "ICR DCR DESCRIPTION

10 "SUC TLX No EOT Received " 23ICR DCR DESCRIPTIONyes A message was entered, however a line data exceeded cond-

ition occurred, which caused the LES to send the LDE sig-nal, the subsequent required time for end of text to beentered by the user then also expired

11 "SUC TLX LDE Transmitted " 23


17th July 2001

E-2

ICR DCR DESCRIPTIONyes A message was entered but either the size was greater

than permitted or the duration allowed for message entryhas expiredLDE - Maximum acceptable message length or duration has

been exceeded

12 "SUC TLX Forced Clear On Idle Detection " 38ICR DCR DESCRIPTIONyes A message was entered into the LES, but the user timed

out with idle causing the LES to clear the call.

13 "SUC TLX User Cleared Successful " 31ICR DCR DESCRIPTIONyes A message was entered but the user cleared without enter-

end of text

14 "SUC TLX No Answerback End Of Call " 33ICR DCR DESCRIPTIONyes The calling party did not provide a answerback at the end

of the call although a WRU was sent

15 "SUC TLX Text After EOT " 22ICR DCR DESCRIPTIONyes Text detected after EOT received while waiting for WRU

for more than the limit allowed

16 "SUC TLX No Clear Confirm Successful " 35ICR DCR DESCRIPTIONyes yes The LES has no received a clear signal in response to its

own clear, although the message transfer was successful

17 "SUC TLX Tape Stuck Success " 26ICR DCR DESCRIPTIONyes The tape stuck condition was detected on the line for an

incoming call (more than 80 identical consecutive combin-ations

18 "SUC TLX Automatic Eqp Failed To Clear " 37ICR DCR DESCRIPTIONyes An automatic terminal i/c call failed to clear down first

and the LES had to forward clear as a result

30 "SUC X25 Backward cleared " 24ICR DCR DESCRIPTION

yes The user acknowledged receipt of the message by clearingthe call while the LES was pausing before clearing thecall itself

Codes in the range 40-49 reserved for X400 service.

50 "SUC SD Satellite Call Succeeded " 31ICR DCR DESCRIPTIONyes yes Call successfully received or delivered or


E-3

PVT completed successfully

60 "SUC MH Success " 14ICR DCR DESCRIPTIONyes no DN successfully generated by MDir

61 "SUC MH CNID Msg Stored " 22ICR DCR DESCRIPTIONyes no DNID addressed message successfully stored

62 "SUC MH Data Report Msg Stored " 29ICR DCR DESCRIPTIONyes no data report successfully stored

63 "SUC MH Not Forwarded CNID Msg Stored " 36ICR DCR DESCRIPTIONyes no DNID addressed message successfully stored on

failing to be immediately forwarded

64 "SUC MH Not Forwarded Data Report Stored " 39ICR DCR DESCRIPTIONyes no data report successfully stored after failing to

be immediately forwarded

65 "SUC MH Data Report Not Delivered " 32ICR DCR DESCRIPTIONyes no A mobile status data report was not delivered because

no DNID was specified for the PIN or the mobilestatus was unchanged

70 "SUC FAX Message Transmitted " 27ICR DCR DESCRIPTIONNo Yes Message was delivered successfully

150 "DBU Unconfirmed by user " 23ICR DCR DESCRIPTION

151 "DBU Unconfirmed by oper " 23ICR DCR DESCRIPTION

152 "DBU Unconfirmed on expiry set by user " 37ICR DCR DESCRIPTION

153 "DBU Unconfirmed on expiry set by oper " 37ICR DCR DESCRIPTION

154 "DBU Unconfirmed on expiry set by system " 39ICR DCR DESCRIPTION

200 "BK Clear Down " 14ICR DCR DESCRIPTIONyes yes Either: Message aborted by LES operator

or : Forced clear received from the mobileor : Distress received from the mobileor : Call prematurely clearedor : Message cut by message of higher priorityor : Call was cut or disconnected


17th July 2001

E-4

202 "ABS Absent Subscriber " 21ICR DCR DESCRIPTIONyes Either: Machine switched off

or : Mobile not logged into ocean region

203 "BK Message Aborted " 19ICR DCR DESCRIPTIONyes yes Delivery aborted by Message Handler

due to driver interface error

204 "BMC No End of Message or End of TX RXed " 39ICR DCR DESCRIPTION

205 "DER Out Of Order " 16ICR DCR DESCRIPTIONyes yes Internal error within the LES

Protocol error from the mobile

206 "DTE Remote DTE Clearing " 23ICR DCR DESCRIPTION

207 "FMT Format Error " 16ICR DCR DESCRIPTIONyes Message did not contain address line

208 "IAB Invalid Answerback " 22ICR DCR DESCRIPTIONyes Either: No final answerback received from destination

or : No initial answerback returned by destinationor : Wrong initial answerback sent by destinationor : Wrong final answerback returned by destination

209 "INF Call the Network Information Service" 40ICR DCR DESCRIPTIONyes The mobile has failed to respond

210 "INV Invalid Call " 16ICR DCR DESCRIPTION

212 "LDE Maximum Message Length Exceeded " 35ICR DCR DESCRIPTION

213 "LPE Local Protocol Error " 24ICR DCR DESCRIPTION

214 "MOM Mobile Waiting For Clear " 28ICR DCR DESCRIPTION

215 "NA Access to This Number Barred " 32ICR DCR DESCRIPTIONyes Either: Access to this mobile barred

or : The destination is incompatibleor : Fast select acceptance not subscribedor : Called address refuses connection

216 "NC Network Congestion " 22ICR DCR DESCRIPTION

217 "NCH Subscribers Number Has Changed " 34ICR DCR DESCRIPTION


E-5

218 "NDA No Delivery Attempt Has Been Made " 37ICR DCR DESCRIPTIONyes Call not yet started

Currently attempting to deliver the message

219 "NP Not Obtainable " 18ICR DCR DESCRIPTION

220 "NRC Rev Charging Accept Not Subscribed " 38ICR DCR DESCRIPTION

Reverse charging acceptance not subscribed

221 "OCC Number Busy " 15ICR DCR DESCRIPTION

222 "RDI Redirected Call " 19ICR DCR DESCRIPTION

223 "RPE Remote Protocol Error " 25ICR DCR DESCRIPTION

224 "TMD Maximum Number of Addresses Exceeded" 40ICR DCR DESCRIPTION

225 "UNK Unknown Reason For Failure " 30ICR DCR DESCRIPTION

229 "ITD Awaiting Delivery " 21ICR DCR DESCRIPTIONno no First delivery attempt pending for normal delivery, EGC

or poll TX, or EGC or poll echo - CCC returned to ITD onTX or echo completion if further TX or echo required

230 "ITD Await.Deliv. by 3rd party SAF system" 40ICR DCR DESCRIPTIONno no Delivery to third-party store-and-forward system partly

complete - remote delivery completion pending (X.400)

231 "NA Invalid Presentation Code " 29ICR DCR DESCRIPTION

232 "BK Cancelled by user " 21ICR DCR DESCRIPTION

Cancelled by user

233 "BK Cancelled by oper " 21ICR DCR DESCRIPTION

Cancelled by operator

234 "BK Cancelled on expiry set by user " 35ICR DCR DESCRIPTION

Cancelled by system on expiry of cancellation time setby user

235 "BK Cancelled on expiry set by oper " 35ICR DCR DESCRIPTION

Cancelled by system on expiry of cancellation time setby operator

236 "BK Cancelled on expiry set by system " 37ICR DCR DESCRIPTION

Cancelled by system on expiry of cancellation time set


17th July 2001

E-6

by system

237 "BK Cancelled on TX failure " 27ICR DCR DESCRIPTION

Cancelled by system on transmission failure - atransmission of an EGC or poll message has failed

238 "BK Cancelled on route failure " 30ICR DCR DESCRIPTION

Cancelled by system on route failure - one or more routeshave been unavailable for too long

239 "BK Cancelled by user without NDN " 33ICR DCR DESCRIPTION

Cancelled by user, but no NDN generated

240 "BK Cancelled by oper without NDN " 33ICR DCR DESCRIPTION

Cancelled by user, but no NDN generated

245 "NA Not Commissioned " 20ICR DCR DESCRIPTION

Cannot deliver from not commissioned

400 "DER FAX Cannot Deliver Via This Route " 37ICR DCR DESCRIPTIONNo Yes Unable to deliver message via the specified route.

The Fax Driver has no record of the route MessageHandler has specified as the delivery route.

401 "DER FAX No PC Available On This Route " 37ICR DCR DESCRIPTIONNo Yes Unable to deliver message via the specified route.

The Fax Driver cannot find a PC on the route MessageHandler has specified as the delivery route.

402 "DER FAX Failed To Secure Message To PC " 38ICR DCR DESCRIPTIONNo Yes Unable to secure message to the Fax PC’s hard disk,

this could indicate a Pathworks problem.

403 "LPE FAX Invalid Delivery File " 29ICR DCR DESCRIPTIONNo Yes Unable to process a delivery file correctly due to either

the .FIN or .DEL file being invalid. This situation mayarise due to a PC returning an invalid file, a file beinglocked or corrupted. It should be assumed that deliveryfailed, though this is not certain.

404 "LPE FAX Path Not Found " 22ICR DCR DESCRIPTIONNo Yes The required path cannot be found, possibly due to a

Pathworks problem.

407 "DER FAX PC Failure " 18


E-7

ICR DCR DESCRIPTIONNo Yes No PC on the specified route has been able to deliver the

message. The message was secured to a PC but the PC hassince developed a problem preventing delivery.

410 "LPE FAX Cannot Access Control File " 34ICR DCR DESCRIPTIONNo Yes Unable to access the PC control file for this message or

control file is invalid.

411 "LPE FAX Cannot Access Message File " 34ICR DCR DESCRIPTIONNo Yes Unable to access the PC message file for this message or

message file is invalid.

412 "NC FAX PC Disk Full " 20ICR DCR DESCRIPTIONNo Yes Unable to create the necessary PC files to send the

message due to the PC hard disk being full.

413 "LPE FAX Bad Zetafax INI File " 28ICR DCR DESCRIPTIONNo Yes Unable to access the Zetafax.INI file or Zetafax.INI

file is invalid.

414 "LPE FAX Cannot Convert Message " 30ICR DCR DESCRIPTIONNo Yes Unable to convert message into the correct format for

Zetafax.

415 "LPE FAX Cannot Access Letterhead " 32ICR DCR DESCRIPTIONNo Yes Unable to access letterhead for this message or

letterhead file is invalid.

416 "LPE FAX Cannot Access Graphic " 29ICR DCR DESCRIPTIONNo Yes Unable to access graphics file specified in this message

or graphics file is invalid. The term ’message’ refers tothe fax banner and message text.

417 "DER FAX Device Failed " 21ICR DCR DESCRIPTIONNo Yes Unable to send message from this fax modem device due to

the device failing. This device will remain in a failedstate.

418 "NC FAX Device Busy " 19ICR DCR DESCRIPTIONNo Yes Unable to send message from this fax modem device due to

the device being busy.

419 "NC FAX Device Offline " 22


17th July 2001

E-8

ICR DCR DESCRIPTIONNo Yes Unable to send message from this fax modem device due to

the device being offline. Device should recover.

420 "LPE FAX Device Invalid " 22ICR DCR DESCRIPTIONNo Yes Unable to send message from this fax modem device due to

the device being invalid. Device may be incompatible orconfigured incorrectly.

421 "NC FAX No Device Available " 27ICR DCR DESCRIPTIONNo Yes Unable to deliver message as there are no working fax

modem devices of the correct type in the delivering PC.

422 "DER FAX Device Protocol Error " 29ICR DCR DESCRIPTIONNo Yes Unable to deliver message due to a serious error in

communicating with this fax modem device.

423 "BK FAX Device Timeout " 22ICR DCR DESCRIPTIONNo Yes Unable to deliver message from this fax modem device due

to the device timing out.

424 "LPE FAX No Dial Tone " 20ICR DCR DESCRIPTIONNo Yes No dialtone detected by the fax modem when a call attempt

was made. This indicates either a failure in the exchangeor the connection to the exchange.

425 "NA FAX No Dial Permit " 22ICR DCR DESCRIPTIONNo Yes No permission to dial the specified number.

426 "OCC FAX Number Busy " 19ICR DCR DESCRIPTIONNo Yes Dialled number was busy.

427 "NP FAX No Reply " 16ICR DCR DESCRIPTIONNo Yes No answer from dialled number.

428 "RPE FAX Invalid Response " 24ICR DCR DESCRIPTIONNo Yes An incorrect response was received from the dialled

number, i.e. Call answered but not by a valid faxmachine. This covers answer by human, other machine(i.e. modem) or faulty fax machine.

429 "BK FAX Transmission Error " 26ICR DCR DESCRIPTIONNo Yes Unable to deliver message due to a communications error

occurring during transmission of the message, e.g. callcut off.


E-9

430 "LDE FAX Message Too Long " 24ICR DCR DESCRIPTIONNo Yes Message is too long to be delivered.

431 "UNK FAX Send Failed " 19ICR DCR DESCRIPTIONNo Yes This is used to report problems which cannot be more

accurately identified and are not covered by othermessages.

500 "NC TLX Idle Timeout " 20ICR DCR DESCRIPTIONyes no For an incoming call, the call has gone idle - i.e. the

user has stopped transmitting for the time allowed.

501 "NC TLX No Seize Confirm " 24ICR DCR DESCRIPTIONno yes The called party has not responded to the LES seize

signal

502 "NC TLX No PTS Received " 23ICR DCR DESCRIPTIONno yes For an o/g call the LES has not received the proceed to

send signal.

503 "FMT TLX Invalid Format " 22ICR DCR DESCRIPTIONno yes For an outgoing call the LES has received a format error

service code (FMT).

504 "NC TLX User Cleared " 20ICR DCR DESCRIPTIONyes yes For either o/g or i/c call the called/calling party has

cleared the call before the expected end of call.

505 "NC TLX User Cleared Awaiting COT " 33ICR DCR DESCRIPTIONyes no For an i/c call the LES was waiting for a trunk Type C

Class of Traffic character (COT), when the callerterminated the call by clearing the line.

506 "NC TLX User Cleared Awaiting COT Check " 39ICR DCR DESCRIPTIONyes no For an i/c call the LES was waiting for a trunk Type C

Class of Traffic Check character (COTC), when the callerterminated the call by clearing the line.

507 "NC TLX User Cleared Awaiting Selection " 39ICR DCR DESCRIPTIONyes no For an i/c call the LES was waiting for the selection

digits when the caller cleared the call.

508 "NC TLX User Cld Await Selectn Validn " 37ICR DCR DESCRIPTIONyes no For an i/c call the LES was validating the received

selection digits when the calling party cleared the call

509 "NC TLX User Cld Awaiting IC Answerback " 39ICR DCR DESCRIPTIONyes no For an i/c call the calling party cleared the call when

the LES was waiting for the calling party answerback.


17th July 2001

E-10

510 "NC TLX Circuit Fault " 21ICR DCR DESCRIPTIONyes yes A protocol error or communications error related to the

circuit behaviour has been detected.

511 "OCC TLX Busy " 12ICR DCR DESCRIPTIONno yes The LES has received on an o/g call, the OCC service

signal instead of call connect

512 "NC TLX Congested " 17ICR DCR DESCRIPTIONyes yes If DCR then the LES has received, on an o/g call the NC

service signal. If in the ICR, then the LES has rejectedan i/c call due to insufficient call storage resources.

513 "ABS TLX Absent " 14ICR DCR DESCRIPTIONyes yes If DCR then the LES has received, on an o/g call the ABS

service signal. If in the ICR, then the LES has rejectedthe call because the mobile addressed is not logged onin the ocean region(s) supported by the LES.ABS - Absent subscriber/Office closed

514 "DER TLX Out Of Order " 20ICR DCR DESCRIPTIONno yes For an o/g LES call the LES has received the service

signal DER instead of call connectDER - Out of order

515 "NC TLX No Circuits " 19ICR DCR DESCRIPTIONyes For an i/c call, the address had an incorrect F69 code

516 "NP TLX Not Permitted " 21ICR DCR DESCRIPTIONyes yes For an o/g call, the LES received the service signal NP,

for an i/c call, the address was invalid or not in theship listNP - The called party is not, or is no longer asubscriber

517 "NA TLX Not Admitted " 20ICR DCR DESCRIPTIONyes yes For an o/g call, the LES received the service signal NA,

for an i/c call, the mobile addressed was barred or notauthorised for accessNA - Correspondence with this subscriber is not admitted

518 "OCC TLX Engaged " 15ICR DCR DESCRIPTIONyes For an i/c call the addressed mobile was engaged.

519 "INF TLX Unobtainable Call Info Service " 38ICR DCR DESCRIPTION

yes For an o/g call the LES received the service signalINF, in place of call connectINF - subscriber temporarily unobtainable, call inform-

service

520 "MOM TLX Waiting " 15ICR DCR DESCRIPTION


E-11

yes For an o/g call the LES received the service signal MOMMOM - wait/waiting

521 "JFE TLX Closed " 14ICR DCR DESCRIPTION

yes For an o/g call the LES received the service signal JFEJFE - Office closed because of holiday

522 "BK TLX I Cut Off " 15ICR DCR DESCRIPTIONyes yes For an o/g call the LES received the service signal BK

For an i/c call the LES has cleared the call to due idletimeout, 3 consecutive invalid inputs, or paper tapestuck conditions

523 "UNK TLX Other Service Signal " 28ICR DCR DESCRIPTION

yes An unsupported service signal was received when the LESwas attempting telex delivery.

524 "IAB TLX Unexpected Answerback " 29ICR DCR DESCRIPTION

yes The answerback received from the called party does notmatch the expected answerback given by the caller

525 "DER TLX No Answerback " 21ICR DCR DESCRIPTIONyes yes For either i/c or o/g calls the LES failed to received

an answerback from the far end within the required time.Also if answerback is larger than maximum expected by LES

526 "IAB TLX Answerback Mismatch " 26ICR DCR DESCRIPTION

yes For an outgoing, where enabled, the answerback at thestart of the call did not match that received at the endallowing for one character mismatch

527 "NC TLX Back Path Signals " 25ICR DCR DESCRIPTION

yes While delivering a telex call the LES detected characterson its received path exceeding the limit allowed for this

528 "NC TLX LES Failure " 19ICR DCR DESCRIPTIONyes yes An software error was detected

529 "NC TLX Tape Stuck " 18ICR DCR DESCRIPTIONyes For an incoming call more than 80 consecutive exact comb-

inations were detected causing the tape stuck condition

530 "NC TLX Call Preempted By IC " 28ICR DCR DESCRIPTION

yes For bidirectional working, current no supported, the o/gcall could not be delivered due to an incoming calloccupying the line.

531 "NC TLX Outgoing Circuit Guarded " 32ICR DCR DESCRIPTION

yes The outgoing call could not be made because the line wasin its guard state. This code will only occur if there isan interprocess communications fault


17th July 2001

E-12

532 "NC TLX No Call Connect " 23ICR DCR DESCRIPTION

yes For an o/g call the LES did not receive the call connectsignal within the time allowed

533 "NP TLX No Clear Confirm " 24ICR DCR DESCRIPTIONyes yes The far end has failed to respond with a clear signal

subsequent to the LES sending clear

534 "NC TLX No RC TC " 16ICR DCR DESCRIPTION

yes For Type C trunk signalling, during an outgoing call theLES failed to receive the reception confirmation andtransmission confirmation characters

535 "NRT TLX No Further Retests Needed " 33ICR DCR DESCRIPTIONn/a n/a Used internally within the telex driver to notify the

retest algorithm that no retests are needed - i.e. thecircuit is now operating correctly

536 "NA TLX Invalid Seize Combination " 33ICR DCR DESCRIPTIONyes For Type C trunk signalling, an incoming call was

received but the seize combinations ’T’s were not correc-tly received

537 "NA TLX Invalid COT " 19ICR DCR DESCRIPTIONyes For Type C trunk signalling the class of traffic combina-

tion was not as expected

538 "NA TLX Invalid COT COTC " 24ICR DCR DESCRIPTIONyes For Type C trunk signalling the combined class of traffic

and class of traffic check character do not validate

539 "NA TLX No COT Sent " 19ICR DCR DESCRIPTIONyes For Type C trunk signalling the class of traffic charac-

was not received by the LES during an incoming call

540 "NA TLX COT Not Permitted " 25ICR DCR DESCRIPTIONyes For Type C trunk signalling, for an i/c call the COT

combination received is not permitted

541 "RTD TLX Incoming Retest Detected " 32ICR DCR DESCRIPTIONyes For Type C trunk signalling, an incoming retest call has

been received

542 "DER TLX Incoming Message Not Secured " 36ICR DCR DESCRIPTIONyes The LES was unable to store the received message, either

due to a resource failure or a software fault

543 "NA TLX No PIN " 14ICR DCR DESCRIPTIONyes For registered access no PIN was received


E-13

544 "NP TLX Invalid PIN " 19ICR DCR DESCRIPTIONyes For registered access the PIN received was invalid

545 "NA TLX No WRU " 14ICR DCR DESCRIPTIONyes For subscriber signalling the exchange failed to send a

WRU combination at call initiation

546 "NC TLX Invalid PTS " 19ICR DCR DESCRIPTION

yes For an o/g call the LES did not receive a valid proceedto send character

547 "NC TLX Stn CLosed Await IC Answerback " 38ICR DCR DESCRIPTION

548 "NC TLX Stn Closed Await CLear Confirm " 38ICR DCR DESCRIPTION

549 "NC TLX Station Closed " 22ICR DCR DESCRIPTION

550 "NCH TLX Number Changed " 22ICR DCR DESCRIPTION

yes For an o/g call, the LES received the service signal NCHinstead of call connect

551 "NC Multi delivery address not supported" 40ICR DCR DESCRIPTION

552 "NC No outgoing circuit available " 33ICR DCR DESCRIPTION

553 "NC No free circuit at the moment " 33ICR DCR DESCRIPTION

554 "NC Too many attempts at delivery " 33ICR DCR DESCRIPTION

555 "NC Software err: MES AB rtn failed " 35ICR DCR DESCRIPTION

556 "NC Software err: CODT i/f failed " 33ICR DCR DESCRIPTION

557 "NC Software err: MDIR ROU i/f failed " 37ICR DCR DESCRIPTION

558 "NC Software err: MDIR DEL i/f failed " 37ICR DCR DESCRIPTION

559 "NC Software err: TLXIL IC i/f failed " 37ICR DCR DESCRIPTION

560 "NC System err: i/c call record failed " 38ICR DCR DESCRIPTION

561 "NC Software err: TESH i/f failed " 33ICR DCR DESCRIPTION

562 "NC Software err: SDA Regd i/f failed " 37


17th July 2001

E-14

ICR DCR DESCRIPTION

563 "NC User failed to enter valid data " 35ICR DCR DESCRIPTION

564 "NC Oversize message detected " 29ICR DCR DESCRIPTION

565 "NC Circuit not for unregd msg entry " 36ICR DCR DESCRIPTION

566 "NC Call ended due to FEP switchover " 36ICR DCR DESCRIPTION

567 "NC Call ended due to Operator request " 38ICR DCR DESCRIPTION

568 "NC Invalid destination address " 31ICR DCR DESCRIPTION

569 "NC System err: o/g call record failed " 38ICR DCR DESCRIPTION

570 "NC Communication equipment was reset " 37ICR DCR DESCRIPTION

571 "NC Communication equipment fault " 33ICR DCR DESCRIPTION

572 "NC No call connect signal " 26ICR DCR DESCRIPTION

573 "NC BAP timeout on FEP o/g service " 34ICR DCR DESCRIPTION

574 "NC Software err: TLXOL OC i/f failed " 37ICR DCR DESCRIPTION

575 "NC Bad message cause error " 27ICR DCR DESCRIPTION

576 "NC Active circuit gone busy " 28ICR DCR DESCRIPTION

577 "NC Active circuit gone statn close " 35ICR DCR DESCRIPTION

578 "NC Active circuit at fault " 27ICR DCR DESCRIPTION

579 "NC Circuit from Guard to fault " 31ICR DCR DESCRIPTION

580 "NC Circuit fault, o/g seize rejected " 37ICR DCR DESCRIPTION

581 "NC Station closed, o/g seize rejected " 38ICR DCR DESCRIPTION

582 "NC Circuit busy, o/g seize rejected " 36ICR DCR DESCRIPTION


E-15

583 "NC Circuit from busy to fault " 30ICR DCR DESCRIPTION

584 "NC Circuit from busy to Out-of-Service " 39ICR DCR DESCRIPTION

585 "NC Station closed to Out-of-Service " 36ICR DCR DESCRIPTION

586 "NC FEP was inactive " 20ICR DCR DESCRIPTION

587 "NC Incorrect termination character " 35ICR DCR DESCRIPTION

588 "NC LO timeout on msg transmit ack " 34ICR DCR DESCRIPTION

589 "NC Failed to format delivery message " 37ICR DCR DESCRIPTION

590 "NC FEP timeout on BAP delivery service " 39ICR DCR DESCRIPTION

591 "NC FEP timeout on FEP line service " 35ICR DCR DESCRIPTION

592 "NC LO stopped by LM " 20ICR DCR DESCRIPTION

593 "NC LO was prohibited to do delivery " 36ICR DCR DESCRIPTION

594 "NC IL timeout on FEP line service " 34ICR DCR DESCRIPTION

600 "DER X25 Remote Procedure Error " 30ICR DCR DESCRIPTIONYes Yes Problem in X25 protocol handling by the remote DTE

601 "NA X25 Access Barred " 21ICR DCR DESCRIPTIONYes Yes If in ICR : The requested service is barred for the PIN

If in DCR : The destination address rejected the call.

602 "LPE X25 Local Procedure Error " 29ICR DCR DESCRIPTIONYes Yes Problem in X25 protocol handling by the local DTE

603 "NA X25 DTE Incompatible Call " 29ICR DCR DESCRIPTIONNo Yes The destination’s set up is not compatible with LES.

604 "NC X25 Call Collision " 22ICR DCR DESCRIPTIONNo Yes The LES received a call exactly at the same time it was

making a call to a particular destination

605 "NC X25 Restart Received " 24ICR DCR DESCRIPTIONYes Yes X25 Restart Packet received. i.e. network has been reset.


17th July 2001

E-16

606 "NC X25 Reset Received " 22ICR DCR DESCRIPTIONYes Yes X25 Reset packet received. i.e the Virtual circuit reset.

607 "NC X25 Network Timeout " 23ICR DCR DESCRIPTIONYes Yes Network did not reply to LES in the required time limit

Chances are that the network is out of order

608 "NP X25 Protocol Error " 22ICR DCR DESCRIPTIONYes Yes X25 protocol error by local or remote DTE.

609 "NC X25 Internal Cause " 22ICR DCR DESCRIPTIONYes Yes Internal problems with the LES.

610 "DTE X25 User Cleared " 21ICR DCR DESCRIPTIONYes Yes The user has cleared the X25 call.

611 "OCC X25 Number Busy " 20ICR DCR DESCRIPTIONNo Yes Destination number is busy

612 "DER X25 Out Of Order " 21ICR DCR DESCRIPTIONNo Yes Destination number is out of order.

613 "ABS X25 Not Obtainable " 22ICR DCR DESCRIPTIONNo yes Destination number does NOT Exist.

614 "NC X25 LES Congestion " 22ICR DCR DESCRIPTIONYes No LES is congested. users should try later.

615 "NA X25 Invalid Dest address " 28ICR DCR DESCRIPTIONNo Yes Destination address fails the LES internal validations.

616 "DTE X25 User Abort Trans " 24ICR DCR DESCRIPTIONyes No User has quitted out of a service.

617 "NA X25 Mobile Barred " 21ICR DCR DESCRIPTIONYes No The required mobile is barred

618 "ABS X25 Mobile Absent " 21ICR DCR DESCRIPTIONYes No The required mobile is absent

619 "BK X25 Exceed Retries " 22ICR DCR DESCRIPTIONyes No The user has exceeded number of retries for entering an

valid input to the given prompt. The call has thereforebeen cleared and the service request been aborted.

620 "LDE X25 Max Msgs Exceeded " 25ICR DCR DESCRIPTIONYes No Max limit on follow on message is 10. This upper limit


E-17

has been exceeded. i.e the user is trying to send morethan 10 messages in the same session.

621 "LDE X25 Msg Too Long " 20ICR DCR DESCRIPTIONYes No message length exceeded max value.

622 "NC X25 Network Shut " 20ICR DCR DESCRIPTIONYes Yes Network has been shutdown - as a result of operator

request or during a Bap/Demsa switchovers

623 "NC X25 Routing Failure " 23ICR DCR DESCRIPTIONYes No The Message Handler has failed to route the message to

the required mobile

624 "NP X25_PVC_Not_Available " 25ICR DCR DESCRIPTIONNo no PVC assigned to immediate forwarding is out of service.

625 "NA X25_Invalid_Facility " 24ICR DCR DESCRIPTIONYes No Invalid facilities has been requested by the calling DTE.

626 "NC X25_PVC_Queue_Full " 22ICR DCR DESCRIPTIONNo No PVC Queue for immediate forwarding Data Reports is full.

627 "NC X25_PVC_Not_Started " 23ICR DCR DESCRIPTIONNo No Data Report was received before XCCC process was started.

Codes in the range 700-799 reserved for X400 service.

800 "DER SD Satellite Call Failed " 28ICR DCR DESCRIPTIONyes yes Call failed in satellite driver for unspecified reason

801 "ABS SD Mobile Absent " 20ICR DCR DESCRIPTIONyes yes Attempt to deliver call to mobile not now logged into

given ocean region. The mobile status has changedwhile the call was in progress.

802 "BK SD Aborted By Operator " 26ICR DCR DESCRIPTIONyes yes Operator cancelled call

803 "OCC SD Call Failed Due To Distress " 34ICR DCR DESCRIPTIONyes yes Call was aborted due to distress call from same mobile

804 "NA SD Invalid Address In Message " 33ICR DCR DESCRIPTIONyes Message data network type and address mismatch

805 "FMT SD Invalid Address Format " 29ICR DCR DESCRIPTIONyes Invalid address format or invalid address extension or

invalid F69, DNIC, U80, SAC, NMDD, DNID, route number or


17th July 2001

E-18

illegal extension length or illegal address location ormessage packet failed validation

806 "LDE SD Invalid Message Size " 27ICR DCR DESCRIPTIONyes yes Message too long or zero length message

807 "TMD SD Invalid Number Of Addresses " 34ICR DCR DESCRIPTIONyes Message from mobile contained an invalid number of

addresses, e.g. 0 or >20 telex, >8 PSDN or >7 PSTN

808 "NA SD Invalid Presentation " 27ICR DCR DESCRIPTIONyes An unsupported presentation code or a mismatch between

the assignment request data network and presentation code

809 "NC SD LES Internal Error " 25ICR DCR DESCRIPTIONyes yes An unknown or unexpected error in SD e.g.

BAP or FEP switchover, BAP to FEP communications loss,Missing station record or station not in service,Error interfacing with ADV, terrestrial links closed,Internal call record not found

810 "NA SD Mobile Already Commissioned " 33ICR DCR DESCRIPTIONyes yes Attempt to commission an already commissioned mobile

811 "NA SD Mobile Barred " 20ICR DCR DESCRIPTIONyes yes Attempt to send a call to, or receive a call from, a

barred mobile

812 "OCC SD Mobile Busy " 18ICR DCR DESCRIPTION

yes Attempt to send call to an already busy mobile

813 "DER SD Mobile Failed To Respond " 31ICR DCR DESCRIPTIONyes yes Mobile failed to respond when expected

814 "BK SD Mobile Forced Clear " 26ICR DCR DESCRIPTIONyes yes Mobile sent a force clear to cancel the call

815 "NA SD Mobile Not Commissioned " 30ICR DCR DESCRIPTIONyes yes Attempt to send/receive message from non-commissioned

mobile

816 "ABS SD Mobile Not Logged In OR " 30ICR DCR DESCRIPTIONyes yes Attempt to send/receive message from mobile not logged

into this ocean region

817 "NP SD Mobile Not Registered " 28ICR DCR DESCRIPTIONyes Call received from mobile not in the mobile list

818 "DER SD Mobile Responded Incorrectly " 35ICR DCR DESCRIPTION


E-19

yes yes Mobile sent incorrect response or responded out ofsequence

819 "DER SD Mobile Response Timeout " 30ICR DCR DESCRIPTIONyes yes Timeout waiting for mobile response

820 "DER SD Mobile Protocol Error " 28ICR DCR DESCRIPTIONyes yes Mobile did not follow the protocol

821 "NC SD NCS Failed To Respond " 28ICR DCR DESCRIPTIONyes yes NCS failed to send the expected response

822 "BK SD NCS Forced Clear " 23ICR DCR DESCRIPTIONyes yes NCS sent a forced clear to cancel a call

823 "LPE SD Presentation Conversion Error " 36ICR DCR DESCRIPTIONyes yes Cannot convert the given text to the specified

presentation code

824 "NC SD Protocol Failure " 23ICR DCR DESCRIPTIONyes yes SD did not follow the protocol or

a bad state event combination in SD FSM oran unexpected mobile status in registration packet

825 "DER SD Remote Equipment Failure " 31ICR DCR DESCRIPTIONyes yes Mobile failure, the usual reason is message packets not

received from a mobile

826 "NC SD Resource Limit Exceeded " 30ICR DCR DESCRIPTIONyes yes No resources to allocate a TDM group or a call record or

no pending events or MDIR storage full

827 "DER SD Satellite Network Failure " 32ICR DCR DESCRIPTION

- this is no longer used

828 "NA SD Service Not Provided " 27ICR DCR DESCRIPTIONyes Call attempted for a service not provided by the LES,

e.g. ocean region PSTN, SAC, DNID

829 "NC SD Call pending " 19ICR DCR DESCRIPTION

Mobile told to wait to send message until capacity isavailable.

830 "NA SD Invalid LES ID in data report " 36ICR DCR DESCRIPTION

A data report has been received with an invalid LES id.

831 "NC SD TDM Not Available " 24ICR DCR Descriptionno yes No TDM Group assigned to given Ocean

Region and Spot Id combination.


17th July 2001

E-20

832 "NA SD No Msg Status Information " 32ICR DCR Descriptionyes no Unable to obtain message status information

from the database for this call. The messagestatus request is either more than 72 hoursafter the original call or an erroneous MRN wassupplied.

833 "ITD SD Error in Outbound Message " 32ICR DCR DESCRIPTION

An error has been detected in the outbound messagefor an unknown reason.

834 "BK SD EGC Transmission Failed by NCS " 37ICR DCR DESCRIPTIONno yes The NCS has not acknowledged the EGC.

835 "BK SD EGC Packet Sequence Error " 32ICR DCR DESCRIPTIONno yes (In Standalone mode only) The FEP has acknowledged the

transmission of an EGC block that was the blockwhich was expected.

836 "BK SD Call Cleared By System " 29ICR DCR DESCRIPTIONno yes Call has been cleared e.g. if the LES has detected

that it to have been stuck in the system.

837 "OCC SD Cancelled due to Distress EGC " 36ICR DCR DESCRIPTIONno yes No longer required.

838 "DER Announcement failed due to login " 39ICR DCR DESCRIPTIONno yes An outgoing call fails since

the mobile is in the process of logging into adifferent Spot Id or Ocean Region.

839 "ABS SD Call to an incorrect Ocean Region" 40ICR DCR DESCRIPTIONno yes An outgoing call fails since the mobile is no longer

logged into that Spot Id or Ocean Region.

845 "NC SD MSG Channel Overloaded "ICR DCR DESCRIPTIONno yes There are too many concurrent Inbound messages for the

number of message channels.

900 "NC MH Congested " 16ICR DCR DESCRIPTIONno yes MDir did not route delivery due to scheduler or route

congestion

901 "NC MH Routing Failed " 21ICR DCR DESCRIPTIONno yes Unable to determine a route for the delivery from the

address received or the routing information held.Possible causes include incorrect address from the


E-21

mobile (event raised).

902 "NC MH Rerouting Failed " 23ICR DCR DESCRIPTIONno yes Failed to reroute delivery - LES was unable to

determine an alternate route for the delivery from therouting table - possible exhaustion of alternate routes,possible error in routing table (event raised).

903 "NC MH CNID Msg Not Stored " 26ICR DCR DESCRIPTIONno yes CNID addressed message not stored in DNID file due to

problem other than overflow.

904 "NC MH Oper Msg Not Logged " 26ICR DCR DESCRIPTIONno yes MDir failed to log operator message - LFM was unable to

write log records to operator log file (event raised)

905 "NC MH CNID Overflow Occurred " 29ICR DCR DESCRIPTIONno yes CNID addressed message not stored in DNID file due to

overflow.

906 "NC MH Data Report Msg Not Stored " 33ICR DCR DESCRIPTIONyes no Data report not stored in DNID file due to problem other

than overflow.

907 "NC MH Data Report Overflow Occurred " 36ICR DCR DESCRIPTIONyes no Data report not stored in DNID file due to overflow.

opga5.mss

CSPR A4-OPG-003076Issue 3.23 - Accepted

17th July 2001

E-22

A4-OPG-003076 CSPRIssue 3.23 - Accepted17th July 2001

F-1

Appendix F

CUSTOMER SERVICE PROBLEM REPORT

In the event of any problem occurring at a Customer’s site, the Customer Service ProblemReporting mechanism provides the means for a report to be sent to HNS Ltd on a form whichallows both the problem and solution to be tracked.

The following extracts from Company procedure PAP0046 show how the customer can ensurethat problems are dealt with efficiently and speedily to everyone’s satisfaction.

When a CSPR form has been completed, the customer should contact the Customer ServiceDesk at HNS Ltd. Telephone number : +44 1908 221122 extension 220. A unique CSPR numberwill be allocated, which the customer should add to the form before forwarding the original CSPRto the Customer Service Desk at HNS Ltd.

In order for a problem to be addressed as quickly as possible, the CSPR form can be faxed in thefirst instance to the Customer Service Desk at HNS Ltd. Forms should not be sent to other staff atHNS; only in this way can HNS Ltd meet agreed turnround times.

It is imperative that the Customer supplies as much detail as possible about the problem so thatHNS Ltd staff are in a position to recreate the error situation if necessary in order to provide acomprehensive and satisfactory solution.

If there is insufficient room in any section then Continuation sheets can be used and cross-reference made in the ATTACHMENTS field.

The following parts of the Customer Service Problem Report are to be completed by the customer.

Customer Reference : This is for the customer to use for internal reference purposes if required,and appears on both sides of the form and also on the continuation sheets.

CSPR Number : Unique number assigned to this problem, provided by the HNS Ltd. CustomerService Desk and added to the form by the customer.

Reported by : The name of the person reporting the problem.

Company : Name of the customer/company

Site details : Address, telephone and fax numbers for contacting the customer.

Date : Date on which the CSPR form is being completed.

System/Product : Domsat LES

Problem title : One line summary of the problem being reported

Problem : Enter the date and time the problem occurred.

Area/Effect/Occurrence/Frequency - mark the relevant boxes which best describe the symptomsof the problem and specify other information as appropriate.

Outage Time/Period of non-operation/Duration of Traffic Loss - enter the number of hours of sys-tem failure.

CSPR A4-OPG-003076Issue 3.23 - Accepted

17th July 2001

F-2

Environment : Provide the relevant details of system configuration including :

• Software : release/version number - identity of the software

• Application/subsystem - give information about the particular software application run-ning of the sub-system in use.

• Hardware : equipment type - describe the hardware

• Part number and serial number - identify any specific equipment

In the additional space provided also give any other details concerning the hardware sub-systemor sub-assembly involved.

Comments : provide any other relevant information that is pertinent to the problem. For example,give details of any abnormal conditions that the system is operating under, such as load testingbeing carried out.

Attachments : Record details of any other information provided (on tape or in hardcopy). If anycontinuation sheets are used then this should be noted and the number of pages recorded.

In case of software problems, the System Error Log may contain useful information to assist HNSin tracing the fault. Use the Operating System Console to log onto the BAP that was master whenthe fault occurred, as described in section 12.2, and copy the latest file by using the followingcommand :

CES nnnn> COPY BAP$ERROR:ERROR.LOG BAP$ERROR:ERROR.SAV

Note on the CSPR form that the file has been saved. HNS may request that the file is printed oraccessed by them when the CSPR is analysed. The system can store up to three versions of the.SAV file; please consult HNS if three files have been saved and none have been inspected.

The number of files in the system can be found be entering the command :

CES nnnn> DIR/DATE BAP$ERROR:ERROR.*

If material/parts are to be returned to HNS Ltd, then the Customer Service Desk also provides aReturn Material Authorisation number, which should be entered on the CSPR form and used toidentify the hardware concerned. Each separate module should have a separate CSPR form andRMA number - this is used internally by HNS to track the progress of the repair. The units shouldbe despatched in the boxes in which they were delivered to site. Note that in the case of theChannel Units and the MTMs, the flying leads on the front of the unit are part of the unit andshould be returned if there is a fault.

When the Customer Service Desk receives the completed CSPR form, it will pass it to the relevantpersonnel for attention.

When the problem has been resolved, the Customer Service Desk will provide copies of all therelevant documentation detailing the problem solution and send it to the customer along with theoriginal CSPR form.

The CSPR is considered closed either when the Customer returns the original form signed asaccepted or when four weeks have passed since solution and the customer has not made anycomments on the solution.

[opga6.mss]

A4-OPG-003076 GlossaryIssue 3.23 - Accepted17th July 2001

G-1

Appendix G

GLOSSARY

ACSE Access Control and Signalling Equipment, composed of the SCPs plus chan-nel unit equipment

Ada A high level language introduced by the US Department of Defense andwidely used on the ACSE

AFC Automatic Frequency Compensation

Alarm An event that is raised immediately to the SOC operator’s attention and whichhas associated audible and visible indication.

AORE Atlantic Ocean Region East

AORW Atlantic Ocean Region West

Arbiter A device that tells the BAPs on startup which BAP is Master and which isStandby. It also monitors each BAP for activity and if a BAP failure isdetected, it commands the Standby BAP to become Master

ARQ Automatic retransmission request

ASM Alarm and Switchover Module

BAP Background Applications Processor, the VAX that does the message storage,routing, and provides operator services

Billing Record A call record visible to and used by customers for billing

BIM Bus Interface Module

B/W Bothway

C-band Radio frequency in the range 4 - 6GHz. In this application used for trans-mission between the earth station and the satellite and vice versa. Note:Although the ACSE acts as if C-Band were used the RF equipment convertsto and from Ku-Band in this application CallA connection originated by a user to enter messages or status requests intothe LES or a connection originated by the LES to pass messages or status toa user

Call Record A data structure used for holding details of a call. It is allocated by a CallRecord Manager package. There is one ICR for each call entered into theLES and a DCR for each destination attempt

CCITT International Consultive Committee for Telegraphy and Telephony. A stan-dards group for communications

CES Coast Earth Station - obsolescent term replaced by LES

CNID Closed Network ID - obsolescent term replaced by DNID

Codex Name of modem used along with the MicroTurbo PAD for the asynchronousinterface.

Crosstalk Comms package that contains HNS preferred version of Kermit , for runningon PCs and Async Terminals

CU Channel Unit, the part of the LES configuration that provides the communica-tion path for a single satellite channel

CUC Channel Unit Controller, a component of the LES software that provides lowlevel call handling support for the satellite driver. Also the DEC VAX Front EndProcessors that drive the channel units

Glossary A4-OPG-003076Issue 3.23 - Accepted

17th July 2001

G-2

CURC Channel unit rack control line

Data Report A short message sent on the signalling channel of the LES. It is stored in aDNID file

DCE Data Circuit-terminating Equipment. CCITT terminology for a class of datadevices, of which the most common is the modem

DCL Digital Command Language - VAX VMS language used for writing commandprocedures

DCR Delivery Call Record

DEC Digital Equipment Corporation (Trademark). Supplier of the computers used inthe SCP

DEMSA A DEC Microserver that supports the DEC X.25 package, providing routingbetween DECnet and the X.25 PSDN

DMOD (or Demodulator) Channel Unit for receiving characters from Satellite

DNIC Data Network Identity Code. International code for identifying data networks

DNID Data Network Identification, an address of a file in the LES that stores datareports and messages (formerly CNID)

DTE Data Terminal Equipment. CCITT terminology for the data terminal devicesthemselves, a category which includes the computer. In Inmarsat-C terms, auser device that connects to the DCE part of an MES. A keyboard is one ex-ample of a DTE

E-Mail Electronic Mail

EGC Enhanced Group Call, a broadcast message to one or more mobiles

EGCID Enhanced Group Call Identification - obsolescent term replaced by ENID.

ELN The DEC operating system that is used in the DEC single board computersthat are used for Front End Processors

End User The customer for the service. See Terrestrial User

ENID Enhanced Network Identification. 16 bit number used in EGC addressing(formerly EGCID).

Event A message generated by the LES to the Log file to record an occurrence inthe system.

FEP Front End Processor. DEC Single board VAX implementing the CUC and TICfunctions or DEMSA for the X25 interface.

Follow on messageThe ability to accept more than one message in a single call setup. This isalso referred to as follow on call. Follow on messages are allowed from LESto mobile where the LES successfully transmits a message to a mobile andhas another message for the same mobile queued for delivery. Some ter-restrial interfaces have the capability of follow on messages

GMDSS Global Maritime Distress and Safety at Sea

IA5 International Alphabet Number 5. This is the default code for all Inmarsat-CMobiles

ICR Incoming Call Record

IF Intermediate frequency, in this application 70MHz

Inbound Message In the direction of Mobile to LES

IOR Indian Ocean Region


G-3

Inmarsat International Maritime Satellite Organisation - owners of various satellite sys-tems and regulators of the protocols for using those systems

Inmarsat-C The protocol as defined in 1. Also, the protocol used between the mobile andthe LES for the orderly transfer of data. Formerly referred to as "Standard-C".

ISC International switching Centre

ISL Interstation Signalling Link, used for communications between LES and NCS.Not used in this application.

ITA2 International Telegraph Alphabet Number 2, a 5 bit code used for Telex

Journal File A log which contains a history of events, call records, and statistics. It isprocessed by the offline database program. Also known as Log file

Kermit Software protocol used for file transfer

Ku-Band Radio frequency in the range 10 to 15 GHz. In this application used instead ofC-Band for the up and downlinks to the satellite.

L-band Radio frequency in the range 1 - 2 GHz. In this application used for com-munication between the mobile and the satellite and vice versa.

LCA Logical Channel Assignment

LCN Logical Channel Number that is allocated to a message transfer between theLES and a mobile

LCU Logical Channel Unit. This is used to define the satellite channel hardwareconfiguration independent of the physical equipment used to provide the ac-tual function. This allows LCUs to be permanently committed to a specificfunction, such as a TDM channel in a TDM group, even though the physicalequipment may be changed dynamically for redundancy switchover purposes

Leased Line A communications line that is dedicated to a particular end user. May be Telexor asynchronous

LES Land Earth Station. The equipment providing the gateway between mobilesand terrestrial networks, and comprising the ACSE plus Radio Frequencyequipment. (formerly CES)

LMAD Land Mobile Alert Destination

Master An active component in the system that carries traffic. See Standby

MEM Macro Encoded Message. A 7 bit code that has a specific meaning defined byan end user. Used to send messages with a preset meaning in a compactform as part of the polling protocol.

MES Mobile Earth Station. The L-Band terminal used to access the network usingthe Inmarsat-C protocol. (formerly SES)

MES ID Two 24 bit numbers that are used on the satellite channels to identify amobile. The forward ID is used in the outbound direction and the reverse ID isused in the inbound direction. These numbers are not presented to the exter-nal users. These numbers should not be confused with the 9 digit Mobile num-ber associated with the pair of IDs in the mobile list.

Message Channel An inbound channel for transferring messages between an MES and the LES.

Message Handler Message handler subsystem in the LES.

MicroPAD Type of PAD used in the LES for Asynchronous operation made by SFADatacomms Inc. (formerly Plantronics).

MID Maritime Identification Digits - part of the mobile’s address

MMI Man Machine Interface, the entire collection of input/output peripherals used


17th July 2001

G-4

by system operators to monitor and control the system

Mobile Another term for MES

Mobile Number The 9 digit mobile number that is used by terrestrial users and mobiles to ad-dress a mobile. This number should not be confused with the 24 bit MES IDsto which it is associated in the mobile list.

MOD (or Modulator) Channel Unit sending characters to Satellite

Motif is a trademark of the Open Software Foundation Inc., representing the win-dowing system used on certain SOCs, and which may be used on non DECterminals.

MRCC Maritime Rescue Coordination Centre. All maritime distress messages areautomatically routed to the MRCC address which must be configured

MRN Message Reference Number - generated by the ACSE to uniquely identifyeach message.

MTM Master Timing Module, part of the CU rack hardware which generates the12MHz reference for the CUs

NCP Network Control Program (DEC utility)

NCS Network Coordination Station, coordinates the MESs and LESs in a givenOcean Region (Not used in this application)

NDN Non Delivery Notification

NMCC Non-Maritime Distress Destination. Another term for LMAD

NUA Network User Address

Ocean Region One of: Atlantic (East), Atlantic (West), Pacific or Indian.

Offline ProcessingAll processing that does not have to be performed on the real-time (Master)traffic system. This includes generation of billing information and reports

OS/2 The multitasking operating system used on the LES Facsimile interface ser-vers. OS/2 is a trademark of International Business Machines.

Outbound Message in the direction of LES to Mobile

PAD Packet Assembler/Disassembler, used to connect non X.25 devices to X.25networks

PCU Physical Channel Unit. This is used to define the characteristics of the physi-cal channel unit equipment in the channel unit equipment hardware racks.PCUs can be assigned to LCUs automatically in CU redundancy activity ormanually by the operator for maintenance purposes

PDN Positive Delivery Notification

PIN Personal Identification Number (6 - 8 Alphanumeric characters)

PLL Phase-locked loop, used in frequency synthesis and demodulation

Poll A short message transmitted to one or more mobiles as a broadcast mes-sage. It is sent on the NCS TDM, or in stand-alone on the LES TDM. A Pollcan generate a response from the mobile in the form of a data report.

POR Pacific Ocean Region

PSDN Packet Switched Data Network

PSI A DEC layered product running on the DEMSAs under VMS that realises theX.25 interface from the PSDN network to the LES

PSTN Public Switched Telephone Network

PSTxN Public Switched Telex Network


G-5

PTT Public Telephone and Telegraph organisation

PVT Performance Verification Test, also known as Link Test

RCC Rescue Coordination Centre.

RF Radio Frequency, the frequency at which the signal is transmitted over the air.

RFT Radio Frequency Terminal, that part of the earth station which links the IF sig-nal at the ACSE interface with the satellite dish.

Route A collection of paths to the next switching point

S&F Store and Forward, a technique used in messaging where the whole messageis received and then passed on.

SAC Special Access Code, a short code that is expanded by the LES into a fullterrestrial address. SACs can also cause the LES to perform a specificpredefined function

SCP System Control Processor, the DEC VAX computers and associatedperipherals that controls the LES

SDAP Signal distribution and alarm panel. This is the top chassis in the ChannelUnit rack.

SDL Specification Design Language - a CCITT graphical language for defining sys-tems

SDM System Definition Manual see 1 for the version used.

SES Ship Earth Station. Obsolete term, replaced by MES

SIG Signalling Channel

Signalling ChannelA slotted aloha channel for sending signalling messages and data reports.Also known as an inbound channel

SOC System Operations Console. A DEC workstation that provides user screens ina multi window environment to configure, control, and monitor the ACSE.(Component in the LES Software)

SOCV SOC Viewer - access to the data in the BAP via the SOC.

SQL Structured Query Language. The high level language used by most commer-cial database packages

Standby A component in the system that is providing redundancy. It does not carrytraffic. Depending on the state of the standby equipment it may or may not beable to become Master

SVC Switched Virtual Circuit. An X.25 term for a logical communications channelover an X.25 network

SYBASE Relational database used for storing the data for the LES (Trademark)

TDM Time Division Multiplex - the channel is divided into frames and each frameinto slots. The same slot in successive frames is allocated to specific pur-poses. This mechanism is used in the channels from LES or NCS to a MES.

TDM Group Associated with a particular TDM output channel there are signalling and mes-sage channels. These channels are form a TDM group

Terrestrial User The LES customer using the ACSE services via the terrestrial network, iePublic Networks, Private Networks or Leased lines. In practice, this includesmobiles from other mobile data services.

TIC Terrestrial Interface Controller. A type of FEP in the ACSE, interfaces be-tween the SCP and the Telex lines of the terrestrial network.


17th July 2001

G-6

TNIC Terrestrial Network Identity Code. Used for identifying telex networks, asdescribed in CCITT Rec F69.

TSAP Terrestrial Service Access Point. A logical grouping of LES provided services

VAX Virtual Address Extension. The name for the DEC family of computers used toimplement the LES

VMS The DEC operating system used in the BAPs

VMS Console A terminal that controls the DEC VMS operating system. This is a physicalterminal plus a printer that is connected to each BAP, or it can be a window onthe SOC

VWS DEC windowing system, used in certain SOCs

X.25 CCITT standard for passing data packets over transmission links

X.29 CCITT standard for packet assemblers/disassemblers (PADs)

X.400 CCITT standard for messaging services

ZETAFAX Name of product used for sending Faxes from LES via FAX PC[glossary.mss]

A4-OPG-003076 GlossaryIssue 3.23 - Accepted OPERATOR GUIDE17th July 2001 Table of Contents

1

Index

ENID Report 8-50

Abort key 3-4

Access group definition 15-1

Account name and password changes 16-6

ACSE identity definition 10-28

ACSE identity in telex messages 6-2

Add key 3-1

Adding channel units 7-20

Addition of sparing pools 7-24

Address extension display 8-20

Address from mobiles 8-8

Address translation 8-14

Address validation 8-9

Administration of operators 15-1

Alarm acknowledgement 10-17

Alarm actions 10-23

Alarm and event definition 10-16

Alarm management 10-19

Alarm notification 10-17

Alarm printer 10-24

Alarm printer management 10-24

Alarm summary display 10-18

All call statistics report 14-20

All mobiles report - offline 14-17

All ships report 14-17

Analysis of message queues 8-32

Answerback on 2 stage telex 6-3

Answerbacks in single stage telex 6-2

Arbiter failure 10-7

Archive Database Configuration 10-15

Archive log files 14-4

ASM display 10-26

Asynchronous interface 6-20

Audible alarm silencing 10-17

Auto billing start time restrictions 16-20

Auto housekeeping 16-19

Auto housekeeping duration 16-20

Auto housekeeping journal entries 16-22

Autobilling 16-1

Autobilling alarms 16-26

Autobilling error recovery 16-29

Autobilling housekeeping 16-5

Autobilling Lock 16-5

Autobilling Procedures 16-27

Autobilling setup 16-4

Autobilling SOC access 16-8

Automatic billing 14-9

Automatic processing of offline records 14-9

Backups 12-7

Banner line 2-3

BAP Switchover 10-2

BAP management 10-1

BAP connections on SOC screen 2-3

BAP Failover 10-2

BAP failure 10-7

BAP manual switchover 10-1, 10-6

BAP process states 10-1

BAP startup progress 12-6

BAP switchover process 10-2

BAPOP 12-2

Billing Journals 16-21

Call completion code summary report 14-20

Call completion summary report - offline 14-14

Call analysis 8-37

Call completion code definition 8-20

Call completion code report 8-21

Call completion codes 8-20, E-1

Call completion summary report 14-14

Call failures on satellite side 11-67

Call in system - how to find 8-37

Call record full ICR display 8-46

Call record full DCR display 8-46

Call record list - offline 14-16

Call record list report 14-16

Call record reports - online 13-3, 8-48

Call record summary display 8-46

Call volume 8-47

Cancellation of messages 8-12

Carryover files 16-24

Change password 15-1

Change superuser password form 9-17

Channel unit chassis status summary 7-11

Channel activity monitoring 7-27

Channel unit spare pool status summary 7-19

Channel unit addition 7-20

Channel unit chassis statistics 7-11

Channel unit chassis definition 7-10

Channel unit chassis statistics 14-13

Channel unit controller failure 10-11

Channel unit controller management 10-8

Channel unit controller switchover 10-11

Channel unit module failure 7-14

Channel unit rack failures 7-9

Channel unit rack management 7-8

Channel unit rack statistics - offline 14-13

Channel unit rack statistics 7-9

Channel unit rack status summary 7-9

Channel unit spare pool definition 7-19

Channel unit startup sequence 7-26

Cold start 12-5

Combining tapes 14-10

Configuration changes - channel units 7-20

Configuration changes in TDM groups 7-20

Glossary A4-OPG-003076OPERATOR GUIDE Issue 3.23 - AcceptedTable of Contents 17th July 2001

2

Configuration of channel units 7-20

Configuring terrestrial interfaces 6-1

Country code definition 8-9

Create vt200 window 12-1

Create SOC session 5-1

Create SOC form 2-4

Create VT200 window 2-5

CSPR forms F-1

CU backplane failure 7-12

CU chassis address 7-10

CU event filtering 11-76

CU hardware reconfiguration 7-12

CUC port numbering 7-10

Data report file display 9-17

Data report file management 9-18

Database access 4-2

Database backup 14-4

Database change implementation 4-1

Database online 10-14

Database size 11-48

Database Transaction Log 11-48

Date format 3-3

DCL 12-2

Default processing 14-8

Default reports 14-8, 14-20

Deinstall BAP 12-2, 12-3

Delete key 3-1

Deletion of mobiles 9-7

Deletion of sparing pools 7-24

Delivery notifications 9-8

DEMSA management 10-13

DEMSA failure 10-11

DEMSA return to service 10-13

Disaster Recovery 12-13

Disk failure 10-14, 12-11

Disk Status 12-10

Distress alarm action 10-22

Distress call - action on receipt 10-22

Distress message contents 8-27

Distress message full display 8-27

Distress message report - online 13-3

Distress message summary display 8-27

Distress message summary report - offline 14-15

Distress routing 8-21

DNID download 9-15

DNID report 8-50

Download of ENIDs and DNIDs 9-15

Driver specific call completion code report 14-20

DTE address 6-8

EGC call report - offline 14-18

EGC distress message report 8-28

EGC request report 8-49

ENID download 9-15

ENID report 8-50

Enter key 3-1

Equipment switch settings A-1

Ethernet node connections 12-4

Event summary display 10-20

Event summary report - offline 14-15

Event and alarm definition 10-16

Event classes 10-17

Event definition 10-23

Event filtering on CU failures 11-76

Event full display 10-21

Event log report - offline 14-15

Event log report - online 13-4

Examples of routing table entries 8-16

Exit SOC viewer 4-3

F69 codes 6-4

Facsimile interface 6-13

Failure to handle messages 8-50

Failures of message channels 7-10

Faults - how to report to HNS F-1

FAX banner access 6-18

FAX banner configuration 6-18

FAX banner formats 6-19

FAX banners 6-14

Fax interface C-1

FAX PC Definition 6-15

FAX PC Display 6-15

FAX PC Management 6-16

FAX PC SOC forms 6-15

Fax reattempts C-3

FAX Route Definition 6-14

FAX Route Display 6-13

FAX Route Management 6-14

FAX Route SOC forms 6-13

FAX SOC statistics 6-16

FEP management 10-8

FEP failure 10-11

FEP management 8-51

FEP manual switchover 10-8, 10-11

FEP monitor connection and use 10-11

FEP process states 10-9

FEP startup 10-9

File names 14-3

Find a call in system 8-37

Find out about messages 8-27

First generation 7-7

First generation satellite 7-7

First page key 3-1

Flow control on TDM 7-17

Form menu 3-4

Form structure 3-1

Form use 3-4

Forms 3-1

Frame boundary 7-16

Frame timing reference generator 7-2, 7-15

Function key identification 2-3


3

Function keys in forms 3-1

Generate Log File Reports 8-50

Generate customer billing on disk 14-7

Help - VMS 12-2

Hex display on CUs 10-25

HNS access for fault investigation 10-29

Hold key 2-6

Housekeeping 16-14

Inactivity timers 7-27

Indicators 10-25

Info provider string 9-9

Initiate PVT 9-18

Inmarsat MES status report 9-3

Internal timers 7-28

Jump 3-2

Jump key 3-4

Keyboard 2-6

Land alert action 10-23

Land mobile alert destination definition 8-22

Land mobile alert destination display 8-22

Land mobile alerts 8-22

Land mobile distress destination 8-21

LCU 7-1

LCU addition and deletion 7-22

LEDs 10-25

LES call report - from mobiles 14-17

LES call report - to mobiles 14-17

LES definition 7-3

LES Management 7-3

LES Summary 7-2

LES to mobile message report 8-49

Life cycle of mobiles 9-1

Log file reports 8-50

Log-file list 14-11

Logical channel units 7-14

Logon - setting up operators 15-1

Main menu key 3-2

Manual billing 16-7

Manual switchover of processors 10-1

Manufacturers handbook 2-5

Maritime distress destination definition 8-21

Menu key 3-2

MES status report 9-3

MES analysis report 14-19

Message events 8-34

Message monitor 8-34

Message details full displays 8-30

Message cancellation 8-12, 8-47

Message delivery 8-11

Message details display 8-30, 8-37

Message details full data report display 8-31

Message details full delivery notification display 8-31

Message details full EGC display 8-31

Message details full Polls display 8-31

Message handler monitor 8-34

Message handling database 8-14

Message handling failure 8-50

Message queue analysis 8-32

Message queue summary display 8-29

Message records 8-45

Message routing 8-1

Message status display 8-37

Message status enquiry 8-28

Message status full display 8-29

Message status summary display 8-28

Message tracing 8-29

Message window 2-3

Messages - how to find out about 8-27

Messages to the LES operator 8-25

Microturbo 6-20

Minimize button 2-1, 2-5

Mobile status report 8-49

Mobile call summary report 14-15

Mobile definition 9-4

Mobile deletion 9-7

Mobile details available 9-1

Mobile distress message report 8-28

Mobile life cycle 9-1

Mobile list display 9-1

Mobile management 9-5

Mobile state change 9-4

Mobile to LES message report 8-49

Mobile to shore messages 8-6

Modify key 3-1

Motif 2-1, 3-4, 12-7

Mouse 2-4

Mouse Pointer 2-4

Move 3-2

MRCC 8-21

MSG logical channel unit definition 7-14

MTM display 10-26

Naming of files 14-3

NDN delivery address 8-25

NDN spill-out dest definition 8-27

NDNs 9-8

Network identity - PSDN 6-8

New Bbilling error recovery 16-29

New Billing 16-1

Next page key 3-1

Non-deliverable messages 8-25

Non-maritime distress destination 8-21

Notification of alarms 10-17

NUA 6-8


4

Ocean region address definition 8-20

Ocean region address report 8-20

Ocean regions on SOC screen 2-3

OFDB use with autobilling - precautions 16-1

Offline housekeeping 14-9

Offline processing menu 4-5

Offline processing 4-3, 14-1

Offline processing functions 14-2

Offline processing lifecycle 14-3

Offline report generation 14-11

Offline reports 14-11

One-touch billing 14-9

Online call record reports 8-48

Online event report 13-4

Online logfile reports 13-3

Online processing 4-3

Online reports 13-1, 13-4

Online statistics 13-1

Online statistics printouts 13-1

Operating system access 12-1

Operational procedures on satellite side 7-26

Operational recovery from disk failure 10-14

Operator - messages from mobiles to 8-25, 13-4

Operator administration 15-1

Operator as PSDN subscriber 10-28

Operator definition 15-1

Operator display 15-1

Operator log file 12-11

Operator logon 5-1

Operator menu 10-16

Operator message report 13-4

Operator Register 9-16

OS/2 6-13

Out of printer paper 10-24

Password - superuser 9-17

Password changes 16-6

Password update 9-17

PCU 7-1

PDNs 9-8

Performance Verification Tests 9-18

Pf keys 3-3

Physical channel unit definition 7-13

Physical channel unit management 7-13

Poll request report 8-49

Post EOT character limit table 6-7

PRC_CNTL_VALUES.INI 11-48

Presentation Code Validation 8-11

Preventative maintenance 10-15

Previous page key 3-2

Print online log file reports 13-3

Processor modes 10-1

Processor restart 12-4

Profile identity - PSDN 6-8

PSDN access by the operator 10-28

PSDN line failures 6-12

PSI security 10-16

PSTN 6-13, 6-20

Rack failures - channel unit 7-9

Randomizing interval 7-16

Randomizing interval for polls 7-4

Reattempt table - satellite 7-5

Reattempt table - telex 6-5

Reattempt table - X25 6-11

Recovery Procedures 8-50

Registered user data report definition 9-11

Registered user polling definition 9-11

Registered user definition 9-7

Registered user addition 9-7

Registered user display 9-12

Registered user DNID file space 9-18

Registered user EGC definition 9-10

Registered user full display 9-14

Registered user summary display 9-13

Regular system checks 10-15

Report generation 14-11

Report printer 10-25

Reporting faults to HNS F-1

Reports - online logfile 13-3

Reports available 14-11

Reports format 4-1

Restarting billing 16-20

Retest intervals on trunk telex lines 6-5

Retries for polls 7-4

Route numbers 8-18

Routine maintenance 10-15, 14-3

Routing of messages 8-1

Routing tables 8-14

Routing through the system 8-1

Routing to mobiles 8-20

SAC 33 message report 8-25, 13-4

Satellite interfaces 7-1

Satellite loop delay detection 7-10

Satellite loop timing 7-2

Satellite Parameter Definition 7-6

Satellite reattempt table 7-5

Satellite side call failure details 11-67

Satellite side operational procedures 7-26

Screen blanking 2-9

Second generation 7-7

Second generation satellite 7-7

Session Manager 2-4

Shore to mobile messages 8-2

Show BAP 12-3

Show key 3-2

SIG logical channel unit definition 7-14

Silencing the audible alarm 10-17

SOC form - create 2-4

SOC forms 3-1

SOC screen structure 2-1


5

SOC Start 2-5

SOC Viewer 2-5, 4-1

SOC viewer access 4-3

SOC Viewer database access 4-2

Software reload 10-14

Software security 10-13

Sopping a processor 12-6

Sparing pool addition and deletion 7-24

Sparing pools 7-2, 7-18

Special access code route definition 8-23

Special access code function definition 8-23

Special access code - setting up 8-24

Special access code address definition 8-24

Special access code display 8-23

Spill-out address 8-25

Spot Beam Definition 7-20

Spot beams 7-7, 7-20

Spot identity 7-16

Standalone backup 12-7

Start BAP 12-3

Startup 12-5

Startup progress of BAPs 12-6

Startup sequence - channel units 7-26

Statistics interval definition 13-2

Statistics intervals 13-2

Statistics printouts 13-1

Statistics Reports Management 13-1

Statistics Reports Print Management 13-1

Status Indications 10-25

Stop BAP 12-4

Stopping a system 12-6

Stopping MES traffic 7-17

Structure of this guide 1-1

Superuser password 9-17

Switch settings A-1

System checks 10-15

System disk space recovery 12-11

System error log F-2

System management 10-13

System manual 1-1

System messages 2-1

System PIN 9-8

System time 10-7

System usage display 2-3, 8-40

System usage statistics 8-45

Tape archiving 10-15

Tape combining 14-10

Tape drive failure 14-2

Tape drive usage when housekeeping 16-20

Tape drives 14-2

Tape header record 14-7

TDM groups 7-2

TDM group management 7-16

TDM bulletin board 7-4

TDM channels assigned 7-3

TDM group statistics 7-18

TDM group configuration changes 7-17, 7-20

TDM group definition 7-15

TDM group management 8-51

TDM Group statistics 14-14

TDM group summary 7-18

TDM groups 7-15

TDM logical channel unit definition 7-14

TDM loop timing generation 7-2

TDM reference enable 7-15, 7-2

TDM Rx logical channel definition 8-51

TDM Tx logical channel definition 8-51

Telex trunk retest 6-5

Telex call - EOT 6-7

Telex circuit numbering 6-3

Telex circuit definition 6-3

Telex FEP failure 10-11

Telex FEP management 10-8

Telex FEP manual switchover 10-11

Telex line failures 6-8

Telex reattempt table 6-5

Telex route statistics - offline 14-15

Telex timeouts 6-2

Telex trunk circuit management 6-4

Telex trunk circuit display 6-3

Telex trunk management 6-2

Telex trunk route definition 6-3

Terrestrial distress message report 8-28

Terrestrial interfaces 6-1

Terrestrial routing definition 8-19

Terrestrial routing display 8-19

Test mobile definition 10-28

Test telex circuit 6-2

Third generation 7-7

Throttle factor 7-17, 11-26

Time in system 10-7

Timeouts 7-28

Timers - internal 7-28

TNIC Display 8-25

TNIC definition 6-4, 8-25

TNIC display 6-4

Trace telex circuit 6-2

Trunk telex route display 6-2

User access 10-28

Validation of addresses from mobiles 8-9

Validation of presentation codes from mobiles 8-11

View online log file reports 13-3

Viewer 4-1

VMS access 12-1

VMS help 12-2

VMS Operator log file 12-11

VMS remote access 10-29

VMS security 10-16

VT200 window - create 2-5


6

Warm start 12-5

Windows - use of 2-4

X25 interactive PAD parameter definition 6-10

X25 reattempt table 6-11

X25 access 10-28

X25 channel definition 6-9

X25 channel display 6-9

X25 file transfer PAD definition 6-11

X25 general definition 6-10

X25 line definition 6-8

X25 line display 6-8

X25 line management 6-9, 10-13

X25 route display 6-8

X25 route definition 6-8

X25 statistics 6-11

Zetafax C-1

SOC_OPG_v3_23_1

Documents

registered user pin

left hand column

special access code

special access codes

confirm message cancellation

destination ocean region

registered terrestrial users

call completion code