You are on page 1of 413

HUGHES

NETWORK 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: Issue: Status:

17th July 2001 3.23 Accepted

Hughes Network Systems Limited Saxon Street Milton Keynes MK14 6LD United Kingdom

Telephone Facsimile

+44 1908 221122 +44 1908 221127

Copyright Hughes Network Systems Ltd 2001

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

System Operator Console

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 connection with the associated binding contract between HNS Limited and the recipient. This restriction does not apply to information in this document if it is obtainable from another source 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-003076 Issue 3.23 - Accepted 17th July 2001

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

System Operator Console

REVISION HISTORY
Issue Status 3.10a For Review Date Author Change References SCR568 - New Autobilling References to Inmarsat call record tapes removed for non-Inmarsat customers.

29-Jan-1998 M.J.Williams

3.10b For Review 3.11a For Review 3.11 Accepted

13-Feb-1998 M.J.Williams Review comments added. 5-Mar-1998 M.J.Williams Four OR text reinstated for Telstra.

18-Mar-1998 M.J.Williams 10-June-1998 M.J.Williams SPR 24228 - Stopping PADR SPR 25959 Autobilling file name in existing AMSC format Clarifications added to Autobilling chapter SPR 25961 new CCC - 845 - added SPR 25994 new MDIR event - 82 - added 2-Feb-1999 M.J.Williams Inm CN 126 and CP 127 Inmarsat Service Providers.

3.12a For Review

3.13a For Review 3.14a For Review

17-Mar-1999 M.J.Williams New billing, CSV o/p, and DNID Tracking added Minor changes and corrections. 19-Mar-1999 M.J.Williams SOCV diagrams and Chapter 16 do not yet fully reflect applied changes Will be updated as soon as possible. Chapters 4 (SOCV diagrams) and 16 (New Billing) have now been completed 30-Mar-1999 M.J.Williams 3.13a now accepted as 3.15 28-Apr-1999 M.J.Williams SPR20671 - Auto housekeeping for Telstra New SUD displays for AMSC 11-June-1999 M.J.Williams Accepted for Telstra 21-Sep-1999 M.J.Williams REL80110 - New billing Data banner suppression SPR26092, number of addresses in P/NDN 22-Sep-1999 M.J.Williams Accepted for Italy 06-Oct-1999 M.J.Williams REL80111\2 New billing for OTE Billing file name changes for Telstra 26-Oct-1999 M.J.Williams Accepted for Italy 05-April-2000 M.J.Williams REL80120\2

3.14

Accepted

3.15

Accepted

3.16a For Review

3.16

Accepted

3.17a For Review

3.17

Accepted

3.18a Draft

3.18

Accepted

3.19a For review

System Operator Console

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

E-mail and ordered delivery texts added 3.19 Accepted 14-April-2000 M.J.Williams Ordered delivery text reviewed 23-Aug-2000 M.J.Williams DNID polling alarm 17-Oct-2000 M.J.Williams FAX modem data re-inserted for Telstra only 27-Oct-2000 M.J.Williams (Customer name changed to Station 12). 18-Dec-2000 M.J.Williams SPR 26315 - Clarification on use of markers and << in banners (Appendix G) SPR 26322 New MCM event 123 No TDM at NCS 12-Feb-2001 M.J.Williams SPR 26313. Extend 26315 to cover FAX 13-Feb-2001 M.J.Williams Review comments added 27-Feb-2001 M.J.Williams SPR 26333 - Actions to manage VAXoperator log files (Chapter 12) Note referring to this added to PRC event 70 in Chapter 11 SUD/SOC descriptions extended for Mexico 7-Mar-2001 M.J.Williams SUD descriptions re-instated for Italy Signature sheet and early revision histories removed. 20-Mar-2001 M.J.Williams Description for XCCC event 33 corrected in chapter 11. Document now issued as Accepted. Signatures not required 21-Jun-2001 M.J.Williams SPR 26376, include descriptions for XCCC event 34-36 in chapter 11. Enable new SUDs for TDM 3.23 17-JUL-2001 M.J.Williams 09-Apr-2002 M.J.Williams SPR 26461, Six new PRC events in chapter 11. Customer names updated 24-Apr-2002 M.J.Williams 25-July-2002 M.J.Williams CN131/134/135 details added for customers taking these enhancements. Chapters affected:7, 8, 9 and 11 12-Aug-2002 M.J.Williams GAB review comments (1-4) incorporated Doc. now pending final comments from team. 10-Jan-2005 M.J.Franklin CN: 137. Covert Security Alerts

3.20a For review 3.20b For review 3.20 Accepted

3.21a For review

3.21b For review 3.21 Accepted

3.22a For review

3.22b For review 3.22 Accepted

3.23a For review Accepted 3.24a For review 3.24 Accepted

3.25a For review 3.25b For review 4.0 Accepted

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

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

System Operator Console

Reporting Issues with this Document


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

System Operator Console

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

Referenced and Related Documents Reference: 1. 2. 3. 4. 5. 6. Inmarsat-C SDM Identity: Issue: 2.0 System Manual Identity: A4-OMM-003076 Issue: 3.0

Channel Unit Operations and Maintenance Manual Identity: 8016264C Issue: 1.1 Billing Tape Formats Identity: A4-IFD-003076-7 Issue: 3.3

Customer Release Configuration Guide Identity: A4-SCG-003076-1 Issue: 3.6 Zetafax User Guide Identity: Issue: 3.0

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

System Operator Console

Table of Contents
REVISION HISTORY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Reporting Issues with this Document New Features 1. 2. . . . . . . . . . . . . . . . . . . . . . . . 1 1-1 2-1 2-1 2-1 2-3 2-4 2-4 2-6 2-6 2-8 2-9 3-1 3-1 3-1 3-1 3-3 3-4 3-4 3-5 4-1 4-1 4-1 4-2 4-3 4-3 4-5 4-5 5-1 6-1 6-1 6-1 6-2 6-8 6-8 6-10 6-12 6-13 6-13 6-15

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

INTRODUCTION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . PRINCIPLES OF THE SOC 2.1. 2.2. 2.3. 2.4. 2.5. 2.6. 2.7. 2.8. 2.9. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Structure . . . . . . . . . . . . . . . Screen . . . . . . . . . . . . . . . . Screen Areas . . . . . . . . . . . . . Operating System Messages . . . . . Use of Windows . . . . . . . . . . . . Keyboard . . . . . . . . . . . . . . . Implementation of Database Changes Processing Time . . . . . . . . . . . Screen Blanking . . . . . . . . . . .

3.

GUIDE TO THE SOC FORMS 3.1. 3.2. 3.3. 3.4. 3.5. 3.6. 3.7.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

General Structure of the Forms Types of Forms . . . . . . . . Function Keys . . . . . . . . . Fields on SOC Screen . . . . Help . . . . . . . . . . . . . . How to Use a Form . . . . . . Menu of Forms . . . . . . . .

4.

GUIDE TO THE SOC VIEWER . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.1. 4.2. 4.3. 4.4. 4.5. 4.6. 4.7. Introduction . . . . . . . . . . . Format of Reports . . . . . . . . Database Access . . . . . . . . Accessing the SOC Viewer . . . Menu Details : Online Processing Menu Details : Offline Processing Use of Control Characters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5. 6.

OPERATOR LOGON/OFF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . TERRESTRIAL INTERFACES . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.1. 6.2. 6.3. 6.4. 6.5. 6.6. 6.7. 6.8. Configuring the Terrestrial Interfaces . . . Structure of the Terrestrial Interface Forms Forms for Trunk Telex Circuits . . . . . . Telex Line Failures . . . . . . . . . . . . PSDN Line Configuration . . . . . . . . . General PSDN Parameters . . . . . . . . PSDN Line Failures . . . . . . . . . . . . PSTN Interface for Facsimile . . . . . . . 6.8.1. FAX Route SOC Forms . . . . . . 6.8.2. FAX PC SOC Forms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

System Operator Console

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

6.9. 7.

6.8.3. FAX Statistics SOC Forms . . . . 6.8.4. FAX Banner Configuration . . . . 6.8.5. FAX Banner Access . . . . . . . 6.8.6. FAX Banner Formats . . . . . . . PSTN Interface for Asynchronous Access

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

6-16 6-18 6-18 6-19 6-20 7-1 7-1 7-2 7-7 7-8 7-8 7-9 7-10 7-10 7-12 7-13 7-14 7-14 7-15 7-18 7-20 7-20 7-20 7-20 7-22 7-24 7-26 7-26 7-27 7-27 7-27 7-28 8-1 8-1 8-2 8-2 8-6 8-9 8-9 8-11 8-11 8-12 8-14 8-14 8-14 8-16 8-18 8-20 8-20 8-21

SATELLITE INTERFACE 7.1. 7.2. 7.3. 7.4.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . LES Forms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Satellite Generation Change . . . . . . . . . . . . . . . . . . . . . . . . . Physical Channel Units . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.4.1. Channel Unit Rack Forms . . . . . . . . . . . . . . . . . . . . . . 7.4.2. Channel Unit Rack Failures . . . . . . . . . . . . . . . . . . . . . . 7.4.3. Satellite Loop Delay Detection . . . . . . . . . . . . . . . . . . . . 7.4.4. Channel Unit Chassis . . . . . . . . . . . . . . . . . . . . . . . . . 7.4.5. Channel Unit Backplane Failure . . . . . . . . . . . . . . . . . . . 7.4.6. Physical Channel Unit Forms . . . . . . . . . . . . . . . . . . . . . 7.4.7. Channel Unit Module Failures . . . . . . . . . . . . . . . . . . . . 7.5. Logical Channel Units . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.6. TDM Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.7. Spare Pools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.8. Spot Beams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.9. Changing the Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . 7.9.1. Changing the Configuration of TDM Groups . . . . . . . . . . . . . 7.9.2. Adding Channel Units to the System . . . . . . . . . . . . . . . . . 7.9.3. Logical Channel Unit Addition and Deletion . . . . . . . . . . . . . 7.9.4. Procedure for Defining and Deleting Sparing Pools and TDM Groups 7.10. Satellite Side Operational Procedures . . . . . . . . . . . . . . . . . . . . 7.10.1. Channel Unit Startup Sequence . . . . . . . . . . . . . . . . . . . 7.10.2. Network Failures . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.10.3. RF Equipment Failure . . . . . . . . . . . . . . . . . . . . . . . . . 7.10.4. Channel Activity Monitoring . . . . . . . . . . . . . . . . . . . . . . 7.10.5. Internal Timers . . . . . . . . . . . . . . . . . . . . . . . . . . . .

8.

MESSAGE HANDLING . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.1. 8.2. Introduction . . . . . . . . . . . . . . . . . . . How Messages Pass Through the System . . . 8.2.1. Shore to Mobile Messages . . . . . . . 8.2.2. Mobile to Shore Messages . . . . . . . 8.2.3. Messages between Inmarsat-C Mobiles 8.2.4. Address Validation . . . . . . . . . . . 8.2.5. Presentation Code Validation . . . . . . 8.2.6. Message Delivery . . . . . . . . . . . . 8.2.7. Message Cancellation . . . . . . . . . 8.2.8. Delivery of Messages by Facsimile . . . Setting Up the Message Handling Database . . 8.3.1. Routing Tables . . . . . . . . . . . . . 8.3.2. Examples of Routing Table Entries . . . 8.3.3. Routing for Mobile Originated Messages 8.3.4. Routing for Messages to Mobiles . . . . 8.3.5. Call Completion Codes . . . . . . . . . 8.3.6. Alert Routing Strategy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

8.3.

ii

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

System Operator Console

8.4.

8.5.

8.6.

8.7.

8.3.6.1. Maritime Distress Routing . . . . . . 8.3.7. Land Mobile Alerts . . . . . . . . . . . . . . . 8.3.8. Special Access Codes . . . . . . . . . . . . . 8.3.9. Information for Setting Up Special Access Codes 8.3.10. Messages to the LES . . . . . . . . . . . . . . 8.3.11. Delivery Notifications . . . . . . . . . . . . . . How to Find Out About Messages . . . . . . . . . . . 8.4.1. Distress Message Contents . . . . . . . . . . . 8.4.2. Message Status Enquiry . . . . . . . . . . . . 8.4.3. Message Queues . . . . . . . . . . . . . . . . 8.4.4. Message Details . . . . . . . . . . . . . . . . 8.4.5. Message Queue Analysis . . . . . . . . . . . . 8.4.6. Call Analysis . . . . . . . . . . . . . . . . . . System Usage . . . . . . . . . . . . . . . . . . . . . 8.5.1. Text Information SUD . . . . . . . . . . . . . . 8.5.2. Bar Graph SUD . . . . . . . . . . . . . . . . . 8.5.3. Call Completion SUD . . . . . . . . . . . . . . 8.5.4. User Interface Response SUD . . . . . . . . . 8.5.5. Queue Counts by Individual Routes . . . . . . 8.5.6. Delivery Rate by Route SUD . . . . . . . . . . 8.5.7. TDM_Summary Display SUD . . . . . . . . . . 8.5.8. Call Count SUD . . . . . . . . . . . . . . . . . 8.5.9. Forced Clear Counts SUD . . . . . . . . . . . 8.5.10. Statistics . . . . . . . . . . . . . . . . . . . . Message Records . . . . . . . . . . . . . . . . . . . . 8.6.1. Online Call Records on SOC Forms . . . . . . 8.6.2. Online Call Record Reports . . . . . . . . . . . 8.6.3. Report Presentation . . . . . . . . . . . . . . . 8.6.4. Message Status Reports . . . . . . . . . . . . 8.6.5. DNID Report . . . . . . . . . . . . . . . . . . 8.6.6. ENID Report . . . . . . . . . . . . . . . . . . 8.6.7. Log File Reports . . . . . . . . . . . . . . . . Recovery from Failures in Message Handling . . . . . 8.7.1. Satellite Call Failures . . . . . . . . . . . . . . 8.7.2. Terrestrial X.25 Calls Failing . . . . . . . . . . 8.7.3. All outgoing telex calls failing . . . . . . . . . . 8.7.4. All incoming telex calls failing . . . . . . . . . . 8.7.5. Telex line stuck in retest or bothway busy . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

8-21 8-22 8-23 8-24 8-25 8-25 8-27 8-27 8-28 8-29 8-30 8-32 8-37 8-40 8-40 8-41 8-42 8-43 8-43 8-43 8-44 8-44 8-45 8-45 8-45 8-46 8-48 8-48 8-49 8-50 8-50 8-50 8-50 8-51 8-53 8-53 8-55 8-55 9-1 9-1 9-1 9-1 9-4 9-5 9-5 9-6 9-6 9-7 9-7 9-7 9-10

9.

USER SERVICES 9.1.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

9.2.

Mobiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9.1.1. Mobile Life Cycle . . . . . . . . . . . . . . . . . . . . . . 9.1.2. Information Available . . . . . . . . . . . . . . . . . . . . 9.1.3. Defining a Mobile . . . . . . . . . . . . . . . . . . . . . . 9.1.4. Barring of Mobiles . . . . . . . . . . . . . . . . . . . . . . 9.1.4.1. Barring all the Mobiles . . . . . . . . . . . . . . 9.1.4.2. Unbarring Site Mobiles . . . . . . . . . . . . . . 9.1.4.3. Automating the Barring and Unbarring of Mobiles 9.1.5. Maintaining the Mobile List . . . . . . . . . . . . . . . . . Management of Registered Users and ISPs . . . . . . . . . . . . 9.2.1. Management of General Services for Registered Users . . 9.2.2. Management of EGC Services for Registered Users . . . .

iii

System Operator Console

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

9.3. 9.4. 9.5. 9.6. 9.7. 9.8. 10.

9.2.3. Management of Polling Services for Registered Users . . . . . 9.2.4. Management of Data Reporting Services for Registered Users 9.2.5. Management of Mobile Services for Registered Users . . . . . Displaying Information Regarding Registered Users . . . . . . . . . . Download of ENIDs and DNIDs to Mobiles . . . . . . . . . . . . . . . Password Update . . . . . . . . . . . . . . . . . . . . . . . . . . . . Superuser Password for the Operator . . . . . . . . . . . . . . . . . Data Reporting File Management . . . . . . . . . . . . . . . . . . . . Performance Verification Tests . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

9-11 9-11 9-12 9-12 9-15 9-17 9-17 9-17 9-18 10-1 10-1 10-1 10-2 10-6 10-7 10-7 10-7 10-8 10-8 10-11 10-11 10-12 10-13 10-13 10-13 10-14 10-14 10-15 10-16 10-16 10-16 10-17 10-17 10-18 10-20 10-22 10-23 10-23 10-23 10-24 10-25 10-25 10-27 10-28 10-28 10-28 10-29

SYSTEM CONTROL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.1. Background Applications Processors . . . . . . . . . . . . . 10.1.1. BAP Management . . . . . . . . . . . . . . . . . . 10.1.2. BAP Switchover Process . . . . . . . . . . . . . . . 10.1.3. Manually Controlled BAP Switchover . . . . . . . . . 10.1.4. BAP Failure . . . . . . . . . . . . . . . . . . . . . . 10.1.5. System Time . . . . . . . . . . . . . . . . . . . . . 10.1.5.1. Setting the Time on the VAX Clock . . . . 10.2. Front End Processors . . . . . . . . . . . . . . . . . . . . . 10.2.1. Telex and CU FEP Management . . . . . . . . . . . 10.2.2. Telex and CU FEP Manually Controlled Switchover . 10.2.3. Telex, CU FEP and DEMSA Failure . . . . . . . . . 10.2.4. Recommended Dip Switch Settings for On-site FEPs 10.2.5. DEMSA Management . . . . . . . . . . . . . . . . . 10.3. System Management . . . . . . . . . . . . . . . . . . . . . 10.3.1. Security of Software . . . . . . . . . . . . . . . . . 10.3.2. Operational Recovery from Disk Failure . . . . . . . 10.3.3. Security of Online Configuration Data . . . . . . . . 10.3.4. Online System Checks . . . . . . . . . . . . . . . . 10.3.5. VMS security . . . . . . . . . . . . . . . . . . . . . 10.4. Alarms and Events . . . . . . . . . . . . . . . . . . . . . . 10.4.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 10.4.2. Notification of Alarms . . . . . . . . . . . . . . . . . 10.4.3. Summary Display on the SOC . . . . . . . . . . . . 10.4.4. Alarm Summary Display . . . . . . . . . . . . . . . 10.4.5. Event Displays . . . . . . . . . . . . . . . . . . . . 10.4.6. Action on Receipt of Distress Alarms . . . . . . . . . 10.4.7. Action on Receipt of Land Alert Events . . . . . . . . 10.4.8. Action on Occurrence of other Alarms . . . . . . . . 10.4.9. Event Management . . . . . . . . . . . . . . . . . . 10.4.10. Alarm (or Event) Printer . . . . . . . . . . . . . . . . 10.5. Report Printer . . . . . . . . . . . . . . . . . . . . . . . . . 10.6. Other Status Indications in the System . . . . . . . . . . . . 10.7. Reporting Faults . . . . . . . . . . . . . . . . . . . . . . . 10.8. Test Message Functions . . . . . . . . . . . . . . . . . . . 10.9. ACSE Identifier . . . . . . . . . . . . . . . . . . . . . . . . 10.10. The Operator as a PSDN subscriber . . . . . . . . . . . . . 10.11. Access by HNS for Fault Investigation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

iv

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

System Operator Console

11.

EVENT MESSAGES 11.1. 11.2. 11.3. 11.4.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

11-1

Introduction . . . . . . . . . . . . . . . . Event Details . . . . . . . . . . . . . . . Call Failures on the Satellite Side . . . . . Channel Unit Failure Event Filtering . . .

. 11-1 . 11-4 . 11-67 . 11-76 12-1 12-1 12-1 12-2 12-4 12-4 12-5 12-5 12-5 12-6 12-6 12-6 12-6 12-7 12-9

12.

OPERATING SYSTEM ACCESS 12.1. 12.2. 12.3. 12.4. 12.5. 12.6.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Access Mechanism . . . . . . . . . . . . . . . . . . . . . . . . BAP Operations Facility . . . . . . . . . . . . . . . . . . . . . . When to Restart the System . . . . . . . . . . . . . . . . . . . Hardware Initialization . . . . . . . . . . . . . . . . . . . . . . Types of Software Startup . . . . . . . . . . . . . . . . . . . . 12.6.1. Warm Start . . . . . . . . . . . . . . . . . . . . . . . . 12.6.2. Cold Start . . . . . . . . . . . . . . . . . . . . . . . . . 12.6.3. Monitoring the Progress of Startup . . . . . . . . . . . . 12.7. Stopping a Processor . . . . . . . . . . . . . . . . . . . . . . . 12.8. Stopping a System . . . . . . . . . . . . . . . . . . . . . . . . 12.9. Starting the SOC Terminal . . . . . . . . . . . . . . . . . . . . 12.10. Performing a Standalone Backup of a System Disk (BAP or SOC) 12.11. Backing up a System Disk Whilst the LES is Still Live . . . . . . 12.12. Disk Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12.12.1. Monitoring Disk Status . . . . . . . . . . . . . . . . . . 12.12.2. Disk Failure . . . . . . . . . . . . . . . . . . . . . . . . 12.12.3. Disk Space Exhaustion . . . . . . . . . . . . . . . . . . 12.12.4. System Disk Space Exhaustion . . . . . . . . . . . . . . 12.12.5. Operator log files . . . . . . . . . . . . . . . . . . . . . 12.12.5.1. Procedure to manage operator log files . . . . 12.13. Disaster Recovery . . . . . . . . . . . . . . . . . . . . . . . . ONLINE REPORTS AND STATISTICS 13.1. Online Statistics Printouts . 13.2. Online Logfile Reports . . 13.2.1. Call Records . . . 13.2.2. Distress Messages 13.2.3. Event Messages . 13.2.4. Operator message 13.3. Online Database Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . 12-10 . . . . . . . . 12-10 . . . . . . . . 12-11 . . . . . . . . 12-11 . . . . . . . . 12-11 . . . . . . . . 12-11 . . . . . . . . 12-12 . . . . . . . . 12-13 . . . . . . . . 13-1 13-1 13-3 13-3 13-3 13-4 13-4 13-4 14-1 14-1

13.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

14.

OFFLINE PROCESSING . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14.1. Functions Performed Offline . . . . . . . . . . . . . . . . . . . . . . . . . . .

System Operator Console

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

14.2. 14.3. 14.4. 14.5. 14.6.

Access to the Offline Functions . . . . . . . . . . . Tapes . . . . . . . . . . . . . . . . . . . . . . . . Disks . . . . . . . . . . . . . . . . . . . . . . . . File Naming . . . . . . . . . . . . . . . . . . . . . Routine Procedures for Processing Offline Records 14.6.1. Automatic Processing of Offline Records . . 14.7. Off-line Database Housekeeping . . . . . . . . . . 14.8. Abnormal Processing of Records . . . . . . . . . . 14.9. Tape Combining . . . . . . . . . . . . . . . . . . 14.10. Log-File List Generation . . . . . . . . . . . . . . 14.11. Offline Report Generation . . . . . . . . . . . . . . 14.11.1. Statistics . . . . . . . . . . . . . . . . . . 14.11.2. Events . . . . . . . . . . . . . . . . . . . . 14.11.3. Distress . . . . . . . . . . . . . . . . . . . 14.11.4. Call Records . . . . . . . . . . . . . . . . 14.11.5. Default Reports . . . . . . . . . . . . . . . OPERATOR CONTROL

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. 14-2 . 14-2 . 14-3 . 14-3 . 14-3 . 14-9 . 14-9 . 14-9 . 14-10 14-11 . 14-11 . 14-13 . 14-15 . 14-15 . 14-16 . 14-20 . 15-1 15-1 15-1 16-1 16-1 16-1 16-2 16-3 16-4 16-4 16-5 16-5 16-6 16-7 16-7 16-8 16-8 16-8 16-8 16-10 16-10 16-11 16-13 16-13 16-14 16-16 16-16

15.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

15.1. Administration of Operators . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15.2. Changing Passwords . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16. GUIDE TO AUTOBILLING . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16.1. INTRODUCTION . . . . . . . . . . . . . . . . . . . . . 16.1.1. Use of OFDB - precautions . . . . . . . . . . . . 16.2. FASTER BILLING . . . . . . . . . . . . . . . . . . . . . 16.3. AUTOBILLING . . . . . . . . . . . . . . . . . . . . . . 16.3.1. Billing process . . . . . . . . . . . . . . . . . . 16.3.2. Billing setup procedure . . . . . . . . . . . . . . 16.3.3. Billing housekeeping procedure . . . . . . . . . 16.3.3.1. Lock/Unlock billing . . . . . . . . . . . 16.3.4. Account name and password changes . . . . . . 16.4. Manual Operations . . . . . . . . . . . . . . . . . . . . 16.4.1. Manual billing . . . . . . . . . . . . . . . . . . . 16.5. SOCV ACCESS AND BILLING SET UP . . . . . . . . . 16.5.1. Autobilling Main menu . . . . . . . . . . . . . . 16.5.2. Configuration . . . . . . . . . . . . . . . . . . . 16.5.2.1. Autobilling Configuration . . . . . . . . 16.5.2.2. CSV File Operation Configuration . . . 16.5.3. Start Auto billing . . . . . . . . . . . . . . . . . 16.5.3.1. Start times . . . . . . . . . . . . . . . 16.5.4. Performing the Manual Operations . . . . . . . . 16.5.4.1. Manual Billing . . . . . . . . . . . . . 16.5.5. Housekeeping . . . . . . . . . . . . . . . . . . . 16.5.5.1. Housekeeping with no OFDB processing 16.5.5.2. Housekeeping with OFDB processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

vi

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

System Operator Console

16.6.

16.7. 16.8.

16.9.

16.5.6. Auto Housekeeping . . . . . . . . . . . . . . . . . . . . . 16.5.6.1. Tape drive precautions during auto housekeeping 16.5.6.2. Billing start time restrictions . . . . . . . . . . . 16.5.6.3. Restarting billing . . . . . . . . . . . . . . . . . FILES UTILISED BY ADVANCED BILLING . . . . . . . . . . . . 16.6.1. User Journal file . . . . . . . . . . . . . . . . . . . . . . 16.6.1.1. Auto Billing User Journal updates . . . . . . . . 16.6.1.2. Auto housekeeping journal entries . . . . . . . . 16.6.1.3. Manual billing user journal updates . . . . . . . 16.6.2. System Journal file . . . . . . . . . . . . . . . . . . . . . 16.6.3. Carryover files . . . . . . . . . . . . . . . . . . . . . . . 16.6.3.1. Auto Billing Carry Over files . . . . . . . . . . . 16.6.3.2. Manual Billing Carry Over files . . . . . . . . . . ALARMS AND EVENTS . . . . . . . . . . . . . . . . . . . . . . OPERATOR PROCEDURES . . . . . . . . . . . . . . . . . . . . 16.8.1. Starting billing for first time . . . . . . . . . . . . . . . . . 16.8.2. Changing configuration parameters . . . . . . . . . . . . 16.8.3. Changing copy or partner node passwords . . . . . . . . 16.8.3.1. Auto Billing . . . . . . . . . . . . . . . . . . . . 16.8.4. Changing Start Time . . . . . . . . . . . . . . . . . . . . 16.8.5. System backups . . . . . . . . . . . . . . . . . . . . . . ERROR RECOVERY . . . . . . . . . . . . . . . . . . . . . . . . 16.9.1. General . . . . . . . . . . . . . . . . . . . . . . . . . . . 16.9.2. Billing has (been) halted . . . . . . . . . . . . . . . . . . 16.9.3. Autobilling continues, use of manual billing . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . .

16-19 16-20 16-20 16-20 16-21 16-21 16-21 16-22 16-23 16-24 16-24 16-24 16-25 16-26 16-27 16-27 16-27 16-27 16-27 16-28 16-28 16-29 16-29 16-29 16-30 A-1 A-1 A-2 A-3 B-1 C-1 C-1 C-1 C-2 C-2 C-2 C-2 C-3 C-3 D-1 E-1 F-1 G-1 1

A.

EQUIPMENT SWITCH SETTINGS . . . . . . . . . . . . . . . . . . . . . . . . . . A.1. A.2. A.3. DEC Equipment Switches . . . . . . . . . . . . . . . . . . . . . . . . . . . . Channel Unit Equipment Switches . . . . . . . . . . . . . . . . . . . . . . . . Other Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

B. C.

REGISTERED USER DETAILS

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

D. E. F. G.

GUIDE TO SETTING UP ASYNCHRONOUS COMMUNICATIONS . . . . . . . . . CALL COMPLETION CODES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

CUSTOMER SERVICE PROBLEM REPORT GLOSSARY Index

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

vii

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

System Operator Console

List of Figures
2-1 2-2 3-1 3-2 4-1 4-2 4-3 4-4 4-5 4-6 4-7 4-8 4-9 4-10 8-1 8-2 8-3 8-4 8-5 8-6 8-7 8-8 8-9 8-10 8-11 8-12 8-13 8-14 9-1 9-2 9-3 9-4 10-1 10-2 11-1 14-1 16-1 16-2 SOC Screen Structure . . . . . . . . . . . . . . . . . . . . . . . . . . SOC Keyboard - LA401 . . . . . . . . . . . . . . . . . . . . . . . . . SOC Forms Menu Tree 1/2 . . . . . . . . . . . . . . . . . . . . . . . SOC Forms Menu Tree 2/2 . . . . . . . . . . . . . . . . . . . . . . . SOC Viewer Main Menu . . . . . . . . . . . . . . . . . . . . . . . . . SOC Viewer On-Line Processing Menu Tree 1/5 . . . . . . . . . . . . SOC Viewer On-Line Processing Menu Tree 2/5 . . . . . . . . . . . . SOC Viewer On-Line Processing Menu Tree 3/5 . . . . . . . . . . . . SOC Viewer On-Line Processing Menu Tree 4/5 . . . . . . . . . . . . SOC Viewer On-Line Processing Menu Tree 5/5 . . . . . . . . . . . . SOC Viewer Off-Line Processing Menu Tree 1/3 . . . . . . . . . . . . SOC Viewer Off-Line Processing Menu Tree 2/3 . . . . . . . . . . . . SOC Viewer Off-Line Processing Menu Tree 3/3 . . . . . . . . . . . . SOC Viewer Autobilling Menu Tree . . . . . . . . . . . . . . . . . . . Telex Access Mechanisms . . . . . . . . . . . . . . . . . . . . . . . . TSAP3 : Telex Registered User Access . . . . . . . . . . . . . . . . . TSAP4 : Telex Unregistered Message Status Enquiry . . . . . . . . . . Mobile to Shore Message Flow . . . . . . . . . . . . . . . . . . . . . Message Delivery cycle . . . . . . . . . . . . . . . . . . . . . . . . . Delivery Notifications to Registered Terrestrial Users . . . . . . . . . . Ordinary Message Lifecycle . . . . . . . . . . . . . . . . . . . . . . . EGC Message Lifecycle . . . . . . . . . . . . . . . . . . . . . . . . . Call Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Recovery Procedure when Satellite Calls Are Failing . . . . . . . . . . Recovery Procedure when X.25 Calls Are Failing . . . . . . . . . . . . Recovery Procedures for Failure of Outgoing Telex Calls . . . . . . . . Recovery Procedures for Failure of Incoming Telex Calls . . . . . . . . Recovery Procedure when Telex Lines Stuck in Retest or Bothway Busy Mobile State Life Cycle . . . . . . . . . . . . . . . . . . . . . . . . . . Mobile List Display Selection . . . . . . . . . . . . . . . . . . . . . . . Registered User Summary Display Selection . . . . . . . . . . . . . . Registered User Full Display Selection . . . . . . . . . . . . . . . . . BAP Process State Control . . . . . . . . . . . . . . . . . . . . . . . FEP Process State Control . . . . . . . . . . . . . . . . . . . . . . . . Sample Event Printer Output . . . . . . . . . . . . . . . . . . . . . . . Offline Database Life Cycle . . . . . . . . . . . . . . . . . . . . . . . Housekeeping where OFDB processing is not required . . . . . . . . . Housekeeping where OFDB processing is required . . . . . . . . . . . . 2-2 . 2-7 . 3-6 . 3-7 . 4-4 . 4-6 . 4-7 . 4-8 . 4-9 . 4-10 . 4-11 . 4-12 . 4-13 . 4-14 . 8-3 . 8-4 . 8-5 . 8-7 . 8-13 . 8-26 . 8-35 . 8-36 . 8-38 . 8-52 . 8-54 . 8-56 . 8-57 . 8-58 . 9-2 . 9-3 . 9-14 . 9-15 . 10-3 . 10-10 . 11-2 . 14-5 . 16-17 . 16-18

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

System Operator Console

List of Tables
8-1 9-1 9-2 10-1 10-2 14-1 Destination Networks and Address Extensions . . . . . . . . Settings used to select NDN and PDN functions . . . . . . . . Example extract from the Operator Register . . . . . . . . . . Master BAP - response to BAPOP SHOW STATE command . Standby BAP - response to BAPOP SHOW STATE command Default Report Names, File Names and References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-8 . 9-10 . 9-16 . 10-4 . 10-5 . 14-21

System Operator Console

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

ii

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

System Operator Console

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-003076 Issue 3.23 - Accepted 17th July 2001

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

Introduction

Chapter 1 INTRODUCTION
This manual describes how the operator can use the System Operator Console (SOC) to control the 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 control of the system and has distinguished the functions performed on the SOC from those on the Operating 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 is used. Chapter 3 describes the uses and structure of the SOC forms and gives the complete menu of forms. 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 be monitored and controlled. Chapter 7 describes the ACSE satellite interface, showing how this interface can be monitored and controlled. Chapter 8 describes message handling - how the routing through the system is configured and how address translations are set up. It also describes the reports available and shows how problems 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 be taken when an event is reported. Chapter 12 shows how to access the operating system.
1-1

Introduction

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

Chapter 13 describes the online statistics available. Chapter 14 describes offline processing, and shows how offline reports are prepared, how backups 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 form access by the operators. Chapter 16 describes the autobilling process which, though accessed via offline processing, does not require access to the offline database. Appendix A shows the standard switch settings for the equipment. This should be used to ensure that any replacement equipment is correctly configured. Appendix B shows the details relating to registered users which must be available before such users 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, but only for the first 10 characters of each word. This guide assumes familiarity with the ACSE equipment and a general understanding of the use of DEC processors. The SOC software must be loaded before it can be used. In normal operation, the equipment should be left operational so that it is available whenever needed.
[opg1.mss]

1-2

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

SOC Screen

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 and keyboard, running the Motif windowing system.The displays combine a fixed status summary with a selection of text displays used to show detailed status and to guide the operator to input parameters on the keyboard. A mouse pointing device is also provided. This is used to initially select the desired display. It may also be used within certain regions of the screen for selection options. Where the mouse has a function it causes a box to appear round the object pointed at e.g. the message window in the Banner 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 (or several windows) can be called up. The fixed structure is divided into three separate areas as follows : banner to show the time and date, summary alarm status, BAP connection details and the latest alarm. display area function key display Windows can be created on the screen for interactive operations. Various displays are available and are called up using mouse and/or function keys. Data can be input using the keyboard. Only some of the displays are needed in the day to day operation of the equipment; others are used to set parameters which only need to be changed either infrequently or on initial configuration of the equipment. 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 make infrequent changes. This also acts as the access to the Offline processing functions such as reporting and billing tape preparation. In effect, the SOC Viewer gives direct access to the BAP. This method of access can also be used from a standard DEC VT 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 of the 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 it causes the existing messages to scroll up the screen, and removes the sixth oldest message. It is not possible to delete this window, but it can be shrunk to an icon by positioning the mouse on the
2-1

SOC Screen

Undelivered Distress Distress


BAP FEP ARB TLX X25 CU SOC ISL NET X400 Other

LES Identity

LOGO

Urgent Semi Urgent Ocean Regions BAP Connections

Figure 2-1. SOC Screen Structure

Minor Message Line

Use this area to open windows:

SYSTEM USAGE DISPLAY

2-2

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

Function Keys

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

SOC Screen

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 administrations logo is displayed and time and date shown. Note: the time and date may be entered by the operator as part of the system start-up sequence following booting up the SOC, but if it differs by more than a few seconds from the time in the Master 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 is an indication of : the ACSE identity the ocean regions served - IOR. BAP connections - whether or not the BAP is in communication with the SOC - and BAP states - master, standby, idle or unknown. The message window which displays in plain text the latest alarm, as soon as it occurs. If several alarms occur in quick succession, details can be found in a SOC form. When the mouse points to this area, it is highlighted. If the left button on the mouse is pressed, the current message disappears and is replaced by the previous message. If there are no more messages to be displayed, the message No Broadcast 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 connection messages superimposed. A refresh of this area can be forced by repositioning it centrally at top of screen at correct size by moving the window off left hand edge of screen, iconising it and deiconise it again. The window should 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 more windows for this purpose. Section 2.5 describes the use of windows. A default display in this area is provided by the System Usage Display which shows occupancy and capacity details of the equipment and is updated every 30 seconds, as described in section 8.5. This display is permanently 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 the keyboard. 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, the operator 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.

2-3

SOC Screen

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

2.4 Operating System Messages One of the facilities of the SOC workstation is the ability to display messages initiated by the operating system e.g. DECNET failures. This will result in the top half of the screen being blanked with SOC windows being forced down the screen. It is possible to return to the original display using the CTRL and F2 function keys. Alternatively it is possible when configuring the workstation for this display not to be automatically given, in which case it is still possible to view operating system messages 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 SOC Viewer session. The operator can switch backwards and forwards between two or more windows by using the mouse to point to the desired window and clicking the left button. Note if a window completely covers another window, it must firstly be re-positioned using the Mouse facilities, in order 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 pointing to the top left corner of the screen, dragging the mouse repeatedly from right to left will bring the pointer back on to the screen. Before the first window is created the entire screen will be blank, except for a box which contains Username and Password. The Operator should enter the appropriate values, normally the username is SOCSYS with the password initially set to SOCSYS. This will cause a Session Manager window to be created. This can be then be iconised. Following the creation of the Session Manager the operator can thereafter create windows. Note: the Session Manager window must not be deleted as this is required in order to produce further SOC forms. To call up a window, position the cursor on the plain background outside any display areas and click the left button on the mouse. A small window will be displayed showing: Create SOC form window Create new VT200 window Next SUD display Previous SUD display Hold current SUD display Release 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 VT200 window and following the procedure in section 12.9. This will result in the creation of the SOC screen, 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 invited to login to the SOC. Once logged in the operator has access to the SOC forms which are available to the logged in user. The forms are accessed through a menu structure, detailed in chapter 3.

2-4

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

SOC Screen

Create new VT200 window: this allows the operator to access either of the BAPs in order to run SOC Viewer, which is also accessed via a menu structure, as detailed in chapter 4. This also allows the operator access to the SOC System account, needed if the SOC application is not running, see section 12.9. At the top of the SOC form there is a menu bar with a number of symbols. This enables certain operations for that form. These are supplied as part of the Motif windowing system. An explanation of these symbols is given in the manufacturers handbook which accompanies the SOC. Note: using key sequences not described in this Operators Guide for particular operations should either 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 VT200 form window window | | SOC Forms access SOC Viewer access | | | | Menu as described in Menu as described in Chapter 3 Chapter 4 Up to four SOC form windows can be open simultaneously. The current window is selected by locating the pointer in the desired window and pressing the left button on the mouse. More than one SOC Viewer or VT200 window may also be used at a time. It must be noted that the performance of the workstation will reduce as more windows are opened. The active window on the screen is the one containing the flashing cursor. All user input will be confined to the window containing the flashing cursor. Windows can be moved about the screen but should be kept wholly within the outside borders of the window area. Windows are moved by using the mouse to select the title bar; keep the button on the mouse depressed and move the mouse to drag the window to the desired position on the screen. A number of facilities specific to the windowing system of the SOC also relate to window control. For further details of these features refer to the manufacturers handbook which accompanies the SOC.

Windows can be reduced to icons by pointing the mouse to the minimize button at the right side of the top boundary box to the window. The windows are still active but there is no screen output of the information, allowing the operator to clear the screen of unwanted displays. It is possible to remove a window permanently using the exit command from the File selection menu on the left corner of the second top boundary box. Also, to remove a window used for SOC Viewer or Operating 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 form application is running the mouse can be used to select an option from the "Jump" menu. It should
2-5

SOC Screen

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

be noted that if a mouse is faulty, it is still possible to use all the commands of the SOC with the appropriate function and cursor keys, as described in the SOC manufacturers handbook. 2.6 Keyboard The keyboard is illustrated in figure 2-2 and consists of function keys along the top. f1 to f5 have preset functions and f6 to f20 are used as defined later in this Guide "qwerty" keyboard cursor movement keys and special keys - of the special keys, only the Help Do and Remove are used numeric keypad Special points to note are f1 - Hold Screen - key on the top left will freeze the screen and should be used with care. The green LED above the F3 key is illuminated as an indication that the screen is held. To remove the hold condition, press f1 key again. Do not leave Hold enabled while using other keys. Where the window contains a number of fields which must be filled in, use the keys with the arrows towards the right of the keyboard. The Tab key on the left can also be used to move to the next field. The Enter is used to effect an input To delete an entry, use the Delete key to the top right of the qwerty section. If confirmation is requested, this must be positive be entering Y. Return will be taken as N. Just pressing

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 systems database and the operator should appreciate how those changes are implemented in order to follow the reaction of the system to commands. 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 are checked immediately and can be rejected if wrong; the operator is then asked to enter an acceptable value. Checks which require access to the database are only made when all the data is entered. If the checks fail, a message is given to the operator, who must repeat the whole entry process. Once all changes are validated by the system, they become operational as soon as possible.
2-6

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001


newkey.eps

SOC Screen

Figure 2-2. SOC Keyboard - LA401


2-7

SOC Screen

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

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 to make changes to the database, these changes have to be read into the online system. In many cases 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 to obtain data in most cases, it may occasionally take a few seconds to produce the display or, in particular, to execute a command. During this time, a message is displayed in the same window advising the operator that processing is in progress. The operator should give the system time to work and not enter further commands until the initial one has been completed. Any subsequent commands are queued up and will be executed in turn; the result may be that the operator is unsure of all the actions which have been taken.

2-8

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

SOC Screen

2.9 Screen Blanking In order to prolong the life of the screen, it is automatically blanked after a timeout. Touching any key, or moving the mouse, restores the display. The timeout can be set by the operator (from the Set up Workstation option), but it is recommended that the default setting of 15 minutes be retained.
[opg2.mss]

2-9

Guide to the SOC Forms

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

2-10

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

Guide to the SOC Forms

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 all references 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 the operator enters information. Some fields are therefore read only; some require an entry and others can be modified by the operator. There is some overlap between the information available in different forms to provide a logical display of related data. There are also cases where control functions appear in more than one form; this is to allow different levels of access restriction while at the same time linking relevant control 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 configure all those parameters. Management forms are used to change operational states, e.g. in service and out of service. An initial state will have been associated with the relevant item using a Definition 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 allocated to the same key. These functions have the following meanings: Add : to add a new entity with the given parameters to the database, for instance add a new circuit. Delete : to delete an entity with the given parameters to the database, for instance delete an existing circuit. Enter (beside the numeric keypad) : confirms and executes the transaction. The updated parameters will then, and only then, be operational. First Page : to select the first page of a multi-page output, such as alarms. Modify : to change the parameters shown in the display. The information must first be called up using the Show function.

3-1

Guide to the SOC Forms

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

Next Page : to select the next page of a multi-page output, such as alarms. Prev Page : to select the previous page of a multi-page output, such as alarms. Show : will show the current state of the entity selected; it is a snapshot of the information held. Once a display is produced, it is not updated even if the relevant parameters in the system database alter. Pressing this key is one way to fetch the latest data from the database in the BAPs. The normal sequence of operations is therefore : indicate the desired function : press Add , Modify or Show as appropriate 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 are shown against each form. Where they are used, f13 - f20 have the following meaning : f13 : Erase field - delete the contents of the current field. f14 : Previous field - move to the previous field within the form displayed. f15 : Help - takes the operator into the online Help facility. f16 : Abort - cancel the request operation and re-enter the current form. f17 : Jump - brings up the direct access list from which any form may be selected. The mouse MUST be used to select one before any other function key is pressed. If the operator decides not to proceed with the change, use the last line Exit from this Menu to return to the previous form. f18 : Move - brings up the Menu window, from which another form may be selected. The mouse must be used to select one or EXIT before any other function key is pressed. f19 : Menu - go to the menu from which the present form was selected, or the parent menu if a menu is currently selected. f20 : Main Menu - go back to the top-level menu.

3-2

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

Guide to the SOC Forms

Program function keys - on the right hand side of the keyboard - are used as follows : pf1 : Gold - combines with another key to perform a specific function. pf2 : Help - another way of accessing the online help facility. pf4 : Hardcopy - causes the current form to be printed out (if printer attached). The following keys on the keyboard are also used in the specific way shown : Down arrow : Moves the cursor to the next field. Enter : completes the data entry in a particular boxed region of the form pf1 + Down arrow : moves the cursor out of a scrolled region to the next field pf1 + Up arrow : moves the cursor out of a scrolled region to the previous field Left arrow : moves the cursor one position to the left within the current field Return : moves the cursor to the next field Right arrow : moves the cursor one position to the right within the current field Tab : moves the cursor to the next field Up arrow : moves the cursor to the previous field. Ctrl-w : has the effect of refreshing the SOC screen display. 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 can however access the data in those fields which are not visible by scrolling down and up the display using the Down arrow and Up arrow keys. 3.4 Fields on SOC Screen Each field in a form has a specific maximum size and can only accept defined characters. Also, in many 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 may produce 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 MMM YYYY hh mm ss Day (1..31), Month (JAN,FEB,MAR,APR,MAY,JUN,JUL,AUG,SEP,OCT,NOV,DEC), Year (1901..2099), hours (0..23), minutes (0..59), seconds (0..59).
3-3

Guide to the SOC Forms

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

3.5 Help Help is available at successive levels. Pressing the Help key the first time displays information on the current field in the system response line. A second press of the Help displays a help form corresponding to the current form. Pressing help a third time gives general help information. A final press of the key returns the operator to the form which is being worked on. Note that selecting Help brings up a fixed text and therefore advice on any selections possible is not tailored to particular applications; for instance when selecting an ocean region, the help screen will present all 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 fields and then press the Show key. If more than one page of information is available, First Page , Prev Page and Next Page keys are available to scan through the pages. In some cases, more information is available by using the Up Arrow and Down Arrow keys. For new entries, use the Show to check that there is no existing entry, press the Add key and enter the details in the each section of the form in turn. Press the Enter when all the details are correct; 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 Show . Press the Modify key, enter the new data and then press the Enter key, which is needed to bring the revised configuration into use. The system performs checks on the data entered by the operator. Where an entry is rejected, the reason is shown on the form. Should the operator wish to terminate a transaction without effecting a change, the Abort key can be used, where this is provided. The operator can return to either the main menu or the menu immediately higher in the structure using function keys 19 (where appropriate) and 20 for the main menu. The Jump and Move keys 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. Some must be filled in, for example where there is an action to be performed, but others can be left blank, for example where a display is being called up. In general, the display will appear quicker if there are fewer qualifications entered since each qualification adds to the time taken to process the selection.

3-4

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

Guide to the SOC Forms

3.7 Menu of Forms The full SOC Form menu structure is shown in figures 3-1 and 3-2.The function keys to make selections are included. Where a function key is in parenthesis () then the following form will be selected from a SOC form rather than a menu. The initial selection of forms from the Main Menu consists 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]

3-5

Guide to the SOC Viewer

Message Routing and Destination Menu Message Handler Menu Terrestrial Interfaces Menu Refer to Online Processing Menu Tree 2/2 Main Menu Operator Logon Terrestrial Interfaces Menu Satellite Interface Menu Message Handler Menu User Services Menu System Control Menu Operator Menu Message Routing and Destination Menu Call Record Summary Display Message Details Menu Message Display Menu Terrestrial Routing Display Terrestrial Routing Definition Land Mobile Alert Destination Display Land Mobile Alert Destination Definition Maritime Distress Destination Definition

Call Record Full ICR Display

Satellite Interface Menu Refer to Online Processing Menu Tree 2/2

Call Record Full DCR Display

Message Details Menu Message Details Summary Display Message Queue Summary Display

User Services Menu Special Access Code Menu Special Access Code Display Special Access Code Route Definition Special Access Code Function Definition Special Access Code Address Definition Special Access Code Menu Registered Users Menu Mobile Users Menu Data Reporting Menu

Message Display Menu Message Status Summary Display Distress Message Summary Display Message Details Full General Display

3-6
Registered Users Menu Registered User Display Registered User Definition Registered User EGC Definition Registered User Polling Definition Registered User Data Report Definition Mobile Users Menu Mobile Definition Mobile Management Mobile List Management Test Mobile Definition Initiate PVT Test Message Status Full Display Distress Message Full Display Data Reporting Menu Data Report File Display Data Report File Management System Control Menu Operator Menu Change Password Operator Definition Operator Display Access Group Definition BAP Management FEP Management DEMSA Management Alarm Summary Display Event Summary Display

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

Alarm Management

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

Event Full Display

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


[scmex1.eps]

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

Satellite General Menu Satellite Parameter Definition Spot Beam Definition Satellite Reattempt Table

From Main Menu

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

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

TNIC Menu TNIC Display TNIC Definition Satellite Interface Menu Satellite General Menu Satellite Station Menu Satellite Equipment Menu Satellite Physical Channel Menu Satellite Logical Menu Satellite TDM Group Menu

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

3-7
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
SCMEX.VSD

Satellite TDM Group Menu TDM Group Definition TDM Group Management TDM Group Summary

Guide to the SOC Viewer

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


[scmex2.eps]

Guide to the SOC Viewer

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

3-8

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

Guide to the SOC Viewer

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 and to 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 information is fetched from the database or log files and displayed. Database Access is used to input new configurations into the database and can also display the related information already contained in the database. For new or changed data, the operator enters inputs against a string of prompts. These are then entered into the database after passing validation checks. Some software processes read the data directly from the database whenever it is used, and in these cases updates are effective immediately. Other processes read from the database on initialization only, and in such cases changes are implemented when the online software is restarted or as a result of switchover. Warning: Except in the case of Call Completion Code and Event definitions, whenever 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 configuration, a BAP switchover or system restart will be needed for the changes to become 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, whilst the offline options will be available from both Master and Standby BAPs, although a warning will be given whenever an offline option is invoked from the Master BAP. It is recommended that offline options be invoked from the Standby BAP in order to cause minimum degradation in performance to the online system. 4.2 Format of Reports Reports can be generated either as part of online processing or offline processing. The following general 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
4-1

Guide to the SOC Viewer

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

enter the value and press Return or, if no qualifier is required, just press Return . Each qualifier appears separately on the screen, in turn. Once a choice has been made and Return pressed, it cannot be altered, although it is visible on the screen. If the operator decides that he has made the wrong choice, he should return to the menu and select the report again. It is useful to make a double check that all the selections are correct. Some reports cannot be fitted into the screen; in these cases, they are paged and the display can be scrolled using the Prev Screen and Next Screen keys to be found on the right-hand side of the keyboard. Options generally exist whereby reports are displayed or can be sent to the Report Printer on request. 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 menu structure for successive choices to reach the desired function. However, it is only possible to go up 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 such as : M A D S X Modify Add Delete Show 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 Return or enter a new value and then press Return . Help is available at all stages, showing the entry options available.

4-2

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

Guide to the SOC Viewer

4.4 Accessing the SOC Viewer Access is via the VT200 option on the SOC pop up menu. Select Create a new VT200 Window with the mouse and press on the left button of the mouse. A prompt for a username is given; the response 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 for offline processing. However, offline processing can also be performed on the master but, if this mode is used, performance will be degraded. A warning appears on the screen if this is attempted. Online processing cannot be performed on the standby and any attempt to select online processing on the standby will be rejected. The welcome banner is then presented with the date and time of last logon; this changes to the top level menu selection as shown in figure 4-1, after a few seconds. The user should make a selection by number or use E to return to the parent of the current menu or M to return to the top level of the menu and then press Return on the keyboard. The user may also access the SOC viewer on either of the BAPs. The procedure is the same as for the SOC access, except the username is BAPV. The operator must also ensure that the desired 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 to manage the alarm printer and move data files between the database, the hard disk and tape and it sets the parameters for statistics collection. The menu is shown in figures 4-2, 4-3, 4-4, 4-5 and 4-6. Offline Processing is used to manage the closed log files and to abstract data from them. It is also used for the preparation of billing tapes and, where applicable, call record tapes. The menu is 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, the choice is to exit SOC Viewer, and the user will be asked to confirm this choice. Answering Yes will result 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 is presented in the form of a scrolling window. The information for these reports is ob4-3

Guide to the SOC Viewer

Online Processing Menu Level 1 Refer to Online Processing Menu Tree 1/4

Main Menu Level 0 1. Online Processing 2. Offline Processing 3. Exit 1 2 Offline Processing Menu Level 1 Refer to Offline Processing Menu Tree 1/3

4-4
[svmain.eps]

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

Figure 4-1. SOC Viewer Main Menu

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

Guide to the SOC Viewer

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 backup a dump to tape. statistics reports management controls the parameters used to produce statistics reports. 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 all messages 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 is necessary, 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 uses include 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 is indicated 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 a specified use, e.g. Return . Avoid using the Ctrl-z key, unless exiting from an editor, since it could give rise to undesirable effects, such as aborting software programs and transferring control up a level or two in the menu tree.
[opg4.mss]

4-5

Operator Logon/off

1 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 1 2 3 4 5 6 7

1 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 1 2 3 9

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

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. 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

Database Access Menu - Level 2 Refer to Menu 2/5

7 Alarm Print Management 3 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

Statistics Report Print Management 6 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 4

Online Database Reports Menu - Level 3 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 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

4-6
[svonl1.eps]

Statistics Reports Management 5 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

PADR Not supported on this system

Online Log File Reports Menu - Level 3 Refer to Menu Tree 3/5

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

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

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

7 F ro m Database Access Menu Onl i ne Level 2 Me n u 1. T el ex Database A ccess Level 1 2. X 25 D atabase A ccess 3. X 400 D atabase Access 4. Message H andler D atabase A ccess 5. U ser S ervi ces D atabase Access 6. F A X D atabase A ccess M. R eturn to Main Menu E. E xi t

6 1 2 3 4 5 6 2 1

FAX Database Access Menu Level 3


1. Add a new FA X Banner defi nition 2. Modify an exi sting F AX Banner definition 3. D el ete an exi sti ng FA X Banner definition 4. Li st All exi sti ng FAX Banner defi ni ti on fil es M. Return to Main Menu E. E xi t

X25 General Definition Menu


S . Show X 25 Detail s M. Modi fy X 25 Detai l s X . E xi t Menu

Telex Database Access Menu Level 3 Refer to Menu Tree 4/5

ACSE ID Definition Menu


S . S how the A CS E ID M. Modify the AC S E ID X . E xi t Menu

X25 Database Access Menu Level 3 1. X25 General Definition 2. X25 PAD Parameters Definition 3. X25 Reattempt Table 4. X25 Route Definition 5. X25 Line Definition 6. X25 Channel Definition M. R eturn to Main Menu E. Exit

2 1 2 3 4 5 6

X25 Profile Definition Menu I I. S how /Modify Interactive PA D Profile T able F. Show /Modify Fil e T ransfer PA D Profile Table F X . E xit Menu

X25 Interactive PAD Para Definition


S . S how PA D P rofi le Tabl e M. Modify PA D Profi le Table

X25 File Transfer PAD Para Definition S . S how PA D P rofi le Tabl e M. Modify PA D Profi le Table

Call Completion Code Def Menu S. Show the C al l Status Text for a CCC M. C reate / U pdate the C all Status Text for a C CC X. Exi t

X400 Database Access Menu Level 3 Refer to Menu Tree 5/5

Ocean Region Address Definition Menu S. S how database E ntry X. E xi t Menu 3

X25 Reattempt Table Men u S. Show tabl e entry M. Modi fy table entry X. E xit menu 4

Event Definition
S. Show database entry M. Modi fy database entry X. E xi t Menu

3 4

Message Handler Database Access Menu - Level 3


1. Ocean R egion A ddress D efi nition 2. NDN Spi ll-Out Desti nation Definiti on 3. Country Code D efi niti on M. Return to Mai n Menu E. E xit 1 2 3

X25 Route Definition Menu


S. Show D atabase E ntry A. Add Database E ntry M. Modify D atabase Entry D . Delete Database Entry X. E xi t Menu

NDN Spill-Out Dest Definition Menu


S . S how N D N A ddress M. Modi fy N D N A ddress X . E xit Menu 5

Inmarsat-C Timeout Entry Defn Menu S. Show D atabase Entry M. Modi fy D atabase Entry X. E xi t Menu

X25 Line Definition Menu


A. Add database entry D . Del ete database entry S. Show database entry M. Modi fy database entry X. E xi t Menu

User Service Database Access Menu - Level 3


1 1. A CSE ID Definition 2 2. Cal l Completion Code Definition 3 3. Event Defi nition 4 4. Inmarsat-C Ti meout E ntry Defi ni tion 5 5. Inmarsat-C Constant Entry D efi nition 6. Mobi le Del eti on 7. C hange S uperuser Passw ord M. R eturn to Main Menu E. E xi t

Country Code Definition Menu


A. Add database entry D. Delete database entry S. Show database entry M. Sel ect entry w ith match U. Modify database entry X. Exi t 6

4-7
S. Show D atabase Entry M. Modify D atabase Entry X. E xi t Menu

Inmarsat-C Constant Entry Defn Menu

6 6

X25 Channel Definition Menu


A. Add database entry D . Del ete database entry S. Show database entry X. E xi t Menu

Mobile Deletion M. Delete Mobil e From D atabase X. Exit

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


[svonl2.eps]

Operator Logon/off

Operator Logon/off

Report Process Main Menu C. Generate Report on Call Records D. Generate Report on Distress Messages E. Generate Report on Event Messages G. Generate Report on Grade of Service O. Generate Report on Operator Messages X. Exit Report Process C

From 2 Reports Menu Level 2 3 3 3

Online Log File Reports Menu Level 3 1. Generate Log File Reports 2. Print Log File Reports 3. View Log File Reports M. Return to Main Menu E. Exit 1 2

Report Viewing Menu - Level 4 1. Summary Message Report 2. Summary Statistics Report 3. LES to Mobile Message Report 4. Mobile to LES Message Report 5. Poll Message Report 6. EGC Message Report 7. DNID Retrieval Message Report 8. Data Report Report 9. DNID Handler Report 10. Distress Report 11. Events Report 12. Operator Message Report 13. More Options [Page 2 of 2] E. Exit

C Call Record Reports Menu 1. Summary and Statistics Message Report 2. LES to Mobile Message Report 3. Mobile to LES Message Report 4. Poll Message Report 5. EGC Message Report 6. DNID Retrieval Report 7. Data Report Report 8. DNID Handler Report 9. Mobile Login/Logout Report 0. Exit Menu

13

Report Process Printing Menu A. Print RP Summary Report : B. Print RP Summary Stats Report C. Print LES to MES Report D. Print MES to LES Report E. Print Poll Report F. Print EGC Report G. Print Data Retrieval Report H. Print Data Report Report I. Print DNID Handler J. Print Distress Message Report K. Print Event Message Report L. Print Operator Message Report M. Print Grade of Service Report N. Print Mobile Login/Logout Report X. Exit

4-8
13 View Log File Reports - Level 4 1. Grade of Service Report 2. Mobile Login/Logout Report 3. More Options [Page 1 of 2] E. Exit 3

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


[svonl3.eps]

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

NOTE:
From Database Access Menu Level 2 1 Telex Database Access Menu Level 3 1. Telex Leased Line Database Access 1 2 2. Telex Subscriber Signalling Database Access 3. Telex Trunk Database Access 3 M. Return to Main Menu E. Exit 3 Telex Trunk Database Access Level 4 1. Telex Trunk Definition M. Return to Main Menu E. Exit 1 Telex LL Database Access Menu Level 4 1 Telex Trunk Route Definition A. Add database entry D. Delete database entry M. Modify database entry S. Show database entry X. Exit Menu 1 1. Telex LL Definition 2. Telex LL Route Definition 3. Telex LL Circuit Definition M. Return to Main Menu E. Exit 1 2 3 2 Telex LL Definition Not yet available

= BAP SWITCHOVER OR RESTART REQUIRED TO EFFECT CHANGE

Telex LL Route Definition A. Add database entry D. Delete database entry M. Modify database entry S. Show database entry X. Exit Menu

4-9
2

Telex Subscriber Signalling Definition S. Show the DVR SCVF M. Modify the DVR SCVF X. Exit Menu 1

Telex LL Circuit Definition 3 Telex Subscriber Signalling Route Defn A. Add database entry D. Delete database entry M. Modify database entry S. Show database entry X. Exit 3

Telex Subscriber Signalling Database Menu Level 4 1 1. Telex Subscriber Signalling Definition 2. Telex Subscriber Signalling Route Definition 2 3. Telex Subscriber Signalling Circuit Definition 3 M. Return to Main Menu E. Exit 2

A. Add database entry D. Delete database entry M. Modify database entry S. Show database entry X. Exit Menu

Telex Subscriber Signal Circuit Defn A. Add database entry D. Delete database entry M. Modify database entry S. Show database entry X. Exit

Operator Logon/off

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


[svonl4.eps]

Operator Logon/off

NOTE:
= BAP SWITCHOVER OR RESTART REQUIRED TO EFFECT CHANGE

X400 Parameters Menu S. Show X400 Details M. Modify X400 Details X. Exit Menu

X400 Route Definition Menu A. Add X400 Route Details D. Delete X400 Route Details S. Show X400 Route Details M. Modify X400 Route Details X. Exit Menu

X400 Database Access Menu 1. X400 Parameters 2. X400 Route Definition 3. X400 Mailbox Definition 4. X400 Mailbox Management 5. X400 Address Translation Definition M. Return to Main Menu X. Exit 1 2 3 4 5

From Database Access Menu Level 2

X400 Mailbox Definition Menu 3 A. Add X400 Mailbox Details D. Delete X400 Mailbox Details S. Show X400 Mailbox Details M. Modify X400 Mailbox Details X. Exit Menu

4-10
[svonl5.eps]

X400 Mailbox Management Menu M. Modify X400 Mailbox Details S. Show X400 Mailbox Details X. Exit Menu

X400 Addr Trans Definition Menu A. Add X400 Addr Trans D. Delete X400 Addr Trans S. Show X400 Addr Trans M. Modify X400 Addr Trans X. Exit Menu

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

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

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

1 1 1

Default Processing Menu Level 2


F rom Mai n Menu Level 0 1. Do Default Housekeeping 2. Do Default Processing M. Return to Main Menu E. Exit

Housekeeping Menu Level 3


1. Log File Utilities 2. Database Utilities 3. Report Utilities 4. List Utilities M. R eturn to Main Menu E. Exit

Logfile Utilities Menu Level 4


D irectory of Logfiles in Offline Area Delete Logfiles from Offline Area Archive Logfiles from Offline Area Restore Logfiles to Offline Area D irectory of Logfiles in Online Area Copy Logfiles from Online to Offline Area 7. Delete Copied Logfiles from Online Area 8. View Logfile Disk Usage M. R eturn to Main Menu E. Exit 1. 2. 3. 4. 5. 6.

1 2 3

Offline Processing Menu Level 1


1. Default Processing Menu 2. Options Menu 3. Start Offline Database Server 4. Stop Offline Database Server E. Exit 1 2

Offline Database Loader Menu Level 3


1. Modify Logfile Specificati on 2. Modify Load Calls 3. Modify Load Distress 4. Modify Load Events 5. Modify Load Statisti cs 6. Modify Load wi th Carryover R. Run Loader M. Return to Main Menu E. Exit 1 2 3 5 3 : : : : : :

Database Utilities Menu Level 4


1. Archive Offline Database 2. Restore Offline Database M. Return to Main Menu E. Exit

Options Menu Level 2


1. Housekeeping 2. D atabase Load 3. Billing Data Generation 4. R eport Generation 5. Lists Generation M. Return to Main Menu E. Exit

Report Utilities Menu Level 4


1. Directory of Reports 2. View a Specific Report 3. Print a Report 4. Delete a Report M. Return to Main Menu E. Exit

Billing Data Generation Menu Level 3


1. Generate Customer Billing Tape 2. Generate Inmarsat Call Data Report Records Tape 3. Generate and Mail EDIFACT Ti cket 4. Combine tapes 5. Generate Customer Billing on Disk 6. Automatic Billing 7. Combine Disk Files M. R eturn to Mai n Menu E. Exit

4-11
[svofl1.eps]

Report Generation Menu Level 3 Refer to Menu Tree 2/3


5

List Utilities Menu Level 4


1. Directory of Lists 2. View a Specific List 3. Print a List 4. Delete a List M. R eturn to Main Menu E. Exit

Lists Generation Menu Level 3


1. List Log File 2. List Customer Billing Tape 3. List Customer Billing Disk File 4. List Inmarsat Call Data Report R ecords tape M. Return to Main Menu E. Exit

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

Operator Logon/off

Operator Logon/off

From 4 Options Menu Level 2

2
Report Generation Menu Level 3

Statistics Reports Menu Level 4

1 1 2 3 4 5 6 7

Channel Unit ChassisStatistics Report Level 5

1. Default Reports 2. Statistics Reports 3. Call Record Reports 4. Event Log Report 5. Distress Summary Report M. Return to Main Menu E. Exit

3 4 5

1. Channel Unit Chassis Stats Report 2. Channel Unit Rack Stats Report 3. ISL Link Layer Stats Report 4. TDM Group Stats Report 5. Call Completion Summary Report 6. Mobile Call Summary Report 7. Telex Route Stats Report M. Return to Main Menu E. Exit

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 Report M. Return to Main Menu E. Exit 2

: : : : : :

Distress Summary Report Level 4

: 1. Modify Start Time : and End Time 2. Modify Report Name : R. Run Report M. Return to Main Menu E. Exit

Telex Route Statistics Report Level 5 1. Modify Start Route Number : and End Route Number : : 2. Modify Start Time : and End Time : 3. Modify Report Name R. Run Report M. Return to Main Menu E. Exit

Channel Unit Rack Statistics Report Level 5

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

: : : : :

Event Log Report Level 4

Mobile Call Summary Report Level 5

: 1. Modify Start Time : and End Time 2. Modify Report Name : R. Run Report M. Return to Main Menu E. Exit

1. Modify Start Time and End Time 2. Modify Start Mobile Number and End Mobile Number 3. Modify Report Name R. Run Report M. Return to Main Menu E. Exit

: : : : :

ISL Link Layer Statistics Report Level 5

4-12
[svofl2.eps]

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

: : : : :

Call Record Reports Menu Level 4 Refer to Menu Tree 3/3

Call Completion Summary Report Level 5 1. Modify Driver : 2. Modify Start Call Serial Number : and End Call Serial Number : 3. Modify Start Time : and End Time : 4. Modify Report Name : R. Run Report M. Return to Main Menu E. Exit

TDM Group Statistics Report Level 5

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 Report M. Return to Main Menu E. Exit

: : : : : :

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

Figure 4-8. SOC Viewer Off-Line Processing Menu Tree 2/3

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

2 All Mobiles Report - Level 5

From Report Generation Menu - Level 3

LES Call Report - Level 5

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 Report M. Return to Main Menu E. Exit

: : : : : :

Call Record List Report - Level 5

EGC Call Report - Level 5

1. Modify Start Time : and End Time : 2. Modify Report Name : R. Run Report M. Return to Main Menu E. Exit 3
Performance Profile Report Level 5 6

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 Menu E. Exit

: : : : : : : : : :

1. Modify Start Time and End Time 2. Modify Call Nature 3. Modify Start Completion Code and End Completion Code 4. Modify Call Direction 5. Modify Report Name R. Run Report M. Return to Main Menu E. Exit

: : : : : : :

MES Analysis Report - Level 5

Call Record Reports Menu - Level 4

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 Report M. Return to Main Menu E. Exit 1 3 5 7 9
7 Call Completion Summary Report - Level 5

: : : : : :

2 4
6

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

: : : : :

1. Call Record List Report 2. All Mobiles Report 3. LES Call Report 4. EGC Call Report 5. MES Analysis Report 6. Performance Profile Report 7. Call Completion Code Summary Report 8. Driver-Specific Call Completion Code Report 9. All Call Statistics Report M. Return to Main Menu E. Exit

4-13
[svofl3.eps]

1. Modify Start Time : and End Time : 2. Modify Start Completion Code : and End Completion Code : 3. Modify Report Name : R. Run Report M. Return to Main Menu E. Exit 9

8
Driver Specific Call Completion Report - Level 5

All Call Statistics Report Level 5

1. Modify Start Time and End Time 2. Modify Priority 3. Modify Report Name R. Run Report M. Return to Main Menu E. Exit

: : : :

1. Modify Start Time and End Time 2. Modify Priority 3. Modify Report Name R. Run Report M. Return to Main Menu E. Exit

: : : :

Operator Logon/off

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

Operator Logon/off

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

Autobilling Main Menu Level 4

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 : : : : : : : : :

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 M. Return to main menu E. Exit

5 - Housekeeping Menu Level 5

4 5 7 8 S R

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

7 - Auto CSV File Configuration Level 5 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 : : : : : : : S - Autobilling Start Level 5 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 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

4-14
[svaubill.eps]

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

: : : : :

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

M. Return to main menu E. Exit

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

SVABOTC.VSD

Figure 4-10. SOC Viewer Autobilling Menu Tree

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

Operator Logon/off

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 than one 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.5 and is presented with the Operator Logon form. Enter name and password and then press the function 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 Logoff function key. 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 is not 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]

5-1

Terrestrial Interfaces

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

5-2

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

Terrestrial Interfaces

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 dedicated connection passing information in real time such as telex, PSDN (X25 and asynchronous) or PSTN. Terrestrial interfaces are defined by route : a group of circuits going to the same destination, e.g. the International Switching 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 the next 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 a number 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 to the 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 add new ones to the system, to group them into routes, to control the operational state of each circuit and 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
6-1

Terrestrial Interfaces

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

will then be entered into the database. For PSDN lines, a DEC package is used to provide some levels of the interface functions. This package is configured by the VMS Console and not the SOC. The configuration will have been set up on installation. 6.3 Forms for Trunk Telex Circuits Telex circuits can be used for all three terrestrial service access points (TSAP1, TSAP3 and TSAP4) as described in the System Manual. Certain parameters are common to all trunk telex lines, regardless of which TSAP they are used on. These parameters are set on the Telex Trunk Management form (SOC Forms - Terrestrial Interfaces - 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 messages sent out from the LES on the terrestrial side pseudo-mobile name : this is used by TSAP 1 only and sets the characters used in the answerback given by the ACSE to incoming calls calling party answerback times for first WRU (default value 10s) and Post answerback idle 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 raised when it is selected for normal calls to advise the operator enable test on a nominated circuit. The nominated circuit will only accept mobile to shore calls from the test mobile. Note that if the test mobile originates a multiaddress 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 otherwise be used for traffic. When selecting a test circuit, ensure that there are other circuits available in the route to carry traffic, i.e. that other circuits are equipped and that they are In Service. Otherwise, normal traffic will cease on that route. To configure telex circuits, routes must first be set up. Before adding a route, inspect what is already set up in the system by call up the Trunk Telex Route Display (SOC Viewer - Online Processing - Run Reports - Online Database Reports). Note: that routes and circuits are generally set up as part of system installation and it is envisaged that changes to route and circuit set up will occur infrequently, if at all. Addition of new lines may be one reason for changing the route/circuit configuration. Each route has a unique number within the ACSE, independent of the interface type, as detailed in section 8.3.1. Entries show the following details:
6-2

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

Terrestrial Interfaces

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 for outgoing delivery notifications (the answerback used for one-stage access and message delivery will be derived from the number of the mobile involved - refer to the Telex User Interface document for 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 Trunk Database 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 enquiries. One route is required for outgoing traffic and one route for each TSAP served by trunk lines in the incoming 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 Trunk Circuit Display(SOC Forms - Terrestrial Interfaces - Telex Trunk). The operator may optionally specify a route, otherwise all routes are displayed. Note: if more than one type of telex is used the 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 has completed RETEST - this occurs after a fault and is automatically performed to re-establish working 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 block at the rear of the TIF rack where the circuits are connected to the external lines. Enter the circuit number and press Show for :
6-3

Terrestrial Interfaces

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

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 is rack 01 in suite A the slot identity of the telex switch card is entered, numbering 1 to 16 (slot 0 is the CPU card) the direction in which the circuit is seized is entered - outgoing or incoming. (Bothway is 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 the direction of the circuit and the route. The direction should be the same as the route or, if the route is 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 Trunk Circuit Management form (SOC Forms - Terrestrial Interfaces - Telex Trunk). Select the form, enter the circuit number and press Show to see the current state. Press FOS-all to put the circuit Out of Service immediately. Press OOS-all to put the circuit Out of Service after any existing calls have matured This form can give direct access to the Telex Circuit Definition form by pressing the Define key. When a telex message is received using single-stage access, the originating telex network is identified 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 - TNIC Display). 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 F69 for Inmarsat). To change an entry, access the TNIC Definition form (SOC Forms - Terrestrial Interfaces - TNIC Definition). Enter the name and F69 code which goes with the TNIC. (It is useful here to include any network limitations such as TWX in the United States) This data will normally only be changed if there is a corresponding change in the international routing. The F69 code is a two or three digit number, the TNIC is one, two or three alpha-numeric character(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-4

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

Terrestrial Interfaces

goes faulty. These sets are First phase selection Second phase Third and subsequent phases Set A 60 secs 5 mins 30 mins Set B 72 secs 6 mins 36 mins

The set selected should be the opposite of that used in the switching centre at the other end of the trunk lines and is effected using the Telex Trunk Circuit Definition (SOC Forms - Terrestrial Interfaces - Telex Trunk). In the first and second phases there will be up to five attempts to send the retest sequence, the interval between each attempt being that shown. For the third and subsequent phases the retest sequence will be sent at the intervals stated until such time the exchange responds with a retest response which puts the line back into service or the operator puts the line back into service. If the message is not delivered, the ACSE will make multiple attempts at delivery, depending on the reason for failure. The Telex Reattempt Table contains a list of failure codes against which the number of re-attempts and the frequency of those reattempts (in minutes). There will be a set of separate values for each type of telex supported (i.e. trunk, subscriber or leased). This can be modified using Telex Reattempt (SOC Forms - Terrestrial Interfaces ) The default values are as follows : Failure Reason Absent subscriber/office closed Backward path signal BK cut off Congestion DER out of order INF subscriber not available call inf JFE office closed due to holiday MOM waiting NA correspondnce with sub not admitted NC no circuits NCH subscriber number has changed No service signal NP party is no longer a subscriber OCC subscriber is engaged Other service signal Unexpected answerback Attempts 10 5 5 20 10 5 5 5 3 20 1 5 5 20 5 2 Interval 30 1 1 10 20 1 1 1 1 10 1 15 2 10 1 1

6-5

Terrestrial Interfaces

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

The following relationship exists between the above Failure Reasons and the Telex call completion codes contained in Appendix E: Call Completion Code NC NC NC FMT NC NC NC NC NC NC NC OCC NC ABS DER NC NP NA OCC INF MOM JFE BK UNK IAB DER IAB NC NC NC NC NC NC NC NC NRT NA NA NA NA NA RTD DER NA NP NA NC NC NC NC NCH No. Reattempt Reason No Service Signal NC NC Other Service Signal Absent Absent Absent Absent Absent Absent Other Service Signal OCC NC Absent DER NC NP NA OCC INF MOM JFE BK Other Service Signal Unexpected Answerback Unexpected Answerback Unexpected Answerback Backward Path Signal NC Other Service Signal Backward Path Signal Other Service Signal Other Service Signal Other Service Signal Other Service Signal Other Service Signal Other Service Signal Other Service Signal Other Service Signal Other Service Signal Other Service Signal Other Service Signal Other Service Signal NP NP NP NP NP NP NP NCH

TLX Idle Timeout 500 TLX No Seize Confirm 501 TLX No PTS Received 501 TLX Invalid Format 503 TLX User Cleared 504 TLX User Cleared Awaiting COT 505 TLX User Cleared Awaiting COT Check 506 TLX User Cleared Awaiting Selection 507 TLX User Cleared Awaiting Selection Validation 508 TLX User Cleared Awaiting IC Answerback 509 TLX Circuit Fault 510 TLX Busy 511 TLX Congested 512 TLX Absent 513 TLX Out Of Order 514 TLX No Circuits 515 TLX Not Permitted 516 TLX Not Admitted 517 TLX Engaged 518 TLX Unobtainable Call Info Service 519 TLX Waiting 520 TLX Closed 521 TLX Cut Off 522 TLX Other Service Signal 523 TLX Unexpected Answerback 524 TLX No Answerback 525 TLX Answerback Mismatch 526 TLX Back Path Signals 527 TLX LES Failure 528 TLX Tape Stuck 529 TLX Call Preempted By IC 530 TLX Outgoing Circuit Guarded 531 TLX No Call Connect 532 TLX No Clear Confirm 533 TLX No RC TC 534 TLX No Further Retests Needed 535 TLX Invalid Seize Combination 536 TLX Invalid COT 537 TLX Invalid COT COTC 538 TLX No COT Sent 539 TLX COT Not Permitted 540 TLX Incoming Retest Detected 541 TLX Incoming Message Not Secured 542 TLX No PIN 543 TLX Invalid PIN 544 TLX No WRU 545 TLX Invalid PTS 546 TLX Station Closed Awaiting Incoming Answerback 547 TLX Station Closed Awaiting Clear Confirm 548 TLX Station Closed 549 TLX Number Changed 550
6-6

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

Terrestrial Interfaces

NC NC NC NC NC NC NC NC NC NC NC NC NC NC NC NC NC NC NC NC NC NC NC NC NC NC NC NC NC NC NC NC NC NC NC NC NC NC NC NC NC NC NC NC

TLX OG Multi Addr TLX NO OG CCT TLX NO FREE OG CCT TLX ENOUGH RETRIES TLX MES AB Services TLX CODT IF TLX MDIR ROU IF TLX MDIR DEL IF TLX TLXIL IC IF TLX TLXIC CRM I TLX TESH IF TLX SDA REGD USER IF TLX ES PARSE ERR TLX OVERSIZE MSG TLX UNREG CONFIG ERR TLX FEP INTRO TLX OP FOS TLX INV DESTN ADDR TLX Delivery CRM Err TLX Enter Reset TLX X Host Fault TLX Spare TLX OL Silent Timeout TLX TLXOL OC If TLX BAD Msg TLX Active To CallBusy TLX Active To StatnClosed TLX Active To CircFault TLX Guard To CircFault TLX OGSR To CircFault TLX OGSR To StatnClosed TLX OGSR To CallBusy TLX Busy To CircFault TLX Busy To TI OOS TLX StatnClosed To TI OOS TLX FEP Inactive TLX Err Read TermChar TLX LO Timeout MsgTXAck TLX OL MsgFormatErr TLX OL OC TIMEOUT TLX OL LO TIMEOUT TLX OL STOP BY LM TLX OL HALTED TLX IL LO TIMEOUT

551 552 553 554 555 556 557 558 559 560 561 562 563 564 565 566 567 568 569 570 571 572 573 574 575 576 577 578 579 580 581 582 583 584 585 586 587 588 589 590 591 592 593 594

NP NC NC DER NC NC NC NC NC NC NC NC NC BK NC BK BK NP NC Other Service Signal Other Service Signal NP NC NC NC NC NC NC NC NC NC NC NC NC NC NC NC NC NC NC NC NC NC NC

The caller signals end of text by the characters EOT. The LES then returns the time, date and message 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 a limit on the number of characters which are allowed to follow the EOT; if this limit is exceeded, it returns character T. The default limit is set at 6 characters; this limit can be changed on the Post EOT Character Limit Table (SOC Viewer - Online Processing - Database Access - Telex Database Access - Telex General Database Access). Set this limit to 30 if an answerback is expected after EOT.

6-7

Terrestrial Interfaces

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

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 line can be placed in maintenance state using the Telex Circuit Management form if there is persistent trouble with the line. It can then be tested using proprietary test equipment without carrying normal 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 and Virtual Circuits (in that order). Changes need to be made at the SOC, the DEMSA unit and the exchange, at roughly the same time. Configuring the DEMSA units is achieved by running a DEC Configuration 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 the ACSE, as described in chapter 8; a separate route number is required for each DEMSA pair to comply 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 - Online Processing - Run Reports - Online Database Reports). X.25 lines, corresponding to the ports on the DEMSA units, are identified by an NUA. This is provided by the PSDN so that both the ACSE and the PSDN identify each line in exactly the same way. Each line must have a separate NUA. At the network end, group hunting should be employed so that the load is spread over the available lines. Sub-addresses are also used on PSDN access. For normal PSDN registered user access, the subaddress of 00 is recommended, either inserted by the terrestrial caller or by the packet network as a default address. This allows other subaddresses to be used for X400 access (if required) 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 Database Reports) 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-8

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

Terrestrial Interfaces

current state. Virtual circuits are configured using the X25 Channel Definition (SOC Viewer - Online Processing - Database Access - X25 Database Access). Call up the form and enter the route, line and virtual circuit (channel) number. The direction shows which way calls can be set up on the circuit 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 the LES and the connected PSDN switch to establish connections. A maximum of 32 virtual circuits can be allocated to any one line and a maximum of 64 virtual circuits can be allocated in the system, 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 the chance of blocking. HNS will recommend the how the lines should be set up, and will normally configure them as part of an initial installation. Note: when altering the configuration of a line, or circuits associated with that line, the line must be set to Out of Service using the X25 Line Management SOC form. The X25 Channel Display (SOC Viewer - Online Processing - Run Reports - Online Database Reports) shows the virtual circuits allocated to a line. Call up the form, enter the route and line number. 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 number and direction. X25 lines, but not virtual circuits, have a state which can be managed using the X25 Line Management (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 out of service when any existing calls have completed)

6-9

Terrestrial Interfaces

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

To change a state, select the form, enter the route and circuit number, press the function key for the desired state and press Enter . If the circuit and route numbers are not known, they can be found using the X25 Route Display (SOC Viewer - Online Processing - Run Reports - Run Online Database 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 this form. Note that the configuration of the line profile itself e.g. packet sizes, window sizes, number of channels is part of the installation process which involves using the DEC PSI software and is done by 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 - X25 Database Access) is used to indicate the driver identity and to set timeouts for clearing a call and for 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 but the caller has not responded. This timeout is used at the set value once, a reminder is issued to the caller, and then a timeout of half this set value is used to repeat the reminder. If after a period of half the set value, the caller has still not responded, the call is cleared. The aim of this sequence is to clear idle sessions on the X25 interface. 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 the ACSE waits after the message has been delivered before the call is cleared. For interactive operation, the ACSE downloads parameters which can be altered or inspected using X25 Interactive PAD Parameter Definition (SOC Viewer - Online Processing - Database Access - X25 Database Access - X25 Profile Definition). Call up this SOC Viewer option and enter 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-10

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

Terrestrial Interfaces

For file transfer, the same set of parameters can be independently set using the X25 File Transfer PAD Definition (SOC Viewer - Online Processing - Database Access - X25 Database Access X25 Profile Definition). Reattempt rates can be set, by using the X25 Reattempt form (SOC Forms - Terrestrial Interfaces). The number of reattempts and their frequency (in minutes) for a variety of call failure reasons can be set. Select the form, and the existing values will be displayed. Use Modify to change settings for number of reattempts and interval. Example values are as follows : Reason Attempts Interval ACCESS BARRED CALL COLLISION DTE INCOMPATIBLE CALL INTERNAL CAUSE LPE NETWORK CONGESTION NUMBER BUSY OUT OF ORDER PSDN PROTOCOL ERROR REMOTE DTE CLEAR RESET RESTART RPE TIME OUT ON NETWORK 3 20 2 5 1 20 10 5 1 10 5 5 2 5 1 10 1 2 1 10 5 2 0 5 2 2 2 2

The following relationship exists between X25 Call Completion codes, (see Appendix E) and the above reattempt reasons. Note not all call completion codes are covered, since they relate to INCOMING call failures. Call Completion Code DER NA LPE NA NC NC NC NC NC NC DTE OCC DER ABS NA NC X25 Remote Procedure error X25 Access Barred X25 Local Procedure Error X25 DTE Incompatible Call X25 Call Collision X25 Restart Received X25 Reset Received X25 Network Timeout X25 Network Timeout X25 Internal Cause X25 User Cleared X25 Number Busy X25 Out Of Order X25 Not Obtainable X25 Invalid Dest Address X25 Network Shut No. 600 601 602 603 604 605 606 607 607 609 610 611 612 613 615 622 Reattempt Reason RPE ACCESS BARRED LPE DTE INCOMPATIBLE CALL CALL COLLISION RESTART RESET NETWORK CONGESTION TIME OUT ON NETWORK INTERNAL CAUSE REMOTE DTE CLEAR NUMBER BUSY OUT OF ORDER REMOTE DTE CLEAR DTE INCOMPATIBLE CALL INTERNAL CAUSE

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

6-11

Terrestrial Interfaces

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

6.7 PSDN Line Failures Any failure will be detected by the VAX PSI software and reported as an event. The X25 Line Management 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 temporary problems 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 the network provider is detected. The software will detect recovery by receiving an incoming call or making 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 so that an alternative route can be used, if one exists. This covers cases where the line failure recovery is not possible without operator corrective action. DEMSA failures are detected separately and, if possible, a DEMSA switchover is initiated. This will be notified to the operator by an event indicating a DEMSA failure followed by a DEMSA switchover 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 be provided 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 before failing the delivery attempt. If the delivery is successful on any of the alternative lines no further action is taken. If the delivery fails on all possible alternative lines, the delivery attempt will be considered as failed. (The delivery will be reattempted according to the rules based upon settings in the X25 reattempt table.) 3. Consecutive delivery attempt failures due to line problems will be counted. If this count gets greater then a maximum failure allowed on the route (set to 10) then the route will be marked as unavailable and no more deliveries will be attempted on the route. However, incoming calls on an unavailable route will be accepted and will cause the route to be reset to available. This is because receiving an incoming call on a faulty line is a good indication that the line has recovered. The maximum number of failures allowed on a route (10) ensures that enough time has been given for lines 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 for the 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 the line stays in the failed condition for a long period, then the number of events generated would fill up the log files. To avoid this problem the number of events raised on the same line has been reduced proportionally to the number of attempts, ie only the 1st, 3rd, 6th, 12th and 24th attempts generate an event.

6-12

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

Terrestrial Interfaces

6.8 PSTN Interface for Facsimile The Fax Interface is provided via PCs running application software on OS/2 and connected to the LES via Ethernet. The number of reattempts and reattempt interval for a message delivery is set by default to be 5 reattempts and 5 minutes reattempt interval respectively, although this can be changed at the PC. From each PC there are up to 4 lines connected via modem to the PSTN network, 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 the parameters file for LESFAX. Log in to the BAP account (BAPSYS). Edit the parameters file by entering: $ EDIT LESFAX_PARAMS Amend the values of Number_Of_Attempts and Reattempt_Delay to reflect the values set on the PC. This allows the BAP software to predict the maximum delivery time for a message and generate events when delivery completion is overdue. As with all other terrestrial interfaces, a route must be allocated for delivery of messages via Fax and the Fax PCs used must be associated with a Fax route. By convention, Fax route numbers are in the range 17 to 32. A description of the operational procedures associated with the FAX PC together with a system description, 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 addressable 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 all the Fax routes defined. Select the form and press First Page ; use the Up arrow and Down arrow to scroll around the display. The information displayed on each route consists of: 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 Of Service, 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 the shadow disk, that have not yet been transferred to the local message queues on the Fax PCs. Messages Waiting in PCs - The number of messages currently in the local message queues of the Fax PCs for this Fax route.
6-13

Terrestrial Interfaces

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

Message Waiting for BAP - The number of delivered messages that are awaiting processing of their delivery details by the BAP. Access to the Definition and Management forms can be obtained directly by placing a Y in the left-hand column and pressing Define or Manage respectively. The FAX Route Definition (SOC Forms - Terrestrial Interfaces - Fax) allows individual route characteristics to be defined. Select the form, enter a Route Number (e.g. 18) and press Show . The 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 or SSerif10, and letterhead, for Faxes sent out on that route. Possible values are DEF_BANR only, which corresponds to a default provided by the system. Definition files will have previously been provided for DEF_BANR, and these contain information 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 and 6.8.5. Details of the format of the definition files are contained in Section 6.8.6. Current State - Current state of the Fax route. Possible values are In Service, Out Of Service, Pending OOS and Shutdown. The Add , Modify and Delete keys can be used to add new route entries and modify or delete existing entries. In addition, Display and Manage give direct access to the FAX Route Display and FAX Route Management forms. The FAX Route Management (SOC Forms - Terrestrial Interfaces - Fax) is used to control the operational state of the FAX Routes. Select the form, enter the required Route Number (e.g. 18) and press Show . The form shows : Number of PCs Connected - The number of PCs attached to a particular Fax route. Messages Waiting for PCs - The number of messages, in the shared area of the shadow disk, that have not yet been transferred to the local message queues on the Fax PCs. Messages Waiting in PCs - The number of messages currently in the local message queues of the Fax PCs for this Fax route. Message Waiting for BAP - The number of delivered messages that are awaiting processing of their delivery details by the BAP. Number of PCs Connected Current State - Current state of the Fax route. Possible values are In Service, Out Of Service, Pending OOS and Shutdown. Action Requested - Desired state of the Fax route. Possible values are In Service and Out Of Service.
6-14

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

Terrestrial Interfaces

To change the current state of the route to In Service or Out of Service, use INS or OOS respectively. In addition Display and Define give direct access to the FAX Route Display and FAX Route Definition forms. 6.8.2 FAX PC SOC Forms The following FAX PC SOC forms, used to interrogate and manage the Fax PCs, are addressable from 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 all the FAX PCs. Select the form, enter a Route Number or 0 for all routes, and press First Page ; use the Up arrow and Down arrow to scroll around the display. The following information will be displayed 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, Pending OOS, Out Of Service, Contact Made, Contact Lost and Shutdown. Messages Waiting for PCs - The number of messages, in the shared area of the shadow disk, that have not yet been transferred to the local message queues on the Fax PCs. Messages Waiting in PCs - The number of messages currently in the local message queues of the Fax PCs for this Fax route. Message Waiting for BAP - The number of delivered messages that are awaiting processing of their delivery details by the BAP. Access to the Definition and Management forms can be obtained directly by placing a Y in the left-hand column and pressing Define or Manage respectively.

6-15

Terrestrial Interfaces

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

The FAX PC Definition (SOC Forms - Terrestrial Interfaces - Fax) allows individual PC characteristics to be defined. Select the form, enter a PC identifier (e.g. PC_B) and press Show . The following information will be displayed : 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, Pending OOS, Out Of Service, Contact Made, Contact Lost and Shutdown. The Add , Modify and Delete keys can be used to add new PC entries and modify or delete existing entries. Access to the Display and Management forms can be obtained directly by pressing Display or Manage respectively. The FAX PC Management (SOC Forms - Terrestrial Interfaces - Fax) is used to control the operational state of FAX PCs. Select the form, enter a PC Identifier (e.g. PC_C) and press Show . The following information will be displayed : Route Number - The Fax route with which this Fax PC is associated. Messages Waiting for PCs - The number of messages, in the shared area of the shadow disk, that have not yet been transferred to the local message queues on the Fax PCs. Messages Waiting in PCs - The number of messages currently in the local message queues of the Fax PCs for this Fax route. Message Waiting for BAP - The number of delivered messages that are awaiting processing of their delivery details by the BAP. Current State - Current state of the Fax PC. Possible values are In Service, Pending OOS, Out of Service, Contact Made, Contact Lost and Shutdown. Action Requested - Desired state of the Fax PC. Possible values are In Service and Out Of Service. To change the state of this FAX PC to In Service or Out Of Service, use INS or OOS respectively. In addition Display and Define are used to give direct access to the FAX PC Display and FAX 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, PC or 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-16

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

Terrestrial Interfaces

The FAX Route Statistics (SOC Forms - Terrestrial Interfaces - Fax) display provides the following 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 following information 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 information 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

6-17

Terrestrial Interfaces

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

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 awaiting conversion into the appropriate FAX format. 3. These represent calls that have been passed to the PC from the BAP and are in the process of being converted into the appropriate FAX format. 4. These represent calls that have been passed to the PC from the BAP, have been converted into the appropriate FAX format, and now are waiting for a modem to become 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 a logo on the first page. The Zetafax workstation program is used to create this file in conjunction with 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 not use 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 are provided 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-18

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

Terrestrial Interfaces

Note: if an attempt is made to invoke the add or delete options, a warning is given that this option is 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. the system 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 customer basis, 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]

6-19

Terrestrial Interfaces

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

Notes: 1. This line contains 80 spaces. This is required in order to provide an underline for the whole 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 all other operator definable banner files, from which changes can be made according the available options and banner requirement. 3. The meaning of the keywords contained between %%[ and ] are described in the Zetafax User Guide, Appendix B, Reference [6]. 4. Up to 50 markers, of the form <...>, can be specified to the LES software. These contain specific text that is translated by the LES software to values associated with the particular message which is to be output via FAX. The specific text set used by the 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/East, Pacific, Indian or Unknown. <MRN> - Message reference number. <Date> - Will display the date in the form "dd month yyyy", e.g. 20 April 1995. <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-mm UTC", 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 banner definition. The character < must NOT be used on its own other than as the leading delimiter forming part of the defined marker text. The use of this character in isolation may cause the banner to fail. If a < character is required to be displayed as part of free text within the banner, then two such characters must be used, with no separation, in the banner definition thus: <<. This will result in the output of a single <.
[opg6_fax.mss]

Atlantic/West,

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 an asynchronous terminal. The ACSE is connected via one of its asynchronous ports to a MicroTurbo PAD. This PAD has up to eight connections, configured either as incoming or out6-20

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

Terrestrial Interfaces

going, but not both ways, each linked to a CODEX modem to the PSTN network. The users terminal is linked with a compatible asynchronous modem into the PSTN network. Thus communication can be established. In order to route messages from a mobile to an asynchronous terminal, specific settings are required in the routing table. A special asynchronous route must be configured, 60 usually being allocated 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 a value such that translation by the message handler software will cause routing to be via the DEMSA connection into the MicroTurbo PAD. Generally, to achieve this the PSDN address extension should begin with 9. For calls from an asynchronous terminal to an MES, the LES interface is similar to that for the PSDN interface, the difference being the network used to make the connection. The former employs the PSTN network whereas the latter employs the PSDN network. In the asynchronous case it is necessary to connect to the LESs PSTN number, and providing a line into the LES is available and modems are compatible, a connection is made. In the PSDN case it is necessary to connect to the LESs X.121 address. Both types of connection are made into the LESs DEMSAs. A description of the operational procedures associated with setting up asynchronous communication plus some guidance to use, is contained in reference [5].
[opg6_async.mss] [opg6.mss]

6-21

Satellite Interfaces

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

6-22

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

Satellite Interfaces

Chapter 7 SATELLITE INTERFACE


7.1 Overview The satellite forms control configuration of the ACSE hardware on the satellite side. Therefore this section covers configuration of the channel units. While there are some forms dealing with the common hardware, such as the channel unit rack, the majority 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 given channel The LES is free to allocate each function to the hardware and can switch the operation from one physical 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 sparing pool which is designated by the operator. The SOC operator is responsible for entering details of the physical channel unit, ie what hardware is equipped in which position. Physical hardware consists of : channel unit racks - one per ocean region, including the equipment in the SDAP chassis. 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 Chassis Definition and may or may not be the same as the number of the chassis in the Channel Unit Maintenance Manual, Reference [3]. physical channel units - each unit is either a modulator or a demodulator. Channel units 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 channel units (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
7-1

Satellite Interfaces

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

The association between logical and physical channels is in several groups, within each of which any logical channel can be associated with any physical channel unit. Physical C-band transmit L-band receive C-band receive Logical TDM TDM SIG, MSG

Note: The terms C-band and L-band are consistently used in this document to denote distinct bandwidths used for satellite transmission. For domestic satellites the equivalent Ku-Band is used instead of C-band. Further details of the applicable satellite bandwidths are to be found in the System Manual, Ref.[2]. For redundancy, there are more physical channel units than logical channels. The spare units are allocated to pools of active units, so that they can be configured with operational parameters automatically by the software in the event that an operational unit has failed. As a minimum, one pool is required for each IF interface. For message transfer, the TDM, MSG and SIG channels are grouped into TDM groups, each containing 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 that there 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 the TDM, signalling and message channels, as specified in ref 1. To co-ordinate the timings, the ACSE has to determine the time taken for a transmission to the satellite and back again. Based on this timing, it knows when to expect data on the signalling and message channels. This timing is derived in the TDM demodulator, and the visual indicators which show that synchronization is established in the TDM demodulator are important when checking that the equipment is operational. The system is designed so that one, and only one, TDM demodulator is used to determine the loop timing for all the channel units that communicate with one physical satellite. The operator has to indicate the position of the demodulator on the TDM Rx Logical Channel Unit Definition form. The system will automatically transfer that timing control to the standby demodulator should redundancy switchover take place. The chosen demodulator should take into account the possibility of spot beam . If there is only one TDM group in the system, no choice is involved. If spot beam working is in use, the demodulator can only be tuned to a modulator in the global beam or in a beam illuminating the earth station. If multiple TDM groups are provided, one group at least should be permanently assigned and that group 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 LES Management. The LES Summary form (SOC Forms - Satellite Interfaces - Satellite Station) summarizes the state of the LES with respect to all the Ocean Regions it serves. Select the form and press Show for a tabular display which shows the following for each Ocean Region.
7-2

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

Satellite Interfaces

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 associated SIG 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 the selected time. The LES Management form (SOC Forms - Satellite Interfaces - Satellite Station) shows further details of the operational status of the system. Call up the form, enter the Ocean Region and press Show . The form shows: current mode : normal or standalone. This will always be set to standalone since the LES operates without an NCS. T15 : this is the time which the LES waits for MES unreserved access to the MES signalling channel. The default value is 19.5s. See ref 1 for further explanation. Base apparent signal strength : this is used as a measurement base when Performance Verification Tests are performed. See ref 1. A value of 16db less or greater 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 the selected 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 indicate open. Enter the desired state and press Modify . Such action will stop all mobile to shore messaging. 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 the TDM 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 .
7-3

Satellite Interfaces

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

This form controls information on the TDM Bulletin Board and the information will be broadcast when the next TDM is assigned. A separate form has to be completed for each Ocean Region served by the ACSE. The form shows : the LES number. This number is set up when the system is first installed and cannot be 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 listed below 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 the software

satellite generation - first, second or third - which sets the speed on the Message Channels and Signalling Channels. See section 7.3 for the actions needed when the satellite is changed from one generation to another. satellite operational - normally set to yes but can be set to no if the satellite, or the RF equipment 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 Reattempt Table described below. If, however, a call completion code were to exist which does not have an entry in the Satellite Reattempt Table, then this value will be used as the number of times further attempts are made to establish a call before giving up. To modify an existing set of data, press Modify , enter the new data and press Enter . This alters the 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 into service 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-4

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

Satellite Interfaces

according to the failure reason for delivery using the Satellite Reattempt form (SOC Forms Satellite Interface - Satellite General). Select the form and press Show for the current settings, which consists of : Call Completion Code - fixed text Retry Count - range 0 - 20. Note that the first attempt does not count in this entry and the 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 - 839 from a range of 800-899). Use the Next Page and Previous Page to see the whole display. When the form is selected, the first page is automatically displayed. It is not possible to add, or remove entries from the list, using the SOC. Modifications can be made to more than one completion code at a time. The maximum period during which retries may be attempted is the retry interval multiplied by the number of retries. This has a maximum of 3 days; this is the longest time a call is allowed to remain in the system. If errors are made in entering data, only the last error that occurred can be reported. However if invalid 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.

7-5

Satellite Interfaces

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

Call Completion Code CCC_SD_Failed CCC_SD_Mobile_Absent CCC_SD_Aborted_By_Operator CCC_SD_Call_Failed_Due_To_Alert CCC_SD_Invalid_Address_In_Message CCC_SD_Invalid_Address_Format CCC_SD_Invalid_Message_Size CCC_SD_Invalid_Number_Of_Addresses CCC_SD_Invalid_Presentation CCC_SD_LES_Internal_Error CCC_SD_Mobile_Already_Commisioned CCC_SD_Mobile_Barred CCC_SD_Mobile_Busy CCC_SD_Mobile_Failed_To_Respond CCC_SD_Mobile_Forced_Clear CCC_SD_Mobile_Not_Commissioned CCC_SD_Mobile_Not_Logged_In_OR CCC_SD_Mobile_Not_Registered CCC_SD_Mobile_Responded_Incorrectly CCC_SD_Mobile_Response_Timeout CCC_SD_Mobile_Protocol_Error CCC_SD_NCS_Failed_To_Respond CCC_SD_NCS_Forced_Clear CCC_SD_Presentation_Conversion_Error CCC_SD_Protocol_Failure CCC_SD_Remote_Equipment_Failure CCC_SD_Resource_Limit_Exceeded CCC_SD_Satellite_Network_Failure CCC_SD_Service_Not_Provided CCC_SD_Call_Pending CCC_SD_Invalid_Les_ID CCC_SD_TDM_Not_Available CCC_SD_No_Message_status_Information CCC_SD_ITD_SD_Error_In_Outbound_Message CCC_SD_EGC_Transmission_Failed_By_NCS CCC_SD_EGC_Packet_Sequence_Error CCC_SD_Call_Cleared_By_System

Number 800 801 802 803 804 805 806 807 808 809 810 811 812 813 814 815 816 817 818 819 820 821 822 823 824 825 826 827 828 829 830 831 832 833 834 835 836

Retry count 0 0 0 5 0 0 0 0 0 5 0 0 5 5 5 0 0 0 5 5 5 5 0 0 5 5 5 5 0 5 0 10 0 5 1 1 1

Retry Interval 0 0 0 5 0 0 0 0 0 5 0 0 5 15 5 0 0 0 5 5 5 15 0 0 5 5 15 5 0 10 0 1 0 5 2 2 5

CCC_SD_Distress_EGC_Interruption 837 3 5 CCC_SD_Announcement_Failed_Due_To_Login 838 6 1 CCC_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 a result, the centre frequency of the channel units can be altered using the Satellite Parameter Definition 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 as follows. The typical RF values of CN0 for each band are listed below. Band C-band uplink (first generation) C-band uplink (second, third generation)
7-6

RF of CN0 6392.5 MHz 6405.0 MHz

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

Satellite Interfaces

C-band downlink (first generation) C-band downlink (second, third generation) L-band downlink

4167.5 MHz 3585.0 MHz 1510.0 MHz

Note that the two values of C-bands relate to the actual satellite in use and therefore may be changed . The administration or designer of the up-converters and down-converters in the earth station will know the frequencies at the IF interface which correspond to the above values or they will know what 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 frequency supplied 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 channel number corresponds to the stated fif. For the C-band and L-band downlink signals, enter the frequency in Hz corresponding to CN0 plus 21400.0. This correction factor accounts for the functional difference between modulation and demodulation. 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 there are changes in the RF frequencies C-band TX CN0 C-band RX CN0 L-band RX CN0 40750.0 kHz 62150.0 kHz 62150.0 kHz

Select the form, enter the Ocean Region and press Show . The values of CN0 cannot be altered from 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 generation channel speeds on second generation satellites. Third generation satellites have the features of a second generation satellite plus the additional capacity 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 operations are supported. The frequencies, firmware and demodulator boards for third generation satellites are the same as for second generation. See also Section 7.8.

7-7

Satellite Interfaces

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

The channel rates are controlled by an entry in the LES Definition SOC form as noted above and also by the precise hardware used in the demodulator module. The RF translation is controlled by the Satellite Parameter Definition SOC form which is also described above. To change between first and second generation operation, if required, the following steps must be taken. Change the firmware in the demodulator Channel Units which are used for Message channels only, including any standby units. The appropriate firmware is available from HNS if required. The firmware is contained in i/cs U11, U12 and U13 as follows : U11 U12 U13 1010973 - 0001C CS 8D8A First generation 1012930 - 0001A CS 8A48 Second, Third generation 1010972 - 0001C CS FA58 First generation 1012929 - 0001A CS C7DF Second, Third generation 1010971 - 0001C CS AE5E First generation 1012928 - 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 correct part number is used. If there is a mismatch on the MSG demodulator between the satellite generation for which it is equipped 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 the FEPs driving it; these are defined using the LES Definition form (see above). The Channel Unit Rack Management form (SOC Forms - Satellite Interfaces - Satellite Equipment) is used to specify 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 to take it Out of Service or put it back to In Service.
7-8

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

Satellite Interfaces

For an existing rack, select the form, enter the Ocean Region and press Show to view the current state. To alter a state, press Modify , enter the desired values and press Enter . The state change will be advised on the message line. The Show key can also be pressed periodically for an update of the status. The Channel Unit Rack Status Summary form (SOC Forms - Satellite Interfaces - Satellite Equipment) is used to display and control the states of all components of the rack. Select the form, enter the Ocean Region and press Show to view: CURC IF : the interface link between the processor and the alarm module. This should show Up timing received - indicates if the TDM RX channel unit is successfully receiving the frame timing generated by the TDM TX unit with loopback via the satellite. This should show Y for correct operation. If it shows a N, then there is a fault - see section 7.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 master timing modules - set this to Auto normally. The Channel Unit Rack Statistics report (SOC Viewer - Offline Processing - Options - Reports Generation) provides details of faults on the rack over a specified period. The operator can enter the interval start and stop times and is given details of the operation of the links between the FEP and 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 equipment serving 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 the normal way and then take the following action : power supply : the two units feed the rack in parallel. Failure in one should not interrupt the operation of the rack, which can be quickly confirmed by ensuring that displays are still present on the front of the modules. See the Channel Unit Operations and Maintenance Manual, Reference [3], for the replacement procedures. Many faults can be dealt with by replacement of the plug-in modules from the front of the rack. Only a major fault requires the complete replacement of the unit and switching power off the rack. MTM : check that automatic switchover has taken place by observing the LEDs on the ASM next to the MTM and replace the faulty unit with a spare one. Before inserting the spare, check that the switch settings are as in the unit being removed. They
7-9

Satellite Interfaces

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

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 if the failure is one or all of the fans. There are 9 separate neon lights visible from the back of the fan tray to show which are working. If all fans have failed, immediate action 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 be replaced, but the rack will continue to operate normally. Follow the instruction in the Channel Unit Operation and Maintenance Manual for replacement, which should only be 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 the system, and in particular to reception of packets on the message channels. The Channel Unit Rack Status Summary form has an entry Timing Received which should show Y for correct operation. If an N is shown, check that the indications on the channel unit rack are correct, as indicated in section 10.6. Perform any re-initialization or replacement of modules to re-establish the correct operation. If the hardware appears to be operating correctly, check that the TDM modulator and TDM demodulator are correctly configured at the SOC and in particular, that the TDM demodulator is configured to receive loop timing on the TDM Rx using the TDM Rx Logical Channel Unit Definition 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 connected and also displays the physical connection to each slot on the IF interface. The FEP port numbering is set up in the factory as follows : Chassis Number FEP Port FEP Port (on SOC) left half right half Bottom CU Middle CU Top CU SDAP 5 4 3 1 3 5 7 2 4 6

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

7-10

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

Satellite Interfaces

The chassis number shown above must agree with the setting of the switch marked Tray Address on the channel unit backplane. This switch should be set as follows : Chassis number on SOC 0 1 2 3 4 5 6 Bit 1 Down Up Down Up Down Up Down Bit 2 Down Down Up Up Down Down Up Bit 3 Down Down Down Down Up Up Up Bit 4 Down Down Down Down Down Down Down

Select the form, enter the Ocean Region and chassis number and either press Add to add a new chassis or Show for an existing one. To change entries, press Modify , enter the new values and press Enter . To delete a complete chassis, press Delete . Note: that the allocation of FEP ports must 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 that L band transmit is not used. Note: The form shows slots 0-15 and is arranged in two halves. The top half shows slots 0-7 allocated 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 C or 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 changes are 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 Ocean Region and chassis number and press Show to see, for each slot number for that chassis, the port, PCU overall status, band, direction, channel type and logical channel identity. The Channel Unit Chassis Statistics report (SOC Viewer - Offline Processing - Options - Report Generation) shows details for each slot of the statistics collected on a regular basis. Call up the form, enter the Ocean Region and chassis number and press Return . The start and stop times of the 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 the channel unit response timeouts : to polls from the software

7-11

Satellite Interfaces

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

received CRC errors : the number of responses to polls received by the software with corruption, 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 frames received in error Demod RX CRC errors : the number of packets received by the demodulator with errors, as detected by the error check on the packet itself. Demod RX carrier loss : the number of times the demodulator lost carrier. This applies 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 be covered 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 exception is the CU chassis backplane. If this fails, the immediate recovery action is to concentrate all traffic on 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 to have failed) to chassis 5 (which is assumed to be completely free). Note: this procedure is error prone and should be exercised with extreme caution. 1. Arrange the IF connections between the CU slots and the splitter/combiners on chassis 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 identical 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 to that in A4. 4. In order to prevent two chassis with the same address, set the DIP switch marked Tray Address on the backplane in A4 to be identical to that which previously existed in 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 from A4/A32/J1 and insert in A5/A32/J1. The channel units now in chassis 5 should be automatically initialized and configured in the normal manner. Details of the identities of all the positions in the channel unit racks are contained in figure 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-12

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

Satellite Interfaces

from chassis 4 to chassis 5 in the database, using the relevant procedures for physical channel units 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 is to be used. This is done on the Physical Channel Unit Definition form (SOC Forms - Satellite Interfaces - Satellite Physical Channel). Call up the form, enter the Ocean Region and PCU identity and press Show , Add or Delete as appropriate. 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 by pressing Modify , entering the new data and pressing Enter . An existing channel unit must be taken 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 connection to the module; the latter is the co-axial cable from the connector above the channel unit backplane to the combiner/splitter behind the backplane. New channel units will be supplied with this cable and details of where it should be installed. Note that a PCU must be identified using the above form and the Add function before it can be added to a sparing pool. Also, before deleting a PCU, ensure that there is no logical channel assigned 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 no operational function) PCU frame number - TDM frame number which counts sequentially from zero at midnight logical channel unit details in the form of channel type (TDM, MSG or SIG) and LCU number 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 .

7-13

Satellite Interfaces

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

7.4.7 Channel Unit Module Failures Failure in an individual module will result in a spare (if available) being automatically substituted for the failed module. It is helpful to understand the mechanism of failure detection to see how the system 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. Receive CUs are polled several times a frame (8.64 seconds). Transmit CUs are polled when 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 alternately for every CU on each half chassis. As an example, if there are 3 CUs in a half-chassis and there is no data to transmit, then it could take 3 frames or 25 seconds 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 retries one 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 60 seconds 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 CU resets due to watchdog timeout. It is desirable to avoid programming another Modulator to take over where there would be the possibility of two CUs radiating the same carrier for a minute. Instead, there is a wait of 60 seconds to do the redundancy in expectation that an isolated modulator will reset itself. It is undesirable to switch unnecessarily in case of temporary line problems between the channel units and the CUC. If the CU comes back up before the 60 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 not be switched out by the redundancy control. 4. If any CU problem persists for 60 seconds, the software performs a CU redundancy configuration change. In the specific case of failure of the TDM demodulator due to the loss of the input signal, the failure will be reported as an event, but then the module will be reconfigured and will search for the correct input signal. Therefore, although the input signal is not present, the module will report its status 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 Unit Definition forms (SOC Forms - Satellite Interfaces - Satellite Logical Channel Menu)
7-14

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

Satellite Interfaces

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 each form, enter the Ocean Region and the LCU identity and press Show . To delete an entry, press Delete . To modify an entry, press Modify , enter the new spare pool number and press Enter . The system will automatically select a physical channel unit from that pool but the PCU can also be specified with this form if it is desired to force a first choice. The operator must ensure that the PCU 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 is to be derived from the channel - this must be done for one, and only one, TDM RX channel in the rack and must always be operational to bring up a TDM group. Choose a permanently assigned TDM group if possible. For the nominated demodulator, enter Y against the question Frame Timing, for any other TDM demodulator, 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 the ACSE allocates message channel capacity in advance; this in practice will normally be left at its greatest value (255) but can be used to limit the mobile to shore traffic handled by the LES. The TDM group and frequency allocated to the message channel are displayed on this form. Note: that before deleting a MSG channel, ensure that it is not assigned to a TDM group. SIG : the use of the channel can be restricted to any or one of store and forward service, closed user group or distress, and also if supported: pre-assigned data reporting, land alerting and aero-c. The TDM group and frequency allocated to the signalling 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 Group Definition form (SOC Forms - Satellite Interfaces - Satellite TDM Group). The system has been designed currently for only one group for an Ocean Region. For each group, enter the Ocean Region and TDM group number and press Show for the following : type of operation : normal or standalone. As the LES is designed to operate without an NCS, this should always be set to standalone.
7-15

Satellite Interfaces

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

spot id : set to 0 to denote global spot used (which is the only one available with first and 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 randomly picks a new frame to transmit a repeated SIG packet, when the burst received bit has not been set for the original attempt. This form will display the LCU identities of the TDM RX and all the MSG and SIG channels allocated 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 Modify , entering the new values and pressing Enter . Note that Add and Delete are not operational at present. TDM groups can be managed using the TDM Group Management form (SOC Forms - Satellite Interfaces - Satellite TDM Group). Select the form, enter the Ocean Region and TDM group number and press Show . The information shown is as follows : 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 before the timer expires. DN: Released, TDM has been released, awaiting confirmation. DN: TDM down, no activity pending.

7-16

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

Satellite Interfaces

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 and should always be set to N. Do not attempt to use this as the recovery action requires 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 the operator. Setting these to 0 will stop all traffic. This mechanism should be used when it is desired to stop traffic on the TDM, for instance to take it out of service to alter bulletin board parameters.

min outbound - (default 1) is the minimum number the LES can reduce the number of outbound calls to when the TDM exceeds a pre-defined load threshold. max outbound - (default 56) is the maximum number the LES can increase the number of outbound calls to when the TDM falls below a pre-defined load threshold. Throttle in - (default 60) is the percentage of the current traffic load for that TDM the system can reduce to when the system exceeds a pre-defined load threshold, within a two minute period. Throttle out - (default 25) is the percentage of the current traffic load for that TDM the system can increase by when the system falls below a pre-defined load threshold, within a two minute period.

LCU status of all the channel units in the group. Only the frequency code can be modified 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
7-17

Satellite Interfaces

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

PCU status - UP or DOWN

Use the Arrow keys to scroll through the LCU display. To modify the state and frequency code (applies in Restoration working only) press Modify , enter the new values and press Enter . To change the flow control limits on the TDM, press Modify , enter the new values and press 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 Return for a list corresponding to each of the associated TDM groups. For each entry the following information is shown: 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 Return . The display shows: collection interval TDM frames, packets, split packets and bytes for each signalling channel : one slot and multislot packets, slots acknowledged and not 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 or demodulators. There must be set of pools for each ocean region served. All the channel units in the pool must be physically of the same type, and occupy the same channel unit rack. Separate pools are required for C-band up, C-band down and L-band down. Providing there is one spare channel 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 pools for TDM channel units. This is necessary in the case of modulators if the transmit levels on the
7-18

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

Satellite Interfaces

TDM channels are different, since the standby unit must be set to exactly the same level as the unit carrying traffic. Use a separate pool number for each group of units, splitting transmit and receive directions, and the bandwidths used. Thus the minimum recommended pooling arrangement for each ocean region 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 have a pool for each channel unit type. The Channel Unit Spare Pool Definition form (SOC Forms - Satellite Interfaces - Satellite Physical Channel) is used to designate these pools. The pool is identified by Ocean Region and a number in the range 1-64 for each pool. A textual name for each pool and the directions must be defined, whether transmit or receive, and the function(s) allowed must be indicated. Then the physical identities of all the units in that pool must be entered. Select the form, enter the Ocean Region and spare pool number and press Show for an existing one, Add for a new one or Delete to remove an existing one. To change an existing entry, press Modify , enter the new parameters and press 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 the Channel Unit Spare Pool Status Summary form (SOC Forms - Satellite Interfaces - Satellite Physical Channel). Call up the form, enter Ocean Region and press Show . The resultant display provides 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 and SIG. direction : transmit or receive (Tx or Rx) PCUs configured : total available for use
7-19

Satellite Interfaces

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

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 the satellite loop timing is derived, must be equipped on the global beam or on a spot which illuminates the LES. Sets of IF interface will be required - one for the global beam, if used, and one each for each of the other spots served. At the physical level, channel units must be identified as either serving a global 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 (signifying the global beam), as only global spot beam operation is supported. The Spot Beam Definition form (SOC Forms - Satellite Interfaces - Satellite General) allows the operator to see, for each spot, the number of TDM groups assigned and the number of TDM groups in service. The operator can see and also set the maximum number of TDMs which can be in service. This value should only be set when the maximum number of TDMs value has been previously set for the corresponding Ocean Region using the LES Definition form. The total of all the maximum number of TDMs for all the spots associated with that Ocean Region must not exceed the maximum 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 before the changes are made. However, a TDM group can only be taken out of service when there are no calls pending. To achieve this state, the call limits on the outbound and inbound routes should be set to 0 to stop any new calls being set up, using the TDM Group Management form. When all 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). This specifies the physical location of the cards within the channel unit rack and specifies how the card will be used (TDM/SIG/MSG/ANY). The format of the PCU identity is C.SS where C is the chassis id (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 this stage the spare pool type (TX/RX) and the allowed use (TDM/SIG/MSG/ANY) is specified. A short text description can also be supplied. Each of the cards which is to be included in the pool must then be listed using their PCU IDs.
7-20

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

Satellite Interfaces

When cards are addressed their PCU IDs are not used. Instead they are addressed by Logical Channel Unit IDs (LCU IDs). This allows the exact position of the cards to be altered without affecting how they are addressed. It also allows different physical cards to be addressed by the same logical address. LCU IDs have a particular channel kind associated with them so there is a separate set of addresses for each channel kind and link direction, i.e. there are TDM RX LCU IDs, TDM TX LCU IDs, etc. All of these must be set up individually. LCU IDs are numbered 1 to 6 for each separate channel kind and link direction. When defining the LCU ID for a card, two separate sparing pools can be specified, using the appropriate Logical Channel Unit Definition form SOC Forms - Satellite Interfaces - Satellite Logical 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 configurations 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 unit racks can be told to generate their own framing timing signals using their MTMs or to use another racks timing signals. The TDM frequency code can be specified. 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 channel services can also be switched on or off, dependant on whether the services are supported for the customer. The services are: Store and Forward, Closed-User Groups, Distress Traffic, Aero C, PADR Reserved, Land Alerting. If a particular service 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 MSG channel allocation, which represents the number of frames into the future to allow message space to be reserved, can be specified, although the default value (100) is generally used..

Now the LCU IDs can be added to the TDM Group. TDM Groups are numbered in the same way as LCU IDs - from 1 to 6. There can only ever be a maximum of 6 TDM Groups per Ocean Region. TDM Groups beyond Group 1 are either required for additional traffic capacity or to sup7-21

Satellite Interfaces

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

port additional spot areas. Each TDM Group operates on a different frequency (specified by its frequency codes). When defining the TDM Group, using the TDM Group Definition SOC form, the following can be specified: 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 unsupported by 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 the corresponding TDM Group ID). The LCU IDs for all the SIG RX and MSG RX channels in that TDM group are listed afterwards 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 in Chassis 2, Slot 6 is defined 1. Select the Channel Unit Chassis Definition form: Enter the Ocean Region and Chassis ID (2). Press Show , followed by Modify and then move the cursor to slot (6). 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 Add again. 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 then press Show . Press Modify , and move cursor to down to the next available entry.
7-22

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

Satellite Interfaces

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 1 field, 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 Show followed by 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. 7. Select the TDM Group Management form: 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 Chassis 2, Slot 6 will be deleted. 1. Select the TDM Group Management form: 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 Show followed by Modify . Move the cursor down to where Logical SIGs are defined and delete the LCU (2) (overwrite with spaces), and then press Enter .
7-23

Satellite Interfaces

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

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 Show , followed by Delete and then Enter . 4. Select the Channel Unit Sparing Pool Definition form: Enter the Ocean Region, and the Sparing Pool ID (3, for SIGs), and then press Show , followed by 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 Show , followed by Delete and then Enter . 6. Select the TDM Group Management form: 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 Unit Definition 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 some forms require cross checking into other tables (forms) in the database. If operations are done out of 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-24

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

Satellite Interfaces

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 Group Management. 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 afterwards and not before:

7-25

Satellite Interfaces

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

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 Unit Management form (SOC Forms - Satellite Interfaces - Satellite Physical Channel) or the switch on the front of the channel unit, it performs a self-test sequence. The Hex display on the front of the channel unit will indicate 0 at the start of this sequence and 9 after several seconds to indicate that initialization is complete. If the physical channel unit slot is configured in the database, the software will then proceed to configure the channel unit according to the information in the database - eg TDM. This configuration process takes several seconds more, but after no more than 30 seconds, the normal indications shown in section 10.6 should be displayed. If the channel unit remains at 9 or does not show the anticipated display, check the database using 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 into service. 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 be observable on the channel unit rack. 1. Initially, TDM modulator displays 9 or 8 and the TDM demodulator, MSG and SIG may display 9, 8 or their correct configurations. The lower LED on both MTMs will show red. (The red LED on the BIMs will also be illuminated, but this only repeats the MTM indication.) 2. The TDM modulator is configured with the appropriate frequency and starts transmission. 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 for one 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 is extinguished. 5. On the CU Rack Management form, the status of (CURC I/F is Up and the MTM Timing 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 (eg FEP changeover).

7-26

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

Satellite Interfaces

7.10.2 Network Failures Failures in the class NET can be in the TDM TX, TDM RX, MSG, or SIG channel units. At least one TDM RX channel is provided, tuned to a TDM TX frequency so that the satellite loop timing can be determined. The flashing of the Frame Detect LED on the front of the TDM RX unit every 8.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 sharing one 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. The system should already have automatically substituted a standby. To check, determine the state of the spare pool by using the appropriate Logical Channel Unit Definition SOC form to find out the spare pool number and then use the Channel Unit Spare Pool Status Summary SOC form to check that there are now sufficient operational units in that pool, followed by checking this is the case 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 the cause of the failure. In the meantime, it is likely that the satellite interface will be non-operational but handling of messages on the terrestrial side will continue without interruption until the message queues are full. 7.10.4 Channel Activity Monitoring The system monitors the activity on Message and Signalling channels and generates an alarm if the channel is inactive for a preset period. The timers provide an approximate measure of the time during which there was no activity on the channel. Restart of activity on the channel is also recorded in the event log. The timeout is set independently for the message and signalling channels as two groups. It is not set for each individual channel. It is also possible to set the timers for PEAK and NON-PEAK hours, so that traffic differences during the day can be accommodated. In this context, PEAK is usually set for daytime and NONPEAK to night time. SIG PEAK -- 60 minutes MSG PEAK -- 65 minutes SIG Non PEAK -- 90 minutes MSG Non PEAK -- 90 minutes PEAK 06:00 to 18:00 Non PEAK 18:00 to 06:00 which represents timeout values of 60 minutes during the hours 06:00 UTC to 18:00 UTC and 90 minutes during 18:00 UTC to 06:00 UTC on both channels. These values are factory set.

7-27

Satellite Interfaces

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

7.10.5 Internal Timers The ACSE uses a number of internal timers which are normally configured during installation of the equipment but which can be altered by the operator. Do so only after careful consideration of 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, T12, T13, T14, T15, T16, T17, T18, T19, T20, T21, T22, T32, T33, T34, T43, T44 T100, T101, T102, T103, T104, T105, T106, T107, T108, T109, T110, T111, T112, T113, T114, T115, T116, T117, T118, -- for MES to be deemed idle after contact with the CES -- for MES announcement response -- for test request from MES -- for NCS response to announcement or poll request -- for MES unreserved access to MES signalling channel -- for MES message -- for MES reserved access to MES signalling channel -- for MES test response -- for MES distress test -- NCS timeout -- NCS timeout -- NCS timeout -- for NCS during distress -- for MES to acquire TDM -- for NCS in queued announcement -- for LES during distress (ref 1. T33 at NCS) -- for TDM assignment hold time (ref 1. T34 at NCS)

-- for CUC response in Ship-Shore message transfer -- for CUC response in Shore-Ship message transfer -- for CUC response in PVT Test Result transfer -- Time to wait for an EGC Ack -- Time to wait for a response from the NCS to a poll -- CUC, input message transfer timeout -- CUC, input retransmission timeout -- CUC, Acknowledgement response timeout -- CUC, Assignment response timeout -- CUC, database update interval -- Time to wait for ISL congestion to clear -- Spare -- Spare -- Spare -- Spare -- Spare -- Spare -- Spare -- Time before retrying with TDM Request after a TDM -- Request Response indicating pending. T119, -- Timeout on TDM Request and TDM Release packet -- responses T120, -- Delay period before retrying outbound call Recommended values are as follows (although some timers have been changed at particular installations) :
7-28

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

Satellite Interfaces

Timeout Identity T11 T12 T13 T14 T15 T16 T17 T18 T19 T21 T22 T32 T33 T34

Suggested value (seconds) 130 120 0 45 195 300 30 95 420 60 60 45 25 300

Timeout Identity T100 T101 T102 T103 T104 T105 T106 T107 T108 T109 T110 T111 T112 T113 T114 T115 T116 T117 T118 T119 T120

Suggested value (seconds) 1200 1200 600 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 1200 90 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 Return followed by Tn Return (where n is the number of the timer to be changed). 3. Modify the entry for the timer by typing Return M Return Tn Return required current value Return required default value Return Yes Return . 4. Repeat the Show and Modify operations for each of the timers which require changing. 5. Force a BAP switchover to bring the new values into use.
[opg7.mss]

7-29

Message Handling

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

7-30

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

Message Handling

Chapter 8 MESSAGE HANDLING


8.1 Introduction This chapter shows how messages are routed through the system. It also shows the operator how to find out about messages which the system is in the process of handling or has recently handled. Message routing is one of the principle functions of the ACSE. The operator has considerable flexibility to set up the rules to be used for routing messages between the satellite side and the various 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 a terrestrially 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 is known 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 since there is a variety of routes which can be used and it is often necessary to translate the address received from the mobile into a different address (or at least alter the first few digits of the address). However, addressing is simpler for messages to mobilessince the terrestrial network splits terrestrially originated telex messages into categories - unregistered message submission, registered access and message status enquiries - which simplifies the processing which must be performed at the ACSE . The ACSE uses Routes to associate a given address with a set of physical circuits which connect to, or towards, the desired destination. Physical circuits are associated with routes as described in chapter 6. Once the route has been determined from the initial address, the software driver for
8-1

Message Handling

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

that interface can attempt to deliver the message. Special arrangements are made for the routing of certain categories of messages. For example distress 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 routed to 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 network. 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 list shows the route to be taken by the message. Basic parameters are set up in the system to indicate which ocean regions are served. Within each 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 for each specific interface. It is important, however, to understand the different routes which are available. These are described in more detail in the System Manual, Reference [2], but are summarized 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 is that 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 available to 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 the user is connected to the LES he follows a set pattern of interaction illustrated in figure 8-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 steps followed are described in figure 8-3. (The status of messages from registered users are obtained via TSAP3 access). Additional routes of each type may be defined to access different networks or define different characteristics. 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. Once connected, the access is as for PSDN terminals except for minor differences in the manipulation of
8-2

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

Message Handling

Telex Subscriber

Telex machine

Telex Switched Network

Leased Line TSAP1 Ocean Region and Mobile Number Outgoing TSAP3 No useful address information TSAP4 No useful adddress information

LES

Figure 8-1. Telex Access Mechanisms

8-3

Message Handling

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

Registered Telex TSAP3

Connect to LES

PIN

Answerback check

LES gives prompts + caller responds as per Interface Descriptions in System Manual

Final question is "Dialogue concluded?"

Connection cleared

Figure 8-2. TSAP3 : Telex Registered User Access

8-4

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

Message Handling

TSA4 Message Status Enquiry

Connect to LES

User supplied MRN + Time of acceptance

LES supplies status of message

Call cleared

Figure 8-3. TSAP4 : Telex Unregistered Message Status Enquiry

8-5

Message Handling

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

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 the purposes of understanding how the ACSE handles messages, figure 8-4 shows the relevant steps. 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 the LES and the congestion bit is not set. The mobile then sends a Request Packet to the LES. The ACSE 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 Channel Assignment and Time of Message to the mobile, telling it when the message can be sent and on which 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 on PSDN) is valid the address extension is valid (which includes those cases where no address extension 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 is requested. When the whole message has been received at the ACSE, an acknowledgement is sent to the mobile, if it was requested at the beginning of the transaction, and the message is stored securely. The ACSE can then begin the process of delivering the message to the recipient(s). The address presented by the mobile is not necessarily the same as the address passed on to the terrestrial network. For instance, the country code may have to be removed for messages to the country in which the LES is sited. It is also necessary to validate the country code received from the 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 the incoming or outgoing direction. PSDN addressing may be used to access the PSTN network for calls to terminals having a dial up asynchronous modem.
8-6

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

Message Handling

Mobile to shore message

Mobile selects LES

Request packet on SIG

LES checks for mobile in OR + Destination network in SIG received in

"Logical channel assignment" or "Time of message" sent to mobile

Message packets

LES checks address for address length and address extension fields

Message received OK N

Message acknowledged (if requested) + stored

Retransmission of failed packets requested

Message ready for delivery cycle

Figure 8-4. Mobile to Shore Message Flow

8-7

Message Handling

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

PSTN for facsimile the ACSE operator Message delivery is attempted as soon as the message has been securely received from the originator. The address information in the call announcement packet and in the beginning of the message packet is used to select a terrestrial route. Once a route has been selected, the routing information 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 to the 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 the services available in the terrestrial network. Table 8-1 lists some of the possibilities : Destination Network Telex PSDN PSTN Extension Allowed no no yes T30 for Fax (group 3) supported Vnn for Async (where nn is valid modem communication standard). supported CNID SAC CSDN X400 Mobile Number Ocean Region no no no no no no (Also referred to as DNID) Can be used for translation within ACSE (Not supported) (Not supported) Typical Address Extensions and Notes

Table 8-1. Destination Networks and Address Extensions

8-8

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

Message Handling

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 code received 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 address extension 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-out Address) Special Access Codes translations Message delivery is attempted as soon as the message has been securely received from the originator. 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 is used to route the message to the appropriate ocean region, provided that ocean region is served by the ACSE. If the mobile is in an ocean region not served by the ACSE , and if a telex format address has been supplied by the calling mobile, the message may be routed over the telex network. In general non telex addresses are not routed via the terrestrial network, and such messages are therefore rejected. Whether or not mobile to mobile messages, where the destination mobile is not in an ocean region served by the LES, are delivered, is dependant on the values in the 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 translations are 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 - Online Processing - Database Access - Message Handler Database Access). The operator is able to perform the following :
8-9

Message Handling

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

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 validation on 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 modems connected 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 translations are performed. The other entries required in this table are : Country code string - as received from the mobile

8-10

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

Message Handling

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. This is a further qualifier for matching the address information as received from the mobile with the translation to be performed. There is no equivalent in the address information passed on to the terrestrial network. Action substitution - set to true if the substitution string is to be used or false if no substitution is required. If the country code is not to be passed on to the terrestrial network, set the substitution string as blank 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 direction and 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 retry cycle is entered. The number and frequency of retries is variable, depending on the reason for failure. For example, if a terrestrial address is busy, several repeat attempts can be made at short intervals until delivery has been achieved. On the other hand, if the address is not valid, repeat attempts are not of any value. If messages cannot be delivered after the retry sequence has been exhausted, a Non Delivery Notification 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 a non-delivery notification cannot itself be delivered, typically this would be because a terrestrial address could not be ascertained, the non-delivery notification will be forwarded to a spill-out address. This is usually the ACSE operator, who should then take steps to advise the originator, if possible, by other means. Messages queued on an active queue by the message scheduler will be periodically checked to ensure that they are not stuck. Any message queued for a period greater than the default of 600 seconds will be checked. If the time queued is greater than an expected maximum, a function of the message type and length, then an event is generated. See the MSCH events in chapter 11 for details of the event and any necessary operator actions. On the satellite side, delivery may be delayed if an interruption occurs on the TDM channels, messages 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 discarded and 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
8-11

Message Handling

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

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 a message for that addressee which is in the course of being sent. If there is, the second message is held in a queue, until the first message delivery is completed, in order to allow the first message delivery to be completed. Message delivery can take place to one or more recipients. Figure 8-5 outlines the steps which the ACSE takes to deliver a message, whether it be to a mobile or a terrestial address, to a single recipient. The case of multiple-addressed messages is described later. Message delivery starts when a complete message is stored securely in the system and is complete when either : a message has been sent to a mobile which has returned an acknowledgement packet 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 message. If the first attempt succeeds, the fact is recorded in the database by entering the appropriate Call Completion Code. If the delivery was not successful, the ACSE makes one or more repeat attempts, depending on the failure cause in the first instance. In the particular case of maritime distress messages and alerts, the repeat attempt is made immediately, using the secondary address. The primary and secondary MRCC addresses are defined using the Maritime Distress Destination Definition form (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 address in turn. Delivery to the first address is tried and, whether successful or not, delivery to the next address is immediately tried. A separate call completion code is entered for each address. Reattempts, when necessary, will be tried after all addresses have been tried once. This cycle is repeated until all attempts to all addresses are exhausted and call completion codes are entered against 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 section 8.2.6 Message Delivery. Use the Call Record Summary Display form to confirm this (SOC Forms - Message Handler Menu).
8-12

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

Message Handling

MESSAGE FOR DELIVERY

ATTEMPT DELIVERY

NO
SUCCESS

YES

NO

PDN REQUESTED

MAKE ANOTHER ATTEMPT ?

YES

YES

NO

SEND PDN

SEND NDN

DELAY

TRANSACTION COMPLETE

Figure 8-5. Message Delivery cycle

8-13

Message Handling

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

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 Full General to access this display.) The messages can be cancelled by using the Cancel function key. If the message is not actually stuck on the satellite, the cancel instruction will be rejected and the operator 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 the circuit should be cleared manually the handling of the call has been transferred from one part of the system to another while the operator was requesting information about it. In this case, check the summary 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 by returning 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 the ACSE to the FAX PC, which makes the PSTN connection to the called address(es) and performs the 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 possible to 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 a given message will be transmitted. In general, the translations required between the address from the mobile and the terrestrial route are 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 complex analysis process in the software has been developed. This analysis process is based on looking for those exceptions first; the forms which configure the analysis reflect those exceptions. Some thought is therefore necessary to determine how the analysis should take place before the configuration is entered in the database. Care should also be exercised when adding new routes; wherever possible a new route should be tried out as soon as 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. In general, it is only necessary to enter a subset of the address, e.g. a route selection for all addresses beginning 581 can be set up with one entry, as explained below.
8-14

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

Message Handling

Before any route translations are entered, they should all be listed and an offline record of them should be retained. Decide the order by determining the most precise exceptions first. This example should illustrate the principle. Take the first three digits of the address as presented from the mobile with the routing to be as follows: 111 directs the message to route 1 112-119 directs the message to route 2 120 onwards directs the message to route 3. The most precise exception is the address for route 1, the next that for route 2. The following entries made in the following order will achieve the desired result: entry 1 entry 2 entry 3 111 ---> route 1 11 ---> route 2 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 entry 2 entry 3 entry 4 111 ---> route 1 112 ---> route 4 11 ---> route 2 all ---> route 3

In fact, entries 1 and 4 could be in either order - if subaddress 112 is more likely than 111 then the ordering 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 subaddress 112 is to be inserted into the table, the operator will have to shuffle the existing entries further 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 existing ones. This may be done by treating the table entry numbering like BASIC program line numbering, that is to make the first entry 10, the second entry 20, the third 30, etc. If it is necessary to add an entry between, say 10 and 20, number 15 could be used. This method is also recommended 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 the same subaddress match. Otherwise, the next entry field is given the same value as the entry itself. The new entry could be inserted as follows :

8-15

Message Handling

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

Before: Entry entry 10 entry 20 entry 30 After: Entry entry 10 entry 15 entry 20 entry 30 Subaddress 111 112 11 all Next entry 10 15 20 30 Route 1 4 2 3 Subaddress 111 11 all Next entry 10 20 30 Route 1 2 3

The full benefit of this method may be observed if a secondary back-up route is introduced for sub-address 11 only, say route 5. In this case the table would changed to: Entry entry 10 entry 15 entry 20 entry 30 entry 40 Subaddress 111 112 11 all 11 Next entry 10 15 40 30 40 Route 1 4 2 3 5

To summarize, the routing is performed on the minimum number of entries necessary by first looking at the most specific cases. The operator should now be able to set up the Terrestrial Routing Definition 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 required in the database are : Address_Format Subaddress Subaddress_Offset Subaddress_Length Address_Ext Address_Ext_Offset Address_Ext_Length Entry_Index Next_Entry_Index Route_Number "TELEX" "" 1 0 "" 1 0 1 1 1

The Next_Entry_Index is the same as the Entry_Index, so that this routing table entry is taken as being 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 the ability to support alternate routing. For example, if Telex messages should be delivered by X400 primarily, but by Telex if no X400 routes were available, then the following two entries would be required:

8-16

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

Message Handling

Address_Format Subaddress Subaddress_Offset Subaddress_Length Address_Ext Address_Ext_Offset Address_Ext_Length Entry_Index Next_Entry_Index Route_Number Route number 200 is an X400 route. Address_Format Subaddress Subaddress_Offset Subaddress_Length Address_Ext Address_Ext_Offset Address_Ext_Length Entry_Index Next_Entry_Index Route_Number Getting back to the original example,

"TELEX" "" 1 0 "" 1 0 1 2 200

"TELEX" "" 1 0 "" 1 0 1 2 1

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 the address 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 PSTN addresses beginning with 0441908 get routed to route 10, ones beginning with 044 get routed to route 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 need three entries: Address_Format Subaddress Subaddress_Offset Subaddress_Length Address_Ext Address_Ext_Offset Address_Ext_Length Entry_Index Next_Entry_Index Route_Number Address_Format Subaddress Subaddress_Offset Subaddress_Length Address_Ext Address_Ext_Offset Address_Ext_Length
8-17

"PSTN" "0441908" 1 7 "" 1 0 1 1 10 (Local route) "PSTN" "044" 1 3 "" 1 0

Message Handling

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

Entry_Index Next_Entry_Index Route_Number Address_Format Subaddress Subaddress_Offset Subaddress_Length Address_Ext Address_Ext_Offset Address_Ext_Length Entry_Index Next_Entry_Index Route_Number

2 2 11 (National route) "PSTN" "" 1 0 "" 1 0 3 3 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 must have 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 will require the following routing table entry: Address_Format Subaddress Subaddress_Offset Subaddress_Length Address_Ext Address_Ext_Offset Address_Ext_Length Entry_Index Next_Entry_Index Route_Number "CNID" "" 1 0 "" 1 0 1 1 999

Note 1: if the DNID number is not known by the LES, an NDN will be returned to the originating mobile 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 routes may be defined. This must be organised for the LES so that each route number is unique. To simplify tracking of the route numbers used, the following convention, which allows plenty of capacity 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-18

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

Message Handling

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 route numbers 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 numbers to ensure that duplication does not occur. The Terrestrial Routing Definition form (SOC Forms - Message Handler - Message Routing) is used to enter the translation for mobile originated address information to route number. This form is indexed by the route number. An entry is required for each combination of address type and address extension field which the mobile can present and which the ACSE can handle. This form has been specially designed to allow a number of different routes to be selected depending on analysis not only of the presentation and address extension fields but also by analysis of the address itself. It is possible to access this form directly, but it is safer if the Terrestrial Routing Display (SOC Forms - Message Handler - Message Routing), which displays all the routes already set up, is accessed first. This form can show all entries, or can be limited to a specific range. Also it is possible to display data for specific address formats and routes. Call up the form, enter any of these fields and press First page to see the first ten entries. Use Next Page to see more entries, if necessary. The use of each field is described below. To add a new route, press Define ; to modify or delete an existing one, enter a Y in the left hand column and press Define . This calls up the Terrestrial Routing Definition form. To add a new entry, press Add , enter the data and press Enter . To change an existing entry, enter the index, press Show , make the changes and press Enter . To delete an entry, enter the index and press Delete . The operator will be asked to confirm this action by entering a Y. If only return is pressed, 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 have the following meanings: Entry index : For each routing use a separate entry index. Use the Terrestrial Routing Display to check the entry indices already in use before setting up a new route. This index is used by the operator to keep track of all the routes configured in the ACSE. Address format : as received from the mobile. Use one of the allowable ones as described in Section 8.2.2. Subaddress : for analysis of part of the address field. This can be any number of digits from the address field and is used as a filter on the addresses to direct only selected ones to the route being entered. The subaddress filter does not need to start at the first address; the subaddress offset field (below) can indicate the first digit to which the subaddress field applies. For example, enter 581 to direct only those telex numbers relating to mobiles in the Atlantic East Ocean Region to a particular route. This field is not used for certain address formats. Subaddress Offset : the subaddress filter set in the field above can start at any digit in the address field, as indicated by this field.

8-19

Message Handling

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

Address extension : use this if the routing is dependent on any particular address extension. This field is not used for certain address formats. Address extension offset : this is similar to the subaddress offset and points to the digit in the address extension field where the routing conditions apply. Next entry : this is the link between entries which are alternatives. Normally this field will 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 direct the message to a particular port. The address extension fields which are allowed for each given address format may be displayed using the Address Extension Display (SOC Viewer - Online Processing - Run Reports - Online Database 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 to mobiles can originate from the terrestrial network or from other mobiles. An entry is required in this form for each of the terrestrial accesses, as listed at the beginning of this section, plus one for each ocean region served by the LES. For each routing, this will show whether or not mobile or shore originated messages are allowed and the name of the destination ocean region. The CCITT ocean 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, but since 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 - Online Processing - 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 to make 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 the text 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 the terrestrial network, the service code received is used to select the call completion code entered in the call records. Where the ACSE decides that a call has failed, the software chooses the most appropriate code to enter 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 changes will not alter the basis on which the software chooses the reason code, so only equivalent wording to the original should be used. To alter a code, use the Call Completion Code Definition (SOC
8-20

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

Message Handling

Viewer - Online Processing - Database Access - User Services Database Access). The codes set up, together with the corresponding text, can be inspected using the Call Completion Code Report (SOC Viewer - Online Processing - Run Reports - Online Database Reports). 8.3.6 Alert Routing Strategy Alerts (distress and land) will be routed according to the originating mobile number. Alerts from mobiles numbered in the range 48XXXXXXX to 49XXXXXXX will be routed to the Non-Maritime Distress Destination (sometimes referred to as the Land Mobile Distress Destination) associated with that mobile. Unregistered land alerts will be allocated the number 480000000 and will be forwarded to the destination indexed by the NMDD. Alerts from maritime mobiles (numbered in the range 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 of distress 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 Definition form (SOC Forms - Message Handling - Message Routing). Both a primary and secondary address, to be used in case the first address cannot be reached, can be configured. The address can 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 Show to view the current definition. To change it, press Modify , enter the data and press Enter . If the primary route to the MRCC uses a dedicated trunk telex line, the entry in the Maritime Distress Destination Definition will be that of a telex subscriber. It is then necessary to use the routing tables to ensure that that particular address is recognised and routed on the dedicated distress route, as described in section 8.3.1. In such a configuration, only the primary address should be set up via the dedicated route. The secondary address should use the normal route for mobile to shore traffic; any distress calls will be handled with priority on it. The Maritime Address should only be modified after consultation with the relevant authority handling distress traffic. When a maritime distress alert/message arrives at the LES an event will be raised giving details of the alert/message. The delivery outcome (successful or unsuccessful) of the alert/message will also be reported. The LES will first attempt to route the alert/message to the primary address, and if that address cannot be reached it will attempt to route to the secondary address. If the secondary address cannot be reached the LES will try again to route to the primary address. The LES
8-21

Message Handling

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

will continue switching between the primary and secondary address until all the retry attempts for the respective failure reasons have been exhausted. The LES will not attempt to deliver a binary message to any Telex address, and this applies equally to Maritime distress messages. The LES will attempt to deliver all distress alerts/messages it receives, irrespective of the barred or logged in status of the sending mobile, and includes those mobiles for which address cannot be determined. In the case of of a distress message received from a mobile which is not logged into any ocean region the LES will mark that mobile as logged in, although it must be noted that this will 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 - Message Routing) provides the addresses for each of these destinations. Call up the form, enter the delivery code and press Add for a new entry. Then enter the address information and press Enter . The address is entered in the same format as used for maritime distress destinations, i.e. 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 field in the mobile to shore address. To view an existing entry, press Show . This can then be modified by pressing Modify , entering the 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. A Delivery Code is entered by the operator against relevant mobiles in the Mobile List as the link to the destination. The address corresponding to delivery code 0 has a special function. It is used both as an address for delivery of alert from mobiles which have no delivery code entered in the mobile list and it is also used when valid addresses cannot be reached. It is therefore recommended that the address 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 (SOC Forms - Message Handler - Message Routing). Call up the form and press First Page for the first ten entries. Use Next Page to see other entries. If the primary route to the MRCC uses a dedicated trunk telex line, the entry in the Maritime Distress Destination Definition will be that of a telex subscriber. It is then necessary to use the routing tables to ensure that that particular address is recognised and routed on the dedicated distress route, as described in section 8.3.1. In such a configuration, only the primary address should be set up via the dedicated route. The secondary address should use the normal route for mobile to shore traffic; any distress calls will be handled with priority on it.

8-22

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

Message Handling

8.3.8 Special Access Codes Special Access Codes can be presented directly by the mobile to translate to any network address or to access a leased line. The code itself consists of a 2-6 character string. A Special Access Code 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 MRCC messages to a Leased Line. Such codes should be allocated so that they are not likely to be used by 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 Code Display (SOC Forms - User Services - Special Access Code). Select the form, optionally enter the kind of code - function, route or address (described below), and press First Page . Up to twelve entries are shown. Use Next Page to see more. The display shows the address to which the message 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 accessed via SOC Forms - User Services - Special Access Code. Select one of the following forms, according 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 route alone and no further address information is required. Also it can be used for routing DNID addressed messages. The Special Access Code "DNID<space><space>" must be 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 be sent 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 the following : Oper_Msg - normally mapped onto special access code 33 (SAC33). The message when received causes an event to be raised. The operator can later retrieve the message via the Operator Message Report (SOC Viewer - Online Processing - Run Reports - Run Online Log File Reports - View Log File Reports - Operator Message Report). The operator can specify whether or not to include banner for outgoing delivery message (if applicable). Further fixed functions can be added with software enhancement. Select the form, enter the Special Access Code and press Show to view any entries already set up. Press Modify to change, enter the new value and press Enter to make the change. If no entry is present, press Add , enter the new value and press Enter .
8-23

Message Handling

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

The Special Access Code Route Definition form (SOC Forms - User Services - Special Access Code) allows the specification of a route number for the special access code. Also the operator can specify whether or not to include banner for outgoing delivery message (if applicable) and whether or not presentation code validation rules for allowing routing to take place are is to be followed (if applicable). Use Add , Modify and Delete in the same way as for the Function definition above. For routing to addresses in the terrestrial network, use the Special Access Code Address Definition 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 used and 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 to presentation 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 are listed 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 characters 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 DNID the raw address and the address extension, in the same format as a mobile would present such information. For Route, the route type (TER) and the route number (e.g. the route number of a leased line). Note that at present, it is possible for the user to specify a satellite route for the mapping. No attempt should be made to set up this configuration.

8-24

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

Message Handling

For Function, the current configurations are

"OPER_MSG" which writes the message to the logfile - these messages may be read by the operator by running an Operator Message Report report. This facility is designed so that the operator may deal with such messages when he is able to; for instance messages can be received during the night and handled when 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 satellite services. These are addressed by Special Access Code 33. When the LES receives such a call, 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 same way as any other message to that address the SOC console, in which case an event - MDIR 100 - is raised to alert the operator and the operator can then read the contents of the message using the Operator Message Report (SOC Viewer - Online processing - Run Reports - Run Online Log File Reports - Generate Log File Reports). The report will be printed on the report printer. 8.3.11 Delivery Notifications Once delivery is complete, a delivery notification can be sent to the originator. If a delivery fails a non-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 the Registered 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 a pre-set address, (entered in the ACSE using the Registered User Definition SOC form.) Figure 8-6 illustrates the steps taken for registered terrestrial users. Note that an NDN is a subset of a PDN, so a registered user would only be set up for either NDN or PDN reception. The delivery notification is only sent when delivery to all addresses is complete or when the delivery retry cycle is complete. For unregistered telex messages, the non-delivery notification is sent to an address obtained from the original message. For registered users, the address for delivery notifications is entered in the Registered User Definition form. For non-registered users, i.e. on telex only, the address is derived from the answerback. The operator must configure the translation using the TNIC Definition form (SOC Forms - Terrestrial Interfaces - Telex - TNIC) and can inspect the configuration using the TNIC Display (SOC Forms
8-25

Message Handling

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

DELIVERY COMPLETE

ALL DESTINATIONS WITH SUCCESS CALL COMPLETION CODE

NO

YES

NO

PDN AUTHORISED YES

NO

ADDRESS ENABLED FOR PDN YES

NO

ADDRESS ENABLED FOR NDN OR PDN

YES

SEND PDN

SEND NDN

COMPLETE

Figure 8-6. Delivery Notifications to Registered Terrestrial Users

8-26

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

Message Handling

- Terrestrial Interfaces - Telex - TNIC). In configuring the TNIC translation, the operator should only make an entry for countries which can automatically route telex messages. The Inmarsat identity of X should not be entered. If it is impossible to obtain a meaningful address, or if it is not possible to deliver the delivery notification, the notification is sent to a default address, set using NDN Spill-out Destination Definition (SOC Viewer - Online Processing - Database Access - Message Handler Database Access). To change the address, press Modify , enter the new address and press 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 the TNIC/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 the current time, which are to be displayed. Press First page and then, if desired use the Next Page key, 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 has distress priority, the acknowledgement message will appear in this display, with the same message reference number as the original distress. To view an individual record in detail, place Y in the left-hand column of the summary display and press Full to obtain the Distress Message Full Display (no direct access to this form). Be sure to select the original message and not the acknowledgement, which will not include the contents of the message itself. The form shows the following : incoming call record serial number
8-27

Message Handling

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

message reference number forward and return MES identities MES number call input time EGC details message kind : mobile to shore, shore to mobile, mobile to mobile, EGC delivery call record serial number call delivery time call completion code 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 MES details, only apply to normal messages. The forms described above are limited to showing 512 characters of text. If the distress message exceeds that size, it will be necessary to use one of the following SOC Viewer options, depending on 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 the system up to at least 72 hours after it has been submitted. The Message Status Summary Display (SOC Forms - Message Handling - Message Display) gives the operator the same information. Refer to section 8.4.6 for details of how to search for information about a particular message. After selecting the form, the operator must enter the same information as a terrestrial user, i.e. : registered user PIN, where applicable message reference number submission time - within one hour
8-28

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

Message Handling

select all (shore originated) messages or only undelivered ones After pressing Show , the operator is shown a tabular display of call completion code, call status and message kind, e.g. shore to mobile, mobile to shore, etc. for each destination address. Use the scroll keys, Up arrow and Down arrow , to see the full page of up to 20 destinations. Further details for a single destination can be obtained by selecting the destination with a Y in the left hand column and pressing Full to give the Message Status Full Display (not directly accessible via the menu) which shows : call completion code 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 can analyse 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 qualifiers represent the successive locations in the system through which a message can be considered to pass. Enter the required details and press First Page for a tabular display of eleven entries, for active messages, showing the following : route identity route number ocean region spot identity (for future use) queue type message reference number

8-29

Message Handling

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

entry time scheduled delivery time priority : normal or distress Use the Next Page command as needed for the rest of the data. 8.4.4 Message Details Details of active messages within the system can be viewed on the Message Details Summary Display (SOC Forms - Message Handling - Message Details). This is keyed by a number of fields, 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 First Page to obtain the following details : incoming call record number time of arrival message kind : mobile to shore, shore to mobile, mobile to mobile, EGC message reference number registered user PIN originators address Use the scroll keys, arrow up and arrow down, to see the full page of 20 messages. Press Next Page to see the next 20 messages. To view all the details associated with a message, there are two forms, one of which is tailored to particular types of message. Enter a Y in the left hand column and press either Full General for the Message Details Full General Display or access directly (SOC Forms - Message Handling - Message Details) or Full Specific for the appropriate Message Details Full Specific Display or access directly (SOC Forms - Message Handling - Message Details)
8-30

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

Message Handling

These forms cannot be accessed directly via the menu The Full General Display shows : incoming call record serial number time of arrival message kind message reference number 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 call completion code

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 : incoming call record serial number time of arrival message kind message reference number

8-31

Message Handling

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

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 displayed on a page and use Cancel (with NDN) to cancel the selected messages and generate an NDN for each message cancelled, or Cancel (without NDN) to cancel the selected messages but not to generate NDNs for the messages cancelled. Before the command is accepted the operator will be prompted with "Confirm message cancellation with NDN (Y/N)" or "Confirm message cancellation without NDN (Y/N)". This facility is useful in that it provides an easy mechanism for ridding 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 and delivered, or in the case that the retry cycle is gone through without delivery success, the time that the system gives up attempting to deliver the message.
8-32

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

Message Handling

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) then a single queue entry may have more than one destination (although there still may be multiple queue entries for the message). A delivery will only be resident on one of the above queues at any one time - however duplications may be seen in the message reference numbers in queue entries, because messages addressed to 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 their schedule time expires. An example of such entries would be deliveries to a mobile being rescheduled on the Time queue because the mobile is busy, or an EGC repetition being rescheduled to be delivered when the next transmission (or echo) is due. The entries on this queue are ordered by the entrys Schedule Time. The Token Seize Queue is a queue where scheduled entries reside until the necessary processing 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 of scheduled messages exceeds the number of parallel deliveries that may be made, then the messages remaining to be delivered will wait on this queue until the delivery drivers resources become free. Entries in this queue are ordered by message priority and then by entry time within the same priority i.e. the oldest distress message will be the first off the queue, and the youngest normal message will be the last off the queue. Note that the entry time should not be confused with schedule time; the entry time is the time when the message entered the system; the schedule time is the time when the queue entry should leave the Time Queue, and is only relevant when the entry is on the Time Queue. Because the Token Seize Queue could be extremely long, a route identifier must be provided as an additional selection parameter when viewing either the Token Seize Queue, or All Queue Entries. The Selectable Queue is a queue where entries have the appropriate driver resource allocated for 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 unlikely that 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 all selectable deliveries will be made by the driver within approximately a second.
8-33

Message Handling

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

The Active Queue is a queue where entries reside while the delivery driver is attempting to deliver the message (i.e. Active within the Delivery Driver). The queue entry will stay on the queue for 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 Message Queue 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 figure 8-7. An EGC message with repetitions will have the life-cycle, from a scheduling point of view, as shown in figure 8-8. A delivery may be rerouted for a variety of reasons e.g. failure of a distress delivery attempt, a route becoming available or unavailable. When the delivery gets rerouted, the message will be moved from one route queue to another route queue (i.e. it will effectively jump routes). Note that if a delivery gets rerouted from a route which handles multiply-addressed messages to one which does not, then the number of queue entries for the delivery may increase. The Message Handler Management facility (SOC Viewer - Online Processing - Message Handler Management) provides a message state monitor display, which shows in real time the changes in state undergone by messages as they pass through the Message Handler, which is the central part of the processing software. The display shows the following : incoming call serial number message reference 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 displayed on the screen normally because the screen is not wide enough but can be seen by pressing Pf1 followed by right arrow . Use Pf1 followed by left arrow to return to the original display. Message events (such as the assignment of a message reference number or the failure of a delivery) are saved in the message event history by the Message Handler process and the Message Handler interfaces used by all driver processes. The state changes resulting from these events are recorded in the Message Handler message state record by a recorder task, and are reflected in the message state monitor display, providing an overview of message traffic.

8-34

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

Message Handling

TIME Q

TOKEN SEIZE Q

SELECTABLE Q

ACTIVE Q

DELIVERY BECOMES SCHEDULED

DRIVER DELIVERY RESOURCE ALLOCATED

OR REQUEUE ENTRY REQUEUE ENTRY IF MOBILE DESTINATION AND MOBILE IS BUSY TRANSMITTING

DRIVER ATTEMPTING DELIVERY

DELIVERY ATTEMPT FAILED DELIVERY ATTEMPT FAILED DELIVERY ATTEMPT SUCCEEDED

- REQUEUE (IF RETRY_COUNT > 0) - DELETE ENTRY (IF RETRY_COUNT <= 0) - ENTRY DELETED

[mess_prog_1.eps]

Figure 8-7. Ordinary Message Lifecycle

8-35

Message Handling

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

TIME Q

TOKEN SEIZE Q

SELECTABLE Q

ACTIVE Q

DELIVERY BECOMES SCHEDULED

DRIVER DELIVERY RESOURCE ALLOCATED

OR REQUEUE ENTRY REQUEUE ENTRY IF MOBILE DESTINATION AND MOBILE IS BUSY TRANSMITTING

DRIVER ATTEMPTING DELIVERY

DELIVERY ATTEMPT SUCCEEDED DELIVERY ATTEMPT SUCCEEDED DELIVERY ATTEMPT FAILED DELIVERY ATTEMPT FAILED

- 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

[mess_prog_2.eps]

Figure 8-8. EGC Message Lifecycle

8-36

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

Message Handling

The messages for which message events have been recorded are displayed one per line. The display may be scrolled by pressing the arrow keys. Further information regarding the use of the monitor may be found by pressing help within the facility 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-9 summarizes the steps. The process would typically be necessary when a user contacts the LES to enquire about delivery of a particular message. The starting point is therefore that the operator knows the message reference 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 information could be missing. Details of the call may be found via SOC Forms, if the message is less than 72 hours old, or via a Call 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 72 hours. It can be used to go directly to the message details if the MRN and TOA are known and are correct, or it can be used to scan through all the possible messages which meet the given criteria. MRN and TOA known If the MRN and TOA are both provided, then go to the Message Status Summary Display. Enter MRN, 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 performed on a per-destination basis for the message by using the Message Status Full Display. Enter a Y against the desired message and press Full . This will allow the operator to give a destinationby-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 the relevant 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 deleted from 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 method described below. If the customer is really unsure, then follow the steps below first assuming the MRN is correct, and then assume the TOA is correct. The PIN used for the message submission may prove useful too - this should strictly be requested anyway to provide a level of security. Only MRN or Only TOA Provided

8-37

Message Handling

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

Call Analysis

Message Reference Number know (MRN) + Time of acceptance (TOA)

Message Status Summary Display

Completed delivery

Still attempting delivery

Cannot Find

Message Status Full dislay - details for each destination

Info already available on Message Status Summary Display

MRN or TOA wrong Older than 72 hours Details not available. Use Call Record Report

Choose MRN or TOA whichever is more likely to be correct

Use as selection to obtain Message Full Display

If not Required message

Choose another selection

Figure 8-9. Call Analysis

8-38

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

Message Handling

If the status could not be found and the message is thought to be active, the Message Status Summary Display can be used with either the MRN or the TOA as the selection key - DO NOT USE BOTH (this combination has already been proven to be incorrect). If the PIN was provided by 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. The easiest way is to perform a billing run and to see the billing records for the calls, but this can take some time. However, with the option to run manual billing under the new autobilling process, this no longer applies. A manual billing run can be performed on immediately closed log files, using carryover data if required. Data can be extracted within minutes rather than hours as might previously have been the case. If the requirement is to see details on a call where the approximate time of the call is known (within a 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 File Utilities). Identify the log file(s) names required, if present, or else copy from on-line area or restore from archive 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:
8-39

Message Handling

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

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. The list 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 the wild card file specification * and the start and end times. This will take more processing time as all log files that are visible to the lister will be searched, but may be easier if calls resulting from the original 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 which are 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 start and 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 and the System Usage Statistics report provides a regular printout of traffic. The System Usage Display window provides both graphical and numeric information as a default display on the SOC. The display can be iconised if it is not wanted on the screen, but is not accessed through the normal menu structure for SOC forms. The display available is dependent on how the system is configured on installation. The system presents each display in sequence at intervals between 1 and 86400 seconds, although it is inadvisable to have intervals of less than 30 seconds as this puts a heavy processing load on the system. The operator can also exercise some control over the current SUD display, by left-clicking the mouse on the background screen (as described in section 2.5). The choices that control the SUD are: 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, it will continue to be updated, as will all the other (unseen) displays. The Release option is only used on a held display. The other two options are self explanatory. The display need not he held before 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-40

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

Message Handling

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 following 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 service for 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 supported ocean 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 to yellow when the percentage exceeds 60% and red when exceeds 80%. Note that when the SOC is 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 capacity and therefore includes any capacity out of service in the occupied category.
8-41

Message Handling

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

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 channels occupied since the LES was last restarted. It cannot be taken as an instantaneous indication of the telex usage. The log data store gives a graphical indication of the percentage of available space currently used for 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 disks L = low water mark F = free blocks on storage disks

The low water mark is the amount of disk space which is reserved for the Online Database and the 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 each CCC 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 will be 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-42

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

Message Handling

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 last hour and last 6 minutes: Successful Calls Failed Calls Mean Successful Delivery Time Mean Failure Delivery Time
8-43

Message Handling

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

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 minutes for: 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-44

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

Message Handling

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 the last 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 the operator) 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 messages details of the oldest message in the queue : arrival, route number, ICR serial number and message reference number message counts : successful and failed deliveries, positive and non-delivery notifications, status enquiries, EGCs, polls, data reports, DNID addressed messages and distress messages 8.6 Message Records There are a series of online and offline forms and reports which show the messages being handled by the system and those which have been handled by the system. Online reports are available from the online database for messages not more than 72 hours old or those whose details are contained in the online logfiles. Offline reports are obtained from logfiles loaded into the offline database and are described in section 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. a call/message coming in and one going out :
8-45

Message Handling

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

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 the call records of active calls within the system. This displays an area of memory which is used to maintain the active call record and hence, from time to time, it may be possible that Unknown call records 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 call completion code Press First Page to obtain : active : yes or no direction : I for incoming, O for outgoing driver : satellite, trunk telex, subscriber telex, leased telex, X.25 call direction : terrestrial to LES, LES to terrestrial, LES to mobile, mobile to LES call priority : normal or distress time message started call completion code A full display of the call record can be obtained by selecting one record by placing a Y in the left hand column and pressing Full General . The two forms described below take a snapshot in time and therefore may only show part of the picture. 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, the Call Record Full DCR Display will be shown. Both will show the following :
8-46

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

Message Handling

active : yes or no direction : I for incoming, O for outgoing driver : satellite, trunk telex, subscriber telex, leased telex, X.25 call direction : terrestrial to LES, LES to terrestrial, LES to mobile, mobile to LES call priority : normal or distress time message started call completion code 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 in over 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 message reference number 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 an error in the satellite side protocols. After selecting either the Call Record Full ICR Display or the Call Record Full DCR Display for the stuck message, press Cancel . The operation will take 2 or 3 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 to cancel other messages will be rejected and the operator advised.

8-47

Message Handling

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

8.6.2 Online Call Record Reports The second type of report will use the online log files. These reports will list the Incoming Call Records (ICRs) and Delivery Call Records (DCRs) that meet the specified criteria. The reports generated from the message details tables of the database will operate substantially faster than the 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 to a 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. The editor 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 PF1 W , then PF1 , P Write report to new file Annotate the report
8-48

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

Message Handling

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 generate them use the Message Status Report (SOC Viewer - Online Processing - Run Reports - Run Online 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 and mobiles. For the LES to Mobile Message Report the optional selection criteria are: Start time End time Message reference number PIN Destination mobile number All messages or only those undelivered defaults to earliest defined time defaults to latest defined time defaults to all defaults to all defaults to all defaults to all messages.

The report consists of one line entries, ordered by message reference number which show date/time of arrival, PIN (if registered user), destination mobile, ocean region, call completion status, 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 to Mobile 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 End time Message reference number PIN All messages or only those undelivered defaults to earliest defined time defaults to latest defined time defaults to all defaults to all defaults to all messages.

The report consists of one line entries, ordered by message reference number which show date/time of arrival, PIN, EGC sequence number, ocean region, call completion status, explanation of the status, number of completed broadcasts and number of outstanding broadcasts for each EGC message. For the Mobile to LES Report, the optional selection criteria are: Start time
8-49

defaults to earliest defined time

Message Handling

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

End time Message reference number Originator mobile number Destination type All messages or only those undelivered

defaults to latest defined time defaults to all defaults to all defaults to all defaults to all messages.

The report consists of one line entries, ordered by message reference number which show date/time of arrival, origination mobile number, destination format, destination address, call completion 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 Up Arrow and Down Arrow to scroll through the display. To exit, press pf1 numeric 7 and type exit at the prompt. The operator is then invited to answer Yes or No as to whether the report is printed. The menu is then re-displayed. 8.6.5 DNID Report The DNID report is generated using the DNID Report option from (SOC Viewer - Online Processing - Run Reports - Run Online Database Reports). The operator can select a range of DNIDs or ALL DNIDs, one PIN or ALL PINs. The report shows the DNIDs, their PIN allocation and the 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 - Online Processing - Run Reports - Run Online Database Reports).The operator can select a range of ENIDs or ALL ENIDs, one PIN or ALL PINs. The report shows the ENIDs, their PIN allocation and the date/time allocated. 8.6.7 Log File Reports SOC Viewer provides means to generate, view and print logfile reports. To generate these reports use Generate Log File Reports (SOC Viewer - Online Processing - Run Reports - Run Online Log File Reports). 8.7 Recovery from Failures in Message Handling This section describes how to overcome a problems with traffic handling. Some of the actions described are drastic, but may be necessary to restore traffic as quickly as possible in the circumstances. In the event of a complete failure of the system, a system restart will be necessary, as described in 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-50

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

Message Handling

8.7.1 Satellite Call Failures Satellite calls may fail over a single TDM, a single rack or all racks. Figure 8-10 shows the operator actions in the case of satellite call failures. The operator, when following the steps, will make 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 in service 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 into service. 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 should take approximately 30 seconds) the TDM can be tested. Calls Failing On A Single Rack. Switch the Channel Unit FEPs for the affected rack using the FEP Management form (SOC Forms - System Control). This will cause all the TDM groups associated with that rack to be initialized. Wait until the channel unit cards 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 and clear a failure with this symptom. After each step make test calls to ascertain if the satellite 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 Definition form (SOC Forms - Satellite Interface - Satellite Logical Channel Menu). Use the TDM Rx Logical Channel Definition form (SOC Forms - Satellite Interface - Satellite Logical Channel Menu) to determine the frequency of the TDM Rx and so identify the TDM group. If the TDM Rx is displaying "A", then spare out the TDM Tx card for the TDM that is generating timing. Use TDM Tx Logical Channel Definition form (SOC Forms - Satellite Interface - Satellite Logical Channel Menu). Switch the MTMs in the first channel unit rack. This is achieved using the Manual Clock Select switch, described in Table 3.2 of reference [3]. Check the elements of the RF chain, to ensure that signals are being received and transmitted to and from the satellite. If satisfied that none of the above steps have cleared the problem, then perform a BAP switchover. This operation is described in section 10.1.2.

If the problem persists, then contact HNS.

8-51

Message Handling

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

SATELLITE CALLS FAILING

SPARE OUT TDM Rx CARD

CHECK HARDWARE COMMS ETC.

No

CALLS STILL FAILING? H/W OR COMMS FAILURE Yes SPARE OUT TDM Tx CARD Yes No Yes

TAKE CORRECTIVE ACTION

CALLS FAILING ON A SINGLE TDM No CALLS STILL FAILING? No

Yes

TAKE TDM GROUP OOS

Yes

CALLS FAILING ON ALL RACKS

BRING TDM GROUP BACK INTO SERVICE

SPARE OUT TDM Tx CARD No

WAIT FOR TDM TO RECONFIGURE

SWITCH CU FEPS No CALLS STILL FAILING?

Yes SWITCH MTMs IN RACK 0

CALLS STILL FAILING?

No

No

CALLS STILL FAILING?

Yes

SWITCH BAPS Yes

No

CALLS STILL FAILING?

Yes CALLS STILL FAILING?

CHECK RF CHAIN

Yes

CONTACT HNS

No FINISH

Figure 8-10. Recovery Procedure when Satellite Calls Are Failing

8-52

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

Message Handling

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 the external network then the network service provider should be contacted. However there are steps that the operator can take to establish if the reason for message failure is within the ACSE, and then 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 to this diagram. Where the operator checks that the DEMSAs are OK (back in service) the operator should be confident that X.25 calls are being successfully routed. 1. Access the DEMSA Management form SOC Forms - System Control Menu. If the form fails and a Time Out error appears on the SOC then there is a probable fault with the X.25 driver and the problem should be reported to HNS. 2. Using the DEMSA Management form, check that the DEMSA pair(s) showing problems have one DEMSA set as a master and all DEMSAs are INS. If the Master appears 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 display at the rear. Generally, either neither or both DEMSAs will have failed (if the master fails then the standby DEMSA should take over as master). If the DEMSAs appear to be physically working go to step 8. 4. Power cycle the DEMSAs. It will take several minutes for the DEMSAs to initialise and be able to transmit traffic. 5. If the Master DEMSA fails to power up, and the problem is obviously hardware, then call 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 the DEMSA(s) into service. Continue with these steps if this does not remedy the problem. 9. After first ensuring both DEMSAs are running, switch the DEMSAs, as described in section 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 to HNS. 11. Check that each line is ON. If any are not then set them to ON. If any fail to do so then call HNS. 12. Attempt to bring the DEMSAs into service using the DEMSA Management Form. If either 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 Management SOC form, perform a switchover of the TIC, using the FEP Management SOC form, and then put
8-53

Message Handling

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

START

BRING UP DEMSA MANAGEMENT

FORM TIME OUT


No

Yes

CHECK DEMSAs INS

Yes

DEMSA INS

No

PHYSICALLY CHECK BOTH DEMSAs

DEMSAs FAILED

Yes

SWITCH DEMSAs
No

No

DEMSA(S) OK

BRING DEMSA INS

POWER RESET DEMSAs

FORM TIME OUT


No

Yes

1
Yes

OBVIOUS H/W FAULT

No

DEMSA MASTER POWER OK

No

DEMSA(S) OK

Yes Yes

Yes

1
No DEMSA STANDBY POWER OK

No

BRING UP X.25 LINE MANAGEMENT

CONTACT FIELD SERVICE


Yes Yes

FORM TIME OUT


No

1
Yes

CHECK LINES ARE ON

DEMSA(S) INS

No

BOTH DEMSAs OK

No

LINE ON

No

BRING DEMSAs INS

Yes

Yes

Yes

ENABLE LINE CONTACT HNS

No

ALL LINES CHECKED

Yes

LINES OK

No FINISH

Figure 8-11. Recovery Procedure when X.25 Calls Are Failing

8-54

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

Message Handling

the lines back into service. Make a test call to confirm that communication is re-established. If problems 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 affected line out of service and then return it to service.
[opg8_inc2.mss] [opg8.mss]

8-55

User Services

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

INCOMING TELEX CALLS FAILING RECOVERY PROCEDURES

INCOMING TELEX CALLS FAILING

MAKE ALL INCOMING LINES OUT OF SERVICE

MAKE SINGLE INCOMING LINE IN-SERVICE

MAKE A TEST CALL

CHECK SIGNAL USING LINE ANALYSER


NO NA SIG L
SIG NA L

TELEX EXCHANGE PROBLEM

SWITCH THE BAPS

REBOOT MASTER TIC

OT ON S DITCH P BA SW

CHECK THE BAP SWITCH


SW IT OK CH

STOP OLD MASTER BAP

BRING ALL LINES IN-SERVICE

RESTART BAP

ic_fail.eps

Figure 8-12. Recovery Procedures for Failure of Outgoing Telex Calls

8-56

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

User Services

OUTGOING TELEX CALLS FAILING RECOVERY PROCEDURES

OUT-GOING TELEX CALLS FAIL

TAKE ALL LINES OUT OF SERVICE

SWITCH TICS & PUT LINES IN-SERVICE

DO A TEST CALL
OD GO
BA D

REBOOT OLD MASTER TIC

SWITCH THE BAPS

REBOOT MASTER TIC

CHECK THE BAP SWITCH


T NO DO H PS ITC A B SW SW IT OK CH

STOP OLD MASTER BAP

O.K.

RESTART BAP

og_fail.eps

Figure 8-13. Recovery Procedures for Failure of Incoming Telex Calls

8-57

User Services

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

SELECT TELEX TRUNK CIRCUIT DISPLAY

all lines OK Lines stuck in B/W busy or retest . OK

SELECT TELEX TRUNK CIRCUIT MANAGEMENT

MAKE CIRCUIT OUT OF SERVICE

MAKE CIRCUIT IN SERVICE

Tlx_Fail.eps

Figure 8-14. Recovery Procedure when Telex Lines Stuck in Retest or Bothway Busy

8-58

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

User Services

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 cycle of a mobile. This is illustrated in figure 9-1, which shows for completeness all the possible states from the initial construction of the mobile to its use for in service. These states can be summarized as follows: build - where the serial number is allocated by the manufacturer and the forward and return identities are allocated by Inmarsat for all Inmarsat-C mobiles. installation - registration in the LES and commissioning tests (PVT) performed. The mobile can now be used in the network. Use - for making and receiving calls. During this time the mobile may be repeatedly switched on and off and may move from one ocean region to another. It may also go faulty 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 of Call 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 responsible for adding mobiles to this list. The complete mobile list can be very long - tens of thousands of entries - so a number of qualifiers are available. Where it is necessary to view a long list of mobiles, it is advisable to print this on the report printer rather than attempt to view it on the SOC screen. The mobile list can be viewed on the Mobile List Display (SOC Viewer - Online Processing - Run Reports - Online Database Reports). The details of the output are shown below, together with the qualifiers, which for this report, are extensive. All the qualifiers are included in the report as a quick reminder of what was selected. 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)
9-1

User Services

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

LES DATABASE
MANUFACTURE MOBILE DOES NOT EXIST
NOT REGISTERED

MOBILE STATUS SERVICE CODE (CN 95, F131)


NP

BUILT & ALLOCATED SERIAL No.


DISTRESS ALERT

NOT REGISTERED

NP

DISTRESS ALERT

ALLOCATED MOB. NUMBER & FID RID

NOT REGISTERED

NP

INMARSAT DECOMMISSION ENTERED IN NCS DB


FAIL 3 CONSEQ. PVT's
REG PKT. 'NOT COMMISSIONED'

MOBILE REGISTERED IMMEDIATELY

ENTERED IN LES DB
PASS PVT. DISTRESS ALERT

NOT COMMISSIONED, NOT IN OR

NA

FAIL PVT

ANY STAGE

COMMISSIONED
AUTOMATICALLY LOGGED IN BY NCS

MOBILE IS LOGGED IN IMMEDIATELY

NETWORK

LOGGED IN OR

IN OR <REGION>, IDLE

SUPPORTED OR UN-SUPPORTED OR

SUC ABS

(NORMAL or DISTRESS)

MAKE CALL

or CALLED

IDLE

DISTRESS ALERT

CALL IN PROGRESS
NCS BARS

IN OR <REGION>, BUSY

OCC (call should complete as SUC when mobile becomes IDLE)

LOG IN / DISTRESS ALERT / PASS PVT

NCS BARRED
LES BARS NCS UNBARS

NCS BARRED, NOT IN OR

DISTRESS NA NORMAL NA

LES UNBARS

DISTRESS MESSAGE MES-LES NCS BARS

LES BARRED
LES BARS DISTRESS MESSAGE / ALERT MES-LES LES UNBARS LOG OUT

LES BARRED, NOT IN OR, or IN OR <REGION>, IDLE

DISTRESS NA (IF NOT IN OR) DISTRESS SUC (IF IN OR) NORMAL NA

LOGGED OUT
POWER ON / FIX POWER DOWN / FAULT

NOT IN OR

ABS

DISTRESS MESSAGE MES-LES

POWERED OFF / FAULTY


POWER ON POWER DOWN

NOT IN OR

ABS

POWER OFF

IN OR <REGION>, BUSY or IDLE

DER

FIXED

FAULTY & RESPONDING

FAULT

IN OR <REGION>, BUSY or IDLE

DER

FIXED

FAULTY & NOT RESPONDING

IN OR <REGION>, BUSY or IDLE

DER

Figure 9-1. Mobile State Life Cycle

9-2

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

User Services

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 a number, followed by %; for example to view all the mobiles beginning with 4931, enter 4931% at the mobile number prompt. The screen display is shown in Figure 9-2. This needs to be viewed in 132 character mode, so press Do . Selection Criteria Mobile Number Spot ID Current NCS Region Forward ID Return ID In Ocean Region Commissioned Barred Busy Regd User PIN Values 40000000-499999999 0-255 0-3 up to eight digits up to eight digits Yes,No,Both Yes,No,Both Yes,No,Both Yes,No,Both eight characters Default Default is ALL Default is ALL Default is ALL Default is ALL Default is ALL Default is Both Default is Both Default is Both Default is Both 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 MES Status 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 headings:
9-3

User Services

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

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 mobile number (9 digits). Press Show to inspect current information, Delete to remove an entry, or Add to 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 combined EGC or message handling (switchable to ECG receive only) and 3 for separate EGC 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 to the mobile. If the operator, in his capacity as a superuser, is the only person authorised to download ENIDs and DNIDs, this field should be left blank. presentation capabilities - ITA2 and data for the satellite side transmission path. The default values are N and Y respectively.

9-4

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

User Services

delivery access code - this is optional and is only for land mobiles. It specifies the destination for non-maritime alerts. If the operator wants to change the LES set data, press Modify to access the the Mobile Management form (SOC Forms - User Services - Mobile Users). This form is of the same structure as the Mobile Definition form, in that the display is the same, but only allows entry for a restricted 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 Modify again, enter the new data and press Enter . Warning: The operator may only modify a mobiles definition when it is idle, i.e. when the busy flag is set to N. After a modification has been made, a Show should be performed to ensure that the changes have been made and that the mobile is still idle. If the mobile became busy whilst its definition was being modified, any modifications made may then be lost. If after having modified the mobile definition, and upon entering the change, a database message appears to the effect that the data has not been successfully entered, it may be necessary to repeat the operation. The reason for losing the change in the first place is that between the original show of data and entering the change that database entry has been modified because of satellite activity associated with that mobile. 9.1.4 Barring of Mobiles The following procedures provide a quick mechanism for barring/unbarring selected mobiles in the mobile list. It is assumed that this procedure would not normally be invoked in the case of normal operation. It could be useful when the LES has been operating for a trial period with an incomplete database 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 flag is taken as FALSE and the mobile is not barred. When set to 2, the flag is taken as TRUE and the mobile is barred. NOTE: If the mobile is busy when the LES operator bars or unbars it the change will not be affected 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 = 2 2> Return 1> exit
9-5

User Services

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

or 1> update Mobile set Barred_by_ACSE = 2 2> Return 1> exit 9.1.4.2 Unbarring Site Mobiles It is assumed that the BAP is not running but that the ONDB_SQL server is. Mobiles can be unbarred by using one of the following commands, depending on whether the mobile was system barred or ACSE barred :1> update Mobile set Barred= 1 where Mobile_Number=xxxxxxxxx 2> Return 1> exit or 1> update Mobile set Barred_by_ACSE= 1 where Mobile_Number=xxxxxxxxx 2> Return 1> exit 9.1.4.3 Automating the Barring and Unbarring of Mobiles It is assumed that the BAP is not running but that the ONDB_SQL server is. For simplicity the following assumes that the Barred_by_ACSE flag is to be used for the barring of mobiles. A SQL file can be generated to bar all the mobiles and then unbar those to be used on site. A typical example might be :/* file to bar all mobile, then unbar site ones */ update Mobile set Barred_by_ACSE = 2 go update Mobile set Barred_by_ACSE= 1 where Mobile_Number=491234567 go update Mobile set Barred_by_ACSE= 1 where Mobile_Number=491111111 go checkpoint go /* end of file for barring mobiles */ It should be noted that only two mobiles are illustrated above. The filename might typically be SITE_MOBILE_DEFS.SQL and the command to action the SQL file is :$ ondb_load SITE_MOBILE_DEFS.SQL

9-6

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

User Services

9.1.5 Maintaining the Mobile List The operator can use the Mobile Definition form to repair single corrupted entries or set up test entries. It is also possible to delete mobiles using the Mobile Deletion form (SOC Viewer - Online Processing - 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 are followed. 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 identifies the users and ensures access security to enhanced services. The registered user database as configured here will use information supplied to the ACSE operator from elsewhere in the organisation. To add a new user, follow the steps below. Use the same procedure to change the attributes of an existing one. Any changes made to the registered user database become effective at the next access made by the 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 of services 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 confirm that 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 a separate administrative function) the operator should press Add for a new entry or Show for an existing one. To change an existing one, Modify can then be used. To delete an existing user, press Delete . Note 1: Although no checks are made on the characters which make up a PIN, other than they are alpha-numeric, it is advised that no new PIN is created which ends in X. This is because of the special use of X in batch mode access by the terrestrial user and the conflict when both PINs
9-7

User Services

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

<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 the operator typing a PIN, provided that that data has not been altered in any way. This provides a quick reference to the information which is expected in each field but does not affect the operation of the form in any other way. Note 3: DNID zero is allocated to the predefined SYSTEM PIN. The SYSTEM PIN should not be deleted 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 user name, for example a person within a company, or as user name could be entered in default. Note 1: the fields which are part of General Information are only of use to the ACSE operator, for example to assist system administration. These fields are not used for processing messages and for 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 but will 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 addressees 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, if one 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 be specified. Users authorised for PDNs will automatically receive NDNs as well; it is not necessary to be authorised 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 is recommended that they are completed. address enabled for use for PDNs - set to Y or N according to whether the user should 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 user were addressed by a mobile, i.e. it consists of address format, address and address extension fields. The following address formats are supported: Telex, PSTN, PSDN, Mobile Number, or Special Access Code (providing this translates to one of the previous formats ). For PSTN delivery, T30 must be entered in the address extension field, otherwise the field should be left blank.
9-8

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

User Services

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 for distress 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 record of 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 at distress priority. For EGC messages, the user sets the priority by entering the appropriate 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 , (1 character) will precede the user entered free message text which is part of any Download/Delete ENID or Download Poll command which is originated by the user. The field will be right filled with spaces. 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. If this field is left blank, the caller can supply any answerback; only leave this field blank if universal access is to be granted using this PIN. Password - to be entered initially by the operator as the same as the PIN; this is subsequently 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 to force 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 PDN functions:

9-9

User Services

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

PDN authorised flag N N N N Y Y Y Y

Address enabled for NDNs N N Y Y N N Y Y

Address enabled for PDNs N Y N Y N Y N Y

Message sent None Invalid selection NDN Invalid selection None PDN NDN 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 be accessed by function keys - EGC , Polling or Data Reporting . Note: the ability to enable/disable the EGC, Polling and Data Reporting services is available from the Registered User Definition SOC form. The ability to enable/disable the EGC service is also available from the Registered User EGC Definition SOC form. The ability to enable/disable the Polling service is also available from the Registered User Polling Definition SOC form. The ability to enable/disable the Data Reporting services is also available from the Registered User Data Report Definition SOC form. Using the Registered User NUA Definition SOC form (SOC Forms - User Services - Registered Users), the operator may specify up to ten NUA addresses. A full NUA address consists of 14 digits. One of these addresses must match that of the caller using the PIN in order to gain access to the registered user services offered by the LES for that PIN. The operator may specify a partial NUA of less than 14 digits, which can be compared with corresponding digits if an NUA. The digits specified 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 these in 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 either the 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 Y or N which of the following services the user is allowed to originate: General call Group call Urgent Msg/Nav warn rec System message

9-10

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

User Services

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 - User Services - Registered Users). Against the PIN, the user name is shown and the operator must indicate 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 given size and one or more DNID numbers, up to a maximum of 20. The file size is an overall number
9-11

User Services

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

to accommodate all the DNID numbers allocated to the user. Section 9.7 describes how the DNID file sizes can be determined. For each DNID number entered the following corresponding data must also be set up: Randomizing Interval - used as part of the Satellite Driver Protocol associated with time of arrival of DNIDs, enabling reports for different DNIDs to arrive at different times, 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 file owner. FWD_ONLY, i.e. data is queued for immediate delivery to the corresponding X.121 address. If delivery is unsuccessful the data is discarded. FWD_OR_STO, i.e. as FWD_ONLY except that if delivery is unsuccessful the data 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 either the normal delivery route (i.e. shared with the delivery of store and forward messages) or a separate route set up and reserved for immediately forwarded DNID reports. X121 Address - X.121 address used for immediate forwarding. The X.121 address must be the full international address, beginning with the DNIC used for international calls, as would be entered by a mobile user or foreign subscriber. The X.25 driver performs any address substitution required before connecting to 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 be set up. The X25 drivers normal delay before sending the clear packet acts as a minimum 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 User Display (SOC Forms - User Services - Registered Users). This display is keyed to a users name. The operator should enter the name, in exactly the correct form matching upper and lower case letters. As well as the PIN, this form shows a contact name and telephone number in case the operator 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-12

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

User Services

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
9-13

User Services

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

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: Selection Criteria Registered user PIN User barred Values 8 characters Yes, No, Both Default ALL Both

Figure 9-3. Registered User Summary Display Selection The Registered User Full Display (SOC Viewer - Online Processing - Run Reports - Online Database Reports) is selected by PIN and shows all the details listed above on the Summary Report, 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 file had 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-14

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

User Services

Selection Criteria Registered user PIN User barred DNID

Values 8 characters Yes, No, Both 4 digits

Default ALL Both 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 by Inmarsat may be used. DNIDs in the range 1-32767 may be allocated by an LES (note a dual ocean region LES uses only one 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 associated with the allocation of ENIDs and DNIDs and the distribution to registered users and Mobiles. 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) or Polling/Data Reporting (DNID), the fleet owner or service provider may contact the administration and ask for the change to be made. The achieve this the LES operator must generate either an Individual EGC Message for ENIDs or an 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 the form: <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 entered by 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 to mobiles: 1. Allocate the required EGC or Polling services required for the user and enter these details in the operators register. Note the Registered users Name and PIN. 2. Use the Registered User Definition SOC form to ensure that the registered user is enabled for the desired service(s) (if necessary). 3. Use the Registered User EGC Definition, Registered User Polling Definition and
9-15

User Services

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

Registered User Data Reporting Definition SOC forms to further ensure that the services available to the registered user are those required, and that ENIDs and DNIDs 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 users PIN together with the Operators superuser password, as discussed in Section 9.6. This overrides the authorise type checks in the registered user table, although ENIDs and DNIDs must still first be allocated. 6. Select either the EGC or Polling function to download or delete the ENID/DNID to the maximum number of mobiles allowed, ensuring that required parameters (especially 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 number used. If a delivery notification is generated it will go to the address shown in the Registered User Definition SOC form. Note: It is not possible to tell if the poll or the EGC have actually been received and processed by the mobile (unless, for polls, an acknowledgement is requested). A record of the downloads performed by the LES operator could be maintained in an Operator Register. The Operator Register could include information such as: Field Type ID PIN LES ID, Information provider Date Time of operation Mobile no MRN CCC Polling: Subaddress member Sequence Example 1 ENID 12345 12345678 011, 21_character_string 29-SEP-1992 16:00:00.00 412345678 123450 50 Example 2 DNID 23456 abcdefgh 111, 21_character_string 29-SEP-1992 16:00:00.00 498765432 123460 50 000 001 001 Example 3 DNID 23456 abcdefgh 111, 21_character_string 29-SEP-1992 16:00:00.00 498765433 123470 50 000 002 001

Table 9-2. Example extract from the Operator Register


9-16

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

User Services

9.5 Password Update The password used by registered users to gain access to the ACSE can be changed at will by the user. The access is described in the X25 Interface Definition which is included as part of the System Manual, Reference [2]. The ACSE operator can set a parameter to force all registered users in the LES to update their passwords at a preset interval, in weeks. The software as initially installed has no entry, giving an infinite expiry time. If it is desired to set a value, this must be done by directly accessing the database. Log on to the BAP as described in section 12.2 and then use the following commands in 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=1 2> go This is case sensitive. A value of 1 week expiry is illustrated. The maximum expiry period allowed is 255 weeks. For an indefinite password expiry period, delete the Password Expiry entry from the database as follows :1> delete Passwd_Expiry 2> go Exit from the SQL prompt by typing Exit. Note: direct use of SQL should only be undertaken when absolutely necessary as in these operations 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 Supervisor password, to perform certain privileged tasks, such as the downloading of ENIDs and DNIDs to mobiles. This password is set using Change Superuser Password (SOC Viewer - Online Processing - 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 service. 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 using the Data Report File Display (SOC Forms - User Services - Data Reporting). The PIN of the registered user should be entered and First Page pressed to bring the following details on the screen : total number and size of reports total size of reports total free space
9-17

User Services

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

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 and latest data reports together with the delivery route and the delivery action, i.e. autostore, or immediate forwarding (with or without deletion if delivery attempt not successful) Use Next page for more information. If it is necessary to clear all the files displayed on the screen, press Delete all . Alternatively, selective deletion can be achieved by pressing Manage to access the Data Report File Management SOC form. Normally the contents of each Data Report file must be regularly checked and cleared by the owner. The operator can find out how many reports there are in the file by using the Data Report File Management form (SOC Forms - User Services - Data Reporting). Both the registered users PIN and the relevant DNID number must also be entered by the operator. The operator can select all reports of those between two specified times. The operator can also delete all the records in a DNID by pressing Delete . The ACSE database reserves a total of 10 Mbyte of disk space for data report storage. This limit can be increased in consultation with HNS Ltd. Each registered user should be allocated a suitable maximum file size so that disk space is used efficiently. 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 User Data Report Definition SOC form, in blocks of 500 bytes. For any one registered user, no more than 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 - User Services - 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 take several minutes. The results can then also be viewed on the Initiate PVT form.

[opg9.mss]

9-18

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

System Control

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 the two 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, the form 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 Switch key. Processor modes are required to allow a pair of processors to behave as a redundant pair, i.e. the Processor Modes allow the redundant processors to power-up, switch-over and stop in a synchronized 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 been taken out of service. Each redundant processor in the system is composed of one or more processes. As well as having a mode, these processes have a state. The process state allows a processor to switch each of its constituent processes from one mode to another in a synchronized manner. The possible 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
10-1

System Control

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

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 mode and state separately. When a redundant pair of processors power-up, one processor will be instructed to power-up in Master mode, and the other will be instructed to power-up in Standby mode. Each processor will then follow the state transitions as shown in the state transition diagram figure 10-1 A process may fail at any time; this is represented by the fact that the Fail state may be reached from 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 visualize two state transition diagrams next to each other - one which is currently in Master mode and Running state, and the other which is in Standby mode and Running state. A switch-over is represented by the Master BAP moving from Master/Running to Standby/End_Running and the Standby BAP moving from Standby/Running to Master/End_Running. Each processor will go through the states shown to end up at Running, at which point traffic handling will resume. The BAPs 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 the standby 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 few minutes, the precise value being dependant upon the speed of the processor employed. It is also advisable to complete any billing runs before switching BAPs, as there would be a performance degradation on the new master BAP if billing is running. Use the BAP Management form (SOC Forms - System Control) to effect the switchover, which will cause each BAP to transition through the states shown above in section 10.1.1. The progress of the switchover can be followed on each BAP using the BAPOP SHOW STATE command described in section 12.3. The final response to the BAPOP SHOW STATE command will be a list of 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 LES installation. There are two types of switchover: the first is invoked using the Switch key, where the Master BAP becomes Standby and the Standby BAP becomes eventually becomes a Running Master. The second is invoked using the Fail key, where the Master BAP fails and the Standby BAP becomes eventually becomes a Running Master. In both cases the operator is prompted to confirm whether or not the Switchover or Failover is to go ahead.

10-2

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

System Control

Fail DB_Sync Running Init Sync 2 3 4 4-s1;4 PRC BAP Task State Control 1

Figure 10-1. BAP Process State Control

10-3

End_Running 6

Mode Change Effected

Unknown

System Control

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

CES nnnn> BAPOP SHOW STATE PRC Ready TRUE Ind 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 Task Name APM_P_01 CUC_BAP_MSD__01 DCD_MGR_P_01 DIM_LINK_MGR_01 DIM_LINK_MGR_02 DIM_LINK_MGR_03 DIM_LINK_MGR_04 EM_P_01 ERRLOG_01 LESFAX_P_01 FCR_BAP_CONN_01 FDCD_EXT_MGR_01 FDCD_EXT_MGR_02 FDCD_EXT_MGR_03 FDCD_EXT_MGR_04 FEH_BAP_MAIN_01 IC_BAP_MSD_P_01 LFM_FILE_SER_01 MC_LOGGER_P_01 MCM_P_01 MDIR_P_01 PRC_EVENT_MO_01 PRC_HANDSHAK_01 PRC_PROC_STA_01 PRC_TASK_STA_01 RG_P_01 SCVFCC_DRIVE_01 SDC_MAIN_P_01 SM_P_01 SOI_SERVER_P_01 TBCC_DRIVER__01 TOKM_P_01 X4CC_DRIVER__01 XCCC_P_01 PADR_MAIN_P_01 SADINIT_01 Commanded Processor Mode MASTER Introduced TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE FALSE Processor Processor Mode State MASTER RUNNING Current State RUNNING RUNNING RUNNING RUNNING RUNNING RUNNING RUNNING RUNNING RUNNING RUNNING RUNNING RUNNING RUNNING RUNNING RUNNING RUNNING RUNNING RUNNING RUNNING RUNNING RUNNING RUNNING RUNNING RUNNING RUNNING RUNNING RUNNING RUNNING RUNNING RUNNING RUNNING RUNNING RUNNING RUNNING RUNNING RUNNING Desired State RUNNING RUNNING RUNNING RUNNING RUNNING RUNNING RUNNING RUNNING RUNNING RUNNING RUNNING RUNNING RUNNING RUNNING RUNNING RUNNING RUNNING RUNNING RUNNING RUNNING RUNNING RUNNING RUNNING RUNNING RUNNING RUNNING RUNNING RUNNING RUNNING RUNNING RUNNING RUNNING RUNNING RUNNING RUNNING UNKNOWN Synchronizing FALSE Notify_On Responded State_Change TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE FALSE TRUE FALSE TRUE TRUE TRUE TRUE TRUE TRUE TRUE FALSE TRUE TRUE FALSE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE FALSE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE FALSE

Table 10-1. Master BAP - response to BAPOP SHOW STATE command

10-4

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

System Control

CES nnnn> BAPOP SHOW STATE PRC Ready TRUE Ind 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 Task Name APM_P_01 CUC_BAP_MSD__01 DCD_MGR_P_01 DIM_LINK_MGR_01 DIM_LINK_MGR_02 DIM_LINK_MGR_03 DIM_LINK_MGR_04 EM_P_01 ERRLOG_01 LESFAX_P_01 FCR_BAP_CONN_01 FDCD_EXT_MGR_01 FDCD_EXT_MGR_02 FDCD_EXT_MGR_03 FDCD_EXT_MGR_04 FEH_BAP_MAIN_01 IC_BAP_MSD_P_01 LFM_FILE_SER_01 MC_LOGGER_P_01 MCM_P_01 MDIR_P_01 PRC_EVENT_MO_01 PRC_HANDSHAK_01 PRC_PROC_STA_01 PRC_TASK_STA_01 RG_P_01 SCVFCC_DRIVE_01 SDC_MAIN_P_01 SM_P_01 SOI_SERVER_P_01 TBCC_DRIVER__01 TOKM_P_01 X4CC_DRIVER__01 XCCC_P_01 PADR_MAIN_P_01 SADINIT_01 Commanded Processor Mode STANDBY Introduced TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE FALSE Processor Processor Mode State STANDBY RUNNING Current State RUNNING RUNNING RUNNING RUNNING RUNNING RUNNING RUNNING RUNNING RUNNING RUNNING RUNNING RUNNING RUNNING RUNNING RUNNING RUNNING RUNNING RUNNING RUNNING RUNNING RUNNING RUNNING RUNNING RUNNING RUNNING RUNNING RUNNING RUNNING RUNNING RUNNING RUNNING RUNNING RUNNING RUNNING RUNNING RUNNING Desired State RUNNING RUNNING RUNNING RUNNING RUNNING RUNNING RUNNING RUNNING RUNNING RUNNING RUNNING RUNNING RUNNING RUNNING RUNNING RUNNING RUNNING RUNNING RUNNING RUNNING RUNNING RUNNING RUNNING RUNNING RUNNING RUNNING RUNNING RUNNING RUNNING RUNNING RUNNING RUNNING RUNNING RUNNING RUNNING UNKNOWN Synchronizing FALSE Notify_On Responded State_Change TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE FALSE TRUE FALSE TRUE TRUE TRUE TRUE TRUE TRUE TRUE FALSE TRUE TRUE FALSE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE FALSE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE FALSE

Table 10-2. Standby BAP - response to BAPOP SHOW STATE command

10-5

System Control

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

Note: Following the switchover, it is advisable to restart the old Master BAP since this will reset all the software into a known state. This is necessary regardless of whether the Switch key or the Fail key has been used. If the BAP that is to become Master takes greater than 10 minutes to attain the "Running" state, or the "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 stopping the other BAP, then it too should be stopped using BAP STOP command. Once it has stopped, as indicated using the BAPOP SHOW STATE command, restart it using the BAPOP START 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 SOC form in the case of a failure of one of the VMS processes running on the Master BAP, because the failed process cannot be expected to respond correctly to a controlled switchover. It is therefore recommended that a BAPOP STOP BAP command on the Master BAP be performed when wishing to switch BAPs instead of requesting a switch via the BAP Management SOC form. This has the added advantage of forcing the operator to restart the old Master BAP (which is necessary in order to restart the VMS process which had previously failed). 2. Whilst a switchover is taking place the BAP mode and states displayed by the SOC will not always be consistent with those obtained using BAPOP commands on the BAP. 10.1.3 Manually Controlled BAP Switchover The operator can manually force switchover of the BAP using the BAP Management form (SOC Forms - System Control). It is also possible to manually select the online BAP using the switch on the front of the Arbiter card - the CPU card in the Arbiter Tray. The centre position is for Automatic switchover, the upper position selects BAP A and the lower position selects BAP B. For normal operation with automatic redundancy, leave the switch in the centre position. To force changeover, move the switch either up or down and keep it there for at least 40 seconds to ensure switchover is forced. The switch can also be used to prevent switchover by putting it in the position corresponding to the 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 the system. If for any reason the CPU card in the Arbiter Tray has to be removed, or if it is faulty, automatic switchover of the BAPs will be disabled. The online BAP will remain online, i.e. Master and Standby 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 are correctly routed through the switches normally controlled by the Arbiter. To do this, access the switch at the rear of the switchover tray, (situated on the PSU+Relay card on the Arbiter Tray, to the left of the power supplies looking from the back of the rack). There are two switches towards the rear lower part of the card: the one nearest the rear of the rack should normally be in the centre position but can be moved downwards to force the connection of BAP B. Similarly, moving
10-6

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

System Control

the other switch will force connection to BAP A, although it will not be necessary to take any action if BAP A is Master. Once the Arbiter has been restored to an operational state, ensure both switches are in the centre position. 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 orange light should be visible in the bottom right hand corner of the front panel. If this indication is not present, check the supply circuit breakers. If the supply is 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; follow the steps outlined in section 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 configuration. In both cases, the system time is distributed from the master BAP to the standby BAP and the online SOCs, such that there should not be a discrepancy between BAP and SOC times of 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 a highly accurate clock. For operational purposes of the system it is still desirable to keep the system 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 system clock is one or two minutes adrift from real time. The following commands can be used to reset the time but they involve BAP shutdown to put into effect. Therefore HNS recommends that they are 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 26SEP-1996:19:31:00, for 7:31pm on the 26th of September 1996.
10-7

System Control

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

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. The status of the BAPS as they restart, can be monitored with the command: CES nnnn> BAPOP SHOW STATE 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 in the system, with the exception of the X.25 DEMSAs which are handled separately. For each it shows : S : enter a Y in this column to activate the Restrt or Switch soft key commands. 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 (unknown) 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 CUC1B CUC2A CUC2B CUC3A CUC3B CUC4A CUC4B TELEX FEP1A TELEX FEP1B TELEX FEP2A TELEX FEP2B TELEX FEPs AOR(West) - if not equipped, will show Unknown AOR(West) - if not equipped, will show Unknown AOR(East) - if not equipped, will show Unknown AOR(East) - if not equipped, will show Unknown POR - if not equipped, will show Unknown POR - if not equipped, will show Unknown IOR - if not equipped, will show Unknown IOR - if not equipped, will show Unknown circuits 101-116 circuits 101-116 for circuits 117-132 for circuits 117-132 for any further circuits equipped, in order.

Note that the numbering of the Channel Unit Controllers does not correspond to the numbering of the ocean regions.

10-8

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

System Control

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 Switch FEPs . To manually 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 on the satellite side. The interruption to traffic handling can be minimized by setting the flow control bits on the TDM Group Management form to zero before performing the switchover and then returning them to their original value after the switchover. However, if the switchover is in response to calls failing, then the switchover should be undertaken without changing the flow control bits. As with the BAP, each FEP processor is composed of one or more processes, each of which has a 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 technique as for the BAPs and visualize two state transition diagrams next to each other - one which is currently in Master mode and Running state, and the other which is in Standby mode and Running state. A switchover is represented by the Master FEP moving from Master/Running to Standby/Sync and the Standby FEP moving from Standby/Running to Master/Sync. The Sync state allows the processor to align its databases and then move to Running, when traffic handling is resumed. When a fault occurs, i.e. a forced switchover, the master will make the transition to idle and the standby will make the transitions shown above. When a FEP switchover occurs, some disruption is caused to the satellite side interface and, as a result, a number of alarms are raised. The switchover process will take a few seconds and the ISL link will go out of service. As a result, the TDM group(s) will be reset - this can be observed on the channel units. The ISL will automatically come back into service and, assuming Demand Assigned mode is not in operation, the TDM group will then come back up. The process is complete once the loop timing on the TDM group is re-established and can be confirmed when the Red LEDs on the MTMs are extinguished. When Demand Assigned mode is in operation the TDM 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 as they would appear in the Alarm Summary Display, i.e. in reverse sequence. TDM Group Release acknowledged TDM Group Release from NCS Route has become unavailable - this refers to the TDM Group ISL Link Failed External alarm port off - there can be several appearance of this alarm Control rack power supply failed
10-9

System Control

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

Fail Running Sync Init 2 3 4-s2;2 PRC FEP Task State Control Unknown

Figure 10-2. FEP Process State Control

10-10

Mode Change Effected Or Resynch

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

System Control

Processor mode change - master before switchover FEP switchover Processor 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 in progress. If for any reason the CPU card in the Switchover Tray has to be removed, or if it is faulty, it is necessary to ensure that the asynchronous lines from the online FEP are correctly routed through the switches normally controlled by the CPU. This is done by a manual switch accessed from the rear of the switchover tray - it is situated on the PSU+Relay card on the Arbiter Tray, to the left of the power supplies (looking from the back of the rack). There are two switches towards the rear lower part of the card : both should normally be in the centre position but can be moved downwards to force the connection of FEP B. The one nearer the back of the rack controls the left hand half of the switchover tray and the further one from the back of the rack controls the right hand 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 as possible. Once the CPU is ready to be replaced, put both switches back into the central position just before re-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 an alarm will be raised. Failure can be due either to a software problem or to a failure in the hardware. 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 a changing 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 supply is 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 power off 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 reconnect it. If the unit fails to restart, call the DEC service engineer. If the fault is in one of the FEPs, advise the engineer that the FEPs do not have any hard disk and that he should bring the appropriate diagnostic tools. There are two types of FEP in common usage, the method for connection of a monitor depending
10-11

System Control

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

on the type installed. CK-KA630-A distribution panel Rear 9 pin connection with 2 pole switch and two rotary controls Internal KA630CNF configuration board. Accessed by removing rear blanking panels and seen at the top of the CPU card as a small plug in daughter board with a 10 pole DIP switch. A ten way ribbon cable terminated by a rectangular plug is required to connect 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 required for fault finding. HNS will give specific instructions in such cases. When a monitor set to interactive mode is powered up, the operator may need to select the language to be used at a prompt which appears on the monitor. If both DEMSAs have been shut down (e.g. during a power failure) then once they have been powered 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 appropriate baud 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 interactive or non-interactive use of the monitor. The normal settings, are shown in Appendix A. The settings of the switches are as follows: Switch 1 2 3 4 5 6 7 8 9 10 Normal Off (Up) On (Down) Off (Up) On (Down) Off (Up) Off (Up) Off (Up) Off (Up) Off (Up) Off (Up) Interactive Off (Up) On (Down) Off (Up) On (Down) Off (Up) Off (Up) Off (Up) Off (Up) On (Down) Off (Up) Function Halt Disabled Console Port Baud Rate=9600 Console Port Baud Rate=9600 Console Port Baud Rate=9600 No language inquiry, no loopback tests No language inquiry, no loopback tests CPU arbitrates Q22 Bus interrupts e.g. DHQ11 CPU arbitrates Q22 Bus interrupts e.g. DHQ11 Console enable if on 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-12

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

System Control

10.2.5 DEMSA Management The DEMSA Management form (SOC Forms - System Control) shows the condition of the X.25 DEMSAs. For each it shows : S : enter a Y in this column to activate the Switch soft key commands. 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 two DEMSAs and press Switch . To modify the service states, press Show to view the current status, then press modify . Enter the desired state in the Desired service state column and press Enter . If a DEMSA is in the Failed state, press modify , set the desired state to INS and press enter . This 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 the standby 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, this should be introduced as Standby to a DEMSA which is already operating as Master. It should be firstly marked Out of Service on the DEMSA Management SOC form. When the DEMSA is powered ON it requests a download of the "Router 2000" software (part of VAXPSI) from its Host node (one of the BAPs). As it takes on average 3 minutes for this software to load and startup, the Standby DEMSA should not be marked as In Service until it has been powered up for at least 3 minutes. This is necessary to ensure that there will be no problem switching DEMSAs so this added 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 only passes traffic to the Master DEMSA. The downloading of the "Router 2000" software is not under the control the the ACSE X.25 application software, rather it is a function of the proprietary VAXPSI software, which does not indicate when the download is complete. Therefore it is necessary to allow sufficient time for the Standby DEMSA to start up before setting it to be In Service by operator 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 continue to operate without any problems. Configuration data, also held on hard disk, is continually up10-13

System Control

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

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 corrupted. For this reason, a secure copy of the application software should be maintained and regular backups taken of the configuration data. The HNS installation team will leave, on tape, an Image Backup of the system disk and a dump of the database. These need to be kept current. If any Emergency Bug Fixes (EBFs) are applied to the 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 system disk without going through the steps of loading the operating system, the DEC layered products and the application software. Image backups are described in chapter eight of the VMS System Managers 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 considered. If there is a failure of one of the shadow disks, once the repair is made, adding the disk back into the shadow set will restore the data on this disk, but this process will take some time. When a shadow-set member which was taken offline comes back on-line it performs a complete disk copy, as a background task. The catchup time for a disk to become a full member of the shadow-set on RF71 disks has been measured at about 45 minutes, 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 effectively still in non-redundant mode. If both shadow disks fail, a most unlikely prospect since this is a dual failure, all current data will be lost. However, once a disk is repaired, the database can be reloaded from tape, using the latest dump, and the system can be restarted. There will be no way to replace the lost data. If a system disk is lost and the repair has been made, this disk can be reloaded by taking loading the image backup tape followed by installing any EBFs that have been received 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 to back it up and reload the backup. The configuration data covers a wide variety of user configurable parameters, from the hardware set up to the mobile lists. Much of the configuration data will only change rarely, for instance the configuration of channel unit hardware will remain fixed for months or years. Other data is more dynamic; principally the mobile list and the registered user list. Note that there is no data related to individual messages in this configuration data. Therefore, it is recommended that the archiving process should be performed at least once a week as a regular function. In addition, a backup should be made if there is a significant change to the registered user data base. Changes to the mobile list are anticipated to occur at a uniform rate.
10-14

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

System Control

Any updates to the mobile list and the registered user database which occurred between the time of the archive was created and the time it is loaded must be entered manually. To archive the database configuration, use Archive Database Configuration (SOC Viewer - Online Processing Database Management). This process will take some time, typically 10 to 20 minutes. The SOC can be used for other functions during this time and the window can be hidden but it should not be deleted. A message will appear in the window when the operation is complete. The operator should 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) is recommended for this archive in preference to the TU81 tape drive, but note that the some of the later 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 from Tape (SOC Viewer - Online Processing - Database Management - Copy Archive From Tape). This transfers the archive to disk. Then load the configuration data in the individual files using Restore Database Configuration (SOC Viewer - Online Processing - Database Management - Restore Database Configuration). This process will take some time, but is faster than the archiving operation. A message will appear in the window when the operation is complete. Additional commands are provided in SOC Viewer - Online Processing - Database Management to 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 archive tapes 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 equipment provides a satisfactory grade of service. The operator must regularly ensure that the system is performing correctly and that sufficient memory is available for the system to function correctly. These checks should be built in to the daily routine of the operating staff. The checks to be performed are : Ensure that messages are passing through the system, i.e. observing that the traffic levels as monitored on the System Usage Display (the default display) goes up and down with time. It is good practice for all staff to keep an eye on this display whenever possible. Ensure that there is a recent copy of the system software held on tape. Any new software releases must be retained on tape. In addition, a VMS backup of the system disk should made at least once every three emergency bug fixes applied. Regularly backup configuration databases. The configuration databases in the system, particularly the mobile list and the registered user database should be regularly backed-up so that in the event of a catastrophic failure of the disks, they can be reloaded and the system restarted. These backups should be made once every two weeks. Details are shown in section 10.3.3. Regularly archive log files. The system can accumulate data at a fast rate; both the event log and the call record log should be cleared on a daily basis to ensure that sufficient memory is available for new data. Files are transferred to tape, from which they can be read for post-processing either to produce the data for the billing centre
10-15

System Control

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

or for analysis of the event log (see section 14.6). Regularly check the offline database usage. Do not collect too many log files, also regularly delete unwanted files. The mechanism is described in section 14.11. Check for stuck messages. Regularly, e.g. daily, check for messages which are stuck 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. At present, there is no check on the standby machine. By regularly performing a switchover, this will ensure that the standby is always available in case the online machine fails. If when this regular switchover is performed, the previously standby DEMSA is not operational, the system will automatically switch back to the working DEMSA. 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 system manager, who controls accounts, privileges, passwords and quotas using the appropriate VMS commands, as documented in the DEC System Manager documentation. Access to the DEC computers is normally via the SOC workstation, although this access is usually restricted to the SOC and SOC Viewer facilities. From the window used to start up the SOC application it is also possible to log into any intelligent device on the Ethernet, providing access is granted. In general it is possible to do this by creating a window on the SOC, logging into one of the non captive SOC accounts, usually SOCSYS, followed by exercising the VMS command SET HOST <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 made using the forms available from (SOC Forms - Operator). Access to the system as a whole, rather than the specific ACSE operator facilities, can be made using the VMS command set, providing an account is set up for the user to use. Outside access to the DEC computer system, other than for ACSE specific functions, can be made via X.25. However, restriction to specified authorised users, e.g. HNS Ltd. for remote support 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, refer to 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 be brought to the attention of the operator and are therefore classed as alarms, until they are acknowledged by the operator. After that, information on them can only be found by examining the event database.
10-16

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

System Control

So all alarms are also events but the reverse is not always true. Also alarms have only a transient existence but events are preserved. It is good operational practice to run the system with no alarm indications showing on the summary alarm display on the SOC. At least once a day, all unacknowledged alarms should be investigated 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 the summary alarm panel on the channel unit racks and, in more detail, in the banner area on the SOC screen. The indication on the channel unit rack can be connected to the earth station alarm collection system. There are SOC forms to display unacknowledged alarms and also to display, in summary and in detail, the event log. Events can be printed out on the event printer. The operator can select which types of event are to 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 on the 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 undelivered 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 operators attention and the class of the alarm on the horizontal axis BAP for those relating to the software or hardware in the Background Processors.
10-17

System Control

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

Note that this covers only those alarms detected by the application software and not by the DEC software, such as the operating system. FEP for alarms in any of the Front End Processors. Again only those alarms detected by 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 faults whose source is not easy to pinpoint. SOC for failure indications from any of the workstations used for the MMI. This would also be used if the operator was expected to attend to an event, such as the receipt of a 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 in some installations. Alarms in these categories will not be reported. When the box is blank, no alarm condition exists. When an alarm occurs, the appropriate box shows red. Once all alarms for that class and level have been acknowledged, the box returns to blank. 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 the operator. For instance, if a mobile wants to send a message to the LES, it can use the Special Access code 33. When the message is received at the ACSE, it is routed to the event log and a Minor alarm raised under the SOC class. The SOC Viewer is then used to read the contents of the message which has been received. The summary alarm display will continue to show red against the appropriate alarm until it is acknowledged. 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 as long as the indication is there, any new alarms of the same classification will only be shown on the message 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 has decided that there is no further need to keep this record of the fault. The information is in any case 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 be given on the summary alarm display. Once another event occurs, it will replace the message on the message line. To view all reported alarms, use the Alarm Summary Display (SOC Forms System Control).
10-18

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

System Control

The event class and alarm level can be specified to investigate a particular area or left blank to see all alarms. The class - BAP, FEP, etc - are entered in the form that appears above the red alarm 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 First Page for the following details. Use Next Page for the previous page 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 Reset Audbl at any time. 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 Man . This brings up the Alarm Management form which shows more details of the event. The operator can enter a comment on this form if it is useful for future fault analysis. To acknowledge the alarm, press Ack . There is a limit of 100 of the number of alarms which can be held in the system. If this limit is reached, the system will automatically acknowledge them. Details can then only be found by searching the event displays. Auto-acknowledgement is performed on the oldest, least significant alarms first. The order of auto-acknowledgement is that all the alarms of one priority are cleared before 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 are 100 urgent and semi-urgent alarms in the system, and a minor alarm occurs, the minor alarm would be immediately acknowledged.
10-19

System Control

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

10.4.5 Event Displays As well as the database, which holds information concerning the 100 most recent alarms, and which is used for the alarm displays, there are log files which hold information about all the events raised, both the events which are also alarms, i.e. of minor severity and above, and those which are not, i.e. of information severity. Events entries can be interrogated for as long as log files are present in the on-line system. The process whereby log files are archived and deleted from the on-line system is described in Chapter 14. The Event Summary Display (SOC Forms - System Control) allows access to this event information and provides a means for the operator to analyse the contents of the log. The operator must specify the time from which the search is to be made (default is current time) and the number of 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 be specified if selection is required on this basis, although it must be noted that the process of scanning 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 information is being gathered. Events are generated whenever the operator accesses a SOC form, unless this has been supressed using Event Definition from the SOC Viewer. The operator may further specify whether 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 in the event log. If the event is later on acknowledged as an alarm, an further entry will be placed in the event log around the time the event was acknowledged. Thus the event will appear twice in the display, although the time shown in the display will be the time raised, in both cases. Events will appear in the order there is an entry in the event log, with the most recent entry being shown first. A page of events contains 8 events. Use the Next Page and Prev Page to scroll through the events. The forms selection criteria can be broken into two parts. The first group - Latest Time Reported and 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 Event Sequence 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 log files for one week on it - this is approximately 168 log files. Today is Sunday. A BAP switchover took place on Tuesday at 10 AM. The operator wishes to see urgent PRC events that happened around switch over. This can be done in two ways: 1. Select Reporting Component - PRC and Alarm Level - Urgent and then first page . The software would then search through all the log files for PRC Urgent events, perhaps taking several minutes to do so. 2. Alternatively, set Last Time Reported to 11 oclock on Tuesday morning, Hours to search to 2, Reporting component to PRC and Alarm Level to Urgent. This would give direct access to the log file of interest and then limit the search window to 2 hours. The information should be displayed within a matter of seconds when this selection is used. Thus the hours to search can be used by itself to limit a search to a previous number of hours.
10-20

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

System Control

This is useful if the events you are interested in all occurred in the last n hours. The key to obtaining 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 enable the operator to understand what has caused the event, to distinguish one event from another and to separate cause and effect: 1. Acknowledge: identifies whether or not the event is an alarm which has previously been 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, as shown in the SOC banner summary alarm display. The event classes are as listed in section 10.4.3 4. Alarm level: (Severity on the Event Printer) shows the alarm indication for this event, 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 correlation between the description text and the text for the corresponding group and event number in Section 11.2. 6. Object: (Affected Object on the Event Printer) can usually be ignored as the information is displayed in a more digestible form under Supporting Data in the Event Full Display, shown below. (The same applies for Object Units in the Event Full Display. 7. Sequence Number: uniquely identifies the event within the system and can be used to relate the information about a single event which appears on the this and the corresponding full display and also that on the event printer. The numbers used are recycled after 99999. Note: in the corresponding output on the event printer there appears Processor field. This indicates which BAP reported the event - BAPA or BAPB, except in the case of events relating to the 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 column intersects the row which containing details of the event of interest, and press Full . This will result in a screen which provides the associated Event Full Display.

10-21

System Control

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

In addition to the information which has already been seen in the Summary display, the following additional 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 the software 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 the event). 3. Event Number: is a number in a group which indicates the nature of the event, see Section 11.2. 4. System Action: shows what the system or the operator needs to do to recover from the fault. This is a short text field. 5. Supporting Data: provides additional details of the event. Relevant status information, collected at the time of the event, is usually displayed. See Section 11.2 for an explanation of the data provided, for the Reporting Component and Event Number to which the event refers. 6. Printed: indicates whether or not the details for that event has been sent to the Event Printer. 7. Acking Operator: (alarmable events only) is reserved for future use. 8. Time acked: (alarmable events only) is the time the operator acknowledged that event. 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 or Undelivered Distress. The prompt alarm buzzer will sound when a distress call is received in the system and visual indications will be given on the SOC screen and on the ASM on the Channel Unit Rack. The message 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 written 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 in cases where a delivery has been attempted, but failed, the alarm level will be Undelivered Distress. The contents of the distress alert/message can be viewed in the Distress Message Logfile Report, from SOC Viewer, as described in section 13.2, or the Distress Message Summary Display 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 the SOC screen.
10-22

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

System Control

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 the alarm. If a message has not been successfully delivered, it may be necessary to manually attempt delivery. For mobile originated messages, direct contact should be made by telephone with the MRCC. For messages to mobiles, manual delivery to another LES may be necessary. See local instructions 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 number of events associated with Land Alerts, and these are similar in form to those for distress alerts/messages. With Land Alerts, similar text is included in the event as for the corresponding event for distress alerts/messages, including the word DISTRESS in the title DISTRESS DELIVERY RECORD, although 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 the SOC. 2. Acknowledge the alarm on the SOC using the Alarm Summary Display. At this stage, the operator has the opportunity to record, for future reference, comments concerning the fault by selecting the Alarm Management Display. Note: after a pre-determined number of alarms are in the system without being acknowledged, 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 the problem and initiate the appropriate corrective. Section 11 explains the event display. 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 up using 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 classification 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 SOC screen. It is recommended that HNS are consulted before this categorization is changed. 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
10-23

System Control

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

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 as they are used by the software. Please consult HNS before making changes to this field. 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. This field is limited to 20 characters and is left blank by HNS, except for certain important events 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 messages. 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 stop traffic handling. This level indicates that the operator should take action as soon as possible. Semi-urgent is used for any fault which can wait to be fixed. For example, faults which 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 occur repeatedly. 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 operational, 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 Printer Management form (SOC Viewer - Online Processing - Alarm Printer Management). This form allows 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 and use 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 printer back on line. When bringing a printer back online, the operator has two options - print from the current event or print all missing events. Normally the printer would not be placed offline. However, this action may be useful in exceptional circumstances, for instance if a fault was causing repetitive alarms and it was desired to stop printing of these alarms.
10-24

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

System Control

10.5 Report Printer Normally no action is required for the Report Printer other than to check that the paper is correctly set in the printer and when low more paper is added. If the printer does run out of paper it may be necessary 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 that the 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 configured and 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 the Channel Unit O&M Manual, Reference [3]. The normal indications are : ISL Modulator TDM Modulator ISL Demodulator TDM Demodulator Message Demodulator E E C, changing to D when a packet is received E, with the Demod Lock LED flashing every TDM frame (every 8.64 seconds) A, changing to C when a message is received. The Demod Lock LED is also illuminated during the time the message is received. B, changing to D when a packet is received. The Demod Lock LED is illuminated all the time. 8, indicating available to be switched in service
10-25

Signalling Demodulator Standby unit

System Control

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

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 0 8 9 A B C D E Normal Modulator Startup Function disabled Ready for initialisation Demodulator Startup Function disabled Ready for initialisation Carrier acquisition Unique word missed Carrier lock (MSG and TDM) Collision detected (SIG) Burst detected (SIG) Normal data enabled (TDM) Normal data ignored (TDM)

Note that if a channel unit is reconfigured from the SOC so that it is taken Out of Service, the mode previously set will remain displayed on the channel unit. For example, if 8 was displayed and the unit is taken out of the sparing pool, the display will remain at 8. However the software is unable to allocate the channel unit. On the ASM Modules, there is a repetition of the summary alarm status - Distress, urgent, semiurgent and minor - together with an indication if communication with the BAP has failed (SCP Line Fail). 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. Note that 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 is received from the TDM Demodulator. If demand assignment mode is in operation and the primary TDM group is not operational, this LED will be illuminated, but no action need be taken. On the Channel unit rack power supplies there is a green LED for power on and a red LED for faults. 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 multidrop link from the CUC FEP to the CUs TDM timing received Repeats summary alarm on the MTMs

TDM Frame active Summary alarm

Orange Red

On the Arbiter and Switchover trays there is a series of indications as follows : Arbiter card in position A5A0 on CUC rack

10-26

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

System Control

LES CAP0 CAP1 CAP2 CAP3 A:1-8 A:9-16

Indication Flashing - comms failure to BAP A or suspension of polling from BAP A Flashing - comms failure to BAP B or suspension of polling from BAP B Flashing - comms failure on BAP port which controls DEMSA switch Flashing - Online BAP selected manually by switch on front of Arbiter ON - BAP A master, OFF - BAP B master ON - DEMSA A master, OFF - DEMSA B master

CUC switch controller in position A4A0 in CUC rack CAP0 CAP1 CAP2 CAP3 A:1-8 A:9-16 Flashing - comms failure on link to BAP. Not used Not used Not used ON - CUC 1A master, OFF - CUC 1B master ON - CUC 2A master, OFF - CUC 2B master

Telex switch controller in position A6A0 in TIF rack CAP0 CAP1 CAP2 CAP3 A:1-8 A:9-16 Flashing - comms failure on link 1 to BAP. Flashing - comms failure on link 2 to BAP. Not used Not used ON - Telex FEP 1A master, OFF - Telex FEP 1B master 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. There are also six red LEDs on the PSU and Relay card, to the left of the left power supply. The LEDs are lit if there is a failure in any of the three outputs from each of the two supplies; It is important to ensure that none of them are lit. Three of the LEDs are immediately behind the black connector on the PSU and Relay card and are not directly visible. If any of these are lit, PSU A is faulty, i.e. the right hand PSU when looking at the back of the rack. The other three LEDs are at the other side of the card and indicate a failure in one of the outputs of PSU B. The CUC and TIF rack manual contains further details of these indications and describes how to replace a suspect power supply. The switchover tray can 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 by the customer site staff. If it is a problem which requires HNS support (as opposed to other support e.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 in one of these forms for each event or failure and use continuation sheets if necessary. It may also often help if associated alarm printer outputs are attached. Appendix F gives details of the form, how to fill it in and the procedures involved.

10-27

System Control

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

10.8 Test Message Functions A number of functions are built into the system for test purposes. The terrestrial interface forms include 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 is made, 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 message to or from the mobile is flagged in the system and traced. The operator is able to follow the progress 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 originates from 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 Show . This will give the mobile number of the currently defined test mobile. To change it, press Modify , enter the new number and press Enter . A Telex circuit can be designated as a test circuit using the Telex Trunk Management form (SOC Forms - Terrestrial Interfaces - Telex). Note that the factory default setting for the test mobile is 400000000, and this equates to no mobile. In order to designate a mobile to be a test mobile this must be modified to the appropriate mobile 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 ID Definition (SOC Viewer - Online Processing - Database Access - User Services). The field can be up 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 during testing. simulating problems which users might encounter. For test uses, the operator should be registered on the system with his own PIN. All services should 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 registered user able to download group identities - ENIDs and DNIDs.

10-28

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

System Control

The operator, by virtue of his privileged position, can enter the PIN of any registered user. This method is of use in investigating problems reported by users. A terrestrial users identity should not be used for any transactions which generate call records and charges unless arrangements 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 prompt which greets a registered user accessing the system. The operator should then engage in exactly the same dialogue as any terrestrial user and can therefore follow the instructions published for such users. 10.11 Access by HNS for Fault Investigation HNS is able to access the ACSE for fault investigation. This is particularly valuable in ascertaining the cause of software or database problems. Access will only be made by arrangement with, and with the permission of, the staff at the LES. The access is achieved by setting up a connection over the X25 interface, using a special subaddress which bypasses the normal PSDN user interface, to establish a direct connection with the VMS 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 VMS from remote machines. The command files are run by entering the appropriate file name shown below, from the VMS SYSTEM account, on the Operating System Consoles for both the Master and 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 standalone. 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 will then be made available when required by request to the operations staff at the site who will be responsible for running the necessary command file to allow temporary access and for closing the access down when it is no longer required.
10-29

System Control

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

The cooperation of staff on site to set the appropriate security level will be much appreciated by HNS staff at Milton Keynes investigating problems.
[opg10.mss]

10-30

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

Event Messages

Chapter 11 EVENT MESSAGES


11.1 Introduction This chapter describes the details which are given when events are reported. Events are visible to the 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 is shown in figure 11-1. The information given consists of a textual description plus a range of supporting information which should enable the operator to understand what has caused the event, to distinguish one event 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 the information 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 mmm is yyyy is hh is mm is ss is tt is day 1...31 month JAN,FEB,MAR,APR,MAY,JUN,JUL,AUG,SEP,OCT,NOV,DEC year e.g. 1992 hour 00...23 minute 00...59 second 00...59 tick 00...99

Note that if the time appears as 1-Jan-1990, this is a default which is printed if the correct time is not 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 the SOC 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 in some 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 this installation. Severity on the Event Printer or Alarm level on the SOC forms shows what alarm indications are generated for this event, if any. The following severity categories exist, all of which apart from the last are alarmable. Undelivered distress - failure to deliver a distress message.
11-1

++++++++++++++++++++++++++> Seq. No. Time -------- ----------------------1342 16-DEC-1992 21:13:12:25 Description : Call Initiated

EVENT <+++++++++++++++++++ Class Severity Group, Evt. No., Processor ------- ----------------------------------BAP INFO-ONLY #MCM_GROUP 27 IOR

Event Messages

Affected Object --------------403100420

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 ++++++++++++++++++++++++++> Seq. No. Time -------- ----------------------1343 16-DEC-1992 21:16:58:36 Description : Call Completed EVENT <+++++++++++++++++++ Class Severity Group, Evt. No., Processor ------- ----------------------------------BAP INFO-ONLY MCM_GROUP 27 IOR Affected Object --------------403100420

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 ++++++++++++++++++++++++++> Seq. No. Time -------- ----------------------1344 16-DEC-1992 21:17:43:10 Description : CU Summary Status 11-2 EVENT <+++++++++++++++++++ Class Severity Group, Evt. No., Processor ------- ----------------------------------CU INFO-ONLY SDC_GROUP 125 AOR Affected Object --------------1. 1

System Action : -------------------

Supporting Data: Ocean Region: 01 Chassis ID: 1 Chassis Slot: 1 Status: OK Enabled: YES Data overun: NO Timing Lost: NO ++++++++++++++++++++++++++> Seq. No. Time -------- ----------------------1345 16-DEC-1992 21:17:55:67 Description : Printer available Supporting Data: Printer is now online and accessed via a LAT Figure 11-1. Sample Event Printer Output EVENT <+++++++++++++++++++ Class Severity Group, Evt. No., Processor ------- ----------------------------------BAP INFO-ONLY APM_GROUP 1 BAPA Affected Object ---------------

System Action : ------------------A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

Event Messages

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 indication. Group on the printer and Reporting Component on the SOC displays describe the software component 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 references the type of event. Processor indicates which one reported the event - BAPA or BAPB, except in the case of events
11-3

Event Messages

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

relating to the satellite interface, where this column shows the Ocean Region to which the event relates: e.g. FP1, FP2, FP3 or FP4. The information displayed under Affected Object on the printer and Object and Object Units on the 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 Supporting Data, described below. Description is the textual description of the event. There is a one to one correlation between this and 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 certain specific cases such as distress. Supporting Data provides additional details of the event, such as ocean region identity or channel unit 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 are categorized according to Group and Event Number. Also shown are brief details of the corrective action, where applicable. Where None is shown in this 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 event will 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 many cases. Where several events occur at the same time, these should be analysed to determine which 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 is assumed 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 reported the loss of its partner. Supporting Data: None Corrective action: Identify which session has failed by looking at the SYS$BATCH queues on each BAP ($ SHOW QUEUE SYS$BATCH). On the BAP which has lost its billing batch job attempt to determine the reason for the lack of billing (see chapter 16. Take corrective action and restart autobilling. BAPS 02 An auto billing run has failed. Explanation: Autobilling has failed to create billing files. Supporting Data: None Corrective action: Identify which billing job has failed (billing will normally be run on the standby BAP). Follow error recovery procedures detailed in section 16.9. This will depend on whether or not "Billing Error Continue" had been selected during billing setup.
11-4

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

Event Messages

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. Supporting Data: None Corrective action: Check decnet, ensure that the destination is visible from the BAP on which billing is run and that write access has been granted. Check disk space. Follow error recovery procedures 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 billing was due to be performed. Supporting Data: None Corrective action: Check for reason (if appropriate). Unlock as soon as possible to allow billing to run. 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. An alarm will be raised if the current available disk space is less than this figure. Supporting Data: None 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 due to a change in the password. Supporting Data: None Corrective action: Check passwords. Restart autobilling if change is to be permanent. See section 16.3.4 BAPS 10 Auto housekeeping run error. Explanation: This is raised if there is a failure to complete an auto housekeeping request. Most likely as a result to write to tape or if a required file has been deleted or renamed after it has been correctly 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 paper has run out.
11-5

Event Messages

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

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 by the 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 (128 pages) is full. Supporting Data: None Corrective action: This is is an unlikely occurrence; if situation persists, new traffic can be suspended by setting the congestion bit on the TDM channel or by taking incoming terrestrial circuits 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 : where DNID space is used up. Database space is not related to disk usage as the space is allocated when installed. Corrective action: The action is to free up space, for example deleting DNID messages no longer required. Supporting Data: None. DAC 1 : Database space desperate warning threshold reached Explanation: Database free space is becoming dangerously low. This is a more severe warning than DAC 0. Corrective action: See DAC0 Supporting Data: None. 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 ear11-6

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

Event Messages

lier warnings were ignored. Supporting Data: None. DAC 10 : Database Connections Alarm Explanation: More than 10 DB connections held for over 5 minutes. Corrective action: Call HNS. Supporting Data: None. 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. Link identification (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 identification (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 be stored because there is not enough space left in the registered users DNID file. The overflow flag is set, and the event is not raised again until it is cleared when more space is created by the operator increasing the registered users quota, or the registered user deleting some of the DNID files 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 occurs repeatedly for a particular user, the allocated file space can be increased, if this is agreed commercially with the customer. Note: For FAX events. Fax events FAX 100 - FAX 124 refer to delivery attempts. These events refer to the final delivery attempt. It is feasible that previous delivery attempts may have failed (for the same or other reasons). The events FAX 100 - FAX 124 generate call completion codes 400 - 424 respectively. These are described 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
11-7

Event Messages

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

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 should become Out Of Service. The Fax PC will remain Pending Out Of Service until there are no more messages 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 Of Service. Supporting Data: Fax PC Id and Fax PC Node Name. Corrective action: This event is normally only raised as the result of operator intervention. No further 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 not available for message delivery. This PC can now be safely shut down for upgrade or maintenance work. Supporting Data: Fax PC Id and Fax PC Node Name. 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 the presence of a file named 00000000.SYN created by the Fax PC within the WorkArea (that is the directory on the ShadowSet allocated solely to this PC). Supporting Data: Fax PC Id and Fax PC Node Name. 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 the LES. 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 unexpected synchronization file has found (a .SYN file other than 00000000.SYN or 11111111.SYN). Supporting Data: Fax PC Id and Fax PC Node Name. Corrective action: Examine the Zetafax Monitor and Startup.Cmd windows on the quoted Fax PC in order to determine the reason for failure. The Fax PC may need to be restarted once the problem has been resolved. FAX 26 : FAX PC Now Shut Down
11-8

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

Event Messages

Explanation: The LESFAX subsystem has received a request from the LES system to shutdown operation. 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 is required. FAX 31 : FAX Route Now In Service Explanation: Indicates that the quoted Fax route is now available for message delivery and messages may currently being delivered on this route. A Fax route will always be In Service whilst there 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 route state has been set as the result of operator instruction that the Fax PCs on this route should become Out Of Service. This route will remain Pending Out of Service until there are no more Fax PCs on this route which are either In Service or Pending Out Of Service. At that time the route status will become Out Of Service. Supporting Data: Fax route number and route name. 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 not available for message delivery. Fax PCs assigned to this route can now safely be shutdown for maintenance or upgrade work. Supporting Data: Fax route number and route name. 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 shutdown operation. Supporting Data: Fax route number and route name. Corrective action: This event is normally only raised as the result of operator intervention. No further 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 as the driver is unaware of the existence of this route. Supporting Data: Message Reference Number and Route.
11-9

Event Messages

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

Corrective Action: Check the preferred route for the fax driver and that this route is defined within the 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 as the 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 been unable to secure the message to the specified PCs hard disk and hence the third party Zetafax software. 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 every message: a .DEL file containing delivery attempt details and a .FIN file containing all other information. If either of these files cannot be processed then the .FIN file will be renamed to .BAD to enable the processing of other messages to continue. This situation may arise due to a PC returning 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 to ascertain the problem. Note. It is possible that the message was sent correctly, however it is advisable 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 this shared area cannot be accessed by both FAX and by the PC (using virtual drives D:and E:) then the PC is effectively useless. The specified PC will not be available for message delivery or producing statistics. Supporting Data: Fax PC Id and Fax PC Node Name. 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. It was necessary to remove this PC from service so no more messages are routed to it. This PC will remain 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 shut11-10

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

Event Messages

ting down and restarting the PC. The PC must then be put back into service using the relevant SOC 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 the same route. Supporting Data: Message filename, Source Fax PC ID, source Fax PC Node Name, destination Fax PC ID and destination Fax PC Node Name Corrective Action: None. If further problems occur then the PC will be forced Out Of Service and another 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 access the PC control file for this message, or the control 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-OUT directory. These files are deleted by Zetafax on completion of message processing, not to be confused with the .FIN and .DEL files in the shared disk area which are deleted by FAX when it processes the Zetafax delivery details. Supporting Data: Fax PC Id, Fax PC Node Name and Message Reference Number. Corrective Action: As the control file is normally deleted following the final delivery attempt this may prove difficult to correct. However, check the ZETAFAX\USERS\API\Z-OUT directory to see if the 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 access 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-OUT directory. These files are deleted by Zetafax on completion of message processing, not to be confused with the .FIN and .DEL files in the shared disk area which are deleted by FAX when it processes the Zetafax delivery details. Supporting Data: Fax PC Id, Fax PC Node Name and Message Reference Number. Corrective Action: As the message file is normally deleted following the final delivery attempt this may prove difficult to correct. However, check the ZETAFAX\USERS\API\Z-OUT directory to see if the 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 insufficient space on the PC hard disk for Zetafax to create the necessary message files. Supporting Data: Fax PC Id, Fax PC Node Name and Message Reference Number. Corrective Action: Free some space on the specified fax PC. FAX 113: Zetafax Bad INI File
11-11

Event Messages

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

Explanation: The specified PC is unable to deliver the specified message as Zetafax cannot access the Zetafax.INI file, or the Zetafax.INI file is invalid. Supporting Data: Fax PC Id, Fax PC Node Name and Message Reference Number. Corrective Action: Ensure that a ZETAFAX.INI file exists on the PC and that the AUTOEXEC.BAT file 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 convert the message into the correct format. This could be caused by an invalid message. Supporting Data: Fax PC Id, Fax PC Node Name and Message Reference Number. Corrective Action: It may prove difficult to determine why a message conversion failed. If possible examine 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 access 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 file in the C:\ZETAFAX\SYSTEM\Z-LETTER directory. Ensure that Zetafax has been set up correctly and is aware of the existence of this letterhead. See Reference 6 for details on how to use the Zetafax Setup program. FAX 116: Zetafax Cannot Access Graphic Explanation: The specified PC is unable to deliver the specified message as Zetafax cannot access a graphics file referenced within this message (or associated banner), or a graphics file is invalid. Supporting Data: Fax PC Id, Fax PC Node Name and Message Reference Number. Corrective Action: Any graphic referenced within the message must have a corresponding G3F file in the C:\ZETAFAX\SYSTEM\Z-GRAPH directory. If a graphic is used, it will most likely be as part of the banner. In this case check that the banner file used for this message does not contain a reference to a non-existent graphic. FAX 117: Device Failed Explanation: The specified message cannot be delivered by the specified PC due to the specified fax 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 and Message Reference Number. Corrective Action: Ensure that the device is configured correctly and that the device installed corresponds to the device configured. See Reference 6 for details on how to use the Zetafax Setup program. It may be useful to test the modem device outside of the Zetafax environment using standard AT commands.
11-12

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

Event Messages

FAX 118: Device Busy Explanation: The specified message cannot be delivered by the specified PC due to the specified fax modem device being busy. Supporting Data: Fax PC Id, Fax PC Node Name, Fax Modem Device COM Port Number and Message Reference Number. 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 specified fax modem device being offline (unavailable for sending). Supporting Data: Fax PC Id, Fax PC Node Name, Fax Modem Device COM Port Number and Message Reference Number. 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 specified fax modem device being invalid. The device may be incompatible or configured incorrectly. Supporting Data: Fax PC Id, Fax PC Node Name, Fax Modem Device COM Port Number and Message Reference Number. Corrective Action: Ensure that the device is configured correctly and that the device installed corresponds to the device configured. See the reference 6 for details on how to use the Zetafax Setup program. FAX 121: No Device Available Explanation: The specified message cannot be delivered due to the specified PC having no working fax modem devices of the correct type. Supporting Data: Fax PC Id, Fax PC Node Name and Message Reference Number. Corrective Action: Ensure that the PC contains fax modem devices, that they are configured correctly and that the device installed corresponds to the device configured. See Reference 6 for details 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 serious error in communicating with the specified fax modem device. Supporting Data: Fax PC Id, Fax PC Node Name, Fax Modem Device COM Port Number and Message Reference Number. Corrective Action: Ensure that the device is configured correctly and that the device installed corresponds to the device configured. See reference 6 for details on how to use the Zetafax Setup program. It may be useful to test the modem device outside of the Zetafax environment using standard AT commands.
11-13

Event Messages

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

FAX 123: Device Timeout Explanation: The specified message cannot be delivered by the specified PC due to the specified fax modem device timing out. Supporting Data: Fax PC Id, Fax PC Node Name, Fax Modem Device COM Port Number and Message Reference Number. Corrective Action: Ensure that the device is configured correctly and that the device installed corresponds to the device configured. See reference 6 for details on how to use the Zetafax Setup program. It may be useful to test the modem device outside of the Zetafax environment using standard AT commands. FAX 124: Device No Dial Tone Explanation: The specified message cannot be delivered by the specified PC due to the specified fax modem device not detecting a dialtone when a call attempt was made. This indicates either a failure in the exchange or the connection to the exchange. Supporting Data: Fax PC Id, Fax PC Node Name, Fax Modem Device COM Port Number and Message Reference Number. Corrective Action: Ensure that the device has the correct type of cable and is properly connected to 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 database be 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. Supporting Data: FEP ID. Corrective action: None FDCD 12 : CU FEP configuration load completed Explanation: Earlier request for FEP configuration load has been successfully completed. No action required. Supporting Data: FEP ID. Corrective action: None FDCD 13 : CU FEP configuration load failed Explanation: Earlier request for FEP configuration load has failed. This will usually mean that the FEP will not be able to operate successfully.
11-14

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

Event Messages

Supporting data: FEP ID, Failure Reason. Corrective action: Check the installation procedure for creating the FEP load file and that this is correctly pointed to. If this is information is correct, restart the FEP. If the event then re-occurs perform 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. Supporting Data: None. Corrective action: Take action to delete unwanted files and logfiles, i.e. use SOCV to move them to 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. Supporting Data: None. Corrective action: Take urgent action to delete unwanted files and logfiles, i.e. use SOCV to move them to the Offline logfile area. Ensure that these files are first archived before deletion. This is the 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 warnings were issued. Supporting Data: None. LFM 3 : Synchronisation still in progress Explanation: The two copies of the database are kept in synchronization by the disk shadowing mechanism. This event is raised to show that the two databases are still being synchronised. Supporting Data: None Corrective action: None LFM 5 : Log file space severe warning threshold reached (90%) Explanation: 90% of the logfile space is full. Supporting Data: None. Corrective action: Take action to clear file and logfile space of unwanted files. This is the second warning. LFM 6 : Synchronisation completed Explanation: The databases have been synchronised Supporting Data: None.
11-15

Event Messages

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

Corrective action: None LFM 7 : Synchronisation failure Explanation: Synchronization of the databases failed. Supporting Data: None. 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 is configured by default for 20 normal priority and 20 distress priority messages concurrently. Supporting Data: None. 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. Supporting Data: None. Corrective action: See MAR 30 MAR 30 : First normal service token retracted Explanation: The system is concurrently able to accept fewer than the configured maximum number of maximum length normal priority messages, but is still able to accept the configured maximum number of maximum length distress priority messages. Supporting Data: None. Corrective action: When token retracted events appear the operator should ascertain why messages remain undelivered in the system, e.g. line failure, and remedy the condition, otherwise the LES 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 number of maximum length normal priority messages, but is still able to accept the configured maximum number of maximum length distress priority messages. Supporting Data: None. Corrective action: See MAR 30 MAR 50 : Normal service not available Explanation: The system is no longer able to accept normal priority messages, but is still able to accept 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 to 500 characters).
11-16

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

Event Messages

Supporting Data: None. Corrective action: See MAR 30 MAR 60 : First Distress Token Retracted Explanation: The system is concurrently able to accept fewer than the configured maximum number of maximum length distress priority messages. Supporting Data: None. Corrective action: See MAR 30 MAR 70 : 50 percent of Distress Tokens Retracted Explanation: The system is concurrently able to accept only 50% of the configured maximum number of maximum length distress priority messages. Supporting Data: None. Corrective action: See MAR 30 MAR 80 : 90 percent of Distress Tokens Retracted Explanation: The system is able to accept only 10% of the configured maximum number of maximum length distress priority messages. Supporting Data: None. Corrective action: See MAR 30 MAR 90 : Distress Service not available Explanation: The system is no longer able to accept distress priority messages. Supporting Data: None. Corrective action: See MAR 30 MCM 1 : Ship Transfer Finite state machine protocol violation Explanation: In exercising the protocols of ref 1 regarding interaction between LES and MES an event occurs which is not allowed by the protocol. Supporting Data: Ocean region, station number, mobile number, state (see ref 1), event (see ref 1), message reference number, internal error code. Corrective action: Possible protocol violations are documented in ref 1 and may be caused by MES, or satellite as well as LES problems. Generally the LES will continue to operate normally after 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 the protocols defined in ref 1.
11-17

Event Messages

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

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 was not possible to successfully complete all the updates. Supporting Data: Ocean region, station number, state (see ref 1), event (see ref 1), last sequence number, 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, accepted and acknowledged by the NCS. Supporting Data: Ocean region, Spot ID, station number, TDM Group ID, request number. Corrective action: None 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. Corrective action: None 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. Corrective action: None 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 then occurs 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, TDM frequency, return channels.
11-18

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

Event Messages

Corrective action: None 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, TDM frequency, return channels. Corrective action: None 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 occurs check 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. Corrective action: None 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 TDM group. 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.
11-19

Event Messages

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

Corrective action: None 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. Corrective action: None 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 is faulty. MCM 24 :Test call initiated Explanation: A test call has been initiated by a mobile marked in the ACSE as a Test Mobile on the SOC using the Test Mobile Definition form. Supporting Data: Ocean region, mobile number, message reference number, start time, signal LUN, call direction. Corrective action: None 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, call completion code, call direction, TDM/MSG LUN. Corrective action: None MCM 26 : Call initiated Explanation: This relates to satellite call attempts only. If call logging is enabled, using the Event Definition 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 conjunction with MCM 27, for testing when the call rate is low. Supporting Data: Ocean region, mobile number, message reference number, start time, signal LUN, call direction. Corrective action: None MCM 27 : Call completed Explanation: Logs end of call to/from mobile and call outcome. Use in conjunction with MCM 26 11-20

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

Event Messages

refer to that event for more details. Supporting Data: Ocean region, mobile number, message reference number, start time, TDM LUN, call completion code, call direction. Corrective action: None MCM 28 : Call pended Explanation: Call waiting to continue depending on resource availability. Supporting Data: Ocean region, mobile number, message reference number, start time, signal LUN, call direction. Corrective action: None MCM 29 : Call not Congested Explanation: Call which earlier had been held up due to congestion now able to continue. Supporting Data: Ocean region, mobile number, message reference number, start time, signal LUN, call direction. Corrective action: None MCM 30 : Congestion on the TDM Explanation: TDM is congested. Whilst this condition remains messages cannot be transmitted by the 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 out of service to limit shore to mobile traffic. When this event is raised frequently, additional TDM group 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 following 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
11-21

Event Messages

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

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 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 42 : Land Mobile Alert Packet Received Explanation: Land Alert Packet received from the MES. Supporting Data: Ocean region, station number, mobile number, return id. 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 LES Mobile 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. This report will be deleted by the LES. Besides checking that the DNID is not be among those used by the 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, contact the 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 the LES. This report will be deleted by the LES. Besides checking that the LES ID is correctly set for the 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, contact the mobile owner to arrange for re-programming. MCM 60 : Standalone mode entrance complete
11-22

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

Event Messages

Explanation: This is generally reported when the LES enters Standalone mode as a result of the operator using the LES Management SOC form. Supporting Data: Ocean region. Corrective action: None MCM 61 : Standalone mode Exit complete Explanation: This is generally reported when the LES leaves Standalone mode as a result of the operator using the LES Management SOC form. Supporting Data: Ocean region. Corrective action: None MCM 70 : Mobile login complete Explanation: A mobile has logged into the LES. Supporting Data: Mobile number, ocean region. Corrective action: None MCM 71 : Mobile logout complete Explanation: A mobile has logged out from the LES. Supporting Data: Mobile number, ocean region. Corrective action: None 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 number already 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.
11-23

Event Messages

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

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. Corrective action: None MCM 81 : Message Channel Inactive Explanation: No activity on a message channel. See section 7.10.5 for details. Supporting Data: Ocean region, LCU, slot, id. Corrective action: None MCM 82 : Signalling channel Active Explanation: Activity once again on signalling channel. Only occurs after event MCM 80. Supporting Data: Ocean region, LCU, slot, id. Corrective action: None MCM 83 : Message Channel Active Explanation: Activity once again on message channel. Only occurs after event MCM 81. Supporting Data: Ocean region, LCU, slot, id. Corrective action: None MCM 85 : Distress Message Assignment Request Explanation: This is the first indication of a distress message received by the LES. The operator should be looking for further events indicating successful delivery of the message. If this does not occur 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-24

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

Event Messages

Explanation: This is the first indication of a distress alert received by the LES. The operator should be looking for further events indicating successful delivery of the alert. If this does not occur the operator should instigate the local procedure for handling distress. Supporting Data: Ocean region, station number, mobile number. Corrective action: See local instructions for distress actions. MCM 87 : Distress Alert Received from Unregistered Mobile Explanation: As MCM 86 but where the mobile number cannot be determined. Supporting Data: Ocean region, station number, mobile number (default), return id. Corrective action: See local instructions for distress actions. MCM 88 : Distress Message Received from Unregistered Mobile Explanation: As MCM 85 but where the mobile number cannot be determined. Supporting Data: Ocean region, station number, mobile number (default), return id. Corrective action: See local instructions for distress actions. 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 TDM Group Management SOC form. Informs the operator that the TDM is now ready to broadcast messages. Supporting Data: Ocean region, station number, TDM group.
11-25

Event Messages

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

Corrective action: None 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 TDM Group Management SOC form. Informs the operator that the TDM can no longer be used to broadcast 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 Corrective action: None MCM 99 : TDM Group outbound lower limit reached Explanation: The load for that TDM has been reduced to the minimum level allowed by the system. Supporting Data: Ocean region, TDM group, new level Corrective action: None 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). Supporting Data: Ocean region, TDM group, new level Corrective action: None 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 same TDM as before. The LES will allow this second attempt, but alerts the operator to advise him of this protocol violation. Supporting Data: Ocean region, spot, mobile number. Corrective action: Advise mobile owner to change mobile software to handle protocols correctly.
11-26

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

Event Messages

MCM 103 : Registration Update Request packet sent to the NCS Explanation: Supporting Data: Ocean Region: <WOR,AOR,POR,IOR>, Mobile Number: <490000000> OR Ocean Region: <WOR,AOR,POR,IOR>, Forward Id : <11223344> OR Ocean 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. Supporting Data: None 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 maximum threshold. Supporting data: congested queue id Corrective action: None. The number of packets allowed to enter the queue will be reduced and, in necessary, 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 packets in the queue has been reduced to a set lower threshold. The queue will now resume normal operation. Supporting data: Number of discarded packets. Corrective action: None 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 successful 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 will cause the TDM to be released and then automatically requested immediately by the LES)
11-27

Event Messages

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

Note: for all MDIR and MSCH events: message ID - includes the messages priority, message kind, message reference number, ICR call serial number, and originator raw address. If the specified message is a delivery notification, the message ID also includes the original messages message kind, message reference number, and ICR call serial number. delivery ID - includes the message ID, and the deliverys destination number (its index in the destination list for the message), destination raw address, and DCR call serial number. delivery status - includes the deliverys current retry count, delivery attempt count, and call completion code. route ID - for satellite TDM routes, includes the ocean region, and spot beam ID; for satellite ISL routes, includes the ocean region; and, for terrestrial routes, includes the route number. Reload counts - includes the number of message details or delivery statuses selected to be fetched from the LES Database, and the number fetched so far. Bulk cancellation request - specifies which messages are to be bulk cancelled and the request number. Bulk cancellation response - specifies how many messages will be or would have been bulk cancelled and the request number. Bulk cancellation summary - specifies how many messages actually were bulk cancelled and the request number. Bulk cancellation ID - specifies the ID of a message that was queued up to be bulk cancelled and the request number. MDIR 2 : NDN not delivered and not spilled out Explanation: An NDN could not be delivered to the registered users 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 supporting 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 in service, is it correctly defined in the NDN Spill-out Destination Definition form. Refer to local instructions 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 users 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 supporting 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-28

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

Event Messages

service, is it correctly defined in the NDN Spill-out Destination Definition form. Refer to local instructions 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. Corrective action: None MDIR 5 : Route has become unavailable Explanation: A delivery route has been made unavailable to Message Handler by an output driver. Supporting Data: Route ID. 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 the country code or routing tables have not been configured correctly. The country code tables are normally configured to ensure invalid destination addresses are rejected at the address validation stage, before routing is attempted. The delivery is given call completion code 901 (routing failed) and is considered to have failed. Supporting Data: Delivery ID, delivery status. 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 the country code or routing tables have not been configured correctly, as for MDIR 6, but more probably, because there is no further destination address for a delivery notification, in which case MDIR 2 or 3 will also be raised. The delivery is given call completion code 902 (rerouting failed) and is considered to have failed. Supporting Data: Delivery ID, delivery status. 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 output driver. Supporting Data: (Primary_only/Secondary_only/Primary_and_secondary), route ID. Corrective action: None MDIR 9 : MRCC route has become unavailable Explanation: An MRCC delivery route has been made unavailable to Message Handler by an output driver.
11-29

Event Messages

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

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 Message Handler (500 by default) has been reached. Supporting Data: Route ID. Corrective action: check that all lines are in service. If the event is raised frequently, additional capacity may be needed. MDIR 12 : Maximum queue length reached, Distress only accepted Explanation: The configured maximum number of deliveries queued for a route in Message Handler (500 by default) has been reached. The system is only able to accept distress messages for this route. However, delivery notifications are still generated for this route. Supporting Data: Route ID. Corrective action: check that all lines are in service. If the event is raised frequently, additional capacity may be needed. MDIR 17 : 50 percent of maximum messages exceeded Explanation: 50% of the configured maximum number of deliveries in Message Handler (2000 by default) has been reached. Supporting Data: None. Corrective action: check that all lines are in service. If the event is raised frequently, additional capacity may be needed. MDIR 20 : 80 percent of maximum messages exceeded Explanation: 80% of the configured maximum number of deliveries in Message Handler (2000 by default) has been reached. Supporting Data: None. Corrective action: check that all lines are in service. If the event is raised frequently, additional capacity may be needed. MDIR 25 : 90 percent of maximum messages exceeded Explanation: 90% of the configured maximum number of deliveries in Message Handler (2000 by default) has been reached. Supporting Data: None. Corrective action: check that all lines are in service. If the event is raised frequently, additional capacity may be needed. MDIR 30 : Maximum number of messages exceeded, Distress only accepted
11-30

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

Event Messages

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, delivery notifications are still generated. Supporting Data: None. Corrective action: check that all lines are in service. If the event is raised frequently, additional capacity may be needed. 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. Supporting Data: None. Corrective action: check that all lines are in service. If the event is raised frequently, additional capacity may be needed. MDIR 50 : Reloading message details from LES Database Explanation: Message Handler has started reloading the old message details from the LES Database, for the messages that were live when the Master BAP left Running state. This happens in parallel with handling new message details when the Master BAP reaches Running state until all the old message details have been reloaded or an error occurs. Supporting Data: Message details reload counts. Corrective action: None. MDIR 51 : All message details reloaded from LES Database Explanation: Message Handler has successfully reloaded all the old message details from the LES Database. Supporting Data: Message details reload counts. Corrective action: None. MDIR 52 : Not all message details reloaded from LES Database Explanation: Message Handler has not successfully reloaded all the old message details from the LES Database. Delivery of the messages for which the message details could not be reloaded will not be completed until corrective action is taken by HNS. The supporting data indicates how many message details were not reloaded, and thus whether the problem needs urgent attention. Supporting Data: Message details reload counts. Corrective action: Contact HNS. MDIR 55 : Reloading delivery statuses from LES Database Explanation: Message Handler has started reloading the old delivery statuses from the LES Database, for the messages that have been delivered remotely by the X.400 or Fax Drivers using third-party store-and-forward systems while their message details were not live in the Master BAP.
11-31

Event Messages

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

This happens in parallel with handling new delivery statuses when the Master BAP reaches Running state, once Message Handler has stopped reloading old message details from the LES Database, until all the delivery statuses have been reloaded or an error occurs. Then only new delivery statuses will be handled. Before Message Handler has stopped reloading old message details from the LES Database, new delivery statuses for messages that have been delivered remotely are created in the LES Database, to be reloaded when their message details are live. Supporting Data: Delivery statuses reload counts. Corrective action: None. MDIR 56 : All delivery statuses reloaded from LES Database Explanation: Message Handler has successfully reloaded all the old delivery statuses from the LES Database. Supporting Data: Delivery statuses reload counts. Corrective action: None. MDIR 57 : Not all delivery statuses reloaded from LES Database Explanation: Message Handler has not successfully reloaded all the old delivery statuses from the LES Database. Although delivery of the messages for which the delivery statuses could not be reloaded may have been completed, generation of delivery notifications for them will not be completed until corrective action is taken by HNS. This may happen if not all the old message details were reloaded from the LES Database. The supporting data indicates how many delivery statuses were not reloaded, and thus whether the problem needs urgent attention or not. Supporting Data: Delivery statuses reload counts. Corrective action: Contact HNS. 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 to a delivery of a message for which Message Handler is generating a delivery notification. This is a configuration error. Supporting Data: Delivery ID, delivery status. 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 queued up for cancellation in response to a non-actionable bulk cancellation request. The supporting data specifies 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-32

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

Event Messages

up for cancellation in response to a non-actionable bulk cancellation request. The supporting data specifies how many messages would have been bulk cancelled if the request had been actionable and the request number. Supporting Data: Bulk cancellation response. Corrective action: none. MDIR 75 : Actionable bulk message cancellation request received Explanation: Message Handler has started queuing up the messages for cancellation in response to an actionable bulk cancellation request. The supporting data specifies which messages are to be bulk cancelled and the request number. Supporting Data: Bulk cancellation request. Corrective action: none. MDIR 76 : Actionable bulk message cancellation request queued up Explanation: Message Handler has finished queuing up the messages for cancellation in response to an actionable bulk cancellation request. The supporting data specifies how many messages will be bulk cancelled and the request number. Supporting Data: Bulk cancellation response. Corrective action: none. MDIR 77 : Actionable bulk message cancellation request completed Explanation: Message Handler has finished cancelling the messages queued up for cancellation in response to an actionable bulk cancellation request. The supporting data specifies how many messages actually were bulk cancelled and the request number. Supporting Data: Bulk cancellation summary. Corrective action: none. MDIR 80 : Message bulk cancelled Explanation: Message Handler has cancelled a message that was queued up for cancellation in response to an actionable bulk cancellation request. The supporting data specifies the ID of the message that was cancelled and the request number. Supporting Data: Bulk cancellation ID. Corrective action: none. MDIR 81 : Message not bulk cancelled because delivery completed Explanation: Message Handler has not cancelled a message that was queued up for cancellation in response to an actionable bulk cancellation request because delivery of the message was completed before it could be cancelled. The supporting data specifies the ID of the message that was not cancelled and the request number. Supporting Data: Bulk cancellation ID.
11-33

Event Messages

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

Corrective action: none. 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. Corrective action: none. MDIR 100 : Message for operator received Explanation: A message from a mobile addressed to the operator has been received and will be written to the operator message log. Supporting Data: Delivery ID, delivery status. Corrective action: The message can be printed on the report printer as described in section 8.3.10. MDIR 105 : Failed to log operator message Explanation: An error occurred writing an operator message to the operator message log. The operator message will not appear in the SOC viewer online operator message report. This is very unlikely. Supporting Data: Delivery ID, delivery status. 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 to the distress message log. The distress message will not appear on the alarm printer, in the SOC distress message forms, or in the SOC viewer online distress message report. This is very unlikely. 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 message log. The distress message can be viewed on the alarm printer, in the SOC distress message forms, or in the SOC viewer online distress message report. Supporting Data: Delivery ID, delivery status. Corrective action: See local instructions for handling distress. MDIR 141 : Distress EGC delivery succeeded Explanation: An EGC distress delivery has succeeded. Supporting Data: Delivery ID, delivery status.
11-34

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

Event Messages

Corrective action: See local instructions for handling distress. MDIR 142 : Distress EGC delivery attempt failed Explanation: An EGC distress delivery attempt has failed. The delivery is being retried. Supporting Data: Delivery ID, delivery status. Corrective action: See local instructions for handling distress. MDIR 143 : Distress EGC delivery failed Explanation: An EGC distress delivery has failed. Supporting Data: Delivery ID, delivery status. Corrective action: See local instructions for handling distress. MDIR 145 : Distress shore-originated message received Explanation: A shore-originated distress message 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, or in the SOC viewer online distress message report. Supporting Data: Delivery ID, delivery status. Corrective action: See local instructions for handling distress. MDIR 146 : Distress shore-originated delivery succeeded Explanation: A shore-originated distress delivery has succeeded. Supporting Data: Delivery ID, delivery status. Corrective action: See local instructions for handling distress. MDIR 147 : Distress shore-originated delivery attempt failed Explanation: A shore-originated distress delivery attempt has failed. The delivery is being retried. Supporting Data: Delivery ID, delivery status. Corrective action: See local instructions for handling distress. MDIR 148 : Distress shore-originated delivery failed Explanation: A shore-originated distress delivery has failed. Supporting Data: Delivery ID, delivery status. Corrective action: See local instructions for handling distress. MDIR 150 : Distress mobile-originated message received Explanation: A mobile-originated distress message 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 dis11-35

Event Messages

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

tress message forms, or in the SOC viewer online distress message report. Supporting Data: Delivery ID, delivery status. Corrective action: See local instructions for handling distress. MDIR 151 : Distress mobile-originated delivery succeeded Explanation: A mobile-originated distress delivery has succeeded. Supporting Data: Delivery ID, delivery status. Corrective action: See local instructions for handling distress. MDIR 152 : Distress mobile-originated delivery attempt failed Explanation: A mobile-originated distress delivery attempt has failed. The delivery is being retried. Supporting Data: Delivery ID, delivery status. Corrective action: See local instructions for handling distress. MDIR 153 : Distress mobile-originated delivery failed Explanation: A mobile-originated distress delivery has failed. Supporting Data: Delivery ID, delivery status. Corrective action: See local instructions for handling distress. 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, or in the SOC viewer online distress message report. Supporting Data: Delivery ID, delivery status. Corrective action: See local instructions for handling distress. MDIR 156 : Distress alert delivery succeeded Explanation: A distress alert delivery has succeeded. Supporting Data: Delivery ID, delivery status. Corrective action: See local instructions for handling distress. MDIR 157 : Distress alert delivery attempt failed Explanation: A distress alert delivery attempt has failed. The delivery is being retried. Supporting Data: Delivery ID, delivery status. Corrective action: See local instructions for handling distress.
11-36

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

Event Messages

MDIR 158 : Distress alert delivery failed Explanation: A distress alert delivery has failed. Supporting Data: Delivery ID, delivery status. Corrective action: See local instructions for handling distress. 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, or in the SOC viewer online distress message report. Supporting Data: Delivery ID, delivery status. Corrective action: See local instructions for handling land alerts. MDIR 161 : Land mobile alert delivery succeeded Explanation: A land mobile alert delivery has succeeded. Supporting Data: Delivery ID, delivery status. Corrective action: See local instructions for handling land alerts. MDIR 162 : Land mobile alert delivery attempt failed Explanation: A land mobile alert delivery attempt has failed. The delivery is being retried. Supporting Data: Delivery ID, delivery status. Corrective action: See local instructions for handling land alerts. MDIR 163 : Land mobile alert delivery failed Explanation: A land mobile alert delivery has failed. Supporting Data: Delivery ID, delivery status. Corrective action: See local instructions for handling land alerts. MSCH 40 : Distress EGC delivery delayed Explanation: An EGC distress delivery has been delayed in Message Handler for more than a certain period (45 seconds by default). Message Handler is waiting for the delivery time to expire or delivery route resources to become available. Supporting Data: Delivery ID, delivery status. Corrective action: See local instructions for handling distress. MSCH 41 : Distress EGC delivery stuck active Explanation: An EGC distress delivery has been in the active queue of the Message Scheduler for longer than the maximum delivery time for the type of delivery route and the length of the mes11-37

Event Messages

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

sage. The delivery may be stuck within the delivery driver. Supporting Data: Delivery ID, delivery status. 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 has now been dequeued from the Message Scheduler. Supporting Data: Delivery ID, delivery status. Corrective action: None. MSCH 45 : Distress shore-originated delivery delayed Explanation: A shore-originated distress delivery has been delayed in Message Handler for more than a certain period (45 seconds by default). Message Handler is waiting for the delivery time to expire or delivery route resources to become available. Supporting Data: Delivery ID, delivery status. Corrective action: See local instructions for handling distress. MSCH 46 : Distress shore-originated delivery stuck active Explanation: A shore-originated distress delivery has been in the active queue of the Message Scheduler for longer than the maximum delivery time for the type of delivery route and the length of the message. The delivery may be stuck within the delivery driver. Supporting Data: Delivery ID, delivery status. Corrective action: See local instructions for handling distress. For deliveries to TDM routes, check if a large number of active calls on the TDM is causing calls to be pended. If this does not explain the event, contact HNS. MSCH 47 : Distress shore-originated delivery unstuck Explanation: A shore-originated distress delivery which may have been stuck within the delivery driver has now been dequeued from the Message Scheduler. Supporting Data: Delivery ID, delivery status. Corrective action: None. MSCH 50 : Distress mobile-originated delivery delayed Explanation: A mobile-originated distress delivery has been delayed in Message Handler for more than a certain period (45 seconds by default). Message Handler is waiting for the delivery time to expire or delivery route resources to become available. Supporting Data: Delivery ID, delivery status. Corrective action: See local instructions for handling distress.
11-38

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

Event Messages

MSCH 51 : Distress mobile-originated delivery stuck active Explanation: A mobile-originated distress delivery has been in the active queue of the Message Scheduler for longer than the maximum delivery time for the type of delivery route and the length of the message. The delivery may be stuck within the delivery driver. Supporting Data: Delivery ID, delivery status. Corrective action: See local instructions for handling distress. Contact HNS. MSCH 52 : Distress mobile-originated delivery unstuck Explanation: A mobile-originated distress delivery which may have been stuck within the delivery driver has now been dequeued from the Message Scheduler. Supporting Data: Delivery ID, delivery status. Corrective action: None. MSCH 55 : Distress alert delivery delayed Explanation: A distress alert delivery has been delayed in Message Handler for more than a certain period (45 seconds by default). Message Handler is waiting for the delivery time to expire or delivery route resources to become available. Supporting Data: Delivery ID, delivery status. Corrective action: See local instructions for handling distress. MSCH 56 : Distress alert delivery stuck active Explanation: A distress alert delivery has been in the active queue of the Message Scheduler for longer than the maximum delivery time for the type of delivery route and the length of the message. The delivery may be stuck within the delivery driver. Supporting Data: Delivery ID, delivery status. Corrective action: See local instructions for handling distress. Contact HNS. MSCH 57 : Distress alert delivery unstuck Explanation: A distress alert delivery which may have been stuck within the delivery driver has now been dequeued from the Message Scheduler. Supporting Data: Delivery ID, delivery status. Corrective action: None. MSCH 60 : Land mobile alert delivery delayed Explanation: A land mobile alert delivery has been delayed in Message Handler for more than a certain period (45 seconds by default). Message Handler is waiting for the delivery time to expire or delivery route resources to become available. Supporting Data: Delivery ID, delivery status.
11-39

Event Messages

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

Corrective action: See local instructions for handling distress. MSCH 61 : Land mobile alert delivery stuck active Explanation: A land mobile alert delivery has been in the active queue of the Message Scheduler for longer than the maximum delivery time for the type of delivery route and the length of the message. The delivery may be stuck within the delivery driver. Supporting Data: Delivery ID, delivery status. Corrective action: See local instructions for handling distress. Contact HNS. MSCH 62 : Land mobile alert delivery unstuck Explanation: A land mobile alert delivery which may have been stuck within the delivery driver has now been dequeued from the Message Scheduler. Supporting Data: Delivery ID, delivery status. Corrective action: None. MSCH 66 : Normal shore-originated delivery stuck active Explanation: A normal shore-originated delivery has been in the active queue of the Message Scheduler for longer than the maximum delivery time for the type of delivery route and the length of the message. The delivery may be stuck within the delivery driver. Supporting Data: Delivery ID, delivery status. Corrective action: For deliveries to TDM routes, check if a large number of active calls on the TDM is 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 delivery driver has now been dequeued from the Message Scheduler. Supporting Data: Delivery ID, delivery status. Corrective action: None. MSCH 71 : Normal mobile-originated delivery stuck active Explanation: A normal mobile-originated delivery has been in the active queue of the Message Scheduler for longer than the maximum delivery time for the type of delivery route and the length of the message. The delivery may be stuck within the delivery driver. Supporting Data: Delivery ID, delivery status. 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 delivery driver has now been dequeued from the Message Scheduler.
11-40

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

Event Messages

Supporting Data: Delivery ID, delivery status. Corrective action: None. Note: For PRC events supporting data is normally included ONLY in the Affected Object field and NOT 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 the BAP and the arbiter, although the arbiter may have failed in such a way that it can only talk to one BAP. If reported from both BAPs indicates a problem with the arbiter itself. In the latter case automatic switchovers will not be possible. Recovery actions include: check cabling and replace if necessary, reset arbiter, replace arbiter. PRC 2 : Arbiter available Explanation: Arbiter now functional. Supporting Data: BAP. Corrective action: None 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 the BAP and the switch controller, although the switch controller may have failed in such a way that it can only talk to one BAP. If reported from both BAPs indicates a problem with the switch controller itself. 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. Corrective action: None PRC 20 : FEP Switchover Explanation: Switchover as a result of operator command or failure detected in master or master FEP has rebooted. Supporting Data: Name of new master FEP. Corrective action: None
11-41

Event Messages

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

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 maintenance. PRC 22 : Standby FEP Failed Explanation: Standby FEP reported a failure. The system will continue to operate normally but with 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 maintenance. PRC 23 : Master FEP Up Explanation: Information that the master FEP has successfully completed its startup sequence and is now ready for use. Supporting Data: Name of master FEP. Corrective action: None PRC 24 : Standby FEP Up Explanation: Information that the standby FEP has successfully completed its startup sequence and is now ready for use. Supporting Data: Name of standby FEP. Corrective action: None PRC 25 : FEP Switch Unit Failure Explanation: Failure in FEP switch card or communications with the card. Supporting Data: Name of master FEP. Corrective action: Check indications on switch controller card; if incorrect, try spare in the same position, then check cabling. If fault clears after a BAP switchover, call DEC maintenance to check the BAP port connected to the switch controller. PRC 26 : FEP Switch Unit Up Explanation: FEP switch unit now available. Supporting Data: Name of master FEP. Corrective action: None PRC 27 : Unable to Switch FEP Lines
11-42

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

Event Messages

Explanation: Switchover card not responding. Supporting Data: Name of master FEP. 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 be master. Supporting Data: None. Corrective action: None 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. Supporting Data: None. Corrective action: None, this is the result of manual action. But note that in this mode, the BAPs are 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. Supporting Data: Disk name. 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 over data from the other member in order for the disks to contain the same data. Supporting Data: Disk name. Corrective action: None PRC 33 : Shadow Disk Set Member Synchronised Explanation: Following beginning of synchronization with the other member of the shadow set after a member has been remounted this event reports that the synchronization has now completed. Supporting Data: Disk name.
11-43

Event Messages

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

Corrective action: None PRC 34 : All Shadow Disk Set Members Dismounted Explanation: All members of the shadow disk set dismounted. Note that this will mean the LES will lose data which cannot be recovered and the LES will cease to function. Supporting Data: None. 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 processors. Note: if the quorum disk is dismounted when one of the VAXes is not running, i.e. it is neither Master or Standby BAP, the cluster configuration will be lost and the system will be put out of service. Supporting Data: Disk name. Corrective action: None - this is the result of operator action. PRC 36 : Quorum Disk Remounted Explanation: Quorum Disk Remounted. Supporting Data: Disk name. Corrective action: None - this is the result of operator action. PRC 37 : System Disk Unavailable Explanation: System Disk Unavailable. This will either lead to a degradation of the system or a switchover. Supporting Data: Disk name. Corrective action: Call DEC maintenance. PRC 38 : System Disk Available Explanation: System Disk Available. Supporting Data: Disk name. Corrective action: None 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-44

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

Event Messages

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. Corrective action: None PRC 44 : Standby BAP Up Explanation: Standby BAP reports it is now up and running. Supporting Data: Name of standby BAP. Corrective action: None PRC 45 : BAP switchover start Explanation: Indicates start of a switchover either initiated by operator command or as a result of failure on the BAP. Corrective action: None, for this event on its own. Supporting Data: None. PRC 46 : BAP to FEP handshake established Explanation: Communication between BAP and FEP has once again been restored following an earlier failure. Event DIM 10 may occur before this. Supporting Data: FEP ID. Corrective action: None PRC 47 : BAP to FEP handshake failed Explanation: Indicates loss of communication between BAP and FEP. This will occur if after a period of 75 seconds no message has been received by the BAP (FEPs send a message to a BAP indicating it is alive on average every 15 seconds). Additional information will be found in event DIM 20. Supporting Data: FEP ID. 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,
11-45

Event Messages

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

now established. Supporting Data: None. Corrective action: None PRC 49 : Master BAP detects handshake failure Explanation: The master BAP has sent a message to the standby BAP indicating it is alive but has received no such message from the standby BAP. Supporting Data: None. Corrective action: Investigate the state of the DECNET link between the two BAPs. If OK check the 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. Supporting Data: None. Corrective action: Investigate the state of the DECNET link between the two BAPs. If OK check the 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 automatic switchovers are enabled. Supporting Data: Name of VMS process. Corrective action: Check the current states of each task by using the BAPOP command Show State. 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 state change 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-46

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

Event Messages

Explanation: Task which failed earlier has restarted. Supporting Data: Name of task. Corrective action: None PRC 65 : Processor shutdown Explanation: Orderly shutdown initiated from BAP. Only the event relating to the standby BAP gets reported. Supporting Data: BAP ID. Corrective action: None PRC 66 : Processor restarted Explanation: Automatic start of a BAP which has previously failed. Supporting Data: BAP ID. Corrective action: None PRC 67 : No FEP available for Master Operation Explanation: The master FEP has failed but switchover is not possible because there is no standby FEP. Supporting Data: FEP ID. Corrective action: Investigate the failure of both the FEPs. Try restarting each one. If FEPs continue 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 performance on the affected BAP will degrade and eventually not function. Supporting Data: None. 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 for management 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 to operate normally. Supporting Data: None. Corrective action: None PRC 72 : Shadow set being rebuilt by merging
11-47

Event Messages

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

Explanation: A situation has occurred earlier where one member of the shadow set has been offline and the system is causing the data from the other disk to be copied to it. Supporting Data: None. Corrective action: None PRC 73 : Virtual Memory is low Explanation: System resources are insufficient to allow the system to operate efficiently. Supporting Data: None. Corrective action: Restart the BAP. PRC 74 : Virtual Memory is available Explanation: The virtual memory low problem reported earlier has gone away. Supporting Data: None. Corrective action: None PRC 110 : Database Transaction Log has Reached Warning Level Explanation: Supporting Data: Perform a BAP switch if recovery does not occur - PRC 111. Corrective action: None PRC 111 : Database Transaction Log Recovered Explanation: Supporting Data: None. Corrective action: None PRC 112 : Database size has reached Warning Level Explanation: Database usage has exceeded the level defined by DB_SPACE_WARNING in PRC$EXE:PRC_CNTL_VALUES.INI Supporting Data: None. Corrective action: None 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 not defined in PRC$EXE:PRC_CNTL_VALUES.INI Supporting Data: None.
11-48

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

Event Messages

Corrective action: None PRC 114 : Database size has reached Critical Level Explanation: Database usage has exceeded the level defined by DB_SPACE_CRITICAL in PRC$EXE:PRC_CNTL_VALUES.INI. Supporting Data: None. 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 not defined in PRC$EXE:PRC_CNTL_VALUES.INI. Database usage is still above the Warning level. Supporting Data: None. Corrective action: None SDC 1 : Satellite FEP start up complete Explanation: Satellite FEP start up complete. This is raised when the FEP becomes MASTER Running. After that, the download of configuration data will start. Once this completes, the event FEP download complete is raised. Supporting Data: Corrective action: None 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. Corrective action: None SDC 12 : TDM Group Not Operational Explanation: TDM Group not in operation. Reason indicated in supplementary data. This event can be filtered, as described in section 11.4. Supporting Data: Ocean Region, TDM Group ID, Supplementary Data. Supplementary Data comprises a single digit in the range 0 - 5 whose meanings are: 0 - Run Status Not Online 1 - No Frame Timing Reference 2 - Inconsistent Configuration Data 3 - TDM Modulator Not Operational 4 - No Signalling Channels 5 - TDM Reconfiguring Corrective action: None for this event on its own, since it could be caused by NCS or operator action. Any failure would have another event identifying the cause more precisely.
11-49

Event Messages

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

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 the NCS. SDC 21 : Multidrop line Operational Explanation: Now able to communicate with the channel units over the multidrop line. Supporting Data: Ocean Region, Multidrop Line. Corrective action: None SDC 22 : No response on Multidrop line Explanation: no acknowledgement received on the multidrop line between the channel unit controllers (satellite driver FEPs) and the channel units. Supporting Data: Ocean Region, Multidrop Line. Corrective action: If only one multidrop line is affected, the possible causes are the BIM on the CU half-chassis, the RS-232 switch card for that line on the switchover tray in the CUC rack, or the associated cabling. If all multidrop lines for one ocean region fail, the possible causes are a general failure in the switchover tray in the CUC rack or a general failure, e.g. all power, in the channel unit rack. If only one channel unit is served by the multidrop line (i.e. only one operational on 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. Supporting Data: Ocean Region, Multidrop Line. Corrective action: None SDC 31 : Physical CU has become operational Explanation: Reported towards the end the CU start up sequence and indicates that the channel unit is now available to handle traffic. This event can be filtered, as described in section 11.4. Supporting Data: Ocean Region, Chassis ID, Chassis Slot. Corrective action: None SDC 32 : Physical CU has been deleted Explanation: This is raised when a physical channel unit is deleted using the Physical Channel Unit Definition form. Supporting Data: Corrective action: None
11-50

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

Event Messages

SDC 33 : Physical CU has reported failure Explanation: a channel unit has returned a response over the multidrop which indicates that it has failed. This event can be filtered, as described in section 11.4. Supporting Data: Ocean Region, Chassis ID, Chassis Slot. Corrective action: Check the HEX display on the front of the channel unit. If the fault indicates an internal failure, change the module. If an external failure is indicated, check the source of the signal. E.g. if a TDM demod has lost its input, check the TDM Mod; if an ISL demod has lost its input, contact the NCS. SDC 34 : Physical CU failure has been detected Explanation: The software is not able to communicate with a channel unit. Supporting Data: Ocean Region, Chassis ID, Chassis Slot. Corrective action: If this is reported for one channel unit only, the channel unit itself is most likely at fault (isolated instances can be ignored). If a group of channel units in one half chassis are reported as faulty, communications over the multidrop line from the CUC FEP to the channel unit rack has been lost. This can be caused by a failure in the RS-232 switch card in the CUC switchover 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. Corrective action: None SDC 42 : MTM Clock is OK Explanation: MTM clock which had previously failed now ok. Supporting Data: Ocean Region, ALD Line Number. Corrective action: None SDC 43 : MTM Clock Failed Explanation: Failure reported, via the ASM, of the master timing module. Supporting Data: Ocean Region, ALD Line Number. Corrective action: Check MTM, and replace if necessary, as described in the Channel Unit Rack Maintenance 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 Auto mode. Supporting Data: Ocean Region, ALD Line Number.
11-51

Event Messages

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

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 Manual mode. Supporting Data: Ocean Region, ALD Line Number. 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. Supporting Data: Ocean Region, ALD Line Number. Corrective action: None SDC 52 : Control Rack Power Supply Failed Explanation: May need to replace power supply. Supporting Data: Ocean Region, ALD Line Number. Corrective action: Check input to power supply. Follow procedures defined in the Channel Unit Maintenance Manual. SDC 61 : Control Rack Blower OK Explanation: Control Rack Blower which had previously failed now OK. Supporting Data: Ocean Region, ALD Line Number. Corrective action: None 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, replacement of failed blower is necessary. (The rack can continue to operate with one failed blower for some time, depending on the ambient temperature.) If no blowers are operational, check the power wiring to the PSUs at the bottom of the rack. See the Channel Unit Maintenance Manual for details. SDC 71 : Communications with Alarm Switchover module established Explanation: Communications which had previously failed now established. Supporting Data: Ocean Region. Corrective action: None
11-52

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

Event Messages

SDC 72 : Communications with Alarm Switchover module failed Explanation: No communications over the link from the channel unit controller to the ASM on the channel unit rack. Supporting Data: Ocean Region. Corrective action: Check indication on ASM. If SCP fail LED is lit, the fault is either in the CUC FEP or the connection between the FEP and the ASM via the switchover tray. If the SCP fail LED is 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 transmitted from 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 the ISL 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. Corrective action: None SDC 102 : Signalling Channel Not Operational Explanation: Demodulator not operational. This event can be filtered, as described in section 11.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,
11-53

Event Messages

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

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. Corrective action: None 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. Supporting Data: Ocean Region, Chassis ID, Chassis Slot. Corrective action: None SDC 112 : PCU deassigned from a LCU Explanation: Physical channel unit no longer assigned a specific usage. Supporting Data: Ocean Region, Chassis ID, Chassis Slot. Corrective action: None SDC 113 : LCU in service Explanation: Logical Channel Unit now available for use. Supporting Data: Ocean Region, Chassis ID, Chassis Slot. Corrective action: None SDC 114 : LCU out of service Explanation: Logical Channel Unit no longer available for use. Supporting Data: Ocean Region, Chassis ID, Chassis Slot. Corrective action: None SDC 115 : LCU taken out for maintenance Explanation: The operator has taken an LCU out of service an put it in the maintenance state. Supporting Data: Ocean Region, Chassis ID, Chassis Slot. Corrective action: None SDC 116 : LCU Undefined Explanation: The operator has deleted the definition of an LCU. Supporting Data: Ocean Region, Chassis ID, Chassis Slot.
11-54

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

Event Messages

Corrective action: None 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 Pool Definition SOC form. Supporting Data: Ocean Region, Pool ID, Pool Name, Chassis ID, Chassis Slot. Corrective action: None 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. Supporting Data: Ocean Region, Chassis ID, Chassis Slot. Corrective action: None 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. Corrective action: None 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 the complement of event SDC 120. Supporting Data: Ocean Region, Logical Channel Unit ID, Chassis ID, Chassis Slot. Corrective action: None SDC 123 : ISL Demodulator has lost the carrier Not used.
11-55

Event Messages

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

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 Overrun Y/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 is responsible 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 been successful. Supporting Data: Corrective action: None SDC 131 : Frequency of Timing TDM Rx Channel has changed Explanation: The software will search for a frequency to assign the TDM Demodulator which is responsible 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 occurred and been successful. Supporting Data: Corrective action: None 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 is responsible 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 been successful. 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. Corrective action: None SDC 141 : Message Channel Not Operational
11-56

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

Event Messages

Explanation: Message channel previously operational no longer is. (Confirm this by checking channel unit display.) Supporting Data: Ocean Region, TDM Group ID, Message Channel. Corrective action: None SDC 142 : Message Channel Deconfigured Explanation: Message Channel has been taken out of the TDM group. Supporting Data: Ocean Region, TDM Group ID, Message Channel. Corrective action: None SDC 160 : External Alarm Port ON Explanation: The ASM module on the channel unit rack monitors a number of places in the CUC and TIF racks, as indicated in the supporting data. This event is raised when the alarm condition on 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 CUC and TIF racks, as indicated in the supporting data. This event is raised when the alarm condition on 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.
11-57

Event Messages

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

Corrective action: investigate the indicated fault and take action as described in the Channel Unit Maintenance Manual or the CUC and TIF Rack Maintenance Manual according to the location of the fault. SOI 0 : SOC failure Explanation: The connection from a BAP to a SOC workstation has been lost. Several watchdog probe messages are expected from each workstation every minute. No probe messages have been received within one minute. Supporting Data: None. 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. Supporting Data: None. Corrective Action: None SOI 10 : SOC Form Request Explanation: Every time a SOC form operation is requested by an operator this event is raised to indicate Supporting Data: "SOI HAND x.Form: y,Function: z Data: " where x = y = z = the number of the window that has requested a SOC form. Current position in menu structure. The operation being performed by the operator, e.g Select, Modify etc.

Corrective Action: None 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 is made to exceed the maximum allowed number of SOC windows open. This is unlikely to occur and is a only transient situation. Supporting Data: None. Corrective Action: Wait a short amount of time and try to logon again. If it still occurs, remove unwanted 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-58

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

Event Messages

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. Supporting Data: Circuit number. Corrective Action: The most likely cause is that the circuit was backward busied after the call finished. TLX 2 : Station closed. (Leased Line No Clear Confirmation) Explanation: A leased line has been held at third condition (0v) for greater than 50ms. Supporting Data: Circuit number. Corrective Action: Check equipment at other end of line. TLX 3 : Clear confirmation was received after no clear confirmation Explanation: The line was returned to service after event TLX 1. Clear confirmation was received later than expected. Supporting Data: Circuit number. Corrective Action: The circuit will most likely be backward busied, and events for that condition will probably 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 time defined. Supporting Data: Circuit number. 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 Supporting Data: Circuit number. Corrective Action: None 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 of transmitted retests to be exceeded. Supporting Data: Circuit number. Corrective Action: Check equipment at other end of line. TLX 7 : Retests reverted to normal since exceeded threshold occurred Explanation: The circuit has returned to service after event TLX 6
11-59

Event Messages

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

Supporting Data: None. Corrective Action: None 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 of all 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 has been completed. Supporting Data: Circuit number. Corrective Action: None 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 second intervals (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 10 attempts. Note: circuit remains in service throughout. Supporting Data: Circuit number. 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. Supporting Data: Circuit number. Corrective Action: None 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-60

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

Event Messages

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 when the line is seized. For an incoming call this event is raised when the selection information indicates that the call is to a test mobile. Supporting Data: Circuit number. Corrective Action: None 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 the point where an incoming answerback has been received. Supporting Data: Circuit number and MRN. Corrective Action: None TLX 20 : Test call completed over circuit Explanation: The test call has been completed. Supporting Data: Circuit number, MRN and call completion code. Corrective Action: None 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 fault either 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 on startup and switchover. Supporting Data: Route number. Corrective Action: None
11-61

Event Messages

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

TLX 23 : Circuit is now in service and available Explanation: INS request completed or automatic recovery from failure (e.g. TLX 21) completed. Supporting Data: Circuit number. Corrective Action: None 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 supporting data describes the nature of the configuration error. If a line error is detected XCCC 3 will be raised 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. Supporting Data: Reason Code. Corrective Action: Action depends on reason code. In addition a DEMSA switchover sequence may be initiated. XCCC 4 : X25 line available Explanation: Line which had previously failed now available for use. Supporting Data: Reason Code. Corrective Action: None XCCC 5 : No LCNs available Explanation: Usually occurs in a load situation where for a period the system cannot handle any more calls.
11-62

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

Event Messages

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. Maintenance. 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 of the LES e.g. maximum packet size. Supporting Data: The supporting data depends on how the users configuration is incompatible with that of the LES. The returned message will be a brief description, followed by supporting data which may include: Diagnostic Code, Cause Code, Task ID, Remote DTE, DNID or Originators Address. 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.
11-63

If this is not successful, call out DEC

Event Messages

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

XCCC 12 : Remote protocol error Explanation: X25 call has failed due to failure in network. Unlike with "Internal protocol error" the problem is at the end remote from the LES. Supporting Data: Reason Code. Corrective Action: Contact network operator and give him the reason code which is included in the event. 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 exists, 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 an automatic BAP switchover to be initiated. Or, the X25 driver has been instructed to fail during a BAP 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. Supporting Data: None. Corrective Action: None XCCC 18 : X25 driver entered init state Explanation: Part of startup sequence. Supporting Data: None. Corrective Action: None XCCC 19 : X25 driver entered ready state
11-64

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

Event Messages

Explanation: Part of startup sequence. Supporting Data: None. Corrective Action: None XCCC 20 : X25 driver entered Running state Explanation: Part of startup sequence. Indicates X25 driver is now ready to accept calls. Supporting Data: None. Corrective Action: None XCCC 21 : X25 driver become Master Explanation: X25 driver has just become Master Supporting Data: None. Corrective Action: None XCCC 22 : X25 driver entered Standby state Explanation: X25 driver has just become Standby Supporting Data: None. Corrective Action: None XCCC 23 : X25 driver entered Idle state Explanation: X25 driver has just entered the Idle state Supporting Data: None. Corrective Action: None XCCC 24 : No storage available Explanation: Supporting Data: None. Corrective Action: None XCCC 25 : X25 driver entered End Running state Explanation: Part of switchover sequence. Indicates old master no longer running. Supporting Data: None. Corrective Action: None XCCC 26 : Test Call Initiated
11-65

Event Messages

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

Explanation: Call has been received to/from a test mobile. Supporting Data: The text "Incoming Test Message". Corrective Action: None XCCC 27 : Test Call Completed Explanation: Call has been delivered to/from test mobile. Supporting Data: Call Completion Code. Corrective Action: None XCCC 28 : Immediate Forwarding Facility Congested Explanation: All channels for the route are active. Supporting Data: None. Corrective Action: Provide more channels. XCCC 29 : Immediate Forwarding Facility Congestion Cleared Explanation: The previously reported congestion condition has now cleared. Supporting Data: None. Corrective Action: None XCCC 30 : Immediate Forwarding Channel Congested Explanation: Cannot get through on specific channel. Supporting Data: Route id, X121 address. Corrective Action: None XCCC 31 : Immediate Forwarding Channel Congestion Cleared Explanation: The previously reported congestion condition has now cleared. Supporting Data: None. Corrective Action: None XCCC 32 : Immediate Forwarding Delivery Failed Explanation: Cannot get through to a specific routes. See also alarms 35 and 36 Supporting Data: Address. Corrective Action: None XCCC 33 : Driver Memory Resource Shortage During DNID Retrieval
11-66

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

Event Messages

Explanation: Storage error exceptions occurring during DNID Retrievals indicate resource shortages in the X.25 Driver process. Supporting Data: None 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. The existing minor alarm 32 applies for forward-or-store). Once raised, no further failure alarms will be raised for that DNID during the current outage Alarming is based on DNIDs, not destination addresses. 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 raising of alarm 35. After which, the first failure alarm (32 or 35) will be raised again if/when another failure 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 further details which enable the operator to know exactly how the call failed. These details are shown under 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: STATE 2: STATE 3: STATE 4: The MES is not in the supported ocean region. The MES is in the supported ocean region. Wait (MES Assignment Request ISL packet received from NCS but LES is congested). Wait for congestion (MES Assignment Request SIG packet received but LES
11-67

Event Messages

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

is congested). STATE 6: STATE 61: STATE 62: STATE 71: STATE 72: STATE 73: STATE 75: STATE 90: STATE 91: STATE 92: The MES is in the supported region and an individual poll has been sent to the NCS. Wait (TEST) (Waiting for MES during the Performance Verification Test) Waiting for Distress Alert Test during the Performance Verification Test. Wait for NCS (Announce) (Waiting for NCS during the Announcement routine). Wait for MES reply (Announce) (Waiting for MES during the Announcement routine). Waiting for NCS during the Announcement routine and Announcement has been cancelled. Wait for NCS (Distress) (Waiting for NCS during the Distress routine). Waiting for CUC FEP during the Ship to Shore routine. Waiting for CUC FEP during the Shore to Ship routine. 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 the event. 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 Request EN02 - Message Status Request EN03 - MES Assignment Request EN04 - MES Status Request EN05 - Test Request EN06 - MES Status EN07 - Registration EN08 - Distress EN09 - MES Forced Clear EN10 - Distress Ack ENCS - General NCS packet EN20 - TDM Request Response EN21 - TDM Release Request EN22 - TDM Request Acknowledgement

11-68

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

Event Messages

The following events are associated with incoming MES SIG packet : ES01 - Announcement Response ES02 - Assignment Response ES03 - Clear ES04 - Distress Alert ES05 - Distress Alert Test ES06 - Forced Clear ES07 - Message Status Request ES08 - Transfer Status Request ES09 - Assignment Request ES10 - Data Report ESIG - General SIG packet The following are other events handled by MCM. These are not generally associated with any particular incoming packet. ET01 - Timer 1 expires ET02 - Timer 2 expires ET03 - Timer 3 expires ET04 - Timer 4 expires EC01 - CUC statistics indicate congestion cleared EC02 - CUC message received EC03 - CUC call status information EA01 - MDir activates new ship bound call EA02 - MDir activates Individual Poll call EA03 - MDir activates Confirmation call EA04 - MDir activates Test Request call ED01 - TDM being used for ship transfer ED02 - TDM released from ship transfer ED03 - TDM now operational The error codes used are defined as seven digit values. In the case of a protocol errors, the values indicate the State and type of event that has been received. Error Code = abbbbbb where a=0 - No Error bbbbbb=0 - No Error a=1 - Specific Protocol Error bbbbbb = ccdeef where cc=state d=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
11-69

Event Messages

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

a=2 - General Protocol Error bbbbbb = error number a=3 - CUC Error bbbbbb = 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 State SS01 Errors - MES not in OR MCM_SS01_EN01_MDIR_Error MCM_SS01_EN01_Already_Commissioned MCM_SS01_EN01_Mobile_Not_Registered MCM_SS01_EN03_SES_Not_Logged_In MCM_SS01_EN07_Unexpected_Status_In_Registration MCM_SS01_EN09_SES_Not_Logged_In MCM_SS01_ES09_Sub1_Cannot_Allocate_TDM_Group MCM_SS01_ES09_SES_Not_Logged_In MCM_SS01_ES09_Mobile_Not_Registered MCM_SS01_ES09_Mobile_Barred MCM_SS01_ES09_Sub2_Login_Failed_PVT MCM_SS01_EC01_Cant_Get_Event MCM_SS01_EA04_SES_Commissioned MCM_SS01_EA04_No_TDM MCM_SS01_EA04_No_Call MCM_SS01_EA04_Cannot_Allocate_TDM_Group MCM_SS01_EA04_No_SES MCM_SS01_EA04_Standalone MCM_SS01_EAIO_Not_In_OR State SS02 Errors - MES is in OR MCM_SS02_EN03_Bad_SES_Reply MCM_SS02_EN03_No_Pending_Event MCM_SS02_EN03_Announce_Fail MCM_SS02_EN03_Cannot_Allocate_TDM_Group MCM_SS02_EN03_Login_Failed_Announce MCM_SS02_EN03_Sub4_Login_Failed_Message MCM_SS02_EN05_Test_Req_MDIR_Err MCM_SS02_EN06_Unexpected_Mobile_Status MCM_SS02_EN07_Unexpected_Status_In_Registration MCM_SS02_ES09_Sub1_Cannot_Allocate_TDM_Group MCM_SS02_ES09_Sub2_Login_Failed_Message MCM_SS02_EC01_Cant_Get_Deferred_Event MCM_SS02_EA01_Sub2_Login_Failed_Message MCM_SS02_EA01_No_TDM_Deferred MCM_SS02_EA01_Cannot_Allocate_TDM_Group MCM_SS02_EA01_SUB1_Deferred_Mobile_Calling MCM_SS02_EA01_SUB1_Deferred_Mobile_Test MCM_SS02_EA01_Bad_SES_Reply
11-70

1000011

1011011 1011012 1011013 1011031 1011071 1011091 1012091 1012092 1012093 1012094 1012095 1014011 1015041 1015042 1015043 1015044 1015045 1015046 1015991

1021031 1021032 1021033 1021034 1021035 1021036 1021051 1021061 1021071 1022091 1022092 1024011 1025010 1025011 1025012 1025013 1025014 1025015

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

Event Messages

MCM_SS02_EA01_No_Pending_Event MCM_SS02_EA01_Announce_Fail MCM_SS02_EA01_Unsuccessful_Transfer MCM_SS02_EA01_Login_Failed_Announce MCM_SS02_EA04_PVT_Deferred_No_TDM MCM_SS02_EA04_No_Call_Record_For_PVT MCM_SS02_EA04_Cannot_Allocate_TDM_Group MCM_SS02_EA04_No_SES MCM_SS02_EA04_Standalone State SS03 Errors - WAIT MCM_SS03_EN06_Bad_Status MCM_SS03_EN07_Unexpected_Status_In_Registration MCM_SS03_EN08_NCS_Distress MCM_SS03_EN09_NCS_Forced_Clear MCM_SS03_ES04_Distress MCM_SS03_ES08_SES_Timeout State SS04 Errors - WAIT for congestion MCM_SS04_EN06_Bad_Status MCM_SS04_EN07_Unexpected_Status_In_Registration MCM_SS04_EN08_NCS_Distress MCM_SS04_EN09_NCS_Forced_Clear MCM_SS04_ES04_Distress MCM_SS04_ES06_Forced_Clear MCM_SS04_ES08_SES_Timeout MCM_SS04_ESIG_Bad_SES_Reply

1025016 1025017 1025018 1025019 1025041 1025042 1025043 1025044 1025045

1031061 1031071 1031081 1031091 1032041 1032081

1041061 1041071 1041081 1041091 1042041 1042061 1042081 1042991

SS06 Errors - MES in OR and an individual poll has been sent to the NCS MCM_SS06_EN06_Not_In_OR MCM_SS06_EN07_Unexpected_Status_In_Registration MCM_SS06_EN08_NCS_Distress MCM_SS06_ES04_Distress MCM_SS06_ET03_NCS_Timeout State SS61 Errors - Wait (TEST) MCM_SS61_EN08_NCS_Distress MCM_SS61_EN06_Ship_Link_Lost MCM_SS61_EN07_Unexpected_Status_In_Registration MCM_SS61_ES04_Distress MCM_SS61_ES09_Ship_Shore MCM_SS61_ES09_Sub1_Login_Failed_PVT MCM_SS61_ET02_Timeout State SS62 Errors - Wait for Distress Test (TEST) MCM_SS62_EN07_Unexpected_Status_In_Registration MCM_SS62_EN08_NCS_Distress MCM_SS62_ES04_Distress MCM_SS62_ET02_Timeout State SS71 Errors - Wait for NCS (Announce)
11-71

1061061 1061071 1061081 1062041 1063031

1611081 1611061 1611071 1612041 1612091 1612092 1613021

1621071 1621081 1622041 1623021

Event Messages

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

MCM_SS71_EN06_Not_In_OR MCM_SS71_EN06_No_TDM MCM_SS71_EN07_Unexpected_Status_In_Registration MCM_SS71_EN08_NCS_Distress MCM_SS71_EN09_NCS_Forced_Clear MCM_SS71_ES04_Distress MCM_SS71_ES06_Forced_Clear MCM_SS71_ET03_NCS_Timeout State SS72 Errors - WAIT for SES reply (Announce) MCM_SS72_EN06_Bad_Status MCM_SS72_EN07_Unexpected_Status_In_Registration MCM_SS72_EN08_NCS_Distress MCM_SS72_ES04_Distress MCM_SS72_ES06_Forced_Clear MCM_SS72_ESIG_Bad_SES_Reply MCM_SS72_ET02_SES_Timeout State SS73 Errors - WAIT for NCS Cancel (Announce) MCM_SS73_EN06_Bad_Status MCM_SS73_EN07_Unexpected_Status_In_Registration MCM_SS73_EN08_NCS_Distress MCM_SS73_ES04_Distress MCM_SS73_ES06_Forced_Clear MCM_SS73_ET03_Cancel_Announce_Failure_After_Retries State SS75 Errors - WAIT for NCS (Distress) MCM_SS75_ET03_NCS_Timeout State SS90 Errors - WAIT for CUC FEP (Mobile to Shore) MCM_SS90_EN07_Unexpected_Status_In_Registration MCM_SS90_EN08_NCS_Distress MCM_SS90_EN09_NCS_Forced_Clear MCM_SS90_ES04_Distress MCM_SS90_ES08_Transfer_Status_Request MCM_SS90_ET01_No_Response_From_CUC MCM_SS90_ET02_No_Abort_Call_Report State SS91 Errors - WAIT for CUC (Shore to Ship) MCM_SS91_EN06_SES_Idle MCM_SS91_EN07_Unexpected_Status_In_Registration MCM_SS91_EN08_NCS_Distress MCM_SS91_EN09_NCS_Forced_Clear MCM_SS91_ES04_Distress MCM_SS91_ES08_Transfer_Status_Request MCM_SS91_ET01_No_Response_From_CUC MCM_SS91_ET02_No_Abort_Call_Report State SS92 Errors - WAIT for CUC (TEST) MCM_SS92_EN06_Unexpected_SES_Status
11-72

1711061 1711062 1711071 1711081 1711091 1712041 1712061 1713031

1721061 1721071 1721081 1722041 1722061 1722991 1723021

1731061 1731071 1731081 1732041 1732061 1733031

1753031

1901071 1901081 1901091 1902041 1902042 1903011 1903021

1911061 1911071 1911081 1911091 1912041 1912042 1913011 1913021

1921061

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

Event Messages

MCM_SS92_EN07_Unexpected_Status_In_Registration MCM_SS92_EN08_NCS_Distress MCM_SS92_ES04_Distress MCM_SS92_ES08_Transfer_Status_Request MCM_SS92_ET01_No_Response_From_CUC MCM_SS92_ET02_No_Abort_Call_Report MCM_SS92_EC03_Bad_CUC_Test_Res General Errors MCM_TEST_SUB2_Announcement MCM_TEST_SUB2_Login_Failed_Announce MCM_TEST_SUB2_Not_In_OR MCM_TEST_SUB2_Bad_SES_Reply MCM_TEST_SUB2_No_Pending_Event MCM_TEST_SUB3_Shore_Ship MCM_TEST_SUB6_Login_Failed_PVT MCM_Announce_No_Resource MCM_Bad_State_Event MCM_Ship_Link_Lost MCM_No_Resource MCM_Aborted_By_Operator MCM_Internal_Error MCM_Invalid_Ship_Request MCM_Invalid_Msg_Size MCM_Invalid_Address_Format MCM_Invalid_Address_Extension MCM_No_Call_Record_For_Distress MCM_ADV_Invalid_F69_Syntax MCM_ADV_Invalid_U80_Syntax MCM_ADV_Invalid_Mobile_Number_Syntax MCM_ADV_Unknown_Mobile_Number MCM_ADV_Invalid_Ocean_Region_Syntax MCM_ADV_Unknown_Ocean_Region MCM_ADV_No_Route_Available MCM_ADV_Invalid_PSTN_Country_Code MCM_ADV_Invalid_PSTN_Ext_Syntax MCM_ADV_Unknown_PSTN_Ext MCM_ADV_Invalid_PSTN_Syntax MCM_ADV_Invalid_SAC_Syntax MCM_ADV_Unknown_SAC MCM_ADV_DNID_File_Overflowed MCM_ADV_Unsupported_Feature MCM_ADV_Telex_Not_Allowed MCM_ADV_X400_Not_Allowed MCM_ADV_Invalid_SAC_Address MCM_ADV_Invalid_NMDD_Address MCM_ADV_Invalid_CNID_Syntax MCM_ADV_Unknown_CNID MCM_ADV_Invalid_NTN_Syntax MCM_ADV_Invalid_DNIC_Syntax MCM_ADV_Invalid_Presentation_Code
11-73

1921071 1921081 1922041 1922042 1923011 1923021 1924031

2000100 2000101 2000200 2000300 2000400 2000500 2000501 2000600 2000700 2000800 2000900 2001000 2001200 2001300 2001400 2001500 2001600 2001700 2010000 2010100 2010200 2010300 2010400 2010500 2010600 2010700 2010800 2010900 2011000 2011100 2011200 2011300 2011400 2011300 2011400 2011500 2011600 2011700 2011800 2011900 2012000 2012100

Event Messages

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

MCM_ADV_Ocean_Region_Not_Supported MCM_ADV_Bad_Selection_Criteria MCM_ADV_Invalid_Route_Number MCM_ADV_No_CNID_Route_Available MCM_ADV_Mobile_Not_Commissioned MCM_ADV_Mobile_Barred MCM_ADV_Mobile_Barred_and_Logged_In MCM_ADV_Mobile_Not_Logged_In MCM_ADV_Unsupported_Country_Code MCM_ADV_Not_Initialised MCM_ADV_Not_Supported MCM_ADV_Internal_Error MCM_ADV_Unknown_Error MCM_MDIR_Message_Store_Full MCM_Message_Too_Long MCM_Zero_Length_Message_Request MCM_Illegal_Extension_Length MCM_Illegal_Address_Location MCM_Unknown_Service_Requested MCM_Service_Not_Supported MCM_Assignment_Not_Processed MCM_Add_Info_Not_Zero MCM_Unknown_Presentation_Code MCM_Invalid_Presentation_Code MCM_Packet_Validation_Problem_1 MCM_Packet_Validation_Problem_2 MCM_Packet_Validation_Problem_3 MCM_Packet_Validation_Problem_4 MCM_Packet_Validation_Problem_5 MCM_Packet_Validation_Problem_6 MCM_Packet_Validation_Problem_7 MCM_Cannot_Allocate_Msg_Ref_Num MCM_Cant_Store_Msg_To_MDIR MCM_Cant_Send_Msg_To_MDIR MCM_No_PSTN_Addresses_In_Message MCM_Add_Info_Len_Invalid_For_PSTN_Addresses MCM_No_PSDN_Addresses_In_Message MCM_Add_Info_Len_Invalid_For_PSDN_Addresses MCM_Too_Many_Telex_Addresses MCM_Telex_Address_Too_Long MCM_No_Telex_Addresses_In_Message MCM_Telex_Message_Ends_Before_Addresses MCM_Zero_Length_Telex_Message MCM_Zero_Length_Message MCM_Cant_Convert_IA5_To_IA5_Odd_Parity MCM_Cant_Convert_IA5_To_IA5_No_Parity MCM_Cant_Convert_ITA2_To_IA5_Odd_Parity MCM_Cant_Convert_ITA2_To_IA5_No_Parity MCM_Cant_Convert_IA5_To_ITA2 MCM_No_Storage_For_Message MCM_Cannot_Allocate_Call_Record
11-74

2012200 2012300 2012400 2012500 2012600 2012700 2012701 2012800 2012900 2013000 2013100 2013200 2013300 2020000 2020100 2020200 2020300 2020400 2020500 2020600 2020700 2020800 2020900 2021000 2021100 2021200 2021300 2021400 2021500 2021600 2021700 2021800 2021900 2022000 2022100 2022200 2022300 2022400 2022500 2022600 2022700 2022800 2022900 2023000 2023100 2023200 2023300 2023400 2023500 2023600 2023700

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

Event Messages

MCM_Station_Record_Not_Found MCM_Station_Not_In_Service_Des_State MCM_Station_Not_In_Service_Cur_State MCM_Station_Not_CES MCM_Mobile_Record_Not_Found MCM_Mobile_Not_Commissioned MCM_Mobile_Not_Logged_In MCM_Mobile_Barred_NCS MCM_Mobile_Barred_CES MCM_Terrestrial_Links_Not_Open MCM_ITA2_Presentation_From_Mobile_That_Should_Not_Handle_It MCM_Data_Presentation_From_Mobile_That_Should_Not_Handle_It MCM_No_Call_Record_In_Shore_Ship_SDL_Subroutine MCM_No_Msg_Text_In_AST_In_Shore_Ship_SDL_Subroutine MCM_No_Call_Record_On_Getting_Outbound_Text MCM_Cannot_Read_Outgoing_Message_From_MDIR MCM_Cannot_Get_Msg_Text_For_Shore_Ship_Message MCM_Shore_Ship_Message_Too_Long MCM_Zero_Length_Message_From_MDIR MCM_Error_Constructing_Distress_Alert MCM_Distress_Alert_From_Unsupported_OR MCM_Exception_In_Distress_Alert LES Force clear codes MCM_FC_CES_Timeout MCM_FC_SES_Protocol_Error_Detected MCM_FC_CES_Fatal_Hardware_Error_Detected MCM_FC_Operator_Forced_Clear MCM_FC_SES_Forced_Clear MCM_FC_CES_Protocol_Error_Detected MCM_FC_SES_Hardware_Error_Detected MCM_FC_SES_Timeout MCM_FC_Unrecognised_Presentation_Code MCM_FC_Invalid_Address MCM_FC_Destination_SES_Not_Commissioned MCM_FC_Destination_SES_Not_Logged_In MCM_FC_Destination_SES_Barred MCM_NCS_Failed_To_Respond_To_TDM_Request MCM_NCS_Failed_To_Respond_To_TDM_Release MCM_Deleted_Operational_TDM_Group_Record MCM_Call_Failed_Due_To_FEP_Switchover MCM_Call_Failed_Due_To_BAP_Switchover CUC FEP Errors CUC_Mobile_Waiting_For_Clear CUC_Timeout CUC_Force_Clear_From_Mobile CUC_Local_Equipment_Failure CUC_Input_Data_Timeout CUC_Unable_To_Send_Ack
11-75

2023800 2023900 2024000 2024100 2024200 2024300 2024400 2024500 2024600 2024700 2024800 2024900 2025000 2025100 2025200 2025300 2025400 2025500 2025600 2026000 2026100 2026200

2030100 2030200 2030300 2030400 2030500 2030600 2030700 2030800 2030900 2031000 2031100 2031200 2031300 2040100 2040200 2040300 2041000 2041100

3000001 3000002 3000003 3000004 3000005 3000006

Event Messages

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

CUC_Unable_To_Send_Assign CUC_Mobile_Response_Timeout CUC_Mobile_Out_Of_Seq CUC_Protocol_Failure CUC_Remote_Equipment_Failure Pre-assigned Data Reporting error codes MCM_PADR_Resp_Timeout MCM_PADR_Reservation_Exists_For_Program This error code indicates a reservation that is already present This indicates an error in the Poll sent by the user MCM_PADR_No_Reserved_Sig_Chan_Defined This error code indicates that no signalling channel exists. MCM_PADR_No_Reservations_Available This error code says that the PADR could not find any reservations in the cache MCM_PADR_Internal_Exception This error represents an Internal Exception in PADR processing MCM_PADR_Res_Not_Found_For_Repetition This error indicates that when a PADR poll was repeated, the original reservation was not found

3000007 3000008 3000009 3000010 3000011

4000001 4000002

4000003 4000004

4000005 4000006

MCM_PADR_Res_Doesnt_Exist_For_Stop_Delete_CNID_Polls 4000007 This indicates that the PADR reservation was not found when the stop or Delete CNID Polls were processed. MCM_PADR_Unexpected_Status_Code This 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 frequent transitions from in-service to out-of-service and back again occur, the number of events presented to 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 event is to be reported to the operator or not. All the occurrences of these events are stored and examined at a check interval - set to 60 seconds. A non-operational event without the appropriate operational event within this interval will generate
11-76

4000008

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

Event Messages

an event to the operator. Similarly, an operational event without a non-operational event during this time will generate an event to the operator. The interval over which this check is made is set to 5 minutes (default). The filter also has limits on the number of transitions which may occur in a given interval before an event is raised to the operator. For the SIG channel events, the event to the operator is raised when there are 12 occurrences within 2 minutes. For the other two events, 5 occurrences in 5 minutes are required.
[opg11.mss]

11-77

Operating System Access

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

11-78

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

Operating System Access

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 application software and to change a limited number of parameters in the system. It is also possible to interrogate the operational state of the application software. Further functions can be performed but 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 directly or the Create VT200 Window option on the SOC. The latter is only possible once the SOC workstation is running. When the Create VT200 Window option is selected, the initial user is requested to logon with the message : Welcome to <name of the SOC> VMS v.... Username: The following information should be entered at the prompts shown in bold and Return pressed at the 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 are allocated when the system is installed and the default appears as part of the prompt. Enter the desired node name or press Return if the default is required. 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 Return to go back to the Username prompt. 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 first four 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
12-1

Operating System Access

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

described in the DEC VMS User literature but such commands are not used in the operation of the ACSE, except where specifically identified in this manual. The DCL commands used in this section uses the following protocol: Dnnn Mnnn xxx Indicates a disk drive e.g. $1$DIA1 Indicates a magnetic media drive e.g. MUA0: Indicates the operator assigned label for a backup

Of particular interest is the BAP Operations Facility, an executable file which is included in the ACSE software. 12.3 BAP Operations Facility The BAP Operations Facility allows the operator to start and stop the BAP software and to perform similar 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 with the BAPOP command, e.g. CES nnnn> BAPOP START BAP ARBITER which is equivalent to the sequence: CES nnnn> BAPOP BAPOP> START BAP ARBITER BAPOP> EXIT CES 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 F10 to close the window. The following commands are available: HELP Information in plain text is available on all the commands listed below, i.e. this help is for the BAPOP facility.

DEINSTALL BAP Deinstalls BAP images from memory, i.e. removes the working copy of the software from the dynamic memory in which it is normally held. This com12-2

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

Operating System Access

mand is used when a new BAP software release is to be loaded onto the system. This command should only be used if the BAP images have been installed in memory via INSTALL BAP or START BAP. The system must not be running 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. If the command contains a space, the command line must be enclosed within double quotes. For example, DO "SHOW TIME" will execute the DCL command SHOW TIME. This command takes the user out of BAPOP and returns to DCL, restoring the CES nnnn> prompt. Installs BAP images from disk into dynamic memory as a prelude to operational use. The BAP software must already have been installed onto the disk. This command is not normally used during system operation; START BAP will install images automatically. Format : BAPOP> INSTALL BAP QUIT SHOW BAP This command returns the user to DCL. It is an alternative for EXIT. Displays operational status for the BAP system, including whether the system is STARTED/STARTING or STOPPED, and the name of the current Online database. If the BAP is STARTED, the mode and state of the processor will be displayed. The user will also be prompted as to whether the current active BAP processes should be listed; if this option is selected, all processes running in the BAP user definable code group will be listed and their current processing states and CPU and memory statistics shown. Note that the disk number (e.g. $1$DIA1) shown in the response refers to the disk 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 and state of the processor will be displayed, followed by the list of processes that will 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 and state of the processor will be displayed, followed by the list of processes that will 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. This command enables the operator to override the operation of the arbiter and operate in the selected mode. Valid modes are MASTER, STANDBY, IDLE, or ARBITER. Normally select ARBITER. The processor assumes that the arbiter is present and the BAP will abide by the mode chosen by the arbiter. This is the only way to implement fully automatic redundant operation of the two BAPs. Only select MASTER and STANDBY when specifically instructed by HNS.
12-3

EXIT INSTALL BAP

Operating System Access

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

The system should not be left in either of these modes for longer than necessary, since it would be operating non-redundantly; restart with ARBITER mode as soon as instructed. The equivalent command from DCL is : CES nnnn> BAPOP START BAP ARBITER STOP BAP Stops the BAP applications software. Note that this will terminate all support for Standard-C operations by this BAP. Format : BAPOP> STOP BAP Only use this command when instructed to do so as part of a software upgrade, or if the BAP has to be stopped and restarted to cure a problem - 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 software becomes locked in a loop from which it cannot recover. If that happens, the first solution must be to switch over to the standby machine. This is performed on the SOC by selecting the BAP Management, 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 undertaken after 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 application software is on disk. A FEP will initialise and communicate with one of the BAPs to request download of its software. Communication between the BAPs and the FEPs is over Ethernet. When a node is connected, it automatically tries to communicate with other nodes which it knows about. Thus if a node is temporarily out of service, communication with it is quickly re-established when it is restored. If communication cannot be automatically re-established, the BAP itself must be restarted using BAPOP STOP and BAPOP START. The Channel unit hardware will go through its self-test automatically and then will request configuration from the processor. Initialization takes about 30 seconds to complete.

12-4

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

Operating System Access

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 be created. 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 activities undertaken by DEC staff to initialise the operating system. It should not be necessary ever to repeat these actions thereafter; the only occasion would be if the equipment was being repaired by DEC, in which case their staff would undertake the work. The relevant instructions are not therefore 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 it has been repaired; the online equipment will not be affected. An important element of start-up is the synchronization of the databases. This is an automatic process, because of the disk shadowing mechanism used, but will take time - between 30 and 45 minutes. Resynchronization is only required when power to the shadowed disks, which are in a separate cabinet, is removed and reconnected. The operator is provided with means of starting and stopping the system by accessing the operating 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. The following 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 the Standby mode. If there is no operational BAP when this process takes place, both BAPs should be started at the same 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 is followed. 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
12-5

Operating System Access

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

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 startup sequence. Use the BAPOP SHOW STATE command to obtain the displays shown in figures 10-1 and 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 at the 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 a sun outage (where communications with a satellite is temporarily lost due to its being in line with the sun) or if work is planned on the RF equipment. Except in an emergency, this can be planned in 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 terrestrial interface 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 transmission until the satellite side is restored. Before the interruption, the TDM groups and then the ISL should be taken out of service using the TDM Group Management and ISL Management forms. If the interruption is more serious and involves stopping the processors, the mobile users should be advised and the congestion bit set on the TDM Group Management form. The terrestrial incoming circuits should also be busied. This will stop new traffic coming to the LES. A suitable period should be allowed for the delivery of messages held within the LES and then the satellite side 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 now run. Access can be gained to the SOC in a similar way to the BAP. Use the Create VT200 window 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-6

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

Operating System Access

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 indicates that 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 SOC form windows to be created. Note 2: it is possible to delete specific windows from this account, using the appropriate VMS commands, needed for example in the exceptional circumstances, where a window is no longer accessible. 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 whilst the BAPs were in an operational state, a number of files would likely be opened and therefore not backed up. System Disks need only be backed up after installing a new software release, before operating with that release. Warning: use of this procedure to backup the BAPs on a live LES is not recommended, since it can prevent successful reformation of the VAX cluster. Both BAPs must be in the shutdown state before either is booted under standalone backup, and neither must rebooted under VMS as a VAX cluster member until both are in the shutdown state once 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
12-7

Operating System Access

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

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, it should 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, it should 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 be backed up at the same time, but neither must be rebooted under VMS until both are once more at the 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-8

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

Operating System Access

Usually the cartridge tape device name is MUA0 on BAPs (MKA500 or MKB500 on SOCs). It is recommended 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 been copied the tape will be rewound and the verification pass will start. This will take a similar time to the copy pass. If the disk image is too big to fit on one tape then when the verification pass for the first tape is complete BACKUP will prompt for a second tape. Enter YES in response to the prompt indicating that the second tape is loaded into the drive. A copy pass followed by a verification pass will then occur for the second tape. Note: Any tapes or cartridges used for backup must have been initialized on the same, or a compatible drive before the backup. The tape label need not be that expected for the backup as the operator 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 not required 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 command 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 enter the 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 12-9

Operating System Access

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

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 is recommended 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 been copied the tape will be rewound and the verification pass will start. This will take a similar time to the copy pass. If the disk image is too big to fit on one tape then when the verification pass for the first tape is complete BACKUP will prompt for a second tape. Enter YES in response to the prompt indicating that the second tape is loaded into the drive. A copy pass followed by a verification pass will then occur 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 the VMS console, informing the operator of a change in disk status or of potential or actual problems with the disk(s), the operator can at any time, whilst VMS is running, exercise the following command in order to ascertain the current status of the disks: CES nnnn> SHOW DEVICE D The resultant output will be of the form: Device Status Mounted Mounted Mounted ShadowSetMember ShadowSetMember Mounted ShadowSetMember ShadowSetMember Mounted Error Count 0 0 0 0 0 0 0 0 0 Volume Label USER01 USER02 RIGEL_SYS (member of (member of QUORUM (member of (member of ORION_SYS Free Trans Mnt Blocks Count Cnt 166215 96 2 157233 69 2 10911 239 2 DSA0:) DSA1:) 45816 1 2 DSA0:) DSA1:) 15114 1 2

Device Name DSA0: DSA0: $1$DIA0: $1$DIA1: $1$DIA3: $1$DIA3: $1$DIA4: $1$DIA5: $1$DIA6:

(RIGEL0) (RIGEL1) (RIGEL2) (RIGEL3) (ORION4) (ORION5) (ORION6)

The devices present will depend on the particular customer configuration. Note in particular the presence of the system disks, whose Volume Labels will normally contain the suffix SYS, and the shadowset disks. The shadowset disk devices have the volume label member of DSnn, where DSnn is the shadowset name, which itself appears as a virtual device. The Device Status should be either Mounted or ShadowSetMember, any other state may indicate that the disk is not accessible. The Mnt Cnt should be equal to the number of VAX processors clustered in the system. If a single disk is showing a lower mount count than the others, then it will be unavailable on another node. If the Mnt Cnt is lower than expected for all disks, this may indicate 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 will normally indicate that the system disk is functioning normally. The shadowset disks should normally have at least 50000 Free Blocks, and the related SOC System Usage display bar should fall short of the red zone. Anything other than this, take the remedial actions contained in this
12-10

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

Operating System Access

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 investigate the cause. If the Master BAP system disk suffers a catastrophic failure and the processor halts, the Standby BAP will assume the Master role when the normal handshaking between the Master BAP and the arbiter 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 or remove unwanted files. Log files should only be removed using the procedures described in Chapter 14. 12.12.4 System Disk Space Exhaustion There are also safety mechanisms in operation, should the amount of free system disk space become critically low. Both the LES software and VMS monitor the system disks, although normally 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 processes will be suspended and will not be able to halt the processor, although operator access to VMS via the VAX operator console should still be possible. In these circumstances, the Standby BAP will assume the Master role when the normal handshaking between the Master BAP and the arbiter fails. If the new Master BAP appears to hang during the switchover, halt the old Master BAP processor, 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 system disk space is freed on a suspended BAP, VMS will automatically unsuspend the LES software processes and normal service will be resumed. Once system disk space has been freed on a halted 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 BAPs system disk. This separate from, and not under the control of, the LES application. This file logs operating system activity and can contain useful information in the event of system malfunction. Without operator intervention, this data will be logged to a single file which may grow to a significant size over a period of a few months (dependant on system activity, 700 blocks per day has been observed). Normally, this data may be discarded as unwanted. However a conflict may arise in the event that this file needs to be deleted when the data contained is relevant to a problem under investigation. It is recommended that this procedure described here, be run once each month and at a time when there has been no errors for two days or more - to ensure that no potentially useful data is lost. The operator should exercise restraint if log files of less than one month old are to be deleted as these files contain records which may be of use when investigating system problems.
12-11

Operating System Access

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

Such recent files should not be deleted UNLESS every other course of action has been exhausted in trying to free more disk space and a BAP failure imminent (i.e. purge all files delete unwanted files). 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 significance unless 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 available for 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 deletion of earlier versions of this log file as described in the monthly procedure above, proceed as follows. Repeat the above procedure immediately. This will close the current log file and delete the previous version. If disk space is still inadequate, and deleting the now closed log file would release significant space, then: $ DELETE/LOG SYS$MANAGER:OPERATOR.LOG;-1 At this point there should only exist one log file, the size now being a few 10s of blocks. No further space gains can now be attained in this area.

12-12

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

Operating System Access

12.13 Disaster Recovery This section summarizes possible failures of the system that require file backups to have been previously performed in order to enable disaster recovery. Note: many of these issues are addressed elsewhere in this manual. In all cases it is assumed that disks or processors have been repaired or replaced before the operations listed are undertaken. Point of Failure 1. Single Points of Failure: Total loss of any System Disks Restore image Backup of the System Disk Archived Tapes of the Software Release, Sybase Installation and VMS Installation plus other layered products Phone HNS support for reinstallation of replacement disk Site Backup HNS Backup

Loss of one Shadowset Disk

Initialise and mount replacement disk (Shadowset software will cause an automatic merge). Restore Logfile Backup

Loss of the Quorum Disk

Reinstall the Offline Database Sybase device as defined by System Disk OFDB files Archived Tapes of the Software Release, Sybase Installation and VMS Installation, plus other layered products Archived Tapes of SOC Software Release and SOC VMS Installation

Loss of an entire BAP including System Disk e.g. through fire

Restore Image Backup of the System Disk, Database dump backup

Loss of an entire SOC or SOC Disk e.g. through fire 2. Dual Points of Failure Loss of both Shadowset disks 3. Total System Loss Loss of all VAXes and disks due to fire, water or explosion damage

Restore Image Backup of the System Disk, and SOC Software if on separate disk

Restore Database Dump archived to tape

Archived Online Database Dump

Restore System Disk Image Backup, Tape Backup of Database Dump, also logfiles Kept in separate building/fire safe

Archived Software Release, VMS / Sybase Installation. Archived Online Database Dump

Backup Frequency
12-13

Operating System Access

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

Note: the following is a suggested procedure. Customers should define their own procedures to meet their particular circumstances. Database Dump to tape System Disk Image Backup Once a month (retain new registered users) For each new software release, or following the third EBF since a backup was last 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 to the systems. The backed up data must not be lost in a catastrophe which also destroys the VAX systems and their drives.
[opg12.mss]

12-14

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

Online Statistics

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 online database. Formatted displays or hard-copy printouts of this data is accessible to the user in the form of online reports and statistics, using the SOC Viewer. Periodically, the data is transferred to the offline part of the system, where separate Offline Reports 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 configurable but has a default of 1 hour, they are transferred to the current open log file. The operator is able to obtain an output of the statistics obtained from any of the log files in the online area including the open log file. There are two associated operator functions. Statistics Reports Management controls whether statistic data is logged for individual components from the raw data contained in the log files and at the interval at which logging takes place. Statistics Reports Print Management controls whether the report for a particular component is output to a printer. The list of components whose statistic data logging is controlled from Statistics Reports Management is a superset of that whose printout can be enabled/disabled from Statistics Reports Print Management. Statistics for certain components, namely EM and LFM, are required for HNS internal diagnostic use, and there is no requirement to print this data out. To control the preparation of data, use Statistics Reports Management (SOC Viewer - Online Processing). 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 components statistics, (i.e. switch them on for all components) log named components statistics The interval over which data is collected can be altered with the above controls. The options for any field, except time, can be seen by selecting ?. Use Statistics Reports Print Management (SOC Viewer - Online Processing) to control printouts. 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
13-1

Online Statistics

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

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 Single Components Statistics Logging Interval or Set All Components Statistics Logging Intervals options 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 24 hours. The original default value is 1 hour. It is advised not to generate outputs too often - once an hour 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 Display Statistics 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 success Hit <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 unchanged. The report is then sent to the Report Printer after the interval period has elapsed, providing 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 online logfile reports described in Section 13.2.

13-2

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

Online Statistics

13.2 Online Logfile Reports The following reports are available via Generate Log File Reports (SOC Viewer - Online Processing - 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 - Run Reports - Run Online Log File Reports) printed - use Print Log File Reports (SOC Viewer - Online Processing - Run Reports - 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 number, 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 (SOC Viewer - Online Processing - Run Reports - Run Online Log File Reports - Generate Log File Reports). This report provides comprehensive details of the distress messages processed by the LES.

13-3

Online Statistics

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

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 is of use in studying the cause of a fault and should be added wherever relevant, to fault reports returned 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 before this 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 N hours preceding the Latest Event time, or N hours before the current time if the Latest Event Time is not filled in. If this field is not filled in then all events preceding the Latest Event Time will be considered for the report (subject to the remaining selection criteria). 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 not filled in then all alarm levels will be selected. Outstanding Events - If Y is entered, then only events which have not been acknowledged (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 the BAP reporting the event. If this is not filled in then events from either BAP will be considered for the report. 13.2.4 Operator message This report provides details (including text) of messages from one or mobile sent to the operator position as a result of addressing the message to the operator using the designated special access code. 13.3 Online Database Reports The following reports are available via SOC Viewer - Online Processing - Run Reports - Run Online Database Reports: Trunk Telex Route Message Status DNID ENID Country Code PVT Results X25 Route
13-4

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

Online Statistics

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 associated LES functions - use the index to locate the required information.
opg13.mss

13-5

Offline Processing

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

13-6

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

Offline Processing

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 be loaded into the offline database for the purpose of billing. Mention of billing remains in this chapter for 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 or OFDB billing), then billing MUST be carried out on these logfiles BEFORE they are copied to the offline area. Reference to other billing support activities within this chapter are still valid, such as tape/file formats 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 systems 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 the specified time span. Call records. These reports hold details of the calls that were made over the system over the specified time span. Events. These list events which were recorded, including all alarms which occurred 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 the administration 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; the software 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 not the case.
14-1

Offline Processing

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

log files are generated in the online system. A log file is closed after 1 hour or 2048 entries, whichever occurs first. A new log file is then automatically started. the offline system contains log files, copied from the online system, and the offline database Files in the offline system are not shadowed but are held on the Quorum disk. These files hold the following 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 in cases 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 in chapter 4. Normally this will be executed on the STANDBY BAP. In the case of a switchover or where only one BAP is available the processing will be possible at much reduced priority on the MASTER BAP. A warning to the effect that traffic handling will be impaired will be issued if an attempt 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 is used for tapes for internal use. Storage costs will be lower and the tapes themselves are more reliable. When tapes are used for billing, the choice of tapes for the billing centre is at the discretion of each 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 tape drive failure occurs in the machine being used, a BAP switchover should be arranged at a convenient time so that the other tape drive can be used. When such a switchover takes place, the offline database is automatically accessed by the new standby processor, so it is not necessary to repeat any of the steps described below. Archive tapes are produced for both the logfiles and for the offline database. The logfiles are the source and therefore the archive copies should be retained for as long as it might be necessary to
14-2

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

Offline Processing

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 is provided because a tape spool can hold a much larger quantity of data than is normally output during 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 to use this facility. 14.4 Disks The offline database can be archived to disk rather than tape. The disk need not be local to the LES in case of catastrophe. The identity of the default archive disk is configured by HNS. The operator can specify another disk identity at the time of archiving, but must have write access to that 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 required yyyy represents the year, e.g. 1992 mm represents the month, e.g. 06 for June dd represents the day, e.g. 02 for the second day of the month hhmmss represents time in hours, minutes and seconds vn_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. the system 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 being generated in the system. The limits can be considered as : daily - which puts an additional load on the staff but ensures that database usage is minimized and that back-ups are available for as much data as possible at least every eight days - which makes the operator workload manageable. This could be split up as follows : 1. 1st to 8th of month 2. 9th to 16th of month 3. 17th to 24th of month

14-3

Offline Processing

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

4. 25th to end of month The exact timetable can be adjusted as necessary to avoid particular days, such as weekends. Five runs may be needed in some months. Initially, at least, following the eight-day routine will be adequate. The period of eight days was chosen 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 of logfiles 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 area of 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 utilities menu 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, a check is made to ensure there is adequate disk space on the target disk. If this is encountered, the operator should ensure that the directory OFDB$LOGDIR is empty before trying again. A reconciliation error has occurred - Following the copy to the offline area, a check is made that every log file has a corresponding index file. If there is an inconsistency, then the first action should be to ensure that directory OFDB$LOGDIR is empty, and then try the operation again. If the error persists then contact HNS. 2. Archive the logfiles that have just been copied into the offline area - this gives a backup of the raw data generated by the system. For instance, this is the source of the event log if at any time it is necessary to look at past events. Use Archive Logfiles from Offline Area (SOC Viewer - Offline Processing - Options Housekeeping - Log File Utilities). Note that a separate tape is required each time an archive is made; if a tape which already contains information is used, the new information 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 set before 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 that all the log files in the offline area are processed. Note 1: if [step 8] has been followed on the previous offline processing session, 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 incor14-4

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

Offline Processing

MASTER BAP

ARCHIVED LOGFILES

Micro VAX

2
ARCHIVED DATABASE

(ONLINE) LOG FILES

(OFFLINE) LOG FILES

3 4 5 8
OFFLINE DATABASE BILLING DATA

(5)

BILLING TAPES

7
DELETED FILES

REPORTS BILLING TAPE LISTING

Brackets indicates choice.


[log_file_billdsk.eps]

[log_file_billdisk.eps]

Figure 14-1. Offline Database Life Cycle

14-5

Offline Processing

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

porated into the offline database, the user would be warned that these files have been incorporated and they will not be incorporated again. Note 2: the database load over a protracted period of time, dependant upon the 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 will be displayed on the screen. Similarly, information messages are displayed which show the files currently being processed. This gives a good indication of how far through the load the loader has got. The operator can use cursor keys to scroll through the messages. At the end of the load examine the following file 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 a CSPR, see Appendix F for the procedure involved, ensuring that the contents of this file are made available to HNS. It may then be necessary to load the offline 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 from the previous billing period are included in that periods processing. For the first ever 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 be deleted before loading takes place. In order to generate the various billing tapes only load calls are required to be set to true. If, however, reports for other than calls are required, load events, load distress and load statistics also need to be set to true. Note that a database load must be performed using a single logfile specifier; it is not possible to load two days worth individually into the database using two separate logfile specifiers and two separate Run Loader commands. When the correct parameters are entered, select Run Loader to read the logfiles into the offline database. If the offline database server is not running a warning message will appear. The operator must use Start Offline Database Server (SOC Viewer - Offline Processing), if this proves to be the case.
14-6

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

Offline Processing

4. The offline database is archived. This provides the backup for the regeneration of billing tapes if these tapes are ever lost or damaged. Use Archive Offline Database (SOC Viewer - Offline Processing - Options - Housekeeping - Database Utilities). The database may be archived to either tape or disk, depending on which menu option is selected. In either case the archive data is copied to disk (temporarily in the case of archiving to tape). The SOCV displays the disk space available and the operator is prompted whether to continue or quit. If archiving to tape is selected then a separate tape is required each time an archive is made; if a tape which already contains information is used, the new information will over-write it. This tape can be used in future as the fastest way to be able to re-produce billing tapes or reports from this time period. If archiving to disk is selected then the operator is prompted for the directory into which the database is to be archived. The default is [OFDB$LISTDIR] on the default disk. The operator can respond with a path to a separate disk (and system) using the syntax: NODE::DISK:[DIRECTORY_PATH]FILENAME Note: The above path is optional. If a separate NODE (i.e. another VAX system) is specified then the archive may only be possible by including details of an account on the 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 is reconciled, the ICR and all associated DCRs together describe calls for which there are no outstanding deliveries. Use Billing Data Generation (SOC Viewer - Offline Processing - Options) and then the appropriate selection. An alternative mechanism exists whereby customer billing information can be placed in a file held on disk. If this facility is required, e.g. where files can be directly transferred to the billing centre, thus negating the need for tapes, then select the 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 file name specified in the command line when the Generate Billing Tape function is selected, as described above. The header record also holds a start time and end time. If no start time was specified in the command line, then the header record start time is the earliest start time that appears in the logfile data in the database. If no end time was specified in the command line, then the header record end time will be the 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 order to ensure that the data has actually been copied to the tape. If the tape has not been copied to successfully then the operator can reproduce the tape. It is possible to obtain a listing of the customer tapes by invoking List Customer Billing Tape from SOC Viewer - Offline Processing - Options - List Generation. A listing of billing data archived to disk can be obtained from the same menu. An
14-7

Offline Processing

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

explanation of the contents of these tapes may be obtained from the Billing Tapes Formats document, Reference [4] and Module 5 of reference [1]. 7. Reports are generated as required: Use Report Generation (SOC Viewer - Offline Processing - Options - Report Generation) and then the appropriate selection. Alternatively select Default Reports from the same menu to produce all the relevant reports (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 been copied 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. Use Delete Copied Logfiles from Online Area (SOC Viewer - Offline Processing Options - Housekeeping - Log File Utilities). Once this option is selected, as long as there are files that qualify for deletion, the operator is prompted whether or not to delete 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 archived status is performed before deletion. Delete offline logfiles: Use Delete Logfiles from Offline Area (SOC Viewer - Offline Processing - Options - Housekeeping - Logfile Utilities). Use of VMS to delete these files 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 ensures the deletion from the offline database of all records which are no longer required, i.e. all reconciled and billed call records, if load with carry over is set to true. If load with carry over is set as false the existing 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 full set of reports it should be noted that the procedure could be very slow, depending upon the speed of the BAP processor, and may also use a large amount of diskspace. The recommended options are: follow the above procedure daily for billing and reports. follow the procedure weekly but use only for billing. (When loading the off-line database, 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 Default Processing SOC Viewer - Offline Processing - Default Processing Menu. The billing data is copied to tape only. However if used then the operator must ensure that all other steps are completed successfully. This operation will also produce a full set of default reports as described in section 14.11.5. HNS recommends that, when supported, automatic processing of offline records is used. Note 4: Log files in the offline database can be archived, listed, deleted and restored from tape using Default Housekeeping SOC Viewer - Offline Processing - Default Processing Menu. This minimizes operator involvement in these operations.
14-8

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

Offline Processing

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 configure which disk(s) that are to be used for offline processing and where the various files generated are to 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 been indicated in the previous section, i.e. Delete a Report (SOC Viewer - Offline Processing - Options - Housekeeping - Report Utilities) Delete a List (SOC Viewer - Offline Processing - Options - Housekeeping - List Utilities) 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 directory defined as OFDB$SCRATCHDIR. Note the disk identity (Characters to the left of the colon ":"). SHOW DEVICE DISK_ID - where DISK_ID is the disk noted above. The number of free blocks on the disk will be displayed. $ PURGE/LOG OFDB$SCRATCHDIR - removes all but the latest version of the files in 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 attempting to combine tapes. 14.8 Abnormal Processing of Records The routine archiving of both the logfiles and the offline database means that recovery from a failure should be straight-forward. In principle, it is necessary to restart from the point of failure and repeat the processing which would normally be done from that point. No attempt should be made to perform abnormal processing until routine processing has completed. 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
14-9

Offline Processing

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

compatible drive) or disk (which can be accessed directly). Either way the following steps must be followed: 1. Ensure that the offline database is archived for the last billed run (if not done already). Use Archive Offline Database to Tape or Archive Offline Database to Disk (SOC Viewer - Offline Processing - Options - Housekeeping - Database Utilities). 2. Restore the database which was archived for the period previous to that where data has been lost. Use Restore Offline Database from Tape or Restore Offline Database 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. Load the archive tape onto the tape reader and then use Restore Logfiles to Offline Area (SOC Viewer - Offline Processing - Options - Housekeeping - Logfile Utilities). 4. Load the log files into the offline database and produce tapes and reports as required. Use Database Load (SOC Viewer - Offline Processing - Options), Billing Data Generation (SOC Viewer - Offline Processing - Options - Billing Data Generation) 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 several tapes 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 it may be used to duplicate a single tape. The utility will only merge tapes of the same type, i.e. it will only merge one billing tape with another. If tapes for two ocean regions are combined, the identity assumed will be that of the first region loaded. Following these steps : 1. Use Combine Tapes (SOC Viewer - Offline Processing - Options - Billing Data Generation). The user is prompted to load the output tape in the drive; this tape is then 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 name of the tape drive, e.g. MUA0. 2. When the tape has been initialized, the operator is asked to remove the output tape and load the first tape to be combined. When the tape is loaded, press Return , and the data will be read. 3. When all the data records have been loaded, the operator is prompted to mount another tape containing further data. To use the utility as a copier, the operator should 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 place the newly initialized output tape in the drive to be used to store the combined data file generated from the previous tape(s). Data will be automatically written to this
14-10

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

Offline Processing

tape. 5. Mark the new output tape with the title and date it was created, so that it can be easily identified in the tape storage rack. The combined tape has a header record, holding the run number and file name specified when combining the tape. The header record also holds a start time and end time. The header record start time is the earliest start time that appears in the files loaded from the previous tape(s). The end 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 data archived 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 been generated from the Offline Database. Except when Default Reports are specified, the operator will be required to enter further detail specifying the range of data to be processed (or else accept the system defaults). All report programs 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 be used 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 selection to generate the report, as shown on figure 4-8. The operator will be invited to set various parameters, including the start and stop times, before running the reports. Only some parameters must be set by the operator. For those parameters which are not set by the operator, the system will 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 report printer, and View a Report to display it on the SOC Viewer screen. This menu is used to delete a report once it is no longer required. Failure to regularly delete unwanted reports will result in gradual exhaustion of the available disk space. The reports available are:
14-11

Offline Processing

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

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 retained wherever 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 MMM YYYY hh mm ss = Day = Month = Year = hours = minutes = seconds (1..31) (JAN,FEB,MAR,APR,MAY,JUN,JUL,AUG,SEP,OCT,NOV,DEC) (1901..current year) (0..23) (0..59) (0..59)

where a date is used without a time then the default time is midnight for the beginning of the date specified. The Start Time must be further in the past than the End Time.

14-12

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

Offline Processing

14.11.1 Statistics The Channel Unit Chassis Statistics : CU_CHASSIS_STATS.RPT (SOC Viewer - Offline Processing - Options - Report Generation - Statistics Reports) provides statistics on the performance of Channel Units. The output shows, against each channel unit, the following in relation to the link between the CUC FEP and the channel unit (i.e. internal to the ACSE) : FEP name Chassis ID Ocean region Slot num Polls Response timeouts RX CRC errors TX CRC errors CU ups CU downs

Number of polls from the CUC to the channel unit Number of times CU fails to respond to poll Number of responses from CU with error, detected by sumcheck Number of CU received polls with error, detected by sumcheck Number of times CU becomes available Number of times CU becomes unavailable

and the following for TDM demods only which indicate the quality of the transmissions from the TDM modulator, over the satellite and back to the TDM demodulator : Framing errors Dem RX CRC err Dem RX car los Number of times the demod fails to detect the frame sequence in the signal Number of time the demod detects a CRC error on the received signal 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 rack for each FEP pair : FEP name Ocean region Polls RX CRC errors Port ups Port downs Missed frame timings Status change messages

Number of polls over the link Number of responses with errors Number of ASM returns to service Number of ASM failures Number of times ASM failed to report start of TDM frame 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 Manual MTM switchovers MTM-A ups MTM-A downs MTM-B ups Selected by the ASM Front switch on MTM Number of times MTM-A returns to service Number of MTM-A failures Number of times MTM-B returns to service
14-13

Offline Processing

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

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 Blower downs Power supply A ups Power supply A downs Power supply B ups Power supply B downs Number of times blower becomes working Number of times blower fails Number of times power supply A becomes working Number of times power supply A fails Number of times power supply B becomes working 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 each TDM group. For the TDM Modulator, the following is shown FEP name Ocean region TDM group ID Frames TX Packets TX Split packets Bytes TX

Number of transmitted frames Number of transmitted packets Number of packets which span a frame boundary Number of bytes transmitted

For the signalling channel, the statistics are in tabular format showing : FEP name Ocean region TDM group ID LUN One-slot packets Multi-slot packets Slots acked Slots nacked Cont slots

Logical channel unit number Number of packets contained in a single slot Number of packets contained in multiple slots Number of packets successfully received Number of packets not unsuccessfully received 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 - Offline Processing - Options - Report Generation - Statistics Reports) gives details of number of calls and the number as a percentage of the whole for each which produce a particular call completion code. 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 one call, consisting of the following data: CCC Call Status Text Call completion code Textual description
14-14

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

Offline Processing

Number of Calls Number of Calls as Percent Number of Distresses Number 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 mobiles whose 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 Num Num of Calls Repeated Packets Num of Failures Num 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 successful and unsuccessful incoming and outgoing calls and times out of service, engaged and free, as a percentage, 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 Calls Successful O/G Calls Unsuccessful I/C Calls Unsuccessful O/G Calls Time OOS Time Engaged Time Free 14.11.2 Events The Event Log Report : EVENT_LOG.RPT (SOC Viewer - Offline Processing - Options - Report Generation) gives a list of all the events for the duration specified. Any event that is repeated many times may highlight the need for investigation into its cause. For each event, the following is given : Date and time Class Level Description Component Event number 14.11.3 Distress Distress Message Summary Report : DISTRESS_SUMMARY.RPT (SOC Viewer - Offline Processing - Options - Report Generation) displays a summary list of distress messages. For each message the a selection from the following is given, depending on applicability. Separate entries are provided for message receipt and for message delivery: Message ID MRN e.g. MES Distress Receipt, EGC Receipt, Distress Delivery Message Reference Number
14-15

Of the event BAP, FEP, etc, as listed in section 11.1 Urgent, semi-urgent, as listed in 11.1 Plain text Reporting the event, as listed in 11.1 Corresponds to number given in section 11.2

Offline Processing

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

Message Kind ICR DCR Fwd MES ID Rtn MES ID EGC Details Orig MES Dest MES Destination CCC Call Input Time Time of Arrival Call Delivery Time 14.11.4 Call Records

e.g. Mobile Originated, EGC, Terrestrial to Mobile Incoming Call Record Number Delivery Call Record Number (if applicable) Forward MES ID (of mobile if applicable) Return MES ID (of mobile if applicable) Type of EGC message (if applicable) Originating MES (if applicable) Originating MES (if applicable) Destination address (if applicable) Call Completion Code (if applicable) time message completely received (if applicable) time message arrival detected (if applicable) time message delivered (if applicable)

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 operator can filter the classes of call records reported on by supplying values to parameter or use the default 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 consisting of the following data: Serial Num MRN Direction Driver Call Nature Completion Code Priority Request Received Internal LES reference Message Reference Number incoming or delivery e.g. X25, SAT e.g. message, NDN message or distress alert -1 to 999 Normal or Distress Time request received

The detailed output consists of the following data: Serial Num MRN Original Network Internal LES reference Message Reference Number Network of message originator
14-16

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

Offline Processing

Call Nature Direction Driver Call Origin Priority CCC Call Destination Request Received Start of Message Completely Received

e.g. message, NDN message or distress alert incoming or delivery e.g. X25, SAT Address of message originator Normal or Distress Completion Code (-1 to 999) Address of message destination Time request received Time start of message 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) gives details of all call records with call completion codes within a specified range, and transmitted either to or from mobiles, for a specified time period, as selected when the report is generated. The output gives the following : Date CALL REC ID ORIGIN ID MESS REF NO DIRECTION CMP CDE CONFM DEL. TDM LUN SIG LUN PACKETS MSG PACKETS RPT ACKNOWLEDGE REQUESTS TOT ACKNOWLEDGE REQUESTS FIRST ACKNOWLEGE REQUESTS LAST MAX OFFSET FREQ MAX OFFSET TIME MIN SIG Call record number Originator of message e.g. mobile number, X121 address Message reference number To or from mobile Call completion code Has delivery been confirmed TDM logical channel unit used Logical signalling channel unit used Number of packets in the message Number of repeat packet transmissions necessary Total number of acknowledgement requests Time of first acknowledgement Time of last acknowledgement Frequency offset of received signal from nominal Time offset from nominal start of frame 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 Record Reports). These provide details of calls to or from MESs, of a specified call type, and with completion codes between a specified range. Note: Some calls reported may be failed calls. If, as a result or cause of failure, any of the times associated with that call are invalid or have been corrupted, then the system earliest time will be displayed. This is 00:00 hours, 1st January 1901. The information presented for the from mobile report is : Date Date call made
14-17

Offline Processing

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

MRN Call Nature CCC Ass Desc Ass Dest Len Slot Freq Msg LUN Announce Pending Destination Dest Ext Len Destination Network MES Busy MES Idle

Message reference number Type of message e.g. message, non-preassigned data report Call completion code Assignment Descriptor Destination Network requested by MES Length of message, in packets Slot used in signal channel Frequency of message channel used (if applicable) Logical channel number of the message channel used, if applicable Time of announcement Time allocated for delivery of message Destination address (if applicable) Destination Extension Length Network used for delivery Time MES became busy Time MES became idle

The information presented for the to mobile report is : Date MRN Call Nature CCC Ass Resp CU Frame Slot TDM LUN Sig LUN Announce Assign Pending Destination Packet Size Num of Pkts Num of Repeated Pkts MES Busy MES Idle Date call made Message reference number Type of message e.g. message, NDN message or distress alert Call completion code Signalling channel used for assignment response Frames used Slot used TDM logical channel unit number, if applicable Signalling logical channel unit number, if applicable Time of Announcement Time of Assignment Time allocated for delivery of message Destination address (if applicable) Size of packet Number of packets Number of repeated packets Time MES became busy Time MES became idle

The EGC Call Report : EGC_CALL.RPT (SOC Viewer - Offline Processing - Options - Report Generation - Call Record Reports) gives details of all EGC type calls. The output gives the following : Date Serial Num MRN Origin Creation Pkts Interval TX Maximum TX Number Service Priority Date of EGC Call record number Message reference number Originator address Time of call creation Number of Packets in EGC message EGC Repetition Interval Maximum number of transmissions Number of transmissions to date EGC Service (C2 code) EGC Priority
14-18

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

Offline Processing

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 mobile over the specified time, specified range of call completion codes and for one or all mobiles, and shows : Date MRN Serial Num Mobile Call Nature CCC Direction Sig LUN Freq Start Complete Volume Pkts Repeated Pkts LCN Error Code Ack Req Tot S/N Max Freq Off Min Max Time Off Min Max Sig Lvl Min Date call made Message reference number Call record number Mobile number Type of call e.g. Message, NDN message or distress alert Call completion code Direction of call, e.g. LES_TO_MES Signalling channel logical channel number Frequency of signalling channel Time of start of call Time of completion of call Call Volume Number of packets Number of repeated packets Logical channel unit Provides further detail of error (for HNS use) Total number of acknowledgement requests Signal to Noise ratio, see below Maximum and minimum frequency offset - variation in frequency of received signal, as described below. Maximum and minimum time offset - variation in time of start of burst from mobile as described below Maximum and minimum signal level - 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. It is not measured on the MSG demodulator, since the relevant value has already been obtained on the 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 2s complement value in steps of 1200/16384Hz, according to the following formula : Frequency offset +23211 to +32767 -23210 to +23210 -32768 to -23211 Hertz greater than 1700 Frequency offset x (1200/16384) less than -1700

Timing offset measures the delay relative to the beginning of the slot, of the burst in quarter TDM symbol units. This value is only measured by signalling channel demodulators. To calculate the timing 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 following formula :
14-19

Offline Processing

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

Signal level >16384 1024 to 16384 <1024

dBm greater than -60dBm -60 + 20log(signal level/16384) 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 completion 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 - Offline Processing - Options - Report Generation - Call Record Reports) gives the number of successful and failed calls, total calls and percentage success, both for incoming and outgoing calls, through each of the satellite, telex, X25, X400, Fax drivers, plus sum for all drivers, for a specified priority or 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 all priorities, in the period specified, for each of the destination networks which may specified in the assignment request packet from a mobile. For each of Telex, PSTN, CSDN, PSDN, X400, CNID, SAC, Other, Mobile, Ocean, Unknown Destination networks as well as Totals of all these and percentage of all calls, for each of the Telex, X25, X400, Fax, Satellite and Totals of all these, are shown for the following : Number of Messages Successfully delivered Number of Messages Failed to deliver Number of NDN/PDN Successfully delivered Number of NDN/PDN Failed to deliver Total Successfully delivered Total Failed to deliver 14.11.5 Default Reports Reports utilities menu The operator can automatically generate a suite of all reports, with default parameters, using Default Reports SOC Viewer - Offline Processing - Options - Report Generation. This writes reports, 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]

14-20

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

Operator Control

Report Name Call Completion Code Report Driver-Specific Call Completion Code Report All Statistics Report Channel Unit Chassis Stats Report Channel Unit Rack Stats Report ISL Link Layer Stats Report TDM Group Stats Report in Event Log Report Distress Summary Report Call Record List Report Call Completion Summary Report Mobile Call Summary Report Telex Route Stats Report All Ships Report (MES to LES) All Ships Report (LES to MES) LES Call Report (From Mobile) LES Call Report (To Mobile) EGC Call Report MES Analysis Report CCC.RPT DRIVER.RPT

File

Reference 14.11.4 14.11.4 14.11.4 14.11.1 14.11.1 14.11.1 14.11.1 14.11.2 14.11.2 14.11.4 14.11.1 14.11.1 14.11.1 14.11.4 14.11.4 14.11.4 14.11.4 14.11.4 14.11.4

ALL_STATS.RPT CU_CHASSIS_STATS.RPT CU_RACK_STATS.RPT ISL_LINK_LAYER_STATS.RPT TDM_GROUP_STATS.RPT EVENT_LOG.RPT DISTRESS_SUMMARY.RPT CALL_RECORD_LIST.RPT CALL_COMPLETION.RPT MOBILE_CALL.RPT TELEX_ROUTE_STATS.RPT MES_TO_LES.RPT LES_TO_MES.RPT LES_CALL_FROM_MOBILE.RPT LES_CALL_TO_MOBILE.RPT EGC_CALL.RPT MES_ANALYSIS.RPT

Table 14-1. Default Report Names, File Names and References

14-21

Operator Control

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

14-22

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

Operator Control

Chapter 15 OPERATOR CONTROL


15.1 Administration of Operators The supervisor must configure operators names and initial passwords into the system using the Operator Definition form (SOC Forms - Operator). Select the form, enter the name and press Show . For a new operator, enter the initial password and the access group (see below) and then press Add . For an existing operator, the password and access group will be displayed. If a change is required, press Modify , enter the new value and then press Enter to change or Delete to remove the 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 First Page . An individual operators entry can be accessed by placing a Y in the left hand column and pressing Select to bring up the Operator Definition form. Operator Access Groups are a means of defining which functions an operator can access. Up to 15 groups - numbers 1 to 15 are valid, number 0 is reserved - can be defined and for each group the SOC forms and functions keys which they can use are identifiable. The access group against each operator is defined in the Operator Definition form described above. The functions for each access 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 access group number (1 to 15), and press Show . Against each of the applicable function keys, there will be an entry of Y or N, according to whether the group should have access to that function or not. To change these settings, press Modify and amend each entry as required. When all the entries are correct press Enter . An extensive help is provided which gives the names of all the forms and the 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 strictly reserved for HNS or system operator use when configuring the system. Initially all other access groups are configured as allowing all read type operations and disallowing all write type operations. 15.2 Changing Passwords The initial password is set up by the supervisor, as described in section 15.1 but each operator can change his password at any time thereafter by selecting the Change Password form (SOC Forms - 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]

15-1

AutoBilling

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

15-2

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

AutoBilling

Chapter 16 GUIDE TO AUTOBILLING


16.1 INTRODUCTION The Advanced billing process described here encompasses two enhancements to the way that billing operates when compared with the former billing process. The fundamental change is that the off-line database is no longer used for billing. Instead the log files are read and processed using cached memory. Reconciliation is performed as soon as the corresponding parts of calls are found. In this way, there is no longer any need for repeated very large database searches and thus 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 is Manual billing which simply makes one call to Faster billing with the set up required for this individual billing run. The second way to run Faster billing is called Auto billing which is set up to allow billing to be configured to run repeatedly at a given interval of time (e.g. once per day). A new 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 system. NOTE Advanced Billing MUST be carried out on these logfiles BEFORE they are copied to the offline area. In addition, the online files should be archived, but not deleted, before copying to offline. This will ensure that the billing run can be repeated at a later date, if necessary, by re-loading from archive.

16-1

AutoBilling

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

16.2 FASTER BILLING Unlike the earlier method, billing no longer requires that the selected log file data be loaded into the offline database. Instead, the call reconciliation is performed in cache The code that generates the billing records and writes them to disk (or tape) is unchanged. This gives a high level of confidence in the correct contents of the billing records. The billing process reads the call records from the logfiles in the order they are logged. Data reports are billed directly as are ICRs that do not require a DCR for billing. ICRs that are billed in conjunction with DCRs are stored in local cache until their DCR is read from the log files. Once an ICR has been reconciled with all of its DCRs it is removed from cache. At the end of a billing run the 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 the loaded OFDB) for the associated ICR. The earlier billing method would result in billing file entries based on a delivery initiation or completion time whereas faster billing, as explained above, processes the data in the order that it was created. This will produce a change in the order that entries appear in the billing file when comparing the two billing methods. For calls that are a success the order will generally be the same. For calls that fail on final delivery they will appear later in the log. This fact should be noted if comparisons 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 for the earlier billing.

16-2

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

AutoBilling

16.3 AUTOBILLING The autobilling function handles the periodic running of faster billing (already described above) . It is responsible for the following operations: Health check of the partner node. Raises an alarm if billing is not running on the partner 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 log files. Throughout this document reference is made to the start and end billing times. By this is meant the time range to bill over, not the time any individual billing run was started or completed. The term 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 the Billing Data Generation menu. Access to this point has not been changed.

16-3

AutoBilling

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

16.3.1 Billing process Once started, billing will execute periodically at a period defined by the operator. On running it executes 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 BAP raising an alarm if not. On the standby BAP the reciprocal check will be run. Once a billing run has started it will continue to completion even if a BAP switch occurs midrun. Before starting a new automatic billing run on the standby, a check will be made to see if billing is already running (for example a manual run started by the operator or post BAP switch billing not yet completed on the master) if so then it will reschedule the next billing run. Maintain a journal file - OFDB$CACHE:User_Journal.Lis At the end of each billing run the billing subsystem will append the following information 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 the operators. The choices made during billing set up allow for billing to be either suspended or to continue 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 operations should 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 had not been requested during configuration. 16.3.2 Billing setup procedure This section describes the basic requirements for setting up autobilling. Following sections give the specific details required at each menu level. Assuming that billing is not running, the operator must first define the configuration for billing
16-4

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

AutoBilling

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 the billing output files are defined. The settings are written to a data file which is read on initiation of autobilling. However if any changes are required here, then auto billing does not need to be restarted 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 must use the Start Autobilling option (see 16.5.3 below) to define the remaining parameters including the start time for the autobilling run. Note that generally this start time should only need to be set/changed before the first ever auto billing run. Subsequently the start time will be taken to be the 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 copy nodes password is entered, since, unlike the billing configuration details above, none of this information is written to file. 16.3.3 Billing housekeeping procedure Once autobilling has been started, the operator must perform various housekeeping functions (see 16.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 been provided within the autobilling area. This has been tailored to suit the auto billing procedures and should 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 performed automatically on completion of each billing run. In addition, provided that two tape drives are available, 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/or taking backups of system or quorum disks. It should be remembered that billing is not dependant on having the host BAP running. Therefore in order to prevent unnecessary file changes during this period, billing should be locked. On unlocking billing, generation of the missing billing data files will commence within one minute. The billing process will be aware of the excess of un-billed log files (by virtue of the greater time span of these files). In this case, in order that the billing centre does not become overloaded with an unusually large file, billing will be performed in as many steps of the desired time span as required to clear the backlog. This will result in two or more files being produced of the 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 disk to fill with new log files before the earliest logs can be billed, archived and deleted.

16-5

AutoBilling

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

16.3.4 Account name and password changes It should be remembered that to run correctly, auto billing requires that the account names and passwords be defined for both the partner BAP node and the remote target nodes for Billing operations. If any of these are changed for reasons of security or for the purpose of granting HNS access to part of the system, then errors will occur. Section 16.5.3 shows where these passwords are defined for use by autobilling. Section 16.5.5.2 indicates how to alter the target nodes password 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 this effect. However billing will still be able to continue normally though will not be able to detect the loss 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 the change will be preserved locally but will not have been copied. The autobilling run may, or may not continue, 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.1 covers the setting of the Copy error continue flag. Section 16.9 gives instructions for error recovery instructions

16-6

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

AutoBilling

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 and should only be considered for use in exceptional circumstances. Housekeeping has been configured to backup and delete files based on the latest autobilling run times. Excessive use of manual billing rather than autobilling may result in complications for the operator and incomplete housekeeping. 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. The DCR one will be derived from the ICR name. Note that the carry over files used are not affected by the 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 resulting 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 backup and 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.

16-7

AutoBilling

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

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 Data Generation 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 Autobilling Menu Tree for the SOC viewer access. The following billing functions are available at this level. (Those items in capitals generate further menus). 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 activities are 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 of billing data at a time requested by the operator). LOCKED if billing has been locked out by the operator 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 current node) 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 billing has 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 name In order to ensure that autobilling continues after a BAP switch, the billing process monitors its partner node for the continuing existence of the corresponding process there. In the event that this is not found, then an alarm will be raised. The software will calculate the partner node name directly, this being the name of the other BAP in a redundant pair. The user may over write this value if required.

16-8

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

AutoBilling

2. Modify Billing mode The billing mode may be STANDBY or EITHER. Ordinarily, this value should be set to STANDBY. The billing mode defines the status that a BAP must have in order to allow billing to run on that BAP. This refers to the Master/Standby mode. Setting the mode to STANDBY will mean that billing will always switch to run on the standby partner so that billing is never performed on a master BAP. If set to either then billing will be performed irrespective of the BAP status. Note EITHER must only be specified if and when one and only one autobilling process is running, for example when the standby BAP is down for upgrade otherwise billing may be performed twice whenever the either BAP is master. 3. Modify Billing interval The billing interval time for each billing run. It will accept any valid delta time. The format for this is: DDDD-HH:MM:SS.CC The DDDD- and .CC are optional Examples of likely intervals ; Required Interval 1 day 1 week 2 weeks Specification for Billing Interval 1-00:00:00.00 7-00:00:00.00 14-00:00:00.00

Note: If an interval of less than one day is specified then due to the naming convention 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 node The target node is the DECNET node name that the user may wish to have the billing files copied to. If it is set to DONT_COPY then no copying of the billing files will take place. 5. Modify Target directory Target directory is the full path on the target node where the file is to be copied to. 6. Modify Delete after copy If this flag is set true then the billing file will be deleted after it is copied to the target node. Note: If Modify Target node has been set to DONT_COPY, then this flag should be set to FALSE. 7. Modify Billing error continue Billing error continue. If this is set true then the billing will continue even if an error occurs. This will normally mean that the autobilling sequence will continue after the predefined interval, leaving the operator to manually correct the current fault. This option should be used with caution. 8. Modify Copy error continue Copy Error Continue. If this is set true then the billing process will continue even if a copy of the billing file failed. 9. Modify Copy User name This is the name of an account with write privilege for the target directory.

16-9

AutoBilling

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

16.5.2.2 CSV File Operation Configuration 1. Auto CSV Generation required By default this is FALSE. If set to TRUE then each time an Auto Billing Run executes it will create a CSV file from the billing file output. If left as FALSE then the manual CSV file option can be used to provide these files when required. 2. Target Node name for Copy This option is only applicable to CSV files created during Auto Billing Runs. The target node is the DECNet node name that the user may wish to have the CSV output file copied to. If it is set to DONT_COPY then no copying of the CSV file will take place. 3. Target Directory for Copy This option is only applicable to CSV files created during Auto Billing Runs. This is the 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 is the User name of the account to which the CSV file is to be copied. 5. Alter Target Password This option is only applicable to CSV files created during Auto Billing Runs. Unlike the 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. To change it select this option. When altered it is written in an encrypted format to the configuration file. It appears nowhere in a Human readable form. 6. Delete File after Copy This option is only applicable to CSV files created during Auto Billing Runs. If this is set to TRUE then once the CSV File has been transferred successfully to the remote node the local copy will be deleted. If the operator has so configured the CSV process to not copy the local CSV file then this delete operation will not be performed. G. Generate CSV File An option to manually generate the CSV File. Selecting this option the user is prompted for the Full Directory Path and then file name of the Billing File Output from which the CSV file is to be generated. The CSV file will be created in the OFDB$LISTDIR directory with a file name as that of the billing file 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 password and then starts it as a batch job. On selecting the start auto billing function the user will be presented with the following SOCV form menu list. 1. Modify Batch queue Defines which batch queue to run the autobilling job on. This is defaulted to SYS$BATCH 2. Modify Start time Start Time is the time the user wishes the first billing run should run from. See section 16.5.3.1 regarding start times.
16-10

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

AutoBilling

3. Modify Copy password The copy password is the password for the account to which the billing file is to be copied on the target node. The account has the User name defined in the autobilling 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 then decoded before being used. 4. Modify Partner password The 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 then decoded before being used 5. Submit billing Note, should the passwords be changed (at the remote nodes) then autobilling will need to be restarted using the new passwords. 16.5.3.1 Start times Before contemplating changes to start times one ANY live system, the following note should be understood. When Advanced Billing was installed for the first time on an LES, the OFLN database converter should have been run, thus creating the initial carry over files. If carry over is to be used, these files MUST be kept up to date. In other words from the creation of the initial carry over files, Advanced Billing MUST always be run over CONTIGUOUS periods, with the initial start time being set to the end of the period covered by LAST old billing run. These contiguous Advanced Billing runs can be performed either by Auto or Manual Billing (both of 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 accurate OFDB$CACHE:JOURNAL.LIS does not exist (the operator could/may have deleted it), then a default 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 billed immediately. The day boundary has been provided in order to assist the operator in the following ways: To reduce operator typing by calculating the most recent start time from which a full interval, 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 billing run on a live system be that of the end of the last old billing run. If this start time does not coincide with the required time for the auto billing runs, the operator may wish to adjust the interval until the start time coincides with a desired time. In this way contiguous billing runs will be maintained. If a valid journal file is found (i.e. billing has been run before), then the last line in this file will indicate the end time of the last billing run on this BAP pair (the journal file is common to both BAPs). It is assumed that, in normal circumstances, a contiguous set of billing runs will be required, 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 of the consequences and be asked to confirm the change. This will then be written, immediately, to
16-11

AutoBilling

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

the journal file. The operator may of course provide any other start time he wishes. The acceptance of the offered start 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 are made to the journaled start time, then a reminder that this MAY result in skipped or duplicated billing will be displayed. This is primarily there as a safeguard against the operator entering erroneous start times (i.e. thinking that of the previous end time was, for example, 00:00, he might enter 00:01 as the next start time, this would be WRONG). In the event that the operator does indeed wish to shift the start times, then the warning may be safely ignored on the assumption that the consequences are understood. If the specified time is less than interval + 5 minutes in the past, then this will be accepted, but billing will not run until 5 minutes after the completion of the first interval period following the entered start time. If the specified time is more than interval + 5 minutes in the past, then billing will commence immediately, and create a full set of output files for every full interval period following the given time. 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 from the 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 operator will have been warned of the existence of a billing batch job before reaching this point. There are two possible outcomes which should be borne in mind when changing these times if billing has not been stopped. 1. Billing is active (on either node) In this case, there is a possibility that the billing process has yet to make its entries in the journal file. If this happens, then changes made by the operator will not be found at the next billing run. It is recommended that the start time should not be altered 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 plus interval), auto billing will run, based on the new start time. It will create a full set of output files for every full interval period following the new start time. If there are no full periods (i.e. new start time, plus interval plus 5 minutes is not in the past) then the next billing run will be rescheduled for 5 minutes after the first full interval.

16-12

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

AutoBilling

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 will create a special entry in the user journal (see 16.6.1.3 below) but will not affect the normal carryover file. The following commands and options are provided to enable the operator to (re)create a billing file at will. 1. Modify Start Time The 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 time The end time is defaulted to one day after the start time. The operator may enter any other valid time that he wishes. 3. Modify Run Number Run Number, as stored in the billing tape header, is set to 00001 by default 4. Modify File ID File ID set to CBTAPE by default and stored in the billing tape header. 5. Modify Billing File Name The 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 directory The source directory defaults to BAP$LOG and points to the location of the logfiles to be used. 7. Modify carry over file The carry over file name needs to be specified. This should not be the same as the current system carry over file. Only the ICR carry over name is required. The DCR one will be derived from the ICR name. 8. Run billing

16-13

AutoBilling

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

16.5.5 Housekeeping The housekeeping menu aims to bring all the housekeeping functions associated with Advanced billing together under one menu. Housekeeping should NOT be performed when a billing session is ACTIVE or is imminent. These procedures replace the existing OFDB housekeeping procedures. The menu takes the form: A full description of each each option available from this menu is given after the summary shown below. 1. Backup/Copy billing files 2. Backup log and carryover files 3. Delete backed up log and/or carryover files 4. Restore backed up log and carryover files 5. View the Journal file 6. 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 an existing set of files on a tape, or to INITIALISE a new (or recycled) tape, overwriting any 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 be backed 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 label will 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 over files. Note that this does not include the current carryover files which will be used as input for the next auto billing run. This means that restoring carryover files from tape 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 log files last modified before midnight X days in the past will then be deleted (i.e. files opened before midnight, but not closed until the next day will not be included). If this includes the latest log file, then the operator will be asked to retry later. If no log files fall in the above categories, then the operator will be informed. Only previously backed up files will be deleted. If any OFDB processing of these logfiles is required (report generation etc) then they must have been copied to the offline area BEFORE this step is performed. See 16.5.5.2 below.
16-14

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

AutoBilling

As for log files, the operator can select to delete carry over files created before midnight 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 will be restored to OFDB$CACHE, but the operator can specify the destination required for the log files (defaulted to BAP$LOG). The operator must check that sufficient disk space is available before restoring log files. This routine will handle tapes created under earlier releases where log and carryover files were backed up to different tapes, and will restore the files as appropriate to the tape inserted. 5. View the Journal file The option to view the user journal file (ofdb$cache:user_journal.lis) will give operators access to the user journal file from SOCV 6. Truncate journal/Delete history file As 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 contain 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 history files. C. Configure Auto Housekeeping This 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 be carried out regularly, normally after each billing run and will permit almost fully automated billing. Depending on whether or not any offline processing is to be performed on the LES log files, one of two housekeeping philosophies should be followed. These are described in sections 16.5.5.1 and 16.5.5.2 below.

16-15

AutoBilling

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

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 on the current batch of log files then the simple housekeeping procedures shown in figure 16-1 below should be followed. There are four steps to this, after creating the billing data from selected log files (performed automatically), 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 housekeeping procedures should be performed for the relevant files after creating the billing data from selected log files (performed automatically or manually). 1. Backup carry over files 2. Delete carry over files 3. 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-16

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

AutoBilling

MASTER BAP

Micro VAX

(ONLINE) LOG FILES

REPORTS

5 AUTO BILLING 4 1 CARRYOVER FILES 3 DELETED FILES

2 BILLING FILES

DELETED CARRYOVER FILES ARCHIVED CARRYOVER FILES

ARCHIVED LOGFILES

[Autobil]

Figure 16-1. Housekeeping where OFDB processing is not required


[autobil.eps]

16-17

AutoBilling

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

MASTER BAP

Micro VAX

AUTO BILLING

(ONLINE) LOG FILES

1 CARRYOVER 3 FILES 2 3 OFFLINE LOG FILES ARCHIVED CARRYOVER FILES 4 5

DELETED CARRYOVER FILES

ARCHIVED LOGFILES

BILLING FILES

OFFLINE DATABASE

BILLING ESSENTIALS

REPORTS DELETED FILES

(ARCHIVE DATABASE)
[AbilONDB]

Figure 16-2. Housekeeping where OFDB processing is required


[AbilOFDB.eps]

16-18

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

AutoBilling

16.5.6 Auto Housekeeping Those housekeeping functions regularly carried out after each billing run may be automated using this option. These being: 1. Copy, to tape, the billing output file produced by the current billing run just completed. 2. Backup, to tape, the log and carryover files involved in the last billing run, plus any others 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 billing run as each tape is initialised prior to processing. In the case that only one drive is available, then only one of the tape options should be specified and the other operation performed manually. It remains 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 on in 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.2 below. An alarm will be raised in case of failures during autohousekeeping. Configuration details required are: 1 2 3 4 5 Select Billing Tape Drive Select Backup Tape Drive Delete Logfiles older than Delete C/O files older than Reset auto housekeeping : : : :

For 1 and 2, the operator may enter any available tape drive name. To deselect a tape drive, entering Quit when asked for the name will result in DONT_COPY being displayed against the option, and no copy will take place. The specification of a tape drive is all that is required to enable the appropriate copy/backup action. If the same drive name is entered in both cases, then when the first operation (billing o/p) has completed, 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

16-19

AutoBilling

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

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 DONT_COPY and both durations to DONT_DELETE, thus offering a simple 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 all times EXCEPT for the duration of auto housekeeping immediately following each billing run. The operator 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 drive and are write enabled. The duration of the auto housekeeping process will depend on the volume of calls/size of log files being 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 become 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 time should be set on an hourly boundary (i.e. XX:00). This will mean that the last log file involved in the latest billing run will be closed when autohousekeeping is performed. Successful backup will then 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 multiple billing runs will be performed, it is recommended that auto housekeeping be disabled (reset) before starting billing. Once the billing runs are back up to date, (i.e. the next scheduled billing run is in the future), then manual housekeeping should be used to cover the catch up period. When this has been completed, then auto housekeeping may be enabled for future auto billing runs.

16-20

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

AutoBilling

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 information included in the user journal is the start and end time of the billing run. The statistics collected during 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. An example 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:00 The disk billing file is : OFDB$LISTDIR:BILLING_200001270000.DAT Disk space ample currently : 124983 The ICR carry over file Copied to : OFDB$CACHE:Carry_Over_200001270000.DAT The DCR carry over file copied to : OFDB$CACHE:DCR_Carry_Over_200001270000.DAT Billing started at : 28-JAN-2000 00:05:14.96 The billing run was a : SUCCESS Billing completed at : 28-JAN-2000 00:11:05.15 Call counts from the billing run Current ICRs in cache 0 Peak ICRs in cache 1 Number of cache over flows ICRs read from the Cache 1 Unreconciled DCRs 0 ICR retrieves ICR only billing 0 DCRs billed 1 Data reports billed ICRs cancelled 0 ICRs not loaded 0 Failed DCR reconciliations were : end of DCR reconciliation failures User does not want billing to be copied to another node ***************************** END OF BILLING RUN ****************************

0 0 0

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 run 3. 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 this figure 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 DCR carry over files. See section 16.9 for instructions on this recovery. 5. DCR carry over 6. 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 are reported). 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 the cache being full. If this value is greater than 0 then the size of the cache MUST 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 find their ICR in the CACHE. The DCR cache is periodically checked to attempt to
16-21

AutoBilling

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

match ICRs and DCRs. This value shows the number of DCRs that will be carried over to the next billing run. ICR retrieves. It is possible, via a control flag, to get the billing software to search the log files 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 completion code. DCRS billed. The number of attempted DCR billing operations = Success (ICRs read from the 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 by the 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. The information (ICR number, DCR number, driver and CCC) will allow the operator to track down the problem. 11. The final entry in the journal is the status of the billing file copy, or a message indicating 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 already performed, 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:32 Start_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 which triggered the housekeeping. Any failures will result in an alarm so that the operator is prompted to check the User_Journal and rectify 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-22

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

AutoBilling

***************************** HOUSEKEEPING ***************************


OFDB$LISTDIR:BILLING_200001270000.DAT copied to MKA500: Status of Log and Carryover file backup is: SUCCESS Deleting (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), together with valid entries for both delete options. **************************** HOUSEKEEPING ****************************
OFDB$LISTDIR:BILLING_200001270000.DAT copied to MKA500: Status of LOG and Carryover file backup is : SUCCESS Deleting (already backed up) log files last modified before 23-APR-1999 Looking for backed up Carryover files created before 23-APR-1999 Carryover file(s) found and deleted ************************* End of Housekeeping ************************

As above, but now with a drive specified for backup. This is the normal successful completion 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 all other steps have resulted in no action. In this case, the last billed log file was still open at time of housekeeping consequently no log files have been backed up In addition, in the case of certain failures, additional information will be logged indicating the point at 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 journal file:
***************************** END OF BILLING RUN **************************** MANUAL billing run started for range 15-JAN-2000 10:00 to 15-JAN-2000:10:30 The disk billing file is OFDB$LISTDIR:NEW_Billing.DAT The billing run was a success Call counts from the billing run Current ICRs in cache 0 Peak ICRs in cache 1 Number of cache over flows ICRs read from the Cache 1 Unreconciled DCRs 0 ICR retrieves ICR only billing 0 DCRs billed 1 Data reports billed ICRs cancelled 0 ICRs not loaded 0 ************************** END OF MANUAL BILLING RUN *************************

0 0 0

The entries here are similar to those for the auto billing user journal entries.

16-23

AutoBilling

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

16.6.2 System Journal file The (System) Journal file, ofdb$cache:journal.lis, is only written to by auto billing. It provides a breakdown of the auto billing runs carried out on the system. At the end of each auto billing run the following details are written to this file (a single line entry for each run): the start and end time of 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 the start time. In this case the requested update will be reflected in the journal file with a dummy entry giving 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 LES is a store and forward system these two parts may occur with some time between the them. The information relating to the incoming part of a call is recorded in the LES Log files as an Incoming Call Record (ICR). The information relating to the delivery part of a call is recorded in the LES Log files 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 the matching DCR(s) have not yet all been found. For this reason the ICR must be carried over. So the ICR carry over file contains any such ICRs. The next billing run will read in the carried over ICRs so they can be reconciled. Without this it would not be possible to bill the corresponding DCRs. Note that under obscure conditions it is possible for a DCR to be logged before the corresponding ICR 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 over files. If carry over is required, it is important that the first auto billing run is contiguous with the time of 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 current start time included in the file name as follows: From Carry_Over.Dat DCR_Carry_Over.Dat To Carry_Over_YYYYMMDDHHMM.Dat e.g. Carry_Over_200001270000.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 be backed 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 faster billing and then deleted. At the end of the billing run, after the billing output file has been created, then new carry over files are created (Carry_Over.Dat and DCR_Carry_Over.Dat).

16-24

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

AutoBilling

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.Dat DCR_Manual.Dat (these are the files used by manual billing). The specified carry over files are also copied to: Manual_<YYYYMMDDHHMM>.Dat DCR_Manual_<YYYYMMDDHHMM>.Dat These files are used to keep a record of the carry over files used for manual billing runs and will be 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 billing and then deleted. At the end of the billing run, after the billing output file has been created, then new carry over files are created (Manual.Dat and DCR_Manual.Dat). Note that if a manual billing run is performed because an auto billing run has failed, the resultant carry over files will need to be copied so that they will be picked up be auto billing (see section 16.9 below).

16-25

AutoBilling

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

16.7 ALARMS AND EVENTS The following five alarms of Group BAPS_GROUP and Class BAP are now added to the online DB. 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 a failure condition Copy of billing file to target node has failed. Check User Journal. Check DECnet. Manually copy file when problem rectified. If the option 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 password Check password. Auto housekeeping run error. A warning has been logged during the auto housekeeping run. Check OFDB$CACHE:User_Journal.Lis, BAP$ERROR:Auto_Billing*.LOG and output tape. Correct the error and run manual backup/deletion.

16-26

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

AutoBilling

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 node where billing will run and it is this session which will maintain the journal files. It is though the journal file that both BAPs remain in sync. The operations detailed below do not need to be performed simultaneously on each BAP. The only proviso being that, assuming that the changes are required to be put into effect, each BAP should be (re)started before the next scheduled billing session. 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) 5. Ensure that all parameters are set to desired values. 6. Submit billing - option S NOTE: This must be performed on both BAPs and the same values should be used for both. Any differences entered on one node after the other node had been set up, are likely to result in confusion. 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 of a scheduled billing run it is safe to make any such changes without stopping or locking billing. The changes will be picked up at the next scheduled run. However if the billing interval has been changed, billing should be stopped and restarted in order to schedule the next run at the correct 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 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 performed 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)
16-27

AutoBilling

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

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 same time 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 this procedure 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 backups, it might be better to start backups immediately after the end of a billing run (check the batch queue for billing jobs, executing or holding) 1. Lock billing (both BAPs) - Option 2 2. Perform backups 3. Unlock billing (both BAPs) - Option 3

16-28

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

AutoBilling

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, the batch 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 producing any 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 temporary (for example to allow HNS access), then no further action need be taken. If the change is permanent, then the autobilling process which raised the alarm must be restarted using the new password in the set-up. If the error was in copying the billing file to the required destination, then manually copy the billing file to the required destination once the problem has been corrected (or deliver the file by an alternate method if urgent). If the copy error continue flag has been set to CONTINUE, then the billing process will continue as normal at the next scheduled time. If not, then autobilling will need to be restarted. 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 autobilling has been configured to halt on an error (or has subsequently been halted by the operator) then the user 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 form OFDB$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 form OFDB$CACHE:DCR_Carry_Over_<Date/Time>.DAT. Where the time stamp in the file name matches the start time of the billing run.

16-29

AutoBilling

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

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 time taken 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 required 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 over files. Unlock billing from the autobilling main menu.
[opg16.mss]

16-30

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

Switch Settings

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 BAP FEP DHQ11 in TIF rack (DHV mode) Switch none switch E19 switch E11 bits 1, 6, 9 ON In addition set bit 10 ON on second board bits 1, 4, 5, ON In addition set bit 8 ON on second board One 3-position switch (on top) and two dial switches (below) control console interface and automatic reboot option. 1) 3-position switch - set to bottom setting (circle with dot above). 2) Middle dial - set to top setting (arrow) 3) Bottom dial - set to e.g. 19200 OR FEP CPU (TIF) Monitor Connection FEP in CUC rack DEMSA LA210 Printer DIL switch adjacent to monitor connection on KA630CNF none none DIL switch 1 DIL switch 2 bit 6 up, all others down bits 1, 3, 4, 8 up, all others down For normal operation or non-interactive monitoring, switches 2,4 down (= On), all other switches up (= Off) For interactive monitoring, see section 10.2.4 Setting

FEP CPU (TIF) Monitor Connection

Rear Console control (CK-KA630-A)

A-1

Switch Settings

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

A.2 Channel Unit Equipment Switches Ensure that any replacement modules are set as shown below. Component Modem Chassis Switch Tray Address Setting Chassis ID as configured on the Channel unit chassis definition screen. See section 7.4.4. Center - Auto MTM selection enabled Press for manual reset; returns to correct position automatically. 0 (not Open) - SCP Frame Sync enabled 0 (not Open) - CU Frame Sync enabled 0 (not Open) - not used 0 (not Open) - Debugger Disabled 0 (not Open) - Enable SCP Timeout Audible Alarm 1,0,0 (6 Open, 7, 8 Closed) SCP Timeout Value. Bit 6 is the low order bit, and bit 8 is the high order bit, giving a range of values of 0-7. All zeros disables the timeout. 1-7 ranges from 20 to 140 seconds in 20 second increments. The default 1,0,0 for switches 6,7,8 gives a value of 1, which corresponds to a 20 second SCP Timeout Value.

ASM

S1-Toggle S2-Toggle S3-DIL switch bit 1 bit 2 bit 3 bit 4 bit 5 bits 6-8

Jumpers have these functions when in A or B position, i.e. the opposite letter is visible. W1-Jumper W2-Jumper W3-Jumper W4-Jumper MTM Toggle A - Manual reset enabled A - Relay test disabled B - Speaker output enabled A - Watch dog timeout enabled Used to set frame number zero at midnight. Press a few seconds before midnight and release exactly at midnight. Include/exclude satellite loop delay in frame timing. For satellite the link should be in the left hand position and B visible. Place in right hand position for instation loopback only. Install for internal oscillator. 1-8 Normally ON. Leave ON for normal operation
A-2

MTM

W1-Jumper

Link J3-J4 MOD S1-DIL switch

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

Switch Settings

S2-Toggle S3-Toggle

When OFF, used as follows: 1 - not used 2 - BER Test Mode 3 - Slot Number Hex Display 4 - Debugger Enable 5 - Transmit Disable 6 - Multidrop Timer Disable 7 - Multidrop Max Msg Size (1000 off/512 on) 8 - ISL Test Mode Press for manual reset; returns to correct position automatically. 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 operation When OFF, used as follows: 1 - Force Collision Detect Flag 2 - TDM Data Mode 3 - Slot Number Hex Display 4 - Debugger Enable 5 - Not used 6 - Multidrop Timer Disable 7 - Multidrop Max Msg Size (1000 off/512 on) 8 - Displays frame number Press for manual reset; returns to correct position automatically. 1,2,3 open, 4 closed - Sets T0 Value for slot timing. 1-2 - Enable DSP Clock 1-2 - Vector Signal Processor Start State Lookup Page (with W3 & W4) 1-2 - Vector Signal Processor Start State Lookup Page (with W2 & W4) 1-2 - Vector Signal Processor Start State Lookup Page (with W2 & W3)

S2-Toggle S3-DIL switch W1-Jumper W2-Jumper W3-Jumper W4-Jumper

A.3 Other Components Component Arbiter tray CPU Switch Front panel Rotary Switch in centre of board CU and Telex Switchover trays CPU Front panel Rotary Switch in centre of board Setting Centre for auto Up to select BAP A as master Down to select BAP B as master Arrow pointing to 4 : Arbiter Not used Arrow pointing to 8 : Switch Controller

A-3

Switch Settings

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

Arbiter tray See note Arbiter tray See note CU Switchover tray See note CU Switchover tray See note

PSU/relay card Switch nearest front of rack PSU/relay card Switch nearest rear of rack PSU/relay card Switch nearest front of rack PSU/relay card Switch nearest rear of rack PSU/relay card Switch nearest front of rack PSU/relay card Switch nearest rear of rack Auto/Manual Normal/Self Test Letter/Draft Online/Offline

Centre for auto Up to connect BAPA Down to connect BAPB Centre for auto Up to connect DEMSA-A Down to connect DEMSA-B Centre for auto Up to connect CUC1A Down to connect CUC1B Centre for auto Up to connect CUC2A Down to connect CUC2B Centre for auto Up to connect TIC1A Down to connect TIC1B Centre for auto Up to connect TIC2A Down to connect TIC2B Auto (up) Normal (up) Draft (down) Online (up)

Telex Switchover tray See note Telex Switchover tray See note Alarm Printer

Note : the switches on the PSU/relay card must only be used when the CPU card (in slot 0) of the same tray is removed.
[opga1.mss]

A-4

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

Registered User Details

Appendix B REGISTERED USER DETAILS


This appendix lists all the details about registered users which need to be available before a registered 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 Address, line 1 Address, line 2 Address, line 3 Postal code Country Contact name Contact tel Plain text, up to 45 characters, any format Plain text, up to 30 characters, any format Plain text, up to 30 characters, any format Plain text, up to 30 characters, any format Plain text, up to 15 characters, any format Plain text, up to 20 characters, any format Plain text, up to 45 characters, any format 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 Address Address extension Enabled for use as NDN or PDN up to 13 characters, telex, PSDN, PSTN, mobile up to 69 characters, format as in section 8.3.11 up to 4 characters, format as in section 8.3.11 Yes or No

Authorisation information, summarizing the registered services available to this user complete all these fields. Store & forward messages Message status enquiry Cancel messages Polling Data reporting EGC Distress priority messages PIN for use with telex PIN for use with X25/X400 Password Answerback Yes or No normally set to Yes normally set to Yes Yes or No Yes or No Yes or No Yes or No Yes or No Yes or No Yes or No 6 - 10 characters, initially set by operator 13 characters, numbers and upper case letters only PDN

B-1

Registered User Details

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

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) as defined in the reference [1] M5 S9.3.3 and the service type - System, SafetyNET or FleetNET. 0 2 4 11 12 14 23 24 31 33 34 44 72 74 Type System FleetNET SafetyNET System SafetyNET SafetyNET System SafetyNET SafetyNET System SafetyNET SafetyNET FleetNET SafetyNET Use General call Group call Urgency message, NAV warnings to rectangular area System message Coastal warning Shore to ship distress alert to circular area EGC system message Urgency message, MET/NAV warnings to circular area NavArea warning or MET forecast Download ENID (See section 9.4) SAR coordination to rectangular area SAR coordination to circular areas Chart correction service Chart correction fixed area

Polling definition, to be completed if Polling shown as Yes in authorisation information above Show the individual poll commands which the user can issue corresponding to the Command type described in reference [1] M3 Supplement 2 para 4.4.4.2. Code 0 1 2 3 4 5 6 7 8 9 10 11 Use Send unreserved data report Program reserved Initiate reserved Stop reserved Program unreserved Initiate unreserved Stop unreserved Define macro encoded message Macro encoded message Data transmission Download DNID (See section 9.4)) Delete DNID (See section 9.4))

Data Reporting definition, to be completed if Data Reporting shown as Yes in authorisation information above Set the data report file size in bytes, a 7 digit number, with a maximum of 1,000,000. This is the maximum 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 to one PIN.
[opga2.mss]

B-2

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

Guide to using the FAX PC

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 troubleshooting hints. Further details are provided in reference [5]. A further description of the facilities associated with the Zetafax software running on the PC is contained 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 the LESFAX software. 2. LESFAX process will create a text file suffixed with .SUB for each Fax message that it receives. This file is created in "Zetafax API submit file" format and is placed into a common work area on the ShadowDisk. This work area is shared between the LESFAX and PCFAX processes, shared directory access being provided by the Digital Pathworks software. 3. As part of its startup procedure the Fax PC will initiate the PCFAX process which will periodically search for .SUB messages within the shared disk area. PCFAX is responsible for converting .SUB files into .WPC files and submitting them to Zetafax via the Zetafax API interface. 4. The third party Zetafax software receives Fax messages from the PCFAX software and is responsible for ensuring that these messages are successfully delivered. The Zetafax software is responsible for driving up to four Fax modems, and a maximum of eight messages can be queued within the Fax PC awaiting transmission. (Note that 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 unsuccessful Fax message deliveries. Once final delivery status is determined PCFAX will create a file suffixed by .DEL, within the common work area, containing delivery details. In addition the associated .WPC file will be renamed to .FIN to indicate that PCFAX has finished with the message. 6. LESFAX will periodically scan the common work area for files suffixed with .FIN. The associated .DEL file is then read and a delivery call record is logged. Delivery details are returned to Message Director and finally the processed .FIN and .DEL files are deleted. 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 example for routine maintenance. From the FAX PC Display form on the SOC determine the current state of the Fax PC in question. If the Fax PC is not in Out Of Service state, then from the FAX PC Management form
C-1

Guide to using the FAX PC

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

request that the PC state become OOS. If the PC has no calls in progress then it should now become OOS. But if there are still fax calls in progress then the Fax PC should 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 removed then 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 potentially result in hard disk problems. The correct and safe procedure is to double-right click on the OS/2 desktop and select the Shut-Down... option. Then respond with OK to any warnings about closing down sessions and windows containing active programs. The machine can be powered off once the shutdown procedure has completed. Occasionally the OS/2 shutdown sequence will not complete. If this occurs then just invoke shutdown again. If the system still wont shutdown then close any open windows manually (left click on top left of menu bar and select "Close" for any active windows) and then Control-Alt-Delete and wait 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 that the PC has already been configured to be a Fax PC and that the PC is known to Pathworks on the BAP, in accordance with the LES Configuration Document. From the FAX PC Definition form add a new entry for the PC. The PC nodename should be the same as the name quoted to Pathworks and NCP during PC configuration. 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 and two 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 Login window 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 should initialise. It is responsible for starting up the Zetafax Server and will create a file 00000000.SYN in the workarea to indicate to the LES that it has started. LESFAX acknowledges PCFAX by removing this synchronization file. When PCFAX detects the file removal it will complete its initialization and begin scanning the workarea for Fax messages to process. In addition PCFAX periodically creates a heartbeat file (11111111.SYN) in the workarea to indicate to LESFAX that it is still running. LESFAX is responsible for periodically deleting this file. The second of these windows is titled "Zetafax Monitor". It should report messages from the Zetafax 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 the Fax 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 example following routine maintenance.
C-2

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

Guide to using the FAX PC

Reboot the Fax PC and ensure that it restarts correctly - by checking the OS/2 windows 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 question become In Service. The PC state should change from OOS to INS as contact is established 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. Any messages currently queued for Zetafax will be listed here together with their current status : SENDING CONNECTING WAITING Message is currently transmitting to the quoted Fax number. Zetafax is currently dialling the quoted Fax number.

Message is held waiting for transmission. This may be because the Fax number was engaged earlier and the message transmission is to be reattempted, or it may be because all the modem cards on the Fax PC are currently in use. Zetafax maintains a simple text file of all messages logged by the Zetafax Server during the current run: (C:\ZETAFAX\SERVER\Z-DB\SERVER.LOG) This file keeps growing whilst Zetafax Server is running and is cleared down each time the Zetafax Server is restarted. 2. The STARTUP.CMD window will give a good indication of the start of the PCFAX software 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 these cards 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 be searched 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 file C:\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 configurable within this file under the [QUEUEMAN] section as : SendRetryWait: <seconds> { Default: 5 minutes
C-3

Guide to using the FAX PC

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

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 back to the first modem when all modems have been used. If a message cannot be delivered by the designated modem the message will be submitted to another modem until either delivery is successful or the maximum number of delivery attempts is reached. This ensures that all available modems will attempt to deliver a message before a failure is registered and that failure of a single PSTN line or Modem does not cause messages to fail.
[opga3.mss]

C-4

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

Guide to Setting Up Asynchronous Communications

Appendix D GUIDE TO SETTING UP ASYNCHRONOUS COMMUNICATIONS


This is now more fully described in the Configuration Guide, 5.

D-1

Call Completion Code List

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

D-2

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

Call Completion Code List

Appendix E CALL COMPLETION CODES


This list below shows the completion codes which are configured initially. This information is extracted from the software files and is therefore in the format : CCC ICR "Text DCR " DESCRIPTION Text_Len

where: CCC is the call completion code Text_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 record DCR - 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 is generated 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 delivery attempts may have failed (for the same or other reasons). The list below is indexed by the call completion code. -1 ICR no 0 ICR 1 ICR 2 ICR 3 ICR 4 ICR 5 ICR 10 ICR yes "UNK Unknown " 11 DCR DESCRIPTION no Initial CCC set by input driver - changed to ITD by MDir if routed successfully, to failure CCC if not "SUC Call Success DCR DESCRIPTION "SUC Unconfirmed by user" DCR DESCRIPTION "SUC Unconfirmed by oper DCR DESCRIPTION "SUC Unconfirmed on expiry set by user DCR DESCRIPTION "SUC Unconfirmed on expiry set by oper DCR DESCRIPTION " " " " 16

"SUC Unconfirmed on expiry set by system " DCR DESCRIPTION "SUC TLX No EOT Received " 23 DCR DESCRIPTION A message was entered, however a line data exceeded condition occurred, which caused the LES to send the LDE signal, the subsequent required time for end of text to be entered by the user then also expired "SUC TLX LDE Transmitted
E-1

11

"

23

Call Completion Code List

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

ICR yes

DCR

DESCRIPTION A message was entered but either the size was greater than permitted or the duration allowed for message entry has expired LDE - Maximum acceptable message length or duration has been exceeded

12 ICR yes

"SUC TLX Forced Clear On Idle Detection " 38 DCR DESCRIPTION A message was entered into the LES, but the user timed out with idle causing the LES to clear the call. "SUC TLX User Cleared Successful " 31 DCR DESCRIPTION A message was entered but the user cleared without enterend of text "SUC TLX No Answerback End Of Call " 33 DCR DESCRIPTION The calling party did not provide a answerback at the end of the call although a WRU was sent "SUC TLX Text After EOT " 22 DCR DESCRIPTION Text detected after EOT received while waiting for WRU for more than the limit allowed "SUC TLX No Clear Confirm Successful " 35 DCR DESCRIPTION yes The LES has no received a clear signal in response to its own clear, although the message transfer was successful "SUC TLX Tape Stuck Success " 26 DCR DESCRIPTION The tape stuck condition was detected on the line for an incoming call (more than 80 identical consecutive combinations "SUC TLX Automatic Eqp Failed To Clear " 37 DCR DESCRIPTION An automatic terminal i/c call failed to clear down first and the LES had to forward clear as a result "SUC X25 Backward cleared " 24 DCR DESCRIPTION yes The user acknowledged receipt of the message by clearing the call while the LES was pausing before clearing the call itself

13 ICR yes

14 ICR yes

15 ICR yes

16 ICR yes

17 ICR yes

18 ICR yes 30 ICR

Codes in the range 40-49 reserved for X400 service. 50 ICR yes "SUC SD Satellite Call Succeeded " 31 DCR DESCRIPTION yes Call successfully received or delivered or
E-2

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

Call Completion Code List

PVT completed successfully 60 ICR yes 61 ICR yes 62 ICR yes 63 ICR yes 64 ICR yes "SUC MH Success " DCR DESCRIPTION no DN successfully generated by MDir 14

"SUC MH CNID Msg Stored " 22 DCR DESCRIPTION no DNID addressed message successfully stored "SUC MH Data Report Msg Stored " DCR DESCRIPTION no data report successfully stored 29

"SUC MH Not Forwarded CNID Msg Stored " 36 DCR DESCRIPTION no DNID addressed message successfully stored on failing to be immediately forwarded "SUC MH Not Forwarded Data Report Stored " 39 DCR DESCRIPTION no data report successfully stored after failing to be immediately forwarded "SUC MH Data Report Not Delivered " 32 DCR DESCRIPTION no A mobile status data report was not delivered because no DNID was specified for the PIN or the mobile status was unchanged "SUC FAX Message Transmitted " 27 DCR DESCRIPTION Yes Message was delivered successfully

65 ICR yes

70 ICR No

150 ICR 151 ICR 152 ICR 153 ICR 154 ICR 200 ICR yes

"DBU Unconfirmed by user DCR DESCRIPTION "DBU Unconfirmed by oper DCR DESCRIPTION "DBU Unconfirmed on expiry set by user DCR DESCRIPTION "DBU Unconfirmed on expiry set by oper DCR DESCRIPTION

" " " "

23 23 37 37 39

"DBU Unconfirmed on expiry set by system " DCR DESCRIPTION

"BK Clear Down " 14 DCR DESCRIPTION yes Either: Message aborted by LES operator or : Forced clear received from the mobile or : Distress received from the mobile or : Call prematurely cleared or : Message cut by message of higher priority or : Call was cut or disconnected
E-3

Call Completion Code List

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

202 ICR yes 203 ICR yes 204 ICR 205 ICR yes 206 ICR 207 ICR yes 208 ICR yes

"ABS Absent Subscriber " 21 DCR DESCRIPTION Either: Machine switched off or : Mobile not logged into ocean region "BK Message Aborted " 19 DCR DESCRIPTION yes Delivery aborted by Message Handler due to driver interface error "BMC No End of Message or End of TX RXed " DCR DESCRIPTION "DER Out Of Order DCR DESCRIPTION yes Internal error within the LES Protocol error from the mobile "DTE Remote DTE Clearing DCR DESCRIPTION " 39 16

"

23

"FMT Format Error " 16 DCR DESCRIPTION Message did not contain address line "IAB Invalid Answerback " 22 DCR DESCRIPTION Either: No final answerback received from destination or : No initial answerback returned by destination or : Wrong initial answerback sent by destination or : Wrong final answerback returned by destination "INF Call the Network Information Service" DCR DESCRIPTION The mobile has failed to respond "INV Invalid Call DCR DESCRIPTION "LDE Maximum Message Length Exceeded DCR DESCRIPTION "LPE Local Protocol Error DCR DESCRIPTION "MOM Mobile Waiting For Clear DCR DESCRIPTION " 40

209 ICR yes 210 ICR 212 ICR 213 ICR 214 ICR 215 ICR yes

16

" " "

35 24 28

"NA Access to This Number Barred " 32 DCR DESCRIPTION Either: Access to this mobile barred or : The destination is incompatible or : Fast select acceptance not subscribed or : Called address refuses connection "NC Network Congestion DCR DESCRIPTION "NCH Subscribers Number Has Changed DCR DESCRIPTION
E-4

216 ICR 217 ICR

" "

22 34

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

Call Completion Code List

218 ICR yes 219 ICR 220 ICR 221 ICR 222 ICR 223 ICR 224 ICR 225 ICR 229 ICR no

"NDA No Delivery Attempt Has Been Made " 37 DCR DESCRIPTION Call not yet started Currently attempting to deliver the message "NP Not Obtainable DCR DESCRIPTION " 18

"NRC Rev Charging Accept Not Subscribed " 38 DCR DESCRIPTION Reverse charging acceptance not subscribed "OCC Number Busy DCR DESCRIPTION "RDI Redirected Call DCR DESCRIPTION "RPE Remote Protocol Error DCR DESCRIPTION " " " 15 19 25 40 30

"TMD Maximum Number of Addresses Exceeded" DCR DESCRIPTION "UNK Unknown Reason For Failure DCR DESCRIPTION "

"ITD Awaiting Delivery " 21 DCR DESCRIPTION no First delivery attempt pending for normal delivery, EGC or poll TX, or EGC or poll echo - CCC returned to ITD on TX or echo completion if further TX or echo required "ITD Await.Deliv. by 3rd party SAF system" 40 DCR DESCRIPTION no Delivery to third-party store-and-forward system partly complete - remote delivery completion pending (X.400) "NA Invalid Presentation Code DCR DESCRIPTION "BK Cancelled by user DCR DESCRIPTION Cancelled by user "BK Cancelled by oper DCR DESCRIPTION Cancelled by operator " " 29 21

230 ICR no 231 ICR 232 ICR 233 ICR 234 ICR

"

21

"BK Cancelled on expiry set by user " 35 DCR DESCRIPTION Cancelled by system on expiry of cancellation time set by user "BK Cancelled on expiry set by oper " 35 DCR DESCRIPTION Cancelled by system on expiry of cancellation time set by operator "BK Cancelled on expiry set by system " 37 DCR DESCRIPTION Cancelled by system on expiry of cancellation time set
E-5

235 ICR

236 ICR

Call Completion Code List

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

by system 237 ICR "BK Cancelled on TX failure " 27 DCR DESCRIPTION Cancelled by system on transmission failure - a transmission of an EGC or poll message has failed "BK Cancelled on route failure " 30 DCR DESCRIPTION Cancelled by system on route failure - one or more routes have been unavailable for too long "BK Cancelled by user without NDN " 33 DCR DESCRIPTION Cancelled by user, but no NDN generated "BK Cancelled by oper without NDN " 33 DCR DESCRIPTION Cancelled by user, but no NDN generated "NA Not Commissioned " 20 DCR DESCRIPTION Cannot deliver from not commissioned

238 ICR

239 ICR 240 ICR 245 ICR

400 ICR No

"DER FAX Cannot Deliver Via This Route " 37 DCR DESCRIPTION Yes Unable to deliver message via the specified route. The Fax Driver has no record of the route Message Handler has specified as the delivery route. "DER FAX No PC Available On This Route " 37 DCR DESCRIPTION Yes Unable to deliver message via the specified route. The Fax Driver cannot find a PC on the route Message Handler has specified as the delivery route. "DER FAX Failed To Secure Message To PC " 38 DCR DESCRIPTION Yes Unable to secure message to the Fax PCs hard disk, this could indicate a Pathworks problem. "LPE FAX Invalid Delivery File " 29 DCR DESCRIPTION Yes Unable to process a delivery file correctly due to either the .FIN or .DEL file being invalid. This situation may arise due to a PC returning an invalid file, a file being locked or corrupted. It should be assumed that delivery failed, though this is not certain. "LPE FAX Path Not Found " 22 DCR DESCRIPTION Yes The required path cannot be found, possibly due to a Pathworks problem. "DER FAX PC Failure
E-6

401 ICR No

402 ICR No

403 ICR No

404 ICR No 407

"

18

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

Call Completion Code List

ICR No

DCR Yes

DESCRIPTION No PC on the specified route has been able to deliver the message. The message was secured to a PC but the PC has since developed a problem preventing delivery.

410 ICR No

"LPE FAX Cannot Access Control File " 34 DCR DESCRIPTION Yes Unable to access the PC control file for this message or control file is invalid. "LPE FAX Cannot Access Message File " 34 DCR DESCRIPTION Yes Unable to access the PC message file for this message or message file is invalid. "NC FAX PC Disk Full " 20 DCR DESCRIPTION Yes Unable to create the necessary PC files to send the message due to the PC hard disk being full. "LPE FAX Bad Zetafax INI File " 28 DCR DESCRIPTION Yes Unable to access the Zetafax.INI file or Zetafax.INI file is invalid. "LPE FAX Cannot Convert Message " 30 DCR DESCRIPTION Yes Unable to convert message into the correct format for Zetafax. "LPE FAX Cannot Access Letterhead " 32 DCR DESCRIPTION Yes Unable to access letterhead for this message or letterhead file is invalid. "LPE FAX Cannot Access Graphic " 29 DCR DESCRIPTION Yes Unable to access graphics file specified in this message or graphics file is invalid. The term message refers to the fax banner and message text. "DER FAX Device Failed " 21 DCR DESCRIPTION Yes Unable to send message from this fax modem device due to the device failing. This device will remain in a failed state. "NC FAX Device Busy " 19 DCR DESCRIPTION Yes Unable to send message from this fax modem device due to the device being busy. "NC FAX Device Offline
E-7

411 ICR No

412 ICR No

413 ICR No

414 ICR No

415 ICR No

416 ICR No

417 ICR No

418 ICR No

419

"

22

Call Completion Code List

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

ICR No

DCR Yes

DESCRIPTION Unable to send message from this fax modem device due to the device being offline. Device should recover.

420 ICR No

"LPE FAX Device Invalid " 22 DCR DESCRIPTION Yes Unable to send message from this fax modem device due to the device being invalid. Device may be incompatible or configured incorrectly. "NC FAX No Device Available " 27 DCR DESCRIPTION Yes Unable to deliver message as there are no working fax modem devices of the correct type in the delivering PC. "DER FAX Device Protocol Error " 29 DCR DESCRIPTION Yes Unable to deliver message due to a serious error in communicating with this fax modem device. "BK FAX Device Timeout " 22 DCR DESCRIPTION Yes Unable to deliver message from this fax modem device due to the device timing out. "LPE FAX No Dial Tone " 20 DCR DESCRIPTION Yes No dialtone detected by the fax modem when a call attempt was made. This indicates either a failure in the exchange or the connection to the exchange. "NA FAX No Dial Permit " 22 DCR DESCRIPTION Yes No permission to dial the specified number. "OCC FAX Number Busy DCR DESCRIPTION Yes Dialled number was busy. "NP FAX No Reply DCR DESCRIPTION Yes No answer from dialled number. " 19

421 ICR No

422 ICR No

423 ICR No

424 ICR No

425 ICR No 426 ICR No 427 ICR No 428 ICR No

"

16

"RPE FAX Invalid Response " 24 DCR DESCRIPTION Yes An incorrect response was received from the dialled number, i.e. Call answered but not by a valid fax machine. This covers answer by human, other machine (i.e. modem) or faulty fax machine. "BK FAX Transmission Error " 26 DCR DESCRIPTION Yes Unable to deliver message due to a communications error occurring during transmission of the message, e.g. call cut off.
E-8

429 ICR No

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

Call Completion Code List

430 ICR No 431 ICR No

"LDE FAX Message Too Long " 24 DCR DESCRIPTION Yes Message is too long to be delivered. "UNK FAX Send Failed " 19 DCR DESCRIPTION Yes This is used to report problems which cannot be more accurately identified and are not covered by other messages. "NC TLX Idle Timeout " 20 DCR DESCRIPTION no For an incoming call, the call has gone idle - i.e. the user has stopped transmitting for the time allowed. "NC TLX No Seize Confirm " 24 DCR DESCRIPTION yes The called party has not responded to the LES seize signal "NC TLX No PTS Received " 23 DCR DESCRIPTION yes For an o/g call the LES has not received the proceed to send signal. "FMT TLX Invalid Format " 22 DCR DESCRIPTION yes For an outgoing call the LES has received a format error service code (FMT). "NC TLX User Cleared " 20 DCR DESCRIPTION yes For either o/g or i/c call the called/calling party has cleared the call before the expected end of call. "NC TLX User Cleared Awaiting COT " 33 DCR DESCRIPTION no For an i/c call the LES was waiting for a trunk Type C Class of Traffic character (COT), when the caller terminated the call by clearing the line. "NC TLX User Cleared Awaiting COT Check " 39 DCR DESCRIPTION no For an i/c call the LES was waiting for a trunk Type C Class of Traffic Check character (COTC), when the caller terminated the call by clearing the line. "NC TLX User Cleared Awaiting Selection " 39 DCR DESCRIPTION no For an i/c call the LES was waiting for the selection digits when the caller cleared the call. "NC TLX User Cld Await Selectn Validn " 37 DCR DESCRIPTION no For an i/c call the LES was validating the received selection digits when the calling party cleared the call "NC TLX User Cld Awaiting IC Answerback " 39 DCR DESCRIPTION no For an i/c call the calling party cleared the call when the LES was waiting for the calling party answerback.
E-9

500 ICR yes 501 ICR no 502 ICR no 503 ICR no 504 ICR yes 505 ICR yes

506 ICR yes

507 ICR yes 508 ICR yes 509 ICR yes

Call Completion Code List

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

510 ICR yes 511 ICR no 512 ICR yes

"NC TLX Circuit Fault " 21 DCR DESCRIPTION yes A protocol error or communications error related to the circuit behaviour has been detected. "OCC TLX Busy " 12 DCR DESCRIPTION yes The LES has received on an o/g call, the OCC service signal instead of call connect "NC TLX Congested " 17 DCR DESCRIPTION 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 rejected an i/c call due to insufficient call storage resources. "ABS TLX Absent " 14 DCR DESCRIPTION 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 rejected the call because the mobile addressed is not logged on in the ocean region(s) supported by the LES. ABS - Absent subscriber/Office closed "DER TLX Out Of Order " 20 DCR DESCRIPTION yes For an o/g LES call the LES has received the service signal DER instead of call connect DER - Out of order "NC TLX No Circuits " 19 DCR DESCRIPTION For an i/c call, the address had an incorrect F69 code "NP TLX Not Permitted " 21 DCR DESCRIPTION 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 the ship list NP - The called party is not, or is no longer a subscriber "NA TLX Not Admitted " 20 DCR DESCRIPTION yes For an o/g call, the LES received the service signal NA, for an i/c call, the mobile addressed was barred or not authorised for access NA - Correspondence with this subscriber is not admitted "OCC TLX Engaged " 15 DCR DESCRIPTION For an i/c call the addressed mobile was engaged. "INF TLX Unobtainable Call Info Service " 38 DCR DESCRIPTION yes For an o/g call the LES received the service signal INF, in place of call connect INF - subscriber temporarily unobtainable, call informservice "MOM TLX Waiting DCR DESCRIPTION
E-10

513 ICR yes

514 ICR no

515 ICR yes 516 ICR yes

517 ICR yes

518 ICR yes 519 ICR

520 ICR

"

15

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

Call Completion Code List

yes 521 ICR

For an o/g call the LES received the service signal MOM MOM - wait/waiting

"JFE TLX Closed " 14 DCR DESCRIPTION yes For an o/g call the LES received the service signal JFE JFE - Office closed because of holiday "BK TLX I Cut Off " 15 DCR DESCRIPTION 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 idle timeout, 3 consecutive invalid inputs, or paper tape stuck conditions "UNK TLX Other Service Signal " 28 DCR DESCRIPTION yes An unsupported service signal was received when the LES was attempting telex delivery. "IAB TLX Unexpected Answerback " 29 DCR DESCRIPTION yes The answerback received from the called party does not match the expected answerback given by the caller "DER TLX No Answerback " 21 DCR DESCRIPTION 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 "IAB TLX Answerback Mismatch " 26 DCR DESCRIPTION yes For an outgoing, where enabled, the answerback at the start of the call did not match that received at the end allowing for one character mismatch "NC TLX Back Path Signals " 25 DCR DESCRIPTION yes While delivering a telex call the LES detected characters on its received path exceeding the limit allowed for this "NC TLX LES Failure DCR DESCRIPTION yes An software error was detected " 19

522 ICR yes

523 ICR

524 ICR

525 ICR yes

526 ICR

527 ICR

528 ICR yes 529 ICR yes 530 ICR

"NC TLX Tape Stuck " 18 DCR DESCRIPTION For an incoming call more than 80 consecutive exact combinations were detected causing the tape stuck condition "NC TLX Call Preempted By IC " 28 DCR DESCRIPTION yes For bidirectional working, current no supported, the o/g call could not be delivered due to an incoming call occupying the line. "NC TLX Outgoing Circuit Guarded " 32 DCR DESCRIPTION yes The outgoing call could not be made because the line was in its guard state. This code will only occur if there is an interprocess communications fault
E-11

531 ICR

Call Completion Code List

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

532 ICR

"NC TLX No Call Connect " 23 DCR DESCRIPTION yes For an o/g call the LES did not receive the call connect signal within the time allowed "NP TLX No Clear Confirm " 24 DCR DESCRIPTION yes The far end has failed to respond with a clear signal subsequent to the LES sending clear "NC TLX No RC TC " 16 DCR DESCRIPTION yes For Type C trunk signalling, during an outgoing call the LES failed to receive the reception confirmation and transmission confirmation characters "NRT TLX No Further Retests Needed " 33 DCR DESCRIPTION n/a Used internally within the telex driver to notify the retest algorithm that no retests are needed - i.e. the circuit is now operating correctly "NA TLX Invalid Seize Combination " 33 DCR DESCRIPTION For Type C trunk signalling, an incoming call was received but the seize combinations Ts were not correctly received "NA TLX Invalid COT " 19 DCR DESCRIPTION For Type C trunk signalling the class of traffic combination was not as expected "NA TLX Invalid COT COTC " 24 DCR DESCRIPTION For Type C trunk signalling the combined class of traffic and class of traffic check character do not validate "NA TLX No COT Sent " 19 DCR DESCRIPTION For Type C trunk signalling the class of traffic characwas not received by the LES during an incoming call "NA TLX COT Not Permitted " 25 DCR DESCRIPTION For Type C trunk signalling, for an i/c call the COT combination received is not permitted "RTD TLX Incoming Retest Detected " 32 DCR DESCRIPTION For Type C trunk signalling, an incoming retest call has been received "DER TLX Incoming Message Not Secured " 36 DCR DESCRIPTION The LES was unable to store the received message, either due to a resource failure or a software fault "NA TLX No PIN " 14 DCR DESCRIPTION For registered access no PIN was received
E-12

533 ICR yes 534 ICR

535 ICR n/a

536 ICR yes

537 ICR yes 538 ICR yes 539 ICR yes 540 ICR yes 541 ICR yes 542 ICR yes 543 ICR yes

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

Call Completion Code List

544 ICR yes 545 ICR yes 546 ICR

"NP TLX Invalid PIN " 19 DCR DESCRIPTION For registered access the PIN received was invalid "NA TLX No WRU " 14 DCR DESCRIPTION For subscriber signalling the exchange failed to send a WRU combination at call initiation "NC TLX Invalid PTS " 19 DCR DESCRIPTION yes For an o/g call the LES did not receive a valid proceed to send character "NC TLX Stn CLosed Await IC Answerback DCR DESCRIPTION "NC TLX Stn Closed Await CLear Confirm DCR DESCRIPTION "NC TLX Station Closed DCR DESCRIPTION " " " 38 38 22

547 ICR 548 ICR 549 ICR 550 ICR

"NCH TLX Number Changed " 22 DCR DESCRIPTION yes For an o/g call, the LES received the service signal NCH instead of call connect "NC Multi delivery address not supported" DCR DESCRIPTION "NC No outgoing circuit available DCR DESCRIPTION "NC No free circuit at the moment DCR DESCRIPTION "NC Too many attempts at delivery DCR DESCRIPTION "NC Software err: MES AB rtn failed DCR DESCRIPTION "NC Software err: CODT i/f failed DCR DESCRIPTION "NC Software err: MDIR ROU i/f failed DCR DESCRIPTION "NC Software err: MDIR DEL i/f failed DCR DESCRIPTION "NC Software err: TLXIL IC i/f failed DCR DESCRIPTION "NC System err: i/c call record failed DCR DESCRIPTION "NC Software err: TESH i/f failed DCR DESCRIPTION "NC Software err: SDA Regd i/f failed
E-13

551 ICR 552 ICR 553 ICR 554 ICR 555 ICR 556 ICR 557 ICR 558 ICR 559 ICR 560 ICR 561 ICR 562

40 33 33 33 35 33 37 37 37 38 33 37

" " " " " " " " " " "

Call Completion Code List

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

ICR 563 ICR 564 ICR 565 ICR 566 ICR 567 ICR 568 ICR 569 ICR 570 ICR 571 ICR 572 ICR 573 ICR 574 ICR 575 ICR 576 ICR 577 ICR 578 ICR 579 ICR 580 ICR 581 ICR 582 ICR

DCR

DESCRIPTION " " " " " " " " " " " " " " " " " " " " 35 29 36 36 38 31 38 37 33 26 34 37 27 28 35 27 31 37 38 36

"NC User failed to enter valid data DCR DESCRIPTION "NC Oversize message detected DCR DESCRIPTION "NC Circuit not for unregd msg entry DCR DESCRIPTION "NC Call ended due to FEP switchover DCR DESCRIPTION "NC Call ended due to Operator request DCR DESCRIPTION "NC Invalid destination address DCR DESCRIPTION "NC System err: o/g call record failed DCR DESCRIPTION "NC Communication equipment was reset DCR DESCRIPTION "NC Communication equipment fault DCR DESCRIPTION "NC No call connect signal DCR DESCRIPTION "NC BAP timeout on FEP o/g service DCR DESCRIPTION "NC Software err: TLXOL OC i/f failed DCR DESCRIPTION "NC Bad message cause error DCR DESCRIPTION "NC Active circuit gone busy DCR DESCRIPTION "NC Active circuit gone statn close DCR DESCRIPTION "NC Active circuit at fault DCR DESCRIPTION "NC Circuit from Guard to fault DCR DESCRIPTION "NC Circuit fault, o/g seize rejected DCR DESCRIPTION "NC Station closed, o/g seize rejected DCR DESCRIPTION "NC Circuit busy, o/g seize rejected DCR DESCRIPTION
E-14

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

Call Completion Code List

583 ICR 584 ICR 585 ICR 586 ICR 587 ICR 588 ICR 589 ICR 590 ICR 591 ICR 592 ICR 593 ICR 594 ICR 600 ICR Yes 601 ICR Yes 602 ICR Yes 603 ICR No 604 ICR No 605 ICR Yes

"NC Circuit from busy to fault DCR DESCRIPTION

"

30 39 36 20 35 34 37 39 35 20 36 34

"NC Circuit from busy to Out-of-Service " DCR DESCRIPTION "NC Station closed to Out-of-Service DCR DESCRIPTION "NC FEP was inactive DCR DESCRIPTION "NC Incorrect termination character DCR DESCRIPTION "NC LO timeout on msg transmit ack DCR DESCRIPTION "NC Failed to format delivery message DCR DESCRIPTION " " " " "

"NC FEP timeout on BAP delivery service " DCR DESCRIPTION "NC FEP timeout on FEP line service DCR DESCRIPTION "NC LO stopped by LM DCR DESCRIPTION "NC LO was prohibited to do delivery DCR DESCRIPTION "NC IL timeout on FEP line service DCR DESCRIPTION " " " "

"DER X25 Remote Procedure Error " 30 DCR DESCRIPTION Yes Problem in X25 protocol handling by the remote DTE "NA X25 Access Barred " 21 DCR DESCRIPTION Yes If in ICR : The requested service is barred for the PIN If in DCR : The destination address rejected the call. "LPE X25 Local Procedure Error " 29 DCR DESCRIPTION Yes Problem in X25 protocol handling by the local

DTE

"NA X25 DTE Incompatible Call " 29 DCR DESCRIPTION Yes The destinations set up is not compatible with LES. "NC X25 Call Collision " 22 DCR DESCRIPTION Yes The LES received a call exactly at the same time it was making a call to a particular destination "NC X25 Restart Received " 24 DCR DESCRIPTION Yes X25 Restart Packet received. i.e. network has been reset.
E-15

Call Completion Code List

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

606 ICR Yes 607 ICR Yes 608 ICR Yes 609 ICR Yes 610 ICR Yes 611 ICR No 612 ICR No 613 ICR No 614 ICR Yes 615 ICR No 616 ICR yes 617 ICR Yes 618 ICR Yes 619 ICR yes

"NC X25 Reset Received " 22 DCR DESCRIPTION Yes X25 Reset packet received. i.e the Virtual circuit reset. "NC X25 Network Timeout " 23 DCR DESCRIPTION Yes Network did not reply to LES in the required time limit Chances are that the network is out of order "NP X25 Protocol Error " 22 DCR DESCRIPTION Yes X25 protocol error by local or remote DTE. "NC X25 Internal Cause " DCR DESCRIPTION Yes Internal problems with the LES. 22

"DTE X25 User Cleared " 21 DCR DESCRIPTION Yes The user has cleared the X25 call. "OCC X25 Number Busy DCR DESCRIPTION Yes Destination number is busy " 20

"DER X25 Out Of Order " 21 DCR DESCRIPTION Yes Destination number is out of order. "ABS X25 Not Obtainable " 22 DCR DESCRIPTION yes Destination number does NOT Exist. "NC X25 LES Congestion " 22 DCR DESCRIPTION No LES is congested. users should try later. "NA X25 Invalid Dest address " 28 DCR DESCRIPTION Yes Destination address fails the LES internal validations. "DTE X25 User Abort Trans " 24 DCR DESCRIPTION No User has quitted out of a service. "NA X25 Mobile Barred DCR DESCRIPTION No The required mobile is barred "ABS X25 Mobile Absent DCR DESCRIPTION No The required mobile is absent " 21

"

21

"BK X25 Exceed Retries " 22 DCR DESCRIPTION No The user has exceeded number of retries for entering an valid input to the given prompt. The call has therefore been cleared and the service request been aborted. "LDE X25 Max Msgs Exceeded " 25 DCR DESCRIPTION No Max limit on follow on message is 10. This upper limit
E-16

620 ICR Yes

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

Call Completion Code List

has been exceeded. i.e the user is trying to send more than 10 messages in the same session. 621 ICR Yes 622 ICR Yes 623 ICR Yes 624 ICR No 625 ICR Yes 626 ICR No 627 ICR No "LDE X25 Msg Too Long " 20 DCR DESCRIPTION No message length exceeded max value. "NC X25 Network Shut " 20 DCR DESCRIPTION Yes Network has been shutdown - as a result of operator request or during a Bap/Demsa switchovers "NC X25 Routing Failure " 23 DCR DESCRIPTION No The Message Handler has failed to route the message to the required mobile "NP X25_PVC_Not_Available " 25 DCR DESCRIPTION no PVC assigned to immediate forwarding is out of service. "NA X25_Invalid_Facility " 24 DCR DESCRIPTION No Invalid facilities has been requested by the calling DTE. "NC X25_PVC_Queue_Full " 22 DCR DESCRIPTION No PVC Queue for immediate forwarding Data Reports is full. "NC X25_PVC_Not_Started " 23 DCR DESCRIPTION No Data Report was received before XCCC process was started.

Codes in the range 700-799 reserved for X400 service. 800 ICR yes 801 ICR yes "DER SD Satellite Call Failed " 28 DCR DESCRIPTION yes Call failed in satellite driver for unspecified reason "ABS SD Mobile Absent " 20 DCR DESCRIPTION yes Attempt to deliver call to mobile not now logged into given ocean region. The mobile status has changed while the call was in progress. "BK SD Aborted By Operator DCR DESCRIPTION yes Operator cancelled call " 26

802 ICR yes 803 ICR yes 804 ICR yes 805 ICR yes

"OCC SD Call Failed Due To Distress " 34 DCR DESCRIPTION yes Call was aborted due to distress call from same mobile "NA SD Invalid Address In Message " 33 DCR DESCRIPTION Message data network type and address mismatch "FMT SD Invalid Address Format " 29 DCR DESCRIPTION Invalid address format or invalid address extension or invalid F69, DNIC, U80, SAC, NMDD, DNID, route number or
E-17

Call Completion Code List

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

illegal extension length or illegal address location or message packet failed validation 806 ICR yes 807 ICR yes 808 ICR yes 809 ICR yes "LDE SD Invalid Message Size " 27 DCR DESCRIPTION yes Message too long or zero length message "TMD SD Invalid Number Of Addresses " 34 DCR DESCRIPTION Message from mobile contained an invalid number of addresses, e.g. 0 or >20 telex, >8 PSDN or >7 PSTN "NA SD Invalid Presentation " 27 DCR DESCRIPTION An unsupported presentation code or a mismatch between the assignment request data network and presentation code "NC SD LES Internal Error " 25 DCR DESCRIPTION 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 "NA SD Mobile Already Commissioned " 33 DCR DESCRIPTION yes Attempt to commission an already commissioned mobile "NA SD Mobile Barred " 20 DCR DESCRIPTION yes Attempt to send a call to, or receive a call from, a barred mobile "OCC SD Mobile Busy " 18 DCR DESCRIPTION yes Attempt to send call to an already busy mobile "DER SD Mobile Failed To Respond " 31 DCR DESCRIPTION yes Mobile failed to respond when expected "BK SD Mobile Forced Clear " 26 DCR DESCRIPTION yes Mobile sent a force clear to cancel the call "NA SD Mobile Not Commissioned " 30 DCR DESCRIPTION yes Attempt to send/receive message from non-commissioned mobile "ABS SD Mobile Not Logged In OR " 30 DCR DESCRIPTION yes Attempt to send/receive message from mobile not logged into this ocean region "NP SD Mobile Not Registered " 28 DCR DESCRIPTION Call received from mobile not in the mobile list "DER SD Mobile Responded Incorrectly DCR DESCRIPTION
E-18

810 ICR yes 811 ICR yes 812 ICR 813 ICR yes 814 ICR yes 815 ICR yes 816 ICR yes 817 ICR yes 818 ICR

"

35

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

Call Completion Code List

yes 819 ICR yes 820 ICR yes 821 ICR yes 822 ICR yes 823 ICR yes 824 ICR yes

yes

Mobile sent incorrect response or responded out of sequence

"DER SD Mobile Response Timeout " 30 DCR DESCRIPTION yes Timeout waiting for mobile response "DER SD Mobile Protocol Error " 28 DCR DESCRIPTION yes Mobile did not follow the protocol "NC SD NCS Failed To Respond " 28 DCR DESCRIPTION yes NCS failed to send the expected response "BK SD NCS Forced Clear " 23 DCR DESCRIPTION yes NCS sent a forced clear to cancel a call "LPE SD Presentation Conversion Error " 36 DCR DESCRIPTION yes Cannot convert the given text to the specified presentation code "NC SD Protocol Failure " 23 DCR DESCRIPTION yes SD did not follow the protocol or a bad state event combination in SD FSM or an unexpected mobile status in registration packet "DER SD Remote Equipment Failure " 31 DCR DESCRIPTION yes Mobile failure, the usual reason is message packets not received from a mobile "NC SD Resource Limit Exceeded " 30 DCR DESCRIPTION yes No resources to allocate a TDM group or a call record or no pending events or MDIR storage full "DER SD Satellite Network Failure DCR DESCRIPTION - this is no longer used " 32

825 ICR yes 826 ICR yes 827 ICR 828 ICR yes 829 ICR

"NA SD Service Not Provided " 27 DCR DESCRIPTION Call attempted for a service not provided by the LES, e.g. ocean region PSTN, SAC, DNID "NC SD Call pending " 19 DCR DESCRIPTION Mobile told to wait to send message until capacity is available. "NA SD Invalid LES ID in data report " 36 DCR DESCRIPTION A data report has been received with an invalid LES id. "NC SD TDM Not Available " 24 DCR Description yes No TDM Group assigned to given Ocean Region and Spot Id combination.
E-19

830 ICR 831 ICR no

Call Completion Code List

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

832 ICR yes

"NA SD No Msg Status Information " 32 DCR Description no Unable to obtain message status information from the database for this call. The message status request is either more than 72 hours after the original call or an erroneous MRN was supplied. "ITD SD Error in Outbound Message " 32 DCR DESCRIPTION An error has been detected in the outbound message for an unknown reason. "BK SD EGC Transmission Failed by NCS " 37 DCR DESCRIPTION yes The NCS has not acknowledged the EGC. "BK SD EGC Packet Sequence Error " 32 DCR DESCRIPTION yes (In Standalone mode only) The FEP has acknowledged the transmission of an EGC block that was the block which was expected. "BK SD Call Cleared By System " 29 DCR DESCRIPTION yes Call has been cleared e.g. if the LES has detected that it to have been stuck in the system. "OCC SD Cancelled due to Distress EGC DCR DESCRIPTION yes No longer required. "DER DCR yes " 36

833 ICR

834 ICR no 835 ICR no

836 ICR no 837 ICR no 838 ICR no

Announcement failed due to login " 39 DESCRIPTION An outgoing call fails since the mobile is in the process of logging into a different Spot Id or Ocean Region.

839 ICR no

"ABS SD Call to an incorrect Ocean Region" 40 DCR DESCRIPTION yes An outgoing call fails since the mobile is no longer logged into that Spot Id or Ocean Region. "NC SD MSG Channel Overloaded " DCR DESCRIPTION yes There are too many concurrent Inbound messages for the number of message channels. "NC MH Congested " 16 DCR DESCRIPTION yes MDir did not route delivery due to scheduler or route congestion "NC MH Routing Failed " 21 DCR DESCRIPTION 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-20

845 ICR no

900 ICR no 901 ICR no

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

Call Completion Code List

mobile (event raised). 902 ICR no "NC MH Rerouting Failed " 23 DCR DESCRIPTION yes Failed to reroute delivery - LES was unable to determine an alternate route for the delivery from the routing table - possible exhaustion of alternate routes, possible error in routing table (event raised). "NC MH CNID Msg Not Stored " 26 DCR DESCRIPTION yes CNID addressed message not stored in DNID file due to problem other than overflow. "NC MH Oper Msg Not Logged " 26 DCR DESCRIPTION yes MDir failed to log operator message - LFM was unable to write log records to operator log file (event raised) "NC MH CNID Overflow Occurred " 29 DCR DESCRIPTION yes CNID addressed message not stored in DNID file due to overflow. "NC MH Data Report Msg Not Stored " 33 DCR DESCRIPTION no Data report not stored in DNID file due to problem other than overflow. "NC MH Data Report Overflow Occurred " 36 DCR DESCRIPTION no Data report not stored in DNID file due to overflow.

903 ICR no 904 ICR no 905 ICR no 906 ICR yes 907 ICR yes

opga5.mss

E-21

CSPR

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

E-22

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

CSPR

Appendix F CUSTOMER SERVICE PROBLEM REPORT


In the event of any problem occurring at a Customers site, the Customer Service Problem Reporting mechanism provides the means for a report to be sent to HNS Ltd on a form which allows both the problem and solution to be tracked. The following extracts from Company procedure PAP0046 show how the customer can ensure that problems are dealt with efficiently and speedily to everyones satisfaction. When a CSPR form has been completed, the customer should contact the Customer Service Desk at HNS Ltd. Telephone number : +44 1908 221122 extension 220. A unique CSPR number will be allocated, which the customer should add to the form before forwarding the original CSPR to 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 the first instance to the Customer Service Desk at HNS Ltd. Forms should not be sent to other staff at HNS; 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 that HNS Ltd staff are in a position to recreate the error situation if necessary in order to provide a comprehensive and satisfactory solution. If there is insufficient room in any section then Continuation sheets can be used and crossreference 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. Customer Service 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 symptoms of the problem and specify other information as appropriate. Outage Time/Period of non-operation/Duration of Traffic Loss - enter the number of hours of system failure.
F-1

CSPR

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

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 running 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-system or 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 testing being carried out. Attachments : Record details of any other information provided (on tape or in hardcopy). If any continuation 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 HNS in tracing the fault. Use the Operating System Console to log onto the BAP that was master when the fault occurred, as described in section 12.2, and copy the latest file by using the following command : 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 or accessed 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 a Return Material Authorisation number, which should be entered on the CSPR form and used to identify the hardware concerned. Each separate module should have a separate CSPR form and RMA number - this is used internally by HNS to track the progress of the repair. The units should be despatched in the boxes in which they were delivered to site. Note that in the case of the Channel Units and the MTMs, the flying leads on the front of the unit are part of the unit and should be returned if there is a fault. When the Customer Service Desk receives the completed CSPR form, it will pass it to the relevant personnel for attention. When the problem has been resolved, the Customer Service Desk will provide copies of all the relevant documentation detailing the problem solution and send it to the customer along with the original CSPR form. The CSPR is considered closed either when the Customer returns the original form signed as accepted or when four weeks have passed since solution and the customer has not made any comments on the solution.
[opga6.mss]

F-2

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

Glossary

Appendix G GLOSSARY
ACSE Ada AFC Alarm AORE AORW Arbiter Access Control and Signalling Equipment, composed of the SCPs plus channel unit equipment A high level language introduced by the US Department of Defense and widely used on the ACSE Automatic Frequency Compensation An event that is raised immediately to the SOC operators attention and which has associated audible and visible indication. Atlantic Ocean Region East Atlantic Ocean Region West A device that tells the BAPs on startup which BAP is Master and which is Standby. It also monitors each BAP for activity and if a BAP failure is detected, it commands the Standby BAP to become Master Automatic retransmission request Alarm and Switchover Module Background Applications Processor, the VAX that does the message storage, routing, and provides operator services A call record visible to and used by customers for billing Bus Interface Module Bothway Radio frequency in the range 4 - 6GHz. In this application used for transmission between the earth station and the satellite and vice versa. Note: Although the ACSE acts as if C-Band were used the RF equipment converts to and from Ku-Band in this application Call A connection originated by a user to enter messages or status requests into the LES or a connection originated by the LES to pass messages or status to a user A data structure used for holding details of a call. It is allocated by a Call Record Manager package. There is one ICR for each call entered into the LES and a DCR for each destination attempt International Consultive Committee for Telegraphy and Telephony. A standards group for communications Coast Earth Station - obsolescent term replaced by LES Closed Network ID - obsolescent term replaced by DNID Name of modem used along with the MicroTurbo PAD for the asynchronous interface. Comms package that contains HNS preferred version of Kermit , for running on PCs and Async Terminals Channel Unit, the part of the LES configuration that provides the communication path for a single satellite channel Channel Unit Controller, a component of the LES software that provides low level call handling support for the satellite driver. Also the DEC VAX Front End Processors that drive the channel units
G-1

ARQ ASM BAP Billing Record BIM B/W C-band

Call Record

CCITT CES CNID Codex Crosstalk CU CUC

Glossary

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

CURC Data Report DCE DCL DCR DEC DEMSA DMOD DNIC DNID DTE

Channel unit rack control line A short message sent on the signalling channel of the LES. It is stored in a DNID file Data Circuit-terminating Equipment. CCITT terminology for a class of data devices, of which the most common is the modem Digital Command Language - VAX VMS language used for writing command procedures Delivery Call Record Digital Equipment Corporation (Trademark). Supplier of the computers used in the SCP A DEC Microserver that supports the DEC X.25 package, providing routing between DECnet and the X.25 PSDN (or Demodulator) Channel Unit for receiving characters from Satellite Data Network Identity Code. International code for identifying data networks Data Network Identification, an address of a file in the LES that stores data reports and messages (formerly CNID) Data Terminal Equipment. CCITT terminology for the data terminal devices themselves, a category which includes the computer. In Inmarsat-C terms, a user device that connects to the DCE part of an MES. A keyboard is one example of a DTE Electronic Mail Enhanced Group Call, a broadcast message to one or more mobiles Enhanced Group Call Identification - obsolescent term replaced by ENID. The DEC operating system that is used in the DEC single board computers that are used for Front End Processors The customer for the service. See Terrestrial User Enhanced Network Identification. 16 bit number used in EGC addressing (formerly EGCID). A message generated by the LES to the Log file to record an occurrence in the system. Front End Processor. DEC Single board VAX implementing the CUC and TIC functions or DEMSA for the X25 interface.

E-Mail EGC EGCID ELN End User ENID Event FEP

Follow on message The ability to accept more than one message in a single call setup. This is also referred to as follow on call. Follow on messages are allowed from LES to mobile where the LES successfully transmits a message to a mobile and has another message for the same mobile queued for delivery. Some terrestrial interfaces have the capability of follow on messages GMDSS IA5 ICR IF IOR Global Maritime Distress and Safety at Sea International Alphabet Number 5. This is the default code for all Inmarsat-C Mobiles Incoming Call Record Intermediate frequency, in this application 70MHz Indian Ocean Region
G-2

Inbound Message In the direction of Mobile to LES

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

Glossary

Inmarsat Inmarsat-C ISC ISL ITA2 Journal File Kermit Ku-Band L-band LCA LCN LCU

International Maritime Satellite Organisation - owners of various satellite systems and regulators of the protocols for using those systems The protocol as defined in 1. Also, the protocol used between the mobile and the LES for the orderly transfer of data. Formerly referred to as "Standard-C". International switching Centre Interstation Signalling Link, used for communications between LES and NCS. Not used in this application. International Telegraph Alphabet Number 2, a 5 bit code used for Telex A log which contains a history of events, call records, and statistics. It is processed by the offline database program. Also known as Log file Software protocol used for file transfer Radio frequency in the range 10 to 15 GHz. In this application used instead of C-Band for the up and downlinks to the satellite. Radio frequency in the range 1 - 2 GHz. In this application used for communication between the mobile and the satellite and vice versa. Logical Channel Assignment Logical Channel Number that is allocated to a message transfer between the LES and a mobile Logical Channel Unit. This is used to define the satellite channel hardware configuration independent of the physical equipment used to provide the actual function. This allows LCUs to be permanently committed to a specific function, such as a TDM channel in a TDM group, even though the physical equipment may be changed dynamically for redundancy switchover purposes A communications line that is dedicated to a particular end user. May be Telex or asynchronous Land Earth Station. The equipment providing the gateway between mobiles and terrestrial networks, and comprising the ACSE plus Radio Frequency equipment. (formerly CES) Land Mobile Alert Destination An active component in the system that carries traffic. See Standby Macro Encoded Message. A 7 bit code that has a specific meaning defined by an end user. Used to send messages with a preset meaning in a compact form as part of the polling protocol. Mobile Earth Station. The L-Band terminal used to access the network using the Inmarsat-C protocol. (formerly SES) Two 24 bit numbers that are used on the satellite channels to identify a mobile. The forward ID is used in the outbound direction and the reverse ID is used in the inbound direction. These numbers are not presented to the external users. These numbers should not be confused with the 9 digit Mobile number associated with the pair of IDs in the mobile list.

Leased Line LES

LMAD Master MEM

MES MES ID

Message Channel An inbound channel for transferring messages between an MES and the LES. Message Handler Message handler subsystem in the LES. MicroPAD MID MMI Type of PAD used in the LES for Asynchronous operation made by SFA Datacomms Inc. (formerly Plantronics). Maritime Identification Digits - part of the mobiles address Man Machine Interface, the entire collection of input/output peripherals used
G-3

Glossary

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

by system operators to monitor and control the system Mobile Mobile Number Another term for MES The 9 digit mobile number that is used by terrestrial users and mobiles to address a mobile. This number should not be confused with the 24 bit MES IDs to which it is associated in the mobile list. (or Modulator) Channel Unit sending characters to Satellite is a trademark of the Open Software Foundation Inc., representing the windowing system used on certain SOCs, and which may be used on non DEC terminals. Maritime Rescue Coordination Centre. All maritime distress messages are automatically routed to the MRCC address which must be configured Message Reference Number - generated by the ACSE to uniquely identify each message. Master Timing Module, part of the CU rack hardware which generates the 12MHz reference for the CUs Network Control Program (DEC utility) Network Coordination Station, coordinates the MESs and LESs in a given Ocean Region (Not used in this application) Non Delivery Notification Non-Maritime Distress Destination. Another term for LMAD Network User Address One of: Atlantic (East), Atlantic (West), Pacific or Indian.

MOD Motif

MRCC MRN MTM NCP NCS NDN NMCC NUA Ocean Region

Offline Processing All 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 Outbound PAD PCU The multitasking operating system used on the LES Facsimile interface servers. OS/2 is a trademark of International Business Machines. Message in the direction of LES to Mobile Packet Assembler/Disassembler, used to connect non X.25 devices to X.25 networks Physical Channel Unit. This is used to define the characteristics of the physical channel unit equipment in the channel unit equipment hardware racks. PCUs can be assigned to LCUs automatically in CU redundancy activity or manually by the operator for maintenance purposes Positive Delivery Notification Personal Identification Number (6 - 8 Alphanumeric characters) Phase-locked loop, used in frequency synthesis and demodulation A short message transmitted to one or more mobiles as a broadcast message. It is sent on the NCS TDM, or in stand-alone on the LES TDM. A Poll can generate a response from the mobile in the form of a data report. Pacific Ocean Region Packet Switched Data Network A DEC layered product running on the DEMSAs under VMS that realises the X.25 interface from the PSDN network to the LES Public Switched Telephone Network Public Switched Telex Network
G-4

PDN PIN PLL Poll

POR PSDN PSI PSTN PSTxN

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

Glossary

PTT PVT RCC RF RFT Route S&F SAC

Public Telephone and Telegraph organisation Performance Verification Test, also known as Link Test Rescue Coordination Centre. Radio Frequency, the frequency at which the signal is transmitted over the air. Radio Frequency Terminal, that part of the earth station which links the IF signal at the ACSE interface with the satellite dish. A collection of paths to the next switching point Store and Forward, a technique used in messaging where the whole message is received and then passed on. Special Access Code, a short code that is expanded by the LES into a full terrestrial address. SACs can also cause the LES to perform a specific predefined function System Control Processor, the DEC VAX computers and associated peripherals that controls the LES Signal distribution and alarm panel. This is the top chassis in the Channel Unit rack. Specification Design Language - a CCITT graphical language for defining systems System Definition Manual see 1 for the version used. Ship Earth Station. Obsolete term, replaced by MES Signalling Channel

SCP SDAP SDL SDM SES SIG

Signalling Channel A 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 in a multi window environment to configure, control, and monitor the ACSE. (Component in the LES Software) SOC Viewer - access to the data in the BAP via the SOC. Structured Query Language. The high level language used by most commercial database packages A component in the system that is providing redundancy. It does not carry traffic. Depending on the state of the standby equipment it may or may not be able to become Master Switched Virtual Circuit. An X.25 term for a logical communications channel over an X.25 network Relational database used for storing the data for the LES (Trademark) Time Division Multiplex - the channel is divided into frames and each frame into slots. The same slot in successive frames is allocated to specific purposes. This mechanism is used in the channels from LES or NCS to a MES. Associated with a particular TDM output channel there are signalling and message channels. These channels are form a TDM group The LES customer using the ACSE services via the terrestrial network, ie Public Networks, Private Networks or Leased lines. In practice, this includes mobiles from other mobile data services. Terrestrial Interface Controller. A type of FEP in the ACSE, interfaces between the SCP and the Telex lines of the terrestrial network.
G-5

SOCV SQL Standby

SVC SYBASE TDM

TDM Group Terrestrial User

TIC

Glossary

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

TNIC TSAP VAX VMS VMS Console

Terrestrial Network Identity Code. Used for identifying telex networks, as described in CCITT Rec F69. Terrestrial Service Access Point. A logical grouping of LES provided services Virtual Address Extension. The name for the DEC family of computers used to implement the LES The DEC operating system used in the BAPs A terminal that controls the DEC VMS operating system. This is a physical terminal plus a printer that is connected to each BAP, or it can be a window on the SOC DEC windowing system, used in certain SOCs CCITT standard for passing data packets over transmission links CCITT standard for packet assemblers/disassemblers (PADs) CCITT standard for messaging services Name of product used for sending Faxes from LES via FAX PC

VWS X.25 X.29 X.400 ZETAFAX


[glossary.mss]

G-6

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

Glossary OPERATOR GUIDE Table of Contents

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 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 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

Glossary OPERATOR GUIDE Table of Contents


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 F69 codes 6-4 Facsimile interface 6-13 Failure to handle messages 8-50 Enter key 3-1 Equipment switch settings A-1 Ethernet node connections 12-4 Event summary display 10-20

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

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

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

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001


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

Glossary OPERATOR GUIDE Table of Contents

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

Glossary OPERATOR GUIDE Table of Contents


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 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 PSI security 10-16 PSTN 6-13, 6-20

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

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

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001


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 User access 10-28 TDM group statistics 7-18

Glossary OPERATOR GUIDE Table of Contents

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

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

Glossary OPERATOR GUIDE Table of Contents


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

A4-OPG-003076 Issue 3.23 - Accepted 17th July 2001

You might also like